From xen-devel-bounces@lists.xensource.com Thu Sep 01 00:03:42 2011 Return-path: Envelope-to: www-data@lists.xensource.com Delivery-date: Thu, 01 Sep 2011 00:03:42 -0700 Received: from localhost ([127.0.0.1] helo=lists.colo.xensource.com) by lists.xensource.com with esmtp (Exim 4.43) id 1Qz1JO-0005AO-Eb; Thu, 01 Sep 2011 00:03:42 -0700 Received: from mail27.messagelabs.com ([193.109.254.147]) by lists.xensource.com with smtp (Exim 4.43) id 1Qz1Ey-0004uR-3a for xen-devel@lists.xensource.com; Thu, 01 Sep 2011 00:00:15 -0700 X-Env-Sender: kevin.tian@intel.com X-Msg-Ref: server-14.tower-27.messagelabs.com!1314860330!34304481!1 X-Originating-IP: [192.55.52.93] X-StarScan-Version: 6.3.6; banners=-,-,- X-VirusChecked: Checked Received: (qmail 27391 invoked from network); 1 Sep 2011 06:58:51 -0000 Received: from mga11.intel.com (HELO mga11.intel.com) (192.55.52.93) by server-14.tower-27.messagelabs.com with SMTP; 1 Sep 2011 06:58:51 -0000 Received: from fmsmga002.fm.intel.com ([10.253.24.26]) by fmsmga102.fm.intel.com with ESMTP; 31 Aug 2011 23:59:01 -0700 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="4.68,312,1312182000"; d="scan'208";a="47427266" Received: from pgsmsx603.gar.corp.intel.com ([10.221.43.87]) by fmsmga002.fm.intel.com with ESMTP; 31 Aug 2011 23:58:59 -0700 Received: from pgsmsx103.gar.corp.intel.com (10.221.44.82) by pgsmsx603.gar.corp.intel.com (10.221.43.87) with Microsoft SMTP Server (TLS) id 8.2.255.0; Thu, 1 Sep 2011 14:58:40 +0800 Received: from shsmsx602.ccr.corp.intel.com (10.239.4.104) by PGSMSX103.gar.corp.intel.com (10.221.44.82) with Microsoft SMTP Server (TLS) id 14.1.323.3; Thu, 1 Sep 2011 14:58:40 +0800 Received: from shsmsx502.ccr.corp.intel.com ([10.239.4.96]) by SHSMSX602.ccr.corp.intel.com ([10.239.4.104]) with mapi; Thu, 1 Sep 2011 14:58:39 +0800 From: "Tian, Kevin" To: Konrad Rzeszutek Wilk , "x86@kernel.org" , "tglx@linutronix.de" , "tboot-devel@lists.sourceforge.net" , "Wang, Shane" , "linux-pm@lists.linux-foundation.org" , "linux-acpi@vger.kernel.org" , "Brown, Len" , "Cihula, Joseph" , "hpa@zytor.com" , "Yu, Ke" , "liang.tang@oracle.com" , "keir@xen.org" Date: Thu, 1 Sep 2011 14:58:38 +0800 Thread-Topic: [RFC PATCH v1] ACPI S3 to work under Xen. Thread-Index: AcxoDGbfAJcvZpZKTgi46ODu9l0kwwAZkpgQ Message-ID: <625BA99ED14B2D499DC4E29D8138F15063048B8696@shsmsx502.ccr.corp.intel.com> References: <1314815484-4668-1-git-send-email-konrad.wilk@oracle.com> In-Reply-To: <1314815484-4668-1-git-send-email-konrad.wilk@oracle.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "xen-devel@lists.xensource.com" Subject: [Xen-devel] RE: [RFC PATCH v1] ACPI S3 to work under Xen. X-BeenThere: xen-devel@lists.xensource.com X-Mailman-Version: 2.1.5 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xensource.com Errors-To: xen-devel-bounces@lists.xensource.com > From: Konrad Rzeszutek Wilk [mailto:konrad.wilk@oracle.com] > Sent: Thursday, September 01, 2011 2:31 AM >=20 > Attached is an RFC set of patches to enable S3 to work with the Xen hyper= visor. >=20 > The relationship that Xen has with Linux kernel is symbiotic. The Linux > kernel does the ACPI "stuff" and tells the hypervisor to do the low-level > stuff (such as program the IOAPIC, setup vectors, etc). The realm of > ACPI S3 is more complex as we need to save the CPU state (and Intel TXT > values - which the hypervisor has to do) and then restore them. >=20 > The major difficulties we hit was with 'acpi_suspend_lowlevel' - which tw= eaks > a lot of lowlevel values and some of them are not properly handled by Xen= . > Liang Tang has figured which ones of them we trip over (read below) - and= he > suggested that perhaps we can provide a registration mechanism to abstrac= t > this away. that's not a problem for Xen. On bare metal the processor state handled off from BIOS after resume (e.g. real mode in many cases) doesn't match the execution environment expected by Linux. So Linux has to save original cont= ext and then restore it after resume. However for Xen, Linux doesn't talk to BIOS directly. Instead it simply wal= ks through necessary ACPI methods, and then issues a hypercall to Xen which then further completes the remaining suspend steps. So here ACPI S3 is exactly same as any other hypercall path, where processor context will be saved/restored by Xen automatically. >=20 > So the attached patches do exactly that - there are two entry points > in the ACPI. >=20 > 1). For S3: acpi_suspend_lowlevel -> .. lots of code -> acpi_enter_sleep= _state > 2). For S1/S4/S5: acpi_enter_sleep_state >=20 > The first naive idea was of abstracting away in the 'acpi_enter_sleep_sta= te' > function the tboot_sleep code so that we can use it too. And low-behold -= it > worked splendidly for powering off (S5 I believe) >=20 > For S3 that did not work - during suspend the hypervisor tripped over whe= n > saving cr8. During resume it tripped over at restoring the cr3, cr8, idt, > and gdt values. >=20 > What do you guys think? One thought is to use the paravirt interface to > deal with cr3, cr8, idt, gdt for suspend/resume case.. But that is a lot > of extra 'if' in the paravirt code - which the callback registration wou= ld > effectively do the same thing as the paravirt - except at a higher level. >=20 So tweaking at a higher level is a right thing to do. Thanks Kevin _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel From xen-devel-bounces@lists.xensource.com Thu Sep 01 00:43:42 2011 Return-path: Envelope-to: www-data@lists.xensource.com Delivery-date: Thu, 01 Sep 2011 00:43:42 -0700 Received: from localhost ([127.0.0.1] helo=lists.colo.xensource.com) by lists.xensource.com with esmtp (Exim 4.43) id 1Qz1w5-0006Lm-RI; Thu, 01 Sep 2011 00:43:41 -0700 Received: from mail21.messagelabs.com ([85.158.143.35]) by lists.xensource.com with smtp (Exim 4.43) id 1Qz1vL-000695-MU for xen-devel@lists.xensource.com; Thu, 01 Sep 2011 00:42:56 -0700 X-Env-Sender: Ian.Campbell@eu.citrix.com X-Msg-Ref: server-9.tower-21.messagelabs.com!1314862931!46747651!1 X-Originating-IP: [62.200.22.115] X-StarScan-Version: 6.3.6; banners=-,-,- X-VirusChecked: Checked Received: (qmail 4315 invoked from network); 1 Sep 2011 07:42:11 -0000 Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115) by server-9.tower-21.messagelabs.com with SMTP; 1 Sep 2011 07:42:11 -0000 X-IronPort-AV: E=Sophos;i="4.68,312,1312156800"; d="scan'208";a="7545400" Received: from lonpmailmx01.citrite.net ([10.30.203.162]) by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5; 01 Sep 2011 07:42:52 +0000 Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net (10.30.203.162) with Microsoft SMTP Server id 8.3.137.0; Thu, 1 Sep 2011 08:42:52 +0100 Subject: Re: [Xen-devel] Kernel bug from 3.0 (was phy disks and vifs timing out in DomU) From: Ian Campbell To: Konrad Rzeszutek Wilk In-Reply-To: <20110831170711.GB13642@dumpdata.com> References: <4E31820C.5030200@overnetdata.com> <1311870512.24408.153.camel@cthulhu.hellion.org.uk> <4E3266DE.9000606@overnetdata.com> <20110803152841.GA2860@dumpdata.com> <4E4E3957.1040007@overnetdata.com> <20110819125615.GA26558@dumpdata.com> <4E56B132.9050708@overnetdata.com> <20110826142606.GA25511@dumpdata.com> <20110826144438.GA24836@dumpdata.com> <4E5E6843.7050206@citrix.com> <20110831170711.GB13642@dumpdata.com> Content-Type: text/plain; charset="UTF-8" Organization: Citrix Systems, Inc. Date: Thu, 1 Sep 2011 08:42:52 +0100 Message-ID: <1314862972.28989.74.camel@zakaz.uk.xensource.com> MIME-Version: 1.0 X-Mailer: Evolution 2.32.3 Content-Transfer-Encoding: 7bit Cc: Todd Deshane , "xen-devel@lists.xensource.com" , Jeremy Fitzhardinge , David Vrabel , Anthony Wright X-BeenThere: xen-devel@lists.xensource.com X-Mailman-Version: 2.1.5 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xensource.com Errors-To: xen-devel-bounces@lists.xensource.com On Wed, 2011-08-31 at 18:07 +0100, Konrad Rzeszutek Wilk wrote: > On Wed, Aug 31, 2011 at 05:58:43PM +0100, David Vrabel wrote: > > On 26/08/11 15:44, Konrad Rzeszutek Wilk wrote: > > > > > > So while I am still looking at the hypervisor code to figure out why > > > it would give me [when trying to map a grant page]: > > > > > > (XEN) mm.c:3846:d0 Could not find L1 PTE for address fbb42000 > > > > It is failing in guest_map_l1e() because the page for the vmalloc'd > > virtual address PTEs is not present. > > > > The test that fails is: > > > > (l2e_get_flags(l2e) & (_PAGE_PRESENT | _PAGE_PSE)) != _PAGE_PRESENT > > > > I think this is because the GNTTABOP_map_grant_ref hypercall is done > > when task->active_mm != &init_mm and alloc_vm_area() only adds PTEs into > > init_mm so when Xen looks in the page tables it doesn't find the entries > > because they're not there yet. > > > > Putting a call to vmalloc_sync_all() after create_vm_area() and before > > the hypercall makes it work for me. Classic Xen kernels used to have > > such a call. > > That sounds quite reasonable. I was wondering why upstream was missing the vmalloc_sync_all() in alloc_vm_area() since the out-of-tree kernels did have it and the function was added by us. I found this: http://git.kernel.org/?p=linux/kernel/git/torvalds/linux.git;a=commitdiff;h=ef691947d8a3d479e67652312783aedcf629320a commit ef691947d8a3d479e67652312783aedcf629320a Author: Jeremy Fitzhardinge Date: Wed Dec 1 15:45:48 2010 -0800 vmalloc: remove vmalloc_sync_all() from alloc_vm_area() There's no need for it: it will get faulted into the current pagetable as needed. Signed-off-by: Jeremy Fitzhardinge The flaw in the reasoning here is that you cannot take a kernel fault while processing a hypercall, so hypercall arguments must have been faulted in beforehand and that is what the sync_all was for. It's probably fair to say that the Xen specific caller should take care of that Xen-specific requirement rather than pushing it into common code. On the other hand Xen is the only user and creating a Xen specific helper/wrapper seems a bit pointless. Ian. > > > > This presumably works on some systems/configuration and not others > > depending on what else is using vmalloc(). i.e., if another kernel > > thread (?) calls vmalloc() etc. then there will be a page for vmalloc > > area PTEs and it will work. > > > > I'll try and post a patch tomorrow. > > > > Thanks to Ian Campbell for pointing me in the right direction. > > Great! Thanks for hunting this one down. > > > > David _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel From xen-devel-bounces@lists.xensource.com Thu Sep 01 01:05:10 2011 Return-path: Envelope-to: www-data@lists.xensource.com Delivery-date: Thu, 01 Sep 2011 01:05:10 -0700 Received: from localhost ([127.0.0.1] helo=lists.colo.xensource.com) by lists.xensource.com with esmtp (Exim 4.43) id 1Qz2Gs-00077V-4b; Thu, 01 Sep 2011 01:05:10 -0700 Received: from mail27.messagelabs.com ([193.109.254.147]) by lists.xensource.com with smtp (Exim 4.43) id 1Qz2EB-0006tI-Ci for xen-devel@lists.xensource.com; Thu, 01 Sep 2011 01:03:01 -0700 X-Env-Sender: Ian.Campbell@eu.citrix.com X-Msg-Ref: server-3.tower-27.messagelabs.com!1314864119!37836065!1 X-Originating-IP: [62.200.22.115] X-StarScan-Version: 6.3.6; banners=-,-,- X-VirusChecked: Checked Received: (qmail 9914 invoked from network); 1 Sep 2011 08:01:59 -0000 Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115) by server-3.tower-27.messagelabs.com with SMTP; 1 Sep 2011 08:01:59 -0000 X-IronPort-AV: E=Sophos;i="4.68,312,1312156800"; d="scan'208";a="7545784" Received: from lonpmailmx01.citrite.net ([10.30.203.162]) by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5; 01 Sep 2011 08:02:10 +0000 Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net (10.30.203.162) with Microsoft SMTP Server id 8.3.137.0; Thu, 1 Sep 2011 09:02:10 +0100 Subject: Re: [Xen-devel] difference between xen hypervisor and common kernel on handling BIOS's e820 map ? From: Ian Campbell To: Konrad Rzeszutek Wilk In-Reply-To: <20110830161004.GA4055@dumpdata.com> References: <1314681899.56694.YahooMailNeo@web122110.mail.ne1.yahoo.com> <20110830140030.GG11346@dumpdata.com> <1314718232.58990.YahooMailNeo@web122104.mail.ne1.yahoo.com> <20110830161004.GA4055@dumpdata.com> Content-Type: text/plain; charset="UTF-8" Organization: Citrix Systems, Inc. Date: Thu, 1 Sep 2011 09:02:09 +0100 Message-ID: <1314864129.28989.81.camel@zakaz.uk.xensource.com> MIME-Version: 1.0 X-Mailer: Evolution 2.32.3 Content-Transfer-Encoding: 7bit Cc: "xen-devel@lists.xensource.com" , Lin-bao Zhang X-BeenThere: xen-devel@lists.xensource.com X-Mailman-Version: 2.1.5 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xensource.com Errors-To: xen-devel-bounces@lists.xensource.com On Tue, 2011-08-30 at 17:10 +0100, Konrad Rzeszutek Wilk wrote: > On Tue, Aug 30, 2011 at 08:30:32AM -0700, Lin-bao Zhang wrote: > > > > > > >> I diff them in a picture : > > > > >Huh? Can you just do a diff of the two texts or just > > >do <=== on the email to point to it? > > orry for lost that differing result of picture(I just paste it here ,it seems it can't work), > > I am having a hard time believing you can't paste it (which you did in the previous email) > and adding this in what you pasted: > > Xen: 00000000fff80000 - 0000000100000000 (reserved) > Xen: 0000000100000000 - 0000000144b15000 (usable) <==== THIS ONE? > > > so , I paste this picture link:https://lh3.googleusercontent.com/-SfaWAj7_hzQ/TlyUQhgoUcI/AAAAAAAAAVk/Ax_ucBYVbD4/s800/e820%252520map.jpg > > Ah, That. It is an extra 8MB phantom area that is used to setup mappings with > other guests. It's described as being to "balance backend allocations", which AIUI means it's there to provide an extra 8M of (empty) PFN space for the backend drivers to use for the page arrays where they map foreign pages. This might have made sense in the old days when netback/blkback would allocate there array and return the backing MFNs to Xen but in mainline we only shadow those MFNs rather than returning them to the hypervisor, don't we? So the slack doesn't really make sense any more. I fully expect 8M bears no relationship to the actual size used by the backends these days. Ian. > > > > > I also upload my machine's all booting messages including BIOS/grub/linuxkernel. > > There is no need for all of that. > > _______________________________________________ > Xen-devel mailing list > Xen-devel@lists.xensource.com > http://lists.xensource.com/xen-devel _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel From xen-devel-bounces@lists.xensource.com Thu Sep 01 01:20:05 2011 Return-path: Envelope-to: www-data@lists.xensource.com Delivery-date: Thu, 01 Sep 2011 01:20:05 -0700 Received: from localhost ([127.0.0.1] helo=lists.colo.xensource.com) by lists.xensource.com with esmtp (Exim 4.43) id 1Qz2VI-0007h1-D4; Thu, 01 Sep 2011 01:20:04 -0700 Received: from mail182.messagelabs.com ([85.158.139.83]) by lists.xensource.com with smtp (Exim 4.43) id 1Qz2US-0007US-AB for xen-devel@lists.xensource.com; Thu, 01 Sep 2011 01:19:12 -0700 X-Env-Sender: imammedo@redhat.com X-Msg-Ref: server-5.tower-182.messagelabs.com!1314865148!11644828!1 X-Originating-IP: [209.132.183.28] X-StarScan-Version: 6.3.6; banners=-,-,- X-VirusChecked: Checked Received: (qmail 2913 invoked from network); 1 Sep 2011 08:19:08 -0000 Received: from mx1.redhat.com (HELO mx1.redhat.com) (209.132.183.28) by server-5.tower-182.messagelabs.com with SMTP; 1 Sep 2011 08:19:08 -0000 Received: from int-mx10.intmail.prod.int.phx2.redhat.com (int-mx10.intmail.prod.int.phx2.redhat.com [10.5.11.23]) by mx1.redhat.com (8.14.4/8.14.4) with ESMTP id p818J7ix022246 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Thu, 1 Sep 2011 04:19:07 -0400 Received: from ns3.rdu.redhat.com (ns3.rdu.redhat.com [10.11.255.199]) by int-mx10.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP id p818J6KE028084; Thu, 1 Sep 2011 04:19:06 -0400 Received: from nial.usersys.redhat.com (dhcp-1-247.brq.redhat.com [10.34.1.247]) by ns3.rdu.redhat.com (8.13.8/8.13.8) with ESMTP id p818J4xX024680; Thu, 1 Sep 2011 04:19:05 -0400 Message-ID: <4E5F3FF7.8010805@redhat.com> Date: Thu, 01 Sep 2011 10:19:03 +0200 From: Igor Mammedov User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.2.20) Gecko/20110805 Red Hat/3.1.12-1.el6_1 Lightning/1.0b2 Thunderbird/3.1.12 MIME-Version: 1.0 To: Jeremy Fitzhardinge References: <20110829194633.GB16530@dumpdata.com> <1314834438-3181-1-git-send-email-imammedo@redhat.com> <4E5EB794.7050909@goop.org> In-Reply-To: <4E5EB794.7050909@goop.org> Content-Type: text/plain; charset=ISO-8859-15; format=flowed Content-Transfer-Encoding: 7bit X-Scanned-By: MIMEDefang 2.68 on 10.5.11.23 Cc: xen-devel@lists.xensource.com, linux-kernel@vger.kernel.org, konrad.wilk@oracle.com Subject: [Xen-devel] Re: [PATCH] xen: x86_32: do not enable iterrupts when returning from exception in interrupt context X-BeenThere: xen-devel@lists.xensource.com X-Mailman-Version: 2.1.5 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xensource.com Errors-To: xen-devel-bounces@lists.xensource.com On 09/01/2011 12:37 AM, Jeremy Fitzhardinge wrote: > On 08/31/2011 04:47 PM, Igor Mammedov wrote: >> If vmalloc page_fault happens inside of interrupt handler with interrupts >> disabled then on exit path from exception handler when there is no pending >> interrupts, the following code (arch/x86/xen/xen-asm_32.S:112): >> >> cmpw $0x0001, XEN_vcpu_info_pending(%eax) >> sete XEN_vcpu_info_mask(%eax) >> >> will enable interrupts even if they has been previously disabled according to >> eflags from the bounce frame (arch/x86/xen/xen-asm_32.S:99) >> >> testb $X86_EFLAGS_IF>>8, 8+1+ESP_OFFSET(%esp) >> setz XEN_vcpu_info_mask(%eax) >> >> Solution is in setting XEN_vcpu_info_mask only when it should be set >> according to >> cmpw $0x0001, XEN_vcpu_info_pending(%eax) >> but not clearing it if there isn't any pending events. > > Wow, that's a great find. I guess it shows how rarely we end up doing > an exception return with interrupts disabled, since that's been there > since, erm, 2.6.23? > > But this could definitely explain some bugs where interrupts became > unexpectedly re-enabled. Were you tracking one down when you found this? > >> Signed-off-by: Igor Mammedov >> --- >> arch/x86/xen/xen-asm_32.S | 6 +++++- >> 1 files changed, 5 insertions(+), 1 deletions(-) >> >> diff --git a/arch/x86/xen/xen-asm_32.S b/arch/x86/xen/xen-asm_32.S >> index 22a2093..313dca7 100644 >> --- a/arch/x86/xen/xen-asm_32.S >> +++ b/arch/x86/xen/xen-asm_32.S >> @@ -113,10 +113,14 @@ xen_iret_start_crit: >> >> /* >> * If there's something pending, mask events again so we can >> - * jump back into xen_hypervisor_callback >> + * jump back into xen_hypervisor_callback. Otherwise do not >> + * touch XEN_vcpu_info_mask. >> */ >> + jne ignore_vcpu_info_mask >> sete XEN_vcpu_info_mask(%eax) >> >> +ignore_vcpu_info_mask: >> + > > This should be: > > jne 1f > movb $1, XEN_vcpu_info_mask(%eax) > > 1: popl %eax > > > There's no point in using sete if we're already using a conditional jump > to avoid the write, and it's better to use local labels for little > control flow changes like this. > > Thanks, > J Jeremy, Thanks for review, I'll re-post it soon. _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel From xen-devel-bounces@lists.xensource.com Thu Sep 01 01:40:23 2011 Return-path: Envelope-to: www-data@lists.xensource.com Delivery-date: Thu, 01 Sep 2011 01:40:23 -0700 Received: from localhost ([127.0.0.1] helo=lists.colo.xensource.com) by lists.xensource.com with esmtp (Exim 4.43) id 1Qz2ox-0001I4-JH; Thu, 01 Sep 2011 01:40:23 -0700 Received: from mail174.messagelabs.com ([85.158.138.51]) by lists.xensource.com with esmtp (Exim 4.43) id 1Qz2oK-00015Y-OZ for xen-devel@lists.xensource.com; Thu, 01 Sep 2011 01:39:45 -0700 X-Env-Sender: Christoph.Egger@amd.com X-Msg-Ref: server-7.tower-174.messagelabs.com!1314866380!29831060!1 X-Originating-IP: [216.32.180.31] X-StarScan-Version: 6.3.6; banners=-,-,- X-VirusChecked: Checked Received: (qmail 15547 invoked from network); 1 Sep 2011 08:39:41 -0000 Received: from va3ehsobe005.messaging.microsoft.com (HELO VA3EHSOBE005.bigfish.com) (216.32.180.31) by server-7.tower-174.messagelabs.com with AES128-SHA encrypted SMTP; 1 Sep 2011 08:39:41 -0000 Received: from mail38-va3-R.bigfish.com (10.7.14.251) by VA3EHSOBE005.bigfish.com (10.7.40.25) with Microsoft SMTP Server id 14.1.225.22; Thu, 1 Sep 2011 08:39:40 +0000 Received: from mail38-va3 (localhost.localdomain [127.0.0.1]) by mail38-va3-R.bigfish.com (Postfix) with ESMTP id 16D9B838074; Thu, 1 Sep 2011 08:39:40 +0000 (UTC) X-SpamScore: 1 X-BigFish: VPS1(zzzz1202hzzz32i668h839h64h) X-Spam-TCS-SCL: 3:0 X-Forefront-Antispam-Report: CIP:163.181.249.109; KIP:(null); UIP:(null); IPVD:NLI; H:ausb3twp02.amd.com; RD:none; EFVD:NLI Received: from mail38-va3 (localhost.localdomain [127.0.0.1]) by mail38-va3 (MessageSwitch) id 1314866172864984_7674; Thu, 1 Sep 2011 08:36:12 +0000 (UTC) Received: from VA3EHSMHS036.bigfish.com (unknown [10.7.14.246]) by mail38-va3.bigfish.com (Postfix) with ESMTP id 89EAD1A6004F; Thu, 1 Sep 2011 08:36:12 +0000 (UTC) Received: from ausb3twp02.amd.com (163.181.249.109) by VA3EHSMHS036.bigfish.com (10.7.99.46) with Microsoft SMTP Server id 14.1.225.22; Thu, 1 Sep 2011 08:36:08 +0000 X-WSS-ID: 0LQU584-02-BTK-02 X-M-MSG: Received: from sausexedgep01.amd.com (sausexedgep01-ext.amd.com [163.181.249.72]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by ausb3twp02.amd.com (Axway MailGate 3.8.1) with ESMTP id 26082C8007; Thu, 1 Sep 2011 03:36:03 -0500 (CDT) Received: from sausexhtp01.amd.com (163.181.3.165) by sausexedgep01.amd.com (163.181.36.54) with Microsoft SMTP Server (TLS) id 8.3.106.1; Thu, 1 Sep 2011 03:36:42 -0500 Received: from storexhtp02.amd.com (172.24.4.4) by sausexhtp01.amd.com (163.181.3.165) with Microsoft SMTP Server (TLS) id 8.3.83.0; Thu, 1 Sep 2011 03:36:04 -0500 Received: from rhodium.osrc.amd.com (165.204.15.173) by storexhtp02.amd.com (172.24.4.4) with Microsoft SMTP Server id 8.3.83.0; Thu, 1 Sep 2011 04:36:03 -0400 Message-ID: <4E5F43F2.6010601@amd.com> Date: Thu, 1 Sep 2011 10:36:02 +0200 From: Christoph Egger User-Agent: Mozilla/5.0 (X11; U; NetBSD amd64; en-US; rv:1.9.2.17) Gecko/20110523 Lightning/1.0b3pre Thunderbird/3.1.10 MIME-Version: 1.0 To: Ian Campbell , "xen-devel@lists.xensource.com" Content-Type: text/plain; charset="ISO-8859-15"; format=flowed Content-Transfer-Encoding: 7bit X-OriginatorOrg: amd.com Cc: Subject: [Xen-devel] cs 23453:4f4970d2848d beaks Win 7 X-BeenThere: xen-devel@lists.xensource.com X-Mailman-Version: 2.1.5 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xensource.com Errors-To: xen-devel-bounces@lists.xensource.com Hi Ian, cs 23453:4f4970d2848d breaks Win 7. It fails to initialize the CPUs as shown in the device manager and this causes a BSOD on shutdown. Christoph -- ---to satisfy European Law for business letters: Advanced Micro Devices GmbH Einsteinring 24, 85689 Dornach b. Muenchen Geschaeftsfuehrer: Alberto Bozzo, Andrew Bowd Sitz: Dornach, Gemeinde Aschheim, Landkreis Muenchen Registergericht Muenchen, HRB Nr. 43632 _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel From xen-devel-bounces@lists.xensource.com Thu Sep 01 01:41:18 2011 Return-path: Envelope-to: www-data@lists.xensource.com Delivery-date: Thu, 01 Sep 2011 01:41:18 -0700 Received: from localhost ([127.0.0.1] helo=lists.colo.xensource.com) by lists.xensource.com with esmtp (Exim 4.43) id 1Qz2pq-0001fG-4V; Thu, 01 Sep 2011 01:41:18 -0700 Received: from mail182.messagelabs.com ([85.158.139.83]) by lists.xensource.com with esmtp (Exim 4.43) id 1Qz2pK-0001Pn-QU for xen-devel@lists.xensource.com; Thu, 01 Sep 2011 01:40:47 -0700 X-Env-Sender: tim@xen.org X-Msg-Ref: server-5.tower-182.messagelabs.com!1314866443!11648183!1 X-Originating-IP: [81.29.64.94] X-StarScan-Version: 6.3.6; banners=-,-,- X-VirusChecked: Checked Received: (qmail 2316 invoked from network); 1 Sep 2011 08:40:43 -0000 Received: from ocelot.phlegethon.org (HELO mail.phlegethon.org) (81.29.64.94) by server-5.tower-182.messagelabs.com with DHE-RSA-AES256-SHA encrypted SMTP; 1 Sep 2011 08:40:43 -0000 Received: from tjd by mail.phlegethon.org with local (Exim 4.67 (FreeBSD)) (envelope-from ) id 1Qz2pF-00019U-He; Thu, 01 Sep 2011 08:40:41 +0000 Date: Thu, 1 Sep 2011 09:40:41 +0100 From: Tim Deegan To: Christoph Egger Subject: Re: [Xen-devel] [PATCH 01/04] p2m: use defines for page sizes rather hardcoding them Message-ID: <20110901084041.GB3859@ocelot.phlegethon.org> References: <4E57B184.8070601@amd.com> Mime-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline In-Reply-To: <4E57B184.8070601@amd.com> User-Agent: Mutt/1.4.2.1i Cc: "xen-devel@lists.xensource.com" , Tim Deegan X-BeenThere: xen-devel@lists.xensource.com X-Mailman-Version: 2.1.5 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xensource.com Errors-To: xen-devel-bounces@lists.xensource.com Content-Description: xen_superpage1.diff > use defines for page sizes rather hardcoding them. > > Signed-off-by: Christoph Egger Applied, thanks. Tim. -- Tim Deegan Principal Software Engineer, Xen Platform Team Citrix Systems UK Ltd. (Company #02937203, SL9 0BG) _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel From xen-devel-bounces@lists.xensource.com Thu Sep 01 01:42:11 2011 Return-path: Envelope-to: www-data@lists.xensource.com Delivery-date: Thu, 01 Sep 2011 01:42:11 -0700 Received: from localhost ([127.0.0.1] helo=lists.colo.xensource.com) by lists.xensource.com with esmtp (Exim 4.43) id 1Qz2qh-00022c-1R; Thu, 01 Sep 2011 01:42:11 -0700 Received: from mail182.messagelabs.com ([85.158.139.83]) by lists.xensource.com with esmtp (Exim 4.43) id 1Qz2q6-0001lE-B4 for xen-devel@lists.xensource.com; Thu, 01 Sep 2011 01:41:34 -0700 X-Env-Sender: dunlapg@gmail.com X-Msg-Ref: server-6.tower-182.messagelabs.com!1314866489!16624089!1 X-Originating-IP: [209.85.210.171] X-StarScan-Version: 6.3.6; banners=-,-,- X-VirusChecked: Checked Received: (qmail 17602 invoked from network); 1 Sep 2011 08:41:31 -0000 Received: from mail-iy0-f171.google.com (HELO mail-iy0-f171.google.com) (209.85.210.171) by server-6.tower-182.messagelabs.com with RC4-SHA encrypted SMTP; 1 Sep 2011 08:41:31 -0000 Received: by iagk10 with SMTP id k10so1968905iag.30 for ; Thu, 01 Sep 2011 01:41:29 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=rCJVMXxV98gTIKSr+PQ1ODuw+fS5Wjxnu/Dogo3RrNI=; b=otOJ5nkoIEvxb5+g3GpyLqIGoz6Ga4+RvZ0szxHHoBHeLIkpRkuOP5HpXdB/Z6a+CQ an9rmD/5Vik5DDXHS//t1RPWlPFMkPUPbq/Z6wu0WjdcI9o9h70xfqrpjlraK4lVQeUc HAOArOWcTo6ZWhIyTUNv7NYinTI+LDCgwmrLg= MIME-Version: 1.0 Received: by 10.42.156.71 with SMTP id y7mr1108233icw.425.1314866488214; Thu, 01 Sep 2011 01:41:28 -0700 (PDT) Received: by 10.42.153.197 with HTTP; Thu, 1 Sep 2011 01:41:28 -0700 (PDT) In-Reply-To: References: Date: Thu, 1 Sep 2011 09:41:28 +0100 X-Google-Sender-Auth: DoenSdXyvHKroEQgpu9oqBAB3L4 Message-ID: Subject: Re: [Xen-devel] A problem/suggestion about network ring buffer From: George Dunlap To: zhefu jiang , Paul Durrant Content-Type: text/plain; charset=GB2312 Content-Transfer-Encoding: quoted-printable Cc: xen-devel@lists.xensource.com X-BeenThere: xen-devel@lists.xensource.com X-Mailman-Version: 2.1.5 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xensource.com Errors-To: xen-devel-bounces@lists.xensource.com Paul, Were there any plans to address ring buffer size as part of the netchannel2 work? -George 2011/9/1 zhefu jiang : > Hi > Recently some observation suggests that Xen's one-page sized ring buffer = is > not suitable for 10GB Networking environment. Sending packet at that high > rate may cause the ring to overflow. So I'm now wondering that should we > provide some mechanism in future versions of Xen to make the ring size > configurable (such as passing the number of ring pages through xenbus)=A3= =BF > > -- > Best Wishes > ----------------------------------------------------------- > Jeff Jiang/Zhefu Jiang > > > _______________________________________________ > Xen-devel mailing list > Xen-devel@lists.xensource.com > http://lists.xensource.com/xen-devel > > _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel From xen-devel-bounces@lists.xensource.com Thu Sep 01 01:46:28 2011 Return-path: Envelope-to: www-data@lists.xensource.com Delivery-date: Thu, 01 Sep 2011 01:46:28 -0700 Received: from localhost ([127.0.0.1] helo=lists.colo.xensource.com) by lists.xensource.com with esmtp (Exim 4.43) id 1Qz2uq-0002TK-Mr; Thu, 01 Sep 2011 01:46:28 -0700 Received: from mail27.messagelabs.com ([193.109.254.147]) by lists.xensource.com with esmtp (Exim 4.43) id 1Qz2uM-0002HE-Vy for xen-devel@lists.xensource.com; Thu, 01 Sep 2011 01:45:59 -0700 X-Env-Sender: tim@xen.org X-Msg-Ref: server-4.tower-27.messagelabs.com!1314866740!41033666!1 X-Originating-IP: [81.29.64.94] X-StarScan-Version: 6.3.6; banners=-,-,- X-VirusChecked: Checked Received: (qmail 23668 invoked from network); 1 Sep 2011 08:45:40 -0000 Received: from ocelot.phlegethon.org (HELO mail.phlegethon.org) (81.29.64.94) by server-4.tower-27.messagelabs.com with DHE-RSA-AES256-SHA encrypted SMTP; 1 Sep 2011 08:45:40 -0000 Received: from tjd by mail.phlegethon.org with local (Exim 4.67 (FreeBSD)) (envelope-from ) id 1Qz2uH-0001As-Nt; Thu, 01 Sep 2011 08:45:53 +0000 Date: Thu, 1 Sep 2011 09:45:53 +0100 From: Tim Deegan To: Christoph Egger Subject: Re: [Xen-devel] [PATCH 01/04] p2m: use defines for page sizes rather hardcoding them Message-ID: <20110901084553.GC3859@ocelot.phlegethon.org> References: <4E57B184.8070601@amd.com> <20110901084041.GB3859@ocelot.phlegethon.org> Mime-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline In-Reply-To: <20110901084041.GB3859@ocelot.phlegethon.org> User-Agent: Mutt/1.4.2.1i Cc: "xen-devel@lists.xensource.com" , Tim Deegan X-BeenThere: xen-devel@lists.xensource.com X-Mailman-Version: 2.1.5 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xensource.com Errors-To: xen-devel-bounces@lists.xensource.com At 09:40 +0100 on 01 Sep (1314870041), Tim Deegan wrote: > Content-Description: xen_superpage1.diff > > use defines for page sizes rather hardcoding them. > > > > Signed-off-by: Christoph Egger > > Applied, thanks. The rest of this series looks OK in principle but I haven't time to look at the detail today (and I'm wondering whether there's a way of doing it without adding yet another argument to the p2m interfaces, but I suspect not). I'll get to it as soon as I can. Tim. _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel From xen-devel-bounces@lists.xensource.com Thu Sep 01 01:51:32 2011 Return-path: Envelope-to: www-data@lists.xensource.com Delivery-date: Thu, 01 Sep 2011 01:51:32 -0700 Received: from localhost ([127.0.0.1] helo=lists.colo.xensource.com) by lists.xensource.com with esmtp (Exim 4.43) id 1Qz2zj-0002vT-VY; Thu, 01 Sep 2011 01:51:31 -0700 Received: from mail174.messagelabs.com ([85.158.138.51]) by lists.xensource.com with smtp (Exim 4.43) id 1Qz2zJ-0002jb-RE for xen-devel@lists.xensource.com; Thu, 01 Sep 2011 01:51:06 -0700 X-Env-Sender: Ian.Campbell@eu.citrix.com X-Msg-Ref: server-12.tower-174.messagelabs.com!1314867059!29836608!1 X-Originating-IP: [62.200.22.115] X-StarScan-Version: 6.3.6; banners=-,-,- X-VirusChecked: Checked Received: (qmail 7307 invoked from network); 1 Sep 2011 08:51:02 -0000 Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115) by server-12.tower-174.messagelabs.com with SMTP; 1 Sep 2011 08:51:02 -0000 X-IronPort-AV: E=Sophos;i="4.68,312,1312156800"; d="scan'208";a="7547013" Received: from lonpmailmx01.citrite.net ([10.30.203.162]) by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5; 01 Sep 2011 08:50:58 +0000 Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net (10.30.203.162) with Microsoft SMTP Server id 8.3.137.0; Thu, 1 Sep 2011 09:50:58 +0100 From: Ian Campbell To: Christoph Egger In-Reply-To: <4E5F43F2.6010601@amd.com> References: <4E5F43F2.6010601@amd.com> Content-Type: text/plain; charset="UTF-8" Organization: Citrix Systems, Inc. Date: Thu, 1 Sep 2011 09:50:58 +0100 Message-ID: <1314867058.28989.84.camel@zakaz.uk.xensource.com> MIME-Version: 1.0 X-Mailer: Evolution 2.32.3 Content-Transfer-Encoding: 7bit Cc: "xen-devel@lists.xensource.com" Subject: [Xen-devel] Re: cs 23453:4f4970d2848d beaks Win 7 X-BeenThere: xen-devel@lists.xensource.com X-Mailman-Version: 2.1.5 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xensource.com Errors-To: xen-devel-bounces@lists.xensource.com On Thu, 2011-09-01 at 09:36 +0100, Christoph Egger wrote: > cs 23453:4f4970d2848d breaks Win 7. It fails to initialize the CPUs > as shown in the device manager and this causes a BSOD on shutdown. Are you 100% sure it's that cset? It moves a few things around but it doesn't actually remove anything. Ian. _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel From xen-devel-bounces@lists.xensource.com Thu Sep 01 02:07:28 2011 Return-path: Envelope-to: www-data@lists.xensource.com Delivery-date: Thu, 01 Sep 2011 02:07:28 -0700 Received: from localhost ([127.0.0.1] helo=lists.colo.xensource.com) by lists.xensource.com with esmtp (Exim 4.43) id 1Qz3FA-0004NC-Ks; Thu, 01 Sep 2011 02:07:28 -0700 Received: from mail216.messagelabs.com ([85.158.143.99]) by lists.xensource.com with esmtp (Exim 4.43) id 1Qz3BW-0003LH-9D for xen-devel@lists.xensource.com; Thu, 01 Sep 2011 02:03:45 -0700 X-Env-Sender: dunlapg@gmail.com X-Msg-Ref: server-11.tower-216.messagelabs.com!1314867818!9099141!1 X-Originating-IP: [209.85.161.171] X-StarScan-Version: 6.3.6; banners=-,-,- X-VirusChecked: Checked Received: (qmail 3799 invoked from network); 1 Sep 2011 09:03:39 -0000 Received: from mail-gx0-f171.google.com (HELO mail-gx0-f171.google.com) (209.85.161.171) by server-11.tower-216.messagelabs.com with RC4-SHA encrypted SMTP; 1 Sep 2011 09:03:39 -0000 Received: by gxk22 with SMTP id 22so1538183gxk.30 for ; Thu, 01 Sep 2011 02:03:37 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type; bh=9LWASKiKWTBWnu68ftfhqZanITvUiw3j2PRJNrLz7V0=; b=WTGP0i27r3H0c5vaxqv4Xtkhj4v7DUX8N8vmeF+tofiqsIcUxaA2JGRxPgtH7JpeG2 wnXOBvfFM+eHSNFEaCssFOrRWeDFE0O0JIMSHPDbf0IPtZ3Xh6E1+IXHuxT8K7NfJCRz iSze+gbinkzWKw+mzoeuM727XRjBkDXzp/lI0= MIME-Version: 1.0 Received: by 10.42.156.71 with SMTP id y7mr1123923icw.425.1314867817700; Thu, 01 Sep 2011 02:03:37 -0700 (PDT) Received: by 10.42.153.197 with HTTP; Thu, 1 Sep 2011 02:03:37 -0700 (PDT) In-Reply-To: <4E5E58AD.9060500@citrix.com> References: <4E5E58AD.9060500@citrix.com> Date: Thu, 1 Sep 2011 10:03:37 +0100 X-Google-Sender-Auth: Njvw41zxLuQAo1GRfjKwW1js3hw Message-ID: Subject: Re: [Xen-devel] Interrupt code cleanup [RFC] From: George Dunlap To: Andrew Cooper Content-Type: text/plain; charset=ISO-8859-1 Cc: "xen-devel@lists.xensource.com" , Keir Fraser X-BeenThere: xen-devel@lists.xensource.com X-Mailman-Version: 2.1.5 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xensource.com Errors-To: xen-devel-bounces@lists.xensource.com On Wed, Aug 31, 2011 at 4:52 PM, Andrew Cooper wrote: > Are there any areas people have noticed where the irq code is limited > and could be improved? The locking seems a bit strange too, and doesn't seem to be documented anywhere. For instance, in irq.c:__clear_irq_vector(), cfg->move_in_progress is protected by vector_lock. But in io_apic.c:send_cleanup_vector(), cfg->move_in_progress is read without any locks, and cfg->move_cleanup_count is written without any locks, or any memory barriers; but in smp_irq_move_cleanup_interrupt(), cfg->move_cleanup_count is protected by desc->lock. It may be that this is all OK and carefully thought out, but it's a bit hard to believe. And even if it were carefully thought out, if it's not either obvious or documented, at some point someone will make a change that breaks the delicately balanced invariants. I'm taking a look at that now... -George _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel From xen-devel-bounces@lists.xensource.com Thu Sep 01 02:10:09 2011 Return-path: Envelope-to: www-data@lists.xensource.com Delivery-date: Thu, 01 Sep 2011 02:10:09 -0700 Received: from localhost ([127.0.0.1] helo=lists.colo.xensource.com) by lists.xensource.com with esmtp (Exim 4.43) id 1Qz3Hl-0005T5-Jv; Thu, 01 Sep 2011 02:10:09 -0700 Received: from mail216.messagelabs.com ([85.158.143.99]) by lists.xensource.com with esmtp (Exim 4.43) id 1Qz3HI-0005GO-Jp for xen-devel@lists.xensource.com; Thu, 01 Sep 2011 02:09:41 -0700 X-Env-Sender: Christoph.Egger@amd.com X-Msg-Ref: server-8.tower-216.messagelabs.com!1314868102!15229568!1 X-Originating-IP: [216.32.181.181] X-StarScan-Version: 6.3.6; banners=-,-,- X-VirusChecked: Checked Received: (qmail 28493 invoked from network); 1 Sep 2011 09:08:23 -0000 Received: from ch1ehsobe001.messaging.microsoft.com (HELO ch1outboundpool.messaging.microsoft.com) (216.32.181.181) by server-8.tower-216.messagelabs.com with AES128-SHA encrypted SMTP; 1 Sep 2011 09:08:23 -0000 Received: from mail148-ch1-R.bigfish.com (216.32.181.172) by CH1EHSOBE011.bigfish.com (10.43.70.61) with Microsoft SMTP Server id 14.1.225.22; Thu, 1 Sep 2011 09:08:21 +0000 Received: from mail148-ch1 (localhost.localdomain [127.0.0.1]) by mail148-ch1-R.bigfish.com (Postfix) with ESMTP id 9B5001990558; Thu, 1 Sep 2011 09:08:21 +0000 (UTC) X-SpamScore: -14 X-BigFish: VPS-14(zzbb2dK936eK1432N98dKzz1202hzzz32i668h839h93fh61h) X-Spam-TCS-SCL: 0:0 X-Forefront-Antispam-Report: CIP:163.181.249.108; KIP:(null); UIP:(null); IPVD:NLI; H:ausb3twp01.amd.com; RD:none; EFVD:NLI Received: from mail148-ch1 (localhost.localdomain [127.0.0.1]) by mail148-ch1 (MessageSwitch) id 1314868101511901_21182; Thu, 1 Sep 2011 09:08:21 +0000 (UTC) Received: from CH1EHSMHS002.bigfish.com (snatpool1.int.messaging.microsoft.com [10.43.68.248]) by mail148-ch1.bigfish.com (Postfix) with ESMTP id 78881CF004B; Thu, 1 Sep 2011 09:08:21 +0000 (UTC) Received: from ausb3twp01.amd.com (163.181.249.108) by CH1EHSMHS002.bigfish.com (10.43.70.2) with Microsoft SMTP Server id 14.1.225.22; Thu, 1 Sep 2011 09:08:18 +0000 X-WSS-ID: 0LQU6PT-01-058-02 X-M-MSG: Received: from sausexedgep01.amd.com (sausexedgep01-ext.amd.com [163.181.249.72]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by ausb3twp01.amd.com (Axway MailGate 3.8.1) with ESMTP id 2A1FD1028477; Thu, 1 Sep 2011 04:08:16 -0500 (CDT) Received: from SAUSEXDAG03.amd.com (163.181.55.3) by sausexedgep01.amd.com (163.181.36.54) with Microsoft SMTP Server (TLS) id 8.3.106.1; Thu, 1 Sep 2011 04:08:55 -0500 Received: from storexhtp01.amd.com (172.24.4.3) by sausexdag03.amd.com (163.181.55.3) with Microsoft SMTP Server (TLS) id 14.1.289.1; Thu, 1 Sep 2011 04:08:16 -0500 Received: from rhodium.osrc.amd.com (165.204.15.173) by storexhtp01.amd.com (172.24.4.3) with Microsoft SMTP Server id 8.3.83.0; Thu, 1 Sep 2011 05:08:15 -0400 Message-ID: <4E5F4B7E.8090601@amd.com> Date: Thu, 1 Sep 2011 11:08:14 +0200 From: Christoph Egger User-Agent: Mozilla/5.0 (X11; U; NetBSD amd64; en-US; rv:1.9.2.17) Gecko/20110523 Lightning/1.0b3pre Thunderbird/3.1.10 MIME-Version: 1.0 To: Ian Campbell References: <4E5F43F2.6010601@amd.com> <1314867058.28989.84.camel@zakaz.uk.xensource.com> In-Reply-To: <1314867058.28989.84.camel@zakaz.uk.xensource.com> Content-Type: text/plain; charset="UTF-8"; format=flowed Content-Transfer-Encoding: 7bit X-OriginatorOrg: amd.com Cc: "xen-devel@lists.xensource.com" Subject: [Xen-devel] Re: cs 23453:4f4970d2848d beaks Win 7 X-BeenThere: xen-devel@lists.xensource.com X-Mailman-Version: 2.1.5 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xensource.com Errors-To: xen-devel-bounces@lists.xensource.com On 09/01/11 10:50, Ian Campbell wrote: > On Thu, 2011-09-01 at 09:36 +0100, Christoph Egger wrote: >> cs 23453:4f4970d2848d breaks Win 7. It fails to initialize the CPUs >> as shown in the device manager and this causes a BSOD on shutdown. > > Are you 100% sure it's that cset? Yes, I am. I found that c/s by bisecting. I used the latest xen-kernel and toolchain, just replaced the hvmloader binary and booted a Win7 guest (both 32bit and 64bit) with one vcpu. An hvmloader binary built from c/s 23452 works. BTW: I use the rombios. > It moves a few things around but it doesn't actually remove anything. From a first glance, bios_info_setup() is called earlier with this c/s. Christoph -- ---to satisfy European Law for business letters: Advanced Micro Devices GmbH Einsteinring 24, 85689 Dornach b. Muenchen Geschaeftsfuehrer: Alberto Bozzo, Andrew Bowd Sitz: Dornach, Gemeinde Aschheim, Landkreis Muenchen Registergericht Muenchen, HRB Nr. 43632 _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel From xen-devel-bounces@lists.xensource.com Thu Sep 01 02:33:22 2011 Return-path: Envelope-to: www-data@lists.xensource.com Delivery-date: Thu, 01 Sep 2011 02:33:22 -0700 Received: from localhost ([127.0.0.1] helo=lists.colo.xensource.com) by lists.xensource.com with esmtp (Exim 4.43) id 1Qz3eD-0006MF-Dt; Thu, 01 Sep 2011 02:33:22 -0700 Received: from mail21.messagelabs.com ([85.158.143.35]) by lists.xensource.com with smtp (Exim 4.43) id 1Qz3dR-00069g-Lr for xen-devel@lists.xensource.com; Thu, 01 Sep 2011 02:32:33 -0700 X-Env-Sender: Ian.Campbell@eu.citrix.com X-Msg-Ref: server-15.tower-21.messagelabs.com!1314869551!48939089!1 X-Originating-IP: [62.200.22.115] X-StarScan-Version: 6.3.6; banners=-,-,- X-VirusChecked: Checked Received: (qmail 18668 invoked from network); 1 Sep 2011 09:32:31 -0000 Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115) by server-15.tower-21.messagelabs.com with SMTP; 1 Sep 2011 09:32:31 -0000 X-IronPort-AV: E=Sophos;i="4.68,312,1312156800"; d="scan'208";a="7548199" Received: from lonpmailmx01.citrite.net ([10.30.203.162]) by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5; 01 Sep 2011 09:32:30 +0000 Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net (10.30.203.162) with Microsoft SMTP Server id 8.3.137.0; Thu, 1 Sep 2011 10:32:30 +0100 From: Ian Campbell To: Christoph Egger In-Reply-To: <4E5F4B7E.8090601@amd.com> References: <4E5F43F2.6010601@amd.com> <1314867058.28989.84.camel@zakaz.uk.xensource.com> <4E5F4B7E.8090601@amd.com> Content-Type: text/plain; charset="UTF-8" Organization: Citrix Systems, Inc. Date: Thu, 1 Sep 2011 10:32:29 +0100 Message-ID: <1314869549.28989.86.camel@zakaz.uk.xensource.com> MIME-Version: 1.0 X-Mailer: Evolution 2.32.3 Content-Transfer-Encoding: 7bit Cc: "xen-devel@lists.xensource.com" Subject: [Xen-devel] Re: cs 23453:4f4970d2848d beaks Win 7 X-BeenThere: xen-devel@lists.xensource.com X-Mailman-Version: 2.1.5 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xensource.com Errors-To: xen-devel-bounces@lists.xensource.com On Thu, 2011-09-01 at 10:08 +0100, Christoph Egger wrote: > On 09/01/11 10:50, Ian Campbell wrote: > > On Thu, 2011-09-01 at 09:36 +0100, Christoph Egger wrote: > >> cs 23453:4f4970d2848d breaks Win 7. It fails to initialize the CPUs > >> as shown in the device manager and this causes a BSOD on shutdown. > > > > Are you 100% sure it's that cset? > > Yes, I am. I found that c/s by bisecting. I used the latest xen-kernel > and toolchain, just replaced the hvmloader binary and booted a > Win7 guest (both 32bit and 64bit) with one vcpu. > > An hvmloader binary built from c/s 23452 works. > BTW: I use the rombios. > > > It moves a few things around but it doesn't actually remove anything. > > From a first glance, bios_info_setup() is called earlier with this c/s. I guess something could be clobbering that datastructure but there isn't much of interest in it now anyway. This stuff has subsequently been reorganised even more and moved around etc. I presume it is broken even for xen-unstable.hg 23809:85b29185c911? I'll see if I can repro. Can you post your guest cfg file please? Ian. _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel From xen-devel-bounces@lists.xensource.com Thu Sep 01 02:45:49 2011 Return-path: Envelope-to: www-data@lists.xensource.com Delivery-date: Thu, 01 Sep 2011 02:45:49 -0700 Received: from localhost ([127.0.0.1] helo=lists.colo.xensource.com) by lists.xensource.com with esmtp (Exim 4.43) id 1Qz3qG-0007bx-Tb; Thu, 01 Sep 2011 02:45:49 -0700 Received: from mail182.messagelabs.com ([85.158.139.83]) by lists.xensource.com with esmtp (Exim 4.43) id 1Qz3pi-0007Q5-6V for xen-devel@lists.xensource.com; Thu, 01 Sep 2011 02:45:15 -0700 X-Env-Sender: Christoph.Egger@amd.com X-Msg-Ref: server-5.tower-182.messagelabs.com!1314870309!11659258!1 X-Originating-IP: [65.55.88.14] X-StarScan-Version: 6.3.6; banners=-,-,- X-VirusChecked: Checked Received: (qmail 31481 invoked from network); 1 Sep 2011 09:45:11 -0000 Received: from tx2ehsobe004.messaging.microsoft.com (HELO TX2EHSOBE009.bigfish.com) (65.55.88.14) by server-5.tower-182.messagelabs.com with AES128-SHA encrypted SMTP; 1 Sep 2011 09:45:11 -0000 Received: from mail79-tx2-R.bigfish.com (10.9.14.241) by TX2EHSOBE009.bigfish.com (10.9.40.29) with Microsoft SMTP Server id 14.1.225.22; Thu, 1 Sep 2011 09:45:09 +0000 Received: from mail79-tx2 (localhost.localdomain [127.0.0.1]) by mail79-tx2-R.bigfish.com (Postfix) with ESMTP id A6CEA1101C3; Thu, 1 Sep 2011 09:45:09 +0000 (UTC) X-SpamScore: -14 X-BigFish: VPS-14(zzbb2dK936eK1432N98dKzz1202hzzz32i668h839h93fh61h) X-Spam-TCS-SCL: 0:0 X-Forefront-Antispam-Report: CIP:163.181.249.109; KIP:(null); UIP:(null); IPVD:NLI; H:ausb3twp02.amd.com; RD:none; EFVD:NLI Received: from mail79-tx2 (localhost.localdomain [127.0.0.1]) by mail79-tx2 (MessageSwitch) id 1314870309446785_19921; Thu, 1 Sep 2011 09:45:09 +0000 (UTC) Received: from TX2EHSMHS046.bigfish.com (unknown [10.9.14.248]) by mail79-tx2.bigfish.com (Postfix) with ESMTP id 5DAE2120004D; Thu, 1 Sep 2011 09:45:09 +0000 (UTC) Received: from ausb3twp02.amd.com (163.181.249.109) by TX2EHSMHS046.bigfish.com (10.9.99.146) with Microsoft SMTP Server id 14.1.225.22; Thu, 1 Sep 2011 09:45:09 +0000 X-WSS-ID: 0LQU8F7-02-1LA-02 X-M-MSG: Received: from sausexedgep02.amd.com (sausexedgep02-ext.amd.com [163.181.249.73]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by ausb3twp02.amd.com (Axway MailGate 3.8.1) with ESMTP id 2F01FC8011; Thu, 1 Sep 2011 04:45:06 -0500 (CDT) Received: from sausexhtp02.amd.com (163.181.3.152) by sausexedgep02.amd.com (163.181.36.59) with Microsoft SMTP Server (TLS) id 8.3.106.1; Thu, 1 Sep 2011 04:45:46 -0500 Received: from storexhtp01.amd.com (172.24.4.3) by sausexhtp02.amd.com (163.181.3.152) with Microsoft SMTP Server (TLS) id 8.3.83.0; Thu, 1 Sep 2011 04:45:07 -0500 Received: from rhodium.osrc.amd.com (165.204.15.173) by storexhtp01.amd.com (172.24.4.3) with Microsoft SMTP Server id 8.3.83.0; Thu, 1 Sep 2011 05:45:06 -0400 Message-ID: <4E5F541F.6010405@amd.com> Date: Thu, 1 Sep 2011 11:45:03 +0200 From: Christoph Egger User-Agent: Mozilla/5.0 (X11; U; NetBSD amd64; en-US; rv:1.9.2.17) Gecko/20110523 Lightning/1.0b3pre Thunderbird/3.1.10 MIME-Version: 1.0 To: Ian Campbell Subject: Re: [Xen-devel] Re: cs 23453:4f4970d2848d beaks Win 7 References: <4E5F43F2.6010601@amd.com> <1314867058.28989.84.camel@zakaz.uk.xensource.com> <4E5F4B7E.8090601@amd.com> <1314869549.28989.86.camel@zakaz.uk.xensource.com> In-Reply-To: <1314869549.28989.86.camel@zakaz.uk.xensource.com> Content-Type: text/plain; charset="UTF-8"; format=flowed Content-Transfer-Encoding: 7bit X-OriginatorOrg: amd.com Cc: "xen-devel@lists.xensource.com" X-BeenThere: xen-devel@lists.xensource.com X-Mailman-Version: 2.1.5 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xensource.com Errors-To: xen-devel-bounces@lists.xensource.com On 09/01/11 11:32, Ian Campbell wrote: > On Thu, 2011-09-01 at 10:08 +0100, Christoph Egger wrote: >> On 09/01/11 10:50, Ian Campbell wrote: >>> On Thu, 2011-09-01 at 09:36 +0100, Christoph Egger wrote: >>>> cs 23453:4f4970d2848d breaks Win 7. It fails to initialize the CPUs >>>> as shown in the device manager and this causes a BSOD on shutdown. >>> >>> Are you 100% sure it's that cset? >> >> Yes, I am. I found that c/s by bisecting. I used the latest xen-kernel >> and toolchain, just replaced the hvmloader binary and booted a >> Win7 guest (both 32bit and 64bit) with one vcpu. >> >> An hvmloader binary built from c/s 23452 works. >> BTW: I use the rombios. >> >> > It moves a few things around but it doesn't actually remove anything. >> >> From a first glance, bios_info_setup() is called earlier with this c/s. > > I guess something could be clobbering that datastructure but there isn't > much of interest in it now anyway. This stuff has subsequently been > reorganised even more and moved around etc. I presume it is broken even > for xen-unstable.hg 23809:85b29185c911? Yes, it is. > I'll see if I can repro. Can you post your guest cfg file please? builder="hvm" memory=2048 name="win7" vcpus=1 acpi=1 apic=1 vif = [ 'type=ioemu, model=e1000' ] disk = [ 'file:/hvm-guest/win7.img,ioemu:hda,w' ] sdl=0 vnc=1 stdvga=1 usb=1 usbdevice='tablet' -- ---to satisfy European Law for business letters: Advanced Micro Devices GmbH Einsteinring 24, 85689 Dornach b. Muenchen Geschaeftsfuehrer: Alberto Bozzo, Andrew Bowd Sitz: Dornach, Gemeinde Aschheim, Landkreis Muenchen Registergericht Muenchen, HRB Nr. 43632 _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel From xen-devel-bounces@lists.xensource.com Thu Sep 01 02:47:27 2011 Return-path: Envelope-to: www-data@lists.xensource.com Delivery-date: Thu, 01 Sep 2011 02:47:27 -0700 Received: from localhost ([127.0.0.1] helo=lists.colo.xensource.com) by lists.xensource.com with esmtp (Exim 4.43) id 1Qz3rr-00081y-SW; Thu, 01 Sep 2011 02:47:27 -0700 Received: from mail216.messagelabs.com ([85.158.143.99]) by lists.xensource.com with smtp (Exim 4.43) id 1Qz3rM-0007pY-17 for xen-devel@lists.xensource.com; Thu, 01 Sep 2011 02:47:00 -0700 X-Env-Sender: andreas.olsowski@leuphana.de X-Msg-Ref: server-4.tower-216.messagelabs.com!1314870412!16670041!1 X-Originating-IP: [193.174.46.71] X-StarScan-Version: 6.3.6; banners=-,-,- X-VirusChecked: Checked Received: (qmail 23554 invoked from network); 1 Sep 2011 09:46:52 -0000 Received: from mailhost.leuphana.de (HELO leuphana.de) (193.174.46.71) by server-4.tower-216.messagelabs.com with SMTP; 1 Sep 2011 09:46:52 -0000 Received: from [141.39.215.216] (account aolsowsk@leuphana.de [141.39.215.216] verified) by leuphana.de (CommuniGate Pro SMTP 5.4.1e) with ESMTPSA id 44752587 for xen-devel@lists.xensource.com; Thu, 01 Sep 2011 11:46:52 +0200 Message-ID: <4E5F548B.1010602@leuphana.de> Date: Thu, 01 Sep 2011 11:46:51 +0200 From: Andreas Olsowski User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.2.18) Gecko/20110626 Icedove/3.1.11 MIME-Version: 1.0 To: xen-devel@lists.xensource.com Subject: Re: [Xen-devel] [Xen-deve] xen/stable-2.6.32.x bare-metal: panic early exception 0e rip 10:0 error 10 cr2 0 References: <4E4D9A90.30800@leuphana.de> In-Reply-To: X-BeenThere: xen-devel@lists.xensource.com X-Mailman-Version: 2.1.5 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1115811912==" Sender: xen-devel-bounces@lists.xensource.com Errors-To: xen-devel-bounces@lists.xensource.com This is a cryptographically signed message in MIME format. --===============1115811912== Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha1; boundary="------------ms020404000701080402050906" This is a cryptographically signed message in MIME format. --------------ms020404000701080402050906 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: quoted-printable > I am seeing this as well. I have been trying to narrow it down a bit, > and it seems to me that the bug was introduced somewhere between > xen-2.6.32.39 and xen-2.6.32.42. Sounds realistic, i did test 42-45. I will try to find the time to narrow it down to one exact version this=20 weekend. --=20 Andreas Olsowski Leuphana Universit=E4t L=FCneburg Rechen- und Medienzentrum Scharnhorststra=DFe 1, C7.015 21335 L=FCneburg Tel: ++49 4131 677 1309 --------------ms020404000701080402050906 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIU3TCC BCEwggMJoAMCAQICAgDHMA0GCSqGSIb3DQEBBQUAMHExCzAJBgNVBAYTAkRFMRwwGgYDVQQK ExNEZXV0c2NoZSBUZWxla29tIEFHMR8wHQYDVQQLExZULVRlbGVTZWMgVHJ1c3QgQ2VudGVy MSMwIQYDVQQDExpEZXV0c2NoZSBUZWxla29tIFJvb3QgQ0EgMjAeFw0wNjEyMTkxMDI5MDBa Fw0xOTA2MzAyMzU5MDBaMFoxCzAJBgNVBAYTAkRFMRMwEQYDVQQKEwpERk4tVmVyZWluMRAw DgYDVQQLEwdERk4tUEtJMSQwIgYDVQQDExtERk4tVmVyZWluIFBDQSBHbG9iYWwgLSBHMDEw ggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQDpm8NnhfkNrvWNVMOWUDU9YuluTO2U 1wBblSJ01CDrNI/W7MAxBAuZgeKmFNJSoCgjhIt0iQReW+DieMF4yxbLKDU5ey2QRdDtoAB6 fL9KDhsAw4bpXCsxEXsM84IkQ4wcOItqaACa7txPeKvSxhObdq3u3ibo7wGvdA/BCaL2a869 080UME/15eOkyGKbghoDJzANAmVgTe3RCSMqljVYJ9N2xnG2kB3E7f81hn1vM7PbD8URwoqD oZRdQWvY0hD1TP3KUazZve+Sg7va64sWVlZDz+HVEz2mHycwzUlU28kTNJpxdcVs6qcLmPkh nSevPqM5OUhqjK3JmfvDEvK9AgMBAAGjgdkwgdYwcAYDVR0fBGkwZzBloGOgYYZfaHR0cDov L3BraS50ZWxlc2VjLmRlL2NnaS1iaW4vc2VydmljZS9hZl9Eb3dubG9hZEFSTC5jcmw/LWNy bF9mb3JtYXQ9WF81MDkmLWlzc3Vlcj1EVF9ST09UX0NBXzIwHQYDVR0OBBYEFEm3xs/oPR9/ 6kR7Eyn38QpwPt5kMB8GA1UdIwQYMBaAFDHDeRu69VPXF+CJei0XbAqzK50zMA4GA1UdDwEB /wQEAwIBBjASBgNVHRMBAf8ECDAGAQH/AgECMA0GCSqGSIb3DQEBBQUAA4IBAQA74Vp3wEgX 3KkY7IGvWonwvSiSpspZGBJw7Cjy565/lizn8l0ZMfYTK3S9vYCyufdnyTmieTvhERHua3iR M347XyYndVNljjNj7s9zw7CSI0khUHUjoR8Y4pSFPT8z6XcgjaK95qGFKUD2P3MyWA0Ja6ba hWzAP7uNZmRWJE6uDT8yNQFb6YyC2XJZT7GGhfF0hVblw/hc843uR7NTBXDn5U2KaYMo4RMJ hp5eyOpYHgwf+aTUWgRo/Sg+iwK2WLX2oSw3VwBnqyNojWOl75lrXP1LVvarQIc01BGSbOyH xQoLBzNytG8MHVQs2FHHzL8w00Ny8TK/jM5JY6gA9/IcMIIFXjCCBEagAwIBAgIEC8pR1jAN BgkqhkiG9w0BAQUFADBaMQswCQYDVQQGEwJERTETMBEGA1UEChMKREZOLVZlcmVpbjEQMA4G A1UECxMHREZOLVBLSTEkMCIGA1UEAxMbREZOLVZlcmVpbiBQQ0EgR2xvYmFsIC0gRzAxMB4X DTA4MDIwNzA5NTAwMFoXDTE5MDYzMDAwMDAwMFowgdMxCzAJBgNVBAYTAkRFMRYwFAYDVQQI Ew1OaWVkZXJzYWNoc2VuMRIwEAYDVQQHEwlMdWVuZWJ1cmcxKDAmBgNVBAoTH0xldXBoYW5h IFVuaXZlcnNpdGFldCBMdWVuZWJ1cmcxIjAgBgNVBAsTGVJlY2hlbi0gdW5kIE1lZGllbnpl bnRydW0xKzApBgNVBAMTIkxldXBoYW5hIFVuaXZlcnNpdGFldCBMdWVuZWJ1cmcgQ0ExHTAb BgkqhkiG9w0BCQEWDmNhQGxldXBoYW5hLmRlMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIB CgKCAQEAqJ+JpHih32+icKiQ2IkbhmFLjAcnK0vrnyOKbn7+1xywhvL3zkraqhQlrqEltTDy 711vIEadOVfhIx8xZYYJ/zg1OCwKUxNbIbjcsIFiOKNbWxI3/yMOsaZpXsCLW7GfHLlLADW1 Cv2gUAdnjJUATcUF3a25Bgr9Lbv+GI+3bY9ydMkGnhFYSL96LLqLxAXzGXL/MAM5t/xK8cc8 +6+mWxHAqO+85Jn+UvS1khVTtZfACrYZKFnAsVHOMM/WRugohq4ue6Jfp65exMM7HKWNPrKn UV0hotcInKFBYywcZrIa2r/6m63nOxl1gHrewxiFWEBvpgMkQ+a7PHhXsMkPdQIDAQABo4IB sDCCAawwEgYDVR0TAQH/BAgwBgEB/wIBATALBgNVHQ8EBAMCAQYwHQYDVR0OBBYEFPThaBk7 GUPHATbRNGKW8/UDoQeMMB8GA1UdIwQYMBaAFEm3xs/oPR9/6kR7Eyn38QpwPt5kMBkGA1Ud EQQSMBCBDmNhQGxldXBoYW5hLmRlMIGIBgNVHR8EgYAwfjA9oDugOYY3aHR0cDovL2NkcDEu cGNhLmRmbi5kZS9nbG9iYWwtcm9vdC1jYS9wdWIvY3JsL2NhY3JsLmNybDA9oDugOYY3aHR0 cDovL2NkcDIucGNhLmRmbi5kZS9nbG9iYWwtcm9vdC1jYS9wdWIvY3JsL2NhY3JsLmNybDCB ogYIKwYBBQUHAQEEgZUwgZIwRwYIKwYBBQUHMAKGO2h0dHA6Ly9jZHAxLnBjYS5kZm4uZGUv Z2xvYmFsLXJvb3QtY2EvcHViL2NhY2VydC9jYWNlcnQuY3J0MEcGCCsGAQUFBzAChjtodHRw Oi8vY2RwMi5wY2EuZGZuLmRlL2dsb2JhbC1yb290LWNhL3B1Yi9jYWNlcnQvY2FjZXJ0LmNy dDANBgkqhkiG9w0BAQUFAAOCAQEAmSFLUEnTM1zmNRfF4TTDRB53iHmBY0OYTlaPJvXXy4f7 jc1Dpz00HiVyFohY9gqo+jbIAm5avSCmhbL9glEWubE/BNZz9l9lyTCMMxFES0TCiC6W86Ev o9E4C5IEqxZAOlvRyM3w3u8ItBO9cG190/XMi1Ouk3iBfwRVvFINy9Favq+/8HWFwkFrphpy 6JR90AbbjtE7b7owcMxusgFtPi8A1uyc3cpR21f51K7qgmGbsyXso+U9c/8Fak0IM0qQTN7p GPmI1lfJ0x1r/QusHVYSFojAT2vQamfGeCNVELg/gH4tlTGkDbHW5QhInkASQv4obBYewNfR rLG4wgPz5TCCBacwggSPoAMCAQICBBDuKTAwDQYJKoZIhvcNAQEFBQAwgdMxCzAJBgNVBAYT AkRFMRYwFAYDVQQIEw1OaWVkZXJzYWNoc2VuMRIwEAYDVQQHEwlMdWVuZWJ1cmcxKDAmBgNV BAoTH0xldXBoYW5hIFVuaXZlcnNpdGFldCBMdWVuZWJ1cmcxIjAgBgNVBAsTGVJlY2hlbi0g dW5kIE1lZGllbnplbnRydW0xKzApBgNVBAMTIkxldXBoYW5hIFVuaXZlcnNpdGFldCBMdWVu ZWJ1cmcgQ0ExHTAbBgkqhkiG9w0BCQEWDmNhQGxldXBoYW5hLmRlMB4XDTEwMTEwMTExNTky OVoXDTEzMTAzMTExNTkyOVowajELMAkGA1UEBhMCREUxKDAmBgNVBAoTH0xldXBoYW5hIFVu aXZlcnNpdGFldCBMdWVuZWJ1cmcxFjAUBgNVBAsTDVJlY2hlbnplbnRydW0xGTAXBgNVBAMT EEFuZHJlYXMgT2xzb3dza2kwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQDBzfnZ 7pbsecrmresa6JNTMmgoBFpwyr7k7U5O+j7QlFvMlePF/Tz7TeULaEevf7H68IiA/6oGZQvg NReD/64PYXxbKfsJydY6W1K+jq2karofhW5bk5p210DEQv4qyV6M+aJRKxW0Hp32OeLk5QUH 9T2780PELXGn222r+NCSmBKLP0MHsUa6CFI+jRqztB60v+wc9TD6crMEB37ddckq7mS3QWk1 m2/68bmCsHWRLTpWn9hT4S8eBSL/3YLR9DF8kfWl0wEgy8/tJY1nz5IlSI3S2v1ys7rwXBAp YHRpeHM/WNNNV4kiH09g2vlxFebQN0xTyoO1+PX6iPeAh0NbAgMBAAGjggHpMIIB5TAJBgNV HRMEAjAAMAsGA1UdDwQEAwIF4DApBgNVHSUEIjAgBggrBgEFBQcDAgYIKwYBBQUHAwQGCisG AQQBgjcUAgIwHQYDVR0OBBYEFMrca499fLnPczMLjRm2Nck06YCyMB8GA1UdIwQYMBaAFPTh aBk7GUPHATbRNGKW8/UDoQeMMCcGA1UdEQQgMB6BHGFuZHJlYXMub2xzb3dza2lAbGV1cGhh bmEuZGUwgY0GA1UdHwSBhTCBgjA/oD2gO4Y5aHR0cDovL2NkcDEucGNhLmRmbi5kZS91bmkt bHVlbmVidXJnLWNhL3B1Yi9jcmwvY2FjcmwuY3JsMD+gPaA7hjlodHRwOi8vY2RwMi5wY2Eu ZGZuLmRlL3VuaS1sdWVuZWJ1cmctY2EvcHViL2NybC9jYWNybC5jcmwwgaYGCCsGAQUFBwEB BIGZMIGWMEkGCCsGAQUFBzAChj1odHRwOi8vY2RwMS5wY2EuZGZuLmRlL3VuaS1sdWVuZWJ1 cmctY2EvcHViL2NhY2VydC9jYWNlcnQuY3J0MEkGCCsGAQUFBzAChj1odHRwOi8vY2RwMi5w Y2EuZGZuLmRlL3VuaS1sdWVuZWJ1cmctY2EvcHViL2NhY2VydC9jYWNlcnQuY3J0MA0GCSqG SIb3DQEBBQUAA4IBAQANa3ZG/UAmpRcAXqOFOKXBfzN9vZilIdAUxSaXzN9gmXBNptDEcLfD ccoA228Qc0BSdpvqMdE/21ahqE6oYI1CTfqbuYdoi/cmGoXo6+MdKCKxAD9LokkHdZFhr8re NrsVkqxyY++Cek777HKZWn1Ft9864LA6vDar3K/sUHlBNxO6VhVzt09NQIFrA50lCkNd6iCG 7Hji624SI49aWjzysBOBdcP68tzSYM+nJLod1NZ3S/W3v+IlPlMeu1JZ5hRnzoTC5qHKKdoQ kwSmQmv8/uXD46TXutmLXxH3SyBUIM4ks6RN8+VbJ9+61nOQjtazZzvgz9cnYquQC9Dm2s+q MIIFpzCCBI+gAwIBAgIEEO4pMDANBgkqhkiG9w0BAQUFADCB0zELMAkGA1UEBhMCREUxFjAU BgNVBAgTDU5pZWRlcnNhY2hzZW4xEjAQBgNVBAcTCUx1ZW5lYnVyZzEoMCYGA1UEChMfTGV1 cGhhbmEgVW5pdmVyc2l0YWV0IEx1ZW5lYnVyZzEiMCAGA1UECxMZUmVjaGVuLSB1bmQgTWVk aWVuemVudHJ1bTErMCkGA1UEAxMiTGV1cGhhbmEgVW5pdmVyc2l0YWV0IEx1ZW5lYnVyZyBD QTEdMBsGCSqGSIb3DQEJARYOY2FAbGV1cGhhbmEuZGUwHhcNMTAxMTAxMTE1OTI5WhcNMTMx MDMxMTE1OTI5WjBqMQswCQYDVQQGEwJERTEoMCYGA1UEChMfTGV1cGhhbmEgVW5pdmVyc2l0 YWV0IEx1ZW5lYnVyZzEWMBQGA1UECxMNUmVjaGVuemVudHJ1bTEZMBcGA1UEAxMQQW5kcmVh cyBPbHNvd3NraTCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAMHN+dnulux5yuat 6xrok1MyaCgEWnDKvuTtTk76PtCUW8yV48X9PPtN5QtoR69/sfrwiID/qgZlC+A1F4P/rg9h fFsp+wnJ1jpbUr6OraRquh+FbluTmnbXQMRC/irJXoz5olErFbQenfY54uTlBQf1PbvzQ8Qt cafbbav40JKYEos/QwexRroIUj6NGrO0HrS/7Bz1MPpyswQHft11ySruZLdBaTWbb/rxuYKw dZEtOlaf2FPhLx4FIv/dgtH0MXyR9aXTASDLz+0ljWfPkiVIjdLa/XKzuvBcEClgdGl4cz9Y 001XiSIfT2Da+XEV5tA3TFPKg7X49fqI94CHQ1sCAwEAAaOCAekwggHlMAkGA1UdEwQCMAAw CwYDVR0PBAQDAgXgMCkGA1UdJQQiMCAGCCsGAQUFBwMCBggrBgEFBQcDBAYKKwYBBAGCNxQC AjAdBgNVHQ4EFgQUytxrj318uc9zMwuNGbY1yTTpgLIwHwYDVR0jBBgwFoAU9OFoGTsZQ8cB NtE0Ypbz9QOhB4wwJwYDVR0RBCAwHoEcYW5kcmVhcy5vbHNvd3NraUBsZXVwaGFuYS5kZTCB jQYDVR0fBIGFMIGCMD+gPaA7hjlodHRwOi8vY2RwMS5wY2EuZGZuLmRlL3VuaS1sdWVuZWJ1 cmctY2EvcHViL2NybC9jYWNybC5jcmwwP6A9oDuGOWh0dHA6Ly9jZHAyLnBjYS5kZm4uZGUv dW5pLWx1ZW5lYnVyZy1jYS9wdWIvY3JsL2NhY3JsLmNybDCBpgYIKwYBBQUHAQEEgZkwgZYw SQYIKwYBBQUHMAKGPWh0dHA6Ly9jZHAxLnBjYS5kZm4uZGUvdW5pLWx1ZW5lYnVyZy1jYS9w dWIvY2FjZXJ0L2NhY2VydC5jcnQwSQYIKwYBBQUHMAKGPWh0dHA6Ly9jZHAyLnBjYS5kZm4u ZGUvdW5pLWx1ZW5lYnVyZy1jYS9wdWIvY2FjZXJ0L2NhY2VydC5jcnQwDQYJKoZIhvcNAQEF BQADggEBAA1rdkb9QCalFwBeo4U4pcF/M329mKUh0BTFJpfM32CZcE2m0MRwt8NxygDbbxBz QFJ2m+ox0T/bVqGoTqhgjUJN+pu5h2iL9yYahejr4x0oIrEAP0uiSQd1kWGvyt42uxWSrHJj 74J6TvvscplafUW33zrgsDq8Nqvcr+xQeUE3E7pWFXO3T01AgWsDnSUKQ13qIIbseOLrbhIj j1paPPKwE4F1w/ry3NJgz6ckuh3U1ndL9be/4iU+Ux67UlnmFGfOhMLmocop2hCTBKZCa/z+ 5cPjpNe62YtfEfdLIFQgziSzpE3z5Vsn37rWc5CO1rNnO+DP1ydiq5AL0Obaz6oxggSoMIIE pAIBATCB3DCB0zELMAkGA1UEBhMCREUxFjAUBgNVBAgTDU5pZWRlcnNhY2hzZW4xEjAQBgNV BAcTCUx1ZW5lYnVyZzEoMCYGA1UEChMfTGV1cGhhbmEgVW5pdmVyc2l0YWV0IEx1ZW5lYnVy ZzEiMCAGA1UECxMZUmVjaGVuLSB1bmQgTWVkaWVuemVudHJ1bTErMCkGA1UEAxMiTGV1cGhh bmEgVW5pdmVyc2l0YWV0IEx1ZW5lYnVyZyBDQTEdMBsGCSqGSIb3DQEJARYOY2FAbGV1cGhh bmEuZGUCBBDuKTAwCQYFKw4DAhoFAKCCAqAwGAYJKoZIhvcNAQkDMQsGCSqGSIb3DQEHATAc BgkqhkiG9w0BCQUxDxcNMTEwOTAxMDk0NjUxWjAjBgkqhkiG9w0BCQQxFgQUJ0qFSLNC8wvy nZ9ShVLrOMGMuwgwXwYJKoZIhvcNAQkPMVIwUDALBglghkgBZQMEAQIwCgYIKoZIhvcNAwcw DgYIKoZIhvcNAwICAgCAMA0GCCqGSIb3DQMCAgFAMAcGBSsOAwIHMA0GCCqGSIb3DQMCAgEo MIHtBgkrBgEEAYI3EAQxgd8wgdwwgdMxCzAJBgNVBAYTAkRFMRYwFAYDVQQIEw1OaWVkZXJz YWNoc2VuMRIwEAYDVQQHEwlMdWVuZWJ1cmcxKDAmBgNVBAoTH0xldXBoYW5hIFVuaXZlcnNp dGFldCBMdWVuZWJ1cmcxIjAgBgNVBAsTGVJlY2hlbi0gdW5kIE1lZGllbnplbnRydW0xKzAp BgNVBAMTIkxldXBoYW5hIFVuaXZlcnNpdGFldCBMdWVuZWJ1cmcgQ0ExHTAbBgkqhkiG9w0B CQEWDmNhQGxldXBoYW5hLmRlAgQQ7ikwMIHvBgsqhkiG9w0BCRACCzGB36CB3DCB0zELMAkG A1UEBhMCREUxFjAUBgNVBAgTDU5pZWRlcnNhY2hzZW4xEjAQBgNVBAcTCUx1ZW5lYnVyZzEo MCYGA1UEChMfTGV1cGhhbmEgVW5pdmVyc2l0YWV0IEx1ZW5lYnVyZzEiMCAGA1UECxMZUmVj aGVuLSB1bmQgTWVkaWVuemVudHJ1bTErMCkGA1UEAxMiTGV1cGhhbmEgVW5pdmVyc2l0YWV0 IEx1ZW5lYnVyZyBDQTEdMBsGCSqGSIb3DQEJARYOY2FAbGV1cGhhbmEuZGUCBBDuKTAwDQYJ KoZIhvcNAQEBBQAEggEAqv0WqMdbWaEO/4uht9uT03HNJ3Rbejs1UmqVCl2hLf2tVgQjlfP/ eBjubCF++Qzh3HH+hnf0IELZmYYrg5SCrrv2hg8DDm+WCK3DPXk96WIwPVwhUtBaSGb/BeYQ VZJEOUstSB6UZP/zez3RiMCJEP57oS9lnJz+acy6gDm6qMrMO+G/Y9x/Kdo0vUxfEs8Iu0z+ fO2R5Ovx6QH+j7nmJpuAJiQRsApUdGCiQPGQZLiH18u6B/M5fYcnYUHB9myi4iQbJIVH2U1w uCI66E4I38LIuTEtJdi+qZoRvV4SXOsLwNOkTEx3n65DV0Pbdsl6RfND0zWqtZiF3h3A4kMm TQAAAAAAAA== --------------ms020404000701080402050906-- --===============1115811912== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel --===============1115811912==-- From xen-devel-bounces@lists.xensource.com Thu Sep 01 03:02:45 2011 Return-path: Envelope-to: www-data@lists.xensource.com Delivery-date: Thu, 01 Sep 2011 03:02:45 -0700 Received: from localhost ([127.0.0.1] helo=lists.colo.xensource.com) by lists.xensource.com with esmtp (Exim 4.43) id 1Qz46e-0000Qx-Sy; Thu, 01 Sep 2011 03:02:44 -0700 Received: from mail182.messagelabs.com ([85.158.139.83]) by lists.xensource.com with smtp (Exim 4.43) id 1Qz43y-0000A5-FX for xen-devel@lists.xensource.com; Thu, 01 Sep 2011 03:00:38 -0700 X-Env-Sender: xudong.hao@intel.com X-Msg-Ref: server-14.tower-182.messagelabs.com!1314871194!16493029!1 X-Originating-IP: [134.134.136.24] X-StarScan-Version: 6.3.6; banners=-,-,- X-VirusChecked: Checked Received: (qmail 22552 invoked from network); 1 Sep 2011 09:59:55 -0000 Received: from mga09.intel.com (HELO mga09.intel.com) (134.134.136.24) by server-14.tower-182.messagelabs.com with SMTP; 1 Sep 2011 09:59:55 -0000 Received: from orsmga001.jf.intel.com ([10.7.209.18]) by orsmga102.jf.intel.com with ESMTP; 01 Sep 2011 02:59:46 -0700 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="4.67,352,1309762800"; d="scan'208";a="44313870" Received: from pgsmsx602.gar.corp.intel.com ([10.221.43.81]) by orsmga001.jf.intel.com with ESMTP; 01 Sep 2011 02:59:45 -0700 Received: from pgsmsx104.gar.corp.intel.com (10.221.44.91) by pgsmsx602.gar.corp.intel.com (10.221.43.81) with Microsoft SMTP Server (TLS) id 8.2.255.0; Thu, 1 Sep 2011 17:58:45 +0800 Received: from shsmsx602.ccr.corp.intel.com (10.239.4.104) by PGSMSX104.gar.corp.intel.com (10.221.44.91) with Microsoft SMTP Server (TLS) id 14.1.323.3; Thu, 1 Sep 2011 17:58:45 +0800 Received: from shsmsx502.ccr.corp.intel.com ([10.239.4.96]) by SHSMSX602.ccr.corp.intel.com ([10.239.4.104]) with mapi; Thu, 1 Sep 2011 17:58:44 +0800 From: "Hao, Xudong" To: Christoph Egger , Ian Campbell Date: Thu, 1 Sep 2011 17:58:43 +0800 Subject: RE: [Xen-devel] Re: cs 23453:4f4970d2848d beaks Win 7 Thread-Topic: [Xen-devel] Re: cs 23453:4f4970d2848d beaks Win 7 Thread-Index: AcxohvI3cLUV7s5FSd646fwEx+f6agABpXnw Message-ID: References: <4E5F43F2.6010601@amd.com> <1314867058.28989.84.camel@zakaz.uk.xensource.com> <4E5F4B7E.8090601@amd.com> In-Reply-To: <4E5F4B7E.8090601@amd.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US MIME-Version: 1.0 Cc: "xen-devel@lists.xensource.com" X-BeenThere: xen-devel@lists.xensource.com X-Mailman-Version: 2.1.5 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1304861347==" Sender: xen-devel-bounces@lists.xensource.com Errors-To: xen-devel-bounces@lists.xensource.com --===============1304861347== Content-Language: en-US Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 V2luZG93czIwMDggZ3Vlc3QgaGFzIHRoaXMgQlNPRCBpc3N1ZSB0b28uDQpodHRwOi8vYnVnemls bGEueGVuc291cmNlLmNvbS9idWd6aWxsYS9zaG93X2J1Zy5jZ2k/aWQ9MTc3OA0KDQoNClRoYW5r cywNCi1YdWRvbmcNCg0KPiAtLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KPiBGcm9tOiB4ZW4t ZGV2ZWwtYm91bmNlc0BsaXN0cy54ZW5zb3VyY2UuY29tDQo+IFttYWlsdG86eGVuLWRldmVsLWJv dW5jZXNAbGlzdHMueGVuc291cmNlLmNvbV0gT24gQmVoYWxmIE9mIENocmlzdG9waCBFZ2dlcg0K PiBTZW50OiBUaHVyc2RheSwgU2VwdGVtYmVyIDAxLCAyMDExIDU6MDggUE0NCj4gVG86IElhbiBD YW1wYmVsbA0KPiBDYzogeGVuLWRldmVsQGxpc3RzLnhlbnNvdXJjZS5jb20NCj4gU3ViamVjdDog W1hlbi1kZXZlbF0gUmU6IGNzIDIzNDUzOjRmNDk3MGQyODQ4ZCBiZWFrcyBXaW4gNw0KPiANCj4g T24gMDkvMDEvMTEgMTA6NTAsIElhbiBDYW1wYmVsbCB3cm90ZToNCj4gPiBPbiBUaHUsIDIwMTEt MDktMDEgYXQgMDk6MzYgKzAxMDAsIENocmlzdG9waCBFZ2dlciB3cm90ZToNCj4gPj4gY3MgMjM0 NTM6NGY0OTcwZDI4NDhkIGJyZWFrcyBXaW4gNy4gSXQgZmFpbHMgdG8gaW5pdGlhbGl6ZSB0aGUg Q1BVcw0KPiA+PiBhcyBzaG93biBpbiB0aGUgZGV2aWNlIG1hbmFnZXIgYW5kIHRoaXMgY2F1c2Vz IGEgQlNPRCBvbiBzaHV0ZG93bi4NCj4gPg0KPiA+IEFyZSB5b3UgMTAwJSBzdXJlIGl0J3MgdGhh dCBjc2V0Pw0KPiANCj4gWWVzLCBJIGFtLiBJIGZvdW5kIHRoYXQgYy9zIGJ5IGJpc2VjdGluZy4g SSB1c2VkIHRoZSBsYXRlc3QgeGVuLWtlcm5lbCBhbmQNCj4gdG9vbGNoYWluLCBqdXN0IHJlcGxh Y2VkIHRoZSBodm1sb2FkZXIgYmluYXJ5IGFuZCBib290ZWQgYQ0KPiBXaW43IGd1ZXN0IChib3Ro IDMyYml0IGFuZCA2NGJpdCkgd2l0aCBvbmUgdmNwdS4NCj4gDQo+IEFuIGh2bWxvYWRlciBiaW5h cnkgYnVpbHQgZnJvbSBjL3MgMjM0NTIgd29ya3MuDQo+IEJUVzogSSB1c2UgdGhlIHJvbWJpb3Mu DQo+IA0KPiAgPiBJdCBtb3ZlcyBhIGZldyB0aGluZ3MgYXJvdW5kIGJ1dCBpdCBkb2Vzbid0IGFj dHVhbGx5IHJlbW92ZSBhbnl0aGluZy4NCj4gDQo+ICBGcm9tIGEgZmlyc3QgZ2xhbmNlLCBiaW9z X2luZm9fc2V0dXAoKSBpcyBjYWxsZWQgZWFybGllciB3aXRoIHRoaXMgYy9zLg0KPiANCj4gDQo+ IENocmlzdG9waA0KPiANCj4gDQo+IC0tDQo+IC0tLXRvIHNhdGlzZnkgRXVyb3BlYW4gTGF3IGZv ciBidXNpbmVzcyBsZXR0ZXJzOg0KPiBBZHZhbmNlZCBNaWNybyBEZXZpY2VzIEdtYkgNCj4gRWlu c3RlaW5yaW5nIDI0LCA4NTY4OSBEb3JuYWNoIGIuIE11ZW5jaGVuDQo+IEdlc2NoYWVmdHNmdWVo cmVyOiBBbGJlcnRvIEJvenpvLCBBbmRyZXcgQm93ZA0KPiBTaXR6OiBEb3JuYWNoLCBHZW1laW5k ZSBBc2NoaGVpbSwgTGFuZGtyZWlzIE11ZW5jaGVuIFJlZ2lzdGVyZ2VyaWNodA0KPiBNdWVuY2hl biwgSFJCIE5yLiA0MzYzMg0KPiANCj4gDQo+IF9fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fDQo+IFhlbi1kZXZlbCBtYWlsaW5nIGxpc3QNCj4gWGVuLWRldmVs QGxpc3RzLnhlbnNvdXJjZS5jb20NCj4gaHR0cDovL2xpc3RzLnhlbnNvdXJjZS5jb20veGVuLWRl dmVsDQo= --===============1304861347== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel --===============1304861347==-- From xen-devel-bounces@lists.xensource.com Thu Sep 01 03:15:34 2011 Return-path: Envelope-to: www-data@lists.xensource.com Delivery-date: Thu, 01 Sep 2011 03:15:34 -0700 Received: from localhost ([127.0.0.1] helo=lists.colo.xensource.com) by lists.xensource.com with esmtp (Exim 4.43) id 1Qz4J4-00010x-Q4; Thu, 01 Sep 2011 03:15:34 -0700 Received: from mail21.messagelabs.com ([85.158.143.35]) by lists.xensource.com with smtp (Exim 4.43) id 1Qz4IJ-0000oI-RX for xen-devel@lists.xensource.com; Thu, 01 Sep 2011 03:14:48 -0700 X-Env-Sender: stefan.bader@canonical.com X-Msg-Ref: server-15.tower-21.messagelabs.com!1314872085!48945776!1 X-Originating-IP: [91.189.89.112] X-StarScan-Version: 6.3.6; banners=-,-,- X-VirusChecked: Checked Received: (qmail 28828 invoked from network); 1 Sep 2011 10:14:45 -0000 Received: from youngberry.canonical.com (HELO youngberry.canonical.com) (91.189.89.112) by server-15.tower-21.messagelabs.com with SMTP; 1 Sep 2011 10:14:45 -0000 Received: from p5b2e5774.dip.t-dialin.net ([91.46.87.116] helo=[192.168.2.5]) by youngberry.canonical.com with esmtpsa (TLS1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.71) (envelope-from ) id 1Qz4IG-0002Tn-5E; Thu, 01 Sep 2011 10:14:44 +0000 Message-ID: <4E5F5B12.4080206@canonical.com> Date: Thu, 01 Sep 2011 12:14:42 +0200 From: Stefan Bader User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.2.20) Gecko/20110805 Lightning/1.0b2 Thunderbird/3.1.12 MIME-Version: 1.0 To: "xen-devel@lists.xensource.com" X-Enigmail-Version: 1.1.2 Content-Type: text/plain; charset=ISO-8859-15 Content-Transfer-Encoding: 7bit Cc: Stefano Stabellini Subject: [Xen-devel] HVM guests and pvlocks not working as expected X-BeenThere: xen-devel@lists.xensource.com X-Mailman-Version: 2.1.5 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xensource.com Errors-To: xen-devel-bounces@lists.xensource.com After much joy with this, I thought I post this to a bigger audience. After having migrated to Xen 4.1.1, booting HVM guests had several issues. Some related to interrupts not being set up correctly (which Stefano has posted patches) and even with those 3.0 guests seem to hang for me while 2.6.38 or older kernels were ok. After digging deeply into this, I think I found the issue. However, if that is true, it seems rather lucky if pv spinlocks in HVM worked for anybody. The xen_hvm_smp_init() call will change the smp_ops hooks. One of which is smp_prepare_cpus. This is done in start_kernel and at this point in time, there is no change to the pv_lock_ops and they point to the ticket versions. Later in start_kernel, check_bugs is called and part of that takes the pv_lock_ops and patches the kernel with the correct jumps. _After_ that, the kernel_init is called and that in turn does the smp_prepare_cpus which now changes the pv_lock_ops again, *but not* run any patching again. So the _raw_spin_*lock calls still use the ticket calls. start_kernel setup_arch -> xen_hvm_smp_init (set smp_ops) ... check_bugs -> alternative_instructions (patches pv_locks sites) ... rest_init (triggers kernel_init as a thread) kernel_init ... smp_prepare_cpus (calls xen_init_spinlocks through smp_ops hook) To make things even more fun, there is the possibility that some spinlock functions are forced to be inlined and others are not (CONFIG_INLINE_SPIN_*). In our special case only two versions of spin_unlock were inlined. Put that together into a pot with modules, shake well, and there is the fun. Basically on load time, the non-inline calls remain pointing to the unmodified ticket implementation (main kernel). But the unlock calls (which are inlined) get modified because the loaded module gets patched up. One can imagine that this does not work too well. Anyway, even without the secondary issue, I am sure that just replacing the functions in pv_lock_ops without the spinlock calls getting actually modified is not the intended behaviour. Unfortunately I have not yet been able to make it work. Any attempt to move xen_init_spinlocks to be called before check_bugs or adding a call to alternative_instructions results in another hang on boot. At least the latter method results in a more usable dump for crash, which shows that on spinlock was taken (slow) and two spurious taken ones (this is more to play for me). But then, maybe someone has some ideas there... -Stefan _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel From xen-devel-bounces@lists.xensource.com Thu Sep 01 03:16:58 2011 Return-path: Envelope-to: www-data@lists.xensource.com Delivery-date: Thu, 01 Sep 2011 03:16:58 -0700 Received: from localhost ([127.0.0.1] helo=lists.colo.xensource.com) by lists.xensource.com with esmtp (Exim 4.43) id 1Qz4KQ-0001TU-LX; Thu, 01 Sep 2011 03:16:58 -0700 Received: from mail216.messagelabs.com ([85.158.143.99]) by lists.xensource.com with esmtp (Exim 4.43) id 1Qz4JM-00016Q-5H for xen-devel@lists.xensource.com; Thu, 01 Sep 2011 03:15:52 -0700 X-Env-Sender: olaf@aepfle.de X-Msg-Ref: server-6.tower-216.messagelabs.com!1314872148!15434753!1 X-Originating-IP: [81.169.146.160] X-StarScan-Version: 6.3.6; banners=-,-,- X-VirusChecked: Checked Received: (qmail 5160 invoked from network); 1 Sep 2011 10:15:49 -0000 Received: from mo-p00-ob.rzone.de (HELO mo-p00-ob.rzone.de) (81.169.146.160) by server-6.tower-216.messagelabs.com with DHE-RSA-AES256-SHA encrypted SMTP; 1 Sep 2011 10:15:49 -0000 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; t=1314872147; l=2364; s=domk; d=aepfle.de; h=In-Reply-To:Content-Type:MIME-Version:References:Subject:Cc:To:From: Date:X-RZG-CLASS-ID:X-RZG-AUTH; bh=+uqU99LqwXDEYXiD2lqFm8LllFU=; b=xe/RCXagUsBjYNne43zjEaEQF3Rq/wZBxT10jp7k0h0OdPMMAyu0OadZ2LIMzrhjXlJ 1Qv4PF8LJMZDlhqcwNmLeq9HSIWEQBdGZagXpfCdwuxiJB2RwztAEDIy8np/qtzS+6fff umkOnhSGNgsyYmdvv8fpQtz6revzR39m1R4= X-RZG-AUTH: :P2EQZWCpfu+qG7CngxMFH1J+zrwiavkK6tmQaLfmztM8TOFHii0PETdN X-RZG-CLASS-ID: mo00 Received: from probook.site (dslb-088-065-094-125.pools.arcor-ip.net [88.65.94.125]) by smtp.strato.de (cohen mo57) (RZmta 26.5) with (DHE-RSA-AES256-SHA encrypted) ESMTPA id w009afn8194pe3 ; Thu, 1 Sep 2011 12:15:26 +0200 (MEST) Received: by probook.site (Postfix, from userid 1000) id B20AA18B65; Thu, 1 Sep 2011 12:15:25 +0200 (CEST) Date: Thu, 1 Sep 2011 12:15:25 +0200 From: Olaf Hering To: zhen shi Message-ID: <20110901101525.GA3258@aepfle.de> References: MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.21.rev5535 (2011-07-01) Cc: xen-devel@lists.xensource.com Subject: [Xen-devel] Re: some questions of IO ring in xenpaging X-BeenThere: xen-devel@lists.xensource.com X-Mailman-Version: 2.1.5 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xensource.com Errors-To: xen-devel-bounces@lists.xensource.com On Thu, Sep 01, zhen shi wrote: > Hi Olaf -- > > I have two questions to ask you about xenpaging. > 1) When guest os causes page_fault for the accessed page is paging_out > or paged, it will execute p2m_mem_paging_populate(). and in > p2m_mem_paging_populate() it will first check if the ring is full. > when I ran with domU suse11 4G memory and 8vcpus, I found there will > be a corruption in checking the ring. > For example, if 4vcpus are met with page faults when they access > different pages, and there is only four free-requests for the ring. > and then they call p2m_mem_paging_populate(),and execute > mem_event_check_ring(d) at the same time.All will find ring is not > full,and will fill the requests. It will cause the latter request to > cover the front request. > and I think there should a lock before the mem_event_check_ring(d), > and normally it unlock after mem_event_put_request(d, &req). > You can review the attached doc of xenpaging_IO_ring.txt to see if my > opnion is right. Yes, you are right. I think mem_event_check_ring() should reserve a reference, and mem_event_put_request() should use that reference. mem_sharing_alloc_page() even has a comment that this should be done. > 2) mem_sharing and xenpaging are shared with one IO ring for domU. In > the function of mem_sharing_alloc_page(), if alloc_domheap_page(d, 0) > returns NULL, then it will pause VCPU, check if the ring is full, and > fill the request at last. > I think there is also a corruption of mem_event_check_ring(d) with it > in p2m_mem_paging_populate(). We should assure exclusively in reading > the free_request and puting requests. What's more, although it hardly > fails in alloc_domheap_page(d, 0) from mem_sharing_alloc_page(), it > will fill the requests in IO ring. But in xenpaging when handling the > page_in requests, we have not distinguished the requests with flag > "MEM_EVENT_FLAG_VCPU_PAUSED" from paging or sharing. It will cause if > the request is from mem_sharing_alloc_page(), it will go to > p2m_mem_paging_resume() at last, and the page's p2mt is p2m_ram_rw. I > think this is wrong. Maybe we should add the req.type when page in. Yes, get_request() in xenpaging should check the type before popping the request from the ring. Perhaps memsharing and xenpaging should use its own rings. Olaf _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel From xen-devel-bounces@lists.xensource.com Thu Sep 01 03:31:29 2011 Return-path: Envelope-to: www-data@lists.xensource.com Delivery-date: Thu, 01 Sep 2011 03:31:29 -0700 Received: from localhost ([127.0.0.1] helo=lists.colo.xensource.com) by lists.xensource.com with esmtp (Exim 4.43) id 1Qz4YT-00023h-Ik; Thu, 01 Sep 2011 03:31:29 -0700 Received: from mail27.messagelabs.com ([193.109.254.147]) by lists.xensource.com with smtp (Exim 4.43) id 1Qz4Xy-0001r6-AK for xen-devel@lists.xensource.com; Thu, 01 Sep 2011 03:30:58 -0700 X-Env-Sender: imammedo@redhat.com X-Msg-Ref: server-8.tower-27.messagelabs.com!1314873040!44799604!1 X-Originating-IP: [209.132.183.28] X-StarScan-Version: 6.3.6; banners=-,-,- X-VirusChecked: Checked Received: (qmail 11650 invoked from network); 1 Sep 2011 10:30:41 -0000 Received: from mx1.redhat.com (HELO mx1.redhat.com) (209.132.183.28) by server-8.tower-27.messagelabs.com with SMTP; 1 Sep 2011 10:30:41 -0000 Received: from int-mx02.intmail.prod.int.phx2.redhat.com (int-mx02.intmail.prod.int.phx2.redhat.com [10.5.11.12]) by mx1.redhat.com (8.14.4/8.14.4) with ESMTP id p81AUMHd024817 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Thu, 1 Sep 2011 06:30:24 -0400 Received: from dell-pet610-01.lab.eng.brq.redhat.com (dell-pet610-01.lab.eng.brq.redhat.com [10.34.42.20]) by int-mx02.intmail.prod.int.phx2.redhat.com (8.13.8/8.13.8) with ESMTP id p819l6QK019929; Thu, 1 Sep 2011 05:47:07 -0400 From: Igor Mammedov To: linux-kernel@vger.kernel.org Date: Thu, 1 Sep 2011 13:46:55 +0200 Message-Id: <1314877615-18280-1-git-send-email-imammedo@redhat.com> In-Reply-To: <4E5EB794.7050909@goop.org> References: <4E5EB794.7050909@goop.org> X-Scanned-By: MIMEDefang 2.67 on 10.5.11.12 Cc: jeremy@goop.org, xen-devel@lists.xensource.com, konrad.wilk@oracle.com Subject: [Xen-devel] [PATCH v2] xen: x86_32: do not enable iterrupts when returning from exception in interrupt context X-BeenThere: xen-devel@lists.xensource.com X-Mailman-Version: 2.1.5 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xensource.com Errors-To: xen-devel-bounces@lists.xensource.com If vmalloc page_fault happens inside of interrupt handler with interrupts disabled then on exit path from exception handler when there is no pending interrupts, the following code (arch/x86/xen/xen-asm_32.S:112): cmpw $0x0001, XEN_vcpu_info_pending(%eax) sete XEN_vcpu_info_mask(%eax) will enable interrupts even if they has been previously disabled according to eflags from the bounce frame (arch/x86/xen/xen-asm_32.S:99) testb $X86_EFLAGS_IF>>8, 8+1+ESP_OFFSET(%esp) setz XEN_vcpu_info_mask(%eax) Solution is in setting XEN_vcpu_info_mask only when it should be set according to cmpw $0x0001, XEN_vcpu_info_pending(%eax) but not clearing it if there isn't any pending events. Reproducer for bug is attached to RHBZ 707552 Signed-off-by: Igor Mammedov Signed-off-by: Jeremy Fitzhardinge --- arch/x86/xen/xen-asm_32.S | 8 +++++--- 1 files changed, 5 insertions(+), 3 deletions(-) diff --git a/arch/x86/xen/xen-asm_32.S b/arch/x86/xen/xen-asm_32.S index 22a2093..b040b0e 100644 --- a/arch/x86/xen/xen-asm_32.S +++ b/arch/x86/xen/xen-asm_32.S @@ -113,11 +113,13 @@ xen_iret_start_crit: /* * If there's something pending, mask events again so we can - * jump back into xen_hypervisor_callback + * jump back into xen_hypervisor_callback. Otherwise do not + * touch XEN_vcpu_info_mask. */ - sete XEN_vcpu_info_mask(%eax) + jne 1f + movb $1, XEN_vcpu_info_mask(%eax) - popl %eax +1: popl %eax /* * From this point on the registers are restored and the stack -- 1.7.1 _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel From xen-devel-bounces@lists.xensource.com Thu Sep 01 03:40:15 2011 Return-path: Envelope-to: www-data@lists.xensource.com Delivery-date: Thu, 01 Sep 2011 03:40:15 -0700 Received: from localhost ([127.0.0.1] helo=lists.colo.xensource.com) by lists.xensource.com with esmtp (Exim 4.43) id 1Qz4gx-0002aC-7e; Thu, 01 Sep 2011 03:40:15 -0700 Received: from mail174.messagelabs.com ([85.158.138.51]) by lists.xensource.com with esmtp (Exim 4.43) id 1Qz4gQ-0002NC-IW for xen-devel@lists.xensource.com; Thu, 01 Sep 2011 03:39:42 -0700 X-Env-Sender: lidongyang@novell.com X-Msg-Ref: server-6.tower-174.messagelabs.com!1314873573!27742269!1 X-Originating-IP: [137.65.250.26] X-StarScan-Version: 6.3.6; banners=-,-,- X-VirusChecked: Checked Received: (qmail 4737 invoked from network); 1 Sep 2011 10:39:38 -0000 Received: from victor.provo.novell.com (HELO victor.provo.novell.com) (137.65.250.26) by server-6.tower-174.messagelabs.com with DHE-RSA-AES256-SHA encrypted SMTP; 1 Sep 2011 10:39:38 -0000 Received: from localhost.localdomain (prv-ext-foundry1int.gns.novell.com [137.65.251.240]) by victor.provo.novell.com with ESMTP (TLS encrypted); Thu, 01 Sep 2011 04:39:20 -0600 From: Li Dongyang To: xen-devel@lists.xensource.com Date: Thu, 1 Sep 2011 18:39:08 +0800 Message-Id: <2b6a823be2bf5273c7f584ba0f9c96aa5a56c05a.1314872306.git.lidongyang@novell.com> X-Mailer: git-send-email 1.7.6 In-Reply-To: References: In-Reply-To: References: Cc: owen.smith@citrix.com, JBeulich@novell.com, konrad.wilk@oracle.com Subject: [Xen-devel] [PATCH V4 1/3] xen-blkfront: add BLKIF_OP_DISCARD and discard request struct X-BeenThere: xen-devel@lists.xensource.com X-Mailman-Version: 2.1.5 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xensource.com Errors-To: xen-devel-bounces@lists.xensource.com Now we use BLKIF_OP_DISCARD and add blkif_request_discard to blkif_request union, the patch is taken from Owen Smith and Konrad, Thanks Signed-off-by: Konrad Rzeszutek Wilk Signed-off-by: Owen Smith Signed-off-by: Li Dongyang --- include/xen/interface/io/blkif.h | 36 ++++++++++++++++++++++++++++++++++++ 1 files changed, 36 insertions(+), 0 deletions(-) diff --git a/include/xen/interface/io/blkif.h b/include/xen/interface/io/blkif.h index 3d5d6db..9324488 100644 --- a/include/xen/interface/io/blkif.h +++ b/include/xen/interface/io/blkif.h @@ -57,6 +57,36 @@ typedef uint64_t blkif_sector_t; * "feature-flush-cache" node! */ #define BLKIF_OP_FLUSH_DISKCACHE 3 + +/* + * Recognised only if "feature-discard" is present in backend xenbus info. + * The "feature-discard" node contains a boolean indicating whether trim + * (ATA) or unmap (SCSI) - conviently called discard requests are likely + * to succeed or fail. Either way, a discard request + * may fail at any time with BLKIF_RSP_EOPNOTSUPP if it is unsupported by + * the underlying block-device hardware. The boolean simply indicates whether + * or not it is worthwhile for the frontend to attempt discard requests. + * If a backend does not recognise BLKIF_OP_DISCARD, it should *not* + * create the "feature-discard" node! + * + * Discard operation is a request for the underlying block device to mark + * extents to be erased. However, discard does not guarantee that the blocks + * will be erased from the device - it is just a hint to the device + * controller that these blocks are no longer in use. What the device + * controller does with that information is left to the controller. + * Discard operations are passed with sector_number as the + * sector index to begin discard operations at and nr_sectors as the number of + * sectors to be discarded. The specified sectors should be discarded if the + * underlying block device supports trim (ATA) or unmap (SCSI) operations, + * or a BLKIF_RSP_EOPNOTSUPP should be returned. + * More information about trim/unmap operations at: + * http://t13.org/Documents/UploadedDocuments/docs2008/ + * e07154r6-Data_Set_Management_Proposal_for_ATA-ACS2.doc + * http://www.seagate.com/staticfiles/support/disc/manuals/ + * Interface%20manuals/100293068c.pdf + */ +#define BLKIF_OP_DISCARD 5 + /* * Maximum scatter/gather segments per request. * This is carefully chosen so that sizeof(struct blkif_ring) <= PAGE_SIZE. @@ -74,6 +104,11 @@ struct blkif_request_rw { } seg[BLKIF_MAX_SEGMENTS_PER_REQUEST]; }; +struct blkif_request_discard { + blkif_sector_t sector_number; + uint64_t nr_sectors; +}; + struct blkif_request { uint8_t operation; /* BLKIF_OP_??? */ uint8_t nr_segments; /* number of segments */ @@ -81,6 +116,7 @@ struct blkif_request { uint64_t id; /* private guest value, echoed in resp */ union { struct blkif_request_rw rw; + struct blkif_request_discard discard; } u; }; -- 1.7.6 _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel From xen-devel-bounces@lists.xensource.com Thu Sep 01 03:41:09 2011 Return-path: Envelope-to: www-data@lists.xensource.com Delivery-date: Thu, 01 Sep 2011 03:41:09 -0700 Received: from localhost ([127.0.0.1] helo=lists.colo.xensource.com) by lists.xensource.com with esmtp (Exim 4.43) id 1Qz4ho-0002x9-Ry; Thu, 01 Sep 2011 03:41:08 -0700 Received: from mail174.messagelabs.com ([85.158.138.51]) by lists.xensource.com with esmtp (Exim 4.43) id 1Qz4gR-0002NE-Qq for xen-devel@lists.xensource.com; Thu, 01 Sep 2011 03:39:44 -0700 X-Env-Sender: lidongyang@novell.com X-Msg-Ref: server-14.tower-174.messagelabs.com!1314873575!29868973!1 X-Originating-IP: [137.65.250.26] X-StarScan-Version: 6.3.6; banners=-,-,- X-VirusChecked: Checked Received: (qmail 18441 invoked from network); 1 Sep 2011 10:39:39 -0000 Received: from victor.provo.novell.com (HELO victor.provo.novell.com) (137.65.250.26) by server-14.tower-174.messagelabs.com with DHE-RSA-AES256-SHA encrypted SMTP; 1 Sep 2011 10:39:39 -0000 Received: from localhost.localdomain (prv-ext-foundry1int.gns.novell.com [137.65.251.240]) by victor.provo.novell.com with ESMTP (TLS encrypted); Thu, 01 Sep 2011 04:39:25 -0600 From: Li Dongyang To: xen-devel@lists.xensource.com Date: Thu, 1 Sep 2011 18:39:10 +0800 Message-Id: <7f85bb71f76deed2537438928fa8b6dafb6a51f8.1314872306.git.lidongyang@novell.com> X-Mailer: git-send-email 1.7.6 In-Reply-To: References: In-Reply-To: References: Cc: owen.smith@citrix.com, JBeulich@novell.com, konrad.wilk@oracle.com Subject: [Xen-devel] [PATCH V4 3/3] xen-blkback: discard requests handling in blkback driver X-BeenThere: xen-devel@lists.xensource.com X-Mailman-Version: 2.1.5 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xensource.com Errors-To: xen-devel-bounces@lists.xensource.com Now blkback driver can handle the discard request from guest, we will forward the request to phy device if it really has discard support, or we'll punch a hole on the image file. Signed-off-by: Li Dongyang --- drivers/block/xen-blkback/blkback.c | 87 +++++++++++++++++++++++++++----- drivers/block/xen-blkback/common.h | 93 ++++++++++++++++++++++++++++------ drivers/block/xen-blkback/xenbus.c | 58 ++++++++++++++++++++++ 3 files changed, 207 insertions(+), 31 deletions(-) diff --git a/drivers/block/xen-blkback/blkback.c b/drivers/block/xen-blkback/blkback.c index 2330a9a..a3b50d0 100644 --- a/drivers/block/xen-blkback/blkback.c +++ b/drivers/block/xen-blkback/blkback.c @@ -39,6 +39,9 @@ #include #include #include +#include +#include +#include #include #include @@ -258,13 +261,16 @@ irqreturn_t xen_blkif_be_int(int irq, void *dev_id) static void print_stats(struct xen_blkif *blkif) { - pr_info("xen-blkback (%s): oo %3d | rd %4d | wr %4d | f %4d\n", + pr_info("xen-blkback (%s): oo %3d | rd %4d | wr %4d | f %4d" + " | ds %4d\n", current->comm, blkif->st_oo_req, - blkif->st_rd_req, blkif->st_wr_req, blkif->st_f_req); + blkif->st_rd_req, blkif->st_wr_req, + blkif->st_f_req, blkif->st_ds_req); blkif->st_print = jiffies + msecs_to_jiffies(10 * 1000); blkif->st_rd_req = 0; blkif->st_wr_req = 0; blkif->st_oo_req = 0; + blkif->st_ds_req = 0; } int xen_blkif_schedule(void *arg) @@ -410,6 +416,43 @@ static int xen_blkbk_map(struct blkif_request *req, return ret; } +static void xen_blk_discard(struct xen_blkif *blkif, struct blkif_request *req) +{ + int err = 0; + int status = BLKIF_RSP_OKAY; + struct block_device *bdev = blkif->vbd.bdev; + + if (blkif->blk_backend_type == BLKIF_BACKEND_PHY) + /* just forward the discard request */ + err = blkdev_issue_discard(bdev, + req->u.discard.sector_number, + req->u.discard.nr_sectors, + GFP_KERNEL, 0); + else if (blkif->blk_backend_type == BLKIF_BACKEND_FILE) { + /* punch a hole in the backing file */ + struct loop_device *lo = bdev->bd_disk->private_data; + struct file *file = lo->lo_backing_file; + + if (file->f_op->fallocate) + err = file->f_op->fallocate(file, + FALLOC_FL_KEEP_SIZE | FALLOC_FL_PUNCH_HOLE, + req->u.discard.sector_number << 9, + req->u.discard.nr_sectors << 9); + else + err = -EOPNOTSUPP; + } else + err = -EOPNOTSUPP; + + if (err == -EOPNOTSUPP) { + pr_debug(DRV_PFX "blkback: discard op failed, " + "not supported\n"); + status = BLKIF_RSP_EOPNOTSUPP; + } else if (err) + status = BLKIF_RSP_ERROR; + + make_response(blkif, req->id, req->operation, status); +} + /* * Completion callback on the bio's. Called as bh->b_end_io() */ @@ -563,6 +606,10 @@ static int dispatch_rw_block_io(struct xen_blkif *blkif, blkif->st_f_req++; operation = WRITE_FLUSH; break; + case BLKIF_OP_DISCARD: + blkif->st_ds_req++; + operation = REQ_DISCARD; + break; case BLKIF_OP_WRITE_BARRIER: default: operation = 0; /* make gcc happy */ @@ -572,7 +619,8 @@ static int dispatch_rw_block_io(struct xen_blkif *blkif, /* Check that the number of segments is sane. */ nseg = req->nr_segments; - if (unlikely(nseg == 0 && operation != WRITE_FLUSH) || + if (unlikely(nseg == 0 && operation != WRITE_FLUSH && + operation != REQ_DISCARD) || unlikely(nseg > BLKIF_MAX_SEGMENTS_PER_REQUEST)) { pr_debug(DRV_PFX "Bad number of segments in request (%d)\n", nseg); @@ -627,10 +675,14 @@ static int dispatch_rw_block_io(struct xen_blkif *blkif, * the hypercall to unmap the grants - that is all done in * xen_blkbk_unmap. */ - if (xen_blkbk_map(req, pending_req, seg)) + if (operation != BLKIF_OP_DISCARD && + xen_blkbk_map(req, pending_req, seg)) goto fail_flush; - /* This corresponding xen_blkif_put is done in __end_block_io_op */ + /* + * This corresponding xen_blkif_put is done in __end_block_io_op, or + * below if we are handling a BLKIF_OP_DISCARD. + */ xen_blkif_get(blkif); for (i = 0; i < nseg; i++) { @@ -654,18 +706,25 @@ static int dispatch_rw_block_io(struct xen_blkif *blkif, preq.sector_number += seg[i].nsec; } - /* This will be hit if the operation was a flush. */ + /* This will be hit if the operation was a flush or discard. */ if (!bio) { - BUG_ON(operation != WRITE_FLUSH); + BUG_ON(operation != WRITE_FLUSH && operation != REQ_DISCARD); - bio = bio_alloc(GFP_KERNEL, 0); - if (unlikely(bio == NULL)) - goto fail_put_bio; + if (operation == WRITE_FLUSH) { + bio = bio_alloc(GFP_KERNEL, 0); + if (unlikely(bio == NULL)) + goto fail_put_bio; - biolist[nbio++] = bio; - bio->bi_bdev = preq.bdev; - bio->bi_private = pending_req; - bio->bi_end_io = end_block_io_op; + biolist[nbio++] = bio; + bio->bi_bdev = preq.bdev; + bio->bi_private = pending_req; + bio->bi_end_io = end_block_io_op; + } else if (operation == REQ_DISCARD) { + xen_blk_discard(blkif, req); + xen_blkif_put(blkif); + free_req(pending_req); + return 0; + } } /* diff --git a/drivers/block/xen-blkback/common.h b/drivers/block/xen-blkback/common.h index 9e40b28..bfb532e 100644 --- a/drivers/block/xen-blkback/common.h +++ b/drivers/block/xen-blkback/common.h @@ -63,13 +63,26 @@ struct blkif_common_response { /* i386 protocol version */ #pragma pack(push, 4) + +struct blkif_x86_32_request_rw { + blkif_sector_t sector_number;/* start sector idx on disk (r/w only) */ + struct blkif_request_segment seg[BLKIF_MAX_SEGMENTS_PER_REQUEST]; +}; + +struct blkif_x86_32_request_discard { + blkif_sector_t sector_number;/* start sector idx on disk (r/w only) */ + uint64_t nr_sectors; +}; + struct blkif_x86_32_request { uint8_t operation; /* BLKIF_OP_??? */ uint8_t nr_segments; /* number of segments */ blkif_vdev_t handle; /* only for read/write requests */ uint64_t id; /* private guest value, echoed in resp */ - blkif_sector_t sector_number;/* start sector idx on disk (r/w only) */ - struct blkif_request_segment seg[BLKIF_MAX_SEGMENTS_PER_REQUEST]; + union { + struct blkif_x86_32_request_rw rw; + struct blkif_x86_32_request_discard discard; + } u; }; struct blkif_x86_32_response { uint64_t id; /* copied from request */ @@ -79,13 +92,26 @@ struct blkif_x86_32_response { #pragma pack(pop) /* x86_64 protocol version */ + +struct blkif_x86_64_request_rw { + blkif_sector_t sector_number;/* start sector idx on disk (r/w only) */ + struct blkif_request_segment seg[BLKIF_MAX_SEGMENTS_PER_REQUEST]; +}; + +struct blkif_x86_64_request_discard { + blkif_sector_t sector_number;/* start sector idx on disk (r/w only) */ + uint64_t nr_sectors; +}; + struct blkif_x86_64_request { uint8_t operation; /* BLKIF_OP_??? */ uint8_t nr_segments; /* number of segments */ blkif_vdev_t handle; /* only for read/write requests */ uint64_t __attribute__((__aligned__(8))) id; - blkif_sector_t sector_number;/* start sector idx on disk (r/w only) */ - struct blkif_request_segment seg[BLKIF_MAX_SEGMENTS_PER_REQUEST]; + union { + struct blkif_x86_64_request_rw rw; + struct blkif_x86_64_request_discard discard; + } u; }; struct blkif_x86_64_response { uint64_t __attribute__((__aligned__(8))) id; @@ -113,6 +139,11 @@ enum blkif_protocol { BLKIF_PROTOCOL_X86_64 = 3, }; +enum blkif_backend_type { + BLKIF_BACKEND_PHY = 1, + BLKIF_BACKEND_FILE = 2, +}; + struct xen_vbd { /* What the domain refers to this vbd as. */ blkif_vdev_t handle; @@ -138,6 +169,7 @@ struct xen_blkif { unsigned int irq; /* Comms information. */ enum blkif_protocol blk_protocol; + enum blkif_backend_type blk_backend_type; union blkif_back_rings blk_rings; struct vm_struct *blk_ring_area; /* The VBD attached to this interface. */ @@ -159,6 +191,7 @@ struct xen_blkif { int st_wr_req; int st_oo_req; int st_f_req; + int st_ds_req; int st_rd_sect; int st_wr_sect; @@ -182,7 +215,7 @@ struct xen_blkif { struct phys_req { unsigned short dev; - unsigned short nr_sects; + blkif_sector_t nr_sects; struct block_device *bdev; blkif_sector_t sector_number; }; @@ -206,12 +239,25 @@ static inline void blkif_get_x86_32_req(struct blkif_request *dst, dst->nr_segments = src->nr_segments; dst->handle = src->handle; dst->id = src->id; - dst->u.rw.sector_number = src->sector_number; - barrier(); - if (n > dst->nr_segments) - n = dst->nr_segments; - for (i = 0; i < n; i++) - dst->u.rw.seg[i] = src->seg[i]; + switch (src->operation) { + case BLKIF_OP_READ: + case BLKIF_OP_WRITE: + case BLKIF_OP_WRITE_BARRIER: + case BLKIF_OP_FLUSH_DISKCACHE: + dst->u.rw.sector_number = src->u.rw.sector_number; + barrier(); + if (n > dst->nr_segments) + n = dst->nr_segments; + for (i = 0; i < n; i++) + dst->u.rw.seg[i] = src->u.rw.seg[i]; + break; + case BLKIF_OP_DISCARD: + dst->u.discard.sector_number = src->u.discard.sector_number; + dst->u.discard.nr_sectors = src->u.discard.nr_sectors; + break; + default: + break; + } } static inline void blkif_get_x86_64_req(struct blkif_request *dst, @@ -222,12 +268,25 @@ static inline void blkif_get_x86_64_req(struct blkif_request *dst, dst->nr_segments = src->nr_segments; dst->handle = src->handle; dst->id = src->id; - dst->u.rw.sector_number = src->sector_number; - barrier(); - if (n > dst->nr_segments) - n = dst->nr_segments; - for (i = 0; i < n; i++) - dst->u.rw.seg[i] = src->seg[i]; + switch (src->operation) { + case BLKIF_OP_READ: + case BLKIF_OP_WRITE: + case BLKIF_OP_WRITE_BARRIER: + case BLKIF_OP_FLUSH_DISKCACHE: + dst->u.rw.sector_number = src->u.rw.sector_number; + barrier(); + if (n > dst->nr_segments) + n = dst->nr_segments; + for (i = 0; i < n; i++) + dst->u.rw.seg[i] = src->u.rw.seg[i]; + break; + case BLKIF_OP_DISCARD: + dst->u.discard.sector_number = src->u.discard.sector_number; + dst->u.discard.nr_sectors = src->u.discard.nr_sectors; + break; + default: + break; + } } #endif /* __XEN_BLKIF__BACKEND__COMMON_H__ */ diff --git a/drivers/block/xen-blkback/xenbus.c b/drivers/block/xen-blkback/xenbus.c index 3f129b4..2b3aef0 100644 --- a/drivers/block/xen-blkback/xenbus.c +++ b/drivers/block/xen-blkback/xenbus.c @@ -272,6 +272,7 @@ VBD_SHOW(oo_req, "%d\n", be->blkif->st_oo_req); VBD_SHOW(rd_req, "%d\n", be->blkif->st_rd_req); VBD_SHOW(wr_req, "%d\n", be->blkif->st_wr_req); VBD_SHOW(f_req, "%d\n", be->blkif->st_f_req); +VBD_SHOW(ds_req, "%d\n", be->blkif->st_ds_req); VBD_SHOW(rd_sect, "%d\n", be->blkif->st_rd_sect); VBD_SHOW(wr_sect, "%d\n", be->blkif->st_wr_sect); @@ -280,6 +281,7 @@ static struct attribute *xen_vbdstat_attrs[] = { &dev_attr_rd_req.attr, &dev_attr_wr_req.attr, &dev_attr_f_req.attr, + &dev_attr_ds_req.attr, &dev_attr_rd_sect.attr, &dev_attr_wr_sect.attr, NULL @@ -419,6 +421,60 @@ int xen_blkbk_flush_diskcache(struct xenbus_transaction xbt, return err; } +int xen_blkbk_discard(struct xenbus_transaction xbt, struct backend_info *be) +{ + struct xenbus_device *dev = be->dev; + struct xen_blkif *blkif = be->blkif; + char *type; + int err; + int state = 0; + + type = xenbus_read(XBT_NIL, dev->nodename, "type", NULL); + if (!IS_ERR(type)) { + if (strncmp(type, "file", 4) == 0) { + state = 1; + blkif->blk_backend_type = BLKIF_BACKEND_FILE; + } + if (strncmp(type, "phy", 3) == 0) { + struct block_device *bdev = be->blkif->vbd.bdev; + struct request_queue *q = bdev_get_queue(bdev); + if (blk_queue_discard(q)) { + err = xenbus_printf(xbt, dev->nodename, + "discard-granularity", "%u", + q->limits.discard_granularity); + if (err) { + xenbus_dev_fatal(dev, err, + "writing discard-granularity"); + goto kfree; + } + err = xenbus_printf(xbt, dev->nodename, + "discard-alignment", "%u", + q->limits.discard_alignment); + if (err) { + xenbus_dev_fatal(dev, err, + "writing discard-alignment"); + goto kfree; + } + state = 1; + blkif->blk_backend_type = BLKIF_BACKEND_PHY; + } + } + } else { + err = PTR_ERR(type); + xenbus_dev_fatal(dev, err, "reading type"); + goto out; + } + + err = xenbus_printf(xbt, dev->nodename, "feature-discard", + "%d", state); + if (err) + xenbus_dev_fatal(dev, err, "writing feature-discard"); +kfree: + kfree(type); +out: + return err; +} + /* * Entry point to this code when a new device is created. Allocate the basic * structures, and watch the store waiting for the hotplug scripts to tell us @@ -650,6 +706,8 @@ again: if (err) goto abort; + err = xen_blkbk_discard(xbt, be); + err = xenbus_printf(xbt, dev->nodename, "sectors", "%llu", (unsigned long long)vbd_sz(&be->blkif->vbd)); if (err) { -- 1.7.6 _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel From xen-devel-bounces@lists.xensource.com Thu Sep 01 03:42:03 2011 Return-path: Envelope-to: www-data@lists.xensource.com Delivery-date: Thu, 01 Sep 2011 03:42:03 -0700 Received: from localhost ([127.0.0.1] helo=lists.colo.xensource.com) by lists.xensource.com with esmtp (Exim 4.43) id 1Qz4if-0003Je-8F; Thu, 01 Sep 2011 03:42:02 -0700 Received: from mail174.messagelabs.com ([85.158.138.51]) by lists.xensource.com with esmtp (Exim 4.43) id 1Qz4gW-0002OA-Rp for xen-devel@lists.xensource.com; Thu, 01 Sep 2011 03:39:49 -0700 X-Env-Sender: lidongyang@novell.com X-Msg-Ref: server-9.tower-174.messagelabs.com!1314873574!23831834!1 X-Originating-IP: [137.65.250.26] X-StarScan-Version: 6.3.6; banners=-,-,- X-VirusChecked: Checked Received: (qmail 4080 invoked from network); 1 Sep 2011 10:39:42 -0000 Received: from victor.provo.novell.com (HELO victor.provo.novell.com) (137.65.250.26) by server-9.tower-174.messagelabs.com with DHE-RSA-AES256-SHA encrypted SMTP; 1 Sep 2011 10:39:42 -0000 Received: from localhost.localdomain (prv-ext-foundry1int.gns.novell.com [137.65.251.240]) by victor.provo.novell.com with ESMTP (TLS encrypted); Thu, 01 Sep 2011 04:39:22 -0600 From: Li Dongyang To: xen-devel@lists.xensource.com Date: Thu, 1 Sep 2011 18:39:09 +0800 Message-Id: X-Mailer: git-send-email 1.7.6 In-Reply-To: References: In-Reply-To: References: Cc: owen.smith@citrix.com, JBeulich@novell.com, konrad.wilk@oracle.com Subject: [Xen-devel] [PATCH V4 2/3] xen-blkfront: teach blkfront driver to handle discard requests X-BeenThere: xen-devel@lists.xensource.com X-Mailman-Version: 2.1.5 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xensource.com Errors-To: xen-devel-bounces@lists.xensource.com The blkfront driver now will read discard related nodes from xenstore, and set up the request queue, then we can forward the discard requests to backend driver. Signed-off-by: Li Dongyang --- drivers/block/xen-blkfront.c | 111 +++++++++++++++++++++++++++++++++--------- 1 files changed, 88 insertions(+), 23 deletions(-) diff --git a/drivers/block/xen-blkfront.c b/drivers/block/xen-blkfront.c index 9ea8c25..86e2c63 100644 --- a/drivers/block/xen-blkfront.c +++ b/drivers/block/xen-blkfront.c @@ -98,6 +98,9 @@ struct blkfront_info unsigned long shadow_free; unsigned int feature_flush; unsigned int flush_op; + unsigned int feature_discard; + unsigned int discard_granularity; + unsigned int discard_alignment; int is_ready; }; @@ -302,29 +305,36 @@ static int blkif_queue_request(struct request *req) ring_req->operation = info->flush_op; } - ring_req->nr_segments = blk_rq_map_sg(req->q, req, info->sg); - BUG_ON(ring_req->nr_segments > BLKIF_MAX_SEGMENTS_PER_REQUEST); + if (unlikely(req->cmd_flags & REQ_DISCARD)) { + /* id, sector_number and handle are set above. */ + ring_req->operation = BLKIF_OP_DISCARD; + ring_req->nr_segments = 0; + ring_req->u.discard.nr_sectors = blk_rq_sectors(req); + } else { + ring_req->nr_segments = blk_rq_map_sg(req->q, req, info->sg); + BUG_ON(ring_req->nr_segments > BLKIF_MAX_SEGMENTS_PER_REQUEST); - for_each_sg(info->sg, sg, ring_req->nr_segments, i) { - buffer_mfn = pfn_to_mfn(page_to_pfn(sg_page(sg))); - fsect = sg->offset >> 9; - lsect = fsect + (sg->length >> 9) - 1; - /* install a grant reference. */ - ref = gnttab_claim_grant_reference(&gref_head); - BUG_ON(ref == -ENOSPC); + for_each_sg(info->sg, sg, ring_req->nr_segments, i) { + buffer_mfn = pfn_to_mfn(page_to_pfn(sg_page(sg))); + fsect = sg->offset >> 9; + lsect = fsect + (sg->length >> 9) - 1; + /* install a grant reference. */ + ref = gnttab_claim_grant_reference(&gref_head); + BUG_ON(ref == -ENOSPC); - gnttab_grant_foreign_access_ref( - ref, - info->xbdev->otherend_id, - buffer_mfn, - rq_data_dir(req) ); - - info->shadow[id].frame[i] = mfn_to_pfn(buffer_mfn); - ring_req->u.rw.seg[i] = - (struct blkif_request_segment) { - .gref = ref, - .first_sect = fsect, - .last_sect = lsect }; + gnttab_grant_foreign_access_ref( + ref, + info->xbdev->otherend_id, + buffer_mfn, + rq_data_dir(req)); + + info->shadow[id].frame[i] = mfn_to_pfn(buffer_mfn); + ring_req->u.rw.seg[i] = + (struct blkif_request_segment) { + .gref = ref, + .first_sect = fsect, + .last_sect = lsect }; + } } info->ring.req_prod_pvt++; @@ -399,6 +409,7 @@ wait: static int xlvbd_init_blk_queue(struct gendisk *gd, u16 sector_size) { struct request_queue *rq; + struct blkfront_info *info = gd->private_data; rq = blk_init_queue(do_blkif_request, &blkif_io_lock); if (rq == NULL) @@ -406,6 +417,13 @@ static int xlvbd_init_blk_queue(struct gendisk *gd, u16 sector_size) queue_flag_set_unlocked(QUEUE_FLAG_VIRT, rq); + if (info->feature_discard) { + queue_flag_set_unlocked(QUEUE_FLAG_DISCARD, rq); + blk_queue_max_discard_sectors(rq, get_capacity(gd)); + rq->limits.discard_granularity = info->discard_granularity; + rq->limits.discard_alignment = info->discard_alignment; + } + /* Hard sector size and max sectors impersonate the equiv. hardware. */ blk_queue_logical_block_size(rq, sector_size); blk_queue_max_hw_sectors(rq, 512); @@ -722,6 +740,19 @@ static irqreturn_t blkif_interrupt(int irq, void *dev_id) error = (bret->status == BLKIF_RSP_OKAY) ? 0 : -EIO; switch (bret->operation) { + case BLKIF_OP_DISCARD: + if (unlikely(bret->status == BLKIF_RSP_EOPNOTSUPP)) { + struct request_queue *rq = info->rq; + printk(KERN_WARNING "blkfront: %s: discard op failed\n", + info->gd->disk_name); + error = -EOPNOTSUPP; + info->feature_discard = 0; + spin_lock(rq->queue_lock); + queue_flag_clear(QUEUE_FLAG_DISCARD, rq); + spin_unlock(rq->queue_lock); + } + __blk_end_request_all(req, error); + break; case BLKIF_OP_FLUSH_DISKCACHE: case BLKIF_OP_WRITE_BARRIER: if (unlikely(bret->status == BLKIF_RSP_EOPNOTSUPP)) { @@ -1098,6 +1129,33 @@ blkfront_closing(struct blkfront_info *info) bdput(bdev); } +static void blkfront_setup_discard(struct blkfront_info *info) +{ + int err; + char *type; + unsigned int discard_granularity; + unsigned int discard_alignment; + + type = xenbus_read(XBT_NIL, info->xbdev->otherend, "type", NULL); + if (IS_ERR(type)) + return; + + if (strncmp(type, "phy", 3) == 0) { + err = xenbus_gather(XBT_NIL, info->xbdev->otherend, + "discard-granularity", "%u", &discard_granularity, + "discard-alignment", "%u", &discard_alignment, + NULL); + if (!err) { + info->feature_discard = 1; + info->discard_granularity = discard_granularity; + info->discard_alignment = discard_alignment; + } + } else if (strncmp(type, "file", 4) == 0) + info->feature_discard = 1; + + kfree(type); +} + /* * Invoked when the backend is finally 'ready' (and has told produced * the details about the physical device - #sectors, size, etc). @@ -1108,7 +1166,7 @@ static void blkfront_connect(struct blkfront_info *info) unsigned long sector_size; unsigned int binfo; int err; - int barrier, flush; + int barrier, flush, discard; switch (info->connected) { case BLKIF_STATE_CONNECTED: @@ -1178,7 +1236,14 @@ static void blkfront_connect(struct blkfront_info *info) info->feature_flush = REQ_FLUSH; info->flush_op = BLKIF_OP_FLUSH_DISKCACHE; } - + + err = xenbus_gather(XBT_NIL, info->xbdev->otherend, + "feature-discard", "%d", &discard, + NULL); + + if (!err && discard) + blkfront_setup_discard(info); + err = xlvbd_alloc_gendisk(sectors, info, binfo, sector_size); if (err) { xenbus_dev_fatal(info->xbdev, err, "xlvbd_add at %s", -- 1.7.6 _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel From xen-devel-bounces@lists.xensource.com Thu Sep 01 03:57:19 2011 Return-path: Envelope-to: www-data@lists.xensource.com Delivery-date: Thu, 01 Sep 2011 03:57:19 -0700 Received: from localhost ([127.0.0.1] helo=lists.colo.xensource.com) by lists.xensource.com with esmtp (Exim 4.43) id 1Qz4xS-0004kC-07; Thu, 01 Sep 2011 03:57:18 -0700 Received: from mail182.messagelabs.com ([85.158.139.83]) by lists.xensource.com with esmtp (Exim 4.43) id 1QyoBl-0008Va-RR for xen-devel@lists.xensource.com; Wed, 31 Aug 2011 10:03:16 -0700 X-Env-Sender: bickys1986@gmail.com X-Msg-Ref: server-8.tower-182.messagelabs.com!1314810174!16579509!1 X-Originating-IP: [209.85.215.43] X-StarScan-Version: 6.3.6; banners=-,-,- X-VirusChecked: Checked Received: (qmail 8963 invoked from network); 31 Aug 2011 17:02:54 -0000 Received: from mail-ew0-f43.google.com (HELO mail-ew0-f43.google.com) (209.85.215.43) by server-8.tower-182.messagelabs.com with RC4-SHA encrypted SMTP; 31 Aug 2011 17:02:54 -0000 Received: by ewy20 with SMTP id 20so884462ewy.30 for ; Wed, 31 Aug 2011 10:02:54 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:date:message-id:subject:from:to:cc:content-type; bh=ILCmf46aB+X/EuQp5meUplmdN9+kh0mBbOJbeJqI7PA=; b=Ogh3covCB9DGhWkkRQudRLVGujI1RrOkoHMzoCKqm3GklNojkL0T0nZWs5VihSyW3c uP9cGE95fpQy8s0DhtMBa9XcEE2eSfV3Gr55c8Cr4YYigK2NVXcrgap01fN9b/WqNmqG y2w+IjnvstN9bIEhNWisnDsBIbzrRsvtzJINw= MIME-Version: 1.0 Received: by 10.213.2.141 with SMTP id 13mr409534ebj.89.1314810174388; Wed, 31 Aug 2011 10:02:54 -0700 (PDT) Received: by 10.213.22.6 with HTTP; Wed, 31 Aug 2011 10:02:54 -0700 (PDT) Date: Thu, 1 Sep 2011 01:02:54 +0800 Message-ID: From: zhen shi To: olaf@aepfle.de Content-Type: multipart/mixed; boundary=0015174be08064387904abd01977 X-Mailman-Approved-At: Thu, 01 Sep 2011 03:55:19 -0700 Cc: xen-devel@lists.xensource.com Subject: [Xen-devel] some questions of IO ring in xenpaging X-BeenThere: xen-devel@lists.xensource.com X-Mailman-Version: 2.1.5 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xensource.com Errors-To: xen-devel-bounces@lists.xensource.com --0015174be08064387904abd01977 Content-Type: text/plain; charset=GB2312 Content-Transfer-Encoding: quoted-printable Hi Olaf -- I have two questions to ask you about xenpaging. 1) When guest os causes page_fault for the accessed page is paging_out or paged,it will execute p2m_mem_paging_populate() . and in p2m_mem_paging_populate() it will first check if the ring is full. when I ran with domU suse11 4G memory and 8vcpus,I found there will be a corruption in checking the ring. For example,if 4vcpus are met with page faults when they access different pages,and there is only four free-requests for the ring. and then they call p2m_mem_paging_populate(),and execute mem_event_check_ring(d) at the same time.All will find ring is not full,and will fill the requests.It will cause the latter request to cover the front request. and I think there should a lock before the mem_event_check_ring(d) ,and normally it unlock after mem_event_put_request(d, &req). You can review the attached doc of xenpaging_IO_ring.txt to see if my opnion is right. 2)mem_sharing and xenpaging are shared with one IO ring for domU.In the function of mem_sharing_alloc_page(),if alloc_domheap_page(d, 0) returns NULL,then it will pause VCPU ,check if the ring is full,and fill the request at last. I think there is also a corruption of mem_event_check_ring(d) with it in p2m_mem_paging_populate().We should assure exclusively in reading the free_request and puting requests. What's more,although it hardly fails in alloc_domheap_page(d, 0) from mem_sharing_alloc_page() ,it will fill the requests in IO ring. But in xenpaging when handling the page_in requests,we have not distinguished the requests with flag "MEM_EVENT_FLAG_VCPU_PAUSED" from paging or sharing.It will cause if the request is from mem_sharing_alloc_page(),it will go to p2m_mem_paging_resume() at last,and the page's p2mt is p2m_ram_rw.I think this is wrong.Maybe we should add the req.type when page in . I'm so sorry to have a poor English.But I look forward to your early reply. Thank you=A3=A1 --0015174be08064387904abd01977 Content-Type: text/plain; charset=US-ASCII; name="xenpaging_IO_ring.txt" Content-Disposition: attachment; filename="xenpaging_IO_ring.txt" Content-Transfer-Encoding: base64 X-Attachment-Id: f_gs0jy6ho1 dm9pZCBwMm1fbWVtX3BhZ2luZ19wb3B1bGF0ZShzdHJ1Y3QgcDJtX2RvbWFpbiAqcDJtLCB1bnNp Z25lZCBsb25nIGdmbikNCnsNCiAgICBzdHJ1Y3QgdmNwdSAqdiA9IGN1cnJlbnQ7DQogICAgbWVt X2V2ZW50X3JlcXVlc3RfdCByZXE7DQogICAgcDJtX3R5cGVfdCBwMm10Ow0KICAgIHN0cnVjdCBk b21haW4gKmQgPSBwMm0tPmRvbWFpbjsNCg0KICsgIHAybV9sb2NrKHAybSk7DQogICAgLyogQ2hl Y2sgdGhhdCB0aGVyZSdzIHNwYWNlIG9uIHRoZSByaW5nIGZvciB0aGlzIHJlcXVlc3QgKi8NCiAg ICBpZiAoIG1lbV9ldmVudF9jaGVja19yaW5nKGQpICkNCisgIHsNCisgICAgIHAybV91bmxvY2so cDJtKTsNCiAgICAgICAgcmV0dXJuOw0KKyB9DQoNCiAgICBtZW1zZXQoJnJlcSwgMCwgc2l6ZW9m KHJlcSkpOw0KICAgIHJlcS50eXBlID0gTUVNX0VWRU5UX1RZUEVfUEFHSU5HOw0KDQogICAgLyog Rml4IHAybSBtYXBwaW5nICovDQogICAgLyogWFhYOiBJdCBzZWVtcyBpbmVmZmljaWVudCB0byBo YXZlIHRoaXMgaGVyZSwgYXMgaXQncyBvbmx5IG5lZWRlZA0KICAgICAqICAgICAgaW4gb25lIGNh c2UgKGVwdCBndWVzdCBhY2Nlc3NpbmcgcGFnaW5nIG91dCBwYWdlKSAqLw0KICAgIGdmbl90b19t Zm4ocDJtLCBnZm4sICZwMm10KTsNCiAgICBpZiAoIHAybXQgPT0gcDJtX3JhbV9wYWdlZCApDQog ICAgew0KLSAgICAgIHAybV9sb2NrKHAybSk7DQogICAgICAgIHNldF9wMm1fZW50cnkocDJtLCBn Zm4sIF9tZm4oUEFHSU5HX01GTiksIDAsIHAybV9yYW1fcGFnaW5nX2luX3N0YXJ0LCBwMm0tPmRl ZmF1bHRfYWNjZXNzKTsNCiAgICAgICAgYXVkaXRfcDJtKHAybSwgMSk7DQotICAgICBwMm1fdW5s b2NrKHAybSk7DQogICAgfQ0KDQogICAgLyogUGF1c2UgZG9tYWluICovDQogICAgaWYgKCB2LT5k b21haW4tPmRvbWFpbl9pZCA9PSBkLT5kb21haW5faWQgKQ0KICAgIHsNCiAgICAgICAgdmNwdV9w YXVzZV9ub3N5bmModik7DQogICAgICAgIHJlcS5mbGFncyB8PSBNRU1fRVZFTlRfRkxBR19WQ1BV X1BBVVNFRDsNCiAgICB9DQogICAgZWxzZSBpZiAoIHAybXQgIT0gcDJtX3JhbV9wYWdpbmdfb3V0 ICYmIHAybXQgIT0gcDJtX3JhbV9wYWdlZCApDQogICAgew0KICAgICAgICAvKiBnZm4gaXMgYWxy ZWFkeSBvbiBpdHMgd2F5IGJhY2sgYW5kIHZjcHUgaXMgbm90IHBhdXNlZCAqLw0KKyAgICAgcDJt X3VubG9jayhwMm0pOw0KICAgICAgICByZXR1cm47DQogICAgfQ0KDQogICAgLyogU2VuZCByZXF1 ZXN0IHRvIHBhZ2VyICovDQogICAgcmVxLmdmbiA9IGdmbjsNCiAgICByZXEucDJtdCA9IHAybXQ7 DQogICAgcmVxLnZjcHVfaWQgPSB2LT52Y3B1X2lkOw0KDQogICAgbWVtX2V2ZW50X3B1dF9yZXF1 ZXN0KGQsICZyZXEpOw0KKyBwMm1fdW5sb2NrKHAybSk7DQp9DQo= --0015174be08064387904abd01977 Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel --0015174be08064387904abd01977-- From xen-devel-bounces@lists.xensource.com Thu Sep 01 04:06:20 2011 Return-path: Envelope-to: www-data@lists.xensource.com Delivery-date: Thu, 01 Sep 2011 04:06:20 -0700 Received: from localhost ([127.0.0.1] helo=lists.colo.xensource.com) by lists.xensource.com with esmtp (Exim 4.43) id 1Qz56B-0005Pg-Op; Thu, 01 Sep 2011 04:06:19 -0700 Received: from mail174.messagelabs.com ([85.158.138.51]) by lists.xensource.com with esmtp (Exim 4.43) id 1Qz53u-00058l-1Q for xen-devel@lists.xensource.com; Thu, 01 Sep 2011 04:04:07 -0700 X-Env-Sender: lidongyang@novell.com X-Msg-Ref: server-9.tower-174.messagelabs.com!1314875028!23835651!1 X-Originating-IP: [137.65.250.26] X-StarScan-Version: 6.3.6; banners=-,-,- X-VirusChecked: Checked Received: (qmail 28939 invoked from network); 1 Sep 2011 11:03:52 -0000 Received: from victor.provo.novell.com (HELO victor.provo.novell.com) (137.65.250.26) by server-9.tower-174.messagelabs.com with DHE-RSA-AES256-SHA encrypted SMTP; 1 Sep 2011 11:03:52 -0000 Received: from localhost.localdomain (prv-ext-foundry1int.gns.novell.com [137.65.251.240]) by victor.provo.novell.com with ESMTP (TLS encrypted); Thu, 01 Sep 2011 04:39:18 -0600 From: Li Dongyang To: xen-devel@lists.xensource.com Date: Thu, 1 Sep 2011 18:39:07 +0800 Message-Id: X-Mailer: git-send-email 1.7.6 Cc: owen.smith@citrix.com, JBeulich@novell.com, konrad.wilk@oracle.com Subject: [Xen-devel] [PATCH V4 0/3] xen-blkfront/blkback discard support X-BeenThere: xen-devel@lists.xensource.com X-Mailman-Version: 2.1.5 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xensource.com Errors-To: xen-devel-bounces@lists.xensource.com Dear list, This is the V4 of the trim support for xen-blkfront/blkback, Now we move BLKIF_OP_TRIM to BLKIF_OP_DISCARD, and dropped all "trim" stuffs in the patches, and use "discard" instead. Also we updated the helpers of blkif_x86_{32|64}_request or we will meet problems using a non-native protocol. And this patch has been tested with both SSD and raw file, with SSD we will forward the discard command and with raw file, the disk usage will reduce as we send discard request in the guest. Changelog V4: switch from BLKIF_OP_TRIM to BLKIF_OP_DISCARD make blkback work with non-native protocol do not abort connection in blkback if we can not setup discard in xenstore Changelog V3: rebased on linus's tree enum backend types in blkif instead of flags in the interface header more reasonable names in xenstore move trim requesting handling to a separate function do not re-enable interrupts unconditionally when handling response set info->feature-trim only when we have all info needed for request queue Changelog V2: rebased on Jeremy's tree fixes according to Jan Beulich's comments Li Dongyang (3): xen-blkfront: add BLKIF_OP_DISCARD and discard request struct xen-blkfront: teach blkfront driver to handle discard requests xen-blkback: discard requests handling in blkback driver drivers/block/xen-blkback/blkback.c | 87 +++++++++++++++++++++++----- drivers/block/xen-blkback/common.h | 93 ++++++++++++++++++++++++----- drivers/block/xen-blkback/xenbus.c | 58 ++++++++++++++++++ drivers/block/xen-blkfront.c | 111 +++++++++++++++++++++++++++------- include/xen/interface/io/blkif.h | 36 +++++++++++ 5 files changed, 331 insertions(+), 54 deletions(-) -- 1.7.6 _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel From xen-devel-bounces@lists.xensource.com Thu Sep 01 04:07:46 2011 Return-path: Envelope-to: www-data@lists.xensource.com Delivery-date: Thu, 01 Sep 2011 04:07:46 -0700 Received: from localhost ([127.0.0.1] helo=lists.colo.xensource.com) by lists.xensource.com with esmtp (Exim 4.43) id 1Qz57a-0005nE-Cu; Thu, 01 Sep 2011 04:07:46 -0700 Received: from mail21.messagelabs.com ([85.158.143.35]) by lists.xensource.com with esmtp (Exim 4.43) id 1Qz54M-0005C9-UJ for xen-devel@lists.xensource.com; Thu, 01 Sep 2011 04:04:36 -0700 X-Env-Sender: George.Dunlap@eu.citrix.com X-Msg-Ref: server-13.tower-21.messagelabs.com!1314875057!47289911!1 X-Originating-IP: [66.165.176.63] X-StarScan-Version: 6.3.6; banners=-,-,- X-VirusChecked: Checked Received: (qmail 1139 invoked from network); 1 Sep 2011 11:04:18 -0000 Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63) by server-13.tower-21.messagelabs.com with RC4-SHA encrypted SMTP; 1 Sep 2011 11:04:18 -0000 X-IronPort-AV: E=Sophos;i="4.68,313,1312171200"; d="scan'208";a="161406934" Received: from ftlpmailmx01.citrite.net ([10.13.107.65]) by FTLPIPO02.CITRIX.COM with ESMTP/TLS/RC4-MD5; 01 Sep 2011 07:04:22 -0400 Received: from smtp01.ad.xensource.com (10.219.128.104) by smtprelay.citrix.com (10.13.107.65) with Microsoft SMTP Server id 8.3.137.0; Thu, 1 Sep 2011 07:04:21 -0400 Received: from [127.0.1.1] (elijah.uk.xensource.com [10.80.2.24]) by smtp01.ad.xensource.com (8.13.1/8.13.1) with ESMTP id p81B4KMw028414; Thu, 1 Sep 2011 04:04:21 -0700 Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Mercurial-Node: 4f27afd5c1d361232ae973f61933003b99224ce1 Message-ID: <4f27afd5c1d361232ae9.1314874742@elijah> User-Agent: Mercurial-patchbomb/1.4.3 Date: Thu, 1 Sep 2011 11:59:02 +0100 From: George Dunlap To: xen-devel@lists.xensource.com Cc: george.dunlap@eu.citrix.com Subject: [Xen-devel] [PATCH] xen: Add global irq_vector_map option, set if using AMD global intremap tables X-BeenThere: xen-devel@lists.xensource.com X-Mailman-Version: 2.1.5 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xensource.com Errors-To: xen-devel-bounces@lists.xensource.com As mentioned in previous changesets, AMD IOMMU interrupt remapping tables only look at the vector, not the destination id of an interrupt. This means that all IRQs going through the same interrupt remapping table need to *not* share vectors. The irq "vector map" functionality was originally introduced after a patch which disabled global AMD IOMMUs entirely. That patch has since been reverted, meaning that AMD intremap tables can either be per-device or global. This patch therefore introduces a global irq vector map option, and enables it if we're using an AMD IOMMU with a global interrupt remapping table. This patch removes the "irq-perdev-vector-map" boolean command-line optino and replaces it with "irq_vector_map", which can have one of three values: none, global, or per-device. Setting the irq_vector_map to any value will override the default that the AMD code sets. Signed-off-by: George Dunlap diff -r 4a4882df5649 -r 4f27afd5c1d3 docs/src/user.tex --- a/docs/src/user.tex Wed Aug 31 15:23:49 2011 +0100 +++ b/docs/src/user.tex Thu Sep 01 11:58:40 2011 +0100 @@ -2280,6 +2280,10 @@ writing to the VGA console after domain \item [ vcpu\_migration\_delay=$<$minimum\_time$>$] Set minimum time of vcpu migration in microseconds (default 0). This parameter avoids agressive vcpu migration. For example, the linux kernel uses 0.5ms by default. +\item [ irq_vector_map=xxx ] Enable irq vector non-sharing maps. Setting 'global' + will ensure that no IRQs will share vectors. Setting 'per-device' will ensure + that no IRQs from the same device will share vectors. Setting to 'none' will + disable it entirely, overriding any defaults the IOMMU code may set. \end{description} In addition, the following options may be specified on the Xen command diff -r 4a4882df5649 -r 4f27afd5c1d3 xen/arch/x86/irq.c --- a/xen/arch/x86/irq.c Wed Aug 31 15:23:49 2011 +0100 +++ b/xen/arch/x86/irq.c Thu Sep 01 11:58:40 2011 +0100 @@ -24,6 +24,8 @@ #include #include +static void parse_irq_vector_map_param(char *s); + /* opt_noirqbalance: If true, software IRQ balancing/affinity is disabled. */ bool_t __read_mostly opt_noirqbalance = 0; boolean_param("noirqbalance", opt_noirqbalance); @@ -33,8 +35,10 @@ unsigned int __read_mostly nr_irqs; integer_param("nr_irqs", nr_irqs); /* This default may be changed by the AMD IOMMU code */ -bool_t __read_mostly opt_irq_perdev_vector_map = 0; -boolean_param("irq-perdev-vector-map", opt_irq_perdev_vector_map); +int __read_mostly opt_irq_vector_map = OPT_IRQ_VECTOR_MAP_DEFAULT; +custom_param("irq_vector_map", parse_irq_vector_map_param); + +vmask_t global_used_vector_map; u8 __read_mostly *irq_vector; struct irq_desc __read_mostly *irq_desc = NULL; @@ -64,6 +68,26 @@ static struct timer irq_ratelimit_timer; static unsigned int __read_mostly irq_ratelimit_threshold = 10000; integer_param("irq_ratelimit", irq_ratelimit_threshold); +static void __init parse_irq_vector_map_param(char *s) +{ + char *ss; + + do { + ss = strchr(s, ','); + if ( ss ) + *ss = '\0'; + + if ( !strcmp(s, "none")) + opt_irq_vector_map=OPT_IRQ_VECTOR_MAP_NONE; + else if ( !strcmp(s, "global")) + opt_irq_vector_map=OPT_IRQ_VECTOR_MAP_GLOBAL; + else if ( !strcmp(s, "per-device")) + opt_irq_vector_map=OPT_IRQ_VECTOR_MAP_PERDEV; + + s = ss + 1; + } while ( ss ); +} + /* Must be called when irq disabled */ void lock_vector_lock(void) { @@ -365,6 +389,41 @@ hw_irq_controller no_irq_type = { end_none }; +static vmask_t *irq_get_used_vector_mask(int irq) +{ + vmask_t *ret = NULL; + + if ( opt_irq_vector_map == OPT_IRQ_VECTOR_MAP_GLOBAL ) + { + struct irq_desc *desc = irq_to_desc(irq); + + ret = &global_used_vector_map; + + if ( desc->chip_data->used_vectors ) + { + printk(XENLOG_INFO "%s: Strange, unassigned irq %d already has used_vectors!\n", + __func__, irq); + } + else + { + int vector; + + vector = irq_to_vector(irq); + if ( vector > 0 ) + { + printk(XENLOG_INFO "%s: Strange, irq %d already assigned vector %d!\n", + __func__, irq, vector); + + ASSERT(!test_bit(vector, ret)); + + set_bit(vector, ret); + } + } + } + + return ret; +} + int __assign_irq_vector(int irq, struct irq_cfg *cfg, const cpumask_t *mask) { /* @@ -383,6 +442,7 @@ int __assign_irq_vector(int irq, struct int cpu, err; unsigned long flags; cpumask_t tmp_mask; + vmask_t *irq_used_vectors = NULL; old_vector = irq_to_vector(irq); if (old_vector) { @@ -397,6 +457,17 @@ int __assign_irq_vector(int irq, struct return -EAGAIN; err = -ENOSPC; + + /* This is the only place normal IRQs are ever marked + * as "in use". If they're not in use yet, check to see + * if we need to assign a global vector mask. */ + if ( irq_status[irq] == IRQ_USED ) + { + irq_used_vectors = cfg->used_vectors; + } + else + irq_used_vectors = irq_get_used_vector_mask(irq); + for_each_cpu_mask(cpu, *mask) { int new_cpu; int vector, offset; @@ -422,8 +493,8 @@ next: if (test_bit(vector, used_vectors)) goto next; - if (cfg->used_vectors - && test_bit(vector, cfg->used_vectors) ) + if (irq_used_vectors + && test_bit(vector, irq_used_vectors) ) goto next; for_each_cpu_mask(new_cpu, tmp_mask) @@ -442,15 +513,22 @@ next: per_cpu(vector_irq, new_cpu)[vector] = irq; cfg->vector = vector; cpus_copy(cfg->cpu_mask, tmp_mask); + + irq_status[irq] = IRQ_USED; + ASSERT((cfg->used_vectors == NULL) + || (cfg->used_vectors == irq_used_vectors)); + cfg->used_vectors = irq_used_vectors; + + if (IO_APIC_IRQ(irq)) + irq_vector[irq] = vector; + if ( cfg->used_vectors ) { ASSERT(!test_bit(vector, cfg->used_vectors)); + set_bit(vector, cfg->used_vectors); } - irq_status[irq] = IRQ_USED; - if (IO_APIC_IRQ(irq)) - irq_vector[irq] = vector; err = 0; local_irq_restore(flags); break; @@ -1621,7 +1699,7 @@ int map_domain_pirq( if ( !IS_PRIV(current->domain) && !(IS_PRIV_FOR(current->domain, d) && - irq_access_permitted(current->domain, pirq))) + irq_access_permitted(current->domain, pirq))) return -EPERM; if ( pirq < 0 || pirq >= d->nr_pirqs || irq < 0 || irq >= nr_irqs ) @@ -1673,11 +1751,22 @@ int map_domain_pirq( if ( desc->handler != &no_irq_type ) dprintk(XENLOG_G_ERR, "dom%d: irq %d in use\n", - d->domain_id, irq); + d->domain_id, irq); desc->handler = &pci_msi_type; - if ( opt_irq_perdev_vector_map + + if ( opt_irq_vector_map == OPT_IRQ_VECTOR_MAP_PERDEV && !desc->chip_data->used_vectors ) + { desc->chip_data->used_vectors = &pdev->info.used_vectors; + if ( desc->chip_data->vector != IRQ_VECTOR_UNASSIGNED ) + { + int vector = desc->chip_data->vector; + ASSERT(!test_bit(vector, desc->chip_data->used_vectors)); + + set_bit(vector, desc->chip_data->used_vectors); + } + } + set_domain_irq_pirq(d, irq, info); setup_msi_irq(msi_desc, irq); spin_unlock_irqrestore(&desc->lock, flags); @@ -1687,9 +1776,12 @@ int map_domain_pirq( spin_lock_irqsave(&desc->lock, flags); set_domain_irq_pirq(d, irq, info); spin_unlock_irqrestore(&desc->lock, flags); + + if ( opt_irq_vector_map == OPT_IRQ_VECTOR_MAP_PERDEV ) + printk(XENLOG_INFO "Per-device vector maps for GSIs not implemented yet.\n"); } - done: +done: if ( ret ) cleanup_domain_irq_pirq(d, irq, info); return ret; diff -r 4a4882df5649 -r 4f27afd5c1d3 xen/drivers/passthrough/amd/pci_amd_iommu.c --- a/xen/drivers/passthrough/amd/pci_amd_iommu.c Wed Aug 31 15:23:49 2011 +0100 +++ b/xen/drivers/passthrough/amd/pci_amd_iommu.c Thu Sep 01 11:58:40 2011 +0100 @@ -167,18 +167,35 @@ int __init amd_iov_detect(void) return -ENODEV; } - /* Enable use of per-device vector map unless otherwise - * specified */ - if ( iommu_amd_perdev_vector_map ) + /* + * AMD IOMMUs don't distinguish between vectors destined for + * different cpus when doing interrupt remapping. This means + * that interrupts going through the same intremap table + * can't share the same vector. + * + * If irq_vector_map isn't specified, choose a sensible default: + * - If we're using per-device interemap tables, per-device + * vector non-sharing maps + * - If we're using a global interemap table, global vector + * non-sharing map + */ + if ( opt_irq_vector_map == OPT_IRQ_VECTOR_MAP_DEFAULT ) { - printk("AMD-Vi: Enabling per-device vector maps\n"); - opt_irq_perdev_vector_map=1; + if ( amd_iommu_perdev_intremap ) + { + printk("AMD-Vi: Enabling per-device vector maps\n"); + opt_irq_vector_map = OPT_IRQ_VECTOR_MAP_PERDEV; + } + else + { + printk("AMD-Vi: Enabling global vector map\n"); + opt_irq_vector_map = OPT_IRQ_VECTOR_MAP_GLOBAL; + } } else { - printk("AMD-Vi: WARNING - not enabling per-device vector maps\n"); + printk("AMD-Vi: Not overriding irq_vector_map setting\n"); } - return scan_pci_devices(); } diff -r 4a4882df5649 -r 4f27afd5c1d3 xen/include/asm-x86/irq.h --- a/xen/include/asm-x86/irq.h Wed Aug 31 15:23:49 2011 +0100 +++ b/xen/include/asm-x86/irq.h Thu Sep 01 11:58:40 2011 +0100 @@ -46,6 +46,13 @@ extern u8 *irq_vector; extern bool_t opt_noirqbalance; +#define OPT_IRQ_VECTOR_MAP_DEFAULT 0 /* Do the default thing */ +#define OPT_IRQ_VECTOR_MAP_NONE 1 /* None */ +#define OPT_IRQ_VECTOR_MAP_GLOBAL 2 /* One global vector map (no vector sharing) */ +#define OPT_IRQ_VECTOR_MAP_PERDEV 3 /* Per-device vetor map (no vector sharing w/in a device) */ + +extern int opt_irq_vector_map; + /* * Per-cpu current frame pointer - the location of the last exception frame on * the stack _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel From xen-devel-bounces@lists.xensource.com Thu Sep 01 04:51:54 2011 Return-path: Envelope-to: www-data@lists.xensource.com Delivery-date: Thu, 01 Sep 2011 04:51:54 -0700 Received: from localhost ([127.0.0.1] helo=lists.colo.xensource.com) by lists.xensource.com with esmtp (Exim 4.43) id 1Qz5oI-0007vl-BJ; Thu, 01 Sep 2011 04:51:54 -0700 Received: from mail174.messagelabs.com ([85.158.138.51]) by lists.xensource.com with esmtp (Exim 4.43) id 1Qz5nO-0007io-Us for xen-devel@lists.xensource.com; Thu, 01 Sep 2011 04:50:59 -0700 X-Env-Sender: david.vrabel@citrix.com X-Msg-Ref: server-7.tower-174.messagelabs.com!1314877852!29860189!1 X-Originating-IP: [66.165.176.89] X-StarScan-Version: 6.3.6; banners=-,-,- X-VirusChecked: Checked Received: (qmail 2137 invoked from network); 1 Sep 2011 11:50:55 -0000 Received: from smtp.citrix.com (HELO SMTP.CITRIX.COM) (66.165.176.89) by server-7.tower-174.messagelabs.com with RC4-SHA encrypted SMTP; 1 Sep 2011 11:50:55 -0000 X-IronPort-AV: E=Sophos;i="4.68,313,1312171200"; d="scan'208";a="16620250" Received: from ftlpmailmx02.citrite.net ([10.13.107.66]) by FTLPIPO01.CITRIX.COM with ESMTP/TLS/RC4-MD5; 01 Sep 2011 07:50:52 -0400 Received: from smtp01.ad.xensource.com (10.219.128.104) by smtprelay.citrix.com (10.13.107.66) with Microsoft SMTP Server id 8.3.137.0; Thu, 1 Sep 2011 07:50:52 -0400 Received: from qabil.uk.xensource.com (qabil.uk.xensource.com [10.80.2.76]) by smtp01.ad.xensource.com (8.13.1/8.13.1) with ESMTP id p81BonXm028531; Thu, 1 Sep 2011 04:50:50 -0700 From: David Vrabel To: xen-devel@lists.xensource.com Date: Thu, 1 Sep 2011 12:51:03 +0100 Message-ID: <1314877863-21977-1-git-send-email-david.vrabel@citrix.com> X-Mailer: git-send-email 1.7.2.5 MIME-Version: 1.0 Content-Type: text/plain Cc: Jeremy Fitzhardinge , David Vrabel , Konrad Rzeszutek Wilk Subject: [Xen-devel] [PATCH] mm: sync vmalloc address space page tables in alloc_vm_area() X-BeenThere: xen-devel@lists.xensource.com X-Mailman-Version: 2.1.5 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xensource.com Errors-To: xen-devel-bounces@lists.xensource.com From: David Vrabel Xen backend drivers (e.g., blkback and netback) would sometimes fail to map grant pages into the vmalloc address space allocated with alloc_vm_area(). The GNTTABOP_map_grant_ref would fail because Xen could not find the page (in the L2 table) containing the PTEs it needed to update. (XEN) mm.c:3846:d0 Could not find L1 PTE for address fbb42000 netback and blkback were making the hypercall from a kernel thread where task->active_mm != &init_mm and alloc_vm_area() was only updating the page tables for init_mm. The usual method of deferring the update to the page tables of other processes (i.e., after taking a fault) doesn't work as a fault cannot occur during the hypercall. This would work on some systems depending on what else was using vmalloc. Fix this by reverting ef691947d8a3d479e67652312783aedcf629320a (vmalloc: remove vmalloc_sync_all() from alloc_vm_area()) and add a comment to explain why it's needed. Signed-off-by: David Vrabel Cc: Jeremy Fitzhardinge --- mm/vmalloc.c | 8 ++++++++ 1 files changed, 8 insertions(+), 0 deletions(-) diff --git a/mm/vmalloc.c b/mm/vmalloc.c index 7ef0903..5016f19 100644 --- a/mm/vmalloc.c +++ b/mm/vmalloc.c @@ -2140,6 +2140,14 @@ struct vm_struct *alloc_vm_area(size_t size) return NULL; } + /* + * If the allocated address space is passed to a hypercall + * before being used then we cannot rely on a page fault to + * trigger an update of the page tables. So sync all the page + * tables here. + */ + vmalloc_sync_all(); + return area; } EXPORT_SYMBOL_GPL(alloc_vm_area); -- 1.7.2.5 _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel From xen-devel-bounces@lists.xensource.com Thu Sep 01 05:11:12 2011 Return-path: Envelope-to: www-data@lists.xensource.com Delivery-date: Thu, 01 Sep 2011 05:11:12 -0700 Received: from localhost ([127.0.0.1] helo=lists.colo.xensource.com) by lists.xensource.com with esmtp (Exim 4.43) id 1Qz66y-00008m-3c; Thu, 01 Sep 2011 05:11:12 -0700 Received: from mail27.messagelabs.com ([193.109.254.147]) by lists.xensource.com with esmtp (Exim 4.43) id 1Qz65o-0008NJ-2f for xen-devel@lists.xensource.com; Thu, 01 Sep 2011 05:10:04 -0700 X-Env-Sender: david.vrabel@citrix.com X-Msg-Ref: server-8.tower-27.messagelabs.com!1314878982!44815905!1 X-Originating-IP: [66.165.176.63] X-StarScan-Version: 6.3.6; banners=-,-,- X-VirusChecked: Checked Received: (qmail 1035 invoked from network); 1 Sep 2011 12:09:43 -0000 Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63) by server-8.tower-27.messagelabs.com with RC4-SHA encrypted SMTP; 1 Sep 2011 12:09:43 -0000 X-IronPort-AV: E=Sophos;i="4.68,313,1312171200"; d="scan'208";a="161412858" Received: from ftlpmailmx02.citrite.net ([10.13.107.66]) by FTLPIPO02.CITRIX.COM with ESMTP/TLS/RC4-MD5; 01 Sep 2011 08:09:55 -0400 Received: from [10.80.2.76] (10.80.2.76) by FTLPMAILMX02.citrite.net (10.13.107.66) with Microsoft SMTP Server id 8.3.137.0; Thu, 1 Sep 2011 08:09:55 -0400 Message-ID: <4E5F769A.5080303@citrix.com> Date: Thu, 1 Sep 2011 13:12:10 +0100 From: David Vrabel User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.1.16) Gecko/20110818 Icedove/3.0.11 MIME-Version: 1.0 To: Konrad Rzeszutek Wilk Subject: Re: [Xen-devel] [PATCH 1/5] xen: use maximum reservation to limit amount of usable RAM References: <1313765840-22084-1-git-send-email-david.vrabel@citrix.com> <1313765840-22084-2-git-send-email-david.vrabel@citrix.com> <20110831204057.GA641@dumpdata.com> In-Reply-To: <20110831204057.GA641@dumpdata.com> Content-Type: text/plain; charset="ISO-8859-1" Content-Transfer-Encoding: 7bit Cc: "xen-devel@lists.xensource.com" X-BeenThere: xen-devel@lists.xensource.com X-Mailman-Version: 2.1.5 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xensource.com Errors-To: xen-devel-bounces@lists.xensource.com On 31/08/11 21:40, Konrad Rzeszutek Wilk wrote: >> Signed-off-by: David Vrabel >> --- >> arch/x86/xen/setup.c | 19 +++++++++++++++++++ >> 1 files changed, 19 insertions(+), 0 deletions(-) >> >> diff --git a/arch/x86/xen/setup.c b/arch/x86/xen/setup.c >> index df118a8..c3b8d44 100644 >> --- a/arch/x86/xen/setup.c >> +++ b/arch/x86/xen/setup.c >> @@ -184,6 +184,19 @@ static unsigned long __init xen_set_identity(const struct e820entry *list, >> PFN_UP(start_pci), PFN_DOWN(last)); >> return identity; >> } >> + >> +static unsigned long __init xen_get_max_pages(void) >> +{ >> + unsigned long max_pages = MAX_DOMAIN_PAGES; >> + domid_t domid = DOMID_SELF; >> + int ret; >> + >> + ret = HYPERVISOR_memory_op(XENMEM_maximum_reservation, &domid); >> + if (ret > 0) >> + max_pages = ret; >> + return min(max_pages, MAX_DOMAIN_PAGES); >> +} >> + >> /** >> * machine_specific_memory_setup - Hook for machine specific memory setup. >> **/ >> @@ -292,6 +305,12 @@ char * __init xen_memory_setup(void) >> >> sanitize_e820_map(e820.map, ARRAY_SIZE(e820.map), &e820.nr_map); >> >> + extra_limit = xen_get_max_pages(); >> + if (extra_limit >= max_pfn) >> + extra_pages = extra_limit - max_pfn; >> + else >> + extra_pages = 0; >> + >> extra_pages += xen_return_unused_memory(xen_start_info->nr_pages, &e820); > > I ran this on three setups: > > 1) PV (domU) > 2) PV+PCI (dom0) > 3) PV+PCI+e820_hole=1 (domU) > > and then the same without this patch. > > Both the 2) and 3) worked correctly - the E820 had the same non-RAM regions and > gaps - and the last RAM E820 entry was properly truncated. However, when it > came to pure PV it was truncated more than it should: > > domU: domU: > 0000000000000000 - 00000000000a0000 (usable) 0000000000000000 - 00000000000a0000 (usable) > 00000000000a0000 - 0000000000100000 (reserved) 00000000000a0000 - 0000000000100000 (reserved) > 0000000000100000 - 0000000040800000 (usable) | 0000000000100000 - 0000000040100000 (usable) > > (left has the old PV - without your patch). Which makes me think that there is something > amiss in the toolstack? I used 'xl' (latest xen-unstable from today). What were you expecting? It looks like xl is either: specifying a memory map that is larger than it should be or b) setting the maximum reservation as too low. And if you asked for 1 GiB neither looks right. David _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel From xen-devel-bounces@lists.xensource.com Thu Sep 01 05:31:18 2011 Return-path: Envelope-to: www-data@lists.xensource.com Delivery-date: Thu, 01 Sep 2011 05:31:18 -0700 Received: from localhost ([127.0.0.1] helo=lists.colo.xensource.com) by lists.xensource.com with esmtp (Exim 4.43) id 1Qz6QQ-0000td-PV; Thu, 01 Sep 2011 05:31:18 -0700 Received: from mail174.messagelabs.com ([85.158.138.51]) by lists.xensource.com with esmtp (Exim 4.43) id 1Qz6Ps-0000hN-3f for xen-devel@lists.xensource.com; Thu, 01 Sep 2011 05:30:45 -0700 X-Env-Sender: deepak.s@hcl.com X-Msg-Ref: server-3.tower-174.messagelabs.com!1314880231!23814583!1 X-Originating-IP: [203.105.186.26] X-StarScan-Version: 6.3.6; banners=-,-,- X-VirusChecked: Checked Received: (qmail 16369 invoked from network); 1 Sep 2011 12:30:35 -0000 Received: from gws08.hcl.com (HELO gws08.hcl.com) (203.105.186.26) by server-3.tower-174.messagelabs.com with AES256-SHA encrypted SMTP; 1 Sep 2011 12:30:35 -0000 Received: from chn-hclin-ht02.CORP.HCL.IN (10.249.64.36) by CHN-HCLIN-EDGE4.HCL.COM (10.249.64.141) with Microsoft SMTP Server id 8.2.254.0; Thu, 1 Sep 2011 17:58:59 +0530 Received: from CHN-HCLT-HT03.HCLT.CORP.HCL.IN (10.108.45.35) by chn-hclin-ht02.CORP.HCL.IN (10.249.64.36) with Microsoft SMTP Server (TLS) id 8.2.254.0; Thu, 1 Sep 2011 18:00:28 +0530 Received: from CHN-HCLT-EVS07.HCLT.CORP.HCL.IN ([fe80::3d0d:efa3:3da8:2ae9]) by CHN-HCLT-HT03.HCLT.CORP.HCL.IN ([::1]) with mapi; Thu, 1 Sep 2011 18:00:28 +0530 From: "Deepak Kr. Sharma - ERS, HCL Tech" To: Stefano Stabellini Date: Thu, 1 Sep 2011 18:00:26 +0530 Subject: RE: [Xen-devel] FW: HXEN on linux Thread-Topic: [Xen-devel] FW: HXEN on linux Thread-Index: Acxj568oIRiOvjHGThudZ5CbmwFcywC+2qvwAG/eYmA= Message-ID: <90F0F47595235141A4380FCF01B0185B20BC608BBC@CHN-HCLT-EVS07.HCLT.CORP.HCL.IN> References: <90F0F47595235141A4380FCF01B0185B20BC426222@CHN-HCLT-EVS07.HCLT.CORP.HCL.IN> <20110809195159.GA7834@dumpdata.com> <90F0F47595235141A4380FCF01B0185B20BC513BCB@CHN-HCLT-EVS07.HCLT.CORP.HCL.IN> <90F0F47595235141A4380FCF01B0185B20BC585A8A@CHN-HCLT-EVS07.HCLT.CORP.HCL.IN> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: multipart/mixed; boundary="_002_90F0F47595235141A4380FCF01B0185B20BC608BBCCHNHCLTEVS07H_" MIME-Version: 1.0 Cc: "todd.deshane.xen@gmail.com" , "xen-devel@lists.xensource.com" , Lars Kurth , Konrad Rzeszutek Wilk X-BeenThere: xen-devel@lists.xensource.com X-Mailman-Version: 2.1.5 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xensource.com Errors-To: xen-devel-bounces@lists.xensource.com --_002_90F0F47595235141A4380FCF01B0185B20BC608BBCCHNHCLTEVS07H_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hello All, I am sending a doc that captures our understanding of HXen. We need inputs and suggestions from you all to correct any discrepancies an= d clarify our grey areas. Based on your inputs, we will define our path ahead. Regards, Deepak -----Original Message----- From: Deepak Kr. Sharma - ERS, HCL Tech Sent: 30 August 2011 12:41 To: 'Stefano Stabellini' Cc: Konrad Rzeszutek Wilk; todd.deshane.xen@gmail.com; xen-devel@lists.xens= ource.com; Lars Kurth Subject: RE: [Xen-devel] FW: HXEN on linux Hello, I understand that there is no document available for HXen. Please correct me if I am wrong but I assume that HXen draws some stuff fro= m Xen. Is that correlation known and can it be explained? We have started identifying the blocks in HXen and will be sending out very= soon an assessment and understanding of what we want to do. I would reques= t you all to validate the same and give your precious inputs. The first challenge is to identify the big picture of HXen and our focus ar= ea. Regards, Deepak -----Original Message----- From: Stefano Stabellini [mailto:stefano.stabellini@eu.citrix.com] Sent: 26 August 2011 17:37 To: Deepak Kr. Sharma - ERS, HCL Tech Cc: Stefano Stabellini; Konrad Rzeszutek Wilk; todd.deshane.xen@gmail.com; = xen-devel@lists.xensource.com; Lars Kurth Subject: RE: [Xen-devel] FW: HXEN on linux On Fri, 26 Aug 2011, Deepak Kr. Sharma - ERS, HCL Tech wrote: > Hello, > > I have few concerns regarding this project that we want to carry out: > > 1. It would be great to get some documents/technical information that wil= l help us to get a better understanding of the work that has already been d= one and the work that has to be done, e.g. a detailed architecture of HXen = will be a great help. like Tim wrote, there isn't one. > 2. Is there any preference of development tools on linux? you mean, apart from make and gcc? > 3. In the current state, is there a way to configure virtualized hardware= ? For example, can we configure the network card or sound card that is bein= g virtualized to the guest OS? I think qemu is still used as hardware emulator in HXEN, so there should be some degrees of configuration. ::DISCLAIMER:: ---------------------------------------------------------------------------= -------------------------------------------- The contents of this e-mail and any attachment(s) are confidential and inte= nded for the named recipient(s) only. It shall not attach any liability on the originator or HCL or its affiliate= s. Any views or opinions presented in this email are solely those of the author and may not necessarily reflect t= he opinions of HCL or its affiliates. Any form of reproduction, dissemination, copying, disclosure, modification,= distribution and / or publication of this message without the prior written consent of the author of this e-mail= is strictly prohibited. If you have received this email in error please delete it and notify the sender immedia= tely. Before opening any mail and attachments please check them for viruses and defect. ---------------------------------------------------------------------------= -------------------------------------------- --_002_90F0F47595235141A4380FCF01B0185B20BC608BBCCHNHCLTEVS07H_ Content-Type: application/vnd.openxmlformats-officedocument.wordprocessingml.document; name="HXenPortingToLinux.docx" Content-Description: HXenPortingToLinux.docx Content-Disposition: attachment; filename="HXenPortingToLinux.docx"; size=25181; creation-date="Thu, 01 Sep 2011 11:02:54 GMT"; modification-date="Thu, 01 Sep 2011 17:57:05 GMT" Content-Transfer-Encoding: base64 UEsDBBQABgAIAAAAIQDhD46/jQEAACkGAAATAAgCW0NvbnRlbnRfVHlwZXNdLnhtbCCiBAIooAAC AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAC0 lEtPwkAUhfcm/odmtoYOuDDGUFj4WCqJmLgdprcwcV6Ze0H5994WaIyPEkU2TZrmfufcM6czHL85 m60goQm+EIO8LzLwOpTGzwvxNL3rXYoMSflS2eChEGtAMR6dngyn6wiY8bTHQiyI4pWUqBfgFOYh gucvVUhOEb+muYxKv6g5yPN+/0Lq4Ak89ahmiNHwgQ0kU0I2UYnulWMdqZdIwT07Kw2Bm6QQcZAz VGTXm+naQCFUjNZoRWxfrnz5SboXqspoKINeOhbMW2jNg0QG8KxmytHwBiq1tJTdvrG1TRoJLP5O brtlzpONJVyY2KXQvc/W2XfpvIZUynatbsz+WGpaTEEDIp+7s3lLdsr4XUI/+vBLN4PEkwefzxcj LXqvCaS1Bfx/BxtulzyH1dRTchcP1oe6fiWUPT6PTw39MX8EIk7/GMtvyV3rN1Uk/vFBNs/D/9IG s1ey4mtgqmYWDs78S+ta9F4TrzB7PFr6H+BdRtr+6ZD+EMbuzqqnv2mdbC760TsAAAD//wMAUEsD BBQABgAIAAAAIQAekRq38wAAAE4CAAALAAgCX3JlbHMvLnJlbHMgogQCKKAAAgAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAjJLbSgNBDIbvBd9h yH032woi0tneSKF3IusDhJnsAXcOzKTavr2jILpQ217m9OfLT9abg5vUO6c8Bq9hWdWg2JtgR99r eG23iwdQWchbmoJnDUfOsGlub9YvPJGUoTyMMaui4rOGQSQ+ImYzsKNchci+VLqQHEkJU4+RzBv1 jKu6vsf0VwOamabaWQ1pZ+9AtcdYNl/WDl03Gn4KZu/Yy4kVyAdhb9kuYipsScZyjWop9SwabDDP JZ2RYqwKNuBpotX1RP9fi46FLAmhCYnP83x1nANaXg902aJ5x687HyFZLBZ9e/tDg7MvaD4BAAD/ /wMAUEsDBBQABgAIAAAAIQDX5gieIAEAAEQEAAAcAAgBd29yZC9fcmVscy9kb2N1bWVudC54bWwu cmVscyCiBAEooAABAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAKyTT0vEMBDF74LfIczdpl11 Fdl0LyLsVSt4TdvpH2ySkkzVfnvDyna7uHQvuQTmhcz7ZV6y2f6ojn2hda3RApIoBoa6MGWrawHv 2cvNIzBHUpeyMxoFjOhgm15fbV6xk+QPuabtHfNdtBPQEPVPnLuiQSVdZHrUfqcyVknypa15L4tP WSNfxfGa23kPSE96sl0pwO7KW2DZ2Hvny71NVbUFPptiUKjpjAV3NHb+AiyTtkYS8FdHnhH4efuH kPbkx4JH933J92uyxLAKyaAHlaP18R45JmkJIgkJUQyOjPrwY5+iiCI+qbwlVIsjWYekqYymTObd LJpJWhrJfUiIb8zfkMgHM3ufM3EJ5C4kiPtHcVAOCPzk76e/AAAA//8DAFBLAwQUAAYACAAAACEA kNcpD5omAACzRgEAEQAAAHdvcmQvZG9jdW1lbnQueG1s7F3JcttImr5PxLwDgn0Ye0KWCS5a2C32 yJY9dlR5adu13BwgCYkogwALACXRp36Qmes8WD/JfH8uYCYJEAkSlCgZjipbAkEg89/3/Nvfbye+ de1GsRcGZw37sNmw3GAYjrzg6qzxy5fXz04aVpw4wcjxw8A9a8zduPH3/r//299ueqNwOJu4QWLh EUHcu8an4ySZ9p4/j4djd+LEh+HUDfDhZRhNnAS/RlfPJ070bTZ9NgwnUyfxBp7vJfPnrWbzqCEe E541ZlHQE494NvGGURiHlwl9pRdeXnpDV/wjvxGZvJd/80Ismb3xeeT6WEMYxGNvGsunTTZ9GrY4 lg+5XreJ64kv77uZmrxtFDk3wMfE58u+CaPRNAqHbhzj6gX/MH2i3Vz3bgFAekT6DZMl6O+UK5k4 XpA+hqhjCf8p8g6BvOf83c/pUYuNABZ90NIgHM3p36l10wMtjj6dNZrNbvP4xclpQ166cC+dmZ+s fvJRucQe8jFi/3xO5r6Lb187/lnjjesQUduN5/2/PceL+D3sxqT/NkiicDQbEjXQpwm7Bx/SnXey rlbWuoglevHUGQK008iN3ejabfR/GzuJ5cWWtlCsMwrDy1dRhA0n8ym+EU9d3/+cOFFCzwZc6a+k /+Z3V99j3ldfBSPti3/XXmgCmY9gzWbzvNOxT15Xi8a2WJnA4uswSGJs3ImHnvcFwgfbn3hBGL05 D2KPXu06cXIee07mh2O6K/OTYZwoT3vhjTz+4oEkq6b4/SW9nhGauDIM/ZBwwa45sySkGwG0iJZM wBNLxy2M4DVYMXQ90L2BxrLp9k0YJ+6oPNk+Rgj1yzPhYwRDNqFYT978/ur9UyuaBbEF/qtJhgnu mmQIDDkkMwwj1xpD70XXXgzB68SWY33B789a1q/v3llhYCXh1AovcTlyr2a+E1kwTyMYgMGVFc8h miaWF+AfZ0R3EdnN4pnj84fY1sRNxuEIQv1qjg+hgWvC5AoqqWUZM6xyCFOhSdhsIzf2rgJoQfhE hxaJObLkhs7UGcBUBd1B5gVEkQq9BvNVSh3MmAk4nEURPDB/jgdfuz4Imj3Z+s0LRuENWCAYWe+c ofXh8++H1heQNIzEP9xhYo3BHwPXDSwnGo69a3d0WNq4q8QczzR7uYV744IfExc7SEJrFNbWZ219 clt7rWWdqyF+U8lpGkZJbVVs6g7+QJYoRM/PXjC7JXl8M/aG45pqaqoRTnyuqCGVHoSJtdDO8WxK IgdqVqefOoiihkwGdRBFBohyaQtqzPHj0Jr6Dnk01sT5VvvHGwc2fyBNNiEHeRgGl97VLGLeBjkH M8SUrcvIg5ntz3UfAFJOgoeiuBft9tGLCwql/iDhSutLaDlwjuBYwdf34gMLHolkO/JMrhA82IL3 HjlQN8kzSOJ65KDJiRTceMkW5uUjh1nf9wbXXpRoYYrizNUPTlHMY7nxfJ8CP9feyLWQB/Mg8inS 6fg8/c2iROL6r+8WOoKlxk0M1iXVoASG9E9YnlZcIpUtUmBTgzztrpObOSx5Hjj+PPZijeqyjfZ2 8/gUtRJCPSow6GqfLMOAJWVZTvCmF4QfKYfLkrUw767wMJm2PGu4wbO379UcIuDnDZGovu5FFNHz RmeNr7dN/Pka280WK9tA+huJ4zD2CJU9ZxCH/ixx/4oajCsveOa7l0mv3eoedqeJvIYYea91fHiC KzfeKBn3Okfs47HrXY1x9zH77fszxBfd216rax8d4V0nDVpG4t4mg/CWGWO3g9uXyMkiNskQLcFC QkqHx6dVSLFvGCazf30XaLgpkAiboY4nbhN1T8+V7eJnwgDP6jKUkBVPu9gVclEsE1NtQxFybft4 HWoJ7/mI7Z60Os3KEctAkvR/fWdreOOIwd+lobwZSgVB8soRzqC7RNixIcJadvPweJkdD9t0xZAd u6eto87usNbaR6wJPZJAwBES8S/QywILJOJIJkMGnjW6J82uEKD8ViIdUWTBkM9/rlAKt21DvNun 9mFrCe/2UffwNEW83Woq3Eo/a0K4Be+scqzfk9L95kaB61sTFGT5bkX0Vo0sjsfO1KXiKlXbJu1W A0YTqtpi7ztEcss+ajYP2N8NK0T5FirW6JawhwJKKGkQJEofxyhQOvCVe92GdQlDje64ZJikm5Ce i8Kb8Bv7Fn1MP17Ss+DJB1A6vNIrwJOJssOeHw6/Wdc9aGJYDCMP70rXTM8gTXbdSy+R1ma/qPuB 9QBasviT/yJMCrZJI53z7GhFgtkwGzopJXdOW/wOoXpanPI1cj7qcIiJXSJ0yivaksghO0RwMbd/ wMVMqfC/tuPhFDIqQJJ2pxjBuEVBsDP6A8W0zZMmymlTZP9X86CJ/xWc859XMB+jGBFRvT9CstKZ mp94iRvRrq97VEyL6gVIOvxsuX+iaheizvoLKzsDctXPNyCh694YcSHfZc8fW9J4PGv8pXkwhDnH l4H3pLdVRnTdVaIDVI2IrnW6ZOjYKsV1jzWC69r81yhMWPlv77SpC9NupwnzOeUxSX2uPwhvGpbA 7fGpffDMPj6xWy382z3pnHK1K5AH9yrCf+Des8aAuJLqqkfaBYUZd2Q7ZvI2YLrM28ZgtttgY+E+ kKvQtg+PFsZJt8lZWTC23V2F86XvTXu3Org77RPGPUvMroL7pNtuHXRPuq3uMYDdOj1ttZiM3Htg tzcHtt1uH9o6uO3TQ0IANwWXqLpDPptK0lmghpUAiWRA2fZpq9k+OXh2fNLtdPcO1CFJPN3hbWNf RqLCPj5dMbWOOioZ2x0Cu3SMTjLUk922Of1V6fIy/ZVX3mbxP29DdzI7dG+zzCIYs6XcbBI/6/0t AnOeZIILh2gc1cehvmjsBW7VMRIRJiDDfFv7vlIX8VEtRphOSf98OvW9IVOHmsUtb3AGIBdQS/+Q /9FuMoEvL2/Pj/0cv7JfEQ/jhWj/2IVfnqkMoeeXlSFMdSNB0uq2lqTzob3QhZrFcURSWzNwjztd 2Ngrghj6jBu4zDLnZuCWloQJclZjcBl4YASgiRg9uqtG8vRPVGyuPqXdaZ92TSOnilTg8rL/IS3i /cyKeIspc+mFnDKXLioQ0T9hexGXyuylzFPyueT1aefVxSuNS8QlRU5mxtNb0mdSAh5J//MQJaPW h0sLTVnfiiGnM+knDrmliwrk9E8Y5Gy7e/HChkGRSvXM1bL2HqJcbbUfYYlTbawsyipesA4vlUL1 T9jaFEiu08XnsQWSs8JZBDkxG80PWCU4WiaRHaYFUuUu1YcHrjtC+0KIOlvrJvISBMORdrEQJ8C3 cZlu1quBsF/DsPemPVw5aQ6sRoOl+UJ8Ko4z+u5SN1nOSlbb2iLVqBEUxVRR9hOoKj92EyqlXlrW OpwitOLG1gxJjcgaeRTND6O59a9//g/6LqmQ+l///F/rSexMXIrR4M6xg6IAVj/tTaY+2s3gGPPK 66WXmiJ04gyNvmkGxeWNGD1a6RRcWTVKHSbK50L0YtEfPhs922zZT4ueRcswetRS1hJGhUpFp612 88UrJoTy7G2qlWcszUH54bOFbsqhh+5jhT6ont+jrOqIKtVDkgMxqG82eMZjl3FP21CmJhZrkctT pKf+CZNQysKFZNSl589enHx0Igdwmo5J4COnOJtwGer51z7ewsLiokURn70dyWtSQYgvLITvCjFk 9pUiIpV8comB3NFH58p9EbnON7YCdJzebtZxms3hlogPjyL0LUQ9Jn1V/h3jbYdo6FERJZlU/66o 6AUanSF1UwOPg/my2CjevsQdV4cKjkRa1wMYAE7xW9L34MS5M4008gSuIbETtXJwUOmpKpKgcIxe tMrcDIwVCqUVllwB7LKQyYUr+rU/vPzys+5xSk8lh2gQFmWUkoKpCCzGsqZCeH/1wmHiH1YKddAG Cv8c/B9CPqHYjykwXsueUop17UReOIuty1nAmuAdzGXwoOjiGUre0Ss0cVE/mPYhYWTCQWm6KsQ3 0+r94bQka2Q+14hxZFsV207iTQg6Yv/YXzKGCIMFR2WS/Ge0CQZDKwpnsELdmDdUjdzE8fxYtgym 3ydTj+sDDnBCwBUEFrMBnSkGY4y820ONCB+1fkj6LwHOxPUmV9qmt5J8FjBBA0RICZDgo55PmomB VjqCOtfgzBhPKZ03FIvvkRk+ZMvCF0de/A28DN1FyHTQdcfxRVm9JeH1yDFF+hpyaBd4QhMisCTB v6SsZsz+Nnpttr6qdtGpI2CCfeHYSp2l2HH6J0Ze8IodJ62xTMLTX6A6ufon2716vX5FWwL5u6lf C9FXWkEIr4IMDyMaMJPxQuHvjYt7aCmwSsUS6YpU+Ujlm37KHAxNnSDIYASjVT6p2mMHYGWVPDU3 w/xHf32MOT2xgXbTCXRXpLt7rhHDhTLDVtkGKSYOsQYCChetxipWbJpMn6tyz2qzCnRut21Qn22C F+5UbUknCOJAMFMxGKrAjo+yQqHZWGLaKkY4iNDE6qgRzJtNRzBkMCUiGCKyx23rESpwcAMqdlgM EEHKDdnz4Uf2+nfN94L5ZABDjxkjPRBYf87cmFWzP7+K3Dk5Q47uPJpQoqLSj153Oq8vtDC8oFDi hczQjCoh0lhA9IDnVtFORUjjwW0DicxsfiepHDmM3Z9Ti1d06Qwp4zBwkxualrERUz9gKLFYVUl/ nJlxD3jP2ZTBwgA/HPrJEzTatLDFM+WoLi0/cY2+dHG9cBU3/zjCVbqRGqwepcT9FPK5R0ZUpnoz jxFEffJ9SwYxMlku316+aB21XqPcEspb1tmIS0XclT05FYVDLJSp4S9zTfqbVV9P/4SFKVbXpNrw VB3OkyqasZctuTUbHjWmiNdirKAjOvsynC8tV9h83TlqHq/LFV66NzL6qwFBBkz6MUoF4CmwOPDy HZKKqTFOfVWfR5d9JPRSv8O9nSIWDceDItIIdI5d5LmlU0KjeGln+JhSHTBYYL0gCH2J6D/8FAOb /Lhpv3yxqMMR2ayjZqd7LslFRZp+O0OauKQQkjADBiwRGH/Hbln+EX1l4spi4ge/Bsph3yEK4nnL YldYwlBbsSIsy7+dCt1I9X1FMqJ0NmY3yzFIJesYEXp26aKiZ/VPchBYXX7Zlr1XGySYdZAqZKbQ l6ScFHeXXhQnhMElnssmqEUwsezLnjzVcSP4Pntp2SJq2a9IJRAnaWXDOX7LyB1ioCXydQ7L5Mlh glTauPzs7O3na1b15f1vDgawB8i4VAXTnP1YTwZegtk2yMhQLgYOGeptsHLK0odRrBeKZGobnbrN BVdp0H9GqRAAT/FbMe/JSteOHCC2geRhOLsqP9phBVPrE+Qaon5y/zFzo/k5g9zHFHCVoa3/pOhR ev48l6mS/lM5fXWIgQTaU00Qq3GIfIuxlCuN7fcY60XovfFQ6cMOMUBel8X9iAAwctybzCaUBZk4 t+zHlGiZ1o7cBIcbsBpG3D7GQOzS7LkNVVQoDJMKKSAID8tz9HaIl8bFZ/WIgJW0W4nyqWX1JuwY nGygVP9sbtUozJ2tWFJ75evUK+WyY6GSbTSQLhlQqnot5P2VbEXZNxBnVEisOSBbUtx7KG4umF4n ebGPin0PAUbaWIrXVA3DhJg6rLxPUy95pSeKLXSnwjbzZQZ2aZ4NRSPQoyt+RA8sEWcQwogSluIo tRM1kOwjRuHJcoxSeY8wP7lpKGv6pN0lqrRmVAJ0p3r1J/ezm/D2k3Oxwi+sekwDbh69maC4/0TX kBnPUgyu3aPxcevPr4KiqkJfjv5Z9hx3j7Z8VZ/0M3UN8yBx8pdetHevC812oaXghy2Z5TJi0OXd C4X/dpOXfED/R+mBvZ9NBm5UFV3BCK9aLBi7TjLyyqN0i9geJo+txPb4NVANYwSiHtHXlWsX5ui0 c0Q+SZUTLuGFqRpukwKv/NezSDwFj74W4aqEU16hZV4S83pMqgyyclPluoLdvUR4bBqnqGGGER8o 5iuLYxZRIfO4DAyJB6GJzq+QyIDHQ3qHtWc/GGP1JUJYOmNkGGrm3nHSp36Cytz5HKFa6YIpg8lJ tkrJWWEsoMrA1VMW1IuFz+nhCEIe4AO9+jM6bwRKSuPc3YvJNRZetuFEKpUir5uYR2tetlCgVWq9 7C1Q1x73bqW/e8dAf2y6aZH9/DoLKsRfnva5Dr3RPgXj+m8TKmJfZHZG/OhZo/hDTXtLx87mWtk5 5MBUCHr4mQXEc3/V6ZKcd1KqUUNcnt7ewsYqer4SwNkgKP+vf/6f7gvuoa5ZhBio3/ThZ6mpEEdq fzUBrIcp98wMwGHX6O1Fj9F3UvksbUl59immTVLJkIiUq661yG8i/ipD6hop7yGhaWlabbF5fK0E /ddZNQFQbvQ8AzmRZ47LYnMRykJagJc9WFdIPl9G4WR39lqlvmbe/gqFeRkHqUrPIMe6JC5POVpy AGZHoB8A5YQYskvNQWAOOvLL/ZNG4iEW9d2NQjgAgtPQJGRd+eEAn6WSz4iMDMmSqUyKVl1PjB67 BXUuhIHRm0w3UG3CN4/0ipZcIpjHXLzSmfCNc3x9SIPwsmj9pmGgPPiksuauTYnH50ExlgyDry66 YwslnjHd5ZivFUrBnDcUUnptvfaJO1n30wqXl9Fod1Zj+SCt12wd/UKW5BkJSEOddJe23mq5INUQ inJCQlSWuRFwK0MmxMiU3/+SwhXeMBQceSpLdVR2lQMsGQLbQ4foC4Y3ERlVyR8YQz3Vw9t5ztUW 5ibV+MihSqmPWrQLY3WKBEthdmVL+qTYuqv7jHtIH5S4qjoD8EZ00FRn/ST9SsPRVaaCWAjbwthX yuseagS6e3Q/UuuZHFqI3uroJ8e2vX4U5rPehbR7ohPjmr68uChN7RsWGZVv5CMo7EEb4eZjHRWK vekt6naKGyipDW5Tijh50T3upONNCnqnxM1K0+dmPYOsvZg1XBjMpF0K0SpryDETMaoY8TjYhzQb mgxljWbz7JZ8R0F9I0t1Gz0vzw5Sn5bt4NBpaDiGms0YFnMJWQBKe605z4sXyszcen5UVieZaaO2 maow3E+RORy7OO6MgQbxVwDEw1SmiAKxPyJcsikH/ZojmegJwox29xWHrCBYoZBD0t+gUefhU6mo Y1UF8hZVrxo8cQDIbIgeQcbrNKwgCpFOgLyKkFlARQLa+2OcWuYW03c+i+ufsMZvZQ27ZvGtgJdJ O/p+CtSV0ki31U7ZAIr16mqrnW6lkoTVsLAXismT7IVvcNgwUj1GPkujr7y1GKizzVaSLcksOtvQ whyNhUCzxHKrFWubLbpfLveWScpLXeu8IfOR0ne+DbcZ/HOIxoiSjQy9zZbV/wlc5YfOCGezOqSJ jRZ016xVrUm8IaQAqL0EjjwzQJzxIYbha0vdc27OOvAjdx5LPmPmOFeolqQoJx+CkQZrNfjkqRAj xoOZSaFE4p8tp/Eods4ducdV2RtVYXBR/cWmxSzsTVn/RToWyAzpMEDUh/GDHzRc/iC0TifLpaM6 hAjgXYQ4My14cnioV/+TBGWHDmAK9jDypige/gGhtqarKVs//8J6+djxDQvA0VRlOjJNQBQNf+HQ YzOXF9VHyt0iLDKYXWLamTyoCZ6SBv8tJRBhXo8q5D3QQHXnyNHSC15x3dcnvjTpd0l+pBGETDa0 3TQYbWFbFDLfi6VcSjKvYKxMsGV27YxGulTZARGeWU9moPWTr4n1n3oZWN7LDJX4hKmVOyS5MrD9 5o8O8f9XOu2luiU+/av2rB1pToV9toppbEfJJWTPUldcBl2tS7or280TpMKAEXPZxOSTeeBMcH6f OMqKqiFSnY0SfcTWplab6njp2CdWLCFP7WT6BR8o3yQyoXtBYnQq4MYJ/lISS9n4Vng2iF0RpWb2 6CtrSPo//f7q/S/vf/5wfnEnqaYNbGl1amy7fSx9nuK9ZVsrVCYRl1bTaxwq7tloQiKHGwyFbDye JTixtDJHessaCY1cnooDF0eha3I05v4Ew7IEIxtzATZZGWe6BtvZRKUGNGEfiGYPMYLGn0NKMYkU zQLmjiwf/bMjpbIBswlQ3PSKzhqVJ7BsDzvMXeJhBxdH6+HU38EfOKyFTUCuNqKVlD+XsDQdyPTu NHKv2WGMZKHTMcNwyaFsMHQStY5FoqKMzRN7V5iCvaS7MsQPe6bwAh4+tSFtN+Wnetz0nEu0vJ01 2sdsIjoq4NyzRgvFFUiM0y+fZj4uOLMkpJk2C524lRU/okwecnlGmDTxvbKlCjqO+JGWgicEGRFb 8Ous3Q858wPL48cdEnnRH5RIHFgYNo6zvPRF1rin032Wj2gvYfcC+EVY39LwXRqFBwt1OkssNKLB hnUgQCBFuFSZBTg6kxnA/JRLnH45dRIUVERSiJJ1S8Uy9MWiVe9a6iCVKmtVtJwYVR3l+QB8n4hm Pgmn1KIH023+FGe8y30zYBAr4PDW2cYlm6UM+CKd+j6M4CT/5g74CK1N9WmaeL77g5mUlLPwMuLv ixn/LXHNdxBZFmcBuMGzt++FeGV5ozVi1pjVRALqQe6fMvGY0hnhkPAg0QVwjvQxUBIPHCA5Ko6U GRdfXMn9Bznv4sQL9OaC15kfP8U5XuAsNp0HMKV2XVY5ZnJCZaYT0mwdtS9OyUqgQ1QKKk4UF8jU a9/QQIHhTZ1C4qBD6e7mSIOzxmf3KnStX97SPsbnQezpl4ax8jsb6TcMfYhTwbc4rwR/uKBSuL4j ryhcz66BrZfYe41I75+zYbXCG+JBmSkdH81PNyG8S03HDf8n1Hwdo25Kj1juyGLZAKWZslyIQ3y2 Xc0rC8S8ff/2y76GYTJ3n+VVnwpNkH5hQ1ZYKJF1VAb7hiU5YRowU0j062PwHAZug5VG7mBGKdA4 xqnguijeEWUVWQjbjKi/W9jyQdOUQsbocsx3Spu3CLAiPkufwiKFUIEUp18W0lvk9BwZdJ2GKITE IO/FmeyaTVqjg47jlArJ1EbW5lOkgykA5SoOjlGEJEoL5QANDWsZ9owaa9hgR1U0OWoLj3HIFihz 18uW2mz5qBs26Fx7eU3p6ym9TxNalONZhIxRz2ghnxYN14sDhfYUwBvqviUz8IhbaQuNuE0EA8Jb A1YGB28ZwaD6owAWuj5Ah7BY9OIyQYjRdGj0OAPXKi/+QHpOGhggSQTXEoynRERFWLXYJ+2VbNnY meiBoQfI5DYz57Dw6ky3rQh1+OdsJYBZPbXiGEZ0qMJgRB9SzLuzWMN3hIpI5JTnwRCHfwWULHaG lNgh0ROPcVQbjEsncRCYg3k0mfmJl1LFs9i5RPmTM6exppHjsQKpt5/+8fOhRrGPgkQSZxCzGJ4z kH6l714mDfwyDeF/ntosVYSQSM4N9gk/CjT/jtZxR0ykz3tG++hIeK15d3S6J8JZybuj2zktWOlR xxbuXt4zjtuyTSPvjpNWp2ClAFjBSu1m87hgqXbz9LRgrbZ92iwAq93Ccnk0IG8/NhIvRcvtHHVl uhCPYdSyohfThM2a7M1N74+hpLFBmIyFo7lpJcDCdKazZC0t/UgjSRTeRyEt9NkTixgZhx1T3NmN nopGRRSPUKUtbmA2N3+OUB0xOUcPNv7O9DiCMizJuJxlfBTSa4UOt84jGge4kY9GUUCyFJTYiX6b ozIKRxryIoRkjBEXGPwynOHdpL2+uVHg+rwHl8iWD0AnBhjjV5C7tHH4Ax6hDrtXKoDVcO2hFFoz DXZABtx4YR3WXFqRwILlKpLLHNcH5H3zdDK/n2ygAUL0kYPRsvhEEgeL34YR8stTGqAJ2152H4iw TxrOH4SjeXmaWd/PvssYW2VW8EOM2mdnaT7LEh1edqAKCTWOX0TBZby7kvNcdqSMlDiSaeIn9Z3U CqqqsgTZ6KEazs9vfvly8eG39z3dx94RXHbJf3VVXpx8dCIHInfKTFzFH1dpSljdoLdF5kma2YII CfuFJcDZNJWyvGYWS0vgHjl9k4iyUEnTuiqPqp82mvxiQG11VV5dlUc1QVVVZBp7Ums6FvuwT4qE Fb1niyCxzPsI96qu10PUoK7X6znx0PO+jFECdtbAFOAwekP1ORQWdTFe8jz2nMwPWRVP5ifDGLSc Pu2FN/JknY6MicnavLpeT6lcEqb32nrFul5vqYATAMk2C1nE4G7r9dZHAlrnbbtrN8rMLtww2rOU kxWdaA/Rya+qNG+tKe4MWMFhHh2xNgVLd1Zzgl6GbXMQmtGudT2yfig7COYWsg8os8fYQrSX4Ewl FOjjAorN0AimHSbDgq3eZBpGCQJolDAYhpOpTwkDd7T7qNjGpJ5ZbKwUk0Ll3Ee96Uo6uSCk1Hrd bb0+Z9Khqh1xsjaoo22LFJ2qjfk1uOViNeKURnQlbzkVZ/83umldqxDwIDiDQu1dxqVsNvwUuEsj fDKZmZcbrVPfWiVAnfreVeq7tFhcGE2o62Tpvy0ntCtmWILhvjR8qsjtXlsmqj1vq4OLtCdh4lNP Vi5Db7OKZDESgkpmqY5LToPgyXw11eEsp7hECTQKgQZUPVRenfMi3y0lXC2FlGqjugCnhwzvWUMT vHZ1BThqd9JxSwSF86tyzNNPWzJBdUHtWs1zvy2nWq9msN0yWD4vZXjHRd7PbtX8ZeQW+tv3oOSz A1c063EpN74lQEeu1P+FpTvGUMheOyqxmIFBzVOqySLfj4ZRLxkvmy/O1T0ZJAWyWCala91A5dF1 9bNuq9TVz3mza9ZXP1fhApJAr9IPHLvOdF+9QG1d5qIILQDtY5uyeLuJRskopVajESfi3B19GMZZ 4zzyHJ8WI2Kx6e/U+M9/Wdf1j22z9+1YIise+FZFdG2e79QKnmprvbbWdV/3TvtRVHfYbsmmnHU2 fCRFhxb7WTMEiY85oQFfIlCFApOF4YfyfYpavbv4WTSj6Bk1c8FWyv/egKNVSLGwQS101C652gys zcCzhlkTnMpKOxI6NM+UCZYppqaIMUz84ASSNprttKUXPRn5Ro/LK9BTRFFeqYGciqG9Z38kYx2/ r+P33LLNyyPvKH5fGL2He5BvrbD6HnARO0P4fu7bHx5OSwLUBo3aX1nKQ9X98xm5ucfmr1AQKTUd RtJpkcYDVccvTApMx6BRG9Q9WqlRIUoaKk1QZIfmnzzVF74/Ikm1EmuHazUnXk8d0eImddw9P+6u stKOHK7I9dEWgpIkjBJypphHdMUmd8+mbBoenK5AlzNbel1p7hIv0tyivOdu4X6RvJd6QHuXiaws W/xfO1O1M3UvztQ6uSDSLPjnXtI6GTy9vrVSjan0UQGpcW3O07YQEFWHlEau7zvi8NOipW9bmcFO vRSBeSrN0N63vYBbrWevBVwt4O5MwK0msu5dlPFwkxhqcafilM0nRLYVXI1FmPC2luKTkbSyFk1B NZXSjqLGnkRsr86VA+xsDGUde7rv2NOqMCEe4pxcRfUS7zr5EeqX6HjlO2mnUwxBiShN5JoeZZAZ CWeN+SCBNHa+cbOq5p83+ZzXBW2tyU1kx/RkdUXMBlg/w4nwGH15UKn/jenYzC3WzMUMy9rYPO0f WNPxPEZfMQY5upMwmrM4KxtWjAl+qA/RXrU/2mtHSF8RKCU8HgAdBwLPNYBl4Gbd2BiFcfKy0uT1 4HyziJ9egnS7i/9THNIp4Zg1ra1hf5CWsmyhycE4/y6YfE0FFQJqPCEhGYRYj44cxRxUaujH7M1h 5A2ojW9Og4DBLGwMJiuzuqEbUQIBoYCGfxr9zalDXEV1VnnBwNbaH7hjB4eElj0Mfs1GqT+AFksR xM1Dbvtmtd4ZCUkLXQPAGnBLPcFgrkY5iY5kXkvj4AwpwiR8/oQLVZDITt3K22s3PXBLLE7C7R49 m72lERqVw+gjFfXUw8Mi4qmsF/q6SkrBIUyRGwyra8/KtpT4ZHMx+Fdbv4muWk8vq6GvQk+4Elui dSIPCtiwFl+O9zprfGEnk753b6xPIabGNMAomxXqY7Lid3yZeXByIL86VoRfA8wfUjm/WYhiQ5wS /VXgWk6gSqv0KJnloTFKnkowiaf3qxuM8OBcykzqYWdVqNZmHS2vo+V3Fi3PCkOUbNor4aVK61P3 ETPEyZZ+qtpwLPwLIwFmaNOKSIjRI01kYp6hMp/i/CbtcIul8wokPO9ymIti3UtttVF8zUwYbqhK 9bmH9vbxtdomhqFGh06j4aMpzFzpQ2m+p7y43lDegIgqoYROR06bZ7RrYvHfze7Mo1O1vcDCG/Wo F6hNNozhnoqx/18AAAAA///sVl9v0zAQ/ypWnjYJaUla2q6ilbp2Q0gbilrekZtcEkMSR7bT0j3x afhgfBLOl3i0YrAOBtIk8tL6fHe+P7/7M/ECf+R7Z9NX2/GHmG3HG15MvLU0uaWdbcd1pOxdraRM L5VCDrOrYeLpGopiZbgyrbC9UVoky0hNPN8PZ73gZeBZUTMteS2qzGozpPMXGi+r5EF97FNZjHXN YzSjVqBBbcCbMpMDq/OdFjEvWM0z0EjihnEFLAEdK7GGhK13jFfsZnH9An8Thm7EIt2RcMxjVHGU mUc6voacb4RUR+nsXLcxp4i7gNpwDv1gfjHyHOkgxo64gJQ3hfmRPdojkeY2pTaCmBYU56kBzFpv 2LcvFKLCwIZ93x2WTYEE3hjZpkZg3JANUnxrGBJ4HFD+kvF7aHJ4XJldAWgG4fVaaBNxxTPFawLu dlw1ZeumKDaF4+uAjndvrAskGwQd0u8kfjswqn1RHdimDT2A1XElK6PxWa5jISbeTAle2BgD12am BZ9470SJqH0LW7aUJa/sZT6r9D5zrJ0k1WwsC6mcKz59bZL0raOGfUeZ29fJ6ZaG2SKTXfb+tMyb Civ9PZXeYxCPVqBdP2ke9xf7ydfPX07HjLElbEBpYDJ90sItn96R6cnpQVCOKZV/VtLPHbnHBLNt msE8CHszW1kEuP8Rpjaibx/uDTS1nytQcF5hl11ClYCCJMLt4EIB/0jOm/t7DHaXw+/R5dsibhEO wiuarEcgrmPeG9P707bfC7thRWPQoV5DbKK7Hro37R3K7zNkhUKWtR8Eg/MBbWp1trJTY4tLYXDu D2yR5Ph/MOqN2hFSZzfcvmNkjfR+uyIokeWoyR1xdzSy/H5u9wR3mwPHDODe4NM2k0pJq0d3zBpD x25O43CzE6tb9SwP5SuR8WslaAfBVSUSJkYrewO3iLTRoEVzLZMd/UGRpoTKTL8BAAD//wMAUEsD BBQABgAIAAAAIQCWta3ilgYAAFAbAAAVAAAAd29yZC90aGVtZS90aGVtZTEueG1s7FlPb9s2FL8P 2HcgdG9jJ3YaB3WK2LGbLU0bxG6HHmmJlthQokDSSX0b2uOAAcO6YYcV2G2HYVuBFtil+zTZOmwd 0K+wR1KSxVhekjbYiq0+JBL54/v/Hh+pq9fuxwwdEiEpT9pe/XLNQyTxeUCTsO3dHvYvrXlIKpwE mPGEtL0pkd61jfffu4rXVURigmB9Itdx24uUSteXlqQPw1he5ilJYG7MRYwVvIpwKRD4COjGbGm5 VltdijFNPJTgGMjeGo+pT9BQk/Q2cuI9Bq+JknrAZ2KgSRNnhcEGB3WNkFPZZQIdYtb2gE/Aj4bk vvIQw1LBRNurmZ+3tHF1Ca9ni5hasLa0rm9+2bpsQXCwbHiKcFQwrfcbrStbBX0DYGoe1+v1ur16 Qc8AsO+DplaWMs1Gf63eyWmWQPZxnna31qw1XHyJ/sqczK1Op9NsZbJYogZkHxtz+LXaamNz2cEb kMU35/CNzma3u+rgDcjiV+fw/Sut1YaLN6CI0eRgDq0d2u9n1AvImLPtSvgawNdqGXyGgmgookuz GPNELYq1GN/jog8ADWRY0QSpaUrG2Ico7uJ4JCjWDPA6waUZO+TLuSHNC0lf0FS1vQ9TDBkxo/fq +fevnj9Fxw+eHT/46fjhw+MHP1pCzqptnITlVS+//ezPxx+jP55+8/LRF9V4Wcb/+sMnv/z8eTUQ 0mcmzosvn/z27MmLrz79/btHFfBNgUdl+JDGRKKb5Ajt8xgUM1ZxJScjcb4VwwjT8orNJJQ4wZpL Bf2eihz0zSlmmXccOTrEteAdAeWjCnh9cs8ReBCJiaIVnHei2AHucs46XFRaYUfzKpl5OEnCauZi UsbtY3xYxbuLE8e/vUkKdTMPS0fxbkQcMfcYThQOSUIU0nP8gJAK7e5S6th1l/qCSz5W6C5FHUwr TTKkIyeaZou2aQx+mVbpDP52bLN7B3U4q9J6ixy6SMgKzCqEHxLmmPE6nigcV5Ec4piVDX4Dq6hK yMFU+GVcTyrwdEgYR72ASFm15pYAfUtO38FQsSrdvsumsYsUih5U0byBOS8jt/hBN8JxWoUd0CQq Yz+QBxCiGO1xVQXf5W6G6HfwA04WuvsOJY67T68Gt2noiDQLED0zEdqXUKqdChzT5O/KMaNQj20M XFw5hgL44uvHFZH1thbiTdiTqjJh+0T5XYQ7WXS7XAT07a+5W3iS7BEI8/mN513JfVdyvf98yV2U z2cttLPaCmVX9w22KTYtcrywQx5TxgZqysgNaZpkCftE0IdBvc6cDklxYkojeMzquoMLBTZrkODq I6qiQYRTaLDrniYSyox0KFHKJRzszHAlbY2HJl3ZY2FTHxhsPZBY7fLADq/o4fxcUJAxu01oDp85 oxVN4KzMVq5kREHt12FW10KdmVvdiGZKncOtUBl8OK8aDBbWhAYEQdsCVl6F87lmDQcTzEig7W73 3twtxgsX6SIZ4YBkPtJ6z/uobpyUx4q5CYDYqfCRPuSdYrUSt5Ym+wbczuKkMrvGAna5997ES3kE z7yk8/ZEOrKknJwsQUdtr9VcbnrIx2nbG8OZFh7jFLwudc+HWQgXQ74SNuxPTWaT5TNvtnLF3CSo wzWFtfucwk4dSIVUW1hGNjTMVBYCLNGcrPzLTTDrRSlgI/01pFhZg2D416QAO7quJeMx8VXZ2aUR bTv7mpVSPlFEDKLgCI3YROxjcL8OVdAnoBKuJkxF0C9wj6atbabc4pwlXfn2yuDsOGZphLNyq1M0 z2QLN3lcyGDeSuKBbpWyG+XOr4pJ+QtSpRzG/zNV9H4CNwUrgfaAD9e4AiOdr22PCxVxqEJpRP2+ gMbB1A6IFriLhWkIKrhMNv8FOdT/bc5ZGiat4cCn9mmIBIX9SEWCkD0oSyb6TiFWz/YuS5JlhExE lcSVqRV7RA4JG+oauKr3dg9FEOqmmmRlwOBOxp/7nmXQKNRNTjnfnBpS7L02B/7pzscmMyjl1mHT 0OT2L0Ss2FXterM833vLiuiJWZvVyLMCmJW2glaW9q8pwjm3Wlux5jRebubCgRfnNYbBoiFK4b4H 6T+w/1HhM/tlQm+oQ74PtRXBhwZNDMIGovqSbTyQLpB2cASNkx20waRJWdNmrZO2Wr5ZX3CnW/A9 YWwt2Vn8fU5jF82Zy87JxYs0dmZhx9Z2bKGpwbMnUxSGxvlBxjjGfNIqf3Xio3vg6C24358wJU0w wTclgaH1HJg8gOS3HM3Sjb8AAAD//wMAUEsDBBQABgAIAAAAIQCvHYinqQMAAEgJAAARAAAAd29y ZC9zZXR0aW5ncy54bWycVtuO2zYQfS/QfxDU13qtu20h2sA3NSl20yJO+xpQEmULyxtIylr36zuU xHiNqIFRv5icM+cMLzNDvXv/SolzxlI1nGWu/+C5DmYlrxp2zNy/vuSzpesojViFCGc4cy9Yue8f f/7pXZcqrDW4KQckmEp55raSpao8YYrUjDal5IrXelZymvK6bko8/rkjQ2buSWuRzucj6YELzECt 5pIirR64PM4H5o6XLcVMzwPPS+YSE6RhwerUCGXV6P9Vg1AnK3L+0SbOlFi/zvd+5Dlut+Oy+sa4 Z3mGICQvsVJwspQM26WoYVZGkXt0hvN8agqJ5OWNyCNc2z+cU6dLBZYlHCjcuee5cwNAYF4fNNIY YCUwIX0SlAQjCN+lR4koRXBpg6XnVLhGLdFfUHHQXIDTGcECF8EoWZ6QRKXG8iBQCWpbzrTkxPpV /BPXW06FhA0Pi4BkEUj32pCTlTILM4PPnGtL87zYW2yWq4Fh0Cvi5VHiLaYQ3493G38S2S5W6+0U EqxDP57khFG4ipdTnMj3k1UyiSTh3ltPIf+9nzj0FqvJOPEm3q8n1xbnSeLvpuIkeRTlk8jC87eb yTiLvb8Px/u8PevlJl5Ek2qrIPQ2+6kVrKPIX+ZTyC5IgjyaRMIw2UzGyVfRftfHmQ9pAvlCU1PQ f0o7yiHnHDok5hbRQjbIeTYlD0lG00K+bBpm8QJD68FvkUNbWHA2GwBFESE55LUFoNoHpGqU2OG6 FybPSB6vyv0B0lROWqGKfv+mZqoSy98kb8Wg2kkkPrIKzDagH0WjXsP0U0OtXbXFwbIYVP4bqGXV H2dpBOfXA+pSDc0amxN6Quxoqwiz2cdPxrVLSyIPpqHjZyQEFDC4FEc/c0lzPGnfdAUNswrJl35S HIMRC3oMZgbrJ6g0OwPvcWAchiF4jYOrLbS28GqLrC262mJri6+2xNoSYztdoNVBK3uBxmmHxl5z QniHqw/WmLnfmYZDUCckMNyr6XSQYDztDWPrU845xa/QR3HVaHgrRVNR9Jq5ATQpQx+9CbrwVt/4 Gsw4ixurUyGNoCsPXNkSfBvBsKTTVJn7d/oZUNijhh1AV+aM4VJz6QIqcZ25v3x99eD3VfleGI56 b5iL+5h9Sd7GhG+Ce2LG38f04fviHmrfP2+D+pBF91D7JjYHrjk6SPebC4A5vG2399mlFS4bKOrD hRbXx+nBrL5LSaP0AQt4x+BoIW36B+5Xgxml8RPo8V8AAAD//wMAUEsDBBQABgAIAAAAIQBTLah4 LwsAAE1kAAAPAAAAd29yZC9zdHlsZXMueG1s5F1dc9s2Fn3fmf0PHD3tPqTWlyUrU6VjO/HGM66b Rvb0maJgi2uK1JJUHPfX9+IChPgF8sKEWrk7eXAIkjgA7sEBcYEL/fjT903gfGNx4kfhvDf4od9z WOhFKz98nPfu767enfWcJHXDlRtEIZv3XljS++nDP//x4/P7JH0JWOJABmHyPp731mm6fX9yknhr tnGTH6ItC+HeQxRv3BQu48eT6OHB99jHyNttWJieDPv9yUnMAjcF8GTtb5OezO2ZkttzFK+2ceSx JIHSbgKR38b1w94HKN4q8j6yB3cXpAm/jL/E8lJe4Z+rKEwT5/m9m3i+fwcFhypu/DCKP5+Hid+D O8xN0vPEd2tvrvlTtXe8JM3lduGv/N4JR0x+hzy/ucG8NxxmKZe8BIW0wA0fszQWvru+zZdk3oOk +wVPWkK+854bv1uc88xOsJrZ31x1t4XKwxUWZet60HCQjfuQMjAg2INnGvjc0MPpJLv4ugsgwd2l kQTBDAAsny1clloc7ApWXgiWwF32cBN5T2y1SOHGvIdYkHh//SX2o9hPX+a92YxjQuKCbfzP/mrF OCll2n249lfstzUL7xO22qf/eoUUkzl60S5MofiTKbIgSFafvntsyykGWYcut/AtfyHg2SY5HCzQ zt+XRiSUUDHxfxnkQNiwFmXNXN6NHCx/IxDWetcZaMhrlK8A5mtU1lH3LMbdszjtngWSt1tbTLuX AsSzq0UEN3KspBs1jTxBvnw7jGYNlOVvVFjU+kaFNK1vVDjS+kaFEq1vVBjQ+kbF4K1vVOzb+kbF nI1veC4KV5lFI2wNUse+89OA8fcbBWjQUerkUON8cWP3MXa3a4cPrOViN4nlYrdMaUVFOX29WC7S OAofW1sERmfedV+tyZ8227Wb+PBF09L0w45Nf+cuA+b8J/ZXrVCngnyVOuGHSe0Q9iVwPbaOghWL nTv2XVjU4P3byFmIr4zWwnU0643/uE6dxRqH3FawiabR9S0h8r/xE2yDxs400VSlLXOSDScaXuoz /5mt/N0maxrC18hE6LmBmUsQWMTmJhpzE1V7V2stuAEoVRDDhXkVMH9C+cXgYp4/tzGl/GIoemX+ hPKLgeuV+SM/mu1rrDQf3fjJIXWvqXHfvYyCKH7YBVkfaJWHqXEPVhC0Khh3YpU/SSSmxj24IJ/O uefBzI3CU2Nb7HXUAMXYHAIFOxu9LsZGKcnewKBGxgYqYQ0NsLpprQGQseh+Zd987ngyHQxQpdW3 Zmt3HmlaAIYg0jf0r7sobf+GHmo0j4pyHYK7JGEODW2k6XlUNMknMd4Z2LjbwGcA1G0ENADqNhQa AGn4of/mUWMiHaT74GiAZSzLahRD2pGVeWqszArIbAiwNG4Svr80vVfPheq4SUAxNlB13CSgGFun NJapcZOAZW3cJGBpRg29jfKaalIp43EzD6S+BAg1siPeBCA74k0AsiPeBKDu4t0OYk+8CVjG2qA0 NS/eBCB8xGSqr4Dy4k0AMtYGoXbSZ5SNe5hL8+TWgngTUIwNVBVvAoqxdXTiTcDCR0yYUMJSUkfA siPeBCA74k0AsiPeBCA74k0AsiPeBKDu4t0OYk+8CVjG2qA0NS/eBCBjeVBAefEmAOEjJtpQK97Y 6w8u3gQUYwNVxZuAYmydkqCqj1QClrGBSlhKvAlY+IgJGSQWktukUnbEm1AjO+JNALIj3gQgO+JN AOou3u0g9sSbgGWsDUpT8+JNADKWBwWUF28CkLE21Io3dsaDizcBxdhAVfEmoBhbpySoSucIWMYG KmEp8SZgIV86izcBCB95LZBJjeyIN6FGdsSbAGRHvAlA3cW7HcSeeBOwjLVBaWpevAlAxvKggPLi TQAy1oZa8cY+cnDxJqAYG6gq3gQUY+uUBFWJNwHL2EAlLCV1BCw74k0AQmJ2Fm8CED7yCiDsRSZm siPehBrZEW8CUHfxbgexJ94ELGNtUJqaF28CkLE8KKC8eBOAjLWB77OF/aLk7akDDQmo+wyyXQ1k wKHGSFRAWcGv7IHFEMnE2neHdATMamiAqKEHtYoXUfTk0DZ2jzQEIUP5y8CPcEv3C+7SyQUijKYN kQR3v1w6n0UATOU9pFRx5w1ED+XDhTA8iQcOQTnTly2E7GyzneU8NwgQ4nFdMgQI49CuISBIhvXw l3mcDzyIQVUyGddtJSr+H2LeVtkz/f54MJjMJjLACbNsKYSCldUcYLxRHngfAIR4SxfCln7hUUiV YoWwt7ouHUKxnrL0DOZy7cai4fdhHdkzMrZDX8vT/vTiTD4lw8CeGNveAj6WkV/cQPxXglfhbiNC xeA/16qtcBs/GEzdTVQg2ZJBuB9Ya3yGa2QyrqwvihvtUh5advMtyIqLN0QcGW9sCNHDP7VBee5/ G4Ly+M1PMlCPE6QQl1d4cx+Xx5P3cXlLYaJLUXGP7xjNSjmanF7NUCQwpA+lGsLhcI/kPpkvI0LN L65EZXNxfmdZSi7OD9Og5lhl+Psawg21hJORhXYINyQQrvh9hU1pnYN+sCeOjCQxpaUMcGyjZUZw 2UGOlJbjq7PBxUfO9jpaog1yJERlA579niNhpnZdSDjSknAkaG+HhKMjJKHsZQciIeZ+9NrYSsKO GjfW0mtsk15jAr32zg3sW3+25MnudCC2Ye7HyDYfG9uvG5cPzb1TLfdObXLv9Pi5J/vagbiHuR8H 9wrffcPx6EoECtYNsNm4uxDffVP87uuodhMt4+TwbWcwnRw/42QPOxDjMPfjYFyDvv35/BNHZtRN YeVU3w7/psfPP9nfDsS/7MP7CCYYDfwb9/m/8gQjBVfBftZ75/PDVsSkt6P4nWnFT06g7ZDv7PjJ JzvbgciHuR+H+BWGW1O68cls5qKBQxTkhDc3vc28S12mtzMtKaUTzQ4pZ8dPStkJD0TKzB/291JE WxT1wOXrenBGFxdjjfNbHsGiomLxAJayK1xzTouY0CrXftarpJetbeILWqJxX6b8bJKGMuPZJY1e ewcfEZ27xt0tO2FbCVWcL1Y0XQbC0Qz/uQ65WxuOmxPjHC41rL67AhDuX7Ig+NmNeTum0Vb/aMAe uAMfMhr0cX1WrFqorJZRmkYb/fsxHl+izQCaOF8YcckroW976KhLFsP5Yw3tfxvxdc2KxMGpLZiu oQUc0ibEVp2dJh4snCYBSfqyFfjs7RJomgVf7Skv6BSWPMpcljedgbMXz5Ia1/YJLGzdwoqWZeJG cbkov5BypA7iv3DdwtDAYolBZ+ChJQNLf22NjLxRA7c6wArjj5zSvGYFwNCcwlmvM+fIkjmlQ/T/ yJwgqC3fsoaGEm5vnaHGlgwlvYdaQ5VG77egs02z5rZlOetWFA5knRVPLVlReuTethULE86D+NcM e6BwxepsN7FkOyn9b9t2DX3uGCwpnJo6S04tWVK6hv62ljR1AlkXU+Ee1JnxzJIZpTPlbZuxIKam hit8mnbw3hnqrXC06cw7s2ReOUF+2+Zt0Nu/ytiFTaBq/yX3VSi3V8WZgTu397dx9l9yE+Q3iFZt BqfH4Uv6DW2z4ah/8Uk8JR2YPvqVuFdo3ptm3mkPzkSG1ZOdG8hDcYWTBF/RO0vqKy3K/BtbVios 7jj/gnv/FmUyqi7VuwNzkcL+2Wl/cHkhdU02QnVf6ED8woDYJnoOPyggH5GOH7kxTz6FV9WH+B5S ON9frEzxi/qfJ9BsJ5337vwN/GrFLXt2vkYbF88ezH7jofYm7iWtveMl1WSkSm5hQpKnMOuWaaUf eYBfdBB8sDTHS2CZrix0PA1LWKKE3lGmM/Ker9n/kg9/AAAA//8DAFBLAwQUAAYACAAAACEAdD85 esIAAAAoAQAAHgAIAWN1c3RvbVhtbC9fcmVscy9pdGVtMS54bWwucmVscyCiBAEooAABAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAITPwYoCMQwG4LvgO5Tcnc54EJHpeFkWvIm44LV0MjPFaVOa KPr2Fk8rLOwxCfn+pN0/wqzumNlTNNBUNSiMjnofRwM/5+/VFhSLjb2dKaKBJzLsu+WiPeFspSzx 5BOrokQ2MImkndbsJgyWK0oYy2SgHKyUMo86WXe1I+p1XW90/m1A92GqQ28gH/oG1PmZSvL/Ng2D d/hF7hYwyh8R2t1YKFzCfMyUuMg2jygGvGB4t5qq3Au6a/XHf90LAAD//wMAUEsDBBQABgAIAAAA IQBOnpJlygoAADCHAAASAAAAd29yZC9udW1iZXJpbmcueG1s7F3NjuM2Er4vsO/QMODDHsbW/08j nsBu29gJssEimWDPbls9LawlGbK6O33Ny+QR9rHyClsUZZmUaMkq0R4O4sv0WBIpfWR95MdiqfTd 979F27vXIN2HSTwZ6CNtcBfE62QTxl8mg18/Lz94g7t9too3q20SB5PBe7AffP/x73/77u0+foke gxQuvIM64v39K5x+zrLd/Xi8Xz8H0Wo/SnZBDCefkjRaZfAz/TKOVul/X3Yf1km0W2XhY7gNs/ex oWnOoKgmmQxe0vi+qOJDFK7TZJ88ZaTIffL0FK6D4s+hRHrOfWnJebJ+iYI4y+84ToMtPEMS75/D 3f5QW4StDSA+Hyp5bQLxGm0P173tzrnbJl29QTtHW/rYb0m62aXJOtjv4eicnixr1LWmexcNSKoo S5zzCPw9D08SrcK4rIaYR6X/y84bQeeN6b3HpKojEGiLj2BMq8d9lq7W2U8v0R3369NmMtDyS+J9 uIFzr6stHPFcT9MXs8GYFI5etln4Y/AabD+/74LDNfnRLTlKr8qi3fZwzncsxzUtg57ZvpITIfw5 3AtMPs0OF9v0KrD3ZVQe3ATrMFoVVUPJz8Fv5bmhXtb7w/pQyzZ4yujh3b9T8tRhTOCQw5OB6doD +PG8ir/kzCO/Adr47b64OKVl0mUSZ3tyZRhDsU3wtALsxaX5NVAEnobUz6LS8xbkUJn0YbqgGg2P DXYmMN329IsiM+rIitbviGw0LFoE2u1McKZuGhw419CkdpspEdxoaNEePx+f5fgw/DNmqWueXICW XICjYcHV8zHavmZdFqMtHeNo6HTtStdyYWpnu9Ky5HalcwmYo6HbFannuKAlLonUvRDS0dDrClbX DJjEOLSeJrdfvcuhHQ39zoB1T+PHJEN3+gKGOZPRH61yhE6mrBzRTd3Vpk4x8YjlyPP7Yxpu/kWk yglRMp0uF/bMnJZtAv16ECXw32y3XYM+sTRf0zTBhC6c9h5fttug0B0wKLIq5c/f/1fe6cwJD+5d 0Sltbb/ar8NwMvjlPXpMQPUCLafQcNyBrkqm2hQmqTYDUQ9anqxBJDRN0rlhPB3XMA/JSxoG6d1P wRvTOpWj6/1kUDnUUf/lYwRnQPnjym21P3//o2u72baJa7f/gEwmi1RYtpU2xR/rZlbUiHiGSTcr BOMcw8Y1kDzG5fKIsx0VGOf41SXTmUNRlUh0PKoc7c84yi/WoNRgnOsgh3CeXbTV+GPdGJeLNM6s 8oWi7CGp8xznWcihXB7j3HxGY21HBcb5OnKsrnCrUACVo/0Zl8tCzqDUYJzvIYdwnl0YxnUUttSX wglb31topl4sN7HC1nM1b+q6x9UNzKxqCVvT1nkvgHnmbCKP9HT0U430lmHiGqZC70uRXlVha/k2 rt36k573/KoqbG3HxTWQPMbl9+cmDBWmWcf0cQ1zJcYpK2x15BAum3GqClvXQw7l8hinprAFfaY0 45QVtgZyCO/PuI7Clu6jscLW0Oa+vYCtn4YN5HaP7UJbeFOikPJawL+qnrCt7SzfhG2+4452ZV9p mlVW2GI93f1J/40IW6xLW940q6iwxbqyr8Q4VYUt2tMtm3HKClusS1se4xQVtlhX9pUYp6ywxXq6 +zOuo7Cl8VOcsDUXS9M2C18r1mOrme50Rnyiygpbw4ZYO7L3W4ZM3oQtDSU1ILAL0zBXIr2qwtb0 wYAw7daf9N+GsLUcCP7ENJC8aVZNYWtbEHKHaZgrMU5ZYasjh3DZjFNV2DoeciiXxzg1ha1rI8fq KzFOVWHrGcghvD/jOgpbGjTPCduZo9vObN7PYzt7mDsPS+dBYWHrIftIHunVDEWAkAylp1lVha1l KjLNKhuKADH1KP0mj3GKCltX7WlWWWFrIYfw/tMsv5RUVdjCe5Jfm3GKClsfOVb/1YWtgxzC+zOu o7Clr0lywnY5n2qW3fgue3sowoO+8JzZg8LCFq3f5E2zagpbtEC7EulVFbY2Vrf1Jz0/zSorbLH6 TR7j1BS2DlagXYlxqgpbtG6TzThlhS1Wv8ljnJrC1sMKtCsxTlWPrU9eRMLsLfVnXEdhS7NisMLW NL2ZQV7T7RVjO3uATCVT45h5CFqj9vIY7MBBVgT93Ff/m5M3/aN0Dp+ZFoGk/WnoI2hICA2up2SC IsXbJ45v2HNLSgYVY9T16XWSCabh8d/ueyafYvRj0U+zM3OKbJO3IP05iVZxCYrNYDE0RWDT8Mtz Rq8XZNrK04WwaCGhCLkYOim/WtxZjMKjELQlaTLEy8qNpmeJ8DQmDjNadgvEcBhVVvSIj4ST99CP QZYFqbiL7M6Q2taJYkiMZCqNDNdDbUbniBA1G11thXeW0TEi55JG54rwNBpd28JL3EOMMLm00Xnd IbUslcSQGNVwYaPzRYiaja62yDlhdACtS/Yjmg+Km+f95dQxtSJvETbk0HCmnuX6zfP8V81+1DYw 1SfKv0r2I+wO45XEPSNACgOis4XUnFGY7Ec3B9ageaJpGZWvwDhGKhW2o8RL4jcH1mSAYNzNgTVp ZhxMwB0Xg9LnOEYnKsS4mwMLkmMjGPftOLD83CnBClvLhwjcOeRAbnBg5XL3REJPuiYwjjmJYUF6 cF0RdxCXj1uYvpPzFux+yd63ZXrzfwYrkgCxKFbJ7dk9AzksUTknEPnd6hZB+duEMI6yn3Pw6IiU 43Yl/y/53YoElUZciOSYRbyGBJFivOpaJL9bwaDShgvBHF8AE4FBpBSHYZQzM/K7FQ8qS7gQz5GK J/AgMojrWiUjcX6gFRQqLbgQ1DEZ+GlQiJThum7zQ0J+oBUXyostxHVM/d2IC5EjXDf83LlWvjyY H2iFhkr8LYR2TIXXBg2TFLzq0M89/K3oUIm+heiOWb3PQIdJAm57/CgCX5kQDiMdXVt6/UMj1tw2 dHuZD7qnPjTSHpzlQQ9MdaM5OKv08SKkQW36F7kLG5fa1YmG7DsyJlNfaXfMQC0KvToPaEMK8855 urvvdRXLm6/oqerdSgjVXtslazWHop36bzu3h1ZJaJDOWYHb9tnq/JC+LlbTE4V2il+JUcy+oFK+ 39qW4NdiGLPLWDQQHaolO8c7M65tk/EKjFPTEwXrWZyL7kqMYzZFlWJcbT/0eozrqkOpX4V1Rdne cmrY7pJoMrwOfXCXlm9Nj6t6xiFFgiXy7NNK61DxPjwjLot9+IvFs8iPrxJDYvYsC0izPiE6tyCq hq8vtok7cQ8xeuzSRncLooKPXdYU04l4Fn4BwcibcmDDxYVxvvjqgvsWRAU91KZMxDxi9MKFRzp1 gqj0+qc2nLmxsGbzYj8HG0Xl+b6hu1B9rhPASr+5Gb6u62+eptrn3/p/LYfRF6VKl+BY+aM0vDNj 52+epsqnoNvESJ0fN0/TiY9kX9d3e/M0kZcoGj5Czkixm6eJV6k3T9NbHhbQ7ROCjHIs5zCctm/Y Y0LsnijlaYpfImgT+PfT5vBtXCbc/9MGTr6uILYr37QFAsOVRAdwxahaFRbLN+lPFKNxKMJiTXej 4R6di9GACmGxw+awCBuNVxAWy0N5TmCjsQDCYoeNU9Hd6Ca7sFiu/E/cjcamCYsdgptEdys2tIXl 8hCEE7crXqQUloM66b6w8IYNlkIXJafu2GAredDOqXINxnIIYBM+aIO1AHoGIb3xY5BCsN3H/wMA AP//AwBQSwMEFAAGAAgAAAAhABIscYnhAAAAVQEAABgAKABjdXN0b21YbWwvaXRlbVByb3BzMS54 bWwgoiQAKKAgAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAnJDBasMwDIbvg71D0N21 k6VZU+KUrlmg17HCrq7jJIbYCrYzNsbefQ47dcedxCchfT+qDh9mSt6V8xoth3TDIFFWYqftwOHy 2pIdJD4I24kJreJgEQ71/V3V+X0ngvABnToHZZLY0LGeGw5fLG1PrGQZOe3KB5Lnzy05smxL0u1T XpSsORaP7BuSqLbxjOcwhjDvKfVyVEb4Dc7KxmGPzogQ0Q0U+15L1aBcjLKBZowVVC5Rb97MBPWa 53f7RfX+Ftdoi9P/tVz1ddI4ODGPn0Driv5RrXzzivoHAAD//wMAUEsDBBQABgAIAAAAIQDR2d7j eQEAAOgCAAARAAgBZG9jUHJvcHMvY29yZS54bWwgogQBKKAAAQAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAACMUk1PwzAMvSPxH6rc2yQtn1XbSYB2YhISQyBuIfG2sDaNkmzd/j1pu3Wr4MAt9nt+ tp+TTXZVGWzBWFmrHNGIoAAUr4VUyxy9zafhHQqsY0qwslaQoz1YNCkuLzKuU14beDG1BuMk2MAr KZtynaOVczrF2PIVVMxGnqE8uKhNxZwPzRJrxtdsCTgm5AZX4JhgjuFWMNSDIjpICj5I6o0pOwHB MZRQgXIW04jiE9eBqeyfBR1yxqyk22u/02Hcc23Be3Bg76wciE3TRE3SjeHnp/hj9vzarRpK1XrF ARWZ4KmTroQiw6enf9nN1zdw16eHwAPcAHO1KQSAZuvIdnXHZGv3GvZNbYT1paPI1wqw3Ejt/BF7 4VHCs0tm3cxfdSFBPOzPevzG2lYGtrL9EQW96poNsV+rc7GfFkTgfUl7F4/Ie/L4NJ+iIiaUhuQ+ JHROrtMkSQn5bHca1bc+9YnqMN3/FGmcxrdjxaNAb8/4bxY/AAAA//8DAFBLAwQUAAYACAAAACEA qchcqowAAADaAAAAEwAoAGN1c3RvbVhtbC9pdGVtMS54bWwgoiQAKKAgAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAskmyCs4vLUpOLVYITs1JTS5JTQkuqcxJtVWKcQxw1IsI9lFSAAv4 JeYCBYFiSgoVuTl5xVZJtkoZJSUFVvr6xckZqbmJxXr5Bal5QLm0/KLcxBIgtyhdPz8tLTM51SU/ uTQ3Na9E38jAwEw/KTMpJzM/vSixIKMSahhVjLKz0Yd7xo6XCwAAAP//AwBQSwMEFAAGAAgAAAAh AEvRgkNWAgAAOgkAABIAAAB3b3JkL2ZvbnRUYWJsZS54bWy8lV1v2jAUhu8n7T9Evl/jmFA+1FAB BWk3u1hb7doEByzFdmQHUv79juOQ0REmXJWB+MiJfXL8+D2vHx7fRB7smTZcyQRFdxgFTKZqzeUm Qa8vy29DFJiSyjXNlWQJOjCDHidfvzxU40zJ0gQwX5qxTtC2LItxGJp0ywQ1d6pgEu5lSgtawqXe hCrLeMqeVLoTTJYhwfg+1CynJTzbbHlhUJOtuiZbpfS60CplxkCxInf5BOUSTZrqgmosqYCqX7hg JvjBquCnEtQNKKhUhkUwZk/zBGEC73vcw30cw4fAvxiFNlO6pdqwsh2IXTijgueHY1TXeevxBS/T 7TG+p5rTVc7cHMM3cGNnVjhBC4wxmS6XyEWiBM0hMhjGURMhUJR7jZpIr43ANkFhdZ56SOTyQATy NLPqOkO3T2dEng9ipfKa1N8g+rD8CABEeABACFwNukGQzwHRltuCiJrQGYh62YCvE8TwZNb1IOZq pznTVhydNAhQ6OERcLAkCIjDRxZCrZmWjtM7XWT8ja09RNE7Y3EDUfyCRrKdbzpJ9I8b9efXQxd0 V6oODpf74/iUZuGg6/8qC5rzleadIAhe1lKwkohBHPDdDaLTKUzFjfEisbALJ6dOEUNgOm8jXk4x qh3Ho0GoABD0Agnrlc4zrXf6kfD3zKkVBVmceKYlgXE8O2uPf1pFPSnyJfHMNooFr98voJg1/mBF YaXRu7koyDtR2ONjEQ+OcFpRkCuc4slTFFNQRPfpQfAMTg1HwFLwk8QHmgNW3XmM3sYxm/PUTH4D AAD//wMAUEsDBBQABgAIAAAAIQBK2IqSuwAAAAQBAAAUAAAAd29yZC93ZWJTZXR0aW5ncy54bWyM zsFqwzAMxvF7Ye8QdF+d9TBKSFIooy/Q9QFcR2kMsWQkbd729DVsl916FJ/48e8PX2ltPlE0Mg3w sm2hQQo8RboNcHk/Pe+hUfM0+ZUJB/hGhcP4tOlLV/B6RrP6qU1VSDsZYDHLnXMaFkxet5yR6jaz JG/1lJvjeY4B3zh8JCRzu7Z9dYKrt1qgS8wKf1p5RCssUxYOqFpD0vrrJR8JxtrI2WKKP3hiOQoX RXFj7/61j3cAAAD//wMAUEsDBBQABgAIAAAAIQD+uyxJ5AEAAN4DAAAQAAgBZG9jUHJvcHMvYXBw LnhtbCCiBAEooAABAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAJxTwW7bMAy9D9g/GL43irMk ywpGxZBi6GFbA8Rtz5pMJ8JkSZDUoNnXj7IbV9l2mk+PjwT59EjDzUuniyP6oKxZl9VkWhZopG2U 2a/Lh/rL1aosQhSmEdoaXJcnDOUNf/8Ott469FFhKKiFCevyEKO7ZizIA3YiTChtKNNa34lIod8z 27ZK4q2Vzx2ayGbT6ZLhS0TTYHPlxobl0PH6GP+3aWNl0hce65MjwRxq7JwWEfn3JEcDGwmobRS6 Vh3y2aqixBjCVuwx8CWwAcCT9U3gVTUnasCwOQgvZCT/+HLxYQUsI+Czc1pJEcla/k1Jb4NtY3Hf m1CkBsDyEiBjdiifvYonPgWWh/BVGdKymAMbEInzYu+FO5CiRZI4hrCTQuOG3s9boQMCeyPgDkXa 7VYokgzHeH1EGa0vgvpF252VxQ8RMLm2Lo/CK2EiuZfKhqDH2oXoea2ipt6UG+Ie5mU5VnNO3lIt gcvCRA4aKHGprp8Q7lt6W/yH2CoX22sYpGZyMjjO+KPrxnZOmBMNHxE5/DM8uNrepot59fCSzBb/ pOJh54Sk9XxcLj/lJ5ClYEeXgg3t9NzwjYA78tvrNJXOx+yxOdf8nUhH9Tj8rryaTab09Vd05ugS xv+I/wYAAP//AwBQSwECLQAUAAYACAAAACEA4Q+Ov40BAAApBgAAEwAAAAAAAAAAAAAAAAAAAAAA W0NvbnRlbnRfVHlwZXNdLnhtbFBLAQItABQABgAIAAAAIQAekRq38wAAAE4CAAALAAAAAAAAAAAA AAAAAMYDAABfcmVscy8ucmVsc1BLAQItABQABgAIAAAAIQDX5gieIAEAAEQEAAAcAAAAAAAAAAAA AAAAAOoGAAB3b3JkL19yZWxzL2RvY3VtZW50LnhtbC5yZWxzUEsBAi0AFAAGAAgAAAAhAJDXKQ+a JgAAs0YBABEAAAAAAAAAAAAAAAAATAkAAHdvcmQvZG9jdW1lbnQueG1sUEsBAi0AFAAGAAgAAAAh AJa1reKWBgAAUBsAABUAAAAAAAAAAAAAAAAAFTAAAHdvcmQvdGhlbWUvdGhlbWUxLnhtbFBLAQIt ABQABgAIAAAAIQCvHYinqQMAAEgJAAARAAAAAAAAAAAAAAAAAN42AAB3b3JkL3NldHRpbmdzLnht bFBLAQItABQABgAIAAAAIQBTLah4LwsAAE1kAAAPAAAAAAAAAAAAAAAAALY6AAB3b3JkL3N0eWxl cy54bWxQSwECLQAUAAYACAAAACEAdD85esIAAAAoAQAAHgAAAAAAAAAAAAAAAAASRgAAY3VzdG9t WG1sL19yZWxzL2l0ZW0xLnhtbC5yZWxzUEsBAi0AFAAGAAgAAAAhAE6ekmXKCgAAMIcAABIAAAAA AAAAAAAAAAAAGEgAAHdvcmQvbnVtYmVyaW5nLnhtbFBLAQItABQABgAIAAAAIQASLHGJ4QAAAFUB AAAYAAAAAAAAAAAAAAAAABJTAABjdXN0b21YbWwvaXRlbVByb3BzMS54bWxQSwECLQAUAAYACAAA ACEA0dne43kBAADoAgAAEQAAAAAAAAAAAAAAAABRVAAAZG9jUHJvcHMvY29yZS54bWxQSwECLQAU AAYACAAAACEAqchcqowAAADaAAAAEwAAAAAAAAAAAAAAAAABVwAAY3VzdG9tWG1sL2l0ZW0xLnht bFBLAQItABQABgAIAAAAIQBL0YJDVgIAADoJAAASAAAAAAAAAAAAAAAAAOZXAAB3b3JkL2ZvbnRU YWJsZS54bWxQSwECLQAUAAYACAAAACEAStiKkrsAAAAEAQAAFAAAAAAAAAAAAAAAAABsWgAAd29y ZC93ZWJTZXR0aW5ncy54bWxQSwECLQAUAAYACAAAACEA/rssSeQBAADeAwAAEAAAAAAAAAAAAAAA AABZWwAAZG9jUHJvcHMvYXBwLnhtbFBLBQYAAAAADwAPANQDAABzXgAAAAA= --_002_90F0F47595235141A4380FCF01B0185B20BC608BBCCHNHCLTEVS07H_ Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel --_002_90F0F47595235141A4380FCF01B0185B20BC608BBCCHNHCLTEVS07H_-- From xen-devel-bounces@lists.xensource.com Thu Sep 01 06:15:48 2011 Return-path: Envelope-to: www-data@lists.xensource.com Delivery-date: Thu, 01 Sep 2011 06:15:48 -0700 Received: from localhost ([127.0.0.1] helo=lists.colo.xensource.com) by lists.xensource.com with esmtp (Exim 4.43) id 1Qz77T-0002HN-0c; Thu, 01 Sep 2011 06:15:47 -0700 Received: from mail27.messagelabs.com ([193.109.254.147]) by lists.xensource.com with esmtp (Exim 4.43) id 1Qz76f-00024W-0W for xen-devel@lists.xensource.com; Thu, 01 Sep 2011 06:14:57 -0700 X-Env-Sender: konrad@dumpdata.com X-Msg-Ref: server-2.tower-27.messagelabs.com!1314882871!53201214!1 X-Originating-IP: [141.146.126.227] X-StarScan-Version: 6.3.6; banners=-,-,- X-VirusChecked: Checked Received: (qmail 15914 invoked from network); 1 Sep 2011 13:14:32 -0000 Received: from acsinet15.oracle.com (HELO acsinet15.oracle.com) (141.146.126.227) by server-2.tower-27.messagelabs.com with DHE-RSA-AES256-SHA encrypted SMTP; 1 Sep 2011 13:14:32 -0000 Received: from rtcsinet21.oracle.com (rtcsinet21.oracle.com [66.248.204.29]) by acsinet15.oracle.com (Switch-3.4.4/Switch-3.4.4) with ESMTP id p81DEmlQ023623 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Thu, 1 Sep 2011 13:14:50 GMT Received: from acsmt356.oracle.com (acsmt356.oracle.com [141.146.40.156]) by rtcsinet21.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id p81DEkXi025323 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 1 Sep 2011 13:14:47 GMT Received: from abhmt102.oracle.com (abhmt102.oracle.com [141.146.116.54]) by acsmt356.oracle.com (8.12.11.20060308/8.12.11) with ESMTP id p81DEeoV001354; Thu, 1 Sep 2011 08:14:41 -0500 Received: from phenom (/209.6.55.207) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Thu, 01 Sep 2011 06:14:40 -0700 Received: by phenom (Postfix, from userid 1000) id D119FEBD; Thu, 1 Sep 2011 09:14:37 -0400 (EDT) Date: Thu, 1 Sep 2011 09:14:37 -0400 From: Konrad Rzeszutek Wilk To: David Vrabel Subject: Re: [Xen-devel] [PATCH 1/5] xen: use maximum reservation to limit amount of usable RAM Message-ID: <20110901131437.GA23971@dumpdata.com> References: <1313765840-22084-1-git-send-email-david.vrabel@citrix.com> <1313765840-22084-2-git-send-email-david.vrabel@citrix.com> <20110831204057.GA641@dumpdata.com> <4E5F769A.5080303@citrix.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <4E5F769A.5080303@citrix.com> User-Agent: Mutt/1.5.21 (2010-09-15) X-Source-IP: rtcsinet21.oracle.com [66.248.204.29] X-CT-RefId: str=0001.0A090209.4E5F854A.0140,ss=1,re=0.000,fgs=0 Cc: "xen-devel@lists.xensource.com" X-BeenThere: xen-devel@lists.xensource.com X-Mailman-Version: 2.1.5 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xensource.com Errors-To: xen-devel-bounces@lists.xensource.com > > I ran this on three setups: > > > > 1) PV (domU) > > 2) PV+PCI (dom0) > > 3) PV+PCI+e820_hole=1 (domU) > > > > and then the same without this patch. > > > > Both the 2) and 3) worked correctly - the E820 had the same non-RAM regions and > > gaps - and the last RAM E820 entry was properly truncated. However, when it > > came to pure PV it was truncated more than it should: > > > > domU: domU: > > 0000000000000000 - 00000000000a0000 (usable) 0000000000000000 - 00000000000a0000 (usable) > > 00000000000a0000 - 0000000000100000 (reserved) 00000000000a0000 - 0000000000100000 (reserved) > > 0000000000100000 - 0000000040800000 (usable) | 0000000000100000 - 0000000040100000 (usable) > > > > (left has the old PV - without your patch). Which makes me think that there is something > > amiss in the toolstack? I used 'xl' (latest xen-unstable from today). > > What were you expecting? It looks like xl is either: specifying a memory > map that is larger than it should be or b) setting the maximum > reservation as too low. And if you asked for 1 GiB neither looks right. 'xm' is even worst. It ends up truncating it to 40000000 exactly. Anyhow, I chatted with Ian about it and also the thread "difference between xen hypervisor and common kernel on handling BIOS's e820 map" nails the coffin to this - there is no need anymore for that 8MB of extra space. So - off to look at your next set of patches :-) _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel From xen-devel-bounces@lists.xensource.com Thu Sep 01 06:48:34 2011 Return-path: Envelope-to: www-data@lists.xensource.com Delivery-date: Thu, 01 Sep 2011 06:48:34 -0700 Received: from localhost ([127.0.0.1] helo=lists.colo.xensource.com) by lists.xensource.com with esmtp (Exim 4.43) id 1Qz7dC-0003ez-HN; Thu, 01 Sep 2011 06:48:34 -0700 Received: from mail182.messagelabs.com ([85.158.139.83]) by lists.xensource.com with esmtp (Exim 4.43) id 1Qz7cT-0003SV-Ff for xen-devel@lists.xensource.com; Thu, 01 Sep 2011 06:47:49 -0700 X-Env-Sender: konrad@dumpdata.com X-Msg-Ref: server-14.tower-182.messagelabs.com!1314884864!16531511!1 X-Originating-IP: [141.146.126.227] X-StarScan-Version: 6.3.6; banners=-,-,- X-VirusChecked: Checked Received: (qmail 3690 invoked from network); 1 Sep 2011 13:47:46 -0000 Received: from acsinet15.oracle.com (HELO acsinet15.oracle.com) (141.146.126.227) by server-14.tower-182.messagelabs.com with DHE-RSA-AES256-SHA encrypted SMTP; 1 Sep 2011 13:47:46 -0000 Received: from rtcsinet22.oracle.com (rtcsinet22.oracle.com [66.248.204.30]) by acsinet15.oracle.com (Switch-3.4.4/Switch-3.4.4) with ESMTP id p81DknbJ007131 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Thu, 1 Sep 2011 13:46:51 GMT Received: from acsmt356.oracle.com (acsmt356.oracle.com [141.146.40.156]) by rtcsinet22.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id p81Dklkp014963 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 1 Sep 2011 13:46:48 GMT Received: from abhmt114.oracle.com (abhmt114.oracle.com [141.146.116.66]) by acsmt356.oracle.com (8.12.11.20060308/8.12.11) with ESMTP id p81DkfhZ025988; Thu, 1 Sep 2011 08:46:41 -0500 Received: from phenom (/209.6.55.207) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Thu, 01 Sep 2011 06:46:41 -0700 Received: by phenom (Postfix, from userid 1000) id EA493FD1; Thu, 1 Sep 2011 09:46:38 -0400 (EDT) Date: Thu, 1 Sep 2011 09:46:38 -0400 From: Konrad Rzeszutek Wilk To: "Deepak Kr. Sharma - ERS, HCL Tech" Subject: Re: [Xen-devel] FW: HXEN on linux Message-ID: <20110901134638.GB23971@dumpdata.com> References: <90F0F47595235141A4380FCF01B0185B20BC426222@CHN-HCLT-EVS07.HCLT.CORP.HCL.IN> <20110809195159.GA7834@dumpdata.com> <90F0F47595235141A4380FCF01B0185B20BC513BCB@CHN-HCLT-EVS07.HCLT.CORP.HCL.IN> <90F0F47595235141A4380FCF01B0185B20BC585A8A@CHN-HCLT-EVS07.HCLT.CORP.HCL.IN> <90F0F47595235141A4380FCF01B0185B20BC608BBC@CHN-HCLT-EVS07.HCLT.CORP.HCL.IN> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <90F0F47595235141A4380FCF01B0185B20BC608BBC@CHN-HCLT-EVS07.HCLT.CORP.HCL.IN> User-Agent: Mutt/1.5.21 (2010-09-15) X-Source-IP: rtcsinet22.oracle.com [66.248.204.30] X-CT-RefId: str=0001.0A090201.4E5F8CF8.00C8,ss=1,re=0.000,fgs=0 Cc: "todd.deshane.xen@gmail.com" , "xen-devel@lists.xensource.com" , Lars Kurth , Stefano Stabellini X-BeenThere: xen-devel@lists.xensource.com X-Mailman-Version: 2.1.5 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xensource.com Errors-To: xen-devel-bounces@lists.xensource.com On Thu, Sep 01, 2011 at 06:00:26PM +0530, Deepak Kr. Sharma - ERS, HCL Tech wrote: > Hello All, > > I am sending a doc that captures our understanding of HXen. > > We need inputs and suggestions from you all to correct any discrepancies and clarify our grey areas. Ok, first question - why are you doing it? > > Based on your inputs, we will define our path ahead. > > Regards, > Deepak > > -----Original Message----- > From: Deepak Kr. Sharma - ERS, HCL Tech > Sent: 30 August 2011 12:41 > To: 'Stefano Stabellini' > Cc: Konrad Rzeszutek Wilk; todd.deshane.xen@gmail.com; xen-devel@lists.xensource.com; Lars Kurth > Subject: RE: [Xen-devel] FW: HXEN on linux > > Hello, > > I understand that there is no document available for HXen. > > Please correct me if I am wrong but I assume that HXen draws some stuff from Xen. Is that correlation known and can it be explained? > > We have started identifying the blocks in HXen and will be sending out very soon an assessment and understanding of what we want to do. I would request you all to validate the same and give your precious inputs. > > The first challenge is to identify the big picture of HXen and our focus area. > > Regards, > Deepak > > -----Original Message----- > From: Stefano Stabellini [mailto:stefano.stabellini@eu.citrix.com] > Sent: 26 August 2011 17:37 > To: Deepak Kr. Sharma - ERS, HCL Tech > Cc: Stefano Stabellini; Konrad Rzeszutek Wilk; todd.deshane.xen@gmail.com; xen-devel@lists.xensource.com; Lars Kurth > Subject: RE: [Xen-devel] FW: HXEN on linux > > On Fri, 26 Aug 2011, Deepak Kr. Sharma - ERS, HCL Tech wrote: > > Hello, > > > > I have few concerns regarding this project that we want to carry out: > > > > 1. It would be great to get some documents/technical information that will help us to get a better understanding of the work that has already been done and the work that has to be done, e.g. a detailed architecture of HXen will be a great help. > > like Tim wrote, there isn't one. > > > > 2. Is there any preference of development tools on linux? > > you mean, apart from make and gcc? > > > > 3. In the current state, is there a way to configure virtualized hardware? For example, can we configure the network card or sound card that is being virtualized to the guest OS? > > I think qemu is still used as hardware emulator in HXEN, so there should > be some degrees of configuration. > > ::DISCLAIMER:: > ----------------------------------------------------------------------------------------------------------------------- > > The contents of this e-mail and any attachment(s) are confidential and intended for the named recipient(s) only. > It shall not attach any liability on the originator or HCL or its affiliates. Any views or opinions presented in > this email are solely those of the author and may not necessarily reflect the opinions of HCL or its affiliates. > Any form of reproduction, dissemination, copying, disclosure, modification, distribution and / or publication of > this message without the prior written consent of the author of this e-mail is strictly prohibited. If you have > received this email in error please delete it and notify the sender immediately. Before opening any mail and > attachments please check them for viruses and defect. > > ----------------------------------------------------------------------------------------------------------------------- > _______________________________________________ > Xen-devel mailing list > Xen-devel@lists.xensource.com > http://lists.xensource.com/xen-devel _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel From xen-devel-bounces@lists.xensource.com Thu Sep 01 07:25:15 2011 Return-path: Envelope-to: www-data@lists.xensource.com Delivery-date: Thu, 01 Sep 2011 07:25:15 -0700 Received: from localhost ([127.0.0.1] helo=lists.colo.xensource.com) by lists.xensource.com with esmtp (Exim 4.43) id 1Qz8Ch-0005at-5Q; Thu, 01 Sep 2011 07:25:15 -0700 Received: from mail174.messagelabs.com ([85.158.138.51]) by lists.xensource.com with esmtp (Exim 4.43) id 1Qz8C0-0005JE-FD for xen-devel@lists.xensource.com; Thu, 01 Sep 2011 07:24:33 -0700 X-Env-Sender: konrad@dumpdata.com X-Msg-Ref: server-9.tower-174.messagelabs.com!1314887064!23867869!1 X-Originating-IP: [148.87.113.117] X-StarScan-Version: 6.3.6; banners=-,-,- X-VirusChecked: Checked Received: (qmail 13022 invoked from network); 1 Sep 2011 14:24:28 -0000 Received: from rcsinet15.oracle.com (HELO rcsinet15.oracle.com) (148.87.113.117) by server-9.tower-174.messagelabs.com with DHE-RSA-AES256-SHA encrypted SMTP; 1 Sep 2011 14:24:28 -0000 Received: from acsinet21.oracle.com (acsinet21.oracle.com [141.146.126.237]) by rcsinet15.oracle.com (Switch-3.4.4/Switch-3.4.4) with ESMTP id p81EOAAd005919 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Thu, 1 Sep 2011 14:24:12 GMT Received: from acsmt356.oracle.com (acsmt356.oracle.com [141.146.40.156]) by acsinet21.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id p81EO7Xk005449 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 1 Sep 2011 14:24:07 GMT Received: from abhmt101.oracle.com (abhmt101.oracle.com [141.146.116.53]) by acsmt356.oracle.com (8.12.11.20060308/8.12.11) with ESMTP id p81ENxmP022938; Thu, 1 Sep 2011 09:23:59 -0500 Received: from phenom (/209.6.55.207) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Thu, 01 Sep 2011 07:23:59 -0700 Received: by phenom (Postfix, from userid 1000) id 913C3FD1; Thu, 1 Sep 2011 10:23:56 -0400 (EDT) Date: Thu, 1 Sep 2011 10:23:56 -0400 From: Konrad Rzeszutek Wilk To: Ian Campbell Subject: Re: [Xen-devel] Kernel bug from 3.0 (was phy disks and vifs timing out in DomU) Message-ID: <20110901142356.GD23971@dumpdata.com> References: <4E3266DE.9000606@overnetdata.com> <20110803152841.GA2860@dumpdata.com> <4E4E3957.1040007@overnetdata.com> <20110819125615.GA26558@dumpdata.com> <4E56B132.9050708@overnetdata.com> <20110826142606.GA25511@dumpdata.com> <20110826144438.GA24836@dumpdata.com> <4E5E6843.7050206@citrix.com> <20110831170711.GB13642@dumpdata.com> <1314862972.28989.74.camel@zakaz.uk.xensource.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <1314862972.28989.74.camel@zakaz.uk.xensource.com> User-Agent: Mutt/1.5.21 (2010-09-15) X-Source-IP: acsinet21.oracle.com [141.146.126.237] X-Auth-Type: Internal IP X-CT-RefId: str=0001.0A090205.4E5F958F.001C:SCFMA922111,ss=1,re=-4.000,fgs=0 Cc: Todd Deshane , "xen-devel@lists.xensource.com" , Jeremy Fitzhardinge , David Vrabel , Anthony Wright X-BeenThere: xen-devel@lists.xensource.com X-Mailman-Version: 2.1.5 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xensource.com Errors-To: xen-devel-bounces@lists.xensource.com On Thu, Sep 01, 2011 at 08:42:52AM +0100, Ian Campbell wrote: > On Wed, 2011-08-31 at 18:07 +0100, Konrad Rzeszutek Wilk wrote: > > On Wed, Aug 31, 2011 at 05:58:43PM +0100, David Vrabel wrote: > > > On 26/08/11 15:44, Konrad Rzeszutek Wilk wrote: > > > > > > > > So while I am still looking at the hypervisor code to figure out why > > > > it would give me [when trying to map a grant page]: > > > > > > > > (XEN) mm.c:3846:d0 Could not find L1 PTE for address fbb42000 > > > > > > It is failing in guest_map_l1e() because the page for the vmalloc'd > > > virtual address PTEs is not present. > > > > > > The test that fails is: > > > > > > (l2e_get_flags(l2e) & (_PAGE_PRESENT | _PAGE_PSE)) != _PAGE_PRESENT > > > > > > I think this is because the GNTTABOP_map_grant_ref hypercall is done > > > when task->active_mm != &init_mm and alloc_vm_area() only adds PTEs into > > > init_mm so when Xen looks in the page tables it doesn't find the entries > > > because they're not there yet. > > > > > > Putting a call to vmalloc_sync_all() after create_vm_area() and before > > > the hypercall makes it work for me. Classic Xen kernels used to have > > > such a call. > > > > That sounds quite reasonable. > > I was wondering why upstream was missing the vmalloc_sync_all() in > alloc_vm_area() since the out-of-tree kernels did have it and the > function was added by us. I found this: > http://git.kernel.org/?p=linux/kernel/git/torvalds/linux.git;a=commitdiff;h=ef691947d8a3d479e67652312783aedcf629320a > > commit ef691947d8a3d479e67652312783aedcf629320a > Author: Jeremy Fitzhardinge > Date: Wed Dec 1 15:45:48 2010 -0800 > > vmalloc: remove vmalloc_sync_all() from alloc_vm_area() > > There's no need for it: it will get faulted into the current pagetable > as needed. > > Signed-off-by: Jeremy Fitzhardinge > > The flaw in the reasoning here is that you cannot take a kernel fault > while processing a hypercall, so hypercall arguments must have been > faulted in beforehand and that is what the sync_all was for. > > It's probably fair to say that the Xen specific caller should take care > of that Xen-specific requirement rather than pushing it into common > code. On the other hand Xen is the only user and creating a Xen specific > helper/wrapper seems a bit pointless. Perhaps then doing the vmalloc_sync_all() (or are more precise one: vmalloc_sync_one) should be employed in the netback code then? And obviously guarded by the CONFIG_HIGHMEM case? _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel From xen-devel-bounces@lists.xensource.com Thu Sep 01 07:26:05 2011 Return-path: Envelope-to: www-data@lists.xensource.com Delivery-date: Thu, 01 Sep 2011 07:26:05 -0700 Received: from localhost ([127.0.0.1] helo=lists.colo.xensource.com) by lists.xensource.com with esmtp (Exim 4.43) id 1Qz8DV-0005xx-0h; Thu, 01 Sep 2011 07:26:05 -0700 Received: from mail174.messagelabs.com ([85.158.138.51]) by lists.xensource.com with esmtp (Exim 4.43) id 1Qz8Cy-0005hs-Bi for xen-devel@lists.xensource.com; Thu, 01 Sep 2011 07:25:32 -0700 X-Env-Sender: George.Dunlap@eu.citrix.com X-Msg-Ref: server-15.tower-174.messagelabs.com!1314887125!23552967!1 X-Originating-IP: [66.165.176.89] X-StarScan-Version: 6.3.6; banners=-,-,- X-VirusChecked: Checked Received: (qmail 24898 invoked from network); 1 Sep 2011 14:25:28 -0000 Received: from smtp.citrix.com (HELO SMTP.CITRIX.COM) (66.165.176.89) by server-15.tower-174.messagelabs.com with RC4-SHA encrypted SMTP; 1 Sep 2011 14:25:28 -0000 X-IronPort-AV: E=Sophos;i="4.68,313,1312171200"; d="scan'208";a="16626663" Received: from ftlpmailmx01.citrite.net ([10.13.107.65]) by FTLPIPO01.CITRIX.COM with ESMTP/TLS/RC4-MD5; 01 Sep 2011 10:25:24 -0400 Received: from smtp01.ad.xensource.com (10.219.128.104) by smtprelay.citrix.com (10.13.107.65) with Microsoft SMTP Server id 8.3.137.0; Thu, 1 Sep 2011 10:25:24 -0400 Received: from [127.0.1.1] (elijah.uk.xensource.com [10.80.2.24]) by smtp01.ad.xensource.com (8.13.1/8.13.1) with ESMTP id p81EPMwm028827; Thu, 1 Sep 2011 07:25:23 -0700 Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Mercurial-Node: ede81b0552be5b4d1004f3b7b722ed79c9c7c98e Message-ID: User-Agent: Mercurial-patchbomb/1.4.3 Date: Thu, 1 Sep 2011 15:20:04 +0100 From: George Dunlap To: xen-devel@lists.xensource.com Cc: george.dunlap@eu.citrix.com Subject: [Xen-devel] [PATCH] xen, vtd: Fix device check for devices behind PCIe-to-PCI bridges X-BeenThere: xen-devel@lists.xensource.com X-Mailman-Version: 2.1.5 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xensource.com Errors-To: xen-devel-bounces@lists.xensource.com On some systems, requests devices behind a PCIe-to-PCI bridge all appear to the IOMMU as though they come from from slot 0, function 0 on that device; so the mapping code much punch a hole for X:0.0 in the IOMMU for such devices. When punching the hole, if that device has already been mapped once, we simply need to check ownership to make sure it's legal. To do so, domain_context_mapping_one() will look up the device for the mapping with pci_get_pdev() and look for the owner. However, if there is no device in X:0.0, this look up will fail. Rather than returning -ENODEV in this situation (causing a failure in mapping the device), try to get the domain ownership from the iommu context mapping itself. Signed-off-by: George Dunlap diff -r 4a4882df5649 -r ede81b0552be xen/drivers/passthrough/vtd/iommu.c --- a/xen/drivers/passthrough/vtd/iommu.c Wed Aug 31 15:23:49 2011 +0100 +++ b/xen/drivers/passthrough/vtd/iommu.c Thu Sep 01 15:18:18 2011 +0100 @@ -113,6 +113,27 @@ static int context_set_domain_id(struct return 0; } +static int context_get_domain_id(struct context_entry *context, + struct iommu *iommu) +{ + unsigned long dom_index, nr_dom; + int domid = -1; + + if (iommu && context) + { + nr_dom = cap_ndoms(iommu->cap); + + dom_index = context_domain_id(*context); + + if ( dom_index < nr_dom && iommu->domid_map) + domid = iommu->domid_map[dom_index]; + else + dprintk(XENLOG_DEBUG VTDPREFIX, "%s: dom_index %lu exceeds nr_dom %lu or iommu has no domid_map\n", + __func__, dom_index, nr_dom); + } + return domid; +} + static struct intel_iommu *__init alloc_intel_iommu(void) { struct intel_iommu *intel; @@ -1237,7 +1258,6 @@ int domain_context_mapping_one( struct hvm_iommu *hd = domain_hvm_iommu(domain); struct context_entry *context, *context_entries; u64 maddr, pgd_maddr; - struct pci_dev *pdev = NULL; int agaw; ASSERT(spin_is_locked(&pcidevs_lock)); @@ -1249,12 +1269,45 @@ int domain_context_mapping_one( if ( context_present(*context) ) { int res = 0; + struct pci_dev *pdev = NULL; + /* First try to get domain ownership from device structure. If that's + * not available, try to read it from the context itself. */ pdev = pci_get_pdev(bus, devfn); - if (!pdev) - res = -ENODEV; - else if (pdev->domain != domain) - res = -EINVAL; + if ( pdev ) + { + if ( pdev->domain != domain ) + { + dprintk(XENLOG_INFO VTDPREFIX, "d%d: bdf = %x:%x.%x owned by d%d!", + domain->domain_id, + bus, PCI_SLOT(devfn), PCI_FUNC(devfn), + (pdev->domain) + ? pdev->domain->domain_id : -1); + res = -EINVAL; + } + } + else + { + int cdomain; + cdomain = context_get_domain_id(context, iommu); + + if ( cdomain < 0 ) + { + dprintk(VTDPREFIX, "d%d: bdf = %x:%x.%x mapped, but can't find owner!\n", + domain->domain_id, + bus, PCI_SLOT(devfn), PCI_FUNC(devfn)); + res = -EINVAL; + } + else if ( cdomain != domain->domain_id ) + { + dprintk(XENLOG_INFO VTDPREFIX, "d%d: bdf = %x:%x.%x already mapped to d%d!", + domain->domain_id, + bus, PCI_SLOT(devfn), PCI_FUNC(devfn), + cdomain); + res = -EINVAL; + } + } + unmap_vtd_domain_page(context_entries); spin_unlock(&iommu->lock); return res; _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel From xen-devel-bounces@lists.xensource.com Thu Sep 01 07:29:01 2011 Return-path: Envelope-to: www-data@lists.xensource.com Delivery-date: Thu, 01 Sep 2011 07:29:01 -0700 Received: from localhost ([127.0.0.1] helo=lists.colo.xensource.com) by lists.xensource.com with esmtp (Exim 4.43) id 1Qz8GL-0006Ms-LZ; Thu, 01 Sep 2011 07:29:01 -0700 Received: from mail216.messagelabs.com ([85.158.143.99]) by lists.xensource.com with smtp (Exim 4.43) id 1Qz8Fs-0006AT-SV for xen-devel@lists.xensource.com; Thu, 01 Sep 2011 07:28:33 -0700 X-Env-Sender: tobias.geiger@vido.info X-Msg-Ref: server-11.tower-216.messagelabs.com!1314887309!9152975!1 X-Originating-IP: [78.47.43.171] X-StarScan-Version: 6.3.6; banners=-,-,- X-VirusChecked: Checked Received: (qmail 11729 invoked from network); 1 Sep 2011 14:28:29 -0000 Received: from www.vido.info (HELO mail.vido.info) (78.47.43.171) by server-11.tower-216.messagelabs.com with SMTP; 1 Sep 2011 14:28:29 -0000 Received: from localhost (ip6-localhost [127.0.0.1]) by mail.vido.info (Postfix) with ESMTP id 90868D34248; Thu, 1 Sep 2011 16:28:29 +0200 (CEST) X-Virus-Scanned: by amavis at mail.vido.info Received: from mail.vido.info ([127.0.0.1]) by localhost (mail.vido.info [127.0.0.1]) (amavisd-new, port 10024) with LMTP id N1li2rZYW+S9; Thu, 1 Sep 2011 16:28:18 +0200 (CEST) Received: from lxgeigert.localnet (et-1-10.gw-nat.bs.kae.de.oneandone.net [212.227.35.74]) by mail.vido.info (Postfix) with ESMTPSA id B23F4D34833; Thu, 1 Sep 2011 16:28:10 +0200 (CEST) From: Tobias Geiger Organization: VIDO IT-Service To: xen-devel@lists.xensource.com Subject: Re: [Xen-devel] Re: cs 23453:4f4970d2848d beaks Win 7 Date: Thu, 1 Sep 2011 16:28:09 +0200 User-Agent: KMail/1.13.7 (Linux/2.6.39-2-amd64; KDE/4.6.5; x86_64; ; ) References: <4E5F43F2.6010601@amd.com> <1314869549.28989.86.camel@zakaz.uk.xensource.com> <4E5F541F.6010405@amd.com> In-Reply-To: <4E5F541F.6010405@amd.com> MIME-Version: 1.0 Content-Type: Text/Plain; charset="utf-8" Content-Transfer-Encoding: 7bit Message-Id: <201109011628.09908.tobias.geiger@vido.info> Cc: Ian Campbell , Christoph Egger X-BeenThere: xen-devel@lists.xensource.com X-Mailman-Version: 2.1.5 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xensource.com Errors-To: xen-devel-bounces@lists.xensource.com Hallo List!, To bring even more confusion to this: W7 64bit (prof) HVM guest works fine here (i.e. no BSOD like the ones described here) with: xen_changeset : Thu Aug 25 12:03:14 2011 +0100 23791:227130622561 Standard qemu, no seabios/upstreamqemu. OTOH - see the screenshot here: http://img199.imagevenue.com/img.php?image=84661_win64_strange_cpus_122_233lo.jpg This "behaviour" is normal here - since Win7_64, in Win7_32 and WinXP_32 this was no the case iirc. Windows7_64 seems to have Problems "to start" the CPU (Code: 10) - but with no visible consquences besides this funny looking devicemanager... Here's the xen cfg for this guest: acpi=1 apic=1 boot="c" builder = 'hvm' cpus = [ "2", "3", "4", "5", "6", "7" ] disk = ['tap:qcow2:/home/kaeptnb/.kvm/windows7.qcow2,ioemu:hda,w' ] gfx_passthru=0 hpet=1 keymap = "de" memory = '4900' monitor=1 name = 'win' on_crash = "preserve" on_poweroff = "preserve" on_reboot = "preserve" on_xend_stop = "shutdown" pae=1 pci = [ '08:00.0' , '08:00.1' , '00:1a.7' ] pci_msitranslate=1 pci_power_mgmt = 1 sdl=0 serial = 'pty' shadow_memory=32 stdvga=1 uuid = "someuuid :)" vcpus = 6 vif = ['type=ioemu, bridge=br0, mac=anymac:), model=e1000' ] viridian=1 vnc=1 vncconsole=0 vncpasswd="" xen_platform_pci=1 Greetings Tobias Am Donnerstag, 1. September 2011, 11:45:03 schrieb Christoph Egger: > On 09/01/11 11:32, Ian Campbell wrote: > > On Thu, 2011-09-01 at 10:08 +0100, Christoph Egger wrote: > >> On 09/01/11 10:50, Ian Campbell wrote: > >>> On Thu, 2011-09-01 at 09:36 +0100, Christoph Egger wrote: > >>>> cs 23453:4f4970d2848d breaks Win 7. It fails to initialize the CPUs > >>>> as shown in the device manager and this causes a BSOD on shutdown. > >>> > >>> Are you 100% sure it's that cset? > >> > >> Yes, I am. I found that c/s by bisecting. I used the latest xen-kernel > >> and toolchain, just replaced the hvmloader binary and booted a > >> Win7 guest (both 32bit and 64bit) with one vcpu. > >> > >> An hvmloader binary built from c/s 23452 works. > >> BTW: I use the rombios. > >> > >> > It moves a few things around but it doesn't actually remove > >> > anything. > >> > >> From a first glance, bios_info_setup() is called earlier with this > >> c/s. > > > > I guess something could be clobbering that datastructure but there isn't > > much of interest in it now anyway. This stuff has subsequently been > > reorganised even more and moved around etc. I presume it is broken even > > for xen-unstable.hg 23809:85b29185c911? > > Yes, it is. > > > I'll see if I can repro. Can you post your guest cfg file please? > > builder="hvm" > memory=2048 > name="win7" > vcpus=1 > acpi=1 > apic=1 > vif = [ 'type=ioemu, model=e1000' ] > disk = [ 'file:/hvm-guest/win7.img,ioemu:hda,w' ] > sdl=0 > vnc=1 > stdvga=1 > usb=1 > usbdevice='tablet' _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel From xen-devel-bounces@lists.xensource.com Thu Sep 01 07:32:38 2011 Return-path: Envelope-to: www-data@lists.xensource.com Delivery-date: Thu, 01 Sep 2011 07:32:38 -0700 Received: from localhost ([127.0.0.1] helo=lists.colo.xensource.com) by lists.xensource.com with esmtp (Exim 4.43) id 1Qz8Jp-0006rP-RR; Thu, 01 Sep 2011 07:32:37 -0700 Received: from mail21.messagelabs.com ([85.158.143.35]) by lists.xensource.com with smtp (Exim 4.43) id 1Qz8JL-0006af-In for xen-devel@lists.xensource.com; Thu, 01 Sep 2011 07:32:08 -0700 X-Env-Sender: Ian.Jackson@eu.citrix.com X-Msg-Ref: server-12.tower-21.messagelabs.com!1314887511!48347963!1 X-Originating-IP: [62.200.22.115] X-StarScan-Version: 6.3.6; banners=-,-,- X-VirusChecked: Checked Received: (qmail 23065 invoked from network); 1 Sep 2011 14:31:51 -0000 Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115) by server-12.tower-21.messagelabs.com with SMTP; 1 Sep 2011 14:31:51 -0000 X-IronPort-AV: E=Sophos;i="4.68,313,1312156800"; d="scan'208";a="7556740" Received: from lonpmailmx01.citrite.net ([10.30.203.162]) by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5; 01 Sep 2011 14:32:04 +0000 Received: from woking.xci-test.com (10.80.248.135) by smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id 8.3.137.0; Thu, 1 Sep 2011 15:32:04 +0100 Received: from osstest by woking.xci-test.com with local (Exim 4.69) (envelope-from ) id 1Qz8JH-0001c8-Lu; Thu, 01 Sep 2011 15:32:03 +0100 To: xen-devel@lists.xensource.com Message-ID: From: xen.org Date: Thu, 1 Sep 2011 15:32:03 +0100 MIME-Version: 1.0 Content-Type: text/plain Cc: ian.jackson@eu.citrix.com Subject: [Xen-devel] [xen-4.0-testing test] 8801: tolerable FAIL - PUSHED X-BeenThere: xen-devel@lists.xensource.com X-Mailman-Version: 2.1.5 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xensource.com Errors-To: xen-devel-bounces@lists.xensource.com flight 8801 xen-4.0-testing real [real] http://www.chiark.greenend.org.uk/~xensrcts/logs/8801/ Failures :-/ but no regressions. Tests which are failing intermittently (not blocking): test-i386-i386-xl 5 xen-boot fail pass in 8788 test-amd64-i386-xl-multivcpu 9 guest-start fail pass in 8788 test-amd64-amd64-xl 5 xen-boot fail pass in 8788 test-amd64-i386-xl-credit2 10 guest-saverestore fail pass in 8777 test-i386-i386-xl-win 5 xen-boot fail pass in 8788 test-amd64-amd64-xl-sedf 5 xen-boot fail in 8788 pass in 8801 test-amd64-i386-rhel6hvm-intel 5 xen-boot fail in 8788 pass in 8801 Tests which did not succeed, but are not blocking, including regressions (tests previously passed) regarded as allowable: test-amd64-amd64-xl-pcipt-intel 8 debian-fixup fail never pass test-amd64-i386-xl 15 guest-stop fail never pass test-amd64-amd64-xl-sedf 15 guest-stop fail never pass test-amd64-i386-rhel6hvm-intel 7 redhat-install fail never pass test-amd64-i386-rhel6hvm-amd 7 redhat-install fail never pass test-amd64-i386-win-vcpus1 16 leak-check/check fail never pass test-amd64-i386-win 16 leak-check/check fail never pass test-amd64-amd64-win 16 leak-check/check fail never pass test-i386-i386-win 16 leak-check/check fail never pass test-amd64-amd64-xl-win 7 windows-install fail never pass test-amd64-i386-xl-win-vcpus1 7 windows-install fail never pass test-i386-i386-xl 15 guest-stop fail in 8788 never pass test-amd64-i386-xl-multivcpu 15 guest-stop fail in 8788 never pass test-amd64-amd64-xl 15 guest-stop fail in 8788 never pass test-amd64-i386-xl-credit2 5 xen-boot fail in 8788 like 8763 test-i386-i386-xl-win 7 windows-install fail in 8788 never pass test-amd64-i386-xl-credit2 15 guest-stop fail in 8777 never pass version targeted for testing: xen 0383662ea34c baseline version: xen 4b7b75ace863 ------------------------------------------------------------ People who touched revisions under test: Andrew Cooper ------------------------------------------------------------ jobs: build-amd64 pass build-i386 pass build-amd64-oldkern pass build-i386-oldkern pass build-amd64-pvops pass build-i386-pvops pass test-amd64-amd64-xl fail test-amd64-i386-xl fail test-i386-i386-xl fail test-amd64-i386-rhel6hvm-amd fail test-amd64-i386-xl-credit2 fail test-amd64-amd64-xl-pcipt-intel fail test-amd64-i386-rhel6hvm-intel fail test-amd64-i386-xl-multivcpu fail test-amd64-amd64-pair pass test-amd64-i386-pair pass test-i386-i386-pair pass test-amd64-amd64-pv pass test-amd64-i386-pv pass test-i386-i386-pv pass test-amd64-amd64-xl-sedf fail test-amd64-i386-win-vcpus1 fail test-amd64-i386-xl-win-vcpus1 fail test-amd64-amd64-win fail test-amd64-i386-win fail test-i386-i386-win fail test-amd64-amd64-xl-win fail test-i386-i386-xl-win fail ------------------------------------------------------------ sg-report-flight on woking.cam.xci-test.com logs: /home/xc_osstest/logs images: /home/xc_osstest/images Logs, config files, etc. are available at http://www.chiark.greenend.org.uk/~xensrcts/logs Test harness code can be found at http://xenbits.xensource.com/gitweb?p=osstest.git;a=summary Pushing revision : + branch=xen-4.0-testing + revision=0383662ea34c + . cri-lock-repos ++ . cri-common +++ umask 002 +++ getconfig Repos +++ perl -e ' use Osstest; readconfigonly(); print $c{Repos} or die $!; ' ++ repos=/export/home/osstest/repos ++ repos_lock=/export/home/osstest/repos/lock ++ '[' x '!=' x/export/home/osstest/repos/lock ']' ++ OSSTEST_REPOS_LOCK_LOCKED=/export/home/osstest/repos/lock ++ exec with-lock-ex -w /export/home/osstest/repos/lock ./ap-push xen-4.0-testing 0383662ea34c + branch=xen-4.0-testing + revision=0383662ea34c + . cri-lock-repos ++ . cri-common +++ umask 002 +++ getconfig Repos +++ perl -e ' use Osstest; readconfigonly(); print $c{Repos} or die $!; ' ++ repos=/export/home/osstest/repos ++ repos_lock=/export/home/osstest/repos/lock ++ '[' x/export/home/osstest/repos/lock '!=' x/export/home/osstest/repos/lock ']' + : xen@xenbits.xensource.com + : xen@xenbits.xensource.com:git/linux-pvops + : master + : tested/2.6.39.x + case "$branch" in + cd /export/home/osstest/repos/xen-4.0-testing.hg + hg push -r 0383662ea34c ssh://xen@xenbits.xensource.com/HG/xen-4.0-testing.hg pushing to ssh://xen@xenbits.xensource.com/HG/xen-4.0-testing.hg searching for changes remote: adding changesets remote: adding manifests remote: adding file changes remote: added 1 changesets with 8 changes to 8 files _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel From xen-devel-bounces@lists.xensource.com Thu Sep 01 08:05:58 2011 Return-path: Envelope-to: www-data@lists.xensource.com Delivery-date: Thu, 01 Sep 2011 08:05:58 -0700 Received: from localhost ([127.0.0.1] helo=lists.colo.xensource.com) by lists.xensource.com with esmtp (Exim 4.43) id 1Qz8q6-00081L-Mx; Thu, 01 Sep 2011 08:05:58 -0700 Received: from mail174.messagelabs.com ([85.158.138.51]) by lists.xensource.com with smtp (Exim 4.43) id 1Qz8pL-0007pT-6d for xen-devel@lists.xensource.com; Thu, 01 Sep 2011 08:05:11 -0700 X-Env-Sender: Ian.Campbell@eu.citrix.com X-Msg-Ref: server-2.tower-174.messagelabs.com!1314889507!29913174!1 X-Originating-IP: [62.200.22.115] X-StarScan-Version: 6.3.6; banners=-,-,- X-VirusChecked: Checked Received: (qmail 11122 invoked from network); 1 Sep 2011 15:05:08 -0000 Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115) by server-2.tower-174.messagelabs.com with SMTP; 1 Sep 2011 15:05:08 -0000 X-IronPort-AV: E=Sophos;i="4.68,313,1312156800"; d="scan'208";a="7557628" Received: from lonpmailmx01.citrite.net ([10.30.203.162]) by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5; 01 Sep 2011 15:05:06 +0000 Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net (10.30.203.162) with Microsoft SMTP Server id 8.3.137.0; Thu, 1 Sep 2011 16:05:06 +0100 Subject: Re: [Xen-devel] Re: cs 23453:4f4970d2848d beaks Win 7 From: Ian Campbell To: Christoph Egger , Keir Fraser , Ian Jackson In-Reply-To: <4E5F541F.6010405@amd.com> References: <4E5F43F2.6010601@amd.com> <1314867058.28989.84.camel@zakaz.uk.xensource.com> <4E5F4B7E.8090601@amd.com> <1314869549.28989.86.camel@zakaz.uk.xensource.com> <4E5F541F.6010405@amd.com> Content-Type: text/plain; charset="UTF-8" Organization: Citrix Systems, Inc. Date: Thu, 1 Sep 2011 16:05:05 +0100 Message-ID: <1314889505.28989.127.camel@zakaz.uk.xensource.com> MIME-Version: 1.0 X-Mailer: Evolution 2.32.3 Content-Transfer-Encoding: 7bit Cc: "xen-devel@lists.xensource.com" X-BeenThere: xen-devel@lists.xensource.com X-Mailman-Version: 2.1.5 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xensource.com Errors-To: xen-devel-bounces@lists.xensource.com The issue with 23453:4f4970d2848d is that it uses madt_csum_addr and madt_lapic0_addr to initialise bios_info before they have themselves been initialised. But in xen-unstable.hg tip everything has moved around and the issue now turns out to be that we clear the acpi_info struct _after_ we've setup the madt_* fields. Ooops! Thanks for reporting. Cheers, Ian. # HG changeset patch # User Ian Campbell # Date 1314889401 -3600 # Node ID bb97bd46df6c6d8562759a964ebf6c31b6361a7a # Parent 85b29185c9119ff9139596251d7bd13586853994 hvmloader: don't clear acpi_info after filling in some fields In particular the madt_lapic0_addr and madt_csum_addr fields are filled in while building the tables. This fixes a bluescreen on shutdown with certain versions of Windows. Signed-off-by: Ian Campbell Reported-by: Christoph Egger diff -r 85b29185c911 -r bb97bd46df6c tools/firmware/hvmloader/acpi/build.c --- a/tools/firmware/hvmloader/acpi/build.c Thu Sep 01 09:39:25 2011 +0100 +++ b/tools/firmware/hvmloader/acpi/build.c Thu Sep 01 16:03:21 2011 +0100 @@ -277,6 +277,8 @@ void acpi_build_tables(unsigned int phys unsigned long secondary_tables[16]; int nr_secondaries, i; + memset(acpi_info, 0, sizeof(*acpi_info)); + /* * Fill in high-memory data structures, starting at @buf. */ @@ -375,7 +377,6 @@ void acpi_build_tables(unsigned int phys offsetof(struct acpi_20_rsdp, extended_checksum), sizeof(struct acpi_20_rsdp)); - memset(acpi_info, 0, sizeof(*acpi_info)); acpi_info->com1_present = uart_exists(0x3f8); acpi_info->com2_present = uart_exists(0x2f8); acpi_info->lpt1_present = lpt_exists(0x378); _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel From xen-devel-bounces@lists.xensource.com Thu Sep 01 08:10:25 2011 Return-path: Envelope-to: www-data@lists.xensource.com Delivery-date: Thu, 01 Sep 2011 08:10:25 -0700 Received: from localhost ([127.0.0.1] helo=lists.colo.xensource.com) by lists.xensource.com with esmtp (Exim 4.43) id 1Qz8uP-0008Ru-Na; Thu, 01 Sep 2011 08:10:25 -0700 Received: from mail174.messagelabs.com ([85.158.138.51]) by lists.xensource.com with esmtp (Exim 4.43) id 1Qz8tv-0008FN-Mm for xen-devel@lists.xensource.com; Thu, 01 Sep 2011 08:09:56 -0700 X-Env-Sender: david.vrabel@citrix.com X-Msg-Ref: server-8.tower-174.messagelabs.com!1314889789!16230690!1 X-Originating-IP: [66.165.176.89] X-StarScan-Version: 6.3.6; banners=-,-,- X-VirusChecked: Checked Received: (qmail 29299 invoked from network); 1 Sep 2011 15:09:52 -0000 Received: from smtp.citrix.com (HELO SMTP.CITRIX.COM) (66.165.176.89) by server-8.tower-174.messagelabs.com with RC4-SHA encrypted SMTP; 1 Sep 2011 15:09:52 -0000 X-IronPort-AV: E=Sophos;i="4.68,313,1312171200"; d="scan'208";a="16628256" Received: from ftlpmailmx01.citrite.net ([10.13.107.65]) by FTLPIPO01.CITRIX.COM with ESMTP/TLS/RC4-MD5; 01 Sep 2011 11:09:48 -0400 Received: from [10.80.2.76] (10.80.2.76) by FTLPMAILMX01.citrite.net (10.13.107.65) with Microsoft SMTP Server id 8.3.137.0; Thu, 1 Sep 2011 11:09:48 -0400 Message-ID: <4E5FA0C4.7000806@citrix.com> Date: Thu, 1 Sep 2011 16:12:04 +0100 From: David Vrabel User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.1.16) Gecko/20110818 Icedove/3.0.11 MIME-Version: 1.0 To: Konrad Rzeszutek Wilk Subject: Re: [Xen-devel] Kernel bug from 3.0 (was phy disks and vifs timing out in DomU) References: <4E3266DE.9000606@overnetdata.com> <20110803152841.GA2860@dumpdata.com> <4E4E3957.1040007@overnetdata.com> <20110819125615.GA26558@dumpdata.com> <4E56B132.9050708@overnetdata.com> <20110826142606.GA25511@dumpdata.com> <20110826144438.GA24836@dumpdata.com> <4E5E6843.7050206@citrix.com> <20110831170711.GB13642@dumpdata.com> <1314862972.28989.74.camel@zakaz.uk.xensource.com> <20110901142356.GD23971@dumpdata.com> In-Reply-To: <20110901142356.GD23971@dumpdata.com> Content-Type: text/plain; charset="ISO-8859-1" Content-Transfer-Encoding: 7bit Cc: Fitzhardinge , "xen-devel@lists.xensource.com" , Jeremy, Anthony Wright , Ian Campbell , Todd Deshane X-BeenThere: xen-devel@lists.xensource.com X-Mailman-Version: 2.1.5 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xensource.com Errors-To: xen-devel-bounces@lists.xensource.com On 01/09/11 15:23, Konrad Rzeszutek Wilk wrote: > On Thu, Sep 01, 2011 at 08:42:52AM +0100, Ian Campbell wrote: >> On Wed, 2011-08-31 at 18:07 +0100, Konrad Rzeszutek Wilk wrote: >>> On Wed, Aug 31, 2011 at 05:58:43PM +0100, David Vrabel wrote: >>>> On 26/08/11 15:44, Konrad Rzeszutek Wilk wrote: >>>>> >>>>> So while I am still looking at the hypervisor code to figure out why >>>>> it would give me [when trying to map a grant page]: >>>>> >>>>> (XEN) mm.c:3846:d0 Could not find L1 PTE for address fbb42000 >>>> >>>> It is failing in guest_map_l1e() because the page for the vmalloc'd >>>> virtual address PTEs is not present. >>>> >>>> The test that fails is: >>>> >>>> (l2e_get_flags(l2e) & (_PAGE_PRESENT | _PAGE_PSE)) != _PAGE_PRESENT >>>> >>>> I think this is because the GNTTABOP_map_grant_ref hypercall is done >>>> when task->active_mm != &init_mm and alloc_vm_area() only adds PTEs into >>>> init_mm so when Xen looks in the page tables it doesn't find the entries >>>> because they're not there yet. >>>> >>>> Putting a call to vmalloc_sync_all() after create_vm_area() and before >>>> the hypercall makes it work for me. Classic Xen kernels used to have >>>> such a call. >>> >>> That sounds quite reasonable. >> >> I was wondering why upstream was missing the vmalloc_sync_all() in >> alloc_vm_area() since the out-of-tree kernels did have it and the >> function was added by us. I found this: >> http://git.kernel.org/?p=linux/kernel/git/torvalds/linux.git;a=commitdiff;h=ef691947d8a3d479e67652312783aedcf629320a >> >> commit ef691947d8a3d479e67652312783aedcf629320a >> Author: Jeremy Fitzhardinge >> Date: Wed Dec 1 15:45:48 2010 -0800 >> >> vmalloc: remove vmalloc_sync_all() from alloc_vm_area() >> >> There's no need for it: it will get faulted into the current pagetable >> as needed. >> >> Signed-off-by: Jeremy Fitzhardinge >> >> The flaw in the reasoning here is that you cannot take a kernel fault >> while processing a hypercall, so hypercall arguments must have been >> faulted in beforehand and that is what the sync_all was for. >> >> It's probably fair to say that the Xen specific caller should take care >> of that Xen-specific requirement rather than pushing it into common >> code. On the other hand Xen is the only user and creating a Xen specific >> helper/wrapper seems a bit pointless. > > Perhaps then doing the vmalloc_sync_all() (or are more precise one: > vmalloc_sync_one) should be employed in the netback code then? > > And obviously guarded by the CONFIG_HIGHMEM case? Perhaps. But I think the correct thing to do initially is revert the change and then look at possible improvements. Particularly as the fix needs to be a backported to stable. David _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel From xen-devel-bounces@lists.xensource.com Thu Sep 01 08:12:14 2011 Return-path: Envelope-to: www-data@lists.xensource.com Delivery-date: Thu, 01 Sep 2011 08:12:14 -0700 Received: from localhost ([127.0.0.1] helo=lists.colo.xensource.com) by lists.xensource.com with esmtp (Exim 4.43) id 1Qz8wA-0000Oy-LT; Thu, 01 Sep 2011 08:12:14 -0700 Received: from mail27.messagelabs.com ([193.109.254.147]) by lists.xensource.com with smtp (Exim 4.43) id 1Qz8vi-0000C9-LQ for xen-devel@lists.xensource.com; Thu, 01 Sep 2011 08:11:47 -0700 X-Env-Sender: Ian.Campbell@eu.citrix.com X-Msg-Ref: server-3.tower-27.messagelabs.com!1314889883!37911384!1 X-Originating-IP: [62.200.22.115] X-StarScan-Version: 6.3.6; banners=-,-,- X-VirusChecked: Checked Received: (qmail 1229 invoked from network); 1 Sep 2011 15:11:23 -0000 Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115) by server-3.tower-27.messagelabs.com with SMTP; 1 Sep 2011 15:11:23 -0000 X-IronPort-AV: E=Sophos;i="4.68,313,1312156800"; d="scan'208";a="7557806" Received: from lonpmailmx01.citrite.net ([10.30.203.162]) by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5; 01 Sep 2011 15:11:37 +0000 Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net (10.30.203.162) with Microsoft SMTP Server id 8.3.137.0; Thu, 1 Sep 2011 16:11:37 +0100 Subject: Re: [Xen-devel] Re: cs 23453:4f4970d2848d beaks Win 7 From: Ian Campbell To: Tobias Geiger In-Reply-To: <201109011628.09908.tobias.geiger@vido.info> References: <4E5F43F2.6010601@amd.com> <1314869549.28989.86.camel@zakaz.uk.xensource.com> <4E5F541F.6010405@amd.com> <201109011628.09908.tobias.geiger@vido.info> Content-Type: text/plain; charset="UTF-8" Organization: Citrix Systems, Inc. Date: Thu, 1 Sep 2011 16:11:36 +0100 Message-ID: <1314889896.28989.129.camel@zakaz.uk.xensource.com> MIME-Version: 1.0 X-Mailer: Evolution 2.32.3 Content-Transfer-Encoding: 7bit Cc: Egger , "xen-devel@lists.xensource.com" , Christoph X-BeenThere: xen-devel@lists.xensource.com X-Mailman-Version: 2.1.5 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xensource.com Errors-To: xen-devel-bounces@lists.xensource.com On Thu, 2011-09-01 at 15:28 +0100, Tobias Geiger wrote: > OTOH - see the screenshot here: > http://img199.imagevenue.com/img.php?image=84661_win64_strange_cpus_122_233lo.jpg > > This "behaviour" is normal here - since Win7_64, in Win7_32 and WinXP_32 this > was no the case iirc. Does the patch I posted for Christoph's issue help? If not then please can you try and identify what the last working changeset is for you e.g. by bisecting. You should only need to rebuild/reinstall the tools/firmware directory on each iteration. Thanks, Ian. _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel From xen-devel-bounces@lists.xensource.com Thu Sep 01 08:13:18 2011 Return-path: Envelope-to: www-data@lists.xensource.com Delivery-date: Thu, 01 Sep 2011 08:13:18 -0700 Received: from localhost ([127.0.0.1] helo=lists.colo.xensource.com) by lists.xensource.com with esmtp (Exim 4.43) id 1Qz8xC-0000mQ-OR; Thu, 01 Sep 2011 08:13:18 -0700 Received: from mail182.messagelabs.com ([85.158.139.83]) by lists.xensource.com with smtp (Exim 4.43) id 1Qz8wX-0000Xz-Hf for xen-devel@lists.xensource.com; Thu, 01 Sep 2011 08:12:37 -0700 X-Env-Sender: Ian.Campbell@eu.citrix.com X-Msg-Ref: server-4.tower-182.messagelabs.com!1314889954!16705850!1 X-Originating-IP: [62.200.22.115] X-StarScan-Version: 6.3.6; banners=-,-,- X-VirusChecked: Checked Received: (qmail 11153 invoked from network); 1 Sep 2011 15:12:34 -0000 Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115) by server-4.tower-182.messagelabs.com with SMTP; 1 Sep 2011 15:12:34 -0000 X-IronPort-AV: E=Sophos;i="4.68,313,1312156800"; d="scan'208";a="7557836" Received: from lonpmailmx01.citrite.net ([10.30.203.162]) by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5; 01 Sep 2011 15:12:34 +0000 Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net (10.30.203.162) with Microsoft SMTP Server id 8.3.137.0; Thu, 1 Sep 2011 16:12:34 +0100 Subject: Re: [Xen-devel] Kernel bug from 3.0 (was phy disks and vifs timing out in DomU) From: Ian Campbell To: Konrad Rzeszutek Wilk In-Reply-To: <20110901142356.GD23971@dumpdata.com> References: <4E3266DE.9000606@overnetdata.com> <20110803152841.GA2860@dumpdata.com> <4E4E3957.1040007@overnetdata.com> <20110819125615.GA26558@dumpdata.com> <4E56B132.9050708@overnetdata.com> <20110826142606.GA25511@dumpdata.com> <20110826144438.GA24836@dumpdata.com> <4E5E6843.7050206@citrix.com> <20110831170711.GB13642@dumpdata.com> <1314862972.28989.74.camel@zakaz.uk.xensource.com> <20110901142356.GD23971@dumpdata.com> Content-Type: text/plain; charset="UTF-8" Organization: Citrix Systems, Inc. Date: Thu, 1 Sep 2011 16:12:33 +0100 Message-ID: <1314889953.28989.130.camel@zakaz.uk.xensource.com> MIME-Version: 1.0 X-Mailer: Evolution 2.32.3 Content-Transfer-Encoding: 7bit Cc: Todd Deshane , "xen-devel@lists.xensource.com" , Jeremy Fitzhardinge , David Vrabel , Anthony Wright X-BeenThere: xen-devel@lists.xensource.com X-Mailman-Version: 2.1.5 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xensource.com Errors-To: xen-devel-bounces@lists.xensource.com On Thu, 2011-09-01 at 15:23 +0100, Konrad Rzeszutek Wilk wrote: > On Thu, Sep 01, 2011 at 08:42:52AM +0100, Ian Campbell wrote: > > On Wed, 2011-08-31 at 18:07 +0100, Konrad Rzeszutek Wilk wrote: > > > On Wed, Aug 31, 2011 at 05:58:43PM +0100, David Vrabel wrote: > > > > On 26/08/11 15:44, Konrad Rzeszutek Wilk wrote: > > > > > > > > > > So while I am still looking at the hypervisor code to figure out why > > > > > it would give me [when trying to map a grant page]: > > > > > > > > > > (XEN) mm.c:3846:d0 Could not find L1 PTE for address fbb42000 > > > > > > > > It is failing in guest_map_l1e() because the page for the vmalloc'd > > > > virtual address PTEs is not present. > > > > > > > > The test that fails is: > > > > > > > > (l2e_get_flags(l2e) & (_PAGE_PRESENT | _PAGE_PSE)) != _PAGE_PRESENT > > > > > > > > I think this is because the GNTTABOP_map_grant_ref hypercall is done > > > > when task->active_mm != &init_mm and alloc_vm_area() only adds PTEs into > > > > init_mm so when Xen looks in the page tables it doesn't find the entries > > > > because they're not there yet. > > > > > > > > Putting a call to vmalloc_sync_all() after create_vm_area() and before > > > > the hypercall makes it work for me. Classic Xen kernels used to have > > > > such a call. > > > > > > That sounds quite reasonable. > > > > I was wondering why upstream was missing the vmalloc_sync_all() in > > alloc_vm_area() since the out-of-tree kernels did have it and the > > function was added by us. I found this: > > http://git.kernel.org/?p=linux/kernel/git/torvalds/linux.git;a=commitdiff;h=ef691947d8a3d479e67652312783aedcf629320a > > > > commit ef691947d8a3d479e67652312783aedcf629320a > > Author: Jeremy Fitzhardinge > > Date: Wed Dec 1 15:45:48 2010 -0800 > > > > vmalloc: remove vmalloc_sync_all() from alloc_vm_area() > > > > There's no need for it: it will get faulted into the current pagetable > > as needed. > > > > Signed-off-by: Jeremy Fitzhardinge > > > > The flaw in the reasoning here is that you cannot take a kernel fault > > while processing a hypercall, so hypercall arguments must have been > > faulted in beforehand and that is what the sync_all was for. > > > > It's probably fair to say that the Xen specific caller should take care > > of that Xen-specific requirement rather than pushing it into common > > code. On the other hand Xen is the only user and creating a Xen specific > > helper/wrapper seems a bit pointless. > > Perhaps then doing the vmalloc_sync_all() (or are more precise one: > vmalloc_sync_one) should be employed in the netback code then? Not just netback but everywhere which uses this interface. > And obviously guarded by the CONFIG_HIGHMEM case? I don't think this has anything to do with highmem, does it? It is potentially just as much of a problem on 64 bit for example. Ian. _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel From xen-devel-bounces@lists.xensource.com Thu Sep 01 08:26:22 2011 Return-path: Envelope-to: www-data@lists.xensource.com Delivery-date: Thu, 01 Sep 2011 08:26:22 -0700 Received: from localhost ([127.0.0.1] helo=lists.colo.xensource.com) by lists.xensource.com with esmtp (Exim 4.43) id 1Qz99q-0001K8-7i; Thu, 01 Sep 2011 08:26:22 -0700 Received: from mail21.messagelabs.com ([85.158.143.35]) by lists.xensource.com with esmtp (Exim 4.43) id 1Qz99O-00017v-B5 for xen-devel@lists.xensource.com; Thu, 01 Sep 2011 08:25:54 -0700 X-Env-Sender: konrad@dumpdata.com X-Msg-Ref: server-11.tower-21.messagelabs.com!1314890734!40995584!1 X-Originating-IP: [148.87.113.117] X-StarScan-Version: 6.3.6; banners=-,-,- X-VirusChecked: Checked Received: (qmail 597 invoked from network); 1 Sep 2011 15:25:36 -0000 Received: from rcsinet15.oracle.com (HELO rcsinet15.oracle.com) (148.87.113.117) by server-11.tower-21.messagelabs.com with DHE-RSA-AES256-SHA encrypted SMTP; 1 Sep 2011 15:25:36 -0000 Received: from rtcsinet21.oracle.com (rtcsinet21.oracle.com [66.248.204.29]) by rcsinet15.oracle.com (Switch-3.4.4/Switch-3.4.4) with ESMTP id p81FPjZJ021479 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Thu, 1 Sep 2011 15:25:47 GMT Received: from acsmt358.oracle.com (acsmt358.oracle.com [141.146.40.158]) by rtcsinet21.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id p81FPhjG025857 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 1 Sep 2011 15:25:44 GMT Received: from abhmt108.oracle.com (abhmt108.oracle.com [141.146.116.60]) by acsmt358.oracle.com (8.12.11.20060308/8.12.11) with ESMTP id p81FPcY3014722; Thu, 1 Sep 2011 10:25:38 -0500 Received: from phenom (/209.6.55.207) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Thu, 01 Sep 2011 08:25:37 -0700 Received: by phenom (Postfix, from userid 1000) id 132C3FD1; Thu, 1 Sep 2011 11:25:35 -0400 (EDT) Date: Thu, 1 Sep 2011 11:25:35 -0400 From: Konrad Rzeszutek Wilk To: Li Dongyang Message-ID: <20110901152534.GA6965@dumpdata.com> References: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.21 (2010-09-15) X-Source-IP: rtcsinet21.oracle.com [66.248.204.29] X-CT-RefId: str=0001.0A090201.4E5FA3FB.01AB,ss=1,re=3.899,fgs=0 Cc: xen-devel@lists.xensource.com, owen.smith@citrix.com, JBeulich@novell.com Subject: [Xen-devel] Re: [PATCH V4 2/3] xen-blkfront: teach blkfront driver to handle discard requests X-BeenThere: xen-devel@lists.xensource.com X-Mailman-Version: 2.1.5 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xensource.com Errors-To: xen-devel-bounces@lists.xensource.com On Thu, Sep 01, 2011 at 06:39:09PM +0800, Li Dongyang wrote: > The blkfront driver now will read discard related nodes from xenstore, > and set up the request queue, then we can forward the > discard requests to backend driver. A better description is as follow: xen-blkfront: Handle discard requests. If the backend advertises 'feature-discard', then interrogate the backend for alignment, granularity, and max discard block size. Setup the request queue with the appropiate values and send the discard operation as required. > > Signed-off-by: Li Dongyang > --- > drivers/block/xen-blkfront.c | 111 +++++++++++++++++++++++++++++++++--------- > 1 files changed, 88 insertions(+), 23 deletions(-) > > diff --git a/drivers/block/xen-blkfront.c b/drivers/block/xen-blkfront.c > index 9ea8c25..86e2c63 100644 > --- a/drivers/block/xen-blkfront.c > +++ b/drivers/block/xen-blkfront.c > @@ -98,6 +98,9 @@ struct blkfront_info > unsigned long shadow_free; > unsigned int feature_flush; > unsigned int flush_op; > + unsigned int feature_discard; > + unsigned int discard_granularity; > + unsigned int discard_alignment; > int is_ready; > }; > > @@ -302,29 +305,36 @@ static int blkif_queue_request(struct request *req) > ring_req->operation = info->flush_op; > } > > - ring_req->nr_segments = blk_rq_map_sg(req->q, req, info->sg); > - BUG_ON(ring_req->nr_segments > BLKIF_MAX_SEGMENTS_PER_REQUEST); > + if (unlikely(req->cmd_flags & REQ_DISCARD)) { > + /* id, sector_number and handle are set above. */ > + ring_req->operation = BLKIF_OP_DISCARD; > + ring_req->nr_segments = 0; > + ring_req->u.discard.nr_sectors = blk_rq_sectors(req); > + } else { > + ring_req->nr_segments = blk_rq_map_sg(req->q, req, info->sg); > + BUG_ON(ring_req->nr_segments > BLKIF_MAX_SEGMENTS_PER_REQUEST); > > - for_each_sg(info->sg, sg, ring_req->nr_segments, i) { > - buffer_mfn = pfn_to_mfn(page_to_pfn(sg_page(sg))); > - fsect = sg->offset >> 9; > - lsect = fsect + (sg->length >> 9) - 1; > - /* install a grant reference. */ > - ref = gnttab_claim_grant_reference(&gref_head); > - BUG_ON(ref == -ENOSPC); > + for_each_sg(info->sg, sg, ring_req->nr_segments, i) { > + buffer_mfn = pfn_to_mfn(page_to_pfn(sg_page(sg))); > + fsect = sg->offset >> 9; > + lsect = fsect + (sg->length >> 9) - 1; > + /* install a grant reference. */ > + ref = gnttab_claim_grant_reference(&gref_head); > + BUG_ON(ref == -ENOSPC); > > - gnttab_grant_foreign_access_ref( > - ref, > - info->xbdev->otherend_id, > - buffer_mfn, > - rq_data_dir(req) ); > - > - info->shadow[id].frame[i] = mfn_to_pfn(buffer_mfn); > - ring_req->u.rw.seg[i] = > - (struct blkif_request_segment) { > - .gref = ref, > - .first_sect = fsect, > - .last_sect = lsect }; > + gnttab_grant_foreign_access_ref( > + ref, > + info->xbdev->otherend_id, > + buffer_mfn, > + rq_data_dir(req)); > + > + info->shadow[id].frame[i] = mfn_to_pfn(buffer_mfn); > + ring_req->u.rw.seg[i] = > + (struct blkif_request_segment) { > + .gref = ref, > + .first_sect = fsect, > + .last_sect = lsect }; > + } > } > > info->ring.req_prod_pvt++; > @@ -399,6 +409,7 @@ wait: > static int xlvbd_init_blk_queue(struct gendisk *gd, u16 sector_size) > { > struct request_queue *rq; > + struct blkfront_info *info = gd->private_data; > > rq = blk_init_queue(do_blkif_request, &blkif_io_lock); > if (rq == NULL) > @@ -406,6 +417,13 @@ static int xlvbd_init_blk_queue(struct gendisk *gd, u16 sector_size) > > queue_flag_set_unlocked(QUEUE_FLAG_VIRT, rq); > > + if (info->feature_discard) { > + queue_flag_set_unlocked(QUEUE_FLAG_DISCARD, rq); > + blk_queue_max_discard_sectors(rq, get_capacity(gd)); This is not correct. I took a look at the SCSI support for this ('sd_config_discard') and if you look there carefully you will see that the value can be 64KB for example. You need to provide a mechanism similar to 'discard-*' to fetch that data from the backend. > + rq->limits.discard_granularity = info->discard_granularity; > + rq->limits.discard_alignment = info->discard_alignment; > + } > + > /* Hard sector size and max sectors impersonate the equiv. hardware. */ > blk_queue_logical_block_size(rq, sector_size); > blk_queue_max_hw_sectors(rq, 512); > @@ -722,6 +740,19 @@ static irqreturn_t blkif_interrupt(int irq, void *dev_id) > > error = (bret->status == BLKIF_RSP_OKAY) ? 0 : -EIO; > switch (bret->operation) { > + case BLKIF_OP_DISCARD: > + if (unlikely(bret->status == BLKIF_RSP_EOPNOTSUPP)) { > + struct request_queue *rq = info->rq; > + printk(KERN_WARNING "blkfront: %s: discard op failed\n", > + info->gd->disk_name); > + error = -EOPNOTSUPP; > + info->feature_discard = 0; > + spin_lock(rq->queue_lock); > + queue_flag_clear(QUEUE_FLAG_DISCARD, rq); > + spin_unlock(rq->queue_lock); > + } > + __blk_end_request_all(req, error); > + break; > case BLKIF_OP_FLUSH_DISKCACHE: > case BLKIF_OP_WRITE_BARRIER: > if (unlikely(bret->status == BLKIF_RSP_EOPNOTSUPP)) { > @@ -1098,6 +1129,33 @@ blkfront_closing(struct blkfront_info *info) > bdput(bdev); > } > > +static void blkfront_setup_discard(struct blkfront_info *info) > +{ > + int err; > + char *type; > + unsigned int discard_granularity; > + unsigned int discard_alignment; > + > + type = xenbus_read(XBT_NIL, info->xbdev->otherend, "type", NULL); > + if (IS_ERR(type)) > + return; > + > + if (strncmp(type, "phy", 3) == 0) { > + err = xenbus_gather(XBT_NIL, info->xbdev->otherend, > + "discard-granularity", "%u", &discard_granularity, > + "discard-alignment", "%u", &discard_alignment, > + NULL); > + if (!err) { > + info->feature_discard = 1; > + info->discard_granularity = discard_granularity; > + info->discard_alignment = discard_alignment; > + } > + } else if (strncmp(type, "file", 4) == 0) > + info->feature_discard = 1; > + > + kfree(type); > +} > + > /* > * Invoked when the backend is finally 'ready' (and has told produced > * the details about the physical device - #sectors, size, etc). > @@ -1108,7 +1166,7 @@ static void blkfront_connect(struct blkfront_info *info) > unsigned long sector_size; > unsigned int binfo; > int err; > - int barrier, flush; > + int barrier, flush, discard; > > switch (info->connected) { > case BLKIF_STATE_CONNECTED: > @@ -1178,7 +1236,14 @@ static void blkfront_connect(struct blkfront_info *info) > info->feature_flush = REQ_FLUSH; > info->flush_op = BLKIF_OP_FLUSH_DISKCACHE; > } > - > + > + err = xenbus_gather(XBT_NIL, info->xbdev->otherend, > + "feature-discard", "%d", &discard, > + NULL); > + > + if (!err && discard) > + blkfront_setup_discard(info); > + > err = xlvbd_alloc_gendisk(sectors, info, binfo, sector_size); > if (err) { > xenbus_dev_fatal(info->xbdev, err, "xlvbd_add at %s", > -- > 1.7.6 _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel From xen-devel-bounces@lists.xensource.com Thu Sep 01 08:29:53 2011 Return-path: Envelope-to: www-data@lists.xensource.com Delivery-date: Thu, 01 Sep 2011 08:29:53 -0700 Received: from localhost ([127.0.0.1] helo=lists.colo.xensource.com) by lists.xensource.com with esmtp (Exim 4.43) id 1Qz9DF-0001jG-0h; Thu, 01 Sep 2011 08:29:53 -0700 Received: from mail216.messagelabs.com ([85.158.143.99]) by lists.xensource.com with esmtp (Exim 4.43) id 1Qz9Ck-0001XV-6u for xen-devel@lists.xensource.com; Thu, 01 Sep 2011 08:29:22 -0700 X-Env-Sender: konrad@dumpdata.com X-Msg-Ref: server-3.tower-216.messagelabs.com!1314890957!15704188!1 X-Originating-IP: [141.146.126.227] X-StarScan-Version: 6.3.6; banners=-,-,- X-VirusChecked: Checked Received: (qmail 14680 invoked from network); 1 Sep 2011 15:29:19 -0000 Received: from acsinet15.oracle.com (HELO acsinet15.oracle.com) (141.146.126.227) by server-3.tower-216.messagelabs.com with DHE-RSA-AES256-SHA encrypted SMTP; 1 Sep 2011 15:29:19 -0000 Received: from rtcsinet21.oracle.com (rtcsinet21.oracle.com [66.248.204.29]) by acsinet15.oracle.com (Switch-3.4.4/Switch-3.4.4) with ESMTP id p81FSaI1006378 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Thu, 1 Sep 2011 15:28:38 GMT Received: from acsmt356.oracle.com (acsmt356.oracle.com [141.146.40.156]) by rtcsinet21.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id p81FSYhN000599 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 1 Sep 2011 15:28:35 GMT Received: from abhmt115.oracle.com (abhmt115.oracle.com [141.146.116.67]) by acsmt356.oracle.com (8.12.11.20060308/8.12.11) with ESMTP id p81FSTGE011766; Thu, 1 Sep 2011 10:28:29 -0500 Received: from phenom (/209.6.55.207) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Thu, 01 Sep 2011 08:28:29 -0700 Received: by phenom (Postfix, from userid 1000) id 7C39BFD1; Thu, 1 Sep 2011 11:28:26 -0400 (EDT) Date: Thu, 1 Sep 2011 11:28:26 -0400 From: Konrad Rzeszutek Wilk To: Li Dongyang Message-ID: <20110901152826.GB6965@dumpdata.com> References: <7f85bb71f76deed2537438928fa8b6dafb6a51f8.1314872306.git.lidongyang@novell.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <7f85bb71f76deed2537438928fa8b6dafb6a51f8.1314872306.git.lidongyang@novell.com> User-Agent: Mutt/1.5.21 (2010-09-15) X-Source-IP: rtcsinet21.oracle.com [66.248.204.29] X-CT-RefId: str=0001.0A090207.4E5FA4C0.0155,ss=1,re=0.000,fgs=0 Cc: xen-devel@lists.xensource.com, owen.smith@citrix.com, JBeulich@novell.com Subject: [Xen-devel] Re: [PATCH V4 3/3] xen-blkback: discard requests handling in blkback driver X-BeenThere: xen-devel@lists.xensource.com X-Mailman-Version: 2.1.5 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xensource.com Errors-To: xen-devel-bounces@lists.xensource.com On Thu, Sep 01, 2011 at 06:39:10PM +0800, Li Dongyang wrote: > Now blkback driver can handle the discard request from guest, we will > forward the request to phy device if it really has discard support, or we'll > punch a hole on the image file. The description should read: xen-blkback: Implement discard requests handling If the backend device (or loopback file) supports discard requests then advertise it to the frontend via 'feature-discard'. Implementation wise - if the backend is 'phy' - use blkdev_issue_discard, while if it is 'file', then punch a hole in the image file. Signed-off-by: Li Dongyang .. snip.. > + if (err == -EOPNOTSUPP) { > + pr_debug(DRV_PFX "blkback: discard op failed, " ^^^^^^^ - get rid of that. The DRV_PFX already provides the 'xen-blkback' string. _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel From xen-devel-bounces@lists.xensource.com Thu Sep 01 08:36:25 2011 Return-path: Envelope-to: www-data@lists.xensource.com Delivery-date: Thu, 01 Sep 2011 08:36:25 -0700 Received: from localhost ([127.0.0.1] helo=lists.colo.xensource.com) by lists.xensource.com with esmtp (Exim 4.43) id 1Qz9JZ-0002Hm-JL; Thu, 01 Sep 2011 08:36:25 -0700 Received: from mail27.messagelabs.com ([193.109.254.147]) by lists.xensource.com with esmtp (Exim 4.43) id 1Qz9J2-00025S-Pc for xen-devel@lists.xensource.com; Thu, 01 Sep 2011 08:35:53 -0700 X-Env-Sender: George.Dunlap@eu.citrix.com X-Msg-Ref: server-10.tower-27.messagelabs.com!1314891331!34002170!1 X-Originating-IP: [66.165.176.63] X-StarScan-Version: 6.3.6; banners=-,-,- X-VirusChecked: Checked Received: (qmail 3623 invoked from network); 1 Sep 2011 15:35:32 -0000 Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63) by server-10.tower-27.messagelabs.com with RC4-SHA encrypted SMTP; 1 Sep 2011 15:35:32 -0000 X-IronPort-AV: E=Sophos;i="4.68,313,1312171200"; d="scan'208";a="161445848" Received: from ftlpmailmx02.citrite.net ([10.13.107.66]) by FTLPIPO02.CITRIX.COM with ESMTP/TLS/RC4-MD5; 01 Sep 2011 11:35:47 -0400 Received: from smtp01.ad.xensource.com (10.219.128.104) by smtprelay.citrix.com (10.13.107.66) with Microsoft SMTP Server id 8.3.137.0; Thu, 1 Sep 2011 11:35:47 -0400 Received: from [127.0.1.1] (elijah.uk.xensource.com [10.80.2.24]) by smtp01.ad.xensource.com (8.13.1/8.13.1) with ESMTP id p81FZj8g029024; Thu, 1 Sep 2011 08:35:46 -0700 Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Mercurial-Node: 782284c5b1bccc4f1acf8d4abd3bc9d28a90b24d Message-ID: <782284c5b1bccc4f1acf.1314891026@elijah> User-Agent: Mercurial-patchbomb/1.4.3 Date: Thu, 1 Sep 2011 16:30:26 +0100 From: George Dunlap To: xen-devel@lists.xensource.com Cc: george.dunlap@eu.citrix.com Subject: [Xen-devel] [PATCH] xen,credit1: Add variable timeslice X-BeenThere: xen-devel@lists.xensource.com X-Mailman-Version: 2.1.5 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xensource.com Errors-To: xen-devel-bounces@lists.xensource.com Add a xen command-line parameter, sched_credit_tslice_ms, to set the timeslice of the credit1 scheduler. Signed-off-by: George Dunlap diff -r 4a4882df5649 -r 782284c5b1bc xen/common/sched_credit.c --- a/xen/common/sched_credit.c Wed Aug 31 15:23:49 2011 +0100 +++ b/xen/common/sched_credit.c Thu Sep 01 16:29:50 2011 +0100 @@ -41,15 +41,9 @@ */ #define CSCHED_DEFAULT_WEIGHT 256 #define CSCHED_TICKS_PER_TSLICE 3 -#define CSCHED_TICKS_PER_ACCT 3 -#define CSCHED_MSECS_PER_TICK 10 -#define CSCHED_MSECS_PER_TSLICE \ - (CSCHED_MSECS_PER_TICK * CSCHED_TICKS_PER_TSLICE) +/* Default timeslice: 30ms */ +#define CSCHED_DEFAULT_TSLICE_MS 30 #define CSCHED_CREDITS_PER_MSEC 10 -#define CSCHED_CREDITS_PER_TSLICE \ - (CSCHED_CREDITS_PER_MSEC * CSCHED_MSECS_PER_TSLICE) -#define CSCHED_CREDITS_PER_ACCT \ - (CSCHED_CREDITS_PER_MSEC * CSCHED_MSECS_PER_TICK * CSCHED_TICKS_PER_ACCT) /* @@ -113,6 +107,8 @@ */ static bool_t __read_mostly sched_credit_default_yield; boolean_param("sched_credit_default_yield", sched_credit_default_yield); +static int __read_mostly sched_credit_tslice_ms = CSCHED_DEFAULT_TSLICE_MS; +integer_param("sched_credit_tslice_ms", sched_credit_tslice_ms); /* * Physical CPU @@ -176,6 +172,9 @@ struct csched_private { uint32_t credit; int credit_balance; uint32_t runq_sort; + /* Period of master and tick in milliseconds */ + unsigned tslice_ms, tick_period_us, ticks_per_tslice; + unsigned credits_per_tslice; }; static void csched_tick(void *_cpu); @@ -326,7 +325,7 @@ csched_free_pdata(const struct scheduler spin_lock_irqsave(&prv->lock, flags); - prv->credit -= CSCHED_CREDITS_PER_ACCT; + prv->credit -= prv->credits_per_tslice; prv->ncpus--; cpu_clear(cpu, prv->idlers); cpu_clear(cpu, prv->cpus); @@ -360,19 +359,19 @@ csched_alloc_pdata(const struct schedule spin_lock_irqsave(&prv->lock, flags); /* Initialize/update system-wide config */ - prv->credit += CSCHED_CREDITS_PER_ACCT; + prv->credit += prv->credits_per_tslice; prv->ncpus++; cpu_set(cpu, prv->cpus); if ( prv->ncpus == 1 ) { prv->master = cpu; init_timer(&prv->master_ticker, csched_acct, prv, cpu); - set_timer(&prv->master_ticker, NOW() + - MILLISECS(CSCHED_MSECS_PER_TICK) * CSCHED_TICKS_PER_ACCT); + set_timer(&prv->master_ticker, + NOW() + MILLISECS(prv->tslice_ms)); } init_timer(&spc->ticker, csched_tick, (void *)(unsigned long)cpu, cpu); - set_timer(&spc->ticker, NOW() + MILLISECS(CSCHED_MSECS_PER_TICK)); + set_timer(&spc->ticker, NOW() + MICROSECS(prv->tick_period_us) ); INIT_LIST_HEAD(&spc->runq); spc->runq_sort_last = prv->runq_sort; @@ -1002,7 +1001,7 @@ csched_acct(void* dummy) * for one full accounting period. We allow a domain to earn more * only when the system-wide credit balance is negative. */ - credit_peak = sdom->active_vcpu_count * CSCHED_CREDITS_PER_ACCT; + credit_peak = sdom->active_vcpu_count * prv->credits_per_tslice; if ( prv->credit_balance < 0 ) { credit_peak += ( ( -prv->credit_balance @@ -1014,7 +1013,7 @@ csched_acct(void* dummy) if ( sdom->cap != 0U ) { - credit_cap = ((sdom->cap * CSCHED_CREDITS_PER_ACCT) + 99) / 100; + credit_cap = ((sdom->cap * prv->credits_per_tslice) + 99) / 100; if ( credit_cap < credit_peak ) credit_peak = credit_cap; @@ -1092,10 +1091,10 @@ csched_acct(void* dummy) } /* Lower bound on credits */ - if ( credit < -CSCHED_CREDITS_PER_TSLICE ) + if ( credit < -prv->credits_per_tslice ) { CSCHED_STAT_CRANK(acct_min_credit); - credit = -CSCHED_CREDITS_PER_TSLICE; + credit = -prv->credits_per_tslice; atomic_set(&svc->credit, credit); } } @@ -1117,7 +1116,7 @@ csched_acct(void* dummy) } /* Upper bound on credits means VCPU stops earning */ - if ( credit > CSCHED_CREDITS_PER_TSLICE ) + if ( credit > prv->credits_per_tslice ) { __csched_vcpu_acct_stop_locked(prv, svc); /* Divide credits in half, so that when it starts @@ -1141,8 +1140,8 @@ csched_acct(void* dummy) prv->runq_sort++; out: - set_timer( &prv->master_ticker, NOW() + - MILLISECS(CSCHED_MSECS_PER_TICK) * CSCHED_TICKS_PER_ACCT ); + set_timer( &prv->master_ticker, + NOW() + MILLISECS(prv->tslice_ms)); } static void @@ -1169,7 +1168,7 @@ csched_tick(void *_cpu) */ csched_runq_sort(prv, cpu); - set_timer(&spc->ticker, NOW() + MILLISECS(CSCHED_MSECS_PER_TICK)); + set_timer(&spc->ticker, NOW() + MICROSECS(prv->tick_period_us) ); } static struct csched_vcpu * @@ -1375,7 +1374,7 @@ csched_schedule( * Return task to run next... */ ret.time = (is_idle_vcpu(snext->vcpu) ? - -1 : MILLISECS(CSCHED_MSECS_PER_TSLICE)); + -1 : MILLISECS(prv->tslice_ms)); ret.task = snext->vcpu; CSCHED_VCPU_CHECK(ret.task); @@ -1469,10 +1468,9 @@ csched_dump(const struct scheduler *ops) "\tweight = %u\n" "\trunq_sort = %u\n" "\tdefault-weight = %d\n" - "\tmsecs per tick = %dms\n" + "\ttslice = %dms\n" "\tcredits per msec = %d\n" "\tticks per tslice = %d\n" - "\tticks per acct = %d\n" "\tmigration delay = %uus\n", prv->ncpus, prv->master, @@ -1481,10 +1479,9 @@ csched_dump(const struct scheduler *ops) prv->weight, prv->runq_sort, CSCHED_DEFAULT_WEIGHT, - CSCHED_MSECS_PER_TICK, + prv->tslice_ms, CSCHED_CREDITS_PER_MSEC, - CSCHED_TICKS_PER_TSLICE, - CSCHED_TICKS_PER_ACCT, + prv->ticks_per_tslice, vcpu_migration_delay); cpumask_scnprintf(idlers_buf, sizeof(idlers_buf), prv->idlers); @@ -1526,6 +1523,13 @@ csched_init(struct scheduler *ops) INIT_LIST_HEAD(&prv->active_sdom); prv->master = UINT_MAX; + prv->tslice_ms = sched_credit_tslice_ms; + prv->ticks_per_tslice = CSCHED_TICKS_PER_TSLICE; + if ( prv->tslice_ms < prv->ticks_per_tslice ) + prv->ticks_per_tslice = 1; + prv->tick_period_us = prv->tslice_ms * 1000 / prv->ticks_per_tslice; + prv->credits_per_tslice = CSCHED_CREDITS_PER_MSEC * prv->tslice_ms; + return 0; } @@ -1550,13 +1554,16 @@ static void csched_tick_suspend(const st static void csched_tick_resume(const struct scheduler *ops, unsigned int cpu) { + struct csched_private *prv; struct csched_pcpu *spc; uint64_t now = NOW(); spc = CSCHED_PCPU(cpu); - set_timer(&spc->ticker, now + MILLISECS(CSCHED_MSECS_PER_TICK) - - now % MILLISECS(CSCHED_MSECS_PER_TICK) ); + prv = CSCHED_PRIV(ops); + + set_timer(&spc->ticker, now + MICROSECS(prv->tick_period_us) + - now % MICROSECS(prv->tick_period_us) ); } static struct csched_private _csched_priv; _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel From xen-devel-bounces@lists.xensource.com Thu Sep 01 08:37:30 2011 Return-path: Envelope-to: www-data@lists.xensource.com Delivery-date: Thu, 01 Sep 2011 08:37:30 -0700 Received: from localhost ([127.0.0.1] helo=lists.colo.xensource.com) by lists.xensource.com with esmtp (Exim 4.43) id 1Qz9Kc-0002fQ-3t; Thu, 01 Sep 2011 08:37:30 -0700 Received: from mail21.messagelabs.com ([85.158.143.35]) by lists.xensource.com with smtp (Exim 4.43) id 1Qz9J6-00025b-LV for xen-devel@lists.xensource.com; Thu, 01 Sep 2011 08:35:57 -0700 X-Env-Sender: Ian.Jackson@eu.citrix.com X-Msg-Ref: server-14.tower-21.messagelabs.com!1314891346!57996135!1 X-Originating-IP: [62.200.22.115] X-StarScan-Version: 6.3.6; banners=-,-,- X-VirusChecked: Checked Received: (qmail 12569 invoked from network); 1 Sep 2011 15:35:46 -0000 Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115) by server-14.tower-21.messagelabs.com with SMTP; 1 Sep 2011 15:35:46 -0000 X-IronPort-AV: E=Sophos;i="4.68,313,1312156800"; d="scan'208";a="7558354" Received: from lonpmailmx01.citrite.net ([10.30.203.162]) by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5; 01 Sep 2011 15:35:52 +0000 Received: from norwich.cam.xci-test.com (10.80.248.129) by smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id 8.3.137.0; Thu, 1 Sep 2011 16:35:52 +0100 Received: from mariner.cam.xci-test.com ([10.80.2.22] helo=mariner.uk.xensource.com ident=Debian-exim) by norwich.cam.xci-test.com with esmtp (Exim 4.72) (envelope-from ) id 1Qz9J1-0006Mw-UD; Thu, 01 Sep 2011 15:35:51 +0000 Received: from iwj by mariner.uk.xensource.com with local (Exim 4.69) (envelope-from ) id 1Qz9J1-0007Ox-SO; Thu, 01 Sep 2011 16:35:51 +0100 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Message-ID: <20063.42583.600301.913545@mariner.uk.xensource.com> Date: Thu, 1 Sep 2011 16:35:51 +0100 To: Jeremy Fitzhardinge Subject: Re: [Xen-devel] udev oops, and system boot failure, with 2.6.32.44 as PV guest Newsgroups: chiark.mail.xen.devel In-Reply-To: <4E4D81C8.7000900@goop.org> References: <20044.62811.430835.316774@mariner.uk.xensource.com> <4E4D81C8.7000900@goop.org> X-Mailer: VM 8.0.9 under Emacs 21.4.1 (i486-pc-linux-gnu) From: Ian Jackson Cc: xen-devel@lists.xensource.com X-BeenThere: xen-devel@lists.xensource.com X-Mailman-Version: 2.1.5 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xensource.com Errors-To: xen-devel-bounces@lists.xensource.com Jeremy Fitzhardinge writes ("Re: [Xen-devel] udev oops, and system boot= failure, with 2.6.32.44 as PV guest"): > On 08/18/2011 04:19 AM, Ian Jackson wrote: > > This failure happens only on these two machines, for some reason. > > I haven't tried 32-bit. I see crashes with 32-on-64 too. > At first glance it doesn't really look very Xen-related; alloc_fd isn= 't > generally a place where anything Xen-specific happens. Can you deco= de > that to a specific line of code? There doesn't seem to be much point, given that different crashes have different locations. I tried a number of boots and got the stack backtraces you can see below. Something is obviously completely buggered. > I'm wondering if the access to "/sys/devices/virtual/bdi/1:13/uevent"= is > pertinent though; it could be one of our drivers which is doing the > wrong thing which causes alloc_fd to explode. No, it gives a different access each time. > Is this expected, or does it indicate something wrong with your > (initramfs?) confg? I don't think anything is wrong with my initramfs. It works fine with other kernels :-). The messages about volume group "rice-weevil" being missing are simply because I reuse the host's initramfs, which has had stuff about the host's disk layout encoded into it by the host's initramfs-tools, and is harmless. Ian. Starting the hotplug events dispatcher: udevd[ 1.240492] udev[835]: = starting version 164 . [ 1.335497] BUG: unable to handle kernel NULL pointer dereference at= (null) [ 1.335536] IP: [] __wake_up_common+0x17/0x5c [ 1.335562] *pdpt =3D 000000000175c007 *pde =3D 0000000000000000=20 [ 1.335590] Oops: 0000 [#1] SMP=20 [ 1.335614] last sysfs file: /sys/kernel/uevent_seqnum [ 1.335627] Modules linked in: [last unloaded: scsi_wait_scan] [ 1.335653]=20 [ 1.335664] Pid: 844, comm: mv Not tainted (2.6.32.45 #1)=20 [ 1.335678] EIP: 0061:[] EFLAGS: 00010093 CPU: 0 [ 1.335692] EIP is at __wake_up_common+0x17/0x5c [ 1.335705] EAX: dfcb290c EBX: fffffff4 ECX: 00000001 EDX: 00000001 [ 1.335720] ESI: dfcb0008 EDI: 00000001 EBP: dbb51e90 ESP: dbb51e78 [ 1.335734] DS: 007b ES: 007b FS: 00d8 GS: 0000 SS: 0069 [ 1.335748] Process mv (pid: 844, ti=3Ddbb50000 task=3Dc4ef8f30 task= .ti=3Ddbb50000) [ 1.335763] Stack: [ 1.335772] 00000011 dbb51e84 00000001 dfcb2908 dfcb0008 00000011 d= bb51eb0 c1056e39 [ 1.335828] <0> 00000001 c4ef8f30 00000001 00000001 c4ef8f30 0000001= 1 dbb51ebc c1062759 [ 1.335889] <0> c4ef8f30 dbb51f5c c106f763 c4efef40 c4ef0044 c4eff44= 4 00000011 00000000 [ 1.335958] Call Trace: [ 1.335976] [] ? __wake_up_sync_key+0x33/0x45 [ 1.335996] [] ? __wake_up_parent+0x1e/0x21 [ 1.336015] [] ? do_notify_parent+0x17e/0x19c [ 1.336036] [] ? perf_event_exit_task+0x1e/0x2b2 [ 1.336059] [] ? _write_lock_irq+0x18/0x2a [ 1.336070] [] ? exit_ptrace+0xa3/0x10d [ 1.336070] [] ? switch_task_namespaces+0xf/0x3a [ 1.336070] [] ? do_exit+0x553/0x608 [ 1.336070] [] ? do_group_exit+0x88/0xab [ 1.336070] [] ? sys_exit_group+0x13/0x17 [ 1.336070] [] ? syscall_call+0x7/0xb [ 1.336070] Code: 89 e5 e8 9b ff ff ff 5d c3 55 8b 80 88 02 00 00 89= e5 5d c3 55 89 e5 57 89 d7 56 53 83 ec 0c 89 4d f0 8b 58 04 83 c0 04 8= 3 eb 0c <8b> 73 0c 89 45 e8 83 ee 0c eb 2a 8b 03 89 fa ff 75 0c 8b 4d 0= 8=20 [ 1.336070] EIP: [] __wake_up_common+0x17/0x5c SS:ESP 0069= :dbb51e78 [ 1.336070] CR2: 0000000000000000 [ 1.336070] ---[ end trace 59579aaa0506cac8 ]--- [ 1.336070] Fixing recursive fault but reboot is needed! Starting the hotplug events dispatcher: udevd[ 1.200636] udev[839]: = starting version 164 . Synthesizing the initial hotplug events...done. Waiting for /dev to be fully populated...[ 1.546234] BUG: unable to = handle kernel NULL pointer dereference at 00000008 [ 1.546258] IP: [] rb_erase+0x72/0x208 [ 1.546272] *pdpt =3D 000000001fdcc007 *pde =3D 0000000000000000=20 [ 1.546284] Oops: 0002 [#1] SMP=20 [ 1.546295] last sysfs file: /sys/devices/virtual/vtconsole/vtcon0/u= event [ 1.546302] Modules linked in: [last unloaded: scsi_wait_scan] [ 1.546314]=20 [ 1.546319] Pid: 855, comm: udevd Not tainted (2.6.32.45 #1)=20 [ 1.546325] EIP: 0061:[] EFLAGS: 00010046 CPU: 0 [ 1.546332] EIP is at rb_erase+0x72/0x208 [ 1.546337] EAX: dbbfd004 EBX: 00000000 ECX: c4da8b84 EDX: 00000000 [ 1.546344] ESI: c5ff0388 EDI: 00000000 EBP: c52c5f04 ESP: c52c5eec [ 1.546350] DS: 007b ES: 007b FS: 00d8 GS: 0033 SS: 0069 [ 1.546357] Process udevd (pid: 855, ti=3Dc52c4000 task=3Ddbbab7b0 t= ask.ti=3Dc52c4000) [ 1.546363] Stack: [ 1.546368] 00000000 00000000 00000000 dbbfd004 c5ff0380 00000000 c= 52c5f18 c1078bd5 [ 1.546393] <0> dbbfd004 048a2000 c52c5f84 c52c5f30 c1078c28 0000000= 1 c5ff0380 dbbfd004 [ 1.546420] <0> ffffffff c52c5f44 c10793a4 c5ff0050 dbbab7b0 c52c5f9= 4 c52c5f7c c1064ae1 [ 1.546451] Call Trace: [ 1.546461] [] ? __remove_hrtimer+0x64/0x6c [ 1.546469] [] ? remove_hrtimer+0x4b/0x58 [ 1.546478] [] ? hrtimer_try_to_cancel+0x24/0x3a [ 1.546488] [] ? do_setitimer+0xaa/0x1f5 [ 1.546497] [] ? __fput+0x161/0x169 [ 1.546505] [] ? alarm_setitimer+0x35/0x54 [ 1.546515] [] ? sys_alarm+0xb/0xd [ 1.546524] [] ? syscall_call+0x7/0xb [ 1.546530] Code: 8b 19 8b 51 04 89 5d ec 83 e3 fc 39 c3 89 5d f0 89= 5d e8 75 05 89 4d e8 eb 26 85 d2 74 0a 8b 3a 83 e7 03 0b 7d f0 89 3a 8= b 7d f0 <89> 57 08 8b 78 04 89 79 04 8b 58 04 8b 3b 83 e7 03 09 cf 89 3= b=20 [ 1.546713] EIP: [] rb_erase+0x72/0x208 SS:ESP 0069:c52c5e= ec [ 1.546726] CR2: 0000000000000008 [ 1.546733] ---[ end trace cafed11e7d7abcb5 ]--- Starting the hotplug events dispatcher: udevd[ 1.260149] udev[838]: = starting version 164 . Synthesizing the initial hotplug events...done. Waiting for /dev to be fully populated...[ 1.647871] BUG: unable to = handle kernel NULL pointer dereference at (null) [ 1.647896] IP: [] __wake_up_common+0x17/0x5c [ 1.647909] *pdpt =3D 000000000175c007 *pde =3D 0000000000000000=20 [ 1.647922] Oops: 0000 [#1] SMP=20 [ 1.647933] last sysfs file: /sys/devices/virtual/input/input0/mouse= 0/uevent [ 1.647940] Modules linked in: [last unloaded: scsi_wait_scan] [ 1.647952]=20 [ 1.647957] Pid: 934, comm: grep Not tainted (2.6.32.45 #1)=20 [ 1.647964] EIP: 0061:[] EFLAGS: 00010093 CPU: 0 [ 1.647971] EIP is at __wake_up_common+0x17/0x5c [ 1.647977] EAX: dea9f20c EBX: fffffff4 ECX: 00000001 EDX: 00000001 [ 1.647983] ESI: dea90008 EDI: 00000001 EBP: dead5e90 ESP: dead5e78 [ 1.647990] DS: 007b ES: 007b FS: 00d8 GS: 0000 SS: 0069 [ 1.647996] Process grep (pid: 934, ti=3Ddead4000 task=3Ddea98000 ta= sk.ti=3Ddead4000) [ 1.648003] Stack: [ 1.648008] 00000011 dead5e84 00000001 dea9f208 dea90008 00000011 d= ead5eb0 c1056e39 [ 1.648033] <0> 00000001 dea98000 00000001 00000001 dea98000 0000001= 1 dead5ebc c1062759 [ 1.648053] <0> dea98000 dead5f5c c106f763 c4df39c0 c4df00c4 c4df3ec= 4 00000011 00000000 [ 1.648053] Call Trace: [ 1.648053] [] ? __wake_up_sync_key+0x33/0x45 [ 1.648053] [] ? __wake_up_parent+0x1e/0x21 [ 1.648053] [] ? do_notify_parent+0x17e/0x19c [ 1.648053] [] ? perf_event_exit_task+0x1e/0x2b2 [ 1.648053] [] ? _write_lock_irq+0x18/0x2a [ 1.648053] [] ? exit_ptrace+0xa3/0x10d [ 1.648053] [] ? switch_task_namespaces+0xf/0x3a [ 1.648053] [] ? do_exit+0x553/0x608 [ 1.648053] [] ? do_group_exit+0x88/0xab [ 1.648053] [] ? sys_exit_group+0x13/0x17 [ 1.648053] [] ? syscall_call+0x7/0xb [ 1.648053] Code: 89 e5 e8 9b ff ff ff 5d c3 55 8b 80 88 02 00 00 89= e5 5d c3 55 89 e5 57 89 d7 56 53 83 ec 0c 89 4d f0 8b 58 04 83 c0 04 8= 3 eb 0c <8b> 73 0c 89 45 e8 83 ee 0c eb 2a 8b 03 89 fa ff 75 0c 8b 4d 0= 8=20 [ 1.648053] EIP: [] __wake_up_common+0x17/0x5c SS:ESP 0069= :dead5e78 [ 1.648053] CR2: 0000000000000000 [ 1.648053] ---[ end trace 6942a97668899ff4 ]--- [ 1.648053] Fixing recursive fault but reboot is needed! Using makefile-style concurrent boot in runlevel S. [ 1.133364] BUG: unable to handle kernel NULL pointer dereference at= 00000004 [ 1.133398] IP: [] add_wait_queue+0x1b/0x36 [ 1.133423] *pdpt =3D 000000001bfe4027 *pde =3D 0000000000000000=20 [ 1.133449] Oops: 0002 [#1] SMP=20 [ 1.133472] last sysfs file: /sys/kernel/uevent_seqnum [ 1.133485] Modules linked in: [last unloaded: scsi_wait_scan] [ 1.133510]=20 [ 1.133522] Pid: 808, comm: startpar Not tainted (2.6.32.45 #1)=20 [ 1.133536] EIP: 0061:[] EFLAGS: 00010096 CPU: 0 [ 1.133550] EIP is at add_wait_queue+0x1b/0x36 [ 1.133563] EAX: c4f30208 EBX: c4f34908 ECX: dfce9f7c EDX: c4f3490c [ 1.133577] ESI: dfce9f70 EDI: 00000000 EBP: dfce9f20 ESP: dfce9f14 [ 1.133591] DS: 007b ES: 007b FS: 00d8 GS: 0033 SS: 0069 [ 1.133604] Process startpar (pid: 808, ti=3Ddfce8000 task=3Dc4f28a2= 0 task.ti=3Ddfce8000) [ 1.133619] Stack: [ 1.133629] dfce9f58 00000000 00000000 dfce9f4c c1063dd3 c5384380 c= 5384980 dfce9f70 [ 1.133683] <0> dfce9f48 00000010 c4f28a20 ffffffff 00000000 0000000= 0 dfce9f94 c1063fcf [ 1.133744] <0> c10e82b9 00000003 00000007 00000000 00000000 bf87ee9= c 00000000 00000000 [ 1.133811] Call Trace: [ 1.133829] [] ? do_wait+0x61/0x1d5 [ 1.133847] [] ? sys_wait4+0x88/0xa1 [ 1.133865] [] ? rw_verify_area+0x98/0xbb [ 1.133884] [] ? child_wait_callback+0x0/0x5f [ 1.133902] [] ? sys_waitpid+0x13/0x15 [ 1.133922] [] ? syscall_call+0x7/0xb [ 1.133934] Code: 89 39 89 c2 89 d8 e8 00 d9 3e 00 5b 5e 5f 5d c3 55= 89 e5 57 56 89 d6 53 89 c3 83 22 fe e8 70 da 3e 00 8b 7b 0 4 8d 4e 0c 8d 53 04 <89> 4f 04 89 7e 0c 89 56 10 89 c2 89 d8 89 4b 04 e= 8 cb d8 3e 00=20 [ 1.134058] EIP: [] add_wait_queue+0x1b/0x36 SS:ESP 0069:d= fce9f14 [ 1.134058] CR2: 0000000000000004 [ 1.134058] ---[ end trace 85d46112ef8f4b48 ]--- [ 1.134895] ------------[ cut here ]------------ [ 1.134912] kernel BUG at kernel/exit.c:84! [ 1.134924] invalid opcode: 0000 [#2] SMP=20 [ 1.134948] last sysfs file: /sys/kernel/uevent_seqnum [ 1.134960] Modules linked in: [last unloaded: scsi_wait_scan] [ 1.134984]=20 [ 1.134996] Pid: 805, comm: rc Tainted: G D (2.6.32.45 #1)=20= [ 1.135010] EIP: 0061:[] EFLAGS: 00010046 CPU: 0 [ 1.135025] EIP is at release_task+0x73/0x3d4 [ 1.135038] EAX: 00000000 EBX: c4f28a20 ECX: c1668980 EDX: 02218e31 [ 1.135054] ESI: c4f34900 EDI: c174e2e0 EBP: dfde7ed0 ESP: dfde7eb8 [ 1.135068] DS: 007b ES: 007b FS: 00d8 GS: 0033 SS: 0069 [ 1.135081] Process rc (pid: 805, ti=3Ddfde6000 task=3Dc4f29440 task= .ti=3Ddfde6000) [ 1.135096] Stack: [ 1.135105] c4f28a20 dfde7ec4 c102ce90 bffffffd 00000328 c4f28a20 d= fde7f38 c1063967 [ 1.135159] <0> 00003493 00000000 00000166 00000000 00000000 0000032= 8 00000001 00000000 [ 1.135220] <0> 00000022 00000000 00000018 00000000 00000000 0000000= 0 00000000 00000000 [ 1.135287] Call Trace: [ 1.135303] [] ? xen_spin_lock+0xa/0xe [ 1.135321] [] ? wait_consider_task+0x745/0xb50 [ 1.135340] [] ? do_wait+0xd5/0x1d5 [ 1.135358] [] ? sys_wait4+0x88/0xa1 [ 1.135376] [] ? child_wait_callback+0x0/0x5f [ 1.135395] [] ? syscall_call+0x7/0xb [ 1.135405] Code: e8 d9 6c 00 00 8d 83 34 02 00 00 39 83 34 02 00 00= 74 04 0f 0b eb fe 8b b3 a8 03 00 00 85 f6 75 04 0f 0b eb f e 8b 06 85 c0 75 04 <0f> 0b eb fe 8b 83 ac 03 00 00 89 45 f0 05 04 05 0= 0 00 e8 00 12=20 [ 1.135405] EIP: [] release_task+0x73/0x3d4 SS:ESP 0069:df= de7eb8 [ 1.135405] ---[ end trace 85d46112ef8f4b49 ]--- _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel From xen-devel-bounces@lists.xensource.com Thu Sep 01 08:38:25 2011 Return-path: Envelope-to: www-data@lists.xensource.com Delivery-date: Thu, 01 Sep 2011 08:38:25 -0700 Received: from localhost ([127.0.0.1] helo=lists.colo.xensource.com) by lists.xensource.com with esmtp (Exim 4.43) id 1Qz9LV-00032U-Ja; Thu, 01 Sep 2011 08:38:25 -0700 Received: from mail182.messagelabs.com ([85.158.139.83]) by lists.xensource.com with smtp (Exim 4.43) id 1Qz9Jy-0002Qn-VC for xen-devel@lists.xensource.com; Thu, 01 Sep 2011 08:36:51 -0700 X-Env-Sender: Ian.Jackson@eu.citrix.com X-Msg-Ref: server-11.tower-182.messagelabs.com!1314891407!16706416!1 X-Originating-IP: [62.200.22.115] X-StarScan-Version: 6.3.6; banners=-,-,- X-VirusChecked: Checked Received: (qmail 28901 invoked from network); 1 Sep 2011 15:36:48 -0000 Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115) by server-11.tower-182.messagelabs.com with SMTP; 1 Sep 2011 15:36:48 -0000 X-IronPort-AV: E=Sophos;i="4.68,313,1312156800"; d="scan'208";a="7558371" Received: from lonpmailmx01.citrite.net ([10.30.203.162]) by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5; 01 Sep 2011 15:36:31 +0000 Received: from woking.xci-test.com (10.80.248.135) by smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id 8.3.137.0; Thu, 1 Sep 2011 16:36:30 +0100 Received: from osstest by woking.xci-test.com with local (Exim 4.69) (envelope-from ) id 1Qz9Je-00053L-NF; Thu, 01 Sep 2011 16:36:30 +0100 To: Message-ID: From: xen.org Date: Thu, 1 Sep 2011 16:36:30 +0100 MIME-Version: 1.0 Content-Type: text/plain Cc: ian.jackson@eu.citrix.com Subject: [Xen-devel] [xen-4.1-testing test] 8802: regressions - FAIL X-BeenThere: xen-devel@lists.xensource.com X-Mailman-Version: 2.1.5 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xensource.com Errors-To: xen-devel-bounces@lists.xensource.com flight 8802 xen-4.1-testing real [real] http://www.chiark.greenend.org.uk/~xensrcts/logs/8802/ Regressions :-( Tests which did not succeed and are blocking: test-amd64-amd64-xl-sedf 14 guest-localmigrate/x10 fail in 8789 REGR. vs. 8771 Tests which are failing intermittently (not blocking): test-amd64-amd64-xl-sedf 13 guest-localmigrate.2 fail pass in 8789 Tests which did not succeed, but are not blocking, including regressions (tests previously passed) regarded as allowable: test-amd64-amd64-xl-pcipt-intel 9 guest-start fail never pass test-amd64-i386-rhel6hvm-intel 9 guest-start.2 fail never pass test-amd64-i386-rhel6hvm-amd 9 guest-start.2 fail never pass test-amd64-i386-win-vcpus1 16 leak-check/check fail never pass test-amd64-i386-xl-win-vcpus1 13 guest-stop fail never pass test-amd64-i386-win 16 leak-check/check fail never pass test-amd64-amd64-win 16 leak-check/check fail never pass test-amd64-amd64-xl-win 13 guest-stop fail never pass test-i386-i386-win 16 leak-check/check fail never pass test-i386-i386-xl-win 13 guest-stop fail never pass version targeted for testing: xen 6239209bb560 baseline version: xen be4b078e2d08 ------------------------------------------------------------ People who touched revisions under test: Andrew Cooper Dietmar Hahn Ian Jackson Marek Marczykowski Stefano Stabellini ------------------------------------------------------------ jobs: build-amd64 pass build-i386 pass build-amd64-oldkern pass build-i386-oldkern pass build-amd64-pvops pass build-i386-pvops pass test-amd64-amd64-xl pass test-amd64-i386-xl pass test-i386-i386-xl pass test-amd64-i386-rhel6hvm-amd fail test-amd64-i386-xl-credit2 pass test-amd64-amd64-xl-pcipt-intel fail test-amd64-i386-rhel6hvm-intel fail test-amd64-i386-xl-multivcpu pass test-amd64-amd64-pair pass test-amd64-i386-pair pass test-i386-i386-pair pass test-amd64-amd64-pv pass test-amd64-i386-pv pass test-i386-i386-pv pass test-amd64-amd64-xl-sedf fail test-amd64-i386-win-vcpus1 fail test-amd64-i386-xl-win-vcpus1 fail test-amd64-amd64-win fail test-amd64-i386-win fail test-i386-i386-win fail test-amd64-amd64-xl-win fail test-i386-i386-xl-win fail ------------------------------------------------------------ sg-report-flight on woking.cam.xci-test.com logs: /home/xc_osstest/logs images: /home/xc_osstest/images Logs, config files, etc. are available at http://www.chiark.greenend.org.uk/~xensrcts/logs Test harness code can be found at http://xenbits.xensource.com/gitweb?p=osstest.git;a=summary Not pushing. ------------------------------------------------------------ changeset: 23147:6239209bb560 tag: tip user: Stefano Stabellini date: Wed Aug 31 15:32:47 2011 +0100 xen: __hvm_pci_intx_assert should check for gsis remapped onto pirqs If the isa irq corresponding to a particular gsi is disabled while the gsi is enabled, __hvm_pci_intx_assert will always inject the gsi through the violapic, even if the gsi has been remapped onto a pirq. This patch makes sure that even in this case we inject the notification appropriately. Signed-off-by: Stefano Stabellini xen-unstable changeset: 23807:2297b90a6a7b xen-unstable date: Wed Aug 31 15:23:34 2011 +0100 changeset: 23146:50496ccde3c3 user: Stefano Stabellini date: Wed Aug 31 15:32:24 2011 +0100 xen: fix hvm_domain_use_pirq's behavior hvm_domain_use_pirq should return true when the guest is using a certain pirq, no matter if the corresponding event channel is currently enabled or disabled. As an additional complication, qemu is going to request pirqs for passthrough devices even for Xen unaware HVM guests, so we need to wait for an event channel to be connected before considering the pirq of a passthrough device as "in use". Signed-off-by: Stefano Stabellini xen-unstable changeset: 23806:4226ea1785b5 xen-unstable date: Wed Aug 31 15:23:12 2011 +0100 changeset: 23145:1092a143ef9d user: Andrew Cooper date: Wed Aug 31 15:31:22 2011 +0100 IRQ: manually EOI migrating line interrupts When migrating IO-APIC line level interrupts between PCPUs, the migration code rewrites the IO-APIC entry to point to the new CPU/Vector before EOI'ing it. The EOI process says that EOI'ing the Local APIC will cause a broadcast with the vector number, which the IO-APIC must listen to to clear the IRR and Status bits. In the case of migrating, the IO-APIC has already been reprogrammed so the EOI broadcast with the old vector fails to match the new vector, leaving the IO-APIC with an outstanding vector, preventing any more use of that line interrupt. This causes a lockup especially when your root device is using PCI INTA (megaraid_sas driver *ehem*) However, the problem is mostly hidden because send_cleanup_vector() causes a cleanup of all moving vectors on the current PCPU in such a way which does not cause the problem, and if the problem has occured, the writes it makes to the IO-APIC clears the IRR and Status bits which unlocks the problem. This fix is distinctly a temporary hack, waiting on a cleanup of the irq code. It checks for the edge case where we have moved the irq, and manually EOI's the old vector with the IO-APIC which correctly clears the IRR and Status bits. Also, it protects the code which updates irq_cfg by disabling interrupts. Signed-off-by: Andrew Cooper xen-unstable changeset: 23805:7048810180de xen-unstable date: Wed Aug 31 15:19:24 2011 +0100 changeset: 23144:2ace86381b97 user: Dietmar Hahn date: Wed Aug 31 15:26:45 2011 +0100 vpmu: Add processors Westmere E7-8837 and SandyBridge i5-2500 to the vpmu list Signed-off-by: Dietmar Hahn xen-unstable changeset: 23803:51983821efa4 xen-unstable date: Wed Aug 31 15:17:45 2011 +0100 changeset: 23143:be4b078e2d08 user: Marek Marczykowski date: Sun Jun 05 16:55:21 2011 +0200 libxl: Do not SEGV when no 'removable' disk parameter in xenstore Just assume disk as not removable when no 'removable' paremeter Signed-off-by: Marek Marczykowski xen-unstable changest: 23607:2f63562df1c4 Backport-requested-by: Marek Marczykowski Committed-by: Ian Jackson (qemu changes not included) _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel From xen-devel-bounces@lists.xensource.com Thu Sep 01 08:39:59 2011 Return-path: Envelope-to: www-data@lists.xensource.com Delivery-date: Thu, 01 Sep 2011 08:39:59 -0700 Received: from localhost ([127.0.0.1] helo=lists.colo.xensource.com) by lists.xensource.com with esmtp (Exim 4.43) id 1Qz9N1-0003YF-Ko; Thu, 01 Sep 2011 08:39:59 -0700 Received: from mail174.messagelabs.com ([85.158.138.51]) by lists.xensource.com with esmtp (Exim 4.43) id 1Qz9Kc-0002fO-Vj for xen-devel@lists.xensource.com; Thu, 01 Sep 2011 08:37:31 -0700 X-Env-Sender: konrad@dumpdata.com X-Msg-Ref: server-12.tower-174.messagelabs.com!1314891446!29899324!1 X-Originating-IP: [148.87.113.117] X-StarScan-Version: 6.3.6; banners=-,-,- X-VirusChecked: Checked Received: (qmail 12429 invoked from network); 1 Sep 2011 15:37:27 -0000 Received: from rcsinet15.oracle.com (HELO rcsinet15.oracle.com) (148.87.113.117) by server-12.tower-174.messagelabs.com with DHE-RSA-AES256-SHA encrypted SMTP; 1 Sep 2011 15:37:27 -0000 Received: from acsinet22.oracle.com (acsinet22.oracle.com [141.146.126.238]) by rcsinet15.oracle.com (Switch-3.4.4/Switch-3.4.4) with ESMTP id p81FbHPh016579 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Thu, 1 Sep 2011 15:37:19 GMT Received: from acsmt356.oracle.com (acsmt356.oracle.com [141.146.40.156]) by acsinet22.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id p81FbES1025657 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 1 Sep 2011 15:37:15 GMT Received: from abhmt102.oracle.com (abhmt102.oracle.com [141.146.116.54]) by acsmt356.oracle.com (8.12.11.20060308/8.12.11) with ESMTP id p81Fb8vo018890; Thu, 1 Sep 2011 10:37:08 -0500 Received: from phenom (/209.6.55.207) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Thu, 01 Sep 2011 08:37:08 -0700 Received: by phenom (Postfix, from userid 1000) id 11FBFFD1; Thu, 1 Sep 2011 11:37:05 -0400 (EDT) Date: Thu, 1 Sep 2011 11:37:04 -0400 From: Konrad Rzeszutek Wilk To: David Vrabel Subject: Re: [Xen-devel] Kernel bug from 3.0 (was phy disks and vifs timing out in DomU) Message-ID: <20110901153704.GB7506@dumpdata.com> References: <4E4E3957.1040007@overnetdata.com> <20110819125615.GA26558@dumpdata.com> <4E56B132.9050708@overnetdata.com> <20110826142606.GA25511@dumpdata.com> <20110826144438.GA24836@dumpdata.com> <4E5E6843.7050206@citrix.com> <20110831170711.GB13642@dumpdata.com> <1314862972.28989.74.camel@zakaz.uk.xensource.com> <20110901142356.GD23971@dumpdata.com> <4E5FA0C4.7000806@citrix.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <4E5FA0C4.7000806@citrix.com> User-Agent: Mutt/1.5.21 (2010-09-15) X-Source-IP: acsinet22.oracle.com [141.146.126.238] X-Auth-Type: Internal IP X-CT-RefId: str=0001.0A090208.4E5FA6B1.00AA:SCFMA922111,ss=1,re=-4.000,fgs=0 Cc: Fitzhardinge , "xen-devel@lists.xensource.com" , Anthony Wright , Jeremy@acsinet12.oracle.com, Ian Campbell , Todd Deshane X-BeenThere: xen-devel@lists.xensource.com X-Mailman-Version: 2.1.5 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xensource.com Errors-To: xen-devel-bounces@lists.xensource.com > >> vmalloc: remove vmalloc_sync_all() from alloc_vm_area() > >> > >> There's no need for it: it will get faulted into the current pagetable > >> as needed. > >> > >> Signed-off-by: Jeremy Fitzhardinge > >> > >> The flaw in the reasoning here is that you cannot take a kernel fault > >> while processing a hypercall, so hypercall arguments must have been > >> faulted in beforehand and that is what the sync_all was for. > >> > >> It's probably fair to say that the Xen specific caller should take care > >> of that Xen-specific requirement rather than pushing it into common > >> code. On the other hand Xen is the only user and creating a Xen specific > >> helper/wrapper seems a bit pointless. > > > > Perhaps then doing the vmalloc_sync_all() (or are more precise one: > > vmalloc_sync_one) should be employed in the netback code then? > > > > And obviously guarded by the CONFIG_HIGHMEM case? > > Perhaps. But I think the correct thing to do initially is revert the > change and then look at possible improvements. Particularly as the fix > needs to be a backported to stable. I disagree. Ian pointed out properly that this a Xen requirment - and there is no reason for us to slow down non-Xen runs with vmalloc_sync_all plucked in a generic path. _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel From xen-devel-bounces@lists.xensource.com Thu Sep 01 08:41:06 2011 Return-path: Envelope-to: www-data@lists.xensource.com Delivery-date: Thu, 01 Sep 2011 08:41:06 -0700 Received: from localhost ([127.0.0.1] helo=lists.colo.xensource.com) by lists.xensource.com with esmtp (Exim 4.43) id 1Qz9O6-0003wW-Fz; Thu, 01 Sep 2011 08:41:06 -0700 Received: from mail216.messagelabs.com ([85.158.143.99]) by lists.xensource.com with esmtp (Exim 4.43) id 1Qz9NK-0003e0-9n for xen-devel@lists.xensource.com; Thu, 01 Sep 2011 08:40:18 -0700 X-Env-Sender: konrad@dumpdata.com X-Msg-Ref: server-6.tower-216.messagelabs.com!1314891613!15484329!1 X-Originating-IP: [148.87.113.117] X-StarScan-Version: 6.3.6; banners=-,-,- X-VirusChecked: Checked Received: (qmail 16519 invoked from network); 1 Sep 2011 15:40:15 -0000 Received: from rcsinet15.oracle.com (HELO rcsinet15.oracle.com) (148.87.113.117) by server-6.tower-216.messagelabs.com with DHE-RSA-AES256-SHA encrypted SMTP; 1 Sep 2011 15:40:15 -0000 Received: from rtcsinet21.oracle.com (rtcsinet21.oracle.com [66.248.204.29]) by rcsinet15.oracle.com (Switch-3.4.4/Switch-3.4.4) with ESMTP id p81Fe2dB023141 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Thu, 1 Sep 2011 15:40:08 GMT Received: from acsmt357.oracle.com (acsmt357.oracle.com [141.146.40.157]) by rtcsinet21.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id p81FcVAJ019407 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 1 Sep 2011 15:38:33 GMT Received: from abhmt108.oracle.com (abhmt108.oracle.com [141.146.116.60]) by acsmt357.oracle.com (8.12.11.20060308/8.12.11) with ESMTP id p81FcQJr028127; Thu, 1 Sep 2011 10:38:26 -0500 Received: from phenom (/209.6.55.207) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Thu, 01 Sep 2011 08:38:26 -0700 Received: by phenom (Postfix, from userid 1000) id 74AC1FD1; Thu, 1 Sep 2011 11:38:23 -0400 (EDT) Date: Thu, 1 Sep 2011 11:38:23 -0400 From: Konrad Rzeszutek Wilk To: Ian Campbell Subject: Re: [Xen-devel] Kernel bug from 3.0 (was phy disks and vifs timing out in DomU) Message-ID: <20110901153823.GC7506@dumpdata.com> References: <4E4E3957.1040007@overnetdata.com> <20110819125615.GA26558@dumpdata.com> <4E56B132.9050708@overnetdata.com> <20110826142606.GA25511@dumpdata.com> <20110826144438.GA24836@dumpdata.com> <4E5E6843.7050206@citrix.com> <20110831170711.GB13642@dumpdata.com> <1314862972.28989.74.camel@zakaz.uk.xensource.com> <20110901142356.GD23971@dumpdata.com> <1314889953.28989.130.camel@zakaz.uk.xensource.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <1314889953.28989.130.camel@zakaz.uk.xensource.com> User-Agent: Mutt/1.5.21 (2010-09-15) X-Source-IP: rtcsinet21.oracle.com [66.248.204.29] X-CT-RefId: str=0001.0A090206.4E5FA759.0148,ss=1,re=0.000,fgs=0 Cc: Todd Deshane , "xen-devel@lists.xensource.com" , Jeremy Fitzhardinge , David Vrabel , Anthony Wright X-BeenThere: xen-devel@lists.xensource.com X-Mailman-Version: 2.1.5 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xensource.com Errors-To: xen-devel-bounces@lists.xensource.com > > > The flaw in the reasoning here is that you cannot take a kernel fault > > > while processing a hypercall, so hypercall arguments must have been > > > faulted in beforehand and that is what the sync_all was for. > > > > > > It's probably fair to say that the Xen specific caller should take care > > > of that Xen-specific requirement rather than pushing it into common > > > code. On the other hand Xen is the only user and creating a Xen specific > > > helper/wrapper seems a bit pointless. > > > > Perhaps then doing the vmalloc_sync_all() (or are more precise one: > > vmalloc_sync_one) should be employed in the netback code then? > > Not just netback but everywhere which uses this interface. Which is for right now netback :-). But yes - wherever we use that we should do follow with some sort of vmalloc. > > > And obviously guarded by the CONFIG_HIGHMEM case? > > I don't think this has anything to do with highmem, does it? It is > potentially just as much of a problem on 64 bit for example. You are right. I somehow had vmalloc == highmem equated but that is bogus. > > Ian. _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel From xen-devel-bounces@lists.xensource.com Thu Sep 01 08:43:39 2011 Return-path: Envelope-to: www-data@lists.xensource.com Delivery-date: Thu, 01 Sep 2011 08:43:39 -0700 Received: from localhost ([127.0.0.1] helo=lists.colo.xensource.com) by lists.xensource.com with esmtp (Exim 4.43) id 1Qz9QZ-0004N7-II; Thu, 01 Sep 2011 08:43:39 -0700 Received: from mail182.messagelabs.com ([85.158.139.83]) by lists.xensource.com with smtp (Exim 4.43) id 1Qz9Q5-0004BM-6N for xen-devel@lists.xensource.com; Thu, 01 Sep 2011 08:43:09 -0700 X-Env-Sender: Ian.Campbell@eu.citrix.com X-Msg-Ref: server-6.tower-182.messagelabs.com!1314891786!16695250!1 X-Originating-IP: [62.200.22.115] X-StarScan-Version: 6.3.6; banners=-,-,- X-VirusChecked: Checked Received: (qmail 31063 invoked from network); 1 Sep 2011 15:43:06 -0000 Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115) by server-6.tower-182.messagelabs.com with SMTP; 1 Sep 2011 15:43:06 -0000 X-IronPort-AV: E=Sophos;i="4.68,313,1312156800"; d="scan'208";a="7558533" Received: from lonpmailmx01.citrite.net ([10.30.203.162]) by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5; 01 Sep 2011 15:43:06 +0000 Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net (10.30.203.162) with Microsoft SMTP Server id 8.3.137.0; Thu, 1 Sep 2011 16:43:05 +0100 Subject: Re: [Xen-devel] Kernel bug from 3.0 (was phy disks and vifs timing out in DomU) From: Ian Campbell To: Konrad Rzeszutek Wilk In-Reply-To: <20110901153704.GB7506@dumpdata.com> References: <4E4E3957.1040007@overnetdata.com> <20110819125615.GA26558@dumpdata.com> <4E56B132.9050708@overnetdata.com> <20110826142606.GA25511@dumpdata.com> <20110826144438.GA24836@dumpdata.com> <4E5E6843.7050206@citrix.com> <20110831170711.GB13642@dumpdata.com> <1314862972.28989.74.camel@zakaz.uk.xensource.com> <20110901142356.GD23971@dumpdata.com> <4E5FA0C4.7000806@citrix.com> <20110901153704.GB7506@dumpdata.com> Content-Type: text/plain; charset="UTF-8" Organization: Citrix Systems, Inc. Date: Thu, 1 Sep 2011 16:43:05 +0100 Message-ID: <1314891785.28989.133.camel@zakaz.uk.xensource.com> MIME-Version: 1.0 X-Mailer: Evolution 2.32.3 Content-Transfer-Encoding: 7bit Cc: Fitzhardinge , "xen-devel@lists.xensource.com" , Anthony Wright , "Jeremy@acsinet12.oracle.com" , David Vrabel , Todd Deshane X-BeenThere: xen-devel@lists.xensource.com X-Mailman-Version: 2.1.5 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xensource.com Errors-To: xen-devel-bounces@lists.xensource.com On Thu, 2011-09-01 at 16:37 +0100, Konrad Rzeszutek Wilk wrote: > > >> vmalloc: remove vmalloc_sync_all() from alloc_vm_area() > > >> > > >> There's no need for it: it will get faulted into the current pagetable > > >> as needed. > > >> > > >> Signed-off-by: Jeremy Fitzhardinge > > >> > > >> The flaw in the reasoning here is that you cannot take a kernel fault > > >> while processing a hypercall, so hypercall arguments must have been > > >> faulted in beforehand and that is what the sync_all was for. > > >> > > >> It's probably fair to say that the Xen specific caller should take care > > >> of that Xen-specific requirement rather than pushing it into common > > >> code. On the other hand Xen is the only user and creating a Xen specific > > >> helper/wrapper seems a bit pointless. > > > > > > Perhaps then doing the vmalloc_sync_all() (or are more precise one: > > > vmalloc_sync_one) should be employed in the netback code then? > > > > > > And obviously guarded by the CONFIG_HIGHMEM case? > > > > Perhaps. But I think the correct thing to do initially is revert the > > change and then look at possible improvements. Particularly as the fix > > needs to be a backported to stable. > > I disagree. Ian pointed out properly that this a Xen requirment - and there > is no reason for us to slow down non-Xen runs with vmalloc_sync_all plucked in > a generic path. There is literally no other caller of alloc_vm_area than xen so you won't be slowing anyone else down. Maybe we should add alloc_vm_area_sync and use that everywhere? Ian. _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel From xen-devel-bounces@lists.xensource.com Thu Sep 01 08:45:29 2011 Return-path: Envelope-to: www-data@lists.xensource.com Delivery-date: Thu, 01 Sep 2011 08:45:29 -0700 Received: from localhost ([127.0.0.1] helo=lists.colo.xensource.com) by lists.xensource.com with esmtp (Exim 4.43) id 1Qz9SK-0004li-VF; Thu, 01 Sep 2011 08:45:28 -0700 Received: from mail174.messagelabs.com ([85.158.138.51]) by lists.xensource.com with smtp (Exim 4.43) id 1Qz9Rq-0004Z0-CY for xen-devel@lists.xensource.com; Thu, 01 Sep 2011 08:44:58 -0700 X-Env-Sender: Ian.Campbell@eu.citrix.com X-Msg-Ref: server-3.tower-174.messagelabs.com!1314891895!23845117!1 X-Originating-IP: [62.200.22.115] X-StarScan-Version: 6.3.6; banners=-,-,- X-VirusChecked: Checked Received: (qmail 19787 invoked from network); 1 Sep 2011 15:44:55 -0000 Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115) by server-3.tower-174.messagelabs.com with SMTP; 1 Sep 2011 15:44:55 -0000 X-IronPort-AV: E=Sophos;i="4.68,313,1312156800"; d="scan'208";a="7558571" Received: from lonpmailmx01.citrite.net ([10.30.203.162]) by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5; 01 Sep 2011 15:44:55 +0000 Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net (10.30.203.162) with Microsoft SMTP Server id 8.3.137.0; Thu, 1 Sep 2011 16:44:54 +0100 Subject: Re: [Xen-devel] Kernel bug from 3.0 (was phy disks and vifs timing out in DomU) From: Ian Campbell To: Konrad Rzeszutek Wilk In-Reply-To: <20110901153823.GC7506@dumpdata.com> References: <4E4E3957.1040007@overnetdata.com> <20110819125615.GA26558@dumpdata.com> <4E56B132.9050708@overnetdata.com> <20110826142606.GA25511@dumpdata.com> <20110826144438.GA24836@dumpdata.com> <4E5E6843.7050206@citrix.com> <20110831170711.GB13642@dumpdata.com> <1314862972.28989.74.camel@zakaz.uk.xensource.com> <20110901142356.GD23971@dumpdata.com> <1314889953.28989.130.camel@zakaz.uk.xensource.com> <20110901153823.GC7506@dumpdata.com> Content-Type: text/plain; charset="UTF-8" Organization: Citrix Systems, Inc. Date: Thu, 1 Sep 2011 16:44:54 +0100 Message-ID: <1314891894.28989.135.camel@zakaz.uk.xensource.com> MIME-Version: 1.0 X-Mailer: Evolution 2.32.3 Content-Transfer-Encoding: 7bit Cc: Todd Deshane , "xen-devel@lists.xensource.com" , Jeremy Fitzhardinge , David Vrabel , Anthony Wright X-BeenThere: xen-devel@lists.xensource.com X-Mailman-Version: 2.1.5 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xensource.com Errors-To: xen-devel-bounces@lists.xensource.com On Thu, 2011-09-01 at 16:38 +0100, Konrad Rzeszutek Wilk wrote: > > > > The flaw in the reasoning here is that you cannot take a kernel fault > > > > while processing a hypercall, so hypercall arguments must have been > > > > faulted in beforehand and that is what the sync_all was for. > > > > > > > > It's probably fair to say that the Xen specific caller should take care > > > > of that Xen-specific requirement rather than pushing it into common > > > > code. On the other hand Xen is the only user and creating a Xen specific > > > > helper/wrapper seems a bit pointless. > > > > > > Perhaps then doing the vmalloc_sync_all() (or are more precise one: > > > vmalloc_sync_one) should be employed in the netback code then? > > > > Not just netback but everywhere which uses this interface. > > Which is for right now netback :-). But yes - wherever we use that > we should do follow with some sort of vmalloc. blkback, xenbus_client and the grant table stuff all use it as well and AFAICT have the same requirement for syncing. $ git grep alloc_vm_area arch/x86/include/asm/xen/grant_table.h:#define xen_alloc_vm_area(size) alloc_vm_area(size) -- this macro is unused... arch/x86/xen/grant-table.c: xen_alloc_vm_area(PAGE_SIZE * max_nr_gframes); drivers/block/xen-blkback/xenbus.c: blkif->blk_ring_area = alloc_vm_area(PAGE_SIZE); drivers/net/xen-netback/netback.c: vif->tx_comms_area = alloc_vm_area(PAGE_SIZE); drivers/net/xen-netback/netback.c: vif->rx_comms_area = alloc_vm_area(PAGE_SIZE); drivers/xen/xenbus/xenbus_client.c: area = xen_alloc_vm_area(PAGE_SIZE); Ian. _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel From xen-devel-bounces@lists.xensource.com Thu Sep 01 08:46:24 2011 Return-path: Envelope-to: www-data@lists.xensource.com Delivery-date: Thu, 01 Sep 2011 08:46:24 -0700 Received: from localhost ([127.0.0.1] helo=lists.colo.xensource.com) by lists.xensource.com with esmtp (Exim 4.43) id 1Qz9TE-0005Ck-8y; Thu, 01 Sep 2011 08:46:24 -0700 Received: from mail21.messagelabs.com ([85.158.143.35]) by lists.xensource.com with esmtp (Exim 4.43) id 1Qz9SE-0004hz-5Z for xen-devel@lists.xensource.com; Thu, 01 Sep 2011 08:45:22 -0700 X-Env-Sender: konrad@dumpdata.com X-Msg-Ref: server-14.tower-21.messagelabs.com!1314891910!57997244!1 X-Originating-IP: [141.146.126.227] X-StarScan-Version: 6.3.6; banners=-,-,- X-VirusChecked: Checked Received: (qmail 31901 invoked from network); 1 Sep 2011 15:45:11 -0000 Received: from acsinet15.oracle.com (HELO acsinet15.oracle.com) (141.146.126.227) by server-14.tower-21.messagelabs.com with DHE-RSA-AES256-SHA encrypted SMTP; 1 Sep 2011 15:45:11 -0000 Received: from rtcsinet22.oracle.com (rtcsinet22.oracle.com [66.248.204.30]) by acsinet15.oracle.com (Switch-3.4.4/Switch-3.4.4) with ESMTP id p81FjDu8016591 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Thu, 1 Sep 2011 15:45:15 GMT Received: from acsmt357.oracle.com (acsmt357.oracle.com [141.146.40.157]) by rtcsinet22.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id p81FjBMc017638 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 1 Sep 2011 15:45:12 GMT Received: from abhmt107.oracle.com (abhmt107.oracle.com [141.146.116.59]) by acsmt357.oracle.com (8.12.11.20060308/8.12.11) with ESMTP id p81Fj6tr000978; Thu, 1 Sep 2011 10:45:06 -0500 Received: from phenom (/209.6.55.207) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Thu, 01 Sep 2011 08:45:06 -0700 Received: by phenom (Postfix, from userid 1000) id 7984BFD1; Thu, 1 Sep 2011 11:45:03 -0400 (EDT) Date: Thu, 1 Sep 2011 11:45:03 -0400 From: Konrad Rzeszutek Wilk To: Igor Mammedov Message-ID: <20110901154503.GA7626@dumpdata.com> References: <4E5EB794.7050909@goop.org> <1314877615-18280-1-git-send-email-imammedo@redhat.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <1314877615-18280-1-git-send-email-imammedo@redhat.com> User-Agent: Mutt/1.5.21 (2010-09-15) X-Source-IP: rtcsinet22.oracle.com [66.248.204.30] X-CT-RefId: str=0001.0A090205.4E5FA88B.014A,ss=1,re=0.000,fgs=0 Cc: jeremy@goop.org, xen-devel@lists.xensource.com, linux-kernel@vger.kernel.org Subject: [Xen-devel] Re: [PATCH v2] xen: x86_32: do not enable iterrupts when returning from exception in interrupt context X-BeenThere: xen-devel@lists.xensource.com X-Mailman-Version: 2.1.5 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xensource.com Errors-To: xen-devel-bounces@lists.xensource.com On Thu, Sep 01, 2011 at 01:46:55PM +0200, Igor Mammedov wrote: > If vmalloc page_fault happens inside of interrupt handler with interrupts > disabled then on exit path from exception handler when there is no pending > interrupts, the following code (arch/x86/xen/xen-asm_32.S:112): > > cmpw $0x0001, XEN_vcpu_info_pending(%eax) > sete XEN_vcpu_info_mask(%eax) > > will enable interrupts even if they has been previously disabled according to > eflags from the bounce frame (arch/x86/xen/xen-asm_32.S:99) > > testb $X86_EFLAGS_IF>>8, 8+1+ESP_OFFSET(%esp) > setz XEN_vcpu_info_mask(%eax) > > Solution is in setting XEN_vcpu_info_mask only when it should be set > according to > cmpw $0x0001, XEN_vcpu_info_pending(%eax) > but not clearing it if there isn't any pending events. > > Reproducer for bug is attached to RHBZ 707552 > > Signed-off-by: Igor Mammedov > Signed-off-by: Jeremy Fitzhardinge Stuck it in the queue for 3.1 and stable. Thanks for finding this one! _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel From xen-devel-bounces@lists.xensource.com Thu Sep 01 08:49:55 2011 Return-path: Envelope-to: www-data@lists.xensource.com Delivery-date: Thu, 01 Sep 2011 08:49:55 -0700 Received: from localhost ([127.0.0.1] helo=lists.colo.xensource.com) by lists.xensource.com with esmtp (Exim 4.43) id 1Qz9Wd-0005fO-8P; Thu, 01 Sep 2011 08:49:55 -0700 Received: from mail174.messagelabs.com ([85.158.138.51]) by lists.xensource.com with esmtp (Exim 4.43) id 1Qz9Vt-0005TH-ES for xen-devel@lists.xensource.com; Thu, 01 Sep 2011 08:49:09 -0700 X-Env-Sender: tim@xen.org X-Msg-Ref: server-4.tower-174.messagelabs.com!1314892146!29928028!1 X-Originating-IP: [81.29.64.94] X-StarScan-Version: 6.3.6; banners=-,-,- X-VirusChecked: Checked Received: (qmail 12936 invoked from network); 1 Sep 2011 15:49:06 -0000 Received: from ocelot.phlegethon.org (HELO mail.phlegethon.org) (81.29.64.94) by server-4.tower-174.messagelabs.com with DHE-RSA-AES256-SHA encrypted SMTP; 1 Sep 2011 15:49:06 -0000 Received: from tjd by mail.phlegethon.org with local (Exim 4.67 (FreeBSD)) (envelope-from ) id 1Qz9Vo-0002V9-Il; Thu, 01 Sep 2011 15:49:04 +0000 Date: Thu, 1 Sep 2011 16:49:04 +0100 From: Tim Deegan To: George Dunlap Subject: Re: [Xen-devel] [PATCH] xen,credit1: Add variable timeslice Message-ID: <20110901154904.GG3859@ocelot.phlegethon.org> References: <782284c5b1bccc4f1acf.1314891026@elijah> Mime-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline In-Reply-To: <782284c5b1bccc4f1acf.1314891026@elijah> User-Agent: Mutt/1.4.2.1i Cc: xen-devel@lists.xensource.com X-BeenThere: xen-devel@lists.xensource.com X-Mailman-Version: 2.1.5 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xensource.com Errors-To: xen-devel-bounces@lists.xensource.com At 16:30 +0100 on 01 Sep (1314894626), George Dunlap wrote: > Add a xen command-line parameter, sched_credit_tslice_ms, > to set the timeslice of the credit1 scheduler. Does that really need to be set at boot time? It seem like sounething that should go through the credit scheduler's run-time interfaces. Tim. -- _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel From xen-devel-bounces@lists.xensource.com Thu Sep 01 08:51:41 2011 Return-path: Envelope-to: www-data@lists.xensource.com Delivery-date: Thu, 01 Sep 2011 08:51:41 -0700 Received: from localhost ([127.0.0.1] helo=lists.colo.xensource.com) by lists.xensource.com with esmtp (Exim 4.43) id 1Qz9YL-00063A-Qy; Thu, 01 Sep 2011 08:51:41 -0700 Received: from mail174.messagelabs.com ([85.158.138.51]) by lists.xensource.com with esmtp (Exim 4.43) id 1Qz9Xo-0005rB-P7 for xen-devel@lists.xensource.com; Thu, 01 Sep 2011 08:51:09 -0700 X-Env-Sender: George.Dunlap@eu.citrix.com X-Msg-Ref: server-7.tower-174.messagelabs.com!1314892264!29895928!1 X-Originating-IP: [66.165.176.63] X-StarScan-Version: 6.3.6; banners=-,-,- X-VirusChecked: Checked Received: (qmail 6751 invoked from network); 1 Sep 2011 15:51:05 -0000 Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63) by server-7.tower-174.messagelabs.com with RC4-SHA encrypted SMTP; 1 Sep 2011 15:51:05 -0000 X-IronPort-AV: E=Sophos;i="4.68,313,1312171200"; d="scan'208";a="161448414" Received: from ftlpmailmx02.citrite.net ([10.13.107.66]) by FTLPIPO02.CITRIX.COM with ESMTP/TLS/RC4-MD5; 01 Sep 2011 11:51:03 -0400 Received: from smtp01.ad.xensource.com (10.219.128.104) by smtprelay.citrix.com (10.13.107.66) with Microsoft SMTP Server id 8.3.137.0; Thu, 1 Sep 2011 11:51:03 -0400 Received: from [10.80.2.24] (elijah.uk.xensource.com [10.80.2.24]) by smtp01.ad.xensource.com (8.13.1/8.13.1) with ESMTP id p81Fp14E029039; Thu, 1 Sep 2011 08:51:02 -0700 Subject: Re: [Xen-devel] [PATCH] xen,credit1: Add variable timeslice From: George Dunlap To: Tim Deegan In-Reply-To: <20110901154904.GG3859@ocelot.phlegethon.org> References: <782284c5b1bccc4f1acf.1314891026@elijah> <20110901154904.GG3859@ocelot.phlegethon.org> Content-Type: text/plain; charset="UTF-8" Date: Thu, 1 Sep 2011 16:45:42 +0100 Message-ID: <1314891942.5679.9042.camel@elijah> MIME-Version: 1.0 X-Mailer: Evolution 2.28.3 Content-Transfer-Encoding: 7bit Cc: George Dunlap , "xen-devel@lists.xensource.com" X-BeenThere: xen-devel@lists.xensource.com X-Mailman-Version: 2.1.5 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xensource.com Errors-To: xen-devel-bounces@lists.xensource.com On Thu, 2011-09-01 at 16:49 +0100, Tim Deegan wrote: > At 16:30 +0100 on 01 Sep (1314894626), George Dunlap wrote: > > Add a xen command-line parameter, sched_credit_tslice_ms, > > to set the timeslice of the credit1 scheduler. > > Does that really need to be set at boot time? It seem like sounething > that should go through the credit scheduler's run-time interfaces. Yes, setting at run-time would be convenient. But it involves a lot of plumbing through to user-space tools that I don't have time to do at the moment. (Hopefully sometime in the next few months, maybe before 4.2.) -George _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel From xen-devel-bounces@lists.xensource.com Thu Sep 01 08:55:17 2011 Return-path: Envelope-to: www-data@lists.xensource.com Delivery-date: Thu, 01 Sep 2011 08:55:17 -0700 Received: from localhost ([127.0.0.1] helo=lists.colo.xensource.com) by lists.xensource.com with esmtp (Exim 4.43) id 1Qz9bp-0006Sp-Bu; Thu, 01 Sep 2011 08:55:17 -0700 Received: from mail216.messagelabs.com ([85.158.143.99]) by lists.xensource.com with smtp (Exim 4.43) id 1Qz9bE-0006G5-44 for xen-devel@lists.xensource.com; Thu, 01 Sep 2011 08:54:40 -0700 X-Env-Sender: Ian.Jackson@eu.citrix.com X-Msg-Ref: server-6.tower-216.messagelabs.com!1314892476!15485943!1 X-Originating-IP: [62.200.22.115] X-StarScan-Version: 6.3.6; banners=-,-,- X-VirusChecked: Checked Received: (qmail 16418 invoked from network); 1 Sep 2011 15:54:36 -0000 Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115) by server-6.tower-216.messagelabs.com with SMTP; 1 Sep 2011 15:54:36 -0000 X-IronPort-AV: E=Sophos;i="4.68,313,1312156800"; d="scan'208";a="7558787" Received: from lonpmailmx01.citrite.net ([10.30.203.162]) by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5; 01 Sep 2011 15:54:36 +0000 Received: from woking.xci-test.com (10.80.248.135) by smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id 8.3.137.0; Thu, 1 Sep 2011 16:54:36 +0100 Received: from osstest by woking.xci-test.com with local (Exim 4.69) (envelope-from ) id 1Qz9bA-0008S0-Hh; Thu, 01 Sep 2011 16:54:36 +0100 To: xen-devel@lists.xensource.com Message-ID: From: xen.org Date: Thu, 1 Sep 2011 16:54:36 +0100 MIME-Version: 1.0 Content-Type: text/plain Cc: ian.jackson@eu.citrix.com, keir@xen.org, stefano.stabellini@eu.citrix.com Subject: [Xen-devel] [xen-unstable bisection] complete test-amd64-i386-rhel6hvm-intel X-BeenThere: xen-devel@lists.xensource.com X-Mailman-Version: 2.1.5 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xensource.com Errors-To: xen-devel-bounces@lists.xensource.com branch xen-unstable xen branch xen-unstable job test-amd64-i386-rhel6hvm-intel test xen-install Tree: linux git://git.eu.kernel.org/pub/scm/linux/kernel/git/jeremy/xen.git Tree: qemu git://hg.uk.xensource.com/HG/qemu-xen-unstable.git Tree: xen http://hg.uk.xensource.com/xen-unstable.hg *** Found and reproduced problem changeset *** Bug is in tree: xen http://hg.uk.xensource.com/xen-unstable.hg Bug introduced: bb9b81008733 Bug not present: d54cfae72cd1 changeset: 23802:bb9b81008733 user: Laszlo Ersek date: Wed Aug 31 15:16:14 2011 +0100 x86: Increase the default NR_CPUS to 256 Changeset 21012:ef845a385014 bumped the default to 128 about one and a half years ago. Increase it now to 256, as systems with eg. 160 logical CPUs are becoming (have become) common. Signed-off-by: Laszlo Ersek For bisection revision-tuple graph see: http://www.chiark.greenend.org.uk/~xensrcts/results/bisect.xen-unstable.test-amd64-i386-rhel6hvm-intel.xen-install.html Revision IDs in each graph node refer, respectively, to the Trees above. ---------------------------------------- Searching for failure / basis pass: 8791 fail [host=earwig] / 8769 [host=itch-mite] 8760 [host=bush-cricket] 8739 [host=itch-mite] 8735 [host=bush-cricket] 8731 [host=itch-mite] 8729 [host=itch-mite] 8727 [host=gall-mite] 8726 [host=field-cricket] 8725 [host=gall-mite] 8724 [host=bush-cricket] 8723 [host=itch-mite] 8722 [host=bush-cricket] 8721 [host=field-cricket] 8718 [host=gall-mite] 8717 [host=bush-cricket] 8715 [host=itch-mite] 8713 [host=gall-mite] 8712 [host=gall-mite] 8711 [host=gall-mite] 8710 [host=field-cricket] 8707 [host=gall-mite] 8696 [host=gall-mite] 8687 [host=gall-mite] 8674 ok. Failure / basis pass flights: 8791 / 8674 Tree: linux git://git.eu.kernel.org/pub/scm/linux/kernel/git/jeremy/xen.git Tree: qemu git://hg.uk.xensource.com/HG/qemu-xen-unstable.git Tree: xen http://hg.uk.xensource.com/xen-unstable.hg Latest 1c3f03ccc5258887f5f2cafc0836a865834f9205 cd776ee9408ff127f934a707c1a339ee600bc127 4a4882df5649 Basis pass ada3f6a1ba43e163aab95c7808f11b88fc7c79e6 cd776ee9408ff127f934a707c1a339ee600bc127 fc2be6cb89ad Generating revisions with ./adhoc-revtuple-generator git://git.eu.kernel.org/pub/scm/linux/kernel/git/jeremy/xen.git#ada3f6a1ba43e163aab95c7808f11b88fc7c79e6-1c3f03ccc5258887f5f2cafc0836a865834f9205 git://hg.uk.xensource.com/HG/qemu-xen-unstable.git#cd776ee9408ff127f934a707c1a339ee600bc127-cd776ee9408ff127f934a707c1a339ee600bc127 http://hg.uk.xensource.com/xen-unstable.hg#fc2be6cb89ad-4a4882df5649 using cache /export/home/osstest/repos/git-cache... using cache /export/home/osstest/repos/git-cache... locked cache /export/home/osstest/repos/git-cache... processing ./cacheing-git clone --bare git://git.eu.kernel.org/pub/scm/linux/kernel/git/jeremy/xen.git /export/home/osstest/repos/xen... Initialized empty Git repository in /export/home/osstest/repos/xen/ Initialized empty Git repository in /export/home/osstest/repos/xen/ updating cache /export/home/osstest/repos/git-cache xen... pulling from http://hg.uk.xensource.com/xen-unstable.hg searching for changes no changes found using cache /export/home/osstest/repos/git-cache... using cache /export/home/osstest/repos/git-cache... locked cache /export/home/osstest/repos/git-cache... processing ./cacheing-git clone --bare git://git.eu.kernel.org/pub/scm/linux/kernel/git/jeremy/xen.git /export/home/osstest/repos/xen... Initialized empty Git repository in /export/home/osstest/repos/xen/ Initialized empty Git repository in /export/home/osstest/repos/xen/ updating cache /export/home/osstest/repos/git-cache xen... pulling from http://hg.uk.xensource.com/xen-unstable.hg searching for changes no changes found Loaded 2260 nodes in revision graph Searching for test results: 8674 pass ada3f6a1ba43e163aab95c7808f11b88fc7c79e6 cd776ee9408ff127f934a707c1a339ee600bc127 fc2be6cb89ad 8664 pass ada3f6a1ba43e163aab95c7808f11b88fc7c79e6 cd776ee9408ff127f934a707c1a339ee600bc127 fc2be6cb89ad 8712 [host=gall-mite] 8722 [host=bush-cricket] 8713 [host=gall-mite] 8687 [host=gall-mite] 8735 [host=bush-cricket] 8723 [host=itch-mite] 8696 [host=gall-mite] 8715 [host=itch-mite] 8707 [host=gall-mite] 8724 [host=bush-cricket] 8710 [host=field-cricket] 8717 [host=bush-cricket] 8711 [host=gall-mite] 8718 [host=gall-mite] 8725 [host=gall-mite] 8721 [host=field-cricket] 8729 [host=itch-mite] 8726 [host=field-cricket] 8727 [host=gall-mite] 8731 [host=itch-mite] 8739 [host=itch-mite] 8786 pass 1c3f03ccc5258887f5f2cafc0836a865834f9205 cd776ee9408ff127f934a707c1a339ee600bc127 2c687e70a343 8806 fail 1c3f03ccc5258887f5f2cafc0836a865834f9205 cd776ee9408ff127f934a707c1a339ee600bc127 bb9b81008733 8781 [host=field-cricket] 8760 [host=bush-cricket] 8790 pass 20a27c1e25b8550066902c9d6ca91631e656dfa3 cd776ee9408ff127f934a707c1a339ee600bc127 41f00cf6b822 8792 [host=field-cricket] 8793 [host=field-cricket] 8769 [host=itch-mite] 8794 [host=field-cricket] 8791 fail 1c3f03ccc5258887f5f2cafc0836a865834f9205 cd776ee9408ff127f934a707c1a339ee600bc127 4a4882df5649 8795 [host=field-cricket] 8796 pass 1c3f03ccc5258887f5f2cafc0836a865834f9205 cd776ee9408ff127f934a707c1a339ee600bc127 ac9aa65050e9 8797 fail 1c3f03ccc5258887f5f2cafc0836a865834f9205 cd776ee9408ff127f934a707c1a339ee600bc127 51983821efa4 8776 fail 1c3f03ccc5258887f5f2cafc0836a865834f9205 cd776ee9408ff127f934a707c1a339ee600bc127 4a4882df5649 8798 pass 1c3f03ccc5258887f5f2cafc0836a865834f9205 cd776ee9408ff127f934a707c1a339ee600bc127 d54cfae72cd1 8782 pass ada3f6a1ba43e163aab95c7808f11b88fc7c79e6 cd776ee9408ff127f934a707c1a339ee600bc127 fc2be6cb89ad 8799 fail 1c3f03ccc5258887f5f2cafc0836a865834f9205 cd776ee9408ff127f934a707c1a339ee600bc127 bb9b81008733 8784 fail 1c3f03ccc5258887f5f2cafc0836a865834f9205 cd776ee9408ff127f934a707c1a339ee600bc127 4a4882df5649 8800 pass 1c3f03ccc5258887f5f2cafc0836a865834f9205 cd776ee9408ff127f934a707c1a339ee600bc127 d54cfae72cd1 8804 fail 1c3f03ccc5258887f5f2cafc0836a865834f9205 cd776ee9408ff127f934a707c1a339ee600bc127 bb9b81008733 8805 pass 1c3f03ccc5258887f5f2cafc0836a865834f9205 cd776ee9408ff127f934a707c1a339ee600bc127 d54cfae72cd1 Searching for interesting versions Result found: flight 8664 (pass), for basis pass Result found: flight 8776 (fail), for basis failure Repro found: flight 8782 (pass), for basis pass Repro found: flight 8784 (fail), for basis failure 0 revisions at 1c3f03ccc5258887f5f2cafc0836a865834f9205 cd776ee9408ff127f934a707c1a339ee600bc127 d54cfae72cd1 No revisions left to test, checking graph state. Result found: flight 8798 (pass), for last pass Result found: flight 8799 (fail), for first failure Repro found: flight 8800 (pass), for last pass Repro found: flight 8804 (fail), for first failure Repro found: flight 8805 (pass), for last pass Repro found: flight 8806 (fail), for first failure *** Found and reproduced problem changeset *** Bug is in tree: xen http://hg.uk.xensource.com/xen-unstable.hg Bug introduced: bb9b81008733 Bug not present: d54cfae72cd1 pulling from http://hg.uk.xensource.com/xen-unstable.hg searching for changes no changes found changeset: 23802:bb9b81008733 user: Laszlo Ersek date: Wed Aug 31 15:16:14 2011 +0100 x86: Increase the default NR_CPUS to 256 Changeset 21012:ef845a385014 bumped the default to 128 about one and a half years ago. Increase it now to 256, as systems with eg. 160 logical CPUs are becoming (have become) common. Signed-off-by: Laszlo Ersek Revision graph left in /home/xc_osstest/results/bisect.xen-unstable.test-amd64-i386-rhel6hvm-intel.xen-install.{dot,ps,png,html}. ---------------------------------------- 8806: ALL FAIL flight 8806 xen-unstable real-bisect [real] http://www.chiark.greenend.org.uk/~xensrcts/logs/8806/ jobs: build-i386 fail test-amd64-i386-rhel6hvm-intel fail ------------------------------------------------------------ sg-report-flight on woking.cam.xci-test.com logs: /home/xc_osstest/logs images: /home/xc_osstest/images Logs, config files, etc. are available at http://www.chiark.greenend.org.uk/~xensrcts/logs Test harness code can be found at http://xenbits.xensource.com/gitweb?p=osstest.git;a=summary _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel From xen-devel-bounces@lists.xensource.com Thu Sep 01 08:59:56 2011 Return-path: Envelope-to: www-data@lists.xensource.com Delivery-date: Thu, 01 Sep 2011 08:59:56 -0700 Received: from localhost ([127.0.0.1] helo=lists.colo.xensource.com) by lists.xensource.com with esmtp (Exim 4.43) id 1Qz9gI-00075Q-Qr; Thu, 01 Sep 2011 08:59:54 -0700 Received: from mail174.messagelabs.com ([85.158.138.51]) by lists.xensource.com with esmtp (Exim 4.43) id 1Qz9eX-0006qg-6o for xen-devel@lists.xensource.com; Thu, 01 Sep 2011 08:58:05 -0700 X-Env-Sender: Christoph.Egger@amd.com X-Msg-Ref: server-10.tower-174.messagelabs.com!1314892680!29912549!1 X-Originating-IP: [65.55.88.12] X-StarScan-Version: 6.3.6; banners=-,-,- X-VirusChecked: Checked Received: (qmail 18873 invoked from network); 1 Sep 2011 15:58:02 -0000 Received: from tx2ehsobe002.messaging.microsoft.com (HELO TX2EHSOBE004.bigfish.com) (65.55.88.12) by server-10.tower-174.messagelabs.com with AES128-SHA encrypted SMTP; 1 Sep 2011 15:58:02 -0000 Received: from mail155-tx2-R.bigfish.com (10.9.14.246) by TX2EHSOBE004.bigfish.com (10.9.40.24) with Microsoft SMTP Server id 14.1.225.22; Thu, 1 Sep 2011 15:58:00 +0000 Received: from mail155-tx2 (localhost.localdomain [127.0.0.1]) by mail155-tx2-R.bigfish.com (Postfix) with ESMTP id 48B1E12D809E; Thu, 1 Sep 2011 15:58:00 +0000 (UTC) X-SpamScore: -16 X-BigFish: VPS-16(zzbb2dK148cM1432N98dKzz1202hzz8275bhz32i668h839h93fh61h) X-Spam-TCS-SCL: 0:0 X-Forefront-Antispam-Report: CIP:163.181.249.108; KIP:(null); UIP:(null); IPVD:NLI; H:ausb3twp01.amd.com; RD:none; EFVD:NLI Received: from mail155-tx2 (localhost.localdomain [127.0.0.1]) by mail155-tx2 (MessageSwitch) id 1314892679381204_19075; Thu, 1 Sep 2011 15:57:59 +0000 (UTC) Received: from TX2EHSMHS021.bigfish.com (unknown [10.9.14.250]) by mail155-tx2.bigfish.com (Postfix) with ESMTP id 4E155D6004B; Thu, 1 Sep 2011 15:57:59 +0000 (UTC) Received: from ausb3twp01.amd.com (163.181.249.108) by TX2EHSMHS021.bigfish.com (10.9.99.121) with Microsoft SMTP Server id 14.1.225.22; Thu, 1 Sep 2011 15:57:57 +0000 X-WSS-ID: 0LQUPOK-01-4HL-02 X-M-MSG: Received: from sausexedgep01.amd.com (sausexedgep01-ext.amd.com [163.181.249.72]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by ausb3twp01.amd.com (Axway MailGate 3.8.1) with ESMTP id 2E2A11028493; Thu, 1 Sep 2011 10:57:55 -0500 (CDT) Received: from SAUSEXDAG02.amd.com (163.181.55.2) by sausexedgep01.amd.com (163.181.36.54) with Microsoft SMTP Server (TLS) id 8.3.106.1; Thu, 1 Sep 2011 10:58:34 -0500 Received: from storexhtp01.amd.com (172.24.4.3) by sausexdag02.amd.com (163.181.55.2) with Microsoft SMTP Server (TLS) id 14.1.289.1; Thu, 1 Sep 2011 10:57:55 -0500 Received: from rhodium.osrc.amd.com (165.204.15.173) by storexhtp01.amd.com (172.24.4.3) with Microsoft SMTP Server id 8.3.83.0; Thu, 1 Sep 2011 11:57:54 -0400 Message-ID: <4E5FAB81.9060904@amd.com> Date: Thu, 1 Sep 2011 17:57:53 +0200 From: Christoph Egger User-Agent: Mozilla/5.0 (X11; U; NetBSD amd64; en-US; rv:1.9.2.17) Gecko/20110523 Lightning/1.0b3pre Thunderbird/3.1.10 MIME-Version: 1.0 To: Ian Campbell Subject: Re: [Xen-devel] Re: cs 23453:4f4970d2848d beaks Win 7 References: <4E5F43F2.6010601@amd.com> <1314867058.28989.84.camel@zakaz.uk.xensource.com> <4E5F4B7E.8090601@amd.com> <1314869549.28989.86.camel@zakaz.uk.xensource.com> <4E5F541F.6010405@amd.com> <1314889505.28989.127.camel@zakaz.uk.xensource.com> In-Reply-To: <1314889505.28989.127.camel@zakaz.uk.xensource.com> Content-Type: text/plain; charset="UTF-8"; format=flowed Content-Transfer-Encoding: 7bit X-OriginatorOrg: amd.com Cc: Ian Jackson , "xen-devel@lists.xensource.com" , Keir Fraser X-BeenThere: xen-devel@lists.xensource.com X-Mailman-Version: 2.1.5 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xensource.com Errors-To: xen-devel-bounces@lists.xensource.com On 09/01/11 17:05, Ian Campbell wrote: > The issue with 23453:4f4970d2848d is that it uses madt_csum_addr and > madt_lapic0_addr to initialise bios_info before they have themselves > been initialised. > > But in xen-unstable.hg tip everything has moved around and the issue now > turns out to be that we clear the acpi_info struct _after_ we've setup > the madt_* fields. Ooops! > > Thanks for reporting. > > Cheers, > Ian. I successfully tested your patch with Windows 7 (both 32bit and 64bit). Windows 7 can initialize its CPUs and no longer crashes on shutdown. Thanks for fixing. Please apply the fix. Tested-and-acked-by: Christoph Egger Christoph > > # HG changeset patch > # User Ian Campbell > # Date 1314889401 -3600 > # Node ID bb97bd46df6c6d8562759a964ebf6c31b6361a7a > # Parent 85b29185c9119ff9139596251d7bd13586853994 > hvmloader: don't clear acpi_info after filling in some fields > > In particular the madt_lapic0_addr and madt_csum_addr fields are > filled in while building the tables. > > This fixes a bluescreen on shutdown with certain versions of Windows. > > Signed-off-by: Ian Campbell > Reported-by: Christoph Egger > > diff -r 85b29185c911 -r bb97bd46df6c tools/firmware/hvmloader/acpi/build.c > --- a/tools/firmware/hvmloader/acpi/build.c Thu Sep 01 09:39:25 2011 +0100 > +++ b/tools/firmware/hvmloader/acpi/build.c Thu Sep 01 16:03:21 2011 +0100 > @@ -277,6 +277,8 @@ void acpi_build_tables(unsigned int phys > unsigned long secondary_tables[16]; > int nr_secondaries, i; > > + memset(acpi_info, 0, sizeof(*acpi_info)); > + > /* > * Fill in high-memory data structures, starting at @buf. > */ > @@ -375,7 +377,6 @@ void acpi_build_tables(unsigned int phys > offsetof(struct acpi_20_rsdp, extended_checksum), > sizeof(struct acpi_20_rsdp)); > > - memset(acpi_info, 0, sizeof(*acpi_info)); > acpi_info->com1_present = uart_exists(0x3f8); > acpi_info->com2_present = uart_exists(0x2f8); > acpi_info->lpt1_present = lpt_exists(0x378); -- ---to satisfy European Law for business letters: Advanced Micro Devices GmbH Einsteinring 24, 85689 Dornach b. Muenchen Geschaeftsfuehrer: Alberto Bozzo, Andrew Bowd Sitz: Dornach, Gemeinde Aschheim, Landkreis Muenchen Registergericht Muenchen, HRB Nr. 43632 _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel From xen-devel-bounces@lists.xensource.com Thu Sep 01 09:03:11 2011 Return-path: Envelope-to: www-data@lists.xensource.com Delivery-date: Thu, 01 Sep 2011 09:03:11 -0700 Received: from localhost ([127.0.0.1] helo=lists.colo.xensource.com) by lists.xensource.com with esmtp (Exim 4.43) id 1Qz9jT-0007Ut-8m; Thu, 01 Sep 2011 09:03:11 -0700 Received: from mail174.messagelabs.com ([85.158.138.51]) by lists.xensource.com with smtp (Exim 4.43) id 1Qz9fe-0006zh-Je for xen-devel@lists.xensource.com; Thu, 01 Sep 2011 08:59:15 -0700 X-Env-Sender: Ian.Jackson@eu.citrix.com X-Msg-Ref: server-12.tower-174.messagelabs.com!1314892750!29901795!1 X-Originating-IP: [62.200.22.115] X-StarScan-Version: 6.3.6; banners=-,-,- X-VirusChecked: Checked Received: (qmail 32528 invoked from network); 1 Sep 2011 15:59:10 -0000 Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115) by server-12.tower-174.messagelabs.com with SMTP; 1 Sep 2011 15:59:10 -0000 X-IronPort-AV: E=Sophos;i="4.68,313,1312156800"; d="scan'208";a="7558891" Received: from lonpmailmx01.citrite.net ([10.30.203.162]) by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5; 01 Sep 2011 15:59:10 +0000 Received: from woking.xci-test.com (10.80.248.135) by smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id 8.3.137.0; Thu, 1 Sep 2011 16:59:10 +0100 Received: from osstest by woking.xci-test.com with local (Exim 4.69) (envelope-from ) id 1Qz9fa-0006py-3f; Thu, 01 Sep 2011 16:59:10 +0100 To: xen-devel@lists.xensource.com Message-ID: From: xen.org Date: Thu, 1 Sep 2011 16:59:10 +0100 MIME-Version: 1.0 Content-Type: text/plain Cc: ian.jackson@eu.citrix.com Subject: [Xen-devel] [xen-unstable test] 8803: regressions - FAIL X-BeenThere: xen-devel@lists.xensource.com X-Mailman-Version: 2.1.5 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xensource.com Errors-To: xen-devel-bounces@lists.xensource.com flight 8803 xen-unstable real [real] http://www.chiark.greenend.org.uk/~xensrcts/logs/8803/ Regressions :-( Tests which did not succeed and are blocking: test-amd64-i386-rhel6hvm-intel 4 xen-install fail REGR. vs. 8769 test-amd64-i386-xl 4 xen-install fail REGR. vs. 8769 test-amd64-i386-pair 6 xen-install/dst_host fail REGR. vs. 8769 test-amd64-i386-pair 5 xen-install/src_host fail REGR. vs. 8769 test-amd64-i386-xl-credit2 4 xen-install fail REGR. vs. 8769 build-i386 4 xen-build fail REGR. vs. 8769 test-amd64-i386-pv 4 xen-install fail REGR. vs. 8769 build-i386-oldkern 4 xen-build fail REGR. vs. 8769 test-amd64-i386-xl-multivcpu 4 xen-install fail REGR. vs. 8769 test-amd64-i386-win-vcpus1 4 xen-install fail REGR. vs. 8769 test-amd64-i386-rhel6hvm-amd 4 xen-install fail REGR. vs. 8769 test-amd64-i386-win 4 xen-install fail REGR. vs. 8769 test-amd64-i386-xl-win-vcpus1 4 xen-install fail REGR. vs. 8769 Tests which did not succeed, but are not blocking, including regressions (tests previously passed) regarded as allowable: test-amd64-amd64-xl-pcipt-intel 9 guest-start fail never pass test-i386-i386-pv 1 xen-build-check(1) blocked n/a test-i386-i386-xl 1 xen-build-check(1) blocked n/a test-amd64-amd64-xl-sedf 11 guest-localmigrate fail like 8769 test-i386-i386-pair 1 xen-build-check(1) blocked n/a test-amd64-amd64-xl-win 13 guest-stop fail never pass test-i386-i386-win 1 xen-build-check(1) blocked n/a test-i386-i386-xl-win 1 xen-build-check(1) blocked n/a test-amd64-amd64-win 16 leak-check/check fail never pass version targeted for testing: xen 85b29185c911 baseline version: xen ac9aa65050e9 ------------------------------------------------------------ People who touched revisions under test: Andrew Cooper Christoph Egger Dietmar Hahn Ian Jackson Keir Fraser Kevin Tian Laszlo Ersek Olaf Hering Stefano Stabellini Tim Deegan ------------------------------------------------------------ jobs: build-amd64 pass build-i386 fail build-amd64-oldkern pass build-i386-oldkern fail build-amd64-pvops pass build-i386-pvops pass test-amd64-amd64-xl pass test-amd64-i386-xl fail test-i386-i386-xl blocked test-amd64-i386-rhel6hvm-amd fail test-amd64-i386-xl-credit2 fail test-amd64-amd64-xl-pcipt-intel fail test-amd64-i386-rhel6hvm-intel fail test-amd64-i386-xl-multivcpu fail test-amd64-amd64-pair pass test-amd64-i386-pair fail test-i386-i386-pair blocked test-amd64-amd64-pv pass test-amd64-i386-pv fail test-i386-i386-pv blocked test-amd64-amd64-xl-sedf fail test-amd64-i386-win-vcpus1 fail test-amd64-i386-xl-win-vcpus1 fail test-amd64-amd64-win fail test-amd64-i386-win fail test-i386-i386-win blocked test-amd64-amd64-xl-win fail test-i386-i386-xl-win blocked ------------------------------------------------------------ sg-report-flight on woking.cam.xci-test.com logs: /home/xc_osstest/logs images: /home/xc_osstest/images Logs, config files, etc. are available at http://www.chiark.greenend.org.uk/~xensrcts/logs Test harness code can be found at http://xenbits.xensource.com/gitweb?p=osstest.git;a=summary Not pushing. ------------------------------------------------------------ changeset: 23809:85b29185c911 tag: tip user: Tim Deegan date: Thu Sep 01 09:39:25 2011 +0100 x86/mm: use defines for page sizes rather hardcoding them. Signed-off-by: Christoph Egger Acked-by: Tim Deegan Committed-by: Tim Deegan changeset: 23808:4a4882df5649 user: Stefano Stabellini date: Wed Aug 31 15:23:49 2011 +0100 xen: get_free_pirq: make sure that the returned pirq is allocated Signed-off-by: Stefano Stabellini changeset: 23807:2297b90a6a7b user: Stefano Stabellini date: Wed Aug 31 15:23:34 2011 +0100 xen: __hvm_pci_intx_assert should check for gsis remapped onto pirqs If the isa irq corresponding to a particular gsi is disabled while the gsi is enabled, __hvm_pci_intx_assert will always inject the gsi through the violapic, even if the gsi has been remapped onto a pirq. This patch makes sure that even in this case we inject the notification appropriately. Signed-off-by: Stefano Stabellini changeset: 23806:4226ea1785b5 user: Stefano Stabellini date: Wed Aug 31 15:23:12 2011 +0100 xen: fix hvm_domain_use_pirq's behavior hvm_domain_use_pirq should return true when the guest is using a certain pirq, no matter if the corresponding event channel is currently enabled or disabled. As an additional complication, qemu is going to request pirqs for passthrough devices even for Xen unaware HVM guests, so we need to wait for an event channel to be connected before considering the pirq of a passthrough device as "in use". Signed-off-by: Stefano Stabellini changeset: 23805:7048810180de user: Andrew Cooper date: Wed Aug 31 15:19:24 2011 +0100 IRQ: manually EOI migrating line interrupts When migrating IO-APIC line level interrupts between PCPUs, the migration code rewrites the IO-APIC entry to point to the new CPU/Vector before EOI'ing it. The EOI process says that EOI'ing the Local APIC will cause a broadcast with the vector number, which the IO-APIC must listen to to clear the IRR and Status bits. In the case of migrating, the IO-APIC has already been reprogrammed so the EOI broadcast with the old vector fails to match the new vector, leaving the IO-APIC with an outstanding vector, preventing any more use of that line interrupt. This causes a lockup especially when your root device is using PCI INTA (megaraid_sas driver *ehem*) However, the problem is mostly hidden because send_cleanup_vector() causes a cleanup of all moving vectors on the current PCPU in such a way which does not cause the problem, and if the problem has occured, the writes it makes to the IO-APIC clears the IRR and Status bits which unlocks the problem. This fix is distinctly a temporary hack, waiting on a cleanup of the irq code. It checks for the edge case where we have moved the irq, and manually EOI's the old vector with the IO-APIC which correctly clears the IRR and Status bits. Also, it protects the code which updates irq_cfg by disabling interrupts. Signed-off-by: Andrew Cooper changeset: 23804:42d76c68b2bf user: Kevin Tian date: Wed Aug 31 15:18:23 2011 +0100 x86: add irq count for IPIs such count is useful to assist decision make in cpuidle governor, while w/o this patch only device interrupts through do_IRQ is currently counted. Signed-off-by: Kevin Tian changeset: 23803:51983821efa4 user: Dietmar Hahn date: Wed Aug 31 15:17:45 2011 +0100 vpmu: Add processors Westmere E7-8837 and SandyBridge i5-2500 to the vpmu list Signed-off-by: Dietmar Hahn changeset: 23802:bb9b81008733 user: Laszlo Ersek date: Wed Aug 31 15:16:14 2011 +0100 x86: Increase the default NR_CPUS to 256 Changeset 21012:ef845a385014 bumped the default to 128 about one and a half years ago. Increase it now to 256, as systems with eg. 160 logical CPUs are becoming (have become) common. Signed-off-by: Laszlo Ersek changeset: 23801:d54cfae72cd1 user: Christoph Egger date: Wed Aug 31 15:15:41 2011 +0100 nestedsvm: VMRUN doesn't use nextrip VMRUN does not use nextrip. So remove pointless assignment. Signed-off-by: Christoph Egger changeset: 23800:72edc40e2942 user: Keir Fraser date: Wed Aug 31 15:14:49 2011 +0100 x86-64: Fix off-by-one error in __addr_ok() macro Signed-off-by: Laszlo Ersek Signed-off-by: Keir Fraser changeset: 23799:ac9aa65050e9 parent: 23798:469aa1fbd843 parent: 23797:2c687e70a343 user: Ian Jackson date: Tue Aug 30 11:46:58 2011 +0100 Merge ======================================== commit cd776ee9408ff127f934a707c1a339ee600bc127 Author: Ian Jackson Date: Tue Jun 28 13:50:53 2011 +0100 qemu-char.c: fix incorrect CONFIG_STUBDOM handling qemu-char.c:1123:7: warning: "CONFIG_STUBDOM" is not defined [-Wundef] Signed-off-by: Olaf Hering Acked-by: Ian Jackson _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel From xen-devel-bounces@lists.xensource.com Thu Sep 01 09:09:06 2011 Return-path: Envelope-to: www-data@lists.xensource.com Delivery-date: Thu, 01 Sep 2011 09:09:06 -0700 Received: from localhost ([127.0.0.1] helo=lists.colo.xensource.com) by lists.xensource.com with esmtp (Exim 4.43) id 1Qz9pC-0007vs-00; Thu, 01 Sep 2011 09:09:06 -0700 Received: from mail174.messagelabs.com ([85.158.138.51]) by lists.xensource.com with esmtp (Exim 4.43) id 1Qz9o0-0007il-Nw for xen-devel@lists.xensource.com; Thu, 01 Sep 2011 09:07:58 -0700 X-Env-Sender: konrad@dumpdata.com X-Msg-Ref: server-2.tower-174.messagelabs.com!1314893266!29921090!1 X-Originating-IP: [148.87.113.117] X-StarScan-Version: 6.3.6; banners=-,-,- X-VirusChecked: Checked Received: (qmail 8715 invoked from network); 1 Sep 2011 16:07:47 -0000 Received: from rcsinet15.oracle.com (HELO rcsinet15.oracle.com) (148.87.113.117) by server-2.tower-174.messagelabs.com with DHE-RSA-AES256-SHA encrypted SMTP; 1 Sep 2011 16:07:47 -0000 Received: from acsinet22.oracle.com (acsinet22.oracle.com [141.146.126.238]) by rcsinet15.oracle.com (Switch-3.4.4/Switch-3.4.4) with ESMTP id p81G7aeK022890 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Thu, 1 Sep 2011 16:07:38 GMT Received: from acsmt356.oracle.com (acsmt356.oracle.com [141.146.40.156]) by acsinet22.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id p81G7XcN013803 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 1 Sep 2011 16:07:33 GMT Received: from abhmt114.oracle.com (abhmt114.oracle.com [141.146.116.66]) by acsmt356.oracle.com (8.12.11.20060308/8.12.11) with ESMTP id p81G7PLE010681; Thu, 1 Sep 2011 11:07:25 -0500 Received: from phenom (/209.6.55.207) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Thu, 01 Sep 2011 09:07:25 -0700 Received: by phenom (Postfix, from userid 1000) id EAF67FD1; Thu, 1 Sep 2011 12:07:22 -0400 (EDT) Date: Thu, 1 Sep 2011 12:07:22 -0400 From: Konrad Rzeszutek Wilk To: Ian Campbell Subject: Re: [Xen-devel] Kernel bug from 3.0 (was phy disks and vifs timing out in DomU) Message-ID: <20110901160722.GB8715@dumpdata.com> References: <4E56B132.9050708@overnetdata.com> <20110826142606.GA25511@dumpdata.com> <20110826144438.GA24836@dumpdata.com> <4E5E6843.7050206@citrix.com> <20110831170711.GB13642@dumpdata.com> <1314862972.28989.74.camel@zakaz.uk.xensource.com> <20110901142356.GD23971@dumpdata.com> <4E5FA0C4.7000806@citrix.com> <20110901153704.GB7506@dumpdata.com> <1314891785.28989.133.camel@zakaz.uk.xensource.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <1314891785.28989.133.camel@zakaz.uk.xensource.com> User-Agent: Mutt/1.5.21 (2010-09-15) X-Source-IP: acsinet22.oracle.com [141.146.126.238] X-Auth-Type: Internal IP X-CT-RefId: str=0001.0A090205.4E5FADCC.0041:SCFMA922111,ss=1,re=-4.000,fgs=0 Cc: Fitzhardinge , "xen-devel@lists.xensource.com" , Anthony Wright , "Jeremy@acsinet12.oracle.com" , David Vrabel , Todd Deshane X-BeenThere: xen-devel@lists.xensource.com X-Mailman-Version: 2.1.5 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xensource.com Errors-To: xen-devel-bounces@lists.xensource.com On Thu, Sep 01, 2011 at 04:43:05PM +0100, Ian Campbell wrote: > On Thu, 2011-09-01 at 16:37 +0100, Konrad Rzeszutek Wilk wrote: > > > >> vmalloc: remove vmalloc_sync_all() from alloc_vm_area() > > > >> > > > >> There's no need for it: it will get faulted into the current pagetable > > > >> as needed. > > > >> > > > >> Signed-off-by: Jeremy Fitzhardinge > > > >> > > > >> The flaw in the reasoning here is that you cannot take a kernel fault > > > >> while processing a hypercall, so hypercall arguments must have been > > > >> faulted in beforehand and that is what the sync_all was for. > > > >> > > > >> It's probably fair to say that the Xen specific caller should take care > > > >> of that Xen-specific requirement rather than pushing it into common > > > >> code. On the other hand Xen is the only user and creating a Xen specific > > > >> helper/wrapper seems a bit pointless. > > > > > > > > Perhaps then doing the vmalloc_sync_all() (or are more precise one: > > > > vmalloc_sync_one) should be employed in the netback code then? > > > > > > > > And obviously guarded by the CONFIG_HIGHMEM case? > > > > > > Perhaps. But I think the correct thing to do initially is revert the > > > change and then look at possible improvements. Particularly as the fix > > > needs to be a backported to stable. > > > > I disagree. Ian pointed out properly that this a Xen requirment - and there > > is no reason for us to slow down non-Xen runs with vmalloc_sync_all plucked in > > a generic path. > > There is literally no other caller of alloc_vm_area than xen so you > won't be slowing anyone else down. Duh! I totally missed that. Sounds plausible then - let me ping Andrew Morton on re-adding the vmalloc back. > > Maybe we should add alloc_vm_area_sync and use that everywhere? That is an option too. > > Ian. > > > > _______________________________________________ > Xen-devel mailing list > Xen-devel@lists.xensource.com > http://lists.xensource.com/xen-devel _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel From xen-devel-bounces@lists.xensource.com Thu Sep 01 09:13:15 2011 Return-path: Envelope-to: www-data@lists.xensource.com Delivery-date: Thu, 01 Sep 2011 09:13:15 -0700 Received: from localhost ([127.0.0.1] helo=lists.colo.xensource.com) by lists.xensource.com with esmtp (Exim 4.43) id 1Qz9tD-0008Lm-3P; Thu, 01 Sep 2011 09:13:15 -0700 Received: from mail216.messagelabs.com ([85.158.143.99]) by lists.xensource.com with esmtp (Exim 4.43) id 1Qz9sd-000899-Pv for xen-devel@lists.xensource.com; Thu, 01 Sep 2011 09:12:41 -0700 X-Env-Sender: konrad@dumpdata.com X-Msg-Ref: server-7.tower-216.messagelabs.com!1314893555!16750674!1 X-Originating-IP: [148.87.113.117] X-StarScan-Version: 6.3.6; banners=-,-,- X-VirusChecked: Checked Received: (qmail 8905 invoked from network); 1 Sep 2011 16:12:36 -0000 Received: from rcsinet15.oracle.com (HELO rcsinet15.oracle.com) (148.87.113.117) by server-7.tower-216.messagelabs.com with DHE-RSA-AES256-SHA encrypted SMTP; 1 Sep 2011 16:12:36 -0000 Received: from acsinet21.oracle.com (acsinet21.oracle.com [141.146.126.237]) by rcsinet15.oracle.com (Switch-3.4.4/Switch-3.4.4) with ESMTP id p81GBiU4030747 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Thu, 1 Sep 2011 16:11:46 GMT Received: from acsmt356.oracle.com (acsmt356.oracle.com [141.146.40.156]) by acsinet21.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id p81GBhT1015033 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 1 Sep 2011 16:11:44 GMT Received: from abhmt110.oracle.com (abhmt110.oracle.com [141.146.116.62]) by acsmt356.oracle.com (8.12.11.20060308/8.12.11) with ESMTP id p81GBbro013829; Thu, 1 Sep 2011 11:11:37 -0500 Received: from phenom (/209.6.55.207) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Thu, 01 Sep 2011 09:11:37 -0700 Received: by phenom (Postfix, from userid 1000) id 50A5AFD1; Thu, 1 Sep 2011 12:11:34 -0400 (EDT) Date: Thu, 1 Sep 2011 12:11:34 -0400 From: Konrad Rzeszutek Wilk To: David Vrabel , linux-kernel@vger.kernel.org, akpm@linux-foundation.org, namhyung@gmail.com, rientjes@google.com, linux-mm@kvack.org Message-ID: <20110901161134.GA8979@dumpdata.com> References: <1314877863-21977-1-git-send-email-david.vrabel@citrix.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <1314877863-21977-1-git-send-email-david.vrabel@citrix.com> User-Agent: Mutt/1.5.21 (2010-09-15) X-Source-IP: acsinet21.oracle.com [141.146.126.237] X-Auth-Type: Internal IP X-CT-RefId: str=0001.0A090201.4E5FAEC3.00C5:SCFMA922111,ss=1,re=-4.000,fgs=0 Cc: paulmck@linux.vnet.ibm.com, xen-devel@lists.xensource.com, Jeremy Fitzhardinge Subject: [Xen-devel] [Revert] Re: [PATCH] mm: sync vmalloc address space page tables in alloc_vm_area() X-BeenThere: xen-devel@lists.xensource.com X-Mailman-Version: 2.1.5 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xensource.com Errors-To: xen-devel-bounces@lists.xensource.com On Thu, Sep 01, 2011 at 12:51:03PM +0100, David Vrabel wrote: > From: David Vrabel Andrew, I was wondering if you would be Ok with this patch for 3.1. It is a revert (I can prepare a proper revert if you would like that instead of this patch). The users of this particular function (alloc_vm_area) are just Xen. There are no others. > > Xen backend drivers (e.g., blkback and netback) would sometimes fail > to map grant pages into the vmalloc address space allocated with > alloc_vm_area(). The GNTTABOP_map_grant_ref would fail because Xen > could not find the page (in the L2 table) containing the PTEs it > needed to update. > > (XEN) mm.c:3846:d0 Could not find L1 PTE for address fbb42000 > > netback and blkback were making the hypercall from a kernel thread > where task->active_mm != &init_mm and alloc_vm_area() was only > updating the page tables for init_mm. The usual method of deferring > the update to the page tables of other processes (i.e., after taking a > fault) doesn't work as a fault cannot occur during the hypercall. > > This would work on some systems depending on what else was using > vmalloc. > > Fix this by reverting ef691947d8a3d479e67652312783aedcf629320a > (vmalloc: remove vmalloc_sync_all() from alloc_vm_area()) and add a > comment to explain why it's needed. > > Signed-off-by: David Vrabel > Cc: Jeremy Fitzhardinge > --- > mm/vmalloc.c | 8 ++++++++ > 1 files changed, 8 insertions(+), 0 deletions(-) > > diff --git a/mm/vmalloc.c b/mm/vmalloc.c > index 7ef0903..5016f19 100644 > --- a/mm/vmalloc.c > +++ b/mm/vmalloc.c > @@ -2140,6 +2140,14 @@ struct vm_struct *alloc_vm_area(size_t size) > return NULL; > } > > + /* > + * If the allocated address space is passed to a hypercall > + * before being used then we cannot rely on a page fault to > + * trigger an update of the page tables. So sync all the page > + * tables here. > + */ > + vmalloc_sync_all(); > + > return area; > } > EXPORT_SYMBOL_GPL(alloc_vm_area); > -- > 1.7.2.5 _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel From xen-devel-bounces@lists.xensource.com Thu Sep 01 09:14:28 2011 Return-path: Envelope-to: www-data@lists.xensource.com Delivery-date: Thu, 01 Sep 2011 09:14:28 -0700 Received: from localhost ([127.0.0.1] helo=lists.colo.xensource.com) by lists.xensource.com with esmtp (Exim 4.43) id 1Qz9uO-0000HN-GX; Thu, 01 Sep 2011 09:14:28 -0700 Received: from mail216.messagelabs.com ([85.158.143.99]) by lists.xensource.com with smtp (Exim 4.43) id 1Qz9tR-0008R8-74 for xen-devel@lists.xensource.com; Thu, 01 Sep 2011 09:13:32 -0700 X-Env-Sender: tobias.geiger@vido.info X-Msg-Ref: server-6.tower-216.messagelabs.com!1314893605!15487991!1 X-Originating-IP: [78.47.43.171] X-StarScan-Version: 6.3.6; banners=-,-,- X-VirusChecked: Checked Received: (qmail 27504 invoked from network); 1 Sep 2011 16:13:26 -0000 Received: from www.vido.info (HELO mail.vido.info) (78.47.43.171) by server-6.tower-216.messagelabs.com with SMTP; 1 Sep 2011 16:13:26 -0000 Received: from localhost (ip6-localhost [127.0.0.1]) by mail.vido.info (Postfix) with ESMTP id 219E6D34833; Thu, 1 Sep 2011 18:13:25 +0200 (CEST) X-Virus-Scanned: by amavis at mail.vido.info Received: from mail.vido.info ([127.0.0.1]) by localhost (mail.vido.info [127.0.0.1]) (amavisd-new, port 10024) with LMTP id yOekHEkvFbF2; Thu, 1 Sep 2011 18:13:18 +0200 (CEST) Received: from lxgeigert.localnet (et-1-10.gw-nat.bs.kae.de.oneandone.net [212.227.35.74]) by mail.vido.info (Postfix) with ESMTPSA id 38355D34819; Thu, 1 Sep 2011 18:13:18 +0200 (CEST) From: Tobias Geiger Organization: VIDO IT-Service To: xen-devel@lists.xensource.com Subject: Re: [Xen-devel] Re: cs 23453:4f4970d2848d beaks Win 7 Date: Thu, 1 Sep 2011 18:13:16 +0200 User-Agent: KMail/1.13.7 (Linux/2.6.39-2-amd64; KDE/4.6.5; x86_64; ; ) References: <4E5F43F2.6010601@amd.com> <1314889505.28989.127.camel@zakaz.uk.xensource.com> <4E5FAB81.9060904@amd.com> In-Reply-To: <4E5FAB81.9060904@amd.com> MIME-Version: 1.0 Content-Type: Text/Plain; charset="utf-8" Content-Transfer-Encoding: 7bit Message-Id: <201109011813.17280.tobias.geiger@vido.info> Cc: Ian Campbell , Keir Fraser , Christoph Egger , Ian Jackson X-BeenThere: xen-devel@lists.xensource.com X-Mailman-Version: 2.1.5 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xensource.com Errors-To: xen-devel-bounces@lists.xensource.com +1 now the Devicemanager looks ok too. Thanks and Greetings Tobias Am Donnerstag, 1. September 2011, 17:57:53 schrieb Christoph Egger: > On 09/01/11 17:05, Ian Campbell wrote: > > The issue with 23453:4f4970d2848d is that it uses madt_csum_addr and > > madt_lapic0_addr to initialise bios_info before they have themselves > > been initialised. > > > > But in xen-unstable.hg tip everything has moved around and the issue now > > turns out to be that we clear the acpi_info struct _after_ we've setup > > the madt_* fields. Ooops! > > > > Thanks for reporting. > > > > Cheers, > > Ian. > > I successfully tested your patch with Windows 7 (both 32bit and 64bit). > Windows 7 can initialize its CPUs and no longer crashes on shutdown. > Thanks for fixing. Please apply the fix. > > Tested-and-acked-by: Christoph Egger > > Christoph > > > # HG changeset patch > > # User Ian Campbell > > # Date 1314889401 -3600 > > # Node ID bb97bd46df6c6d8562759a964ebf6c31b6361a7a > > # Parent 85b29185c9119ff9139596251d7bd13586853994 > > hvmloader: don't clear acpi_info after filling in some fields > > > > In particular the madt_lapic0_addr and madt_csum_addr fields are > > filled in while building the tables. > > > > This fixes a bluescreen on shutdown with certain versions of Windows. > > > > Signed-off-by: Ian Campbell > > Reported-by: Christoph Egger > > > > diff -r 85b29185c911 -r bb97bd46df6c > > tools/firmware/hvmloader/acpi/build.c --- > > a/tools/firmware/hvmloader/acpi/build.c Thu Sep 01 09:39:25 2011 +0100 > > +++ b/tools/firmware/hvmloader/acpi/build.c Thu Sep 01 16:03:21 2011 > > +0100 @@ -277,6 +277,8 @@ void acpi_build_tables(unsigned int phys > > > > unsigned long secondary_tables[16]; > > int nr_secondaries, i; > > > > + memset(acpi_info, 0, sizeof(*acpi_info)); > > + > > > > /* > > > > * Fill in high-memory data structures, starting at @buf. > > */ > > > > @@ -375,7 +377,6 @@ void acpi_build_tables(unsigned int phys > > > > offsetof(struct acpi_20_rsdp, extended_checksum), > > sizeof(struct acpi_20_rsdp)); > > > > - memset(acpi_info, 0, sizeof(*acpi_info)); > > > > acpi_info->com1_present = uart_exists(0x3f8); > > acpi_info->com2_present = uart_exists(0x2f8); > > acpi_info->lpt1_present = lpt_exists(0x378); _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel From xen-devel-bounces@lists.xensource.com Thu Sep 01 09:23:45 2011 Return-path: Envelope-to: www-data@lists.xensource.com Delivery-date: Thu, 01 Sep 2011 09:23:45 -0700 Received: from localhost ([127.0.0.1] helo=lists.colo.xensource.com) by lists.xensource.com with esmtp (Exim 4.43) id 1QzA3N-0000rN-KS; Thu, 01 Sep 2011 09:23:45 -0700 Received: from mail216.messagelabs.com ([85.158.143.99]) by lists.xensource.com with smtp (Exim 4.43) id 1QzA2w-0000fP-63 for xen-devel@lists.xensource.com; Thu, 01 Sep 2011 09:23:18 -0700 X-Env-Sender: Ian.Jackson@eu.citrix.com X-Msg-Ref: server-8.tower-216.messagelabs.com!1314894189!15289734!1 X-Originating-IP: [62.200.22.115] X-StarScan-Version: 6.3.6; banners=-,-,- X-VirusChecked: Checked Received: (qmail 20649 invoked from network); 1 Sep 2011 16:23:09 -0000 Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115) by server-8.tower-216.messagelabs.com with SMTP; 1 Sep 2011 16:23:09 -0000 X-IronPort-AV: E=Sophos;i="4.68,314,1312156800"; d="scan'208";a="7559382" Received: from lonpmailmx01.citrite.net ([10.30.203.162]) by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5; 01 Sep 2011 16:23:09 +0000 Received: from norwich.cam.xci-test.com (10.80.248.129) by smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id 8.3.137.0; Thu, 1 Sep 2011 17:23:09 +0100 Received: from mariner.cam.xci-test.com ([10.80.2.22] helo=mariner.uk.xensource.com ident=Debian-exim) by norwich.cam.xci-test.com with esmtp (Exim 4.72) (envelope-from ) id 1QzA2n-0006Z6-A1 for xen-devel@lists.xensource.com; Thu, 01 Sep 2011 16:23:09 +0000 Received: from iwj by mariner.uk.xensource.com with local (Exim 4.69) (envelope-from ) id 1QzA2n-0007T8-90 for xen-devel@lists.xensource.com; Thu, 01 Sep 2011 17:23:09 +0100 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Message-ID: <20063.45421.271505.189374@mariner.uk.xensource.com> Date: Thu, 1 Sep 2011 17:23:09 +0100 To: "xen-devel@lists.xensource.com" In-Reply-To: References: X-Mailer: VM 8.0.9 under Emacs 21.4.1 (i486-pc-linux-gnu) From: Ian Jackson Subject: [Xen-devel] Re: [xen-unstable test] 8803: regressions - FAIL X-BeenThere: xen-devel@lists.xensource.com X-Mailman-Version: 2.1.5 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xensource.com Errors-To: xen-devel-bounces@lists.xensource.com ~xen.org writes ("[xen-unstable test] 8803: regressions - FAIL"): > flight 8803 xen-unstable real [real] > http://www.chiark.greenend.org.uk/~xensrcts/logs/8803/ > build-i386 4 xen-build fail REGR. vs. 8769 gcc -O1 -fno-omit-frame-pointer -m32 -march=i686 -g -fno-strict-aliasing -std=gnu99 -Wall -Wstrict-prototypes -Wno-unused-value -Wdeclaration-after- statement -fno-builtin -fno-common -Wredundant-decls -iwithprefix include -Werror -Wno-pointer-arith -pipe -I/home/osstest/build.8803.build-i386/xe n-unstable/xen/include -I/home/osstest/build.8803.build-i386/xen-unstable/xen/include/asm-x86/mach-generic -I/home/osstest/build.8803.build-i386/xe n-unstable/xen/include/asm-x86/mach-default -msoft-float -fno-stack-protector -fno-exceptions -Wnested-externs -fno-optimize-sibling-calls -nostdinc -g -D__XEN__ -DVERBOSE -fno-omit-frame-pointer -DCONFIG_FRAME_POINTER -MMD -MF .domain_page.o.d -c domain_page.c -o domain_page.o domain_page.c: In function 'map_domain_page_global': domain_page.c:211: error: negative width in bit-field '' make[5]: *** [domain_page.o] Error 1 make[5]: Leaving directory `/home/osstest/build.8803.build-i386/xen-unstable/xen/arch/x86/x86_32' make[4]: *** [x86_32/built_in.o] Error 2 Ian. _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel From xen-devel-bounces@lists.xensource.com Thu Sep 01 09:27:06 2011 Return-path: Envelope-to: www-data@lists.xensource.com Delivery-date: Thu, 01 Sep 2011 09:27:06 -0700 Received: from localhost ([127.0.0.1] helo=lists.colo.xensource.com) by lists.xensource.com with esmtp (Exim 4.43) id 1QzA6b-0001Gw-57; Thu, 01 Sep 2011 09:27:05 -0700 Received: from mail27.messagelabs.com ([193.109.254.147]) by lists.xensource.com with smtp (Exim 4.43) id 1QzA6B-00014O-6k for xen-devel@lists.xensource.com; Thu, 01 Sep 2011 09:26:39 -0700 X-Env-Sender: Ian.Jackson@eu.citrix.com X-Msg-Ref: server-2.tower-27.messagelabs.com!1314894374!53232498!1 X-Originating-IP: [62.200.22.115] X-StarScan-Version: 6.3.6; banners=-,-,- X-VirusChecked: Checked Received: (qmail 24190 invoked from network); 1 Sep 2011 16:26:14 -0000 Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115) by server-2.tower-27.messagelabs.com with SMTP; 1 Sep 2011 16:26:14 -0000 X-IronPort-AV: E=Sophos;i="4.68,314,1312156800"; d="scan'208";a="7559436" Received: from lonpmailmx01.citrite.net ([10.30.203.162]) by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5; 01 Sep 2011 16:26:15 +0000 Received: from norwich.cam.xci-test.com (10.80.248.129) by smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id 8.3.137.0; Thu, 1 Sep 2011 17:26:15 +0100 Received: from mariner.cam.xci-test.com ([10.80.2.22] helo=mariner.uk.xensource.com ident=Debian-exim) by norwich.cam.xci-test.com with esmtp (Exim 4.72) (envelope-from ) id 1QzA5n-0006a0-Ez; Thu, 01 Sep 2011 16:26:15 +0000 Received: from iwj by mariner.uk.xensource.com with local (Exim 4.69) (envelope-from ) id 1QzA5n-0007TV-DQ; Thu, 01 Sep 2011 17:26:15 +0100 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Message-ID: <20063.45607.355820.209628@mariner.uk.xensource.com> Date: Thu, 1 Sep 2011 17:26:15 +0100 To: , Laszlo Ersek Subject: Re: [Xen-devel] [xen-unstable bisection] complete test-amd64-i386-rhel6hvm-intel Newsgroups: chiark.mail.xen.devel In-Reply-To: References: X-Mailer: VM 8.0.9 under Emacs 21.4.1 (i486-pc-linux-gnu) From: Ian Jackson Cc: keir@xen.org, stefano.stabellini@eu.citrix.com X-BeenThere: xen-devel@lists.xensource.com X-Mailman-Version: 2.1.5 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xensource.com Errors-To: xen-devel-bounces@lists.xensource.com xen.org writes ("[Xen-devel] [xen-unstable bisection] complete test-amd64-i386-rhel6hvm-intel"): > branch xen-unstable > xen branch xen-unstable > job test-amd64-i386-rhel6hvm-intel > test xen-install > > Tree: linux git://git.eu.kernel.org/pub/scm/linux/kernel/git/jeremy/xen.git > Tree: qemu git://hg.uk.xensource.com/HG/qemu-xen-unstable.git > Tree: xen http://hg.uk.xensource.com/xen-unstable.hg > > *** Found and reproduced problem changeset *** > > Bug is in tree: xen http://hg.uk.xensource.com/xen-unstable.hg > Bug introduced: bb9b81008733 > Bug not present: d54cfae72cd1 > > > changeset: 23802:bb9b81008733 > user: Laszlo Ersek > date: Wed Aug 31 15:16:14 2011 +0100 > > x86: Increase the default NR_CPUS to 256 > > Changeset 21012:ef845a385014 bumped the default to 128 about one and a > half years ago. Increase it now to 256, as systems with eg. 160 > logical CPUs are becoming (have become) common. > > Signed-off-by: Laszlo Ersek My bisector is pretty reliable nowadays. Looking at the revision graph it tested before/after/before/after/before/after, ie three times each on the same host. This change looks innocuous enough TBH. Is there any way this change could have broken a PV-on-HVM guest ? Note that RHEL6, which is what this is testing, seems to generally be full of bugs. If the problem is indeed a bug in the current RHEL6 then I will add this test to the "do not care" list. Ian. _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel From xen-devel-bounces@lists.xensource.com Thu Sep 01 09:28:18 2011 Return-path: Envelope-to: www-data@lists.xensource.com Delivery-date: Thu, 01 Sep 2011 09:28:18 -0700 Received: from localhost ([127.0.0.1] helo=lists.colo.xensource.com) by lists.xensource.com with esmtp (Exim 4.43) id 1QzA7m-0001eQ-3p; Thu, 01 Sep 2011 09:28:18 -0700 Received: from mail182.messagelabs.com ([85.158.139.83]) by lists.xensource.com with smtp (Exim 4.43) id 1QzA7K-0001RX-Mo for xen-devel@lists.xensource.com; Thu, 01 Sep 2011 09:27:51 -0700 X-Env-Sender: dgdegra@tycho.nsa.gov X-Msg-Ref: server-5.tower-182.messagelabs.com!1314894466!11726160!1 X-Originating-IP: [63.239.65.39] X-StarScan-Version: 6.3.6; banners=-,-,- X-VirusChecked: Checked Received: (qmail 14391 invoked from network); 1 Sep 2011 16:27:47 -0000 Received: from msux-gh1-uea01.nsa.gov (HELO msux-gh1-uea01.nsa.gov) (63.239.65.39) by server-5.tower-182.messagelabs.com with SMTP; 1 Sep 2011 16:27:47 -0000 Received: from tarius.tycho.ncsc.mil (localhost [127.0.0.1]) by msux-gh1-uea01.nsa.gov (8.12.10/8.12.10) with ESMTP id p81GRiMm003598; Thu, 1 Sep 2011 16:27:44 GMT Received: from moss-nexus.epoch.ncsc.mil (moss-nexus [144.51.25.48]) by tarius.tycho.ncsc.mil (8.13.1/8.13.1) with ESMTP id p81GRiC4009262; Thu, 1 Sep 2011 12:27:44 -0400 From: Daniel De Graaf To: xen-devel@lists.xensource.com Date: Thu, 1 Sep 2011 12:22:15 -0400 Message-Id: <1314894138-28747-1-git-send-email-dgdegra@tycho.nsa.gov> X-Mailer: git-send-email 1.7.6 In-Reply-To: <1313764724-12683-1-git-send-email-dgdegra@tycho.nsa.gov> References: <1313764724-12683-1-git-send-email-dgdegra@tycho.nsa.gov> Cc: Ian.Campbell@eu.citrix.com, konrad.wilk@oracle.com, Ian.Jackson@eu.citrix.com, Stefano.Stabellini@eu.citrix.com Subject: [Xen-devel] [PATCH v4 0/3] libvchan: interdomain communications library X-BeenThere: xen-devel@lists.xensource.com X-Mailman-Version: 2.1.5 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xensource.com Errors-To: xen-devel-bounces@lists.xensource.com Changes since v3: - libxc integration - use of .opic for .so build instead of forcing -fPIC - change library name to "libxenvchan" - relicense to LGPL - change xenstore path to include both client and server domid - avoid sending unneeded event channel notifications [PATCH 1/3] libxc: add xc_gnttab_map_grant_ref_notify [PATCH 2/3] libxc: add xc_gntshr_* functions [PATCH 3/3] libvchan: interdomain communications library _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel From xen-devel-bounces@lists.xensource.com Thu Sep 01 09:29:05 2011 Return-path: Envelope-to: www-data@lists.xensource.com Delivery-date: Thu, 01 Sep 2011 09:29:05 -0700 Received: from localhost ([127.0.0.1] helo=lists.colo.xensource.com) by lists.xensource.com with esmtp (Exim 4.43) id 1QzA8X-00021D-84; Thu, 01 Sep 2011 09:29:05 -0700 Received: from mail216.messagelabs.com ([85.158.143.99]) by lists.xensource.com with smtp (Exim 4.43) id 1QzA7K-0001RV-DD for xen-devel@lists.xensource.com; Thu, 01 Sep 2011 09:27:51 -0700 X-Env-Sender: dgdegra@tycho.nsa.gov X-Msg-Ref: server-9.tower-216.messagelabs.com!1314894466!16761627!1 X-Originating-IP: [63.239.65.39] X-StarScan-Version: 6.3.6; banners=-,-,- X-VirusChecked: Checked Received: (qmail 30984 invoked from network); 1 Sep 2011 16:27:47 -0000 Received: from msux-gh1-uea01.nsa.gov (HELO msux-gh1-uea01.nsa.gov) (63.239.65.39) by server-9.tower-216.messagelabs.com with SMTP; 1 Sep 2011 16:27:47 -0000 Received: from tarius.tycho.ncsc.mil (localhost [127.0.0.1]) by msux-gh1-uea01.nsa.gov (8.12.10/8.12.10) with ESMTP id p81GRiMm003599; Thu, 1 Sep 2011 16:27:44 GMT Received: from moss-nexus.epoch.ncsc.mil (moss-nexus [144.51.25.48]) by tarius.tycho.ncsc.mil (8.13.1/8.13.1) with ESMTP id p81GRiC6009262; Thu, 1 Sep 2011 12:27:44 -0400 From: Daniel De Graaf To: xen-devel@lists.xensource.com Date: Thu, 1 Sep 2011 12:22:17 -0400 Message-Id: <1314894138-28747-3-git-send-email-dgdegra@tycho.nsa.gov> X-Mailer: git-send-email 1.7.6 In-Reply-To: <1314894138-28747-1-git-send-email-dgdegra@tycho.nsa.gov> References: <1313764724-12683-1-git-send-email-dgdegra@tycho.nsa.gov> <1314894138-28747-1-git-send-email-dgdegra@tycho.nsa.gov> Cc: Ian.Campbell@eu.citrix.com, Daniel De Graaf , konrad.wilk@oracle.com, Ian.Jackson@eu.citrix.com, Stefano.Stabellini@eu.citrix.com Subject: [Xen-devel] [PATCH 2/3] libxc: add xc_gntshr_* functions X-BeenThere: xen-devel@lists.xensource.com X-Mailman-Version: 2.1.5 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xensource.com Errors-To: xen-devel-bounces@lists.xensource.com These functions and the xc_gntshr device (/dev/xen/gntalloc on linux) allow applications to create pages shared with other domains. Signed-off-by: Daniel De Graaf --- tools/libxc/xc_gnttab.c | 27 +++++++++ tools/libxc/xc_linux_osdep.c | 121 ++++++++++++++++++++++++++++++++++++++++++ tools/libxc/xc_private.c | 13 +++++ tools/libxc/xenctrl.h | 48 +++++++++++++++++ tools/libxc/xenctrlosdep.h | 13 +++++ 5 files changed, 222 insertions(+), 0 deletions(-) diff --git a/tools/libxc/xc_gnttab.c b/tools/libxc/xc_gnttab.c index dc7aa0c..ffa3550 100644 --- a/tools/libxc/xc_gnttab.c +++ b/tools/libxc/xc_gnttab.c @@ -204,6 +204,33 @@ int xc_gnttab_set_max_grants(xc_gnttab *xcg, uint32_t count) return xcg->ops->u.gnttab.set_max_grants(xcg, xcg->ops_handle, count); } +void *xc_gntshr_share_pages(xc_gntshr *xcg, uint32_t domid, + int count, uint32_t *refs, int writable) +{ + return xcg->ops->u.gntshr.share_pages(xcg, xcg->ops_handle, domid, + count, refs, writable); +} + +void *xc_gntshr_share_page_notify(xc_gntshr *xcg, uint32_t domid, + uint32_t *ref, int writable, + uint32_t notify_offset, + evtchn_port_t notify_port) +{ + return xcg->ops->u.gntshr.share_page_notify(xcg, xcg->ops_handle, + domid, ref, writable, notify_offset, notify_port); +} + +/* + * Unmaps the @count pages starting at @start_address, which were mapped by a + * call to xc_gntshr_share_*. Never logs. + */ +int xc_gntshr_munmap(xc_gntshr *xcg, void *start_address, uint32_t count) +{ + return xcg->ops->u.gntshr.munmap(xcg, xcg->ops_handle, + start_address, count); +} + + /* * Local variables: * mode: C diff --git a/tools/libxc/xc_linux_osdep.c b/tools/libxc/xc_linux_osdep.c index 8f7718f..871d37c 100644 --- a/tools/libxc/xc_linux_osdep.c +++ b/tools/libxc/xc_linux_osdep.c @@ -34,6 +34,7 @@ #include #include #include +#include #include "xenctrl.h" #include "xenctrlosdep.h" @@ -718,6 +719,124 @@ static struct xc_osdep_ops linux_gnttab_ops = { }, }; +static xc_osdep_handle linux_gntshr_open(xc_gntshr *xcg) +{ + int fd = open(DEVXEN "gntalloc", O_RDWR); + + if ( fd == -1 ) + return XC_OSDEP_OPEN_ERROR; + + return (xc_osdep_handle)fd; +} + +static int linux_gntshr_close(xc_gntshr *xcg, xc_osdep_handle h) +{ + int fd = (int)h; + return close(fd); +} + +static void *linux_gntshr_share_pages(xc_gntshr *xch, xc_osdep_handle h, + uint32_t domid, int count, + uint32_t *refs, int writable) +{ + struct ioctl_gntalloc_alloc_gref *gref_info = NULL; + int err; + void *area = NULL; + gref_info = malloc(sizeof(*gref_info) + count * sizeof(uint32_t)); + if (!gref_info) + return NULL; + gref_info->domid = domid; + gref_info->flags = writable ? GNTALLOC_FLAG_WRITABLE : 0; + gref_info->count = count; + + err = ioctl((int)h, IOCTL_GNTALLOC_ALLOC_GREF, gref_info); + if (err) { + PERROR("linux_gntshr_share_pages: ioctl failed"); + goto out; + } + + area = mmap(NULL, count * XC_PAGE_SIZE, PROT_READ | PROT_WRITE, + MAP_SHARED, (int)h, gref_info->index); + + if (area == MAP_FAILED) { + area = NULL; + PERROR("linux_gntshr_share_pages: mmap failed"); + goto out; + } + + memcpy(refs, gref_info->gref_ids, count * sizeof(uint32_t)); + out: + free(gref_info); + return area; +} + +static void *linux_gntshr_share_page_notify(xc_gntshr *xch, xc_osdep_handle h, + uint32_t domid, uint32_t *ref, + int writable, uint32_t notify_offset, + evtchn_port_t notify_port) +{ + struct ioctl_gntalloc_alloc_gref gref_info; + struct ioctl_gntalloc_unmap_notify notify; + int err; + int fd = (int)h; + void *area = NULL; + gref_info.domid = domid; + gref_info.flags = writable ? GNTALLOC_FLAG_WRITABLE : 0; + gref_info.count = 1; + + err = ioctl(fd, IOCTL_GNTALLOC_ALLOC_GREF, &gref_info); + if (err) { + PERROR("linux_gntshr_share_page_notify: ioctl failed"); + goto out; + } + + area = mmap(NULL, XC_PAGE_SIZE, PROT_READ | PROT_WRITE, + MAP_SHARED, fd, gref_info.index); + + if (area == MAP_FAILED) { + PERROR("linux_gntshr_share_page_notify: mmap failed"); + area = NULL; + goto out; + } + + notify.index = gref_info.index; + notify.action = 0; + if (notify_offset >= 0) { + notify.index += notify_offset; + notify.action |= UNMAP_NOTIFY_CLEAR_BYTE; + } + if (notify_port >= 0) { + notify.event_channel_port = notify_port; + notify.action |= UNMAP_NOTIFY_SEND_EVENT; + } + if (notify.action && ioctl(fd, IOCTL_GNTALLOC_SET_UNMAP_NOTIFY, ¬ify)) { + PERROR("linux_gntshr_share_page_notify: ioctl SET_UNMAP_NOTIFY failed"); + } + + *ref = gref_info.gref_ids[0]; + out: + return area; +} + + +static int linux_gntshr_munmap(xc_gntshr *xcg, xc_osdep_handle h, + void *start_address, uint32_t count) +{ + return munmap(start_address, count); +} + +static struct xc_osdep_ops linux_gntshr_ops = { + .open = &linux_gntshr_open, + .close = &linux_gntshr_close, + + .u.gntshr = { + .share_pages = &linux_gntshr_share_pages, + .share_page_notify = &linux_gntshr_share_page_notify, + .munmap = &linux_gntshr_munmap, + }, +}; + + static struct xc_osdep_ops *linux_osdep_init(xc_interface *xch, enum xc_osdep_type type) { switch ( type ) @@ -728,6 +847,8 @@ static struct xc_osdep_ops *linux_osdep_init(xc_interface *xch, enum xc_osdep_ty return &linux_evtchn_ops; case XC_OSDEP_GNTTAB: return &linux_gnttab_ops; + case XC_OSDEP_GNTSHR: + return &linux_gntshr_ops; default: return NULL; } diff --git a/tools/libxc/xc_private.c b/tools/libxc/xc_private.c index 09c8f23..09a91e7 100644 --- a/tools/libxc/xc_private.c +++ b/tools/libxc/xc_private.c @@ -258,6 +258,19 @@ int xc_gnttab_close(xc_gnttab *xcg) return xc_interface_close_common(xcg); } +xc_gntshr *xc_gntshr_open(xentoollog_logger *logger, + unsigned open_flags) +{ + return xc_interface_open_common(logger, NULL, open_flags, + XC_OSDEP_GNTSHR); +} + +int xc_gntshr_close(xc_gntshr *xcg) +{ + return xc_interface_close_common(xcg); +} + + static pthread_key_t errbuf_pkey; static pthread_once_t errbuf_pkey_once = PTHREAD_ONCE_INIT; diff --git a/tools/libxc/xenctrl.h b/tools/libxc/xenctrl.h index 7859571..374c705 100644 --- a/tools/libxc/xenctrl.h +++ b/tools/libxc/xenctrl.h @@ -115,6 +115,7 @@ typedef struct xc_interface_core xc_interface; typedef struct xc_interface_core xc_evtchn; typedef struct xc_interface_core xc_gnttab; +typedef struct xc_interface_core xc_gntshr; typedef enum xc_error_code xc_error_code; @@ -1400,6 +1401,53 @@ grant_entry_v1_t *xc_gnttab_map_table_v1(xc_interface *xch, int domid, int *gnt_ grant_entry_v2_t *xc_gnttab_map_table_v2(xc_interface *xch, int domid, int *gnt_num); /* Sometimes these don't set errno [fixme], and sometimes they don't log. */ +/* + * Return an fd onto the grant sharing driver. Logs errors. + */ +xc_gntshr *xc_gntshr_open(xentoollog_logger *logger, + unsigned open_flags); + +/* + * Close a handle previously allocated with xc_gntshr_open(). + * Never logs errors. + */ +int xc_gntshr_close(xc_gntshr *xcg); + +/* + * Creates and shares pages with another domain. + * + * @parm xcg a handle to an open grant sharing instance + * @parm domid the domain to share memory with + * @parm count the number of pages to share + * @parm refs the grant references of the pages (output) + * @parm writable true if the other domain can write to the pages + * @return local mapping of the pages + */ +void *xc_gntshr_share_pages(xc_gntshr *xcg, uint32_t domid, + int count, uint32_t *refs, int writable); + +/* + * Creates and shares a page with another domain, with unmap notification. + * + * @parm xcg a handle to an open grant sharing instance + * @parm domid the domain to share memory with + * @parm refs the grant reference of the pages (output) + * @parm writable true if the other domain can write to the page + * @parm notify_offset The byte offset in the page to use for unmap + * notification; -1 for none. + * @parm notify_port The event channel port to use for unmap notify, or -1 + * @return local mapping of the page + */ +void *xc_gntshr_share_page_notify(xc_gntshr *xcg, uint32_t domid, + uint32_t *ref, int writable, + uint32_t notify_offset, + evtchn_port_t notify_port); +/* + * Unmaps the @count pages starting at @start_address, which were mapped by a + * call to xc_gntshr_share_*. Never logs. + */ +int xc_gntshr_munmap(xc_gntshr *xcg, void *start_address, uint32_t count); + int xc_physdev_map_pirq(xc_interface *xch, int domid, int index, diff --git a/tools/libxc/xenctrlosdep.h b/tools/libxc/xenctrlosdep.h index 01969c5..e1c1ba5 100644 --- a/tools/libxc/xenctrlosdep.h +++ b/tools/libxc/xenctrlosdep.h @@ -54,6 +54,7 @@ enum xc_osdep_type { XC_OSDEP_PRIVCMD, XC_OSDEP_EVTCHN, XC_OSDEP_GNTTAB, + XC_OSDEP_GNTSHR, }; /* Opaque handle internal to the backend */ @@ -129,6 +130,18 @@ struct xc_osdep_ops uint32_t count); int (*set_max_grants)(xc_gnttab *xcg, xc_osdep_handle h, uint32_t count); } gnttab; + struct { + void *(*share_pages)(xc_gntshr *xcg, xc_osdep_handle h, + uint32_t domid, int count, + uint32_t *refs, int writable); + void *(*share_page_notify)(xc_gntshr *xcg, xc_osdep_handle h, + uint32_t domid, + uint32_t *ref, int writable, + uint32_t notify_offset, + evtchn_port_t notify_port); + int (*munmap)(xc_gntshr *xcg, xc_osdep_handle h, + void *start_address, uint32_t count); + } gntshr; } u; }; typedef struct xc_osdep_ops xc_osdep_ops; -- 1.7.6 _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel From xen-devel-bounces@lists.xensource.com Thu Sep 01 09:30:08 2011 Return-path: Envelope-to: www-data@lists.xensource.com Delivery-date: Thu, 01 Sep 2011 09:30:08 -0700 Received: from localhost ([127.0.0.1] helo=lists.colo.xensource.com) by lists.xensource.com with esmtp (Exim 4.43) id 1QzA9Y-0002Om-OE; Thu, 01 Sep 2011 09:30:08 -0700 Received: from mail174.messagelabs.com ([85.158.138.51]) by lists.xensource.com with smtp (Exim 4.43) id 1QzA7K-0001RW-Mb for xen-devel@lists.xensource.com; Thu, 01 Sep 2011 09:27:52 -0700 X-Env-Sender: dgdegra@tycho.nsa.gov X-Msg-Ref: server-14.tower-174.messagelabs.com!1314894466!29920393!1 X-Originating-IP: [63.239.65.40] X-StarScan-Version: 6.3.6; banners=-,-,- X-VirusChecked: Checked Received: (qmail 30711 invoked from network); 1 Sep 2011 16:27:47 -0000 Received: from msux-gh1-uea02.nsa.gov (HELO msux-gh1-uea02.nsa.gov) (63.239.65.40) by server-14.tower-174.messagelabs.com with SMTP; 1 Sep 2011 16:27:47 -0000 Received: from tarius.tycho.ncsc.mil (localhost [127.0.0.1]) by msux-gh1-uea02.nsa.gov (8.12.10/8.12.10) with ESMTP id p81GRi6U013460; Thu, 1 Sep 2011 16:27:44 GMT Received: from moss-nexus.epoch.ncsc.mil (moss-nexus [144.51.25.48]) by tarius.tycho.ncsc.mil (8.13.1/8.13.1) with ESMTP id p81GRiC5009262; Thu, 1 Sep 2011 12:27:44 -0400 From: Daniel De Graaf To: xen-devel@lists.xensource.com Date: Thu, 1 Sep 2011 12:22:16 -0400 Message-Id: <1314894138-28747-2-git-send-email-dgdegra@tycho.nsa.gov> X-Mailer: git-send-email 1.7.6 In-Reply-To: <1314894138-28747-1-git-send-email-dgdegra@tycho.nsa.gov> References: <1313764724-12683-1-git-send-email-dgdegra@tycho.nsa.gov> <1314894138-28747-1-git-send-email-dgdegra@tycho.nsa.gov> Cc: Ian.Campbell@eu.citrix.com, Daniel De Graaf , konrad.wilk@oracle.com, Ian.Jackson@eu.citrix.com, Stefano.Stabellini@eu.citrix.com Subject: [Xen-devel] [PATCH 1/3] libxc: add xc_gnttab_map_grant_ref_notify X-BeenThere: xen-devel@lists.xensource.com X-Mailman-Version: 2.1.5 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xensource.com Errors-To: xen-devel-bounces@lists.xensource.com Normally, when a userspace process mapping a grant crashes, the domain providing the reference receives no indication that its peer has crashed, possibly leading to unexpected freezes or timeouts. This function provides a notification of the unmap by signalling an event channel and/or clearing a specific byte in the page. Signed-off-by: Daniel De Graaf --- tools/libxc/xc_gnttab.c | 15 ++++++++++++ tools/libxc/xc_linux_osdep.c | 52 ++++++++++++++++++++++++++++++++++++++++++ tools/libxc/xenctrl.h | 21 +++++++++++++++++ tools/libxc/xenctrlosdep.h | 5 ++++ 4 files changed, 93 insertions(+), 0 deletions(-) diff --git a/tools/libxc/xc_gnttab.c b/tools/libxc/xc_gnttab.c index 4f55fce..dc7aa0c 100644 --- a/tools/libxc/xc_gnttab.c +++ b/tools/libxc/xc_gnttab.c @@ -174,6 +174,21 @@ void *xc_gnttab_map_domain_grant_refs(xc_gnttab *xcg, count, domid, refs, prot); } +void *xc_gnttab_map_grant_ref_notify(xc_gnttab *xcg, + uint32_t domid, + uint32_t ref, + uint32_t notify_offset, + evtchn_port_t notify_port) +{ + if (xcg->ops->u.gnttab.map_grant_ref_notify) + return xcg->ops->u.gnttab.map_grant_ref_notify(xcg, xcg->ops_handle, + domid, ref, notify_offset, notify_port); + else + return xcg->ops->u.gnttab.map_grant_ref(xcg, xcg->ops_handle, + domid, ref, PROT_READ|PROT_WRITE); +} + + int xc_gnttab_munmap(xc_gnttab *xcg, void *start_address, uint32_t count) diff --git a/tools/libxc/xc_linux_osdep.c b/tools/libxc/xc_linux_osdep.c index dca6718..8f7718f 100644 --- a/tools/libxc/xc_linux_osdep.c +++ b/tools/libxc/xc_linux_osdep.c @@ -613,6 +613,57 @@ static void *linux_gnttab_map_domain_grant_refs(xc_gnttab *xcg, xc_osdep_handle return do_gnttab_map_grant_refs(xcg, h, count, &domid, 0, refs, prot); } +static void *linux_gnttab_map_grant_ref_notify(xc_gnttab *xch, xc_osdep_handle h, + uint32_t domid, uint32_t ref, + uint32_t notify_offset, + evtchn_port_t notify_port) +{ + int fd = (int)h; + struct ioctl_gntdev_map_grant_ref map; + struct ioctl_gntdev_unmap_notify notify; + void *addr; + + map.count = 1; + map.refs[0].domid = domid; + map.refs[0].ref = ref; + + if ( ioctl(fd, IOCTL_GNTDEV_MAP_GRANT_REF, &map) ) { + PERROR("xc_gnttab_map_grant_ref: ioctl MAP_GRANT_REF failed"); + return NULL; + } + + addr = mmap(NULL, XC_PAGE_SIZE, PROT_READ|PROT_WRITE, MAP_SHARED, fd, map.index); + if ( addr == MAP_FAILED ) + { + int saved_errno = errno; + struct ioctl_gntdev_unmap_grant_ref unmap_grant; + + PERROR("xc_gnttab_map_grant_ref: mmap failed"); + unmap_grant.index = map.index; + unmap_grant.count = 1; + ioctl(fd, IOCTL_GNTDEV_UNMAP_GRANT_REF, &unmap_grant); + errno = saved_errno; + return NULL; + } + + notify.index = map.index; + notify.action = 0; + if (notify_offset >= 0) { + notify.index += notify_offset; + notify.action |= UNMAP_NOTIFY_CLEAR_BYTE; + } + if (notify_port >= 0) { + notify.event_channel_port = notify_port; + notify.action |= UNMAP_NOTIFY_SEND_EVENT; + } + if (notify.action && ioctl(fd, IOCTL_GNTDEV_SET_UNMAP_NOTIFY, ¬ify)) { + PERROR("linux_gnttab_map_grant_ref_notify: ioctl SET_UNMAP_NOTIFY failed"); + } + + return addr; +} + + static int linux_gnttab_munmap(xc_gnttab *xcg, xc_osdep_handle h, void *start_address, uint32_t count) { @@ -662,6 +713,7 @@ static struct xc_osdep_ops linux_gnttab_ops = { .map_grant_ref = &linux_gnttab_map_grant_ref, .map_grant_refs = &linux_gnttab_map_grant_refs, .map_domain_grant_refs = &linux_gnttab_map_domain_grant_refs, + .map_grant_ref_notify = &linux_gnttab_map_grant_ref_notify, .munmap = &linux_gnttab_munmap, }, }; diff --git a/tools/libxc/xenctrl.h b/tools/libxc/xenctrl.h index 1b82ee0..7859571 100644 --- a/tools/libxc/xenctrl.h +++ b/tools/libxc/xenctrl.h @@ -1349,6 +1349,27 @@ void *xc_gnttab_map_domain_grant_refs(xc_gnttab *xcg, int prot); /* + * Memory maps a grant reference from one domain to a local address range. + * Mappings should be unmapped with xc_gnttab_munmap. Logs errors. + * This version always maps writable pages, and will attempt to set up + * an unmap notification at the given offset and event channel. When the + * page is unmapped, the byte at the given offset will be zeroed and a + * wakeup will be sent to the given event channel. + * + * @parm xcg a handle on an open grant table interface + * @parm domid the domain to map memory from + * @parm ref the grant reference ID to map + * @parm notify_offset The byte offset in the page to use for unmap + * notification; -1 for none. + * @parm notify_port The event channel port to use for unmap notify, or -1 + */ +void *xc_gnttab_map_grant_ref_notify(xc_gnttab *xcg, + uint32_t domid, + uint32_t ref, + uint32_t notify_offset, + evtchn_port_t notify_port); + +/* * Unmaps the @count pages starting at @start_address, which were mapped by a * call to xc_gnttab_map_grant_ref or xc_gnttab_map_grant_refs. Never logs. */ diff --git a/tools/libxc/xenctrlosdep.h b/tools/libxc/xenctrlosdep.h index bfe46e0..01969c5 100644 --- a/tools/libxc/xenctrlosdep.h +++ b/tools/libxc/xenctrlosdep.h @@ -119,6 +119,11 @@ struct xc_osdep_ops uint32_t domid, uint32_t *refs, int prot); + void *(*map_grant_ref_notify)(xc_gnttab *xcg, xc_osdep_handle h, + uint32_t domid, + uint32_t ref, + uint32_t notify_offset, + evtchn_port_t notify_port); int (*munmap)(xc_gnttab *xcg, xc_osdep_handle h, void *start_address, uint32_t count); -- 1.7.6 _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel From xen-devel-bounces@lists.xensource.com Thu Sep 01 09:31:20 2011 Return-path: Envelope-to: www-data@lists.xensource.com Delivery-date: Thu, 01 Sep 2011 09:31:20 -0700 Received: from localhost ([127.0.0.1] helo=lists.colo.xensource.com) by lists.xensource.com with esmtp (Exim 4.43) id 1QzAAi-0002r1-FV; Thu, 01 Sep 2011 09:31:20 -0700 Received: from mail182.messagelabs.com ([85.158.139.83]) by lists.xensource.com with smtp (Exim 4.43) id 1QzA7L-0001RY-B7 for xen-devel@lists.xensource.com; Thu, 01 Sep 2011 09:27:53 -0700 X-Env-Sender: dgdegra@tycho.nsa.gov X-Msg-Ref: server-8.tower-182.messagelabs.com!1314894467!16720199!1 X-Originating-IP: [63.239.65.40] X-StarScan-Version: 6.3.6; banners=-,-,- X-VirusChecked: Checked Received: (qmail 29989 invoked from network); 1 Sep 2011 16:27:47 -0000 Received: from msux-gh1-uea02.nsa.gov (HELO msux-gh1-uea02.nsa.gov) (63.239.65.40) by server-8.tower-182.messagelabs.com with SMTP; 1 Sep 2011 16:27:47 -0000 Received: from tarius.tycho.ncsc.mil (localhost [127.0.0.1]) by msux-gh1-uea02.nsa.gov (8.12.10/8.12.10) with ESMTP id p81GRi6U013462; Thu, 1 Sep 2011 16:27:44 GMT Received: from moss-nexus.epoch.ncsc.mil (moss-nexus [144.51.25.48]) by tarius.tycho.ncsc.mil (8.13.1/8.13.1) with ESMTP id p81GRiC7009262; Thu, 1 Sep 2011 12:27:44 -0400 From: Daniel De Graaf To: xen-devel@lists.xensource.com Date: Thu, 1 Sep 2011 12:22:18 -0400 Message-Id: <1314894138-28747-4-git-send-email-dgdegra@tycho.nsa.gov> X-Mailer: git-send-email 1.7.6 In-Reply-To: <1314894138-28747-1-git-send-email-dgdegra@tycho.nsa.gov> References: <1313764724-12683-1-git-send-email-dgdegra@tycho.nsa.gov> <1314894138-28747-1-git-send-email-dgdegra@tycho.nsa.gov> Cc: Ian.Campbell@eu.citrix.com, Daniel De Graaf , konrad.wilk@oracle.com, Ian.Jackson@eu.citrix.com, Stefano.Stabellini@eu.citrix.com Subject: [Xen-devel] [PATCH 3/3] libvchan: interdomain communications library X-BeenThere: xen-devel@lists.xensource.com X-Mailman-Version: 2.1.5 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xensource.com Errors-To: xen-devel-bounces@lists.xensource.com This library implements a bidirectional communication interface between applications in different domains, similar to unix sockets. Data can be sent using the byte-oriented libvchan_read/libvchan_write or the packet-oriented libvchan_recv/libvchan_send. Channel setup is done using a client-server model; domain IDs and a port number must be negotiated prior to initialization. The server allocates memory for the shared pages and determines the sizes of the communication rings (which may span multiple pages, although the default places rings and control within a single page). With properly sized rings, testing has shown that this interface provides speed comparable to pipes within a single Linux domain; it is significantly faster than network-based communication. Signed-off-by: Daniel De Graaf --- tools/Makefile | 1 + tools/include/xen-sys/Linux/gntalloc.h | 82 +++++++ tools/include/xen-sys/Linux/gntdev.h | 33 +++- tools/libvchan/Makefile | 59 +++++ tools/libvchan/init.c | 396 ++++++++++++++++++++++++++++++++ tools/libvchan/io.c | 375 ++++++++++++++++++++++++++++++ tools/libvchan/libxenvchan.h | 173 ++++++++++++++ tools/libvchan/node-select.c | 162 +++++++++++++ tools/libvchan/node.c | 169 ++++++++++++++ xen/include/public/io/libvchan.h | 97 ++++++++ 10 files changed, 1546 insertions(+), 1 deletions(-) create mode 100644 tools/include/xen-sys/Linux/gntalloc.h create mode 100644 tools/libvchan/Makefile create mode 100644 tools/libvchan/init.c create mode 100644 tools/libvchan/io.c create mode 100644 tools/libvchan/libxenvchan.h create mode 100644 tools/libvchan/node-select.c create mode 100644 tools/libvchan/node.c create mode 100644 xen/include/public/io/libvchan.h diff --git a/tools/Makefile b/tools/Makefile index df6270c..9389e1f 100644 --- a/tools/Makefile +++ b/tools/Makefile @@ -27,6 +27,7 @@ SUBDIRS-$(CONFIG_NetBSD) += blktap2 SUBDIRS-$(CONFIG_NetBSD) += xenbackendd SUBDIRS-y += libfsimage SUBDIRS-$(LIBXENAPI_BINDINGS) += libxen +SUBDIRS-y += libvchan # do not recurse in to a dir we are about to delete ifneq "$(MAKECMDGOALS)" "distclean" diff --git a/tools/include/xen-sys/Linux/gntalloc.h b/tools/include/xen-sys/Linux/gntalloc.h new file mode 100644 index 0000000..76bd580 --- /dev/null +++ b/tools/include/xen-sys/Linux/gntalloc.h @@ -0,0 +1,82 @@ +/****************************************************************************** + * gntalloc.h + * + * Interface to /dev/xen/gntalloc. + * + * Author: Daniel De Graaf + * + * This file is in the public domain. + */ + +#ifndef __LINUX_PUBLIC_GNTALLOC_H__ +#define __LINUX_PUBLIC_GNTALLOC_H__ + +/* + * Allocates a new page and creates a new grant reference. + */ +#define IOCTL_GNTALLOC_ALLOC_GREF \ +_IOC(_IOC_NONE, 'G', 5, sizeof(struct ioctl_gntalloc_alloc_gref)) +struct ioctl_gntalloc_alloc_gref { + /* IN parameters */ + /* The ID of the domain to be given access to the grants. */ + uint16_t domid; + /* Flags for this mapping */ + uint16_t flags; + /* Number of pages to map */ + uint32_t count; + /* OUT parameters */ + /* The offset to be used on a subsequent call to mmap(). */ + uint64_t index; + /* The grant references of the newly created grant, one per page */ + /* Variable size, depending on count */ + uint32_t gref_ids[1]; +}; + +#define GNTALLOC_FLAG_WRITABLE 1 + +/* + * Deallocates the grant reference, allowing the associated page to be freed if + * no other domains are using it. + */ +#define IOCTL_GNTALLOC_DEALLOC_GREF \ +_IOC(_IOC_NONE, 'G', 6, sizeof(struct ioctl_gntalloc_dealloc_gref)) +struct ioctl_gntalloc_dealloc_gref { + /* IN parameters */ + /* The offset returned in the map operation */ + uint64_t index; + /* Number of references to unmap */ + uint32_t count; +}; + +/* + * Sets up an unmap notification within the page, so that the other side can do + * cleanup if this side crashes. Required to implement cross-domain robust + * mutexes or close notification on communication channels. + * + * Each mapped page only supports one notification; multiple calls referring to + * the same page overwrite the previous notification. You must clear the + * notification prior to the IOCTL_GNTALLOC_DEALLOC_GREF if you do not want it + * to occur. + */ +#define IOCTL_GNTALLOC_SET_UNMAP_NOTIFY \ +_IOC(_IOC_NONE, 'G', 7, sizeof(struct ioctl_gntalloc_unmap_notify)) +struct ioctl_gntalloc_unmap_notify { + /* IN parameters */ + /* Offset in the file descriptor for a byte within the page (same as + * used in mmap). If using UNMAP_NOTIFY_CLEAR_BYTE, this is the byte to + * be cleared. Otherwise, it can be any byte in the page whose + * notification we are adjusting. + */ + uint64_t index; + /* Action(s) to take on unmap */ + uint32_t action; + /* Event channel to notify */ + uint32_t event_channel_port; +}; + +/* Clear (set to zero) the byte specified by index */ +#define UNMAP_NOTIFY_CLEAR_BYTE 0x1 +/* Send an interrupt on the indicated event channel */ +#define UNMAP_NOTIFY_SEND_EVENT 0x2 + +#endif /* __LINUX_PUBLIC_GNTALLOC_H__ */ diff --git a/tools/include/xen-sys/Linux/gntdev.h b/tools/include/xen-sys/Linux/gntdev.h index 8bd1467..5304bd3 100644 --- a/tools/include/xen-sys/Linux/gntdev.h +++ b/tools/include/xen-sys/Linux/gntdev.h @@ -66,7 +66,7 @@ struct ioctl_gntdev_map_grant_ref { * before this ioctl is called, or an error will result. */ #define IOCTL_GNTDEV_UNMAP_GRANT_REF \ -_IOC(_IOC_NONE, 'G', 1, sizeof(struct ioctl_gntdev_unmap_grant_ref)) +_IOC(_IOC_NONE, 'G', 1, sizeof(struct ioctl_gntdev_unmap_grant_ref)) struct ioctl_gntdev_unmap_grant_ref { /* IN parameters */ /* The offset was returned by the corresponding map operation. */ @@ -116,4 +116,35 @@ struct ioctl_gntdev_set_max_grants { uint32_t count; }; +/* + * Sets up an unmap notification within the page, so that the other side can do + * cleanup if this side crashes. Required to implement cross-domain robust + * mutexes or close notification on communication channels. + * + * Each mapped page only supports one notification; multiple calls referring to + * the same page overwrite the previous notification. You must clear the + * notification prior to the IOCTL_GNTALLOC_DEALLOC_GREF if you do not want it + * to occur. + */ +#define IOCTL_GNTDEV_SET_UNMAP_NOTIFY \ +_IOC(_IOC_NONE, 'G', 7, sizeof(struct ioctl_gntdev_unmap_notify)) +struct ioctl_gntdev_unmap_notify { + /* IN parameters */ + /* Offset in the file descriptor for a byte within the page (same as + * used in mmap). If using UNMAP_NOTIFY_CLEAR_BYTE, this is the byte to + * be cleared. Otherwise, it can be any byte in the page whose + * notification we are adjusting. + */ + uint64_t index; + /* Action(s) to take on unmap */ + uint32_t action; + /* Event channel to notify */ + uint32_t event_channel_port; +}; + +/* Clear (set to zero) the byte specified by index */ +#define UNMAP_NOTIFY_CLEAR_BYTE 0x1 +/* Send an interrupt on the indicated event channel */ +#define UNMAP_NOTIFY_SEND_EVENT 0x2 + #endif /* __LINUX_PUBLIC_GNTDEV_H__ */ diff --git a/tools/libvchan/Makefile b/tools/libvchan/Makefile new file mode 100644 index 0000000..528eaed --- /dev/null +++ b/tools/libvchan/Makefile @@ -0,0 +1,59 @@ +# +# tools/libvchan/Makefile +# + +XEN_ROOT = $(CURDIR)/../.. +include $(XEN_ROOT)/tools/Rules.mk + +LIBVCHAN_OBJS = init.o io.o +NODE_OBJS = node.o +NODE2_OBJS = node-select.o + +LIBVCHAN_PIC_OBJS = $(patsubst %.o,%.opic,$(LIBVCHAN_OBJS)) +LIBVCHAN_LIBS = $(LDLIBS_libxenstore) $(LDLIBS_libxenctrl) +$(LIBVCHAN_OBJS) $(LIBVCHAN_PIC_OBJS): CFLAGS += $(CFLAGS_libxenstore) $(CFLAGS_libxenctrl) +$(NODE_OBJS) $(NODE2_OBJS): CFLAGS += $(CFLAGS_libxenctrl) + +MAJOR = 1.0 +MINOR = 0 + +CFLAGS += -I../include -I. + +.PHONY: all +all: libxenvchan.so vchan-node1 vchan-node2 libxenvchan.a + +libxenvchan.so: libxenvchan.so.$(MAJOR) + ln -sf $< $@ + +libxenvchan.so.$(MAJOR): libxenvchan.so.$(MAJOR).$(MINOR) + ln -sf $< $@ + +libxenvchan.so.$(MAJOR).$(MINOR): $(LIBVCHAN_PIC_OBJS) + $(CC) $(LDFLAGS) -Wl,$(SONAME_LDFLAG) -Wl,libxenvchan.so.$(MAJOR) $(SHLIB_LDFLAGS) -o $@ $^ $(LIBVCHAN_LIBS) + +libxenvchan.a: $(LIBVCHAN_OBJS) + $(AR) rcs libxenvchan.a $^ + +vchan-node1: $(NODE_OBJS) libxenvchan.so + $(CC) $(LDFLAGS) -o $@ $(NODE_OBJS) libxenvchan.so $(LDLIBS_libvchan) + +vchan-node2: $(NODE2_OBJS) libxenvchan.so + $(CC) $(LDFLAGS) -o $@ $(NODE2_OBJS) libxenvchan.so $(LDLIBS_libvchan) + +.PHONY: install +install: all + $(INSTALL_DIR) $(DESTDIR)$(LIBDIR) + $(INSTALL_DIR) $(DESTDIR)$(INCLUDEDIR) + $(INSTALL_PROG) libxenvchan.so.$(MAJOR).$(MINOR) $(DESTDIR)$(LIBDIR) + ln -sf libxenvchan.so.$(MAJOR).$(MINOR) $(DESTDIR)$(LIBDIR)/libxenvchan.so.$(MAJOR) + ln -sf libxenvchan.so.$(MAJOR) $(DESTDIR)$(LIBDIR)/libxenvchan.so + $(INSTALL_DATA) libxenvchan.h $(DESTDIR)$(INCLUDEDIR) + $(INSTALL_DATA) libxenvchan.a $(DESTDIR)$(LIBDIR) + +.PHONY: clean +clean: + $(RM) -f *.o *.so* *.a vchan-node1 vchan-node2 $(DEPS) + +distclean: clean + +-include $(DEPS) diff --git a/tools/libvchan/init.c b/tools/libvchan/init.c new file mode 100644 index 0000000..9b98104 --- /dev/null +++ b/tools/libvchan/init.c @@ -0,0 +1,396 @@ +/** + * @file + * @section AUTHORS + * + * Copyright (C) 2010 Rafal Wojtczuk + * + * Authors: + * Rafal Wojtczuk + * Daniel De Graaf + * + * @section LICENSE + * + * This library is free software; you can redistribute it and/or + * modify it under the terms of the GNU Lesser General Public + * License as published by the Free Software Foundation; either + * version 2 of the License, or (at your option) any later version. + * + * This library is distributed in the hope that it will be useful, + * but WITHOUT ANY WARRANTY; without even the implied warranty of + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU + * Lesser General Public License for more details. + * + * You should have received a copy of the GNU Lesser General Public + * License along with this library; if not, write to the Free Software + * Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston, MA 02110-1301 USA + * + * @section DESCRIPTION + * + * This file contains the setup code used to establish the ring buffer. + */ + +#include +#include +#include +#include +#include +#include +#include +#include +#include +#include + +#include +#include +#include +#include +#include + +#ifndef PAGE_SHIFT +#define PAGE_SHIFT 12 +#endif + +#ifndef PAGE_SIZE +#define PAGE_SIZE 4096 +#endif + +#ifndef offsetof +#define offsetof(TYPE, MEMBER) ((size_t) &((TYPE *)0)->MEMBER) +#endif + +#define max(a,b) ((a > b) ? a : b) + +static int init_gnt_srv(struct libvchan *ctrl) +{ + int pages_left = ctrl->read.order >= PAGE_SHIFT ? 1 << (ctrl->read.order - PAGE_SHIFT) : 0; + int pages_right = ctrl->write.order >= PAGE_SHIFT ? 1 << (ctrl->write.order - PAGE_SHIFT) : 0; + uint32_t ring_ref = -1; + void *ring; + + ring = xc_gntshr_share_page_notify(ctrl->gntshr, ctrl->other_domain_id, + &ring_ref, 1, offsetof(struct vchan_interface, srv_live), + ctrl->event_port); + + if (!ring) + goto out; + + memset(ring, 0, PAGE_SIZE); + + ctrl->ring = ring; + ctrl->read.shr = &ctrl->ring->left; + ctrl->write.shr = &ctrl->ring->right; + ctrl->ring->left_order = ctrl->read.order; + ctrl->ring->right_order = ctrl->write.order; + ctrl->ring->cli_live = 2; + ctrl->ring->srv_live = 1; + ctrl->ring->cli_notify = VCHAN_NOTIFY_WRITE; + + if (ctrl->read.order == 10) { + ctrl->read.buffer = ((void*)ctrl->ring) + 1024; + } else if (ctrl->read.order == 11) { + ctrl->read.buffer = ((void*)ctrl->ring) + 2048; + } else { + ctrl->read.buffer = xc_gntshr_share_pages(ctrl->gntshr, ctrl->other_domain_id, + pages_left, ctrl->ring->grants, 1); + if (!ctrl->read.buffer) + goto out_ring; + } + + if (ctrl->write.order == 10) { + ctrl->write.buffer = ((void*)ctrl->ring) + 1024; + } else if (ctrl->write.order == 11) { + ctrl->write.buffer = ((void*)ctrl->ring) + 2048; + } else { + ctrl->write.buffer = xc_gntshr_share_pages(ctrl->gntshr, ctrl->other_domain_id, + pages_right, ctrl->ring->grants + pages_left, 1); + if (!ctrl->write.buffer) + goto out_unmap_left; + } + +out: + return ring_ref; +out_unmap_left: + if (ctrl->read.order > 11) + xc_gntshr_munmap(ctrl->gntshr, ctrl->read.buffer, pages_left * PAGE_SIZE); +out_ring: + xc_gntshr_munmap(ctrl->gntshr, ring, PAGE_SIZE); + ring_ref = -1; + ctrl->ring = NULL; + ctrl->write.order = ctrl->read.order = 0; + goto out; +} + +static int init_gnt_cli(struct libvchan *ctrl, uint32_t ring_ref) +{ + int rv = -1; + uint32_t *grants; + + ctrl->ring = xc_gnttab_map_grant_ref_notify(ctrl->gnttab, + ctrl->other_domain_id, ring_ref, + offsetof(struct vchan_interface, cli_live), ctrl->event_port); + + if (!ctrl->ring) + goto out; + + ctrl->write.order = ctrl->ring->left_order; + ctrl->read.order = ctrl->ring->right_order; + ctrl->write.shr = &ctrl->ring->left; + ctrl->read.shr = &ctrl->ring->right; + if (ctrl->write.order < 10 || ctrl->write.order > 24) + goto out_unmap_ring; + if (ctrl->read.order < 10 || ctrl->read.order > 24) + goto out_unmap_ring; + if (ctrl->read.order == ctrl->write.order && ctrl->read.order < 12) + goto out_unmap_ring; + + grants = ctrl->ring->grants; + + if (ctrl->write.order == 10) { + ctrl->write.buffer = ((void*)ctrl->ring) + 1024; + } else if (ctrl->write.order == 11) { + ctrl->write.buffer = ((void*)ctrl->ring) + 2048; + } else { + int pages_left = 1 << (ctrl->write.order - PAGE_SHIFT); + ctrl->write.buffer = xc_gnttab_map_domain_grant_refs(ctrl->gnttab, + pages_left, ctrl->other_domain_id, grants, PROT_READ|PROT_WRITE); + if (!ctrl->write.buffer) + goto out_unmap_ring; + grants += pages_left; + } + + if (ctrl->read.order == 10) { + ctrl->read.buffer = ((void*)ctrl->ring) + 1024; + } else if (ctrl->read.order == 11) { + ctrl->read.buffer = ((void*)ctrl->ring) + 2048; + } else { + int pages_right = 1 << (ctrl->read.order - PAGE_SHIFT); + ctrl->read.buffer = xc_gnttab_map_domain_grant_refs(ctrl->gnttab, + pages_right, ctrl->other_domain_id, grants, PROT_READ); + if (!ctrl->read.buffer) + goto out_unmap_left; + } + + rv = 0; + out: + return rv; + out_unmap_left: + if (ctrl->write.order >= PAGE_SHIFT) + xc_gnttab_munmap(ctrl->gnttab, ctrl->write.buffer, + 1 << ctrl->write.order); + out_unmap_ring: + xc_gnttab_munmap(ctrl->gnttab, ctrl->ring, PAGE_SIZE); + ctrl->ring = 0; + ctrl->write.order = ctrl->read.order = 0; + rv = -1; + goto out; +} + +static int init_evt_srv(struct libvchan *ctrl, xentoollog_logger *logger) +{ + ctrl->event = xc_evtchn_open(logger, 0); + if (!ctrl->event) + return -1; + ctrl->event_port = xc_evtchn_bind_unbound_port(ctrl->event, ctrl->other_domain_id); + if (ctrl->event_port < 0) + return -1; + if (xc_evtchn_unmask(ctrl->event, ctrl->event_port)) + return -1; + return 0; +} + +static int init_xs_srv(struct libvchan *ctrl, int ring_ref) +{ + int ret = -1; + struct xs_handle *xs; + struct xs_permissions perms[2]; + char buf[64]; + char ref[16]; + char* domid_str = NULL; + xs = xs_domain_open(); + if (!xs) + goto fail; + domid_str = xs_read(xs, 0, "domid", NULL); + if (!domid_str) + goto fail_xs_open; + + // owner domain is us + perms[0].id = atoi(domid_str); + // permissions for domains not listed = none + perms[0].perms = XS_PERM_NONE; + // other domains + perms[1].id = ctrl->other_domain_id; + perms[1].perms = XS_PERM_READ; + + snprintf(ref, sizeof ref, "%d", ring_ref); + snprintf(buf, sizeof buf, "data/vchan/%d/%d/ring-ref", ctrl->other_domain_id, ctrl->device_number); + if (!xs_write(xs, 0, buf, ref, strlen(ref))) + goto fail_xs_open; + if (!xs_set_permissions(xs, 0, buf, perms, 2)) + goto fail_xs_open; + + snprintf(ref, sizeof ref, "%d", ctrl->event_port); + snprintf(buf, sizeof buf, "data/vchan/%d/%d/event-channel", ctrl->other_domain_id, ctrl->device_number); + if (!xs_write(xs, 0, buf, ref, strlen(ref))) + goto fail_xs_open; + if (!xs_set_permissions(xs, 0, buf, perms, 2)) + goto fail_xs_open; + + ret = 0; + fail_xs_open: + free(domid_str); + xs_daemon_close(xs); + fail: + return ret; +} + +static int min_order(size_t siz) +{ + int rv = PAGE_SHIFT; + while (siz > (1 << rv)) + rv++; + return rv; +} + +struct libvchan *libvchan_server_init(xentoollog_logger *logger, int domain, int devno, size_t left_min, size_t right_min) +{ + // if you go over this size, you'll have too many grants to fit in the shared page. + size_t MAX_RING_SIZE = 256 * PAGE_SIZE; + struct libvchan *ctrl; + int ring_ref; + if (left_min > MAX_RING_SIZE || right_min > MAX_RING_SIZE) + return 0; + + ctrl = malloc(sizeof(*ctrl)); + if (!ctrl) + return 0; + + ctrl->other_domain_id = domain; + ctrl->device_number = devno; + ctrl->ring = NULL; + ctrl->event = NULL; + ctrl->is_server = 1; + ctrl->server_persist = 0; + + ctrl->read.order = min_order(left_min); + ctrl->write.order = min_order(right_min); + + // if we can avoid allocating extra pages by using in-page rings, do so +#define MAX_SMALL_RING 1024 +#define MAX_LARGE_RING 2048 + if (left_min <= MAX_SMALL_RING && right_min <= MAX_LARGE_RING) { + ctrl->read.order = 10; + ctrl->write.order = 11; + } else if (left_min <= MAX_LARGE_RING && right_min <= MAX_SMALL_RING) { + ctrl->read.order = 11; + ctrl->write.order = 10; + } else if (left_min <= MAX_LARGE_RING) { + ctrl->read.order = 11; + } else if (right_min <= MAX_LARGE_RING) { + ctrl->write.order = 11; + } + + ctrl->gntshr = xc_gntshr_open(logger, 0); + if (!ctrl->gntshr) + goto out; + + if (init_evt_srv(ctrl, logger)) + goto out; + ring_ref = init_gnt_srv(ctrl); + if (ring_ref < 0) + goto out; + if (init_xs_srv(ctrl, ring_ref)) + goto out; + return ctrl; +out: + libvchan_close(ctrl); + return 0; +} + +static int init_evt_cli(struct libvchan *ctrl, xentoollog_logger *logger) +{ + ctrl->event = xc_evtchn_open(logger, 0); + if (!ctrl->event) + return -1; + ctrl->event_port = xc_evtchn_bind_interdomain(ctrl->event, + ctrl->other_domain_id, ctrl->event_port); + if (ctrl->event_port < 0) + return -1; + xc_evtchn_unmask(ctrl->event, ctrl->event_port); + return 0; +} + + +struct libvchan *libvchan_client_init(xentoollog_logger *logger, int domain, int devno) +{ + struct libvchan *ctrl = malloc(sizeof(struct libvchan)); + struct xs_handle *xs = NULL; + char buf[64]; + char *ref; + int ring_ref; + unsigned int len; + char* domid_str = NULL; + + if (!ctrl) + return 0; + ctrl->other_domain_id = domain; + ctrl->device_number = devno; + ctrl->ring = NULL; + ctrl->event = NULL; + ctrl->write.order = ctrl->read.order = 0; + ctrl->is_server = 0; + + xs = xs_daemon_open(); + if (!xs) + xs = xs_domain_open(); + if (!xs) + goto fail; + + domid_str = xs_read(xs, 0, "domid", NULL); + if (!domid_str) + goto fail; + +// find xenstore entry + snprintf(buf, sizeof buf, "/local/domain/%d/data/vchan/%s/%d/ring-ref", + ctrl->other_domain_id, domid_str, ctrl->device_number); + ref = xs_read(xs, 0, buf, &len); + if (!ref) + goto fail; + ring_ref = atoi(ref); + free(ref); + if (!ring_ref) + goto fail; + snprintf(buf, sizeof buf, "/local/domain/%d/data/vchan/%s/%d/event-channel", + ctrl->other_domain_id, domid_str, ctrl->device_number); + ref = xs_read(xs, 0, buf, &len); + if (!ref) + goto fail; + ctrl->event_port = atoi(ref); + free(ref); + if (!ctrl->event_port) + goto fail; + + ctrl->gnttab = xc_gnttab_open(logger, 0); + if (!ctrl->gnttab) + goto out; + +// set up event channel + if (init_evt_cli(ctrl, logger)) + goto fail; + +// set up shared page(s) + if (init_gnt_cli(ctrl, ring_ref)) + goto fail; + + ctrl->ring->cli_live = 1; + ctrl->ring->srv_notify = VCHAN_NOTIFY_WRITE; + + out: + free(domid_str); + if (xs) + xs_daemon_close(xs); + return ctrl; + fail: + libvchan_close(ctrl); + ctrl = NULL; + goto out; +} diff --git a/tools/libvchan/io.c b/tools/libvchan/io.c new file mode 100644 index 0000000..08d5dcf --- /dev/null +++ b/tools/libvchan/io.c @@ -0,0 +1,375 @@ +/** + * @file + * @section AUTHORS + * + * Copyright (C) 2010 Rafal Wojtczuk + * + * Authors: + * Rafal Wojtczuk + * Daniel De Graaf + * + * @section LICENSE + * + * This library is free software; you can redistribute it and/or + * modify it under the terms of the GNU Lesser General Public + * License as published by the Free Software Foundation; either + * version 2 of the License, or (at your option) any later version. + * + * This library is distributed in the hope that it will be useful, + * but WITHOUT ANY WARRANTY; without even the implied warranty of + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU + * Lesser General Public License for more details. + * + * You should have received a copy of the GNU Lesser General Public + * License along with this library; if not, write to the Free Software + * Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston, MA 02110-1301 USA + * + * @section DESCRIPTION + * + * This file contains the communications interface built on the ring buffer. + */ + +#include +#include +#include +#include +#include +#include +#include +#include + +#include +#include + +#ifndef PAGE_SHIFT +#define PAGE_SHIFT 12 +#endif + +#ifndef PAGE_SIZE +#define PAGE_SIZE 4096 +#endif + +// allow vchan data to be easily observed in strace by doing a +// writev() to FD -1 with the data being read/written. +#ifndef VCHAN_DEBUG +#define VCHAN_DEBUG 0 +#endif + +#define barrier() asm volatile("" ::: "memory") + + +static inline uint32_t rd_prod(struct libvchan *ctrl) +{ + return ctrl->read.shr->prod; +} + +static inline uint32_t* _rd_cons(struct libvchan *ctrl) +{ + return &ctrl->read.shr->cons; +} +#define rd_cons(x) (*_rd_cons(x)) + +static inline uint32_t* _wr_prod(struct libvchan *ctrl) +{ + return &ctrl->write.shr->prod; +} +#define wr_prod(x) (*_wr_prod(x)) + +static inline uint32_t wr_cons(struct libvchan *ctrl) +{ + return ctrl->write.shr->cons; +} + +static inline const void* rd_ring(struct libvchan *ctrl) +{ + return ctrl->read.buffer; +} + +static inline void* wr_ring(struct libvchan *ctrl) +{ + return ctrl->write.buffer; +} + +static inline uint32_t wr_ring_size(struct libvchan *ctrl) +{ + return (1 << ctrl->write.order); +} + +static inline uint32_t rd_ring_size(struct libvchan *ctrl) +{ + return (1 << ctrl->read.order); +} + +static inline void request_notify(struct libvchan *ctrl, uint8_t bit) +{ + uint8_t *notify = ctrl->is_server ? &ctrl->ring->cli_notify : &ctrl->ring->srv_notify; + __sync_or_and_fetch(notify, bit); +} + +static inline int send_notify(struct libvchan *ctrl, uint8_t bit) +{ + uint8_t *notify = ctrl->is_server ? &ctrl->ring->srv_notify : &ctrl->ring->cli_notify; + uint8_t prev = __sync_fetch_and_and(notify, ~bit); + if (prev & bit) + return xc_evtchn_notify(ctrl->event, ctrl->event_port); + else + return 0; +} + +/** + * Get the amount of buffer space available and enable notifications if needed. + */ +static inline int fast_get_data_ready(struct libvchan *ctrl, size_t request) +{ + int ready = rd_prod(ctrl) - rd_cons(ctrl); + if (ready >= request) + return ready; + /* We plan to consume all data; please tell us if you send more */ + request_notify(ctrl, VCHAN_NOTIFY_WRITE); + /* + * If the writer moved rd_prod after our read but before request, we + * will not get notified even though the actual amount of data ready is + * above request. Reread rd_prod to cover this case. + */ + return rd_prod(ctrl) - rd_cons(ctrl); +} + +int libvchan_data_ready(struct libvchan *ctrl) +{ + /* Since this value is being used outside libvchan, request notification + * when it changes + */ + request_notify(ctrl, VCHAN_NOTIFY_WRITE); + return rd_prod(ctrl) - rd_cons(ctrl); +} + +/** + * Get the amount of buffer space available and enable notifications if needed. + */ +static inline int fast_get_buffer_space(struct libvchan *ctrl, size_t request) +{ + int ready = wr_ring_size(ctrl) - (wr_prod(ctrl) - wr_cons(ctrl)); + if (ready >= request) + return ready; + /* We plan to fill the buffer; please tell us when you've read it */ + request_notify(ctrl, VCHAN_NOTIFY_READ); + /* + * If the reader moved wr_cons after our read but before request, we + * will not get notified even though the actual amount of buffer space + * is above request. Reread wr_cons to cover this case. + */ + return wr_ring_size(ctrl) - (wr_prod(ctrl) - wr_cons(ctrl)); +} + +int libvchan_buffer_space(struct libvchan *ctrl) +{ + /* Since this value is being used outside libvchan, request notification + * when it changes + */ + request_notify(ctrl, VCHAN_NOTIFY_READ); + return wr_ring_size(ctrl) - (wr_prod(ctrl) - wr_cons(ctrl)); +} + +int libvchan_wait(struct libvchan *ctrl) +{ + int ret = xc_evtchn_pending(ctrl->event); + if (ret < 0) + return -1; + xc_evtchn_unmask(ctrl->event, ret); + return 0; +} + +/** + * returns -1 on error, or size on success + */ +static int do_send(struct libvchan *ctrl, const void *data, size_t size) +{ + int real_idx = wr_prod(ctrl) & (wr_ring_size(ctrl) - 1); + int avail_contig = wr_ring_size(ctrl) - real_idx; + if (VCHAN_DEBUG) { + char metainfo[32]; + struct iovec iov[2]; + iov[0].iov_base = metainfo; + iov[0].iov_len = snprintf(metainfo, 32, "vchan wr %d/%d", ctrl->other_domain_id, ctrl->device_number); + iov[1].iov_base = (void *)data; + iov[1].iov_len = size; + writev(-1, iov, 2); + } + if (avail_contig > size) + avail_contig = size; + memcpy(wr_ring(ctrl) + real_idx, data, avail_contig); + if (avail_contig < size) + { + // we rolled across the end of the ring + memcpy(wr_ring(ctrl), data + avail_contig, size - avail_contig); + } + barrier(); // data must be in the ring prior to increment + wr_prod(ctrl) += size; + barrier(); // increment must happen prior to notify + if (send_notify(ctrl, VCHAN_NOTIFY_WRITE)) + return -1; + return size; +} + +/** + * returns 0 if no buffer space is available, -1 on error, or size on success + */ +int libvchan_send(struct libvchan *ctrl, const void *data, size_t size) +{ + int avail; + while (1) { + if (!libvchan_is_open(ctrl)) + return -1; + avail = fast_get_buffer_space(ctrl, size); + if (size <= avail) + return do_send(ctrl, data, size); + if (!ctrl->blocking) + return 0; + if (size > wr_ring_size(ctrl)) + return -1; + if (libvchan_wait(ctrl)) + return -1; + } +} + +int libvchan_write(struct libvchan *ctrl, const void *data, size_t size) +{ + int avail; + if (!libvchan_is_open(ctrl)) + return -1; + if (ctrl->blocking) { + size_t pos = 0; + while (1) { + avail = fast_get_buffer_space(ctrl, size - pos); + if (pos + avail > size) + avail = size - pos; + if (avail) + pos += do_send(ctrl, data + pos, avail); + if (pos == size) + return pos; + if (libvchan_wait(ctrl)) + return -1; + if (!libvchan_is_open(ctrl)) + return -1; + } + } else { + avail = fast_get_buffer_space(ctrl, size); + if (size > avail) + size = avail; + if (size == 0) + return 0; + return do_send(ctrl, data, size); + } +} + +static int do_recv(struct libvchan *ctrl, void *data, size_t size) +{ + int real_idx = rd_cons(ctrl) & (rd_ring_size(ctrl) - 1); + int avail_contig = rd_ring_size(ctrl) - real_idx; + if (avail_contig > size) + avail_contig = size; + barrier(); // data read must happen after rd_cons read + memcpy(data, rd_ring(ctrl) + real_idx, avail_contig); + if (avail_contig < size) + { + // we rolled across the end of the ring + memcpy(data + avail_contig, rd_ring(ctrl), size - avail_contig); + } + rd_cons(ctrl) += size; + if (VCHAN_DEBUG) { + char metainfo[32]; + struct iovec iov[2]; + iov[0].iov_base = metainfo; + iov[0].iov_len = snprintf(metainfo, 32, "vchan rd %d/%d", ctrl->other_domain_id, ctrl->device_number); + iov[1].iov_base = data; + iov[1].iov_len = size; + writev(-1, iov, 2); + } + barrier(); // consumption must happen prior to notify of newly freed space + if (send_notify(ctrl, VCHAN_NOTIFY_READ)) + return -1; + return size; +} + +/** + * reads exactly size bytes from the vchan. + * returns 0 if insufficient data is available, -1 on error, or size on success + */ +int libvchan_recv(struct libvchan *ctrl, void *data, size_t size) +{ + while (1) { + int avail = fast_get_data_ready(ctrl, size); + if (size <= avail) + return do_recv(ctrl, data, size); + if (!libvchan_is_open(ctrl)) + return -1; + if (!ctrl->blocking) + return 0; + if (size > rd_ring_size(ctrl)) + return -1; + if (libvchan_wait(ctrl)) + return -1; + } +} + +int libvchan_read(struct libvchan *ctrl, void *data, size_t size) +{ + while (1) { + int avail = fast_get_data_ready(ctrl, size); + if (avail && size > avail) + size = avail; + if (avail) + return do_recv(ctrl, data, size); + if (!libvchan_is_open(ctrl)) + return -1; + if (!ctrl->blocking) + return 0; + if (libvchan_wait(ctrl)) + return -1; + } +} + +int libvchan_is_open(struct libvchan* ctrl) +{ + if (ctrl->is_server) + return ctrl->server_persist ? 1 : ctrl->ring->cli_live; + else + return ctrl->ring->srv_live; +} + +int libvchan_fd_for_select(struct libvchan *ctrl) +{ + return xc_evtchn_fd(ctrl->event); +} + +void libvchan_close(struct libvchan *ctrl) +{ + if (!ctrl) + return; + if (ctrl->read.order >= PAGE_SHIFT) + munmap(ctrl->read.buffer, 1 << ctrl->read.order); + if (ctrl->write.order >= PAGE_SHIFT) + munmap(ctrl->write.buffer, 1 << ctrl->write.order); + if (ctrl->ring) { + if (ctrl->is_server) { + ctrl->ring->srv_live = 0; + xc_gntshr_munmap(ctrl->gntshr, ctrl->ring, PAGE_SIZE); + } else { + ctrl->ring->cli_live = 0; + xc_gnttab_munmap(ctrl->gnttab, ctrl->ring, PAGE_SIZE); + } + } + if (ctrl->event) { + if (ctrl->event_port >= 0 && ctrl->ring) + xc_evtchn_notify(ctrl->event, ctrl->event_port); + xc_evtchn_close(ctrl->event); + } + if (ctrl->is_server) { + if (ctrl->gntshr) + xc_gntshr_close(ctrl->gntshr); + } else { + if (ctrl->gnttab) + xc_gnttab_close(ctrl->gnttab); + } + free(ctrl); +} diff --git a/tools/libvchan/libxenvchan.h b/tools/libvchan/libxenvchan.h new file mode 100644 index 0000000..c4a3ab9 --- /dev/null +++ b/tools/libvchan/libxenvchan.h @@ -0,0 +1,173 @@ +/** + * @file + * @section AUTHORS + * + * Copyright (C) 2010 Rafal Wojtczuk + * + * Authors: + * Rafal Wojtczuk + * Daniel De Graaf + * + * @section LICENSE + * + * This library is free software; you can redistribute it and/or + * modify it under the terms of the GNU Lesser General Public + * License as published by the Free Software Foundation; either + * version 2 of the License, or (at your option) any later version. + * + * This library is distributed in the hope that it will be useful, + * but WITHOUT ANY WARRANTY; without even the implied warranty of + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU + * Lesser General Public License for more details. + * + * You should have received a copy of the GNU Lesser General Public + * License along with this library; if not, write to the Free Software + * Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston, MA 02110-1301 USA + * + * @section DESCRIPTION + * + * Originally borrowed from the Qubes OS Project, http://www.qubes-os.org, + * this code has been substantially rewritten to use the gntdev and gntalloc + * devices instead of raw MFNs and map_foreign_range. + * + * This is a library for inter-domain communication. A standard Xen ring + * buffer is used, with a datagram-based interface built on top. The grant + * reference and event channels are shared in XenStore under the path + * /local/domain//data/vchan///{ring-ref,event-channel} + * + * The ring.h macros define an asymmetric interface to a shared data structure + * that assumes all rings reside in a single contiguous memory space. This is + * not suitable for vchan because the interface to the ring is symmetric except + * for the setup. Unlike the producer-consumer rings defined in ring.h, the + * size of the rings used in vchan are determined at execution time instead of + * compile time, so the macros in ring.h cannot be used to access the rings. + */ + +#include +#include +#include + +struct libvchan_ring { + /* Pointer into the shared page. Offsets into buffer. */ + struct ring_shared* shr; + /* ring data; may be its own shared page(s) depending on order */ + void* buffer; + /** + * The size of the ring is (1 << order); offsets wrap around when they + * exceed this. This copy is required because we can't trust the order + * in the shared page to remain constant. + */ + int order; +}; + +/** + * struct libvchan: control structure passed to all library calls + */ +struct libvchan { + /* person we communicate with */ + int other_domain_id; + /* "port" we communicate on (allows multiple vchans to exist in xenstore) */ + int device_number; + /* Mapping handle for shared ring page */ + union { + xc_gntshr *gntshr; /* for server */ + xc_gnttab *gnttab; /* for client */ + }; + /* Pointer to shared ring page */ + struct vchan_interface *ring; + /* event channel interface */ + xc_evtchn *event; + uint32_t event_port; + /* informative flags: are we acting as server? */ + int is_server:1; + /* true if server remains active when client closes (allows reconnection) */ + int server_persist:1; + /* true if operations should block instead of returning 0 */ + int blocking:1; + /* communication rings */ + struct libvchan_ring read, write; +}; + +/** + * Set up a vchan, including granting pages + * @param logger Logger for libxc errors + * @param domain The peer domain that will be connecting + * @param devno A device number, used to identify this vchan in xenstore + * @param send_min The minimum size (in bytes) of the send ring (left) + * @param recv_min The minimum size (in bytes) of the receive ring (right) + * @return The structure, or NULL in case of an error + */ +struct libvchan *libvchan_server_init(xentoollog_logger *logger, int domain, int devno, size_t read_min, size_t write_min); +/** + * Connect to an existing vchan. Note: you can reconnect to an existing vchan + * safely, however no locking is performed, so you must prevent multiple clients + * from connecting to a single server. + * + * @param logger Logger for libxc errors + * @param domain The peer domain to connect to + * @param devno A device number, used to identify this vchan in xenstore + * @return The structure, or NULL in case of an error + */ +struct libvchan *libvchan_client_init(xentoollog_logger *logger, int domain, int devno); +/** + * Close a vchan. This deallocates the vchan and attempts to free its + * resources. The other side is notified of the close, but can still read any + * data pending prior to the close. + */ +void libvchan_close(struct libvchan *ctrl); + +/** + * Packet-based receive: always reads exactly $size bytes. + * @param ctrl The vchan control structure + * @param data Buffer for data that was read + * @param size Size of the buffer and amount of data to read + * @return -1 on error, 0 if nonblocking and insufficient data is available, or $size + */ +int libvchan_recv(struct libvchan *ctrl, void *data, size_t size); +/** + * Stream-based receive: reads as much data as possible. + * @param ctrl The vchan control structure + * @param data Buffer for data that was read + * @param size Size of the buffer + * @return -1 on error, otherwise the amount of data read (which may be zero if + * the vchan is nonblocking) + */ +int libvchan_read(struct libvchan *ctrl, void *data, size_t size); +/** + * Packet-based send: send entire buffer if possible + * @param ctrl The vchan control structure + * @param data Buffer for data to send + * @param size Size of the buffer and amount of data to send + * @return -1 on error, 0 if nonblocking and insufficient space is available, or $size + */ +int libvchan_send(struct libvchan *ctrl, const void *data, size_t size); +/** + * Stream-based send: send as much data as possible. + * @param ctrl The vchan control structure + * @param data Buffer for data to send + * @param size Size of the buffer + * @return -1 on error, otherwise the amount of data sent (which may be zero if + * the vchan is nonblocking) + */ +int libvchan_write(struct libvchan *ctrl, const void *data, size_t size); +/** + * Waits for reads or writes to unblock, or for a close + */ +int libvchan_wait(struct libvchan *ctrl); +/** + * Returns the event file descriptor for this vchan. When this FD is readable, + * libvchan_wait() will not block, and the state of the vchan has changed since + * the last invocation of libvchan_wait(). + */ +int libvchan_fd_for_select(struct libvchan *ctrl); +/** + * Query the state of the vchan shared page: + * return 0 when one side has called libvchan_close() or crashed + * return 1 when both sides are open + * return 2 [server only] when no client has yet connected + */ +int libvchan_is_open(struct libvchan* ctrl); +/** Amount of data ready to read, in bytes */ +int libvchan_data_ready(struct libvchan *ctrl); +/** Amount of data it is possible to send without blocking */ +int libvchan_buffer_space(struct libvchan *ctrl); diff --git a/tools/libvchan/node-select.c b/tools/libvchan/node-select.c new file mode 100644 index 0000000..ea1bfc6 --- /dev/null +++ b/tools/libvchan/node-select.c @@ -0,0 +1,162 @@ +/** + * @file + * @section AUTHORS + * + * Copyright (C) 2010 Rafal Wojtczuk + * + * Authors: + * Rafal Wojtczuk + * Daniel De Graaf + * + * @section LICENSE + * + * This program is free software; you can redistribute it and/or + * modify it under the terms of the GNU Lesser General Public + * License as published by the Free Software Foundation; either + * version 2 of the License, or (at your option) any later version. + * + * This program is distributed in the hope that it will be useful, + * but WITHOUT ANY WARRANTY; without even the implied warranty of + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU + * Lesser General Public License for more details. + * + * You should have received a copy of the GNU Lesser General Public + * License along with this program; if not, write to the Free Software + * Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston, MA 02110-1301 USA + * + * @section DESCRIPTION + * + * This is a test program for libvchan. Communications are bidirectional, + * with either server (grant offeror) or client able to read and write. + */ + +#include +#include +#include +#include +#include +#include + +#include + +void usage(char** argv) +{ + fprintf(stderr, "usage:\n" + "\t%s [client|server] domainid nodeid [rbufsiz wbufsiz]\n", + argv[0]); + exit(1); +} + +#define BUFSIZE 5000 +char inbuf[BUFSIZE]; +char outbuf[BUFSIZE]; +int insiz = 0; +int outsiz = 0; +struct libvchan *ctrl = 0; + +void vchan_wr() { + if (!insiz) + return; + int ret = libvchan_write(ctrl, inbuf, insiz); + if (ret < 0) { + fprintf(stderr, "vchan write failed\n"); + exit(1); + } + if (ret > 0) { + insiz -= ret; + memmove(inbuf, inbuf + ret, insiz); + } +} + +void stdout_wr() { + if (!outsiz) + return; + int ret = write(1, outbuf, outsiz); + if (ret < 0 && errno != EAGAIN) + exit(1); + if (ret > 0) { + outsiz -= ret; + memmove(outbuf, outbuf + ret, outsiz); + } +} + +/** + Simple libvchan application, both client and server. + Both sides may write and read, both from the libvchan and from + stdin/stdout (just like netcat). +*/ + +int main(int argc, char **argv) +{ + int ret; + int libvchan_fd; + if (argc < 4) + usage(argv); + if (!strcmp(argv[1], "server")) { + int rsiz = argc > 4 ? atoi(argv[4]) : 0; + int wsiz = argc > 5 ? atoi(argv[5]) : 0; + ctrl = libvchan_server_init(NULL, atoi(argv[2]), atoi(argv[3]), rsiz, wsiz); + } else if (!strcmp(argv[1], "client")) + ctrl = libvchan_client_init(NULL, atoi(argv[2]), atoi(argv[3])); + else + usage(argv); + if (!ctrl) { + perror("libvchan_*_init"); + exit(1); + } + + fcntl(0, F_SETFL, O_NONBLOCK); + fcntl(1, F_SETFL, O_NONBLOCK); + + libvchan_fd = libvchan_fd_for_select(ctrl); + for (;;) { + fd_set rfds; + fd_set wfds; + FD_ZERO(&rfds); + FD_ZERO(&wfds); + if (insiz != BUFSIZE) + FD_SET(0, &rfds); + if (outsiz) + FD_SET(1, &wfds); + FD_SET(libvchan_fd, &rfds); + ret = select(libvchan_fd + 1, &rfds, &wfds, NULL, NULL); + if (ret < 0) { + perror("select"); + exit(1); + } + if (FD_ISSET(0, &rfds)) { + ret = read(0, inbuf + insiz, BUFSIZE - insiz); + if (ret < 0 && errno != EAGAIN) + exit(1); + if (ret == 0) { + while (insiz) { + vchan_wr(); + libvchan_wait(ctrl); + } + return 0; + } + if (ret) + insiz += ret; + vchan_wr(); + } + if (FD_ISSET(libvchan_fd, &rfds)) { + libvchan_wait(ctrl); + vchan_wr(); + } + if (FD_ISSET(1, &wfds)) + stdout_wr(); + while (libvchan_data_ready(ctrl) && outsiz < BUFSIZE) { + ret = libvchan_read(ctrl, outbuf + outsiz, BUFSIZE - outsiz); + if (ret < 0) + exit(1); + outsiz += ret; + stdout_wr(); + } + if (!libvchan_is_open(ctrl)) { + fcntl(1, F_SETFL, 0); + while (outsiz) + stdout_wr(); + return 0; + } + } +} diff --git a/tools/libvchan/node.c b/tools/libvchan/node.c new file mode 100644 index 0000000..6a9204c --- /dev/null +++ b/tools/libvchan/node.c @@ -0,0 +1,169 @@ +/** + * @file + * @section AUTHORS + * + * Copyright (C) 2010 Rafal Wojtczuk + * + * Authors: + * Rafal Wojtczuk + * Daniel De Graaf + * + * @section LICENSE + * + * This program is free software; you can redistribute it and/or + * modify it under the terms of the GNU Lesser General Public + * License as published by the Free Software Foundation; either + * version 2 of the License, or (at your option) any later version. + * + * This program is distributed in the hope that it will be useful, + * but WITHOUT ANY WARRANTY; without even the implied warranty of + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU + * Lesser General Public License for more details. + * + * You should have received a copy of the GNU Lesser General Public + * License along with this program; if not, write to the Free Software + * Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston, MA 02110-1301 USA + * + * @section DESCRIPTION + * + * This is a test program for libvchan. Communications are in one direction, + * either server (grant offeror) to client or vice versa. + */ + +#include +#include +#include +#include +#include + +#include + +int libvchan_write_all(struct libvchan *ctrl, char *buf, int size) +{ + int written = 0; + int ret; + while (written < size) { + ret = libvchan_write(ctrl, buf + written, size - written); + if (ret <= 0) { + perror("write"); + exit(1); + } + written += ret; + } + return size; +} + +int write_all(int fd, char *buf, int size) +{ + int written = 0; + int ret; + while (written < size) { + ret = write(fd, buf + written, size - written); + if (ret <= 0) { + perror("write"); + exit(1); + } + written += ret; + } + return size; +} + +void usage(char** argv) +{ + fprintf(stderr, "usage:\n" + "%s [client|server] [read|write] domid nodeid\n", argv[0]); + exit(1); +} + +#define BUFSIZE 5000 +char buf[BUFSIZE]; +void reader(struct libvchan *ctrl) +{ + int size; + for (;;) { + size = rand() % (BUFSIZE - 1) + 1; + size = libvchan_read(ctrl, buf, size); + fprintf(stderr, "#"); + if (size < 0) { + perror("read vchan"); + libvchan_close(ctrl); + exit(1); + } + size = write_all(1, buf, size); + if (size < 0) { + perror("stdout write"); + exit(1); + } + if (size == 0) { + perror("write size=0?\n"); + exit(1); + } + } +} + +void writer(struct libvchan *ctrl) +{ + int size; + for (;;) { + size = rand() % (BUFSIZE - 1) + 1; + size = read(0, buf, size); + if (size < 0) { + perror("read stdin"); + libvchan_close(ctrl); + exit(1); + } + if (size == 0) + break; + size = libvchan_write_all(ctrl, buf, size); + fprintf(stderr, "#"); + if (size < 0) { + perror("vchan write"); + exit(1); + } + if (size == 0) { + perror("write size=0?\n"); + exit(1); + } + } +} + + +/** + Simple libvchan application, both client and server. + One side does writing, the other side does reading; both from + standard input/output fds. +*/ +int main(int argc, char **argv) +{ + int seed = time(0); + struct libvchan *ctrl = 0; + int wr = 0; + if (argc < 4) + usage(argv); + if (!strcmp(argv[2], "read")) + wr = 0; + else if (!strcmp(argv[2], "write")) + wr = 1; + else + usage(argv); + if (!strcmp(argv[1], "server")) + ctrl = libvchan_server_init(NULL, atoi(argv[3]), atoi(argv[4]), 0, 0); + else if (!strcmp(argv[1], "client")) + ctrl = libvchan_client_init(NULL, atoi(argv[3]), atoi(argv[4])); + else + usage(argv); + if (!ctrl) { + perror("libvchan_*_init"); + exit(1); + } + ctrl->blocking = 1; + + srand(seed); + fprintf(stderr, "seed=%d\n", seed); + if (wr) + writer(ctrl); + else + reader(ctrl); + libvchan_close(ctrl); + return 0; +} diff --git a/xen/include/public/io/libvchan.h b/xen/include/public/io/libvchan.h new file mode 100644 index 0000000..a3bf7cd --- /dev/null +++ b/xen/include/public/io/libvchan.h @@ -0,0 +1,97 @@ +/** + * @file + * @section AUTHORS + * + * Copyright (C) 2010 Rafal Wojtczuk + * + * Authors: + * Rafal Wojtczuk + * Daniel De Graaf + * + * @section LICENSE + * + * This library is free software; you can redistribute it and/or + * modify it under the terms of the GNU Lesser General Public + * License as published by the Free Software Foundation; either + * version 2 of the License, or (at your option) any later version. + * + * This library is distributed in the hope that it will be useful, + * but WITHOUT ANY WARRANTY; without even the implied warranty of + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU + * Lesser General Public License for more details. + * + * You should have received a copy of the GNU Lesser General Public + * License along with this library; if not, write to the Free Software + * Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston, MA 02110-1301 USA + * + * @section DESCRIPTION + * + * Originally borrowed from the Qubes OS Project, http://www.qubes-os.org, + * this code has been substantially rewritten to use the gntdev and gntalloc + * devices instead of raw MFNs and map_foreign_range. + * + * This is a library for inter-domain communication. A standard Xen ring + * buffer is used, with a datagram-based interface built on top. The grant + * reference and event channels are shared in XenStore under the path + * /local/domain//data/vchan///{ring-ref,event-channel} + * + * The ring.h macros define an asymmetric interface to a shared data structure + * that assumes all rings reside in a single contiguous memory space. This is + * not suitable for vchan because the interface to the ring is symmetric except + * for the setup. Unlike the producer-consumer rings defined in ring.h, the + * size of the rings used in vchan are determined at execution time instead of + * compile time, so the macros in ring.h cannot be used to access the rings. + */ + +#include +#include + +struct ring_shared { + uint32_t cons, prod; +}; + +#define VCHAN_NOTIFY_WRITE 0x1 +#define VCHAN_NOTIFY_READ 0x2 + +/** + * vchan_interface: primary shared data structure + */ +struct vchan_interface { + /** + * Standard consumer/producer interface, one pair per buffer + * left is client write, server read + * right is client read, server write + */ + struct ring_shared left, right; + /** + * size of the rings, which determines their location + * 10 - at offset 1024 in ring's page + * 11 - at offset 2048 in ring's page + * 12+ - uses 2^(N-12) grants to describe the multi-page ring + * These should remain constant once the page is shared. + * Only one of the two orders can be 10 (or 11). + */ + uint16_t left_order, right_order; + /** + * Shutdown detection: + * 0: client (or server) has exited + * 1: client (or server) is connected + * 2: client has not yet connected + */ + uint8_t cli_live, srv_live; + /** + * Notification bits: + * VCHAN_NOTIFY_WRITE: send notify when data is written + * VCHAN_NOTIFY_READ: send notify when data is read (consumed) + * cli_notify is used for the client to inform the server of its action + */ + uint8_t cli_notify, srv_notify; + /** + * Grant list: ordering is left, right. Must not extend into actual ring + * or grow beyond the end of the initial shared page. + * These should remain constant once the page is shared, to allow + * for possible remapping by a client that restarts. + */ + uint32_t grants[0]; +}; + -- 1.7.6 _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel From xen-devel-bounces@lists.xensource.com Thu Sep 01 09:32:46 2011 Return-path: Envelope-to: www-data@lists.xensource.com Delivery-date: Thu, 01 Sep 2011 09:32:46 -0700 Received: from localhost ([127.0.0.1] helo=lists.colo.xensource.com) by lists.xensource.com with esmtp (Exim 4.43) id 1QzAC6-0003PB-GU; Thu, 01 Sep 2011 09:32:46 -0700 Received: from mail182.messagelabs.com ([85.158.139.83]) by lists.xensource.com with smtp (Exim 4.43) id 1QzA8B-0001q0-4e for xen-devel@lists.xensource.com; Thu, 01 Sep 2011 09:28:44 -0700 X-Env-Sender: Ian.Campbell@eu.citrix.com X-Msg-Ref: server-9.tower-182.messagelabs.com!1314894520!16707138!1 X-Originating-IP: [62.200.22.115] X-StarScan-Version: 6.3.6; banners=-,-,- X-VirusChecked: Checked Received: (qmail 14989 invoked from network); 1 Sep 2011 16:28:40 -0000 Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115) by server-9.tower-182.messagelabs.com with SMTP; 1 Sep 2011 16:28:40 -0000 X-IronPort-AV: E=Sophos;i="4.68,314,1312156800"; d="scan'208";a="7559490" Received: from lonpmailmx01.citrite.net ([10.30.203.162]) by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5; 01 Sep 2011 16:28:40 +0000 Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net (10.30.203.162) with Microsoft SMTP Server id 8.3.137.0; Thu, 1 Sep 2011 17:28:39 +0100 From: Ian Campbell To: Daniel De Graaf In-Reply-To: <4E5E88CF.7090408@tycho.nsa.gov> References: <20055.42803.979775.531468@mariner.uk.xensource.com> <1314643714-28350-1-git-send-email-dgdegra@tycho.nsa.gov> <1314700361.10283.135.camel@zakaz.uk.xensource.com> <4E5E88CF.7090408@tycho.nsa.gov> Content-Type: text/plain; charset="UTF-8" Organization: Citrix Systems, Inc. Date: Thu, 1 Sep 2011 17:28:39 +0100 Message-ID: <1314894519.28989.143.camel@zakaz.uk.xensource.com> MIME-Version: 1.0 X-Mailer: Evolution 2.32.3 Content-Transfer-Encoding: 7bit Cc: Stefano Stabellini , "xen-devel@lists.xensource.com" , Ian Jackson , "konrad.wilk@oracle.com" Subject: [Xen-devel] Re: [PATCH v3] libvchan: interdomain communications library X-BeenThere: xen-devel@lists.xensource.com X-Mailman-Version: 2.1.5 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xensource.com Errors-To: xen-devel-bounces@lists.xensource.com On Wed, 2011-08-31 at 20:17 +0100, Daniel De Graaf wrote: > > [...] > >> +static int init_gnt_srv(struct libvchan *ctrl) > >> +{ > >> + int pages_left = ctrl->read.order >= PAGE_SHIFT ? 1 << (ctrl->read.order - PAGE_SHIFT) : 0; > >> + int pages_right = ctrl->write.order >= PAGE_SHIFT ? 1 << (ctrl->write.order - PAGE_SHIFT) : 0; > >> + struct ioctl_gntalloc_alloc_gref *gref_info = NULL; > >> + int ring_fd = open("/dev/xen/gntalloc", O_RDWR); > >> + int ring_ref = -1; > >> + int err; > >> + void *ring, *area; > >> + > >> + if (ring_fd < 0) > >> + return -1; > >> + > >> + gref_info = malloc(sizeof(*gref_info) + max(pages_left, pages_right)*sizeof(uint32_t)); > >> + > >> + gref_info->domid = ctrl->other_domain_id; > >> + gref_info->flags = GNTALLOC_FLAG_WRITABLE; > >> + gref_info->count = 1; > >> + > >> + err = ioctl(ring_fd, IOCTL_GNTALLOC_ALLOC_GREF, gref_info); > > > > Unless libvchan is going to be the only user of this interface we should > > add helpful wrappers to libxc, like we do for gntdev and evtchn. > > Adding the wrappers made the library more complex with no other gains when > it was out-of-tree; for upstreaming, this does make sense. This will result > in a vchan consuming two file descriptors while it is active because the libxc > API does not expose the ability to close descriptors without unmapping memory. > Since that ability is likely to be linux-specific, it's reasonable to stop > relying on it for portability reasons. I'm not sure I understand (wouldn't you just add a gntalloc fd to libvchan and reuse it everywhere?) but if you need a new variant of a particular libxc interface with different semantics feel free to add it (or convert an existing function to it if that seems more appropriate). > >> +#ifdef IOCTL_GNTALLOC_SET_UNMAP_NOTIFY > >> + { > >> + struct ioctl_gntalloc_unmap_notify arg; > >> + arg.index = gref_info->index + offsetof(struct vchan_interface, srv_live); > >> + arg.action = UNMAP_NOTIFY_CLEAR_BYTE | UNMAP_NOTIFY_SEND_EVENT; > >> + arg.event_channel_port = ctrl->event_port; > >> + ioctl(ring_fd, IOCTL_GNTALLOC_SET_UNMAP_NOTIFY, &arg); > >> + } > >> +#endif > > > > What is the fallback if this isn't available? > > The fallback is that the notify is not sent, and the peer cannot detect when > its peer crashes or is killed instead of executing a graceful shutdown. > > Adding this functionality to libxc requires yet another wrapper on the grant > mapping functionality. Instead of attempting to pass back the index as is > done in the current version, I am considering adding the functions > xc_gnttab_map_grant_ref_notify(xcg, domid, ref, notify_offset, notify_port) and > xc_gntshr_share_page_notify(xcs, domid, &ref, notify_offset, notify_port); > these would fall back to xc_gnttab_map_grant_ref if notify is not present. You can't just add the xc_gnttab_notify() as a function which just registers the notify and use xc_gnttab_map_grant_ref + that new function? > > [...] > >> static int init_xs_srv(struct libvchan *ctrl, int ring_ref) > >> +{ > >> + int ret = -1; > >> + struct xs_handle *xs; > >> + struct xs_permissions perms[2]; > >> + char buf[64]; > >> + char ref[16]; > >> + char* domid_str = NULL; > >> + xs = xs_domain_open(); > >> + if (!xs) > >> + goto fail; > >> + domid_str = xs_read(xs, 0, "domid", NULL); > >> + if (!domid_str) > >> + goto fail_xs_open; > >> + > >> + // owner domain is us > >> + perms[0].id = atoi(domid_str); > > > > It sucks a bit that xenstore doesn't appear to allow DOMNID_SELF here > > but oh well. > > On the client side, we need to look up our own domid to find the path > (if the changes to follow usual xenstore convention are made) so it's > required either way. How do you mean? relative xenstore accesses are relative to /local/domain/ so you shouldn't need to know domid to access e.g. /local/domain//foo/bar -- just access foo/bar instead. > >> + // permissions for domains not listed = none > >> + perms[0].perms = XS_PERM_NONE; > >> + // other domains > >> + perms[1].id = ctrl->other_domain_id; > >> + perms[1].perms = XS_PERM_READ; > >> + > >> + snprintf(ref, sizeof ref, "%d", ring_ref); > >> + snprintf(buf, sizeof buf, "data/vchan/%d/ring-ref", ctrl->device_number); > >> + if (!xs_write(xs, 0, buf, ref, strlen(ref))) > >> + goto fail_xs_open; > >> + if (!xs_set_permissions(xs, 0, buf, perms, 2)) > >> + goto fail_xs_open; > >> + > >> + snprintf(ref, sizeof ref, "%d", ctrl->event_port); > >> + snprintf(buf, sizeof buf, "data/vchan/%d/event-channel", ctrl->device_number); > >> + if (!xs_write(xs, 0, buf, ref, strlen(ref))) > >> + goto fail_xs_open; > >> + if (!xs_set_permissions(xs, 0, buf, perms, 2)) > >> + goto fail_xs_open; > > > > Am I right that the intended usage model is that two domains can decide > > to setup a connection without admin or toolstack involvement? > > > > Do we need to arrange on the toolstack side that a suitable > > vchan-specific directory (or directories) in xenstore exists with > > suitable permissions to allow this to happen exists or do we think data > > is an appropriate location? > > Yes, the intended use is to avoid needing to have management tools involved > in the setup. Of course, that doesn't mean that vchan can't have help from > management tools - but since this help isn't required, adding an unneeded > dependency was pointless and might also imply a level of control that is not > actually present (i.e. restricting the management tools does not actually > restrict the ability to set up a vchan; that requires something like an XSM > policy blocking the grant or event channels). I picked data because it does > not require toolstack modification to use, and no other location jumped out > at me - vchan isn't really a device. OK. I'm a bit fearful that data may become a bit of a dumping ground (I'm not sure what its intended use/semantics actually are) but that's not the fault of this patch. Ian. _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel From xen-devel-bounces@lists.xensource.com Thu Sep 01 09:35:55 2011 Return-path: Envelope-to: www-data@lists.xensource.com Delivery-date: Thu, 01 Sep 2011 09:35:55 -0700 Received: from localhost ([127.0.0.1] helo=lists.colo.xensource.com) by lists.xensource.com with esmtp (Exim 4.43) id 1QzAF9-0003pS-6n; Thu, 01 Sep 2011 09:35:55 -0700 Received: from mail174.messagelabs.com ([85.158.138.51]) by lists.xensource.com with smtp (Exim 4.43) id 1QzAEj-0003dh-Sd for xen-devel@lists.xensource.com; Thu, 01 Sep 2011 09:35:30 -0700 X-Env-Sender: Ian.Campbell@eu.citrix.com X-Msg-Ref: server-6.tower-174.messagelabs.com!1314894926!27794006!1 X-Originating-IP: [62.200.22.115] X-StarScan-Version: 6.3.6; banners=-,-,- X-VirusChecked: Checked Received: (qmail 21592 invoked from network); 1 Sep 2011 16:35:26 -0000 Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115) by server-6.tower-174.messagelabs.com with SMTP; 1 Sep 2011 16:35:26 -0000 X-IronPort-AV: E=Sophos;i="4.68,314,1312156800"; d="scan'208";a="7559632" Received: from lonpmailmx01.citrite.net ([10.30.203.162]) by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5; 01 Sep 2011 16:35:26 +0000 Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net (10.30.203.162) with Microsoft SMTP Server id 8.3.137.0; Thu, 1 Sep 2011 17:35:26 +0100 Subject: Re: [Xen-devel] Re: [xen-unstable test] 8803: regressions - FAIL From: Ian Campbell To: Ian Jackson In-Reply-To: <20063.45421.271505.189374@mariner.uk.xensource.com> References: <20063.45421.271505.189374@mariner.uk.xensource.com> Content-Type: text/plain; charset="UTF-8" Organization: Citrix Systems, Inc. Date: Thu, 1 Sep 2011 17:35:26 +0100 Message-ID: <1314894926.28989.146.camel@zakaz.uk.xensource.com> MIME-Version: 1.0 X-Mailer: Evolution 2.32.3 Content-Transfer-Encoding: 7bit Cc: "xen-devel@lists.xensource.com" X-BeenThere: xen-devel@lists.xensource.com X-Mailman-Version: 2.1.5 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xensource.com Errors-To: xen-devel-bounces@lists.xensource.com On Thu, 2011-09-01 at 17:23 +0100, Ian Jackson wrote: > ~xen.org writes ("[xen-unstable test] 8803: regressions - FAIL"): > > flight 8803 xen-unstable real [real] > > http://www.chiark.greenend.org.uk/~xensrcts/logs/8803/ > > build-i386 4 xen-build fail REGR. vs. 8769 > > gcc -O1 -fno-omit-frame-pointer -m32 -march=i686 -g -fno-strict-aliasing -std=gnu99 -Wall -Wstrict-prototypes -Wno-unused-value -Wdeclaration-after- > statement -fno-builtin -fno-common -Wredundant-decls -iwithprefix include -Werror -Wno-pointer-arith -pipe -I/home/osstest/build.8803.build-i386/xe > n-unstable/xen/include -I/home/osstest/build.8803.build-i386/xen-unstable/xen/include/asm-x86/mach-generic -I/home/osstest/build.8803.build-i386/xe > n-unstable/xen/include/asm-x86/mach-default -msoft-float -fno-stack-protector -fno-exceptions -Wnested-externs -fno-optimize-sibling-calls -nostdinc > -g -D__XEN__ -DVERBOSE -fno-omit-frame-pointer -DCONFIG_FRAME_POINTER -MMD -MF .domain_page.o.d -c domain_page.c -o domain_page.o > domain_page.c: In function 'map_domain_page_global': > domain_page.c:211: error: negative width in bit-field '' Which is: /* At least half the ioremap space should be available to us. */ BUILD_BUG_ON(IOREMAP_VIRT_START + (IOREMAP_MBYTES << 19) >= FIXADDR_START); Looking at 8769 vs this revision my bet is: changeset: 23802:bb9b81008733 user: Laszlo Ersek date: Wed Aug 31 15:16:14 2011 +0100 files: xen/include/asm-x86/config.h description: x86: Increase the default NR_CPUS to 256 Changeset 21012:ef845a385014 bumped the default to 128 about one and a half years ago. Increase it now to 256, as systems with eg. 160 logical CPUs are becoming (have become) common. Signed-off-by: Laszlo Ersek diff -r d54cfae72cd1 -r bb9b81008733 xen/include/asm-x86/config.h --- a/xen/include/asm-x86/config.h Wed Aug 31 15:15:41 2011 +0100 +++ b/xen/include/asm-x86/config.h Wed Aug 31 15:16:14 2011 +0100 @@ -50,7 +50,7 @@ #ifdef MAX_PHYS_CPUS #define NR_CPUS MAX_PHYS_CPUS #else -#define NR_CPUS 128 +#define NR_CPUS 256 #endif #ifdef __i386__ I think we need (untested): # HG changeset patch # User Ian Campbell # Date 1314894881 -3600 # Node ID 4309ff9535001bdca8db93a439edd86bb4c447cd # Parent bb97bd46df6c6d8562759a964ebf6c31b6361a7a xen/x86: only support >128 CPUs on x86_64 32 bit cannot cope with 256 cpus and hits: /* At least half the ioremap space should be available to us. */ BUILD_BUG_ON(IOREMAP_VIRT_START + (IOREMAP_MBYTES << 19) >= FIXADDR_START); Signed-off-by: Ian Campbell diff -r bb97bd46df6c -r 4309ff953500 xen/include/asm-x86/config.h --- a/xen/include/asm-x86/config.h Thu Sep 01 16:03:21 2011 +0100 +++ b/xen/include/asm-x86/config.h Thu Sep 01 17:34:41 2011 +0100 @@ -49,6 +49,8 @@ #ifdef MAX_PHYS_CPUS #define NR_CPUS MAX_PHYS_CPUS +#elif defined __i386__ +#define NR_CPUS 128 #else #define NR_CPUS 256 #endif _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel From xen-devel-bounces@lists.xensource.com Thu Sep 01 09:37:00 2011 Return-path: Envelope-to: www-data@lists.xensource.com Delivery-date: Thu, 01 Sep 2011 09:37:00 -0700 Received: from localhost ([127.0.0.1] helo=lists.colo.xensource.com) by lists.xensource.com with esmtp (Exim 4.43) id 1QzAGC-0004CQ-2A; Thu, 01 Sep 2011 09:37:00 -0700 Received: from mail174.messagelabs.com ([85.158.138.51]) by lists.xensource.com with smtp (Exim 4.43) id 1QzAFj-00040f-Ja for xen-devel@lists.xensource.com; Thu, 01 Sep 2011 09:36:32 -0700 X-Env-Sender: Ian.Jackson@eu.citrix.com X-Msg-Ref: server-11.tower-174.messagelabs.com!1314894988!29919475!1 X-Originating-IP: [62.200.22.115] X-StarScan-Version: 6.3.6; banners=-,-,- X-VirusChecked: Checked Received: (qmail 13809 invoked from network); 1 Sep 2011 16:36:28 -0000 Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115) by server-11.tower-174.messagelabs.com with SMTP; 1 Sep 2011 16:36:28 -0000 X-IronPort-AV: E=Sophos;i="4.68,314,1312156800"; d="scan'208";a="7559676" Received: from lonpmailmx01.citrite.net ([10.30.203.162]) by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5; 01 Sep 2011 16:36:28 +0000 Received: from norwich.cam.xci-test.com (10.80.248.129) by smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id 8.3.137.0; Thu, 1 Sep 2011 17:36:28 +0100 Received: from mariner.cam.xci-test.com ([10.80.2.22] helo=mariner.uk.xensource.com ident=Debian-exim) by norwich.cam.xci-test.com with esmtp (Exim 4.72) (envelope-from ) id 1QzAFf-0006cQ-T1; Thu, 01 Sep 2011 16:36:27 +0000 Received: from iwj by mariner.uk.xensource.com with local (Exim 4.69) (envelope-from ) id 1QzAFf-0007Ui-Rk; Thu, 01 Sep 2011 17:36:27 +0100 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Message-ID: <20063.46219.852602.885928@mariner.uk.xensource.com> Date: Thu, 1 Sep 2011 17:36:27 +0100 To: Eugene Teo Subject: [Xen-devel] Re: Security vulnerability process - last call Newsgroups: chiark.mail.xen.devel In-Reply-To: References: <19998.52380.356516.189861@mariner.uk.xensource.com> X-Mailer: VM 8.0.9 under Emacs 21.4.1 (i486-pc-linux-gnu) From: Ian Jackson Cc: xen-devel@lists.xensource.com X-BeenThere: xen-devel@lists.xensource.com X-Mailman-Version: 2.1.5 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xensource.com Errors-To: xen-devel-bounces@lists.xensource.com Eugene Teo writes ("[Xen-devel] Re: Security vulnerability process - last call"): > Ian Jackson eu.citrix.com> writes: > [...] > > 1. We request that anyone who discovers a vulnerability in xen.org > > software reports this by email to security (at) xen (dot) org. > > > > (This also covers the situation where an existing published > > changeset is retrospectively found to be a security fix.) > > For this situation, the patch is already made public. Such > information should be shared with both the pre-disclosure and > oss-security lists immediately, so that we can avoid having > duplicated CVE names assigned. "Immediately" might be OK for oss-security. But the I don't think we want to send half-digested information to the predisclosure list. I will add something to the draft to say we will tell oss-security right away in this situation. > > (d) If we think other software systems (for example, competing > > hypervisor systems) are likely to be affected by the same > > vulnerability, we will try to make those other projects aware > > of the problem and include them in the advisory preparation > > process. (This may rely on the other project(s) having > > documented and responsive security contact points.) > > There's linux-distros@vs.openwall.org if you are unable to find the > necessary security contacts. Noted, thanks. > > 3. Advisory public release: > > > > At the embargo date we will publish the advisory, and push > > bugfix changesets to public revision control trees. > > Perhaps be a bit more specific. At which timezone will the advisory be > published? For the folks in Asia Pacific, this could mean a public pre- > disclosure of about 12 hours or more if security (at) xen is based in the > States. As Ian C said, the advisory will state the a specific time, with timezone, for the end of the embargo. That will probably normally be between 1200 UTC and 1600 UTC simply because of the timezone where most of the xen.org security team are based. Do you need something specific written in the process document about this ? > > Public advisories will be posted to xen-devel. > > > > Copies will also be sent to the pre-disclosure list, unless > > the advisory was already sent there previously during the embargo > > period and has not been updated since. > > And the oss-security list. Right. > > Specifically, prior to the embargo date, pre-disclosure list members > > should not make available, even to their own customers and partners: > > - the Xen.org advisory > > - their own advisory > > - revision control commits which are a fix for the problem > > - patched software (even in binary form) > > without prior consultation with security xen and/or the discoverer. > > Shouldn't this be "and", instead of "and/or"? And shouldn't this > includes prior consultation with the list members too? I think if the discoverer tells a downstream to publish something, and doesn't consult us, that's up to the discoverer. It shouldn't include prior consultation with the pre-disclosure list members because that's not a discussion list. Ian. _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel From xen-devel-bounces@lists.xensource.com Thu Sep 01 09:47:49 2011 Return-path: Envelope-to: www-data@lists.xensource.com Delivery-date: Thu, 01 Sep 2011 09:47:49 -0700 Received: from localhost ([127.0.0.1] helo=lists.colo.xensource.com) by lists.xensource.com with esmtp (Exim 4.43) id 1QzAQf-0004s5-2k; Thu, 01 Sep 2011 09:47:49 -0700 Received: from mail21.messagelabs.com ([85.158.143.35]) by lists.xensource.com with esmtp (Exim 4.43) id 1QzAPy-0004gG-5W for xen-devel@lists.xensource.com; Thu, 01 Sep 2011 09:47:06 -0700 X-Env-Sender: jeremy@goop.org X-Msg-Ref: server-2.tower-21.messagelabs.com!1314895621!32517743!1 X-Originating-IP: [74.207.240.146] X-StarScan-Version: 6.3.6; banners=-,-,- X-VirusChecked: Checked Received: (qmail 3889 invoked from network); 1 Sep 2011 16:47:02 -0000 Received: from claw.goop.org (HELO claw.goop.org) (74.207.240.146) by server-2.tower-21.messagelabs.com with DHE-RSA-AES256-SHA encrypted SMTP; 1 Sep 2011 16:47:02 -0000 Received: from saboo.goop.org (c-50-131-57-2.hsd1.ca.comcast.net [50.131.57.2]) (Authenticated sender: smtp-saboo) by claw.goop.org (Postfix) with ESMTPSA id D74B6212; Thu, 1 Sep 2011 09:47:00 -0700 (PDT) Received: from saboo.goop.org (localhost [IPv6:::1]) by saboo.goop.org (Postfix) with ESMTP id 30DFA20255; Thu, 1 Sep 2011 09:46:56 -0700 (PDT) Message-ID: <4E5FB700.1070908@goop.org> Date: Thu, 01 Sep 2011 09:46:56 -0700 From: Jeremy Fitzhardinge User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:6.0) Gecko/20110816 Thunderbird/6.0 MIME-Version: 1.0 To: Igor Mammedov References: <4E5EB794.7050909@goop.org> <1314877615-18280-1-git-send-email-imammedo@redhat.com> In-Reply-To: <1314877615-18280-1-git-send-email-imammedo@redhat.com> X-Enigmail-Version: 1.3.1 Content-Type: text/plain; charset=ISO-8859-15 Content-Transfer-Encoding: 7bit Cc: xen-devel@lists.xensource.com, linux-kernel@vger.kernel.org, konrad.wilk@oracle.com Subject: [Xen-devel] Re: [PATCH v2] xen: x86_32: do not enable iterrupts when returning from exception in interrupt context X-BeenThere: xen-devel@lists.xensource.com X-Mailman-Version: 2.1.5 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xensource.com Errors-To: xen-devel-bounces@lists.xensource.com On 09/01/2011 04:46 AM, Igor Mammedov wrote: > If vmalloc page_fault happens inside of interrupt handler with interrupts > disabled then on exit path from exception handler when there is no pending > interrupts, the following code (arch/x86/xen/xen-asm_32.S:112): > > cmpw $0x0001, XEN_vcpu_info_pending(%eax) > sete XEN_vcpu_info_mask(%eax) > > will enable interrupts even if they has been previously disabled according to > eflags from the bounce frame (arch/x86/xen/xen-asm_32.S:99) > > testb $X86_EFLAGS_IF>>8, 8+1+ESP_OFFSET(%esp) > setz XEN_vcpu_info_mask(%eax) > > Solution is in setting XEN_vcpu_info_mask only when it should be set > according to > cmpw $0x0001, XEN_vcpu_info_pending(%eax) > but not clearing it if there isn't any pending events. > > Reproducer for bug is attached to RHBZ 707552 > > Signed-off-by: Igor Mammedov > Signed-off-by: Jeremy Fitzhardinge One nit, this should be acked-by or reviewed-by, not signed-off-by, since the patch isn't passing through my hands. J _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel From xen-devel-bounces@lists.xensource.com Thu Sep 01 09:49:03 2011 Return-path: Envelope-to: www-data@lists.xensource.com Delivery-date: Thu, 01 Sep 2011 09:49:03 -0700 Received: from localhost ([127.0.0.1] helo=lists.colo.xensource.com) by lists.xensource.com with esmtp (Exim 4.43) id 1QzARr-0005Jz-0j; Thu, 01 Sep 2011 09:49:03 -0700 Received: from mail21.messagelabs.com ([85.158.143.35]) by lists.xensource.com with smtp (Exim 4.43) id 1QzAQX-0004p1-FT for xen-devel@lists.xensource.com; Thu, 01 Sep 2011 09:47:42 -0700 X-Env-Sender: dgdegra@tycho.nsa.gov X-Msg-Ref: server-4.tower-21.messagelabs.com!1314895625!58635822!1 X-Originating-IP: [63.239.65.39] X-StarScan-Version: 6.3.6; banners=-,-,- X-VirusChecked: Checked Received: (qmail 14987 invoked from network); 1 Sep 2011 16:47:05 -0000 Received: from msux-gh1-uea01.nsa.gov (HELO msux-gh1-uea01.nsa.gov) (63.239.65.39) by server-4.tower-21.messagelabs.com with SMTP; 1 Sep 2011 16:47:05 -0000 Received: from tarius.tycho.ncsc.mil (localhost [127.0.0.1]) by msux-gh1-uea01.nsa.gov (8.12.10/8.12.10) with ESMTP id p81GlaMm009338; Thu, 1 Sep 2011 16:47:36 GMT Received: from moss-nexus.epoch.ncsc.mil (moss-nexus [144.51.25.48]) by tarius.tycho.ncsc.mil (8.13.1/8.13.1) with ESMTP id p81GlZPT010651; Thu, 1 Sep 2011 12:47:35 -0400 Message-ID: <4E5FB72B.7010200@tycho.nsa.gov> Date: Thu, 01 Sep 2011 12:47:39 -0400 From: Daniel De Graaf Organization: National Security Agency User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:5.0) Gecko/20110707 Thunderbird/5.0 MIME-Version: 1.0 To: Ian Campbell References: <20055.42803.979775.531468@mariner.uk.xensource.com> <1314643714-28350-1-git-send-email-dgdegra@tycho.nsa.gov> <1314700361.10283.135.camel@zakaz.uk.xensource.com> <4E5E88CF.7090408@tycho.nsa.gov> <1314894519.28989.143.camel@zakaz.uk.xensource.com> In-Reply-To: <1314894519.28989.143.camel@zakaz.uk.xensource.com> X-Enigmail-Version: 1.2.1 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Cc: Stefano Stabellini , "xen-devel@lists.xensource.com" , Ian Jackson , "konrad.wilk@oracle.com" Subject: [Xen-devel] Re: [PATCH v3] libvchan: interdomain communications library X-BeenThere: xen-devel@lists.xensource.com X-Mailman-Version: 2.1.5 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xensource.com Errors-To: xen-devel-bounces@lists.xensource.com On 09/01/2011 12:28 PM, Ian Campbell wrote: > On Wed, 2011-08-31 at 20:17 +0100, Daniel De Graaf wrote: >>> [...] >>>> +static int init_gnt_srv(struct libvchan *ctrl) >>>> +{ >>>> + int pages_left = ctrl->read.order >= PAGE_SHIFT ? 1 << (ctrl->read.order - PAGE_SHIFT) : 0; >>>> + int pages_right = ctrl->write.order >= PAGE_SHIFT ? 1 << (ctrl->write.order - PAGE_SHIFT) : 0; >>>> + struct ioctl_gntalloc_alloc_gref *gref_info = NULL; >>>> + int ring_fd = open("/dev/xen/gntalloc", O_RDWR); >>>> + int ring_ref = -1; >>>> + int err; >>>> + void *ring, *area; >>>> + >>>> + if (ring_fd < 0) >>>> + return -1; >>>> + >>>> + gref_info = malloc(sizeof(*gref_info) + max(pages_left, pages_right)*sizeof(uint32_t)); >>>> + >>>> + gref_info->domid = ctrl->other_domain_id; >>>> + gref_info->flags = GNTALLOC_FLAG_WRITABLE; >>>> + gref_info->count = 1; >>>> + >>>> + err = ioctl(ring_fd, IOCTL_GNTALLOC_ALLOC_GREF, gref_info); >>> >>> Unless libvchan is going to be the only user of this interface we should >>> add helpful wrappers to libxc, like we do for gntdev and evtchn. >> >> Adding the wrappers made the library more complex with no other gains when >> it was out-of-tree; for upstreaming, this does make sense. This will result >> in a vchan consuming two file descriptors while it is active because the libxc >> API does not expose the ability to close descriptors without unmapping memory. >> Since that ability is likely to be linux-specific, it's reasonable to stop >> relying on it for portability reasons. > > I'm not sure I understand (wouldn't you just add a gntalloc fd to > libvchan and reuse it everywhere?) but if you need a new variant of a > particular libxc interface with different semantics feel free to add it > (or convert an existing function to it if that seems more appropriate). The previous version of libvchan closed the gntalloc file descriptor during the initialization. This is unlikely to be portable when abstracted to close the entire gntshr interface. Making this change has exposed an interesting ordering dependency in the notify API under Linux: the file descriptor for gntdev or gntalloc must be less than the file descriptor for evtchn in order for the event channel to still be active when the unmap occurs on a crash. The init functions of libvchan do open the files in the proper order for this to happen. >>>> +#ifdef IOCTL_GNTALLOC_SET_UNMAP_NOTIFY >>>> + { >>>> + struct ioctl_gntalloc_unmap_notify arg; >>>> + arg.index = gref_info->index + offsetof(struct vchan_interface, srv_live); >>>> + arg.action = UNMAP_NOTIFY_CLEAR_BYTE | UNMAP_NOTIFY_SEND_EVENT; >>>> + arg.event_channel_port = ctrl->event_port; >>>> + ioctl(ring_fd, IOCTL_GNTALLOC_SET_UNMAP_NOTIFY, &arg); >>>> + } >>>> +#endif >>> >>> What is the fallback if this isn't available? >> >> The fallback is that the notify is not sent, and the peer cannot detect when >> its peer crashes or is killed instead of executing a graceful shutdown. >> >> Adding this functionality to libxc requires yet another wrapper on the grant >> mapping functionality. Instead of attempting to pass back the index as is >> done in the current version, I am considering adding the functions >> xc_gnttab_map_grant_ref_notify(xcg, domid, ref, notify_offset, notify_port) and >> xc_gntshr_share_page_notify(xcs, domid, &ref, notify_offset, notify_port); >> these would fall back to xc_gnttab_map_grant_ref if notify is not present. > > You can't just add the xc_gnttab_notify() as a function which just > registers the notify and use xc_gnttab_map_grant_ref + that new > function? This is possible, but you would need to pass back the index used to mmap or keep metadata within the file descriptor to allow this to be determined. Since the current xc_* mapping interfaces do not expose this index, it would require a larger change to expose this mostly-useless index just for the purpose of passing it to the notify call. >>> [...] >>>> static int init_xs_srv(struct libvchan *ctrl, int ring_ref) >>>> +{ >>>> + int ret = -1; >>>> + struct xs_handle *xs; >>>> + struct xs_permissions perms[2]; >>>> + char buf[64]; >>>> + char ref[16]; >>>> + char* domid_str = NULL; >>>> + xs = xs_domain_open(); >>>> + if (!xs) >>>> + goto fail; >>>> + domid_str = xs_read(xs, 0, "domid", NULL); >>>> + if (!domid_str) >>>> + goto fail_xs_open; >>>> + >>>> + // owner domain is us >>>> + perms[0].id = atoi(domid_str); >>> >>> It sucks a bit that xenstore doesn't appear to allow DOMNID_SELF here >>> but oh well. >> >> On the client side, we need to look up our own domid to find the path >> (if the changes to follow usual xenstore convention are made) so it's >> required either way. > > How do you mean? relative xenstore accesses are relative > to /local/domain/ so you shouldn't need to know domid to access > e.g. /local/domain//foo/bar -- just access foo/bar instead. > Yes, but the client doesn't use a path relative to its own domid. It uses /local/domain//data/vchan///... Devices work around this problem by having xl or xm fill in paths under both /local/domain/ and /local/domain/ pointing to each other; using this style of path is not possible without some side knowing its own domain ID. Is reading "domid" the best method for determining the domain ID of the local domain? I noticed in testing that it may need to be set for dom0 if only the xl tools are used in domain creation. >>>> + // permissions for domains not listed = none >>>> + perms[0].perms = XS_PERM_NONE; >>>> + // other domains >>>> + perms[1].id = ctrl->other_domain_id; >>>> + perms[1].perms = XS_PERM_READ; >>>> + >>>> + snprintf(ref, sizeof ref, "%d", ring_ref); >>>> + snprintf(buf, sizeof buf, "data/vchan/%d/ring-ref", ctrl->device_number); >>>> + if (!xs_write(xs, 0, buf, ref, strlen(ref))) >>>> + goto fail_xs_open; >>>> + if (!xs_set_permissions(xs, 0, buf, perms, 2)) >>>> + goto fail_xs_open; >>>> + >>>> + snprintf(ref, sizeof ref, "%d", ctrl->event_port); >>>> + snprintf(buf, sizeof buf, "data/vchan/%d/event-channel", ctrl->device_number); >>>> + if (!xs_write(xs, 0, buf, ref, strlen(ref))) >>>> + goto fail_xs_open; >>>> + if (!xs_set_permissions(xs, 0, buf, perms, 2)) >>>> + goto fail_xs_open; >>> >>> Am I right that the intended usage model is that two domains can decide >>> to setup a connection without admin or toolstack involvement? >>> >>> Do we need to arrange on the toolstack side that a suitable >>> vchan-specific directory (or directories) in xenstore exists with >>> suitable permissions to allow this to happen exists or do we think data >>> is an appropriate location? >> >> Yes, the intended use is to avoid needing to have management tools involved >> in the setup. Of course, that doesn't mean that vchan can't have help from >> management tools - but since this help isn't required, adding an unneeded >> dependency was pointless and might also imply a level of control that is not >> actually present (i.e. restricting the management tools does not actually >> restrict the ability to set up a vchan; that requires something like an XSM >> policy blocking the grant or event channels). I picked data because it does >> not require toolstack modification to use, and no other location jumped out >> at me - vchan isn't really a device. > > OK. I'm a bit fearful that data may become a bit of a dumping ground > (I'm not sure what its intended use/semantics actually are) but that's > not the fault of this patch. > > Ian. > -- Daniel De Graaf National Security Agency _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel From xen-devel-bounces@lists.xensource.com Thu Sep 01 09:55:32 2011 Return-path: Envelope-to: www-data@lists.xensource.com Delivery-date: Thu, 01 Sep 2011 09:55:32 -0700 Received: from localhost ([127.0.0.1] helo=lists.colo.xensource.com) by lists.xensource.com with esmtp (Exim 4.43) id 1QzAY8-0005t5-Hf; Thu, 01 Sep 2011 09:55:32 -0700 Received: from mail27.messagelabs.com ([193.109.254.147]) by lists.xensource.com with smtp (Exim 4.43) id 1QzAXe-0005gU-RQ for xen-devel@lists.xensource.com; Thu, 01 Sep 2011 09:55:03 -0700 X-Env-Sender: Ian.Jackson@eu.citrix.com X-Msg-Ref: server-9.tower-27.messagelabs.com!1314896085!42793374!1 X-Originating-IP: [62.200.22.115] X-StarScan-Version: 6.3.6; banners=-,-,- X-VirusChecked: Checked Received: (qmail 21607 invoked from network); 1 Sep 2011 16:54:45 -0000 Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115) by server-9.tower-27.messagelabs.com with SMTP; 1 Sep 2011 16:54:45 -0000 X-IronPort-AV: E=Sophos;i="4.68,314,1312156800"; d="scan'208";a="7559959" Received: from lonpmailmx01.citrite.net ([10.30.203.162]) by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5; 01 Sep 2011 16:54:59 +0000 Received: from norwich.cam.xci-test.com (10.80.248.129) by smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id 8.3.137.0; Thu, 1 Sep 2011 17:54:59 +0100 Received: from mariner.cam.xci-test.com ([10.80.2.22] helo=mariner.uk.xensource.com ident=Debian-exim) by norwich.cam.xci-test.com with esmtp (Exim 4.72) (envelope-from ) id 1QzAXb-0006hH-F2; Thu, 01 Sep 2011 16:54:59 +0000 Received: from iwj by mariner.uk.xensource.com with local (Exim 4.69) (envelope-from ) id 1QzAXb-0007W9-E0; Thu, 01 Sep 2011 17:54:59 +0100 Message-ID: <20063.47331.426650.5120@mariner.uk.xensource.com> Date: Thu, 1 Sep 2011 17:54:59 +0100 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit To: Ian Campbell Subject: Re: [Xen-devel] Re: [xen-unstable test] 8803: regressions - FAIL In-Reply-To: <1314894926.28989.146.camel@zakaz.uk.xensource.com> References: <20063.45421.271505.189374@mariner.uk.xensource.com> <1314894926.28989.146.camel@zakaz.uk.xensource.com> X-Mailer: VM 8.0.9 under Emacs 21.4.1 (i486-pc-linux-gnu) From: Ian Jackson Cc: "xen-devel@lists.xensource.com" , Ersek , Laszlo X-BeenThere: xen-devel@lists.xensource.com X-Mailman-Version: 2.1.5 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xensource.com Errors-To: xen-devel-bounces@lists.xensource.com Ian Campbell writes ("Re: [Xen-devel] Re: [xen-unstable test] 8803: regressions - FAIL"): > I think we need (untested): Thanks. This is indeed the cause of the "RHEL6" test failure, which if I actually read it properly fails at the stage of "install xen", because Xen didn't build properly. Ian. > On Thu, 2011-09-01 at 17:23 +0100, Ian Jackson wrote: > > ~xen.org writes ("[xen-unstable test] 8803: regressions - FAIL"): > > > flight 8803 xen-unstable real [real] > > > http://www.chiark.greenend.org.uk/~xensrcts/logs/8803/ > > > build-i386 4 xen-build fail REGR. vs. 8769 > > > > gcc -O1 -fno-omit-frame-pointer -m32 -march=i686 -g -fno-strict-aliasing -std=gnu99 -Wall -Wstrict-prototypes -Wno-unused-value -Wdeclaration-after- > > statement -fno-builtin -fno-common -Wredundant-decls -iwithprefix include -Werror -Wno-pointer-arith -pipe -I/home/osstest/build.8803.build-i386/xe > > n-unstable/xen/include -I/home/osstest/build.8803.build-i386/xen-unstable/xen/include/asm-x86/mach-generic -I/home/osstest/build.8803.build-i386/xe > > n-unstable/xen/include/asm-x86/mach-default -msoft-float -fno-stack-protector -fno-exceptions -Wnested-externs -fno-optimize-sibling-calls -nostdinc > > -g -D__XEN__ -DVERBOSE -fno-omit-frame-pointer -DCONFIG_FRAME_POINTER -MMD -MF .domain_page.o.d -c domain_page.c -o domain_page.o > > domain_page.c: In function 'map_domain_page_global': > > domain_page.c:211: error: negative width in bit-field '' > > Which is: > /* At least half the ioremap space should be available to us. */ > BUILD_BUG_ON(IOREMAP_VIRT_START + (IOREMAP_MBYTES << 19) >= FIXADDR_START); > > Looking at 8769 vs this revision my bet is: > > changeset: 23802:bb9b81008733 > user: Laszlo Ersek > date: Wed Aug 31 15:16:14 2011 +0100 > files: xen/include/asm-x86/config.h > description: > x86: Increase the default NR_CPUS to 256 > > Changeset 21012:ef845a385014 bumped the default to 128 about one and a > half years ago. Increase it now to 256, as systems with eg. 160 > logical CPUs are becoming (have become) common. > > Signed-off-by: Laszlo Ersek > > > diff -r d54cfae72cd1 -r bb9b81008733 xen/include/asm-x86/config.h > --- a/xen/include/asm-x86/config.h Wed Aug 31 15:15:41 2011 +0100 > +++ b/xen/include/asm-x86/config.h Wed Aug 31 15:16:14 2011 +0100 > @@ -50,7 +50,7 @@ > #ifdef MAX_PHYS_CPUS > #define NR_CPUS MAX_PHYS_CPUS > #else > -#define NR_CPUS 128 > +#define NR_CPUS 256 > #endif > > #ifdef __i386__ > > I think we need (untested): > > # HG changeset patch > # User Ian Campbell > # Date 1314894881 -3600 > # Node ID 4309ff9535001bdca8db93a439edd86bb4c447cd > # Parent bb97bd46df6c6d8562759a964ebf6c31b6361a7a > xen/x86: only support >128 CPUs on x86_64 > > 32 bit cannot cope with 256 cpus and hits: > > /* At least half the ioremap space should be available to us. */ > BUILD_BUG_ON(IOREMAP_VIRT_START + (IOREMAP_MBYTES << 19) >= FIXADDR_START); > > Signed-off-by: Ian Campbell > > diff -r bb97bd46df6c -r 4309ff953500 xen/include/asm-x86/config.h > --- a/xen/include/asm-x86/config.h Thu Sep 01 16:03:21 2011 +0100 > +++ b/xen/include/asm-x86/config.h Thu Sep 01 17:34:41 2011 +0100 > @@ -49,6 +49,8 @@ > > #ifdef MAX_PHYS_CPUS > #define NR_CPUS MAX_PHYS_CPUS > +#elif defined __i386__ > +#define NR_CPUS 128 > #else > #define NR_CPUS 256 > #endif > > _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel From xen-devel-bounces@lists.xensource.com Thu Sep 01 09:57:32 2011 Return-path: Envelope-to: www-data@lists.xensource.com Delivery-date: Thu, 01 Sep 2011 09:57:32 -0700 Received: from localhost ([127.0.0.1] helo=lists.colo.xensource.com) by lists.xensource.com with esmtp (Exim 4.43) id 1QzAa3-0006Kd-UO; Thu, 01 Sep 2011 09:57:32 -0700 Received: from mail21.messagelabs.com ([85.158.143.35]) by lists.xensource.com with smtp (Exim 4.43) id 1QzAZR-00064k-4R for xen-devel@lists.xensource.com; Thu, 01 Sep 2011 09:56:53 -0700 X-Env-Sender: Ian.Jackson@eu.citrix.com X-Msg-Ref: server-13.tower-21.messagelabs.com!1314896205!47342375!1 X-Originating-IP: [62.200.22.115] X-StarScan-Version: 6.3.6; banners=-,-,- X-VirusChecked: Checked Received: (qmail 30991 invoked from network); 1 Sep 2011 16:56:45 -0000 Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115) by server-13.tower-21.messagelabs.com with SMTP; 1 Sep 2011 16:56:45 -0000 X-IronPort-AV: E=Sophos;i="4.68,314,1312156800"; d="scan'208";a="7559998" Received: from lonpmailmx01.citrite.net ([10.30.203.162]) by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5; 01 Sep 2011 16:56:49 +0000 Received: from norwich.cam.xci-test.com (10.80.248.129) by smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id 8.3.137.0; Thu, 1 Sep 2011 17:56:49 +0100 Received: from mariner.cam.xci-test.com ([10.80.2.22] helo=mariner.uk.xensource.com ident=Debian-exim) by norwich.cam.xci-test.com with esmtp (Exim 4.72) (envelope-from ) id 1QzAZN-0006hp-Js; Thu, 01 Sep 2011 16:56:49 +0000 Received: from iwj by mariner.uk.xensource.com with local (Exim 4.69) (envelope-from ) id 1QzAZN-0007WL-Is; Thu, 01 Sep 2011 17:56:49 +0100 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Message-ID: <20063.47441.576537.375177@mariner.uk.xensource.com> Date: Thu, 1 Sep 2011 17:56:49 +0100 To: Daniel De Graaf In-Reply-To: <4E5FB72B.7010200@tycho.nsa.gov> References: <20055.42803.979775.531468@mariner.uk.xensource.com> <1314643714-28350-1-git-send-email-dgdegra@tycho.nsa.gov> <1314700361.10283.135.camel@zakaz.uk.xensource.com> <4E5E88CF.7090408@tycho.nsa.gov> <1314894519.28989.143.camel@zakaz.uk.xensource.com> <4E5FB72B.7010200@tycho.nsa.gov> X-Mailer: VM 8.0.9 under Emacs 21.4.1 (i486-pc-linux-gnu) From: Ian Jackson Cc: Ian Campbell , "xen-devel@lists.xensource.com" , Stefano Stabellini , "konrad.wilk@oracle.com" Subject: [Xen-devel] Re: [PATCH v3] libvchan: interdomain communications library X-BeenThere: xen-devel@lists.xensource.com X-Mailman-Version: 2.1.5 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xensource.com Errors-To: xen-devel-bounces@lists.xensource.com Daniel De Graaf writes ("Re: [PATCH v3] libvchan: interdomain communications library"): > Making this change has exposed an interesting ordering dependency in the > notify API under Linux: the file descriptor for gntdev or gntalloc must be > less than the file descriptor for evtchn in order for the event channel to > still be active when the unmap occurs on a crash. The init functions of > libvchan do open the files in the proper order for this to happen. Wow, that's pretty crazy. Surely the gnt* fd should have an internal reference to the evtchn fd ? Ian. _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel From xen-devel-bounces@lists.xensource.com Thu Sep 01 10:15:13 2011 Return-path: Envelope-to: www-data@lists.xensource.com Delivery-date: Thu, 01 Sep 2011 10:15:13 -0700 Received: from localhost ([127.0.0.1] helo=lists.colo.xensource.com) by lists.xensource.com with esmtp (Exim 4.43) id 1QzArB-0008U3-Dd; Thu, 01 Sep 2011 10:15:13 -0700 Received: from mail27.messagelabs.com ([193.109.254.147]) by lists.xensource.com with esmtp (Exim 4.43) id 1QzAow-0007dx-Oz for xen-devel@lists.xensource.com; Thu, 01 Sep 2011 10:12:55 -0700 X-Env-Sender: yujiageng734@gmail.com X-Msg-Ref: server-6.tower-27.messagelabs.com!1314897154!47239925!1 X-Originating-IP: [74.125.83.43] X-StarScan-Version: 6.3.6; banners=-,-,- X-VirusChecked: Checked Received: (qmail 10062 invoked from network); 1 Sep 2011 17:12:35 -0000 Received: from mail-gw0-f43.google.com (HELO mail-gw0-f43.google.com) (74.125.83.43) by server-6.tower-27.messagelabs.com with RC4-SHA encrypted SMTP; 1 Sep 2011 17:12:35 -0000 Received: by gwm11 with SMTP id 11so1521569gwm.30 for ; Thu, 01 Sep 2011 10:12:50 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; bh=r8VKYusOW1HkVBZ5SHfGYuLUt41cc1Jq/exxp67+Q9A=; b=KAzWHlQjL1ETa9Z+ya7MfNvoJpgDg2fQW2IJ663ToqJWNFPTYzuS3cHEJsiPhMmP5w fcZlFRKD3xPzzUvkH6bGbiDhnPESWeUOIq5HL+HpIVUnwjQQy7624q6wpAbJ0ZlHw+LF QzUDdu9UgG/C1Z1hIBSJSDEO9JsRvee2rNmzE= MIME-Version: 1.0 Received: by 10.42.74.202 with SMTP id x10mr56071icj.295.1314897170105; Thu, 01 Sep 2011 10:12:50 -0700 (PDT) Received: by 10.42.108.71 with HTTP; Thu, 1 Sep 2011 10:12:50 -0700 (PDT) In-Reply-To: References: Date: Fri, 2 Sep 2011 01:12:50 +0800 Message-ID: Subject: Re: [Xen-devel] Re: Linux Stubdom Problem From: Jiageng Yu To: Keir Fraser Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Cc: "xen-devel@lists.xensource.com" , Konrad Rzeszutek Wilk , Stefano Stabellini , Tim Deegan , Ian Campbell , Anthony PERARD , Thibault X-BeenThere: xen-devel@lists.xensource.com X-Mailman-Version: 2.1.5 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xensource.com Errors-To: xen-devel-bounces@lists.xensource.com 2011/8/31 Keir Fraser : > On 29/08/2011 17:03, "Stefano Stabellini" > wrote: > >>> Oh, so it will. =C2=A0You'd need to arrange for that to be called from = inside >>> the guest; or you could implement an add_to_physmap space for it; that >>> could be called from another domain. >> >> "From inside the guest" means hvmloader? >> The good thing about doing it in hvmloader is that we could use the >> traditional PV frontend/backend mechanism to share pages. On the other >> hand hvmloader doesn't know if we are using stubdoms at the moment and >> it would need to issue the grant table hypercall only in that case. >> Unless we decide to always grant the videoram to guests but it would >> change once again the domain to which the videoram is accounted for >> (dom0/stubdom rather than the guest, that is a bad thing). >> Also I don't like the idea of making hvmloader stubdom aware. > > I don't see a problem with it, in principle. I see hvmloader as almost an > in-guest part of the toolstack. The fact that it only executes at guest b= oot > means it can be fairly closely tied to the toolstack version. > > =C2=A0-- Keir > > > Hi all, I report a new issue about vram mapping in linux stubdom. I use the follow patch to map the mfn of stubdom into hvm guest. diff -r 0f36c2eec2e1 xen/arch/x86/mm.c --- a/xen/arch/x86/mm.c Thu Jul 28 15:40:54 2011 +0100 +++ b/xen/arch/x86/mm.c Thu Sep 01 14:52:25 2011 +0100 @@ -4663,6 +4665,14 @@ page =3D mfn_to_page(mfn); break; } + case XENMAPSPACE_mfn: + { + if(!IS_PRIV_FOR(current->domain, d)) + return -EINVAL; + mfn =3D xatp.idx; + page =3D mfn_to_page(mfn); + break; + } default: break; } @@ -4693,13 +4708,17 @@ } /* Unmap from old location, if any. */ - gpfn =3D get_gpfn_from_mfn(mfn); - ASSERT( gpfn !=3D SHARED_M2P_ENTRY ); - if ( gpfn !=3D INVALID_M2P_ENTRY ) - guest_physmap_remove_page(d, gpfn, mfn, 0); + if(xatp.space!=3DXENMAPSPACE_mfn) { + gpfn =3D get_gpfn_from_mfn(mfn); + ASSERT( gpfn !=3D SHARED_M2P_ENTRY ); + if ( gpfn !=3D INVALID_M2P_ENTRY ) + guest_physmap_remove_page(d, gpfn, mfn, 0); + } /* Map at new location. */ rc =3D guest_physmap_add_page(d, xatp.gpfn, mfn, 0); diff -r 0f36c2eec2e1 xen/include/public/memory.h --- a/xen/include/public/memory.h Thu Jul 28 15:40:54 2011 +0100 +++ b/xen/include/public/memory.h Thu Sep 01 14:52:25 2011 +0100 @@ -212,6 +212,7 @@ #define XENMAPSPACE_shared_info 0 /* shared info page */ #define XENMAPSPACE_grant_table 1 /* grant table page */ #define XENMAPSPACE_gmfn 2 /* GMFN */ +#define XENMAPSPACE_mfn 3 /* MFN */ unsigned int space; #define XENMAPIDX_grant_table_status 0x80000000 I got error at: arch_memory_op() -->case XENMEM_add_to_physmap: -->if ( page ) -->put_page(page); -->free_domheap_page(page); -->BUG_ON((pg[i].u.inuse.type_info & PGT_count_mask) !=3D 0); In my case, pg[i].u.inuse.type_info & PGT_count_mask =3D1. Actually, in the linux based stubdom case, I need to keep these pages of vram mapped in qemu of stubdom. But it seems that granting pages implies having the pages unmapped in the process that grants them. Maybe the grant table could not solve the vram mapping problem. Thanks, Jiageng Yu. _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel From xen-devel-bounces@lists.xensource.com Thu Sep 01 10:28:05 2011 Return-path: Envelope-to: www-data@lists.xensource.com Delivery-date: Thu, 01 Sep 2011 10:28:05 -0700 Received: from localhost ([127.0.0.1] helo=lists.colo.xensource.com) by lists.xensource.com with esmtp (Exim 4.43) id 1QzB3c-0000bI-8T; Thu, 01 Sep 2011 10:28:05 -0700 Received: from mail182.messagelabs.com ([85.158.139.83]) by lists.xensource.com with esmtp (Exim 4.43) id 1QzB39-0000Oy-B4 for xen-devel@lists.xensource.com; Thu, 01 Sep 2011 10:27:36 -0700 X-Env-Sender: tim@xen.org X-Msg-Ref: server-7.tower-182.messagelabs.com!1314898052!11712794!1 X-Originating-IP: [81.29.64.94] X-StarScan-Version: 6.3.6; banners=-,-,- X-VirusChecked: Checked Received: (qmail 27641 invoked from network); 1 Sep 2011 17:27:32 -0000 Received: from ocelot.phlegethon.org (HELO mail.phlegethon.org) (81.29.64.94) by server-7.tower-182.messagelabs.com with DHE-RSA-AES256-SHA encrypted SMTP; 1 Sep 2011 17:27:32 -0000 Received: from tjd by mail.phlegethon.org with local (Exim 4.67 (FreeBSD)) (envelope-from ) id 1QzB32-0002mx-79; Thu, 01 Sep 2011 17:27:28 +0000 Date: Thu, 1 Sep 2011 18:27:28 +0100 From: Tim Deegan To: Jiageng Yu Subject: Re: [Xen-devel] Re: Linux Stubdom Problem Message-ID: <20110901172728.GH3859@ocelot.phlegethon.org> References: Mime-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: User-Agent: Mutt/1.4.2.1i Cc: "xen-devel@lists.xensource.com" , Konrad Rzeszutek Wilk , Stefano Stabellini , Ian Campbell , Keir Fraser , Anthony PERARD , Thibault X-BeenThere: xen-devel@lists.xensource.com X-Mailman-Version: 2.1.5 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xensource.com Errors-To: xen-devel-bounces@lists.xensource.com At 01:12 +0800 on 02 Sep (1314925970), Jiageng Yu wrote: > 2011/8/31 Keir Fraser : > > On 29/08/2011 17:03, "Stefano Stabellini" > > wrote: > > > >>> Oh, so it will.  You'd need to arrange for that to be called from inside > >>> the guest; or you could implement an add_to_physmap space for it; that > >>> could be called from another domain. > >> > >> "From inside the guest" means hvmloader? > >> The good thing about doing it in hvmloader is that we could use the > >> traditional PV frontend/backend mechanism to share pages. On the other > >> hand hvmloader doesn't know if we are using stubdoms at the moment and > >> it would need to issue the grant table hypercall only in that case. > >> Unless we decide to always grant the videoram to guests but it would > >> change once again the domain to which the videoram is accounted for > >> (dom0/stubdom rather than the guest, that is a bad thing). > >> Also I don't like the idea of making hvmloader stubdom aware. > > > > I don't see a problem with it, in principle. I see hvmloader as almost an > > in-guest part of the toolstack. The fact that it only executes at guest boot > > means it can be fairly closely tied to the toolstack version. > > > >  -- Keir > > > > > > > > Hi all, > > I report a new issue about vram mapping in linux stubdom. I use > the follow patch to map the mfn of stubdom into hvm guest. > > diff -r 0f36c2eec2e1 xen/arch/x86/mm.c > --- a/xen/arch/x86/mm.c Thu Jul 28 15:40:54 2011 +0100 > +++ b/xen/arch/x86/mm.c Thu Sep 01 14:52:25 2011 +0100 > @@ -4663,6 +4665,14 @@ > page = mfn_to_page(mfn); > break; > } > + case XENMAPSPACE_mfn: > + { > + if(!IS_PRIV_FOR(current->domain, d)) > + return -EINVAL; > + mfn = xatp.idx; > + page = mfn_to_page(mfn); > + break; > + } I would really rather not have this interface; I don't see why we can't use grant tables for this. If you must do it this way, it should check that the MFN is valid and that it's owned by the caller. > default: > break; > } > @@ -4693,13 +4708,17 @@ > } > > /* Unmap from old location, if any. */ > - gpfn = get_gpfn_from_mfn(mfn); > - ASSERT( gpfn != SHARED_M2P_ENTRY ); > - if ( gpfn != INVALID_M2P_ENTRY ) > - guest_physmap_remove_page(d, gpfn, mfn, 0); > + if(xatp.space!=XENMAPSPACE_mfn) { > + gpfn = get_gpfn_from_mfn(mfn); > + ASSERT( gpfn != SHARED_M2P_ENTRY ); > + if ( gpfn != INVALID_M2P_ENTRY ) > + guest_physmap_remove_page(d, gpfn, mfn, 0); > + } Why did you make this change? > > /* Map at new location. */ > rc = guest_physmap_add_page(d, xatp.gpfn, mfn, 0); > diff -r 0f36c2eec2e1 xen/include/public/memory.h > --- a/xen/include/public/memory.h Thu Jul 28 15:40:54 2011 +0100 > +++ b/xen/include/public/memory.h Thu Sep 01 14:52:25 2011 +0100 > @@ -212,6 +212,7 @@ > #define XENMAPSPACE_shared_info 0 /* shared info page */ > #define XENMAPSPACE_grant_table 1 /* grant table page */ > #define XENMAPSPACE_gmfn 2 /* GMFN */ > +#define XENMAPSPACE_mfn 3 /* MFN */ > unsigned int space; > > #define XENMAPIDX_grant_table_status 0x80000000 > > > I got error at: > > arch_memory_op() > -->case XENMEM_add_to_physmap: > -->if ( page ) > -->put_page(page); > -->free_domheap_page(page); > -->BUG_ON((pg[i].u.inuse.type_info & > PGT_count_mask) != 0); > > In my case, pg[i].u.inuse.type_info & PGT_count_mask =1. OK, so you've dropped the last untyped refcount on a page which still has a type count. That means the reference counting has got messed up somewhere. > Actually, in the linux based stubdom case, I need to keep these pages > of vram mapped in qemu of stubdom. But it seems that granting pages > implies having the pages unmapped in the process that grants them. > Maybe the grant table could not solve the vram mapping problem. But this patch doesn't use the grant tables at all. Tim. -- _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel From xen-devel-bounces@lists.xensource.com Thu Sep 01 10:33:00 2011 Return-path: Envelope-to: www-data@lists.xensource.com Delivery-date: Thu, 01 Sep 2011 10:33:00 -0700 Received: from localhost ([127.0.0.1] helo=lists.colo.xensource.com) by lists.xensource.com with esmtp (Exim 4.43) id 1QzB8N-00013l-Ui; Thu, 01 Sep 2011 10:33:00 -0700 Received: from mail216.messagelabs.com ([85.158.143.99]) by lists.xensource.com with esmtp (Exim 4.43) id 1QzB7k-0000rg-Tk for xen-devel@lists.xensource.com; Thu, 01 Sep 2011 10:32:23 -0700 X-Env-Sender: jeremy@goop.org X-Msg-Ref: server-11.tower-216.messagelabs.com!1314898336!9173181!1 X-Originating-IP: [74.207.240.146] X-StarScan-Version: 6.3.6; banners=-,-,- X-VirusChecked: Checked Received: (qmail 23398 invoked from network); 1 Sep 2011 17:32:17 -0000 Received: from claw.goop.org (HELO claw.goop.org) (74.207.240.146) by server-11.tower-216.messagelabs.com with DHE-RSA-AES256-SHA encrypted SMTP; 1 Sep 2011 17:32:17 -0000 Received: from saboo.goop.org (c-50-131-57-2.hsd1.ca.comcast.net [50.131.57.2]) (Authenticated sender: smtp-saboo) by claw.goop.org (Postfix) with ESMTPSA id 8EDF189FA; Thu, 1 Sep 2011 10:32:15 -0700 (PDT) Received: from saboo.goop.org (localhost [IPv6:::1]) by saboo.goop.org (Postfix) with ESMTP id ECFFA20350; Thu, 1 Sep 2011 10:32:07 -0700 (PDT) Message-ID: <4E5FC197.7040004@goop.org> Date: Thu, 01 Sep 2011 10:32:07 -0700 From: Jeremy Fitzhardinge User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:6.0) Gecko/20110816 Thunderbird/6.0 MIME-Version: 1.0 To: Ian Campbell Subject: Re: [Xen-devel] Kernel bug from 3.0 (was phy disks and vifs timing out in DomU) References: <4E31820C.5030200@overnetdata.com> <1311870512.24408.153.camel@cthulhu.hellion.org.uk> <4E3266DE.9000606@overnetdata.com> <20110803152841.GA2860@dumpdata.com> <4E4E3957.1040007@overnetdata.com> <20110819125615.GA26558@dumpdata.com> <4E56B132.9050708@overnetdata.com> <20110826142606.GA25511@dumpdata.com> <20110826144438.GA24836@dumpdata.com> <4E5E6843.7050206@citrix.com> <20110831170711.GB13642@dumpdata.com> <1314862972.28989.74.camel@zakaz.uk.xensource.com> In-Reply-To: <1314862972.28989.74.camel@zakaz.uk.xensource.com> X-Enigmail-Version: 1.3.1 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Cc: Todd Deshane , "xen-devel@lists.xensource.com" , David Vrabel , Anthony Wright , Konrad Rzeszutek Wilk X-BeenThere: xen-devel@lists.xensource.com X-Mailman-Version: 2.1.5 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xensource.com Errors-To: xen-devel-bounces@lists.xensource.com On 09/01/2011 12:42 AM, Ian Campbell wrote: > On Wed, 2011-08-31 at 18:07 +0100, Konrad Rzeszutek Wilk wrote: >> On Wed, Aug 31, 2011 at 05:58:43PM +0100, David Vrabel wrote: >>> On 26/08/11 15:44, Konrad Rzeszutek Wilk wrote: >>>> So while I am still looking at the hypervisor code to figure out why >>>> it would give me [when trying to map a grant page]: >>>> >>>> (XEN) mm.c:3846:d0 Could not find L1 PTE for address fbb42000 >>> It is failing in guest_map_l1e() because the page for the vmalloc'd >>> virtual address PTEs is not present. >>> >>> The test that fails is: >>> >>> (l2e_get_flags(l2e) & (_PAGE_PRESENT | _PAGE_PSE)) != _PAGE_PRESENT >>> >>> I think this is because the GNTTABOP_map_grant_ref hypercall is done >>> when task->active_mm != &init_mm and alloc_vm_area() only adds PTEs into >>> init_mm so when Xen looks in the page tables it doesn't find the entries >>> because they're not there yet. >>> >>> Putting a call to vmalloc_sync_all() after create_vm_area() and before >>> the hypercall makes it work for me. Classic Xen kernels used to have >>> such a call. >> That sounds quite reasonable. > I was wondering why upstream was missing the vmalloc_sync_all() in > alloc_vm_area() since the out-of-tree kernels did have it and the > function was added by us. I found this: > http://git.kernel.org/?p=linux/kernel/git/torvalds/linux.git;a=commitdiff;h=ef691947d8a3d479e67652312783aedcf629320a > > commit ef691947d8a3d479e67652312783aedcf629320a > Author: Jeremy Fitzhardinge > Date: Wed Dec 1 15:45:48 2010 -0800 > > vmalloc: remove vmalloc_sync_all() from alloc_vm_area() > > There's no need for it: it will get faulted into the current pagetable > as needed. > > Signed-off-by: Jeremy Fitzhardinge > > The flaw in the reasoning here is that you cannot take a kernel fault > while processing a hypercall, so hypercall arguments must have been > faulted in beforehand and that is what the sync_all was for. That's a good point. (Maybe Xen should have generated pagefaults when hypercall arg pointers are bad...) > It's probably fair to say that the Xen specific caller should take care > of that Xen-specific requirement rather than pushing it into common > code. On the other hand Xen is the only user and creating a Xen specific > helper/wrapper seems a bit pointless. There's already a wrapper: xen_alloc_vm_area(), which is just a #define. But we could easily add a sync_all to it (and use it in netback, like we do in grant-table and xenbus). J _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel From xen-devel-bounces@lists.xensource.com Thu Sep 01 10:34:57 2011 Return-path: Envelope-to: www-data@lists.xensource.com Delivery-date: Thu, 01 Sep 2011 10:34:57 -0700 Received: from localhost ([127.0.0.1] helo=lists.colo.xensource.com) by lists.xensource.com with esmtp (Exim 4.43) id 1QzBAH-0001Rn-EP; Thu, 01 Sep 2011 10:34:57 -0700 Received: from mail21.messagelabs.com ([85.158.143.35]) by lists.xensource.com with smtp (Exim 4.43) id 1QzB9S-0001Fp-OX for xen-devel@lists.xensource.com; Thu, 01 Sep 2011 10:34:08 -0700 X-Env-Sender: lersek@redhat.com X-Msg-Ref: server-6.tower-21.messagelabs.com!1314898424!36662865!1 X-Originating-IP: [209.132.183.28] X-StarScan-Version: 6.3.6; banners=-,-,- X-VirusChecked: Checked Received: (qmail 19945 invoked from network); 1 Sep 2011 17:33:44 -0000 Received: from mx1.redhat.com (HELO mx1.redhat.com) (209.132.183.28) by server-6.tower-21.messagelabs.com with SMTP; 1 Sep 2011 17:33:44 -0000 Received: from int-mx01.intmail.prod.int.phx2.redhat.com (int-mx01.intmail.prod.int.phx2.redhat.com [10.5.11.11]) by mx1.redhat.com (8.14.4/8.14.4) with ESMTP id p81HXiSo024010 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Thu, 1 Sep 2011 13:33:59 -0400 Received: from [10.36.7.92] (vpn1-7-92.ams2.redhat.com [10.36.7.92]) by int-mx01.intmail.prod.int.phx2.redhat.com (8.13.8/8.13.8) with ESMTP id p81HLKK2003817; Thu, 1 Sep 2011 13:21:20 -0400 Message-ID: <4E5FBF5F.7030600@redhat.com> Date: Thu, 01 Sep 2011 19:22:39 +0200 From: Laszlo Ersek User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.2.20) Gecko/20110817 Fedora/3.1.12-1.fc14 Lightning/1.0b3pre Mnenhy/0.8.3 Thunderbird/3.1.12 MIME-Version: 1.0 To: Ian Jackson Subject: Re: [Xen-devel] [xen-unstable bisection] complete test-amd64-i386-rhel6hvm-intel References: <20063.45607.355820.209628@mariner.uk.xensource.com> In-Reply-To: <20063.45607.355820.209628@mariner.uk.xensource.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Scanned-By: MIMEDefang 2.67 on 10.5.11.11 Cc: Drew Jones , xen-devel@lists.xensource.com, keir@xen.org, stefano.stabellini@eu.citrix.com, Igor Mammedov , Paolo Bonzini X-BeenThere: xen-devel@lists.xensource.com X-Mailman-Version: 2.1.5 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xensource.com Errors-To: xen-devel-bounces@lists.xensource.com On 09/01/11 18:26, Ian Jackson wrote: >> job test-amd64-i386-rhel6hvm-intel >> changeset: 23802:bb9b81008733 >> user: Laszlo Ersek >> date: Wed Aug 31 15:16:14 2011 +0100 >> >> x86: Increase the default NR_CPUS to 256 >> >> Changeset 21012:ef845a385014 bumped the default to 128 about one and a >> half years ago. Increase it now to 256, as systems with eg. 160 >> logical CPUs are becoming (have become) common. >> >> Signed-off-by: Laszlo Ersek > > My bisector is pretty reliable nowadays. Looking at the revision > graph it tested before/after/before/after/before/after, ie three times > each on the same host. > > This change looks innocuous enough TBH. Is there any way this change > could have broken a PV-on-HVM guest ? Note that RHEL6, which is what > this is testing, seems to generally be full of bugs. > > If the problem is indeed a bug in the current RHEL6 then I will add > this test to the "do not care" list. In what way was the guest broken? How many physical cores/threads was the hypervisor running on? Thanks, lacos _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel From xen-devel-bounces@lists.xensource.com Thu Sep 01 10:36:08 2011 Return-path: Envelope-to: www-data@lists.xensource.com Delivery-date: Thu, 01 Sep 2011 10:36:08 -0700 Received: from localhost ([127.0.0.1] helo=lists.colo.xensource.com) by lists.xensource.com with esmtp (Exim 4.43) id 1QzBBQ-0001v0-Ol; Thu, 01 Sep 2011 10:36:08 -0700 Received: from mail182.messagelabs.com ([85.158.139.83]) by lists.xensource.com with esmtp (Exim 4.43) id 1QzB9Y-0001Fw-6f for xen-devel@lists.xensource.com; Thu, 01 Sep 2011 10:34:12 -0700 X-Env-Sender: jeremy@goop.org X-Msg-Ref: server-14.tower-182.messagelabs.com!1314898447!16562192!1 X-Originating-IP: [74.207.240.146] X-StarScan-Version: 6.3.6; banners=-,-,- X-VirusChecked: Checked Received: (qmail 10302 invoked from network); 1 Sep 2011 17:34:09 -0000 Received: from claw.goop.org (HELO claw.goop.org) (74.207.240.146) by server-14.tower-182.messagelabs.com with DHE-RSA-AES256-SHA encrypted SMTP; 1 Sep 2011 17:34:09 -0000 Received: from saboo.goop.org (c-50-131-57-2.hsd1.ca.comcast.net [50.131.57.2]) (Authenticated sender: smtp-saboo) by claw.goop.org (Postfix) with ESMTPSA id B860489FD; Thu, 1 Sep 2011 10:34:06 -0700 (PDT) Received: from saboo.goop.org (localhost [IPv6:::1]) by saboo.goop.org (Postfix) with ESMTP id 75DE820350; Thu, 1 Sep 2011 10:34:02 -0700 (PDT) Message-ID: <4E5FC20A.2080009@goop.org> Date: Thu, 01 Sep 2011 10:34:02 -0700 From: Jeremy Fitzhardinge User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:6.0) Gecko/20110816 Thunderbird/6.0 MIME-Version: 1.0 To: Ian Campbell Subject: Re: [Xen-devel] Kernel bug from 3.0 (was phy disks and vifs timing out in DomU) References: <4E4E3957.1040007@overnetdata.com> <20110819125615.GA26558@dumpdata.com> <4E56B132.9050708@overnetdata.com> <20110826142606.GA25511@dumpdata.com> <20110826144438.GA24836@dumpdata.com> <4E5E6843.7050206@citrix.com> <20110831170711.GB13642@dumpdata.com> <1314862972.28989.74.camel@zakaz.uk.xensource.com> <20110901142356.GD23971@dumpdata.com> <1314889953.28989.130.camel@zakaz.uk.xensource.com> <20110901153823.GC7506@dumpdata.com> <1314891894.28989.135.camel@zakaz.uk.xensource.com> In-Reply-To: <1314891894.28989.135.camel@zakaz.uk.xensource.com> X-Enigmail-Version: 1.3.1 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Cc: Todd Deshane , "xen-devel@lists.xensource.com" , David Vrabel , Anthony Wright , Konrad Rzeszutek Wilk X-BeenThere: xen-devel@lists.xensource.com X-Mailman-Version: 2.1.5 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xensource.com Errors-To: xen-devel-bounces@lists.xensource.com On 09/01/2011 08:44 AM, Ian Campbell wrote: > > blkback, xenbus_client and the grant table stuff all use it as well and > AFAICT have the same requirement for syncing. > > $ git grep alloc_vm_area > arch/x86/include/asm/xen/grant_table.h:#define xen_alloc_vm_area(size) alloc_vm_area(size) > > -- this macro is unused... > > arch/x86/xen/grant-table.c: xen_alloc_vm_area(PAGE_SIZE * max_nr_gframes); > drivers/block/xen-blkback/xenbus.c: blkif->blk_ring_area = alloc_vm_area(PAGE_SIZE); > drivers/net/xen-netback/netback.c: vif->tx_comms_area = alloc_vm_area(PAGE_SIZE); > drivers/net/xen-netback/netback.c: vif->rx_comms_area = alloc_vm_area(PAGE_SIZE); > drivers/xen/xenbus/xenbus_client.c: area = xen_alloc_vm_area(PAGE_SIZE); Well, 3/5ths unused. J _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel From xen-devel-bounces@lists.xensource.com Thu Sep 01 10:46:46 2011 Return-path: Envelope-to: www-data@lists.xensource.com Delivery-date: Thu, 01 Sep 2011 10:46:46 -0700 Received: from localhost ([127.0.0.1] helo=lists.colo.xensource.com) by lists.xensource.com with esmtp (Exim 4.43) id 1QzBLi-0002bp-99; Thu, 01 Sep 2011 10:46:46 -0700 Received: from mail182.messagelabs.com ([85.158.139.83]) by lists.xensource.com with smtp (Exim 4.43) id 1QzBLC-0002Oj-Ua for xen-devel@lists.xensource.com; Thu, 01 Sep 2011 10:46:15 -0700 X-Env-Sender: dgdegra@tycho.nsa.gov X-Msg-Ref: server-13.tower-182.messagelabs.com!1314899171!16565642!1 X-Originating-IP: [63.239.65.39] X-StarScan-Version: 6.3.6; banners=-,-,- X-VirusChecked: Checked Received: (qmail 6320 invoked from network); 1 Sep 2011 17:46:11 -0000 Received: from msux-gh1-uea01.nsa.gov (HELO msux-gh1-uea01.nsa.gov) (63.239.65.39) by server-13.tower-182.messagelabs.com with SMTP; 1 Sep 2011 17:46:11 -0000 Received: from tarius.tycho.ncsc.mil (localhost [127.0.0.1]) by msux-gh1-uea01.nsa.gov (8.12.10/8.12.10) with ESMTP id p81Hk9Mm024415; Thu, 1 Sep 2011 17:46:09 GMT Received: from moss-nexus.epoch.ncsc.mil (moss-nexus [144.51.25.48]) by tarius.tycho.ncsc.mil (8.13.1/8.13.1) with ESMTP id p81Hk9HZ014742; Thu, 1 Sep 2011 13:46:09 -0400 Message-ID: <4E5FC4E5.4070704@tycho.nsa.gov> Date: Thu, 01 Sep 2011 13:46:13 -0400 From: Daniel De Graaf Organization: National Security Agency User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:5.0) Gecko/20110707 Thunderbird/5.0 MIME-Version: 1.0 To: Ian Jackson References: <20055.42803.979775.531468@mariner.uk.xensource.com> <1314643714-28350-1-git-send-email-dgdegra@tycho.nsa.gov> <1314700361.10283.135.camel@zakaz.uk.xensource.com> <4E5E88CF.7090408@tycho.nsa.gov> <1314894519.28989.143.camel@zakaz.uk.xensource.com> <4E5FB72B.7010200@tycho.nsa.gov> <20063.47441.576537.375177@mariner.uk.xensource.com> In-Reply-To: <20063.47441.576537.375177@mariner.uk.xensource.com> X-Enigmail-Version: 1.2.1 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: Ian Campbell , "xen-devel@lists.xensource.com" , Stefano Stabellini , "konrad.wilk@oracle.com" Subject: [Xen-devel] Re: [PATCH v3] libvchan: interdomain communications library X-BeenThere: xen-devel@lists.xensource.com X-Mailman-Version: 2.1.5 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xensource.com Errors-To: xen-devel-bounces@lists.xensource.com On 09/01/2011 12:56 PM, Ian Jackson wrote: > Daniel De Graaf writes ("Re: [PATCH v3] libvchan: interdomain communications library"): >> Making this change has exposed an interesting ordering dependency in the >> notify API under Linux: the file descriptor for gntdev or gntalloc must be >> less than the file descriptor for evtchn in order for the event channel to >> still be active when the unmap occurs on a crash. The init functions of >> libvchan do open the files in the proper order for this to happen. > > Wow, that's pretty crazy. Surely the gnt* fd should have an internal > reference to the evtchn fd ? > > Ian. > The gnt* drivers will need to be changed to both find and take such a reference; currently, they only refer to the port. This will probably add a dependency from the gnt* module on evtchn; I'll look at what is actually required to hold the event channel open when I make the patch. -- Daniel De Graaf National Security Agency _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel From xen-devel-bounces@lists.xensource.com Thu Sep 01 10:48:04 2011 Return-path: Envelope-to: www-data@lists.xensource.com Delivery-date: Thu, 01 Sep 2011 10:48:04 -0700 Received: from localhost ([127.0.0.1] helo=lists.colo.xensource.com) by lists.xensource.com with esmtp (Exim 4.43) id 1QzBMy-00036B-3O; Thu, 01 Sep 2011 10:48:04 -0700 Received: from mail182.messagelabs.com ([85.158.139.83]) by lists.xensource.com with smtp (Exim 4.43) id 1QzBMZ-0002tZ-Q4 for xen-devel@lists.xensource.com; Thu, 01 Sep 2011 10:47:40 -0700 X-Env-Sender: lersek@redhat.com X-Msg-Ref: server-8.tower-182.messagelabs.com!1314899255!16728899!1 X-Originating-IP: [209.132.183.28] X-StarScan-Version: 6.3.6; banners=-,-,- X-VirusChecked: Checked Received: (qmail 10964 invoked from network); 1 Sep 2011 17:47:36 -0000 Received: from mx1.redhat.com (HELO mx1.redhat.com) (209.132.183.28) by server-8.tower-182.messagelabs.com with SMTP; 1 Sep 2011 17:47:36 -0000 Received: from int-mx09.intmail.prod.int.phx2.redhat.com (int-mx09.intmail.prod.int.phx2.redhat.com [10.5.11.22]) by mx1.redhat.com (8.14.4/8.14.4) with ESMTP id p81HlXJu031168 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Thu, 1 Sep 2011 13:47:33 -0400 Received: from [10.36.7.92] (vpn1-7-92.ams2.redhat.com [10.36.7.92]) by int-mx09.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP id p81HlV82017030; Thu, 1 Sep 2011 13:47:32 -0400 Message-ID: <4E5FC583.5050306@redhat.com> Date: Thu, 01 Sep 2011 19:48:51 +0200 From: Laszlo Ersek User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.2.20) Gecko/20110817 Fedora/3.1.12-1.fc14 Lightning/1.0b3pre Mnenhy/0.8.3 Thunderbird/3.1.12 MIME-Version: 1.0 To: Ian Jackson Subject: Re: [Xen-devel] [xen-unstable bisection] complete test-amd64-i386-rhel6hvm-intel References: <20063.45607.355820.209628@mariner.uk.xensource.com> In-Reply-To: <20063.45607.355820.209628@mariner.uk.xensource.com> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Scanned-By: MIMEDefang 2.68 on 10.5.11.22 Cc: xen-devel@lists.xensource.com, keir@xen.org, stefano.stabellini@eu.citrix.com X-BeenThere: xen-devel@lists.xensource.com X-Mailman-Version: 2.1.5 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xensource.com Errors-To: xen-devel-bounces@lists.xensource.com On 09/01/11 18:26, Ian Jackson wrote: >> changeset: 23802:bb9b81008733 >> user: Laszlo Ersek >> date: Wed Aug 31 15:16:14 2011 +0100 >> >> x86: Increase the default NR_CPUS to 256 >> >> Changeset 21012:ef845a385014 bumped the default to 128 about one and a >> half years ago. Increase it now to 256, as systems with eg. 160 >> logical CPUs are becoming (have become) common. >> >> Signed-off-by: Laszlo Ersek FWIW, the hypervisor shipped in RHEL-5 has been built for 256 CPUs since April 2009, using the max_phys_cpus make macro. I posted the patch because now we changed the in-source macro definition too. lacos _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel From xen-devel-bounces@lists.xensource.com Thu Sep 01 11:14:33 2011 Return-path: Envelope-to: www-data@lists.xensource.com Delivery-date: Thu, 01 Sep 2011 11:14:33 -0700 Received: from localhost ([127.0.0.1] helo=lists.colo.xensource.com) by lists.xensource.com with esmtp (Exim 4.43) id 1QzBma-0003sZ-8N; Thu, 01 Sep 2011 11:14:33 -0700 Received: from mail174.messagelabs.com ([85.158.138.51]) by lists.xensource.com with smtp (Exim 4.43) id 1QzBlN-0003fq-O6 for xen-devel@lists.xensource.com; Thu, 01 Sep 2011 11:13:18 -0700 X-Env-Sender: Ian.Jackson@eu.citrix.com X-Msg-Ref: server-6.tower-174.messagelabs.com!1314900794!27802475!1 X-Originating-IP: [62.200.22.115] X-StarScan-Version: 6.3.6; banners=-,-,- X-VirusChecked: Checked Received: (qmail 15785 invoked from network); 1 Sep 2011 18:13:14 -0000 Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115) by server-6.tower-174.messagelabs.com with SMTP; 1 Sep 2011 18:13:14 -0000 X-IronPort-AV: E=Sophos;i="4.68,314,1312156800"; d="scan'208";a="7560930" Received: from lonpmailmx01.citrite.net ([10.30.203.162]) by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5; 01 Sep 2011 18:13:14 +0000 Received: from woking.xci-test.com (10.80.248.135) by smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id 8.3.137.0; Thu, 1 Sep 2011 19:13:14 +0100 Received: from osstest by woking.xci-test.com with local (Exim 4.69) (envelope-from ) id 1QzBlJ-0000MK-RX; Thu, 01 Sep 2011 19:13:13 +0100 To: xen-devel@lists.xensource.com Message-ID: From: xen.org Date: Thu, 1 Sep 2011 19:13:13 +0100 MIME-Version: 1.0 Content-Type: text/plain Cc: ian.jackson@eu.citrix.com Subject: [Xen-devel] [xen-4.1-testing test] 8808: tolerable FAIL - PUSHED X-BeenThere: xen-devel@lists.xensource.com X-Mailman-Version: 2.1.5 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xensource.com Errors-To: xen-devel-bounces@lists.xensource.com flight 8808 xen-4.1-testing real [real] http://www.chiark.greenend.org.uk/~xensrcts/logs/8808/ Failures :-/ but no regressions. Tests which did not succeed, but are not blocking, including regressions (tests previously passed) regarded as allowable: test-amd64-amd64-xl-pcipt-intel 9 guest-start fail never pass test-amd64-i386-rhel6hvm-intel 9 guest-start.2 fail never pass test-amd64-i386-rhel6hvm-amd 9 guest-start.2 fail never pass test-amd64-i386-win-vcpus1 16 leak-check/check fail never pass test-amd64-i386-xl-win-vcpus1 13 guest-stop fail never pass test-amd64-i386-win 16 leak-check/check fail never pass test-amd64-amd64-win 16 leak-check/check fail never pass test-amd64-amd64-xl-win 13 guest-stop fail never pass test-i386-i386-win 16 leak-check/check fail never pass test-i386-i386-xl-win 13 guest-stop fail never pass version targeted for testing: xen 6239209bb560 baseline version: xen be4b078e2d08 ------------------------------------------------------------ People who touched revisions under test: Andrew Cooper Dietmar Hahn Ian Jackson Marek Marczykowski Stefano Stabellini ------------------------------------------------------------ jobs: build-amd64 pass build-i386 pass build-amd64-oldkern pass build-i386-oldkern pass build-amd64-pvops pass build-i386-pvops pass test-amd64-amd64-xl pass test-amd64-i386-xl pass test-i386-i386-xl pass test-amd64-i386-rhel6hvm-amd fail test-amd64-i386-xl-credit2 pass test-amd64-amd64-xl-pcipt-intel fail test-amd64-i386-rhel6hvm-intel fail test-amd64-i386-xl-multivcpu pass test-amd64-amd64-pair pass test-amd64-i386-pair pass test-i386-i386-pair pass test-amd64-amd64-pv pass test-amd64-i386-pv pass test-i386-i386-pv pass test-amd64-amd64-xl-sedf pass test-amd64-i386-win-vcpus1 fail test-amd64-i386-xl-win-vcpus1 fail test-amd64-amd64-win fail test-amd64-i386-win fail test-i386-i386-win fail test-amd64-amd64-xl-win fail test-i386-i386-xl-win fail ------------------------------------------------------------ sg-report-flight on woking.cam.xci-test.com logs: /home/xc_osstest/logs images: /home/xc_osstest/images Logs, config files, etc. are available at http://www.chiark.greenend.org.uk/~xensrcts/logs Test harness code can be found at http://xenbits.xensource.com/gitweb?p=osstest.git;a=summary Pushing revision : + branch=xen-4.1-testing + revision=6239209bb560 + . cri-lock-repos ++ . cri-common +++ umask 002 +++ getconfig Repos +++ perl -e ' use Osstest; readconfigonly(); print $c{Repos} or die $!; ' ++ repos=/export/home/osstest/repos ++ repos_lock=/export/home/osstest/repos/lock ++ '[' x '!=' x/export/home/osstest/repos/lock ']' ++ OSSTEST_REPOS_LOCK_LOCKED=/export/home/osstest/repos/lock ++ exec with-lock-ex -w /export/home/osstest/repos/lock ./ap-push xen-4.1-testing 6239209bb560 + branch=xen-4.1-testing + revision=6239209bb560 + . cri-lock-repos ++ . cri-common +++ umask 002 +++ getconfig Repos +++ perl -e ' use Osstest; readconfigonly(); print $c{Repos} or die $!; ' ++ repos=/export/home/osstest/repos ++ repos_lock=/export/home/osstest/repos/lock ++ '[' x/export/home/osstest/repos/lock '!=' x/export/home/osstest/repos/lock ']' + : xen@xenbits.xensource.com + : xen@xenbits.xensource.com:git/linux-pvops + : master + : tested/2.6.39.x + case "$branch" in + cd /export/home/osstest/repos/xen-4.1-testing.hg + hg push -r 6239209bb560 ssh://xen@xenbits.xensource.com/HG/xen-4.1-testing.hg pushing to ssh://xen@xenbits.xensource.com/HG/xen-4.1-testing.hg searching for changes remote: adding changesets remote: adding manifests remote: adding file changes remote: added 4 changesets with 13 changes to 12 files _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel From xen-devel-bounces@lists.xensource.com Thu Sep 01 11:54:51 2011 Return-path: Envelope-to: www-data@lists.xensource.com Delivery-date: Thu, 01 Sep 2011 11:54:51 -0700 Received: from localhost ([127.0.0.1] helo=lists.colo.xensource.com) by lists.xensource.com with esmtp (Exim 4.43) id 1QzCPb-00063S-J2; Thu, 01 Sep 2011 11:54:51 -0700 Received: from mail21.messagelabs.com ([85.158.143.35]) by lists.xensource.com with smtp (Exim 4.43) id 1QzCOe-0005qz-CA for xen-devel@lists.xensource.com; Thu, 01 Sep 2011 11:53:52 -0700 X-Env-Sender: lersek@redhat.com X-Msg-Ref: server-13.tower-21.messagelabs.com!1314903223!47352755!1 X-Originating-IP: [209.132.183.28] X-StarScan-Version: 6.3.6; banners=-,-,- X-VirusChecked: Checked Received: (qmail 8103 invoked from network); 1 Sep 2011 18:53:43 -0000 Received: from mx1.redhat.com (HELO mx1.redhat.com) (209.132.183.28) by server-13.tower-21.messagelabs.com with SMTP; 1 Sep 2011 18:53:43 -0000 Received: from int-mx12.intmail.prod.int.phx2.redhat.com (int-mx12.intmail.prod.int.phx2.redhat.com [10.5.11.25]) by mx1.redhat.com (8.14.4/8.14.4) with ESMTP id p81Irhtn030904 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Thu, 1 Sep 2011 14:53:44 -0400 Received: from [10.36.7.92] (vpn1-7-92.ams2.redhat.com [10.36.7.92]) by int-mx12.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP id p81IrfNl030376; Thu, 1 Sep 2011 14:53:42 -0400 Message-ID: <4E5FD505.8020504@redhat.com> Date: Thu, 01 Sep 2011 20:55:01 +0200 From: Laszlo Ersek User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.2.20) Gecko/20110817 Fedora/3.1.12-1.fc14 Lightning/1.0b3pre Mnenhy/0.8.3 Thunderbird/3.1.12 MIME-Version: 1.0 To: Ian Campbell Subject: Re: [Xen-devel] Re: [xen-unstable test] 8803: regressions - FAIL References: <20063.45421.271505.189374@mariner.uk.xensource.com> <1314894926.28989.146.camel@zakaz.uk.xensource.com> In-Reply-To: <1314894926.28989.146.camel@zakaz.uk.xensource.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Scanned-By: MIMEDefang 2.68 on 10.5.11.25 Cc: "xen-devel@lists.xensource.com" , Ian Jackson X-BeenThere: xen-devel@lists.xensource.com X-Mailman-Version: 2.1.5 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xensource.com Errors-To: xen-devel-bounces@lists.xensource.com On 09/01/11 18:35, Ian Campbell wrote: > diff -r bb97bd46df6c -r 4309ff953500 xen/include/asm-x86/config.h > --- a/xen/include/asm-x86/config.h Thu Sep 01 16:03:21 2011 +0100 > +++ b/xen/include/asm-x86/config.h Thu Sep 01 17:34:41 2011 +0100 > @@ -49,6 +49,8 @@ > > #ifdef MAX_PHYS_CPUS > #define NR_CPUS MAX_PHYS_CPUS > +#elif defined __i386__ > +#define NR_CPUS 128 > #else > #define NR_CPUS 256 > #endif Ah, sorry. This special-casing / after-the-fact #error for 32-bit is actually there in the RHEL-5 fork, and there I bumped only the x86_64 default (the 32-bit one is set to 32). When I looked at the upstream source, I noticed only a single case (set to 128), and I figured upstream either makes the 32/64 distinction by different means, or they support 128 PCPUs on 32-bit too, and 128 being >> than 32, I thought 256 should be fine as well. I was wrong, sorry for wasting your time. lacos _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel From xen-devel-bounces@lists.xensource.com Thu Sep 01 11:55:53 2011 Return-path: Envelope-to: www-data@lists.xensource.com Delivery-date: Thu, 01 Sep 2011 11:55:53 -0700 Received: from localhost ([127.0.0.1] helo=lists.colo.xensource.com) by lists.xensource.com with esmtp (Exim 4.43) id 1QzCQb-0006R0-HZ; Thu, 01 Sep 2011 11:55:53 -0700 Received: from mail21.messagelabs.com ([85.158.143.35]) by lists.xensource.com with smtp (Exim 4.43) id 1QzCPm-00066z-4Q for xen-devel@lists.xensource.com; Thu, 01 Sep 2011 11:55:03 -0700 X-Env-Sender: Ian.Jackson@eu.citrix.com X-Msg-Ref: server-2.tower-21.messagelabs.com!1314903298!32529075!1 X-Originating-IP: [62.200.22.115] X-StarScan-Version: 6.3.6; banners=-,-,- X-VirusChecked: Checked Received: (qmail 4785 invoked from network); 1 Sep 2011 18:54:59 -0000 Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115) by server-2.tower-21.messagelabs.com with SMTP; 1 Sep 2011 18:54:59 -0000 X-IronPort-AV: E=Sophos;i="4.68,314,1312156800"; d="scan'208";a="7561325" Received: from lonpmailmx01.citrite.net ([10.30.203.162]) by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5; 01 Sep 2011 18:54:58 +0000 Received: from woking.xci-test.com (10.80.248.135) by smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id 8.3.137.0; Thu, 1 Sep 2011 19:54:58 +0100 Received: from osstest by woking.xci-test.com with local (Exim 4.69) (envelope-from ) id 1QzCPi-0003sk-Cs; Thu, 01 Sep 2011 19:54:58 +0100 To: xen-devel@lists.xensource.com Message-ID: From: xen.org Date: Thu, 1 Sep 2011 19:54:58 +0100 MIME-Version: 1.0 Content-Type: text/plain Cc: ian.jackson@eu.citrix.com Subject: [Xen-devel] [xen-unstable test] 8810: regressions - FAIL X-BeenThere: xen-devel@lists.xensource.com X-Mailman-Version: 2.1.5 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xensource.com Errors-To: xen-devel-bounces@lists.xensource.com flight 8810 xen-unstable real [real] http://www.chiark.greenend.org.uk/~xensrcts/logs/8810/ Regressions :-( Tests which did not succeed and are blocking: test-amd64-i386-rhel6hvm-intel 4 xen-install fail REGR. vs. 8769 test-amd64-i386-xl 4 xen-install fail REGR. vs. 8769 test-amd64-i386-pair 6 xen-install/dst_host fail REGR. vs. 8769 test-amd64-i386-pair 5 xen-install/src_host fail REGR. vs. 8769 test-amd64-i386-xl-credit2 4 xen-install fail REGR. vs. 8769 build-i386 4 xen-build fail REGR. vs. 8769 test-amd64-i386-pv 4 xen-install fail REGR. vs. 8769 build-i386-oldkern 4 xen-build fail REGR. vs. 8769 test-amd64-i386-xl-multivcpu 4 xen-install fail REGR. vs. 8769 test-amd64-i386-win-vcpus1 4 xen-install fail REGR. vs. 8769 test-amd64-i386-rhel6hvm-amd 4 xen-install fail REGR. vs. 8769 test-amd64-i386-win 4 xen-install fail REGR. vs. 8769 test-amd64-i386-xl-win-vcpus1 4 xen-install fail REGR. vs. 8769 Tests which did not succeed, but are not blocking, including regressions (tests previously passed) regarded as allowable: test-amd64-amd64-xl-pcipt-intel 9 guest-start fail never pass test-i386-i386-pv 1 xen-build-check(1) blocked n/a test-i386-i386-xl 1 xen-build-check(1) blocked n/a test-i386-i386-pair 1 xen-build-check(1) blocked n/a test-amd64-amd64-xl-win 13 guest-stop fail never pass test-i386-i386-win 1 xen-build-check(1) blocked n/a test-i386-i386-xl-win 1 xen-build-check(1) blocked n/a test-amd64-amd64-win 16 leak-check/check fail never pass version targeted for testing: xen 85b29185c911 baseline version: xen ac9aa65050e9 ------------------------------------------------------------ People who touched revisions under test: Andrew Cooper Christoph Egger Dietmar Hahn Ian Jackson Keir Fraser Kevin Tian Laszlo Ersek Olaf Hering Stefano Stabellini Tim Deegan ------------------------------------------------------------ jobs: build-amd64 pass build-i386 fail build-amd64-oldkern pass build-i386-oldkern fail build-amd64-pvops pass build-i386-pvops pass test-amd64-amd64-xl pass test-amd64-i386-xl fail test-i386-i386-xl blocked test-amd64-i386-rhel6hvm-amd fail test-amd64-i386-xl-credit2 fail test-amd64-amd64-xl-pcipt-intel fail test-amd64-i386-rhel6hvm-intel fail test-amd64-i386-xl-multivcpu fail test-amd64-amd64-pair pass test-amd64-i386-pair fail test-i386-i386-pair blocked test-amd64-amd64-pv pass test-amd64-i386-pv fail test-i386-i386-pv blocked test-amd64-amd64-xl-sedf pass test-amd64-i386-win-vcpus1 fail test-amd64-i386-xl-win-vcpus1 fail test-amd64-amd64-win fail test-amd64-i386-win fail test-i386-i386-win blocked test-amd64-amd64-xl-win fail test-i386-i386-xl-win blocked ------------------------------------------------------------ sg-report-flight on woking.cam.xci-test.com logs: /home/xc_osstest/logs images: /home/xc_osstest/images Logs, config files, etc. are available at http://www.chiark.greenend.org.uk/~xensrcts/logs Test harness code can be found at http://xenbits.xensource.com/gitweb?p=osstest.git;a=summary Not pushing. ------------------------------------------------------------ changeset: 23809:85b29185c911 tag: tip user: Tim Deegan date: Thu Sep 01 09:39:25 2011 +0100 x86/mm: use defines for page sizes rather hardcoding them. Signed-off-by: Christoph Egger Acked-by: Tim Deegan Committed-by: Tim Deegan changeset: 23808:4a4882df5649 user: Stefano Stabellini date: Wed Aug 31 15:23:49 2011 +0100 xen: get_free_pirq: make sure that the returned pirq is allocated Signed-off-by: Stefano Stabellini changeset: 23807:2297b90a6a7b user: Stefano Stabellini date: Wed Aug 31 15:23:34 2011 +0100 xen: __hvm_pci_intx_assert should check for gsis remapped onto pirqs If the isa irq corresponding to a particular gsi is disabled while the gsi is enabled, __hvm_pci_intx_assert will always inject the gsi through the violapic, even if the gsi has been remapped onto a pirq. This patch makes sure that even in this case we inject the notification appropriately. Signed-off-by: Stefano Stabellini changeset: 23806:4226ea1785b5 user: Stefano Stabellini date: Wed Aug 31 15:23:12 2011 +0100 xen: fix hvm_domain_use_pirq's behavior hvm_domain_use_pirq should return true when the guest is using a certain pirq, no matter if the corresponding event channel is currently enabled or disabled. As an additional complication, qemu is going to request pirqs for passthrough devices even for Xen unaware HVM guests, so we need to wait for an event channel to be connected before considering the pirq of a passthrough device as "in use". Signed-off-by: Stefano Stabellini changeset: 23805:7048810180de user: Andrew Cooper date: Wed Aug 31 15:19:24 2011 +0100 IRQ: manually EOI migrating line interrupts When migrating IO-APIC line level interrupts between PCPUs, the migration code rewrites the IO-APIC entry to point to the new CPU/Vector before EOI'ing it. The EOI process says that EOI'ing the Local APIC will cause a broadcast with the vector number, which the IO-APIC must listen to to clear the IRR and Status bits. In the case of migrating, the IO-APIC has already been reprogrammed so the EOI broadcast with the old vector fails to match the new vector, leaving the IO-APIC with an outstanding vector, preventing any more use of that line interrupt. This causes a lockup especially when your root device is using PCI INTA (megaraid_sas driver *ehem*) However, the problem is mostly hidden because send_cleanup_vector() causes a cleanup of all moving vectors on the current PCPU in such a way which does not cause the problem, and if the problem has occured, the writes it makes to the IO-APIC clears the IRR and Status bits which unlocks the problem. This fix is distinctly a temporary hack, waiting on a cleanup of the irq code. It checks for the edge case where we have moved the irq, and manually EOI's the old vector with the IO-APIC which correctly clears the IRR and Status bits. Also, it protects the code which updates irq_cfg by disabling interrupts. Signed-off-by: Andrew Cooper changeset: 23804:42d76c68b2bf user: Kevin Tian date: Wed Aug 31 15:18:23 2011 +0100 x86: add irq count for IPIs such count is useful to assist decision make in cpuidle governor, while w/o this patch only device interrupts through do_IRQ is currently counted. Signed-off-by: Kevin Tian changeset: 23803:51983821efa4 user: Dietmar Hahn date: Wed Aug 31 15:17:45 2011 +0100 vpmu: Add processors Westmere E7-8837 and SandyBridge i5-2500 to the vpmu list Signed-off-by: Dietmar Hahn changeset: 23802:bb9b81008733 user: Laszlo Ersek date: Wed Aug 31 15:16:14 2011 +0100 x86: Increase the default NR_CPUS to 256 Changeset 21012:ef845a385014 bumped the default to 128 about one and a half years ago. Increase it now to 256, as systems with eg. 160 logical CPUs are becoming (have become) common. Signed-off-by: Laszlo Ersek changeset: 23801:d54cfae72cd1 user: Christoph Egger date: Wed Aug 31 15:15:41 2011 +0100 nestedsvm: VMRUN doesn't use nextrip VMRUN does not use nextrip. So remove pointless assignment. Signed-off-by: Christoph Egger changeset: 23800:72edc40e2942 user: Keir Fraser date: Wed Aug 31 15:14:49 2011 +0100 x86-64: Fix off-by-one error in __addr_ok() macro Signed-off-by: Laszlo Ersek Signed-off-by: Keir Fraser changeset: 23799:ac9aa65050e9 parent: 23798:469aa1fbd843 parent: 23797:2c687e70a343 user: Ian Jackson date: Tue Aug 30 11:46:58 2011 +0100 Merge ======================================== commit cd776ee9408ff127f934a707c1a339ee600bc127 Author: Ian Jackson Date: Tue Jun 28 13:50:53 2011 +0100 qemu-char.c: fix incorrect CONFIG_STUBDOM handling qemu-char.c:1123:7: warning: "CONFIG_STUBDOM" is not defined [-Wundef] Signed-off-by: Olaf Hering Acked-by: Ian Jackson _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel From xen-devel-bounces@lists.xensource.com Thu Sep 01 12:20:43 2011 Return-path: Envelope-to: www-data@lists.xensource.com Delivery-date: Thu, 01 Sep 2011 12:20:43 -0700 Received: from localhost ([127.0.0.1] helo=lists.colo.xensource.com) by lists.xensource.com with esmtp (Exim 4.43) id 1QzCob-0007VV-Ta; Thu, 01 Sep 2011 12:20:42 -0700 Received: from mail174.messagelabs.com ([85.158.138.51]) by lists.xensource.com with smtp (Exim 4.43) id 1QzCne-0007Ib-9X for xen-devel@lists.xensource.com; Thu, 01 Sep 2011 12:19:43 -0700 X-Env-Sender: Ian.Campbell@eu.citrix.com X-Msg-Ref: server-9.tower-174.messagelabs.com!1314904779!23897243!1 X-Originating-IP: [62.200.22.115] X-StarScan-Version: 6.3.6; banners=-,-,- X-VirusChecked: Checked Received: (qmail 5847 invoked from network); 1 Sep 2011 19:19:39 -0000 Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115) by server-9.tower-174.messagelabs.com with SMTP; 1 Sep 2011 19:19:39 -0000 X-IronPort-AV: E=Sophos;i="4.68,314,1312156800"; d="scan'208";a="7561592" Received: from lonpmailmx01.citrite.net ([10.30.203.162]) by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5; 01 Sep 2011 19:19:38 +0000 Received: from [127.0.0.1] (10.80.16.67) by smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id 8.3.137.0; Thu, 1 Sep 2011 20:19:38 +0100 Subject: Re: [Xen-devel] Kernel bug from 3.0 (was phy disks and vifs timing out in DomU) From: Ian Campbell To: Jeremy Fitzhardinge In-Reply-To: <4E5FC20A.2080009@goop.org> References: <4E4E3957.1040007@overnetdata.com> <20110819125615.GA26558@dumpdata.com> <4E56B132.9050708@overnetdata.com> <20110826142606.GA25511@dumpdata.com> <20110826144438.GA24836@dumpdata.com> <4E5E6843.7050206@citrix.com> <20110831170711.GB13642@dumpdata.com> <1314862972.28989.74.camel@zakaz.uk.xensource.com> <20110901142356.GD23971@dumpdata.com> <1314889953.28989.130.camel@zakaz.uk.xensource.com> <20110901153823.GC7506@dumpdata.com> <1314891894.28989.135.camel@zakaz.uk.xensource.com> <4E5FC20A.2080009@goop.org> Content-Type: text/plain; charset="ISO-8859-1" Organization: Citrix Systems, Inc. Date: Thu, 1 Sep 2011 20:19:37 +0100 Message-ID: <1314904777.19389.25.camel@dagon.hellion.org.uk> MIME-Version: 1.0 X-Mailer: Evolution 2.32.3 Content-Transfer-Encoding: 7bit Cc: "xen-devel@lists.xensource.com" , Anthony Wright , Konrad Rzeszutek Wilk , David Vrabel , Todd, Deshane X-BeenThere: xen-devel@lists.xensource.com X-Mailman-Version: 2.1.5 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xensource.com Errors-To: xen-devel-bounces@lists.xensource.com On Thu, 2011-09-01 at 18:34 +0100, Jeremy Fitzhardinge wrote: > On 09/01/2011 08:44 AM, Ian Campbell wrote: > > > > blkback, xenbus_client and the grant table stuff all use it as well and > > AFAICT have the same requirement for syncing. > > > > $ git grep alloc_vm_area > > arch/x86/include/asm/xen/grant_table.h:#define xen_alloc_vm_area(size) alloc_vm_area(size) > > > > -- this macro is unused... > > > > arch/x86/xen/grant-table.c: xen_alloc_vm_area(PAGE_SIZE * max_nr_gframes); > > drivers/block/xen-blkback/xenbus.c: blkif->blk_ring_area = alloc_vm_area(PAGE_SIZE); > > drivers/net/xen-netback/netback.c: vif->tx_comms_area = alloc_vm_area(PAGE_SIZE); > > drivers/net/xen-netback/netback.c: vif->rx_comms_area = alloc_vm_area(PAGE_SIZE); > > drivers/xen/xenbus/xenbus_client.c: area = xen_alloc_vm_area(PAGE_SIZE); > > Well, 3/5ths unused. Hmm, yes, no sure how I missed that. _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel From xen-devel-bounces@lists.xensource.com Thu Sep 01 12:21:57 2011 Return-path: Envelope-to: www-data@lists.xensource.com Delivery-date: Thu, 01 Sep 2011 12:21:57 -0700 Received: from localhost ([127.0.0.1] helo=lists.colo.xensource.com) by lists.xensource.com with esmtp (Exim 4.43) id 1QzCpp-0007sz-RG; Thu, 01 Sep 2011 12:21:57 -0700 Received: from mail27.messagelabs.com ([193.109.254.147]) by lists.xensource.com with esmtp (Exim 4.43) id 1QzCoE-0007Qb-QV for Xen-devel@lists.xensource.com; Thu, 01 Sep 2011 12:20:19 -0700 X-Env-Sender: mukesh.rathor@oracle.com X-Msg-Ref: server-6.tower-27.messagelabs.com!1314904797!47253592!1 X-Originating-IP: [148.87.113.117] X-StarScan-Version: 6.3.6; banners=-,-,- X-VirusChecked: Checked Received: (qmail 19837 invoked from network); 1 Sep 2011 19:19:59 -0000 Received: from rcsinet15.oracle.com (HELO rcsinet15.oracle.com) (148.87.113.117) by server-6.tower-27.messagelabs.com with DHE-RSA-AES256-SHA encrypted SMTP; 1 Sep 2011 19:19:59 -0000 Received: from rtcsinet21.oracle.com (rtcsinet21.oracle.com [66.248.204.29]) by rcsinet15.oracle.com (Switch-3.4.4/Switch-3.4.4) with ESMTP id p81JKBBA005101 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Thu, 1 Sep 2011 19:20:13 GMT Received: from acsmt357.oracle.com (acsmt357.oracle.com [141.146.40.157]) by rtcsinet21.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id p81JKAn2002591 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 1 Sep 2011 19:20:11 GMT Received: from abhmt117.oracle.com (abhmt117.oracle.com [141.146.116.69]) by acsmt357.oracle.com (8.12.11.20060308/8.12.11) with ESMTP id p81JK5NQ000850; Thu, 1 Sep 2011 14:20:05 -0500 Received: from mantra.us.oracle.com (/130.35.68.95) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Thu, 01 Sep 2011 12:20:05 -0700 Date: Thu, 1 Sep 2011 12:20:04 -0700 From: Mukesh Rathor To: "Xen-devel@lists.xensource.com" , Jan Beulich Message-ID: <20110901122004.2c12f34f@mantra.us.oracle.com> Organization: Oracle Corporation X-Mailer: Claws Mail 3.7.6 (GTK+ 2.18.9; x86_64-redhat-linux-gnu) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-Source-IP: rtcsinet21.oracle.com [66.248.204.29] X-CT-RefId: str=0001.0A090202.4E5FDAED.0101,ss=1,re=0.000,fgs=0 Cc: Subject: [Xen-devel] DOM0 Hang on a large box.... X-BeenThere: xen-devel@lists.xensource.com X-Mailman-Version: 2.1.5 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xensource.com Errors-To: xen-devel-bounces@lists.xensource.com Hi, I'm looking at a system hang on a large box: 160 cpus, 2TB. Dom0 is booted with 160 vcpus (don't ask me why :)), and an HVM guest is started with over 1.5T RAM and 128 vcpus. The system hangs without much activity after couple hours. Xen 4.0.2 and 2.6.32 based 64bit dom0. During hang I discovered: Most of dom0 vcpus are in double_lock_balance spinning on one of the locks: @ ffffffff800083aa: 0:hypercall_page+3aa pop %r11 @ ffffffff802405eb: 0:xen_spin_wait+19b test %eax, %eax @ ffffffff8035969b: 0:_spin_lock+10b test %al, %al @ ffffffff800342f5: 0:double_lock_balance+65 mov %rbx, %rdi @ ffffffff80356fc0: 0:thread_return+37e mov 0x880(%r12), %edi static int _double_lock_balance(struct rq *this_rq, struct rq *busiest) __releases(this_rq->lock) __acquires(busiest->lock) __acquires(this_rq->lock) { int ret = 0; if (unlikely(!spin_trylock(&busiest->lock))) { if (busiest < this_rq) { spin_unlock(&this_rq->lock); spin_lock(&busiest->lock); spin_lock_nested(&this_rq->lock, SINGLE_DEPTH_NESTING); ret = 1; } else spin_lock_nested(&busiest->lock, SINGLE_DEPTH_NESTING); } return ret; } The lock is taken, but not sure who the owner is. The lock struct: @ ffff8800020e2480: 2f102e70 0000000c 00000002 00000000 so slock is: 2f102e70 The remaining vcpus are idling: ffffffff800083aa: 0:hypercall_page+3aa pop %r11 ffffffff8000f0c7: 0:xen_safe_halt+f7 addq $0x18, %rsp ffffffff8000a5c5: 0:cpu_idle+65 jmp 0:cpu_idle+4e ffffffff803558fe: 0:cpu_bringup_and_idle+e leave But the baffling thing is the vcpu upcall mask is set. The block schedop call does local_event_delivery_enable() first thing, so the mask should be clear!!! Another baffling thing is the dom0 upcall mask looks fishy: @ ffff83007f4dba00: 4924924924924929 2492492492492492 @ ffff83007f4dba10: 9249249249249249 4924924924924924 @ ffff83007f4dba20: 2492492492492492 9249249249249249 @ ffff83007f4dba30: 4924924924924924 0000000092492492 @ ffff83007f4dba40: 0000000000000000 0000000000000000 @ ffff83007f4dba50: 0000000000000000 ffffffffc0000000 @ ffff83007f4dba60: ffffffffffffffff ffffffffffffffff @ ffff83007f4dba70: ffffffffffffffff ffffffffffffffff Finally, ticketing is used for spin locks. Hi Jan, what is the largest system this was tested on? Have you seen this before? thanks, Mukesh _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel From xen-devel-bounces@lists.xensource.com Thu Sep 01 12:22:49 2011 Return-path: Envelope-to: www-data@lists.xensource.com Delivery-date: Thu, 01 Sep 2011 12:22:49 -0700 Received: from localhost ([127.0.0.1] helo=lists.colo.xensource.com) by lists.xensource.com with esmtp (Exim 4.43) id 1QzCqf-0008Gd-Nx; Thu, 01 Sep 2011 12:22:49 -0700 Received: from mail174.messagelabs.com ([85.158.138.51]) by lists.xensource.com with smtp (Exim 4.43) id 1QzCpi-0007oK-15 for xen-devel@lists.xensource.com; Thu, 01 Sep 2011 12:21:50 -0700 X-Env-Sender: Ian.Campbell@eu.citrix.com X-Msg-Ref: server-4.tower-174.messagelabs.com!1314904906!29945752!1 X-Originating-IP: [62.200.22.115] X-StarScan-Version: 6.3.6; banners=-,-,- X-VirusChecked: Checked Received: (qmail 19961 invoked from network); 1 Sep 2011 19:21:47 -0000 Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115) by server-4.tower-174.messagelabs.com with SMTP; 1 Sep 2011 19:21:47 -0000 X-IronPort-AV: E=Sophos;i="4.68,314,1312156800"; d="scan'208";a="7561641" Received: from lonpmailmx01.citrite.net ([10.30.203.162]) by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5; 01 Sep 2011 19:21:46 +0000 Received: from [127.0.0.1] (10.80.16.67) by smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id 8.3.137.0; Thu, 1 Sep 2011 20:21:46 +0100 Subject: Re: [Xen-devel] Kernel bug from 3.0 (was phy disks and vifs timing out in DomU) From: Ian Campbell To: Jeremy Fitzhardinge In-Reply-To: <4E5FC197.7040004@goop.org> References: <4E31820C.5030200@overnetdata.com> <1311870512.24408.153.camel@cthulhu.hellion.org.uk> <4E3266DE.9000606@overnetdata.com> <20110803152841.GA2860@dumpdata.com> <4E4E3957.1040007@overnetdata.com> <20110819125615.GA26558@dumpdata.com> <4E56B132.9050708@overnetdata.com> <20110826142606.GA25511@dumpdata.com> <20110826144438.GA24836@dumpdata.com> <4E5E6843.7050206@citrix.com> <20110831170711.GB13642@dumpdata.com> <1314862972.28989.74.camel@zakaz.uk.xensource.com> <4E5FC197.7040004@goop.org> Content-Type: text/plain; charset="ISO-8859-1" Organization: Citrix Systems, Inc. Date: Thu, 1 Sep 2011 20:21:45 +0100 Message-ID: <1314904905.19389.28.camel@dagon.hellion.org.uk> MIME-Version: 1.0 X-Mailer: Evolution 2.32.3 Content-Transfer-Encoding: 7bit Cc: "xen-devel@lists.xensource.com" , Anthony Wright , Konrad Rzeszutek Wilk , David Vrabel , Todd, Deshane X-BeenThere: xen-devel@lists.xensource.com X-Mailman-Version: 2.1.5 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xensource.com Errors-To: xen-devel-bounces@lists.xensource.com On Thu, 2011-09-01 at 18:32 +0100, Jeremy Fitzhardinge wrote: > On 09/01/2011 12:42 AM, Ian Campbell wrote: > > On Wed, 2011-08-31 at 18:07 +0100, Konrad Rzeszutek Wilk wrote: > >> On Wed, Aug 31, 2011 at 05:58:43PM +0100, David Vrabel wrote: > >>> On 26/08/11 15:44, Konrad Rzeszutek Wilk wrote: > >>>> So while I am still looking at the hypervisor code to figure out why > >>>> it would give me [when trying to map a grant page]: > >>>> > >>>> (XEN) mm.c:3846:d0 Could not find L1 PTE for address fbb42000 > >>> It is failing in guest_map_l1e() because the page for the vmalloc'd > >>> virtual address PTEs is not present. > >>> > >>> The test that fails is: > >>> > >>> (l2e_get_flags(l2e) & (_PAGE_PRESENT | _PAGE_PSE)) != _PAGE_PRESENT > >>> > >>> I think this is because the GNTTABOP_map_grant_ref hypercall is done > >>> when task->active_mm != &init_mm and alloc_vm_area() only adds PTEs into > >>> init_mm so when Xen looks in the page tables it doesn't find the entries > >>> because they're not there yet. > >>> > >>> Putting a call to vmalloc_sync_all() after create_vm_area() and before > >>> the hypercall makes it work for me. Classic Xen kernels used to have > >>> such a call. > >> That sounds quite reasonable. > > I was wondering why upstream was missing the vmalloc_sync_all() in > > alloc_vm_area() since the out-of-tree kernels did have it and the > > function was added by us. I found this: > > http://git.kernel.org/?p=linux/kernel/git/torvalds/linux.git;a=commitdiff;h=ef691947d8a3d479e67652312783aedcf629320a > > > > commit ef691947d8a3d479e67652312783aedcf629320a > > Author: Jeremy Fitzhardinge > > Date: Wed Dec 1 15:45:48 2010 -0800 > > > > vmalloc: remove vmalloc_sync_all() from alloc_vm_area() > > > > There's no need for it: it will get faulted into the current pagetable > > as needed. > > > > Signed-off-by: Jeremy Fitzhardinge > > > > The flaw in the reasoning here is that you cannot take a kernel fault > > while processing a hypercall, so hypercall arguments must have been > > faulted in beforehand and that is what the sync_all was for. > > That's a good point. (Maybe Xen should have generated pagefaults when > hypercall arg pointers are bad...) I think it would be a bit tricky to do in practice, you'd either have to support recursive hypercalls in the middle of other hypercalls (because the page fault handler is surely going to want to do some) or proper hypercall restart (so you can fully return to guest context to handle the fault then retry) or something along those and complexifying up the hypervisor one way or another. Probably not impossible if you were building something form the ground up, but not trivial. > > It's probably fair to say that the Xen specific caller should take care > > of that Xen-specific requirement rather than pushing it into common > > code. On the other hand Xen is the only user and creating a Xen specific > > helper/wrapper seems a bit pointless. > > There's already a wrapper: xen_alloc_vm_area(), which is just a > #define. But we could easily add a sync_all to it (and use it in > netback, like we do in grant-table and xenbus). OOI what was the wrapper for originally? Ian. _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel From xen-devel-bounces@lists.xensource.com Thu Sep 01 12:29:15 2011 Return-path: Envelope-to: www-data@lists.xensource.com Delivery-date: Thu, 01 Sep 2011 12:29:15 -0700 Received: from localhost ([127.0.0.1] helo=lists.colo.xensource.com) by lists.xensource.com with esmtp (Exim 4.43) id 1QzCwt-0000HZ-2J; Thu, 01 Sep 2011 12:29:15 -0700 Received: from mail182.messagelabs.com ([85.158.139.83]) by lists.xensource.com with smtp (Exim 4.43) id 1QzCwS-00005C-7q for xen-devel@lists.xensource.com; Thu, 01 Sep 2011 12:28:48 -0700 X-Env-Sender: drjones@redhat.com X-Msg-Ref: server-3.tower-182.messagelabs.com!1314905324!13934916!1 X-Originating-IP: [209.132.183.25] X-StarScan-Version: 6.3.6; banners=-,-,- X-VirusChecked: Checked Received: (qmail 19951 invoked from network); 1 Sep 2011 19:28:44 -0000 Received: from mx4-phx2.redhat.com (HELO mx4-phx2.redhat.com) (209.132.183.25) by server-3.tower-182.messagelabs.com with SMTP; 1 Sep 2011 19:28:44 -0000 Received: from mail01.corp.redhat.com (zmail01.collab.prod.int.phx2.redhat.com [10.5.5.41]) by mx4-phx2.redhat.com (8.13.8/8.13.8) with ESMTP id p81JSdBr003015; Thu, 1 Sep 2011 15:28:39 -0400 Date: Thu, 1 Sep 2011 15:28:39 -0400 (EDT) From: Andrew Jones To: Ian Jackson Message-ID: <1653323123.636758.1314905319336.JavaMail.root@zmail01.collab.prod.int.phx2.redhat.com> In-Reply-To: <20063.45607.355820.209628@mariner.uk.xensource.com> Subject: Re: [Xen-devel] [xen-unstable bisection] complete test-amd64-i386-rhel6hvm-intel MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit X-Originating-IP: [10.5.5.72] X-Mailer: Zimbra 6.0.9_GA_2686 (ZimbraWebClient - FF3.0 (Linux)/6.0.9_GA_2686) Cc: Laszlo Ersek , xen-devel@lists.xensource.com, keir@xen.org, stefano stabellini X-BeenThere: xen-devel@lists.xensource.com X-Mailman-Version: 2.1.5 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xensource.com Errors-To: xen-devel-bounces@lists.xensource.com ----- Original Message ----- > xen.org writes ("[Xen-devel] [xen-unstable bisection] complete > test-amd64-i386-rhel6hvm-intel"): > > branch xen-unstable > > xen branch xen-unstable > > job test-amd64-i386-rhel6hvm-intel > > test xen-install > > > > Tree: linux > > git://git.eu.kernel.org/pub/scm/linux/kernel/git/jeremy/xen.git > > Tree: qemu git://hg.uk.xensource.com/HG/qemu-xen-unstable.git > > Tree: xen http://hg.uk.xensource.com/xen-unstable.hg > > > > *** Found and reproduced problem changeset *** > > > > Bug is in tree: xen http://hg.uk.xensource.com/xen-unstable.hg > > Bug introduced: bb9b81008733 > > Bug not present: d54cfae72cd1 > > > > > > changeset: 23802:bb9b81008733 > > user: Laszlo Ersek > > date: Wed Aug 31 15:16:14 2011 +0100 > > > > x86: Increase the default NR_CPUS to 256 > > > > Changeset 21012:ef845a385014 bumped the default to 128 about > > one and a > > half years ago. Increase it now to 256, as systems with eg. > > 160 > > logical CPUs are becoming (have become) common. > > > > Signed-off-by: Laszlo Ersek > > My bisector is pretty reliable nowadays. Looking at the revision > graph it tested before/after/before/after/before/after, ie three times > each on the same host. > > This change looks innocuous enough TBH. Is there any way this change > could have broken a PV-on-HVM guest ? Note that RHEL6, which is what > this is testing, seems to generally be full of bugs. It's seems unlikely this change could break a guest, but without any output from you tests it's impossible to tell. The fact it failed on the same host each of the three times is probably a clue worth looking further at. I take it that it succeeded on other hosts? Which RHEL6 kernel release do you test with? When you say "full of bugs", where have the bugs been filed? Are those bugs only present with the pv-on-hvm drivers? IMO, the HV should support the guest (especially an HVM guest), even if it was based on something as "old" as 2.6.32. So the bugs you're finding should likely be looked at from both the host and the guest sides, certainly not ignored. > > If the problem is indeed a bug in the current RHEL6 then I will add > this test to the "do not care" list. > This attitude won't get anybody anywhere. > Ian. > > _______________________________________________ > Xen-devel mailing list > Xen-devel@lists.xensource.com > http://lists.xensource.com/xen-devel _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel From xen-devel-bounces@lists.xensource.com Thu Sep 01 13:35:56 2011 Return-path: Envelope-to: www-data@lists.xensource.com Delivery-date: Thu, 01 Sep 2011 13:35:56 -0700 Received: from localhost ([127.0.0.1] helo=lists.colo.xensource.com) by lists.xensource.com with esmtp (Exim 4.43) id 1QzDzO-0001yw-6y; Thu, 01 Sep 2011 13:35:54 -0700 Received: from mail174.messagelabs.com ([85.158.138.51]) by lists.xensource.com with esmtp (Exim 4.43) id 1QzDyc-0001lp-Jc for xen-devel@lists.xensource.com; Thu, 01 Sep 2011 13:35:07 -0700 X-Env-Sender: jeremy@goop.org X-Msg-Ref: server-5.tower-174.messagelabs.com!1314909301!26236494!1 X-Originating-IP: [74.207.240.146] X-StarScan-Version: 6.3.6; banners=-,-,- X-VirusChecked: Checked Received: (qmail 18272 invoked from network); 1 Sep 2011 20:35:03 -0000 Received: from claw.goop.org (HELO claw.goop.org) (74.207.240.146) by server-5.tower-174.messagelabs.com with DHE-RSA-AES256-SHA encrypted SMTP; 1 Sep 2011 20:35:03 -0000 Received: from saboo.goop.org (unknown [IPv6:2001:470:1f05:899:a4d0:63ff:fe78:9062]) (Authenticated sender: smtp-saboo) by claw.goop.org (Postfix) with ESMTPSA id 77321362; Thu, 1 Sep 2011 13:35:00 -0700 (PDT) Received: from saboo.goop.org (localhost [IPv6:::1]) by saboo.goop.org (Postfix) with ESMTP id 7CDA72034D; Thu, 1 Sep 2011 13:34:57 -0700 (PDT) Message-ID: <4E5FEC71.4090504@goop.org> Date: Thu, 01 Sep 2011 13:34:57 -0700 From: Jeremy Fitzhardinge User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:6.0) Gecko/20110816 Thunderbird/6.0 MIME-Version: 1.0 To: Ian Campbell Subject: Re: [Xen-devel] Kernel bug from 3.0 (was phy disks and vifs timing out in DomU) References: <4E31820C.5030200@overnetdata.com> <1311870512.24408.153.camel@cthulhu.hellion.org.uk> <4E3266DE.9000606@overnetdata.com> <20110803152841.GA2860@dumpdata.com> <4E4E3957.1040007@overnetdata.com> <20110819125615.GA26558@dumpdata.com> <4E56B132.9050708@overnetdata.com> <20110826142606.GA25511@dumpdata.com> <20110826144438.GA24836@dumpdata.com> <4E5E6843.7050206@citrix.com> <20110831170711.GB13642@dumpdata.com> <1314862972.28989.74.camel@zakaz.uk.xensource.com> <4E5FC197.7040004@goop.org> <1314904905.19389.28.camel@dagon.hellion.org.uk> In-Reply-To: <1314904905.19389.28.camel@dagon.hellion.org.uk> X-Enigmail-Version: 1.3.1 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: "xen-devel@lists.xensource.com" , Keir Fraser , Anthony Wright , Konrad Rzeszutek Wilk , David Vrabel , Todd Deshane X-BeenThere: xen-devel@lists.xensource.com X-Mailman-Version: 2.1.5 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xensource.com Errors-To: xen-devel-bounces@lists.xensource.com On 09/01/2011 12:21 PM, Ian Campbell wrote: > On Thu, 2011-09-01 at 18:32 +0100, Jeremy Fitzhardinge wrote: >> On 09/01/2011 12:42 AM, Ian Campbell wrote: >>> On Wed, 2011-08-31 at 18:07 +0100, Konrad Rzeszutek Wilk wrote: >>>> On Wed, Aug 31, 2011 at 05:58:43PM +0100, David Vrabel wrote: >>>>> On 26/08/11 15:44, Konrad Rzeszutek Wilk wrote: >>>>>> So while I am still looking at the hypervisor code to figure out why >>>>>> it would give me [when trying to map a grant page]: >>>>>> >>>>>> (XEN) mm.c:3846:d0 Could not find L1 PTE for address fbb42000 >>>>> It is failing in guest_map_l1e() because the page for the vmalloc'd >>>>> virtual address PTEs is not present. >>>>> >>>>> The test that fails is: >>>>> >>>>> (l2e_get_flags(l2e) & (_PAGE_PRESENT | _PAGE_PSE)) != _PAGE_PRESENT >>>>> >>>>> I think this is because the GNTTABOP_map_grant_ref hypercall is done >>>>> when task->active_mm != &init_mm and alloc_vm_area() only adds PTEs into >>>>> init_mm so when Xen looks in the page tables it doesn't find the entries >>>>> because they're not there yet. >>>>> >>>>> Putting a call to vmalloc_sync_all() after create_vm_area() and before >>>>> the hypercall makes it work for me. Classic Xen kernels used to have >>>>> such a call. >>>> That sounds quite reasonable. >>> I was wondering why upstream was missing the vmalloc_sync_all() in >>> alloc_vm_area() since the out-of-tree kernels did have it and the >>> function was added by us. I found this: >>> http://git.kernel.org/?p=linux/kernel/git/torvalds/linux.git;a=commitdiff;h=ef691947d8a3d479e67652312783aedcf629320a >>> >>> commit ef691947d8a3d479e67652312783aedcf629320a >>> Author: Jeremy Fitzhardinge >>> Date: Wed Dec 1 15:45:48 2010 -0800 >>> >>> vmalloc: remove vmalloc_sync_all() from alloc_vm_area() >>> >>> There's no need for it: it will get faulted into the current pagetable >>> as needed. >>> >>> Signed-off-by: Jeremy Fitzhardinge >>> >>> The flaw in the reasoning here is that you cannot take a kernel fault >>> while processing a hypercall, so hypercall arguments must have been >>> faulted in beforehand and that is what the sync_all was for. >> That's a good point. (Maybe Xen should have generated pagefaults when >> hypercall arg pointers are bad...) > I think it would be a bit tricky to do in practice, you'd either have to > support recursive hypercalls in the middle of other hypercalls (because > the page fault handler is surely going to want to do some) or proper > hypercall restart (so you can fully return to guest context to handle > the fault then retry) or something along those and complexifying up the > hypervisor one way or another. Probably not impossible if you were > building something form the ground up, but not trivial. Well, Xen already has the continuation machinery for dealing with hypercall restart, so that could be reused. And accesses to guest memory are already special events which must be checked so that EFAULT can be returned. If, rather than failing with EFAULT Xen set up a pagefault exception for the guest CPU with the return set up to retry the hypercall, it should all work... Of course, if the guest isn't expecting that - or its buggy - then it could end up in an infinite loop. But maybe a flag (set a high bit in the hypercall number?), or a feature, or something? Might be worthwhile if it saves guests having to do something expensive (like a vmalloc_sync_all), even if they have to also deal with old hypervisors. >> There's already a wrapper: xen_alloc_vm_area(), which is just a >> #define. But we could easily add a sync_all to it (and use it in >> netback, like we do in grant-table and xenbus). > OOI what was the wrapper for originally? Not sure; I brought it over from 2.6.18-xen. BTW, vmalloc_sync_all() is much hated, and is slated for removal at some point - there are definitely target sights on it. So we should think about not needing it. J _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel From xen-devel-bounces@lists.xensource.com Thu Sep 01 13:38:29 2011 Return-path: Envelope-to: www-data@lists.xensource.com Delivery-date: Thu, 01 Sep 2011 13:38:29 -0700 Received: from localhost ([127.0.0.1] helo=lists.colo.xensource.com) by lists.xensource.com with esmtp (Exim 4.43) id 1QzE1s-0002O5-EZ; Thu, 01 Sep 2011 13:38:29 -0700 Received: from mail174.messagelabs.com ([85.158.138.51]) by lists.xensource.com with esmtp (Exim 4.43) id 1QzE1O-0002BG-7E for xen-devel@lists.xensource.com; Thu, 01 Sep 2011 13:37:58 -0700 X-Env-Sender: jeremy@goop.org X-Msg-Ref: server-15.tower-174.messagelabs.com!1314909473!23586783!1 X-Originating-IP: [74.207.240.146] X-StarScan-Version: 6.3.6; banners=-,-,- X-VirusChecked: Checked Received: (qmail 29500 invoked from network); 1 Sep 2011 20:37:55 -0000 Received: from claw.goop.org (HELO claw.goop.org) (74.207.240.146) by server-15.tower-174.messagelabs.com with DHE-RSA-AES256-SHA encrypted SMTP; 1 Sep 2011 20:37:55 -0000 Received: from saboo.goop.org (unknown [IPv6:2001:470:1f05:899:a4d0:63ff:fe78:9062]) (Authenticated sender: smtp-saboo) by claw.goop.org (Postfix) with ESMTPSA id 995B0377; Thu, 1 Sep 2011 13:37:52 -0700 (PDT) Received: from saboo.goop.org (localhost [IPv6:::1]) by saboo.goop.org (Postfix) with ESMTP id 3D120200B6; Thu, 1 Sep 2011 13:37:46 -0700 (PDT) Message-ID: <4E5FED1A.1000300@goop.org> Date: Thu, 01 Sep 2011 13:37:46 -0700 From: Jeremy Fitzhardinge User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:6.0) Gecko/20110816 Thunderbird/6.0 MIME-Version: 1.0 To: Konrad Rzeszutek Wilk References: <1314877863-21977-1-git-send-email-david.vrabel@citrix.com> <20110901161134.GA8979@dumpdata.com> In-Reply-To: <20110901161134.GA8979@dumpdata.com> X-Enigmail-Version: 1.3.1 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: "xen-devel@lists.xensource.com" , "namhyung@gmail.com" , "linux-kernel@vger.kernel.org" , "linux-mm@kvack.org" , David Vrabel , "rientjes@google.com" , "akpm@linux-foundation.org" , "paulmck@linux.vnet.ibm.com" Subject: [Xen-devel] Re: [Revert] Re: [PATCH] mm: sync vmalloc address space page tables in alloc_vm_area() X-BeenThere: xen-devel@lists.xensource.com X-Mailman-Version: 2.1.5 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xensource.com Errors-To: xen-devel-bounces@lists.xensource.com On 09/01/2011 09:11 AM, Konrad Rzeszutek Wilk wrote: > On Thu, Sep 01, 2011 at 12:51:03PM +0100, David Vrabel wrote: >> From: David Vrabel > Andrew, > > I was wondering if you would be Ok with this patch for 3.1. > > It is a revert (I can prepare a proper revert if you would like > that instead of this patch). > > The users of this particular function (alloc_vm_area) are just > Xen. There are no others. I'd prefer to put explicit vmalloc_sync_all()s in the callsites where necessary, and ultimately try to work out ways of avoiding it altogether (like have some hypercall wrapper which touches the arg memory to make sure its mapped?). J _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel From xen-devel-bounces@lists.xensource.com Thu Sep 01 14:14:47 2011 Return-path: Envelope-to: www-data@lists.xensource.com Delivery-date: Thu, 01 Sep 2011 14:14:47 -0700 Received: from localhost ([127.0.0.1] helo=lists.colo.xensource.com) by lists.xensource.com with esmtp (Exim 4.43) id 1QzEb1-0003pO-2J; Thu, 01 Sep 2011 14:14:47 -0700 Received: from mail21.messagelabs.com ([85.158.143.35]) by lists.xensource.com with smtp (Exim 4.43) id 1QzEZL-0003bp-0l for xen-devel@lists.xensource.com; Thu, 01 Sep 2011 14:13:05 -0700 X-Env-Sender: Ian.Jackson@eu.citrix.com X-Msg-Ref: server-12.tower-21.messagelabs.com!1314911567!48381874!1 X-Originating-IP: [62.200.22.115] X-StarScan-Version: 6.3.6; banners=-,-,- X-VirusChecked: Checked Received: (qmail 2115 invoked from network); 1 Sep 2011 21:12:47 -0000 Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115) by server-12.tower-21.messagelabs.com with SMTP; 1 Sep 2011 21:12:47 -0000 X-IronPort-AV: E=Sophos;i="4.68,315,1312156800"; d="scan'208";a="7562487" Received: from lonpmailmx01.citrite.net ([10.30.203.162]) by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5; 01 Sep 2011 21:12:59 +0000 Received: from woking.xci-test.com (10.80.248.135) by smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id 8.3.137.0; Thu, 1 Sep 2011 22:12:59 +0100 Received: from osstest by woking.xci-test.com with local (Exim 4.69) (envelope-from ) id 1QzEZH-0000ro-Cv; Thu, 01 Sep 2011 22:12:59 +0100 To: xen-devel@lists.xensource.com Message-ID: From: xen.org Date: Thu, 1 Sep 2011 22:12:59 +0100 MIME-Version: 1.0 Content-Type: text/plain Cc: ian.jackson@eu.citrix.com Subject: [Xen-devel] [xen-unstable test] 8814: regressions - FAIL X-BeenThere: xen-devel@lists.xensource.com X-Mailman-Version: 2.1.5 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xensource.com Errors-To: xen-devel-bounces@lists.xensource.com flight 8814 xen-unstable real [real] http://www.chiark.greenend.org.uk/~xensrcts/logs/8814/ Regressions :-( Tests which did not succeed and are blocking: test-amd64-amd64-xl-sedf 7 debian-install fail REGR. vs. 8769 test-i386-i386-win 8 guest-saverestore fail REGR. vs. 8769 Tests which did not succeed, but are not blocking, including regressions (tests previously passed) regarded as allowable: test-amd64-amd64-xl-pcipt-intel 9 guest-start fail never pass test-amd64-i386-rhel6hvm-intel 9 guest-start.2 fail never pass test-amd64-i386-win-vcpus1 16 leak-check/check fail never pass test-amd64-i386-rhel6hvm-amd 9 guest-start.2 fail never pass test-amd64-i386-win 16 leak-check/check fail never pass test-amd64-amd64-xl-win 13 guest-stop fail never pass test-i386-i386-xl-win 13 guest-stop fail never pass test-amd64-amd64-win 16 leak-check/check fail never pass test-amd64-i386-xl-win-vcpus1 13 guest-stop fail never pass version targeted for testing: xen a6a5bda3c962 baseline version: xen ac9aa65050e9 ------------------------------------------------------------ People who touched revisions under test: Andrew Cooper Christoph Egger Dietmar Hahn Ian Campbell Ian Jackson Keir Fraser Kevin Tian Laszlo Ersek Olaf Hering Stefano Stabellini Tim Deegan ------------------------------------------------------------ jobs: build-amd64 pass build-i386 pass build-amd64-oldkern pass build-i386-oldkern pass build-amd64-pvops pass build-i386-pvops pass test-amd64-amd64-xl pass test-amd64-i386-xl pass test-i386-i386-xl pass test-amd64-i386-rhel6hvm-amd fail test-amd64-i386-xl-credit2 pass test-amd64-amd64-xl-pcipt-intel fail test-amd64-i386-rhel6hvm-intel fail test-amd64-i386-xl-multivcpu pass test-amd64-amd64-pair pass test-amd64-i386-pair pass test-i386-i386-pair pass test-amd64-amd64-pv pass test-amd64-i386-pv pass test-i386-i386-pv pass test-amd64-amd64-xl-sedf fail test-amd64-i386-win-vcpus1 fail test-amd64-i386-xl-win-vcpus1 fail test-amd64-amd64-win fail test-amd64-i386-win fail test-i386-i386-win fail test-amd64-amd64-xl-win fail test-i386-i386-xl-win fail ------------------------------------------------------------ sg-report-flight on woking.cam.xci-test.com logs: /home/xc_osstest/logs images: /home/xc_osstest/images Logs, config files, etc. are available at http://www.chiark.greenend.org.uk/~xensrcts/logs Test harness code can be found at http://xenbits.xensource.com/gitweb?p=osstest.git;a=summary Not pushing. ------------------------------------------------------------ changeset: 23810:a6a5bda3c962 tag: tip user: Ian Campbell date: Thu Sep 01 17:46:43 2011 +0100 xen/x86: only support >128 CPUs on x86_64 32 bit cannot cope with 256 cpus and hits: /* At least half the ioremap space should be available to us. */ BUILD_BUG_ON(IOREMAP_VIRT_START + (IOREMAP_MBYTES << 19) >= FIXADDR_START); Signed-off-by: Ian Campbell changeset: 23809:85b29185c911 user: Tim Deegan date: Thu Sep 01 09:39:25 2011 +0100 x86/mm: use defines for page sizes rather hardcoding them. Signed-off-by: Christoph Egger Acked-by: Tim Deegan Committed-by: Tim Deegan changeset: 23808:4a4882df5649 user: Stefano Stabellini date: Wed Aug 31 15:23:49 2011 +0100 xen: get_free_pirq: make sure that the returned pirq is allocated Signed-off-by: Stefano Stabellini changeset: 23807:2297b90a6a7b user: Stefano Stabellini date: Wed Aug 31 15:23:34 2011 +0100 xen: __hvm_pci_intx_assert should check for gsis remapped onto pirqs If the isa irq corresponding to a particular gsi is disabled while the gsi is enabled, __hvm_pci_intx_assert will always inject the gsi through the violapic, even if the gsi has been remapped onto a pirq. This patch makes sure that even in this case we inject the notification appropriately. Signed-off-by: Stefano Stabellini changeset: 23806:4226ea1785b5 user: Stefano Stabellini date: Wed Aug 31 15:23:12 2011 +0100 xen: fix hvm_domain_use_pirq's behavior hvm_domain_use_pirq should return true when the guest is using a certain pirq, no matter if the corresponding event channel is currently enabled or disabled. As an additional complication, qemu is going to request pirqs for passthrough devices even for Xen unaware HVM guests, so we need to wait for an event channel to be connected before considering the pirq of a passthrough device as "in use". Signed-off-by: Stefano Stabellini changeset: 23805:7048810180de user: Andrew Cooper date: Wed Aug 31 15:19:24 2011 +0100 IRQ: manually EOI migrating line interrupts When migrating IO-APIC line level interrupts between PCPUs, the migration code rewrites the IO-APIC entry to point to the new CPU/Vector before EOI'ing it. The EOI process says that EOI'ing the Local APIC will cause a broadcast with the vector number, which the IO-APIC must listen to to clear the IRR and Status bits. In the case of migrating, the IO-APIC has already been reprogrammed so the EOI broadcast with the old vector fails to match the new vector, leaving the IO-APIC with an outstanding vector, preventing any more use of that line interrupt. This causes a lockup especially when your root device is using PCI INTA (megaraid_sas driver *ehem*) However, the problem is mostly hidden because send_cleanup_vector() causes a cleanup of all moving vectors on the current PCPU in such a way which does not cause the problem, and if the problem has occured, the writes it makes to the IO-APIC clears the IRR and Status bits which unlocks the problem. This fix is distinctly a temporary hack, waiting on a cleanup of the irq code. It checks for the edge case where we have moved the irq, and manually EOI's the old vector with the IO-APIC which correctly clears the IRR and Status bits. Also, it protects the code which updates irq_cfg by disabling interrupts. Signed-off-by: Andrew Cooper changeset: 23804:42d76c68b2bf user: Kevin Tian date: Wed Aug 31 15:18:23 2011 +0100 x86: add irq count for IPIs such count is useful to assist decision make in cpuidle governor, while w/o this patch only device interrupts through do_IRQ is currently counted. Signed-off-by: Kevin Tian changeset: 23803:51983821efa4 user: Dietmar Hahn date: Wed Aug 31 15:17:45 2011 +0100 vpmu: Add processors Westmere E7-8837 and SandyBridge i5-2500 to the vpmu list Signed-off-by: Dietmar Hahn changeset: 23802:bb9b81008733 user: Laszlo Ersek date: Wed Aug 31 15:16:14 2011 +0100 x86: Increase the default NR_CPUS to 256 Changeset 21012:ef845a385014 bumped the default to 128 about one and a half years ago. Increase it now to 256, as systems with eg. 160 logical CPUs are becoming (have become) common. Signed-off-by: Laszlo Ersek changeset: 23801:d54cfae72cd1 user: Christoph Egger date: Wed Aug 31 15:15:41 2011 +0100 nestedsvm: VMRUN doesn't use nextrip VMRUN does not use nextrip. So remove pointless assignment. Signed-off-by: Christoph Egger changeset: 23800:72edc40e2942 user: Keir Fraser date: Wed Aug 31 15:14:49 2011 +0100 x86-64: Fix off-by-one error in __addr_ok() macro Signed-off-by: Laszlo Ersek Signed-off-by: Keir Fraser changeset: 23799:ac9aa65050e9 parent: 23798:469aa1fbd843 parent: 23797:2c687e70a343 user: Ian Jackson date: Tue Aug 30 11:46:58 2011 +0100 Merge ======================================== commit cd776ee9408ff127f934a707c1a339ee600bc127 Author: Ian Jackson Date: Tue Jun 28 13:50:53 2011 +0100 qemu-char.c: fix incorrect CONFIG_STUBDOM handling qemu-char.c:1123:7: warning: "CONFIG_STUBDOM" is not defined [-Wundef] Signed-off-by: Olaf Hering Acked-by: Ian Jackson _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel From xen-devel-bounces@lists.xensource.com Thu Sep 01 14:19:28 2011 Return-path: Envelope-to: www-data@lists.xensource.com Delivery-date: Thu, 01 Sep 2011 14:19:28 -0700 Received: from localhost ([127.0.0.1] helo=lists.colo.xensource.com) by lists.xensource.com with esmtp (Exim 4.43) id 1QzEfY-0004LG-73; Thu, 01 Sep 2011 14:19:28 -0700 Received: from mail216.messagelabs.com ([85.158.143.99]) by lists.xensource.com with esmtp (Exim 4.43) id 1QzEek-000488-9I for xen-devel@lists.xensource.com; Thu, 01 Sep 2011 14:18:39 -0700 X-Env-Sender: akpm@linux-foundation.org X-Msg-Ref: server-6.tower-216.messagelabs.com!1314911913!15508878!1 X-Originating-IP: [140.211.169.13] X-StarScan-Version: 6.3.6; banners=-,-,- X-VirusChecked: Checked Received: (qmail 8867 invoked from network); 1 Sep 2011 21:18:35 -0000 Received: from smtp1.linux-foundation.org (HELO smtp1.linux-foundation.org) (140.211.169.13) by server-6.tower-216.messagelabs.com with DHE-RSA-AES256-SHA encrypted SMTP; 1 Sep 2011 21:18:35 -0000 Received: from imap1.linux-foundation.org (imap1.linux-foundation.org [140.211.169.55]) by smtp1.linux-foundation.org (8.14.2/8.13.5/Debian-3ubuntu1.1) with ESMTP id p81LHtR0028148 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 1 Sep 2011 14:17:55 -0700 Received: from akpm.mtv.corp.google.com (localhost [127.0.0.1]) by imap1.linux-foundation.org (8.13.5.20060308/8.13.5/Debian-3ubuntu1.1) with SMTP id p81LHsxA029787; Thu, 1 Sep 2011 14:17:54 -0700 Date: Thu, 1 Sep 2011 14:17:54 -0700 From: Andrew Morton To: Jeremy Fitzhardinge Message-Id: <20110901141754.76cef93b.akpm@linux-foundation.org> In-Reply-To: <4E5FED1A.1000300@goop.org> References: <1314877863-21977-1-git-send-email-david.vrabel@citrix.com> <20110901161134.GA8979@dumpdata.com> <4E5FED1A.1000300@goop.org> X-Mailer: Sylpheed 3.0.2 (GTK+ 2.20.1; x86_64-pc-linux-gnu) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-Spam-Status: No, hits=-104.975 required=5 tests=AWL, BAYES_00, OSDL_HEADER_SUBJECT_BRACKETED, PATCH_SUBJECT_OSDL, USER_IN_WHITELIST X-Spam-Checker-Version: SpamAssassin 3.2.4-osdl_revision__1.47__ X-MIMEDefang-Filter: lf$Revision: 1.188 $ X-Scanned-By: MIMEDefang 2.63 on 140.211.169.13 Cc: "xen-devel@lists.xensource.com" , Konrad Rzeszutek Wilk , "namhyung@gmail.com" , "linux-kernel@vger.kernel.org" , "linux-mm@kvack.org" , David Vrabel , "rientjes@google.com" , "paulmck@linux.vnet.ibm.com" Subject: [Xen-devel] Re: [Revert] Re: [PATCH] mm: sync vmalloc address space page tables in alloc_vm_area() X-BeenThere: xen-devel@lists.xensource.com X-Mailman-Version: 2.1.5 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xensource.com Errors-To: xen-devel-bounces@lists.xensource.com On Thu, 01 Sep 2011 13:37:46 -0700 Jeremy Fitzhardinge wrote: > On 09/01/2011 09:11 AM, Konrad Rzeszutek Wilk wrote: > > On Thu, Sep 01, 2011 at 12:51:03PM +0100, David Vrabel wrote: > >> From: David Vrabel > > Andrew, > > > > I was wondering if you would be Ok with this patch for 3.1. > > > > It is a revert (I can prepare a proper revert if you would like > > that instead of this patch). David's patch looks better than a straight reversion. Problem is, I can't find David's original email anywhere. Someone's been playing games with To: headers? > > The users of this particular function (alloc_vm_area) are just > > Xen. There are no others. > > I'd prefer to put explicit vmalloc_sync_all()s in the callsites where > necessary, What would that patch look like? Bear in mind that we'll need something suitable for 3.1 and for a 3.0 backport. > and ultimately try to work out ways of avoiding it altogether > (like have some hypercall wrapper which touches the arg memory to make > sure its mapped?). _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel From xen-devel-bounces@lists.xensource.com Thu Sep 01 14:30:42 2011 Return-path: Envelope-to: www-data@lists.xensource.com Delivery-date: Thu, 01 Sep 2011 14:30:42 -0700 Received: from localhost ([127.0.0.1] helo=lists.colo.xensource.com) by lists.xensource.com with esmtp (Exim 4.43) id 1QzEqQ-0004rx-Mp; Thu, 01 Sep 2011 14:30:42 -0700 Received: from mail174.messagelabs.com ([85.158.138.51]) by lists.xensource.com with esmtp (Exim 4.43) id 1QzEpc-0004f5-La for xen-devel@lists.xensource.com; Thu, 01 Sep 2011 14:29:53 -0700 X-Env-Sender: m.a.young@durham.ac.uk X-Msg-Ref: server-8.tower-174.messagelabs.com!1314912589!16260292!1 X-Originating-IP: [129.234.248.1] X-StarScan-Version: 6.3.6; banners=-,-,- X-VirusChecked: Checked Received: (qmail 24157 invoked from network); 1 Sep 2011 21:29:49 -0000 Received: from hermes1.dur.ac.uk (HELO hermes1.dur.ac.uk) (129.234.248.1) by server-8.tower-174.messagelabs.com with DHE-RSA-AES256-SHA encrypted SMTP; 1 Sep 2011 21:29:49 -0000 Received: from smtphost3.dur.ac.uk (smtphost3.dur.ac.uk [129.234.252.3]) by hermes1.dur.ac.uk (8.13.8/8.13.7) with ESMTP id p81LTYh8014439 for ; Thu, 1 Sep 2011 22:29:38 +0100 Received: from vega3.dur.ac.uk (vega3.dur.ac.uk [129.234.250.131]) by smtphost3.dur.ac.uk (8.13.8/8.13.7) with ESMTP id p81LTKKE029581 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Thu, 1 Sep 2011 22:29:20 +0100 Received: from vega3.dur.ac.uk (localhost [127.0.0.1]) by vega3.dur.ac.uk (8.14.4/8.11.1) with ESMTP id p81LTJIN025516 for ; Thu, 1 Sep 2011 22:29:19 +0100 Received: from localhost (dcl0may@localhost) by vega3.dur.ac.uk (8.14.4/8.14.4/Submit) with ESMTP id p81LTJ3T025512 for ; Thu, 1 Sep 2011 22:29:19 +0100 Date: Thu, 1 Sep 2011 22:29:19 +0100 (BST) From: M A Young To: xen-devel@lists.xensource.com Subject: Re: [Xen-devel] [Xen-deve] xen/stable-2.6.32.x bare-metal: panic early exception 0e rip 10:0 error 10 cr2 0 In-Reply-To: Message-ID: References: <4E4D9A90.30800@leuphana.de> User-Agent: Alpine 2.02 (LFD 1266 2009-07-14) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; format=flowed; charset=US-ASCII X-DurhamAcUk-MailScanner: Found to be clean, Found to be clean X-DurhamAcUk-MailScanner-ID: p81LTYh8014439 X-BeenThere: xen-devel@lists.xensource.com X-Mailman-Version: 2.1.5 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xensource.com Errors-To: xen-devel-bounces@lists.xensource.com On Wed, 31 Aug 2011, M A Young wrote: > On Fri, 19 Aug 2011, Andreas Olsowski wrote: > >> Source: >> git://git.kernel.org/pub/scm/linux/kernel/git/jeremy/xen.git >> >> Tested branches: >> xen/stable-2.6.32.x >> xen/next-2.6.32.x >> >> When trying to boot the current kernel bare-metal it will not load >> properly, instead i am prompted with: >> >> panic early exception 0e rip 10:0 error 10 cr2 0 > > I am seeing this as well. I have been trying to narrow it down a bit, and it > seems to me that the bug was introduced somewhere between xen-2.6.32.39 and > xen-2.6.32.42. xen-2.6.32.40 also crashes. I think that means that it is either commits c3dd7941354fa96a71f2613e2c7a1b215fa175dc or 280802657fb95c52bb5a35d43fea60351883b2af (or something in the stable kernel or else compile differences though both are unlikely). I am still working on this to confirm which patch it is. Michael Young _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel From xen-devel-bounces@lists.xensource.com Thu Sep 01 15:43:18 2011 Return-path: Envelope-to: www-data@lists.xensource.com Delivery-date: Thu, 01 Sep 2011 15:43:18 -0700 Received: from localhost ([127.0.0.1] helo=lists.colo.xensource.com) by lists.xensource.com with esmtp (Exim 4.43) id 1QzFyg-0000IR-4Q; Thu, 01 Sep 2011 15:43:18 -0700 Received: from mail27.messagelabs.com ([193.109.254.147]) by lists.xensource.com with esmtp (Exim 4.43) id 1QzFyA-00005u-9u for xen-devel@lists.xensource.com; Thu, 01 Sep 2011 15:42:46 -0700 X-Env-Sender: jeremy@goop.org X-Msg-Ref: server-6.tower-27.messagelabs.com!1314916945!47264532!1 X-Originating-IP: [74.207.240.146] X-StarScan-Version: 6.3.6; banners=-,-,- X-VirusChecked: Checked Received: (qmail 8664 invoked from network); 1 Sep 2011 22:42:26 -0000 Received: from claw.goop.org (HELO claw.goop.org) (74.207.240.146) by server-6.tower-27.messagelabs.com with DHE-RSA-AES256-SHA encrypted SMTP; 1 Sep 2011 22:42:26 -0000 Received: from saboo.goop.org (unknown [IPv6:2001:470:1f05:899:a4d0:63ff:fe78:9062]) (Authenticated sender: smtp-saboo) by claw.goop.org (Postfix) with ESMTPSA id C86668F53; Thu, 1 Sep 2011 15:42:40 -0700 (PDT) Received: from saboo.goop.org (localhost [IPv6:::1]) by saboo.goop.org (Postfix) with ESMTP id 4D33020231; Thu, 1 Sep 2011 15:42:31 -0700 (PDT) Message-ID: <4E600A57.9040208@goop.org> Date: Thu, 01 Sep 2011 15:42:31 -0700 From: Jeremy Fitzhardinge User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:6.0) Gecko/20110816 Thunderbird/6.0 MIME-Version: 1.0 To: M A Young Subject: Re: [Xen-devel] [Xen-deve] xen/stable-2.6.32.x bare-metal: panic early exception 0e rip 10:0 error 10 cr2 0 References: <4E4D9A90.30800@leuphana.de> In-Reply-To: X-Enigmail-Version: 1.3.1 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: xen-devel@lists.xensource.com X-BeenThere: xen-devel@lists.xensource.com X-Mailman-Version: 2.1.5 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xensource.com Errors-To: xen-devel-bounces@lists.xensource.com On 09/01/2011 02:29 PM, M A Young wrote: > On Wed, 31 Aug 2011, M A Young wrote: > >> On Fri, 19 Aug 2011, Andreas Olsowski wrote: >> >>> Source: >>> git://git.kernel.org/pub/scm/linux/kernel/git/jeremy/xen.git >>> >>> Tested branches: >>> xen/stable-2.6.32.x >>> xen/next-2.6.32.x >>> >>> When trying to boot the current kernel bare-metal it will not load >>> properly, instead i am prompted with: >>> >>> panic early exception 0e rip 10:0 error 10 cr2 0 >> >> I am seeing this as well. I have been trying to narrow it down a bit, >> and it seems to me that the bug was introduced somewhere between >> xen-2.6.32.39 and xen-2.6.32.42. > > xen-2.6.32.40 also crashes. I think that means that it is either > commits c3dd7941354fa96a71f2613e2c7a1b215fa175dc or > 280802657fb95c52bb5a35d43fea60351883b2af (or something in the stable > kernel or else compile differences though both are unlikely). I am > still working on this to confirm which patch it is. 280802657fb95c5 is unlikely - that's just a blkback change. c3dd7941354fa96 looks plausible. J _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel From xen-devel-bounces@lists.xensource.com Thu Sep 01 16:46:05 2011 Return-path: Envelope-to: www-data@lists.xensource.com Delivery-date: Thu, 01 Sep 2011 16:46:05 -0700 Received: from localhost ([127.0.0.1] helo=lists.colo.xensource.com) by lists.xensource.com with esmtp (Exim 4.43) id 1QzGxQ-0001p7-6V; Thu, 01 Sep 2011 16:46:04 -0700 Received: from mail216.messagelabs.com ([85.158.143.99]) by lists.xensource.com with esmtp (Exim 4.43) id 1QzGwZ-0001c7-I1 for xen-devel@lists.xensource.com; Thu, 01 Sep 2011 16:45:11 -0700 X-Env-Sender: m.a.young@durham.ac.uk X-Msg-Ref: server-4.tower-216.messagelabs.com!1314920708!16756711!1 X-Originating-IP: [129.234.248.2] X-StarScan-Version: 6.3.6; banners=-,-,- X-VirusChecked: Checked Received: (qmail 8902 invoked from network); 1 Sep 2011 23:45:08 -0000 Received: from hermes2.dur.ac.uk (HELO hermes2.dur.ac.uk) (129.234.248.2) by server-4.tower-216.messagelabs.com with DHE-RSA-AES256-SHA encrypted SMTP; 1 Sep 2011 23:45:08 -0000 Received: from smtphost4.dur.ac.uk (smtphost4.dur.ac.uk [129.234.252.4]) by hermes2.dur.ac.uk (8.13.8/8.13.7) with ESMTP id p81NinEn031761; Fri, 2 Sep 2011 00:44:53 +0100 Received: from vega3.dur.ac.uk (vega3.dur.ac.uk [129.234.250.131]) by smtphost4.dur.ac.uk (8.13.8/8.13.7) with ESMTP id p81NiYHJ008704 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 2 Sep 2011 00:44:34 +0100 Received: from vega3.dur.ac.uk (localhost [127.0.0.1]) by vega3.dur.ac.uk (8.14.4/8.11.1) with ESMTP id p81NiYM6008522; Fri, 2 Sep 2011 00:44:34 +0100 Received: from localhost (dcl0may@localhost) by vega3.dur.ac.uk (8.14.4/8.14.4/Submit) with ESMTP id p81NiWCp008518; Fri, 2 Sep 2011 00:44:34 +0100 Date: Fri, 2 Sep 2011 00:44:31 +0100 (BST) From: M A Young To: Jeremy Fitzhardinge Subject: Re: [Xen-devel] [Xen-deve] xen/stable-2.6.32.x bare-metal: panic early exception 0e rip 10:0 error 10 cr2 0 In-Reply-To: <4E600A57.9040208@goop.org> Message-ID: References: <4E4D9A90.30800@leuphana.de> <4E600A57.9040208@goop.org> User-Agent: Alpine 2.02 (LFD 1266 2009-07-14) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-DurhamAcUk-MailScanner: Found to be clean, Found to be clean X-DurhamAcUk-MailScanner-ID: p81NinEn031761 Cc: xen-devel@lists.xensource.com X-BeenThere: xen-devel@lists.xensource.com X-Mailman-Version: 2.1.5 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xensource.com Errors-To: xen-devel-bounces@lists.xensource.com On Thu, 1 Sep 2011, Jeremy Fitzhardinge wrote: > On 09/01/2011 02:29 PM, M A Young wrote: >> On Wed, 31 Aug 2011, M A Young wrote: >> >>> On Fri, 19 Aug 2011, Andreas Olsowski wrote: >>> >>>> Source: >>>> git://git.kernel.org/pub/scm/linux/kernel/git/jeremy/xen.git >>>> >>>> Tested branches: >>>> xen/stable-2.6.32.x >>>> xen/next-2.6.32.x >>>> >>>> When trying to boot the current kernel bare-metal it will not load >>>> properly, instead i am prompted with: >>>> >>>> panic early exception 0e rip 10:0 error 10 cr2 0 >>> >>> I am seeing this as well. I have been trying to narrow it down a bit, >>> and it seems to me that the bug was introduced somewhere between >>> xen-2.6.32.39 and xen-2.6.32.42. >> >> xen-2.6.32.40 also crashes. I think that means that it is either >> commits c3dd7941354fa96a71f2613e2c7a1b215fa175dc or >> 280802657fb95c52bb5a35d43fea60351883b2af (or something in the stable >> kernel or else compile differences though both are unlikely). I am >> still working on this to confirm which patch it is. > > 280802657fb95c5 is unlikely - that's just a blkback change. > > c3dd7941354fa96 looks plausible. Yes, xen-2.6.32.40 with c3dd7941354fa96a71f2613e2c7a1b215fa175dc reverted will boot on bare metal. Michael Young _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel From xen-devel-bounces@lists.xensource.com Thu Sep 01 17:09:49 2011 Return-path: Envelope-to: www-data@lists.xensource.com Delivery-date: Thu, 01 Sep 2011 17:09:49 -0700 Received: from localhost ([127.0.0.1] helo=lists.colo.xensource.com) by lists.xensource.com with esmtp (Exim 4.43) id 1QzHKP-0002hG-Iz; Thu, 01 Sep 2011 17:09:49 -0700 Received: from mail182.messagelabs.com ([85.158.139.83]) by lists.xensource.com with smtp (Exim 4.43) id 1QzHJW-0002UT-Ss for xen-devel@lists.xensource.com; Thu, 01 Sep 2011 17:08:56 -0700 X-Env-Sender: Ian.Jackson@eu.citrix.com X-Msg-Ref: server-15.tower-182.messagelabs.com!1314922131!15746354!1 X-Originating-IP: [62.200.22.115] X-StarScan-Version: 6.3.6; banners=-,-,- X-VirusChecked: Checked Received: (qmail 4234 invoked from network); 2 Sep 2011 00:08:51 -0000 Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115) by server-15.tower-182.messagelabs.com with SMTP; 2 Sep 2011 00:08:51 -0000 X-IronPort-AV: E=Sophos;i="4.68,316,1312156800"; d="scan'208";a="7563245" Received: from lonpmailmx01.citrite.net ([10.30.203.162]) by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5; 02 Sep 2011 00:08:51 +0000 Received: from woking.xci-test.com (10.80.248.135) by smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id 8.3.137.0; Fri, 2 Sep 2011 01:08:51 +0100 Received: from osstest by woking.xci-test.com with local (Exim 4.69) (envelope-from ) id 1QzHJT-0000fQ-1Y; Fri, 02 Sep 2011 01:08:51 +0100 To: xen-devel@lists.xensource.com Message-ID: From: xen.org Date: Fri, 2 Sep 2011 01:08:51 +0100 MIME-Version: 1.0 Content-Type: text/plain Cc: ian.jackson@eu.citrix.com Subject: [Xen-devel] [xen-unstable test] 8817: regressions - FAIL X-BeenThere: xen-devel@lists.xensource.com X-Mailman-Version: 2.1.5 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xensource.com Errors-To: xen-devel-bounces@lists.xensource.com flight 8817 xen-unstable real [real] http://www.chiark.greenend.org.uk/~xensrcts/logs/8817/ Regressions :-( Tests which did not succeed and are blocking: test-i386-i386-win 14 guest-start.2 fail REGR. vs. 8769 test-amd64-amd64-xl-sedf 7 debian-install fail in 8814 REGR. vs. 8769 Tests which are failing intermittently (not blocking): test-amd64-amd64-xl-sedf 5 xen-boot fail pass in 8814 test-i386-i386-win 8 guest-saverestore fail in 8814 pass in 8817 Tests which did not succeed, but are not blocking, including regressions (tests previously passed) regarded as allowable: test-amd64-amd64-xl-pcipt-intel 9 guest-start fail never pass test-amd64-i386-rhel6hvm-intel 9 guest-start.2 fail never pass test-amd64-i386-win-vcpus1 16 leak-check/check fail never pass test-amd64-i386-rhel6hvm-amd 9 guest-start.2 fail never pass test-amd64-i386-win 16 leak-check/check fail never pass test-amd64-amd64-xl-win 13 guest-stop fail never pass test-i386-i386-xl-win 13 guest-stop fail never pass test-amd64-amd64-win 16 leak-check/check fail never pass test-amd64-i386-xl-win-vcpus1 13 guest-stop fail never pass version targeted for testing: xen a6a5bda3c962 baseline version: xen ac9aa65050e9 ------------------------------------------------------------ People who touched revisions under test: Andrew Cooper Christoph Egger Dietmar Hahn Ian Campbell Ian Jackson Keir Fraser Kevin Tian Laszlo Ersek Olaf Hering Stefano Stabellini Tim Deegan ------------------------------------------------------------ jobs: build-amd64 pass build-i386 pass build-amd64-oldkern pass build-i386-oldkern pass build-amd64-pvops pass build-i386-pvops pass test-amd64-amd64-xl pass test-amd64-i386-xl pass test-i386-i386-xl pass test-amd64-i386-rhel6hvm-amd fail test-amd64-i386-xl-credit2 pass test-amd64-amd64-xl-pcipt-intel fail test-amd64-i386-rhel6hvm-intel fail test-amd64-i386-xl-multivcpu pass test-amd64-amd64-pair pass test-amd64-i386-pair pass test-i386-i386-pair pass test-amd64-amd64-pv pass test-amd64-i386-pv pass test-i386-i386-pv pass test-amd64-amd64-xl-sedf fail test-amd64-i386-win-vcpus1 fail test-amd64-i386-xl-win-vcpus1 fail test-amd64-amd64-win fail test-amd64-i386-win fail test-i386-i386-win fail test-amd64-amd64-xl-win fail test-i386-i386-xl-win fail ------------------------------------------------------------ sg-report-flight on woking.cam.xci-test.com logs: /home/xc_osstest/logs images: /home/xc_osstest/images Logs, config files, etc. are available at http://www.chiark.greenend.org.uk/~xensrcts/logs Test harness code can be found at http://xenbits.xensource.com/gitweb?p=osstest.git;a=summary Not pushing. ------------------------------------------------------------ changeset: 23810:a6a5bda3c962 tag: tip user: Ian Campbell date: Thu Sep 01 17:46:43 2011 +0100 xen/x86: only support >128 CPUs on x86_64 32 bit cannot cope with 256 cpus and hits: /* At least half the ioremap space should be available to us. */ BUILD_BUG_ON(IOREMAP_VIRT_START + (IOREMAP_MBYTES << 19) >= FIXADDR_START); Signed-off-by: Ian Campbell changeset: 23809:85b29185c911 user: Tim Deegan date: Thu Sep 01 09:39:25 2011 +0100 x86/mm: use defines for page sizes rather hardcoding them. Signed-off-by: Christoph Egger Acked-by: Tim Deegan Committed-by: Tim Deegan changeset: 23808:4a4882df5649 user: Stefano Stabellini date: Wed Aug 31 15:23:49 2011 +0100 xen: get_free_pirq: make sure that the returned pirq is allocated Signed-off-by: Stefano Stabellini changeset: 23807:2297b90a6a7b user: Stefano Stabellini date: Wed Aug 31 15:23:34 2011 +0100 xen: __hvm_pci_intx_assert should check for gsis remapped onto pirqs If the isa irq corresponding to a particular gsi is disabled while the gsi is enabled, __hvm_pci_intx_assert will always inject the gsi through the violapic, even if the gsi has been remapped onto a pirq. This patch makes sure that even in this case we inject the notification appropriately. Signed-off-by: Stefano Stabellini changeset: 23806:4226ea1785b5 user: Stefano Stabellini date: Wed Aug 31 15:23:12 2011 +0100 xen: fix hvm_domain_use_pirq's behavior hvm_domain_use_pirq should return true when the guest is using a certain pirq, no matter if the corresponding event channel is currently enabled or disabled. As an additional complication, qemu is going to request pirqs for passthrough devices even for Xen unaware HVM guests, so we need to wait for an event channel to be connected before considering the pirq of a passthrough device as "in use". Signed-off-by: Stefano Stabellini changeset: 23805:7048810180de user: Andrew Cooper date: Wed Aug 31 15:19:24 2011 +0100 IRQ: manually EOI migrating line interrupts When migrating IO-APIC line level interrupts between PCPUs, the migration code rewrites the IO-APIC entry to point to the new CPU/Vector before EOI'ing it. The EOI process says that EOI'ing the Local APIC will cause a broadcast with the vector number, which the IO-APIC must listen to to clear the IRR and Status bits. In the case of migrating, the IO-APIC has already been reprogrammed so the EOI broadcast with the old vector fails to match the new vector, leaving the IO-APIC with an outstanding vector, preventing any more use of that line interrupt. This causes a lockup especially when your root device is using PCI INTA (megaraid_sas driver *ehem*) However, the problem is mostly hidden because send_cleanup_vector() causes a cleanup of all moving vectors on the current PCPU in such a way which does not cause the problem, and if the problem has occured, the writes it makes to the IO-APIC clears the IRR and Status bits which unlocks the problem. This fix is distinctly a temporary hack, waiting on a cleanup of the irq code. It checks for the edge case where we have moved the irq, and manually EOI's the old vector with the IO-APIC which correctly clears the IRR and Status bits. Also, it protects the code which updates irq_cfg by disabling interrupts. Signed-off-by: Andrew Cooper changeset: 23804:42d76c68b2bf user: Kevin Tian date: Wed Aug 31 15:18:23 2011 +0100 x86: add irq count for IPIs such count is useful to assist decision make in cpuidle governor, while w/o this patch only device interrupts through do_IRQ is currently counted. Signed-off-by: Kevin Tian changeset: 23803:51983821efa4 user: Dietmar Hahn date: Wed Aug 31 15:17:45 2011 +0100 vpmu: Add processors Westmere E7-8837 and SandyBridge i5-2500 to the vpmu list Signed-off-by: Dietmar Hahn changeset: 23802:bb9b81008733 user: Laszlo Ersek date: Wed Aug 31 15:16:14 2011 +0100 x86: Increase the default NR_CPUS to 256 Changeset 21012:ef845a385014 bumped the default to 128 about one and a half years ago. Increase it now to 256, as systems with eg. 160 logical CPUs are becoming (have become) common. Signed-off-by: Laszlo Ersek changeset: 23801:d54cfae72cd1 user: Christoph Egger date: Wed Aug 31 15:15:41 2011 +0100 nestedsvm: VMRUN doesn't use nextrip VMRUN does not use nextrip. So remove pointless assignment. Signed-off-by: Christoph Egger changeset: 23800:72edc40e2942 user: Keir Fraser date: Wed Aug 31 15:14:49 2011 +0100 x86-64: Fix off-by-one error in __addr_ok() macro Signed-off-by: Laszlo Ersek Signed-off-by: Keir Fraser changeset: 23799:ac9aa65050e9 parent: 23798:469aa1fbd843 parent: 23797:2c687e70a343 user: Ian Jackson date: Tue Aug 30 11:46:58 2011 +0100 Merge ======================================== commit cd776ee9408ff127f934a707c1a339ee600bc127 Author: Ian Jackson Date: Tue Jun 28 13:50:53 2011 +0100 qemu-char.c: fix incorrect CONFIG_STUBDOM handling qemu-char.c:1123:7: warning: "CONFIG_STUBDOM" is not defined [-Wundef] Signed-off-by: Olaf Hering Acked-by: Ian Jackson _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel From xen-devel-bounces@lists.xensource.com Thu Sep 01 17:56:15 2011 Return-path: Envelope-to: www-data@lists.xensource.com Delivery-date: Thu, 01 Sep 2011 17:56:15 -0700 Received: from localhost ([127.0.0.1] helo=lists.colo.xensource.com) by lists.xensource.com with esmtp (Exim 4.43) id 1QzI3L-000492-89; Thu, 01 Sep 2011 17:56:15 -0700 Received: from mail21.messagelabs.com ([85.158.143.35]) by lists.xensource.com with esmtp (Exim 4.43) id 1QzI2X-0003vm-2y for xen-devel@lists.xensource.com; Thu, 01 Sep 2011 17:55:25 -0700 X-Env-Sender: jeremy@goop.org X-Msg-Ref: server-5.tower-21.messagelabs.com!1314924889!46569358!1 X-Originating-IP: [74.207.240.146] X-StarScan-Version: 6.3.6; banners=-,-,- X-VirusChecked: Checked Received: (qmail 18133 invoked from network); 2 Sep 2011 00:54:50 -0000 Received: from claw.goop.org (HELO claw.goop.org) (74.207.240.146) by server-5.tower-21.messagelabs.com with DHE-RSA-AES256-SHA encrypted SMTP; 2 Sep 2011 00:54:50 -0000 Received: from saboo.goop.org (unknown [IPv6:2001:470:1f05:899:a4d0:63ff:fe78:9062]) (Authenticated sender: smtp-saboo) by claw.goop.org (Postfix) with ESMTPSA id B5D5F92DC; Thu, 1 Sep 2011 17:55:18 -0700 (PDT) Received: by saboo.goop.org (Postfix, from userid 500) id B6E512060F; Thu, 1 Sep 2011 17:55:14 -0700 (PDT) From: Jeremy Fitzhardinge To: "H. Peter Anvin" Date: Thu, 1 Sep 2011 17:54:55 -0700 Message-Id: <860046dfb09b88e19854366ca1fc29b027b2fd27.1314922370.git.jeremy.fitzhardinge@citrix.com> X-Mailer: git-send-email 1.7.6 In-Reply-To: References: In-Reply-To: References: Cc: Marcelo Tosatti , Nick Piggin , KVM , Peter Zijlstra , the arch/x86 maintainers , Linux Kernel Mailing List , Andi Kleen , Avi Kivity , Jeremy Fitzhardinge , Ingo Molnar , Linus Torvalds , Xen Devel Subject: [Xen-devel] [PATCH 02/13] x86/ticketlock: collapse a layer of functions X-BeenThere: xen-devel@lists.xensource.com X-Mailman-Version: 2.1.5 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xensource.com Errors-To: xen-devel-bounces@lists.xensource.com From: Jeremy Fitzhardinge Now that the paravirtualization layer doesn't exist at the spinlock level any more, we can collapse the __ticket_ functions into the arch_ functions. Signed-off-by: Jeremy Fitzhardinge --- arch/x86/include/asm/spinlock.h | 35 +++++------------------------------ 1 files changed, 5 insertions(+), 30 deletions(-) diff --git a/arch/x86/include/asm/spinlock.h b/arch/x86/include/asm/spinlock.h index f5d9236..c1d9617 100644 --- a/arch/x86/include/asm/spinlock.h +++ b/arch/x86/include/asm/spinlock.h @@ -81,7 +81,7 @@ static __always_inline void __ticket_unlock_kick(struct arch_spinlock *lock, __t * save some instructions and make the code more elegant. There really isn't * much between them in performance though, especially as locks are out of line. */ -static __always_inline void __ticket_spin_lock(struct arch_spinlock *lock) +static __always_inline void arch_spin_lock(struct arch_spinlock *lock) { register struct __raw_tickets inc = { .tail = 1 }; @@ -101,7 +101,7 @@ static __always_inline void __ticket_spin_lock(struct arch_spinlock *lock) out: barrier(); /* make sure nothing creeps before the lock is taken */ } -static __always_inline int __ticket_spin_trylock(arch_spinlock_t *lock) +static __always_inline int arch_spin_trylock(arch_spinlock_t *lock) { arch_spinlock_t old, new; @@ -133,7 +133,7 @@ static __always_inline void __ticket_unlock_release(arch_spinlock_t *lock) } #endif -static __always_inline void __ticket_spin_unlock(arch_spinlock_t *lock) +static __always_inline void arch_spin_unlock(arch_spinlock_t *lock) { __ticket_t next = lock->tickets.head + 1; @@ -141,46 +141,21 @@ static __always_inline void __ticket_spin_unlock(arch_spinlock_t *lock) __ticket_unlock_kick(lock, next); } -static inline int __ticket_spin_is_locked(arch_spinlock_t *lock) +static inline int arch_spin_is_locked(arch_spinlock_t *lock) { struct __raw_tickets tmp = ACCESS_ONCE(lock->tickets); return !!(tmp.tail ^ tmp.head); } -static inline int __ticket_spin_is_contended(arch_spinlock_t *lock) +static inline int arch_spin_is_contended(arch_spinlock_t *lock) { struct __raw_tickets tmp = ACCESS_ONCE(lock->tickets); return ((tmp.tail - tmp.head) & TICKET_MASK) > 1; } - -static inline int arch_spin_is_locked(arch_spinlock_t *lock) -{ - return __ticket_spin_is_locked(lock); -} - -static inline int arch_spin_is_contended(arch_spinlock_t *lock) -{ - return __ticket_spin_is_contended(lock); -} #define arch_spin_is_contended arch_spin_is_contended -static __always_inline void arch_spin_lock(arch_spinlock_t *lock) -{ - __ticket_spin_lock(lock); -} - -static __always_inline int arch_spin_trylock(arch_spinlock_t *lock) -{ - return __ticket_spin_trylock(lock); -} - -static __always_inline void arch_spin_unlock(arch_spinlock_t *lock) -{ - __ticket_spin_unlock(lock); -} - static __always_inline void arch_spin_lock_flags(arch_spinlock_t *lock, unsigned long flags) { -- 1.7.6 _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel From xen-devel-bounces@lists.xensource.com Thu Sep 01 17:57:32 2011 Return-path: Envelope-to: www-data@lists.xensource.com Delivery-date: Thu, 01 Sep 2011 17:57:32 -0700 Received: from localhost ([127.0.0.1] helo=lists.colo.xensource.com) by lists.xensource.com with esmtp (Exim 4.43) id 1QzI4Z-0004XR-Vu; Thu, 01 Sep 2011 17:57:32 -0700 Received: from mail21.messagelabs.com ([85.158.143.35]) by lists.xensource.com with esmtp (Exim 4.43) id 1QzI2X-0003vl-2y for xen-devel@lists.xensource.com; Thu, 01 Sep 2011 17:55:25 -0700 X-Env-Sender: jeremy@goop.org X-Msg-Ref: server-8.tower-21.messagelabs.com!1314924905!57427129!1 X-Originating-IP: [74.207.240.146] X-StarScan-Version: 6.3.6; banners=-,-,- X-VirusChecked: Checked Received: (qmail 30376 invoked from network); 2 Sep 2011 00:55:07 -0000 Received: from claw.goop.org (HELO claw.goop.org) (74.207.240.146) by server-8.tower-21.messagelabs.com with DHE-RSA-AES256-SHA encrypted SMTP; 2 Sep 2011 00:55:07 -0000 Received: from saboo.goop.org (unknown [IPv6:2001:470:1f05:899:a4d0:63ff:fe78:9062]) (Authenticated sender: smtp-saboo) by claw.goop.org (Postfix) with ESMTPSA id BA0AF92DD; Thu, 1 Sep 2011 17:55:18 -0700 (PDT) Received: by saboo.goop.org (Postfix, from userid 500) id BB7552062E; Thu, 1 Sep 2011 17:55:14 -0700 (PDT) From: Jeremy Fitzhardinge To: "H. Peter Anvin" Date: Thu, 1 Sep 2011 17:54:56 -0700 Message-Id: <1f03a619d426bd8a97e167c6d34ebf8cafc1646e.1314922370.git.jeremy.fitzhardinge@citrix.com> X-Mailer: git-send-email 1.7.6 In-Reply-To: References: In-Reply-To: References: Cc: Marcelo Tosatti , Nick Piggin , KVM , Peter Zijlstra , the arch/x86 maintainers , Linux Kernel Mailing List , Andi Kleen , Avi Kivity , Jeremy Fitzhardinge , Ingo Molnar , Linus Torvalds , Xen Devel Subject: [Xen-devel] [PATCH 03/13] xen/pvticketlock: Xen implementation for PV ticket locks X-BeenThere: xen-devel@lists.xensource.com X-Mailman-Version: 2.1.5 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xensource.com Errors-To: xen-devel-bounces@lists.xensource.com From: Jeremy Fitzhardinge Replace the old Xen implementation of PV spinlocks with and implementation of xen_lock_spinning and xen_unlock_kick. xen_lock_spinning simply registers the cpu in its entry in lock_waiting, adds itself to the waiting_cpus set, and blocks on an event channel until the channel becomes pending. xen_unlock_kick searches the cpus in waiting_cpus looking for the one which next wants this lock with the next ticket, if any. If found, it kicks it by making its event channel pending, which wakes it up. Signed-off-by: Jeremy Fitzhardinge --- arch/x86/xen/spinlock.c | 281 ++++++----------------------------------------- 1 files changed, 36 insertions(+), 245 deletions(-) diff --git a/arch/x86/xen/spinlock.c b/arch/x86/xen/spinlock.c index 23af06a..c1bd84c 100644 --- a/arch/x86/xen/spinlock.c +++ b/arch/x86/xen/spinlock.c @@ -19,32 +19,21 @@ #ifdef CONFIG_XEN_DEBUG_FS static struct xen_spinlock_stats { - u64 taken; u32 taken_slow; - u32 taken_slow_nested; u32 taken_slow_pickup; u32 taken_slow_spurious; - u32 taken_slow_irqenable; - u64 released; u32 released_slow; u32 released_slow_kicked; #define HISTO_BUCKETS 30 - u32 histo_spin_total[HISTO_BUCKETS+1]; - u32 histo_spin_spinning[HISTO_BUCKETS+1]; u32 histo_spin_blocked[HISTO_BUCKETS+1]; - u64 time_total; - u64 time_spinning; u64 time_blocked; } spinlock_stats; static u8 zero_stats; -static unsigned lock_timeout = 1 << 10; -#define TIMEOUT lock_timeout - static inline void check_zero(void) { if (unlikely(zero_stats)) { @@ -73,22 +62,6 @@ static void __spin_time_accum(u64 delta, u32 *array) array[HISTO_BUCKETS]++; } -static inline void spin_time_accum_spinning(u64 start) -{ - u32 delta = xen_clocksource_read() - start; - - __spin_time_accum(delta, spinlock_stats.histo_spin_spinning); - spinlock_stats.time_spinning += delta; -} - -static inline void spin_time_accum_total(u64 start) -{ - u32 delta = xen_clocksource_read() - start; - - __spin_time_accum(delta, spinlock_stats.histo_spin_total); - spinlock_stats.time_total += delta; -} - static inline void spin_time_accum_blocked(u64 start) { u32 delta = xen_clocksource_read() - start; @@ -105,214 +78,76 @@ static inline u64 spin_time_start(void) return 0; } -static inline void spin_time_accum_total(u64 start) -{ -} -static inline void spin_time_accum_spinning(u64 start) -{ -} static inline void spin_time_accum_blocked(u64 start) { } #endif /* CONFIG_XEN_DEBUG_FS */ -struct xen_spinlock { - unsigned char lock; /* 0 -> free; 1 -> locked */ - unsigned short spinners; /* count of waiting cpus */ +struct xen_lock_waiting { + struct arch_spinlock *lock; + __ticket_t want; }; static DEFINE_PER_CPU(int, lock_kicker_irq) = -1; +static DEFINE_PER_CPU(struct xen_lock_waiting, lock_waiting); +static cpumask_t waiting_cpus; -#if 0 -static int xen_spin_is_locked(struct arch_spinlock *lock) -{ - struct xen_spinlock *xl = (struct xen_spinlock *)lock; - - return xl->lock != 0; -} - -static int xen_spin_is_contended(struct arch_spinlock *lock) -{ - struct xen_spinlock *xl = (struct xen_spinlock *)lock; - - /* Not strictly true; this is only the count of contended - lock-takers entering the slow path. */ - return xl->spinners != 0; -} - -static int xen_spin_trylock(struct arch_spinlock *lock) -{ - struct xen_spinlock *xl = (struct xen_spinlock *)lock; - u8 old = 1; - - asm("xchgb %b0,%1" - : "+q" (old), "+m" (xl->lock) : : "memory"); - - return old == 0; -} - -static DEFINE_PER_CPU(struct xen_spinlock *, lock_spinners); - -/* - * Mark a cpu as interested in a lock. Returns the CPU's previous - * lock of interest, in case we got preempted by an interrupt. - */ -static inline struct xen_spinlock *spinning_lock(struct xen_spinlock *xl) -{ - struct xen_spinlock *prev; - - prev = __this_cpu_read(lock_spinners); - __this_cpu_write(lock_spinners, xl); - - wmb(); /* set lock of interest before count */ - - asm(LOCK_PREFIX " incw %0" - : "+m" (xl->spinners) : : "memory"); - - return prev; -} - -/* - * Mark a cpu as no longer interested in a lock. Restores previous - * lock of interest (NULL for none). - */ -static inline void unspinning_lock(struct xen_spinlock *xl, struct xen_spinlock *prev) -{ - asm(LOCK_PREFIX " decw %0" - : "+m" (xl->spinners) : : "memory"); - wmb(); /* decrement count before restoring lock */ - __this_cpu_write(lock_spinners, prev); -} - -static noinline int xen_spin_lock_slow(struct arch_spinlock *lock, bool irq_enable) +static void xen_lock_spinning(struct arch_spinlock *lock, unsigned want) { - struct xen_spinlock *xl = (struct xen_spinlock *)lock; - struct xen_spinlock *prev; int irq = __this_cpu_read(lock_kicker_irq); - int ret; + struct xen_lock_waiting *w = &__get_cpu_var(lock_waiting); + int cpu = smp_processor_id(); u64 start; /* If kicker interrupts not initialized yet, just spin */ if (irq == -1) - return 0; + return; start = spin_time_start(); - /* announce we're spinning */ - prev = spinning_lock(xl); + w->want = want; + w->lock = lock; + + /* This uses set_bit, which atomic and therefore a barrier */ + cpumask_set_cpu(cpu, &waiting_cpus); ADD_STATS(taken_slow, 1); - ADD_STATS(taken_slow_nested, prev != NULL); - - do { - unsigned long flags; - - /* clear pending */ - xen_clear_irq_pending(irq); - - /* check again make sure it didn't become free while - we weren't looking */ - ret = xen_spin_trylock(lock); - if (ret) { - ADD_STATS(taken_slow_pickup, 1); - - /* - * If we interrupted another spinlock while it - * was blocking, make sure it doesn't block - * without rechecking the lock. - */ - if (prev != NULL) - xen_set_irq_pending(irq); - goto out; - } - flags = arch_local_save_flags(); - if (irq_enable) { - ADD_STATS(taken_slow_irqenable, 1); - raw_local_irq_enable(); - } + /* clear pending */ + xen_clear_irq_pending(irq); - /* - * Block until irq becomes pending. If we're - * interrupted at this point (after the trylock but - * before entering the block), then the nested lock - * handler guarantees that the irq will be left - * pending if there's any chance the lock became free; - * xen_poll_irq() returns immediately if the irq is - * pending. - */ - xen_poll_irq(irq); + /* Only check lock once pending cleared */ + barrier(); - raw_local_irq_restore(flags); + /* check again make sure it didn't become free while + we weren't looking */ + if (ACCESS_ONCE(lock->tickets.head) == want) { + ADD_STATS(taken_slow_pickup, 1); + goto out; + } - ADD_STATS(taken_slow_spurious, !xen_test_irq_pending(irq)); - } while (!xen_test_irq_pending(irq)); /* check for spurious wakeups */ + /* Block until irq becomes pending (or perhaps a spurious wakeup) */ + xen_poll_irq(irq); + ADD_STATS(taken_slow_spurious, !xen_test_irq_pending(irq)); kstat_incr_irqs_this_cpu(irq, irq_to_desc(irq)); out: - unspinning_lock(xl, prev); + cpumask_clear_cpu(cpu, &waiting_cpus); + w->lock = NULL; spin_time_accum_blocked(start); - - return ret; } -static inline void __xen_spin_lock(struct arch_spinlock *lock, bool irq_enable) -{ - struct xen_spinlock *xl = (struct xen_spinlock *)lock; - unsigned timeout; - u8 oldval; - u64 start_spin; - - ADD_STATS(taken, 1); - - start_spin = spin_time_start(); - - do { - u64 start_spin_fast = spin_time_start(); - - timeout = TIMEOUT; - - asm("1: xchgb %1,%0\n" - " testb %1,%1\n" - " jz 3f\n" - "2: rep;nop\n" - " cmpb $0,%0\n" - " je 1b\n" - " dec %2\n" - " jnz 2b\n" - "3:\n" - : "+m" (xl->lock), "=q" (oldval), "+r" (timeout) - : "1" (1) - : "memory"); - - spin_time_accum_spinning(start_spin_fast); - - } while (unlikely(oldval != 0 && - (TIMEOUT == ~0 || !xen_spin_lock_slow(lock, irq_enable)))); - - spin_time_accum_total(start_spin); -} - -static void xen_spin_lock(struct arch_spinlock *lock) -{ - __xen_spin_lock(lock, false); -} - -static void xen_spin_lock_flags(struct arch_spinlock *lock, unsigned long flags) -{ - __xen_spin_lock(lock, !raw_irqs_disabled_flags(flags)); -} - -static noinline void xen_spin_unlock_slow(struct xen_spinlock *xl) +static void xen_unlock_kick(struct arch_spinlock *lock, unsigned next) { int cpu; ADD_STATS(released_slow, 1); - for_each_online_cpu(cpu) { - /* XXX should mix up next cpu selection */ - if (per_cpu(lock_spinners, cpu) == xl) { + for_each_cpu(cpu, &waiting_cpus) { + const struct xen_lock_waiting *w = &per_cpu(lock_waiting, cpu); + + if (w->lock == lock && w->want == next) { ADD_STATS(released_slow_kicked, 1); xen_send_IPI_one(cpu, XEN_SPIN_UNLOCK_VECTOR); break; @@ -320,28 +155,6 @@ static noinline void xen_spin_unlock_slow(struct xen_spinlock *xl) } } -static void xen_spin_unlock(struct arch_spinlock *lock) -{ - struct xen_spinlock *xl = (struct xen_spinlock *)lock; - - ADD_STATS(released, 1); - - smp_wmb(); /* make sure no writes get moved after unlock */ - xl->lock = 0; /* release lock */ - - /* - * Make sure unlock happens before checking for waiting - * spinners. We need a strong barrier to enforce the - * write-read ordering to different memory locations, as the - * CPU makes no implied guarantees about their ordering. - */ - mb(); - - if (unlikely(xl->spinners)) - xen_spin_unlock_slow(xl); -} -#endif - static irqreturn_t dummy_handler(int irq, void *dev_id) { BUG(); @@ -376,14 +189,8 @@ void xen_uninit_lock_cpu(int cpu) void __init xen_init_spinlocks(void) { -#if 0 - pv_lock_ops.spin_is_locked = xen_spin_is_locked; - pv_lock_ops.spin_is_contended = xen_spin_is_contended; - pv_lock_ops.spin_lock = xen_spin_lock; - pv_lock_ops.spin_lock_flags = xen_spin_lock_flags; - pv_lock_ops.spin_trylock = xen_spin_trylock; - pv_lock_ops.spin_unlock = xen_spin_unlock; -#endif + pv_lock_ops.lock_spinning = xen_lock_spinning; + pv_lock_ops.unlock_kick = xen_unlock_kick; } #ifdef CONFIG_XEN_DEBUG_FS @@ -401,37 +208,21 @@ static int __init xen_spinlock_debugfs(void) debugfs_create_u8("zero_stats", 0644, d_spin_debug, &zero_stats); - debugfs_create_u32("timeout", 0644, d_spin_debug, &lock_timeout); - - debugfs_create_u64("taken", 0444, d_spin_debug, &spinlock_stats.taken); debugfs_create_u32("taken_slow", 0444, d_spin_debug, &spinlock_stats.taken_slow); - debugfs_create_u32("taken_slow_nested", 0444, d_spin_debug, - &spinlock_stats.taken_slow_nested); debugfs_create_u32("taken_slow_pickup", 0444, d_spin_debug, &spinlock_stats.taken_slow_pickup); debugfs_create_u32("taken_slow_spurious", 0444, d_spin_debug, &spinlock_stats.taken_slow_spurious); - debugfs_create_u32("taken_slow_irqenable", 0444, d_spin_debug, - &spinlock_stats.taken_slow_irqenable); - debugfs_create_u64("released", 0444, d_spin_debug, &spinlock_stats.released); debugfs_create_u32("released_slow", 0444, d_spin_debug, &spinlock_stats.released_slow); debugfs_create_u32("released_slow_kicked", 0444, d_spin_debug, &spinlock_stats.released_slow_kicked); - debugfs_create_u64("time_spinning", 0444, d_spin_debug, - &spinlock_stats.time_spinning); debugfs_create_u64("time_blocked", 0444, d_spin_debug, &spinlock_stats.time_blocked); - debugfs_create_u64("time_total", 0444, d_spin_debug, - &spinlock_stats.time_total); - xen_debugfs_create_u32_array("histo_total", 0444, d_spin_debug, - spinlock_stats.histo_spin_total, HISTO_BUCKETS + 1); - xen_debugfs_create_u32_array("histo_spinning", 0444, d_spin_debug, - spinlock_stats.histo_spin_spinning, HISTO_BUCKETS + 1); xen_debugfs_create_u32_array("histo_blocked", 0444, d_spin_debug, spinlock_stats.histo_spin_blocked, HISTO_BUCKETS + 1); -- 1.7.6 _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel From xen-devel-bounces@lists.xensource.com Thu Sep 01 18:01:59 2011 Return-path: Envelope-to: www-data@lists.xensource.com Delivery-date: Thu, 01 Sep 2011 18:01:59 -0700 Received: from localhost ([127.0.0.1] helo=lists.colo.xensource.com) by lists.xensource.com with esmtp (Exim 4.43) id 1QzI8s-00052E-7B; Thu, 01 Sep 2011 18:01:58 -0700 Received: from mail27.messagelabs.com ([193.109.254.147]) by lists.xensource.com with esmtp (Exim 4.43) id 1QzI2a-0003vw-PE for xen-devel@lists.xensource.com; Thu, 01 Sep 2011 17:55:29 -0700 X-Env-Sender: jeremy@goop.org X-Msg-Ref: server-11.tower-27.messagelabs.com!1314924917!35718124!1 X-Originating-IP: [74.207.240.146] X-StarScan-Version: 6.3.6; banners=-,-,- X-VirusChecked: Checked Received: (qmail 958 invoked from network); 2 Sep 2011 00:55:19 -0000 Received: from claw.goop.org (HELO claw.goop.org) (74.207.240.146) by server-11.tower-27.messagelabs.com with DHE-RSA-AES256-SHA encrypted SMTP; 2 Sep 2011 00:55:19 -0000 Received: from saboo.goop.org (unknown [IPv6:2001:470:1f05:899:a4d0:63ff:fe78:9062]) (Authenticated sender: smtp-saboo) by claw.goop.org (Postfix) with ESMTPSA id C189092DE; Thu, 1 Sep 2011 17:55:18 -0700 (PDT) Received: by saboo.goop.org (Postfix, from userid 500) id BFFBC2064F; Thu, 1 Sep 2011 17:55:14 -0700 (PDT) From: Jeremy Fitzhardinge To: "H. Peter Anvin" Date: Thu, 1 Sep 2011 17:54:57 -0700 Message-Id: <3dbb724d24eddcda0e4ff708f7a91da0023bc6c2.1314922370.git.jeremy.fitzhardinge@citrix.com> X-Mailer: git-send-email 1.7.6 In-Reply-To: References: In-Reply-To: References: Cc: Marcelo Tosatti , Nick Piggin , KVM , Peter Zijlstra , the arch/x86 maintainers , Linux Kernel Mailing List , Andi Kleen , Avi Kivity , Jeremy Fitzhardinge , Ingo Molnar , Linus Torvalds , Xen Devel Subject: [Xen-devel] [PATCH 04/13] x86/pvticketlock: use callee-save for lock_spinning X-BeenThere: xen-devel@lists.xensource.com X-Mailman-Version: 2.1.5 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xensource.com Errors-To: xen-devel-bounces@lists.xensource.com From: Jeremy Fitzhardinge Although the lock_spinning calls in the spinlock code are on the uncommon path, their presence can cause the compiler to generate many more register save/restores in the function pre/postamble, which is in the fast path. To avoid this, convert it to using the pvops callee-save calling convention, which defers all the save/restores until the actual function is called, keeping the fastpath clean. Signed-off-by: Jeremy Fitzhardinge --- arch/x86/include/asm/paravirt.h | 2 +- arch/x86/include/asm/paravirt_types.h | 2 +- arch/x86/kernel/paravirt-spinlocks.c | 2 +- arch/x86/xen/spinlock.c | 3 ++- 4 files changed, 5 insertions(+), 4 deletions(-) diff --git a/arch/x86/include/asm/paravirt.h b/arch/x86/include/asm/paravirt.h index d88a813..622f3d6 100644 --- a/arch/x86/include/asm/paravirt.h +++ b/arch/x86/include/asm/paravirt.h @@ -743,7 +743,7 @@ static inline void __set_fixmap(unsigned /* enum fixed_addresses */ idx, static inline void __ticket_lock_spinning(struct arch_spinlock *lock, unsigned ticket) { - PVOP_VCALL2(pv_lock_ops.lock_spinning, lock, ticket); + PVOP_VCALLEE2(pv_lock_ops.lock_spinning, lock, ticket); } static inline void ____ticket_unlock_kick(struct arch_spinlock *lock, unsigned ticket) diff --git a/arch/x86/include/asm/paravirt_types.h b/arch/x86/include/asm/paravirt_types.h index e9101c3..97faa3b 100644 --- a/arch/x86/include/asm/paravirt_types.h +++ b/arch/x86/include/asm/paravirt_types.h @@ -321,7 +321,7 @@ struct pv_mmu_ops { struct arch_spinlock; struct pv_lock_ops { - void (*lock_spinning)(struct arch_spinlock *lock, unsigned ticket); + struct paravirt_callee_save lock_spinning; void (*unlock_kick)(struct arch_spinlock *lock, unsigned ticket); }; diff --git a/arch/x86/kernel/paravirt-spinlocks.c b/arch/x86/kernel/paravirt-spinlocks.c index c2e010e..4251c1d 100644 --- a/arch/x86/kernel/paravirt-spinlocks.c +++ b/arch/x86/kernel/paravirt-spinlocks.c @@ -9,7 +9,7 @@ struct pv_lock_ops pv_lock_ops = { #ifdef CONFIG_SMP - .lock_spinning = paravirt_nop, + .lock_spinning = __PV_IS_CALLEE_SAVE(paravirt_nop), .unlock_kick = paravirt_nop, #endif }; diff --git a/arch/x86/xen/spinlock.c b/arch/x86/xen/spinlock.c index c1bd84c..b133865 100644 --- a/arch/x86/xen/spinlock.c +++ b/arch/x86/xen/spinlock.c @@ -137,6 +137,7 @@ out: w->lock = NULL; spin_time_accum_blocked(start); } +PV_CALLEE_SAVE_REGS_THUNK(xen_lock_spinning); static void xen_unlock_kick(struct arch_spinlock *lock, unsigned next) { @@ -189,7 +190,7 @@ void xen_uninit_lock_cpu(int cpu) void __init xen_init_spinlocks(void) { - pv_lock_ops.lock_spinning = xen_lock_spinning; + pv_lock_ops.lock_spinning = PV_CALLEE_SAVE(xen_lock_spinning); pv_lock_ops.unlock_kick = xen_unlock_kick; } -- 1.7.6 _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel From xen-devel-bounces@lists.xensource.com Thu Sep 01 18:04:53 2011 Return-path: Envelope-to: www-data@lists.xensource.com Delivery-date: Thu, 01 Sep 2011 18:04:53 -0700 Received: from localhost ([127.0.0.1] helo=lists.colo.xensource.com) by lists.xensource.com with esmtp (Exim 4.43) id 1QzIBg-0005Qp-R5; Thu, 01 Sep 2011 18:04:52 -0700 Received: from mail182.messagelabs.com ([85.158.139.83]) by lists.xensource.com with esmtp (Exim 4.43) id 1QzI2c-0003w1-Cy for xen-devel@lists.xensource.com; Thu, 01 Sep 2011 17:55:31 -0700 X-Env-Sender: jeremy@goop.org X-Msg-Ref: server-10.tower-182.messagelabs.com!1314924925!16729758!1 X-Originating-IP: [74.207.240.146] X-StarScan-Version: 6.3.6; banners=-,-,- X-VirusChecked: Checked Received: (qmail 27619 invoked from network); 2 Sep 2011 00:55:27 -0000 Received: from claw.goop.org (HELO claw.goop.org) (74.207.240.146) by server-10.tower-182.messagelabs.com with DHE-RSA-AES256-SHA encrypted SMTP; 2 Sep 2011 00:55:27 -0000 Received: from saboo.goop.org (unknown [IPv6:2001:470:1f05:899:a4d0:63ff:fe78:9062]) (Authenticated sender: smtp-saboo) by claw.goop.org (Postfix) with ESMTPSA id C4BE792E0; Thu, 1 Sep 2011 17:55:18 -0700 (PDT) Received: by saboo.goop.org (Postfix, from userid 500) id B16332034D; Thu, 1 Sep 2011 17:55:14 -0700 (PDT) From: Jeremy Fitzhardinge To: "H. Peter Anvin" Date: Thu, 1 Sep 2011 17:54:54 -0700 Message-Id: X-Mailer: git-send-email 1.7.6 In-Reply-To: References: In-Reply-To: References: Cc: Marcelo Tosatti , Nick Piggin , KVM , Peter Zijlstra , the arch/x86 maintainers , Linux Kernel Mailing List , Andi Kleen , Avi Kivity , Jeremy Fitzhardinge , Ingo Molnar , Linus Torvalds , Xen Devel Subject: [Xen-devel] [PATCH 01/13] x86/spinlocks: replace pv spinlocks with pv ticketlocks X-BeenThere: xen-devel@lists.xensource.com X-Mailman-Version: 2.1.5 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xensource.com Errors-To: xen-devel-bounces@lists.xensource.com From: Jeremy Fitzhardinge Rather than outright replacing the entire spinlock implementation in order to paravirtualize it, keep the ticket lock implementation but add a couple of pvops hooks on the slow patch (long spin on lock, unlocking a contended lock). Ticket locks have a number of nice properties, but they also have some surprising behaviours in virtual environments. They enforce a strict FIFO ordering on cpus trying to take a lock; however, if the hypervisor scheduler does not schedule the cpus in the correct order, the system can waste a huge amount of time spinning until the next cpu can take the lock. (See Thomas Friebel's talk "Prevent Guests from Spinning Around" http://www.xen.org/files/xensummitboston08/LHP.pdf for more details.) To address this, we add two hooks: - __ticket_spin_lock which is called after the cpu has been spinning on the lock for a significant number of iterations but has failed to take the lock (presumably because the cpu holding the lock has been descheduled). The lock_spinning pvop is expected to block the cpu until it has been kicked by the current lock holder. - __ticket_spin_unlock, which on releasing a contended lock (there are more cpus with tail tickets), it looks to see if the next cpu is blocked and wakes it if so. When compiled with CONFIG_PARAVIRT_SPINLOCKS disabled, a set of stub functions causes all the extra code to go away. Signed-off-by: Jeremy Fitzhardinge --- arch/x86/include/asm/paravirt.h | 30 ++-------------- arch/x86/include/asm/paravirt_types.h | 8 +--- arch/x86/include/asm/spinlock.h | 59 ++++++++++++++++++++++++++------- arch/x86/kernel/paravirt-spinlocks.c | 15 +------- arch/x86/xen/spinlock.c | 7 +++- 5 files changed, 61 insertions(+), 58 deletions(-) diff --git a/arch/x86/include/asm/paravirt.h b/arch/x86/include/asm/paravirt.h index ebbc4d8..d88a813 100644 --- a/arch/x86/include/asm/paravirt.h +++ b/arch/x86/include/asm/paravirt.h @@ -741,36 +741,14 @@ static inline void __set_fixmap(unsigned /* enum fixed_addresses */ idx, #if defined(CONFIG_SMP) && defined(CONFIG_PARAVIRT_SPINLOCKS) -static inline int arch_spin_is_locked(struct arch_spinlock *lock) +static inline void __ticket_lock_spinning(struct arch_spinlock *lock, unsigned ticket) { - return PVOP_CALL1(int, pv_lock_ops.spin_is_locked, lock); + PVOP_VCALL2(pv_lock_ops.lock_spinning, lock, ticket); } -static inline int arch_spin_is_contended(struct arch_spinlock *lock) +static inline void ____ticket_unlock_kick(struct arch_spinlock *lock, unsigned ticket) { - return PVOP_CALL1(int, pv_lock_ops.spin_is_contended, lock); -} -#define arch_spin_is_contended arch_spin_is_contended - -static __always_inline void arch_spin_lock(struct arch_spinlock *lock) -{ - PVOP_VCALL1(pv_lock_ops.spin_lock, lock); -} - -static __always_inline void arch_spin_lock_flags(struct arch_spinlock *lock, - unsigned long flags) -{ - PVOP_VCALL2(pv_lock_ops.spin_lock_flags, lock, flags); -} - -static __always_inline int arch_spin_trylock(struct arch_spinlock *lock) -{ - return PVOP_CALL1(int, pv_lock_ops.spin_trylock, lock); -} - -static __always_inline void arch_spin_unlock(struct arch_spinlock *lock) -{ - PVOP_VCALL1(pv_lock_ops.spin_unlock, lock); + PVOP_VCALL2(pv_lock_ops.unlock_kick, lock, ticket); } #endif diff --git a/arch/x86/include/asm/paravirt_types.h b/arch/x86/include/asm/paravirt_types.h index 8288509..e9101c3 100644 --- a/arch/x86/include/asm/paravirt_types.h +++ b/arch/x86/include/asm/paravirt_types.h @@ -321,12 +321,8 @@ struct pv_mmu_ops { struct arch_spinlock; struct pv_lock_ops { - int (*spin_is_locked)(struct arch_spinlock *lock); - int (*spin_is_contended)(struct arch_spinlock *lock); - void (*spin_lock)(struct arch_spinlock *lock); - void (*spin_lock_flags)(struct arch_spinlock *lock, unsigned long flags); - int (*spin_trylock)(struct arch_spinlock *lock); - void (*spin_unlock)(struct arch_spinlock *lock); + void (*lock_spinning)(struct arch_spinlock *lock, unsigned ticket); + void (*unlock_kick)(struct arch_spinlock *lock, unsigned ticket); }; /* This contains all the paravirt structures: we get a convenient diff --git a/arch/x86/include/asm/spinlock.h b/arch/x86/include/asm/spinlock.h index 3549e6c..f5d9236 100644 --- a/arch/x86/include/asm/spinlock.h +++ b/arch/x86/include/asm/spinlock.h @@ -38,6 +38,32 @@ # define UNLOCK_LOCK_PREFIX #endif +/* How long a lock should spin before we consider blocking */ +#define SPIN_THRESHOLD (1 << 11) + +#ifndef CONFIG_PARAVIRT_SPINLOCKS + +static __always_inline void __ticket_lock_spinning(struct arch_spinlock *lock, unsigned ticket) +{ +} + +static __always_inline void ____ticket_unlock_kick(struct arch_spinlock *lock, unsigned ticket) +{ +} + +#endif /* CONFIG_PARAVIRT_SPINLOCKS */ + + +/* + * If a spinlock has someone waiting on it, then kick the appropriate + * waiting cpu. + */ +static __always_inline void __ticket_unlock_kick(struct arch_spinlock *lock, __ticket_t next) +{ + if (unlikely(lock->tickets.tail != next)) + ____ticket_unlock_kick(lock, next); +} + /* * Ticket locks are conceptually two parts, one indicating the current head of * the queue, and the other indicating the current tail. The lock is acquired @@ -55,19 +81,24 @@ * save some instructions and make the code more elegant. There really isn't * much between them in performance though, especially as locks are out of line. */ -static __always_inline void __ticket_spin_lock(arch_spinlock_t *lock) +static __always_inline void __ticket_spin_lock(struct arch_spinlock *lock) { register struct __raw_tickets inc = { .tail = 1 }; inc = xadd(&lock->tickets, inc); for (;;) { - if (inc.head == inc.tail) - break; - cpu_relax(); - inc.head = ACCESS_ONCE(lock->tickets.head); + unsigned count = SPIN_THRESHOLD; + + do { + if (inc.head == inc.tail) + goto out; + cpu_relax(); + inc.head = ACCESS_ONCE(lock->tickets.head); + } while (--count); + __ticket_lock_spinning(lock, inc.tail); } - barrier(); /* make sure nothing creeps before the lock is taken */ +out: barrier(); /* make sure nothing creeps before the lock is taken */ } static __always_inline int __ticket_spin_trylock(arch_spinlock_t *lock) @@ -85,7 +116,7 @@ static __always_inline int __ticket_spin_trylock(arch_spinlock_t *lock) } #if (NR_CPUS < 256) -static __always_inline void __ticket_spin_unlock(arch_spinlock_t *lock) +static __always_inline void __ticket_unlock_release(arch_spinlock_t *lock) { asm volatile(UNLOCK_LOCK_PREFIX "incb %0" : "+m" (lock->head_tail) @@ -93,7 +124,7 @@ static __always_inline void __ticket_spin_unlock(arch_spinlock_t *lock) : "memory", "cc"); } #else -static __always_inline void __ticket_spin_unlock(arch_spinlock_t *lock) +static __always_inline void __ticket_unlock_release(arch_spinlock_t *lock) { asm volatile(UNLOCK_LOCK_PREFIX "incw %0" : "+m" (lock->head_tail) @@ -102,6 +133,14 @@ static __always_inline void __ticket_spin_unlock(arch_spinlock_t *lock) } #endif +static __always_inline void __ticket_spin_unlock(arch_spinlock_t *lock) +{ + __ticket_t next = lock->tickets.head + 1; + + __ticket_unlock_release(lock); + __ticket_unlock_kick(lock, next); +} + static inline int __ticket_spin_is_locked(arch_spinlock_t *lock) { struct __raw_tickets tmp = ACCESS_ONCE(lock->tickets); @@ -116,8 +155,6 @@ static inline int __ticket_spin_is_contended(arch_spinlock_t *lock) return ((tmp.tail - tmp.head) & TICKET_MASK) > 1; } -#ifndef CONFIG_PARAVIRT_SPINLOCKS - static inline int arch_spin_is_locked(arch_spinlock_t *lock) { return __ticket_spin_is_locked(lock); @@ -150,8 +187,6 @@ static __always_inline void arch_spin_lock_flags(arch_spinlock_t *lock, arch_spin_lock(lock); } -#endif /* CONFIG_PARAVIRT_SPINLOCKS */ - static inline void arch_spin_unlock_wait(arch_spinlock_t *lock) { while (arch_spin_is_locked(lock)) diff --git a/arch/x86/kernel/paravirt-spinlocks.c b/arch/x86/kernel/paravirt-spinlocks.c index 676b8c7..c2e010e 100644 --- a/arch/x86/kernel/paravirt-spinlocks.c +++ b/arch/x86/kernel/paravirt-spinlocks.c @@ -7,21 +7,10 @@ #include -static inline void -default_spin_lock_flags(arch_spinlock_t *lock, unsigned long flags) -{ - arch_spin_lock(lock); -} - struct pv_lock_ops pv_lock_ops = { #ifdef CONFIG_SMP - .spin_is_locked = __ticket_spin_is_locked, - .spin_is_contended = __ticket_spin_is_contended, - - .spin_lock = __ticket_spin_lock, - .spin_lock_flags = default_spin_lock_flags, - .spin_trylock = __ticket_spin_trylock, - .spin_unlock = __ticket_spin_unlock, + .lock_spinning = paravirt_nop, + .unlock_kick = paravirt_nop, #endif }; EXPORT_SYMBOL(pv_lock_ops); diff --git a/arch/x86/xen/spinlock.c b/arch/x86/xen/spinlock.c index cc9b1e1..23af06a 100644 --- a/arch/x86/xen/spinlock.c +++ b/arch/x86/xen/spinlock.c @@ -121,6 +121,9 @@ struct xen_spinlock { unsigned short spinners; /* count of waiting cpus */ }; +static DEFINE_PER_CPU(int, lock_kicker_irq) = -1; + +#if 0 static int xen_spin_is_locked(struct arch_spinlock *lock) { struct xen_spinlock *xl = (struct xen_spinlock *)lock; @@ -148,7 +151,6 @@ static int xen_spin_trylock(struct arch_spinlock *lock) return old == 0; } -static DEFINE_PER_CPU(int, lock_kicker_irq) = -1; static DEFINE_PER_CPU(struct xen_spinlock *, lock_spinners); /* @@ -338,6 +340,7 @@ static void xen_spin_unlock(struct arch_spinlock *lock) if (unlikely(xl->spinners)) xen_spin_unlock_slow(xl); } +#endif static irqreturn_t dummy_handler(int irq, void *dev_id) { @@ -373,12 +376,14 @@ void xen_uninit_lock_cpu(int cpu) void __init xen_init_spinlocks(void) { +#if 0 pv_lock_ops.spin_is_locked = xen_spin_is_locked; pv_lock_ops.spin_is_contended = xen_spin_is_contended; pv_lock_ops.spin_lock = xen_spin_lock; pv_lock_ops.spin_lock_flags = xen_spin_lock_flags; pv_lock_ops.spin_trylock = xen_spin_trylock; pv_lock_ops.spin_unlock = xen_spin_unlock; +#endif } #ifdef CONFIG_XEN_DEBUG_FS -- 1.7.6 _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel From xen-devel-bounces@lists.xensource.com Thu Sep 01 18:06:52 2011 Return-path: Envelope-to: www-data@lists.xensource.com Delivery-date: Thu, 01 Sep 2011 18:06:52 -0700 Received: from localhost ([127.0.0.1] helo=lists.colo.xensource.com) by lists.xensource.com with esmtp (Exim 4.43) id 1QzIDc-0005oo-9g; Thu, 01 Sep 2011 18:06:52 -0700 Received: from mail21.messagelabs.com ([85.158.143.35]) by lists.xensource.com with esmtp (Exim 4.43) id 1QzI2d-0003wd-Pz for xen-devel@lists.xensource.com; Thu, 01 Sep 2011 17:55:32 -0700 X-Env-Sender: jeremy@goop.org X-Msg-Ref: server-5.tower-21.messagelabs.com!1314924895!46569364!1 X-Originating-IP: [74.207.240.146] X-StarScan-Version: 6.3.6; banners=-,-,- X-VirusChecked: Checked Received: (qmail 18414 invoked from network); 2 Sep 2011 00:54:57 -0000 Received: from claw.goop.org (HELO claw.goop.org) (74.207.240.146) by server-5.tower-21.messagelabs.com with DHE-RSA-AES256-SHA encrypted SMTP; 2 Sep 2011 00:54:57 -0000 Received: from saboo.goop.org (unknown [IPv6:2001:470:1f05:899:a4d0:63ff:fe78:9062]) (Authenticated sender: smtp-saboo) by claw.goop.org (Postfix) with ESMTPSA id 3985D92E2; Thu, 1 Sep 2011 17:55:21 -0700 (PDT) Received: by saboo.goop.org (Postfix, from userid 500) id E8EA8208C4; Thu, 1 Sep 2011 17:55:14 -0700 (PDT) From: Jeremy Fitzhardinge To: "H. Peter Anvin" Date: Thu, 1 Sep 2011 17:55:04 -0700 Message-Id: <8cd2c77886e2d3fcad8258aa62509b3b2fae5545.1314922370.git.jeremy.fitzhardinge@citrix.com> X-Mailer: git-send-email 1.7.6 In-Reply-To: References: In-Reply-To: References: Cc: Marcelo Tosatti , Nick Piggin , KVM , Peter Zijlstra , the arch/x86 maintainers , Linux Kernel Mailing List , Srivatsa Vaddagiri , Andi Kleen , Avi Kivity , Jeremy Fitzhardinge , Ingo Molnar , Linus Torvalds , Xen Devel Subject: [Xen-devel] [PATCH 11/13] x86/ticketlock: only do kick after doing unlock X-BeenThere: xen-devel@lists.xensource.com X-Mailman-Version: 2.1.5 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xensource.com Errors-To: xen-devel-bounces@lists.xensource.com From: Srivatsa Vaddagiri We must release the lock before checking to see if the lock is in slowpath or else there's a potential race where the lock enters the slow path after the unlocker has checked the slowpath flag, but before it has actually unlocked. Signed-off-by: Srivatsa Vaddagiri Signed-off-by: Jeremy Fitzhardinge --- arch/x86/include/asm/spinlock.h | 7 +++---- arch/x86/kernel/paravirt-spinlocks.c | 23 ++++++----------------- 2 files changed, 9 insertions(+), 21 deletions(-) diff --git a/arch/x86/include/asm/spinlock.h b/arch/x86/include/asm/spinlock.h index 365d787..bf6dff4 100644 --- a/arch/x86/include/asm/spinlock.h +++ b/arch/x86/include/asm/spinlock.h @@ -43,7 +43,7 @@ /* Only defined when CONFIG_PARAVIRT_SPINLOCKS defined, but may as * well leave the prototype always visible. */ -extern void __ticket_unlock_release_slowpath(struct arch_spinlock *lock); +extern void __ticket_unlock_slowpath(struct arch_spinlock *lock); #ifdef CONFIG_PARAVIRT_SPINLOCKS @@ -154,10 +154,9 @@ static __always_inline void __ticket_unlock_release(arch_spinlock_t *lock) static __always_inline void arch_spin_unlock(arch_spinlock_t *lock) { + __ticket_unlock_release(lock); if (unlikely(__ticket_in_slowpath(lock))) - __ticket_unlock_release_slowpath(lock); - else - __ticket_unlock_release(lock); + __ticket_unlock_slowpath(lock); } static inline int arch_spin_is_locked(arch_spinlock_t *lock) diff --git a/arch/x86/kernel/paravirt-spinlocks.c b/arch/x86/kernel/paravirt-spinlocks.c index 71b8557..674718f 100644 --- a/arch/x86/kernel/paravirt-spinlocks.c +++ b/arch/x86/kernel/paravirt-spinlocks.c @@ -22,32 +22,21 @@ EXPORT_SYMBOL(pv_lock_ops); * bits. However, we need to be careful about this because someone * may just be entering as we leave, and enter the slowpath. */ -void __ticket_unlock_release_slowpath(struct arch_spinlock *lock) +void __ticket_unlock_slowpath(struct arch_spinlock *lock) { struct arch_spinlock old, new; BUILD_BUG_ON(((__ticket_t)NR_CPUS) != NR_CPUS); old = ACCESS_ONCE(*lock); - new = old; - new.tickets.head += TICKET_LOCK_INC; /* Clear the slowpath flag */ new.tickets.tail &= ~TICKET_SLOWPATH_FLAG; + if (new.tickets.head == new.tickets.tail) + cmpxchg(&lock->head_tail, old.head_tail, new.head_tail); - /* - * If there's currently people waiting or someone snuck in - * since we read the lock above, then do a normal unlock and - * kick. If we managed to unlock with no queued waiters, then - * we can clear the slowpath flag. - */ - if (new.tickets.head != new.tickets.tail || - cmpxchg(&lock->head_tail, - old.head_tail, new.head_tail) != old.head_tail) { - /* still people waiting */ - __ticket_unlock_release(lock); - __ticket_unlock_kick(lock, new.tickets.head); - } + /* Wake up an appropriate waiter */ + __ticket_unlock_kick(lock, new.tickets.head); } -EXPORT_SYMBOL(__ticket_unlock_release_slowpath); +EXPORT_SYMBOL(__ticket_unlock_slowpath); -- 1.7.6 _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel From xen-devel-bounces@lists.xensource.com Thu Sep 01 18:09:03 2011 Return-path: Envelope-to: www-data@lists.xensource.com Delivery-date: Thu, 01 Sep 2011 18:09:03 -0700 Received: from localhost ([127.0.0.1] helo=lists.colo.xensource.com) by lists.xensource.com with esmtp (Exim 4.43) id 1QzIFi-0006Ih-VG; Thu, 01 Sep 2011 18:09:03 -0700 Received: from mail27.messagelabs.com ([193.109.254.147]) by lists.xensource.com with esmtp (Exim 4.43) id 1QzI2e-0003wn-FZ for xen-devel@lists.xensource.com; Thu, 01 Sep 2011 17:55:33 -0700 X-Env-Sender: jeremy@goop.org X-Msg-Ref: server-13.tower-27.messagelabs.com!1314924917!38338956!1 X-Originating-IP: [74.207.240.146] X-StarScan-Version: 6.3.6; banners=-,-,- X-VirusChecked: Checked Received: (qmail 16333 invoked from network); 2 Sep 2011 00:55:19 -0000 Received: from claw.goop.org (HELO claw.goop.org) (74.207.240.146) by server-13.tower-27.messagelabs.com with DHE-RSA-AES256-SHA encrypted SMTP; 2 Sep 2011 00:55:19 -0000 Received: from saboo.goop.org (unknown [IPv6:2001:470:1f05:899:a4d0:63ff:fe78:9062]) (Authenticated sender: smtp-saboo) by claw.goop.org (Postfix) with ESMTPSA id 24F9592E1; Thu, 1 Sep 2011 17:55:21 -0700 (PDT) Received: by saboo.goop.org (Postfix, from userid 500) id ED22B208CC; Thu, 1 Sep 2011 17:55:14 -0700 (PDT) From: Jeremy Fitzhardinge To: "H. Peter Anvin" Date: Thu, 1 Sep 2011 17:55:05 -0700 Message-Id: <59ac6dc9120d440f45fa997910b5d396461c60f5.1314922370.git.jeremy.fitzhardinge@citrix.com> X-Mailer: git-send-email 1.7.6 In-Reply-To: References: In-Reply-To: References: Cc: Marcelo Tosatti , Nick Piggin , KVM , Peter Zijlstra , the arch/x86 maintainers , Linux Kernel Mailing List , Andi Kleen , Avi Kivity , Jeremy Fitzhardinge , Ingo Molnar , Linus Torvalds , Xen Devel Subject: [Xen-devel] [PATCH 12/13] x86/pvticketlock: make sure unlock_kick pvop call is inlined X-BeenThere: xen-devel@lists.xensource.com X-Mailman-Version: 2.1.5 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xensource.com Errors-To: xen-devel-bounces@lists.xensource.com From: Jeremy Fitzhardinge Otherwise the generated code for raw_spin_lock will look awful. Signed-off-by: Jeremy Fitzhardinge --- arch/x86/include/asm/paravirt.h | 4 ++-- 1 files changed, 2 insertions(+), 2 deletions(-) diff --git a/arch/x86/include/asm/paravirt.h b/arch/x86/include/asm/paravirt.h index b89699a..a6f2651 100644 --- a/arch/x86/include/asm/paravirt.h +++ b/arch/x86/include/asm/paravirt.h @@ -741,12 +741,12 @@ static inline void __set_fixmap(unsigned /* enum fixed_addresses */ idx, #if defined(CONFIG_SMP) && defined(CONFIG_PARAVIRT_SPINLOCKS) -static inline void __ticket_lock_spinning(struct arch_spinlock *lock, unsigned ticket) +static __always_inline void __ticket_lock_spinning(struct arch_spinlock *lock, unsigned ticket) { PVOP_VCALLEE2(pv_lock_ops.lock_spinning, lock, ticket); } -static inline void __ticket_unlock_kick(struct arch_spinlock *lock, unsigned ticket) +static __always_inline void __ticket_unlock_kick(struct arch_spinlock *lock, unsigned ticket) { PVOP_VCALL2(pv_lock_ops.unlock_kick, lock, ticket); } -- 1.7.6 _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel From xen-devel-bounces@lists.xensource.com Thu Sep 01 18:09:51 2011 Return-path: Envelope-to: www-data@lists.xensource.com Delivery-date: Thu, 01 Sep 2011 18:09:51 -0700 Received: from localhost ([127.0.0.1] helo=lists.colo.xensource.com) by lists.xensource.com with esmtp (Exim 4.43) id 1QzIGV-0006fK-EC; Thu, 01 Sep 2011 18:09:51 -0700 Received: from mail174.messagelabs.com ([85.158.138.51]) by lists.xensource.com with esmtp (Exim 4.43) id 1QzI2f-0003xI-VP for xen-devel@lists.xensource.com; Thu, 01 Sep 2011 17:55:34 -0700 X-Env-Sender: jeremy@goop.org X-Msg-Ref: server-14.tower-174.messagelabs.com!1314924929!29950298!1 X-Originating-IP: [74.207.240.146] X-StarScan-Version: 6.3.6; banners=-,-,- X-VirusChecked: Checked Received: (qmail 21985 invoked from network); 2 Sep 2011 00:55:30 -0000 Received: from claw.goop.org (HELO claw.goop.org) (74.207.240.146) by server-14.tower-174.messagelabs.com with DHE-RSA-AES256-SHA encrypted SMTP; 2 Sep 2011 00:55:30 -0000 Received: from saboo.goop.org (unknown [IPv6:2001:470:1f05:899:a4d0:63ff:fe78:9062]) (Authenticated sender: smtp-saboo) by claw.goop.org (Postfix) with ESMTPSA id 48A8C92E9; Thu, 1 Sep 2011 17:55:21 -0700 (PDT) Received: by saboo.goop.org (Postfix, from userid 500) id D86DB20878; Thu, 1 Sep 2011 17:55:14 -0700 (PDT) From: Jeremy Fitzhardinge To: "H. Peter Anvin" Date: Thu, 1 Sep 2011 17:55:02 -0700 Message-Id: X-Mailer: git-send-email 1.7.6 In-Reply-To: References: In-Reply-To: References: Cc: Marcelo Tosatti , Nick Piggin , KVM , Peter Zijlstra , the arch/x86 maintainers , Linux Kernel Mailing List , Andi Kleen , Avi Kivity , Jeremy Fitzhardinge , Ingo Molnar , Linus Torvalds , Xen Devel Subject: [Xen-devel] [PATCH 09/13] x86/pvticketlocks: we only need to kick if there's waiters X-BeenThere: xen-devel@lists.xensource.com X-Mailman-Version: 2.1.5 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xensource.com Errors-To: xen-devel-bounces@lists.xensource.com From: Jeremy Fitzhardinge If we're releasing the lock into an uncontended state, there's nobody waiting on it, so there's no need to kick anyone. Signed-off-by: Jeremy Fitzhardinge --- arch/x86/kernel/paravirt-spinlocks.c | 3 +-- 1 files changed, 1 insertions(+), 2 deletions(-) diff --git a/arch/x86/kernel/paravirt-spinlocks.c b/arch/x86/kernel/paravirt-spinlocks.c index 21b6986..71b8557 100644 --- a/arch/x86/kernel/paravirt-spinlocks.c +++ b/arch/x86/kernel/paravirt-spinlocks.c @@ -47,8 +47,7 @@ void __ticket_unlock_release_slowpath(struct arch_spinlock *lock) old.head_tail, new.head_tail) != old.head_tail) { /* still people waiting */ __ticket_unlock_release(lock); + __ticket_unlock_kick(lock, new.tickets.head); } - - __ticket_unlock_kick(lock, new.tickets.head); } EXPORT_SYMBOL(__ticket_unlock_release_slowpath); -- 1.7.6 _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel From xen-devel-bounces@lists.xensource.com Thu Sep 01 18:10:42 2011 Return-path: Envelope-to: www-data@lists.xensource.com Delivery-date: Thu, 01 Sep 2011 18:10:42 -0700 Received: from localhost ([127.0.0.1] helo=lists.colo.xensource.com) by lists.xensource.com with esmtp (Exim 4.43) id 1QzIHK-00072R-B6; Thu, 01 Sep 2011 18:10:42 -0700 Received: from mail27.messagelabs.com ([193.109.254.147]) by lists.xensource.com with esmtp (Exim 4.43) id 1QzI2g-0003xR-TM for xen-devel@lists.xensource.com; Thu, 01 Sep 2011 17:55:35 -0700 X-Env-Sender: jeremy@goop.org X-Msg-Ref: server-5.tower-27.messagelabs.com!1314924913!43172794!1 X-Originating-IP: [74.207.240.146] X-StarScan-Version: 6.3.6; banners=-,-,- X-VirusChecked: Checked Received: (qmail 17613 invoked from network); 2 Sep 2011 00:55:15 -0000 Received: from claw.goop.org (HELO claw.goop.org) (74.207.240.146) by server-5.tower-27.messagelabs.com with DHE-RSA-AES256-SHA encrypted SMTP; 2 Sep 2011 00:55:15 -0000 Received: from saboo.goop.org (unknown [IPv6:2001:470:1f05:899:a4d0:63ff:fe78:9062]) (Authenticated sender: smtp-saboo) by claw.goop.org (Postfix) with ESMTPSA id 3B19592E6; Thu, 1 Sep 2011 17:55:21 -0700 (PDT) Received: by saboo.goop.org (Postfix, from userid 500) id AE75A20607; Thu, 1 Sep 2011 17:55:14 -0700 (PDT) From: Jeremy Fitzhardinge To: "H. Peter Anvin" Date: Thu, 1 Sep 2011 17:54:53 -0700 Message-Id: X-Mailer: git-send-email 1.7.6 Cc: Marcelo Tosatti , Nick Piggin , KVM , Peter Zijlstra , the arch/x86 maintainers , Linux Kernel Mailing List , Andi Kleen , Avi Kivity , Jeremy Fitzhardinge , Ingo Molnar , Linus Torvalds , Xen Devel Subject: [Xen-devel] [PATCH 00/13] [PATCH RFC] Paravirtualized ticketlocks X-BeenThere: xen-devel@lists.xensource.com X-Mailman-Version: 2.1.5 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xensource.com Errors-To: xen-devel-bounces@lists.xensource.com From: Jeremy Fitzhardinge This series replaces the existing paravirtualized spinlock mechanism with a paravirtualized ticketlock mechanism. Ticket locks have an inherent problem in a virtualized case, because the vCPUs are scheduled rather than running concurrently (ignoring gang scheduled vCPUs). This can result in catastrophic performance collapses when the vCPU scheduler doesn't schedule the correct "next" vCPU, and ends up scheduling a vCPU which burns its entire timeslice spinning. (Note that this is not the same problem as lock-holder preemption, which this series also addresses; that's also a problem, but not catastrophic). (See Thomas Friebel's talk "Prevent Guests from Spinning Around" http://www.xen.org/files/xensummitboston08/LHP.pdf for more details.) Currently we deal with this by having PV spinlocks, which adds a layer of indirection in front of all the spinlock functions, and defining a completely new implementation for Xen (and for other pvops users, but there are none at present). PV ticketlocks keeps the existing ticketlock implemenentation (fastpath) as-is, but adds a couple of pvops for the slow paths: - If a CPU has been waiting for a spinlock for SPIN_THRESHOLD iterations, then call out to the __ticket_lock_spinning() pvop, which allows a backend to block the vCPU rather than spinning. This pvop can set the lock into "slowpath state". - When releasing a lock, if it is in "slowpath state", the call __ticket_unlock_kick() to kick the next vCPU in line awake. If the lock is no longer in contention, it also clears the slowpath flag. The "slowpath state" is stored in the LSB of the within the lock ticket. This has the effect of reducing the max number of CPUs by half (so, a "small ticket" can deal with 128 CPUs, and "large ticket" 32768). This series provides a Xen implementation, but it should be straightforward to add a KVM implementation as well. Overall, it results in a large reduction in code, it makes the native and virtualized cases closer, and it removes a layer of indirection around all the spinlock functions. The downside is that it does add a few instructions into the fastpath in the native case. Most of the heavy lifting code is in the slowpaths, but it does have an effect on the fastpath code. The inner part of ticket lock code becomes: inc = xadd(&lock->tickets, inc); inc.tail &= ~TICKET_SLOWPATH_FLAG; for (;;) { unsigned count = SPIN_THRESHOLD; do { if (inc.head == inc.tail) goto out; cpu_relax(); inc.head = ACCESS_ONCE(lock->tickets.head); } while (--count); __ticket_lock_spinning(lock, inc.tail); } which results in: pushq %rbp movq %rsp,%rbp movl $512, %ecx lock; xaddw %cx, (%rdi) # claim ticket movzbl %ch, %edx movl $2048, %eax # set spin count andl $-2, %edx # mask off TICKET_SLOWPATH_FLAG movzbl %dl, %esi 1: cmpb %dl, %cl # compare head and tail je 2f # got it! ### BEGIN SLOWPATH rep; nop # pause decl %eax # dec count movb (%rdi), %cl # re-fetch head jne 1b # try again call *pv_lock_ops # call __ticket_lock_spinning movl $2048, %eax # reload spin count jmp 1b ### END SLOWPATH 2: popq %rbp ret with CONFIG_PARAVIRT_SPINLOCKS=n, the same code identical asm to the current ticketlock code: pushq %rbp movq %rsp, %rbp movl $256, %eax lock; xaddw %ax, (%rdi) movzbl %ah, %edx 1: cmpb %dl, %al # compare head and tail je 2f # got it! ### BEGIN SLOWPATH rep; nop # pause movb (%rdi), %al # reload head jmp 1b # loop ### END SLOWPATH 2: popq %rbp ret so the pv ticketlocks add 3 extra instructions to the fastpath, one of which really doesn't need to be there (setting up the arg for the slowpath function): movl $2048, %eax # set spin count andl $-2, %edx # mask off SLOW_PATH_FLAG movzbl %dl, %esi # set up __ticket_lock_spinning arg The unlock code is very straightforward: __ticket_unlock_release(lock); if (unlikely(__ticket_in_slowpath(lock))) __ticket_unlock_slowpath(lock); which generates: addb $2, (%rdi) testb $1, 1(%rdi) je 1f call __ticket_unlock_slowpath 1: which, while simple, is more complex than the simple "incb (%rdi)". (I'm not sure whether its worth inlining this or not.) Thoughts? Comments? Suggestions? Thanks, J Jeremy Fitzhardinge (12): x86/spinlocks: replace pv spinlocks with pv ticketlocks x86/ticketlock: collapse a layer of functions xen/pvticketlock: Xen implementation for PV ticket locks x86/pvticketlock: use callee-save for lock_spinning x86/ticketlocks: when paravirtualizing ticket locks, increment by 2 x86/ticketlock: add slowpath logic x86/ticketlocks: tidy up __ticket_unlock_kick() xen/pvticketlock: disable interrupts while blocking x86/pvticketlocks: we only need to kick if there's waiters xen/pvticket: allow interrupts to be enabled while blocking x86/pvticketlock: make sure unlock_kick pvop call is inlined x86/pvticketlock: use __ticket_t for pvop args Srivatsa Vaddagiri (1): x86/ticketlock: only do kick after doing unlock arch/x86/include/asm/paravirt.h | 30 +--- arch/x86/include/asm/paravirt_types.h | 8 +- arch/x86/include/asm/spinlock.h | 118 ++++++++----- arch/x86/include/asm/spinlock_types.h | 16 ++- arch/x86/kernel/paravirt-spinlocks.c | 40 +++-- arch/x86/xen/spinlock.c | 305 ++++++++------------------------- 6 files changed, 186 insertions(+), 331 deletions(-) -- 1.7.6 _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel From xen-devel-bounces@lists.xensource.com Thu Sep 01 18:11:29 2011 Return-path: Envelope-to: www-data@lists.xensource.com Delivery-date: Thu, 01 Sep 2011 18:11:29 -0700 Received: from localhost ([127.0.0.1] helo=lists.colo.xensource.com) by lists.xensource.com with esmtp (Exim 4.43) id 1QzII4-0007PR-Vf; Thu, 01 Sep 2011 18:11:28 -0700 Received: from mail27.messagelabs.com ([193.109.254.147]) by lists.xensource.com with esmtp (Exim 4.43) id 1QzI2h-0003xn-Ge for xen-devel@lists.xensource.com; Thu, 01 Sep 2011 17:55:35 -0700 X-Env-Sender: jeremy@goop.org X-Msg-Ref: server-10.tower-27.messagelabs.com!1314924913!34042940!1 X-Originating-IP: [74.207.240.146] X-StarScan-Version: 6.3.6; banners=-,-,- X-VirusChecked: Checked Received: (qmail 12648 invoked from network); 2 Sep 2011 00:55:15 -0000 Received: from claw.goop.org (HELO claw.goop.org) (74.207.240.146) by server-10.tower-27.messagelabs.com with DHE-RSA-AES256-SHA encrypted SMTP; 2 Sep 2011 00:55:15 -0000 Received: from saboo.goop.org (unknown [IPv6:2001:470:1f05:899:a4d0:63ff:fe78:9062]) (Authenticated sender: smtp-saboo) by claw.goop.org (Postfix) with ESMTPSA id 4B7CA92EA; Thu, 1 Sep 2011 17:55:22 -0700 (PDT) Received: by saboo.goop.org (Postfix, from userid 500) id C36EF2081F; Thu, 1 Sep 2011 17:55:14 -0700 (PDT) From: Jeremy Fitzhardinge To: "H. Peter Anvin" Date: Thu, 1 Sep 2011 17:54:58 -0700 Message-Id: <076a86852aaa1ce14cf2216abfceea20d366fd98.1314922370.git.jeremy.fitzhardinge@citrix.com> X-Mailer: git-send-email 1.7.6 In-Reply-To: References: In-Reply-To: References: Cc: Marcelo Tosatti , Nick Piggin , KVM , Peter Zijlstra , the arch/x86 maintainers , Linux Kernel Mailing List , Andi Kleen , Avi Kivity , Jeremy Fitzhardinge , Ingo Molnar , Linus Torvalds , Xen Devel Subject: [Xen-devel] [PATCH 05/13] x86/ticketlocks: when paravirtualizing ticket locks, increment by 2 X-BeenThere: xen-devel@lists.xensource.com X-Mailman-Version: 2.1.5 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xensource.com Errors-To: xen-devel-bounces@lists.xensource.com From: Jeremy Fitzhardinge Increment ticket head/tails by 2 rather than 1 to leave the LSB free to store a "is in slowpath state" bit. This halves the number of possible CPUs for a given ticket size, but this shouldn't matter in practice - kernels built for 32k+ CPU systems are probably specially built for the hardware rather than a generic distro kernel. Signed-off-by: Jeremy Fitzhardinge --- arch/x86/include/asm/spinlock.h | 16 ++++++++-------- arch/x86/include/asm/spinlock_types.h | 10 +++++++++- 2 files changed, 17 insertions(+), 9 deletions(-) diff --git a/arch/x86/include/asm/spinlock.h b/arch/x86/include/asm/spinlock.h index c1d9617..6028b01 100644 --- a/arch/x86/include/asm/spinlock.h +++ b/arch/x86/include/asm/spinlock.h @@ -83,7 +83,7 @@ static __always_inline void __ticket_unlock_kick(struct arch_spinlock *lock, __t */ static __always_inline void arch_spin_lock(struct arch_spinlock *lock) { - register struct __raw_tickets inc = { .tail = 1 }; + register struct __raw_tickets inc = { .tail = TICKET_LOCK_INC }; inc = xadd(&lock->tickets, inc); @@ -109,7 +109,7 @@ static __always_inline int arch_spin_trylock(arch_spinlock_t *lock) if (old.tickets.head != old.tickets.tail) return 0; - new.head_tail = old.head_tail + (1 << TICKET_SHIFT); + new.head_tail = old.head_tail + (TICKET_LOCK_INC << TICKET_SHIFT); /* cmpxchg is a full barrier, so nothing can move before it */ return cmpxchg(&lock->head_tail, old.head_tail, new.head_tail) == old.head_tail; @@ -118,24 +118,24 @@ static __always_inline int arch_spin_trylock(arch_spinlock_t *lock) #if (NR_CPUS < 256) static __always_inline void __ticket_unlock_release(arch_spinlock_t *lock) { - asm volatile(UNLOCK_LOCK_PREFIX "incb %0" + asm volatile(UNLOCK_LOCK_PREFIX "addb %1, %0" : "+m" (lock->head_tail) - : + : "i" (TICKET_LOCK_INC) : "memory", "cc"); } #else static __always_inline void __ticket_unlock_release(arch_spinlock_t *lock) { - asm volatile(UNLOCK_LOCK_PREFIX "incw %0" + asm volatile(UNLOCK_LOCK_PREFIX "addw %1, %0" : "+m" (lock->head_tail) - : + : "i" (TICKET_LOCK_INC) : "memory", "cc"); } #endif static __always_inline void arch_spin_unlock(arch_spinlock_t *lock) { - __ticket_t next = lock->tickets.head + 1; + __ticket_t next = lock->tickets.head + TICKET_LOCK_INC; __ticket_unlock_release(lock); __ticket_unlock_kick(lock, next); @@ -152,7 +152,7 @@ static inline int arch_spin_is_contended(arch_spinlock_t *lock) { struct __raw_tickets tmp = ACCESS_ONCE(lock->tickets); - return ((tmp.tail - tmp.head) & TICKET_MASK) > 1; + return ((tmp.tail - tmp.head) & TICKET_MASK) > TICKET_LOCK_INC; } #define arch_spin_is_contended arch_spin_is_contended diff --git a/arch/x86/include/asm/spinlock_types.h b/arch/x86/include/asm/spinlock_types.h index 72e154e..0553c0b 100644 --- a/arch/x86/include/asm/spinlock_types.h +++ b/arch/x86/include/asm/spinlock_types.h @@ -7,7 +7,13 @@ #include -#if (CONFIG_NR_CPUS < 256) +#ifdef CONFIG_PARAVIRT_SPINLOCKS +#define __TICKET_LOCK_INC 2 +#else +#define __TICKET_LOCK_INC 1 +#endif + +#if (CONFIG_NR_CPUS < (256 / __TICKET_LOCK_INC)) typedef u8 __ticket_t; typedef u16 __ticketpair_t; #else @@ -15,6 +21,8 @@ typedef u16 __ticket_t; typedef u32 __ticketpair_t; #endif +#define TICKET_LOCK_INC ((__ticket_t)__TICKET_LOCK_INC) + #define TICKET_SHIFT (sizeof(__ticket_t) * 8) #define TICKET_MASK ((__ticket_t)((1 << TICKET_SHIFT) - 1)) -- 1.7.6 _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel From xen-devel-bounces@lists.xensource.com Thu Sep 01 18:12:16 2011 Return-path: Envelope-to: www-data@lists.xensource.com Delivery-date: Thu, 01 Sep 2011 18:12:16 -0700 Received: from localhost ([127.0.0.1] helo=lists.colo.xensource.com) by lists.xensource.com with esmtp (Exim 4.43) id 1QzIIq-0007mb-L3; Thu, 01 Sep 2011 18:12:16 -0700 Received: from mail21.messagelabs.com ([85.158.143.35]) by lists.xensource.com with esmtp (Exim 4.43) id 1QzI2i-0003xw-HS for xen-devel@lists.xensource.com; Thu, 01 Sep 2011 17:55:37 -0700 X-Env-Sender: jeremy@goop.org X-Msg-Ref: server-6.tower-21.messagelabs.com!1314924913!36688081!1 X-Originating-IP: [74.207.240.146] X-StarScan-Version: 6.3.6; banners=-,-,- X-VirusChecked: Checked Received: (qmail 4787 invoked from network); 2 Sep 2011 00:55:14 -0000 Received: from claw.goop.org (HELO claw.goop.org) (74.207.240.146) by server-6.tower-21.messagelabs.com with DHE-RSA-AES256-SHA encrypted SMTP; 2 Sep 2011 00:55:14 -0000 Received: from saboo.goop.org (unknown [IPv6:2001:470:1f05:899:a4d0:63ff:fe78:9062]) (Authenticated sender: smtp-saboo) by claw.goop.org (Postfix) with ESMTPSA id A322392ED; Thu, 1 Sep 2011 17:55:23 -0700 (PDT) Received: by saboo.goop.org (Postfix, from userid 500) id E06DD208AC; Thu, 1 Sep 2011 17:55:14 -0700 (PDT) From: Jeremy Fitzhardinge To: "H. Peter Anvin" Date: Thu, 1 Sep 2011 17:55:03 -0700 Message-Id: <17a0f6177a71190dad30a6dcd1da93bec13a7836.1314922370.git.jeremy.fitzhardinge@citrix.com> X-Mailer: git-send-email 1.7.6 In-Reply-To: References: In-Reply-To: References: Cc: Marcelo Tosatti , Nick Piggin , KVM , Peter Zijlstra , the arch/x86 maintainers , Linux Kernel Mailing List , Andi Kleen , Avi Kivity , Jeremy Fitzhardinge , Ingo Molnar , Linus Torvalds , Xen Devel Subject: [Xen-devel] [PATCH 10/13] xen/pvticket: allow interrupts to be enabled while blocking X-BeenThere: xen-devel@lists.xensource.com X-Mailman-Version: 2.1.5 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xensource.com Errors-To: xen-devel-bounces@lists.xensource.com From: Jeremy Fitzhardinge Signed-off-by: Jeremy Fitzhardinge --- arch/x86/xen/spinlock.c | 28 +++++++++++++++++++++++++--- 1 files changed, 25 insertions(+), 3 deletions(-) diff --git a/arch/x86/xen/spinlock.c b/arch/x86/xen/spinlock.c index 2ed5d05..7b89439 100644 --- a/arch/x86/xen/spinlock.c +++ b/arch/x86/xen/spinlock.c @@ -106,11 +106,26 @@ static void xen_lock_spinning(struct arch_spinlock *lock, unsigned want) start = spin_time_start(); - /* Make sure interrupts are disabled to ensure that these - per-cpu values are not overwritten. */ + /* Make sure an interrupt handler can't upset things in a + partially setup state. */ local_irq_save(flags); + /* + * We don't really care if we're overwriting some other + * (lock,want) pair, as that would mean that we're currently + * in an interrupt context, and the outer context had + * interrupts enabled. That has already kicked the VCPU out + * of xen_poll_irq(), so it will just return spuriously and + * retry with newly setup (lock,want). + * + * The ordering protocol on this is that the "lock" pointer + * may only be set non-NULL if the "want" ticket is correct. + * If we're updating "want", we must first clear "lock". + */ + w->lock = NULL; + smp_wmb(); w->want = want; + smp_wmb(); w->lock = lock; /* This uses set_bit, which atomic and therefore a barrier */ @@ -135,10 +150,15 @@ static void xen_lock_spinning(struct arch_spinlock *lock, unsigned want) goto out; } + /* Allow interrupts while blocked */ + local_irq_restore(flags); + /* Block until irq becomes pending (or perhaps a spurious wakeup) */ xen_poll_irq(irq); ADD_STATS(taken_slow_spurious, !xen_test_irq_pending(irq)); + local_irq_save(flags); + kstat_incr_irqs_this_cpu(irq, irq_to_desc(irq)); out: @@ -160,7 +180,9 @@ static void xen_unlock_kick(struct arch_spinlock *lock, unsigned next) for_each_cpu(cpu, &waiting_cpus) { const struct xen_lock_waiting *w = &per_cpu(lock_waiting, cpu); - if (w->lock == lock && w->want == next) { + /* Make sure we read lock before want */ + if (ACCESS_ONCE(w->lock) == lock && + ACCESS_ONCE(w->want) == next) { ADD_STATS(released_slow_kicked, 1); xen_send_IPI_one(cpu, XEN_SPIN_UNLOCK_VECTOR); break; -- 1.7.6 _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel From xen-devel-bounces@lists.xensource.com Thu Sep 01 18:13:29 2011 Return-path: Envelope-to: www-data@lists.xensource.com Delivery-date: Thu, 01 Sep 2011 18:13:29 -0700 Received: from localhost ([127.0.0.1] helo=lists.colo.xensource.com) by lists.xensource.com with esmtp (Exim 4.43) id 1QzIK1-00089v-De; Thu, 01 Sep 2011 18:13:29 -0700 Received: from mail216.messagelabs.com ([85.158.143.99]) by lists.xensource.com with esmtp (Exim 4.43) id 1QzI2l-0003yn-Iu for xen-devel@lists.xensource.com; Thu, 01 Sep 2011 17:55:40 -0700 X-Env-Sender: jeremy@goop.org X-Msg-Ref: server-2.tower-216.messagelabs.com!1314924934!16766418!1 X-Originating-IP: [74.207.240.146] X-StarScan-Version: 6.3.6; banners=-,-,- X-VirusChecked: Checked Received: (qmail 18448 invoked from network); 2 Sep 2011 00:55:36 -0000 Received: from claw.goop.org (HELO claw.goop.org) (74.207.240.146) by server-2.tower-216.messagelabs.com with DHE-RSA-AES256-SHA encrypted SMTP; 2 Sep 2011 00:55:36 -0000 Received: from saboo.goop.org (unknown [IPv6:2001:470:1f05:899:a4d0:63ff:fe78:9062]) (Authenticated sender: smtp-saboo) by claw.goop.org (Postfix) with ESMTPSA id 6095292F4; Thu, 1 Sep 2011 17:55:24 -0700 (PDT) Received: by saboo.goop.org (Postfix, from userid 500) id D430920871; Thu, 1 Sep 2011 17:55:14 -0700 (PDT) From: Jeremy Fitzhardinge To: "H. Peter Anvin" Date: Thu, 1 Sep 2011 17:55:01 -0700 Message-Id: <38bb37e15f6e5056d5238adac945bc1837a996ec.1314922370.git.jeremy.fitzhardinge@citrix.com> X-Mailer: git-send-email 1.7.6 In-Reply-To: References: In-Reply-To: References: Cc: Marcelo Tosatti , Nick Piggin , KVM , Peter Zijlstra , the arch/x86 maintainers , Linux Kernel Mailing List , Andi Kleen , Avi Kivity , Jeremy Fitzhardinge , Ingo Molnar , Linus Torvalds , Xen Devel Subject: [Xen-devel] [PATCH 08/13] xen/pvticketlock: disable interrupts while blocking X-BeenThere: xen-devel@lists.xensource.com X-Mailman-Version: 2.1.5 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xensource.com Errors-To: xen-devel-bounces@lists.xensource.com From: Jeremy Fitzhardinge We need to make sure interrupts are disabled while we're relying on the contents of the per-cpu lock_waiting values, otherwise an interrupt handler could come in, try to take some other lock, block, and overwrite our values. Signed-off-by: Jeremy Fitzhardinge --- arch/x86/xen/spinlock.c | 8 ++++++++ 1 files changed, 8 insertions(+), 0 deletions(-) diff --git a/arch/x86/xen/spinlock.c b/arch/x86/xen/spinlock.c index 4c46144..2ed5d05 100644 --- a/arch/x86/xen/spinlock.c +++ b/arch/x86/xen/spinlock.c @@ -98,6 +98,7 @@ static void xen_lock_spinning(struct arch_spinlock *lock, unsigned want) struct xen_lock_waiting *w = &__get_cpu_var(lock_waiting); int cpu = smp_processor_id(); u64 start; + unsigned long flags; /* If kicker interrupts not initialized yet, just spin */ if (irq == -1) @@ -105,6 +106,10 @@ static void xen_lock_spinning(struct arch_spinlock *lock, unsigned want) start = spin_time_start(); + /* Make sure interrupts are disabled to ensure that these + per-cpu values are not overwritten. */ + local_irq_save(flags); + w->want = want; w->lock = lock; @@ -139,6 +144,9 @@ static void xen_lock_spinning(struct arch_spinlock *lock, unsigned want) out: cpumask_clear_cpu(cpu, &waiting_cpus); w->lock = NULL; + + local_irq_restore(flags); + spin_time_accum_blocked(start); } PV_CALLEE_SAVE_REGS_THUNK(xen_lock_spinning); -- 1.7.6 _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel From xen-devel-bounces@lists.xensource.com Thu Sep 01 18:14:25 2011 Return-path: Envelope-to: www-data@lists.xensource.com Delivery-date: Thu, 01 Sep 2011 18:14:25 -0700 Received: from localhost ([127.0.0.1] helo=lists.colo.xensource.com) by lists.xensource.com with esmtp (Exim 4.43) id 1QzIKv-0000AD-Bj; Thu, 01 Sep 2011 18:14:25 -0700 Received: from mail174.messagelabs.com ([85.158.138.51]) by lists.xensource.com with esmtp (Exim 4.43) id 1QzI2p-0003zd-N1 for xen-devel@lists.xensource.com; Thu, 01 Sep 2011 17:55:44 -0700 X-Env-Sender: jeremy@goop.org X-Msg-Ref: server-4.tower-174.messagelabs.com!1314924936!29961654!1 X-Originating-IP: [74.207.240.146] X-StarScan-Version: 6.3.6; banners=-,-,- X-VirusChecked: Checked Received: (qmail 13647 invoked from network); 2 Sep 2011 00:55:40 -0000 Received: from claw.goop.org (HELO claw.goop.org) (74.207.240.146) by server-4.tower-174.messagelabs.com with DHE-RSA-AES256-SHA encrypted SMTP; 2 Sep 2011 00:55:40 -0000 Received: from saboo.goop.org (unknown [IPv6:2001:470:1f05:899:a4d0:63ff:fe78:9062]) (Authenticated sender: smtp-saboo) by claw.goop.org (Postfix) with ESMTPSA id 5EDF592F3; Thu, 1 Sep 2011 17:55:24 -0700 (PDT) Received: by saboo.goop.org (Postfix, from userid 500) id F2D91208DE; Thu, 1 Sep 2011 17:55:14 -0700 (PDT) From: Jeremy Fitzhardinge To: "H. Peter Anvin" Date: Thu, 1 Sep 2011 17:55:06 -0700 Message-Id: X-Mailer: git-send-email 1.7.6 In-Reply-To: References: In-Reply-To: References: Cc: Marcelo Tosatti , Nick Piggin , KVM , Peter Zijlstra , the arch/x86 maintainers , Linux Kernel Mailing List , Andi Kleen , Avi Kivity , Jeremy Fitzhardinge , Ingo Molnar , Linus Torvalds , Xen Devel Subject: [Xen-devel] [PATCH 13/13] x86/pvticketlock: use __ticket_t for pvop args X-BeenThere: xen-devel@lists.xensource.com X-Mailman-Version: 2.1.5 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xensource.com Errors-To: xen-devel-bounces@lists.xensource.com From: Jeremy Fitzhardinge Use __ticket_t for the ticket argument to the pvops, to prevent unnecessary zero-extension in the calling code. Signed-off-by: Jeremy Fitzhardinge --- arch/x86/include/asm/paravirt.h | 6 ++++-- arch/x86/include/asm/spinlock_types.h | 4 ---- arch/x86/xen/spinlock.c | 4 ++-- 3 files changed, 6 insertions(+), 8 deletions(-) diff --git a/arch/x86/include/asm/paravirt.h b/arch/x86/include/asm/paravirt.h index a6f2651..932a682 100644 --- a/arch/x86/include/asm/paravirt.h +++ b/arch/x86/include/asm/paravirt.h @@ -741,12 +741,14 @@ static inline void __set_fixmap(unsigned /* enum fixed_addresses */ idx, #if defined(CONFIG_SMP) && defined(CONFIG_PARAVIRT_SPINLOCKS) -static __always_inline void __ticket_lock_spinning(struct arch_spinlock *lock, unsigned ticket) +#include + +static __always_inline void __ticket_lock_spinning(struct arch_spinlock *lock, __ticket_t ticket) { PVOP_VCALLEE2(pv_lock_ops.lock_spinning, lock, ticket); } -static __always_inline void __ticket_unlock_kick(struct arch_spinlock *lock, unsigned ticket) +static __always_inline void __ticket_unlock_kick(struct arch_spinlock *lock, __ticket_t ticket) { PVOP_VCALL2(pv_lock_ops.unlock_kick, lock, ticket); } diff --git a/arch/x86/include/asm/spinlock_types.h b/arch/x86/include/asm/spinlock_types.h index 7b383e2..62ea99e 100644 --- a/arch/x86/include/asm/spinlock_types.h +++ b/arch/x86/include/asm/spinlock_types.h @@ -1,10 +1,6 @@ #ifndef _ASM_X86_SPINLOCK_TYPES_H #define _ASM_X86_SPINLOCK_TYPES_H -#ifndef __LINUX_SPINLOCK_TYPES_H -# error "please don't include this file directly" -#endif - #include #ifdef CONFIG_PARAVIRT_SPINLOCKS diff --git a/arch/x86/xen/spinlock.c b/arch/x86/xen/spinlock.c index 7b89439..91b0940 100644 --- a/arch/x86/xen/spinlock.c +++ b/arch/x86/xen/spinlock.c @@ -92,7 +92,7 @@ static DEFINE_PER_CPU(int, lock_kicker_irq) = -1; static DEFINE_PER_CPU(struct xen_lock_waiting, lock_waiting); static cpumask_t waiting_cpus; -static void xen_lock_spinning(struct arch_spinlock *lock, unsigned want) +static void xen_lock_spinning(struct arch_spinlock *lock, __ticket_t want) { int irq = __this_cpu_read(lock_kicker_irq); struct xen_lock_waiting *w = &__get_cpu_var(lock_waiting); @@ -171,7 +171,7 @@ out: } PV_CALLEE_SAVE_REGS_THUNK(xen_lock_spinning); -static void xen_unlock_kick(struct arch_spinlock *lock, unsigned next) +static void xen_unlock_kick(struct arch_spinlock *lock, __ticket_t next) { int cpu; -- 1.7.6 _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel From xen-devel-bounces@lists.xensource.com Thu Sep 01 18:15:10 2011 Return-path: Envelope-to: www-data@lists.xensource.com Delivery-date: Thu, 01 Sep 2011 18:15:10 -0700 Received: from localhost ([127.0.0.1] helo=lists.colo.xensource.com) by lists.xensource.com with esmtp (Exim 4.43) id 1QzILe-0000Xz-Ez; Thu, 01 Sep 2011 18:15:10 -0700 Received: from mail182.messagelabs.com ([85.158.139.83]) by lists.xensource.com with esmtp (Exim 4.43) id 1QzI2p-0003zi-Ug for xen-devel@lists.xensource.com; Thu, 01 Sep 2011 17:55:44 -0700 X-Env-Sender: jeremy@goop.org X-Msg-Ref: server-2.tower-182.messagelabs.com!1314924938!15745902!1 X-Originating-IP: [74.207.240.146] X-StarScan-Version: 6.3.6; banners=-,-,- X-VirusChecked: Checked Received: (qmail 11229 invoked from network); 2 Sep 2011 00:55:40 -0000 Received: from claw.goop.org (HELO claw.goop.org) (74.207.240.146) by server-2.tower-182.messagelabs.com with DHE-RSA-AES256-SHA encrypted SMTP; 2 Sep 2011 00:55:40 -0000 Received: from saboo.goop.org (unknown [IPv6:2001:470:1f05:899:a4d0:63ff:fe78:9062]) (Authenticated sender: smtp-saboo) by claw.goop.org (Postfix) with ESMTPSA id 9050C92EC; Thu, 1 Sep 2011 17:55:23 -0700 (PDT) Received: by saboo.goop.org (Postfix, from userid 500) id CD55A20870; Thu, 1 Sep 2011 17:55:14 -0700 (PDT) From: Jeremy Fitzhardinge To: "H. Peter Anvin" Date: Thu, 1 Sep 2011 17:55:00 -0700 Message-Id: X-Mailer: git-send-email 1.7.6 In-Reply-To: References: In-Reply-To: References: Cc: Marcelo Tosatti , Nick Piggin , KVM , Peter Zijlstra , the arch/x86 maintainers , Linux Kernel Mailing List , Andi Kleen , Avi Kivity , Jeremy Fitzhardinge , Ingo Molnar , Linus Torvalds , Xen Devel Subject: [Xen-devel] [PATCH 07/13] x86/ticketlocks: tidy up __ticket_unlock_kick() X-BeenThere: xen-devel@lists.xensource.com X-Mailman-Version: 2.1.5 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xensource.com Errors-To: xen-devel-bounces@lists.xensource.com From: Jeremy Fitzhardinge __ticket_unlock_kick() is now only called from known slowpaths, so there's no need for it to do any checking of its own. Signed-off-by: Jeremy Fitzhardinge --- arch/x86/include/asm/paravirt.h | 2 +- arch/x86/include/asm/spinlock.h | 14 -------------- 2 files changed, 1 insertions(+), 15 deletions(-) diff --git a/arch/x86/include/asm/paravirt.h b/arch/x86/include/asm/paravirt.h index 622f3d6..b89699a 100644 --- a/arch/x86/include/asm/paravirt.h +++ b/arch/x86/include/asm/paravirt.h @@ -746,7 +746,7 @@ static inline void __ticket_lock_spinning(struct arch_spinlock *lock, unsigned t PVOP_VCALLEE2(pv_lock_ops.lock_spinning, lock, ticket); } -static inline void ____ticket_unlock_kick(struct arch_spinlock *lock, unsigned ticket) +static inline void __ticket_unlock_kick(struct arch_spinlock *lock, unsigned ticket) { PVOP_VCALL2(pv_lock_ops.unlock_kick, lock, ticket); } diff --git a/arch/x86/include/asm/spinlock.h b/arch/x86/include/asm/spinlock.h index 2135a48..365d787 100644 --- a/arch/x86/include/asm/spinlock.h +++ b/arch/x86/include/asm/spinlock.h @@ -78,23 +78,9 @@ static __always_inline void __ticket_lock_spinning(struct arch_spinlock *lock, u { } -static __always_inline void ____ticket_unlock_kick(struct arch_spinlock *lock, unsigned ticket) -{ -} - #endif /* CONFIG_PARAVIRT_SPINLOCKS */ -/* - * If a spinlock has someone waiting on it, then kick the appropriate - * waiting cpu. - */ -static __always_inline void __ticket_unlock_kick(struct arch_spinlock *lock, __ticket_t next) -{ - if (unlikely(lock->tickets.tail != next)) - ____ticket_unlock_kick(lock, next); -} - /* * Ticket locks are conceptually two parts, one indicating the current head of * the queue, and the other indicating the current tail. The lock is acquired -- 1.7.6 _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel From xen-devel-bounces@lists.xensource.com Thu Sep 01 18:15:54 2011 Return-path: Envelope-to: www-data@lists.xensource.com Delivery-date: Thu, 01 Sep 2011 18:15:54 -0700 Received: from localhost ([127.0.0.1] helo=lists.colo.xensource.com) by lists.xensource.com with esmtp (Exim 4.43) id 1QzIMM-0000ua-Ff; Thu, 01 Sep 2011 18:15:54 -0700 Received: from mail21.messagelabs.com ([85.158.143.35]) by lists.xensource.com with esmtp (Exim 4.43) id 1QzI2r-0003zy-UC for xen-devel@lists.xensource.com; Thu, 01 Sep 2011 17:55:46 -0700 X-Env-Sender: jeremy@goop.org X-Msg-Ref: server-4.tower-21.messagelabs.com!1314924907!58665503!1 X-Originating-IP: [74.207.240.146] X-StarScan-Version: 6.3.6; banners=-,-,- X-VirusChecked: Checked Received: (qmail 15827 invoked from network); 2 Sep 2011 00:55:09 -0000 Received: from claw.goop.org (HELO claw.goop.org) (74.207.240.146) by server-4.tower-21.messagelabs.com with DHE-RSA-AES256-SHA encrypted SMTP; 2 Sep 2011 00:55:09 -0000 Received: from saboo.goop.org (unknown [IPv6:2001:470:1f05:899:a4d0:63ff:fe78:9062]) (Authenticated sender: smtp-saboo) by claw.goop.org (Postfix) with ESMTPSA id 9A9B792F5; Thu, 1 Sep 2011 17:55:24 -0700 (PDT) Received: by saboo.goop.org (Postfix, from userid 500) id C750F20822; Thu, 1 Sep 2011 17:55:14 -0700 (PDT) From: Jeremy Fitzhardinge To: "H. Peter Anvin" Date: Thu, 1 Sep 2011 17:54:59 -0700 Message-Id: <8a788f3fbf2ad1316e462bf5aae623bab9d38319.1314922370.git.jeremy.fitzhardinge@citrix.com> X-Mailer: git-send-email 1.7.6 In-Reply-To: References: In-Reply-To: References: Cc: Marcelo Tosatti , Nick Piggin , KVM , Peter Zijlstra , the arch/x86 maintainers , Linux Kernel Mailing List , Andi Kleen , Avi Kivity , Jeremy Fitzhardinge , Ingo Molnar , Linus Torvalds , Xen Devel Subject: [Xen-devel] [PATCH 06/13] x86/ticketlock: add slowpath logic X-BeenThere: xen-devel@lists.xensource.com X-Mailman-Version: 2.1.5 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xensource.com Errors-To: xen-devel-bounces@lists.xensource.com From: Jeremy Fitzhardinge Maintain a flag in both LSBs of the ticket lock which indicates whether anyone is in the lock slowpath and may need kicking when the current holder unlocks. The flags are set when the first locker enters the slowpath, and cleared when unlocking to an empty queue. In the specific implementation of lock_spinning(), make sure to set the slowpath flags on the lock just before blocking. We must do this before the last-chance pickup test to prevent a deadlock with the unlocker: Unlocker Locker test for lock pickup -> fail test slowpath + unlock -> false set slowpath flags block Whereas this works in any ordering: Unlocker Locker set slowpath flags test for lock pickup -> fail block test slowpath + unlock -> true, kick Signed-off-by: Jeremy Fitzhardinge --- arch/x86/include/asm/spinlock.h | 41 +++++++++++++++++++++++++++++--- arch/x86/include/asm/spinlock_types.h | 2 + arch/x86/kernel/paravirt-spinlocks.c | 37 +++++++++++++++++++++++++++++ arch/x86/xen/spinlock.c | 4 +++ 4 files changed, 80 insertions(+), 4 deletions(-) diff --git a/arch/x86/include/asm/spinlock.h b/arch/x86/include/asm/spinlock.h index 6028b01..2135a48 100644 --- a/arch/x86/include/asm/spinlock.h +++ b/arch/x86/include/asm/spinlock.h @@ -41,7 +41,38 @@ /* How long a lock should spin before we consider blocking */ #define SPIN_THRESHOLD (1 << 11) -#ifndef CONFIG_PARAVIRT_SPINLOCKS +/* Only defined when CONFIG_PARAVIRT_SPINLOCKS defined, but may as + * well leave the prototype always visible. */ +extern void __ticket_unlock_release_slowpath(struct arch_spinlock *lock); + +#ifdef CONFIG_PARAVIRT_SPINLOCKS + +/* + * Return true if someone is in the slowpath on this lock. This + * should only be used by the current lock-holder. + */ +static inline bool __ticket_in_slowpath(struct arch_spinlock *lock) +{ + return !!(lock->tickets.tail & TICKET_SLOWPATH_FLAG); +} + +static inline void __ticket_enter_slowpath(struct arch_spinlock *lock) +{ + if (sizeof(lock->tickets.tail) == sizeof(u8)) + asm (LOCK_PREFIX "orb %1, %0" + : "+m" (lock->tickets.tail) + : "i" (TICKET_SLOWPATH_FLAG) : "memory"); + else + asm (LOCK_PREFIX "orw %1, %0" + : "+m" (lock->tickets.tail) + : "i" (TICKET_SLOWPATH_FLAG) : "memory"); +} + +#else /* !CONFIG_PARAVIRT_SPINLOCKS */ +static inline bool __ticket_in_slowpath(struct arch_spinlock *lock) +{ + return false; +} static __always_inline void __ticket_lock_spinning(struct arch_spinlock *lock, unsigned ticket) { @@ -86,6 +117,7 @@ static __always_inline void arch_spin_lock(struct arch_spinlock *lock) register struct __raw_tickets inc = { .tail = TICKET_LOCK_INC }; inc = xadd(&lock->tickets, inc); + inc.tail &= ~TICKET_SLOWPATH_FLAG; for (;;) { unsigned count = SPIN_THRESHOLD; @@ -135,10 +167,11 @@ static __always_inline void __ticket_unlock_release(arch_spinlock_t *lock) static __always_inline void arch_spin_unlock(arch_spinlock_t *lock) { - __ticket_t next = lock->tickets.head + TICKET_LOCK_INC; - __ticket_unlock_release(lock); - __ticket_unlock_kick(lock, next); + if (unlikely(__ticket_in_slowpath(lock))) + __ticket_unlock_release_slowpath(lock); + else + __ticket_unlock_release(lock); } static inline int arch_spin_is_locked(arch_spinlock_t *lock) diff --git a/arch/x86/include/asm/spinlock_types.h b/arch/x86/include/asm/spinlock_types.h index 0553c0b..7b383e2 100644 --- a/arch/x86/include/asm/spinlock_types.h +++ b/arch/x86/include/asm/spinlock_types.h @@ -9,8 +9,10 @@ #ifdef CONFIG_PARAVIRT_SPINLOCKS #define __TICKET_LOCK_INC 2 +#define TICKET_SLOWPATH_FLAG ((__ticket_t)1) #else #define __TICKET_LOCK_INC 1 +#define TICKET_SLOWPATH_FLAG ((__ticket_t)0) #endif #if (CONFIG_NR_CPUS < (256 / __TICKET_LOCK_INC)) diff --git a/arch/x86/kernel/paravirt-spinlocks.c b/arch/x86/kernel/paravirt-spinlocks.c index 4251c1d..21b6986 100644 --- a/arch/x86/kernel/paravirt-spinlocks.c +++ b/arch/x86/kernel/paravirt-spinlocks.c @@ -15,3 +15,40 @@ struct pv_lock_ops pv_lock_ops = { }; EXPORT_SYMBOL(pv_lock_ops); + +/* + * If we're unlocking and we're leaving the lock uncontended (there's + * nobody else waiting for the lock), then we can clear the slowpath + * bits. However, we need to be careful about this because someone + * may just be entering as we leave, and enter the slowpath. + */ +void __ticket_unlock_release_slowpath(struct arch_spinlock *lock) +{ + struct arch_spinlock old, new; + + BUILD_BUG_ON(((__ticket_t)NR_CPUS) != NR_CPUS); + + old = ACCESS_ONCE(*lock); + + new = old; + new.tickets.head += TICKET_LOCK_INC; + + /* Clear the slowpath flag */ + new.tickets.tail &= ~TICKET_SLOWPATH_FLAG; + + /* + * If there's currently people waiting or someone snuck in + * since we read the lock above, then do a normal unlock and + * kick. If we managed to unlock with no queued waiters, then + * we can clear the slowpath flag. + */ + if (new.tickets.head != new.tickets.tail || + cmpxchg(&lock->head_tail, + old.head_tail, new.head_tail) != old.head_tail) { + /* still people waiting */ + __ticket_unlock_release(lock); + } + + __ticket_unlock_kick(lock, new.tickets.head); +} +EXPORT_SYMBOL(__ticket_unlock_release_slowpath); diff --git a/arch/x86/xen/spinlock.c b/arch/x86/xen/spinlock.c index b133865..4c46144 100644 --- a/arch/x86/xen/spinlock.c +++ b/arch/x86/xen/spinlock.c @@ -119,6 +119,10 @@ static void xen_lock_spinning(struct arch_spinlock *lock, unsigned want) /* Only check lock once pending cleared */ barrier(); + /* Mark entry to slowpath before doing the pickup test to make + sure we don't deadlock with an unlocker. */ + __ticket_enter_slowpath(lock); + /* check again make sure it didn't become free while we weren't looking */ if (ACCESS_ONCE(lock->tickets.head) == want) { -- 1.7.6 _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel From xen-devel-bounces@lists.xensource.com Thu Sep 01 19:33:26 2011 Return-path: Envelope-to: www-data@lists.xensource.com Delivery-date: Thu, 01 Sep 2011 19:33:26 -0700 Received: from localhost ([127.0.0.1] helo=lists.colo.xensource.com) by lists.xensource.com with esmtp (Exim 4.43) id 1QzJZM-00034U-9Y; Thu, 01 Sep 2011 19:33:24 -0700 Received: from mail216.messagelabs.com ([85.158.143.99]) by lists.xensource.com with esmtp (Exim 4.43) id 1QzJYN-0002oS-Lc for xen-devel@lists.xensource.com; Thu, 01 Sep 2011 19:32:24 -0700 X-Env-Sender: yujiageng734@gmail.com X-Msg-Ref: server-2.tower-216.messagelabs.com!1314930739!16770329!1 X-Originating-IP: [209.85.210.171] X-StarScan-Version: 6.3.6; banners=-,-,- X-VirusChecked: Checked Received: (qmail 7066 invoked from network); 2 Sep 2011 02:32:20 -0000 Received: from mail-iy0-f171.google.com (HELO mail-iy0-f171.google.com) (209.85.210.171) by server-2.tower-216.messagelabs.com with RC4-SHA encrypted SMTP; 2 Sep 2011 02:32:20 -0000 Received: by iagk10 with SMTP id k10so2989579iag.30 for ; Thu, 01 Sep 2011 19:32:19 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; bh=jK5f+BNsOkE/Z9R47ClGB90wGBrCAXFGeOb5k87kb6k=; b=yBBjZ3V1sXkWHzNJ9XVnxemq6n6W1hqgtmV797QvF64aPzW05g0GhZTmo3kSfCXzfj pHACP701IjTLOTzjGcpm3/AOTTMM5BdvNhSAaXFWkzMPLxsObIEJafU6sH/el6hJshZG DsKSiaR1lSpzxFc+F5aoEF7YnZj+JLBmnA5xw= MIME-Version: 1.0 Received: by 10.42.149.67 with SMTP id u3mr537933icv.124.1314930738736; Thu, 01 Sep 2011 19:32:18 -0700 (PDT) Received: by 10.42.239.134 with HTTP; Thu, 1 Sep 2011 19:32:18 -0700 (PDT) In-Reply-To: <20110901172728.GH3859@ocelot.phlegethon.org> References: <20110901172728.GH3859@ocelot.phlegethon.org> Date: Fri, 2 Sep 2011 10:32:18 +0800 Message-ID: Subject: Re: [Xen-devel] Re: Linux Stubdom Problem From: Jiageng Yu To: Tim Deegan Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Cc: "xen-devel@lists.xensource.com" , Konrad Rzeszutek Wilk , Stefano Stabellini , Ian Campbell , Keir Fraser , Anthony PERARD , Thibault X-BeenThere: xen-devel@lists.xensource.com X-Mailman-Version: 2.1.5 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xensource.com Errors-To: xen-devel-bounces@lists.xensource.com 2011/9/2 Tim Deegan : > At 01:12 +0800 on 02 Sep (1314925970), Jiageng Yu wrote: >> 2011/8/31 Keir Fraser : >> > On 29/08/2011 17:03, "Stefano Stabellini" >> > wrote: >> > >> >>> Oh, so it will. =C2=A0You'd need to arrange for that to be called fr= om inside >> >>> the guest; or you could implement an add_to_physmap space for it; th= at >> >>> could be called from another domain. >> >> >> >> "From inside the guest" means hvmloader? >> >> The good thing about doing it in hvmloader is that we could use the >> >> traditional PV frontend/backend mechanism to share pages. On the othe= r >> >> hand hvmloader doesn't know if we are using stubdoms at the moment an= d >> >> it would need to issue the grant table hypercall only in that case. >> >> Unless we decide to always grant the videoram to guests but it would >> >> change once again the domain to which the videoram is accounted for >> >> (dom0/stubdom rather than the guest, that is a bad thing). >> >> Also I don't like the idea of making hvmloader stubdom aware. >> > >> > I don't see a problem with it, in principle. I see hvmloader as almost= an >> > in-guest part of the toolstack. The fact that it only executes at gues= t boot >> > means it can be fairly closely tied to the toolstack version. >> > >> > =C2=A0-- Keir >> > >> > >> > >> >> Hi all, >> >> =C2=A0 =C2=A0 I report a new issue about vram mapping in linux stubdom. = I use >> the follow patch to map the mfn of stubdom into hvm guest. >> >> diff -r 0f36c2eec2e1 xen/arch/x86/mm.c >> --- a/xen/arch/x86/mm.c =C2=A0 =C2=A0 =C2=A0 Thu Jul 28 15:40:54 2011 +0= 100 >> +++ b/xen/arch/x86/mm.c =C2=A0 =C2=A0 =C2=A0 Thu Sep 01 14:52:25 2011 +0= 100 >> @@ -4663,6 +4665,14 @@ >> =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0page =3D mfn_to_page(mfn= ); >> =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0break; >> =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0} >> + =C2=A0 =C2=A0 =C2=A0 case XENMAPSPACE_mfn: >> + =C2=A0 =C2=A0 =C2=A0 { >> + =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 if(!IS_PRIV_FOR(current->dom= ain, d)) >> + =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = return -EINVAL; >> + =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 mfn =3D xatp.idx; >> + =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 page =3D mfn_to_page(mfn); >> + =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 break; >> + =C2=A0 =C2=A0 =C2=A0 } > > I would really rather not have this interface; I don't see why we can't > use grant tables for this. > Hi, In linux based stubdom case, we want to keep hvm guest and its hvmloader unaware of running on stubdom. Therefore, we do need a way to map vram pages of stubdom into guest hvm transparently. If we use the grant tables for this, the general procedure would be: 1. stubdom allocates vram pages 2. stubdom creates the grant reference for these pages and transfers the GRs to hvm guest(or hvmloader) 3. hvm guest(or hvmloader) maps these pages into its memory space using the GRs 4. stubdom and hvm guest share the same vram memory. In this procedure, the hvm guest(or hvmloader) must know it is running on stubdom. Additionally, if I modified grant table to map pages without any participation of hvm guest(or hvmloader), it will obey the design goals of grant table. So I think grant table may not be suitable for our case. Another idea is to allocate vram in hvm guest and stubdom maps vram pages into its memory space. In this scenario, I must delay the initial process of xen-fbfront in stubdom until qemu populates vram pages for hvm guest (unsing xc_domain_populate_physmap_exact()). Then, I map these pages into stubdom kernel through the function similar to privcmd_ioctl_mmap_batch(). But I would not use privcmd device. If anyone has any advice for me I'm all ears. Thanks. Jiageng Yu. > If you must do it this way, it should check that the MFN is valid and > that it's owned by the caller. > >> =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0default: >> =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0break; >> =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0} >> @@ -4693,13 +4708,17 @@ >> =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0} >> >> =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0/* Unmap from old location, if any. */ >> - =C2=A0 =C2=A0 =C2=A0 =C2=A0gpfn =3D get_gpfn_from_mfn(mfn); >> - =C2=A0 =C2=A0 =C2=A0 =C2=A0ASSERT( gpfn !=3D SHARED_M2P_ENTRY ); >> - =C2=A0 =C2=A0 =C2=A0 =C2=A0if ( gpfn !=3D INVALID_M2P_ENTRY ) >> - =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0guest_physmap_remove_page(d, = gpfn, mfn, 0); >> + =C2=A0 =C2=A0 =C2=A0if(xatp.space!=3DXENMAPSPACE_mfn) { >> + =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 gpfn =3D get_gpfn_from_mfn(mfn); >> + =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 ASSERT( gpfn !=3D SHARED_M2P_ENTRY = ); >> + =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 if ( gpfn !=3D INVALID_M2P_ENTRY ) >> + =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 guest_physmap_remove_= page(d, gpfn, mfn, 0); >> + =C2=A0 =C2=A0 =C2=A0} > > Why did you make this change? > >> >> =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0/* Map at new location. */ >> =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0rc =3D guest_physmap_add_page(d, xatp.= gpfn, mfn, 0); >> diff -r 0f36c2eec2e1 xen/include/public/memory.h >> --- a/xen/include/public/memory.h =C2=A0 =C2=A0 Thu Jul 28 15:40:54 2011= +0100 >> +++ b/xen/include/public/memory.h =C2=A0 =C2=A0 Thu Sep 01 14:52:25 2011= +0100 >> @@ -212,6 +212,7 @@ >> =C2=A0#define XENMAPSPACE_shared_info 0 /* shared info page */ >> =C2=A0#define XENMAPSPACE_grant_table 1 /* grant table page */ >> =C2=A0#define XENMAPSPACE_gmfn =C2=A0 =C2=A0 =C2=A0 =C2=A02 /* GMFN */ >> +#define XENMAPSPACE_mfn =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A03 /* MFN =C2= =A0*/ >> =C2=A0 =C2=A0 =C2=A0unsigned int space; >> >> =C2=A0#define XENMAPIDX_grant_table_status 0x80000000 >> >> >> I got error at: >> >> arch_memory_op() >> =C2=A0 =C2=A0-->case XENMEM_add_to_physmap: >> =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0-->if ( page ) >> =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 -->put_page(page); >> =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 --= >free_domheap_page(page); >> =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0-->BUG_ON((pg[i].u.inuse.type_info & >> PGT_count_mask) !=3D 0); >> >> In my case, pg[i].u.inuse.type_info & PGT_count_mask =3D1. > > OK, so you've dropped the last untyped refcount on a page which still > has a type count. =C2=A0That means the reference counting has got messed = up > somewhere. > >> Actually, in the linux based stubdom case, I need to keep these pages >> of vram mapped in qemu of stubdom. But it seems that granting pages >> implies having the pages unmapped in the process that grants them. >> Maybe the grant table could not solve the vram mapping problem. > > But this patch doesn't use the grant tables at all. > > Tim. > > -- > _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel From xen-devel-bounces@lists.xensource.com Thu Sep 01 20:38:49 2011 Return-path: Envelope-to: www-data@lists.xensource.com Delivery-date: Thu, 01 Sep 2011 20:38:49 -0700 Received: from localhost ([127.0.0.1] helo=lists.colo.xensource.com) by lists.xensource.com with esmtp (Exim 4.43) id 1QzKad-0004aL-Q4; Thu, 01 Sep 2011 20:38:47 -0700 Received: from mail216.messagelabs.com ([85.158.143.99]) by lists.xensource.com with smtp (Exim 4.43) id 1QzKZt-0004NX-UN for xen-devel@lists.xensource.com; Thu, 01 Sep 2011 20:38:02 -0700 X-Env-Sender: Ian.Jackson@eu.citrix.com X-Msg-Ref: server-3.tower-216.messagelabs.com!1314934678!15748286!1 X-Originating-IP: [62.200.22.115] X-StarScan-Version: 6.3.6; banners=-,-,- X-VirusChecked: Checked Received: (qmail 23117 invoked from network); 2 Sep 2011 03:37:58 -0000 Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115) by server-3.tower-216.messagelabs.com with SMTP; 2 Sep 2011 03:37:58 -0000 X-IronPort-AV: E=Sophos;i="4.68,317,1312156800"; d="scan'208";a="7563990" Received: from lonpmailmx01.citrite.net ([10.30.203.162]) by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5; 02 Sep 2011 03:37:58 +0000 Received: from woking.xci-test.com (10.80.248.135) by smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id 8.3.137.0; Fri, 2 Sep 2011 04:37:58 +0100 Received: from osstest by woking.xci-test.com with local (Exim 4.69) (envelope-from ) id 1QzKZp-0003P7-LZ; Fri, 02 Sep 2011 04:37:57 +0100 To: xen-devel@lists.xensource.com Message-ID: From: xen.org Date: Fri, 2 Sep 2011 04:37:57 +0100 MIME-Version: 1.0 Content-Type: text/plain Cc: ian.jackson@eu.citrix.com Subject: [Xen-devel] [xen-unstable test] 8822: regressions - FAIL X-BeenThere: xen-devel@lists.xensource.com X-Mailman-Version: 2.1.5 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xensource.com Errors-To: xen-devel-bounces@lists.xensource.com flight 8822 xen-unstable real [real] http://www.chiark.greenend.org.uk/~xensrcts/logs/8822/ Regressions :-( Tests which did not succeed and are blocking: test-i386-i386-win 14 guest-start.2 fail REGR. vs. 8769 test-amd64-amd64-xl-sedf 7 debian-install fail in 8814 REGR. vs. 8769 Tests which are failing intermittently (not blocking): test-amd64-amd64-xl-sedf 5 xen-boot fail pass in 8814 test-i386-i386-win 8 guest-saverestore fail in 8814 pass in 8822 Tests which did not succeed, but are not blocking, including regressions (tests previously passed) regarded as allowable: test-amd64-amd64-xl-pcipt-intel 9 guest-start fail never pass test-amd64-i386-rhel6hvm-intel 9 guest-start.2 fail never pass test-amd64-i386-win-vcpus1 16 leak-check/check fail never pass test-amd64-i386-rhel6hvm-amd 9 guest-start.2 fail never pass test-amd64-i386-win 16 leak-check/check fail never pass test-amd64-amd64-win 16 leak-check/check fail never pass test-amd64-amd64-xl-win 13 guest-stop fail never pass test-i386-i386-xl-win 13 guest-stop fail never pass test-amd64-i386-xl-win-vcpus1 13 guest-stop fail never pass version targeted for testing: xen a6a5bda3c962 baseline version: xen ac9aa65050e9 ------------------------------------------------------------ People who touched revisions under test: Andrew Cooper Christoph Egger Dietmar Hahn Ian Campbell Ian Jackson Keir Fraser Kevin Tian Laszlo Ersek Olaf Hering Stefano Stabellini Tim Deegan ------------------------------------------------------------ jobs: build-amd64 pass build-i386 pass build-amd64-oldkern pass build-i386-oldkern pass build-amd64-pvops pass build-i386-pvops pass test-amd64-amd64-xl pass test-amd64-i386-xl pass test-i386-i386-xl pass test-amd64-i386-rhel6hvm-amd fail test-amd64-i386-xl-credit2 pass test-amd64-amd64-xl-pcipt-intel fail test-amd64-i386-rhel6hvm-intel fail test-amd64-i386-xl-multivcpu pass test-amd64-amd64-pair pass test-amd64-i386-pair pass test-i386-i386-pair pass test-amd64-amd64-pv pass test-amd64-i386-pv pass test-i386-i386-pv pass test-amd64-amd64-xl-sedf fail test-amd64-i386-win-vcpus1 fail test-amd64-i386-xl-win-vcpus1 fail test-amd64-amd64-win fail test-amd64-i386-win fail test-i386-i386-win fail test-amd64-amd64-xl-win fail test-i386-i386-xl-win fail ------------------------------------------------------------ sg-report-flight on woking.cam.xci-test.com logs: /home/xc_osstest/logs images: /home/xc_osstest/images Logs, config files, etc. are available at http://www.chiark.greenend.org.uk/~xensrcts/logs Test harness code can be found at http://xenbits.xensource.com/gitweb?p=osstest.git;a=summary Not pushing. ------------------------------------------------------------ changeset: 23810:a6a5bda3c962 tag: tip user: Ian Campbell date: Thu Sep 01 17:46:43 2011 +0100 xen/x86: only support >128 CPUs on x86_64 32 bit cannot cope with 256 cpus and hits: /* At least half the ioremap space should be available to us. */ BUILD_BUG_ON(IOREMAP_VIRT_START + (IOREMAP_MBYTES << 19) >= FIXADDR_START); Signed-off-by: Ian Campbell changeset: 23809:85b29185c911 user: Tim Deegan date: Thu Sep 01 09:39:25 2011 +0100 x86/mm: use defines for page sizes rather hardcoding them. Signed-off-by: Christoph Egger Acked-by: Tim Deegan Committed-by: Tim Deegan changeset: 23808:4a4882df5649 user: Stefano Stabellini date: Wed Aug 31 15:23:49 2011 +0100 xen: get_free_pirq: make sure that the returned pirq is allocated Signed-off-by: Stefano Stabellini changeset: 23807:2297b90a6a7b user: Stefano Stabellini date: Wed Aug 31 15:23:34 2011 +0100 xen: __hvm_pci_intx_assert should check for gsis remapped onto pirqs If the isa irq corresponding to a particular gsi is disabled while the gsi is enabled, __hvm_pci_intx_assert will always inject the gsi through the violapic, even if the gsi has been remapped onto a pirq. This patch makes sure that even in this case we inject the notification appropriately. Signed-off-by: Stefano Stabellini changeset: 23806:4226ea1785b5 user: Stefano Stabellini date: Wed Aug 31 15:23:12 2011 +0100 xen: fix hvm_domain_use_pirq's behavior hvm_domain_use_pirq should return true when the guest is using a certain pirq, no matter if the corresponding event channel is currently enabled or disabled. As an additional complication, qemu is going to request pirqs for passthrough devices even for Xen unaware HVM guests, so we need to wait for an event channel to be connected before considering the pirq of a passthrough device as "in use". Signed-off-by: Stefano Stabellini changeset: 23805:7048810180de user: Andrew Cooper date: Wed Aug 31 15:19:24 2011 +0100 IRQ: manually EOI migrating line interrupts When migrating IO-APIC line level interrupts between PCPUs, the migration code rewrites the IO-APIC entry to point to the new CPU/Vector before EOI'ing it. The EOI process says that EOI'ing the Local APIC will cause a broadcast with the vector number, which the IO-APIC must listen to to clear the IRR and Status bits. In the case of migrating, the IO-APIC has already been reprogrammed so the EOI broadcast with the old vector fails to match the new vector, leaving the IO-APIC with an outstanding vector, preventing any more use of that line interrupt. This causes a lockup especially when your root device is using PCI INTA (megaraid_sas driver *ehem*) However, the problem is mostly hidden because send_cleanup_vector() causes a cleanup of all moving vectors on the current PCPU in such a way which does not cause the problem, and if the problem has occured, the writes it makes to the IO-APIC clears the IRR and Status bits which unlocks the problem. This fix is distinctly a temporary hack, waiting on a cleanup of the irq code. It checks for the edge case where we have moved the irq, and manually EOI's the old vector with the IO-APIC which correctly clears the IRR and Status bits. Also, it protects the code which updates irq_cfg by disabling interrupts. Signed-off-by: Andrew Cooper changeset: 23804:42d76c68b2bf user: Kevin Tian date: Wed Aug 31 15:18:23 2011 +0100 x86: add irq count for IPIs such count is useful to assist decision make in cpuidle governor, while w/o this patch only device interrupts through do_IRQ is currently counted. Signed-off-by: Kevin Tian changeset: 23803:51983821efa4 user: Dietmar Hahn date: Wed Aug 31 15:17:45 2011 +0100 vpmu: Add processors Westmere E7-8837 and SandyBridge i5-2500 to the vpmu list Signed-off-by: Dietmar Hahn changeset: 23802:bb9b81008733 user: Laszlo Ersek date: Wed Aug 31 15:16:14 2011 +0100 x86: Increase the default NR_CPUS to 256 Changeset 21012:ef845a385014 bumped the default to 128 about one and a half years ago. Increase it now to 256, as systems with eg. 160 logical CPUs are becoming (have become) common. Signed-off-by: Laszlo Ersek changeset: 23801:d54cfae72cd1 user: Christoph Egger date: Wed Aug 31 15:15:41 2011 +0100 nestedsvm: VMRUN doesn't use nextrip VMRUN does not use nextrip. So remove pointless assignment. Signed-off-by: Christoph Egger changeset: 23800:72edc40e2942 user: Keir Fraser date: Wed Aug 31 15:14:49 2011 +0100 x86-64: Fix off-by-one error in __addr_ok() macro Signed-off-by: Laszlo Ersek Signed-off-by: Keir Fraser changeset: 23799:ac9aa65050e9 parent: 23798:469aa1fbd843 parent: 23797:2c687e70a343 user: Ian Jackson date: Tue Aug 30 11:46:58 2011 +0100 Merge ======================================== commit cd776ee9408ff127f934a707c1a339ee600bc127 Author: Ian Jackson Date: Tue Jun 28 13:50:53 2011 +0100 qemu-char.c: fix incorrect CONFIG_STUBDOM handling qemu-char.c:1123:7: warning: "CONFIG_STUBDOM" is not defined [-Wundef] Signed-off-by: Olaf Hering Acked-by: Ian Jackson _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel From xen-devel-bounces@lists.xensource.com Thu Sep 01 23:31:10 2011 Return-path: Envelope-to: www-data@lists.xensource.com Delivery-date: Thu, 01 Sep 2011 23:31:10 -0700 Received: from localhost ([127.0.0.1] helo=lists.colo.xensource.com) by lists.xensource.com with esmtp (Exim 4.43) id 1QzNHR-0008El-L9; Thu, 01 Sep 2011 23:31:10 -0700 Received: from mail174.messagelabs.com ([85.158.138.51]) by lists.xensource.com with esmtp (Exim 4.43) id 1QzNGb-000824-3x for xen-devel@lists.xensource.com; Thu, 01 Sep 2011 23:30:18 -0700 X-Env-Sender: lidongyang@novell.com X-Msg-Ref: server-10.tower-174.messagelabs.com!1314945011!29963088!1 X-Originating-IP: [137.65.250.26] X-StarScan-Version: 6.3.6; banners=-,-,- X-VirusChecked: Checked Received: (qmail 32187 invoked from network); 2 Sep 2011 06:30:13 -0000 Received: from victor.provo.novell.com (HELO victor.provo.novell.com) (137.65.250.26) by server-10.tower-174.messagelabs.com with DHE-RSA-AES256-SHA encrypted SMTP; 2 Sep 2011 06:30:13 -0000 Received: from mail-fx0-f43.google.com (prv-ext-foundry1int.gns.novell.com [137.65.251.240]) by victor.provo.novell.com with ESMTP (TLS encrypted); Fri, 02 Sep 2011 00:30:06 -0600 Received: by fxg17 with SMTP id 17so1631253fxg.30 for ; Thu, 01 Sep 2011 23:30:03 -0700 (PDT) MIME-Version: 1.0 Received: by 10.223.87.204 with SMTP id x12mr1186387fal.27.1314945003356; Thu, 01 Sep 2011 23:30:03 -0700 (PDT) Received: by 10.152.22.33 with HTTP; Thu, 1 Sep 2011 23:30:03 -0700 (PDT) In-Reply-To: <20110901152534.GA6965@dumpdata.com> References: <20110901152534.GA6965@dumpdata.com> Date: Fri, 2 Sep 2011 14:30:03 +0800 Message-ID: From: Li Dongyang To: Konrad Rzeszutek Wilk Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: xen-devel@lists.xensource.com, owen.smith@citrix.com, JBeulich@novell.com Subject: [Xen-devel] Re: [PATCH V4 2/3] xen-blkfront: teach blkfront driver to handle discard requests X-BeenThere: xen-devel@lists.xensource.com X-Mailman-Version: 2.1.5 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xensource.com Errors-To: xen-devel-bounces@lists.xensource.com On Thu, Sep 1, 2011 at 11:25 PM, Konrad Rzeszutek Wilk wrote: > On Thu, Sep 01, 2011 at 06:39:09PM +0800, Li Dongyang wrote: >> The blkfront driver now will read discard related nodes from xenstore, >> and set up the request queue, then we can forward the >> discard requests to backend driver. > > > A better description is as follow: > > xen-blkfront: Handle discard requests. > > =A0 =A0If the backend advertises 'feature-discard', then interrogate > =A0 =A0the backend for alignment, granularity, and max discard block size= . > =A0 =A0Setup the request queue with the appropiate values and send the > =A0 =A0discard operation as required. > thanks for the description, way better than mine :-) > >> >> Signed-off-by: Li Dongyang >> --- >> =A0drivers/block/xen-blkfront.c | =A0111 +++++++++++++++++++++++++++++++= ++--------- >> =A01 files changed, 88 insertions(+), 23 deletions(-) >> >> diff --git a/drivers/block/xen-blkfront.c b/drivers/block/xen-blkfront.c >> index 9ea8c25..86e2c63 100644 >> --- a/drivers/block/xen-blkfront.c >> +++ b/drivers/block/xen-blkfront.c >> @@ -98,6 +98,9 @@ struct blkfront_info >> =A0 =A0 =A0 unsigned long shadow_free; >> =A0 =A0 =A0 unsigned int feature_flush; >> =A0 =A0 =A0 unsigned int flush_op; >> + =A0 =A0 unsigned int feature_discard; >> + =A0 =A0 unsigned int discard_granularity; >> + =A0 =A0 unsigned int discard_alignment; >> =A0 =A0 =A0 int is_ready; >> =A0}; >> >> @@ -302,29 +305,36 @@ static int blkif_queue_request(struct request *req= ) >> =A0 =A0 =A0 =A0 =A0 =A0 =A0 ring_req->operation =3D info->flush_op; >> =A0 =A0 =A0 } >> >> - =A0 =A0 ring_req->nr_segments =3D blk_rq_map_sg(req->q, req, info->sg)= ; >> - =A0 =A0 BUG_ON(ring_req->nr_segments > BLKIF_MAX_SEGMENTS_PER_REQUEST)= ; >> + =A0 =A0 if (unlikely(req->cmd_flags & REQ_DISCARD)) { >> + =A0 =A0 =A0 =A0 =A0 =A0 /* id, sector_number and handle are set above.= */ >> + =A0 =A0 =A0 =A0 =A0 =A0 ring_req->operation =3D BLKIF_OP_DISCARD; >> + =A0 =A0 =A0 =A0 =A0 =A0 ring_req->nr_segments =3D 0; >> + =A0 =A0 =A0 =A0 =A0 =A0 ring_req->u.discard.nr_sectors =3D blk_rq_sect= ors(req); >> + =A0 =A0 } else { >> + =A0 =A0 =A0 =A0 =A0 =A0 ring_req->nr_segments =3D blk_rq_map_sg(req->q= , req, info->sg); >> + =A0 =A0 =A0 =A0 =A0 =A0 BUG_ON(ring_req->nr_segments > BLKIF_MAX_SEGME= NTS_PER_REQUEST); >> >> - =A0 =A0 for_each_sg(info->sg, sg, ring_req->nr_segments, i) { >> - =A0 =A0 =A0 =A0 =A0 =A0 buffer_mfn =3D pfn_to_mfn(page_to_pfn(sg_page(= sg))); >> - =A0 =A0 =A0 =A0 =A0 =A0 fsect =3D sg->offset >> 9; >> - =A0 =A0 =A0 =A0 =A0 =A0 lsect =3D fsect + (sg->length >> 9) - 1; >> - =A0 =A0 =A0 =A0 =A0 =A0 /* install a grant reference. */ >> - =A0 =A0 =A0 =A0 =A0 =A0 ref =3D gnttab_claim_grant_reference(&gref_hea= d); >> - =A0 =A0 =A0 =A0 =A0 =A0 BUG_ON(ref =3D=3D -ENOSPC); >> + =A0 =A0 =A0 =A0 =A0 =A0 for_each_sg(info->sg, sg, ring_req->nr_segment= s, i) { >> + =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 buffer_mfn =3D pfn_to_mfn(page= _to_pfn(sg_page(sg))); >> + =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 fsect =3D sg->offset >> 9; >> + =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 lsect =3D fsect + (sg->length = >> 9) - 1; >> + =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 /* install a grant reference. = */ >> + =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 ref =3D gnttab_claim_grant_ref= erence(&gref_head); >> + =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 BUG_ON(ref =3D=3D -ENOSPC); >> >> - =A0 =A0 =A0 =A0 =A0 =A0 gnttab_grant_foreign_access_ref( >> - =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 ref, >> - =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 info->xbdev->o= therend_id, >> - =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 buffer_mfn, >> - =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 rq_data_dir(re= q) ); >> - >> - =A0 =A0 =A0 =A0 =A0 =A0 info->shadow[id].frame[i] =3D mfn_to_pfn(buffe= r_mfn); >> - =A0 =A0 =A0 =A0 =A0 =A0 ring_req->u.rw.seg[i] =3D >> - =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 (struct blkif_= request_segment) { >> - =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 = =A0 .gref =A0 =A0 =A0 =3D ref, >> - =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 = =A0 .first_sect =3D fsect, >> - =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 = =A0 .last_sect =A0=3D lsect }; >> + =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 gnttab_grant_foreign_access_re= f( >> + =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 = =A0 ref, >> + =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 = =A0 info->xbdev->otherend_id, >> + =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 = =A0 buffer_mfn, >> + =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 = =A0 rq_data_dir(req)); >> + >> + =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 info->shadow[id].frame[i] =3D = mfn_to_pfn(buffer_mfn); >> + =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 ring_req->u.rw.seg[i] =3D >> + =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 = =A0 (struct blkif_request_segment) { >> + =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 = =A0 =A0 =A0 =A0 =A0 .gref =A0 =A0 =A0 =3D ref, >> + =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 = =A0 =A0 =A0 =A0 =A0 .first_sect =3D fsect, >> + =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 = =A0 =A0 =A0 =A0 =A0 .last_sect =A0=3D lsect }; >> + =A0 =A0 =A0 =A0 =A0 =A0 } >> =A0 =A0 =A0 } >> >> =A0 =A0 =A0 info->ring.req_prod_pvt++; >> @@ -399,6 +409,7 @@ wait: >> =A0static int xlvbd_init_blk_queue(struct gendisk *gd, u16 sector_size) >> =A0{ >> =A0 =A0 =A0 struct request_queue *rq; >> + =A0 =A0 struct blkfront_info *info =3D gd->private_data; >> >> =A0 =A0 =A0 rq =3D blk_init_queue(do_blkif_request, &blkif_io_lock); >> =A0 =A0 =A0 if (rq =3D=3D NULL) >> @@ -406,6 +417,13 @@ static int xlvbd_init_blk_queue(struct gendisk *gd,= u16 sector_size) >> >> =A0 =A0 =A0 queue_flag_set_unlocked(QUEUE_FLAG_VIRT, rq); >> >> + =A0 =A0 if (info->feature_discard) { >> + =A0 =A0 =A0 =A0 =A0 =A0 queue_flag_set_unlocked(QUEUE_FLAG_DISCARD, rq= ); >> + =A0 =A0 =A0 =A0 =A0 =A0 blk_queue_max_discard_sectors(rq, get_capacity= (gd)); > > This is not correct. I took a look at the SCSI support for this > ('sd_config_discard') and if you look there carefully you will see that > the value can be 64KB for example. well I don't think so, max_discard_sectors are used to split the bio, make them not to exceed the max_discard_sectors, see blkdev_issue_discard, and that's fine if we use the capacity as max_discard_sectors in guest: for file backend, there's no need for max_discard_sectors, and for phy backend, we'll make the blkfront sent out a single big discard request, and when we deal with that in blkback by calling blkdev_issue_discard, the real max_discard_sectors from phy dev will be used, and take care of splitting bios, Thanks > > You need to provide a mechanism similar to 'discard-*' to fetch that data > from the backend. > >> + =A0 =A0 =A0 =A0 =A0 =A0 rq->limits.discard_granularity =3D info->disca= rd_granularity; >> + =A0 =A0 =A0 =A0 =A0 =A0 rq->limits.discard_alignment =3D info->discard= _alignment; >> + =A0 =A0 } >> + >> =A0 =A0 =A0 /* Hard sector size and max sectors impersonate the equiv. h= ardware. */ >> =A0 =A0 =A0 blk_queue_logical_block_size(rq, sector_size); >> =A0 =A0 =A0 blk_queue_max_hw_sectors(rq, 512); >> @@ -722,6 +740,19 @@ static irqreturn_t blkif_interrupt(int irq, void *d= ev_id) >> >> =A0 =A0 =A0 =A0 =A0 =A0 =A0 error =3D (bret->status =3D=3D BLKIF_RSP_OKA= Y) ? 0 : -EIO; >> =A0 =A0 =A0 =A0 =A0 =A0 =A0 switch (bret->operation) { >> + =A0 =A0 =A0 =A0 =A0 =A0 case BLKIF_OP_DISCARD: >> + =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 if (unlikely(bret->status =3D= =3D BLKIF_RSP_EOPNOTSUPP)) { >> + =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 struct request= _queue *rq =3D info->rq; >> + =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 printk(KERN_WA= RNING "blkfront: %s: discard op failed\n", >> + =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 = =A0 =A0 =A0info->gd->disk_name); >> + =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 error =3D -EOP= NOTSUPP; >> + =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 info->feature_= discard =3D 0; >> + =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 spin_lock(rq->= queue_lock); >> + =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 queue_flag_cle= ar(QUEUE_FLAG_DISCARD, rq); >> + =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 spin_unlock(rq= ->queue_lock); >> + =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 } >> + =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 __blk_end_request_all(req, err= or); >> + =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 break; >> =A0 =A0 =A0 =A0 =A0 =A0 =A0 case BLKIF_OP_FLUSH_DISKCACHE: >> =A0 =A0 =A0 =A0 =A0 =A0 =A0 case BLKIF_OP_WRITE_BARRIER: >> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 if (unlikely(bret->status = =3D=3D BLKIF_RSP_EOPNOTSUPP)) { >> @@ -1098,6 +1129,33 @@ blkfront_closing(struct blkfront_info *info) >> =A0 =A0 =A0 bdput(bdev); >> =A0} >> >> +static void blkfront_setup_discard(struct blkfront_info *info) >> +{ >> + =A0 =A0 int err; >> + =A0 =A0 char *type; >> + =A0 =A0 unsigned int discard_granularity; >> + =A0 =A0 unsigned int discard_alignment; >> + >> + =A0 =A0 type =3D xenbus_read(XBT_NIL, info->xbdev->otherend, "type", N= ULL); >> + =A0 =A0 if (IS_ERR(type)) >> + =A0 =A0 =A0 =A0 =A0 =A0 return; >> + >> + =A0 =A0 if (strncmp(type, "phy", 3) =3D=3D 0) { >> + =A0 =A0 =A0 =A0 =A0 =A0 err =3D xenbus_gather(XBT_NIL, info->xbdev->ot= herend, >> + =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 "discard-granularity", "%u", &= discard_granularity, >> + =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 "discard-alignment", "%u", &di= scard_alignment, >> + =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 NULL); >> + =A0 =A0 =A0 =A0 =A0 =A0 if (!err) { >> + =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 info->feature_discard =3D 1; >> + =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 info->discard_granularity =3D = discard_granularity; >> + =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 info->discard_alignment =3D di= scard_alignment; >> + =A0 =A0 =A0 =A0 =A0 =A0 } >> + =A0 =A0 } else if (strncmp(type, "file", 4) =3D=3D 0) >> + =A0 =A0 =A0 =A0 =A0 =A0 info->feature_discard =3D 1; >> + >> + =A0 =A0 kfree(type); >> +} >> + >> =A0/* >> =A0 * Invoked when the backend is finally 'ready' (and has told produced >> =A0 * the details about the physical device - #sectors, size, etc). >> @@ -1108,7 +1166,7 @@ static void blkfront_connect(struct blkfront_info = *info) >> =A0 =A0 =A0 unsigned long sector_size; >> =A0 =A0 =A0 unsigned int binfo; >> =A0 =A0 =A0 int err; >> - =A0 =A0 int barrier, flush; >> + =A0 =A0 int barrier, flush, discard; >> >> =A0 =A0 =A0 switch (info->connected) { >> =A0 =A0 =A0 case BLKIF_STATE_CONNECTED: >> @@ -1178,7 +1236,14 @@ static void blkfront_connect(struct blkfront_info= *info) >> =A0 =A0 =A0 =A0 =A0 =A0 =A0 info->feature_flush =3D REQ_FLUSH; >> =A0 =A0 =A0 =A0 =A0 =A0 =A0 info->flush_op =3D BLKIF_OP_FLUSH_DISKCACHE; >> =A0 =A0 =A0 } >> - >> + >> + =A0 =A0 err =3D xenbus_gather(XBT_NIL, info->xbdev->otherend, >> + =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 "feature-discard", "%d= ", &discard, >> + =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 NULL); >> + >> + =A0 =A0 if (!err && discard) >> + =A0 =A0 =A0 =A0 =A0 =A0 blkfront_setup_discard(info); >> + >> =A0 =A0 =A0 err =3D xlvbd_alloc_gendisk(sectors, info, binfo, sector_siz= e); >> =A0 =A0 =A0 if (err) { >> =A0 =A0 =A0 =A0 =A0 =A0 =A0 xenbus_dev_fatal(info->xbdev, err, "xlvbd_ad= d at %s", >> -- >> 1.7.6 > _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel From xen-devel-bounces@lists.xensource.com Fri Sep 02 00:12:55 2011 Return-path: Envelope-to: www-data@lists.xensource.com Delivery-date: Fri, 02 Sep 2011 00:12:55 -0700 Received: from localhost ([127.0.0.1] helo=lists.colo.xensource.com) by lists.xensource.com with esmtp (Exim 4.43) id 1QzNvq-0002Mj-Sm; Fri, 02 Sep 2011 00:12:54 -0700 Received: from mail21.messagelabs.com ([85.158.143.35]) by lists.xensource.com with smtp (Exim 4.43) id 1QzNv0-00029v-Vc for xen-devel@lists.xensource.com; Fri, 02 Sep 2011 00:12:03 -0700 X-Env-Sender: Ian.Campbell@eu.citrix.com X-Msg-Ref: server-14.tower-21.messagelabs.com!1314947512!58056855!1 X-Originating-IP: [62.200.22.115] X-StarScan-Version: 6.3.6; banners=-,-,- X-VirusChecked: Checked Received: (qmail 5123 invoked from network); 2 Sep 2011 07:11:52 -0000 Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115) by server-14.tower-21.messagelabs.com with SMTP; 2 Sep 2011 07:11:52 -0000 X-IronPort-AV: E=Sophos;i="4.68,317,1312156800"; d="scan'208";a="7565284" Received: from lonpmailmx01.citrite.net ([10.30.203.162]) by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5; 02 Sep 2011 07:11:59 +0000 Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net (10.30.203.162) with Microsoft SMTP Server id 8.3.137.0; Fri, 2 Sep 2011 08:11:59 +0100 Subject: Re: [Xen-devel] [xen-unstable bisection] complete test-amd64-i386-rhel6hvm-intel From: Ian Campbell To: Laszlo Ersek In-Reply-To: <4E5FBF5F.7030600@redhat.com> References: <20063.45607.355820.209628@mariner.uk.xensource.com> <4E5FBF5F.7030600@redhat.com> Content-Type: text/plain; charset="UTF-8" Organization: Citrix Systems, Inc. Date: Fri, 2 Sep 2011 08:11:58 +0100 Message-ID: <1314947518.28989.150.camel@zakaz.uk.xensource.com> MIME-Version: 1.0 X-Mailer: Evolution 2.32.3 Content-Transfer-Encoding: 7bit Cc: Drew Jones , "xen-devel@lists.xensource.com" , "keir@xen.org" , Stefano Stabellini , Ian Jackson , Paolo Bonzini , Igor Mammedov X-BeenThere: xen-devel@lists.xensource.com X-Mailman-Version: 2.1.5 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xensource.com Errors-To: xen-devel-bounces@lists.xensource.com On Thu, 2011-09-01 at 18:22 +0100, Laszlo Ersek wrote: > On 09/01/11 18:26, Ian Jackson wrote: > > >> job test-amd64-i386-rhel6hvm-intel > > >> changeset: 23802:bb9b81008733 > >> user: Laszlo Ersek > >> date: Wed Aug 31 15:16:14 2011 +0100 > >> > >> x86: Increase the default NR_CPUS to 256 > >> > >> Changeset 21012:ef845a385014 bumped the default to 128 about one and a > >> half years ago. Increase it now to 256, as systems with eg. 160 > >> logical CPUs are becoming (have become) common. > >> > >> Signed-off-by: Laszlo Ersek > > > > My bisector is pretty reliable nowadays. Looking at the revision > > graph it tested before/after/before/after/before/after, ie three times > > each on the same host. > > > > This change looks innocuous enough TBH. Is there any way this change > > could have broken a PV-on-HVM guest ? Note that RHEL6, which is what > > this is testing, seems to generally be full of bugs. > > > > If the problem is indeed a bug in the current RHEL6 then I will add > > this test to the "do not care" list. > > In what way was the guest broken? How many physical cores/threads was > the hypervisor running on? This is just confusion over the way the failure is reported. The bisector was running the test-amd64-i386-rhel6hvm-intel job but it was actually failing at the build/install Xen stage and not getting anywhere near actually testing rhel6hvm. This confused me (and apparently IanJ) too. For future reference the thing to look at is the report's header which in this case said: job test-amd64-i386-rhel6hvm-intel test xen-install i.e. the xen-install stage failed while running the test-amd64-i386-rhel6hvm-intel sequence. The selection of the test-amd64-i386-rhel6hvm-intel sequence for bisecting is apparently just an arbitrary choice out of all the sequences which suffered this failure. The actual fix for this issue was identified and posted in the "8803: regressions - FAIL" thread. Ian. _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel From xen-devel-bounces@lists.xensource.com Fri Sep 02 00:18:35 2011 Return-path: Envelope-to: www-data@lists.xensource.com Delivery-date: Fri, 02 Sep 2011 00:18:35 -0700 Received: from localhost ([127.0.0.1] helo=lists.colo.xensource.com) by lists.xensource.com with esmtp (Exim 4.43) id 1QzO1L-0002vO-9Q; Fri, 02 Sep 2011 00:18:35 -0700 Received: from mail182.messagelabs.com ([85.158.139.83]) by lists.xensource.com with smtp (Exim 4.43) id 1QzO0l-0002iQ-Ic for xen-devel@lists.xensource.com; Fri, 02 Sep 2011 00:18:00 -0700 X-Env-Sender: Ian.Campbell@eu.citrix.com X-Msg-Ref: server-6.tower-182.messagelabs.com!1314947876!16756060!1 X-Originating-IP: [62.200.22.115] X-StarScan-Version: 6.3.6; banners=-,-,- X-VirusChecked: Checked Received: (qmail 16447 invoked from network); 2 Sep 2011 07:17:56 -0000 Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115) by server-6.tower-182.messagelabs.com with SMTP; 2 Sep 2011 07:17:56 -0000 X-IronPort-AV: E=Sophos;i="4.68,317,1312156800"; d="scan'208";a="7565376" Received: from lonpmailmx01.citrite.net ([10.30.203.162]) by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5; 02 Sep 2011 07:17:56 +0000 Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net (10.30.203.162) with Microsoft SMTP Server id 8.3.137.0; Fri, 2 Sep 2011 08:17:56 +0100 Subject: Re: [Xen-devel] Kernel bug from 3.0 (was phy disks and vifs timing out in DomU) From: Ian Campbell To: Jeremy Fitzhardinge In-Reply-To: <4E5FEC71.4090504@goop.org> References: <4E31820C.5030200@overnetdata.com> <1311870512.24408.153.camel@cthulhu.hellion.org.uk> <4E3266DE.9000606@overnetdata.com> <20110803152841.GA2860@dumpdata.com> <4E4E3957.1040007@overnetdata.com> <20110819125615.GA26558@dumpdata.com> <4E56B132.9050708@overnetdata.com> <20110826142606.GA25511@dumpdata.com> <20110826144438.GA24836@dumpdata.com> <4E5E6843.7050206@citrix.com> <20110831170711.GB13642@dumpdata.com> <1314862972.28989.74.camel@zakaz.uk.xensource.com> <4E5FC197.7040004@goop.org> <1314904905.19389.28.camel@dagon.hellion.org.uk> <4E5FEC71.4090504@goop.org> Content-Type: text/plain; charset="UTF-8" Organization: Citrix Systems, Inc. Date: Fri, 2 Sep 2011 08:17:55 +0100 Message-ID: <1314947875.28989.155.camel@zakaz.uk.xensource.com> MIME-Version: 1.0 X-Mailer: Evolution 2.32.3 Content-Transfer-Encoding: 7bit Cc: "xen-devel@lists.xensource.com" , Keir Fraser , Anthony Wright , Konrad Rzeszutek Wilk , David Vrabel , Todd Deshane X-BeenThere: xen-devel@lists.xensource.com X-Mailman-Version: 2.1.5 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xensource.com Errors-To: xen-devel-bounces@lists.xensource.com On Thu, 2011-09-01 at 21:34 +0100, Jeremy Fitzhardinge wrote: > On 09/01/2011 12:21 PM, Ian Campbell wrote: > > On Thu, 2011-09-01 at 18:32 +0100, Jeremy Fitzhardinge wrote: > >> On 09/01/2011 12:42 AM, Ian Campbell wrote: > >>> On Wed, 2011-08-31 at 18:07 +0100, Konrad Rzeszutek Wilk wrote: > >>>> On Wed, Aug 31, 2011 at 05:58:43PM +0100, David Vrabel wrote: > >>>>> On 26/08/11 15:44, Konrad Rzeszutek Wilk wrote: > >>>>>> So while I am still looking at the hypervisor code to figure out why > >>>>>> it would give me [when trying to map a grant page]: > >>>>>> > >>>>>> (XEN) mm.c:3846:d0 Could not find L1 PTE for address fbb42000 > >>>>> It is failing in guest_map_l1e() because the page for the vmalloc'd > >>>>> virtual address PTEs is not present. > >>>>> > >>>>> The test that fails is: > >>>>> > >>>>> (l2e_get_flags(l2e) & (_PAGE_PRESENT | _PAGE_PSE)) != _PAGE_PRESENT > >>>>> > >>>>> I think this is because the GNTTABOP_map_grant_ref hypercall is done > >>>>> when task->active_mm != &init_mm and alloc_vm_area() only adds PTEs into > >>>>> init_mm so when Xen looks in the page tables it doesn't find the entries > >>>>> because they're not there yet. > >>>>> > >>>>> Putting a call to vmalloc_sync_all() after create_vm_area() and before > >>>>> the hypercall makes it work for me. Classic Xen kernels used to have > >>>>> such a call. > >>>> That sounds quite reasonable. > >>> I was wondering why upstream was missing the vmalloc_sync_all() in > >>> alloc_vm_area() since the out-of-tree kernels did have it and the > >>> function was added by us. I found this: > >>> http://git.kernel.org/?p=linux/kernel/git/torvalds/linux.git;a=commitdiff;h=ef691947d8a3d479e67652312783aedcf629320a > >>> > >>> commit ef691947d8a3d479e67652312783aedcf629320a > >>> Author: Jeremy Fitzhardinge > >>> Date: Wed Dec 1 15:45:48 2010 -0800 > >>> > >>> vmalloc: remove vmalloc_sync_all() from alloc_vm_area() > >>> > >>> There's no need for it: it will get faulted into the current pagetable > >>> as needed. > >>> > >>> Signed-off-by: Jeremy Fitzhardinge > >>> > >>> The flaw in the reasoning here is that you cannot take a kernel fault > >>> while processing a hypercall, so hypercall arguments must have been > >>> faulted in beforehand and that is what the sync_all was for. > >> That's a good point. (Maybe Xen should have generated pagefaults when > >> hypercall arg pointers are bad...) > > I think it would be a bit tricky to do in practice, you'd either have to > > support recursive hypercalls in the middle of other hypercalls (because > > the page fault handler is surely going to want to do some) or proper > > hypercall restart (so you can fully return to guest context to handle > > the fault then retry) or something along those and complexifying up the > > hypervisor one way or another. Probably not impossible if you were > > building something form the ground up, but not trivial. > > Well, Xen already has the continuation machinery for dealing with > hypercall restart, so that could be reused. That requires special support beyond just calling the continuation in each hypercall (often extending into the ABI) for pickling progress and picking it up again, only a small number of (usually long running) hypercalls have that support today. It also uses the guest context to store the state which perhaps isn't helpful if you want to return to the guest, although I suppose building a nested frame would work. The guys doing paging and sharing etc looked into this and came to the conclusion that it would be intractably difficult to do this fully -- hence we now have the ability to sleep in hypercalls, which works because the pager/sharer is in a different domain/vcpu. > And accesses to guest > memory are already special events which must be checked so that EFAULT > can be returned. If, rather than failing with EFAULT Xen set up a > pagefault exception for the guest CPU with the return set up to retry > the hypercall, it should all work... > > Of course, if the guest isn't expecting that - or its buggy - then it > could end up in an infinite loop. But maybe a flag (set a high bit in > the hypercall number?), or a feature, or something? Might be worthwhile > if it saves guests having to do something expensive (like a > vmalloc_sync_all), even if they have to also deal with old hypervisors. The vmalloc_sync_all is a pretty event even on Xen though, isn't it? > >> There's already a wrapper: xen_alloc_vm_area(), which is just a > >> #define. But we could easily add a sync_all to it (and use it in > >> netback, like we do in grant-table and xenbus). > > OOI what was the wrapper for originally? > > Not sure; I brought it over from 2.6.18-xen. > > BTW, vmalloc_sync_all() is much hated, and is slated for removal at some > point - there are definitely target sights on it. So we should think > about not needing it. > > J _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel From xen-devel-bounces@lists.xensource.com Fri Sep 02 00:23:09 2011 Return-path: Envelope-to: www-data@lists.xensource.com Delivery-date: Fri, 02 Sep 2011 00:23:09 -0700 Received: from localhost ([127.0.0.1] helo=lists.colo.xensource.com) by lists.xensource.com with esmtp (Exim 4.43) id 1QzO5l-0003N1-8S; Fri, 02 Sep 2011 00:23:09 -0700 Received: from mail174.messagelabs.com ([85.158.138.51]) by lists.xensource.com with smtp (Exim 4.43) id 1QzO5G-0003AM-Tf for xen-devel@lists.xensource.com; Fri, 02 Sep 2011 00:22:39 -0700 X-Env-Sender: Ian.Campbell@eu.citrix.com X-Msg-Ref: server-12.tower-174.messagelabs.com!1314948155!29957278!1 X-Originating-IP: [62.200.22.115] X-StarScan-Version: 6.3.6; banners=-,-,- X-VirusChecked: Checked Received: (qmail 22672 invoked from network); 2 Sep 2011 07:22:35 -0000 Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115) by server-12.tower-174.messagelabs.com with SMTP; 2 Sep 2011 07:22:35 -0000 X-IronPort-AV: E=Sophos;i="4.68,317,1312156800"; d="scan'208";a="7565448" Received: from lonpmailmx01.citrite.net ([10.30.203.162]) by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5; 02 Sep 2011 07:22:35 +0000 Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net (10.30.203.162) with Microsoft SMTP Server id 8.3.137.0; Fri, 2 Sep 2011 08:22:35 +0100 Subject: Re: [Xen-devel] Re: [Revert] Re: [PATCH] mm: sync vmalloc address space page tables in alloc_vm_area() From: Ian Campbell To: Jeremy Fitzhardinge In-Reply-To: <4E5FED1A.1000300@goop.org> References: <1314877863-21977-1-git-send-email-david.vrabel@citrix.com> <20110901161134.GA8979@dumpdata.com> <4E5FED1A.1000300@goop.org> Content-Type: text/plain; charset="UTF-8" Organization: Citrix Systems, Inc. Date: Fri, 2 Sep 2011 08:22:34 +0100 Message-ID: <1314948154.28989.158.camel@zakaz.uk.xensource.com> MIME-Version: 1.0 X-Mailer: Evolution 2.32.3 Content-Transfer-Encoding: 7bit Cc: "xen-devel@lists.xensource.com" , Konrad Rzeszutek Wilk , "namhyung@gmail.com" , "linux-kernel@vger.kernel.org" , "linux-mm@kvack.org" , David Vrabel , "rientjes@google.com" , "akpm@linux-foundation.org" , "paulmck@linux.vnet.ibm.com" X-BeenThere: xen-devel@lists.xensource.com X-Mailman-Version: 2.1.5 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xensource.com Errors-To: xen-devel-bounces@lists.xensource.com On Thu, 2011-09-01 at 21:37 +0100, Jeremy Fitzhardinge wrote: > On 09/01/2011 09:11 AM, Konrad Rzeszutek Wilk wrote: > > On Thu, Sep 01, 2011 at 12:51:03PM +0100, David Vrabel wrote: > >> From: David Vrabel > > Andrew, > > > > I was wondering if you would be Ok with this patch for 3.1. > > > > It is a revert (I can prepare a proper revert if you would like > > that instead of this patch). > > > > The users of this particular function (alloc_vm_area) are just > > Xen. There are no others. > > I'd prefer to put explicit vmalloc_sync_all()s in the callsites where > necessary, and ultimately try to work out ways of avoiding it altogether > (like have some hypercall wrapper which touches the arg memory to make > sure its mapped?). That only syncs the current pagetable though. If that is sufficient (and it could well be) then perhaps just doing a vmalloc_sync_one on the current page tables directly would be better than faulting to do it? It's the sort of thing you could hide inside the gnttab_set_map_op type helpers I guess? Ian. _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel From xen-devel-bounces@lists.xensource.com Fri Sep 02 00:32:43 2011 Return-path: Envelope-to: www-data@lists.xensource.com Delivery-date: Fri, 02 Sep 2011 00:32:43 -0700 Received: from localhost ([127.0.0.1] helo=lists.colo.xensource.com) by lists.xensource.com with esmtp (Exim 4.43) id 1QzOF1-0003tN-KA; Fri, 02 Sep 2011 00:32:43 -0700 Received: from mail27.messagelabs.com ([193.109.254.147]) by lists.xensource.com with esmtp (Exim 4.43) id 1QzODm-0003fS-54 for xen-devel@lists.xensource.com; Fri, 02 Sep 2011 00:31:31 -0700 X-Env-Sender: keir.xen@gmail.com X-Msg-Ref: server-3.tower-27.messagelabs.com!1314948662!37983853!1 X-Originating-IP: [74.125.82.171] X-StarScan-Version: 6.3.6; banners=-,-,- X-VirusChecked: Checked Received: (qmail 25797 invoked from network); 2 Sep 2011 07:31:02 -0000 Received: from mail-wy0-f171.google.com (HELO mail-wy0-f171.google.com) (74.125.82.171) by server-3.tower-27.messagelabs.com with RC4-SHA encrypted SMTP; 2 Sep 2011 07:31:02 -0000 Received: by wyh13 with SMTP id 13so2541200wyh.30 for ; Fri, 02 Sep 2011 00:31:22 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=user-agent:date:subject:from:to:cc:message-id:thread-topic :thread-index:in-reply-to:mime-version:content-type :content-transfer-encoding; bh=a1X2RYzxBXVvsGSjGDO8cZlHMc0tVkpT9W9xf71ubKs=; b=TIaQ6YmZoUF/TUteyzE8Y83zRjRTuMufG2+rjGA2FbeasSA2bie2fb/BYVAzLsdKTj Qo+eB0pjC4DWniAmpof8QmUGJ+zKxCLhdSzKhT2+/DIV30MKARVGJL3UxXaHtzHFCyMN TGEGKo/B2Xs4vj92A2VoeF1LA23bay1p0eK90= Received: by 10.227.198.130 with SMTP id eo2mr730531wbb.50.1314948682769; Fri, 02 Sep 2011 00:31:22 -0700 (PDT) Received: from [192.168.1.78] (host86-137-116-193.range86-137.btcentralplus.com [86.137.116.193]) by mx.google.com with ESMTPS id ft2sm719875wbb.18.2011.09.02.00.31.18 (version=SSLv3 cipher=OTHER); Fri, 02 Sep 2011 00:31:21 -0700 (PDT) User-Agent: Microsoft-Entourage/12.30.0.110427 Date: Fri, 02 Sep 2011 08:31:16 +0100 Subject: Re: [Xen-devel] Re: [Revert] Re: [PATCH] mm: sync vmalloc address space page tables in alloc_vm_area() From: Keir Fraser To: Ian Campbell , Jeremy Fitzhardinge Message-ID: Thread-Topic: [Xen-devel] Re: [Revert] Re: [PATCH] mm: sync vmalloc address space page tables in alloc_vm_area() Thread-Index: AcxpQkyN6Y7ZjHhdY0KuxuwbyOI3oA== In-Reply-To: <1314948154.28989.158.camel@zakaz.uk.xensource.com> Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit Cc: "xen-devel@lists.xensource.com" , Konrad Rzeszutek Wilk , "namhyung@gmail.com" , "linux-kernel@vger.kernel.org" , "linux-mm@kvack.org" , David Vrabel , "rientjes@google.com" , "akpm@linux-foundation.org" , "paulmck@linux.vnet.ibm.com" X-BeenThere: xen-devel@lists.xensource.com X-Mailman-Version: 2.1.5 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xensource.com Errors-To: xen-devel-bounces@lists.xensource.com On 02/09/2011 08:22, "Ian Campbell" wrote: > On Thu, 2011-09-01 at 21:37 +0100, Jeremy Fitzhardinge wrote: >> On 09/01/2011 09:11 AM, Konrad Rzeszutek Wilk wrote: >>> On Thu, Sep 01, 2011 at 12:51:03PM +0100, David Vrabel wrote: >>>> From: David Vrabel >>> Andrew, >>> >>> I was wondering if you would be Ok with this patch for 3.1. >>> >>> It is a revert (I can prepare a proper revert if you would like >>> that instead of this patch). >>> >>> The users of this particular function (alloc_vm_area) are just >>> Xen. There are no others. >> >> I'd prefer to put explicit vmalloc_sync_all()s in the callsites where >> necessary, and ultimately try to work out ways of avoiding it altogether >> (like have some hypercall wrapper which touches the arg memory to make >> sure its mapped?). > > That only syncs the current pagetable though. If that is sufficient (and > it could well be) then perhaps just doing a vmalloc_sync_one on the > current page tables directly would be better than faulting to do it? It's probably sufficient unless the kernel has non-voluntary preemption, and we are not preempt_disable()d. -- Keir > It's the sort of thing you could hide inside the gnttab_set_map_op type > helpers I guess? > > Ian. > > > > _______________________________________________ > Xen-devel mailing list > Xen-devel@lists.xensource.com > http://lists.xensource.com/xen-devel _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel From xen-devel-bounces@lists.xensource.com Fri Sep 02 01:19:48 2011 Return-path: Envelope-to: www-data@lists.xensource.com Delivery-date: Fri, 02 Sep 2011 01:19:48 -0700 Received: from localhost ([127.0.0.1] helo=lists.colo.xensource.com) by lists.xensource.com with esmtp (Exim 4.43) id 1QzOyY-0005Im-Of; Fri, 02 Sep 2011 01:19:46 -0700 Received: from mail216.messagelabs.com ([85.158.143.99]) by lists.xensource.com with smtp (Exim 4.43) id 1QzOxN-00055c-W0 for xen-devel@lists.xensource.com; Fri, 02 Sep 2011 01:18:34 -0700 X-Env-Sender: imammedo@redhat.com X-Msg-Ref: server-12.tower-216.messagelabs.com!1314951510!11074737!1 X-Originating-IP: [209.132.183.28] X-StarScan-Version: 6.3.6; banners=-,-,- X-VirusChecked: Checked Received: (qmail 1445 invoked from network); 2 Sep 2011 08:18:30 -0000 Received: from mx1.redhat.com (HELO mx1.redhat.com) (209.132.183.28) by server-12.tower-216.messagelabs.com with SMTP; 2 Sep 2011 08:18:30 -0000 Received: from int-mx01.intmail.prod.int.phx2.redhat.com (int-mx01.intmail.prod.int.phx2.redhat.com [10.5.11.11]) by mx1.redhat.com (8.14.4/8.14.4) with ESMTP id p828IRKl015716 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Fri, 2 Sep 2011 04:18:28 -0400 Received: from ns3.rdu.redhat.com (ns3.rdu.redhat.com [10.11.255.199]) by int-mx01.intmail.prod.int.phx2.redhat.com (8.13.8/8.13.8) with ESMTP id p828IPPl029370; Fri, 2 Sep 2011 04:18:25 -0400 Received: from nial.usersys.redhat.com (dhcp-1-247.brq.redhat.com [10.34.1.247]) by ns3.rdu.redhat.com (8.13.8/8.13.8) with ESMTP id p828IOAa024642; Fri, 2 Sep 2011 04:18:24 -0400 Message-ID: <4E60914F.7080208@redhat.com> Date: Fri, 02 Sep 2011 10:18:23 +0200 From: Igor Mammedov User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.2.20) Gecko/20110805 Red Hat/3.1.12-1.el6_1 Lightning/1.0b2 Thunderbird/3.1.12 MIME-Version: 1.0 To: Jeremy Fitzhardinge References: <4E5EB794.7050909@goop.org> <1314877615-18280-1-git-send-email-imammedo@redhat.com> <4E5FB700.1070908@goop.org> In-Reply-To: <4E5FB700.1070908@goop.org> Content-Type: text/plain; charset=ISO-8859-15; format=flowed Content-Transfer-Encoding: 7bit X-Scanned-By: MIMEDefang 2.67 on 10.5.11.11 Cc: xen-devel@lists.xensource.com, linux-kernel@vger.kernel.org, konrad.wilk@oracle.com Subject: [Xen-devel] Re: [PATCH v2] xen: x86_32: do not enable iterrupts when returning from exception in interrupt context X-BeenThere: xen-devel@lists.xensource.com X-Mailman-Version: 2.1.5 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xensource.com Errors-To: xen-devel-bounces@lists.xensource.com On 09/01/2011 06:46 PM, Jeremy Fitzhardinge wrote: > On 09/01/2011 04:46 AM, Igor Mammedov wrote: >> If vmalloc page_fault happens inside of interrupt handler with interrupts >> disabled then on exit path from exception handler when there is no pending >> interrupts, the following code (arch/x86/xen/xen-asm_32.S:112): >> >> cmpw $0x0001, XEN_vcpu_info_pending(%eax) >> sete XEN_vcpu_info_mask(%eax) >> >> will enable interrupts even if they has been previously disabled according to >> eflags from the bounce frame (arch/x86/xen/xen-asm_32.S:99) >> >> testb $X86_EFLAGS_IF>>8, 8+1+ESP_OFFSET(%esp) >> setz XEN_vcpu_info_mask(%eax) >> >> Solution is in setting XEN_vcpu_info_mask only when it should be set >> according to >> cmpw $0x0001, XEN_vcpu_info_pending(%eax) >> but not clearing it if there isn't any pending events. >> >> Reproducer for bug is attached to RHBZ 707552 >> >> Signed-off-by: Igor Mammedov >> Signed-off-by: Jeremy Fitzhardinge > > One nit, this should be acked-by or reviewed-by, not signed-off-by, > since the patch isn't passing through my hands. > > J I'm new to this stuff, would you like me to re-post it? Next time will do it right. ------- Thanks, Igor _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel From xen-devel-bounces@lists.xensource.com Fri Sep 02 02:12:03 2011 Return-path: Envelope-to: www-data@lists.xensource.com Delivery-date: Fri, 02 Sep 2011 02:12:03 -0700 Received: from localhost ([127.0.0.1] helo=lists.colo.xensource.com) by lists.xensource.com with esmtp (Exim 4.43) id 1QzPn9-0000Ju-Ii; Fri, 02 Sep 2011 02:12:03 -0700 Received: from mail27.messagelabs.com ([193.109.254.147]) by lists.xensource.com with smtp (Exim 4.43) id 1QzPmB-00006S-28 for xen-devel@lists.xensource.com; Fri, 02 Sep 2011 02:11:05 -0700 X-Env-Sender: chao.zhou@intel.com X-Msg-Ref: server-4.tower-27.messagelabs.com!1314954643!41189128!1 X-Originating-IP: [143.182.124.21] X-StarScan-Version: 6.3.6; banners=-,-,- X-VirusChecked: Checked Received: (qmail 15308 invoked from network); 2 Sep 2011 09:10:44 -0000 Received: from mga03.intel.com (HELO mga03.intel.com) (143.182.124.21) by server-4.tower-27.messagelabs.com with SMTP; 2 Sep 2011 09:10:44 -0000 Received: from azsmga001.ch.intel.com ([10.2.17.19]) by azsmga101.ch.intel.com with ESMTP; 02 Sep 2011 02:10:58 -0700 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="4.68,317,1312182000"; d="scan'208";a="44989473" Received: from pgsmsx602.gar.corp.intel.com ([10.221.43.81]) by azsmga001.ch.intel.com with ESMTP; 02 Sep 2011 02:10:57 -0700 Received: from shsmsx601.ccr.corp.intel.com (10.239.4.112) by pgsmsx602.gar.corp.intel.com (10.221.43.81) with Microsoft SMTP Server (TLS) id 8.2.255.0; Fri, 2 Sep 2011 17:10:47 +0800 Received: from shsmsx502.ccr.corp.intel.com ([10.239.4.96]) by shsmsx601.ccr.corp.intel.com ([10.239.4.112]) with mapi; Fri, 2 Sep 2011 17:10:45 +0800 From: "Zhou, Chao" To: "xen-devel@lists.xensource.com" Date: Fri, 2 Sep 2011 17:10:44 +0800 Thread-Topic: Biweekly VMX status report. Xen:23799 & Dom0:1c3f03cc... Thread-Index: AcxpNUMiq2EufXbNS7+1ZnBhb55YuwAAl/bwAAYR99A= Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: [Xen-devel] FW: Biweekly VMX status report. Xen:23799 & Dom0:1c3f03cc... X-BeenThere: xen-devel@lists.xensource.com X-Mailman-Version: 2.1.5 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xensource.com Errors-To: xen-devel-bounces@lists.xensource.com Hi all, This is the test report for xen-unstable tree. We found two bugs(#1774­= 2) fixed and one new bug(#1778) about win2k8 guest shutdown with blue scree= n. Details are listed as below. Version Info =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D xen_changeset : Tue Aug 30 11:46:58 2011 +0100 23799:ac9aa65050e9 pvops git:=20 commit 1c3f03ccc5258887f5f2cafc0836a865834f9205 =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D Test Environment =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D Platform Romley-EP(x86_64) Westmere-EP(x86_64) CPU 32 24 Memory 28G 12G =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D New issue(1) =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D 1. Windows2k8 guest shows blue screen when shut down http://bugzilla.xensource.com/bugzilla/show_bug.cgi?id=3D1778 Fixed issues(2) =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D 1. [Hypervisor]Xen complains msi error when startup http://bugzilla.xensource.com/bugzilla/show_bug.cgi?id=3D1732 2. 'VT-d 1G super page' feature is blocked http://bugzilla.xensource.com/bugzilla/show_bug.cgi?id=3D1774 Old issues(7) =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D 1. [ACPI] System cann't resume after do suspend http://bugzilla.xensource.com/bugzilla/show_bug.cgi?id=3D1707 2.[XL]"xl vcpu-set" causes dom0 crash or panic http://bugzilla.xensource.com/bugzilla/show_bug.cgi?id=3D1730 3.[VT-D]fail to detach NIC from guest http://bugzilla.xensource.com/bugzilla/show_bug.cgi?id=3D1736 4.[Save/Restore] guest failed to reboot after L-Migration it http://bugzilla.xensource.com/bugzilla/show_bug.cgi?id=3D1739 5.Dom0 crash on power-off http://bugzilla.xensource.com/bugzilla/show_bug.cgi?id=3D1740 6.Sometimes Xen panic on ia32pae Sandybridge when restore guest http://bugzilla.xensource.com/bugzilla/show_bug.cgi?id=3D1747 7.[VT-D] device reset fail when create/destroy guest http://bugzilla.xensource.com/bugzilla/show_bug.cgi?id=3D1752 Best Regards, Chao Zhou _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel From xen-devel-bounces@lists.xensource.com Fri Sep 02 02:20:47 2011 Return-path: Envelope-to: www-data@lists.xensource.com Delivery-date: Fri, 02 Sep 2011 02:20:47 -0700 Received: from localhost ([127.0.0.1] helo=lists.colo.xensource.com) by lists.xensource.com with esmtp (Exim 4.43) id 1QzPvb-0002nC-6U; Fri, 02 Sep 2011 02:20:47 -0700 Received: from mail174.messagelabs.com ([85.158.138.51]) by lists.xensource.com with smtp (Exim 4.43) id 1QzPuS-0002Da-G5 for xen-devel@lists.xensource.com; Fri, 02 Sep 2011 02:19:37 -0700 X-Env-Sender: imammedo@redhat.com X-Msg-Ref: server-13.tower-174.messagelabs.com!1314955171!29999700!1 X-Originating-IP: [209.132.183.28] X-StarScan-Version: 6.3.6; banners=-,-,- X-VirusChecked: Checked Received: (qmail 19852 invoked from network); 2 Sep 2011 09:19:32 -0000 Received: from mx1.redhat.com (HELO mx1.redhat.com) (209.132.183.28) by server-13.tower-174.messagelabs.com with SMTP; 2 Sep 2011 09:19:32 -0000 Received: from int-mx09.intmail.prod.int.phx2.redhat.com (int-mx09.intmail.prod.int.phx2.redhat.com [10.5.11.22]) by mx1.redhat.com (8.14.4/8.14.4) with ESMTP id p829JVjd031155 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK) for ; Fri, 2 Sep 2011 05:19:31 -0400 Received: from ns3.rdu.redhat.com (ns3.rdu.redhat.com [10.11.255.199]) by int-mx09.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP id p829JUsR002005 for ; Fri, 2 Sep 2011 05:19:30 -0400 Received: from nial.usersys.redhat.com (dhcp-1-247.brq.redhat.com [10.34.1.247]) by ns3.rdu.redhat.com (8.13.8/8.13.8) with ESMTP id p829JTiI001424 for ; Fri, 2 Sep 2011 05:19:30 -0400 Message-ID: <4E609FA1.3010503@redhat.com> Date: Fri, 02 Sep 2011 11:19:29 +0200 From: Igor Mammedov User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.2.20) Gecko/20110805 Red Hat/3.1.12-1.el6_1 Lightning/1.0b2 Thunderbird/3.1.12 MIME-Version: 1.0 To: xen-devel@lists.xensource.com Subject: Re: [Xen-devel] [PATCH v2] xen: x86_32: do not enable iterrupts when returning from exception in interrupt context References: <4E5EB794.7050909@goop.org> <1314877615-18280-1-git-send-email-imammedo@redhat.com> In-Reply-To: <1314877615-18280-1-git-send-email-imammedo@redhat.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Scanned-By: MIMEDefang 2.68 on 10.5.11.22 X-BeenThere: xen-devel@lists.xensource.com X-Mailman-Version: 2.1.5 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xensource.com Errors-To: xen-devel-bounces@lists.xensource.com BTW, while debugging this issue, I've tried to print saved_upcall_mask inside xen when handling page fault from guest. And it value is always 0. Looking at asm code for example in xen/arch/x86/x86_32/entry.S:382 movzwl TRAPBOUNCE_cs(%edx),%eax ^^^^^ upper 16-bit is 0 set in propagate_page_fault by "tb->cs = ti->cs;" /* Null selectors (0-3) are not allowed. */ testl $~3,%eax jz domain_crash_synchronous movl %eax,UREGS_cs+4(%esp) ^^^^^^^^^^^^^^^^ and here is the only place we set saved_upcall_mask field in current cpu_user_regs It looks like "saved_upcall_mask" in cpu_user_regs is not really used any more for what it means and it's presence in struct is just confusing and misleading. So why not delete it and extend _pad1 to 4 bytes? _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel From xen-devel-bounces@lists.xensource.com Fri Sep 02 02:25:08 2011 Return-path: Envelope-to: www-data@lists.xensource.com Delivery-date: Fri, 02 Sep 2011 02:25:08 -0700 Received: from localhost ([127.0.0.1] helo=lists.colo.xensource.com) by lists.xensource.com with esmtp (Exim 4.43) id 1QzPzo-0003FG-2a; Fri, 02 Sep 2011 02:25:08 -0700 Received: from mail27.messagelabs.com ([193.109.254.147]) by lists.xensource.com with smtp (Exim 4.43) id 1QzJzx-0003jJ-3q for xen-devel@lists.xensource.com; Thu, 01 Sep 2011 20:01:14 -0700 X-Env-Sender: serge@hallyn.com X-Msg-Ref: server-11.tower-27.messagelabs.com!1314932440!35724292!1 X-Originating-IP: [50.56.35.84] X-StarScan-Version: 6.3.6; banners=-,-,- X-VirusChecked: Checked Received: (qmail 19712 invoked from network); 2 Sep 2011 03:00:41 -0000 Received: from 50-56-35-84.static.cloud-ips.com (HELO mail) (50.56.35.84) by server-11.tower-27.messagelabs.com with SMTP; 2 Sep 2011 03:00:41 -0000 Received: by mail (Postfix, from userid 1000) id DCF7110025A; Fri, 2 Sep 2011 03:01:40 +0000 (UTC) Date: Fri, 2 Sep 2011 03:01:40 +0000 From: "Serge E. Hallyn" To: Jonathan Nieder Message-ID: <20110902030140.GA31569@hallyn.com> References: <625BA99ED14B2D499DC4E29D8138F1505C8ED7F7E3@shsmsx502.ccr.corp.intel.com> <20110829041532.GA22087@elie.gateway.2wire.net> <1314752662.6411.26.camel@nimitz> <20110831082230.GA4539@elie.gateway.2wire.net> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20110831082230.GA4539@elie.gateway.2wire.net> User-Agent: Mutt/1.5.20 (2009-06-14) X-Mailman-Approved-At: Fri, 02 Sep 2011 02:24:36 -0700 Cc: Len Brown , Kevin Tian , xen-devel@lists.xensource.com, linux-kernel@vger.kernel.org, JBeulich@novell.com, Dave Hansen , Ian Campbell , mingo@redhat.com, hpa@zytor.com, Thomas Gleixner , Lars Boegild Thomsen Subject: [Xen-devel] Re: [regression] Ideapad S10-3 does not wake up from suspend (Re: [PATCH v2 2/2] x86: don't unmask disabled irqs when migrating them) X-BeenThere: xen-devel@lists.xensource.com X-Mailman-Version: 2.1.5 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xensource.com Errors-To: xen-devel-bounces@lists.xensource.com Quoting Jonathan Nieder (jrnieder@gmail.com): > Hi Dave, > > Dave Hansen wrote: > > > I'm seeing the exact same symptoms on my S10-3, fwiw. They definitely > > don't happen when intel_idle is compiled out or when > > intel_idle.max_cstate=0 is specified on the kernel command-line. > > Lars reminds me[1] that the kernel he was testing already had the > intel_idle driver compiled out, so you're probably seeing a different > (possibly related) bug. (By the way, Lars, it is fine to communicate > with lkml directly. :) The people there don't bite.) Right, over the past year or so this has been hit or miss. Sometimes intel_idle.max_cstate=0 would fix it. Sometimes (like today) not. Ever since the problems have started, using intel_idle has not worked once, but disabling it is not 100% reliable. And when it doesn't work, it doesn't work at all until I get a new kernel. Sorry, not very helpful. -serge _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel From xen-devel-bounces@lists.xensource.com Fri Sep 02 03:07:39 2011 Return-path: Envelope-to: www-data@lists.xensource.com Delivery-date: Fri, 02 Sep 2011 03:07:39 -0700 Received: from localhost ([127.0.0.1] helo=lists.colo.xensource.com) by lists.xensource.com with esmtp (Exim 4.43) id 1QzQew-0006dS-La; Fri, 02 Sep 2011 03:07:38 -0700 Received: from mail216.messagelabs.com ([85.158.143.99]) by lists.xensource.com with esmtp (Exim 4.43) id 1QzQYW-0005gQ-9z for xen-devel@lists.xensource.com; Fri, 02 Sep 2011 03:01:09 -0700 X-Env-Sender: keir.xen@gmail.com X-Msg-Ref: server-11.tower-216.messagelabs.com!1314957657!9244431!1 X-Originating-IP: [74.125.82.171] X-StarScan-Version: 6.3.6; banners=-,-,- X-VirusChecked: Checked Received: (qmail 8760 invoked from network); 2 Sep 2011 10:00:57 -0000 Received: from mail-wy0-f171.google.com (HELO mail-wy0-f171.google.com) (74.125.82.171) by server-11.tower-216.messagelabs.com with RC4-SHA encrypted SMTP; 2 Sep 2011 10:00:57 -0000 Received: by wyh13 with SMTP id 13so2653044wyh.30 for ; Fri, 02 Sep 2011 03:00:57 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=user-agent:date:subject:from:to:message-id:thread-topic :thread-index:in-reply-to:mime-version:content-type :content-transfer-encoding; bh=k3RjyFPgwlxzU4Kt2b4KuC3SR7hraIBnOxqq+vyBQys=; b=f9pkf1EWW7txI1y8zHtP1jQ/0txTLi3Ftt+KGXU1tUuAthNwCxBRZcg0fjmBInIE6S P2rONcsu09hhzfzcvrSCBPAOkIYd4Q7S/hwlJTOqVgE4uxekKl9h33HI1QNe8P29kLbI w9pWKXyOFFWNM78zrYEY/fsMOXUVpTHkQlhJo= Received: by 10.227.116.77 with SMTP id l13mr913518wbq.33.1314957657068; Fri, 02 Sep 2011 03:00:57 -0700 (PDT) Received: from [192.168.1.78] (host86-137-116-193.range86-137.btcentralplus.com [86.137.116.193]) by mx.google.com with ESMTPS id ek7sm1120366wbb.14.2011.09.02.03.00.52 (version=SSLv3 cipher=OTHER); Fri, 02 Sep 2011 03:00:55 -0700 (PDT) User-Agent: Microsoft-Entourage/12.30.0.110427 Date: Fri, 02 Sep 2011 11:00:48 +0100 Subject: Re: [Xen-devel] [PATCH v2] xen: x86_32: do not enable iterrupts when returning from exception in interrupt context From: Keir Fraser To: Igor Mammedov , Message-ID: Thread-Topic: [Xen-devel] [PATCH v2] xen: x86_32: do not enable iterrupts when returning from exception in interrupt context Thread-Index: AcxpVzBI3XgzhCy+0EW9yfvxBvTCqQ== In-Reply-To: <4E609FA1.3010503@redhat.com> Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit Cc: X-BeenThere: xen-devel@lists.xensource.com X-Mailman-Version: 2.1.5 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xensource.com Errors-To: xen-devel-bounces@lists.xensource.com On 02/09/2011 10:19, "Igor Mammedov" wrote: > BTW, while debugging this issue, I've tried to print saved_upcall_mask > inside xen when handling page fault from guest. And it value is always > 0. Looking at asm code for example in xen/arch/x86/x86_32/entry.S:382 > > movzwl TRAPBOUNCE_cs(%edx),%eax > ^^^^^ upper 16-bit is 0 set in propagate_page_fault > by "tb->cs = ti->cs;" > > /* Null selectors (0-3) are not allowed. */ > testl $~3,%eax > jz domain_crash_synchronous > movl %eax,UREGS_cs+4(%esp) > ^^^^^^^^^^^^^^^^ and here is the only place we set > saved_upcall_mask field in current cpu_user_regs > > It looks like "saved_upcall_mask" in cpu_user_regs is not really used > any more for what it means and it's presence in struct is just confusing > and misleading. > > So why not delete it and extend _pad1 to 4 bytes? It's part of the guest ABI. -- Keir > > _______________________________________________ > Xen-devel mailing list > Xen-devel@lists.xensource.com > http://lists.xensource.com/xen-devel _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel From xen-devel-bounces@lists.xensource.com Fri Sep 02 04:04:33 2011 Return-path: Envelope-to: www-data@lists.xensource.com Delivery-date: Fri, 02 Sep 2011 04:04:33 -0700 Received: from localhost ([127.0.0.1] helo=lists.colo.xensource.com) by lists.xensource.com with esmtp (Exim 4.43) id 1QzRY0-00017p-Q8; Fri, 02 Sep 2011 04:04:32 -0700 Received: from mail216.messagelabs.com ([85.158.143.99]) by lists.xensource.com with esmtp (Exim 4.43) id 1QzRWs-0000v6-Qi for xen-devel@lists.xensource.com; Fri, 02 Sep 2011 04:03:23 -0700 X-Env-Sender: tim@xen.org X-Msg-Ref: server-11.tower-216.messagelabs.com!1314961399!9253717!1 X-Originating-IP: [81.29.64.94] X-StarScan-Version: 6.3.6; banners=-,-,- X-VirusChecked: Checked Received: (qmail 30755 invoked from network); 2 Sep 2011 11:03:19 -0000 Received: from ocelot.phlegethon.org (HELO mail.phlegethon.org) (81.29.64.94) by server-11.tower-216.messagelabs.com with DHE-RSA-AES256-SHA encrypted SMTP; 2 Sep 2011 11:03:19 -0000 Received: from tjd by mail.phlegethon.org with local (Exim 4.67 (FreeBSD)) (envelope-from ) id 1QzRWm-0008W4-EG; Fri, 02 Sep 2011 11:03:16 +0000 Date: Fri, 2 Sep 2011 12:03:16 +0100 From: Tim Deegan To: Jiageng Yu Subject: Re: [Xen-devel] Re: Linux Stubdom Problem Message-ID: <20110902110316.GA30893@ocelot.phlegethon.org> References: <20110901172728.GH3859@ocelot.phlegethon.org> Mime-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.4.2.1i Cc: "xen-devel@lists.xensource.com" , Stefano Stabellini , Konrad Rzeszutek Wilk , Ian Campbell , Keir Fraser , Anthony PERARD , Samuel Thibault X-BeenThere: xen-devel@lists.xensource.com X-Mailman-Version: 2.1.5 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xensource.com Errors-To: xen-devel-bounces@lists.xensource.com Hi, At 10:32 +0800 on 02 Sep (1314959538), Jiageng Yu wrote: > 2011/9/2 Tim Deegan : > > I would really rather not have this interface; I don't see why we can't > > use grant tables for this. > > In linux based stubdom case, we want to keep hvm guest and its > hvmloader unaware of running on stubdom. Why? HVMloader is already tightly coupled to the hypervisor and the toostack - special cases for stubdoms should be fine. > Therefore, we do need a way > to map vram pages of stubdom into guest hvm transparently. I've suggested two so far: have grant mappings done from inside the guest, or add a XENMAPSPACE that takes grant IDs. I think the XENMAPSPACE is better; I suspect that save/restore will be easier to get right that way. > Additionally, if I modified grant table to map pages without any > participation of hvm guest(or hvmloader), it will obey the design > goals of grant table. So I think grant table may not be suitable for > our case. I don't understand you. > Another idea is to allocate vram in hvm guest and stubdom maps vram > pages into its memory space. Sure. The minios-based stubdoms seem to manage that just fine. If this is really difficult for a linux-based stub domain, then maybe that's a reason not to use them. Cheers, Tim. _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel From xen-devel-bounces@lists.xensource.com Fri Sep 02 04:12:31 2011 Return-path: Envelope-to: www-data@lists.xensource.com Delivery-date: Fri, 02 Sep 2011 04:12:31 -0700 Received: from localhost ([127.0.0.1] helo=lists.colo.xensource.com) by lists.xensource.com with esmtp (Exim 4.43) id 1QzRfi-0001hb-8a; Fri, 02 Sep 2011 04:12:30 -0700 Received: from mail27.messagelabs.com ([193.109.254.147]) by lists.xensource.com with smtp (Exim 4.43) id 1QzRc7-0001RT-NI for xen-devel@lists.xensource.com; Fri, 02 Sep 2011 04:11:33 -0700 X-Env-Sender: Ian.Jackson@eu.citrix.com X-Msg-Ref: server-6.tower-27.messagelabs.com!1314961708!47332442!1 X-Originating-IP: [62.200.22.115] X-StarScan-Version: 6.3.6; banners=-,-,- X-VirusChecked: Checked Received: (qmail 2675 invoked from network); 2 Sep 2011 11:08:28 -0000 Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115) by server-6.tower-27.messagelabs.com with SMTP; 2 Sep 2011 11:08:28 -0000 X-IronPort-AV: E=Sophos;i="4.68,318,1312156800"; d="scan'208";a="7570470" Received: from lonpmailmx01.citrite.net ([10.30.203.162]) by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5; 02 Sep 2011 11:08:44 +0000 Received: from norwich.cam.xci-test.com (10.80.248.129) by smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id 8.3.137.0; Fri, 2 Sep 2011 12:08:44 +0100 Received: from mariner.cam.xci-test.com ([10.80.2.22] helo=mariner.uk.xensource.com ident=Debian-exim) by norwich.cam.xci-test.com with esmtp (Exim 4.72) (envelope-from ) id 1QzRc4-0002p2-AQ; Fri, 02 Sep 2011 11:08:44 +0000 Received: from iwj by mariner.uk.xensource.com with local (Exim 4.69) (envelope-from ) id 1QzRc4-00087c-8I; Fri, 02 Sep 2011 12:08:44 +0100 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Message-ID: <20064.47420.206222.363587@mariner.uk.xensource.com> Date: Fri, 2 Sep 2011 12:08:44 +0100 To: Andrew Jones Subject: Re: [Xen-devel] [xen-unstable bisection] complete test-amd64-i386-rhel6hvm-intel In-Reply-To: <1653323123.636758.1314905319336.JavaMail.root@zmail01.collab.prod.int.phx2.redhat.com> References: <20063.45607.355820.209628@mariner.uk.xensource.com> <1653323123.636758.1314905319336.JavaMail.root@zmail01.collab.prod.int.phx2.redhat.com> X-Mailer: VM 8.0.9 under Emacs 21.4.1 (i486-pc-linux-gnu) From: Ian Jackson Cc: Laszlo Ersek , "xen-devel@lists.xensource.com" , "keir@xen.org" , Stefano Stabellini X-BeenThere: xen-devel@lists.xensource.com X-Mailman-Version: 2.1.5 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xensource.com Errors-To: xen-devel-bounces@lists.xensource.com Andrew Jones writes ("Re: [Xen-devel] [xen-unstable bisection] complete test-amd64-i386-rhel6hvm-intel"): > It's seems unlikely this change could break a guest, but without any > output from you tests it's impossible to tell. The fact it failed on > the same host each of the three times is probably a clue worth looking > further at. I take it that it succeeded on other hosts? Sorry, this particular problem was a Xen build failure and nothing to do with RHEL6. Ian. _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel From xen-devel-bounces@lists.xensource.com Fri Sep 02 04:15:26 2011 Return-path: Envelope-to: www-data@lists.xensource.com Delivery-date: Fri, 02 Sep 2011 04:15:26 -0700 Received: from localhost ([127.0.0.1] helo=lists.colo.xensource.com) by lists.xensource.com with esmtp (Exim 4.43) id 1QzRiY-00026M-N1; Fri, 02 Sep 2011 04:15:26 -0700 Received: from mail182.messagelabs.com ([85.158.139.83]) by lists.xensource.com with smtp (Exim 4.43) id 1QzRhs-0001th-Gr for xen-devel@lists.xensource.com; Fri, 02 Sep 2011 04:14:45 -0700 X-Env-Sender: Stefano.Stabellini@eu.citrix.com X-Msg-Ref: server-14.tower-182.messagelabs.com!1314962081!16643624!1 X-Originating-IP: [62.200.22.115] X-StarScan-Version: 6.3.6; banners=-,-,- X-VirusChecked: Checked Received: (qmail 1930 invoked from network); 2 Sep 2011 11:14:41 -0000 Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115) by server-14.tower-182.messagelabs.com with SMTP; 2 Sep 2011 11:14:41 -0000 X-IronPort-AV: E=Sophos;i="4.68,318,1312156800"; d="scan'208";a="7570621" Received: from lonpmailmx01.citrite.net ([10.30.203.162]) by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5; 02 Sep 2011 11:14:40 +0000 Received: from kaball.uk.xensource.com (10.80.2.59) by LONPMAILMX01.citrite.net (10.30.203.162) with Microsoft SMTP Server id 8.3.137.0; Fri, 2 Sep 2011 12:14:40 +0100 Date: Fri, 2 Sep 2011 12:22:31 +0100 From: Stefano Stabellini X-X-Sender: sstabellini@kaball-desktop To: Jeremy Fitzhardinge In-Reply-To: Message-ID: References: User-Agent: Alpine 2.00 (DEB 1167 2008-08-23) MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Cc: Ingo, Jeremy, Nick Piggin , KVM , Linux, Peter Zijlstra , the arch/x86 maintainers , Kernel Mailing List , Marcelo Tosatti , Fitzhardinge , Andi Kleen , Avi Kivity , "H. Peter Anvin" , Molnar , Linus Torvalds , Xen Devel Subject: [Xen-devel] Re: [PATCH 00/13] [PATCH RFC] Paravirtualized ticketlocks X-BeenThere: xen-devel@lists.xensource.com X-Mailman-Version: 2.1.5 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xensource.com Errors-To: xen-devel-bounces@lists.xensource.com On Fri, 2 Sep 2011, Jeremy Fitzhardinge wrote: > From: Jeremy Fitzhardinge > > This series replaces the existing paravirtualized spinlock mechanism > with a paravirtualized ticketlock mechanism. > > Ticket locks have an inherent problem in a virtualized case, because > the vCPUs are scheduled rather than running concurrently (ignoring > gang scheduled vCPUs). This can result in catastrophic performance > collapses when the vCPU scheduler doesn't schedule the correct "next" > vCPU, and ends up scheduling a vCPU which burns its entire timeslice > spinning. (Note that this is not the same problem as lock-holder > preemption, which this series also addresses; that's also a problem, > but not catastrophic). > > (See Thomas Friebel's talk "Prevent Guests from Spinning Around" > http://www.xen.org/files/xensummitboston08/LHP.pdf for more details.) > > Currently we deal with this by having PV spinlocks, which adds a layer > of indirection in front of all the spinlock functions, and defining a > completely new implementation for Xen (and for other pvops users, but > there are none at present). > > PV ticketlocks keeps the existing ticketlock implemenentation > (fastpath) as-is, but adds a couple of pvops for the slow paths: > > - If a CPU has been waiting for a spinlock for SPIN_THRESHOLD > iterations, then call out to the __ticket_lock_spinning() pvop, > which allows a backend to block the vCPU rather than spinning. This > pvop can set the lock into "slowpath state". > > - When releasing a lock, if it is in "slowpath state", the call > __ticket_unlock_kick() to kick the next vCPU in line awake. If the > lock is no longer in contention, it also clears the slowpath flag. > > The "slowpath state" is stored in the LSB of the within the lock > ticket. This has the effect of reducing the max number of CPUs by > half (so, a "small ticket" can deal with 128 CPUs, and "large ticket" > 32768). > > This series provides a Xen implementation, but it should be > straightforward to add a KVM implementation as well. > > Overall, it results in a large reduction in code, it makes the native > and virtualized cases closer, and it removes a layer of indirection > around all the spinlock functions. The downside is that it does add a > few instructions into the fastpath in the native case. > > Most of the heavy lifting code is in the slowpaths, but it does have > an effect on the fastpath code. The inner part of ticket lock code > becomes: > inc = xadd(&lock->tickets, inc); > inc.tail &= ~TICKET_SLOWPATH_FLAG; > > for (;;) { > unsigned count = SPIN_THRESHOLD; > > do { > if (inc.head == inc.tail) > goto out; > cpu_relax(); > inc.head = ACCESS_ONCE(lock->tickets.head); > } while (--count); > __ticket_lock_spinning(lock, inc.tail); > } > > which results in: > > pushq %rbp > movq %rsp,%rbp > > movl $512, %ecx > lock; xaddw %cx, (%rdi) # claim ticket > > movzbl %ch, %edx > movl $2048, %eax # set spin count > andl $-2, %edx # mask off TICKET_SLOWPATH_FLAG > movzbl %dl, %esi > > 1: cmpb %dl, %cl # compare head and tail > je 2f # got it! > > ### BEGIN SLOWPATH > rep; nop # pause > decl %eax # dec count > movb (%rdi), %cl # re-fetch head > jne 1b # try again > > call *pv_lock_ops # call __ticket_lock_spinning > movl $2048, %eax # reload spin count > jmp 1b > ### END SLOWPATH > > 2: popq %rbp > ret > > with CONFIG_PARAVIRT_SPINLOCKS=n, the same code identical asm to the > current ticketlock code: > > pushq %rbp > movq %rsp, %rbp > > movl $256, %eax > lock; xaddw %ax, (%rdi) > > movzbl %ah, %edx > > 1: cmpb %dl, %al # compare head and tail > je 2f # got it! > > ### BEGIN SLOWPATH > rep; nop # pause > movb (%rdi), %al # reload head > jmp 1b # loop > ### END SLOWPATH > > 2: popq %rbp > ret > > so the pv ticketlocks add 3 extra instructions to the fastpath, one of > which really doesn't need to be there (setting up the arg for the > slowpath function): > movl $2048, %eax # set spin count > andl $-2, %edx # mask off SLOW_PATH_FLAG > movzbl %dl, %esi # set up __ticket_lock_spinning arg > > The unlock code is very straightforward: > __ticket_unlock_release(lock); > if (unlikely(__ticket_in_slowpath(lock))) > __ticket_unlock_slowpath(lock); > which generates: > addb $2, (%rdi) > testb $1, 1(%rdi) > je 1f > call __ticket_unlock_slowpath > 1: > > which, while simple, is more complex than the simple "incb (%rdi)". > (I'm not sure whether its worth inlining this or not.) > > Thoughts? Comments? Suggestions? > > Thanks, > J > > Jeremy Fitzhardinge (12): > x86/spinlocks: replace pv spinlocks with pv ticketlocks > x86/ticketlock: collapse a layer of functions > xen/pvticketlock: Xen implementation for PV ticket locks > x86/pvticketlock: use callee-save for lock_spinning > x86/ticketlocks: when paravirtualizing ticket locks, increment by 2 > x86/ticketlock: add slowpath logic > x86/ticketlocks: tidy up __ticket_unlock_kick() > xen/pvticketlock: disable interrupts while blocking > x86/pvticketlocks: we only need to kick if there's waiters > xen/pvticket: allow interrupts to be enabled while blocking > x86/pvticketlock: make sure unlock_kick pvop call is inlined > x86/pvticketlock: use __ticket_t for pvop args > > Srivatsa Vaddagiri (1): > x86/ticketlock: only do kick after doing unlock > > arch/x86/include/asm/paravirt.h | 30 +--- > arch/x86/include/asm/paravirt_types.h | 8 +- > arch/x86/include/asm/spinlock.h | 118 ++++++++----- > arch/x86/include/asm/spinlock_types.h | 16 ++- > arch/x86/kernel/paravirt-spinlocks.c | 40 +++-- > arch/x86/xen/spinlock.c | 305 ++++++++------------------------- > 6 files changed, 186 insertions(+), 331 deletions(-) do you have a git tree somewhere with this series? _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel From xen-devel-bounces@lists.xensource.com Fri Sep 02 04:20:56 2011 Return-path: Envelope-to: www-data@lists.xensource.com Delivery-date: Fri, 02 Sep 2011 04:20:56 -0700 Received: from localhost ([127.0.0.1] helo=lists.colo.xensource.com) by lists.xensource.com with esmtp (Exim 4.43) id 1QzRns-0003CZ-2K; Fri, 02 Sep 2011 04:20:56 -0700 Received: from mail21.messagelabs.com ([85.158.143.35]) by lists.xensource.com with smtp (Exim 4.43) id 1QzRlN-0002LT-RJ for xen-devel@lists.xensource.com; Fri, 02 Sep 2011 04:18:22 -0700 X-Env-Sender: Ian.Jackson@eu.citrix.com X-Msg-Ref: server-11.tower-21.messagelabs.com!1314962283!41094582!1 X-Originating-IP: [62.200.22.115] X-StarScan-Version: 6.3.6; banners=-,-,- X-VirusChecked: Checked Received: (qmail 14264 invoked from network); 2 Sep 2011 11:18:03 -0000 Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115) by server-11.tower-21.messagelabs.com with SMTP; 2 Sep 2011 11:18:03 -0000 X-IronPort-AV: E=Sophos;i="4.68,318,1312156800"; d="scan'208";a="7570696" Received: from lonpmailmx01.citrite.net ([10.30.203.162]) by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5; 02 Sep 2011 11:18:18 +0000 Received: from norwich.cam.xci-test.com (10.80.248.129) by smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id 8.3.137.0; Fri, 2 Sep 2011 12:18:18 +0100 Received: from mariner.cam.xci-test.com ([10.80.2.22] helo=mariner.uk.xensource.com ident=Debian-exim) by norwich.cam.xci-test.com with esmtp (Exim 4.72) (envelope-from ) id 1QzRlJ-0002rY-TC; Fri, 02 Sep 2011 11:18:17 +0000 Received: from iwj by mariner.uk.xensource.com with local (Exim 4.69) (envelope-from ) id 1QzRlJ-00088K-SW; Fri, 02 Sep 2011 12:18:17 +0100 MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="3+3soRJq8/" Content-Transfer-Encoding: 7bit Message-ID: <20064.47993.850551.693023@mariner.uk.xensource.com> Date: Fri, 2 Sep 2011 12:18:17 +0100 From: Xen.org security team To: xen-devel@lists.xensource.com X-Mailer: VM 8.0.9 under Emacs 21.4.1 (i486-pc-linux-gnu) Cc: oss-security@lists.openwall.com Subject: [Xen-devel] Xen Security Advisory 4 (CVE-2011-2901) - Xen 3.3 vaddr validation X-BeenThere: xen-devel@lists.xensource.com X-Mailman-Version: 2.1.5 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xensource.com Errors-To: xen-devel-bounces@lists.xensource.com --3+3soRJq8/ Content-Type: text/plain; charset="us-ascii" Content-Description: message body text Content-Transfer-Encoding: 7bit -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Xen Security Advisory CVE-2011-2901 / XSA-4 revision no.2 Xen <= 3.3 DoS due to incorrect virtual address validation ISSUE DESCRIPTION ================= The x86_64 __addr_ok() macro intends to ensure that the checked address is either in the positive half of the 48-bit virtual address space, or above the Xen-reserved area. However, the current shift count is off-by-one, allowing full access to the "negative half" too, via certain hypercalls which ignore virtual-address bits [63:48]. Vulnerable hypercalls exist only in very old versions of the hypervisor. VULNERABLE SYSTEMS ================== All systems running a Xen 3.3 or earlier hypervisor with 64-bit PV guests with untrusted administrators are vulnerable. IMPACT ====== A malicious guest administrator on a vulnerable system is able to crash the host. There are no known further exploits but these have not been ruled out. RESOLUTION ========== The attached patch resolves the issue. Alternatively, users may choose to upgrade to a more recent hypervisor PATCHES ======= The following patch resolves this issue. Filename: fix-__addr_ok-limit.patch SHA1: f18bde8d276110451c608a16f577865aa1226b4f SHA256: 2da5aac72e1ac4849c34d38374ae456795905fd9512eef94b48fc31383c21636 This patch should apply cleanly, and fix the problem, for all affected versions of Xen. It is harmless when applied to later hypervisors and will be included in the Xen unstable branch in due course. VERSION HISTORY =============== Analysis following version 1 of this advisory (sent out to the predisclosure list during the embargo period) indicates that the actual DoS vulnerability only exists in very old hypervisors, Xen 3.3 and earlier, contrary to previous reports. This advisory is no longer embargoed. -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (GNU/Linux) iQEcBAEBAgAGBQJOYLq2AAoJEIP+FMlX6CvZLegH/26/oJBkd/WM/yYhXkzlbnIP MxF6Fgy96Omu8poQTanD7g1vEcM0TOLY+Kk3GGsfj4aDdEJ5Nq4ZOW8ooI0VnVcD 7VXQqFsXPxre+eZ6g+G0AsmzdsG45C3qujUTRfGKqzYwXqjWjt9nNsdIy1Mrz8/4 zG1uLDkN0LXnBG2Te4q8ZckYwMq8gFXHHnH35RfQ5Besu6pvJmtK3rFXETdlP12A JjBh7t5jsCfzvYWFQehVp8mJupuftiOBPClmVh4vrvN9gYd5rzEgB4Q9Ioiqz2qT 2bE1zegR8NeOKBOi9xriTU8F530OdFzeWAbo7D5gyEbYdc60eNwbadcgNGLbzMg= =09T8 -----END PGP SIGNATURE----- --3+3soRJq8/ Content-Type: text/plain; name="fix-__addr_ok-limit.patch" Content-Description: fix for XSA 4 Content-Disposition: inline; filename="fix-__addr_ok-limit.patch" Content-Transfer-Encoding: 7bit Subject: XSA-4: xen: correct limit checking in x86_64 version of __addr_ok The x86_64 __addr_ok() macro intends to ensure that the checked address is either in the positive half of the 48-bit virtual address space, or above the Xen-reserved area. However, the current shift count is off-by-one, allowing full access to the "negative half" too. Guests may exploit this to gain access to off-limits ranges. This issue has been assigned CVE-2011-2901. Signed-off-by: Laszlo Ersek Signed-off-by: Ian Campbell diff --git a/xen/include/asm-x86/x86_64/uaccess.h b/xen/include/asm-x86/x86_64/uaccess.h --- a/xen/include/asm-x86/x86_64/uaccess.h +++ b/xen/include/asm-x86/x86_64/uaccess.h @@ -34,7 +34,7 @@ * non-canonical address (and thus fault) before ever reaching VIRT_START. */ #define __addr_ok(addr) \ - (((unsigned long)(addr) < (1UL<<48)) || \ + (((unsigned long)(addr) < (1UL<<47)) || \ ((unsigned long)(addr) >= HYPERVISOR_VIRT_END)) #define access_ok(addr, size) \ --3+3soRJq8/ Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel --3+3soRJq8/-- From xen-devel-bounces@lists.xensource.com Fri Sep 02 04:37:55 2011 Return-path: Envelope-to: www-data@lists.xensource.com Delivery-date: Fri, 02 Sep 2011 04:37:55 -0700 Received: from localhost ([127.0.0.1] helo=lists.colo.xensource.com) by lists.xensource.com with esmtp (Exim 4.43) id 1QzS4I-00043o-Fq; Fri, 02 Sep 2011 04:37:54 -0700 Received: from mail174.messagelabs.com ([85.158.138.51]) by lists.xensource.com with esmtp (Exim 4.43) id 1QzS3S-0003r8-IB for xen-devel@lists.xensource.com; Fri, 02 Sep 2011 04:37:02 -0700 X-Env-Sender: david.vrabel@citrix.com X-Msg-Ref: server-6.tower-174.messagelabs.com!1314963416!27883863!1 X-Originating-IP: [66.165.176.63] X-StarScan-Version: 6.3.6; banners=-,-,- X-VirusChecked: Checked Received: (qmail 14023 invoked from network); 2 Sep 2011 11:36:59 -0000 Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63) by server-6.tower-174.messagelabs.com with RC4-SHA encrypted SMTP; 2 Sep 2011 11:36:59 -0000 X-IronPort-AV: E=Sophos;i="4.68,318,1312171200"; d="scan'208";a="161550794" Received: from ftlpmailmx01.citrite.net ([10.13.107.65]) by FTLPIPO02.CITRIX.COM with ESMTP/TLS/RC4-MD5; 02 Sep 2011 07:36:55 -0400 Received: from [10.80.2.76] (10.80.2.76) by FTLPMAILMX01.citrite.net (10.13.107.65) with Microsoft SMTP Server id 8.3.137.0; Fri, 2 Sep 2011 07:36:55 -0400 Message-ID: <4E60C067.4010600@citrix.com> Date: Fri, 2 Sep 2011 12:39:19 +0100 From: David Vrabel User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.1.16) Gecko/20110818 Icedove/3.0.11 MIME-Version: 1.0 To: Andrew Morton References: <1314877863-21977-1-git-send-email-david.vrabel@citrix.com> <20110901161134.GA8979@dumpdata.com> <4E5FED1A.1000300@goop.org> <20110901141754.76cef93b.akpm@linux-foundation.org> In-Reply-To: <20110901141754.76cef93b.akpm@linux-foundation.org> Content-Type: text/plain; charset="ISO-8859-1" Content-Transfer-Encoding: 7bit Cc: Jeremy Fitzhardinge , "xen-devel@lists.xensource.com" , Konrad Rzeszutek Wilk , "namhyung@gmail.com" , "linux-kernel@vger.kernel.org" , "linux-mm@kvack.org" , "rientjes@google.com" , "paulmck@linux.vnet.ibm.com" Subject: [Xen-devel] Re: [Revert] Re: [PATCH] mm: sync vmalloc address space page tables in alloc_vm_area() X-BeenThere: xen-devel@lists.xensource.com X-Mailman-Version: 2.1.5 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xensource.com Errors-To: xen-devel-bounces@lists.xensource.com On 01/09/11 22:17, Andrew Morton wrote: > On Thu, 01 Sep 2011 13:37:46 -0700 > Jeremy Fitzhardinge wrote: > >> On 09/01/2011 09:11 AM, Konrad Rzeszutek Wilk wrote: >>> On Thu, Sep 01, 2011 at 12:51:03PM +0100, David Vrabel wrote: >>>> From: David Vrabel >>> Andrew, >>> >>> I was wondering if you would be Ok with this patch for 3.1. >>> >>> It is a revert (I can prepare a proper revert if you would like >>> that instead of this patch). > > David's patch looks better than a straight reversion. > > Problem is, I can't find David's original email anywhere. Someone's > been playing games with To: headers? Sorry, I should have Cc'd linux-kernel and others on the original patch. >From 6844ca07140e08f29454ca7b3fa459571c7ba428 Mon Sep 17 00:00:00 2001 From: David Vrabel Date: Thu, 1 Sep 2011 11:42:50 +0100 Subject: [PATCH] mm: sync vmalloc address space page tables in alloc_vm_area() Xen backend drivers (e.g., blkback and netback) would sometimes fail to map grant pages into the vmalloc address space allocated with alloc_vm_area(). The GNTTABOP_map_grant_ref would fail because Xen could not find the page (in the L2 table) containing the PTEs it needed to update. (XEN) mm.c:3846:d0 Could not find L1 PTE for address fbb42000 netback and blkback were making the hypercall from a kernel thread where task->active_mm != &init_mm and alloc_vm_area() was only updating the page tables for init_mm. The usual method of deferring the update to the page tables of other processes (i.e., after taking a fault) doesn't work as a fault cannot occur during the hypercall. This would work on some systems depending on what else was using vmalloc. Fix this by reverting ef691947d8a3d479e67652312783aedcf629320a (vmalloc: remove vmalloc_sync_all() from alloc_vm_area()) and add a comment to explain why it's needed. Signed-off-by: David Vrabel Cc: Jeremy Fitzhardinge --- mm/vmalloc.c | 8 ++++++++ 1 files changed, 8 insertions(+), 0 deletions(-) diff --git a/mm/vmalloc.c b/mm/vmalloc.c index 7ef0903..5016f19 100644 --- a/mm/vmalloc.c +++ b/mm/vmalloc.c @@ -2140,6 +2140,14 @@ struct vm_struct *alloc_vm_area(size_t size) return NULL; } + /* + * If the allocated address space is passed to a hypercall + * before being used then we cannot rely on a page fault to + * trigger an update of the page tables. So sync all the page + * tables here. + */ + vmalloc_sync_all(); + return area; } EXPORT_SYMBOL_GPL(alloc_vm_area); -- 1.7.2.5 _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel From xen-devel-bounces@lists.xensource.com Fri Sep 02 04:45:48 2011 Return-path: Envelope-to: www-data@lists.xensource.com Delivery-date: Fri, 02 Sep 2011 04:45:48 -0700 Received: from localhost ([127.0.0.1] helo=lists.colo.xensource.com) by lists.xensource.com with esmtp (Exim 4.43) id 1QzSBw-0004cG-S1; Fri, 02 Sep 2011 04:45:48 -0700 Received: from mail174.messagelabs.com ([85.158.138.51]) by lists.xensource.com with smtp (Exim 4.43) id 1QzSBL-0004QC-1s for xen-devel@lists.xensource.com; Fri, 02 Sep 2011 04:45:11 -0700 X-Env-Sender: Stefano.Stabellini@eu.citrix.com X-Msg-Ref: server-5.tower-174.messagelabs.com!1314963907!26310989!1 X-Originating-IP: [62.200.22.115] X-StarScan-Version: 6.3.6; banners=-,-,- X-VirusChecked: Checked Received: (qmail 1406 invoked from network); 2 Sep 2011 11:45:07 -0000 Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115) by server-5.tower-174.messagelabs.com with SMTP; 2 Sep 2011 11:45:07 -0000 X-IronPort-AV: E=Sophos;i="4.68,318,1312156800"; d="scan'208";a="7571283" Received: from lonpmailmx01.citrite.net ([10.30.203.162]) by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5; 02 Sep 2011 11:45:07 +0000 Received: from kaball.uk.xensource.com (10.80.2.59) by LONPMAILMX01.citrite.net (10.30.203.162) with Microsoft SMTP Server id 8.3.137.0; Fri, 2 Sep 2011 12:45:07 +0100 Date: Fri, 2 Sep 2011 12:52:58 +0100 From: Stefano Stabellini X-X-Sender: sstabellini@kaball-desktop To: Konrad Rzeszutek Wilk Subject: Re: [Xen-devel] [RFC PATCH v1] ACPI S3 to work under Xen. In-Reply-To: <1314815484-4668-1-git-send-email-konrad.wilk@oracle.com> Message-ID: References: <1314815484-4668-1-git-send-email-konrad.wilk@oracle.com> User-Agent: Alpine 2.00 (DEB 1167 2008-08-23) MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Cc: "xen-devel@lists.xensource.com" , "len.brown@intel.com" , "kevin.tian@intel.com" , "joseph.cihula@intel.com" , "keir@xen.org" , "shane.wang@intel.com" , "x86@kernel.org" , "linux-acpi@vger.kernel.org" , "tboot-devel@lists.sourceforge.net" , "liang.tang@oracle.com" , "ke.yu@intel.com" , "hpa@zytor.com" , "tglx@linutronix.de" , "linux-pm@lists.linux-foundation.org" X-BeenThere: xen-devel@lists.xensource.com X-Mailman-Version: 2.1.5 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xensource.com Errors-To: xen-devel-bounces@lists.xensource.com On Wed, 31 Aug 2011, Konrad Rzeszutek Wilk wrote: > Attached is an RFC set of patches to enable S3 to work with the Xen hypervisor. > > The relationship that Xen has with Linux kernel is symbiotic. The Linux > kernel does the ACPI "stuff" and tells the hypervisor to do the low-level > stuff (such as program the IOAPIC, setup vectors, etc). The realm of > ACPI S3 is more complex as we need to save the CPU state (and Intel TXT > values - which the hypervisor has to do) and then restore them. > > The major difficulties we hit was with 'acpi_suspend_lowlevel' - which tweaks > a lot of lowlevel values and some of them are not properly handled by Xen. > Liang Tang has figured which ones of them we trip over (read below) - and he > suggested that perhaps we can provide a registration mechanism to abstract > this away. > > So the attached patches do exactly that - there are two entry points > in the ACPI. > > 1). For S3: acpi_suspend_lowlevel -> .. lots of code -> acpi_enter_sleep_state > 2). For S1/S4/S5: acpi_enter_sleep_state > > The first naive idea was of abstracting away in the 'acpi_enter_sleep_state' > function the tboot_sleep code so that we can use it too. And low-behold - it > worked splendidly for powering off (S5 I believe) > > For S3 that did not work - during suspend the hypervisor tripped over when > saving cr8. During resume it tripped over at restoring the cr3, cr8, idt, > and gdt values. > > What do you guys think? One thought is to use the paravirt interface to > deal with cr3, cr8, idt, gdt for suspend/resume case.. But that is a lot > of extra 'if' in the paravirt code - which the callback registration would > effectively do the same thing as the paravirt - except at a higher level. > > Thoughts? I think there are no doubts about the fact that this approach produces cleaner code than using the pvop interface for dealing with cr3, cr8, etc. Also, having seen the original xen acpi implementation in 2.6.18, I want to add that you did a _very_ good job with this series. _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel From xen-devel-bounces@lists.xensource.com Fri Sep 02 05:28:06 2011 Return-path: Envelope-to: www-data@lists.xensource.com Delivery-date: Fri, 02 Sep 2011 05:28:06 -0700 Received: from localhost ([127.0.0.1] helo=lists.colo.xensource.com) by lists.xensource.com with esmtp (Exim 4.43) id 1QzSqq-0006wo-Ju; Fri, 02 Sep 2011 05:28:04 -0700 Received: from mail21.messagelabs.com ([85.158.143.35]) by lists.xensource.com with smtp (Exim 4.43) id 1QzSps-0006jO-0a for xen-devel@lists.xensource.com; Fri, 02 Sep 2011 05:27:04 -0700 X-Env-Sender: Stefano.Stabellini@eu.citrix.com X-Msg-Ref: server-14.tower-21.messagelabs.com!1314966413!58103410!1 X-Originating-IP: [62.200.22.115] X-StarScan-Version: 6.3.6; banners=-,-,- X-VirusChecked: Checked Received: (qmail 18007 invoked from network); 2 Sep 2011 12:26:53 -0000 Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115) by server-14.tower-21.messagelabs.com with SMTP; 2 Sep 2011 12:26:53 -0000 X-IronPort-AV: E=Sophos;i="4.68,319,1312156800"; d="scan'208";a="7572669" Received: from lonpmailmx01.citrite.net ([10.30.203.162]) by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5; 02 Sep 2011 12:26:43 +0000 Received: from kaball.uk.xensource.com (10.80.2.59) by LONPMAILMX01.citrite.net (10.30.203.162) with Microsoft SMTP Server id 8.3.137.0; Fri, 2 Sep 2011 13:26:43 +0100 Date: Fri, 2 Sep 2011 13:34:34 +0100 From: Stefano Stabellini X-X-Sender: sstabellini@kaball-desktop To: Stefan Bader In-Reply-To: <4E5F5B12.4080206@canonical.com> Message-ID: References: <4E5F5B12.4080206@canonical.com> User-Agent: Alpine 2.00 (DEB 1167 2008-08-23) MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Cc: Jeremy Fitzhardinge , "xen-devel@lists.xensource.com" , Stabellini , Stefano Subject: [Xen-devel] Re: HVM guests and pvlocks not working as expected X-BeenThere: xen-devel@lists.xensource.com X-Mailman-Version: 2.1.5 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xensource.com Errors-To: xen-devel-bounces@lists.xensource.com On Thu, 1 Sep 2011, Stefan Bader wrote: > After much joy with this, I thought I post this to a bigger audience. After > having migrated to Xen 4.1.1, booting HVM guests had several issues. Some > related to interrupts not being set up correctly (which Stefano has posted > patches) and even with those 3.0 guests seem to hang for me while 2.6.38 or > older kernels were ok. > > After digging deeply into this, I think I found the issue. However, if that is > true, it seems rather lucky if pv spinlocks in HVM worked for anybody. > > The xen_hvm_smp_init() call will change the smp_ops hooks. One of which is > smp_prepare_cpus. This is done in start_kernel and at this point in time, there > is no change to the pv_lock_ops and they point to the ticket versions. > Later in start_kernel, check_bugs is called and part of that takes the > pv_lock_ops and patches the kernel with the correct jumps. > _After_ that, the kernel_init is called and that in turn does the > smp_prepare_cpus which now changes the pv_lock_ops again, *but not* run any > patching again. So the _raw_spin_*lock calls still use the ticket calls. > > start_kernel > setup_arch -> xen_hvm_smp_init (set smp_ops) > ... > check_bugs -> alternative_instructions (patches pv_locks sites) > ... > rest_init (triggers kernel_init as a thread) > kernel_init > ... > smp_prepare_cpus (calls xen_init_spinlocks through smp_ops hook) > > To make things even more fun, there is the possibility that some spinlock > functions are forced to be inlined and others are not (CONFIG_INLINE_SPIN_*). In > our special case only two versions of spin_unlock were inlined. Put that > together into a pot with modules, shake well, and there is the fun. Basically on > load time, the non-inline calls remain pointing to the unmodified ticket > implementation (main kernel). But the unlock calls (which are inlined) get > modified because the loaded module gets patched up. One can imagine that this > does not work too well. > > Anyway, even without the secondary issue, I am sure that just replacing the > functions in pv_lock_ops without the spinlock calls getting actually modified is > not the intended behaviour. > > Unfortunately I have not yet been able to make it work. Any attempt to move > xen_init_spinlocks to be called before check_bugs or adding a call to > alternative_instructions results in another hang on boot. At least the latter > method results in a more usable dump for crash, which shows that on spinlock was > taken (slow) and two spurious taken ones (this is more to play for me). > > But then, maybe someone has some ideas there... we have two possible ways to solve this problem: 1) we wait for Jeremy's pv ticketlock series to be applied, that should make the datastructure internally used by native ticketlock and pv tickerlock identical, so a lock taken by the native ticket spin lock function can be freed by the xen pv ticket spin unlock function. 2) we add a very early hook to call xen_init_spinlocks() before any spinlocks have been taken, that means earlier than init_hypervisor_platform() _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel From xen-devel-bounces@lists.xensource.com Fri Sep 02 05:52:14 2011 Return-path: Envelope-to: www-data@lists.xensource.com Delivery-date: Fri, 02 Sep 2011 05:52:14 -0700 Received: from localhost ([127.0.0.1] helo=lists.colo.xensource.com) by lists.xensource.com with esmtp (Exim 4.43) id 1QzTEE-0000sN-C1; Fri, 02 Sep 2011 05:52:14 -0700 Received: from mail21.messagelabs.com ([85.158.143.35]) by lists.xensource.com with esmtp (Exim 4.43) id 1QzTDe-0000fk-Hy for xen-devel@lists.xensource.com; Fri, 02 Sep 2011 05:51:41 -0700 X-Env-Sender: konrad@dumpdata.com X-Msg-Ref: server-11.tower-21.messagelabs.com!1314967878!41107923!1 X-Originating-IP: [141.146.126.227] X-StarScan-Version: 6.3.6; banners=-,-,- X-VirusChecked: Checked Received: (qmail 28918 invoked from network); 2 Sep 2011 12:51:20 -0000 Received: from acsinet15.oracle.com (HELO acsinet15.oracle.com) (141.146.126.227) by server-11.tower-21.messagelabs.com with DHE-RSA-AES256-SHA encrypted SMTP; 2 Sep 2011 12:51:20 -0000 Received: from rtcsinet22.oracle.com (rtcsinet22.oracle.com [66.248.204.30]) by acsinet15.oracle.com (Switch-3.4.4/Switch-3.4.4) with ESMTP id p82CpT1U003559 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Fri, 2 Sep 2011 12:51:31 GMT Received: from acsmt358.oracle.com (acsmt358.oracle.com [141.146.40.158]) by rtcsinet22.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id p82CpRhk022964 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 2 Sep 2011 12:51:28 GMT Received: from abhmt110.oracle.com (abhmt110.oracle.com [141.146.116.62]) by acsmt358.oracle.com (8.12.11.20060308/8.12.11) with ESMTP id p82CpLLR007605; Fri, 2 Sep 2011 07:51:21 -0500 Received: from phenom (/209.6.55.207) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Fri, 02 Sep 2011 05:51:21 -0700 Received: by phenom (Postfix, from userid 1000) id E430B1211; Thu, 1 Sep 2011 15:29:22 -0400 (EDT) Date: Thu, 1 Sep 2011 15:29:22 -0400 From: Konrad Rzeszutek Wilk To: Daniel De Graaf Message-ID: <20110901192922.GB21520@dumpdata.com> References: <1313764724-12683-1-git-send-email-dgdegra@tycho.nsa.gov> <1314894138-28747-1-git-send-email-dgdegra@tycho.nsa.gov> <1314894138-28747-2-git-send-email-dgdegra@tycho.nsa.gov> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <1314894138-28747-2-git-send-email-dgdegra@tycho.nsa.gov> User-Agent: Mutt/1.5.21 (2010-09-15) X-Source-IP: rtcsinet22.oracle.com [66.248.204.30] X-CT-RefId: str=0001.0A090209.4E60D153.00F9,ss=1,re=0.000,fgs=0 Cc: Ian.Campbell@eu.citrix.com, xen-devel@lists.xensource.com, Ian.Jackson@eu.citrix.com, Stefano.Stabellini@eu.citrix.com Subject: [Xen-devel] Re: [PATCH 1/3] libxc: add xc_gnttab_map_grant_ref_notify X-BeenThere: xen-devel@lists.xensource.com X-Mailman-Version: 2.1.5 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xensource.com Errors-To: xen-devel-bounces@lists.xensource.com On Thu, Sep 01, 2011 at 12:22:16PM -0400, Daniel De Graaf wrote: > Normally, when a userspace process mapping a grant crashes, the domain > providing the reference receives no indication that its peer has > crashed, possibly leading to unexpected freezes or timeouts. This > function provides a notification of the unmap by signalling an event > channel and/or clearing a specific byte in the page. > > Signed-off-by: Daniel De Graaf > --- > tools/libxc/xc_gnttab.c | 15 ++++++++++++ > tools/libxc/xc_linux_osdep.c | 52 ++++++++++++++++++++++++++++++++++++++++++ > tools/libxc/xenctrl.h | 21 +++++++++++++++++ > tools/libxc/xenctrlosdep.h | 5 ++++ > 4 files changed, 93 insertions(+), 0 deletions(-) > > diff --git a/tools/libxc/xc_gnttab.c b/tools/libxc/xc_gnttab.c > index 4f55fce..dc7aa0c 100644 > --- a/tools/libxc/xc_gnttab.c > +++ b/tools/libxc/xc_gnttab.c > @@ -174,6 +174,21 @@ void *xc_gnttab_map_domain_grant_refs(xc_gnttab *xcg, > count, domid, refs, prot); > } > > +void *xc_gnttab_map_grant_ref_notify(xc_gnttab *xcg, > + uint32_t domid, > + uint32_t ref, > + uint32_t notify_offset, > + evtchn_port_t notify_port) > +{ > + if (xcg->ops->u.gnttab.map_grant_ref_notify) > + return xcg->ops->u.gnttab.map_grant_ref_notify(xcg, xcg->ops_handle, > + domid, ref, notify_offset, notify_port); > + else > + return xcg->ops->u.gnttab.map_grant_ref(xcg, xcg->ops_handle, > + domid, ref, PROT_READ|PROT_WRITE); > +} > + > + > int xc_gnttab_munmap(xc_gnttab *xcg, > void *start_address, > uint32_t count) > diff --git a/tools/libxc/xc_linux_osdep.c b/tools/libxc/xc_linux_osdep.c > index dca6718..8f7718f 100644 > --- a/tools/libxc/xc_linux_osdep.c > +++ b/tools/libxc/xc_linux_osdep.c > @@ -613,6 +613,57 @@ static void *linux_gnttab_map_domain_grant_refs(xc_gnttab *xcg, xc_osdep_handle > return do_gnttab_map_grant_refs(xcg, h, count, &domid, 0, refs, prot); > } > > +static void *linux_gnttab_map_grant_ref_notify(xc_gnttab *xch, xc_osdep_handle h, > + uint32_t domid, uint32_t ref, > + uint32_t notify_offset, > + evtchn_port_t notify_port) > +{ > + int fd = (int)h; > + struct ioctl_gntdev_map_grant_ref map; > + struct ioctl_gntdev_unmap_notify notify; That looks a bit odd. Like the formatting is off? > + void *addr; > + > + map.count = 1; > + map.refs[0].domid = domid; > + map.refs[0].ref = ref; > + > + if ( ioctl(fd, IOCTL_GNTDEV_MAP_GRANT_REF, &map) ) { > + PERROR("xc_gnttab_map_grant_ref: ioctl MAP_GRANT_REF failed"); > + return NULL; > + } > + > + addr = mmap(NULL, XC_PAGE_SIZE, PROT_READ|PROT_WRITE, MAP_SHARED, fd, map.index); > + if ( addr == MAP_FAILED ) > + { > + int saved_errno = errno; > + struct ioctl_gntdev_unmap_grant_ref unmap_grant; > + > + PERROR("xc_gnttab_map_grant_ref: mmap failed"); > + unmap_grant.index = map.index; > + unmap_grant.count = 1; > + ioctl(fd, IOCTL_GNTDEV_UNMAP_GRANT_REF, &unmap_grant); > + errno = saved_errno; > + return NULL; > + } > + > + notify.index = map.index; > + notify.action = 0; > + if (notify_offset >= 0) { > + notify.index += notify_offset; > + notify.action |= UNMAP_NOTIFY_CLEAR_BYTE; > + } > + if (notify_port >= 0) { > + notify.event_channel_port = notify_port; > + notify.action |= UNMAP_NOTIFY_SEND_EVENT; > + } > + if (notify.action && ioctl(fd, IOCTL_GNTDEV_SET_UNMAP_NOTIFY, ¬ify)) { > + PERROR("linux_gnttab_map_grant_ref_notify: ioctl SET_UNMAP_NOTIFY failed"); Perhaps reporting via an argument that we failed at doing the notify would be useful? That way at least you know you need to do polling. > + } > + > + return addr; > +} > + > + > static int linux_gnttab_munmap(xc_gnttab *xcg, xc_osdep_handle h, > void *start_address, uint32_t count) > { > @@ -662,6 +713,7 @@ static struct xc_osdep_ops linux_gnttab_ops = { > .map_grant_ref = &linux_gnttab_map_grant_ref, > .map_grant_refs = &linux_gnttab_map_grant_refs, > .map_domain_grant_refs = &linux_gnttab_map_domain_grant_refs, > + .map_grant_ref_notify = &linux_gnttab_map_grant_ref_notify, > .munmap = &linux_gnttab_munmap, > }, > }; > diff --git a/tools/libxc/xenctrl.h b/tools/libxc/xenctrl.h > index 1b82ee0..7859571 100644 > --- a/tools/libxc/xenctrl.h > +++ b/tools/libxc/xenctrl.h > @@ -1349,6 +1349,27 @@ void *xc_gnttab_map_domain_grant_refs(xc_gnttab *xcg, > int prot); > > /* > + * Memory maps a grant reference from one domain to a local address range. > + * Mappings should be unmapped with xc_gnttab_munmap. Logs errors. ^^^^^^^^^^^^ .. that looks odd? > + * This version always maps writable pages, and will attempt to set up > + * an unmap notification at the given offset and event channel. When the > + * page is unmapped, the byte at the given offset will be zeroed and a > + * wakeup will be sent to the given event channel. > + * > + * @parm xcg a handle on an open grant table interface > + * @parm domid the domain to map memory from > + * @parm ref the grant reference ID to map > + * @parm notify_offset The byte offset in the page to use for unmap > + * notification; -1 for none. > + * @parm notify_port The event channel port to use for unmap notify, or -1 > + */ > +void *xc_gnttab_map_grant_ref_notify(xc_gnttab *xcg, > + uint32_t domid, > + uint32_t ref, > + uint32_t notify_offset, > + evtchn_port_t notify_port); > + > +/* > * Unmaps the @count pages starting at @start_address, which were mapped by a > * call to xc_gnttab_map_grant_ref or xc_gnttab_map_grant_refs. Never logs. > */ > diff --git a/tools/libxc/xenctrlosdep.h b/tools/libxc/xenctrlosdep.h > index bfe46e0..01969c5 100644 > --- a/tools/libxc/xenctrlosdep.h > +++ b/tools/libxc/xenctrlosdep.h > @@ -119,6 +119,11 @@ struct xc_osdep_ops > uint32_t domid, > uint32_t *refs, > int prot); > + void *(*map_grant_ref_notify)(xc_gnttab *xcg, xc_osdep_handle h, > + uint32_t domid, > + uint32_t ref, > + uint32_t notify_offset, > + evtchn_port_t notify_port); > int (*munmap)(xc_gnttab *xcg, xc_osdep_handle h, > void *start_address, > uint32_t count); > -- > 1.7.6 _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel From xen-devel-bounces@lists.xensource.com Fri Sep 02 05:53:06 2011 Return-path: Envelope-to: www-data@lists.xensource.com Delivery-date: Fri, 02 Sep 2011 05:53:06 -0700 Received: from localhost ([127.0.0.1] helo=lists.colo.xensource.com) by lists.xensource.com with esmtp (Exim 4.43) id 1QzTF4-0001FU-FK; Fri, 02 Sep 2011 05:53:06 -0700 Received: from mail216.messagelabs.com ([85.158.143.99]) by lists.xensource.com with esmtp (Exim 4.43) id 1QzTDe-0000fj-2f for xen-devel@lists.xensource.com; Fri, 02 Sep 2011 05:51:41 -0700 X-Env-Sender: konrad@dumpdata.com X-Msg-Ref: server-10.tower-216.messagelabs.com!1314967893!8772479!1 X-Originating-IP: [141.146.126.227] X-StarScan-Version: 6.3.6; banners=-,-,- X-VirusChecked: Checked Received: (qmail 23527 invoked from network); 2 Sep 2011 12:51:34 -0000 Received: from acsinet15.oracle.com (HELO acsinet15.oracle.com) (141.146.126.227) by server-10.tower-216.messagelabs.com with DHE-RSA-AES256-SHA encrypted SMTP; 2 Sep 2011 12:51:34 -0000 Received: from acsinet22.oracle.com (acsinet22.oracle.com [141.146.126.238]) by acsinet15.oracle.com (Switch-3.4.4/Switch-3.4.4) with ESMTP id p82CpRlV003530 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Fri, 2 Sep 2011 12:51:29 GMT Received: from acsmt356.oracle.com (acsmt356.oracle.com [141.146.40.156]) by acsinet22.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id p82CpRSI020769 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 2 Sep 2011 12:51:27 GMT Received: from abhmt117.oracle.com (abhmt117.oracle.com [141.146.116.69]) by acsmt356.oracle.com (8.12.11.20060308/8.12.11) with ESMTP id p82CpLD1005692; Fri, 2 Sep 2011 07:51:21 -0500 Received: from phenom (/209.6.55.207) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Fri, 02 Sep 2011 05:51:21 -0700 Received: by phenom (Postfix, from userid 1000) id 3343B10D8; Thu, 1 Sep 2011 15:24:55 -0400 (EDT) Date: Thu, 1 Sep 2011 15:24:55 -0400 From: Konrad Rzeszutek Wilk To: Daniel De Graaf Message-ID: <20110901192455.GA21520@dumpdata.com> References: <1313764724-12683-1-git-send-email-dgdegra@tycho.nsa.gov> <1314894138-28747-1-git-send-email-dgdegra@tycho.nsa.gov> <1314894138-28747-3-git-send-email-dgdegra@tycho.nsa.gov> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <1314894138-28747-3-git-send-email-dgdegra@tycho.nsa.gov> User-Agent: Mutt/1.5.21 (2010-09-15) X-Source-IP: acsinet22.oracle.com [141.146.126.238] X-Auth-Type: Internal IP X-CT-RefId: str=0001.0A090203.4E60D151.0148:SCFMA922111,ss=1,re=-6.300,fgs=0 Cc: Ian.Campbell@eu.citrix.com, xen-devel@lists.xensource.com, Ian.Jackson@eu.citrix.com, Stefano.Stabellini@eu.citrix.com Subject: [Xen-devel] Re: [PATCH 2/3] libxc: add xc_gntshr_* functions X-BeenThere: xen-devel@lists.xensource.com X-Mailman-Version: 2.1.5 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xensource.com Errors-To: xen-devel-bounces@lists.xensource.com On Thu, Sep 01, 2011 at 12:22:17PM -0400, Daniel De Graaf wrote: > These functions and the xc_gntshr device (/dev/xen/gntalloc on linux) > allow applications to create pages shared with other domains. > > Signed-off-by: Daniel De Graaf > --- > tools/libxc/xc_gnttab.c | 27 +++++++++ > tools/libxc/xc_linux_osdep.c | 121 ++++++++++++++++++++++++++++++++++++++++++ > tools/libxc/xc_private.c | 13 +++++ > tools/libxc/xenctrl.h | 48 +++++++++++++++++ > tools/libxc/xenctrlosdep.h | 13 +++++ > 5 files changed, 222 insertions(+), 0 deletions(-) > > diff --git a/tools/libxc/xc_gnttab.c b/tools/libxc/xc_gnttab.c > index dc7aa0c..ffa3550 100644 > --- a/tools/libxc/xc_gnttab.c > +++ b/tools/libxc/xc_gnttab.c > @@ -204,6 +204,33 @@ int xc_gnttab_set_max_grants(xc_gnttab *xcg, uint32_t count) > return xcg->ops->u.gnttab.set_max_grants(xcg, xcg->ops_handle, count); > } > > +void *xc_gntshr_share_pages(xc_gntshr *xcg, uint32_t domid, > + int count, uint32_t *refs, int writable) > +{ > + return xcg->ops->u.gntshr.share_pages(xcg, xcg->ops_handle, domid, > + count, refs, writable); > +} > + > +void *xc_gntshr_share_page_notify(xc_gntshr *xcg, uint32_t domid, > + uint32_t *ref, int writable, > + uint32_t notify_offset, > + evtchn_port_t notify_port) > +{ > + return xcg->ops->u.gntshr.share_page_notify(xcg, xcg->ops_handle, > + domid, ref, writable, notify_offset, notify_port); > +} > + > +/* > + * Unmaps the @count pages starting at @start_address, which were mapped by a > + * call to xc_gntshr_share_*. Never logs. > + */ > +int xc_gntshr_munmap(xc_gntshr *xcg, void *start_address, uint32_t count) > +{ > + return xcg->ops->u.gntshr.munmap(xcg, xcg->ops_handle, > + start_address, count); > +} > + > + > /* > * Local variables: > * mode: C > diff --git a/tools/libxc/xc_linux_osdep.c b/tools/libxc/xc_linux_osdep.c > index 8f7718f..871d37c 100644 > --- a/tools/libxc/xc_linux_osdep.c > +++ b/tools/libxc/xc_linux_osdep.c > @@ -34,6 +34,7 @@ > #include > #include > #include > +#include > > #include "xenctrl.h" > #include "xenctrlosdep.h" > @@ -718,6 +719,124 @@ static struct xc_osdep_ops linux_gnttab_ops = { > }, > }; > > +static xc_osdep_handle linux_gntshr_open(xc_gntshr *xcg) > +{ > + int fd = open(DEVXEN "gntalloc", O_RDWR); > + > + if ( fd == -1 ) > + return XC_OSDEP_OPEN_ERROR; > + > + return (xc_osdep_handle)fd; > +} > + > +static int linux_gntshr_close(xc_gntshr *xcg, xc_osdep_handle h) > +{ > + int fd = (int)h; > + return close(fd); > +} > + > +static void *linux_gntshr_share_pages(xc_gntshr *xch, xc_osdep_handle h, > + uint32_t domid, int count, > + uint32_t *refs, int writable) > +{ > + struct ioctl_gntalloc_alloc_gref *gref_info = NULL; > + int err; > + void *area = NULL; > + gref_info = malloc(sizeof(*gref_info) + count * sizeof(uint32_t)); > + if (!gref_info) > + return NULL; > + gref_info->domid = domid; > + gref_info->flags = writable ? GNTALLOC_FLAG_WRITABLE : 0; > + gref_info->count = count; > + > + err = ioctl((int)h, IOCTL_GNTALLOC_ALLOC_GREF, gref_info); > + if (err) { > + PERROR("linux_gntshr_share_pages: ioctl failed"); > + goto out; > + } > + > + area = mmap(NULL, count * XC_PAGE_SIZE, PROT_READ | PROT_WRITE, > + MAP_SHARED, (int)h, gref_info->index); > + > + if (area == MAP_FAILED) { > + area = NULL; > + PERROR("linux_gntshr_share_pages: mmap failed"); > + goto out; > + } > + > + memcpy(refs, gref_info->gref_ids, count * sizeof(uint32_t)); > + out: > + free(gref_info); > + return area; > +} > + > +static void *linux_gntshr_share_page_notify(xc_gntshr *xch, xc_osdep_handle h, > + uint32_t domid, uint32_t *ref, > + int writable, uint32_t notify_offset, > + evtchn_port_t notify_port) > +{ > + struct ioctl_gntalloc_alloc_gref gref_info; > + struct ioctl_gntalloc_unmap_notify notify; > + int err; > + int fd = (int)h; > + void *area = NULL; > + gref_info.domid = domid; > + gref_info.flags = writable ? GNTALLOC_FLAG_WRITABLE : 0; > + gref_info.count = 1; > + > + err = ioctl(fd, IOCTL_GNTALLOC_ALLOC_GREF, &gref_info); > + if (err) { > + PERROR("linux_gntshr_share_page_notify: ioctl failed"); > + goto out; > + } > + > + area = mmap(NULL, XC_PAGE_SIZE, PROT_READ | PROT_WRITE, > + MAP_SHARED, fd, gref_info.index); > + > + if (area == MAP_FAILED) { > + PERROR("linux_gntshr_share_page_notify: mmap failed"); > + area = NULL; > + goto out; > + } > + > + notify.index = gref_info.index; > + notify.action = 0; > + if (notify_offset >= 0) { > + notify.index += notify_offset; > + notify.action |= UNMAP_NOTIFY_CLEAR_BYTE; > + } > + if (notify_port >= 0) { > + notify.event_channel_port = notify_port; > + notify.action |= UNMAP_NOTIFY_SEND_EVENT; > + } > + if (notify.action && ioctl(fd, IOCTL_GNTALLOC_SET_UNMAP_NOTIFY, ¬ify)) { > + PERROR("linux_gntshr_share_page_notify: ioctl SET_UNMAP_NOTIFY failed"); Should we report to the caller that we can't set it up? Say by reporting via a bool (as in through the arguments )? > + } > + > + *ref = gref_info.gref_ids[0]; > + out: > + return area; > +} > + > + > +static int linux_gntshr_munmap(xc_gntshr *xcg, xc_osdep_handle h, > + void *start_address, uint32_t count) > +{ > + return munmap(start_address, count); > +} > + > +static struct xc_osdep_ops linux_gntshr_ops = { > + .open = &linux_gntshr_open, > + .close = &linux_gntshr_close, > + > + .u.gntshr = { > + .share_pages = &linux_gntshr_share_pages, > + .share_page_notify = &linux_gntshr_share_page_notify, > + .munmap = &linux_gntshr_munmap, > + }, > +}; > + > + > static struct xc_osdep_ops *linux_osdep_init(xc_interface *xch, enum xc_osdep_type type) > { > switch ( type ) > @@ -728,6 +847,8 @@ static struct xc_osdep_ops *linux_osdep_init(xc_interface *xch, enum xc_osdep_ty > return &linux_evtchn_ops; > case XC_OSDEP_GNTTAB: > return &linux_gnttab_ops; > + case XC_OSDEP_GNTSHR: > + return &linux_gntshr_ops; > default: > return NULL; > } > diff --git a/tools/libxc/xc_private.c b/tools/libxc/xc_private.c > index 09c8f23..09a91e7 100644 > --- a/tools/libxc/xc_private.c > +++ b/tools/libxc/xc_private.c > @@ -258,6 +258,19 @@ int xc_gnttab_close(xc_gnttab *xcg) > return xc_interface_close_common(xcg); > } > > +xc_gntshr *xc_gntshr_open(xentoollog_logger *logger, > + unsigned open_flags) > +{ > + return xc_interface_open_common(logger, NULL, open_flags, > + XC_OSDEP_GNTSHR); > +} > + > +int xc_gntshr_close(xc_gntshr *xcg) > +{ > + return xc_interface_close_common(xcg); > +} > + > + > static pthread_key_t errbuf_pkey; > static pthread_once_t errbuf_pkey_once = PTHREAD_ONCE_INIT; > > diff --git a/tools/libxc/xenctrl.h b/tools/libxc/xenctrl.h > index 7859571..374c705 100644 > --- a/tools/libxc/xenctrl.h > +++ b/tools/libxc/xenctrl.h > @@ -115,6 +115,7 @@ > typedef struct xc_interface_core xc_interface; > typedef struct xc_interface_core xc_evtchn; > typedef struct xc_interface_core xc_gnttab; > +typedef struct xc_interface_core xc_gntshr; > typedef enum xc_error_code xc_error_code; > > > @@ -1400,6 +1401,53 @@ grant_entry_v1_t *xc_gnttab_map_table_v1(xc_interface *xch, int domid, int *gnt_ > grant_entry_v2_t *xc_gnttab_map_table_v2(xc_interface *xch, int domid, int *gnt_num); > /* Sometimes these don't set errno [fixme], and sometimes they don't log. */ > > +/* > + * Return an fd onto the grant sharing driver. Logs errors. > + */ > +xc_gntshr *xc_gntshr_open(xentoollog_logger *logger, > + unsigned open_flags); > + > +/* > + * Close a handle previously allocated with xc_gntshr_open(). > + * Never logs errors. > + */ > +int xc_gntshr_close(xc_gntshr *xcg); > + > +/* > + * Creates and shares pages with another domain. > + * > + * @parm xcg a handle to an open grant sharing instance > + * @parm domid the domain to share memory with > + * @parm count the number of pages to share > + * @parm refs the grant references of the pages (output) > + * @parm writable true if the other domain can write to the pages > + * @return local mapping of the pages > + */ > +void *xc_gntshr_share_pages(xc_gntshr *xcg, uint32_t domid, > + int count, uint32_t *refs, int writable); > + > +/* > + * Creates and shares a page with another domain, with unmap notification. > + * > + * @parm xcg a handle to an open grant sharing instance > + * @parm domid the domain to share memory with > + * @parm refs the grant reference of the pages (output) > + * @parm writable true if the other domain can write to the page > + * @parm notify_offset The byte offset in the page to use for unmap > + * notification; -1 for none. > + * @parm notify_port The event channel port to use for unmap notify, or -1 > + * @return local mapping of the page > + */ > +void *xc_gntshr_share_page_notify(xc_gntshr *xcg, uint32_t domid, > + uint32_t *ref, int writable, > + uint32_t notify_offset, > + evtchn_port_t notify_port); > +/* > + * Unmaps the @count pages starting at @start_address, which were mapped by a > + * call to xc_gntshr_share_*. Never logs. > + */ > +int xc_gntshr_munmap(xc_gntshr *xcg, void *start_address, uint32_t count); > + > int xc_physdev_map_pirq(xc_interface *xch, > int domid, > int index, > diff --git a/tools/libxc/xenctrlosdep.h b/tools/libxc/xenctrlosdep.h > index 01969c5..e1c1ba5 100644 > --- a/tools/libxc/xenctrlosdep.h > +++ b/tools/libxc/xenctrlosdep.h > @@ -54,6 +54,7 @@ enum xc_osdep_type { > XC_OSDEP_PRIVCMD, > XC_OSDEP_EVTCHN, > XC_OSDEP_GNTTAB, > + XC_OSDEP_GNTSHR, > }; > > /* Opaque handle internal to the backend */ > @@ -129,6 +130,18 @@ struct xc_osdep_ops > uint32_t count); > int (*set_max_grants)(xc_gnttab *xcg, xc_osdep_handle h, uint32_t count); > } gnttab; > + struct { > + void *(*share_pages)(xc_gntshr *xcg, xc_osdep_handle h, > + uint32_t domid, int count, > + uint32_t *refs, int writable); > + void *(*share_page_notify)(xc_gntshr *xcg, xc_osdep_handle h, > + uint32_t domid, > + uint32_t *ref, int writable, > + uint32_t notify_offset, > + evtchn_port_t notify_port); > + int (*munmap)(xc_gntshr *xcg, xc_osdep_handle h, > + void *start_address, uint32_t count); > + } gntshr; > } u; > }; > typedef struct xc_osdep_ops xc_osdep_ops; > -- > 1.7.6 _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel From xen-devel-bounces@lists.xensource.com Fri Sep 02 06:04:06 2011 Return-path: Envelope-to: www-data@lists.xensource.com Delivery-date: Fri, 02 Sep 2011 06:04:06 -0700 Received: from localhost ([127.0.0.1] helo=lists.colo.xensource.com) by lists.xensource.com with esmtp (Exim 4.43) id 1QzTPh-00025F-Sw; Fri, 02 Sep 2011 06:04:05 -0700 Received: from mail216.messagelabs.com ([85.158.143.99]) by lists.xensource.com with smtp (Exim 4.43) id 1QzTN6-0001qT-9Y for xen-devel@lists.xensource.com; Fri, 02 Sep 2011 06:01:42 -0700 X-Env-Sender: Stefano.Stabellini@eu.citrix.com X-Msg-Ref: server-9.tower-216.messagelabs.com!1314968480!16862852!1 X-Originating-IP: [62.200.22.115] X-StarScan-Version: 6.3.6; banners=-,-,- X-VirusChecked: Checked Received: (qmail 22909 invoked from network); 2 Sep 2011 13:01:20 -0000 Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115) by server-9.tower-216.messagelabs.com with SMTP; 2 Sep 2011 13:01:20 -0000 X-IronPort-AV: E=Sophos;i="4.68,319,1312156800"; d="scan'208";a="7573439" Received: from lonpmailmx01.citrite.net ([10.30.203.162]) by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5; 02 Sep 2011 13:01:19 +0000 Received: from kaball.uk.xensource.com (10.80.2.59) by LONPMAILMX01.citrite.net (10.30.203.162) with Microsoft SMTP Server id 8.3.137.0; Fri, 2 Sep 2011 14:01:19 +0100 Date: Fri, 2 Sep 2011 14:09:10 +0100 From: Stefano Stabellini X-X-Sender: sstabellini@kaball-desktop To: Tim Deegan Subject: Re: [Xen-devel] Re: Linux Stubdom Problem In-Reply-To: <20110902110316.GA30893@ocelot.phlegethon.org> Message-ID: References: <20110901172728.GH3859@ocelot.phlegethon.org> <20110902110316.GA30893@ocelot.phlegethon.org> User-Agent: Alpine 2.00 (DEB 1167 2008-08-23) MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Cc: Anthony, "xen-devel@lists.xensource.com" , Stefano Stabellini , Konrad Rzeszutek Wilk , Ian Campbell , Keir Fraser , Jiageng Yu , PERARD , Samuel Thibault X-BeenThere: xen-devel@lists.xensource.com X-Mailman-Version: 2.1.5 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xensource.com Errors-To: xen-devel-bounces@lists.xensource.com On Fri, 2 Sep 2011, Tim Deegan wrote: > At 10:32 +0800 on 02 Sep (1314959538), Jiageng Yu wrote: > > 2011/9/2 Tim Deegan : > > > I would really rather not have this interface; I don't see why we can't > > > use grant tables for this. > > > > In linux based stubdom case, we want to keep hvm guest and its > > hvmloader unaware of running on stubdom. > > Why? HVMloader is already tightly coupled to the hypervisor and the > toostack - special cases for stubdoms should be fine. I think think that leaking the implementation details of the device model into hvmloader should be avoided, but obviously if there are no alternatives, it can be done. > > Therefore, we do need a way > > to map vram pages of stubdom into guest hvm transparently. > > I've suggested two so far: have grant mappings done from inside the > guest, or add a XENMAPSPACE that takes grant IDs. I think the > XENMAPSPACE is better; I suspect that save/restore will be easier to get > right that way. OK. I think we'll try the other approach first to see if it is easier: modify Linux xen-fbfront driver to take a list of pages from the guest for the vram. > > Another idea is to allocate vram in hvm guest and stubdom maps vram > > pages into its memory space. > > Sure. The minios-based stubdoms seem to manage that just fine. If this > is really difficult for a linux-based stub domain, then maybe that's a > reason not to use them. We could fully re-implement xen-fbfront in userspace inside qemu, at that point the problem would go away completely. Rather than duplicating all that code, we'll try to reuse Linux xen-fbfront implementation, making sure that xen-fbfront is loaded after qemu is started and initialized. _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel From xen-devel-bounces@lists.xensource.com Fri Sep 02 06:12:39 2011 Return-path: Envelope-to: www-data@lists.xensource.com Delivery-date: Fri, 02 Sep 2011 06:12:39 -0700 Received: from localhost ([127.0.0.1] helo=lists.colo.xensource.com) by lists.xensource.com with esmtp (Exim 4.43) id 1QzTXz-0002Ys-Gb; Fri, 02 Sep 2011 06:12:39 -0700 Received: from mail182.messagelabs.com ([85.158.139.83]) by lists.xensource.com with esmtp (Exim 4.43) id 1QzTXM-0002MB-7J for xen-devel@lists.xensource.com; Fri, 02 Sep 2011 06:12:03 -0700 X-Env-Sender: keir.xen@gmail.com X-Msg-Ref: server-5.tower-182.messagelabs.com!1314969117!11834688!1 X-Originating-IP: [74.125.82.171] X-StarScan-Version: 6.3.6; banners=-,-,- X-VirusChecked: Checked Received: (qmail 10555 invoked from network); 2 Sep 2011 13:11:57 -0000 Received: from mail-wy0-f171.google.com (HELO mail-wy0-f171.google.com) (74.125.82.171) by server-5.tower-182.messagelabs.com with RC4-SHA encrypted SMTP; 2 Sep 2011 13:11:57 -0000 Received: by wyh13 with SMTP id 13so2808366wyh.30 for ; Fri, 02 Sep 2011 06:11:56 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=user-agent:date:subject:from:to:cc:message-id:thread-topic :thread-index:in-reply-to:mime-version:content-type :content-transfer-encoding; bh=a60JQ07sQ20W5ZLkbfjs0BpjBdGI4VyUMJeihAcJLMA=; b=U6aswHZne3ZYKKDTikjKpXgQtiTIiC1VgA2GKpvNyFHJ5h4M7m8cLNUEwq6xp+rOAT 58PNa03lEey7j7ah4846zapetm2uVPS+6i1gmT8rimCbLmLL0Pg33u/hcIUS6FGgYJBl cEYZN2xjN0oY8/aP0FwGZ3WW/Zcv+Z21ElVFU= Received: by 10.227.203.213 with SMTP id fj21mr630382wbb.69.1314969116767; Fri, 02 Sep 2011 06:11:56 -0700 (PDT) Received: from [192.168.1.78] (host86-137-116-193.range86-137.btcentralplus.com [86.137.116.193]) by mx.google.com with ESMTPS id fq9sm1652759wbb.15.2011.09.02.06.11.51 (version=SSLv3 cipher=OTHER); Fri, 02 Sep 2011 06:11:55 -0700 (PDT) User-Agent: Microsoft-Entourage/12.30.0.110427 Date: Fri, 02 Sep 2011 14:11:45 +0100 Subject: Re: [Xen-devel] Re: Linux Stubdom Problem From: Keir Fraser To: Stefano Stabellini , Tim Deegan Message-ID: Thread-Topic: [Xen-devel] Re: Linux Stubdom Problem Thread-Index: Acxpcd0v1E2dk76LSkeV6O+GrFHaNQ== In-Reply-To: Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit Cc: "xen-devel@lists.xensource.com" , Konrad Rzeszutek Wilk , Ian Campbell , Jiageng Yu , Anthony PERARD , Samuel Thibault X-BeenThere: xen-devel@lists.xensource.com X-Mailman-Version: 2.1.5 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xensource.com Errors-To: xen-devel-bounces@lists.xensource.com On 02/09/2011 14:09, "Stefano Stabellini" wrote: >> Why? HVMloader is already tightly coupled to the hypervisor and the >> toostack - special cases for stubdoms should be fine. > > I think think that leaking the implementation details of the device > model into hvmloader should be avoided, but obviously if there are no > alternatives, it can be done. This is a fair and more general point, that we don't want fragile dependencies on qemu now that we are using upstream. But as I say that's a more general point on our policy regarding qemu, rather than something specifically concerning hvmloader. -- Keir _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel From xen-devel-bounces@lists.xensource.com Fri Sep 02 06:16:13 2011 Return-path: Envelope-to: www-data@lists.xensource.com Delivery-date: Fri, 02 Sep 2011 06:16:13 -0700 Received: from localhost ([127.0.0.1] helo=lists.colo.xensource.com) by lists.xensource.com with esmtp (Exim 4.43) id 1QzTbR-0002ye-Pz; Fri, 02 Sep 2011 06:16:13 -0700 Received: from mail174.messagelabs.com ([85.158.138.51]) by lists.xensource.com with smtp (Exim 4.43) id 1QzTas-0002m4-Js for xen-devel@lists.xensource.com; Fri, 02 Sep 2011 06:15:41 -0700 X-Env-Sender: Ian.Jackson@eu.citrix.com X-Msg-Ref: server-7.tower-174.messagelabs.com!1314969335!30003804!1 X-Originating-IP: [62.200.22.115] X-StarScan-Version: 6.3.6; banners=-,-,- X-VirusChecked: Checked Received: (qmail 1874 invoked from network); 2 Sep 2011 13:15:35 -0000 Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115) by server-7.tower-174.messagelabs.com with SMTP; 2 Sep 2011 13:15:35 -0000 X-IronPort-AV: E=Sophos;i="4.68,319,1312156800"; d="scan'208";a="7573889" Received: from lonpmailmx01.citrite.net ([10.30.203.162]) by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5; 02 Sep 2011 13:15:34 +0000 Received: from woking.xci-test.com (10.80.248.135) by smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id 8.3.137.0; Fri, 2 Sep 2011 14:15:34 +0100 Received: from osstest by woking.xci-test.com with local (Exim 4.69) (envelope-from ) id 1QzTao-0007Yj-B0; Fri, 02 Sep 2011 14:15:34 +0100 To: xen-devel@lists.xensource.com Message-ID: From: xen.org Date: Fri, 2 Sep 2011 14:15:34 +0100 MIME-Version: 1.0 Content-Type: text/plain Cc: ian.jackson@eu.citrix.com Subject: [Xen-devel] [xen-unstable test] 8823: regressions - FAIL X-BeenThere: xen-devel@lists.xensource.com X-Mailman-Version: 2.1.5 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xensource.com Errors-To: xen-devel-bounces@lists.xensource.com flight 8823 xen-unstable real [real] http://www.chiark.greenend.org.uk/~xensrcts/logs/8823/ Regressions :-( Tests which did not succeed and are blocking: test-amd64-amd64-xl-sedf 14 guest-localmigrate/x10 fail REGR. vs. 8760 Tests which are failing intermittently (not blocking): test-amd64-amd64-win 7 windows-install fail pass in 8822 test-amd64-amd64-xl-sedf 5 xen-boot fail in 8822 pass in 8823 test-i386-i386-win 14 guest-start.2 fail in 8822 pass in 8823 Tests which did not succeed, but are not blocking, including regressions (tests previously passed) regarded as allowable: test-amd64-amd64-xl-pcipt-intel 9 guest-start fail never pass test-amd64-i386-rhel6hvm-intel 9 guest-start.2 fail never pass test-amd64-i386-win-vcpus1 16 leak-check/check fail never pass test-amd64-i386-rhel6hvm-amd 9 guest-start.2 fail never pass test-amd64-i386-win 16 leak-check/check fail never pass test-amd64-amd64-xl-win 13 guest-stop fail never pass test-i386-i386-xl-win 13 guest-stop fail never pass test-i386-i386-win 16 leak-check/check fail never pass test-amd64-i386-xl-win-vcpus1 13 guest-stop fail never pass test-amd64-amd64-win 16 leak-check/check fail in 8822 never pass version targeted for testing: xen a6a5bda3c962 baseline version: xen ac9aa65050e9 ------------------------------------------------------------ People who touched revisions under test: Andrew Cooper Christoph Egger Dietmar Hahn Ian Campbell Ian Jackson Keir Fraser Kevin Tian Laszlo Ersek Olaf Hering Stefano Stabellini Tim Deegan ------------------------------------------------------------ jobs: build-amd64 pass build-i386 pass build-amd64-oldkern pass build-i386-oldkern pass build-amd64-pvops pass build-i386-pvops pass test-amd64-amd64-xl pass test-amd64-i386-xl pass test-i386-i386-xl pass test-amd64-i386-rhel6hvm-amd fail test-amd64-i386-xl-credit2 pass test-amd64-amd64-xl-pcipt-intel fail test-amd64-i386-rhel6hvm-intel fail test-amd64-i386-xl-multivcpu pass test-amd64-amd64-pair pass test-amd64-i386-pair pass test-i386-i386-pair pass test-amd64-amd64-pv pass test-amd64-i386-pv pass test-i386-i386-pv pass test-amd64-amd64-xl-sedf fail test-amd64-i386-win-vcpus1 fail test-amd64-i386-xl-win-vcpus1 fail test-amd64-amd64-win fail test-amd64-i386-win fail test-i386-i386-win fail test-amd64-amd64-xl-win fail test-i386-i386-xl-win fail ------------------------------------------------------------ sg-report-flight on woking.cam.xci-test.com logs: /home/xc_osstest/logs images: /home/xc_osstest/images Logs, config files, etc. are available at http://www.chiark.greenend.org.uk/~xensrcts/logs Test harness code can be found at http://xenbits.xensource.com/gitweb?p=osstest.git;a=summary Not pushing. ------------------------------------------------------------ changeset: 23810:a6a5bda3c962 tag: tip user: Ian Campbell date: Thu Sep 01 17:46:43 2011 +0100 xen/x86: only support >128 CPUs on x86_64 32 bit cannot cope with 256 cpus and hits: /* At least half the ioremap space should be available to us. */ BUILD_BUG_ON(IOREMAP_VIRT_START + (IOREMAP_MBYTES << 19) >= FIXADDR_START); Signed-off-by: Ian Campbell changeset: 23809:85b29185c911 user: Tim Deegan date: Thu Sep 01 09:39:25 2011 +0100 x86/mm: use defines for page sizes rather hardcoding them. Signed-off-by: Christoph Egger Acked-by: Tim Deegan Committed-by: Tim Deegan changeset: 23808:4a4882df5649 user: Stefano Stabellini date: Wed Aug 31 15:23:49 2011 +0100 xen: get_free_pirq: make sure that the returned pirq is allocated Signed-off-by: Stefano Stabellini changeset: 23807:2297b90a6a7b user: Stefano Stabellini date: Wed Aug 31 15:23:34 2011 +0100 xen: __hvm_pci_intx_assert should check for gsis remapped onto pirqs If the isa irq corresponding to a particular gsi is disabled while the gsi is enabled, __hvm_pci_intx_assert will always inject the gsi through the violapic, even if the gsi has been remapped onto a pirq. This patch makes sure that even in this case we inject the notification appropriately. Signed-off-by: Stefano Stabellini changeset: 23806:4226ea1785b5 user: Stefano Stabellini date: Wed Aug 31 15:23:12 2011 +0100 xen: fix hvm_domain_use_pirq's behavior hvm_domain_use_pirq should return true when the guest is using a certain pirq, no matter if the corresponding event channel is currently enabled or disabled. As an additional complication, qemu is going to request pirqs for passthrough devices even for Xen unaware HVM guests, so we need to wait for an event channel to be connected before considering the pirq of a passthrough device as "in use". Signed-off-by: Stefano Stabellini changeset: 23805:7048810180de user: Andrew Cooper date: Wed Aug 31 15:19:24 2011 +0100 IRQ: manually EOI migrating line interrupts When migrating IO-APIC line level interrupts between PCPUs, the migration code rewrites the IO-APIC entry to point to the new CPU/Vector before EOI'ing it. The EOI process says that EOI'ing the Local APIC will cause a broadcast with the vector number, which the IO-APIC must listen to to clear the IRR and Status bits. In the case of migrating, the IO-APIC has already been reprogrammed so the EOI broadcast with the old vector fails to match the new vector, leaving the IO-APIC with an outstanding vector, preventing any more use of that line interrupt. This causes a lockup especially when your root device is using PCI INTA (megaraid_sas driver *ehem*) However, the problem is mostly hidden because send_cleanup_vector() causes a cleanup of all moving vectors on the current PCPU in such a way which does not cause the problem, and if the problem has occured, the writes it makes to the IO-APIC clears the IRR and Status bits which unlocks the problem. This fix is distinctly a temporary hack, waiting on a cleanup of the irq code. It checks for the edge case where we have moved the irq, and manually EOI's the old vector with the IO-APIC which correctly clears the IRR and Status bits. Also, it protects the code which updates irq_cfg by disabling interrupts. Signed-off-by: Andrew Cooper changeset: 23804:42d76c68b2bf user: Kevin Tian date: Wed Aug 31 15:18:23 2011 +0100 x86: add irq count for IPIs such count is useful to assist decision make in cpuidle governor, while w/o this patch only device interrupts through do_IRQ is currently counted. Signed-off-by: Kevin Tian changeset: 23803:51983821efa4 user: Dietmar Hahn date: Wed Aug 31 15:17:45 2011 +0100 vpmu: Add processors Westmere E7-8837 and SandyBridge i5-2500 to the vpmu list Signed-off-by: Dietmar Hahn changeset: 23802:bb9b81008733 user: Laszlo Ersek date: Wed Aug 31 15:16:14 2011 +0100 x86: Increase the default NR_CPUS to 256 Changeset 21012:ef845a385014 bumped the default to 128 about one and a half years ago. Increase it now to 256, as systems with eg. 160 logical CPUs are becoming (have become) common. Signed-off-by: Laszlo Ersek changeset: 23801:d54cfae72cd1 user: Christoph Egger date: Wed Aug 31 15:15:41 2011 +0100 nestedsvm: VMRUN doesn't use nextrip VMRUN does not use nextrip. So remove pointless assignment. Signed-off-by: Christoph Egger changeset: 23800:72edc40e2942 user: Keir Fraser date: Wed Aug 31 15:14:49 2011 +0100 x86-64: Fix off-by-one error in __addr_ok() macro Signed-off-by: Laszlo Ersek Signed-off-by: Keir Fraser changeset: 23799:ac9aa65050e9 parent: 23798:469aa1fbd843 parent: 23797:2c687e70a343 user: Ian Jackson date: Tue Aug 30 11:46:58 2011 +0100 Merge ======================================== commit cd776ee9408ff127f934a707c1a339ee600bc127 Author: Ian Jackson Date: Tue Jun 28 13:50:53 2011 +0100 qemu-char.c: fix incorrect CONFIG_STUBDOM handling qemu-char.c:1123:7: warning: "CONFIG_STUBDOM" is not defined [-Wundef] Signed-off-by: Olaf Hering Acked-by: Ian Jackson _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel From xen-devel-bounces@lists.xensource.com Fri Sep 02 06:30:13 2011 Return-path: Envelope-to: www-data@lists.xensource.com Delivery-date: Fri, 02 Sep 2011 06:30:13 -0700 Received: from localhost ([127.0.0.1] helo=lists.colo.xensource.com) by lists.xensource.com with esmtp (Exim 4.43) id 1QzToz-0003Ym-P5; Fri, 02 Sep 2011 06:30:13 -0700 Received: from mail27.messagelabs.com ([193.109.254.147]) by lists.xensource.com with esmtp (Exim 4.43) id 1QzTnw-0003Lu-Kg for xen-devel@lists.xensource.com; Fri, 02 Sep 2011 06:29:09 -0700 X-Env-Sender: konrad@dumpdata.com X-Msg-Ref: server-14.tower-27.messagelabs.com!1314970131!34514370!1 X-Originating-IP: [141.146.126.227] X-StarScan-Version: 6.3.6; banners=-,-,- X-VirusChecked: Checked Received: (qmail 23194 invoked from network); 2 Sep 2011 13:28:53 -0000 Received: from acsinet15.oracle.com (HELO acsinet15.oracle.com) (141.146.126.227) by server-14.tower-27.messagelabs.com with DHE-RSA-AES256-SHA encrypted SMTP; 2 Sep 2011 13:28:53 -0000 Received: from acsinet22.oracle.com (acsinet22.oracle.com [141.146.126.238]) by acsinet15.oracle.com (Switch-3.4.4/Switch-3.4.4) with ESMTP id p82DSb3V016066 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Fri, 2 Sep 2011 13:28:39 GMT Received: from acsmt357.oracle.com (acsmt357.oracle.com [141.146.40.157]) by acsinet22.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id p82DSaBR011455 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 2 Sep 2011 13:28:37 GMT Received: from abhmt118.oracle.com (abhmt118.oracle.com [141.146.116.70]) by acsmt357.oracle.com (8.12.11.20060308/8.12.11) with ESMTP id p82DSVh1004911; Fri, 2 Sep 2011 08:28:31 -0500 Received: from phenom (/209.6.55.207) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Fri, 02 Sep 2011 06:28:31 -0700 Received: by phenom (Postfix, from userid 1000) id 549A3E45; Fri, 2 Sep 2011 09:28:30 -0400 (EDT) Date: Fri, 2 Sep 2011 09:28:30 -0400 From: Konrad Rzeszutek Wilk To: Li Dongyang Message-ID: <20110902132830.GB5088@dumpdata.com> References: <20110901152534.GA6965@dumpdata.com> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.21 (2010-09-15) Content-Transfer-Encoding: quoted-printable X-Source-IP: acsinet22.oracle.com [141.146.126.238] X-Auth-Type: Internal IP X-CT-RefId: str=0001.0A090201.4E60DA1D.0089:SCFMA922111,ss=1,re=-4.000,fgs=0 Cc: xen-devel@lists.xensource.com, owen.smith@citrix.com, JBeulich@novell.com Subject: [Xen-devel] Re: [PATCH V4 2/3] xen-blkfront: teach blkfront driver to handle discard requests X-BeenThere: xen-devel@lists.xensource.com X-Mailman-Version: 2.1.5 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xensource.com Errors-To: xen-devel-bounces@lists.xensource.com On Fri, Sep 02, 2011 at 02:30:03PM +0800, Li Dongyang wrote: > On Thu, Sep 1, 2011 at 11:25 PM, Konrad Rzeszutek Wilk > wrote: > > On Thu, Sep 01, 2011 at 06:39:09PM +0800, Li Dongyang wrote: > >> The blkfront driver now will read discard related nodes from xenstor= e, > >> and set up the request queue, then we can forward the > >> discard requests to backend driver. > > > > > > A better description is as follow: > > > > xen-blkfront: Handle discard requests. > > > > =A0 =A0If the backend advertises 'feature-discard', then interrogate > > =A0 =A0the backend for alignment, granularity, and max discard block = size. > > =A0 =A0Setup the request queue with the appropiate values and send th= e > > =A0 =A0discard operation as required. > > > thanks for the description, way better than mine :-) OK. Lets use that. .. snip.. > >> + =A0 =A0 if (info->feature_discard) { > >> + =A0 =A0 =A0 =A0 =A0 =A0 queue_flag_set_unlocked(QUEUE_FLAG_DISCARD= , rq); > >> + =A0 =A0 =A0 =A0 =A0 =A0 blk_queue_max_discard_sectors(rq, get_capa= city(gd)); > > > > This is not correct. I took a look at the SCSI support for this > > ('sd_config_discard') and if you look there carefully you will see th= at > > the value can be 64KB for example. > well I don't think so, max_discard_sectors are used to split the bio, > make them not to > exceed the max_discard_sectors, see blkdev_issue_discard, and > that's fine if we use the capacity as max_discard_sectors > in guest: for file backend, there's no need for max_discard_sectors, > and for phy backend, we'll make the blkfront sent out a single big > discard request, Right, one sector for the whole disk size. > and when we deal with that in blkback by calling blkdev_issue_discard, > the real max_discard_sectors > from phy dev will be used, and take care of splitting bios, Thanks Ah, you are right: if (nr_sects > max_discard_sectors) { bio->bi_size =3D max_discard_sectors << 9; nr_sects -=3D max_discard_sectors; sector +=3D max_discard_sectors; } else { handles when that value (nr_sects =3D=3D get_capacity(x)) is extremely large. OK, that was the only issue I had - and that has been resolved. So stuck your patchset series in my tree - but they are not yet visisble at kernel.org >=20 > > > > You need to provide a mechanism similar to 'discard-*' to fetch that = data > > from the backend. > > > >> + =A0 =A0 =A0 =A0 =A0 =A0 rq->limits.discard_granularity =3D info->d= iscard_granularity; > >> + =A0 =A0 =A0 =A0 =A0 =A0 rq->limits.discard_alignment =3D info->dis= card_alignment; > >> + =A0 =A0 } > >> + > >> =A0 =A0 =A0 /* Hard sector size and max sectors impersonate the equi= v. hardware. */ > >> =A0 =A0 =A0 blk_queue_logical_block_size(rq, sector_size); > >> =A0 =A0 =A0 blk_queue_max_hw_sectors(rq, 512); > >> @@ -722,6 +740,19 @@ static irqreturn_t blkif_interrupt(int irq, voi= d *dev_id) > >> > >> =A0 =A0 =A0 =A0 =A0 =A0 =A0 error =3D (bret->status =3D=3D BLKIF_RSP= _OKAY) ? 0 : -EIO; > >> =A0 =A0 =A0 =A0 =A0 =A0 =A0 switch (bret->operation) { > >> + =A0 =A0 =A0 =A0 =A0 =A0 case BLKIF_OP_DISCARD: > >> + =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 if (unlikely(bret->status = =3D=3D BLKIF_RSP_EOPNOTSUPP)) { > >> + =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 struct req= uest_queue *rq =3D info->rq; > >> + =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 printk(KER= N_WARNING "blkfront: %s: discard op failed\n", > >> + =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0= =A0 =A0 =A0info->gd->disk_name); > >> + =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 error =3D = -EOPNOTSUPP; > >> + =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 info->feat= ure_discard =3D 0; > >> + =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 spin_lock(= rq->queue_lock); > >> + =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 queue_flag= _clear(QUEUE_FLAG_DISCARD, rq); > >> + =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 spin_unloc= k(rq->queue_lock); > >> + =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 } > >> + =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 __blk_end_request_all(req,= error); > >> + =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 break; > >> =A0 =A0 =A0 =A0 =A0 =A0 =A0 case BLKIF_OP_FLUSH_DISKCACHE: > >> =A0 =A0 =A0 =A0 =A0 =A0 =A0 case BLKIF_OP_WRITE_BARRIER: > >> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 if (unlikely(bret->statu= s =3D=3D BLKIF_RSP_EOPNOTSUPP)) { > >> @@ -1098,6 +1129,33 @@ blkfront_closing(struct blkfront_info *info) > >> =A0 =A0 =A0 bdput(bdev); > >> =A0} > >> > >> +static void blkfront_setup_discard(struct blkfront_info *info) > >> +{ > >> + =A0 =A0 int err; > >> + =A0 =A0 char *type; > >> + =A0 =A0 unsigned int discard_granularity; > >> + =A0 =A0 unsigned int discard_alignment; > >> + > >> + =A0 =A0 type =3D xenbus_read(XBT_NIL, info->xbdev->otherend, "type= ", NULL); > >> + =A0 =A0 if (IS_ERR(type)) > >> + =A0 =A0 =A0 =A0 =A0 =A0 return; > >> + > >> + =A0 =A0 if (strncmp(type, "phy", 3) =3D=3D 0) { > >> + =A0 =A0 =A0 =A0 =A0 =A0 err =3D xenbus_gather(XBT_NIL, info->xbdev= ->otherend, > >> + =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 "discard-granularity", "%u= ", &discard_granularity, > >> + =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 "discard-alignment", "%u",= &discard_alignment, > >> + =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 NULL); > >> + =A0 =A0 =A0 =A0 =A0 =A0 if (!err) { > >> + =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 info->feature_discard =3D = 1; > >> + =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 info->discard_granularity = =3D discard_granularity; > >> + =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 info->discard_alignment =3D= discard_alignment; > >> + =A0 =A0 =A0 =A0 =A0 =A0 } > >> + =A0 =A0 } else if (strncmp(type, "file", 4) =3D=3D 0) > >> + =A0 =A0 =A0 =A0 =A0 =A0 info->feature_discard =3D 1; > >> + > >> + =A0 =A0 kfree(type); > >> +} > >> + > >> =A0/* > >> =A0 * Invoked when the backend is finally 'ready' (and has told prod= uced > >> =A0 * the details about the physical device - #sectors, size, etc). > >> @@ -1108,7 +1166,7 @@ static void blkfront_connect(struct blkfront_i= nfo *info) > >> =A0 =A0 =A0 unsigned long sector_size; > >> =A0 =A0 =A0 unsigned int binfo; > >> =A0 =A0 =A0 int err; > >> - =A0 =A0 int barrier, flush; > >> + =A0 =A0 int barrier, flush, discard; > >> > >> =A0 =A0 =A0 switch (info->connected) { > >> =A0 =A0 =A0 case BLKIF_STATE_CONNECTED: > >> @@ -1178,7 +1236,14 @@ static void blkfront_connect(struct blkfront_= info *info) > >> =A0 =A0 =A0 =A0 =A0 =A0 =A0 info->feature_flush =3D REQ_FLUSH; > >> =A0 =A0 =A0 =A0 =A0 =A0 =A0 info->flush_op =3D BLKIF_OP_FLUSH_DISKCA= CHE; > >> =A0 =A0 =A0 } > >> - > >> + > >> + =A0 =A0 err =3D xenbus_gather(XBT_NIL, info->xbdev->otherend, > >> + =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 "feature-discard",= "%d", &discard, > >> + =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 NULL); > >> + > >> + =A0 =A0 if (!err && discard) > >> + =A0 =A0 =A0 =A0 =A0 =A0 blkfront_setup_discard(info); > >> + > >> =A0 =A0 =A0 err =3D xlvbd_alloc_gendisk(sectors, info, binfo, sector= _size); > >> =A0 =A0 =A0 if (err) { > >> =A0 =A0 =A0 =A0 =A0 =A0 =A0 xenbus_dev_fatal(info->xbdev, err, "xlvb= d_add at %s", > >> -- > >> 1.7.6 > > _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel From xen-devel-bounces@lists.xensource.com Fri Sep 02 06:36:24 2011 Return-path: Envelope-to: www-data@lists.xensource.com Delivery-date: Fri, 02 Sep 2011 06:36:24 -0700 Received: from localhost ([127.0.0.1] helo=lists.colo.xensource.com) by lists.xensource.com with esmtp (Exim 4.43) id 1QzTuy-00046C-6T; Fri, 02 Sep 2011 06:36:24 -0700 Received: from mail174.messagelabs.com ([85.158.138.51]) by lists.xensource.com with esmtp (Exim 4.43) id 1QzTuO-0003ta-Lw for xen-devel@lists.xensource.com; Fri, 02 Sep 2011 06:35:49 -0700 X-Env-Sender: konrad@dumpdata.com X-Msg-Ref: server-15.tower-174.messagelabs.com!1314970543!23674672!1 X-Originating-IP: [141.146.126.227] X-StarScan-Version: 6.3.6; banners=-,-,- X-VirusChecked: Checked Received: (qmail 2326 invoked from network); 2 Sep 2011 13:35:45 -0000 Received: from acsinet15.oracle.com (HELO acsinet15.oracle.com) (141.146.126.227) by server-15.tower-174.messagelabs.com with DHE-RSA-AES256-SHA encrypted SMTP; 2 Sep 2011 13:35:45 -0000 Received: from rtcsinet22.oracle.com (rtcsinet22.oracle.com [66.248.204.30]) by acsinet15.oracle.com (Switch-3.4.4/Switch-3.4.4) with ESMTP id p82DZMT5032757 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Fri, 2 Sep 2011 13:35:25 GMT Received: from acsmt357.oracle.com (acsmt357.oracle.com [141.146.40.157]) by rtcsinet22.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id p82DZJpc002363 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 2 Sep 2011 13:35:20 GMT Received: from abhmt105.oracle.com (abhmt105.oracle.com [141.146.116.57]) by acsmt357.oracle.com (8.12.11.20060308/8.12.11) with ESMTP id p82DZCZb009953; Fri, 2 Sep 2011 08:35:12 -0500 Received: from phenom (/209.6.55.207) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Fri, 02 Sep 2011 06:35:12 -0700 Received: by phenom (Postfix, from userid 1000) id 7FDF5E45; Fri, 2 Sep 2011 09:35:11 -0400 (EDT) Date: Fri, 2 Sep 2011 09:35:11 -0400 From: Konrad Rzeszutek Wilk To: Jeremy Fitzhardinge Subject: Re: [Xen-devel] [Xen-deve] xen/stable-2.6.32.x bare-metal: panic early exception 0e rip 10:0 error 10 cr2 0 Message-ID: <20110902133511.GA5968@dumpdata.com> References: <4E4D9A90.30800@leuphana.de> <4E600A57.9040208@goop.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <4E600A57.9040208@goop.org> User-Agent: Mutt/1.5.21 (2010-09-15) X-Source-IP: rtcsinet22.oracle.com [66.248.204.30] X-CT-RefId: str=0001.0A090205.4E60DB9E.0088,ss=1,re=0.000,fgs=0 Cc: xen-devel@lists.xensource.com, M A Young X-BeenThere: xen-devel@lists.xensource.com X-Mailman-Version: 2.1.5 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xensource.com Errors-To: xen-devel-bounces@lists.xensource.com On Thu, Sep 01, 2011 at 03:42:31PM -0700, Jeremy Fitzhardinge wrote: > On 09/01/2011 02:29 PM, M A Young wrote: > > On Wed, 31 Aug 2011, M A Young wrote: > > > >> On Fri, 19 Aug 2011, Andreas Olsowski wrote: > >> > >>> Source: > >>> git://git.kernel.org/pub/scm/linux/kernel/git/jeremy/xen.git > >>> > >>> Tested branches: > >>> xen/stable-2.6.32.x > >>> xen/next-2.6.32.x > >>> > >>> When trying to boot the current kernel bare-metal it will not load > >>> properly, instead i am prompted with: > >>> > >>> panic early exception 0e rip 10:0 error 10 cr2 0 > >> > >> I am seeing this as well. I have been trying to narrow it down a bit, > >> and it seems to me that the bug was introduced somewhere between > >> xen-2.6.32.39 and xen-2.6.32.42. > > > > xen-2.6.32.40 also crashes. I think that means that it is either > > commits c3dd7941354fa96a71f2613e2c7a1b215fa175dc or > > 280802657fb95c52bb5a35d43fea60351883b2af (or something in the stable > > kernel or else compile differences though both are unlikely). I am > > still working on this to confirm which patch it is. > > 280802657fb95c5 is unlikely - that's just a blkback change. > > c3dd7941354fa96 looks plausible. There was a patch on top of it - that made it work under PV. _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel From xen-devel-bounces@lists.xensource.com Fri Sep 02 06:38:12 2011 Return-path: Envelope-to: www-data@lists.xensource.com Delivery-date: Fri, 02 Sep 2011 06:38:12 -0700 Received: from localhost ([127.0.0.1] helo=lists.colo.xensource.com) by lists.xensource.com with esmtp (Exim 4.43) id 1QzTwi-0004XA-K3; Fri, 02 Sep 2011 06:38:12 -0700 Received: from mail216.messagelabs.com ([85.158.143.99]) by lists.xensource.com with esmtp (Exim 4.43) id 1QzTwD-0004HT-HT for xen-devel@lists.xensource.com; Fri, 02 Sep 2011 06:37:41 -0700 X-Env-Sender: konrad@dumpdata.com X-Msg-Ref: server-9.tower-216.messagelabs.com!1314970657!16867873!1 X-Originating-IP: [148.87.113.117] X-StarScan-Version: 6.3.6; banners=-,-,- X-VirusChecked: Checked Received: (qmail 18816 invoked from network); 2 Sep 2011 13:37:38 -0000 Received: from rcsinet15.oracle.com (HELO rcsinet15.oracle.com) (148.87.113.117) by server-9.tower-216.messagelabs.com with DHE-RSA-AES256-SHA encrypted SMTP; 2 Sep 2011 13:37:38 -0000 Received: from acsinet22.oracle.com (acsinet22.oracle.com [141.146.126.238]) by rcsinet15.oracle.com (Switch-3.4.4/Switch-3.4.4) with ESMTP id p82DbCMl007669 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Fri, 2 Sep 2011 13:37:13 GMT Received: from acsmt357.oracle.com (acsmt357.oracle.com [141.146.40.157]) by acsinet22.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id p82DbA8t001276 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 2 Sep 2011 13:37:11 GMT Received: from abhmt102.oracle.com (abhmt102.oracle.com [141.146.116.54]) by acsmt357.oracle.com (8.12.11.20060308/8.12.11) with ESMTP id p82Db5ti011458; Fri, 2 Sep 2011 08:37:05 -0500 Received: from phenom (/209.6.55.207) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Fri, 02 Sep 2011 06:37:05 -0700 Received: by phenom (Postfix, from userid 1000) id 6C7A2E45; Fri, 2 Sep 2011 09:37:03 -0400 (EDT) Date: Fri, 2 Sep 2011 09:37:03 -0400 From: Konrad Rzeszutek Wilk To: M A Young Subject: Re: [Xen-devel] [Xen-deve] xen/stable-2.6.32.x bare-metal: panic early exception 0e rip 10:0 error 10 cr2 0 Message-ID: <20110902133703.GB5968@dumpdata.com> References: <4E4D9A90.30800@leuphana.de> <4E600A57.9040208@goop.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.21 (2010-09-15) X-Source-IP: acsinet22.oracle.com [141.146.126.238] X-Auth-Type: Internal IP X-CT-RefId: str=0001.0A090204.4E60DC0C.008F:SCFMA922111,ss=1,re=-4.000,fgs=0 Cc: Jeremy Fitzhardinge , xen-devel@lists.xensource.com X-BeenThere: xen-devel@lists.xensource.com X-Mailman-Version: 2.1.5 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xensource.com Errors-To: xen-devel-bounces@lists.xensource.com On Fri, Sep 02, 2011 at 12:44:31AM +0100, M A Young wrote: > > > On Thu, 1 Sep 2011, Jeremy Fitzhardinge wrote: > > >On 09/01/2011 02:29 PM, M A Young wrote: > >>On Wed, 31 Aug 2011, M A Young wrote: > >> > >>>On Fri, 19 Aug 2011, Andreas Olsowski wrote: > >>> > >>>>Source: > >>>>git://git.kernel.org/pub/scm/linux/kernel/git/jeremy/xen.git > >>>> > >>>>Tested branches: > >>>>xen/stable-2.6.32.x > >>>>xen/next-2.6.32.x > >>>> > >>>>When trying to boot the current kernel bare-metal it will not load > >>>>properly, instead i am prompted with: > >>>> > >>>>panic early exception 0e rip 10:0 error 10 cr2 0 > >>> > >>>I am seeing this as well. I have been trying to narrow it down a bit, > >>>and it seems to me that the bug was introduced somewhere between > >>>xen-2.6.32.39 and xen-2.6.32.42. > >> > >>xen-2.6.32.40 also crashes. I think that means that it is either > >>commits c3dd7941354fa96a71f2613e2c7a1b215fa175dc or > >>280802657fb95c52bb5a35d43fea60351883b2af (or something in the stable > >>kernel or else compile differences though both are unlikely). I am > >>still working on this to confirm which patch it is. > > > >280802657fb95c5 is unlikely - that's just a blkback change. > > > >c3dd7941354fa96 looks plausible. > > Yes, xen-2.6.32.40 with c3dd7941354fa96a71f2613e2c7a1b215fa175dc > reverted will boot on bare metal. bare metal. Yes, it won't work under that - at least not in that state. Jeremy, can you revert that patch please - it was fixing one instance of machines - and it looks to be breaking many more. Grrrrrr _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel From xen-devel-bounces@lists.xensource.com Fri Sep 02 06:41:17 2011 Return-path: Envelope-to: www-data@lists.xensource.com Delivery-date: Fri, 02 Sep 2011 06:41:17 -0700 Received: from localhost ([127.0.0.1] helo=lists.colo.xensource.com) by lists.xensource.com with esmtp (Exim 4.43) id 1QzTzg-00057g-FO; Fri, 02 Sep 2011 06:41:16 -0700 Received: from mail174.messagelabs.com ([85.158.138.51]) by lists.xensource.com with esmtp (Exim 4.43) id 1QzTzG-0004v7-BN for xen-devel@lists.xensource.com; Fri, 02 Sep 2011 06:40:51 -0700 X-Env-Sender: konrad@dumpdata.com X-Msg-Ref: server-2.tower-174.messagelabs.com!1314970845!30031512!1 X-Originating-IP: [141.146.126.227] X-StarScan-Version: 6.3.6; banners=-,-,- X-VirusChecked: Checked Received: (qmail 27449 invoked from network); 2 Sep 2011 13:40:47 -0000 Received: from acsinet15.oracle.com (HELO acsinet15.oracle.com) (141.146.126.227) by server-2.tower-174.messagelabs.com with DHE-RSA-AES256-SHA encrypted SMTP; 2 Sep 2011 13:40:47 -0000 Received: from rtcsinet22.oracle.com (rtcsinet22.oracle.com [66.248.204.30]) by acsinet15.oracle.com (Switch-3.4.4/Switch-3.4.4) with ESMTP id p82Defit008903 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Fri, 2 Sep 2011 13:40:43 GMT Received: from acsmt356.oracle.com (acsmt356.oracle.com [141.146.40.156]) by rtcsinet22.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id p82DednQ011427 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 2 Sep 2011 13:40:40 GMT Received: from abhmt110.oracle.com (abhmt110.oracle.com [141.146.116.62]) by acsmt356.oracle.com (8.12.11.20060308/8.12.11) with ESMTP id p82DeY1c009857; Fri, 2 Sep 2011 08:40:34 -0500 Received: from phenom (/209.6.55.207) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Fri, 02 Sep 2011 06:40:34 -0700 Received: by phenom (Postfix, from userid 1000) id E103FE45; Fri, 2 Sep 2011 09:40:32 -0400 (EDT) Date: Fri, 2 Sep 2011 09:40:32 -0400 From: Konrad Rzeszutek Wilk To: Igor Mammedov Subject: Re: [Xen-devel] Re: [PATCH v2] xen: x86_32: do not enable iterrupts when returning from exception in interrupt context Message-ID: <20110902134032.GA6064@dumpdata.com> References: <4E5EB794.7050909@goop.org> <1314877615-18280-1-git-send-email-imammedo@redhat.com> <4E5FB700.1070908@goop.org> <4E60914F.7080208@redhat.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <4E60914F.7080208@redhat.com> User-Agent: Mutt/1.5.21 (2010-09-15) X-Source-IP: rtcsinet22.oracle.com [66.248.204.30] X-CT-RefId: str=0001.0A090204.4E60DCDC.0005,ss=1,re=0.000,fgs=0 Cc: Jeremy Fitzhardinge , xen-devel@lists.xensource.com, linux-kernel@vger.kernel.org X-BeenThere: xen-devel@lists.xensource.com X-Mailman-Version: 2.1.5 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xensource.com Errors-To: xen-devel-bounces@lists.xensource.com On Fri, Sep 02, 2011 at 10:18:23AM +0200, Igor Mammedov wrote: > On 09/01/2011 06:46 PM, Jeremy Fitzhardinge wrote: > >On 09/01/2011 04:46 AM, Igor Mammedov wrote: > >>If vmalloc page_fault happens inside of interrupt handler with interrupts > >>disabled then on exit path from exception handler when there is no pending > >>interrupts, the following code (arch/x86/xen/xen-asm_32.S:112): > >> > >> cmpw $0x0001, XEN_vcpu_info_pending(%eax) > >> sete XEN_vcpu_info_mask(%eax) > >> > >>will enable interrupts even if they has been previously disabled according to > >>eflags from the bounce frame (arch/x86/xen/xen-asm_32.S:99) > >> > >> testb $X86_EFLAGS_IF>>8, 8+1+ESP_OFFSET(%esp) > >> setz XEN_vcpu_info_mask(%eax) > >> > >>Solution is in setting XEN_vcpu_info_mask only when it should be set > >>according to > >> cmpw $0x0001, XEN_vcpu_info_pending(%eax) > >>but not clearing it if there isn't any pending events. > >> > >>Reproducer for bug is attached to RHBZ 707552 > >> > >>Signed-off-by: Igor Mammedov > >>Signed-off-by: Jeremy Fitzhardinge > > > >One nit, this should be acked-by or reviewed-by, not signed-off-by, > >since the patch isn't passing through my hands. > > > > J > > I'm new to this stuff, would you like me to re-post it? That is OK. I fixed it up in the git commit. Thanks for finding this one! _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel From xen-devel-bounces@lists.xensource.com Fri Sep 02 07:03:08 2011 Return-path: Envelope-to: www-data@lists.xensource.com Delivery-date: Fri, 02 Sep 2011 07:03:08 -0700 Received: from localhost ([127.0.0.1] helo=lists.colo.xensource.com) by lists.xensource.com with esmtp (Exim 4.43) id 1QzUKq-0005ph-3z; Fri, 02 Sep 2011 07:03:08 -0700 Received: from mail27.messagelabs.com ([193.109.254.147]) by lists.xensource.com with smtp (Exim 4.43) id 1QzUJd-0005c2-02 for xen-devel@lists.xensource.com; Fri, 02 Sep 2011 07:01:53 -0700 X-Env-Sender: imammedo@redhat.com X-Msg-Ref: server-8.tower-27.messagelabs.com!1314972095!44985313!1 X-Originating-IP: [209.132.183.28] X-StarScan-Version: 6.3.6; banners=-,-,- X-VirusChecked: Checked Received: (qmail 28416 invoked from network); 2 Sep 2011 14:01:35 -0000 Received: from mx1.redhat.com (HELO mx1.redhat.com) (209.132.183.28) by server-8.tower-27.messagelabs.com with SMTP; 2 Sep 2011 14:01:35 -0000 Received: from int-mx01.intmail.prod.int.phx2.redhat.com (int-mx01.intmail.prod.int.phx2.redhat.com [10.5.11.11]) by mx1.redhat.com (8.14.4/8.14.4) with ESMTP id p82E1l0g022401 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Fri, 2 Sep 2011 10:01:47 -0400 Received: from ns3.rdu.redhat.com (ns3.rdu.redhat.com [10.11.255.199]) by int-mx01.intmail.prod.int.phx2.redhat.com (8.13.8/8.13.8) with ESMTP id p82E1lhe011536; Fri, 2 Sep 2011 10:01:47 -0400 Received: from nial.usersys.redhat.com (dhcp-1-247.brq.redhat.com [10.34.1.247]) by ns3.rdu.redhat.com (8.13.8/8.13.8) with ESMTP id p82E1Zfc013512; Fri, 2 Sep 2011 10:01:36 -0400 Message-ID: <4E60E1BF.2020206@redhat.com> Date: Fri, 02 Sep 2011 16:01:35 +0200 From: Igor Mammedov User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.2.20) Gecko/20110805 Red Hat/3.1.12-1.el6_1 Lightning/1.0b2 Thunderbird/3.1.12 MIME-Version: 1.0 To: Konrad Rzeszutek Wilk Subject: Re: [Xen-devel] Re: [PATCH v2] xen: x86_32: do not enable iterrupts when returning from exception in interrupt context References: <4E5EB794.7050909@goop.org> <1314877615-18280-1-git-send-email-imammedo@redhat.com> <4E5FB700.1070908@goop.org> <4E60914F.7080208@redhat.com> <20110902134032.GA6064@dumpdata.com> In-Reply-To: <20110902134032.GA6064@dumpdata.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Scanned-By: MIMEDefang 2.67 on 10.5.11.11 Cc: Jeremy Fitzhardinge , xen-devel@lists.xensource.com, linux-kernel@vger.kernel.org X-BeenThere: xen-devel@lists.xensource.com X-Mailman-Version: 2.1.5 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xensource.com Errors-To: xen-devel-bounces@lists.xensource.com On 09/02/2011 03:40 PM, Konrad Rzeszutek Wilk wrote: > On Fri, Sep 02, 2011 at 10:18:23AM +0200, Igor Mammedov wrote: >> On 09/01/2011 06:46 PM, Jeremy Fitzhardinge wrote: >>> On 09/01/2011 04:46 AM, Igor Mammedov wrote: >>>> If vmalloc page_fault happens inside of interrupt handler with interrupts >>>> disabled then on exit path from exception handler when there is no pending >>>> interrupts, the following code (arch/x86/xen/xen-asm_32.S:112): >>>> >>>> cmpw $0x0001, XEN_vcpu_info_pending(%eax) >>>> sete XEN_vcpu_info_mask(%eax) >>>> >>>> will enable interrupts even if they has been previously disabled according to >>>> eflags from the bounce frame (arch/x86/xen/xen-asm_32.S:99) >>>> >>>> testb $X86_EFLAGS_IF>>8, 8+1+ESP_OFFSET(%esp) >>>> setz XEN_vcpu_info_mask(%eax) >>>> >>>> Solution is in setting XEN_vcpu_info_mask only when it should be set >>>> according to >>>> cmpw $0x0001, XEN_vcpu_info_pending(%eax) >>>> but not clearing it if there isn't any pending events. >>>> >>>> Reproducer for bug is attached to RHBZ 707552 >>>> >>>> Signed-off-by: Igor Mammedov >>>> Signed-off-by: Jeremy Fitzhardinge >>> >>> One nit, this should be acked-by or reviewed-by, not signed-off-by, >>> since the patch isn't passing through my hands. >>> >>> J >> >> I'm new to this stuff, would you like me to re-post it? > > That is OK. I fixed it up in the git commit. Thanks for finding this one! You're welcome! I've learned a lot while debugging it. In particular, how to use kvm and qemu's gdbstub to debug xen and guest using gdb. -- Thanks, Igor _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel From xen-devel-bounces@lists.xensource.com Fri Sep 02 07:48:20 2011 Return-path: Envelope-to: www-data@lists.xensource.com Delivery-date: Fri, 02 Sep 2011 07:48:20 -0700 Received: from localhost ([127.0.0.1] helo=lists.colo.xensource.com) by lists.xensource.com with esmtp (Exim 4.43) id 1QzV2a-0007lj-2u; Fri, 02 Sep 2011 07:48:20 -0700 Received: from mail216.messagelabs.com ([85.158.143.99]) by lists.xensource.com with esmtp (Exim 4.43) id 1QzV1f-0007Ys-Rb for xen-devel@lists.xensource.com; Fri, 02 Sep 2011 07:47:24 -0700 X-Env-Sender: konrad@dumpdata.com X-Msg-Ref: server-11.tower-216.messagelabs.com!1314974839!9284421!1 X-Originating-IP: [148.87.113.117] X-StarScan-Version: 6.3.6; banners=-,-,- X-VirusChecked: Checked Received: (qmail 15586 invoked from network); 2 Sep 2011 14:47:20 -0000 Received: from rcsinet15.oracle.com (HELO rcsinet15.oracle.com) (148.87.113.117) by server-11.tower-216.messagelabs.com with DHE-RSA-AES256-SHA encrypted SMTP; 2 Sep 2011 14:47:20 -0000 Received: from acsinet21.oracle.com (acsinet21.oracle.com [141.146.126.237]) by rcsinet15.oracle.com (Switch-3.4.4/Switch-3.4.4) with ESMTP id p82ElF0K030498 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Fri, 2 Sep 2011 14:47:17 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 p82ElCSK027563 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 2 Sep 2011 14:47:12 GMT Received: from abhmt120.oracle.com (abhmt120.oracle.com [141.146.116.72]) by acsmt358.oracle.com (8.12.11.20060308/8.12.11) with ESMTP id p82El40D030262; Fri, 2 Sep 2011 09:47:04 -0500 Received: from phenom (/209.6.55.207) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Fri, 02 Sep 2011 07:47:04 -0700 Received: by phenom (Postfix, from userid 1000) id D914CE45; Fri, 2 Sep 2011 10:47:02 -0400 (EDT) Date: Fri, 2 Sep 2011 10:47:02 -0400 From: Konrad Rzeszutek Wilk To: Igor Mammedov Subject: Re: [Xen-devel] Re: [PATCH v2] xen: x86_32: do not enable iterrupts when returning from exception in interrupt context Message-ID: <20110902144702.GA1704@dumpdata.com> References: <4E5EB794.7050909@goop.org> <1314877615-18280-1-git-send-email-imammedo@redhat.com> <4E5FB700.1070908@goop.org> <4E60914F.7080208@redhat.com> <20110902134032.GA6064@dumpdata.com> <4E60E1BF.2020206@redhat.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <4E60E1BF.2020206@redhat.com> User-Agent: Mutt/1.5.21 (2010-09-15) X-Source-IP: acsinet21.oracle.com [141.146.126.237] X-Auth-Type: Internal IP X-CT-RefId: str=0001.0A090208.4E60EC75.011E:SCFMA922111,ss=1,re=-4.000,fgs=0 Cc: Jeremy Fitzhardinge , xen-devel@lists.xensource.com, linux-kernel@vger.kernel.org X-BeenThere: xen-devel@lists.xensource.com X-Mailman-Version: 2.1.5 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xensource.com Errors-To: xen-devel-bounces@lists.xensource.com On Fri, Sep 02, 2011 at 04:01:35PM +0200, Igor Mammedov wrote: > On 09/02/2011 03:40 PM, Konrad Rzeszutek Wilk wrote: > >On Fri, Sep 02, 2011 at 10:18:23AM +0200, Igor Mammedov wrote: > >>On 09/01/2011 06:46 PM, Jeremy Fitzhardinge wrote: > >>>On 09/01/2011 04:46 AM, Igor Mammedov wrote: > >>>>If vmalloc page_fault happens inside of interrupt handler with interrupts > >>>>disabled then on exit path from exception handler when there is no pending > >>>>interrupts, the following code (arch/x86/xen/xen-asm_32.S:112): > >>>> > >>>> cmpw $0x0001, XEN_vcpu_info_pending(%eax) > >>>> sete XEN_vcpu_info_mask(%eax) > >>>> > >>>>will enable interrupts even if they has been previously disabled according to > >>>>eflags from the bounce frame (arch/x86/xen/xen-asm_32.S:99) > >>>> > >>>> testb $X86_EFLAGS_IF>>8, 8+1+ESP_OFFSET(%esp) > >>>> setz XEN_vcpu_info_mask(%eax) > >>>> > >>>>Solution is in setting XEN_vcpu_info_mask only when it should be set > >>>>according to > >>>> cmpw $0x0001, XEN_vcpu_info_pending(%eax) > >>>>but not clearing it if there isn't any pending events. > >>>> > >>>>Reproducer for bug is attached to RHBZ 707552 > >>>> > >>>>Signed-off-by: Igor Mammedov > >>>>Signed-off-by: Jeremy Fitzhardinge > >>> > >>>One nit, this should be acked-by or reviewed-by, not signed-off-by, > >>>since the patch isn't passing through my hands. > >>> > >>> J > >> > >>I'm new to this stuff, would you like me to re-post it? > > > >That is OK. I fixed it up in the git commit. Thanks for finding this one! > > You're welcome! > I've learned a lot while debugging it. In particular, how to use kvm and qemu's > gdbstub to debug xen and guest using gdb. Oh, would you be interested in writting a blog article on xen.org by any chance? That sounds pretty nifty! _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel From xen-devel-bounces@lists.xensource.com Fri Sep 02 07:49:26 2011 Return-path: Envelope-to: www-data@lists.xensource.com Delivery-date: Fri, 02 Sep 2011 07:49:26 -0700 Received: from localhost ([127.0.0.1] helo=lists.colo.xensource.com) by lists.xensource.com with esmtp (Exim 4.43) id 1QzV3e-000891-NZ; Fri, 02 Sep 2011 07:49:26 -0700 Received: from mail216.messagelabs.com ([85.158.143.99]) by lists.xensource.com with esmtp (Exim 4.43) id 1QzV1s-0007b3-33 for xen-devel@lists.xensource.com; Fri, 02 Sep 2011 07:47:36 -0700 X-Env-Sender: peterz@infradead.org X-Msg-Ref: server-5.tower-216.messagelabs.com!1314974851!16399205!1 X-Originating-IP: [205.233.59.134] X-StarScan-Version: 6.3.6; banners=-,-,- X-VirusChecked: Checked Received: (qmail 27443 invoked from network); 2 Sep 2011 14:47:32 -0000 Received: from merlin.infradead.org (HELO merlin.infradead.org) (205.233.59.134) by server-5.tower-216.messagelabs.com with DHE-RSA-AES256-SHA encrypted SMTP; 2 Sep 2011 14:47:32 -0000 Received: from canuck.infradead.org ([2001:4978:20e::1]) by merlin.infradead.org with esmtps (Exim 4.76 #1 (Red Hat Linux)) id 1QzV1V-0004Ym-No; Fri, 02 Sep 2011 14:47:13 +0000 Received: from j77219.upc-j.chello.nl ([24.132.77.219] helo=twins) by canuck.infradead.org with esmtpsa (Exim 4.76 #1 (Red Hat Linux)) id 1QzV1V-0005nA-2l; Fri, 02 Sep 2011 14:47:13 +0000 Received: by twins (Postfix, from userid 1000) id 5F596814B94F; Fri, 2 Sep 2011 16:47:06 +0200 (CEST) From: Peter Zijlstra To: Jeremy Fitzhardinge Date: Fri, 02 Sep 2011 16:47:06 +0200 In-Reply-To: <38bb37e15f6e5056d5238adac945bc1837a996ec.1314922370.git.jeremy.fitzhardinge@citrix.com> References: <38bb37e15f6e5056d5238adac945bc1837a996ec.1314922370.git.jeremy.fitzhardinge@citrix.com> Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Mailer: Evolution 3.0.2- Message-ID: <1314974826.1861.1.camel@twins> Mime-Version: 1.0 Cc: Xen Devel , Marcelo Tosatti , Nick Piggin , KVM , maintainers , Linux Kernel Mailing List , Andi Kleen , Avi Kivity , Jeremy Fitzhardinge , "H. Peter Anvin" , Ingo Molnar , Linus Torvalds , the Subject: [Xen-devel] Re: [PATCH 08/13] xen/pvticketlock: disable interrupts while blocking X-BeenThere: xen-devel@lists.xensource.com X-Mailman-Version: 2.1.5 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xensource.com Errors-To: xen-devel-bounces@lists.xensource.com On Thu, 2011-09-01 at 17:55 -0700, Jeremy Fitzhardinge wrote: > From: Jeremy Fitzhardinge >=20 > We need to make sure interrupts are disabled while we're relying on the > contents of the per-cpu lock_waiting values, otherwise an interrupt > handler could come in, try to take some other lock, block, and overwrite > our values. Would this make it illegal to take a spinlock from NMI context? I know that its generally considered bad form, but there's at least one spinlock that's only taken from NMI context and thus hasn't got any deadlock potential. _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel From xen-devel-bounces@lists.xensource.com Fri Sep 02 07:50:15 2011 Return-path: Envelope-to: www-data@lists.xensource.com Delivery-date: Fri, 02 Sep 2011 07:50:15 -0700 Received: from localhost ([127.0.0.1] helo=lists.colo.xensource.com) by lists.xensource.com with esmtp (Exim 4.43) id 1QzV4R-0008WL-Oa; Fri, 02 Sep 2011 07:50:15 -0700 Received: from mail21.messagelabs.com ([85.158.143.35]) by lists.xensource.com with esmtp (Exim 4.43) id 1QzV2w-0007rO-5c for xen-devel@lists.xensource.com; Fri, 02 Sep 2011 07:48:42 -0700 X-Env-Sender: peterz@infradead.org X-Msg-Ref: server-5.tower-21.messagelabs.com!1314974887!46659191!1 X-Originating-IP: [205.233.59.134] X-StarScan-Version: 6.3.6; banners=-,-,- X-VirusChecked: Checked Received: (qmail 6369 invoked from network); 2 Sep 2011 14:48:07 -0000 Received: from merlin.infradead.org (HELO merlin.infradead.org) (205.233.59.134) by server-5.tower-21.messagelabs.com with DHE-RSA-AES256-SHA encrypted SMTP; 2 Sep 2011 14:48:07 -0000 Received: from canuck.infradead.org ([2001:4978:20e::1]) by merlin.infradead.org with esmtps (Exim 4.76 #1 (Red Hat Linux)) id 1QzV2m-0004Yz-Vh; Fri, 02 Sep 2011 14:48:33 +0000 Received: from j77219.upc-j.chello.nl ([24.132.77.219] helo=twins) by canuck.infradead.org with esmtpsa (Exim 4.76 #1 (Red Hat Linux)) id 1QzV2m-0005oS-6U; Fri, 02 Sep 2011 14:48:32 +0000 Received: by twins (Postfix, from userid 1000) id E83DE814B94F; Fri, 2 Sep 2011 16:48:25 +0200 (CEST) From: Peter Zijlstra To: Jeremy Fitzhardinge Date: Fri, 02 Sep 2011 16:48:25 +0200 In-Reply-To: <17a0f6177a71190dad30a6dcd1da93bec13a7836.1314922370.git.jeremy.fitzhardinge@citrix.com> References: <17a0f6177a71190dad30a6dcd1da93bec13a7836.1314922370.git.jeremy.fitzhardinge@citrix.com> Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Mailer: Evolution 3.0.2- Message-ID: <1314974905.1861.2.camel@twins> Mime-Version: 1.0 Cc: Xen Devel , Marcelo Tosatti , Nick Piggin , KVM , maintainers , Linux Kernel Mailing List , Andi Kleen , Avi Kivity , Jeremy Fitzhardinge , "H. Peter Anvin" , Ingo Molnar , Linus Torvalds , the Subject: [Xen-devel] Re: [PATCH 10/13] xen/pvticket: allow interrupts to be enabled while blocking X-BeenThere: xen-devel@lists.xensource.com X-Mailman-Version: 2.1.5 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xensource.com Errors-To: xen-devel-bounces@lists.xensource.com On Thu, 2011-09-01 at 17:55 -0700, Jeremy Fitzhardinge wrote: > + /* Make sure an interrupt handler can't upset things in a > + partially setup state. */ > local_irq_save(flags); > =20 > + /* > + * We don't really care if we're overwriting some other > + * (lock,want) pair, as that would mean that we're currently > + * in an interrupt context, and the outer context had > + * interrupts enabled. That has already kicked the VCPU out > + * of xen_poll_irq(), so it will just return spuriously and > + * retry with newly setup (lock,want). > + * > + * The ordering protocol on this is that the "lock" pointer > + * may only be set non-NULL if the "want" ticket is correct. > + * If we're updating "want", we must first clear "lock". > + */ > + w->lock =3D NULL;=20 I mean, I don't much care about Xen code, but that's two different comment styles. _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel From xen-devel-bounces@lists.xensource.com Fri Sep 02 07:51:10 2011 Return-path: Envelope-to: www-data@lists.xensource.com Delivery-date: Fri, 02 Sep 2011 07:51:10 -0700 Received: from localhost ([127.0.0.1] helo=lists.colo.xensource.com) by lists.xensource.com with esmtp (Exim 4.43) id 1QzV5K-0000So-Mj; Fri, 02 Sep 2011 07:51:10 -0700 Received: from mail182.messagelabs.com ([85.158.139.83]) by lists.xensource.com with esmtp (Exim 4.43) id 1QzV4a-00007E-78 for xen-devel@lists.xensource.com; Fri, 02 Sep 2011 07:50:25 -0700 X-Env-Sender: peterz@infradead.org X-Msg-Ref: server-9.tower-182.messagelabs.com!1314975020!16827501!1 X-Originating-IP: [85.118.1.10] X-StarScan-Version: 6.3.6; banners=-,-,- X-VirusChecked: Checked Received: (qmail 5918 invoked from network); 2 Sep 2011 14:50:21 -0000 Received: from casper.infradead.org (HELO casper.infradead.org) (85.118.1.10) by server-9.tower-182.messagelabs.com with DHE-RSA-AES256-SHA encrypted SMTP; 2 Sep 2011 14:50:21 -0000 Received: from j77219.upc-j.chello.nl ([24.132.77.219] helo=twins) by casper.infradead.org with esmtpsa (Exim 4.76 #1 (Red Hat Linux)) id 1QzV3l-0005Y2-Rn; Fri, 02 Sep 2011 14:49:33 +0000 Received: by twins (Postfix, from userid 1000) id 60599814B951; Fri, 2 Sep 2011 16:49:28 +0200 (CEST) From: Peter Zijlstra To: Jeremy Fitzhardinge Date: Fri, 02 Sep 2011 16:49:28 +0200 In-Reply-To: <8cd2c77886e2d3fcad8258aa62509b3b2fae5545.1314922370.git.jeremy.fitzhardinge@citrix.com> References: <8cd2c77886e2d3fcad8258aa62509b3b2fae5545.1314922370.git.jeremy.fitzhardinge@citrix.com> Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Mailer: Evolution 3.0.2- Message-ID: <1314974968.1861.3.camel@twins> Mime-Version: 1.0 Cc: Xen Devel , Marcelo Tosatti , Nick Piggin , KVM , maintainers , Linux Kernel Mailing List , Srivatsa Vaddagiri , Andi Kleen , Avi Kivity , Jeremy Fitzhardinge , "H. Peter Anvin" , Ingo Molnar , Linus Torvalds , the Subject: [Xen-devel] Re: [PATCH 11/13] x86/ticketlock: only do kick after doing unlock X-BeenThere: xen-devel@lists.xensource.com X-Mailman-Version: 2.1.5 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xensource.com Errors-To: xen-devel-bounces@lists.xensource.com On Thu, 2011-09-01 at 17:55 -0700, Jeremy Fitzhardinge wrote: > From: Srivatsa Vaddagiri >=20 > We must release the lock before checking to see if the lock is in > slowpath or else there's a potential race where the lock enters the > slow path after the unlocker has checked the slowpath flag, but before > it has actually unlocked. >=20 > Signed-off-by: Srivatsa Vaddagiri > Signed-off-by: Jeremy Fitzhardinge =20 Wouldn't it be much better to fold it back so that this bug never happens when you bisect? _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel From xen-devel-bounces@lists.xensource.com Fri Sep 02 08:40:25 2011 Return-path: Envelope-to: www-data@lists.xensource.com Delivery-date: Fri, 02 Sep 2011 08:40:25 -0700 Received: from localhost ([127.0.0.1] helo=lists.colo.xensource.com) by lists.xensource.com with esmtp (Exim 4.43) id 1QzVqz-0001rl-2n; Fri, 02 Sep 2011 08:40:25 -0700 Received: from mail182.messagelabs.com ([85.158.139.83]) by lists.xensource.com with esmtp (Exim 4.43) id 1QzVq3-0001aX-03 for xen-devel@lists.xensource.com; Fri, 02 Sep 2011 08:39:27 -0700 X-Env-Sender: torvalds@linux-foundation.org X-Msg-Ref: server-8.tower-182.messagelabs.com!1314977961!16845687!1 X-Originating-IP: [140.211.169.13] X-StarScan-Version: 6.3.6; banners=-,-,- X-VirusChecked: Checked Received: (qmail 23651 invoked from network); 2 Sep 2011 15:39:23 -0000 Received: from smtp1.linux-foundation.org (HELO smtp1.linux-foundation.org) (140.211.169.13) by server-8.tower-182.messagelabs.com with DHE-RSA-AES256-SHA encrypted SMTP; 2 Sep 2011 15:39:23 -0000 Received: from mail-wy0-f171.google.com (mail-wy0-f171.google.com [74.125.82.171]) (authenticated bits=0) by smtp1.linux-foundation.org (8.14.2/8.13.5/Debian-3ubuntu1.1) with ESMTP id p82FcjP7014985 (version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=FAIL) for ; Fri, 2 Sep 2011 08:38:46 -0700 Received: by wyh13 with SMTP id 13so2941889wyh.30 for ; Fri, 02 Sep 2011 08:38:42 -0700 (PDT) Received: by 10.216.28.148 with SMTP id g20mr1051207wea.100.1314977922123; Fri, 02 Sep 2011 08:38:42 -0700 (PDT) MIME-Version: 1.0 Received: by 10.216.187.66 with HTTP; Fri, 2 Sep 2011 08:38:22 -0700 (PDT) In-Reply-To: References: From: Linus Torvalds Date: Fri, 2 Sep 2011 08:38:22 -0700 Message-ID: To: Jeremy Fitzhardinge Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable X-Spam-Status: No, hits=-103.509 required=5 tests=AWL, BAYES_00, OSDL_HEADER_SUBJECT_BRACKETED, USER_IN_WHITELIST X-Spam-Checker-Version: SpamAssassin 3.2.4-osdl_revision__1.47__ X-MIMEDefang-Filter: lf-20110901g X-Scanned-By: MIMEDefang 2.63 on 140.211.169.13 Cc: Marcelo Tosatti , Nick Piggin , KVM , Peter Zijlstra , the arch/x86 maintainers , Linux Kernel Mailing List , Andi Kleen , Avi Kivity , Jeremy Fitzhardinge , "H. Peter Anvin" , Ingo Molnar , Xen Devel Subject: [Xen-devel] Re: [PATCH 00/13] [PATCH RFC] Paravirtualized ticketlocks X-BeenThere: xen-devel@lists.xensource.com X-Mailman-Version: 2.1.5 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xensource.com Errors-To: xen-devel-bounces@lists.xensource.com On Thu, Sep 1, 2011 at 5:54 PM, Jeremy Fitzhardinge wrote= : > > The inner part of ticket lock code becomes: > =A0 =A0 =A0 =A0inc =3D xadd(&lock->tickets, inc); > =A0 =A0 =A0 =A0inc.tail &=3D ~TICKET_SLOWPATH_FLAG; > > =A0 =A0 =A0 =A0for (;;) { > =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0unsigned count =3D SPIN_THRESHOLD; > > =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0do { > =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0if (inc.head =3D=3D inc.ta= il) > =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0goto out; > =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0cpu_relax(); > =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0inc.head =3D ACCESS_ONCE(l= ock->tickets.head); > =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0} while (--count); > =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0__ticket_lock_spinning(lock, inc.tail); > =A0 =A0 =A0 =A0} Hmm. It strikes me that I don't think you should touch the TICKET_SLOWPATH_FLAG in the fastpath at all. Can't you just do this: inc =3D xadd(&lock->tickets, inc); if (likely(inc.head =3D=3D inc.tail)) goto out; ### SLOWPATH ### inc.tail &=3D ~TICKET_SLOWPATH_FLAG; for (;;) { .. as before .. which might alleviate the problem with the fastpath being polluted by all those silly slowpath things. Hmm? (This assumes that TICKET_SLOWPATH_FLAG is never set in inc.head, so if it's set that equality check will fail. I didn't actually check if that assumption was correct) Linus _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel From xen-devel-bounces@lists.xensource.com Fri Sep 02 09:28:11 2011 Return-path: Envelope-to: www-data@lists.xensource.com Delivery-date: Fri, 02 Sep 2011 09:28:11 -0700 Received: from localhost ([127.0.0.1] helo=lists.colo.xensource.com) by lists.xensource.com with esmtp (Exim 4.43) id 1QzWbD-0003kx-00; Fri, 02 Sep 2011 09:28:11 -0700 Received: from mail21.messagelabs.com ([85.158.143.35]) by lists.xensource.com with esmtp (Exim 4.43) id 1QzWaF-0003Xn-2S for xen-devel@lists.xensource.com; Fri, 02 Sep 2011 09:27:11 -0700 X-Env-Sender: davidxu06@gmail.com X-Msg-Ref: server-11.tower-21.messagelabs.com!1314980811!41136451!1 X-Originating-IP: [209.85.160.171] X-StarScan-Version: 6.3.6; banners=-,-,- X-VirusChecked: Checked Received: (qmail 318 invoked from network); 2 Sep 2011 16:26:52 -0000 Received: from mail-gy0-f171.google.com (HELO mail-gy0-f171.google.com) (209.85.160.171) by server-11.tower-21.messagelabs.com with RC4-SHA encrypted SMTP; 2 Sep 2011 16:26:52 -0000 Received: by gye5 with SMTP id 5so2833515gye.30 for ; Fri, 02 Sep 2011 09:27:06 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:date:message-id:subject:from:to:cc:content-type; bh=+j6UlYEU4mymZyMn/CmqjbA9MFVH1KooRVlWOGb0bn0=; b=dNpZrOyOr72HjyzO+ebX6KCw7NQs+0V+VhyFTgr/rN1WxppzfHG2Oc3jd3lLcTiGqj TDQd/aSuneIgr3nfk7MIrt+C0hLSYqsI8i2H8CywiuNolmy9RJzttr23bA2GmeEpEn2Q +f3ZtoRhlPYayYi7Ugk3HK4+VlzOZEbPkoAjA= MIME-Version: 1.0 Received: by 10.236.177.72 with SMTP id c48mr6580712yhm.79.1314980826457; Fri, 02 Sep 2011 09:27:06 -0700 (PDT) Received: by 10.236.208.101 with HTTP; Fri, 2 Sep 2011 09:27:06 -0700 (PDT) Date: Fri, 2 Sep 2011 12:27:06 -0400 Message-ID: From: David Xu To: xen-devel Cc: George Dunlap Subject: [Xen-devel] determine the latency characteristics of a VM automatically X-BeenThere: xen-devel@lists.xensource.com X-Mailman-Version: 2.1.5 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0017725119==" Sender: xen-devel-bounces@lists.xensource.com Errors-To: xen-devel-bounces@lists.xensource.com --===============0017725119== Content-Type: multipart/alternative; boundary=20cf303ea4aa0c25be04abf7d53d --20cf303ea4aa0c25be04abf7d53d Content-Type: text/plain; charset=ISO-8859-1 Hi George, Tow months ago, we talked about how to reduce the scheduling latency for a specific VM which runs a mixed workload, where the boost mechanism can not works well. I have tried some methods to reduce the scheduling latency for some assumed latency-sensitive VMs and got some progress on it. Now I hope to make it on demand. That is to say, I hope to get the scheduler to determine the latency characteristics of a VM automatically. Since most time latency-sensitive operations are initiated with an interrupt, so a pending interrupt generally means that there is a latency sensitive operation waiting to happen. I remember you said your idea was to have the scheduler look at the historical rate of interrupts and determine a preemption timeslice based on those. I know your general idea, but could you talk more about it? What's more, I wonder if only the interrupts can infer the workload type? In my opinion, a pending interrupt indicates there is a operation to handle but may not be latency sensitive. Some common I/O operation, e.g. http request for a web page or file transmission, would also result in pending interrupt if the destination VM does not get scheduled at the moment. But they are not latency sensitive. Of course, if we can directly get some important information for distinguishing the latency-sensitive workload from common workload, it is powerful and high efficient. I am looking forward to your opinions and I hope I will not disturb your work. Thanks. Regards, Cong --20cf303ea4aa0c25be04abf7d53d Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Hi George,

=
Tow months ago, we talked about how to reduce the scheduling lat= ency for a specific VM which runs a mixed workload, where the boost mechani= sm can not works well. I have tried some methods to reduce the scheduling l= atency for some assumed latency-sensitive VMs and got some progress on it. = Now I hope to make it on demand. That is to say, I hope to get the schedule= r to determine the latency characteristics of a VM automatically. Since mos= t time latency-sensitive operations are=A0initiated=A0with an interrupt, so= a pending interrupt generally means that there is a latency sensitive oper= ation waiting to happen. I remember you said your idea was to have the sche= duler look at the historical rate of interrupts and determine a preemption = timeslice based on those. I know your general idea, but could you talk more= about it? What's more, I wonder if only the interrupts can infer the w= orkload type? In my opinion, a pending interrupt indicates there is a opera= tion to handle but may not be latency sensitive. Some common I/O operation,= e.g. http request for a web page or=A0=A0file=A0transmission, would also r= esult in pending interrupt if the destination VM does not get scheduled at = the moment. But they are not latency sensitive. Of course, if we can direct= ly get some important information for distinguishing the latency-sensitive = workload from common workload, it is powerful and high efficient. I am look= ing forward to your opinions and I hope I will not disturb your work. Thank= s.

Regards,
Cong
 --20cf303ea4aa0c25be04abf7d53d-- --===============0017725119== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel --===============0017725119==-- From xen-devel-bounces@lists.xensource.com Fri Sep 02 09:36:13 2011 Return-path: Envelope-to: www-data@lists.xensource.com Delivery-date: Fri, 02 Sep 2011 09:36:13 -0700 Received: from localhost ([127.0.0.1] helo=lists.colo.xensource.com) by lists.xensource.com with esmtp (Exim 4.43) id 1QzWiz-0004K7-95; Fri, 02 Sep 2011 09:36:13 -0700 Received: from mail21.messagelabs.com ([85.158.143.35]) by lists.xensource.com with smtp (Exim 4.43) id 1QzWiL-00044M-Qu for xen-devel@lists.xensource.com; Fri, 02 Sep 2011 09:35:34 -0700 X-Env-Sender: Andrew.Cooper3@citrix.com X-Msg-Ref: server-10.tower-21.messagelabs.com!1314981317!52661674!1 X-Originating-IP: [62.200.22.115] X-StarScan-Version: 6.3.6; banners=-,-,- X-VirusChecked: Checked Received: (qmail 18391 invoked from network); 2 Sep 2011 16:35:17 -0000 Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115) by server-10.tower-21.messagelabs.com with SMTP; 2 Sep 2011 16:35:17 -0000 X-IronPort-AV: E=Sophos;i="4.68,320,1312156800"; d="scan'208";a="7578147" Received: from lonpmailmx01.citrite.net ([10.30.203.162]) by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5; 02 Sep 2011 16:35:30 +0000 Received: from andrewcoop.uk.xensource.com (10.80.2.18) by LONPMAILMX01.citrite.net (10.30.203.162) with Microsoft SMTP Server id 8.3.137.0; Fri, 2 Sep 2011 17:35:30 +0100 Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Message-ID: User-Agent: Mercurial-patchbomb/1.4.3 Date: Fri, 2 Sep 2011 17:35:13 +0100 From: Andrew Cooper To: xen-devel@lists.xensource.com Cc: Andrew Cooper Subject: [Xen-devel] [PATCH 0 of 3] IRQ: Part 1 of the irq code cleanup X-BeenThere: xen-devel@lists.xensource.com X-Mailman-Version: 2.1.5 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xensource.com Errors-To: xen-devel-bounces@lists.xensource.com Presented are some basic changes Patch 1 removes some bit-rotten code Patch 2 reduces the data overhead of the irq code Patch 3 removes a loop from the irq cleanup code Signed-off-by Andrew Cooper _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel From xen-devel-bounces@lists.xensource.com Fri Sep 02 09:37:03 2011 Return-path: Envelope-to: www-data@lists.xensource.com Delivery-date: Fri, 02 Sep 2011 09:37:03 -0700 Received: from localhost ([127.0.0.1] helo=lists.colo.xensource.com) by lists.xensource.com with esmtp (Exim 4.43) id 1QzWjn-0004hD-55; Fri, 02 Sep 2011 09:37:03 -0700 Received: from mail21.messagelabs.com ([85.158.143.35]) by lists.xensource.com with smtp (Exim 4.43) id 1QzWiL-00044Q-Ts for xen-devel@lists.xensource.com; Fri, 02 Sep 2011 09:35:34 -0700 X-Env-Sender: Andrew.Cooper3@citrix.com X-Msg-Ref: server-10.tower-21.messagelabs.com!1314981317!52661674!3 X-Originating-IP: [62.200.22.115] X-StarScan-Version: 6.3.6; banners=-,-,- X-VirusChecked: Checked Received: (qmail 18400 invoked from network); 2 Sep 2011 16:35:17 -0000 Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115) by server-10.tower-21.messagelabs.com with SMTP; 2 Sep 2011 16:35:17 -0000 X-IronPort-AV: E=Sophos;i="4.68,320,1312156800"; d="scan'208";a="7578149" Received: from lonpmailmx01.citrite.net ([10.30.203.162]) by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5; 02 Sep 2011 16:35:30 +0000 Received: from andrewcoop.uk.xensource.com (10.80.2.18) by LONPMAILMX01.citrite.net (10.30.203.162) with Microsoft SMTP Server id 8.3.137.0; Fri, 2 Sep 2011 17:35:31 +0100 Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Mercurial-Node: cf93a1825d668bfeea233189c85b7acffe826851 Message-ID: In-Reply-To: References: User-Agent: Mercurial-patchbomb/1.4.3 Date: Fri, 2 Sep 2011 17:35:15 +0100 From: Andrew Cooper To: xen-devel@lists.xensource.com Cc: Andrew Cooper Subject: [Xen-devel] [PATCH 2 of 3] IRQ: Fold irq_status into irq_cfg X-BeenThere: xen-devel@lists.xensource.com X-Mailman-Version: 2.1.5 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xensource.com Errors-To: xen-devel-bounces@lists.xensource.com irq_status is an int for each of nr_irqs which represents a single boolean variable. Fold it into the bitfield in irq_cfg, which saves 768 bytes per CPU with per-cpu IDTs in use. Signed-off-by Andrew Cooper diff -r 5a1826139750 -r cf93a1825d66 xen/arch/x86/irq.c --- a/xen/arch/x86/irq.c Fri Sep 02 17:33:17 2011 +0100 +++ b/xen/arch/x86/irq.c Fri Sep 02 17:33:17 2011 +0100 @@ -39,11 +39,6 @@ boolean_param("irq-perdev-vector-map", o u8 __read_mostly *irq_vector; struct irq_desc __read_mostly *irq_desc = NULL; -int __read_mostly *irq_status = NULL; -#define IRQ_UNUSED (0) -#define IRQ_USED (1) -#define IRQ_RSVD (2) - #define IRQ_VECTOR_UNASSIGNED (0) static DECLARE_BITMAP(used_vectors, NR_VECTORS); @@ -117,7 +112,7 @@ static int __init __bind_irq_vector(int ASSERT(!test_bit(vector, cfg->used_vectors)); set_bit(vector, cfg->used_vectors); } - irq_status[irq] = IRQ_USED; + cfg->used = IRQ_USED; if (IO_APIC_IRQ(irq)) irq_vector[irq] = vector; return 0; @@ -139,7 +134,7 @@ static inline int find_unassigned_irq(vo int irq; for (irq = nr_irqs_gsi; irq < nr_irqs; irq++) - if (irq_status[irq] == IRQ_UNUSED) + if (irq_cfg[irq].used == IRQ_UNUSED) return irq; return -ENOSPC; } @@ -191,8 +186,6 @@ static void dynamic_irq_cleanup(unsigned xfree(action); } -static void init_one_irq_status(int irq); - static void __clear_irq_vector(int irq) { int cpu, vector; @@ -211,7 +204,7 @@ static void __clear_irq_vector(int irq) cfg->vector = IRQ_VECTOR_UNASSIGNED; cpus_clear(cfg->cpu_mask); - init_one_irq_status(irq); + cfg->used = IRQ_UNUSED; if (likely(!cfg->move_in_progress)) return; @@ -283,17 +276,13 @@ static void __init init_one_irq_desc(str INIT_LIST_HEAD(&desc->rl_link); } -static void init_one_irq_status(int irq) -{ - irq_status[irq] = IRQ_UNUSED; -} - static void __init init_one_irq_cfg(struct irq_cfg *cfg) { cfg->vector = IRQ_VECTOR_UNASSIGNED; cpus_clear(cfg->cpu_mask); cpus_clear(cfg->old_cpu_mask); cfg->used_vectors = NULL; + cfg->used = IRQ_UNUSED; } int __init init_irq_data(void) @@ -307,15 +296,13 @@ int __init init_irq_data(void) irq_desc = xmalloc_array(struct irq_desc, nr_irqs); irq_cfg = xmalloc_array(struct irq_cfg, nr_irqs); - irq_status = xmalloc_array(int, nr_irqs); irq_vector = xmalloc_array(u8, nr_irqs_gsi); - if ( !irq_desc || !irq_cfg || !irq_status ||! irq_vector ) + if ( !irq_desc || !irq_cfg ||! irq_vector ) return -ENOMEM; memset(irq_desc, 0, nr_irqs * sizeof(*irq_desc)); memset(irq_cfg, 0, nr_irqs * sizeof(*irq_cfg)); - memset(irq_status, 0, nr_irqs * sizeof(*irq_status)); memset(irq_vector, 0, nr_irqs_gsi * sizeof(*irq_vector)); for (irq = 0; irq < nr_irqs; irq++) { @@ -325,7 +312,6 @@ int __init init_irq_data(void) desc->chip_data = cfg; init_one_irq_desc(desc); init_one_irq_cfg(cfg); - init_one_irq_status(irq); } /* Never allocate the hypercall vector or Linux/BSD fast-trap vector. */ @@ -444,7 +430,7 @@ next: set_bit(vector, cfg->used_vectors); } - irq_status[irq] = IRQ_USED; + cfg->used = IRQ_USED; if (IO_APIC_IRQ(irq)) irq_vector[irq] = vector; err = 0; diff -r 5a1826139750 -r cf93a1825d66 xen/include/asm-x86/irq.h --- a/xen/include/asm-x86/irq.h Fri Sep 02 17:33:17 2011 +0100 +++ b/xen/include/asm-x86/irq.h Fri Sep 02 17:33:17 2011 +0100 @@ -34,8 +34,13 @@ struct irq_cfg { unsigned move_cleanup_count; vmask_t *used_vectors; u8 move_in_progress : 1; + u8 used: 1; }; +/* For use with irq_cfg.used */ +#define IRQ_UNUSED (0) +#define IRQ_USED (1) + extern struct irq_cfg *irq_cfg; typedef int vector_irq_t[NR_VECTORS]; _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel From xen-devel-bounces@lists.xensource.com Fri Sep 02 09:38:06 2011 Return-path: Envelope-to: www-data@lists.xensource.com Delivery-date: Fri, 02 Sep 2011 09:38:06 -0700 Received: from localhost ([127.0.0.1] helo=lists.colo.xensource.com) by lists.xensource.com with esmtp (Exim 4.43) id 1QzWko-00054J-9c; Fri, 02 Sep 2011 09:38:06 -0700 Received: from mail21.messagelabs.com ([85.158.143.35]) by lists.xensource.com with smtp (Exim 4.43) id 1QzWiL-00044N-SZ for xen-devel@lists.xensource.com; Fri, 02 Sep 2011 09:35:35 -0700 X-Env-Sender: Andrew.Cooper3@citrix.com X-Msg-Ref: server-10.tower-21.messagelabs.com!1314981317!52661674!2 X-Originating-IP: [62.200.22.115] X-StarScan-Version: 6.3.6; banners=-,-,- X-VirusChecked: Checked Received: (qmail 18395 invoked from network); 2 Sep 2011 16:35:17 -0000 Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115) by server-10.tower-21.messagelabs.com with SMTP; 2 Sep 2011 16:35:17 -0000 X-IronPort-AV: E=Sophos;i="4.68,320,1312156800"; d="scan'208";a="7578148" Received: from lonpmailmx01.citrite.net ([10.30.203.162]) by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5; 02 Sep 2011 16:35:30 +0000 Received: from andrewcoop.uk.xensource.com (10.80.2.18) by LONPMAILMX01.citrite.net (10.30.203.162) with Microsoft SMTP Server id 8.3.137.0; Fri, 2 Sep 2011 17:35:30 +0100 Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Mercurial-Node: 5a1826139750ab0efe4f94d9f6e628469e46469a Message-ID: <5a1826139750ab0efe4f.1314981314@andrewcoop.uk.xensource.com> In-Reply-To: References: User-Agent: Mercurial-patchbomb/1.4.3 Date: Fri, 2 Sep 2011 17:35:14 +0100 From: Andrew Cooper To: xen-devel@lists.xensource.com Cc: Andrew Cooper Subject: [Xen-devel] [PATCH 1 of 3] IRQ: Remove bit-rotten code X-BeenThere: xen-devel@lists.xensource.com X-Mailman-Version: 2.1.5 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xensource.com Errors-To: xen-devel-bounces@lists.xensource.com irq_desc.depth is a write only variable. LEGACY_IRQ_FROM_VECTOR(vec) is never referenced. Signed-off-by Andrew Cooper diff -r 227130622561 -r 5a1826139750 xen/arch/x86/io_apic.c --- a/xen/arch/x86/io_apic.c Thu Aug 25 12:03:14 2011 +0100 +++ b/xen/arch/x86/io_apic.c Fri Sep 02 17:33:17 2011 +0100 @@ -1955,7 +1955,6 @@ static void __init check_timer(void) if ((ret = bind_irq_vector(0, vector, mask_all))) printk(KERN_ERR"..IRQ0 is not set correctly with ioapic!!!, err:%d\n", ret); - irq_desc[0].depth = 0; irq_desc[0].status &= ~IRQ_DISABLED; /* diff -r 227130622561 -r 5a1826139750 xen/arch/x86/irq.c --- a/xen/arch/x86/irq.c Thu Aug 25 12:03:14 2011 +0100 +++ b/xen/arch/x86/irq.c Fri Sep 02 17:33:17 2011 +0100 @@ -178,7 +178,6 @@ static void dynamic_irq_cleanup(unsigned desc->handler->shutdown(irq); action = desc->action; desc->action = NULL; - desc->depth = 1; desc->msi_desc = NULL; desc->handler = &no_irq_type; desc->chip_data->used_vectors=NULL; @@ -278,7 +277,6 @@ static void __init init_one_irq_desc(str desc->status = IRQ_DISABLED; desc->handler = &no_irq_type; desc->action = NULL; - desc->depth = 1; desc->msi_desc = NULL; spin_lock_init(&desc->lock); cpus_setall(desc->affinity); @@ -736,7 +734,6 @@ void __init release_irq(unsigned int irq spin_lock_irqsave(&desc->lock,flags); action = desc->action; desc->action = NULL; - desc->depth = 1; desc->status |= IRQ_DISABLED; desc->handler->shutdown(irq); spin_unlock_irqrestore(&desc->lock,flags); @@ -764,7 +761,6 @@ int __init setup_irq(unsigned int irq, s } desc->action = new; - desc->depth = 0; desc->status &= ~IRQ_DISABLED; desc->handler->startup(irq); @@ -1343,7 +1339,6 @@ int pirq_guest_bind(struct vcpu *v, stru cpus_clear(action->cpu_eoi_map); init_timer(&action->eoi_timer, irq_guest_eoi_timer_fn, desc, 0); - desc->depth = 0; desc->status |= IRQ_GUEST; desc->status &= ~IRQ_DISABLED; desc->handler->startup(irq); @@ -1459,7 +1454,6 @@ static irq_guest_action_t *__pirq_guest_ BUG_ON(action->in_flight != 0); /* Disabling IRQ before releasing the desc_lock avoids an IRQ storm. */ - desc->depth = 1; desc->status |= IRQ_DISABLED; desc->handler->disable(irq); diff -r 227130622561 -r 5a1826139750 xen/include/asm-x86/irq.h --- a/xen/include/asm-x86/irq.h Thu Aug 25 12:03:14 2011 +0100 +++ b/xen/include/asm-x86/irq.h Fri Sep 02 17:33:17 2011 +0100 @@ -19,7 +19,6 @@ #define MSI_IRQ(irq) ((irq) >= nr_irqs_gsi && (irq) < nr_irqs) #define LEGACY_VECTOR(irq) ((irq) + FIRST_LEGACY_VECTOR) -#define LEGACY_IRQ_FROM_VECTOR(vec) ((vec) - FIRST_LEGACY_VECTOR) #define irq_to_desc(irq) (&irq_desc[irq]) #define irq_cfg(irq) (&irq_cfg[irq]) diff -r 227130622561 -r 5a1826139750 xen/include/xen/irq.h --- a/xen/include/xen/irq.h Thu Aug 25 12:03:14 2011 +0100 +++ b/xen/include/xen/irq.h Fri Sep 02 17:33:17 2011 +0100 @@ -72,7 +72,6 @@ typedef struct irq_desc { hw_irq_controller *handler; struct msi_desc *msi_desc; struct irqaction *action; /* IRQ action list */ - unsigned int depth; /* nested irq disables */ struct irq_cfg *chip_data; int irq; spinlock_t lock; _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel From xen-devel-bounces@lists.xensource.com Fri Sep 02 09:39:28 2011 Return-path: Envelope-to: www-data@lists.xensource.com Delivery-date: Fri, 02 Sep 2011 09:39:28 -0700 Received: from localhost ([127.0.0.1] helo=lists.colo.xensource.com) by lists.xensource.com with esmtp (Exim 4.43) id 1QzWm8-0005Rr-EK; Fri, 02 Sep 2011 09:39:28 -0700 Received: from mail21.messagelabs.com ([85.158.143.35]) by lists.xensource.com with smtp (Exim 4.43) id 1QzWiL-00044b-W7 for xen-devel@lists.xensource.com; Fri, 02 Sep 2011 09:35:35 -0700 X-Env-Sender: Andrew.Cooper3@citrix.com X-Msg-Ref: server-10.tower-21.messagelabs.com!1314981317!52661674!4 X-Originating-IP: [62.200.22.115] X-StarScan-Version: 6.3.6; banners=-,-,- X-VirusChecked: Checked Received: (qmail 18406 invoked from network); 2 Sep 2011 16:35:17 -0000 Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115) by server-10.tower-21.messagelabs.com with SMTP; 2 Sep 2011 16:35:17 -0000 X-IronPort-AV: E=Sophos;i="4.68,320,1312156800"; d="scan'208";a="7578150" Received: from lonpmailmx01.citrite.net ([10.30.203.162]) by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5; 02 Sep 2011 16:35:31 +0000 Received: from andrewcoop.uk.xensource.com (10.80.2.18) by LONPMAILMX01.citrite.net (10.30.203.162) with Microsoft SMTP Server id 8.3.137.0; Fri, 2 Sep 2011 17:35:31 +0100 Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Mercurial-Node: 1a244d4ca6ac2e442c3be922d5b8219ca1bb047d Message-ID: <1a244d4ca6ac2e442c3b.1314981316@andrewcoop.uk.xensource.com> In-Reply-To: References: User-Agent: Mercurial-patchbomb/1.4.3 Date: Fri, 2 Sep 2011 17:35:16 +0100 From: Andrew Cooper To: xen-devel@lists.xensource.com Cc: Andrew Cooper Subject: [Xen-devel] [PATCH 3 of 3] IRQ: Introduce old_vector to irq_cfg X-BeenThere: xen-devel@lists.xensource.com X-Mailman-Version: 2.1.5 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xensource.com Errors-To: xen-devel-bounces@lists.xensource.com Introduce old_vector to irq_cfg with the same principle as old_cpu_mask. This removes a brute force loop from __clear_irq_vector(), and paves the way to correct bitrotten logic elsewhere in the irq code. Signed-off-by Andrew Cooper diff -r cf93a1825d66 -r 1a244d4ca6ac xen/arch/x86/io_apic.c --- a/xen/arch/x86/io_apic.c Fri Sep 02 17:33:17 2011 +0100 +++ b/xen/arch/x86/io_apic.c Fri Sep 02 17:33:17 2011 +0100 @@ -487,11 +487,16 @@ fastcall void smp_irq_move_cleanup_inter __get_cpu_var(vector_irq)[vector] = -1; cfg->move_cleanup_count--; - if ( cfg->move_cleanup_count == 0 - && cfg->used_vectors ) + if ( cfg->move_cleanup_count == 0 ) { - ASSERT(test_bit(vector, cfg->used_vectors)); - clear_bit(vector, cfg->used_vectors); + cfg->old_vector = -1; + cpus_clear(cfg->old_cpu_mask); + + if ( cfg->used_vectors ) + { + ASSERT(test_bit(vector, cfg->used_vectors)); + clear_bit(vector, cfg->used_vectors); + } } unlock: spin_unlock(&desc->lock); diff -r cf93a1825d66 -r 1a244d4ca6ac xen/arch/x86/irq.c --- a/xen/arch/x86/irq.c Fri Sep 02 17:33:17 2011 +0100 +++ b/xen/arch/x86/irq.c Fri Sep 02 17:33:17 2011 +0100 @@ -211,15 +211,9 @@ static void __clear_irq_vector(int irq) cpus_and(tmp_mask, cfg->old_cpu_mask, cpu_online_map); for_each_cpu_mask(cpu, tmp_mask) { - for (vector = FIRST_DYNAMIC_VECTOR; vector <= LAST_DYNAMIC_VECTOR; - vector++) { - if (per_cpu(vector_irq, cpu)[vector] != irq) - continue; - TRACE_3D(TRC_HW_IRQ_MOVE_FINISH, - irq, vector, cpu); - per_cpu(vector_irq, cpu)[vector] = -1; - break; - } + ASSERT( per_cpu(vector_irq, cpu)[cfg->old_vector] == irq ); + TRACE_3D(TRC_HW_IRQ_MOVE_FINISH, irq, vector, cpu); + per_cpu(vector_irq, cpu)[vector] = -1; } if ( cfg->used_vectors ) @@ -279,6 +273,7 @@ static void __init init_one_irq_desc(str static void __init init_one_irq_cfg(struct irq_cfg *cfg) { cfg->vector = IRQ_VECTOR_UNASSIGNED; + cfg->old_vector = IRQ_VECTOR_UNASSIGNED; cpus_clear(cfg->cpu_mask); cpus_clear(cfg->old_cpu_mask); cfg->used_vectors = NULL; @@ -418,6 +413,7 @@ next: if (old_vector) { cfg->move_in_progress = 1; cpus_copy(cfg->old_cpu_mask, cfg->cpu_mask); + cfg->old_vector = cfg->vector; } trace_irq_mask(TRC_HW_IRQ_ASSIGN_VECTOR, irq, vector, &tmp_mask); for_each_cpu_mask(new_cpu, tmp_mask) diff -r cf93a1825d66 -r 1a244d4ca6ac xen/include/asm-x86/irq.h --- a/xen/include/asm-x86/irq.h Fri Sep 02 17:33:17 2011 +0100 +++ b/xen/include/asm-x86/irq.h Fri Sep 02 17:33:17 2011 +0100 @@ -28,7 +28,8 @@ typedef struct { } vmask_t; struct irq_cfg { - int vector; + s16 vector; /* vector itself is only 8 bits, */ + s16 old_vector; /* but we use -1 for unassigned */ cpumask_t cpu_mask; cpumask_t old_cpu_mask; unsigned move_cleanup_count; _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel From xen-devel-bounces@lists.xensource.com Fri Sep 02 09:41:36 2011 Return-path: Envelope-to: www-data@lists.xensource.com Delivery-date: Fri, 02 Sep 2011 09:41:36 -0700 Received: from localhost ([127.0.0.1] helo=lists.colo.xensource.com) by lists.xensource.com with esmtp (Exim 4.43) id 1QzWoC-0005qW-JL; Fri, 02 Sep 2011 09:41:36 -0700 Received: from mail174.messagelabs.com ([85.158.138.51]) by lists.xensource.com with smtp (Exim 4.43) id 1QzWng-0005dl-KX for xen-devel@lists.xensource.com; Fri, 02 Sep 2011 09:41:05 -0700 X-Env-Sender: Ian.Jackson@eu.citrix.com X-Msg-Ref: server-15.tower-174.messagelabs.com!1314981661!23697571!1 X-Originating-IP: [62.200.22.115] X-StarScan-Version: 6.3.6; banners=-,-,- X-VirusChecked: Checked Received: (qmail 17133 invoked from network); 2 Sep 2011 16:41:01 -0000 Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115) by server-15.tower-174.messagelabs.com with SMTP; 2 Sep 2011 16:41:01 -0000 X-IronPort-AV: E=Sophos;i="4.68,320,1312156800"; d="scan'208";a="7578251" Received: from lonpmailmx01.citrite.net ([10.30.203.162]) by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5; 02 Sep 2011 16:41:01 +0000 Received: from woking.xci-test.com (10.80.248.135) by smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id 8.3.137.0; Fri, 2 Sep 2011 17:41:01 +0100 Received: from osstest by woking.xci-test.com with local (Exim 4.69) (envelope-from ) id 1QzWnc-0004JX-Rm; Fri, 02 Sep 2011 17:41:00 +0100 To: Message-ID: From: xen.org Date: Fri, 2 Sep 2011 17:41:00 +0100 MIME-Version: 1.0 Content-Type: text/plain Cc: ian.jackson@eu.citrix.com Subject: [Xen-devel] [xen-unstable test] 8825: tolerable FAIL - PUSHED X-BeenThere: xen-devel@lists.xensource.com X-Mailman-Version: 2.1.5 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xensource.com Errors-To: xen-devel-bounces@lists.xensource.com flight 8825 xen-unstable real [real] http://www.chiark.greenend.org.uk/~xensrcts/logs/8825/ Failures :-/ but no regressions. Tests which did not succeed, but are not blocking, including regressions (tests previously passed) regarded as allowable: test-amd64-amd64-xl-pcipt-intel 9 guest-start fail never pass test-amd64-i386-rhel6hvm-intel 9 guest-start.2 fail never pass test-amd64-i386-win-vcpus1 16 leak-check/check fail never pass test-amd64-i386-rhel6hvm-amd 9 guest-start.2 fail never pass test-amd64-i386-win 16 leak-check/check fail never pass test-amd64-amd64-win 16 leak-check/check fail never pass test-amd64-amd64-xl-win 13 guest-stop fail never pass test-i386-i386-xl-win 13 guest-stop fail never pass test-i386-i386-win 16 leak-check/check fail never pass test-amd64-i386-xl-win-vcpus1 13 guest-stop fail never pass version targeted for testing: xen a6a5bda3c962 baseline version: xen ac9aa65050e9 ------------------------------------------------------------ People who touched revisions under test: Andrew Cooper Christoph Egger Dietmar Hahn Ian Campbell Ian Jackson Keir Fraser Kevin Tian Laszlo Ersek Olaf Hering Stefano Stabellini Tim Deegan ------------------------------------------------------------ jobs: build-amd64 pass build-i386 pass build-amd64-oldkern pass build-i386-oldkern pass build-amd64-pvops pass build-i386-pvops pass test-amd64-amd64-xl pass test-amd64-i386-xl pass test-i386-i386-xl pass test-amd64-i386-rhel6hvm-amd fail test-amd64-i386-xl-credit2 pass test-amd64-amd64-xl-pcipt-intel fail test-amd64-i386-rhel6hvm-intel fail test-amd64-i386-xl-multivcpu pass test-amd64-amd64-pair pass test-amd64-i386-pair pass test-i386-i386-pair pass test-amd64-amd64-pv pass test-amd64-i386-pv pass test-i386-i386-pv pass test-amd64-amd64-xl-sedf pass test-amd64-i386-win-vcpus1 fail test-amd64-i386-xl-win-vcpus1 fail test-amd64-amd64-win fail test-amd64-i386-win fail test-i386-i386-win fail test-amd64-amd64-xl-win fail test-i386-i386-xl-win fail ------------------------------------------------------------ sg-report-flight on woking.cam.xci-test.com logs: /home/xc_osstest/logs images: /home/xc_osstest/images Logs, config files, etc. are available at http://www.chiark.greenend.org.uk/~xensrcts/logs Test harness code can be found at http://xenbits.xensource.com/gitweb?p=osstest.git;a=summary Pushing revision : + branch=xen-unstable + revision=a6a5bda3c962 + . cri-lock-repos ++ . cri-common +++ umask 002 +++ getconfig Repos +++ perl -e ' use Osstest; readconfigonly(); print $c{Repos} or die $!; ' ++ repos=/export/home/osstest/repos ++ repos_lock=/export/home/osstest/repos/lock ++ '[' x '!=' x/export/home/osstest/repos/lock ']' ++ OSSTEST_REPOS_LOCK_LOCKED=/export/home/osstest/repos/lock ++ exec with-lock-ex -w /export/home/osstest/repos/lock ./ap-push xen-unstable a6a5bda3c962 + branch=xen-unstable + revision=a6a5bda3c962 + . cri-lock-repos ++ . cri-common +++ umask 002 +++ getconfig Repos +++ perl -e ' use Osstest; readconfigonly(); print $c{Repos} or die $!; ' ++ repos=/export/home/osstest/repos ++ repos_lock=/export/home/osstest/repos/lock ++ '[' x/export/home/osstest/repos/lock '!=' x/export/home/osstest/repos/lock ']' + : xen@xenbits.xensource.com + : xen@xenbits.xensource.com:git/linux-pvops + : master + : tested/2.6.39.x + case "$branch" in + cd /export/home/osstest/repos/xen-unstable.hg + hg push -r a6a5bda3c962 ssh://xen@xenbits.xensource.com/HG/xen-unstable.hg pushing to ssh://xen@xenbits.xensource.com/HG/xen-unstable.hg searching for changes remote: adding changesets remote: adding manifests remote: adding file changes remote: added 11 changesets with 23 changes to 19 files _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel From xen-devel-bounces@lists.xensource.com Fri Sep 02 10:27:44 2011 Return-path: Envelope-to: www-data@lists.xensource.com Delivery-date: Fri, 02 Sep 2011 10:27:44 -0700 Received: from localhost ([127.0.0.1] helo=lists.colo.xensource.com) by lists.xensource.com with esmtp (Exim 4.43) id 1QzXWq-0000b5-2Q; Fri, 02 Sep 2011 10:27:44 -0700 Received: from mail27.messagelabs.com ([193.109.254.147]) by lists.xensource.com with smtp (Exim 4.43) id 1QzXW8-0000OW-9l for xen-devel@lists.xensource.com; Fri, 02 Sep 2011 10:27:00 -0700 X-Env-Sender: Stefano.Stabellini@eu.citrix.com X-Msg-Ref: server-4.tower-27.messagelabs.com!1314984401!41258256!1 X-Originating-IP: [62.200.22.115] X-StarScan-Version: 6.3.6; banners=-,-,- X-VirusChecked: Checked Received: (qmail 31448 invoked from network); 2 Sep 2011 17:26:41 -0000 Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115) by server-4.tower-27.messagelabs.com with SMTP; 2 Sep 2011 17:26:41 -0000 X-IronPort-AV: E=Sophos;i="4.68,320,1312156800"; d="scan'208";a="7578697" Received: from lonpmailmx01.citrite.net ([10.30.203.162]) by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5; 02 Sep 2011 17:26:46 +0000 Received: from kaball.uk.xensource.com (10.80.2.59) by LONPMAILMX01.citrite.net (10.30.203.162) with Microsoft SMTP Server id 8.3.137.0; Fri, 2 Sep 2011 18:26:46 +0100 Date: Fri, 2 Sep 2011 18:34:38 +0100 From: Stefano Stabellini X-X-Sender: sstabellini@kaball-desktop To: Stefano Stabellini In-Reply-To: Message-ID: References: <4E5F5B12.4080206@canonical.com> User-Agent: Alpine 2.00 (DEB 1167 2008-08-23) MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Cc: Jeremy Fitzhardinge , "xen-devel@lists.xensource.com" , Stefan Bader Subject: [Xen-devel] Re: HVM guests and pvlocks not working as expected X-BeenThere: xen-devel@lists.xensource.com X-Mailman-Version: 2.1.5 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xensource.com Errors-To: xen-devel-bounces@lists.xensource.com On Fri, 2 Sep 2011, Stefano Stabellini wrote: > On Thu, 1 Sep 2011, Stefan Bader wrote: > > After much joy with this, I thought I post this to a bigger audience. After > > having migrated to Xen 4.1.1, booting HVM guests had several issues. Some > > related to interrupts not being set up correctly (which Stefano has posted > > patches) and even with those 3.0 guests seem to hang for me while 2.6.38 or > > older kernels were ok. > > > > After digging deeply into this, I think I found the issue. However, if that is > > true, it seems rather lucky if pv spinlocks in HVM worked for anybody. > > > > The xen_hvm_smp_init() call will change the smp_ops hooks. One of which is > > smp_prepare_cpus. This is done in start_kernel and at this point in time, there > > is no change to the pv_lock_ops and they point to the ticket versions. > > Later in start_kernel, check_bugs is called and part of that takes the > > pv_lock_ops and patches the kernel with the correct jumps. > > _After_ that, the kernel_init is called and that in turn does the > > smp_prepare_cpus which now changes the pv_lock_ops again, *but not* run any > > patching again. So the _raw_spin_*lock calls still use the ticket calls. > > > > start_kernel > > setup_arch -> xen_hvm_smp_init (set smp_ops) > > ... > > check_bugs -> alternative_instructions (patches pv_locks sites) > > ... > > rest_init (triggers kernel_init as a thread) > > kernel_init > > ... > > smp_prepare_cpus (calls xen_init_spinlocks through smp_ops hook) > > > > To make things even more fun, there is the possibility that some spinlock > > functions are forced to be inlined and others are not (CONFIG_INLINE_SPIN_*). In > > our special case only two versions of spin_unlock were inlined. Put that > > together into a pot with modules, shake well, and there is the fun. Basically on > > load time, the non-inline calls remain pointing to the unmodified ticket > > implementation (main kernel). But the unlock calls (which are inlined) get > > modified because the loaded module gets patched up. One can imagine that this > > does not work too well. > > > > Anyway, even without the secondary issue, I am sure that just replacing the > > functions in pv_lock_ops without the spinlock calls getting actually modified is > > not the intended behaviour. > > > > Unfortunately I have not yet been able to make it work. Any attempt to move > > xen_init_spinlocks to be called before check_bugs or adding a call to > > alternative_instructions results in another hang on boot. At least the latter > > method results in a more usable dump for crash, which shows that on spinlock was > > taken (slow) and two spurious taken ones (this is more to play for me). > > > > But then, maybe someone has some ideas there... > > we have two possible ways to solve this problem: > > 1) we wait for Jeremy's pv ticketlock series to be applied, that should > make the datastructure internally used by native ticketlock and pv > tickerlock identical, so a lock taken by the native ticket spin lock > function can be freed by the xen pv ticket spin unlock function. this simple patch is enough to make pv ticketlocks work correctly on top of Jeremy's pv ticketlocks series (cover.1314922370.git.jeremy.fitzhardinge@citrix.com): --- xen: initialize PV spinlocks before patching is done Signed-off-by: Stefano Stabellini diff --git a/arch/x86/xen/smp.c b/arch/x86/xen/smp.c index 3061244..04a84e8 100644 --- a/arch/x86/xen/smp.c +++ b/arch/x86/xen/smp.c @@ -518,7 +518,6 @@ static void __init xen_hvm_smp_prepare_cpus(unsigned int max_cpus) if (!xen_have_vector_callback) return; xen_init_lock_cpu(0); - xen_init_spinlocks(); } static int __cpuinit xen_hvm_cpu_up(unsigned int cpu) @@ -546,4 +545,5 @@ void __init xen_hvm_smp_init(void) smp_ops.cpu_die = xen_hvm_cpu_die; smp_ops.send_call_func_ipi = xen_smp_send_call_function_ipi; smp_ops.send_call_func_single_ipi = xen_smp_send_call_function_single_ipi; + xen_init_spinlocks(); } _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel From xen-devel-bounces@lists.xensource.com Fri Sep 02 12:15:58 2011 Return-path: Envelope-to: www-data@lists.xensource.com Delivery-date: Fri, 02 Sep 2011 12:15:58 -0700 Received: from localhost ([127.0.0.1] helo=lists.colo.xensource.com) by lists.xensource.com with esmtp (Exim 4.43) id 1QzZDa-0003QX-2M; Fri, 02 Sep 2011 12:15:58 -0700 Received: from mail21.messagelabs.com ([85.158.143.35]) by lists.xensource.com with smtp (Exim 4.43) id 1QzZCk-0003EX-4r for xen-devel@lists.xensource.com; Fri, 02 Sep 2011 12:15:06 -0700 X-Env-Sender: Ian.Jackson@eu.citrix.com X-Msg-Ref: server-8.tower-21.messagelabs.com!1314990888!57539077!1 X-Originating-IP: [62.200.22.115] X-StarScan-Version: 6.3.6; banners=-,-,- X-VirusChecked: Checked Received: (qmail 18621 invoked from network); 2 Sep 2011 19:14:48 -0000 Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115) by server-8.tower-21.messagelabs.com with SMTP; 2 Sep 2011 19:14:48 -0000 X-IronPort-AV: E=Sophos;i="4.68,320,1312156800"; d="scan'208";a="7579524" Received: from lonpmailmx01.citrite.net ([10.30.203.162]) by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5; 02 Sep 2011 19:15:02 +0000 Received: from woking.xci-test.com (10.80.248.135) by smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id 8.3.137.0; Fri, 2 Sep 2011 20:15:02 +0100 Received: from osstest by woking.xci-test.com with local (Exim 4.69) (envelope-from ) id 1QzZCg-0004Q9-7r; Fri, 02 Sep 2011 20:15:02 +0100 To: xen-devel@lists.xensource.com Message-ID: From: xen.org Date: Fri, 2 Sep 2011 20:15:02 +0100 MIME-Version: 1.0 Content-Type: text/plain Cc: ian.jackson@eu.citrix.com Subject: [Xen-devel] [xen-unstable test] 8826: tolerable FAIL - PUSHED X-BeenThere: xen-devel@lists.xensource.com X-Mailman-Version: 2.1.5 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xensource.com Errors-To: xen-devel-bounces@lists.xensource.com flight 8826 xen-unstable real [real] http://www.chiark.greenend.org.uk/~xensrcts/logs/8826/ Failures :-/ but no regressions. Tests which did not succeed, but are not blocking, including regressions (tests previously passed) regarded as allowable: test-amd64-amd64-xl-pcipt-intel 9 guest-start fail never pass test-amd64-i386-rhel6hvm-intel 9 guest-start.2 fail never pass test-amd64-i386-win-vcpus1 16 leak-check/check fail never pass test-amd64-i386-rhel6hvm-amd 9 guest-start.2 fail never pass test-amd64-i386-win 16 leak-check/check fail never pass test-amd64-amd64-win 16 leak-check/check fail never pass test-amd64-amd64-xl-win 13 guest-stop fail never pass test-i386-i386-xl-win 13 guest-stop fail never pass test-i386-i386-win 16 leak-check/check fail never pass test-amd64-i386-xl-win-vcpus1 13 guest-stop fail never pass version targeted for testing: xen f1349a968a5a baseline version: xen a6a5bda3c962 ------------------------------------------------------------ People who touched revisions under test: Ian Campbell Ian Jackson Keir Fraser Olaf Hering ------------------------------------------------------------ jobs: build-amd64 pass build-i386 pass build-amd64-oldkern pass build-i386-oldkern pass build-amd64-pvops pass build-i386-pvops pass test-amd64-amd64-xl pass test-amd64-i386-xl pass test-i386-i386-xl pass test-amd64-i386-rhel6hvm-amd fail test-amd64-i386-xl-credit2 pass test-amd64-amd64-xl-pcipt-intel fail test-amd64-i386-rhel6hvm-intel fail test-amd64-i386-xl-multivcpu pass test-amd64-amd64-pair pass test-amd64-i386-pair pass test-i386-i386-pair pass test-amd64-amd64-pv pass test-amd64-i386-pv pass test-i386-i386-pv pass test-amd64-amd64-xl-sedf pass test-amd64-i386-win-vcpus1 fail test-amd64-i386-xl-win-vcpus1 fail test-amd64-amd64-win fail test-amd64-i386-win fail test-i386-i386-win fail test-amd64-amd64-xl-win fail test-i386-i386-xl-win fail ------------------------------------------------------------ sg-report-flight on woking.cam.xci-test.com logs: /home/xc_osstest/logs images: /home/xc_osstest/images Logs, config files, etc. are available at http://www.chiark.greenend.org.uk/~xensrcts/logs Test harness code can be found at http://xenbits.xensource.com/gitweb?p=osstest.git;a=summary Pushing revision : + branch=xen-unstable + revision=f1349a968a5a + . cri-lock-repos ++ . cri-common +++ umask 002 +++ getconfig Repos +++ perl -e ' use Osstest; readconfigonly(); print $c{Repos} or die $!; ' ++ repos=/export/home/osstest/repos ++ repos_lock=/export/home/osstest/repos/lock ++ '[' x '!=' x/export/home/osstest/repos/lock ']' ++ OSSTEST_REPOS_LOCK_LOCKED=/export/home/osstest/repos/lock ++ exec with-lock-ex -w /export/home/osstest/repos/lock ./ap-push xen-unstable f1349a968a5a + branch=xen-unstable + revision=f1349a968a5a + . cri-lock-repos ++ . cri-common +++ umask 002 +++ getconfig Repos +++ perl -e ' use Osstest; readconfigonly(); print $c{Repos} or die $!; ' ++ repos=/export/home/osstest/repos ++ repos_lock=/export/home/osstest/repos/lock ++ '[' x/export/home/osstest/repos/lock '!=' x/export/home/osstest/repos/lock ']' + : xen@xenbits.xensource.com + : xen@xenbits.xensource.com:git/linux-pvops + : master + : tested/2.6.39.x + case "$branch" in + cd /export/home/osstest/repos/xen-unstable.hg + hg push -r f1349a968a5a ssh://xen@xenbits.xensource.com/HG/xen-unstable.hg pushing to ssh://xen@xenbits.xensource.com/HG/xen-unstable.hg searching for changes remote: adding changesets remote: adding manifests remote: adding file changes remote: added 1 changesets with 1 changes to 1 files _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel From xen-devel-bounces@lists.xensource.com Fri Sep 02 12:27:31 2011 Return-path: Envelope-to: www-data@lists.xensource.com Delivery-date: Fri, 02 Sep 2011 12:27:31 -0700 Received: from localhost ([127.0.0.1] helo=lists.colo.xensource.com) by lists.xensource.com with esmtp (Exim 4.43) id 1QzZOk-00041R-W8; Fri, 02 Sep 2011 12:27:31 -0700 Received: from mail21.messagelabs.com ([85.158.143.35]) by lists.xensource.com with esmtp (Exim 4.43) id 1QzZNx-0003os-Mw for xen-devel@lists.xensource.com; Fri, 02 Sep 2011 12:26:44 -0700 X-Env-Sender: jeremy@goop.org X-Msg-Ref: server-8.tower-21.messagelabs.com!1314991582!57539597!1 X-Originating-IP: [74.207.240.146] X-StarScan-Version: 6.3.6; banners=-,-,- X-VirusChecked: Checked Received: (qmail 31028 invoked from network); 2 Sep 2011 19:26:24 -0000 Received: from claw.goop.org (HELO claw.goop.org) (74.207.240.146) by server-8.tower-21.messagelabs.com with DHE-RSA-AES256-SHA encrypted SMTP; 2 Sep 2011 19:26:24 -0000 Received: from saboo.goop.org (unknown [IPv6:2001:470:1f05:899:f2de:f1ff:fe5c:34ed]) (Authenticated sender: smtp-saboo) by claw.goop.org (Postfix) with ESMTPSA id 08FC99257; Fri, 2 Sep 2011 12:26:36 -0700 (PDT) Received: from saboo.goop.org (localhost [IPv6:::1]) by saboo.goop.org (Postfix) with ESMTP id 32C1220166; Fri, 2 Sep 2011 12:26:32 -0700 (PDT) Message-ID: <4E612DE8.3040709@goop.org> Date: Fri, 02 Sep 2011 12:26:32 -0700 From: Jeremy Fitzhardinge User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:6.0) Gecko/20110816 Thunderbird/6.0 MIME-Version: 1.0 To: Konrad Rzeszutek Wilk Subject: Re: [Xen-devel] [Xen-deve] xen/stable-2.6.32.x bare-metal: panic early exception 0e rip 10:0 error 10 cr2 0 References: <4E4D9A90.30800@leuphana.de> <4E600A57.9040208@goop.org> <20110902133703.GB5968@dumpdata.com> In-Reply-To: <20110902133703.GB5968@dumpdata.com> X-Enigmail-Version: 1.3.1 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: xen-devel@lists.xensource.com, M A Young X-BeenThere: xen-devel@lists.xensource.com X-Mailman-Version: 2.1.5 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xensource.com Errors-To: xen-devel-bounces@lists.xensource.com On 09/02/2011 06:37 AM, Konrad Rzeszutek Wilk wrote: > On Fri, Sep 02, 2011 at 12:44:31AM +0100, M A Young wrote: >> >> On Thu, 1 Sep 2011, Jeremy Fitzhardinge wrote: >> >>> On 09/01/2011 02:29 PM, M A Young wrote: >>>> On Wed, 31 Aug 2011, M A Young wrote: >>>> >>>>> On Fri, 19 Aug 2011, Andreas Olsowski wrote: >>>>> >>>>>> Source: >>>>>> git://git.kernel.org/pub/scm/linux/kernel/git/jeremy/xen.git >>>>>> >>>>>> Tested branches: >>>>>> xen/stable-2.6.32.x >>>>>> xen/next-2.6.32.x >>>>>> >>>>>> When trying to boot the current kernel bare-metal it will not load >>>>>> properly, instead i am prompted with: >>>>>> >>>>>> panic early exception 0e rip 10:0 error 10 cr2 0 >>>>> I am seeing this as well. I have been trying to narrow it down a bit, >>>>> and it seems to me that the bug was introduced somewhere between >>>>> xen-2.6.32.39 and xen-2.6.32.42. >>>> xen-2.6.32.40 also crashes. I think that means that it is either >>>> commits c3dd7941354fa96a71f2613e2c7a1b215fa175dc or >>>> 280802657fb95c52bb5a35d43fea60351883b2af (or something in the stable >>>> kernel or else compile differences though both are unlikely). I am >>>> still working on this to confirm which patch it is. >>> 280802657fb95c5 is unlikely - that's just a blkback change. >>> >>> c3dd7941354fa96 looks plausible. >> Yes, xen-2.6.32.40 with c3dd7941354fa96a71f2613e2c7a1b215fa175dc >> reverted will boot on bare metal. > bare metal. Yes, it won't work under that - at least > not in that state. > > Jeremy, can you revert that patch please - it was fixing one instance > of machines - and it looks to be breaking many more. Done. Unfortunately I can't push it because kernel.org is still out. J _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel From xen-devel-bounces@lists.xensource.com Fri Sep 02 12:30:21 2011 Return-path: Envelope-to: www-data@lists.xensource.com Delivery-date: Fri, 02 Sep 2011 12:30:21 -0700 Received: from localhost ([127.0.0.1] helo=lists.colo.xensource.com) by lists.xensource.com with esmtp (Exim 4.43) id 1QzZRV-0004QR-Ai; Fri, 02 Sep 2011 12:30:21 -0700 Received: from mail21.messagelabs.com ([85.158.143.35]) by lists.xensource.com with esmtp (Exim 4.43) id 1QzZQu-0004Dj-EU for xen-devel@lists.xensource.com; Fri, 02 Sep 2011 12:29:45 -0700 X-Env-Sender: jeremy@goop.org X-Msg-Ref: server-7.tower-21.messagelabs.com!1314991751!53415214!1 X-Originating-IP: [74.207.240.146] X-StarScan-Version: 6.3.6; banners=-,-,- X-VirusChecked: Checked Received: (qmail 26197 invoked from network); 2 Sep 2011 19:29:13 -0000 Received: from claw.goop.org (HELO claw.goop.org) (74.207.240.146) by server-7.tower-21.messagelabs.com with DHE-RSA-AES256-SHA encrypted SMTP; 2 Sep 2011 19:29:13 -0000 Received: from saboo.goop.org (unknown [IPv6:2001:470:1f05:899:f2de:f1ff:fe5c:34ed]) (Authenticated sender: smtp-saboo) by claw.goop.org (Postfix) with ESMTPSA id 55F969264; Fri, 2 Sep 2011 12:29:39 -0700 (PDT) Received: from saboo.goop.org (localhost [IPv6:::1]) by saboo.goop.org (Postfix) with ESMTP id 6C63520166; Fri, 2 Sep 2011 12:29:37 -0700 (PDT) Message-ID: <4E612EA1.20007@goop.org> Date: Fri, 02 Sep 2011 12:29:37 -0700 From: Jeremy Fitzhardinge User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:6.0) Gecko/20110816 Thunderbird/6.0 MIME-Version: 1.0 To: Peter Zijlstra References: <38bb37e15f6e5056d5238adac945bc1837a996ec.1314922370.git.jeremy.fitzhardinge@citrix.com> <1314974826.1861.1.camel@twins> In-Reply-To: <1314974826.1861.1.camel@twins> X-Enigmail-Version: 1.3.1 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Cc: Marcelo Tosatti , Nick Piggin , KVM , the arch/x86 maintainers , Linux Kernel Mailing List , Andi Kleen , Avi Kivity , Jeremy Fitzhardinge , "H. Peter Anvin" , Ingo Molnar , Linus Torvalds , Xen Devel Subject: [Xen-devel] Re: [PATCH 08/13] xen/pvticketlock: disable interrupts while blocking X-BeenThere: xen-devel@lists.xensource.com X-Mailman-Version: 2.1.5 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xensource.com Errors-To: xen-devel-bounces@lists.xensource.com On 09/02/2011 07:47 AM, Peter Zijlstra wrote: > On Thu, 2011-09-01 at 17:55 -0700, Jeremy Fitzhardinge wrote: >> From: Jeremy Fitzhardinge >> >> We need to make sure interrupts are disabled while we're relying on the >> contents of the per-cpu lock_waiting values, otherwise an interrupt >> handler could come in, try to take some other lock, block, and overwrite >> our values. > Would this make it illegal to take a spinlock from NMI context? That would be problematic. But a Xen domain wouldn't be getting NMIs - at least not standard x86 ones - so that's moot. > I know that its generally considered bad form, but there's at least one > spinlock that's only taken from NMI context and thus hasn't got any > deadlock potential. Which one? J _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel From xen-devel-bounces@lists.xensource.com Fri Sep 02 12:31:15 2011 Return-path: Envelope-to: www-data@lists.xensource.com Delivery-date: Fri, 02 Sep 2011 12:31:15 -0700 Received: from localhost ([127.0.0.1] helo=lists.colo.xensource.com) by lists.xensource.com with esmtp (Exim 4.43) id 1QzZSN-0004ne-3H; Fri, 02 Sep 2011 12:31:15 -0700 Received: from mail27.messagelabs.com ([193.109.254.147]) by lists.xensource.com with esmtp (Exim 4.43) id 1QzZRp-0004X6-Ap for xen-devel@lists.xensource.com; Fri, 02 Sep 2011 12:30:42 -0700 X-Env-Sender: jeremy@goop.org X-Msg-Ref: server-7.tower-27.messagelabs.com!1314991816!47078276!1 X-Originating-IP: [74.207.240.146] X-StarScan-Version: 6.3.6; banners=-,-,- X-VirusChecked: Checked Received: (qmail 1758 invoked from network); 2 Sep 2011 19:30:18 -0000 Received: from claw.goop.org (HELO claw.goop.org) (74.207.240.146) by server-7.tower-27.messagelabs.com with DHE-RSA-AES256-SHA encrypted SMTP; 2 Sep 2011 19:30:18 -0000 Received: from saboo.goop.org (unknown [IPv6:2001:470:1f05:899:f2de:f1ff:fe5c:34ed]) (Authenticated sender: smtp-saboo) by claw.goop.org (Postfix) with ESMTPSA id BFD119264; Fri, 2 Sep 2011 12:30:31 -0700 (PDT) Received: from saboo.goop.org (localhost [IPv6:::1]) by saboo.goop.org (Postfix) with ESMTP id 12CC320166; Fri, 2 Sep 2011 12:30:29 -0700 (PDT) Message-ID: <4E612ED5.7050303@goop.org> Date: Fri, 02 Sep 2011 12:30:29 -0700 From: Jeremy Fitzhardinge User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:6.0) Gecko/20110816 Thunderbird/6.0 MIME-Version: 1.0 To: Peter Zijlstra References: <17a0f6177a71190dad30a6dcd1da93bec13a7836.1314922370.git.jeremy.fitzhardinge@citrix.com> <1314974905.1861.2.camel@twins> In-Reply-To: <1314974905.1861.2.camel@twins> X-Enigmail-Version: 1.3.1 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Cc: Marcelo Tosatti , Nick Piggin , KVM , the arch/x86 maintainers , Linux Kernel Mailing List , Andi Kleen , Avi Kivity , Jeremy Fitzhardinge , "H. Peter Anvin" , Ingo Molnar , Linus Torvalds , Xen Devel Subject: [Xen-devel] Re: [PATCH 10/13] xen/pvticket: allow interrupts to be enabled while blocking X-BeenThere: xen-devel@lists.xensource.com X-Mailman-Version: 2.1.5 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xensource.com Errors-To: xen-devel-bounces@lists.xensource.com On 09/02/2011 07:48 AM, Peter Zijlstra wrote: > On Thu, 2011-09-01 at 17:55 -0700, Jeremy Fitzhardinge wrote: >> + /* Make sure an interrupt handler can't upset things in a >> + partially setup state. */ >> local_irq_save(flags); >> >> + /* >> + * We don't really care if we're overwriting some other >> + * (lock,want) pair, as that would mean that we're currently >> + * in an interrupt context, and the outer context had >> + * interrupts enabled. That has already kicked the VCPU out >> + * of xen_poll_irq(), so it will just return spuriously and >> + * retry with newly setup (lock,want). >> + * >> + * The ordering protocol on this is that the "lock" pointer >> + * may only be set non-NULL if the "want" ticket is correct. >> + * If we're updating "want", we must first clear "lock". >> + */ >> + w->lock = NULL; > I mean, I don't much care about Xen code, but that's two different > comment styles. Yeah, that's the "two line comment style" next to "big block comment" style - but you're right they look pretty bad juxtaposed like that. J _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel From xen-devel-bounces@lists.xensource.com Fri Sep 02 12:33:01 2011 Return-path: Envelope-to: www-data@lists.xensource.com Delivery-date: Fri, 02 Sep 2011 12:33:01 -0700 Received: from localhost ([127.0.0.1] helo=lists.colo.xensource.com) by lists.xensource.com with esmtp (Exim 4.43) id 1QzZU5-0005EA-0n; Fri, 02 Sep 2011 12:33:01 -0700 Received: from mail182.messagelabs.com ([85.158.139.83]) by lists.xensource.com with esmtp (Exim 4.43) id 1QzZTc-00051u-Q5 for xen-devel@lists.xensource.com; Fri, 02 Sep 2011 12:32:33 -0700 X-Env-Sender: jeremy@goop.org X-Msg-Ref: server-13.tower-182.messagelabs.com!1314991948!16702238!1 X-Originating-IP: [74.207.240.146] X-StarScan-Version: 6.3.6; banners=-,-,- X-VirusChecked: Checked Received: (qmail 29612 invoked from network); 2 Sep 2011 19:32:29 -0000 Received: from claw.goop.org (HELO claw.goop.org) (74.207.240.146) by server-13.tower-182.messagelabs.com with DHE-RSA-AES256-SHA encrypted SMTP; 2 Sep 2011 19:32:29 -0000 Received: from saboo.goop.org (unknown [IPv6:2001:470:1f05:899:f2de:f1ff:fe5c:34ed]) (Authenticated sender: smtp-saboo) by claw.goop.org (Postfix) with ESMTPSA id 784E19272; Fri, 2 Sep 2011 12:32:27 -0700 (PDT) Received: from saboo.goop.org (localhost [IPv6:::1]) by saboo.goop.org (Postfix) with ESMTP id 78A0E20166; Fri, 2 Sep 2011 12:32:25 -0700 (PDT) Message-ID: <4E612F49.9080100@goop.org> Date: Fri, 02 Sep 2011 12:32:25 -0700 From: Jeremy Fitzhardinge User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:6.0) Gecko/20110816 Thunderbird/6.0 MIME-Version: 1.0 To: Eric Northup References: <8a788f3fbf2ad1316e462bf5aae623bab9d38319.1314922370.git.jeremy.fitzhardinge@citrix.com> In-Reply-To: X-Enigmail-Version: 1.3.1 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: Marcelo Tosatti , Nick Piggin , KVM , Peter Zijlstra , the arch/x86 maintainers , Linux Kernel Mailing List , Andi Kleen , Avi Kivity , Jeremy Fitzhardinge , "H. Peter Anvin" , Ingo Molnar , Linus Torvalds , Xen Devel Subject: [Xen-devel] Re: [PATCH 06/13] x86/ticketlock: add slowpath logic X-BeenThere: xen-devel@lists.xensource.com X-Mailman-Version: 2.1.5 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xensource.com Errors-To: xen-devel-bounces@lists.xensource.com On 09/02/2011 11:46 AM, Eric Northup wrote: > On Thu, Sep 1, 2011 at 5:54 PM, Jeremy Fitzhardinge wrote: >> From: Jeremy Fitzhardinge >> >> Maintain a flag in both LSBs of the ticket lock which indicates whether >> anyone is in the lock slowpath and may need kicking when the current >> holder unlocks. The flags are set when the first locker enters >> the slowpath, and cleared when unlocking to an empty queue. > Are there actually two flags maintained? I only see the one in the > ticket tail getting set/cleared/tested. Yeah, there's only one flag, so there's a spare bit in the other half. j _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel From xen-devel-bounces@lists.xensource.com Fri Sep 02 12:34:54 2011 Return-path: Envelope-to: www-data@lists.xensource.com Delivery-date: Fri, 02 Sep 2011 12:34:54 -0700 Received: from localhost ([127.0.0.1] helo=lists.colo.xensource.com) by lists.xensource.com with esmtp (Exim 4.43) id 1QzZVu-0005ct-EE; Fri, 02 Sep 2011 12:34:54 -0700 Received: from mail182.messagelabs.com ([85.158.139.83]) by lists.xensource.com with esmtp (Exim 4.43) id 1QzZVN-0005QL-Uu for xen-devel@lists.xensource.com; Fri, 02 Sep 2011 12:34:23 -0700 X-Env-Sender: jeremy@goop.org X-Msg-Ref: server-14.tower-182.messagelabs.com!1314992057!16697767!1 X-Originating-IP: [74.207.240.146] X-StarScan-Version: 6.3.6; banners=-,-,- X-VirusChecked: Checked Received: (qmail 3711 invoked from network); 2 Sep 2011 19:34:18 -0000 Received: from claw.goop.org (HELO claw.goop.org) (74.207.240.146) by server-14.tower-182.messagelabs.com with DHE-RSA-AES256-SHA encrypted SMTP; 2 Sep 2011 19:34:18 -0000 Received: from saboo.goop.org (unknown [IPv6:2001:470:1f05:899:f2de:f1ff:fe5c:34ed]) (Authenticated sender: smtp-saboo) by claw.goop.org (Postfix) with ESMTPSA id 9FD3D9276; Fri, 2 Sep 2011 12:34:16 -0700 (PDT) Received: from saboo.goop.org (localhost [IPv6:::1]) by saboo.goop.org (Postfix) with ESMTP id B9BA520166; Fri, 2 Sep 2011 12:34:14 -0700 (PDT) Message-ID: <4E612FB6.9030904@goop.org> Date: Fri, 02 Sep 2011 12:34:14 -0700 From: Jeremy Fitzhardinge User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:6.0) Gecko/20110816 Thunderbird/6.0 MIME-Version: 1.0 To: Peter Zijlstra References: <8cd2c77886e2d3fcad8258aa62509b3b2fae5545.1314922370.git.jeremy.fitzhardinge@citrix.com> <1314974968.1861.3.camel@twins> In-Reply-To: <1314974968.1861.3.camel@twins> X-Enigmail-Version: 1.3.1 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Cc: Marcelo Tosatti , Nick Piggin , KVM , the arch/x86 maintainers , Linux Kernel Mailing List , Srivatsa Vaddagiri , Andi Kleen , Avi Kivity , Jeremy Fitzhardinge , "H. Peter Anvin" , Ingo Molnar , Linus Torvalds , Xen Devel Subject: [Xen-devel] Re: [PATCH 11/13] x86/ticketlock: only do kick after doing unlock X-BeenThere: xen-devel@lists.xensource.com X-Mailman-Version: 2.1.5 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xensource.com Errors-To: xen-devel-bounces@lists.xensource.com On 09/02/2011 07:49 AM, Peter Zijlstra wrote: > On Thu, 2011-09-01 at 17:55 -0700, Jeremy Fitzhardinge wrote: >> From: Srivatsa Vaddagiri >> >> We must release the lock before checking to see if the lock is in >> slowpath or else there's a potential race where the lock enters the >> slow path after the unlocker has checked the slowpath flag, but before >> it has actually unlocked. >> >> Signed-off-by: Srivatsa Vaddagiri >> Signed-off-by: Jeremy Fitzhardinge > Wouldn't it be much better to fold it back so that this bug never > happens when you bisect? Yes indeed. J _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel From xen-devel-bounces@lists.xensource.com Fri Sep 02 13:10:40 2011 Return-path: Envelope-to: www-data@lists.xensource.com Delivery-date: Fri, 02 Sep 2011 13:10:40 -0700 Received: from localhost ([127.0.0.1] helo=lists.colo.xensource.com) by lists.xensource.com with esmtp (Exim 4.43) id 1Qza4V-0007Pp-NA; Fri, 02 Sep 2011 13:10:39 -0700 Received: from mail216.messagelabs.com ([85.158.143.99]) by lists.xensource.com with esmtp (Exim 4.43) id 1Qza1X-0007BA-9f for xen-devel@lists.xensource.com; Fri, 02 Sep 2011 13:08:10 -0700 X-Env-Sender: jeremy@goop.org X-Msg-Ref: server-11.tower-216.messagelabs.com!1314994050!9309819!1 X-Originating-IP: [74.207.240.146] X-StarScan-Version: 6.3.6; banners=-,-,- X-VirusChecked: Checked Received: (qmail 31810 invoked from network); 2 Sep 2011 20:07:32 -0000 Received: from claw.goop.org (HELO claw.goop.org) (74.207.240.146) by server-11.tower-216.messagelabs.com with DHE-RSA-AES256-SHA encrypted SMTP; 2 Sep 2011 20:07:32 -0000 Received: from saboo.goop.org (unknown [IPv6:2001:470:1f05:899:f2de:f1ff:fe5c:34ed]) (Authenticated sender: smtp-saboo) by claw.goop.org (Postfix) with ESMTPSA id 4DD3692F4; Fri, 2 Sep 2011 13:07:29 -0700 (PDT) Received: from saboo.goop.org (localhost [IPv6:::1]) by saboo.goop.org (Postfix) with ESMTP id 28F2320214; Fri, 2 Sep 2011 13:07:23 -0700 (PDT) Message-ID: <4E61377B.4020600@goop.org> Date: Fri, 02 Sep 2011 13:07:23 -0700 From: Jeremy Fitzhardinge User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:6.0) Gecko/20110816 Thunderbird/6.0 MIME-Version: 1.0 To: Linus Torvalds References: In-Reply-To: X-Enigmail-Version: 1.3.1 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: Marcelo Tosatti , Nick Piggin , KVM , Peter Zijlstra , the arch/x86 maintainers , Linux Kernel Mailing List , Andi Kleen , Avi Kivity , Jeremy Fitzhardinge , "H. Peter Anvin" , Ingo Molnar , Xen Devel Subject: [Xen-devel] Re: [PATCH 00/13] [PATCH RFC] Paravirtualized ticketlocks X-BeenThere: xen-devel@lists.xensource.com X-Mailman-Version: 2.1.5 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xensource.com Errors-To: xen-devel-bounces@lists.xensource.com On 09/02/2011 08:38 AM, Linus Torvalds wrote: > On Thu, Sep 1, 2011 at 5:54 PM, Jeremy Fitzhardinge wrote: >> The inner part of ticket lock code becomes: >> inc = xadd(&lock->tickets, inc); >> inc.tail &= ~TICKET_SLOWPATH_FLAG; >> >> for (;;) { >> unsigned count = SPIN_THRESHOLD; >> >> do { >> if (inc.head == inc.tail) >> goto out; >> cpu_relax(); >> inc.head = ACCESS_ONCE(lock->tickets.head); >> } while (--count); >> __ticket_lock_spinning(lock, inc.tail); >> } > Hmm. It strikes me that I don't think you should touch the > TICKET_SLOWPATH_FLAG in the fastpath at all. > > Can't you just do this: > > inc = xadd(&lock->tickets, inc); > if (likely(inc.head == inc.tail)) > goto out; > > ### SLOWPATH ### > inc.tail &= ~TICKET_SLOWPATH_FLAG; > for (;;) { > .. as before .. > > which might alleviate the problem with the fastpath being polluted by > all those silly slowpath things. Hmm? > > (This assumes that TICKET_SLOWPATH_FLAG is never set in inc.head, so > if it's set that equality check will fail. I didn't actually check if > that assumption was correct) Yes, nice idea. That ends up making the overall code slightly longer, but the fastpath becomes identical to the non-pv case: mov $512,%ecx lock xadd %cx,(%rdi) movzbl %ch,%edx cmp %cl,%dl je 2f ### SLOWPATH START and $-2,%edx mov $8192,%eax movzbl %dl,%esi 1: cmp %dl,%cl je 2f pause dec %eax mov (%rdi),%cl jne 1b callq __ticket_lock_spinning mov $8192,%eax jmp 1b ### SLOWPATH ENDS 2: It's especially nice that it also moves the spin counter and arg setup into the slowpath code. And that entire piece of slowpath code can be moved out into its own function, so the fastpath becomes: mov $512,%eax lock xadd %ax,(%rdi) movzbl %ah,%esi cmp %al,%sil je 1f movzbl %sil,%esi callq __ticket_lock_slow 1: I don't know whether that fastpath code is small enough to consider inlining everywhere? J _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel From xen-devel-bounces@lists.xensource.com Fri Sep 02 13:27:04 2011 Return-path: Envelope-to: www-data@lists.xensource.com Delivery-date: Fri, 02 Sep 2011 13:27:04 -0700 Received: from localhost ([127.0.0.1] helo=lists.colo.xensource.com) by lists.xensource.com with esmtp (Exim 4.43) id 1QzaKO-00088O-6N; Fri, 02 Sep 2011 13:27:04 -0700 Received: from mail27.messagelabs.com ([193.109.254.147]) by lists.xensource.com with esmtp (Exim 4.43) id 1QzaJv-0007vw-D5 for xen-devel@lists.xensource.com; Fri, 02 Sep 2011 13:26:35 -0700 X-Env-Sender: jeremy@goop.org X-Msg-Ref: server-15.tower-27.messagelabs.com!1314995183!47189649!1 X-Originating-IP: [74.207.240.146] X-StarScan-Version: 6.3.6; banners=-,-,- X-VirusChecked: Checked Received: (qmail 5149 invoked from network); 2 Sep 2011 20:26:25 -0000 Received: from claw.goop.org (HELO claw.goop.org) (74.207.240.146) by server-15.tower-27.messagelabs.com with DHE-RSA-AES256-SHA encrypted SMTP; 2 Sep 2011 20:26:25 -0000 Received: from saboo.goop.org (unknown [IPv6:2001:470:1f05:899:f2de:f1ff:fe5c:34ed]) (Authenticated sender: smtp-saboo) by claw.goop.org (Postfix) with ESMTPSA id AB90F34D; Fri, 2 Sep 2011 13:26:29 -0700 (PDT) Received: from saboo.goop.org (localhost [IPv6:::1]) by saboo.goop.org (Postfix) with ESMTP id AACD72006C; Fri, 2 Sep 2011 13:26:23 -0700 (PDT) Message-ID: <4E613BEF.30908@goop.org> Date: Fri, 02 Sep 2011 13:26:23 -0700 From: Jeremy Fitzhardinge User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:6.0) Gecko/20110816 Thunderbird/6.0 MIME-Version: 1.0 To: Ian Campbell Subject: Re: [Xen-devel] Kernel bug from 3.0 (was phy disks and vifs timing out in DomU) References: <4E31820C.5030200@overnetdata.com> <1311870512.24408.153.camel@cthulhu.hellion.org.uk> <4E3266DE.9000606@overnetdata.com> <20110803152841.GA2860@dumpdata.com> <4E4E3957.1040007@overnetdata.com> <20110819125615.GA26558@dumpdata.com> <4E56B132.9050708@overnetdata.com> <20110826142606.GA25511@dumpdata.com> <20110826144438.GA24836@dumpdata.com> <4E5E6843.7050206@citrix.com> <20110831170711.GB13642@dumpdata.com> <1314862972.28989.74.camel@zakaz.uk.xensource.com> <4E5FC197.7040004@goop.org> <1314904905.19389.28.camel@dagon.hellion.org.uk> <4E5FEC71.4090504@goop.org> <1314947875.28989.155.camel@zakaz.uk.xensource.com> In-Reply-To: <1314947875.28989.155.camel@zakaz.uk.xensource.com> X-Enigmail-Version: 1.3.1 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Cc: "xen-devel@lists.xensource.com" , Keir Fraser , Anthony Wright , Konrad Rzeszutek Wilk , David Vrabel , Todd Deshane X-BeenThere: xen-devel@lists.xensource.com X-Mailman-Version: 2.1.5 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xensource.com Errors-To: xen-devel-bounces@lists.xensource.com On 09/02/2011 12:17 AM, Ian Campbell wrote: > On Thu, 2011-09-01 at 21:34 +0100, Jeremy Fitzhardinge wrote: >> On 09/01/2011 12:21 PM, Ian Campbell wrote: >>> On Thu, 2011-09-01 at 18:32 +0100, Jeremy Fitzhardinge wrote: >>>> On 09/01/2011 12:42 AM, Ian Campbell wrote: >>>>> On Wed, 2011-08-31 at 18:07 +0100, Konrad Rzeszutek Wilk wrote: >>>>>> On Wed, Aug 31, 2011 at 05:58:43PM +0100, David Vrabel wrote: >>>>>>> On 26/08/11 15:44, Konrad Rzeszutek Wilk wrote: >>>>>>>> So while I am still looking at the hypervisor code to figure out why >>>>>>>> it would give me [when trying to map a grant page]: >>>>>>>> >>>>>>>> (XEN) mm.c:3846:d0 Could not find L1 PTE for address fbb42000 >>>>>>> It is failing in guest_map_l1e() because the page for the vmalloc'd >>>>>>> virtual address PTEs is not present. >>>>>>> >>>>>>> The test that fails is: >>>>>>> >>>>>>> (l2e_get_flags(l2e) & (_PAGE_PRESENT | _PAGE_PSE)) != _PAGE_PRESENT >>>>>>> >>>>>>> I think this is because the GNTTABOP_map_grant_ref hypercall is done >>>>>>> when task->active_mm != &init_mm and alloc_vm_area() only adds PTEs into >>>>>>> init_mm so when Xen looks in the page tables it doesn't find the entries >>>>>>> because they're not there yet. >>>>>>> >>>>>>> Putting a call to vmalloc_sync_all() after create_vm_area() and before >>>>>>> the hypercall makes it work for me. Classic Xen kernels used to have >>>>>>> such a call. >>>>>> That sounds quite reasonable. >>>>> I was wondering why upstream was missing the vmalloc_sync_all() in >>>>> alloc_vm_area() since the out-of-tree kernels did have it and the >>>>> function was added by us. I found this: >>>>> http://git.kernel.org/?p=linux/kernel/git/torvalds/linux.git;a=commitdiff;h=ef691947d8a3d479e67652312783aedcf629320a >>>>> >>>>> commit ef691947d8a3d479e67652312783aedcf629320a >>>>> Author: Jeremy Fitzhardinge >>>>> Date: Wed Dec 1 15:45:48 2010 -0800 >>>>> >>>>> vmalloc: remove vmalloc_sync_all() from alloc_vm_area() >>>>> >>>>> There's no need for it: it will get faulted into the current pagetable >>>>> as needed. >>>>> >>>>> Signed-off-by: Jeremy Fitzhardinge >>>>> >>>>> The flaw in the reasoning here is that you cannot take a kernel fault >>>>> while processing a hypercall, so hypercall arguments must have been >>>>> faulted in beforehand and that is what the sync_all was for. >>>> That's a good point. (Maybe Xen should have generated pagefaults when >>>> hypercall arg pointers are bad...) >>> I think it would be a bit tricky to do in practice, you'd either have to >>> support recursive hypercalls in the middle of other hypercalls (because >>> the page fault handler is surely going to want to do some) or proper >>> hypercall restart (so you can fully return to guest context to handle >>> the fault then retry) or something along those and complexifying up the >>> hypervisor one way or another. Probably not impossible if you were >>> building something form the ground up, but not trivial. >> Well, Xen already has the continuation machinery for dealing with >> hypercall restart, so that could be reused. > That requires special support beyond just calling the continuation in > each hypercall (often extending into the ABI) for pickling progress and > picking it up again, only a small number of (usually long running) > hypercalls have that support today. It also uses the guest context to > store the state which perhaps isn't helpful if you want to return to the > guest, although I suppose building a nested frame would work. I guess it depends on how many hypercalls do work before touching guest memory, but any hypercall should be like that anyway, or at least be able to wind back work done if a later read EFAULTs. I was vaguely speculating about a scheme on the lines of: 1. In copy_to/from_user, if we touch a bad address, save it in a per-vcpu "bad_guest_addr" 2. when returning to the guest, if the errno is EFAULT and bad_guest_addr is set, then generate a memory fault frame with cr2 = bad_guest_addr, and with the exception return restarting the hypercall Perhaps there should be a EFAULT_RETRY error return to trigger this behaviour, rather than doing it for all EFAULTs, so the faulting behaviour can be added incrementally. Maybe this is a lost cause for x86, but perhaps its worth considering for new ports? > The guys doing paging and sharing etc looked into this and came to the > conclusion that it would be intractably difficult to do this fully -- > hence we now have the ability to sleep in hypercalls, which works > because the pager/sharer is in a different domain/vcpu. Hmm. Were they looking at injecting faults back into the guest, or forwarding "missing page" events off to another domain? >> And accesses to guest >> memory are already special events which must be checked so that EFAULT >> can be returned. If, rather than failing with EFAULT Xen set up a >> pagefault exception for the guest CPU with the return set up to retry >> the hypercall, it should all work... >> >> Of course, if the guest isn't expecting that - or its buggy - then it >> could end up in an infinite loop. But maybe a flag (set a high bit in >> the hypercall number?), or a feature, or something? Might be worthwhile >> if it saves guests having to do something expensive (like a >> vmalloc_sync_all), even if they have to also deal with old hypervisors. > The vmalloc_sync_all is a pretty event even on Xen though, isn't it? Looks like an important word is missing there. But its very expensive, if that's what you're saying. J _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel From xen-devel-bounces@lists.xensource.com Fri Sep 02 13:29:14 2011 Return-path: Envelope-to: www-data@lists.xensource.com Delivery-date: Fri, 02 Sep 2011 13:29:14 -0700 Received: from localhost ([127.0.0.1] helo=lists.colo.xensource.com) by lists.xensource.com with esmtp (Exim 4.43) id 1QzaMU-0008WV-AA; Fri, 02 Sep 2011 13:29:14 -0700 Received: from mail27.messagelabs.com ([193.109.254.147]) by lists.xensource.com with esmtp (Exim 4.43) id 1QzaM2-0008Jx-84 for xen-devel@lists.xensource.com; Fri, 02 Sep 2011 13:28:46 -0700 X-Env-Sender: torvalds@linux-foundation.org X-Msg-Ref: server-5.tower-27.messagelabs.com!1314995304!43295708!1 X-Originating-IP: [140.211.169.13] X-StarScan-Version: 6.3.6; banners=-,-,- X-VirusChecked: Checked Received: (qmail 23860 invoked from network); 2 Sep 2011 20:28:26 -0000 Received: from smtp1.linux-foundation.org (HELO smtp1.linux-foundation.org) (140.211.169.13) by server-5.tower-27.messagelabs.com with DHE-RSA-AES256-SHA encrypted SMTP; 2 Sep 2011 20:28:26 -0000 Received: from mail-ww0-f41.google.com (mail-ww0-f41.google.com [74.125.82.41]) (authenticated bits=0) by smtp1.linux-foundation.org (8.14.2/8.13.5/Debian-3ubuntu1.1) with ESMTP id p82KSAaY024719 (version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=FAIL) for ; Fri, 2 Sep 2011 13:28:11 -0700 Received: by wwj26 with SMTP id 26so2537388wwj.0 for ; Fri, 02 Sep 2011 13:28:08 -0700 (PDT) Received: by 10.216.14.234 with SMTP id d84mr1692279wed.85.1314995288469; Fri, 02 Sep 2011 13:28:08 -0700 (PDT) MIME-Version: 1.0 Received: by 10.216.187.66 with HTTP; Fri, 2 Sep 2011 13:27:44 -0700 (PDT) In-Reply-To: <4E61377B.4020600@goop.org> References: <4E61377B.4020600@goop.org> From: Linus Torvalds Date: Fri, 2 Sep 2011 13:27:44 -0700 Message-ID: To: Jeremy Fitzhardinge Content-Type: text/plain; charset=ISO-8859-1 X-Spam-Status: No, hits=-103.509 required=5 tests=AWL, BAYES_00, OSDL_HEADER_SUBJECT_BRACKETED, USER_IN_WHITELIST X-Spam-Checker-Version: SpamAssassin 3.2.4-osdl_revision__1.47__ X-MIMEDefang-Filter: lf-20110901g X-Scanned-By: MIMEDefang 2.63 on 140.211.169.13 Cc: Marcelo Tosatti , Nick Piggin , KVM , Peter Zijlstra , the arch/x86 maintainers , Linux Kernel Mailing List , Andi Kleen , Avi Kivity , Jeremy Fitzhardinge , "H. Peter Anvin" , Ingo Molnar , Xen Devel Subject: [Xen-devel] Re: [PATCH 00/13] [PATCH RFC] Paravirtualized ticketlocks X-BeenThere: xen-devel@lists.xensource.com X-Mailman-Version: 2.1.5 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xensource.com Errors-To: xen-devel-bounces@lists.xensource.com On Fri, Sep 2, 2011 at 1:07 PM, Jeremy Fitzhardinge wrote: > > I don't know whether that fastpath code is small enough to consider > inlining everywhere? No. There's no point in inlining something that ends up containing a conditional function call: gcc will have to effectively save/restore registers around that thing anyway, so you lose a lot of the advantages of inlining. So I think it's better done as an out-of-line function, which I thought we did for spinlocks anyway. Also, do you run with CONFIG_OPTIMIZE_SIZE? Without that, gcc should be smart enough to make a "likely()" case be a fall-through. Linus _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel From xen-devel-bounces@lists.xensource.com Fri Sep 02 13:49:02 2011 Return-path: Envelope-to: www-data@lists.xensource.com Delivery-date: Fri, 02 Sep 2011 13:49:02 -0700 Received: from localhost ([127.0.0.1] helo=lists.colo.xensource.com) by lists.xensource.com with esmtp (Exim 4.43) id 1Qzafe-0001eu-Ev; Fri, 02 Sep 2011 13:49:02 -0700 Received: from mail216.messagelabs.com ([85.158.143.99]) by lists.xensource.com with esmtp (Exim 4.43) id 1QzafD-0001SK-PZ for xen-devel@lists.xensource.com; Fri, 02 Sep 2011 13:48:36 -0700 X-Env-Sender: peterz@infradead.org X-Msg-Ref: server-2.tower-216.messagelabs.com!1314996512!16878940!1 X-Originating-IP: [85.118.1.10] X-StarScan-Version: 6.3.6; banners=-,-,- X-VirusChecked: Checked Received: (qmail 18293 invoked from network); 2 Sep 2011 20:48:32 -0000 Received: from casper.infradead.org (HELO casper.infradead.org) (85.118.1.10) by server-2.tower-216.messagelabs.com with DHE-RSA-AES256-SHA encrypted SMTP; 2 Sep 2011 20:48:32 -0000 Received: from j77219.upc-j.chello.nl ([24.132.77.219] helo=twins) by casper.infradead.org with esmtpsa (Exim 4.76 #1 (Red Hat Linux)) id 1QzaeY-0007aL-Uz; Fri, 02 Sep 2011 20:47:55 +0000 Received: by twins (Postfix, from userid 1000) id A1715816ED15; Fri, 2 Sep 2011 22:47:48 +0200 (CEST) From: Peter Zijlstra To: Jeremy Fitzhardinge Date: Fri, 02 Sep 2011 22:47:48 +0200 In-Reply-To: <4E612EA1.20007@goop.org> References: <38bb37e15f6e5056d5238adac945bc1837a996ec.1314922370.git.jeremy.fitzhardinge@citrix.com> <1314974826.1861.1.camel@twins> <4E612EA1.20007@goop.org> Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Mailer: Evolution 3.0.2- Message-ID: <1314996468.8255.0.camel@twins> Mime-Version: 1.0 Cc: Xen Devel , Marcelo Tosatti , Nick Piggin , KVM , maintainers , Linux Kernel Mailing List , Andi Kleen , Avi Kivity , Jeremy Fitzhardinge , "H. Peter Anvin" , Ingo Molnar , Linus Torvalds , the Subject: [Xen-devel] Re: [PATCH 08/13] xen/pvticketlock: disable interrupts while blocking X-BeenThere: xen-devel@lists.xensource.com X-Mailman-Version: 2.1.5 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xensource.com Errors-To: xen-devel-bounces@lists.xensource.com On Fri, 2011-09-02 at 12:29 -0700, Jeremy Fitzhardinge wrote: >=20 > > I know that its generally considered bad form, but there's at least one > > spinlock that's only taken from NMI context and thus hasn't got any > > deadlock potential. >=20 > Which one?=20 arch/x86/kernel/traps.c:nmi_reason_lock It serializes NMI access to the NMI reason port across CPUs. _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel From xen-devel-bounces@lists.xensource.com Fri Sep 02 14:43:24 2011 Return-path: Envelope-to: www-data@lists.xensource.com Delivery-date: Fri, 02 Sep 2011 14:43:24 -0700 Received: from localhost ([127.0.0.1] helo=lists.colo.xensource.com) by lists.xensource.com with esmtp (Exim 4.43) id 1QzbWF-0003w3-KI; Fri, 02 Sep 2011 14:43:23 -0700 Received: from mail182.messagelabs.com ([85.158.139.83]) by lists.xensource.com with esmtp (Exim 4.43) id 1QzbVO-0003j6-GL for xen-devel@lists.xensource.com; Fri, 02 Sep 2011 14:42:31 -0700 X-Env-Sender: jeremy@goop.org X-Msg-Ref: server-6.tower-182.messagelabs.com!1314999745!16853143!1 X-Originating-IP: [74.207.240.146] X-StarScan-Version: 6.3.6; banners=-,-,- X-VirusChecked: Checked Received: (qmail 13513 invoked from network); 2 Sep 2011 21:42:27 -0000 Received: from claw.goop.org (HELO claw.goop.org) (74.207.240.146) by server-6.tower-182.messagelabs.com with DHE-RSA-AES256-SHA encrypted SMTP; 2 Sep 2011 21:42:27 -0000 Received: from saboo.goop.org (unknown [IPv6:2001:470:1f05:899:f2de:f1ff:fe5c:34ed]) (Authenticated sender: smtp-saboo) by claw.goop.org (Postfix) with ESMTPSA id 5E2568918; Fri, 2 Sep 2011 14:42:24 -0700 (PDT) Received: from saboo.goop.org (localhost [IPv6:::1]) by saboo.goop.org (Postfix) with ESMTP id 3644020166; Fri, 2 Sep 2011 14:42:21 -0700 (PDT) Message-ID: <4E614DBD.3000504@goop.org> Date: Fri, 02 Sep 2011 14:42:21 -0700 From: Jeremy Fitzhardinge User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:6.0) Gecko/20110816 Thunderbird/6.0 MIME-Version: 1.0 To: Linus Torvalds References: <4E61377B.4020600@goop.org> In-Reply-To: X-Enigmail-Version: 1.3.1 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: Marcelo Tosatti , Nick Piggin , KVM , Peter Zijlstra , the arch/x86 maintainers , Linux Kernel Mailing List , Andi Kleen , Avi Kivity , Jeremy Fitzhardinge , "H. Peter Anvin" , Ingo Molnar , Xen Devel Subject: [Xen-devel] Re: [PATCH 00/13] [PATCH RFC] Paravirtualized ticketlocks X-BeenThere: xen-devel@lists.xensource.com X-Mailman-Version: 2.1.5 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xensource.com Errors-To: xen-devel-bounces@lists.xensource.com On 09/02/2011 01:27 PM, Linus Torvalds wrote: > On Fri, Sep 2, 2011 at 1:07 PM, Jeremy Fitzhardinge wrote: >> I don't know whether that fastpath code is small enough to consider >> inlining everywhere? > No. > > There's no point in inlining something that ends up containing a > conditional function call: gcc will have to effectively save/restore > registers around that thing anyway, so you lose a lot of the > advantages of inlining. So I think it's better done as an out-of-line > function, which I thought we did for spinlocks anyway. Yes, lock currently out-of-line. I should also make sure that unlock is also out of line when paravirtualized. > Also, do you run with CONFIG_OPTIMIZE_SIZE? Without that, gcc should > be smart enough to make a "likely()" case be a fall-through. Ah, I was wondering why I'd never seen likely/unlikely do anything useful. With OPTIMIZE_SIZE=n, there's no point in explicitly moving the slowpath out to a separate function. So the only downside with this variant is that it breaks my design criteria of making the generated code look identical to the the original code when CONFIG_PARAVIRT_SPINLOCKS=n. But I don't know if that's an actual downside in practice. J _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel From xen-devel-bounces@lists.xensource.com Fri Sep 02 14:51:38 2011 Return-path: Envelope-to: www-data@lists.xensource.com Delivery-date: Fri, 02 Sep 2011 14:51:38 -0700 Received: from localhost ([127.0.0.1] helo=lists.colo.xensource.com) by lists.xensource.com with esmtp (Exim 4.43) id 1QzbeE-0004SM-QG; Fri, 02 Sep 2011 14:51:38 -0700 Received: from mail27.messagelabs.com ([193.109.254.147]) by lists.xensource.com with esmtp (Exim 4.43) id 1Qzbdd-0004Fo-VH for xen-devel@lists.xensource.com; Fri, 02 Sep 2011 14:51:02 -0700 X-Env-Sender: jeremy@goop.org X-Msg-Ref: server-3.tower-27.messagelabs.com!1315000237!38086324!1 X-Originating-IP: [74.207.240.146] X-StarScan-Version: 6.3.6; banners=-,-,- X-VirusChecked: Checked Received: (qmail 29210 invoked from network); 2 Sep 2011 21:50:38 -0000 Received: from claw.goop.org (HELO claw.goop.org) (74.207.240.146) by server-3.tower-27.messagelabs.com with DHE-RSA-AES256-SHA encrypted SMTP; 2 Sep 2011 21:50:38 -0000 Received: from saboo.goop.org (unknown [IPv6:2001:470:1f05:899:f2de:f1ff:fe5c:34ed]) (Authenticated sender: smtp-saboo) by claw.goop.org (Postfix) with ESMTPSA id F0DC789B2; Fri, 2 Sep 2011 14:50:55 -0700 (PDT) Received: from saboo.goop.org (localhost [IPv6:::1]) by saboo.goop.org (Postfix) with ESMTP id DD0F620166; Fri, 2 Sep 2011 14:50:53 -0700 (PDT) Message-ID: <4E614FBD.2030509@goop.org> Date: Fri, 02 Sep 2011 14:50:53 -0700 From: Jeremy Fitzhardinge User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:6.0) Gecko/20110816 Thunderbird/6.0 MIME-Version: 1.0 To: Peter Zijlstra References: <38bb37e15f6e5056d5238adac945bc1837a996ec.1314922370.git.jeremy.fitzhardinge@citrix.com> <1314974826.1861.1.camel@twins> <4E612EA1.20007@goop.org> <1314996468.8255.0.camel@twins> In-Reply-To: <1314996468.8255.0.camel@twins> X-Enigmail-Version: 1.3.1 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Cc: Marcelo Tosatti , Nick Piggin , KVM , Stefano Stabellini , the arch/x86 maintainers , Linux Kernel Mailing List , Andi Kleen , Avi Kivity , Jeremy Fitzhardinge , "H. Peter Anvin" , Ingo Molnar , Linus Torvalds , Xen Devel Subject: [Xen-devel] Re: [PATCH 08/13] xen/pvticketlock: disable interrupts while blocking X-BeenThere: xen-devel@lists.xensource.com X-Mailman-Version: 2.1.5 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xensource.com Errors-To: xen-devel-bounces@lists.xensource.com On 09/02/2011 01:47 PM, Peter Zijlstra wrote: > On Fri, 2011-09-02 at 12:29 -0700, Jeremy Fitzhardinge wrote: >>> I know that its generally considered bad form, but there's at least one >>> spinlock that's only taken from NMI context and thus hasn't got any >>> deadlock potential. >> Which one? > arch/x86/kernel/traps.c:nmi_reason_lock > > It serializes NMI access to the NMI reason port across CPUs. Ah, OK. Well, that will never happen in a PV Xen guest. But PV ticketlocks are equally applicable to an HVM Xen domain (and KVM guest), so I guess there's at least some chance there could be a virtual emulated NMI. Maybe? Does qemu do that kind of thing? But, erm, does that even make sense? I'm assuming the NMI reason port tells the CPU why it got an NMI. If multiple CPUs can get NMIs and there's only a single reason port, then doesn't that mean that either 1) they all got the NMI for the same reason, or 2) having a single port is inherently racy? How does the locking actually work there? J _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel From xen-devel-bounces@lists.xensource.com Fri Sep 02 15:33:19 2011 Return-path: Envelope-to: www-data@lists.xensource.com Delivery-date: Fri, 02 Sep 2011 15:33:19 -0700 Received: from localhost ([127.0.0.1] helo=lists.colo.xensource.com) by lists.xensource.com with esmtp (Exim 4.43) id 1QzcIZ-0005Sn-9X; Fri, 02 Sep 2011 15:33:19 -0700 Received: from mail27.messagelabs.com ([193.109.254.147]) by lists.xensource.com with esmtp (Exim 4.43) id 1QzcHe-0005Fu-4A for xen-devel@lists.xensource.com; Fri, 02 Sep 2011 15:32:22 -0700 X-Env-Sender: akpm@linux-foundation.org X-Msg-Ref: server-3.tower-27.messagelabs.com!1315002717!38087955!1 X-Originating-IP: [140.211.169.13] X-StarScan-Version: 6.3.6; banners=-,-,- X-VirusChecked: Checked Received: (qmail 27540 invoked from network); 2 Sep 2011 22:31:58 -0000 Received: from smtp1.linux-foundation.org (HELO smtp1.linux-foundation.org) (140.211.169.13) by server-3.tower-27.messagelabs.com with DHE-RSA-AES256-SHA encrypted SMTP; 2 Sep 2011 22:31:58 -0000 Received: from imap1.linux-foundation.org (imap1.linux-foundation.org [140.211.169.55]) by smtp1.linux-foundation.org (8.14.2/8.13.5/Debian-3ubuntu1.1) with ESMTP id p82MW6cc019425 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 2 Sep 2011 15:32:06 -0700 Received: from akpm.mtv.corp.google.com (localhost [127.0.0.1]) by imap1.linux-foundation.org (8.13.5.20060308/8.13.5/Debian-3ubuntu1.1) with SMTP id p82MW5wF014409; Fri, 2 Sep 2011 15:32:05 -0700 Date: Fri, 2 Sep 2011 15:32:04 -0700 From: Andrew Morton To: David Vrabel Message-Id: <20110902153204.59a928c1.akpm@linux-foundation.org> In-Reply-To: <4E60C067.4010600@citrix.com> References: <1314877863-21977-1-git-send-email-david.vrabel@citrix.com> <20110901161134.GA8979@dumpdata.com> <4E5FED1A.1000300@goop.org> <20110901141754.76cef93b.akpm@linux-foundation.org> <4E60C067.4010600@citrix.com> X-Mailer: Sylpheed 3.0.2 (GTK+ 2.20.1; x86_64-pc-linux-gnu) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-Scanned-By: MIMEDefang 2.63 on 140.211.169.13 Cc: Jeremy Fitzhardinge , "xen-devel@lists.xensource.com" , Konrad Rzeszutek Wilk , "namhyung@gmail.com" , "linux-kernel@vger.kernel.org" , "linux-mm@kvack.org" , "rientjes@google.com" , "paulmck@linux.vnet.ibm.com" Subject: [Xen-devel] Re: [Revert] Re: [PATCH] mm: sync vmalloc address space page tables in alloc_vm_area() X-BeenThere: xen-devel@lists.xensource.com X-Mailman-Version: 2.1.5 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xensource.com Errors-To: xen-devel-bounces@lists.xensource.com On Fri, 2 Sep 2011 12:39:19 +0100 David Vrabel wrote: > Xen backend drivers (e.g., blkback and netback) would sometimes fail > to map grant pages into the vmalloc address space allocated with > alloc_vm_area(). The GNTTABOP_map_grant_ref would fail because Xen > could not find the page (in the L2 table) containing the PTEs it > needed to update. > > (XEN) mm.c:3846:d0 Could not find L1 PTE for address fbb42000 > > netback and blkback were making the hypercall from a kernel thread > where task->active_mm != &init_mm and alloc_vm_area() was only > updating the page tables for init_mm. The usual method of deferring > the update to the page tables of other processes (i.e., after taking a > fault) doesn't work as a fault cannot occur during the hypercall. > > This would work on some systems depending on what else was using > vmalloc. > > Fix this by reverting ef691947d8a3d479e67652312783aedcf629320a > (vmalloc: remove vmalloc_sync_all() from alloc_vm_area()) and add a > comment to explain why it's needed. oookay, I queued this for 3.1 and tagged it for a 3.0.x backport. I *think* that's the outcome of this discussion, for the short-term? _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel From xen-devel-bounces@lists.xensource.com Fri Sep 02 15:41:38 2011 Return-path: Envelope-to: www-data@lists.xensource.com Delivery-date: Fri, 02 Sep 2011 15:41:38 -0700 Received: from localhost ([127.0.0.1] helo=lists.colo.xensource.com) by lists.xensource.com with esmtp (Exim 4.43) id 1QzcQb-00060z-VT; Fri, 02 Sep 2011 15:41:38 -0700 Received: from mail21.messagelabs.com ([85.158.143.35]) by lists.xensource.com with esmtp (Exim 4.43) id 1QzcQ1-0005oL-8T for xen-devel@lists.xensource.com; Fri, 02 Sep 2011 15:41:01 -0700 X-Env-Sender: peterz@infradead.org X-Msg-Ref: server-3.tower-21.messagelabs.com!1315003269!50136845!1 X-Originating-IP: [205.233.59.134] X-StarScan-Version: 6.3.6; banners=-,-,- X-VirusChecked: Checked Received: (qmail 31021 invoked from network); 2 Sep 2011 22:41:09 -0000 Received: from merlin.infradead.org (HELO merlin.infradead.org) (205.233.59.134) by server-3.tower-21.messagelabs.com with DHE-RSA-AES256-SHA encrypted SMTP; 2 Sep 2011 22:41:09 -0000 Received: from canuck.infradead.org ([2001:4978:20e::1]) by merlin.infradead.org with esmtps (Exim 4.76 #1 (Red Hat Linux)) id 1QzcMO-0002pl-WF; Fri, 02 Sep 2011 22:37:17 +0000 Received: from j77219.upc-j.chello.nl ([24.132.77.219] helo=twins) by canuck.infradead.org with esmtpsa (Exim 4.76 #1 (Red Hat Linux)) id 1QzcMO-0004UK-FA; Fri, 02 Sep 2011 22:37:16 +0000 Received: by twins (Postfix, from userid 1000) id E9F618181C60; Sat, 3 Sep 2011 00:37:07 +0200 (CEST) From: Peter Zijlstra To: Jeremy Fitzhardinge Date: Sat, 03 Sep 2011 00:37:07 +0200 In-Reply-To: <4E614FBD.2030509@goop.org> References: <38bb37e15f6e5056d5238adac945bc1837a996ec.1314922370.git.jeremy.fitzhardinge@citrix.com> <1314974826.1861.1.camel@twins> <4E612EA1.20007@goop.org> <1314996468.8255.0.camel@twins> <4E614FBD.2030509@goop.org> Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Mailer: Evolution 3.0.2- Message-ID: <1315003027.10110.2.camel@twins> Mime-Version: 1.0 Cc: Xen Devel , Marcelo Tosatti , Nick Piggin , KVM , Stefano Stabellini , maintainers , Linux Kernel Mailing List , Andi Kleen , Avi Kivity , Jeremy Fitzhardinge , "H. Peter Anvin" , Ingo Molnar , Linus Torvalds , the Subject: [Xen-devel] Re: [PATCH 08/13] xen/pvticketlock: disable interrupts while blocking X-BeenThere: xen-devel@lists.xensource.com X-Mailman-Version: 2.1.5 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xensource.com Errors-To: xen-devel-bounces@lists.xensource.com On Fri, 2011-09-02 at 14:50 -0700, Jeremy Fitzhardinge wrote: > On 09/02/2011 01:47 PM, Peter Zijlstra wrote: > > On Fri, 2011-09-02 at 12:29 -0700, Jeremy Fitzhardinge wrote: > >>> I know that its generally considered bad form, but there's at least o= ne > >>> spinlock that's only taken from NMI context and thus hasn't got any > >>> deadlock potential. > >> Which one?=20 > > arch/x86/kernel/traps.c:nmi_reason_lock > > > > It serializes NMI access to the NMI reason port across CPUs. >=20 > Ah, OK. Well, that will never happen in a PV Xen guest. But PV > ticketlocks are equally applicable to an HVM Xen domain (and KVM guest), > so I guess there's at least some chance there could be a virtual > emulated NMI. Maybe? Does qemu do that kind of thing? Afaik qemu/kvm can do the whole NMI thing, yes. > But, erm, does that even make sense? I'm assuming the NMI reason port > tells the CPU why it got an NMI. If multiple CPUs can get NMIs and > there's only a single reason port, then doesn't that mean that either 1) > they all got the NMI for the same reason, or 2) having a single port is > inherently racy? How does the locking actually work there? I really wouldn't know, the whole NMI thing is a bit of a trainwreck architecturally. Maybe the x86 maintainers or Linus knows more on this aspect of it. _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel From xen-devel-bounces@lists.xensource.com Fri Sep 02 16:05:28 2011 Return-path: Envelope-to: www-data@lists.xensource.com Delivery-date: Fri, 02 Sep 2011 16:05:28 -0700 Received: from localhost ([127.0.0.1] helo=lists.colo.xensource.com) by lists.xensource.com with esmtp (Exim 4.43) id 1Qzcnf-0006zi-Lf; Fri, 02 Sep 2011 16:05:28 -0700 Received: from mail21.messagelabs.com ([85.158.143.35]) by lists.xensource.com with esmtp (Exim 4.43) id 1Qzcmh-0006mo-4b for xen-devel@lists.xensource.com; Fri, 02 Sep 2011 16:04:28 -0700 X-Env-Sender: jeremy@goop.org X-Msg-Ref: server-3.tower-21.messagelabs.com!1315004674!50137698!1 X-Originating-IP: [74.207.240.146] X-StarScan-Version: 6.3.6; banners=-,-,- X-VirusChecked: Checked Received: (qmail 15125 invoked from network); 2 Sep 2011 23:04:35 -0000 Received: from claw.goop.org (HELO claw.goop.org) (74.207.240.146) by server-3.tower-21.messagelabs.com with DHE-RSA-AES256-SHA encrypted SMTP; 2 Sep 2011 23:04:35 -0000 Received: from saboo.goop.org (unknown [IPv6:2001:470:1f05:899:f2de:f1ff:fe5c:34ed]) (Authenticated sender: smtp-saboo) by claw.goop.org (Postfix) with ESMTPSA id 911EF8807; Fri, 2 Sep 2011 16:04:21 -0700 (PDT) Received: from saboo.goop.org (localhost [IPv6:::1]) by saboo.goop.org (Postfix) with ESMTP id 70B2D20166; Fri, 2 Sep 2011 16:04:19 -0700 (PDT) Message-ID: <4E6160F3.8030708@goop.org> Date: Fri, 02 Sep 2011 16:04:19 -0700 From: Jeremy Fitzhardinge User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:6.0) Gecko/20110816 Thunderbird/6.0 MIME-Version: 1.0 To: Andrew Morton References: <1314877863-21977-1-git-send-email-david.vrabel@citrix.com> <20110901161134.GA8979@dumpdata.com> <4E5FED1A.1000300@goop.org> <20110901141754.76cef93b.akpm@linux-foundation.org> <4E60C067.4010600@citrix.com> <20110902153204.59a928c1.akpm@linux-foundation.org> In-Reply-To: <20110902153204.59a928c1.akpm@linux-foundation.org> X-Enigmail-Version: 1.3.1 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: "xen-devel@lists.xensource.com" , Konrad Rzeszutek Wilk , "namhyung@gmail.com" , "linux-kernel@vger.kernel.org" , "linux-mm@kvack.org" , David Vrabel , "rientjes@google.com" , "paulmck@linux.vnet.ibm.com" Subject: [Xen-devel] Re: [Revert] Re: [PATCH] mm: sync vmalloc address space page tables in alloc_vm_area() X-BeenThere: xen-devel@lists.xensource.com X-Mailman-Version: 2.1.5 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xensource.com Errors-To: xen-devel-bounces@lists.xensource.com On 09/02/2011 03:32 PM, Andrew Morton wrote: > On Fri, 2 Sep 2011 12:39:19 +0100 > David Vrabel wrote: > >> Xen backend drivers (e.g., blkback and netback) would sometimes fail >> to map grant pages into the vmalloc address space allocated with >> alloc_vm_area(). The GNTTABOP_map_grant_ref would fail because Xen >> could not find the page (in the L2 table) containing the PTEs it >> needed to update. >> >> (XEN) mm.c:3846:d0 Could not find L1 PTE for address fbb42000 >> >> netback and blkback were making the hypercall from a kernel thread >> where task->active_mm != &init_mm and alloc_vm_area() was only >> updating the page tables for init_mm. The usual method of deferring >> the update to the page tables of other processes (i.e., after taking a >> fault) doesn't work as a fault cannot occur during the hypercall. >> >> This would work on some systems depending on what else was using >> vmalloc. >> >> Fix this by reverting ef691947d8a3d479e67652312783aedcf629320a >> (vmalloc: remove vmalloc_sync_all() from alloc_vm_area()) and add a >> comment to explain why it's needed. > oookay, I queued this for 3.1 and tagged it for a 3.0.x backport. I > *think* that's the outcome of this discussion, for the short-term? Sure, that will get things going for now. Thanks, J _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel From xen-devel-bounces@lists.xensource.com Fri Sep 02 16:15:53 2011 Return-path: Envelope-to: www-data@lists.xensource.com Delivery-date: Fri, 02 Sep 2011 16:15:53 -0700 Received: from localhost ([127.0.0.1] helo=lists.colo.xensource.com) by lists.xensource.com with esmtp (Exim 4.43) id 1Qzcxl-0007VD-3p; Fri, 02 Sep 2011 16:15:53 -0700 Received: from mail174.messagelabs.com ([85.158.138.51]) by lists.xensource.com with esmtp (Exim 4.43) id 1Qzcwt-0007II-7B for xen-devel@lists.xensource.com; Fri, 02 Sep 2011 16:14:59 -0700 X-Env-Sender: andi@firstfloor.org X-Msg-Ref: server-10.tower-174.messagelabs.com!1315005295!30064362!1 X-Originating-IP: [213.235.205.2] X-StarScan-Version: 6.3.6; banners=-,-,- X-VirusChecked: Checked Received: (qmail 2935 invoked from network); 2 Sep 2011 23:14:56 -0000 Received: from one.firstfloor.org (HELO one.firstfloor.org) (213.235.205.2) by server-10.tower-174.messagelabs.com with DHE-RSA-AES256-SHA encrypted SMTP; 2 Sep 2011 23:14:56 -0000 Received: by one.firstfloor.org (Postfix, from userid 48) id 25BA71ED80AD; Sat, 3 Sep 2011 01:14:55 +0200 (CEST) Received: from 71.214.95.187 (SquirrelMail authenticated user andi) by www.firstfloor.org with HTTP; Sat, 3 Sep 2011 01:14:55 +0200 Message-ID: In-Reply-To: <4E614FBD.2030509@goop.org> References: <38bb37e15f6e5056d5238adac945bc1837a996ec.1314922370.git.jeremy.fitzhardinge@citrix.com> <1314974826.1861.1.camel@twins> <4E612EA1.20007@goop.org> <1314996468.8255.0.camel@twins> <4E614FBD.2030509@goop.org> Date: Sat, 3 Sep 2011 01:14:55 +0200 From: "Andi Kleen" To: "Jeremy Fitzhardinge" User-Agent: SquirrelMail/1.4.21 MIME-Version: 1.0 Content-Type: text/plain;charset=iso-8859-1 Content-Transfer-Encoding: 8bit X-Priority: 3 (Normal) Importance: Normal Cc: Marcelo Tosatti , Nick Piggin , KVM , Stefano Stabellini , Peter Zijlstra , the arch/x86 maintainers , Linux Kernel Mailing List , Andi Kleen , Avi Kivity , Jeremy Fitzhardinge , "H. Peter Anvin" , Ingo Molnar , Linus Torvalds , Xen Devel Subject: [Xen-devel] Re: [PATCH 08/13] xen/pvticketlock: disable interrupts while blocking X-BeenThere: xen-devel@lists.xensource.com X-Mailman-Version: 2.1.5 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xensource.com Errors-To: xen-devel-bounces@lists.xensource.com > But, erm, does that even make sense? I'm assuming the NMI reason port > tells the CPU why it got an NMI. If multiple CPUs can get NMIs and > there's only a single reason port, then doesn't that mean that either 1) > they all got the NMI for the same reason, or 2) having a single port is > inherently racy? How does the locking actually work there? All the code to determine NMI reasons is inherently racy, and each new NMI user makes it worse. -Andi _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel From xen-devel-bounces@lists.xensource.com Fri Sep 02 16:55:19 2011 Return-path: Envelope-to: www-data@lists.xensource.com Delivery-date: Fri, 02 Sep 2011 16:55:19 -0700 Received: from localhost ([127.0.0.1] helo=lists.colo.xensource.com) by lists.xensource.com with esmtp (Exim 4.43) id 1QzdZu-0000xS-AJ; Fri, 02 Sep 2011 16:55:18 -0700 Received: from mail182.messagelabs.com ([85.158.139.83]) by lists.xensource.com with esmtp (Exim 4.43) id 1QzdZ4-0000jw-Id for xen-devel@lists.xensource.com; Fri, 02 Sep 2011 16:54:26 -0700 X-Env-Sender: jeremy@goop.org X-Msg-Ref: server-13.tower-182.messagelabs.com!1315007661!16713779!1 X-Originating-IP: [74.207.240.146] X-StarScan-Version: 6.3.6; banners=-,-,- X-VirusChecked: Checked Received: (qmail 8914 invoked from network); 2 Sep 2011 23:54:23 -0000 Received: from claw.goop.org (HELO claw.goop.org) (74.207.240.146) by server-13.tower-182.messagelabs.com with DHE-RSA-AES256-SHA encrypted SMTP; 2 Sep 2011 23:54:23 -0000 Received: from saboo.goop.org (unknown [IPv6:2001:470:1f05:899:f2de:f1ff:fe5c:34ed]) (Authenticated sender: smtp-saboo) by claw.goop.org (Postfix) with ESMTPSA id A81AD8AB5; Fri, 2 Sep 2011 16:54:20 -0700 (PDT) Received: by saboo.goop.org (Postfix, from userid 500) id 582A0204BD; Fri, 2 Sep 2011 16:54:17 -0700 (PDT) From: Jeremy Fitzhardinge To: "H. Peter Anvin" Date: Fri, 2 Sep 2011 16:54:09 -0700 Message-Id: X-Mailer: git-send-email 1.7.6 In-Reply-To: References: In-Reply-To: References: Cc: Marcelo Tosatti , Nick Piggin , KVM , Peter Zijlstra , the arch/x86 maintainers , Linux Kernel Mailing List , Andi Kleen , Avi Kivity , Jeremy Fitzhardinge , Ingo Molnar , Linus Torvalds , Xen Devel Subject: [Xen-devel] [PATCH 2/8] x86/ticketlock: don't inline _spin_unlock when using paravirt spinlocks X-BeenThere: xen-devel@lists.xensource.com X-Mailman-Version: 2.1.5 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xensource.com Errors-To: xen-devel-bounces@lists.xensource.com From: Jeremy Fitzhardinge The code size expands somewhat, and its probably better to just call a function rather than inline it. Signed-off-by: Jeremy Fitzhardinge --- arch/x86/Kconfig | 3 +++ kernel/Kconfig.locks | 2 +- 2 files changed, 4 insertions(+), 1 deletions(-) diff --git a/arch/x86/Kconfig b/arch/x86/Kconfig index 6a47bb2..1f03f82 100644 --- a/arch/x86/Kconfig +++ b/arch/x86/Kconfig @@ -585,6 +585,9 @@ config PARAVIRT_SPINLOCKS If you are unsure how to answer this question, answer N. +config ARCH_NOINLINE_SPIN_UNLOCK + def_bool PARAVIRT_SPINLOCKS + config PARAVIRT_CLOCK bool diff --git a/kernel/Kconfig.locks b/kernel/Kconfig.locks index 5068e2a..584637b 100644 --- a/kernel/Kconfig.locks +++ b/kernel/Kconfig.locks @@ -125,7 +125,7 @@ config INLINE_SPIN_LOCK_IRQSAVE ARCH_INLINE_SPIN_LOCK_IRQSAVE config INLINE_SPIN_UNLOCK - def_bool !DEBUG_SPINLOCK && (!PREEMPT || ARCH_INLINE_SPIN_UNLOCK) + def_bool !DEBUG_SPINLOCK && (!PREEMPT || ARCH_INLINE_SPIN_UNLOCK) && !ARCH_NOINLINE_SPIN_UNLOCK config INLINE_SPIN_UNLOCK_BH def_bool !DEBUG_SPINLOCK && ARCH_INLINE_SPIN_UNLOCK_BH -- 1.7.6 _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel From xen-devel-bounces@lists.xensource.com Fri Sep 02 16:56:19 2011 Return-path: Envelope-to: www-data@lists.xensource.com Delivery-date: Fri, 02 Sep 2011 16:56:19 -0700 Received: from localhost ([127.0.0.1] helo=lists.colo.xensource.com) by lists.xensource.com with esmtp (Exim 4.43) id 1Qzdat-0001KZ-J4; Fri, 02 Sep 2011 16:56:19 -0700 Received: from mail216.messagelabs.com ([85.158.143.99]) by lists.xensource.com with esmtp (Exim 4.43) id 1QzdZ5-0000jx-SS for xen-devel@lists.xensource.com; Fri, 02 Sep 2011 16:54:28 -0700 X-Env-Sender: jeremy@goop.org X-Msg-Ref: server-10.tower-216.messagelabs.com!1315007662!8822334!1 X-Originating-IP: [74.207.240.146] X-StarScan-Version: 6.3.6; banners=-,-,- X-VirusChecked: Checked Received: (qmail 30875 invoked from network); 2 Sep 2011 23:54:24 -0000 Received: from claw.goop.org (HELO claw.goop.org) (74.207.240.146) by server-10.tower-216.messagelabs.com with DHE-RSA-AES256-SHA encrypted SMTP; 2 Sep 2011 23:54:24 -0000 Received: from saboo.goop.org (unknown [IPv6:2001:470:1f05:899:f2de:f1ff:fe5c:34ed]) (Authenticated sender: smtp-saboo) by claw.goop.org (Postfix) with ESMTPSA id AE4D18AB7; Fri, 2 Sep 2011 16:54:20 -0700 (PDT) Received: by saboo.goop.org (Postfix, from userid 500) id 62B8620505; Fri, 2 Sep 2011 16:54:17 -0700 (PDT) From: Jeremy Fitzhardinge To: "H. Peter Anvin" Date: Fri, 2 Sep 2011 16:54:10 -0700 Message-Id: X-Mailer: git-send-email 1.7.6 In-Reply-To: References: In-Reply-To: References: Cc: Marcelo Tosatti , Nick Piggin , KVM , Peter Zijlstra , the arch/x86 maintainers , Linux Kernel Mailing List , Andi Kleen , Avi Kivity , Jeremy Fitzhardinge , Ingo Molnar , Linus Torvalds , Xen Devel Subject: [Xen-devel] [PATCH 3/8] x86/ticketlock: collapse a layer of functions X-BeenThere: xen-devel@lists.xensource.com X-Mailman-Version: 2.1.5 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xensource.com Errors-To: xen-devel-bounces@lists.xensource.com From: Jeremy Fitzhardinge Now that the paravirtualization layer doesn't exist at the spinlock level any more, we can collapse the __ticket_ functions into the arch_ functions. Signed-off-by: Jeremy Fitzhardinge --- arch/x86/include/asm/spinlock.h | 35 +++++------------------------------ 1 files changed, 5 insertions(+), 30 deletions(-) diff --git a/arch/x86/include/asm/spinlock.h b/arch/x86/include/asm/spinlock.h index bafed3b..d1a3970 100644 --- a/arch/x86/include/asm/spinlock.h +++ b/arch/x86/include/asm/spinlock.h @@ -80,7 +80,7 @@ static __always_inline void __ticket_unlock_kick(struct arch_spinlock *lock, __t * save some instructions and make the code more elegant. There really isn't * much between them in performance though, especially as locks are out of line. */ -static __always_inline void __ticket_spin_lock(struct arch_spinlock *lock) +static __always_inline void arch_spin_lock(struct arch_spinlock *lock) { register struct __raw_tickets inc = { .tail = 1 }; @@ -100,7 +100,7 @@ static __always_inline void __ticket_spin_lock(struct arch_spinlock *lock) out: barrier(); /* make sure nothing creeps before the lock is taken */ } -static __always_inline int __ticket_spin_trylock(arch_spinlock_t *lock) +static __always_inline int arch_spin_trylock(arch_spinlock_t *lock) { arch_spinlock_t old, new; @@ -132,7 +132,7 @@ static __always_inline void __ticket_unlock_release(arch_spinlock_t *lock) } #endif -static __always_inline void __ticket_spin_unlock(arch_spinlock_t *lock) +static __always_inline void arch_spin_unlock(arch_spinlock_t *lock) { __ticket_t next = lock->tickets.head + 1; @@ -140,46 +140,21 @@ static __always_inline void __ticket_spin_unlock(arch_spinlock_t *lock) __ticket_unlock_kick(lock, next); } -static inline int __ticket_spin_is_locked(arch_spinlock_t *lock) +static inline int arch_spin_is_locked(arch_spinlock_t *lock) { struct __raw_tickets tmp = ACCESS_ONCE(lock->tickets); return !!(tmp.tail ^ tmp.head); } -static inline int __ticket_spin_is_contended(arch_spinlock_t *lock) +static inline int arch_spin_is_contended(arch_spinlock_t *lock) { struct __raw_tickets tmp = ACCESS_ONCE(lock->tickets); return ((tmp.tail - tmp.head) & TICKET_MASK) > 1; } - -static inline int arch_spin_is_locked(arch_spinlock_t *lock) -{ - return __ticket_spin_is_locked(lock); -} - -static inline int arch_spin_is_contended(arch_spinlock_t *lock) -{ - return __ticket_spin_is_contended(lock); -} #define arch_spin_is_contended arch_spin_is_contended -static __always_inline void arch_spin_lock(arch_spinlock_t *lock) -{ - __ticket_spin_lock(lock); -} - -static __always_inline int arch_spin_trylock(arch_spinlock_t *lock) -{ - return __ticket_spin_trylock(lock); -} - -static __always_inline void arch_spin_unlock(arch_spinlock_t *lock) -{ - __ticket_spin_unlock(lock); -} - static __always_inline void arch_spin_lock_flags(arch_spinlock_t *lock, unsigned long flags) { -- 1.7.6 _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel From xen-devel-bounces@lists.xensource.com Fri Sep 02 16:57:17 2011 Return-path: Envelope-to: www-data@lists.xensource.com Delivery-date: Fri, 02 Sep 2011 16:57:17 -0700 Received: from localhost ([127.0.0.1] helo=lists.colo.xensource.com) by lists.xensource.com with esmtp (Exim 4.43) id 1Qzdbp-0001jI-JI; Fri, 02 Sep 2011 16:57:17 -0700 Received: from mail27.messagelabs.com ([193.109.254.147]) by lists.xensource.com with esmtp (Exim 4.43) id 1QzdZ7-0000jz-5m for xen-devel@lists.xensource.com; Fri, 02 Sep 2011 16:54:30 -0700 X-Env-Sender: jeremy@goop.org X-Msg-Ref: server-15.tower-27.messagelabs.com!1315007657!47198369!1 X-Originating-IP: [74.207.240.146] X-StarScan-Version: 6.3.6; banners=-,-,- X-VirusChecked: Checked Received: (qmail 8546 invoked from network); 2 Sep 2011 23:54:19 -0000 Received: from claw.goop.org (HELO claw.goop.org) (74.207.240.146) by server-15.tower-27.messagelabs.com with DHE-RSA-AES256-SHA encrypted SMTP; 2 Sep 2011 23:54:19 -0000 Received: from saboo.goop.org (unknown [IPv6:2001:470:1f05:899:f2de:f1ff:fe5c:34ed]) (Authenticated sender: smtp-saboo) by claw.goop.org (Postfix) with ESMTPSA id A6EEF8AB3; Fri, 2 Sep 2011 16:54:20 -0700 (PDT) Received: by saboo.goop.org (Postfix, from userid 500) id 6A85D2052D; Fri, 2 Sep 2011 16:54:17 -0700 (PDT) From: Jeremy Fitzhardinge To: "H. Peter Anvin" Date: Fri, 2 Sep 2011 16:54:11 -0700 Message-Id: <00ad0e6f2f2a9d6c258a80a584acda6a97f53705.1315007226.git.jeremy.fitzhardinge@citrix.com> X-Mailer: git-send-email 1.7.6 In-Reply-To: References: In-Reply-To: References: Cc: Marcelo Tosatti , Nick Piggin , KVM , Peter Zijlstra , the arch/x86 maintainers , Linux Kernel Mailing List , Andi Kleen , Avi Kivity , Jeremy Fitzhardinge , Ingo Molnar , Linus Torvalds , Xen Devel Subject: [Xen-devel] [PATCH 4/8] xen/pvticketlock: Xen implementation for PV ticket locks X-BeenThere: xen-devel@lists.xensource.com X-Mailman-Version: 2.1.5 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xensource.com Errors-To: xen-devel-bounces@lists.xensource.com From: Jeremy Fitzhardinge Replace the old Xen implementation of PV spinlocks with and implementation of xen_lock_spinning and xen_unlock_kick. xen_lock_spinning simply registers the cpu in its entry in lock_waiting, adds itself to the waiting_cpus set, and blocks on an event channel until the channel becomes pending. xen_unlock_kick searches the cpus in waiting_cpus looking for the one which next wants this lock with the next ticket, if any. If found, it kicks it by making its event channel pending, which wakes it up. We need to make sure interrupts are disabled while we're relying on the contents of the per-cpu lock_waiting values, otherwise an interrupt handler could come in, try to take some other lock, block, and overwrite our values. Signed-off-by: Jeremy Fitzhardinge --- arch/x86/xen/spinlock.c | 287 +++++++---------------------------------------- 1 files changed, 43 insertions(+), 244 deletions(-) diff --git a/arch/x86/xen/spinlock.c b/arch/x86/xen/spinlock.c index 23af06a..f6133c5 100644 --- a/arch/x86/xen/spinlock.c +++ b/arch/x86/xen/spinlock.c @@ -19,32 +19,21 @@ #ifdef CONFIG_XEN_DEBUG_FS static struct xen_spinlock_stats { - u64 taken; u32 taken_slow; - u32 taken_slow_nested; u32 taken_slow_pickup; u32 taken_slow_spurious; - u32 taken_slow_irqenable; - u64 released; u32 released_slow; u32 released_slow_kicked; #define HISTO_BUCKETS 30 - u32 histo_spin_total[HISTO_BUCKETS+1]; - u32 histo_spin_spinning[HISTO_BUCKETS+1]; u32 histo_spin_blocked[HISTO_BUCKETS+1]; - u64 time_total; - u64 time_spinning; u64 time_blocked; } spinlock_stats; static u8 zero_stats; -static unsigned lock_timeout = 1 << 10; -#define TIMEOUT lock_timeout - static inline void check_zero(void) { if (unlikely(zero_stats)) { @@ -73,22 +62,6 @@ static void __spin_time_accum(u64 delta, u32 *array) array[HISTO_BUCKETS]++; } -static inline void spin_time_accum_spinning(u64 start) -{ - u32 delta = xen_clocksource_read() - start; - - __spin_time_accum(delta, spinlock_stats.histo_spin_spinning); - spinlock_stats.time_spinning += delta; -} - -static inline void spin_time_accum_total(u64 start) -{ - u32 delta = xen_clocksource_read() - start; - - __spin_time_accum(delta, spinlock_stats.histo_spin_total); - spinlock_stats.time_total += delta; -} - static inline void spin_time_accum_blocked(u64 start) { u32 delta = xen_clocksource_read() - start; @@ -105,214 +78,84 @@ static inline u64 spin_time_start(void) return 0; } -static inline void spin_time_accum_total(u64 start) -{ -} -static inline void spin_time_accum_spinning(u64 start) -{ -} static inline void spin_time_accum_blocked(u64 start) { } #endif /* CONFIG_XEN_DEBUG_FS */ -struct xen_spinlock { - unsigned char lock; /* 0 -> free; 1 -> locked */ - unsigned short spinners; /* count of waiting cpus */ +struct xen_lock_waiting { + struct arch_spinlock *lock; + __ticket_t want; }; static DEFINE_PER_CPU(int, lock_kicker_irq) = -1; +static DEFINE_PER_CPU(struct xen_lock_waiting, lock_waiting); +static cpumask_t waiting_cpus; -#if 0 -static int xen_spin_is_locked(struct arch_spinlock *lock) -{ - struct xen_spinlock *xl = (struct xen_spinlock *)lock; - - return xl->lock != 0; -} - -static int xen_spin_is_contended(struct arch_spinlock *lock) +static void xen_lock_spinning(struct arch_spinlock *lock, __ticket_t want) { - struct xen_spinlock *xl = (struct xen_spinlock *)lock; - - /* Not strictly true; this is only the count of contended - lock-takers entering the slow path. */ - return xl->spinners != 0; -} - -static int xen_spin_trylock(struct arch_spinlock *lock) -{ - struct xen_spinlock *xl = (struct xen_spinlock *)lock; - u8 old = 1; - - asm("xchgb %b0,%1" - : "+q" (old), "+m" (xl->lock) : : "memory"); - - return old == 0; -} - -static DEFINE_PER_CPU(struct xen_spinlock *, lock_spinners); - -/* - * Mark a cpu as interested in a lock. Returns the CPU's previous - * lock of interest, in case we got preempted by an interrupt. - */ -static inline struct xen_spinlock *spinning_lock(struct xen_spinlock *xl) -{ - struct xen_spinlock *prev; - - prev = __this_cpu_read(lock_spinners); - __this_cpu_write(lock_spinners, xl); - - wmb(); /* set lock of interest before count */ - - asm(LOCK_PREFIX " incw %0" - : "+m" (xl->spinners) : : "memory"); - - return prev; -} - -/* - * Mark a cpu as no longer interested in a lock. Restores previous - * lock of interest (NULL for none). - */ -static inline void unspinning_lock(struct xen_spinlock *xl, struct xen_spinlock *prev) -{ - asm(LOCK_PREFIX " decw %0" - : "+m" (xl->spinners) : : "memory"); - wmb(); /* decrement count before restoring lock */ - __this_cpu_write(lock_spinners, prev); -} - -static noinline int xen_spin_lock_slow(struct arch_spinlock *lock, bool irq_enable) -{ - struct xen_spinlock *xl = (struct xen_spinlock *)lock; - struct xen_spinlock *prev; int irq = __this_cpu_read(lock_kicker_irq); - int ret; + struct xen_lock_waiting *w = &__get_cpu_var(lock_waiting); + int cpu = smp_processor_id(); u64 start; + unsigned long flags; /* If kicker interrupts not initialized yet, just spin */ if (irq == -1) - return 0; + return; start = spin_time_start(); - /* announce we're spinning */ - prev = spinning_lock(xl); + /* Make sure interrupts are disabled to ensure that these + per-cpu values are not overwritten. */ + local_irq_save(flags); + + w->want = want; + w->lock = lock; + + /* This uses set_bit, which atomic and therefore a barrier */ + cpumask_set_cpu(cpu, &waiting_cpus); ADD_STATS(taken_slow, 1); - ADD_STATS(taken_slow_nested, prev != NULL); - - do { - unsigned long flags; - - /* clear pending */ - xen_clear_irq_pending(irq); - - /* check again make sure it didn't become free while - we weren't looking */ - ret = xen_spin_trylock(lock); - if (ret) { - ADD_STATS(taken_slow_pickup, 1); - - /* - * If we interrupted another spinlock while it - * was blocking, make sure it doesn't block - * without rechecking the lock. - */ - if (prev != NULL) - xen_set_irq_pending(irq); - goto out; - } - flags = arch_local_save_flags(); - if (irq_enable) { - ADD_STATS(taken_slow_irqenable, 1); - raw_local_irq_enable(); - } + /* clear pending */ + xen_clear_irq_pending(irq); - /* - * Block until irq becomes pending. If we're - * interrupted at this point (after the trylock but - * before entering the block), then the nested lock - * handler guarantees that the irq will be left - * pending if there's any chance the lock became free; - * xen_poll_irq() returns immediately if the irq is - * pending. - */ - xen_poll_irq(irq); + /* Only check lock once pending cleared */ + barrier(); - raw_local_irq_restore(flags); + /* check again make sure it didn't become free while + we weren't looking */ + if (ACCESS_ONCE(lock->tickets.head) == want) { + ADD_STATS(taken_slow_pickup, 1); + goto out; + } - ADD_STATS(taken_slow_spurious, !xen_test_irq_pending(irq)); - } while (!xen_test_irq_pending(irq)); /* check for spurious wakeups */ + /* Block until irq becomes pending (or perhaps a spurious wakeup) */ + xen_poll_irq(irq); + ADD_STATS(taken_slow_spurious, !xen_test_irq_pending(irq)); kstat_incr_irqs_this_cpu(irq, irq_to_desc(irq)); out: - unspinning_lock(xl, prev); - spin_time_accum_blocked(start); - - return ret; -} - -static inline void __xen_spin_lock(struct arch_spinlock *lock, bool irq_enable) -{ - struct xen_spinlock *xl = (struct xen_spinlock *)lock; - unsigned timeout; - u8 oldval; - u64 start_spin; - - ADD_STATS(taken, 1); - - start_spin = spin_time_start(); - - do { - u64 start_spin_fast = spin_time_start(); - - timeout = TIMEOUT; + cpumask_clear_cpu(cpu, &waiting_cpus); + w->lock = NULL; - asm("1: xchgb %1,%0\n" - " testb %1,%1\n" - " jz 3f\n" - "2: rep;nop\n" - " cmpb $0,%0\n" - " je 1b\n" - " dec %2\n" - " jnz 2b\n" - "3:\n" - : "+m" (xl->lock), "=q" (oldval), "+r" (timeout) - : "1" (1) - : "memory"); + local_irq_restore(flags); - spin_time_accum_spinning(start_spin_fast); - - } while (unlikely(oldval != 0 && - (TIMEOUT == ~0 || !xen_spin_lock_slow(lock, irq_enable)))); - - spin_time_accum_total(start_spin); -} - -static void xen_spin_lock(struct arch_spinlock *lock) -{ - __xen_spin_lock(lock, false); -} - -static void xen_spin_lock_flags(struct arch_spinlock *lock, unsigned long flags) -{ - __xen_spin_lock(lock, !raw_irqs_disabled_flags(flags)); + spin_time_accum_blocked(start); } -static noinline void xen_spin_unlock_slow(struct xen_spinlock *xl) +static void xen_unlock_kick(struct arch_spinlock *lock, __ticket_t next) { int cpu; ADD_STATS(released_slow, 1); - for_each_online_cpu(cpu) { - /* XXX should mix up next cpu selection */ - if (per_cpu(lock_spinners, cpu) == xl) { + for_each_cpu(cpu, &waiting_cpus) { + const struct xen_lock_waiting *w = &per_cpu(lock_waiting, cpu); + + if (w->lock == lock && w->want == next) { ADD_STATS(released_slow_kicked, 1); xen_send_IPI_one(cpu, XEN_SPIN_UNLOCK_VECTOR); break; @@ -320,28 +163,6 @@ static noinline void xen_spin_unlock_slow(struct xen_spinlock *xl) } } -static void xen_spin_unlock(struct arch_spinlock *lock) -{ - struct xen_spinlock *xl = (struct xen_spinlock *)lock; - - ADD_STATS(released, 1); - - smp_wmb(); /* make sure no writes get moved after unlock */ - xl->lock = 0; /* release lock */ - - /* - * Make sure unlock happens before checking for waiting - * spinners. We need a strong barrier to enforce the - * write-read ordering to different memory locations, as the - * CPU makes no implied guarantees about their ordering. - */ - mb(); - - if (unlikely(xl->spinners)) - xen_spin_unlock_slow(xl); -} -#endif - static irqreturn_t dummy_handler(int irq, void *dev_id) { BUG(); @@ -376,14 +197,8 @@ void xen_uninit_lock_cpu(int cpu) void __init xen_init_spinlocks(void) { -#if 0 - pv_lock_ops.spin_is_locked = xen_spin_is_locked; - pv_lock_ops.spin_is_contended = xen_spin_is_contended; - pv_lock_ops.spin_lock = xen_spin_lock; - pv_lock_ops.spin_lock_flags = xen_spin_lock_flags; - pv_lock_ops.spin_trylock = xen_spin_trylock; - pv_lock_ops.spin_unlock = xen_spin_unlock; -#endif + pv_lock_ops.lock_spinning = xen_lock_spinning; + pv_lock_ops.unlock_kick = xen_unlock_kick; } #ifdef CONFIG_XEN_DEBUG_FS @@ -401,37 +216,21 @@ static int __init xen_spinlock_debugfs(void) debugfs_create_u8("zero_stats", 0644, d_spin_debug, &zero_stats); - debugfs_create_u32("timeout", 0644, d_spin_debug, &lock_timeout); - - debugfs_create_u64("taken", 0444, d_spin_debug, &spinlock_stats.taken); debugfs_create_u32("taken_slow", 0444, d_spin_debug, &spinlock_stats.taken_slow); - debugfs_create_u32("taken_slow_nested", 0444, d_spin_debug, - &spinlock_stats.taken_slow_nested); debugfs_create_u32("taken_slow_pickup", 0444, d_spin_debug, &spinlock_stats.taken_slow_pickup); debugfs_create_u32("taken_slow_spurious", 0444, d_spin_debug, &spinlock_stats.taken_slow_spurious); - debugfs_create_u32("taken_slow_irqenable", 0444, d_spin_debug, - &spinlock_stats.taken_slow_irqenable); - debugfs_create_u64("released", 0444, d_spin_debug, &spinlock_stats.released); debugfs_create_u32("released_slow", 0444, d_spin_debug, &spinlock_stats.released_slow); debugfs_create_u32("released_slow_kicked", 0444, d_spin_debug, &spinlock_stats.released_slow_kicked); - debugfs_create_u64("time_spinning", 0444, d_spin_debug, - &spinlock_stats.time_spinning); debugfs_create_u64("time_blocked", 0444, d_spin_debug, &spinlock_stats.time_blocked); - debugfs_create_u64("time_total", 0444, d_spin_debug, - &spinlock_stats.time_total); - xen_debugfs_create_u32_array("histo_total", 0444, d_spin_debug, - spinlock_stats.histo_spin_total, HISTO_BUCKETS + 1); - xen_debugfs_create_u32_array("histo_spinning", 0444, d_spin_debug, - spinlock_stats.histo_spin_spinning, HISTO_BUCKETS + 1); xen_debugfs_create_u32_array("histo_blocked", 0444, d_spin_debug, spinlock_stats.histo_spin_blocked, HISTO_BUCKETS + 1); -- 1.7.6 _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel From xen-devel-bounces@lists.xensource.com Fri Sep 02 17:01:25 2011 Return-path: Envelope-to: www-data@lists.xensource.com Delivery-date: Fri, 02 Sep 2011 17:01:25 -0700 Received: from localhost ([127.0.0.1] helo=lists.colo.xensource.com) by lists.xensource.com with esmtp (Exim 4.43) id 1Qzdfp-0002EN-D7; Fri, 02 Sep 2011 17:01:25 -0700 Received: from mail216.messagelabs.com ([85.158.143.99]) by lists.xensource.com with esmtp (Exim 4.43) id 1QzdZD-0000lN-2z for xen-devel@lists.xensource.com; Fri, 02 Sep 2011 16:54:35 -0700 X-Env-Sender: jeremy@goop.org X-Msg-Ref: server-8.tower-216.messagelabs.com!1315007669!15433886!1 X-Originating-IP: [74.207.240.146] X-StarScan-Version: 6.3.6; banners=-,-,- X-VirusChecked: Checked Received: (qmail 25749 invoked from network); 2 Sep 2011 23:54:30 -0000 Received: from claw.goop.org (HELO claw.goop.org) (74.207.240.146) by server-8.tower-216.messagelabs.com with DHE-RSA-AES256-SHA encrypted SMTP; 2 Sep 2011 23:54:30 -0000 Received: from saboo.goop.org (unknown [IPv6:2001:470:1f05:899:f2de:f1ff:fe5c:34ed]) (Authenticated sender: smtp-saboo) by claw.goop.org (Postfix) with ESMTPSA id D58658ABD; Fri, 2 Sep 2011 16:54:21 -0700 (PDT) Received: by saboo.goop.org (Postfix, from userid 500) id 740922052F; Fri, 2 Sep 2011 16:54:17 -0700 (PDT) From: Jeremy Fitzhardinge To: "H. Peter Anvin" Date: Fri, 2 Sep 2011 16:54:12 -0700 Message-Id: <9205607036e71de584347dc5b9e90f08e393b6fe.1315007226.git.jeremy.fitzhardinge@citrix.com> X-Mailer: git-send-email 1.7.6 In-Reply-To: References: In-Reply-To: References: Cc: Marcelo Tosatti , Nick Piggin , KVM , Peter Zijlstra , the arch/x86 maintainers , Linux Kernel Mailing List , Andi Kleen , Avi Kivity , Jeremy Fitzhardinge , Ingo Molnar , Linus Torvalds , Xen Devel Subject: [Xen-devel] [PATCH 5/8] x86/pvticketlock: use callee-save for lock_spinning X-BeenThere: xen-devel@lists.xensource.com X-Mailman-Version: 2.1.5 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xensource.com Errors-To: xen-devel-bounces@lists.xensource.com From: Jeremy Fitzhardinge Although the lock_spinning calls in the spinlock code are on the uncommon path, their presence can cause the compiler to generate many more register save/restores in the function pre/postamble, which is in the fast path. To avoid this, convert it to using the pvops callee-save calling convention, which defers all the save/restores until the actual function is called, keeping the fastpath clean. Signed-off-by: Jeremy Fitzhardinge --- arch/x86/include/asm/paravirt.h | 2 +- arch/x86/include/asm/paravirt_types.h | 2 +- arch/x86/kernel/paravirt-spinlocks.c | 2 +- arch/x86/xen/spinlock.c | 3 ++- 4 files changed, 5 insertions(+), 4 deletions(-) diff --git a/arch/x86/include/asm/paravirt.h b/arch/x86/include/asm/paravirt.h index 76cae7a..50281c7 100644 --- a/arch/x86/include/asm/paravirt.h +++ b/arch/x86/include/asm/paravirt.h @@ -752,7 +752,7 @@ static inline void __set_fixmap(unsigned /* enum fixed_addresses */ idx, static __always_inline void __ticket_lock_spinning(struct arch_spinlock *lock, __ticket_t ticket) { - PVOP_VCALL2(pv_lock_ops.lock_spinning, lock, ticket); + PVOP_VCALLEE2(pv_lock_ops.lock_spinning, lock, ticket); } static __always_inline void ____ticket_unlock_kick(struct arch_spinlock *lock, __ticket_t ticket) diff --git a/arch/x86/include/asm/paravirt_types.h b/arch/x86/include/asm/paravirt_types.h index 005e24d..5e0c138 100644 --- a/arch/x86/include/asm/paravirt_types.h +++ b/arch/x86/include/asm/paravirt_types.h @@ -330,7 +330,7 @@ struct arch_spinlock; #include struct pv_lock_ops { - void (*lock_spinning)(struct arch_spinlock *lock, __ticket_t ticket); + struct paravirt_callee_save lock_spinning; void (*unlock_kick)(struct arch_spinlock *lock, __ticket_t ticket); }; diff --git a/arch/x86/kernel/paravirt-spinlocks.c b/arch/x86/kernel/paravirt-spinlocks.c index c2e010e..4251c1d 100644 --- a/arch/x86/kernel/paravirt-spinlocks.c +++ b/arch/x86/kernel/paravirt-spinlocks.c @@ -9,7 +9,7 @@ struct pv_lock_ops pv_lock_ops = { #ifdef CONFIG_SMP - .lock_spinning = paravirt_nop, + .lock_spinning = __PV_IS_CALLEE_SAVE(paravirt_nop), .unlock_kick = paravirt_nop, #endif }; diff --git a/arch/x86/xen/spinlock.c b/arch/x86/xen/spinlock.c index f6133c5..7a04950 100644 --- a/arch/x86/xen/spinlock.c +++ b/arch/x86/xen/spinlock.c @@ -145,6 +145,7 @@ out: spin_time_accum_blocked(start); } +PV_CALLEE_SAVE_REGS_THUNK(xen_lock_spinning); static void xen_unlock_kick(struct arch_spinlock *lock, __ticket_t next) { @@ -197,7 +198,7 @@ void xen_uninit_lock_cpu(int cpu) void __init xen_init_spinlocks(void) { - pv_lock_ops.lock_spinning = xen_lock_spinning; + pv_lock_ops.lock_spinning = PV_CALLEE_SAVE(xen_lock_spinning); pv_lock_ops.unlock_kick = xen_unlock_kick; } -- 1.7.6 _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel From xen-devel-bounces@lists.xensource.com Fri Sep 02 17:04:29 2011 Return-path: Envelope-to: www-data@lists.xensource.com Delivery-date: Fri, 02 Sep 2011 17:04:29 -0700 Received: from localhost ([127.0.0.1] helo=lists.colo.xensource.com) by lists.xensource.com with esmtp (Exim 4.43) id 1Qzdik-0002da-1z; Fri, 02 Sep 2011 17:04:28 -0700 Received: from mail216.messagelabs.com ([85.158.143.99]) by lists.xensource.com with esmtp (Exim 4.43) id 1QzdZD-0000lL-03 for xen-devel@lists.xensource.com; Fri, 02 Sep 2011 16:54:35 -0700 X-Env-Sender: jeremy@goop.org X-Msg-Ref: server-8.tower-216.messagelabs.com!1315007669!15433887!1 X-Originating-IP: [74.207.240.146] X-StarScan-Version: 6.3.6; banners=-,-,- X-VirusChecked: Checked Received: (qmail 25750 invoked from network); 2 Sep 2011 23:54:31 -0000 Received: from claw.goop.org (HELO claw.goop.org) (74.207.240.146) by server-8.tower-216.messagelabs.com with DHE-RSA-AES256-SHA encrypted SMTP; 2 Sep 2011 23:54:31 -0000 Received: from saboo.goop.org (unknown [IPv6:2001:470:1f05:899:f2de:f1ff:fe5c:34ed]) (Authenticated sender: smtp-saboo) by claw.goop.org (Postfix) with ESMTPSA id DE6458ABE; Fri, 2 Sep 2011 16:54:21 -0700 (PDT) Received: by saboo.goop.org (Postfix, from userid 500) id 8D8502054C; Fri, 2 Sep 2011 16:54:17 -0700 (PDT) From: Jeremy Fitzhardinge To: "H. Peter Anvin" Date: Fri, 2 Sep 2011 16:54:15 -0700 Message-Id: X-Mailer: git-send-email 1.7.6 In-Reply-To: References: In-Reply-To: References: Cc: Marcelo Tosatti , Nick Piggin , KVM , Peter Zijlstra , the arch/x86 maintainers , Linux Kernel Mailing List , Andi Kleen , Avi Kivity , Jeremy Fitzhardinge , Ingo Molnar , Linus Torvalds , Xen Devel Subject: [Xen-devel] [PATCH 8/8] xen/pvticketlock: allow interrupts to be enabled while blocking X-BeenThere: xen-devel@lists.xensource.com X-Mailman-Version: 2.1.5 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xensource.com Errors-To: xen-devel-bounces@lists.xensource.com From: Jeremy Fitzhardinge If interrupts were enabled when taking the spinlock, we can leave them enabled while blocking to get the lock. Signed-off-by: Jeremy Fitzhardinge --- arch/x86/xen/spinlock.c | 42 +++++++++++++++++++++++++++++++++++------- 1 files changed, 35 insertions(+), 7 deletions(-) diff --git a/arch/x86/xen/spinlock.c b/arch/x86/xen/spinlock.c index c939723..d2335f88 100644 --- a/arch/x86/xen/spinlock.c +++ b/arch/x86/xen/spinlock.c @@ -106,11 +106,28 @@ static void xen_lock_spinning(struct arch_spinlock *lock, __ticket_t want) start = spin_time_start(); - /* Make sure interrupts are disabled to ensure that these - per-cpu values are not overwritten. */ + /* + * Make sure an interrupt handler can't upset things in a + * partially setup state. + */ local_irq_save(flags); + /* + * We don't really care if we're overwriting some other + * (lock,want) pair, as that would mean that we're currently + * in an interrupt context, and the outer context had + * interrupts enabled. That has already kicked the VCPU out + * of xen_poll_irq(), so it will just return spuriously and + * retry with newly setup (lock,want). + * + * The ordering protocol on this is that the "lock" pointer + * may only be set non-NULL if the "want" ticket is correct. + * If we're updating "want", we must first clear "lock". + */ + w->lock = NULL; + smp_wmb(); w->want = want; + smp_wmb(); w->lock = lock; /* This uses set_bit, which atomic and therefore a barrier */ @@ -124,21 +141,30 @@ static void xen_lock_spinning(struct arch_spinlock *lock, __ticket_t want) /* Only check lock once pending cleared */ barrier(); - /* Mark entry to slowpath before doing the pickup test to make - sure we don't deadlock with an unlocker. */ + /* + * Mark entry to slowpath before doing the pickup test to make + * sure we don't deadlock with an unlocker. + */ __ticket_enter_slowpath(lock); - /* check again make sure it didn't become free while - we weren't looking */ + /* + * check again make sure it didn't become free while + * we weren't looking + */ if (ACCESS_ONCE(lock->tickets.head) == want) { ADD_STATS(taken_slow_pickup, 1); goto out; } + /* Allow interrupts while blocked */ + local_irq_restore(flags); + /* Block until irq becomes pending (or perhaps a spurious wakeup) */ xen_poll_irq(irq); ADD_STATS(taken_slow_spurious, !xen_test_irq_pending(irq)); + local_irq_save(flags); + kstat_incr_irqs_this_cpu(irq, irq_to_desc(irq)); out: @@ -160,7 +186,9 @@ static void xen_unlock_kick(struct arch_spinlock *lock, __ticket_t next) for_each_cpu(cpu, &waiting_cpus) { const struct xen_lock_waiting *w = &per_cpu(lock_waiting, cpu); - if (w->lock == lock && w->want == next) { + /* Make sure we read lock before want */ + if (ACCESS_ONCE(w->lock) == lock && + ACCESS_ONCE(w->want) == next) { ADD_STATS(released_slow_kicked, 1); xen_send_IPI_one(cpu, XEN_SPIN_UNLOCK_VECTOR); break; -- 1.7.6 _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel From xen-devel-bounces@lists.xensource.com Fri Sep 02 17:06:30 2011 Return-path: Envelope-to: www-data@lists.xensource.com Delivery-date: Fri, 02 Sep 2011 17:06:30 -0700 Received: from localhost ([127.0.0.1] helo=lists.colo.xensource.com) by lists.xensource.com with esmtp (Exim 4.43) id 1Qzdkj-00031j-TC; Fri, 02 Sep 2011 17:06:29 -0700 Received: from mail21.messagelabs.com ([85.158.143.35]) by lists.xensource.com with esmtp (Exim 4.43) id 1QzdZD-0000lO-AP for xen-devel@lists.xensource.com; Fri, 02 Sep 2011 16:54:35 -0700 X-Env-Sender: jeremy@goop.org X-Msg-Ref: server-8.tower-21.messagelabs.com!1315007652!57551661!1 X-Originating-IP: [74.207.240.146] X-StarScan-Version: 6.3.6; banners=-,-,- X-VirusChecked: Checked Received: (qmail 17958 invoked from network); 2 Sep 2011 23:54:17 -0000 Received: from claw.goop.org (HELO claw.goop.org) (74.207.240.146) by server-8.tower-21.messagelabs.com with DHE-RSA-AES256-SHA encrypted SMTP; 2 Sep 2011 23:54:17 -0000 Received: from saboo.goop.org (unknown [IPv6:2001:470:1f05:899:f2de:f1ff:fe5c:34ed]) (Authenticated sender: smtp-saboo) by claw.goop.org (Postfix) with ESMTPSA id 92B8B8AB2; Fri, 2 Sep 2011 16:54:20 -0700 (PDT) Received: by saboo.goop.org (Postfix, from userid 500) id 4E31F2045A; Fri, 2 Sep 2011 16:54:17 -0700 (PDT) From: Jeremy Fitzhardinge To: "H. Peter Anvin" Date: Fri, 2 Sep 2011 16:54:07 -0700 Message-Id: X-Mailer: git-send-email 1.7.6 Cc: Marcelo Tosatti , Nick Piggin , KVM , Peter Zijlstra , the arch/x86 maintainers , Linux Kernel Mailing List , Andi Kleen , Avi Kivity , Jeremy Fitzhardinge , Ingo Molnar , Linus Torvalds , Xen Devel Subject: [Xen-devel] [PATCH 0/8] [PATCH RFC V2] Paravirtualized ticketlocks X-BeenThere: xen-devel@lists.xensource.com X-Mailman-Version: 2.1.5 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xensource.com Errors-To: xen-devel-bounces@lists.xensource.com From: Jeremy Fitzhardinge [ Changes since last posting: - fold all the cleanup/bugfix patches into their base patches - change spin_lock to make sure fastpath has no cruft in it - make sure it doesn't attempt to inline unlock ] NOTE: this series is based on tip.git tip/x86/spinlocks This series replaces the existing paravirtualized spinlock mechanism with a paravirtualized ticketlock mechanism. Ticket locks have an inherent problem in a virtualized case, because the vCPUs are scheduled rather than running concurrently (ignoring gang scheduled vCPUs). This can result in catastrophic performance collapses when the vCPU scheduler doesn't schedule the correct "next" vCPU, and ends up scheduling a vCPU which burns its entire timeslice spinning. (Note that this is not the same problem as lock-holder preemption, which this series also addresses; that's also a problem, but not catastrophic). (See Thomas Friebel's talk "Prevent Guests from Spinning Around" http://www.xen.org/files/xensummitboston08/LHP.pdf for more details.) Currently we deal with this by having PV spinlocks, which adds a layer of indirection in front of all the spinlock functions, and defining a completely new implementation for Xen (and for other pvops users, but there are none at present). PV ticketlocks keeps the existing ticketlock implemenentation (fastpath) as-is, but adds a couple of pvops for the slow paths: - If a CPU has been waiting for a spinlock for SPIN_THRESHOLD iterations, then call out to the __ticket_lock_spinning() pvop, which allows a backend to block the vCPU rather than spinning. This pvop can set the lock into "slowpath state". - When releasing a lock, if it is in "slowpath state", the call __ticket_unlock_kick() to kick the next vCPU in line awake. If the lock is no longer in contention, it also clears the slowpath flag. The "slowpath state" is stored in the LSB of the within the lock ticket. This has the effect of reducing the max number of CPUs by half (so, a "small ticket" can deal with 128 CPUs, and "large ticket" 32768). This series provides a Xen implementation, but it should be straightforward to add a KVM implementation as well. Overall, it results in a large reduction in code, it makes the native and virtualized cases closer, and it removes a layer of indirection around all the spinlock functions. The fast path (taking an uncontended lock which isn't in "slowpath" state) is optimal, identical to the non-paravirtualized case. The inner part of ticket lock code becomes: inc = xadd(&lock->tickets, inc); inc.tail &= ~TICKET_SLOWPATH_FLAG; if (likely(inc.head == inc.tail)) goto out; for (;;) { unsigned count = SPIN_THRESHOLD; do { if (ACCESS_ONCE(lock->tickets.head) == inc.tail) goto out; cpu_relax(); } while (--count); __ticket_lock_spinning(lock, inc.tail); } out: barrier(); which results in: push %rbp mov %rsp,%rbp mov $0x200,%eax lock xadd %ax,(%rdi) movzbl %ah,%edx cmp %al,%dl jne 1f pop %rbp retq ### SLOWPATH START 1: and $-2,%edx movzbl %dl,%esi 2: mov $0x800,%eax jmp 4f 3: pause sub $0x1,%eax je 5f 4: movzbl (%rdi),%ecx cmp %cl,%dl jne 3b pop %rbp retq 5: callq *__ticket_lock_spinning jmp 2b ### SLOWPATH END with CONFIG_PARAVIRT_SPINLOCKS=n, the code has changed slightly, where the fastpath case is straight through (taking the lock without contention), and the spin loop is out of line: push %rbp mov %rsp,%rbp mov $0x100,%eax lock xadd %ax,(%rdi) movzbl %ah,%edx cmp %al,%dl jne 1f pop %rbp retq ### SLOWPATH START 1: pause movzbl (%rdi),%eax cmp %dl,%al jne 1b pop %rbp retq ### SLOWPATH END The unlock code is very straightforward: __ticket_unlock_release(lock); if (unlikely(__ticket_in_slowpath(lock))) __ticket_unlock_slowpath(lock); which generates: push %rbp mov %rsp,%rbp addb $0x2,(%rdi) testb $0x1,0x1(%rdi) jne 1f pop %rbp retq ### SLOWPATH START 1: movzwl (%rdi),%edx movzbl %dh,%ecx mov %edx,%eax and $-2,%ecx # clear TICKET_SLOWPATH_FLAG mov %cl,%dh cmp %dl,%cl # test to see if lock is uncontended je 3f 2: movzbl %dl,%esi callq *__ticket_unlock_kick # kick anyone waiting pop %rbp retq 3: lock cmpxchg %dx,(%rdi) # use cmpxchg to safely write back flag jmp 2b ### SLOWPATH END The fastpath is pretty straightforward, but it is definitely more complex than a simple "incb (%rdi)" - which is still generated (and inlined) when PARAVIRT_SPINLOCKS is disabled. Thoughts? Comments? Suggestions? Thanks, J Jeremy Fitzhardinge (8): x86/spinlocks: replace pv spinlocks with pv ticketlocks x86/ticketlock: don't inline _spin_unlock when using paravirt spinlocks x86/ticketlock: collapse a layer of functions xen/pvticketlock: Xen implementation for PV ticket locks x86/pvticketlock: use callee-save for lock_spinning x86/ticketlocks: when paravirtualizing ticket locks, increment by 2 x86/ticketlock: add slowpath logic xen/pvticketlock: allow interrupts to be enabled while blocking arch/x86/Kconfig | 3 + arch/x86/include/asm/paravirt.h | 30 +--- arch/x86/include/asm/paravirt_types.h | 10 +- arch/x86/include/asm/spinlock.h | 134 ++++++++++----- arch/x86/include/asm/spinlock_types.h | 16 ++- arch/x86/kernel/paravirt-spinlocks.c | 16 +-- arch/x86/xen/spinlock.c | 311 ++++++++------------------------- kernel/Kconfig.locks | 2 +- 8 files changed, 193 insertions(+), 329 deletions(-) -- 1.7.6 _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel From xen-devel-bounces@lists.xensource.com Fri Sep 02 17:08:34 2011 Return-path: Envelope-to: www-data@lists.xensource.com Delivery-date: Fri, 02 Sep 2011 17:08:34 -0700 Received: from localhost ([127.0.0.1] helo=lists.colo.xensource.com) by lists.xensource.com with esmtp (Exim 4.43) id 1Qzdmi-0003Pp-UI; Fri, 02 Sep 2011 17:08:33 -0700 Received: from mail216.messagelabs.com ([85.158.143.99]) by lists.xensource.com with esmtp (Exim 4.43) id 1QzdZD-0000lP-Gs for xen-devel@lists.xensource.com; Fri, 02 Sep 2011 16:54:36 -0700 X-Env-Sender: jeremy@goop.org X-Msg-Ref: server-5.tower-216.messagelabs.com!1315007670!16431555!1 X-Originating-IP: [74.207.240.146] X-StarScan-Version: 6.3.6; banners=-,-,- X-VirusChecked: Checked Received: (qmail 1347 invoked from network); 2 Sep 2011 23:54:32 -0000 Received: from claw.goop.org (HELO claw.goop.org) (74.207.240.146) by server-5.tower-216.messagelabs.com with DHE-RSA-AES256-SHA encrypted SMTP; 2 Sep 2011 23:54:32 -0000 Received: from saboo.goop.org (unknown [IPv6:2001:470:1f05:899:f2de:f1ff:fe5c:34ed]) (Authenticated sender: smtp-saboo) by claw.goop.org (Postfix) with ESMTPSA id D1FA78AB8; Fri, 2 Sep 2011 16:54:21 -0700 (PDT) Received: by saboo.goop.org (Postfix, from userid 500) id 5310920166; Fri, 2 Sep 2011 16:54:17 -0700 (PDT) From: Jeremy Fitzhardinge To: "H. Peter Anvin" Date: Fri, 2 Sep 2011 16:54:08 -0700 Message-Id: X-Mailer: git-send-email 1.7.6 In-Reply-To: References: In-Reply-To: References: Cc: Marcelo Tosatti , Nick Piggin , KVM , Peter Zijlstra , the arch/x86 maintainers , Linux Kernel Mailing List , Andi Kleen , Avi Kivity , Jeremy Fitzhardinge , Ingo Molnar , Linus Torvalds , Xen Devel Subject: [Xen-devel] [PATCH 1/8] x86/spinlocks: replace pv spinlocks with pv ticketlocks X-BeenThere: xen-devel@lists.xensource.com X-Mailman-Version: 2.1.5 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xensource.com Errors-To: xen-devel-bounces@lists.xensource.com From: Jeremy Fitzhardinge Rather than outright replacing the entire spinlock implementation in order to paravirtualize it, keep the ticket lock implementation but add a couple of pvops hooks on the slow patch (long spin on lock, unlocking a contended lock). Ticket locks have a number of nice properties, but they also have some surprising behaviours in virtual environments. They enforce a strict FIFO ordering on cpus trying to take a lock; however, if the hypervisor scheduler does not schedule the cpus in the correct order, the system can waste a huge amount of time spinning until the next cpu can take the lock. (See Thomas Friebel's talk "Prevent Guests from Spinning Around" http://www.xen.org/files/xensummitboston08/LHP.pdf for more details.) To address this, we add two hooks: - __ticket_spin_lock which is called after the cpu has been spinning on the lock for a significant number of iterations but has failed to take the lock (presumably because the cpu holding the lock has been descheduled). The lock_spinning pvop is expected to block the cpu until it has been kicked by the current lock holder. - __ticket_spin_unlock, which on releasing a contended lock (there are more cpus with tail tickets), it looks to see if the next cpu is blocked and wakes it if so. When compiled with CONFIG_PARAVIRT_SPINLOCKS disabled, a set of stub functions causes all the extra code to go away. Signed-off-by: Jeremy Fitzhardinge --- arch/x86/include/asm/paravirt.h | 30 ++-------------- arch/x86/include/asm/paravirt_types.h | 10 ++--- arch/x86/include/asm/spinlock.h | 59 ++++++++++++++++++++++++++------- arch/x86/include/asm/spinlock_types.h | 4 -- arch/x86/kernel/paravirt-spinlocks.c | 15 +------- arch/x86/xen/spinlock.c | 7 +++- 6 files changed, 63 insertions(+), 62 deletions(-) diff --git a/arch/x86/include/asm/paravirt.h b/arch/x86/include/asm/paravirt.h index a7d2db9..76cae7a 100644 --- a/arch/x86/include/asm/paravirt.h +++ b/arch/x86/include/asm/paravirt.h @@ -750,36 +750,14 @@ static inline void __set_fixmap(unsigned /* enum fixed_addresses */ idx, #if defined(CONFIG_SMP) && defined(CONFIG_PARAVIRT_SPINLOCKS) -static inline int arch_spin_is_locked(struct arch_spinlock *lock) +static __always_inline void __ticket_lock_spinning(struct arch_spinlock *lock, __ticket_t ticket) { - return PVOP_CALL1(int, pv_lock_ops.spin_is_locked, lock); + PVOP_VCALL2(pv_lock_ops.lock_spinning, lock, ticket); } -static inline int arch_spin_is_contended(struct arch_spinlock *lock) +static __always_inline void ____ticket_unlock_kick(struct arch_spinlock *lock, __ticket_t ticket) { - return PVOP_CALL1(int, pv_lock_ops.spin_is_contended, lock); -} -#define arch_spin_is_contended arch_spin_is_contended - -static __always_inline void arch_spin_lock(struct arch_spinlock *lock) -{ - PVOP_VCALL1(pv_lock_ops.spin_lock, lock); -} - -static __always_inline void arch_spin_lock_flags(struct arch_spinlock *lock, - unsigned long flags) -{ - PVOP_VCALL2(pv_lock_ops.spin_lock_flags, lock, flags); -} - -static __always_inline int arch_spin_trylock(struct arch_spinlock *lock) -{ - return PVOP_CALL1(int, pv_lock_ops.spin_trylock, lock); -} - -static __always_inline void arch_spin_unlock(struct arch_spinlock *lock) -{ - PVOP_VCALL1(pv_lock_ops.spin_unlock, lock); + PVOP_VCALL2(pv_lock_ops.unlock_kick, lock, ticket); } #endif diff --git a/arch/x86/include/asm/paravirt_types.h b/arch/x86/include/asm/paravirt_types.h index 8e8b9a4..005e24d 100644 --- a/arch/x86/include/asm/paravirt_types.h +++ b/arch/x86/include/asm/paravirt_types.h @@ -327,13 +327,11 @@ struct pv_mmu_ops { }; struct arch_spinlock; +#include + struct pv_lock_ops { - int (*spin_is_locked)(struct arch_spinlock *lock); - int (*spin_is_contended)(struct arch_spinlock *lock); - void (*spin_lock)(struct arch_spinlock *lock); - void (*spin_lock_flags)(struct arch_spinlock *lock, unsigned long flags); - int (*spin_trylock)(struct arch_spinlock *lock); - void (*spin_unlock)(struct arch_spinlock *lock); + void (*lock_spinning)(struct arch_spinlock *lock, __ticket_t ticket); + void (*unlock_kick)(struct arch_spinlock *lock, __ticket_t ticket); }; /* This contains all the paravirt structures: we get a convenient diff --git a/arch/x86/include/asm/spinlock.h b/arch/x86/include/asm/spinlock.h index f5695ee..bafed3b 100644 --- a/arch/x86/include/asm/spinlock.h +++ b/arch/x86/include/asm/spinlock.h @@ -37,6 +37,32 @@ # define UNLOCK_LOCK_PREFIX #endif +/* How long a lock should spin before we consider blocking */ +#define SPIN_THRESHOLD (1 << 11) + +#ifndef CONFIG_PARAVIRT_SPINLOCKS + +static __always_inline void __ticket_lock_spinning(struct arch_spinlock *lock, __ticket_t ticket) +{ +} + +static __always_inline void ____ticket_unlock_kick(struct arch_spinlock *lock, __ticket_t ticket) +{ +} + +#endif /* CONFIG_PARAVIRT_SPINLOCKS */ + + +/* + * If a spinlock has someone waiting on it, then kick the appropriate + * waiting cpu. + */ +static __always_inline void __ticket_unlock_kick(struct arch_spinlock *lock, __ticket_t next) +{ + if (unlikely(lock->tickets.tail != next)) + ____ticket_unlock_kick(lock, next); +} + /* * Ticket locks are conceptually two parts, one indicating the current head of * the queue, and the other indicating the current tail. The lock is acquired @@ -54,19 +80,24 @@ * save some instructions and make the code more elegant. There really isn't * much between them in performance though, especially as locks are out of line. */ -static __always_inline void __ticket_spin_lock(arch_spinlock_t *lock) +static __always_inline void __ticket_spin_lock(struct arch_spinlock *lock) { register struct __raw_tickets inc = { .tail = 1 }; inc = xadd(&lock->tickets, inc); for (;;) { - if (inc.head == inc.tail) - break; - cpu_relax(); - inc.head = ACCESS_ONCE(lock->tickets.head); + unsigned count = SPIN_THRESHOLD; + + do { + if (inc.head == inc.tail) + goto out; + cpu_relax(); + inc.head = ACCESS_ONCE(lock->tickets.head); + } while (--count); + __ticket_lock_spinning(lock, inc.tail); } - barrier(); /* make sure nothing creeps before the lock is taken */ +out: barrier(); /* make sure nothing creeps before the lock is taken */ } static __always_inline int __ticket_spin_trylock(arch_spinlock_t *lock) @@ -84,7 +115,7 @@ static __always_inline int __ticket_spin_trylock(arch_spinlock_t *lock) } #if (NR_CPUS < 256) -static __always_inline void __ticket_spin_unlock(arch_spinlock_t *lock) +static __always_inline void __ticket_unlock_release(arch_spinlock_t *lock) { asm volatile(UNLOCK_LOCK_PREFIX "incb %0" : "+m" (lock->head_tail) @@ -92,7 +123,7 @@ static __always_inline void __ticket_spin_unlock(arch_spinlock_t *lock) : "memory", "cc"); } #else -static __always_inline void __ticket_spin_unlock(arch_spinlock_t *lock) +static __always_inline void __ticket_unlock_release(arch_spinlock_t *lock) { asm volatile(UNLOCK_LOCK_PREFIX "incw %0" : "+m" (lock->head_tail) @@ -101,6 +132,14 @@ static __always_inline void __ticket_spin_unlock(arch_spinlock_t *lock) } #endif +static __always_inline void __ticket_spin_unlock(arch_spinlock_t *lock) +{ + __ticket_t next = lock->tickets.head + 1; + + __ticket_unlock_release(lock); + __ticket_unlock_kick(lock, next); +} + static inline int __ticket_spin_is_locked(arch_spinlock_t *lock) { struct __raw_tickets tmp = ACCESS_ONCE(lock->tickets); @@ -115,8 +154,6 @@ static inline int __ticket_spin_is_contended(arch_spinlock_t *lock) return ((tmp.tail - tmp.head) & TICKET_MASK) > 1; } -#ifndef CONFIG_PARAVIRT_SPINLOCKS - static inline int arch_spin_is_locked(arch_spinlock_t *lock) { return __ticket_spin_is_locked(lock); @@ -149,8 +186,6 @@ static __always_inline void arch_spin_lock_flags(arch_spinlock_t *lock, arch_spin_lock(lock); } -#endif /* CONFIG_PARAVIRT_SPINLOCKS */ - static inline void arch_spin_unlock_wait(arch_spinlock_t *lock) { while (arch_spin_is_locked(lock)) diff --git a/arch/x86/include/asm/spinlock_types.h b/arch/x86/include/asm/spinlock_types.h index 8ebd5df..dbe223d 100644 --- a/arch/x86/include/asm/spinlock_types.h +++ b/arch/x86/include/asm/spinlock_types.h @@ -1,10 +1,6 @@ #ifndef _ASM_X86_SPINLOCK_TYPES_H #define _ASM_X86_SPINLOCK_TYPES_H -#ifndef __LINUX_SPINLOCK_TYPES_H -# error "please don't include this file directly" -#endif - #include #if (CONFIG_NR_CPUS < 256) diff --git a/arch/x86/kernel/paravirt-spinlocks.c b/arch/x86/kernel/paravirt-spinlocks.c index 676b8c7..c2e010e 100644 --- a/arch/x86/kernel/paravirt-spinlocks.c +++ b/arch/x86/kernel/paravirt-spinlocks.c @@ -7,21 +7,10 @@ #include -static inline void -default_spin_lock_flags(arch_spinlock_t *lock, unsigned long flags) -{ - arch_spin_lock(lock); -} - struct pv_lock_ops pv_lock_ops = { #ifdef CONFIG_SMP - .spin_is_locked = __ticket_spin_is_locked, - .spin_is_contended = __ticket_spin_is_contended, - - .spin_lock = __ticket_spin_lock, - .spin_lock_flags = default_spin_lock_flags, - .spin_trylock = __ticket_spin_trylock, - .spin_unlock = __ticket_spin_unlock, + .lock_spinning = paravirt_nop, + .unlock_kick = paravirt_nop, #endif }; EXPORT_SYMBOL(pv_lock_ops); diff --git a/arch/x86/xen/spinlock.c b/arch/x86/xen/spinlock.c index cc9b1e1..23af06a 100644 --- a/arch/x86/xen/spinlock.c +++ b/arch/x86/xen/spinlock.c @@ -121,6 +121,9 @@ struct xen_spinlock { unsigned short spinners; /* count of waiting cpus */ }; +static DEFINE_PER_CPU(int, lock_kicker_irq) = -1; + +#if 0 static int xen_spin_is_locked(struct arch_spinlock *lock) { struct xen_spinlock *xl = (struct xen_spinlock *)lock; @@ -148,7 +151,6 @@ static int xen_spin_trylock(struct arch_spinlock *lock) return old == 0; } -static DEFINE_PER_CPU(int, lock_kicker_irq) = -1; static DEFINE_PER_CPU(struct xen_spinlock *, lock_spinners); /* @@ -338,6 +340,7 @@ static void xen_spin_unlock(struct arch_spinlock *lock) if (unlikely(xl->spinners)) xen_spin_unlock_slow(xl); } +#endif static irqreturn_t dummy_handler(int irq, void *dev_id) { @@ -373,12 +376,14 @@ void xen_uninit_lock_cpu(int cpu) void __init xen_init_spinlocks(void) { +#if 0 pv_lock_ops.spin_is_locked = xen_spin_is_locked; pv_lock_ops.spin_is_contended = xen_spin_is_contended; pv_lock_ops.spin_lock = xen_spin_lock; pv_lock_ops.spin_lock_flags = xen_spin_lock_flags; pv_lock_ops.spin_trylock = xen_spin_trylock; pv_lock_ops.spin_unlock = xen_spin_unlock; +#endif } #ifdef CONFIG_XEN_DEBUG_FS -- 1.7.6 _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel From xen-devel-bounces@lists.xensource.com Fri Sep 02 17:09:53 2011 Return-path: Envelope-to: www-data@lists.xensource.com Delivery-date: Fri, 02 Sep 2011 17:09:53 -0700 Received: from localhost ([127.0.0.1] helo=lists.colo.xensource.com) by lists.xensource.com with esmtp (Exim 4.43) id 1Qzdo1-0003n4-Iw; Fri, 02 Sep 2011 17:09:53 -0700 Received: from mail216.messagelabs.com ([85.158.143.99]) by lists.xensource.com with esmtp (Exim 4.43) id 1QzdZD-0000lQ-J2 for xen-devel@lists.xensource.com; Fri, 02 Sep 2011 16:54:36 -0700 X-Env-Sender: jeremy@goop.org X-Msg-Ref: server-12.tower-216.messagelabs.com!1315007670!11161581!1 X-Originating-IP: [74.207.240.146] X-StarScan-Version: 6.3.6; banners=-,-,- X-VirusChecked: Checked Received: (qmail 5799 invoked from network); 2 Sep 2011 23:54:32 -0000 Received: from claw.goop.org (HELO claw.goop.org) (74.207.240.146) by server-12.tower-216.messagelabs.com with DHE-RSA-AES256-SHA encrypted SMTP; 2 Sep 2011 23:54:32 -0000 Received: from saboo.goop.org (unknown [IPv6:2001:470:1f05:899:f2de:f1ff:fe5c:34ed]) (Authenticated sender: smtp-saboo) by claw.goop.org (Postfix) with ESMTPSA id D20468ABC; Fri, 2 Sep 2011 16:54:21 -0700 (PDT) Received: by saboo.goop.org (Postfix, from userid 500) id 7B57E20530; Fri, 2 Sep 2011 16:54:17 -0700 (PDT) From: Jeremy Fitzhardinge To: "H. Peter Anvin" Date: Fri, 2 Sep 2011 16:54:13 -0700 Message-Id: <82b5dc58aa9e5ce0b6352d06a1eaf78983021f96.1315007226.git.jeremy.fitzhardinge@citrix.com> X-Mailer: git-send-email 1.7.6 In-Reply-To: References: In-Reply-To: References: Cc: Marcelo Tosatti , Nick Piggin , KVM , Peter Zijlstra , the arch/x86 maintainers , Linux Kernel Mailing List , Andi Kleen , Avi Kivity , Jeremy Fitzhardinge , Ingo Molnar , Linus Torvalds , Xen Devel Subject: [Xen-devel] [PATCH 6/8] x86/ticketlocks: when paravirtualizing ticket locks, increment by 2 X-BeenThere: xen-devel@lists.xensource.com X-Mailman-Version: 2.1.5 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xensource.com Errors-To: xen-devel-bounces@lists.xensource.com From: Jeremy Fitzhardinge Increment ticket head/tails by 2 rather than 1 to leave the LSB free to store a "is in slowpath state" bit. This halves the number of possible CPUs for a given ticket size, but this shouldn't matter in practice - kernels built for 32k+ CPU systems are probably specially built for the hardware rather than a generic distro kernel. Signed-off-by: Jeremy Fitzhardinge --- arch/x86/include/asm/spinlock.h | 16 ++++++++-------- arch/x86/include/asm/spinlock_types.h | 10 +++++++++- 2 files changed, 17 insertions(+), 9 deletions(-) diff --git a/arch/x86/include/asm/spinlock.h b/arch/x86/include/asm/spinlock.h index d1a3970..7a1c0c4 100644 --- a/arch/x86/include/asm/spinlock.h +++ b/arch/x86/include/asm/spinlock.h @@ -82,7 +82,7 @@ static __always_inline void __ticket_unlock_kick(struct arch_spinlock *lock, __t */ static __always_inline void arch_spin_lock(struct arch_spinlock *lock) { - register struct __raw_tickets inc = { .tail = 1 }; + register struct __raw_tickets inc = { .tail = TICKET_LOCK_INC }; inc = xadd(&lock->tickets, inc); @@ -108,7 +108,7 @@ static __always_inline int arch_spin_trylock(arch_spinlock_t *lock) if (old.tickets.head != old.tickets.tail) return 0; - new.head_tail = old.head_tail + (1 << TICKET_SHIFT); + new.head_tail = old.head_tail + (TICKET_LOCK_INC << TICKET_SHIFT); /* cmpxchg is a full barrier, so nothing can move before it */ return cmpxchg(&lock->head_tail, old.head_tail, new.head_tail) == old.head_tail; @@ -117,24 +117,24 @@ static __always_inline int arch_spin_trylock(arch_spinlock_t *lock) #if (NR_CPUS < 256) static __always_inline void __ticket_unlock_release(arch_spinlock_t *lock) { - asm volatile(UNLOCK_LOCK_PREFIX "incb %0" + asm volatile(UNLOCK_LOCK_PREFIX "addb %1, %0" : "+m" (lock->head_tail) - : + : "i" (TICKET_LOCK_INC) : "memory", "cc"); } #else static __always_inline void __ticket_unlock_release(arch_spinlock_t *lock) { - asm volatile(UNLOCK_LOCK_PREFIX "incw %0" + asm volatile(UNLOCK_LOCK_PREFIX "addw %1, %0" : "+m" (lock->head_tail) - : + : "i" (TICKET_LOCK_INC) : "memory", "cc"); } #endif static __always_inline void arch_spin_unlock(arch_spinlock_t *lock) { - __ticket_t next = lock->tickets.head + 1; + __ticket_t next = lock->tickets.head + TICKET_LOCK_INC; __ticket_unlock_release(lock); __ticket_unlock_kick(lock, next); @@ -151,7 +151,7 @@ static inline int arch_spin_is_contended(arch_spinlock_t *lock) { struct __raw_tickets tmp = ACCESS_ONCE(lock->tickets); - return ((tmp.tail - tmp.head) & TICKET_MASK) > 1; + return ((tmp.tail - tmp.head) & TICKET_MASK) > TICKET_LOCK_INC; } #define arch_spin_is_contended arch_spin_is_contended diff --git a/arch/x86/include/asm/spinlock_types.h b/arch/x86/include/asm/spinlock_types.h index dbe223d..aa9a205 100644 --- a/arch/x86/include/asm/spinlock_types.h +++ b/arch/x86/include/asm/spinlock_types.h @@ -3,7 +3,13 @@ #include -#if (CONFIG_NR_CPUS < 256) +#ifdef CONFIG_PARAVIRT_SPINLOCKS +#define __TICKET_LOCK_INC 2 +#else +#define __TICKET_LOCK_INC 1 +#endif + +#if (CONFIG_NR_CPUS < (256 / __TICKET_LOCK_INC)) typedef u8 __ticket_t; typedef u16 __ticketpair_t; #else @@ -11,6 +17,8 @@ typedef u16 __ticket_t; typedef u32 __ticketpair_t; #endif +#define TICKET_LOCK_INC ((__ticket_t)__TICKET_LOCK_INC) + #define TICKET_SHIFT (sizeof(__ticket_t) * 8) #define TICKET_MASK ((__ticket_t)((1 << TICKET_SHIFT) - 1)) -- 1.7.6 _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel From xen-devel-bounces@lists.xensource.com Fri Sep 02 17:11:06 2011 Return-path: Envelope-to: www-data@lists.xensource.com Delivery-date: Fri, 02 Sep 2011 17:11:06 -0700 Received: from localhost ([127.0.0.1] helo=lists.colo.xensource.com) by lists.xensource.com with esmtp (Exim 4.43) id 1QzdpC-0004Ap-AB; Fri, 02 Sep 2011 17:11:06 -0700 Received: from mail27.messagelabs.com ([193.109.254.147]) by lists.xensource.com with esmtp (Exim 4.43) id 1QzdZE-0000le-VF for xen-devel@lists.xensource.com; Fri, 02 Sep 2011 16:54:37 -0700 X-Env-Sender: jeremy@goop.org X-Msg-Ref: server-9.tower-27.messagelabs.com!1315007658!42957842!1 X-Originating-IP: [74.207.240.146] X-StarScan-Version: 6.3.6; banners=-,-,- X-VirusChecked: Checked Received: (qmail 11856 invoked from network); 2 Sep 2011 23:54:19 -0000 Received: from claw.goop.org (HELO claw.goop.org) (74.207.240.146) by server-9.tower-27.messagelabs.com with DHE-RSA-AES256-SHA encrypted SMTP; 2 Sep 2011 23:54:19 -0000 Received: from saboo.goop.org (unknown [IPv6:2001:470:1f05:899:f2de:f1ff:fe5c:34ed]) (Authenticated sender: smtp-saboo) by claw.goop.org (Postfix) with ESMTPSA id 5085D8ABF; Fri, 2 Sep 2011 16:54:22 -0700 (PDT) Received: by saboo.goop.org (Postfix, from userid 500) id 84DEE2054B; Fri, 2 Sep 2011 16:54:17 -0700 (PDT) From: Jeremy Fitzhardinge To: "H. Peter Anvin" Date: Fri, 2 Sep 2011 16:54:14 -0700 Message-Id: <1004debacaf9e25bd2cc1793e671b494995ec10a.1315007226.git.jeremy.fitzhardinge@citrix.com> X-Mailer: git-send-email 1.7.6 In-Reply-To: References: In-Reply-To: References: Cc: Marcelo Tosatti , Nick Piggin , KVM , Peter Zijlstra , the arch/x86 maintainers , Linux Kernel Mailing List , Srivatsa Vaddagiri , Andi Kleen , Avi Kivity , Jeremy Fitzhardinge , Ingo Molnar , Linus Torvalds , Xen Devel Subject: [Xen-devel] [PATCH 7/8] x86/ticketlock: add slowpath logic X-BeenThere: xen-devel@lists.xensource.com X-Mailman-Version: 2.1.5 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xensource.com Errors-To: xen-devel-bounces@lists.xensource.com From: Jeremy Fitzhardinge Maintain a flag in the LSB of the ticket lock tail which indicates whether anyone is in the lock slowpath and may need kicking when the current holder unlocks. The flags are set when the first locker enters the slowpath, and cleared when unlocking to an empty queue (ie, no contention). In the specific implementation of lock_spinning(), make sure to set the slowpath flags on the lock just before blocking. We must do this before the last-chance pickup test to prevent a deadlock with the unlocker: Unlocker Locker test for lock pickup -> fail unlock test slowpath -> false set slowpath flags block Whereas this works in any ordering: Unlocker Locker set slowpath flags test for lock pickup -> fail block unlock test slowpath -> true, kick Note: this code relies on gcc making sure that unlikely() code is out of line of the fastpath, which only happens when OPTIMIZE_SIZE=n. If it doesn't the generated code isn't too bad, but its definitely suboptimal. (Thanks to Srivatsa Vaddagiri for providing a bugfix to the original version of this change, which has been folded in.) Signed-off-by: Jeremy Fitzhardinge Signed-off-by: Srivatsa Vaddagiri --- arch/x86/include/asm/paravirt.h | 2 +- arch/x86/include/asm/spinlock.h | 72 ++++++++++++++++++++++++++------- arch/x86/include/asm/spinlock_types.h | 2 + arch/x86/kernel/paravirt-spinlocks.c | 1 + arch/x86/xen/spinlock.c | 4 ++ 5 files changed, 65 insertions(+), 16 deletions(-) diff --git a/arch/x86/include/asm/paravirt.h b/arch/x86/include/asm/paravirt.h index 50281c7..13b3d8b 100644 --- a/arch/x86/include/asm/paravirt.h +++ b/arch/x86/include/asm/paravirt.h @@ -755,7 +755,7 @@ static __always_inline void __ticket_lock_spinning(struct arch_spinlock *lock, _ PVOP_VCALLEE2(pv_lock_ops.lock_spinning, lock, ticket); } -static __always_inline void ____ticket_unlock_kick(struct arch_spinlock *lock, __ticket_t ticket) +static __always_inline void __ticket_unlock_kick(struct arch_spinlock *lock, __ticket_t ticket) { PVOP_VCALL2(pv_lock_ops.unlock_kick, lock, ticket); } diff --git a/arch/x86/include/asm/spinlock.h b/arch/x86/include/asm/spinlock.h index 7a1c0c4..64422f1 100644 --- a/arch/x86/include/asm/spinlock.h +++ b/arch/x86/include/asm/spinlock.h @@ -40,29 +40,46 @@ /* How long a lock should spin before we consider blocking */ #define SPIN_THRESHOLD (1 << 11) -#ifndef CONFIG_PARAVIRT_SPINLOCKS +#ifdef CONFIG_PARAVIRT_SPINLOCKS -static __always_inline void __ticket_lock_spinning(struct arch_spinlock *lock, __ticket_t ticket) +/* + * Return true if someone is in the slowpath on this lock. This + * should only be used by the current lock-holder. + */ +static inline bool __ticket_in_slowpath(struct arch_spinlock *lock) { + return !!(lock->tickets.tail & TICKET_SLOWPATH_FLAG); } -static __always_inline void ____ticket_unlock_kick(struct arch_spinlock *lock, __ticket_t ticket) +static inline void __ticket_enter_slowpath(struct arch_spinlock *lock) { + if (sizeof(lock->tickets.tail) == sizeof(u8)) + asm (LOCK_PREFIX "orb %1, %0" + : "+m" (lock->tickets.tail) + : "i" (TICKET_SLOWPATH_FLAG) : "memory"); + else + asm (LOCK_PREFIX "orw %1, %0" + : "+m" (lock->tickets.tail) + : "i" (TICKET_SLOWPATH_FLAG) : "memory"); } -#endif /* CONFIG_PARAVIRT_SPINLOCKS */ +#else /* !CONFIG_PARAVIRT_SPINLOCKS */ +static inline bool __ticket_in_slowpath(struct arch_spinlock *lock) +{ + return false; +} +static __always_inline void __ticket_lock_spinning(struct arch_spinlock *lock, __ticket_t ticket) +{ +} -/* - * If a spinlock has someone waiting on it, then kick the appropriate - * waiting cpu. - */ -static __always_inline void __ticket_unlock_kick(struct arch_spinlock *lock, __ticket_t next) +static inline void __ticket_unlock_kick(struct arch_spinlock *lock, __ticket_t ticket) { - if (unlikely(lock->tickets.tail != next)) - ____ticket_unlock_kick(lock, next); } +#endif /* CONFIG_PARAVIRT_SPINLOCKS */ + + /* * Ticket locks are conceptually two parts, one indicating the current head of * the queue, and the other indicating the current tail. The lock is acquired @@ -85,15 +102,17 @@ static __always_inline void arch_spin_lock(struct arch_spinlock *lock) register struct __raw_tickets inc = { .tail = TICKET_LOCK_INC }; inc = xadd(&lock->tickets, inc); + if (likely(inc.head == inc.tail)) + goto out; + inc.tail &= ~TICKET_SLOWPATH_FLAG; for (;;) { unsigned count = SPIN_THRESHOLD; do { - if (inc.head == inc.tail) + if (ACCESS_ONCE(lock->tickets.head) == inc.tail) goto out; cpu_relax(); - inc.head = ACCESS_ONCE(lock->tickets.head); } while (--count); __ticket_lock_spinning(lock, inc.tail); } @@ -132,12 +151,35 @@ static __always_inline void __ticket_unlock_release(arch_spinlock_t *lock) } #endif +static inline void __ticket_unlock_slowpath(struct arch_spinlock *lock) +{ + struct arch_spinlock old, new; + + BUILD_BUG_ON(((__ticket_t)NR_CPUS) != NR_CPUS); + + old = ACCESS_ONCE(*lock); + new = old; + + /* Clear the slowpath flag */ + new.tickets.tail &= ~TICKET_SLOWPATH_FLAG; + + /* + * If the lock is uncontended, clear the flag - use cmpxchg in + * case it changes behind our back though. + */ + if (new.tickets.head == new.tickets.tail) + cmpxchg(&lock->head_tail, old.head_tail, new.head_tail); + + /* Wake up an appropriate waiter */ + __ticket_unlock_kick(lock, new.tickets.head); +} + static __always_inline void arch_spin_unlock(arch_spinlock_t *lock) { - __ticket_t next = lock->tickets.head + TICKET_LOCK_INC; __ticket_unlock_release(lock); - __ticket_unlock_kick(lock, next); + if (unlikely(__ticket_in_slowpath(lock))) + __ticket_unlock_slowpath(lock); } static inline int arch_spin_is_locked(arch_spinlock_t *lock) diff --git a/arch/x86/include/asm/spinlock_types.h b/arch/x86/include/asm/spinlock_types.h index aa9a205..407f7f7 100644 --- a/arch/x86/include/asm/spinlock_types.h +++ b/arch/x86/include/asm/spinlock_types.h @@ -5,8 +5,10 @@ #ifdef CONFIG_PARAVIRT_SPINLOCKS #define __TICKET_LOCK_INC 2 +#define TICKET_SLOWPATH_FLAG ((__ticket_t)1) #else #define __TICKET_LOCK_INC 1 +#define TICKET_SLOWPATH_FLAG ((__ticket_t)0) #endif #if (CONFIG_NR_CPUS < (256 / __TICKET_LOCK_INC)) diff --git a/arch/x86/kernel/paravirt-spinlocks.c b/arch/x86/kernel/paravirt-spinlocks.c index 4251c1d..0883c48 100644 --- a/arch/x86/kernel/paravirt-spinlocks.c +++ b/arch/x86/kernel/paravirt-spinlocks.c @@ -15,3 +15,4 @@ struct pv_lock_ops pv_lock_ops = { }; EXPORT_SYMBOL(pv_lock_ops); + diff --git a/arch/x86/xen/spinlock.c b/arch/x86/xen/spinlock.c index 7a04950..c939723 100644 --- a/arch/x86/xen/spinlock.c +++ b/arch/x86/xen/spinlock.c @@ -124,6 +124,10 @@ static void xen_lock_spinning(struct arch_spinlock *lock, __ticket_t want) /* Only check lock once pending cleared */ barrier(); + /* Mark entry to slowpath before doing the pickup test to make + sure we don't deadlock with an unlocker. */ + __ticket_enter_slowpath(lock); + /* check again make sure it didn't become free while we weren't looking */ if (ACCESS_ONCE(lock->tickets.head) == want) { -- 1.7.6 _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel From xen-devel-bounces@lists.xensource.com Fri Sep 02 20:50:02 2011 Return-path: Envelope-to: www-data@lists.xensource.com Delivery-date: Fri, 02 Sep 2011 20:50:02 -0700 Received: from localhost ([127.0.0.1] helo=lists.colo.xensource.com) by lists.xensource.com with esmtp (Exim 4.43) id 1QzhF3-0001Bn-VP; Fri, 02 Sep 2011 20:50:02 -0700 Received: from mail216.messagelabs.com ([85.158.143.99]) by lists.xensource.com with smtp (Exim 4.43) id 1QzhEB-0000zC-4n for xen-devel@lists.xensource.com; Fri, 02 Sep 2011 20:49:08 -0700 X-Env-Sender: Ian.Jackson@eu.citrix.com X-Msg-Ref: server-4.tower-216.messagelabs.com!1315021744!16886678!1 X-Originating-IP: [62.200.22.115] X-StarScan-Version: 6.3.6; banners=-,-,- X-VirusChecked: Checked Received: (qmail 12810 invoked from network); 3 Sep 2011 03:49:04 -0000 Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115) by server-4.tower-216.messagelabs.com with SMTP; 3 Sep 2011 03:49:04 -0000 X-IronPort-AV: E=Sophos;i="4.68,323,1312156800"; d="scan'208";a="7584595" Received: from lonpmailmx01.citrite.net ([10.30.203.162]) by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5; 03 Sep 2011 03:49:03 +0000 Received: from woking.xci-test.com (10.80.248.135) by smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id 8.3.137.0; Sat, 3 Sep 2011 04:49:04 +0100 Received: from osstest by woking.xci-test.com with local (Exim 4.69) (envelope-from ) id 1QzhE7-0002Mq-8l; Sat, 03 Sep 2011 04:49:03 +0100 To: xen-devel@lists.xensource.com Message-ID: From: xen.org Date: Sat, 3 Sep 2011 04:49:03 +0100 MIME-Version: 1.0 Content-Type: text/plain Cc: ian.jackson@eu.citrix.com Subject: [Xen-devel] [xen-unstable test] 8827: trouble: broken/fail/pass X-BeenThere: xen-devel@lists.xensource.com X-Mailman-Version: 2.1.5 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xensource.com Errors-To: xen-devel-bounces@lists.xensource.com flight 8827 xen-unstable real [real] http://www.chiark.greenend.org.uk/~xensrcts/logs/8827/ Failures and problems with tests :-( Tests which did not succeed and are blocking: test-amd64-amd64-xl 3 host-install(3) broken Tests which are failing intermittently (not blocking): test-amd64-amd64-xl-sedf 14 guest-localmigrate/x10 fail pass in 8826 test-amd64-i386-xl-win-vcpus1 12 guest-localmigrate/x10 fail pass in 8826 test-i386-i386-win 14 guest-start.2 fail pass in 8826 Tests which did not succeed, but are not blocking, including regressions (tests previously passed) regarded as allowable: test-amd64-amd64-xl-pcipt-intel 9 guest-start fail never pass test-amd64-i386-rhel6hvm-intel 9 guest-start.2 fail never pass test-amd64-i386-win-vcpus1 16 leak-check/check fail never pass test-amd64-i386-rhel6hvm-amd 9 guest-start.2 fail never pass test-amd64-i386-win 16 leak-check/check fail never pass test-amd64-amd64-win 16 leak-check/check fail never pass test-amd64-amd64-xl-win 13 guest-stop fail never pass test-i386-i386-xl-win 13 guest-stop fail never pass test-amd64-i386-xl-win-vcpus1 13 guest-stop fail in 8826 never pass test-i386-i386-win 16 leak-check/check fail in 8826 never pass version targeted for testing: xen f1349a968a5a baseline version: xen f1349a968a5a jobs: build-amd64 pass build-i386 pass build-amd64-oldkern pass build-i386-oldkern pass build-amd64-pvops pass build-i386-pvops pass test-amd64-amd64-xl broken test-amd64-i386-xl pass test-i386-i386-xl pass test-amd64-i386-rhel6hvm-amd fail test-amd64-i386-xl-credit2 pass test-amd64-amd64-xl-pcipt-intel fail test-amd64-i386-rhel6hvm-intel fail test-amd64-i386-xl-multivcpu pass test-amd64-amd64-pair pass test-amd64-i386-pair pass test-i386-i386-pair pass test-amd64-amd64-pv pass test-amd64-i386-pv pass test-i386-i386-pv pass test-amd64-amd64-xl-sedf fail test-amd64-i386-win-vcpus1 fail test-amd64-i386-xl-win-vcpus1 fail test-amd64-amd64-win fail test-amd64-i386-win fail test-i386-i386-win fail test-amd64-amd64-xl-win fail test-i386-i386-xl-win fail ------------------------------------------------------------ sg-report-flight on woking.cam.xci-test.com logs: /home/xc_osstest/logs images: /home/xc_osstest/images Logs, config files, etc. are available at http://www.chiark.greenend.org.uk/~xensrcts/logs Test harness code can be found at http://xenbits.xensource.com/gitweb?p=osstest.git;a=summary Published tested tree is already up to date. _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel From xen-devel-bounces@lists.xensource.com Sat Sep 03 02:26:22 2011 Return-path: Envelope-to: www-data@lists.xensource.com Delivery-date: Sat, 03 Sep 2011 02:26:22 -0700 Received: from localhost ([127.0.0.1] helo=lists.colo.xensource.com) by lists.xensource.com with esmtp (Exim 4.43) id 1QzmUX-0008Ow-RM; Sat, 03 Sep 2011 02:26:21 -0700 Received: from mail182.messagelabs.com ([85.158.139.83]) by lists.xensource.com with esmtp (Exim 4.43) id 1QzmTf-0008By-G4 for Xen-devel@lists.xensource.com; Sat, 03 Sep 2011 02:25:27 -0700 X-Env-Sender: mkjinesh@gmail.com X-Msg-Ref: server-3.tower-182.messagelabs.com!1315041923!14099346!1 X-Originating-IP: [209.85.220.171] X-StarScan-Version: 6.3.6; banners=-,-,- X-VirusChecked: Checked Received: (qmail 11547 invoked from network); 3 Sep 2011 09:25:24 -0000 Received: from mail-vx0-f171.google.com (HELO mail-vx0-f171.google.com) (209.85.220.171) by server-3.tower-182.messagelabs.com with RC4-SHA encrypted SMTP; 3 Sep 2011 09:25:24 -0000 Received: by vxh2 with SMTP id 2so404219vxh.30 for ; Sat, 03 Sep 2011 02:25:23 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:from:date:message-id:subject:to:content-type; bh=BGQvqWChzDg4w0Fql48p9428JF+89RHDbhoGSELPBH0=; b=hSTq4CHmaMNPHdOSvARMMAacndKemU8w+p9yvJjv+f0daq8wUSdK1udniLuZ1ZkmGy 0XToZXpdWGDuzAOX0MIlqebI/9zVymheC6PSNJDTafmY2/L9XhpbmrgnAlVwkrDRqBhM U+zm16ZUl1pVTlMloJuYUFJDqTW8zCMeOYnGQ= Received: by 10.52.92.233 with SMTP id cp9mr1974122vdb.513.1315041923046; Sat, 03 Sep 2011 02:25:23 -0700 (PDT) MIME-Version: 1.0 Received: by 10.52.107.195 with HTTP; Sat, 3 Sep 2011 02:25:03 -0700 (PDT) From: "Jinesh M.K" Date: Sat, 3 Sep 2011 14:55:03 +0530 Message-ID: To: Xen-devel@lists.xensource.com Cc: Subject: [Xen-devel] Memory location of Vm X-BeenThere: xen-devel@lists.xensource.com X-Mailman-Version: 2.1.5 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0143130221==" Sender: xen-devel-bounces@lists.xensource.com Errors-To: xen-devel-bounces@lists.xensource.com --===============0143130221== Content-Type: multipart/alternative; boundary=20cf307f3a66b01bc604ac060eeb --20cf307f3a66b01bc604ac060eeb Content-Type: text/plain; charset=ISO-8859-1 HAi, how to identify the memory location of each vm (start and end location)from dom0? Thanks in advance Thanking you, Jinesh --20cf307f3a66b01bc604ac060eeb Content-Type: text/html; charset=ISO-8859-1 HAi,
how to identify the memory location of each vm (start and end location)from dom0?

Thanks in advance

Thanking you,
Jinesh
--20cf307f3a66b01bc604ac060eeb-- --===============0143130221== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel --===============0143130221==-- From xen-devel-bounces@lists.xensource.com Sat Sep 03 03:28:13 2011 Return-path: Envelope-to: www-data@lists.xensource.com Delivery-date: Sat, 03 Sep 2011 03:28:13 -0700 Received: from localhost ([127.0.0.1] helo=lists.colo.xensource.com) by lists.xensource.com with esmtp (Exim 4.43) id 1QznSP-0001Z3-PV; Sat, 03 Sep 2011 03:28:13 -0700 Received: from mail182.messagelabs.com ([85.158.139.83]) by lists.xensource.com with smtp (Exim 4.43) id 1QznRb-0001MM-LK for xen-devel@lists.xensource.com; Sat, 03 Sep 2011 03:27:25 -0700 X-Env-Sender: Ian.Campbell@eu.citrix.com X-Msg-Ref: server-9.tower-182.messagelabs.com!1315045640!16890971!1 X-Originating-IP: [62.200.22.115] X-StarScan-Version: 6.3.6; banners=-,-,- X-VirusChecked: Checked Received: (qmail 29445 invoked from network); 3 Sep 2011 10:27:20 -0000 Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115) by server-9.tower-182.messagelabs.com with SMTP; 3 Sep 2011 10:27:20 -0000 X-IronPort-AV: E=Sophos;i="4.68,324,1312156800"; d="scan'208";a="7586337" Received: from lonpmailmx01.citrite.net ([10.30.203.162]) by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5; 03 Sep 2011 10:27:20 +0000 Received: from [127.0.0.1] (10.80.16.67) by smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id 8.3.137.0; Sat, 3 Sep 2011 11:27:20 +0100 Subject: Re: [Xen-devel] Kernel bug from 3.0 (was phy disks and vifs timing out in DomU) From: Ian Campbell To: Jeremy Fitzhardinge In-Reply-To: <4E613BEF.30908@goop.org> References: <4E31820C.5030200@overnetdata.com> <1311870512.24408.153.camel@cthulhu.hellion.org.uk> <4E3266DE.9000606@overnetdata.com> <20110803152841.GA2860@dumpdata.com> <4E4E3957.1040007@overnetdata.com> <20110819125615.GA26558@dumpdata.com> <4E56B132.9050708@overnetdata.com> <20110826142606.GA25511@dumpdata.com> <20110826144438.GA24836@dumpdata.com> <4E5E6843.7050206@citrix.com> <20110831170711.GB13642@dumpdata.com> <1314862972.28989.74.camel@zakaz.uk.xensource.com> <4E5FC197.7040004@goop.org> <1314904905.19389.28.camel@dagon.hellion.org.uk> <4E5FEC71.4090504@goop.org> <1314947875.28989.155.camel@zakaz.uk.xensource.com> <4E613BEF.30908@goop.org> Content-Type: text/plain; charset="ISO-8859-1" Organization: Citrix Systems, Inc. Date: Sat, 3 Sep 2011 11:27:19 +0100 Message-ID: <1315045639.19389.1683.camel@dagon.hellion.org.uk> MIME-Version: 1.0 X-Mailer: Evolution 2.32.3 Content-Transfer-Encoding: 7bit Cc: "xen-devel@lists.xensource.com" , Keir Fraser , Anthony Wright , Konrad Rzeszutek Wilk , David Vrabel , Todd Deshane X-BeenThere: xen-devel@lists.xensource.com X-Mailman-Version: 2.1.5 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xensource.com Errors-To: xen-devel-bounces@lists.xensource.com On Fri, 2011-09-02 at 21:26 +0100, Jeremy Fitzhardinge wrote: > On 09/02/2011 12:17 AM, Ian Campbell wrote: > > On Thu, 2011-09-01 at 21:34 +0100, Jeremy Fitzhardinge wrote: > >> On 09/01/2011 12:21 PM, Ian Campbell wrote: > >>> On Thu, 2011-09-01 at 18:32 +0100, Jeremy Fitzhardinge wrote: > >>>> On 09/01/2011 12:42 AM, Ian Campbell wrote: > >>>>> On Wed, 2011-08-31 at 18:07 +0100, Konrad Rzeszutek Wilk wrote: > >>>>>> On Wed, Aug 31, 2011 at 05:58:43PM +0100, David Vrabel wrote: > >>>>>>> On 26/08/11 15:44, Konrad Rzeszutek Wilk wrote: > >>>>>>>> So while I am still looking at the hypervisor code to figure out why > >>>>>>>> it would give me [when trying to map a grant page]: > >>>>>>>> > >>>>>>>> (XEN) mm.c:3846:d0 Could not find L1 PTE for address fbb42000 > >>>>>>> It is failing in guest_map_l1e() because the page for the vmalloc'd > >>>>>>> virtual address PTEs is not present. > >>>>>>> > >>>>>>> The test that fails is: > >>>>>>> > >>>>>>> (l2e_get_flags(l2e) & (_PAGE_PRESENT | _PAGE_PSE)) != _PAGE_PRESENT > >>>>>>> > >>>>>>> I think this is because the GNTTABOP_map_grant_ref hypercall is done > >>>>>>> when task->active_mm != &init_mm and alloc_vm_area() only adds PTEs into > >>>>>>> init_mm so when Xen looks in the page tables it doesn't find the entries > >>>>>>> because they're not there yet. > >>>>>>> > >>>>>>> Putting a call to vmalloc_sync_all() after create_vm_area() and before > >>>>>>> the hypercall makes it work for me. Classic Xen kernels used to have > >>>>>>> such a call. > >>>>>> That sounds quite reasonable. > >>>>> I was wondering why upstream was missing the vmalloc_sync_all() in > >>>>> alloc_vm_area() since the out-of-tree kernels did have it and the > >>>>> function was added by us. I found this: > >>>>> http://git.kernel.org/?p=linux/kernel/git/torvalds/linux.git;a=commitdiff;h=ef691947d8a3d479e67652312783aedcf629320a > >>>>> > >>>>> commit ef691947d8a3d479e67652312783aedcf629320a > >>>>> Author: Jeremy Fitzhardinge > >>>>> Date: Wed Dec 1 15:45:48 2010 -0800 > >>>>> > >>>>> vmalloc: remove vmalloc_sync_all() from alloc_vm_area() > >>>>> > >>>>> There's no need for it: it will get faulted into the current pagetable > >>>>> as needed. > >>>>> > >>>>> Signed-off-by: Jeremy Fitzhardinge > >>>>> > >>>>> The flaw in the reasoning here is that you cannot take a kernel fault > >>>>> while processing a hypercall, so hypercall arguments must have been > >>>>> faulted in beforehand and that is what the sync_all was for. > >>>> That's a good point. (Maybe Xen should have generated pagefaults when > >>>> hypercall arg pointers are bad...) > >>> I think it would be a bit tricky to do in practice, you'd either have to > >>> support recursive hypercalls in the middle of other hypercalls (because > >>> the page fault handler is surely going to want to do some) or proper > >>> hypercall restart (so you can fully return to guest context to handle > >>> the fault then retry) or something along those and complexifying up the > >>> hypervisor one way or another. Probably not impossible if you were > >>> building something form the ground up, but not trivial. > >> Well, Xen already has the continuation machinery for dealing with > >> hypercall restart, so that could be reused. > > That requires special support beyond just calling the continuation in > > each hypercall (often extending into the ABI) for pickling progress and > > picking it up again, only a small number of (usually long running) > > hypercalls have that support today. It also uses the guest context to > > store the state which perhaps isn't helpful if you want to return to the > > guest, although I suppose building a nested frame would work. > > I guess it depends on how many hypercalls do work before touching guest > memory, but any hypercall should be like that anyway, or at least be > able to wind back work done if a later read EFAULTs. > > I was vaguely speculating about a scheme on the lines of: > > 1. In copy_to/from_user, if we touch a bad address, save it in a > per-vcpu "bad_guest_addr" > 2. when returning to the guest, if the errno is EFAULT and > bad_guest_addr is set, then generate a memory fault frame with cr2 = > bad_guest_addr, and with the exception return restarting the hypercall > > Perhaps there should be a EFAULT_RETRY error return to trigger this > behaviour, rather than doing it for all EFAULTs, so the faulting > behaviour can be added incrementally. The kernel uses -ERESTARTSSYS for something similar, doesn't it? Does this scheme work if the hypercall causing the exception was itself runnnig in an exception handler? I guess it depends on the architecture +OSes handling of nested faults. > Maybe this is a lost cause for x86, but perhaps its worth considering > for new ports? Certainly worth thinking about. > > The guys doing paging and sharing etc looked into this and came to the > > conclusion that it would be intractably difficult to do this fully -- > > hence we now have the ability to sleep in hypercalls, which works > > because the pager/sharer is in a different domain/vcpu. > > Hmm. Were they looking at injecting faults back into the guest, or > forwarding "missing page" events off to another domain? Sharing and swapping are transparent to the domain, another domain runs the swapper/unshare process (actually, unshare might be in the h/v itself, not sure). > >> And accesses to guest > >> memory are already special events which must be checked so that EFAULT > >> can be returned. If, rather than failing with EFAULT Xen set up a > >> pagefault exception for the guest CPU with the return set up to retry > >> the hypercall, it should all work... > >> > >> Of course, if the guest isn't expecting that - or its buggy - then it > >> could end up in an infinite loop. But maybe a flag (set a high bit in > >> the hypercall number?), or a feature, or something? Might be worthwhile > >> if it saves guests having to do something expensive (like a > >> vmalloc_sync_all), even if they have to also deal with old hypervisors. > > The vmalloc_sync_all is a pretty event even on Xen though, isn't it? > > Looks like an important word is missing there. But its very expensive, > if that's what you're saying. Oops. "rare" was the missing word. > > J _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel From xen-devel-bounces@lists.xensource.com Sat Sep 03 05:00:08 2011 Return-path: Envelope-to: www-data@lists.xensource.com Delivery-date: Sat, 03 Sep 2011 05:00:08 -0700 Received: from localhost ([127.0.0.1] helo=lists.colo.xensource.com) by lists.xensource.com with esmtp (Exim 4.43) id 1QzotL-00040O-Hp; Sat, 03 Sep 2011 05:00:07 -0700 Received: from mail174.messagelabs.com ([85.158.138.51]) by lists.xensource.com with esmtp (Exim 4.43) id 1QzosI-0003nB-PY for Xen-devel@lists.xensource.com; Sat, 03 Sep 2011 04:59:03 -0700 X-Env-Sender: olaf@aepfle.de X-Msg-Ref: server-9.tower-174.messagelabs.com!1315051139!24069345!1 X-Originating-IP: [81.169.146.162] X-StarScan-Version: 6.3.6; banners=-,-,- X-VirusChecked: Checked Received: (qmail 2776 invoked from network); 3 Sep 2011 11:58:59 -0000 Received: from mo-p00-ob.rzone.de (HELO mo-p00-ob.rzone.de) (81.169.146.162) by server-9.tower-174.messagelabs.com with DHE-RSA-AES256-SHA encrypted SMTP; 3 Sep 2011 11:58:59 -0000 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; t=1315051139; l=803; s=domk; d=aepfle.de; h=In-Reply-To:Content-Transfer-Encoding:Content-Type:MIME-Version: References:Subject:To:From:Date:X-RZG-CLASS-ID:X-RZG-AUTH; bh=t7MrY+v0TVIplgLj1ADefduyE+w=; b=DMPRJtX6OYLEk1fXh1sKUR2g5DfdIoMwCw5L4yOM36TvA/FuavfU1LwpjiXzJhCBHJI e9LZd8Squ83mjTnGRAhTdZWkgZwof8Docmy0QusN1weMgl/Vj4bLOcJH2Dnv+DanS3suf QSF2ByKyvWSa5jUd6dFXh4zrUz0yLMVK0b4= X-RZG-AUTH: :P2EQZWCpfu+qG7CngxMFH1J+zrwiavkK6tmQaLfmztM8TOFPjDYQGuW8 X-RZG-CLASS-ID: mo00 Received: from probook.site (dslb-088-065-125-090.pools.arcor-ip.net [88.65.125.90]) by smtp.strato.de (jimi mo54) (RZmta 26.6) with (DHE-RSA-AES256-SHA encrypted) ESMTPA id N01fc5n83Bo0A3 ; Sat, 3 Sep 2011 13:58:43 +0200 (MEST) Received: by probook.site (Postfix, from userid 1000) id 9299D18B65; Sat, 3 Sep 2011 13:58:42 +0200 (CEST) Date: Sat, 3 Sep 2011 13:58:42 +0200 From: Olaf Hering To: Farshid Abediny , Xen-devel@lists.xensource.com Subject: Re: [Xen-devel] read mac in vif-bridge Message-ID: <20110903115842.GA11981@aepfle.de> References: <20110830131806.GO32373@reaktio.net> <20110830132316.GA19098@aepfle.de> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: User-Agent: Mutt/1.5.21.rev5535 (2011-07-01) Cc: X-BeenThere: xen-devel@lists.xensource.com X-Mailman-Version: 2.1.5 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xensource.com Errors-To: xen-devel-bounces@lists.xensource.com On Sat, Sep 03, Farshid Abediny wrote: > Hello Olaf, > but in that file did not put correct mac it is like : e:ff:ff:ff:ff:ff Does 'ip a' or 'ifconfig -a' show a different MAC address for your interface? Olaf > On Tue, Aug 30, 2011 at 5:53 PM, Olaf Hering wrote: > > On Tue, Aug 30, Pasi Kärkkäinen wrote: > > > On Tue, Aug 30, 2011 at 03:14:40PM +0430, Farshid Hajizeinalabedin wrote: > > >    Hello, > > >    i need read mac address in /etc/xend/scripts/vif-bridge but in this > file i > > >    can only read ip and vif how can i read mac address on this file? > > >    thanks, > > > > Well, you know the vif name, so use "ifconfig" or "ip" commands to get > the mac? > > Its provided in the /sys/class/net/${vif}/address file. > > Olaf > > _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel From xen-devel-bounces@lists.xensource.com Sat Sep 03 05:13:23 2011 Return-path: Envelope-to: www-data@lists.xensource.com Delivery-date: Sat, 03 Sep 2011 05:13:23 -0700 Received: from localhost ([127.0.0.1] helo=lists.colo.xensource.com) by lists.xensource.com with esmtp (Exim 4.43) id 1Qzp6B-0004YY-GY; Sat, 03 Sep 2011 05:13:23 -0700 Received: from mail21.messagelabs.com ([85.158.143.35]) by lists.xensource.com with esmtp (Exim 4.43) id 1Qzp5Y-0004Lw-TR for Xen-devel@lists.xensource.com; Sat, 03 Sep 2011 05:12:45 -0700 X-Env-Sender: olaf@aepfle.de X-Msg-Ref: server-2.tower-21.messagelabs.com!1315051961!32705010!1 X-Originating-IP: [81.169.146.160] X-StarScan-Version: 6.3.6; banners=-,-,- X-VirusChecked: Checked Received: (qmail 15596 invoked from network); 3 Sep 2011 12:12:41 -0000 Received: from mo-p00-ob.rzone.de (HELO mo-p00-ob.rzone.de) (81.169.146.160) by server-2.tower-21.messagelabs.com with EDH-RSA-DES-CBC3-SHA encrypted SMTP; 3 Sep 2011 12:12:41 -0000 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; t=1315051961; l=338; s=domk; d=aepfle.de; h=In-Reply-To:Content-Type:MIME-Version:References:Subject:To:From: Date:X-RZG-CLASS-ID:X-RZG-AUTH; bh=oWqM2MgdeyZiwMmaTiog1bzEoas=; b=USk8UjzhyrXPvcANtFGj5KXiRAAdXbZZAxKtqTr3M24kfepnNxShuG1C/Ii5XCqcC02 Mg3U0b2GShIVJQnz7qGvGL8ElmluRIm7s1jvs4Cb3D6nmKKIvwPLJtHe8BfLfyOwy0nwB sDzVHVNcyHbi8sCuaNXawFmXmLhHXtUl8V0= X-RZG-AUTH: :P2EQZWCpfu+qG7CngxMFH1J+zrwiavkK6tmQaLfmztM8TOFPjDYQGuW8 X-RZG-CLASS-ID: mo00 Received: from probook.site (dslb-088-065-125-090.pools.arcor-ip.net [88.65.125.90]) by post.strato.de (mrclete mo51) (RZmta 26.6) with (EDH-RSA-DES-CBC3-SHA encrypted) ESMTPA id a03359n83C6JU1 ; Sat, 3 Sep 2011 14:12:38 +0200 (MEST) Received: by probook.site (Postfix, from userid 1000) id 589C918B65; Sat, 3 Sep 2011 14:12:38 +0200 (CEST) Date: Sat, 3 Sep 2011 14:12:38 +0200 From: Olaf Hering To: Farshid Abediny , Xen-devel@lists.xensource.com Subject: Re: [Xen-devel] read mac in vif-bridge Message-ID: <20110903121238.GA18113@aepfle.de> References: <20110830131806.GO32373@reaktio.net> <20110830132316.GA19098@aepfle.de> <20110903115842.GA11981@aepfle.de> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.21.rev5535 (2011-07-01) Cc: X-BeenThere: xen-devel@lists.xensource.com X-Mailman-Version: 2.1.5 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xensource.com Errors-To: xen-devel-bounces@lists.xensource.com On Sat, Sep 03, Farshid Abediny wrote: > Hello, > yes it is, > and also i am using solusvm (solusvm.com) > can you guide me how can i find mac ? Please keep Xen-devel@lists.xensource.com in cc list. Please post the output from your systems. 'ip a' and 'head /sys/class/net/*/address ' from dom0 and from the domU. Olaf _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel From xen-devel-bounces@lists.xensource.com Sat Sep 03 05:24:21 2011 Return-path: Envelope-to: www-data@lists.xensource.com Delivery-date: Sat, 03 Sep 2011 05:24:21 -0700 Received: from localhost ([127.0.0.1] helo=lists.colo.xensource.com) by lists.xensource.com with esmtp (Exim 4.43) id 1QzpGn-00054l-Hd; Sat, 03 Sep 2011 05:24:21 -0700 Received: from mail182.messagelabs.com ([85.158.139.83]) by lists.xensource.com with smtp (Exim 4.43) id 1QzpFr-0004sA-Mg for Xen-devel@lists.xensource.com; Sat, 03 Sep 2011 05:23:24 -0700 X-Env-Sender: Ian.Campbell@eu.citrix.com X-Msg-Ref: server-7.tower-182.messagelabs.com!1315052600!11896753!1 X-Originating-IP: [62.200.22.115] X-StarScan-Version: 6.3.6; banners=-,-,- X-VirusChecked: Checked Received: (qmail 10477 invoked from network); 3 Sep 2011 12:23:20 -0000 Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115) by server-7.tower-182.messagelabs.com with SMTP; 3 Sep 2011 12:23:20 -0000 X-IronPort-AV: E=Sophos;i="4.68,324,1312156800"; d="scan'208";a="7587148" Received: from lonpmailmx01.citrite.net ([10.30.203.162]) by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5; 03 Sep 2011 12:23:20 +0000 Received: from [127.0.0.1] (10.80.16.67) by smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id 8.3.137.0; Sat, 3 Sep 2011 13:23:20 +0100 Subject: Re: [Xen-devel] read mac in vif-bridge From: Ian Campbell To: Olaf Hering In-Reply-To: <20110903121238.GA18113@aepfle.de> References: <20110830131806.GO32373@reaktio.net> <20110830132316.GA19098@aepfle.de> <20110903115842.GA11981@aepfle.de> <20110903121238.GA18113@aepfle.de> Content-Type: text/plain; charset="ISO-8859-1" Organization: Citrix Systems, Inc. Date: Sat, 3 Sep 2011 13:23:19 +0100 Message-ID: <1315052599.5182.2.camel@dagon.hellion.org.uk> MIME-Version: 1.0 X-Mailer: Evolution 2.32.3 Content-Transfer-Encoding: 7bit Cc: "Xen-devel@lists.xensource.com" , Farshid Abediny X-BeenThere: xen-devel@lists.xensource.com X-Mailman-Version: 2.1.5 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xensource.com Errors-To: xen-devel-bounces@lists.xensource.com On Sat, 2011-09-03 at 13:12 +0100, Olaf Hering wrote: > On Sat, Sep 03, Farshid Abediny wrote: > > > Hello, > > yes it is, > > and also i am using solusvm (solusvm.com) > > can you guide me how can i find mac ? > > Please keep Xen-devel@lists.xensource.com in cc list. > > Please post the output from your systems. > 'ip a' and 'head /sys/class/net/*/address ' from dom0 and from the domU. The mac address of a vifX.Y device in dom0 is almost always fe:ff:ff:ff:ff. This is the largest valid MAC address and is chosen because the bridge will take on the lowest MAC of all it's ports under some circumstances so using fe:..... ensures it is never the MAC of a VIF. Presumably the original poster wants the MAC of the ethX device within the guest? /etc/xen/scripts/vif-nat has an example of how to do this: # grep mac /etc/xen/scripts/vif* /etc/xen/scripts/vif-nat: mac=$(xenstore_read "$XENBUS_PATH/mac") Ian. _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel From xen-devel-bounces@lists.xensource.com Sat Sep 03 20:06:30 2011 Return-path: Envelope-to: www-data@lists.xensource.com Delivery-date: Sat, 03 Sep 2011 20:06:30 -0700 Received: from localhost ([127.0.0.1] helo=lists.colo.xensource.com) by lists.xensource.com with esmtp (Exim 4.43) id 1R032T-0005R8-WE; Sat, 03 Sep 2011 20:06:30 -0700 Received: from mail21.messagelabs.com ([85.158.143.35]) by lists.xensource.com with smtp (Exim 4.43) id 1QzWmS-0005Xs-1h for xen-devel@lists.xensource.com; Fri, 02 Sep 2011 09:39:49 -0700 X-Env-Sender: vincent.r.scarlata@intel.com X-Msg-Ref: server-7.tower-21.messagelabs.com!1314981555!53404748!1 X-Originating-IP: [134.134.136.20] X-StarScan-Version: 6.3.6; banners=-,-,- X-VirusChecked: Checked Received: (qmail 29810 invoked from network); 2 Sep 2011 16:39:15 -0000 Received: from mga02.intel.com (HELO mga02.intel.com) (134.134.136.20) by server-7.tower-21.messagelabs.com with SMTP; 2 Sep 2011 16:39:15 -0000 Received: from orsmga001.jf.intel.com ([10.7.209.18]) by orsmga101.jf.intel.com with ESMTP; 02 Sep 2011 09:39:42 -0700 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="4.67,352,1309762800"; d="p7s'?scan'208";a="44776490" Received: from orsmsx602.amr.corp.intel.com ([10.22.226.211]) by orsmga001.jf.intel.com with ESMTP; 02 Sep 2011 09:39:42 -0700 Received: from orsmsx105.amr.corp.intel.com (10.22.225.132) by orsmsx602.amr.corp.intel.com (10.22.226.211) with Microsoft SMTP Server (TLS) id 8.2.255.0; Fri, 2 Sep 2011 09:39:42 -0700 Received: from orsmsx101.amr.corp.intel.com ([169.254.8.19]) by ORSMSX105.amr.corp.intel.com ([169.254.4.165]) with mapi id 14.01.0323.003; Fri, 2 Sep 2011 09:39:42 -0700 From: "Scarlata, Vincent R" To: Winai Wongthai , "xen-devel@lists.xensource.com" Subject: RE: [Xen-devel] Questions about the GVTPM framework Thread-Topic: [Xen-devel] Questions about the GVTPM framework Thread-Index: AQHMZ3m4cFpa6W5Rkki8JQ7o9rDpY5U6Tf9Q Date: Fri, 2 Sep 2011 16:39:41 +0000 Message-ID: <123657B31765C64CB9BC722F4EE9C3DA16E9D8B1@ORSMSX101.amr.corp.intel.com> References: <1314744792065-4752119.post@n5.nabble.com> In-Reply-To: <1314744792065-4752119.post@n5.nabble.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: x-originating-ip: [10.22.254.138] MIME-Version: 1.0 X-Mailman-Approved-At: Sat, 03 Sep 2011 20:05:53 -0700 Cc: X-BeenThere: xen-devel@lists.xensource.com X-Mailman-Version: 2.1.5 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0497532364==" Sender: xen-devel-bounces@lists.xensource.com Errors-To: xen-devel-bounces@lists.xensource.com --===============0497532364== Content-Language: en-US Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=SHA1; boundary="----=_NextPart_000_013D_01CC6954.3D24E820" ------=_NextPart_000_013D_01CC6954.3D24E820 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit There is a "Proof of Concept" implementation in Xen at tools/{vtpm, vtpm_manager}. To the best of my knowledge it has not been maintained for quite some time. It did not support migration as described in the paper. -Vinnie -----Original Message----- From: xen-devel-bounces@lists.xensource.com [mailto:xen-devel-bounces@lists.xensource.com] On Behalf Of Winai Wongthai Sent: Tuesday, August 30, 2011 03:53 PM To: xen-devel@lists.xensource.com Subject: [Xen-devel] Questions about the GVTPM framework Hi all, I would like to ask several questions about the GVTPM framework in this paper(TPM Virtualization: Building a General Framework , http://www.springerlink.com/content/qg78864080t57306/). Is there an open-source and concrete implementation of the framework? Is this framework support vTPM instance migration? Best Regards, Winai -- View this message in context: http://xen.1045712.n5.nabble.com/Questions-about-the-GVTPM-framework-tp47521 19p4752119.html Sent from the Xen - Dev mailing list archive at Nabble.com. _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel ------=_NextPart_000_013D_01CC6954.3D24E820 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIYiDCCAyAw ggKJoAMCAQICBDXe9M8wDQYJKoZIhvcNAQEFBQAwTjELMAkGA1UEBhMCVVMxEDAOBgNVBAoTB0Vx dWlmYXgxLTArBgNVBAsTJEVxdWlmYXggU2VjdXJlIENlcnRpZmljYXRlIEF1dGhvcml0eTAeFw05 ODA4MjIxNjQxNTFaFw0xODA4MjIxNjQxNTFaME4xCzAJBgNVBAYTAlVTMRAwDgYDVQQKEwdFcXVp ZmF4MS0wKwYDVQQLEyRFcXVpZmF4IFNlY3VyZSBDZXJ0aWZpY2F0ZSBBdXRob3JpdHkwgZ8wDQYJ KoZIhvcNAQEBBQADgY0AMIGJAoGBAMFdsVhnCGLuoJotHwhtkRRomAoe/toEbxOEYiHD0XzOnwXg uAHwTjTs4oqVBGSs8WtTXwWzy2eAv0ICjv7dAQns4QAUT/z78AzdQ7pbK+EfgHCZFVeTFvEPl2q3 wmgjHMxNWTCsUR47ryvW7mNFe8XZX1DS41APOojnvxT94Me5AgMBAAGjggEJMIIBBTBwBgNVHR8E aTBnMGWgY6BhpF8wXTELMAkGA1UEBhMCVVMxEDAOBgNVBAoTB0VxdWlmYXgxLTArBgNVBAsTJEVx dWlmYXggU2VjdXJlIENlcnRpZmljYXRlIEF1dGhvcml0eTENMAsGA1UEAxMEQ1JMMTAaBgNVHRAE EzARgQ8yMDE4MDgyMjE2NDE1MVowCwYDVR0PBAQDAgEGMB8GA1UdIwQYMBaAFEjmaPkr0rKV10fY IyAQTzOYkJ/UMB0GA1UdDgQWBBRI5mj5K9KylddH2CMgEE8zmJCf1DAMBgNVHRMEBTADAQH/MBoG CSqGSIb2fQdBAAQNMAsbBVYzLjBjAwIGwDANBgkqhkiG9w0BAQUFAAOBgQBYzinq/Pfetc4CuRe1 hdG54+CVzCUxDQCmkm5/tpJjnlCV0Zpv5BHeY4VumO6o/1rI01WyZnFX3sAh6z0qpyNJAQSGQnv8 7n+iFlK1Z2fTQNs7JliyKHc9rhR3Ydb6KmYnoA36p3Nc6nDxlCFlRF/6/O8paKmih3nvee9PrAd3 ODCCAz0wggKmoAMCAQICAwWw/zANBgkqhkiG9w0BAQUFADBOMQswCQYDVQQGEwJVUzEQMA4GA1UE ChMHRXF1aWZheDEtMCsGA1UECxMkRXF1aWZheCBTZWN1cmUgQ2VydGlmaWNhdGUgQXV0aG9yaXR5 MB4XDTA2MDIxNjE4MDEzMFoXDTE2MDIxOTE4MDEzMFowUjELMAkGA1UEBhMCVVMxGjAYBgNVBAoT EUludGVsIENvcnBvcmF0aW9uMScwJQYDVQQDEx5JbnRlbCBFeHRlcm5hbCBCYXNpYyBQb2xpY3kg Q0EwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQDBpd/XOb9QVqEZ8mQ1042TdOIq3ATD IsV2xDyt30yLyMR5Wjtus0bn3B+he89BiNO/LP6+rFzEwlD55PlX+HLGIKeNNG97dqyc30FElEUj ZzTZFq2N4e3kVJ/XAEEgANzV8v9qp7qWwxugPgfc3z9BkYot+CifozexHLb/hEZj+yISCU61kRZv uSQ0E11yYL4dRgcglJeaHo3oX57rvIckaLsYV5/1Aj+R8DM1Ppk965XQAKsHfnyT7C4S50T4lVn4 lz36wOdNZn/zegG1zp41lnoTFfT4KuKVJH5x7YD1p6KbgJCKLovnujGuohquBNfdXKpZkvz6pGv+ iC1HawJdAgMBAAGjgaAwgZ0wDgYDVR0PAQH/BAQDAgEGMB0GA1UdDgQWBBQaxgxKxEdvqNutK/D0 Vgaj7TdUDDA6BgNVHR8EMzAxMC+gLaArhilodHRwOi8vY3JsLmdlb3RydXN0LmNvbS9jcmxzL3Nl Y3VyZWNhLmNybDAfBgNVHSMEGDAWgBRI5mj5K9KylddH2CMgEE8zmJCf1DAPBgNVHRMBAf8EBTAD AQH/MA0GCSqGSIb3DQEBBQUAA4GBABMQOK2kVKVIlUWwLTdywJ+e2O+PC/uQltK2F3lRyrPfBn69 tOkIP4SgDJOfsxyobIrPLe75kBLw+Dom13OBDp/EMZJZ1CglQfVV8co9mT3aZMjSGGQiMgkJLR3j Mfr900fXZKj5XeqCJ+JP0mEhJGEdVCY+FFlksJjV86fDrq1QMIIFijCCBHKgAwIBAgIKYR6AtwAA AAAABzANBgkqhkiG9w0BAQUFADBSMQswCQYDVQQGEwJVUzEaMBgGA1UEChMRSW50ZWwgQ29ycG9y YXRpb24xJzAlBgNVBAMTHkludGVsIEV4dGVybmFsIEJhc2ljIFBvbGljeSBDQTAeFw0wOTA1MTUx OTI1MTNaFw0xNTA1MTUxOTM1MTNaMFYxCzAJBgNVBAYTAlVTMRowGAYDVQQKExFJbnRlbCBDb3Jw b3JhdGlvbjErMCkGA1UEAxMiSW50ZWwgRXh0ZXJuYWwgQmFzaWMgSXNzdWluZyBDQSAzQTCCASIw DQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAMGPgGLnOO5IOzlHRfr1XfCVb97V4BR2QVpPZ7Cr cIQ+FGa2KHD/6dPjwxOIrtFTdfW4BYikdFmxUZVBWRWZ5Vye2cCdGzFWqIEOE1e17nNx1jM8Z6GZ EqbDUS+vBuPlBFHKQoVm5BaNIHpyn2XZxqwjV9j5/crIfPrCGstk+2ztUhVS8OHEgzO784PgD9pO gBnnAbZHmEM1FYYmQ6ibS+gVCHzobDYG+YReRiHpFKWBxpUuP+X0WYFw/Ja1JW7N8pELAFDw0UFB WFgiv1QIusdLvSy8mcsLJ5wy050OVcxShqoUxhw/wvyuuoQxvmEPjhRa1C2oSCmGN0003GMhQWMC AwEAAaOCAlwwggJYMA8GA1UdEwEB/wQFMAMBAf8wHQYDVR0OBBYEFKoWZq+3PVZTYK4Nwu3z7gfL UWB+MAsGA1UdDwQEAwIBhjASBgkrBgEEAYI3FQEEBQIDAQABMCMGCSsGAQQBgjcVAgQWBBTCKwhT x+hdMsKCgOmWwLgjQsAV+TAZBgkrBgEEAYI3FAIEDB4KAFMAdQBiAEMAQTAfBgNVHSMEGDAWgBQa xgxKxEdvqNutK/D0Vgaj7TdUDDCBvQYDVR0fBIG1MIGyMIGvoIGsoIGphk5odHRwOi8vd3d3Lmlu dGVsLmNvbS9yZXBvc2l0b3J5L0NSTC9JbnRlbCUyMEV4dGVybmFsJTIwQmFzaWMlMjBQb2xpY3kl MjBDQS5jcmyGV2h0dHA6Ly9jZXJ0aWZpY2F0ZXMuaW50ZWwuY29tL3JlcG9zaXRvcnkvQ1JML0lu dGVsJTIwRXh0ZXJuYWwlMjBCYXNpYyUyMFBvbGljeSUyMENBLmNybDCB4wYIKwYBBQUHAQEEgdYw gdMwYwYIKwYBBQUHMAKGV2h0dHA6Ly93d3cuaW50ZWwuY29tL3JlcG9zaXRvcnkvY2VydGlmaWNh dGVzL0ludGVsJTIwRXh0ZXJuYWwlMjBCYXNpYyUyMFBvbGljeSUyMENBLmNydDBsBggrBgEFBQcw AoZgaHR0cDovL2NlcnRpZmljYXRlcy5pbnRlbC5jb20vcmVwb3NpdG9yeS9jZXJ0aWZpY2F0ZXMv SW50ZWwlMjBFeHRlcm5hbCUyMEJhc2ljJTIwUG9saWN5JTIwQ0EuY3J0MA0GCSqGSIb3DQEBBQUA A4IBAQCUY/1d0MS6VPTlIcOho1XWh193PD5kJDJSPdphLHQdM1oKA+whMdIBoY1VzTDDK+C+Ey4J cyna7fpC8uVmn/Rz/i9MZtyc7qezPtZTn9UyORvJmddH+Ox/RycGwe3ags8jUdspECorYOkJyZks nDIlTVUvbR7wyY+gGJYqxWXqrcVFEiMsWu8/OIlf7F2gAYMBw1kZ55dn4lWBIM0WqvReWpPvhYeN 7Y+3MKEdSMkQ7TZiNbfdZ5D/8KfWNMTJ4VHltOgCL1lA5tx/F4R1920skpL5eu3Sj650RUe3rOXs aV5NyJzBwB31+1zsmleVdFD0k/Fw9HxXbAQE35ucN/7CMIIGIzCCBQugAwIBAgIKFq4u0AABAABr DDANBgkqhkiG9w0BAQUFADBWMQswCQYDVQQGEwJVUzEaMBgGA1UEChMRSW50ZWwgQ29ycG9yYXRp b24xKzApBgNVBAMTIkludGVsIEV4dGVybmFsIEJhc2ljIElzc3VpbmcgQ0EgM0EwHhcNMTEwODE3 MTgxODAxWhcNMTQwODAxMTgxODAxWjBLMRwwGgYDVQQDExNTY2FybGF0YSwgVmluY2VudCBSMSsw KQYJKoZIhvcNAQkBFhx2aW5jZW50LnIuc2NhcmxhdGFAaW50ZWwuY29tMIIBIjANBgkqhkiG9w0B AQEFAAOCAQ8AMIIBCgKCAQEA1xNzrKnuIQabroE8bGtw5NnJHHLJC6Y0larBvG1+62jj+5hwq57F NwQIp4wkADGv9mHToJ3alotd4q4HC/xQULcp11PBOZYpLZS1FClpICPro3/AHKRmZx/Quebv8IsE 6bdRZQzTP5Sb+/1yw4p4cahaj6QILrx4ZxuoqggGoIUXuwxDfdDSSKlUzYKSuNL7v4Ato4O56pHw RdD/IygPHG0+vSLba2PIJ3tKaQBiY+jXhliSSmp5idkC0xFkDSaUoUvmbCd0MTb3Lm/r7VPuZLEV vvOC836lAMxemObrHr0AW8CLb001tMIUU4tZXlsZLKRnyI7Jx2BaSWIH18O/dwIDAQABo4IC/DCC AvgwCwYDVR0PBAQDAgeAMDwGCSsGAQQBgjcVBwQvMC0GJSsGAQQBgjcVCIbDjHWEmeVRg/2BKIWO n1OCkcAJZ4HevTmV8EMCAWQCAQgwHQYDVR0OBBYEFFggJCUONhd15FN+wHchgJYlHEFiMB8GA1Ud IwQYMBaAFKoWZq+3PVZTYK4Nwu3z7gfLUWB+MIHPBgNVHR8EgccwgcQwgcGggb6ggbuGV2h0dHA6 Ly93d3cuaW50ZWwuY29tL3JlcG9zaXRvcnkvQ1JML0ludGVsJTIwRXh0ZXJuYWwlMjBCYXNpYyUy MElzc3VpbmclMjBDQSUyMDNBKDEpLmNybIZgaHR0cDovL2NlcnRpZmljYXRlcy5pbnRlbC5jb20v cmVwb3NpdG9yeS9DUkwvSW50ZWwlMjBFeHRlcm5hbCUyMEJhc2ljJTIwSXNzdWluZyUyMENBJTIw M0EoMSkuY3JsMIH1BggrBgEFBQcBAQSB6DCB5TBsBggrBgEFBQcwAoZgaHR0cDovL3d3dy5pbnRl bC5jb20vcmVwb3NpdG9yeS9jZXJ0aWZpY2F0ZXMvSW50ZWwlMjBFeHRlcm5hbCUyMEJhc2ljJTIw SXNzdWluZyUyMENBJTIwM0EoMSkuY3J0MHUGCCsGAQUFBzAChmlodHRwOi8vY2VydGlmaWNhdGVz LmludGVsLmNvbS9yZXBvc2l0b3J5L2NlcnRpZmljYXRlcy9JbnRlbCUyMEV4dGVybmFsJTIwQmFz aWMlMjBJc3N1aW5nJTIwQ0ElMjAzQSgxKS5jcnQwHwYDVR0lBBgwFgYIKwYBBQUHAwQGCisGAQQB gjcKAwwwKQYJKwYBBAGCNxUKBBwwGjAKBggrBgEFBQcDBDAMBgorBgEEAYI3CgMMMFUGA1UdEQRO MEygLAYKKwYBBAGCNxQCA6AeDBx2aW5jZW50LnIuc2NhcmxhdGFAaW50ZWwuY29tgRx2aW5jZW50 LnIuc2NhcmxhdGFAaW50ZWwuY29tMA0GCSqGSIb3DQEBBQUAA4IBAQA9jbdADW81alElgYYUjXqB ZQI8by2wKZC5GaTEH1cuzSxO+j8E39iO10v/7xscxzeUvfQJQe9Z+DeNCofihKIHOXB0Q/rg9Ax+ wKkyFvhuOUfuH4oO6Q77O1mbkS4jD45Jbfsbup+kt3vwYOIzkIhlKxiMf4JkN9Ryeh0Oc2mjEMG3 2HLwDvWQWlXP9MAbHFNaNESJ4/78GFnaG71vXg/YuveDZB6g5UJwBCshkuFc/di8Jcs1NPQbqGb3 8T0BMdhx+XssqdCNhh4moJUHMCy7MqPjoGQTkGflloNnysmT3lZFYF/2i0p9AoOxa9L4hjcdbueo mtfDeLjogl46oRYOMIIGajCCBVKgAwIBAgIKG0yYBAABAABVoTANBgkqhkiG9w0BAQUFADBWMQsw CQYDVQQGEwJVUzEaMBgGA1UEChMRSW50ZWwgQ29ycG9yYXRpb24xKzApBgNVBAMTIkludGVsIEV4 dGVybmFsIEJhc2ljIElzc3VpbmcgQ0EgM0EwHhcNMTAxMjMwMTYzMDQ2WhcNMTMxMjE0MTYzMDQ2 WjBLMRwwGgYDVQQDExNTY2FybGF0YSwgVmluY2VudCBSMSswKQYJKoZIhvcNAQkBFhx2aW5jZW50 LnIuc2NhcmxhdGFAaW50ZWwuY29tMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEArOPB 310uYWm485n3ll7uASehQHIlbvcdjTTZpnL/G0YIQg2rat1dgmjHucxH/J8yaJq24STZzrVtNVW0 eEAXjWhRIMW50gwbtXoIJe9jyyxrNwGCgkIWVj4q3BZ4BFqMcgxXYZ8XCFT2PypnnUXOfVPQc+Ji Ls6VBu7+flI60JxvC2/b2ylOzb00x331GoM/h2fZRklv3MS+ZujRmK8hX1IM6xd2iopq0zVqFlQQ VjtQ+jHhqNCwAKlJW1kbzkS6J+r2g5al5Pu5brqpluFHBHj2khHZ+LvmiVO/vjqTDqcT51y/u2Xd a6kw6uULbif9swsXHVrwMz0rBAToW5NmkwIDAQABo4IDQzCCAz8wCwYDVR0PBAQDAgQwMD0GCSsG AQQBgjcVBwQwMC4GJisGAQQBgjcVCIbDjHWEmeVRg/2BKIWOn1OCkcAJZ4S52UGHhP9OAgFkAgEM MEQGCSqGSIb3DQEJDwQ3MDUwDgYIKoZIhvcNAwICAgCAMA4GCCqGSIb3DQMEAgIAgDAHBgUrDgMC BzAKBggqhkiG9w0DBzAdBgNVHQ4EFgQUOwVB4Yk1jswZxSSIGohZMBL+AtMwHwYDVR0jBBgwFoAU qhZmr7c9VlNgrg3C7fPuB8tRYH4wgc8GA1UdHwSBxzCBxDCBwaCBvqCBu4ZXaHR0cDovL3d3dy5p bnRlbC5jb20vcmVwb3NpdG9yeS9DUkwvSW50ZWwlMjBFeHRlcm5hbCUyMEJhc2ljJTIwSXNzdWlu ZyUyMENBJTIwM0EoMSkuY3JshmBodHRwOi8vY2VydGlmaWNhdGVzLmludGVsLmNvbS9yZXBvc2l0 b3J5L0NSTC9JbnRlbCUyMEV4dGVybmFsJTIwQmFzaWMlMjBJc3N1aW5nJTIwQ0ElMjAzQSgxKS5j cmwwgfUGCCsGAQUFBwEBBIHoMIHlMGwGCCsGAQUFBzAChmBodHRwOi8vd3d3LmludGVsLmNvbS9y ZXBvc2l0b3J5L2NlcnRpZmljYXRlcy9JbnRlbCUyMEV4dGVybmFsJTIwQmFzaWMlMjBJc3N1aW5n JTIwQ0ElMjAzQSgxKS5jcnQwdQYIKwYBBQUHMAKGaWh0dHA6Ly9jZXJ0aWZpY2F0ZXMuaW50ZWwu Y29tL3JlcG9zaXRvcnkvY2VydGlmaWNhdGVzL0ludGVsJTIwRXh0ZXJuYWwlMjBCYXNpYyUyMElz c3VpbmclMjBDQSUyMDNBKDEpLmNydDAfBgNVHSUEGDAWBggrBgEFBQcDBAYKKwYBBAGCNwoDBDAp BgkrBgEEAYI3FQoEHDAaMAoGCCsGAQUFBwMEMAwGCisGAQQBgjcKAwQwVQYDVR0RBE4wTKAsBgor BgEEAYI3FAIDoB4MHHZpbmNlbnQuci5zY2FybGF0YUBpbnRlbC5jb22BHHZpbmNlbnQuci5zY2Fy bGF0YUBpbnRlbC5jb20wDQYJKoZIhvcNAQEFBQADggEBAKbDTuJGEb4gojiUdHhwAwl5hCYXpjgH CGfNO4/De1rHd2BZgn9fRs8h1NHZLqh0vu8yUyhegzZ0svhgjZ1lVQ1RVTa1gJVhdKCdLM02YGRw 6cOGSA3y66BOsuAq7i2wSf8rNmm1uJKyjLMrL8iDIUEkvizdcZCWaNN2No+lCVBiP96H9IHbmWRD +B5zt5whkJ/jAkbkYi25USY/NuLICNqXa0tEolcbadN1xk+xQ8TGuzu2N6ygbc2ni/ZUmNxlrVnD pQsj6PhnnmCuufw5eeg97puDqCv437bPs/b8Nzy71AmD4klH6h9+AS5Oj+KMbZKuvDGgl9Ypq5Gy BCXka/UxggOGMIIDggIBATBkMFYxCzAJBgNVBAYTAlVTMRowGAYDVQQKExFJbnRlbCBDb3Jwb3Jh dGlvbjErMCkGA1UEAxMiSW50ZWwgRXh0ZXJuYWwgQmFzaWMgSXNzdWluZyBDQSAzQQIKFq4u0AAB AABrDDAJBgUrDgMCGgUAoIIB9zAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqGSIb3DQEJ BTEPFw0xMTA5MDIxNjM5NDFaMCMGCSqGSIb3DQEJBDEWBBRTTeqz959c0GOgHibEMog8smm7PzBz BgkrBgEEAYI3EAQxZjBkMFYxCzAJBgNVBAYTAlVTMRowGAYDVQQKExFJbnRlbCBDb3Jwb3JhdGlv bjErMCkGA1UEAxMiSW50ZWwgRXh0ZXJuYWwgQmFzaWMgSXNzdWluZyBDQSAzQQIKG0yYBAABAABV oTB1BgsqhkiG9w0BCRACCzFmoGQwVjELMAkGA1UEBhMCVVMxGjAYBgNVBAoTEUludGVsIENvcnBv cmF0aW9uMSswKQYDVQQDEyJJbnRlbCBFeHRlcm5hbCBCYXNpYyBJc3N1aW5nIENBIDNBAgobTJgE AAEAAFWhMIGrBgkqhkiG9w0BCQ8xgZ0wgZowCwYJYIZIAWUDBAEqMAsGCWCGSAFlAwQBFjAKBggq hkiG9w0DBzALBglghkgBZQMEAQIwDgYIKoZIhvcNAwICAgCAMAcGBSsOAwIHMA0GCCqGSIb3DQMC AgFAMA0GCCqGSIb3DQMCAgEoMAcGBSsOAwIaMAsGCWCGSAFlAwQCAzALBglghkgBZQMEAgIwCwYJ YIZIAWUDBAIBMA0GCSqGSIb3DQEBAQUABIIBAGmN9EzGwwpW5Y+lySVOJo/NuFm6Ti0Sm59bvxai uJV+SJ8X6LhFowcdUc4/vXpLlSxpWGWzz7BN2t8uTHaDWfP7EA7VtOfuZ9wI/2bUnyweZZcNpH0n ox9FYOT2/J6TkgBH9PzRrhXD7Sa9cFdfDT+aAwmImBaVNM73eCHGdFCzMs/pAesYzDgh/nd5r3rD bSsD0G5DJUpy/wIxrfNu1QSk9L5EgHL+Cch6W6e0Nb5UTgUVjr/0ZGiJ6Fuj9fNmbEaIS0vv2sq4 T3DHltMyxKsQRRvX7eG9IeaMEt3J/JuY/CVRFcgipWm7CDbRYZKCTjePOlP9jDp9H4m11WIR4goA AAAAAAA= ------=_NextPart_000_013D_01CC6954.3D24E820-- --===============0497532364== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel --===============0497532364==-- From xen-devel-bounces@lists.xensource.com Sat Sep 03 20:07:30 2011 Return-path: Envelope-to: www-data@lists.xensource.com Delivery-date: Sat, 03 Sep 2011 20:07:30 -0700 Received: from localhost ([127.0.0.1] helo=lists.colo.xensource.com) by lists.xensource.com with esmtp (Exim 4.43) id 1R033S-0005oY-Pv; Sat, 03 Sep 2011 20:07:30 -0700 Received: from mail182.messagelabs.com ([85.158.139.83]) by lists.xensource.com with esmtp (Exim 4.43) id 1QzYku-0002SN-6U for xen-devel@lists.xensource.com; Fri, 02 Sep 2011 11:46:21 -0700 X-Env-Sender: digitaleric@google.com X-Msg-Ref: server-11.tower-182.messagelabs.com!1314989175!16856033!1 X-Originating-IP: [216.239.44.51] X-StarScan-Version: 6.3.6; banners=-,-,- X-VirusChecked: Checked Received: (qmail 22718 invoked from network); 2 Sep 2011 18:46:16 -0000 Received: from smtp-out.google.com (HELO smtp-out.google.com) (216.239.44.51) by server-11.tower-182.messagelabs.com with DHE-RSA-AES256-SHA encrypted SMTP; 2 Sep 2011 18:46:16 -0000 Received: from hpaq13.eem.corp.google.com (hpaq13.eem.corp.google.com [172.25.149.13]) by smtp-out.google.com with ESMTP id p82IkBEV019929 for ; Fri, 2 Sep 2011 11:46:12 -0700 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=google.com; s=beta; t=1314989175; bh=kNt0dlErXx7RyHhV396UzM+bBZo=; h=MIME-Version:In-Reply-To:References:Date:Message-ID:Subject:From: To:Cc:Content-Type:Content-Transfer-Encoding; b=GjTvOE0vA1InOHaaJsBWgeADBD9M4nVK4gHUcVX+WEt02WoAOeQGVS3rKhYpe59+K iaMl6yDHwKfOES9rLM3Dg== DomainKey-Signature: a=rsa-sha1; s=beta; d=google.com; c=nofws; q=dns; h=dkim-signature:mime-version:in-reply-to:references:date: message-id:subject:from:to:cc:content-type: content-transfer-encoding:x-system-of-record; b=aC88XQZ/W7vc0UQh/Oa7+7LxDqbof0i5CdvI1nxelqjxNjfnypcS6DnwZfmSaBvSn 4ZZEPA6bV4IunYBH8ynkw== Received: from gwaa12 (gwaa12.prod.google.com [10.200.27.12]) by hpaq13.eem.corp.google.com with ESMTP id p82Ik90a002117 (version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=NOT) for ; Fri, 2 Sep 2011 11:46:10 -0700 Received: by gwaa12 with SMTP id a12so2348569gwa.33 for ; Fri, 02 Sep 2011 11:46:09 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=beta; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; bh=rP+B77jgDnUD7NumEOoxdg5b4o7n34kzXmsd4OXlPDg=; b=eRKcJcqZLDcjoE3gFagvDOulQtTo18vvRaYB2jrCi9vh2ox0i//cDN5d9w8HxTiSHP laxFz605VgVIlTpYhDAA== Received: by 10.68.1.1 with SMTP id 1mr2391414pbi.187.1314989169235; Fri, 02 Sep 2011 11:46:09 -0700 (PDT) MIME-Version: 1.0 Received: by 10.68.1.1 with SMTP id 1mr2391388pbi.187.1314989169090; Fri, 02 Sep 2011 11:46:09 -0700 (PDT) Received: by 10.142.161.6 with HTTP; Fri, 2 Sep 2011 11:46:08 -0700 (PDT) In-Reply-To: <8a788f3fbf2ad1316e462bf5aae623bab9d38319.1314922370.git.jeremy.fitzhardinge@citrix.com> References: <8a788f3fbf2ad1316e462bf5aae623bab9d38319.1314922370.git.jeremy.fitzhardinge@citrix.com> Date: Fri, 2 Sep 2011 11:46:08 -0700 Message-ID: From: Eric Northup To: Jeremy Fitzhardinge Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable X-System-Of-Record: true X-Mailman-Approved-At: Sat, 03 Sep 2011 20:05:53 -0700 Cc: Marcelo Tosatti , Nick Piggin , KVM , Peter Zijlstra , the arch/x86 maintainers , Linux Kernel Mailing List , Andi Kleen , Avi Kivity , Jeremy Fitzhardinge , "H. Peter Anvin" , Ingo Molnar , Linus Torvalds , Xen Devel Subject: [Xen-devel] Re: [PATCH 06/13] x86/ticketlock: add slowpath logic X-BeenThere: xen-devel@lists.xensource.com X-Mailman-Version: 2.1.5 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xensource.com Errors-To: xen-devel-bounces@lists.xensource.com On Thu, Sep 1, 2011 at 5:54 PM, Jeremy Fitzhardinge wrote= : > From: Jeremy Fitzhardinge > > Maintain a flag in both LSBs of the ticket lock which indicates whether > anyone is in the lock slowpath and may need kicking when the current > holder unlocks. =A0The flags are set when the first locker enters > the slowpath, and cleared when unlocking to an empty queue. Are there actually two flags maintained? I only see the one in the ticket tail getting set/cleared/tested. _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel From xen-devel-bounces@lists.xensource.com Sat Sep 03 20:39:49 2011 Return-path: Envelope-to: www-data@lists.xensource.com Delivery-date: Sat, 03 Sep 2011 20:39:49 -0700 Received: from localhost ([127.0.0.1] helo=lists.colo.xensource.com) by lists.xensource.com with esmtp (Exim 4.43) id 1R03Yj-0006jX-6P; Sat, 03 Sep 2011 20:39:49 -0700 Received: from mail182.messagelabs.com ([85.158.139.83]) by lists.xensource.com with smtp (Exim 4.43) id 1R03YF-0006XV-JI for xen-devel@lists.xensource.com; Sat, 03 Sep 2011 20:39:19 -0700 X-Env-Sender: Ian.Jackson@eu.citrix.com X-Msg-Ref: server-6.tower-182.messagelabs.com!1315107556!16940431!1 X-Originating-IP: [62.200.22.115] X-StarScan-Version: 6.3.6; banners=-,-,- X-VirusChecked: Checked Received: (qmail 29404 invoked from network); 4 Sep 2011 03:39:16 -0000 Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115) by server-6.tower-182.messagelabs.com with SMTP; 4 Sep 2011 03:39:16 -0000 X-IronPort-AV: E=Sophos;i="4.68,326,1312156800"; d="scan'208";a="7590205" Received: from lonpmailmx01.citrite.net ([10.30.203.162]) by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5; 04 Sep 2011 03:39:16 +0000 Received: from woking.xci-test.com (10.80.248.135) by smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id 8.3.137.0; Sun, 4 Sep 2011 04:39:16 +0100 Received: from osstest by woking.xci-test.com with local (Exim 4.69) (envelope-from ) id 1R03YB-0006So-I9; Sun, 04 Sep 2011 04:39:15 +0100 To: xen-devel@lists.xensource.com Message-ID: From: xen.org Date: Sun, 4 Sep 2011 04:39:15 +0100 MIME-Version: 1.0 Content-Type: text/plain Cc: ian.jackson@eu.citrix.com Subject: [Xen-devel] [xen-unstable test] 8828: FAIL X-BeenThere: xen-devel@lists.xensource.com X-Mailman-Version: 2.1.5 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xensource.com Errors-To: xen-devel-bounces@lists.xensource.com flight 8828 xen-unstable real [real] http://www.chiark.greenend.org.uk/~xensrcts/logs/8828/ Failures and problems with tests :-( Tests which did not succeed and are blocking: test-amd64-amd64-xl 3 host-install(3) broken in 8827 Tests which are failing intermittently (not blocking): test-amd64-amd64-xl-sedf 9 guest-start fail pass in 8827 test-amd64-amd64-xl-sedf 14 guest-localmigrate/x10 fail in 8827 pass in 8826 test-amd64-i386-xl-win-vcpus1 12 guest-localmigrate/x10 fail in 8827 pass in 8828 test-i386-i386-win 14 guest-start.2 fail in 8827 pass in 8828 Tests which did not succeed, but are not blocking, including regressions (tests previously passed) regarded as allowable: test-amd64-amd64-xl-pcipt-intel 9 guest-start fail never pass test-amd64-i386-rhel6hvm-intel 9 guest-start.2 fail never pass test-amd64-i386-win-vcpus1 16 leak-check/check fail never pass test-amd64-i386-xl-win-vcpus1 13 guest-stop fail never pass test-amd64-i386-rhel6hvm-amd 9 guest-start.2 fail never pass test-amd64-i386-win 16 leak-check/check fail never pass test-amd64-amd64-win 16 leak-check/check fail never pass test-amd64-amd64-xl-win 13 guest-stop fail never pass test-i386-i386-xl-win 13 guest-stop fail never pass test-i386-i386-win 16 leak-check/check fail never pass version targeted for testing: xen f1349a968a5a baseline version: xen f1349a968a5a jobs: build-amd64 pass build-i386 pass build-amd64-oldkern pass build-i386-oldkern pass build-amd64-pvops pass build-i386-pvops pass test-amd64-amd64-xl pass test-amd64-i386-xl pass test-i386-i386-xl pass test-amd64-i386-rhel6hvm-amd fail test-amd64-i386-xl-credit2 pass test-amd64-amd64-xl-pcipt-intel fail test-amd64-i386-rhel6hvm-intel fail test-amd64-i386-xl-multivcpu pass test-amd64-amd64-pair pass test-amd64-i386-pair pass test-i386-i386-pair pass test-amd64-amd64-pv pass test-amd64-i386-pv pass test-i386-i386-pv pass test-amd64-amd64-xl-sedf fail test-amd64-i386-win-vcpus1 fail test-amd64-i386-xl-win-vcpus1 fail test-amd64-amd64-win fail test-amd64-i386-win fail test-i386-i386-win fail test-amd64-amd64-xl-win fail test-i386-i386-xl-win fail ------------------------------------------------------------ sg-report-flight on woking.cam.xci-test.com logs: /home/xc_osstest/logs images: /home/xc_osstest/images Logs, config files, etc. are available at http://www.chiark.greenend.org.uk/~xensrcts/logs Test harness code can be found at http://xenbits.xensource.com/gitweb?p=osstest.git;a=summary Published tested tree is already up to date. _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel From xen-devel-bounces@lists.xensource.com Sun Sep 04 03:28:24 2011 Return-path: Envelope-to: www-data@lists.xensource.com Delivery-date: Sun, 04 Sep 2011 03:28:24 -0700 Received: from localhost ([127.0.0.1] helo=lists.colo.xensource.com) by lists.xensource.com with esmtp (Exim 4.43) id 1R09w7-00063n-Mx; Sun, 04 Sep 2011 03:28:23 -0700 Received: from mail174.messagelabs.com ([85.158.138.51]) by lists.xensource.com with esmtp (Exim 4.43) id 1R09vM-0005r4-2v for xen-devel@lists.xensource.com; Sun, 04 Sep 2011 03:27:36 -0700 X-Env-Sender: marmarek@mimuw.edu.pl X-Msg-Ref: server-12.tower-174.messagelabs.com!1315132052!30152953!1 X-Originating-IP: [193.0.96.6] X-StarScan-Version: 6.3.6; banners=-,-,- X-VirusChecked: Checked Received: (qmail 30427 invoked from network); 4 Sep 2011 10:27:32 -0000 Received: from mail.mimuw.edu.pl (HELO mail.mimuw.edu.pl) (193.0.96.6) by server-12.tower-174.messagelabs.com with DHE-RSA-AES256-SHA encrypted SMTP; 4 Sep 2011 10:27:32 -0000 Received: from localhost (localhost [127.0.0.1] ident=amavis) by duch.mimuw.edu.pl (Postfix) with ESMTP id D68541F5 for ; Sun, 4 Sep 2011 12:27:31 +0200 (CEST) X-Virus-Scanned: amavisd-new at mimuw.edu.pl Received: from duch.mimuw.edu.pl ([127.0.0.1]) by localhost (mail.mimuw.edu.pl [127.0.0.1]) (amavisd-new, port 10026) with ESMTP id yyckoViQ7xjz for ; Sun, 4 Sep 2011 12:27:30 +0200 (CEST) Received: from [10.137.1.11] (87-206-116-192.dynamic.chello.pl [87.206.116.192]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (No client certificate requested) by duch.mimuw.edu.pl (Postfix) with ESMTPSA for ; Sun, 4 Sep 2011 12:27:30 +0200 (CEST) Message-ID: <4E635296.5080803@mimuw.edu.pl> Date: Sun, 04 Sep 2011 12:27:34 +0200 From: Marek Marczykowski User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.2.18) Gecko/20110621 Fedora/3.1.11-1.fc14 Lightning/1.0b3pre Thunderbird/3.1.11 MIME-Version: 1.0 To: "xen-devel@lists.xensource.com" X-Enigmail-Version: 1.1.2 Subject: [Xen-devel] [PATCH] Initialize vars in blkfront_connect X-BeenThere: xen-devel@lists.xensource.com X-Mailman-Version: 2.1.5 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0340917801==" Sender: xen-devel-bounces@lists.xensource.com Errors-To: xen-devel-bounces@lists.xensource.com This is a cryptographically signed message in MIME format. --===============0340917801== Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha1; boundary="------------ms050400070403010200080707" This is a cryptographically signed message in MIME format. --------------ms050400070403010200080707 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Hello, barrier and flush variable isn't initialized, which cause undetermined result in case of xenstore entries (feature-barrier and feature-flush-cache) not present (feature_flush not set to 0). Signed-off-by: Marek Marczykowski diff --git a/drivers/block/xen-blkfront.c b/drivers/block/xen-blkfront.c index 863d4c5..e3cbe08 100644 --- a/drivers/block/xen-blkfront.c +++ b/drivers/block/xen-blkfront.c @@ -1110,7 +1110,7 @@ static void blkfront_connect(struct blkfront_info *info) unsigned long sector_size; unsigned int binfo; int err; - int barrier, flush; + int barrier =3D 0, flush =3D 0; switch (info->connected) { case BLKIF_STATE_CONNECTED: --=20 Pozdrawiam / Best Regards, Marek Marczykowski | RLU #390519 marmarek at mimuw edu pl | xmpp:marmarek at staszic waw pl --------------ms050400070403010200080707 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIRqDCC BVcwggQ/oAMCAQICEGdLwnOg7SU/xzieX7FaFewwDQYJKoZIhvcNAQEFBQAwgd0xCzAJBgNV BAYTAlVTMRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNpZ24gVHJ1 c3QgTmV0d29yazE7MDkGA1UECxMyVGVybXMgb2YgdXNlIGF0IGh0dHBzOi8vd3d3LnZlcmlz aWduLmNvbS9ycGEgKGMpMDkxHjAcBgNVBAsTFVBlcnNvbmEgTm90IFZhbGlkYXRlZDE3MDUG A1UEAxMuVmVyaVNpZ24gQ2xhc3MgMSBJbmRpdmlkdWFsIFN1YnNjcmliZXIgQ0EgLSBHMzAe Fw0xMDEyMDgwMDAwMDBaFw0xMTEyMDgyMzU5NTlaMIIBGjEXMBUGA1UEChMOVmVyaVNpZ24s IEluYy4xHzAdBgNVBAsTFlZlcmlTaWduIFRydXN0IE5ldHdvcmsxRjBEBgNVBAsTPXd3dy52 ZXJpc2lnbi5jb20vcmVwb3NpdG9yeS9SUEEgSW5jb3JwLiBieSBSZWYuLExJQUIuTFREKGMp OTgxHjAcBgNVBAsTFVBlcnNvbmEgTm90IFZhbGlkYXRlZDEzMDEGA1UECxMqRGlnaXRhbCBJ RCBDbGFzcyAxIC0gTmV0c2NhcGUgRnVsbCBTZXJ2aWNlMRswGQYDVQQDFBJNQVJFSyBNYXJj enlrb3dza2kxJDAiBgkqhkiG9w0BCQEWFW1hcm1hcmVrQG1pbXV3LmVkdS5wbDCCASIwDQYJ KoZIhvcNAQEBBQADggEPADCCAQoCggEBAMGGGDj1KJXXy13nNqo0NP7EJNnzjWHih+Z88UA/ c/CZOIu3/SUnA9gly922moQ+r4AM0k6EQaVkAdldSOy1hO/fTcJQBwDemcnACWstMDMvIbWn dkxyxNgh8bQD/xKXx1SyfKTixcx0QZXosY8HnHLWeF0Te5U9J8yUPxigCFJFe6rtY2iARrWc qWXDr4DRQc5J43aohBXGRHw+OakREqLZds6HEE6+YvJH+udcfqlrfkLKHJeiyA4UPtZwBvam EGOKrm2rqyps/JeivaTs6zKh0+4eNxSKlOGTUmj4eHVb/K3gkbX6bihmWS+9nnN3I4HL+KPZ j88xQCHX07Gh4nECAwEAAaOB0jCBzzAJBgNVHRMEAjAAMEQGA1UdIAQ9MDswOQYLYIZIAYb4 RQEHFwEwKjAoBggrBgEFBQcCARYcaHR0cHM6Ly93d3cudmVyaXNpZ24uY29tL3JwYTALBgNV HQ8EBAMCBaAwHQYDVR0lBBYwFAYIKwYBBQUHAwQGCCsGAQUFBwMCMFAGA1UdHwRJMEcwRaBD oEGGP2h0dHA6Ly9pbmRjMWRpZ2l0YWxpZC1nMy1jcmwudmVyaXNpZ24uY29tL0luZEMxRGln aXRhbElELUczLmNybDANBgkqhkiG9w0BAQUFAAOCAQEAl7oehxokYa9omPurM44GROaRxtIQ acWWpCgeMNDqJXyEgm30u0hY1szXiSyVnkIx/sh4HuBqvXJnZZvLjksEIzdALTgCAskojzeT oeX+340loS87OO82/XUDT5YY3+R5G+4oQIxKVqF7kDmOuJ2opbjU4dFxHhIypiEcWjG2sjWd 127poxMQeY4lCk3qKw94pK5RpVPJK8hzaf+pWoL2D7i3L2xE+DMzZJ1OB3AxcGxhvupUq+zz 3Z9IIHo6DNOwUyCNR+ShVnuCaoJcya35mQzhs1s5+LcP/ysrUzhPo+iYNXGv+q5iNQEXZ7Dw kPgAm17fnxmih6D4KRbmrc3xpjCCBVcwggQ/oAMCAQICEGdLwnOg7SU/xzieX7FaFewwDQYJ KoZIhvcNAQEFBQAwgd0xCzAJBgNVBAYTAlVTMRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEf MB0GA1UECxMWVmVyaVNpZ24gVHJ1c3QgTmV0d29yazE7MDkGA1UECxMyVGVybXMgb2YgdXNl IGF0IGh0dHBzOi8vd3d3LnZlcmlzaWduLmNvbS9ycGEgKGMpMDkxHjAcBgNVBAsTFVBlcnNv bmEgTm90IFZhbGlkYXRlZDE3MDUGA1UEAxMuVmVyaVNpZ24gQ2xhc3MgMSBJbmRpdmlkdWFs IFN1YnNjcmliZXIgQ0EgLSBHMzAeFw0xMDEyMDgwMDAwMDBaFw0xMTEyMDgyMzU5NTlaMIIB GjEXMBUGA1UEChMOVmVyaVNpZ24sIEluYy4xHzAdBgNVBAsTFlZlcmlTaWduIFRydXN0IE5l dHdvcmsxRjBEBgNVBAsTPXd3dy52ZXJpc2lnbi5jb20vcmVwb3NpdG9yeS9SUEEgSW5jb3Jw LiBieSBSZWYuLExJQUIuTFREKGMpOTgxHjAcBgNVBAsTFVBlcnNvbmEgTm90IFZhbGlkYXRl ZDEzMDEGA1UECxMqRGlnaXRhbCBJRCBDbGFzcyAxIC0gTmV0c2NhcGUgRnVsbCBTZXJ2aWNl MRswGQYDVQQDFBJNQVJFSyBNYXJjenlrb3dza2kxJDAiBgkqhkiG9w0BCQEWFW1hcm1hcmVr QG1pbXV3LmVkdS5wbDCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAMGGGDj1KJXX y13nNqo0NP7EJNnzjWHih+Z88UA/c/CZOIu3/SUnA9gly922moQ+r4AM0k6EQaVkAdldSOy1 hO/fTcJQBwDemcnACWstMDMvIbWndkxyxNgh8bQD/xKXx1SyfKTixcx0QZXosY8HnHLWeF0T e5U9J8yUPxigCFJFe6rtY2iARrWcqWXDr4DRQc5J43aohBXGRHw+OakREqLZds6HEE6+YvJH +udcfqlrfkLKHJeiyA4UPtZwBvamEGOKrm2rqyps/JeivaTs6zKh0+4eNxSKlOGTUmj4eHVb /K3gkbX6bihmWS+9nnN3I4HL+KPZj88xQCHX07Gh4nECAwEAAaOB0jCBzzAJBgNVHRMEAjAA MEQGA1UdIAQ9MDswOQYLYIZIAYb4RQEHFwEwKjAoBggrBgEFBQcCARYcaHR0cHM6Ly93d3cu dmVyaXNpZ24uY29tL3JwYTALBgNVHQ8EBAMCBaAwHQYDVR0lBBYwFAYIKwYBBQUHAwQGCCsG AQUFBwMCMFAGA1UdHwRJMEcwRaBDoEGGP2h0dHA6Ly9pbmRjMWRpZ2l0YWxpZC1nMy1jcmwu dmVyaXNpZ24uY29tL0luZEMxRGlnaXRhbElELUczLmNybDANBgkqhkiG9w0BAQUFAAOCAQEA l7oehxokYa9omPurM44GROaRxtIQacWWpCgeMNDqJXyEgm30u0hY1szXiSyVnkIx/sh4HuBq vXJnZZvLjksEIzdALTgCAskojzeToeX+340loS87OO82/XUDT5YY3+R5G+4oQIxKVqF7kDmO uJ2opbjU4dFxHhIypiEcWjG2sjWd127poxMQeY4lCk3qKw94pK5RpVPJK8hzaf+pWoL2D7i3 L2xE+DMzZJ1OB3AxcGxhvupUq+zz3Z9IIHo6DNOwUyCNR+ShVnuCaoJcya35mQzhs1s5+LcP /ysrUzhPo+iYNXGv+q5iNQEXZ7DwkPgAm17fnxmih6D4KRbmrc3xpjCCBu4wggXWoAMCAQIC EHEVZgVK5JEhTem8RPms09wwDQYJKoZIhvcNAQEFBQAwgcoxCzAJBgNVBAYTAlVTMRcwFQYD VQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNpZ24gVHJ1c3QgTmV0d29yazE6 MDgGA1UECxMxKGMpIDE5OTkgVmVyaVNpZ24sIEluYy4gLSBGb3IgYXV0aG9yaXplZCB1c2Ug b25seTFFMEMGA1UEAxM8VmVyaVNpZ24gQ2xhc3MgMSBQdWJsaWMgUHJpbWFyeSBDZXJ0aWZp Y2F0aW9uIEF1dGhvcml0eSAtIEczMB4XDTA5MDUwMTAwMDAwMFoXDTE5MDQzMDIzNTk1OVow gd0xCzAJBgNVBAYTAlVTMRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVy aVNpZ24gVHJ1c3QgTmV0d29yazE7MDkGA1UECxMyVGVybXMgb2YgdXNlIGF0IGh0dHBzOi8v d3d3LnZlcmlzaWduLmNvbS9ycGEgKGMpMDkxHjAcBgNVBAsTFVBlcnNvbmEgTm90IFZhbGlk YXRlZDE3MDUGA1UEAxMuVmVyaVNpZ24gQ2xhc3MgMSBJbmRpdmlkdWFsIFN1YnNjcmliZXIg Q0EgLSBHMzCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAO3ER98qKB18Bmu71yEy yWwTj+mxjUFONPfaC+Nq+mWIIAsRE+mb4ElOi2/VAdBfDUeRilpMdD4/xpEJu0w0no1uoYJR YvdpdliWB6+eFBgHT1q9n9IxslQZc0ZqGUIR7BJzIY313DDN5dlWCjHFNm0pFJe9LdqJRxmI 2EsEPeu2PGcedAATDdCG2pNn+DMDrho8a2l49sAsjuGDP3f5mf/+n1JawrSHCthsqUfBVCll Qz5KwJYfwa33d69ssQRevsG2lC2XkC0n0rse6YNqhPbEsq4jBmUmpSdYKwcitG+mYkgad/LV UCeaKdOW+yj1uiR2YuOMWev7btVCxL5Bx/UCAwEAAaOCArkwggK1MDQGCCsGAQUFBwEBBCgw JjAkBggrBgEFBQcwAYYYaHR0cDovL29jc3AudmVyaXNpZ24uY29tMBIGA1UdEwEB/wQIMAYB Af8CAQAwcAYDVR0gBGkwZzBlBgtghkgBhvhFAQcXATBWMCgGCCsGAQUFBwIBFhxodHRwczov L3d3dy52ZXJpc2lnbi5jb20vY3BzMCoGCCsGAQUFBwICMB4aHGh0dHBzOi8vd3d3LnZlcmlz aWduLmNvbS9ycGEwNAYDVR0fBC0wKzApoCegJYYjaHR0cDovL2NybC52ZXJpc2lnbi5jb20v cGNhMS1nMy5jcmwwDgYDVR0PAQH/BAQDAgEGMG4GCCsGAQUFBwEMBGIwYKFeoFwwWjBYMFYW CWltYWdlL2dpZjAhMB8wBwYFKw4DAhoEFEtruSiWBgy70FI4mymsSweLIQUYMCYWJGh0dHA6 Ly9sb2dvLnZlcmlzaWduLmNvbS92c2xvZ28xLmdpZjAuBgNVHREEJzAlpCMwITEfMB0GA1UE AxMWUHJpdmF0ZUxhYmVsNC0yMDQ4LTExODAdBgNVHQ4EFgQUeUdhCEH9OASiS+e1zPVD9kkr EfgwgfEGA1UdIwSB6TCB5qGB0KSBzTCByjELMAkGA1UEBhMCVVMxFzAVBgNVBAoTDlZlcmlT aWduLCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMTowOAYDVQQLEzEo YykgMTk5OSBWZXJpU2lnbiwgSW5jLiAtIEZvciBhdXRob3JpemVkIHVzZSBvbmx5MUUwQwYD VQQDEzxWZXJpU2lnbiBDbGFzcyAxIFB1YmxpYyBQcmltYXJ5IENlcnRpZmljYXRpb24gQXV0 aG9yaXR5IC0gRzOCEQCLW3VWhFSFCwDPrzhIzrGkMA0GCSqGSIb3DQEBBQUAA4IBAQA5Tc9B mYG1qQW1UjjpOYSJbOQ0qFrn2GwJTCQaulmkhztzIfGTgc+/aGNaZ/41hSuhw12jSsI6Gd0w 1sxN7/HSgZfKVFpDvzeLeo4ZjQ9DqIzyr2CzFYqzlZw84J6zJ5ikNXIX5fwqXYfTig3C0UUq +MD0rCqTOtWuEnAI6/s74nfs6CtkNXbNutrg0csU1nFYm77VPn222egkxSRmTF2RH3azFz5/ DcYhiS+zN7ih/1yybUneZVJC+w6I0u1KHb9L4/jMcvpIDmWOScjW+JmYO7eUPjFxBof6bFlT LtffK+1fYwCsFe0DuFUWjMZoA+ciqHMLsbyg2lJY3QoOf8GCMYIE7DCCBOgCAQEwgfIwgd0x CzAJBgNVBAYTAlVTMRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNp Z24gVHJ1c3QgTmV0d29yazE7MDkGA1UECxMyVGVybXMgb2YgdXNlIGF0IGh0dHBzOi8vd3d3 LnZlcmlzaWduLmNvbS9ycGEgKGMpMDkxHjAcBgNVBAsTFVBlcnNvbmEgTm90IFZhbGlkYXRl ZDE3MDUGA1UEAxMuVmVyaVNpZ24gQ2xhc3MgMSBJbmRpdmlkdWFsIFN1YnNjcmliZXIgQ0Eg LSBHMwIQZ0vCc6DtJT/HOJ5fsVoV7DAJBgUrDgMCGgUAoIICzjAYBgkqhkiG9w0BCQMxCwYJ KoZIhvcNAQcBMBwGCSqGSIb3DQEJBTEPFw0xMTA5MDQxMDI3MzRaMCMGCSqGSIb3DQEJBDEW BBTRF6DvqdKprxuCdHfKdKyZkoHUTDBfBgkqhkiG9w0BCQ8xUjBQMAsGCWCGSAFlAwQBAjAK BggqhkiG9w0DBzAOBggqhkiG9w0DAgICAIAwDQYIKoZIhvcNAwICAUAwBwYFKw4DAgcwDQYI KoZIhvcNAwICASgwggEDBgkrBgEEAYI3EAQxgfUwgfIwgd0xCzAJBgNVBAYTAlVTMRcwFQYD VQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNpZ24gVHJ1c3QgTmV0d29yazE7 MDkGA1UECxMyVGVybXMgb2YgdXNlIGF0IGh0dHBzOi8vd3d3LnZlcmlzaWduLmNvbS9ycGEg KGMpMDkxHjAcBgNVBAsTFVBlcnNvbmEgTm90IFZhbGlkYXRlZDE3MDUGA1UEAxMuVmVyaVNp Z24gQ2xhc3MgMSBJbmRpdmlkdWFsIFN1YnNjcmliZXIgQ0EgLSBHMwIQZ0vCc6DtJT/HOJ5f sVoV7DCCAQUGCyqGSIb3DQEJEAILMYH1oIHyMIHdMQswCQYDVQQGEwJVUzEXMBUGA1UEChMO VmVyaVNpZ24sIEluYy4xHzAdBgNVBAsTFlZlcmlTaWduIFRydXN0IE5ldHdvcmsxOzA5BgNV BAsTMlRlcm1zIG9mIHVzZSBhdCBodHRwczovL3d3dy52ZXJpc2lnbi5jb20vcnBhIChjKTA5 MR4wHAYDVQQLExVQZXJzb25hIE5vdCBWYWxpZGF0ZWQxNzA1BgNVBAMTLlZlcmlTaWduIENs YXNzIDEgSW5kaXZpZHVhbCBTdWJzY3JpYmVyIENBIC0gRzMCEGdLwnOg7SU/xzieX7FaFeww DQYJKoZIhvcNAQEBBQAEggEAcaSA76VpyjPF1vhTYAHf5ulz1lMY0+qMn4Fj57SOp19aVGBd MVGq8kHJ5PO2bUk9zj5DYRxLyW+e8zFHAGgetPMHoIFmLjRZEK2O1Ni5Yh5J0MihJtSkhI0/ xcHMK6WCvfd57Wi/XTgWyujU/iUW6JnlwCw887HWgWEb8hDhz/VuQRL492n1ngRyYeN0/cIz y37dsCsrNW6xcJWp8i5hJqrFqAFjeviWgiR7Gq34Sgd2PTvhdBNlclLOVJ8AuoIrw5cOMb/3 ZCvX0v+tU8qko6iJz3yS9vmJ2NNKSGXFEhhqTtMTGS3uU01HqDLhECNejVC2M3qDdMGzyztt RCrV0QAAAAAAAA== --------------ms050400070403010200080707-- --===============0340917801== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel --===============0340917801==-- From xen-devel-bounces@lists.xensource.com Sun Sep 04 03:50:41 2011 Return-path: Envelope-to: www-data@lists.xensource.com Delivery-date: Sun, 04 Sep 2011 03:50:41 -0700 Received: from localhost ([127.0.0.1] helo=lists.colo.xensource.com) by lists.xensource.com with esmtp (Exim 4.43) id 1R0AHg-0006uF-7u; Sun, 04 Sep 2011 03:50:40 -0700 Received: from mail216.messagelabs.com ([85.158.143.99]) by lists.xensource.com with esmtp (Exim 4.43) id 1R0AGl-0006hV-9u for xen-devel@lists.xensource.com; Sun, 04 Sep 2011 03:49:43 -0700 X-Env-Sender: marmarek@mimuw.edu.pl X-Msg-Ref: server-15.tower-216.messagelabs.com!1315133379!16595607!1 X-Originating-IP: [193.0.96.6] X-StarScan-Version: 6.3.6; banners=-,-,- X-VirusChecked: Checked Received: (qmail 3151 invoked from network); 4 Sep 2011 10:49:39 -0000 Received: from mail.mimuw.edu.pl (HELO mail.mimuw.edu.pl) (193.0.96.6) by server-15.tower-216.messagelabs.com with DHE-RSA-AES256-SHA encrypted SMTP; 4 Sep 2011 10:49:39 -0000 Received: from localhost (localhost [127.0.0.1] ident=amavis) by duch.mimuw.edu.pl (Postfix) with ESMTP id 07CB52DA for ; Sun, 4 Sep 2011 12:49:39 +0200 (CEST) X-Virus-Scanned: amavisd-new at mimuw.edu.pl Received: from duch.mimuw.edu.pl ([127.0.0.1]) by localhost (mail.mimuw.edu.pl [127.0.0.1]) (amavisd-new, port 10026) with ESMTP id nPsV+8u2Whik for ; Sun, 4 Sep 2011 12:49:38 +0200 (CEST) Received: from [10.137.1.11] (87-206-116-192.dynamic.chello.pl [87.206.116.192]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (No client certificate requested) by duch.mimuw.edu.pl (Postfix) with ESMTPSA for ; Sun, 4 Sep 2011 12:49:37 +0200 (CEST) Message-ID: <4E6357C6.6050101@mimuw.edu.pl> Date: Sun, 04 Sep 2011 12:49:42 +0200 From: Marek Marczykowski User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.2.18) Gecko/20110621 Fedora/3.1.11-1.fc14 Lightning/1.0b3pre Thunderbird/3.1.11 MIME-Version: 1.0 To: "xen-devel@lists.xensource.com" X-Enigmail-Version: 1.1.2 Subject: [Xen-devel] blkfront problem in pvops kernel when barriers enabled X-BeenThere: xen-devel@lists.xensource.com X-Mailman-Version: 2.1.5 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1749819658==" Sender: xen-devel-bounces@lists.xensource.com Errors-To: xen-devel-bounces@lists.xensource.com This is a cryptographically signed message in MIME format. --===============1749819658== Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha1; boundary="------------ms050206020003090207010401" This is a cryptographically signed message in MIME format. --------------ms050206020003090207010401 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Hello, Pvops block frontend (tested vanilla 3.0.3, 3.1rc2, Konrad's testing branch) produces a lot of I/O errors when barriers are enabled but cannot be used. On xenlinux I've got message: [ 15.036921] blkfront: xvdb: empty write barrier op failed [ 15.036936] blkfront: xvdb: barriers disabled and after that, everything works fine. On pvops - I/O errors. As backend I've used 2.6.38.3 xenlinux (based on SUSE package) and 3.1rc2 with same result. When I disable barriers (patching blkbackend to set feature-barrier=3D0) everything works fine with all above versions. My setup is xen-4.1.1 (if it matters), backends: phy from device-mapper device and phy from loop device; frontends covered by device-mapper snapshot, which is set up in domU initramfs. It looks like some race condition, because when I setup device-mapper in domU and mount it manually (which cause some delays between steps), it works fine... Have you idea why it happens? What additional data can I provide debug it= ? In addition it should be possible to disable barrier without patching module... Perhaps some pciback module parameter? Or leave feature-* xenstore entries alone if present before device initialization. --=20 Pozdrawiam / Best Regards, Marek Marczykowski | RLU #390519 marmarek at mimuw edu pl | xmpp:marmarek at staszic waw pl --------------ms050206020003090207010401 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIRqDCC BVcwggQ/oAMCAQICEGdLwnOg7SU/xzieX7FaFewwDQYJKoZIhvcNAQEFBQAwgd0xCzAJBgNV BAYTAlVTMRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNpZ24gVHJ1 c3QgTmV0d29yazE7MDkGA1UECxMyVGVybXMgb2YgdXNlIGF0IGh0dHBzOi8vd3d3LnZlcmlz aWduLmNvbS9ycGEgKGMpMDkxHjAcBgNVBAsTFVBlcnNvbmEgTm90IFZhbGlkYXRlZDE3MDUG A1UEAxMuVmVyaVNpZ24gQ2xhc3MgMSBJbmRpdmlkdWFsIFN1YnNjcmliZXIgQ0EgLSBHMzAe Fw0xMDEyMDgwMDAwMDBaFw0xMTEyMDgyMzU5NTlaMIIBGjEXMBUGA1UEChMOVmVyaVNpZ24s IEluYy4xHzAdBgNVBAsTFlZlcmlTaWduIFRydXN0IE5ldHdvcmsxRjBEBgNVBAsTPXd3dy52 ZXJpc2lnbi5jb20vcmVwb3NpdG9yeS9SUEEgSW5jb3JwLiBieSBSZWYuLExJQUIuTFREKGMp OTgxHjAcBgNVBAsTFVBlcnNvbmEgTm90IFZhbGlkYXRlZDEzMDEGA1UECxMqRGlnaXRhbCBJ RCBDbGFzcyAxIC0gTmV0c2NhcGUgRnVsbCBTZXJ2aWNlMRswGQYDVQQDFBJNQVJFSyBNYXJj enlrb3dza2kxJDAiBgkqhkiG9w0BCQEWFW1hcm1hcmVrQG1pbXV3LmVkdS5wbDCCASIwDQYJ KoZIhvcNAQEBBQADggEPADCCAQoCggEBAMGGGDj1KJXXy13nNqo0NP7EJNnzjWHih+Z88UA/ c/CZOIu3/SUnA9gly922moQ+r4AM0k6EQaVkAdldSOy1hO/fTcJQBwDemcnACWstMDMvIbWn dkxyxNgh8bQD/xKXx1SyfKTixcx0QZXosY8HnHLWeF0Te5U9J8yUPxigCFJFe6rtY2iARrWc qWXDr4DRQc5J43aohBXGRHw+OakREqLZds6HEE6+YvJH+udcfqlrfkLKHJeiyA4UPtZwBvam EGOKrm2rqyps/JeivaTs6zKh0+4eNxSKlOGTUmj4eHVb/K3gkbX6bihmWS+9nnN3I4HL+KPZ j88xQCHX07Gh4nECAwEAAaOB0jCBzzAJBgNVHRMEAjAAMEQGA1UdIAQ9MDswOQYLYIZIAYb4 RQEHFwEwKjAoBggrBgEFBQcCARYcaHR0cHM6Ly93d3cudmVyaXNpZ24uY29tL3JwYTALBgNV HQ8EBAMCBaAwHQYDVR0lBBYwFAYIKwYBBQUHAwQGCCsGAQUFBwMCMFAGA1UdHwRJMEcwRaBD oEGGP2h0dHA6Ly9pbmRjMWRpZ2l0YWxpZC1nMy1jcmwudmVyaXNpZ24uY29tL0luZEMxRGln aXRhbElELUczLmNybDANBgkqhkiG9w0BAQUFAAOCAQEAl7oehxokYa9omPurM44GROaRxtIQ acWWpCgeMNDqJXyEgm30u0hY1szXiSyVnkIx/sh4HuBqvXJnZZvLjksEIzdALTgCAskojzeT oeX+340loS87OO82/XUDT5YY3+R5G+4oQIxKVqF7kDmOuJ2opbjU4dFxHhIypiEcWjG2sjWd 127poxMQeY4lCk3qKw94pK5RpVPJK8hzaf+pWoL2D7i3L2xE+DMzZJ1OB3AxcGxhvupUq+zz 3Z9IIHo6DNOwUyCNR+ShVnuCaoJcya35mQzhs1s5+LcP/ysrUzhPo+iYNXGv+q5iNQEXZ7Dw kPgAm17fnxmih6D4KRbmrc3xpjCCBVcwggQ/oAMCAQICEGdLwnOg7SU/xzieX7FaFewwDQYJ KoZIhvcNAQEFBQAwgd0xCzAJBgNVBAYTAlVTMRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEf MB0GA1UECxMWVmVyaVNpZ24gVHJ1c3QgTmV0d29yazE7MDkGA1UECxMyVGVybXMgb2YgdXNl IGF0IGh0dHBzOi8vd3d3LnZlcmlzaWduLmNvbS9ycGEgKGMpMDkxHjAcBgNVBAsTFVBlcnNv bmEgTm90IFZhbGlkYXRlZDE3MDUGA1UEAxMuVmVyaVNpZ24gQ2xhc3MgMSBJbmRpdmlkdWFs IFN1YnNjcmliZXIgQ0EgLSBHMzAeFw0xMDEyMDgwMDAwMDBaFw0xMTEyMDgyMzU5NTlaMIIB GjEXMBUGA1UEChMOVmVyaVNpZ24sIEluYy4xHzAdBgNVBAsTFlZlcmlTaWduIFRydXN0IE5l dHdvcmsxRjBEBgNVBAsTPXd3dy52ZXJpc2lnbi5jb20vcmVwb3NpdG9yeS9SUEEgSW5jb3Jw LiBieSBSZWYuLExJQUIuTFREKGMpOTgxHjAcBgNVBAsTFVBlcnNvbmEgTm90IFZhbGlkYXRl ZDEzMDEGA1UECxMqRGlnaXRhbCBJRCBDbGFzcyAxIC0gTmV0c2NhcGUgRnVsbCBTZXJ2aWNl MRswGQYDVQQDFBJNQVJFSyBNYXJjenlrb3dza2kxJDAiBgkqhkiG9w0BCQEWFW1hcm1hcmVr QG1pbXV3LmVkdS5wbDCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAMGGGDj1KJXX y13nNqo0NP7EJNnzjWHih+Z88UA/c/CZOIu3/SUnA9gly922moQ+r4AM0k6EQaVkAdldSOy1 hO/fTcJQBwDemcnACWstMDMvIbWndkxyxNgh8bQD/xKXx1SyfKTixcx0QZXosY8HnHLWeF0T e5U9J8yUPxigCFJFe6rtY2iARrWcqWXDr4DRQc5J43aohBXGRHw+OakREqLZds6HEE6+YvJH +udcfqlrfkLKHJeiyA4UPtZwBvamEGOKrm2rqyps/JeivaTs6zKh0+4eNxSKlOGTUmj4eHVb /K3gkbX6bihmWS+9nnN3I4HL+KPZj88xQCHX07Gh4nECAwEAAaOB0jCBzzAJBgNVHRMEAjAA MEQGA1UdIAQ9MDswOQYLYIZIAYb4RQEHFwEwKjAoBggrBgEFBQcCARYcaHR0cHM6Ly93d3cu dmVyaXNpZ24uY29tL3JwYTALBgNVHQ8EBAMCBaAwHQYDVR0lBBYwFAYIKwYBBQUHAwQGCCsG AQUFBwMCMFAGA1UdHwRJMEcwRaBDoEGGP2h0dHA6Ly9pbmRjMWRpZ2l0YWxpZC1nMy1jcmwu dmVyaXNpZ24uY29tL0luZEMxRGlnaXRhbElELUczLmNybDANBgkqhkiG9w0BAQUFAAOCAQEA l7oehxokYa9omPurM44GROaRxtIQacWWpCgeMNDqJXyEgm30u0hY1szXiSyVnkIx/sh4HuBq vXJnZZvLjksEIzdALTgCAskojzeToeX+340loS87OO82/XUDT5YY3+R5G+4oQIxKVqF7kDmO uJ2opbjU4dFxHhIypiEcWjG2sjWd127poxMQeY4lCk3qKw94pK5RpVPJK8hzaf+pWoL2D7i3 L2xE+DMzZJ1OB3AxcGxhvupUq+zz3Z9IIHo6DNOwUyCNR+ShVnuCaoJcya35mQzhs1s5+LcP /ysrUzhPo+iYNXGv+q5iNQEXZ7DwkPgAm17fnxmih6D4KRbmrc3xpjCCBu4wggXWoAMCAQIC EHEVZgVK5JEhTem8RPms09wwDQYJKoZIhvcNAQEFBQAwgcoxCzAJBgNVBAYTAlVTMRcwFQYD VQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNpZ24gVHJ1c3QgTmV0d29yazE6 MDgGA1UECxMxKGMpIDE5OTkgVmVyaVNpZ24sIEluYy4gLSBGb3IgYXV0aG9yaXplZCB1c2Ug b25seTFFMEMGA1UEAxM8VmVyaVNpZ24gQ2xhc3MgMSBQdWJsaWMgUHJpbWFyeSBDZXJ0aWZp Y2F0aW9uIEF1dGhvcml0eSAtIEczMB4XDTA5MDUwMTAwMDAwMFoXDTE5MDQzMDIzNTk1OVow gd0xCzAJBgNVBAYTAlVTMRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVy aVNpZ24gVHJ1c3QgTmV0d29yazE7MDkGA1UECxMyVGVybXMgb2YgdXNlIGF0IGh0dHBzOi8v d3d3LnZlcmlzaWduLmNvbS9ycGEgKGMpMDkxHjAcBgNVBAsTFVBlcnNvbmEgTm90IFZhbGlk YXRlZDE3MDUGA1UEAxMuVmVyaVNpZ24gQ2xhc3MgMSBJbmRpdmlkdWFsIFN1YnNjcmliZXIg Q0EgLSBHMzCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAO3ER98qKB18Bmu71yEy yWwTj+mxjUFONPfaC+Nq+mWIIAsRE+mb4ElOi2/VAdBfDUeRilpMdD4/xpEJu0w0no1uoYJR YvdpdliWB6+eFBgHT1q9n9IxslQZc0ZqGUIR7BJzIY313DDN5dlWCjHFNm0pFJe9LdqJRxmI 2EsEPeu2PGcedAATDdCG2pNn+DMDrho8a2l49sAsjuGDP3f5mf/+n1JawrSHCthsqUfBVCll Qz5KwJYfwa33d69ssQRevsG2lC2XkC0n0rse6YNqhPbEsq4jBmUmpSdYKwcitG+mYkgad/LV UCeaKdOW+yj1uiR2YuOMWev7btVCxL5Bx/UCAwEAAaOCArkwggK1MDQGCCsGAQUFBwEBBCgw JjAkBggrBgEFBQcwAYYYaHR0cDovL29jc3AudmVyaXNpZ24uY29tMBIGA1UdEwEB/wQIMAYB Af8CAQAwcAYDVR0gBGkwZzBlBgtghkgBhvhFAQcXATBWMCgGCCsGAQUFBwIBFhxodHRwczov L3d3dy52ZXJpc2lnbi5jb20vY3BzMCoGCCsGAQUFBwICMB4aHGh0dHBzOi8vd3d3LnZlcmlz aWduLmNvbS9ycGEwNAYDVR0fBC0wKzApoCegJYYjaHR0cDovL2NybC52ZXJpc2lnbi5jb20v cGNhMS1nMy5jcmwwDgYDVR0PAQH/BAQDAgEGMG4GCCsGAQUFBwEMBGIwYKFeoFwwWjBYMFYW CWltYWdlL2dpZjAhMB8wBwYFKw4DAhoEFEtruSiWBgy70FI4mymsSweLIQUYMCYWJGh0dHA6 Ly9sb2dvLnZlcmlzaWduLmNvbS92c2xvZ28xLmdpZjAuBgNVHREEJzAlpCMwITEfMB0GA1UE AxMWUHJpdmF0ZUxhYmVsNC0yMDQ4LTExODAdBgNVHQ4EFgQUeUdhCEH9OASiS+e1zPVD9kkr EfgwgfEGA1UdIwSB6TCB5qGB0KSBzTCByjELMAkGA1UEBhMCVVMxFzAVBgNVBAoTDlZlcmlT aWduLCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMTowOAYDVQQLEzEo YykgMTk5OSBWZXJpU2lnbiwgSW5jLiAtIEZvciBhdXRob3JpemVkIHVzZSBvbmx5MUUwQwYD VQQDEzxWZXJpU2lnbiBDbGFzcyAxIFB1YmxpYyBQcmltYXJ5IENlcnRpZmljYXRpb24gQXV0 aG9yaXR5IC0gRzOCEQCLW3VWhFSFCwDPrzhIzrGkMA0GCSqGSIb3DQEBBQUAA4IBAQA5Tc9B mYG1qQW1UjjpOYSJbOQ0qFrn2GwJTCQaulmkhztzIfGTgc+/aGNaZ/41hSuhw12jSsI6Gd0w 1sxN7/HSgZfKVFpDvzeLeo4ZjQ9DqIzyr2CzFYqzlZw84J6zJ5ikNXIX5fwqXYfTig3C0UUq +MD0rCqTOtWuEnAI6/s74nfs6CtkNXbNutrg0csU1nFYm77VPn222egkxSRmTF2RH3azFz5/ DcYhiS+zN7ih/1yybUneZVJC+w6I0u1KHb9L4/jMcvpIDmWOScjW+JmYO7eUPjFxBof6bFlT LtffK+1fYwCsFe0DuFUWjMZoA+ciqHMLsbyg2lJY3QoOf8GCMYIE7DCCBOgCAQEwgfIwgd0x CzAJBgNVBAYTAlVTMRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNp Z24gVHJ1c3QgTmV0d29yazE7MDkGA1UECxMyVGVybXMgb2YgdXNlIGF0IGh0dHBzOi8vd3d3 LnZlcmlzaWduLmNvbS9ycGEgKGMpMDkxHjAcBgNVBAsTFVBlcnNvbmEgTm90IFZhbGlkYXRl ZDE3MDUGA1UEAxMuVmVyaVNpZ24gQ2xhc3MgMSBJbmRpdmlkdWFsIFN1YnNjcmliZXIgQ0Eg LSBHMwIQZ0vCc6DtJT/HOJ5fsVoV7DAJBgUrDgMCGgUAoIICzjAYBgkqhkiG9w0BCQMxCwYJ KoZIhvcNAQcBMBwGCSqGSIb3DQEJBTEPFw0xMTA5MDQxMDQ5NDJaMCMGCSqGSIb3DQEJBDEW BBS+xKBepW5ln0JzEA7V9U48YIc22TBfBgkqhkiG9w0BCQ8xUjBQMAsGCWCGSAFlAwQBAjAK BggqhkiG9w0DBzAOBggqhkiG9w0DAgICAIAwDQYIKoZIhvcNAwICAUAwBwYFKw4DAgcwDQYI KoZIhvcNAwICASgwggEDBgkrBgEEAYI3EAQxgfUwgfIwgd0xCzAJBgNVBAYTAlVTMRcwFQYD VQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNpZ24gVHJ1c3QgTmV0d29yazE7 MDkGA1UECxMyVGVybXMgb2YgdXNlIGF0IGh0dHBzOi8vd3d3LnZlcmlzaWduLmNvbS9ycGEg KGMpMDkxHjAcBgNVBAsTFVBlcnNvbmEgTm90IFZhbGlkYXRlZDE3MDUGA1UEAxMuVmVyaVNp Z24gQ2xhc3MgMSBJbmRpdmlkdWFsIFN1YnNjcmliZXIgQ0EgLSBHMwIQZ0vCc6DtJT/HOJ5f sVoV7DCCAQUGCyqGSIb3DQEJEAILMYH1oIHyMIHdMQswCQYDVQQGEwJVUzEXMBUGA1UEChMO VmVyaVNpZ24sIEluYy4xHzAdBgNVBAsTFlZlcmlTaWduIFRydXN0IE5ldHdvcmsxOzA5BgNV BAsTMlRlcm1zIG9mIHVzZSBhdCBodHRwczovL3d3dy52ZXJpc2lnbi5jb20vcnBhIChjKTA5 MR4wHAYDVQQLExVQZXJzb25hIE5vdCBWYWxpZGF0ZWQxNzA1BgNVBAMTLlZlcmlTaWduIENs YXNzIDEgSW5kaXZpZHVhbCBTdWJzY3JpYmVyIENBIC0gRzMCEGdLwnOg7SU/xzieX7FaFeww DQYJKoZIhvcNAQEBBQAEggEAbuiod9Lyc09G3wxaWvseH7Q1XJYEXfmgaIHzOtKHnemDI6rq Nix8HeZyYLNy8qtEAPizUkS8XtImavLJaC3r/P0e5lysKw2D4dViDf+o3EGpNdIiZXIUl3Aa wtXv5lSPjLNiLH41C4WiLOK+OXvi7jkkfICsHeaIjiC5WuNCl00c3HA4eKO8JiiH9E3CLI1Y LpHFWaFjqR14tvSFFzGb0MehfhmKMpUCH3rmXVcB6Vk39qZQiXfRl9oyeAhtwV9FAspWxx7B Qf8fTZgBFDQ+vyhsZV+MN5/j56M02lbjuvE0Bz58B5l3MMpOcjucxlsbv74x8O54SomNSjKt UbtWPgAAAAAAAA== --------------ms050206020003090207010401-- --===============1749819658== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel --===============1749819658==-- From xen-devel-bounces@lists.xensource.com Sun Sep 04 14:52:35 2011 Return-path: Envelope-to: www-data@lists.xensource.com Delivery-date: Sun, 04 Sep 2011 14:52:35 -0700 Received: from localhost ([127.0.0.1] helo=lists.colo.xensource.com) by lists.xensource.com with esmtp (Exim 4.43) id 1R0KcE-0004H3-To; Sun, 04 Sep 2011 14:52:34 -0700 Received: from mail216.messagelabs.com ([85.158.143.99]) by lists.xensource.com with esmtp (Exim 4.43) id 1R0KbM-00044b-QS for xen-devel@lists.xensource.com; Sun, 04 Sep 2011 14:51:41 -0700 X-Env-Sender: marmarek@mimuw.edu.pl X-Msg-Ref: server-4.tower-216.messagelabs.com!1315173097!17014847!1 X-Originating-IP: [193.0.96.6] X-StarScan-Version: 6.3.6; banners=-,-,- X-VirusChecked: Checked Received: (qmail 10957 invoked from network); 4 Sep 2011 21:51:37 -0000 Received: from mail.mimuw.edu.pl (HELO mail.mimuw.edu.pl) (193.0.96.6) by server-4.tower-216.messagelabs.com with DHE-RSA-AES256-SHA encrypted SMTP; 4 Sep 2011 21:51:37 -0000 Received: from localhost (localhost [127.0.0.1] ident=amavis) by duch.mimuw.edu.pl (Postfix) with ESMTP id C8C9953; Sun, 4 Sep 2011 23:51:36 +0200 (CEST) X-Virus-Scanned: amavisd-new at mimuw.edu.pl Received: by duch.mimuw.edu.pl (Postfix, from userid 1575) id 282113E; Sun, 4 Sep 2011 23:51:36 +0200 (CEST) Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Mercurial-Node: 4683409fac3d4fef836ce78f01f12b31f5f9e12a Message-Id: <4683409fac3d4fef836c.1315173032@devel14> User-Agent: Mercurial-patchbomb/1.8.4 Date: Sun, 04 Sep 2011 23:50:32 +0200 From: Marek Marczykowski To: xen-devel@lists.xensource.com Cc: marmarek@mimuw.edu.pl Subject: [Xen-devel] [PATCH] libxl: fix double free at get_all_assigned_devices X-BeenThere: xen-devel@lists.xensource.com X-Mailman-Version: 2.1.5 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xensource.com Errors-To: xen-devel-bounces@lists.xensource.com # HG changeset patch # User Marek Marczykowski # Date 1315172996 -7200 # Node ID 4683409fac3d4fef836ce78f01f12b31f5f9e12a # Parent 6239209bb560b4931d4d97456c82c1a5ca4bd10a libxl: fix double free at get_all_assigned_devices Do not free() list manually - it will be freed by libxl__free_all. Signed-off-by: Marek Marczykowski diff --git a/tools/libxl/libxl_pci.c b/tools/libxl/libxl_pci.c --- a/tools/libxl/libxl_pci.c +++ b/tools/libxl/libxl_pci.c @@ -469,7 +469,6 @@ static int get_all_assigned_devices(libx } if ( 0 == *num ) { - free(pcidevs); pcidevs = NULL; }else{ *list = pcidevs; _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel From xen-devel-bounces@lists.xensource.com Sun Sep 04 15:07:30 2011 Return-path: Envelope-to: www-data@lists.xensource.com Delivery-date: Sun, 04 Sep 2011 15:07:30 -0700 Received: from localhost ([127.0.0.1] helo=lists.colo.xensource.com) by lists.xensource.com with esmtp (Exim 4.43) id 1R0Kqg-0004sQ-28; Sun, 04 Sep 2011 15:07:30 -0700 Received: from mail216.messagelabs.com ([85.158.143.99]) by lists.xensource.com with esmtp (Exim 4.43) id 1R0Kot-0004ei-DK for xen-devel@lists.xensource.com; Sun, 04 Sep 2011 15:05:47 -0700 X-Env-Sender: marmarek@mimuw.edu.pl X-Msg-Ref: server-4.tower-216.messagelabs.com!1315173934!17015373!1 X-Originating-IP: [193.0.96.6] X-StarScan-Version: 6.3.6; banners=-,-,- X-VirusChecked: Checked Received: (qmail 22878 invoked from network); 4 Sep 2011 22:05:35 -0000 Received: from mail.mimuw.edu.pl (HELO mail.mimuw.edu.pl) (193.0.96.6) by server-4.tower-216.messagelabs.com with DHE-RSA-AES256-SHA encrypted SMTP; 4 Sep 2011 22:05:35 -0000 Received: from localhost (localhost [127.0.0.1] ident=amavis) by duch.mimuw.edu.pl (Postfix) with ESMTP id 800991EC; Mon, 5 Sep 2011 00:05:34 +0200 (CEST) X-Virus-Scanned: amavisd-new at mimuw.edu.pl Received: from duch.mimuw.edu.pl ([127.0.0.1]) by localhost (mail.mimuw.edu.pl [127.0.0.1]) (amavisd-new, port 10026) with ESMTP id GGviOctyvS5p; Mon, 5 Sep 2011 00:05:33 +0200 (CEST) Received: from [10.137.1.11] (87-206-116-192.dynamic.chello.pl [87.206.116.192]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (No client certificate requested) by duch.mimuw.edu.pl (Postfix) with ESMTPSA; Mon, 5 Sep 2011 00:05:33 +0200 (CEST) Message-ID: <4E63F630.5090607@mimuw.edu.pl> Date: Mon, 05 Sep 2011 00:05:36 +0200 From: Marek Marczykowski User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.2.18) Gecko/20110621 Fedora/3.1.11-1.fc14 Lightning/1.0b3pre Thunderbird/3.1.11 MIME-Version: 1.0 To: Marek Marczykowski References: <4683409fac3d4fef836c.1315173032@devel14> In-Reply-To: <4683409fac3d4fef836c.1315173032@devel14> X-Enigmail-Version: 1.1.2 Cc: xen-devel@lists.xensource.com Subject: [Xen-devel] Re: [PATCH] libxl: fix double free at get_all_assigned_devices X-BeenThere: xen-devel@lists.xensource.com X-Mailman-Version: 2.1.5 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0590964966==" Sender: xen-devel-bounces@lists.xensource.com Errors-To: xen-devel-bounces@lists.xensource.com This is a cryptographically signed message in MIME format. --===============0590964966== Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha1; boundary="------------ms060805060407040800080206" This is a cryptographically signed message in MIME format. --------------ms060805060407040800080206 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On 04.09.2011 23:50, Marek Marczykowski wrote: > # HG changeset patch > # User Marek Marczykowski > # Date 1315172996 -7200 > # Node ID 4683409fac3d4fef836ce78f01f12b31f5f9e12a > # Parent 6239209bb560b4931d4d97456c82c1a5ca4bd10a > libxl: fix double free at get_all_assigned_devices >=20 > Do not free() list manually - it will be freed by libxl__free_all. >=20 > Signed-off-by: Marek Marczykowski Ah, it is for xen-4.1. In unstable seems to be ok. > diff --git a/tools/libxl/libxl_pci.c b/tools/libxl/libxl_pci.c > --- a/tools/libxl/libxl_pci.c > +++ b/tools/libxl/libxl_pci.c > @@ -469,7 +469,6 @@ static int get_all_assigned_devices(libx > } > =20 > if ( 0 =3D=3D *num ) { > - free(pcidevs); > pcidevs =3D NULL; > }else{ > *list =3D pcidevs; >=20 >=20 --=20 Pozdrawiam / Best Regards, Marek Marczykowski | RLU #390519 marmarek at mimuw edu pl | xmpp:marmarek at staszic waw pl --------------ms060805060407040800080206 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIRqDCC BVcwggQ/oAMCAQICEGdLwnOg7SU/xzieX7FaFewwDQYJKoZIhvcNAQEFBQAwgd0xCzAJBgNV BAYTAlVTMRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNpZ24gVHJ1 c3QgTmV0d29yazE7MDkGA1UECxMyVGVybXMgb2YgdXNlIGF0IGh0dHBzOi8vd3d3LnZlcmlz aWduLmNvbS9ycGEgKGMpMDkxHjAcBgNVBAsTFVBlcnNvbmEgTm90IFZhbGlkYXRlZDE3MDUG A1UEAxMuVmVyaVNpZ24gQ2xhc3MgMSBJbmRpdmlkdWFsIFN1YnNjcmliZXIgQ0EgLSBHMzAe Fw0xMDEyMDgwMDAwMDBaFw0xMTEyMDgyMzU5NTlaMIIBGjEXMBUGA1UEChMOVmVyaVNpZ24s IEluYy4xHzAdBgNVBAsTFlZlcmlTaWduIFRydXN0IE5ldHdvcmsxRjBEBgNVBAsTPXd3dy52 ZXJpc2lnbi5jb20vcmVwb3NpdG9yeS9SUEEgSW5jb3JwLiBieSBSZWYuLExJQUIuTFREKGMp OTgxHjAcBgNVBAsTFVBlcnNvbmEgTm90IFZhbGlkYXRlZDEzMDEGA1UECxMqRGlnaXRhbCBJ RCBDbGFzcyAxIC0gTmV0c2NhcGUgRnVsbCBTZXJ2aWNlMRswGQYDVQQDFBJNQVJFSyBNYXJj enlrb3dza2kxJDAiBgkqhkiG9w0BCQEWFW1hcm1hcmVrQG1pbXV3LmVkdS5wbDCCASIwDQYJ KoZIhvcNAQEBBQADggEPADCCAQoCggEBAMGGGDj1KJXXy13nNqo0NP7EJNnzjWHih+Z88UA/ c/CZOIu3/SUnA9gly922moQ+r4AM0k6EQaVkAdldSOy1hO/fTcJQBwDemcnACWstMDMvIbWn dkxyxNgh8bQD/xKXx1SyfKTixcx0QZXosY8HnHLWeF0Te5U9J8yUPxigCFJFe6rtY2iARrWc qWXDr4DRQc5J43aohBXGRHw+OakREqLZds6HEE6+YvJH+udcfqlrfkLKHJeiyA4UPtZwBvam EGOKrm2rqyps/JeivaTs6zKh0+4eNxSKlOGTUmj4eHVb/K3gkbX6bihmWS+9nnN3I4HL+KPZ j88xQCHX07Gh4nECAwEAAaOB0jCBzzAJBgNVHRMEAjAAMEQGA1UdIAQ9MDswOQYLYIZIAYb4 RQEHFwEwKjAoBggrBgEFBQcCARYcaHR0cHM6Ly93d3cudmVyaXNpZ24uY29tL3JwYTALBgNV HQ8EBAMCBaAwHQYDVR0lBBYwFAYIKwYBBQUHAwQGCCsGAQUFBwMCMFAGA1UdHwRJMEcwRaBD oEGGP2h0dHA6Ly9pbmRjMWRpZ2l0YWxpZC1nMy1jcmwudmVyaXNpZ24uY29tL0luZEMxRGln aXRhbElELUczLmNybDANBgkqhkiG9w0BAQUFAAOCAQEAl7oehxokYa9omPurM44GROaRxtIQ acWWpCgeMNDqJXyEgm30u0hY1szXiSyVnkIx/sh4HuBqvXJnZZvLjksEIzdALTgCAskojzeT oeX+340loS87OO82/XUDT5YY3+R5G+4oQIxKVqF7kDmOuJ2opbjU4dFxHhIypiEcWjG2sjWd 127poxMQeY4lCk3qKw94pK5RpVPJK8hzaf+pWoL2D7i3L2xE+DMzZJ1OB3AxcGxhvupUq+zz 3Z9IIHo6DNOwUyCNR+ShVnuCaoJcya35mQzhs1s5+LcP/ysrUzhPo+iYNXGv+q5iNQEXZ7Dw kPgAm17fnxmih6D4KRbmrc3xpjCCBVcwggQ/oAMCAQICEGdLwnOg7SU/xzieX7FaFewwDQYJ KoZIhvcNAQEFBQAwgd0xCzAJBgNVBAYTAlVTMRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEf MB0GA1UECxMWVmVyaVNpZ24gVHJ1c3QgTmV0d29yazE7MDkGA1UECxMyVGVybXMgb2YgdXNl IGF0IGh0dHBzOi8vd3d3LnZlcmlzaWduLmNvbS9ycGEgKGMpMDkxHjAcBgNVBAsTFVBlcnNv bmEgTm90IFZhbGlkYXRlZDE3MDUGA1UEAxMuVmVyaVNpZ24gQ2xhc3MgMSBJbmRpdmlkdWFs IFN1YnNjcmliZXIgQ0EgLSBHMzAeFw0xMDEyMDgwMDAwMDBaFw0xMTEyMDgyMzU5NTlaMIIB GjEXMBUGA1UEChMOVmVyaVNpZ24sIEluYy4xHzAdBgNVBAsTFlZlcmlTaWduIFRydXN0IE5l dHdvcmsxRjBEBgNVBAsTPXd3dy52ZXJpc2lnbi5jb20vcmVwb3NpdG9yeS9SUEEgSW5jb3Jw LiBieSBSZWYuLExJQUIuTFREKGMpOTgxHjAcBgNVBAsTFVBlcnNvbmEgTm90IFZhbGlkYXRl ZDEzMDEGA1UECxMqRGlnaXRhbCBJRCBDbGFzcyAxIC0gTmV0c2NhcGUgRnVsbCBTZXJ2aWNl MRswGQYDVQQDFBJNQVJFSyBNYXJjenlrb3dza2kxJDAiBgkqhkiG9w0BCQEWFW1hcm1hcmVr QG1pbXV3LmVkdS5wbDCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAMGGGDj1KJXX y13nNqo0NP7EJNnzjWHih+Z88UA/c/CZOIu3/SUnA9gly922moQ+r4AM0k6EQaVkAdldSOy1 hO/fTcJQBwDemcnACWstMDMvIbWndkxyxNgh8bQD/xKXx1SyfKTixcx0QZXosY8HnHLWeF0T e5U9J8yUPxigCFJFe6rtY2iARrWcqWXDr4DRQc5J43aohBXGRHw+OakREqLZds6HEE6+YvJH +udcfqlrfkLKHJeiyA4UPtZwBvamEGOKrm2rqyps/JeivaTs6zKh0+4eNxSKlOGTUmj4eHVb /K3gkbX6bihmWS+9nnN3I4HL+KPZj88xQCHX07Gh4nECAwEAAaOB0jCBzzAJBgNVHRMEAjAA MEQGA1UdIAQ9MDswOQYLYIZIAYb4RQEHFwEwKjAoBggrBgEFBQcCARYcaHR0cHM6Ly93d3cu dmVyaXNpZ24uY29tL3JwYTALBgNVHQ8EBAMCBaAwHQYDVR0lBBYwFAYIKwYBBQUHAwQGCCsG AQUFBwMCMFAGA1UdHwRJMEcwRaBDoEGGP2h0dHA6Ly9pbmRjMWRpZ2l0YWxpZC1nMy1jcmwu dmVyaXNpZ24uY29tL0luZEMxRGlnaXRhbElELUczLmNybDANBgkqhkiG9w0BAQUFAAOCAQEA l7oehxokYa9omPurM44GROaRxtIQacWWpCgeMNDqJXyEgm30u0hY1szXiSyVnkIx/sh4HuBq vXJnZZvLjksEIzdALTgCAskojzeToeX+340loS87OO82/XUDT5YY3+R5G+4oQIxKVqF7kDmO uJ2opbjU4dFxHhIypiEcWjG2sjWd127poxMQeY4lCk3qKw94pK5RpVPJK8hzaf+pWoL2D7i3 L2xE+DMzZJ1OB3AxcGxhvupUq+zz3Z9IIHo6DNOwUyCNR+ShVnuCaoJcya35mQzhs1s5+LcP /ysrUzhPo+iYNXGv+q5iNQEXZ7DwkPgAm17fnxmih6D4KRbmrc3xpjCCBu4wggXWoAMCAQIC EHEVZgVK5JEhTem8RPms09wwDQYJKoZIhvcNAQEFBQAwgcoxCzAJBgNVBAYTAlVTMRcwFQYD VQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNpZ24gVHJ1c3QgTmV0d29yazE6 MDgGA1UECxMxKGMpIDE5OTkgVmVyaVNpZ24sIEluYy4gLSBGb3IgYXV0aG9yaXplZCB1c2Ug b25seTFFMEMGA1UEAxM8VmVyaVNpZ24gQ2xhc3MgMSBQdWJsaWMgUHJpbWFyeSBDZXJ0aWZp Y2F0aW9uIEF1dGhvcml0eSAtIEczMB4XDTA5MDUwMTAwMDAwMFoXDTE5MDQzMDIzNTk1OVow gd0xCzAJBgNVBAYTAlVTMRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVy aVNpZ24gVHJ1c3QgTmV0d29yazE7MDkGA1UECxMyVGVybXMgb2YgdXNlIGF0IGh0dHBzOi8v d3d3LnZlcmlzaWduLmNvbS9ycGEgKGMpMDkxHjAcBgNVBAsTFVBlcnNvbmEgTm90IFZhbGlk YXRlZDE3MDUGA1UEAxMuVmVyaVNpZ24gQ2xhc3MgMSBJbmRpdmlkdWFsIFN1YnNjcmliZXIg Q0EgLSBHMzCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAO3ER98qKB18Bmu71yEy yWwTj+mxjUFONPfaC+Nq+mWIIAsRE+mb4ElOi2/VAdBfDUeRilpMdD4/xpEJu0w0no1uoYJR YvdpdliWB6+eFBgHT1q9n9IxslQZc0ZqGUIR7BJzIY313DDN5dlWCjHFNm0pFJe9LdqJRxmI 2EsEPeu2PGcedAATDdCG2pNn+DMDrho8a2l49sAsjuGDP3f5mf/+n1JawrSHCthsqUfBVCll Qz5KwJYfwa33d69ssQRevsG2lC2XkC0n0rse6YNqhPbEsq4jBmUmpSdYKwcitG+mYkgad/LV UCeaKdOW+yj1uiR2YuOMWev7btVCxL5Bx/UCAwEAAaOCArkwggK1MDQGCCsGAQUFBwEBBCgw JjAkBggrBgEFBQcwAYYYaHR0cDovL29jc3AudmVyaXNpZ24uY29tMBIGA1UdEwEB/wQIMAYB Af8CAQAwcAYDVR0gBGkwZzBlBgtghkgBhvhFAQcXATBWMCgGCCsGAQUFBwIBFhxodHRwczov L3d3dy52ZXJpc2lnbi5jb20vY3BzMCoGCCsGAQUFBwICMB4aHGh0dHBzOi8vd3d3LnZlcmlz aWduLmNvbS9ycGEwNAYDVR0fBC0wKzApoCegJYYjaHR0cDovL2NybC52ZXJpc2lnbi5jb20v cGNhMS1nMy5jcmwwDgYDVR0PAQH/BAQDAgEGMG4GCCsGAQUFBwEMBGIwYKFeoFwwWjBYMFYW CWltYWdlL2dpZjAhMB8wBwYFKw4DAhoEFEtruSiWBgy70FI4mymsSweLIQUYMCYWJGh0dHA6 Ly9sb2dvLnZlcmlzaWduLmNvbS92c2xvZ28xLmdpZjAuBgNVHREEJzAlpCMwITEfMB0GA1UE AxMWUHJpdmF0ZUxhYmVsNC0yMDQ4LTExODAdBgNVHQ4EFgQUeUdhCEH9OASiS+e1zPVD9kkr EfgwgfEGA1UdIwSB6TCB5qGB0KSBzTCByjELMAkGA1UEBhMCVVMxFzAVBgNVBAoTDlZlcmlT aWduLCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMTowOAYDVQQLEzEo YykgMTk5OSBWZXJpU2lnbiwgSW5jLiAtIEZvciBhdXRob3JpemVkIHVzZSBvbmx5MUUwQwYD VQQDEzxWZXJpU2lnbiBDbGFzcyAxIFB1YmxpYyBQcmltYXJ5IENlcnRpZmljYXRpb24gQXV0 aG9yaXR5IC0gRzOCEQCLW3VWhFSFCwDPrzhIzrGkMA0GCSqGSIb3DQEBBQUAA4IBAQA5Tc9B mYG1qQW1UjjpOYSJbOQ0qFrn2GwJTCQaulmkhztzIfGTgc+/aGNaZ/41hSuhw12jSsI6Gd0w 1sxN7/HSgZfKVFpDvzeLeo4ZjQ9DqIzyr2CzFYqzlZw84J6zJ5ikNXIX5fwqXYfTig3C0UUq +MD0rCqTOtWuEnAI6/s74nfs6CtkNXbNutrg0csU1nFYm77VPn222egkxSRmTF2RH3azFz5/ DcYhiS+zN7ih/1yybUneZVJC+w6I0u1KHb9L4/jMcvpIDmWOScjW+JmYO7eUPjFxBof6bFlT LtffK+1fYwCsFe0DuFUWjMZoA+ciqHMLsbyg2lJY3QoOf8GCMYIE7DCCBOgCAQEwgfIwgd0x CzAJBgNVBAYTAlVTMRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNp Z24gVHJ1c3QgTmV0d29yazE7MDkGA1UECxMyVGVybXMgb2YgdXNlIGF0IGh0dHBzOi8vd3d3 LnZlcmlzaWduLmNvbS9ycGEgKGMpMDkxHjAcBgNVBAsTFVBlcnNvbmEgTm90IFZhbGlkYXRl ZDE3MDUGA1UEAxMuVmVyaVNpZ24gQ2xhc3MgMSBJbmRpdmlkdWFsIFN1YnNjcmliZXIgQ0Eg LSBHMwIQZ0vCc6DtJT/HOJ5fsVoV7DAJBgUrDgMCGgUAoIICzjAYBgkqhkiG9w0BCQMxCwYJ KoZIhvcNAQcBMBwGCSqGSIb3DQEJBTEPFw0xMTA5MDQyMjA1MzdaMCMGCSqGSIb3DQEJBDEW BBQRf2+9n3QAx73liRa8xYATJHHUljBfBgkqhkiG9w0BCQ8xUjBQMAsGCWCGSAFlAwQBAjAK BggqhkiG9w0DBzAOBggqhkiG9w0DAgICAIAwDQYIKoZIhvcNAwICAUAwBwYFKw4DAgcwDQYI KoZIhvcNAwICASgwggEDBgkrBgEEAYI3EAQxgfUwgfIwgd0xCzAJBgNVBAYTAlVTMRcwFQYD VQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNpZ24gVHJ1c3QgTmV0d29yazE7 MDkGA1UECxMyVGVybXMgb2YgdXNlIGF0IGh0dHBzOi8vd3d3LnZlcmlzaWduLmNvbS9ycGEg KGMpMDkxHjAcBgNVBAsTFVBlcnNvbmEgTm90IFZhbGlkYXRlZDE3MDUGA1UEAxMuVmVyaVNp Z24gQ2xhc3MgMSBJbmRpdmlkdWFsIFN1YnNjcmliZXIgQ0EgLSBHMwIQZ0vCc6DtJT/HOJ5f sVoV7DCCAQUGCyqGSIb3DQEJEAILMYH1oIHyMIHdMQswCQYDVQQGEwJVUzEXMBUGA1UEChMO VmVyaVNpZ24sIEluYy4xHzAdBgNVBAsTFlZlcmlTaWduIFRydXN0IE5ldHdvcmsxOzA5BgNV BAsTMlRlcm1zIG9mIHVzZSBhdCBodHRwczovL3d3dy52ZXJpc2lnbi5jb20vcnBhIChjKTA5 MR4wHAYDVQQLExVQZXJzb25hIE5vdCBWYWxpZGF0ZWQxNzA1BgNVBAMTLlZlcmlTaWduIENs YXNzIDEgSW5kaXZpZHVhbCBTdWJzY3JpYmVyIENBIC0gRzMCEGdLwnOg7SU/xzieX7FaFeww DQYJKoZIhvcNAQEBBQAEggEAplp/e/9+TQR1Dqb4plZgAqEDYt+d1c9B5oH2/FoMLtLGWpoy EPlvo0TsOGTF7mXqu273s92bYfE3RLRxWnun3ZXRK+4gd4jqG/dP1ektaD4FHR3NDfmWPa76 Pi+etasNnTwO0ENQWZgXBfc1NdobLaqIA5MPpi50LGloJmRrdUBtbc6oi6eIdkvrtPvB+ULc r0qccxl6P677ED36JrI8++jwvYsc90+D0BcIqL+pfIoICLmmFHt5/adZHMqrIAyX/qpDIPuL 9SB/0hFyg5JIghDsm0Pf9u/jg3Elxm/EylVyUqwSVdDGwQHjgt87ncOoDW7uhZ9e9aHLiYti USFyCgAAAAAAAA== --------------ms060805060407040800080206-- --===============0590964966== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel --===============0590964966==-- From xen-devel-bounces@lists.xensource.com Sun Sep 04 18:33:58 2011 Return-path: Envelope-to: www-data@lists.xensource.com Delivery-date: Sun, 04 Sep 2011 18:33:58 -0700 Received: from localhost ([127.0.0.1] helo=lists.colo.xensource.com) by lists.xensource.com with esmtp (Exim 4.43) id 1R0O4U-0000Aq-OM; Sun, 04 Sep 2011 18:33:58 -0700 Received: from mail174.messagelabs.com ([85.158.138.51]) by lists.xensource.com with smtp (Exim 4.43) id 1R0O3X-0008PQ-GG for xen-devel@lists.xensource.com; Sun, 04 Sep 2011 18:32:59 -0700 X-Env-Sender: xudong.hao@intel.com X-Msg-Ref: server-14.tower-174.messagelabs.com!1315186375!30215903!1 X-Originating-IP: [192.55.52.88] X-StarScan-Version: 6.3.6; banners=-,-,- X-VirusChecked: Checked Received: (qmail 25040 invoked from network); 5 Sep 2011 01:32:56 -0000 Received: from mga01.intel.com (HELO mga01.intel.com) (192.55.52.88) by server-14.tower-174.messagelabs.com with SMTP; 5 Sep 2011 01:32:56 -0000 Received: from fmsmga002.fm.intel.com ([10.253.24.26]) by fmsmga101.fm.intel.com with ESMTP; 04 Sep 2011 18:32:54 -0700 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="4.68,330,1312182000"; d="scan'208";a="48866970" Received: from pgsmsx602.gar.corp.intel.com ([10.221.43.81]) by fmsmga002.fm.intel.com with ESMTP; 04 Sep 2011 18:32:54 -0700 Received: from pgsmsx103.gar.corp.intel.com (10.221.44.82) by pgsmsx602.gar.corp.intel.com (10.221.43.81) with Microsoft SMTP Server (TLS) id 8.2.255.0; Mon, 5 Sep 2011 09:32:21 +0800 Received: from shsmsx602.ccr.corp.intel.com (10.239.4.104) by PGSMSX103.gar.corp.intel.com (10.221.44.82) with Microsoft SMTP Server (TLS) id 14.1.323.3; Mon, 5 Sep 2011 09:32:20 +0800 Received: from shsmsx502.ccr.corp.intel.com ([10.239.4.96]) by SHSMSX602.ccr.corp.intel.com ([10.239.4.104]) with mapi; Mon, 5 Sep 2011 09:31:39 +0800 From: "Hao, Xudong" To: "xen-devel@lists.xensource.com" Date: Mon, 5 Sep 2011 09:31:37 +0800 Thread-Topic: XEN 4.1.2-rc1 test report Thread-Index: AcxraPEQ5d5QYlfkRtiN0IqyWRUXBw== Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: [Xen-devel] XEN 4.1.2-rc1 test report X-BeenThere: xen-devel@lists.xensource.com X-Mailman-Version: 2.1.5 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xensource.com Errors-To: xen-devel-bounces@lists.xensource.com Hi, all This is the test report for xen 4.1.2-rc1. The bug that VT-d 1G super page = does not work got fixed on Xen 4.1 23128, the Windows2008 BSOD when shutdow= n issue also exist on Xen 4.1 tree too. Version Info =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D xen-changeset: Xen 4.1 testing 23122:d78a122898d5 pvops git: commit 20a27c1e25b8550066902c9d6ca91631e656dfa3 =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D Test Environment =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D Platform Romley-EP(x86_64) Westmere-EP(x86_64) CPU 32 24 Memory 28G 12G =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D New issue(1) =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D 1. 'VT-d 1G super page' feature is blocked ----fixed and verified on = Xen 4.1 #23128 http://bugzilla.xensource.com/bugzilla/show_bug.cgi?id=3D1774 2. Windows2k8 guest shows blue screen when shut down http://bugzilla.xensource.com/bugzilla/show_bug.cgi?id=3D1778 _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel From xen-devel-bounces@lists.xensource.com Sun Sep 04 18:50:14 2011 Return-path: Envelope-to: www-data@lists.xensource.com Delivery-date: Sun, 04 Sep 2011 18:50:14 -0700 Received: from localhost ([127.0.0.1] helo=lists.colo.xensource.com) by lists.xensource.com with esmtp (Exim 4.43) id 1R0OKD-0000mv-TJ; Sun, 04 Sep 2011 18:50:13 -0700 Received: from mail27.messagelabs.com ([193.109.254.147]) by lists.xensource.com with smtp (Exim 4.43) id 1R0OJQ-0000aK-S1 for xen-devel@lists.xensource.com; Sun, 04 Sep 2011 18:49:25 -0700 X-Env-Sender: xudong.hao@intel.com X-Msg-Ref: server-13.tower-27.messagelabs.com!1315187350!38642382!1 X-Originating-IP: [192.55.52.93] X-StarScan-Version: 6.3.6; banners=-,-,- X-VirusChecked: Checked Received: (qmail 25087 invoked from network); 5 Sep 2011 01:49:11 -0000 Received: from mga11.intel.com (HELO mga11.intel.com) (192.55.52.93) by server-13.tower-27.messagelabs.com with SMTP; 5 Sep 2011 01:49:11 -0000 Received: from fmsmga002.fm.intel.com ([10.253.24.26]) by fmsmga102.fm.intel.com with ESMTP; 04 Sep 2011 18:49:20 -0700 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="4.68,330,1312182000"; d="scan'208";a="48869676" Received: from pgsmsx601.gar.corp.intel.com ([10.221.43.69]) by fmsmga002.fm.intel.com with ESMTP; 04 Sep 2011 18:49:20 -0700 Received: from shsmsx601.ccr.corp.intel.com (10.239.4.112) by pgsmsx601.gar.corp.intel.com (10.221.43.69) with Microsoft SMTP Server (TLS) id 8.2.255.0; Mon, 5 Sep 2011 09:48:50 +0800 Received: from shsmsx502.ccr.corp.intel.com ([10.239.4.96]) by shsmsx601.ccr.corp.intel.com ([10.239.4.112]) with mapi; Mon, 5 Sep 2011 09:48:49 +0800 From: "Hao, Xudong" To: "xen-devel@lists.xensource.com" Date: Mon, 5 Sep 2011 09:48:48 +0800 Thread-Topic: Biweekly Xen status report. Xen:23799 & Dom0:1c3f03cc... Thread-Index: AcxrbQakBxuJVj5PRO2d+1YzxSu/cQ== Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: [Xen-devel] Biweekly Xen status report. Xen:23799 & Dom0:1c3f03cc... X-BeenThere: xen-devel@lists.xensource.com X-Mailman-Version: 2.1.5 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xensource.com Errors-To: xen-devel-bounces@lists.xensource.com Hi all, This is the test report for xen-unstable Cset #23799. 4 old bugs got fixed = recently, open 1 new bug which is Windows2008 guest will BSOD when shutdown= .=20 Version Info =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D xen_changeset : Tue Aug 30 11:46:58 2011 +0100 23799:ac9aa65050e9=20 pvops git commit: 1c3f03ccc5258887f5f2cafc0836a865834f9205 =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D Test Environment =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D Platform Romley-EP(x86_64) Westmere-EP(x86_64) CPU 32 24 Memory 28G 12G =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D New issue(1) =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D 1. Windows2k8 guest shows blue screen when shut down http://bugzilla.xensource.com/bugzilla/show_bug.cgi?id=3D1778 Fixed issues(4) =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D 1. [Hypervisor]Xen complains msi error when startup http://bugzilla.xensource.com/bugzilla/show_bug.cgi?id=3D1732 2. 'VT-d 1G super page' feature is blocked http://bugzilla.xensource.com/bugzilla/show_bug.cgi?id=3D1774 3. [xl]Fail to create multi-guests with NIC assigned http://bugzilla.xensource.com/bugzilla/show_bug.cgi?id=3D1761 4. [VT-D] xen panic when the second time to creating guest with a NIC assig= ned http://bugzilla.xensource.com/bugzilla/show_bug.cgi?id=3D1771 Old issues(7) =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D 1. [ACPI] System cann't resume after do suspend http://bugzilla.xensource.com/bugzilla/show_bug.cgi?id=3D1707 2.[XL]"xl vcpu-set" causes dom0 crash or panic http://bugzilla.xensource.com/bugzilla/show_bug.cgi?id=3D1730 3.[VT-D]fail to detach NIC from guest http://bugzilla.xensource.com/bugzilla/show_bug.cgi?id=3D1736 4.[Save/Restore] guest failed to reboot after L-Migration it http://bugzilla.xensource.com/bugzilla/show_bug.cgi?id=3D1739 5.Dom0 crash on power-off http://bugzilla.xensource.com/bugzilla/show_bug.cgi?id=3D1740 6.Sometimes Xen panic on ia32pae Sandybridge when restore guest http://bugzilla.xensource.com/bugzilla/show_bug.cgi?id=3D1747 7.[VT-D] device reset fail when create/destroy guest http://bugzilla.xensource.com/bugzilla/show_bug.cgi?id=3D1752 Best Regards, Xudong Hao _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel From xen-devel-bounces@lists.xensource.com Sun Sep 04 20:35:47 2011 Return-path: Envelope-to: www-data@lists.xensource.com Delivery-date: Sun, 04 Sep 2011 20:35:47 -0700 Received: from localhost ([127.0.0.1] helo=lists.colo.xensource.com) by lists.xensource.com with esmtp (Exim 4.43) id 1R0PyM-0002oQ-W9; Sun, 04 Sep 2011 20:35:47 -0700 Received: from mail216.messagelabs.com ([85.158.143.99]) by lists.xensource.com with smtp (Exim 4.43) id 1R0PxW-0002Yq-Qw for xen-devel@lists.xensource.com; Sun, 04 Sep 2011 20:34:55 -0700 X-Env-Sender: Ian.Jackson@eu.citrix.com X-Msg-Ref: server-7.tower-216.messagelabs.com!1315193691!17051389!1 X-Originating-IP: [62.200.22.115] X-StarScan-Version: 6.3.6; banners=-,-,- X-VirusChecked: Checked Received: (qmail 680 invoked from network); 5 Sep 2011 03:34:51 -0000 Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115) by server-7.tower-216.messagelabs.com with SMTP; 5 Sep 2011 03:34:51 -0000 X-IronPort-AV: E=Sophos;i="4.68,330,1312156800"; d="scan'208";a="7595728" Received: from lonpmailmx01.citrite.net ([10.30.203.162]) by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5; 05 Sep 2011 03:34:51 +0000 Received: from woking.xci-test.com (10.80.248.135) by smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id 8.3.137.0; Mon, 5 Sep 2011 04:34:51 +0100 Received: from osstest by woking.xci-test.com with local (Exim 4.69) (envelope-from ) id 1R0PxS-0003b7-SK; Mon, 05 Sep 2011 04:34:50 +0100 To: xen-devel@lists.xensource.com Message-ID: From: xen.org Date: Mon, 5 Sep 2011 04:34:50 +0100 MIME-Version: 1.0 Content-Type: text/plain Cc: ian.jackson@eu.citrix.com Subject: [Xen-devel] [xen-unstable test] 8829: tolerable FAIL X-BeenThere: xen-devel@lists.xensource.com X-Mailman-Version: 2.1.5 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xensource.com Errors-To: xen-devel-bounces@lists.xensource.com flight 8829 xen-unstable real [real] http://www.chiark.greenend.org.uk/~xensrcts/logs/8829/ Failures :-/ but no regressions. Tests which did not succeed, but are not blocking, including regressions (tests previously passed) regarded as allowable: test-amd64-amd64-xl-pcipt-intel 9 guest-start fail never pass test-amd64-i386-rhel6hvm-intel 9 guest-start.2 fail never pass test-amd64-i386-win-vcpus1 16 leak-check/check fail never pass test-amd64-i386-xl-win-vcpus1 13 guest-stop fail never pass test-amd64-i386-rhel6hvm-amd 9 guest-start.2 fail never pass test-amd64-i386-win 16 leak-check/check fail never pass test-amd64-amd64-win 16 leak-check/check fail never pass test-amd64-amd64-xl-win 13 guest-stop fail never pass test-i386-i386-xl-win 13 guest-stop fail never pass test-i386-i386-win 16 leak-check/check fail never pass version targeted for testing: xen f1349a968a5a baseline version: xen f1349a968a5a jobs: build-amd64 pass build-i386 pass build-amd64-oldkern pass build-i386-oldkern pass build-amd64-pvops pass build-i386-pvops pass test-amd64-amd64-xl pass test-amd64-i386-xl pass test-i386-i386-xl pass test-amd64-i386-rhel6hvm-amd fail test-amd64-i386-xl-credit2 pass test-amd64-amd64-xl-pcipt-intel fail test-amd64-i386-rhel6hvm-intel fail test-amd64-i386-xl-multivcpu pass test-amd64-amd64-pair pass test-amd64-i386-pair pass test-i386-i386-pair pass test-amd64-amd64-pv pass test-amd64-i386-pv pass test-i386-i386-pv pass test-amd64-amd64-xl-sedf pass test-amd64-i386-win-vcpus1 fail test-amd64-i386-xl-win-vcpus1 fail test-amd64-amd64-win fail test-amd64-i386-win fail test-i386-i386-win fail test-amd64-amd64-xl-win fail test-i386-i386-xl-win fail ------------------------------------------------------------ sg-report-flight on woking.cam.xci-test.com logs: /home/xc_osstest/logs images: /home/xc_osstest/images Logs, config files, etc. are available at http://www.chiark.greenend.org.uk/~xensrcts/logs Test harness code can be found at http://xenbits.xensource.com/gitweb?p=osstest.git;a=summary Published tested tree is already up to date. _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel From xen-devel-bounces@lists.xensource.com Mon Sep 05 00:14:39 2011 Return-path: Envelope-to: www-data@lists.xensource.com Delivery-date: Mon, 05 Sep 2011 00:14:39 -0700 Received: from localhost ([127.0.0.1] helo=lists.colo.xensource.com) by lists.xensource.com with esmtp (Exim 4.43) id 1R0TOA-0006dv-Hw; Mon, 05 Sep 2011 00:14:39 -0700 Received: from mail27.messagelabs.com ([193.109.254.147]) by lists.xensource.com with esmtp (Exim 4.43) id 1R0TN4-0006R6-FS for xen-devel@lists.xensource.com; Mon, 05 Sep 2011 00:13:30 -0700 X-Env-Sender: deepak.s@hcl.com X-Msg-Ref: server-8.tower-27.messagelabs.com!1315206790!45226630!1 X-Originating-IP: [203.105.186.26] X-StarScan-Version: 6.3.6; banners=-,-,- X-VirusChecked: Checked Received: (qmail 8080 invoked from network); 5 Sep 2011 07:13:12 -0000 Received: from gws08.hcl.com (HELO gws08.hcl.com) (203.105.186.26) by server-8.tower-27.messagelabs.com with AES256-SHA encrypted SMTP; 5 Sep 2011 07:13:12 -0000 Received: from chn-hclin-ht01.CORP.HCL.IN (10.249.64.35) by CHN-HCLIN-EDGE4.HCL.COM (10.249.64.141) with Microsoft SMTP Server id 8.2.254.0; Mon, 5 Sep 2011 12:43:13 +0530 Received: from CHN-HCLT-CASHT1.HCLT.CORP.HCL.IN (10.108.45.33) by chn-hclin-ht01.CORP.HCL.IN (10.249.64.35) with Microsoft SMTP Server (TLS) id 8.2.254.0; Mon, 5 Sep 2011 12:43:22 +0530 Received: from CHN-HCLT-EVS07.HCLT.CORP.HCL.IN ([fe80::f46b:fdf2:3218:985d]) by CHN-HCLT-CASHT1.HCLT.CORP.HCL.IN ([::1]) with mapi; Mon, 5 Sep 2011 12:43:22 +0530 From: "Deepak Kr. Sharma - ERS, HCL Tech" To: Konrad Rzeszutek Wilk Date: Mon, 5 Sep 2011 12:43:19 +0530 Subject: RE: [Xen-devel] FW: HXEN on linux Thread-Topic: [Xen-devel] FW: HXEN on linux Thread-Index: AcxorbtWbg41Y1C6QwaYXrseK4FnmwC24ZbQ Message-ID: <90F0F47595235141A4380FCF01B0185B2240FEA5E3@CHN-HCLT-EVS07.HCLT.CORP.HCL.IN> References: <90F0F47595235141A4380FCF01B0185B20BC426222@CHN-HCLT-EVS07.HCLT.CORP.HCL.IN> <20110809195159.GA7834@dumpdata.com> <90F0F47595235141A4380FCF01B0185B20BC513BCB@CHN-HCLT-EVS07.HCLT.CORP.HCL.IN> <90F0F47595235141A4380FCF01B0185B20BC585A8A@CHN-HCLT-EVS07.HCLT.CORP.HCL.IN> <90F0F47595235141A4380FCF01B0185B20BC608BBC@CHN-HCLT-EVS07.HCLT.CORP.HCL.IN> <20110901134638.GB23971@dumpdata.com> In-Reply-To: <20110901134638.GB23971@dumpdata.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "todd.deshane.xen@gmail.com" , "xen-devel@lists.xensource.com" , Lars Kurth , Stefano Stabellini X-BeenThere: xen-devel@lists.xensource.com X-Mailman-Version: 2.1.5 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xensource.com Errors-To: xen-devel-bounces@lists.xensource.com Hello Konrad, We want to build expertise in virtualization domain and contribute to open = source community. We have used Xen as type-1 hypervisor and the performance is unprecedented.= We see good potential in HXen as a type-2 hypervisor and some good solutio= ns can be built around it on linux based platforms. Regards, Deepak -----Original Message----- From: Konrad Rzeszutek Wilk [mailto:konrad.wilk@oracle.com]=20 Sent: 01 September 2011 19:17 To: Deepak Kr. Sharma - ERS, HCL Tech Cc: Stefano Stabellini; todd.deshane.xen@gmail.com; xen-devel@lists.xensour= ce.com; Lars Kurth Subject: Re: [Xen-devel] FW: HXEN on linux On Thu, Sep 01, 2011 at 06:00:26PM +0530, Deepak Kr. Sharma - ERS, HCL Tec= h wrote: > Hello All, >=20 > I am sending a doc that captures our understanding of HXen. >=20 > We need inputs and suggestions from you all to correct any discrepancies = and clarify our grey areas. Ok, first question - why are you doing it? >=20 > Based on your inputs, we will define our path ahead. >=20 > Regards, > Deepak >=20 > -----Original Message----- > From: Deepak Kr. Sharma - ERS, HCL Tech > Sent: 30 August 2011 12:41 > To: 'Stefano Stabellini' > Cc: Konrad Rzeszutek Wilk; todd.deshane.xen@gmail.com; xen-devel@lists.xe= nsource.com; Lars Kurth > Subject: RE: [Xen-devel] FW: HXEN on linux >=20 > Hello, >=20 > I understand that there is no document available for HXen. >=20 > Please correct me if I am wrong but I assume that HXen draws some stuff f= rom Xen. Is that correlation known and can it be explained? >=20 > We have started identifying the blocks in HXen and will be sending out ve= ry soon an assessment and understanding of what we want to do. I would requ= est you all to validate the same and give your precious inputs. >=20 > The first challenge is to identify the big picture of HXen and our focus = area. >=20 > Regards, > Deepak >=20 > -----Original Message----- > From: Stefano Stabellini [mailto:stefano.stabellini@eu.citrix.com] > Sent: 26 August 2011 17:37 > To: Deepak Kr. Sharma - ERS, HCL Tech > Cc: Stefano Stabellini; Konrad Rzeszutek Wilk; todd.deshane.xen@gmail.com= ; xen-devel@lists.xensource.com; Lars Kurth > Subject: RE: [Xen-devel] FW: HXEN on linux >=20 > On Fri, 26 Aug 2011, Deepak Kr. Sharma - ERS, HCL Tech wrote: > > Hello, > > > > I have few concerns regarding this project that we want to carry out: > > > > 1. It would be great to get some documents/technical information that w= ill help us to get a better understanding of the work that has already been= done and the work that has to be done, e.g. a detailed architecture of HXe= n will be a great help. >=20 > like Tim wrote, there isn't one. >=20 >=20 > > 2. Is there any preference of development tools on linux? >=20 > you mean, apart from make and gcc? >=20 >=20 > > 3. In the current state, is there a way to configure virtualized hardwa= re? For example, can we configure the network card or sound card that is be= ing virtualized to the guest OS? >=20 > I think qemu is still used as hardware emulator in HXEN, so there should > be some degrees of configuration. >=20 > ::DISCLAIMER:: > -------------------------------------------------------------------------= ---------------------------------------------- >=20 > The contents of this e-mail and any attachment(s) are confidential and in= tended for the named recipient(s) only. > It shall not attach any liability on the originator or HCL or its affilia= tes. Any views or opinions presented in > this email are solely those of the author and may not necessarily reflect= the opinions of HCL or its affiliates. > Any form of reproduction, dissemination, copying, disclosure, modificatio= n, distribution and / or publication of > this message without the prior written consent of the author of this e-ma= il is strictly prohibited. If you have > received this email in error please delete it and notify the sender immed= iately. Before opening any mail and > attachments please check them for viruses and defect. >=20 > -------------------------------------------------------------------------= ---------------------------------------------- > _______________________________________________ > Xen-devel mailing list > Xen-devel@lists.xensource.com > http://lists.xensource.com/xen-devel _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel From xen-devel-bounces@lists.xensource.com Mon Sep 05 01:15:31 2011 Return-path: Envelope-to: www-data@lists.xensource.com Delivery-date: Mon, 05 Sep 2011 01:15:31 -0700 Received: from localhost ([127.0.0.1] helo=lists.colo.xensource.com) by lists.xensource.com with esmtp (Exim 4.43) id 1R0UL4-00084Z-UK; Mon, 05 Sep 2011 01:15:30 -0700 Received: from mail21.messagelabs.com ([85.158.143.35]) by lists.xensource.com with esmtp (Exim 4.43) id 1R0UJm-0007rg-Db for xen-devel@lists.xensource.com; Mon, 05 Sep 2011 01:14:11 -0700 X-Env-Sender: JBeulich@suse.com X-Msg-Ref: server-8.tower-21.messagelabs.com!1315210432!57733489!1 X-Originating-IP: [130.57.49.28] X-StarScan-Version: 6.3.6; banners=-,-,- X-VirusChecked: Checked Received: (qmail 30477 invoked from network); 5 Sep 2011 08:13:52 -0000 Received: from nat28.tlf.novell.com (HELO nat28.tlf.novell.com) (130.57.49.28) by server-8.tower-21.messagelabs.com with DHE-RSA-AES256-SHA encrypted SMTP; 5 Sep 2011 08:13:52 -0000 Received: from EMEA1-MTA by nat28.tlf.novell.com with Novell_GroupWise; Mon, 05 Sep 2011 09:14:06 +0100 Message-Id: <4E64A0EB0200007800054995@nat28.tlf.novell.com> X-Mailer: Novell GroupWise Internet Agent 8.0.1 Date: Mon, 05 Sep 2011 09:14:03 +0100 From: "Jan Beulich" To: "Kevin Tian" Subject: RE: [Xen-devel] expose MWAIT to dom0 References: <4E4D23370200007800051D2C@nat28.tlf.novell.com> <625BA99ED14B2D499DC4E29D8138F15062EB8CC157@shsmsx502.ccr.corp.intel.com> <4E4E369F0200007800051F2A@nat28.tlf.novell.com> <625BA99ED14B2D499DC4E29D8138F15062EB8CC533@shsmsx502.ccr.corp.intel.com> <4E4E49C40200007800051F7B@nat28.tlf.novell.com> <625BA99ED14B2D499DC4E29D8138F15062EB8CC5AC@shsmsx502.ccr.corp.intel.com> <4E4E9707020000780005206C@nat28.tlf.novell.com> <625BA99ED14B2D499DC4E29D8138F15062F09DB9A7@shsmsx502.ccr.corp.intel.com> <4E565E0D0200007800053391@nat28.tlf.novell.com> <625BA99ED14B2D499DC4E29D8138F15063007E01DB@shsmsx502.ccr.corp.intel.com> In-Reply-To: <625BA99ED14B2D499DC4E29D8138F15063007E01DB@shsmsx502.ccr.corp.intel.com> Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: quoted-printable Content-Disposition: inline Cc: Yang Z Zhang , "xen-devel@lists.xensource.com" , Keir Fraser , Gang Wei , "'KonradRzeszutek Wilk \(konrad.wilk@oracle.com\)'" X-BeenThere: xen-devel@lists.xensource.com X-Mailman-Version: 2.1.5 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xensource.com Errors-To: xen-devel-bounces@lists.xensource.com >>> On 26.08.11 at 04:18, "Tian, Kevin" wrote: >> From: Jan Beulich [mailto:JBeulich@novell.com]=20 >> Sent: Thursday, August 25, 2011 8:37 PM >>=20 >> >>> On 21.08.11 at 07:26, "Tian, Kevin" wrote: >> >> From: Jan Beulich [mailto:JBeulich@novell.com]=20 >> >> Sent: Friday, August 19, 2011 11:02 PM >> >> > >> Yet another idea - why don't we simply pass the buffer passed = to >> >> > >> arch_acpi_set_pdc_bits() down to Xen, rather than fiddling with = the >> >> > >> bits in Dom0? That would at once allow to not set ACPI_PDC_T_FFH= >> >> > >> (which I don't think Xen really supports at present). >> >> > >> >> >> > >> Or really, depending on who controls what, the P, C, and T bits = should >> >> > >> be set by either Dom0 or Xen (so e.g. let Dom0 do what it = currently >> >> > >> does, and then let Xen override the bits it ought to control). >> >> > > >> >> > > _PDC is encoded in AML language, and requires an ACPI parser = which >> >> > > is one thing we avoid in Xen. If Xen want to override those = bits, then >> >> > > whole ACPI component needs move down to Xen too. >> >> > >> >> > No, I'm not saying the evaluation should be happening there. Below = is >> >> > a draft hypervisor patch (only compile tested so far). >> >> >> >> Attached a patch that actually works (with a minimal Dom0 addition). >> >> >> > >> > yes, this change looks more straightforward. :-) >>=20 >> With that in, we still have more deficiencies compared to native Linux. >=20 > definitely there'll be even more than what's revealed today, due to the > way that dom0 ACPI processor driver is tightly bound. there're lots of > factors in dom0 itself which may impact the verification/filtering on > Cx entries provide by BIOS, while some of which should be avoided from > Xen p.o.v, such as the 2nd example you just found. The more severe is > that to work around those factors adds intrusive Xen awareness into > generic ACPI processor driver, e.g.=20 >=20 > @@ -780,7 +780,7 @@ static int acpi_processor_get_power_info > current_count)); > =20 > /* Validate number of power states discovered */ > - if (current_count < 2) > + if (current_count < 1 + !processor_pm_external()) > status =3D -EFAULT; > =20 > end: >=20 > More changes like above are added, less possibilities for Xen PM > changes to be accepted into upstream. Also such specific changes > made on one dom0 version may be invalid in a new version quickly. > Above change is one example which doesn't hold true in newer > kernel.=20 Afaict, the code is unchanged up to at least 3.0, and requires the same adjustment (at least for the non-pvops case; the pvops one clearly can't be reasonably viewed from any post-2.6.32 perspective). > When working with Konrad on rebasing xen PM patches to latest > Linux 3.0.0. we tried hard to avoid intrusive changes in generic > ACPI processor driver, by trying to invoke existing interfaces in > higher level as possible. The end result is that we skip handling > those corner cases like above example for now, by at least making > Xen PM working on majority boxes. Later after Xen PM is accepted > upstream with more Xen awareness in Linux ACPI people, those > corner cases handling may be improved gradually. > =20 > Another option Yang currently is working on is to port native intel-idle > driver to Xen, which should avoid nasty dependency on dom0 ACPI > bits and immune to various BIOS bugs. That's good to hear. >> For one, we don't use mwait when ACPI doesn't tell us to, while Linux >> does (in the intel_idle driver for deeper C-states, and for C1 also via >> mwait_idle()). This is likely a bit more work, but it should be = possible to >> construct C-state information from CPUID leaf 5 (and, if valid, ignore >> information passed down from Dom0), which would match intel_idle's >> taking precedence over acpi_idle in Linux. >=20 > yes. This should be a desired feature in Xen, with some limitations: > - not work with CPU hotplug > - not work with old boxes (starting from Nehalem) > - not work with Px/Cx state changes (_PPC, _CST e.g. from Node = Manager) >=20 > So this will be a supplemented option to existing acpi_idle, and should > work on most cases when above 3 factors are not concerned. >=20 >>=20 >> Second, if only C1 gets announced by ACPI, we end up not using it >> because Dom0 simply neglects to let the hypervisor know. This is >> because acpi_processor_get_power_info_cst() (back to at least >> 2.6.16) returns -EFAULT if less than two C-states were found. Simply >> prefixing the check with "!processor_pm_external() && " fixes this >> (but I don't know whether something similar could be done in Jeremy's >> tree). >=20 > this is a very temporary problem which disappears quickly in subsequent > versions. But if just taking 2.6.18-xen, it's a right fix. Again - when did you see this disappear? Jan _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel From xen-devel-bounces@lists.xensource.com Mon Sep 05 02:04:52 2011 Return-path: Envelope-to: www-data@lists.xensource.com Delivery-date: Mon, 05 Sep 2011 02:04:52 -0700 Received: from localhost ([127.0.0.1] helo=lists.colo.xensource.com) by lists.xensource.com with esmtp (Exim 4.43) id 1R0V6q-000280-Fw; Mon, 05 Sep 2011 02:04:52 -0700 Received: from mail27.messagelabs.com ([193.109.254.147]) by lists.xensource.com with esmtp (Exim 4.43) id 1R0V4Z-0001ua-Iu for xen-devel@lists.xensource.com; Mon, 05 Sep 2011 02:02:34 -0700 X-Env-Sender: tim@xen.org X-Msg-Ref: server-15.tower-27.messagelabs.com!1315213340!47413043!1 X-Originating-IP: [81.29.64.94] X-StarScan-Version: 6.3.6; banners=-,-,- X-VirusChecked: Checked Received: (qmail 13433 invoked from network); 5 Sep 2011 09:02:21 -0000 Received: from ocelot.phlegethon.org (HELO mail.phlegethon.org) (81.29.64.94) by server-15.tower-27.messagelabs.com with DHE-RSA-AES256-SHA encrypted SMTP; 5 Sep 2011 09:02:21 -0000 Received: from tjd by mail.phlegethon.org with local (Exim 4.67 (FreeBSD)) (envelope-from ) id 1R0V4S-000Mdw-PV; Mon, 05 Sep 2011 09:02:24 +0000 Date: Mon, 5 Sep 2011 10:02:24 +0100 From: Tim Deegan To: Christoph Egger Subject: Re: [Xen-devel] [PATCH 01/04] p2m: use defines for page sizes rather hardcoding them Message-ID: <20110905090224.GB86376@ocelot.phlegethon.org> References: <4E57B184.8070601@amd.com> <20110901084041.GB3859@ocelot.phlegethon.org> <20110901084553.GC3859@ocelot.phlegethon.org> Mime-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline In-Reply-To: <20110901084553.GC3859@ocelot.phlegethon.org> User-Agent: Mutt/1.4.2.1i Cc: "xen-devel@lists.xensource.com" , Tim Deegan X-BeenThere: xen-devel@lists.xensource.com X-Mailman-Version: 2.1.5 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xensource.com Errors-To: xen-devel-bounces@lists.xensource.com At 09:45 +0100 on 01 Sep (1314870353), Tim Deegan wrote: > At 09:40 +0100 on 01 Sep (1314870041), Tim Deegan wrote: > > Content-Description: xen_superpage1.diff > > > use defines for page sizes rather hardcoding them. > > > > > > Signed-off-by: Christoph Egger > > > > Applied, thanks. > > The rest of this series looks OK in principle but I haven't time to look > at the detail today (and I'm wondering whether there's a way of doing it > without adding yet another argument to the p2m interfaces, but I suspect > not). I'll get to it as soon as I can. I've had a look and the mechanism is good, but the patches are not quite ready. Patch #2 touches too much of the p2m interfaces with the new page-order argument -- there are functions in it that now have a new argument that's _never_ called except with NULL. Patches #4 and #5 have a lot of churn in and around spage_* for what's basically a mask operation on an MFN. I don't think any of it is necessary. Also, please don't send patches that contain things like: +/* XXX: defines should be moved to a proper header */ It might make me think you didn't re-read them before posting. :) I think they really just need trimmed back a bit before they go in. I'll have some time on Wednesday, so I might just do that then. Cheers, Tim. _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel From xen-devel-bounces@lists.xensource.com Mon Sep 05 02:19:11 2011 Return-path: Envelope-to: www-data@lists.xensource.com Delivery-date: Mon, 05 Sep 2011 02:19:11 -0700 Received: from localhost ([127.0.0.1] helo=lists.colo.xensource.com) by lists.xensource.com with esmtp (Exim 4.43) id 1R0VKh-0003NV-6v; Mon, 05 Sep 2011 02:19:11 -0700 Received: from mail21.messagelabs.com ([85.158.143.35]) by lists.xensource.com with esmtp (Exim 4.43) id 1R0VJy-0003AY-1M for xen-devel@lists.xensource.com; Mon, 05 Sep 2011 02:18:26 -0700 X-Env-Sender: olaf@aepfle.de X-Msg-Ref: server-12.tower-21.messagelabs.com!1315214288!48713056!1 X-Originating-IP: [81.169.146.160] X-StarScan-Version: 6.3.6; banners=-,-,- X-VirusChecked: Checked Received: (qmail 2950 invoked from network); 5 Sep 2011 09:18:09 -0000 Received: from mo-p00-ob.rzone.de (HELO mo-p00-ob.rzone.de) (81.169.146.160) by server-12.tower-21.messagelabs.com with EDH-RSA-DES-CBC3-SHA encrypted SMTP; 5 Sep 2011 09:18:09 -0000 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; t=1315214302; l=4598; s=domk; d=aepfle.de; h=Cc:To:From:Date:Subject:Content-Transfer-Encoding:MIME-Version: Content-Type:X-RZG-CLASS-ID:X-RZG-AUTH; bh=FZDXZsk7kEjRtsfCCWllV6BWKes=; b=FLuPm0jQH/I8wLxEGsSsab6R9Bk+ja6gfSsLUS9V3d5SMbNqmochl4TvDOxk7MtTA9E tUrdtluzNVo9dGw3PcZjIa5e7T/YqU5fkRsC/yCdgkqYmcDkou81cn3G+0vlByIpDMhlk MNLQ1/NFy4NvmaMZk3lIhIrQVy/xoYe4LeM= X-RZG-AUTH: :P2EQZWCpfu+qG7CngxMFH1J+zrwiavkK6tmQaLfmwtM48/ll2s7pEE4= X-RZG-CLASS-ID: mo00 Received: from probook.site (dslb-084-057-083-022.pools.arcor-ip.net [84.57.83.22]) by smtp.strato.de (fruni mo37) (RZmta 26.6) with (EDH-RSA-DES-CBC3-SHA encrypted) ESMTPA id 407148n857fbyW ; Mon, 5 Sep 2011 11:18:11 +0200 (MEST) Received: from probook.site (localhost [IPv6:::1]) by probook.site (Postfix) with ESMTP id 7F92718B64; Mon, 5 Sep 2011 11:18:10 +0200 (CEST) Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Mercurial-Node: b2c8dacb2dc08bd93e4926eb0c2c7823d40e2174 Message-Id: User-Agent: Mercurial-patchbomb/1.7.5 Date: Mon, 05 Sep 2011 11:18:06 +0200 From: Olaf Hering To: xen-devel@lists.xensource.com Cc: Tim Deegan Subject: [Xen-devel] [PATCH] mem_event: add ref counting for free requestslots X-BeenThere: xen-devel@lists.xensource.com X-Mailman-Version: 2.1.5 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xensource.com Errors-To: xen-devel-bounces@lists.xensource.com # HG changeset patch # User Olaf Hering # Date 1315214140 -7200 # Node ID b2c8dacb2dc08bd93e4926eb0c2c7823d40e2174 # Parent f1349a968a5ac5577d67ad4a3f3490c580dbe264 mem_event: add ref counting for free requestslots If mem_event_check_ring() is called by many vcpus at the same time before any of them called also mem_event_put_request(), all of the callers must assume there are enough free slots available in the ring. Record the number of request producers in mem_event_check_ring() to keep track of available free slots. Add a new mem_event_put_req_producers() function to release a request attempt made in mem_event_check_ring(). Its required for p2m_mem_paging_populate() because that function can only modify the p2m type if there are free request slots. But in some cases p2m_mem_paging_populate() does not actually have to produce another request when it is known that the same request was already made earlier by a different vcpu. mem_event_check_ring() can not return a reference to a free request slot because there could be multiple references for different vcpus and the order of mem_event_put_request() calls is not known. As a result, incomplete requests could be consumed by the ring user. Signed-off-by: Olaf Hering diff -r f1349a968a5a -r b2c8dacb2dc0 xen/arch/x86/mm/mem_event.c --- a/xen/arch/x86/mm/mem_event.c +++ b/xen/arch/x86/mm/mem_event.c @@ -37,8 +37,6 @@ #define mem_event_ring_lock(_d) spin_lock(&(_d)->mem_event.ring_lock) #define mem_event_ring_unlock(_d) spin_unlock(&(_d)->mem_event.ring_lock) -#define MEM_EVENT_RING_THRESHOLD 4 - static int mem_event_enable(struct domain *d, mfn_t ring_mfn, mfn_t shared_mfn) { int rc; @@ -109,6 +107,7 @@ void mem_event_put_request(struct domain req_prod++; /* Update ring */ + d->mem_event.req_producers--; front_ring->req_prod_pvt = req_prod; RING_PUSH_REQUESTS(front_ring); @@ -153,11 +152,18 @@ void mem_event_mark_and_pause(struct vcp vcpu_sleep_nosync(v); } +void mem_event_put_req_producers(struct domain *d) +{ + mem_event_ring_lock(d); + d->mem_event.req_producers--; + mem_event_ring_unlock(d); +} + int mem_event_check_ring(struct domain *d) { struct vcpu *curr = current; int free_requests; - int ring_full; + int ring_full = 1; if ( !d->mem_event.ring_page ) return -1; @@ -165,12 +171,11 @@ int mem_event_check_ring(struct domain * mem_event_ring_lock(d); free_requests = RING_FREE_REQUESTS(&d->mem_event.front_ring); - if ( unlikely(free_requests < 2) ) + if ( d->mem_event.req_producers < free_requests ) { - gdprintk(XENLOG_INFO, "free request slots: %d\n", free_requests); - WARN_ON(free_requests == 0); + d->mem_event.req_producers++; + ring_full = 0; } - ring_full = free_requests < MEM_EVENT_RING_THRESHOLD ? 1 : 0; if ( (curr->domain->domain_id == d->domain_id) && ring_full ) { diff -r f1349a968a5a -r b2c8dacb2dc0 xen/arch/x86/mm/mem_sharing.c --- a/xen/arch/x86/mm/mem_sharing.c +++ b/xen/arch/x86/mm/mem_sharing.c @@ -281,7 +281,6 @@ static struct page_info* mem_sharing_all vcpu_pause_nosync(v); req.flags |= MEM_EVENT_FLAG_VCPU_PAUSED; - /* XXX: Need to reserve a request, not just check the ring! */ if(mem_event_check_ring(d)) return page; req.gfn = gfn; diff -r f1349a968a5a -r b2c8dacb2dc0 xen/arch/x86/mm/p2m.c --- a/xen/arch/x86/mm/p2m.c +++ b/xen/arch/x86/mm/p2m.c @@ -803,6 +803,7 @@ void p2m_mem_paging_populate(struct doma else if ( p2mt != p2m_ram_paging_out && p2mt != p2m_ram_paged ) { /* gfn is already on its way back and vcpu is not paused */ + mem_event_put_req_producers(d); return; } diff -r f1349a968a5a -r b2c8dacb2dc0 xen/include/asm-x86/mem_event.h --- a/xen/include/asm-x86/mem_event.h +++ b/xen/include/asm-x86/mem_event.h @@ -27,6 +27,7 @@ /* Pauses VCPU while marking pause flag for mem event */ void mem_event_mark_and_pause(struct vcpu *v); int mem_event_check_ring(struct domain *d); +void mem_event_put_req_producers(struct domain *d); void mem_event_put_request(struct domain *d, mem_event_request_t *req); void mem_event_get_response(struct domain *d, mem_event_response_t *rsp); void mem_event_unpause_vcpus(struct domain *d); diff -r f1349a968a5a -r b2c8dacb2dc0 xen/include/xen/sched.h --- a/xen/include/xen/sched.h +++ b/xen/include/xen/sched.h @@ -183,6 +183,7 @@ struct mem_event_domain { /* ring lock */ spinlock_t ring_lock; + unsigned int req_producers; /* shared page */ mem_event_shared_page_t *shared_page; /* shared ring page */ _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel From xen-devel-bounces@lists.xensource.com Mon Sep 05 02:20:26 2011 Return-path: Envelope-to: www-data@lists.xensource.com Delivery-date: Mon, 05 Sep 2011 02:20:26 -0700 Received: from localhost ([127.0.0.1] helo=lists.colo.xensource.com) by lists.xensource.com with esmtp (Exim 4.43) id 1R0VLu-0003kl-04; Mon, 05 Sep 2011 02:20:26 -0700 Received: from mail21.messagelabs.com ([85.158.143.35]) by lists.xensource.com with esmtp (Exim 4.43) id 1R0VLE-0003Ts-NT for xen-devel@lists.xensource.com; Mon, 05 Sep 2011 02:19:46 -0700 X-Env-Sender: rafal@invisiblethingslab.com X-Msg-Ref: server-12.tower-21.messagelabs.com!1315214367!48713361!1 X-Originating-IP: [194.181.28.234] X-StarScan-Version: 6.3.6; banners=-,-,- X-VirusChecked: Checked Received: (qmail 9278 invoked from network); 5 Sep 2011 09:19:28 -0000 Received: from warszawa.7bulls.com (HELO warszawa.7bulls.com) (194.181.28.234) by server-12.tower-21.messagelabs.com with DHE-RSA-AES256-SHA encrypted SMTP; 5 Sep 2011 09:19:28 -0000 Received: from localhost (localhost [127.0.0.1]) by warszawa.7bulls.com (Postfix) with ESMTP id AD05EE7ABF for ; Mon, 5 Sep 2011 11:19:31 +0200 (CEST) X-Virus-Scanned: Debian amavisd-new at warszawa.7bulls.com Received: from warszawa.7bulls.com ([127.0.0.1]) by localhost (localhost [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jLQav6UVRB4A for ; Mon, 5 Sep 2011 11:19:31 +0200 (CEST) Received: from email (249-mo5-9.acn.waw.pl [82.210.136.249]) by warszawa.7bulls.com (Postfix) with ESMTP id 8829AE7A81 for ; Mon, 5 Sep 2011 11:19:31 +0200 (CEST) Received: from email. (email [10.137.2.12]) by email (8.14.4/8.14.4) with ESMTP id p859JcGu001926 for ; Mon, 5 Sep 2011 11:19:38 +0200 Received: (from user@localhost) by email. (8.14.4/8.14.4/Submit) id p859Jc8Z001924 for xen-devel@lists.xensource.com; Mon, 5 Sep 2011 11:19:38 +0200 X-Authentication-Warning: email.: user set sender to rafal@invisiblethingslab.com using -f Date: Mon, 5 Sep 2011 11:19:37 +0200 From: Rafal Wojtczuk To: xen-devel@lists.xensource.com Message-ID: <20110905091937.GA1906@email> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-2 Content-Disposition: inline User-Agent: Mutt/1.5.21 (2010-09-15) Subject: [Xen-devel] dom0 is stalled until a keypress X-BeenThere: xen-devel@lists.xensource.com X-Mailman-Version: 2.1.5 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xensource.com Errors-To: xen-devel-bounces@lists.xensource.com Hello, The following bizarre behaviour was observed on xen4.1+suse dom0 2.6.38, on an old Core Duo laptop; maybe someone can hint what is wrong. Dom0 boot stalls after an init.d script prints "Starting udev". Then nothing seems to happen. I need to press any key to observe progress - I need to do it tens of times for the boot to finish. After X starts fine, then there is no need for keypressing anymore. A particularly disturbing fact is that qrexec_daemon parent, that basically does for (;;) { sleep(1); fprintf(stderr, "."); } does not print dots, until a keypress arrives. So something is very wrong with timers. Somehow similarly, pm-suspend sometimes hangs at some stage - after detaching power cord, machine enters S3 immediately. This is vaguely similar to the issue described in https://lkml.org/lkml/2008/9/14/122 but this time, "nohz=off" does not help. "cpufreq=dom0-kernel" cures the symptoms; but it is not a sideeffectless solution. Any idea what is going on or how to debug it ? Regards, RW _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel From xen-devel-bounces@lists.xensource.com Mon Sep 05 03:11:01 2011 Return-path: Envelope-to: www-data@lists.xensource.com Delivery-date: Mon, 05 Sep 2011 03:11:01 -0700 Received: from localhost ([127.0.0.1] helo=lists.colo.xensource.com) by lists.xensource.com with esmtp (Exim 4.43) id 1R0W8r-0007eY-Qk; Mon, 05 Sep 2011 03:11:01 -0700 Received: from mail21.messagelabs.com ([85.158.143.35]) by lists.xensource.com with esmtp (Exim 4.43) id 1R0W8J-0007Rn-Js for xen-devel@lists.xensource.com; Mon, 05 Sep 2011 03:10:28 -0700 X-Env-Sender: dunlapg@gmail.com X-Msg-Ref: server-14.tower-21.messagelabs.com!1315217416!58366122!1 X-Originating-IP: [74.125.82.171] X-StarScan-Version: 6.3.6; banners=-,-,- X-VirusChecked: Checked Received: (qmail 21655 invoked from network); 5 Sep 2011 10:10:17 -0000 Received: from mail-wy0-f171.google.com (HELO mail-wy0-f171.google.com) (74.125.82.171) by server-14.tower-21.messagelabs.com with RC4-SHA encrypted SMTP; 5 Sep 2011 10:10:17 -0000 Received: by wyh13 with SMTP id 13so4744252wyh.30 for ; Mon, 05 Sep 2011 03:10:24 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=xGKDa4x/u1XvIBs53J7GbDN7nqZDuFZImsWmeNB6l6A=; b=N7P0C7KcRYCeqH72aUfG39LOQSSq4y0sLyYwEMoDo20yOLDwnugN3nstHLw7FRXsgO P80I8Mk2DUxJfc1mxutbRWqNxLXVl/2U0TSfBNW17o+tRrt2pssKh1Dwe1doGZuWTNPb d5HZUjtwvjGGB9/WJC49nkgXJWwQXcO5Pjxbg= MIME-Version: 1.0 Received: by 10.216.185.133 with SMTP id u5mr2242441wem.55.1315217424050; Mon, 05 Sep 2011 03:10:24 -0700 (PDT) Received: by 10.216.202.40 with HTTP; Mon, 5 Sep 2011 03:10:24 -0700 (PDT) In-Reply-To: <5a1826139750ab0efe4f.1314981314@andrewcoop.uk.xensource.com> References: <5a1826139750ab0efe4f.1314981314@andrewcoop.uk.xensource.com> Date: Mon, 5 Sep 2011 11:10:24 +0100 X-Google-Sender-Auth: lPQeaRm5vmFdPdI6XnpJb7cMOHA Message-ID: Subject: Re: [Xen-devel] [PATCH 1 of 3] IRQ: Remove bit-rotten code From: George Dunlap To: Andrew Cooper Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: xen-devel@lists.xensource.com X-BeenThere: xen-devel@lists.xensource.com X-Mailman-Version: 2.1.5 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xensource.com Errors-To: xen-devel-bounces@lists.xensource.com Acked-by: George Dunlap On Fri, Sep 2, 2011 at 5:35 PM, Andrew Cooper w= rote: > irq_desc.depth is a write only variable. > LEGACY_IRQ_FROM_VECTOR(vec) is never referenced. > > Signed-off-by Andrew Cooper > > diff -r 227130622561 -r 5a1826139750 xen/arch/x86/io_apic.c > --- a/xen/arch/x86/io_apic.c =A0 =A0Thu Aug 25 12:03:14 2011 +0100 > +++ b/xen/arch/x86/io_apic.c =A0 =A0Fri Sep 02 17:33:17 2011 +0100 > @@ -1955,7 +1955,6 @@ static void __init check_timer(void) > =A0 =A0 if ((ret =3D bind_irq_vector(0, vector, mask_all))) > =A0 =A0 =A0 =A0 printk(KERN_ERR"..IRQ0 is not set correctly with ioapic!!= !, err:%d\n", ret); > > - =A0 =A0irq_desc[0].depth =A0=3D 0; > =A0 =A0 irq_desc[0].status &=3D ~IRQ_DISABLED; > > =A0 =A0 /* > diff -r 227130622561 -r 5a1826139750 xen/arch/x86/irq.c > --- a/xen/arch/x86/irq.c =A0 =A0 =A0 =A0Thu Aug 25 12:03:14 2011 +0100 > +++ b/xen/arch/x86/irq.c =A0 =A0 =A0 =A0Fri Sep 02 17:33:17 2011 +0100 > @@ -178,7 +178,6 @@ static void dynamic_irq_cleanup(unsigned > =A0 =A0 desc->handler->shutdown(irq); > =A0 =A0 action =3D desc->action; > =A0 =A0 desc->action =A0=3D NULL; > - =A0 =A0desc->depth =A0 =3D 1; > =A0 =A0 desc->msi_desc =3D NULL; > =A0 =A0 desc->handler =3D &no_irq_type; > =A0 =A0 desc->chip_data->used_vectors=3DNULL; > @@ -278,7 +277,6 @@ static void __init init_one_irq_desc(str > =A0 =A0 desc->status =A0=3D IRQ_DISABLED; > =A0 =A0 desc->handler =3D &no_irq_type; > =A0 =A0 desc->action =A0=3D NULL; > - =A0 =A0desc->depth =A0 =3D 1; > =A0 =A0 desc->msi_desc =3D NULL; > =A0 =A0 spin_lock_init(&desc->lock); > =A0 =A0 cpus_setall(desc->affinity); > @@ -736,7 +734,6 @@ void __init release_irq(unsigned int irq > =A0 =A0 spin_lock_irqsave(&desc->lock,flags); > =A0 =A0 action =3D desc->action; > =A0 =A0 desc->action =A0=3D NULL; > - =A0 =A0desc->depth =A0 =3D 1; > =A0 =A0 desc->status |=3D IRQ_DISABLED; > =A0 =A0 desc->handler->shutdown(irq); > =A0 =A0 spin_unlock_irqrestore(&desc->lock,flags); > @@ -764,7 +761,6 @@ int __init setup_irq(unsigned int irq, s > =A0 =A0 } > > =A0 =A0 desc->action =A0=3D new; > - =A0 =A0desc->depth =A0 =3D 0; > =A0 =A0 desc->status &=3D ~IRQ_DISABLED; > =A0 =A0 desc->handler->startup(irq); > > @@ -1343,7 +1339,6 @@ int pirq_guest_bind(struct vcpu *v, stru > =A0 =A0 =A0 =A0 cpus_clear(action->cpu_eoi_map); > =A0 =A0 =A0 =A0 init_timer(&action->eoi_timer, irq_guest_eoi_timer_fn, de= sc, 0); > > - =A0 =A0 =A0 =A0desc->depth =3D 0; > =A0 =A0 =A0 =A0 desc->status |=3D IRQ_GUEST; > =A0 =A0 =A0 =A0 desc->status &=3D ~IRQ_DISABLED; > =A0 =A0 =A0 =A0 desc->handler->startup(irq); > @@ -1459,7 +1454,6 @@ static irq_guest_action_t *__pirq_guest_ > =A0 =A0 BUG_ON(action->in_flight !=3D 0); > > =A0 =A0 /* Disabling IRQ before releasing the desc_lock avoids an IRQ sto= rm. */ > - =A0 =A0desc->depth =A0 =3D 1; > =A0 =A0 desc->status |=3D IRQ_DISABLED; > =A0 =A0 desc->handler->disable(irq); > > diff -r 227130622561 -r 5a1826139750 xen/include/asm-x86/irq.h > --- a/xen/include/asm-x86/irq.h Thu Aug 25 12:03:14 2011 +0100 > +++ b/xen/include/asm-x86/irq.h Fri Sep 02 17:33:17 2011 +0100 > @@ -19,7 +19,6 @@ > =A0#define MSI_IRQ(irq) =A0 =A0 =A0 ((irq) >=3D nr_irqs_gsi && (irq) < nr= _irqs) > > =A0#define LEGACY_VECTOR(irq) =A0 =A0 =A0 =A0 =A0((irq) + FIRST_LEGACY_VE= CTOR) > -#define LEGACY_IRQ_FROM_VECTOR(vec) ((vec) - FIRST_LEGACY_VECTOR) > > =A0#define irq_to_desc(irq) =A0 =A0(&irq_desc[irq]) > =A0#define irq_cfg(irq) =A0 =A0 =A0 =A0(&irq_cfg[irq]) > diff -r 227130622561 -r 5a1826139750 xen/include/xen/irq.h > --- a/xen/include/xen/irq.h =A0 =A0 Thu Aug 25 12:03:14 2011 +0100 > +++ b/xen/include/xen/irq.h =A0 =A0 Fri Sep 02 17:33:17 2011 +0100 > @@ -72,7 +72,6 @@ typedef struct irq_desc { > =A0 =A0 hw_irq_controller *handler; > =A0 =A0 struct msi_desc =A0 *msi_desc; > =A0 =A0 struct irqaction *action; =A0/* IRQ action list */ > - =A0 =A0unsigned int depth; =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0/* nested irq= disables */ > =A0 =A0 struct irq_cfg *chip_data; > =A0 =A0 int irq; > =A0 =A0 spinlock_t lock; > > _______________________________________________ > Xen-devel mailing list > Xen-devel@lists.xensource.com > http://lists.xensource.com/xen-devel > _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel From xen-devel-bounces@lists.xensource.com Mon Sep 05 03:14:35 2011 Return-path: Envelope-to: www-data@lists.xensource.com Delivery-date: Mon, 05 Sep 2011 03:14:35 -0700 Received: from localhost ([127.0.0.1] helo=lists.colo.xensource.com) by lists.xensource.com with esmtp (Exim 4.43) id 1R0WCJ-000843-9S; Mon, 05 Sep 2011 03:14:35 -0700 Received: from mail27.messagelabs.com ([193.109.254.147]) by lists.xensource.com with smtp (Exim 4.43) id 1R0WBr-0007rn-7K for xen-devel@lists.xensource.com; Mon, 05 Sep 2011 03:14:07 -0700 X-Env-Sender: ml-xen-devel@hfp.de X-Msg-Ref: server-10.tower-27.messagelabs.com!1315217626!34403352!1 X-Originating-IP: [88.205.101.6] X-StarScan-Version: 6.3.6; banners=-,-,- X-VirusChecked: Checked Received: (qmail 26227 invoked from network); 5 Sep 2011 10:13:46 -0000 Received: from rootsrv.hfp.de (HELO rootsrv.hfp.de) (88.205.101.6) by server-10.tower-27.messagelabs.com with SMTP; 5 Sep 2011 10:13:46 -0000 Received: from localhost (localhost [127.0.0.1]) by rootsrv.hfp.de (Postfix) with ESMTP id B93DB1A8A7B; Mon, 5 Sep 2011 12:14:02 +0200 (CEST) X-Virus-Scanned: amavisd-new/ClamAV at rootsrv.hfp.de Received: from rootsrv.hfp.de ([127.0.0.1]) by localhost (rootsrv.hfp.de [127.0.0.1]) (amavisd-new, port 10026) with ESMTP id 7w8v6nWfbvHj; Mon, 5 Sep 2011 12:14:02 +0200 (CEST) Received: from [10.0.0.1] (p5DCB73AE.dip.t-dialin.net [93.203.115.174]) by rootsrv.hfp.de (Postfix) with ESMTPA; Mon, 5 Sep 2011 12:14:02 +0200 (CEST) Message-ID: <4E64A0DF.2070007@hfp.de> Date: Mon, 05 Sep 2011 12:13:51 +0200 From: Andreas Kinzler User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:6.0) Gecko/20110812 Thunderbird/6.0 MIME-Version: 1.0 To: James Harper , xen-devel@lists.xensource.com Content-Type: multipart/mixed; boundary="------------050007050803000508040203" Cc: Subject: [Xen-devel] Stability report GPLPV 0.11.0.308 X-BeenThere: xen-devel@lists.xensource.com X-Mailman-Version: 2.1.5 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xensource.com Errors-To: xen-devel-bounces@lists.xensource.com This is a multi-part message in MIME format. --------------050007050803000508040203 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Hello James, I am doing quite rigorous torture tests with Xen and GPLPV. Let me first repeat the test setup: Use Xen 4.1.1 and kernel 2.6.32.36 (commit ae333e9). Configure 2 HVMs called VM1 and VM2 as follows (per HVM): 2 VCPUs, 2 virtual disks, 1024 MB RAM, viridian=1 Install Windows 2008 R2 SP1, do install everything twice - never clone. Install GPLPV, iometer 2006.07.27, prime95 26.6 x64, ActiveState Perl 5.12.4 x64, wget for Windows and the attached perl script. Run iometer with 2 workers on the same but separate second virtual disk, queue depth 4 per worker, access specification "All in one". Run prime95 torture test with "In-place large FFTs". On VM1 use the task manager to set affinity to VCPU2, on VM2 set affinity to VCPU1. Run the perl script to fetch a good mix of some large (50-500 MB) and many small (some KB) files from a high performance FTP server on the LAN (I use vsftpd). This generates quite some load as vmstat shows: virt5620 ~ # vmstat 1 procs -----------memory---------- ---swap-- -----io---- -system-- ----cpu---- r b swpd free buff cache si so bi bo in cs us sy id wa 0 0 0 723408 6860 33860 0 0 82113 82132 22503 30252 2 12 84 0 0 0 0 723408 6860 33860 0 0 80117 82913 23109 30776 1 13 83 0 4 0 0 723408 6860 33860 0 0 92555 87013 28411 33283 2 12 84 0 4 0 0 723408 6860 33860 0 0 82678 85775 26228 31739 1 13 83 0 5 0 0 723408 6860 33860 0 0 82252 84837 24180 29723 1 14 82 0 With GPLPV 0.11.0.308 it worked perfectly and with very good performance for over 9 days but then when I wanted to monitor the status, I was no longer able to connect via remote desktop. When examining the file system of the HVMs I found that somehow even the prime95 processes did stop. Any ideas? Could c/s 948 make any difference? Network worked perfectly for 9 days, so I ask myself if the count of c/s 948 is used at all? Regards Andreas --------------050007050803000508040203 Content-Type: text/plain; name="test-via-wget.pl" Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename="test-via-wget.pl" use IPC::Run3; $url = "ftp://10.0.0.3"; $ftpUser = "ftpuser"; $ftpPass = "ftp"; $sleepSec = 60; sub runWget() { my ($stdout, $stderr); my @args = ("wget", "-O", "nul", "-r", "-v", "--user=$ftpUser", "--password=$ftpPass", $url); IPC::Run3::run3(\@args, undef, \$stdout, \$stderr); $r = $?; open FILE, ">last-stdout" or die; print FILE $stdout; close FILE; open FILE, ">last-stderr" or die; print FILE $stderr; close FILE; return $r; } $iter = 1; while(1) { my ($r); $r = runWget; if ($r) { print("\nError!\n"); exit 1; } print "Iteration #$iter completed\n"; $iter++; sleep($sleepSec); } --------------050007050803000508040203 Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel --------------050007050803000508040203-- From xen-devel-bounces@lists.xensource.com Mon Sep 05 03:15:37 2011 Return-path: Envelope-to: www-data@lists.xensource.com Delivery-date: Mon, 05 Sep 2011 03:15:37 -0700 Received: from localhost ([127.0.0.1] helo=lists.colo.xensource.com) by lists.xensource.com with esmtp (Exim 4.43) id 1R0WDJ-0008WF-2X; Mon, 05 Sep 2011 03:15:37 -0700 Received: from mail182.messagelabs.com ([85.158.139.83]) by lists.xensource.com with esmtp (Exim 4.43) id 1R0WCg-0008DZ-5N for xen-devel@lists.xensource.com; Mon, 05 Sep 2011 03:14:58 -0700 X-Env-Sender: dunlapg@gmail.com X-Msg-Ref: server-8.tower-182.messagelabs.com!1315217695!17084525!1 X-Originating-IP: [74.125.82.43] X-StarScan-Version: 6.3.6; banners=-,-,- X-VirusChecked: Checked Received: (qmail 13382 invoked from network); 5 Sep 2011 10:14:55 -0000 Received: from mail-ww0-f43.google.com (HELO mail-ww0-f43.google.com) (74.125.82.43) by server-8.tower-182.messagelabs.com with RC4-SHA encrypted SMTP; 5 Sep 2011 10:14:55 -0000 Received: by wwe32 with SMTP id 32so3980307wwe.24 for ; Mon, 05 Sep 2011 03:14:55 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=sKkuoPnLSavpIgLhs+LqfAIBZjVXTA61rL2fpIRpCyo=; b=dstrDz8+m0G9IaqdzW+/IXthon1+tNcpb7+gQRjiwXj/7XRpc0jFWD4c8qSPEJn8sM i/GC6s1MsSoSstHCAKDFarU2pDYWBUp7SdSjg8YTcbkexbPHnl+7NoS+IpgY3bcsUEWQ TsIb8za5mXgwQkundqHzM7OH5IOgE9MRFJcR4= MIME-Version: 1.0 Received: by 10.216.179.69 with SMTP id g47mr1133532wem.10.1315217694840; Mon, 05 Sep 2011 03:14:54 -0700 (PDT) Received: by 10.216.202.40 with HTTP; Mon, 5 Sep 2011 03:14:54 -0700 (PDT) In-Reply-To: <1a244d4ca6ac2e442c3b.1314981316@andrewcoop.uk.xensource.com> References: <1a244d4ca6ac2e442c3b.1314981316@andrewcoop.uk.xensource.com> Date: Mon, 5 Sep 2011 11:14:54 +0100 X-Google-Sender-Auth: owsMbeIgoMymMYfJ02OOBu40hmY Message-ID: Subject: Re: [Xen-devel] [PATCH 3 of 3] IRQ: Introduce old_vector to irq_cfg From: George Dunlap To: Andrew Cooper Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: xen-devel@lists.xensource.com X-BeenThere: xen-devel@lists.xensource.com X-Mailman-Version: 2.1.5 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xensource.com Errors-To: xen-devel-bounces@lists.xensource.com Comments inline. On Fri, Sep 2, 2011 at 5:35 PM, Andrew Cooper w= rote: > Introduce old_vector to irq_cfg with the same principle as > old_cpu_mask. =A0This removes a brute force loop from > __clear_irq_vector(), and paves the way to correct bitrotten logic > elsewhere in the irq code. > > Signed-off-by Andrew Cooper > > diff -r cf93a1825d66 -r 1a244d4ca6ac xen/arch/x86/io_apic.c > --- a/xen/arch/x86/io_apic.c =A0 =A0Fri Sep 02 17:33:17 2011 +0100 > +++ b/xen/arch/x86/io_apic.c =A0 =A0Fri Sep 02 17:33:17 2011 +0100 > @@ -487,11 +487,16 @@ fastcall void smp_irq_move_cleanup_inter > =A0 =A0 =A0 =A0 __get_cpu_var(vector_irq)[vector] =3D -1; > =A0 =A0 =A0 =A0 cfg->move_cleanup_count--; > > - =A0 =A0 =A0 =A0if ( cfg->move_cleanup_count =3D=3D 0 > - =A0 =A0 =A0 =A0 =A0 =A0 && =A0cfg->used_vectors ) > + =A0 =A0 =A0 =A0if ( cfg->move_cleanup_count =3D=3D 0 ) > =A0 =A0 =A0 =A0 { > - =A0 =A0 =A0 =A0 =A0 =A0ASSERT(test_bit(vector, cfg->used_vectors)); > - =A0 =A0 =A0 =A0 =A0 =A0clear_bit(vector, cfg->used_vectors); > + =A0 =A0 =A0 =A0 =A0 =A0cfg->old_vector =3D -1; Just for consistency, should this be IRQ_VECTOR_UNASSIGNED instead of -1? > + =A0 =A0 =A0 =A0 =A0 =A0cpus_clear(cfg->old_cpu_mask); > + > + =A0 =A0 =A0 =A0 =A0 =A0if ( cfg->used_vectors ) > + =A0 =A0 =A0 =A0 =A0 =A0{ > + =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0ASSERT(test_bit(vector, cfg->used_vector= s)); > + =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0clear_bit(vector, cfg->used_vectors); > + =A0 =A0 =A0 =A0 =A0 =A0} > =A0 =A0 =A0 =A0 } > =A0unlock: > =A0 =A0 =A0 =A0 spin_unlock(&desc->lock); > diff -r cf93a1825d66 -r 1a244d4ca6ac xen/arch/x86/irq.c > --- a/xen/arch/x86/irq.c =A0 =A0 =A0 =A0Fri Sep 02 17:33:17 2011 +0100 > +++ b/xen/arch/x86/irq.c =A0 =A0 =A0 =A0Fri Sep 02 17:33:17 2011 +0100 > @@ -211,15 +211,9 @@ static void __clear_irq_vector(int irq) > > =A0 =A0 cpus_and(tmp_mask, cfg->old_cpu_mask, cpu_online_map); > =A0 =A0 for_each_cpu_mask(cpu, tmp_mask) { > - =A0 =A0 =A0 =A0for (vector =3D FIRST_DYNAMIC_VECTOR; vector <=3D LAST_D= YNAMIC_VECTOR; > - =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0vector++= ) { > - =A0 =A0 =A0 =A0 =A0 =A0if (per_cpu(vector_irq, cpu)[vector] !=3D irq) > - =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0continue; > - =A0 =A0 =A0 =A0 =A0 =A0TRACE_3D(TRC_HW_IRQ_MOVE_FINISH, > - =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 irq, vector, cpu); > - =A0 =A0 =A0 =A0 =A0 =A0per_cpu(vector_irq, cpu)[vector] =3D -1; > - =A0 =A0 =A0 =A0 =A0 =A0 break; > - =A0 =A0 =A0 =A0} > + =A0 =A0 =A0 =A0ASSERT( per_cpu(vector_irq, cpu)[cfg->old_vector] =3D=3D= irq ); > + =A0 =A0 =A0 =A0TRACE_3D(TRC_HW_IRQ_MOVE_FINISH, irq, vector, cpu); > + =A0 =A0 =A0 =A0per_cpu(vector_irq, cpu)[vector] =3D -1; Do you mean cfg->old_vector here, instead of vector? > =A0 =A0 =A0} > > =A0 =A0 if ( cfg->used_vectors ) > @@ -279,6 +273,7 @@ static void __init init_one_irq_desc(str > =A0static void __init init_one_irq_cfg(struct irq_cfg *cfg) > =A0{ > =A0 =A0 cfg->vector =3D IRQ_VECTOR_UNASSIGNED; > + =A0 =A0cfg->old_vector =3D IRQ_VECTOR_UNASSIGNED; > =A0 =A0 cpus_clear(cfg->cpu_mask); > =A0 =A0 cpus_clear(cfg->old_cpu_mask); > =A0 =A0 cfg->used_vectors =3D NULL; > @@ -418,6 +413,7 @@ next: > =A0 =A0 =A0 =A0 if (old_vector) { > =A0 =A0 =A0 =A0 =A0 =A0 cfg->move_in_progress =3D 1; > =A0 =A0 =A0 =A0 =A0 =A0 cpus_copy(cfg->old_cpu_mask, cfg->cpu_mask); > + =A0 =A0 =A0 =A0 =A0 =A0cfg->old_vector =3D cfg->vector; > =A0 =A0 =A0 =A0 } > =A0 =A0 =A0 =A0 trace_irq_mask(TRC_HW_IRQ_ASSIGN_VECTOR, irq, vector, &tm= p_mask); > =A0 =A0 =A0 =A0 for_each_cpu_mask(new_cpu, tmp_mask) > diff -r cf93a1825d66 -r 1a244d4ca6ac xen/include/asm-x86/irq.h > --- a/xen/include/asm-x86/irq.h Fri Sep 02 17:33:17 2011 +0100 > +++ b/xen/include/asm-x86/irq.h Fri Sep 02 17:33:17 2011 +0100 > @@ -28,7 +28,8 @@ typedef struct { > =A0} vmask_t; > > =A0struct irq_cfg { > - =A0 =A0 =A0 =A0int =A0vector; > + =A0 =A0 =A0 =A0s16 vector; =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0/* vector= itself is only 8 bits, */ > + =A0 =A0 =A0 =A0s16 old_vector; =A0 =A0 =A0 =A0 =A0 =A0 =A0/* but we use= -1 for unassigned =A0*/ > =A0 =A0 =A0 =A0 cpumask_t cpu_mask; > =A0 =A0 =A0 =A0 cpumask_t old_cpu_mask; > =A0 =A0 =A0 =A0 unsigned move_cleanup_count; > > _______________________________________________ > Xen-devel mailing list > Xen-devel@lists.xensource.com > http://lists.xensource.com/xen-devel > _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel From xen-devel-bounces@lists.xensource.com Mon Sep 05 03:32:27 2011 Return-path: Envelope-to: www-data@lists.xensource.com Delivery-date: Mon, 05 Sep 2011 03:32:27 -0700 Received: from localhost ([127.0.0.1] helo=lists.colo.xensource.com) by lists.xensource.com with esmtp (Exim 4.43) id 1R0WTb-0000hQ-JG; Mon, 05 Sep 2011 03:32:27 -0700 Received: from mail21.messagelabs.com ([85.158.143.35]) by lists.xensource.com with smtp (Exim 4.43) id 1R0WSr-0000UN-Rq for xen-devel@lists.xensource.com; Mon, 05 Sep 2011 03:31:42 -0700 X-Env-Sender: anthony@overnetdata.com X-Msg-Ref: server-4.tower-21.messagelabs.com!1315218664!58998441!1 X-Originating-IP: [81.137.131.225] X-StarScan-Version: 6.3.6; banners=-,-,- X-VirusChecked: Checked Received: (qmail 1341 invoked from network); 5 Sep 2011 10:31:04 -0000 Received: from host81-137-131-225.in-addr.btopenworld.com (HELO zimbra.overnetdata.com) (81.137.131.225) by server-4.tower-21.messagelabs.com with SMTP; 5 Sep 2011 10:31:04 -0000 Received: from localhost (localhost.localdomain [127.0.0.1]) by zimbra.overnetdata.com (Postfix) with ESMTP id CDA98161588 for ; Mon, 5 Sep 2011 11:31:37 +0100 (BST) X-Virus-Scanned: amavisd-new at overnetdata.com Received: from zimbra.overnetdata.com ([127.0.0.1]) by localhost (zimbra.overnetdata.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GvVK7ANH-9Hg for ; Mon, 5 Sep 2011 11:31:19 +0100 (BST) Received: from [192.168.1.54] (unknown [192.168.1.54]) by zimbra.overnetdata.com (Postfix) with ESMTPSA id 2866516158C for ; Mon, 5 Sep 2011 11:31:19 +0100 (BST) Message-ID: <4E64A4F4.1040402@overnetdata.com> Date: Mon, 05 Sep 2011 11:31:16 +0100 From: Anthony Wright User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:6.0.1) Gecko/20110830 Thunderbird/6.0.1 MIME-Version: 1.0 To: "xen-devel@lists.xensource.com" X-Enigmail-Version: 1.3.1 Content-Type: multipart/mixed; boundary="------------030602000607000908030302" Subject: [Xen-devel] VM hangs during boot on 3.0.4 dom0 kernel, works on alternative hardware X-BeenThere: xen-devel@lists.xensource.com X-Mailman-Version: 2.1.5 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xensource.com Errors-To: xen-devel-bounces@lists.xensource.com This is a multi-part message in MIME format. --------------030602000607000908030302 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit I have two machines with identical Dom0's and DomUs, but different hardware. The Dom0 has a patch which I produced myself based on the "Re: [Xen-devel] Kernel bug from 3.0 (was phy disks and vifs timing out in DomU)" thread. The patch calls vmalloc_sync_all after every alloc_vm_area, and I realise this isn't the best solution, but it allowed me to move forward. The patch fixes the problem I had on one machine, so that now the VMs boot correctly, but I have another system with an identical setup (identical Dom0 & DomU kernels, identical startup for DomU) and the VM fails to start. I have attached a copy of the console log from the good VM and the bad VM. Anthony. --------------030602000607000908030302 Content-Type: text/plain; name="bad.log" Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename="bad.log" [ 3.226308] Reserving virtual address space above 0xf5800000 [ 3.226308] Linux version 2.6.30.1 (root@deb-builder) (gcc version 4.3.2 (GCC) ) #2 SMP Mon Jul 18 12:06:12 GMT 2011 [ 3.226308] KERNEL supported cpus: [ 3.226308] Intel GenuineIntel [ 3.226308] AMD AuthenticAMD [ 3.226308] NSC Geode by NSC [ 3.226308] Cyrix CyrixInstead [ 3.226308] Centaur CentaurHauls [ 3.226308] Transmeta GenuineTMx86 [ 3.226308] Transmeta TransmetaCPU [ 3.226308] UMC UMC UMC UMC [ 3.226308] BIOS-provided physical RAM map: [ 3.226308] Xen: 0000000000000000 - 00000000000a0000 (usable) [ 3.226308] Xen: 00000000000a0000 - 0000000000100000 (reserved) [ 3.226308] Xen: 0000000000100000 - 000000000065c000 (usable) [ 3.226308] Xen: 000000000065c000 - 0000000000759000 (reserved) [ 3.226308] Xen: 0000000000759000 - 000000003e800000 (usable) [ 3.226308] DMI not present or invalid. [ 3.226308] last_pfn = 0x3e800 max_arch_pfn = 0x1000000 [ 3.226308] init_memory_mapping: 0000000000000000-00000000229fe000 [ 3.226308] NX (Execute Disable) protection: active [ 3.226308] 446MB HIGHMEM available. [ 3.226308] 553MB LOWMEM available. [ 3.226308] mapped low ram: 0 - 229fe000 [ 3.226308] low ram: 0 - 229fe000 [ 3.226308] node 0 low ram: 00000000 - 229fe000 [ 3.226308] node 0 bootmap 00007000 - 0000b540 [ 3.226308] (7 early reservations) ==> bootmem [0000000000 - 00229fe000] [ 3.226308] #0 [0000000000 - 0000001000] BIOS data page ==> [0000000000 - 0000001000] [ 3.226308] #1 [0000759000 - 000075f000] XEN PAGETABLES ==> [0000759000 - 000075f000] [ 3.226308] #2 [0000001000 - 0000002000] EX TRAMPOLINE ==> [0000001000 - 0000002000] [ 3.226308] #3 [0000006000 - 0000007000] TRAMPOLINE ==> [0000006000 - 0000007000] [ 3.226308] #4 [0000100000 - 00005366f4] TEXT DATA BSS ==> [0000100000 - 00005366f4] [ 3.226308] #5 [0000537000 - 0000645000] PGTABLE ==> [0000537000 - 0000645000] [ 3.226308] #6 [0000007000 - 000000c000] BOOTMAP ==> [0000007000 - 000000c000] [ 3.226308] Zone PFN ranges: [ 3.226308] DMA 0x00000000 -> 0x00001000 [ 3.226308] Normal 0x00001000 -> 0x000229fe [ 3.226308] HighMem 0x000229fe -> 0x0003e800 [ 3.226308] Movable zone start PFN for each node [ 3.226308] early_node_map[3] active PFN ranges [ 3.226308] 0: 0x00000000 -> 0x000000a0 [ 3.226308] 0: 0x00000100 -> 0x0000065c [ 3.226308] 0: 0x00000759 -> 0x0003e800 [ 3.226308] Using APIC driver default [ 3.226308] SMP: Allowing 1 CPUs, 0 hotplug CPUs [ 3.226308] Local APIC disabled by BIOS -- you can enable it with "lapic" [ 3.226308] Allocating PCI resources starting at 40000000 (gap: 3e800000:c1800000) [ 3.226308] NR_CPUS:8 nr_cpumask_bits:8 nr_cpu_ids:1 nr_node_ids:1 [ 3.226308] PERCPU: Allocated 6 4k pages, static data 22940 bytes [ 3.810521] Xen: using vcpu_info placement [ 0.000000] Built 1 zonelists in Zone order, mobility grouping on. Total pages: 253650 [ 0.000000] Kernel command line: root=/dev/xvda1 [ 0.000000] Enabling fast FPU save and restore... done. [ 0.000000] Enabling unmasked SIMD FPU exception support... done. [ 0.000000] Initializing CPU#0 [ 0.000000] NR_IRQS:512 [ 0.000000] PID hash table entries: 4096 (order: 12, 16384 bytes) [ 0.000000] Detected 2533.458 MHz processor. [ 0.010000] Console: colour dummy device 80x25 [ 0.010000] console [tty0] enabled [ 0.010000] console [hvc0] enabled [ 0.010000] Dentry cache hash table entries: 131072 (order: 7, 524288 bytes) [ 0.010000] Inode-cache hash table entries: 65536 (order: 6, 262144 bytes) [ 0.010000] Initializing HighMem for node 0 (000229fe:0003e800) [ 0.010000] Memory: 1007448k/1024000k available (2539k kernel code, 14292k reserved, 1067k data, 244k init, 456712k highmem) [ 0.010000] virtual kernel memory layout: [ 0.010000] fixmap : 0xf574f000 - 0xf57ff000 ( 704 kB) [ 0.010000] pkmap : 0xf5200000 - 0xf5400000 (2048 kB) [ 0.010000] vmalloc : 0xe31fe000 - 0xf51fe000 ( 288 MB) [ 0.010000] lowmem : 0xc0000000 - 0xe29fe000 ( 553 MB) [ 0.010000] .init : 0xc0490000 - 0xc04cd000 ( 244 kB) [ 0.010000] .data : 0xc037ae1d - 0xc0485e18 (1067 kB) [ 0.010000] .text : 0xc0100000 - 0xc037ae1d (2539 kB) [ 0.010000] Checking if this processor honours the WP bit even in supervisor mode...Ok. [ 0.010000] installing Xen timer for CPU 0 [ 0.010000] Calibrating delay loop (skipped), value calculated using timer frequency.. 5066.91 BogoMIPS (lpj=25334580) [ 0.010000] Mount-cache hash table entries: 512 --------------030602000607000908030302 Content-Type: text/plain; name="good.log" Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename="good.log" [ 3.226308] Reserving virtual address space above 0xf5800000 [ 3.226308] Linux version 2.6.30.1 (root@deb-builder) (gcc version 4.3.2 (GCC) ) #2 SMP Mon Jul 18 12:06:12 GMT 2011 [ 3.226308] KERNEL supported cpus: [ 3.226308] Intel GenuineIntel [ 3.226308] AMD AuthenticAMD [ 3.226308] NSC Geode by NSC [ 3.226308] Cyrix CyrixInstead [ 3.226308] Centaur CentaurHauls [ 3.226308] Transmeta GenuineTMx86 [ 3.226308] Transmeta TransmetaCPU [ 3.226308] UMC UMC UMC UMC [ 3.226308] BIOS-provided physical RAM map: [ 3.226308] Xen: 0000000000000000 - 00000000000a0000 (usable) [ 3.226308] Xen: 00000000000a0000 - 0000000000100000 (reserved) [ 3.226308] Xen: 0000000000100000 - 000000000065c000 (usable) [ 3.226308] Xen: 000000000065c000 - 0000000000759000 (reserved) [ 3.226308] Xen: 0000000000759000 - 000000003e800000 (usable) [ 3.226308] DMI not present or invalid. [ 3.226308] last_pfn = 0x3e800 max_arch_pfn = 0x1000000 [ 3.226308] init_memory_mapping: 0000000000000000-00000000229fe000 [ 3.226308] NX (Execute Disable) protection: active [ 3.226308] 446MB HIGHMEM available. [ 3.226308] 553MB LOWMEM available. [ 3.226308] mapped low ram: 0 - 229fe000 [ 3.226308] low ram: 0 - 229fe000 [ 3.226308] node 0 low ram: 00000000 - 229fe000 [ 3.226308] node 0 bootmap 00007000 - 0000b540 [ 3.226308] (7 early reservations) ==> bootmem [0000000000 - 00229fe000] [ 3.226308] #0 [0000000000 - 0000001000] BIOS data page ==> [0000000000 - 0000001000] [ 3.226308] #1 [0000759000 - 000075f000] XEN PAGETABLES ==> [0000759000 - 000075f000] [ 3.226308] #2 [0000001000 - 0000002000] EX TRAMPOLINE ==> [0000001000 - 0000002000] [ 3.226308] #3 [0000006000 - 0000007000] TRAMPOLINE ==> [0000006000 - 0000007000] [ 3.226308] #4 [0000100000 - 00005366f4] TEXT DATA BSS ==> [0000100000 - 00005366f4] [ 3.226308] #5 [0000537000 - 0000645000] PGTABLE ==> [0000537000 - 000 default [ 3.226308] SMP: Allowing 1 CPUs, 0 hotplug CPUs [ 3.226308] Local APIC disabled by BIOS -- you can enable it with "lapic" [ 3.226308] Allocating PCI resources starting at 40000000 (gap: 3e800000:c1800000) [ 3.226308] NR_CPUS:8 nr_cpumask_bits:8 nr_cpu_ids:1 nr_node_ids:1 [ 3.226308] PERCPU: Allocated 6 4k pages, static data 22940 bytes [ 3.810521] Xen: using vcpu_info placement [ 0.000000] Built 1 zonelists in Zone order, mobility grouping on. Total pages: 253650 [ 0.000000] Kernel command line: root=/dev/xvda1 [ 0.000000] Enabling fast FPU save and restore... done. [ 0.000000] Enabling unmasked SIMD FPU exception support... done. [ 0.000000] Initializing CPU#0 [ 0.000000] NR_IRQS:512 [ 0.000000] PID hash table entries: 4096 (order: 12, 16384 bytes) [ 0.000000] Detected 3013.788 MHz processor. [ 0.010000] Console: colour dummy device 80x25 [ 0.010000] console [tty0] enabled [ 0.010000] console [hvc0] enabled [ 0.010000] Dentry cache hash table entries: 131072 (order: 7, 524288 bytes) [ 0.010000] Inode-cache hash table entries: 65536 (order: 6, 262144 bytes) [ 0.010000] Initializing HighMem for node 0 (000229fe:0003e800) [ 0.010000] Memory: 1007448k/1024000k available (2539k kernel code, 14292k reserved, 1067k data, 244k init, 456712k highmem) [ 0.010000] virtual kernel memory layout: [ 0.010000] fixmap : 0xf574f000 - 0xf57ff000 ( 704 kB) [ 0.010000] pkmap : 0xf5200000 - 0xf5400000 (2048 kB) [ 0.010000] vmalloc : 0xe31fe000 - 0xf51fe000 ( 288 MB) [ 0.010000] lowmem : 0xc0000000 - 0xe29fe000 ( 553 MB) [ 0.010000] .init : 0xc0490000 - 0xc04cd000 ( 244 kB) [ 0.010000] .data : 0xc037ae1d - 0xc0485e18 (1067 kB) [ 0.010000] .text : 0xc0100000 - 0xc037ae1d (2539 kB) [ 0.010000] Checking if this processor honours the WP bit even in supervisor mode...Ok. [ 0.010000] installing Xen timer for CPU 0 [ 0.010000] Calibrating delay loop (skipped), value calculated using timer frequency.. 6027.57 BogoMIPS (lpj=30137880) [ 0.010000] Mount-cache hash table entries: 512 [ 0.010000] CPU: L1 I Cache: 64K (64 bytes/line), D cache 64K (64 bytes/line) [ 0.010000] CPU: L2 Cache: 1024K (64 bytes/line) [ 0.010000] CPU: Physical Processor ID: 0 [ 0.010000] CPU: Processor Core ID: 0 [ 0.010000] SMP alternatives: switching to UP code [ 0.010000] Freeing SMP alternatives: 28k freed [ 0.010180] Brought up 1 CPUs [ 0.010394] net_namespace: 452 bytes [ 0.010403] Booting paravirtualized kernel on Xen [ 0.010408] Xen version: 4.1.1 (preserve-AD) [ 0.010445] xor: automatically using best checksumming function: pIII_sse [ 0.060003] pIII_sse : 2499.200 MB/sec [ 0.060011] xor: using function: pIII_sse (2499.200 MB/sec) [ 0.060054] Grant table initialized [ 0.060094] NET: Registered protocol family 16 [ 0.062835] bio: create slab at 0 [ 0.063164] xen_balloon: Initialising balloon driver. [ 0.230016] raid6: int32x1 774 MB/s [ 0.400011] raid6: int32x2 1342 MB/s [ 0.570087] raid6: int32x4 649 MB/s [ 0.740008] raid6: int32x8 802 MB/s [ 0.910011] raid6: mmxx1 2348 MB/s [ 1.080015] raid6: mmxx2 4362 MB/s [ 1.250030] raid6: sse1x1 1907 MB/s [ 1.420018] raid6: sse1x2 2746 MB/s [ 1.590025] raid6: sse2x1 3313 MB/s [ 1.760017] raid6: sse2x2 4325 MB/s [ 1.760033] raid6: using algorithm sse2x2 (4325 MB/s) [ 1.760643] NET: Registered protocol family 2 [ 1.760683] IP route cache hash table entries: 32768 (order: 5, 131072 bytes) [ 1.760767] TCP established hash table entries: 131072 (order: 8, 1048576 bytes) [ 1.761182] TCP bind hash table entries: 65536 (order: 7, 524288 bytes) [ 1.761437] TCP: Hash tables configured (established 131072 bind 65536) [ 1.761445] TCP reno registered [ 1.761513] NET: Registered protocol family 1 [ 1.761732] platform rtc_cmos: registered platform RTC device (no PNP device found) [ 1.762311] highmem bounce pool size: 64 pages [ 1.762325] HugeTLB registered 2 MB page size, pre-allocated 0 pages [ 1.762389] VFS: Disk quotas dquot_6.5.2 [ 1.762401] Dquot-cache hash table entries: 1024 (order 0, 4096 bytes) [ 1.762499] squashfs: version 4.0 (2009/01/31) Phillip Lougher [ 1.762596] Installing knfsd (copyright (C) 1996 okir@monad.swb.de). [ 1.762940] msgmni has been set to 1107 [ 1.763134] alg: No test for stdrng (krng) [ 1.763146] async_tx: api initialized (sync-only) [ 1.763155] io scheduler noop registered [ 1.763160] io scheduler anticipatory registered (default) [ 1.763165] io scheduler deadline registered [ 1.763180] io scheduler cfq registered [ 1.766472] loop: module loaded [ 1.783564] Initialising Xen virtual ethernet driver. [ 1.785475] blkfront: xvda1: barriers enabled [ 1.788158] blkfront: xvda2: barriers enabled [ 1.789731] i8042.c: No controller found. [ 1.790197] mice: PS/2 mouse device common for all mice [ 1.790238] md: linear personality registered for level -1 [ 1.790244] md: raid0 personality registered for level 0 [ 1.790249] md: raid1 personality registered for level 1 [ 1.790254] md: raid10 personality registered for level 10 [ 1.790259] md: raid6 personality registered for level 6 [ 1.790264] md: raid5 personality registered for level 5 [ 1.790268] md: raid4 personality registered for level 4 [ 1.790273] md: multipath personality registered for level -4 [ 1.790278] md: faulty personality registered for level -5 [ 1.790305] device-mapper: uevent: version 1.0.3 [ 1.790378] device-mapper: ioctl: 4.14.0-ioctl (2008-04-23) initialised: dm-devel@redhat.com [ 1.790454] device-mapper: multipath: version 1.0.5 loaded [ 1.790460] device-mapper: multipath round-robin: version 1.0.0 loaded [ 1.790554] oprofile: using timer interrupt. [ 1.790565] Netfilter messages via NETLINK v0.30. [ 1.790604] xt_time: kernel timezone is -0000 [ 1.790625] ip_tables: (C) 2000-2006 Netfilter Core Team [ 1.790646] arp_tables: (C) 2002 David S. Miller [ 1.790656] TCP cubic registered [ 1.790661] NET: Registered protocol family 17 [ 1.790680] Bridge firewalling registered [ 1.790742] RPC: Registered udp transport module. [ 1.790747] RPC: Registered tcp transport module. [ 1.790766] Using IPI No-Shortcut mode [ 1.890171] md: Waiting for all devices to be available before autodetect [ 1.890188] md: If you don't use raid, use raid=noautodetect [ 1.890361] md: Autodetecting RAID arrays. [ 1.890367] md: Scanned 0 and added 0 devices. [ 1.890371] md: autorun ... [ 1.890374] md: ... autorun DONE. [ 1.892999] VFS: Mounted root (squashfs filesystem) readonly on device 202:1. [ 1.893048] Freeing unused kernel memory: 244k freed --------------030602000607000908030302 Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel --------------030602000607000908030302-- From xen-devel-bounces@lists.xensource.com Mon Sep 05 03:33:31 2011 Return-path: Envelope-to: www-data@lists.xensource.com Delivery-date: Mon, 05 Sep 2011 03:33:31 -0700 Received: from localhost ([127.0.0.1] helo=lists.colo.xensource.com) by lists.xensource.com with esmtp (Exim 4.43) id 1R0WUd-00016j-1R; Mon, 05 Sep 2011 03:33:31 -0700 Received: from mail174.messagelabs.com ([85.158.138.51]) by lists.xensource.com with esmtp (Exim 4.43) id 1R0WT2-0000VW-AR for xen-devel@lists.xensource.com; Mon, 05 Sep 2011 03:31:52 -0700 X-Env-Sender: james.harper@bendigoit.com.au X-Msg-Ref: server-2.tower-174.messagelabs.com!1315218701!30274597!1 X-Originating-IP: [203.16.224.4] X-StarScan-Version: 6.3.6; banners=-,-,- X-VirusChecked: Checked Received: (qmail 11835 invoked from network); 5 Sep 2011 10:31:48 -0000 Received: from smtp1.bendigoit.com.au (HELO smtp1.bendigoit.com.au) (203.16.224.4) by server-2.tower-174.messagelabs.com with AES256-SHA encrypted SMTP; 5 Sep 2011 10:31:48 -0000 Received: from mail.bendigoit.com.au ([203.16.207.99]) by smtp1.bendigoit.com.au with esmtp (Exim 4.69) (envelope-from ) id 1R0WSn-0006Dm-92; Mon, 05 Sep 2011 20:31:37 +1000 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable Date: Mon, 5 Sep 2011 20:31:36 +1000 Message-ID: In-Reply-To: <4E64A0DF.2070007@hfp.de> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Stability report GPLPV 0.11.0.308 Thread-Index: AcxrtKKGw0SHoTzxT6i4NgIv1q2HRwAAjVvg References: <4E64A0DF.2070007@hfp.de> From: "James Harper" To: "Andreas Kinzler" , X-Really-From-Bendigo-IT: magichashvalue Cc: Subject: [Xen-devel] RE: Stability report GPLPV 0.11.0.308 X-BeenThere: xen-devel@lists.xensource.com X-Mailman-Version: 2.1.5 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xensource.com Errors-To: xen-devel-bounces@lists.xensource.com >=20 > With GPLPV 0.11.0.308 it worked perfectly and with very good performance > for over 9 days but then when I wanted to monitor the status, I was no > longer able to connect via remote desktop. When examining the file > system of the HVMs I found that somehow even the prime95 processes did stop. >=20 > Any ideas? Could c/s 948 make any difference? Network worked perfectly > for 9 days, so I ask myself if the count of c/s 948 is used at all? >=20 There is some combination that I can't reproduce that seems to cause a problem when that count isn't passed in correctly. So it is a bug, but I'm not sure if it causes the problems you are seeing. I can give you a link to a build with that fix applied if you want to test further. Thanks James _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel From xen-devel-bounces@lists.xensource.com Mon Sep 05 03:43:53 2011 Return-path: Envelope-to: www-data@lists.xensource.com Delivery-date: Mon, 05 Sep 2011 03:43:53 -0700 Received: from localhost ([127.0.0.1] helo=lists.colo.xensource.com) by lists.xensource.com with esmtp (Exim 4.43) id 1R0Wee-0001fw-EP; Mon, 05 Sep 2011 03:43:52 -0700 Received: from mail182.messagelabs.com ([85.158.139.83]) by lists.xensource.com with esmtp (Exim 4.43) id 1R0We7-0001Tv-Fg for xen-devel@lists.xensource.com; Mon, 05 Sep 2011 03:43:19 -0700 X-Env-Sender: JBeulich@suse.com X-Msg-Ref: server-7.tower-182.messagelabs.com!1315219396!12074890!1 X-Originating-IP: [130.57.49.28] X-StarScan-Version: 6.3.6; banners=-,-,- X-VirusChecked: Checked Received: (qmail 1929 invoked from network); 5 Sep 2011 10:43:16 -0000 Received: from nat28.tlf.novell.com (HELO nat28.tlf.novell.com) (130.57.49.28) by server-7.tower-182.messagelabs.com with DHE-RSA-AES256-SHA encrypted SMTP; 5 Sep 2011 10:43:16 -0000 Received: from EMEA1-MTA by nat28.tlf.novell.com with Novell_GroupWise; Mon, 05 Sep 2011 11:43:15 +0100 Message-Id: <4E64C3E10200007800054A4F@nat28.tlf.novell.com> X-Mailer: Novell GroupWise Internet Agent 8.0.1 Date: Mon, 05 Sep 2011 11:43:13 +0100 From: "Jan Beulich" To: "Andrew Cooper" Subject: Re: [Xen-devel] [PATCH] IRQ: manually EOI migrating line interrupts References: In-Reply-To: Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: quoted-printable Content-Disposition: inline Cc: xen-devel@lists.xensource.com X-BeenThere: xen-devel@lists.xensource.com X-Mailman-Version: 2.1.5 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xensource.com Errors-To: xen-devel-bounces@lists.xensource.com >>> On 30.08.11 at 16:17, Andrew Cooper wrote: > When migrating IO-APIC line level interrupts between PCPUs, the > migration code rewrites the IO-APIC entry to point to the new > CPU/Vector before EOI'ing it. >=20 > The EOI process says that EOI'ing the Local APIC will cause a > broadcast with the vector number, which the IO-APIC must listen to to > clear the IRR and Status bits. >=20 > In the case of migrating, the IO-APIC has already been > reprogrammed so the EOI broadcast with the old vector fails to match > the new vector, leaving the IO-APIC with an outstanding vector, > preventing any more use of that line interrupt. This causes a lockup > especially when your root device is using PCI INTA (megaraid_sas > driver *ehem*) >=20 > However, the problem is mostly hidden because send_cleanup_vector() > causes a cleanup of all moving vectors on the current PCPU in such a > way which does not cause the problem, and if the problem has occured, > the writes it makes to the IO-APIC clears the IRR and Status bits > which unlocks the problem. >=20 >=20 > This fix is distinctly a temporary hack, waiting on a cleanup of the > irq code. It checks for the edge case where we have moved the irq, > and manually EOI's the old vector with the IO-APIC which correctly > clears the IRR and Status bits. Also, it protects the code which > updates irq_cfg by disabling interrupts. >=20 > Signed-off-by: Andrew Cooper >=20 > diff -r 227130622561 -r a95fd5d03c20 xen/arch/x86/hpet.c > --- a/xen/arch/x86/hpet.c Thu Aug 25 12:03:14 2011 +0100 > +++ b/xen/arch/x86/hpet.c Tue Aug 30 15:15:56 2011 +0100 > @@ -301,7 +301,7 @@ static void hpet_msi_ack(unsigned int ir > ack_APIC_irq(); > } > =20 > -static void hpet_msi_end(unsigned int irq) > +static void hpet_msi_end(unsigned int irq, u8 vector) > { > } > =20 > diff -r 227130622561 -r a95fd5d03c20 xen/arch/x86/i8259.c > --- a/xen/arch/x86/i8259.c Thu Aug 25 12:03:14 2011 +0100 > +++ b/xen/arch/x86/i8259.c Tue Aug 30 15:15:56 2011 +0100 > @@ -93,7 +93,7 @@ static unsigned int startup_8259A_irq(un > return 0; /* never anything pending */ > } > =20 > -static void end_8259A_irq(unsigned int irq) > +static void end_8259A_irq(unsigned int irq, u8 vector) > { > if (!(irq_desc[irq].status & (IRQ_DISABLED|IRQ_INPROGRESS))) > enable_8259A_irq(irq); > diff -r 227130622561 -r a95fd5d03c20 xen/arch/x86/io_apic.c > --- a/xen/arch/x86/io_apic.c Thu Aug 25 12:03:14 2011 +0100 > +++ b/xen/arch/x86/io_apic.c Tue Aug 30 15:15:56 2011 +0100 > @@ -1690,7 +1690,7 @@ static void mask_and_ack_level_ioapic_ir > } > } > =20 > -static void end_level_ioapic_irq (unsigned int irq) > +static void end_level_ioapic_irq (unsigned int irq, u8 vector) > { > unsigned long v; > int i; > @@ -1739,6 +1739,14 @@ static void end_level_ioapic_irq (unsign > */ > i =3D IO_APIC_VECTOR(irq); > =20 > + /* Manually EOI the old vector if we are moving to the new */ > + if ( vector && i !=3D vector ) > + { > + int ioapic; > + for (ioapic =3D 0; ioapic < nr_ioapics; ioapic++) > + io_apic_eoi(ioapic, i); While I realize that the patch already went in, this still will need adjustment for dealing with old IO-APICs that don't have an EOI register (or if we want to stop supporting such, a clear panic() rather than subtle and hard to debug failure). Jan > + } > + > v =3D apic_read(APIC_TMR + ((i & ~0x1f) >> 1)); > =20 > ack_APIC_irq(); > @@ -1762,7 +1770,10 @@ static void disable_edge_ioapic_irq(unsi > { > } > =20 > -#define end_edge_ioapic_irq disable_edge_ioapic_irq > +static void end_edge_ioapic_irq(unsigned int irq, u8 vector) > +{ > +} > + > =20 > /* > * Level and edge triggered IO-APIC interrupts need different handling, > @@ -1811,7 +1822,7 @@ static void ack_msi_irq(unsigned int irq > ack_APIC_irq(); /* ACKTYPE_NONE */ > } > =20 > -static void end_msi_irq(unsigned int irq) > +static void end_msi_irq(unsigned int irq, u8 vector) > { > if ( !msi_maskable_irq(irq_desc[irq].msi_desc) ) > ack_APIC_irq(); /* ACKTYPE_EOI */ > diff -r 227130622561 -r a95fd5d03c20 xen/arch/x86/irq.c > --- a/xen/arch/x86/irq.c Thu Aug 25 12:03:14 2011 +0100 > +++ b/xen/arch/x86/irq.c Tue Aug 30 15:15:56 2011 +0100 > @@ -345,6 +345,7 @@ static void __do_IRQ_guest(int vector); > void no_action(int cpl, void *dev_id, struct cpu_user_regs *regs) { } > =20 > static void enable_none(unsigned int vector) { } > +static void end_none(unsigned int irq, u8 vector) { } > static unsigned int startup_none(unsigned int vector) { return 0; } > static void disable_none(unsigned int vector) { } > static void ack_none(unsigned int irq) > @@ -353,7 +354,6 @@ static void ack_none(unsigned int irq) > } > =20 > #define shutdown_none disable_none > -#define end_none enable_none > =20 > hw_irq_controller no_irq_type =3D { > "none", > @@ -381,6 +381,7 @@ int __assign_irq_vector(int irq, struct=20 > static int current_vector =3D FIRST_DYNAMIC_VECTOR, current_offset = =3D 0; > unsigned int old_vector; > int cpu, err; > + unsigned long flags; > cpumask_t tmp_mask; > =20 > old_vector =3D irq_to_vector(irq); > @@ -431,6 +432,7 @@ next: > /* Found one! */ > current_vector =3D vector; > current_offset =3D offset; > + local_irq_save(flags); > if (old_vector) { > cfg->move_in_progress =3D 1; > cpus_copy(cfg->old_cpu_mask, cfg->cpu_mask); > @@ -450,6 +452,7 @@ next: > if (IO_APIC_IRQ(irq)) > irq_vector[irq] =3D vector; > err =3D 0; > + local_irq_restore(flags); > break; > } > return err; > @@ -657,7 +660,7 @@ asmlinkage void do_IRQ(struct cpu_user_r > desc->status &=3D ~IRQ_INPROGRESS; > =20 > out: > - desc->handler->end(irq); > + desc->handler->end(irq, regs->entry_vector); > out_no_end: > spin_unlock(&desc->lock); > irq_exit(); > @@ -857,7 +860,7 @@ static void irq_guest_eoi_timer_fn(void=20 > switch ( action->ack_type ) > { > case ACKTYPE_UNMASK: > - desc->handler->end(irq); > + desc->handler->end(irq, 0); > break; > case ACKTYPE_EOI: > cpu_eoi_map =3D action->cpu_eoi_map; > @@ -885,7 +888,7 @@ static void __do_IRQ_guest(int irq) > /* An interrupt may slip through while freeing an ACKTYPE_EOI = irq.=20 > */ > ASSERT(action->ack_type =3D=3D ACKTYPE_EOI); > ASSERT(desc->status & IRQ_DISABLED); > - desc->handler->end(irq); > + desc->handler->end(irq, vector); > return; > } > =20 > @@ -1099,7 +1102,7 @@ static void flush_ready_eoi(void) > ASSERT(irq > 0); > desc =3D irq_to_desc(irq); > spin_lock(&desc->lock); > - desc->handler->end(irq); > + desc->handler->end(irq, peoi[sp].vector); > spin_unlock(&desc->lock); > } > =20 > @@ -1177,7 +1180,7 @@ void desc_guest_eoi(struct irq_desc *des > if ( action->ack_type =3D=3D ACKTYPE_UNMASK ) > { > ASSERT(cpus_empty(action->cpu_eoi_map)); > - desc->handler->end(irq); > + desc->handler->end(irq, 0); > spin_unlock_irq(&desc->lock); > return; > } > @@ -1431,7 +1434,7 @@ static irq_guest_action_t *__pirq_guest_ > case ACKTYPE_UNMASK: > if ( test_and_clear_bool(pirq->masked) && > (--action->in_flight =3D=3D 0) ) > - desc->handler->end(irq); > + desc->handler->end(irq, 0); > break; > case ACKTYPE_EOI: > /* NB. If #guests =3D=3D 0 then we clear the eoi_map later on. = */ > diff -r 227130622561 -r a95fd5d03c20 xen/drivers/passthrough/amd/iommu_in= it.c > --- a/xen/drivers/passthrough/amd/iommu_init.c Thu Aug 25 = 12:03:14 2011 +0100 > +++ b/xen/drivers/passthrough/amd/iommu_init.c Tue Aug 30 = 15:15:56 2011 +0100 > @@ -441,7 +441,7 @@ static unsigned int iommu_msi_startup(un > return 0; > } > =20 > -static void iommu_msi_end(unsigned int irq) > +static void iommu_msi_end(unsigned int irq, u8 vector) > { > iommu_msi_unmask(irq); > ack_APIC_irq(); > diff -r 227130622561 -r a95fd5d03c20 xen/drivers/passthrough/vtd/iommu.c > --- a/xen/drivers/passthrough/vtd/iommu.c Thu Aug 25 12:03:14 2011 = +0100 > +++ b/xen/drivers/passthrough/vtd/iommu.c Tue Aug 30 15:15:56 2011 = +0100 > @@ -971,7 +971,7 @@ static unsigned int dma_msi_startup(unsi > return 0; > } > =20 > -static void dma_msi_end(unsigned int irq) > +static void dma_msi_end(unsigned int irq, u8 vector) > { > dma_msi_unmask(irq); > ack_APIC_irq(); > diff -r 227130622561 -r a95fd5d03c20 xen/include/xen/irq.h > --- a/xen/include/xen/irq.h Thu Aug 25 12:03:14 2011 +0100 > +++ b/xen/include/xen/irq.h Tue Aug 30 15:15:56 2011 +0100 > @@ -44,7 +44,7 @@ struct hw_interrupt_type { > void (*enable)(unsigned int irq); > void (*disable)(unsigned int irq); > void (*ack)(unsigned int irq); > - void (*end)(unsigned int irq); > + void (*end)(unsigned int irq, u8 vector); > void (*set_affinity)(unsigned int irq, cpumask_t mask); > }; > =20 >=20 > _______________________________________________ > Xen-devel mailing list > Xen-devel@lists.xensource.com=20 > http://lists.xensource.com/xen-devel=20 _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel From xen-devel-bounces@lists.xensource.com Mon Sep 05 03:51:14 2011 Return-path: Envelope-to: www-data@lists.xensource.com Delivery-date: Mon, 05 Sep 2011 03:51:14 -0700 Received: from localhost ([127.0.0.1] helo=lists.colo.xensource.com) by lists.xensource.com with esmtp (Exim 4.43) id 1R0Wlm-0002FJ-6y; Mon, 05 Sep 2011 03:51:14 -0700 Received: from mail182.messagelabs.com ([85.158.139.83]) by lists.xensource.com with esmtp (Exim 4.43) id 1R0WlM-00022h-FK for xen-devel@lists.xensource.com; Mon, 05 Sep 2011 03:50:48 -0700 X-Env-Sender: JBeulich@suse.com X-Msg-Ref: server-5.tower-182.messagelabs.com!1315219845!12096819!1 X-Originating-IP: [130.57.49.28] X-StarScan-Version: 6.3.6; banners=-,-,- X-VirusChecked: Checked Received: (qmail 18825 invoked from network); 5 Sep 2011 10:50:45 -0000 Received: from nat28.tlf.novell.com (HELO nat28.tlf.novell.com) (130.57.49.28) by server-5.tower-182.messagelabs.com with DHE-RSA-AES256-SHA encrypted SMTP; 5 Sep 2011 10:50:45 -0000 Received: from EMEA1-MTA by nat28.tlf.novell.com with Novell_GroupWise; Mon, 05 Sep 2011 11:50:44 +0100 Message-Id: <4E64C5A20200007800054A59@nat28.tlf.novell.com> X-Mailer: Novell GroupWise Internet Agent 8.0.1 Date: Mon, 05 Sep 2011 11:50:42 +0100 From: "Jan Beulich" To: "Andrew Cooper" , "Keir Fraser" Subject: [Xen-devel] Re: [PATCH] IRQ: manually EOI migrating line interrupts References: <4E5CFF7C.90309@citrix.com> In-Reply-To: <4E5CFF7C.90309@citrix.com> Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: quoted-printable Content-Disposition: inline Cc: "xen-devel@lists.xensource.com" X-BeenThere: xen-devel@lists.xensource.com X-Mailman-Version: 2.1.5 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xensource.com Errors-To: xen-devel-bounces@lists.xensource.com >>> On 30.08.11 at 17:19, Andrew Cooper wrote: > P.S. If anyone knows which manual contains the specificaion/programming > guide for the IO-APIC, I would be very gratefull. Google always points > to 82093AA datasheet which is very out of date. Intel's ICH documentation (e.g. document number 319973-003) has a section on the IO-APIC (among the other LPC stuff), which covers the EOI register and possibly other newer additions. Jan _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel From xen-devel-bounces@lists.xensource.com Mon Sep 05 04:33:50 2011 Return-path: Envelope-to: www-data@lists.xensource.com Delivery-date: Mon, 05 Sep 2011 04:33:50 -0700 Received: from localhost ([127.0.0.1] helo=lists.colo.xensource.com) by lists.xensource.com with esmtp (Exim 4.43) id 1R0XR0-0003TA-2R; Mon, 05 Sep 2011 04:33:50 -0700 Received: from mail21.messagelabs.com ([85.158.143.35]) by lists.xensource.com with esmtp (Exim 4.43) id 1R0XPW-0003Ff-Be for xen-devel@lists.xensource.com; Mon, 05 Sep 2011 04:32:19 -0700 X-Env-Sender: olaf@aepfle.de X-Msg-Ref: server-11.tower-21.messagelabs.com!1315222319!41377558!1 X-Originating-IP: [81.169.146.161] X-StarScan-Version: 6.3.6; banners=-,-,- X-VirusChecked: Checked Received: (qmail 18072 invoked from network); 5 Sep 2011 11:31:59 -0000 Received: from mo-p00-ob.rzone.de (HELO mo-p00-ob.rzone.de) (81.169.146.161) by server-11.tower-21.messagelabs.com with EDH-RSA-DES-CBC3-SHA encrypted SMTP; 5 Sep 2011 11:31:59 -0000 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; t=1315222334; l=1453; s=domk; d=aepfle.de; h=In-Reply-To:Content-Type:MIME-Version:References:Subject:Cc:To:From: Date:X-RZG-CLASS-ID:X-RZG-AUTH; bh=82HXdVDvczLB/cEpac5rn7Vz7gc=; b=M73r3HJtm51oLeMBNxZjKAc/3xeixu6ZaHleppWzBdWUSAdbnp/zFE9sODXdxp/eipu iywDZlcA23dqSfxyEUUGVwYKnS43fd52Ed8t/3cogjG1dyGaB9lq+pn6o7ANO5fgaaLCY mSdGs/apwINjEFbvFD0Dg8Y4rYCSuXVqg/k= X-RZG-AUTH: :P2EQZWCpfu+qG7CngxMFH1J+zrwiavkK6tmQaLfmwtM48/ll2s7pEE4= X-RZG-CLASS-ID: mo00 Received: from probook.site (dslb-084-057-083-022.pools.arcor-ip.net [84.57.83.22]) by smtp.strato.de (klopstock mo52) (RZmta 26.6) with (EDH-RSA-DES-CBC3-SHA encrypted) ESMTPA id B01409n85BQByT ; Mon, 5 Sep 2011 13:31:55 +0200 (MEST) Received: by probook.site (Postfix, from userid 1000) id 462AC18B65; Mon, 5 Sep 2011 13:31:55 +0200 (CEST) Date: Mon, 5 Sep 2011 13:31:55 +0200 From: Olaf Hering To: zhen shi Message-ID: <20110905113154.GA29099@aepfle.de> References: <20110901101525.GA3258@aepfle.de> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline In-Reply-To: <20110901101525.GA3258@aepfle.de> User-Agent: Mutt/1.5.21.rev5535 (2011-07-01) Cc: xen-devel@lists.xensource.com Subject: [Xen-devel] Re: some questions of IO ring in xenpaging X-BeenThere: xen-devel@lists.xensource.com X-Mailman-Version: 2.1.5 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xensource.com Errors-To: xen-devel-bounces@lists.xensource.com On Thu, Sep 01, Olaf Hering wrote: > On Thu, Sep 01, zhen shi wrote: > > > Hi Olaf -- > > > > I have two questions to ask you about xenpaging. > > 1) When guest os causes page_fault for the accessed page is paging_out > > or paged, it will execute p2m_mem_paging_populate(). and in > > p2m_mem_paging_populate() it will first check if the ring is full. > > when I ran with domU suse11 4G memory and 8vcpus, I found there will > > be a corruption in checking the ring. > > For example, if 4vcpus are met with page faults when they access > > different pages, and there is only four free-requests for the ring. > > and then they call p2m_mem_paging_populate(),and execute > > mem_event_check_ring(d) at the same time.All will find ring is not > > full,and will fill the requests. It will cause the latter request to > > cover the front request. > > and I think there should a lock before the mem_event_check_ring(d), > > and normally it unlock after mem_event_put_request(d, &req). > > You can review the attached doc of xenpaging_IO_ring.txt to see if my > > opnion is right. > > Yes, you are right. > I think mem_event_check_ring() should reserve a reference, and > mem_event_put_request() should use that reference. > mem_sharing_alloc_page() even has a comment that this should be done. Try this patch. It implements some ref counting. http://lists.xensource.com/archives/html/xen-devel/2011-09/msg00189.html Olaf _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel From xen-devel-bounces@lists.xensource.com Mon Sep 05 04:44:53 2011 Return-path: Envelope-to: www-data@lists.xensource.com Delivery-date: Mon, 05 Sep 2011 04:44:53 -0700 Received: from localhost ([127.0.0.1] helo=lists.colo.xensource.com) by lists.xensource.com with esmtp (Exim 4.43) id 1R0Xbf-0004hY-6r; Mon, 05 Sep 2011 04:44:51 -0700 Received: from mail21.messagelabs.com ([85.158.143.35]) by lists.xensource.com with esmtp (Exim 4.43) id 1R0XaZ-0004Ug-3m for xen-devel@lists.xensource.com; Mon, 05 Sep 2011 04:43:43 -0700 X-Env-Sender: Andrew.Cooper3@citrix.com X-Msg-Ref: server-8.tower-21.messagelabs.com!1315223004!57766779!1 X-Originating-IP: [66.165.176.89] X-StarScan-Version: 6.3.6; banners=-,-,- X-VirusChecked: Checked Received: (qmail 22664 invoked from network); 5 Sep 2011 11:43:25 -0000 Received: from smtp.citrix.com (HELO SMTP.CITRIX.COM) (66.165.176.89) by server-8.tower-21.messagelabs.com with RC4-SHA encrypted SMTP; 5 Sep 2011 11:43:25 -0000 X-IronPort-AV: E=Sophos;i="4.68,333,1312171200"; d="scan'208";a="16696488" Received: from ftlpmailmx02.citrite.net ([10.13.107.66]) by FTLPIPO01.CITRIX.COM with ESMTP/TLS/RC4-MD5; 05 Sep 2011 07:43:38 -0400 Received: from [10.80.2.18] (10.80.2.18) by FTLPMAILMX02.citrite.net (10.13.107.66) with Microsoft SMTP Server id 8.3.137.0; Mon, 5 Sep 2011 07:43:38 -0400 Message-ID: <4E64B5E9.6010606@citrix.com> Date: Mon, 5 Sep 2011 12:43:37 +0100 From: Andrew Cooper User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.2.20) Gecko/20110805 Lightning/1.0b2 Thunderbird/3.1.12 MIME-Version: 1.0 To: George Dunlap Subject: Re: [Xen-devel] [PATCH 3 of 3] IRQ: Introduce old_vector to irq_cfg References: <1a244d4ca6ac2e442c3b.1314981316@andrewcoop.uk.xensource.com> In-Reply-To: Content-Type: text/plain; charset="ISO-8859-1" Content-Transfer-Encoding: 7bit Cc: "xen-devel@lists.xensource.com" X-BeenThere: xen-devel@lists.xensource.com X-Mailman-Version: 2.1.5 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xensource.com Errors-To: xen-devel-bounces@lists.xensource.com On 05/09/11 11:14, George Dunlap wrote: > Comments inline. > > On Fri, Sep 2, 2011 at 5:35 PM, Andrew Cooper wrote: >> Introduce old_vector to irq_cfg with the same principle as >> old_cpu_mask. This removes a brute force loop from >> __clear_irq_vector(), and paves the way to correct bitrotten logic >> elsewhere in the irq code. >> >> Signed-off-by Andrew Cooper >> >> diff -r cf93a1825d66 -r 1a244d4ca6ac xen/arch/x86/io_apic.c >> --- a/xen/arch/x86/io_apic.c Fri Sep 02 17:33:17 2011 +0100 >> +++ b/xen/arch/x86/io_apic.c Fri Sep 02 17:33:17 2011 +0100 >> @@ -487,11 +487,16 @@ fastcall void smp_irq_move_cleanup_inter >> __get_cpu_var(vector_irq)[vector] = -1; >> cfg->move_cleanup_count--; >> >> - if ( cfg->move_cleanup_count == 0 >> - && cfg->used_vectors ) >> + if ( cfg->move_cleanup_count == 0 ) >> { >> - ASSERT(test_bit(vector, cfg->used_vectors)); >> - clear_bit(vector, cfg->used_vectors); >> + cfg->old_vector = -1; > Just for consistency, should this be IRQ_VECTOR_UNASSIGNED instead of -1? Yes - I missed that. However, IRQ_VECTOR_UNASSIGNED should be -1 instead of 0, as the first 32 entries of irq_vector have 0 entries which are not unassigned. >> + cpus_clear(cfg->old_cpu_mask); >> + >> + if ( cfg->used_vectors ) >> + { >> + ASSERT(test_bit(vector, cfg->used_vectors)); >> + clear_bit(vector, cfg->used_vectors); >> + } >> } >> unlock: >> spin_unlock(&desc->lock); >> diff -r cf93a1825d66 -r 1a244d4ca6ac xen/arch/x86/irq.c >> --- a/xen/arch/x86/irq.c Fri Sep 02 17:33:17 2011 +0100 >> +++ b/xen/arch/x86/irq.c Fri Sep 02 17:33:17 2011 +0100 >> @@ -211,15 +211,9 @@ static void __clear_irq_vector(int irq) >> >> cpus_and(tmp_mask, cfg->old_cpu_mask, cpu_online_map); >> for_each_cpu_mask(cpu, tmp_mask) { >> - for (vector = FIRST_DYNAMIC_VECTOR; vector <= LAST_DYNAMIC_VECTOR; >> - vector++) { >> - if (per_cpu(vector_irq, cpu)[vector] != irq) >> - continue; >> - TRACE_3D(TRC_HW_IRQ_MOVE_FINISH, >> - irq, vector, cpu); >> - per_cpu(vector_irq, cpu)[vector] = -1; >> - break; >> - } >> + ASSERT( per_cpu(vector_irq, cpu)[cfg->old_vector] == irq ); >> + TRACE_3D(TRC_HW_IRQ_MOVE_FINISH, irq, vector, cpu); >> + per_cpu(vector_irq, cpu)[vector] = -1; > Do you mean cfg->old_vector here, instead of vector? No - the TRACE_3D and per_cpu lines are only diffs because of the change in whitespace when removing the loop (and this is the code which should actually remove the vector mapping). You are correct however that cfg->old_vector should be set to IRQ_VECTOR_UNASSIGNED at the end of the for_each for consistency. (In reality, you cant get to this bit of code without having a valid cfg->old_vector) >> } >> >> if ( cfg->used_vectors ) >> @@ -279,6 +273,7 @@ static void __init init_one_irq_desc(str >> static void __init init_one_irq_cfg(struct irq_cfg *cfg) >> { >> cfg->vector = IRQ_VECTOR_UNASSIGNED; >> + cfg->old_vector = IRQ_VECTOR_UNASSIGNED; >> cpus_clear(cfg->cpu_mask); >> cpus_clear(cfg->old_cpu_mask); >> cfg->used_vectors = NULL; >> @@ -418,6 +413,7 @@ next: >> if (old_vector) { >> cfg->move_in_progress = 1; >> cpus_copy(cfg->old_cpu_mask, cfg->cpu_mask); >> + cfg->old_vector = cfg->vector; >> } >> trace_irq_mask(TRC_HW_IRQ_ASSIGN_VECTOR, irq, vector, &tmp_mask); >> for_each_cpu_mask(new_cpu, tmp_mask) >> diff -r cf93a1825d66 -r 1a244d4ca6ac xen/include/asm-x86/irq.h >> --- a/xen/include/asm-x86/irq.h Fri Sep 02 17:33:17 2011 +0100 >> +++ b/xen/include/asm-x86/irq.h Fri Sep 02 17:33:17 2011 +0100 >> @@ -28,7 +28,8 @@ typedef struct { >> } vmask_t; >> >> struct irq_cfg { >> - int vector; >> + s16 vector; /* vector itself is only 8 bits, */ >> + s16 old_vector; /* but we use -1 for unassigned */ >> cpumask_t cpu_mask; >> cpumask_t old_cpu_mask; >> unsigned move_cleanup_count; >> >> _______________________________________________ >> Xen-devel mailing list >> Xen-devel@lists.xensource.com >> http://lists.xensource.com/xen-devel >> -- Andrew Cooper - Dom0 Kernel Engineer, Citrix XenServer T: +44 (0)1223 225 900, http://www.citrix.com _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel From xen-devel-bounces@lists.xensource.com Mon Sep 05 04:46:39 2011 Return-path: Envelope-to: www-data@lists.xensource.com Delivery-date: Mon, 05 Sep 2011 04:46:39 -0700 Received: from localhost ([127.0.0.1] helo=lists.colo.xensource.com) by lists.xensource.com with esmtp (Exim 4.43) id 1R0XdO-00055W-Vo; Mon, 05 Sep 2011 04:46:39 -0700 Received: from mail174.messagelabs.com ([85.158.138.51]) by lists.xensource.com with smtp (Exim 4.43) id 1R0XbZ-0004ff-St for xen-devel@lists.xensource.com; Mon, 05 Sep 2011 04:44:46 -0700 X-Env-Sender: Stefano.Stabellini@eu.citrix.com X-Msg-Ref: server-3.tower-174.messagelabs.com!1315223081!24213337!1 X-Originating-IP: [62.200.22.115] X-StarScan-Version: 6.3.6; banners=-,-,- X-VirusChecked: Checked Received: (qmail 17409 invoked from network); 5 Sep 2011 11:44:42 -0000 Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115) by server-3.tower-174.messagelabs.com with SMTP; 5 Sep 2011 11:44:42 -0000 X-IronPort-AV: E=Sophos;i="4.68,333,1312156800"; d="scan'208";a="7603009" Received: from lonpmailmx01.citrite.net ([10.30.203.162]) by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5; 05 Sep 2011 11:44:41 +0000 Received: from kaball.uk.xensource.com (10.80.2.59) by LONPMAILMX01.citrite.net (10.30.203.162) with Microsoft SMTP Server id 8.3.137.0; Mon, 5 Sep 2011 12:44:41 +0100 Date: Mon, 5 Sep 2011 12:52:42 +0100 From: Stefano Stabellini X-X-Sender: sstabellini@kaball-desktop To: Jeremy Fitzhardinge In-Reply-To: <4E614FBD.2030509@goop.org> Message-ID: References: <38bb37e15f6e5056d5238adac945bc1837a996ec.1314922370.git.jeremy.fitzhardinge@citrix.com> <1314974826.1861.1.camel@twins> <4E612EA1.20007@goop.org> <1314996468.8255.0.camel@twins> <4E614FBD.2030509@goop.org> User-Agent: Alpine 2.00 (DEB 1167 2008-08-23) MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Cc: Marcelo Tosatti , Keir Fraser , Nick Piggin , KVM , Stefano Stabellini , Peter Zijlstra , the arch/x86 maintainers , Linux Kernel Mailing List , Jeremy Fitzhardinge , Andi Kleen , Avi Kivity , "H. Peter Anvin" , Ingo Molnar , Linus Torvalds , Xen Devel Subject: [Xen-devel] Re: [PATCH 08/13] xen/pvticketlock: disable interrupts while blocking X-BeenThere: xen-devel@lists.xensource.com X-Mailman-Version: 2.1.5 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xensource.com Errors-To: xen-devel-bounces@lists.xensource.com CC'ing Keir. On Fri, 2 Sep 2011, Jeremy Fitzhardinge wrote: > On 09/02/2011 01:47 PM, Peter Zijlstra wrote: > > On Fri, 2011-09-02 at 12:29 -0700, Jeremy Fitzhardinge wrote: > >>> I know that its generally considered bad form, but there's at least one > >>> spinlock that's only taken from NMI context and thus hasn't got any > >>> deadlock potential. > >> Which one? > > arch/x86/kernel/traps.c:nmi_reason_lock > > > > It serializes NMI access to the NMI reason port across CPUs. > > Ah, OK. Well, that will never happen in a PV Xen guest. But PV > ticketlocks are equally applicable to an HVM Xen domain (and KVM guest), > so I guess there's at least some chance there could be a virtual > emulated NMI. Maybe? Does qemu do that kind of thing? Xen knows how to inject NMIs to HVM guests, even though I am not sure if it is actually done in practice at the moment. However digging into the implementation details, it looks like virtual NMIs are not injected if blocking-by-STI (or blocking-by-MOV-SS), so we should be fine, even though I don't know if you actually want to rely on this: /* * We can only inject an NMI if no blocking by MOV SS (also, depending on * implementation, if no blocking by STI). If pin-based 'virtual NMIs' * control is specified then the NMI-blocking interruptibility flag is * also checked. The 'virtual NMI pending' control (available only in * conjunction with 'virtual NMIs') causes a VM exit when all these checks * succeed. It will exit immediately after VM entry if the checks succeed * at that point. * * Because a processor may or may not check blocking-by-STI when injecting * a virtual NMI, it will be necessary to convert that to block-by-MOV-SS * before specifying the 'virtual NMI pending' control. Otherwise we could * enter an infinite loop where we check blocking-by-STI in software and * thus delay delivery of a virtual NMI, but the processor causes immediate * VM exit because it does not check blocking-by-STI. */ _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel From xen-devel-bounces@lists.xensource.com Mon Sep 05 04:51:55 2011 Return-path: Envelope-to: www-data@lists.xensource.com Delivery-date: Mon, 05 Sep 2011 04:51:55 -0700 Received: from localhost ([127.0.0.1] helo=lists.colo.xensource.com) by lists.xensource.com with esmtp (Exim 4.43) id 1R0XiV-0005Wt-JP; Mon, 05 Sep 2011 04:51:55 -0700 Received: from mail27.messagelabs.com ([193.109.254.147]) by lists.xensource.com with esmtp (Exim 4.43) id 1R0Xho-0005Km-TA for xen-devel@lists.xensource.com; Mon, 05 Sep 2011 04:51:13 -0700 X-Env-Sender: George.Dunlap@eu.citrix.com X-Msg-Ref: server-11.tower-27.messagelabs.com!1315223461!36095331!1 X-Originating-IP: [66.165.176.89] X-StarScan-Version: 6.3.6; banners=-,-,- X-VirusChecked: Checked Received: (qmail 23293 invoked from network); 5 Sep 2011 11:51:03 -0000 Received: from smtp.citrix.com (HELO SMTP.CITRIX.COM) (66.165.176.89) by server-11.tower-27.messagelabs.com with RC4-SHA encrypted SMTP; 5 Sep 2011 11:51:03 -0000 X-IronPort-AV: E=Sophos;i="4.68,333,1312171200"; d="scan'208";a="16696550" Received: from ftlpmailmx02.citrite.net ([10.13.107.66]) by FTLPIPO01.CITRIX.COM with ESMTP/TLS/RC4-MD5; 05 Sep 2011 07:51:08 -0400 Received: from smtp01.ad.xensource.com (10.219.128.104) by smtprelay.citrix.com (10.13.107.66) with Microsoft SMTP Server id 8.3.137.0; Mon, 5 Sep 2011 07:51:08 -0400 Received: from [10.80.2.24] (elijah.uk.xensource.com [10.80.2.24]) by smtp01.ad.xensource.com (8.13.1/8.13.1) with ESMTP id p85Bp6MH018769; Mon, 5 Sep 2011 04:51:06 -0700 Subject: Re: [Xen-devel] [PATCH 3 of 3] IRQ: Introduce old_vector to irq_cfg From: George Dunlap To: Andrew Cooper In-Reply-To: <4E64B5E9.6010606@citrix.com> References: <1a244d4ca6ac2e442c3b.1314981316@andrewcoop.uk.xensource.com> <4E64B5E9.6010606@citrix.com> Content-Type: text/plain; charset="UTF-8" Date: Mon, 5 Sep 2011 12:45:27 +0100 Message-ID: <1315223127.5679.9118.camel@elijah> MIME-Version: 1.0 X-Mailer: Evolution 2.28.3 Content-Transfer-Encoding: 7bit Cc: George Dunlap , "xen-devel@lists.xensource.com" X-BeenThere: xen-devel@lists.xensource.com X-Mailman-Version: 2.1.5 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xensource.com Errors-To: xen-devel-bounces@lists.xensource.com On Mon, 2011-09-05 at 12:43 +0100, Andrew Cooper wrote: > >> diff -r cf93a1825d66 -r 1a244d4ca6ac xen/arch/x86/irq.c > >> --- a/xen/arch/x86/irq.c Fri Sep 02 17:33:17 2011 +0100 > >> +++ b/xen/arch/x86/irq.c Fri Sep 02 17:33:17 2011 +0100 > >> @@ -211,15 +211,9 @@ static void __clear_irq_vector(int irq) > >> > >> cpus_and(tmp_mask, cfg->old_cpu_mask, cpu_online_map); > >> for_each_cpu_mask(cpu, tmp_mask) { > >> - for (vector = FIRST_DYNAMIC_VECTOR; vector <= LAST_DYNAMIC_VECTOR; > >> - vector++) { > >> - if (per_cpu(vector_irq, cpu)[vector] != irq) > >> - continue; > >> - TRACE_3D(TRC_HW_IRQ_MOVE_FINISH, > >> - irq, vector, cpu); > >> - per_cpu(vector_irq, cpu)[vector] = -1; > >> - break; > >> - } > >> + ASSERT( per_cpu(vector_irq, cpu)[cfg->old_vector] == irq ); > >> + TRACE_3D(TRC_HW_IRQ_MOVE_FINISH, irq, vector, cpu); > >> + per_cpu(vector_irq, cpu)[vector] = -1; > > Do you mean cfg->old_vector here, instead of vector? > > No - the TRACE_3D and per_cpu lines are only diffs because of the change > in whitespace when removing the loop (and this is the code which should > actually remove the vector mapping). You are correct however that > cfg->old_vector should be set to IRQ_VECTOR_UNASSIGNED at the end of the > for_each for consistency. (In reality, you cant get to this bit of code > without having a valid cfg->old_vector) But you're also removing the for loop, which sets vector. (I.e., there's some bad coding in the original code, where the variable "vector" means different things in different parts of the function.) Before the patch, vector in that line will be any vector between FIRST_DYNAMIC_VECTOR and LAST_DYNAMIC_VECTOR s.t. per_cpu(vector_irq, cpu)[vector] == irq. After the patch, vector at that line will be equal to cfg->vector (set above). Since we're looking through the cpus in cfg->old_cpu_mask, I would think that we would be clearing cfg->old_vector, would we not? In any case, it's certain that the ASSERT() should be checking the same thing as the clearing line; i.e., either ASSERT(...[vector]==irq) and then set ...[vector]=-1, or ASSERT(...[cfg->old_vector]==irq) and then set ...[cfg->old_vector]=-1. -George > > >> } > >> > >> if ( cfg->used_vectors ) > >> @@ -279,6 +273,7 @@ static void __init init_one_irq_desc(str > >> static void __init init_one_irq_cfg(struct irq_cfg *cfg) > >> { > >> cfg->vector = IRQ_VECTOR_UNASSIGNED; > >> + cfg->old_vector = IRQ_VECTOR_UNASSIGNED; > >> cpus_clear(cfg->cpu_mask); > >> cpus_clear(cfg->old_cpu_mask); > >> cfg->used_vectors = NULL; > >> @@ -418,6 +413,7 @@ next: > >> if (old_vector) { > >> cfg->move_in_progress = 1; > >> cpus_copy(cfg->old_cpu_mask, cfg->cpu_mask); > >> + cfg->old_vector = cfg->vector; > >> } > >> trace_irq_mask(TRC_HW_IRQ_ASSIGN_VECTOR, irq, vector, &tmp_mask); > >> for_each_cpu_mask(new_cpu, tmp_mask) > >> diff -r cf93a1825d66 -r 1a244d4ca6ac xen/include/asm-x86/irq.h > >> --- a/xen/include/asm-x86/irq.h Fri Sep 02 17:33:17 2011 +0100 > >> +++ b/xen/include/asm-x86/irq.h Fri Sep 02 17:33:17 2011 +0100 > >> @@ -28,7 +28,8 @@ typedef struct { > >> } vmask_t; > >> > >> struct irq_cfg { > >> - int vector; > >> + s16 vector; /* vector itself is only 8 bits, */ > >> + s16 old_vector; /* but we use -1 for unassigned */ > >> cpumask_t cpu_mask; > >> cpumask_t old_cpu_mask; > >> unsigned move_cleanup_count; > >> > >> _______________________________________________ > >> Xen-devel mailing list > >> Xen-devel@lists.xensource.com > >> http://lists.xensource.com/xen-devel > >> > _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel From xen-devel-bounces@lists.xensource.com Mon Sep 05 05:07:16 2011 Return-path: Envelope-to: www-data@lists.xensource.com Delivery-date: Mon, 05 Sep 2011 05:07:16 -0700 Received: from localhost ([127.0.0.1] helo=lists.colo.xensource.com) by lists.xensource.com with esmtp (Exim 4.43) id 1R0XxL-00068N-Pj; Mon, 05 Sep 2011 05:07:15 -0700 Received: from mail21.messagelabs.com ([85.158.143.35]) by lists.xensource.com with smtp (Exim 4.43) id 1R0Xvy-0005uu-17 for xen-devel@lists.xensource.com; Mon, 05 Sep 2011 05:05:51 -0700 X-Env-Sender: avi@redhat.com X-Msg-Ref: server-12.tower-21.messagelabs.com!1315224332!48740444!1 X-Originating-IP: [209.132.183.28] X-StarScan-Version: 6.3.6; banners=-,-,- X-VirusChecked: Checked Received: (qmail 12665 invoked from network); 5 Sep 2011 12:05:33 -0000 Received: from mx1.redhat.com (HELO mx1.redhat.com) (209.132.183.28) by server-12.tower-21.messagelabs.com with SMTP; 5 Sep 2011 12:05:33 -0000 Received: from int-mx10.intmail.prod.int.phx2.redhat.com (int-mx10.intmail.prod.int.phx2.redhat.com [10.5.11.23]) by mx1.redhat.com (8.14.4/8.14.4) with ESMTP id p85C58am005884 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Mon, 5 Sep 2011 08:05:08 -0400 Received: from balrog.usersys.redhat.com (dhcp-1-24.tlv.redhat.com [10.35.1.24]) by int-mx10.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP id p85C52O2011981; Mon, 5 Sep 2011 08:05:03 -0400 Message-ID: <4E64BAED.2040101@redhat.com> Date: Mon, 05 Sep 2011 15:05:01 +0300 From: Avi Kivity User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:6.0) Gecko/20110816 Thunderbird/6.0 MIME-Version: 1.0 To: Jeremy Fitzhardinge References: <38bb37e15f6e5056d5238adac945bc1837a996ec.1314922370.git.jeremy.fitzhardinge@citrix.com> <1314974826.1861.1.camel@twins> <4E612EA1.20007@goop.org> <1314996468.8255.0.camel@twins> <4E614FBD.2030509@goop.org> In-Reply-To: <4E614FBD.2030509@goop.org> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Scanned-By: MIMEDefang 2.68 on 10.5.11.23 Cc: Marcelo Tosatti , Nick Piggin , KVM , Stefano Stabellini , Peter Zijlstra , the arch/x86 maintainers , Linux Kernel Mailing List , Andi Kleen , Jeremy Fitzhardinge , "H. Peter Anvin" , Ingo Molnar , Linus Torvalds , Xen Devel Subject: [Xen-devel] Re: [PATCH 08/13] xen/pvticketlock: disable interrupts while blocking X-BeenThere: xen-devel@lists.xensource.com X-Mailman-Version: 2.1.5 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xensource.com Errors-To: xen-devel-bounces@lists.xensource.com On 09/03/2011 12:50 AM, Jeremy Fitzhardinge wrote: > On 09/02/2011 01:47 PM, Peter Zijlstra wrote: > > On Fri, 2011-09-02 at 12:29 -0700, Jeremy Fitzhardinge wrote: > >>> I know that its generally considered bad form, but there's at least one > >>> spinlock that's only taken from NMI context and thus hasn't got any > >>> deadlock potential. > >> Which one? > > arch/x86/kernel/traps.c:nmi_reason_lock > > > > It serializes NMI access to the NMI reason port across CPUs. > > Ah, OK. Well, that will never happen in a PV Xen guest. But PV > ticketlocks are equally applicable to an HVM Xen domain (and KVM guest), > so I guess there's at least some chance there could be a virtual > emulated NMI. Maybe? Does qemu do that kind of thing? kvm does. In fact, I want to use 'hlt' for blocking vcpus in the slowpath and an NMI IPI for waking them up. That's not going to work in an NMI, but I guess I can replace the 'hlt' with a 'pause' if we're in an NMI, and just spin there. btw, doing a race-free NMI wakeup is going to be interesting - we'll have to look at %rip and see if is just before our hlt, since there's no magic sti; hlt sequence we can use. -- error compiling committee.c: too many arguments to function _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel From xen-devel-bounces@lists.xensource.com Mon Sep 05 05:16:08 2011 Return-path: Envelope-to: www-data@lists.xensource.com Delivery-date: Mon, 05 Sep 2011 05:16:08 -0700 Received: from localhost ([127.0.0.1] helo=lists.colo.xensource.com) by lists.xensource.com with esmtp (Exim 4.43) id 1R0Y5w-0006bI-Kv; Mon, 05 Sep 2011 05:16:08 -0700 Received: from mail216.messagelabs.com ([85.158.143.99]) by lists.xensource.com with esmtp (Exim 4.43) id 1R0Y5B-0006OZ-IE for xen-devel@lists.xensource.com; Mon, 05 Sep 2011 05:15:21 -0700 X-Env-Sender: JBeulich@suse.com X-Msg-Ref: server-5.tower-216.messagelabs.com!1315224917!16640952!1 X-Originating-IP: [130.57.49.28] X-StarScan-Version: 6.3.6; banners=-,-,- X-VirusChecked: Checked Received: (qmail 22115 invoked from network); 5 Sep 2011 12:15:17 -0000 Received: from nat28.tlf.novell.com (HELO nat28.tlf.novell.com) (130.57.49.28) by server-5.tower-216.messagelabs.com with DHE-RSA-AES256-SHA encrypted SMTP; 5 Sep 2011 12:15:17 -0000 Received: from EMEA1-MTA by nat28.tlf.novell.com with Novell_GroupWise; Mon, 05 Sep 2011 13:15:17 +0100 Message-Id: <4E64D9720200007800054A8A@nat28.tlf.novell.com> X-Mailer: Novell GroupWise Internet Agent 8.0.1 Date: Mon, 05 Sep 2011 13:15:14 +0100 From: "Jan Beulich" To: Subject: Re: [Xen-devel] [PATCH] xen, vtd: Fix device check for devices behind PCIe-to-PCI bridges References: In-Reply-To: Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: quoted-printable Content-Disposition: inline Cc: xen-devel@lists.xensource.com X-BeenThere: xen-devel@lists.xensource.com X-Mailman-Version: 2.1.5 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xensource.com Errors-To: xen-devel-bounces@lists.xensource.com >>> On 01.09.11 at 16:20, George Dunlap = wrote: > On some systems, requests devices behind a PCIe-to-PCI bridge all > appear to the IOMMU as though they come from from slot 0, function > 0 on that device; so the mapping code much punch a hole for X:0.0 > in the IOMMU for such devices. When punching the hole, if that device > has already been mapped once, we simply need to check ownership to > make sure it's legal. To do so, domain_context_mapping_one() will look > up the device for the mapping with pci_get_pdev() and look for the = owner. >=20 > However, if there is no device in X:0.0, this look up will fail. Was it really that there was no device at all at X:0.0, or rather that Xen just didn't know about the device (because Dom0 failed to notify Xen, as could happen in the 2.6.18-derived trees up to pretty recently)? Also, didn't we sort of agree that creating a phantom device would be more elegant (or at least much smaller a change)? Jan > Rather than returning -ENODEV in this situation (causing a failure in > mapping the device), try to get the domain ownership from the iommu = context > mapping itself. >=20 > Signed-off-by: George Dunlap >=20 > diff -r 4a4882df5649 -r ede81b0552be xen/drivers/passthrough/vtd/iommu.c > --- a/xen/drivers/passthrough/vtd/iommu.c Wed Aug 31 15:23:49 2011 = +0100 > +++ b/xen/drivers/passthrough/vtd/iommu.c Thu Sep 01 15:18:18 2011 = +0100 > @@ -113,6 +113,27 @@ static int context_set_domain_id(struct=20 > return 0; > } > =20 > +static int context_get_domain_id(struct context_entry *context, > + struct iommu *iommu) > +{ > + unsigned long dom_index, nr_dom; > + int domid =3D -1; > + > + if (iommu && context) > + { > + nr_dom =3D cap_ndoms(iommu->cap); > + > + dom_index =3D context_domain_id(*context); > + > + if ( dom_index < nr_dom && iommu->domid_map) > + domid =3D iommu->domid_map[dom_index]; > + else > + dprintk(XENLOG_DEBUG VTDPREFIX, "%s: dom_index %lu = exceeds=20 > nr_dom %lu or iommu has no domid_map\n", > + __func__, dom_index, nr_dom); > + } > + return domid; > +} > + > static struct intel_iommu *__init alloc_intel_iommu(void) > { > struct intel_iommu *intel; > @@ -1237,7 +1258,6 @@ int domain_context_mapping_one( > struct hvm_iommu *hd =3D domain_hvm_iommu(domain); > struct context_entry *context, *context_entries; > u64 maddr, pgd_maddr; > - struct pci_dev *pdev =3D NULL; > int agaw; > =20 > ASSERT(spin_is_locked(&pcidevs_lock)); > @@ -1249,12 +1269,45 @@ int domain_context_mapping_one( > if ( context_present(*context) ) > { > int res =3D 0; > + struct pci_dev *pdev =3D NULL; > =20 > + /* First try to get domain ownership from device structure. = If=20 > that's > + * not available, try to read it from the context itself. */ > pdev =3D pci_get_pdev(bus, devfn); > - if (!pdev) > - res =3D -ENODEV; > - else if (pdev->domain !=3D domain) > - res =3D -EINVAL; > + if ( pdev ) > + { > + if ( pdev->domain !=3D domain ) > + { > + dprintk(XENLOG_INFO VTDPREFIX, "d%d: bdf =3D %x:%x.%x = owned=20 > by d%d!", > + domain->domain_id,=20 > + bus, PCI_SLOT(devfn), PCI_FUNC(devfn), > + (pdev->domain) > + ? pdev->domain->domain_id : -1); > + res =3D -EINVAL; > + } > + } > + else > + { > + int cdomain; > + cdomain =3D context_get_domain_id(context, iommu); > + =20 > + if ( cdomain < 0 ) > + { > + dprintk(VTDPREFIX, "d%d: bdf =3D %x:%x.%x mapped, but = can't=20 > find owner!\n", > + domain->domain_id,=20 > + bus, PCI_SLOT(devfn), PCI_FUNC(devfn)); > + res =3D -EINVAL; > + } > + else if ( cdomain !=3D domain->domain_id ) > + { > + dprintk(XENLOG_INFO VTDPREFIX, "d%d: bdf =3D %x:%x.%x = already=20 > mapped to d%d!", > + domain->domain_id,=20 > + bus, PCI_SLOT(devfn), PCI_FUNC(devfn), > + cdomain); > + res =3D -EINVAL; > + } > + } > + > unmap_vtd_domain_page(context_entries); > spin_unlock(&iommu->lock); > return res; >=20 > _______________________________________________ > Xen-devel mailing list > Xen-devel@lists.xensource.com=20 > http://lists.xensource.com/xen-devel=20 _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel From xen-devel-bounces@lists.xensource.com Mon Sep 05 05:25:17 2011 Return-path: Envelope-to: www-data@lists.xensource.com Delivery-date: Mon, 05 Sep 2011 05:25:17 -0700 Received: from localhost ([127.0.0.1] helo=lists.colo.xensource.com) by lists.xensource.com with esmtp (Exim 4.43) id 1R0YEm-0007AY-Ts; Mon, 05 Sep 2011 05:25:16 -0700 Received: from mail182.messagelabs.com ([85.158.139.83]) by lists.xensource.com with esmtp (Exim 4.43) id 1R0YE6-0006y0-2I for xen-devel@lists.xensource.com; Mon, 05 Sep 2011 05:24:34 -0700 X-Env-Sender: Andrew.Cooper3@citrix.com X-Msg-Ref: server-5.tower-182.messagelabs.com!1315225468!12110622!1 X-Originating-IP: [66.165.176.63] X-StarScan-Version: 6.3.6; banners=-,-,- X-VirusChecked: Checked Received: (qmail 795 invoked from network); 5 Sep 2011 12:24:30 -0000 Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63) by server-5.tower-182.messagelabs.com with RC4-SHA encrypted SMTP; 5 Sep 2011 12:24:30 -0000 X-IronPort-AV: E=Sophos;i="4.68,333,1312171200"; d="scan'208";a="161742825" Received: from ftlpmailmx02.citrite.net ([10.13.107.66]) by FTLPIPO02.CITRIX.COM with ESMTP/TLS/RC4-MD5; 05 Sep 2011 08:24:28 -0400 Received: from [10.80.2.18] (10.80.2.18) by FTLPMAILMX02.citrite.net (10.13.107.66) with Microsoft SMTP Server id 8.3.137.0; Mon, 5 Sep 2011 08:24:28 -0400 Message-ID: <4E64BF7B.5090901@citrix.com> Date: Mon, 5 Sep 2011 13:24:27 +0100 From: Andrew Cooper User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.2.20) Gecko/20110805 Lightning/1.0b2 Thunderbird/3.1.12 MIME-Version: 1.0 To: Jan Beulich Subject: Re: [Xen-devel] Re: [PATCH] IRQ: manually EOI migrating line interrupts References: <4E5CFF7C.90309@citrix.com> <4E64C5A20200007800054A59@nat28.tlf.novell.com> In-Reply-To: <4E64C5A20200007800054A59@nat28.tlf.novell.com> Content-Type: text/plain; charset="ISO-8859-1" Content-Transfer-Encoding: 7bit Cc: "xen-devel@lists.xensource.com" , Keir Fraser X-BeenThere: xen-devel@lists.xensource.com X-Mailman-Version: 2.1.5 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xensource.com Errors-To: xen-devel-bounces@lists.xensource.com On 05/09/11 11:50, Jan Beulich wrote: >>>> On 30.08.11 at 17:19, Andrew Cooper wrote: >> P.S. If anyone knows which manual contains the specificaion/programming >> guide for the IO-APIC, I would be very gratefull. Google always points >> to 82093AA datasheet which is very out of date. > Intel's ICH documentation (e.g. document number 319973-003) has a > section on the IO-APIC (among the other LPC stuff), which covers the > EOI register and possibly other newer additions. > > Jan Fantastic - Thanks -- Andrew Cooper - Dom0 Kernel Engineer, Citrix XenServer T: +44 (0)1223 225 900, http://www.citrix.com _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel From xen-devel-bounces@lists.xensource.com Mon Sep 05 05:27:18 2011 Return-path: Envelope-to: www-data@lists.xensource.com Delivery-date: Mon, 05 Sep 2011 05:27:18 -0700 Received: from localhost ([127.0.0.1] helo=lists.colo.xensource.com) by lists.xensource.com with esmtp (Exim 4.43) id 1R0YGk-0007Xy-OW; Mon, 05 Sep 2011 05:27:18 -0700 Received: from mail21.messagelabs.com ([85.158.143.35]) by lists.xensource.com with esmtp (Exim 4.43) id 1R0YGG-0007Lf-29 for Xen-devel@lists.xensource.com; Mon, 05 Sep 2011 05:26:48 -0700 X-Env-Sender: JBeulich@suse.com X-Msg-Ref: server-6.tower-21.messagelabs.com!1315225586!37039190!1 X-Originating-IP: [130.57.49.28] X-StarScan-Version: 6.3.6; banners=-,-,- X-VirusChecked: Checked Received: (qmail 927 invoked from network); 5 Sep 2011 12:26:26 -0000 Received: from nat28.tlf.novell.com (HELO nat28.tlf.novell.com) (130.57.49.28) by server-6.tower-21.messagelabs.com with DHE-RSA-AES256-SHA encrypted SMTP; 5 Sep 2011 12:26:26 -0000 Received: from EMEA1-MTA by nat28.tlf.novell.com with Novell_GroupWise; Mon, 05 Sep 2011 13:26:44 +0100 Message-Id: <4E64DC220200007800054A9D@nat28.tlf.novell.com> X-Mailer: Novell GroupWise Internet Agent 8.0.1 Date: Mon, 05 Sep 2011 13:26:42 +0100 From: "Jan Beulich" To: "Mukesh Rathor" References: <20110901122004.2c12f34f@mantra.us.oracle.com> In-Reply-To: <20110901122004.2c12f34f@mantra.us.oracle.com> Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: quoted-printable Content-Disposition: inline Cc: "Xen-devel@lists.xensource.com" Subject: [Xen-devel] Re: DOM0 Hang on a large box.... X-BeenThere: xen-devel@lists.xensource.com X-Mailman-Version: 2.1.5 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xensource.com Errors-To: xen-devel-bounces@lists.xensource.com >>> On 01.09.11 at 21:20, Mukesh Rathor wrote: > I'm looking at a system hang on a large box: 160 cpus, 2TB. Dom0 is > booted with 160 vcpus (don't ask me why :)), and an HVM guest is started > with over 1.5T RAM and 128 vcpus. The system hangs without much activity > after couple hours. Xen 4.0.2 and 2.6.32 based 64bit dom0. >=20 > During hang I discovered: >=20 > Most of dom0 vcpus are in double_lock_balance spinning on one of the = locks: >=20 > @ ffffffff800083aa: 0:hypercall_page+3aa pop %r11 = =20 > @ ffffffff802405eb: 0:xen_spin_wait+19b test %eax, %eax = =20 > @ ffffffff8035969b: 0:_spin_lock+10b test %al, %al = =20 > @ ffffffff800342f5: 0:double_lock_balance+65 mov %rbx, %rdi = =20 > @ ffffffff80356fc0: 0:thread_return+37e mov 0x880(%r12), %edi = =20 >=20 > static int _double_lock_balance(struct rq *this_rq, struct rq *busiest) > __releases(this_rq->lock) > __acquires(busiest->lock) > __acquires(this_rq->lock) > { > int ret =3D 0; >=20 > if (unlikely(!spin_trylock(&busiest->lock))) { > if (busiest < this_rq) { > spin_unlock(&this_rq->lock); > spin_lock(&busiest->lock); > spin_lock_nested(&this_rq->lock, SINGLE_DEPTH_NES= TING); > ret =3D 1; > } else > spin_lock_nested(&busiest->lock, SINGLE_DEPTH_NES= TING); > } > return ret; > } >=20 >=20 > The lock is taken, but not sure who the owner is. The lock struct: >=20 > @ ffff8800020e2480: 2f102e70 0000000c 00000002 00000000=20 >=20 > so slock is: 2f102e70 >=20 > The remaining vcpus are idling: >=20 > ffffffff800083aa: 0:hypercall_page+3aa pop %r11 = =20 > ffffffff8000f0c7: 0:xen_safe_halt+f7 addq $0x18, %rsp = =20 > ffffffff8000a5c5: 0:cpu_idle+65 jmp 0:cpu_idle+4e > ffffffff803558fe: 0:cpu_bringup_and_idle+e leave = =20 >=20 > But the baffling thing is the vcpu upcall mask is set. The block = schedop=20 > call=20 > does local_event_delivery_enable() first thing, so the mask should be=20 > clear!!! >=20 >=20 > Another baffling thing is the dom0 upcall mask looks fishy: > @ ffff83007f4dba00: 4924924924924929 2492492492492492 > @ ffff83007f4dba10: 9249249249249249 4924924924924924 > @ ffff83007f4dba20: 2492492492492492 9249249249249249 > @ ffff83007f4dba30: 4924924924924924 0000000092492492 > @ ffff83007f4dba40: 0000000000000000 0000000000000000 > @ ffff83007f4dba50: 0000000000000000 ffffffffc0000000 > @ ffff83007f4dba60: ffffffffffffffff ffffffffffffffff > @ ffff83007f4dba70: ffffffffffffffff ffffffffffffffff=20 >=20 >=20 > Finally, ticketing is used for spin locks. Hi Jan, what is the largest=20= > system this was tested on? Have you seen this before? >From the observation of most CPUs sitting in _double_lock_balance() I would have answered yes, but the odd upcall mask I don't recall having seen. In any case - is your Dom0 kernel (presumably derived from ours) up-to-date? That problem I recall was fixed months ago. Jan _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel From xen-devel-bounces@lists.xensource.com Mon Sep 05 05:30:37 2011 Return-path: Envelope-to: www-data@lists.xensource.com Delivery-date: Mon, 05 Sep 2011 05:30:37 -0700 Received: from localhost ([127.0.0.1] helo=lists.colo.xensource.com) by lists.xensource.com with esmtp (Exim 4.43) id 1R0YJx-0007wf-0W; Mon, 05 Sep 2011 05:30:37 -0700 Received: from mail27.messagelabs.com ([193.109.254.147]) by lists.xensource.com with esmtp (Exim 4.43) id 1R0YJR-0007ke-2L for xen-devel@lists.xensource.com; Mon, 05 Sep 2011 05:30:08 -0700 X-Env-Sender: Andrew.Cooper3@citrix.com X-Msg-Ref: server-9.tower-27.messagelabs.com!1315225786!43207104!1 X-Originating-IP: [66.165.176.89] X-StarScan-Version: 6.3.6; banners=-,-,- X-VirusChecked: Checked Received: (qmail 13555 invoked from network); 5 Sep 2011 12:29:47 -0000 Received: from smtp.citrix.com (HELO SMTP.CITRIX.COM) (66.165.176.89) by server-9.tower-27.messagelabs.com with RC4-SHA encrypted SMTP; 5 Sep 2011 12:29:47 -0000 X-IronPort-AV: E=Sophos;i="4.68,333,1312171200"; d="scan'208";a="16697604" Received: from ftlpmailmx02.citrite.net ([10.13.107.66]) by FTLPIPO01.CITRIX.COM with ESMTP/TLS/RC4-MD5; 05 Sep 2011 08:30:00 -0400 Received: from [10.80.2.18] (10.80.2.18) by FTLPMAILMX02.citrite.net (10.13.107.66) with Microsoft SMTP Server id 8.3.137.0; Mon, 5 Sep 2011 08:30:00 -0400 Message-ID: <4E64C0C7.3060804@citrix.com> Date: Mon, 5 Sep 2011 13:29:59 +0100 From: Andrew Cooper User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.2.20) Gecko/20110805 Lightning/1.0b2 Thunderbird/3.1.12 MIME-Version: 1.0 To: Jan Beulich Subject: Re: [Xen-devel] [PATCH] IRQ: manually EOI migrating line interrupts References: <4E64C3E10200007800054A4F@nat28.tlf.novell.com> In-Reply-To: <4E64C3E10200007800054A4F@nat28.tlf.novell.com> Content-Type: text/plain; charset="ISO-8859-1" Content-Transfer-Encoding: 7bit Cc: "xen-devel@lists.xensource.com" X-BeenThere: xen-devel@lists.xensource.com X-Mailman-Version: 2.1.5 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xensource.com Errors-To: xen-devel-bounces@lists.xensource.com On 05/09/11 11:43, Jan Beulich wrote: >>>> On 30.08.11 at 16:17, Andrew Cooper wrote: >> When migrating IO-APIC line level interrupts between PCPUs, the >> migration code rewrites the IO-APIC entry to point to the new >> CPU/Vector before EOI'ing it. >> >> The EOI process says that EOI'ing the Local APIC will cause a >> broadcast with the vector number, which the IO-APIC must listen to to >> clear the IRR and Status bits. >> >> In the case of migrating, the IO-APIC has already been >> reprogrammed so the EOI broadcast with the old vector fails to match >> the new vector, leaving the IO-APIC with an outstanding vector, >> preventing any more use of that line interrupt. This causes a lockup >> especially when your root device is using PCI INTA (megaraid_sas >> driver *ehem*) >> >> However, the problem is mostly hidden because send_cleanup_vector() >> causes a cleanup of all moving vectors on the current PCPU in such a >> way which does not cause the problem, and if the problem has occured, >> the writes it makes to the IO-APIC clears the IRR and Status bits >> which unlocks the problem. >> >> >> This fix is distinctly a temporary hack, waiting on a cleanup of the >> irq code. It checks for the edge case where we have moved the irq, >> and manually EOI's the old vector with the IO-APIC which correctly >> clears the IRR and Status bits. Also, it protects the code which >> updates irq_cfg by disabling interrupts. >> >> Signed-off-by: Andrew Cooper >> >> diff -r 227130622561 -r a95fd5d03c20 xen/arch/x86/hpet.c >> --- a/xen/arch/x86/hpet.c Thu Aug 25 12:03:14 2011 +0100 >> +++ b/xen/arch/x86/hpet.c Tue Aug 30 15:15:56 2011 +0100 >> @@ -301,7 +301,7 @@ static void hpet_msi_ack(unsigned int ir >> ack_APIC_irq(); >> } >> >> -static void hpet_msi_end(unsigned int irq) >> +static void hpet_msi_end(unsigned int irq, u8 vector) >> { >> } >> >> diff -r 227130622561 -r a95fd5d03c20 xen/arch/x86/i8259.c >> --- a/xen/arch/x86/i8259.c Thu Aug 25 12:03:14 2011 +0100 >> +++ b/xen/arch/x86/i8259.c Tue Aug 30 15:15:56 2011 +0100 >> @@ -93,7 +93,7 @@ static unsigned int startup_8259A_irq(un >> return 0; /* never anything pending */ >> } >> >> -static void end_8259A_irq(unsigned int irq) >> +static void end_8259A_irq(unsigned int irq, u8 vector) >> { >> if (!(irq_desc[irq].status & (IRQ_DISABLED|IRQ_INPROGRESS))) >> enable_8259A_irq(irq); >> diff -r 227130622561 -r a95fd5d03c20 xen/arch/x86/io_apic.c >> --- a/xen/arch/x86/io_apic.c Thu Aug 25 12:03:14 2011 +0100 >> +++ b/xen/arch/x86/io_apic.c Tue Aug 30 15:15:56 2011 +0100 >> @@ -1690,7 +1690,7 @@ static void mask_and_ack_level_ioapic_ir >> } >> } >> >> -static void end_level_ioapic_irq (unsigned int irq) >> +static void end_level_ioapic_irq (unsigned int irq, u8 vector) >> { >> unsigned long v; >> int i; >> @@ -1739,6 +1739,14 @@ static void end_level_ioapic_irq (unsign >> */ >> i = IO_APIC_VECTOR(irq); >> >> + /* Manually EOI the old vector if we are moving to the new */ >> + if ( vector && i != vector ) >> + { >> + int ioapic; >> + for (ioapic = 0; ioapic < nr_ioapics; ioapic++) >> + io_apic_eoi(ioapic, i); > While I realize that the patch already went in, this still will need > adjustment for dealing with old IO-APICs that don't have an EOI > register (or if we want to stop supporting such, a clear panic() > rather than subtle and hard to debug failure). > > Jan > This is a good point. However, due to the use of io_apic_eoi elsewhere in the code, I don't think this is the only area susceptible to this issue. I will add it to my todo list for the irq cleanup. ~Andrew >> + } >> + >> v = apic_read(APIC_TMR + ((i & ~0x1f) >> 1)); >> >> ack_APIC_irq(); >> @@ -1762,7 +1770,10 @@ static void disable_edge_ioapic_irq(unsi >> { >> } >> >> -#define end_edge_ioapic_irq disable_edge_ioapic_irq >> +static void end_edge_ioapic_irq(unsigned int irq, u8 vector) >> +{ >> +} >> + >> >> /* >> * Level and edge triggered IO-APIC interrupts need different handling, >> @@ -1811,7 +1822,7 @@ static void ack_msi_irq(unsigned int irq >> ack_APIC_irq(); /* ACKTYPE_NONE */ >> } >> >> -static void end_msi_irq(unsigned int irq) >> +static void end_msi_irq(unsigned int irq, u8 vector) >> { >> if ( !msi_maskable_irq(irq_desc[irq].msi_desc) ) >> ack_APIC_irq(); /* ACKTYPE_EOI */ >> diff -r 227130622561 -r a95fd5d03c20 xen/arch/x86/irq.c >> --- a/xen/arch/x86/irq.c Thu Aug 25 12:03:14 2011 +0100 >> +++ b/xen/arch/x86/irq.c Tue Aug 30 15:15:56 2011 +0100 >> @@ -345,6 +345,7 @@ static void __do_IRQ_guest(int vector); >> void no_action(int cpl, void *dev_id, struct cpu_user_regs *regs) { } >> >> static void enable_none(unsigned int vector) { } >> +static void end_none(unsigned int irq, u8 vector) { } >> static unsigned int startup_none(unsigned int vector) { return 0; } >> static void disable_none(unsigned int vector) { } >> static void ack_none(unsigned int irq) >> @@ -353,7 +354,6 @@ static void ack_none(unsigned int irq) >> } >> >> #define shutdown_none disable_none >> -#define end_none enable_none >> >> hw_irq_controller no_irq_type = { >> "none", >> @@ -381,6 +381,7 @@ int __assign_irq_vector(int irq, struct >> static int current_vector = FIRST_DYNAMIC_VECTOR, current_offset = 0; >> unsigned int old_vector; >> int cpu, err; >> + unsigned long flags; >> cpumask_t tmp_mask; >> >> old_vector = irq_to_vector(irq); >> @@ -431,6 +432,7 @@ next: >> /* Found one! */ >> current_vector = vector; >> current_offset = offset; >> + local_irq_save(flags); >> if (old_vector) { >> cfg->move_in_progress = 1; >> cpus_copy(cfg->old_cpu_mask, cfg->cpu_mask); >> @@ -450,6 +452,7 @@ next: >> if (IO_APIC_IRQ(irq)) >> irq_vector[irq] = vector; >> err = 0; >> + local_irq_restore(flags); >> break; >> } >> return err; >> @@ -657,7 +660,7 @@ asmlinkage void do_IRQ(struct cpu_user_r >> desc->status &= ~IRQ_INPROGRESS; >> >> out: >> - desc->handler->end(irq); >> + desc->handler->end(irq, regs->entry_vector); >> out_no_end: >> spin_unlock(&desc->lock); >> irq_exit(); >> @@ -857,7 +860,7 @@ static void irq_guest_eoi_timer_fn(void >> switch ( action->ack_type ) >> { >> case ACKTYPE_UNMASK: >> - desc->handler->end(irq); >> + desc->handler->end(irq, 0); >> break; >> case ACKTYPE_EOI: >> cpu_eoi_map = action->cpu_eoi_map; >> @@ -885,7 +888,7 @@ static void __do_IRQ_guest(int irq) >> /* An interrupt may slip through while freeing an ACKTYPE_EOI irq. >> */ >> ASSERT(action->ack_type == ACKTYPE_EOI); >> ASSERT(desc->status & IRQ_DISABLED); >> - desc->handler->end(irq); >> + desc->handler->end(irq, vector); >> return; >> } >> >> @@ -1099,7 +1102,7 @@ static void flush_ready_eoi(void) >> ASSERT(irq > 0); >> desc = irq_to_desc(irq); >> spin_lock(&desc->lock); >> - desc->handler->end(irq); >> + desc->handler->end(irq, peoi[sp].vector); >> spin_unlock(&desc->lock); >> } >> >> @@ -1177,7 +1180,7 @@ void desc_guest_eoi(struct irq_desc *des >> if ( action->ack_type == ACKTYPE_UNMASK ) >> { >> ASSERT(cpus_empty(action->cpu_eoi_map)); >> - desc->handler->end(irq); >> + desc->handler->end(irq, 0); >> spin_unlock_irq(&desc->lock); >> return; >> } >> @@ -1431,7 +1434,7 @@ static irq_guest_action_t *__pirq_guest_ >> case ACKTYPE_UNMASK: >> if ( test_and_clear_bool(pirq->masked) && >> (--action->in_flight == 0) ) >> - desc->handler->end(irq); >> + desc->handler->end(irq, 0); >> break; >> case ACKTYPE_EOI: >> /* NB. If #guests == 0 then we clear the eoi_map later on. */ >> diff -r 227130622561 -r a95fd5d03c20 xen/drivers/passthrough/amd/iommu_init.c >> --- a/xen/drivers/passthrough/amd/iommu_init.c Thu Aug 25 12:03:14 2011 +0100 >> +++ b/xen/drivers/passthrough/amd/iommu_init.c Tue Aug 30 15:15:56 2011 +0100 >> @@ -441,7 +441,7 @@ static unsigned int iommu_msi_startup(un >> return 0; >> } >> >> -static void iommu_msi_end(unsigned int irq) >> +static void iommu_msi_end(unsigned int irq, u8 vector) >> { >> iommu_msi_unmask(irq); >> ack_APIC_irq(); >> diff -r 227130622561 -r a95fd5d03c20 xen/drivers/passthrough/vtd/iommu.c >> --- a/xen/drivers/passthrough/vtd/iommu.c Thu Aug 25 12:03:14 2011 +0100 >> +++ b/xen/drivers/passthrough/vtd/iommu.c Tue Aug 30 15:15:56 2011 +0100 >> @@ -971,7 +971,7 @@ static unsigned int dma_msi_startup(unsi >> return 0; >> } >> >> -static void dma_msi_end(unsigned int irq) >> +static void dma_msi_end(unsigned int irq, u8 vector) >> { >> dma_msi_unmask(irq); >> ack_APIC_irq(); >> diff -r 227130622561 -r a95fd5d03c20 xen/include/xen/irq.h >> --- a/xen/include/xen/irq.h Thu Aug 25 12:03:14 2011 +0100 >> +++ b/xen/include/xen/irq.h Tue Aug 30 15:15:56 2011 +0100 >> @@ -44,7 +44,7 @@ struct hw_interrupt_type { >> void (*enable)(unsigned int irq); >> void (*disable)(unsigned int irq); >> void (*ack)(unsigned int irq); >> - void (*end)(unsigned int irq); >> + void (*end)(unsigned int irq, u8 vector); >> void (*set_affinity)(unsigned int irq, cpumask_t mask); >> }; >> >> >> _______________________________________________ >> Xen-devel mailing list >> Xen-devel@lists.xensource.com >> http://lists.xensource.com/xen-devel > -- Andrew Cooper - Dom0 Kernel Engineer, Citrix XenServer T: +44 (0)1223 225 900, http://www.citrix.com _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel From xen-devel-bounces@lists.xensource.com Mon Sep 05 05:51:36 2011 Return-path: Envelope-to: www-data@lists.xensource.com Delivery-date: Mon, 05 Sep 2011 05:51:36 -0700 Received: from localhost ([127.0.0.1] helo=lists.colo.xensource.com) by lists.xensource.com with esmtp (Exim 4.43) id 1R0YeG-0000GT-0H; Mon, 05 Sep 2011 05:51:36 -0700 Received: from mail21.messagelabs.com ([85.158.143.35]) by lists.xensource.com with esmtp (Exim 4.43) id 1R0YdU-0008V7-Ap for xen-devel@lists.xensource.com; Mon, 05 Sep 2011 05:50:48 -0700 X-Env-Sender: JBeulich@suse.com X-Msg-Ref: server-12.tower-21.messagelabs.com!1315227031!48747108!1 X-Originating-IP: [130.57.49.28] X-StarScan-Version: 6.3.6; banners=-,-,- X-VirusChecked: Checked Received: (qmail 19782 invoked from network); 5 Sep 2011 12:50:31 -0000 Received: from nat28.tlf.novell.com (HELO nat28.tlf.novell.com) (130.57.49.28) by server-12.tower-21.messagelabs.com with DHE-RSA-AES256-SHA encrypted SMTP; 5 Sep 2011 12:50:31 -0000 Received: from EMEA1-MTA by nat28.tlf.novell.com with Novell_GroupWise; Mon, 05 Sep 2011 13:50:45 +0100 Message-Id: <4E64E1C30200007800054AC8@nat28.tlf.novell.com> X-Mailer: Novell GroupWise Internet Agent 8.0.1 Date: Mon, 05 Sep 2011 13:50:43 +0100 From: "Jan Beulich" To: "Andrew Cooper" Subject: Re: [Xen-devel] [PATCH] IRQ: manually EOI migrating line interrupts References: <4E64C3E10200007800054A4F@nat28.tlf.novell.com> <4E64C0C7.3060804@citrix.com> In-Reply-To: <4E64C0C7.3060804@citrix.com> Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: quoted-printable Content-Disposition: inline Cc: "xen-devel@lists.xensource.com" X-BeenThere: xen-devel@lists.xensource.com X-Mailman-Version: 2.1.5 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xensource.com Errors-To: xen-devel-bounces@lists.xensource.com >>> On 05.09.11 at 14:29, Andrew Cooper wrote: >=20 > On 05/09/11 11:43, Jan Beulich wrote: >>>>> On 30.08.11 at 16:17, Andrew Cooper = wrote: >>> When migrating IO-APIC line level interrupts between PCPUs, the >>> migration code rewrites the IO-APIC entry to point to the new >>> CPU/Vector before EOI'ing it. >>> >>> The EOI process says that EOI'ing the Local APIC will cause a >>> broadcast with the vector number, which the IO-APIC must listen to to >>> clear the IRR and Status bits. >>> >>> In the case of migrating, the IO-APIC has already been >>> reprogrammed so the EOI broadcast with the old vector fails to match >>> the new vector, leaving the IO-APIC with an outstanding vector, >>> preventing any more use of that line interrupt. This causes a lockup >>> especially when your root device is using PCI INTA (megaraid_sas >>> driver *ehem*) >>> >>> However, the problem is mostly hidden because send_cleanup_vector() >>> causes a cleanup of all moving vectors on the current PCPU in such a >>> way which does not cause the problem, and if the problem has occured, >>> the writes it makes to the IO-APIC clears the IRR and Status bits >>> which unlocks the problem. >>> >>> >>> This fix is distinctly a temporary hack, waiting on a cleanup of the >>> irq code. It checks for the edge case where we have moved the irq, >>> and manually EOI's the old vector with the IO-APIC which correctly >>> clears the IRR and Status bits. Also, it protects the code which >>> updates irq_cfg by disabling interrupts. >>> >>> Signed-off-by: Andrew Cooper >>> >>> diff -r 227130622561 -r a95fd5d03c20 xen/arch/x86/hpet.c >>> --- a/xen/arch/x86/hpet.c Thu Aug 25 12:03:14 2011 +0100 >>> +++ b/xen/arch/x86/hpet.c Tue Aug 30 15:15:56 2011 +0100 >>> @@ -301,7 +301,7 @@ static void hpet_msi_ack(unsigned int ir >>> ack_APIC_irq(); >>> } >>> =20 >>> -static void hpet_msi_end(unsigned int irq) >>> +static void hpet_msi_end(unsigned int irq, u8 vector) >>> { >>> } >>> =20 >>> diff -r 227130622561 -r a95fd5d03c20 xen/arch/x86/i8259.c >>> --- a/xen/arch/x86/i8259.c Thu Aug 25 12:03:14 2011 +0100 >>> +++ b/xen/arch/x86/i8259.c Tue Aug 30 15:15:56 2011 +0100 >>> @@ -93,7 +93,7 @@ static unsigned int startup_8259A_irq(un >>> return 0; /* never anything pending */ >>> } >>> =20 >>> -static void end_8259A_irq(unsigned int irq) >>> +static void end_8259A_irq(unsigned int irq, u8 vector) >>> { >>> if (!(irq_desc[irq].status & (IRQ_DISABLED|IRQ_INPROGRESS))) >>> enable_8259A_irq(irq); >>> diff -r 227130622561 -r a95fd5d03c20 xen/arch/x86/io_apic.c >>> --- a/xen/arch/x86/io_apic.c Thu Aug 25 12:03:14 2011 +0100 >>> +++ b/xen/arch/x86/io_apic.c Tue Aug 30 15:15:56 2011 +0100 >>> @@ -1690,7 +1690,7 @@ static void mask_and_ack_level_ioapic_ir >>> } >>> } >>> =20 >>> -static void end_level_ioapic_irq (unsigned int irq) >>> +static void end_level_ioapic_irq (unsigned int irq, u8 vector) >>> { >>> unsigned long v; >>> int i; >>> @@ -1739,6 +1739,14 @@ static void end_level_ioapic_irq (unsign >>> */ >>> i =3D IO_APIC_VECTOR(irq); >>> =20 >>> + /* Manually EOI the old vector if we are moving to the new */ >>> + if ( vector && i !=3D vector ) >>> + { >>> + int ioapic; >>> + for (ioapic =3D 0; ioapic < nr_ioapics; ioapic++) >>> + io_apic_eoi(ioapic, i); >> While I realize that the patch already went in, this still will need >> adjustment for dealing with old IO-APICs that don't have an EOI >> register (or if we want to stop supporting such, a clear panic() >> rather than subtle and hard to debug failure). >> >> Jan >> >=20 > This is a good point. However, due to the use of io_apic_eoi elsewhere > in the code, I don't think this is the only area susceptible to this = issue. The only other two uses that I could spot are in directed-EOI specific code (where a new enough IO-APIC can be implied) and in the code recently added to clear remoteIRR bits (protected by a version check). Jan _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel From xen-devel-bounces@lists.xensource.com Mon Sep 05 06:17:27 2011 Return-path: Envelope-to: www-data@lists.xensource.com Delivery-date: Mon, 05 Sep 2011 06:17:27 -0700 Received: from localhost ([127.0.0.1] helo=lists.colo.xensource.com) by lists.xensource.com with esmtp (Exim 4.43) id 1R0Z3G-00010t-O8; Mon, 05 Sep 2011 06:17:27 -0700 Received: from mail174.messagelabs.com ([85.158.138.51]) by lists.xensource.com with esmtp (Exim 4.43) id 1R0Z2H-0000o9-4c for xen-devel@lists.xensource.com; Mon, 05 Sep 2011 06:16:26 -0700 X-Env-Sender: JBeulich@suse.com X-Msg-Ref: server-10.tower-174.messagelabs.com!1315228576!30287135!1 X-Originating-IP: [130.57.49.28] X-StarScan-Version: 6.3.6; banners=-,-,- X-VirusChecked: Checked Received: (qmail 20947 invoked from network); 5 Sep 2011 13:16:18 -0000 Received: from nat28.tlf.novell.com (HELO nat28.tlf.novell.com) (130.57.49.28) by server-10.tower-174.messagelabs.com with DHE-RSA-AES256-SHA encrypted SMTP; 5 Sep 2011 13:16:18 -0000 Received: from EMEA1-MTA by nat28.tlf.novell.com with Novell_GroupWise; Mon, 05 Sep 2011 14:16:15 +0100 Message-Id: <4E64E7BE0200007800054AD6@nat28.tlf.novell.com> X-Mailer: Novell GroupWise Internet Agent 8.0.1 Date: Mon, 05 Sep 2011 14:16:14 +0100 From: "Jan Beulich" To: "Wei Wang2" Subject: Re: [Xen-devel] [PATCH,RFC 5/7] PCI multi-seg: AMD-IOMMU specificadjustments References: <4E567F2A0200007800053475@nat28.tlf.novell.com> <201108261357.57885.wei.wang2@amd.com> In-Reply-To: <201108261357.57885.wei.wang2@amd.com> Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: quoted-printable Content-Disposition: inline Cc: xen-devel@lists.xensource.com X-BeenThere: xen-devel@lists.xensource.com X-Mailman-Version: 2.1.5 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xensource.com Errors-To: xen-devel-bounces@lists.xensource.com >>> On 26.08.11 at 13:57, Wei Wang2 wrote: > Read PCI segment from IVHD block is fine. The value should be the same = as in=20 > IVHDR if they both show up in BIOS. IVHDR also has PCI segment number, = but=20 > IVHDR is only used by IVRS revision 2. Actually, IVRS rev 2 allows = device=20 > IDs=20 > to be chosen freely by OS instead of by firmware. Rev 2 might co-exist = with=20 > rev 1 in BIOS but if SW like Xen or Linux uses device IDs supplied by = BIOS,=20 > it should just ignore rev 2 tables. I don't really follow: The two cases where I can't spot where to get the segment number from are register_exclusion_range_for_all_devices() and register_exclusion_range_for_device(), both called in the context of struct acpi_ivmd_block_header(), which only gets a struct acpi_ivmd_block_header (not having a segment number afaict). Jan > On Thursday 25 August 2011 16:58:18 Jan Beulich wrote: >> There are two places here where it is entirely unclear to me where the >> necessary PCI segment number should be taken from (as IVMD descriptors >> don't have such, only IVHD ones do). >> >> Signed-off-by: Jan Beulich >> >> --- 2011-08-25.orig/xen/drivers/passthrough/amd/iommu_acpi.c = 2011-06-28 >> 09:41:39.000000000 +0200 +++ >> 2011-08-25/xen/drivers/passthrough/amd/iommu_acpi.c 2011-08-25 >> 15:06:47.000000000 +0200 @@ -30,6 +30,7 @@ static unsigned short = __initdata >> last_bd >> static void __init add_ivrs_mapping_entry( >> u16 bdf, u16 alias_id, u8 flags, struct amd_iommu *iommu) >> { >> + struct ivrs_mappings *ivrs_mappings =3D get_ivrs_mappings(iommu->se= g); >> u8 sys_mgt, lint1_pass, lint0_pass, nmi_pass, ext_int_pass, = init_pass; >> ASSERT( ivrs_mappings !=3D NULL ); >> >> @@ -118,9 +119,10 @@ static void __init reserve_iommu_exclusi >> } >> >> static void __init reserve_unity_map_for_device( >> - u16 bdf, unsigned long base, >> + u16 seg, u16 bdf, unsigned long base, >> unsigned long length, u8 iw, u8 ir) >> { >> + struct ivrs_mappings *ivrs_mappings =3D get_ivrs_mappings(seg); >> unsigned long old_top, new_top; >> >> /* need to extend unity-mapped range? */ >> @@ -147,6 +149,7 @@ static void __init reserve_unity_map_for >> static int __init register_exclusion_range_for_all_devices( >> unsigned long base, unsigned long limit, u8 iw, u8 ir) >> { >> + int seg =3D 0; /* XXX */ >> unsigned long range_top, iommu_top, length; >> struct amd_iommu *iommu; >> u16 bdf; >> @@ -163,7 +166,7 @@ static int __init register_exclusion_ran >> /* reserve r/w unity-mapped page entries for devices */ >> /* note: these entries are part of the exclusion range */ >> for ( bdf =3D 0; bdf < ivrs_bdf_entries; bdf++ ) >> - reserve_unity_map_for_device(bdf, base, length, iw, ir); >> + reserve_unity_map_for_device(seg, bdf, base, length, iw, = ir); >> /* push 'base' just outside of virtual address space */ >> base =3D iommu_top; >> } >> @@ -180,11 +183,13 @@ static int __init register_exclusion_ran >> static int __init register_exclusion_range_for_device( >> u16 bdf, unsigned long base, unsigned long limit, u8 iw, u8 ir) >> { >> + int seg =3D 0; /* XXX */ >> + struct ivrs_mappings *ivrs_mappings =3D get_ivrs_mappings(seg); >> unsigned long range_top, iommu_top, length; >> struct amd_iommu *iommu; >> u16 req; >> >> - iommu =3D find_iommu_for_device(bdf); >> + iommu =3D find_iommu_for_device(seg, bdf); >> if ( !iommu ) >> { >> AMD_IOMMU_DEBUG("IVMD Error: No IOMMU for Dev_Id 0x%x!\n", = bdf); >> @@ -202,8 +207,8 @@ static int __init register_exclusion_ran >> length =3D range_top - base; >> /* reserve unity-mapped page entries for device */ >> /* note: these entries are part of the exclusion range */ >> - reserve_unity_map_for_device(bdf, base, length, iw, ir); >> - reserve_unity_map_for_device(req, base, length, iw, ir); >> + reserve_unity_map_for_device(seg, bdf, base, length, iw, ir); >> + reserve_unity_map_for_device(seg, req, base, length, iw, ir); >> >> /* push 'base' just outside of virtual address space */ >> base =3D iommu_top; >> @@ -240,11 +245,13 @@ static int __init register_exclusion_ran >> /* note: these entries are part of the exclusion range */ >> for ( bdf =3D 0; bdf < ivrs_bdf_entries; bdf++ ) >> { >> - if ( iommu =3D=3D find_iommu_for_device(bdf) ) >> + if ( iommu =3D=3D find_iommu_for_device(iommu->seg, bdf) ) >> { >> - reserve_unity_map_for_device(bdf, base, length, iw, = ir); >> - req =3D ivrs_mappings[bdf].dte_requestor_id; >> - reserve_unity_map_for_device(req, base, length, iw, = ir); >> + reserve_unity_map_for_device(iommu->seg, bdf, base, >> length, + iw, ir); >> + req =3D get_ivrs_mappings(iommu->seg)[bdf].dte_requesto= r_id; >> + reserve_unity_map_for_device(iommu->seg, req, base, >> length, + iw, ir); >> } >> } >> >> @@ -627,7 +634,7 @@ static u16 __init parse_ivhd_device_exte >> } >> >> static u16 __init parse_ivhd_device_special( >> - union acpi_ivhd_device *ivhd_device, >> + union acpi_ivhd_device *ivhd_device, u16 seg, >> u16 header_length, u16 block_length, struct amd_iommu *iommu) >> { >> u16 dev_length, bdf; >> @@ -648,6 +655,7 @@ static u16 __init parse_ivhd_device_spec >> >> add_ivrs_mapping_entry(bdf, bdf, ivhd_device->header.flags, = iommu); >> /* set device id of ioapic */ >> + ioapic_seg[ivhd_device->special.handle] =3D seg; >> ioapic_bdf[ivhd_device->special.handle] =3D bdf; >> return dev_length; >> } >> @@ -729,7 +737,7 @@ static int __init parse_ivhd_block(struc >> break; >> case AMD_IOMMU_ACPI_IVHD_DEV_SPECIAL: >> dev_length =3D parse_ivhd_device_special( >> - ivhd_device, >> + ivhd_device, ivhd_block->pci_segment, >> ivhd_block->header.length, block_length, iommu); >> break; >> default: >> --- 2011-08-25.orig/xen/drivers/passthrough/amd/iommu_detect.c = 2011-04-04 >> 09:11:24.000000000 +0200 +++ >> 2011-08-25/xen/drivers/passthrough/amd/iommu_detect.c 2011-08-25 >> 15:06:47.000000000 +0200 @@ -27,8 +27,8 @@ >> #include >> #include >> >> -static int __init get_iommu_msi_capabilities(u8 bus, u8 dev, u8 func, >> - struct amd_iommu *iommu) >> +static int __init get_iommu_msi_capabilities( >> + u16 seg, u8 bus, u8 dev, u8 func, struct amd_iommu *iommu) >> { >> int cap_ptr, cap_id; >> u32 cap_header; >> @@ -66,8 +66,8 @@ static int __init get_iommu_msi_capabili >> return 0; >> } >> >> -static int __init get_iommu_capabilities(u8 bus, u8 dev, u8 func, u8 >> cap_ptr, - struct amd_iommu *iommu) >> +static int __init get_iommu_capabilities( >> + u16 seg, u8 bus, u8 dev, u8 func, u8 cap_ptr, struct amd_iommu = *iommu) >> { >> u32 cap_header, cap_range, misc_info; >> >> @@ -121,6 +121,11 @@ int __init amd_iommu_detect_one_acpi(voi >> >> spin_lock_init(&iommu->lock); >> >> + iommu->seg =3D ivhd_block->pci_segment; >> + if (alloc_ivrs_mappings(ivhd_block->pci_segment)) { >> + xfree(iommu); >> + return -ENOMEM; >> + } >> iommu->bdf =3D ivhd_block->header.dev_id; >> iommu->cap_offset =3D ivhd_block->cap_offset; >> iommu->mmio_base_phys =3D ivhd_block->mmio_base; >> @@ -147,8 +152,9 @@ int __init amd_iommu_detect_one_acpi(voi >> bus =3D iommu->bdf >> 8; >> dev =3D PCI_SLOT(iommu->bdf & 0xFF); >> func =3D PCI_FUNC(iommu->bdf & 0xFF); >> - get_iommu_capabilities(bus, dev, func, iommu->cap_offset, iommu); >> - get_iommu_msi_capabilities(bus, dev, func, iommu); >> + get_iommu_capabilities(iommu->seg, bus, dev, func, >> + iommu->cap_offset, iommu); >> + get_iommu_msi_capabilities(iommu->seg, bus, dev, func, iommu); >> >> list_add_tail(&iommu->list, &amd_iommu_head); >> >> --- 2011-08-25.orig/xen/drivers/passthrough/amd/iommu_init.c = 2011-08-19 >> 17:08:35.000000000 +0200 +++ >> 2011-08-25/xen/drivers/passthrough/amd/iommu_init.c 2011-08-25 >> 15:06:47.000000000 +0200 @@ -33,7 +33,7 @@ static struct amd_iommu >> **__read_mostly >> static int __initdata nr_amd_iommus; >> >> unsigned short ivrs_bdf_entries; >> -struct ivrs_mappings *ivrs_mappings; >> +static struct radix_tree_root ivrs_maps; >> struct list_head amd_iommu_head; >> struct table_struct device_table; >> >> @@ -697,7 +697,6 @@ error_out: >> static void __init amd_iommu_init_cleanup(void) >> { >> struct amd_iommu *iommu, *next; >> - int bdf; >> >> /* free amd iommu list */ >> list_for_each_entry_safe ( iommu, next, &amd_iommu_head, list ) >> @@ -713,21 +712,13 @@ static void __init amd_iommu_init_cleanu >> } >> >> /* free interrupt remapping table */ >> - for ( bdf =3D 0; bdf < ivrs_bdf_entries; bdf++ ) >> - { >> - if ( ivrs_mappings[bdf].intremap_table ) >> - amd_iommu_free_intremap_table(bdf); >> - } >> + iterate_ivrs_entries(amd_iommu_free_intremap_table); >> >> /* free device table */ >> deallocate_iommu_table_struct(&device_table); >> >> /* free ivrs_mappings[] */ >> - if ( ivrs_mappings ) >> - { >> - xfree(ivrs_mappings); >> - ivrs_mappings =3D NULL; >> - } >> + radix_tree_destroy(&ivrs_maps, xfree); >> >> /* free irq_to_iommu[] */ >> if ( irq_to_iommu ) >> @@ -741,19 +732,71 @@ static void __init amd_iommu_init_cleanu >> iommu_intremap =3D 0; >> } >> >> -static int __init init_ivrs_mapping(void) >> +/* >> + * We allocate an extra array element to store the segment number >> + * (and in the future perhaps other global information). >> + */ >> +#define IVRS_MAPPINGS_SEG(m) m[ivrs_bdf_entries].dte_requestor_id >> + >> +struct ivrs_mappings *get_ivrs_mappings(u16 seg) >> +{ >> + return radix_tree_lookup(&ivrs_maps, seg); >> +} >> + >> +int iterate_ivrs_mappings(int (*handler)(u16 seg, struct ivrs_mappings = *)) >> { >> + u16 seg =3D 0; >> + int rc =3D 0; >> + >> + do { >> + struct ivrs_mappings *map; >> + >> + if ( !radix_tree_gang_lookup(&ivrs_maps, (void **)&map, seg, = 1) ) >> + break; >> + seg =3D IVRS_MAPPINGS_SEG(map); >> + rc =3D handler(seg, map); >> + } while ( !rc && ++seg ); >> + >> + return rc; >> +} >> + >> +int iterate_ivrs_entries(int (*handler)(u16 seg, struct ivrs_mappings = *)) >> +{ >> + u16 seg =3D 0; >> + int rc =3D 0; >> + >> + do { >> + struct ivrs_mappings *map; >> + int bdf; >> + >> + if ( !radix_tree_gang_lookup(&ivrs_maps, (void **)&map, seg, = 1) ) >> + break; >> + seg =3D IVRS_MAPPINGS_SEG(map); >> + for ( bdf =3D 0; !rc && bdf < ivrs_bdf_entries; ++bdf ) >> + rc =3D handler(seg, map + bdf); >> + } while ( !rc && ++seg ); >> + >> + return rc; >> +} >> + >> +int __init alloc_ivrs_mappings(u16 seg) >> +{ >> + struct ivrs_mappings *ivrs_mappings; >> int bdf; >> >> BUG_ON( !ivrs_bdf_entries ); >> >> - ivrs_mappings =3D xmalloc_array( struct ivrs_mappings, >> ivrs_bdf_entries); + if ( get_ivrs_mappings(seg) ) >> + return 0; >> + >> + ivrs_mappings =3D xmalloc_array(struct ivrs_mappings, ivrs_bdf_entr= ies + >> 1); if ( ivrs_mappings =3D=3D NULL ) >> { >> AMD_IOMMU_DEBUG("Error allocating IVRS Mappings table\n"); >> return -ENOMEM; >> } >> memset(ivrs_mappings, 0, ivrs_bdf_entries * sizeof(struct >> ivrs_mappings)); + IVRS_MAPPINGS_SEG(ivrs_mappings) =3D seg; >> >> /* assign default values for device entries */ >> for ( bdf =3D 0; bdf < ivrs_bdf_entries; bdf++ ) >> @@ -775,10 +818,14 @@ static int __init init_ivrs_mapping(void >> if ( amd_iommu_perdev_intremap ) >> spin_lock_init(&ivrs_mappings[bdf].intremap_lock); >> } >> + >> + radix_tree_insert(&ivrs_maps, seg, ivrs_mappings); >> + >> return 0; >> } >> >> -static int __init amd_iommu_setup_device_table(void) >> +static int __init amd_iommu_setup_device_table( >> + u16 seg, struct ivrs_mappings *ivrs_mappings) >> { >> int bdf; >> void *intr_tb, *dte; >> @@ -849,7 +896,8 @@ int __init amd_iommu_init(void) >> if ( !ivrs_bdf_entries ) >> goto error_out; >> >> - if ( init_ivrs_mapping() !=3D 0 ) >> + radix_tree_init(&ivrs_maps); >> + if ( alloc_ivrs_mappings(0) !=3D 0 ) >> goto error_out; >> >> if ( amd_iommu_update_ivrs_mapping_acpi() !=3D 0 ) >> @@ -860,7 +908,7 @@ int __init amd_iommu_init(void) >> goto error_out; >> >> /* allocate and initialize a global device table shared by all = iommus >> */ - if ( amd_iommu_setup_device_table() !=3D 0 ) >> + if ( iterate_ivrs_mappings(amd_iommu_setup_device_table) !=3D 0 ) >> goto error_out; >> >> /* per iommu initialization */ >> @@ -905,7 +953,8 @@ static void invalidate_all_domain_pages( >> amd_iommu_flush_all_pages(d); >> } >> >> -static void invalidate_all_devices(void) >> +static int _invalidate_all_devices( >> + u16 seg, struct ivrs_mappings *ivrs_mappings) >> { >> int bdf, req_id; >> unsigned long flags; >> @@ -913,7 +962,7 @@ static void invalidate_all_devices(void) >> >> for ( bdf =3D 0; bdf < ivrs_bdf_entries; bdf++ ) >> { >> - iommu =3D find_iommu_for_device(bdf); >> + iommu =3D find_iommu_for_device(seg, bdf); >> req_id =3D ivrs_mappings[bdf].dte_requestor_id; >> if ( iommu ) >> { >> @@ -924,6 +973,13 @@ static void invalidate_all_devices(void) >> spin_unlock_irqrestore(&iommu->lock, flags); >> } >> } >> + >> + return 0; >> +} >> + >> +static void invalidate_all_devices(void) >> +{ >> + iterate_ivrs_mappings(_invalidate_all_devices); >> } >> >> void amd_iommu_suspend(void) >> --- 2011-08-25.orig/xen/drivers/passthrough/amd/iommu_intr.c = 2011-08-19 >> 17:08:35.000000000 +0200 +++ >> 2011-08-25/xen/drivers/passthrough/amd/iommu_intr.c 2011-08-25 >> 15:06:47.000000000 +0200 @@ -28,20 +28,21 @@ >> #define INTREMAP_ENTRIES (1 << INTREMAP_LENGTH) >> >> int ioapic_bdf[MAX_IO_APICS]; >> +u16 ioapic_seg[MAX_IO_APICS]; >> void *shared_intremap_table; >> static DEFINE_SPINLOCK(shared_intremap_lock); >> >> -static spinlock_t* get_intremap_lock(int req_id) >> +static spinlock_t* get_intremap_lock(int seg, int req_id) >> { >> return (amd_iommu_perdev_intremap ? >> - &ivrs_mappings[req_id].intremap_lock: >> + &get_ivrs_mappings(seg)[req_id].intremap_lock: >> &shared_intremap_lock); >> } >> >> -static int get_intremap_requestor_id(int bdf) >> +static int get_intremap_requestor_id(int seg, int bdf) >> { >> ASSERT( bdf < ivrs_bdf_entries ); >> - return ivrs_mappings[bdf].dte_requestor_id; >> + return get_ivrs_mappings(seg)[bdf].dte_requestor_id; >> } >> >> static int get_intremap_offset(u8 vector, u8 dm) >> @@ -53,20 +54,20 @@ static int get_intremap_offset(u8 vector >> return offset; >> } >> >> -static u8 *get_intremap_entry(int bdf, int offset) >> +static u8 *get_intremap_entry(int seg, int bdf, int offset) >> { >> u8 *table; >> >> - table =3D (u8*)ivrs_mappings[bdf].intremap_table; >> + table =3D (u8*)get_ivrs_mappings(seg)[bdf].intremap_table; >> ASSERT( (table !=3D NULL) && (offset < INTREMAP_ENTRIES) ); >> >> return (u8*) (table + offset); >> } >> >> -static void free_intremap_entry(int bdf, int offset) >> +static void free_intremap_entry(int seg, int bdf, int offset) >> { >> u32* entry; >> - entry =3D (u32*)get_intremap_entry(bdf, offset); >> + entry =3D (u32*)get_intremap_entry(seg, bdf, offset); >> memset(entry, 0, sizeof(u32)); >> } >> >> @@ -125,8 +126,8 @@ static void update_intremap_entry_from_i >> spinlock_t *lock; >> int offset; >> >> - req_id =3D get_intremap_requestor_id(bdf); >> - lock =3D get_intremap_lock(req_id); >> + req_id =3D get_intremap_requestor_id(iommu->seg, bdf); >> + lock =3D get_intremap_lock(iommu->seg, req_id); >> >> delivery_mode =3D rte->delivery_mode; >> vector =3D rte->vector; >> @@ -136,7 +137,7 @@ static void update_intremap_entry_from_i >> spin_lock_irqsave(lock, flags); >> >> offset =3D get_intremap_offset(vector, delivery_mode); >> - entry =3D (u32*)get_intremap_entry(req_id, offset); >> + entry =3D (u32*)get_intremap_entry(iommu->seg, req_id, offset); >> update_intremap_entry(entry, vector, delivery_mode, dest_mode, = dest); >> >> spin_unlock_irqrestore(lock, flags); >> @@ -175,7 +176,7 @@ int __init amd_iommu_setup_ioapic_remapp >> >> /* get device id of ioapic devices */ >> bdf =3D ioapic_bdf[IO_APIC_ID(apic)]; >> - iommu =3D find_iommu_for_device(bdf); >> + iommu =3D find_iommu_for_device(ioapic_seg[IO_APIC_ID(apic)= ], >> bdf); if ( !iommu ) >> { >> AMD_IOMMU_DEBUG("Fail to find iommu for ioapic " >> @@ -183,8 +184,8 @@ int __init amd_iommu_setup_ioapic_remapp >> continue; >> } >> >> - req_id =3D get_intremap_requestor_id(bdf); >> - lock =3D get_intremap_lock(req_id); >> + req_id =3D get_intremap_requestor_id(iommu->seg, bdf); >> + lock =3D get_intremap_lock(iommu->seg, req_id); >> >> delivery_mode =3D rte.delivery_mode; >> vector =3D rte.vector; >> @@ -193,7 +194,7 @@ int __init amd_iommu_setup_ioapic_remapp >> >> spin_lock_irqsave(lock, flags); >> offset =3D get_intremap_offset(vector, delivery_mode); >> - entry =3D (u32*)get_intremap_entry(req_id, offset); >> + entry =3D (u32*)get_intremap_entry(iommu->seg, req_id, = offset); >> update_intremap_entry(entry, vector, >> delivery_mode, dest_mode, dest); >> spin_unlock_irqrestore(lock, flags); >> @@ -227,7 +228,7 @@ void amd_iommu_ioapic_update_ire( >> >> /* get device id of ioapic devices */ >> bdf =3D ioapic_bdf[IO_APIC_ID(apic)]; >> - iommu =3D find_iommu_for_device(bdf); >> + iommu =3D find_iommu_for_device(ioapic_seg[IO_APIC_ID(apic)], = bdf); >> if ( !iommu ) >> { >> AMD_IOMMU_DEBUG("Fail to find iommu for ioapic device id =3D >> 0x%x\n", @@ -289,28 +290,28 @@ static void update_intremap_entry_from_m >> int offset; >> >> bdf =3D (pdev->bus << 8) | pdev->devfn; >> - req_id =3D get_dma_requestor_id(bdf); >> - alias_id =3D get_intremap_requestor_id(bdf); >> + req_id =3D get_dma_requestor_id(pdev->seg, bdf); >> + alias_id =3D get_intremap_requestor_id(pdev->seg, bdf); >> >> if ( msg =3D=3D NULL ) >> { >> - lock =3D get_intremap_lock(req_id); >> + lock =3D get_intremap_lock(iommu->seg, req_id); >> spin_lock_irqsave(lock, flags); >> - free_intremap_entry(req_id, msi_desc->remap_index); >> + free_intremap_entry(iommu->seg, req_id, msi_desc->remap_index);= >> spin_unlock_irqrestore(lock, flags); >> >> if ( ( req_id !=3D alias_id ) && >> - ivrs_mappings[alias_id].intremap_table !=3D NULL ) >> + get_ivrs_mappings(pdev->seg)[alias_id].intremap_table = !=3D NULL >> ) { >> - lock =3D get_intremap_lock(alias_id); >> + lock =3D get_intremap_lock(iommu->seg, alias_id); >> spin_lock_irqsave(lock, flags); >> - free_intremap_entry(alias_id, msi_desc->remap_index); >> + free_intremap_entry(iommu->seg, alias_id, >> msi_desc->remap_index); spin_unlock_irqrestore(lock, flags); >> } >> goto done; >> } >> >> - lock =3D get_intremap_lock(req_id); >> + lock =3D get_intremap_lock(iommu->seg, req_id); >> >> spin_lock_irqsave(lock, flags); >> dest_mode =3D (msg->address_lo >> MSI_ADDR_DESTMODE_SHIFT) & 0x1; >> @@ -320,7 +321,7 @@ static void update_intremap_entry_from_m >> offset =3D get_intremap_offset(vector, delivery_mode); >> msi_desc->remap_index =3D offset; >> >> - entry =3D (u32*)get_intremap_entry(req_id, offset); >> + entry =3D (u32*)get_intremap_entry(iommu->seg, req_id, offset); >> update_intremap_entry(entry, vector, delivery_mode, dest_mode, = dest); >> spin_unlock_irqrestore(lock, flags); >> >> @@ -331,12 +332,12 @@ static void update_intremap_entry_from_m >> * devices. >> */ >> >> - lock =3D get_intremap_lock(alias_id); >> + lock =3D get_intremap_lock(iommu->seg, alias_id); >> if ( ( req_id !=3D alias_id ) && >> - ivrs_mappings[alias_id].intremap_table !=3D NULL ) >> + get_ivrs_mappings(pdev->seg)[alias_id].intremap_table !=3D = NULL ) >> { >> spin_lock_irqsave(lock, flags); >> - entry =3D (u32*)get_intremap_entry(alias_id, offset); >> + entry =3D (u32*)get_intremap_entry(iommu->seg, alias_id, = offset); >> update_intremap_entry(entry, vector, delivery_mode, dest_mode, >> dest); spin_unlock_irqrestore(lock, flags); >> } >> @@ -362,7 +363,7 @@ void amd_iommu_msi_msg_update_ire( >> if ( !iommu_intremap ) >> return; >> >> - iommu =3D find_iommu_for_device((pdev->bus << 8) | pdev->devfn); >> + iommu =3D find_iommu_for_device(pdev->seg, (pdev->bus << 8) | >> pdev->devfn); >> >> if ( !iommu ) >> { >> @@ -379,15 +380,18 @@ void amd_iommu_read_msi_from_ire( >> { >> } >> >> -void __init amd_iommu_free_intremap_table(int bdf) >> +int __init amd_iommu_free_intremap_table( >> + u16 seg, struct ivrs_mappings *ivrs_mapping) >> { >> - void *tb =3D ivrs_mappings[bdf].intremap_table; >> + void *tb =3D ivrs_mapping->intremap_table; >> >> if ( tb ) >> { >> __free_amd_iommu_tables(tb, INTREMAP_TABLE_ORDER); >> - ivrs_mappings[bdf].intremap_table =3D NULL; >> + ivrs_mapping->intremap_table =3D NULL; >> } >> + >> + return 0; >> } >> >> void* __init amd_iommu_alloc_intremap_table(void) >> --- 2011-08-25.orig/xen/drivers/passthrough/amd/iommu_map.c = 2011-08-25 >> 08:21:53.000000000 +0200 +++ >> 2011-08-25/xen/drivers/passthrough/amd/iommu_map.c 2011-08-25 >> 15:06:47.000000000 +0200 @@ -719,8 +719,8 @@ static int >> update_paging_mode(struct dom >> for_each_pdev( d, pdev ) >> { >> bdf =3D (pdev->bus << 8) | pdev->devfn; >> - req_id =3D get_dma_requestor_id(bdf); >> - iommu =3D find_iommu_for_device(bdf); >> + req_id =3D get_dma_requestor_id(pdev->seg, bdf); >> + iommu =3D find_iommu_for_device(pdev->seg, bdf); >> if ( !iommu ) >> { >> AMD_IOMMU_DEBUG("%s Fail to find iommu.\n", __func__); >> --- 2011-08-25.orig/xen/drivers/passthrough/amd/pci_amd_iommu.c = 2011-08-25 >> 15:06:40.000000000 +0200 +++ >> 2011-08-25/xen/drivers/passthrough/amd/pci_amd_iommu.c 2011-08-25 >> 15:06:47.000000000 +0200 @@ -29,10 +29,12 @@ >> extern bool_t __read_mostly opt_irq_perdev_vector_map; >> extern bool_t __read_mostly iommu_amd_perdev_vector_map; >> >> -struct amd_iommu *find_iommu_for_device(int bdf) >> +struct amd_iommu *find_iommu_for_device(int seg, int bdf) >> { >> + struct ivrs_mappings *ivrs_mappings =3D get_ivrs_mappings(seg); >> + >> BUG_ON ( bdf >=3D ivrs_bdf_entries ); >> - return ivrs_mappings[bdf].iommu; >> + return ivrs_mappings ? ivrs_mappings[bdf].iommu : NULL; >> } >> >> /* >> @@ -43,8 +45,9 @@ struct amd_iommu *find_iommu_for_device( >> * Return original device id, if device has valid interrupt remapping >> * table setup for both select entry and alias entry. >> */ >> -int get_dma_requestor_id(u16 bdf) >> +int get_dma_requestor_id(u16 seg, u16 bdf) >> { >> + struct ivrs_mappings *ivrs_mappings =3D get_ivrs_mappings(seg); >> int req_id; >> >> BUG_ON ( bdf >=3D ivrs_bdf_entries ); >> @@ -95,7 +98,7 @@ static void amd_iommu_setup_domain_devic >> valid =3D 0; >> >> /* get device-table entry */ >> - req_id =3D get_dma_requestor_id(bdf); >> + req_id =3D get_dma_requestor_id(iommu->seg, bdf); >> dte =3D iommu->dev_table.buffer + (req_id * IOMMU_DEV_TABLE_ENTRY_S= IZE); >> >> spin_lock_irqsave(&iommu->lock, flags); >> @@ -139,7 +142,7 @@ static void __init amd_iommu_setup_dom0_ >> list_add(&pdev->domain_list, &d->arch.pdev_list); >> >> bdf =3D (bus << 8) | devfn; >> - iommu =3D find_iommu_for_device(bdf); >> + iommu =3D find_iommu_for_device(pdev->seg, bdf); >> >> if ( likely(iommu !=3D NULL) ) >> amd_iommu_setup_domain_device(d, iommu, bdf); >> @@ -270,7 +273,7 @@ static void amd_iommu_disable_domain_dev >> int req_id; >> >> BUG_ON ( iommu->dev_table.buffer =3D=3D NULL ); >> - req_id =3D get_dma_requestor_id(bdf); >> + req_id =3D get_dma_requestor_id(iommu->seg, bdf); >> dte =3D iommu->dev_table.buffer + (req_id * IOMMU_DEV_TABLE_ENTRY_S= IZE); >> >> spin_lock_irqsave(&iommu->lock, flags); >> @@ -301,12 +304,12 @@ static int reassign_device( struct domai >> return -ENODEV; >> >> bdf =3D (bus << 8) | devfn; >> - iommu =3D find_iommu_for_device(bdf); >> + iommu =3D find_iommu_for_device(seg, bdf); >> if ( !iommu ) >> { >> AMD_IOMMU_DEBUG("Fail to find iommu." >> - " %02x:%x02.%x cannot be assigned to domain = %d\n", >> - bus, PCI_SLOT(devfn), PCI_FUNC(devfn), >> + " %04x:%02x:%x02.%x cannot be assigned to >> dom%d\n", + seg, bus, PCI_SLOT(devfn), >> PCI_FUNC(devfn), target->domain_id); >> return -ENODEV; >> } >> @@ -322,8 +325,8 @@ static int reassign_device( struct domai >> allocate_domain_resources(t); >> >> amd_iommu_setup_domain_device(target, iommu, bdf); >> - AMD_IOMMU_DEBUG("Re-assign %02x:%02x.%x from domain %d to domain >> %d\n", - bus, PCI_SLOT(devfn), PCI_FUNC(devfn), >> + AMD_IOMMU_DEBUG("Re-assign %04x:%02x:%02x.%u from dom%d to = dom%d\n", >> + seg, bus, PCI_SLOT(devfn), PCI_FUNC(devfn), >> source->domain_id, target->domain_id); >> >> return 0; >> @@ -331,8 +334,9 @@ static int reassign_device( struct domai >> >> static int amd_iommu_assign_device(struct domain *d, u16 seg, u8 bus, = u8 >> devfn) { >> + struct ivrs_mappings *ivrs_mappings =3D get_ivrs_mappings(seg); >> int bdf =3D (bus << 8) | devfn; >> - int req_id =3D get_dma_requestor_id(bdf); >> + int req_id =3D get_dma_requestor_id(seg, bdf); >> >> if ( ivrs_mappings[req_id].unity_map_enable ) >> { >> @@ -422,12 +426,12 @@ static int amd_iommu_add_device(struct p >> return -EINVAL; >> >> bdf =3D (pdev->bus << 8) | pdev->devfn; >> - iommu =3D find_iommu_for_device(bdf); >> + iommu =3D find_iommu_for_device(pdev->seg, bdf); >> if ( !iommu ) >> { >> AMD_IOMMU_DEBUG("Fail to find iommu." >> - " %02x:%02x.%x cannot be assigned to domain = %d\n", >> - pdev->bus, PCI_SLOT(pdev->devfn), >> + " %04x:%02x:%02x.%u cannot be assigned to >> dom%d\n", + pdev->seg, pdev->bus, >> PCI_SLOT(pdev->devfn), PCI_FUNC(pdev->devfn), pdev->domain->domain_id); >> return -ENODEV; >> } >> @@ -444,12 +448,12 @@ static int amd_iommu_remove_device(struc >> return -EINVAL; >> >> bdf =3D (pdev->bus << 8) | pdev->devfn; >> - iommu =3D find_iommu_for_device(bdf); >> + iommu =3D find_iommu_for_device(pdev->seg, bdf); >> if ( !iommu ) >> { >> AMD_IOMMU_DEBUG("Fail to find iommu." >> - " %02x:%02x.%x cannot be removed from domain >> %d\n", - pdev->bus, PCI_SLOT(pdev->devfn), >> + " %04x:%02x:%02x.%u cannot be removed from >> dom%d\n", + pdev->seg, pdev->bus, >> PCI_SLOT(pdev->devfn), PCI_FUNC(pdev->devfn), pdev->domain->domain_id); >> return -ENODEV; >> } >> @@ -463,7 +467,7 @@ static int amd_iommu_group_id(u16 seg, u >> int rt; >> int bdf =3D (bus << 8) | devfn; >> rt =3D ( bdf < ivrs_bdf_entries ) ? >> - get_dma_requestor_id(bdf) : >> + get_dma_requestor_id(seg, bdf) : >> bdf; >> return rt; >> } >> --- 2011-08-25.orig/xen/include/asm-x86/amd-iommu.h 2011-06-16 >> 09:21:02.000000000 +0200 +++ 2011-08-25/xen/include/asm-x86/amd-iommu.h= =20 >> 2011-08-25 15:06:47.000000000 +0200 @@ -40,6 +40,7 @@ struct amd_iommu = { >> struct list_head list; >> spinlock_t lock; /* protect iommu */ >> >> + u16 seg; >> u16 bdf; >> u8 cap_offset; >> u8 revision; >> @@ -101,6 +102,10 @@ struct ivrs_mappings { >> }; >> >> extern unsigned short ivrs_bdf_entries; >> -extern struct ivrs_mappings *ivrs_mappings; >> + >> +int alloc_ivrs_mappings(u16 seg); >> +struct ivrs_mappings *get_ivrs_mappings(u16 seg); >> +int iterate_ivrs_mappings(int (*)(u16 seg, struct ivrs_mappings *)); >> +int iterate_ivrs_entries(int (*)(u16 seg, struct ivrs_mappings *)); >> >> #endif /* _ASM_X86_64_AMD_IOMMU_H */ >> --- 2011-08-25.orig/xen/include/asm-x86/hvm/svm/amd-iommu-proto.h = =20 >> 2011-08-19 17:08:35.000000000 +0200 +++ >> 2011-08-25/xen/include/asm-x86/hvm/svm/amd-iommu-proto.h 2011-08-25 >> 15:06:47.000000000 +0200 @@ -65,7 +65,7 @@ int >> amd_iommu_reserve_domain_unity_map(s >> void amd_iommu_share_p2m(struct domain *d); >> >> /* device table functions */ >> -int get_dma_requestor_id(u16 bdf); >> +int get_dma_requestor_id(u16 seg, u16 bdf); >> void amd_iommu_add_dev_table_entry( >> u32 *dte, u8 sys_mgt, u8 dev_ex, u8 lint1_pass, u8 lint0_pass, >> u8 nmi_pass, u8 ext_int_pass, u8 init_pass); >> @@ -80,12 +80,12 @@ int send_iommu_command(struct amd_iommu >> void flush_command_buffer(struct amd_iommu *iommu); >> >> /* find iommu for bdf */ >> -struct amd_iommu *find_iommu_for_device(int bdf); >> +struct amd_iommu *find_iommu_for_device(int seg, int bdf); >> >> /* interrupt remapping */ >> int amd_iommu_setup_ioapic_remapping(void); >> void *amd_iommu_alloc_intremap_table(void); >> -void amd_iommu_free_intremap_table(int bdf); >> +int amd_iommu_free_intremap_table(u16 seg, struct ivrs_mappings *); >> void invalidate_interrupt_table(struct amd_iommu *iommu, u16 device_id)= ; >> void amd_iommu_ioapic_update_ire( >> unsigned int apic, unsigned int reg, unsigned int value); >> @@ -95,6 +95,7 @@ void amd_iommu_read_msi_from_ire( >> struct msi_desc *msi_desc, struct msi_msg *msg); >> >> extern int ioapic_bdf[MAX_IO_APICS]; >> +extern u16 ioapic_seg[MAX_IO_APICS]; >> extern void *shared_intremap_table; >> >> /* power management support */ _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel From xen-devel-bounces@lists.xensource.com Mon Sep 05 06:19:03 2011 Return-path: Envelope-to: www-data@lists.xensource.com Delivery-date: Mon, 05 Sep 2011 06:19:03 -0700 Received: from localhost ([127.0.0.1] helo=lists.colo.xensource.com) by lists.xensource.com with esmtp (Exim 4.43) id 1R0Z4p-0001UU-MR; Mon, 05 Sep 2011 06:19:03 -0700 Received: from mail216.messagelabs.com ([85.158.143.99]) by lists.xensource.com with esmtp (Exim 4.43) id 1R0Z3I-00010a-CU for xen-devel@lists.xensource.com; Mon, 05 Sep 2011 06:17:29 -0700 X-Env-Sender: Andrew.Cooper3@citrix.com X-Msg-Ref: server-5.tower-216.messagelabs.com!1315228643!16649476!1 X-Originating-IP: [66.165.176.63] X-StarScan-Version: 6.3.6; banners=-,-,- X-VirusChecked: Checked Received: (qmail 10108 invoked from network); 5 Sep 2011 13:17:24 -0000 Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63) by server-5.tower-216.messagelabs.com with RC4-SHA encrypted SMTP; 5 Sep 2011 13:17:24 -0000 X-IronPort-AV: E=Sophos;i="4.68,333,1312171200"; d="scan'208";a="161746752" Received: from ftlpmailmx02.citrite.net ([10.13.107.66]) by FTLPIPO02.CITRIX.COM with ESMTP/TLS/RC4-MD5; 05 Sep 2011 09:17:22 -0400 Received: from [10.80.2.18] (10.80.2.18) by FTLPMAILMX02.citrite.net (10.13.107.66) with Microsoft SMTP Server id 8.3.137.0; Mon, 5 Sep 2011 09:17:22 -0400 Message-ID: <4E64CBE1.8010502@citrix.com> Date: Mon, 5 Sep 2011 14:17:21 +0100 From: Andrew Cooper User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.2.20) Gecko/20110805 Lightning/1.0b2 Thunderbird/3.1.12 MIME-Version: 1.0 To: "xen-devel@lists.xensource.com" Subject: [Xen-devel] [PATCH 3 of 3] IRQ: Introduce old_vector to irq_cfg v2 References: <1a244d4ca6ac2e442c3b.1314981316@andrewcoop.uk.xensource.com> <4E64B5E9.6010606@citrix.com> <1315223127.5679.9118.camel@elijah> In-Reply-To: <1315223127.5679.9118.camel@elijah> Content-Type: multipart/mixed; boundary="------------080108060603090402060107" X-BeenThere: xen-devel@lists.xensource.com X-Mailman-Version: 2.1.5 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xensource.com Errors-To: xen-devel-bounces@lists.xensource.com --------------080108060603090402060107 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: 7bit IRQ: Introduce old_vector to irq_cfg v2 Introduce old_vector to irq_cfg with the same principle as old_cpu_mask. This removes a brute force loop from __clear_irq_vector(), and paves the way to correct bitrotten logic elsewhere in the irq code. Changes: * Make use of IRQ_VECTOR_UNASSIGNED instead of -1 for consistency * Correct logic in __clear_irq_vector(): should clean up cfg->old_vector rather than cfg->vector which has already been cleaned up Signed-off-by Andrew Cooper -- Andrew Cooper - Dom0 Kernel Engineer, Citrix XenServer T: +44 (0)1223 225 900, http://www.citrix.com --------------080108060603090402060107 Content-Type: text/x-patch; name="irq-introduce-old_vector-to-irq_cfg.patch" Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename="irq-introduce-old_vector-to-irq_cfg.patch" IRQ: Introduce old_vector to irq_cfg v2 Introduce old_vector to irq_cfg with the same principle as old_cpu_mask. This removes a brute force loop from __clear_irq_vector(), and paves the way to correct bitrotten logic elsewhere in the irq code. Changes: * Make use of IRQ_VECTOR_UNASSIGNED instead of -1 for consistency * Correct logic in __clear_irq_vector(): should clean up cfg->old_vector rather than cfg->vector which has already been cleaned up Signed-off-by Andrew Cooper diff -r cf93a1825d66 xen/arch/x86/io_apic.c --- a/xen/arch/x86/io_apic.c Fri Sep 02 17:33:17 2011 +0100 +++ b/xen/arch/x86/io_apic.c Mon Sep 05 14:12:59 2011 +0100 @@ -487,11 +487,16 @@ fastcall void smp_irq_move_cleanup_inter __get_cpu_var(vector_irq)[vector] = -1; cfg->move_cleanup_count--; - if ( cfg->move_cleanup_count == 0 - && cfg->used_vectors ) + if ( cfg->move_cleanup_count == 0 ) { - ASSERT(test_bit(vector, cfg->used_vectors)); - clear_bit(vector, cfg->used_vectors); + cfg->old_vector = IRQ_VECTOR_UNASSIGNED; + cpus_clear(cfg->old_cpu_mask); + + if ( cfg->used_vectors ) + { + ASSERT(test_bit(vector, cfg->used_vectors)); + clear_bit(vector, cfg->used_vectors); + } } unlock: spin_unlock(&desc->lock); diff -r cf93a1825d66 xen/arch/x86/irq.c --- a/xen/arch/x86/irq.c Fri Sep 02 17:33:17 2011 +0100 +++ b/xen/arch/x86/irq.c Mon Sep 05 14:12:59 2011 +0100 @@ -39,8 +39,6 @@ boolean_param("irq-perdev-vector-map", o u8 __read_mostly *irq_vector; struct irq_desc __read_mostly *irq_desc = NULL; -#define IRQ_VECTOR_UNASSIGNED (0) - static DECLARE_BITMAP(used_vectors, NR_VECTORS); struct irq_cfg __read_mostly *irq_cfg = NULL; @@ -211,15 +209,9 @@ static void __clear_irq_vector(int irq) cpus_and(tmp_mask, cfg->old_cpu_mask, cpu_online_map); for_each_cpu_mask(cpu, tmp_mask) { - for (vector = FIRST_DYNAMIC_VECTOR; vector <= LAST_DYNAMIC_VECTOR; - vector++) { - if (per_cpu(vector_irq, cpu)[vector] != irq) - continue; - TRACE_3D(TRC_HW_IRQ_MOVE_FINISH, - irq, vector, cpu); - per_cpu(vector_irq, cpu)[vector] = -1; - break; - } + ASSERT( per_cpu(vector_irq, cpu)[cfg->old_vector] == irq ); + TRACE_3D(TRC_HW_IRQ_MOVE_FINISH, irq, vector, cpu); + per_cpu(vector_irq, cpu)[cfg->old_vector] = -1; } if ( cfg->used_vectors ) @@ -229,6 +221,8 @@ static void __clear_irq_vector(int irq) } cfg->move_in_progress = 0; + cfg->old_vector = IRQ_VECTOR_UNASSIGNED; + cpus_clear(cfg->old_cpu_mask); } void clear_irq_vector(int irq) @@ -279,6 +273,7 @@ static void __init init_one_irq_desc(str static void __init init_one_irq_cfg(struct irq_cfg *cfg) { cfg->vector = IRQ_VECTOR_UNASSIGNED; + cfg->old_vector = IRQ_VECTOR_UNASSIGNED; cpus_clear(cfg->cpu_mask); cpus_clear(cfg->old_cpu_mask); cfg->used_vectors = NULL; @@ -418,6 +413,7 @@ next: if (old_vector) { cfg->move_in_progress = 1; cpus_copy(cfg->old_cpu_mask, cfg->cpu_mask); + cfg->old_vector = cfg->vector; } trace_irq_mask(TRC_HW_IRQ_ASSIGN_VECTOR, irq, vector, &tmp_mask); for_each_cpu_mask(new_cpu, tmp_mask) diff -r cf93a1825d66 xen/include/asm-x86/irq.h --- a/xen/include/asm-x86/irq.h Fri Sep 02 17:33:17 2011 +0100 +++ b/xen/include/asm-x86/irq.h Mon Sep 05 14:12:59 2011 +0100 @@ -28,7 +28,8 @@ typedef struct { } vmask_t; struct irq_cfg { - int vector; + s16 vector; /* vector itself is only 8 bits, */ + s16 old_vector; /* but we use -1 for unassigned */ cpumask_t cpu_mask; cpumask_t old_cpu_mask; unsigned move_cleanup_count; @@ -41,6 +42,8 @@ struct irq_cfg { #define IRQ_UNUSED (0) #define IRQ_USED (1) +#define IRQ_VECTOR_UNASSIGNED (-1) + extern struct irq_cfg *irq_cfg; typedef int vector_irq_t[NR_VECTORS]; --------------080108060603090402060107 Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel --------------080108060603090402060107-- From xen-devel-bounces@lists.xensource.com Mon Sep 05 06:19:54 2011 Return-path: Envelope-to: www-data@lists.xensource.com Delivery-date: Mon, 05 Sep 2011 06:19:54 -0700 Received: from localhost ([127.0.0.1] helo=lists.colo.xensource.com) by lists.xensource.com with esmtp (Exim 4.43) id 1R0Z5d-0001qj-27; Mon, 05 Sep 2011 06:19:53 -0700 Received: from mail174.messagelabs.com ([85.158.138.51]) by lists.xensource.com with esmtp (Exim 4.43) id 1R0Z4P-0001HP-Ds for xen-devel@lists.xensource.com; Mon, 05 Sep 2011 06:18:37 -0700 X-Env-Sender: JBeulich@suse.com X-Msg-Ref: server-13.tower-174.messagelabs.com!1315228712!30302267!1 X-Originating-IP: [130.57.49.28] X-StarScan-Version: 6.3.6; banners=-,-,- X-VirusChecked: Checked Received: (qmail 24102 invoked from network); 5 Sep 2011 13:18:34 -0000 Received: from nat28.tlf.novell.com (HELO nat28.tlf.novell.com) (130.57.49.28) by server-13.tower-174.messagelabs.com with DHE-RSA-AES256-SHA encrypted SMTP; 5 Sep 2011 13:18:34 -0000 Received: from EMEA1-MTA by nat28.tlf.novell.com with Novell_GroupWise; Mon, 05 Sep 2011 14:18:32 +0100 Message-Id: <4E64E8460200007800054ADB@nat28.tlf.novell.com> X-Mailer: Novell GroupWise Internet Agent 8.0.1 Date: Mon, 05 Sep 2011 14:18:30 +0100 From: "Jan Beulich" To: "Ian Jackson" , "Keir Fraser" Subject: Re: [Xen-devel] [PATCH, RFC 0/7] PCI multi-segment support References: <4E567E3E0200007800053454@nat28.tlf.novell.com> In-Reply-To: <4E567E3E0200007800053454@nat28.tlf.novell.com> Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: quoted-printable Content-Disposition: inline Cc: "xen-devel@lists.xensource.com" X-BeenThere: xen-devel@lists.xensource.com X-Mailman-Version: 2.1.5 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xensource.com Errors-To: xen-devel-bounces@lists.xensource.com >>> On 25.08.11 at 16:54, "Jan Beulich" wrote: > In order for Xen to be able to boot on systems with multiple PCI = segments > (also called domains), a number of changes are necessary to the > hypervisor, the hypercall interface, the tools, and the Dom0 kernel, as > in most code paths and definitions there were not even provisions for > passing a segment number. >=20 > The hypercall interface changes may need some discussion before > applying the patches, in particular >=20 > - whether the way PHYSDEVOP_map_pirq gets re-used is acceptable, > or whether alternatively we should define a replacement one sub- > hypercall > - whether PHYSDEVOP_manage_pci_* should be deprecated > - whether the bit assignments for the four uses of machine_bdf in > the domctl interface can be re-defined No comment from either of you on the proposed changes? Jan > Additionally, in the AMD IOMMU code there are two places where I > was unable to identify how the segment value ought to be retrieved. > Since I'm unaware of multi-segment AMD-based systems, imo this > should not be a reason to not commit the changes proposed. >=20 > 1: introduce notion of PCI segments > 2: add new physdevop-s > 3: adjust domctl interface > 4: VT-d specific adjustments > 5: AMD-IOMMU specific adjustments > 6: Pass-through adjustments > 7: config space accessor adjustments >=20 > Signed-off-by: Jan Beulich _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel From xen-devel-bounces@lists.xensource.com Mon Sep 05 06:20:42 2011 Return-path: Envelope-to: www-data@lists.xensource.com Delivery-date: Mon, 05 Sep 2011 06:20:42 -0700 Received: from localhost ([127.0.0.1] helo=lists.colo.xensource.com) by lists.xensource.com with esmtp (Exim 4.43) id 1R0Z6Q-0002De-Rn; Mon, 05 Sep 2011 06:20:42 -0700 Received: from mail27.messagelabs.com ([193.109.254.147]) by lists.xensource.com with esmtp (Exim 4.43) id 1R0Z5O-0001jL-PF for xen-devel@lists.xensource.com; Mon, 05 Sep 2011 06:19:39 -0700 X-Env-Sender: olaf@aepfle.de X-Msg-Ref: server-15.tower-27.messagelabs.com!1315228767!47455279!1 X-Originating-IP: [81.169.146.162] X-StarScan-Version: 6.3.6; banners=-,-,- X-VirusChecked: Checked Received: (qmail 25046 invoked from network); 5 Sep 2011 13:19:28 -0000 Received: from mo-p00-ob.rzone.de (HELO mo-p00-ob.rzone.de) (81.169.146.162) by server-15.tower-27.messagelabs.com with EDH-RSA-DES-CBC3-SHA encrypted SMTP; 5 Sep 2011 13:19:28 -0000 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; t=1315228774; l=725; s=domk; d=aepfle.de; h=To:From:Date:Subject:Content-Transfer-Encoding:MIME-Version: Content-Type:X-RZG-CLASS-ID:X-RZG-AUTH; bh=Ars2tNWsAtSUsLlkAdTJtZ/48Og=; b=KjSVceJ3xJ0yBMh6GIb0G7EIlRuI1kyHzrTJhEcxVO1rK3Is0Qv4T4nmnvxSoevRrRs uysJm7PhSW6B32LOAHIqS4l5neGBdFoRjlrczl4O1nonoQOsd0BDbpMDduFqIa3lxjDhA HNxIhrGwJwjiSmeCxLBYWgQiHnPYoycNrSc= X-RZG-AUTH: :P2EQZWCpfu+qG7CngxMFH1J+zrwiavkK6tmQaLfmwtM48/ll2s7pEE4= X-RZG-CLASS-ID: mo00 Received: from probook.site (dslb-084-057-083-022.pools.arcor-ip.net [84.57.83.22]) by post.strato.de (mrclete mo33) (RZmta 26.6) with (EDH-RSA-DES-CBC3-SHA encrypted) ESMTPA id c028f2n85CLlON for ; Mon, 5 Sep 2011 15:19:30 +0200 (MEST) Received: from probook.site (localhost [IPv6:::1]) by probook.site (Postfix) with ESMTP id F10F618B64 for ; Mon, 5 Sep 2011 15:19:29 +0200 (CEST) Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Mercurial-Node: c703c8e56b81b538e1a6c64dca9150c608fc99d7 Message-Id: User-Agent: Mercurial-patchbomb/1.7.5 Date: Mon, 05 Sep 2011 15:19:28 +0200 From: Olaf Hering To: xen-devel@lists.xensource.com Subject: [Xen-devel] [PATCH] mem_event: use mem_event_mark_and_pause() in mem_event_check_ring() X-BeenThere: xen-devel@lists.xensource.com X-Mailman-Version: 2.1.5 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xensource.com Errors-To: xen-devel-bounces@lists.xensource.com # HG changeset patch # User Olaf Hering # Date 1315228750 -7200 # Node ID c703c8e56b81b538e1a6c64dca9150c608fc99d7 # Parent b2c8dacb2dc08bd93e4926eb0c2c7823d40e2174 mem_event: use mem_event_mark_and_pause() in mem_event_check_ring() Signed-off-by: Olaf Hering diff -r b2c8dacb2dc0 -r c703c8e56b81 xen/arch/x86/mm/mem_event.c --- a/xen/arch/x86/mm/mem_event.c +++ b/xen/arch/x86/mm/mem_event.c @@ -178,10 +178,7 @@ int mem_event_check_ring(struct domain * } if ( (curr->domain->domain_id == d->domain_id) && ring_full ) - { - set_bit(_VPF_mem_event, &curr->pause_flags); - vcpu_sleep_nosync(curr); - } + mem_event_mark_and_pause(curr); mem_event_ring_unlock(d); _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel From xen-devel-bounces@lists.xensource.com Mon Sep 05 06:34:41 2011 Return-path: Envelope-to: www-data@lists.xensource.com Delivery-date: Mon, 05 Sep 2011 06:34:41 -0700 Received: from localhost ([127.0.0.1] helo=lists.colo.xensource.com) by lists.xensource.com with esmtp (Exim 4.43) id 1R0ZJx-0002t7-9F; Mon, 05 Sep 2011 06:34:41 -0700 Received: from mail27.messagelabs.com ([193.109.254.147]) by lists.xensource.com with esmtp (Exim 4.43) id 1R0ZJG-0002gE-Bv for xen-devel@lists.xensource.com; Mon, 05 Sep 2011 06:33:58 -0700 X-Env-Sender: keir.xen@gmail.com X-Msg-Ref: server-10.tower-27.messagelabs.com!1315229617!34433829!1 X-Originating-IP: [74.125.82.43] X-StarScan-Version: 6.3.6; banners=-,-,- X-VirusChecked: Checked Received: (qmail 26266 invoked from network); 5 Sep 2011 13:33:37 -0000 Received: from mail-ww0-f43.google.com (HELO mail-ww0-f43.google.com) (74.125.82.43) by server-10.tower-27.messagelabs.com with RC4-SHA encrypted SMTP; 5 Sep 2011 13:33:37 -0000 Received: by wwe32 with SMTP id 32so4146628wwe.24 for ; Mon, 05 Sep 2011 06:33:55 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=user-agent:date:subject:from:to:cc:message-id:thread-topic :thread-index:in-reply-to:mime-version:content-type :content-transfer-encoding; bh=fwqkI1aG8dg18gCnxxtW4exURtkG+82OtRyXx+VjFLA=; b=a1SQT0GKIlB4JD5kf0MoObuHTAqWj3JchzwJxtdRR+BsSD6G9EcOzER8MFrUEghFtV uGuqLHS9XpazEiuuUgID900zBGAOkwlqael8zNC5Uvk/kaF8XwwOf7FH24IEUBDiPBdq gZV+KhN64/UGzuTDYu9tByhO8rw9bLqRlSv88= Received: by 10.216.229.217 with SMTP id h67mr1854482weq.1.1315229634960; Mon, 05 Sep 2011 06:33:54 -0700 (PDT) Received: from [192.168.1.78] (host86-137-116-193.range86-137.btcentralplus.com [86.137.116.193]) by mx.google.com with ESMTPS id et17sm8249311wbb.0.2011.09.05.06.33.50 (version=SSLv3 cipher=OTHER); Mon, 05 Sep 2011 06:33:53 -0700 (PDT) User-Agent: Microsoft-Entourage/12.30.0.110427 Date: Mon, 05 Sep 2011 14:33:45 +0100 Subject: Re: [Xen-devel] [PATCH, RFC 0/7] PCI multi-segment support From: Keir Fraser To: Jan Beulich , Ian Jackson Message-ID: Thread-Topic: [Xen-devel] [PATCH, RFC 0/7] PCI multi-segment support Thread-Index: Acxr0G809RNQKBX/Rk2lRCObsWlLFg== In-Reply-To: <4E64E8460200007800054ADB@nat28.tlf.novell.com> Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit Cc: "xen-devel@lists.xensource.com" X-BeenThere: xen-devel@lists.xensource.com X-Mailman-Version: 2.1.5 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xensource.com Errors-To: xen-devel-bounces@lists.xensource.com On 05/09/2011 14:18, "Jan Beulich" wrote: >>>> On 25.08.11 at 16:54, "Jan Beulich" wrote: >> In order for Xen to be able to boot on systems with multiple PCI segments >> (also called domains), a number of changes are necessary to the >> hypervisor, the hypercall interface, the tools, and the Dom0 kernel, as >> in most code paths and definitions there were not even provisions for >> passing a segment number. >> >> The hypercall interface changes may need some discussion before >> applying the patches, in particular >> >> - whether the way PHYSDEVOP_map_pirq gets re-used is acceptable, >> or whether alternatively we should define a replacement one sub- >> hypercall >> - whether PHYSDEVOP_manage_pci_* should be deprecated >> - whether the bit assignments for the four uses of machine_bdf in >> the domctl interface can be re-defined > > No comment from either of you on the proposed changes? I'm personally fine with folding segment into the bus field. Otherwise we just end up with more compat cruft. I don't have an opinion on the PHYSDEVOP_manage_pci_* hypercalls. In fact I don't know much about them at all. I've always considered the domctl interface subject to change, but you don't seem to redefine anything that already exists? You just give meaning to bits 24-31 of an existing 32-bit parameter? -- Keir > Jan > >> Additionally, in the AMD IOMMU code there are two places where I >> was unable to identify how the segment value ought to be retrieved. >> Since I'm unaware of multi-segment AMD-based systems, imo this >> should not be a reason to not commit the changes proposed. >> >> 1: introduce notion of PCI segments >> 2: add new physdevop-s >> 3: adjust domctl interface >> 4: VT-d specific adjustments >> 5: AMD-IOMMU specific adjustments >> 6: Pass-through adjustments >> 7: config space accessor adjustments >> >> Signed-off-by: Jan Beulich > _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel From xen-devel-bounces@lists.xensource.com Mon Sep 05 06:50:04 2011 Return-path: Envelope-to: www-data@lists.xensource.com Delivery-date: Mon, 05 Sep 2011 06:50:04 -0700 Received: from localhost ([127.0.0.1] helo=lists.colo.xensource.com) by lists.xensource.com with esmtp (Exim 4.43) id 1R0ZYp-0003Tc-Q7; Mon, 05 Sep 2011 06:50:03 -0700 Received: from mail27.messagelabs.com ([193.109.254.147]) by lists.xensource.com with esmtp (Exim 4.43) id 1R0ZYK-0003Gw-B5 for xen-devel@lists.xensource.com; Mon, 05 Sep 2011 06:49:32 -0700 X-Env-Sender: JBeulich@suse.com X-Msg-Ref: server-2.tower-27.messagelabs.com!1315230547!53656848!1 X-Originating-IP: [130.57.49.28] X-StarScan-Version: 6.3.6; banners=-,-,- X-VirusChecked: Checked Received: (qmail 5643 invoked from network); 5 Sep 2011 13:49:07 -0000 Received: from nat28.tlf.novell.com (HELO nat28.tlf.novell.com) (130.57.49.28) by server-2.tower-27.messagelabs.com with DHE-RSA-AES256-SHA encrypted SMTP; 5 Sep 2011 13:49:07 -0000 Received: from EMEA1-MTA by nat28.tlf.novell.com with Novell_GroupWise; Mon, 05 Sep 2011 14:49:28 +0100 Message-Id: <4E64EF860200007800054B03@nat28.tlf.novell.com> X-Mailer: Novell GroupWise Internet Agent 8.0.1 Date: Mon, 05 Sep 2011 14:49:26 +0100 From: "Jan Beulich" To: "Ian Jackson" , "Keir Fraser" Subject: Re: [Xen-devel] [PATCH, RFC 0/7] PCI multi-segment support References: <4E64E8460200007800054ADB@nat28.tlf.novell.com> In-Reply-To: Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: quoted-printable Content-Disposition: inline Cc: "xen-devel@lists.xensource.com" X-BeenThere: xen-devel@lists.xensource.com X-Mailman-Version: 2.1.5 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xensource.com Errors-To: xen-devel-bounces@lists.xensource.com >>> On 05.09.11 at 15:33, Keir Fraser wrote: > On 05/09/2011 14:18, "Jan Beulich" wrote: >=20 >>>>> On 25.08.11 at 16:54, "Jan Beulich" wrote: >>> In order for Xen to be able to boot on systems with multiple PCI = segments >>> (also called domains), a number of changes are necessary to the >>> hypervisor, the hypercall interface, the tools, and the Dom0 kernel, = as >>> in most code paths and definitions there were not even provisions for >>> passing a segment number. >>>=20 >>> The hypercall interface changes may need some discussion before >>> applying the patches, in particular >>>=20 >>> - whether the way PHYSDEVOP_map_pirq gets re-used is acceptable, >>> or whether alternatively we should define a replacement one sub- >>> hypercall >>> - whether PHYSDEVOP_manage_pci_* should be deprecated >>> - whether the bit assignments for the four uses of machine_bdf in >>> the domctl interface can be re-defined >>=20 >> No comment from either of you on the proposed changes? >=20 > I'm personally fine with folding segment into the bus field. Otherwise = we > just end up with more compat cruft. >=20 > I don't have an opinion on the PHYSDEVOP_manage_pci_* hypercalls. In = fact I > don't know much about them at all. >=20 > I've always considered the domctl interface subject to change, but you = don't > seem to redefine anything that already exists? You just give meaning to = bits > 24-31 of an existing 32-bit parameter? I'm trying to avoid incompatible changes when possible (due to out-of-tree consumers like libvirt, and due to the hacks required to use domctl interfaces from the kernel). Now here we need 16 bits, but have two sets of 8 (at bottom and top), hence I'd favor doing an incompatible change here (moving the bdf bits down to 0...15, and using 16...31 for the segment), perhaps renaming the field to machine_sbdf (to force compile-time noticing of the change at least for those that actually use our headers). But as the odd bit assignment could have other (hidden) reasons I coded things first to not do any re-assignments. Jan _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel From xen-devel-bounces@lists.xensource.com Mon Sep 05 07:01:48 2011 Return-path: Envelope-to: www-data@lists.xensource.com Delivery-date: Mon, 05 Sep 2011 07:01:48 -0700 Received: from localhost ([127.0.0.1] helo=lists.colo.xensource.com) by lists.xensource.com with esmtp (Exim 4.43) id 1R0Zk9-00040d-Sy; Mon, 05 Sep 2011 07:01:45 -0700 Received: from mail182.messagelabs.com ([85.158.139.83]) by lists.xensource.com with smtp (Exim 4.43) id 1R0Zgj-0003lW-Ma for xen-devel@lists.xensource.com; Mon, 05 Sep 2011 06:59:08 -0700 X-Env-Sender: ml-xen-devel@hfp.de X-Msg-Ref: server-9.tower-182.messagelabs.com!1315231081!17106156!1 X-Originating-IP: [88.205.101.6] X-StarScan-Version: 6.3.6; banners=-,-,- X-VirusChecked: Checked Received: (qmail 20407 invoked from network); 5 Sep 2011 13:58:01 -0000 Received: from rootsrv.hfp.de (HELO rootsrv.hfp.de) (88.205.101.6) by server-9.tower-182.messagelabs.com with SMTP; 5 Sep 2011 13:58:01 -0000 Received: from localhost (localhost [127.0.0.1]) by rootsrv.hfp.de (Postfix) with ESMTP id C38521A8A82; Mon, 5 Sep 2011 15:58:00 +0200 (CEST) X-Virus-Scanned: amavisd-new/ClamAV at rootsrv.hfp.de Received: from rootsrv.hfp.de ([127.0.0.1]) by localhost (rootsrv.hfp.de [127.0.0.1]) (amavisd-new, port 10026) with ESMTP id F9Yzp8fyVqoA; Mon, 5 Sep 2011 15:58:00 +0200 (CEST) Received: from [10.0.0.1] (p5DCB73AE.dip.t-dialin.net [93.203.115.174]) by rootsrv.hfp.de (Postfix) with ESMTPA; Mon, 5 Sep 2011 15:58:00 +0200 (CEST) Message-ID: <4E64D569.5030607@hfp.de> Date: Mon, 05 Sep 2011 15:58:01 +0200 From: Andreas Kinzler User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:6.0.1) Gecko/20110830 Thunderbird/6.0.1 MIME-Version: 1.0 To: James Harper References: <4E64A0DF.2070007@hfp.de> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: xen-devel@lists.xensource.com Subject: [Xen-devel] Re: Stability report GPLPV 0.11.0.308 X-BeenThere: xen-devel@lists.xensource.com X-Mailman-Version: 2.1.5 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xensource.com Errors-To: xen-devel-bounces@lists.xensource.com >> With GPLPV 0.11.0.308 it worked perfectly and with very good performance >> for over 9 days but then when I wanted to monitor the status, I was no >> longer able to connect via remote desktop. When examining the file >> system of the HVMs I found that somehow even the prime95 processes did stop. >> Any ideas? Could c/s 948 make any difference? Network worked perfectly >> for 9 days, so I ask myself if the count of c/s 948 is used at all? >There is some combination that I can't reproduce that seems to cause a >problem when that count isn't passed in correctly. So it is a bug, but >I'm not sure if it causes the problems you are seeing. What exactly is the problem you encountered? >I can give you a link to a build with that fix applied if you want to >test further. Thanks. I have plans to test the 0.11.0.312 version. I have a complete build system here and a kernel-mode enabled signing certificate so I can use that for my tests. Regards Andreas _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel From xen-devel-bounces@lists.xensource.com Mon Sep 05 07:04:21 2011 Return-path: Envelope-to: www-data@lists.xensource.com Delivery-date: Mon, 05 Sep 2011 07:04:21 -0700 Received: from localhost ([127.0.0.1] helo=lists.colo.xensource.com) by lists.xensource.com with esmtp (Exim 4.43) id 1R0Zme-0004PH-V8; Mon, 05 Sep 2011 07:04:20 -0700 Received: from mail21.messagelabs.com ([85.158.143.35]) by lists.xensource.com with esmtp (Exim 4.43) id 1R0Zko-00045L-Ib for xen-devel@lists.xensource.com; Mon, 05 Sep 2011 07:02:29 -0700 X-Env-Sender: davidtecher@yahoo.fr X-Msg-Ref: server-9.tower-21.messagelabs.com!1315231299!47224304!1 X-Originating-IP: [216.139.236.26] X-StarScan-Version: 6.3.6; banners=-,-,- X-VirusChecked: Checked Received: (qmail 14191 invoked from network); 5 Sep 2011 14:01:40 -0000 Received: from sam.nabble.com (HELO sam.nabble.com) (216.139.236.26) by server-9.tower-21.messagelabs.com with AES256-SHA encrypted SMTP; 5 Sep 2011 14:01:40 -0000 Received: from [192.168.236.26] (helo=sam.nabble.com) by sam.nabble.com with esmtp (Exim 4.72) (envelope-from ) id 1R0Zkj-0006z6-8Q for xen-devel@lists.xensource.com; Mon, 05 Sep 2011 07:02:21 -0700 Date: Mon, 5 Sep 2011 07:02:21 -0700 (PDT) From: David TECHER To: xen-devel@lists.xensource.com Message-ID: <1315231341254-4770602.post@n5.nabble.com> In-Reply-To: <20110831151913.GE7276@reaktio.net> References: <1312297850948-4659036.post@n5.nabble.com> <1314699668477-4749561.post@n5.nabble.com> <1314712525082-4750109.post@n5.nabble.com> <1314716445148-4750357.post@n5.nabble.com> <1314720409505-4750600.post@n5.nabble.com> <1314778567400-4753326.post@n5.nabble.com> <20110831083832.GD7276@reaktio.net> <1314780568949-4753422.post@n5.nabble.com> <1314795401771-4754024.post@n5.nabble.com> <20110831151913.GE7276@reaktio.net> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Subject: [Xen-devel] Re: Patches for VGA-Passthrough XEN 4.2 unstable X-BeenThere: xen-devel@lists.xensource.com X-Mailman-Version: 2.1.5 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xensource.com Errors-To: xen-devel-bounces@lists.xensource.com It works with Xen 4.2 unstable. I've updated the patchs last week. Please see http://old.nabble.com/Pathcs-for-VGA-PassThrough-for-xen-4.2-unstable-revision-23799-td32370790.html for more informations. David -- View this message in context: http://xen.1045712.n5.nabble.com/Patches-for-VGA-Passthrough-XEN-4-2-unstable-tp4406265p4770602.html Sent from the Xen - Dev mailing list archive at Nabble.com. _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel From xen-devel-bounces@lists.xensource.com Mon Sep 05 07:06:47 2011 Return-path: Envelope-to: www-data@lists.xensource.com Delivery-date: Mon, 05 Sep 2011 07:06:47 -0700 Received: from localhost ([127.0.0.1] helo=lists.colo.xensource.com) by lists.xensource.com with esmtp (Exim 4.43) id 1R0Zp1-0004mz-AY; Mon, 05 Sep 2011 07:06:47 -0700 Received: from mail27.messagelabs.com ([193.109.254.147]) by lists.xensource.com with esmtp (Exim 4.43) id 1R0Zo3-0004aC-3Y for xen-devel@lists.xensource.com; Mon, 05 Sep 2011 07:06:03 -0700 X-Env-Sender: keir.xen@gmail.com X-Msg-Ref: server-5.tower-27.messagelabs.com!1315231527!43566016!1 X-Originating-IP: [74.125.82.171] X-StarScan-Version: 6.3.6; banners=-,-,- X-VirusChecked: Checked Received: (qmail 17482 invoked from network); 5 Sep 2011 14:05:27 -0000 Received: from mail-wy0-f171.google.com (HELO mail-wy0-f171.google.com) (74.125.82.171) by server-5.tower-27.messagelabs.com with RC4-SHA encrypted SMTP; 5 Sep 2011 14:05:27 -0000 Received: by wyh13 with SMTP id 13so4954494wyh.30 for ; Mon, 05 Sep 2011 07:05:44 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=sender:user-agent:date:subject:from:to:cc:message-id:thread-topic :thread-index:in-reply-to:mime-version:content-type :content-transfer-encoding; bh=lSu01BtVKiUXkR3Fe4jTG3g9Y5kscEquaCOsD+rbP38=; b=UAPEQtJonDKZE2J7rLsZYC/BApCMCthCygUqBvdGytXmPierNjV2rbLHAG4WPE0fw1 IWKXSB2hvmUTGtmotz7oVG/RuJNf1rZWeoN5SOBoxodR7b4+EHRy1mNsRbzlb4Pr6R7H GAlmrV2OZLZdNPkCdQCJjXnIQ21EZXuCPeyH8= Received: by 10.227.205.15 with SMTP id fo15mr3182717wbb.110.1315231543924; Mon, 05 Sep 2011 07:05:43 -0700 (PDT) Received: from [192.168.1.3] (host86-137-116-193.range86-137.btcentralplus.com [86.137.116.193]) by mx.google.com with ESMTPS id fd4sm8301477wbb.21.2011.09.05.07.05.41 (version=SSLv3 cipher=OTHER); Mon, 05 Sep 2011 07:05:42 -0700 (PDT) User-Agent: Microsoft-Entourage/12.30.0.110427 Date: Mon, 05 Sep 2011 15:05:35 +0100 Subject: Re: [Xen-devel] [PATCH, RFC 0/7] PCI multi-segment support From: Keir Fraser To: Jan Beulich , Ian Jackson Message-ID: Thread-Topic: [Xen-devel] [PATCH, RFC 0/7] PCI multi-segment support Thread-Index: Acxr1OGniQTFIRBYDEOgZdehj2Yy7w== In-Reply-To: <4E64EF860200007800054B03@nat28.tlf.novell.com> Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit Cc: "xen-devel@lists.xensource.com" X-BeenThere: xen-devel@lists.xensource.com X-Mailman-Version: 2.1.5 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xensource.com Errors-To: xen-devel-bounces@lists.xensource.com On 05/09/2011 14:49, "Jan Beulich" wrote: >>>> On 05.09.11 at 15:33, Keir Fraser wrote: >> On 05/09/2011 14:18, "Jan Beulich" wrote: >> >>>>>> On 25.08.11 at 16:54, "Jan Beulich" wrote: >>>> In order for Xen to be able to boot on systems with multiple PCI segments >>>> (also called domains), a number of changes are necessary to the >>>> hypervisor, the hypercall interface, the tools, and the Dom0 kernel, as >>>> in most code paths and definitions there were not even provisions for >>>> passing a segment number. >>>> >>>> The hypercall interface changes may need some discussion before >>>> applying the patches, in particular >>>> >>>> - whether the way PHYSDEVOP_map_pirq gets re-used is acceptable, >>>> or whether alternatively we should define a replacement one sub- >>>> hypercall >>>> - whether PHYSDEVOP_manage_pci_* should be deprecated >>>> - whether the bit assignments for the four uses of machine_bdf in >>>> the domctl interface can be re-defined >>> >>> No comment from either of you on the proposed changes? >> >> I'm personally fine with folding segment into the bus field. Otherwise we >> just end up with more compat cruft. >> >> I don't have an opinion on the PHYSDEVOP_manage_pci_* hypercalls. In fact I >> don't know much about them at all. >> >> I've always considered the domctl interface subject to change, but you don't >> seem to redefine anything that already exists? You just give meaning to bits >> 24-31 of an existing 32-bit parameter? > > I'm trying to avoid incompatible changes when possible (due to > out-of-tree consumers like libvirt, I think the intention is to maintain API compatibility for libxenlight, and have out-of-tree tool stacks/librariues build on top of that. I think there are libvirt bindings to libxenlight now, for example? My conclusion would be you can do the cleaner change to domctl. Interested in Ian Jackson's view however. -- Keir > and due to the hacks required to > use domctl interfaces from the kernel). Now here we need 16 bits, but > have two sets of 8 (at bottom and top), hence I'd favor doing an > incompatible change here (moving the bdf bits down to 0...15, and > using 16...31 for the segment), perhaps renaming the field to > machine_sbdf (to force compile-time noticing of the change at least > for those that actually use our headers). But as the odd bit assignment > could have other (hidden) reasons I coded things first to not do any > re-assignments. > > Jan > _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel From xen-devel-bounces@lists.xensource.com Mon Sep 05 07:46:31 2011 Return-path: Envelope-to: www-data@lists.xensource.com Delivery-date: Mon, 05 Sep 2011 07:46:31 -0700 Received: from localhost ([127.0.0.1] helo=lists.colo.xensource.com) by lists.xensource.com with esmtp (Exim 4.43) id 1R0aRT-0006bo-KH; Mon, 05 Sep 2011 07:46:31 -0700 Received: from mail216.messagelabs.com ([85.158.143.99]) by lists.xensource.com with esmtp (Exim 4.43) id 1R0aQf-0006P6-KF for xen-devel@lists.xensource.com; Mon, 05 Sep 2011 07:45:41 -0700 X-Env-Sender: dunlapg@gmail.com X-Msg-Ref: server-12.tower-216.messagelabs.com!1315233938!11395114!1 X-Originating-IP: [74.125.82.171] X-StarScan-Version: 6.3.6; banners=-,-,- X-VirusChecked: Checked Received: (qmail 10543 invoked from network); 5 Sep 2011 14:45:38 -0000 Received: from mail-wy0-f171.google.com (HELO mail-wy0-f171.google.com) (74.125.82.171) by server-12.tower-216.messagelabs.com with RC4-SHA encrypted SMTP; 5 Sep 2011 14:45:38 -0000 Received: by wyh13 with SMTP id 13so4988949wyh.30 for ; Mon, 05 Sep 2011 07:45:38 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=/ss1/DdWOVyXCN68lu+Rw5ko5FqpmUtG0yby7taePwg=; b=Ql2TJzAG+p9ueEiDoGB8Y8KL2symNRdYdjTJdusOGsPcU6obPm1/XxusW6Ked9tnXa 6vcok1f71wcSKrzrZNH+MNQqNIF2SajRk3T7uWSv3OABhxJihG/tdxX+/BAh26U7rHf9 Gu5aLm/3Jn33RP8Kslo+RAuCDt1RpjZLegm6g= MIME-Version: 1.0 Received: by 10.216.168.200 with SMTP id k50mr1713569wel.0.1315233938439; Mon, 05 Sep 2011 07:45:38 -0700 (PDT) Received: by 10.216.202.40 with HTTP; Mon, 5 Sep 2011 07:45:38 -0700 (PDT) In-Reply-To: References: Date: Mon, 5 Sep 2011 15:45:38 +0100 X-Google-Sender-Auth: ScIguV1sEYqzZzSr6e-pDI1frAI Message-ID: Subject: Re: [Xen-devel] determine the latency characteristics of a VM automatically From: George Dunlap To: David Xu Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: xen-devel X-BeenThere: xen-devel@lists.xensource.com X-Mailman-Version: 2.1.5 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xensource.com Errors-To: xen-devel-bounces@lists.xensource.com On Fri, Sep 2, 2011 at 5:27 PM, David Xu wrote: > Hi George, > Tow months ago, we talked about how to reduce the scheduling latency for = a > specific VM which runs a mixed workload, where the boost mechanism can no= t > works well. I have tried some methods to reduce the scheduling latency fo= r > some assumed latency-sensitive VMs and got some progress on it. Now I hop= e > to make it on demand. That is to say, I hope to get the scheduler to > determine the latency characteristics of a VM automatically. Since most t= ime > latency-sensitive operations are=A0initiated=A0with an interrupt, so a pe= nding > interrupt generally means that there is a latency sensitive operation > waiting to happen. I remember you said your idea was to have the schedule= r > look at the historical rate of interrupts and determine a preemption > timeslice based on those. I know your general idea, but could you talk mo= re > about it? What's more, I wonder if only the interrupts can infer the > workload type? In my opinion, a pending interrupt indicates there is a > operation to handle but may not be latency sensitive. Some common I/O > operation, e.g. http request for a web page or=A0=A0file=A0transmission, = would > also result in pending interrupt if the destination VM does not get > scheduled at the moment. But they are not latency sensitive. Of course, i= f > we can directly get some important information for distinguishing the > latency-sensitive workload from common workload, it is powerful and high > efficient. I am looking forward to your opinions and I hope I will not > disturb your work. Thanks. Cong, Thanks for your interest in this. My first comment is about latency-senstive. When I say "latency sensitive", I don't mean that the *user* cares about the time the operation takes to complete. (Although I would argue that the user does care about how long a web page takes to load.) I mean that the *algorithm* is affected by delays in processing. In the case of TCP for example (which will be involved both in the http fetch and the file transfer), the throughput will be significantly lower if the VM is not allowed to handle packets in a timely fashion. Regarding interrupts: the general idea was this. Suppose a VM gets interrupts every 6ms. And suppose that right now the system is busy enough that it can only get 50% of the cpu. Ideally, we want the VM to be able to run every time it gets an interrupt -- every 6ms. So in order to get 50% but still be able to run every 6ms, it needs to run for 3ms each time. So Xen should let it run for 3ms, then pre-empt it, and then when it gets another interrupt, pull it to the front of the queue and let it run again. That would be the desired "emergent" behavior of the algorithm (that is, how we would like the algorithm to behave on a large scale). But how to make a particular scheduling algorithm do that is the challenging part, and it would would depend on the algorithm. Were you thinking about trying to do this in credit2? The simple formula would be: runtime =3D (average interval between interrupts) * (%age of cpu the VM can expect to get). This might work just fine, or it might need refinement based on experience (as interrupts seem to me unlikely to come at nice even intervals). The first thing to try would be to figure out how to find the average recent interval between interrupts. An exact but perhaps inefficient way you could do this is keep a circular list of the last N interrupts with a timestamp of when they happened (say, the last 8), with a pointer to the oldest one. Then set avg_interval =3D (timestamp now - timestamp of oldest interrupt). Another way would be to have a "decaying average" function, where new_avg =3D last_interval * p + old_avg * (1-p). The harder thing would be to figure out what percentage of CPU the VM is likely to receive. That may be a bit tricky, and will depend a lot on which algorithm you're using. An easier thing we might try is not setting the rate per vcpu, but per pcpu. That is, when we assign a vcpu to a pcpu, we add its interrupt interval average to the pcpu interval interrupt average, and set the timeslice for that cpu accordingly. That would be fine when workloads are similar, but could cause problems if the workloads are very different. Thoughts? -George _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel From xen-devel-bounces@lists.xensource.com Mon Sep 05 07:56:49 2011 Return-path: Envelope-to: www-data@lists.xensource.com Delivery-date: Mon, 05 Sep 2011 07:56:49 -0700 Received: from localhost ([127.0.0.1] helo=lists.colo.xensource.com) by lists.xensource.com with esmtp (Exim 4.43) id 1R0abR-00076f-BU; Mon, 05 Sep 2011 07:56:49 -0700 Received: from mail182.messagelabs.com ([85.158.139.83]) by lists.xensource.com with esmtp (Exim 4.43) id 1R0aau-0006ud-Qy for xen-devel@lists.xensource.com; Mon, 05 Sep 2011 07:56:17 -0700 X-Env-Sender: dunlapg@gmail.com X-Msg-Ref: server-15.tower-182.messagelabs.com!1315234573!16116670!1 X-Originating-IP: [74.125.82.171] X-StarScan-Version: 6.3.6; banners=-,-,- X-VirusChecked: Checked Received: (qmail 9152 invoked from network); 5 Sep 2011 14:56:13 -0000 Received: from mail-wy0-f171.google.com (HELO mail-wy0-f171.google.com) (74.125.82.171) by server-15.tower-182.messagelabs.com with RC4-SHA encrypted SMTP; 5 Sep 2011 14:56:13 -0000 Received: by wyh13 with SMTP id 13so4997908wyh.30 for ; Mon, 05 Sep 2011 07:56:13 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=+6JOeYcN8H7Y4ujFcV7x6aBgCWRKvAy1z1CNLRG+4Gg=; b=xSvcc5RTuQ0t6SdA0vP+TmZyA8x+QI0klMH/+nxYIh9es+gbb8HqMoQGJHfMEAML75 U4QsUVjaTvhT0RJJ6ko26/HYM1J1AUkehVddNmY/Fs+3qeqP0Mnmy859I/Mkf57mSX6u 8JczSdgoRY5aNhGdzQsBro1tGJmiDcLcWDfaU= MIME-Version: 1.0 Received: by 10.216.169.75 with SMTP id m53mr1700642wel.55.1315234573560; Mon, 05 Sep 2011 07:56:13 -0700 (PDT) Received: by 10.216.202.40 with HTTP; Mon, 5 Sep 2011 07:56:13 -0700 (PDT) In-Reply-To: <4E64D9720200007800054A8A@nat28.tlf.novell.com> References: <4E64D9720200007800054A8A@nat28.tlf.novell.com> Date: Mon, 5 Sep 2011 15:56:13 +0100 X-Google-Sender-Auth: GhlQIY3uqfaoVUQ48yTIQSyx06k Message-ID: Subject: Re: [Xen-devel] [PATCH] xen, vtd: Fix device check for devices behind PCIe-to-PCI bridges From: George Dunlap To: Jan Beulich , Keir Fraser Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: xen-devel@lists.xensource.com X-BeenThere: xen-devel@lists.xensource.com X-Mailman-Version: 2.1.5 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xensource.com Errors-To: xen-devel-bounces@lists.xensource.com On Mon, Sep 5, 2011 at 1:15 PM, Jan Beulich wrote: >>>> On 01.09.11 at 16:20, George Dunlap wrot= e: >> On some systems, requests devices behind a PCIe-to-PCI bridge all >> appear to the IOMMU as though they come from from slot 0, function >> 0 on that device; so the mapping code much punch a hole for X:0.0 >> in the IOMMU for such devices. =A0When punching the hole, if that device >> has already been mapped once, we simply need to check ownership to >> make sure it's legal. =A0To do so, domain_context_mapping_one() will loo= k >> up the device for the mapping with pci_get_pdev() and look for the owner= . >> >> However, if there is no device in X:0.0, this look up will fail. > > Was it really that there was no device at all at X:0.0, or rather that > Xen just didn't know about the device (because Dom0 failed to notify > Xen, as could happen in the 2.6.18-derived trees up to pretty > recently)? Don't know for sure; this was a partner that turned this up through our beta-test program. But IIRC, running "lspci" in dom0 reported nothing under X:0.0 (although I may well be remembering incorrectly). This was for XenServer 6.0 which is using Novell's Xen-ified 2.6.32 kernel. > Also, didn't we sort of agree that creating a phantom device would > be more elegant (or at least much smaller a change)? I don't remember talking about that, but perhaps. :-) In reality, I don't know the code well enough to whip up a patch (like, where / how would I make such a device), and this is not that much of a priority for me. If this patch isn't accepted, it will probably fall to you or Keir (or some other sufficiently motivated party) to fix it. -George _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel From xen-devel-bounces@lists.xensource.com Mon Sep 05 08:32:11 2011 Return-path: Envelope-to: www-data@lists.xensource.com Delivery-date: Mon, 05 Sep 2011 08:32:11 -0700 Received: from localhost ([127.0.0.1] helo=lists.colo.xensource.com) by lists.xensource.com with esmtp (Exim 4.43) id 1R0b9e-00086i-Vv; Mon, 05 Sep 2011 08:32:11 -0700 Received: from mail27.messagelabs.com ([193.109.254.147]) by lists.xensource.com with esmtp (Exim 4.43) id 1R0b8w-0007t4-Fb for xen-devel@lists.xensource.com; Mon, 05 Sep 2011 08:31:26 -0700 X-Env-Sender: JBeulich@suse.com X-Msg-Ref: server-15.tower-27.messagelabs.com!1315236676!47475337!1 X-Originating-IP: [130.57.49.28] X-StarScan-Version: 6.3.6; banners=-,-,- X-VirusChecked: Checked Received: (qmail 6888 invoked from network); 5 Sep 2011 15:31:16 -0000 Received: from nat28.tlf.novell.com (HELO nat28.tlf.novell.com) (130.57.49.28) by server-15.tower-27.messagelabs.com with DHE-RSA-AES256-SHA encrypted SMTP; 5 Sep 2011 15:31:16 -0000 Received: from EMEA1-MTA by nat28.tlf.novell.com with Novell_GroupWise; Mon, 05 Sep 2011 16:31:23 +0100 Message-Id: <4E65077E0200007800054B6A@nat28.tlf.novell.com> X-Mailer: Novell GroupWise Internet Agent 8.0.1 Date: Mon, 05 Sep 2011 16:31:42 +0100 From: "Jan Beulich" To: "George Dunlap" Subject: Re: [Xen-devel] [PATCH] xen, vtd: Fix device check for devices behind PCIe-to-PCI bridges References: <4E64D9720200007800054A8A@nat28.tlf.novell.com> In-Reply-To: Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: quoted-printable Content-Disposition: inline Cc: Keir Fraser , xen-devel@lists.xensource.com, Allen M Kay X-BeenThere: xen-devel@lists.xensource.com X-Mailman-Version: 2.1.5 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xensource.com Errors-To: xen-devel-bounces@lists.xensource.com >>> On 05.09.11 at 16:56, George Dunlap = wrote: > On Mon, Sep 5, 2011 at 1:15 PM, Jan Beulich wrote: >>>>> On 01.09.11 at 16:20, George Dunlap = wrote: >>> On some systems, requests devices behind a PCIe-to-PCI bridge all >>> appear to the IOMMU as though they come from from slot 0, function >>> 0 on that device; so the mapping code much punch a hole for X:0.0 >>> in the IOMMU for such devices. When punching the hole, if that device >>> has already been mapped once, we simply need to check ownership to >>> make sure it's legal. To do so, domain_context_mapping_one() will = look >>> up the device for the mapping with pci_get_pdev() and look for the = owner. >>> >>> However, if there is no device in X:0.0, this look up will fail. >> >> Was it really that there was no device at all at X:0.0, or rather that >> Xen just didn't know about the device (because Dom0 failed to notify >> Xen, as could happen in the 2.6.18-derived trees up to pretty >> recently)? >=20 > Don't know for sure; this was a partner that turned this up through > our beta-test program. But IIRC, running "lspci" in dom0 reported > nothing under X:0.0 (although I may well be remembering incorrectly). >=20 > This was for XenServer 6.0 which is using Novell's Xen-ified 2.6.32 = kernel. >=20 >> Also, didn't we sort of agree that creating a phantom device would >> be more elegant (or at least much smaller a change)? >=20 > I don't remember talking about that, but perhaps. :-) >=20 > In reality, I don't know the code well enough to whip up a patch > (like, where / how would I make such a device), and this is not that > much of a priority for me. If this patch isn't accepted, it will > probably fall to you or Keir (or some other sufficiently motivated > party) to fix it. Understood. I'd be curious of Allen's thoughts here, as he would be the most knowledgeable one in this area. Jan _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel From xen-devel-bounces@lists.xensource.com Mon Sep 05 08:45:47 2011 Return-path: Envelope-to: www-data@lists.xensource.com Delivery-date: Mon, 05 Sep 2011 08:45:47 -0700 Received: from localhost ([127.0.0.1] helo=lists.colo.xensource.com) by lists.xensource.com with esmtp (Exim 4.43) id 1R0bMp-0000IN-J5; Mon, 05 Sep 2011 08:45:47 -0700 Received: from mail174.messagelabs.com ([85.158.138.51]) by lists.xensource.com with esmtp (Exim 4.43) id 1R0bMJ-00006I-UU for xen-devel@lists.xensource.com; Mon, 05 Sep 2011 08:45:16 -0700 X-Env-Sender: JBeulich@suse.com X-Msg-Ref: server-3.tower-174.messagelabs.com!1315237512!24246630!1 X-Originating-IP: [130.57.49.28] X-StarScan-Version: 6.3.6; banners=-,-,- X-VirusChecked: Checked Received: (qmail 22875 invoked from network); 5 Sep 2011 15:45:12 -0000 Received: from nat28.tlf.novell.com (HELO nat28.tlf.novell.com) (130.57.49.28) by server-3.tower-174.messagelabs.com with DHE-RSA-AES256-SHA encrypted SMTP; 5 Sep 2011 15:45:12 -0000 Received: from EMEA1-MTA by nat28.tlf.novell.com with Novell_GroupWise; Mon, 05 Sep 2011 16:45:11 +0100 Message-Id: <4E650ABB0200007800054B8A@nat28.tlf.novell.com> X-Mailer: Novell GroupWise Internet Agent 8.0.1 Date: Mon, 05 Sep 2011 16:45:31 +0100 From: "Jan Beulich" To: "xen-devel@lists.xensource.com" Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: quoted-printable Content-Disposition: inline Subject: [Xen-devel] [PATCH] bitmap_scnlistprintf() should always zero-terminate its output buffer X-BeenThere: xen-devel@lists.xensource.com X-Mailman-Version: 2.1.5 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xensource.com Errors-To: xen-devel-bounces@lists.xensource.com ... as long as it has non-zero size. So far this would not happen if the passed in CPU mask was empty. Also fix the comment describing the return value to actually match reality. Signed-off-by: Jan Beulich --- a/xen/common/bitmap.c +++ b/xen/common/bitmap.c @@ -363,9 +363,8 @@ static inline int bscnl_emit(char *buf,=20 * the range. Output format is compatible with the format * accepted as input by bitmap_parselist(). * - * The return value is the number of characters which would be - * generated for the given input, excluding the trailing '\0', as - * per ISO C99. + * The return value is the number of characters which were output, + * excluding the trailing '\0'. */ int bitmap_scnlistprintf(char *buf, unsigned int buflen, const unsigned long *maskp, int nmaskbits) @@ -383,6 +382,8 @@ int bitmap_scnlistprintf(char *buf, unsi rbot =3D cur; } } + if (!len && buflen) + *buf =3D 0; return len; } EXPORT_SYMBOL(bitmap_scnlistprintf); _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel From xen-devel-bounces@lists.xensource.com Mon Sep 05 08:49:38 2011 Return-path: Envelope-to: www-data@lists.xensource.com Delivery-date: Mon, 05 Sep 2011 08:49:38 -0700 Received: from localhost ([127.0.0.1] helo=lists.colo.xensource.com) by lists.xensource.com with esmtp (Exim 4.43) id 1R0bQW-0001Nf-RX; Mon, 05 Sep 2011 08:49:37 -0700 Received: from mail174.messagelabs.com ([85.158.138.51]) by lists.xensource.com with esmtp (Exim 4.43) id 1R0bOn-0000se-6x for xen-devel@lists.xensource.com; Mon, 05 Sep 2011 08:47:50 -0700 X-Env-Sender: JBeulich@suse.com X-Msg-Ref: server-5.tower-174.messagelabs.com!1315237665!26613998!1 X-Originating-IP: [130.57.49.28] X-StarScan-Version: 6.3.6; banners=-,-,- X-VirusChecked: Checked Received: (qmail 8008 invoked from network); 5 Sep 2011 15:47:45 -0000 Received: from nat28.tlf.novell.com (HELO nat28.tlf.novell.com) (130.57.49.28) by server-5.tower-174.messagelabs.com with DHE-RSA-AES256-SHA encrypted SMTP; 5 Sep 2011 15:47:45 -0000 Received: from EMEA1-MTA by nat28.tlf.novell.com with Novell_GroupWise; Mon, 05 Sep 2011 16:47:45 +0100 Message-Id: <4E650B550200007800054B8E@nat28.tlf.novell.com> X-Mailer: Novell GroupWise Internet Agent 8.0.1 Date: Mon, 05 Sep 2011 16:48:05 +0100 From: "Jan Beulich" To: "xen-devel@lists.xensource.com" Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="=__Part88A7AF25.0__=" Subject: [Xen-devel] [PATCH] x86: remove unnecessary indirection from irq_complete_move()'s sole parameter X-BeenThere: xen-devel@lists.xensource.com X-Mailman-Version: 2.1.5 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xensource.com Errors-To: xen-devel-bounces@lists.xensource.com This is a MIME message. If you are reading this text, you may want to consider changing to a mail reader or gateway that understands how to properly handle MIME multipart messages. --=__Part88A7AF25.0__= Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: quoted-printable Content-Disposition: inline Signed-off-by: Jan Beulich --- a/xen/arch/x86/hpet.c +++ b/xen/arch/x86/hpet.c @@ -296,7 +296,7 @@ static void hpet_msi_ack(unsigned int ir { struct irq_desc *desc =3D irq_to_desc(irq); =20 - irq_complete_move(&desc); + irq_complete_move(desc); move_native_irq(irq); ack_APIC_irq(); } --- a/xen/arch/x86/io_apic.c +++ b/xen/arch/x86/io_apic.c @@ -513,9 +513,8 @@ static void send_cleanup_vector(struct i cfg->move_in_progress =3D 0; } =20 -void irq_complete_move(struct irq_desc **descp) +void irq_complete_move(struct irq_desc *desc) { - struct irq_desc *desc =3D *descp; struct irq_cfg *cfg =3D desc->chip_data; unsigned vector, me; =20 @@ -1564,7 +1563,7 @@ static void ack_edge_ioapic_irq(unsigned { struct irq_desc *desc =3D irq_to_desc(irq); =20 - irq_complete_move(&desc); + irq_complete_move(desc); move_native_irq(irq); =20 if ((desc->status & (IRQ_PENDING | IRQ_DISABLED)) @@ -1643,7 +1642,7 @@ static void mask_and_ack_level_ioapic_ir int i; struct irq_desc *desc =3D irq_to_desc(irq); =20 - irq_complete_move(&desc); + irq_complete_move(desc); =20 if ( ioapic_ack_new ) return; @@ -1816,7 +1815,7 @@ static void ack_msi_irq(unsigned int irq { struct irq_desc *desc =3D irq_to_desc(irq); =20 - irq_complete_move(&desc); + irq_complete_move(desc); move_native_irq(irq); =20 if ( msi_maskable_irq(desc->msi_desc) ) --- a/xen/drivers/passthrough/amd/iommu_init.c +++ b/xen/drivers/passthrough/amd/iommu_init.c @@ -424,7 +424,7 @@ static void iommu_msi_mask(unsigned int=20 struct amd_iommu *iommu =3D irq_to_iommu[irq]; struct irq_desc *desc =3D irq_to_desc(irq); =20 - irq_complete_move(&desc); + irq_complete_move(desc); =20 /* FIXME: do not support mask bits at the moment */ if ( iommu->maskbit ) --- a/xen/drivers/passthrough/vtd/iommu.c +++ b/xen/drivers/passthrough/vtd/iommu.c @@ -957,7 +957,7 @@ static void dma_msi_mask(unsigned int ir struct iommu *iommu =3D irq_to_iommu[irq]; struct irq_desc *desc =3D irq_to_desc(irq); =20 - irq_complete_move(&desc); + irq_complete_move(desc); =20 /* mask it */ spin_lock_irqsave(&iommu->register_lock, flags); --- a/xen/include/asm-x86/irq.h +++ b/xen/include/asm-x86/irq.h @@ -148,7 +148,7 @@ int create_irq(void); void destroy_irq(unsigned int irq); =20 struct irq_desc; -extern void irq_complete_move(struct irq_desc **descp); +extern void irq_complete_move(struct irq_desc *); =20 extern struct irq_desc *irq_desc; =20 --=__Part88A7AF25.0__= Content-Type: text/plain; name="x86-irq_complete_move.patch" Content-Transfer-Encoding: quoted-printable Content-Disposition: attachment; filename="x86-irq_complete_move.patch" Signed-off-by: Jan Beulich =0A=0A--- a/xen/arch/x86/hpet= .c=0A+++ b/xen/arch/x86/hpet.c=0A@@ -296,7 +296,7 @@ static void hpet_msi_a= ck(unsigned int ir=0A {=0A struct irq_desc *desc =3D irq_to_desc(irq);= =0A =0A- irq_complete_move(&desc);=0A+ irq_complete_move(desc);=0A = move_native_irq(irq);=0A ack_APIC_irq();=0A }=0A--- a/xen/arch/x86/io= _apic.c=0A+++ b/xen/arch/x86/io_apic.c=0A@@ -513,9 +513,8 @@ static void = send_cleanup_vector(struct i=0A cfg->move_in_progress =3D 0;=0A }=0A = =0A-void irq_complete_move(struct irq_desc **descp)=0A+void irq_complete_mo= ve(struct irq_desc *desc)=0A {=0A- struct irq_desc *desc =3D *descp;=0A = struct irq_cfg *cfg =3D desc->chip_data;=0A unsigned vector, = me;=0A =0A@@ -1564,7 +1563,7 @@ static void ack_edge_ioapic_irq(unsigned=0A= {=0A struct irq_desc *desc =3D irq_to_desc(irq);=0A =0A- = irq_complete_move(&desc);=0A+ irq_complete_move(desc);=0A move_nativ= e_irq(irq);=0A =0A if ((desc->status & (IRQ_PENDING | IRQ_DISABLED))=0A= @@ -1643,7 +1642,7 @@ static void mask_and_ack_level_ioapic_ir=0A int = i;=0A struct irq_desc *desc =3D irq_to_desc(irq);=0A =0A- irq_comple= te_move(&desc);=0A+ irq_complete_move(desc);=0A =0A if ( ioapic_ack_= new )=0A return;=0A@@ -1816,7 +1815,7 @@ static void ack_msi_irq(un= signed int irq=0A {=0A struct irq_desc *desc =3D irq_to_desc(irq);=0A = =0A- irq_complete_move(&desc);=0A+ irq_complete_move(desc);=0A = move_native_irq(irq);=0A =0A if ( msi_maskable_irq(desc->msi_desc) = )=0A--- a/xen/drivers/passthrough/amd/iommu_init.c=0A+++ b/xen/drivers/pass= through/amd/iommu_init.c=0A@@ -424,7 +424,7 @@ static void iommu_msi_mask(u= nsigned int =0A struct amd_iommu *iommu =3D irq_to_iommu[irq];=0A = struct irq_desc *desc =3D irq_to_desc(irq);=0A =0A- irq_complete_move(&d= esc);=0A+ irq_complete_move(desc);=0A =0A /* FIXME: do not support = mask bits at the moment */=0A if ( iommu->maskbit )=0A--- a/xen/drivers= /passthrough/vtd/iommu.c=0A+++ b/xen/drivers/passthrough/vtd/iommu.c=0A@@ = -957,7 +957,7 @@ static void dma_msi_mask(unsigned int ir=0A struct = iommu *iommu =3D irq_to_iommu[irq];=0A struct irq_desc *desc =3D = irq_to_desc(irq);=0A =0A- irq_complete_move(&desc);=0A+ irq_complete_= move(desc);=0A =0A /* mask it */=0A spin_lock_irqsave(&iommu->regis= ter_lock, flags);=0A--- a/xen/include/asm-x86/irq.h=0A+++ b/xen/include/asm= -x86/irq.h=0A@@ -148,7 +148,7 @@ int create_irq(void);=0A void destroy_irq(= unsigned int irq);=0A =0A struct irq_desc;=0A-extern void irq_complete_move= (struct irq_desc **descp);=0A+extern void irq_complete_move(struct = irq_desc *);=0A =0A extern struct irq_desc *irq_desc;=0A =0A --=__Part88A7AF25.0__= Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel --=__Part88A7AF25.0__=-- From xen-devel-bounces@lists.xensource.com Mon Sep 05 09:17:17 2011 Return-path: Envelope-to: www-data@lists.xensource.com Delivery-date: Mon, 05 Sep 2011 09:17:17 -0700 Received: from localhost ([127.0.0.1] helo=lists.colo.xensource.com) by lists.xensource.com with esmtp (Exim 4.43) id 1R0brJ-00067A-2P; Mon, 05 Sep 2011 09:17:17 -0700 Received: from mail216.messagelabs.com ([85.158.143.99]) by lists.xensource.com with esmtp (Exim 4.43) id 1R0bqh-0005uW-Ch for xen-devel@lists.xensource.com; Mon, 05 Sep 2011 09:16:43 -0700 X-Env-Sender: martin4meier@googlemail.com X-Msg-Ref: server-8.tower-216.messagelabs.com!1315239394!15669212!1 X-Originating-IP: [74.125.82.65] X-StarScan-Version: 6.3.6; banners=-,-,- X-VirusChecked: Checked Received: (qmail 16939 invoked from network); 5 Sep 2011 16:16:35 -0000 Received: from mail-ww0-f65.google.com (HELO mail-ww0-f65.google.com) (74.125.82.65) by server-8.tower-216.messagelabs.com with RC4-SHA encrypted SMTP; 5 Sep 2011 16:16:35 -0000 Received: by wwf10 with SMTP id 10so812868wwf.0 for ; Mon, 05 Sep 2011 09:16:34 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlemail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; bh=9bRrlRhgyOdEWbgzcL9J9/db/l453laNRPmAZcDxecM=; b=Z6cycOvh529eraqfWqsIqZXt8nz5cW5CO3oQoLq3mI3oaN/piyvPVxrg01rLeYHs9F bl9QBtIW8wL58xJwmFj3bKDrveTONYrASRESynv7nx2FNvkriThr04YdjbXc3sDVfXgB Tnf/HqDGf1XLR92ALO1vcXQ5zCHviNfQ27h6s= MIME-Version: 1.0 Received: by 10.216.179.140 with SMTP id h12mr196860wem.45.1315239394014; Mon, 05 Sep 2011 09:16:34 -0700 (PDT) Received: by 10.216.179.11 with HTTP; Mon, 5 Sep 2011 09:16:33 -0700 (PDT) In-Reply-To: <20110829193630.GA15116@dumpdata.com> References: <20110829193630.GA15116@dumpdata.com> Date: Mon, 5 Sep 2011 18:16:33 +0200 Message-ID: Subject: Re: [Xen-devel] Intel IGP VGA-passthrough to Ubuntu 11.04/openSUSE domU doesn't quite work From: Martin Meier To: Konrad Rzeszutek Wilk Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: intel-gfx@lists.freedesktop.org, xen-devel@lists.xensource.com X-BeenThere: xen-devel@lists.xensource.com X-Mailman-Version: 2.1.5 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xensource.com Errors-To: xen-devel-bounces@lists.xensource.com On Mon, Aug 29, 2011 at 9:36 PM, Konrad Rzeszutek Wilk wrote: > On Mon, Aug 29, 2011 at 05:50:23PM +0200, Martin Meier wrote: >> Hi, >> when comparing the dmesgs from a Ubuntu 11.04+xorg-edgers-ppa running on= real >> hardware ver. running in a HVM-domU, I see this change in dmesg: >> >> real: >> [ =A0 =A02.306326] [drm:intel_wait_for_vblank], vblank wait timed out >> [ =A0 =A02.307140] [drm:gen6_fdi_link_train], FDI_RX_IIR 0x700 >> [ =A0 =A02.307143] [drm:gen6_fdi_link_train], FDI train 1 done. >> [ =A0 =A02.307798] [drm:gen6_fdi_link_train], FDI_RX_IIR 0x600 >> [ =A0 =A02.307801] [drm:gen6_fdi_link_train], FDI train 2 done. >> [ =A0 =A02.307802] [drm:gen6_fdi_link_train], FDI train done. >> >> domU: [..] >> [ =A0 =A03.661137] [drm:gen6_fdi_link_train], FDI_RX_IIR 0x0 >> [ =A0 =A03.661140] [drm:gen6_fdi_link_train] *ERROR* FDI train 2 fail! >> [ =A0 =A03.661142] [drm:gen6_fdi_link_train], FDI train done. Hm, this might be a symptom of an earlier error in the boot process I hadn't noticed last week: real: i915 0000:00:02.0: setting latency timer to 64 [drm:intel_opregion_setup], graphic opregion physical addr: 0xbc8d6018 [drm:intel_opregion_setup], Public ACPI methods supported [drm:intel_opregion_setup], SWSCI supported [drm:intel_opregion_setup], ASLE supported [drm:intel_detect_pch], Found CougarPoint PCH [drm:intel_parse_bios], Using VBT from OpRegion: $VBT SNB/IVB-DESKTOPd domU. i915 0000:00:02.0: setting latency timer to 64 [drm:intel_opregion_setup], graphic opregion physical addr: 0xbc8d6018 drm:intel_opregion_setup], opregion signature mismatch i915 0000:00:02.0: irq 64 for MSI/MSI-X [drm] Supports vblank timestamp caching Rev 1 (10.10.2010). [drm] Driver supports precise vblank timestamp query. [drm:parse_general_definitions], crt_ddc_bus_pin: 5 By searching for "opregion signature mismatch" I found in intel_opregion.c: #define OPREGION_SIGNATURE "IntelGraphicsMem" [..] pci_read_config_dword(dev->pdev, PCI_ASLS, &asls); DRM_DEBUG_DRIVER("graphic opregion physical addr: 0x%x\n", asls); if (asls =3D=3D 0) { DRM_DEBUG_DRIVER("ACPI OpRegion not supported!\n"); return -ENOTSUPP; } base =3D acpi_os_ioremap(asls, OPREGION_SIZE); if (!base) return -ENOMEM; if (memcmp(base, OPREGION_SIGNATURE, 16)) { DRM_DEBUG_DRIVER("opregion signature mismatch\n"); err =3D -EINVAL; goto err_out; } On the xen side(/var/log/xen/qemu-dm-domU.log) I see: register_vga_regions: register_vga: igd_opregion =3D bc8d6018 dm-command: hot insert pass-through pci dev register_real_device: Assigning real physical device 00:02.0 ... pt_iomul_init: Error: pt_iomul_init can't open file /dev/xen/pci_iomul: No such file or directory: 0x0:0x2.0x0 pt_register_regions: IO region registered (size=3D0x00400000 base_addr=3D0x= fe000004) pt_register_regions: IO region registered (size=3D0x10000000 base_addr=3D0x= d000000c) pt_register_regions: IO region registered (size=3D0x00000040 base_addr=3D0x= 0000f001) register_vga_regions: register_vga: igd_opregion =3D bc8d6018 pt_msi_setup: msi mapped with pirq 37 pci_intx: intx=3D1 register_real_device: Real physical device 00:02.0 registered successfuly! IRQ type =3D MSI-INTx igd_pci_read: pci_config_read: 0:0.0: addr=3D0 len=3D2 val=3Dffff8086 igd_pci_read: pci_config_read: 0:0.0: addr=3D2 len=3D2 val=3Dffff0100 pt_iomem_map: e_phys=3De0000000 maddr=3Dd0000000 type=3D8 len=3D268435456 index=3D2 first_map=3D1 pt_iomem_map: e_phys=3Df1000000 maddr=3Dfe000000 type=3D0 len=3D4194304 index=3D0 first_map=3D1 pt_ioport_map: e_phys=3Dc100 pio_base=3Df000 len=3D64 index=3D4 first_map= =3D1 igd_pci_read: pci_config_read: 0:0.0: addr=3D0 len=3D2 val=3Dffff8086 igd_pci_read: pci_config_read: 0:0.0: addr=3D2 len=3D2 val=3Dffff0100 Is "can't open file /dev/xen/pci_iomul" a real problem? I'm not sure where to go from here... >> Hardware: >> DQ67SW (vt-d enabled) >> i5 2400 >> Display connected via DVI-D / DVI-I+VGA adapter >> >> Software: >> domU kernel: 3.1.0-rc3 x86 32 bit >> dom0 kernel: 3.0.3 >> (git://git.kernel.org/pub/scm/linux/kernel/git/konrad/xen.git) x86_64 > > An you have CONFIG_DMAR enabled? Yes, CONFIG_DMAR is set to 'y' for the dom0. _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel From xen-devel-bounces@lists.xensource.com Mon Sep 05 10:44:25 2011 Return-path: Envelope-to: www-data@lists.xensource.com Delivery-date: Mon, 05 Sep 2011 10:44:25 -0700 Received: from localhost ([127.0.0.1] helo=lists.colo.xensource.com) by lists.xensource.com with esmtp (Exim 4.43) id 1R0dDd-0000yn-6D; Mon, 05 Sep 2011 10:44:25 -0700 Received: from mail27.messagelabs.com ([193.109.254.147]) by lists.xensource.com with smtp (Exim 4.43) id 1R0dCm-0000lx-0V for xen-devel@lists.xensource.com; Mon, 05 Sep 2011 10:43:33 -0700 X-Env-Sender: stefan.bader@canonical.com X-Msg-Ref: server-14.tower-27.messagelabs.com!1315244596!34853740!1 X-Originating-IP: [91.189.89.112] X-StarScan-Version: 6.3.6; banners=-,-,- X-VirusChecked: Checked Received: (qmail 20401 invoked from network); 5 Sep 2011 17:43:16 -0000 Received: from youngberry.canonical.com (HELO youngberry.canonical.com) (91.189.89.112) by server-14.tower-27.messagelabs.com with SMTP; 5 Sep 2011 17:43:16 -0000 Received: from 216-31-241-140.static-ip.telepacific.net ([216.31.241.140] helo=[192.168.1.112]) by youngberry.canonical.com with esmtpsa (TLS1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.71) (envelope-from ) id 1R0dCc-00021B-Az; Mon, 05 Sep 2011 17:43:22 +0000 Message-ID: <4E650A3B.3020602@canonical.com> Date: Mon, 05 Sep 2011 17:43:23 +0000 From: Stefan Bader User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.2.20) Gecko/20110805 Lightning/1.0b2 Thunderbird/3.1.12 MIME-Version: 1.0 To: Stefano Stabellini Subject: Re: [Xen-devel] Re: HVM guests and pvlocks not working as expected References: <4E5F5B12.4080206@canonical.com> In-Reply-To: X-Enigmail-Version: 1.1.2 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: Jeremy Fitzhardinge , "xen-devel@lists.xensource.com" X-BeenThere: xen-devel@lists.xensource.com X-Mailman-Version: 2.1.5 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xensource.com Errors-To: xen-devel-bounces@lists.xensource.com On 02.09.2011 17:34, Stefano Stabellini wrote: > On Fri, 2 Sep 2011, Stefano Stabellini wrote: >> On Thu, 1 Sep 2011, Stefan Bader wrote: >>> After much joy with this, I thought I post this to a bigger audience. After >>> having migrated to Xen 4.1.1, booting HVM guests had several issues. Some >>> related to interrupts not being set up correctly (which Stefano has posted >>> patches) and even with those 3.0 guests seem to hang for me while 2.6.38 or >>> older kernels were ok. >>> >>> After digging deeply into this, I think I found the issue. However, if that is >>> true, it seems rather lucky if pv spinlocks in HVM worked for anybody. >>> >>> The xen_hvm_smp_init() call will change the smp_ops hooks. One of which is >>> smp_prepare_cpus. This is done in start_kernel and at this point in time, there >>> is no change to the pv_lock_ops and they point to the ticket versions. >>> Later in start_kernel, check_bugs is called and part of that takes the >>> pv_lock_ops and patches the kernel with the correct jumps. >>> _After_ that, the kernel_init is called and that in turn does the >>> smp_prepare_cpus which now changes the pv_lock_ops again, *but not* run any >>> patching again. So the _raw_spin_*lock calls still use the ticket calls. >>> >>> start_kernel >>> setup_arch -> xen_hvm_smp_init (set smp_ops) >>> ... >>> check_bugs -> alternative_instructions (patches pv_locks sites) >>> ... >>> rest_init (triggers kernel_init as a thread) >>> kernel_init >>> ... >>> smp_prepare_cpus (calls xen_init_spinlocks through smp_ops hook) >>> >>> To make things even more fun, there is the possibility that some spinlock >>> functions are forced to be inlined and others are not (CONFIG_INLINE_SPIN_*). In >>> our special case only two versions of spin_unlock were inlined. Put that >>> together into a pot with modules, shake well, and there is the fun. Basically on >>> load time, the non-inline calls remain pointing to the unmodified ticket >>> implementation (main kernel). But the unlock calls (which are inlined) get >>> modified because the loaded module gets patched up. One can imagine that this >>> does not work too well. >>> >>> Anyway, even without the secondary issue, I am sure that just replacing the >>> functions in pv_lock_ops without the spinlock calls getting actually modified is >>> not the intended behaviour. >>> >>> Unfortunately I have not yet been able to make it work. Any attempt to move >>> xen_init_spinlocks to be called before check_bugs or adding a call to >>> alternative_instructions results in another hang on boot. At least the latter >>> method results in a more usable dump for crash, which shows that on spinlock was >>> taken (slow) and two spurious taken ones (this is more to play for me). >>> >>> But then, maybe someone has some ideas there... >> >> we have two possible ways to solve this problem: >> >> 1) we wait for Jeremy's pv ticketlock series to be applied, that should >> make the datastructure internally used by native ticketlock and pv >> tickerlock identical, so a lock taken by the native ticket spin lock >> function can be freed by the xen pv ticket spin unlock function. > > this simple patch is enough to make pv ticketlocks work correctly on > top of Jeremy's pv ticketlocks series > (cover.1314922370.git.jeremy.fitzhardinge@citrix.com): > Right, given that the switch to (or actually patching the code the first time) ticket spinlock happens after the arch setup has been done, it sounds reasonable to assume that no spinlock has been used, yet. Just when I did this without the ticketlocks patches from Jeremy it failed. I will try it again with them. Just with Plumbers and some other stuff this week I don't know how quickly I can do that. -Stefan > --- > > xen: initialize PV spinlocks before patching is done > > Signed-off-by: Stefano Stabellini > > diff --git a/arch/x86/xen/smp.c b/arch/x86/xen/smp.c > index 3061244..04a84e8 100644 > --- a/arch/x86/xen/smp.c > +++ b/arch/x86/xen/smp.c > @@ -518,7 +518,6 @@ static void __init xen_hvm_smp_prepare_cpus(unsigned int max_cpus) > if (!xen_have_vector_callback) > return; > xen_init_lock_cpu(0); > - xen_init_spinlocks(); > } > > static int __cpuinit xen_hvm_cpu_up(unsigned int cpu) > @@ -546,4 +545,5 @@ void __init xen_hvm_smp_init(void) > smp_ops.cpu_die = xen_hvm_cpu_die; > smp_ops.send_call_func_ipi = xen_smp_send_call_function_ipi; > smp_ops.send_call_func_single_ipi = xen_smp_send_call_function_single_ipi; > + xen_init_spinlocks(); > } > > _______________________________________________ > Xen-devel mailing list > Xen-devel@lists.xensource.com > http://lists.xensource.com/xen-devel _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel From xen-devel-bounces@lists.xensource.com Mon Sep 05 12:33:37 2011 Return-path: Envelope-to: www-data@lists.xensource.com Delivery-date: Mon, 05 Sep 2011 12:33:37 -0700 Received: from localhost ([127.0.0.1] helo=lists.colo.xensource.com) by lists.xensource.com with esmtp (Exim 4.43) id 1R0evJ-00046l-D6; Mon, 05 Sep 2011 12:33:37 -0700 Received: from mail174.messagelabs.com ([85.158.138.51]) by lists.xensource.com with smtp (Exim 4.43) id 1R0euj-0003tc-4U for xen-devel@lists.xensource.com; Mon, 05 Sep 2011 12:33:01 -0700 X-Env-Sender: Ian.Jackson@eu.citrix.com X-Msg-Ref: server-5.tower-174.messagelabs.com!1315251178!26632588!1 X-Originating-IP: [62.200.22.115] X-StarScan-Version: 6.3.6; banners=-,-,- X-VirusChecked: Checked Received: (qmail 24869 invoked from network); 5 Sep 2011 19:32:58 -0000 Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115) by server-5.tower-174.messagelabs.com with SMTP; 5 Sep 2011 19:32:58 -0000 X-IronPort-AV: E=Sophos;i="4.68,335,1312156800"; d="scan'208";a="7611905" Received: from lonpmailmx01.citrite.net ([10.30.203.162]) by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5; 05 Sep 2011 19:32:57 +0000 Received: from woking.xci-test.com (10.80.248.135) by smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id 8.3.137.0; Mon, 5 Sep 2011 20:32:57 +0100 Received: from osstest by woking.xci-test.com with local (Exim 4.69) (envelope-from ) id 1R0eue-00061A-EF; Mon, 05 Sep 2011 20:32:56 +0100 To: xen-devel@lists.xensource.com Message-ID: From: xen.org Date: Mon, 5 Sep 2011 20:32:56 +0100 MIME-Version: 1.0 Content-Type: text/plain Cc: ian.jackson@eu.citrix.com Subject: [Xen-devel] [xen-unstable test] 8830: tolerable FAIL - PUSHED X-BeenThere: xen-devel@lists.xensource.com X-Mailman-Version: 2.1.5 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xensource.com Errors-To: xen-devel-bounces@lists.xensource.com flight 8830 xen-unstable real [real] http://www.chiark.greenend.org.uk/~xensrcts/logs/8830/ Failures :-/ but no regressions. Tests which did not succeed, but are not blocking, including regressions (tests previously passed) regarded as allowable: test-amd64-amd64-xl-pcipt-intel 9 guest-start fail never pass test-amd64-i386-rhel6hvm-intel 9 guest-start.2 fail never pass test-amd64-i386-win-vcpus1 16 leak-check/check fail never pass test-amd64-i386-xl-win-vcpus1 13 guest-stop fail never pass test-amd64-i386-rhel6hvm-amd 9 guest-start.2 fail never pass test-amd64-i386-win 16 leak-check/check fail never pass test-amd64-amd64-win 16 leak-check/check fail never pass test-amd64-amd64-xl-win 13 guest-stop fail never pass test-i386-i386-xl-win 13 guest-stop fail never pass test-i386-i386-win 16 leak-check/check fail never pass version targeted for testing: xen 0268e7380953 baseline version: xen f1349a968a5a ------------------------------------------------------------ People who touched revisions under test: Andrew Cooper George Dunlap Ian Jackson Keir Fraser Olaf Hering ------------------------------------------------------------ jobs: build-amd64 pass build-i386 pass build-amd64-oldkern pass build-i386-oldkern pass build-amd64-pvops pass build-i386-pvops pass test-amd64-amd64-xl pass test-amd64-i386-xl pass test-i386-i386-xl pass test-amd64-i386-rhel6hvm-amd fail test-amd64-i386-xl-credit2 pass test-amd64-amd64-xl-pcipt-intel fail test-amd64-i386-rhel6hvm-intel fail test-amd64-i386-xl-multivcpu pass test-amd64-amd64-pair pass test-amd64-i386-pair pass test-i386-i386-pair pass test-amd64-amd64-pv pass test-amd64-i386-pv pass test-i386-i386-pv pass test-amd64-amd64-xl-sedf pass test-amd64-i386-win-vcpus1 fail test-amd64-i386-xl-win-vcpus1 fail test-amd64-amd64-win fail test-amd64-i386-win fail test-i386-i386-win fail test-amd64-amd64-xl-win fail test-i386-i386-xl-win fail ------------------------------------------------------------ sg-report-flight on woking.cam.xci-test.com logs: /home/xc_osstest/logs images: /home/xc_osstest/images Logs, config files, etc. are available at http://www.chiark.greenend.org.uk/~xensrcts/logs Test harness code can be found at http://xenbits.xensource.com/gitweb?p=osstest.git;a=summary Pushing revision : + branch=xen-unstable + revision=0268e7380953 + . cri-lock-repos ++ . cri-common +++ umask 002 +++ getconfig Repos +++ perl -e ' use Osstest; readconfigonly(); print $c{Repos} or die $!; ' ++ repos=/export/home/osstest/repos ++ repos_lock=/export/home/osstest/repos/lock ++ '[' x '!=' x/export/home/osstest/repos/lock ']' ++ OSSTEST_REPOS_LOCK_LOCKED=/export/home/osstest/repos/lock ++ exec with-lock-ex -w /export/home/osstest/repos/lock ./ap-push xen-unstable 0268e7380953 + branch=xen-unstable + revision=0268e7380953 + . cri-lock-repos ++ . cri-common +++ umask 002 +++ getconfig Repos +++ perl -e ' use Osstest; readconfigonly(); print $c{Repos} or die $!; ' ++ repos=/export/home/osstest/repos ++ repos_lock=/export/home/osstest/repos/lock ++ '[' x/export/home/osstest/repos/lock '!=' x/export/home/osstest/repos/lock ']' + : xen@xenbits.xensource.com + : xen@xenbits.xensource.com:git/linux-pvops + : master + : tested/2.6.39.x + case "$branch" in + cd /export/home/osstest/repos/xen-unstable.hg + hg push -r 0268e7380953 ssh://xen@xenbits.xensource.com/HG/xen-unstable.hg pushing to ssh://xen@xenbits.xensource.com/HG/xen-unstable.hg searching for changes remote: adding changesets remote: adding manifests remote: adding file changes remote: added 7 changesets with 20 changes to 12 files _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel From xen-devel-bounces@lists.xensource.com Mon Sep 05 20:35:23 2011 Return-path: Envelope-to: www-data@lists.xensource.com Delivery-date: Mon, 05 Sep 2011 20:35:23 -0700 Received: from localhost ([127.0.0.1] helo=lists.colo.xensource.com) by lists.xensource.com with esmtp (Exim 4.43) id 1R0mRX-0007Y9-QQ; Mon, 05 Sep 2011 20:35:23 -0700 Received: from mail182.messagelabs.com ([85.158.139.83]) by lists.xensource.com with smtp (Exim 4.43) id 1R0mQo-0007LE-RV for xen-devel@lists.xensource.com; Mon, 05 Sep 2011 20:34:39 -0700 X-Env-Sender: Ian.Jackson@eu.citrix.com X-Msg-Ref: server-2.tower-182.messagelabs.com!1315280075!16173594!1 X-Originating-IP: [62.200.22.115] X-StarScan-Version: 6.3.6; banners=-,-,- X-VirusChecked: Checked Received: (qmail 16579 invoked from network); 6 Sep 2011 03:34:35 -0000 Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115) by server-2.tower-182.messagelabs.com with SMTP; 6 Sep 2011 03:34:35 -0000 X-IronPort-AV: E=Sophos;i="4.68,336,1312156800"; d="scan'208";a="7614341" Received: from lonpmailmx01.citrite.net ([10.30.203.162]) by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5; 06 Sep 2011 03:34:35 +0000 Received: from woking.xci-test.com (10.80.248.135) by smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id 8.3.137.0; Tue, 6 Sep 2011 04:34:35 +0100 Received: from osstest by woking.xci-test.com with local (Exim 4.69) (envelope-from ) id 1R0mQl-0003YX-Ah; Tue, 06 Sep 2011 04:34:35 +0100 To: xen-devel@lists.xensource.com Message-ID: From: xen.org Date: Tue, 6 Sep 2011 04:34:35 +0100 MIME-Version: 1.0 Content-Type: text/plain Cc: ian.jackson@eu.citrix.com Subject: [Xen-devel] [xen-unstable test] 8831: tolerable FAIL X-BeenThere: xen-devel@lists.xensource.com X-Mailman-Version: 2.1.5 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xensource.com Errors-To: xen-devel-bounces@lists.xensource.com flight 8831 xen-unstable real [real] http://www.chiark.greenend.org.uk/~xensrcts/logs/8831/ Failures :-/ but no regressions. Tests which did not succeed, but are not blocking, including regressions (tests previously passed) regarded as allowable: test-amd64-amd64-xl-pcipt-intel 9 guest-start fail never pass test-amd64-i386-rhel6hvm-intel 9 guest-start.2 fail never pass test-amd64-i386-win-vcpus1 16 leak-check/check fail never pass test-amd64-i386-xl-win-vcpus1 13 guest-stop fail never pass test-amd64-i386-rhel6hvm-amd 9 guest-start.2 fail never pass test-amd64-i386-win 16 leak-check/check fail never pass test-amd64-amd64-win 16 leak-check/check fail never pass test-amd64-amd64-xl-win 13 guest-stop fail never pass test-i386-i386-xl-win 13 guest-stop fail never pass test-i386-i386-win 16 leak-check/check fail never pass version targeted for testing: xen 0268e7380953 baseline version: xen 0268e7380953 jobs: build-amd64 pass build-i386 pass build-amd64-oldkern pass build-i386-oldkern pass build-amd64-pvops pass build-i386-pvops pass test-amd64-amd64-xl pass test-amd64-i386-xl pass test-i386-i386-xl pass test-amd64-i386-rhel6hvm-amd fail test-amd64-i386-xl-credit2 pass test-amd64-amd64-xl-pcipt-intel fail test-amd64-i386-rhel6hvm-intel fail test-amd64-i386-xl-multivcpu pass test-amd64-amd64-pair pass test-amd64-i386-pair pass test-i386-i386-pair pass test-amd64-amd64-pv pass test-amd64-i386-pv pass test-i386-i386-pv pass test-amd64-amd64-xl-sedf pass test-amd64-i386-win-vcpus1 fail test-amd64-i386-xl-win-vcpus1 fail test-amd64-amd64-win fail test-amd64-i386-win fail test-i386-i386-win fail test-amd64-amd64-xl-win fail test-i386-i386-xl-win fail ------------------------------------------------------------ sg-report-flight on woking.cam.xci-test.com logs: /home/xc_osstest/logs images: /home/xc_osstest/images Logs, config files, etc. are available at http://www.chiark.greenend.org.uk/~xensrcts/logs Test harness code can be found at http://xenbits.xensource.com/gitweb?p=osstest.git;a=summary Published tested tree is already up to date. _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel From xen-devel-bounces@lists.xensource.com Mon Sep 05 21:38:54 2011 Return-path: Envelope-to: www-data@lists.xensource.com Delivery-date: Mon, 05 Sep 2011 21:38:54 -0700 Received: from localhost ([127.0.0.1] helo=lists.colo.xensource.com) by lists.xensource.com with esmtp (Exim 4.43) id 1R0nR0-0000RV-Ow; Mon, 05 Sep 2011 21:38:54 -0700 Received: from mail27.messagelabs.com ([193.109.254.147]) by lists.xensource.com with esmtp (Exim 4.43) id 1R0nQ7-0000EM-U4 for Xen-devel@lists.xensource.com; Mon, 05 Sep 2011 21:38:00 -0700 X-Env-Sender: mkjinesh@gmail.com X-Msg-Ref: server-12.tower-27.messagelabs.com!1315283862!41200663!1 X-Originating-IP: [209.85.220.171] X-StarScan-Version: 6.3.6; banners=-,-,- X-VirusChecked: Checked Received: (qmail 17160 invoked from network); 6 Sep 2011 04:37:43 -0000 Received: from mail-vx0-f171.google.com (HELO mail-vx0-f171.google.com) (209.85.220.171) by server-12.tower-27.messagelabs.com with RC4-SHA encrypted SMTP; 6 Sep 2011 04:37:43 -0000 Received: by vxh2 with SMTP id 2so2618561vxh.30 for ; Mon, 05 Sep 2011 21:37:55 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :content-type; bh=BZe09f/3PKSJk18DqshDnu4hvbn7vNaYcxrlNLatWDc=; b=UN4YaAax8jvmM7BdSZnUUKhIIrLyvx3nZuR/V9yS3rWnwsjzizkHm6uCsK9ZNKj1RB cmJ6h2CqgBydAx0+5XC9cXtlZ1jYCFm4cCiMMpN1JMvUk5KTsStQ2A+4Qsd5zV7CDt/v xBCM2hHunBgqu3voBiHW39yCvpsIq3WMr8h4E= Received: by 10.52.97.227 with SMTP id ed3mr4478328vdb.499.1315283875149; Mon, 05 Sep 2011 21:37:55 -0700 (PDT) MIME-Version: 1.0 Received: by 10.52.187.194 with HTTP; Mon, 5 Sep 2011 21:37:35 -0700 (PDT) In-Reply-To: References: From: "Jinesh M.K" Date: Tue, 6 Sep 2011 10:07:35 +0530 Message-ID: To: Simon Hobson , Xen-devel@lists.xensource.com Content-Type: multipart/mixed; boundary=20cf307abeed28381d04ac3e6483 Cc: Subject: [Xen-devel] Re: [Xen-users] Not show the network interface X-BeenThere: xen-devel@lists.xensource.com X-Mailman-Version: 2.1.5 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xensource.com Errors-To: xen-devel-bounces@lists.xensource.com --20cf307abeed28381d04ac3e6483 Content-Type: multipart/alternative; boundary=20cf307abeed28381804ac3e6481 --20cf307abeed28381804ac3e6481 Content-Type: text/plain; charset=ISO-8859-1 On 5 September 2011 17:02, Simon Hobson wrote: > Jinesh M.K wrote: > > I am using ubuntu 10.10 as dom0. When I start domain, it not display any >> network interface. I am removed all the domU guest,but no use. It show lo >> and virbr0 interface while using ifconfig command. It show the interface >> when I start without xen. Please help >> > > Not nearly enough information to try and start diagnosing the problem. > > Which version of Xen ? Which kernel ? Installed from the distribution > packages, or by some other means ? > > In your Xen config, what do you have set for network_script and vif_script > ? > > What is your network config for the OS ? > > -- > Simon Hobson > > Visit http://www.**magpiesnestpublishing.co.uk/for books by acclaimed > author Gladys Hobson. Novels - poetry - short stories - ideal as > Christmas stocking fillers. Some available as e-books. > > ______________________________**_________________ > Xen-users mailing list > Xen-users@lists.xensource.com > http://lists.xensource.com/**xen-users > I am using xen 4.0.1 version xen with ubuntu 10.10 as dom0. I installed it from source using linux-2.6.32.45-pv as kernal. I use bridged network for xen,but system does not detect my network interface(ifconfig not list my interface). To identify the problem, boot the system without xen. But everthing is perfect without xen..I attach xend-config with this mail. -- Jinesh --20cf307abeed28381804ac3e6481 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable

On 5 September 2011 17:02, Simon Hobson = <linux@theho= bsons.co.uk> wrote:
Jinesh M.K wrote:

I am using ubuntu 10.10 as dom0. When I start domain, it not display any ne= twork interface. I am removed all the domU guest,but no use. It show lo and= virbr0 interface while using ifconfig command. It show the interface when = I start without xen. Please help

Not nearly enough information to try and start diagnosing the problem.

Which version of Xen ? Which kernel ? Installed from the distribution packa= ges, or by some other means ?

In your Xen config, what do you have set for network_script and vif_script = ?

What is your network config for the OS ?

--
Simon Hobson

Visit http://www.magpiesnestpublishing.co.uk/ for books by acclaimed<= br> author Gladys Hobson. Novels - poetry - short stories - ideal as
Christmas stocking fillers. Some available as e-books.

_______________________________________________
Xen-users mailing list
Xen-user= s@lists.xensource.com
http://l= ists.xensource.com/xen-users
I am using xen 4.0.1 version xen with ubuntu 10.10 as do= m0. I installed it from source using linux-2.6.32.45-pv as kernal. I use br= idged network for xen,but system does not detect my network interface(ifcon= fig not list my interface). To identify the problem, boot the system withou= t xen. But=A0 everthing is perfect without xen..I attach xend-config with t= his mail.

--
Jinesh
--20cf307abeed28381804ac3e6481-- --20cf307abeed28381d04ac3e6483 Content-Type: application/octet-stream; name="xend-config.sxp" Content-Disposition: attachment; filename="xend-config.sxp" Content-Transfer-Encoding: base64 X-Attachment-Id: f_gs8e1w0x0 IyAtKi0gc2ggLSotCgojCiMgWGVuZCBjb25maWd1cmF0aW9uIGZpbGUuCiMKCiMgVGhpcyBleGFt cGxlIGNvbmZpZ3VyYXRpb24gaXMgYXBwcm9wcmlhdGUgZm9yIGFuIGluc3RhbGxhdGlvbiB0aGF0 IAojIHV0aWxpemVzIGEgYnJpZGdlZCBuZXR3b3JrIGNvbmZpZ3VyYXRpb24uIEFjY2VzcyB0byB4 ZW5kIHZpYSBodHRwCiMgaXMgZGlzYWJsZWQuICAKCiMgQ29tbWVudGVkIG91dCBlbnRyaWVzIHNo b3cgdGhlIGRlZmF1bHQgZm9yIHRoYXQgZW50cnksIHVubGVzcyBvdGhlcndpc2UKIyBzcGVjaWZp ZWQuCgojKGxvZ2ZpbGUgL3Zhci9sb2cveGVuL3hlbmQubG9nKQojKGxvZ2xldmVsIERFQlVHKQoK IyBVbmNvbW1lbnQgdGhlIGxpbmUgYmVsb3cuICBTZXQgdGhlIHZhbHVlIHRvIGZsYXNrLCBhY20s IG9yIGR1bW15IHRvIAojIHNlbGVjdCBhIHNlY3VyaXR5IG1vZHVsZS4KCiMoeHNtX21vZHVsZV9u YW1lIGR1bW15KQoKIyBUaGUgWGVuLUFQSSBzZXJ2ZXIgY29uZmlndXJhdGlvbi4KIwojIFRoaXMg dmFsdWUgY29uZmlndXJlcyB0aGUgcG9ydHMsIGludGVyZmFjZXMsIGFuZCBhY2Nlc3MgY29udHJv bHMgZm9yIHRoZQojIFhlbi1BUEkgc2VydmVyLiAgRWFjaCBlbnRyeSBpbiB0aGUgbGlzdCBzdGFy dHMgd2l0aCBlaXRoZXIgdW5peCwgYSBwb3J0CiMgbnVtYmVyLCBvciBhbiBhZGRyZXNzOnBvcnQg cGFpci4gIElmIHRoaXMgaXMgInVuaXgiLCB0aGVuIGEgVURQIHNvY2tldCBpcwojIG9wZW5lZCwg YW5kIHRoaXMgZW50cnkgYXBwbGllcyB0byB0aGF0LiAgSWYgaXQgaXMgYSBwb3J0LCB0aGVuIFhl bmQgd2lsbAojIGxpc3RlbiBvbiBhbGwgaW50ZXJmYWNlcyBvbiB0aGF0IFRDUCBwb3J0LCBhbmQg aWYgaXQgaXMgYW4gYWRkcmVzczpwb3J0CiMgcGFpciwgdGhlbiBYZW5kIHdpbGwgbGlzdGVuIG9u IHRoZSBzcGVjaWZpZWQgcG9ydCwgdXNpbmcgdGhlIGludGVyZmFjZSB3aXRoCiMgdGhlIHNwZWNp ZmllZCBhZGRyZXNzLgojCiMgVGhlIHN1YnNlcXVlbnQgc3RyaW5nIGNvbmZpZ3VyZXMgdGhlIHVz ZXItYmFzZWQgYWNjZXNzIGNvbnRyb2wgZm9yIHRoZQojIGxpc3RlbmVyIGluIHF1ZXN0aW9uLiAg VGhpcyBjYW4gYmUgb25lIG9mICJub25lIiBvciAicGFtIiwgaW5kaWNhdGluZyBlaXRoZXIKIyB0 aGF0IHVzZXJzIHNob3VsZCBiZSBhbGxvd2VkIGFjY2VzcyB1bmNvbmRpdGlvbmFsbHksIG9yIHRo YXQgdGhlIGxvY2FsCiMgUGx1Z2dhYmxlIEF1dGhlbnRpY2F0aW9uIE1vZHVsZXMgY29uZmlndXJh dGlvbiBzaG91bGQgYmUgdXNlZC4gIElmIHRoaXMKIyBzdHJpbmcgaXMgbWlzc2luZyBvciBlbXB0 eSwgdGhlbiAicGFtIiBpcyB1c2VkLgojCiMgVGhlIGZpbmFsIHN0cmluZyBnaXZlcyB0aGUgaG9z dC1iYXNlZCBhY2Nlc3MgY29udHJvbCBmb3IgdGhhdCBsaXN0ZW5lci4gSWYKIyB0aGlzIGlzIG1p c3Npbmcgb3IgZW1wdHksIHRoZW4gYWxsIGNvbm5lY3Rpb25zIGFyZSBhY2NlcHRlZC4gIE90aGVy d2lzZSwKIyB0aGlzIHNob3VsZCBiZSBhIHNwYWNlLXNlcGFyYXRlZCBzZXF1ZW5jZSBvZiByZWd1 bGFyIGV4cHJlc3Npb25zOyBhbnkgaG9zdAojIHdpdGggYSBmdWxseS1xdWFsaWZpZWQgZG9tYWlu IG5hbWUgb3IgYW4gSVAgYWRkcmVzcyB0aGF0IG1hdGNoZXMgb25lIG9mCiMgdGhlc2UgcmVndWxh ciBleHByZXNzaW9ucyB3aWxsIGJlIGFjY2VwdGVkLgojCiMgRXhhbXBsZTogbGlzdGVuIG9uIFRD UCBwb3J0IDkzNjMgb24gYWxsIGludGVyZmFjZXMsIGFjY2VwdGluZyBjb25uZWN0aW9ucwojIG9u bHkgZnJvbSBtYWNoaW5lcyBpbiBleGFtcGxlLmNvbSBvciBsb2NhbGhvc3QsIGFuZCBhbGxvdyBh Y2Nlc3MgdGhyb3VnaAojIHRoZSB1bml4IGRvbWFpbiBzb2NrZXQgdW5jb25kaXRpb25hbGx5Ogoj CiMgICAoeGVuLWFwaS1zZXJ2ZXIgKCg5MzYzIHBhbSAnXmxvY2FsaG9zdCQgZXhhbXBsZVxcLmNv bSQnKQojICAgICAgICAgICAgICAgICAgICAodW5peCBub25lKSkpCiMKIyBPcHRpb25hbGx5LCB0 aGUgVENQIFhlbi1BUEkgc2VydmVyIGNhbiB1c2UgU1NMIGJ5IHNwZWNpZnlpbmcgdGhlIHByaXZh dGUKIyBrZXkgYW5kIGNlcnRpZmljYXRlIGxvY2F0aW9uOgojCiMgICAgICAgICAgICAgICAgICAg ICg5MzY3IHBhbSAnJyB4ZW4tYXBpLmtleSB4ZW4tYXBpLmNydCkKIwojIERlZmF1bHQ6CiMgICAo eGVuLWFwaS1zZXJ2ZXIgKCh1bml4KSkpCgoKKHhlbmQtaHR0cC1zZXJ2ZXIgeWVzKQooeGVuZC11 bml4LXNlcnZlciB5ZXMpCiMoeGVuZC10Y3AteG1scnBjLXNlcnZlciBubykKIyh4ZW5kLXVuaXgt eG1scnBjLXNlcnZlciB5ZXMpCiMoeGVuZC1yZWxvY2F0aW9uLXNlcnZlciBubykKKHhlbmQtcmVs b2NhdGlvbi1zZXJ2ZXIgeWVzKQojKHhlbmQtcmVsb2NhdGlvbi1zc2wtc2VydmVyIG5vKQojKHhl bmQtdWRldi1ldmVudC1zZXJ2ZXIgbm8pCgojKHhlbmQtdW5peC1wYXRoIC92YXIvbGliL3hlbmQv eGVuZC1zb2NrZXQpCgoKIyBBZGRyZXNzIGFuZCBwb3J0IHhlbmQgc2hvdWxkIHVzZSBmb3IgdGhl IGxlZ2FjeSBUQ1AgWE1MUlBDIGludGVyZmFjZSwgCiMgaWYgeGVuZC10Y3AteG1scnBjLXNlcnZl ciBpcyBzZXQuCiMoeGVuZC10Y3AteG1scnBjLXNlcnZlci1hZGRyZXNzICdsb2NhbGhvc3QnKQoj KHhlbmQtdGNwLXhtbHJwYy1zZXJ2ZXItcG9ydCA4MDA2KQoKIyBTU0wga2V5IGFuZCBjZXJ0aWZp Y2F0ZSB0byB1c2UgZm9yIHRoZSBsZWdhY3kgVENQIFhNTFJQQyBpbnRlcmZhY2UuCiMgU2V0dGlu ZyB0aGVzZSB3aWxsIG1lYW4gdGhhdCB0aGlzIHBvcnQgc2VydmVzIG9ubHkgU1NMIGNvbm5lY3Rp b25zIGFzCiMgb3Bwb3NlZCB0byBwbGFpbnRleHQgb25lcy4KIyh4ZW5kLXRjcC14bWxycGMtc2Vy dmVyLXNzbC1rZXktZmlsZSAgeG1scnBjLmtleSkKIyh4ZW5kLXRjcC14bWxycGMtc2VydmVyLXNz bC1jZXJ0LWZpbGUgeG1scnBjLmNydCkKCgojIFBvcnQgeGVuZCBzaG91bGQgdXNlIGZvciB0aGUg SFRUUCBpbnRlcmZhY2UsIGlmIHhlbmQtaHR0cC1zZXJ2ZXIgaXMgc2V0LgooeGVuZC1wb3J0ICAg ICAgICAgICAgODAwMCkKCiMgUG9ydCB4ZW5kIHNob3VsZCB1c2UgZm9yIHRoZSByZWxvY2F0aW9u IGludGVyZmFjZSwgaWYgeGVuZC1yZWxvY2F0aW9uLXNlcnZlcgojIGlzIHNldC4KIyh4ZW5kLXJl bG9jYXRpb24tcG9ydCA4MDAyKQoKIyBQb3J0IHhlbmQgc2hvdWxkIHVzZSBmb3IgdGhlIHNzbCBy ZWxvY2F0aW9uIGludGVyZmFjZSwgaWYKIyB4ZW5kLXJlbG9jYXRpb24tc3NsLXNlcnZlciBpcyBz ZXQuCiMoeGVuZC1yZWxvY2F0aW9uLXNzbC1wb3J0IDgwMDMpCgojIFNTTCBrZXkgYW5kIGNlcnRp ZmljYXRlIHRvIHVzZSBmb3IgdGhlIHNzbCByZWxvY2F0aW9uIGludGVyZmFjZSwgaWYKIyB4ZW5k LXJlbG9jYXRpb24tc3NsLXNlcnZlciBpcyBzZXQuCiMoeGVuZC1yZWxvY2F0aW9uLXNlcnZlci1z c2wta2V5LWZpbGUgICB4bWxycGMua2V5KQojKHhlbmQtcmVsb2NhdGlvbi1zZXJ2ZXItc3NsLWNl cnQtZmlsZSAgeG1scnBjLmNydCkKCiMgV2hldGhlciB0byB1c2Ugc3NsIGFzIGRlZmF1bHQgd2hl biByZWxvY2F0aW5nLgojKHhlbmQtcmVsb2NhdGlvbi1zc2wgbm8pCgojIEFkZHJlc3MgeGVuZCBz aG91bGQgbGlzdGVuIG9uIGZvciBIVFRQIGNvbm5lY3Rpb25zLCBpZiB4ZW5kLWh0dHAtc2VydmVy IGlzCiMgc2V0LgojIFNwZWNpZnlpbmcgJ2xvY2FsaG9zdCcgcHJldmVudHMgcmVtb3RlIGNvbm5l Y3Rpb25zLgojIFNwZWNpZnlpbmcgdGhlIGVtcHR5IHN0cmluZyAnJyAodGhlIGRlZmF1bHQpIGFs bG93cyBhbGwgY29ubmVjdGlvbnMuCiMoeGVuZC1hZGRyZXNzICcnKQojKHhlbmQtYWRkcmVzcyBs b2NhbGhvc3QpCgojIEFkZHJlc3MgeGVuZCBzaG91bGQgbGlzdGVuIG9uIGZvciByZWxvY2F0aW9u LXNvY2tldCBjb25uZWN0aW9ucywgaWYKIyB4ZW5kLXJlbG9jYXRpb24tc2VydmVyIGlzIHNldC4K IyBNZWFuaW5nIGFuZCBkZWZhdWx0IGFzIGZvciB4ZW5kLWFkZHJlc3MgYWJvdmUuCiMoeGVuZC1y ZWxvY2F0aW9uLWFkZHJlc3MgJycpCgojIFRoZSBob3N0cyBhbGxvd2VkIHRvIHRhbGsgdG8gdGhl IHJlbG9jYXRpb24gcG9ydC4gIElmIHRoaXMgaXMgZW1wdHkgKHRoZQojIGRlZmF1bHQpLCB0aGVu IGFsbCBjb25uZWN0aW9ucyBhcmUgYWxsb3dlZCAoYXNzdW1pbmcgdGhhdCB0aGUgY29ubmVjdGlv bgojIGFycml2ZXMgb24gYSBwb3J0IGFuZCBpbnRlcmZhY2Ugb24gd2hpY2ggd2UgYXJlIGxpc3Rl bmluZzsgc2VlCiMgeGVuZC1yZWxvY2F0aW9uLXBvcnQgYW5kIHhlbmQtcmVsb2NhdGlvbi1hZGRy ZXNzIGFib3ZlKS4gIE90aGVyd2lzZSwgdGhpcwojIHNob3VsZCBiZSBhIHNwYWNlLXNlcGFyYXRl ZCBzZXF1ZW5jZSBvZiByZWd1bGFyIGV4cHJlc3Npb25zLiAgQW55IGhvc3Qgd2l0aAojIGEgZnVs bHktcXVhbGlmaWVkIGRvbWFpbiBuYW1lIG9yIGFuIElQIGFkZHJlc3MgdGhhdCBtYXRjaGVzIG9u ZSBvZiB0aGVzZQojIHJlZ3VsYXIgZXhwcmVzc2lvbnMgd2lsbCBiZSBhY2NlcHRlZC4KIwojIEZv ciBleGFtcGxlOgojICAoeGVuZC1yZWxvY2F0aW9uLWhvc3RzLWFsbG93ICdebG9jYWxob3N0JCBe LipcXC5leGFtcGxlXFwub3JnJCcpCiMKIyh4ZW5kLXJlbG9jYXRpb24taG9zdHMtYWxsb3cgJycp Cih4ZW5kLXJlbG9jYXRpb24taG9zdHMtYWxsb3cgJ15sb2NhbGhvc3QkIF5sb2NhbGhvc3RcXC5s b2NhbGRvbWFpbiQnKQoKIyBUaGUgbGltaXQgKGluIGtpbG9ieXRlcykgb24gdGhlIHNpemUgb2Yg dGhlIGNvbnNvbGUgYnVmZmVyCiMoY29uc29sZS1saW1pdCAxMDI0KQoKIyMKIyBUbyBicmlkZ2Ug bmV0d29yayB0cmFmZmljLCBsaWtlIHRoaXM6CiMKIyBkb20wOiAtLS0tLS0tLS0tLS0tLS0tLSBi cmlkZ2UgLT4gcmVhbCBldGgwIC0+IHRoZSBuZXR3b3JrCiMgICAgICAgICAgICAgICAgICAgICAg ICAgICAgfAojIGRvbVU6IGZha2UgZXRoMCAtPiB2aWZOLjAgLSsKIwojIHVzZQojCiMgKG5ldHdv cmstc2NyaXB0IG5ldHdvcmstYnJpZGdlKQojCiMgWW91ciBkZWZhdWx0IGV0aGVybmV0IGRldmlj ZSBpcyB1c2VkIGFzIHRoZSBvdXRnb2luZyBpbnRlcmZhY2UsIGJ5IGRlZmF1bHQuIAojIFRvIHVz ZSBhIGRpZmZlcmVudCBvbmUgKGUuZy4gZXRoMSkgdXNlCiMKIyAobmV0d29yay1zY3JpcHQgJ25l dHdvcmstYnJpZGdlIG5ldGRldj1ldGgxJykKIwojIFRoZSBicmlkZ2UgaXMgbmFtZWQgeGVuYnIw LCBieSBkZWZhdWx0LiAgVG8gcmVuYW1lIHRoZSBicmlkZ2UsIHVzZQojCiMgKG5ldHdvcmstc2Ny aXB0ICduZXR3b3JrLWJyaWRnZSBicmlkZ2U9PG5hbWU+JykKIwojIEl0IGlzIHBvc3NpYmxlIHRv IHVzZSB0aGUgbmV0d29yay1icmlkZ2Ugc2NyaXB0IGluIG1vcmUgY29tcGxpY2F0ZWQKIyBzY2Vu YXJpb3MsIHN1Y2ggYXMgaGF2aW5nIHR3byBvdXRnb2luZyBpbnRlcmZhY2VzLCB3aXRoIHR3byBi cmlkZ2VzLCBhbmQKIyB0d28gZmFrZSBpbnRlcmZhY2VzIHBlciBndWVzdCBkb21haW4uICBUbyBk byB0aGluZ3MgbGlrZSB0aGlzLCB3cml0ZQojIHlvdXJzZWxmIGEgd3JhcHBlciBzY3JpcHQsIGFu ZCBjYWxsIG5ldHdvcmstYnJpZGdlIGZyb20gaXQsIGFzIGFwcHJvcHJpYXRlLgojCihuZXR3b3Jr LXNjcmlwdCBuZXR3b3JrLWJyaWRnZSkKCiMgVGhlIHNjcmlwdCB1c2VkIHRvIGNvbnRyb2wgdmly dHVhbCBpbnRlcmZhY2VzLiAgVGhpcyBjYW4gYmUgb3ZlcnJpZGRlbiBvbiBhCiMgcGVyLXZpZiBi YXNpcyB3aGVuIGNyZWF0aW5nIGEgZG9tYWluIG9yIGEgY29uZmlndXJpbmcgYSBuZXcgdmlmLiAg VGhlCiMgdmlmLWJyaWRnZSBzY3JpcHQgaXMgZGVzaWduZWQgZm9yIHVzZSB3aXRoIHRoZSBuZXR3 b3JrLWJyaWRnZSBzY3JpcHQsIG9yCiMgc2ltaWxhciBjb25maWd1cmF0aW9ucy4KIwojIElmIHlv dSBoYXZlIG92ZXJyaWRkZW4gdGhlIGJyaWRnZSBuYW1lIHVzaW5nCiMgKG5ldHdvcmstc2NyaXB0 ICduZXR3b3JrLWJyaWRnZSBicmlkZ2U9PG5hbWU+JykgdGhlbiB5b3UgbWF5IHdpc2ggdG8gZG8g dGhlCiMgc2FtZSBoZXJlLiAgVGhlIGJyaWRnZSBuYW1lIGNhbiBhbHNvIGJlIHNldCB3aGVuIGNy ZWF0aW5nIGEgZG9tYWluIG9yCiMgY29uZmlndXJpbmcgYSBuZXcgdmlmLCBidXQgYSB2YWx1ZSBz cGVjaWZpZWQgaGVyZSB3b3VsZCBhY3QgYXMgYSBkZWZhdWx0LgojCiMgSWYgeW91IGFyZSB1c2lu ZyBvbmx5IG9uZSBicmlkZ2UsIHRoZSB2aWYtYnJpZGdlIHNjcmlwdCB3aWxsIGRpc2NvdmVyIHRo YXQsCiMgc28gdGhlcmUgaXMgbm8gbmVlZCB0byBzcGVjaWZ5IGl0IGV4cGxpY2l0bHkuCiMKKHZp Zi1zY3JpcHQgdmlmLWJyaWRnZSkKCgojIyBVc2UgdGhlIGZvbGxvd2luZyBpZiBuZXR3b3JrIHRy YWZmaWMgaXMgcm91dGVkLCBhcyBhbiBhbHRlcm5hdGl2ZSB0byB0aGUKIyBzZXR0aW5ncyBmb3Ig YnJpZGdlZCBuZXR3b3JraW5nIGdpdmVuIGFib3ZlLgojKG5ldHdvcmstc2NyaXB0IG5ldHdvcmst cm91dGUpCiModmlmLXNjcmlwdCAgICAgdmlmLXJvdXRlKQoKCiMjIFVzZSB0aGUgZm9sbG93aW5n IGlmIG5ldHdvcmsgdHJhZmZpYyBpcyByb3V0ZWQgd2l0aCBOQVQsIGFzIGFuIGFsdGVybmF0aXZl CiMgdG8gdGhlIHNldHRpbmdzIGZvciBicmlkZ2VkIG5ldHdvcmtpbmcgZ2l2ZW4gYWJvdmUuCiMo bmV0d29yay1zY3JpcHQgbmV0d29yay1uYXQpCiModmlmLXNjcmlwdCAgICAgdmlmLW5hdCkKCiMg ZG9tMC1taW4tbWVtIGlzIHRoZSBsb3dlc3QgcGVybWlzc2libGUgbWVtb3J5IGxldmVsIChpbiBN QikgZm9yIGRvbTAuCiMgVGhpcyBpcyBhIG1pbmltdW0gYm90aCBmb3IgYXV0by1iYWxsb29uaW5n IChhcyBlbmFibGVkIGJ5CiMgZW5hYmxlLWRvbTAtYmFsbG9vbmluZyBiZWxvdykgYW5kIGZvciB4 bSBtZW0tc2V0IHdoZW4gYXBwbGllZCB0byBkb20wLgooZG9tMC1taW4tbWVtIDE5NikKCiMgV2hl dGhlciB0byBlbmFibGUgYXV0by1iYWxsb29uaW5nIG9mIGRvbTAgdG8gYWxsb3cgZG9tVXMgdG8g YmUgY3JlYXRlZC4KIyBJZiBlbmFibGUtZG9tMC1iYWxsb29uaW5nID0gbm8sIGRvbTAgd2lsbCBu ZXZlciBiYWxsb29uIG91dC4KKGVuYWJsZS1kb20wLWJhbGxvb25pbmcgeWVzKQoKIyAzMi1iaXQg cGFyYXZpcnR1YWwgZG9tYWlucyBjYW4gb25seSBjb25zdW1lIHBoeXNpY2FsCiMgbWVtb3J5IGJl bG93IDE2OEdCLiBPbiBzeXN0ZW1zIHdpdGggbWVtb3J5IGJleW9uZCB0aGF0IGFkZHJlc3MsCiMg dGhleSdsbCBiZSBjb25maW5lZCB0byBtZW1vcnkgYmVsb3cgMTI4R0IuCiMgVXNpbmcgdG90YWxf YXZhaWxhYmxlX21lbW9yeSAoaW4gR0IpIHRvIHNwZWNpZnkgdGhlIGFtb3VudCBvZiBtZW1vcnkg cmVzZXJ2ZWQKIyBpbiB0aGUgbWVtb3J5IHBvb2wgZXhjbHVzaXZlbHkgZm9yIDMyLWJpdCBwYXJh dmlydHVhbCBkb21haW5zLgojIEFkZGl0aW9uYWxseSB5b3Ugc2hvdWxkIHVzZSBkb20wX21lbSA9 IDwtVmFsdWU+IGFzIGEgcGFyYW1ldGVyIGluIAojIHhlbiBrZXJuZWwgdG8gcmVzZXJ2ZSB0aGUg bWVtb3J5IGZvciAzMi1iaXQgcGFyYXZpcnR1YWwgZG9tYWlucywgZGVmYXVsdCAKIyBpcyAiMCIg KDBHQikuICAKKHRvdGFsX2F2YWlsYWJsZV9tZW1vcnkgMCkgCgojIEluIFNNUCBzeXN0ZW0sIGRv bTAgd2lsbCB1c2UgZG9tMC1jcHVzICMgb2YgQ1BVUwojIElmIGRvbTAtY3B1cyA9IDAsIGRvbTAg d2lsbCB0YWtlIGFsbCBjcHVzIGF2YWlsYWJsZQooZG9tMC1jcHVzIDApCgojIFdoZXRoZXIgdG8g ZW5hYmxlIGNvcmUtZHVtcHMgd2hlbiBkb21haW5zIGNyYXNoLgojKGVuYWJsZS1kdW1wIG5vKQoK IyBUaGUgdG9vbCB1c2VkIGZvciBpbml0aWF0aW5nIHZpcnR1YWwgVFBNIG1pZ3JhdGlvbgojKGV4 dGVybmFsLW1pZ3JhdGlvbi10b29sICcnKQoKIyBUaGUgaW50ZXJmYWNlIGZvciBWTkMgc2VydmVy cyB0byBsaXN0ZW4gb24uIERlZmF1bHRzCiMgdG8gMTI3LjAuMC4xICBUbyByZXN0b3JlIG9sZCAn bGlzdGVuIGV2ZXJ5d2hlcmUnIGJlaGF2aW91cgojIHNldCB0aGlzIHRvIDAuMC4wLjAKIyh2bmMt bGlzdGVuICcxMjcuMC4wLjEnKQoKIyBUaGUgZGVmYXVsdCBwYXNzd29yZCBmb3IgVk5DIGNvbnNv bGUgb24gSFZNIGRvbWFpbi4KIyBFbXB0eSBzdHJpbmcgaXMgbm8gYXV0aGVudGljYXRpb24uCih2 bmNwYXNzd2QgJycpCgojIFRoZSBWTkMgc2VydmVyIGNhbiBiZSB0b2xkIHRvIG5lZ290aWF0ZSBh IFRMUyBzZXNzaW9uCiMgdG8gZW5jcnlwdGlvbiBhbGwgdHJhZmZpYywgYW5kIHByb3ZpZGUgeDUw OSBjZXJ0IHRvCiMgY2xpZW50cyBlbmFibGluZyB0aGVtIHRvIHZlcmlmeSBzZXJ2ZXIgaWRlbnRp dHkuIFRoZQojIEdUSy1WTkMgd2lkZ2V0LCB2aXJ0LXZpZXdlciwgdmlydC1tYW5hZ2VyIGFuZCBW ZU5DcnlwdAojIGFsbCBzdXBwb3J0IHRoZSBWTkMgZXh0ZW5zaW9uIGZvciBUTFMgdXNlZCBpbiBR RU1VLiBUaGUKIyBUaWdodFZOQy9SZWFsVk5DL1VsdHJhVk5DIGNsaWVudHMgZG8gbm90LgojCiMg VG8gZW5hYmxlIHRoaXMgY3JlYXRlIHg1MDkgY2VydGlmaWNhdGVzIC8ga2V5cyBpbiB0aGUKIyBk aXJlY3RvcnkgJHtYRU5fQ09ORklHX0RJUn0gKyB2bmMKIwojICBjYS1jZXJ0LnBlbSAgICAgICAt IFRoZSBDQSBjZXJ0aWZpY2F0ZQojICBzZXJ2ZXItY2VydC5wZW0gICAtIFRoZSBTZXJ2ZXIgY2Vy dGlmaWNhdGUgc2lnbmVkIGJ5IHRoZSBDQQojICBzZXJ2ZXIta2V5LnBlbSAgICAtIFRoZSBzZXJ2 ZXIgcHJpdmF0ZSBrZXkKIwojIGFuZCB0aGVuIHVuY29tbWVudCB0aGlzIG5leHQgbGluZQojICh2 bmMtdGxzIDEpCgojIFRoZSBjZXJ0aWZpY2F0ZSBkaXIgY2FuIGJlIHBvaW50ZWQgZWxzZXdoZXJl Li4KIwojICh2bmMteDUwOS1jZXJ0LWRpciB2bmMpCgojIFRoZSBzZXJ2ZXIgY2FuIGJlIHRvbGQg dG8gcmVxdWVzdCAmIHZhbGlkYXRlIGFuIHg1MDkKIyBjZXJ0aWZpY2F0ZSBmcm9tIHRoZSBjbGll bnQuIE9ubHkgY2xpZW50cyB3aXRoIGEgY2VydAojIHNpZ25lZCBieSB0aGUgdHJ1c3RlZCBDQSB3 aWxsIGJlIGFibGUgdG8gY29ubmVjdC4gVGhpcwojIGlzIG1vcmUgc2VjdXJlIHRoZSBwYXNzd29y ZCBhdXRoIGFsb25lLiBQYXNzd2QgYXV0aCBjYW4KIyB1c2VkIGF0IHRoZSBzYW1lIHRpbWUgaWYg ZGVzaXJlZC4gVG8gZW5hYmxlIGNsaWVudCBjZXJ0CiMgY2hlY2tpbmcgdW5jb21tZW50IHRoaXM6 CiMKIyAodm5jLXg1MDktdmVyaWZ5IDEpCgojIFRoZSBkZWZhdWx0IGtleW1hcCB0byB1c2UgZm9y IHRoZSBWTSdzIHZpcnR1YWwga2V5Ym9hcmQKIyB3aGVuIG5vdCBzcGVjaWZpZmVkIGluIFZNJ3Mg Y29uZmlndXJhdGlvbgojKGtleW1hcCAnZW4tdXMnKQoKIyBTY3JpcHQgdG8gcnVuIHdoZW4gdGhl IGxhYmVsIG9mIGEgcmVzb3VyY2UgaGFzIGNoYW5nZWQuCiMocmVzb3VyY2UtbGFiZWwtY2hhbmdl LXNjcmlwdCAnJykKCiMgUm90YXRpb24gY291bnQgb2YgcWVtdS1kbSBsb2cgZmlsZS4KIyhxZW11 LWRtLWxvZ3JvdGF0ZS1jb3VudCAxMCkKCiMgUGF0aCB3aGVyZSBwZXJzaXN0ZW50IGRvbWFpbiBj b25maWd1cmF0aW9uIGlzIHN0b3JlZC4KIyBEZWZhdWx0IGlzIC92YXIvbGliL3hlbmQvZG9tYWlu cy8KIyh4ZW5kLWRvbWFpbnMtcGF0aCAvdmFyL2xpYi94ZW5kL2RvbWFpbnMpCgojIE51bWJlciBv ZiBzZWNvbmRzIHhlbmQgd2lsbCB3YWl0IGZvciBkZXZpY2UgY3JlYXRpb24gYW5kCiMgZGVzdHJ1 Y3Rpb24KIyhkZXZpY2UtY3JlYXRlLXRpbWVvdXQgMTAwKQojKGRldmljZS1kZXN0cm95LXRpbWVv dXQgMTAwKQoKIyBXaGVuIGFzc2lnbmluZyBkZXZpY2UgdG8gSFZNIGd1ZXN0LCB3ZSB1c2UgdGhl IHN0cmljdCBjaGVjayBmb3IgSFZNIGd1ZXN0IGJ5CiMgZGVmYXVsdC4gKEZvciBQViBndWVzdCwg d2UgdXNlIGxvb3NlIGNoZWNrIGF1dG9tYXRpY2FsbHkgaWYgbmVjZXNzYXJ5LikKIyBXaGVuIHdl IGFzc2lnbiBkZXZpY2UgdG8gSFZNIGd1ZXN0LCBpZiB3ZSBtZWV0IHdpdGggdGhlIGNvLWFzc2ln bm1lbnQKIyBpc3N1ZXMgb3IgdGhlIEFDUyBpc3N1ZSwgd2UgY291bGQgdHJ5IGNoYW5naW5nIHRo ZSBvcHRpb24gdG8gJ25vJyAtLSBob3dldmVyLAojIHdlIGhhdmUgdG8gcmVhbGl6ZSB0aGlzIG1h eSBpbmN1ciBzZWN1cml0eSBpc3N1ZSBhbmQgd2UgY2FuJ3QgbWFrZSBzdXJlIHRoZQojIGRldmlj ZSBhc3NpZ25tZW50IGNvdWxkIHJlYWxseSB3b3JrIHByb3Blcmx5IGV2ZW4gYWZ0ZXIgd2UgZG8g dGhpcy4KIyhwY2ktcGFzc3Rocm91Z2gtc3RyaWN0LWNoZWNrIHllcykK --20cf307abeed28381d04ac3e6483 Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel --20cf307abeed28381d04ac3e6483-- From xen-devel-bounces@lists.xensource.com Mon Sep 05 22:22:37 2011 Return-path: Envelope-to: www-data@lists.xensource.com Delivery-date: Mon, 05 Sep 2011 22:22:37 -0700 Received: from localhost ([127.0.0.1] helo=lists.colo.xensource.com) by lists.xensource.com with esmtp (Exim 4.43) id 1R0o7I-0001aU-RO; Mon, 05 Sep 2011 22:22:37 -0700 Received: from mail27.messagelabs.com ([193.109.254.147]) by lists.xensource.com with esmtp (Exim 4.43) id 1R0o6L-0001NN-0e for xen-devel@lists.xensource.com; Mon, 05 Sep 2011 22:21:38 -0700 X-Env-Sender: james.harper@bendigoit.com.au X-Msg-Ref: server-9.tower-27.messagelabs.com!1315286476!43293555!1 X-Originating-IP: [203.16.224.4] X-StarScan-Version: 6.3.6; banners=-,-,- X-VirusChecked: Checked Received: (qmail 17934 invoked from network); 6 Sep 2011 05:21:19 -0000 Received: from smtp1.bendigoit.com.au (HELO smtp1.bendigoit.com.au) (203.16.224.4) by server-9.tower-27.messagelabs.com with AES256-SHA encrypted SMTP; 6 Sep 2011 05:21:19 -0000 Received: from smtp2.bendigoit.com.au ([203.16.207.99] helo=mail.bendigoit.com.au) by smtp1.bendigoit.com.au with esmtp (Exim 4.69) (envelope-from ) id 1R0o6A-00052M-0Y; Tue, 06 Sep 2011 15:21:26 +1000 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable Date: Tue, 6 Sep 2011 15:21:22 +1000 Message-ID: In-Reply-To: <4E64D569.5030607@hfp.de> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Stability report GPLPV 0.11.0.308 Thread-Index: Acxr09nf4Hgj+XrsTwy7gt+Gerp8QwAV+iqQ References: <4E64A0DF.2070007@hfp.de> <4E64D569.5030607@hfp.de> From: "James Harper" To: "Andreas Kinzler" X-Really-From-Bendigo-IT: magichashvalue Cc: xen-devel@lists.xensource.com Subject: [Xen-devel] RE: Stability report GPLPV 0.11.0.308 X-BeenThere: xen-devel@lists.xensource.com X-Mailman-Version: 2.1.5 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xensource.com Errors-To: xen-devel-bounces@lists.xensource.com >=20 > >> With GPLPV 0.11.0.308 it worked perfectly and with very good performance > >> for over 9 days but then when I wanted to monitor the status, I was no > >> longer able to connect via remote desktop. When examining the file > >> system of the HVMs I found that somehow even the prime95 processes > did stop. > >> Any ideas? Could c/s 948 make any difference? Network worked perfectly > >> for 9 days, so I ask myself if the count of c/s 948 is used at all? > >There is some combination that I can't reproduce that seems to cause a > >problem when that count isn't passed in correctly. So it is a bug, but > >I'm not sure if it causes the problems you are seeing. >=20 > What exactly is the problem you encountered? >=20 > >I can give you a link to a build with that fix applied if you want to > >test further. >=20 > Thanks. I have plans to test the 0.11.0.312 version. I have a complete > build system here and a kernel-mode enabled signing certificate so I can > use that for my tests. >=20 I actually looked back through the changes and there is still a fix to come - basically xennet allocates new buffers when it needs them, but never frees them again so if there is a really big burst of traffic it could end up taking all the available memory. That could cause the problem you are seeing. I'm a bit busy with some other things at the moment but I hope to have a fix by the end of the week. James _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel From xen-devel-bounces@lists.xensource.com Tue Sep 06 00:25:24 2011 Return-path: Envelope-to: www-data@lists.xensource.com Delivery-date: Tue, 06 Sep 2011 00:25:24 -0700 Received: from localhost ([127.0.0.1] helo=lists.colo.xensource.com) by lists.xensource.com with esmtp (Exim 4.43) id 1R0q28-0004mU-EE; Tue, 06 Sep 2011 00:25:24 -0700 Received: from mail174.messagelabs.com ([85.158.138.51]) by lists.xensource.com with smtp (Exim 4.43) id 1R0q15-0004ZY-Gs for xen-devel@lists.xensource.com; Tue, 06 Sep 2011 00:24:29 -0700 X-Env-Sender: tinnycloud@hotmail.com X-Msg-Ref: server-12.tower-174.messagelabs.com!1315293856!30359058!1 X-Originating-IP: [65.55.116.32] X-StarScan-Version: 6.3.6; banners=-,-,- X-VirusChecked: Checked Received: (qmail 11770 invoked from network); 6 Sep 2011 07:24:16 -0000 Received: from blu0-omc1-s21.blu0.hotmail.com (HELO blu0-omc1-s21.blu0.hotmail.com) (65.55.116.32) by server-12.tower-174.messagelabs.com with SMTP; 6 Sep 2011 07:24:16 -0000 Received: from BLU157-W49 ([65.55.116.8]) by blu0-omc1-s21.blu0.hotmail.com with Microsoft SMTPSVC(6.0.3790.4675); Tue, 6 Sep 2011 00:24:14 -0700 Message-ID: X-Originating-IP: [121.0.29.75] From: MaoXiaoyun To: , xen devel Date: Tue, 6 Sep 2011 15:24:14 +0800 Importance: Normal Content-Type: text/plain; charset="gb2312" Content-Transfer-Encoding: 8bit MIME-Version: 1.0 X-OriginalArrivalTime: 06 Sep 2011 07:24:14.0961 (UTC) FILETIME=[FB3F0610:01CC6C65] Cc: jeremy@goop.org, konrad.wilk@oracle.com Subject: [Xen-devel] ext4 BUG in dom0 Kernel 2.6.32.36 X-BeenThere: xen-devel@lists.xensource.com X-Mailman-Version: 2.1.5 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xensource.com Errors-To: xen-devel-bounces@lists.xensource.com Hi: I've met an ext4 Bug in dom0 kernel 2.6.32.36. (See kernel stack below) 32.36 kernel commit: http://git.kernel.org/?p=linux/kernel/git/jeremy/xen.git;a=commit;h=ae333e97552c81ab10395ad1ffc6d6daaadb144a The bug only show up in our cluster environments which includes 300 physical machines, one server will run into this bug per day. Running ontop of every server, there are about 30 VMS, each of which has heavy IO workload inside.(we are doing some kinds of stress tests) We have our own distribute file system as the storage of cluster, every VM'image file will be spilt into several files with equal size in physical disk, and every creation of file use ext4 fallocation(fallocation size 1MB). So I believe there will be quite a lot of uninitialized extent to be initialized during the test. After go through the src code. Call routinue is ext4_da_sritepages->mpage_da_map_blocks->ext4_get_blocks->ext4_ext_get_blocks-> ext4_ext_handle_uninitialized_extents->ext4_ext_convert_to_initialized->ext4_ext_insert_extent if ext4_ext_handle_uninitialized_extents is called, then line 3306 must be satisfied. that is we have in_range(iblock, ee_block, ee_len) = true. so iblock >= ee_block fs/ext4/extents.c 3306 <+++<+++if (in_range(iblock, ee_block, ee_len)) { 3307 <+++<+++<+++newblock = iblock - ee_block + ee_start; 3308 <+++<+++<+++/* number of remaining blocks in the extent */ 3309 <+++<+++<+++allocated = ee_len - (iblock - ee_block); 3310 <+++<+++<+++ext_debug("%u fit into %u:%d -> %llu\n", iblock, 3311 <+++<+++<+++<+++<+++ee_block, ee_len, newblock); 3312 3313 <+++<+++<+++/* Do not put uninitialized extent in the cache */ 3314 <+++<+++<+++if (!ext4_ext_is_uninitialized(ex)) { 3315 <+++<+++<+++<+++ext4_ext_put_in_cache(inode, ee_block, 3316 <+++<+++<+++<+++<+++<+++<+++ee_len, ee_start, 3317 <+++<+++<+++<+++<+++<+++<+++EXT4_EXT_CACHE_EXTENT); 3318 <+++<+++<+++<+++goto out; 3319 <+++<+++<+++} 3320 <+++<+++<+++ret = ext4_ext_handle_uninitialized_extents(handle, 3321 <+++<+++<+++<+++<+++inode, iblock, max_blocks, path, 3322 <+++<+++<+++<+++<+++flags, allocated, bh_result, newblock); 3323 <+++<+++<+++return ret; 3324 <+++<+++} the newext is from line 2678, its ee_block is iblock + max_blocks the nearex is path[depth].p_ext(line 1683) BUG_ON 1716 means iblock + max_blocks = ee_block. So maybe that means we have iblock = ee_block and max_blocks = 0. 1716 <+++<+++BUG_ON(newext->ee_block == nearex->ee_block); 1717 <+++<+++len = (EXT_MAX_EXTENT(eh) - nearex) * sizeof(struct ext4_extent); 1718 <+++<+++len = len < 0 ? 0 : len; 1719 <+++<+++ext_debug("insert %d:%llu:[%d]%d before: nearest 0x%p, " 1720 <+++<+++<+++<+++"move %d from 0x%p to 0x%p\n", 1721 <+++<+++<+++<+++le32_to_cpu(newext->ee_block), 1722 <+++<+++<+++<+++ext_pblock(newext), 1723 <+++<+++<+++<+++ext4_ext_is_uninitialized(newext), 1724 <+++<+++<+++<+++ext4_ext_get_actual_len(newext), 1725 <+++<+++<+++<+++nearex, len, nearex + 1, nearex + 2); 1726 <+++<+++memmove(nearex + 1, nearex, len); 1727 <+++<+++path[depth].p_ext = nearex; 1728 <+++} 2678 <+++<+++ex3 = &newex; 2679 <+++<+++ex3->ee_block = cpu_to_le32(iblock + max_blocks); 2680 <+++<+++ext4_ext_store_pblock(ex3, newblock + max_blocks); 2681 <+++<+++ex3->ee_len = cpu_to_le16(allocated - max_blocks); 2682 <+++<+++ext4_ext_mark_uninitialized(ex3); 2683 <+++<+++err = ext4_ext_insert_extent(handle, inode, path, ex3, 0); 2684 <+++<+++if (err == -ENOSPC && may_zeroout) { 2685 <+++<+++<+++err = ext4_ext_zeroout(inode, &orig_ex); if max_blocks = 0; it means 2225, mpd->b_size >> mpd->inode->i_blkbits is 0. fs/ext4/inode.c 2220 static int mpage_da_map_blocks(struct mpage_da_data *mpd) 2221 { 2222 <+++int err, blks, get_blocks_flags; 2223 <+++struct buffer_head new; 2224 <+++sector_t next = mpd->b_blocknr; 2225 <+++unsigned max_blocks = mpd->b_size >> mpd->inode->i_blkbits; 2226 <+++loff_t disksize = EXT4_I(mpd->inode)->i_disksize; 2227 <+++handle_t *handle = NULL; 2228 Could it be possilbe, right now I am tring to reproduce this problem in a much easiler way, any suggestion? Many thanks. ------------[ cut here ]------------ kernel BUG at fs/ext4/extents.c:1716! invalid opcode: 0000 [#1] SMP last sysfs file: /sys/block/tapdevk/stat CPU 3 Modules linked in: xt_iprange xt_mac arptable_filter arp_tables xt_physdev nf_conntrack_ipv4 nf_defrag_ipv4 xt_state nf_conntrack iptable_filter ip_tables bridge autofs4 ipmi_devintf ipmi_si ipmi_msghandler lockd sunrpc bonding ipv6 8021q garp stp llc xenfs dm_multipath fuse xen_netback xen_blkback blktap blkback_pagemap loop nbd video output sbs sbshc parport_pc lp parport joydev ses enclosure snd_seq_dummy snd_seq_oss bnx2 snd_seq_midi_event snd_seq snd_seq_device dcdbas snd_pcm_oss snd_mixer_oss serio_raw snd_pcm snd_timer snd soundcore snd_page_alloc iTCO_wdt iTCO_vendor_support pcspkr shpchp [last unloaded: freq_table] Pid: 9073, comm: flush-8:16 Not tainted 2.6.32.36xen #1 PowerEdge R710 RIP: e030:[] [] ext4_ext_insert_extent+0xac1/0xbe0 RSP: e02b:ffff8801499cd580 EFLAGS: 00010246 RAX: 0000000000002948 RBX: 0000000000000000 RCX: ffff8801499cd780 RDX: ffff8801499cd360 RSI: ffff88007dedb310 RDI: 0000000000000017 RBP: ffff8801499cd650 R08: ffff8801499cd340 R09: ffff880063488930 R10: 000000018100f8bf R11: dead000000200200 R12: ffff88005a29700c R13: ffff88005a297000 R14: ffff8801158198c0 R15: ffff88003e9ea1b0 FS: 00007fd3cc4bf6e0(0000) GS:ffff88002808f000(0000) knlGS:0000000000000000 CS: e033 DS: 0000 ES: 0000 CR0: 000000008005003b CR2: 000000000042a09e CR3: 00000000bf3bd000 CR4: 0000000000002660 DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 DR3: 0000000000000000 DR6: 00000000ffff0ff0 DR7: 0000000000000400 Process flush-8:16 (pid: 9073, threadinfo ffff8801499cc000, task ffff880149ad5b40) Stack: ffff8801499cd780 ffff88003e9ea180 ffff8801c5b47300 01ffffff81103c0c <0> ffff88003e9ea180 000000017dedb2a0 ffff880115819800 ffff88007dedb2a0 <0> ffff8801499cd5d0 ffffffff811c12ea ffff8801499cd5f0 ffffffff811c16ea Call Trace: [] ? jbd_unlock_bh_journal_head+0x16/0x18 [] ? jbd2_journal_put_journal_head+0x4d/0x52 [] ? jbd2_journal_get_write_access+0x31/0x38 [] ? __ext4_journal_get_write_access+0x4c/0x5f [] ext4_ext_handle_uninitialized_extents+0xa40/0xef5 [] ? xen_force_evtchn_callback+0xd/0xf [] ? check_events+0x12/0x20 [] ? need_resched+0x23/0x2d [] ext4_ext_get_blocks+0x265/0x6eb [] ? need_resched+0x23/0x2d [] ext4_get_blocks+0x140/0x204 [] mpage_da_map_blocks+0xb7/0x681 [] ? find_get_pages_tag+0x48/0xcc [] ? check_events+0x12/0x20 [] ? pagevec_lookup_tag+0x27/0x30 [] ? write_cache_pages+0x175/0x35e [] ? __mpage_da_writepage+0x0/0x164 [] ? kmem_cache_alloc+0x94/0xf6 [] ? jbd2_journal_start+0xa1/0xcd [] ? ext4_journal_start_sb+0xdc/0x111 [] ? ext4_meta_trans_blocks+0x74/0xce [] ext4_da_writepages+0x47a/0x6a7 [] do_writepages+0x21/0x2a [] writeback_single_inode+0xc8/0x1e3 [] writeback_inodes_wb+0x30b/0x37e [] ? paravirt_end_context_switch+0x17/0x31 [] ? xen_end_context_switch+0x1e/0x22 [] wb_writeback+0x131/0x1bb [] ? try_to_del_timer_sync+0x73/0x81 [] wb_do_writeback+0x13c/0x153 [] ? process_timeout+0x0/0x10 [] ? bdi_start_fn+0x0/0xd0 [] bdi_writeback_task+0x2c/0xb3 [] bdi_start_fn+0x6a/0xd0 [] kthread+0x6e/0x76 [] child_rip+0xa/0x20 [] ? int_ret_from_sys_call+0x7/0x1b [] ? retint_restore_args+0x5/0x6 [] ? child_rip+0x0/0x20 Code: 8d 04 85 f4 ff ff ff 85 c0 0f 49 d8 48 63 d3 e8 47 c7 07 00 49 8d 44 24 0c 49 89 47 10 eb 3a bb f4 ff ff ff e9 c2 00 00 00 75 04 <0f> 0b eb fe 41 0f b7 45 04 49 8d 7c 24 0c 48 6b c0 0c 4c 89 e6 RIP [] ext4_ext_insert_extent+0xac1/0xbe0 RSP ---[ end trace 035c7d09ed95fb32 ]--- _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel From xen-devel-bounces@lists.xensource.com Tue Sep 06 02:08:47 2011 Return-path: Envelope-to: www-data@lists.xensource.com Delivery-date: Tue, 06 Sep 2011 02:08:47 -0700 Received: from localhost ([127.0.0.1] helo=lists.colo.xensource.com) by lists.xensource.com with esmtp (Exim 4.43) id 1R0reA-0007Tq-W2; Tue, 06 Sep 2011 02:08:47 -0700 Received: from mail174.messagelabs.com ([85.158.138.51]) by lists.xensource.com with esmtp (Exim 4.43) id 1R0rdQ-0007H8-6P for xen-devel@lists.xensource.com; Tue, 06 Sep 2011 02:08:00 -0700 X-Env-Sender: olaf@aepfle.de X-Msg-Ref: server-10.tower-174.messagelabs.com!1315300074!30384419!1 X-Originating-IP: [81.169.146.160] X-StarScan-Version: 6.3.6; banners=-,-,- X-VirusChecked: Checked Received: (qmail 32069 invoked from network); 6 Sep 2011 09:07:57 -0000 Received: from mo-p00-ob.rzone.de (HELO mo-p00-ob.rzone.de) (81.169.146.160) by server-10.tower-174.messagelabs.com with EDH-RSA-DES-CBC3-SHA encrypted SMTP; 6 Sep 2011 09:07:57 -0000 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; t=1315300074; l=720; s=domk; d=aepfle.de; h=To:From:Date:Subject:Content-Transfer-Encoding:MIME-Version: Content-Type:X-RZG-CLASS-ID:X-RZG-AUTH; bh=JoqA6TVYoS7qBMiaXC515/CQ3vs=; b=kchTe9XLNlxRE0XY/IImTSOhQB3Ely9urafcKutcypTgja0tfOtmNjWudmAUr2Qv93i cCZmH9R5wvvvGr6EsHwW9wYN45BJUDZzwsMxgwJrEMEmstWAqJeIrgFcbL/JKykiwNFUM c8UvtmdQEQeGpZ7Kh9DoJqPLK2pEVS/69Lo= X-RZG-AUTH: :P2EQZWCpfu+qG7CngxMFH1J+zrwiavkK6tmQaLfmwtM48/ll387qFiVd X-RZG-CLASS-ID: mo00 Received: from probook.site (dslb-084-057-086-149.pools.arcor-ip.net [84.57.86.149]) by smtp.strato.de (klopstock mo7) (RZmta 26.6) with (EDH-RSA-DES-CBC3-SHA encrypted) ESMTPA id 601b57n8676SPY for ; Tue, 6 Sep 2011 11:07:53 +0200 (MEST) Received: from probook.site (localhost [IPv6:::1]) by probook.site (Postfix) with ESMTP id 2585D18B64 for ; Tue, 6 Sep 2011 11:07:53 +0200 (CEST) Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Mercurial-Node: bde6301b03c818d93a19cf4ffd668c6c825e5181 Message-Id: User-Agent: Mercurial-patchbomb/1.7.5 Date: Tue, 06 Sep 2011 11:07:51 +0200 From: Olaf Hering To: xen-devel@lists.xensource.com Subject: [Xen-devel] [PATCH] p2m-ept: remove map_domain_page check X-BeenThere: xen-devel@lists.xensource.com X-Mailman-Version: 2.1.5 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xensource.com Errors-To: xen-devel-bounces@lists.xensource.com # HG changeset patch # User Olaf Hering # Date 1315299489 -7200 # Node ID bde6301b03c818d93a19cf4ffd668c6c825e5181 # Parent 0268e73809532a4a3ca18a075efcee3c62caf458 p2m-ept: remove map_domain_page check map_domain_page() can not fail, remove ASSERT in ept_set_entry(). Signed-off-by: Olaf Hering diff -r 0268e7380953 -r bde6301b03c8 xen/arch/x86/mm/p2m-ept.c --- a/xen/arch/x86/mm/p2m-ept.c +++ b/xen/arch/x86/mm/p2m-ept.c @@ -332,8 +332,6 @@ ept_set_entry(struct p2m_domain *p2m, un table = map_domain_page(ept_get_asr(d)); - ASSERT(table != NULL); - for ( i = ept_get_wl(d); i > target; i-- ) { ret = ept_next_level(p2m, 0, &table, &gfn_remainder, i); _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel From xen-devel-bounces@lists.xensource.com Tue Sep 06 02:17:27 2011 Return-path: Envelope-to: www-data@lists.xensource.com Delivery-date: Tue, 06 Sep 2011 02:17:27 -0700 Received: from localhost ([127.0.0.1] helo=lists.colo.xensource.com) by lists.xensource.com with esmtp (Exim 4.43) id 1R0rmZ-0007yM-MU; Tue, 06 Sep 2011 02:17:27 -0700 Received: from mail216.messagelabs.com ([85.158.143.99]) by lists.xensource.com with smtp (Exim 4.43) id 1R0rm2-0007lf-W7 for xen-devel@lists.xensource.com; Tue, 06 Sep 2011 02:16:55 -0700 X-Env-Sender: imammedo@redhat.com X-Msg-Ref: server-4.tower-216.messagelabs.com!1315300611!17197988!1 X-Originating-IP: [209.132.183.28] X-StarScan-Version: 6.3.6; banners=-,-,- X-VirusChecked: Checked Received: (qmail 15746 invoked from network); 6 Sep 2011 09:16:51 -0000 Received: from mx1.redhat.com (HELO mx1.redhat.com) (209.132.183.28) by server-4.tower-216.messagelabs.com with SMTP; 6 Sep 2011 09:16:51 -0000 Received: from int-mx09.intmail.prod.int.phx2.redhat.com (int-mx09.intmail.prod.int.phx2.redhat.com [10.5.11.22]) by mx1.redhat.com (8.14.4/8.14.4) with ESMTP id p869GnWS020257 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Tue, 6 Sep 2011 05:16:49 -0400 Received: from ns3.rdu.redhat.com (ns3.rdu.redhat.com [10.11.255.199]) by int-mx09.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP id p869Gktf011438; Tue, 6 Sep 2011 05:16:46 -0400 Received: from nial.usersys.redhat.com (dhcp-1-247.brq.redhat.com [10.34.1.247]) by ns3.rdu.redhat.com (8.13.8/8.13.8) with ESMTP id p869GPiD007977; Tue, 6 Sep 2011 05:16:25 -0400 Message-ID: <4E65E4E9.4050101@redhat.com> Date: Tue, 06 Sep 2011 11:16:25 +0200 From: Igor Mammedov User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.2.20) Gecko/20110805 Red Hat/3.1.12-1.el6_1 Lightning/1.0b2 Thunderbird/3.1.12 MIME-Version: 1.0 To: Konrad Rzeszutek Wilk Subject: Re: [Xen-devel] Re: [PATCH v2] xen: x86_32: do not enable iterrupts when returning from exception in interrupt context References: <4E5EB794.7050909@goop.org> <1314877615-18280-1-git-send-email-imammedo@redhat.com> <4E5FB700.1070908@goop.org> <4E60914F.7080208@redhat.com> <20110902134032.GA6064@dumpdata.com> <4E60E1BF.2020206@redhat.com> <20110902144702.GA1704@dumpdata.com> In-Reply-To: <20110902144702.GA1704@dumpdata.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Scanned-By: MIMEDefang 2.68 on 10.5.11.22 Cc: Jeremy Fitzhardinge , xen-devel@lists.xensource.com, linux-kernel@vger.kernel.org X-BeenThere: xen-devel@lists.xensource.com X-Mailman-Version: 2.1.5 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xensource.com Errors-To: xen-devel-bounces@lists.xensource.com On 09/02/2011 04:47 PM, Konrad Rzeszutek Wilk wrote: > On Fri, Sep 02, 2011 at 04:01:35PM +0200, Igor Mammedov wrote: >> On 09/02/2011 03:40 PM, Konrad Rzeszutek Wilk wrote: >>> On Fri, Sep 02, 2011 at 10:18:23AM +0200, Igor Mammedov wrote: >>>> On 09/01/2011 06:46 PM, Jeremy Fitzhardinge wrote: >>>>> On 09/01/2011 04:46 AM, Igor Mammedov wrote: >>>>>> If vmalloc page_fault happens inside of interrupt handler with interrupts >>>>>> disabled then on exit path from exception handler when there is no pending >>>>>> interrupts, the following code (arch/x86/xen/xen-asm_32.S:112): >>>>>> >>>>>> cmpw $0x0001, XEN_vcpu_info_pending(%eax) >>>>>> sete XEN_vcpu_info_mask(%eax) >>>>>> >>>>>> will enable interrupts even if they has been previously disabled according to >>>>>> eflags from the bounce frame (arch/x86/xen/xen-asm_32.S:99) >>>>>> >>>>>> testb $X86_EFLAGS_IF>>8, 8+1+ESP_OFFSET(%esp) >>>>>> setz XEN_vcpu_info_mask(%eax) >>>>>> >>>>>> Solution is in setting XEN_vcpu_info_mask only when it should be set >>>>>> according to >>>>>> cmpw $0x0001, XEN_vcpu_info_pending(%eax) >>>>>> but not clearing it if there isn't any pending events. >>>>>> >>>>>> Reproducer for bug is attached to RHBZ 707552 >>>>>> >>>>>> Signed-off-by: Igor Mammedov >>>>>> Signed-off-by: Jeremy Fitzhardinge >>>>> >>>>> One nit, this should be acked-by or reviewed-by, not signed-off-by, >>>>> since the patch isn't passing through my hands. >>>>> >>>>> J >>>> >>>> I'm new to this stuff, would you like me to re-post it? >>> >>> That is OK. I fixed it up in the git commit. Thanks for finding this one! >> >> You're welcome! >> I've learned a lot while debugging it. In particular, how to use kvm and qemu's >> gdbstub to debug xen and guest using gdb. > > Oh, would you be interested in writting a blog article on xen.org by any chance? > That sounds pretty nifty! Sure, that is on my todo list. I'll just gather separated bits of information together, on how to prepare host for debugging. And description of problems and limitations of this approach, that I've stumbled on. -- Thanks, Igor _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel From xen-devel-bounces@lists.xensource.com Tue Sep 06 04:01:01 2011 Return-path: Envelope-to: www-data@lists.xensource.com Delivery-date: Tue, 06 Sep 2011 04:01:01 -0700 Received: from localhost ([127.0.0.1] helo=lists.colo.xensource.com) by lists.xensource.com with esmtp (Exim 4.43) id 1R0tOn-0004MI-8L; Tue, 06 Sep 2011 04:01:01 -0700 Received: from mail174.messagelabs.com ([85.158.138.51]) by lists.xensource.com with esmtp (Exim 4.43) id 1R0tNr-00049X-AY for xen-devel@lists.xensource.com; Tue, 06 Sep 2011 04:00:03 -0700 X-Env-Sender: Wei.Wang2@amd.com X-Msg-Ref: server-11.tower-174.messagelabs.com!1315306795!30404164!1 X-Originating-IP: [216.32.181.185] X-StarScan-Version: 6.3.6; banners=-,-,- X-VirusChecked: Checked Received: (qmail 29346 invoked from network); 6 Sep 2011 10:59:59 -0000 Received: from ch1ehsobe005.messaging.microsoft.com (HELO ch1outboundpool.messaging.microsoft.com) (216.32.181.185) by server-11.tower-174.messagelabs.com with AES128-SHA encrypted SMTP; 6 Sep 2011 10:59:59 -0000 Received: from mail126-ch1-R.bigfish.com (216.32.181.171) by CH1EHSOBE005.bigfish.com (10.43.70.55) with Microsoft SMTP Server id 14.1.225.22; Tue, 6 Sep 2011 10:59:55 +0000 Received: from mail126-ch1 (localhost.localdomain [127.0.0.1]) by mail126-ch1-R.bigfish.com (Postfix) with ESMTP id 6EFF02A01C6; Tue, 6 Sep 2011 10:59:55 +0000 (UTC) X-SpamScore: -3 X-BigFish: VPS-3(z37d5kz98dK4015Lzz1202hzzz32i668h839h61h) X-Spam-TCS-SCL: 0:0 X-Forefront-Antispam-Report: CIP:163.181.249.108; KIP:(null); UIP:(null); IPVD:NLI; H:ausb3twp01.amd.com; RD:none; EFVD:NLI Received: from mail126-ch1 (localhost.localdomain [127.0.0.1]) by mail126-ch1 (MessageSwitch) id 1315306795344977_25760; Tue, 6 Sep 2011 10:59:55 +0000 (UTC) Received: from CH1EHSMHS012.bigfish.com (snatpool1.int.messaging.microsoft.com [10.43.68.246]) by mail126-ch1.bigfish.com (Postfix) with ESMTP id 418A793004B; Tue, 6 Sep 2011 10:59:55 +0000 (UTC) Received: from ausb3twp01.amd.com (163.181.249.108) by CH1EHSMHS012.bigfish.com (10.43.70.12) with Microsoft SMTP Server id 14.1.225.22; Tue, 6 Sep 2011 10:59:52 +0000 X-WSS-ID: 0LR3L7N-01-2MA-02 X-M-MSG: Received: from sausexedgep02.amd.com (sausexedgep02-ext.amd.com [163.181.249.73]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by ausb3twp01.amd.com (Axway MailGate 3.8.1) with ESMTP id 236881028075; Tue, 6 Sep 2011 05:59:47 -0500 (CDT) Received: from SAUSEXDAG04.amd.com (163.181.55.4) by sausexedgep02.amd.com (163.181.36.59) with Microsoft SMTP Server (TLS) id 8.3.106.1; Tue, 6 Sep 2011 06:00:46 -0500 Received: from storexhtp02.amd.com (172.24.4.4) by sausexdag04.amd.com (163.181.55.4) with Microsoft SMTP Server (TLS) id 14.1.289.1; Tue, 6 Sep 2011 05:59:50 -0500 Received: from gwo.osrc.amd.com (165.204.16.204) by storexhtp02.amd.com (172.24.4.4) with Microsoft SMTP Server id 8.3.83.0; Tue, 6 Sep 2011 06:59:50 -0400 Received: from mail.osrc.amd.com (silizium.osrc.amd.com [165.204.15.142]) by gwo.osrc.amd.com (Postfix) with ESMTP id 1FE9F49C20C; Tue, 6 Sep 2011 11:59:49 +0100 (BST) Received: from gran.osrc.amd.com (gran.osrc.amd.com [165.204.15.57]) by mail.osrc.amd.com (Postfix) with ESMTP id 037A35940FF; Tue, 6 Sep 2011 12:59:49 +0200 (CEST) From: Wei Wang2 To: Jan Beulich Subject: Re: [Xen-devel] [PATCH, RFC 5/7] PCI multi-seg: AMD-IOMMU specificadjustments Date: Tue, 6 Sep 2011 13:03:11 +0200 User-Agent: KMail/1.9.6 (enterprise 20070904.708012) References: <4E567F2A0200007800053475@nat28.tlf.novell.com> <201108261357.57885.wei.wang2@amd.com> <4E64E7BE0200007800054AD6@nat28.tlf.novell.com> In-Reply-To: <4E64E7BE0200007800054AD6@nat28.tlf.novell.com> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-ID: <201109061303.11919.wei.wang2@amd.com> X-OriginatorOrg: amd.com Cc: "xen-devel@lists.xensource.com" X-BeenThere: xen-devel@lists.xensource.com X-Mailman-Version: 2.1.5 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xensource.com Errors-To: xen-devel-bounces@lists.xensource.com On Monday 05 September 2011 15:16:14 Jan Beulich wrote: > I don't really follow: The two cases where I can't spot where to get the > segment number from are register_exclusion_range_for_all_devices() > and register_exclusion_range_for_device(), both called in the context > of struct acpi_ivmd_block_header(), which only gets a struct > acpi_ivmd_block_header (not having a segment number afaict). OK, now I understand your question. I thought you are question about iommu specification. For these two functions, I think seg = 0 is fine, since amd iommu does not support multiple pci segment other than 0. Also, You could pass acpi_ivhd_block_header to parse_ivmd_block() in function parse_ivrs_block(), since both ivhd and ivmd entries shares the same ivhd header. Thanks, Wei _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel From xen-devel-bounces@lists.xensource.com Tue Sep 06 04:34:42 2011 Return-path: Envelope-to: www-data@lists.xensource.com Delivery-date: Tue, 06 Sep 2011 04:34:42 -0700 Received: from localhost ([127.0.0.1] helo=lists.colo.xensource.com) by lists.xensource.com with esmtp (Exim 4.43) id 1R0tvO-0005Kf-Et; Tue, 06 Sep 2011 04:34:42 -0700 Received: from mail216.messagelabs.com ([85.158.143.99]) by lists.xensource.com with smtp (Exim 4.43) id 1R0tub-00057z-1N for xen-devel@lists.xensource.com; Tue, 06 Sep 2011 04:33:53 -0700 X-Env-Sender: tinnycloud@hotmail.com X-Msg-Ref: server-3.tower-216.messagelabs.com!1315308829!16200063!1 X-Originating-IP: [65.55.116.27] X-StarScan-Version: 6.3.6; banners=-,-,- X-VirusChecked: Checked Received: (qmail 14018 invoked from network); 6 Sep 2011 11:33:49 -0000 Received: from blu0-omc1-s16.blu0.hotmail.com (HELO blu0-omc1-s16.blu0.hotmail.com) (65.55.116.27) by server-3.tower-216.messagelabs.com with SMTP; 6 Sep 2011 11:33:49 -0000 Received: from BLU157-W44 ([65.55.116.8]) by blu0-omc1-s16.blu0.hotmail.com with Microsoft SMTPSVC(6.0.3790.4675); Tue, 6 Sep 2011 04:33:48 -0700 Message-ID: X-Originating-IP: [121.0.29.75] From: MaoXiaoyun To: , xen devel Date: Tue, 6 Sep 2011 19:33:48 +0800 Importance: Normal In-Reply-To: References: Content-Type: text/plain; charset="gb2312" Content-Transfer-Encoding: 8bit MIME-Version: 1.0 X-OriginalArrivalTime: 06 Sep 2011 11:33:48.0894 (UTC) FILETIME=[D867DFE0:01CC6C88] Cc: jeremy@goop.org, konrad.wilk@oracle.com Subject: [Xen-devel] RE: ext4 BUG in dom0 Kernel 2.6.32.36 X-BeenThere: xen-devel@lists.xensource.com X-Mailman-Version: 2.1.5 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xensource.com Errors-To: xen-devel-bounces@lists.xensource.com fsck some of the the hard disk has multiply-claimd blocks. And it looks like i need this patch to fix "should not have EOFBLOCKS_FL set" error. http://git390.marist.edu/cgi-bin/gitweb.cgi?p=linux-2.6.git;a=commitdiff;h=58590b06d79f7ce5ab64ff3b6d537180fa50dc84 Inode 50343178 should not have EOFBLOCKS_FL set (size 67108864, lblk 16383) Clear? yes Inode 50345362 should not have EOFBLOCKS_FL set (size 67108864, lblk 16383) Clear? yes Inode 50345386 should not have EOFBLOCKS_FL set (size 63963136, lblk 15615) Clear? yes Inode 50345648 should not have EOFBLOCKS_FL set (size 3145728, lblk 767) Clear? yes Inode 50345690 should not have EOFBLOCKS_FL set (size 67108864, lblk 16383) Clear? yes Inode 50346361, i_blocks is 133136, should be 133256. Fix? yes Running additional passes to resolve blocks claimed by more than one inode... Pass 1B: Rescanning for multiply-claimed blocks Multiply-claimed block(s) in inode 50346361: 226854591 226854592 226854593 226854594 226854595 226854596 226854597 226854598 226854599 226854600 226854601 226854602 226854603 226854604 226854605 226854591 226854592 226854593 226854594 226854595 226854596 226854597 226854598 226854599 226854600 226854601 226854602 226854603 226854604 226854605 Pass 1C: Scanning directories for inodes with multiply-claimed blocks Pass 1D: Reconciling multiply-claimed blocks (There are 1 inodes containing multiply-claimed blocks.) File /chunks/2410339941482498_637 (inode #50346361, mod time Tue Sep 6 16:25:33 2011) has 30 multiply-claimed block(s), shared with 0 file(s): Clone multiply-claimed blocks? yes Pass 2: Checking directory structure Pass 3: Checking directory connectivity Pass 4: Checking reference counts Pass 5: Checking group summary information Free blocks count wrong for group #0 (78, counted=63). Fix? yes Free blocks count wrong (7028646, counted=7028631). Fix? yes ---------------------------------------- > From: tinnycloud@hotmail.com > To: linux-ext4@vger.kernel.org; xen-devel@lists.xensource.com > CC: jeremy@goop.org; konrad.wilk@oracle.com > Subject: ext4 BUG in dom0 Kernel 2.6.32.36 > Date: Tue, 6 Sep 2011 15:24:14 +0800 > > > > Hi: > > I've met an ext4 Bug in dom0 kernel 2.6.32.36. (See kernel stack below) > 32.36 kernel commit: http://git.kernel.org/?p=linux/kernel/git/jeremy/xen.git;a=commit;h=ae333e97552c81ab10395ad1ffc6d6daaadb144a > > The bug only show up in our cluster environments which includes 300 physical machines, one server will run into this bug per day. > Running ontop of every server, there are about 30 VMS, each of which has heavy IO workload inside.(we are doing some kinds of stress tests) > > We have our own distribute file system as the storage of cluster, every VM'image file will be spilt into several files with equal size in > physical disk, and every creation of file use ext4 fallocation(fallocation size 1MB). So I believe there will be quite a lot of uninitialized > extent to be initialized during the test. > > After go through the src code. Call routinue is > ext4_da_sritepages->mpage_da_map_blocks->ext4_get_blocks->ext4_ext_get_blocks-> > ext4_ext_handle_uninitialized_extents->ext4_ext_convert_to_initialized->ext4_ext_insert_extent > > > if ext4_ext_handle_uninitialized_extents is called, then line 3306 must be satisfied. > that is we have in_range(iblock, ee_block, ee_len) = true. > so iblock >= ee_block > > fs/ext4/extents.c > 3306 <+++<+++if (in_range(iblock, ee_block, ee_len)) { > 3307 <+++<+++<+++newblock = iblock - ee_block + ee_start; > 3308 <+++<+++<+++/* number of remaining blocks in the extent */ > 3309 <+++<+++<+++allocated = ee_len - (iblock - ee_block); > 3310 <+++<+++<+++ext_debug("%u fit into %u:%d -> %llu\n", iblock, > 3311 <+++<+++<+++<+++<+++ee_block, ee_len, newblock); > 3312 > 3313 <+++<+++<+++/* Do not put uninitialized extent in the cache */ > 3314 <+++<+++<+++if (!ext4_ext_is_uninitialized(ex)) { > 3315 <+++<+++<+++<+++ext4_ext_put_in_cache(inode, ee_block, > 3316 <+++<+++<+++<+++<+++<+++<+++ee_len, ee_start, > 3317 <+++<+++<+++<+++<+++<+++<+++EXT4_EXT_CACHE_EXTENT); > 3318 <+++<+++<+++<+++goto out; > 3319 <+++<+++<+++} > 3320 <+++<+++<+++ret = ext4_ext_handle_uninitialized_extents(handle, > 3321 <+++<+++<+++<+++<+++inode, iblock, max_blocks, path, > 3322 <+++<+++<+++<+++<+++flags, allocated, bh_result, newblock); > 3323 <+++<+++<+++return ret; > 3324 <+++<+++} > > > the newext is from line 2678, its ee_block is iblock + max_blocks > the nearex is path[depth].p_ext(line 1683) > > BUG_ON 1716 means iblock + max_blocks = ee_block. > So maybe that means we have iblock = ee_block and max_blocks = 0. > > > 1716 <+++<+++BUG_ON(newext->ee_block == nearex->ee_block); > 1717 <+++<+++len = (EXT_MAX_EXTENT(eh) - nearex) * sizeof(struct ext4_extent); > 1718 <+++<+++len = len < 0 ? 0 : len; > 1719 <+++<+++ext_debug("insert %d:%llu:[%d]%d before: nearest 0x%p, " > 1720 <+++<+++<+++<+++"move %d from 0x%p to 0x%p\n", > 1721 <+++<+++<+++<+++le32_to_cpu(newext->ee_block), > 1722 <+++<+++<+++<+++ext_pblock(newext), > 1723 <+++<+++<+++<+++ext4_ext_is_uninitialized(newext), > 1724 <+++<+++<+++<+++ext4_ext_get_actual_len(newext), > 1725 <+++<+++<+++<+++nearex, len, nearex + 1, nearex + 2); > 1726 <+++<+++memmove(nearex + 1, nearex, len); > 1727 <+++<+++path[depth].p_ext = nearex; > 1728 <+++} > > > 2678 <+++<+++ex3 = &newex; > 2679 <+++<+++ex3->ee_block = cpu_to_le32(iblock + max_blocks); > 2680 <+++<+++ext4_ext_store_pblock(ex3, newblock + max_blocks); > 2681 <+++<+++ex3->ee_len = cpu_to_le16(allocated - max_blocks); > 2682 <+++<+++ext4_ext_mark_uninitialized(ex3); > 2683 <+++<+++err = ext4_ext_insert_extent(handle, inode, path, ex3, 0); > 2684 <+++<+++if (err == -ENOSPC && may_zeroout) { > 2685 <+++<+++<+++err = ext4_ext_zeroout(inode, &orig_ex); > > > if max_blocks = 0; it means 2225, mpd->b_size >> mpd->inode->i_blkbits is 0. > > fs/ext4/inode.c > 2220 static int mpage_da_map_blocks(struct mpage_da_data *mpd) > 2221 { > 2222 <+++int err, blks, get_blocks_flags; > 2223 <+++struct buffer_head new; > 2224 <+++sector_t next = mpd->b_blocknr; > 2225 <+++unsigned max_blocks = mpd->b_size >> mpd->inode->i_blkbits; > 2226 <+++loff_t disksize = EXT4_I(mpd->inode)->i_disksize; > 2227 <+++handle_t *handle = NULL; > 2228 > > > Could it be possilbe, right now I am tring to reproduce this problem in a much > easiler way, any suggestion? > > Many thanks. > > > ------------[ cut here ]------------ > kernel BUG at fs/ext4/extents.c:1716! > invalid opcode: 0000 [#1] SMP > last sysfs file: /sys/block/tapdevk/stat > CPU 3 > Modules linked in: xt_iprange xt_mac arptable_filter arp_tables xt_physdev nf_conntrack_ipv4 nf_defrag_ipv4 xt_state nf_conntrack > iptable_filter ip_tables bridge autofs4 ipmi_devintf ipmi_si ipmi_msghandler lockd sunrpc bonding ipv6 8021q garp stp llc xenfs > dm_multipath fuse xen_netback xen_blkback blktap blkback_pagemap loop nbd video output sbs sbshc parport_pc lp parport joydev ses > enclosure snd_seq_dummy snd_seq_oss bnx2 snd_seq_midi_event snd_seq snd_seq_device dcdbas snd_pcm_oss snd_mixer_oss serio_raw snd_pcm > snd_timer snd soundcore snd_page_alloc iTCO_wdt iTCO_vendor_support pcspkr shpchp [last unloaded: freq_table] > Pid: 9073, comm: flush-8:16 Not tainted 2.6.32.36xen #1 PowerEdge R710 > RIP: e030:[] [] ext4_ext_insert_extent+0xac1/0xbe0 > RSP: e02b:ffff8801499cd580 EFLAGS: 00010246 > RAX: 0000000000002948 RBX: 0000000000000000 RCX: ffff8801499cd780 > RDX: ffff8801499cd360 RSI: ffff88007dedb310 RDI: 0000000000000017 > RBP: ffff8801499cd650 R08: ffff8801499cd340 R09: ffff880063488930 > R10: 000000018100f8bf R11: dead000000200200 R12: ffff88005a29700c > R13: ffff88005a297000 R14: ffff8801158198c0 R15: ffff88003e9ea1b0 > FS: 00007fd3cc4bf6e0(0000) GS:ffff88002808f000(0000) knlGS:0000000000000000 > CS: e033 DS: 0000 ES: 0000 CR0: 000000008005003b > CR2: 000000000042a09e CR3: 00000000bf3bd000 CR4: 0000000000002660 > DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 > DR3: 0000000000000000 DR6: 00000000ffff0ff0 DR7: 0000000000000400 > Process flush-8:16 (pid: 9073, threadinfo ffff8801499cc000, task ffff880149ad5b40) > Stack: > ffff8801499cd780 ffff88003e9ea180 ffff8801c5b47300 01ffffff81103c0c > <0> ffff88003e9ea180 000000017dedb2a0 ffff880115819800 ffff88007dedb2a0 > <0> ffff8801499cd5d0 ffffffff811c12ea ffff8801499cd5f0 ffffffff811c16ea > Call Trace: > [] ? jbd_unlock_bh_journal_head+0x16/0x18 > [] ? jbd2_journal_put_journal_head+0x4d/0x52 > [] ? jbd2_journal_get_write_access+0x31/0x38 > [] ? __ext4_journal_get_write_access+0x4c/0x5f > [] ext4_ext_handle_uninitialized_extents+0xa40/0xef5 > [] ? xen_force_evtchn_callback+0xd/0xf > [] ? check_events+0x12/0x20 > [] ? need_resched+0x23/0x2d > [] ext4_ext_get_blocks+0x265/0x6eb > [] ? need_resched+0x23/0x2d > [] ext4_get_blocks+0x140/0x204 > [] mpage_da_map_blocks+0xb7/0x681 > [] ? find_get_pages_tag+0x48/0xcc > [] ? check_events+0x12/0x20 > [] ? pagevec_lookup_tag+0x27/0x30 > [] ? write_cache_pages+0x175/0x35e > [] ? __mpage_da_writepage+0x0/0x164 > [] ? kmem_cache_alloc+0x94/0xf6 > [] ? jbd2_journal_start+0xa1/0xcd > [] ? ext4_journal_start_sb+0xdc/0x111 > [] ? ext4_meta_trans_blocks+0x74/0xce > [] ext4_da_writepages+0x47a/0x6a7 > [] do_writepages+0x21/0x2a > [] writeback_single_inode+0xc8/0x1e3 > [] writeback_inodes_wb+0x30b/0x37e > [] ? paravirt_end_context_switch+0x17/0x31 > [] ? xen_end_context_switch+0x1e/0x22 > [] wb_writeback+0x131/0x1bb > [] ? try_to_del_timer_sync+0x73/0x81 > [] wb_do_writeback+0x13c/0x153 > [] ? process_timeout+0x0/0x10 > [] ? bdi_start_fn+0x0/0xd0 > [] bdi_writeback_task+0x2c/0xb3 > [] bdi_start_fn+0x6a/0xd0 > [] kthread+0x6e/0x76 > [] child_rip+0xa/0x20 > [] ? int_ret_from_sys_call+0x7/0x1b > [] ? retint_restore_args+0x5/0x6 > [] ? child_rip+0x0/0x20 > Code: 8d 04 85 f4 ff ff ff 85 c0 0f 49 d8 48 63 d3 e8 47 c7 07 00 49 8d 44 24 0c 49 89 47 10 eb 3a bb f4 ff ff ff e9 c2 00 00 00 75 04 > <0f> 0b eb fe 41 0f b7 45 04 49 8d 7c 24 0c 48 6b c0 0c 4c 89 e6 > RIP [] ext4_ext_insert_extent+0xac1/0xbe0 > RSP > ---[ end trace 035c7d09ed95fb32 ]--- > -- > To unsubscribe from this list: send the line "unsubscribe linux-ext4" in > the body of a message to majordomo@vger.kernel.org > More majordomo info at http://vger.kernel.org/majordomo-info.html _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel From xen-devel-bounces@lists.xensource.com Tue Sep 06 04:47:52 2011 Return-path: Envelope-to: www-data@lists.xensource.com Delivery-date: Tue, 06 Sep 2011 04:47:52 -0700 Received: from localhost ([127.0.0.1] helo=lists.colo.xensource.com) by lists.xensource.com with esmtp (Exim 4.43) id 1R0u87-00063H-GC; Tue, 06 Sep 2011 04:47:51 -0700 Received: from mail27.messagelabs.com ([193.109.254.147]) by lists.xensource.com with esmtp (Exim 4.43) id 1R0u7L-0005qO-Le for xen-devel@lists.xensource.com; Tue, 06 Sep 2011 04:47:03 -0700 X-Env-Sender: JBeulich@suse.com X-Msg-Ref: server-3.tower-27.messagelabs.com!1315309599!38484543!1 X-Originating-IP: [130.57.49.28] X-StarScan-Version: 6.3.6; banners=-,-,- X-VirusChecked: Checked Received: (qmail 17824 invoked from network); 6 Sep 2011 11:46:39 -0000 Received: from nat28.tlf.novell.com (HELO nat28.tlf.novell.com) (130.57.49.28) by server-3.tower-27.messagelabs.com with DHE-RSA-AES256-SHA encrypted SMTP; 6 Sep 2011 11:46:39 -0000 Received: from EMEA1-MTA by nat28.tlf.novell.com with Novell_GroupWise; Tue, 06 Sep 2011 12:46:59 +0100 Message-Id: <4E6624690200007800054CDC@nat28.tlf.novell.com> X-Mailer: Novell GroupWise Internet Agent 8.0.1 Date: Tue, 06 Sep 2011 12:47:21 +0100 From: "Jan Beulich" To: "Wei Wang2" Subject: Re: [Xen-devel] [PATCH,RFC 5/7] PCI multi-seg: AMD-IOMMU specificadjustments References: <4E567F2A0200007800053475@nat28.tlf.novell.com> <201108261357.57885.wei.wang2@amd.com> <4E64E7BE0200007800054AD6@nat28.tlf.novell.com> <201109061303.11919.wei.wang2@amd.com> In-Reply-To: <201109061303.11919.wei.wang2@amd.com> Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: quoted-printable Content-Disposition: inline Cc: "xen-devel@lists.xensource.com" X-BeenThere: xen-devel@lists.xensource.com X-Mailman-Version: 2.1.5 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xensource.com Errors-To: xen-devel-bounces@lists.xensource.com >>> On 06.09.11 at 13:03, Wei Wang2 wrote: > On Monday 05 September 2011 15:16:14 Jan Beulich wrote: >> I don't really follow: The two cases where I can't spot where to get = the >> segment number from are register_exclusion_range_for_all_devices() >> and register_exclusion_range_for_device(), both called in the context >> of struct acpi_ivmd_block_header(), which only gets a struct >> acpi_ivmd_block_header (not having a segment number afaict). >=20 > OK, now I understand your question. I thought you are question about = iommu=20 > specification. For these two functions, I think seg =3D 0 is fine, since = amd=20 > iommu does not support multiple pci segment other than 0. So I'll leave the code unchanged then, also because ... > Also, You could=20 > pass acpi_ivhd_block_header to parse_ivmd_block() in function=20 > parse_ivrs_block(), since both ivhd and ivmd entries shares the same = ivhd=20 > header. ... this I cannot make sense of: parse_ivrs_block() casts its input (of type struct acpi_ivrs_block_header *) to either struct acpi_ivhd_block_header * (on which path I'm already using the available segment number) or struct acpi_ivmd_block_header * (which doesn't have a segment number, and which has its start_addr member located at the offset where pci_segment would be in acpi_ivhd_block_header, so casting to both types in a single function invocation is clearly = wrong). Jan _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel From xen-devel-bounces@lists.xensource.com Tue Sep 06 05:02:47 2011 Return-path: Envelope-to: www-data@lists.xensource.com Delivery-date: Tue, 06 Sep 2011 05:02:47 -0700 Received: from localhost ([127.0.0.1] helo=lists.colo.xensource.com) by lists.xensource.com with esmtp (Exim 4.43) id 1R0uMY-0007Kz-2W; Tue, 06 Sep 2011 05:02:46 -0700 Received: from mail216.messagelabs.com ([85.158.143.99]) by lists.xensource.com with esmtp (Exim 4.43) id 1R0uH8-0006Vr-MA for xen-devel@lists.xensource.com; Tue, 06 Sep 2011 04:57:11 -0700 X-Env-Sender: komkon555@freenet.de X-Msg-Ref: server-2.tower-216.messagelabs.com!1315310226!17232268!1 X-Originating-IP: [216.139.236.26] X-StarScan-Version: 6.3.6; banners=-,-,- X-VirusChecked: Checked Received: (qmail 13300 invoked from network); 6 Sep 2011 11:57:07 -0000 Received: from sam.nabble.com (HELO sam.nabble.com) (216.139.236.26) by server-2.tower-216.messagelabs.com with AES256-SHA encrypted SMTP; 6 Sep 2011 11:57:07 -0000 Received: from [192.168.236.26] (helo=sam.nabble.com) by sam.nabble.com with esmtp (Exim 4.72) (envelope-from ) id 1R0uH3-0000Ni-2I for xen-devel@lists.xensource.com; Tue, 06 Sep 2011 04:57:05 -0700 Date: Tue, 6 Sep 2011 04:57:05 -0700 (PDT) From: komkon555 To: xen-devel@lists.xensource.com Message-ID: <1315310225039-4774097.post@n5.nabble.com> In-Reply-To: <1315231341254-4770602.post@n5.nabble.com> References: <1314699668477-4749561.post@n5.nabble.com> <1314712525082-4750109.post@n5.nabble.com> <1314716445148-4750357.post@n5.nabble.com> <1314720409505-4750600.post@n5.nabble.com> <1314778567400-4753326.post@n5.nabble.com> <20110831083832.GD7276@reaktio.net> <1314780568949-4753422.post@n5.nabble.com> <1314795401771-4754024.post@n5.nabble.com> <20110831151913.GE7276@reaktio.net> <1315231341254-4770602.post@n5.nabble.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Subject: [Xen-devel] Re: Patches for VGA-Passthrough XEN 4.2 unstable X-BeenThere: xen-devel@lists.xensource.com X-Mailman-Version: 2.1.5 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xensource.com Errors-To: xen-devel-bounces@lists.xensource.com Hallo. I tested the new patches. The patched version of xen-unstable let start/shutdown Windows XP normally. But the current nvidia driver is not yet functional: question-sign in device-manager windows. This problem is very sadly, because it makes no sense to use gfx-passthrough for nvidia cards. Anyway thank you a lot for patches. I see some progress against the old one. P.S. Hardware as above. -- View this message in context: http://xen.1045712.n5.nabble.com/Patches-for-VGA-Passthrough-XEN-4-2-unstable-tp4406265p4774097.html Sent from the Xen - Dev mailing list archive at Nabble.com. _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel From xen-devel-bounces@lists.xensource.com Tue Sep 06 07:34:58 2011 Return-path: Envelope-to: www-data@lists.xensource.com Delivery-date: Tue, 06 Sep 2011 07:34:58 -0700 Received: from localhost ([127.0.0.1] helo=lists.colo.xensource.com) by lists.xensource.com with esmtp (Exim 4.43) id 1R0wjp-0004Lz-Sp; Tue, 06 Sep 2011 07:34:58 -0700 Received: from mail21.messagelabs.com ([85.158.143.35]) by lists.xensource.com with esmtp (Exim 4.43) id 1R0wjE-00049x-NU for xen-devel@lists.xensource.com; Tue, 06 Sep 2011 07:34:21 -0700 X-Env-Sender: JBeulich@suse.com X-Msg-Ref: server-11.tower-21.messagelabs.com!1315319641!41544679!1 X-Originating-IP: [130.57.49.28] X-StarScan-Version: 6.3.6; banners=-,-,- X-VirusChecked: Checked Received: (qmail 11423 invoked from network); 6 Sep 2011 14:34:02 -0000 Received: from nat28.tlf.novell.com (HELO nat28.tlf.novell.com) (130.57.49.28) by server-11.tower-21.messagelabs.com with DHE-RSA-AES256-SHA encrypted SMTP; 6 Sep 2011 14:34:02 -0000 Received: from EMEA1-MTA by nat28.tlf.novell.com with Novell_GroupWise; Tue, 06 Sep 2011 15:34:17 +0100 Message-Id: <4E664B9D0200007800054D6D@nat28.tlf.novell.com> X-Mailer: Novell GroupWise Internet Agent 8.0.1 Date: Tue, 06 Sep 2011 15:34:37 +0100 From: "Jan Beulich" To: "xen-devel@lists.xensource.com" Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: quoted-printable Content-Disposition: inline Subject: [Xen-devel] struct irq_desc vs. struct irq_cfg X-BeenThere: xen-devel@lists.xensource.com X-Mailman-Version: 2.1.5 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xensource.com Errors-To: xen-devel-bounces@lists.xensource.com Originally, iirc, struct irq_desc's chip_data pointer was intended to be = set to something specific to the struct hw_interrupt_type instance that's being put into its handler pointer. Currently, however, struct irq_cfg is being used universally (and carries data that is also intended to be available) = for all interrupt types. Wouldn't it make sense to move global data back into struct irq_desc, or should we rather introduce a second pointer (e.g. handler_data) in struct irq_desc to allow handler specific context to be stored? Thanks, Jan _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel From xen-devel-bounces@lists.xensource.com Tue Sep 06 07:45:00 2011 Return-path: Envelope-to: www-data@lists.xensource.com Delivery-date: Tue, 06 Sep 2011 07:45:00 -0700 Received: from localhost ([127.0.0.1] helo=lists.colo.xensource.com) by lists.xensource.com with esmtp (Exim 4.43) id 1R0wtY-0004s8-Ko; Tue, 06 Sep 2011 07:45:00 -0700 Received: from mail174.messagelabs.com ([85.158.138.51]) by lists.xensource.com with esmtp (Exim 4.43) id 1R0wsp-0004fj-Qy for xen-devel@lists.xensource.com; Tue, 06 Sep 2011 07:44:16 -0700 X-Env-Sender: Andrew.Cooper3@citrix.com X-Msg-Ref: server-3.tower-174.messagelabs.com!1315320246!24376338!1 X-Originating-IP: [66.165.176.63] X-StarScan-Version: 6.3.6; banners=-,-,- X-VirusChecked: Checked Received: (qmail 20329 invoked from network); 6 Sep 2011 14:44:12 -0000 Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63) by server-3.tower-174.messagelabs.com with RC4-SHA encrypted SMTP; 6 Sep 2011 14:44:12 -0000 X-IronPort-AV: E=Sophos;i="4.68,338,1312171200"; d="scan'208";a="161841906" Received: from ftlpmailmx02.citrite.net ([10.13.107.66]) by FTLPIPO02.CITRIX.COM with ESMTP/TLS/RC4-MD5; 06 Sep 2011 10:44:06 -0400 Received: from [10.80.2.18] (10.80.2.18) by FTLPMAILMX02.citrite.net (10.13.107.66) with Microsoft SMTP Server id 8.3.137.0; Tue, 6 Sep 2011 10:44:06 -0400 Message-ID: <4E6631B5.8030308@citrix.com> Date: Tue, 6 Sep 2011 15:44:05 +0100 From: Andrew Cooper User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.2.21) Gecko/20110831 Lightning/1.0b2 Thunderbird/3.1.13 MIME-Version: 1.0 To: Subject: Re: [Xen-devel] struct irq_desc vs. struct irq_cfg References: <4E664B9D0200007800054D6D@nat28.tlf.novell.com> In-Reply-To: <4E664B9D0200007800054D6D@nat28.tlf.novell.com> Content-Type: text/plain; charset="ISO-8859-1" Content-Transfer-Encoding: 7bit X-BeenThere: xen-devel@lists.xensource.com X-Mailman-Version: 2.1.5 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xensource.com Errors-To: xen-devel-bounces@lists.xensource.com On 06/09/11 15:34, Jan Beulich wrote: > Originally, iirc, struct irq_desc's chip_data pointer was intended to be set to > something specific to the struct hw_interrupt_type instance that's being > put into its handler pointer. Currently, however, struct irq_cfg is being > used universally (and carries data that is also intended to be available) for > all interrupt types. Wouldn't it make sense to move global data back into > struct irq_desc, or should we rather introduce a second pointer (e.g. > handler_data) in struct irq_desc to allow handler specific context to be > stored? I believe I asked this question in my long email about the direction of irq cleanup (and if not, I certainly intended to) As the inequality irq_desc[irq].chip-data == irq_cfg[irq] is maintained at all times, merging the two would make sense, as well as removing many needless indirections, and nr_irqs pointers. Therefore, I vote to merge the two. What were you considering to contain in the handler specific context? > Thanks, Jan > > > _______________________________________________ > Xen-devel mailing list > Xen-devel@lists.xensource.com > http://lists.xensource.com/xen-devel -- Andrew Cooper - Dom0 Kernel Engineer, Citrix XenServer T: +44 (0)1223 225 900, http://www.citrix.com _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel From xen-devel-bounces@lists.xensource.com Tue Sep 06 07:55:05 2011 Return-path: Envelope-to: www-data@lists.xensource.com Delivery-date: Tue, 06 Sep 2011 07:55:05 -0700 Received: from localhost ([127.0.0.1] helo=lists.colo.xensource.com) by lists.xensource.com with esmtp (Exim 4.43) id 1R0x3I-0005P2-8g; Tue, 06 Sep 2011 07:55:04 -0700 Received: from mail27.messagelabs.com ([193.109.254.147]) by lists.xensource.com with esmtp (Exim 4.43) id 1R0x2X-0005CD-8A for xen-devel@lists.xensource.com; Tue, 06 Sep 2011 07:54:17 -0700 X-Env-Sender: konrad@dumpdata.com X-Msg-Ref: server-7.tower-27.messagelabs.com!1315320832!47521626!1 X-Originating-IP: [141.146.126.227] X-StarScan-Version: 6.3.6; banners=-,-,- X-VirusChecked: Checked Received: (qmail 15033 invoked from network); 6 Sep 2011 14:53:53 -0000 Received: from acsinet15.oracle.com (HELO acsinet15.oracle.com) (141.146.126.227) by server-7.tower-27.messagelabs.com with DHE-RSA-AES256-SHA encrypted SMTP; 6 Sep 2011 14:53:53 -0000 Received: from rtcsinet21.oracle.com (rtcsinet21.oracle.com [66.248.204.29]) by acsinet15.oracle.com (Switch-3.4.4/Switch-3.4.4) with ESMTP id p86Es8bV022349 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Tue, 6 Sep 2011 14:54:10 GMT Received: from acsmt358.oracle.com (acsmt358.oracle.com [141.146.40.158]) by rtcsinet21.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id p86Es5VO026754 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 6 Sep 2011 14:54:06 GMT Received: from abhmt116.oracle.com (abhmt116.oracle.com [141.146.116.68]) by acsmt358.oracle.com (8.12.11.20060308/8.12.11) with ESMTP id p86ErwL6026296; Tue, 6 Sep 2011 09:53:58 -0500 Received: from phenom (/209.6.55.207) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Tue, 06 Sep 2011 07:53:57 -0700 Received: by phenom (Postfix, from userid 1000) id CB822FD1; Tue, 6 Sep 2011 10:53:47 -0400 (EDT) Date: Tue, 6 Sep 2011 10:53:47 -0400 From: Konrad Rzeszutek Wilk To: MaoXiaoyun Message-ID: <20110906145347.GA4133@dumpdata.com> References: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.21 (2010-09-15) X-Source-IP: rtcsinet21.oracle.com [66.248.204.29] X-CT-RefId: str=0001.0A090201.4E663412.0149,ss=1,re=0.000,fgs=0 Cc: jeremy@goop.org, linux-ext4@vger.kernel.org, xen devel Subject: [Xen-devel] Re: ext4 BUG in dom0 Kernel 2.6.32.36 X-BeenThere: xen-devel@lists.xensource.com X-Mailman-Version: 2.1.5 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xensource.com Errors-To: xen-devel-bounces@lists.xensource.com On Tue, Sep 06, 2011 at 03:24:14PM +0800, MaoXiaoyun wrote: > > > Hi: > > I've met an ext4 Bug in dom0 kernel 2.6.32.36. (See kernel stack below) Did you try the 3.0 kernel? _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel From xen-devel-bounces@lists.xensource.com Tue Sep 06 08:02:14 2011 Return-path: Envelope-to: www-data@lists.xensource.com Delivery-date: Tue, 06 Sep 2011 08:02:14 -0700 Received: from localhost ([127.0.0.1] helo=lists.colo.xensource.com) by lists.xensource.com with esmtp (Exim 4.43) id 1R0xAD-0005sr-S5; Tue, 06 Sep 2011 08:02:13 -0700 Received: from mail182.messagelabs.com ([85.158.139.83]) by lists.xensource.com with esmtp (Exim 4.43) id 1R0x6T-0005dG-Qo for xen-devel@lists.xensource.com; Tue, 06 Sep 2011 07:58:24 -0700 X-Env-Sender: George.Dunlap@eu.citrix.com X-Msg-Ref: server-12.tower-182.messagelabs.com!1315321096!17125624!1 X-Originating-IP: [66.165.176.89] X-StarScan-Version: 6.3.6; banners=-,-,- X-VirusChecked: Checked Received: (qmail 1357 invoked from network); 6 Sep 2011 14:58:18 -0000 Received: from smtp.citrix.com (HELO SMTP.CITRIX.COM) (66.165.176.89) by server-12.tower-182.messagelabs.com with RC4-SHA encrypted SMTP; 6 Sep 2011 14:58:18 -0000 X-IronPort-AV: E=Sophos;i="4.68,338,1312171200"; d="scan'208";a="16723686" Received: from ftlpmailmx02.citrite.net ([10.13.107.66]) by FTLPIPO01.CITRIX.COM with ESMTP/TLS/RC4-MD5; 06 Sep 2011 10:58:16 -0400 Received: from smtp01.ad.xensource.com (10.219.128.104) by smtprelay.citrix.com (10.13.107.66) with Microsoft SMTP Server id 8.3.137.0; Tue, 6 Sep 2011 10:58:16 -0400 Received: from [127.0.1.1] (elijah.uk.xensource.com [10.80.2.24]) by smtp01.ad.xensource.com (8.13.1/8.13.1) with ESMTP id p86EwEfb022297; Tue, 6 Sep 2011 07:58:15 -0700 Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Mercurial-Node: 6ee237f744acebecf48ce42956f904796af2069e Message-ID: <6ee237f744acebecf48c.1315320749@elijah> User-Agent: Mercurial-patchbomb/1.4.3 Date: Tue, 6 Sep 2011 15:52:29 +0100 From: George Dunlap To: xen-devel@lists.xensource.com Cc: george.dunlap@eu.citrix.com Subject: [Xen-devel] [PATCH] Fix documentation build X-BeenThere: xen-devel@lists.xensource.com X-Mailman-Version: 2.1.5 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xensource.com Errors-To: xen-devel-bounces@lists.xensource.com Signed-off-by: George Dunlap diff -r 0268e7380953 -r 6ee237f744ac docs/src/user.tex --- a/docs/src/user.tex Mon Sep 05 15:10:28 2011 +0100 +++ b/docs/src/user.tex Tue Sep 06 15:52:20 2011 +0100 @@ -2280,7 +2280,7 @@ writing to the VGA console after domain \item [ vcpu\_migration\_delay=$<$minimum\_time$>$] Set minimum time of vcpu migration in microseconds (default 0). This parameter avoids agressive vcpu migration. For example, the linux kernel uses 0.5ms by default. -\item [ irq_vector_map=xxx ] Enable irq vector non-sharing maps. Setting 'global' +\item [ irq\_vector\_map=xxx ] Enable irq vector non-sharing maps. Setting 'global' will ensure that no IRQs will share vectors. Setting 'per-device' will ensure that no IRQs from the same device will share vectors. Setting to 'none' will disable it entirely, overriding any defaults the IOMMU code may set. _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel From xen-devel-bounces@lists.xensource.com Tue Sep 06 08:12:54 2011 Return-path: Envelope-to: www-data@lists.xensource.com Delivery-date: Tue, 06 Sep 2011 08:12:54 -0700 Received: from localhost ([127.0.0.1] helo=lists.colo.xensource.com) by lists.xensource.com with esmtp (Exim 4.43) id 1R0xKY-0006RY-KG; Tue, 06 Sep 2011 08:12:54 -0700 Received: from mail174.messagelabs.com ([85.158.138.51]) by lists.xensource.com with smtp (Exim 4.43) id 1R0xJh-0006Eu-6O for xen-devel@lists.xensource.com; Tue, 06 Sep 2011 08:12:03 -0700 X-Env-Sender: tinnycloud@hotmail.com X-Msg-Ref: server-8.tower-174.messagelabs.com!1315321917!16767552!1 X-Originating-IP: [65.55.116.22] X-StarScan-Version: 6.3.6; banners=-,-,- X-VirusChecked: Checked Received: (qmail 14698 invoked from network); 6 Sep 2011 15:11:57 -0000 Received: from blu0-omc1-s11.blu0.hotmail.com (HELO blu0-omc1-s11.blu0.hotmail.com) (65.55.116.22) by server-8.tower-174.messagelabs.com with SMTP; 6 Sep 2011 15:11:57 -0000 Received: from BLU157-W41 ([65.55.116.7]) by blu0-omc1-s11.blu0.hotmail.com with Microsoft SMTPSVC(6.0.3790.4675); Tue, 6 Sep 2011 08:11:56 -0700 Message-ID: X-Originating-IP: [115.195.35.9] From: MaoXiaoyun To: Date: Tue, 6 Sep 2011 23:11:56 +0800 Importance: Normal In-Reply-To: <20110906145347.GA4133@dumpdata.com> References: , <20110906145347.GA4133@dumpdata.com> MIME-Version: 1.0 X-OriginalArrivalTime: 06 Sep 2011 15:11:56.0879 (UTC) FILETIME=[5173E5F0:01CC6CA7] Cc: jeremy@goop.org, linux-ext4@vger.kernel.org, xen devel Subject: [Xen-devel] RE: ext4 BUG in dom0 Kernel 2.6.32.36 X-BeenThere: xen-devel@lists.xensource.com X-Mailman-Version: 2.1.5 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1819275364==" Sender: xen-devel-bounces@lists.xensource.com Errors-To: xen-devel-bounces@lists.xensource.com --===============1819275364== Content-Type: multipart/alternative; boundary="_88720937-3531-4584-a055-432612a6bc85_" --_88720937-3531-4584-a055-432612a6bc85_ Content-Type: text/plain; charset="gb2312" Content-Transfer-Encoding: 8bit > Date: Tue, 6 Sep 2011 10:53:47 -0400 > From: konrad.wilk@oracle.com > To: tinnycloud@hotmail.com > CC: linux-ext4@vger.kernel.org; xen-devel@lists.xensource.com; jeremy@goop.org > Subject: Re: ext4 BUG in dom0 Kernel 2.6.32.36 > > On Tue, Sep 06, 2011 at 03:24:14PM +0800, MaoXiaoyun wrote: > > > > > > Hi: > > > > I've met an ext4 Bug in dom0 kernel 2.6.32.36. (See kernel stack below) > > Did you try the 3.0 kernel? No, I am afried the change would be to much for our current env. May result in other stable issue. So, I want to dig out what really happen. Hopes. Thanks. --_88720937-3531-4584-a055-432612a6bc85_ Content-Type: text/html; charset="gb2312" Content-Transfer-Encoding: 8bit
 
> Date: Tue, 6 Sep 2011 10:53:47 -0400
> From: konrad.wilk@oracle.com
> To: tinnycloud@hotmail.com
> CC: linux-ext4@vger.kernel.org; xen-devel@lists.xensource.com; jeremy@goop.org
> Subject: Re: ext4 BUG in dom0 Kernel 2.6.32.36
>
> On Tue, Sep 06, 2011 at 03:24:14PM +0800, MaoXiaoyun wrote:
> >
> >
> > Hi:
> >
> > I've met an ext4 Bug in dom0 kernel 2.6.32.36. (See kernel stack below)
>
> Did you try the 3.0 kernel?
No,  I am afried the change would be to much for our current env.
May result in other stable issue.
So, I want to dig out what really happen. Hopes.
 
Thanks.
--_88720937-3531-4584-a055-432612a6bc85_-- --===============1819275364== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel --===============1819275364==-- From xen-devel-bounces@lists.xensource.com Tue Sep 06 08:17:44 2011 Return-path: Envelope-to: www-data@lists.xensource.com Delivery-date: Tue, 06 Sep 2011 08:17:44 -0700 Received: from localhost ([127.0.0.1] helo=lists.colo.xensource.com) by lists.xensource.com with esmtp (Exim 4.43) id 1R0xPE-0006sa-PG; Tue, 06 Sep 2011 08:17:44 -0700 Received: from mail21.messagelabs.com ([85.158.143.35]) by lists.xensource.com with esmtp (Exim 4.43) id 1R0xOX-0006fn-12 for xen-devel@lists.xensource.com; Tue, 06 Sep 2011 08:17:01 -0700 X-Env-Sender: JBeulich@suse.com X-Msg-Ref: server-13.tower-21.messagelabs.com!1315322212!47885003!1 X-Originating-IP: [130.57.49.28] X-StarScan-Version: 6.3.6; banners=-,-,- X-VirusChecked: Checked Received: (qmail 22065 invoked from network); 6 Sep 2011 15:16:52 -0000 Received: from nat28.tlf.novell.com (HELO nat28.tlf.novell.com) (130.57.49.28) by server-13.tower-21.messagelabs.com with DHE-RSA-AES256-SHA encrypted SMTP; 6 Sep 2011 15:16:52 -0000 Received: from EMEA1-MTA by nat28.tlf.novell.com with Novell_GroupWise; Tue, 06 Sep 2011 16:16:58 +0100 Message-Id: <4E66559E0200007800054D97@nat28.tlf.novell.com> X-Mailer: Novell GroupWise Internet Agent 8.0.1 Date: Tue, 06 Sep 2011 16:17:18 +0100 From: "Jan Beulich" To: "Andrew Cooper" , Subject: Re: [Xen-devel] struct irq_desc vs. struct irq_cfg References: <4E664B9D0200007800054D6D@nat28.tlf.novell.com> <4E6631B5.8030308@citrix.com> In-Reply-To: <4E6631B5.8030308@citrix.com> Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: quoted-printable Content-Disposition: inline Cc: X-BeenThere: xen-devel@lists.xensource.com X-Mailman-Version: 2.1.5 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xensource.com Errors-To: xen-devel-bounces@lists.xensource.com >>> On 06.09.11 at 16:44, Andrew Cooper wrote: > On 06/09/11 15:34, Jan Beulich wrote: >> Originally, iirc, struct irq_desc's chip_data pointer was intended to = be set=20 > to >> something specific to the struct hw_interrupt_type instance that's = being >> put into its handler pointer. Currently, however, struct irq_cfg is = being >> used universally (and carries data that is also intended to be = available)=20 > for >> all interrupt types. Wouldn't it make sense to move global data back = into >> struct irq_desc, or should we rather introduce a second pointer (e.g. >> handler_data) in struct irq_desc to allow handler specific context to = be >> stored? >=20 > I believe I asked this question in my long email about the direction of > irq cleanup (and if not, I certainly intended to) >=20 > As the inequality irq_desc[irq].chip-data =3D=3D irq_cfg[irq] is = maintained > at all times, merging the two would make sense, as well as removing many > needless indirections, and nr_irqs pointers. >=20 > Therefore, I vote to merge the two. >=20 > What were you considering to contain in the handler specific context? Actually I meanwhile think I can get away without - the places it's desirable are the various MSI sub-types (HPET, IOMMU), but there I can assume that only a single action instance exists for each IRQ, and hence I can equally well use desc->action->dev_id (I was really after being able to use what is already being put there from the various struct hw_interrupt_type actors, while perhaps also converting all of those to take a struct irq_desc * instead of the numerical IRQ as first argument). Jan _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel From xen-devel-bounces@lists.xensource.com Tue Sep 06 08:48:48 2011 Return-path: Envelope-to: www-data@lists.xensource.com Delivery-date: Tue, 06 Sep 2011 08:48:48 -0700 Received: from localhost ([127.0.0.1] helo=lists.colo.xensource.com) by lists.xensource.com with esmtp (Exim 4.43) id 1R0xtI-0008Qe-Ch; Tue, 06 Sep 2011 08:48:48 -0700 Received: from mail27.messagelabs.com ([193.109.254.147]) by lists.xensource.com with esmtp (Exim 4.43) id 1R0xsY-0008Dl-Hu for xen-devel@lists.xensource.com; Tue, 06 Sep 2011 08:48:02 -0700 X-Env-Sender: dunlapg@gmail.com X-Msg-Ref: server-4.tower-27.messagelabs.com!1315324063!39133090!1 X-Originating-IP: [74.125.82.171] X-StarScan-Version: 6.3.6; banners=-,-,- X-VirusChecked: Checked Received: (qmail 29631 invoked from network); 6 Sep 2011 15:47:43 -0000 Received: from mail-wy0-f171.google.com (HELO mail-wy0-f171.google.com) (74.125.82.171) by server-4.tower-27.messagelabs.com with RC4-SHA encrypted SMTP; 6 Sep 2011 15:47:43 -0000 Received: by wyh13 with SMTP id 13so5936955wyh.30 for ; Tue, 06 Sep 2011 08:47:59 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:sender:date:x-google-sender-auth:message-id:subject :from:to:content-type; bh=Ee2a7xGWBG0SzxdN34ECBQuUsU+IoTplvurvIgHRd2I=; b=LRS471AIyQkUXTu1PmWZkwQYStX9Qc9ssK2FDSK8LksiE+iem02SDddA3mLLcgammK 3fPnfJ0cvpcBKmS/g34m+/GwLHArT7j7pmbDqPWOCv8Yp5oh0WHJHbZeQmj/pWMhubnL kWbkUVFwBzDVeNwhR01ayC+q24NjdyVNWdQys= MIME-Version: 1.0 Received: by 10.216.178.11 with SMTP id e11mr755112wem.40.1315324079263; Tue, 06 Sep 2011 08:47:59 -0700 (PDT) Received: by 10.216.202.40 with HTTP; Tue, 6 Sep 2011 08:47:59 -0700 (PDT) Date: Tue, 6 Sep 2011 16:47:59 +0100 X-Google-Sender-Auth: 0sBJk05IkVRTgYbS9Rv3-Tmpjpk Message-ID: From: George Dunlap To: Wei Wang2 , xen-devel@lists.xensource.com Content-Type: text/plain; charset=ISO-8859-1 Cc: Subject: [Xen-devel] AMD IOMMU intremap tables and IOAPICs X-BeenThere: xen-devel@lists.xensource.com X-Mailman-Version: 2.1.5 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xensource.com Errors-To: xen-devel-bounces@lists.xensource.com Wei, Quick question: Am I reading the code correctly, that even with per-device interrupt remap tables, that GSIs are accounted to the intremap table of the corresponding IOAPIC, presumably because the IOMMU sees interrupts generated as GSIs as coming from the IOAPIC? In that case, then we need all devices sharing the same IOAPIC must not have any vector collisions. Is that correct? -George _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel From xen-devel-bounces@lists.xensource.com Tue Sep 06 08:50:00 2011 Return-path: Envelope-to: www-data@lists.xensource.com Delivery-date: Tue, 06 Sep 2011 08:50:00 -0700 Received: from localhost ([127.0.0.1] helo=lists.colo.xensource.com) by lists.xensource.com with esmtp (Exim 4.43) id 1R0xuS-0000M2-7Z; Tue, 06 Sep 2011 08:50:00 -0700 Received: from mail174.messagelabs.com ([85.158.138.51]) by lists.xensource.com with esmtp (Exim 4.43) id 1R0xtz-00009l-A8 for xen-devel@lists.xensource.com; Tue, 06 Sep 2011 08:49:31 -0700 X-Env-Sender: dan.magenheimer@oracle.com X-Msg-Ref: server-13.tower-174.messagelabs.com!1315324164!30461098!1 X-Originating-IP: [141.146.126.227] X-StarScan-Version: 6.3.6; banners=-,-,- X-VirusChecked: Checked Received: (qmail 17730 invoked from network); 6 Sep 2011 15:49:27 -0000 Received: from acsinet15.oracle.com (HELO acsinet15.oracle.com) (141.146.126.227) by server-13.tower-174.messagelabs.com with DHE-RSA-AES256-SHA encrypted SMTP; 6 Sep 2011 15:49:27 -0000 Received: from rtcsinet21.oracle.com (rtcsinet21.oracle.com [66.248.204.29]) by acsinet15.oracle.com (Switch-3.4.4/Switch-3.4.4) with ESMTP id p86FnKrq030150 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Tue, 6 Sep 2011 15:49:22 GMT Received: from acsmt356.oracle.com (acsmt356.oracle.com [141.146.40.156]) by rtcsinet21.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id p86FnJVB018893 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 6 Sep 2011 15:49:19 GMT Received: from abhmt107.oracle.com (abhmt107.oracle.com [141.146.116.59]) by acsmt356.oracle.com (8.12.11.20060308/8.12.11) with ESMTP id p86FnD2Y015939; Tue, 6 Sep 2011 10:49:13 -0500 MIME-Version: 1.0 Message-ID: <36a5b662-4420-41aa-be01-445f83b15a7b@default> Date: Tue, 6 Sep 2011 08:49:07 -0700 (PDT) From: Dan Magenheimer To: Rafal Wojtczuk , xen-devel@lists.xensource.com Subject: RE: [Xen-devel] dom0 is stalled until a keypress References: <20110905091937.GA1906@email> In-Reply-To: <20110905091937.GA1906@email> X-Priority: 3 X-Mailer: Oracle Beehive Extensions for Outlook 2.0.1.4.1.0 (410211) [OL 12.0.6557.5001] Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable X-Source-IP: rtcsinet21.oracle.com [66.248.204.29] X-CT-RefId: str=0001.0A090205.4E664102.0143,ss=1,re=0.000,fgs=0 Cc: X-BeenThere: xen-devel@lists.xensource.com X-Mailman-Version: 2.1.5 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xensource.com Errors-To: xen-devel-bounces@lists.xensource.com > From: Rafal Wojtczuk [mailto:rafal@invisiblethingslab.com] > Sent: Monday, September 05, 2011 3:20 AM > To: xen-devel@lists.xensource.com > Subject: [Xen-devel] dom0 is stalled until a keypress >=20 > Hello, > The following bizarre behaviour was observed on xen4.1+suse dom0 2.6.38, = on > an old Core Duo laptop; maybe someone can hint what is wrong. > Dom0 boot stalls after an init.d script prints "Starting udev". Then noth= ing > seems to happen. I need to press any key to observe progress - I need to = do > it tens of times for the boot to finish. After X starts fine, then there = is > no need for keypressing anymore. > A particularly disturbing fact is that qrexec_daemon parent, that basical= ly > does > for (;;) { sleep(1); fprintf(stderr, "."); } > does not print dots, until a keypress arrives. So something is very wrong > with timers. > Somehow similarly, pm-suspend sometimes hangs at some stage - after detac= hing > power cord, machine enters S3 immediately. > This is vaguely similar to the issue described in > https://lkml.org/lkml/2008/9/14/122 > but this time, "nohz=3Doff" does not help. >=20 > "cpufreq=3Ddom0-kernel" cures the symptoms; but it is not a sideeffectles= s > solution. Any idea what is going on or how to debug it ? ISTR seeing this on a Core(2?)Duo laptop and I think the workaround was setting max_cstate=3D0 (as Xen boot parameter). _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel From xen-devel-bounces@lists.xensource.com Tue Sep 06 08:55:14 2011 Return-path: Envelope-to: www-data@lists.xensource.com Delivery-date: Tue, 06 Sep 2011 08:55:14 -0700 Received: from localhost ([127.0.0.1] helo=lists.colo.xensource.com) by lists.xensource.com with esmtp (Exim 4.43) id 1R0xzW-0000sx-4I; Tue, 06 Sep 2011 08:55:14 -0700 Received: from mail174.messagelabs.com ([85.158.138.51]) by lists.xensource.com with esmtp (Exim 4.43) id 1R0xyy-0000gI-D1 for xen-devel@lists.xensource.com; Tue, 06 Sep 2011 08:54:41 -0700 X-Env-Sender: Andrew.Cooper3@citrix.com X-Msg-Ref: server-7.tower-174.messagelabs.com!1315324474!30427338!1 X-Originating-IP: [66.165.176.89] X-StarScan-Version: 6.3.6; banners=-,-,- X-VirusChecked: Checked Received: (qmail 16274 invoked from network); 6 Sep 2011 15:54:37 -0000 Received: from smtp.citrix.com (HELO SMTP.CITRIX.COM) (66.165.176.89) by server-7.tower-174.messagelabs.com with RC4-SHA encrypted SMTP; 6 Sep 2011 15:54:37 -0000 X-IronPort-AV: E=Sophos;i="4.68,339,1312171200"; d="scan'208";a="16725862" Received: from ftlpmailmx02.citrite.net ([10.13.107.66]) by FTLPIPO01.CITRIX.COM with ESMTP/TLS/RC4-MD5; 06 Sep 2011 11:54:18 -0400 Received: from [10.80.2.18] (10.80.2.18) by FTLPMAILMX02.citrite.net (10.13.107.66) with Microsoft SMTP Server id 8.3.137.0; Tue, 6 Sep 2011 11:54:18 -0400 Message-ID: <4E664228.5070606@citrix.com> Date: Tue, 6 Sep 2011 16:54:16 +0100 From: Andrew Cooper User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.2.21) Gecko/20110831 Lightning/1.0b2 Thunderbird/3.1.13 MIME-Version: 1.0 To: Subject: Re: [Xen-devel] AMD IOMMU intremap tables and IOAPICs References: In-Reply-To: Content-Type: text/plain; charset="ISO-8859-1" Content-Transfer-Encoding: 7bit Cc: George Dunlap X-BeenThere: xen-devel@lists.xensource.com X-Mailman-Version: 2.1.5 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xensource.com Errors-To: xen-devel-bounces@lists.xensource.com On 06/09/11 16:47, George Dunlap wrote: > Wei, > > Quick question: Am I reading the code correctly, that even with > per-device interrupt remap tables, that GSIs are accounted to the > intremap table of the corresponding IOAPIC, presumably because the > IOMMU sees interrupts generated as GSIs as coming from the IOAPIC? In > that case, then we need all devices sharing the same IOAPIC must not > have any vector collisions. Is that correct? Based on the ICH10 IO-APIC documentation with respect to auto EOIs, we cant have any two IRQs across any IO-APICs sharing a vector, irrespective of IOMMU or not. (Because the EOI'ing an IO-APIC entry only takes account of vector and not destination) If we were to disable the auto EOI broadcast and do manual EOI'ing (only available on newer versions of the local apic) then we could reduce that restriction to "no two IRQs in the same IO-APIC may share a vector". ~Andrew > -George > > _______________________________________________ > Xen-devel mailing list > Xen-devel@lists.xensource.com > http://lists.xensource.com/xen-devel -- Andrew Cooper - Dom0 Kernel Engineer, Citrix XenServer T: +44 (0)1223 225 900, http://www.citrix.com _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel From xen-devel-bounces@lists.xensource.com Tue Sep 06 08:59:29 2011 Return-path: Envelope-to: www-data@lists.xensource.com Delivery-date: Tue, 06 Sep 2011 08:59:29 -0700 Received: from localhost ([127.0.0.1] helo=lists.colo.xensource.com) by lists.xensource.com with esmtp (Exim 4.43) id 1R0y3d-0001Ju-7O; Tue, 06 Sep 2011 08:59:29 -0700 Received: from mail182.messagelabs.com ([85.158.139.83]) by lists.xensource.com with esmtp (Exim 4.43) id 1R0y1u-00016Q-AO for xen-devel@lists.xensource.com; Tue, 06 Sep 2011 08:57:43 -0700 X-Env-Sender: dunlapg@gmail.com X-Msg-Ref: server-6.tower-182.messagelabs.com!1315324659!17270687!1 X-Originating-IP: [74.125.82.171] X-StarScan-Version: 6.3.6; banners=-,-,- X-VirusChecked: Checked Received: (qmail 3008 invoked from network); 6 Sep 2011 15:57:39 -0000 Received: from mail-wy0-f171.google.com (HELO mail-wy0-f171.google.com) (74.125.82.171) by server-6.tower-182.messagelabs.com with RC4-SHA encrypted SMTP; 6 Sep 2011 15:57:39 -0000 Received: by wyh13 with SMTP id 13so5946599wyh.30 for ; Tue, 06 Sep 2011 08:57:39 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=PTSXQyQ89NENVE76Nsaxz+SI0QULRstTgeiLviXssHY=; b=Aa6MxduD6KHtIApQ3XgH6v/dKuLVRCQQTtS21RZThSHFG6OTuOzmHg46RKZDX8jWb1 N+U+qs4JBiYmWwzRS1hEtV7C5RB0nE4mNcg9SCoRhxn6v5wrQoKWHbrXCSyOTjanG1tY BXn5PtBPm1nWRmS7ZvsEdmJMyG4AttDIpBN8w= MIME-Version: 1.0 Received: by 10.216.171.204 with SMTP id r54mr960093wel.55.1315324658864; Tue, 06 Sep 2011 08:57:38 -0700 (PDT) Received: by 10.216.202.40 with HTTP; Tue, 6 Sep 2011 08:57:38 -0700 (PDT) In-Reply-To: <4E664228.5070606@citrix.com> References: <4E664228.5070606@citrix.com> Date: Tue, 6 Sep 2011 16:57:38 +0100 X-Google-Sender-Auth: fcJTJaCu5dYZOsDdbIxTncMZsZ4 Message-ID: Subject: Re: [Xen-devel] AMD IOMMU intremap tables and IOAPICs From: George Dunlap To: Andrew Cooper Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: xen-devel@lists.xensource.com X-BeenThere: xen-devel@lists.xensource.com X-Mailman-Version: 2.1.5 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xensource.com Errors-To: xen-devel-bounces@lists.xensource.com On Tue, Sep 6, 2011 at 4:54 PM, Andrew Cooper w= rote: > On 06/09/11 16:47, George Dunlap wrote: >> Wei, >> >> Quick question: =A0Am I reading the code correctly, that even with >> per-device interrupt remap tables, that GSIs are accounted to the >> intremap table of the corresponding IOAPIC, presumably because the >> IOMMU sees interrupts generated as GSIs as coming from the IOAPIC? =A0In >> that case, then we need all devices sharing the same IOAPIC must not >> have any vector collisions. =A0Is that correct? > > Based on the ICH10 IO-APIC documentation with respect to auto EOIs, we > cant have any two IRQs across any IO-APICs sharing a vector, > irrespective of IOMMU or not. =A0(Because the EOI'ing an IO-APIC entry > only takes account of vector and not destination) > > If we were to disable the auto EOI broadcast and do manual EOI'ing (only > available on newer versions of the local apic) then we could reduce that > restriction to "no two IRQs in the same IO-APIC may share a vector". Hmm, so it sounds like enforcing non-sharing of vectors within a single IOAPIC is something we probably want to do even when we're not using an AMD IOMMU? -George _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel From xen-devel-bounces@lists.xensource.com Tue Sep 06 09:06:19 2011 Return-path: Envelope-to: www-data@lists.xensource.com Delivery-date: Tue, 06 Sep 2011 09:06:19 -0700 Received: from localhost ([127.0.0.1] helo=lists.colo.xensource.com) by lists.xensource.com with esmtp (Exim 4.43) id 1R0yAD-0001mJ-TS; Tue, 06 Sep 2011 09:06:17 -0700 Received: from mail21.messagelabs.com ([85.158.143.35]) by lists.xensource.com with esmtp (Exim 4.43) id 1R0y7d-0001XV-04 for xen-devel@lists.xensource.com; Tue, 06 Sep 2011 09:03:48 -0700 X-Env-Sender: Andrew.Cooper3@citrix.com X-Msg-Ref: server-3.tower-21.messagelabs.com!1315325024!50537841!1 X-Originating-IP: [66.165.176.89] X-StarScan-Version: 6.3.6; banners=-,-,- X-VirusChecked: Checked Received: (qmail 15391 invoked from network); 6 Sep 2011 16:03:45 -0000 Received: from smtp.citrix.com (HELO SMTP.CITRIX.COM) (66.165.176.89) by server-3.tower-21.messagelabs.com with RC4-SHA encrypted SMTP; 6 Sep 2011 16:03:45 -0000 X-IronPort-AV: E=Sophos;i="4.68,339,1312171200"; d="scan'208";a="16726232" Received: from ftlpmailmx02.citrite.net ([10.13.107.66]) by FTLPIPO01.CITRIX.COM with ESMTP/TLS/RC4-MD5; 06 Sep 2011 12:03:32 -0400 Received: from [10.80.2.18] (10.80.2.18) by FTLPMAILMX02.citrite.net (10.13.107.66) with Microsoft SMTP Server id 8.3.137.0; Tue, 6 Sep 2011 12:03:32 -0400 Message-ID: <4E664452.9020005@citrix.com> Date: Tue, 6 Sep 2011 17:03:30 +0100 From: Andrew Cooper User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.2.21) Gecko/20110831 Lightning/1.0b2 Thunderbird/3.1.13 MIME-Version: 1.0 To: George Dunlap Subject: Re: [Xen-devel] AMD IOMMU intremap tables and IOAPICs References: <4E664228.5070606@citrix.com> In-Reply-To: Content-Type: text/plain; charset="ISO-8859-1" Content-Transfer-Encoding: 7bit Cc: "xen-devel@lists.xensource.com" X-BeenThere: xen-devel@lists.xensource.com X-Mailman-Version: 2.1.5 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xensource.com Errors-To: xen-devel-bounces@lists.xensource.com On 06/09/11 16:57, George Dunlap wrote: > On Tue, Sep 6, 2011 at 4:54 PM, Andrew Cooper wrote: >> On 06/09/11 16:47, George Dunlap wrote: >>> Wei, >>> >>> Quick question: Am I reading the code correctly, that even with >>> per-device interrupt remap tables, that GSIs are accounted to the >>> intremap table of the corresponding IOAPIC, presumably because the >>> IOMMU sees interrupts generated as GSIs as coming from the IOAPIC? In >>> that case, then we need all devices sharing the same IOAPIC must not >>> have any vector collisions. Is that correct? >> Based on the ICH10 IO-APIC documentation with respect to auto EOIs, we >> cant have any two IRQs across any IO-APICs sharing a vector, >> irrespective of IOMMU or not. (Because the EOI'ing an IO-APIC entry >> only takes account of vector and not destination) >> >> If we were to disable the auto EOI broadcast and do manual EOI'ing (only >> available on newer versions of the local apic) then we could reduce that >> restriction to "no two IRQs in the same IO-APIC may share a vector". > Hmm, so it sounds like enforcing non-sharing of vectors within a > single IOAPIC is something we probably want to do even when we're not > using an AMD IOMMU? > > -George Currently there is no code to disable auto EOI and do manual EOI instead. As a result, we should enforce non-sharing of vectors across all IO-APICs. It was on my irq cleanup list but seems to be a specific problem for you at the moment. -- Andrew Cooper - Dom0 Kernel Engineer, Citrix XenServer T: +44 (0)1223 225 900, http://www.citrix.com _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel From xen-devel-bounces@lists.xensource.com Tue Sep 06 09:07:27 2011 Return-path: Envelope-to: www-data@lists.xensource.com Delivery-date: Tue, 06 Sep 2011 09:07:27 -0700 Received: from localhost ([127.0.0.1] helo=lists.colo.xensource.com) by lists.xensource.com with esmtp (Exim 4.43) id 1R0yBL-00029u-QF; Tue, 06 Sep 2011 09:07:27 -0700 Received: from mail216.messagelabs.com ([85.158.143.99]) by lists.xensource.com with esmtp (Exim 4.43) id 1R0y9u-0001jN-Sf for xen-devel@lists.xensource.com; Tue, 06 Sep 2011 09:06:00 -0700 X-Env-Sender: George.Dunlap@eu.citrix.com X-Msg-Ref: server-7.tower-216.messagelabs.com!1315325154!17280452!1 X-Originating-IP: [66.165.176.89] X-StarScan-Version: 6.3.6; banners=-,-,- X-VirusChecked: Checked Received: (qmail 21971 invoked from network); 6 Sep 2011 16:05:55 -0000 Received: from smtp.citrix.com (HELO SMTP.CITRIX.COM) (66.165.176.89) by server-7.tower-216.messagelabs.com with RC4-SHA encrypted SMTP; 6 Sep 2011 16:05:55 -0000 X-IronPort-AV: E=Sophos;i="4.68,339,1312171200"; d="scan'208";a="16726297" Received: from ftlpmailmx02.citrite.net ([10.13.107.66]) by FTLPIPO01.CITRIX.COM with ESMTP/TLS/RC4-MD5; 06 Sep 2011 12:05:54 -0400 Received: from smtp01.ad.xensource.com (10.219.128.104) by smtprelay.citrix.com (10.13.107.66) with Microsoft SMTP Server id 8.3.137.0; Tue, 6 Sep 2011 12:05:54 -0400 Received: from [10.80.2.24] (elijah.uk.xensource.com [10.80.2.24]) by smtp01.ad.xensource.com (8.13.1/8.13.1) with ESMTP id p86G5pPq022467; Tue, 6 Sep 2011 09:05:52 -0700 Subject: Re: [Xen-devel] AMD IOMMU intremap tables and IOAPICs From: George Dunlap To: Andrew Cooper In-Reply-To: <4E664452.9020005@citrix.com> References: <4E664228.5070606@citrix.com> <4E664452.9020005@citrix.com> Content-Type: text/plain; charset="UTF-8" Date: Tue, 6 Sep 2011 17:00:06 +0100 Message-ID: <1315324806.11099.1.camel@elijah> MIME-Version: 1.0 X-Mailer: Evolution 2.28.3 Content-Transfer-Encoding: 7bit Cc: George Dunlap , "xen-devel@lists.xensource.com" X-BeenThere: xen-devel@lists.xensource.com X-Mailman-Version: 2.1.5 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xensource.com Errors-To: xen-devel-bounces@lists.xensource.com On Tue, 2011-09-06 at 17:03 +0100, Andrew Cooper wrote: > On 06/09/11 16:57, George Dunlap wrote: > > On Tue, Sep 6, 2011 at 4:54 PM, Andrew Cooper wrote: > >> On 06/09/11 16:47, George Dunlap wrote: > >>> Wei, > >>> > >>> Quick question: Am I reading the code correctly, that even with > >>> per-device interrupt remap tables, that GSIs are accounted to the > >>> intremap table of the corresponding IOAPIC, presumably because the > >>> IOMMU sees interrupts generated as GSIs as coming from the IOAPIC? In > >>> that case, then we need all devices sharing the same IOAPIC must not > >>> have any vector collisions. Is that correct? > >> Based on the ICH10 IO-APIC documentation with respect to auto EOIs, we > >> cant have any two IRQs across any IO-APICs sharing a vector, > >> irrespective of IOMMU or not. (Because the EOI'ing an IO-APIC entry > >> only takes account of vector and not destination) > >> > >> If we were to disable the auto EOI broadcast and do manual EOI'ing (only > >> available on newer versions of the local apic) then we could reduce that > >> restriction to "no two IRQs in the same IO-APIC may share a vector". > > Hmm, so it sounds like enforcing non-sharing of vectors within a > > single IOAPIC is something we probably want to do even when we're not > > using an AMD IOMMU? > > > > -George > > Currently there is no code to disable auto EOI and do manual EOI > instead. As a result, we should enforce non-sharing of vectors across > all IO-APICs. It was on my irq cleanup list but seems to be a specific > problem for you at the moment. My problem doesn't have anything to do with EOIs, but with the AMD IOMMU interrupt remapping table, and a device driver which simply dies if it misses any interrupts. If we can kill two birds with one stone, all the better. -George _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel From xen-devel-bounces@lists.xensource.com Tue Sep 06 09:08:21 2011 Return-path: Envelope-to: www-data@lists.xensource.com Delivery-date: Tue, 06 Sep 2011 09:08:21 -0700 Received: from localhost ([127.0.0.1] helo=lists.colo.xensource.com) by lists.xensource.com with esmtp (Exim 4.43) id 1R0yCD-0002Wd-9c; Tue, 06 Sep 2011 09:08:21 -0700 Received: from mail27.messagelabs.com ([193.109.254.147]) by lists.xensource.com with esmtp (Exim 4.43) id 1R0yAD-0001l7-40 for xen-devel@lists.xensource.com; Tue, 06 Sep 2011 09:06:17 -0700 X-Env-Sender: tim@xen.org X-Msg-Ref: server-12.tower-27.messagelabs.com!1315325160!41313053!1 X-Originating-IP: [81.29.64.94] X-StarScan-Version: 6.3.6; banners=-,-,- X-VirusChecked: Checked Received: (qmail 2327 invoked from network); 6 Sep 2011 16:06:00 -0000 Received: from ocelot.phlegethon.org (HELO mail.phlegethon.org) (81.29.64.94) by server-12.tower-27.messagelabs.com with DHE-RSA-AES256-SHA encrypted SMTP; 6 Sep 2011 16:06:00 -0000 Received: from tjd by mail.phlegethon.org with local (Exim 4.67 (FreeBSD)) (envelope-from ) id 1R0yA8-00058j-Hl; Tue, 06 Sep 2011 16:06:12 +0000 Date: Tue, 6 Sep 2011 17:06:12 +0100 From: Tim Deegan To: Andrew Cooper Subject: Re: [Xen-devel] AMD IOMMU intremap tables and IOAPICs Message-ID: <20110906160612.GA12835@ocelot.phlegethon.org> References: <4E664228.5070606@citrix.com> Mime-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline In-Reply-To: <4E664228.5070606@citrix.com> User-Agent: Mutt/1.4.2.1i Cc: George Dunlap , xen-devel@lists.xensource.com X-BeenThere: xen-devel@lists.xensource.com X-Mailman-Version: 2.1.5 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xensource.com Errors-To: xen-devel-bounces@lists.xensource.com At 16:54 +0100 on 06 Sep (1315328056), Andrew Cooper wrote: > On 06/09/11 16:47, George Dunlap wrote: > > Wei, > > > > Quick question: Am I reading the code correctly, that even with > > per-device interrupt remap tables, that GSIs are accounted to the > > intremap table of the corresponding IOAPIC, presumably because the > > IOMMU sees interrupts generated as GSIs as coming from the IOAPIC? In > > that case, then we need all devices sharing the same IOAPIC must not > > have any vector collisions. Is that correct? > > Based on the ICH10 IO-APIC documentation with respect to auto EOIs, we > cant have any two IRQs across any IO-APICs sharing a vector, > irrespective of IOMMU or not. (Because the EOI'ing an IO-APIC entry > only takes account of vector and not destination) If this is the case, is there any point in having per-CPU IDTs? Or per-device remapping tables? Tim. _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel From xen-devel-bounces@lists.xensource.com Tue Sep 06 09:10:19 2011 Return-path: Envelope-to: www-data@lists.xensource.com Delivery-date: Tue, 06 Sep 2011 09:10:19 -0700 Received: from localhost ([127.0.0.1] helo=lists.colo.xensource.com) by lists.xensource.com with esmtp (Exim 4.43) id 1R0yE7-0002uz-0k; Tue, 06 Sep 2011 09:10:19 -0700 Received: from mail182.messagelabs.com ([85.158.139.83]) by lists.xensource.com with esmtp (Exim 4.43) id 1R0yDR-0002iK-7Z for xen-devel@lists.xensource.com; Tue, 06 Sep 2011 09:09:37 -0700 X-Env-Sender: George.Dunlap@eu.citrix.com X-Msg-Ref: server-14.tower-182.messagelabs.com!1315325372!17119507!1 X-Originating-IP: [66.165.176.89] X-StarScan-Version: 6.3.6; banners=-,-,- X-VirusChecked: Checked Received: (qmail 31864 invoked from network); 6 Sep 2011 16:09:34 -0000 Received: from smtp.citrix.com (HELO SMTP.CITRIX.COM) (66.165.176.89) by server-14.tower-182.messagelabs.com with RC4-SHA encrypted SMTP; 6 Sep 2011 16:09:34 -0000 X-IronPort-AV: E=Sophos;i="4.68,339,1312171200"; d="scan'208";a="16726423" Received: from ftlpmailmx02.citrite.net ([10.13.107.66]) by FTLPIPO01.CITRIX.COM with ESMTP/TLS/RC4-MD5; 06 Sep 2011 12:09:28 -0400 Received: from smtp01.ad.xensource.com (10.219.128.104) by smtprelay.citrix.com (10.13.107.66) with Microsoft SMTP Server id 8.3.137.0; Tue, 6 Sep 2011 12:09:28 -0400 Received: from [10.80.2.24] (elijah.uk.xensource.com [10.80.2.24]) by smtp01.ad.xensource.com (8.13.1/8.13.1) with ESMTP id p86G9QG3022476; Tue, 6 Sep 2011 09:09:27 -0700 Subject: Re: [Xen-devel] AMD IOMMU intremap tables and IOAPICs From: George Dunlap To: Tim Deegan In-Reply-To: <20110906160612.GA12835@ocelot.phlegethon.org> References: <4E664228.5070606@citrix.com> <20110906160612.GA12835@ocelot.phlegethon.org> Content-Type: text/plain; charset="UTF-8" Date: Tue, 6 Sep 2011 17:03:41 +0100 Message-ID: <1315325021.11099.2.camel@elijah> MIME-Version: 1.0 X-Mailer: Evolution 2.28.3 Content-Transfer-Encoding: 7bit Cc: George Dunlap , Andrew Cooper , "xen-devel@lists.xensource.com" X-BeenThere: xen-devel@lists.xensource.com X-Mailman-Version: 2.1.5 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xensource.com Errors-To: xen-devel-bounces@lists.xensource.com On Tue, 2011-09-06 at 17:06 +0100, Tim Deegan wrote: > At 16:54 +0100 on 06 Sep (1315328056), Andrew Cooper wrote: > > On 06/09/11 16:47, George Dunlap wrote: > > > Wei, > > > > > > Quick question: Am I reading the code correctly, that even with > > > per-device interrupt remap tables, that GSIs are accounted to the > > > intremap table of the corresponding IOAPIC, presumably because the > > > IOMMU sees interrupts generated as GSIs as coming from the IOAPIC? In > > > that case, then we need all devices sharing the same IOAPIC must not > > > have any vector collisions. Is that correct? > > > > Based on the ICH10 IO-APIC documentation with respect to auto EOIs, we > > cant have any two IRQs across any IO-APICs sharing a vector, > > irrespective of IOMMU or not. (Because the EOI'ing an IO-APIC entry > > only takes account of vector and not destination) > > If this is the case, is there any point in having per-CPU IDTs? > Or per-device remapping tables? Yes, for devices that use MSIs, at least. -George _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel From xen-devel-bounces@lists.xensource.com Tue Sep 06 09:11:26 2011 Return-path: Envelope-to: www-data@lists.xensource.com Delivery-date: Tue, 06 Sep 2011 09:11:26 -0700 Received: from localhost ([127.0.0.1] helo=lists.colo.xensource.com) by lists.xensource.com with esmtp (Exim 4.43) id 1R0yFC-0003IH-Nj; Tue, 06 Sep 2011 09:11:26 -0700 Received: from mail27.messagelabs.com ([193.109.254.147]) by lists.xensource.com with smtp (Exim 4.43) id 1R0yEm-00035Y-1b for xen-devel@lists.xensource.com; Tue, 06 Sep 2011 09:11:00 -0700 X-Env-Sender: Stefano.Stabellini@eu.citrix.com X-Msg-Ref: server-4.tower-27.messagelabs.com!1315325440!39135712!1 X-Originating-IP: [62.200.22.115] X-StarScan-Version: 6.3.6; banners=-,-,- X-VirusChecked: Checked Received: (qmail 20729 invoked from network); 6 Sep 2011 16:10:40 -0000 Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115) by server-4.tower-27.messagelabs.com with SMTP; 6 Sep 2011 16:10:40 -0000 X-IronPort-AV: E=Sophos;i="4.68,339,1312156800"; d="scan'208";a="7632134" Received: from lonpmailmx01.citrite.net ([10.30.203.162]) by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5; 06 Sep 2011 16:10:57 +0000 Received: from kaball.uk.xensource.com (10.80.2.59) by LONPMAILMX01.citrite.net (10.30.203.162) with Microsoft SMTP Server id 8.3.137.0; Tue, 6 Sep 2011 17:10:56 +0100 Date: Tue, 6 Sep 2011 17:19:01 +0100 From: Stefano Stabellini X-X-Sender: sstabellini@kaball-desktop To: Konrad Rzeszutek Wilk In-Reply-To: <20110809023407.GA13905@dumpdata.com> Message-ID: References: <1311699345-32579-1-git-send-email-stefano.stabellini@eu.citrix.com> <20110809023407.GA13905@dumpdata.com> User-Agent: Alpine 2.00 (DEB 1167 2008-08-23) MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Cc: "xen-devel@lists.xensource.com" , Jeremy, Stefano Stabellini , "linux-kernel@vger.kernel.org" , Ian Campbell , Fitzhardinge Subject: [Xen-devel] Re: [PATCH] xen: modify kernel mappings corresponding to granted pages X-BeenThere: xen-devel@lists.xensource.com X-Mailman-Version: 2.1.5 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xensource.com Errors-To: xen-devel-bounces@lists.xensource.com On Tue, 9 Aug 2011, Konrad Rzeszutek Wilk wrote: > On Tue, Jul 26, 2011 at 05:55:45PM +0100, stefano.stabellini@eu.citrix.com wrote: > > From: Stefano Stabellini > > > > If we want to use granted pages for AIO, changing the mappings of a user > > vma and the corresponding p2m is not enough, we also need to update the > > kernel mappings accordingly. > > On x86_64 it is easy, we can issue another HYPERVISOR_grant_table_op > > right away in m2p_add_override. We can remove the mappings using another > > HYPERVISOR_grant_table_op in m2p_remove_override. > > On x86_32 it is more difficult because the pages are highmem pages and > > therefore we need to catch the set_pte that tries to map a granted page > > and issue an HYPERVISOR_grant_table_op instead. > > Same thing for unmapping them: we need to catch the pte clear or the > > set_pte that try to unmap a granted page and issue an > > HYPERVISOR_grant_table_op. > > So I hadn't looked at this in detail, but I wonder if we can use the > MULTIcall for this? It looks like we need to do two hypercalls so why > not batch it? It wasn't easy but I managed to use multicalls in both m2p override and the highmem counterparts in xen/mmu.c. I'll send the multicall changes as a separate patch because I think is going to be easier to read. _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel From xen-devel-bounces@lists.xensource.com Tue Sep 06 09:12:13 2011 Return-path: Envelope-to: www-data@lists.xensource.com Delivery-date: Tue, 06 Sep 2011 09:12:13 -0700 Received: from localhost ([127.0.0.1] helo=lists.colo.xensource.com) by lists.xensource.com with esmtp (Exim 4.43) id 1R0yFx-0003fe-MC; Tue, 06 Sep 2011 09:12:13 -0700 Received: from mail216.messagelabs.com ([85.158.143.99]) by lists.xensource.com with esmtp (Exim 4.43) id 1R0yF6-0003EY-3o for xen-devel@lists.xensource.com; Tue, 06 Sep 2011 09:11:20 -0700 X-Env-Sender: Stefano.Stabellini@eu.citrix.com X-Msg-Ref: server-10.tower-216.messagelabs.com!1315325475!9201429!1 X-Originating-IP: [66.165.176.89] X-StarScan-Version: 6.3.6; banners=-,-,- X-VirusChecked: Checked Received: (qmail 29042 invoked from network); 6 Sep 2011 16:11:16 -0000 Received: from smtp.citrix.com (HELO SMTP.CITRIX.COM) (66.165.176.89) by server-10.tower-216.messagelabs.com with RC4-SHA encrypted SMTP; 6 Sep 2011 16:11:16 -0000 X-IronPort-AV: E=Sophos;i="4.68,339,1312171200"; d="scan'208";a="16726481" Received: from ftlpmailmx02.citrite.net ([10.13.107.66]) by FTLPIPO01.CITRIX.COM with ESMTP/TLS/RC4-MD5; 06 Sep 2011 12:11:15 -0400 Received: from smtp01.ad.xensource.com (10.219.128.104) by smtprelay.citrix.com (10.13.107.66) with Microsoft SMTP Server id 8.3.137.0; Tue, 6 Sep 2011 12:11:15 -0400 Received: from localhost.localdomain (kaball.uk.xensource.com [10.80.2.59]) by smtp01.ad.xensource.com (8.13.1/8.13.1) with ESMTP id p86GBARq022485; Tue, 6 Sep 2011 09:11:13 -0700 From: To: linux-kernel@vger.kernel.org Date: Tue, 6 Sep 2011 17:19:29 +0100 Message-ID: <1315325969-32346-2-git-send-email-stefano.stabellini@eu.citrix.com> X-Mailer: git-send-email 1.7.0.4 In-Reply-To: <1315325969-32346-1-git-send-email-stefano.stabellini@eu.citrix.com> References: <1315325969-32346-1-git-send-email-stefano.stabellini@eu.citrix.com> MIME-Version: 1.0 Content-Type: text/plain Cc: Ian.Campbell@eu.citrix.com, xen-devel@lists.xensource.com, Jeremy.Fitzhardinge@citrix.com, stefano.stabellini@eu.citrix.com, konrad.wilk@oracle.com Subject: [Xen-devel] [PATCH v2 2/2] xen: use multicalls for m2p override grant table ops X-BeenThere: xen-devel@lists.xensource.com X-Mailman-Version: 2.1.5 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xensource.com Errors-To: xen-devel-bounces@lists.xensource.com From: Stefano Stabellini Replace the HYPERVISOR_grant_table_op hypercalls with multicalls. Use the kmap_op pointer directly as argument to do the mapping as it is guaranteed to be present up until the unmapping is done. The mapping can be done either by m2p_add_override, in case of !PageHighMem, or in __xen_set_pte otherwise. Before issuing any unmapping multicalls, we need to make sure that the mapping has already being done, because we need the kmap->handle to be set correctly. Also we need to do the unmapping before the page is removed from the m2p override, so we force the unmapping in m2p_remove_override even if PageHighMem. The value of map_op->host_addr can be used to know if the unmapping has already happened. Signed-off-by: Stefano Stabellini --- arch/x86/xen/mmu.c | 49 +++++++++++++++++++++++++++++------------- arch/x86/xen/p2m.c | 60 ++++++++++++++++++++++++++++++++------------------- 2 files changed, 72 insertions(+), 37 deletions(-) diff --git a/arch/x86/xen/mmu.c b/arch/x86/xen/mmu.c index e80dad5..b142315 100644 --- a/arch/x86/xen/mmu.c +++ b/arch/x86/xen/mmu.c @@ -317,18 +317,36 @@ static int xen_unmap_granted_page(pte_t *ptep) mfn = (ptep->pte & PTE_PFN_MASK) >> PAGE_SHIFT; page = m2p_find_override(mfn); if (page != NULL && (page->private & GRANT_FRAME_BIT)) { - int ret; - struct gnttab_unmap_grant_ref kunmap_op; struct gnttab_map_grant_ref *kmap_op = (struct gnttab_map_grant_ref *) page->index; - kunmap_op.host_addr = kmap_op->host_addr; - kunmap_op.handle = kmap_op->handle; - kunmap_op.dev_bus_addr = 0; - ret = HYPERVISOR_grant_table_op( - GNTTABOP_unmap_grant_ref, &kunmap_op, 1); - WARN(ret, "m2p_remove_override: pfn %lx mfn %lx, failed to " - "modify kernel mappings", page_to_pfn(page), mfn); - return ret; + struct multicall_space mcs = + xen_mc_entry(sizeof(struct gnttab_unmap_grant_ref)); + struct gnttab_unmap_grant_ref *kunmap_op = mcs.args; + + if (kmap_op->host_addr == 0) + return 0; + /* + * Has the grant_op mapping multicall being issued? If not, + * make sure it is called now. + */ + if (kmap_op->handle == -1) + xen_mc_flush(); + if (kmap_op->handle == -1) { + printk(KERN_WARNING "xen_unmap_granted_page: mfn %lx, " + "failed to modify kernel mappings", mfn); + return -1; + } + + kunmap_op->host_addr = kmap_op->host_addr; + kunmap_op->handle = kmap_op->handle; + kunmap_op->dev_bus_addr = 0; + + MULTI_grant_table_op(mcs.mc, + GNTTABOP_unmap_grant_ref, kunmap_op, 1); + + xen_mc_issue(PARAVIRT_LAZY_MMU); + kmap_op->host_addr = 0; + return 0; } return 1; } @@ -345,7 +363,6 @@ static inline void __xen_set_pte(pte_t *ptep, pte_t pteval) xen_unmap_granted_page(ptep); if (!(pte_flags(pteval) & _PAGE_USER)) { - int ret; struct page *page; unsigned long mfn = (pteval.pte & PTE_PFN_MASK) >> PAGE_SHIFT; page = m2p_find_override(mfn); @@ -354,17 +371,19 @@ static inline void __xen_set_pte(pte_t *ptep, pte_t pteval) * hypercall to map it instead */ if (page != NULL && (page->private & GRANT_FRAME_BIT)) { + struct multicall_space mcs = + xen_mc_entry(sizeof(struct gnttab_unmap_grant_ref)); struct gnttab_map_grant_ref *kmap_op = (struct gnttab_map_grant_ref *) page->index; unsigned long old_mfn = kmap_op->dev_bus_addr; kmap_op->host_addr = arbitrary_virt_to_machine(ptep).maddr; kmap_op->dev_bus_addr = 0; - ret = HYPERVISOR_grant_table_op( + + MULTI_grant_table_op(mcs.mc, GNTTABOP_map_grant_ref, kmap_op, 1); - WARN(ret, "xen_set_pte: pfn %lx mfn %lx, failed to " - "modify kernel mappings", - page_to_pfn(page), mfn); + + xen_mc_issue(PARAVIRT_LAZY_MMU); kmap_op->dev_bus_addr = old_mfn; return; } diff --git a/arch/x86/xen/p2m.c b/arch/x86/xen/p2m.c index 1c4d2b5..287fa77 100644 --- a/arch/x86/xen/p2m.c +++ b/arch/x86/xen/p2m.c @@ -163,6 +163,7 @@ #include #include +#include "multicalls.h" #include "xen-ops.h" static void __init m2p_override_init(void); @@ -703,10 +704,12 @@ int m2p_add_override(unsigned long mfn, struct page *page, if (kmap_op != NULL) { if (!PageHighMem(page)) { - int ret = HYPERVISOR_grant_table_op( + struct multicall_space mcs = xen_mc_entry(sizeof(*kmap_op)); + + MULTI_grant_table_op(mcs.mc, GNTTABOP_map_grant_ref, kmap_op, 1); - WARN(ret, "m2p_add_override: pfn %lx mfn %lx, " - "failed to modify kernel mappings", pfn, mfn); + + xen_mc_issue(PARAVIRT_LAZY_MMU); } page->private |= GRANT_FRAME_BIT; /* let's use dev_bus_addr to record the old mfn instead */ @@ -734,15 +737,6 @@ int m2p_remove_override(struct page *page, bool clear_pte) if (mfn == INVALID_P2M_ENTRY || !(mfn & FOREIGN_FRAME_BIT)) return -EINVAL; - if (!PageHighMem(page)) { - address = (unsigned long)__va(pfn << PAGE_SHIFT); - ptep = lookup_address(address, &level); - - if (WARN(ptep == NULL || level != PG_LEVEL_4K, - "m2p_remove_override: pfn %lx not mapped", pfn)) - return -EINVAL; - } - spin_lock_irqsave(&m2p_override_lock, flags); list_del(&page->lru); spin_unlock_irqrestore(&m2p_override_lock, flags); @@ -751,16 +745,38 @@ int m2p_remove_override(struct page *page, bool clear_pte) struct gnttab_map_grant_ref *map_op = (struct gnttab_map_grant_ref *) page->index; set_phys_to_machine(pfn, map_op->dev_bus_addr); - if (!PageHighMem(page)) { - int ret; - struct gnttab_unmap_grant_ref unmap_op; - unmap_op.host_addr = map_op->host_addr; - unmap_op.handle = map_op->handle; - unmap_op.dev_bus_addr = 0; - ret = HYPERVISOR_grant_table_op( - GNTTABOP_unmap_grant_ref, &unmap_op, 1); - WARN(ret, "m2p_remove_override: pfn %lx mfn %lx, " - "failed to modify kernel mappings", pfn, mfn); + if (map_op->host_addr != 0) { + struct multicall_space mcs = + xen_mc_entry(sizeof(struct gnttab_unmap_grant_ref)); + struct gnttab_unmap_grant_ref *unmap_op = mcs.args; + + /* + * Has the grant_op mapping multicall being issued? If not, + * make sure it is called now. + */ + if (map_op->handle == -1) + xen_mc_flush(); + if (map_op->handle == -1) { + printk(KERN_WARNING "m2p_remove_override: pfn %lx mfn %lx, " + "failed to modify kernel mappings", pfn, mfn); + return -1; + } + + unmap_op->host_addr = map_op->host_addr; + unmap_op->handle = map_op->handle; + unmap_op->dev_bus_addr = 0; + + MULTI_grant_table_op(mcs.mc, + GNTTABOP_unmap_grant_ref, unmap_op, 1); + + xen_mc_issue(PARAVIRT_LAZY_MMU); + + map_op->host_addr = 0; + address = (unsigned long)__va(pfn << PAGE_SHIFT); + ptep = lookup_address(address, &level); + if (WARN(ptep == NULL || level != PG_LEVEL_4K, + "m2p_remove_override: pfn %lx not mapped", pfn)) + return -2; set_pte_at(&init_mm, address, ptep, pfn_pte(pfn, PAGE_KERNEL)); __flush_tlb_single(address); -- 1.7.2.3 _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel From xen-devel-bounces@lists.xensource.com Tue Sep 06 09:13:00 2011 Return-path: Envelope-to: www-data@lists.xensource.com Delivery-date: Tue, 06 Sep 2011 09:13:00 -0700 Received: from localhost ([127.0.0.1] helo=lists.colo.xensource.com) by lists.xensource.com with esmtp (Exim 4.43) id 1R0yGi-00042I-BX; Tue, 06 Sep 2011 09:13:00 -0700 Received: from mail174.messagelabs.com ([85.158.138.51]) by lists.xensource.com with esmtp (Exim 4.43) id 1R0yF6-0003Eh-8u for xen-devel@lists.xensource.com; Tue, 06 Sep 2011 09:11:21 -0700 X-Env-Sender: Stefano.Stabellini@eu.citrix.com X-Msg-Ref: server-8.tower-174.messagelabs.com!1315325474!16773681!1 X-Originating-IP: [66.165.176.89] X-StarScan-Version: 6.3.6; banners=-,-,- X-VirusChecked: Checked Received: (qmail 27436 invoked from network); 6 Sep 2011 16:11:16 -0000 Received: from smtp.citrix.com (HELO SMTP.CITRIX.COM) (66.165.176.89) by server-8.tower-174.messagelabs.com with RC4-SHA encrypted SMTP; 6 Sep 2011 16:11:16 -0000 X-IronPort-AV: E=Sophos;i="4.68,339,1312171200"; d="scan'208";a="16726480" Received: from ftlpmailmx02.citrite.net ([10.13.107.66]) by FTLPIPO01.CITRIX.COM with ESMTP/TLS/RC4-MD5; 06 Sep 2011 12:11:13 -0400 Received: from smtp01.ad.xensource.com (10.219.128.104) by smtprelay.citrix.com (10.13.107.66) with Microsoft SMTP Server id 8.3.137.0; Tue, 6 Sep 2011 12:11:13 -0400 Received: from localhost.localdomain (kaball.uk.xensource.com [10.80.2.59]) by smtp01.ad.xensource.com (8.13.1/8.13.1) with ESMTP id p86GBARp022485; Tue, 6 Sep 2011 09:11:11 -0700 From: To: linux-kernel@vger.kernel.org Date: Tue, 6 Sep 2011 17:19:28 +0100 Message-ID: <1315325969-32346-1-git-send-email-stefano.stabellini@eu.citrix.com> X-Mailer: git-send-email 1.7.0.4 MIME-Version: 1.0 Content-Type: text/plain Cc: Ian.Campbell@eu.citrix.com, xen-devel@lists.xensource.com, Jeremy.Fitzhardinge@citrix.com, stefano.stabellini@eu.citrix.com, konrad.wilk@oracle.com Subject: [Xen-devel] [PATCH v2 1/2] xen: modify kernel mappings corresponding to granted pages X-BeenThere: xen-devel@lists.xensource.com X-Mailman-Version: 2.1.5 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xensource.com Errors-To: xen-devel-bounces@lists.xensource.com From: Stefano Stabellini If we want to use granted pages for AIO, changing the mappings of a user vma and the corresponding p2m is not enough, we also need to update the kernel mappings accordingly. On x86_64 it is easy, we can issue another HYPERVISOR_grant_table_op right away in m2p_add_override. We can remove the mappings using another HYPERVISOR_grant_table_op in m2p_remove_override. On x86_32 it is more difficult because the pages are highmem pages and therefore we need to catch the set_pte that tries to map a granted page and issue an HYPERVISOR_grant_table_op instead. Same thing for unmapping them: we need to catch the pte clear or the set_pte that try to unmap a granted page and issue an HYPERVISOR_grant_table_op. Signed-off-by: Stefano Stabellini --- arch/x86/include/asm/xen/page.h | 5 ++- arch/x86/xen/mmu.c | 69 +++++++++++++++++++++++++++++++++++++++ arch/x86/xen/p2m.c | 47 ++++++++++++++++++++------ drivers/xen/gntdev.c | 27 ++++++++++++++- drivers/xen/grant-table.c | 4 +- include/xen/grant_table.h | 1 + 6 files changed, 138 insertions(+), 15 deletions(-) diff --git a/arch/x86/include/asm/xen/page.h b/arch/x86/include/asm/xen/page.h index 7ff4669..0ce1884 100644 --- a/arch/x86/include/asm/xen/page.h +++ b/arch/x86/include/asm/xen/page.h @@ -12,6 +12,7 @@ #include #include +#include #include /* Xen machine address */ @@ -31,8 +32,10 @@ typedef struct xpaddr { #define INVALID_P2M_ENTRY (~0UL) #define FOREIGN_FRAME_BIT (1UL<<(BITS_PER_LONG-1)) #define IDENTITY_FRAME_BIT (1UL<<(BITS_PER_LONG-2)) +#define GRANT_FRAME_BIT (1UL<<(BITS_PER_LONG-3)) #define FOREIGN_FRAME(m) ((m) | FOREIGN_FRAME_BIT) #define IDENTITY_FRAME(m) ((m) | IDENTITY_FRAME_BIT) +#define GRANT_FRAME(m) ((m) | GRANT_FRAME_BIT) /* Maximum amount of memory we can handle in a domain in pages */ #define MAX_DOMAIN_PAGES \ @@ -48,7 +51,7 @@ extern unsigned long set_phys_range_identity(unsigned long pfn_s, unsigned long pfn_e); extern int m2p_add_override(unsigned long mfn, struct page *page, - bool clear_pte); + struct gnttab_map_grant_ref *kmap_op); extern int m2p_remove_override(struct page *page, bool clear_pte); extern struct page *m2p_find_override(unsigned long mfn); extern unsigned long m2p_find_override_pfn(unsigned long mfn, unsigned long pfn); diff --git a/arch/x86/xen/mmu.c b/arch/x86/xen/mmu.c index 20a6142..e80dad5 100644 --- a/arch/x86/xen/mmu.c +++ b/arch/x86/xen/mmu.c @@ -306,8 +306,71 @@ static bool xen_batched_set_pte(pte_t *ptep, pte_t pteval) return true; } +#ifdef CONFIG_HIGHMEM +static int xen_unmap_granted_page(pte_t *ptep) +{ + unsigned long mfn; + struct page *page; + + if (pte_flags(*ptep) & _PAGE_USER) + return 1; + mfn = (ptep->pte & PTE_PFN_MASK) >> PAGE_SHIFT; + page = m2p_find_override(mfn); + if (page != NULL && (page->private & GRANT_FRAME_BIT)) { + int ret; + struct gnttab_unmap_grant_ref kunmap_op; + struct gnttab_map_grant_ref *kmap_op = + (struct gnttab_map_grant_ref *) page->index; + kunmap_op.host_addr = kmap_op->host_addr; + kunmap_op.handle = kmap_op->handle; + kunmap_op.dev_bus_addr = 0; + ret = HYPERVISOR_grant_table_op( + GNTTABOP_unmap_grant_ref, &kunmap_op, 1); + WARN(ret, "m2p_remove_override: pfn %lx mfn %lx, failed to " + "modify kernel mappings", page_to_pfn(page), mfn); + return ret; + } + return 1; +} +#endif + static inline void __xen_set_pte(pte_t *ptep, pte_t pteval) { +#ifdef CONFIG_HIGHMEM + /* + * the old page we are about to overwrite could be a granted page + * and in that case we need to unmap it using a grant table + * hypercall + */ + xen_unmap_granted_page(ptep); + + if (!(pte_flags(pteval) & _PAGE_USER)) { + int ret; + struct page *page; + unsigned long mfn = (pteval.pte & PTE_PFN_MASK) >> PAGE_SHIFT; + page = m2p_find_override(mfn); + /* + * if this is a granted page we need to use a grant table + * hypercall to map it instead + */ + if (page != NULL && (page->private & GRANT_FRAME_BIT)) { + struct gnttab_map_grant_ref *kmap_op = + (struct gnttab_map_grant_ref *) page->index; + unsigned long old_mfn = kmap_op->dev_bus_addr; + kmap_op->host_addr = + arbitrary_virt_to_machine(ptep).maddr; + kmap_op->dev_bus_addr = 0; + ret = HYPERVISOR_grant_table_op( + GNTTABOP_map_grant_ref, kmap_op, 1); + WARN(ret, "xen_set_pte: pfn %lx mfn %lx, failed to " + "modify kernel mappings", + page_to_pfn(page), mfn); + kmap_op->dev_bus_addr = old_mfn; + return; + } + } +#endif + if (!xen_batched_set_pte(ptep, pteval)) native_set_pte(ptep, pteval); } @@ -585,6 +648,12 @@ static void xen_set_pte_atomic(pte_t *ptep, pte_t pte) static void xen_pte_clear(struct mm_struct *mm, unsigned long addr, pte_t *ptep) { trace_xen_mmu_pte_clear(mm, addr, ptep); + /* + * check if this is a granted page and unmap it using a grant table + * hypercall in that case + */ + if (!xen_unmap_granted_page(ptep)) + return; if (!xen_batched_set_pte(ptep, native_make_pte(0))) native_pte_clear(mm, addr, ptep); } diff --git a/arch/x86/xen/p2m.c b/arch/x86/xen/p2m.c index 58efeb9..1c4d2b5 100644 --- a/arch/x86/xen/p2m.c +++ b/arch/x86/xen/p2m.c @@ -161,6 +161,7 @@ #include #include #include +#include #include "xen-ops.h" @@ -676,7 +677,8 @@ static unsigned long mfn_hash(unsigned long mfn) } /* Add an MFN override for a particular page */ -int m2p_add_override(unsigned long mfn, struct page *page, bool clear_pte) +int m2p_add_override(unsigned long mfn, struct page *page, + struct gnttab_map_grant_ref *kmap_op) { unsigned long flags; unsigned long pfn; @@ -699,9 +701,18 @@ int m2p_add_override(unsigned long mfn, struct page *page, bool clear_pte) if (unlikely(!set_phys_to_machine(pfn, FOREIGN_FRAME(mfn)))) return -ENOMEM; - if (clear_pte && !PageHighMem(page)) - /* Just zap old mapping for now */ - pte_clear(&init_mm, address, ptep); + if (kmap_op != NULL) { + if (!PageHighMem(page)) { + int ret = HYPERVISOR_grant_table_op( + GNTTABOP_map_grant_ref, kmap_op, 1); + WARN(ret, "m2p_add_override: pfn %lx mfn %lx, " + "failed to modify kernel mappings", pfn, mfn); + } + page->private |= GRANT_FRAME_BIT; + /* let's use dev_bus_addr to record the old mfn instead */ + kmap_op->dev_bus_addr = page->index; + page->index = (unsigned long) kmap_op; + } spin_lock_irqsave(&m2p_override_lock, flags); list_add(&page->lru, &m2p_overrides[mfn_hash(mfn)]); spin_unlock_irqrestore(&m2p_override_lock, flags); @@ -735,13 +746,27 @@ int m2p_remove_override(struct page *page, bool clear_pte) spin_lock_irqsave(&m2p_override_lock, flags); list_del(&page->lru); spin_unlock_irqrestore(&m2p_override_lock, flags); - set_phys_to_machine(pfn, page->index); - if (clear_pte && !PageHighMem(page)) - set_pte_at(&init_mm, address, ptep, - pfn_pte(pfn, PAGE_KERNEL)); - /* No tlb flush necessary because the caller already - * left the pte unmapped. */ + if (clear_pte) { + struct gnttab_map_grant_ref *map_op = + (struct gnttab_map_grant_ref *) page->index; + set_phys_to_machine(pfn, map_op->dev_bus_addr); + if (!PageHighMem(page)) { + int ret; + struct gnttab_unmap_grant_ref unmap_op; + unmap_op.host_addr = map_op->host_addr; + unmap_op.handle = map_op->handle; + unmap_op.dev_bus_addr = 0; + ret = HYPERVISOR_grant_table_op( + GNTTABOP_unmap_grant_ref, &unmap_op, 1); + WARN(ret, "m2p_remove_override: pfn %lx mfn %lx, " + "failed to modify kernel mappings", pfn, mfn); + set_pte_at(&init_mm, address, ptep, + pfn_pte(pfn, PAGE_KERNEL)); + __flush_tlb_single(address); + } + } else + set_phys_to_machine(pfn, page->index); return 0; } @@ -758,7 +783,7 @@ struct page *m2p_find_override(unsigned long mfn) spin_lock_irqsave(&m2p_override_lock, flags); list_for_each_entry(p, bucket, lru) { - if (p->private == mfn) { + if ((p->private & (~GRANT_FRAME_BIT)) == mfn) { ret = p; break; } diff --git a/drivers/xen/gntdev.c b/drivers/xen/gntdev.c index f914b26..ca41772 100644 --- a/drivers/xen/gntdev.c +++ b/drivers/xen/gntdev.c @@ -83,6 +83,7 @@ struct grant_map { struct ioctl_gntdev_grant_ref *grants; struct gnttab_map_grant_ref *map_ops; struct gnttab_unmap_grant_ref *unmap_ops; + struct gnttab_map_grant_ref *kmap_ops; struct page **pages; }; @@ -116,10 +117,12 @@ static struct grant_map *gntdev_alloc_map(struct gntdev_priv *priv, int count) add->grants = kzalloc(sizeof(add->grants[0]) * count, GFP_KERNEL); add->map_ops = kzalloc(sizeof(add->map_ops[0]) * count, GFP_KERNEL); add->unmap_ops = kzalloc(sizeof(add->unmap_ops[0]) * count, GFP_KERNEL); + add->kmap_ops = kzalloc(sizeof(add->kmap_ops[0]) * count, GFP_KERNEL); add->pages = kzalloc(sizeof(add->pages[0]) * count, GFP_KERNEL); if (NULL == add->grants || NULL == add->map_ops || NULL == add->unmap_ops || + NULL == add->kmap_ops || NULL == add->pages) goto err; @@ -129,6 +132,7 @@ static struct grant_map *gntdev_alloc_map(struct gntdev_priv *priv, int count) for (i = 0; i < count; i++) { add->map_ops[i].handle = -1; add->unmap_ops[i].handle = -1; + add->kmap_ops[i].handle = -1; } add->index = 0; @@ -142,6 +146,7 @@ err: kfree(add->grants); kfree(add->map_ops); kfree(add->unmap_ops); + kfree(add->kmap_ops); kfree(add); return NULL; } @@ -243,10 +248,30 @@ static int map_grant_pages(struct grant_map *map) gnttab_set_unmap_op(&map->unmap_ops[i], addr, map->flags, -1 /* handle */); } + } else { + for (i = 0; i < map->count; i++) { + unsigned level; + unsigned long address = (unsigned long) + pfn_to_kaddr(page_to_pfn(map->pages[i])); + pte_t *ptep; + u64 pte_maddr = 0; + if (!PageHighMem(map->pages[i])) { + ptep = lookup_address(address, &level); + pte_maddr = + arbitrary_virt_to_machine(ptep).maddr; + } + gnttab_set_map_op(&map->kmap_ops[i], pte_maddr, + map->flags | + GNTMAP_host_map | + GNTMAP_contains_pte, + map->grants[i].ref, + map->grants[i].domid); + } } pr_debug("map %d+%d\n", map->index, map->count); - err = gnttab_map_refs(map->map_ops, map->pages, map->count); + err = gnttab_map_refs(map->map_ops, use_ptemod ? map->kmap_ops : NULL, + map->pages, map->count); if (err) return err; diff --git a/drivers/xen/grant-table.c b/drivers/xen/grant-table.c index 4f44b34..ed6622f 100644 --- a/drivers/xen/grant-table.c +++ b/drivers/xen/grant-table.c @@ -448,6 +448,7 @@ unsigned int gnttab_max_grant_frames(void) EXPORT_SYMBOL_GPL(gnttab_max_grant_frames); int gnttab_map_refs(struct gnttab_map_grant_ref *map_ops, + struct gnttab_map_grant_ref *kmap_ops, struct page **pages, unsigned int count) { int i, ret; @@ -488,8 +489,7 @@ int gnttab_map_refs(struct gnttab_map_grant_ref *map_ops, */ return -EOPNOTSUPP; } - ret = m2p_add_override(mfn, pages[i], - map_ops[i].flags & GNTMAP_contains_pte); + ret = m2p_add_override(mfn, pages[i], &kmap_ops[i]); if (ret) return ret; } diff --git a/include/xen/grant_table.h b/include/xen/grant_table.h index b1fab6b..6b99bfb 100644 --- a/include/xen/grant_table.h +++ b/include/xen/grant_table.h @@ -156,6 +156,7 @@ unsigned int gnttab_max_grant_frames(void); #define gnttab_map_vaddr(map) ((void *)(map.host_virt_addr)) int gnttab_map_refs(struct gnttab_map_grant_ref *map_ops, + struct gnttab_map_grant_ref *kmap_ops, struct page **pages, unsigned int count); int gnttab_unmap_refs(struct gnttab_unmap_grant_ref *unmap_ops, struct page **pages, unsigned int count); -- 1.7.2.3 _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel From xen-devel-bounces@lists.xensource.com Tue Sep 06 09:13:58 2011 Return-path: Envelope-to: www-data@lists.xensource.com Delivery-date: Tue, 06 Sep 2011 09:13:58 -0700 Received: from localhost ([127.0.0.1] helo=lists.colo.xensource.com) by lists.xensource.com with esmtp (Exim 4.43) id 1R0yHe-0004UW-Aw; Tue, 06 Sep 2011 09:13:58 -0700 Received: from mail174.messagelabs.com ([85.158.138.51]) by lists.xensource.com with esmtp (Exim 4.43) id 1R0yH3-0004C8-BZ for xen-devel@lists.xensource.com; Tue, 06 Sep 2011 09:13:21 -0700 X-Env-Sender: keir.xen@gmail.com X-Msg-Ref: server-11.tower-174.messagelabs.com!1315325597!30448761!1 X-Originating-IP: [74.125.82.171] X-StarScan-Version: 6.3.6; banners=-,-,- X-VirusChecked: Checked Received: (qmail 8523 invoked from network); 6 Sep 2011 16:13:18 -0000 Received: from mail-wy0-f171.google.com (HELO mail-wy0-f171.google.com) (74.125.82.171) by server-11.tower-174.messagelabs.com with RC4-SHA encrypted SMTP; 6 Sep 2011 16:13:18 -0000 Received: by wyh13 with SMTP id 13so5962617wyh.30 for ; Tue, 06 Sep 2011 09:13:17 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=user-agent:date:subject:from:to:cc:message-id:thread-topic :thread-index:in-reply-to:mime-version:content-type :content-transfer-encoding; bh=RcXgqRR5NcBdBy0ooVR9lcWUMui2I8GgCLMha0wiMWQ=; b=w4a42bPcLJQu+bT3E5AsuVZVwrbXGYsSDjC49y+MAxrjOid6l7jGkG1KqWefGRxk+b PYCNXvIGLQfKyQmVaFv5bJJPpsd82VslohSqlA3grTEzIXZxVwTuEUhTg2++LXXQ16pG 4UhtIjz/u2ejo7Bpm0EGZC0MV9sHeTarZGGbM= Received: by 10.216.18.146 with SMTP id l18mr3844295wel.38.1315325596928; Tue, 06 Sep 2011 09:13:16 -0700 (PDT) Received: from [192.168.1.78] (host86-137-116-193.range86-137.btcentralplus.com [86.137.116.193]) by mx.google.com with ESMTPS id fp5sm564866wbb.2.2011.09.06.09.13.13 (version=SSLv3 cipher=OTHER); Tue, 06 Sep 2011 09:13:14 -0700 (PDT) User-Agent: Microsoft-Entourage/12.30.0.110427 Date: Tue, 06 Sep 2011 17:13:07 +0100 Subject: Re: [Xen-devel] AMD IOMMU intremap tables and IOAPICs From: Keir Fraser To: Tim Deegan , Andrew Cooper Message-ID: Thread-Topic: [Xen-devel] AMD IOMMU intremap tables and IOAPICs Thread-Index: Acxsr90Dc6v2MhSKfUO0/5E/nRE14w== In-Reply-To: <20110906160612.GA12835@ocelot.phlegethon.org> Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit Cc: George Dunlap , xen-devel@lists.xensource.com X-BeenThere: xen-devel@lists.xensource.com X-Mailman-Version: 2.1.5 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xensource.com Errors-To: xen-devel-bounces@lists.xensource.com On 06/09/2011 17:06, "Tim Deegan" wrote: > At 16:54 +0100 on 06 Sep (1315328056), Andrew Cooper wrote: >> On 06/09/11 16:47, George Dunlap wrote: >>> Wei, >>> >>> Quick question: Am I reading the code correctly, that even with >>> per-device interrupt remap tables, that GSIs are accounted to the >>> intremap table of the corresponding IOAPIC, presumably because the >>> IOMMU sees interrupts generated as GSIs as coming from the IOAPIC? In >>> that case, then we need all devices sharing the same IOAPIC must not >>> have any vector collisions. Is that correct? >> >> Based on the ICH10 IO-APIC documentation with respect to auto EOIs, we >> cant have any two IRQs across any IO-APICs sharing a vector, >> irrespective of IOMMU or not. (Because the EOI'ing an IO-APIC entry >> only takes account of vector and not destination) > > If this is the case, is there any point in having per-CPU IDTs? > Or per-device remapping tables? It still makes sense for MSIs, which are the most common interrupt type these days. -- Keir > Tim. > > _______________________________________________ > Xen-devel mailing list > Xen-devel@lists.xensource.com > http://lists.xensource.com/xen-devel _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel From xen-devel-bounces@lists.xensource.com Tue Sep 06 09:14:41 2011 Return-path: Envelope-to: www-data@lists.xensource.com Delivery-date: Tue, 06 Sep 2011 09:14:41 -0700 Received: from localhost ([127.0.0.1] helo=lists.colo.xensource.com) by lists.xensource.com with esmtp (Exim 4.43) id 1R0yIL-0004rU-RO; Tue, 06 Sep 2011 09:14:41 -0700 Received: from mail21.messagelabs.com ([85.158.143.35]) by lists.xensource.com with esmtp (Exim 4.43) id 1R0yHB-0004F9-Ff for xen-devel@lists.xensource.com; Tue, 06 Sep 2011 09:13:29 -0700 X-Env-Sender: konrad@dumpdata.com X-Msg-Ref: server-8.tower-21.messagelabs.com!1315325590!57945857!1 X-Originating-IP: [148.87.113.117] X-StarScan-Version: 6.3.6; banners=-,-,- X-VirusChecked: Checked Received: (qmail 24269 invoked from network); 6 Sep 2011 16:13:11 -0000 Received: from rcsinet15.oracle.com (HELO rcsinet15.oracle.com) (148.87.113.117) by server-8.tower-21.messagelabs.com with DHE-RSA-AES256-SHA encrypted SMTP; 6 Sep 2011 16:13:11 -0000 Received: from acsinet21.oracle.com (acsinet21.oracle.com [141.146.126.237]) by rcsinet15.oracle.com (Switch-3.4.4/Switch-3.4.4) with ESMTP id p86GDFTQ004285 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Tue, 6 Sep 2011 16:13:17 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 p86GDE4f000379 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 6 Sep 2011 16:13:15 GMT Received: from abhmt106.oracle.com (abhmt106.oracle.com [141.146.116.58]) by acsmt358.oracle.com (8.12.11.20060308/8.12.11) with ESMTP id p86GD9Hd031909; Tue, 6 Sep 2011 11:13:09 -0500 Received: from phenom (/209.6.55.207) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Tue, 06 Sep 2011 09:13:08 -0700 Received: by phenom (Postfix, from userid 1000) id D3754FD1; Tue, 6 Sep 2011 12:12:58 -0400 (EDT) Date: Tue, 6 Sep 2011 12:12:58 -0400 From: Konrad Rzeszutek Wilk To: "Deepak Kr. Sharma - ERS, HCL Tech" Subject: Re: [Xen-devel] FW: HXEN on linux Message-ID: <20110906161258.GA5264@dumpdata.com> References: <90F0F47595235141A4380FCF01B0185B20BC426222@CHN-HCLT-EVS07.HCLT.CORP.HCL.IN> <20110809195159.GA7834@dumpdata.com> <90F0F47595235141A4380FCF01B0185B20BC513BCB@CHN-HCLT-EVS07.HCLT.CORP.HCL.IN> <90F0F47595235141A4380FCF01B0185B20BC585A8A@CHN-HCLT-EVS07.HCLT.CORP.HCL.IN> <90F0F47595235141A4380FCF01B0185B20BC608BBC@CHN-HCLT-EVS07.HCLT.CORP.HCL.IN> <20110901134638.GB23971@dumpdata.com> <90F0F47595235141A4380FCF01B0185B2240FEA5E3@CHN-HCLT-EVS07.HCLT.CORP.HCL.IN> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <90F0F47595235141A4380FCF01B0185B2240FEA5E3@CHN-HCLT-EVS07.HCLT.CORP.HCL.IN> User-Agent: Mutt/1.5.21 (2010-09-15) X-Source-IP: acsinet21.oracle.com [141.146.126.237] X-Auth-Type: Internal IP X-CT-RefId: str=0001.0A090204.4E66469D.0175:SCFMA922111,ss=1,re=-4.000,fgs=0 Cc: "todd.deshane.xen@gmail.com" , "xen-devel@lists.xensource.com" , Lars Kurth , Stefano Stabellini X-BeenThere: xen-devel@lists.xensource.com X-Mailman-Version: 2.1.5 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xensource.com Errors-To: xen-devel-bounces@lists.xensource.com On Mon, Sep 05, 2011 at 12:43:19PM +0530, Deepak Kr. Sharma - ERS, HCL Tech wrote: > Hello Konrad, > > We want to build expertise in virtualization domain and contribute to open source community. > > We have used Xen as type-1 hypervisor and the performance is unprecedented. We see good potential in HXen as a type-2 hypervisor and some good solutions can be built around it on linux based platforms. "good solutions" .. such as? I am just trying to wrap my mind around why you would do this extra work instead of doing it in the Xen hypervisor and expanding what it can do? _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel From xen-devel-bounces@lists.xensource.com Tue Sep 06 09:17:28 2011 Return-path: Envelope-to: www-data@lists.xensource.com Delivery-date: Tue, 06 Sep 2011 09:17:28 -0700 Received: from localhost ([127.0.0.1] helo=lists.colo.xensource.com) by lists.xensource.com with esmtp (Exim 4.43) id 1R0yL2-0005HL-2E; Tue, 06 Sep 2011 09:17:28 -0700 Received: from mail21.messagelabs.com ([85.158.143.35]) by lists.xensource.com with esmtp (Exim 4.43) id 1R0yKc-00054t-DH for xen-devel@lists.xensource.com; Tue, 06 Sep 2011 09:17:03 -0700 X-Env-Sender: konrad@dumpdata.com X-Msg-Ref: server-9.tower-21.messagelabs.com!1315325775!47386325!1 X-Originating-IP: [141.146.126.227] X-StarScan-Version: 6.3.6; banners=-,-,- X-VirusChecked: Checked Received: (qmail 25976 invoked from network); 6 Sep 2011 16:16:16 -0000 Received: from acsinet15.oracle.com (HELO acsinet15.oracle.com) (141.146.126.227) by server-9.tower-21.messagelabs.com with DHE-RSA-AES256-SHA encrypted SMTP; 6 Sep 2011 16:16:16 -0000 Received: from acsinet22.oracle.com (acsinet22.oracle.com [141.146.126.238]) by acsinet15.oracle.com (Switch-3.4.4/Switch-3.4.4) with ESMTP id p86GGtFP018395 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Tue, 6 Sep 2011 16:16:56 GMT Received: from acsmt357.oracle.com (acsmt357.oracle.com [141.146.40.157]) by acsinet22.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id p86GGsXn002975 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 6 Sep 2011 16:16:54 GMT Received: from abhmt107.oracle.com (abhmt107.oracle.com [141.146.116.59]) by acsmt357.oracle.com (8.12.11.20060308/8.12.11) with ESMTP id p86GGnGC000479; Tue, 6 Sep 2011 11:16:49 -0500 Received: from phenom (/209.6.55.207) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Tue, 06 Sep 2011 09:16:48 -0700 Received: by phenom (Postfix, from userid 1000) id DC7CDFD1; Tue, 6 Sep 2011 12:16:38 -0400 (EDT) Date: Tue, 6 Sep 2011 12:16:38 -0400 From: Konrad Rzeszutek Wilk To: Anthony Wright Subject: Re: [Xen-devel] VM hangs during boot on 3.0.4 dom0 kernel, works on alternative hardware Message-ID: <20110906161638.GB5264@dumpdata.com> References: <4E64A4F4.1040402@overnetdata.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <4E64A4F4.1040402@overnetdata.com> User-Agent: Mutt/1.5.21 (2010-09-15) X-Source-IP: acsinet22.oracle.com [141.146.126.238] X-Auth-Type: Internal IP X-CT-RefId: str=0001.0A090204.4E664779.0071:SCFMA922111,ss=1,re=-6.300,fgs=0 Cc: "xen-devel@lists.xensource.com" X-BeenThere: xen-devel@lists.xensource.com X-Mailman-Version: 2.1.5 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xensource.com Errors-To: xen-devel-bounces@lists.xensource.com On Mon, Sep 05, 2011 at 11:31:16AM +0100, Anthony Wright wrote: > I have two machines with identical Dom0's and DomUs, but different > hardware. The Dom0 has a patch which I produced myself based on the "Re: > [Xen-devel] Kernel bug from 3.0 (was phy disks and vifs timing out in > DomU)" thread. The patch calls vmalloc_sync_all after every > alloc_vm_area, and I realise this isn't the best solution, but it > allowed me to move forward. > > The patch fixes the problem I had on one machine, so that now the VMs > boot correctly, but I have another system with an identical setup > (identical Dom0 & DomU kernels, identical startup for DomU) and the VM > fails to start. I have attached a copy of the console log from the good > VM and the bad VM. And what does the dom0 and xen hypervisor log give you? It looks to be hanging at identifying the CPU - is the hardware quite different from one setup to another? Have you toyed with using the cpuid flag in the guest to mimic the lowest CPU type? > > Anthony. > > > [ 3.226308] Reserving virtual address space above 0xf5800000 > [ 3.226308] Linux version 2.6.30.1 (root@deb-builder) (gcc version 4.3.2 (GCC) ) #2 SMP Mon Jul 18 12:06:12 GMT 2011 > [ 3.226308] KERNEL supported cpus: > [ 3.226308] Intel GenuineIntel > [ 3.226308] AMD AuthenticAMD > [ 3.226308] NSC Geode by NSC > [ 3.226308] Cyrix CyrixInstead > [ 3.226308] Centaur CentaurHauls > [ 3.226308] Transmeta GenuineTMx86 > [ 3.226308] Transmeta TransmetaCPU > [ 3.226308] UMC UMC UMC UMC > [ 3.226308] BIOS-provided physical RAM map: > [ 3.226308] Xen: 0000000000000000 - 00000000000a0000 (usable) > [ 3.226308] Xen: 00000000000a0000 - 0000000000100000 (reserved) > [ 3.226308] Xen: 0000000000100000 - 000000000065c000 (usable) > [ 3.226308] Xen: 000000000065c000 - 0000000000759000 (reserved) > [ 3.226308] Xen: 0000000000759000 - 000000003e800000 (usable) > [ 3.226308] DMI not present or invalid. > [ 3.226308] last_pfn = 0x3e800 max_arch_pfn = 0x1000000 > [ 3.226308] init_memory_mapping: 0000000000000000-00000000229fe000 > [ 3.226308] NX (Execute Disable) protection: active > [ 3.226308] 446MB HIGHMEM available. > [ 3.226308] 553MB LOWMEM available. > [ 3.226308] mapped low ram: 0 - 229fe000 > [ 3.226308] low ram: 0 - 229fe000 > [ 3.226308] node 0 low ram: 00000000 - 229fe000 > [ 3.226308] node 0 bootmap 00007000 - 0000b540 > [ 3.226308] (7 early reservations) ==> bootmem [0000000000 - 00229fe000] > [ 3.226308] #0 [0000000000 - 0000001000] BIOS data page ==> [0000000000 - 0000001000] > [ 3.226308] #1 [0000759000 - 000075f000] XEN PAGETABLES ==> [0000759000 - 000075f000] > [ 3.226308] #2 [0000001000 - 0000002000] EX TRAMPOLINE ==> [0000001000 - 0000002000] > [ 3.226308] #3 [0000006000 - 0000007000] TRAMPOLINE ==> [0000006000 - 0000007000] > [ 3.226308] #4 [0000100000 - 00005366f4] TEXT DATA BSS ==> [0000100000 - 00005366f4] > [ 3.226308] #5 [0000537000 - 0000645000] PGTABLE ==> [0000537000 - 0000645000] > [ 3.226308] #6 [0000007000 - 000000c000] BOOTMAP ==> [0000007000 - 000000c000] > [ 3.226308] Zone PFN ranges: > [ 3.226308] DMA 0x00000000 -> 0x00001000 > [ 3.226308] Normal 0x00001000 -> 0x000229fe > [ 3.226308] HighMem 0x000229fe -> 0x0003e800 > [ 3.226308] Movable zone start PFN for each node > [ 3.226308] early_node_map[3] active PFN ranges > [ 3.226308] 0: 0x00000000 -> 0x000000a0 > [ 3.226308] 0: 0x00000100 -> 0x0000065c > [ 3.226308] 0: 0x00000759 -> 0x0003e800 > [ 3.226308] Using APIC driver default > [ 3.226308] SMP: Allowing 1 CPUs, 0 hotplug CPUs > [ 3.226308] Local APIC disabled by BIOS -- you can enable it with "lapic" > [ 3.226308] Allocating PCI resources starting at 40000000 (gap: 3e800000:c1800000) > [ 3.226308] NR_CPUS:8 nr_cpumask_bits:8 nr_cpu_ids:1 nr_node_ids:1 > [ 3.226308] PERCPU: Allocated 6 4k pages, static data 22940 bytes > [ 3.810521] Xen: using vcpu_info placement > [ 0.000000] Built 1 zonelists in Zone order, mobility grouping on. Total pages: 253650 > [ 0.000000] Kernel command line: root=/dev/xvda1 > [ 0.000000] Enabling fast FPU save and restore... done. > [ 0.000000] Enabling unmasked SIMD FPU exception support... done. > [ 0.000000] Initializing CPU#0 > [ 0.000000] NR_IRQS:512 > [ 0.000000] PID hash table entries: 4096 (order: 12, 16384 bytes) > [ 0.000000] Detected 2533.458 MHz processor. > [ 0.010000] Console: colour dummy device 80x25 > [ 0.010000] console [tty0] enabled > [ 0.010000] console [hvc0] enabled > [ 0.010000] Dentry cache hash table entries: 131072 (order: 7, 524288 bytes) > [ 0.010000] Inode-cache hash table entries: 65536 (order: 6, 262144 bytes) > [ 0.010000] Initializing HighMem for node 0 (000229fe:0003e800) > [ 0.010000] Memory: 1007448k/1024000k available (2539k kernel code, 14292k reserved, 1067k data, 244k init, 456712k highmem) > [ 0.010000] virtual kernel memory layout: > [ 0.010000] fixmap : 0xf574f000 - 0xf57ff000 ( 704 kB) > [ 0.010000] pkmap : 0xf5200000 - 0xf5400000 (2048 kB) > [ 0.010000] vmalloc : 0xe31fe000 - 0xf51fe000 ( 288 MB) > [ 0.010000] lowmem : 0xc0000000 - 0xe29fe000 ( 553 MB) > [ 0.010000] .init : 0xc0490000 - 0xc04cd000 ( 244 kB) > [ 0.010000] .data : 0xc037ae1d - 0xc0485e18 (1067 kB) > [ 0.010000] .text : 0xc0100000 - 0xc037ae1d (2539 kB) > [ 0.010000] Checking if this processor honours the WP bit even in supervisor mode...Ok. > [ 0.010000] installing Xen timer for CPU 0 > [ 0.010000] Calibrating delay loop (skipped), value calculated using timer frequency.. 5066.91 BogoMIPS (lpj=25334580) > [ 0.010000] Mount-cache hash table entries: 512 > [ 3.226308] Reserving virtual address space above 0xf5800000 > [ 3.226308] Linux version 2.6.30.1 (root@deb-builder) (gcc version 4.3.2 (GCC) ) #2 SMP Mon Jul 18 12:06:12 GMT 2011 > [ 3.226308] KERNEL supported cpus: > [ 3.226308] Intel GenuineIntel > [ 3.226308] AMD AuthenticAMD > [ 3.226308] NSC Geode by NSC > [ 3.226308] Cyrix CyrixInstead > [ 3.226308] Centaur CentaurHauls > [ 3.226308] Transmeta GenuineTMx86 > [ 3.226308] Transmeta TransmetaCPU > [ 3.226308] UMC UMC UMC UMC > [ 3.226308] BIOS-provided physical RAM map: > [ 3.226308] Xen: 0000000000000000 - 00000000000a0000 (usable) > [ 3.226308] Xen: 00000000000a0000 - 0000000000100000 (reserved) > [ 3.226308] Xen: 0000000000100000 - 000000000065c000 (usable) > [ 3.226308] Xen: 000000000065c000 - 0000000000759000 (reserved) > [ 3.226308] Xen: 0000000000759000 - 000000003e800000 (usable) > [ 3.226308] DMI not present or invalid. > [ 3.226308] last_pfn = 0x3e800 max_arch_pfn = 0x1000000 > [ 3.226308] init_memory_mapping: 0000000000000000-00000000229fe000 > [ 3.226308] NX (Execute Disable) protection: active > [ 3.226308] 446MB HIGHMEM available. > [ 3.226308] 553MB LOWMEM available. > [ 3.226308] mapped low ram: 0 - 229fe000 > [ 3.226308] low ram: 0 - 229fe000 > [ 3.226308] node 0 low ram: 00000000 - 229fe000 > [ 3.226308] node 0 bootmap 00007000 - 0000b540 > [ 3.226308] (7 early reservations) ==> bootmem [0000000000 - 00229fe000] > [ 3.226308] #0 [0000000000 - 0000001000] BIOS data page ==> [0000000000 - 0000001000] > [ 3.226308] #1 [0000759000 - 000075f000] XEN PAGETABLES ==> [0000759000 - 000075f000] > [ 3.226308] #2 [0000001000 - 0000002000] EX TRAMPOLINE ==> [0000001000 - 0000002000] > [ 3.226308] #3 [0000006000 - 0000007000] TRAMPOLINE ==> [0000006000 - 0000007000] > [ 3.226308] #4 [0000100000 - 00005366f4] TEXT DATA BSS ==> [0000100000 - 00005366f4] > [ 3.226308] #5 [0000537000 - 0000645000] PGTABLE ==> [0000537000 - 000 default > [ 3.226308] SMP: Allowing 1 CPUs, 0 hotplug CPUs > [ 3.226308] Local APIC disabled by BIOS -- you can enable it with "lapic" > [ 3.226308] Allocating PCI resources starting at 40000000 (gap: 3e800000:c1800000) > [ 3.226308] NR_CPUS:8 nr_cpumask_bits:8 nr_cpu_ids:1 nr_node_ids:1 > [ 3.226308] PERCPU: Allocated 6 4k pages, static data 22940 bytes > [ 3.810521] Xen: using vcpu_info placement > [ 0.000000] Built 1 zonelists in Zone order, mobility grouping on. Total pages: 253650 > [ 0.000000] Kernel command line: root=/dev/xvda1 > [ 0.000000] Enabling fast FPU save and restore... done. > [ 0.000000] Enabling unmasked SIMD FPU exception support... done. > [ 0.000000] Initializing CPU#0 > [ 0.000000] NR_IRQS:512 > [ 0.000000] PID hash table entries: 4096 (order: 12, 16384 bytes) > [ 0.000000] Detected 3013.788 MHz processor. > [ 0.010000] Console: colour dummy device 80x25 > [ 0.010000] console [tty0] enabled > [ 0.010000] console [hvc0] enabled > [ 0.010000] Dentry cache hash table entries: 131072 (order: 7, 524288 bytes) > [ 0.010000] Inode-cache hash table entries: 65536 (order: 6, 262144 bytes) > [ 0.010000] Initializing HighMem for node 0 (000229fe:0003e800) > [ 0.010000] Memory: 1007448k/1024000k available (2539k kernel code, 14292k reserved, 1067k data, 244k init, 456712k highmem) > [ 0.010000] virtual kernel memory layout: > [ 0.010000] fixmap : 0xf574f000 - 0xf57ff000 ( 704 kB) > [ 0.010000] pkmap : 0xf5200000 - 0xf5400000 (2048 kB) > [ 0.010000] vmalloc : 0xe31fe000 - 0xf51fe000 ( 288 MB) > [ 0.010000] lowmem : 0xc0000000 - 0xe29fe000 ( 553 MB) > [ 0.010000] .init : 0xc0490000 - 0xc04cd000 ( 244 kB) > [ 0.010000] .data : 0xc037ae1d - 0xc0485e18 (1067 kB) > [ 0.010000] .text : 0xc0100000 - 0xc037ae1d (2539 kB) > [ 0.010000] Checking if this processor honours the WP bit even in supervisor mode...Ok. > [ 0.010000] installing Xen timer for CPU 0 > [ 0.010000] Calibrating delay loop (skipped), value calculated using timer frequency.. 6027.57 BogoMIPS (lpj=30137880) > [ 0.010000] Mount-cache hash table entries: 512 > [ 0.010000] CPU: L1 I Cache: 64K (64 bytes/line), D cache 64K (64 bytes/line) > [ 0.010000] CPU: L2 Cache: 1024K (64 bytes/line) > [ 0.010000] CPU: Physical Processor ID: 0 > [ 0.010000] CPU: Processor Core ID: 0 > [ 0.010000] SMP alternatives: switching to UP code > [ 0.010000] Freeing SMP alternatives: 28k freed > [ 0.010180] Brought up 1 CPUs > [ 0.010394] net_namespace: 452 bytes > [ 0.010403] Booting paravirtualized kernel on Xen > [ 0.010408] Xen version: 4.1.1 (preserve-AD) > [ 0.010445] xor: automatically using best checksumming function: pIII_sse > [ 0.060003] pIII_sse : 2499.200 MB/sec > [ 0.060011] xor: using function: pIII_sse (2499.200 MB/sec) > [ 0.060054] Grant table initialized > [ 0.060094] NET: Registered protocol family 16 > [ 0.062835] bio: create slab at 0 > [ 0.063164] xen_balloon: Initialising balloon driver. > [ 0.230016] raid6: int32x1 774 MB/s > [ 0.400011] raid6: int32x2 1342 MB/s > [ 0.570087] raid6: int32x4 649 MB/s > [ 0.740008] raid6: int32x8 802 MB/s > [ 0.910011] raid6: mmxx1 2348 MB/s > [ 1.080015] raid6: mmxx2 4362 MB/s > [ 1.250030] raid6: sse1x1 1907 MB/s > [ 1.420018] raid6: sse1x2 2746 MB/s > [ 1.590025] raid6: sse2x1 3313 MB/s > [ 1.760017] raid6: sse2x2 4325 MB/s > [ 1.760033] raid6: using algorithm sse2x2 (4325 MB/s) > [ 1.760643] NET: Registered protocol family 2 > [ 1.760683] IP route cache hash table entries: 32768 (order: 5, 131072 bytes) > [ 1.760767] TCP established hash table entries: 131072 (order: 8, 1048576 bytes) > [ 1.761182] TCP bind hash table entries: 65536 (order: 7, 524288 bytes) > [ 1.761437] TCP: Hash tables configured (established 131072 bind 65536) > [ 1.761445] TCP reno registered > [ 1.761513] NET: Registered protocol family 1 > [ 1.761732] platform rtc_cmos: registered platform RTC device (no PNP device found) > [ 1.762311] highmem bounce pool size: 64 pages > [ 1.762325] HugeTLB registered 2 MB page size, pre-allocated 0 pages > [ 1.762389] VFS: Disk quotas dquot_6.5.2 > [ 1.762401] Dquot-cache hash table entries: 1024 (order 0, 4096 bytes) > [ 1.762499] squashfs: version 4.0 (2009/01/31) Phillip Lougher > [ 1.762596] Installing knfsd (copyright (C) 1996 okir@monad.swb.de). > [ 1.762940] msgmni has been set to 1107 > [ 1.763134] alg: No test for stdrng (krng) > [ 1.763146] async_tx: api initialized (sync-only) > [ 1.763155] io scheduler noop registered > [ 1.763160] io scheduler anticipatory registered (default) > [ 1.763165] io scheduler deadline registered > [ 1.763180] io scheduler cfq registered > [ 1.766472] loop: module loaded > [ 1.783564] Initialising Xen virtual ethernet driver. > [ 1.785475] blkfront: xvda1: barriers enabled > [ 1.788158] blkfront: xvda2: barriers enabled > [ 1.789731] i8042.c: No controller found. > [ 1.790197] mice: PS/2 mouse device common for all mice > [ 1.790238] md: linear personality registered for level -1 > [ 1.790244] md: raid0 personality registered for level 0 > [ 1.790249] md: raid1 personality registered for level 1 > [ 1.790254] md: raid10 personality registered for level 10 > [ 1.790259] md: raid6 personality registered for level 6 > [ 1.790264] md: raid5 personality registered for level 5 > [ 1.790268] md: raid4 personality registered for level 4 > [ 1.790273] md: multipath personality registered for level -4 > [ 1.790278] md: faulty personality registered for level -5 > [ 1.790305] device-mapper: uevent: version 1.0.3 > [ 1.790378] device-mapper: ioctl: 4.14.0-ioctl (2008-04-23) initialised: dm-devel@redhat.com > [ 1.790454] device-mapper: multipath: version 1.0.5 loaded > [ 1.790460] device-mapper: multipath round-robin: version 1.0.0 loaded > [ 1.790554] oprofile: using timer interrupt. > [ 1.790565] Netfilter messages via NETLINK v0.30. > [ 1.790604] xt_time: kernel timezone is -0000 > [ 1.790625] ip_tables: (C) 2000-2006 Netfilter Core Team > [ 1.790646] arp_tables: (C) 2002 David S. Miller > [ 1.790656] TCP cubic registered > [ 1.790661] NET: Registered protocol family 17 > [ 1.790680] Bridge firewalling registered > [ 1.790742] RPC: Registered udp transport module. > [ 1.790747] RPC: Registered tcp transport module. > [ 1.790766] Using IPI No-Shortcut mode > [ 1.890171] md: Waiting for all devices to be available before autodetect > [ 1.890188] md: If you don't use raid, use raid=noautodetect > [ 1.890361] md: Autodetecting RAID arrays. > [ 1.890367] md: Scanned 0 and added 0 devices. > [ 1.890371] md: autorun ... > [ 1.890374] md: ... autorun DONE. > [ 1.892999] VFS: Mounted root (squashfs filesystem) readonly on device 202:1. > [ 1.893048] Freeing unused kernel memory: 244k freed > _______________________________________________ > Xen-devel mailing list > Xen-devel@lists.xensource.com > http://lists.xensource.com/xen-devel _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel From xen-devel-bounces@lists.xensource.com Tue Sep 06 09:25:38 2011 Return-path: Envelope-to: www-data@lists.xensource.com Delivery-date: Tue, 06 Sep 2011 09:25:38 -0700 Received: from localhost ([127.0.0.1] helo=lists.colo.xensource.com) by lists.xensource.com with esmtp (Exim 4.43) id 1R0ySw-0005ro-94; Tue, 06 Sep 2011 09:25:38 -0700 Received: from mail182.messagelabs.com ([85.158.139.83]) by lists.xensource.com with esmtp (Exim 4.43) id 1R0ySV-0005fo-V6 for xen-devel@lists.xensource.com; Tue, 06 Sep 2011 09:25:12 -0700 X-Env-Sender: Andrew.Cooper3@citrix.com X-Msg-Ref: server-6.tower-182.messagelabs.com!1315326307!17273726!1 X-Originating-IP: [66.165.176.63] X-StarScan-Version: 6.3.6; banners=-,-,- X-VirusChecked: Checked Received: (qmail 28185 invoked from network); 6 Sep 2011 16:25:08 -0000 Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63) by server-6.tower-182.messagelabs.com with RC4-SHA encrypted SMTP; 6 Sep 2011 16:25:08 -0000 X-IronPort-AV: E=Sophos;i="4.68,339,1312171200"; d="scan'208";a="161861053" Received: from ftlpmailmx02.citrite.net ([10.13.107.66]) by FTLPIPO02.CITRIX.COM with ESMTP/TLS/RC4-MD5; 06 Sep 2011 12:25:07 -0400 Received: from [10.80.2.18] (10.80.2.18) by FTLPMAILMX02.citrite.net (10.13.107.66) with Microsoft SMTP Server id 8.3.137.0; Tue, 6 Sep 2011 12:25:07 -0400 Message-ID: <4E664961.9020009@citrix.com> Date: Tue, 6 Sep 2011 17:25:05 +0100 From: Andrew Cooper User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.2.21) Gecko/20110831 Lightning/1.0b2 Thunderbird/3.1.13 MIME-Version: 1.0 To: Tim Deegan Subject: Re: [Xen-devel] AMD IOMMU intremap tables and IOAPICs References: <4E664228.5070606@citrix.com> <20110906160612.GA12835@ocelot.phlegethon.org> In-Reply-To: <20110906160612.GA12835@ocelot.phlegethon.org> Content-Type: text/plain; charset="ISO-8859-1" Content-Transfer-Encoding: 7bit Cc: Dunlap , "xen-devel@lists.xensource.com" , George X-BeenThere: xen-devel@lists.xensource.com X-Mailman-Version: 2.1.5 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xensource.com Errors-To: xen-devel-bounces@lists.xensource.com On 06/09/11 17:06, Tim Deegan wrote: > At 16:54 +0100 on 06 Sep (1315328056), Andrew Cooper wrote: >> On 06/09/11 16:47, George Dunlap wrote: >>> Wei, >>> >>> Quick question: Am I reading the code correctly, that even with >>> per-device interrupt remap tables, that GSIs are accounted to the >>> intremap table of the corresponding IOAPIC, presumably because the >>> IOMMU sees interrupts generated as GSIs as coming from the IOAPIC? In >>> that case, then we need all devices sharing the same IOAPIC must not >>> have any vector collisions. Is that correct? >> Based on the ICH10 IO-APIC documentation with respect to auto EOIs, we >> cant have any two IRQs across any IO-APICs sharing a vector, >> irrespective of IOMMU or not. (Because the EOI'ing an IO-APIC entry >> only takes account of vector and not destination) > If this is the case, is there any point in having per-CPU IDTs? > Or per-device remapping tables? > > Tim. My understanding is: GSIs should always have unique vectors (due to the auto EOI broadcast) AMD IOMMU with per-device remapping tables means that devices cant ever share interrupts when migrating. AMD IOMMU with a global remapping table negates the benefit of per-CPU IDTs Therefore per-CPU IDTs are useful, but there is juggling required when choosing a new vector on migrate (With the possibility of having free vectors, but unable to assign any because of other restrictions) -- Andrew Cooper - Dom0 Kernel Engineer, Citrix XenServer T: +44 (0)1223 225 900, http://www.citrix.com _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel From xen-devel-bounces@lists.xensource.com Tue Sep 06 09:33:15 2011 Return-path: Envelope-to: www-data@lists.xensource.com Delivery-date: Tue, 06 Sep 2011 09:33:15 -0700 Received: from localhost ([127.0.0.1] helo=lists.colo.xensource.com) by lists.xensource.com with esmtp (Exim 4.43) id 1R0yaJ-0006Pa-3T; Tue, 06 Sep 2011 09:33:15 -0700 Received: from mail174.messagelabs.com ([85.158.138.51]) by lists.xensource.com with esmtp (Exim 4.43) id 1R0yZh-0006Bu-TH for xen-devel@lists.xensource.com; Tue, 06 Sep 2011 09:32:38 -0700 X-Env-Sender: konrad@dumpdata.com X-Msg-Ref: server-11.tower-174.messagelabs.com!1315326753!30450839!1 X-Originating-IP: [141.146.126.227] X-StarScan-Version: 6.3.6; banners=-,-,- X-VirusChecked: Checked Received: (qmail 17260 invoked from network); 6 Sep 2011 16:32:34 -0000 Received: from acsinet15.oracle.com (HELO acsinet15.oracle.com) (141.146.126.227) by server-11.tower-174.messagelabs.com with DHE-RSA-AES256-SHA encrypted SMTP; 6 Sep 2011 16:32:34 -0000 Received: from rtcsinet21.oracle.com (rtcsinet21.oracle.com [66.248.204.29]) by acsinet15.oracle.com (Switch-3.4.4/Switch-3.4.4) with ESMTP id p86GWT4T020819 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Tue, 6 Sep 2011 16:32:32 GMT Received: from acsmt358.oracle.com (acsmt358.oracle.com [141.146.40.158]) by rtcsinet21.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id p86GWRqt011585 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 6 Sep 2011 16:32:29 GMT Received: from abhmt105.oracle.com (abhmt105.oracle.com [141.146.116.57]) by acsmt358.oracle.com (8.12.11.20060308/8.12.11) with ESMTP id p86GWNAT015486; Tue, 6 Sep 2011 11:32:24 -0500 Received: from phenom (/209.6.55.207) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Tue, 06 Sep 2011 09:32:23 -0700 Received: by phenom (Postfix, from userid 1000) id 05D7BFD1; Tue, 6 Sep 2011 12:32:13 -0400 (EDT) Date: Tue, 6 Sep 2011 12:32:13 -0400 From: Konrad Rzeszutek Wilk To: Marek Marczykowski Subject: Re: [Xen-devel] blkfront problem in pvops kernel when barriers enabled Message-ID: <20110906163213.GC5264@dumpdata.com> References: <4E6357C6.6050101@mimuw.edu.pl> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <4E6357C6.6050101@mimuw.edu.pl> User-Agent: Mutt/1.5.21 (2010-09-15) X-Source-IP: rtcsinet21.oracle.com [66.248.204.29] X-CT-RefId: str=0001.0A090209.4E664B20.00CD,ss=1,re=0.000,fgs=0 Cc: "xen-devel@lists.xensource.com" X-BeenThere: xen-devel@lists.xensource.com X-Mailman-Version: 2.1.5 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xensource.com Errors-To: xen-devel-bounces@lists.xensource.com On Sun, Sep 04, 2011 at 12:49:42PM +0200, Marek Marczykowski wrote: > Hello, > > Pvops block frontend (tested vanilla 3.0.3, 3.1rc2, Konrad's testing > branch) produces a lot of I/O errors when barriers are enabled but > cannot be used. > > On xenlinux I've got message: > [ 15.036921] blkfront: xvdb: empty write barrier op failed > [ 15.036936] blkfront: xvdb: barriers disabled > > and after that, everything works fine. On pvops - I/O errors. > As backend I've used 2.6.38.3 xenlinux (based on SUSE package) and > 3.1rc2 with same result. Hm, and the 'feature-barrier' was enabled on in those backends? That is really bizzare considering that those backends don't actually support WRITE_BARRIER anymore. > > When I disable barriers (patching blkbackend to set feature-barrier=0) > everything works fine with all above versions. Ok, and the patch you sent "[PATCH] Initialize vars in blkfront_connect" as well? > > My setup is xen-4.1.1 (if it matters), backends: phy from device-mapper > device and phy from loop device; frontends covered by device-mapper > snapshot, which is set up in domU initramfs. > > It looks like some race condition, because when I setup device-mapper in > domU and mount it manually (which cause some delays between steps), it > works fine... > > Have you idea why it happens? What additional data can I provide debug it? > > In addition it should be possible to disable barrier without patching > module... Perhaps some pciback module parameter? Or leave feature-* Not sure why you would touch pciback.. But the barrier should _not_ be enabled in those backends. The 'feature-flush-cache' should be. > xenstore entries alone if present before device initialization. > > -- > Pozdrawiam / Best Regards, > Marek Marczykowski | RLU #390519 > marmarek at mimuw edu pl | xmpp:marmarek at staszic waw pl > > _______________________________________________ > Xen-devel mailing list > Xen-devel@lists.xensource.com > http://lists.xensource.com/xen-devel _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel From xen-devel-bounces@lists.xensource.com Tue Sep 06 09:34:29 2011 Return-path: Envelope-to: www-data@lists.xensource.com Delivery-date: Tue, 06 Sep 2011 09:34:29 -0700 Received: from localhost ([127.0.0.1] helo=lists.colo.xensource.com) by lists.xensource.com with esmtp (Exim 4.43) id 1R0ybV-0006nV-GA; Tue, 06 Sep 2011 09:34:29 -0700 Received: from mail21.messagelabs.com ([85.158.143.35]) by lists.xensource.com with esmtp (Exim 4.43) id 1R0yal-0006YD-EM for xen-devel@lists.xensource.com; Tue, 06 Sep 2011 09:33:43 -0700 X-Env-Sender: Stefano.Stabellini@eu.citrix.com X-Msg-Ref: server-5.tower-21.messagelabs.com!1315326787!47096427!1 X-Originating-IP: [66.165.176.63] X-StarScan-Version: 6.3.6; banners=-,-,- X-VirusChecked: Checked Received: (qmail 16549 invoked from network); 6 Sep 2011 16:33:08 -0000 Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63) by server-5.tower-21.messagelabs.com with RC4-SHA encrypted SMTP; 6 Sep 2011 16:33:08 -0000 X-IronPort-AV: E=Sophos;i="4.68,339,1312171200"; d="scan'208";a="161862817" Received: from ftlpmailmx02.citrite.net ([10.13.107.66]) by FTLPIPO02.CITRIX.COM with ESMTP/TLS/RC4-MD5; 06 Sep 2011 12:33:36 -0400 Received: from smtp01.ad.xensource.com (10.219.128.104) by smtprelay.citrix.com (10.13.107.66) with Microsoft SMTP Server id 8.3.137.0; Tue, 6 Sep 2011 12:33:36 -0400 Received: from localhost.localdomain (kaball.uk.xensource.com [10.80.2.59]) by smtp01.ad.xensource.com (8.13.1/8.13.1) with ESMTP id p86GXSOt022549; Tue, 6 Sep 2011 09:33:29 -0700 From: To: konrad.wilk@oracle.com Date: Tue, 6 Sep 2011 17:41:47 +0100 Message-ID: <1315327307-392-1-git-send-email-stefano.stabellini@eu.citrix.com> X-Mailer: git-send-email 1.7.0.4 MIME-Version: 1.0 Content-Type: text/plain Cc: xen-devel@lists.xensource.com, linux-kernel@vger.kernel.org, Stefano Stabellini , Stefano.Stabellini@eu.citrix.com Subject: [Xen-devel] [PATCH] xen: disable PV spinlocks on HVM X-BeenThere: xen-devel@lists.xensource.com X-Mailman-Version: 2.1.5 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xensource.com Errors-To: xen-devel-bounces@lists.xensource.com From: Stefano Stabellini PV spinlocks cannot possibly work with the current code because they are enabled after pvops patching has already been done, and because PV spinlocks use a different data structure than native spinlocks so we cannot switch between them dynamically. A spinlock that has been taken once by the native code (__ticket_spin_lock) cannot be taken by __xen_spin_lock even after it has been released. Reported-by: Stefan Bader Signed-off-by: Stefano Stabellini --- arch/x86/xen/smp.c | 1 - 1 files changed, 0 insertions(+), 1 deletions(-) diff --git a/arch/x86/xen/smp.c b/arch/x86/xen/smp.c index e79dbb9..51339b4 100644 --- a/arch/x86/xen/smp.c +++ b/arch/x86/xen/smp.c @@ -522,7 +522,6 @@ static void __init xen_hvm_smp_prepare_cpus(unsigned int max_cpus) WARN_ON(xen_smp_intr_init(0)); xen_init_lock_cpu(0); - xen_init_spinlocks(); } static int __cpuinit xen_hvm_cpu_up(unsigned int cpu) -- 1.7.2.3 _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel From xen-devel-bounces@lists.xensource.com Tue Sep 06 09:36:38 2011 Return-path: Envelope-to: www-data@lists.xensource.com Delivery-date: Tue, 06 Sep 2011 09:36:38 -0700 Received: from localhost ([127.0.0.1] helo=lists.colo.xensource.com) by lists.xensource.com with esmtp (Exim 4.43) id 1R0yda-0007Bu-5J; Tue, 06 Sep 2011 09:36:38 -0700 Received: from mail216.messagelabs.com ([85.158.143.99]) by lists.xensource.com with esmtp (Exim 4.43) id 1R0yd5-0006zs-H5 for xen-devel@lists.xensource.com; Tue, 06 Sep 2011 09:36:07 -0700 X-Env-Sender: joanna@invisiblethingslab.com X-Msg-Ref: server-10.tower-216.messagelabs.com!1315326963!9203487!1 X-Originating-IP: [66.111.4.28] X-StarScan-Version: 6.3.6; banners=-,-,- X-VirusChecked: Checked Received: (qmail 9184 invoked from network); 6 Sep 2011 16:36:04 -0000 Received: from out4.smtp.messagingengine.com (HELO out4.smtp.messagingengine.com) (66.111.4.28) by server-10.tower-216.messagelabs.com with DHE-RSA-AES256-SHA encrypted SMTP; 6 Sep 2011 16:36:04 -0000 Received: from compute6.internal (compute6.nyi.mail.srv.osa [10.202.2.46]) by gateway1.nyi.mail.srv.osa (Postfix) with ESMTP id 55AB224402; Tue, 6 Sep 2011 12:36:03 -0400 (EDT) Received: from frontend2.nyi.mail.srv.osa ([10.202.2.161]) by compute6.internal (MEProxy); Tue, 06 Sep 2011 12:36:03 -0400 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d= messagingengine.com; h=message-id:date:from:mime-version:to:cc :subject:references:in-reply-to:content-type; s=smtpout; bh=7QCW BIKzahwi8W7AlrCdMv0tywI=; b=QBkFQE/0FXQFs4u8PD+Bfe6dl24tm8TKO+kp xw7Jq3ImxqRwukpmGAG1SjAVpguD23JmoKzpohirp3hrrPlsF5Bmwq4rurGFcM5h +qtjW53wqkW1NUYwvmG6SOStHTZR6DiSeznNoyUYeBy9ZeX+omPKMnCk18s1uMD4 G6CT0/M= X-Sasl-enc: YbSKFIwNq621U3n1QpQK2u5lLU7fpxEWC5nGs0A4/vBk 1315326962 Received: from [10.137.2.8] (aatx51.neoplus.adsl.tpnet.pl [83.6.5.51]) by mail.messagingengine.com (Postfix) with ESMTPSA id 8AC718E0237; Tue, 6 Sep 2011 12:36:02 -0400 (EDT) Message-ID: <4E664BEE.9000208@invisiblethingslab.com> Date: Tue, 06 Sep 2011 18:35:58 +0200 From: Joanna Rutkowska User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.2.18) Gecko/20110621 Fedora/3.1.11-1.fc14 Thunderbird/3.1.11 MIME-Version: 1.0 To: Dan Magenheimer Subject: Re: [Xen-devel] dom0 is stalled until a keypress References: <20110905091937.GA1906@email> <36a5b662-4420-41aa-be01-445f83b15a7b@default> In-Reply-To: <36a5b662-4420-41aa-be01-445f83b15a7b@default> X-Enigmail-Version: 1.1.2 Cc: xen-devel@lists.xensource.com, Rafal Wojtczuk X-BeenThere: xen-devel@lists.xensource.com X-Mailman-Version: 2.1.5 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1638461726==" Sender: xen-devel-bounces@lists.xensource.com Errors-To: xen-devel-bounces@lists.xensource.com This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --===============1638461726== Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="------------enig8412AECBE07A109407FDDB35" This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enig8412AECBE07A109407FDDB35 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable On 09/06/11 17:49, Dan Magenheimer wrote: >> From: Rafal Wojtczuk [mailto:rafal@invisiblethingslab.com] >> Sent: Monday, September 05, 2011 3:20 AM >> To: xen-devel@lists.xensource.com >> Subject: [Xen-devel] dom0 is stalled until a keypress >> >> Hello, >> The following bizarre behaviour was observed on xen4.1+suse dom0 2.6.3= 8, on >> an old Core Duo laptop; maybe someone can hint what is wrong. >> Dom0 boot stalls after an init.d script prints "Starting udev". Then n= othing >> seems to happen. I need to press any key to observe progress - I need = to do >> it tens of times for the boot to finish. After X starts fine, then the= re is >> no need for keypressing anymore. >> A particularly disturbing fact is that qrexec_daemon parent, that basi= cally >> does >> for (;;) { sleep(1); fprintf(stderr, "."); } >> does not print dots, until a keypress arrives. So something is very wr= ong >> with timers. >> Somehow similarly, pm-suspend sometimes hangs at some stage - after de= taching >> power cord, machine enters S3 immediately. >> This is vaguely similar to the issue described in >> https://lkml.org/lkml/2008/9/14/122 >> but this time, "nohz=3Doff" does not help. >> >> "cpufreq=3Ddom0-kernel" cures the symptoms; but it is not a sideeffect= less >> solution. Any idea what is going on or how to debug it ? >=20 > ISTR seeing this on a Core(2?)Duo laptop and I think the > workaround was setting max_cstate=3D0 (as Xen boot parameter). >=20 But what was the actual problem? Setting max_cstate is probably even worse for power management than setting cpufreq=3Ddom-kernel, isn't it? Thanks, joanna. --------------enig8412AECBE07A109407FDDB35 Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org/ iQEcBAEBAgAGBQJOZkvuAAoJEDaIqHeRBUM0RfAIALzSuoL8H2ZLHO4SANiPMoO1 M1Sw2wKDWXDqdjcrmyHwa0Pd4LxjigQXUhQ7TkCYYEVA1Poc0Qi9lpqdRqWUXeLr piVZD2zD49K6lWsJLzbBum+l1dI/Q4XSXkKWOhHcohBkcYfaOz1kPcH/tbZaxbNd xsqn46uxmAeGG70CP2Zr1CIpMcvT+fYr3lv37eSKfs0EubZ6Zh7vnr6t6Y0DK8+L exuOrj2Fq9d9iY+A5Yk6LUP06sizbUTlvqiJMh5na4kpNohOj/2nquUoetCW4MHA AgtH91JGO7lxNlrYYQ8yXCHlbBc7XBw3PFy8SaXK0Whtjapv1F4mZnsZ3Pzu5OQ= =2nYZ -----END PGP SIGNATURE----- --------------enig8412AECBE07A109407FDDB35-- --===============1638461726== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel --===============1638461726==-- From xen-devel-bounces@lists.xensource.com Tue Sep 06 09:37:34 2011 Return-path: Envelope-to: www-data@lists.xensource.com Delivery-date: Tue, 06 Sep 2011 09:37:34 -0700 Received: from localhost ([127.0.0.1] helo=lists.colo.xensource.com) by lists.xensource.com with esmtp (Exim 4.43) id 1R0yeU-0007Zx-CT; Tue, 06 Sep 2011 09:37:34 -0700 Received: from mail174.messagelabs.com ([85.158.138.51]) by lists.xensource.com with esmtp (Exim 4.43) id 1R0ydx-0007Ko-9V for xen-devel@lists.xensource.com; Tue, 06 Sep 2011 09:37:02 -0700 X-Env-Sender: konrad@dumpdata.com X-Msg-Ref: server-4.tower-174.messagelabs.com!1315327016!30465965!1 X-Originating-IP: [148.87.113.117] X-StarScan-Version: 6.3.6; banners=-,-,- X-VirusChecked: Checked Received: (qmail 13444 invoked from network); 6 Sep 2011 16:36:58 -0000 Received: from rcsinet15.oracle.com (HELO rcsinet15.oracle.com) (148.87.113.117) by server-4.tower-174.messagelabs.com with DHE-RSA-AES256-SHA encrypted SMTP; 6 Sep 2011 16:36:58 -0000 Received: from acsinet21.oracle.com (acsinet21.oracle.com [141.146.126.237]) by rcsinet15.oracle.com (Switch-3.4.4/Switch-3.4.4) with ESMTP id p86GaDT5020531 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Tue, 6 Sep 2011 16:36:15 GMT Received: from acsmt357.oracle.com (acsmt357.oracle.com [141.146.40.157]) by acsinet21.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id p86GaB5Z029808 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 6 Sep 2011 16:36:11 GMT Received: from abhmt113.oracle.com (abhmt113.oracle.com [141.146.116.65]) by acsmt357.oracle.com (8.12.11.20060308/8.12.11) with ESMTP id p86Ga44P016532; Tue, 6 Sep 2011 11:36:04 -0500 Received: from phenom (/209.6.55.207) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Tue, 06 Sep 2011 09:36:04 -0700 Received: by phenom (Postfix, from userid 1000) id EA89CFD1; Tue, 6 Sep 2011 12:35:53 -0400 (EDT) Date: Tue, 6 Sep 2011 12:35:53 -0400 From: Konrad Rzeszutek Wilk To: Andrew Morton Subject: Re: [Xen-devel] Re: [Revert] Re: [PATCH] mm: sync vmalloc address space page tables in alloc_vm_area() Message-ID: <20110906163553.GA28971@dumpdata.com> References: <1314877863-21977-1-git-send-email-david.vrabel@citrix.com> <20110901161134.GA8979@dumpdata.com> <4E5FED1A.1000300@goop.org> <20110901141754.76cef93b.akpm@linux-foundation.org> <4E60C067.4010600@citrix.com> <20110902153204.59a928c1.akpm@linux-foundation.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20110902153204.59a928c1.akpm@linux-foundation.org> User-Agent: Mutt/1.5.21 (2010-09-15) X-Source-IP: acsinet21.oracle.com [141.146.126.237] X-Auth-Type: Internal IP X-CT-RefId: str=0001.0A090203.4E664C01.01A0:SCFMA922111,ss=1,re=-4.000,fgs=0 Cc: Jeremy Fitzhardinge , "xen-devel@lists.xensource.com" , "namhyung@gmail.com" , "linux-kernel@vger.kernel.org" , "linux-mm@kvack.org" , David Vrabel , "rientjes@google.com" , "paulmck@linux.vnet.ibm.com" X-BeenThere: xen-devel@lists.xensource.com X-Mailman-Version: 2.1.5 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xensource.com Errors-To: xen-devel-bounces@lists.xensource.com On Fri, Sep 02, 2011 at 03:32:04PM -0700, Andrew Morton wrote: > On Fri, 2 Sep 2011 12:39:19 +0100 > David Vrabel wrote: > > > Xen backend drivers (e.g., blkback and netback) would sometimes fail > > to map grant pages into the vmalloc address space allocated with > > alloc_vm_area(). The GNTTABOP_map_grant_ref would fail because Xen > > could not find the page (in the L2 table) containing the PTEs it > > needed to update. > > > > (XEN) mm.c:3846:d0 Could not find L1 PTE for address fbb42000 > > > > netback and blkback were making the hypercall from a kernel thread > > where task->active_mm != &init_mm and alloc_vm_area() was only > > updating the page tables for init_mm. The usual method of deferring > > the update to the page tables of other processes (i.e., after taking a > > fault) doesn't work as a fault cannot occur during the hypercall. > > > > This would work on some systems depending on what else was using > > vmalloc. > > > > Fix this by reverting ef691947d8a3d479e67652312783aedcf629320a > > (vmalloc: remove vmalloc_sync_all() from alloc_vm_area()) and add a > > comment to explain why it's needed. > > oookay, I queued this for 3.1 and tagged it for a 3.0.x backport. I > *think* that's the outcome of this discussion, for the short-term? Yup. Thanks! _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel From xen-devel-bounces@lists.xensource.com Tue Sep 06 09:56:15 2011 Return-path: Envelope-to: www-data@lists.xensource.com Delivery-date: Tue, 06 Sep 2011 09:56:15 -0700 Received: from localhost ([127.0.0.1] helo=lists.colo.xensource.com) by lists.xensource.com with esmtp (Exim 4.43) id 1R0ywZ-0008DS-BD; Tue, 06 Sep 2011 09:56:15 -0700 Received: from mail182.messagelabs.com ([85.158.139.83]) by lists.xensource.com with esmtp (Exim 4.43) id 1R0yw7-00080y-MT for xen-devel@lists.xensource.com; Tue, 06 Sep 2011 09:55:48 -0700 X-Env-Sender: konrad@dumpdata.com X-Msg-Ref: server-4.tower-182.messagelabs.com!1315328142!17291399!1 X-Originating-IP: [148.87.113.117] X-StarScan-Version: 6.3.6; banners=-,-,- X-VirusChecked: Checked Received: (qmail 22054 invoked from network); 6 Sep 2011 16:55:44 -0000 Received: from rcsinet15.oracle.com (HELO rcsinet15.oracle.com) (148.87.113.117) by server-4.tower-182.messagelabs.com with DHE-RSA-AES256-SHA encrypted SMTP; 6 Sep 2011 16:55:44 -0000 Received: from rtcsinet21.oracle.com (rtcsinet21.oracle.com [66.248.204.29]) by rcsinet15.oracle.com (Switch-3.4.4/Switch-3.4.4) with ESMTP id p86GteM7022703 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Tue, 6 Sep 2011 16:55:42 GMT Received: from acsmt356.oracle.com (acsmt356.oracle.com [141.146.40.156]) by rtcsinet21.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id p86Gtcd8022760 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 6 Sep 2011 16:55:39 GMT Received: from abhmt111.oracle.com (abhmt111.oracle.com [141.146.116.63]) by acsmt356.oracle.com (8.12.11.20060308/8.12.11) with ESMTP id p86GtXDO006705; Tue, 6 Sep 2011 11:55:33 -0500 Received: from phenom (/209.6.55.207) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Tue, 06 Sep 2011 09:55:33 -0700 Received: by phenom (Postfix, from userid 1000) id EFCE2FD1; Tue, 6 Sep 2011 12:55:22 -0400 (EDT) Date: Tue, 6 Sep 2011 12:55:22 -0400 From: Konrad Rzeszutek Wilk To: Marek Marczykowski , JBeulich@novell.com Subject: Re: [Xen-devel] blkfront problem in pvops kernel when barriers enabled Message-ID: <20110906165522.GD28971@dumpdata.com> References: <4E6357C6.6050101@mimuw.edu.pl> <20110906163213.GC5264@dumpdata.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20110906163213.GC5264@dumpdata.com> User-Agent: Mutt/1.5.21 (2010-09-15) X-Source-IP: rtcsinet21.oracle.com [66.248.204.29] X-CT-RefId: str=0001.0A090206.4E66508E.00D6,ss=1,re=0.000,fgs=0 Cc: "xen-devel@lists.xensource.com" X-BeenThere: xen-devel@lists.xensource.com X-Mailman-Version: 2.1.5 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xensource.com Errors-To: xen-devel-bounces@lists.xensource.com On Tue, Sep 06, 2011 at 12:32:13PM -0400, Konrad Rzeszutek Wilk wrote: > On Sun, Sep 04, 2011 at 12:49:42PM +0200, Marek Marczykowski wrote: > > Hello, > > > > Pvops block frontend (tested vanilla 3.0.3, 3.1rc2, Konrad's testing > > branch) produces a lot of I/O errors when barriers are enabled but > > cannot be used. > > > > On xenlinux I've got message: > > [ 15.036921] blkfront: xvdb: empty write barrier op failed > > [ 15.036936] blkfront: xvdb: barriers disabled > > > > and after that, everything works fine. On pvops - I/O errors. > > As backend I've used 2.6.38.3 xenlinux (based on SUSE package) and > > 3.1rc2 with same result. > > Hm, and the 'feature-barrier' was enabled on in those backends? > That is really bizzare considering that those backends don't actually > support WRITE_BARRIER anymore. To be exact: http://lwn.net/Articles/399715/ so in 2.6.37-era ish the WRITE_BARRIER functionality got ripped out. And the LFS summit in 2010 had more details: http://lwn.net/Articles/399148/ "That led, eventually, to one of the clearest decisions in the first day of the summit: barriers, as such, will be no more." And WRITE_BARRIER != WRITE_FLUSH so if the SuSE backend is using it as so - then there is a bug in there. In the 3.1-rc2 upstream kernel there should be absolutly no hint of 'feature-barrier' in the _backend_ code (it is OK for it to be in the frontend code). Can you confirm where you got your sources? P.S. There should be a backwards compatible way of implementing the 'feature-barrier' in the block backend of 3.0 and further kernels.. but nobody has stepped up in implementing it. Also, one more thing - are you sure you are using the block backend? You might be using the QEMU qdisk? _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel From xen-devel-bounces@lists.xensource.com Tue Sep 06 10:05:02 2011 Return-path: Envelope-to: www-data@lists.xensource.com Delivery-date: Tue, 06 Sep 2011 10:05:02 -0700 Received: from localhost ([127.0.0.1] helo=lists.colo.xensource.com) by lists.xensource.com with esmtp (Exim 4.43) id 1R0z52-0000I4-Lj; Tue, 06 Sep 2011 10:05:00 -0700 Received: from mail21.messagelabs.com ([85.158.143.35]) by lists.xensource.com with esmtp (Exim 4.43) id 1R0z3T-000051-Gr for xen-devel@lists.xensource.com; Tue, 06 Sep 2011 10:03:24 -0700 X-Env-Sender: konrad@dumpdata.com X-Msg-Ref: server-4.tower-21.messagelabs.com!1315328565!59194488!1 X-Originating-IP: [141.146.126.227] X-StarScan-Version: 6.3.6; banners=-,-,- X-VirusChecked: Checked Received: (qmail 5327 invoked from network); 6 Sep 2011 17:02:46 -0000 Received: from acsinet15.oracle.com (HELO acsinet15.oracle.com) (141.146.126.227) by server-4.tower-21.messagelabs.com with DHE-RSA-AES256-SHA encrypted SMTP; 6 Sep 2011 17:02:46 -0000 Received: from acsinet22.oracle.com (acsinet22.oracle.com [141.146.126.238]) by acsinet15.oracle.com (Switch-3.4.4/Switch-3.4.4) with ESMTP id p86H3CRn016363 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Tue, 6 Sep 2011 17:03:14 GMT Received: from acsmt357.oracle.com (acsmt357.oracle.com [141.146.40.157]) by acsinet22.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id p86H3Bm7000339 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 6 Sep 2011 17:03:12 GMT Received: from abhmt107.oracle.com (abhmt107.oracle.com [141.146.116.59]) by acsmt357.oracle.com (8.12.11.20060308/8.12.11) with ESMTP id p86H36PR006495; Tue, 6 Sep 2011 12:03:06 -0500 Received: from phenom (/209.6.55.207) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Tue, 06 Sep 2011 10:03:06 -0700 Received: by phenom (Postfix, from userid 1000) id D190DFD1; Tue, 6 Sep 2011 13:02:55 -0400 (EDT) Date: Tue, 6 Sep 2011 13:02:55 -0400 From: Konrad Rzeszutek Wilk To: stefano.stabellini@eu.citrix.com, stefan.bader@canonical.com Subject: Re: [Xen-devel] [PATCH] xen: disable PV spinlocks on HVM Message-ID: <20110906170255.GA29839@dumpdata.com> References: <1315327307-392-1-git-send-email-stefano.stabellini@eu.citrix.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <1315327307-392-1-git-send-email-stefano.stabellini@eu.citrix.com> User-Agent: Mutt/1.5.21 (2010-09-15) X-Source-IP: acsinet22.oracle.com [141.146.126.238] X-Auth-Type: Internal IP X-CT-RefId: str=0001.0A020202.4E665252.0124:SCFMA922111,ss=1,re=-4.000,fgs=0 Cc: xen-devel@lists.xensource.com, linux-kernel@vger.kernel.org X-BeenThere: xen-devel@lists.xensource.com X-Mailman-Version: 2.1.5 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xensource.com Errors-To: xen-devel-bounces@lists.xensource.com On Tue, Sep 06, 2011 at 05:41:47PM +0100, stefano.stabellini@eu.citrix.com wrote: > From: Stefano Stabellini > > PV spinlocks cannot possibly work with the current code because they are > enabled after pvops patching has already been done, and because PV > spinlocks use a different data structure than native spinlocks so we > cannot switch between them dynamically. A spinlock that has been taken > once by the native code (__ticket_spin_lock) cannot be taken by > __xen_spin_lock even after it has been released. Let me stick it on my 3.1-rc5 bug-fix list and add stable@kernel.org to it. Stefan, if you have some time this week, and can test it - I can also stick 'Tested-by' if you would like. Thinking to send the patches on Friday. > > Reported-by: Stefan Bader > Signed-off-by: Stefano Stabellini > --- > arch/x86/xen/smp.c | 1 - > 1 files changed, 0 insertions(+), 1 deletions(-) > > diff --git a/arch/x86/xen/smp.c b/arch/x86/xen/smp.c > index e79dbb9..51339b4 100644 > --- a/arch/x86/xen/smp.c > +++ b/arch/x86/xen/smp.c > @@ -522,7 +522,6 @@ static void __init xen_hvm_smp_prepare_cpus(unsigned int max_cpus) > WARN_ON(xen_smp_intr_init(0)); > > xen_init_lock_cpu(0); > - xen_init_spinlocks(); > } > > static int __cpuinit xen_hvm_cpu_up(unsigned int cpu) > -- > 1.7.2.3 > > > _______________________________________________ > Xen-devel mailing list > Xen-devel@lists.xensource.com > http://lists.xensource.com/xen-devel _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel From xen-devel-bounces@lists.xensource.com Tue Sep 06 10:14:32 2011 Return-path: Envelope-to: www-data@lists.xensource.com Delivery-date: Tue, 06 Sep 2011 10:14:32 -0700 Received: from localhost ([127.0.0.1] helo=lists.colo.xensource.com) by lists.xensource.com with esmtp (Exim 4.43) id 1R0zEG-0001Wl-7y; Tue, 06 Sep 2011 10:14:32 -0700 Received: from mail27.messagelabs.com ([193.109.254.147]) by lists.xensource.com with esmtp (Exim 4.43) id 1R0zDb-0001K8-3Y for xen-devel@lists.xensource.com; Tue, 06 Sep 2011 10:13:51 -0700 X-Env-Sender: konrad@dumpdata.com X-Msg-Ref: server-7.tower-27.messagelabs.com!1315329205!47537947!1 X-Originating-IP: [148.87.113.117] X-StarScan-Version: 6.3.6; banners=-,-,- X-VirusChecked: Checked Received: (qmail 23177 invoked from network); 6 Sep 2011 17:13:27 -0000 Received: from rcsinet15.oracle.com (HELO rcsinet15.oracle.com) (148.87.113.117) by server-7.tower-27.messagelabs.com with DHE-RSA-AES256-SHA encrypted SMTP; 6 Sep 2011 17:13:27 -0000 Received: from rtcsinet21.oracle.com (rtcsinet21.oracle.com [66.248.204.29]) by rcsinet15.oracle.com (Switch-3.4.4/Switch-3.4.4) with ESMTP id p86HDeIh025512 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Tue, 6 Sep 2011 17:13:42 GMT Received: from acsmt358.oracle.com (acsmt358.oracle.com [141.146.40.158]) by rtcsinet21.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id p86HDath026438 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 6 Sep 2011 17:13:37 GMT Received: from abhmt112.oracle.com (abhmt112.oracle.com [141.146.116.64]) by acsmt358.oracle.com (8.12.11.20060308/8.12.11) with ESMTP id p86HDURf016689; Tue, 6 Sep 2011 12:13:30 -0500 Received: from phenom (/209.6.55.207) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Tue, 06 Sep 2011 10:13:30 -0700 Received: by phenom (Postfix, from userid 1000) id 03AB0FD1; Tue, 6 Sep 2011 13:13:19 -0400 (EDT) Date: Tue, 6 Sep 2011 13:13:19 -0400 From: Konrad Rzeszutek Wilk To: "Christopher S. Aker" Subject: Re: [Xen-devel] Re: kernel BUG at mm/swapfile.c:2527! [was 3.0.0 Xen pv guest - BUG: Unable to handle] Message-ID: <20110906171319.GB29839@dumpdata.com> References: <9CAEB881-07FE-437C-8A6B-DB7B690CEABE@linode.com> <4E5BA49D.5060800@theshore.net> <20110829150734.GB24825@dumpdata.com> <1314704744.28989.2.camel@zakaz.uk.xensource.com> <4E5E9CDB.3070706@theshore.net> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <4E5E9CDB.3070706@theshore.net> User-Agent: Mutt/1.5.21 (2010-09-15) X-Source-IP: rtcsinet21.oracle.com [66.248.204.29] X-CT-RefId: str=0001.0A090202.4E6654C8.0025,ss=1,re=-2.300,fgs=0 Cc: Jeremy Fitzhardinge , "xen-devel@lists.xensource.com" , Ian Campbell , LKML X-BeenThere: xen-devel@lists.xensource.com X-Mailman-Version: 2.1.5 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xensource.com Errors-To: xen-devel-bounces@lists.xensource.com On Wed, Aug 31, 2011 at 04:43:07PM -0400, Christopher S. Aker wrote: > On 8/30/11 7:45 AM, Ian Campbell wrote: > >On Mon, 2011-08-29 at 16:07 +0100, Konrad Rzeszutek Wilk wrote: > >>I just don't get how you are the only person seeing this - and you have > >>been seeing this from 2.6.32... The dom0 you have - is it printing at least > >>something when this happens (or before)? Or the Xen hypervisor: > >>maybe a message about L1 pages not found? So .. just to confirm this b/c you have been seeing this for some time. Did you see this with a 2.6.32 DomU? Asking b/c in 2.6.37 we removed some code: ef691947d8a3d479e67652312783aedcf629320a commit ef691947d8a3d479e67652312783aedcf629320a Author: Jeremy Fitzhardinge Date: Wed Dec 1 15:45:48 2010 -0800 vmalloc: remove vmalloc_sync_all() from alloc_vm_area() There's no need for it: it will get faulted into the current pagetable as needed. Signed-off-by: Jeremy Fitzhardinge diff --git a/mm/vmalloc.c b/mm/vmalloc.c index 5d60302..fdf4b1e 100644 --- a/mm/vmalloc.c +++ b/mm/vmalloc.c @@ -2148,10 +2148,6 @@ struct vm_struct *alloc_vm_area(size_t size) return NULL; } - /* Make sure the pagetables are constructed in process kernel - mappings */ - vmalloc_sync_all(); - return area; } EXPORT_SYMBOL_GPL(alloc_vm_area); Which we found led to a couple of bugs: " Revert "vmalloc: remove vmalloc_sync_all() from alloc_vm_area()" This reverts commit ef691947d8a3d479e67652312783aedcf629320a. Xen backend drivers (e.g., blkback and netback) would sometimes fail to map grant pages into the vmalloc address space allocated with alloc_vm_area(). The GNTTABOP_map_grant_ref would fail because Xen could not find the page (in the L2 table) containing the PTEs it needed to update. (XEN) mm.c:3846:d0 Could not find L1 PTE for address fbb42000 netback and blkback were making the hypercall from a kernel thread where task->active_mm != &init_mm and alloc_vm_area() was only updating the page tables for init_mm. The usual method of deferring the update to the page tables of other processes (i.e., after taking a fault) doesn't work as a fault cannot occur during the hypercall. This would work on some systems depending on what else was using vmalloc. " It would really neat if the issue you have been hitting was exactly this and just having you revert the ef691947d8a3d479e67652312783aedcf629320a would fix it. I am grasping at straws here - since without able to reproduce this it is a bit hard to figure out what is going wrong. BTW, the fix also affects the front-ends - especially the xen netfront - even thought the comment only mentions backends. > > > >It'd be worth ensuring that the requires guest_loglvl and loglvl > >parameters to allow this is in place on the hypervisor command line. > > Nothing in Xen's output correlates at the time of the domUs > crashing, however we don't have guest log levels turned up. > > >Are these reports against totally unpatched kernel.org domU kernels? > > Yes - unpatched domUs. > > >>And the dom0 is 2.6.18, right? - Did you update it (I know that the Red Hat guys > >>have been updating a couple of things on it). > > 2.6.18 from xenbits, all around changeset 931 vintage. > > >>Any chance I can get access to your setup and try to work with somebody > >>to reproduce this? > > Konrad, that's a fantastic offer and much appreciated. To make this > happen I'll need to find a volunteer customer or two whose activity > reproduces this problem and who can deal with some downtime -- then > quarantine them off to an environment you can access. I'll send out > the word... > > >>>------------[ cut here ]------------ > >>>kernel BUG at mm/swapfile.c:2527! > > > >This is "BUG_ON(*map == 0);" which is subtly different from the error in > >the original post from Peter which was a "unable to handle kernel paging > >request" at EIP c01ab854, with a pagetable walk showing PTE==0. > > > >I'd bet the dereference corresponds to the "*map" in that same place but > >Peter can you convert that address to a line of code please? > > root@build:/build/xen/domU/i386/3.0.0-linode35-debug# gdb vmlinux > GNU gdb (GDB) 7.1-ubuntu (...snip...) > Reading symbols from > /build/xen/domU/i386/3.0.0-linode35-debug/vmlinux...done. > (gdb) list *0xc01ab854 > 0xc01ab854 is in swap_count_continued (mm/swapfile.c:2493). > 2488 > 2489 if (count == (SWAP_MAP_MAX | COUNT_CONTINUED)) { /* > incrementing */ > 2490 /* > 2491 * Think of how you add 1 to 999 > 2492 */ > 2493 while (*map == (SWAP_CONT_MAX | COUNT_CONTINUED)) { > 2494 kunmap_atomic(map, KM_USER0); > 2495 page = list_entry(page->lru.next, > struct page, lru); > 2496 BUG_ON(page == head); > 2497 map = kmap_atomic(page, KM_USER0) + offset; > (gdb) > > >map came from a kmap_atomic() not far before this point so it appears > >that it is mapping the wrong page (so *map != 0) and/or mapping a > >non-existent page (leading to the fault). > > > >Warning, wild speculation follows... > > > >Is it possible that we are in lazy paravirt mode at this point such that > >the mapping hasn't really occurred yet, leaving either nothing or the > >previous mapping? (would the current paravirt lazy state make a useful > >general addition to the panic message?) > > > >The definition of kmap_atomic is a bit confusing: > > /* > > * Make both: kmap_atomic(page, idx) and kmap_atomic(page) work. > > */ > > #define kmap_atomic(page, args...) __kmap_atomic(page) > >but it appears that the KM_USER0 at the callsite is ignored and instead > >we end up using the __kmap_atomic_idx stuff (fine). I wondered if it is > >possible we are overflowing the number of slots but there is an explicit > >BUG_ON for that case in kmap_atomic_idx_push. Oh, wait, that's iff > >CONFIG_DEBUG_HIGHMEM, which appears to not be enabled. I think it would > >be worth trying, it doesn't look to have too much overhead. > > My next build will be sure to include CONFIG_DEBUG_HIGHMEM. Maybe > that'll lead us to a discovery. > > >Another possibility which springs to mind is the pfn->mfn laundering > >going wrong. Perhaps as a skanky debug hack remembering the last pte > >val, address, mfn, pfn etc and dumping them on error would give a hint? > >I wouldn't expect that to result in a non-present mapping though, rather > >I would expect either the wrong thing or the guest to be killed by the > >hypervisor > > > >Would it be worth doing a __get_user(map) (or some other "safe" pointer > >dereference) right after the mapping is established, catching a fault if > >one occurs so we can dump some additional debug in that case? I'm not > >entirely sure what to suggest dumping though. > > > >Ian. > > > >>>invalid opcode: 0000 [#1] SMP > >>>last sysfs file: /sys/devices/system/cpu/cpu3/topology/core_id > >>>Modules linked in: > >>> > >>>Pid: 17680, comm: postgres Tainted: G B 2.6.39-linode33 #3 > >>>EIP: 0061:[] EFLAGS: 00210246 CPU: 0 > >>>EIP is at swap_count_continued+0x176/0x180 > >>>EAX: f57bac57 EBX: eba2c200 ECX: f57ba000 EDX: 00000000 > >>>ESI: ebfd7c20 EDI: 00000080 EBP: 00000c57 ESP: c670fe0c > >>> DS: 007b ES: 007b FS: 00d8 GS: 0000 SS: 0069 > >>>Process postgres (pid: 17680, ti=c670e000 task=e93415d0 task.ti=c670e000) > >>>Stack: > >>> e9e3a340 00013c57 ee15fc57 00000000 c01b60b1 c0731000 c06982d5 401b4b73 > >>> ceebc988 e9e3a340 00013c57 00000000 c01b60f7 ceebc988 b7731000 c670ff04 > >>> c01a7183 4646e045 80000005 e62ce348 28999063 c0103fc5 7f662000 00278ae0 > >>>Call Trace: > >>> [] ? swap_entry_free+0x121/0x140 > >>> [] ? _raw_spin_lock+0x5/0x10 > >>> [] ? free_swap_and_cache+0x27/0xd0 > >>> [] ? zap_pte_range+0x1b3/0x480 > >>> [] ? pte_pfn_to_mfn+0xb5/0xd0 > >>> [] ? unmap_page_range+0x118/0x1a0 > >>> [] ? xen_force_evtchn_callback+0x17/0x30 > >>> [] ? unmap_vmas+0x12b/0x1e0 > >>> [] ? exit_mmap+0x91/0x140 > >>> [] ? mmput+0x2b/0xc0 > >>> [] ? exit_mm+0xfa/0x130 > >>> [] ? _raw_spin_lock_irq+0x10/0x20 > >>> [] ? do_exit+0x125/0x360 > >>> [] ? xen_force_evtchn_callback+0x17/0x30 > >>> [] ? do_group_exit+0x3c/0xa0 > >>> [] ? sys_exit_group+0x11/0x20 > >>> [] ? syscall_call+0x7/0xb > >>>Code: ff 89 d8 e8 7d ec f6 ff 01 e8 8d 76 00 c6 00 00 ba 01 00 00 00 > >>>eb b2 89 f8 3c 80 0f 94 c0 > >>>e9 b9 fe ff ff 0f 0b eb fe 0f 0b eb fe<0f> 0b eb fe 0f 0b eb fe 66 > >>>90 53 31 db 83 ec 0c 85 c0 7 > >>>4 39 89 > >>>EIP: [] swap_count_continued+0x176/0x180 SS:ESP 0069:c670fe0c > >>>---[ end trace c2dcb41c89b0a9f7 ]--- > > > -- > To unsubscribe from this list: send the line "unsubscribe linux-kernel" in > the body of a message to majordomo@vger.kernel.org > More majordomo info at http://vger.kernel.org/majordomo-info.html > Please read the FAQ at http://www.tux.org/lkml/ _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel From xen-devel-bounces@lists.xensource.com Tue Sep 06 10:17:06 2011 Return-path: Envelope-to: www-data@lists.xensource.com Delivery-date: Tue, 06 Sep 2011 10:17:06 -0700 Received: from localhost ([127.0.0.1] helo=lists.colo.xensource.com) by lists.xensource.com with esmtp (Exim 4.43) id 1R0zGk-0001vS-IM; Tue, 06 Sep 2011 10:17:06 -0700 Received: from mail174.messagelabs.com ([85.158.138.51]) by lists.xensource.com with esmtp (Exim 4.43) id 1R0zGG-0001ii-4U for xen-devel@lists.xensource.com; Tue, 06 Sep 2011 10:16:36 -0700 X-Env-Sender: marmarek@mimuw.edu.pl X-Msg-Ref: server-6.tower-174.messagelabs.com!1315329392!28320179!1 X-Originating-IP: [193.0.96.6] X-StarScan-Version: 6.3.6; banners=-,-,- X-VirusChecked: Checked Received: (qmail 27989 invoked from network); 6 Sep 2011 17:16:32 -0000 Received: from mail.mimuw.edu.pl (HELO mail.mimuw.edu.pl) (193.0.96.6) by server-6.tower-174.messagelabs.com with DHE-RSA-AES256-SHA encrypted SMTP; 6 Sep 2011 17:16:32 -0000 Received: from localhost (localhost [127.0.0.1] ident=amavis) by duch.mimuw.edu.pl (Postfix) with ESMTP id A35695A; Tue, 6 Sep 2011 19:16:31 +0200 (CEST) X-Virus-Scanned: amavisd-new at mimuw.edu.pl Received: from duch.mimuw.edu.pl ([127.0.0.1]) by localhost (mail.mimuw.edu.pl [127.0.0.1]) (amavisd-new, port 10026) with ESMTP id 7iq+JUvnQaN0; Tue, 6 Sep 2011 19:16:30 +0200 (CEST) Received: from [10.137.1.11] (87-206-116-192.dynamic.chello.pl [87.206.116.192]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (No client certificate requested) by duch.mimuw.edu.pl (Postfix) with ESMTPSA; Tue, 6 Sep 2011 19:16:30 +0200 (CEST) Message-ID: <4E665572.7080009@mimuw.edu.pl> Date: Tue, 06 Sep 2011 19:16:34 +0200 From: Marek Marczykowski User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.2.18) Gecko/20110621 Fedora/3.1.11-1.fc14 Lightning/1.0b3pre Thunderbird/3.1.11 MIME-Version: 1.0 To: Konrad Rzeszutek Wilk Subject: Re: [Xen-devel] blkfront problem in pvops kernel when barriers enabled References: <4E6357C6.6050101@mimuw.edu.pl> <20110906163213.GC5264@dumpdata.com> In-Reply-To: <20110906163213.GC5264@dumpdata.com> X-Enigmail-Version: 1.1.2 Cc: "xen-devel@lists.xensource.com" X-BeenThere: xen-devel@lists.xensource.com X-Mailman-Version: 2.1.5 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1239862971==" Sender: xen-devel-bounces@lists.xensource.com Errors-To: xen-devel-bounces@lists.xensource.com This is a cryptographically signed message in MIME format. --===============1239862971== Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha1; boundary="------------ms000203010008080704050506" This is a cryptographically signed message in MIME format. --------------ms000203010008080704050506 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On 06.09.2011 18:32, Konrad Rzeszutek Wilk wrote: > On Sun, Sep 04, 2011 at 12:49:42PM +0200, Marek Marczykowski wrote: >> Hello, >> >> Pvops block frontend (tested vanilla 3.0.3, 3.1rc2, Konrad's testing >> branch) produces a lot of I/O errors when barriers are enabled but >> cannot be used. >> >> On xenlinux I've got message: >> [ 15.036921] blkfront: xvdb: empty write barrier op failed >> [ 15.036936] blkfront: xvdb: barriers disabled >> >> and after that, everything works fine. On pvops - I/O errors. >> As backend I've used 2.6.38.3 xenlinux (based on SUSE package) and >> 3.1rc2 with same result. >=20 > Hm, and the 'feature-barrier' was enabled on in those backends? > That is really bizzare considering that those backends don't actually > support WRITE_BARRIER anymore. At least in 2.6.38.3 xenlinux (SUSE). Now I'm not sure if 3.1rc2 also needed this modification (can't find it now). >> When I disable barriers (patching blkbackend to set feature-barrier=3D= 0) >> everything works fine with all above versions. >=20 > Ok, and the patch you sent "[PATCH] Initialize vars in blkfront_connect= " > as well? Yes. I've noticed now that this patch was needed only on your testing branch (not vanilla kernel). >> My setup is xen-4.1.1 (if it matters), backends: phy from device-mappe= r >> device and phy from loop device; frontends covered by device-mapper >> snapshot, which is set up in domU initramfs. >> >> It looks like some race condition, because when I setup device-mapper = in >> domU and mount it manually (which cause some delays between steps), it= >> works fine... >> >> Have you idea why it happens? What additional data can I provide debug= it? >> >> In addition it should be possible to disable barrier without patching >> module... Perhaps some pciback module parameter? Or leave feature-* >=20 > Not sure why you would touch pciback..=20 I mean blkback of course. > But the barrier should _not_ > be enabled in those backends. The 'feature-flush-cache' should be. (on 3.1rc2) Looking to xenstore now there is 'feature-flush-cache=3D1' an= d no 'feature-barrier'. So it is ok. --=20 Pozdrawiam / Best Regards, Marek Marczykowski | RLU #390519 marmarek at mimuw edu pl | xmpp:marmarek at staszic waw pl --------------ms000203010008080704050506 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIRqDCC BVcwggQ/oAMCAQICEGdLwnOg7SU/xzieX7FaFewwDQYJKoZIhvcNAQEFBQAwgd0xCzAJBgNV BAYTAlVTMRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNpZ24gVHJ1 c3QgTmV0d29yazE7MDkGA1UECxMyVGVybXMgb2YgdXNlIGF0IGh0dHBzOi8vd3d3LnZlcmlz aWduLmNvbS9ycGEgKGMpMDkxHjAcBgNVBAsTFVBlcnNvbmEgTm90IFZhbGlkYXRlZDE3MDUG A1UEAxMuVmVyaVNpZ24gQ2xhc3MgMSBJbmRpdmlkdWFsIFN1YnNjcmliZXIgQ0EgLSBHMzAe Fw0xMDEyMDgwMDAwMDBaFw0xMTEyMDgyMzU5NTlaMIIBGjEXMBUGA1UEChMOVmVyaVNpZ24s IEluYy4xHzAdBgNVBAsTFlZlcmlTaWduIFRydXN0IE5ldHdvcmsxRjBEBgNVBAsTPXd3dy52 ZXJpc2lnbi5jb20vcmVwb3NpdG9yeS9SUEEgSW5jb3JwLiBieSBSZWYuLExJQUIuTFREKGMp OTgxHjAcBgNVBAsTFVBlcnNvbmEgTm90IFZhbGlkYXRlZDEzMDEGA1UECxMqRGlnaXRhbCBJ RCBDbGFzcyAxIC0gTmV0c2NhcGUgRnVsbCBTZXJ2aWNlMRswGQYDVQQDFBJNQVJFSyBNYXJj enlrb3dza2kxJDAiBgkqhkiG9w0BCQEWFW1hcm1hcmVrQG1pbXV3LmVkdS5wbDCCASIwDQYJ KoZIhvcNAQEBBQADggEPADCCAQoCggEBAMGGGDj1KJXXy13nNqo0NP7EJNnzjWHih+Z88UA/ c/CZOIu3/SUnA9gly922moQ+r4AM0k6EQaVkAdldSOy1hO/fTcJQBwDemcnACWstMDMvIbWn dkxyxNgh8bQD/xKXx1SyfKTixcx0QZXosY8HnHLWeF0Te5U9J8yUPxigCFJFe6rtY2iARrWc qWXDr4DRQc5J43aohBXGRHw+OakREqLZds6HEE6+YvJH+udcfqlrfkLKHJeiyA4UPtZwBvam EGOKrm2rqyps/JeivaTs6zKh0+4eNxSKlOGTUmj4eHVb/K3gkbX6bihmWS+9nnN3I4HL+KPZ j88xQCHX07Gh4nECAwEAAaOB0jCBzzAJBgNVHRMEAjAAMEQGA1UdIAQ9MDswOQYLYIZIAYb4 RQEHFwEwKjAoBggrBgEFBQcCARYcaHR0cHM6Ly93d3cudmVyaXNpZ24uY29tL3JwYTALBgNV HQ8EBAMCBaAwHQYDVR0lBBYwFAYIKwYBBQUHAwQGCCsGAQUFBwMCMFAGA1UdHwRJMEcwRaBD oEGGP2h0dHA6Ly9pbmRjMWRpZ2l0YWxpZC1nMy1jcmwudmVyaXNpZ24uY29tL0luZEMxRGln aXRhbElELUczLmNybDANBgkqhkiG9w0BAQUFAAOCAQEAl7oehxokYa9omPurM44GROaRxtIQ acWWpCgeMNDqJXyEgm30u0hY1szXiSyVnkIx/sh4HuBqvXJnZZvLjksEIzdALTgCAskojzeT oeX+340loS87OO82/XUDT5YY3+R5G+4oQIxKVqF7kDmOuJ2opbjU4dFxHhIypiEcWjG2sjWd 127poxMQeY4lCk3qKw94pK5RpVPJK8hzaf+pWoL2D7i3L2xE+DMzZJ1OB3AxcGxhvupUq+zz 3Z9IIHo6DNOwUyCNR+ShVnuCaoJcya35mQzhs1s5+LcP/ysrUzhPo+iYNXGv+q5iNQEXZ7Dw kPgAm17fnxmih6D4KRbmrc3xpjCCBVcwggQ/oAMCAQICEGdLwnOg7SU/xzieX7FaFewwDQYJ KoZIhvcNAQEFBQAwgd0xCzAJBgNVBAYTAlVTMRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEf MB0GA1UECxMWVmVyaVNpZ24gVHJ1c3QgTmV0d29yazE7MDkGA1UECxMyVGVybXMgb2YgdXNl IGF0IGh0dHBzOi8vd3d3LnZlcmlzaWduLmNvbS9ycGEgKGMpMDkxHjAcBgNVBAsTFVBlcnNv bmEgTm90IFZhbGlkYXRlZDE3MDUGA1UEAxMuVmVyaVNpZ24gQ2xhc3MgMSBJbmRpdmlkdWFs IFN1YnNjcmliZXIgQ0EgLSBHMzAeFw0xMDEyMDgwMDAwMDBaFw0xMTEyMDgyMzU5NTlaMIIB GjEXMBUGA1UEChMOVmVyaVNpZ24sIEluYy4xHzAdBgNVBAsTFlZlcmlTaWduIFRydXN0IE5l dHdvcmsxRjBEBgNVBAsTPXd3dy52ZXJpc2lnbi5jb20vcmVwb3NpdG9yeS9SUEEgSW5jb3Jw LiBieSBSZWYuLExJQUIuTFREKGMpOTgxHjAcBgNVBAsTFVBlcnNvbmEgTm90IFZhbGlkYXRl ZDEzMDEGA1UECxMqRGlnaXRhbCBJRCBDbGFzcyAxIC0gTmV0c2NhcGUgRnVsbCBTZXJ2aWNl MRswGQYDVQQDFBJNQVJFSyBNYXJjenlrb3dza2kxJDAiBgkqhkiG9w0BCQEWFW1hcm1hcmVr QG1pbXV3LmVkdS5wbDCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAMGGGDj1KJXX y13nNqo0NP7EJNnzjWHih+Z88UA/c/CZOIu3/SUnA9gly922moQ+r4AM0k6EQaVkAdldSOy1 hO/fTcJQBwDemcnACWstMDMvIbWndkxyxNgh8bQD/xKXx1SyfKTixcx0QZXosY8HnHLWeF0T e5U9J8yUPxigCFJFe6rtY2iARrWcqWXDr4DRQc5J43aohBXGRHw+OakREqLZds6HEE6+YvJH +udcfqlrfkLKHJeiyA4UPtZwBvamEGOKrm2rqyps/JeivaTs6zKh0+4eNxSKlOGTUmj4eHVb /K3gkbX6bihmWS+9nnN3I4HL+KPZj88xQCHX07Gh4nECAwEAAaOB0jCBzzAJBgNVHRMEAjAA MEQGA1UdIAQ9MDswOQYLYIZIAYb4RQEHFwEwKjAoBggrBgEFBQcCARYcaHR0cHM6Ly93d3cu dmVyaXNpZ24uY29tL3JwYTALBgNVHQ8EBAMCBaAwHQYDVR0lBBYwFAYIKwYBBQUHAwQGCCsG AQUFBwMCMFAGA1UdHwRJMEcwRaBDoEGGP2h0dHA6Ly9pbmRjMWRpZ2l0YWxpZC1nMy1jcmwu dmVyaXNpZ24uY29tL0luZEMxRGlnaXRhbElELUczLmNybDANBgkqhkiG9w0BAQUFAAOCAQEA l7oehxokYa9omPurM44GROaRxtIQacWWpCgeMNDqJXyEgm30u0hY1szXiSyVnkIx/sh4HuBq vXJnZZvLjksEIzdALTgCAskojzeToeX+340loS87OO82/XUDT5YY3+R5G+4oQIxKVqF7kDmO uJ2opbjU4dFxHhIypiEcWjG2sjWd127poxMQeY4lCk3qKw94pK5RpVPJK8hzaf+pWoL2D7i3 L2xE+DMzZJ1OB3AxcGxhvupUq+zz3Z9IIHo6DNOwUyCNR+ShVnuCaoJcya35mQzhs1s5+LcP /ysrUzhPo+iYNXGv+q5iNQEXZ7DwkPgAm17fnxmih6D4KRbmrc3xpjCCBu4wggXWoAMCAQIC EHEVZgVK5JEhTem8RPms09wwDQYJKoZIhvcNAQEFBQAwgcoxCzAJBgNVBAYTAlVTMRcwFQYD VQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNpZ24gVHJ1c3QgTmV0d29yazE6 MDgGA1UECxMxKGMpIDE5OTkgVmVyaVNpZ24sIEluYy4gLSBGb3IgYXV0aG9yaXplZCB1c2Ug b25seTFFMEMGA1UEAxM8VmVyaVNpZ24gQ2xhc3MgMSBQdWJsaWMgUHJpbWFyeSBDZXJ0aWZp Y2F0aW9uIEF1dGhvcml0eSAtIEczMB4XDTA5MDUwMTAwMDAwMFoXDTE5MDQzMDIzNTk1OVow gd0xCzAJBgNVBAYTAlVTMRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVy aVNpZ24gVHJ1c3QgTmV0d29yazE7MDkGA1UECxMyVGVybXMgb2YgdXNlIGF0IGh0dHBzOi8v d3d3LnZlcmlzaWduLmNvbS9ycGEgKGMpMDkxHjAcBgNVBAsTFVBlcnNvbmEgTm90IFZhbGlk YXRlZDE3MDUGA1UEAxMuVmVyaVNpZ24gQ2xhc3MgMSBJbmRpdmlkdWFsIFN1YnNjcmliZXIg Q0EgLSBHMzCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAO3ER98qKB18Bmu71yEy yWwTj+mxjUFONPfaC+Nq+mWIIAsRE+mb4ElOi2/VAdBfDUeRilpMdD4/xpEJu0w0no1uoYJR YvdpdliWB6+eFBgHT1q9n9IxslQZc0ZqGUIR7BJzIY313DDN5dlWCjHFNm0pFJe9LdqJRxmI 2EsEPeu2PGcedAATDdCG2pNn+DMDrho8a2l49sAsjuGDP3f5mf/+n1JawrSHCthsqUfBVCll Qz5KwJYfwa33d69ssQRevsG2lC2XkC0n0rse6YNqhPbEsq4jBmUmpSdYKwcitG+mYkgad/LV UCeaKdOW+yj1uiR2YuOMWev7btVCxL5Bx/UCAwEAAaOCArkwggK1MDQGCCsGAQUFBwEBBCgw JjAkBggrBgEFBQcwAYYYaHR0cDovL29jc3AudmVyaXNpZ24uY29tMBIGA1UdEwEB/wQIMAYB Af8CAQAwcAYDVR0gBGkwZzBlBgtghkgBhvhFAQcXATBWMCgGCCsGAQUFBwIBFhxodHRwczov L3d3dy52ZXJpc2lnbi5jb20vY3BzMCoGCCsGAQUFBwICMB4aHGh0dHBzOi8vd3d3LnZlcmlz aWduLmNvbS9ycGEwNAYDVR0fBC0wKzApoCegJYYjaHR0cDovL2NybC52ZXJpc2lnbi5jb20v cGNhMS1nMy5jcmwwDgYDVR0PAQH/BAQDAgEGMG4GCCsGAQUFBwEMBGIwYKFeoFwwWjBYMFYW CWltYWdlL2dpZjAhMB8wBwYFKw4DAhoEFEtruSiWBgy70FI4mymsSweLIQUYMCYWJGh0dHA6 Ly9sb2dvLnZlcmlzaWduLmNvbS92c2xvZ28xLmdpZjAuBgNVHREEJzAlpCMwITEfMB0GA1UE AxMWUHJpdmF0ZUxhYmVsNC0yMDQ4LTExODAdBgNVHQ4EFgQUeUdhCEH9OASiS+e1zPVD9kkr EfgwgfEGA1UdIwSB6TCB5qGB0KSBzTCByjELMAkGA1UEBhMCVVMxFzAVBgNVBAoTDlZlcmlT aWduLCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMTowOAYDVQQLEzEo YykgMTk5OSBWZXJpU2lnbiwgSW5jLiAtIEZvciBhdXRob3JpemVkIHVzZSBvbmx5MUUwQwYD VQQDEzxWZXJpU2lnbiBDbGFzcyAxIFB1YmxpYyBQcmltYXJ5IENlcnRpZmljYXRpb24gQXV0 aG9yaXR5IC0gRzOCEQCLW3VWhFSFCwDPrzhIzrGkMA0GCSqGSIb3DQEBBQUAA4IBAQA5Tc9B mYG1qQW1UjjpOYSJbOQ0qFrn2GwJTCQaulmkhztzIfGTgc+/aGNaZ/41hSuhw12jSsI6Gd0w 1sxN7/HSgZfKVFpDvzeLeo4ZjQ9DqIzyr2CzFYqzlZw84J6zJ5ikNXIX5fwqXYfTig3C0UUq +MD0rCqTOtWuEnAI6/s74nfs6CtkNXbNutrg0csU1nFYm77VPn222egkxSRmTF2RH3azFz5/ DcYhiS+zN7ih/1yybUneZVJC+w6I0u1KHb9L4/jMcvpIDmWOScjW+JmYO7eUPjFxBof6bFlT LtffK+1fYwCsFe0DuFUWjMZoA+ciqHMLsbyg2lJY3QoOf8GCMYIE7DCCBOgCAQEwgfIwgd0x CzAJBgNVBAYTAlVTMRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNp Z24gVHJ1c3QgTmV0d29yazE7MDkGA1UECxMyVGVybXMgb2YgdXNlIGF0IGh0dHBzOi8vd3d3 LnZlcmlzaWduLmNvbS9ycGEgKGMpMDkxHjAcBgNVBAsTFVBlcnNvbmEgTm90IFZhbGlkYXRl ZDE3MDUGA1UEAxMuVmVyaVNpZ24gQ2xhc3MgMSBJbmRpdmlkdWFsIFN1YnNjcmliZXIgQ0Eg LSBHMwIQZ0vCc6DtJT/HOJ5fsVoV7DAJBgUrDgMCGgUAoIICzjAYBgkqhkiG9w0BCQMxCwYJ KoZIhvcNAQcBMBwGCSqGSIb3DQEJBTEPFw0xMTA5MDYxNzE2MzRaMCMGCSqGSIb3DQEJBDEW BBTvSi1TBSvuGngtvRAf6QSzc3wpJDBfBgkqhkiG9w0BCQ8xUjBQMAsGCWCGSAFlAwQBAjAK BggqhkiG9w0DBzAOBggqhkiG9w0DAgICAIAwDQYIKoZIhvcNAwICAUAwBwYFKw4DAgcwDQYI KoZIhvcNAwICASgwggEDBgkrBgEEAYI3EAQxgfUwgfIwgd0xCzAJBgNVBAYTAlVTMRcwFQYD VQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNpZ24gVHJ1c3QgTmV0d29yazE7 MDkGA1UECxMyVGVybXMgb2YgdXNlIGF0IGh0dHBzOi8vd3d3LnZlcmlzaWduLmNvbS9ycGEg KGMpMDkxHjAcBgNVBAsTFVBlcnNvbmEgTm90IFZhbGlkYXRlZDE3MDUGA1UEAxMuVmVyaVNp Z24gQ2xhc3MgMSBJbmRpdmlkdWFsIFN1YnNjcmliZXIgQ0EgLSBHMwIQZ0vCc6DtJT/HOJ5f sVoV7DCCAQUGCyqGSIb3DQEJEAILMYH1oIHyMIHdMQswCQYDVQQGEwJVUzEXMBUGA1UEChMO VmVyaVNpZ24sIEluYy4xHzAdBgNVBAsTFlZlcmlTaWduIFRydXN0IE5ldHdvcmsxOzA5BgNV BAsTMlRlcm1zIG9mIHVzZSBhdCBodHRwczovL3d3dy52ZXJpc2lnbi5jb20vcnBhIChjKTA5 MR4wHAYDVQQLExVQZXJzb25hIE5vdCBWYWxpZGF0ZWQxNzA1BgNVBAMTLlZlcmlTaWduIENs YXNzIDEgSW5kaXZpZHVhbCBTdWJzY3JpYmVyIENBIC0gRzMCEGdLwnOg7SU/xzieX7FaFeww DQYJKoZIhvcNAQEBBQAEggEAmiMgbD99gLEdK/+hSDI4Ylbcr28ok8CNHopIAOfToCYLFywe XIo1pgrp39o2z+A4avHUoqv8XaV3P7e4hgRo2ts9OOzeJw4DvmPtKtvZklZ+M/yashv8jPb5 NNze2jd3H+pBQEtGS0TQ4iASVwp6ilf/CEv5VZb3PunOI/H8CsoAs680+LAayLdc/unGHGQy wkvuv8Zc8In7sn1kfT8gexUZVeF0uIjH6PyXxSV151GQZh21WNUsvsSs9uB49MUCpjAFs2JT 1XvlrXBw/t3GgBoO8BJbftSarnjDipzjbHKcpfcxRQ2aaKBEDKQx2jQux+JV+EKCncflL+KQ rrvt3QAAAAAAAA== --------------ms000203010008080704050506-- --===============1239862971== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel --===============1239862971==-- From xen-devel-bounces@lists.xensource.com Tue Sep 06 10:18:37 2011 Return-path: Envelope-to: www-data@lists.xensource.com Delivery-date: Tue, 06 Sep 2011 10:18:37 -0700 Received: from localhost ([127.0.0.1] helo=lists.colo.xensource.com) by lists.xensource.com with esmtp (Exim 4.43) id 1R0zIC-0002It-SK; Tue, 06 Sep 2011 10:18:36 -0700 Received: from mail182.messagelabs.com ([85.158.139.83]) by lists.xensource.com with esmtp (Exim 4.43) id 1R0zHj-00026h-JE for xen-devel@lists.xensource.com; Tue, 06 Sep 2011 10:18:07 -0700 X-Env-Sender: dan.magenheimer@oracle.com X-Msg-Ref: server-11.tower-182.messagelabs.com!1315329482!17290112!1 X-Originating-IP: [141.146.126.227] X-StarScan-Version: 6.3.6; banners=-,-,- X-VirusChecked: Checked Received: (qmail 20080 invoked from network); 6 Sep 2011 17:18:04 -0000 Received: from acsinet15.oracle.com (HELO acsinet15.oracle.com) (141.146.126.227) by server-11.tower-182.messagelabs.com with DHE-RSA-AES256-SHA encrypted SMTP; 6 Sep 2011 17:18:04 -0000 Received: from rtcsinet22.oracle.com (rtcsinet22.oracle.com [66.248.204.30]) by acsinet15.oracle.com (Switch-3.4.4/Switch-3.4.4) with ESMTP id p86HHwwC009422 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Tue, 6 Sep 2011 17:18:00 GMT Received: from acsmt356.oracle.com (acsmt356.oracle.com [141.146.40.156]) by rtcsinet22.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id p86HHvrN005200 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 6 Sep 2011 17:17:57 GMT Received: from abhmt107.oracle.com (abhmt107.oracle.com [141.146.116.59]) by acsmt356.oracle.com (8.12.11.20060308/8.12.11) with ESMTP id p86HHpkD025011; Tue, 6 Sep 2011 12:17:51 -0500 MIME-Version: 1.0 Message-ID: <71fba00b-9a7a-4029-ac11-4d37732bb53f@default> Date: Tue, 6 Sep 2011 10:17:45 -0700 (PDT) From: Dan Magenheimer To: Joanna Rutkowska Subject: RE: [Xen-devel] dom0 is stalled until a keypress References: <20110905091937.GA1906@email> <36a5b662-4420-41aa-be01-445f83b15a7b@default 4E664BEE.9000208@invisiblethingslab.com> In-Reply-To: <4E664BEE.9000208@invisiblethingslab.com> X-Priority: 3 X-Mailer: Oracle Beehive Extensions for Outlook 2.0.1.4.1.0 (410211) [OL 12.0.6557.5001] Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable X-Source-IP: rtcsinet22.oracle.com [66.248.204.30] X-CT-RefId: str=0001.0A090208.4E6655C8.0085,ss=1,re=0.000,fgs=0 Cc: xen-devel@lists.xensource.com, Rafal Wojtczuk X-BeenThere: xen-devel@lists.xensource.com X-Mailman-Version: 2.1.5 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xensource.com Errors-To: xen-devel-bounces@lists.xensource.com > From: Joanna Rutkowska [mailto:joanna@invisiblethingslab.com] > Subject: Re: [Xen-devel] dom0 is stalled until a keypress >=20 > On 09/06/11 17:49, Dan Magenheimer wrote: > >> From: Rafal Wojtczuk [mailto:rafal@invisiblethingslab.com] > >> Sent: Monday, September 05, 2011 3:20 AM > >> To: xen-devel@lists.xensource.com > >> Subject: [Xen-devel] dom0 is stalled until a keypress > >> > >> Hello, > >> The following bizarre behaviour was observed on xen4.1+suse dom0 2.6.3= 8, on > >> an old Core Duo laptop; maybe someone can hint what is wrong. > >> Dom0 boot stalls after an init.d script prints "Starting udev". Then n= othing > >> seems to happen. I need to press any key to observe progress - I need = to do > >> it tens of times for the boot to finish. After X starts fine, then the= re is > >> no need for keypressing anymore. > >> A particularly disturbing fact is that qrexec_daemon parent, that basi= cally > >> does > >> for (;;) { sleep(1); fprintf(stderr, "."); } > >> does not print dots, until a keypress arrives. So something is very wr= ong > >> with timers. > >> Somehow similarly, pm-suspend sometimes hangs at some stage - after de= taching > >> power cord, machine enters S3 immediately. > >> This is vaguely similar to the issue described in > >> https://lkml.org/lkml/2008/9/14/122 > >> but this time, "nohz=3Doff" does not help. > >> > >> "cpufreq=3Ddom0-kernel" cures the symptoms; but it is not a sideeffect= less > >> solution. Any idea what is going on or how to debug it ? > > > > ISTR seeing this on a Core(2?)Duo laptop and I think the > > workaround was setting max_cstate=3D0 (as Xen boot parameter). > > > But what was the actual problem? Setting max_cstate is probably even > worse for power management than setting cpufreq=3Ddom-kernel, isn't it? Sorry, dunno. I recall looking into it a bit and finding that the Core processor (and possibly specifically Merom, the laptop version) had some special C-state (C3, C1E maybe?) and giving up at that point. Sorry I can't be more helpful. _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel From xen-devel-bounces@lists.xensource.com Tue Sep 06 10:19:21 2011 Return-path: Envelope-to: www-data@lists.xensource.com Delivery-date: Tue, 06 Sep 2011 10:19:21 -0700 Received: from localhost ([127.0.0.1] helo=lists.colo.xensource.com) by lists.xensource.com with esmtp (Exim 4.43) id 1R0zIv-0002gE-EG; Tue, 06 Sep 2011 10:19:21 -0700 Received: from mail21.messagelabs.com ([85.158.143.35]) by lists.xensource.com with smtp (Exim 4.43) id 1R0zHn-00026s-Jd for xen-devel@lists.xensource.com; Tue, 06 Sep 2011 10:18:12 -0700 X-Env-Sender: stefan.bader@canonical.com X-Msg-Ref: server-13.tower-21.messagelabs.com!1315329483!47897569!1 X-Originating-IP: [91.189.89.112] X-StarScan-Version: 6.3.6; banners=-,-,- X-VirusChecked: Checked Received: (qmail 13246 invoked from network); 6 Sep 2011 17:18:03 -0000 Received: from youngberry.canonical.com (HELO youngberry.canonical.com) (91.189.89.112) by server-13.tower-21.messagelabs.com with SMTP; 6 Sep 2011 17:18:03 -0000 Received: from [12.139.69.140] (helo=[192.168.1.106]) by youngberry.canonical.com with esmtpsa (TLS1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.71) (envelope-from ) id 1R0zHi-00055V-LC; Tue, 06 Sep 2011 17:18:06 +0000 Message-ID: <4E6655D0.2080606@canonical.com> Date: Tue, 06 Sep 2011 10:18:08 -0700 From: Stefan Bader User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.2.20) Gecko/20110805 Lightning/1.0b2 Thunderbird/3.1.12 MIME-Version: 1.0 To: Konrad Rzeszutek Wilk Subject: Re: [Xen-devel] [PATCH] xen: disable PV spinlocks on HVM References: <1315327307-392-1-git-send-email-stefano.stabellini@eu.citrix.com> <20110906170255.GA29839@dumpdata.com> In-Reply-To: <20110906170255.GA29839@dumpdata.com> X-Enigmail-Version: 1.1.2 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: xen-devel@lists.xensource.com, linux-kernel@vger.kernel.org, stefano.stabellini@eu.citrix.com X-BeenThere: xen-devel@lists.xensource.com X-Mailman-Version: 2.1.5 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xensource.com Errors-To: xen-devel-bounces@lists.xensource.com On 06.09.2011 10:02, Konrad Rzeszutek Wilk wrote: > On Tue, Sep 06, 2011 at 05:41:47PM +0100, stefano.stabellini@eu.citrix.com wrote: >> From: Stefano Stabellini >> >> PV spinlocks cannot possibly work with the current code because they are >> enabled after pvops patching has already been done, and because PV >> spinlocks use a different data structure than native spinlocks so we >> cannot switch between them dynamically. A spinlock that has been taken >> once by the native code (__ticket_spin_lock) cannot be taken by >> __xen_spin_lock even after it has been released. > > Let me stick it on my 3.1-rc5 bug-fix list and add stable@kernel.org to it. > > Stefan, if you have some time this week, and can test it - I can also > stick 'Tested-by' if you would like. > > Thinking to send the patches on Friday. > >> >> Reported-by: Stefan Bader >> Signed-off-by: Stefano Stabellini >> --- >> arch/x86/xen/smp.c | 1 - >> 1 files changed, 0 insertions(+), 1 deletions(-) >> >> diff --git a/arch/x86/xen/smp.c b/arch/x86/xen/smp.c >> index e79dbb9..51339b4 100644 >> --- a/arch/x86/xen/smp.c >> +++ b/arch/x86/xen/smp.c >> @@ -522,7 +522,6 @@ static void __init xen_hvm_smp_prepare_cpus(unsigned int max_cpus) >> WARN_ON(xen_smp_intr_init(0)); >> >> xen_init_lock_cpu(0); >> - xen_init_spinlocks(); >> } >> >> static int __cpuinit xen_hvm_cpu_up(unsigned int cpu) >> -- >> 1.7.2.3 >> >> >> _______________________________________________ >> Xen-devel mailing list >> Xen-devel@lists.xensource.com >> http://lists.xensource.com/xen-devel I'll try. Currently I only got a version tested that takes out the xen_init_lock_cpu calls as well. -Stefan _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel From xen-devel-bounces@lists.xensource.com Tue Sep 06 10:47:59 2011 Return-path: Envelope-to: www-data@lists.xensource.com Delivery-date: Tue, 06 Sep 2011 10:47:59 -0700 Received: from localhost ([127.0.0.1] helo=lists.colo.xensource.com) by lists.xensource.com with esmtp (Exim 4.43) id 1R0zkc-0004Ga-RD; Tue, 06 Sep 2011 10:47:58 -0700 Received: from mail216.messagelabs.com ([85.158.143.99]) by lists.xensource.com with esmtp (Exim 4.43) id 1R0zk0-00044U-Or for xen-devel@lists.xensource.com; Tue, 06 Sep 2011 10:47:21 -0700 X-Env-Sender: marmarek@mimuw.edu.pl X-Msg-Ref: server-3.tower-216.messagelabs.com!1315331237!16250149!1 X-Originating-IP: [193.0.96.6] X-StarScan-Version: 6.3.6; banners=-,-,- X-VirusChecked: Checked Received: (qmail 30425 invoked from network); 6 Sep 2011 17:47:17 -0000 Received: from mail.mimuw.edu.pl (HELO mail.mimuw.edu.pl) (193.0.96.6) by server-3.tower-216.messagelabs.com with DHE-RSA-AES256-SHA encrypted SMTP; 6 Sep 2011 17:47:17 -0000 Received: from localhost (localhost [127.0.0.1] ident=amavis) by duch.mimuw.edu.pl (Postfix) with ESMTP id C5C5E50; Tue, 6 Sep 2011 19:47:16 +0200 (CEST) X-Virus-Scanned: amavisd-new at mimuw.edu.pl Received: from duch.mimuw.edu.pl ([127.0.0.1]) by localhost (mail.mimuw.edu.pl [127.0.0.1]) (amavisd-new, port 10026) with ESMTP id Cm-AYkXJ4enQ; Tue, 6 Sep 2011 19:47:15 +0200 (CEST) Received: from [10.137.1.11] (87-206-116-192.dynamic.chello.pl [87.206.116.192]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (No client certificate requested) by duch.mimuw.edu.pl (Postfix) with ESMTPSA; Tue, 6 Sep 2011 19:47:15 +0200 (CEST) Message-ID: <4E665CA7.6060904@mimuw.edu.pl> Date: Tue, 06 Sep 2011 19:47:19 +0200 From: Marek Marczykowski User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.2.18) Gecko/20110621 Fedora/3.1.11-1.fc14 Lightning/1.0b3pre Thunderbird/3.1.11 MIME-Version: 1.0 To: Konrad Rzeszutek Wilk Subject: Re: [Xen-devel] blkfront problem in pvops kernel when barriers enabled References: <4E6357C6.6050101@mimuw.edu.pl> <20110906163213.GC5264@dumpdata.com> <20110906165522.GD28971@dumpdata.com> In-Reply-To: <20110906165522.GD28971@dumpdata.com> X-Enigmail-Version: 1.1.2 Cc: "xen-devel@lists.xensource.com" , JBeulich@novell.com X-BeenThere: xen-devel@lists.xensource.com X-Mailman-Version: 2.1.5 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1708382466==" Sender: xen-devel-bounces@lists.xensource.com Errors-To: xen-devel-bounces@lists.xensource.com This is a cryptographically signed message in MIME format. --===============1708382466== Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha1; boundary="------------ms070101010208000406000905" This is a cryptographically signed message in MIME format. --------------ms070101010208000406000905 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On 06.09.2011 18:55, Konrad Rzeszutek Wilk wrote: > On Tue, Sep 06, 2011 at 12:32:13PM -0400, Konrad Rzeszutek Wilk wrote: >> On Sun, Sep 04, 2011 at 12:49:42PM +0200, Marek Marczykowski wrote: >>> Hello, >>> >>> Pvops block frontend (tested vanilla 3.0.3, 3.1rc2, Konrad's testing >>> branch) produces a lot of I/O errors when barriers are enabled but >>> cannot be used. >>> >>> On xenlinux I've got message: >>> [ 15.036921] blkfront: xvdb: empty write barrier op failed >>> [ 15.036936] blkfront: xvdb: barriers disabled >>> >>> and after that, everything works fine. On pvops - I/O errors. >>> As backend I've used 2.6.38.3 xenlinux (based on SUSE package) and >>> 3.1rc2 with same result. >> >> Hm, and the 'feature-barrier' was enabled on in those backends? >> That is really bizzare considering that those backends don't actually >> support WRITE_BARRIER anymore. >=20 > To be exact: > http://lwn.net/Articles/399715/ so in 2.6.37-era ish the WRITE_BARRIER > functionality got ripped out. >=20 > And the LFS summit in 2010 had more details: > http://lwn.net/Articles/399148/ > "That led, eventually, to one of the clearest decisions in the first > day of the summit: barriers, as such, will be no more." >=20 > And WRITE_BARRIER !=3D WRITE_FLUSH so if the SuSE backend is using it > as so - then there is a bug in there. 2.6.38.3 OpenSUSE (stable branch) uses feature-barrier and no feature-flush-cache, so it should works... http://kernel.opensuse.org/cgit/kernel/tree/drivers/xen/blkback/xenbus.c?= h=3Dstable#n208 http://kernel.opensuse.org/cgit/kernel/tree/drivers/xen/blkback/xenbus.c?= h=3Dstable#n443 > In the 3.1-rc2 upstream kernel there should be absolutly no hint > of 'feature-barrier' in the _backend_ code (it is OK for it to be > in the frontend code). Ok, it looks like I've mixed up logs from 2.6.38.3 dom0 and 3.1-rc2 dom0. Sorry for that. > Also, one more thing - are you sure you are using the block backend? > You might be using the QEMU qdisk? Yes. --=20 Pozdrawiam / Best Regards, Marek Marczykowski | RLU #390519 marmarek at mimuw edu pl | xmpp:marmarek at staszic waw pl --------------ms070101010208000406000905 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIRqDCC BVcwggQ/oAMCAQICEGdLwnOg7SU/xzieX7FaFewwDQYJKoZIhvcNAQEFBQAwgd0xCzAJBgNV BAYTAlVTMRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNpZ24gVHJ1 c3QgTmV0d29yazE7MDkGA1UECxMyVGVybXMgb2YgdXNlIGF0IGh0dHBzOi8vd3d3LnZlcmlz aWduLmNvbS9ycGEgKGMpMDkxHjAcBgNVBAsTFVBlcnNvbmEgTm90IFZhbGlkYXRlZDE3MDUG A1UEAxMuVmVyaVNpZ24gQ2xhc3MgMSBJbmRpdmlkdWFsIFN1YnNjcmliZXIgQ0EgLSBHMzAe Fw0xMDEyMDgwMDAwMDBaFw0xMTEyMDgyMzU5NTlaMIIBGjEXMBUGA1UEChMOVmVyaVNpZ24s IEluYy4xHzAdBgNVBAsTFlZlcmlTaWduIFRydXN0IE5ldHdvcmsxRjBEBgNVBAsTPXd3dy52 ZXJpc2lnbi5jb20vcmVwb3NpdG9yeS9SUEEgSW5jb3JwLiBieSBSZWYuLExJQUIuTFREKGMp OTgxHjAcBgNVBAsTFVBlcnNvbmEgTm90IFZhbGlkYXRlZDEzMDEGA1UECxMqRGlnaXRhbCBJ RCBDbGFzcyAxIC0gTmV0c2NhcGUgRnVsbCBTZXJ2aWNlMRswGQYDVQQDFBJNQVJFSyBNYXJj enlrb3dza2kxJDAiBgkqhkiG9w0BCQEWFW1hcm1hcmVrQG1pbXV3LmVkdS5wbDCCASIwDQYJ KoZIhvcNAQEBBQADggEPADCCAQoCggEBAMGGGDj1KJXXy13nNqo0NP7EJNnzjWHih+Z88UA/ c/CZOIu3/SUnA9gly922moQ+r4AM0k6EQaVkAdldSOy1hO/fTcJQBwDemcnACWstMDMvIbWn dkxyxNgh8bQD/xKXx1SyfKTixcx0QZXosY8HnHLWeF0Te5U9J8yUPxigCFJFe6rtY2iARrWc qWXDr4DRQc5J43aohBXGRHw+OakREqLZds6HEE6+YvJH+udcfqlrfkLKHJeiyA4UPtZwBvam EGOKrm2rqyps/JeivaTs6zKh0+4eNxSKlOGTUmj4eHVb/K3gkbX6bihmWS+9nnN3I4HL+KPZ j88xQCHX07Gh4nECAwEAAaOB0jCBzzAJBgNVHRMEAjAAMEQGA1UdIAQ9MDswOQYLYIZIAYb4 RQEHFwEwKjAoBggrBgEFBQcCARYcaHR0cHM6Ly93d3cudmVyaXNpZ24uY29tL3JwYTALBgNV HQ8EBAMCBaAwHQYDVR0lBBYwFAYIKwYBBQUHAwQGCCsGAQUFBwMCMFAGA1UdHwRJMEcwRaBD oEGGP2h0dHA6Ly9pbmRjMWRpZ2l0YWxpZC1nMy1jcmwudmVyaXNpZ24uY29tL0luZEMxRGln aXRhbElELUczLmNybDANBgkqhkiG9w0BAQUFAAOCAQEAl7oehxokYa9omPurM44GROaRxtIQ acWWpCgeMNDqJXyEgm30u0hY1szXiSyVnkIx/sh4HuBqvXJnZZvLjksEIzdALTgCAskojzeT oeX+340loS87OO82/XUDT5YY3+R5G+4oQIxKVqF7kDmOuJ2opbjU4dFxHhIypiEcWjG2sjWd 127poxMQeY4lCk3qKw94pK5RpVPJK8hzaf+pWoL2D7i3L2xE+DMzZJ1OB3AxcGxhvupUq+zz 3Z9IIHo6DNOwUyCNR+ShVnuCaoJcya35mQzhs1s5+LcP/ysrUzhPo+iYNXGv+q5iNQEXZ7Dw kPgAm17fnxmih6D4KRbmrc3xpjCCBVcwggQ/oAMCAQICEGdLwnOg7SU/xzieX7FaFewwDQYJ KoZIhvcNAQEFBQAwgd0xCzAJBgNVBAYTAlVTMRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEf MB0GA1UECxMWVmVyaVNpZ24gVHJ1c3QgTmV0d29yazE7MDkGA1UECxMyVGVybXMgb2YgdXNl IGF0IGh0dHBzOi8vd3d3LnZlcmlzaWduLmNvbS9ycGEgKGMpMDkxHjAcBgNVBAsTFVBlcnNv bmEgTm90IFZhbGlkYXRlZDE3MDUGA1UEAxMuVmVyaVNpZ24gQ2xhc3MgMSBJbmRpdmlkdWFs IFN1YnNjcmliZXIgQ0EgLSBHMzAeFw0xMDEyMDgwMDAwMDBaFw0xMTEyMDgyMzU5NTlaMIIB GjEXMBUGA1UEChMOVmVyaVNpZ24sIEluYy4xHzAdBgNVBAsTFlZlcmlTaWduIFRydXN0IE5l dHdvcmsxRjBEBgNVBAsTPXd3dy52ZXJpc2lnbi5jb20vcmVwb3NpdG9yeS9SUEEgSW5jb3Jw LiBieSBSZWYuLExJQUIuTFREKGMpOTgxHjAcBgNVBAsTFVBlcnNvbmEgTm90IFZhbGlkYXRl ZDEzMDEGA1UECxMqRGlnaXRhbCBJRCBDbGFzcyAxIC0gTmV0c2NhcGUgRnVsbCBTZXJ2aWNl MRswGQYDVQQDFBJNQVJFSyBNYXJjenlrb3dza2kxJDAiBgkqhkiG9w0BCQEWFW1hcm1hcmVr QG1pbXV3LmVkdS5wbDCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAMGGGDj1KJXX y13nNqo0NP7EJNnzjWHih+Z88UA/c/CZOIu3/SUnA9gly922moQ+r4AM0k6EQaVkAdldSOy1 hO/fTcJQBwDemcnACWstMDMvIbWndkxyxNgh8bQD/xKXx1SyfKTixcx0QZXosY8HnHLWeF0T e5U9J8yUPxigCFJFe6rtY2iARrWcqWXDr4DRQc5J43aohBXGRHw+OakREqLZds6HEE6+YvJH +udcfqlrfkLKHJeiyA4UPtZwBvamEGOKrm2rqyps/JeivaTs6zKh0+4eNxSKlOGTUmj4eHVb /K3gkbX6bihmWS+9nnN3I4HL+KPZj88xQCHX07Gh4nECAwEAAaOB0jCBzzAJBgNVHRMEAjAA MEQGA1UdIAQ9MDswOQYLYIZIAYb4RQEHFwEwKjAoBggrBgEFBQcCARYcaHR0cHM6Ly93d3cu dmVyaXNpZ24uY29tL3JwYTALBgNVHQ8EBAMCBaAwHQYDVR0lBBYwFAYIKwYBBQUHAwQGCCsG AQUFBwMCMFAGA1UdHwRJMEcwRaBDoEGGP2h0dHA6Ly9pbmRjMWRpZ2l0YWxpZC1nMy1jcmwu dmVyaXNpZ24uY29tL0luZEMxRGlnaXRhbElELUczLmNybDANBgkqhkiG9w0BAQUFAAOCAQEA l7oehxokYa9omPurM44GROaRxtIQacWWpCgeMNDqJXyEgm30u0hY1szXiSyVnkIx/sh4HuBq vXJnZZvLjksEIzdALTgCAskojzeToeX+340loS87OO82/XUDT5YY3+R5G+4oQIxKVqF7kDmO uJ2opbjU4dFxHhIypiEcWjG2sjWd127poxMQeY4lCk3qKw94pK5RpVPJK8hzaf+pWoL2D7i3 L2xE+DMzZJ1OB3AxcGxhvupUq+zz3Z9IIHo6DNOwUyCNR+ShVnuCaoJcya35mQzhs1s5+LcP /ysrUzhPo+iYNXGv+q5iNQEXZ7DwkPgAm17fnxmih6D4KRbmrc3xpjCCBu4wggXWoAMCAQIC EHEVZgVK5JEhTem8RPms09wwDQYJKoZIhvcNAQEFBQAwgcoxCzAJBgNVBAYTAlVTMRcwFQYD VQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNpZ24gVHJ1c3QgTmV0d29yazE6 MDgGA1UECxMxKGMpIDE5OTkgVmVyaVNpZ24sIEluYy4gLSBGb3IgYXV0aG9yaXplZCB1c2Ug b25seTFFMEMGA1UEAxM8VmVyaVNpZ24gQ2xhc3MgMSBQdWJsaWMgUHJpbWFyeSBDZXJ0aWZp Y2F0aW9uIEF1dGhvcml0eSAtIEczMB4XDTA5MDUwMTAwMDAwMFoXDTE5MDQzMDIzNTk1OVow gd0xCzAJBgNVBAYTAlVTMRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVy aVNpZ24gVHJ1c3QgTmV0d29yazE7MDkGA1UECxMyVGVybXMgb2YgdXNlIGF0IGh0dHBzOi8v d3d3LnZlcmlzaWduLmNvbS9ycGEgKGMpMDkxHjAcBgNVBAsTFVBlcnNvbmEgTm90IFZhbGlk YXRlZDE3MDUGA1UEAxMuVmVyaVNpZ24gQ2xhc3MgMSBJbmRpdmlkdWFsIFN1YnNjcmliZXIg Q0EgLSBHMzCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAO3ER98qKB18Bmu71yEy yWwTj+mxjUFONPfaC+Nq+mWIIAsRE+mb4ElOi2/VAdBfDUeRilpMdD4/xpEJu0w0no1uoYJR YvdpdliWB6+eFBgHT1q9n9IxslQZc0ZqGUIR7BJzIY313DDN5dlWCjHFNm0pFJe9LdqJRxmI 2EsEPeu2PGcedAATDdCG2pNn+DMDrho8a2l49sAsjuGDP3f5mf/+n1JawrSHCthsqUfBVCll Qz5KwJYfwa33d69ssQRevsG2lC2XkC0n0rse6YNqhPbEsq4jBmUmpSdYKwcitG+mYkgad/LV UCeaKdOW+yj1uiR2YuOMWev7btVCxL5Bx/UCAwEAAaOCArkwggK1MDQGCCsGAQUFBwEBBCgw JjAkBggrBgEFBQcwAYYYaHR0cDovL29jc3AudmVyaXNpZ24uY29tMBIGA1UdEwEB/wQIMAYB Af8CAQAwcAYDVR0gBGkwZzBlBgtghkgBhvhFAQcXATBWMCgGCCsGAQUFBwIBFhxodHRwczov L3d3dy52ZXJpc2lnbi5jb20vY3BzMCoGCCsGAQUFBwICMB4aHGh0dHBzOi8vd3d3LnZlcmlz aWduLmNvbS9ycGEwNAYDVR0fBC0wKzApoCegJYYjaHR0cDovL2NybC52ZXJpc2lnbi5jb20v cGNhMS1nMy5jcmwwDgYDVR0PAQH/BAQDAgEGMG4GCCsGAQUFBwEMBGIwYKFeoFwwWjBYMFYW CWltYWdlL2dpZjAhMB8wBwYFKw4DAhoEFEtruSiWBgy70FI4mymsSweLIQUYMCYWJGh0dHA6 Ly9sb2dvLnZlcmlzaWduLmNvbS92c2xvZ28xLmdpZjAuBgNVHREEJzAlpCMwITEfMB0GA1UE AxMWUHJpdmF0ZUxhYmVsNC0yMDQ4LTExODAdBgNVHQ4EFgQUeUdhCEH9OASiS+e1zPVD9kkr EfgwgfEGA1UdIwSB6TCB5qGB0KSBzTCByjELMAkGA1UEBhMCVVMxFzAVBgNVBAoTDlZlcmlT aWduLCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMTowOAYDVQQLEzEo YykgMTk5OSBWZXJpU2lnbiwgSW5jLiAtIEZvciBhdXRob3JpemVkIHVzZSBvbmx5MUUwQwYD VQQDEzxWZXJpU2lnbiBDbGFzcyAxIFB1YmxpYyBQcmltYXJ5IENlcnRpZmljYXRpb24gQXV0 aG9yaXR5IC0gRzOCEQCLW3VWhFSFCwDPrzhIzrGkMA0GCSqGSIb3DQEBBQUAA4IBAQA5Tc9B mYG1qQW1UjjpOYSJbOQ0qFrn2GwJTCQaulmkhztzIfGTgc+/aGNaZ/41hSuhw12jSsI6Gd0w 1sxN7/HSgZfKVFpDvzeLeo4ZjQ9DqIzyr2CzFYqzlZw84J6zJ5ikNXIX5fwqXYfTig3C0UUq +MD0rCqTOtWuEnAI6/s74nfs6CtkNXbNutrg0csU1nFYm77VPn222egkxSRmTF2RH3azFz5/ DcYhiS+zN7ih/1yybUneZVJC+w6I0u1KHb9L4/jMcvpIDmWOScjW+JmYO7eUPjFxBof6bFlT LtffK+1fYwCsFe0DuFUWjMZoA+ciqHMLsbyg2lJY3QoOf8GCMYIE7DCCBOgCAQEwgfIwgd0x CzAJBgNVBAYTAlVTMRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNp Z24gVHJ1c3QgTmV0d29yazE7MDkGA1UECxMyVGVybXMgb2YgdXNlIGF0IGh0dHBzOi8vd3d3 LnZlcmlzaWduLmNvbS9ycGEgKGMpMDkxHjAcBgNVBAsTFVBlcnNvbmEgTm90IFZhbGlkYXRl ZDE3MDUGA1UEAxMuVmVyaVNpZ24gQ2xhc3MgMSBJbmRpdmlkdWFsIFN1YnNjcmliZXIgQ0Eg LSBHMwIQZ0vCc6DtJT/HOJ5fsVoV7DAJBgUrDgMCGgUAoIICzjAYBgkqhkiG9w0BCQMxCwYJ KoZIhvcNAQcBMBwGCSqGSIb3DQEJBTEPFw0xMTA5MDYxNzQ3MTlaMCMGCSqGSIb3DQEJBDEW BBTuxPDKJtOTlTPs8xm0NojtoPNREzBfBgkqhkiG9w0BCQ8xUjBQMAsGCWCGSAFlAwQBAjAK BggqhkiG9w0DBzAOBggqhkiG9w0DAgICAIAwDQYIKoZIhvcNAwICAUAwBwYFKw4DAgcwDQYI KoZIhvcNAwICASgwggEDBgkrBgEEAYI3EAQxgfUwgfIwgd0xCzAJBgNVBAYTAlVTMRcwFQYD VQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNpZ24gVHJ1c3QgTmV0d29yazE7 MDkGA1UECxMyVGVybXMgb2YgdXNlIGF0IGh0dHBzOi8vd3d3LnZlcmlzaWduLmNvbS9ycGEg KGMpMDkxHjAcBgNVBAsTFVBlcnNvbmEgTm90IFZhbGlkYXRlZDE3MDUGA1UEAxMuVmVyaVNp Z24gQ2xhc3MgMSBJbmRpdmlkdWFsIFN1YnNjcmliZXIgQ0EgLSBHMwIQZ0vCc6DtJT/HOJ5f sVoV7DCCAQUGCyqGSIb3DQEJEAILMYH1oIHyMIHdMQswCQYDVQQGEwJVUzEXMBUGA1UEChMO VmVyaVNpZ24sIEluYy4xHzAdBgNVBAsTFlZlcmlTaWduIFRydXN0IE5ldHdvcmsxOzA5BgNV BAsTMlRlcm1zIG9mIHVzZSBhdCBodHRwczovL3d3dy52ZXJpc2lnbi5jb20vcnBhIChjKTA5 MR4wHAYDVQQLExVQZXJzb25hIE5vdCBWYWxpZGF0ZWQxNzA1BgNVBAMTLlZlcmlTaWduIENs YXNzIDEgSW5kaXZpZHVhbCBTdWJzY3JpYmVyIENBIC0gRzMCEGdLwnOg7SU/xzieX7FaFeww DQYJKoZIhvcNAQEBBQAEggEAokLN+6hQB6MaNCxLhOZ0HSz4iPbvKfC+0AMmz91S4hcR8OPn K2BGu7YDgivTsplwj1Q3Gwf7z0r1Yt+oF6lNDV82ecyB6vEASBMk70nkiUE/RlN1rU8dI0/6 gg9Y+lR58eTtU1VXwoC25FDA6MxOIsXG6nShtiNifZhfUdL41NfVA0tf8QTyf6PXVNgxPFzO uaA40hXRjaldZj3r7fiiudezzGgkpjvHMVcA6mSzZbGvqtb91FLyekVTX/q7NaxDnqbLI0e3 aMwRXMwmyr/BEnaw3aoBYpZsOEQF3s8jjXw4GI8hNIIabL4Iqfv0UL6UxsLR2Ezc96PpZ+g5 6f3pcgAAAAAAAA== --------------ms070101010208000406000905-- --===============1708382466== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel --===============1708382466==-- From xen-devel-bounces@lists.xensource.com Tue Sep 06 11:09:26 2011 Return-path: Envelope-to: www-data@lists.xensource.com Delivery-date: Tue, 06 Sep 2011 11:09:26 -0700 Received: from localhost ([127.0.0.1] helo=lists.colo.xensource.com) by lists.xensource.com with esmtp (Exim 4.43) id 1R105O-0004yY-9t; Tue, 06 Sep 2011 11:09:26 -0700 Received: from mail21.messagelabs.com ([85.158.143.35]) by lists.xensource.com with esmtp (Exim 4.43) id 1R103c-0004kn-5d for xen-devel@lists.xensource.com; Tue, 06 Sep 2011 11:08:05 -0700 X-Env-Sender: jeremy@goop.org X-Msg-Ref: server-9.tower-21.messagelabs.com!1315332409!47395836!1 X-Originating-IP: [74.207.240.146] X-StarScan-Version: 6.3.6; banners=-,-,- X-VirusChecked: Checked Received: (qmail 29150 invoked from network); 6 Sep 2011 18:06:50 -0000 Received: from claw.goop.org (HELO claw.goop.org) (74.207.240.146) by server-9.tower-21.messagelabs.com with DHE-RSA-AES256-SHA encrypted SMTP; 6 Sep 2011 18:06:50 -0000 Received: from saboo.goop.org (unknown [IPv6:2001:470:1f05:899:585a:baff:fee6:65b4]) (Authenticated sender: smtp-saboo) by claw.goop.org (Postfix) with ESMTPSA id 5741D8A6A; Tue, 6 Sep 2011 11:07:30 -0700 (PDT) Received: from saboo.goop.org (localhost [IPv6:::1]) by saboo.goop.org (Postfix) with ESMTP id B046A201D1; Tue, 6 Sep 2011 11:07:26 -0700 (PDT) Message-ID: <4E66615E.8070806@goop.org> Date: Tue, 06 Sep 2011 11:07:26 -0700 From: Jeremy Fitzhardinge User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:6.0) Gecko/20110816 Thunderbird/6.0 MIME-Version: 1.0 To: Don Zickus References: <38bb37e15f6e5056d5238adac945bc1837a996ec.1314922370.git.jeremy.fitzhardinge@citrix.com> <1314974826.1861.1.camel@twins> <4E612EA1.20007@goop.org> <1314996468.8255.0.camel@twins> <4E614FBD.2030509@goop.org> <20110906151408.GA7459@redhat.com> In-Reply-To: <20110906151408.GA7459@redhat.com> X-Enigmail-Version: 1.3.1 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: Marcelo Tosatti , Nick Piggin , KVM , Stefano Stabellini , Peter Zijlstra , the arch/x86 maintainers , Linux Kernel Mailing List , Andi Kleen , Avi Kivity , Jeremy Fitzhardinge , "H. Peter Anvin" , Ingo Molnar , Linus Torvalds , Xen Devel Subject: [Xen-devel] Re: [PATCH 08/13] xen/pvticketlock: disable interrupts while blocking X-BeenThere: xen-devel@lists.xensource.com X-Mailman-Version: 2.1.5 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xensource.com Errors-To: xen-devel-bounces@lists.xensource.com On 09/06/2011 08:14 AM, Don Zickus wrote: > On Fri, Sep 02, 2011 at 02:50:53PM -0700, Jeremy Fitzhardinge wrote: >> On 09/02/2011 01:47 PM, Peter Zijlstra wrote: >>> On Fri, 2011-09-02 at 12:29 -0700, Jeremy Fitzhardinge wrote: >>>>> I know that its generally considered bad form, but there's at least one >>>>> spinlock that's only taken from NMI context and thus hasn't got any >>>>> deadlock potential. >>>> Which one? >>> arch/x86/kernel/traps.c:nmi_reason_lock >>> >>> It serializes NMI access to the NMI reason port across CPUs. >> Ah, OK. Well, that will never happen in a PV Xen guest. But PV >> ticketlocks are equally applicable to an HVM Xen domain (and KVM guest), >> so I guess there's at least some chance there could be a virtual >> emulated NMI. Maybe? Does qemu do that kind of thing? >> >> But, erm, does that even make sense? I'm assuming the NMI reason port >> tells the CPU why it got an NMI. If multiple CPUs can get NMIs and >> there's only a single reason port, then doesn't that mean that either 1) >> they all got the NMI for the same reason, or 2) having a single port is >> inherently racy? How does the locking actually work there? > The reason port is for an external/system NMI. All the IPI-NMI don't need > to access this register to process their handlers, ie perf. I think in > general the IOAPIC is configured to deliver the external NMI to one cpu, > usually the bsp cpu. However, there has been a slow movement to free the > bsp cpu from exceptions like this to allow one to eventually hot-swap the > bsp cpu. The spin locks in that code were an attempt to be more abstract > about who really gets the external NMI. Of course SGI's box is setup to > deliver an external NMI to all cpus to dump the stack when the system > isn't behaving. > > This is a very low usage NMI (in fact almost all cases lead to loud > console messages). > > Hope that clears up some of the confusion. Hm, not really. What does it mean if two CPUs go down that path? Should one do some NMI processing while the other waits around for it to finish, and then do some NMI processing on its own? It sounds like that could only happen if you reroute NMI from one CPU to another while the first CPU is actually in the middle of processing an NMI - in which case, shouldn't the code doing the re-routing be taking the spinlock? Or perhaps a spinlock isn't the right primitive to use at all? Couldn't the second CPU just set a flag/counter (using something like an atomic add/cmpxchg/etc) to make the first CPU process the second NMI? But on the other hand, I don't really care if you can say that this path will never be called in a virtual machine. J _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel From xen-devel-bounces@lists.xensource.com Tue Sep 06 11:51:40 2011 Return-path: Envelope-to: www-data@lists.xensource.com Delivery-date: Tue, 06 Sep 2011 11:51:40 -0700 Received: from localhost ([127.0.0.1] helo=lists.colo.xensource.com) by lists.xensource.com with esmtp (Exim 4.43) id 1R10kF-00066J-8A; Tue, 06 Sep 2011 11:51:39 -0700 Received: from mail21.messagelabs.com ([85.158.143.35]) by lists.xensource.com with esmtp (Exim 4.43) id 1R10jj-0005uN-PF for xen-devel@lists.xensource.com; Tue, 06 Sep 2011 11:51:08 -0700 X-Env-Sender: jeremy@goop.org X-Msg-Ref: server-6.tower-21.messagelabs.com!1315335044!37230009!1 X-Originating-IP: [74.207.240.146] X-StarScan-Version: 6.3.6; banners=-,-,- X-VirusChecked: Checked Received: (qmail 14114 invoked from network); 6 Sep 2011 18:50:45 -0000 Received: from claw.goop.org (HELO claw.goop.org) (74.207.240.146) by server-6.tower-21.messagelabs.com with DHE-RSA-AES256-SHA encrypted SMTP; 6 Sep 2011 18:50:45 -0000 Received: from saboo.goop.org (unknown [IPv6:2001:470:1f05:899:585a:baff:fee6:65b4]) (Authenticated sender: smtp-saboo) by claw.goop.org (Postfix) with ESMTPSA id 4C1368F1E; Tue, 6 Sep 2011 11:51:02 -0700 (PDT) Received: from saboo.goop.org (localhost [IPv6:::1]) by saboo.goop.org (Postfix) with ESMTP id 9F3362040C; Tue, 6 Sep 2011 11:50:58 -0700 (PDT) Message-ID: <4E666B92.9010300@goop.org> Date: Tue, 06 Sep 2011 11:50:58 -0700 From: Jeremy Fitzhardinge User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:6.0) Gecko/20110816 Thunderbird/6.0 MIME-Version: 1.0 To: Don Zickus References: <38bb37e15f6e5056d5238adac945bc1837a996ec.1314922370.git.jeremy.fitzhardinge@citrix.com> <1314974826.1861.1.camel@twins> <4E612EA1.20007@goop.org> <1314996468.8255.0.camel@twins> <4E614FBD.2030509@goop.org> <20110906151408.GA7459@redhat.com> <4E66615E.8070806@goop.org> <20110906182758.GR5795@redhat.com> In-Reply-To: <20110906182758.GR5795@redhat.com> X-Enigmail-Version: 1.3.1 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: Marcelo Tosatti , Nick Piggin , KVM , Stefano Stabellini , Peter Zijlstra , the arch/x86 maintainers , Linux Kernel Mailing List , Andi Kleen , Avi Kivity , Jeremy Fitzhardinge , "H. Peter Anvin" , Ingo Molnar , Linus Torvalds , Xen Devel Subject: [Xen-devel] Re: [PATCH 08/13] xen/pvticketlock: disable interrupts while blocking X-BeenThere: xen-devel@lists.xensource.com X-Mailman-Version: 2.1.5 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xensource.com Errors-To: xen-devel-bounces@lists.xensource.com On 09/06/2011 11:27 AM, Don Zickus wrote: >> But on the other hand, I don't really care if you can say that this path >> will never be called in a virtual machine. > Does virtual machines support hot remove of cpus? Probably not > considering bare-metal barely supports it. The only reason you'd want to is to add/remove VCPUs as a mechanism of resource control, so if you were removing a VCPU it wouldn't matter much which one you choose. In other words, there's no reason you'd ever need to remove the BSP in favour of one of the other CPUs. Anyway, I'm not going to lose any sleep over this issue. J _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel From xen-devel-bounces@lists.xensource.com Tue Sep 06 11:55:41 2011 Return-path: Envelope-to: www-data@lists.xensource.com Delivery-date: Tue, 06 Sep 2011 11:55:41 -0700 Received: from localhost ([127.0.0.1] helo=lists.colo.xensource.com) by lists.xensource.com with esmtp (Exim 4.43) id 1R10o9-0006Vx-Dk; Tue, 06 Sep 2011 11:55:41 -0700 Received: from mail174.messagelabs.com ([85.158.138.51]) by lists.xensource.com with esmtp (Exim 4.43) id 1R10nf-0006Ju-Cb for xen-devel@lists.xensource.com; Tue, 06 Sep 2011 11:55:11 -0700 X-Env-Sender: jeremy@goop.org X-Msg-Ref: server-5.tower-174.messagelabs.com!1315335306!26765366!1 X-Originating-IP: [74.207.240.146] X-StarScan-Version: 6.3.6; banners=-,-,- X-VirusChecked: Checked Received: (qmail 5688 invoked from network); 6 Sep 2011 18:55:08 -0000 Received: from claw.goop.org (HELO claw.goop.org) (74.207.240.146) by server-5.tower-174.messagelabs.com with DHE-RSA-AES256-SHA encrypted SMTP; 6 Sep 2011 18:55:08 -0000 Received: from saboo.goop.org (unknown [IPv6:2001:470:1f05:899:585a:baff:fee6:65b4]) (Authenticated sender: smtp-saboo) by claw.goop.org (Postfix) with ESMTPSA id F34318F26; Tue, 6 Sep 2011 11:55:05 -0700 (PDT) Received: from saboo.goop.org (localhost [IPv6:::1]) by saboo.goop.org (Postfix) with ESMTP id 81576201D1; Tue, 6 Sep 2011 11:55:02 -0700 (PDT) Message-ID: <4E666C86.5090707@goop.org> Date: Tue, 06 Sep 2011 11:55:02 -0700 From: Jeremy Fitzhardinge User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:6.0) Gecko/20110816 Thunderbird/6.0 MIME-Version: 1.0 To: MaoXiaoyun Subject: Re: [Xen-devel] RE: ext4 BUG in dom0 Kernel 2.6.32.36 References: , <20110906145347.GA4133@dumpdata.com> In-Reply-To: X-Enigmail-Version: 1.3.1 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Cc: linux-ext4@vger.kernel.org, xen devel , konrad.wilk@oracle.com X-BeenThere: xen-devel@lists.xensource.com X-Mailman-Version: 2.1.5 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xensource.com Errors-To: xen-devel-bounces@lists.xensource.com On 09/06/2011 08:11 AM, MaoXiaoyun wrote: > > > Date: Tue, 6 Sep 2011 10:53:47 -0400 > > From: konrad.wilk@oracle.com > > To: tinnycloud@hotmail.com > > CC: linux-ext4@vger.kernel.org; xen-devel@lists.xensource.com; > jeremy@goop.org > > Subject: Re: ext4 BUG in dom0 Kernel 2.6.32.36 > > > > On Tue, Sep 06, 2011 at 03:24:14PM +0800, MaoXiaoyun wrote: > > > > > > > > > Hi: > > > > > > I've met an ext4 Bug in dom0 kernel 2.6.32.36. (See kernel stack > below) > > > > Did you try the 3.0 kernel? > No, I am afried the change would be to much for our current env. > May result in other stable issue. > So, I want to dig out what really happen. Hopes. Another question is whether this is a regression compared to earlier versions of 2.6.32? Do you know if this problem exists in a non-Xen environment? Thanks, J _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel From xen-devel-bounces@lists.xensource.com Tue Sep 06 12:05:33 2011 Return-path: Envelope-to: www-data@lists.xensource.com Delivery-date: Tue, 06 Sep 2011 12:05:34 -0700 Received: from localhost ([127.0.0.1] helo=lists.colo.xensource.com) by lists.xensource.com with esmtp (Exim 4.43) id 1R10xg-0007M2-5U; Tue, 06 Sep 2011 12:05:32 -0700 Received: from mail27.messagelabs.com ([193.109.254.147]) by lists.xensource.com with esmtp (Exim 4.43) id 1R10wT-00070n-UU for xen-devel@lists.xensource.com; Tue, 06 Sep 2011 12:04:19 -0700 X-Env-Sender: jeremy@goop.org X-Msg-Ref: server-4.tower-27.messagelabs.com!1315335837!39149278!1 X-Originating-IP: [74.207.240.146] X-StarScan-Version: 6.3.6; banners=-,-,- X-VirusChecked: Checked Received: (qmail 6871 invoked from network); 6 Sep 2011 19:03:58 -0000 Received: from claw.goop.org (HELO claw.goop.org) (74.207.240.146) by server-4.tower-27.messagelabs.com with DHE-RSA-AES256-SHA encrypted SMTP; 6 Sep 2011 19:03:58 -0000 Received: from saboo.goop.org (unknown [IPv6:2001:470:1f05:899:585a:baff:fee6:65b4]) (Authenticated sender: smtp-saboo) by claw.goop.org (Postfix) with ESMTPSA id 879318F6B; Tue, 6 Sep 2011 12:04:12 -0700 (PDT) Received: from saboo.goop.org (localhost [IPv6:::1]) by saboo.goop.org (Postfix) with ESMTP id 0B5EA2024D; Tue, 6 Sep 2011 12:04:09 -0700 (PDT) Message-ID: <4E666EA9.7060302@goop.org> Date: Tue, 06 Sep 2011 12:04:09 -0700 From: Jeremy Fitzhardinge User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:6.0) Gecko/20110816 Thunderbird/6.0 MIME-Version: 1.0 To: Rafal Wojtczuk Subject: Re: [Xen-devel] dom0 is stalled until a keypress References: <20110905091937.GA1906@email> In-Reply-To: <20110905091937.GA1906@email> X-Enigmail-Version: 1.3.1 Content-Type: text/plain; charset=ISO-8859-2 Content-Transfer-Encoding: 7bit Cc: xen-devel@lists.xensource.com X-BeenThere: xen-devel@lists.xensource.com X-Mailman-Version: 2.1.5 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xensource.com Errors-To: xen-devel-bounces@lists.xensource.com On 09/05/2011 02:19 AM, Rafal Wojtczuk wrote: > Hello, > The following bizarre behaviour was observed on xen4.1+suse dom0 2.6.38, on > an old Core Duo laptop; maybe someone can hint what is wrong. > Dom0 boot stalls after an init.d script prints "Starting udev". Then nothing > seems to happen. I need to press any key to observe progress - I need to do > it tens of times for the boot to finish. After X starts fine, then there is > no need for keypressing anymore. > A particularly disturbing fact is that qrexec_daemon parent, that basically > does > for (;;) { sleep(1); fprintf(stderr, "."); } > does not print dots, until a keypress arrives. So something is very wrong > with timers. > Somehow similarly, pm-suspend sometimes hangs at some stage - after detaching > power cord, machine enters S3 immediately. > This is vaguely similar to the issue described in > https://lkml.org/lkml/2008/9/14/122 > but this time, "nohz=off" does not help. > > "cpufreq=dom0-kernel" cures the symptoms; but it is not a sideeffectless > solution. Any idea what is going on or how to debug it ? Try booting with "idle=halt". J _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel From xen-devel-bounces@lists.xensource.com Tue Sep 06 12:34:05 2011 Return-path: Envelope-to: www-data@lists.xensource.com Delivery-date: Tue, 06 Sep 2011 12:34:05 -0700 Received: from localhost ([127.0.0.1] helo=lists.colo.xensource.com) by lists.xensource.com with esmtp (Exim 4.43) id 1R11PI-0000XK-D9; Tue, 06 Sep 2011 12:34:04 -0700 Received: from mail27.messagelabs.com ([193.109.254.147]) by lists.xensource.com with smtp (Exim 4.43) id 1R11Kf-0007u9-JN for xen-devel@lists.xensource.com; Tue, 06 Sep 2011 12:29:18 -0700 X-Env-Sender: Ian.Jackson@eu.citrix.com X-Msg-Ref: server-10.tower-27.messagelabs.com!1315337336!34637825!1 X-Originating-IP: [62.200.22.115] X-StarScan-Version: 6.3.6; banners=-,-,- X-VirusChecked: Checked Received: (qmail 23948 invoked from network); 6 Sep 2011 19:28:56 -0000 Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115) by server-10.tower-27.messagelabs.com with SMTP; 6 Sep 2011 19:28:56 -0000 X-IronPort-AV: E=Sophos;i="4.68,340,1312156800"; d="scan'208";a="7634828" Received: from lonpmailmx01.citrite.net ([10.30.203.162]) by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5; 06 Sep 2011 19:29:13 +0000 Received: from woking.xci-test.com (10.80.248.135) by smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id 8.3.137.0; Tue, 6 Sep 2011 20:29:13 +0100 Received: from osstest by woking.xci-test.com with local (Exim 4.69) (envelope-from ) id 1R11Kb-0002Jt-56; Tue, 06 Sep 2011 20:29:13 +0100 To: xen-devel@lists.xensource.com Message-ID: From: xen.org Date: Tue, 6 Sep 2011 20:29:13 +0100 MIME-Version: 1.0 Content-Type: text/plain Cc: ian.jackson@eu.citrix.com Subject: [Xen-devel] [xen-unstable test] 8832: tolerable FAIL - PUSHED X-BeenThere: xen-devel@lists.xensource.com X-Mailman-Version: 2.1.5 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xensource.com Errors-To: xen-devel-bounces@lists.xensource.com flight 8832 xen-unstable real [real] http://www.chiark.greenend.org.uk/~xensrcts/logs/8832/ Failures :-/ but no regressions. Tests which did not succeed, but are not blocking, including regressions (tests previously passed) regarded as allowable: test-amd64-amd64-xl-pcipt-intel 9 guest-start fail never pass test-amd64-i386-rhel6hvm-intel 9 guest-start.2 fail never pass test-amd64-i386-win-vcpus1 16 leak-check/check fail never pass test-amd64-i386-xl-win-vcpus1 13 guest-stop fail never pass test-amd64-i386-rhel6hvm-amd 9 guest-start.2 fail never pass test-amd64-amd64-win 16 leak-check/check fail never pass test-amd64-i386-win 16 leak-check/check fail never pass test-amd64-amd64-xl-win 13 guest-stop fail never pass test-i386-i386-xl-win 13 guest-stop fail never pass test-i386-i386-win 16 leak-check/check fail never pass version targeted for testing: xen 5fe770c8a8a3 baseline version: xen 0268e7380953 ------------------------------------------------------------ People who touched revisions under test: Ian Jackson Keir Fraser Olaf Hering ------------------------------------------------------------ jobs: build-amd64 pass build-i386 pass build-amd64-oldkern pass build-i386-oldkern pass build-amd64-pvops pass build-i386-pvops pass test-amd64-amd64-xl pass test-amd64-i386-xl pass test-i386-i386-xl pass test-amd64-i386-rhel6hvm-amd fail test-amd64-i386-xl-credit2 pass test-amd64-amd64-xl-pcipt-intel fail test-amd64-i386-rhel6hvm-intel fail test-amd64-i386-xl-multivcpu pass test-amd64-amd64-pair pass test-amd64-i386-pair pass test-i386-i386-pair pass test-amd64-amd64-pv pass test-amd64-i386-pv pass test-i386-i386-pv pass test-amd64-amd64-xl-sedf pass test-amd64-i386-win-vcpus1 fail test-amd64-i386-xl-win-vcpus1 fail test-amd64-amd64-win fail test-amd64-i386-win fail test-i386-i386-win fail test-amd64-amd64-xl-win fail test-i386-i386-xl-win fail ------------------------------------------------------------ sg-report-flight on woking.cam.xci-test.com logs: /home/xc_osstest/logs images: /home/xc_osstest/images Logs, config files, etc. are available at http://www.chiark.greenend.org.uk/~xensrcts/logs Test harness code can be found at http://xenbits.xensource.com/gitweb?p=osstest.git;a=summary Pushing revision : + branch=xen-unstable + revision=5fe770c8a8a3 + . cri-lock-repos ++ . cri-common +++ umask 002 +++ getconfig Repos +++ perl -e ' use Osstest; readconfigonly(); print $c{Repos} or die $!; ' ++ repos=/export/home/osstest/repos ++ repos_lock=/export/home/osstest/repos/lock ++ '[' x '!=' x/export/home/osstest/repos/lock ']' ++ OSSTEST_REPOS_LOCK_LOCKED=/export/home/osstest/repos/lock ++ exec with-lock-ex -w /export/home/osstest/repos/lock ./ap-push xen-unstable 5fe770c8a8a3 + branch=xen-unstable + revision=5fe770c8a8a3 + . cri-lock-repos ++ . cri-common +++ umask 002 +++ getconfig Repos +++ perl -e ' use Osstest; readconfigonly(); print $c{Repos} or die $!; ' ++ repos=/export/home/osstest/repos ++ repos_lock=/export/home/osstest/repos/lock ++ '[' x/export/home/osstest/repos/lock '!=' x/export/home/osstest/repos/lock ']' + : xen@xenbits.xensource.com + : xen@xenbits.xensource.com:git/linux-pvops + : master + : tested/2.6.39.x + case "$branch" in + cd /export/home/osstest/repos/xen-unstable.hg + hg push -r 5fe770c8a8a3 ssh://xen@xenbits.xensource.com/HG/xen-unstable.hg pushing to ssh://xen@xenbits.xensource.com/HG/xen-unstable.hg searching for changes remote: adding changesets remote: adding manifests remote: adding file changes remote: added 1 changesets with 1 changes to 1 files _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel From xen-devel-bounces@lists.xensource.com Tue Sep 06 12:35:37 2011 Return-path: Envelope-to: www-data@lists.xensource.com Delivery-date: Tue, 06 Sep 2011 12:35:37 -0700 Received: from localhost ([127.0.0.1] helo=lists.colo.xensource.com) by lists.xensource.com with esmtp (Exim 4.43) id 1R11Qn-0000xs-M3; Tue, 06 Sep 2011 12:35:37 -0700 Received: from mail216.messagelabs.com ([85.158.143.99]) by lists.xensource.com with esmtp (Exim 4.43) id 1R11Oq-0000MG-MD for xen-devel@lists.xensource.com; Tue, 06 Sep 2011 12:33:37 -0700 X-Env-Sender: jeremy@goop.org X-Msg-Ref: server-4.tower-216.messagelabs.com!1315337611!17276643!1 X-Originating-IP: [74.207.240.146] X-StarScan-Version: 6.3.6; banners=-,-,- X-VirusChecked: Checked Received: (qmail 15374 invoked from network); 6 Sep 2011 19:33:33 -0000 Received: from claw.goop.org (HELO claw.goop.org) (74.207.240.146) by server-4.tower-216.messagelabs.com with DHE-RSA-AES256-SHA encrypted SMTP; 6 Sep 2011 19:33:33 -0000 Received: from saboo.goop.org (unknown [IPv6:2001:470:1f05:899:585a:baff:fee6:65b4]) (Authenticated sender: smtp-saboo) by claw.goop.org (Postfix) with ESMTPSA id 2B3A58F6B; Tue, 6 Sep 2011 12:33:31 -0700 (PDT) Received: from saboo.goop.org (localhost [IPv6:::1]) by saboo.goop.org (Postfix) with ESMTP id D60E320498; Tue, 6 Sep 2011 12:33:27 -0700 (PDT) Message-ID: <4E667587.8010100@goop.org> Date: Tue, 06 Sep 2011 12:33:27 -0700 From: Jeremy Fitzhardinge User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:6.0) Gecko/20110816 Thunderbird/6.0 MIME-Version: 1.0 To: Stefano Stabellini References: In-Reply-To: X-Enigmail-Version: 1.3.1 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: Marcelo Tosatti , Nick Piggin , KVM , Peter Zijlstra , the arch/x86 maintainers , Linux Kernel Mailing List , Jeremy Fitzhardinge , Andi Kleen , Avi Kivity , "H. Peter Anvin" , Ingo Molnar , Linus Torvalds , Xen Devel Subject: [Xen-devel] Re: [PATCH 00/13] [PATCH RFC] Paravirtualized ticketlocks X-BeenThere: xen-devel@lists.xensource.com X-Mailman-Version: 2.1.5 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xensource.com Errors-To: xen-devel-bounces@lists.xensource.com On 09/02/2011 04:22 AM, Stefano Stabellini wrote: > do you have a git tree somewhere with this series? git://github.com/jsgf/linux-xen.git upstream/pvticketlock-slowflag J _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel From xen-devel-bounces@lists.xensource.com Tue Sep 06 14:17:37 2011 Return-path: Envelope-to: www-data@lists.xensource.com Delivery-date: Tue, 06 Sep 2011 14:17:37 -0700 Received: from localhost ([127.0.0.1] helo=lists.colo.xensource.com) by lists.xensource.com with esmtp (Exim 4.43) id 1R131V-0002wH-J3; Tue, 06 Sep 2011 14:17:37 -0700 Received: from mail27.messagelabs.com ([193.109.254.147]) by lists.xensource.com with smtp (Exim 4.43) id 1R130Q-0002jQ-Fn for xen-devel@lists.xensource.com; Tue, 06 Sep 2011 14:16:31 -0700 X-Env-Sender: allen.m.kay@intel.com X-Msg-Ref: server-7.tower-27.messagelabs.com!1315343765!47554261!1 X-Originating-IP: [134.134.136.24] X-StarScan-Version: 6.3.6; banners=-,-,- X-VirusChecked: Checked Received: (qmail 25099 invoked from network); 6 Sep 2011 21:16:05 -0000 Received: from mga09.intel.com (HELO mga09.intel.com) (134.134.136.24) by server-7.tower-27.messagelabs.com with SMTP; 6 Sep 2011 21:16:05 -0000 Received: from orsmga001.jf.intel.com ([10.7.209.18]) by orsmga102.jf.intel.com with ESMTP; 06 Sep 2011 14:16:24 -0700 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="4.67,352,1309762800"; d="scan'208";a="45812027" Received: from orsmsx603.amr.corp.intel.com ([10.22.226.49]) by orsmga001.jf.intel.com with ESMTP; 06 Sep 2011 14:16:24 -0700 Received: from orsmsx505.amr.corp.intel.com ([10.22.226.208]) by orsmsx603.amr.corp.intel.com ([10.22.226.49]) with mapi; Tue, 6 Sep 2011 14:16:24 -0700 From: "Kay, Allen M" To: George Dunlap , Jan Beulich Date: Tue, 6 Sep 2011 14:16:22 -0700 Subject: RE: [Xen-devel] [PATCH] xen, vtd: Fix device check for devices behind PCIe-to-PCI bridges Thread-Topic: [Xen-devel] [PATCH] xen, vtd: Fix device check for devices behind PCIe-to-PCI bridges Thread-Index: Acxosw8TH9UmVo6jQ96fev2KIMRl2gEItXFg Message-ID: <987664A83D2D224EAE907B061CE93D5301EA8F9921@orsmsx505.amr.corp.intel.com> References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "xen-devel@lists.xensource.com" X-BeenThere: xen-devel@lists.xensource.com X-Mailman-Version: 2.1.5 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xensource.com Errors-To: xen-devel-bounces@lists.xensource.com I'm curious how does this context entry became valid in the first place if = pdev cannot be found? In general, this patch seems harmless to other situations. It just does th= e same new and old domain checking for the case where pdev is not found. Allen -----Original Message----- From: xen-devel-bounces@lists.xensource.com [mailto:xen-devel-bounces@lists= .xensource.com] On Behalf Of George Dunlap Sent: Thursday, September 01, 2011 7:20 AM To: xen-devel@lists.xensource.com Cc: george.dunlap@eu.citrix.com Subject: [Xen-devel] [PATCH] xen, vtd: Fix device check for devices behind = PCIe-to-PCI bridges On some systems, requests devices behind a PCIe-to-PCI bridge all appear to the IOMMU as though they come from from slot 0, function 0 on that device; so the mapping code much punch a hole for X:0.0 in the IOMMU for such devices. When punching the hole, if that device has already been mapped once, we simply need to check ownership to make sure it's legal. To do so, domain_context_mapping_one() will look up the device for the mapping with pci_get_pdev() and look for the owner. However, if there is no device in X:0.0, this look up will fail. Rather than returning -ENODEV in this situation (causing a failure in mapping the device), try to get the domain ownership from the iommu context mapping itself. Signed-off-by: George Dunlap diff -r 4a4882df5649 -r ede81b0552be xen/drivers/passthrough/vtd/iommu.c --- a/xen/drivers/passthrough/vtd/iommu.c Wed Aug 31 15:23:49 2011 +0100 +++ b/xen/drivers/passthrough/vtd/iommu.c Thu Sep 01 15:18:18 2011 +0100 @@ -113,6 +113,27 @@ static int context_set_domain_id(struct=20 return 0; } =20 +static int context_get_domain_id(struct context_entry *context, + struct iommu *iommu) +{ + unsigned long dom_index, nr_dom; + int domid =3D -1; + + if (iommu && context) + { + nr_dom =3D cap_ndoms(iommu->cap); + + dom_index =3D context_domain_id(*context); + + if ( dom_index < nr_dom && iommu->domid_map) + domid =3D iommu->domid_map[dom_index]; + else + dprintk(XENLOG_DEBUG VTDPREFIX, "%s: dom_index %lu exceeds nr_= dom %lu or iommu has no domid_map\n", + __func__, dom_index, nr_dom); + } + return domid; +} + static struct intel_iommu *__init alloc_intel_iommu(void) { struct intel_iommu *intel; @@ -1237,7 +1258,6 @@ int domain_context_mapping_one( struct hvm_iommu *hd =3D domain_hvm_iommu(domain); struct context_entry *context, *context_entries; u64 maddr, pgd_maddr; - struct pci_dev *pdev =3D NULL; int agaw; =20 ASSERT(spin_is_locked(&pcidevs_lock)); @@ -1249,12 +1269,45 @@ int domain_context_mapping_one( if ( context_present(*context) ) { int res =3D 0; + struct pci_dev *pdev =3D NULL; =20 + /* First try to get domain ownership from device structure. If th= at's + * not available, try to read it from the context itself. */ pdev =3D pci_get_pdev(bus, devfn); - if (!pdev) - res =3D -ENODEV; - else if (pdev->domain !=3D domain) - res =3D -EINVAL; + if ( pdev ) + { + if ( pdev->domain !=3D domain ) + { + dprintk(XENLOG_INFO VTDPREFIX, "d%d: bdf =3D %x:%x.%x owne= d by d%d!", + domain->domain_id,=20 + bus, PCI_SLOT(devfn), PCI_FUNC(devfn), + (pdev->domain) + ? pdev->domain->domain_id : -1); + res =3D -EINVAL; + } + } + else + { + int cdomain; + cdomain =3D context_get_domain_id(context, iommu); + =20 + if ( cdomain < 0 ) + { + dprintk(VTDPREFIX, "d%d: bdf =3D %x:%x.%x mapped, but can'= t find owner!\n", + domain->domain_id,=20 + bus, PCI_SLOT(devfn), PCI_FUNC(devfn)); + res =3D -EINVAL; + } + else if ( cdomain !=3D domain->domain_id ) + { + dprintk(XENLOG_INFO VTDPREFIX, "d%d: bdf =3D %x:%x.%x alre= ady mapped to d%d!", + domain->domain_id,=20 + bus, PCI_SLOT(devfn), PCI_FUNC(devfn), + cdomain); + res =3D -EINVAL; + } + } + unmap_vtd_domain_page(context_entries); spin_unlock(&iommu->lock); return res; _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel From xen-devel-bounces@lists.xensource.com Tue Sep 06 14:18:54 2011 Return-path: Envelope-to: www-data@lists.xensource.com Delivery-date: Tue, 06 Sep 2011 14:18:54 -0700 Received: from localhost ([127.0.0.1] helo=lists.colo.xensource.com) by lists.xensource.com with esmtp (Exim 4.43) id 1R132j-0003Jo-R7; Tue, 06 Sep 2011 14:18:54 -0700 Received: from mail174.messagelabs.com ([85.158.138.51]) by lists.xensource.com with smtp (Exim 4.43) id 1R131v-00032P-Oy for xen-devel@lists.xensource.com; Tue, 06 Sep 2011 14:18:06 -0700 X-Env-Sender: davidtecher@yahoo.fr X-Msg-Ref: server-12.tower-174.messagelabs.com!1315343880!30460429!1 X-Originating-IP: [77.238.189.39] X-StarScan-Version: 6.3.6; banners=-,-,- X-VirusChecked: Checked Received: (qmail 17624 invoked from network); 6 Sep 2011 21:18:00 -0000 Received: from nm10.bullet.mail.ird.yahoo.com (HELO nm10.bullet.mail.ird.yahoo.com) (77.238.189.39) by server-12.tower-174.messagelabs.com with SMTP; 6 Sep 2011 21:18:00 -0000 Received: from [77.238.189.51] by nm10.bullet.mail.ird.yahoo.com with NNFMP; 06 Sep 2011 21:18:00 -0000 Received: from [212.82.108.254] by tm4.bullet.mail.ird.yahoo.com with NNFMP; 06 Sep 2011 21:18:00 -0000 Received: from [127.0.0.1] by omp1019.mail.ird.yahoo.com with NNFMP; 06 Sep 2011 21:18:00 -0000 X-Yahoo-Newman-Property: ymail-3 X-Yahoo-Newman-Id: 143049.57417.bm@omp1019.mail.ird.yahoo.com Received: (qmail 73213 invoked by uid 60001); 6 Sep 2011 21:18:00 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.fr; s=s1024; t=1315343880; bh=Xt+3sHTKENZNaf7TI1rNIHoEuLbYbJmL4t7JQSbAkRA=; h=X-YMail-OSG:Received:X-Mailer:References:Message-ID:Date:From:Reply-To:Subject:To:In-Reply-To:MIME-Version:Content-Type; b=5X4a1GHIFhIn7+yD3lRpPzcASJVJ885DKgHTOTc6rfC2PlyfH9a8KNH9j5Gn7uhOVqWRkGsNBEcF4KvcpxwCHoA0edvQXwqpFdVq7dnksrj4JQ5r2yLEllEn3gp3qrZuWlqjR49yC2jnctD21CMgi7yk8cLp/2opBwh+WDpZcbs= DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.fr; h=X-YMail-OSG:Received:X-Mailer:References:Message-ID:Date:From:Reply-To:Subject:To:In-Reply-To:MIME-Version:Content-Type; b=NwEnbgYmhcYjevTi0RbU3UDHRUNfYZYW5qETrIRv2v7M1KHxk4+MAR/+ljJg7lpTyN2bWknQJizjwB1i1Tr0NN5DAEtevoiVK78yeRnaWofrvryeu0vTLrGhvPinrZ+qYxeCU+2aOFbSSCXv6Dg3OFzKwOBQikTJUFsCrSsNf2A=; X-YMail-OSG: grRZ2nUVM1mK2BYNnR4hz91pccqTZe7PmS1K1050j74CiwK WcuHQmlsS9G7_qzEDdb1JD2h7Nr7noKpiF1jyyP2lD4ucZOm5ohZVB300nng sSIplyJegNIr2x1eRTF3.icUxcUkLwdzpP8lk_R7RgQ4iemc_x_4987CucoA QOFJ0T4_AvBRzTHtJsShUyHWIZwfy7ih2cGfusP7U1tVrWd5E7vU1qUULvsI j3hnGKbDbdaTGhNHkZp_m3TH5ThcH_GPybQxQWHAK2q0X9IZG0KW1paO8S__ 3UcK2U904_Nyoc5ODjBHhnruFFHy0EaBqPtpo6fJcZc1qERXnsWCh5Hd3zLN F7_Dju9czs0z5QI4OTAGmlNucm.crXv3pPwiaptAU3UgG4gTOltRpA9NKbpE xW2Tje1lFR50ZS8LWz11YZ20_ay2xKp05ffD7qtUqQz.xKdEiwI8BGxq8T4z gr3.e7MsGg_Sxlbil0XsitkSJ0QlmL_JV9H4qF6N7MHxUZ0d_51gC.qX8JAt Eyy7xR02L0NCf64Cgh9j17.I0YtUpJmIg3L2Dy33xF1xarCm0ZYmNAiyBLPG nu.aXEghZRkbh0yMFBYcjIQPwrT_T5xiFqlMVZNaIb7Yt82SJdMU62IEC1EE Z4L9d6A6GqokjfkAkdPiIOdvrwaDvWIw5enT05sTF7yEbraiI76Xp.LiiOZb XbfUye_617KdRHUWHK3xdcCM3HQPeiSloYHo71R7K6chy2sizmsJHjUns31f 7p_RgP.5tCGxEprg2M7oku_9ACDPJlA-- Received: from [83.154.246.188] by web29818.mail.ird.yahoo.com via HTTP; Tue, 06 Sep 2011 22:17:59 BST X-Mailer: YahooMailWebService/0.8.113.315625 References: <1314699668477-4749561.post@n5.nabble.com> <1314712525082-4750109.post@n5.nabble.com> <1314716445148-4750357.post@n5.nabble.com> <1314720409505-4750600.post@n5.nabble.com> <1314778567400-4753326.post@n5.nabble.com> <20110831083832.GD7276@reaktio.net> <1314780568949-4753422.post@n5.nabble.com> <1314795401771-4754024.post@n5.nabble.com> <20110831151913.GE7276@reaktio.net> <1315231341254-4770602.post@n5.nabble.com> <1315310225039-4774097.post@n5.nabble.com> Message-ID: <1315343879.61837.YahooMailNeo@web29818.mail.ird.yahoo.com> Date: Tue, 6 Sep 2011 22:17:59 +0100 (BST) From: David TECHER Subject: Re : [Xen-devel] Re: Patches for VGA-Passthrough XEN 4.2 unstable To: komkon555 , "xen-devel@lists.xensource.com" In-Reply-To: <1315310225039-4774097.post@n5.nabble.com> MIME-Version: 1.0 Cc: X-BeenThere: xen-devel@lists.xensource.com X-Mailman-Version: 2.1.5 Precedence: list Reply-To: David TECHER List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0928603130==" Sender: xen-devel-bounces@lists.xensource.com Errors-To: xen-devel-bounces@lists.xensource.com --===============0928603130== Content-Type: multipart/alternative; boundary="0-1635973955-1315343879=:61837" --0-1635973955-1315343879=:61837 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable For the tests I've done, I've tried the last driver .i.e 280.26.=0A=A0It fa= iled.=0A=0A=0ASo I use the old 275.33 and it works like a charm :) on =0A= =0A=0A- XP Pro 32 bits SP3=0A- XP Pro 64 bits SP2=0A=0A=0AI can launch Crys= is 2 and play the game :)=0A=0AHave a look at http://www.youtube.com/watch?= v=3D3SaYO0ERW44=0A=0A=0AWell I am a little limited with my graphic card (MS= I GT 440 1GB for resolution and XP) but it is just enough for me=0Aon a res= olution like 1440x900 ou 1600x??? to play the game.=0A=0ADo not forget to a= dapt dsd to the requires ranges of your graphic card.=0A=0AThis is what I d= id for my card=0A=0A-------------------------------------------------------= ----------------------------=0Aroot@mercury:~# lspci |grep VGA=0A01:00.0 VG= A compatible controller: nVidia Corporation Device 0de0 (rev a1)=0Aroot@mer= cury:~# dmesg | grep 01:00.0 |grep mem=0A[=A0=A0=A0 3.124546] pci 0000:01:0= 0.0: reg 10: [mem 0xfa000000-0xfaffffff]=0A[=A0=A0=A0 3.124565] pci 0000:01= :00.0: reg 14: [mem 0xc0000000-0xcfffffff 64bit pref]=0A[=A0=A0=A0 3.124584= ] pci 0000:01:00.0: reg 1c: [mem 0xd0000000-0xd1ffffff 64bit pref]=0A[=A0= =A0=A0 3.124609] pci 0000:01:00.0: reg 30: [mem 0xfb000000-0xfb07ffff pref]= =0A[=A0=A0=A0 3.199436] vgaarb: device added: PCI:0000:01:00.0,decodes=3Dio= +mem,owns=3Dio+mem,locks=3Dnone=0A[=A0=A0=A0 3.199730] pci 0000:01:00.0: BA= R 0: reserving [mem 0xfa000000-0xfaffffff flags 0x40200] (d=3D0, p=3D0)=0A[= =A0=A0=A0 3.199732] pci 0000:01:00.0: BAR 1: reserving [mem 0xc0000000-0xcf= ffffff flags 0x14220c] (d=3D0, p=3D0)=0A[=A0=A0=A0 3.199735] pci 0000:01:00= .0: BAR 3: reserving [mem 0xd0000000-0xd1ffffff flags 0x14220c] (d=3D0, p= =3D0)=0Aroot@mercury:~# cat gfx_patch/dsdt.asl.patch=0A--- tools/firmware/h= vmloader/acpi/dsdt.asl=A0=A0=A0=A0=A0 2011-08-13 18:43:39.000000000 +0200= =0A+++ tools/firmware/hvmloader/acpi/dsdt.asl=A0=A0=A0=A0=A0 2011-08-13 18:= 58:25.000000000 +0200=0A@@ -173,15 +173,43 @@ DefinitionBlock ("DSDT.aml", = "DSDT", 2,=0A=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0= =A0=A0=A0=A0 0x00000000,=0A=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0= =A0=A0=A0=A0=A0=A0=A0=A0 0x00020000)=0A=0A+=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0= =A0=A0=A0=A0=A0=A0=A0=A0=A0 /* reserve MMIO BARs of gfx for 1:1 mapping */= =0A=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 DWordMemory= (=0A=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0= =A0 ResourceProducer, PosDecode, MinFixed, MaxFixed,=0A=A0=A0=A0=A0=A0=A0= =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 Cacheable, ReadWrite= ,=0A=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0= =A0 0x00000000,=0A-=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0= =A0=A0=A0=A0=A0 0xF0000000,=0A-=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0= =A0=A0=A0=A0=A0=A0=A0=A0=A0 0xF4FFFFFF,=0A+=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0= =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 0xFA000000,=0A+=A0=A0=A0=A0=A0=A0= =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 0xFAFFFFFF,=0A=A0=A0=A0= =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 0x00000000,= =0A-=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 0= x05000000,=0A-=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0= =A0=A0=A0 ,, _Y01)=0A+=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0= =A0=A0=A0=A0=A0=A0 0x01000000)=0A+=0A+=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0= =A0=A0=A0=A0=A0=A0=A0 DWordMemory(=0A+=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0= =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 ResourceProducer, PosDecode, MinFixed, Ma= xFixed,=0A+=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0= =A0=A0 NonCacheable, ReadWrite,=0A+=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0= =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 0x00000000,=0A+=A0=A0=A0=A0=A0=A0=A0=A0=A0= =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 0xC0000000,=0A+=A0=A0=A0=A0=A0= =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 0xCFFFFFFF,=0A+=A0= =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 0x000000= 00,=0A+=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0= =A0 0x10000000)=0A+=0A+=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0= =A0=A0 DWordMemory(=0A+=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0= =A0=A0=A0=A0=A0=A0 ResourceProducer, PosDecode, MinFixed, MaxFixed,=0A+=A0= =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 Cacheabl= e, ReadWrite,=0A+=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0= =A0=A0=A0=A0 0x00000000,=0A+=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0= =A0=A0=A0=A0=A0=A0=A0=A0 0xD0000000,=0A+=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0= =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 0xD1FFFFFF,=0A+=A0=A0=A0=A0=A0=A0=A0= =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 0x00000000,=0A+=A0=A0=A0= =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 0x02000000)=0A= +=0A+=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 DWordMemory(= =0A+=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 R= esourceProducer, PosDecode, MinFixed, MaxFixed,=0A+=A0=A0=A0=A0=A0=A0=A0=A0= =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 Cacheable, ReadWrite,=0A+=A0= =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 0x000000= 00,=0A+=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0= =A0 0xFB000000,=0A+=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0= =A0=A0=A0=A0=A0 0xFB07FFFF,=0A+=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0= =A0=A0=A0=A0=A0=A0=A0=A0=A0 0x00000000,=0A+=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0= =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 0x00080000,=0A+=A0=A0=A0=A0=A0=A0= =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 ,, _Y01)=0A=A0=A0=A0=A0=A0= =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 })=0A=0A=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0= =A0=A0=A0=A0=A0 CreateDWordField(PRT0, \_SB.PCI0._CRS._Y01._MIN, MMIN)=0A= =0A=0A=0A=0A________________________________=0ADe=A0: komkon555 =0A=C0=A0: xen-devel@lists.xensource.com=0AEnvoy=E9 le : Mardi 6= Septembre 2011 12h57=0AObjet=A0: [Xen-devel] Re: Patches for VGA-Passthrou= gh XEN 4.2 unstable=0A=0A=A0 =A0 =A0 =A0 =A0 =A0 Hallo. I tested the new p= atches. The patched version of=0Axen-unstable let start/shutdown Windows XP= normally. But the current nvidia=0Adriver is not yet functional:=A0 questi= on-sign in device-manager windows. =0AThis problem is very sadly, because i= t makes no sense to use gfx-passthrough=0Afor nvidia cards.=0A=A0 =A0 =A0 = =A0 =A0 =A0 Anyway thank you a lot for patches. I see some progress against= =0Athe old one.=0A=0AP.S. Hardware as above.=0A=0A=0A--=0AView this message= in context: http://xen.1045712.n5.nabble.com/Patches-for-VGA-Passthrough-X= EN-4-2-unstable-tp4406265p4774097.html=0ASent from the Xen - Dev mailing li= st archive at Nabble.com.=0A=0A____________________________________________= ___=0AXen-devel mailing list=0AXen-devel@lists.xensource.com=0Ahttp://lists= .xensource.com/xen-devel --0-1635973955-1315343879=:61837 Content-Type: text/html; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable
For the te= sts I've done, I've tried the last driver .i.e 280.26.
 It failed.

= So I use the old 275.33 and it works like a charm :) on

- XP Pro 32 bits SP3
= - XP Pro 64 bits SP2

I can launch Crysis 2 and play the game :)

Have a look at http://www.youtube.com/watch?v=3D3= SaYO0ERW44

Well I am= a little limited with my graphic card (MSI GT 440 1GB for resolution and X= P) but it is just enough for me
on a resolution like= 1440x900 ou 1600x??? to play the game.

Do n= ot forget to adapt dsd to the requires ranges of your graphic card.<= /div>

This is what I did for my card<= /span>

------------------------= -----------------------------------------------------------
root@mercury:~# lspci |grep VGA
01:00.0 VGA compatible controlle= r: nVidia Corporation Device 0de0 (rev a1)
root@mercury:~# dmesg | grep = 01:00.0 |grep mem
[    3.124546] pci 0000:01:00.0: reg 10= : [mem 0xfa000000-0xfaffffff]
[    3.124565] pci 0000:01:= 00.0: reg 14: [mem 0xc0000000-0xcfffffff 64bit pref]
[   = 3.124584] pci 0000:01:00.0: reg 1c: [mem 0xd0000000-0xd1ffffff 64bit pref]=
[    3.124609] pci 0000:01:00.0: reg 30: [mem 0xfb000000= -0xfb07ffff pref]
[    3.199436] vgaarb: device added: PCI:0000:01:00.0,decodes=3Dio+mem,owns=3Dio+mem,locks=3Dnone
[&n= bsp;   3.199730] pci 0000:01:00.0: BAR 0: reserving [mem 0xfa0000= 00-0xfaffffff flags 0x40200] (d=3D0, p=3D0)
[    3.199732= ] pci 0000:01:00.0: BAR 1: reserving [mem 0xc0000000-0xcfffffff flags 0x142= 20c] (d=3D0, p=3D0)
[    3.199735] pci 0000:01:00.0: BAR = 3: reserving [mem 0xd0000000-0xd1ffffff flags 0x14220c] (d=3D0, p=3D0)
r= oot@mercury:~# cat gfx_patch/dsdt.asl.patch
--- tools/firmware/hvmloader= /acpi/dsdt.asl      2011-08-13 18:43:39.000000000 = +0200
+++ tools/firmware/hvmloader/acpi/dsdt.asl    =   2011-08-13 18:58:25.000000000 +0200
@@ -173,15 +173,43 @@ Definit= ionBlock ("DSDT.aml", "DSDT", 2,
      &nb= sp;            =       0x00000000,
          = ;            &n= bsp;  0x00020000)

+       &n= bsp;            /* r= eserve MMIO BARs of gfx for 1:1 mapping */
     = ;            &n= bsp;   DWordMemory(
       =             &nb= sp;     ResourceProducer, PosDecode, MinFixed, MaxFixed= ,
           &nbs= p;             = Cacheable, ReadWrite,
          =             &nb= sp;  0x00000000,
-        &= nbsp;           &nbs= p;   0xF0000000,
-       &n= bsp;            = ;    0xF4FFFFFF,
+      &nb= sp;            =      0xFA000000,
+     &nbs= p;            &= nbsp;     0xFAFFFFFF,
     =             &nb= sp;       0x00000000,
-         &nbs= p;            &= nbsp; 0x05000000,
-         = ;            &n= bsp;  ,, _Y01)
+        &nb= sp;            =    0x01000000)
+
+       = ;             D= WordMemory(
+          = ;            &n= bsp; ResourceProducer, PosDecode, MinFixed, MaxFixed,
+   = ;            &n= bsp;        NonCacheable, ReadWrite,
+          = ;            &n= bsp; 0x00000000,
+         =             &nb= sp;  0xC0000000,
+        &= nbsp;           &nbs= p;   0xCFFFFFFF,
+       &n= bsp;            = ;    0x00000000,
+      &nb= sp;            =      0x10000000)
+
+     = ;            &n= bsp;  DWordMemory(
+         &nb= sp;            =   ResourceProducer, PosDecode, MinFixed, MaxFixed,
+  &nb= sp;            =          Cacheable, ReadWrite,
+=             &nb= sp;           0x00000000,=
+           &nbs= p;            0xD000= 0000,
+           = ;             0xD1FFFFFF,
+         &nbs= p;            &= nbsp; 0x00000000,
+         = ;            &n= bsp;  0x02000000)
+
+       &= nbsp;            DWo= rdMemory(
+          &= nbsp;           &nbs= p; ResourceProducer, PosDecode, MinFixed, MaxFixed,
+   &= nbsp;           &nbs= p;        Cacheable, ReadWrite,
+&nbs= p;            &= nbsp;          0x00000000,
+         &nbs= p;            &= nbsp; 0xFB000000,
+         = ;            &n= bsp;  0xFB07FFFF,
+        =             &nb= sp;   0x00000000,
+       &= nbsp;           &nbs= p;    0x00080000,
+      &n= bsp;            = ;    ,, _Y01)
       &= nbsp;         })

          &nbs= p;      CreateDWordField(PRT0, \_SB.PCI0._CRS._Y01= ._MIN, MMIN)


De : komkon555 <komkon555@freenet.de>
=C0 : xen-devel@lists.xensour= ce.com
Envoy=E9 le : Ma= rdi 6 Septembre 2011 12h57
Objet&n= bsp;: [Xen-devel] Re: Patches for VGA-Passthrough XEN 4.2 unstab= le

            Hallo. I tested= the new patches. The patched version of
xen-unstable let start/shutdown= Windows XP normally. But the current nvidia
driver is not yet functional:  qu= estion-sign in device-manager windows.
This problem is very sadly, beca= use it makes no sense to use gfx-passthrough
for nvidia cards.
 =           Anyway thank you a lot for patches. I s= ee some progress against
the old one.

P.S. Hardware as above.
=

--
View this message in context: http://xen.1045712.n5.nabble.com/Patches-for-VGA-= Passthrough-XEN-4-2-unstable-tp4406265p4774097.html
Sent from the Xe= n - Dev mailing list archive at Nabble.com.

________________________= _______________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lis= ts.xensource.com/xen-devel


--0-1635973955-1315343879=:61837-- --===============0928603130== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel --===============0928603130==-- From xen-devel-bounces@lists.xensource.com Tue Sep 06 14:21:42 2011 Return-path: Envelope-to: www-data@lists.xensource.com Delivery-date: Tue, 06 Sep 2011 14:21:42 -0700 Received: from localhost ([127.0.0.1] helo=lists.colo.xensource.com) by lists.xensource.com with esmtp (Exim 4.43) id 1R135S-0003o0-KK; Tue, 06 Sep 2011 14:21:42 -0700 Received: from mail21.messagelabs.com ([85.158.143.35]) by lists.xensource.com with esmtp (Exim 4.43) id 1R1353-0003bx-1m for xen-devel@lists.xensource.com; Tue, 06 Sep 2011 14:21:17 -0700 X-Env-Sender: konrad@dumpdata.com X-Msg-Ref: server-10.tower-21.messagelabs.com!1315344058!53106953!1 X-Originating-IP: [148.87.113.117] X-StarScan-Version: 6.3.6; banners=-,-,- X-VirusChecked: Checked Received: (qmail 11664 invoked from network); 6 Sep 2011 21:21:00 -0000 Received: from rcsinet15.oracle.com (HELO rcsinet15.oracle.com) (148.87.113.117) by server-10.tower-21.messagelabs.com with DHE-RSA-AES256-SHA encrypted SMTP; 6 Sep 2011 21:21:00 -0000 Received: from rtcsinet22.oracle.com (rtcsinet22.oracle.com [66.248.204.30]) by rcsinet15.oracle.com (Switch-3.4.4/Switch-3.4.4) with ESMTP id p86LL4Jm015052 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Tue, 6 Sep 2011 21:21:06 GMT Received: from acsmt357.oracle.com (acsmt357.oracle.com [141.146.40.157]) by rtcsinet22.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id p86LL3AS028338 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 6 Sep 2011 21:21:04 GMT Received: from abhmt114.oracle.com (abhmt114.oracle.com [141.146.116.66]) by acsmt357.oracle.com (8.12.11.20060308/8.12.11) with ESMTP id p86LKvc5010017; Tue, 6 Sep 2011 16:20:57 -0500 Received: from phenom (/209.6.55.207) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Tue, 06 Sep 2011 14:20:57 -0700 Received: by phenom (Postfix, from userid 1000) id 96B33FD1; Tue, 6 Sep 2011 17:20:46 -0400 (EDT) Date: Tue, 6 Sep 2011 17:20:46 -0400 From: Konrad Rzeszutek Wilk To: David Vrabel Message-ID: <20110906212046.GA24860@dumpdata.com> References: <1313765840-22084-1-git-send-email-david.vrabel@citrix.com> <1313765840-22084-6-git-send-email-david.vrabel@citrix.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <1313765840-22084-6-git-send-email-david.vrabel@citrix.com> User-Agent: Mutt/1.5.21 (2010-09-15) X-Source-IP: rtcsinet22.oracle.com [66.248.204.30] X-CT-RefId: str=0001.0A090208.4E668EC3.0068,ss=1,re=0.000,fgs=0 Cc: xen-devel@lists.xensource.com, David Vrabel Subject: [Xen-devel] Re: [PATCH 5/5] xen: release all pages within 1-1 p2m mappings X-BeenThere: xen-devel@lists.xensource.com X-Mailman-Version: 2.1.5 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xensource.com Errors-To: xen-devel-bounces@lists.xensource.com On Fri, Aug 19, 2011 at 03:57:20PM +0100, David Vrabel wrote: > In xen_memory_setup() all reserved regions and gaps are set to an > identity (1-1) p2m mapping. If an available page has a PFN within one > of these 1-1 mappings it will become accessible (as it MFN is lost) so > release them before setting up the mapping. > > This can make an additional 256 MiB or more of RAM available > (depending on the size of the reserved regions in the memory map). .. if the xen_start_info->nr_pages overlaps the reserved region. > > Signed-off-by: David Vrabel > --- > arch/x86/xen/setup.c | 88 ++++++++++++-------------------------------------- > 1 files changed, 21 insertions(+), 67 deletions(-) > > diff --git a/arch/x86/xen/setup.c b/arch/x86/xen/setup.c > index 93e4542..0f1cd69 100644 > --- a/arch/x86/xen/setup.c > +++ b/arch/x86/xen/setup.c > @@ -123,73 +123,33 @@ static unsigned long __init xen_release_chunk(phys_addr_t start_addr, > return len; > } > > -static unsigned long __init xen_return_unused_memory(unsigned long max_pfn, > - const struct e820entry *map, > - int nr_map) > +static unsigned long __init xen_set_identity_and_release(const struct e820entry *list, > + ssize_t map_size, > + unsigned long nr_pages) > { > - phys_addr_t max_addr = PFN_PHYS(max_pfn); > - phys_addr_t last_end = ISA_END_ADDRESS; > + phys_addr_t avail_end = PFN_PHYS(nr_pages); > + phys_addr_t last_end = 0; > unsigned long released = 0; > - int i; > - > - /* Free any unused memory above the low 1Mbyte. */ > - for (i = 0; i < nr_map && last_end < max_addr; i++) { > - phys_addr_t end = map[i].addr; > - end = min(max_addr, end); > - > - if (last_end < end) > - released += xen_release_chunk(last_end, end); > - last_end = max(last_end, map[i].addr + map[i].size); > - } > - > - if (last_end < max_addr) > - released += xen_release_chunk(last_end, max_addr); > - > - printk(KERN_INFO "released %lu pages of unused memory\n", released); > - return released; > -} > - > -static unsigned long __init xen_set_identity(const struct e820entry *list, > - ssize_t map_size) > -{ > - phys_addr_t last = xen_initial_domain() ? 0 : ISA_END_ADDRESS; > - phys_addr_t start_pci = last; > const struct e820entry *entry; > - unsigned long identity = 0; > int i; > > for (i = 0, entry = list; i < map_size; i++, entry++) { > - phys_addr_t start = entry->addr; > - phys_addr_t end = start + entry->size; > - > - if (start < last) > - start = last; > + phys_addr_t begin = last_end; The "begin" is a bit confusing. You are using the previous E820 entry's end - not the beginning of this E820 entry. Doing a s/begin/last_end/ makes the code a bit easier to understand. > + phys_addr_t end = entry->addr + entry->size; > > - if (end <= start) > - continue; > + last_end = end; Please include the comment: /* This entry end. */ > > - /* Skip over the 1MB region. */ > - if (last > end) > - continue; > + if (entry->type == E820_RAM || entry->type == E820_UNUSABLE) > + end = entry->addr; And: /* Should encapsulate the gap between prev_end and this E820 entry's starting address. */ > > - if ((entry->type == E820_RAM) || (entry->type == E820_UNUSABLE)) { > - if (start > start_pci) > - identity += set_phys_range_identity( > - PFN_UP(start_pci), PFN_DOWN(start)); > + if (begin < end) { > + if (begin < avail_end) > + released += xen_release_chunk(begin, min(end, avail_end)); > > - /* Without saving 'last' we would gooble RAM too > - * at the end of the loop. */ > - last = end; > - start_pci = end; > - continue; > + set_phys_range_identity(PFN_UP(begin), PFN_DOWN(end)); identity += set_phys_range .. > } > - start_pci = min(start, start_pci); > - last = end; > } > - if (last > start_pci) > - identity += set_phys_range_identity( > - PFN_UP(start_pci), PFN_DOWN(last)); > - return identity; OK, but you have ripped out the nice printk's that existed before. So add them back in: printk(KERN_INFO "released %lu pages of unused memory\n", released); printk(KERN_INFO "Set %ld page(s) to 1-1 mapping.\n", identity); as they are quite useful in the field. > + return released; > } > > static unsigned long __init xen_get_max_pages(void) > @@ -217,7 +177,6 @@ char * __init xen_memory_setup(void) > struct xen_memory_map memmap; > unsigned long max_pages; > unsigned long extra_pages = 0; > - unsigned long identity_pages = 0; > int i; > int op; > > @@ -250,7 +209,12 @@ char * __init xen_memory_setup(void) > if (max_pages > max_pfn) > extra_pages += max_pages - max_pfn; > > - extra_pages += xen_return_unused_memory(max_pfn, map, memmap.nr_entries); > + /* > + * Set P2M for all non-RAM pages and E820 gaps to be identity > + * type PFNs. Any RAM pages that would be made inaccesible by > + * this are first released. > + */ > + extra_pages += xen_set_identity_and_release(map, memmap.nr_entries, max_pfn); > > /* > * Clamp the amount of extra memory to a EXTRA_MEM_RATIO > @@ -294,10 +258,6 @@ char * __init xen_memory_setup(void) > * In domU, the ISA region is normal, usable memory, but we > * reserve ISA memory anyway because too many things poke > * about in there. > - * > - * In Dom0, the host E820 information can leave gaps in the > - * ISA range, which would cause us to release those pages. To > - * avoid this, we unconditionally reserve them here. > */ > e820_add_region(ISA_START_ADDRESS, ISA_END_ADDRESS - ISA_START_ADDRESS, > E820_RESERVED); > @@ -314,12 +274,6 @@ char * __init xen_memory_setup(void) > > sanitize_e820_map(e820.map, ARRAY_SIZE(e820.map), &e820.nr_map); > > - /* > - * Set P2M for all non-RAM pages and E820 gaps to be identity > - * type PFNs. > - */ > - identity_pages = xen_set_identity(e820.map, e820.nr_map); > - printk(KERN_INFO "Set %ld page(s) to 1-1 mapping.\n", identity_pages); > return "Xen"; > } > > -- > 1.7.2.5 _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel From xen-devel-bounces@lists.xensource.com Tue Sep 06 14:32:47 2011 Return-path: Envelope-to: www-data@lists.xensource.com Delivery-date: Tue, 06 Sep 2011 14:32:47 -0700 Received: from localhost ([127.0.0.1] helo=lists.colo.xensource.com) by lists.xensource.com with esmtp (Exim 4.43) id 1R13GB-0004Md-KV; Tue, 06 Sep 2011 14:32:47 -0700 Received: from mail182.messagelabs.com ([85.158.139.83]) by lists.xensource.com with esmtp (Exim 4.43) id 1R13FT-00049n-FA for xen-devel@lists.xensource.com; Tue, 06 Sep 2011 14:32:03 -0700 X-Env-Sender: konrad@dumpdata.com X-Msg-Ref: server-10.tower-182.messagelabs.com!1315344718!17288498!1 X-Originating-IP: [141.146.126.227] X-StarScan-Version: 6.3.6; banners=-,-,- X-VirusChecked: Checked Received: (qmail 5573 invoked from network); 6 Sep 2011 21:32:00 -0000 Received: from acsinet15.oracle.com (HELO acsinet15.oracle.com) (141.146.126.227) by server-10.tower-182.messagelabs.com with DHE-RSA-AES256-SHA encrypted SMTP; 6 Sep 2011 21:32:00 -0000 Received: from acsinet22.oracle.com (acsinet22.oracle.com [141.146.126.238]) by acsinet15.oracle.com (Switch-3.4.4/Switch-3.4.4) with ESMTP id p86LVudB010043 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Tue, 6 Sep 2011 21:31:57 GMT Received: from acsmt356.oracle.com (acsmt356.oracle.com [141.146.40.156]) by acsinet22.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id p86LVt1p007361 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 6 Sep 2011 21:31:55 GMT Received: from abhmt101.oracle.com (abhmt101.oracle.com [141.146.116.53]) by acsmt356.oracle.com (8.12.11.20060308/8.12.11) with ESMTP id p86LVnbi024676; Tue, 6 Sep 2011 16:31:50 -0500 Received: from phenom (/209.6.55.207) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Tue, 06 Sep 2011 14:31:49 -0700 Received: by phenom (Postfix, from userid 1000) id 4D565FD1; Tue, 6 Sep 2011 17:31:39 -0400 (EDT) Date: Tue, 6 Sep 2011 17:31:39 -0400 From: Konrad Rzeszutek Wilk To: David Vrabel Message-ID: <20110906213139.GB24860@dumpdata.com> References: <1313765840-22084-1-git-send-email-david.vrabel@citrix.com> <1313765840-22084-3-git-send-email-david.vrabel@citrix.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <1313765840-22084-3-git-send-email-david.vrabel@citrix.com> User-Agent: Mutt/1.5.21 (2010-09-15) X-Source-IP: acsinet22.oracle.com [141.146.126.238] X-Auth-Type: Internal IP X-CT-RefId: str=0001.0A090209.4E66914D.015B:SCFMA922111,ss=1,re=-4.000,fgs=0 Cc: xen-devel@lists.xensource.com Subject: [Xen-devel] Re: [PATCH 2/5] xen/balloon: account for pages released during memory setup X-BeenThere: xen-devel@lists.xensource.com X-Mailman-Version: 2.1.5 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xensource.com Errors-To: xen-devel-bounces@lists.xensource.com On Fri, Aug 19, 2011 at 03:57:17PM +0100, David Vrabel wrote: > In xen_memory_setup() pages that occur in gaps in the memory map are > released back to Xen. This reduces the domain's current page count. You might want to add: "in the hypervisor." > The Xen balloon driver does not correctly decrease its initial > current_pages count to reflect this. If 'delta' pages are released > and the target is adjusted the resulting reservation is always 'delta' > less than the requested target. Might want to add: Wherein delta is reported as (for example): [ 0.000000] released 261886 pages of unused memory > > This affects dom0 if the initial allocation of pages overlaps the PCI > memory region but won't affect most domU guests that have been setup > with pseudo-physical memory maps that don't have gaps. > > Fix this by asking the hypervisor what the current reservation is when > starting the balloon driver. > > If the domain's targets are managed by xapi, the domain may eventually > run out of memory and die because xapi currently gets its target > calculations wrong and whenever it is restarted it always reduces the > target by 'delta'. > > Signed-off-by: David Vrabel > --- > drivers/xen/balloon.c | 7 ++++++- > 1 files changed, 6 insertions(+), 1 deletions(-) > > diff --git a/drivers/xen/balloon.c b/drivers/xen/balloon.c > index 5dfd8f8..5814022 100644 > --- a/drivers/xen/balloon.c > +++ b/drivers/xen/balloon.c > @@ -557,15 +557,20 @@ EXPORT_SYMBOL(free_xenballooned_pages); > > static int __init balloon_init(void) > { > + domid_t domid = DOMID_SELF; > unsigned long pfn, extra_pfn_end; > struct page *page; > + int ret; long int? > > if (!xen_domain()) > return -ENODEV; > > pr_info("xen/balloon: Initialising balloon driver.\n"); > > - balloon_stats.current_pages = xen_pv_domain() ? min(xen_start_info->nr_pages, max_pfn) : max_pfn; > + ret = HYPERVISOR_memory_op(XENMEM_current_reservation, &domid); > + if (ret < 0) > + return ret; > + balloon_stats.current_pages = ret; > balloon_stats.target_pages = balloon_stats.current_pages; > balloon_stats.balloon_low = 0; > balloon_stats.balloon_high = 0; > -- > 1.7.2.5 _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel From xen-devel-bounces@lists.xensource.com Tue Sep 06 14:59:22 2011 Return-path: Envelope-to: www-data@lists.xensource.com Delivery-date: Tue, 06 Sep 2011 14:59:22 -0700 Received: from localhost ([127.0.0.1] helo=lists.colo.xensource.com) by lists.xensource.com with esmtp (Exim 4.43) id 1R13fs-000584-5D; Tue, 06 Sep 2011 14:59:21 -0700 Received: from mail27.messagelabs.com ([193.109.254.147]) by lists.xensource.com with esmtp (Exim 4.43) id 1R13e6-0004uW-D2 for xen-devel@lists.xensource.com; Tue, 06 Sep 2011 14:57:31 -0700 X-Env-Sender: konrad@dumpdata.com X-Msg-Ref: server-7.tower-27.messagelabs.com!1315346225!47556367!1 X-Originating-IP: [141.146.126.227] X-StarScan-Version: 6.3.6; banners=-,-,- X-VirusChecked: Checked Received: (qmail 3523 invoked from network); 6 Sep 2011 21:57:06 -0000 Received: from acsinet15.oracle.com (HELO acsinet15.oracle.com) (141.146.126.227) by server-7.tower-27.messagelabs.com with DHE-RSA-AES256-SHA encrypted SMTP; 6 Sep 2011 21:57:06 -0000 Received: from acsinet21.oracle.com (acsinet21.oracle.com [141.146.126.237]) by acsinet15.oracle.com (Switch-3.4.4/Switch-3.4.4) with ESMTP id p86LvMR3010270 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Tue, 6 Sep 2011 21:57:24 GMT Received: from acsmt356.oracle.com (acsmt356.oracle.com [141.146.40.156]) by acsinet21.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id p86LvMXd022059 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 6 Sep 2011 21:57:22 GMT Received: from abhmt114.oracle.com (abhmt114.oracle.com [141.146.116.66]) by acsmt356.oracle.com (8.12.11.20060308/8.12.11) with ESMTP id p86LvHow008850; Tue, 6 Sep 2011 16:57:17 -0500 Received: from phenom (/209.6.55.207) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Tue, 06 Sep 2011 14:57:16 -0700 Received: by phenom (Postfix, from userid 1000) id 63EFFFD1; Tue, 6 Sep 2011 17:57:06 -0400 (EDT) Date: Tue, 6 Sep 2011 17:57:06 -0400 From: Konrad Rzeszutek Wilk To: David Vrabel Message-ID: <20110906215706.GC24860@dumpdata.com> References: <1313765840-22084-1-git-send-email-david.vrabel@citrix.com> <1313765840-22084-4-git-send-email-david.vrabel@citrix.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <1313765840-22084-4-git-send-email-david.vrabel@citrix.com> User-Agent: Mutt/1.5.21 (2010-09-15) X-Source-IP: acsinet21.oracle.com [141.146.126.237] X-Auth-Type: Internal IP X-CT-RefId: str=0001.0A090203.4E669744.0126:SCFMA922111,ss=1,re=-4.000,fgs=0 Cc: xen-devel@lists.xensource.com Subject: [Xen-devel] Re: [PATCH 3/5] xen: allow balloon driver to use more than one memory region X-BeenThere: xen-devel@lists.xensource.com X-Mailman-Version: 2.1.5 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xensource.com Errors-To: xen-devel-bounces@lists.xensource.com On Fri, Aug 19, 2011 at 03:57:18PM +0100, David Vrabel wrote: > Allow the xen balloon driver to populate its list of extra pages from > more than one region of memory. This will allow platforms to provide > (for example) a region of low memory and a region of high memory. > > The maximum possible number of extra regions is 128 (== E820MAX) which > is quite large so xen_extra_mem is placed in __initdata. This is safe > as both xen_memeory_setup() and balloon_init() are in __init. ^^^^^^ memory. > > The balloon regions themselves are not altered (i.e., there is still > only the one region). > > Signed-off-by: David Vrabel > --- > arch/x86/xen/setup.c | 20 +++++++++--------- > drivers/xen/balloon.c | 51 ++++++++++++++++++++++++++++-------------------- > include/xen/page.h | 9 +++++++- > 3 files changed, 48 insertions(+), 32 deletions(-) > > diff --git a/arch/x86/xen/setup.c b/arch/x86/xen/setup.c > index c3b8d44..4720c2d 100644 > --- a/arch/x86/xen/setup.c > +++ b/arch/x86/xen/setup.c > @@ -37,7 +37,7 @@ extern void xen_syscall_target(void); > extern void xen_syscall32_target(void); > > /* Amount of extra memory space we add to the e820 ranges */ > -phys_addr_t xen_extra_mem_start, xen_extra_mem_size; > +struct xen_memory_region xen_extra_mem[XEN_EXTRA_MEM_MAX_REGIONS] __initdata; > > /* > * The maximum amount of extra memory compared to the base size. The > @@ -56,7 +56,7 @@ static void __init xen_add_extra_mem(unsigned long pages) > unsigned long pfn; > > u64 size = (u64)pages * PAGE_SIZE; > - u64 extra_start = xen_extra_mem_start + xen_extra_mem_size; > + u64 extra_start = xen_extra_mem[0].start + xen_extra_mem[0].size; > > if (!pages) > return; > @@ -66,7 +66,7 @@ static void __init xen_add_extra_mem(unsigned long pages) > > memblock_x86_reserve_range(extra_start, extra_start + size, "XEN EXTRA"); > > - xen_extra_mem_size += size; > + xen_extra_mem[0].size += size; > > xen_max_p2m_pfn = PFN_DOWN(extra_start + size); > > @@ -239,7 +239,7 @@ char * __init xen_memory_setup(void) > > memcpy(map_raw, map, sizeof(map)); > e820.nr_map = 0; > - xen_extra_mem_start = mem_end; > + xen_extra_mem[0].start = mem_end; > for (i = 0; i < memmap.nr_entries; i++) { > unsigned long long end; > > @@ -267,8 +267,8 @@ char * __init xen_memory_setup(void) > e820_add_region(end, delta, E820_UNUSABLE); > } > > - if (map[i].size > 0 && end > xen_extra_mem_start) > - xen_extra_mem_start = end; > + if (map[i].size > 0 && end > xen_extra_mem[0].start) > + xen_extra_mem[0].start = end; > > /* Add region if any remains */ > if (map[i].size > 0) > @@ -276,10 +276,10 @@ char * __init xen_memory_setup(void) > } > /* Align the balloon area so that max_low_pfn does not get set > * to be at the _end_ of the PCI gap at the far end (fee01000). > - * Note that xen_extra_mem_start gets set in the loop above to be > - * past the last E820 region. */ > - if (xen_initial_domain() && (xen_extra_mem_start < (1ULL<<32))) > - xen_extra_mem_start = (1ULL<<32); > + * Note that the start of balloon area gets set in the loop above > + * to be past the last E820 region. */ > + if (xen_initial_domain() && (xen_extra_mem[0].start < (1ULL<<32))) > + xen_extra_mem[0].start = (1ULL<<32); > > /* > * In domU, the ISA region is normal, usable memory, but we > diff --git a/drivers/xen/balloon.c b/drivers/xen/balloon.c > index 5814022..996cf65 100644 > --- a/drivers/xen/balloon.c > +++ b/drivers/xen/balloon.c > @@ -555,11 +555,35 @@ void free_xenballooned_pages(int nr_pages, struct page** pages) > } > EXPORT_SYMBOL(free_xenballooned_pages); > > -static int __init balloon_init(void) > +static void __init balloon_add_memory_region(unsigned long start_pfn, unsigned long pages) That looks suspiciously like it has more than 80 lines. You ran the _all_ of the patches through scripts/checkpath.pl right? > { > - domid_t domid = DOMID_SELF; > unsigned long pfn, extra_pfn_end; > struct page *page; > + > + /* > + * Initialise the balloon with excess memory space. We need > + * to make sure we don't add memory which doesn't exist or > + * logically exist. The E820 map can be trimmed to be smaller > + * than the amount of physical memory due to the mem= command > + * line parameter. And if this is a 32-bit non-HIGHMEM kernel > + * on a system with memory which requires highmem to access, > + * don't try to use it. That whole comment is just confusing.. But I do know that you just moved it, but I wonder if it makes sense to remove it or alter it in the future. > + */ > + extra_pfn_end = min(min(max_pfn, e820_end_of_ram_pfn()), > + start_pfn + pages); > + for (pfn = start_pfn; pfn < extra_pfn_end; pfn++) { > + page = pfn_to_page(pfn); > + /* totalram_pages and totalhigh_pages do not > + include the boot-time balloon extension, so > + don't subtract from it. */ > + __balloon_append(page); > + } > +} > + > +static int __init balloon_init(void) > +{ > + domid_t domid = DOMID_SELF; > + int i; > int ret; > > if (!xen_domain()) > @@ -588,25 +612,10 @@ static int __init balloon_init(void) > register_memory_notifier(&xen_memory_nb); > #endif > > - /* > - * Initialise the balloon with excess memory space. We need > - * to make sure we don't add memory which doesn't exist or > - * logically exist. The E820 map can be trimmed to be smaller > - * than the amount of physical memory due to the mem= command > - * line parameter. And if this is a 32-bit non-HIGHMEM kernel > - * on a system with memory which requires highmem to access, > - * don't try to use it. > - */ > - extra_pfn_end = min(min(max_pfn, e820_end_of_ram_pfn()), > - (unsigned long)PFN_DOWN(xen_extra_mem_start + xen_extra_mem_size)); > - for (pfn = PFN_UP(xen_extra_mem_start); > - pfn < extra_pfn_end; > - pfn++) { > - page = pfn_to_page(pfn); > - /* totalram_pages and totalhigh_pages do not include the boot-time > - balloon extension, so don't subtract from it. */ > - __balloon_append(page); > - } > + for (i = 0; i < XEN_EXTRA_MEM_MAX_REGIONS; i++) > + if (xen_extra_mem[i].size) > + balloon_add_memory_region(PFN_UP(xen_extra_mem[i].start), > + PFN_DOWN(xen_extra_mem[i].size)); > > return 0; > } > diff --git a/include/xen/page.h b/include/xen/page.h > index 0be36b9..b432c03 100644 > --- a/include/xen/page.h > +++ b/include/xen/page.h > @@ -3,6 +3,13 @@ > > #include > > -extern phys_addr_t xen_extra_mem_start, xen_extra_mem_size; > +struct xen_memory_region { > + phys_addr_t start; > + phys_addr_t size; > +}; > + > +#define XEN_EXTRA_MEM_MAX_REGIONS 128 /* == E820MAX */ > + > +extern struct xen_memory_region xen_extra_mem[XEN_EXTRA_MEM_MAX_REGIONS]; __initdata > > #endif /* _XEN_PAGE_H */ > -- > 1.7.2.5 _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel From xen-devel-bounces@lists.xensource.com Tue Sep 06 17:54:23 2011 Return-path: Envelope-to: www-data@lists.xensource.com Delivery-date: Tue, 06 Sep 2011 17:54:23 -0700 Received: from localhost ([127.0.0.1] helo=lists.colo.xensource.com) by lists.xensource.com with esmtp (Exim 4.43) id 1R16PG-0008FU-ES; Tue, 06 Sep 2011 17:54:23 -0700 Received: from mail216.messagelabs.com ([85.158.143.99]) by lists.xensource.com with esmtp (Exim 4.43) id 1R0t0m-0003nW-UW for xen-devel@lists.xensource.com; Tue, 06 Sep 2011 03:36:14 -0700 X-Env-Sender: b.schweikert@googlemail.com X-Msg-Ref: server-2.tower-216.messagelabs.com!1315305369!17219972!1 X-Originating-IP: [74.125.82.43] X-StarScan-Version: 6.3.6; banners=-,-,- X-VirusChecked: Checked Received: (qmail 18384 invoked from network); 6 Sep 2011 10:36:09 -0000 Received: from mail-ww0-f43.google.com (HELO mail-ww0-f43.google.com) (74.125.82.43) by server-2.tower-216.messagelabs.com with RC4-SHA encrypted SMTP; 6 Sep 2011 10:36:09 -0000 Received: by wwe32 with SMTP id 32so4887701wwe.24 for ; Tue, 06 Sep 2011 03:36:09 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlemail.com; s=gamma; h=message-id:date:from:user-agent:mime-version:to:subject :content-type; bh=AMCL5758yR2Kb7v7aOE44osfBuYuSy1h0Saz7bAmmqs=; b=a8bcYiNbNqGSZe6YYEYda6ETwRm55mwk6VlsehnlxC+ow6vTAT5DK4ZGKf5eXBl3kE xOLKgEo6uVHokAVcTYP+KWu4Rxnr/Nuhy0yS04ug4VSI4Y6rzi1kmDAHty7zg5nRglRt bewi9Kqy1hR9aqySEzHt9B2p7MvrRsNtgKVK8= Received: by 10.227.28.154 with SMTP id m26mr5015296wbc.38.1315305369073; Tue, 06 Sep 2011 03:36:09 -0700 (PDT) Received: from [192.168.0.2] (p3E9C317C.dip.t-dialin.net [62.156.49.124]) by mx.google.com with ESMTPS id n12sm11152492wbp.7.2011.09.06.03.36.06 (version=SSLv3 cipher=OTHER); Tue, 06 Sep 2011 03:36:07 -0700 (PDT) Message-ID: <4E65F794.6060705@gmail.com> Date: Tue, 06 Sep 2011 12:36:04 +0200 From: Benjamin Schweikert User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:6.0.1) Gecko/20110830 Thunderbird/6.0.1 MIME-Version: 1.0 To: xen-devel@lists.xensource.com Content-Type: multipart/mixed; boundary="------------050404030308050904030304" X-Mailman-Approved-At: Tue, 06 Sep 2011 17:53:10 -0700 Subject: [Xen-devel] Problems with xen 4.1.x + passthrough + pvonhvm X-BeenThere: xen-devel@lists.xensource.com X-Mailman-Version: 2.1.5 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xensource.com Errors-To: xen-devel-bounces@lists.xensource.com This is a multi-part message in MIME format. --------------050404030308050904030304 Content-Type: text/plain; charset=ISO-8859-15; format=flowed Content-Transfer-Encoding: 7bit Hi, I have a Gigabyte 890FXA-UD5 Mainboard with Debian Squeeze (with Debians Xen Kernel-2.6.32) and xen 4.0.2 running. I am able to use PV Domains with passthrough and HVM Domains (Kernel 2.6.38 with pvonhvm) with pci and vga passthroug without any problems. If I upgrade xen to 4.1.x I can still use my pv domains with pci passthrough. I can also use a Win 7 HVM domain with pci passthrough. But if I want to use a Ubuntu Natty HVM domain with pci and vga passthrough I am running into some errors. Remember, this setup was running with xen 4.0.2. I attached some log files for every case I tested. Things that work with the Ubuntu Natty HVM wit Xen 4.1.x: - Without passthroughing anything, everything is working - Using a Kernel older than 2.6.36 everything is wirking incl. pci and vga passthrough Things I tried without success: - Kernel 2.6.38 and 3.0.4 with pvonhvm - xen_platform_pci=0 - hda instead of xvda in the config file I hope somebody got a good idea how to fix this problem. Ben --------------050404030308050904030304 Content-Type: text/plain; charset=UTF-8; name="1-Natty-working-no-passthrough" Content-Transfer-Encoding: 8bit Content-Disposition: attachment; filename="1-Natty-working-no-passthrough" root@server:~/xen/configs# xm create ubuntu-mediacenter.cfg -c Using config file "./ubuntu-mediacenter.cfg". Started domain ubuntu-mediacenter (id=8) [ 0.000000] Initializing cgroup subsys cpuset [ 0.000000] Initializing cgroup subsys cpu [ 0.000000] Linux version 2.6.38-11-server (buildd@allspice) (gcc version 4.5.2 (Ubuntu/Linaro 4.5.2-8ubuntu4) ) #48-Ubuntu SMP Fri Jul 29 19:20:32 UTC 2011 (Ubuntu 2.6.38-11.48-server 2.6.38.8) [ 0.000000] Command line: BOOT_IMAGE=/boot/vmlinuz-2.6.38-11-server root=UUID=992cda33-09ce-4437-b110-fe153702b2d5 ro console=ttyS0,115200n8 [ 0.000000] BIOS-provided physical RAM map: [ 0.000000] BIOS-e820: 0000000000000000 - 000000000009e000 (usable) [ 0.000000] BIOS-e820: 000000000009e000 - 00000000000a0000 (reserved) [ 0.000000] BIOS-e820: 00000000000e0000 - 0000000000100000 (reserved) [ 0.000000] BIOS-e820: 0000000000100000 - 0000000040000000 (usable) [ 0.000000] BIOS-e820: 00000000fc000000 - 0000000100000000 (reserved) [ 0.000000] NX (Execute Disable) protection: active [ 0.000000] DMI 2.4 present. [ 0.000000] Hypervisor detected: Xen HVM [ 0.000000] Xen version 4.1. [ 0.000000] Netfront and the Xen platform PCI driver have been compiled for this kernel: unplug emulated NICs. [ 0.000000] Blkfront and the Xen platform PCI driver have been compiled for this kernel: unplug emulated disks. [ 0.000000] You might have to change the root device [ 0.000000] from /dev/hd[a-d] to /dev/xvd[a-d] [ 0.000000] in your root= kernel command line option [ 0.000000] No AGP bridge found [ 0.000000] last_pfn = 0x40000 max_arch_pfn = 0x400000000 [ 0.000000] x86 PAT enabled: cpu 0, old 0x7040600070406, new 0x7010600070106 [ 0.000000] found SMP MP-table at [ffff8800000fbc90] fbc90 [ 0.000000] init_memory_mapping: 0000000000000000-0000000040000000 [ 0.000000] RAMDISK: 366e0000 - 37368000 [ 0.000000] ACPI: RSDP 00000000000ea020 00024 (v02 Xen) [ 0.000000] ACPI: XSDT 00000000fc0134b0 00034 (v01 Xen HVM 00000000 HVML 00000000) [ 0.000000] ACPI: FACP 00000000fc0132d0 000F4 (v04 Xen HVM 00000000 HVML 00000000) [ 0.000000] ACPI: DSDT 00000000fc003440 0FE05 (v02 Xen HVM 00000000 INTL 20100528) [ 0.000000] ACPI: FACS 00000000fc003400 00040 [ 0.000000] ACPI: APIC 00000000fc0133d0 000D8 (v02 Xen HVM 00000000 HVML 00000000) [ 0.000000] No NUMA configuration found [ 0.000000] Faking a node at 0000000000000000-0000000040000000 [ 0.000000] Initmem setup node 0 0000000000000000-0000000040000000 [ 0.000000] NODE_DATA [000000003fffb000 - 000000003fffffff] [ 0.000000] Zone PFN ranges: [ 0.000000] DMA 0x00000010 -> 0x00001000 [ 0.000000] DMA32 0x00001000 -> 0x00100000 [ 0.000000] Normal empty [ 0.000000] Movable zone start PFN for each node [ 0.000000] early_node_map[2] active PFN ranges [ 0.000000] 0: 0x00000010 -> 0x0000009e [ 0.000000] 0: 0x00000100 -> 0x00040000 [ 0.000000] ACPI: PM-Timer IO Port: 0xb008 [ 0.000000] ACPI: LAPIC (acpi_id[0x00] lapic_id[0x00] enabled) [ 0.000000] ACPI: LAPIC (acpi_id[0x01] lapic_id[0x02] enabled) [ 0.000000] ACPI: LAPIC (acpi_id[0x02] lapic_id[0x04] disabled) [ 0.000000] ACPI: LAPIC (acpi_id[0x03] lapic_id[0x06] disabled) [ 0.000000] ACPI: LAPIC (acpi_id[0x04] lapic_id[0x08] disabled) [ 0.000000] ACPI: LAPIC (acpi_id[0x05] lapic_id[0x0a] disabled) [ 0.000000] ACPI: LAPIC (acpi_id[0x06] lapic_id[0x0c] disabled) [ 0.000000] ACPI: LAPIC (acpi_id[0x07] lapic_id[0x0e] disabled) [ 0.000000] ACPI: LAPIC (acpi_id[0x08] lapic_id[0x10] disabled) [ 0.000000] ACPI: LAPIC (acpi_id[0x09] lapic_id[0x12] disabled) [ 0.000000] ACPI: LAPIC (acpi_id[0x0a] lapic_id[0x14] disabled) [ 0.000000] ACPI: LAPIC (acpi_id[0x0b] lapic_id[0x16] disabled) [ 0.000000] ACPI: LAPIC (acpi_id[0x0c] lapic_id[0x18] disabled) [ 0.000000] ACPI: LAPIC (acpi_id[0x0d] lapic_id[0x1a] disabled) [ 0.000000] ACPI: LAPIC (acpi_id[0x0e] lapic_id[0x1c] disabled) [ 0.000000] ACPI: IOAPIC (id[0x01] address[0xfec00000] gsi_base[0]) [ 0.000000] IOAPIC[0]: apic_id 1, version 17, address 0xfec00000, GSI 0-47 [ 0.000000] ACPI: INT_SRC_OVR (bus 0 bus_irq 0 global_irq 2 dfl dfl) [ 0.000000] ACPI: INT_SRC_OVR (bus 0 bus_irq 5 global_irq 5 low level) [ 0.000000] ACPI: INT_SRC_OVR (bus 0 bus_irq 10 global_irq 10 low level) [ 0.000000] ACPI: INT_SRC_OVR (bus 0 bus_irq 11 global_irq 11 low level) [ 0.000000] Using ACPI (MADT) for SMP configuration information [ 0.000000] SMP: Allowing 15 CPUs, 13 hotplug CPUs [ 0.000000] PM: Registered nosave memory: 000000000009e000 - 00000000000a0000 [ 0.000000] PM: Registered nosave memory: 00000000000a0000 - 00000000000e0000 [ 0.000000] PM: Registered nosave memory: 00000000000e0000 - 0000000000100000 [ 0.000000] Allocating PCI resources starting at 40000000 (gap: 40000000:bc000000) [ 0.000000] Booting paravirtualized kernel on Xen [ 0.000000] setup_percpu: NR_CPUS:256 nr_cpumask_bits:256 nr_cpu_ids:15 nr_node_ids:1 [ 0.000000] PERCPU: Embedded 28 pages/cpu @ffff88003fc00000 s84416 r8192 d22080 u131072 [ 0.000000] Built 1 zonelists in Node order, mobility grouping on. Total pages: 258440 [ 0.000000] Policy zone: DMA32 [ 0.000000] Kernel command line: BOOT_IMAGE=/boot/vmlinuz-2.6.38-11-server root=UUID=992cda33-09ce-4437-b110-fe153702b2d5 ro console=ttyS0,115200n8 [ 0.000000] PID hash table entries: 4096 (order: 3, 32768 bytes) [ 0.000000] Checking aperture... [ 0.000000] No AGP bridge found [ 0.000000] Memory: 1005640k/1048576k available (6025k kernel code, 456k absent, 42480k reserved, 5023k data, 880k init) [ 0.000000] SLUB: Genslabs=15, HWalign=64, Order=0-3, MinObjects=0, CPUs=15, Nodes=1 [ 0.000000] Hierarchical RCU implementation. [ 0.000000] RCU dyntick-idle grace-period acceleration is enabled. [ 0.000000] RCU-based detection of stalled CPUs is disabled. [ 0.000000] NR_IRQS:16640 nr_irqs:1208 16 [ 0.000000] Xen HVM callback vector for event delivery is enabled [ 0.000000] Console: colour dummy device 80x25 [ 0.000000] console [ttyS0] enabled [ 0.000000] allocated 10485760 bytes of page_cgroup [ 0.000000] please try 'cgroup_disable=memory' option if you don't want memory cgroups [ 0.000000] Detected 2310.666 MHz processor. [ 0.000000] Marking TSC unstable due to TSCs unsynchronized [ 0.020000] Calibrating delay loop (skipped), value calculated using timer frequency.. 4621.33 BogoMIPS (lpj=23106660) [ 0.020000] pid_max: default: 32768 minimum: 301 [ 0.020024] Security Framework initialized [ 0.022291] AppArmor: AppArmor initialized [ 0.024463] Yama: becoming mindful. [ 0.026506] Dentry cache hash table entries: 131072 (order: 8, 1048576 bytes) [ 0.030305] Inode-cache hash table entries: 65536 (order: 7, 524288 bytes) [ 0.034139] Mount-cache hash table entries: 256 [ 0.036667] Initializing cgroup subsys ns [ 0.040007] ns_cgroup deprecated: consider using the 'clone_children' flag without the ns_cgroup. [ 0.044747] Initializing cgroup subsys cpuacct [ 0.047179] Initializing cgroup subsys memory [ 0.049484] Initializing cgroup subsys devices [ 0.050003] Initializing cgroup subsys freezer [ 0.052393] Initializing cgroup subsys net_cls [ 0.054770] Initializing cgroup subsys blkio [ 0.057180] CPU: Physical Processor ID: 0 [ 0.060003] CPU: Processor Core ID: 0 [ 0.062056] mce: CPU supports 6 MCE banks [ 0.064222] using C1E aware idle routine [ 0.072142] ACPI: Core revision 20110112 [ 0.079575] ftrace: allocating 24622 entries in 97 pages [ 0.102216] Not enabling x2apic, Intr-remapping init failed. [ 0.105311] Setting APIC routing to physical flat [ 0.112671] ..TIMER: vector=0x30 apic1=0 pin1=2 apic2=0 pin2=0 [ 0.217152] CPU0: AMD Athlon(tm) II X4 605e Processor stepping 02 [ 0.220015] installing Xen timer for CPU 0 [ 0.222242] Performance Events: Broken PMU hardware detected, using software events only. [ 0.227412] Booting Node 0, Processors #1 [ 0.020000] installing Xen timer for CPU 1 [ 0.380401] Brought up 2 CPUs [ 0.380404] Total of 2 processors activated (9270.10 BogoMIPS). [ 0.387744] devtmpfs: initialized [ 0.390895] print_constraints: dummy: [ 0.393005] Time: 9:25:05 Date: 09/06/11 [ 0.395354] NET: Registered protocol family 16 [ 0.395354] Trying to unpack rootfs image as initramfs... [ 0.395623] Extended Config Space enabled on 0 nodes [ 0.398431] ACPI: bus type pci registered [ 0.400349] PCI: Using configuration type 1 for base access [ 0.403421] PCI: Using configuration type 1 for extended access [ 0.410068] bio: create slab at 0 [ 0.416367] ACPI: Interpreter enabled [ 0.418551] ACPI: (supports S0 S3 S4 S5) [ 0.420871] ACPI: Using IOAPIC for interrupt routing [ 0.509103] ACPI: No dock devices found. [ 0.510005] HEST: Table not found. [ 0.511937] PCI: Using host bridge windows from ACPI; if necessary, use "pci=nocrs" and report a bug [ 0.516990] ACPI: PCI Root Bridge [PCI0] (domain 0000 [bus 00-ff]) [ 0.520113] pci_root PNP0A03:00: host bridge window [io 0x0000-0x0cf7] [ 0.523727] pci_root PNP0A03:00: host bridge window [io 0x0d00-0xffff] [ 0.527320] pci_root PNP0A03:00: host bridge window [mem 0x000a0000-0x000bffff] [ 0.530006] pci_root PNP0A03:00: host bridge window [mem 0xf0000000-0xfbffffff] [ 0.540005] * Found PM-Timer Bug on the chipset. Due to workarounds for a bug, [ 0.540006] * this clock source is slow. Consider trying other clock sources [ 0.549841] pci 0000:00:01.3: quirk: [io 0xb000-0xb03f] claimed by PIIX4 ACPI [ 0.566533] pci0000:00: Requesting ACPI _OSC control (0x1d) [ 0.639848] Freeing initrd memory: 12832k freed [ 0.673985] ACPI: PCI Interrupt Link [LNKA] (IRQs *5 10 11) [ 0.677573] ACPI: PCI Interrupt Link [LNKB] (IRQs 5 *10 11) [ 0.680978] ACPI: PCI Interrupt Link [LNKC] (IRQs 5 10 *11) [ 0.684523] ACPI: PCI Interrupt Link [LNKD] (IRQs *5 10 11) [ 0.688154] vgaarb: device added: PCI:0000:00:02.0,decodes=io+mem,owns=io+mem,locks=none [ 0.700007] vgaarb: loaded [ 0.701693] SCSI subsystem initialized [ 0.703782] usbcore: registered new interface driver usbfs [ 0.703782] usbcore: registered new interface driver hub [ 0.710052] usbcore: registered new device driver usb [ 0.710088] wmi: Mapper loaded [ 0.711743] PCI: Using ACPI for IRQ routing [ 0.714530] NetLabel: Initializing [ 0.716352] NetLabel: domain hash size = 128 [ 0.720010] NetLabel: protocols = UNLABELED CIPSOv4 [ 0.722734] NetLabel: unlabeled traffic allowed by default [ 0.725740] Switching to clocksource xen [ 0.727979] Switched to NOHz mode on CPU #0 [ 0.727926] Switched to NOHz mode on CPU #1 [ 0.727926] AppArmor: AppArmor Filesystem Enabled [ 0.727926] pnp: PnP ACPI init [ 0.727926] ACPI: bus type pnp registered [ 0.727926] system 00:00: [mem 0x00000000-0x0009ffff] could not be reserved [ 0.727926] system 00:02: [io 0x10c0-0x1141] has been reserved [ 0.727926] system 00:02: [io 0xb044-0xb047] has been reserved [ 0.727926] system 00:03: [io 0x08a0-0x08a3] has been reserved [ 0.727926] system 00:03: [io 0x0cc0-0x0ccf] has been reserved [ 0.727926] system 00:03: [io 0x04d0-0x04d1] has been reserved [ 0.757374] pnp: PnP ACPI: found 12 devices [ 0.757375] ACPI: ACPI bus type pnp unregistered [ 0.763422] NET: Registered protocol family 2 [ 0.763508] IP route cache hash table entries: 32768 (order: 6, 262144 bytes) [ 0.763885] TCP established hash table entries: 131072 (order: 9, 2097152 bytes) [ 0.764548] TCP bind hash table entries: 65536 (order: 8, 1048576 bytes) [ 0.764843] TCP: Hash tables configured (established 131072 bind 65536) [ 0.764845] TCP reno registered [ 0.764851] UDP hash table entries: 512 (order: 2, 16384 bytes) [ 0.764861] UDP-Lite hash table entries: 512 (order: 2, 16384 bytes) [ 0.764992] NET: Registered protocol family 1 [ 0.765002] pci 0000:00:00.0: Limiting direct PCI/PCI transfers [ 0.765085] pci 0000:00:01.0: PIIX3: Enabling Passive Release [ 0.765244] pci 0000:00:01.0: Activating ISA DMA hang workarounds [ 0.809559] audit: initializing netlink socket (disabled) [ 0.812561] type=2000 audit(1315301107.481:1): initialized [ 0.829076] HugeTLB registered 2 MB page size, pre-allocated 0 pages [ 0.834497] VFS: Disk quotas dquot_6.5.2 [ 0.836817] Dquot-cache hash table entries: 512 (order 0, 4096 bytes) [ 0.841062] fuse init (API version 7.16) [ 0.843391] msgmni has been set to 1989 [ 0.846048] Block layer SCSI generic (bsg) driver version 0.4 loaded (major 253) [ 0.850212] io scheduler noop registered [ 0.852454] io scheduler deadline registered (default) [ 0.855346] io scheduler cfq registered [ 0.857506] pci_hotplug: PCI Hot Plug PCI Core version: 0.5 [ 0.860632] pciehp: PCI Express Hot Plug Controller Driver version: 0.4 [ 0.864295] efifb: probing for efifb [ 0.866349] efifb: framebuffer at 0xf0000000, mapped to 0xffffc90000500000, using 1408k, total 1408k [ 0.871357] efifb: mode is 800x600x24, linelength=2400, pages=1 [ 0.874601] efifb: scrolling: redraw [ 0.876564] efifb: Truecolor: size=0:8:8:8, shift=0:16:8:0 [ 0.895136] Console: switching to colour frame buffer device 100x37 [ 0.913467] fb0: EFI VGA frame buffer device [ 0.915943] input: Power Button as /devices/LNXSYSTM:00/LNXPWRBN:00/input/input0 [ 0.920038] ACPI: Power Button [PWRF] [ 0.922116] input: Sleep Button as /devices/LNXSYSTM:00/LNXSLPBN:00/input/input1 [ 0.926146] ACPI: Sleep Button [SLPF] [ 0.949079] ERST: Table is not found! [ 0.951234] Serial: 8250/16550 driver, 32 ports, IRQ sharing enabled [ 0.983996] serial8250: ttyS0 at I/O 0x3f8 (irq = 4) is a 16550A [ 1.465630] 00:0a: ttyS0 at I/O 0x3f8 (irq = 4) is a 16550A [ 1.480384] Linux agpgart interface v0.103 [ 1.483727] brd: module loaded [ 1.486409] loop: module loaded [ 1.489435] i2c-core: driver [adp5520] using legacy suspend method [ 1.494724] i2c-core: driver [adp5520] using legacy resume method [ 1.501317] scsi0 : ata_piix [ 1.504296] scsi1 : ata_piix [ 1.506242] ata1: PATA max MWDMA2 cmd 0x1f0 ctl 0x3f6 bmdma 0xc200 irq 14 [ 1.509926] ata2: PATA max MWDMA2 cmd 0x170 ctl 0x376 bmdma 0xc208 irq 15 [ 1.513945] Fixed MDIO Bus: probed [ 1.517200] PPP generic driver version 2.4.2 [ 1.519624] tun: Universal TUN/TAP device driver, 1.6 [ 1.522349] tun: (C) 1999-2004 Max Krasnyansky [ 1.525792] ehci_hcd: USB 2.0 'Enhanced' Host Controller (EHCI) Driver [ 1.529353] ohci_hcd: USB 1.1 'Open' Host Controller (OHCI) Driver [ 1.532767] uhci_hcd: USB Universal Host Controller Interface driver [ 1.536328] i8042: PNP: PS/2 Controller [PNP0303:PS2K,PNP0f13:PS2M] at 0x60,0x64 irq 1,12 [ 1.542538] serio: i8042 KBD port at 0x60,0x64 irq 1 [ 1.545206] serio: i8042 AUX port at 0x60,0x64 irq 12 [ 1.548006] mousedev: PS/2 mouse device common for all mice [ 1.551810] input: AT Translated Set 2 keyboard as /devices/platform/i8042/serio0/input/input2 [ 1.557360] rtc_cmos 00:05: rtc core: registered rtc_cmos as rtc0 [ 1.560842] rtc0: alarms up to one day, 114 bytes nvram [ 1.563772] device-mapper: uevent: version 1.0.3 [ 1.566315] device-mapper: ioctl: 4.19.1-ioctl (2011-01-07) initialised: dm-devel@redhat.com [ 1.571149] device-mapper: multipath: version 1.2.0 loaded [ 1.574223] device-mapper: multipath round-robin: version 1.0.0 loaded [ 1.578250] cpuidle: using governor ladder [ 1.580578] cpuidle: using governor menu [ 1.583000] TCP cubic registered [ 1.585002] NET: Registered protocol family 10 [ 1.587989] NET: Registered protocol family 17 [ 1.590615] Registering the dns_resolver key type [ 1.593456] registered taskstats version 1 [ 1.596104] Magic number: 11:794:423 [ 1.598299] rtc_cmos 00:05: setting system clock to 2011-09-06 09:25:07 UTC (1315301107) [ 1.602821] BIOS EDD facility v0.16 2004-Jun-25, 0 devices found [ 1.606072] EDD information not available. [ 1.678095] Freeing unused kernel memory: 880k freed [ 1.686940] Write protecting the kernel read-only data: 10240k [ 1.698305] Freeing unused kernel memory: 100k freed [ 1.710489] Freeing unused kernel memory: 1416k freed Loading, please wait... [ 1.741002] <30>udev[68]: starting version 167 Begin: Loading essential drivers ... [ 1.766249] xen-platform-pci 0000:00:03.0: PCI INT A -> GSI 28 (level, low) -> IRQ 28 [ 1.770657] Grant table initialized FATAL: Error inserting xen_pcifront (/lib/modules/2.6.38-11-server/kernel/drivers/pci/xen-pcifront.ko): No such device [ 1.832332] FDC 0 is a S82078B [ 1.840990] blkfront device/vbd/51712 num-ring-pages 1 nr_ents 32. [ 1.847187] blkfront: xvda: barriers enabled [ 1.851762] Initialising Xen virtual ethernet driver. [ 1.865841] Event-channel device installed. [ 1.875819] xvda: xvda1 xvda2 < xvda5 > FATAL: Error inserting xen_fbfront (/lib/modules/2.6.38-11-server/kernel/drivers/video/xen-fbfront.ko): No such device done. Begin: Running /scripts/init-premount ... done. Begin: Mounting root file system ... Begin: Running /scripts/local-top ... done. Begin: Running /scripts/local-premount ... done. [ 2.116143] EXT4-fs (xvda1): mounted filesystem with ordered data mode. Opts: (null) Begin: Running /scripts/local-bottom ... done. done. Begin: Running /scripts/init-bottom ... done. fsck from util-linux-ng 2.17.2 [ 6.235023] piix4_smbus 0000:00:01.3: SMBus base address uninitialized - upgrade BIOS or use force_addr=0xaddr [ 6.624385] [fglrx:firegl_init_device_list] *ERROR* No supported display adapters were found [ 6.629300] [fglrx:firegl_init_module] *ERROR* firegl_init_devices failed /dev/xvda1: sauber, 238123/589824 Dateien, 1251602/2359040 Blöcke Skipping profile in /etc/apparmor.d/disable: usr.bin.firefox * Starting AppArmor profiles [ OK ] Starting AirVideo fsck from util-linux-ng 2.17.2 /dev/xvda1: sauber, 238123/589824 Dateien, 1251602/2359040 Blöcke Skipping profile in /etc/apparmor.d/disable: usr.bin.firefox * Starting AppArmor profiles [ OK ] Starting AirVideo * Exporting directories for NFS kernel daemon... [ OK ] * Starting NFS kernel daemon [ OK ] speech-dispatcher disabled; edit /etc/default/speech-dispatcher * Starting bluetooth [ OK ] * PulseAudio configured for per-user sessions saned disabled; edit /etc/default/saned * Enabling additional executable binary formats binfmt-support [ OK ] * Checking battery state... [ OK ] --------------050404030308050904030304 Content-Type: text/plain; name="2-Natty-not-working-with-passthrough" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="2-Natty-not-working-with-passthrough" eG0gY3JlYXRlIHVidW50dS1tZWRpYWNlbnRlci5jZmcgLWMKVXNpbmcgY29uZmlnIGZpbGUg Ii4vdWJ1bnR1LW1lZGlhY2VudGVyLmNmZyIuClN0YXJ0ZWQgZG9tYWluIHVidW50dS1tZWRp YWNlbnRlciAoaWQ9OSkKICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg IFsgICAgMC4wMDAwMDBdIEluaXRpYWxpemluZyBjZ3JvdXAgc3Vic3lzIGNwdXNldApbICAg IDAuMDAwMDAwXSBJbml0aWFsaXppbmcgY2dyb3VwIHN1YnN5cyBjcHUKWyAgICAwLjAwMDAw MF0gTGludXggdmVyc2lvbiAyLjYuMzgtMTEtc2VydmVyIChidWlsZGRAYWxsc3BpY2UpIChn Y2MgdmVyc2lvbiA0LjUuMiAoVWJ1bnR1L0xpbmFybyA0LjUuMi04dWJ1bnR1NCkgKSAjNDgt VWJ1bnR1IFNNUCBGcmkgSnVsIDI5IDE5OjIwOjMyIFVUQyAyMDExIChVYnVudHUgMi42LjM4 LTExLjQ4LXNlcnZlciAyLjYuMzguOCkKWyAgICAwLjAwMDAwMF0gQ29tbWFuZCBsaW5lOiBC T09UX0lNQUdFPS9ib290L3ZtbGludXotMi42LjM4LTExLXNlcnZlciByb290PVVVSUQ9OTky Y2RhMzMtMDljZS00NDM3LWIxMTAtZmUxNTM3MDJiMmQ1IHJvIGNvbnNvbGU9dHR5UzAsMTE1 MjAwbjgKWyAgICAwLjAwMDAwMF0gQklPUy1wcm92aWRlZCBwaHlzaWNhbCBSQU0gbWFwOgpb ICAgIDAuMDAwMDAwXSAgQklPUy1lODIwOiAwMDAwMDAwMDAwMDAwMDAwIC0gMDAwMDAwMDAw MDA5ZTAwMCAodXNhYmxlKQpbICAgIDAuMDAwMDAwXSAgQklPUy1lODIwOiAwMDAwMDAwMDAw MDllMDAwIC0gMDAwMDAwMDAwMDBhMDAwMCAocmVzZXJ2ZWQpClsgICAgMC4wMDAwMDBdICBC SU9TLWU4MjA6IDAwMDAwMDAwMDAwZTAwMDAgLSAwMDAwMDAwMDAwMTAwMDAwIChyZXNlcnZl ZCkKWyAgICAwLjAwMDAwMF0gIEJJT1MtZTgyMDogMDAwMDAwMDAwMDEwMDAwMCAtIDAwMDAw MDAwNDAwMDAwMDAgKHVzYWJsZSkKWyAgICAwLjAwMDAwMF0gIEJJT1MtZTgyMDogMDAwMDAw MDBmYzAwMDAwMCAtIDAwMDAwMDAxMDAwMDAwMDAgKHJlc2VydmVkKQpbICAgIDAuMDAwMDAw XSBOWCAoRXhlY3V0ZSBEaXNhYmxlKSBwcm90ZWN0aW9uOiBhY3RpdmUKWyAgICAwLjAwMDAw MF0gRE1JIDIuNCBwcmVzZW50LgpbICAgIDAuMDAwMDAwXSBIeXBlcnZpc29yIGRldGVjdGVk OiBYZW4gSFZNClsgICAgMC4wMDAwMDBdIFhlbiB2ZXJzaW9uIDQuMS4KWyAgICAwLjAwMDAw MF0gTmV0ZnJvbnQgYW5kIHRoZSBYZW4gcGxhdGZvcm0gUENJIGRyaXZlciBoYXZlIGJlZW4g Y29tcGlsZWQgZm9yIHRoaXMga2VybmVsOiB1bnBsdWcgZW11bGF0ZWQgTklDcy4KWyAgICAw LjAwMDAwMF0gQmxrZnJvbnQgYW5kIHRoZSBYZW4gcGxhdGZvcm0gUENJIGRyaXZlciBoYXZl IGJlZW4gY29tcGlsZWQgZm9yIHRoaXMga2VybmVsOiB1bnBsdWcgZW11bGF0ZWQgZGlza3Mu ClsgICAgMC4wMDAwMDBdIFlvdSBtaWdodCBoYXZlIHRvIGNoYW5nZSB0aGUgcm9vdCBkZXZp Y2UKWyAgICAwLjAwMDAwMF0gZnJvbSAvZGV2L2hkW2EtZF0gdG8gL2Rldi94dmRbYS1kXQpb ICAgIDAuMDAwMDAwXSBpbiB5b3VyIHJvb3Q9IGtlcm5lbCBjb21tYW5kIGxpbmUgb3B0aW9u ClsgICAgMC4wMDAwMDBdIE5vIEFHUCBicmlkZ2UgZm91bmQKWyAgICAwLjAwMDAwMF0gbGFz dF9wZm4gPSAweDQwMDAwIG1heF9hcmNoX3BmbiA9IDB4NDAwMDAwMDAwClsgICAgMC4wMDAw MDBdIHg4NiBQQVQgZW5hYmxlZDogY3B1IDAsIG9sZCAweDcwNDA2MDAwNzA0MDYsIG5ldyAw eDcwMTA2MDAwNzAxMDYKWyAgICAwLjAwMDAwMF0gZm91bmQgU01QIE1QLXRhYmxlIGF0IFtm ZmZmODgwMDAwMGZiYzkwXSBmYmM5MApbICAgIDAuMDAwMDAwXSBpbml0X21lbW9yeV9tYXBw aW5nOiAwMDAwMDAwMDAwMDAwMDAwLTAwMDAwMDAwNDAwMDAwMDAKWyAgICAwLjAwMDAwMF0g UkFNRElTSzogMzY2ZTAwMDAgLSAzNzM2ODAwMApbICAgIDAuMDAwMDAwXSBBQ1BJOiBSU0RQ IDAwMDAwMDAwMDAwZWEwMjAgMDAwMjQgKHYwMiAgICBYZW4pClsgICAgMC4wMDAwMDBdIEFD UEk6IFhTRFQgMDAwMDAwMDBmYzAxMzRiMCAwMDAzNCAodjAxICAgIFhlbiAgICAgIEhWTSAw MDAwMDAwMCBIVk1MIDAwMDAwMDAwKQpbICAgIDAuMDAwMDAwXSBBQ1BJOiBGQUNQIDAwMDAw MDAwZmMwMTMyZDAgMDAwRjQgKHYwNCAgICBYZW4gICAgICBIVk0gMDAwMDAwMDAgSFZNTCAw MDAwMDAwMCkKWyAgICAwLjAwMDAwMF0gQUNQSTogRFNEVCAwMDAwMDAwMGZjMDAzNDQwIDBG RTA1ICh2MDIgICAgWGVuICAgICAgSFZNIDAwMDAwMDAwIElOVEwgMjAxMDA1MjgpClsgICAg MC4wMDAwMDBdIEFDUEk6IEZBQ1MgMDAwMDAwMDBmYzAwMzQwMCAwMDA0MApbICAgIDAuMDAw MDAwXSBBQ1BJOiBBUElDIDAwMDAwMDAwZmMwMTMzZDAgMDAwRDggKHYwMiAgICBYZW4gICAg ICBIVk0gMDAwMDAwMDAgSFZNTCAwMDAwMDAwMCkKWyAgICAwLjAwMDAwMF0gTm8gTlVNQSBj b25maWd1cmF0aW9uIGZvdW5kClsgICAgMC4wMDAwMDBdIEZha2luZyBhIG5vZGUgYXQgMDAw MDAwMDAwMDAwMDAwMC0wMDAwMDAwMDQwMDAwMDAwClsgICAgMC4wMDAwMDBdIEluaXRtZW0g c2V0dXAgbm9kZSAwIDAwMDAwMDAwMDAwMDAwMDAtMDAwMDAwMDA0MDAwMDAwMApbICAgIDAu MDAwMDAwXSAgIE5PREVfREFUQSBbMDAwMDAwMDAzZmZmYjAwMCAtIDAwMDAwMDAwM2ZmZmZm ZmZdClsgICAgMC4wMDAwMDBdIFpvbmUgUEZOIHJhbmdlczoKWyAgICAwLjAwMDAwMF0gICBE TUEgICAgICAweDAwMDAwMDEwIC0+IDB4MDAwMDEwMDAKWyAgICAwLjAwMDAwMF0gICBETUEz MiAgICAweDAwMDAxMDAwIC0+IDB4MDAxMDAwMDAKWyAgICAwLjAwMDAwMF0gICBOb3JtYWwg ICBlbXB0eQpbICAgIDAuMDAwMDAwXSBNb3ZhYmxlIHpvbmUgc3RhcnQgUEZOIGZvciBlYWNo IG5vZGUKWyAgICAwLjAwMDAwMF0gZWFybHlfbm9kZV9tYXBbMl0gYWN0aXZlIFBGTiByYW5n ZXMKWyAgICAwLjAwMDAwMF0gICAgIDA6IDB4MDAwMDAwMTAgLT4gMHgwMDAwMDA5ZQpbICAg IDAuMDAwMDAwXSAgICAgMDogMHgwMDAwMDEwMCAtPiAweDAwMDQwMDAwClsgICAgMC4wMDAw MDBdIEFDUEk6IFBNLVRpbWVyIElPIFBvcnQ6IDB4YjAwOApbICAgIDAuMDAwMDAwXSBBQ1BJ OiBMQVBJQyAoYWNwaV9pZFsweDAwXSBsYXBpY19pZFsweDAwXSBlbmFibGVkKQpbICAgIDAu MDAwMDAwXSBBQ1BJOiBMQVBJQyAoYWNwaV9pZFsweDAxXSBsYXBpY19pZFsweDAyXSBlbmFi bGVkKQpbICAgIDAuMDAwMDAwXSBBQ1BJOiBMQVBJQyAoYWNwaV9pZFsweDAyXSBsYXBpY19p ZFsweDA0XSBkaXNhYmxlZCkKWyAgICAwLjAwMDAwMF0gQUNQSTogTEFQSUMgKGFjcGlfaWRb MHgwM10gbGFwaWNfaWRbMHgwNl0gZGlzYWJsZWQpClsgICAgMC4wMDAwMDBdIEFDUEk6IExB UElDIChhY3BpX2lkWzB4MDRdIGxhcGljX2lkWzB4MDhdIGRpc2FibGVkKQpbICAgIDAuMDAw MDAwXSBBQ1BJOiBMQVBJQyAoYWNwaV9pZFsweDA1XSBsYXBpY19pZFsweDBhXSBkaXNhYmxl ZCkKWyAgICAwLjAwMDAwMF0gQUNQSTogTEFQSUMgKGFjcGlfaWRbMHgwNl0gbGFwaWNfaWRb MHgwY10gZGlzYWJsZWQpClsgICAgMC4wMDAwMDBdIEFDUEk6IExBUElDIChhY3BpX2lkWzB4 MDddIGxhcGljX2lkWzB4MGVdIGRpc2FibGVkKQpbICAgIDAuMDAwMDAwXSBBQ1BJOiBMQVBJ QyAoYWNwaV9pZFsweDA4XSBsYXBpY19pZFsweDEwXSBkaXNhYmxlZCkKWyAgICAwLjAwMDAw MF0gQUNQSTogTEFQSUMgKGFjcGlfaWRbMHgwOV0gbGFwaWNfaWRbMHgxMl0gZGlzYWJsZWQp ClsgICAgMC4wMDAwMDBdIEFDUEk6IExBUElDIChhY3BpX2lkWzB4MGFdIGxhcGljX2lkWzB4 MTRdIGRpc2FibGVkKQpbICAgIDAuMDAwMDAwXSBBQ1BJOiBMQVBJQyAoYWNwaV9pZFsweDBi XSBsYXBpY19pZFsweDE2XSBkaXNhYmxlZCkKWyAgICAwLjAwMDAwMF0gQUNQSTogTEFQSUMg KGFjcGlfaWRbMHgwY10gbGFwaWNfaWRbMHgxOF0gZGlzYWJsZWQpClsgICAgMC4wMDAwMDBd IEFDUEk6IExBUElDIChhY3BpX2lkWzB4MGRdIGxhcGljX2lkWzB4MWFdIGRpc2FibGVkKQpb ICAgIDAuMDAwMDAwXSBBQ1BJOiBMQVBJQyAoYWNwaV9pZFsweDBlXSBsYXBpY19pZFsweDFj XSBkaXNhYmxlZCkKWyAgICAwLjAwMDAwMF0gQUNQSTogSU9BUElDIChpZFsweDAxXSBhZGRy ZXNzWzB4ZmVjMDAwMDBdIGdzaV9iYXNlWzBdKQpbICAgIDAuMDAwMDAwXSBJT0FQSUNbMF06 IGFwaWNfaWQgMSwgdmVyc2lvbiAxNywgYWRkcmVzcyAweGZlYzAwMDAwLCBHU0kgMC00Nwpb ICAgIDAuMDAwMDAwXSBBQ1BJOiBJTlRfU1JDX09WUiAoYnVzIDAgYnVzX2lycSAwIGdsb2Jh bF9pcnEgMiBkZmwgZGZsKQpbICAgIDAuMDAwMDAwXSBBQ1BJOiBJTlRfU1JDX09WUiAoYnVz IDAgYnVzX2lycSA1IGdsb2JhbF9pcnEgNSBsb3cgbGV2ZWwpClsgICAgMC4wMDAwMDBdIEFD UEk6IElOVF9TUkNfT1ZSIChidXMgMCBidXNfaXJxIDEwIGdsb2JhbF9pcnEgMTAgbG93IGxl dmVsKQpbICAgIDAuMDAwMDAwXSBBQ1BJOiBJTlRfU1JDX09WUiAoYnVzIDAgYnVzX2lycSAx MSBnbG9iYWxfaXJxIDExIGxvdyBsZXZlbCkKWyAgICAwLjAwMDAwMF0gVXNpbmcgQUNQSSAo TUFEVCkgZm9yIFNNUCBjb25maWd1cmF0aW9uIGluZm9ybWF0aW9uClsgICAgMC4wMDAwMDBd IFNNUDogQWxsb3dpbmcgMTUgQ1BVcywgMTMgaG90cGx1ZyBDUFVzClsgICAgMC4wMDAwMDBd IFBNOiBSZWdpc3RlcmVkIG5vc2F2ZSBtZW1vcnk6IDAwMDAwMDAwMDAwOWUwMDAgLSAwMDAw MDAwMDAwMGEwMDAwClsgICAgMC4wMDAwMDBdIFBNOiBSZWdpc3RlcmVkIG5vc2F2ZSBtZW1v cnk6IDAwMDAwMDAwMDAwYTAwMDAgLSAwMDAwMDAwMDAwMGUwMDAwClsgICAgMC4wMDAwMDBd IFBNOiBSZWdpc3RlcmVkIG5vc2F2ZSBtZW1vcnk6IDAwMDAwMDAwMDAwZTAwMDAgLSAwMDAw MDAwMDAwMTAwMDAwClsgICAgMC4wMDAwMDBdIEFsbG9jYXRpbmcgUENJIHJlc291cmNlcyBz dGFydGluZyBhdCA0MDAwMDAwMCAoZ2FwOiA0MDAwMDAwMDpiYzAwMDAwMCkKWyAgICAwLjAw MDAwMF0gQm9vdGluZyBwYXJhdmlydHVhbGl6ZWQga2VybmVsIG9uIFhlbgpbICAgIDAuMDAw MDAwXSBzZXR1cF9wZXJjcHU6IE5SX0NQVVM6MjU2IG5yX2NwdW1hc2tfYml0czoyNTYgbnJf Y3B1X2lkczoxNSBucl9ub2RlX2lkczoxClsgICAgMC4wMDAwMDBdIFBFUkNQVTogRW1iZWRk ZWQgMjggcGFnZXMvY3B1IEBmZmZmODgwMDNmYzAwMDAwIHM4NDQxNiByODE5MiBkMjIwODAg dTEzMTA3MgpbICAgIDAuMDAwMDAwXSBCdWlsdCAxIHpvbmVsaXN0cyBpbiBOb2RlIG9yZGVy LCBtb2JpbGl0eSBncm91cGluZyBvbi4gIFRvdGFsIHBhZ2VzOiAyNTg0NDAKWyAgICAwLjAw MDAwMF0gUG9saWN5IHpvbmU6IERNQTMyClsgICAgMC4wMDAwMDBdIEtlcm5lbCBjb21tYW5k IGxpbmU6IEJPT1RfSU1BR0U9L2Jvb3Qvdm1saW51ei0yLjYuMzgtMTEtc2VydmVyIHJvb3Q9 VVVJRD05OTJjZGEzMy0wOWNlLTQ0MzctYjExMC1mZTE1MzcwMmIyZDUgcm8gY29uc29sZT10 dHlTMCwxMTUyMDBuOApbICAgIDAuMDAwMDAwXSBQSUQgaGFzaCB0YWJsZSBlbnRyaWVzOiA0 MDk2IChvcmRlcjogMywgMzI3NjggYnl0ZXMpClsgICAgMC4wMDAwMDBdIENoZWNraW5nIGFw ZXJ0dXJlLi4uClsgICAgMC4wMDAwMDBdIE5vIEFHUCBicmlkZ2UgZm91bmQKWyAgICAwLjAw MDAwMF0gTWVtb3J5OiAxMDA1NjQway8xMDQ4NTc2ayBhdmFpbGFibGUgKDYwMjVrIGtlcm5l bCBjb2RlLCA0NTZrIGFic2VudCwgNDI0ODBrIHJlc2VydmVkLCA1MDIzayBkYXRhLCA4ODBr IGluaXQpClsgICAgMC4wMDAwMDBdIFNMVUI6IEdlbnNsYWJzPTE1LCBIV2FsaWduPTY0LCBP cmRlcj0wLTMsIE1pbk9iamVjdHM9MCwgQ1BVcz0xNSwgTm9kZXM9MQpbICAgIDAuMDAwMDAw XSBIaWVyYXJjaGljYWwgUkNVIGltcGxlbWVudGF0aW9uLgpbICAgIDAuMDAwMDAwXSAgUkNV IGR5bnRpY2staWRsZSBncmFjZS1wZXJpb2QgYWNjZWxlcmF0aW9uIGlzIGVuYWJsZWQuClsg ICAgMC4wMDAwMDBdICBSQ1UtYmFzZWQgZGV0ZWN0aW9uIG9mIHN0YWxsZWQgQ1BVcyBpcyBk aXNhYmxlZC4KWyAgICAwLjAwMDAwMF0gTlJfSVJRUzoxNjY0MCBucl9pcnFzOjEyMDggMTYK WyAgICAwLjAwMDAwMF0gWGVuIEhWTSBjYWxsYmFjayB2ZWN0b3IgZm9yIGV2ZW50IGRlbGl2 ZXJ5IGlzIGVuYWJsZWQKWyAgICAwLjAwMDAwMF0gQ29uc29sZTogY29sb3VyIGR1bW15IGRl dmljZSA4MHgyNQpbICAgIDAuMDAwMDAwXSBjb25zb2xlIFt0dHlTMF0gZW5hYmxlZApbICAg IDAuMDAwMDAwXSBhbGxvY2F0ZWQgMTA0ODU3NjAgYnl0ZXMgb2YgcGFnZV9jZ3JvdXAKWyAg ICAwLjAwMDAwMF0gcGxlYXNlIHRyeSAnY2dyb3VwX2Rpc2FibGU9bWVtb3J5JyBvcHRpb24g aWYgeW91IGRvbid0IHdhbnQgbWVtb3J5IGNncm91cHMKWyAgICAwLjAwMDAwMF0gRGV0ZWN0 ZWQgMjMxMC42NjYgTUh6IHByb2Nlc3Nvci4KWyAgICAwLjAwMDAwMF0gTWFya2luZyBUU0Mg dW5zdGFibGUgZHVlIHRvIFRTQ3MgdW5zeW5jaHJvbml6ZWQKWyAgICAwLjAyMDAwMF0gQ2Fs aWJyYXRpbmcgZGVsYXkgbG9vcCAoc2tpcHBlZCksIHZhbHVlIGNhbGN1bGF0ZWQgdXNpbmcg dGltZXIgZnJlcXVlbmN5Li4gNDYyMS4zMyBCb2dvTUlQUyAobHBqPTIzMTA2NjYwKQpbICAg IDAuMDIwMDAwXSBwaWRfbWF4OiBkZWZhdWx0OiAzMjc2OCBtaW5pbXVtOiAzMDEKWyAgICAw LjAyMDAwMF0gU2VjdXJpdHkgRnJhbWV3b3JrIGluaXRpYWxpemVkClsgICAgMC4wMjAwMjdd IEFwcEFybW9yOiBBcHBBcm1vciBpbml0aWFsaXplZApbICAgIDAuMDIyNDA2XSBZYW1hOiBi ZWNvbWluZyBtaW5kZnVsLgpbICAgIDAuMDI0NTg3XSBEZW50cnkgY2FjaGUgaGFzaCB0YWJs ZSBlbnRyaWVzOiAxMzEwNzIgKG9yZGVyOiA4LCAxMDQ4NTc2IGJ5dGVzKQpbICAgIDAuMDI4 NzQ2XSBJbm9kZS1jYWNoZSBoYXNoIHRhYmxlIGVudHJpZXM6IDY1NTM2IChvcmRlcjogNywg NTI0Mjg4IGJ5dGVzKQpbICAgIDAuMDMwMTUxXSBNb3VudC1jYWNoZSBoYXNoIHRhYmxlIGVu dHJpZXM6IDI1NgpbICAgIDAuMDMyNzc2XSBJbml0aWFsaXppbmcgY2dyb3VwIHN1YnN5cyBu cwpbICAgIDAuMDM1MDUwXSBuc19jZ3JvdXAgZGVwcmVjYXRlZDogY29uc2lkZXIgdXNpbmcg dGhlICdjbG9uZV9jaGlsZHJlbicgZmxhZyB3aXRob3V0IHRoZSBuc19jZ3JvdXAuClsgICAg MC4wNDAwMDVdIEluaXRpYWxpemluZyBjZ3JvdXAgc3Vic3lzIGNwdWFjY3QKWyAgICAwLjA0 MjQ5OF0gSW5pdGlhbGl6aW5nIGNncm91cCBzdWJzeXMgbWVtb3J5ClsgICAgMC4wNDQ4OTJd IEluaXRpYWxpemluZyBjZ3JvdXAgc3Vic3lzIGRldmljZXMKWyAgICAwLjA1MDAwM10gSW5p dGlhbGl6aW5nIGNncm91cCBzdWJzeXMgZnJlZXplcgpbICAgIDAuMDUyNDUxXSBJbml0aWFs aXppbmcgY2dyb3VwIHN1YnN5cyBuZXRfY2xzClsgICAgMC4wNTQ4NjZdIEluaXRpYWxpemlu ZyBjZ3JvdXAgc3Vic3lzIGJsa2lvClsgICAgMC4wNTczNDVdIENQVTogUGh5c2ljYWwgUHJv Y2Vzc29yIElEOiAwClsgICAgMC4wNjAwMDNdIENQVTogUHJvY2Vzc29yIENvcmUgSUQ6IDAK WyAgICAwLjA2MjA2OV0gbWNlOiBDUFUgc3VwcG9ydHMgNiBNQ0UgYmFua3MKWyAgICAwLjA2 NDM4MV0gdXNpbmcgQzFFIGF3YXJlIGlkbGUgcm91dGluZQpbICAgIDAuMDcxMjgyXSBBQ1BJ OiBDb3JlIHJldmlzaW9uIDIwMTEwMTEyClsgICAgMC4wNzg3NTNdIGZ0cmFjZTogYWxsb2Nh dGluZyAyNDYyMiBlbnRyaWVzIGluIDk3IHBhZ2VzClsgICAgMC4xMDIwMjVdIE5vdCBlbmFi bGluZyB4MmFwaWMsIEludHItcmVtYXBwaW5nIGluaXQgZmFpbGVkLgpbICAgIDAuMTA1MTky XSBTZXR0aW5nIEFQSUMgcm91dGluZyB0byBwaHlzaWNhbCBmbGF0ClsgICAgMC4xMTI0NzJd IC4uVElNRVI6IHZlY3Rvcj0weDMwIGFwaWMxPTAgcGluMT0yIGFwaWMyPTAgcGluMj0wClsg ICAgMC4yMTU4NzhdIENQVTA6IEFNRCBBdGhsb24odG0pIElJIFg0IDYwNWUgUHJvY2Vzc29y IHN0ZXBwaW5nIDAyClsgICAgMC4yMTk0OThdIGluc3RhbGxpbmcgWGVuIHRpbWVyIGZvciBD UFUgMApbICAgIDAuMjIwMDM5XSBQZXJmb3JtYW5jZSBFdmVudHM6IEJyb2tlbiBQTVUgaGFy ZHdhcmUgZGV0ZWN0ZWQsIHVzaW5nIHNvZnR3YXJlIGV2ZW50cyBvbmx5LgpbICAgIDAuMjI1 Mjg5XSBCb290aW5nIE5vZGUgICAwLCBQcm9jZXNzb3JzICAjMQpbICAgIDAuMDIwMDAwXSBp bnN0YWxsaW5nIFhlbiB0aW1lciBmb3IgQ1BVIDEKWyAgICAwLjM4MDMwMV0gQnJvdWdodCB1 cCAyIENQVXMKWyAgICAwLjM4MDMwNF0gVG90YWwgb2YgMiBwcm9jZXNzb3JzIGFjdGl2YXRl ZCAoOTI3MC4xNCBCb2dvTUlQUykuClsgICAgMC4zODgwNTJdIGRldnRtcGZzOiBpbml0aWFs aXplZApbICAgIDAuMzkxMDc1XSBwcmludF9jb25zdHJhaW50czogZHVtbXk6IApbICAgIDAu MzkzMTI5XSBUaW1lOiAgOToyNzoyNyAgRGF0ZTogMDkvMDYvMTEKWyAgICAwLjM5NTQxN10g TkVUOiBSZWdpc3RlcmVkIHByb3RvY29sIGZhbWlseSAxNgpbICAgIDAuMzk1NDE3XSBUcnlp bmcgdG8gdW5wYWNrIHJvb3RmcyBpbWFnZSBhcyBpbml0cmFtZnMuLi4KWyAgICAwLjQxMjk1 MV0gRXh0ZW5kZWQgQ29uZmlnIFNwYWNlIGVuYWJsZWQgb24gMCBub2RlcwpbICAgIDAuNDE1 ODU1XSBBQ1BJOiBidXMgdHlwZSBwY2kgcmVnaXN0ZXJlZApbICAgIDAuNDE4NDIxXSBQQ0k6 IFVzaW5nIGNvbmZpZ3VyYXRpb24gdHlwZSAxIGZvciBiYXNlIGFjY2VzcwpbICAgIDAuNDIw MDEzXSBQQ0k6IFVzaW5nIGNvbmZpZ3VyYXRpb24gdHlwZSAxIGZvciBleHRlbmRlZCBhY2Nl c3MKWyAgICAwLjQyNDA4M10gYmlvOiBjcmVhdGUgc2xhYiA8YmlvLTA+IGF0IDAKWyAgICAw LjQzMzEzMV0gQUNQSTogSW50ZXJwcmV0ZXIgZW5hYmxlZApbICAgIDAuNDM1MjkyXSBBQ1BJ OiAoc3VwcG9ydHMgUzAgUzMgUzQgUzUpClsgICAgMC40Mzc3OTVdIEFDUEk6IFVzaW5nIElP QVBJQyBmb3IgaW50ZXJydXB0IHJvdXRpbmcKWyAgICAwLjUyMDczMl0gQUNQSTogTm8gZG9j ayBkZXZpY2VzIGZvdW5kLgpbICAgIDAuNTIyOTQ1XSBIRVNUOiBUYWJsZSBub3QgZm91bmQu ClsgICAgMC41MjQ4MjldIFBDSTogVXNpbmcgaG9zdCBicmlkZ2Ugd2luZG93cyBmcm9tIEFD UEk7IGlmIG5lY2Vzc2FyeSwgdXNlICJwY2k9bm9jcnMiIGFuZCByZXBvcnQgYSBidWcKWyAg ICAwLjUyOTk2NF0gQUNQSTogUENJIFJvb3QgQnJpZGdlIFtQQ0kwXSAoZG9tYWluIDAwMDAg W2J1cyAwMC1mZl0pClsgICAgMC41MzAxOTFdIHBjaV9yb290IFBOUDBBMDM6MDA6IGhvc3Qg YnJpZGdlIHdpbmRvdyBbaW8gIDB4MDAwMC0weDBjZjddClsgICAgMC41MzM4NDNdIHBjaV9y b290IFBOUDBBMDM6MDA6IGhvc3QgYnJpZGdlIHdpbmRvdyBbaW8gIDB4MGQwMC0weGZmZmZd ClsgICAgMC41Mzc1NDFdIHBjaV9yb290IFBOUDBBMDM6MDA6IGhvc3QgYnJpZGdlIHdpbmRv dyBbbWVtIDB4MDAwYTAwMDAtMHgwMDBiZmZmZl0KWyAgICAwLjU0MDAxNl0gcGNpX3Jvb3Qg UE5QMEEwMzowMDogaG9zdCBicmlkZ2Ugd2luZG93IFttZW0gMHhlMDAwMDAwMC0weGZiZmZm ZmZmXQpbICAgIDAuNTUwMTk5XSAqIEZvdW5kIFBNLVRpbWVyIEJ1ZyBvbiB0aGUgY2hpcHNl dC4gRHVlIHRvIHdvcmthcm91bmRzIGZvciBhIGJ1ZywKWyAgICAwLjU1MDIwMF0gKiB0aGlz IGNsb2NrIHNvdXJjZSBpcyBzbG93LiBDb25zaWRlciB0cnlpbmcgb3RoZXIgY2xvY2sgc291 cmNlcwpbICAgIDAuNTU5OTkwXSBwY2kgMDAwMDowMDowMS4zOiBxdWlyazogW2lvICAweGIw MDAtMHhiMDNmXSBjbGFpbWVkIGJ5IFBJSVg0IEFDUEkKWyAgICAwLjU3Njg4MV0gRnJlZWlu ZyBpbml0cmQgbWVtb3J5OiAxMjgzMmsgZnJlZWQKWyAgICAwLjY3Nzk4Nl0gIHBjaTAwMDA6 MDA6IFJlcXVlc3RpbmcgQUNQSSBfT1NDIGNvbnRyb2wgKDB4MWQpClsgICAgMC44OTM4OTFd IEFDUEk6IFBDSSBJbnRlcnJ1cHQgTGluayBbTE5LQV0gKElSUXMgKjUgMTAgMTEpClsgICAg MC44OTc1NzFdIEFDUEk6IFBDSSBJbnRlcnJ1cHQgTGluayBbTE5LQl0gKElSUXMgNSAqMTAg MTEpClsgICAgMC45MDA5NjJdIEFDUEk6IFBDSSBJbnRlcnJ1cHQgTGluayBbTE5LQ10gKElS UXMgNSAxMCAqMTEpClsgICAgMC45MDQ0ODldIEFDUEk6IFBDSSBJbnRlcnJ1cHQgTGluayBb TE5LRF0gKElSUXMgKjUgMTAgMTEpClsgICAgMC45MDgxMTJdIHZnYWFyYjogZGV2aWNlIGFk ZGVkOiBQQ0k6MDAwMDowMDowMi4wLGRlY29kZXM9aW8rbWVtLG93bnM9aW8rbWVtLGxvY2tz PW5vbmUKWyAgICAwLjkxMDA5OV0gdmdhYXJiOiBkZXZpY2UgYWRkZWQ6IFBDSTowMDAwOjAw OjA4LjAsZGVjb2Rlcz1pbyttZW0sb3ducz1pbyttZW0sbG9ja3M9bm9uZQpbICAgIDAuOTE0 NDYyXSB2Z2FhcmI6IGxvYWRlZApbICAgIDAuOTE2MTE2XSBTQ1NJIHN1YnN5c3RlbSBpbml0 aWFsaXplZApbICAgIDAuOTE4MjE2XSB1c2Jjb3JlOiByZWdpc3RlcmVkIG5ldyBpbnRlcmZh Y2UgZHJpdmVyIHVzYmZzClsgICAgMC45MTgyMTZdIHVzYmNvcmU6IHJlZ2lzdGVyZWQgbmV3 IGludGVyZmFjZSBkcml2ZXIgaHViClsgICAgMC45MjAwNTNdIHVzYmNvcmU6IHJlZ2lzdGVy ZWQgbmV3IGRldmljZSBkcml2ZXIgdXNiClsgICAgMC45MjI4MzldIHdtaTogTWFwcGVyIGxv YWRlZApbICAgIDAuOTIyODM5XSBQQ0k6IFVzaW5nIEFDUEkgZm9yIElSUSByb3V0aW5nClsg ICAgMC45MjM0NDJdIE5ldExhYmVsOiBJbml0aWFsaXppbmcKWyAgICAwLjkyNTMwOF0gTmV0 TGFiZWw6ICBkb21haW4gaGFzaCBzaXplID0gMTI4ClsgICAgMC45Mjc2MzhdIE5ldExhYmVs OiAgcHJvdG9jb2xzID0gVU5MQUJFTEVEIENJUFNPdjQKWyAgICAwLjkzMDAxNF0gTmV0TGFi ZWw6ICB1bmxhYmVsZWQgdHJhZmZpYyBhbGxvd2VkIGJ5IGRlZmF1bHQKWyAgICAwLjkzMzA2 M10gU3dpdGNoaW5nIHRvIGNsb2Nrc291cmNlIHhlbgpbICAgIDAuOTQ0ODczXSBTd2l0Y2hl ZCB0byBOT0h6IG1vZGUgb24gQ1BVICMxClsgICAgMC45NDU2MTFdIFN3aXRjaGVkIHRvIE5P SHogbW9kZSBvbiBDUFUgIzAKWyAgICAwLjk1MDM3OF0gQXBwQXJtb3I6IEFwcEFybW9yIEZp bGVzeXN0ZW0gRW5hYmxlZApbICAgIDAuOTUyOTIzXSBwbnA6IFBuUCBBQ1BJIGluaXQKWyAg ICAwLjk1NDY3N10gQUNQSTogYnVzIHR5cGUgcG5wIHJlZ2lzdGVyZWQKWyAgICAwLjk1Njg5 NV0gc3lzdGVtIDAwOjAwOiBbbWVtIDB4MDAwMDAwMDAtMHgwMDA5ZmZmZl0gY291bGQgbm90 IGJlIHJlc2VydmVkClsgICAgMC45NjA4MDRdIHN5c3RlbSAwMDowMjogW2lvICAweDEwYzAt MHgxMTQxXSBoYXMgYmVlbiByZXNlcnZlZApbICAgIDAuOTYzOTg5XSBzeXN0ZW0gMDA6MDI6 IFtpbyAgMHhiMDQ0LTB4YjA0N10gaGFzIGJlZW4gcmVzZXJ2ZWQKWyAgICAwLjk2NzI2OV0g c3lzdGVtIDAwOjAzOiBbaW8gIDB4MDhhMC0weDA4YTNdIGhhcyBiZWVuIHJlc2VydmVkClsg ICAgMC45NzA0NzFdIHN5c3RlbSAwMDowMzogW2lvICAweDBjYzAtMHgwY2NmXSBoYXMgYmVl biByZXNlcnZlZApbICAgIDAuOTczNjgxXSBzeXN0ZW0gMDA6MDM6IFtpbyAgMHgwNGQwLTB4 MDRkMV0gaGFzIGJlZW4gcmVzZXJ2ZWQKWyAgICAwLjk3NzIxMV0geGVuIG1hcCBpcnEgZmFp bGVkIC0yMgpbICAgIDAuOTc5MTYwXSB4ZW4gbWFwIGlycSBmYWlsZWQgLTIyClsgICAgMC45 OTg5MjJdIHBucDogUG5QIEFDUEk6IGZvdW5kIDEyIGRldmljZXMKWyAgICAxLjAwMTIwNF0g QUNQSTogQUNQSSBidXMgdHlwZSBwbnAgdW5yZWdpc3RlcmVkClsgICAgMS4wMDk3NDRdIE5F VDogUmVnaXN0ZXJlZCBwcm90b2NvbCBmYW1pbHkgMgpbICAgIDEuMDEyMjc0XSBJUCByb3V0 ZSBjYWNoZSBoYXNoIHRhYmxlIGVudHJpZXM6IDMyNzY4IChvcmRlcjogNiwgMjYyMTQ0IGJ5 dGVzKQpbICAgIDEuMDE2NDY0XSBUQ1AgZXN0YWJsaXNoZWQgaGFzaCB0YWJsZSBlbnRyaWVz OiAxMzEwNzIgKG9yZGVyOiA5LCAyMDk3MTUyIGJ5dGVzKQpbICAgIDEuMDIxMTc5XSBUQ1Ag YmluZCBoYXNoIHRhYmxlIGVudHJpZXM6IDY1NTM2IChvcmRlcjogOCwgMTA0ODU3NiBieXRl cykKWyAgICAxLjAyNTEyNV0gVENQOiBIYXNoIHRhYmxlcyBjb25maWd1cmVkIChlc3RhYmxp c2hlZCAxMzEwNzIgYmluZCA2NTUzNikKWyAgICAxLjAyODczMl0gVENQIHJlbm8gcmVnaXN0 ZXJlZApbICAgIDEuMDMwNTE3XSBVRFAgaGFzaCB0YWJsZSBlbnRyaWVzOiA1MTIgKG9yZGVy OiAyLCAxNjM4NCBieXRlcykKWyAgICAxLjAzMzY5MV0gVURQLUxpdGUgaGFzaCB0YWJsZSBl bnRyaWVzOiA1MTIgKG9yZGVyOiAyLCAxNjM4NCBieXRlcykKWyAgICAxLjAzNzIxN10gTkVU OiBSZWdpc3RlcmVkIHByb3RvY29sIGZhbWlseSAxClsgICAgMS4wMzk1ODNdIHBjaSAwMDAw OjAwOjAwLjA6IExpbWl0aW5nIGRpcmVjdCBQQ0kvUENJIHRyYW5zZmVycwpbICAgIDEuMDQy ODQ3XSBwY2kgMDAwMDowMDowMS4wOiBQSUlYMzogRW5hYmxpbmcgUGFzc2l2ZSBSZWxlYXNl ClsgICAgMS4wNDU5OTVdIHBjaSAwMDAwOjAwOjAxLjA6IEFjdGl2YXRpbmcgSVNBIERNQSBo YW5nIHdvcmthcm91bmRzClsgICAgMS4wNTAzODldIGF1ZGl0OiBpbml0aWFsaXppbmcgbmV0 bGluayBzb2NrZXQgKGRpc2FibGVkKQpbICAgIDEuMDUzMzA4XSB0eXBlPTIwMDAgYXVkaXQo MTMxNTMwMTI1MC4wNTI6MSk6IGluaXRpYWxpemVkClsgICAgMS4wNjg4MjldIEh1Z2VUTEIg cmVnaXN0ZXJlZCAyIE1CIHBhZ2Ugc2l6ZSwgcHJlLWFsbG9jYXRlZCAwIHBhZ2VzClsgICAg MS4wNzQyMDldIFZGUzogRGlzayBxdW90YXMgZHF1b3RfNi41LjIKWyAgICAxLjA3NjQwOV0g RHF1b3QtY2FjaGUgaGFzaCB0YWJsZSBlbnRyaWVzOiA1MTIgKG9yZGVyIDAsIDQwOTYgYnl0 ZXMpClsgICAgMS4wODA1OTZdIGZ1c2UgaW5pdCAoQVBJIHZlcnNpb24gNy4xNikKWyAgICAx LjA4MzA1MF0gbXNnbW5pIGhhcyBiZWVuIHNldCB0byAxOTg5ClsgICAgMS4wODU3MTddIEJs b2NrIGxheWVyIFNDU0kgZ2VuZXJpYyAoYnNnKSBkcml2ZXIgdmVyc2lvbiAwLjQgbG9hZGVk IChtYWpvciAyNTMpClsgICAgMS4wODk4ODhdIGlvIHNjaGVkdWxlciBub29wIHJlZ2lzdGVy ZWQKWyAgICAxLjA5MjIwNl0gaW8gc2NoZWR1bGVyIGRlYWRsaW5lIHJlZ2lzdGVyZWQgKGRl ZmF1bHQpClsgICAgMS4wOTUxMzFdIGlvIHNjaGVkdWxlciBjZnEgcmVnaXN0ZXJlZApbICAg IDEuMDk3MzA2XSBwY2lfaG90cGx1ZzogUENJIEhvdCBQbHVnIFBDSSBDb3JlIHZlcnNpb246 IDAuNQpbICAgIDEuMTAwMzk2XSBwY2llaHA6IFBDSSBFeHByZXNzIEhvdCBQbHVnIENvbnRy b2xsZXIgRHJpdmVyIHZlcnNpb246IDAuNApbICAgIDEuMTA0MDkwXSBlZmlmYjogcHJvYmlu ZyBmb3IgZWZpZmIKWyAgICAxLjEwNjE2Nl0gZWZpZmI6IGZyYW1lYnVmZmVyIGF0IDB4ZjAw MDAwMDAsIG1hcHBlZCB0byAweGZmZmZjOTAwMDA1MDAwMDAsIHVzaW5nIDE0MDhrLCB0b3Rh bCAxNDA4awpbICAgIDEuMTExMTExXSBlZmlmYjogbW9kZSBpcyA4MDB4NjAweDI0LCBsaW5l bGVuZ3RoPTI0MDAsIHBhZ2VzPTEKWyAgICAxLjExNDMzM10gZWZpZmI6IHNjcm9sbGluZzog cmVkcmF3ClsgICAgMS4xMTYyNzhdIGVmaWZiOiBUcnVlY29sb3I6IHNpemU9MDo4Ojg6OCwg c2hpZnQ9MDoxNjo4OjAKWyAgICAxLjEzNTk1NV0gQ29uc29sZTogc3dpdGNoaW5nIHRvIGNv bG91ciBmcmFtZSBidWZmZXIgZGV2aWNlIDEwMHgzNwpbICAgIDEuMTU2NTQ0XSBmYjA6IEVG SSBWR0EgZnJhbWUgYnVmZmVyIGRldmljZQpbICAgIDEuMTU5MDQzXSBpbnB1dDogUG93ZXIg QnV0dG9uIGFzIC9kZXZpY2VzL0xOWFNZU1RNOjAwL0xOWFBXUkJOOjAwL2lucHV0L2lucHV0 MApbICAgIDEuMTYzMDg0XSBBQ1BJOiBQb3dlciBCdXR0b24gW1BXUkZdClsgICAgMS4xNjUx MzFdIGlucHV0OiBTbGVlcCBCdXR0b24gYXMgL2RldmljZXMvTE5YU1lTVE06MDAvTE5YU0xQ Qk46MDAvaW5wdXQvaW5wdXQxClsgICAgMS4xNjkxNzNdIEFDUEk6IFNsZWVwIEJ1dHRvbiBb U0xQRl0KWyAgICAxLjE5MzQ2OV0gRVJTVDogVGFibGUgaXMgbm90IGZvdW5kIQpbICAgIDEu MTk1NTczXSBTZXJpYWw6IDgyNTAvMTY1NTAgZHJpdmVyLCAzMiBwb3J0cywgSVJRIHNoYXJp bmcgZW5hYmxlZApbICAgIDEuMjI4Mjk0XSBzZXJpYWw4MjUwOiB0dHlTMCBhdCBJL08gMHgz ZjggKGlycSA9IDQpIGlzIGEgMTY1NTBBClsgICAgMS43NDgwNzddIDAwOjBhOiB0dHlTMCBh dCBJL08gMHgzZjggKGlycSA9IC0xKSBpcyBhIDE2NTUwQQpbICAgIDEuNzU4MTE2XSBMaW51 eCBhZ3BnYXJ0IGludGVyZmFjZSB2MC4xMDMKWyAgICAxLjc2NzUxOV0gYnJkOiBtb2R1bGUg bG9hZGVkClsgICAgMS43NzM4NDFdIGxvb3A6IG1vZHVsZSBsb2FkZWQKWyAgICAxLjc3OTM0 OF0gaTJjLWNvcmU6IGRyaXZlciBbYWRwNTUyMF0gdXNpbmcgbGVnYWN5IHN1c3BlbmQgbWV0 aG9kClsgICAgMS43ODkyMTZdIGkyYy1jb3JlOiBkcml2ZXIgW2FkcDU1MjBdIHVzaW5nIGxl Z2FjeSByZXN1bWUgbWV0aG9kClsgICAgMS43OTgyMDRdIHNjc2kwIDogYXRhX3BpaXgKWyAg ICAxLjgwMDE3NV0gc2NzaTEgOiBhdGFfcGlpeApbICAgIDEuODAxOTMwXSBhdGExOiBQQVRB IG1heCBNV0RNQTIgY21kIDB4MWYwIGN0bCAweDNmNiBibWRtYSAweGMzMDAgaXJxIDE0Clsg ICAgMS44MDU2MDVdIGF0YTI6IFBBVEEgbWF4IE1XRE1BMiBjbWQgMHgxNzAgY3RsIDB4Mzc2 IGJtZG1hIDB4YzMwOCBpcnEgMTUKWyAgICAxLjgwOTU2N10gRml4ZWQgTURJTyBCdXM6IHBy b2JlZApbICAgIDEuODEyOTE2XSBQUFAgZ2VuZXJpYyBkcml2ZXIgdmVyc2lvbiAyLjQuMgpb ICAgIDEuODE1MzEzXSB0dW46IFVuaXZlcnNhbCBUVU4vVEFQIGRldmljZSBkcml2ZXIsIDEu NgpbICAgIDEuODE4MDkzXSB0dW46IChDKSAxOTk5LTIwMDQgTWF4IEtyYXNueWFuc2t5IDxt YXhrQHF1YWxjb21tLmNvbT4KWyAgICAxLjgyMTY0N10gZWhjaV9oY2Q6IFVTQiAyLjAgJ0Vu aGFuY2VkJyBIb3N0IENvbnRyb2xsZXIgKEVIQ0kpIERyaXZlcgpbICAgIDEuODI1Mzg1XSBl aGNpX2hjZCAwMDAwOjAwOjA2LjA6IFBDSSBJTlQgQiAtPiBHU0kgNDEgKGxldmVsLCBsb3cp IC0+IElSUSA0MQpbICAgIDEuODI5NDk3XSBlaGNpX2hjZCAwMDAwOjAwOjA2LjA6IEVIQ0kg SG9zdCBDb250cm9sbGVyClsgICAgMS44MzI0MzFdIGVoY2lfaGNkIDAwMDA6MDA6MDYuMDog bmV3IFVTQiBidXMgcmVnaXN0ZXJlZCwgYXNzaWduZWQgYnVzIG51bWJlciAxClsgICAgMS44 MzY1ODFdIGVoY2lfaGNkIDAwMDA6MDA6MDYuMDogYXBwbHlpbmcgQU1EIFNCNzAwL1NCODAw L0h1ZHNvbi0yLzMgRUhDSSBkdW1teSBxaCB3b3JrYXJvdW5kClsgICAgMS44NDE5NjVdIGVo Y2lfaGNkIDAwMDA6MDA6MDYuMDogaXJxIDQxLCBpbyBtZW0gMHhmMzA0YTAwMApbICAgIDEu ODYwMTQ0XSBlaGNpX2hjZCAwMDAwOjAwOjA2LjA6IFVTQiAyLjAgc3RhcnRlZCwgRUhDSSAx LjAwClsgICAgMS44NjUyNDBdIGh1YiAxLTA6MS4wOiBVU0IgaHViIGZvdW5kClsgICAgMS44 Njg1NDNdIGh1YiAxLTA6MS4wOiA1IHBvcnRzIGRldGVjdGVkClsgICAgMS44NzIxMjJdIG9o Y2lfaGNkOiBVU0IgMS4xICdPcGVuJyBIb3N0IENvbnRyb2xsZXIgKE9IQ0kpIERyaXZlcgpb ICAgIDEuODc3NTE0XSBvaGNpX2hjZCAwMDAwOjAwOjA1LjA6IFBDSSBJTlQgQSAtPiBHU0kg MzYgKGxldmVsLCBsb3cpIC0+IElSUSAzNgpbICAgIDEuODgzNzQxXSBvaGNpX2hjZCAwMDAw OjAwOjA1LjA6IE9IQ0kgSG9zdCBDb250cm9sbGVyClsgICAgMS44ODgyNzRdIG9oY2lfaGNk IDAwMDA6MDA6MDUuMDogbmV3IFVTQiBidXMgcmVnaXN0ZXJlZCwgYXNzaWduZWQgYnVzIG51 bWJlciAyClsgICAgMS44OTQ3OTBdIG9oY2lfaGNkIDAwMDA6MDA6MDUuMDogaXJxIDM2LCBp byBtZW0gMHhmMzA0OTAwMApbICAgIDEuOTU0NTM3XSBodWIgMi0wOjEuMDogVVNCIGh1YiBm b3VuZApbICAgIDEuOTYwNzY1XSBodWIgMi0wOjEuMDogNSBwb3J0cyBkZXRlY3RlZApbICAg IDEuOTY3NTYzXSB1aGNpX2hjZDogVVNCIFVuaXZlcnNhbCBIb3N0IENvbnRyb2xsZXIgSW50 ZXJmYWNlIGRyaXZlcgpbICAgIDEuOTc3ODk4XSBpODA0MjogUE5QOiBQUy8yIENvbnRyb2xs ZXIgW1BOUDAzMDM6UFMySyxQTlAwZjEzOlBTMk1dIGF0IDB4NjAsMHg2NCBpcnEgMSwxMgpb ICAgIDEuOTg0MzgyXSBzZXJpbzogaTgwNDIgS0JEIHBvcnQgYXQgMHg2MCwweDY0IGlycSAx ClsgICAgMS45ODcxMzFdIHNlcmlvOiBpODA0MiBBVVggcG9ydCBhdCAweDYwLDB4NjQgaXJx IDEyClsgICAgMS45OTAwMDBdIG1vdXNlZGV2OiBQUy8yIG1vdXNlIGRldmljZSBjb21tb24g Zm9yIGFsbCBtaWNlClsgICAgMS45OTM4MTJdIGlucHV0OiBBVCBUcmFuc2xhdGVkIFNldCAy IGtleWJvYXJkIGFzIC9kZXZpY2VzL3BsYXRmb3JtL2k4MDQyL3NlcmlvMC9pbnB1dC9pbnB1 dDIKWyAgICAyLjAxMDI2NV0gcnRjX2Ntb3MgMDA6MDU6IHJ0YyBjb3JlOiByZWdpc3RlcmVk IHJ0Y19jbW9zIGFzIHJ0YzAKWyAgICAyLjAxMzY2N10gcnRjMDogYWxhcm1zIHVwIHRvIG9u ZSBkYXksIDExNCBieXRlcyBudnJhbQpbICAgIDIuMDE3MDQ2XSBkZXZpY2UtbWFwcGVyOiB1 ZXZlbnQ6IHZlcnNpb24gMS4wLjMKWyAgICAyLjAyMTIwNV0gZGV2aWNlLW1hcHBlcjogaW9j dGw6IDQuMTkuMS1pb2N0bCAoMjAxMS0wMS0wNykgaW5pdGlhbGlzZWQ6IGRtLWRldmVsQHJl ZGhhdC5jb20KWyAgICAyLjAyODY2NF0gZGV2aWNlLW1hcHBlcjogbXVsdGlwYXRoOiB2ZXJz aW9uIDEuMi4wIGxvYWRlZApbICAgIDIuMDMzMzQxXSBkZXZpY2UtbWFwcGVyOiBtdWx0aXBh dGggcm91bmQtcm9iaW46IHZlcnNpb24gMS4wLjAgbG9hZGVkClsgICAgMi4wMzgxNzhdIGNw dWlkbGU6IHVzaW5nIGdvdmVybm9yIGxhZGRlcgpbICAgIDIuMDQwNDQzXSBjcHVpZGxlOiB1 c2luZyBnb3Zlcm5vciBtZW51ClsgICAgMi4wNDI4NDhdIFRDUCBjdWJpYyByZWdpc3RlcmVk ClsgICAgMi4wNDQ3MjddIE5FVDogUmVnaXN0ZXJlZCBwcm90b2NvbCBmYW1pbHkgMTAKWyAg ICAyLjA0NzY1OV0gTkVUOiBSZWdpc3RlcmVkIHByb3RvY29sIGZhbWlseSAxNwpbICAgIDIu MDUwMjk3XSBSZWdpc3RlcmluZyB0aGUgZG5zX3Jlc29sdmVyIGtleSB0eXBlClsgICAgMi4w NTMwNjFdIHJlZ2lzdGVyZWQgdGFza3N0YXRzIHZlcnNpb24gMQpbICAgIDIuMDU3MDE2XSAg IE1hZ2ljIG51bWJlcjogMTE6MzQ3OjQ3NApbICAgIDIuMDU5MjQyXSBydGNfY21vcyAwMDow NTogc2V0dGluZyBzeXN0ZW0gY2xvY2sgdG8gMjAxMS0wOS0wNiAwOToyNzozMCBVVEMgKDEz MTUzMDEyNTApClsgICAgMi4wNjM2MjVdIEJJT1MgRUREIGZhY2lsaXR5IHYwLjE2IDIwMDQt SnVuLTI1LCAwIGRldmljZXMgZm91bmQKWyAgICAyLjA2Njk0M10gRUREIGluZm9ybWF0aW9u IG5vdCBhdmFpbGFibGUuClsgICAgMi4wNzExMzNdIEZyZWVpbmcgdW51c2VkIGtlcm5lbCBt ZW1vcnk6IDg4MGsgZnJlZWQKWyAgICAyLjA3NDIyN10gV3JpdGUgcHJvdGVjdGluZyB0aGUg a2VybmVsIHJlYWQtb25seSBkYXRhOiAxMDI0MGsKWyAgICAyLjA3ODA1N10gRnJlZWluZyB1 bnVzZWQga2VybmVsIG1lbW9yeTogMTAwayBmcmVlZApbICAgIDIuMDg1NjI2XSBGcmVlaW5n IHVudXNlZCBrZXJuZWwgbWVtb3J5OiAxNDE2ayBmcmVlZApbICAgIDIuMTE1MjYwXSA8MzA+ dWRldls2OF06IHN0YXJ0aW5nIHZlcnNpb24gMTY3ClsgICAgMi4xNDk1MTNdIHhlbiBtYXAg aXJxIGZhaWxlZCAtMjIKWyAgICAyLjE1MTQ1OV0geGVuLXBsYXRmb3JtLXBjaSAwMDAwOjAw OjAzLjA6IFBDSSBJTlQgQTogZmFpbGVkIHRvIHJlZ2lzdGVyIEdTSQpbICAgIDIuMTU1NDA0 XSB4ZW4tcGxhdGZvcm0tcGNpOiBwcm9iZSBvZiAwMDAwOjAwOjAzLjAgZmFpbGVkIHdpdGgg ZXJyb3IgLTEKWyAgICAyLjIyMjA1NF0gRkRDIDAgaXMgYSBTODIwNzhCClsgICAgMi4yMjYx OTldIEluaXRpYWxpc2luZyBYZW4gdmlydHVhbCBldGhlcm5ldCBkcml2ZXIuClsgICAgMi4y Mzc3NDRdIEV2ZW50LWNoYW5uZWwgZGV2aWNlIGluc3RhbGxlZC4KWyAgICAyLjMzMDI5NV0g dXNiIDItMjogbmV3IGxvdyBzcGVlZCBVU0IgZGV2aWNlIHVzaW5nIG9oY2lfaGNkIGFuZCBh ZGRyZXNzIDIKWyAgICAyLjYwMDY4Nl0gaW5wdXQ6IEFCQkFIT01FIGFzIC9kZXZpY2VzL3Bj aTAwMDA6MDAvMDAwMDowMDowNS4wL3VzYjIvMi0yLzItMjoxLjAvaW5wdXQvaW5wdXQzClsg ICAgMi42MTUxOTFdIGdlbmVyaWMtdXNiIDAwMDM6MDVENTo2NzgyLjAwMDE6IGlucHV0LGhp ZHJhdzA6IFVTQiBISUQgdjEuMTAgS2V5Ym9hcmQgW0FCQkFIT01FXSBvbiB1c2ItMDAwMDow MDowNS4wLTIvaW5wdXQwClsgICAgMi42MzMzOThdIHVzYmNvcmU6IHJlZ2lzdGVyZWQgbmV3 IGludGVyZmFjZSBkcml2ZXIgdXNiaGlkClsgICAgMi42MzgyNTFdIHVzYmhpZDogVVNCIEhJ RCBjb3JlIGRyaXZlcg== --------------050404030308050904030304 Content-Type: text/plain; name="3-Natty-not-working-with-passthrough-no-xen-platform-pci" Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename*0="3-Natty-not-working-with-passthrough-no-xen-platform-pci" xm create ubuntu-mediacenter.cfg -c Using config file "./ubuntu-mediacenter.cfg". Started domain ubuntu-mediacenter (id=10) [ 0.000000] Initializing cgroup subsys cpuset [ 0.000000] Initializing cgroup subsys cpu [ 0.000000] Linux version 2.6.38-11-server (buildd@allspice) (gcc version 4.5.2 (Ubuntu/Linaro 4.5.2-8ubuntu4) ) #48-Ubuntu SMP Fri Jul 29 19:20:32 UTC 2011 (Ubuntu 2.6.38-11.48-server 2.6.38.8) [ 0.000000] Command line: BOOT_IMAGE=/boot/vmlinuz-2.6.38-11-server root=UUID=992cda33-09ce-4437-b110-fe153702b2d5 ro console=ttyS0,115200n8 [ 0.000000] BIOS-provided physical RAM map: [ 0.000000] BIOS-e820: 0000000000000000 - 000000000009e000 (usable) [ 0.000000] BIOS-e820: 000000000009e000 - 00000000000a0000 (reserved) [ 0.000000] BIOS-e820: 00000000000e0000 - 0000000000100000 (reserved) [ 0.000000] BIOS-e820: 0000000000100000 - 0000000040000000 (usable) [ 0.000000] BIOS-e820: 00000000fc000000 - 0000000100000000 (reserved) [ 0.000000] NX (Execute Disable) protection: active [ 0.000000] DMI 2.4 present. [ 0.000000] Hypervisor detected: Xen HVM [ 0.000000] Xen version 4.1. [ 0.000000] Xen Platform PCI: unrecognised magic value [ 0.000000] No AGP bridge found [ 0.000000] last_pfn = 0x40000 max_arch_pfn = 0x400000000 [ 0.000000] x86 PAT enabled: cpu 0, old 0x7040600070406, new 0x7010600070106 [ 0.000000] found SMP MP-table at [ffff8800000fbc90] fbc90 [ 0.000000] init_memory_mapping: 0000000000000000-0000000040000000 [ 0.000000] RAMDISK: 366e0000 - 37368000 [ 0.000000] ACPI: RSDP 00000000000ea020 00024 (v02 Xen) [ 0.000000] ACPI: XSDT 00000000fc0134b0 00034 (v01 Xen HVM 00000000 HVML 00000000) [ 0.000000] ACPI: FACP 00000000fc0132d0 000F4 (v04 Xen HVM 00000000 HVML 00000000) [ 0.000000] ACPI: DSDT 00000000fc003440 0FE05 (v02 Xen HVM 00000000 INTL 20100528) [ 0.000000] ACPI: FACS 00000000fc003400 00040 [ 0.000000] ACPI: APIC 00000000fc0133d0 000D8 (v02 Xen HVM 00000000 HVML 00000000) [ 0.000000] No NUMA configuration found [ 0.000000] Faking a node at 0000000000000000-0000000040000000 [ 0.000000] Initmem setup node 0 0000000000000000-0000000040000000 [ 0.000000] NODE_DATA [000000003fffb000 - 000000003fffffff] [ 0.000000] Zone PFN ranges: [ 0.000000] DMA 0x00000010 -> 0x00001000 [ 0.000000] DMA32 0x00001000 -> 0x00100000 [ 0.000000] Normal empty [ 0.000000] Movable zone start PFN for each node [ 0.000000] early_node_map[2] active PFN ranges [ 0.000000] 0: 0x00000010 -> 0x0000009e [ 0.000000] 0: 0x00000100 -> 0x00040000 [ 0.000000] ACPI: PM-Timer IO Port: 0xb008 [ 0.000000] ACPI: LAPIC (acpi_id[0x00] lapic_id[0x00] enabled) [ 0.000000] ACPI: LAPIC (acpi_id[0x01] lapic_id[0x02] enabled) [ 0.000000] ACPI: LAPIC (acpi_id[0x02] lapic_id[0x04] disabled) [ 0.000000] ACPI: LAPIC (acpi_id[0x03] lapic_id[0x06] disabled) [ 0.000000] ACPI: LAPIC (acpi_id[0x04] lapic_id[0x08] disabled) [ 0.000000] ACPI: LAPIC (acpi_id[0x05] lapic_id[0x0a] disabled) [ 0.000000] ACPI: LAPIC (acpi_id[0x06] lapic_id[0x0c] disabled) [ 0.000000] ACPI: LAPIC (acpi_id[0x07] lapic_id[0x0e] disabled) [ 0.000000] ACPI: LAPIC (acpi_id[0x08] lapic_id[0x10] disabled) [ 0.000000] ACPI: LAPIC (acpi_id[0x09] lapic_id[0x12] disabled) [ 0.000000] ACPI: LAPIC (acpi_id[0x0a] lapic_id[0x14] disabled) [ 0.000000] ACPI: LAPIC (acpi_id[0x0b] lapic_id[0x16] disabled) [ 0.000000] ACPI: LAPIC (acpi_id[0x0c] lapic_id[0x18] disabled) [ 0.000000] ACPI: LAPIC (acpi_id[0x0d] lapic_id[0x1a] disabled) [ 0.000000] ACPI: LAPIC (acpi_id[0x0e] lapic_id[0x1c] disabled) [ 0.000000] ACPI: IOAPIC (id[0x01] address[0xfec00000] gsi_base[0]) [ 0.000000] IOAPIC[0]: apic_id 1, version 17, address 0xfec00000, GSI 0-47 [ 0.000000] ACPI: INT_SRC_OVR (bus 0 bus_irq 0 global_irq 2 dfl dfl) [ 0.000000] ACPI: INT_SRC_OVR (bus 0 bus_irq 5 global_irq 5 low level) [ 0.000000] ACPI: INT_SRC_OVR (bus 0 bus_irq 10 global_irq 10 low level) [ 0.000000] ACPI: INT_SRC_OVR (bus 0 bus_irq 11 global_irq 11 low level) [ 0.000000] Using ACPI (MADT) for SMP configuration information [ 0.000000] SMP: Allowing 15 CPUs, 13 hotplug CPUs [ 0.000000] PM: Registered nosave memory: 000000000009e000 - 00000000000a0000 [ 0.000000] PM: Registered nosave memory: 00000000000a0000 - 00000000000e0000 [ 0.000000] PM: Registered nosave memory: 00000000000e0000 - 0000000000100000 [ 0.000000] Allocating PCI resources starting at 40000000 (gap: 40000000:bc000000) [ 0.000000] Booting paravirtualized kernel on Xen [ 0.000000] setup_percpu: NR_CPUS:256 nr_cpumask_bits:256 nr_cpu_ids:15 nr_node_ids:1 [ 0.000000] PERCPU: Embedded 28 pages/cpu @ffff88003fc00000 s84416 r8192 d22080 u131072 [ 0.000000] Built 1 zonelists in Node order, mobility grouping on. Total pages: 258440 [ 0.000000] Policy zone: DMA32 [ 0.000000] Kernel command line: BOOT_IMAGE=/boot/vmlinuz-2.6.38-11-server root=UUID=992cda33-09ce-4437-b110-fe153702b2d5 ro console=ttyS0,115200n8 [ 0.000000] PID hash table entries: 4096 (order: 3, 32768 bytes) [ 0.000000] Checking aperture... [ 0.000000] No AGP bridge found [ 0.000000] Memory: 1005640k/1048576k available (6025k kernel code, 456k absent, 42480k reserved, 5023k data, 880k init) [ 0.000000] SLUB: Genslabs=15, HWalign=64, Order=0-3, MinObjects=0, CPUs=15, Nodes=1 [ 0.000000] Hierarchical RCU implementation. [ 0.000000] RCU dyntick-idle grace-period acceleration is enabled. [ 0.000000] RCU-based detection of stalled CPUs is disabled. [ 0.000000] NR_IRQS:16640 nr_irqs:1208 16 [ 0.000000] Xen HVM callback vector for event delivery is enabled [ 0.000000] Console: colour VGA+ 80x25 [ 0.000000] console [ttyS0] enabled [ 0.000000] allocated 10485760 bytes of page_cgroup [ 0.000000] please try 'cgroup_disable=memory' option if you don't want memory cgroups [ 0.000000] Detected 2310.666 MHz processor. [ 0.000000] Marking TSC unstable due to TSCs unsynchronized [ 0.020000] Calibrating delay loop (skipped), value calculated using timer frequency.. 4621.33 BogoMIPS (lpj=23106660) [ 0.020000] pid_max: default: 32768 minimum: 301 [ 0.020000] Security Framework initialized [ 0.020024] AppArmor: AppArmor initialized [ 0.022347] Yama: becoming mindful. [ 0.024480] Dentry cache hash table entries: 131072 (order: 8, 1048576 bytes) [ 0.030284] Inode-cache hash table entries: 65536 (order: 7, 524288 bytes) [ 0.034281] Mount-cache hash table entries: 256 [ 0.036969] Initializing cgroup subsys ns [ 0.039207] ns_cgroup deprecated: consider using the 'clone_children' flag without the ns_cgroup. [ 0.040006] Initializing cgroup subsys cpuacct [ 0.042499] Initializing cgroup subsys memory [ 0.044978] Initializing cgroup subsys devices [ 0.050003] Initializing cgroup subsys freezer [ 0.052545] Initializing cgroup subsys net_cls [ 0.055111] Initializing cgroup subsys blkio [ 0.057594] CPU: Physical Processor ID: 0 [ 0.060003] CPU: Processor Core ID: 0 [ 0.062061] mce: CPU supports 6 MCE banks [ 0.064378] using C1E aware idle routine [ 0.072639] ACPI: Core revision 20110112 [ 0.080164] ftrace: allocating 24622 entries in 97 pages [ 0.102054] Not enabling x2apic, Intr-remapping init failed. [ 0.105290] Setting APIC routing to physical flat [ 0.112512] ..TIMER: vector=0x30 apic1=0 pin1=2 apic2=0 pin2=0 [ 0.218008] CPU0: AMD Athlon(tm) II X4 605e Processor stepping 02 [ 0.220764] installing Xen timer for CPU 0 [ 0.223050] Performance Events: Broken PMU hardware detected, using software events only. [ 0.228482] Booting Node 0, Processors #1 [ 0.020000] installing Xen timer for CPU 1 [ 0.380320] Brought up 2 CPUs [ 0.380323] Total of 2 processors activated (9269.62 BogoMIPS). [ 0.388257] devtmpfs: initialized [ 0.391075] print_constraints: dummy: [ 0.393091] Time: 9:30:15 Date: 09/06/11 [ 0.395446] NET: Registered protocol family 16 [ 0.395446] Trying to unpack rootfs image as initramfs... [ 0.395850] Extended Config Space enabled on 0 nodes [ 0.398913] ACPI: bus type pci registered [ 0.400403] PCI: Using configuration type 1 for base access [ 0.403609] PCI: Using configuration type 1 for extended access [ 0.410213] bio: create slab at 0 [ 0.416643] ACPI: Interpreter enabled [ 0.418934] ACPI: (supports S0 S3 S4 S5) [ 0.420962] ACPI: Using IOAPIC for interrupt routing [ 0.511295] ACPI: No dock devices found. [ 0.513582] HEST: Table not found. [ 0.515645] PCI: Using host bridge windows from ACPI; if necessary, use "pci=nocrs" and report a bug [ 0.520096] ACPI: PCI Root Bridge [PCI0] (domain 0000 [bus 00-ff]) [ 0.523873] pci_root PNP0A03:00: host bridge window [io 0x0000-0x0cf7] [ 0.527673] pci_root PNP0A03:00: host bridge window [io 0x0d00-0xffff] [ 0.530012] pci_root PNP0A03:00: host bridge window [mem 0x000a0000-0x000bffff] [ 0.534165] pci_root PNP0A03:00: host bridge window [mem 0xe0000000-0xfbffffff] [ 0.544641] * Found PM-Timer Bug on the chipset. Due to workarounds for a bug, [ 0.544642] * this clock source is slow. Consider trying other clock sources [ 0.562020] pci 0000:00:01.3: quirk: [io 0xb000-0xb03f] claimed by PIIX4 ACPI [ 0.742268] Freeing initrd memory: 12832k freed [ 0.748076] pci0000:00: Requesting ACPI _OSC control (0x1d) [ 0.969338] ACPI: PCI Interrupt Link [LNKA] (IRQs *5 10 11) [ 0.971129] ACPI: PCI Interrupt Link [LNKB] (IRQs 5 *10 11) [ 0.974855] ACPI: PCI Interrupt Link [LNKC] (IRQs 5 10 *11) [ 0.978564] ACPI: PCI Interrupt Link [LNKD] (IRQs *5 10 11) [ 0.991196] vgaarb: device added: PCI:0000:00:02.0,decodes=io+mem,owns=io+mem,locks=none [ 0.995806] vgaarb: device added: PCI:0000:00:07.0,decodes=io+mem,owns=io+mem,locks=none [ 1.000010] vgaarb: loaded [ 1.001747] SCSI subsystem initialized [ 1.003913] usbcore: registered new interface driver usbfs [ 1.003913] usbcore: registered new interface driver hub [ 1.010049] usbcore: registered new device driver usb [ 1.012991] wmi: Mapper loaded [ 1.012991] PCI: Using ACPI for IRQ routing [ 1.015425] NetLabel: Initializing [ 1.020011] NetLabel: domain hash size = 128 [ 1.022474] NetLabel: protocols = UNLABELED CIPSOv4 [ 1.025273] NetLabel: unlabeled traffic allowed by default [ 1.028463] Switching to clocksource xen [ 1.035574] AppArmor: AppArmor Filesystem Enabled [ 1.038398] pnp: PnP ACPI init [ 1.040023] Switched to NOHz mode on CPU #0 [ 1.042639] Switched to NOHz mode on CPU #1 [ 1.045090] ACPI: bus type pnp registered [ 1.047473] system 00:00: [mem 0x00000000-0x0009ffff] could not be reserved [ 1.051644] system 00:02: [io 0x10c0-0x1141] has been reserved [ 1.054980] system 00:02: [io 0xb044-0xb047] has been reserved [ 1.058401] system 00:03: [io 0x08a0-0x08a3] has been reserved [ 1.061841] system 00:03: [io 0x0cc0-0x0ccf] has been reserved [ 1.065187] system 00:03: [io 0x04d0-0x04d1] has been reserved [ 1.068822] xen map irq failed -22 [ 1.070854] xen map irq failed -22 [ 1.090595] pnp: PnP ACPI: found 12 devices [ 1.093006] ACPI: ACPI bus type pnp unregistered [ 1.101715] NET: Registered protocol family 2 [ 1.104389] IP route cache hash table entries: 32768 (order: 6, 262144 bytes) [ 1.108811] TCP established hash table entries: 131072 (order: 9, 2097152 bytes) [ 1.113696] TCP bind hash table entries: 65536 (order: 8, 1048576 bytes) [ 1.117867] TCP: Hash tables configured (established 131072 bind 65536) [ 1.121623] TCP reno registered [ 1.123500] UDP hash table entries: 512 (order: 2, 16384 bytes) [ 1.126844] UDP-Lite hash table entries: 512 (order: 2, 16384 bytes) [ 1.130545] NET: Registered protocol family 1 [ 1.133052] pci 0000:00:00.0: Limiting direct PCI/PCI transfers [ 1.136487] pci 0000:00:01.0: PIIX3: Enabling Passive Release [ 1.139804] pci 0000:00:01.0: Activating ISA DMA hang workarounds [ 1.144499] audit: initializing netlink socket (disabled) [ 1.147616] type=2000 audit(1315301417.187:1): initialized [ 1.163320] HugeTLB registered 2 MB page size, pre-allocated 0 pages [ 1.168812] VFS: Disk quotas dquot_6.5.2 [ 1.171348] Dquot-cache hash table entries: 512 (order 0, 4096 bytes) [ 1.175801] fuse init (API version 7.16) [ 1.178344] msgmni has been set to 1989 [ 1.181195] Block layer SCSI generic (bsg) driver version 0.4 loaded (major 253) [ 1.185614] io scheduler noop registered [ 1.187934] io scheduler deadline registered (default) [ 1.190898] io scheduler cfq registered [ 1.193147] pci_hotplug: PCI Hot Plug PCI Core version: 0.5 [ 1.196307] pciehp: PCI Express Hot Plug Controller Driver version: 0.4 [ 1.200146] input: Power Button as /devices/LNXSYSTM:00/LNXPWRBN:00/input/input0 [ 1.204266] ACPI: Power Button [PWRF] [ 1.206363] input: Sleep Button as /devices/LNXSYSTM:00/LNXSLPBN:00/input/input1 [ 1.210499] ACPI: Sleep Button [SLPF] [ 1.233930] ERST: Table is not found! [ 1.236112] Serial: 8250/16550 driver, 32 ports, IRQ sharing enabled [ 1.269075] serial8250: ttyS0 at I/O 0x3f8 (irq = 4) is a 16550A [ 1.623941] 00:0a: ttyS0 at I/O 0x3f8 (irq = -1) is a 16550A [ 1.630398] Linux agpgart interface v0.103 [ 1.633948] brd: module loaded [ 1.636375] loop: module loaded [ 1.638242] i2c-core: driver [adp5520] using legacy suspend method [ 1.641731] i2c-core: driver [adp5520] using legacy resume method [ 1.646207] scsi0 : ata_piix [ 1.648288] scsi1 : ata_piix [ 1.649986] ata1: PATA max MWDMA2 cmd 0x1f0 ctl 0x3f6 bmdma 0xc200 irq 14 [ 1.653879] ata2: PATA max MWDMA2 cmd 0x170 ctl 0x376 bmdma 0xc208 irq 15 [ 1.658092] Fixed MDIO Bus: probed [ 1.661650] PPP generic driver version 2.4.2 [ 1.664237] tun: Universal TUN/TAP device driver, 1.6 [ 1.667107] tun: (C) 1999-2004 Max Krasnyansky [ 1.670777] ehci_hcd: USB 2.0 'Enhanced' Host Controller (EHCI) Driver [ 1.674668] ehci_hcd 0000:00:05.0: PCI INT B -> GSI 37 (level, low) -> IRQ 37 [ 1.678868] ehci_hcd 0000:00:05.0: EHCI Host Controller [ 1.681917] ehci_hcd 0000:00:05.0: new USB bus registered, assigned bus number 1 [ 1.686176] ehci_hcd 0000:00:05.0: applying AMD SB700/SB800/Hudson-2/3 EHCI dummy qh workaround [ 1.691713] ehci_hcd 0000:00:05.0: irq 37, io mem 0xf204a000 [ 1.710125] ehci_hcd 0000:00:05.0: USB 2.0 started, EHCI 1.00 [ 1.713600] hub 1-0:1.0: USB hub found [ 1.715815] hub 1-0:1.0: 5 ports detected [ 1.718146] ohci_hcd: USB 1.1 'Open' Host Controller (OHCI) Driver [ 1.721931] ohci_hcd 0000:00:04.0: PCI INT A -> GSI 32 (level, low) -> IRQ 32 [ 1.727387] ohci_hcd 0000:00:04.0: OHCI Host Controller [ 1.731291] ohci_hcd 0000:00:04.0: new USB bus registered, assigned bus number 2 [ 1.736771] ohci_hcd 0000:00:04.0: irq 32, io mem 0xf2049000 [ 1.804542] hub 2-0:1.0: USB hub found [ 1.811114] hub 2-0:1.0: 5 ports detected [ 1.819787] uhci_hcd: USB Universal Host Controller Interface driver [ 1.824567] i8042: PNP: PS/2 Controller [PNP0303:PS2K,PNP0f13:PS2M] at 0x60,0x64 irq 1,12 [ 1.830000] ata1.00: ATA-7: QEMU HARDDISK, 0.10.2, max UDMA/100 [ 1.830003] ata1.00: 20971520 sectors, multi 16: LBA48 [ 1.832836] ata1.00: configured for MWDMA2 [ 1.832939] scsi 0:0:0:0: Direct-Access ATA QEMU HARDDISK 0.10 PQ: 0 ANSI: 5 [ 1.833082] sd 0:0:0:0: Attached scsi generic sg0 type 0 [ 1.833153] sd 0:0:0:0: [sda] 20971520 512-byte logical blocks: (10.7 GB/10.0 GiB) [ 1.833194] sd 0:0:0:0: [sda] Write Protect is off [ 1.833213] sd 0:0:0:0: [sda] Write cache: disabled, read cache: enabled, doesn't support DPO or FUA [ 1.835930] sda: sda1 sda2 < sda5 > [ 1.865559] sd 0:0:0:0: [sda] Attached SCSI disk [ 1.869809] serio: i8042 KBD port at 0x60,0x64 irq 1 [ 1.872720] serio: i8042 AUX port at 0x60,0x64 irq 12 [ 1.875722] mousedev: PS/2 mouse device common for all mice [ 1.879875] input: AT Translated Set 2 keyboard as /devices/platform/i8042/serio0/input/input2 [ 1.885143] rtc_cmos 00:05: rtc core: registered rtc_cmos as rtc0 [ 1.888975] rtc0: alarms up to one day, 114 bytes nvram [ 1.892237] device-mapper: uevent: version 1.0.3 [ 1.894962] device-mapper: ioctl: 4.19.1-ioctl (2011-01-07) initialised: dm-devel@redhat.com [ 1.899975] device-mapper: multipath: version 1.2.0 loaded [ 1.903122] device-mapper: multipath round-robin: version 1.0.0 loaded [ 1.907097] cpuidle: using governor ladder [ 1.909440] cpuidle: using governor menu [ 1.911920] TCP cubic registered [ 1.913898] NET: Registered protocol family 10 [ 1.917002] NET: Registered protocol family 17 [ 1.919612] Registering the dns_resolver key type [ 1.922580] registered taskstats version 1 [ 1.926724] Magic number: 11:897:524 [ 1.928980] rtc_cmos 00:05: setting system clock to 2011-09-06 09:30:17 UTC (1315301417) [ 1.933558] BIOS EDD facility v0.16 2004-Jun-25, 0 devices found [ 1.936954] EDD information not available. [ 1.941296] Freeing unused kernel memory: 880k freed [ 1.944420] Write protecting the kernel read-only data: 10240k [ 1.948403] Freeing unused kernel memory: 100k freed [ 1.956146] Freeing unused kernel memory: 1416k freed [ 1.982153] <30>udev[68]: starting version 167 [ 2.026106] 8139cp: 8139cp: 10/100 PCI Ethernet driver v1.3 (Mar 22, 2004) [ 2.030192] xen map irq failed -22 [ 2.032214] 8139cp 0000:00:03.0: PCI INT A: failed to register GSI [ 2.035748] 8139cp: probe of 0000:00:03.0 failed with error -1 [ 2.054128] 8139too: 8139too Fast Ethernet driver 0.9.28 [ 2.057279] 8139too 0000:00:03.0: This (id 10ec:8139 rev 20) is an enhanced 8139C+ chip, use 8139cp [ 2.091272] Initialising Xen virtual ethernet driver. [ 2.101295] Event-channel device installed. [ 2.106257] FDC 0 is a S82078B [ 2.350206] usb 2-2: new low speed USB device using ohci_hcd and address 2 [ 2.630564] input: ABBAHOME as /devices/pci0000:00/0000:00:04.0/usb2/2-2/2-2:1.0/input/input3 [ 2.645108] generic-usb 0003:05D5:6782.0001: input,hidraw0: USB HID v1.10 Keyboard [ABBAHOME] on usb-0000:00:04.0-2/input0 [ 2.662113] usbcore: registered new interface driver usbhid [ 2.665292] usbhid: USB HID core driver [ 32.060751] ata1: lost interrupt (Status 0x58) [ 32.087015] ata1.00: exception Emask 0x0 SAct 0x0 SErr 0x0 action 0x6 frozen [ 32.091068] ata1.00: failed command: IDENTIFY DEVICE [ 32.093860] ata1.00: cmd ec/00:01:00:00:00/00:00:00:00:00/00 tag 0 pio 512 in [ 32.093862] res 40/00:00:00:00:00/00:00:00:00:00/00 Emask 0x4 (timeout) [ 32.102858] ata1.00: status: { DRDY } [ 32.105411] ata1: soft resetting link [ 32.264671] ata1.00: configured for MWDMA2 [ 32.267070] ata1: EH complete --------------050404030308050904030304 Content-Type: text/plain; name="4-Natty-not-working-with-passthrough-no-xen-platform-pci-hda" Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename*0="4-Natty-not-working-with-passthrough-no-xen-platform-pci-hda" xm create ubuntu-mediacenter.cfg -c Using config file "./ubuntu-mediacenter.cfg". Started domain ubuntu-mediacenter (id=11) [ 0.000000] Initializing cgroup subsys cpuset [ 0.000000] Initializing cgroup subsys cpu [ 0.000000] Linux version 2.6.38-11-server (buildd@allspice) (gcc version 4.5.2 (Ubuntu/Linaro 4.5.2-8ubuntu4) ) #48-Ubuntu SMP Fri Jul 29 19:20:32 UTC 2011 (Ubuntu 2.6.38-11.48-server 2.6.38.8) [ 0.000000] Command line: BOOT_IMAGE=/boot/vmlinuz-2.6.38-11-server root=UUID=992cda33-09ce-4437-b110-fe153702b2d5 ro console=ttyS0,115200n8 [ 0.000000] BIOS-provided physical RAM map: [ 0.000000] BIOS-e820: 0000000000000000 - 000000000009e000 (usable) [ 0.000000] BIOS-e820: 000000000009e000 - 00000000000a0000 (reserved) [ 0.000000] BIOS-e820: 00000000000e0000 - 0000000000100000 (reserved) [ 0.000000] BIOS-e820: 0000000000100000 - 0000000040000000 (usable) [ 0.000000] BIOS-e820: 00000000fc000000 - 0000000100000000 (reserved) [ 0.000000] NX (Execute Disable) protection: active [ 0.000000] DMI 2.4 present. [ 0.000000] Hypervisor detected: Xen HVM [ 0.000000] Xen version 4.1. [ 0.000000] Xen Platform PCI: unrecognised magic value [ 0.000000] No AGP bridge found [ 0.000000] last_pfn = 0x40000 max_arch_pfn = 0x400000000 [ 0.000000] x86 PAT enabled: cpu 0, old 0x7040600070406, new 0x7010600070106 [ 0.000000] found SMP MP-table at [ffff8800000fbc90] fbc90 [ 0.000000] init_memory_mapping: 0000000000000000-0000000040000000 [ 0.000000] RAMDISK: 366e0000 - 37368000 [ 0.000000] ACPI: RSDP 00000000000ea020 00024 (v02 Xen) [ 0.000000] ACPI: XSDT 00000000fc0134b0 00034 (v01 Xen HVM 00000000 HVML 00000000) [ 0.000000] ACPI: FACP 00000000fc0132d0 000F4 (v04 Xen HVM 00000000 HVML 00000000) [ 0.000000] ACPI: DSDT 00000000fc003440 0FE05 (v02 Xen HVM 00000000 INTL 20100528) [ 0.000000] ACPI: FACS 00000000fc003400 00040 [ 0.000000] ACPI: APIC 00000000fc0133d0 000D8 (v02 Xen HVM 00000000 HVML 00000000) [ 0.000000] No NUMA configuration found [ 0.000000] Faking a node at 0000000000000000-0000000040000000 [ 0.000000] Initmem setup node 0 0000000000000000-0000000040000000 [ 0.000000] NODE_DATA [000000003fffb000 - 000000003fffffff] [ 0.000000] Zone PFN ranges: [ 0.000000] DMA 0x00000010 -> 0x00001000 [ 0.000000] DMA32 0x00001000 -> 0x00100000 [ 0.000000] Normal empty [ 0.000000] Movable zone start PFN for each node [ 0.000000] early_node_map[2] active PFN ranges [ 0.000000] 0: 0x00000010 -> 0x0000009e [ 0.000000] 0: 0x00000100 -> 0x00040000 [ 0.000000] ACPI: PM-Timer IO Port: 0xb008 [ 0.000000] ACPI: LAPIC (acpi_id[0x00] lapic_id[0x00] enabled) [ 0.000000] ACPI: LAPIC (acpi_id[0x01] lapic_id[0x02] enabled) [ 0.000000] ACPI: LAPIC (acpi_id[0x02] lapic_id[0x04] disabled) [ 0.000000] ACPI: LAPIC (acpi_id[0x03] lapic_id[0x06] disabled) [ 0.000000] ACPI: LAPIC (acpi_id[0x04] lapic_id[0x08] disabled) [ 0.000000] ACPI: LAPIC (acpi_id[0x05] lapic_id[0x0a] disabled) [ 0.000000] ACPI: LAPIC (acpi_id[0x06] lapic_id[0x0c] disabled) [ 0.000000] ACPI: LAPIC (acpi_id[0x07] lapic_id[0x0e] disabled) [ 0.000000] ACPI: LAPIC (acpi_id[0x08] lapic_id[0x10] disabled) [ 0.000000] ACPI: LAPIC (acpi_id[0x09] lapic_id[0x12] disabled) [ 0.000000] ACPI: LAPIC (acpi_id[0x0a] lapic_id[0x14] disabled) [ 0.000000] ACPI: LAPIC (acpi_id[0x0b] lapic_id[0x16] disabled) [ 0.000000] ACPI: LAPIC (acpi_id[0x0c] lapic_id[0x18] disabled) [ 0.000000] ACPI: LAPIC (acpi_id[0x0d] lapic_id[0x1a] disabled) [ 0.000000] ACPI: LAPIC (acpi_id[0x0e] lapic_id[0x1c] disabled) [ 0.000000] ACPI: IOAPIC (id[0x01] address[0xfec00000] gsi_base[0]) [ 0.000000] IOAPIC[0]: apic_id 1, version 17, address 0xfec00000, GSI 0-47 [ 0.000000] ACPI: INT_SRC_OVR (bus 0 bus_irq 0 global_irq 2 dfl dfl) [ 0.000000] ACPI: INT_SRC_OVR (bus 0 bus_irq 5 global_irq 5 low level) [ 0.000000] ACPI: INT_SRC_OVR (bus 0 bus_irq 10 global_irq 10 low level) [ 0.000000] ACPI: INT_SRC_OVR (bus 0 bus_irq 11 global_irq 11 low level) [ 0.000000] Using ACPI (MADT) for SMP configuration information [ 0.000000] SMP: Allowing 15 CPUs, 13 hotplug CPUs [ 0.000000] PM: Registered nosave memory: 000000000009e000 - 00000000000a0000 [ 0.000000] PM: Registered nosave memory: 00000000000a0000 - 00000000000e0000 [ 0.000000] PM: Registered nosave memory: 00000000000e0000 - 0000000000100000 [ 0.000000] Allocating PCI resources starting at 40000000 (gap: 40000000:bc000000) [ 0.000000] Booting paravirtualized kernel on Xen [ 0.000000] setup_percpu: NR_CPUS:256 nr_cpumask_bits:256 nr_cpu_ids:15 nr_node_ids:1 [ 0.000000] PERCPU: Embedded 28 pages/cpu @ffff88003fc00000 s84416 r8192 d22080 u131072 [ 0.000000] Built 1 zonelists in Node order, mobility grouping on. Total pages: 258440 [ 0.000000] Policy zone: DMA32 [ 0.000000] Kernel command line: BOOT_IMAGE=/boot/vmlinuz-2.6.38-11-server root=UUID=992cda33-09ce-4437-b110-fe153702b2d5 ro console=ttyS0,115200n8 [ 0.000000] PID hash table entries: 4096 (order: 3, 32768 bytes) [ 0.000000] Checking aperture... [ 0.000000] No AGP bridge found [ 0.000000] Memory: 1005640k/1048576k available (6025k kernel code, 456k absent, 42480k reserved, 5023k data, 880k init) [ 0.000000] SLUB: Genslabs=15, HWalign=64, Order=0-3, MinObjects=0, CPUs=15, Nodes=1 [ 0.000000] Hierarchical RCU implementation. [ 0.000000] RCU dyntick-idle grace-period acceleration is enabled. [ 0.000000] RCU-based detection of stalled CPUs is disabled. [ 0.000000] NR_IRQS:16640 nr_irqs:1208 16 [ 0.000000] Xen HVM callback vector for event delivery is enabled [ 0.000000] Console: colour VGA+ 80x25 [ 0.000000] console [ttyS0] enabled [ 0.000000] allocated 10485760 bytes of page_cgroup [ 0.000000] please try 'cgroup_disable=memory' option if you don't want memory cgroups [ 0.000000] Detected 2310.666 MHz processor. [ 0.000000] Marking TSC unstable due to TSCs unsynchronized [ 0.020000] Calibrating delay loop (skipped), value calculated using timer frequency.. 4621.33 BogoMIPS (lpj=23106660) [ 0.020000] pid_max: default: 32768 minimum: 301 [ 0.020000] Security Framework initialized [ 0.020017] AppArmor: AppArmor initialized [ 0.022379] Yama: becoming mindful. [ 0.024492] Dentry cache hash table entries: 131072 (order: 8, 1048576 bytes) [ 0.030212] Inode-cache hash table entries: 65536 (order: 7, 524288 bytes) [ 0.034272] Mount-cache hash table entries: 256 [ 0.036974] Initializing cgroup subsys ns [ 0.039353] ns_cgroup deprecated: consider using the 'clone_children' flag without the ns_cgroup. [ 0.040006] Initializing cgroup subsys cpuacct [ 0.042487] Initializing cgroup subsys memory [ 0.044947] Initializing cgroup subsys devices [ 0.050003] Initializing cgroup subsys freezer [ 0.052565] Initializing cgroup subsys net_cls [ 0.055068] Initializing cgroup subsys blkio [ 0.057554] CPU: Physical Processor ID: 0 [ 0.060003] CPU: Processor Core ID: 0 [ 0.062134] mce: CPU supports 6 MCE banks [ 0.064428] using C1E aware idle routine [ 0.072780] ACPI: Core revision 20110112 [ 0.080336] ftrace: allocating 24622 entries in 97 pages [ 0.111356] Not enabling x2apic, Intr-remapping init failed. [ 0.114662] Setting APIC routing to physical flat [ 0.119821] ..TIMER: vector=0x30 apic1=0 pin1=2 apic2=0 pin2=0 [ 0.223141] CPU0: AMD Athlon(tm) II X4 605e Processor stepping 02 [ 0.226829] installing Xen timer for CPU 0 [ 0.229223] Performance Events: Broken PMU hardware detected, using software events only. [ 0.230000] Booting Node 0, Processors #1 [ 0.020000] installing Xen timer for CPU 1 [ 0.380326] Brought up 2 CPUs [ 0.380329] Total of 2 processors activated (9269.66 BogoMIPS). [ 0.388283] devtmpfs: initialized [ 0.391072] print_constraints: dummy: [ 0.393194] Time: 9:32:46 Date: 09/06/11 [ 0.395524] NET: Registered protocol family 16 [ 0.395524] Trying to unpack rootfs image as initramfs... [ 0.395912] Extended Config Space enabled on 0 nodes [ 0.398792] ACPI: bus type pci registered [ 0.400372] PCI: Using configuration type 1 for base access [ 0.403546] PCI: Using configuration type 1 for extended access [ 0.410082] bio: create slab at 0 [ 0.416529] ACPI: Interpreter enabled [ 0.418836] ACPI: (supports S0 S3 S4 S5) [ 0.420925] ACPI: Using IOAPIC for interrupt routing [ 0.511326] ACPI: No dock devices found. [ 0.513604] HEST: Table not found. [ 0.515525] PCI: Using host bridge windows from ACPI; if necessary, use "pci=nocrs" and report a bug [ 0.520067] ACPI: PCI Root Bridge [PCI0] (domain 0000 [bus 00-ff]) [ 0.523641] pci_root PNP0A03:00: host bridge window [io 0x0000-0x0cf7] [ 0.527355] pci_root PNP0A03:00: host bridge window [io 0x0d00-0xffff] [ 0.530006] pci_root PNP0A03:00: host bridge window [mem 0x000a0000-0x000bffff] [ 0.534100] pci_root PNP0A03:00: host bridge window [mem 0xe0000000-0xfbffffff] [ 0.544468] * Found PM-Timer Bug on the chipset. Due to workarounds for a bug, [ 0.544469] * this clock source is slow. Consider trying other clock sources [ 0.552017] pci 0000:00:01.3: quirk: [io 0xb000-0xb03f] claimed by PIIX4 ACPI [ 0.740691] Freeing initrd memory: 12832k freed [ 0.748045] pci0000:00: Requesting ACPI _OSC control (0x1d) [ 0.965735] ACPI: PCI Interrupt Link [LNKA] (IRQs *5 10 11) [ 0.969433] ACPI: PCI Interrupt Link [LNKB] (IRQs 5 *10 11) [ 0.971167] ACPI: PCI Interrupt Link [LNKC] (IRQs 5 10 *11) [ 0.974807] ACPI: PCI Interrupt Link [LNKD] (IRQs *5 10 11) [ 0.978568] vgaarb: device added: PCI:0000:00:02.0,decodes=io+mem,owns=io+mem,locks=none [ 0.990078] vgaarb: device added: PCI:0000:00:07.0,decodes=io+mem,owns=io+mem,locks=none [ 0.994573] vgaarb: loaded [ 0.996244] SCSI subsystem initialized [ 1.000093] usbcore: registered new interface driver usbfs [ 1.003223] usbcore: registered new interface driver hub [ 1.006226] usbcore: registered new device driver usb [ 1.006226] wmi: Mapper loaded [ 1.010010] PCI: Using ACPI for IRQ routing [ 1.013572] NetLabel: Initializing [ 1.015495] NetLabel: domain hash size = 128 [ 1.018030] NetLabel: protocols = UNLABELED CIPSOv4 [ 1.020031] NetLabel: unlabeled traffic allowed by default [ 1.023248] Switching to clocksource xen [ 1.025579] Switched to NOHz mode on CPU #0 [ 1.028188] AppArmor: AppArmor Filesystem Enabled [ 1.030968] pnp: PnP ACPI init [ 1.032754] ACPI: bus type pnp registered [ 1.034172] Switched to NOHz mode on CPU #1 [ 1.037586] system 00:00: [mem 0x00000000-0x0009ffff] could not be reserved [ 1.041744] system 00:02: [io 0x10c0-0x1141] has been reserved [ 1.045183] system 00:02: [io 0xb044-0xb047] has been reserved [ 1.048623] system 00:03: [io 0x08a0-0x08a3] has been reserved [ 1.051973] system 00:03: [io 0x0cc0-0x0ccf] has been reserved [ 1.055282] system 00:03: [io 0x04d0-0x04d1] has been reserved [ 1.058851] xen map irq failed -22 [ 1.060887] xen map irq failed -22 [ 1.081196] pnp: PnP ACPI: found 12 devices [ 1.083554] ACPI: ACPI bus type pnp unregistered [ 1.092156] NET: Registered protocol family 2 [ 1.094789] IP route cache hash table entries: 32768 (order: 6, 262144 bytes) [ 1.099106] TCP established hash table entries: 131072 (order: 9, 2097152 bytes) [ 1.104004] TCP bind hash table entries: 65536 (order: 8, 1048576 bytes) [ 1.108147] TCP: Hash tables configured (established 131072 bind 65536) [ 1.111884] TCP reno registered [ 1.113664] UDP hash table entries: 512 (order: 2, 16384 bytes) [ 1.116998] UDP-Lite hash table entries: 512 (order: 2, 16384 bytes) [ 1.120701] NET: Registered protocol family 1 [ 1.123176] pci 0000:00:00.0: Limiting direct PCI/PCI transfers [ 1.126564] pci 0000:00:01.0: PIIX3: Enabling Passive Release [ 1.129893] pci 0000:00:01.0: Activating ISA DMA hang workarounds [ 1.134583] audit: initializing netlink socket (disabled) [ 1.137645] type=2000 audit(1315301567.994:1): initialized [ 1.153417] HugeTLB registered 2 MB page size, pre-allocated 0 pages [ 1.158877] VFS: Disk quotas dquot_6.5.2 [ 1.161436] Dquot-cache hash table entries: 512 (order 0, 4096 bytes) [ 1.165852] fuse init (API version 7.16) [ 1.168342] msgmni has been set to 1989 [ 1.171050] Block layer SCSI generic (bsg) driver version 0.4 loaded (major 253) [ 1.175353] io scheduler noop registered [ 1.177762] io scheduler deadline registered (default) [ 1.180800] io scheduler cfq registered [ 1.183039] pci_hotplug: PCI Hot Plug PCI Core version: 0.5 [ 1.186209] pciehp: PCI Express Hot Plug Controller Driver version: 0.4 [ 1.190088] input: Power Button as /devices/LNXSYSTM:00/LNXPWRBN:00/input/input0 [ 1.194255] ACPI: Power Button [PWRF] [ 1.196434] input: Sleep Button as /devices/LNXSYSTM:00/LNXSLPBN:00/input/input1 [ 1.200581] ACPI: Sleep Button [SLPF] [ 1.223961] ERST: Table is not found! [ 1.226148] Serial: 8250/16550 driver, 32 ports, IRQ sharing enabled [ 1.259267] serial8250: ttyS0 at I/O 0x3f8 (irq = 4) is a 16550A [ 1.684123] 00:0a: ttyS0 at I/O 0x3f8 (irq = -1) is a 16550A [ 1.730567] Linux agpgart interface v0.103 [ 1.740279] brd: module loaded [ 1.746799] loop: module loaded [ 1.752586] i2c-core: driver [adp5520] using legacy suspend method [ 1.762057] i2c-core: driver [adp5520] using legacy resume method [ 1.766556] scsi0 : ata_piix [ 1.768540] scsi1 : ata_piix [ 1.770268] ata1: PATA max MWDMA2 cmd 0x1f0 ctl 0x3f6 bmdma 0xc200 irq 14 [ 1.774155] ata2: PATA max MWDMA2 cmd 0x170 ctl 0x376 bmdma 0xc208 irq 15 [ 1.778271] Fixed MDIO Bus: probed [ 1.781705] PPP generic driver version 2.4.2 [ 1.784245] tun: Universal TUN/TAP device driver, 1.6 [ 1.787090] tun: (C) 1999-2004 Max Krasnyansky [ 1.790724] ehci_hcd: USB 2.0 'Enhanced' Host Controller (EHCI) Driver [ 1.794629] ehci_hcd 0000:00:05.0: PCI INT B -> GSI 37 (level, low) -> IRQ 37 [ 1.798833] ehci_hcd 0000:00:05.0: EHCI Host Controller [ 1.801846] ehci_hcd 0000:00:05.0: new USB bus registered, assigned bus number 1 [ 1.820185] ehci_hcd 0000:00:05.0: applying AMD SB700/SB800/Hudson-2/3 EHCI dummy qh workaround [ 1.830676] ehci_hcd 0000:00:05.0: irq 37, io mem 0xf204a000 [ 1.850148] ehci_hcd 0000:00:05.0: USB 2.0 started, EHCI 1.00 [ 1.855577] hub 1-0:1.0: USB hub found [ 1.858938] hub 1-0:1.0: 5 ports detected [ 1.862632] ohci_hcd: USB 1.1 'Open' Host Controller (OHCI) Driver [ 1.868229] ohci_hcd 0000:00:04.0: PCI INT A -> GSI 32 (level, low) -> IRQ 32 [ 1.874697] ohci_hcd 0000:00:04.0: OHCI Host Controller [ 1.879340] ohci_hcd 0000:00:04.0: new USB bus registered, assigned bus number 2 [ 1.884393] ohci_hcd 0000:00:04.0: irq 32, io mem 0xf2049000 [ 1.939803] ata1.00: ATA-7: QEMU HARDDISK, 0.10.2, max UDMA/100 [ 1.949772] ata1.00: 20971520 sectors, multi 16: LBA48 [ 1.962625] ata1.00: configured for MWDMA2 [ 1.965089] scsi 0:0:0:0: Direct-Access ATA QEMU HARDDISK 0.10 PQ: 0 ANSI: 5 [ 1.966108] hub 2-0:1.0: USB hub found [ 1.966114] hub 2-0:1.0: 5 ports detected [ 1.966177] uhci_hcd: USB Universal Host Controller Interface driver [ 1.966273] i8042: PNP: PS/2 Controller [PNP0303:PS2K,PNP0f13:PS2M] at 0x60,0x64 irq 1,12 [ 1.983548] sd 0:0:0:0: Attached scsi generic sg0 type 0 [ 1.984869] serio: i8042 KBD port at 0x60,0x64 irq 1 [ 1.984883] serio: i8042 AUX port at 0x60,0x64 irq 12 [ 1.984991] mousedev: PS/2 mouse device common for all mice [ 1.985271] sd 0:0:0:0: [sda] 20971520 512-byte logical blocks: (10.7 GB/10.0 GiB) [ 1.985308] sd 0:0:0:0: [sda] Write Protect is off [ 1.985326] sd 0:0:0:0: [sda] Write cache: disabled, read cache: enabled, doesn't support DPO or FUA [ 2.009551] input: AT Translated Set 2 keyboard as /devices/platform/i8042/serio0/input/input2 [ 2.040271] rtc_cmos 00:05: rtc core: registered rtc_cmos as rtc0 [ 2.048384] rtc0: alarms up to one day, 114 bytes nvram [ 2.057499] device-mapper: uevent: version 1.0.3 [ 2.063184] device-mapper: ioctl: 4.19.1-ioctl (2011-01-07) initialised: dm-devel@redhat.com [ 2.068047] device-mapper: multipath: version 1.2.0 loaded [ 2.071142] device-mapper: multipath round-robin: version 1.0.0 loaded [ 2.075069] cpuidle: using governor ladder [ 2.077378] cpuidle: using governor menu [ 2.079819] TCP cubic registered [ 2.081843] NET: Registered protocol family 10 [ 2.084855] NET: Registered protocol family 17 [ 2.087524] Registering the dns_resolver key type [ 2.090350] registered taskstats version 1 [ 2.094361] Magic number: 11:897:524 [ 2.096602] rtc_cmos 00:05: setting system clock to 2011-09-06 09:32:48 UTC (1315301568) [ 2.101024] BIOS EDD facility v0.16 2004-Jun-25, 0 devices found [ 2.104347] EDD information not available. [ 2.480195] usb 2-2: new low speed USB device using ohci_hcd and address 2 [ 32.060398] ata1: lost interrupt (Status 0x50) [ 32.068260] ata1.00: exception Emask 0x0 SAct 0x0 SErr 0x0 action 0x6 frozen [ 32.079927] ata1.00: failed command: READ DMA [ 32.083923] ata1.00: cmd c8/00:08:00:00:00/00:00:00:00:00/e0 tag 0 dma 4096 in [ 32.083924] res 40/00:00:00:00:00/00:00:00:00:00/00 Emask 0x4 (timeout) [ 32.092282] ata1.00: status: { DRDY } [ 32.094728] ata1: soft resetting link [ 32.261020] ata1.00: configured for MWDMA2 [ 32.267841] ata1.00: device reported invalid CHS sector 0 [ 32.276828] ata1: EH complete --------------050404030308050904030304 Content-Type: text/plain; name="6-Natty-config" Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename="6-Natty-config" kernel = "hvmloader" builder='hvm' memory = 1024 name = "ubuntu-mediacenter" vcpus=2 vif = ['mac=00:26:3E:12:33:33, bridge=xenbrI'] disk = ['phy:/dev/vg/ubuntu-mediacenter,xvda,w'] on_poweroff = 'destroy' on_reboot = 'restart' on_crash = 'restart' device_model='qemu-dm' sdl=0 opengl=1 vnc=1 vnclisten="0.0.0.0" vncpasswd='' stdvga=0 keymap='de' pci = [ '00:13.0','00:13.2','00:14.2','00:01:00.0,1' ] shadow_memory = 32 xen_platform_pci=1 serial='pty' --------------050404030308050904030304 Content-Type: text/plain; name="7-Natty-xm_dmesg_2.6.32" Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename="7-Natty-xm_dmesg_2.6.32" xm dmesg (XEN) Xen version 4.1.1 (Debian 4.1.1-2) (waldi@debian.org) (gcc version 4.6.1 (Debian 4.6.1-5) ) Fri Aug 5 21:59:51 UTC 2011 (XEN) Bootloader: GRUB 1.99-11 (XEN) Command line: placeholder (XEN) Video information: (XEN) VGA is text mode 80x25, font 8x16 (XEN) VBE/DDC methods: V2; EDID transfer time: 1 seconds (XEN) Disc information: (XEN) Found 3 MBR signatures (XEN) Found 3 EDD information structures (XEN) Xen-e820 RAM map: (XEN) 0000000000000000 - 0000000000098800 (usable) (XEN) 000000000009f800 - 00000000000a0000 (reserved) (XEN) 00000000000f0000 - 0000000000100000 (reserved) (XEN) 0000000000100000 - 00000000cfcf0000 (usable) (XEN) 00000000cfcf0000 - 00000000cfcf1000 (ACPI NVS) (XEN) 00000000cfcf1000 - 00000000cfd00000 (ACPI data) (XEN) 00000000cfd00000 - 00000000cfe00000 (reserved) (XEN) 00000000e0000000 - 00000000f0000000 (reserved) (XEN) 00000000fec00000 - 0000000100000000 (reserved) (XEN) 0000000100000000 - 0000000230000000 (usable) (XEN) ACPI: RSDP 000F6080, 0014 (r0 GBT ) (XEN) ACPI: RSDT CFCF1000, 0044 (r1 GBT GBTUACPI 42302E31 GBTU 1010101) (XEN) ACPI: FACP CFCF1080, 0074 (r1 GBT GBTUACPI 42302E31 GBTU 1010101) (XEN) ACPI: DSDT CFCF1100, 7BE1 (r1 GBT GBTUACPI 1000 MSFT 3000000) (XEN) ACPI: FACS CFCF0000, 0040 (XEN) ACPI: SSDT CFCF8DC0, 088C (r1 PTLTD POWERNOW 1 LTP 1) (XEN) ACPI: HPET CFCF9680, 0038 (r1 GBT GBTUACPI 42302E31 GBTU 98) (XEN) ACPI: MCFG CFCF96C0, 003C (r1 GBT GBTUACPI 42302E31 GBTU 1010101) (XEN) ACPI: MATS CFCF9700, 0034 (r1 GBT 0 0) (XEN) ACPI: TAMG CFCF9770, 048A (r1 GBT GBT B0 5455312E BG 53450101) (XEN) ACPI: APIC CFCF8D00, 00BC (r1 GBT GBTUACPI 42302E31 GBTU 1010101) (XEN) ACPI: IVRS CFCF9C70, 00E8 (r1 AMD RD890S 202031 AMD 0) (XEN) System RAM: 8188MB (8385056kB) (XEN) Domain heap initialised (XEN) Processor #0 0:5 APIC version 16 (XEN) Processor #1 0:5 APIC version 16 (XEN) Processor #2 0:5 APIC version 16 (XEN) Processor #3 0:5 APIC version 16 (XEN) IOAPIC[0]: apic_id 2, version 33, address 0xfec00000, GSI 0-23 (XEN) Enabling APIC mode: Flat. Using 1 I/O APICs (XEN) Table is not found! (XEN) Using scheduler: SMP Credit Scheduler (credit) (XEN) Detected 2310.666 MHz processor. (XEN) Initing memory sharing. (XEN) AMD-Vi: IOMMU 0 Enabled. (XEN) I/O virtualisation enabled (XEN) - Dom0 mode: Relaxed (XEN) ENABLING IO-APIC IRQs (XEN) -> Using new ACK method (XEN) Platform timer is 14.318MHz HPET (XEN) Allocated console ring of 16 KiB. (XEN) HVM: ASIDs enabled. (XEN) SVM: Supported advanced features: (XEN) - Nested Page Tables (NPT) (XEN) - Last Branch Record (LBR) Virtualisation (XEN) - Next-RIP Saved on #VMEXIT (XEN) HVM: SVM enabled (XEN) HVM: Hardware Assisted Paging detected. (XEN) do_IRQ: 1.231 No irq handler for vector (irq -1) (XEN) do_IRQ: 2.231 No irq handler for vector (irq -1) (XEN) Brought up 4 CPUs (XEN) do_IRQ: 3.231 No irq handler for vector (irq -1) (XEN) Xenoprofile: AMD IBS detected (0x0000001f) (XEN) *** LOADING DOMAIN 0 *** (XEN) Xen kernel: 64-bit, lsb, compat32 (XEN) Dom0 kernel: 64-bit, PAE, lsb, paddr 0x1000000 -> 0x16ba000 (XEN) PHYSICAL MEMORY ARRANGEMENT: (XEN) Dom0 alloc.: 0000000220000000->0000000224000000 (2010429 pages to be allocated) (XEN) Init. ramdisk: 000000022e1bf000->000000022ffffe00 (XEN) VIRTUAL MEMORY ARRANGEMENT: (XEN) Loaded kernel: ffffffff81000000->ffffffff816ba000 (XEN) Init. ramdisk: ffffffff816ba000->ffffffff834fae00 (XEN) Phys-Mach map: ffffffff834fb000->ffffffff84480bf0 (XEN) Start info: ffffffff84481000->ffffffff844814b4 (XEN) Page tables: ffffffff84482000->ffffffff844a9000 (XEN) Boot stack: ffffffff844a9000->ffffffff844aa000 (XEN) TOTAL: ffffffff80000000->ffffffff84800000 (XEN) ENTRY ADDRESS: ffffffff81509200 (XEN) Dom0 has maximum 4 VCPUs (XEN) Scrubbing Free RAM: .done. (XEN) Xen trace buffers: disabled (XEN) Std. Loglevel: Errors and warnings (XEN) Guest Loglevel: Nothing (Rate-limited: Errors and warnings) (XEN) Xen is relinquishing VGA console. (XEN) *** Serial input -> DOM0 (type 'CTRL-a' three times to switch input to Xen) (XEN) Freed 224kB init memory. (XEN) traps.c:2388:d0 Domain attempted WRMSR 00000000c0010004 from 0x00002dc7991b856e to 0x0000000000000000. (XEN) traps.c:2388:d0 Domain attempted WRMSR 00000000c0010000 from 0x0000020ef19dc23e to 0x0000000000430076. (XEN) traps.c:2388:d0 Domain attempted WRMSR 00000000c0010048 from 0x0000000000780000 to 0x0000000000780400. (XEN) traps.c:2388:d0 Domain attempted WRMSR 00000000c0010048 from 0x0000000000780000 to 0x0000000000780400. (XEN) traps.c:2388:d0 Domain attempted WRMSR 00000000c0010048 from 0x0000000000780000 to 0x0000000000780400. (XEN) traps.c:2388:d0 Domain attempted WRMSR 00000000c0010048 from 0x0000000000780000 to 0x0000000000780400. (XEN) physdev.c:170: dom3: 18:-1 already mapped to 16 (XEN) physdev.c:170: dom4: 18:-1 already mapped to 16 (XEN) irq.c:1817: dom4: invalid pirq -28 or emuirq 4 (XEN) irq.c:1817: dom4: invalid pirq -28 or emuirq 7 (XEN) irq.c:1817: dom4: invalid pirq -28 or emuirq 28 (XEN) physdev.c:170: dom5: 18:-1 already mapped to 16 (XEN) irq.c:1817: dom5: invalid pirq -28 or emuirq 4 (XEN) irq.c:1817: dom5: invalid pirq -28 or emuirq 7 (XEN) irq.c:1817: dom5: invalid pirq -28 or emuirq 28 (XEN) physdev.c:170: dom9: 18:-1 already mapped to 16 (XEN) irq.c:1817: dom9: invalid pirq -28 or emuirq 4 (XEN) irq.c:1817: dom9: invalid pirq -28 or emuirq 7 (XEN) irq.c:1817: dom9: invalid pirq -28 or emuirq 28 (XEN) physdev.c:170: dom10: 18:-1 already mapped to 16 (XEN) irq.c:1817: dom10: invalid pirq -28 or emuirq 4 (XEN) irq.c:1817: dom10: invalid pirq -28 or emuirq 7 (XEN) irq.c:1817: dom10: invalid pirq -28 or emuirq 28 (XEN) physdev.c:170: dom11: 18:-1 already mapped to 16 (XEN) irq.c:1817: dom11: invalid pirq -28 or emuirq 4 (XEN) irq.c:1817: dom11: invalid pirq -28 or emuirq 7 (XEN) physdev.c:170: dom12: 18:-1 already mapped to 16 (XEN) physdev.c:170: dom13: 18:-1 already mapped to 16 --------------050404030308050904030304 Content-Type: text/plain; name="8-Dom0-Grub" Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename="8-Dom0-Grub" menuentry 'Debian GNU/Linux, mit Xen 4.1-amd64 und Linux 2.6.32-5-xen-amd64' --class debian --class gnu-linux --class gnu --class os --class xen { insmod part_msdos insmod ext2 set root='(hd2,msdos1)' search --no-floppy --fs-uuid --set=root 5dc5d1f3-ff05-4a98-8438-72c656ec0d7d echo 'Xen 4.1-amd64 wird geladen ...' multiboot /xen-4.1-amd64.gz placeholder echo 'Linux 2.6.32-5-xen-amd64 wird geladen ...' module /vmlinuz-2.6.32-5-xen-amd64 placeholder root=/dev/mapper/vg2-root ro xen-pciback.hide=(08:06.0)(03:00.0)(00:14.2)(00:13.0)(00:13.2)(01:00.1)(01:00.0) echo 'Initiale Ramdisk wird geladen ...' module /initrd.img-2.6.32-5-xen-amd64 } --------------050404030308050904030304 Content-Type: text/plain; charset=UTF-8; name="5-Natty-working-with-passthrough-debian-2.6.32" Content-Transfer-Encoding: 8bit Content-Disposition: attachment; filename="5-Natty-working-with-passthrough-debian-2.6.32" xm create ubuntu-mediacenter.cfg -c Using config file "./ubuntu-mediacenter.cfg". Started domain ubuntu-mediacenter (id=13) [ 0.000000] Initializing cgroup subsys cpuset [ 0.000000] Initializing cgroup subsys cpu [ 0.000000] Linux version 2.6.32-5-xen-amd64 (Debian 2.6.32-35) (dannf@debian.org) (gcc version 4.3.5 (Debian 4.3.5-4) ) #1 SMP Tue Jun 14 12:46:30 UTC 2011 [ 0.000000] Command line: BOOT_IMAGE=/boot/vmlinuz-2.6.32-5-xen-amd64 root=UUID=992cda33-09ce-4437-b110-fe153702b2d5 ro console=ttyS0,115200n8 [ 0.000000] KERNEL supported cpus: [ 0.000000] Intel GenuineIntel [ 0.000000] AMD AuthenticAMD [ 0.000000] Centaur CentaurHauls [ 0.000000] BIOS-provided physical RAM map: [ 0.000000] BIOS-e820: 0000000000000000 - 000000000009e000 (usable) [ 0.000000] BIOS-e820: 000000000009e000 - 00000000000a0000 (reserved) [ 0.000000] BIOS-e820: 00000000000e0000 - 0000000000100000 (reserved) [ 0.000000] BIOS-e820: 0000000000100000 - 0000000040000000 (usable) [ 0.000000] BIOS-e820: 00000000fc000000 - 0000000100000000 (reserved) [ 0.000000] DMI 2.4 present. [ 0.000000] last_pfn = 0x40000 max_arch_pfn = 0x400000000 [ 0.000000] x86 PAT enabled: cpu 0, old 0x7040600070406, new 0x7010600070106 [ 0.000000] init_memory_mapping: 0000000000000000-0000000040000000 [ 0.000000] RAMDISK: 36970000 - 374af29e [ 0.000000] ACPI: RSDP 00000000000ea020 00024 (v02 Xen) [ 0.000000] ACPI: XSDT 00000000fc0134b0 00034 (v01 Xen HVM 00000000 HVML 00000000) [ 0.000000] ACPI: FACP 00000000fc0132d0 000F4 (v04 Xen HVM 00000000 HVML 00000000) [ 0.000000] ACPI: DSDT 00000000fc003440 0FE05 (v02 Xen HVM 00000000 INTL 20100528) [ 0.000000] ACPI: FACS 00000000fc003400 00040 [ 0.000000] ACPI: APIC 00000000fc0133d0 000D8 (v02 Xen HVM 00000000 HVML 00000000) [ 0.000000] No NUMA configuration found [ 0.000000] Faking a node at 0000000000000000-0000000040000000 [ 0.000000] Bootmem setup node 0 0000000000000000-0000000040000000 [ 0.000000] NODE_DATA [0000000000008000 - 000000000000ffff] [ 0.000000] bootmap [0000000000010000 - 0000000000017fff] pages 8 [ 0.000000] (6 early reservations) ==> bootmem [0000000000 - 0040000000] [ 0.000000] #0 [0000000000 - 0000001000] BIOS data page ==> [0000000000 - 0000001000] [ 0.000000] #1 [0000006000 - 0000008000] TRAMPOLINE ==> [0000006000 - 0000008000] [ 0.000000] #2 [0001000000 - 00016999d4] TEXT DATA BSS ==> [0001000000 - 00016999d4] [ 0.000000] #3 [0036970000 - 00374af29e] RAMDISK ==> [0036970000 - 00374af29e] [ 0.000000] #4 [000009e000 - 0000100000] BIOS reserved ==> [000009e000 - 0000100000] [ 0.000000] #5 [000169a000 - 000169a0c0] BRK ==> [000169a000 - 000169a0c0] [ 0.000000] found SMP MP-table at [ffff8800000fbc90] fbc90 [ 0.000000] Zone PFN ranges: [ 0.000000] DMA 0x00000000 -> 0x00001000 [ 0.000000] DMA32 0x00001000 -> 0x00100000 [ 0.000000] Normal 0x00100000 -> 0x00100000 [ 0.000000] Movable zone start PFN for each node [ 0.000000] early_node_map[2] active PFN ranges [ 0.000000] 0: 0x00000000 -> 0x0000009e [ 0.000000] 0: 0x00000100 -> 0x00040000 [ 0.000000] ACPI: PM-Timer IO Port: 0xb008 [ 0.000000] ACPI: LAPIC (acpi_id[0x00] lapic_id[0x00] enabled) [ 0.000000] ACPI: LAPIC (acpi_id[0x01] lapic_id[0x02] enabled) [ 0.000000] ACPI: LAPIC (acpi_id[0x02] lapic_id[0x04] disabled) [ 0.000000] ACPI: LAPIC (acpi_id[0x03] lapic_id[0x06] disabled) [ 0.000000] ACPI: LAPIC (acpi_id[0x04] lapic_id[0x08] disabled) [ 0.000000] ACPI: LAPIC (acpi_id[0x05] lapic_id[0x0a] disabled) [ 0.000000] ACPI: LAPIC (acpi_id[0x06] lapic_id[0x0c] disabled) [ 0.000000] ACPI: LAPIC (acpi_id[0x07] lapic_id[0x0e] disabled) [ 0.000000] ACPI: LAPIC (acpi_id[0x08] lapic_id[0x10] disabled) [ 0.000000] ACPI: LAPIC (acpi_id[0x09] lapic_id[0x12] disabled) [ 0.000000] ACPI: LAPIC (acpi_id[0x0a] lapic_id[0x14] disabled) [ 0.000000] ACPI: LAPIC (acpi_id[0x0b] lapic_id[0x16] disabled) [ 0.000000] ACPI: LAPIC (acpi_id[0x0c] lapic_id[0x18] disabled) [ 0.000000] ACPI: LAPIC (acpi_id[0x0d] lapic_id[0x1a] disabled) [ 0.000000] ACPI: LAPIC (acpi_id[0x0e] lapic_id[0x1c] disabled) [ 0.000000] ACPI: IOAPIC (id[0x01] address[0xfec00000] gsi_base[0]) [ 0.000000] IOAPIC[0]: apic_id 1, version 17, address 0xfec00000, GSI 0-47 [ 0.000000] ACPI: INT_SRC_OVR (bus 0 bus_irq 0 global_irq 2 dfl dfl) [ 0.000000] ACPI: INT_SRC_OVR (bus 0 bus_irq 5 global_irq 5 low level) [ 0.000000] ACPI: INT_SRC_OVR (bus 0 bus_irq 10 global_irq 10 low level) [ 0.000000] ACPI: INT_SRC_OVR (bus 0 bus_irq 11 global_irq 11 low level) [ 0.000000] Using ACPI (MADT) for SMP configuration information [ 0.000000] SMP: Allowing 15 CPUs, 13 hotplug CPUs [ 0.000000] Xen version 4.1. [ 0.000000] Netfront and the Xen platform PCI driver have been compiled for this kernel: unplug emulated NICs. [ 0.000000] Blkfront and the Xen platform PCI driver have been compiled for this kernel: unplug emulated disks. [ 0.000000] You might have to change the root device [ 0.000000] from /dev/hd[a-d] to /dev/xvd[a-d] [ 0.000000] in your root= kernel command line option [ 0.000000] PM: Registered nosave memory: 000000000009e000 - 00000000000a0000 [ 0.000000] PM: Registered nosave memory: 00000000000a0000 - 00000000000e0000 [ 0.000000] PM: Registered nosave memory: 00000000000e0000 - 0000000000100000 [ 0.000000] Allocating PCI resources starting at 40000000 (gap: 40000000:bc000000) [ 0.000000] Booting paravirtualized kernel on Xen [ 0.000000] NR_CPUS:512 nr_cpumask_bits:512 nr_cpu_ids:15 nr_node_ids:1 [ 0.000000] PERCPU: Embedded 30 pages/cpu @ffff880001800000 s90328 r8192 d24360 u131072 [ 0.000000] pcpu-alloc: s90328 r8192 d24360 u131072 alloc=1*2097152 [ 0.000000] pcpu-alloc: [0] 00 01 02 03 04 05 06 07 08 09 10 11 12 13 14 -- [ 0.000000] Built 1 zonelists in Node order, mobility grouping on. Total pages: 258361 [ 0.000000] Policy zone: DMA32 [ 0.000000] Kernel command line: BOOT_IMAGE=/boot/vmlinuz-2.6.32-5-xen-amd64 root=UUID=992cda33-09ce-4437-b110-fe153702b2d5 ro console=ttyS0,115200n8 [ 0.000000] PID hash table entries: 4096 (order: 3, 32768 bytes) [ 0.000000] Initializing CPU#0 [ 0.000000] Checking aperture... [ 0.000000] No AGP bridge found [ 0.000000] Memory: 1013436k/1048576k available (3149k kernel code, 392k absent, 34748k reserved, 1906k data, 604k init) [ 0.000000] SLUB: Genslabs=14, HWalign=64, Order=0-3, MinObjects=0, CPUs=15, Nodes=1 [ 0.000000] Hierarchical RCU implementation. [ 0.000000] NR_IRQS:4352 nr_irqs:936 [ 0.000000] Xen HVM callback vector for event delivery is enabled [ 0.000000] Console: colour VGA+ 80x25 [ 0.000000] console [ttyS0] enabled [ 0.000000] Detected 2310.666 MHz processor. [ 0.008000] Calibrating delay loop (skipped), value calculated using timer frequency.. 4621.33 BogoMIPS (lpj=9242664) [ 0.008020] Security Framework initialized [ 0.010256] SELinux: Disabled at boot. [ 0.012082] Dentry cache hash table entries: 131072 (order: 8, 1048576 bytes) [ 0.016288] Inode-cache hash table entries: 65536 (order: 7, 524288 bytes) [ 0.020148] Mount-cache hash table entries: 256 [ 0.024113] Initializing cgroup subsys ns [ 0.026354] Initializing cgroup subsys cpuacct [ 0.028006] Initializing cgroup subsys devices [ 0.030459] Initializing cgroup subsys freezer [ 0.032003] Initializing cgroup subsys net_cls [ 0.036081] CPU: L1 I Cache: 64K (64 bytes/line), D cache 64K (64 bytes/line) [ 0.040004] CPU: L2 Cache: 512K (64 bytes/line) [ 0.042473] CPU 0/0x0 -> Node 0 [ 0.044011] CPU: Physical Processor ID: 0 [ 0.046241] CPU: Processor Core ID: 0 [ 0.048005] mce: CPU supports 6 MCE banks [ 0.050227] using C1E aware idle routine [ 0.052003] Performance Events: AMD PMU driver. [ 0.054611] ... version: 0 [ 0.056003] ... bit width: 48 [ 0.060003] ... generic registers: 4 [ 0.062196] ... value mask: 0000ffffffffffff [ 0.064003] ... max period: 00007fffffffffff [ 0.068003] ... fixed-purpose events: 0 [ 0.070191] ... event mask: 000000000000000f [ 0.074037] ACPI: Core revision 20090903 [ 0.090928] Not enabling x2apic, Intr-remapping init failed. [ 0.092004] Setting APIC routing to physical flat [ 0.098517] ..TIMER: vector=0x30 apic1=0 pin1=2 apic2=0 pin2=0 [ 0.142247] CPU0: AMD Athlon(tm) II X4 605e Processor stepping 02 [ 0.144740] installing Xen timer for CPU 0 [ 0.148178] Booting processor 1 APIC 0x2 ip 0x6000 [ 0.008000] Initializing CPU#1 [ 0.008000] CPU: L1 I Cache: 64K (64 bytes/line), D cache 64K (64 bytes/line) [ 0.008000] CPU: L2 Cache: 512K (64 bytes/line) [ 0.008000] CPU 1/0x2 -> Node 0 [ 0.008000] CPU: Physical Processor ID: 0 [ 0.008000] CPU: Processor Core ID: 2 [ 0.008000] installing Xen timer for CPU 1 [ 0.240204] CPU1: AMD Athlon(tm) II X4 605e Processor stepping 02 [ 0.240310] Brought up 2 CPUs [ 0.240312] Total of 2 processors activated (9308.40 BogoMIPS). [ 0.244150] devtmpfs: initialized [ 0.248845] regulator: core version 0.5 [ 0.250418] NET: Registered protocol family 16 [ 0.252221] ACPI: bus type pci registered [ 0.254797] PCI: Using configuration type 1 for base access [ 0.260005] PCI: Using configuration type 1 for extended access [ 0.264036] bio: create slab at 0 [ 0.311324] ACPI: Interpreter enabled [ 0.312006] ACPI: (supports S0 S3 S4 S5) [ 0.314466] ACPI: Using IOAPIC for interrupt routing [ 0.404032] ACPI: No dock devices found. [ 0.406408] ACPI: PCI Root Bridge [PCI0] (0000:00) [ 0.416778] * Found PM-Timer Bug on the chipset. Due to workarounds for a bug, [ 0.416779] * this clock source is slow. Consider trying other clock sources [ 0.425199] pci 0000:00:01.3: quirk: region b000-b03f claimed by PIIX4 ACPI [ 0.901613] ACPI: PCI Interrupt Link [LNKA] (IRQs *5 10 11) [ 0.905339] ACPI: PCI Interrupt Link [LNKB] (IRQs 5 *10 11) [ 0.908920] ACPI: PCI Interrupt Link [LNKC] (IRQs 5 10 *11) [ 0.912578] ACPI: PCI Interrupt Link [LNKD] (IRQs *5 10 11) [ 0.916247] vgaarb: device added: PCI:0000:00:02.0,decodes=io+mem,owns=io+mem,locks=none [ 0.920102] vgaarb: device added: PCI:0000:00:08.0,decodes=io+mem,owns=io+mem,locks=none [ 0.924006] vgaarb: loaded [ 0.928063] PCI: Using ACPI for IRQ routing [ 0.932646] Switching to clocksource xen [ 0.934861] pnp: PnP ACPI init [ 0.934861] ACPI: bus type pnp registered [ 0.978560] pnp: PnP ACPI: found 12 devices [ 0.980876] ACPI: ACPI bus type pnp unregistered [ 0.983431] system 00:00: iomem range 0x0-0x9ffff could not be reserved [ 0.987067] system 00:02: ioport range 0x10c0-0x1141 has been reserved [ 0.990716] system 00:02: ioport range 0xb044-0xb047 has been reserved [ 0.994398] system 00:03: ioport range 0x8a0-0x8a3 has been reserved [ 0.998018] system 00:03: ioport range 0xcc0-0xccf has been reserved [ 1.001591] system 00:03: ioport range 0x4d0-0x4d1 has been reserved [ 1.010138] NET: Registered protocol family 2 [ 1.012686] IP route cache hash table entries: 32768 (order: 6, 262144 bytes) [ 1.016956] TCP established hash table entries: 131072 (order: 9, 2097152 bytes) [ 1.021660] TCP bind hash table entries: 65536 (order: 8, 1048576 bytes) [ 1.025691] TCP: Hash tables configured (established 131072 bind 65536) [ 1.029401] TCP reno registered [ 1.031302] NET: Registered protocol family 1 [ 1.033718] pci 0000:00:00.0: Limiting direct PCI/PCI transfers [ 1.037050] pci 0000:00:01.0: PIIX3: Enabling Passive Release [ 1.040276] pci 0000:00:01.0: Activating ISA DMA hang workarounds [ 1.044150] Unpacking initramfs... [ 1.262942] Freeing initrd memory: 11516k freed [ 1.268817] audit: initializing netlink socket (disabled) [ 1.271914] type=2000 audit(1315301804.216:1): initialized [ 1.277900] HugeTLB registered 2 MB page size, pre-allocated 0 pages [ 1.282790] VFS: Disk quotas dquot_6.5.2 [ 1.285182] Dquot-cache hash table entries: 512 (order 0, 4096 bytes) [ 1.288813] msgmni has been set to 2001 [ 1.291409] alg: No test for stdrng (krng) [ 1.293804] Block layer SCSI generic (bsg) driver version 0.4 loaded (major 253) [ 1.297920] io scheduler noop registered [ 1.300131] io scheduler anticipatory registered [ 1.302726] io scheduler deadline registered [ 1.305128] io scheduler cfq registered (default) [ 1.307972] xen-platform-pci 0000:00:03.0: PCI INT A -> GSI 28 (level, low) -> IRQ 28 [ 1.312401] Grant table initialized [ 1.319494] Linux agpgart interface v0.103 [ 1.321859] Serial: 8250/16550 driver, 4 ports, IRQ sharing enabled [ 1.326198] serial8250: ttyS0 at I/O 0x3f8 (irq = 4) is a 16550A [ 1.330936] 00:0a: ttyS0 at I/O 0x3f8 (irq = 4) is a 16550A [ 1.334096] input: Macintosh mouse button emulation as /devices/virtual/input/input0 [ 1.338347] PNP: PS/2 Controller [PNP0303:PS2K,PNP0f13:PS2M] at 0x60,0x64 irq 1,12 [ 1.344552] serio: i8042 KBD port at 0x60,0x64 irq 1 [ 1.347365] serio: i8042 AUX port at 0x60,0x64 irq 12 [ 1.350365] mice: PS/2 mouse device common for all mice [ 1.353406] rtc_cmos 00:05: rtc core: registered rtc_cmos as rtc0 [ 1.357168] rtc0: alarms up to one day, 114 bytes nvram [ 1.360177] cpuidle: using governor ladder [ 1.362530] cpuidle: using governor menu [ 1.364794] No iBFT detected. [ 1.366672] input: AT Translated Set 2 keyboard as /devices/platform/i8042/serio0/input/input1 [ 1.366859] TCP cubic registered [ 1.366950] NET: Registered protocol family 10 [ 1.367634] Mobile IPv6 [ 1.367636] NET: Registered protocol family 17 [ 1.367737] registered taskstats version 1 [ 6.464177] XENBUS: Waiting for devices to initialise: 295s...290s...285s...280s...275s...270s...265s...260s...255s...250s...245s...240s...235s...230s...225s...220s...215s...210s...205s...200s...195s...190s...185s...180s...175s...170s...165s...160s...155s...150s...145s...140s...135s...130s...125s...120s...115s...110s...105s...100s...95s...90s...85s...80s...75s...70s...65s...60s...55s...50s...45s...40s...35s...30s...25s...20s...15s...10s...5s...0s... [ 301.373683] XENBUS: Device with no driver: device/vfb/0 [ 301.382279] XENBUS: Device with no driver: device/vbd/51712 [ 301.391104] XENBUS: Device with no driver: device/vif/0 [ 301.397662] XENBUS: Timeout connecting to device: device/pci/0 (local state 3, remote state 7) [ 301.402483] XENBUS: Device with no driver: device/console/0 [ 301.405733] rtc_cmos 00:05: setting system clock to 2011-09-06 09:41:42 UTC (1315302102) [ 301.410303] Initalizing network drop monitor service [ 301.413046] Freeing unused kernel memory: 604k freed [ 301.415886] Write protecting the kernel read-only data: 4332k Loading, please wait... [ 301.447626] <30>udev[62]: starting version 167 Begin: Loading essential drivers ... [ 301.507205] SCSI subsystem initialized [ 301.544457] usbcore: registered new interface driver usbfs [ 301.547839] usbcore: registered new interface driver hub [ 301.551451] usbcore: registered new device driver usb [ 301.560217] Initialising Xen virtual ethernet driver. [ 301.578318] scsi0 : ata_piix [ 301.579462] ohci_hcd: USB 1.1 'Open' Host Controller (OHCI) Driver [ 301.583128] blkfront: xvda: barriers enabled [ 301.584123] xvda: [ 301.589200] scsi1 : ata_piix [ 301.591177] ata1: PATA max MWDMA2 cmd 0x1f0 ctl 0x3f6 bmdma 0xc300 irq 14 [ 301.595526] FDC 0 is a S82078B [ 301.595551] xvda1 xvda2 < [ 301.600225] ata2: PATA max MWDMA2 cmd 0x170 ctl 0x376 bmdma 0xc308 irq 15 [ 301.604212] xvda5 > [ 301.605733] ohci_hcd 0000:00:05.0: PCI INT A -> GSI 36 (level, low) -> IRQ 36 [ 301.612365] ohci_hcd 0000:00:05.0: OHCI Host Controller [ 301.615352] ohci_hcd 0000:00:05.0: new USB bus registered, assigned bus number 1 [ 301.619610] ohci_hcd 0000:00:05.0: irq 36, io mem 0xf3049000 [ 301.652482] ehci_hcd: USB 2.0 'Enhanced' Host Controller (EHCI) Driver [ 301.659922] Warning! ehci_hcd should always be loaded before uhci_hcd and ohci_hcd, not after [ 301.680369] usb usb1: New USB device found, idVendor=1d6b, idProduct=0001 [ 301.683389] Event-channel device installed. [ 301.686526] usb usb1: New USB device strings: Mfr=3, Product=2, SerialNumber=1 [ 301.690483] usb usb1: Product: OHCI Host Controller [ 301.693173] usb usb1: Manufacturer: Linux 2.6.32-5-xen-amd64 ohci_hcd [ 301.696746] usb usb1: SerialNumber: 0000:00:05.0 [ 301.699420] usb usb1: configuration #1 chosen from 1 choice [ 301.702567] hub 1-0:1.0: USB hub found [ 301.704656] hub 1-0:1.0: 5 ports detected [ 301.707321] ehci_hcd 0000:00:06.0: PCI INT B -> GSI 41 (level, low) -> IRQ 41 [ 301.711516] ehci_hcd 0000:00:06.0: EHCI Host Controller [ 301.714553] ehci_hcd 0000:00:06.0: new USB bus registered, assigned bus number 2 [ 301.719289] ehci_hcd 0000:00:06.0: irq 41, io mem 0xf304a000 [ 301.732129] ehci_hcd 0000:00:06.0: USB 2.0 started, EHCI 1.00 [ 301.735482] usb usb2: New USB device found, idVendor=1d6b, idProduct=0002 [ 301.740207] usb usb2: New USB device strings: Mfr=3, Product=2, SerialNumber=1 [ 301.745398] usb usb2: Product: EHCI Host Controller [ 301.748962] usb usb2: Manufacturer: Linux 2.6.32-5-xen-amd64 ehci_hcd [ 301.753479] usb usb2: SerialNumber: 0000:00:06.0 [ 301.757024] usb usb2: configuration #1 chosen from 1 choice [ 301.761141] hub 2-0:1.0: USB hub found [ 301.767067] hub 2-0:1.0: 5 ports detected [ 301.781162] xenfs: not registering filesystem on non-xen platform done. Begin: Running /scripts/init-premount ... done. Begin: Mounting root file system ... Begin: Running /scripts/local-top ... done. Begin: Running /scripts/local-premount ... done. [ 302.000472] EXT4-fs (xvda1): mounted filesystem with ordered data mode Begin: Running /scripts/local-bottom ... done. done. Begin: Running /scripts/init-bottom ... done. [ 302.292212] usb 1-2: new low speed USB device using ohci_hcd and address 2 [ 302.470396] usb 1-2: New USB device found, idVendor=05d5, idProduct=6782 [ 302.481277] usb 1-2: New USB device strings: Mfr=0, Product=1, SerialNumber=0 [ 302.492595] usb 1-2: Product: ABBAHOME [ 302.497395] usb 1-2: configuration #1 chosen from 1 choice [ 308.839730] piix4_smbus 0000:00:01.3: SMBus base address uninitialized - upgrade BIOS or use force_addr=0xaddr fsck from util-linux-ng 2.17.2 /dev/xvda1: sauber, 238123/589824 Dateien, 1251617/2359040 Blöcke * Starting configure network device security [ OK ] * Starting configure network device security [ OK ] * Starting NFSv4 id <-> name mapper [ OK ] * Starting Mount network filesystems [ OK ] * Starting Upstart job to start portmap on boot only [ OK ] * Starting System V initialisation compatibility [ OK ] * Stopping Upstart job to start portmap on boot only [ OK ] * Stopping Mount network filesystems [ OK ] * Stopping load modules from /etc/modules [ OK ] * Starting configure network device [ OK ] * Starting Bridge socket events into upstart [ OK ] * Starting mDNS/DNS-SD daemon [ OK ] * Starting configure network device [ OK ] * Starting RPC port mapper [ OK ] * Stopping rpcsec_gss daemon [ OK ] * Starting Start this job to wait until portmap is started or fails to s[ OK ] * Stopping Start this job to wait until portmap is started or fails to s[ OK ] * Stopping mount the rpc_pipefs filesystem for NFSv4 [fail] * Starting NSM status monitor [ OK ] Starting AirVideo * Stopping System V initialisation compatibility [ OK ] * Starting System V runlevel compatibility [ OK ] * Starting restore sound card(s') mixer state(s) [ OK ] * Starting save kernel messages [ OK ] * Starting automatic crash report generation [fail] * Starting anac(h)ronistic cron [ OK ] * Starting regular background program processing daemon [ OK ] * Starting deferred execution scheduler [ OK ] * Starting ACPI daemon [ OK ] * Stopping anac(h)ronistic cron [ OK ] * Exporting directories for NFS kernel daemon... [ OK ] * Starting CPU interrupts balancing daemon [ OK ] * Starting Uncomplicated firewall [ OK ] * Starting NFS kernel daemon [ OK ] speech-dispatcher disabled; edit /etc/default/speech-dispatcher * Starting bluetooth [ OK ] * PulseAudio configured for per-user sessions saned disabled; edit /etc/default/saned * Starting restore sound card(s') mixer state(s) [fail] * Stopping save kernel messages [ OK ] * Enabling additional executable binary formats binfmt-support [ OK ] * Starting anac(h)ronistic cron [ OK ] * Stopping anac(h)ronistic cron [ OK ] * Starting network connection manager [ OK ] * Stopping cold plug devices [ OK ] * Stopping log initial device creation [ OK ] * Starting load fallback graphics devices [ OK ] * Starting load fallback graphics devices [fail] * Starting configure network device security [ OK ] * Starting save udev log and update rules [ OK ] * Starting configure virtual network devices [ OK ] * Stopping save udev log and update rules [ OK ] * Stopping configure virtual network devices [ OK ] * Starting GNOME Display Manager [ OK ] * Starting Automounter [ OK ] fsck from util-linux-ng 2.17.2 /dev/xvda1: sauber, 238123/589824 Dateien, 1251617/2359040 Blöcke * Starting configure network device security [ OK ] * Starting configure network device security [ OK ] * Starting NFSv4 id <-> name mapper [ OK ] * Starting Mount network filesystems [ OK ] * Starting Upstart job to start portmap on boot only [ OK ] * Starting System V initialisation compatibility [ OK ] * Stopping Upstart job to start portmap on boot only [ OK ] * Stopping Mount network filesystems [ OK ] * Stopping load modules from /etc/modules [ OK ] * Starting configure network device [ OK ] * Starting Bridge socket events into upstart [ OK ] * Starting mDNS/DNS-SD daemon [ OK ] * Starting configure network device [ OK ] * Starting RPC port mapper [ OK ] * Stopping rpcsec_gss daemon [ OK ] * Starting Start this job to wait until portmap is started or fails to s[ OK ] * Stopping Start this job to wait until portmap is started or fails to s[ OK ] * Stopping mount the rpc_pipefs filesystem for NFSv4 [fail] * Starting NSM status monitor [ OK ] Starting AirVideo * Stopping System V initialisation compatibility [ OK ] * Starting System V runlevel compatibility [ OK ] * Starting restore sound card(s') mixer state(s) [ OK ] * Starting save kernel messages [ OK ] * Starting automatic crash report generation [fail] * Starting anac(h)ronistic cron [ OK ] * Starting regular background program processing daemon [ OK ] * Starting deferred execution scheduler [ OK ] * Starting ACPI daemon [ OK ] * Stopping anac(h)ronistic cron [ OK ] * Exporting directories for NFS kernel daemon... [ OK ] * Starting CPU interrupts balancing daemon [ OK ] * Starting Uncomplicated firewall [ OK ] * Starting NFS kernel daemon [ OK ] speech-dispatcher disabled; edit /etc/default/speech-dispatcher * Starting bluetooth [ OK ] * PulseAudio configured for per-user sessions saned disabled; edit /etc/default/saned * Starting restore sound card(s') mixer state(s) [fail] * Stopping save kernel messages [ OK ] * Enabling additional executable binary formats binfmt-support [ OK ] * Starting anac(h)ronistic cron [ OK ] * Stopping anac(h)ronistic cron [ OK ] * Starting network connection manager [ OK ] * Stopping cold plug devices [ OK ] * Stopping log initial device creation [ OK ] * Starting load fallback graphics devices [ OK ] * Starting load fallback graphics devices [fail] * Starting configure network device security [ OK ] * Starting save udev log and update rules [ OK ] * Starting configure virtual network devices [ OK ] * Stopping save udev log and update rules [ OK ] * Stopping configure virtual network devices [ OK ] * Starting GNOME Display Manager [ OK ] * Starting Automounter [ OK ] --------------050404030308050904030304 Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel --------------050404030308050904030304-- From xen-devel-bounces@lists.xensource.com Tue Sep 06 17:56:00 2011 Return-path: Envelope-to: www-data@lists.xensource.com Delivery-date: Tue, 06 Sep 2011 17:56:00 -0700 Received: from localhost ([127.0.0.1] helo=lists.colo.xensource.com) by lists.xensource.com with esmtp (Exim 4.43) id 1R16Qq-0000Hh-SC; Tue, 06 Sep 2011 17:56:00 -0700 Received: from mail27.messagelabs.com ([193.109.254.147]) by lists.xensource.com with smtp (Exim 4.43) id 1R0xN4-0006eM-A4 for xen-devel@lists.xensource.com; Tue, 06 Sep 2011 08:15:31 -0700 X-Env-Sender: dzickus@redhat.com X-Msg-Ref: server-12.tower-27.messagelabs.com!1315322113!41306178!1 X-Originating-IP: [209.132.183.28] X-StarScan-Version: 6.3.6; banners=-,-,- X-VirusChecked: Checked Received: (qmail 21071 invoked from network); 6 Sep 2011 15:15:13 -0000 Received: from mx1.redhat.com (HELO mx1.redhat.com) (209.132.183.28) by server-12.tower-27.messagelabs.com with SMTP; 6 Sep 2011 15:15:13 -0000 Received: from int-mx01.intmail.prod.int.phx2.redhat.com (int-mx01.intmail.prod.int.phx2.redhat.com [10.5.11.11]) by mx1.redhat.com (8.14.4/8.14.4) with ESMTP id p86FEEQp024076 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Tue, 6 Sep 2011 11:14:14 -0400 Received: from ihatethathostname.lab.bos.redhat.com (ihatethathostname.lab.bos.redhat.com [10.16.43.238]) by int-mx01.intmail.prod.int.phx2.redhat.com (8.13.8/8.13.8) with ESMTP id p86FEDrI001873 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 6 Sep 2011 11:14:14 -0400 Received: from ihatethathostname.lab.bos.redhat.com (ihatethathostname.lab.bos.redhat.com [127.0.0.1]) by ihatethathostname.lab.bos.redhat.com (8.14.5/8.14.4) with ESMTP id p86FEDKF012666; Tue, 6 Sep 2011 11:14:13 -0400 Received: (from dzickus@localhost) by ihatethathostname.lab.bos.redhat.com (8.14.5/8.14.5/Submit) id p86FE9Yj012665; Tue, 6 Sep 2011 11:14:09 -0400 X-Authentication-Warning: ihatethathostname.lab.bos.redhat.com: dzickus set sender to dzickus@redhat.com using -f Date: Tue, 6 Sep 2011 11:14:09 -0400 From: Don Zickus To: Jeremy Fitzhardinge Message-ID: <20110906151408.GA7459@redhat.com> References: <38bb37e15f6e5056d5238adac945bc1837a996ec.1314922370.git.jeremy.fitzhardinge@citrix.com> <1314974826.1861.1.camel@twins> <4E612EA1.20007@goop.org> <1314996468.8255.0.camel@twins> <4E614FBD.2030509@goop.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <4E614FBD.2030509@goop.org> User-Agent: Mutt/1.5.21 (2010-09-15) X-Scanned-By: MIMEDefang 2.67 on 10.5.11.11 X-Mailman-Approved-At: Tue, 06 Sep 2011 17:53:10 -0700 Cc: Marcelo Tosatti , Nick Piggin , KVM , Stefano Stabellini , Peter Zijlstra , the arch/x86 maintainers , Linux Kernel Mailing List , Andi Kleen , Avi Kivity , Jeremy Fitzhardinge , "H. Peter Anvin" , Ingo Molnar , Linus Torvalds , Xen Devel Subject: [Xen-devel] Re: [PATCH 08/13] xen/pvticketlock: disable interrupts while blocking X-BeenThere: xen-devel@lists.xensource.com X-Mailman-Version: 2.1.5 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xensource.com Errors-To: xen-devel-bounces@lists.xensource.com On Fri, Sep 02, 2011 at 02:50:53PM -0700, Jeremy Fitzhardinge wrote: > On 09/02/2011 01:47 PM, Peter Zijlstra wrote: > > On Fri, 2011-09-02 at 12:29 -0700, Jeremy Fitzhardinge wrote: > >>> I know that its generally considered bad form, but there's at least one > >>> spinlock that's only taken from NMI context and thus hasn't got any > >>> deadlock potential. > >> Which one? > > arch/x86/kernel/traps.c:nmi_reason_lock > > > > It serializes NMI access to the NMI reason port across CPUs. > > Ah, OK. Well, that will never happen in a PV Xen guest. But PV > ticketlocks are equally applicable to an HVM Xen domain (and KVM guest), > so I guess there's at least some chance there could be a virtual > emulated NMI. Maybe? Does qemu do that kind of thing? > > But, erm, does that even make sense? I'm assuming the NMI reason port > tells the CPU why it got an NMI. If multiple CPUs can get NMIs and > there's only a single reason port, then doesn't that mean that either 1) > they all got the NMI for the same reason, or 2) having a single port is > inherently racy? How does the locking actually work there? The reason port is for an external/system NMI. All the IPI-NMI don't need to access this register to process their handlers, ie perf. I think in general the IOAPIC is configured to deliver the external NMI to one cpu, usually the bsp cpu. However, there has been a slow movement to free the bsp cpu from exceptions like this to allow one to eventually hot-swap the bsp cpu. The spin locks in that code were an attempt to be more abstract about who really gets the external NMI. Of course SGI's box is setup to deliver an external NMI to all cpus to dump the stack when the system isn't behaving. This is a very low usage NMI (in fact almost all cases lead to loud console messages). Hope that clears up some of the confusion. Cheers, Don _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel From xen-devel-bounces@lists.xensource.com Tue Sep 06 17:56:55 2011 Return-path: Envelope-to: www-data@lists.xensource.com Delivery-date: Tue, 06 Sep 2011 17:56:55 -0700 Received: from localhost ([127.0.0.1] helo=lists.colo.xensource.com) by lists.xensource.com with esmtp (Exim 4.43) id 1R16Rj-0000fA-H7; Tue, 06 Sep 2011 17:56:55 -0700 Received: from mail216.messagelabs.com ([85.158.143.99]) by lists.xensource.com with esmtp (Exim 4.43) id 1R0zqv-0004XP-Uq for xen-devel@lists.xensource.com; Tue, 06 Sep 2011 10:54:30 -0700 X-Env-Sender: marmarek@invisiblethingslab.com X-Msg-Ref: server-9.tower-216.messagelabs.com!1315331666!17298491!1 X-Originating-IP: [66.111.4.28] X-StarScan-Version: 6.3.6; banners=-,-,- X-VirusChecked: Checked Received: (qmail 19527 invoked from network); 6 Sep 2011 17:54:26 -0000 Received: from out4.smtp.messagingengine.com (HELO out4.smtp.messagingengine.com) (66.111.4.28) by server-9.tower-216.messagelabs.com with DHE-RSA-AES256-SHA encrypted SMTP; 6 Sep 2011 17:54:26 -0000 Received: from compute5.internal (compute5.nyi.mail.srv.osa [10.202.2.45]) by gateway1.nyi.mail.srv.osa (Postfix) with ESMTP id E741324675 for ; Tue, 6 Sep 2011 13:54:25 -0400 (EDT) Received: from frontend2.nyi.mail.srv.osa ([10.202.2.161]) by compute5.internal (MEProxy); Tue, 06 Sep 2011 13:54:25 -0400 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d= messagingengine.com; h=message-id:date:from:mime-version:to:cc :subject:content-type; s=smtpout; bh=6W2nn+SFlnw91Lywxflkg2wKEK4 =; b=UZ6iBLcofeFOBbr+hOu16yFNCpdaB3SERPnpncV6Xd4yZCGcMr6AjHHFaLG zlHt0Onk+XnAzxewJ5tR4xsq5bgrdPd7P/gaVAiK2+QVjMW1J3nn4WcNtHGbgTcH cOhsCzmsajDnbITumK7iizrR2Ino0agU6XPeECOvSv5hB45U= X-Sasl-enc: nN5lxjQR7QWfFL0N+63Wf7ptnlRFkHlHLqDYTBjZHXQO 1315331665 Received: from [10.137.1.11] (87-206-116-192.dynamic.chello.pl [87.206.116.192]) by mail.messagingengine.com (Postfix) with ESMTPSA id 4FD5B8E027B; Tue, 6 Sep 2011 13:54:24 -0400 (EDT) Message-ID: <4E665E53.3@invisiblethingslab.com> Date: Tue, 06 Sep 2011 19:54:27 +0200 From: Marek Marczykowski User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.2.18) Gecko/20110621 Fedora/3.1.11-1.fc14 Lightning/1.0b3pre Thunderbird/3.1.11 MIME-Version: 1.0 To: "xen-devel@lists.xensource.com" X-Enigmail-Version: 1.1.2 X-Mailman-Approved-At: Tue, 06 Sep 2011 17:53:10 -0700 Cc: Rafal Wojtczuk , Joanna Rutkowska Subject: [Xen-devel] Memory fragmentation and PCI passthrough X-BeenThere: xen-devel@lists.xensource.com X-Mailman-Version: 2.1.5 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1655502185==" Sender: xen-devel-bounces@lists.xensource.com Errors-To: xen-devel-bounces@lists.xensource.com This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --===============1655502185== Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="------------enig5A5420FFFDF5DD86CC10B256" This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enig5A5420FFFDF5DD86CC10B256 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Hello, I've hit known problem with dynamic memory management - memory fragmentation... This dynamic memory management basically does xl mem-set to balance memory. After some time of running system, xen memory is so fragmented that it is impossible to start new VM with PCI device. Sometimes it crashes during boot (no 64MB contiguous memory for SWIOTLB), or later - eg. iwlagn cannot allocate memory for loading firmware (few allocs, each bellow 100k). DomU kernel cmdline: console=3Dhvc0 iommu=3Dsoft earlyprintk=3Dxen There is two cases (I think): 1. With IOMMU 2. Without IOMMU I've tried only the second one. Is there any known solution for this problem? Some ideas: 1. With IOMMU pass iommu=3Dpv to Xen. AFAIU domU will not need iommu=3Dso= ft parameter then, right? Will it work then with fragmented memory? 2. Force somehow on xen/libxl to allocate memory (for domU) in chunks of, say 4MB, to not fragment it so badly. Is it doable? In tmem documentation is also described some workaround for this: reserve some memory region for allocations with 0 Envelope-to: www-data@lists.xensource.com Delivery-date: Tue, 06 Sep 2011 17:59:02 -0700 Received: from localhost ([127.0.0.1] helo=lists.colo.xensource.com) by lists.xensource.com with esmtp (Exim 4.43) id 1R16Ti-00014R-Kx; Tue, 06 Sep 2011 17:58:58 -0700 Received: from mail21.messagelabs.com ([85.158.143.35]) by lists.xensource.com with smtp (Exim 4.43) id 1R10OR-0005RG-UD for xen-devel@lists.xensource.com; Tue, 06 Sep 2011 11:29:08 -0700 X-Env-Sender: dzickus@redhat.com X-Msg-Ref: server-15.tower-21.messagelabs.com!1315333745!49564007!1 X-Originating-IP: [209.132.183.28] X-StarScan-Version: 6.3.6; banners=-,-,- X-VirusChecked: Checked Received: (qmail 30514 invoked from network); 6 Sep 2011 18:29:05 -0000 Received: from mx1.redhat.com (HELO mx1.redhat.com) (209.132.183.28) by server-15.tower-21.messagelabs.com with SMTP; 6 Sep 2011 18:29:05 -0000 Received: from int-mx01.intmail.prod.int.phx2.redhat.com (int-mx01.intmail.prod.int.phx2.redhat.com [10.5.11.11]) by mx1.redhat.com (8.14.4/8.14.4) with ESMTP id p86IS1JV002240 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Tue, 6 Sep 2011 14:28:01 -0400 Received: from redhat.com (dhcp-100-19-141.bos.redhat.com [10.16.19.141]) by int-mx01.intmail.prod.int.phx2.redhat.com (8.13.8/8.13.8) with SMTP id p86IRwt9012809; Tue, 6 Sep 2011 14:27:59 -0400 Date: Tue, 6 Sep 2011 14:27:58 -0400 From: Don Zickus To: Jeremy Fitzhardinge Message-ID: <20110906182758.GR5795@redhat.com> References: <38bb37e15f6e5056d5238adac945bc1837a996ec.1314922370.git.jeremy.fitzhardinge@citrix.com> <1314974826.1861.1.camel@twins> <4E612EA1.20007@goop.org> <1314996468.8255.0.camel@twins> <4E614FBD.2030509@goop.org> <20110906151408.GA7459@redhat.com> <4E66615E.8070806@goop.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <4E66615E.8070806@goop.org> User-Agent: Mutt/1.5.21 (2010-09-15) X-Scanned-By: MIMEDefang 2.67 on 10.5.11.11 X-Mailman-Approved-At: Tue, 06 Sep 2011 17:53:10 -0700 Cc: Marcelo Tosatti , Nick Piggin , KVM , Stefano Stabellini , Peter Zijlstra , the arch/x86 maintainers , Linux Kernel Mailing List , Andi Kleen , Avi Kivity , Jeremy Fitzhardinge , "H. Peter Anvin" , Ingo Molnar , Linus Torvalds , Xen Devel Subject: [Xen-devel] Re: [PATCH 08/13] xen/pvticketlock: disable interrupts while blocking X-BeenThere: xen-devel@lists.xensource.com X-Mailman-Version: 2.1.5 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xensource.com Errors-To: xen-devel-bounces@lists.xensource.com On Tue, Sep 06, 2011 at 11:07:26AM -0700, Jeremy Fitzhardinge wrote: > >> But, erm, does that even make sense? I'm assuming the NMI reason port > >> tells the CPU why it got an NMI. If multiple CPUs can get NMIs and > >> there's only a single reason port, then doesn't that mean that either 1) > >> they all got the NMI for the same reason, or 2) having a single port is > >> inherently racy? How does the locking actually work there? > > The reason port is for an external/system NMI. All the IPI-NMI don't need > > to access this register to process their handlers, ie perf. I think in > > general the IOAPIC is configured to deliver the external NMI to one cpu, > > usually the bsp cpu. However, there has been a slow movement to free the > > bsp cpu from exceptions like this to allow one to eventually hot-swap the > > bsp cpu. The spin locks in that code were an attempt to be more abstract > > about who really gets the external NMI. Of course SGI's box is setup to > > deliver an external NMI to all cpus to dump the stack when the system > > isn't behaving. > > > > This is a very low usage NMI (in fact almost all cases lead to loud > > console messages). > > > > Hope that clears up some of the confusion. > > Hm, not really. > > What does it mean if two CPUs go down that path? Should one do some NMI > processing while the other waits around for it to finish, and then do > some NMI processing on its own? Well the time the second one gets to the external NMI it should have been cleared by the first cpu, which would of course lead to the second cpu causing a 'Dazed and confused' message. But on most x86 machines only one cpu should be routed the external NMI. Though there is an SGI box that is designed to send an external NMI to all of its cpus. > > It sounds like that could only happen if you reroute NMI from one CPU to > another while the first CPU is actually in the middle of processing an > NMI - in which case, shouldn't the code doing the re-routing be taking > the spinlock? Perhaps, but like I said it is a slow transition because most people don't have the hardware to test this (nor does it work due to other limitations). > > Or perhaps a spinlock isn't the right primitive to use at all? Couldn't > the second CPU just set a flag/counter (using something like an atomic > add/cmpxchg/etc) to make the first CPU process the second NMI? Might be a smarter approach. Like I said it is hard to test without functioning hardware. :-( > > But on the other hand, I don't really care if you can say that this path > will never be called in a virtual machine. Does virtual machines support hot remove of cpus? Probably not considering bare-metal barely supports it. Cheers, Don _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel From xen-devel-bounces@lists.xensource.com Tue Sep 06 18:48:58 2011 Return-path: Envelope-to: www-data@lists.xensource.com Delivery-date: Tue, 06 Sep 2011 18:48:58 -0700 Received: from localhost ([127.0.0.1] helo=lists.colo.xensource.com) by lists.xensource.com with esmtp (Exim 4.43) id 1R17G6-0002Hw-JS; Tue, 06 Sep 2011 18:48:58 -0700 Received: from mail21.messagelabs.com ([85.158.143.35]) by lists.xensource.com with esmtp (Exim 4.43) id 1R17FH-00025w-6Z for xen-devel@lists.xensource.com; Tue, 06 Sep 2011 18:48:07 -0700 X-Env-Sender: konrad@dumpdata.com X-Msg-Ref: server-10.tower-21.messagelabs.com!1315360068!53119024!1 X-Originating-IP: [148.87.113.117] X-StarScan-Version: 6.3.6; banners=-,-,- X-VirusChecked: Checked Received: (qmail 28817 invoked from network); 7 Sep 2011 01:47:50 -0000 Received: from rcsinet15.oracle.com (HELO rcsinet15.oracle.com) (148.87.113.117) by server-10.tower-21.messagelabs.com with DHE-RSA-AES256-SHA encrypted SMTP; 7 Sep 2011 01:47:50 -0000 Received: from rtcsinet21.oracle.com (rtcsinet21.oracle.com [66.248.204.29]) by rcsinet15.oracle.com (Switch-3.4.4/Switch-3.4.4) with ESMTP id p871lxvm032403 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Wed, 7 Sep 2011 01:48:01 GMT Received: from acsmt357.oracle.com (acsmt357.oracle.com [141.146.40.157]) by rtcsinet21.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id p871lwI1004869 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 7 Sep 2011 01:47:59 GMT Received: from abhmt106.oracle.com (abhmt106.oracle.com [141.146.116.58]) by acsmt357.oracle.com (8.12.11.20060308/8.12.11) with ESMTP id p871lqdv006164; Tue, 6 Sep 2011 20:47:52 -0500 Received: from phenom (/209.6.55.207) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Tue, 06 Sep 2011 18:47:52 -0700 Received: by phenom (Postfix, from userid 1000) id AB883FD1; Tue, 6 Sep 2011 21:47:41 -0400 (EDT) Date: Tue, 6 Sep 2011 21:47:41 -0400 From: Konrad Rzeszutek Wilk To: Marek Marczykowski Subject: Re: [Xen-devel] blkfront problem in pvops kernel when barriers enabled Message-ID: <20110907014741.GD30639@dumpdata.com> References: <4E6357C6.6050101@mimuw.edu.pl> <20110906163213.GC5264@dumpdata.com> <4E665572.7080009@mimuw.edu.pl> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <4E665572.7080009@mimuw.edu.pl> User-Agent: Mutt/1.5.21 (2010-09-15) X-Source-IP: rtcsinet21.oracle.com [66.248.204.29] X-CT-RefId: str=0001.0A090209.4E66CD52.0007,ss=1,re=0.000,fgs=0 Cc: "xen-devel@lists.xensource.com" X-BeenThere: xen-devel@lists.xensource.com X-Mailman-Version: 2.1.5 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xensource.com Errors-To: xen-devel-bounces@lists.xensource.com On Tue, Sep 06, 2011 at 07:16:34PM +0200, Marek Marczykowski wrote: > On 06.09.2011 18:32, Konrad Rzeszutek Wilk wrote: > > On Sun, Sep 04, 2011 at 12:49:42PM +0200, Marek Marczykowski wrote: > >> Hello, > >> > >> Pvops block frontend (tested vanilla 3.0.3, 3.1rc2, Konrad's testing > >> branch) produces a lot of I/O errors when barriers are enabled but > >> cannot be used. > >> > >> On xenlinux I've got message: > >> [ 15.036921] blkfront: xvdb: empty write barrier op failed > >> [ 15.036936] blkfront: xvdb: barriers disabled > >> > >> and after that, everything works fine. On pvops - I/O errors. > >> As backend I've used 2.6.38.3 xenlinux (based on SUSE package) and > >> 3.1rc2 with same result. > > > > Hm, and the 'feature-barrier' was enabled on in those backends? > > That is really bizzare considering that those backends don't actually > > support WRITE_BARRIER anymore. > > At least in 2.6.38.3 xenlinux (SUSE). Now I'm not sure if 3.1rc2 also > needed this modification (can't find it now). > > >> When I disable barriers (patching blkbackend to set feature-barrier=0) > >> everything works fine with all above versions. > > > > Ok, and the patch you sent "[PATCH] Initialize vars in blkfront_connect" > > as well? > > Yes. > I've noticed now that this patch was needed only on your testing branch > (not vanilla kernel). Oooo. Let me check what went wrong. Perhaps the fix is already applied in my local tree. > > >> My setup is xen-4.1.1 (if it matters), backends: phy from device-mapper > >> device and phy from loop device; frontends covered by device-mapper > >> snapshot, which is set up in domU initramfs. > >> > >> It looks like some race condition, because when I setup device-mapper in > >> domU and mount it manually (which cause some delays between steps), it > >> works fine... > >> > >> Have you idea why it happens? What additional data can I provide debug it? > >> > >> In addition it should be possible to disable barrier without patching > >> module... Perhaps some pciback module parameter? Or leave feature-* > > > > Not sure why you would touch pciback.. > > I mean blkback of course. > > > But the barrier should _not_ > > be enabled in those backends. The 'feature-flush-cache' should be. > > (on 3.1rc2) Looking to xenstore now there is 'feature-flush-cache=1' and > no 'feature-barrier'. So it is ok. I can only think of 2.6.38-3 XenOLinux doing it - and it is a bug to do it. It really ought to _not_ advertise 'feature-barrier' and instead advertise 'feature-flush-cache'. _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel From xen-devel-bounces@lists.xensource.com Tue Sep 06 18:57:03 2011 Return-path: Envelope-to: www-data@lists.xensource.com Delivery-date: Tue, 06 Sep 2011 18:57:03 -0700 Received: from localhost ([127.0.0.1] helo=lists.colo.xensource.com) by lists.xensource.com with esmtp (Exim 4.43) id 1R17Nv-0002mj-LQ; Tue, 06 Sep 2011 18:57:03 -0700 Received: from mail27.messagelabs.com ([193.109.254.147]) by lists.xensource.com with smtp (Exim 4.43) id 1R17NN-0002Zr-Ru for xen-devel@lists.xensource.com; Tue, 06 Sep 2011 18:56:30 -0700 X-Env-Sender: gbtux@126.com X-Msg-Ref: server-15.tower-27.messagelabs.com!1315360577!47677545!1 X-Originating-IP: [220.181.15.44] X-StarScan-Version: 6.3.6; banners=-,-,- X-VirusChecked: Checked Received: (qmail 19839 invoked from network); 7 Sep 2011 01:56:18 -0000 Received: from m15-44.126.com (HELO m15-44.126.com) (220.181.15.44) by server-15.tower-27.messagelabs.com with SMTP; 7 Sep 2011 01:56:18 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=126.com; s=s110527; h=Received:Date:From:Cc:Message-ID:Subject: MIME-Version:Content-Type; bh=eps6RCM4eLGazZ2l/U0/kjA4MmglyIcxKH jOFRfaGEs=; b=NlvasJIm90pE/2iAbt/JQtXC2LCS8GlV9EAC7O1OiC46En0H8H pxgr2CLgytmpR1wAUlzVhdU79kqZlhbuT6SLXgyH4OXfFT106LAz307jl0JjPsAM YuXdAVh8b0+j50kNdbNz39BdHWzadRhageGnbPWdkozr5kJN1BR/ncQ9g= Received: from gbtux ( [124.16.139.196] ) by ajax-webmail-wmsvr44 (Coremail) ; Wed, 7 Sep 2011 09:56:21 +0800 (CST) Date: Wed, 7 Sep 2011 09:56:21 +0800 (CST) From: zhikai Cc: xen-devel@lists.xensource.com Message-ID: <617bb665.38c8.1324199a5c4.Coremail.gbtux@126.com> MIME-Version: 1.0 X-Originating-IP: [124.16.139.196] X-Priority: 3 X-Mailer: Coremail Webmail Server Version SP_ntes V3.5 build 110829(14649.4006.3992) Copyright (c) 2002-2011 www.mailtech.cn 126com X-CM-CTRLDATA: Wd17F2Zvb3Rlcl9odG09MzUyOjgx X-CM-TRANSID: LMqowECZSEJIz2ZOkxAHAA--.3036W X-CM-SenderInfo: pjew35a6rslhhfrp/1tbiHRyznEihSj2TiAACsp X-Coremail-Antispam: 1U5529EdanIXcx71UUUUU7vcSsGvfC2KfnxnUU== Subject: [Xen-devel] How to start a GUI in Xen PV DomU X-BeenThere: xen-devel@lists.xensource.com X-Mailman-Version: 2.1.5 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0338348307==" Sender: xen-devel-bounces@lists.xensource.com Errors-To: xen-devel-bounces@lists.xensource.com --===============0338348307== Content-Type: multipart/alternative; boundary="----=_Part_40092_1622996804.1315360581060" ------=_Part_40092_1622996804.1315360581060 Content-Type: text/plain; charset=GBK Content-Transfer-Encoding: 7bit Hi All, Could anyone tell me how to start the desktop of a PV DomU? Does Xen support the GUI in PV? And how to run a application with GUI? Any reply is appreciated. Best Regards, Kai ------=_Part_40092_1622996804.1315360581060 Content-Type: text/html; charset=GBK Content-Transfer-Encoding: 7bit
Hi All,

Could anyone tell me how to start the desktop of a PV DomU? Does Xen support the GUI in PV?  And how to run a application with GUI?
Any reply is appreciated.

Best Regards,
Kai


------=_Part_40092_1622996804.1315360581060-- --===============0338348307== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel --===============0338348307==-- From xen-devel-bounces@lists.xensource.com Tue Sep 06 19:36:18 2011 Return-path: Envelope-to: www-data@lists.xensource.com Delivery-date: Tue, 06 Sep 2011 19:36:18 -0700 Received: from localhost ([127.0.0.1] helo=lists.colo.xensource.com) by lists.xensource.com with esmtp (Exim 4.43) id 1R17zt-0004QP-Bw; Tue, 06 Sep 2011 19:36:17 -0700 Received: from mail182.messagelabs.com ([85.158.139.83]) by lists.xensource.com with smtp (Exim 4.43) id 1R17z4-0004Da-Kz for xen-devel@lists.xensource.com; Tue, 06 Sep 2011 19:35:27 -0700 X-Env-Sender: tinnycloud@hotmail.com X-Msg-Ref: server-5.tower-182.messagelabs.com!1315362923!12334617!1 X-Originating-IP: [65.55.116.37] X-StarScan-Version: 6.3.6; banners=-,-,- X-VirusChecked: Checked Received: (qmail 25556 invoked from network); 7 Sep 2011 02:35:23 -0000 Received: from blu0-omc1-s26.blu0.hotmail.com (HELO blu0-omc1-s26.blu0.hotmail.com) (65.55.116.37) by server-5.tower-182.messagelabs.com with SMTP; 7 Sep 2011 02:35:23 -0000 Received: from BLU157-W32 ([65.55.116.9]) by blu0-omc1-s26.blu0.hotmail.com with Microsoft SMTPSVC(6.0.3790.4675); Tue, 6 Sep 2011 19:35:22 -0700 Message-ID: X-Originating-IP: [121.0.29.75] From: MaoXiaoyun To: Subject: RE: [Xen-devel] RE: ext4 BUG in dom0 Kernel 2.6.32.36 Date: Wed, 7 Sep 2011 10:35:21 +0800 Importance: Normal In-Reply-To: <4E666C86.5090707@goop.org> References: , <20110906145347.GA4133@dumpdata.com> , <4E666C86.5090707@goop.org> Content-Type: text/plain; charset="gb2312" Content-Transfer-Encoding: 8bit MIME-Version: 1.0 X-OriginalArrivalTime: 07 Sep 2011 02:35:22.0423 (UTC) FILETIME=[CAA95C70:01CC6D06] Cc: linux-ext4@vger.kernel.org, xen devel , konrad.wilk@oracle.com X-BeenThere: xen-devel@lists.xensource.com X-Mailman-Version: 2.1.5 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xensource.com Errors-To: xen-devel-bounces@lists.xensource.com ---------------------------------------- > Date: Tue, 6 Sep 2011 11:55:02 -0700 > From: jeremy@goop.org > To: tinnycloud@hotmail.com > CC: konrad.wilk@oracle.com; linux-ext4@vger.kernel.org; xen-devel@lists.xensource.com > Subject: Re: [Xen-devel] RE: ext4 BUG in dom0 Kernel 2.6.32.36 > > On 09/06/2011 08:11 AM, MaoXiaoyun wrote: > > > > > Date: Tue, 6 Sep 2011 10:53:47 -0400 > > > From: konrad.wilk@oracle.com > > > To: tinnycloud@hotmail.com > > > CC: linux-ext4@vger.kernel.org; xen-devel@lists.xensource.com; > > jeremy@goop.org > > > Subject: Re: ext4 BUG in dom0 Kernel 2.6.32.36 > > > > > > On Tue, Sep 06, 2011 at 03:24:14PM +0800, MaoXiaoyun wrote: > > > > > > > > > > > > Hi: > > > > > > > > I've met an ext4 Bug in dom0 kernel 2.6.32.36. (See kernel stack > > below) > > > > > > Did you try the 3.0 kernel? > > No, I am afried the change would be to much for our current env. > > May result in other stable issue. > > So, I want to dig out what really happen. Hopes. > > Another question is whether this is a regression compared to earlier > versions of 2.6.32? Do you know if this problem exists in a non-Xen > environment? > There are some others reports this issue in non-xen env. http://markmail.org/message/ywr4nfgiuvgdcr7y http://www.spinics.net/lists/linux-ext4/msg21066.html The difficulty is I haven't find a efficient way to reproduce it. (Currently it only show in our cluster, redeploy our cluster may cost 3days more. ) > Thanks, > J > -- > To unsubscribe from this list: send the line "unsubscribe linux-ext4" in > the body of a message to majordomo@vger.kernel.org > More majordomo info at http://vger.kernel.org/majordomo-info.html _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel From xen-devel-bounces@lists.xensource.com Tue Sep 06 20:47:32 2011 Return-path: Envelope-to: www-data@lists.xensource.com Delivery-date: Tue, 06 Sep 2011 20:47:32 -0700 Received: from localhost ([127.0.0.1] helo=lists.colo.xensource.com) by lists.xensource.com with esmtp (Exim 4.43) id 1R196q-0007FH-2A; Tue, 06 Sep 2011 20:47:32 -0700 Received: from mail216.messagelabs.com ([85.158.143.99]) by lists.xensource.com with smtp (Exim 4.43) id 1R195w-00072U-8C for xen-devel@lists.xensource.com; Tue, 06 Sep 2011 20:46:36 -0700 X-Env-Sender: Ian.Jackson@eu.citrix.com X-Msg-Ref: server-3.tower-216.messagelabs.com!1315367193!16279532!1 X-Originating-IP: [62.200.22.115] X-StarScan-Version: 6.3.6; banners=-,-,- X-VirusChecked: Checked Received: (qmail 22710 invoked from network); 7 Sep 2011 03:46:33 -0000 Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115) by server-3.tower-216.messagelabs.com with SMTP; 7 Sep 2011 03:46:33 -0000 X-IronPort-AV: E=Sophos;i="4.68,343,1312156800"; d="scan'208";a="7638365" Received: from lonpmailmx01.citrite.net ([10.30.203.162]) by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5; 07 Sep 2011 03:46:32 +0000 Received: from woking.xci-test.com (10.80.248.135) by smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id 8.3.137.0; Wed, 7 Sep 2011 04:46:32 +0100 Received: from osstest by woking.xci-test.com with local (Exim 4.69) (envelope-from ) id 1R195s-0001ZV-1i; Wed, 07 Sep 2011 04:46:32 +0100 To: xen-devel@lists.xensource.com Message-ID: From: xen.org Date: Wed, 7 Sep 2011 04:46:32 +0100 MIME-Version: 1.0 Content-Type: text/plain Cc: ian.jackson@eu.citrix.com Subject: [Xen-devel] [xen-unstable test] 8833: tolerable FAIL X-BeenThere: xen-devel@lists.xensource.com X-Mailman-Version: 2.1.5 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xensource.com Errors-To: xen-devel-bounces@lists.xensource.com flight 8833 xen-unstable real [real] http://www.chiark.greenend.org.uk/~xensrcts/logs/8833/ Failures :-/ but no regressions. Tests which are failing intermittently (not blocking): test-amd64-amd64-xl-sedf 11 guest-localmigrate fail pass in 8832 Tests which did not succeed, but are not blocking, including regressions (tests previously passed) regarded as allowable: test-amd64-amd64-xl-pcipt-intel 9 guest-start fail never pass test-amd64-i386-rhel6hvm-intel 9 guest-start.2 fail never pass test-amd64-i386-win-vcpus1 16 leak-check/check fail never pass test-amd64-i386-xl-win-vcpus1 13 guest-stop fail never pass test-amd64-i386-rhel6hvm-amd 9 guest-start.2 fail never pass test-amd64-amd64-win 16 leak-check/check fail never pass test-amd64-i386-win 16 leak-check/check fail never pass test-amd64-amd64-xl-win 13 guest-stop fail never pass test-i386-i386-xl-win 13 guest-stop fail never pass test-i386-i386-win 16 leak-check/check fail never pass version targeted for testing: xen 5fe770c8a8a3 baseline version: xen 5fe770c8a8a3 jobs: build-amd64 pass build-i386 pass build-amd64-oldkern pass build-i386-oldkern pass build-amd64-pvops pass build-i386-pvops pass test-amd64-amd64-xl pass test-amd64-i386-xl pass test-i386-i386-xl pass test-amd64-i386-rhel6hvm-amd fail test-amd64-i386-xl-credit2 pass test-amd64-amd64-xl-pcipt-intel fail test-amd64-i386-rhel6hvm-intel fail test-amd64-i386-xl-multivcpu pass test-amd64-amd64-pair pass test-amd64-i386-pair pass test-i386-i386-pair pass test-amd64-amd64-pv pass test-amd64-i386-pv pass test-i386-i386-pv pass test-amd64-amd64-xl-sedf fail test-amd64-i386-win-vcpus1 fail test-amd64-i386-xl-win-vcpus1 fail test-amd64-amd64-win fail test-amd64-i386-win fail test-i386-i386-win fail test-amd64-amd64-xl-win fail test-i386-i386-xl-win fail ------------------------------------------------------------ sg-report-flight on woking.cam.xci-test.com logs: /home/xc_osstest/logs images: /home/xc_osstest/images Logs, config files, etc. are available at http://www.chiark.greenend.org.uk/~xensrcts/logs Test harness code can be found at http://xenbits.xensource.com/gitweb?p=osstest.git;a=summary Published tested tree is already up to date. _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel From xen-devel-bounces@lists.xensource.com Tue Sep 06 21:16:51 2011 Return-path: Envelope-to: www-data@lists.xensource.com Delivery-date: Tue, 06 Sep 2011 21:16:51 -0700 Received: from localhost ([127.0.0.1] helo=lists.colo.xensource.com) by lists.xensource.com with esmtp (Exim 4.43) id 1R19ZD-00088z-Mb; Tue, 06 Sep 2011 21:16:51 -0700 Received: from mail216.messagelabs.com ([85.158.143.99]) by lists.xensource.com with smtp (Exim 4.43) id 1R19YJ-0007w9-Q6 for xen-devel@lists.xensource.com; Tue, 06 Sep 2011 21:15:56 -0700 X-Env-Sender: avi@redhat.com X-Msg-Ref: server-15.tower-216.messagelabs.com!1315368951!16902779!1 X-Originating-IP: [209.132.183.28] X-StarScan-Version: 6.3.6; banners=-,-,- X-VirusChecked: Checked Received: (qmail 21885 invoked from network); 7 Sep 2011 04:15:51 -0000 Received: from mx1.redhat.com (HELO mx1.redhat.com) (209.132.183.28) by server-15.tower-216.messagelabs.com with SMTP; 7 Sep 2011 04:15:51 -0000 Received: from int-mx10.intmail.prod.int.phx2.redhat.com (int-mx10.intmail.prod.int.phx2.redhat.com [10.5.11.23]) by mx1.redhat.com (8.14.4/8.14.4) with ESMTP id p874E6D8025569 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Wed, 7 Sep 2011 00:14:06 -0400 Received: from mermaid.qumranet.com (vpn-200-96.tlv.redhat.com [10.35.200.96]) by int-mx10.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP id p874DwF1025443; Wed, 7 Sep 2011 00:13:59 -0400 Message-ID: <4E66EF86.9070200@redhat.com> Date: Wed, 07 Sep 2011 07:13:58 +0300 From: Avi Kivity User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:6.0) Gecko/20110816 Thunderbird/6.0 MIME-Version: 1.0 To: Don Zickus References: <38bb37e15f6e5056d5238adac945bc1837a996ec.1314922370.git.jeremy.fitzhardinge@citrix.com> <1314974826.1861.1.camel@twins> <4E612EA1.20007@goop.org> <1314996468.8255.0.camel@twins> <4E614FBD.2030509@goop.org> <20110906151408.GA7459@redhat.com> <4E66615E.8070806@goop.org> <20110906182758.GR5795@redhat.com> In-Reply-To: <20110906182758.GR5795@redhat.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Scanned-By: MIMEDefang 2.68 on 10.5.11.23 Cc: Jeremy Fitzhardinge , Marcelo Tosatti , Nick Piggin , KVM , Stefano Stabellini , Peter Zijlstra , the arch/x86 maintainers , Linux Kernel Mailing List , Andi Kleen , Jeremy Fitzhardinge , "H. Peter Anvin" , Ingo Molnar , Linus Torvalds , Xen Devel Subject: [Xen-devel] Re: [PATCH 08/13] xen/pvticketlock: disable interrupts while blocking X-BeenThere: xen-devel@lists.xensource.com X-Mailman-Version: 2.1.5 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xensource.com Errors-To: xen-devel-bounces@lists.xensource.com On 09/06/2011 09:27 PM, Don Zickus wrote: > On Tue, Sep 06, 2011 at 11:07:26AM -0700, Jeremy Fitzhardinge wrote: > > >> But, erm, does that even make sense? I'm assuming the NMI reason port > > >> tells the CPU why it got an NMI. If multiple CPUs can get NMIs and > > >> there's only a single reason port, then doesn't that mean that either 1) > > >> they all got the NMI for the same reason, or 2) having a single port is > > >> inherently racy? How does the locking actually work there? > > > The reason port is for an external/system NMI. All the IPI-NMI don't need > > > to access this register to process their handlers, ie perf. I think in > > > general the IOAPIC is configured to deliver the external NMI to one cpu, > > > usually the bsp cpu. However, there has been a slow movement to free the > > > bsp cpu from exceptions like this to allow one to eventually hot-swap the > > > bsp cpu. The spin locks in that code were an attempt to be more abstract > > > about who really gets the external NMI. Of course SGI's box is setup to > > > deliver an external NMI to all cpus to dump the stack when the system > > > isn't behaving. > > > > > > This is a very low usage NMI (in fact almost all cases lead to loud > > > console messages). > > > > > > Hope that clears up some of the confusion. > > > > Hm, not really. > > > > What does it mean if two CPUs go down that path? Should one do some NMI > > processing while the other waits around for it to finish, and then do > > some NMI processing on its own? > > Well the time the second one gets to the external NMI it should have been > cleared by the first cpu, which would of course lead to the second cpu > causing a 'Dazed and confused' message. But on most x86 machines only one > cpu should be routed the external NMI. Though there is an SGI box that is > designed to send an external NMI to all of its cpus. Is there a way to tell whether an NMI was internally or externally generated? I don't think so, especially as two or more NMIs can be coalesced. So any NMI received on this first cpu has to check the NMI reason port? > > > > But on the other hand, I don't really care if you can say that this path > > will never be called in a virtual machine. > > Does virtual machines support hot remove of cpus? Probably not > considering bare-metal barely supports it. > They do. -- I have a truly marvellous patch that fixes the bug which this signature is too narrow to contain. _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel From xen-devel-bounces@lists.xensource.com Tue Sep 06 21:20:53 2011 Return-path: Envelope-to: www-data@lists.xensource.com Delivery-date: Tue, 06 Sep 2011 21:20:53 -0700 Received: from localhost ([127.0.0.1] helo=lists.colo.xensource.com) by lists.xensource.com with esmtp (Exim 4.43) id 1R19d7-00008C-Bq; Tue, 06 Sep 2011 21:20:53 -0700 Received: from mail182.messagelabs.com ([85.158.139.83]) by lists.xensource.com with smtp (Exim 4.43) id 1R19ce-0008Ni-EP for xen-devel@lists.xensource.com; Tue, 06 Sep 2011 21:20:24 -0700 X-Env-Sender: joseph.cihula@intel.com X-Msg-Ref: server-4.tower-182.messagelabs.com!1315369220!17326439!1 X-Originating-IP: [192.55.52.88] X-StarScan-Version: 6.3.6; banners=-,-,- X-VirusChecked: Checked Received: (qmail 8699 invoked from network); 7 Sep 2011 04:20:21 -0000 Received: from mga01.intel.com (HELO mga01.intel.com) (192.55.52.88) by server-4.tower-182.messagelabs.com with SMTP; 7 Sep 2011 04:20:21 -0000 Received: from fmsmga002.fm.intel.com ([10.253.24.26]) by fmsmga101.fm.intel.com with ESMTP; 06 Sep 2011 21:20:19 -0700 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="4.68,343,1312182000"; d="scan'208";a="49813255" Received: from orsmsx604.amr.corp.intel.com ([10.22.226.87]) by fmsmga002.fm.intel.com with ESMTP; 06 Sep 2011 21:20:19 -0700 Received: from orsmsx105.amr.corp.intel.com (10.22.225.132) by orsmsx604.amr.corp.intel.com (10.22.226.87) with Microsoft SMTP Server (TLS) id 8.2.255.0; Tue, 6 Sep 2011 21:20:19 -0700 Received: from orsmsx101.amr.corp.intel.com ([169.254.8.19]) by ORSMSX105.amr.corp.intel.com ([169.254.4.165]) with mapi id 14.01.0323.003; Tue, 6 Sep 2011 21:20:18 -0700 From: "Cihula, Joseph" To: Konrad Rzeszutek Wilk , "x86@kernel.org" , "tglx@linutronix.de" , "tboot-devel@lists.sourceforge.net" , "Wang, Shane" , "linux-pm@lists.linux-foundation.org" , "linux-acpi@vger.kernel.org" , "Brown, Len" , "hpa@zytor.com" , "Yu, Ke" , "liang.tang@oracle.com" , "Tian, Kevin" , "keir@xen.org" Thread-Topic: [PATCH 2/7] x86, acpi, tboot: Have a ACPI sleep override instead of calling tboot_sleep. Thread-Index: AQHMaAxpmDG2lzlV9k+vsLkLH7seFZVBWmyg Date: Wed, 7 Sep 2011 04:20:17 +0000 Message-ID: <9F57BF860713DF4BA3EFA4F8C6DFEDAC16F3F524@ORSMSX101.amr.corp.intel.com> References: <1314815484-4668-1-git-send-email-konrad.wilk@oracle.com> <1314815484-4668-3-git-send-email-konrad.wilk@oracle.com> In-Reply-To: <1314815484-4668-3-git-send-email-konrad.wilk@oracle.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.22.254.139] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "xen-devel@lists.xensource.com" Subject: [Xen-devel] RE: [PATCH 2/7] x86, acpi, tboot: Have a ACPI sleep override instead of calling tboot_sleep. X-BeenThere: xen-devel@lists.xensource.com X-Mailman-Version: 2.1.5 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xensource.com Errors-To: xen-devel-bounces@lists.xensource.com > From: Konrad Rzeszutek Wilk [mailto:konrad.wilk@oracle.com] > Sent: Wednesday, August 31, 2011 11:31 AM >=20 > The ACPI suspend path makes a call to tboot_sleep right before it writes = the PM1A, PM1B values. We > replace the direct call to tboot via an registration callback similar to = __acpi_register_gsi. >=20 > CC: Thomas Gleixner > CC: "H. Peter Anvin" > CC: x86@kernel.org > CC: Len Brown > CC: Joseph Cihula > CC: Shane Wang > CC: xen-devel@lists.xensource.com > CC: linux-pm@lists.linux-foundation.org > CC: tboot-devel@lists.sourceforge.net > CC: linux-acpi@vger.kernel.org > Signed-off-by: Konrad Rzeszutek Wilk > --- > arch/x86/include/asm/acpi.h | 3 +++ > arch/x86/kernel/acpi/boot.c | 3 +++ > arch/x86/kernel/tboot.c | 13 +++++++++---- > drivers/acpi/acpica/hwsleep.c | 12 ++++++++++-- > include/linux/tboot.h | 3 ++- > 5 files changed, 27 insertions(+), 7 deletions(-) >=20 > diff --git a/arch/x86/include/asm/acpi.h b/arch/x86/include/asm/acpi.h in= dex 610001d..49864a1 > 100644 > --- a/arch/x86/include/asm/acpi.h > +++ b/arch/x86/include/asm/acpi.h > @@ -98,6 +98,9 @@ void acpi_pic_sci_set_trigger(unsigned int, u16); exte= rn int > (*__acpi_register_gsi)(struct device *dev, u32 gsi, > int trigger, int polarity); >=20 > +extern int (*__acpi_override_sleep)(u8 sleep_state, u32 pm1a_ctrl, > + u32 pm1b_ctrl, bool *skip_rest); > + > static inline void disable_acpi(void) > { > acpi_disabled =3D 1; > diff --git a/arch/x86/kernel/acpi/boot.c b/arch/x86/kernel/acpi/boot.c in= dex 4558f0d..d191b4c > 100644 > --- a/arch/x86/kernel/acpi/boot.c > +++ b/arch/x86/kernel/acpi/boot.c > @@ -552,6 +552,9 @@ static int acpi_register_gsi_ioapic(struct device *de= v, u32 gsi, int > (*__acpi_register_gsi)(struct device *dev, u32 gsi, > int trigger, int polarity) =3D acpi_register_gsi_pic; >=20 > +int (*__acpi_override_sleep)(u8 sleep_state, u32 pm1a_ctrl, > + u32 pm1b_ctrl, bool *skip_rest) =3D NULL; > + > /* > * success: return IRQ number (>=3D0) > * failure: return < 0 > diff --git a/arch/x86/kernel/tboot.c b/arch/x86/kernel/tboot.c index 30ac= 65d..a18070c 100644 > --- a/arch/x86/kernel/tboot.c > +++ b/arch/x86/kernel/tboot.c > @@ -41,7 +41,7 @@ > #include > #include > #include > - > +#include > #include "acpi/realmode/wakeup.h" >=20 > /* Global pointer to shared data; NULL means no measured launch. */ @@ -= 270,7 +270,8 @@ static > void tboot_copy_fadt(const struct acpi_table_fadt *fadt) > offsetof(struct acpi_table_facs, firmware_waking_vector); } >=20 > -void tboot_sleep(u8 sleep_state, u32 pm1a_control, u32 pm1b_control) > +int tboot_sleep(u8 sleep_state, u32 pm1a_control, u32 pm1b_control, > + bool *skip_rest) Don't you need to use the 'unused' attrib on skip_rest in order to prevent = compiler warnings? > { > static u32 acpi_shutdown_map[ACPI_S_STATE_COUNT] =3D { > /* S0,1,2: */ -1, -1, -1, > @@ -279,7 +280,7 @@ void tboot_sleep(u8 sleep_state, u32 pm1a_control, u3= 2 pm1b_control) > /* S5: */ TB_SHUTDOWN_S5 }; >=20 > if (!tboot_enabled()) > - return; > + return AE_OK; >=20 > tboot_copy_fadt(&acpi_gbl_FADT); > tboot->acpi_sinfo.pm1a_cnt_val =3D pm1a_control; @@ -290,10 +291,12 @@ = void tboot_sleep(u8 > sleep_state, u32 pm1a_control, u32 pm1b_control) > if (sleep_state >=3D ACPI_S_STATE_COUNT || > acpi_shutdown_map[sleep_state] =3D=3D -1) { > pr_warning("unsupported sleep state 0x%x\n", sleep_state); > - return; > + return AE_ERROR; > } >=20 > tboot_shutdown(acpi_shutdown_map[sleep_state]); > + > + return AE_OK; > } >=20 > static atomic_t ap_wfs_count; > @@ -343,6 +346,8 @@ static __init int tboot_late_init(void) >=20 > atomic_set(&ap_wfs_count, 0); > register_hotcpu_notifier(&tboot_cpu_notifier); > + > + __acpi_override_sleep =3D tboot_sleep; > return 0; > } >=20 > diff --git a/drivers/acpi/acpica/hwsleep.c b/drivers/acpi/acpica/hwsleep.= c index 2ac28bb..31d1198 > 100644 > --- a/drivers/acpi/acpica/hwsleep.c > +++ b/drivers/acpi/acpica/hwsleep.c > @@ -45,7 +45,6 @@ > #include > #include "accommon.h" > #include "actables.h" > -#include >=20 > #define _COMPONENT ACPI_HARDWARE > ACPI_MODULE_NAME("hwsleep") > @@ -343,8 +342,17 @@ acpi_status asmlinkage acpi_enter_sleep_state(u8 sle= ep_state) >=20 > ACPI_FLUSH_CPU_CACHE(); >=20 > - tboot_sleep(sleep_state, pm1a_control, pm1b_control); > + if (__acpi_override_sleep) { > + bool skip_rest =3D false; >=20 > + status =3D __acpi_override_sleep(sleep_state, pm1a_control, > + pm1b_control, &skip_rest); > + > + if (ACPI_FAILURE(status)) > + return_ACPI_STATUS(status); > + if (skip_rest) > + return_ACPI_STATUS(AE_OK); > + } > /* Write #2: Write both SLP_TYP + SLP_EN */ >=20 > status =3D acpi_hw_write_pm1_control(pm1a_control, pm1b_control); diff = --git > a/include/linux/tboot.h b/include/linux/tboot.h index 1dba6ee..19badbd 10= 0644 > --- a/include/linux/tboot.h > +++ b/include/linux/tboot.h > @@ -143,7 +143,8 @@ static inline int tboot_enabled(void) >=20 > extern void tboot_probe(void); > extern void tboot_shutdown(u32 shutdown_type); -extern void tboot_sleep(= u8 sleep_state, u32 > pm1a_control, u32 pm1b_control); > +extern int tboot_sleep(u8 sleep_state, u32 pm1a_control, u32 pm1b_contro= l, > + bool *skip); > extern struct acpi_table_header *tboot_get_dmar_table( > struct acpi_table_header *dmar_tbl); extern int > tboot_force_iommu(void); > -- > 1.7.4.1 _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel From xen-devel-bounces@lists.xensource.com Tue Sep 06 21:37:27 2011 Return-path: Envelope-to: www-data@lists.xensource.com Delivery-date: Tue, 06 Sep 2011 21:37:27 -0700 Received: from localhost ([127.0.0.1] helo=lists.colo.xensource.com) by lists.xensource.com with esmtp (Exim 4.43) id 1R19t9-0000mR-1T; Tue, 06 Sep 2011 21:37:27 -0700 Received: from mail216.messagelabs.com ([85.158.143.99]) by lists.xensource.com with smtp (Exim 4.43) id 1R19sd-0000Zj-Sj for xen-devel@lists.xensource.com; Tue, 06 Sep 2011 21:36:56 -0700 X-Env-Sender: joseph.cihula@intel.com X-Msg-Ref: server-12.tower-216.messagelabs.com!1315370211!11584229!1 X-Originating-IP: [134.134.136.24] X-StarScan-Version: 6.3.6; banners=-,-,- X-VirusChecked: Checked Received: (qmail 28028 invoked from network); 7 Sep 2011 04:36:52 -0000 Received: from mga09.intel.com (HELO mga09.intel.com) (134.134.136.24) by server-12.tower-216.messagelabs.com with SMTP; 7 Sep 2011 04:36:52 -0000 Received: from orsmga002.jf.intel.com ([10.7.209.21]) by orsmga102.jf.intel.com with ESMTP; 06 Sep 2011 21:36:51 -0700 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="4.67,351,1309762800"; d="scan'208";a="45739770" Received: from orsmsx603.amr.corp.intel.com ([10.22.226.49]) by orsmga002.jf.intel.com with ESMTP; 06 Sep 2011 21:36:51 -0700 Received: from orsmsx152.amr.corp.intel.com (10.22.226.39) by orsmsx603.amr.corp.intel.com (10.22.226.49) with Microsoft SMTP Server (TLS) id 8.2.255.0; Tue, 6 Sep 2011 21:36:50 -0700 Received: from orsmsx101.amr.corp.intel.com ([169.254.8.19]) by ORSMSX152.amr.corp.intel.com ([169.254.8.126]) with mapi id 14.01.0323.003; Tue, 6 Sep 2011 21:36:50 -0700 From: "Cihula, Joseph" To: Konrad Rzeszutek Wilk , "x86@kernel.org" , "tglx@linutronix.de" , "tboot-devel@lists.sourceforge.net" , "Wang, Shane" , "linux-pm@lists.linux-foundation.org" , "linux-acpi@vger.kernel.org" , "Brown, Len" , "hpa@zytor.com" , "Yu, Ke" , "liang.tang@oracle.com" , "Tian, Kevin" , "keir@xen.org" Thread-Topic: [PATCH 6/7] xen/acpi/sleep: Enable ACPI sleep via the __acpi_override_sleep Thread-Index: AQHMaAxA4F/ZCpv8PUCD6otPeC7MhpVBXsng Date: Wed, 7 Sep 2011 04:36:49 +0000 Message-ID: <9F57BF860713DF4BA3EFA4F8C6DFEDAC16F3F5BC@ORSMSX101.amr.corp.intel.com> References: <1314815484-4668-1-git-send-email-konrad.wilk@oracle.com> <1314815484-4668-7-git-send-email-konrad.wilk@oracle.com> In-Reply-To: <1314815484-4668-7-git-send-email-konrad.wilk@oracle.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.22.254.139] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "xen-devel@lists.xensource.com" Subject: [Xen-devel] RE: [PATCH 6/7] xen/acpi/sleep: Enable ACPI sleep via the __acpi_override_sleep X-BeenThere: xen-devel@lists.xensource.com X-Mailman-Version: 2.1.5 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xensource.com Errors-To: xen-devel-bounces@lists.xensource.com > From: Konrad Rzeszutek Wilk [mailto:konrad.wilk@oracle.com] > Sent: Wednesday, August 31, 2011 11:31 AM >=20 > Provide the registration callback to call in the Xen's ACPI sleep functio= nality. This means that > during S3/S5 we make a hypercall XENPF_enter_acpi_sleep with the proper P= M1A/PM1B registers. >=20 > Based of Ke Yu's initial idea. > [ From http://xenbits.xensource.com/linux-2.6.18-xen.hg > change c68699484a65 ] >=20 > Signed-off-by: Konrad Rzeszutek Wilk > --- > arch/x86/include/asm/xen/hypercall.h | 8 ++++++++ > arch/x86/xen/enlighten.c | 3 +++ > drivers/xen/Makefile | 2 +- > drivers/xen/acpi.c | 25 +++++++++++++++++++++++++ > include/xen/acpi.h | 26 ++++++++++++++++++++++++++ > 5 files changed, 63 insertions(+), 1 deletions(-) create mode 100644 dr= ivers/xen/acpi.c create > mode 100644 include/xen/acpi.h >=20 > diff --git a/arch/x86/include/asm/xen/hypercall.h b/arch/x86/include/asm/= xen/hypercall.h > index d240ea9..0c9894e 100644 > --- a/arch/x86/include/asm/xen/hypercall.h > +++ b/arch/x86/include/asm/xen/hypercall.h > @@ -45,6 +45,7 @@ > #include > #include > #include > +#include >=20 > /* > * The hypercall asms have to meet several constraints: > @@ -299,6 +300,13 @@ HYPERVISOR_set_timer_op(u64 timeout) } >=20 > static inline int > +HYPERVISOR_dom0_op(struct xen_platform_op *platform_op) { > + platform_op->interface_version =3D XENPF_INTERFACE_VERSION; > + return _hypercall1(int, dom0_op, platform_op); } > + > +static inline int > HYPERVISOR_set_debugreg(int reg, unsigned long value) { > return _hypercall2(int, set_debugreg, reg, value); diff --git a/arch/x8= 6/xen/enlighten.c > b/arch/x86/xen/enlighten.c index 5525163..6962653 100644 > --- a/arch/x86/xen/enlighten.c > +++ b/arch/x86/xen/enlighten.c > @@ -42,6 +42,7 @@ > #include > #include > #include > +#include >=20 > #include > #include > @@ -1250,6 +1251,8 @@ asmlinkage void __init xen_start_kernel(void) > } else { > /* Make sure ACS will be enabled */ > pci_request_acs(); > + > + xen_acpi_sleep_register(); > } >=20 >=20 > diff --git a/drivers/xen/Makefile b/drivers/xen/Makefile index bbc1825..3= 70552d 100644 > --- a/drivers/xen/Makefile > +++ b/drivers/xen/Makefile > @@ -16,7 +16,7 @@ obj-$(CONFIG_XENFS) +=3D xenfs/ > obj-$(CONFIG_XEN_SYS_HYPERVISOR) +=3D sys-hypervisor.o > obj-$(CONFIG_XEN_PLATFORM_PCI) +=3D xen-platform-pci.o > obj-$(CONFIG_SWIOTLB_XEN) +=3D swiotlb-xen.o > -obj-$(CONFIG_XEN_DOM0) +=3D pci.o > +obj-$(CONFIG_XEN_DOM0) +=3D pci.o acpi.o >=20 > xen-evtchn-y :=3D evtchn.o > xen-gntdev-y :=3D gntdev.o > diff --git a/drivers/xen/acpi.c b/drivers/xen/acpi.c new file mode 100644= index 0000000..c0f829f > --- /dev/null > +++ b/drivers/xen/acpi.c > @@ -0,0 +1,25 @@ Copyright and license? > +#include > +#include > +#include > +#include > + > +int xen_acpi_notify_hypervisor_state(u8 sleep_state, > + u32 pm1a_cnt, u32 pm1b_cnt, > + bool *skip_rest) > +{ > + struct xen_platform_op op =3D { > + .cmd =3D XENPF_enter_acpi_sleep, > + .interface_version =3D XENPF_INTERFACE_VERSION, > + .u =3D { > + .enter_acpi_sleep =3D { > + .pm1a_cnt_val =3D (u16)pm1a_cnt, > + .pm1b_cnt_val =3D (u16)pm1b_cnt, > + .sleep_state =3D sleep_state, > + }, > + }, > + }; > + if (skip_rest) > + *skip_rest =3D true; > + > + return HYPERVISOR_dom0_op(&op); > +} > diff --git a/include/xen/acpi.h b/include/xen/acpi.h new file mode 100644= index 0000000..e414f14 > --- /dev/null > +++ b/include/xen/acpi.h > @@ -0,0 +1,26 @@ Copyright and license? > +#ifndef _XEN_ACPI_H > +#define _XEN_ACPI_H > + > +#include > + > +#ifdef CONFIG_XEN_DOM0 > +#include > +#include > +#include > + > +int xen_acpi_notify_hypervisor_state(u8 sleep_state, > + u32 pm1a_cnt, u32 pm1b_cnd, > + bool *skip_rest); > + > +static inline void xen_acpi_sleep_register(void) { > + if (xen_initial_domain()) > + __acpi_override_sleep =3D xen_acpi_notify_hypervisor_state; } #else > +static inline void xen_acpi_sleep_register(void) { } #endif > + > +#endif /* _XEN_ACPI_H */ > -- > 1.7.4.1 _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel From xen-devel-bounces@lists.xensource.com Tue Sep 06 22:51:57 2011 Return-path: Envelope-to: www-data@lists.xensource.com Delivery-date: Tue, 06 Sep 2011 22:51:57 -0700 Received: from localhost ([127.0.0.1] helo=lists.colo.xensource.com) by lists.xensource.com with esmtp (Exim 4.43) id 1R1B3D-0002JV-9c; Tue, 06 Sep 2011 22:51:55 -0700 Received: from mail174.messagelabs.com ([85.158.138.51]) by lists.xensource.com with smtp (Exim 4.43) id 1R1B2F-00026i-Un for xen-devel@lists.xensource.com; Tue, 06 Sep 2011 22:50:56 -0700 X-Env-Sender: joseph.cihula@intel.com X-Msg-Ref: server-11.tower-174.messagelabs.com!1315374651!30493299!1 X-Originating-IP: [134.134.136.20] X-StarScan-Version: 6.3.6; banners=-,-,- X-VirusChecked: Checked Received: (qmail 5349 invoked from network); 7 Sep 2011 05:50:52 -0000 Received: from mga02.intel.com (HELO mga02.intel.com) (134.134.136.20) by server-11.tower-174.messagelabs.com with SMTP; 7 Sep 2011 05:50:52 -0000 Received: from orsmga001.jf.intel.com ([10.7.209.18]) by orsmga101.jf.intel.com with ESMTP; 06 Sep 2011 22:50:50 -0700 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="4.67,352,1309762800"; d="scan'208";a="45931781" Received: from orsmsx603.amr.corp.intel.com ([10.22.226.49]) by orsmga001.jf.intel.com with ESMTP; 06 Sep 2011 22:50:50 -0700 Received: from orsmsx151.amr.corp.intel.com (10.22.226.38) by orsmsx603.amr.corp.intel.com (10.22.226.49) with Microsoft SMTP Server (TLS) id 8.2.255.0; Tue, 6 Sep 2011 22:50:50 -0700 Received: from orsmsx101.amr.corp.intel.com ([169.254.8.19]) by ORSMSX151.amr.corp.intel.com ([169.254.7.187]) with mapi id 14.01.0323.003; Tue, 6 Sep 2011 22:50:50 -0700 From: "Cihula, Joseph" To: Konrad Rzeszutek Wilk , "x86@kernel.org" , "tglx@linutronix.de" , "tboot-devel@lists.sourceforge.net" , "Wang, Shane" , "linux-pm@lists.linux-foundation.org" , "linux-acpi@vger.kernel.org" , "Brown, Len" , "hpa@zytor.com" , "Yu, Ke" , "liang.tang@oracle.com" , "Tian, Kevin" , "keir@xen.org" Thread-Topic: [PATCH 5/7] xen/acpi: Domain0 acpi parser related platform hypercall Thread-Index: AQHMaAxZ5wNVyrMQuUW3m3AFnHdXf5VBc1bg Date: Wed, 7 Sep 2011 05:50:49 +0000 Message-ID: <9F57BF860713DF4BA3EFA4F8C6DFEDAC16F3F665@ORSMSX101.amr.corp.intel.com> References: <1314815484-4668-1-git-send-email-konrad.wilk@oracle.com> <1314815484-4668-6-git-send-email-konrad.wilk@oracle.com> In-Reply-To: <1314815484-4668-6-git-send-email-konrad.wilk@oracle.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.22.254.139] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "xen-devel@lists.xensource.com" , Jeremy, Fitzhardinge Subject: [Xen-devel] RE: [PATCH 5/7] xen/acpi: Domain0 acpi parser related platform hypercall X-BeenThere: xen-devel@lists.xensource.com X-Mailman-Version: 2.1.5 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xensource.com Errors-To: xen-devel-bounces@lists.xensource.com > From: Konrad Rzeszutek Wilk [mailto:konrad.wilk@oracle.com] > Sent: Wednesday, August 31, 2011 11:31 AM >=20 > From: Yu Ke >=20 > This patches implements the xen_platform_op hypercall, to pass the parsed= ACPI info to hypervisor. >=20 > Signed-off-by: Yu Ke > Signed-off-by: Tian Kevin > Signed-off-by: Jeremy Fitzhardinge > [v1: Added DEFINE_GUEST.. in appropiate headers] > [v2: Ripped out typedefs] > Signed-off-by: Konrad Rzeszutek Wilk > --- > arch/ia64/include/asm/xen/interface.h | 1 + > arch/x86/include/asm/xen/interface.h | 1 + > include/xen/interface/platform.h | 320 +++++++++++++++++++++++++++= ++++++ > include/xen/interface/xen.h | 1 + > 4 files changed, 323 insertions(+), 0 deletions(-) create mode 100644 > include/xen/interface/platform.h >=20 > diff --git a/arch/ia64/include/asm/xen/interface.h b/arch/ia64/include/as= m/xen/interface.h > index e951e74..1d2427d 100644 > --- a/arch/ia64/include/asm/xen/interface.h > +++ b/arch/ia64/include/asm/xen/interface.h > @@ -76,6 +76,7 @@ DEFINE_GUEST_HANDLE(char); DEFINE_GUEST_HANDLE(int); > DEFINE_GUEST_HANDLE(long); DEFINE_GUEST_HANDLE(void); > +DEFINE_GUEST_HANDLE(uint64_t); >=20 > typedef unsigned long xen_pfn_t; > DEFINE_GUEST_HANDLE(xen_pfn_t); > diff --git a/arch/x86/include/asm/xen/interface.h b/arch/x86/include/asm/= xen/interface.h > index 5d4922a..a1f2db5 100644 > --- a/arch/x86/include/asm/xen/interface.h > +++ b/arch/x86/include/asm/xen/interface.h > @@ -55,6 +55,7 @@ DEFINE_GUEST_HANDLE(char); DEFINE_GUEST_HANDLE(int); > DEFINE_GUEST_HANDLE(long); DEFINE_GUEST_HANDLE(void); > +DEFINE_GUEST_HANDLE(uint64_t); > #endif >=20 > #ifndef HYPERVISOR_VIRT_START > diff --git a/include/xen/interface/platform.h b/include/xen/interface/pla= tform.h > new file mode 100644 > index 0000000..c168468 > --- /dev/null > +++ b/include/xen/interface/platform.h Why are you adding so many new hypercalls that aren't being used in this pa= tchset? > @@ -0,0 +1,320 @@ > +/********************************************************************** > +******** > + * platform.h > + * > + * Hardware platform operations. Intended for use by domain-0 kernel. > + * > + * Permission is hereby granted, free of charge, to any person > +obtaining a copy > + * of this software and associated documentation files (the > +"Software"), to > + * deal in the Software without restriction, including without > +limitation the > + * rights to use, copy, modify, merge, publish, distribute, sublicense, > +and/or > + * sell copies of the Software, and to permit persons to whom the > +Software is > + * furnished to do so, subject to the following conditions: > + * > + * The above copyright notice and this permission notice shall be > +included in > + * all copies or substantial portions of the Software. > + * > + * THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, > +EXPRESS OR > + * IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF > +MERCHANTABILITY, > + * FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT > +SHALL THE > + * AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR > +OTHER > + * LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, > +ARISING > + * FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER > + * DEALINGS IN THE SOFTWARE. > + * > + * Copyright (c) 2002-2006, K Fraser > + */ > + > +#ifndef __XEN_PUBLIC_PLATFORM_H__ > +#define __XEN_PUBLIC_PLATFORM_H__ > + > +#include "xen.h" > + > +#define XENPF_INTERFACE_VERSION 0x03000001 > + > +/* > + * Set clock such that it would read after 00:00:00 UTC, > + * 1 January, 1970 if the current system time was . > + */ > +#define XENPF_settime 17 > +struct xenpf_settime { > + /* IN variables. */ > + uint32_t secs; > + uint32_t nsecs; > + uint64_t system_time; > +}; > +DEFINE_GUEST_HANDLE_STRUCT(xenpf_settime_t); > + > +/* > + * Request memory range (@mfn, @mfn+@nr_mfns-1) to have type @type. > + * On x86, @type is an architecture-defined MTRR memory type. > + * On success, returns the MTRR that was used (@reg) and a handle that > +can > + * be passed to XENPF_DEL_MEMTYPE to accurately tear down the new settin= g. > + * (x86-specific). > + */ > +#define XENPF_add_memtype 31 > +struct xenpf_add_memtype { > + /* IN variables. */ > + unsigned long mfn; > + uint64_t nr_mfns; > + uint32_t type; > + /* OUT variables. */ > + uint32_t handle; > + uint32_t reg; > +}; > +DEFINE_GUEST_HANDLE_STRUCT(xenpf_add_memtype_t); > + > +/* > + * Tear down an existing memory-range type. If @handle is remembered > +then it > + * should be passed in to accurately tear down the correct setting (in > +case > + * of overlapping memory regions with differing types). If it is not > +known > + * then @handle should be set to zero. In all cases @reg must be set. > + * (x86-specific). > + */ > +#define XENPF_del_memtype 32 > +struct xenpf_del_memtype { > + /* IN variables. */ > + uint32_t handle; > + uint32_t reg; > +}; > +DEFINE_GUEST_HANDLE_STRUCT(xenpf_del_memtype_t); > + > +/* Read current type of an MTRR (x86-specific). */ > +#define XENPF_read_memtype 33 > +struct xenpf_read_memtype { > + /* IN variables. */ > + uint32_t reg; > + /* OUT variables. */ > + unsigned long mfn; > + uint64_t nr_mfns; > + uint32_t type; > +}; > +DEFINE_GUEST_HANDLE_STRUCT(xenpf_read_memtype_t); > + > +#define XENPF_microcode_update 35 > +struct xenpf_microcode_update { > + /* IN variables. */ > + GUEST_HANDLE(void) data; /* Pointer to microcode data */ > + uint32_t length; /* Length of microcode data. */ > +}; > +DEFINE_GUEST_HANDLE_STRUCT(xenpf_microcode_update_t); > + > +#define XENPF_platform_quirk 39 > +#define QUIRK_NOIRQBALANCING 1 /* Do not restrict IO-APIC RTE targe= ts */ > +#define QUIRK_IOAPIC_BAD_REGSEL 2 /* IO-APIC REGSEL forgets its value = */ > +#define QUIRK_IOAPIC_GOOD_REGSEL 3 /* IO-APIC REGSEL behaves properly = */ > +struct xenpf_platform_quirk { > + /* IN variables. */ > + uint32_t quirk_id; > +}; > +DEFINE_GUEST_HANDLE_STRUCT(xenpf_platform_quirk_t); > + > +#define XENPF_firmware_info 50 > +#define XEN_FW_DISK_INFO 1 /* from int 13 AH=3D08/41/48 */ > +#define XEN_FW_DISK_MBR_SIGNATURE 2 /* from MBR offset 0x1b8 */ > +#define XEN_FW_VBEDDC_INFO 3 /* from int 10 AX=3D4f15 */ > +struct xenpf_firmware_info { > + /* IN variables. */ > + uint32_t type; > + uint32_t index; > + /* OUT variables. */ > + union { > + struct { > + /* Int13, Fn48: Check Extensions Present. */ > + uint8_t device; /* %dl: bios device number */ > + uint8_t version; /* %ah: major version */ > + uint16_t interface_support; /* %cx: support bitmap */ > + /* Int13, Fn08: Legacy Get Device Parameters. */ > + uint16_t legacy_max_cylinder; /* %cl[7:6]:%ch: max cyl # */ > + uint8_t legacy_max_head; /* %dh: max head # */ > + uint8_t legacy_sectors_per_track; /* %cl[5:0]: max sector # */ > + /* Int13, Fn41: Get Device Parameters (as filled into %ds:%esi). */ > + /* NB. First uint16_t of buffer must be set to buffer size. */ > + GUEST_HANDLE(void) edd_params; > + } disk_info; /* XEN_FW_DISK_INFO */ > + struct { > + uint8_t device; /* bios device number */ > + uint32_t mbr_signature; /* offset 0x1b8 in mbr */ > + } disk_mbr_signature; /* XEN_FW_DISK_MBR_SIGNATURE */ > + struct { > + /* Int10, AX=3D4F15: Get EDID info. */ > + uint8_t capabilities; > + uint8_t edid_transfer_time; > + /* must refer to 128-byte buffer */ > + GUEST_HANDLE(uchar) edid; > + } vbeddc_info; /* XEN_FW_VBEDDC_INFO */ > + } u; > +}; > +DEFINE_GUEST_HANDLE_STRUCT(xenpf_firmware_info_t); > + > +#define XENPF_enter_acpi_sleep 51 > +struct xenpf_enter_acpi_sleep { > + /* IN variables */ > + uint16_t pm1a_cnt_val; /* PM1a control value. */ > + uint16_t pm1b_cnt_val; /* PM1b control value. */ These are uint32_t in native Linux--why truncate in the API and not at use? > + uint32_t sleep_state; /* Which state to enter (Sn). */ > + uint32_t flags; /* Must be zero. */ > +}; > +DEFINE_GUEST_HANDLE_STRUCT(xenpf_enter_acpi_sleep_t); > + > +#define XENPF_change_freq 52 > +struct xenpf_change_freq { > + /* IN variables */ > + uint32_t flags; /* Must be zero. */ > + uint32_t cpu; /* Physical cpu. */ > + uint64_t freq; /* New frequency (Hz). */ }; > +DEFINE_GUEST_HANDLE_STRUCT(xenpf_change_freq_t); > + > +/* > + * Get idle times (nanoseconds since boot) for physical CPUs specified > +in the > + * @cpumap_bitmap with range [0..@cpumap_nr_cpus-1]. The @idletime > +array is > + * indexed by CPU number; only entries with the corresponding > +@cpumap_bitmap > + * bit set are written to. On return, @cpumap_bitmap is modified so > +that any > + * non-existent CPUs are cleared. Such CPUs have their @idletime array > +entry > + * cleared. > + */ > +#define XENPF_getidletime 53 > +struct xenpf_getidletime { > + /* IN/OUT variables */ > + /* IN: CPUs to interrogate; OUT: subset of IN which are present */ > + GUEST_HANDLE(uchar) cpumap_bitmap; > + /* IN variables */ > + /* Size of cpumap bitmap. */ > + uint32_t cpumap_nr_cpus; > + /* Must be indexable for every cpu in cpumap_bitmap. */ > + GUEST_HANDLE(uint64_t) idletime; > + /* OUT variables */ > + /* System time when the idletime snapshots were taken. */ > + uint64_t now; > +}; > +DEFINE_GUEST_HANDLE_STRUCT(xenpf_getidletime_t); > + > +#define XENPF_set_processor_pminfo 54 > + > +/* ability bits */ > +#define XEN_PROCESSOR_PM_CX 1 > +#define XEN_PROCESSOR_PM_PX 2 > +#define XEN_PROCESSOR_PM_TX 4 > + > +/* cmd type */ > +#define XEN_PM_CX 0 > +#define XEN_PM_PX 1 > +#define XEN_PM_TX 2 > + > +/* Px sub info type */ > +#define XEN_PX_PCT 1 > +#define XEN_PX_PSS 2 > +#define XEN_PX_PPC 4 > +#define XEN_PX_PSD 8 > + > +struct xen_power_register { > + uint32_t space_id; > + uint32_t bit_width; > + uint32_t bit_offset; > + uint32_t access_size; > + uint64_t address; > +}; > + > +struct xen_processor_csd { > + uint32_t domain; /* domain number of one dependent group */ > + uint32_t coord_type; /* coordination type */ > + uint32_t num; /* number of processors in same domain */ > +}; > +DEFINE_GUEST_HANDLE_STRUCT(xen_processor_csd); > + > +struct xen_processor_cx { > + struct xen_power_register reg; /* GAS for Cx trigger register */ > + uint8_t type; /* cstate value, c0: 0, c1: 1, ... */ > + uint32_t latency; /* worst latency (ms) to enter/exit this cstate *= / > + uint32_t power; /* average power consumption(mW) */ > + uint32_t dpcnt; /* number of dependency entries */ > + GUEST_HANDLE(xen_processor_csd) dp; /* NULL if no dependency */ }; > +DEFINE_GUEST_HANDLE_STRUCT(xen_processor_cx); > + > +struct xen_processor_flags { > + uint32_t bm_control:1; > + uint32_t bm_check:1; > + uint32_t has_cst:1; > + uint32_t power_setup_done:1; > + uint32_t bm_rld_set:1; > +}; > + > +struct xen_processor_power { > + uint32_t count; /* number of C state entries in array below */ > + struct xen_processor_flags flags; /* global flags of this processor */ > + GUEST_HANDLE(xen_processor_cx) states; /* supported c states */ }; > + > +struct xen_pct_register { > + uint8_t descriptor; > + uint16_t length; > + uint8_t space_id; > + uint8_t bit_width; > + uint8_t bit_offset; > + uint8_t reserved; > + uint64_t address; > +}; > + > +struct xen_processor_px { > + uint64_t core_frequency; /* megahertz */ > + uint64_t power; /* milliWatts */ > + uint64_t transition_latency; /* microseconds */ > + uint64_t bus_master_latency; /* microseconds */ > + uint64_t control; /* control value */ > + uint64_t status; /* success indicator */ > +}; > +DEFINE_GUEST_HANDLE_STRUCT(xen_processor_px); > + > +struct xen_psd_package { > + uint64_t num_entries; > + uint64_t revision; > + uint64_t domain; > + uint64_t coord_type; > + uint64_t num_processors; > +}; > + > +struct xen_processor_performance { > + uint32_t flags; /* flag for Px sub info type */ > + uint32_t platform_limit; /* Platform limitation on freq usage */ > + struct xen_pct_register control_register; > + struct xen_pct_register status_register; > + uint32_t state_count; /* total available performance states */ > + GUEST_HANDLE(xen_processor_px) states; > + struct xen_psd_package domain_info; > + uint32_t shared_type; /* coordination type of this processor */ > +}; > +DEFINE_GUEST_HANDLE_STRUCT(xen_processor_performance); > + > +struct xenpf_set_processor_pminfo { > + /* IN variables */ > + uint32_t id; /* ACPI CPU ID */ > + uint32_t type; /* {XEN_PM_CX, XEN_PM_PX} */ > + union { > + struct xen_processor_power power;/* Cx: _CST/_CSD */ > + struct xen_processor_performance perf; /* Px: _PPC/_PCT/_PSS/_PSD *= / > + }; > +}; > +DEFINE_GUEST_HANDLE_STRUCT(xenpf_set_processor_pminfo); > + > +struct xen_platform_op { > + uint32_t cmd; > + uint32_t interface_version; /* XENPF_INTERFACE_VERSION */ > + union { > + struct xenpf_settime settime; > + struct xenpf_add_memtype add_memtype; > + struct xenpf_del_memtype del_memtype; > + struct xenpf_read_memtype read_memtype; > + struct xenpf_microcode_update microcode; > + struct xenpf_platform_quirk platform_quirk; > + struct xenpf_firmware_info firmware_info; > + struct xenpf_enter_acpi_sleep enter_acpi_sleep; > + struct xenpf_change_freq change_freq; > + struct xenpf_getidletime getidletime; > + struct xenpf_set_processor_pminfo set_pminfo; > + uint8_t pad[128]; > + } u; > +}; > +DEFINE_GUEST_HANDLE_STRUCT(xen_platform_op_t); > + > +#endif /* __XEN_PUBLIC_PLATFORM_H__ */ > diff --git a/include/xen/interface/xen.h b/include/xen/interface/xen.h in= dex 70213b4..d83cc08 > 100644 > --- a/include/xen/interface/xen.h > +++ b/include/xen/interface/xen.h > @@ -453,6 +453,7 @@ struct start_info { > /* These flags are passed in the 'flags' field of start_info_t. */ > #define SIF_PRIVILEGED (1<<0) /* Is the domain privileged? */ > #define SIF_INITDOMAIN (1<<1) /* Is this the initial control domain?= */ > +#define SIF_PM_MASK (0xFF<<8) /* reserve 1 byte for xen-pm options= */ >=20 > typedef uint64_t cpumap_t; >=20 > -- > 1.7.4.1 _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel From xen-devel-bounces@lists.xensource.com Wed Sep 07 01:06:47 2011 Return-path: Envelope-to: www-data@lists.xensource.com Delivery-date: Wed, 07 Sep 2011 01:06:47 -0700 Received: from localhost ([127.0.0.1] helo=lists.colo.xensource.com) by lists.xensource.com with esmtp (Exim 4.43) id 1R1D9i-0006Mw-Vh; Wed, 07 Sep 2011 01:06:47 -0700 Received: from mail216.messagelabs.com ([85.158.143.99]) by lists.xensource.com with esmtp (Exim 4.43) id 1R1D8l-0006A6-8j for xen-devel@lists.xensource.com; Wed, 07 Sep 2011 01:05:47 -0700 X-Env-Sender: komkon555@freenet.de X-Msg-Ref: server-14.tower-216.messagelabs.com!1315382742!17347258!1 X-Originating-IP: [216.139.236.26] X-StarScan-Version: 6.3.6; banners=-,-,- X-VirusChecked: Checked Received: (qmail 14369 invoked from network); 7 Sep 2011 08:05:44 -0000 Received: from sam.nabble.com (HELO sam.nabble.com) (216.139.236.26) by server-14.tower-216.messagelabs.com with AES256-SHA encrypted SMTP; 7 Sep 2011 08:05:44 -0000 Received: from [192.168.236.26] (helo=sam.nabble.com) by sam.nabble.com with esmtp (Exim 4.72) (envelope-from ) id 1R1D8g-0006QI-8s for xen-devel@lists.xensource.com; Wed, 07 Sep 2011 01:05:42 -0700 Date: Wed, 7 Sep 2011 01:05:42 -0700 (PDT) From: komkon555 To: xen-devel@lists.xensource.com Message-ID: <1315382742268-4777689.post@n5.nabble.com> In-Reply-To: <1315343879.61837.YahooMailNeo@web29818.mail.ird.yahoo.com> References: <1314716445148-4750357.post@n5.nabble.com> <1314720409505-4750600.post@n5.nabble.com> <1314778567400-4753326.post@n5.nabble.com> <20110831083832.GD7276@reaktio.net> <1314780568949-4753422.post@n5.nabble.com> <1314795401771-4754024.post@n5.nabble.com> <20110831151913.GE7276@reaktio.net> <1315231341254-4770602.post@n5.nabble.com> <1315310225039-4774097.post@n5.nabble.com> <1315343879.61837.YahooMailNeo@web29818.mail.ird.yahoo.com> Subject: Re: Re : [Xen-devel] Re: Patches for VGA-Passthrough XEN 4.2 unstable MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-BeenThere: xen-devel@lists.xensource.com X-Mailman-Version: 2.1.5 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xensource.com Errors-To: xen-devel-bounces@lists.xensource.com Hallo. Can you please explain, what is exactly to do with dsd. I don't understand it. Which entrance are what for? Thank you. -- View this message in context: http://xen.1045712.n5.nabble.com/Patches-for-VGA-Passthrough-XEN-4-2-unstable-tp4406265p4777689.html Sent from the Xen - Dev mailing list archive at Nabble.com. _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel From xen-devel-bounces@lists.xensource.com Wed Sep 07 02:05:45 2011 Return-path: Envelope-to: www-data@lists.xensource.com Delivery-date: Wed, 07 Sep 2011 02:05:45 -0700 Received: from localhost ([127.0.0.1] helo=lists.colo.xensource.com) by lists.xensource.com with esmtp (Exim 4.43) id 1R1E4m-0007iY-W0; Wed, 07 Sep 2011 02:05:45 -0700 Received: from mail216.messagelabs.com ([85.158.143.99]) by lists.xensource.com with esmtp (Exim 4.43) id 1R1E2Y-0007Ud-Df for xen-devel@lists.xensource.com; Wed, 07 Sep 2011 02:03:31 -0700 X-Env-Sender: joanna@invisiblethingslab.com X-Msg-Ref: server-4.tower-216.messagelabs.com!1315386202!17335721!1 X-Originating-IP: [66.111.4.28] X-StarScan-Version: 6.3.6; banners=-,-,- X-VirusChecked: Checked Received: (qmail 6156 invoked from network); 7 Sep 2011 09:03:22 -0000 Received: from out4.smtp.messagingengine.com (HELO out4.smtp.messagingengine.com) (66.111.4.28) by server-4.tower-216.messagelabs.com with DHE-RSA-AES256-SHA encrypted SMTP; 7 Sep 2011 09:03:22 -0000 Received: from compute5.internal (compute5.nyi.mail.srv.osa [10.202.2.45]) by gateway1.nyi.mail.srv.osa (Postfix) with ESMTP id D41F3292A5; Wed, 7 Sep 2011 05:03:21 -0400 (EDT) Received: from frontend2.nyi.mail.srv.osa ([10.202.2.161]) by compute5.internal (MEProxy); Wed, 07 Sep 2011 05:03:21 -0400 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d= messagingengine.com; h=message-id:date:from:mime-version:to:cc :subject:references:in-reply-to:content-type; s=smtpout; bh=vAhY 9D/iXYq++jB1gp/+vbrgWFc=; b=Oge5xN+pSbxwHEAeitPr49zQf+58SefZGsrg 56qY2C3ESlEgucfywslLwy9/nBNiJZxuLh2CstlD5fqJhzTNqS8v9iCfTl/R030D p8D6ShHiCcgQ/EIrIcbjrVm53wKQmySWKpdhEEXvLXqqY7Af8ameUs/Rewovllzd BQidTms= X-Sasl-enc: ER4UuewgPDUZ6h1aY/aiGQTOlEEDOIn06U9vljAwQ7m/ 1315386201 Received: from [10.137.2.8] (aatx51.neoplus.adsl.tpnet.pl [83.6.5.51]) by mail.messagingengine.com (Postfix) with ESMTPSA id E08246E073F; Wed, 7 Sep 2011 05:03:20 -0400 (EDT) Message-ID: <4E673351.6060206@invisiblethingslab.com> Date: Wed, 07 Sep 2011 11:03:13 +0200 From: Joanna Rutkowska User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.2.18) Gecko/20110621 Fedora/3.1.11-1.fc14 Thunderbird/3.1.11 MIME-Version: 1.0 To: Dan Magenheimer Subject: Re: [Xen-devel] dom0 is stalled until a keypress References: <20110905091937.GA1906@email> <36a5b662-4420-41aa-be01-445f83b15a7b@default 4E664BEE.9000208@invisiblethingslab.com> <71fba00b-9a7a-4029-ac11-4d37732bb53f@default> In-Reply-To: <71fba00b-9a7a-4029-ac11-4d37732bb53f@default> X-Enigmail-Version: 1.1.2 Cc: xen-devel@lists.xensource.com, Rafal Wojtczuk X-BeenThere: xen-devel@lists.xensource.com X-Mailman-Version: 2.1.5 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0347598744==" Sender: xen-devel-bounces@lists.xensource.com Errors-To: xen-devel-bounces@lists.xensource.com This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --===============0347598744== Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="------------enigF38E68AB495573FBA3C5C4CE" This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enigF38E68AB495573FBA3C5C4CE Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable On 09/06/11 19:17, Dan Magenheimer wrote: >> From: Joanna Rutkowska [mailto:joanna@invisiblethingslab.com] >> Subject: Re: [Xen-devel] dom0 is stalled until a keypress >> >> On 09/06/11 17:49, Dan Magenheimer wrote: >>>> From: Rafal Wojtczuk [mailto:rafal@invisiblethingslab.com] >>>> Sent: Monday, September 05, 2011 3:20 AM >>>> To: xen-devel@lists.xensource.com >>>> Subject: [Xen-devel] dom0 is stalled until a keypress >>>> >>>> Hello, >>>> The following bizarre behaviour was observed on xen4.1+suse dom0 2.6= =2E38, on >>>> an old Core Duo laptop; maybe someone can hint what is wrong. >>>> Dom0 boot stalls after an init.d script prints "Starting udev". Then= nothing >>>> seems to happen. I need to press any key to observe progress - I nee= d to do >>>> it tens of times for the boot to finish. After X starts fine, then t= here is >>>> no need for keypressing anymore. >>>> A particularly disturbing fact is that qrexec_daemon parent, that ba= sically >>>> does >>>> for (;;) { sleep(1); fprintf(stderr, "."); } >>>> does not print dots, until a keypress arrives. So something is very = wrong >>>> with timers. >>>> Somehow similarly, pm-suspend sometimes hangs at some stage - after = detaching >>>> power cord, machine enters S3 immediately. >>>> This is vaguely similar to the issue described in >>>> https://lkml.org/lkml/2008/9/14/122 >>>> but this time, "nohz=3Doff" does not help. >>>> >>>> "cpufreq=3Ddom0-kernel" cures the symptoms; but it is not a sideeffe= ctless >>>> solution. Any idea what is going on or how to debug it ? >>> >>> ISTR seeing this on a Core(2?)Duo laptop and I think the >>> workaround was setting max_cstate=3D0 (as Xen boot parameter). >>> >> But what was the actual problem? Setting max_cstate is probably even >> worse for power management than setting cpufreq=3Ddom-kernel, isn't it= ? >=20 > Sorry, dunno. I recall looking into it a bit and finding that > the Core processor (and possibly specifically Merom, the laptop > version) had some special C-state (C3, C1E maybe?) and giving > up at that point. Sorry I can't be more helpful. But the same system worked fine without any tweaks (cpufreq, max_cstate) on Xen 3.4 and only started exhibiting this behavior after we switched to Xen 4.1... j. --------------enigF38E68AB495573FBA3C5C4CE Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org/ iQEcBAEBAgAGBQJOZzNSAAoJEDaIqHeRBUM02nsH/0/kZg0wCi7w+TdGqYEnA+k8 5KQfvdDUidWs7tGEIHAVoYp64uJlWRnWXoWfKE8Q39cBtnQ8/QCnUGyV+0S3OY+C QR/8Q8cy9p1vVCUJp8Wz5IGg6WP/oTUlrBNFwmCwOkeW9/+ypEeDi9CUBczcM4n+ 5Ew/49jmyaISpy2XPLCdn8rbbSgnR3OHNatVI/Sxq8d+KUhJy4tgUnmKiQ2oB/rD 9z77CV4v1qQ6SzEMQBSjR3bEzAxAIblhDJvTRt1TdxYXprVizN/GjPzYbsMGaeGa x1jJys4+8crqjyPkuzXSbCwg1MYM+FALXyAp+mogb+pOxRj2BZDDfGWHPoL/eEk= =OJBZ -----END PGP SIGNATURE----- --------------enigF38E68AB495573FBA3C5C4CE-- --===============0347598744== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel --===============0347598744==-- From xen-devel-bounces@lists.xensource.com Wed Sep 07 02:36:10 2011 Return-path: Envelope-to: www-data@lists.xensource.com Delivery-date: Wed, 07 Sep 2011 02:36:10 -0700 Received: from localhost ([127.0.0.1] helo=lists.colo.xensource.com) by lists.xensource.com with esmtp (Exim 4.43) id 1R1EYD-0000qu-Su; Wed, 07 Sep 2011 02:36:09 -0700 Received: from mail182.messagelabs.com ([85.158.139.83]) by lists.xensource.com with esmtp (Exim 4.43) id 1R1EXY-0000eC-ND for xen-devel@lists.xensource.com; Wed, 07 Sep 2011 02:35:29 -0700 X-Env-Sender: JBeulich@suse.com X-Msg-Ref: server-7.tower-182.messagelabs.com!1315388125!12357183!1 X-Originating-IP: [130.57.49.28] X-StarScan-Version: 6.3.6; banners=-,-,- X-VirusChecked: Checked Received: (qmail 14364 invoked from network); 7 Sep 2011 09:35:25 -0000 Received: from nat28.tlf.novell.com (HELO nat28.tlf.novell.com) (130.57.49.28) by server-7.tower-182.messagelabs.com with DHE-RSA-AES256-SHA encrypted SMTP; 7 Sep 2011 09:35:25 -0000 Received: from EMEA1-MTA by nat28.tlf.novell.com with Novell_GroupWise; Wed, 07 Sep 2011 10:35:24 +0100 Message-Id: <4E6757110200007800055040@nat28.tlf.novell.com> X-Mailer: Novell GroupWise Internet Agent 8.0.1 Date: Wed, 07 Sep 2011 10:35:45 +0100 From: "Jan Beulich" To: "Joanna Rutkowska" Subject: Re: [Xen-devel] dom0 is stalled until a keypress References: <20110905091937.GA1906@email> <36a5b662-4420-41aa-be01-445f83b15a7b@default 4E664BEE.9000208@invisiblethingslab.com> <71fba00b-9a7a-4029-ac11-4d37732bb53f@default> <4E673351.6060206@invisiblethingslab.com> In-Reply-To: <4E673351.6060206@invisiblethingslab.com> Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: quoted-printable Content-Disposition: inline Cc: Dan Magenheimer , xen-devel@lists.xensource.com, Rafal Wojtczuk X-BeenThere: xen-devel@lists.xensource.com X-Mailman-Version: 2.1.5 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xensource.com Errors-To: xen-devel-bounces@lists.xensource.com >>> On 07.09.11 at 11:03, Joanna Rutkowska = wrote: > On 09/06/11 19:17, Dan Magenheimer wrote: >>> From: Joanna Rutkowska [mailto:joanna@invisiblethingslab.com]=20 >>> Subject: Re: [Xen-devel] dom0 is stalled until a keypress >>> >>> On 09/06/11 17:49, Dan Magenheimer wrote: >>>>> From: Rafal Wojtczuk [mailto:rafal@invisiblethingslab.com]=20 >>>>> Sent: Monday, September 05, 2011 3:20 AM >>>>> To: xen-devel@lists.xensource.com=20 >>>>> Subject: [Xen-devel] dom0 is stalled until a keypress >>>>> >>>>> Hello, >>>>> The following bizarre behaviour was observed on xen4.1+suse dom0 = 2.6.38, on >>>>> an old Core Duo laptop; maybe someone can hint what is wrong. >>>>> Dom0 boot stalls after an init.d script prints "Starting udev". Then = nothing >>>>> seems to happen. I need to press any key to observe progress - I = need to do >>>>> it tens of times for the boot to finish. After X starts fine, then = there is >>>>> no need for keypressing anymore. >>>>> A particularly disturbing fact is that qrexec_daemon parent, that = basically >>>>> does >>>>> for (;;) { sleep(1); fprintf(stderr, "."); } >>>>> does not print dots, until a keypress arrives. So something is very = wrong >>>>> with timers. >>>>> Somehow similarly, pm-suspend sometimes hangs at some stage - after = detaching >>>>> power cord, machine enters S3 immediately. >>>>> This is vaguely similar to the issue described in >>>>> https://lkml.org/lkml/2008/9/14/122=20 >>>>> but this time, "nohz=3Doff" does not help. >>>>> >>>>> "cpufreq=3Ddom0-kernel" cures the symptoms; but it is not a = sideeffectless >>>>> solution. Any idea what is going on or how to debug it ? >>>> >>>> ISTR seeing this on a Core(2?)Duo laptop and I think the >>>> workaround was setting max_cstate=3D0 (as Xen boot parameter). >>>> >>> But what was the actual problem? Setting max_cstate is probably even >>> worse for power management than setting cpufreq=3Ddom-kernel, isn't = it? >>=20 >> Sorry, dunno. I recall looking into it a bit and finding that >> the Core processor (and possibly specifically Merom, the laptop >> version) had some special C-state (C3, C1E maybe?) and giving >> up at that point. Sorry I can't be more helpful. >=20 > But the same system worked fine without any tweaks (cpufreq, max_cstate) > on Xen 3.4 and only started exhibiting this behavior after we switched > to Xen 4.1... 4.1.0 or 4.1.1? Jan _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel From xen-devel-bounces@lists.xensource.com Wed Sep 07 02:45:28 2011 Return-path: Envelope-to: www-data@lists.xensource.com Delivery-date: Wed, 07 Sep 2011 02:45:28 -0700 Received: from localhost ([127.0.0.1] helo=lists.colo.xensource.com) by lists.xensource.com with esmtp (Exim 4.43) id 1R1EhD-0001LW-VA; Wed, 07 Sep 2011 02:45:27 -0700 Received: from mail216.messagelabs.com ([85.158.143.99]) by lists.xensource.com with esmtp (Exim 4.43) id 1R1EgZ-00018i-Eu for xen-devel@lists.xensource.com; Wed, 07 Sep 2011 02:44:47 -0700 X-Env-Sender: keir.xen@gmail.com X-Msg-Ref: server-11.tower-216.messagelabs.com!1315388684!9782312!1 X-Originating-IP: [74.125.82.43] X-StarScan-Version: 6.3.6; banners=-,-,- X-VirusChecked: Checked Received: (qmail 5392 invoked from network); 7 Sep 2011 09:44:44 -0000 Received: from mail-ww0-f43.google.com (HELO mail-ww0-f43.google.com) (74.125.82.43) by server-11.tower-216.messagelabs.com with RC4-SHA encrypted SMTP; 7 Sep 2011 09:44:44 -0000 Received: by wwe32 with SMTP id 32so5913609wwe.24 for ; Wed, 07 Sep 2011 02:44:44 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=sender:user-agent:date:subject:from:to:message-id:thread-topic :thread-index:mime-version:content-type:content-transfer-encoding; bh=f0qMmJUGdWEiRMQwhloo+faDQcqPiqvgqP6908CnJmY=; b=QgAf+c4vD1XlJRapBUaJ6KnSjbS8BB/bRIzw79zbIJV4H+7zUvfB4HY+ZPbKy7lp7f X7o5nChB3GbsIfn6eFPUeGYwjVR3Z7IBVLQA1FGIEyXcVWYGk5OrogMpUb9zn8BGP+fv +nIsHe58TKf5DAaASGpFIBtYSUgwQQ2uGc754= Received: by 10.227.32.130 with SMTP id c2mr2300504wbd.93.1315388684231; Wed, 07 Sep 2011 02:44:44 -0700 (PDT) Received: from [192.168.1.3] (host86-137-116-193.range86-137.btcentralplus.com [86.137.116.193]) by mx.google.com with ESMTPS id ex16sm3033269wbb.4.2011.09.07.02.44.42 (version=SSLv3 cipher=OTHER); Wed, 07 Sep 2011 02:44:43 -0700 (PDT) User-Agent: Microsoft-Entourage/12.30.0.110427 Date: Wed, 07 Sep 2011 10:44:33 +0100 From: Keir Fraser To: Message-ID: Thread-Topic: Second release candidates for Xen 4.0.3 and 4.1.2 Thread-Index: AcxtQr8zCTWui+1WiE2G9st0PjErBQ== Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit Subject: [Xen-devel] Second release candidates for Xen 4.0.3 and 4.1.2 X-BeenThere: xen-devel@lists.xensource.com X-Mailman-Version: 2.1.5 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xensource.com Errors-To: xen-devel-bounces@lists.xensource.com Folks, RC2 is tagged in the 4.0-testing and 4.1-testing repositories: http://xenbits.xen.org/staging/xen-4.0-testing.hg '4.0.3-rc2' http://xenbits.xen.org/staging/xen-4.1-testing.hg '4.1.2-rc2' Please test! Thanks, Keir _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel From xen-devel-bounces@lists.xensource.com Wed Sep 07 02:50:14 2011 Return-path: Envelope-to: www-data@lists.xensource.com Delivery-date: Wed, 07 Sep 2011 02:50:14 -0700 Received: from localhost ([127.0.0.1] helo=lists.colo.xensource.com) by lists.xensource.com with esmtp (Exim 4.43) id 1R1Elq-0001mB-68; Wed, 07 Sep 2011 02:50:14 -0700 Received: from mail174.messagelabs.com ([85.158.138.51]) by lists.xensource.com with smtp (Exim 4.43) id 1R1ElG-0001ZP-8z for xen-devel@lists.xensource.com; Wed, 07 Sep 2011 02:49:38 -0700 X-Env-Sender: davidtecher@yahoo.fr X-Msg-Ref: server-9.tower-174.messagelabs.com!1315388973!24505935!1 X-Originating-IP: [216.139.236.26] X-StarScan-Version: 6.3.6; banners=-,-,- X-VirusChecked: Checked Received: (qmail 29755 invoked from network); 7 Sep 2011 09:49:34 -0000 Received: from sam.nabble.com (HELO sam.nabble.com) (216.139.236.26) by server-9.tower-174.messagelabs.com with SMTP; 7 Sep 2011 09:49:34 -0000 Received: from [192.168.236.26] (helo=sam.nabble.com) by sam.nabble.com with esmtp (Exim 4.72) (envelope-from ) id 1R1Eh5-0006X5-S5 for xen-devel@lists.xensource.com; Wed, 07 Sep 2011 02:45:19 -0700 Date: Wed, 7 Sep 2011 02:45:19 -0700 (PDT) From: David TECHER To: xen-devel@lists.xensource.com Message-ID: <1315388719863-4777943.post@n5.nabble.com> In-Reply-To: <1315382742268-4777689.post@n5.nabble.com> References: <1314720409505-4750600.post@n5.nabble.com> <1314778567400-4753326.post@n5.nabble.com> <20110831083832.GD7276@reaktio.net> <1314780568949-4753422.post@n5.nabble.com> <1314795401771-4754024.post@n5.nabble.com> <20110831151913.GE7276@reaktio.net> <1315231341254-4770602.post@n5.nabble.com> <1315310225039-4774097.post@n5.nabble.com> <1315343879.61837.YahooMailNeo@web29818.mail.ird.yahoo.com> <1315382742268-4777689.post@n5.nabble.com> Subject: Re: Re : [Xen-devel] Re: Patches for VGA-Passthrough XEN 4.2 unstable MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-BeenThere: xen-devel@lists.xensource.com X-Mailman-Version: 2.1.5 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xensource.com Errors-To: xen-devel-bounces@lists.xensource.com Well it is very simple :) I will show your a example You have to replace the required ranges in for the 4 "ranges" 1 --------> pci 0000:08:00.0: reg 10 32bit mmio: [0xf8000000-0xf8ffffff] 2 --------> pci 0000:08:00.0: reg 14 64bit mmio pref: [0xd0000000-0xdfffffff] 3 --------> pci 0000:08:00.0: reg 1c 64bit mmio: [0xf6000000-0xf7ffffff] 4 --------> pci 0000:08:00.0: reg 30 32bit mmio pref: [0xf5f80000-0xf5ffffff] I will do it for the number 1 1) You will have replace the required values in tools/firmware/hvmloader/acpi/dsdt.asl Search for the words "/* reserve MMIO BARs of gfx for 1:1 mapping */" in the file and the first block AFTER need to be change like that Here the reference is "pci 0000:08:00.0: reg 10 32bit mmio: [0xf8000000-0xf8ffffff]" --------------------------------------------------------------------- "/* reserve MMIO BARs of gfx for 1:1 mapping */ DWordMemory( ResourceProducer, PosDecode, MinFixed, MaxFixed, Cacheable, ReadWrite, 0x00000000, 0xF8000000, // the min value in hexadecimal, I modify it here 0xF8FFFFFF, // the max value in hexadecimal I midify it here 0x00000000, ???????????) // value = max - min + 1 in hexadecimal value, I need to find it --------------------------------------------------------------------------- You need to convert the min and the max and do the conversion For hexadecimal/decimal conversions, go to a site like http://www.statman.info/conversions/hexadecimal.html for doing conversion For min and max values, you will have (enter the value without "0x" on the site I told you, feel the field "Convert", click on "to decimal") Hex Dec F8000000 4160749568 F8FFFFFF 4177526783 So 4177526783 - 4160749568 +1 = 16777216 So 16777216 is 1000000 in hexadecimal As a consequence for pci 0000:08:00.0: reg 10 32bit mmio: [0xf8000000-0xf8ffffff] you will have ------------------------------------------------------------------------ "/* reserve MMIO BARs of gfx for 1:1 mapping */ DWordMemory( ResourceProducer, PosDecode, MinFixed, MaxFixed, Cacheable, ReadWrite, 0x00000000, 0xF8000000, // the min value in hexadecimal 0xF8FFFFFF, // the max value in hexadecimal 0x00000000, 0x01000000) // value = max - min + 1 in hexadecimal value ---------------------------------------------------------------------------- Do the same steps for 2 --------> pci 0000:08:00.0: reg 14 64bit mmio pref: [0xd0000000-0xdfffffff] 3 --------> pci 0000:08:00.0: reg 1c 64bit mmio: [0xf6000000-0xf7ffffff] 4 --------> pci 0000:08:00.0: reg 30 32bit mmio pref: [0xf5f80000-0xf5ffffff] That's all! Ensure to put you vgabios-pt.bin in the required place. Compil and install. My graphic card GT 440 works like a charm with nvidia 275.33. I've tried you 280.26 nvidia drivers but without any success. This driver version requires more ressoures. The GPLPV drivers for HVM works well too! -- View this message in context: http://xen.1045712.n5.nabble.com/Patches-for-VGA-Passthrough-XEN-4-2-unstable-tp4406265p4777943.html Sent from the Xen - Dev mailing list archive at Nabble.com. _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel From xen-devel-bounces@lists.xensource.com Wed Sep 07 02:51:19 2011 Return-path: Envelope-to: www-data@lists.xensource.com Delivery-date: Wed, 07 Sep 2011 02:51:19 -0700 Received: from localhost ([127.0.0.1] helo=lists.colo.xensource.com) by lists.xensource.com with esmtp (Exim 4.43) id 1R1Emt-00029k-2r; Wed, 07 Sep 2011 02:51:19 -0700 Received: from mail174.messagelabs.com ([85.158.138.51]) by lists.xensource.com with esmtp (Exim 4.43) id 1R1EmI-0001wJ-7V for xen-devel@lists.xensource.com; Wed, 07 Sep 2011 02:50:43 -0700 X-Env-Sender: JBeulich@suse.com X-Msg-Ref: server-12.tower-174.messagelabs.com!1315389036!30523621!1 X-Originating-IP: [130.57.49.28] X-StarScan-Version: 6.3.6; banners=-,-,- X-VirusChecked: Checked Received: (qmail 413 invoked from network); 7 Sep 2011 09:50:38 -0000 Received: from nat28.tlf.novell.com (HELO nat28.tlf.novell.com) (130.57.49.28) by server-12.tower-174.messagelabs.com with DHE-RSA-AES256-SHA encrypted SMTP; 7 Sep 2011 09:50:38 -0000 Received: from EMEA1-MTA by nat28.tlf.novell.com with Novell_GroupWise; Wed, 07 Sep 2011 10:50:27 +0100 Message-Id: <4E675A980200007800055050@nat28.tlf.novell.com> X-Mailer: Novell GroupWise Internet Agent 8.0.1 Date: Wed, 07 Sep 2011 10:50:48 +0100 From: "Jan Beulich" To: "Konrad Rzeszutek Wilk" Subject: Re: [Xen-devel] blkfront problem in pvops kernel when barriers enabled References: <4E6357C6.6050101@mimuw.edu.pl> <20110906163213.GC5264@dumpdata.com> <4E665572.7080009@mimuw.edu.pl> <20110907014741.GD30639@dumpdata.com> In-Reply-To: <20110907014741.GD30639@dumpdata.com> Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: quoted-printable Content-Disposition: inline Cc: "xen-devel@lists.xensource.com" , Marek Marczykowski X-BeenThere: xen-devel@lists.xensource.com X-Mailman-Version: 2.1.5 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xensource.com Errors-To: xen-devel-bounces@lists.xensource.com >>> On 07.09.11 at 03:47, Konrad Rzeszutek Wilk = wrote: > On Tue, Sep 06, 2011 at 07:16:34PM +0200, Marek Marczykowski wrote: >> On 06.09.2011 18:32, Konrad Rzeszutek Wilk wrote: >> > On Sun, Sep 04, 2011 at 12:49:42PM +0200, Marek Marczykowski wrote: >> >> Hello, >> >> >> >> Pvops block frontend (tested vanilla 3.0.3, 3.1rc2, Konrad's testing >> >> branch) produces a lot of I/O errors when barriers are enabled but >> >> cannot be used. >> >> >> >> On xenlinux I've got message: >> >> [ 15.036921] blkfront: xvdb: empty write barrier op failed >> >> [ 15.036936] blkfront: xvdb: barriers disabled >> >> >> >> and after that, everything works fine. On pvops - I/O errors. >> >> As backend I've used 2.6.38.3 xenlinux (based on SUSE package) and >> >> 3.1rc2 with same result. >> >=20 >> > Hm, and the 'feature-barrier' was enabled on in those backends? >> > That is really bizzare considering that those backends don't actually >> > support WRITE_BARRIER anymore. >>=20 >> At least in 2.6.38.3 xenlinux (SUSE). Now I'm not sure if 3.1rc2 also >> needed this modification (can't find it now). >>=20 >> >> When I disable barriers (patching blkbackend to set feature-barrier= =3D0) >> >> everything works fine with all above versions. >> >=20 >> > Ok, and the patch you sent "[PATCH] Initialize vars in blkfront_connec= t" >> > as well? >>=20 >> Yes. >> I've noticed now that this patch was needed only on your testing branch >> (not vanilla kernel). >=20 > Oooo. Let me check what went wrong. Perhaps the fix is already applied = in > my local tree. >>=20 >> >> My setup is xen-4.1.1 (if it matters), backends: phy from device-mapp= er >> >> device and phy from loop device; frontends covered by device-mapper >> >> snapshot, which is set up in domU initramfs. >> >> >> >> It looks like some race condition, because when I setup device-mapper= in >> >> domU and mount it manually (which cause some delays between steps), = it >> >> works fine... >> >> >> >> Have you idea why it happens? What additional data can I provide = debug it? >> >> >> >> In addition it should be possible to disable barrier without = patching >> >> module... Perhaps some pciback module parameter? Or leave feature-* >> >=20 >> > Not sure why you would touch pciback..=20 >>=20 >> I mean blkback of course. >>=20 >> > But the barrier should _not_ >> > be enabled in those backends. The 'feature-flush-cache' should be. >>=20 >> (on 3.1rc2) Looking to xenstore now there is 'feature-flush-cache=3D1' = and >> no 'feature-barrier'. So it is ok. >=20 > >=20 > I can only think of 2.6.38-3 XenOLinux doing it - and it is a bug > to do it. It really ought to _not_ advertise 'feature-barrier' and > instead advertise 'feature-flush-cache'. Indeed, I see that I added feature-flush-cache support to the frontend back then, but neglected to do so for the backend. Partly perhaps because I'm not much of a (block, network, ...) driver person... However, what I'm not understanding with dropping feature-barrier support from the backend - how do you deal with old frontends wanting to use barriers? I'm currently converting them into WRITE_FLUSH_FUA operations in the backend as a (hopefully) best effort approach. Jan _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel From xen-devel-bounces@lists.xensource.com Wed Sep 07 02:52:56 2011 Return-path: Envelope-to: www-data@lists.xensource.com Delivery-date: Wed, 07 Sep 2011 02:52:56 -0700 Received: from localhost ([127.0.0.1] helo=lists.colo.xensource.com) by lists.xensource.com with esmtp (Exim 4.43) id 1R1EoS-0002XE-5z; Wed, 07 Sep 2011 02:52:56 -0700 Received: from mail21.messagelabs.com ([85.158.143.35]) by lists.xensource.com with smtp (Exim 4.43) id 1R1Enu-0002Kz-1h for xen-devel@lists.xensource.com; Wed, 07 Sep 2011 02:52:22 -0700 X-Env-Sender: davidtecher@yahoo.fr X-Msg-Ref: server-15.tower-21.messagelabs.com!1315389139!49640329!1 X-Originating-IP: [77.238.189.95] X-StarScan-Version: 6.3.6; banners=-,-,- X-VirusChecked: Checked Received: (qmail 26868 invoked from network); 7 Sep 2011 09:52:19 -0000 Received: from nm1-vm0.bullet.mail.ird.yahoo.com (HELO nm1-vm0.bullet.mail.ird.yahoo.com) (77.238.189.95) by server-15.tower-21.messagelabs.com with SMTP; 7 Sep 2011 09:52:19 -0000 Received: from [77.238.189.233] by nm1.bullet.mail.ird.yahoo.com with NNFMP; 07 Sep 2011 09:52:18 -0000 Received: from [212.82.108.239] by tm14.bullet.mail.ird.yahoo.com with NNFMP; 07 Sep 2011 09:52:18 -0000 Received: from [127.0.0.1] by omp1004.mail.ird.yahoo.com with NNFMP; 07 Sep 2011 09:52:18 -0000 X-Yahoo-Newman-Property: ymail-3 X-Yahoo-Newman-Id: 606851.70547.bm@omp1004.mail.ird.yahoo.com Received: (qmail 75467 invoked by uid 60001); 7 Sep 2011 09:52:18 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.fr; s=s1024; t=1315389138; bh=Z7iXrRLYOXXsagrG+2qsKNgqSziTaX631oSnCi8kLjk=; h=X-YMail-OSG:Received:X-Mailer:References:Message-ID:Date:From:Reply-To:Subject:To:In-Reply-To:MIME-Version:Content-Type; b=TLIxR7ND4ZSna2H0TeID5ZQnM6OR2tECUF+55mwkrqtH+fJ96CT2AeSrRRTUAIKAmbIs6MGJeuuKU74gPcy7U9NWA5lNUrBjzinWa8NV+RG8v6psQnnAlWjuycNdHAvpoayMGdlhMugaoGJj6qsjCHQcOMkYJWg3+KR175hrEkQ= DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.fr; h=X-YMail-OSG:Received:X-Mailer:References:Message-ID:Date:From:Reply-To:Subject:To:In-Reply-To:MIME-Version:Content-Type; b=OTHOGTU6D9fB7hAH6LvsEmKr3VrEtMNuTaf4K6gzvroRscNTf8GQOp1q2dmx0qvq18ICxqOPwbi+x3zrFs1LHVdR68cqZ+3r4keZjqmNjlpmgwcOzz8LSO3srN9+YktgWGq6qLK0+ajRzjJPObH1q/AL3BgCj3O3I3qEECqSuUM=; X-YMail-OSG: AkpmEXoVM1mk7iQVpc25nX45OTjVL94pmZIrs3NwXex9aK3 TGBZI0OWgpjxCsEaDpHZsEeB7kQrgRVbXfqrTfgPYgA3dK9m6H_MoENorKbN CaTDRk4Q2a9SAR_HoDbFplPA2cv2JgEs_86uYxLxbXk0nlodefOQyqai_UVs l3VDf_jQ5nXFk2V3dl16S4kZsoAUsaDqn1RcLHEMtUwqWD_cE74RRJY6h_eS r8WxNmdEElrTPrnYLIUBDsLO4ib8kWrusPuDnMNV0WuJFctiL4Dp6WYR0su9 5kQLVylJKCdsHd5MyAmMFYNY_37h4q1Gt8P5ZT0fX6W_A1SKzuxLClBD9.ov OSv5g_UP7I3gc6a.519lEtIdQLuErEAonqQwBCZcHbVkWAdDvZOa0UXsc8Aq wO8u9gk_2Opx7V.qBwLPaYOAdETw.kMpazQ9vw8JJ8TNd__oyH8E_uQM..9m O3gtFo5RChDfQgSkcV1KdOlHy0knf36RAYIcKtUDlc2OtVghNcaqtCCymDW6 LdyNQEluRrNpLR72MtJMjEVX_8Xch26X.IhQlB1Env2zhjy2BIbqsFt_X39v ihHGEkNoLAI34nzJjtjEfYgQKmXs8xUniDbJ9zjkNyzgofKz77B.P3aiirer VqLehMTLralgwjExKuLKT7cPWMrG_9_R3jhKt9FP041Rmiw9biC7X0UTqk6j _MwC5IBAVlanIZxz7Dn4HTpO.Tz3bu7J6h2ouLP6O1gCT70Wta3eyh8pcaBx f3JUobFuqGqMh_Cz5_7ALBk9ppNSQY0kgapFIJbHBsama Received: from [195.167.237.98] by web29801.mail.ird.yahoo.com via HTTP; Wed, 07 Sep 2011 10:52:18 BST X-Mailer: YahooMailWebService/0.8.113.315625 References: <1314716445148-4750357.post@n5.nabble.com> <1314720409505-4750600.post@n5.nabble.com> <1314778567400-4753326.post@n5.nabble.com> <20110831083832.GD7276@reaktio.net> <1314780568949-4753422.post@n5.nabble.com> <1314795401771-4754024.post@n5.nabble.com> <20110831151913.GE7276@reaktio.net> <1315231341254-4770602.post@n5.nabble.com> <1315310225039-4774097.post@n5.nabble.com> <1315343879.61837.YahooMailNeo@web29818.mail.ird.yahoo.com> <1315382742268-4777689.post@n5.nabble.com> Message-ID: <1315389138.56652.YahooMailNeo@web29801.mail.ird.yahoo.com> Date: Wed, 7 Sep 2011 10:52:18 +0100 (BST) From: David TECHER Subject: Re : Re : [Xen-devel] Re: Patches for VGA-Passthrough XEN 4.2 unstable To: komkon555 , "xen-devel@lists.xensource.com" In-Reply-To: <1315382742268-4777689.post@n5.nabble.com> MIME-Version: 1.0 Cc: X-BeenThere: xen-devel@lists.xensource.com X-Mailman-Version: 2.1.5 Precedence: list Reply-To: David TECHER List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0354580696==" Sender: xen-devel-bounces@lists.xensource.com Errors-To: xen-devel-bounces@lists.xensource.com --===============0354580696== Content-Type: multipart/alternative; boundary="0-1276703661-1315389138=:56652" --0-1276703661-1315389138=:56652 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable Well it is very simple :) =0A=0AI will show your a example =0A=0AYou have t= o replace the required ranges in for the 4 "ranges"; So this is the info yo= u've sent to me=0A=0A1 --------> pci 0000:08:00.0: reg 10 32bit mmio: [0xf8= 000000-0xf8ffffff] =0A2 --------> pci 0000:08:00.0: reg 14 64bit mmio pref:= [0xd0000000-0xdfffffff] =0A3 --------> pci 0000:08:00.0: reg 1c 64bit mmio= : [0xf6000000-0xf7ffffff] =0A4 --------> pci 0000:08:00.0: reg 30 32bit mmi= o pref: [0xf5f80000-0xf5ffffff] =0A=0AI will do it for the number 1 =0A=0A1= ) You will have replace the required values in tools/firmware/hvmloader/acp= i/dsdt.asl =0A=A0 =A0 Search for the words =A0"/* reserve MMIO BARs of gfx = for 1:1 mapping */" in the file =0A=A0 =A0 and the first block AFTER =A0nee= d to be =A0 =A0change like that =0A=0A=A0 =A0 =A0 =A0 =A0Here the reference= is =0A=0A=A0 =A0 =A0"pci 0000:08:00.0: reg 10 32bit mmio: [0xf8000000-0xf8= ffffff]" =0A---------------------------------------------------------------= ------ =0A=A0 =A0 =A0 =A0 =A0"/* reserve MMIO BARs of gfx for 1:1 mapping *= / =0A=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0DWordMemory( =0A=A0 =A0 =A0= =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0ResourceProducer, PosDecode, MinFix= ed, MaxFixed, =0A=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0Cacheab= le, ReadWrite, =0A=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 0x0000000= 0, =0A=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 0xF8000000, // the mi= n value in hexadecimal, I modify it here =0A=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0= =A0 =A0 =A0 =A0 0xF8FFFFFF, // the max value in hexadecimal I midify it he= re =0A=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 0x00000000, =0A=A0 = =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 ???????????) // value =3D max -= min + 1 in hexadecimal value, I need to find it =0A-----------------------= ---------------------------------------------------- =0A=0AYou need to conv= ert the min and the max and do the conversion =0A=0AFor hexadecimal/decimal= conversions, =A0go to a site like http://www.statman.info/conversions/hexa= decimal.html=A0for doing conversion =0A=0AFor min and max values, you will = have (enter the value without =0A"0x" on the site I told you, feel the fiel= d "Convert", click on "to =0Adecimal") =0AHex =A0 =A0 =A0 =A0 =A0 =A0Dec = =0AF8000000 =A0 =A04160749568 =0AF8FFFFFF =A0 =A04177526783 =0A=0ASo 417752= 6783 - 4160749568 +1 =3D 16777216 =0ASo 16777216 is 1000000 in hexadecimal = =0A=0AAs a consequence for =0A=0A=A0pci 0000:08:00.0: reg 10 32bit mmio: [0= xf8000000-0xf8ffffff] =0A=0Ayou will have =0A------------------------------= ------------------------------------------ =0A=A0 =A0 "/* reserve MMIO BARs= of gfx for 1:1 mapping */ =0A=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0DW= ordMemory( =0A=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0ResourcePr= oducer, PosDecode, MinFixed, MaxFixed, =0A=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 = =A0 =A0 =A0 =A0 =A0Cacheable, ReadWrite, =0A=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0= =A0 =A0 =A0 =A0 0x00000000, =0A=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0= =A0 0xF8000000, // the min value in hexadecimal =0A=A0 =A0 =A0 =A0 =A0 =A0= =A0 =A0 =A0 =A0 =A0 =A0 0xF8FFFFFF, // the max value in hexadecimal =0A=A0= =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 0x00000000, =0A=A0 =A0 =A0 =A0= =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 0x01000000) // value =3D max - min + 1 in = hexadecimal value =0A------------------------------------------------------= ---------------------- =0A=0ADo the same steps for =0A=0A2 --------> pci 00= 00:08:00.0: reg 14 64bit mmio pref: [0xd0000000-0xdfffffff] =0A3 --------> = pci 0000:08:00.0: reg 1c 64bit mmio: [0xf6000000-0xf7ffffff] =0A4 -------->= pci 0000:08:00.0: reg 30 32bit mmio pref: [0xf5f80000-0xf5ffffff] =0A=0ATh= at's all! =0A=0AEnsure to put you vgabios-pt.bin in the required place. =0A= =0ACompil and install. =0A=0AMy graphic card GT 440 works like a charm with= nvidia 275.33. =0AI've tried you 280.26 nvidia drivers but without any suc= cess. This =0Adriver version requires more ressoures. =0A=0AThe GPLPV drive= rs for HVM works well too! =0A=0A=0A________________________________=0ADe= =A0: komkon555 =0A=C0=A0: xen-devel@lists.xensource.c= om=0AEnvoy=E9 le : Mercredi 7 Septembre 2011 10h05=0AObjet=A0: Re: Re : [Xe= n-devel] Re: Patches for VGA-Passthrough XEN 4.2 unstable=0A=0AHallo. Can y= ou please explain, what is exactly to do with dsd. I don't=0Aunderstand it.= Which entrance are what for? =0AThank you.=0A=0A=0A--=0AView this message = in context: http://xen.1045712.n5.nabble.com/Patches-for-VGA-Passthrough-XE= N-4-2-unstable-tp4406265p4777689.html=0ASent from the Xen - Dev mailing lis= t archive at Nabble.com.=0A=0A_____________________________________________= __=0AXen-devel mailing list=0AXen-devel@lists.xensource.com=0Ahttp://lists.= xensource.com/xen-devel --0-1276703661-1315389138=:56652 Content-Type: text/html; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable
Well it is very = simple :)=0A

I will show your a example =0A

You have to repla= ce the required ranges in for the 4 "ranges"; So this is the info you've se= nt to me

1 --------> pci 0000:08:00.0: reg 10 32bit mmio: [0xf800= 0000-0xf8ffffff]=0A
2 --------> pci 0000:08:00.0: reg 14 64bit mmio p= ref: [0xd0000000-0xdfffffff]=0A
3 --------> pci 0000:08:00.0: reg 1c = 64bit mmio: [0xf6000000-0xf7ffffff]=0A
4 --------> pci 0000:08:00.0: = reg 30 32bit mmio pref: [0xf5f80000-0xf5ffffff] =0A

I will do it for= the number 1=0A

1) You will have replace the required values in too= ls/firmware/hvmloader/acpi/dsdt.asl =0A
    Search for the wor= ds  "/* reserve MMIO BARs of gfx for 1:1 mapping */" in the file=0A    and the first block AFTER  need to be    chan= ge like that =0A

         Here the referenc= e is =0A

     "pci 0000:08:00.0: reg 10 32bit mmio: [= 0xf8000000-0xf8ffffff]"=0A
---------------------------------------------= ------------------------=0A
         "/* reserv= e MMIO BARs of gfx for 1:1 mapping */=0A
        &nb= sp;            DWordMemory(=0A
  &nbs= p;                     &n= bsp;ResourceProducer, PosDecode, MinFixed, MaxFixed,=0A
    &n= bsp;                    C= acheable, ReadWrite,=0A
             =           0x00000000,=0A
      =                   0xF8000000, = // the min value in hexadecimal, I modify it here=0A
     = ;                   0xF8FFFFFF= , // the max value in hexadecimal I midify it here=0A
    &nbs= p;                   0x0000000= 0,=0A
                  &nb= sp;     ???????????) // value =3D max - min + 1 in hexadecimal va= lue, I need to find it=0A
----------------------------------------------= -----------------------------=0A

You need to convert the min and the= max and do the conversion=0A

For hexadecimal/decimal conversions, &= nbsp;go to a site like http://www.statman.info/conve= rsions/hexadecimal.html for doing conversion=0A

For min and= max values, you will have (enter the value without =0A"0x" on the site I t= old you, feel the field "Convert", click on "to =0Adecimal")=0A
Hex &nbs= p;          Dec=0A
F8000000    416074= 9568=0A
F8FFFFFF    4177526783=0A

So 4177526783 - 41607= 49568 +1 =3D 16777216=0A
So 16777216 is 1000000 in hexadecimal=0A
As a consequence for=0A

 pci 0000:08:00.0: reg 10 32bit mmio: = [0xf8000000-0xf8ffffff]=0A

you will have=0A
---------------------= ---------------------------------------------------=0A
    "/*= reserve MMIO BARs of gfx for 1:1 mapping */=0A
      &nb= sp;              DWordMemory(=0A
&nbs= p;                     &n= bsp;  ResourceProducer, PosDecode, MinFixed, MaxFixed,=0A
  &n= bsp;                     =  Cacheable, ReadWrite,=0A
           =             0x00000000,=0A
    =                     0xF80= 00000, // the min value in hexadecimal=0A
        &n= bsp;               0xF8FFFFFF, // the ma= x value in hexadecimal=0A
            &nbs= p;           0x00000000,=0A
     = ;                   0x01000000= ) // value =3D max - min + 1 in hexadecimal value=0A
-------------------= ---------------------------------------------------------=0A

Do the = same steps for =0A

2 --------> pci 0000:08:00.0: reg 14 64bit mmi= o pref: [0xd0000000-0xdfffffff]=0A
3 --------> pci 0000:08:00.0: reg = 1c 64bit mmio: [0xf6000000-0xf7ffffff]=0A
4 --------> pci 0000:08:00.= 0: reg 30 32bit mmio pref: [0xf5f80000-0xf5ffffff] =0A

That's all!= =0A

Ensure to put you vgabios-pt.bin in the required place. =0A
<= br>Compil and install.=0A

My graphic card GT 440 works like a charm = with nvidia 275.33. =0AI've tried you 280.26 nvidia drivers but without any= success. This =0Adriver version requires more ressoures. =0A

The GP= LPV drivers for HVM works well too!=0A

De : komkon555 <komkon555@freenet.de><= br>=C0 : xen-devel@li= sts.xensource.com
Envoy=E9 le : Mercredi 7 Septembre 2011 10h05
Objet : Re: Re : [Xen-devel] Re: Patches for VGA-Pas= sthrough XEN 4.2 unstable

Hallo. Can you please explain, what= is exactly to do with dsd. I don't
understand it. Which entrance are wh= at for?
Thank you.


--
View this message in context: http://xen.1045712.n5.nabble.com/Patches-for-VGA-Passthr= ough-XEN-4-2-unstable-tp4406265p4777689.html
Sent from the Xen - Dev= mailing list archive at Nabble.com.

_______________________________= ________________
Xen-devel mailing list
Xen-de= vel@lists.xensource.com
http://lists.xensource.com/xen-devel


=
--0-1276703661-1315389138=:56652-- --===============0354580696== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel --===============0354580696==-- From xen-devel-bounces@lists.xensource.com Wed Sep 07 02:54:04 2011 Return-path: Envelope-to: www-data@lists.xensource.com Delivery-date: Wed, 07 Sep 2011 02:54:04 -0700 Received: from localhost ([127.0.0.1] helo=lists.colo.xensource.com) by lists.xensource.com with esmtp (Exim 4.43) id 1R1EpY-0002v7-PR; Wed, 07 Sep 2011 02:54:04 -0700 Received: from mail174.messagelabs.com ([85.158.138.51]) by lists.xensource.com with esmtp (Exim 4.43) id 1R1Enu-0002L0-95 for xen-devel@lists.xensource.com; Wed, 07 Sep 2011 02:52:22 -0700 X-Env-Sender: dunlapg@gmail.com X-Msg-Ref: server-11.tower-174.messagelabs.com!1315389137!30532942!1 X-Originating-IP: [74.125.82.43] X-StarScan-Version: 6.3.6; banners=-,-,- X-VirusChecked: Checked Received: (qmail 17145 invoked from network); 7 Sep 2011 09:52:19 -0000 Received: from mail-ww0-f43.google.com (HELO mail-ww0-f43.google.com) (74.125.82.43) by server-11.tower-174.messagelabs.com with RC4-SHA encrypted SMTP; 7 Sep 2011 09:52:19 -0000 Received: by wwe32 with SMTP id 32so5919628wwe.24 for ; Wed, 07 Sep 2011 02:52:17 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=/9KeirI9Q2inOmINNYRn71MVRVq+IIr07YJ9sIdgRSE=; b=s1vPAgDmoMg0vrlziOAv0JqlJfUrMOOtLhcdDFBRbbLYkCjJTz/Av8wcC0IiHaWTtM KqtB7W+38SXPatkAp/hfZqQykZ8dhXFmsJaKcaGLqHExLPInIa6s+HHc59Kzvsnc3wff 5EPvfiIHzDbXrekpLrAenOWobjn76n90gWGDs= MIME-Version: 1.0 Received: by 10.216.158.83 with SMTP id p61mr2218961wek.10.1315389137326; Wed, 07 Sep 2011 02:52:17 -0700 (PDT) Received: by 10.216.202.40 with HTTP; Wed, 7 Sep 2011 02:52:17 -0700 (PDT) In-Reply-To: <987664A83D2D224EAE907B061CE93D5301EA8F9921@orsmsx505.amr.corp.intel.com> References: <987664A83D2D224EAE907B061CE93D5301EA8F9921@orsmsx505.amr.corp.intel.com> Date: Wed, 7 Sep 2011 10:52:17 +0100 X-Google-Sender-Auth: bfWawgxrdxFr388aG94bB_XFWaQ Message-ID: Subject: Re: [Xen-devel] [PATCH] xen, vtd: Fix device check for devices behind PCIe-to-PCI bridges From: George Dunlap To: "Kay, Allen M" Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: "xen-devel@lists.xensource.com" , Jan Beulich X-BeenThere: xen-devel@lists.xensource.com X-Mailman-Version: 2.1.5 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xensource.com Errors-To: xen-devel-bounces@lists.xensource.com On Tue, Sep 6, 2011 at 10:16 PM, Kay, Allen M wrote= : > I'm curious how does this context entry became valid in the first place i= f pdev cannot be found? Apparently the only code that needs the pdev is the part that does the ownership checking. :-) > In general, this patch seems harmless to other situations. =A0It just doe= s the same new and old domain checking for the case where pdev is not found= . Great, thanks. -George > > Allen > > -----Original Message----- > From: xen-devel-bounces@lists.xensource.com [mailto:xen-devel-bounces@lis= ts.xensource.com] On Behalf Of George Dunlap > Sent: Thursday, September 01, 2011 7:20 AM > To: xen-devel@lists.xensource.com > Cc: george.dunlap@eu.citrix.com > Subject: [Xen-devel] [PATCH] xen, vtd: Fix device check for devices behin= d PCIe-to-PCI bridges > > On some systems, requests devices behind a PCIe-to-PCI bridge all > appear to the IOMMU as though they come from from slot 0, function > 0 on that device; so the mapping code much punch a hole for X:0.0 > in the IOMMU for such devices. =A0When punching the hole, if that device > has already been mapped once, we simply need to check ownership to > make sure it's legal. =A0To do so, domain_context_mapping_one() will look > up the device for the mapping with pci_get_pdev() and look for the owner. > > However, if there is no device in X:0.0, this look up will fail. > > Rather than returning -ENODEV in this situation (causing a failure in > mapping the device), try to get the domain ownership from the iommu conte= xt > mapping itself. > > Signed-off-by: George Dunlap > > diff -r 4a4882df5649 -r ede81b0552be xen/drivers/passthrough/vtd/iommu.c > --- a/xen/drivers/passthrough/vtd/iommu.c =A0 =A0 =A0 Wed Aug 31 15:23:49= 2011 +0100 > +++ b/xen/drivers/passthrough/vtd/iommu.c =A0 =A0 =A0 Thu Sep 01 15:18:18= 2011 +0100 > @@ -113,6 +113,27 @@ static int context_set_domain_id(struct > =A0 =A0 return 0; > =A0} > > +static int context_get_domain_id(struct context_entry *context, > + =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 struct = iommu *iommu) > +{ > + =A0 =A0unsigned long dom_index, nr_dom; > + =A0 =A0int domid =3D -1; > + > + =A0 =A0if (iommu && context) > + =A0 =A0{ > + =A0 =A0 =A0 =A0nr_dom =3D cap_ndoms(iommu->cap); > + > + =A0 =A0 =A0 =A0dom_index =3D context_domain_id(*context); > + > + =A0 =A0 =A0 =A0if ( dom_index < nr_dom && iommu->domid_map) > + =A0 =A0 =A0 =A0 =A0 =A0domid =3D iommu->domid_map[dom_index]; > + =A0 =A0 =A0 =A0else > + =A0 =A0 =A0 =A0 =A0 =A0dprintk(XENLOG_DEBUG VTDPREFIX, "%s: dom_index %= lu exceeds nr_dom %lu or iommu has no domid_map\n", > + =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0__func__, dom_index, nr_dom); > + =A0 =A0} > + =A0 =A0return domid; > +} > + > =A0static struct intel_iommu *__init alloc_intel_iommu(void) > =A0{ > =A0 =A0 struct intel_iommu *intel; > @@ -1237,7 +1258,6 @@ int domain_context_mapping_one( > =A0 =A0 struct hvm_iommu *hd =3D domain_hvm_iommu(domain); > =A0 =A0 struct context_entry *context, *context_entries; > =A0 =A0 u64 maddr, pgd_maddr; > - =A0 =A0struct pci_dev *pdev =3D NULL; > =A0 =A0 int agaw; > > =A0 =A0 ASSERT(spin_is_locked(&pcidevs_lock)); > @@ -1249,12 +1269,45 @@ int domain_context_mapping_one( > =A0 =A0 if ( context_present(*context) ) > =A0 =A0 { > =A0 =A0 =A0 =A0 int res =3D 0; > + =A0 =A0 =A0 =A0struct pci_dev *pdev =3D NULL; > > + =A0 =A0 =A0 =A0/* First try to get domain ownership from device structu= re. =A0If that's > + =A0 =A0 =A0 =A0 * not available, try to read it from the context itself= . */ > =A0 =A0 =A0 =A0 pdev =3D pci_get_pdev(bus, devfn); > - =A0 =A0 =A0 =A0if (!pdev) > - =A0 =A0 =A0 =A0 =A0 =A0res =3D -ENODEV; > - =A0 =A0 =A0 =A0else if (pdev->domain !=3D domain) > - =A0 =A0 =A0 =A0 =A0 =A0res =3D -EINVAL; > + =A0 =A0 =A0 =A0if ( pdev ) > + =A0 =A0 =A0 =A0{ > + =A0 =A0 =A0 =A0 =A0 =A0if ( pdev->domain !=3D domain ) > + =A0 =A0 =A0 =A0 =A0 =A0{ > + =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0dprintk(XENLOG_INFO VTDPREFIX, "d%d: bdf= =3D %x:%x.%x owned by d%d!", > + =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0domain->domain_id, > + =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0bus, PCI_SLOT(devfn), PC= I_FUNC(devfn), > + =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0(pdev->domain) > + =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0? pdev->domain->domain_i= d : -1); > + =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0res =3D -EINVAL; > + =A0 =A0 =A0 =A0 =A0 =A0} > + =A0 =A0 =A0 =A0} > + =A0 =A0 =A0 =A0else > + =A0 =A0 =A0 =A0{ > + =A0 =A0 =A0 =A0 =A0 =A0int cdomain; > + =A0 =A0 =A0 =A0 =A0 =A0cdomain =3D context_get_domain_id(context, iommu= ); > + > + =A0 =A0 =A0 =A0 =A0 =A0if ( cdomain < 0 ) > + =A0 =A0 =A0 =A0 =A0 =A0{ > + =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0dprintk(VTDPREFIX, "d%d: bdf =3D %x:%x.%= x mapped, but can't find owner!\n", > + =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0domain->domain_id, > + =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0bus, PCI_SLOT(devfn), PC= I_FUNC(devfn)); > + =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0res =3D -EINVAL; > + =A0 =A0 =A0 =A0 =A0 =A0} > + =A0 =A0 =A0 =A0 =A0 =A0else if ( cdomain !=3D domain->domain_id ) > + =A0 =A0 =A0 =A0 =A0 =A0{ > + =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0dprintk(XENLOG_INFO VTDPREFIX, "d%d: bdf= =3D %x:%x.%x already mapped to d%d!", > + =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0domain->domain_id, > + =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0bus, PCI_SLOT(devfn), PC= I_FUNC(devfn), > + =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0cdomain); > + =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0res =3D -EINVAL; > + =A0 =A0 =A0 =A0 =A0 =A0} > + =A0 =A0 =A0 =A0} > + > =A0 =A0 =A0 =A0 unmap_vtd_domain_page(context_entries); > =A0 =A0 =A0 =A0 spin_unlock(&iommu->lock); > =A0 =A0 =A0 =A0 return res; > > _______________________________________________ > Xen-devel mailing list > Xen-devel@lists.xensource.com > http://lists.xensource.com/xen-devel > > _______________________________________________ > Xen-devel mailing list > Xen-devel@lists.xensource.com > http://lists.xensource.com/xen-devel > _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel From xen-api-bounces@lists.xensource.com Wed Sep 07 03:01:30 2011 Return-path: Envelope-to: www-data@lists.xensource.com Delivery-date: Wed, 07 Sep 2011 03:01:30 -0700 Received: from localhost ([127.0.0.1] helo=lists.colo.xensource.com) by lists.xensource.com with esmtp (Exim 4.43) id 1R1Ewi-0003LY-2H; Wed, 07 Sep 2011 03:01:28 -0700 Received: from mail27.messagelabs.com ([193.109.254.147]) by lists.xensource.com with esmtp (Exim 4.43) id 1R1Eue-0003H5-EI; Wed, 07 Sep 2011 02:59:42 -0700 X-Env-Sender: mike.mcclurg@citrix.com X-Msg-Ref: server-12.tower-27.messagelabs.com!1315389540!41409036!1 X-Originating-IP: [66.165.176.89] X-StarScan-Version: 6.3.6; banners=-,-,- X-VirusChecked: Checked Received: (qmail 30987 invoked from network); 7 Sep 2011 09:59:02 -0000 Received: from smtp.citrix.com (HELO SMTP.CITRIX.COM) (66.165.176.89) by server-12.tower-27.messagelabs.com with RC4-SHA encrypted SMTP; 7 Sep 2011 09:59:02 -0000 X-IronPort-AV: E=Sophos;i="4.68,344,1312171200"; d="scan'208,217";a="16754351" Received: from ftlpmailmx02.citrite.net ([10.13.107.66]) by FTLPIPO01.CITRIX.COM with ESMTP/TLS/RC4-MD5; 07 Sep 2011 05:59:13 -0400 Received: from [10.80.2.141] (10.80.2.141) by FTLPMAILMX02.citrite.net (10.13.107.66) with Microsoft SMTP Server id 8.3.137.0; Wed, 7 Sep 2011 05:59:13 -0400 Message-ID: <4E674070.6010506@citrix.com> Date: Wed, 7 Sep 2011 10:59:12 +0100 From: Mike McClurg User-Agent: Mozilla/5.0 (X11; Linux i686; rv:5.0) Gecko/20110628 Thunderbird/5.0 MIME-Version: 1.0 To: "xen-users@lists.xensource.com" , "xen-api@lists.xensource.com" , "xen-devel@lists.xensource.com" X-Enigmail-Version: 1.2 Cc: Subject: [Xen-API] Job opportunities at Citrix Systems (Cambridge, UK) X-BeenThere: xen-api@lists.xensource.com X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussion of API issues surrounding Xen List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============2055475850==" Sender: xen-api-bounces@lists.xensource.com Errors-To: xen-api-bounces@lists.xensource.com --===============2055475850== Content-Type: multipart/alternative; boundary="------------070203010005030402020607" --------------070203010005030402020607 Content-Type: text/plain; charset="ISO-8859-1" Content-Transfer-Encoding: 7bit Hi folks, I just wanted to let everyone know that Citrix is hiring developers to work on the OCaml-based XenAPI toolstack. We are looking to recruit top-class engineers to work on the toolstack; applicants must have a good knowledge of data structures and algorithms, experience of programming in the context of large systems and general aesthetic good taste when it comes to code and architecture. Our code base is significant and varied: over 130,000 lines of OCaml, solving problems ranging from the low-level (Xen hypercalls) to the high-level (resource pool management), to the compiler-driven (generating language bindings for our Xen datamodel). Our ideal candidate will have: * significant experience of applications programming in high-level functional languages (such as OCaml) * an aptitude for implementing (and reasoning about) complex concurrent, distributed systems * the skills required to contribute to both the architectural design and day-to-day development of a large code-base * strong communication skills and problem solving ability * a determination to deliver great products that perform brilliantly and meet our customers' needs So if you want to tackle interesting and challenging programming problems and contribute to an innovative, fast-growing product that is already used by tens of thousands of customers across the world, please don't hesitate to send me your CV. Thanks, Mike McClurg PS: Please note that you must have UK right to work. Here are the official job postings, but if you apply please CC me your CV. Req #11673 *Software Development Engineer* http://careers.peopleclick.com/careerscp/client_citrix/emea_region/jobDetails.do?functionName=getJobDetail&jobPostId=32491&localeCode=en-us Req #11897 *Senior Software Developer* http://careers.peopleclick.com/careerscp/client_citrix/emea_region/jobDetails.do?functionName=getJobDetail&jobPostId=33053&localeCode=en-us --------------070203010005030402020607 Content-Type: text/html; charset="ISO-8859-1" Content-Transfer-Encoding: 7bit Hi folks,

I just wanted to let everyone know that Citrix is hiring developers to work on the OCaml-based XenAPI toolstack.

We are looking to recruit top-class engineers to work on the toolstack; applicants must have a good knowledge of data structures and algorithms, experience of programming in the context of large systems and general aesthetic good taste when it comes to code and architecture.

Our code base is significant and varied: over 130,000 lines of OCaml, solving problems ranging from the low-level (Xen hypercalls) to the high-level (resource pool management), to the compiler-driven (generating language bindings for our Xen datamodel).

Our ideal candidate will have:

* significant experience of applications programming in high-level functional languages (such as OCaml)
* an aptitude for implementing (and reasoning about) complex concurrent, distributed systems
* the skills required to contribute to both the architectural design and day-to-day development of a large code-base
* strong communication skills and problem solving ability
* a determination to deliver great products that perform brilliantly and meet our customers' needs

So if you want to tackle interesting and challenging programming problems and contribute to an innovative, fast-growing product that is already used by tens of thousands of customers across the world, please don't hesitate to send me your CV.

Thanks,

Mike McClurg

PS: Please note that you must have UK right to work. Here are the official job postings, but if you apply please CC me your CV.

Req #11673 Software Development Engineer http://careers.peopleclick.com/careerscp/client_citrix/emea_region/jobDetails.do?functionName=getJobDetail&jobPostId=32491&localeCode=en-us

Req #11897 Senior Software Developer http://careers.peopleclick.com/careerscp/client_citrix/emea_region/jobDetails.do?functionName=getJobDetail&jobPostId=33053&localeCode=en-us
--------------070203010005030402020607-- --===============2055475850== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ xen-api mailing list xen-api@lists.xensource.com http://lists.xensource.com/mailman/listinfo/xen-api --===============2055475850==-- From xen-devel-bounces@lists.xensource.com Wed Sep 07 03:10:22 2011 Return-path: Envelope-to: www-data@lists.xensource.com Delivery-date: Wed, 07 Sep 2011 03:10:22 -0700 Received: from localhost ([127.0.0.1] helo=lists.colo.xensource.com) by lists.xensource.com with esmtp (Exim 4.43) id 1R1F5K-0004kd-Jz; Wed, 07 Sep 2011 03:10:22 -0700 Received: from mail182.messagelabs.com ([85.158.139.83]) by lists.xensource.com with esmtp (Exim 4.43) id 1R1Ewv-0003N9-70 for xen-devel@lists.xensource.com; Wed, 07 Sep 2011 03:01:47 -0700 X-Env-Sender: JBeulich@suse.com X-Msg-Ref: server-6.tower-182.messagelabs.com!1315389697!17361760!1 X-Originating-IP: [130.57.49.28] X-StarScan-Version: 6.3.6; banners=-,-,- X-VirusChecked: Checked Received: (qmail 11182 invoked from network); 7 Sep 2011 10:01:38 -0000 Received: from nat28.tlf.novell.com (HELO nat28.tlf.novell.com) (130.57.49.28) by server-6.tower-182.messagelabs.com with DHE-RSA-AES256-SHA encrypted SMTP; 7 Sep 2011 10:01:38 -0000 Received: from EMEA1-MTA by nat28.tlf.novell.com with Novell_GroupWise; Wed, 07 Sep 2011 11:01:37 +0100 Message-Id: <4E675D360200007800055073@nat28.tlf.novell.com> X-Mailer: Novell GroupWise Internet Agent 8.0.1 Date: Wed, 07 Sep 2011 11:01:58 +0100 From: "Jan Beulich" To: "Marek Marczykowski" Subject: Re: [Xen-devel] Memory fragmentation and PCI passthrough References: <4E665E53.3@invisiblethingslab.com> In-Reply-To: <4E665E53.3@invisiblethingslab.com> Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: quoted-printable Content-Disposition: inline Cc: "xen-devel@lists.xensource.com" , Rafal Wojtczuk , Joanna Rutkowska X-BeenThere: xen-devel@lists.xensource.com X-Mailman-Version: 2.1.5 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xensource.com Errors-To: xen-devel-bounces@lists.xensource.com >>> On 06.09.11 at 19:54, Marek Marczykowski wrote: > In tmem documentation is also described some workaround for this: > reserve some memory region for allocations with 0 tries to allocate 64MB, which much bigger than 2MB... Is it really > needed to allocate such big region of contiguous memory in one piece? For one, you can tweak the size (you shouldn't normally need 64Mb in a DomU, and even in Dom0 that's mostly needed for certain SCSI devices iirc). Second, the allocation isn't done in a single 64M contiguous chunk (from hypervisor perspective) - xen_create_contiguous_region() is being called on much smaller pieces (IO_TLB_SEGSIZE << IO_TLB_SHIFT, i.e. 128 << 11, yielding 256k chunks). Jan _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel From xen-devel-bounces@lists.xensource.com Wed Sep 07 03:19:57 2011 Return-path: Envelope-to: www-data@lists.xensource.com Delivery-date: Wed, 07 Sep 2011 03:19:57 -0700 Received: from localhost ([127.0.0.1] helo=lists.colo.xensource.com) by lists.xensource.com with esmtp (Exim 4.43) id 1R1FEb-00060q-Ld; Wed, 07 Sep 2011 03:19:57 -0700 Received: from mail216.messagelabs.com ([85.158.143.99]) by lists.xensource.com with esmtp (Exim 4.43) id 1R1FEB-0005oq-2p for xen-devel@lists.xensource.com; Wed, 07 Sep 2011 03:19:31 -0700 X-Env-Sender: JBeulich@suse.com X-Msg-Ref: server-15.tower-216.messagelabs.com!1315390767!16952520!1 X-Originating-IP: [130.57.49.28] X-StarScan-Version: 6.3.6; banners=-,-,- X-VirusChecked: Checked Received: (qmail 1380 invoked from network); 7 Sep 2011 10:19:27 -0000 Received: from nat28.tlf.novell.com (HELO nat28.tlf.novell.com) (130.57.49.28) by server-15.tower-216.messagelabs.com with DHE-RSA-AES256-SHA encrypted SMTP; 7 Sep 2011 10:19:27 -0000 Received: from EMEA1-MTA by nat28.tlf.novell.com with Novell_GroupWise; Wed, 07 Sep 2011 11:19:26 +0100 Message-Id: <4E6761630200007800055087@nat28.tlf.novell.com> X-Mailer: Novell GroupWise Internet Agent 8.0.1 Date: Wed, 07 Sep 2011 11:19:47 +0100 From: "Jan Beulich" To: "Konrad Rzeszutek Wilk" Subject: Re: [Xen-devel] blkfront problem in pvops kernel when barriers enabled References: <4E6357C6.6050101@mimuw.edu.pl> <20110906163213.GC5264@dumpdata.com> <4E665572.7080009@mimuw.edu.pl> <20110907014741.GD30639@dumpdata.com> <4E675A980200007800055050@nat28.tlf.novell.com> In-Reply-To: <4E675A980200007800055050@nat28.tlf.novell.com> Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: quoted-printable Content-Disposition: inline Cc: "xen-devel@lists.xensource.com" , Marek Marczykowski X-BeenThere: xen-devel@lists.xensource.com X-Mailman-Version: 2.1.5 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xensource.com Errors-To: xen-devel-bounces@lists.xensource.com >>> On 07.09.11 at 11:50, "Jan Beulich" wrote: >>>> On 07.09.11 at 03:47, Konrad Rzeszutek Wilk = wrote: >> On Tue, Sep 06, 2011 at 07:16:34PM +0200, Marek Marczykowski wrote: >>> On 06.09.2011 18:32, Konrad Rzeszutek Wilk wrote: >>> > On Sun, Sep 04, 2011 at 12:49:42PM +0200, Marek Marczykowski wrote: >>> >> Hello, >>> >> >>> >> Pvops block frontend (tested vanilla 3.0.3, 3.1rc2, Konrad's = testing >>> >> branch) produces a lot of I/O errors when barriers are enabled but >>> >> cannot be used. >>> >> >>> >> On xenlinux I've got message: >>> >> [ 15.036921] blkfront: xvdb: empty write barrier op failed >>> >> [ 15.036936] blkfront: xvdb: barriers disabled >>> >> >>> >> and after that, everything works fine. On pvops - I/O errors. >>> >> As backend I've used 2.6.38.3 xenlinux (based on SUSE package) and >>> >> 3.1rc2 with same result. >>> >=20 >>> > Hm, and the 'feature-barrier' was enabled on in those backends? >>> > That is really bizzare considering that those backends don't = actually >>> > support WRITE_BARRIER anymore. >>>=20 >>> At least in 2.6.38.3 xenlinux (SUSE). Now I'm not sure if 3.1rc2 also >>> needed this modification (can't find it now). >>>=20 >>> >> When I disable barriers (patching blkbackend to set feature-barrier= =3D0) >>> >> everything works fine with all above versions. >>> >=20 >>> > Ok, and the patch you sent "[PATCH] Initialize vars in blkfront_conne= ct" >>> > as well? >>>=20 >>> Yes. >>> I've noticed now that this patch was needed only on your testing = branch >>> (not vanilla kernel). >>=20 >> Oooo. Let me check what went wrong. Perhaps the fix is already applied = in >> my local tree. >>>=20 >>> >> My setup is xen-4.1.1 (if it matters), backends: phy from device-map= per >>> >> device and phy from loop device; frontends covered by device-mapper >>> >> snapshot, which is set up in domU initramfs. >>> >> >>> >> It looks like some race condition, because when I setup device-mappe= r in >>> >> domU and mount it manually (which cause some delays between steps), = it >>> >> works fine... >>> >> >>> >> Have you idea why it happens? What additional data can I provide = debug it? >>> >> >>> >> In addition it should be possible to disable barrier without = patching >>> >> module... Perhaps some pciback module parameter? Or leave feature-* >>> >=20 >>> > Not sure why you would touch pciback..=20 >>>=20 >>> I mean blkback of course. >>>=20 >>> > But the barrier should _not_ >>> > be enabled in those backends. The 'feature-flush-cache' should be. >>>=20 >>> (on 3.1rc2) Looking to xenstore now there is 'feature-flush-cache=3D1' = and >>> no 'feature-barrier'. So it is ok. >>=20 >> >>=20 >> I can only think of 2.6.38-3 XenOLinux doing it - and it is a bug >> to do it. It really ought to _not_ advertise 'feature-barrier' and >> instead advertise 'feature-flush-cache'. >=20 > Indeed, I see that I added feature-flush-cache support to the frontend > back then, but neglected to do so for the backend. Partly perhaps > because I'm not much of a (block, network, ...) driver person... >=20 > However, what I'm not understanding with dropping feature-barrier > support from the backend - how do you deal with old frontends > wanting to use barriers? I'm currently converting them into > WRITE_FLUSH_FUA operations in the backend as a (hopefully) best > effort approach. Also I notice you're using WRITE_ODIRECT - what's the background of that? Thanks, Jan _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel From xen-devel-bounces@lists.xensource.com Wed Sep 07 03:41:50 2011 Return-path: Envelope-to: www-data@lists.xensource.com Delivery-date: Wed, 07 Sep 2011 03:41:50 -0700 Received: from localhost ([127.0.0.1] helo=lists.colo.xensource.com) by lists.xensource.com with esmtp (Exim 4.43) id 1R1FZm-0007gp-Q4; Wed, 07 Sep 2011 03:41:50 -0700 Received: from mail27.messagelabs.com ([193.109.254.147]) by lists.xensource.com with smtp (Exim 4.43) id 1R1FZN-0007Ul-IR for xen-devel@lists.xensource.com; Wed, 07 Sep 2011 03:41:25 -0700 X-Env-Sender: Stefano.Stabellini@eu.citrix.com X-Msg-Ref: server-2.tower-27.messagelabs.com!1315392060!53942584!1 X-Originating-IP: [62.200.22.115] X-StarScan-Version: 6.3.6; banners=-,-,- X-VirusChecked: Checked Received: (qmail 10654 invoked from network); 7 Sep 2011 10:41:00 -0000 Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115) by server-2.tower-27.messagelabs.com with SMTP; 7 Sep 2011 10:41:00 -0000 X-IronPort-AV: E=Sophos;i="4.68,344,1312156800"; d="scan'208";a="7647409" Received: from lonpmailmx01.citrite.net ([10.30.203.162]) by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5; 07 Sep 2011 10:41:22 +0000 Received: from kaball.uk.xensource.com (10.80.2.59) by LONPMAILMX01.citrite.net (10.30.203.162) with Microsoft SMTP Server id 8.3.137.0; Wed, 7 Sep 2011 11:41:22 +0100 Date: Wed, 7 Sep 2011 11:49:29 +0100 From: Stefano Stabellini X-X-Sender: sstabellini@kaball-desktop To: Benjamin Schweikert Subject: Re: [Xen-devel] Problems with xen 4.1.x + passthrough + pvonhvm In-Reply-To: <4E65F794.6060705@gmail.com> Message-ID: References: <4E65F794.6060705@gmail.com> User-Agent: Alpine 2.00 (DEB 1167 2008-08-23) MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Cc: "xen-devel@lists.xensource.com" X-BeenThere: xen-devel@lists.xensource.com X-Mailman-Version: 2.1.5 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xensource.com Errors-To: xen-devel-bounces@lists.xensource.com On Tue, 6 Sep 2011, Benjamin Schweikert wrote: > Hi, > I have a Gigabyte 890FXA-UD5 Mainboard with Debian Squeeze (with Debians > Xen Kernel-2.6.32) and xen 4.0.2 running. I am able to use PV Domains > with passthrough and HVM Domains (Kernel 2.6.38 with pvonhvm) with pci > and vga passthroug without any problems. > > If I upgrade xen to 4.1.x I can still use my pv domains with pci > passthrough. I can also use a Win 7 HVM domain with pci passthrough. But > if I want to use a Ubuntu Natty HVM domain with pci and vga passthrough > I am running into some errors. Remember, this setup was running with xen > 4.0.2. > I attached some log files for every case I tested. > > Things that work with the Ubuntu Natty HVM wit Xen 4.1.x: > - Without passthroughing anything, everything is working > - Using a Kernel older than 2.6.36 everything is wirking incl. pci and > vga passthrough > > Things I tried without success: > - Kernel 2.6.38 and 3.0.4 with pvonhvm > - xen_platform_pci=0 > - hda instead of xvda in the config file > > I hope somebody got a good idea how to fix this problem. There are some known issues with pv on hvm and xen 4.1.1, they should be fixed in 4.1.2 (not out yet). The patches you are looking for are: http://marc.info/?l=xen-devel&m=131478605912076 http://marc.info/?l=xen-devel&m=131478611612127 if you clone the xen-4.1-testing tree (http://xenbits.xen.org/hg/xen-4.1-testing.hg) they should be there. _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel From xen-devel-bounces@lists.xensource.com Wed Sep 07 03:42:35 2011 Return-path: Envelope-to: www-data@lists.xensource.com Delivery-date: Wed, 07 Sep 2011 03:42:35 -0700 Received: from localhost ([127.0.0.1] helo=lists.colo.xensource.com) by lists.xensource.com with esmtp (Exim 4.43) id 1R1FaV-00083k-Ax; Wed, 07 Sep 2011 03:42:35 -0700 Received: from mail27.messagelabs.com ([193.109.254.147]) by lists.xensource.com with esmtp (Exim 4.43) id 1R1FZP-0007Um-NJ for xen-devel@lists.xensource.com; Wed, 07 Sep 2011 03:41:28 -0700 X-Env-Sender: david.vrabel@citrix.com X-Msg-Ref: server-13.tower-27.messagelabs.com!1315392072!39016129!1 X-Originating-IP: [66.165.176.89] X-StarScan-Version: 6.3.6; banners=-,-,- X-VirusChecked: Checked Received: (qmail 23506 invoked from network); 7 Sep 2011 10:41:14 -0000 Received: from smtp.citrix.com (HELO SMTP.CITRIX.COM) (66.165.176.89) by server-13.tower-27.messagelabs.com with RC4-SHA encrypted SMTP; 7 Sep 2011 10:41:14 -0000 X-IronPort-AV: E=Sophos;i="4.68,344,1312171200"; d="scan'208";a="16754907" Received: from ftlpmailmx02.citrite.net ([10.13.107.66]) by FTLPIPO01.CITRIX.COM with ESMTP/TLS/RC4-MD5; 07 Sep 2011 06:41:23 -0400 Received: from [10.80.2.76] (10.80.2.76) by FTLPMAILMX02.citrite.net (10.13.107.66) with Microsoft SMTP Server id 8.3.137.0; Wed, 7 Sep 2011 06:41:23 -0400 Message-ID: <4E674B14.4090306@citrix.com> Date: Wed, 7 Sep 2011 11:44:36 +0100 From: David Vrabel User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.1.16) Gecko/20110818 Icedove/3.0.11 MIME-Version: 1.0 To: Konrad Rzeszutek Wilk References: <1313765840-22084-1-git-send-email-david.vrabel@citrix.com> <1313765840-22084-4-git-send-email-david.vrabel@citrix.com> <20110906215706.GC24860@dumpdata.com> In-Reply-To: <20110906215706.GC24860@dumpdata.com> Content-Type: text/plain; charset="ISO-8859-1" Content-Transfer-Encoding: 7bit Cc: "xen-devel@lists.xensource.com" Subject: [Xen-devel] Re: [PATCH 3/5] xen: allow balloon driver to use more than one memory region X-BeenThere: xen-devel@lists.xensource.com X-Mailman-Version: 2.1.5 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xensource.com Errors-To: xen-devel-bounces@lists.xensource.com On 06/09/11 22:57, Konrad Rzeszutek Wilk wrote: > On Fri, Aug 19, 2011 at 03:57:18PM +0100, David Vrabel wrote: >> >> +static void __init balloon_add_memory_region(unsigned long start_pfn, unsigned long pages) > > That looks suspiciously like it has more than 80 lines. You ran the > _all_ of the patches through scripts/checkpath.pl right? Yes, I used checkpatch.pl but I tend to treat the 80 character limit as a guideline rather than a hard limit and only pay attention to it if breaking a line improves readability. I assume your preference is for an 80 character hard limit? >> { >> - domid_t domid = DOMID_SELF; >> unsigned long pfn, extra_pfn_end; >> struct page *page; >> + >> + /* >> + * Initialise the balloon with excess memory space. We need >> + * to make sure we don't add memory which doesn't exist or >> + * logically exist. The E820 map can be trimmed to be smaller >> + * than the amount of physical memory due to the mem= command >> + * line parameter. And if this is a 32-bit non-HIGHMEM kernel >> + * on a system with memory which requires highmem to access, >> + * don't try to use it. > > > That whole comment is just confusing.. But I do know that you > just moved it, but I wonder if it makes sense to remove it or > alter it in the future. I think the comment is valid. >> + */ >> + extra_pfn_end = min(min(max_pfn, e820_end_of_ram_pfn()), >> + start_pfn + pages); It's this line that it's documenting. >> --- a/include/xen/page.h >> +++ b/include/xen/page.h >> @@ -3,6 +3,13 @@ >> >> #include >> >> -extern phys_addr_t xen_extra_mem_start, xen_extra_mem_size; >> +struct xen_memory_region { >> + phys_addr_t start; >> + phys_addr_t size; >> +}; >> + >> +#define XEN_EXTRA_MEM_MAX_REGIONS 128 /* == E820MAX */ >> + >> +extern struct xen_memory_region xen_extra_mem[XEN_EXTRA_MEM_MAX_REGIONS]; > > __initdata Only the definition (in arch/x86/xen/setup.c) needs the __initdata attribute, right? I just checked and it does end up in the .init.data section. David _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel From xen-devel-bounces@lists.xensource.com Wed Sep 07 04:03:45 2011 Return-path: Envelope-to: www-data@lists.xensource.com Delivery-date: Wed, 07 Sep 2011 04:03:45 -0700 Received: from localhost ([127.0.0.1] helo=lists.colo.xensource.com) by lists.xensource.com with esmtp (Exim 4.43) id 1R1Fuz-0000Qs-2z; Wed, 07 Sep 2011 04:03:45 -0700 Received: from mail182.messagelabs.com ([85.158.139.83]) by lists.xensource.com with esmtp (Exim 4.43) id 1R1Fri-00009l-9D for xen-devel@lists.xensource.com; Wed, 07 Sep 2011 04:00:59 -0700 X-Env-Sender: david.vrabel@citrix.com X-Msg-Ref: server-14.tower-182.messagelabs.com!1315393217!17219745!1 X-Originating-IP: [66.165.176.89] X-StarScan-Version: 6.3.6; banners=-,-,- X-VirusChecked: Checked Received: (qmail 27432 invoked from network); 7 Sep 2011 11:00:19 -0000 Received: from smtp.citrix.com (HELO SMTP.CITRIX.COM) (66.165.176.89) by server-14.tower-182.messagelabs.com with RC4-SHA encrypted SMTP; 7 Sep 2011 11:00:19 -0000 X-IronPort-AV: E=Sophos;i="4.68,344,1312171200"; d="scan'208";a="16755182" Received: from ftlpmailmx02.citrite.net ([10.13.107.66]) by FTLPIPO01.CITRIX.COM with ESMTP/TLS/RC4-MD5; 07 Sep 2011 07:00:17 -0400 Received: from [10.80.2.76] (10.80.2.76) by FTLPMAILMX02.citrite.net (10.13.107.66) with Microsoft SMTP Server id 8.3.137.0; Wed, 7 Sep 2011 07:00:17 -0400 Message-ID: <4E674F82.40507@citrix.com> Date: Wed, 7 Sep 2011 12:03:30 +0100 From: David Vrabel User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.1.16) Gecko/20110818 Icedove/3.0.11 MIME-Version: 1.0 To: Konrad Rzeszutek Wilk References: <1313765840-22084-1-git-send-email-david.vrabel@citrix.com> <1313765840-22084-6-git-send-email-david.vrabel@citrix.com> <20110906212046.GA24860@dumpdata.com> In-Reply-To: <20110906212046.GA24860@dumpdata.com> Content-Type: text/plain; charset="ISO-8859-1" Content-Transfer-Encoding: 7bit Cc: Vrabel , "xen-devel@lists.xensource.com" , David Subject: [Xen-devel] Re: [PATCH 5/5] xen: release all pages within 1-1 p2m mappings X-BeenThere: xen-devel@lists.xensource.com X-Mailman-Version: 2.1.5 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xensource.com Errors-To: xen-devel-bounces@lists.xensource.com On 06/09/11 22:20, Konrad Rzeszutek Wilk wrote: > On Fri, Aug 19, 2011 at 03:57:20PM +0100, David Vrabel wrote: >> >> --- a/arch/x86/xen/setup.c >> +++ b/arch/x86/xen/setup.c >> @@ -123,73 +123,33 @@ static unsigned long __init xen_release_chunk(phys_addr_t start_addr, >> return len; >> } >> >> -static unsigned long __init xen_return_unused_memory(unsigned long max_pfn, >> - const struct e820entry *map, >> - int nr_map) >> +static unsigned long __init xen_set_identity_and_release(const struct e820entry *list, >> + ssize_t map_size, >> + unsigned long nr_pages) >> { >> - phys_addr_t max_addr = PFN_PHYS(max_pfn); >> - phys_addr_t last_end = ISA_END_ADDRESS; >> + phys_addr_t avail_end = PFN_PHYS(nr_pages); >> + phys_addr_t last_end = 0; >> unsigned long released = 0; >> - int i; >> - >> - /* Free any unused memory above the low 1Mbyte. */ >> - for (i = 0; i < nr_map && last_end < max_addr; i++) { >> - phys_addr_t end = map[i].addr; >> - end = min(max_addr, end); >> - >> - if (last_end < end) >> - released += xen_release_chunk(last_end, end); >> - last_end = max(last_end, map[i].addr + map[i].size); >> - } >> - >> - if (last_end < max_addr) >> - released += xen_release_chunk(last_end, max_addr); >> - >> - printk(KERN_INFO "released %lu pages of unused memory\n", released); >> - return released; >> -} >> - >> -static unsigned long __init xen_set_identity(const struct e820entry *list, >> - ssize_t map_size) >> -{ >> - phys_addr_t last = xen_initial_domain() ? 0 : ISA_END_ADDRESS; >> - phys_addr_t start_pci = last; >> const struct e820entry *entry; >> - unsigned long identity = 0; >> int i; >> >> for (i = 0, entry = list; i < map_size; i++, entry++) { >> - phys_addr_t start = entry->addr; >> - phys_addr_t end = start + entry->size; >> - >> - if (start < last) >> - start = last; >> + phys_addr_t begin = last_end; > > The "begin" is a bit confusing. You are using the previous E820 entry's end - not > the beginning of this E820 entry. Doing a s/begin/last_end/ makes > the code a bit easier to understand. Really? It seems pretty clear to me that they're the beginning and end of the memory range we're considering to release or map. That loop went through a number of variations and what's there is what I think is the most readable. >> + phys_addr_t end = entry->addr + entry->size; >> >> - if (end <= start) >> - continue; >> + last_end = end; > > Please include the comment: > /* This entry end. */ Not really in favour of little comments like this. I'll put a comment above the loop. /* * For each memory region consider whether to release and map the * region and the preceeding gap (if any). */ > OK, but you have ripped out the nice printk's that existed before. So add them > back in: > > > printk(KERN_INFO "released %lu pages of unused memory\n", released); > printk(KERN_INFO "Set %ld page(s) to 1-1 mapping.\n", identity); > > as they are quite useful in the field. What problem are these useful for diagnosing that the remaining messages (and the e820 map) don't tell you already? xen_release_chunk: looking at area pfn 9e-100: 98 pages freed 1-1 mapping on 9e->100 1-1 mapping on bf699->bf6af 1-1 mapping on bf6af->bf6ce 1-1 mapping on bf6ce->c0000 1-1 mapping on c0000->f0000 1-1 mapping on f0000->100000 The total count just doesn't seem useful. David _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel From xen-devel-bounces@lists.xensource.com Wed Sep 07 04:17:07 2011 Return-path: Envelope-to: www-data@lists.xensource.com Delivery-date: Wed, 07 Sep 2011 04:17:07 -0700 Received: from localhost ([127.0.0.1] helo=lists.colo.xensource.com) by lists.xensource.com with esmtp (Exim 4.43) id 1R1G7u-0001l2-3c; Wed, 07 Sep 2011 04:17:06 -0700 Received: from mail182.messagelabs.com ([85.158.139.83]) by lists.xensource.com with esmtp (Exim 4.43) id 1R1G71-0001YO-3J for xen-devel@lists.xensource.com; Wed, 07 Sep 2011 04:16:11 -0700 X-Env-Sender: Wei.Wang2@amd.com X-Msg-Ref: server-4.tower-182.messagelabs.com!1315394167!17389054!1 X-Originating-IP: [213.199.154.144] X-StarScan-Version: 6.3.6; banners=-,-,- X-VirusChecked: Checked Received: (qmail 20379 invoked from network); 7 Sep 2011 11:16:08 -0000 Received: from db3ehsobe006.messaging.microsoft.com (HELO DB3EHSOBE006.bigfish.com) (213.199.154.144) by server-4.tower-182.messagelabs.com with AES128-SHA encrypted SMTP; 7 Sep 2011 11:16:08 -0000 Received: from mail89-db3-R.bigfish.com (10.3.81.242) by DB3EHSOBE006.bigfish.com (10.3.84.26) with Microsoft SMTP Server id 14.1.225.22; Wed, 7 Sep 2011 11:16:07 +0000 Received: from mail89-db3 (localhost.localdomain [127.0.0.1]) by mail89-db3-R.bigfish.com (Postfix) with ESMTP id 8D1483E00F2; Wed, 7 Sep 2011 11:16:07 +0000 (UTC) X-SpamScore: -8 X-BigFish: VPS-8(zz1432N98dKzz1202hzzz32i668h839h61h) X-Spam-TCS-SCL: 0:0 X-Forefront-Antispam-Report: CIP:163.181.249.109; KIP:(null); UIP:(null); IPVD:NLI; H:ausb3twp02.amd.com; RD:none; EFVD:NLI Received: from mail89-db3 (localhost.localdomain [127.0.0.1]) by mail89-db3 (MessageSwitch) id 1315394125413888_19746; Wed, 7 Sep 2011 11:15:25 +0000 (UTC) Received: from DB3EHSMHS014.bigfish.com (unknown [10.3.81.253]) by mail89-db3.bigfish.com (Postfix) with ESMTP id 8CEF3B9814B; Wed, 7 Sep 2011 11:15:20 +0000 (UTC) Received: from ausb3twp02.amd.com (163.181.249.109) by DB3EHSMHS014.bigfish.com (10.3.87.114) with Microsoft SMTP Server id 14.1.225.22; Wed, 7 Sep 2011 11:15:15 +0000 X-WSS-ID: 0LR5GLB-02-2CG-02 X-M-MSG: Received: from sausexedgep01.amd.com (sausexedgep01-ext.amd.com [163.181.249.72]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by ausb3twp02.amd.com (Axway MailGate 3.8.1) with ESMTP id 2BFB7C80D4; Wed, 7 Sep 2011 06:15:10 -0500 (CDT) Received: from sausexhtp01.amd.com (163.181.3.165) by sausexedgep01.amd.com (163.181.36.54) with Microsoft SMTP Server (TLS) id 8.3.106.1; Wed, 7 Sep 2011 06:16:12 -0500 Received: from storexhtp02.amd.com (172.24.4.4) by sausexhtp01.amd.com (163.181.3.165) with Microsoft SMTP Server (TLS) id 8.3.83.0; Wed, 7 Sep 2011 06:15:13 -0500 Received: from gwo.osrc.amd.com (165.204.16.204) by storexhtp02.amd.com (172.24.4.4) with Microsoft SMTP Server id 8.3.83.0; Wed, 7 Sep 2011 07:15:12 -0400 Received: from mail.osrc.amd.com (silizium.osrc.amd.com [165.204.15.142]) by gwo.osrc.amd.com (Postfix) with ESMTP id D502749C1FF; Wed, 7 Sep 2011 12:15:11 +0100 (BST) Received: from gran.osrc.amd.com (gran.osrc.amd.com [165.204.15.57]) by mail.osrc.amd.com (Postfix) with ESMTP id BA3275940FF; Wed, 7 Sep 2011 13:15:11 +0200 (CEST) From: Wei Wang2 To: George Dunlap Date: Wed, 7 Sep 2011 13:18:33 +0200 User-Agent: KMail/1.9.6 (enterprise 20070904.708012) References: In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-ID: <201109071318.34239.wei.wang2@amd.com> X-OriginatorOrg: amd.com Cc: "xen-devel@lists.xensource.com" Subject: [Xen-devel] Re: AMD IOMMU intremap tables and IOAPICs X-BeenThere: xen-devel@lists.xensource.com X-Mailman-Version: 2.1.5 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xensource.com Errors-To: xen-devel-bounces@lists.xensource.com On Tuesday 06 September 2011 17:47:59 George Dunlap wrote: > Wei, > > Quick question: Am I reading the code correctly, that even with > per-device interrupt remap tables, that GSIs are accounted to the > intremap table of the corresponding IOAPIC, presumably because the > IOMMU sees interrupts generated as GSIs as coming from the IOAPIC? In > that case, then we need all devices sharing the same IOAPIC must not > have any vector collisions. Is that correct? > > -George That is true. All legacy devices have to send interrupts to IOMMU via IOAPIC. So even we use per-device table. All devices attached to the same IOAPIC will use the same interrupt table. There should be no vector collisions. Per-device table only makes sense for MSI devices or systems with multiple IOAPICs. Thanks Wei _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel From xen-devel-bounces@lists.xensource.com Wed Sep 07 04:34:32 2011 Return-path: Envelope-to: www-data@lists.xensource.com Delivery-date: Wed, 07 Sep 2011 04:34:32 -0700 Received: from localhost ([127.0.0.1] helo=lists.colo.xensource.com) by lists.xensource.com with esmtp (Exim 4.43) id 1R1GOl-0003Bo-Vz; Wed, 07 Sep 2011 04:34:32 -0700 Received: from mail21.messagelabs.com ([85.158.143.35]) by lists.xensource.com with esmtp (Exim 4.43) id 1R1GNw-0002zB-WA for xen-devel@lists.xensource.com; Wed, 07 Sep 2011 04:33:41 -0700 X-Env-Sender: xen4wr@gmail.com X-Msg-Ref: server-7.tower-21.messagelabs.com!1315395188!53931064!1 X-Originating-IP: [209.85.213.43] X-StarScan-Version: 6.3.6; banners=-,-,- X-VirusChecked: Checked Received: (qmail 23364 invoked from network); 7 Sep 2011 11:33:09 -0000 Received: from mail-yw0-f43.google.com (HELO mail-yw0-f43.google.com) (209.85.213.43) by server-7.tower-21.messagelabs.com with RC4-SHA encrypted SMTP; 7 Sep 2011 11:33:09 -0000 Received: by ywm3 with SMTP id 3so118012ywm.30 for ; Wed, 07 Sep 2011 04:33:36 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:date:message-id:subject:from:to:content-type; bh=quqn5qerppZay3GySdrzsr1NTjTGmYyL9qk1NPl4nW4=; b=UiXflyEn2Stf1BHYvbJemYSMcp4WLOUpej2VLcrhbkQo4F+N56tG7yD9tvTDJnFTLE XEEJIgERhWW7KYqNnMrj243ZYZeYiK7Gnw1jRDmcvZNg6AQC7OD/kTPOSpWI/U5N4U4J xebnvF9CzLwzNOk0TFrmLtO6PfWsl/hcAgTSU= MIME-Version: 1.0 Received: by 10.68.35.5 with SMTP id d5mr12302272pbj.484.1315395216182; Wed, 07 Sep 2011 04:33:36 -0700 (PDT) Received: by 10.68.50.230 with HTTP; Wed, 7 Sep 2011 04:33:36 -0700 (PDT) Date: Wed, 7 Sep 2011 19:33:36 +0800 Message-ID: From: Johnny R To: xen-devel@lists.xensource.com Subject: [Xen-devel] can someone shed some light on saving vcpu X-BeenThere: xen-devel@lists.xensource.com X-Mailman-Version: 2.1.5 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0078766020==" Sender: xen-devel-bounces@lists.xensource.com Errors-To: xen-devel-bounces@lists.xensource.com --===============0078766020== Content-Type: multipart/alternative; boundary=bcaec520f40b998e2104ac585037 --bcaec520f40b998e2104ac585037 Content-Type: text/plain; charset=ISO-8859-1 when execute xm save,which function does save the domain's status and the vcpu's status? --bcaec520f40b998e2104ac585037 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable when execute xm save,which function does=A0save the domain's status and= the vcpu's status? --bcaec520f40b998e2104ac585037-- --===============0078766020== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel --===============0078766020==-- From xen-devel-bounces@lists.xensource.com Wed Sep 07 04:56:03 2011 Return-path: Envelope-to: www-data@lists.xensource.com Delivery-date: Wed, 07 Sep 2011 04:56:03 -0700 Received: from localhost ([127.0.0.1] helo=lists.colo.xensource.com) by lists.xensource.com with esmtp (Exim 4.43) id 1R1Gjb-0004kb-LU; Wed, 07 Sep 2011 04:56:03 -0700 Received: from mail216.messagelabs.com ([85.158.143.99]) by lists.xensource.com with smtp (Exim 4.43) id 1R1Gia-0004X8-Ps for xen-devel@lists.xensource.com; Wed, 07 Sep 2011 04:55:01 -0700 X-Env-Sender: Ian.Jackson@eu.citrix.com X-Msg-Ref: server-15.tower-216.messagelabs.com!1315396454!16966189!1 X-Originating-IP: [62.200.22.115] X-StarScan-Version: 6.3.6; banners=-,-,- X-VirusChecked: Checked Received: (qmail 22540 invoked from network); 7 Sep 2011 11:54:14 -0000 Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115) by server-15.tower-216.messagelabs.com with SMTP; 7 Sep 2011 11:54:14 -0000 X-IronPort-AV: E=Sophos;i="4.68,344,1312156800"; d="scan'208";a="7649502" Received: from lonpmailmx01.citrite.net ([10.30.203.162]) by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5; 07 Sep 2011 11:54:11 +0000 Received: from woking.xci-test.com (10.80.248.135) by smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id 8.3.137.0; Wed, 7 Sep 2011 12:54:11 +0100 Received: from osstest by woking.xci-test.com with local (Exim 4.69) (envelope-from ) id 1R1Ghn-0001KW-9o; Wed, 07 Sep 2011 12:54:11 +0100 To: Message-ID: From: xen.org Date: Wed, 7 Sep 2011 12:54:11 +0100 MIME-Version: 1.0 Content-Type: text/plain Cc: ian.jackson@eu.citrix.com Subject: [Xen-devel] [xen-4.1-testing test] 8835: regressions - FAIL X-BeenThere: xen-devel@lists.xensource.com X-Mailman-Version: 2.1.5 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xensource.com Errors-To: xen-devel-bounces@lists.xensource.com flight 8835 xen-4.1-testing real [real] http://www.chiark.greenend.org.uk/~xensrcts/logs/8835/ Regressions :-( Tests which did not succeed and are blocking: build-i386-pvops 4 kernel-build fail REGR. vs. 8808 build-amd64-pvops 4 kernel-build fail REGR. vs. 8808 Tests which did not succeed, but are not blocking, including regressions (tests previously passed) regarded as allowable: test-amd64-amd64-xl-pcipt-intel 1 xen-build-check(1) blocked n/a test-amd64-amd64-pv 1 xen-build-check(1) blocked n/a test-amd64-i386-rhel6hvm-intel 1 xen-build-check(1) blocked n/a test-i386-i386-pv 1 xen-build-check(1) blocked n/a test-amd64-i386-pv 1 xen-build-check(1) blocked n/a test-amd64-i386-xl-credit2 1 xen-build-check(1) blocked n/a test-i386-i386-xl 1 xen-build-check(1) blocked n/a test-amd64-amd64-xl 1 xen-build-check(1) blocked n/a test-amd64-i386-xl-multivcpu 1 xen-build-check(1) blocked n/a test-amd64-i386-xl 1 xen-build-check(1) blocked n/a test-amd64-i386-rhel6hvm-amd 1 xen-build-check(1) blocked n/a test-amd64-amd64-pair 1 xen-build-check(1) blocked n/a test-i386-i386-pair 1 xen-build-check(1) blocked n/a test-amd64-i386-pair 1 xen-build-check(1) blocked n/a test-amd64-amd64-xl-sedf 1 xen-build-check(1) blocked n/a test-amd64-i386-win-vcpus1 1 xen-build-check(1) blocked n/a test-amd64-i386-xl-win-vcpus1 1 xen-build-check(1) blocked n/a test-amd64-i386-win 1 xen-build-check(1) blocked n/a test-amd64-amd64-win 1 xen-build-check(1) blocked n/a test-amd64-amd64-xl-win 1 xen-build-check(1) blocked n/a test-i386-i386-win 1 xen-build-check(1) blocked n/a test-i386-i386-xl-win 1 xen-build-check(1) blocked n/a version targeted for testing: xen 2376070f6685 baseline version: xen 6239209bb560 ------------------------------------------------------------ People who touched revisions under test: Jan Beulich Stefano Stabellini ------------------------------------------------------------ jobs: build-amd64 pass build-i386 pass build-amd64-oldkern pass build-i386-oldkern pass build-amd64-pvops fail build-i386-pvops fail test-amd64-amd64-xl blocked test-amd64-i386-xl blocked test-i386-i386-xl blocked test-amd64-i386-rhel6hvm-amd blocked test-amd64-i386-xl-credit2 blocked test-amd64-amd64-xl-pcipt-intel blocked test-amd64-i386-rhel6hvm-intel blocked test-amd64-i386-xl-multivcpu blocked test-amd64-amd64-pair blocked test-amd64-i386-pair blocked test-i386-i386-pair blocked test-amd64-amd64-pv blocked test-amd64-i386-pv blocked test-i386-i386-pv blocked test-amd64-amd64-xl-sedf blocked test-amd64-i386-win-vcpus1 blocked test-amd64-i386-xl-win-vcpus1 blocked test-amd64-amd64-win blocked test-amd64-i386-win blocked test-i386-i386-win blocked test-amd64-amd64-xl-win blocked test-i386-i386-xl-win blocked ------------------------------------------------------------ sg-report-flight on woking.cam.xci-test.com logs: /home/xc_osstest/logs images: /home/xc_osstest/images Logs, config files, etc. are available at http://www.chiark.greenend.org.uk/~xensrcts/logs Test harness code can be found at http://xenbits.xensource.com/gitweb?p=osstest.git;a=summary Not pushing. ------------------------------------------------------------ changeset: 23151:2376070f6685 tag: tip user: Keir Fraser date: Wed Sep 07 10:41:01 2011 +0100 Added signature for changeset 3e6a3bf83935 changeset: 23150:be0040eb0a36 user: Keir Fraser date: Wed Sep 07 10:40:51 2011 +0100 Added tag 4.1.2-rc2 for changeset 3e6a3bf83935 changeset: 23149:3e6a3bf83935 tag: 4.1.2-rc2 user: Keir Fraser date: Wed Sep 07 10:40:42 2011 +0100 Update Xen version to 4.1.2-rc2 changeset: 23148:c4172ba1a98b user: Jan Beulich date: Wed Sep 07 10:39:59 2011 +0100 bitmap_scnlistprintf() should always zero-terminate its output buffer ... as long as it has non-zero size. So far this would not happen if the passed in CPU mask was empty. Also fix the comment describing the return value to actually match reality. Signed-off-by: Jan Beulich xen-unstable changeset: 23820:ba75234a6f56 xen-unstable date: Wed Sep 07 10:36:55 2011 +0100 changeset: 23147:6239209bb560 user: Stefano Stabellini date: Wed Aug 31 15:32:47 2011 +0100 xen: __hvm_pci_intx_assert should check for gsis remapped onto pirqs If the isa irq corresponding to a particular gsi is disabled while the gsi is enabled, __hvm_pci_intx_assert will always inject the gsi through the violapic, even if the gsi has been remapped onto a pirq. This patch makes sure that even in this case we inject the notification appropriately. Signed-off-by: Stefano Stabellini xen-unstable changeset: 23807:2297b90a6a7b xen-unstable date: Wed Aug 31 15:23:34 2011 +0100 (qemu changes not included) _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel From xen-devel-bounces@lists.xensource.com Wed Sep 07 04:57:33 2011 Return-path: Envelope-to: www-data@lists.xensource.com Delivery-date: Wed, 07 Sep 2011 04:57:33 -0700 Received: from localhost ([127.0.0.1] helo=lists.colo.xensource.com) by lists.xensource.com with esmtp (Exim 4.43) id 1R1Gl3-0005A1-0r; Wed, 07 Sep 2011 04:57:33 -0700 Received: from mail21.messagelabs.com ([85.158.143.35]) by lists.xensource.com with smtp (Exim 4.43) id 1R1GkI-0004v0-OW for xen-devel@lists.xensource.com; Wed, 07 Sep 2011 04:56:47 -0700 X-Env-Sender: Ian.Jackson@eu.citrix.com X-Msg-Ref: server-8.tower-21.messagelabs.com!1315396589!58054799!1 X-Originating-IP: [62.200.22.115] X-StarScan-Version: 6.3.6; banners=-,-,- X-VirusChecked: Checked Received: (qmail 21809 invoked from network); 7 Sep 2011 11:56:29 -0000 Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115) by server-8.tower-21.messagelabs.com with SMTP; 7 Sep 2011 11:56:29 -0000 X-IronPort-AV: E=Sophos;i="4.68,344,1312156800"; d="scan'208";a="7649583" Received: from lonpmailmx01.citrite.net ([10.30.203.162]) by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5; 07 Sep 2011 11:56:42 +0000 Received: from woking.xci-test.com (10.80.248.135) by smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id 8.3.137.0; Wed, 7 Sep 2011 12:56:42 +0100 Received: from osstest by woking.xci-test.com with local (Exim 4.69) (envelope-from ) id 1R1GkE-0000rq-Kb; Wed, 07 Sep 2011 12:56:42 +0100 To: Message-ID: From: xen.org Date: Wed, 7 Sep 2011 12:56:42 +0100 MIME-Version: 1.0 Content-Type: text/plain Cc: ian.jackson@eu.citrix.com Subject: [Xen-devel] [xen-unstable test] 8836: regressions - FAIL X-BeenThere: xen-devel@lists.xensource.com X-Mailman-Version: 2.1.5 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xensource.com Errors-To: xen-devel-bounces@lists.xensource.com flight 8836 xen-unstable real [real] http://www.chiark.greenend.org.uk/~xensrcts/logs/8836/ Regressions :-( Tests which did not succeed and are blocking: build-amd64-pvops 4 kernel-build fail REGR. vs. 8833 build-i386-pvops 4 kernel-build fail REGR. vs. 8833 Tests which did not succeed, but are not blocking, including regressions (tests previously passed) regarded as allowable: test-amd64-amd64-xl-pcipt-intel 1 xen-build-check(1) blocked n/a test-amd64-i386-pv 1 xen-build-check(1) blocked n/a test-amd64-i386-rhel6hvm-intel 1 xen-build-check(1) blocked n/a test-i386-i386-pv 1 xen-build-check(1) blocked n/a test-amd64-amd64-pv 1 xen-build-check(1) blocked n/a test-i386-i386-xl 1 xen-build-check(1) blocked n/a test-amd64-i386-xl 1 xen-build-check(1) blocked n/a test-amd64-i386-xl-credit2 1 xen-build-check(1) blocked n/a test-amd64-i386-pair 1 xen-build-check(1) blocked n/a test-i386-i386-pair 1 xen-build-check(1) blocked n/a test-amd64-i386-xl-multivcpu 1 xen-build-check(1) blocked n/a test-amd64-amd64-xl-sedf 1 xen-build-check(1) blocked n/a test-amd64-i386-win-vcpus1 1 xen-build-check(1) blocked n/a test-amd64-i386-xl-win-vcpus1 1 xen-build-check(1) blocked n/a test-amd64-i386-rhel6hvm-amd 1 xen-build-check(1) blocked n/a test-amd64-amd64-win 1 xen-build-check(1) blocked n/a test-amd64-i386-win 1 xen-build-check(1) blocked n/a test-amd64-amd64-xl-win 1 xen-build-check(1) blocked n/a test-amd64-amd64-xl 1 xen-build-check(1) blocked n/a test-i386-i386-xl-win 1 xen-build-check(1) blocked n/a test-i386-i386-win 1 xen-build-check(1) blocked n/a test-amd64-amd64-pair 1 xen-build-check(1) blocked n/a version targeted for testing: xen bdd19847ae63 baseline version: xen 5fe770c8a8a3 ------------------------------------------------------------ People who touched revisions under test: Ian Jackson Jan Beulich Keir Fraser Olaf Hering ------------------------------------------------------------ jobs: build-amd64 pass build-i386 pass build-amd64-oldkern pass build-i386-oldkern pass build-amd64-pvops fail build-i386-pvops fail test-amd64-amd64-xl blocked test-amd64-i386-xl blocked test-i386-i386-xl blocked test-amd64-i386-rhel6hvm-amd blocked test-amd64-i386-xl-credit2 blocked test-amd64-amd64-xl-pcipt-intel blocked test-amd64-i386-rhel6hvm-intel blocked test-amd64-i386-xl-multivcpu blocked test-amd64-amd64-pair blocked test-amd64-i386-pair blocked test-i386-i386-pair blocked test-amd64-amd64-pv blocked test-amd64-i386-pv blocked test-i386-i386-pv blocked test-amd64-amd64-xl-sedf blocked test-amd64-i386-win-vcpus1 blocked test-amd64-i386-xl-win-vcpus1 blocked test-amd64-amd64-win blocked test-amd64-i386-win blocked test-i386-i386-win blocked test-amd64-amd64-xl-win blocked test-i386-i386-xl-win blocked ------------------------------------------------------------ sg-report-flight on woking.cam.xci-test.com logs: /home/xc_osstest/logs images: /home/xc_osstest/images Logs, config files, etc. are available at http://www.chiark.greenend.org.uk/~xensrcts/logs Test harness code can be found at http://xenbits.xensource.com/gitweb?p=osstest.git;a=summary Not pushing. ------------------------------------------------------------ changeset: 23822:bdd19847ae63 tag: tip user: Olaf Hering date: Wed Sep 07 10:37:48 2011 +0100 p2m-ept: remove map_domain_page check map_domain_page() can not fail, remove ASSERT in ept_set_entry(). Signed-off-by: Olaf Hering changeset: 23821:88065fb8d0aa user: Jan Beulich date: Wed Sep 07 10:37:20 2011 +0100 x86: remove unnecessary indirection from irq_complete_move()'s sole parameter Signed-off-by: Jan Beulich changeset: 23820:ba75234a6f56 user: Jan Beulich date: Wed Sep 07 10:36:55 2011 +0100 bitmap_scnlistprintf() should always zero-terminate its output buffer ... as long as it has non-zero size. So far this would not happen if the passed in CPU mask was empty. Also fix the comment describing the return value to actually match reality. Signed-off-by: Jan Beulich changeset: 23819:5fe770c8a8a3 user: Keir Fraser date: Tue Sep 06 15:49:40 2011 +0100 docs: Fix 'make docs' Signed-off-by: Keir Fraser ======================================== commit cd776ee9408ff127f934a707c1a339ee600bc127 Author: Ian Jackson Date: Tue Jun 28 13:50:53 2011 +0100 qemu-char.c: fix incorrect CONFIG_STUBDOM handling qemu-char.c:1123:7: warning: "CONFIG_STUBDOM" is not defined [-Wundef] Signed-off-by: Olaf Hering Acked-by: Ian Jackson _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel From xen-devel-bounces@lists.xensource.com Wed Sep 07 05:07:04 2011 Return-path: Envelope-to: www-data@lists.xensource.com Delivery-date: Wed, 07 Sep 2011 05:07:04 -0700 Received: from localhost ([127.0.0.1] helo=lists.colo.xensource.com) by lists.xensource.com with esmtp (Exim 4.43) id 1R1GuG-0005kC-Ii; Wed, 07 Sep 2011 05:07:04 -0700 Received: from mail182.messagelabs.com ([85.158.139.83]) by lists.xensource.com with smtp (Exim 4.43) id 1R1GrX-0005Vf-H9 for xen-devel@lists.xensource.com; Wed, 07 Sep 2011 05:04:30 -0700 X-Env-Sender: Ian.Jackson@eu.citrix.com X-Msg-Ref: server-7.tower-182.messagelabs.com!1315397051!12384261!1 X-Originating-IP: [62.200.22.115] X-StarScan-Version: 6.3.6; banners=-,-,- X-VirusChecked: Checked Received: (qmail 1033 invoked from network); 7 Sep 2011 12:04:11 -0000 Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115) by server-7.tower-182.messagelabs.com with SMTP; 7 Sep 2011 12:04:11 -0000 X-IronPort-AV: E=Sophos;i="4.68,345,1312156800"; d="scan'208";a="7649795" Received: from lonpmailmx01.citrite.net ([10.30.203.162]) by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5; 07 Sep 2011 12:04:11 +0000 Received: from woking.xci-test.com (10.80.248.135) by smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id 8.3.137.0; Wed, 7 Sep 2011 13:04:11 +0100 Received: from osstest by woking.xci-test.com with local (Exim 4.69) (envelope-from ) id 1R1GrT-0000e0-A1; Wed, 07 Sep 2011 13:04:11 +0100 To: xen-devel@lists.xensource.com Message-ID: From: xen.org Date: Wed, 7 Sep 2011 13:04:11 +0100 MIME-Version: 1.0 Content-Type: text/plain Cc: ian.jackson@eu.citrix.com Subject: [Xen-devel] [xen-4.0-testing test] 8834: regressions - FAIL X-BeenThere: xen-devel@lists.xensource.com X-Mailman-Version: 2.1.5 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xensource.com Errors-To: xen-devel-bounces@lists.xensource.com flight 8834 xen-4.0-testing real [real] http://www.chiark.greenend.org.uk/~xensrcts/logs/8834/ Regressions :-( Tests which did not succeed and are blocking: build-i386-pvops 4 kernel-build fail REGR. vs. 8801 build-amd64-pvops 4 kernel-build fail REGR. vs. 8801 Tests which did not succeed, but are not blocking, including regressions (tests previously passed) regarded as allowable: test-amd64-amd64-xl-pcipt-intel 1 xen-build-check(1) blocked n/a test-i386-i386-xl 1 xen-build-check(1) blocked n/a test-amd64-i386-xl-multivcpu 1 xen-build-check(1) blocked n/a test-amd64-i386-pv 1 xen-build-check(1) blocked n/a test-i386-i386-pv 1 xen-build-check(1) blocked n/a test-amd64-amd64-pv 1 xen-build-check(1) blocked n/a test-amd64-amd64-xl 1 xen-build-check(1) blocked n/a test-amd64-i386-xl 1 xen-build-check(1) blocked n/a test-amd64-i386-xl-credit2 1 xen-build-check(1) blocked n/a test-amd64-amd64-xl-sedf 1 xen-build-check(1) blocked n/a test-amd64-amd64-pair 1 xen-build-check(1) blocked n/a test-i386-i386-pair 1 xen-build-check(1) blocked n/a test-amd64-i386-pair 1 xen-build-check(1) blocked n/a test-amd64-i386-rhel6hvm-intel 1 xen-build-check(1) blocked n/a test-amd64-i386-rhel6hvm-amd 1 xen-build-check(1) blocked n/a test-amd64-i386-win-vcpus1 1 xen-build-check(1) blocked n/a test-amd64-i386-win 1 xen-build-check(1) blocked n/a test-amd64-amd64-win 1 xen-build-check(1) blocked n/a test-i386-i386-win 1 xen-build-check(1) blocked n/a test-amd64-amd64-xl-win 1 xen-build-check(1) blocked n/a test-i386-i386-xl-win 1 xen-build-check(1) blocked n/a test-amd64-i386-xl-win-vcpus1 1 xen-build-check(1) blocked n/a version targeted for testing: xen b44346a6975c baseline version: xen 0383662ea34c ------------------------------------------------------------ People who touched revisions under test: Andrew Cooper ------------------------------------------------------------ jobs: build-amd64 pass build-i386 pass build-amd64-oldkern pass build-i386-oldkern pass build-amd64-pvops fail build-i386-pvops fail test-amd64-amd64-xl blocked test-amd64-i386-xl blocked test-i386-i386-xl blocked test-amd64-i386-rhel6hvm-amd blocked test-amd64-i386-xl-credit2 blocked test-amd64-amd64-xl-pcipt-intel blocked test-amd64-i386-rhel6hvm-intel blocked test-amd64-i386-xl-multivcpu blocked test-amd64-amd64-pair blocked test-amd64-i386-pair blocked test-i386-i386-pair blocked test-amd64-amd64-pv blocked test-amd64-i386-pv blocked test-i386-i386-pv blocked test-amd64-amd64-xl-sedf blocked test-amd64-i386-win-vcpus1 blocked test-amd64-i386-xl-win-vcpus1 blocked test-amd64-amd64-win blocked test-amd64-i386-win blocked test-i386-i386-win blocked test-amd64-amd64-xl-win blocked test-i386-i386-xl-win blocked ------------------------------------------------------------ sg-report-flight on woking.cam.xci-test.com logs: /home/xc_osstest/logs images: /home/xc_osstest/images Logs, config files, etc. are available at http://www.chiark.greenend.org.uk/~xensrcts/logs Test harness code can be found at http://xenbits.xensource.com/gitweb?p=osstest.git;a=summary Not pushing. ------------------------------------------------------------ changeset: 21533:b44346a6975c tag: tip user: Keir Fraser date: Wed Sep 07 10:41:49 2011 +0100 Added signature for changeset 8d012bc20d30 changeset: 21532:b7b51fd533d3 user: Keir Fraser date: Wed Sep 07 10:41:41 2011 +0100 Added tag 4.0.3-rc2 for changeset 8d012bc20d30 changeset: 21531:8d012bc20d30 tag: 4.0.3-rc2 user: Keir Fraser date: Wed Sep 07 10:41:35 2011 +0100 Update Xen version to 4.0.3-rc2 changeset: 21530:0383662ea34c user: Andrew Cooper date: Wed Aug 31 15:37:57 2011 +0100 IRQ: manually EOI migrating line interrupts When migrating IO-APIC line level interrupts between PCPUs, the migration code rewrites the IO-APIC entry to point to the new CPU/Vector before EOI'ing it. The EOI process says that EOI'ing the Local APIC will cause a broadcast with the vector number, which the IO-APIC must listen to to clear the IRR and Status bits. In the case of migrating, the IO-APIC has already been reprogrammed so the EOI broadcast with the old vector fails to match the new vector, leaving the IO-APIC with an outstanding vector, preventing any more use of that line interrupt. This causes a lockup especially when your root device is using PCI INTA (megaraid_sas driver *ehem*) However, the problem is mostly hidden because send_cleanup_vector() causes a cleanup of all moving vectors on the current PCPU in such a way which does not cause the problem, and if the problem has occured, the writes it makes to the IO-APIC clears the IRR and Status bits which unlocks the problem. This fix is distinctly a temporary hack, waiting on a cleanup of the irq code. It checks for the edge case where we have moved the irq, and manually EOI's the old vector with the IO-APIC which correctly clears the IRR and Status bits. Also, it protects the code which updates irq_cfg by disabling interrupts. Signed-off-by: Andrew Cooper xen-unstable changeset: 23805:7048810180de xen-unstable date: Wed Aug 31 15:19:24 2011 +0100 (qemu changes not included) _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel From xen-devel-bounces@lists.xensource.com Wed Sep 07 05:16:28 2011 Return-path: Envelope-to: www-data@lists.xensource.com Delivery-date: Wed, 07 Sep 2011 05:16:28 -0700 Received: from localhost ([127.0.0.1] helo=lists.colo.xensource.com) by lists.xensource.com with esmtp (Exim 4.43) id 1R1H3M-0006FY-QZ; Wed, 07 Sep 2011 05:16:28 -0700 Received: from mail216.messagelabs.com ([85.158.143.99]) by lists.xensource.com with esmtp (Exim 4.43) id 1R1H2d-00062Z-Fj for xen-devel@lists.xensource.com; Wed, 07 Sep 2011 05:15:44 -0700 X-Env-Sender: olaf@aepfle.de X-Msg-Ref: server-7.tower-216.messagelabs.com!1315397739!17389719!1 X-Originating-IP: [81.169.146.162] X-StarScan-Version: 6.3.6; banners=-,-,- X-VirusChecked: Checked Received: (qmail 14889 invoked from network); 7 Sep 2011 12:15:40 -0000 Received: from mo-p00-ob.rzone.de (HELO mo-p00-ob.rzone.de) (81.169.146.162) by server-7.tower-216.messagelabs.com with EDH-RSA-DES-CBC3-SHA encrypted SMTP; 7 Sep 2011 12:15:40 -0000 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; t=1315397739; l=12264; s=domk; d=aepfle.de; h=To:From:Date:References:In-Reply-To:Subject: Content-Transfer-Encoding:MIME-Version:Content-Type:X-RZG-CLASS-ID: X-RZG-AUTH; bh=0LzsNQN5PMphWGf0bBuhALSDXpI=; b=rlf9VcZcFCNQz8HKBCqPigH6MzReWdIMHkcbUeFUCqPHCIMpUcgVaOQw26kzXIy1dYJ fP/LuiVzhQPQfW3qTEcTrg1HSRecJv/eLEgmK/JvOmFIc4BCF2MmYRT79ruNr0gKBHW7o E9KPRPq8PqGBaHw+6kzNFSa+x02k5RPxC+o= X-RZG-AUTH: :P2EQZWCpfu+qG7CngxMFH1J+zrwiavkK6tmQaLfmwtM48/lq287pEZIt X-RZG-CLASS-ID: mo00 Received: from probook.site (dslb-084-057-072-233.pools.arcor-ip.net [84.57.72.233]) by smtp.strato.de (klopstock mo13) (RZmta 26.6) with (EDH-RSA-DES-CBC3-SHA encrypted) ESMTPA id y0721cn87BMHxe for ; Wed, 7 Sep 2011 14:15:37 +0200 (MEST) Received: from probook.site (localhost [IPv6:::1]) by probook.site (Postfix) with ESMTP id 0923F18B65 for ; Wed, 7 Sep 2011 14:15:37 +0200 (CEST) Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Mercurial-Node: 4e7bcc14b76a8e37bc8e2fe490ef6b3209bd8738 Message-Id: <4e7bcc14b76a8e37bc8e.1315397729@probook.site> In-Reply-To: References: User-Agent: Mercurial-patchbomb/1.7.5 Date: Wed, 07 Sep 2011 14:15:29 +0200 From: Olaf Hering To: xen-devel@lists.xensource.com Subject: [Xen-devel] [PATCH 1 of 2] mem_event: pass mem_event_domain pointer to mem_event functions X-BeenThere: xen-devel@lists.xensource.com X-Mailman-Version: 2.1.5 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xensource.com Errors-To: xen-devel-bounces@lists.xensource.com # HG changeset patch # User Olaf Hering # Date 1315389343 -7200 # Node ID 4e7bcc14b76a8e37bc8e2fe490ef6b3209bd8738 # Parent 0268e73809532a4a3ca18a075efcee3c62caf458 mem_event: pass mem_event_domain pointer to mem_event functions Pass a struct mem_event_domain pointer to the various mem_event functions. This will be used in a subsequent patch which creates different ring buffers for the memshare, xenpaging and memaccess functionality. Remove the struct domain argument from some functions. Signed-off-by: Olaf Hering diff -r 0268e7380953 -r 4e7bcc14b76a xen/arch/x86/hvm/hvm.c --- a/xen/arch/x86/hvm/hvm.c +++ b/xen/arch/x86/hvm/hvm.c @@ -4025,7 +4025,7 @@ static int hvm_memory_event_traps(long p if ( (p & HVMPME_onchangeonly) && (value == old) ) return 1; - rc = mem_event_check_ring(d); + rc = mem_event_check_ring(&d->mem_event, d->domain_id); if ( rc ) return rc; @@ -4048,7 +4048,7 @@ static int hvm_memory_event_traps(long p req.gla_valid = 1; } - mem_event_put_request(d, &req); + mem_event_put_request(d, &d->mem_event, &req); return 1; } diff -r 0268e7380953 -r 4e7bcc14b76a xen/arch/x86/mm/mem_event.c --- a/xen/arch/x86/mm/mem_event.c +++ b/xen/arch/x86/mm/mem_event.c @@ -33,21 +33,21 @@ #define xen_rmb() rmb() #define xen_wmb() wmb() -#define mem_event_ring_lock_init(_d) spin_lock_init(&(_d)->mem_event.ring_lock) -#define mem_event_ring_lock(_d) spin_lock(&(_d)->mem_event.ring_lock) -#define mem_event_ring_unlock(_d) spin_unlock(&(_d)->mem_event.ring_lock) +#define mem_event_ring_lock_init(_med) spin_lock_init(&(_med)->ring_lock) +#define mem_event_ring_lock(_med) spin_lock(&(_med)->ring_lock) +#define mem_event_ring_unlock(_med) spin_unlock(&(_med)->ring_lock) -static int mem_event_enable(struct domain *d, mfn_t ring_mfn, mfn_t shared_mfn) +static int mem_event_enable(struct domain *d, struct mem_event_domain *med, mfn_t ring_mfn, mfn_t shared_mfn) { int rc; /* Map ring and shared pages */ - d->mem_event.ring_page = map_domain_page(mfn_x(ring_mfn)); - if ( d->mem_event.ring_page == NULL ) + med->ring_page = map_domain_page(mfn_x(ring_mfn)); + if ( med->ring_page == NULL ) goto err; - d->mem_event.shared_page = map_domain_page(mfn_x(shared_mfn)); - if ( d->mem_event.shared_page == NULL ) + med->shared_page = map_domain_page(mfn_x(shared_mfn)); + if ( med->shared_page == NULL ) goto err_ring; /* Allocate event channel */ @@ -56,15 +56,15 @@ static int mem_event_enable(struct domai if ( rc < 0 ) goto err_shared; - ((mem_event_shared_page_t *)d->mem_event.shared_page)->port = rc; - d->mem_event.xen_port = rc; + ((mem_event_shared_page_t *)med->shared_page)->port = rc; + med->xen_port = rc; /* Prepare ring buffer */ - FRONT_RING_INIT(&d->mem_event.front_ring, - (mem_event_sring_t *)d->mem_event.ring_page, + FRONT_RING_INIT(&med->front_ring, + (mem_event_sring_t *)med->ring_page, PAGE_SIZE); - mem_event_ring_lock_init(d); + mem_event_ring_lock_init(med); /* Wake any VCPUs paused for memory events */ mem_event_unpause_vcpus(d); @@ -72,34 +72,34 @@ static int mem_event_enable(struct domai return 0; err_shared: - unmap_domain_page(d->mem_event.shared_page); - d->mem_event.shared_page = NULL; + unmap_domain_page(med->shared_page); + med->shared_page = NULL; err_ring: - unmap_domain_page(d->mem_event.ring_page); - d->mem_event.ring_page = NULL; + unmap_domain_page(med->ring_page); + med->ring_page = NULL; err: return 1; } -static int mem_event_disable(struct domain *d) +static int mem_event_disable(struct mem_event_domain *med) { - unmap_domain_page(d->mem_event.ring_page); - d->mem_event.ring_page = NULL; + unmap_domain_page(med->ring_page); + med->ring_page = NULL; - unmap_domain_page(d->mem_event.shared_page); - d->mem_event.shared_page = NULL; + unmap_domain_page(med->shared_page); + med->shared_page = NULL; return 0; } -void mem_event_put_request(struct domain *d, mem_event_request_t *req) +void mem_event_put_request(struct domain *d, struct mem_event_domain *med, mem_event_request_t *req) { mem_event_front_ring_t *front_ring; RING_IDX req_prod; - mem_event_ring_lock(d); + mem_event_ring_lock(med); - front_ring = &d->mem_event.front_ring; + front_ring = &med->front_ring; req_prod = front_ring->req_prod_pvt; /* Copy request */ @@ -107,23 +107,23 @@ void mem_event_put_request(struct domain req_prod++; /* Update ring */ - d->mem_event.req_producers--; + med->req_producers--; front_ring->req_prod_pvt = req_prod; RING_PUSH_REQUESTS(front_ring); - mem_event_ring_unlock(d); + mem_event_ring_unlock(med); - notify_via_xen_event_channel(d, d->mem_event.xen_port); + notify_via_xen_event_channel(d, med->xen_port); } -void mem_event_get_response(struct domain *d, mem_event_response_t *rsp) +void mem_event_get_response(struct mem_event_domain *med, mem_event_response_t *rsp) { mem_event_front_ring_t *front_ring; RING_IDX rsp_cons; - mem_event_ring_lock(d); + mem_event_ring_lock(med); - front_ring = &d->mem_event.front_ring; + front_ring = &med->front_ring; rsp_cons = front_ring->rsp_cons; /* Copy response */ @@ -134,7 +134,7 @@ void mem_event_get_response(struct domai front_ring->rsp_cons = rsp_cons; front_ring->sring->rsp_event = rsp_cons + 1; - mem_event_ring_unlock(d); + mem_event_ring_unlock(med); } void mem_event_unpause_vcpus(struct domain *d) @@ -152,35 +152,35 @@ void mem_event_mark_and_pause(struct vcp vcpu_sleep_nosync(v); } -void mem_event_put_req_producers(struct domain *d) +void mem_event_put_req_producers(struct mem_event_domain *med) { - mem_event_ring_lock(d); - d->mem_event.req_producers--; - mem_event_ring_unlock(d); + mem_event_ring_lock(med); + med->req_producers--; + mem_event_ring_unlock(med); } -int mem_event_check_ring(struct domain *d) +int mem_event_check_ring(struct mem_event_domain *med, domid_t dom_id) { struct vcpu *curr = current; int free_requests; int ring_full = 1; - if ( !d->mem_event.ring_page ) + if ( !med->ring_page ) return -1; - mem_event_ring_lock(d); + mem_event_ring_lock(med); - free_requests = RING_FREE_REQUESTS(&d->mem_event.front_ring); - if ( d->mem_event.req_producers < free_requests ) + free_requests = RING_FREE_REQUESTS(&med->front_ring); + if ( med->req_producers < free_requests ) { - d->mem_event.req_producers++; + med->req_producers++; ring_full = 0; } - if ( (curr->domain->domain_id == d->domain_id) && ring_full ) + if ( (curr->domain->domain_id == dom_id) && ring_full ) mem_event_mark_and_pause(curr); - mem_event_ring_unlock(d); + mem_event_ring_unlock(med); return ring_full; } @@ -230,6 +230,7 @@ int mem_event_domctl(struct domain *d, x { struct domain *dom_mem_event = current->domain; struct vcpu *v = current; + struct mem_event_domain *med = &d->mem_event; unsigned long ring_addr = mec->ring_addr; unsigned long shared_addr = mec->shared_addr; l1_pgentry_t l1e; @@ -242,7 +243,7 @@ int mem_event_domctl(struct domain *d, x * the cache is in an undefined state and so is the guest */ rc = -EBUSY; - if ( d->mem_event.ring_page ) + if ( med->ring_page ) break; /* Currently only EPT is supported */ @@ -270,7 +271,7 @@ int mem_event_domctl(struct domain *d, x break; rc = -EINVAL; - if ( mem_event_enable(d, ring_mfn, shared_mfn) != 0 ) + if ( mem_event_enable(d, med, ring_mfn, shared_mfn) != 0 ) break; rc = 0; @@ -279,7 +280,7 @@ int mem_event_domctl(struct domain *d, x case XEN_DOMCTL_MEM_EVENT_OP_DISABLE: { - rc = mem_event_disable(d); + rc = mem_event_disable(&d->mem_event); } break; diff -r 0268e7380953 -r 4e7bcc14b76a xen/arch/x86/mm/mem_sharing.c --- a/xen/arch/x86/mm/mem_sharing.c +++ b/xen/arch/x86/mm/mem_sharing.c @@ -281,12 +281,12 @@ static struct page_info* mem_sharing_all vcpu_pause_nosync(v); req.flags |= MEM_EVENT_FLAG_VCPU_PAUSED; - if(mem_event_check_ring(d)) return page; + if(mem_event_check_ring(&d->mem_event, d->domain_id)) return page; req.gfn = gfn; req.p2mt = p2m_ram_shared; req.vcpu_id = v->vcpu_id; - mem_event_put_request(d, &req); + mem_event_put_request(d, &d->mem_event, &req); return page; } @@ -301,7 +301,7 @@ int mem_sharing_sharing_resume(struct do mem_event_response_t rsp; /* Get request off the ring */ - mem_event_get_response(d, &rsp); + mem_event_get_response(&d->mem_event, &rsp); /* Unpause domain/vcpu */ if( rsp.flags & MEM_EVENT_FLAG_VCPU_PAUSED ) diff -r 0268e7380953 -r 4e7bcc14b76a xen/arch/x86/mm/p2m.c --- a/xen/arch/x86/mm/p2m.c +++ b/xen/arch/x86/mm/p2m.c @@ -755,7 +755,7 @@ void p2m_mem_paging_drop_page(struct dom mem_event_request_t req; /* Check that there's space on the ring for this request */ - if ( mem_event_check_ring(d) == 0) + if ( mem_event_check_ring(&d->mem_event, d->domain_id) == 0) { /* Send release notification to pager */ memset(&req, 0, sizeof(req)); @@ -763,7 +763,7 @@ void p2m_mem_paging_drop_page(struct dom req.gfn = gfn; req.vcpu_id = v->vcpu_id; - mem_event_put_request(d, &req); + mem_event_put_request(d, &d->mem_event, &req); } } @@ -775,7 +775,7 @@ void p2m_mem_paging_populate(struct doma struct p2m_domain *p2m = p2m_get_hostp2m(d); /* Check that there's space on the ring for this request */ - if ( mem_event_check_ring(d) ) + if ( mem_event_check_ring(&d->mem_event, d->domain_id) ) return; memset(&req, 0, sizeof(req)); @@ -803,7 +803,7 @@ void p2m_mem_paging_populate(struct doma else if ( p2mt != p2m_ram_paging_out && p2mt != p2m_ram_paged ) { /* gfn is already on its way back and vcpu is not paused */ - mem_event_put_req_producers(d); + mem_event_put_req_producers(&d->mem_event); return; } @@ -812,7 +812,7 @@ void p2m_mem_paging_populate(struct doma req.p2mt = p2mt; req.vcpu_id = v->vcpu_id; - mem_event_put_request(d, &req); + mem_event_put_request(d, &d->mem_event, &req); } int p2m_mem_paging_prep(struct domain *d, unsigned long gfn) @@ -842,7 +842,7 @@ void p2m_mem_paging_resume(struct domain mfn_t mfn; /* Pull the response off the ring */ - mem_event_get_response(d, &rsp); + mem_event_get_response(&d->mem_event, &rsp); /* Fix p2m entry if the page was not dropped */ if ( !(rsp.flags & MEM_EVENT_FLAG_DROP_PAGE) ) @@ -889,7 +889,7 @@ void p2m_mem_access_check(unsigned long p2m_unlock(p2m); /* Otherwise, check if there is a memory event listener, and send the message along */ - res = mem_event_check_ring(d); + res = mem_event_check_ring(&d->mem_event, d->domain_id); if ( res < 0 ) { /* No listener */ @@ -933,7 +933,7 @@ void p2m_mem_access_check(unsigned long req.vcpu_id = v->vcpu_id; - mem_event_put_request(d, &req); + mem_event_put_request(d, &d->mem_event, &req); /* VCPU paused, mem event request sent */ } @@ -943,7 +943,7 @@ void p2m_mem_access_resume(struct p2m_do struct domain *d = p2m->domain; mem_event_response_t rsp; - mem_event_get_response(d, &rsp); + mem_event_get_response(&d->mem_event, &rsp); /* Unpause domain */ if ( rsp.flags & MEM_EVENT_FLAG_VCPU_PAUSED ) diff -r 0268e7380953 -r 4e7bcc14b76a xen/include/asm-x86/mem_event.h --- a/xen/include/asm-x86/mem_event.h +++ b/xen/include/asm-x86/mem_event.h @@ -26,10 +26,10 @@ /* Pauses VCPU while marking pause flag for mem event */ void mem_event_mark_and_pause(struct vcpu *v); -int mem_event_check_ring(struct domain *d); -void mem_event_put_req_producers(struct domain *d); -void mem_event_put_request(struct domain *d, mem_event_request_t *req); -void mem_event_get_response(struct domain *d, mem_event_response_t *rsp); +int mem_event_check_ring(struct mem_event_domain *med, domid_t dom_id); +void mem_event_put_req_producers(struct mem_event_domain *med); +void mem_event_put_request(struct domain *d, struct mem_event_domain *med, mem_event_request_t *req); +void mem_event_get_response(struct mem_event_domain *med, mem_event_response_t *rsp); void mem_event_unpause_vcpus(struct domain *d); int mem_event_domctl(struct domain *d, xen_domctl_mem_event_op_t *mec, _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel From xen-devel-bounces@lists.xensource.com Wed Sep 07 05:17:23 2011 Return-path: Envelope-to: www-data@lists.xensource.com Delivery-date: Wed, 07 Sep 2011 05:17:23 -0700 Received: from localhost ([127.0.0.1] helo=lists.colo.xensource.com) by lists.xensource.com with esmtp (Exim 4.43) id 1R1H4F-0006cy-KS; Wed, 07 Sep 2011 05:17:23 -0700 Received: from mail21.messagelabs.com ([85.158.143.35]) by lists.xensource.com with esmtp (Exim 4.43) id 1R1H2f-00062a-KV for xen-devel@lists.xensource.com; Wed, 07 Sep 2011 05:15:46 -0700 X-Env-Sender: olaf@aepfle.de X-Msg-Ref: server-9.tower-21.messagelabs.com!1315397699!47498775!1 X-Originating-IP: [81.169.146.162] X-StarScan-Version: 6.3.6; banners=-,-,- X-VirusChecked: Checked Received: (qmail 26026 invoked from network); 7 Sep 2011 12:15:00 -0000 Received: from mo-p00-ob.rzone.de (HELO mo-p00-ob.rzone.de) (81.169.146.162) by server-9.tower-21.messagelabs.com with EDH-RSA-DES-CBC3-SHA encrypted SMTP; 7 Sep 2011 12:15:00 -0000 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; t=1315397742; l=871; s=domk; d=aepfle.de; h=To:From:Date:Subject:Content-Transfer-Encoding:MIME-Version: Content-Type:X-RZG-CLASS-ID:X-RZG-AUTH; bh=fUUOtGzdIHKPmxTcS6NiROXV59U=; b=jttwtKNkV0xRA0D7iXULo4fh/K8hpNfAZtvuo2HFloGKdH1g4egoOxqclmPQKikqgO7 cfOreZtMWe0+5WLbDlIflqx1HZq17j0cntQlzGtvv+Bem6QF7Jxwh9W8j94vTxR5RfEJb 4shyJ2PGbpQnkPNOE6jW1mG5am7yPVnYOm8= X-RZG-AUTH: :P2EQZWCpfu+qG7CngxMFH1J+zrwiavkK6tmQaLfmwtM48/lq287pEZIt X-RZG-CLASS-ID: mo00 Received: from probook.site (dslb-084-057-072-233.pools.arcor-ip.net [84.57.72.233]) by smtp.strato.de (klopstock mo54) (RZmta 26.6) with (EDH-RSA-DES-CBC3-SHA encrypted) ESMTPA id N01546n87BBoT0 for ; Wed, 7 Sep 2011 14:15:37 +0200 (MEST) Received: from probook.site (localhost [IPv6:::1]) by probook.site (Postfix) with ESMTP id B8D2018892 for ; Wed, 7 Sep 2011 14:15:36 +0200 (CEST) Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Message-Id: User-Agent: Mercurial-patchbomb/1.7.5 Date: Wed, 07 Sep 2011 14:15:28 +0200 From: Olaf Hering To: xen-devel@lists.xensource.com Subject: [Xen-devel] [PATCH 0 of 2] memshare/xenpaging/xen-access fixes for xen-unstable X-BeenThere: xen-devel@lists.xensource.com X-Mailman-Version: 2.1.5 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xensource.com Errors-To: xen-devel-bounces@lists.xensource.com The following two patches allow the parallel use of memsharing, xenpaging and xen-access by using an independent ring buffer for each feature. Please review. Olaf tools/libxc/Makefile | 2 tools/libxc/xc_mem_access.c | 21 ++- tools/libxc/xc_mem_event.c | 15 -- tools/libxc/xc_mem_paging.c | 33 +++- tools/libxc/xc_memshr.c | 16 +- tools/libxc/xenctrl.h | 9 - tools/tests/xen-access/xen-access.c | 4 tools/xenpaging/xenpaging.c | 4 xen/arch/ia64/xen/dom0_ops.c | 2 xen/arch/x86/hvm/hvm.c | 4 xen/arch/x86/mm/mem_event.c | 239 +++++++++++++++++++----------------- xen/arch/x86/mm/mem_paging.c | 4 xen/arch/x86/mm/mem_sharing.c | 22 +-- xen/arch/x86/mm/p2m.c | 18 +- xen/include/asm-x86/mem_event.h | 8 - xen/include/public/domctl.h | 43 +++--- xen/include/xen/sched.h | 6 17 files changed, 248 insertions(+), 202 deletions(-) _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel From xen-devel-bounces@lists.xensource.com Wed Sep 07 05:18:20 2011 Return-path: Envelope-to: www-data@lists.xensource.com Delivery-date: Wed, 07 Sep 2011 05:18:20 -0700 Received: from localhost ([127.0.0.1] helo=lists.colo.xensource.com) by lists.xensource.com with esmtp (Exim 4.43) id 1R1H59-00070C-TS; Wed, 07 Sep 2011 05:18:19 -0700 Received: from mail216.messagelabs.com ([85.158.143.99]) by lists.xensource.com with esmtp (Exim 4.43) id 1R1H2n-00063b-4F for xen-devel@lists.xensource.com; Wed, 07 Sep 2011 05:15:55 -0700 X-Env-Sender: olaf@aepfle.de X-Msg-Ref: server-11.tower-216.messagelabs.com!1315397749!9809194!1 X-Originating-IP: [81.169.146.162] X-StarScan-Version: 6.3.6; banners=-,-,- X-VirusChecked: Checked Received: (qmail 5599 invoked from network); 7 Sep 2011 12:15:50 -0000 Received: from mo-p00-ob.rzone.de (HELO mo-p00-ob.rzone.de) (81.169.146.162) by server-11.tower-216.messagelabs.com with EDH-RSA-DES-CBC3-SHA encrypted SMTP; 7 Sep 2011 12:15:50 -0000 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; t=1315397749; l=26401; s=domk; d=aepfle.de; h=To:From:Date:References:In-Reply-To:Subject: Content-Transfer-Encoding:MIME-Version:Content-Type:X-RZG-CLASS-ID: X-RZG-AUTH; bh=T3tjIqhTZx2rK1vfvf1i9un2rp8=; b=apyl3ZjsBlWS99XubBS+QxqpI0AhzNoo56fmwG4WTAhp+rlIw8h6Xbj3USwJs7IMBOv J3YreJuanQHyetqgcme9uqvqB1FvR1Q+BSaDkRvXZ+5bq2KTLey9ffZTt6ttxbsU8Ofe8 u1NNMBfn7aChnJoVR573x3PPdUUQcK6/D8g= X-RZG-AUTH: :P2EQZWCpfu+qG7CngxMFH1J+zrwiavkK6tmQaLfmwtM48/lq287pEZIt X-RZG-CLASS-ID: mo00 Received: from probook.site (dslb-084-057-072-233.pools.arcor-ip.net [84.57.72.233]) by post.strato.de (mrclete mo40) (RZmta 26.6) with (EDH-RSA-DES-CBC3-SHA encrypted) ESMTPA id L02d2dn87BUkGI for ; Wed, 7 Sep 2011 14:15:38 +0200 (MEST) Received: from probook.site (localhost [IPv6:::1]) by probook.site (Postfix) with ESMTP id 41C6918B66 for ; Wed, 7 Sep 2011 14:15:37 +0200 (CEST) Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Mercurial-Node: 9b0929f3243ced27c7c316b008de27cf89402d14 Message-Id: <9b0929f3243ced27c7c3.1315397730@probook.site> In-Reply-To: References: User-Agent: Mercurial-patchbomb/1.7.5 Date: Wed, 07 Sep 2011 14:15:30 +0200 From: Olaf Hering To: xen-devel@lists.xensource.com Subject: [Xen-devel] [PATCH 2 of 2] mem_event: use different ringbuffers for share, paging and access X-BeenThere: xen-devel@lists.xensource.com X-Mailman-Version: 2.1.5 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xensource.com Errors-To: xen-devel-bounces@lists.xensource.com # HG changeset patch # User Olaf Hering # Date 1315389350 -7200 # Node ID 9b0929f3243ced27c7c316b008de27cf89402d14 # Parent 4e7bcc14b76a8e37bc8e2fe490ef6b3209bd8738 mem_event: use different ringbuffers for share, paging and access Up to now a single ring buffer was used for mem_share, xenpaging and xen-access. Each helper would have to cooperate and pull only its own requests from the ring. Unfortunately this was not implemented. And even if it was, it would make the whole concept fragile because a crash or early exit of one helper would stall the others. What happend up to now is that active xenpaging + memory_sharing would push memsharing requests in the buffer. xenpaging is not prepared for such requests. This patch creates an independet ring buffer for mem_share, xenpaging and xen-access and adds also new functions to enable xenpaging and xen-access. The xc_mem_event_enable/xc_mem_event_disable functions will be removed. The various XEN_DOMCTL_MEM_EVENT_* macros were cleaned up. Due to the removal the API changed, so the SONAME will be changed too. Signed-off-by: Olaf Hering diff -r 4e7bcc14b76a -r 9b0929f3243c tools/libxc/Makefile --- a/tools/libxc/Makefile +++ b/tools/libxc/Makefile @@ -1,7 +1,7 @@ XEN_ROOT = $(CURDIR)/../.. include $(XEN_ROOT)/tools/Rules.mk -MAJOR = 4.0 +MAJOR = 4.2 MINOR = 0 CTRL_SRCS-y := diff -r 4e7bcc14b76a -r 9b0929f3243c tools/libxc/xc_mem_access.c --- a/tools/libxc/xc_mem_access.c +++ b/tools/libxc/xc_mem_access.c @@ -24,12 +24,29 @@ #include "xc_private.h" +int xc_mem_access_enable(xc_interface *xch, domid_t domain_id, + void *shared_page, void *ring_page) +{ + return xc_mem_event_control(xch, domain_id, + XEN_DOMCTL_MEM_EVENT_OP_ACCESS_ENABLE, + XEN_DOMCTL_MEM_EVENT_OP_ACCESS, + shared_page, ring_page, INVALID_MFN); +} + +int xc_mem_access_disable(xc_interface *xch, domid_t domain_id) +{ + return xc_mem_event_control(xch, domain_id, + XEN_DOMCTL_MEM_EVENT_OP_ACCESS_DISABLE, + XEN_DOMCTL_MEM_EVENT_OP_ACCESS, + NULL, NULL, INVALID_MFN); +} + int xc_mem_access_resume(xc_interface *xch, domid_t domain_id, unsigned long gfn) { return xc_mem_event_control(xch, domain_id, XEN_DOMCTL_MEM_EVENT_OP_ACCESS_RESUME, - XEN_DOMCTL_MEM_EVENT_OP_ACCESS, NULL, NULL, - gfn); + XEN_DOMCTL_MEM_EVENT_OP_ACCESS, + NULL, NULL, gfn); } /* diff -r 4e7bcc14b76a -r 9b0929f3243c tools/libxc/xc_mem_event.c --- a/tools/libxc/xc_mem_event.c +++ b/tools/libxc/xc_mem_event.c @@ -42,18 +42,3 @@ int xc_mem_event_control(xc_interface *x return do_domctl(xch, &domctl); } -int xc_mem_event_enable(xc_interface *xch, domid_t domain_id, - void *shared_page, void *ring_page) -{ - return xc_mem_event_control(xch, domain_id, - XEN_DOMCTL_MEM_EVENT_OP_ENABLE, 0, - shared_page, ring_page, INVALID_MFN); -} - -int xc_mem_event_disable(xc_interface *xch, domid_t domain_id) -{ - return xc_mem_event_control(xch, domain_id, - XEN_DOMCTL_MEM_EVENT_OP_DISABLE, 0, - NULL, NULL, INVALID_MFN); -} - diff -r 4e7bcc14b76a -r 9b0929f3243c tools/libxc/xc_mem_paging.c --- a/tools/libxc/xc_mem_paging.c +++ b/tools/libxc/xc_mem_paging.c @@ -24,36 +24,53 @@ #include "xc_private.h" +int xc_mem_paging_enable(xc_interface *xch, domid_t domain_id, + void *shared_page, void *ring_page) +{ + return xc_mem_event_control(xch, domain_id, + XEN_DOMCTL_MEM_EVENT_OP_PAGING_ENABLE, + XEN_DOMCTL_MEM_EVENT_OP_PAGING, + shared_page, ring_page, INVALID_MFN); +} + +int xc_mem_paging_disable(xc_interface *xch, domid_t domain_id) +{ + return xc_mem_event_control(xch, domain_id, + XEN_DOMCTL_MEM_EVENT_OP_PAGING_DISABLE, + XEN_DOMCTL_MEM_EVENT_OP_PAGING, + NULL, NULL, INVALID_MFN); +} + int xc_mem_paging_nominate(xc_interface *xch, domid_t domain_id, unsigned long gfn) { return xc_mem_event_control(xch, domain_id, XEN_DOMCTL_MEM_EVENT_OP_PAGING_NOMINATE, - XEN_DOMCTL_MEM_EVENT_OP_PAGING, NULL, NULL, - gfn); + XEN_DOMCTL_MEM_EVENT_OP_PAGING, + NULL, NULL, gfn); } int xc_mem_paging_evict(xc_interface *xch, domid_t domain_id, unsigned long gfn) { return xc_mem_event_control(xch, domain_id, XEN_DOMCTL_MEM_EVENT_OP_PAGING_EVICT, - XEN_DOMCTL_MEM_EVENT_OP_PAGING, NULL, NULL, - gfn); + XEN_DOMCTL_MEM_EVENT_OP_PAGING, + NULL, NULL, gfn); } int xc_mem_paging_prep(xc_interface *xch, domid_t domain_id, unsigned long gfn) { return xc_mem_event_control(xch, domain_id, XEN_DOMCTL_MEM_EVENT_OP_PAGING_PREP, - XEN_DOMCTL_MEM_EVENT_OP_PAGING, NULL, NULL, - gfn); + XEN_DOMCTL_MEM_EVENT_OP_PAGING, + NULL, NULL, gfn); } int xc_mem_paging_resume(xc_interface *xch, domid_t domain_id, unsigned long gfn) { return xc_mem_event_control(xch, domain_id, XEN_DOMCTL_MEM_EVENT_OP_PAGING_RESUME, - XEN_DOMCTL_MEM_EVENT_OP_PAGING, NULL, NULL, - gfn); + XEN_DOMCTL_MEM_EVENT_OP_PAGING, + NULL, NULL, gfn); } diff -r 4e7bcc14b76a -r 9b0929f3243c tools/libxc/xc_memshr.c --- a/tools/libxc/xc_memshr.c +++ b/tools/libxc/xc_memshr.c @@ -36,7 +36,7 @@ int xc_memshr_control(xc_interface *xch, domctl.interface_version = XEN_DOMCTL_INTERFACE_VERSION; domctl.domain = (domid_t)domid; op = &(domctl.u.mem_sharing_op); - op->op = XEN_DOMCTL_MEM_SHARING_OP_CONTROL; + op->op = XEN_DOMCTL_MEM_EVENT_OP_SHARING_CONTROL; op->u.enable = enable; return do_domctl(xch, &domctl); @@ -55,7 +55,7 @@ int xc_memshr_nominate_gfn(xc_interface domctl.interface_version = XEN_DOMCTL_INTERFACE_VERSION; domctl.domain = (domid_t)domid; op = &(domctl.u.mem_sharing_op); - op->op = XEN_DOMCTL_MEM_SHARING_OP_NOMINATE_GFN; + op->op = XEN_DOMCTL_MEM_EVENT_OP_SHARING_NOMINATE_GFN; op->u.nominate.u.gfn = gfn; ret = do_domctl(xch, &domctl); @@ -77,7 +77,7 @@ int xc_memshr_nominate_gref(xc_interface domctl.interface_version = XEN_DOMCTL_INTERFACE_VERSION; domctl.domain = (domid_t)domid; op = &(domctl.u.mem_sharing_op); - op->op = XEN_DOMCTL_MEM_SHARING_OP_NOMINATE_GREF; + op->op = XEN_DOMCTL_MEM_EVENT_OP_SHARING_NOMINATE_GREF; op->u.nominate.u.grant_ref = gref; ret = do_domctl(xch, &domctl); @@ -97,7 +97,7 @@ int xc_memshr_share(xc_interface *xch, domctl.interface_version = XEN_DOMCTL_INTERFACE_VERSION; domctl.domain = 0; op = &(domctl.u.mem_sharing_op); - op->op = XEN_DOMCTL_MEM_SHARING_OP_SHARE; + op->op = XEN_DOMCTL_MEM_EVENT_OP_SHARING_SHARE; op->u.share.source_handle = source_handle; op->u.share.client_handle = client_handle; @@ -114,7 +114,7 @@ int xc_memshr_domain_resume(xc_interface domctl.interface_version = XEN_DOMCTL_INTERFACE_VERSION; domctl.domain = (domid_t)domid; op = &(domctl.u.mem_sharing_op); - op->op = XEN_DOMCTL_MEM_SHARING_OP_RESUME; + op->op = XEN_DOMCTL_MEM_EVENT_OP_SHARING_RESUME; return do_domctl(xch, &domctl); } @@ -130,7 +130,7 @@ int xc_memshr_debug_gfn(xc_interface *xc domctl.interface_version = XEN_DOMCTL_INTERFACE_VERSION; domctl.domain = (domid_t)domid; op = &(domctl.u.mem_sharing_op); - op->op = XEN_DOMCTL_MEM_SHARING_OP_DEBUG_GFN; + op->op = XEN_DOMCTL_MEM_EVENT_OP_SHARING_DEBUG_GFN; op->u.debug.u.gfn = gfn; return do_domctl(xch, &domctl); @@ -147,7 +147,7 @@ int xc_memshr_debug_mfn(xc_interface *xc domctl.interface_version = XEN_DOMCTL_INTERFACE_VERSION; domctl.domain = (domid_t)domid; op = &(domctl.u.mem_sharing_op); - op->op = XEN_DOMCTL_MEM_SHARING_OP_DEBUG_MFN; + op->op = XEN_DOMCTL_MEM_EVENT_OP_SHARING_DEBUG_MFN; op->u.debug.u.mfn = mfn; return do_domctl(xch, &domctl); @@ -164,7 +164,7 @@ int xc_memshr_debug_gref(xc_interface *x domctl.interface_version = XEN_DOMCTL_INTERFACE_VERSION; domctl.domain = (domid_t)domid; op = &(domctl.u.mem_sharing_op); - op->op = XEN_DOMCTL_MEM_SHARING_OP_DEBUG_GREF; + op->op = XEN_DOMCTL_MEM_EVENT_OP_SHARING_DEBUG_GREF; op->u.debug.u.gref = gref; return do_domctl(xch, &domctl); diff -r 4e7bcc14b76a -r 9b0929f3243c tools/libxc/xenctrl.h --- a/tools/libxc/xenctrl.h +++ b/tools/libxc/xenctrl.h @@ -1758,16 +1758,19 @@ int xc_mem_event_control(xc_interface *x unsigned int mode, void *shared_page, void *ring_page, unsigned long gfn); -int xc_mem_event_enable(xc_interface *xch, domid_t domain_id, +int xc_mem_paging_enable(xc_interface *xch, domid_t domain_id, void *shared_page, void *ring_page); -int xc_mem_event_disable(xc_interface *xch, domid_t domain_id); - +int xc_mem_paging_disable(xc_interface *xch, domid_t domain_id); int xc_mem_paging_nominate(xc_interface *xch, domid_t domain_id, unsigned long gfn); int xc_mem_paging_evict(xc_interface *xch, domid_t domain_id, unsigned long gfn); int xc_mem_paging_prep(xc_interface *xch, domid_t domain_id, unsigned long gfn); int xc_mem_paging_resume(xc_interface *xch, domid_t domain_id, unsigned long gfn); + +int xc_mem_access_enable(xc_interface *xch, domid_t domain_id, + void *shared_page, void *ring_page); +int xc_mem_access_disable(xc_interface *xch, domid_t domain_id); int xc_mem_access_resume(xc_interface *xch, domid_t domain_id, unsigned long gfn); diff -r 4e7bcc14b76a -r 9b0929f3243c tools/tests/xen-access/xen-access.c --- a/tools/tests/xen-access/xen-access.c +++ b/tools/tests/xen-access/xen-access.c @@ -241,7 +241,7 @@ xenaccess_t *xenaccess_init(xc_interface mem_event_ring_lock_init(&xenaccess->mem_event); /* Initialise Xen */ - rc = xc_mem_event_enable(xenaccess->xc_handle, xenaccess->mem_event.domain_id, + rc = xc_mem_access_enable(xenaccess->xc_handle, xenaccess->mem_event.domain_id, xenaccess->mem_event.shared_page, xenaccess->mem_event.ring_page); if ( rc != 0 ) @@ -351,7 +351,7 @@ int xenaccess_teardown(xc_interface *xch return 0; /* Tear down domain xenaccess in Xen */ - rc = xc_mem_event_disable(xenaccess->xc_handle, xenaccess->mem_event.domain_id); + rc = xc_mem_access_disable(xenaccess->xc_handle, xenaccess->mem_event.domain_id); if ( rc != 0 ) { ERROR("Error tearing down domain xenaccess in xen"); diff -r 4e7bcc14b76a -r 9b0929f3243c tools/xenpaging/xenpaging.c --- a/tools/xenpaging/xenpaging.c +++ b/tools/xenpaging/xenpaging.c @@ -234,7 +234,7 @@ static xenpaging_t *xenpaging_init(domid PAGE_SIZE); /* Initialise Xen */ - rc = xc_mem_event_enable(xch, paging->mem_event.domain_id, + rc = xc_mem_paging_enable(xch, paging->mem_event.domain_id, paging->mem_event.shared_page, paging->mem_event.ring_page); if ( rc != 0 ) @@ -353,7 +353,7 @@ static int xenpaging_teardown(xenpaging_ xch = paging->xc_handle; paging->xc_handle = NULL; /* Tear down domain paging in Xen */ - rc = xc_mem_event_disable(xch, paging->mem_event.domain_id); + rc = xc_mem_paging_disable(xch, paging->mem_event.domain_id); if ( rc != 0 ) { ERROR("Error tearing down domain paging in xen"); diff -r 4e7bcc14b76a -r 9b0929f3243c xen/arch/ia64/xen/dom0_ops.c --- a/xen/arch/ia64/xen/dom0_ops.c +++ b/xen/arch/ia64/xen/dom0_ops.c @@ -688,7 +688,7 @@ long arch_do_domctl(xen_domctl_t *op, XE switch(mec->op) { - case XEN_DOMCTL_MEM_SHARING_OP_CONTROL: + case XEN_DOMCTL_MEM_EVENT_OP_SHARING_CONTROL: { if (mec->u.enable) { ret = -EINVAL; /* not implemented */ diff -r 4e7bcc14b76a -r 9b0929f3243c xen/arch/x86/hvm/hvm.c --- a/xen/arch/x86/hvm/hvm.c +++ b/xen/arch/x86/hvm/hvm.c @@ -4025,7 +4025,7 @@ static int hvm_memory_event_traps(long p if ( (p & HVMPME_onchangeonly) && (value == old) ) return 1; - rc = mem_event_check_ring(&d->mem_event, d->domain_id); + rc = mem_event_check_ring(&d->mem_access, d->domain_id); if ( rc ) return rc; @@ -4048,7 +4048,7 @@ static int hvm_memory_event_traps(long p req.gla_valid = 1; } - mem_event_put_request(d, &d->mem_event, &req); + mem_event_put_request(d, &d->mem_access, &req); return 1; } diff -r 4e7bcc14b76a -r 9b0929f3243c xen/arch/x86/mm/mem_event.c --- a/xen/arch/x86/mm/mem_event.c +++ b/xen/arch/x86/mm/mem_event.c @@ -37,24 +37,52 @@ #define mem_event_ring_lock(_med) spin_lock(&(_med)->ring_lock) #define mem_event_ring_unlock(_med) spin_unlock(&(_med)->ring_lock) -static int mem_event_enable(struct domain *d, struct mem_event_domain *med, mfn_t ring_mfn, mfn_t shared_mfn) +static int mem_event_enable(struct domain *d, + xen_domctl_mem_event_op_t *mec, + struct mem_event_domain *med) { int rc; + struct domain *dom_mem_event = current->domain; + struct vcpu *v = current; + unsigned long ring_addr = mec->ring_addr; + unsigned long shared_addr = mec->shared_addr; + l1_pgentry_t l1e; + unsigned long gfn; + p2m_type_t p2mt; + mfn_t ring_mfn; + mfn_t shared_mfn; + + /* Only one helper at a time. If the helper crashed, + * the ring is in an undefined state and so is the guest. + */ + if ( med->ring_page ) + return -EBUSY; + + /* Get MFN of ring page */ + guest_get_eff_l1e(v, ring_addr, &l1e); + gfn = l1e_get_pfn(l1e); + ring_mfn = gfn_to_mfn(dom_mem_event, gfn, &p2mt); + + if ( unlikely(!mfn_valid(mfn_x(ring_mfn))) ) + return -EINVAL; + + /* Get MFN of shared page */ + guest_get_eff_l1e(v, shared_addr, &l1e); + gfn = l1e_get_pfn(l1e); + shared_mfn = gfn_to_mfn(dom_mem_event, gfn, &p2mt); + + if ( unlikely(!mfn_valid(mfn_x(shared_mfn))) ) + return -EINVAL; /* Map ring and shared pages */ med->ring_page = map_domain_page(mfn_x(ring_mfn)); - if ( med->ring_page == NULL ) - goto err; - med->shared_page = map_domain_page(mfn_x(shared_mfn)); - if ( med->shared_page == NULL ) - goto err_ring; /* Allocate event channel */ rc = alloc_unbound_xen_event_channel(d->vcpu[0], current->domain->domain_id); if ( rc < 0 ) - goto err_shared; + goto err; ((mem_event_shared_page_t *)med->shared_page)->port = rc; med->xen_port = rc; @@ -71,14 +99,14 @@ static int mem_event_enable(struct domai return 0; - err_shared: + err: unmap_domain_page(med->shared_page); med->shared_page = NULL; - err_ring: + unmap_domain_page(med->ring_page); med->ring_page = NULL; - err: - return 1; + + return rc; } static int mem_event_disable(struct mem_event_domain *med) @@ -220,86 +248,78 @@ int mem_event_domctl(struct domain *d, x rc = -ENOSYS; - switch ( mec-> mode ) + switch ( mec->mode ) { - case 0: + case XEN_DOMCTL_MEM_EVENT_OP_PAGING: { + rc = -ENODEV; + /* Only HAP is supported */ + if ( !hap_enabled(d) ) + break; + + /* Currently only EPT is supported */ + if ( boot_cpu_data.x86_vendor != X86_VENDOR_INTEL ) + break; + switch( mec->op ) { - case XEN_DOMCTL_MEM_EVENT_OP_ENABLE: + case XEN_DOMCTL_MEM_EVENT_OP_PAGING_ENABLE: { - struct domain *dom_mem_event = current->domain; - struct vcpu *v = current; - struct mem_event_domain *med = &d->mem_event; - unsigned long ring_addr = mec->ring_addr; - unsigned long shared_addr = mec->shared_addr; - l1_pgentry_t l1e; - unsigned long gfn; - p2m_type_t p2mt; - mfn_t ring_mfn; - mfn_t shared_mfn; - /* Only one xenpaging at a time. If xenpaging crashed, - * the cache is in an undefined state and so is the guest - */ - rc = -EBUSY; - if ( med->ring_page ) - break; - - /* Currently only EPT is supported */ - rc = -ENODEV; - if ( !(hap_enabled(d) && - (boot_cpu_data.x86_vendor == X86_VENDOR_INTEL)) ) - break; - - /* Get MFN of ring page */ - guest_get_eff_l1e(v, ring_addr, &l1e); - gfn = l1e_get_pfn(l1e); - ring_mfn = gfn_to_mfn(dom_mem_event, gfn, &p2mt); - - rc = -EINVAL; - if ( unlikely(!mfn_valid(mfn_x(ring_mfn))) ) - break; - - /* Get MFN of shared page */ - guest_get_eff_l1e(v, shared_addr, &l1e); - gfn = l1e_get_pfn(l1e); - shared_mfn = gfn_to_mfn(dom_mem_event, gfn, &p2mt); - - rc = -EINVAL; - if ( unlikely(!mfn_valid(mfn_x(shared_mfn))) ) - break; - - rc = -EINVAL; - if ( mem_event_enable(d, med, ring_mfn, shared_mfn) != 0 ) - break; - - rc = 0; + struct mem_event_domain *med = &d->mem_paging; + rc = mem_event_enable(d, mec, med); } break; - case XEN_DOMCTL_MEM_EVENT_OP_DISABLE: + case XEN_DOMCTL_MEM_EVENT_OP_PAGING_DISABLE: { - rc = mem_event_disable(&d->mem_event); + rc = mem_event_disable(&d->mem_paging); } break; default: - rc = -ENOSYS; - break; + { + rc = mem_paging_domctl(d, mec, u_domctl); } break; + } } - case XEN_DOMCTL_MEM_EVENT_OP_PAGING: - { - rc = mem_paging_domctl(d, mec, u_domctl); - break; - } + break; case XEN_DOMCTL_MEM_EVENT_OP_ACCESS: { - rc = mem_access_domctl(d, mec, u_domctl); + rc = -ENODEV; + /* Only HAP is supported */ + if ( !hap_enabled(d) ) + break; + + /* Currently only EPT is supported */ + if ( boot_cpu_data.x86_vendor != X86_VENDOR_INTEL ) + break; + + switch( mec->op ) + { + case XEN_DOMCTL_MEM_EVENT_OP_ACCESS_ENABLE: + { + + struct mem_event_domain *med = &d->mem_access; + rc = mem_event_enable(d, mec, med); + } break; + + case XEN_DOMCTL_MEM_EVENT_OP_ACCESS_DISABLE: + { + rc = mem_event_disable(&d->mem_access); + } + break; + + default: + { + rc = mem_access_domctl(d, mec, u_domctl); + } + break; + } } + break; } return rc; diff -r 4e7bcc14b76a -r 9b0929f3243c xen/arch/x86/mm/mem_paging.c --- a/xen/arch/x86/mm/mem_paging.c +++ b/xen/arch/x86/mm/mem_paging.c @@ -28,10 +28,6 @@ int mem_paging_domctl(struct domain *d, xen_domctl_mem_event_op_t *mec, XEN_GUEST_HANDLE(void) u_domctl) { - /* Only HAP is supported */ - if ( !hap_enabled(d) ) - return -ENODEV; - switch( mec->op ) { case XEN_DOMCTL_MEM_EVENT_OP_PAGING_NOMINATE: diff -r 4e7bcc14b76a -r 9b0929f3243c xen/arch/x86/mm/mem_sharing.c --- a/xen/arch/x86/mm/mem_sharing.c +++ b/xen/arch/x86/mm/mem_sharing.c @@ -281,12 +281,12 @@ static struct page_info* mem_sharing_all vcpu_pause_nosync(v); req.flags |= MEM_EVENT_FLAG_VCPU_PAUSED; - if(mem_event_check_ring(&d->mem_event, d->domain_id)) return page; + if(mem_event_check_ring(&d->mem_share, d->domain_id)) return page; req.gfn = gfn; req.p2mt = p2m_ram_shared; req.vcpu_id = v->vcpu_id; - mem_event_put_request(d, &d->mem_event, &req); + mem_event_put_request(d, &d->mem_share, &req); return page; } @@ -301,7 +301,7 @@ int mem_sharing_sharing_resume(struct do mem_event_response_t rsp; /* Get request off the ring */ - mem_event_get_response(&d->mem_event, &rsp); + mem_event_get_response(&d->mem_share, &rsp); /* Unpause domain/vcpu */ if( rsp.flags & MEM_EVENT_FLAG_VCPU_PAUSED ) @@ -697,14 +697,14 @@ int mem_sharing_domctl(struct domain *d, switch(mec->op) { - case XEN_DOMCTL_MEM_SHARING_OP_CONTROL: + case XEN_DOMCTL_MEM_EVENT_OP_SHARING_CONTROL: { d->arch.hvm_domain.mem_sharing_enabled = mec->u.enable; rc = 0; } break; - case XEN_DOMCTL_MEM_SHARING_OP_NOMINATE_GFN: + case XEN_DOMCTL_MEM_EVENT_OP_SHARING_NOMINATE_GFN: { unsigned long gfn = mec->u.nominate.u.gfn; shr_handle_t handle; @@ -715,7 +715,7 @@ int mem_sharing_domctl(struct domain *d, } break; - case XEN_DOMCTL_MEM_SHARING_OP_NOMINATE_GREF: + case XEN_DOMCTL_MEM_EVENT_OP_SHARING_NOMINATE_GREF: { grant_ref_t gref = mec->u.nominate.u.grant_ref; unsigned long gfn; @@ -730,7 +730,7 @@ int mem_sharing_domctl(struct domain *d, } break; - case XEN_DOMCTL_MEM_SHARING_OP_SHARE: + case XEN_DOMCTL_MEM_EVENT_OP_SHARING_SHARE: { shr_handle_t sh = mec->u.share.source_handle; shr_handle_t ch = mec->u.share.client_handle; @@ -738,7 +738,7 @@ int mem_sharing_domctl(struct domain *d, } break; - case XEN_DOMCTL_MEM_SHARING_OP_RESUME: + case XEN_DOMCTL_MEM_EVENT_OP_SHARING_RESUME: { if(!mem_sharing_enabled(d)) return -EINVAL; @@ -746,21 +746,21 @@ int mem_sharing_domctl(struct domain *d, } break; - case XEN_DOMCTL_MEM_SHARING_OP_DEBUG_GFN: + case XEN_DOMCTL_MEM_EVENT_OP_SHARING_DEBUG_GFN: { unsigned long gfn = mec->u.debug.u.gfn; rc = mem_sharing_debug_gfn(d, gfn); } break; - case XEN_DOMCTL_MEM_SHARING_OP_DEBUG_MFN: + case XEN_DOMCTL_MEM_EVENT_OP_SHARING_DEBUG_MFN: { unsigned long mfn = mec->u.debug.u.mfn; rc = mem_sharing_debug_mfn(mfn); } break; - case XEN_DOMCTL_MEM_SHARING_OP_DEBUG_GREF: + case XEN_DOMCTL_MEM_EVENT_OP_SHARING_DEBUG_GREF: { grant_ref_t gref = mec->u.debug.u.gref; rc = mem_sharing_debug_gref(d, gref); diff -r 4e7bcc14b76a -r 9b0929f3243c xen/arch/x86/mm/p2m.c --- a/xen/arch/x86/mm/p2m.c +++ b/xen/arch/x86/mm/p2m.c @@ -755,7 +755,7 @@ void p2m_mem_paging_drop_page(struct dom mem_event_request_t req; /* Check that there's space on the ring for this request */ - if ( mem_event_check_ring(&d->mem_event, d->domain_id) == 0) + if ( mem_event_check_ring(&d->mem_paging, d->domain_id) == 0) { /* Send release notification to pager */ memset(&req, 0, sizeof(req)); @@ -763,7 +763,7 @@ void p2m_mem_paging_drop_page(struct dom req.gfn = gfn; req.vcpu_id = v->vcpu_id; - mem_event_put_request(d, &d->mem_event, &req); + mem_event_put_request(d, &d->mem_paging, &req); } } @@ -775,7 +775,7 @@ void p2m_mem_paging_populate(struct doma struct p2m_domain *p2m = p2m_get_hostp2m(d); /* Check that there's space on the ring for this request */ - if ( mem_event_check_ring(&d->mem_event, d->domain_id) ) + if ( mem_event_check_ring(&d->mem_paging, d->domain_id) ) return; memset(&req, 0, sizeof(req)); @@ -803,7 +803,7 @@ void p2m_mem_paging_populate(struct doma else if ( p2mt != p2m_ram_paging_out && p2mt != p2m_ram_paged ) { /* gfn is already on its way back and vcpu is not paused */ - mem_event_put_req_producers(&d->mem_event); + mem_event_put_req_producers(&d->mem_paging); return; } @@ -812,7 +812,7 @@ void p2m_mem_paging_populate(struct doma req.p2mt = p2mt; req.vcpu_id = v->vcpu_id; - mem_event_put_request(d, &d->mem_event, &req); + mem_event_put_request(d, &d->mem_paging, &req); } int p2m_mem_paging_prep(struct domain *d, unsigned long gfn) @@ -842,7 +842,7 @@ void p2m_mem_paging_resume(struct domain mfn_t mfn; /* Pull the response off the ring */ - mem_event_get_response(&d->mem_event, &rsp); + mem_event_get_response(&d->mem_paging, &rsp); /* Fix p2m entry if the page was not dropped */ if ( !(rsp.flags & MEM_EVENT_FLAG_DROP_PAGE) ) @@ -889,7 +889,7 @@ void p2m_mem_access_check(unsigned long p2m_unlock(p2m); /* Otherwise, check if there is a memory event listener, and send the message along */ - res = mem_event_check_ring(&d->mem_event, d->domain_id); + res = mem_event_check_ring(&d->mem_access, d->domain_id); if ( res < 0 ) { /* No listener */ @@ -933,7 +933,7 @@ void p2m_mem_access_check(unsigned long req.vcpu_id = v->vcpu_id; - mem_event_put_request(d, &d->mem_event, &req); + mem_event_put_request(d, &d->mem_access, &req); /* VCPU paused, mem event request sent */ } @@ -943,7 +943,7 @@ void p2m_mem_access_resume(struct p2m_do struct domain *d = p2m->domain; mem_event_response_t rsp; - mem_event_get_response(&d->mem_event, &rsp); + mem_event_get_response(&d->mem_access, &rsp); /* Unpause domain */ if ( rsp.flags & MEM_EVENT_FLAG_VCPU_PAUSED ) diff -r 4e7bcc14b76a -r 9b0929f3243c xen/include/public/domctl.h --- a/xen/include/public/domctl.h +++ b/xen/include/public/domctl.h @@ -708,20 +708,18 @@ struct xen_domctl_gdbsx_domstatus { /* XEN_DOMCTL_mem_event_op */ -/* Add and remove memory handlers */ -#define XEN_DOMCTL_MEM_EVENT_OP_ENABLE 0 -#define XEN_DOMCTL_MEM_EVENT_OP_DISABLE 1 - /* +* Domain memory paging * Page memory in and out. */ #define XEN_DOMCTL_MEM_EVENT_OP_PAGING 1 -/* Domain memory paging */ -#define XEN_DOMCTL_MEM_EVENT_OP_PAGING_NOMINATE 0 -#define XEN_DOMCTL_MEM_EVENT_OP_PAGING_EVICT 1 -#define XEN_DOMCTL_MEM_EVENT_OP_PAGING_PREP 2 -#define XEN_DOMCTL_MEM_EVENT_OP_PAGING_RESUME 3 +#define XEN_DOMCTL_MEM_EVENT_OP_PAGING_ENABLE 0 +#define XEN_DOMCTL_MEM_EVENT_OP_PAGING_DISABLE 1 +#define XEN_DOMCTL_MEM_EVENT_OP_PAGING_NOMINATE 2 +#define XEN_DOMCTL_MEM_EVENT_OP_PAGING_EVICT 3 +#define XEN_DOMCTL_MEM_EVENT_OP_PAGING_PREP 4 +#define XEN_DOMCTL_MEM_EVENT_OP_PAGING_RESUME 5 /* * Access permissions. @@ -734,11 +732,14 @@ struct xen_domctl_gdbsx_domstatus { * ACCESS_RESUME mode for the following domctl. */ #define XEN_DOMCTL_MEM_EVENT_OP_ACCESS 2 -#define XEN_DOMCTL_MEM_EVENT_OP_ACCESS_RESUME 0 + +#define XEN_DOMCTL_MEM_EVENT_OP_ACCESS_ENABLE 0 +#define XEN_DOMCTL_MEM_EVENT_OP_ACCESS_DISABLE 1 +#define XEN_DOMCTL_MEM_EVENT_OP_ACCESS_RESUME 2 struct xen_domctl_mem_event_op { - uint32_t op; /* XEN_DOMCTL_MEM_EVENT_OP_* */ - uint32_t mode; /* XEN_DOMCTL_MEM_EVENT_ENABLE_* */ + uint32_t op; /* XEN_DOMCTL_MEM_EVENT_OP_*_* */ + uint32_t mode; /* XEN_DOMCTL_MEM_EVENT_OP_* */ /* OP_ENABLE */ uint64_aligned_t shared_addr; /* IN: Virtual address of shared page */ @@ -755,14 +756,16 @@ DEFINE_XEN_GUEST_HANDLE(xen_domctl_mem_e */ /* XEN_DOMCTL_mem_sharing_op */ -#define XEN_DOMCTL_MEM_SHARING_OP_CONTROL 0 -#define XEN_DOMCTL_MEM_SHARING_OP_NOMINATE_GFN 1 -#define XEN_DOMCTL_MEM_SHARING_OP_NOMINATE_GREF 2 -#define XEN_DOMCTL_MEM_SHARING_OP_SHARE 3 -#define XEN_DOMCTL_MEM_SHARING_OP_RESUME 4 -#define XEN_DOMCTL_MEM_SHARING_OP_DEBUG_GFN 5 -#define XEN_DOMCTL_MEM_SHARING_OP_DEBUG_MFN 6 -#define XEN_DOMCTL_MEM_SHARING_OP_DEBUG_GREF 7 +#define XEN_DOMCTL_MEM_EVENT_OP_SHARING 3 + +#define XEN_DOMCTL_MEM_EVENT_OP_SHARING_CONTROL 0 +#define XEN_DOMCTL_MEM_EVENT_OP_SHARING_NOMINATE_GFN 1 +#define XEN_DOMCTL_MEM_EVENT_OP_SHARING_NOMINATE_GREF 2 +#define XEN_DOMCTL_MEM_EVENT_OP_SHARING_SHARE 3 +#define XEN_DOMCTL_MEM_EVENT_OP_SHARING_RESUME 4 +#define XEN_DOMCTL_MEM_EVENT_OP_SHARING_DEBUG_GFN 5 +#define XEN_DOMCTL_MEM_EVENT_OP_SHARING_DEBUG_MFN 6 +#define XEN_DOMCTL_MEM_EVENT_OP_SHARING_DEBUG_GREF 7 #define XEN_DOMCTL_MEM_SHARING_S_HANDLE_INVALID (-10) #define XEN_DOMCTL_MEM_SHARING_C_HANDLE_INVALID (-9) diff -r 4e7bcc14b76a -r 9b0929f3243c xen/include/xen/sched.h --- a/xen/include/xen/sched.h +++ b/xen/include/xen/sched.h @@ -317,8 +317,12 @@ struct domain /* Non-migratable and non-restoreable? */ bool_t disable_migrate; + /* Memory sharing support */ + struct mem_event_domain mem_share; /* Memory paging support */ - struct mem_event_domain mem_event; + struct mem_event_domain mem_paging; + /* Memory access support */ + struct mem_event_domain mem_access; /* Currently computed from union of all vcpu cpu-affinity masks. */ nodemask_t node_affinity; _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel From xen-devel-bounces@lists.xensource.com Wed Sep 07 05:20:26 2011 Return-path: Envelope-to: www-data@lists.xensource.com Delivery-date: Wed, 07 Sep 2011 05:20:26 -0700 Received: from localhost ([127.0.0.1] helo=lists.colo.xensource.com) by lists.xensource.com with esmtp (Exim 4.43) id 1R1H7C-0007UD-KK; Wed, 07 Sep 2011 05:20:26 -0700 Received: from mail216.messagelabs.com ([85.158.143.99]) by lists.xensource.com with esmtp (Exim 4.43) id 1R1H6a-0007HM-Kr for xen-devel@lists.xensource.com; Wed, 07 Sep 2011 05:19:48 -0700 X-Env-Sender: deepak.s@hcl.com X-Msg-Ref: server-6.tower-216.messagelabs.com!1315397981!16125292!1 X-Originating-IP: [203.105.186.26] X-StarScan-Version: 6.3.6; banners=-,-,- X-VirusChecked: Checked Received: (qmail 30909 invoked from network); 7 Sep 2011 12:19:45 -0000 Received: from gws08.hcl.com (HELO gws08.hcl.com) (203.105.186.26) by server-6.tower-216.messagelabs.com with AES256-SHA encrypted SMTP; 7 Sep 2011 12:19:45 -0000 Received: from CHN-HCLIN-HT04.CORP.HCL.IN (10.249.64.34) by CHN-HCLIN-EDGE4.HCL.COM (10.249.64.141) with Microsoft SMTP Server id 8.2.254.0; Wed, 7 Sep 2011 17:49:23 +0530 Received: from CHN-HCLT-HT03.HCLT.CORP.HCL.IN (10.108.45.35) by CHN-HCLIN-HT04.CORP.HCL.IN (10.249.64.34) with Microsoft SMTP Server (TLS) id 8.2.176.0; Wed, 7 Sep 2011 17:49:39 +0530 Received: from CHN-HCLT-EVS07.HCLT.CORP.HCL.IN ([fe80::f46b:fdf2:3218:985d]) by CHN-HCLT-HT03.HCLT.CORP.HCL.IN ([::1]) with mapi; Wed, 7 Sep 2011 17:49:37 +0530 From: "Deepak Kr. Sharma - ERS, HCL Tech" To: Konrad Rzeszutek Wilk Date: Wed, 7 Sep 2011 17:49:36 +0530 Subject: RE: [Xen-devel] FW: HXEN on linux Thread-Topic: [Xen-devel] FW: HXEN on linux Thread-Index: Acxsr+gmdo8+CiugSkWAJIYSK5o6GwApQJ6g Message-ID: <90F0F47595235141A4380FCF01B0185B2240FEADDE@CHN-HCLT-EVS07.HCLT.CORP.HCL.IN> References: <90F0F47595235141A4380FCF01B0185B20BC426222@CHN-HCLT-EVS07.HCLT.CORP.HCL.IN> <20110809195159.GA7834@dumpdata.com> <90F0F47595235141A4380FCF01B0185B20BC513BCB@CHN-HCLT-EVS07.HCLT.CORP.HCL.IN> <90F0F47595235141A4380FCF01B0185B20BC585A8A@CHN-HCLT-EVS07.HCLT.CORP.HCL.IN> <90F0F47595235141A4380FCF01B0185B20BC608BBC@CHN-HCLT-EVS07.HCLT.CORP.HCL.IN> <20110901134638.GB23971@dumpdata.com> <90F0F47595235141A4380FCF01B0185B2240FEA5E3@CHN-HCLT-EVS07.HCLT.CORP.HCL.IN> <20110906161258.GA5264@dumpdata.com> In-Reply-To: <20110906161258.GA5264@dumpdata.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "todd.deshane.xen@gmail.com" , "xen-devel@lists.xensource.com" , Lars Kurth , Stefano Stabellini X-BeenThere: xen-devel@lists.xensource.com X-Mailman-Version: 2.1.5 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xensource.com Errors-To: xen-devel-bounces@lists.xensource.com Hello Konrad, We are part of COE team and our priorities are driven by team that does tec= hnology tracking (mix of sales and delivery). As recommended by them, Xen i= s type-1 hypervisor and HXen is a type-2 hypervisor. Virtualization in a pr= oduct is a value-add service and not the core product functionality. No one= would want to touch a stable system (which is a must in case of type-1 hyp= ervisor) for a value-add service. Hence, HXen gives flexibility to add feat= ures on VM w/o impacting product's core functionality. The biggest benefit = with HXen is that it can be ported to any other OS without any changes to t= he stable system. Please let me know in case you have any other questions. I would appreciate your and others' inputs and guidance on the analysis tha= t I had sent last week. Regards, Deepak -----Original Message----- From: Konrad Rzeszutek Wilk [mailto:konrad.wilk@oracle.com] Sent: 06 September 2011 21:43 To: Deepak Kr. Sharma - ERS, HCL Tech Cc: Stefano Stabellini; todd.deshane.xen@gmail.com; xen-devel@lists.xensour= ce.com; Lars Kurth Subject: Re: [Xen-devel] FW: HXEN on linux On Mon, Sep 05, 2011 at 12:43:19PM +0530, Deepak Kr. Sharma - ERS, HCL Tec= h wrote: > Hello Konrad, > > We want to build expertise in virtualization domain and contribute to ope= n source community. > > We have used Xen as type-1 hypervisor and the performance is unprecedente= d. We see good potential in HXen as a type-2 hypervisor and some good solut= ions can be built around it on linux based platforms. "good solutions" .. such as? I am just trying to wrap my mind around why you would do this extra work instead of doing it in the Xen hype= rvisor and expanding what it can do? ::DISCLAIMER:: ---------------------------------------------------------------------------= -------------------------------------------- The contents of this e-mail and any attachment(s) are confidential and inte= nded for the named recipient(s) only. It shall not attach any liability on the originator or HCL or its affiliate= s. Any views or opinions presented in this email are solely those of the author and may not necessarily reflect t= he opinions of HCL or its affiliates. Any form of reproduction, dissemination, copying, disclosure, modification,= distribution and / or publication of this message without the prior written consent of the author of this e-mail= is strictly prohibited. If you have received this email in error please delete it and notify the sender immedia= tely. Before opening any mail and attachments please check them for viruses and defect. ---------------------------------------------------------------------------= -------------------------------------------- _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel From xen-devel-bounces@lists.xensource.com Wed Sep 07 05:26:47 2011 Return-path: Envelope-to: www-data@lists.xensource.com Delivery-date: Wed, 07 Sep 2011 05:26:47 -0700 Received: from localhost ([127.0.0.1] helo=lists.colo.xensource.com) by lists.xensource.com with esmtp (Exim 4.43) id 1R1HDL-0007w2-Dx; Wed, 07 Sep 2011 05:26:47 -0700 Received: from mail174.messagelabs.com ([85.158.138.51]) by lists.xensource.com with esmtp (Exim 4.43) id 1R1HCl-0007jt-FA for xen-devel@lists.xensource.com; Wed, 07 Sep 2011 05:26:11 -0700 X-Env-Sender: komkon555@freenet.de X-Msg-Ref: server-5.tower-174.messagelabs.com!1315398361!26860404!1 X-Originating-IP: [216.139.236.26] X-StarScan-Version: 6.3.6; banners=-,-,- X-VirusChecked: Checked Received: (qmail 31623 invoked from network); 7 Sep 2011 12:26:05 -0000 Received: from sam.nabble.com (HELO sam.nabble.com) (216.139.236.26) by server-5.tower-174.messagelabs.com with AES256-SHA encrypted SMTP; 7 Sep 2011 12:26:05 -0000 Received: from [192.168.236.26] (helo=sam.nabble.com) by sam.nabble.com with esmtp (Exim 4.72) (envelope-from ) id 1R1HCa-00047Q-Mf for xen-devel@lists.xensource.com; Wed, 07 Sep 2011 05:26:00 -0700 Date: Wed, 7 Sep 2011 05:26:00 -0700 (PDT) From: komkon555 To: xen-devel@lists.xensource.com Message-ID: <1315398360680-4778339.post@n5.nabble.com> In-Reply-To: <1315389138.56652.YahooMailNeo@web29801.mail.ird.yahoo.com> References: <1314778567400-4753326.post@n5.nabble.com> <20110831083832.GD7276@reaktio.net> <1314780568949-4753422.post@n5.nabble.com> <1314795401771-4754024.post@n5.nabble.com> <20110831151913.GE7276@reaktio.net> <1315231341254-4770602.post@n5.nabble.com> <1315310225039-4774097.post@n5.nabble.com> <1315343879.61837.YahooMailNeo@web29818.mail.ird.yahoo.com> <1315382742268-4777689.post@n5.nabble.com> <1315389138.56652.YahooMailNeo@web29801.mail.ird.yahoo.com> Subject: Re: Re : Re : [Xen-devel] Re: Patches for VGA-Passthrough XEN 4.2 unstable MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-BeenThere: xen-devel@lists.xensource.com X-Mailman-Version: 2.1.5 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xensource.com Errors-To: xen-devel-bounces@lists.xensource.com Perfect, with the latest fixes and configurations it works! I can run dxdiag and see all tests functional. Important is, that cuda-programming is also functional (is what I exactly need). Thank you a lot! The next problem is how to pass through the second (third, fourth) nvidia card to the next one Windows-VM? For me is most impotent to get 4 separate CUDA/OpenCL programming areas. Have you any ideas? Tanks Komkon555 -- View this message in context: http://xen.1045712.n5.nabble.com/Patches-for-VGA-Passthrough-XEN-4-2-unstable-tp4406265p4778339.html Sent from the Xen - Dev mailing list archive at Nabble.com. _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel From xen-devel-bounces@lists.xensource.com Wed Sep 07 05:29:56 2011 Return-path: Envelope-to: www-data@lists.xensource.com Delivery-date: Wed, 07 Sep 2011 05:29:56 -0700 Received: from localhost ([127.0.0.1] helo=lists.colo.xensource.com) by lists.xensource.com with esmtp (Exim 4.43) id 1R1HGO-0008Kj-DV; Wed, 07 Sep 2011 05:29:56 -0700 Received: from mail174.messagelabs.com ([85.158.138.51]) by lists.xensource.com with esmtp (Exim 4.43) id 1R1HFj-00088c-TV for xen-devel@lists.xensource.com; Wed, 07 Sep 2011 05:29:16 -0700 X-Env-Sender: konrad@dumpdata.com X-Msg-Ref: server-2.tower-174.messagelabs.com!1315398549!30562530!1 X-Originating-IP: [141.146.126.227] X-StarScan-Version: 6.3.6; banners=-,-,- X-VirusChecked: Checked Received: (qmail 7604 invoked from network); 7 Sep 2011 12:29:12 -0000 Received: from acsinet15.oracle.com (HELO acsinet15.oracle.com) (141.146.126.227) by server-2.tower-174.messagelabs.com with DHE-RSA-AES256-SHA encrypted SMTP; 7 Sep 2011 12:29:12 -0000 Received: from rtcsinet21.oracle.com (rtcsinet21.oracle.com [66.248.204.29]) by acsinet15.oracle.com (Switch-3.4.4/Switch-3.4.4) with ESMTP id p87CT57K019558 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Wed, 7 Sep 2011 12:29:07 GMT Received: from acsmt358.oracle.com (acsmt358.oracle.com [141.146.40.158]) by rtcsinet21.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id p87CT4c5027096 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 7 Sep 2011 12:29:05 GMT Received: from abhmt112.oracle.com (abhmt112.oracle.com [141.146.116.64]) by acsmt358.oracle.com (8.12.11.20060308/8.12.11) with ESMTP id p87CSwIt018578; Wed, 7 Sep 2011 07:28:58 -0500 Received: from phenom (/209.6.55.207) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Wed, 07 Sep 2011 05:28:57 -0700 Received: by phenom (Postfix, from userid 1000) id 06CD2E45; Wed, 7 Sep 2011 08:28:44 -0400 (EDT) Date: Wed, 7 Sep 2011 08:28:44 -0400 From: Konrad Rzeszutek Wilk To: David Vrabel Message-ID: <20110907122844.GA31987@dumpdata.com> References: <1313765840-22084-1-git-send-email-david.vrabel@citrix.com> <1313765840-22084-5-git-send-email-david.vrabel@citrix.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <1313765840-22084-5-git-send-email-david.vrabel@citrix.com> User-Agent: Mutt/1.5.21 (2010-09-15) X-Source-IP: rtcsinet21.oracle.com [66.248.204.29] X-CT-RefId: str=0001.0A090208.4E676394.0035,ss=1,re=-2.300,fgs=0 Cc: xen-devel@lists.xensource.com Subject: [Xen-devel] Re: [PATCH 4/5] xen: allow extra memory to be in multiple regions X-BeenThere: xen-devel@lists.xensource.com X-Mailman-Version: 2.1.5 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xensource.com Errors-To: xen-devel-bounces@lists.xensource.com On Fri, Aug 19, 2011 at 03:57:19PM +0100, David Vrabel wrote: > Allow the extra memory (used by the balloon driver) to be in multiple > regions regions (typically two regions, one for low memory and one for > high memory). This allows the balloon driver to increase the number > of available low pages (if the initial number if pages is small). > > As a side effect, the algorithm for building the e820 memory map is > simpler and more obviously correct as the map supplied by the > hypervisor is (almost) used as is (in particular, all reserved regions > and gaps are preserved). Only RAM regions are altered and RAM regions > above max_pfn + extra_pages are marked as unused (the region is split > in two if necessary). > > Signed-off-by: David Vrabel > --- > arch/x86/xen/setup.c | 155 ++++++++++++++++++++++---------------------------- > 1 files changed, 67 insertions(+), 88 deletions(-) > > diff --git a/arch/x86/xen/setup.c b/arch/x86/xen/setup.c > index 4720c2d..93e4542 100644 > --- a/arch/x86/xen/setup.c > +++ b/arch/x86/xen/setup.c > @@ -51,23 +51,29 @@ struct xen_memory_region xen_extra_mem[XEN_EXTRA_MEM_MAX_REGIONS] __initdata; > */ > #define EXTRA_MEM_RATIO (10) > > -static void __init xen_add_extra_mem(unsigned long pages) > +static void __init xen_add_extra_mem(u64 extra_start, u64 size) > { > unsigned long pfn; > + int i; > > - u64 size = (u64)pages * PAGE_SIZE; > - u64 extra_start = xen_extra_mem[0].start + xen_extra_mem[0].size; > - > - if (!pages) > - return; > - > - e820_add_region(extra_start, size, E820_RAM); > - sanitize_e820_map(e820.map, ARRAY_SIZE(e820.map), &e820.nr_map); > + for (i = 0; i < XEN_EXTRA_MEM_MAX_REGIONS; i++) { > + /* Add new region. */ > + if (xen_extra_mem[i].size == 0) { > + xen_extra_mem[i].start = extra_start; > + xen_extra_mem[i].size = size; > + break; > + } > + /* Append to existing region. */ > + if (xen_extra_mem[i].start + xen_extra_mem[i].size == extra_start) { > + xen_extra_mem[i].size += size; > + break; > + } > + } > + if (i == XEN_EXTRA_MEM_MAX_REGIONS) > + printk(KERN_WARNING "Warning: not enough extra memory regions\n"); > > memblock_x86_reserve_range(extra_start, extra_start + size, "XEN EXTRA"); > > - xen_extra_mem[0].size += size; > - > xen_max_p2m_pfn = PFN_DOWN(extra_start + size); > > for (pfn = PFN_DOWN(extra_start); pfn <= xen_max_p2m_pfn; pfn++) > @@ -118,7 +124,8 @@ static unsigned long __init xen_release_chunk(phys_addr_t start_addr, > } > > static unsigned long __init xen_return_unused_memory(unsigned long max_pfn, > - const struct e820map *e820) > + const struct e820entry *map, > + int nr_map) > { > phys_addr_t max_addr = PFN_PHYS(max_pfn); > phys_addr_t last_end = ISA_END_ADDRESS; > @@ -126,13 +133,13 @@ static unsigned long __init xen_return_unused_memory(unsigned long max_pfn, > int i; > > /* Free any unused memory above the low 1Mbyte. */ > - for (i = 0; i < e820->nr_map && last_end < max_addr; i++) { > - phys_addr_t end = e820->map[i].addr; > + for (i = 0; i < nr_map && last_end < max_addr; i++) { > + phys_addr_t end = map[i].addr; > end = min(max_addr, end); > > if (last_end < end) > released += xen_release_chunk(last_end, end); > - last_end = max(last_end, e820->map[i].addr + e820->map[i].size); > + last_end = max(last_end, map[i].addr + map[i].size); > } > > if (last_end < max_addr) > @@ -203,14 +210,13 @@ static unsigned long __init xen_get_max_pages(void) > char * __init xen_memory_setup(void) > { > static struct e820entry map[E820MAX] __initdata; > - static struct e820entry map_raw[E820MAX] __initdata; > > unsigned long max_pfn = xen_start_info->nr_pages; > unsigned long long mem_end; > int rc; > struct xen_memory_map memmap; > + unsigned long max_pages; > unsigned long extra_pages = 0; > - unsigned long extra_limit; > unsigned long identity_pages = 0; > int i; > int op; > @@ -237,49 +243,52 @@ char * __init xen_memory_setup(void) > } > BUG_ON(rc); > > - memcpy(map_raw, map, sizeof(map)); > - e820.nr_map = 0; > - xen_extra_mem[0].start = mem_end; > - for (i = 0; i < memmap.nr_entries; i++) { > - unsigned long long end; > - > - /* Guard against non-page aligned E820 entries. */ > - if (map[i].type == E820_RAM) > - map[i].size -= (map[i].size + map[i].addr) % PAGE_SIZE; > - > - end = map[i].addr + map[i].size; > - if (map[i].type == E820_RAM && end > mem_end) { > - /* RAM off the end - may be partially included */ > - u64 delta = min(map[i].size, end - mem_end); > - > - map[i].size -= delta; > - end -= delta; > - > - extra_pages += PFN_DOWN(delta); > - /* > - * Set RAM below 4GB that is not for us to be unusable. > - * This prevents "System RAM" address space from being > - * used as potential resource for I/O address (happens > - * when 'allocate_resource' is called). > - */ > - if (delta && > - (xen_initial_domain() && end < 0x100000000ULL)) > - e820_add_region(end, delta, E820_UNUSABLE); > + /* Make sure the Xen-supplied memory map is well-ordered. */ > + sanitize_e820_map(map, memmap.nr_entries, &memmap.nr_entries); > + > + max_pages = xen_get_max_pages(); > + if (max_pages > max_pfn) > + extra_pages += max_pages - max_pfn; > + > + extra_pages += xen_return_unused_memory(max_pfn, map, memmap.nr_entries); > + > + /* > + * Clamp the amount of extra memory to a EXTRA_MEM_RATIO > + * factor the base size. On non-highmem systems, the base > + * size is the full initial memory allocation; on highmem it > + * is limited to the max size of lowmem, so that it doesn't > + * get completely filled. > + * > + * In principle there could be a problem in lowmem systems if > + * the initial memory is also very large with respect to > + * lowmem, but we won't try to deal with that here. > + */ > + extra_pages = min(EXTRA_MEM_RATIO * min(max_pfn, PFN_DOWN(MAXMEM)), extra_pages); > + > + i = 0; > + while (i < memmap.nr_entries) { > + u64 addr = map[i].addr; > + u64 size = map[i].size; > + u32 type = map[i].type; > + > + if (type == E820_RAM) { > + if (addr < mem_end) { > + size = min(size, mem_end - addr); You removed this little alignmend issue we found on Dell Inspiron laptops: /* Guard against non-page aligned E820 entries. */ if (map[i].type == E820_RAM) map[i].size -= (map[i].size + map[i].addr) % PAGE_SIZE; end = map[i].addr + map[i].size; Without it we end up dying later on when NUMA was turned on as it tried to use two pages and "half" of the last page was not RAM and it ended up going belly up. We need to make sure that the "end" (and the "beginning") of the E820 entry is page aligned. > + } else if (extra_pages) { > + size = min(size, (u64)extra_pages * PAGE_SIZE); > + extra_pages -= size / PAGE_SIZE; Those operations can be done using << and >> (using PAGE_SHIFT) respectivly. > + xen_add_extra_mem(addr, size); > + } else > + type = E820_UNUSABLE; > } > > - if (map[i].size > 0 && end > xen_extra_mem[0].start) > - xen_extra_mem[0].start = end; > + e820_add_region(addr, size, type); > > - /* Add region if any remains */ > - if (map[i].size > 0) > - e820_add_region(map[i].addr, map[i].size, map[i].type); > + map[i].addr += size; > + map[i].size -= size; > + if (map[i].size == 0) > + i++; > } > - /* Align the balloon area so that max_low_pfn does not get set > - * to be at the _end_ of the PCI gap at the far end (fee01000). > - * Note that the start of balloon area gets set in the loop above > - * to be past the last E820 region. */ > - if (xen_initial_domain() && (xen_extra_mem[0].start < (1ULL<<32))) > - xen_extra_mem[0].start = (1ULL<<32); I think this issue is not present with your patch - but just to be on the safe side you might want to ask Stefano to use his box where he found the issue originally. > > /* > * In domU, the ISA region is normal, usable memory, but we > @@ -305,41 +314,11 @@ char * __init xen_memory_setup(void) > > sanitize_e820_map(e820.map, ARRAY_SIZE(e820.map), &e820.nr_map); > > - extra_limit = xen_get_max_pages(); > - if (extra_limit >= max_pfn) > - extra_pages = extra_limit - max_pfn; > - else > - extra_pages = 0; > - > - extra_pages += xen_return_unused_memory(xen_start_info->nr_pages, &e820); > - > - /* > - * Clamp the amount of extra memory to a EXTRA_MEM_RATIO > - * factor the base size. On non-highmem systems, the base > - * size is the full initial memory allocation; on highmem it > - * is limited to the max size of lowmem, so that it doesn't > - * get completely filled. > - * > - * In principle there could be a problem in lowmem systems if > - * the initial memory is also very large with respect to > - * lowmem, but we won't try to deal with that here. > - */ > - extra_limit = min(EXTRA_MEM_RATIO * min(max_pfn, PFN_DOWN(MAXMEM)), > - max_pfn + extra_pages); > - > - if (extra_limit >= max_pfn) > - extra_pages = extra_limit - max_pfn; > - else > - extra_pages = 0; > - > - xen_add_extra_mem(extra_pages); > - > /* > * Set P2M for all non-RAM pages and E820 gaps to be identity > - * type PFNs. We supply it with the non-sanitized version > - * of the E820. > + * type PFNs. > */ > - identity_pages = xen_set_identity(map_raw, memmap.nr_entries); > + identity_pages = xen_set_identity(e820.map, e820.nr_map); > printk(KERN_INFO "Set %ld page(s) to 1-1 mapping.\n", identity_pages); > return "Xen"; > } > -- > 1.7.2.5 _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel From xen-devel-bounces@lists.xensource.com Wed Sep 07 05:30:53 2011 Return-path: Envelope-to: www-data@lists.xensource.com Delivery-date: Wed, 07 Sep 2011 05:30:53 -0700 Received: from localhost ([127.0.0.1] helo=lists.colo.xensource.com) by lists.xensource.com with esmtp (Exim 4.43) id 1R1HHI-0000GJ-Vw; Wed, 07 Sep 2011 05:30:53 -0700 Received: from mail174.messagelabs.com ([85.158.138.51]) by lists.xensource.com with smtp (Exim 4.43) id 1R1HGc-0008Pc-18 for xen-devel@lists.xensource.com; Wed, 07 Sep 2011 05:30:12 -0700 X-Env-Sender: anthony@overnetdata.com X-Msg-Ref: server-6.tower-174.messagelabs.com!1315398605!28423726!1 X-Originating-IP: [81.137.131.225] X-StarScan-Version: 6.3.6; banners=-,-,- X-VirusChecked: Checked Received: (qmail 5115 invoked from network); 7 Sep 2011 12:30:05 -0000 Received: from host81-137-131-225.in-addr.btopenworld.com (HELO zimbra.overnetdata.com) (81.137.131.225) by server-6.tower-174.messagelabs.com with SMTP; 7 Sep 2011 12:30:05 -0000 Received: from localhost (localhost.localdomain [127.0.0.1]) by zimbra.overnetdata.com (Postfix) with ESMTP id 04B23161587; Wed, 7 Sep 2011 13:29:48 +0100 (BST) X-Virus-Scanned: amavisd-new at overnetdata.com Received: from zimbra.overnetdata.com ([127.0.0.1]) by localhost (zimbra.overnetdata.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id iBREWoyFwCQc; Wed, 7 Sep 2011 13:29:46 +0100 (BST) Received: from [192.168.1.54] (unknown [192.168.1.54]) by zimbra.overnetdata.com (Postfix) with ESMTPSA id 405C716157E; Wed, 7 Sep 2011 13:29:46 +0100 (BST) Message-ID: <4E6763B5.40209@overnetdata.com> Date: Wed, 07 Sep 2011 13:29:41 +0100 From: Anthony Wright User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:6.0.1) Gecko/20110830 Thunderbird/6.0.1 MIME-Version: 1.0 To: Konrad Rzeszutek Wilk Subject: Re: [Xen-devel] VM hangs during boot on 3.0.4 dom0 kernel, works on alternative hardware References: <4E64A4F4.1040402@overnetdata.com> <20110906161638.GB5264@dumpdata.com> In-Reply-To: <20110906161638.GB5264@dumpdata.com> X-Enigmail-Version: 1.3.1 Content-Type: multipart/mixed; boundary="------------020606070606080001040109" Cc: "xen-devel@lists.xensource.com" X-BeenThere: xen-devel@lists.xensource.com X-Mailman-Version: 2.1.5 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xensource.com Errors-To: xen-devel-bounces@lists.xensource.com This is a multi-part message in MIME format. --------------020606070606080001040109 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit On 06/09/2011 17:16, Konrad Rzeszutek Wilk wrote: > On Mon, Sep 05, 2011 at 11:31:16AM +0100, Anthony Wright wrote: >> I have two machines with identical Dom0's and DomUs, but different >> hardware. The Dom0 has a patch which I produced myself based on the "Re: >> [Xen-devel] Kernel bug from 3.0 (was phy disks and vifs timing out in >> DomU)" thread. The patch calls vmalloc_sync_all after every >> alloc_vm_area, and I realise this isn't the best solution, but it >> allowed me to move forward. > >> The patch fixes the problem I had on one machine, so that now the VMs >> boot correctly, but I have another system with an identical setup >> (identical Dom0 & DomU kernels, identical startup for DomU) and the VM >> fails to start. I have attached a copy of the console log from the good >> VM and the bad VM. > And what does the dom0 and xen hypervisor log give you? Not a lot, I've attached good/bad dmesg & xend.logs, but I can't see much indicative in them, other than some errors about L1 entries in the good dmesg log which I believe are related to the bug with I patched (I'll report in other thread). > It looks to be hanging at identifying the CPU - is the hardware > quite different from one setup to another? Have you toyed with > using the cpuid flag in the guest to mimic the lowest CPU type? Yes the hardware is quite a lot different. I've had a good look at the cpuid flag, found the cpuid utility & wikipedia page, but I can't find much documentation on the xen cpuid parameter other than some fairly arcane entries in xmexample.hvm. The cpuid utility produces output in hex, while the cpuid flag wants input in binary (with extra controls). Is there any formal documentation that describes cpuid, or an easy way to generate cpuid parameter values? Also my DomU is PV rather than HVM and I see that cpuid is only in HVM xmexample files. Is this just a coincidence or is cpuid a HVM only feature? thanks, Anthony. --------------020606070606080001040109 Content-Type: text/plain; charset=UTF-8; name="bad-dmesg.log" Content-Transfer-Encoding: 8bit Content-Disposition: attachment; filename="bad-dmesg.log" __ __ _ _ _ _ \ \/ /___ _ __ | || | / | / | \ // _ \ '_ \ | || |_ | | | | / \ __/ | | | |__ _|| |_| | /_/\_\___|_| |_| |_|(_)_(_)_| (XEN) Xen version 4.1.1 (@[unknown]) (gcc version 4.4.3 (GCC) ) Tue Aug 30 19:32:56 GMT 2011 (XEN) Latest ChangeSet: unavailable (XEN) Bootloader: GNU GRUB 0.97 (XEN) Command line: dom0_mem=700M sched=credit (XEN) Video information: (XEN) VGA is text mode 80x25, font 8x16 (XEN) VBE/DDC methods: none; EDID transfer time: 2 seconds (XEN) EDID info not retrieved because no DDC retrieval method detected (XEN) Disc information: (XEN) Found 1 MBR signatures (XEN) Found 1 EDD information structures (XEN) WARNING: Only the first 16 GB of the physical memory map can be accessed by Xen in 32-bit mode. (XEN) Truncating RAM from 17301500kB to 16777216kB (XEN) Xen-e820 RAM map: (XEN) 0000000000000000 - 000000000009f400 (usable) (XEN) 000000000009f400 - 00000000000a0000 (reserved) (XEN) 00000000000f0000 - 0000000000100000 (reserved) (XEN) 0000000000100000 - 00000000df62f000 (usable) (XEN) 00000000df62f000 - 00000000df63c000 (ACPI data) (XEN) 00000000df63c000 - 00000000df63d000 (usable) (XEN) 00000000df63d000 - 00000000e4000000 (reserved) (XEN) 00000000fec00000 - 00000000fee10000 (reserved) (XEN) 00000000ff800000 - 0000000100000000 (reserved) (XEN) 0000000100000000 - 0000000400000000 (usable) (XEN) 0000000400000000 - 000000041ffff000 (unusable) (XEN) System RAM: 15861MB (16242492kB) (XEN) ACPI: RSDP 000F4F00, 0024 (r2 HP ) (XEN) ACPI: XSDT DF630140, 00B4 (r1 HP ProLiant 2 � 162E) (XEN) ACPI: FACP DF630240, 00F4 (r3 HP ProLiant 2 � 162E) (XEN) ACPI: DSDT DF630340, 20BD (r1 HP DSDT 1 INTL 20030228) (XEN) ACPI: FACS DF62F100, 0040 (XEN) ACPI: SPCR DF62F140, 0050 (r1 HP SPCRRBSU 1 � 162E) (XEN) ACPI: MCFG DF62F1C0, 003C (r1 HP ProLiant 1 0) (XEN) ACPI: HPET DF62F200, 0038 (r1 HP ProLiant 2 � 162E) (XEN) ACPI: FFFF DF62F240, 0064 (r2 HP ProLiant 2 � 162E) (XEN) ACPI: SPMI DF62F2C0, 0040 (r5 HP ProLiant 1 � 162E) (XEN) ACPI: ERST DF62F300, 01D0 (r1 HP ProLiant 1 � 162E) (XEN) ACPI: APIC DF62F500, 015E (r1 HP ProLiant 2 0) (XEN) ACPI: SRAT DF62F680, 0570 (r1 HP Proliant 1 � 162E) (XEN) ACPI: FFFF DF62FC00, 0176 (r1 HP ProLiant 1 � 162E) (XEN) ACPI: BERT DF62FD80, 0030 (r1 HP ProLiant 1 � 162E) (XEN) ACPI: HEST DF62FDC0, 00BC (r1 HP ProLiant 1 � 162E) (XEN) ACPI: DMAR DF62FE80, 013C (r1 HP ProLiant 1 � 162E) (XEN) ACPI: SSDT DF632400, 0125 (r3 HP CRSPCI0 2 HP 1) (XEN) ACPI: SSDT DF632540, 01CF (r3 HP riser1a 2 INTL 20061109) (XEN) ACPI: SSDT DF632740, 03BB (r1 HP pcc 1 INTL 20090625) (XEN) ACPI: SSDT DF632B00, 0377 (r1 HP pmab 1 INTL 20090625) (XEN) ACPI: SSDT DF632E80, 2B64 (r1 INTEL PPM RCM 1 INTL 20061109) (XEN) Xen heap: 9MB (9788kB) (XEN) Domain heap initialised DMA width 31 bits (XEN) Processor #0 6:12 APIC version 21 (XEN) Processor #32 6:12 APIC version 21 (XEN) Processor #20 6:12 APIC version 21 (XEN) Processor #52 6:12 APIC version 21 (XEN) Processor #2 6:12 APIC version 21 (XEN) Processor #34 6:12 APIC version 21 (XEN) Processor #18 6:12 APIC version 21 (XEN) Processor #50 6:12 APIC version 21 (XEN) Processor #1 6:12 APIC version 21 (XEN) Processor #33 6:12 APIC version 21 (XEN) Processor #21 6:12 APIC version 21 (XEN) Processor #53 6:12 APIC version 21 (XEN) Processor #3 6:12 APIC version 21 (XEN) Processor #35 6:12 APIC version 21 (XEN) Processor #19 6:12 APIC version 21 (XEN) Processor #51 6:12 APIC version 21 (XEN) IOAPIC[0]: apic_id 8, version 32, address 0xfec00000, GSI 0-23 (XEN) IOAPIC[1]: apic_id 0, version 32, address 0xfec80000, GSI 24-47 (XEN) Enabling APIC mode: Phys. Using 2 I/O APICs (XEN) ERST table is invalid (XEN) Using scheduler: SMP Credit Scheduler (credit) (XEN) Detected 2533.500 MHz processor. (XEN) Intel VT-d Snoop Control not enabled. (XEN) Intel VT-d Dom0 DMA Passthrough not enabled. (XEN) Intel VT-d Queued Invalidation enabled. (XEN) Intel VT-d Interrupt Remapping enabled. (XEN) Intel VT-d Shared EPT tables not enabled. (XEN) I/O virtualisation enabled (XEN) - Dom0 mode: Relaxed (XEN) Enabled directed EOI with ioapic_ack_old on! (XEN) ENABLING IO-APIC IRQs (XEN) -> Using old ACK method (XEN) Platform timer is 14.318MHz HPET (XEN) Allocated console ring of 32 KiB. (XEN) VMX: Supported advanced features: (XEN) - APIC MMIO access virtualisation (XEN) - APIC TPR shadow (XEN) - Extended Page Tables (EPT) (XEN) - Virtual-Processor Identifiers (VPID) (XEN) - Virtual NMI (XEN) - MSR direct-access bitmap (XEN) - Unrestricted Guest (XEN) EPT supports 1GB super page. (XEN) EPT supports 2MB super page. (XEN) HVM: ASIDs enabled. (XEN) HVM: VMX enabled (XEN) HVM: Hardware Assisted Paging detected. (XEN) Brought up 16 CPUs (XEN) *** LOADING DOMAIN 0 *** (XEN) Xen kernel: 32-bit, PAE, lsb (XEN) Dom0 kernel: 32-bit, PAE, lsb, paddr 0x400000 -> 0x1780000 (XEN) PHYSICAL MEMORY ARRANGEMENT: (XEN) Dom0 alloc.: 00000003f6000000->00000003f8000000 (170025 pages to be allocated) (XEN) Init. ramdisk: 00000003ffc29000->00000003fffff600 (XEN) VIRTUAL MEMORY ARRANGEMENT: (XEN) Loaded kernel: c0400000->c1780000 (XEN) Init. ramdisk: c1780000->c1b56600 (XEN) Phys-Mach map: c1b57000->c1c06000 (XEN) Start info: c1c06000->c1c0647c (XEN) Page tables: c1c07000->c1c1c000 (XEN) Boot stack: c1c1c000->c1c1d000 (XEN) TOTAL: c0000000->c2000000 (XEN) ENTRY ADDRESS: c13d9000 (XEN) Dom0 has maximum 16 VCPUs (XEN) Scrubbing Free RAM: .....................................................................................................................................................done. (XEN) Xen trace buffers: disabled (XEN) Std. Loglevel: Errors and warnings (XEN) Guest Loglevel: Nothing (Rate-limited: Errors and warnings) (XEN) Xen is relinquishing VGA console. (XEN) *** Serial input -> DOM0 (type 'CTRL-a' three times to switch input to Xen) (XEN) Freed 188kB init memory. --------------020606070606080001040109 Content-Type: text/plain; name="bad-xend.log" Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename="bad-xend.log" [2011-09-07 11:15:10 3517] INFO (SrvDaemon:332) Xend Daemon started [2011-09-07 11:15:10 3517] INFO (SrvDaemon:336) Xend changeset: unavailable. [2011-09-07 11:15:10 3517] DEBUG (tcp:96) Listening on :8002 [2011-09-07 11:15:11 3517] DEBUG (XendNode:332) pscsi record count: 8 [2011-09-07 11:15:11 3517] DEBUG (XendCPUPool:747) recreate_active_pools [2011-09-07 11:15:12 3517] DEBUG (XendDomainInfo:151) XendDomainInfo.recreate({'max_vcpu_id': 15, 'cpu_time': 9593074214L, 'ssidref': 0, 'hvm': 0, 'shutdown_reason': 255, 'dying': 0, 'online_vcpus': 8, 'domid': 0, 'paused': 0, 'crashed': 0, 'running': 1, 'maxmem_kb': 4294967292L, 'shutdown': 0, 'mem_kb': 716800L, 'blocked': 0, 'handle': [0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0], 'cpupool': 0, 'name': 'Domain-0'}) [2011-09-07 11:15:12 3517] INFO (XendDomainInfo:168) Recreating domain 0, UUID 00000000-0000-0000-0000-000000000000. at /local/domain/0 [2011-09-07 11:15:12 3517] DEBUG (XendDomainInfo:3420) Storing VM details: {'on_xend_stop': 'ignore', 'pool_name': 'Pool-0', 'shadow_memory': '0', 'uuid': '00000000-0000-0000-0000-000000000000', 'on_reboot': 'restart', 'image': "(linux (kernel '') (superpages 0) (tsc_mode 0) (nomigrate 0))", 'on_poweroff': 'destroy', 'bootloader_args': '', 'on_xend_start': 'ignore', 'on_crash': 'restart', 'xend/restart_count': '0', 'vcpus': '8', 'vcpu_avail': '255', 'bootloader': '', 'name': 'Domain-0'} [2011-09-07 11:15:12 3517] DEBUG (XendDomainInfo:1794) Storing domain details: {'cpu/3/availability': 'online', 'description': '', 'console/limit': '1048576', 'memory/target': '716800', 'cpu/2/availability': 'online', 'vm': '/vm/00000000-0000-0000-0000-000000000000', 'domid': '0', 'cpu/7/availability': 'online', 'cpu/0/availability': 'online', 'cpu/1/availability': 'online', 'cpu/5/availability': 'online', 'control/platform-feature-multiprocessor-suspend': '1', 'cpu/6/availability': 'online', 'console/type': 'xenconsoled', 'cpu/4/availability': 'online', 'name': 'Domain-0'} [2011-09-07 11:15:12 3517] DEBUG (XendDomain:476) Adding Domain: 0 [2011-09-07 11:15:12 3517] DEBUG (XendDomain:410) number of vcpus to use is 0 [2011-09-07 11:15:12 3517] DEBUG (XendDomainInfo:1881) XendDomainInfo.handleShutdownWatch [2011-09-07 11:15:12 3517] WARNING (XendAPI:708) API call: VBD.set_device not found [2011-09-07 11:15:12 3517] WARNING (XendAPI:708) API call: VBD.set_type not found [2011-09-07 11:15:12 3517] WARNING (XendAPI:708) API call: session.get_all_records not found [2011-09-07 11:15:12 3517] WARNING (XendAPI:708) API call: event.get_record not found [2011-09-07 11:15:12 3517] WARNING (XendAPI:708) API call: event.get_all not found [2011-09-07 11:15:12 3517] WARNING (XendAPI:708) API call: VIF.set_device not found [2011-09-07 11:15:12 3517] WARNING (XendAPI:708) API call: VIF.set_MAC not found [2011-09-07 11:15:12 3517] WARNING (XendAPI:708) API call: VIF.set_MTU not found [2011-09-07 11:15:12 3517] WARNING (XendAPI:708) API call: debug.get_all not found [2011-09-07 11:15:12 3517] INFO (XMLRPCServer:161) Opening Unix domain socket XML-RPC server on /var/run/xend/xen-api.sock; authentication has been disabled for this server. [2011-09-07 11:15:12 3517] INFO (XMLRPCServer:161) Opening Unix domain socket XML-RPC server on /var/run/xend/xmlrpc.sock. [2011-09-07 11:15:27 3517] DEBUG (XendDomainInfo:151) XendDomainInfo.recreate({'max_vcpu_id': 0, 'cpu_time': 0L, 'ssidref': 0, 'hvm': 0, 'shutdown_reason': 255, 'dying': 0, 'online_vcpus': 1, 'domid': 1, 'paused': 1, 'crashed': 0, 'running': 0, 'maxmem_kb': 1025024L, 'shutdown': 0, 'mem_kb': 1024000L, 'handle': [234, 214, 244, 133, 57, 196, 77, 174, 191, 128, 243, 52, 17, 90, 250, 59], 'blocked': 0, 'cpupool': 0}) [2011-09-07 11:15:27 3517] INFO (XendDomainInfo:168) Recreating domain 1, UUID ead6f485-39c4-4dae-bf80-f334115afa3b. at /local/domain/1 [2011-09-07 11:15:27 3517] DEBUG (XendDomain:476) Adding Domain: 1 [2011-09-07 11:15:27 3517] DEBUG (XendDomainInfo:1881) XendDomainInfo.handleShutdownWatch --------------020606070606080001040109 Content-Type: text/plain; name="good-dmesg.log" Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename="good-dmesg.log" __ __ _ _ _ _ \ \/ /___ _ __ | || | / | / | \ // _ \ '_ \ | || |_ | | | | / \ __/ | | | |__ _|| |_| | /_/\_\___|_| |_| |_|(_)_(_)_| (XEN) Xen version 4.1.1 (@[unknown]) (gcc version 4.4.3 (GCC) ) Tue Aug 30 19:32:56 GMT 2011 (XEN) Latest ChangeSet: unavailable (XEN) Bootloader: GNU GRUB 0.97 (XEN) Command line: dom0_mem=400M sched=credit (XEN) Video information: (XEN) VGA is text mode 80x25, font 8x16 (XEN) VBE/DDC methods: none; EDID transfer time: 0 seconds (XEN) EDID info not retrieved because no DDC retrieval method detected (XEN) Disc information: (XEN) Found 2 MBR signatures (XEN) Found 2 EDD information structures (XEN) Xen-e820 RAM map: (XEN) 0000000000000000 - 000000000009b400 (usable) (XEN) 000000000009b400 - 00000000000a0000 (reserved) (XEN) 00000000000e2000 - 0000000000100000 (reserved) (XEN) 0000000000100000 - 00000000aff90000 (usable) (XEN) 00000000aff90000 - 00000000aff9e000 (ACPI data) (XEN) 00000000aff9e000 - 00000000affe0000 (ACPI NVS) (XEN) 00000000affe0000 - 00000000affee000 (reserved) (XEN) 00000000afff0000 - 00000000b0000000 (reserved) (XEN) 00000000fec00000 - 00000000fec01000 (reserved) (XEN) 00000000fee00000 - 00000000fef00000 (reserved) (XEN) 00000000fff00000 - 0000000100000000 (reserved) (XEN) 0000000100000000 - 0000000140000000 (usable) (XEN) System RAM: 3839MB (3931308kB) (XEN) ACPI: RSDP 000FB5D0, 0014 (r0 ACPIAM) (XEN) ACPI: RSDT AFF90000, 0038 (r1 032210 RSDT1037 20100322 MSFT 97) (XEN) ACPI: FACP AFF90200, 0084 (r2 032210 FACP1037 20100322 MSFT 97) (XEN) ACPI: DSDT AFF90460, 7307 (r1 A1270 A1270000 0 INTL 20060113) (XEN) ACPI: FACS AFF9E000, 0040 (XEN) ACPI: APIC AFF90390, 0090 (r1 032210 APIC1037 20100322 MSFT 97) (XEN) ACPI: MCFG AFF90420, 003C (r1 032210 OEMMCFG 20100322 MSFT 97) (XEN) ACPI: OEMB AFF9E040, 0071 (r1 032210 OEMB1037 20100322 MSFT 97) (XEN) ACPI: HPET AFF97770, 0038 (r1 032210 OEMHPET0 20100322 MSFT 97) (XEN) Xen heap: 9MB (9788kB) (XEN) Domain heap initialised (XEN) Processor #0 0:6 APIC version 16 (XEN) Processor #1 0:6 APIC version 16 (XEN) IOAPIC[0]: apic_id 2, version 17, address 0xfec00000, GSI 0-23 (XEN) Enabling APIC mode: Flat. Using 1 I/O APICs (XEN) Table is not found! (XEN) Using scheduler: SMP Credit Scheduler (credit) (XEN) Detected 3013.752 MHz processor. (XEN) AMD-Vi: IOMMU not found! (XEN) I/O virtualisation disabled (XEN) ENABLING IO-APIC IRQs (XEN) -> Using new ACK method (XEN) Platform timer is 25.000MHz HPET (XEN) Allocated console ring of 16 KiB. (XEN) CPU0: AMD SVM Extension is disabled in BIOS. (XEN) SVM: failed to initialise. (XEN) Brought up 2 CPUs (XEN) *** LOADING DOMAIN 0 *** (XEN) Xen kernel: 32-bit, PAE, lsb (XEN) Dom0 kernel: 32-bit, PAE, lsb, paddr 0x400000 -> 0x1780000 (XEN) PHYSICAL MEMORY ARRANGEMENT: (XEN) Dom0 alloc.: 000000013a000000->000000013c000000 (93225 pages to be allocated) (XEN) Init. ramdisk: 000000013fc29000->000000013ffff600 (XEN) VIRTUAL MEMORY ARRANGEMENT: (XEN) Loaded kernel: c0400000->c1780000 (XEN) Init. ramdisk: c1780000->c1b56600 (XEN) Phys-Mach map: c1b57000->c1bbb000 (XEN) Start info: c1bbb000->c1bbb47c (XEN) Page tables: c1bbc000->c1bd1000 (XEN) Boot stack: c1bd1000->c1bd2000 (XEN) TOTAL: c0000000->c2000000 (XEN) ENTRY ADDRESS: c13d9000 (XEN) Dom0 has maximum 2 VCPUs (XEN) Scrubbing Free RAM: ..................................done. (XEN) Xen trace buffers: disabled (XEN) Std. Loglevel: Errors and warnings (XEN) Guest Loglevel: Nothing (Rate-limited: Errors and warnings) (XEN) Xen is relinquishing VGA console. (XEN) *** Serial input -> DOM0 (type 'CTRL-a' three times to switch input to Xen) (XEN) Freed 188kB init memory. (XEN) mm.c:907:d0 Error getting mfn 3a09c (pfn 55555555) from L1 entry 000000003a09c023 for l1e_owner=0, pg_owner=0 (XEN) mm.c:907:d0 Error getting mfn 3a09d (pfn 55555555) from L1 entry 000000003a09d023 for l1e_owner=0, pg_owner=0 (XEN) mm.c:907:d0 Error getting mfn 3a09e (pfn 55555555) from L1 entry 000000003a09e023 for l1e_owner=0, pg_owner=0 (XEN) mm.c:907:d0 Error getting mfn 3a09f (pfn 55555555) from L1 entry 000000003a09f023 for l1e_owner=0, pg_owner=0 (XEN) traps.c:2388:d0 Domain attempted WRMSR c0010004 from 0x0000ab23d6d622da to 0x000000000000abcd. --------------020606070606080001040109 Content-Type: text/plain; name="good-xend.log" Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename="good-xend.log" [2011-09-07 11:08:19 3021] INFO (SrvDaemon:332) Xend Daemon started [2011-09-07 11:08:19 3021] INFO (SrvDaemon:336) Xend changeset: unavailable. [2011-09-07 11:08:19 3021] DEBUG (tcp:96) Listening on :8002 [2011-09-07 11:08:20 3021] DEBUG (XendNode:332) pscsi record count: 11 [2011-09-07 11:08:20 3021] DEBUG (XendCPUPool:747) recreate_active_pools [2011-09-07 11:08:20 3021] DEBUG (XendDomainInfo:151) XendDomainInfo.recreate({'max_vcpu_id': 1, 'cpu_time': 5738793830L, 'ssidref': 0, 'hvm': 0, 'shutdown_reason': 255, 'dying': 0, 'online_vcpus': 2, 'domid': 0, 'paused': 0, 'crashed': 0, 'running': 1, 'maxmem_kb': 4294967292L, 'shutdown': 0, 'mem_kb': 409600L, 'blocked': 0, 'handle': [0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0], 'cpupool': 0, 'name': 'Domain-0'}) [2011-09-07 11:08:20 3021] INFO (XendDomainInfo:168) Recreating domain 0, UUID 00000000-0000-0000-0000-000000000000. at /local/domain/0 [2011-09-07 11:08:20 3021] DEBUG (XendDomainInfo:3420) Storing VM details: {'on_xend_stop': 'ignore', 'pool_name': 'Pool-0', 'shadow_memory': '0', 'uuid': '00000000-0000-0000-0000-000000000000', 'on_reboot': 'restart', 'image': "(linux (kernel '') (superpages 0) (tsc_mode 0) (nomigrate 0))", 'on_poweroff': 'destroy', 'bootloader_args': '', 'on_xend_start': 'ignore', 'on_crash': 'restart', 'xend/restart_count': '0', 'vcpus': '2', 'vcpu_avail': '3', 'bootloader': '', 'name': 'Domain-0'} [2011-09-07 11:08:20 3021] DEBUG (XendDomainInfo:1794) Storing domain details: {'description': '', 'console/limit': '1048576', 'memory/target': '409600', 'vm': '/vm/00000000-0000-0000-0000-000000000000', 'domid': '0', 'cpu/0/availability': 'online', 'cpu/1/availability': 'online', 'control/platform-feature-multiprocessor-suspend': '1', 'console/type': 'xenconsoled', 'name': 'Domain-0'} [2011-09-07 11:08:20 3021] DEBUG (XendDomain:476) Adding Domain: 0 [2011-09-07 11:08:20 3021] DEBUG (XendDomain:410) number of vcpus to use is 0 [2011-09-07 11:08:20 3021] DEBUG (XendDomainInfo:1881) XendDomainInfo.handleShutdownWatch [2011-09-07 11:08:20 3021] WARNING (XendAPI:708) API call: VBD.set_device not found [2011-09-07 11:08:20 3021] WARNING (XendAPI:708) API call: VBD.set_type not found [2011-09-07 11:08:20 3021] WARNING (XendAPI:708) API call: session.get_all_records not found [2011-09-07 11:08:20 3021] WARNING (XendAPI:708) API call: event.get_record not found [2011-09-07 11:08:20 3021] WARNING (XendAPI:708) API call: event.get_all not found [2011-09-07 11:08:20 3021] WARNING (XendAPI:708) API call: VIF.set_device not found [2011-09-07 11:08:20 3021] WARNING (XendAPI:708) API call: VIF.set_MAC not found [2011-09-07 11:08:20 3021] WARNING (XendAPI:708) API call: VIF.set_MTU not found [2011-09-07 11:08:20 3021] WARNING (XendAPI:708) API call: debug.get_all not found [2011-09-07 11:08:20 3021] INFO (XMLRPCServer:161) Opening Unix domain socket XML-RPC server on /var/run/xend/xen-api.sock; authentication has been disabled for this server. [2011-09-07 11:08:20 3021] INFO (XMLRPCServer:161) Opening Unix domain socket XML-RPC server on /var/run/xend/xmlrpc.sock. [2011-09-07 11:08:31 3021] DEBUG (XendDomainInfo:151) XendDomainInfo.recreate({'max_vcpu_id': 0, 'cpu_time': 0L, 'ssidref': 0, 'hvm': 0, 'shutdown_reason': 255, 'dying': 0, 'online_vcpus': 1, 'domid': 1, 'paused': 1, 'crashed': 0, 'running': 0, 'maxmem_kb': 1025024L, 'shutdown': 0, 'mem_kb': 1024000L, 'handle': [113, 167, 96, 104, 228, 231, 74, 230, 145, 8, 130, 229, 153, 66, 37, 27], 'blocked': 0, 'cpupool': 0}) [2011-09-07 11:08:31 3021] INFO (XendDomainInfo:168) Recreating domain 1, UUID 71a76068-e4e7-4ae6-9108-82e59942251b. at /local/domain/1 [2011-09-07 11:08:31 3021] DEBUG (XendDomain:476) Adding Domain: 1 [2011-09-07 11:08:31 3021] DEBUG (XendDomainInfo:1881) XendDomainInfo.handleShutdownWatch --------------020606070606080001040109 Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel --------------020606070606080001040109-- From xen-devel-bounces@lists.xensource.com Wed Sep 07 05:31:58 2011 Return-path: Envelope-to: www-data@lists.xensource.com Delivery-date: Wed, 07 Sep 2011 05:31:58 -0700 Received: from localhost ([127.0.0.1] helo=lists.colo.xensource.com) by lists.xensource.com with esmtp (Exim 4.43) id 1R1HIM-0000kE-Ga; Wed, 07 Sep 2011 05:31:58 -0700 Received: from mail21.messagelabs.com ([85.158.143.35]) by lists.xensource.com with esmtp (Exim 4.43) id 1R1HHL-0000GC-Em for xen-devel@lists.xensource.com; Wed, 07 Sep 2011 05:30:55 -0700 X-Env-Sender: konrad@dumpdata.com X-Msg-Ref: server-7.tower-21.messagelabs.com!1315398622!53939856!1 X-Originating-IP: [141.146.126.227] X-StarScan-Version: 6.3.6; banners=-,-,- X-VirusChecked: Checked Received: (qmail 4666 invoked from network); 7 Sep 2011 12:30:23 -0000 Received: from acsinet15.oracle.com (HELO acsinet15.oracle.com) (141.146.126.227) by server-7.tower-21.messagelabs.com with DHE-RSA-AES256-SHA encrypted SMTP; 7 Sep 2011 12:30:23 -0000 Received: from rtcsinet22.oracle.com (rtcsinet22.oracle.com [66.248.204.30]) by acsinet15.oracle.com (Switch-3.4.4/Switch-3.4.4) with ESMTP id p87CU0mg022413 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Wed, 7 Sep 2011 12:30:02 GMT Received: from acsmt357.oracle.com (acsmt357.oracle.com [141.146.40.157]) by rtcsinet22.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id p87CTvPT013595 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 7 Sep 2011 12:29:58 GMT Received: from abhmt111.oracle.com (abhmt111.oracle.com [141.146.116.63]) by acsmt357.oracle.com (8.12.11.20060308/8.12.11) with ESMTP id p87CToIY016597; Wed, 7 Sep 2011 07:29:51 -0500 Received: from phenom (/209.6.55.207) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Wed, 07 Sep 2011 05:29:50 -0700 Received: by phenom (Postfix, from userid 1000) id D5E15E45; Wed, 7 Sep 2011 08:29:38 -0400 (EDT) Date: Wed, 7 Sep 2011 08:29:38 -0400 From: Konrad Rzeszutek Wilk To: Ben Hutchings Subject: Re: Bug#637234: [Xen-devel] Re: Bug#637234: linux-image-3.0.0-1-686-pae: I/O errors using ext4 under xen Message-ID: <20110907122938.GA32190@dumpdata.com> References: <20110809180728.2279.11548.reportbug@mail1.gedalya.net> <1314254828.17978.720.camel@dagon.hellion.org.uk> <20110826175317.GA5043@dumpdata.com> <4E58251A.8090108@gedalya.net> <20110829140849.GA3897@dumpdata.com> <1315360270.3092.381.camel@deadeye> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <1315360270.3092.381.camel@deadeye> User-Agent: Mutt/1.5.21 (2010-09-15) X-Source-IP: rtcsinet22.oracle.com [66.248.204.30] X-CT-RefId: str=0001.0A090208.4E6763CB.0020,ss=1,re=0.000,fgs=0 Cc: Gedalya , Ian Campbell , xen-devel , 637234@bugs.debian.org X-BeenThere: xen-devel@lists.xensource.com X-Mailman-Version: 2.1.5 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xensource.com Errors-To: xen-devel-bounces@lists.xensource.com On Wed, Sep 07, 2011 at 02:51:04AM +0100, Ben Hutchings wrote: > On Mon, 2011-08-29 at 10:08 -0400, Konrad Rzeszutek Wilk wrote: > [...] > > Oh, I think I know _exactly_ what bug that is: > > > > This git commit: > > 280802657fb95c52bb5a35d43fea60351883b2af "xen/blkback: When writting barriers set the sector number to zero" > > has to be reverted. Specifically: > > > > commit 3f963cae3ef35d26fdd899c08797a598c5ca3e9b > > Author: Jeremy Fitzhardinge > > Date: Tue Jul 19 16:44:42 2011 -0700 > > > > Revert "xen/blkback: When writting barriers set the sector number to zero..." > [...] > > and this one added: > > > > 25266338a41470a21e9b3974445be09e0640dda7 > > xen/blkback: don't fail empty barrier requests > [...] > > Which repository are these in? Jeremy's: git://git.kernel.org/pub/scm/linux/kernel/git/jeremy/xen.git > > Ben. > > _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel From xen-devel-bounces@lists.xensource.com Wed Sep 07 05:34:36 2011 Return-path: Envelope-to: www-data@lists.xensource.com Delivery-date: Wed, 07 Sep 2011 05:34:36 -0700 Received: from localhost ([127.0.0.1] helo=lists.colo.xensource.com) by lists.xensource.com with esmtp (Exim 4.43) id 1R1HKu-00018z-1i; Wed, 07 Sep 2011 05:34:36 -0700 Received: from mail216.messagelabs.com ([85.158.143.99]) by lists.xensource.com with esmtp (Exim 4.43) id 1R1HJu-0000wD-Kw for xen-devel@lists.xensource.com; Wed, 07 Sep 2011 05:33:34 -0700 X-Env-Sender: konrad@dumpdata.com X-Msg-Ref: server-9.tower-216.messagelabs.com!1315398810!17400859!1 X-Originating-IP: [148.87.113.117] X-StarScan-Version: 6.3.6; banners=-,-,- X-VirusChecked: Checked Received: (qmail 9826 invoked from network); 7 Sep 2011 12:33:31 -0000 Received: from rcsinet15.oracle.com (HELO rcsinet15.oracle.com) (148.87.113.117) by server-9.tower-216.messagelabs.com with DHE-RSA-AES256-SHA encrypted SMTP; 7 Sep 2011 12:33:31 -0000 Received: from acsinet22.oracle.com (acsinet22.oracle.com [141.146.126.238]) by rcsinet15.oracle.com (Switch-3.4.4/Switch-3.4.4) with ESMTP id p87CXNHJ004088 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Wed, 7 Sep 2011 12:33:25 GMT Received: from acsmt358.oracle.com (acsmt358.oracle.com [141.146.40.158]) by acsinet22.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id p87CXNeA011718 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 7 Sep 2011 12:33:23 GMT Received: from abhmt120.oracle.com (abhmt120.oracle.com [141.146.116.72]) by acsmt358.oracle.com (8.12.11.20060308/8.12.11) with ESMTP id p87CXHJe021943; Wed, 7 Sep 2011 07:33:18 -0500 Received: from phenom (/209.6.55.207) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Wed, 07 Sep 2011 05:33:17 -0700 Received: by phenom (Postfix, from userid 1000) id A9BE5E45; Wed, 7 Sep 2011 08:33:05 -0400 (EDT) Date: Wed, 7 Sep 2011 08:33:05 -0400 From: Konrad Rzeszutek Wilk To: zhikai Subject: Re: [Xen-devel] How to start a GUI in Xen PV DomU Message-ID: <20110907123305.GB32190@dumpdata.com> References: <617bb665.38c8.1324199a5c4.Coremail.gbtux@126.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <617bb665.38c8.1324199a5c4.Coremail.gbtux@126.com> User-Agent: Mutt/1.5.21 (2010-09-15) X-Source-IP: acsinet22.oracle.com [141.146.126.238] X-Auth-Type: Internal IP X-CT-RefId: str=0001.0A090202.4E676495.00DC:SCFMA922111,ss=1,re=-4.000,fgs=0 Cc: xen-devel@lists.xensource.com X-BeenThere: xen-devel@lists.xensource.com X-Mailman-Version: 2.1.5 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xensource.com Errors-To: xen-devel-bounces@lists.xensource.com On Wed, Sep 07, 2011 at 09:56:21AM +0800, zhikai wrote: > Hi All, > > > Could anyone tell me how to start the desktop of a PV DomU? Does Xen support the GUI in PV? And how to run a application with GUI? > Any reply is appreciated. Normally? The same way as any other way? The xenfb is a normal /dev/fb0 in the guest side. Just make sure you are using the right fb stanze. vfb = [ 'vnc=1, vnclisten=0.0.0.0,vncunused=1'] BTW, why aren't you sending this email to xen-users? _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel From xen-devel-bounces@lists.xensource.com Wed Sep 07 05:52:16 2011 Return-path: Envelope-to: www-data@lists.xensource.com Delivery-date: Wed, 07 Sep 2011 05:52:16 -0700 Received: from localhost ([127.0.0.1] helo=lists.colo.xensource.com) by lists.xensource.com with esmtp (Exim 4.43) id 1R1Hc0-0001sY-D6; Wed, 07 Sep 2011 05:52:16 -0700 Received: from mail182.messagelabs.com ([85.158.139.83]) by lists.xensource.com with smtp (Exim 4.43) id 1R1HbJ-0001fT-G5 for xen-devel@lists.xensource.com; Wed, 07 Sep 2011 05:51:34 -0700 X-Env-Sender: davidtecher@yahoo.fr X-Msg-Ref: server-12.tower-182.messagelabs.com!1315399890!17252745!1 X-Originating-IP: [77.238.189.62] X-StarScan-Version: 6.3.6; banners=-,-,- X-VirusChecked: Checked Received: (qmail 2133 invoked from network); 7 Sep 2011 12:51:30 -0000 Received: from nm5.bullet.mail.ird.yahoo.com (HELO nm5.bullet.mail.ird.yahoo.com) (77.238.189.62) by server-12.tower-182.messagelabs.com with SMTP; 7 Sep 2011 12:51:30 -0000 Received: from [77.238.189.55] by nm5.bullet.mail.ird.yahoo.com with NNFMP; 07 Sep 2011 12:51:29 -0000 Received: from [212.82.108.112] by tm8.bullet.mail.ird.yahoo.com with NNFMP; 07 Sep 2011 12:51:29 -0000 Received: from [127.0.0.1] by omp1021.mail.ird.yahoo.com with NNFMP; 07 Sep 2011 12:51:29 -0000 X-Yahoo-Newman-Property: ymail-3 X-Yahoo-Newman-Id: 907083.75203.bm@omp1021.mail.ird.yahoo.com Received: (qmail 79590 invoked by uid 60001); 7 Sep 2011 12:51:29 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.fr; s=s1024; t=1315399889; bh=yqbZzbltmpw8g08HaTyxfmuMAiMOnNhdNDXJCCX3ZVY=; h=X-YMail-OSG:Received:X-Mailer:References:Message-ID:Date:From:Reply-To:Subject:To:In-Reply-To:MIME-Version:Content-Type; b=5G9j+aZw6HrQH+M6NW3YsloxuiyEvBjj1wuVCugq4xW3y2VoeR94LKtsq3hlU4urGiWlSLDz17FIkLJou9n3esh0cCU9O90VfygZsPqz2rqpuNx57fFI5+NlEV/q2Kgme1lRihZ3UYrrMBTXVAHibWP0VsIiNgewqZQipIJhSGM= DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.fr; h=X-YMail-OSG:Received:X-Mailer:References:Message-ID:Date:From:Reply-To:Subject:To:In-Reply-To:MIME-Version:Content-Type; b=s3PqJy4SYpbYhIKTHhh2SA/U1BHCIdxnB0sropxMJRtIMjiFKQMAHUcLmXukpM6ubok/PmmMwt80ys3rbOC9iBJ6ugSz7looPmxCErUs4DEA1AWI3/Z6EVtgslz5SbPPanbrCp+88yZhlTl4vEqJGiyxITUdZp6y9ch+Tt9hAHI=; X-YMail-OSG: 0ET3n3MVM1kluvChNpcVq8LOKq.J6OP7fpGLnuAlqLT0eHD GSoBfRHauzPVuU8liOHHuT4D2STqfse.32qkplhLBWTLtKgfavP3WHQWHI3j R3QxCpv6OrsLiamcii5WaVQGayis2MDRYPQ9cC6s0DA1caZXTyHxAZzC0GvH iP950XONNj38OnLYbxWfBejd_kDHSBW0MME6drzMjOOYuZVJ5wjGgzy1pEhD zKv1qZlbP2FMYF1PavojIQUSRZKaMnUdWUP8td3N216XVixWwmpm19u0AkZ8 VVetvZV4QGk7BA0UNd4ECnsNhNXyk0S4SAelimY5JWcVe7AGonsQS5nmcoNK E3f4i4.0V5ZRHrRwez8nS8blc0CWc8IBw4bMbyVOcksNA5j2dgjCBzExEeMT a4u_njMG_xKrsYcOGnd_iCw2EMaieNWDwmKtjNA06EyGEIZ82XD3EOht7WF8 cQbCVSVXHGJfwvH4lBw0v6agfg_fwiS.C3.RI5PsjnxQ1ogQxJxuxmBrn6W1 7WJxs97o1sH9aEm3Zwu2uKfC9lhRUzxhgyfDx1sVgf0X9B0RG0080Wkai_kL 03j4lcHQwTmCT86KnoChxGa0wAr4D_XQXmqB9iMx3m8d6dD5fMvQHtu7o7km f9ScRvi058Cx5yl_j0OZe9AZ15bkwBEivEBUt6uY8XANRfhdLBoAYCjhSn9b 9Adl_62VqIwjnThxFwlGkwon3nYFWkWz.sNf8 Received: from [195.167.237.98] by web29820.mail.ird.yahoo.com via HTTP; Wed, 07 Sep 2011 13:51:29 BST X-Mailer: YahooMailWebService/0.8.113.315625 References: <1314778567400-4753326.post@n5.nabble.com> <20110831083832.GD7276@reaktio.net> <1314780568949-4753422.post@n5.nabble.com> <1314795401771-4754024.post@n5.nabble.com> <20110831151913.GE7276@reaktio.net> <1315231341254-4770602.post@n5.nabble.com> <1315310225039-4774097.post@n5.nabble.com> <1315343879.61837.YahooMailNeo@web29818.mail.ird.yahoo.com> <1315382742268-4777689.post@n5.nabble.com> <1315389138.56652.YahooMailNeo@web29801.mail.ird.yahoo.com> <1315398360680-4778339.post@n5.nabble.com> Message-ID: <1315399889.79555.YahooMailNeo@web29820.mail.ird.yahoo.com> Date: Wed, 7 Sep 2011 13:51:29 +0100 (BST) From: David TECHER Subject: Re : Re : Re : [Xen-devel] Re: Patches for VGA-Passthrough XEN 4.2 unstable To: komkon555 , "xen-devel@lists.xensource.com" In-Reply-To: <1315398360680-4778339.post@n5.nabble.com> MIME-Version: 1.0 Cc: X-BeenThere: xen-devel@lists.xensource.com X-Mailman-Version: 2.1.5 Precedence: list Reply-To: David TECHER List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1311803280==" Sender: xen-devel-bounces@lists.xensource.com Errors-To: xen-devel-bounces@lists.xensource.com --===============1311803280== Content-Type: multipart/alternative; boundary="0-903986077-1315399889=:79555" --0-903986077-1315399889=:79555 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable It is a great pleasure to know that is it working for you :)=0A=0AI've just= updated the patchs sent by 'JavMV' on May 2011. Even if I'am not a Xen Dev= eloper=0Ait will be a great idea if a real Xen Developer takes care of the = patchs to improve it for Xen 4.2.=0A=0AThe next step was to understand how = the patch for 'tools/firmware/hvmloader/acpi/dsdt.asl'=0Aworks. Once I've u= nderstood, I've patched for my own graphic card.=0A=0AThat's all.=0A=0A=0AF= or my information, what kind of NVIDIA graphic card do you have? GT 430?GT = 440, GTX?=0A=0ASupporting=A0 several cards?I do not know how to do.=0A=0A= =0AMy feeling is that using the same kind of manufacturer graphic card woul= d be possible=0Abecause qemu-dm could only support one kind of VGA BIOS.=0A= =0AI know that in 2009 a patch was done to support more cards but I've tryi= d to updated it.=0A=0A=0A=0A=0A________________________________=0ADe=A0: ko= mkon555 =0A=C0=A0: xen-devel@lists.xensource.com=0AEn= voy=E9 le : Mercredi 7 Septembre 2011 14h26=0AObjet=A0: Re: Re : Re : [Xen-= devel] Re: Patches for VGA-Passthrough XEN 4.2 unstable=0A=0APerfect, with = the latest fixes and configurations it works! I can run dxdiag=0Aand see al= l tests functional. Important is, that cuda-programming is also=0Afunctiona= l (is what I exactly need). Thank you a lot! The next problem is=0Ahow to p= ass through the second (third, fourth) nvidia card to the next one=0AWindow= s-VM?=A0 For me is most impotent to get 4 separate CUDA/OpenCL=0Aprogrammin= g areas.=A0 Have you any ideas?=0A=0ATanks=0AKomkon555=0A=0A=0A--=0AView th= is message in context: http://xen.1045712.n5.nabble.com/Patches-for-VGA-Pas= sthrough-XEN-4-2-unstable-tp4406265p4778339.html=0ASent from the Xen - Dev = mailing list archive at Nabble.com.=0A=0A__________________________________= _____________=0AXen-devel mailing list=0AXen-devel@lists.xensource.com=0Aht= tp://lists.xensource.com/xen-devel --0-903986077-1315399889=:79555 Content-Type: text/html; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable
It is a gr= eat pleasure to know that is it working for you :)

I've just updated the patchs sent by 'JavMV' on = May 2011. Even if I'am not a Xen Developer
it will b= e a great idea if a real Xen Developer takes care of the patchs to improve = it for Xen 4.2.

The next= step was to understand how the patch for 'tools/firmware/hvmloader/= acpi/dsdt.asl'
=0A
works. Once I've understood, I've patched for m= y own graphic card.

That's all.

=
For my information, what kind of NVIDIA graph= ic card do you have? GT 430?GT 440, GTX?

Supporting  several cards? I do not know = how to do.

My feeling is t= hat using the same kind of manufacturer graphic card would be possible
because qemu-dm could only support one kind of VGA BIOS.=

I know that in 2009 a p= atch was done to support more cards but I've tryid to updated it.



<= div style=3D"font-family: times new roman, new york, times, serif; font-siz= e: 12pt;">
De : komkon555 <komkon555@freenet.de>= ;
=C0 : xen-devel@= lists.xensource.com
Envoy=E9 le :<= /span> Mercredi 7 Septembre 2011 14h26
Objet : Re: Re : Re : [Xen-devel] Re: Patches for = VGA-Passthrough XEN 4.2 unstable

Perfect, with the latest fix= es and configurations it works! I can run dxdiag
and see all tests funct= ional. Important is, that cuda-programming is also
functional (is what I= exactly need). Thank you a lot! The next problem is
how to pass through= the second (third, fourth) nvidia card to the next one
Windows-VM? = ; For me is most impotent to get 4 separate CUDA/OpenCL
programming area= s.  Have you any ideas?

Tanks
Komkon555


--
Vi= ew this message in context: http://xen.1045712.n5.nabble.com/Patches-for-VGA-Passthrough-XEN-4-2-unst= able-tp4406265p4778339.html
Sent from the Xen - Dev mailing list arc= hive at Nabble.com.

_______________________________________________<= br>Xen-devel mailing list
Xen-devel@lists.xensour= ce.com
http://lists.xensource.com/xen-devel


--0-903986077-1315399889=:79555-- --===============1311803280== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel --===============1311803280==-- From xen-devel-bounces@lists.xensource.com Wed Sep 07 05:53:22 2011 Return-path: Envelope-to: www-data@lists.xensource.com Delivery-date: Wed, 07 Sep 2011 05:53:22 -0700 Received: from localhost ([127.0.0.1] helo=lists.colo.xensource.com) by lists.xensource.com with esmtp (Exim 4.43) id 1R1Hd3-0002Gj-HM; Wed, 07 Sep 2011 05:53:21 -0700 Received: from mail21.messagelabs.com ([85.158.143.35]) by lists.xensource.com with esmtp (Exim 4.43) id 1R1Hbm-0001mu-CZ for xen-devel@lists.xensource.com; Wed, 07 Sep 2011 05:52:02 -0700 X-Env-Sender: konrad@dumpdata.com X-Msg-Ref: server-2.tower-21.messagelabs.com!1315399917!33186170!1 X-Originating-IP: [141.146.126.227] X-StarScan-Version: 6.3.6; banners=-,-,- X-VirusChecked: Checked Received: (qmail 10049 invoked from network); 7 Sep 2011 12:51:58 -0000 Received: from acsinet15.oracle.com (HELO acsinet15.oracle.com) (141.146.126.227) by server-2.tower-21.messagelabs.com with DHE-RSA-AES256-SHA encrypted SMTP; 7 Sep 2011 12:51:58 -0000 Received: from rtcsinet21.oracle.com (rtcsinet21.oracle.com [66.248.204.29]) by acsinet15.oracle.com (Switch-3.4.4/Switch-3.4.4) with ESMTP id p87CmSEK000420 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Wed, 7 Sep 2011 12:48:30 GMT Received: from acsmt357.oracle.com (acsmt357.oracle.com [141.146.40.157]) by rtcsinet21.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id p87CmOlH001892 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 7 Sep 2011 12:48:25 GMT Received: from abhmt116.oracle.com (abhmt116.oracle.com [141.146.116.68]) by acsmt357.oracle.com (8.12.11.20060308/8.12.11) with ESMTP id p87CmCwB030420; Wed, 7 Sep 2011 07:48:13 -0500 Received: from phenom (/209.6.55.207) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Wed, 07 Sep 2011 05:48:12 -0700 Received: by phenom (Postfix, from userid 1000) id 50FFCE45; Wed, 7 Sep 2011 08:48:00 -0400 (EDT) Date: Wed, 7 Sep 2011 08:48:00 -0400 From: Konrad Rzeszutek Wilk To: Ian Jackson Subject: Re: [Xen-devel] Re: [patch] xen-blkback: sync I/O after backend disconnected Message-ID: <20110907124800.GC32190@dumpdata.com> References: <4E48A6A6.4040706@oracle.com> <20110815144610.GA3707@infradead.org> <20054.29964.556177.999449@mariner.uk.xensource.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20054.29964.556177.999449@mariner.uk.xensource.com> User-Agent: Mutt/1.5.21 (2010-09-15) X-Source-IP: rtcsinet21.oracle.com [66.248.204.29] X-CT-RefId: str=0001.0A090206.4E676839.0020,ss=1,re=0.000,fgs=0 Cc: Christoph Hellwig , "xen-devel@lists.xensource.com" , Jens Axboe , Marsden , Joe Jin , "linux-kernel@vger.kernel.org" , Greg@acsinet13.oracle.com, Ian Campbell , Kurt C Hackel X-BeenThere: xen-devel@lists.xensource.com X-Mailman-Version: 2.1.5 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xensource.com Errors-To: xen-devel-bounces@lists.xensource.com On Thu, Aug 25, 2011 at 05:15:08PM +0100, Ian Jackson wrote: > Konrad Rzeszutek Wilk writes ("Re: [Xen-devel] Re: [patch] xen-blkback: sync I/O after backend disconnected"): > > And the guest would normally issues a FLUSH when unmounting the > > disk. Hm, I wonder what the conditions are when we forcibly kill the > > guest - there might be outstanding I/Os in the disk's cache - > > at which point we should probably sync the write cache, no? > > If we forcibly kill the guest we don't care about its IO in flight. Why don't we care about it? It might have become wedged but that does not mean we don't want to preserve as much as possible. > After all we are throwing away everything that the guest has in its > queue. We end up finishing all of the outstanding I/Os that guest has sent. When all of the bio_submit callbacks have finished then we release the guest backend. So adding in a 'SYNC' to the queue would force the disk cache to flush all the writes at least. > > Bear in mind that the reason for forcibly killing (or perhaps forcibly > detaching) might be that the underlying device has wedged somehow. It > would be annoying if that prevented even a force detach. > > Or to put it in other words: force detach and force kill should be > lossy. Their whole point is to be the lossy version. Hm, I think you still end up holding on the request queue and not freeing the blkback thread and all of its goodies until the bio callbacks have completed. When the device gets wedged they become wedged too. You have to wait for the error handler to give up and then the avalanche of 'write page lost' and 'error secxtor XX' along with the -ENXIO being returned ends up in the bio callbacks. What I am saying is that the force detach is still stuck waiting if the device has wedged - irregardless of this patch. > > Ian. > > _______________________________________________ > Xen-devel mailing list > Xen-devel@lists.xensource.com > http://lists.xensource.com/xen-devel _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel From xen-devel-bounces@lists.xensource.com Wed Sep 07 06:02:49 2011 Return-path: Envelope-to: www-data@lists.xensource.com Delivery-date: Wed, 07 Sep 2011 06:02:49 -0700 Received: from localhost ([127.0.0.1] helo=lists.colo.xensource.com) by lists.xensource.com with esmtp (Exim 4.43) id 1R1HmC-0002nO-Jf; Wed, 07 Sep 2011 06:02:49 -0700 Received: from mail21.messagelabs.com ([85.158.143.35]) by lists.xensource.com with smtp (Exim 4.43) id 1R1HiA-0002Xy-J8 for xen-devel@lists.xensource.com; Wed, 07 Sep 2011 05:59:33 -0700 X-Env-Sender: anthony@overnetdata.com X-Msg-Ref: server-5.tower-21.messagelabs.com!1315400265!47213117!1 X-Originating-IP: [81.137.131.225] X-StarScan-Version: 6.3.6; banners=-,-,- X-VirusChecked: Checked Received: (qmail 31569 invoked from network); 7 Sep 2011 12:57:46 -0000 Received: from host81-137-131-225.in-addr.btopenworld.com (HELO zimbra.overnetdata.com) (81.137.131.225) by server-5.tower-21.messagelabs.com with SMTP; 7 Sep 2011 12:57:46 -0000 Received: from localhost (localhost.localdomain [127.0.0.1]) by zimbra.overnetdata.com (Postfix) with ESMTP id 2F58E16157E; Wed, 7 Sep 2011 13:58:09 +0100 (BST) X-Virus-Scanned: amavisd-new at overnetdata.com Received: from zimbra.overnetdata.com ([127.0.0.1]) by localhost (zimbra.overnetdata.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ARtS7JNy6R9y; Wed, 7 Sep 2011 13:58:00 +0100 (BST) Received: from [192.168.1.54] (unknown [192.168.1.54]) by zimbra.overnetdata.com (Postfix) with ESMTPSA id DF31B16157B; Wed, 7 Sep 2011 13:57:59 +0100 (BST) Message-ID: <4E676A52.8050907@overnetdata.com> Date: Wed, 07 Sep 2011 13:57:54 +0100 From: Anthony Wright User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:6.0.1) Gecko/20110830 Thunderbird/6.0.1 MIME-Version: 1.0 To: David Vrabel Subject: Re: [Xen-devel] Kernel bug from 3.0 (was phy disks and vifs timing out in DomU) References: <4E3266DE.9000606@overnetdata.com> <20110803152841.GA2860@dumpdata.com> <4E4E3957.1040007@overnetdata.com> <20110819125615.GA26558@dumpdata.com> <4E56B132.9050708@overnetdata.com> <20110826142606.GA25511@dumpdata.com> <20110826144438.GA24836@dumpdata.com> <4E5E6843.7050206@citrix.com> <20110831170711.GB13642@dumpdata.com> <1314862972.28989.74.camel@zakaz.uk.xensource.com> <20110901142356.GD23971@dumpdata.com> <4E5FA0C4.7000806@citrix.com> In-Reply-To: <4E5FA0C4.7000806@citrix.com> X-Enigmail-Version: 1.3.1 Content-Type: multipart/mixed; boundary="------------070203020808050508080303" Cc: Ian Campbell , Todd Deshane , "xen-devel@lists.xensource.com" , Jeremy Fitzhardinge , Konrad Rzeszutek Wilk X-BeenThere: xen-devel@lists.xensource.com X-Mailman-Version: 2.1.5 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xensource.com Errors-To: xen-devel-bounces@lists.xensource.com This is a multi-part message in MIME format. --------------070203020808050508080303 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit On 01/09/2011 16:12, David Vrabel wrote: > On 01/09/11 15:23, Konrad Rzeszutek Wilk wrote: >> On Thu, Sep 01, 2011 at 08:42:52AM +0100, Ian Campbell wrote: >>> On Wed, 2011-08-31 at 18:07 +0100, Konrad Rzeszutek Wilk wrote: >>>> On Wed, Aug 31, 2011 at 05:58:43PM +0100, David Vrabel wrote: >>>>> On 26/08/11 15:44, Konrad Rzeszutek Wilk wrote: >>>>>> So while I am still looking at the hypervisor code to figure out why >>>>>> it would give me [when trying to map a grant page]: >>>>>> >>>>>> (XEN) mm.c:3846:d0 Could not find L1 PTE for address fbb42000 >>>>> It is failing in guest_map_l1e() because the page for the vmalloc'd >>>>> virtual address PTEs is not present. >>>>> >>>>> The test that fails is: >>>>> >>>>> (l2e_get_flags(l2e) & (_PAGE_PRESENT | _PAGE_PSE)) != _PAGE_PRESENT >>>>> >>>>> I think this is because the GNTTABOP_map_grant_ref hypercall is done >>>>> when task->active_mm != &init_mm and alloc_vm_area() only adds PTEs into >>>>> init_mm so when Xen looks in the page tables it doesn't find the entries >>>>> because they're not there yet. >>>>> >>>>> Putting a call to vmalloc_sync_all() after create_vm_area() and before >>>>> the hypercall makes it work for me. Classic Xen kernels used to have >>>>> such a call. >>>> That sounds quite reasonable. >>> I was wondering why upstream was missing the vmalloc_sync_all() in >>> alloc_vm_area() since the out-of-tree kernels did have it and the >>> function was added by us. I found this: >>> http://git.kernel.org/?p=linux/kernel/git/torvalds/linux.git;a=commitdiff;h=ef691947d8a3d479e67652312783aedcf629320a >>> >>> commit ef691947d8a3d479e67652312783aedcf629320a >>> Author: Jeremy Fitzhardinge >>> Date: Wed Dec 1 15:45:48 2010 -0800 >>> >>> vmalloc: remove vmalloc_sync_all() from alloc_vm_area() >>> >>> There's no need for it: it will get faulted into the current pagetable >>> as needed. >>> >>> Signed-off-by: Jeremy Fitzhardinge >>> >>> The flaw in the reasoning here is that you cannot take a kernel fault >>> while processing a hypercall, so hypercall arguments must have been >>> faulted in beforehand and that is what the sync_all was for. >>> >>> It's probably fair to say that the Xen specific caller should take care >>> of that Xen-specific requirement rather than pushing it into common >>> code. On the other hand Xen is the only user and creating a Xen specific >>> helper/wrapper seems a bit pointless. >> Perhaps then doing the vmalloc_sync_all() (or are more precise one: >> vmalloc_sync_one) should be employed in the netback code then? >> >> And obviously guarded by the CONFIG_HIGHMEM case? > Perhaps. But I think the correct thing to do initially is revert the > change and then look at possible improvements. Particularly as the fix > needs to be a backported to stable. > > David > I have implement a patch which does essentially this, i.e. calls vmalloc_sync_all() afer every alloc_vm_area() call (all 5 of them). Now my VMs start correctly, but I still get error messages in the xen dmesg output (attached). Is this expected? Anthony --------------070203020808050508080303 Content-Type: text/plain; name="dmesg.log" Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename="dmesg.log" __ __ _ _ _ _ \ \/ /___ _ __ | || | / | / | \ // _ \ '_ \ | || |_ | | | | / \ __/ | | | |__ _|| |_| | /_/\_\___|_| |_| |_|(_)_(_)_| (XEN) Xen version 4.1.1 (@[unknown]) (gcc version 4.4.3 (GCC) ) Tue Aug 30 19:32:56 GMT 2011 (XEN) Latest ChangeSet: unavailable (XEN) Bootloader: GNU GRUB 0.97 (XEN) Command line: dom0_mem=400M sched=credit (XEN) Video information: (XEN) VGA is text mode 80x25, font 8x16 (XEN) VBE/DDC methods: none; EDID transfer time: 0 seconds (XEN) EDID info not retrieved because no DDC retrieval method detected (XEN) Disc information: (XEN) Found 2 MBR signatures (XEN) Found 2 EDD information structures (XEN) Xen-e820 RAM map: (XEN) 0000000000000000 - 000000000009b400 (usable) (XEN) 000000000009b400 - 00000000000a0000 (reserved) (XEN) 00000000000e2000 - 0000000000100000 (reserved) (XEN) 0000000000100000 - 00000000aff90000 (usable) (XEN) 00000000aff90000 - 00000000aff9e000 (ACPI data) (XEN) 00000000aff9e000 - 00000000affe0000 (ACPI NVS) (XEN) 00000000affe0000 - 00000000affee000 (reserved) (XEN) 00000000afff0000 - 00000000b0000000 (reserved) (XEN) 00000000fec00000 - 00000000fec01000 (reserved) (XEN) 00000000fee00000 - 00000000fef00000 (reserved) (XEN) 00000000fff00000 - 0000000100000000 (reserved) (XEN) 0000000100000000 - 0000000140000000 (usable) (XEN) System RAM: 3839MB (3931308kB) (XEN) ACPI: RSDP 000FB5D0, 0014 (r0 ACPIAM) (XEN) ACPI: RSDT AFF90000, 0038 (r1 032210 RSDT1037 20100322 MSFT 97) (XEN) ACPI: FACP AFF90200, 0084 (r2 032210 FACP1037 20100322 MSFT 97) (XEN) ACPI: DSDT AFF90460, 7307 (r1 A1270 A1270000 0 INTL 20060113) (XEN) ACPI: FACS AFF9E000, 0040 (XEN) ACPI: APIC AFF90390, 0090 (r1 032210 APIC1037 20100322 MSFT 97) (XEN) ACPI: MCFG AFF90420, 003C (r1 032210 OEMMCFG 20100322 MSFT 97) (XEN) ACPI: OEMB AFF9E040, 0071 (r1 032210 OEMB1037 20100322 MSFT 97) (XEN) ACPI: HPET AFF97770, 0038 (r1 032210 OEMHPET0 20100322 MSFT 97) (XEN) Xen heap: 9MB (9788kB) (XEN) Domain heap initialised (XEN) Processor #0 0:6 APIC version 16 (XEN) Processor #1 0:6 APIC version 16 (XEN) IOAPIC[0]: apic_id 2, version 17, address 0xfec00000, GSI 0-23 (XEN) Enabling APIC mode: Flat. Using 1 I/O APICs (XEN) Table is not found! (XEN) Using scheduler: SMP Credit Scheduler (credit) (XEN) Detected 3013.752 MHz processor. (XEN) AMD-Vi: IOMMU not found! (XEN) I/O virtualisation disabled (XEN) ENABLING IO-APIC IRQs (XEN) -> Using new ACK method (XEN) Platform timer is 25.000MHz HPET (XEN) Allocated console ring of 16 KiB. (XEN) CPU0: AMD SVM Extension is disabled in BIOS. (XEN) SVM: failed to initialise. (XEN) Brought up 2 CPUs (XEN) *** LOADING DOMAIN 0 *** (XEN) Xen kernel: 32-bit, PAE, lsb (XEN) Dom0 kernel: 32-bit, PAE, lsb, paddr 0x400000 -> 0x1780000 (XEN) PHYSICAL MEMORY ARRANGEMENT: (XEN) Dom0 alloc.: 000000013a000000->000000013c000000 (93225 pages to be allocated) (XEN) Init. ramdisk: 000000013fc29000->000000013ffff600 (XEN) VIRTUAL MEMORY ARRANGEMENT: (XEN) Loaded kernel: c0400000->c1780000 (XEN) Init. ramdisk: c1780000->c1b56600 (XEN) Phys-Mach map: c1b57000->c1bbb000 (XEN) Start info: c1bbb000->c1bbb47c (XEN) Page tables: c1bbc000->c1bd1000 (XEN) Boot stack: c1bd1000->c1bd2000 (XEN) TOTAL: c0000000->c2000000 (XEN) ENTRY ADDRESS: c13d9000 (XEN) Dom0 has maximum 2 VCPUs (XEN) Scrubbing Free RAM: ..................................done. (XEN) Xen trace buffers: disabled (XEN) Std. Loglevel: Errors and warnings (XEN) Guest Loglevel: Nothing (Rate-limited: Errors and warnings) (XEN) Xen is relinquishing VGA console. (XEN) *** Serial input -> DOM0 (type 'CTRL-a' three times to switch input to Xen) (XEN) Freed 188kB init memory. (XEN) mm.c:907:d0 Error getting mfn 3a09c (pfn 55555555) from L1 entry 000000003a09c023 for l1e_owner=0, pg_owner=0 (XEN) mm.c:907:d0 Error getting mfn 3a09d (pfn 55555555) from L1 entry 000000003a09d023 for l1e_owner=0, pg_owner=0 (XEN) mm.c:907:d0 Error getting mfn 3a09e (pfn 55555555) from L1 entry 000000003a09e023 for l1e_owner=0, pg_owner=0 (XEN) mm.c:907:d0 Error getting mfn 3a09f (pfn 55555555) from L1 entry 000000003a09f023 for l1e_owner=0, pg_owner=0 (XEN) traps.c:2388:d0 Domain attempted WRMSR c0010004 from 0x0000ab23d6d622da to 0x000000000000abcd. --------------070203020808050508080303 Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel --------------070203020808050508080303-- From xen-devel-bounces@lists.xensource.com Wed Sep 07 06:25:59 2011 Return-path: Envelope-to: www-data@lists.xensource.com Delivery-date: Wed, 07 Sep 2011 06:25:59 -0700 Received: from localhost ([127.0.0.1] helo=lists.colo.xensource.com) by lists.xensource.com with esmtp (Exim 4.43) id 1R1I8c-0003gF-SZ; Wed, 07 Sep 2011 06:25:59 -0700 Received: from mail21.messagelabs.com ([85.158.143.35]) by lists.xensource.com with esmtp (Exim 4.43) id 1R1I7m-0003Tx-MV for xen-devel@lists.xensource.com; Wed, 07 Sep 2011 06:25:07 -0700 X-Env-Sender: komkon555@freenet.de X-Msg-Ref: server-9.tower-21.messagelabs.com!1315401859!47510492!1 X-Originating-IP: [216.139.236.26] X-StarScan-Version: 6.3.6; banners=-,-,- X-VirusChecked: Checked Received: (qmail 17549 invoked from network); 7 Sep 2011 13:24:21 -0000 Received: from sam.nabble.com (HELO sam.nabble.com) (216.139.236.26) by server-9.tower-21.messagelabs.com with AES256-SHA encrypted SMTP; 7 Sep 2011 13:24:21 -0000 Received: from [192.168.236.26] (helo=sam.nabble.com) by sam.nabble.com with esmtp (Exim 4.72) (envelope-from ) id 1R1I7h-0000u2-2y for xen-devel@lists.xensource.com; Wed, 07 Sep 2011 06:25:01 -0700 Date: Wed, 7 Sep 2011 06:25:01 -0700 (PDT) From: komkon555 To: xen-devel@lists.xensource.com Message-ID: <1315401901083-4778494.post@n5.nabble.com> In-Reply-To: <1315398360680-4778339.post@n5.nabble.com> References: <20110831083832.GD7276@reaktio.net> <1314780568949-4753422.post@n5.nabble.com> <1314795401771-4754024.post@n5.nabble.com> <20110831151913.GE7276@reaktio.net> <1315231341254-4770602.post@n5.nabble.com> <1315310225039-4774097.post@n5.nabble.com> <1315343879.61837.YahooMailNeo@web29818.mail.ird.yahoo.com> <1315382742268-4777689.post@n5.nabble.com> <1315389138.56652.YahooMailNeo@web29801.mail.ird.yahoo.com> <1315398360680-4778339.post@n5.nabble.com> Subject: Re: Re : Re : [Xen-devel] Re: Patches for VGA-Passthrough XEN 4.2 unstable MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-BeenThere: xen-devel@lists.xensource.com X-Mailman-Version: 2.1.5 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xensource.com Errors-To: xen-devel-bounces@lists.xensource.com My card is: VGA compatible controller: nVidia Corporation GT200 [GeForce GTX 260] (rev a1) -- View this message in context: http://xen.1045712.n5.nabble.com/Patches-for-VGA-Passthrough-XEN-4-2-unstable-tp4406265p4778494.html Sent from the Xen - Dev mailing list archive at Nabble.com. _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel From xen-devel-bounces@lists.xensource.com Wed Sep 07 06:30:32 2011 Return-path: Envelope-to: www-data@lists.xensource.com Delivery-date: Wed, 07 Sep 2011 06:30:32 -0700 Received: from localhost ([127.0.0.1] helo=lists.colo.xensource.com) by lists.xensource.com with esmtp (Exim 4.43) id 1R1ID2-00046p-F4; Wed, 07 Sep 2011 06:30:32 -0700 Received: from mail216.messagelabs.com ([85.158.143.99]) by lists.xensource.com with esmtp (Exim 4.43) id 1R1ICY-0003uB-QR for xen-devel@lists.xensource.com; Wed, 07 Sep 2011 06:30:04 -0700 X-Env-Sender: rafal@invisiblethingslab.com X-Msg-Ref: server-5.tower-216.messagelabs.com!1315402198!16917816!1 X-Originating-IP: [194.181.28.234] X-StarScan-Version: 6.3.6; banners=-,-,- X-VirusChecked: Checked Received: (qmail 5690 invoked from network); 7 Sep 2011 13:29:59 -0000 Received: from warszawa.7bulls.com (HELO warszawa.7bulls.com) (194.181.28.234) by server-5.tower-216.messagelabs.com with DHE-RSA-AES256-SHA encrypted SMTP; 7 Sep 2011 13:29:59 -0000 Received: from localhost (localhost [127.0.0.1]) by warszawa.7bulls.com (Postfix) with ESMTP id 08164E79CA; Wed, 7 Sep 2011 15:29:47 +0200 (CEST) X-Virus-Scanned: Debian amavisd-new at warszawa.7bulls.com Received: from warszawa.7bulls.com ([127.0.0.1]) by localhost (localhost [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CVdfFo7s94E9; Wed, 7 Sep 2011 15:29:46 +0200 (CEST) Received: from email (249-mo5-9.acn.waw.pl [82.210.136.249]) by warszawa.7bulls.com (Postfix) with ESMTP id D7E87E79A9; Wed, 7 Sep 2011 15:29:46 +0200 (CEST) Received: from email. (email [10.137.2.12]) by email (8.14.4/8.14.4) with ESMTP id p87DTraH001224; Wed, 7 Sep 2011 15:29:54 +0200 Received: (from user@localhost) by email. (8.14.4/8.14.4/Submit) id p87DTrFZ001222; Wed, 7 Sep 2011 15:29:53 +0200 X-Authentication-Warning: email.: user set sender to rafal@invisiblethingslab.com using -f Date: Wed, 7 Sep 2011 15:29:53 +0200 From: Rafal Wojtczuk To: Jan Beulich Subject: Re: [Xen-devel] dom0 is stalled until a keypress Message-ID: <20110907132953.GB1185@email> References: <20110905091937.GA1906@email> <36a5b662-4420-41aa-be01-445f83b15a7b@default4E664BEE.9000208@invisiblethingslab.com> <71fba00b-9a7a-4029-ac11-4d37732bb53f@default> <4E673351.6060206@invisiblethingslab.com> <4E6757110200007800055040@nat28.tlf.novell.com> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-2 Content-Disposition: inline In-Reply-To: <4E6757110200007800055040@nat28.tlf.novell.com> User-Agent: Mutt/1.5.21 (2010-09-15) Cc: Dan Magenheimer , xen-devel@lists.xensource.com, Joanna Rutkowska X-BeenThere: xen-devel@lists.xensource.com X-Mailman-Version: 2.1.5 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xensource.com Errors-To: xen-devel-bounces@lists.xensource.com On Wed, Sep 07, 2011 at 10:35:45AM +0100, Jan Beulich wrote: > >>> On 07.09.11 at 11:03, Joanna Rutkowska wrote: > > On 09/06/11 19:17, Dan Magenheimer wrote: > >>> From: Joanna Rutkowska [mailto:joanna@invisiblethingslab.com] > >>> Subject: Re: [Xen-devel] dom0 is stalled until a keypress > >>> > >>> On 09/06/11 17:49, Dan Magenheimer wrote: > >>>>> From: Rafal Wojtczuk [mailto:rafal@invisiblethingslab.com] > >>>>> Sent: Monday, September 05, 2011 3:20 AM > >>>>> To: xen-devel@lists.xensource.com > >>>>> Subject: [Xen-devel] dom0 is stalled until a keypress > >>>>> > >>>>> Hello, > >>>>> The following bizarre behaviour was observed on xen4.1+suse dom0 2.6.38, on > >>>>> an old Core Duo laptop; maybe someone can hint what is wrong. > >>>>> Dom0 boot stalls after an init.d script prints "Starting udev". Then nothing > >>>>> seems to happen. I need to press any key to observe progress - I need to do > >>>>> it tens of times for the boot to finish. After X starts fine, then there is > >>>>> no need for keypressing anymore. > >>>>> A particularly disturbing fact is that qrexec_daemon parent, that basically > >>>>> does > >>>>> for (;;) { sleep(1); fprintf(stderr, "."); } > >>>>> does not print dots, until a keypress arrives. So something is very wrong > >>>>> with timers. > >>>>> Somehow similarly, pm-suspend sometimes hangs at some stage - after detaching > >>>>> power cord, machine enters S3 immediately. > >>>>> This is vaguely similar to the issue described in > >>>>> https://lkml.org/lkml/2008/9/14/122 > >>>>> but this time, "nohz=off" does not help. > >>>>> > >>>>> "cpufreq=dom0-kernel" cures the symptoms; but it is not a sideeffectless > >>>>> solution. Any idea what is going on or how to debug it ? > >>>> > >>>> ISTR seeing this on a Core(2?)Duo laptop and I think the > >>>> workaround was setting max_cstate=0 (as Xen boot parameter). > >>>> > >>> But what was the actual problem? Setting max_cstate is probably even > >>> worse for power management than setting cpufreq=dom-kernel, isn't it? > >> > >> Sorry, dunno. I recall looking into it a bit and finding that > >> the Core processor (and possibly specifically Merom, the laptop > >> version) had some special C-state (C3, C1E maybe?) and giving > >> up at that point. Sorry I can't be more helpful. > > > > But the same system worked fine without any tweaks (cpufreq, max_cstate) > > on Xen 3.4 and only started exhibiting this behavior after we switched > > to Xen 4.1... > > 4.1.0 or 4.1.1? Originally tested on 4.1.0; same problem with 4.1.1. Jeremy> Try booting with "idle=halt". It does not help, either. Regards, RW _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel From xen-devel-bounces@lists.xensource.com Wed Sep 07 06:44:53 2011 Return-path: Envelope-to: www-data@lists.xensource.com Delivery-date: Wed, 07 Sep 2011 06:44:53 -0700 Received: from localhost ([127.0.0.1] helo=lists.colo.xensource.com) by lists.xensource.com with esmtp (Exim 4.43) id 1R1IQv-0004nT-Rh; Wed, 07 Sep 2011 06:44:53 -0700 Received: from mail27.messagelabs.com ([193.109.254.147]) by lists.xensource.com with esmtp (Exim 4.43) id 1R1IQP-0004bP-8S for xen-devel@lists.xensource.com; Wed, 07 Sep 2011 06:44:22 -0700 X-Env-Sender: tim@xen.org X-Msg-Ref: server-11.tower-27.messagelabs.com!1315403051!36430634!1 X-Originating-IP: [81.29.64.94] X-StarScan-Version: 6.3.6; banners=-,-,- X-VirusChecked: Checked Received: (qmail 18900 invoked from network); 7 Sep 2011 13:44:11 -0000 Received: from ocelot.phlegethon.org (HELO mail.phlegethon.org) (81.29.64.94) by server-11.tower-27.messagelabs.com with DHE-RSA-AES256-SHA encrypted SMTP; 7 Sep 2011 13:44:11 -0000 Received: from tjd by mail.phlegethon.org with local (Exim 4.67 (FreeBSD)) (envelope-from ) id 1R1IQK-000BoS-N7; Wed, 07 Sep 2011 13:44:16 +0000 Date: Wed, 7 Sep 2011 14:44:16 +0100 From: Tim Deegan To: Christoph Egger Subject: Re: [Xen-devel] [PATCH 01/04] p2m: use defines for page sizes rather hardcoding them Message-ID: <20110907134416.GD41585@ocelot.phlegethon.org> References: <4E57B184.8070601@amd.com> <20110901084041.GB3859@ocelot.phlegethon.org> <20110901084553.GC3859@ocelot.phlegethon.org> <20110905090224.GB86376@ocelot.phlegethon.org> Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="pf9I7BMVVzbSWLtt" Content-Disposition: inline In-Reply-To: <20110905090224.GB86376@ocelot.phlegethon.org> User-Agent: Mutt/1.4.2.1i Cc: "xen-devel@lists.xensource.com" , Tim Deegan X-BeenThere: xen-devel@lists.xensource.com X-Mailman-Version: 2.1.5 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xensource.com Errors-To: xen-devel-bounces@lists.xensource.com --pf9I7BMVVzbSWLtt Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline At 10:02 +0100 on 05 Sep (1315216944), Tim Deegan wrote: > I think they really just need trimmed back a bit before they go in. > I'll have some time on Wednesday, so I might just do that then. OK, I've cut them back to just the bits that are needed by the new callers. I ended up shuffling the code around as well, so could you please test that the attached series works for you? Cheers, Tim. --pf9I7BMVVzbSWLtt Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: attachment; filename=p2m-order x86/mm: adjust p2m interface to return superpage sizes Signed-off-by: Christoph Egger Signed-off-by: Tim Deegan diff -r f1349a968a5a xen/arch/x86/hvm/hvm.c --- a/xen/arch/x86/hvm/hvm.c Fri Sep 02 14:56:26 2011 +0100 +++ b/xen/arch/x86/hvm/hvm.c Wed Sep 07 11:43:49 2011 +0100 @@ -1216,7 +1216,7 @@ int hvm_hap_nested_page_fault(unsigned l } p2m = p2m_get_hostp2m(v->domain); - mfn = gfn_to_mfn_type_p2m(p2m, gfn, &p2mt, &p2ma, p2m_guest); + mfn = gfn_to_mfn_type_p2m(p2m, gfn, &p2mt, &p2ma, p2m_guest, NULL); /* Check access permissions first, then handle faults */ if ( access_valid && (mfn_x(mfn) != INVALID_MFN) ) diff -r f1349a968a5a xen/arch/x86/hvm/svm/svm.c --- a/xen/arch/x86/hvm/svm/svm.c Fri Sep 02 14:56:26 2011 +0100 +++ b/xen/arch/x86/hvm/svm/svm.c Wed Sep 07 11:43:49 2011 +0100 @@ -1160,7 +1160,7 @@ static void svm_do_nested_pgfault(struct p2m = p2m_get_p2m(v); _d.gpa = gpa; _d.qualification = 0; - _d.mfn = mfn_x(gfn_to_mfn_type_p2m(p2m, gfn, &_d.p2mt, &p2ma, p2m_query)); + _d.mfn = mfn_x(gfn_to_mfn_type_p2m(p2m, gfn, &_d.p2mt, &p2ma, p2m_query, NULL)); __trace_var(TRC_HVM_NPF, 0, sizeof(_d), &_d); } @@ -1180,7 +1180,7 @@ static void svm_do_nested_pgfault(struct if ( p2m == NULL ) p2m = p2m_get_p2m(v); /* Everything else is an error. */ - mfn = gfn_to_mfn_type_p2m(p2m, gfn, &p2mt, &p2ma, p2m_guest); + mfn = gfn_to_mfn_type_p2m(p2m, gfn, &p2mt, &p2ma, p2m_guest, NULL); gdprintk(XENLOG_ERR, "SVM violation gpa %#"PRIpaddr", mfn %#lx, type %i\n", gpa, mfn_x(mfn), p2mt); diff -r f1349a968a5a xen/arch/x86/mm/guest_walk.c --- a/xen/arch/x86/mm/guest_walk.c Fri Sep 02 14:56:26 2011 +0100 +++ b/xen/arch/x86/mm/guest_walk.c Wed Sep 07 11:43:49 2011 +0100 @@ -95,7 +95,7 @@ static inline void *map_domain_gfn(struc p2m_access_t a; /* Translate the gfn, unsharing if shared */ - *mfn = gfn_to_mfn_type_p2m(p2m, gfn_x(gfn), p2mt, &a, p2m_unshare); + *mfn = gfn_to_mfn_type_p2m(p2m, gfn_x(gfn), p2mt, &a, p2m_unshare, NULL); if ( p2m_is_paging(*p2mt) ) { ASSERT(!p2m_is_nestedp2m(p2m)); diff -r f1349a968a5a xen/arch/x86/mm/hap/guest_walk.c --- a/xen/arch/x86/mm/hap/guest_walk.c Fri Sep 02 14:56:26 2011 +0100 +++ b/xen/arch/x86/mm/hap/guest_walk.c Wed Sep 07 11:43:49 2011 +0100 @@ -59,7 +59,7 @@ unsigned long hap_p2m_ga_to_gfn(GUEST_PA /* Get the top-level table's MFN */ top_mfn = gfn_to_mfn_type_p2m(p2m, cr3 >> PAGE_SHIFT, - &p2mt, &p2ma, p2m_unshare); + &p2mt, &p2ma, p2m_unshare, NULL); if ( p2m_is_paging(p2mt) ) { ASSERT(!p2m_is_nestedp2m(p2m)); @@ -92,7 +92,7 @@ unsigned long hap_p2m_ga_to_gfn(GUEST_PA if ( missing == 0 ) { gfn_t gfn = guest_l1e_get_gfn(gw.l1e); - gfn_to_mfn_type_p2m(p2m, gfn_x(gfn), &p2mt, &p2ma, p2m_unshare); + gfn_to_mfn_type_p2m(p2m, gfn_x(gfn), &p2mt, &p2ma, p2m_unshare, NULL); if ( p2m_is_paging(p2mt) ) { ASSERT(!p2m_is_nestedp2m(p2m)); diff -r f1349a968a5a xen/arch/x86/mm/hap/nested_hap.c --- a/xen/arch/x86/mm/hap/nested_hap.c Fri Sep 02 14:56:26 2011 +0100 +++ b/xen/arch/x86/mm/hap/nested_hap.c Wed Sep 07 11:43:49 2011 +0100 @@ -136,7 +136,8 @@ nestedhap_walk_L0_p2m(struct p2m_domain p2m_access_t p2ma; /* walk L0 P2M table */ - mfn = gfn_to_mfn_type_p2m(p2m, L1_gpa >> PAGE_SHIFT, &p2mt, &p2ma, p2m_query); + mfn = gfn_to_mfn_type_p2m(p2m, L1_gpa >> PAGE_SHIFT, &p2mt, &p2ma, + p2m_query, NULL); if ( p2m_is_paging(p2mt) || p2m_is_shared(p2mt) || !p2m_is_ram(p2mt) ) return NESTEDHVM_PAGEFAULT_ERROR; diff -r f1349a968a5a xen/arch/x86/mm/p2m-ept.c --- a/xen/arch/x86/mm/p2m-ept.c Fri Sep 02 14:56:26 2011 +0100 +++ b/xen/arch/x86/mm/p2m-ept.c Wed Sep 07 11:43:49 2011 +0100 @@ -509,7 +509,7 @@ out: /* Read ept p2m entries */ static mfn_t ept_get_entry(struct p2m_domain *p2m, unsigned long gfn, p2m_type_t *t, p2m_access_t* a, - p2m_query_t q) + p2m_query_t q, unsigned int *page_order) { struct domain *d = p2m->domain; ept_entry_t *table = map_domain_page(ept_get_asr(d)); @@ -596,6 +596,9 @@ static mfn_t ept_get_entry(struct p2m_do ((1 << (i * EPT_TABLE_ORDER)) - 1)); mfn = _mfn(split_mfn); } + + if ( page_order ) + *page_order = i * EPT_TABLE_ORDER; } out: diff -r f1349a968a5a xen/arch/x86/mm/p2m-pt.c --- a/xen/arch/x86/mm/p2m-pt.c Fri Sep 02 14:56:26 2011 +0100 +++ b/xen/arch/x86/mm/p2m-pt.c Wed Sep 07 11:43:49 2011 +0100 @@ -503,7 +503,8 @@ static int p2m_pod_check_and_populate(st /* Read the current domain's p2m table (through the linear mapping). */ static mfn_t p2m_gfn_to_mfn_current(struct p2m_domain *p2m, unsigned long gfn, p2m_type_t *t, - p2m_access_t *a, p2m_query_t q) + p2m_access_t *a, p2m_query_t q, + unsigned int *page_order) { mfn_t mfn = _mfn(INVALID_MFN); p2m_type_t p2mt = p2m_mmio_dm; @@ -567,6 +568,8 @@ pod_retry_l3: else p2mt = p2m_mmio_dm; + if ( page_order ) + *page_order = PAGE_ORDER_1G; goto out; } #endif @@ -620,6 +623,8 @@ pod_retry_l2: else p2mt = p2m_mmio_dm; + if ( page_order ) + *page_order = PAGE_ORDER_2M; goto out; } @@ -669,6 +674,8 @@ pod_retry_l1: p2mt = p2m_mmio_dm; } + if ( page_order ) + *page_order = PAGE_ORDER_4K; out: *t = p2mt; return mfn; @@ -676,7 +683,8 @@ out: static mfn_t p2m_gfn_to_mfn(struct p2m_domain *p2m, unsigned long gfn, - p2m_type_t *t, p2m_access_t *a, p2m_query_t q) + p2m_type_t *t, p2m_access_t *a, p2m_query_t q, + unsigned int *page_order) { mfn_t mfn; paddr_t addr = ((paddr_t)gfn) << PAGE_SHIFT; @@ -699,7 +707,7 @@ p2m_gfn_to_mfn(struct p2m_domain *p2m, u /* Use the fast path with the linear mapping if we can */ if ( p2m == p2m_get_hostp2m(current->domain) ) - return p2m_gfn_to_mfn_current(p2m, gfn, t, a, q); + return p2m_gfn_to_mfn_current(p2m, gfn, t, a, q, page_order); mfn = pagetable_get_mfn(p2m_get_pagetable(p2m)); @@ -753,6 +761,8 @@ pod_retry_l3: unmap_domain_page(l3e); ASSERT(mfn_valid(mfn) || !p2m_is_ram(*t)); + if ( page_order ) + *page_order = PAGE_ORDER_1G; return (p2m_is_valid(*t)) ? mfn : _mfn(INVALID_MFN); } @@ -787,6 +797,8 @@ pod_retry_l2: unmap_domain_page(l2e); ASSERT(mfn_valid(mfn) || !p2m_is_ram(*t)); + if ( page_order ) + *page_order = PAGE_ORDER_2M; return (p2m_is_valid(*t)) ? mfn : _mfn(INVALID_MFN); } @@ -817,6 +829,8 @@ pod_retry_l1: unmap_domain_page(l1e); ASSERT(mfn_valid(mfn) || !p2m_is_ram(*t)); + if ( page_order ) + *page_order = PAGE_ORDER_4K; return (p2m_is_valid(*t) || p2m_is_grant(*t)) ? mfn : _mfn(INVALID_MFN); } diff -r f1349a968a5a xen/arch/x86/mm/p2m.c --- a/xen/arch/x86/mm/p2m.c Fri Sep 02 14:56:26 2011 +0100 +++ b/xen/arch/x86/mm/p2m.c Wed Sep 07 11:43:49 2011 +0100 @@ -307,7 +307,7 @@ void p2m_teardown(struct p2m_domain *p2m #ifdef __x86_64__ for ( gfn=0; gfn < p2m->max_mapped_pfn; gfn++ ) { - mfn = gfn_to_mfn_type_p2m(p2m, gfn, &t, &a, p2m_query); + mfn = gfn_to_mfn_type_p2m(p2m, gfn, &t, &a, p2m_query, NULL); if ( mfn_valid(mfn) && (t == p2m_ram_shared) ) { ASSERT(!p2m_is_nestedp2m(p2m)); @@ -372,7 +372,7 @@ p2m_remove_page(struct p2m_domain *p2m, { for ( i = 0; i < (1UL << page_order); i++ ) { - mfn_return = p2m->get_entry(p2m, gfn + i, &t, &a, p2m_query); + mfn_return = p2m->get_entry(p2m, gfn + i, &t, &a, p2m_query, NULL); if ( !p2m_is_grant(t) ) set_gpfn_from_mfn(mfn+i, INVALID_M2P_ENTRY); ASSERT( !p2m_is_valid(t) || mfn + i == mfn_x(mfn_return) ); @@ -877,7 +877,7 @@ void p2m_mem_access_check(unsigned long /* First, handle rx2rw conversion automatically */ p2m_lock(p2m); - mfn = p2m->get_entry(p2m, gfn, &p2mt, &p2ma, p2m_query); + mfn = p2m->get_entry(p2m, gfn, &p2mt, &p2ma, p2m_query, NULL); if ( access_w && p2ma == p2m_access_rx2rw ) { @@ -1035,7 +1035,7 @@ int p2m_get_mem_access(struct domain *d, return 0; } - mfn = p2m->get_entry(p2m, pfn, &t, &a, p2m_query); + mfn = p2m->get_entry(p2m, pfn, &t, &a, p2m_query, NULL); if ( mfn_x(mfn) == INVALID_MFN ) return -ESRCH; diff -r f1349a968a5a xen/include/asm-x86/p2m.h --- a/xen/include/asm-x86/p2m.h Fri Sep 02 14:56:26 2011 +0100 +++ b/xen/include/asm-x86/p2m.h Wed Sep 07 11:43:49 2011 +0100 @@ -233,7 +233,8 @@ struct p2m_domain { unsigned long gfn, p2m_type_t *p2mt, p2m_access_t *p2ma, - p2m_query_t q); + p2m_query_t q, + unsigned int *page_order); void (*change_entry_type_global)(struct p2m_domain *p2m, p2m_type_t ot, p2m_type_t nt); @@ -303,10 +304,14 @@ struct p2m_domain *p2m_get_p2m(struct vc /* Read a particular P2M table, mapping pages as we go. Most callers * should _not_ call this directly; use the other gfn_to_mfn_* functions * below unless you know you want to walk a p2m that isn't a domain's - * main one. */ + * main one. + * If the lookup succeeds, the return value is != INVALID_MFN and + * *page_order is filled in with the order of the superpage (if any) that + * the entry was found in. */ static inline mfn_t gfn_to_mfn_type_p2m(struct p2m_domain *p2m, unsigned long gfn, - p2m_type_t *t, p2m_access_t *a, p2m_query_t q) + p2m_type_t *t, p2m_access_t *a, p2m_query_t q, + unsigned int *page_order) { mfn_t mfn; @@ -318,14 +323,14 @@ gfn_to_mfn_type_p2m(struct p2m_domain *p return _mfn(gfn); } - mfn = p2m->get_entry(p2m, gfn, t, a, q); + mfn = p2m->get_entry(p2m, gfn, t, a, q, page_order); #ifdef __x86_64__ if ( q == p2m_unshare && p2m_is_shared(*t) ) { ASSERT(!p2m_is_nestedp2m(p2m)); mem_sharing_unshare_page(p2m->domain, gfn, 0); - mfn = p2m->get_entry(p2m, gfn, t, a, q); + mfn = p2m->get_entry(p2m, gfn, t, a, q, page_order); } #endif @@ -349,7 +354,7 @@ static inline mfn_t gfn_to_mfn_type(stru p2m_query_t q) { p2m_access_t a; - return gfn_to_mfn_type_p2m(p2m_get_hostp2m(d), gfn, t, &a, q); + return gfn_to_mfn_type_p2m(p2m_get_hostp2m(d), gfn, t, &a, q, NULL); } /* Syntactic sugar: most callers will use one of these. --pf9I7BMVVzbSWLtt Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: attachment; filename=paging-order x86/mm: adjust paging interface to return superpage sizes to the caller of paging_ga_to_gfn_cr3() Signed-off-by: Christoph Egger Signed-off-by: Tim Deegan diff -r e6ae91f100d0 xen/arch/x86/mm/hap/guest_walk.c --- a/xen/arch/x86/mm/hap/guest_walk.c Wed Sep 07 11:43:49 2011 +0100 +++ b/xen/arch/x86/mm/hap/guest_walk.c Wed Sep 07 14:09:01 2011 +0100 @@ -43,12 +43,12 @@ unsigned long hap_gva_to_gfn(GUEST_PAGIN struct vcpu *v, struct p2m_domain *p2m, unsigned long gva, uint32_t *pfec) { unsigned long cr3 = v->arch.hvm_vcpu.guest_cr[3]; - return hap_p2m_ga_to_gfn(GUEST_PAGING_LEVELS)(v, p2m, cr3, gva, pfec); + return hap_p2m_ga_to_gfn(GUEST_PAGING_LEVELS)(v, p2m, cr3, gva, pfec, NULL); } unsigned long hap_p2m_ga_to_gfn(GUEST_PAGING_LEVELS)( struct vcpu *v, struct p2m_domain *p2m, unsigned long cr3, - paddr_t ga, uint32_t *pfec) + paddr_t ga, uint32_t *pfec, unsigned int *page_order) { uint32_t missing; mfn_t top_mfn; @@ -107,6 +108,9 @@ unsigned long hap_p2m_ga_to_gfn(GUEST_PA return INVALID_GFN; } + if ( page_order ) + *page_order = guest_walk_to_page_order(&gw); + return gfn_x(gfn); } diff -r e6ae91f100d0 xen/arch/x86/mm/hap/hap.c --- a/xen/arch/x86/mm/hap/hap.c Wed Sep 07 11:43:49 2011 +0100 +++ b/xen/arch/x86/mm/hap/hap.c Wed Sep 07 14:09:01 2011 +0100 @@ -897,8 +897,10 @@ static unsigned long hap_gva_to_gfn_real static unsigned long hap_p2m_ga_to_gfn_real_mode( struct vcpu *v, struct p2m_domain *p2m, unsigned long cr3, - paddr_t ga, uint32_t *pfec) + paddr_t ga, uint32_t *pfec, unsigned int *page_order) { + if ( page_order ) + *page_order = PAGE_ORDER_4K; return (ga >> PAGE_SHIFT); } diff -r e6ae91f100d0 xen/arch/x86/mm/hap/nested_hap.c --- a/xen/arch/x86/mm/hap/nested_hap.c Wed Sep 07 11:43:49 2011 +0100 +++ b/xen/arch/x86/mm/hap/nested_hap.c Wed Sep 07 14:09:01 2011 +0100 @@ -162,7 +162,7 @@ nestedhap_walk_L1_p2m(struct vcpu *v, pa nested_cr3 = nhvm_vcpu_hostcr3(v); /* Walk the guest-supplied NPT table, just as if it were a pagetable */ - gfn = paging_ga_to_gfn_cr3(v, nested_cr3, L2_gpa, &pfec); + gfn = paging_ga_to_gfn_cr3(v, nested_cr3, L2_gpa, &pfec, NULL); if ( gfn == INVALID_GFN ) return NESTEDHVM_PAGEFAULT_INJECT; diff -r e6ae91f100d0 xen/arch/x86/mm/hap/private.h --- a/xen/arch/x86/mm/hap/private.h Wed Sep 07 11:43:49 2011 +0100 +++ b/xen/arch/x86/mm/hap/private.h Wed Sep 07 14:09:01 2011 +0100 @@ -40,12 +40,12 @@ unsigned long hap_gva_to_gfn_4_levels(st unsigned long hap_p2m_ga_to_gfn_2_levels(struct vcpu *v, struct p2m_domain *p2m, unsigned long cr3, - paddr_t ga, uint32_t *pfec); + paddr_t ga, uint32_t *pfec, unsigned int *page_order); unsigned long hap_p2m_ga_to_gfn_3_levels(struct vcpu *v, struct p2m_domain *p2m, unsigned long cr3, - paddr_t ga, uint32_t *pfec); + paddr_t ga, uint32_t *pfec, unsigned int *page_order); unsigned long hap_p2m_ga_to_gfn_4_levels(struct vcpu *v, struct p2m_domain *p2m, unsigned long cr3, - paddr_t ga, uint32_t *pfec); + paddr_t ga, uint32_t *pfec, unsigned int *page_order); #endif /* __HAP_PRIVATE_H__ */ diff -r e6ae91f100d0 xen/arch/x86/mm/p2m.c --- a/xen/arch/x86/mm/p2m.c Wed Sep 07 11:43:49 2011 +0100 +++ b/xen/arch/x86/mm/p2m.c Wed Sep 07 14:09:01 2011 +0100 @@ -1205,7 +1205,7 @@ unsigned long paging_gva_to_gfn(struct v /* translate l2 guest gfn into l1 guest gfn */ return hostmode->p2m_ga_to_gfn(v, hostp2m, ncr3, - gfn << PAGE_SHIFT, pfec); + gfn << PAGE_SHIFT, pfec, NULL); } return hostmode->gva_to_gfn(v, hostp2m, va, pfec); diff -r e6ae91f100d0 xen/include/asm-x86/guest_pt.h --- a/xen/include/asm-x86/guest_pt.h Wed Sep 07 11:43:49 2011 +0100 +++ b/xen/include/asm-x86/guest_pt.h Wed Sep 07 14:09:01 2011 +0100 @@ -272,6 +272,24 @@ guest_walk_to_gpa(walk_t *gw) return guest_l1e_get_paddr(gw->l1e) + (gw->va & ~PAGE_MASK); } +/* Given a walk_t from a successful walk, return the page-order of the + * page or superpage that the virtual address is in. */ +static inline unsigned int +guest_walk_to_page_order(walk_t *gw) +{ + /* This is only valid for successful walks - otherwise the + * PSE bits might be invalid. */ + ASSERT(guest_l1e_get_flags(gw->l1e) & _PAGE_PRESENT); +#if GUEST_PAGING_LEVELS >= 3 + if ( guest_l3e_get_flags(gw->l3e) & _PAGE_PSE ) + return GUEST_L3_PAGETABLE_SHIFT - PAGE_SHIFT; +#endif + if ( guest_l2e_get_flags(gw->l2e) & _PAGE_PSE ) + return GUEST_L2_PAGETABLE_SHIFT - PAGE_SHIFT; + return GUEST_L1_PAGETABLE_SHIFT - PAGE_SHIFT; +} + + /* Walk the guest pagetables, after the manner of a hardware walker. * * Inputs: a vcpu, a virtual address, a walk_t to fill, a diff -r e6ae91f100d0 xen/include/asm-x86/paging.h --- a/xen/include/asm-x86/paging.h Wed Sep 07 11:43:49 2011 +0100 +++ b/xen/include/asm-x86/paging.h Wed Sep 07 14:09:01 2011 +0100 @@ -115,7 +115,8 @@ struct paging_mode { unsigned long (*p2m_ga_to_gfn )(struct vcpu *v, struct p2m_domain *p2m, unsigned long cr3, - paddr_t ga, uint32_t *pfec); + paddr_t ga, uint32_t *pfec, + unsigned int *page_order); void (*update_cr3 )(struct vcpu *v, int do_locking); void (*update_paging_modes )(struct vcpu *v); void (*write_p2m_entry )(struct vcpu *v, unsigned long gfn, @@ -270,15 +271,18 @@ unsigned long paging_gva_to_gfn(struct v * to by nested HAP code, to walk the guest-supplied NPT tables as if * they were pagetables. * Use 'paddr_t' for the guest address so it won't overflow when - * guest or nested guest is in 32bit PAE mode. - */ + * l1 or l2 guest is in 32bit PAE mode. + * If the GFN returned is not INVALID_GFN, *page_order gives + * the size of the superpage (if any) it was found in. */ static inline unsigned long paging_ga_to_gfn_cr3(struct vcpu *v, unsigned long cr3, paddr_t ga, - uint32_t *pfec) + uint32_t *pfec, + unsigned int *page_order) { struct p2m_domain *p2m = v->domain->arch.p2m; - return paging_get_hostmode(v)->p2m_ga_to_gfn(v, p2m, cr3, ga, pfec); + return paging_get_hostmode(v)->p2m_ga_to_gfn(v, p2m, cr3, ga, pfec, + page_order); } /* Update all the things that are derived from the guest's CR3. --pf9I7BMVVzbSWLtt Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: attachment; filename=nestedhap-order x86/mm: use new page-order interfaces in nested HAP code to make 2M and 1G mappings in the nested p2m tables. Signed-off-by: Christoph Egger Signed-off-by: Tim Deegan diff -r 3ccbaa111cb8 xen/arch/x86/mm/hap/nested_hap.c --- a/xen/arch/x86/mm/hap/nested_hap.c Wed Sep 07 14:26:44 2011 +0100 +++ b/xen/arch/x86/mm/hap/nested_hap.c Wed Sep 07 14:27:57 2011 +0100 @@ -99,7 +99,7 @@ nestedp2m_write_p2m_entry(struct p2m_dom static void nestedhap_fix_p2m(struct vcpu *v, struct p2m_domain *p2m, paddr_t L2_gpa, paddr_t L0_gpa, - p2m_type_t p2mt, p2m_access_t p2ma) + unsigned int page_order, p2m_type_t p2mt, p2m_access_t p2ma) { int rv = 1; ASSERT(p2m); @@ -111,9 +111,20 @@ nestedhap_fix_p2m(struct vcpu *v, struct * leave it alone. We'll pick up the right one as we try to * vmenter the guest. */ if ( p2m->cr3 == nhvm_vcpu_hostcr3(v) ) - rv = set_p2m_entry(p2m, L2_gpa >> PAGE_SHIFT, - page_to_mfn(maddr_to_page(L0_gpa)), - 0 /*4K*/, p2mt, p2ma); + { + unsigned long gfn, mask; + mfn_t mfn; + + /* If this is a superpage mapping, round down both addresses + * to the start of the superpage. */ + mask = ~((1UL << page_order) - 1); + + gfn = (L2_gpa >> PAGE_SHIFT) & mask; + mfn = _mfn((L0_gpa >> PAGE_SHIFT) & mask); + + rv = set_p2m_entry(p2m, gfn, mfn, page_order, p2mt, p2ma); + } + p2m_unlock(p2m); if (rv == 0) { @@ -129,7 +140,8 @@ nestedhap_fix_p2m(struct vcpu *v, struct * value tells the upper level what to do. */ static int -nestedhap_walk_L0_p2m(struct p2m_domain *p2m, paddr_t L1_gpa, paddr_t *L0_gpa) +nestedhap_walk_L0_p2m(struct p2m_domain *p2m, paddr_t L1_gpa, paddr_t *L0_gpa, + unsigned int *page_order) { mfn_t mfn; p2m_type_t p2mt; @@ -137,7 +149,7 @@ nestedhap_walk_L0_p2m(struct p2m_domain /* walk L0 P2M table */ mfn = gfn_to_mfn_type_p2m(p2m, L1_gpa >> PAGE_SHIFT, &p2mt, &p2ma, - p2m_query, NULL); + p2m_query, page_order); if ( p2m_is_paging(p2mt) || p2m_is_shared(p2mt) || !p2m_is_ram(p2mt) ) return NESTEDHVM_PAGEFAULT_ERROR; @@ -154,7 +166,8 @@ nestedhap_walk_L0_p2m(struct p2m_domain * L1_gpa. The result value tells what to do next. */ static int -nestedhap_walk_L1_p2m(struct vcpu *v, paddr_t L2_gpa, paddr_t *L1_gpa) +nestedhap_walk_L1_p2m(struct vcpu *v, paddr_t L2_gpa, paddr_t *L1_gpa, + unsigned int *page_order) { uint32_t pfec; unsigned long nested_cr3, gfn; @@ -162,7 +175,7 @@ nestedhap_walk_L1_p2m(struct vcpu *v, pa nested_cr3 = nhvm_vcpu_hostcr3(v); /* Walk the guest-supplied NPT table, just as if it were a pagetable */ - gfn = paging_ga_to_gfn_cr3(v, nested_cr3, L2_gpa, &pfec, NULL); + gfn = paging_ga_to_gfn_cr3(v, nested_cr3, L2_gpa, &pfec, page_order); if ( gfn == INVALID_GFN ) return NESTEDHVM_PAGEFAULT_INJECT; @@ -183,12 +196,13 @@ nestedhvm_hap_nested_page_fault(struct v paddr_t L1_gpa, L0_gpa; struct domain *d = v->domain; struct p2m_domain *p2m, *nested_p2m; + unsigned int page_order_21, page_order_10, page_order_20; p2m = p2m_get_hostp2m(d); /* L0 p2m */ nested_p2m = p2m_get_nestedp2m(v, nhvm_vcpu_hostcr3(v)); /* walk the L1 P2M table */ - rv = nestedhap_walk_L1_p2m(v, L2_gpa, &L1_gpa); + rv = nestedhap_walk_L1_p2m(v, L2_gpa, &L1_gpa, &page_order_21); /* let caller to handle these two cases */ switch (rv) { @@ -204,7 +218,7 @@ nestedhvm_hap_nested_page_fault(struct v } /* ==> we have to walk L0 P2M */ - rv = nestedhap_walk_L0_p2m(p2m, L1_gpa, &L0_gpa); + rv = nestedhap_walk_L0_p2m(p2m, L1_gpa, &L0_gpa, &page_order_10); /* let upper level caller to handle these two cases */ switch (rv) { @@ -219,8 +233,10 @@ nestedhvm_hap_nested_page_fault(struct v break; } + page_order_20 = min(page_order_21, page_order_10); + /* fix p2m_get_pagetable(nested_p2m) */ - nestedhap_fix_p2m(v, nested_p2m, L2_gpa, L0_gpa, + nestedhap_fix_p2m(v, nested_p2m, L2_gpa, L0_gpa, page_order_20, p2m_ram_rw, p2m_access_rwx /* FIXME: Should use same permission as l1 guest */); --pf9I7BMVVzbSWLtt Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel --pf9I7BMVVzbSWLtt-- From xen-devel-bounces@lists.xensource.com Wed Sep 07 06:52:05 2011 Return-path: Envelope-to: www-data@lists.xensource.com Delivery-date: Wed, 07 Sep 2011 06:52:05 -0700 Received: from localhost ([127.0.0.1] helo=lists.colo.xensource.com) by lists.xensource.com with esmtp (Exim 4.43) id 1R1IXt-0005Mb-6s; Wed, 07 Sep 2011 06:52:05 -0700 Received: from mail174.messagelabs.com ([85.158.138.51]) by lists.xensource.com with esmtp (Exim 4.43) id 1R1IXL-00059q-Dd for xen-devel@lists.xensource.com; Wed, 07 Sep 2011 06:51:31 -0700 X-Env-Sender: konrad@dumpdata.com X-Msg-Ref: server-10.tower-174.messagelabs.com!1315403474!30568981!1 X-Originating-IP: [148.87.113.117] X-StarScan-Version: 6.3.6; banners=-,-,- X-VirusChecked: Checked Received: (qmail 5490 invoked from network); 7 Sep 2011 13:51:24 -0000 Received: from rcsinet15.oracle.com (HELO rcsinet15.oracle.com) (148.87.113.117) by server-10.tower-174.messagelabs.com with DHE-RSA-AES256-SHA encrypted SMTP; 7 Sep 2011 13:51:24 -0000 Received: from acsinet22.oracle.com (acsinet22.oracle.com [141.146.126.238]) by rcsinet15.oracle.com (Switch-3.4.4/Switch-3.4.4) with ESMTP id p87Dp5tW002989 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Wed, 7 Sep 2011 13:51:07 GMT Received: from acsmt357.oracle.com (acsmt357.oracle.com [141.146.40.157]) by acsinet22.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id p87Dp4TT011696 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 7 Sep 2011 13:51:05 GMT Received: from abhmt117.oracle.com (abhmt117.oracle.com [141.146.116.69]) by acsmt357.oracle.com (8.12.11.20060308/8.12.11) with ESMTP id p87DoxU3015068; Wed, 7 Sep 2011 08:50:59 -0500 Received: from phenom (/209.6.55.207) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Wed, 07 Sep 2011 06:50:59 -0700 Received: by phenom (Postfix, from userid 1000) id 093C410B8; Wed, 7 Sep 2011 09:50:47 -0400 (EDT) Date: Wed, 7 Sep 2011 09:50:47 -0400 From: Konrad Rzeszutek Wilk To: Andreas Olsowski Subject: Re: [Xen-devel] xen/stable-2.6.32.x xen-4.1.1 live migration fails with kernels 2.6.39, 3.0.3 and 3.1-rc2 Message-ID: <20110907135046.GD32190@dumpdata.com> References: <4E4EA3E2.2040809@leuphana.de> <4E52224902000078000525CC@nat28.tlf.novell.com> <4E52601B.5060609@leuphana.de> <20110824203435.GA27865@dumpdata.com> <4E55F682.8060405@leuphana.de> <20110826150054.GA1793@dumpdata.com> <4E57D745.2080701@leuphana.de> <20110829194911.GC16530@dumpdata.com> <4E5E320A.60401@leuphana.de> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <4E5E320A.60401@leuphana.de> User-Agent: Mutt/1.5.21 (2010-09-15) X-Source-IP: acsinet22.oracle.com [141.146.126.238] X-Auth-Type: Internal IP X-CT-RefId: str=0001.0A090206.4E6776CB.0194:SCFMA922111,ss=1,re=-4.000,fgs=0 Cc: "xen-devel@lists.xensource.com" X-BeenThere: xen-devel@lists.xensource.com X-Mailman-Version: 2.1.5 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xensource.com Errors-To: xen-devel-bounces@lists.xensource.com On Wed, Aug 31, 2011 at 03:07:22PM +0200, Andreas Olsowski wrote: > A little update, i now have all machines running on xen-4.1-testing > with xen/stable-2.6.32.x > That gave me the possiblity for additional tests. > > (I also tested xm/xend in addtion to xl/libxl, to make sure its not > a xl/libxl problem.) > > I took the liberty to create a new test result matrix that should > provide a better overview (in case someone else wants to get the > whole picture): So.. I don't think the issue I am seeing is exactly the same. This is what 'xl' gives me: :~/ > xl migrate 3 tst010 root@tst010's password: migration target: Ready to receive domain. Saving to migration stream new xl format (info 0x0/0x0/326) Loading new save file incoming migration stream (new xl fmt info 0x0/0x0/326) Savefile contains xl domain config xc: Saving memory: iter 0 (last sent 0 skipped 0): 262400/262400 100% xc: Saving memory: iter 2 (last sent 1105 skipped 23): 262400/262400 100% xc: Saving memory: iter 3 (last sent 74 skipped 0): 262400/262400 100% xc: Saving memory: iter 4 (last sent 0 skipped 0): 262400/262400 100% xc: error: unexpected PFN mapping failure pfn 19d0 map_mfn 4e7e04 p2m_mfn 4e7e04: Internal error libxl: error: libxl_dom.c:363:libxl__domain_restore_common: restoring domain: Resource temporarily unavailable libxl: error: libxl_create.c:483:do_domain_create: cannot (re-)build domain: -3 libxl: error: libxl.c:733:libxl_domain_destroy: non-existant domain 4 migration target: Domain creation failed (code -3). libxl: error: libxl_utils.c:410:libxl_read_exactly: file/stream truncated reading ready message from migration receiver stream libxl: info: libxl_exec.c:125:libxl_report_child_exitstatus: migration target process [5810] exited with error status 3 Migration failed, resuming at sender. And on the receiving side (tst010) I get a monster off: (XEN) mm.c:945:d0 Error getting mfn 4e7e04 (pfn ffffffffffffffff) from L1 entry 80000004e7e04627 for l1e_owner=0, pg_owner=4 XEN) mm.c:945:d0 Error getting mfn 36fd19 (pfn ffffffffffffffff) from L1 entry 800000036fd19627 for l1e_owner=0, pg_owner=4 (XEN) mm.c:945:d0 Error getting mfn 36f583 (pfn ffffffffffffffff) from L1 entry 800000036f583627 for l1e_owner=0, pg_owner=4 .. (XEN) mm.c:945:d0 Error getting mfn 4e7d09 (pfn ffffffffffffffff) from L1 entry 80000004e7d09627 for l1e_owner=0, pg_owner=4 (XEN) event_channel.c:250:d3 EVTCHNOP failure: error -17 The migration is from a 4GB box to a 32GB box (worked), then back to the 4GB( worked) and then back to the 32GB (boom!). anyhow, let me try this with 4.1-testing branch. Running on the bleeding edge might not be the best idea sometimes. > > #################################################################### > ##### xen 4.1 live migration fails between different platforms ##### > #################################################################### > XEN: xen-4.1-testing.hg > dom0: xen/stable-2.6.32.x > domU: linux-2.6.39 vanilla (also 3.0.3 and 3.1) > > toolstack: xl/libxl > (at least FAIL type1 also occurs with xm/xend) > > # create means the guest has been created by this host > # received means the guest has been migrate-received by this host > > XEN: xen-4.1-testing.hg > dom0: xen/stable-2.6.32.x > domU: linux-2.6.39 vanilla (also 3.0.3 and 3.1) > > toolstack: xl/libxl > (at least FAIL type1 also occurs with xm/xend) > > > # Dell PE 2950 and Dell PE 2950 > create pe2950-1 -> pe2950-2 OK > received pe2950-2 -> pe2950-1 OK > create pe2950-2 -> pe2950-1 OK > received pe2950-1 -> pe2950-2 OK > > # Dell PE 2950 and Dell R710 > create pe2950-1 -> r710 OK > received r710 -> pe2950-1 OK > create r710 -> pe2950-1 FAIL (type 1): http://pastebin.com/iUeNPQyY > > # Dell PE 2950 and Dell R610 > create pe2950-1 -> r610-1 FAIL (type 2): http://pastebin.com/fzMkuS5s > create r610-1 -> pe2950-1 FAIL (type 1): http://pastebin.com/Lq6SGVPj > > # Dell R610 and Dell R610 > create r610-1 -> r610-2 OK > received r610-2 -> r610-1 OK > > create r610-2 -> r610-1 OK > received r610-1 -> r610-2 OK > > # Dell R610 and Dell R710 > create r610-1 -> r710 OK > received r710 -> r610-1 OK > > create r710 -> r610-1 FAIL (type 2): http://pastebin.com/eff5Yx0C > > # Dell PE 2950 and Dell R710 and Dell R610 > create pe2950-2 -> r710 OK > received r710 -> r610 FAIL (type 2): http://pastebin.com/it7QPsJk > > create r610 -> r710 OK > received r710 -> pe2950-2 FAIL (type 1 derived?): > http://pastebin.com/R6pXSJpU > > #EOF > > with best regards > > Andreas > > _______________________________________________ > Xen-devel mailing list > Xen-devel@lists.xensource.com > http://lists.xensource.com/xen-devel _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel From xen-devel-bounces@lists.xensource.com Wed Sep 07 06:54:33 2011 Return-path: Envelope-to: www-data@lists.xensource.com Delivery-date: Wed, 07 Sep 2011 06:54:33 -0700 Received: from localhost ([127.0.0.1] helo=lists.colo.xensource.com) by lists.xensource.com with esmtp (Exim 4.43) id 1R1IaG-0005kw-T8; Wed, 07 Sep 2011 06:54:32 -0700 Received: from mail21.messagelabs.com ([85.158.143.35]) by lists.xensource.com with smtp (Exim 4.43) id 1R1IZk-0005YH-5M for xen-devel@lists.xensource.com; Wed, 07 Sep 2011 06:54:00 -0700 X-Env-Sender: dzickus@redhat.com X-Msg-Ref: server-15.tower-21.messagelabs.com!1315403637!49681411!1 X-Originating-IP: [209.132.183.28] X-StarScan-Version: 6.3.6; banners=-,-,- X-VirusChecked: Checked Received: (qmail 27628 invoked from network); 7 Sep 2011 13:53:57 -0000 Received: from mx1.redhat.com (HELO mx1.redhat.com) (209.132.183.28) by server-15.tower-21.messagelabs.com with SMTP; 7 Sep 2011 13:53:57 -0000 Received: from int-mx09.intmail.prod.int.phx2.redhat.com (int-mx09.intmail.prod.int.phx2.redhat.com [10.5.11.22]) by mx1.redhat.com (8.14.4/8.14.4) with ESMTP id p87DlfFs014159 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Wed, 7 Sep 2011 09:47:41 -0400 Received: from redhat.com (dhcp-100-19-141.bos.redhat.com [10.16.19.141]) by int-mx09.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with SMTP id p87DiBJZ030330; Wed, 7 Sep 2011 09:44:12 -0400 Date: Wed, 7 Sep 2011 09:44:11 -0400 From: Don Zickus To: Avi Kivity Message-ID: <20110907134411.GV5795@redhat.com> References: <38bb37e15f6e5056d5238adac945bc1837a996ec.1314922370.git.jeremy.fitzhardinge@citrix.com> <1314974826.1861.1.camel@twins> <4E612EA1.20007@goop.org> <1314996468.8255.0.camel@twins> <4E614FBD.2030509@goop.org> <20110906151408.GA7459@redhat.com> <4E66615E.8070806@goop.org> <20110906182758.GR5795@redhat.com> <4E66EF86.9070200@redhat.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <4E66EF86.9070200@redhat.com> User-Agent: Mutt/1.5.21 (2010-09-15) X-Scanned-By: MIMEDefang 2.68 on 10.5.11.22 Cc: Jeremy Fitzhardinge , Marcelo Tosatti , Nick Piggin , KVM , Stefano Stabellini , Peter Zijlstra , the arch/x86 maintainers , Linux Kernel Mailing List , Andi Kleen , Jeremy Fitzhardinge , "H. Peter Anvin" , Ingo Molnar , Linus Torvalds , Xen Devel Subject: [Xen-devel] Re: [PATCH 08/13] xen/pvticketlock: disable interrupts while blocking X-BeenThere: xen-devel@lists.xensource.com X-Mailman-Version: 2.1.5 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xensource.com Errors-To: xen-devel-bounces@lists.xensource.com On Wed, Sep 07, 2011 at 07:13:58AM +0300, Avi Kivity wrote: > On 09/06/2011 09:27 PM, Don Zickus wrote: > >On Tue, Sep 06, 2011 at 11:07:26AM -0700, Jeremy Fitzhardinge wrote: > >> >> But, erm, does that even make sense? I'm assuming the NMI reason port > >> >> tells the CPU why it got an NMI. If multiple CPUs can get NMIs and > >> >> there's only a single reason port, then doesn't that mean that either 1) > >> >> they all got the NMI for the same reason, or 2) having a single port is > >> >> inherently racy? How does the locking actually work there? > >> > The reason port is for an external/system NMI. All the IPI-NMI don't need > >> > to access this register to process their handlers, ie perf. I think in > >> > general the IOAPIC is configured to deliver the external NMI to one cpu, > >> > usually the bsp cpu. However, there has been a slow movement to free the > >> > bsp cpu from exceptions like this to allow one to eventually hot-swap the > >> > bsp cpu. The spin locks in that code were an attempt to be more abstract > >> > about who really gets the external NMI. Of course SGI's box is setup to > >> > deliver an external NMI to all cpus to dump the stack when the system > >> > isn't behaving. > >> > > >> > This is a very low usage NMI (in fact almost all cases lead to loud > >> > console messages). > >> > > >> > Hope that clears up some of the confusion. > >> > >> Hm, not really. > >> > >> What does it mean if two CPUs go down that path? Should one do some NMI > >> processing while the other waits around for it to finish, and then do > >> some NMI processing on its own? > > > >Well the time the second one gets to the external NMI it should have been > >cleared by the first cpu, which would of course lead to the second cpu > >causing a 'Dazed and confused' message. But on most x86 machines only one > >cpu should be routed the external NMI. Though there is an SGI box that is > >designed to send an external NMI to all of its cpus. > > Is there a way to tell whether an NMI was internally or externally > generated? > > I don't think so, especially as two or more NMIs can be coalesced. > So any NMI received on this first cpu has to check the NMI reason > port? Well we cheat and execute all the nmi handlers first. If they come back as handled, we skip the check for the external NMI. But you are right, other than checking the reason port, there isn't a way to determine if an NMI is internally or externally generated. > > >> > >> But on the other hand, I don't really care if you can say that this path > >> will never be called in a virtual machine. > > > >Does virtual machines support hot remove of cpus? Probably not > >considering bare-metal barely supports it. > > > > They do. But vcpus probably don't have the notion of a bsp cpu, so perhaps virtual machines can get away with it easier? (I don't know enough about the hot cpu remove code to really explain it, just enough to know it can cause problems and people are trying to address it). Cheers, Don _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel From xen-devel-bounces@lists.xensource.com Wed Sep 07 06:56:47 2011 Return-path: Envelope-to: www-data@lists.xensource.com Delivery-date: Wed, 07 Sep 2011 06:56:47 -0700 Received: from localhost ([127.0.0.1] helo=lists.colo.xensource.com) by lists.xensource.com with esmtp (Exim 4.43) id 1R1IcR-00069P-3y; Wed, 07 Sep 2011 06:56:47 -0700 Received: from mail21.messagelabs.com ([85.158.143.35]) by lists.xensource.com with esmtp (Exim 4.43) id 1R1Ibx-0005xD-8B for xen-devel@lists.xensource.com; Wed, 07 Sep 2011 06:56:17 -0700 X-Env-Sender: fajar@fajar.net X-Msg-Ref: server-5.tower-21.messagelabs.com!1315403741!47222816!1 X-Originating-IP: [209.85.213.43] X-StarScan-Version: 6.3.6; banners=-,-,- X-VirusChecked: Checked Received: (qmail 23292 invoked from network); 7 Sep 2011 13:55:42 -0000 Received: from mail-yw0-f43.google.com (HELO mail-yw0-f43.google.com) (209.85.213.43) by server-5.tower-21.messagelabs.com with RC4-SHA encrypted SMTP; 7 Sep 2011 13:55:42 -0000 Received: by ywm3 with SMTP id 3so264093ywm.30 for ; Wed, 07 Sep 2011 06:56:13 -0700 (PDT) MIME-Version: 1.0 Received: by 10.42.123.9 with SMTP id p9mr4416108icr.487.1315403772839; Wed, 07 Sep 2011 06:56:12 -0700 (PDT) Received: by 10.42.225.194 with HTTP; Wed, 7 Sep 2011 06:56:12 -0700 (PDT) In-Reply-To: <90F0F47595235141A4380FCF01B0185B2240FEADDE@CHN-HCLT-EVS07.HCLT.CORP.HCL.IN> References: <90F0F47595235141A4380FCF01B0185B20BC426222@CHN-HCLT-EVS07.HCLT.CORP.HCL.IN> <20110809195159.GA7834@dumpdata.com> <90F0F47595235141A4380FCF01B0185B20BC513BCB@CHN-HCLT-EVS07.HCLT.CORP.HCL.IN> <90F0F47595235141A4380FCF01B0185B20BC585A8A@CHN-HCLT-EVS07.HCLT.CORP.HCL.IN> <90F0F47595235141A4380FCF01B0185B20BC608BBC@CHN-HCLT-EVS07.HCLT.CORP.HCL.IN> <20110901134638.GB23971@dumpdata.com> <90F0F47595235141A4380FCF01B0185B2240FEA5E3@CHN-HCLT-EVS07.HCLT.CORP.HCL.IN> <20110906161258.GA5264@dumpdata.com> <90F0F47595235141A4380FCF01B0185B2240FEADDE@CHN-HCLT-EVS07.HCLT.CORP.HCL.IN> Date: Wed, 7 Sep 2011 20:56:12 +0700 Message-ID: Subject: Re: [Xen-devel] FW: HXEN on linux From: "Fajar A. Nugraha" To: "Deepak Kr. Sharma - ERS, HCL Tech" Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: "xen-devel@lists.xensource.com" X-BeenThere: xen-devel@lists.xensource.com X-Mailman-Version: 2.1.5 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xensource.com Errors-To: xen-devel-bounces@lists.xensource.com On Wed, Sep 7, 2011 at 7:19 PM, Deepak Kr. Sharma - ERS, HCL Tech wrote: > Hello Konrad, > > We are part of COE team and our priorities are driven by team that does t= echnology tracking (mix of sales and delivery). As recommended by them, Xen= is type-1 hypervisor and HXen is a type-2 hypervisor. Virtualization in a = product is a value-add service and not the core product functionality. No o= ne would want to touch a stable system (which is a must in case of type-1 h= ypervisor) for a value-add service. Hence, HXen gives flexibility to add fe= atures on VM w/o impacting product's core functionality. The biggest benefi= t with HXen is that it can be ported to any other OS without any changes to= the stable system. With that goal, I wonder why you choose hxen (which is not developed/maintained anymore, and has minimal or zero documentation) instead of virtualbox (which is available under GPL except for the extension pack, already supporting many host OS) or KVM (since you're going to use Linux anyway), both are still actively developed. Good luck though. --=20 Fajar _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel From xen-devel-bounces@lists.xensource.com Wed Sep 07 07:00:01 2011 Return-path: Envelope-to: www-data@lists.xensource.com Delivery-date: Wed, 07 Sep 2011 07:00:01 -0700 Received: from localhost ([127.0.0.1] helo=lists.colo.xensource.com) by lists.xensource.com with esmtp (Exim 4.43) id 1R1IfZ-0006aZ-GN; Wed, 07 Sep 2011 07:00:01 -0700 Received: from mail174.messagelabs.com ([85.158.138.51]) by lists.xensource.com with esmtp (Exim 4.43) id 1R1Ida-0006Mf-Aj for xen-devel@lists.xensource.com; Wed, 07 Sep 2011 06:57:59 -0700 X-Env-Sender: javier.manzano@edu.uah.es X-Msg-Ref: server-12.tower-174.messagelabs.com!1315403645!30562055!1 X-Originating-IP: [216.139.236.26] X-StarScan-Version: 6.3.6; banners=-,-,- X-VirusChecked: Checked Received: (qmail 5007 invoked from network); 7 Sep 2011 13:57:55 -0000 Received: from sam.nabble.com (HELO sam.nabble.com) (216.139.236.26) by server-12.tower-174.messagelabs.com with AES256-SHA encrypted SMTP; 7 Sep 2011 13:57:55 -0000 Received: from [192.168.236.26] (helo=sam.nabble.com) by sam.nabble.com with esmtp (Exim 4.72) (envelope-from ) id 1R1IZo-0003g5-HB for xen-devel@lists.xensource.com; Wed, 07 Sep 2011 06:54:04 -0700 Date: Wed, 7 Sep 2011 06:54:04 -0700 (PDT) From: JavMV To: xen-devel@lists.xensource.com Message-ID: <1315403644525-4778586.post@n5.nabble.com> In-Reply-To: <1315401901083-4778494.post@n5.nabble.com> References: <1314780568949-4753422.post@n5.nabble.com> <1314795401771-4754024.post@n5.nabble.com> <20110831151913.GE7276@reaktio.net> <1315231341254-4770602.post@n5.nabble.com> <1315310225039-4774097.post@n5.nabble.com> <1315343879.61837.YahooMailNeo@web29818.mail.ird.yahoo.com> <1315382742268-4777689.post@n5.nabble.com> <1315389138.56652.YahooMailNeo@web29801.mail.ird.yahoo.com> <1315398360680-4778339.post@n5.nabble.com> <1315401901083-4778494.post@n5.nabble.com> Subject: Re: Re : Re : [Xen-devel] Re: Patches for VGA-Passthrough XEN 4.2 unstable MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-BeenThere: xen-devel@lists.xensource.com X-Mailman-Version: 2.1.5 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xensource.com Errors-To: xen-devel-bounces@lists.xensource.com Congratulations! these are nice news ^^, I have two questions, first one for David: Did u just adapt my patches or did you add some new things to them? (By the way thank you for adapt them again, and for explain the dsdt modifications I have realised that I made a mistake, maybe now I can make it work for my GTX 460). The second one is for Komkom, would you mind to post a link for the changeset of xen 4.2 about the date of my patches? (the one you said you have tried before) I just want to know if my original pacthes are working too. Well, I'll work on this at the end of the month so I'll post here if this work also for my graphic card (GTX 460) and if this is fine I will adapt the patch for the secondary card to make you happier XD or maybe David is going to do this faster than me because Im bussy until end of this month. Best regards Javier Manzano ----- JavMV -- View this message in context: http://xen.1045712.n5.nabble.com/Patches-for-VGA-Passthrough-XEN-4-2-unstable-tp4406265p4778586.html Sent from the Xen - Dev mailing list archive at Nabble.com. _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel From xen-devel-bounces@lists.xensource.com Wed Sep 07 07:23:54 2011 Return-path: Envelope-to: www-data@lists.xensource.com Delivery-date: Wed, 07 Sep 2011 07:23:54 -0700 Received: from localhost ([127.0.0.1] helo=lists.colo.xensource.com) by lists.xensource.com with esmtp (Exim 4.43) id 1R1J2g-0007QE-34; Wed, 07 Sep 2011 07:23:54 -0700 Received: from mail21.messagelabs.com ([85.158.143.35]) by lists.xensource.com with smtp (Exim 4.43) id 1R1J1k-0007Cz-QF for xen-devel@lists.xensource.com; Wed, 07 Sep 2011 07:23:01 -0700 X-Env-Sender: davidtecher@yahoo.fr X-Msg-Ref: server-10.tower-21.messagelabs.com!1315405359!53218615!1 X-Originating-IP: [77.238.189.196] X-StarScan-Version: 6.3.6; banners=-,-,- X-VirusChecked: Checked Received: (qmail 18866 invoked from network); 7 Sep 2011 14:22:39 -0000 Received: from nm12-vm0.bullet.mail.ird.yahoo.com (HELO nm12-vm0.bullet.mail.ird.yahoo.com) (77.238.189.196) by server-10.tower-21.messagelabs.com with SMTP; 7 Sep 2011 14:22:39 -0000 Received: from [77.238.189.54] by nm12.bullet.mail.ird.yahoo.com with NNFMP; 07 Sep 2011 14:22:53 -0000 Received: from [212.82.108.114] by tm7.bullet.mail.ird.yahoo.com with NNFMP; 07 Sep 2011 14:22:52 -0000 Received: from [127.0.0.1] by omp1023.mail.ird.yahoo.com with NNFMP; 07 Sep 2011 14:22:52 -0000 X-Yahoo-Newman-Property: ymail-3 X-Yahoo-Newman-Id: 968473.93927.bm@omp1023.mail.ird.yahoo.com Received: (qmail 31489 invoked by uid 60001); 7 Sep 2011 14:22:52 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.fr; s=s1024; t=1315405372; bh=OtZTKYKhJUhISyxee0jkJ2rAAvw3UdOKJ10WaU6cm6E=; h=X-YMail-OSG:Received:X-Mailer:References:Message-ID:Date:From:Reply-To:Subject:To:In-Reply-To:MIME-Version:Content-Type; b=29iiFLOZ7RtZ+3NNojeN6BpHxAy+5EBnMuNShibT0lzAIRocsQwbzr2MIE5KlRyD47PF6irdLeHxr9WDGo+7WFxPBvQkNK2FtfO6uy0Lisx7Fd/Yk6mmvueLElUaYH4v2L4aepX5nWE+9CuTrSSwU185PM0R1I8mQhV280L2W3M= DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.fr; h=X-YMail-OSG:Received:X-Mailer:References:Message-ID:Date:From:Reply-To:Subject:To:In-Reply-To:MIME-Version:Content-Type; b=0p9gZkliszzhWCfApjUm8CvscMYmSbNZdfc7xvVkL3buGlJL5BtNct/aeWh8QcfOIt/GBPIVyQO4FnVO9Zc1imUWsHKpHYqSAo87wplb1s2YcvRAvJpY1EgS9O3WVqso9uRFrp0m8se+fBLK7Uu05+XAUR4AqD+3G/3DGQCsJhM=; X-YMail-OSG: HeK9ibMVM1lPAHkJpgw7QtUUCagznmzq86AibPdcGbbA.cv cEh7ZwSV.cL63txMu3Q5ABioG.zcQi_l.mejSVjmxa_s4J.NX.Ik1nZ_no3Y HxCkGFvDz5Ke6oat3XO9XALieo25yZ0UEi_v6hwso3ygIQPQLiIB.rRTs8te GNlNP6XKZmMbcBf1HBxUhWs0FpgAOxy1.mafOxaoyj1guxXe1QmzSLiIhPrQ kAl2apHTnhtrgMdJyjk5uUn6nEq7B6rvPylhuQtGj_2boW5D9b9vTKhVmBRu TRFDu0eSJ9hM1Pj9nt0HjfH0vRHiki_YPdgsoQbFRL0MBvc7aTD_nIgz4wPS zEQ4PDmd0TQYIRVD8UQD0rGcRVVpOTAth2tMjllIBQ43lVWHUt1YzflVj7EG hbNkLCMVVYA9XKxekixgstIIP68h3U31hcfbX5QO4i3T55XH5oYRYDGNwIfe .khGXcEfMVnAPX_VZ92ziVbGtU8CO.O4EGRu8NmRwBJ_L_y_8ZCYeBuRqZKh mhZROkDIKULyOD9_Uz.vX6GiX84VZXMPgfBD3947TOwD1Dltx.VtfFeWiNop pTy1LHGML.eqiBsHvOpm9pVlHx2mHrXFNH64xvncgiE8ZKswgSk8M.gf04vn vqEJpuApSBZarT5Sqj8TIhYnZxM1OKmueskMiqf6k61q.TCcSYN5eB4jdNQx FFl9P29UcGYgb9_P7Nsi03_eyRLIVvs6C8bSZzJWUeHfv9RNmtkyqLbwcmq1 n2vmuk04.vuYmPn4IC2yId4NtNCn6qI_N5bjwf80- Received: from [195.167.237.98] by web29801.mail.ird.yahoo.com via HTTP; Wed, 07 Sep 2011 15:22:52 BST X-Mailer: YahooMailWebService/0.8.113.315625 References: <1314780568949-4753422.post@n5.nabble.com> <1314795401771-4754024.post@n5.nabble.com> <20110831151913.GE7276@reaktio.net> <1315231341254-4770602.post@n5.nabble.com> <1315310225039-4774097.post@n5.nabble.com> <1315343879.61837.YahooMailNeo@web29818.mail.ird.yahoo.com> <1315382742268-4777689.post@n5.nabble.com> <1315389138.56652.YahooMailNeo@web29801.mail.ird.yahoo.com> <1315398360680-4778339.post@n5.nabble.com> <1315401901083-4778494.post@n5.nabble.com> <1315403644525-4778586.post@n5.nabble.com> Message-ID: <1315405372.87224.YahooMailNeo@web29801.mail.ird.yahoo.com> Date: Wed, 7 Sep 2011 15:22:52 +0100 (BST) From: David TECHER Subject: Re : Re : Re : [Xen-devel] Re: Patches for VGA-Passthrough XEN 4.2 unstable To: JavMV , "xen-devel@lists.xensource.com" In-Reply-To: <1315403644525-4778586.post@n5.nabble.com> MIME-Version: 1.0 Cc: X-BeenThere: xen-devel@lists.xensource.com X-Mailman-Version: 2.1.5 Precedence: list Reply-To: David TECHER List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1324609827==" Sender: xen-devel-bounces@lists.xensource.com Errors-To: xen-devel-bounces@lists.xensource.com --===============1324609827== Content-Type: multipart/alternative; boundary="0-2144499568-1315405372=:87224" --0-2144499568-1315405372=:87224 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable Javier,=0A=0A1. Please be informed that the patched are available at http:/= /www.davidgis.fr/download/gfx_patch.tar.bz2=0A=0Awget -q http://www.davidgi= s.fr/download/gfx_patch.tar.bz2=0Atar xvjf gfx_patch.tar.bz2=0Afor file in = $(ls gfx_patch/*.patch);do patch -p0 < ../$file;done=0A=0A=0A2. Concerning = your question, in xen-4.2.unstable one of the function was been placed in a= new file.=0A=A0=A0 That's the reason why you will find the patch'tools/fir= mware/hvmloader/pci.c'=0A=A0=A0 I've did it because the branch 4.2 unstable= placed the function in the file pci.c=0A=A0=A0 I can not tell you, you nee= d to have a look (I am at work while I am writting this mail )=0A=0A3. The = patchs shoud work for revision 23799 on xen 4.2 unstable=0A=0A=A0=A0=A0 hg = clone -r 23799 http://xenbits.xensource.com/hg/staging/xen-unstable.hg/=0A= =0A=0A4. GTX 460: be informed that it will be a great pleasure to=A0 know t= hat you succeed in hacking=A0 your GTX 460.=0A=A0=A0=A0 I've got a 'EVGA GT= X 460 SE' and it doesn't work. I think because EVGA overclocks=0A=A0=A0=A0 = the card. Perhaps I need to underclock the card using nibitor. I do not kno= w. I've tryed yet.=0A=A0=A0 =0A=0A=A0 When I've tried to start my domU with= GTX 460 the domU and dom0 crash.=0A=0A=0A=A0=A0 So let me know if you succ= eed :) =0A=0A=A0 =0A=0A=A0 As far as I'am concern, you need to have a GTX 4= 60 not super overclocked.=0A=0A=0AP.S:=A0I've made a complete tutorial - bu= t for French users only - available on my blog=A0=0A=0A=A0=A0=A0=A0=A0 http= ://www.davidgis.fr/blog/index.php?2011/08/28/818-xen-intel-vt-d-sur-core-5-= 2400-vga-passthrough-sur-carte-nvidia-msi-gt-440-partie-iv=0A=A0=A0=A0=A0= =A0=A0 =0A=0ADavid.=0A=0A=0A=0A=0A________________________________=0ADe=A0:= JavMV =0A=C0=A0: xen-devel@lists.xensource.com= =0AEnvoy=E9 le : Mercredi 7 Septembre 2011 15h54=0AObjet=A0: Re: Re : Re : = [Xen-devel] Re: Patches for VGA-Passthrough XEN 4.2 unstable=0A=0ACongratul= ations!=A0 these are nice news ^^, I have two questions, first one for=0ADa= vid:=0ADid u just adapt my patches or did you add some new things to them? = (By the=0Away thank you for adapt them again, and for explain the dsdt modi= fications I=0Ahave realised that I made a mistake, maybe now I can make it = work for my GTX=0A460).=0AThe second one is for Komkom, would you mind to p= ost a link for the=0Achangeset of xen 4.2 about the date of my patches? (th= e one you said you=0Ahave tried before) I just want to know if my original = pacthes are working=0Atoo.=0A=0AWell, I'll work on this at the end of the m= onth so I'll post here if this=0Awork also for my graphic card (GTX 460) an= d if this is fine I will adapt the=0Apatch for the secondary card to make y= ou happier XD or maybe David is going=0Ato do this faster than me because I= m bussy until end of this month.=0A=0ABest regards=0AJavier Manzano=0A=0A--= ---=0AJavMV=0A--=0AView this message in context: http://xen.1045712.n5.nabb= le.com/Patches-for-VGA-Passthrough-XEN-4-2-unstable-tp4406265p4778586.html= =0ASent from the Xen - Dev mailing list archive at Nabble.com.=0A=0A_______= ________________________________________=0AXen-devel mailing list=0AXen-dev= el@lists.xensource.com=0Ahttp://lists.xensource.com/xen-devel --0-2144499568-1315405372=:87224 Content-Type: text/html; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable
Javier,

1. Please be = informed that the patched are available at http://www.davidgis.fr/download/= gfx_patch.tar.bz2

wget -= q http://www.davidgis.fr/download/gfx_patch.tar.bz2
tar xvjf gfx_patch.t= ar.bz2
for file in $(ls gfx_patch/*.patch);do patch -p0 < ../$file;do= ne

2. Concerning you= r question, in xen-4.2.unstable one of the function was been placed in a ne= w file.
   That's the reason why you will = find the patch 'tools/firmware/hvmloader/pci.c'
&nbs= p;  I've did it because the branch 4.2 unstable placed the function in= the file pci.c
   I can not tell you, you need to have a look (I am at work while I am writting this mail )=

3. The patchs shoud wor= k for revision 23799 on xen 4.2 unstable

=
    hg clone -r 23799 http://xenbits.xensou= rce.com/hg/staging/xen-unstable.hg/

4. = GTX 460: be informed that it will be a great pleasure to  know that yo= u succeed in hacking  your GTX 460.
    I've = got a 'EVGA GTX 460 SE' and it doesn't work. I think because EVGA overclock= s
    the card. Perhaps I need to underclock the c= ard using nibitor. I do not know. I've tryed yet.
  
  When I've tried to start my domU with GTX 460 the domU = and dom0 crash.

   So let me know if= you succeed :)
 
  As far as I'am concern, you need to have a GTX 460 not super overclocked.

P.S:  I've made a complete tutorial - but = for French users only - available on my blog 
<= br>
      http://www.davidg= is.fr/blog/index.php?2011/08/28/818-xen-intel-vt-d-sur-core-5-2400-vga-pass= through-sur-carte-nvidia-msi-gt-440-partie-iv
  =     
David.
<= /div>

<= hr size=3D"1">De : Jav= MV <javier.manzano@edu.uah.es>
=C0 : xen-devel@lists.xensource.com
Envoy=E9 le : Mercredi 7 Septembre= 2011 15h54
Objet : Re: Re : Re : [Xen-devel] Re: Patches for VGA-Passthrough XEN 4.2 unstabl= e

Congratulations!  these are nice news ^^, I have two q= uestions, first one for
David:
Did u just adapt my patches or did you= add some new things to them? (By the
way thank you for adapt them again= , and for explain the dsdt modifications I
have realised that I made a m= istake, maybe now I can make it work for my GTX
460).
The second one = is for Komkom, would you mind to post a link for the
changeset of xen 4.= 2 about the date of my patches? (the one you said you
have tried before)= I just want to know if my original pacthes are working
too.

Well= , I'll work on this at the end of the month so I'll post here if this
wo= rk also for my graphic card (GTX 460) and if this is fine I will adapt the
patch for the secondary card to make you happier XD or maybe David = is going
to do this faster than me because Im bussy until end of this mo= nth.

Best regards
Javier Manzano

-----
JavMV
--
V= iew this message in context: http://xen.1045712.n5.nabble.com/Patches-for-VGA-Passthrough-XE= N-4-2-unstable-tp4406265p4778586.html
Sent from the Xen - Dev mailin= g list archive at Nabble.com.

______________________________________= _________
Xen-devel mailing list
Xen-devel@lis= ts.xensource.com
http://lists.xensource.com/xen-devel


<= /div>
--0-2144499568-1315405372=:87224-- --===============1324609827== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel --===============1324609827==-- From xen-devel-bounces@lists.xensource.com Wed Sep 07 07:32:30 2011 Return-path: Envelope-to: www-data@lists.xensource.com Delivery-date: Wed, 07 Sep 2011 07:32:30 -0700 Received: from localhost ([127.0.0.1] helo=lists.colo.xensource.com) by lists.xensource.com with esmtp (Exim 4.43) id 1R1JB0-000834-B5; Wed, 07 Sep 2011 07:32:30 -0700 Received: from mail216.messagelabs.com ([85.158.143.99]) by lists.xensource.com with esmtp (Exim 4.43) id 1R1JAQ-0007pQ-MJ for xen-devel@lists.xensource.com; Wed, 07 Sep 2011 07:31:55 -0700 X-Env-Sender: Stefano.Stabellini@eu.citrix.com X-Msg-Ref: server-12.tower-216.messagelabs.com!1315405910!11673725!1 X-Originating-IP: [66.165.176.89] X-StarScan-Version: 6.3.6; banners=-,-,- X-VirusChecked: Checked Received: (qmail 11517 invoked from network); 7 Sep 2011 14:31:51 -0000 Received: from smtp.citrix.com (HELO SMTP.CITRIX.COM) (66.165.176.89) by server-12.tower-216.messagelabs.com with RC4-SHA encrypted SMTP; 7 Sep 2011 14:31:51 -0000 X-IronPort-AV: E=Sophos;i="4.68,345,1312171200"; d="scan'208";a="16763108" Received: from ftlpmailmx02.citrite.net ([10.13.107.66]) by FTLPIPO01.CITRIX.COM with ESMTP/TLS/RC4-MD5; 07 Sep 2011 10:31:49 -0400 Received: from smtp01.ad.xensource.com (10.219.128.104) by smtprelay.citrix.com (10.13.107.66) with Microsoft SMTP Server id 8.3.137.0; Wed, 7 Sep 2011 10:31:49 -0400 Received: from localhost.localdomain (kaball.uk.xensource.com [10.80.2.59]) by smtp01.ad.xensource.com (8.13.1/8.13.1) with ESMTP id p87EVavP025584; Wed, 7 Sep 2011 07:31:38 -0700 From: To: xen-devel@lists.xensource.com Date: Wed, 7 Sep 2011 15:39:58 +0100 Message-ID: <1315406398-8987-2-git-send-email-stefano.stabellini@eu.citrix.com> X-Mailer: git-send-email 1.7.0.4 In-Reply-To: <1315406398-8987-1-git-send-email-stefano.stabellini@eu.citrix.com> References: <1315406398-8987-1-git-send-email-stefano.stabellini@eu.citrix.com> MIME-Version: 1.0 Content-Type: text/plain Cc: Stefano Stabellini , keir@xen.org, Stefano.Stabellini@eu.citrix.com Subject: [Xen-devel] [PATCH 2/2] Automatically select seabios when we are building upstream qemu X-BeenThere: xen-devel@lists.xensource.com X-Mailman-Version: 2.1.5 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xensource.com Errors-To: xen-devel-bounces@lists.xensource.com Signed-off-by: Stefano Stabellini diff -r f1269b3216ef Config.mk --- a/Config.mk Wed Sep 07 13:28:05 2011 +0000 +++ b/Config.mk Wed Sep 07 13:29:15 2011 +0000 @@ -195,6 +195,7 @@ endif # Only available through the git protocol at the moment QEMU_UPSTREAM_URL=git://xenbits.xen.org/people/sstabellini/qemu-dm.git QEMU_UPSTREAM_TAG=origin/xen-stable-0.15 +SEABIOS_UPSTREAM_URL=git://git.qemu.org/seabios.git # Specify which qemu-dm to use. This may be `ioemu' to use the old # Mercurial in-tree version, or a local directory, or a git URL. @@ -202,9 +203,12 @@ QEMU_UPSTREAM_TAG=origin/xen-stable-0.15 ifeq ($(QEMU),upstream) CONFIG_QEMU ?= $(QEMU_UPSTREAM_URL) QEMU_TAG ?= $(QEMU_UPSTREAM_TAG) +CONFIG_SEABIOS ?= $(SEABIOS_UPSTREAM_URL) +SEABIOS_TAG ?= 7fc039e9c262b4199fab497f3e12f4e425c37560 else CONFIG_QEMU ?= $(QEMU_REMOTE) QEMU_TAG ?= cd776ee9408ff127f934a707c1a339ee600bc127 +CONFIG_SEABIOS ?= endif # Tue Jun 28 13:50:53 2011 +0100 @@ -213,15 +217,6 @@ endif # Short answer -- do not enable this unless you know what you are # doing and are prepared for some pain. -# SeaBIOS integration is a work in progress. Before enabling this -# option you must clone git://git.qemu.org/seabios.git/, possibly add -# some development patches and then build it yourself before pointing -# this variable to it (using an absolute path). -# -# Note that using SeaBIOS requires the use the upstream qemu as the -# device model. -SEABIOS_DIR ?= - # Optional components XENSTAT_XENTOP ?= y VTPM_TOOLS ?= n diff -r f1269b3216ef tools/firmware/Makefile --- a/tools/firmware/Makefile Wed Sep 07 13:28:05 2011 +0000 +++ b/tools/firmware/Makefile Wed Sep 07 13:29:15 2011 +0000 @@ -6,13 +6,35 @@ TARGET := hvmloader/hvmloader INST_DIR := $(DESTDIR)$(XENFIRMWAREDIR) SUBDIRS := +ifneq ($(CONFIG_SEABIOS),) +SEABIOS_DIR := seabios-dir +SUBDIRS += $(SEABIOS_DIR) +endif SUBDIRS += rombios SUBDIRS += vgabios SUBDIRS += etherboot SUBDIRS += hvmloader +$(SEABIOS_DIR): + set -ex; \ + if [ ! -d seabios-remote ]; then \ + rm -rf seabios-remote seabios-remote.tmp; \ + mkdir seabios-remote.tmp; rmdir seabios-remote.tmp; \ + $(GIT) clone $(CONFIG_SEABIOS) seabios-remote.tmp; \ + if [ "$(SEABIOS_TAG)" ]; then \ + cd seabios-remote.tmp; \ + $(GIT) branch -D dummy >/dev/null 2>&1 ||:; \ + $(GIT) checkout -b dummy $(SEABIOS_TAG); \ + cd ..; \ + fi; \ + mv seabios-remote.tmp seabios-remote; \ + fi; \ + rm -f seabios-dir; \ + ln -sf seabios-remote seabios-dir; \ + mv seabios-config seabios-dir/.config; + .PHONY: all -all: +all: $(SEABIOS_DIR) @set -e; if [ $$((`( bcc -v 2>&1 | grep version || echo 0.0.0 ) | cut -d' ' -f 3 | awk -F. '{ printf "0x%02x%02x%02x", $$1, $$2, $$3}'`)) -lt $$((0x00100e)) ] ; then \ echo "==========================================================================="; \ echo "Require dev86 rpm or bin86 & bcc debs version >= 0.16.14 to build firmware!"; \ @@ -35,4 +57,7 @@ clean: subdirs-clean distclean: subdirs-distclean subdir-distclean-etherboot: .phony - $(MAKE) -C etherboot distclean \ No newline at end of file + $(MAKE) -C etherboot distclean + +subdir-distclean-$(SEABIOS_DIR): .phony + rm -rf seabios-dir seabios-remote diff -r f1269b3216ef tools/firmware/hvmloader/Makefile --- a/tools/firmware/hvmloader/Makefile Wed Sep 07 13:28:05 2011 +0000 +++ b/tools/firmware/hvmloader/Makefile Wed Sep 07 13:29:15 2011 +0000 @@ -37,19 +37,17 @@ endif CIRRUSVGA_DEBUG ?= n +ifneq ($(SEABIOS_DIR),) +OBJS += seabios.o +CFLAGS += -DENABLE_SEABIOS +SEABIOS_ROM := ../$(SEABIOS_DIR)/out/bios.bin +else ROMBIOS_DIR := ../rombios -ifneq ($(ROMBIOS_DIR),) OBJS += rombios.o CFLAGS += -DENABLE_ROMBIOS ROMBIOS_ROM := $(ROMBIOS_DIR)/BIOS-bochs-latest endif -ifneq ($(SEABIOS_DIR),) -OBJS += seabios.o -CFLAGS += -DENABLE_SEABIOS -SEABIOS_ROM := $(SEABIOS_DIR)/out/bios.bin -endif - STDVGA_ROM := ../vgabios/VGABIOS-lgpl-latest.bin ifeq ($(CIRRUSVGA_DEBUG),y) CIRRUSVGA_ROM := ../vgabios/VGABIOS-lgpl-latest.cirrus.debug.bin diff -r f1269b3216ef tools/firmware/seabios-config --- /dev/null Thu Jan 01 00:00:00 1970 +0000 +++ b/tools/firmware/seabios-config Wed Sep 07 13:29:15 2011 +0000 @@ -0,0 +1,73 @@ +# +# Automatically generated make config: don't edit +# SeaBIOS Configuration +# Wed Sep 7 13:03:21 2011 +# + +# +# General Features +# +# CONFIG_COREBOOT is not set +CONFIG_XEN=y +CONFIG_THREADS=y +# CONFIG_THREAD_OPTIONROMS is not set +CONFIG_RELOCATE_INIT=y +CONFIG_BOOTMENU=y +# CONFIG_BOOTSPLASH is not set +CONFIG_BOOTORDER=y + +# +# Hardware support +# +CONFIG_ATA=y +CONFIG_ATA_DMA=y +CONFIG_ATA_PIO32=y +CONFIG_AHCI=y +CONFIG_VIRTIO_BLK=y +CONFIG_FLOPPY=y +CONFIG_PS2PORT=y +CONFIG_USB=y +CONFIG_USB_UHCI=y +CONFIG_USB_OHCI=y +CONFIG_USB_EHCI=y +CONFIG_USB_MSC=y +CONFIG_USB_HUB=y +CONFIG_USB_KEYBOARD=y +CONFIG_USB_MOUSE=y +CONFIG_SERIAL=y +CONFIG_LPT=y +# CONFIG_USE_SMM is not set +CONFIG_MTRR_INIT=y + +# +# BIOS interfaces +# +CONFIG_DRIVES=y +CONFIG_CDROM_BOOT=y +CONFIG_CDROM_EMU=y +CONFIG_PCIBIOS=y +CONFIG_APMBIOS=y +CONFIG_PNPBIOS=y +CONFIG_OPTIONROMS=y +# CONFIG_OPTIONROMS_DEPLOYED is not set +CONFIG_PMM=y +CONFIG_BOOT=y +CONFIG_KEYBOARD=y +CONFIG_KBD_CALL_INT15_4F=y +CONFIG_MOUSE=y +CONFIG_S3_RESUME=y +# CONFIG_DISABLE_A20 is not set + +# +# BIOS Tables +# +CONFIG_PIRTABLE=y +CONFIG_MPTABLE=y +CONFIG_SMBIOS=y +CONFIG_ACPI=y + +# +# Debugging +# +CONFIG_DEBUG_LEVEL=1 +# CONFIG_DEBUG_SERIAL is not set _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel From xen-devel-bounces@lists.xensource.com Wed Sep 07 07:33:26 2011 Return-path: Envelope-to: www-data@lists.xensource.com Delivery-date: Wed, 07 Sep 2011 07:33:26 -0700 Received: from localhost ([127.0.0.1] helo=lists.colo.xensource.com) by lists.xensource.com with esmtp (Exim 4.43) id 1R1JBu-0008QE-DP; Wed, 07 Sep 2011 07:33:26 -0700 Received: from mail216.messagelabs.com ([85.158.143.99]) by lists.xensource.com with esmtp (Exim 4.43) id 1R1JAc-0007tf-LO for xen-devel@lists.xensource.com; Wed, 07 Sep 2011 07:32:07 -0700 X-Env-Sender: komkon555@freenet.de X-Msg-Ref: server-7.tower-216.messagelabs.com!1315405922!17411319!1 X-Originating-IP: [216.139.236.26] X-StarScan-Version: 6.3.6; banners=-,-,- X-VirusChecked: Checked Received: (qmail 10743 invoked from network); 7 Sep 2011 14:32:03 -0000 Received: from sam.nabble.com (HELO sam.nabble.com) (216.139.236.26) by server-7.tower-216.messagelabs.com with AES256-SHA encrypted SMTP; 7 Sep 2011 14:32:03 -0000 Received: from [192.168.236.26] (helo=sam.nabble.com) by sam.nabble.com with esmtp (Exim 4.72) (envelope-from ) id 1R1JAX-0007EC-UZ for xen-devel@lists.xensource.com; Wed, 07 Sep 2011 07:32:01 -0700 Date: Wed, 7 Sep 2011 07:32:01 -0700 (PDT) From: komkon555 To: xen-devel@lists.xensource.com Message-ID: <1315405921936-4778727.post@n5.nabble.com> In-Reply-To: <1315405372.87224.YahooMailNeo@web29801.mail.ird.yahoo.com> References: <20110831151913.GE7276@reaktio.net> <1315231341254-4770602.post@n5.nabble.com> <1315310225039-4774097.post@n5.nabble.com> <1315343879.61837.YahooMailNeo@web29818.mail.ird.yahoo.com> <1315382742268-4777689.post@n5.nabble.com> <1315389138.56652.YahooMailNeo@web29801.mail.ird.yahoo.com> <1315398360680-4778339.post@n5.nabble.com> <1315401901083-4778494.post@n5.nabble.com> <1315403644525-4778586.post@n5.nabble.com> <1315405372.87224.YahooMailNeo@web29801.mail.ird.yahoo.com> Subject: Re: Re : Re : Re : [Xen-devel] Re: Patches for VGA-Passthrough XEN 4.2 unstable MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-BeenThere: xen-devel@lists.xensource.com X-Mailman-Version: 2.1.5 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xensource.com Errors-To: xen-devel-bounces@lists.xensource.com Hallo. I had no success (BSOD while boot in) with patches from JavMV with this config: xen 4.2-unstable changeset 23350 (clearly patched) + jeremi xen kernel 2.6.32.43/45 (xenfs static) on debian squeeze. Best Regards Komkon555 -- View this message in context: http://xen.1045712.n5.nabble.com/Patches-for-VGA-Passthrough-XEN-4-2-unstable-tp4406265p4778727.html Sent from the Xen - Dev mailing list archive at Nabble.com. _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel From xen-devel-bounces@lists.xensource.com Wed Sep 07 07:34:26 2011 Return-path: Envelope-to: www-data@lists.xensource.com Delivery-date: Wed, 07 Sep 2011 07:34:26 -0700 Received: from localhost ([127.0.0.1] helo=lists.colo.xensource.com) by lists.xensource.com with esmtp (Exim 4.43) id 1R1JCr-0000MM-Vs; Wed, 07 Sep 2011 07:34:25 -0700 Received: from mail27.messagelabs.com ([193.109.254.147]) by lists.xensource.com with esmtp (Exim 4.43) id 1R1JB5-00083e-BO for xen-devel@lists.xensource.com; Wed, 07 Sep 2011 07:32:35 -0700 X-Env-Sender: Stefano.Stabellini@eu.citrix.com X-Msg-Ref: server-14.tower-27.messagelabs.com!1315405938!35152350!1 X-Originating-IP: [66.165.176.63] X-StarScan-Version: 6.3.6; banners=-,-,- X-VirusChecked: Checked Received: (qmail 22884 invoked from network); 7 Sep 2011 14:32:19 -0000 Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63) by server-14.tower-27.messagelabs.com with RC4-SHA encrypted SMTP; 7 Sep 2011 14:32:19 -0000 X-IronPort-AV: E=Sophos;i="4.68,345,1312171200"; d="scan'208";a="162004881" Received: from ftlpmailmx02.citrite.net ([10.13.107.66]) by FTLPIPO02.CITRIX.COM with ESMTP/TLS/RC4-MD5; 07 Sep 2011 10:31:43 -0400 Received: from smtp01.ad.xensource.com (10.219.128.104) by smtprelay.citrix.com (10.13.107.66) with Microsoft SMTP Server id 8.3.137.0; Wed, 7 Sep 2011 10:31:43 -0400 Received: from localhost.localdomain (kaball.uk.xensource.com [10.80.2.59]) by smtp01.ad.xensource.com (8.13.1/8.13.1) with ESMTP id p87EVavO025584; Wed, 7 Sep 2011 07:31:37 -0700 From: To: xen-devel@lists.xensource.com Date: Wed, 7 Sep 2011 15:39:57 +0100 Message-ID: <1315406398-8987-1-git-send-email-stefano.stabellini@eu.citrix.com> X-Mailer: git-send-email 1.7.0.4 MIME-Version: 1.0 Content-Type: text/plain Cc: Stefano Stabellini , keir@xen.org, Stefano.Stabellini@eu.citrix.com Subject: [Xen-devel] [PATCH 1/2] Introduce support for upstream qemu in the xen-unstable build system X-BeenThere: xen-devel@lists.xensource.com X-Mailman-Version: 2.1.5 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xensource.com Errors-To: xen-devel-bounces@lists.xensource.com In order to distinguish between upstream qemu and qemu-xen I am introducing a new variable named "QEMU" that only if is equal to "upstream" switches the build system to the new qemu. Users that want to try the new qemu just have to export QEMU=upstream before calling make in the xen-unstable top level directory. Signed-off-by: Stefano Stabellini diff -r 0ba816e077e6 Config.mk --- a/Config.mk Wed Aug 31 16:04:37 2011 +0000 +++ b/Config.mk Wed Sep 07 11:13:17 2011 +0000 @@ -192,12 +192,21 @@ else QEMU_REMOTE=git://xenbits.xensource.com/qemu-xen-unstable.git endif +# Only available through the git protocol at the moment +QEMU_UPSTREAM_URL=git://xenbits.xen.org/people/sstabellini/qemu-dm.git +QEMU_UPSTREAM_TAG=origin/xen-stable-0.15 + # Specify which qemu-dm to use. This may be `ioemu' to use the old # Mercurial in-tree version, or a local directory, or a git URL. # CONFIG_QEMU ?= `pwd`/$(XEN_ROOT)/../qemu-xen.git +ifeq ($(QEMU),upstream) +CONFIG_QEMU ?= $(QEMU_UPSTREAM_URL) +QEMU_TAG ?= $(QEMU_UPSTREAM_TAG) +else CONFIG_QEMU ?= $(QEMU_REMOTE) +QEMU_TAG ?= cd776ee9408ff127f934a707c1a339ee600bc127 +endif -QEMU_TAG ?= cd776ee9408ff127f934a707c1a339ee600bc127 # Tue Jun 28 13:50:53 2011 +0100 # qemu-char.c: fix incorrect CONFIG_STUBDOM handling diff -r 0ba816e077e6 tools/Makefile --- a/tools/Makefile Wed Aug 31 16:04:37 2011 +0000 +++ b/tools/Makefile Wed Sep 07 11:13:17 2011 +0000 @@ -106,7 +106,19 @@ ioemu-dir-find: set -e; \ $(buildmakevars2shellvars); \ cd ioemu-dir; \ - $(QEMU_ROOT)/xen-setup $(IOEMU_CONFIGURE_CROSS) + if [ "$(QEMU)" = upstream ]; then \ + cd $(QEMU_ROOT); \ + ./configure --enable-xen --target-list=i386-softmmu \ + --extra-cflags="-I$(XEN_ROOT)/tools/include \ + -I$(XEN_ROOT)/tools/libxc \ + -I$(XEN_ROOT)/tools/xenstore" \ + --extra-ldflags="-L$(XEN_ROOT)/tools/libxc \ + -L$(XEN_ROOT)/tools/libxenstore" \ + --disable-kvm \ + $(IOEMU_CONFIGURE_CROSS); \ + else \ + $(QEMU_ROOT)/xen-setup $(IOEMU_CONFIGURE_CROSS); \ + fi .PHONY: ioemu-dir-force-update ioemu-dir-force-update: _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel From xen-devel-bounces@lists.xensource.com Wed Sep 07 07:41:24 2011 Return-path: Envelope-to: www-data@lists.xensource.com Delivery-date: Wed, 07 Sep 2011 07:41:24 -0700 Received: from localhost ([127.0.0.1] helo=lists.colo.xensource.com) by lists.xensource.com with esmtp (Exim 4.43) id 1R1JJc-0000ux-40; Wed, 07 Sep 2011 07:41:24 -0700 Received: from mail174.messagelabs.com ([85.158.138.51]) by lists.xensource.com with esmtp (Exim 4.43) id 1R1JJ8-0000iC-KP for xen-devel@lists.xensource.com; Wed, 07 Sep 2011 07:40:54 -0700 X-Env-Sender: tim@xen.org X-Msg-Ref: server-3.tower-174.messagelabs.com!1315406443!24513602!1 X-Originating-IP: [81.29.64.94] X-StarScan-Version: 6.3.6; banners=-,-,- X-VirusChecked: Checked Received: (qmail 18031 invoked from network); 7 Sep 2011 14:40:51 -0000 Received: from ocelot.phlegethon.org (HELO mail.phlegethon.org) (81.29.64.94) by server-3.tower-174.messagelabs.com with DHE-RSA-AES256-SHA encrypted SMTP; 7 Sep 2011 14:40:51 -0000 Received: from tjd by mail.phlegethon.org with local (Exim 4.67 (FreeBSD)) (envelope-from ) id 1R1JIw-000Bz5-G7; Wed, 07 Sep 2011 14:40:42 +0000 Date: Wed, 7 Sep 2011 15:40:42 +0100 From: Tim Deegan To: Olaf Hering Subject: Re: [Xen-devel] [PATCH 1 of 2] mem_event: pass mem_event_domain pointer to mem_event functions Message-ID: <20110907144042.GE41585@ocelot.phlegethon.org> References: <4e7bcc14b76a8e37bc8e.1315397729@probook.site> Mime-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline In-Reply-To: <4e7bcc14b76a8e37bc8e.1315397729@probook.site> User-Agent: Mutt/1.4.2.1i Cc: xen-devel@lists.xensource.com X-BeenThere: xen-devel@lists.xensource.com X-Mailman-Version: 2.1.5 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xensource.com Errors-To: xen-devel-bounces@lists.xensource.com Hi, At 14:15 +0200 on 07 Sep (1315404929), Olaf Hering wrote: > mem_event: pass mem_event_domain pointer to mem_event functions > > Pass a struct mem_event_domain pointer to the various mem_event > functions. This will be used in a subsequent patch which creates > different ring buffers for the memshare, xenpaging and memaccess > functionality. This looks basically sound, except that in mem_event_check_ring(): > -int mem_event_check_ring(struct domain *d) > +int mem_event_check_ring(struct mem_event_domain *med, domid_t dom_id) > { > struct vcpu *curr = current; > int free_requests; > int ring_full = 1; > > - if ( !d->mem_event.ring_page ) > + if ( !med->ring_page ) > return -1; > > - mem_event_ring_lock(d); > + mem_event_ring_lock(med); > > - free_requests = RING_FREE_REQUESTS(&d->mem_event.front_ring); > - if ( d->mem_event.req_producers < free_requests ) > + free_requests = RING_FREE_REQUESTS(&med->front_ring); > + if ( med->req_producers < free_requests ) > { > - d->mem_event.req_producers++; > + med->req_producers++; > ring_full = 0; > } > > - if ( (curr->domain->domain_id == d->domain_id) && ring_full ) > + if ( (curr->domain->domain_id == dom_id) && ring_full ) > mem_event_mark_and_pause(curr); I think you should just have it take a domain and a med like the otehr functions, and have this check be ( curr->domain == d ). I'm pretty sure that checking for equal domain IDs here is just a slight oddity of the original code and not something subtle. :) Cheers, Tim. _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel From xen-devel-bounces@lists.xensource.com Wed Sep 07 07:56:05 2011 Return-path: Envelope-to: www-data@lists.xensource.com Delivery-date: Wed, 07 Sep 2011 07:56:05 -0700 Received: from localhost ([127.0.0.1] helo=lists.colo.xensource.com) by lists.xensource.com with esmtp (Exim 4.43) id 1R1JXp-0001c6-8W; Wed, 07 Sep 2011 07:56:05 -0700 Received: from mail174.messagelabs.com ([85.158.138.51]) by lists.xensource.com with esmtp (Exim 4.43) id 1R1JXA-0001PE-8c for xen-devel@lists.xensource.com; Wed, 07 Sep 2011 07:55:24 -0700 X-Env-Sender: tim@xen.org X-Msg-Ref: server-11.tower-174.messagelabs.com!1315407319!30579096!1 X-Originating-IP: [81.29.64.94] X-StarScan-Version: 6.3.6; banners=-,-,- X-VirusChecked: Checked Received: (qmail 25066 invoked from network); 7 Sep 2011 14:55:21 -0000 Received: from ocelot.phlegethon.org (HELO mail.phlegethon.org) (81.29.64.94) by server-11.tower-174.messagelabs.com with DHE-RSA-AES256-SHA encrypted SMTP; 7 Sep 2011 14:55:21 -0000 Received: from tjd by mail.phlegethon.org with local (Exim 4.67 (FreeBSD)) (envelope-from ) id 1R1JX5-000C20-5l; Wed, 07 Sep 2011 14:55:19 +0000 Date: Wed, 7 Sep 2011 15:55:19 +0100 From: Tim Deegan To: Olaf Hering Subject: Re: [Xen-devel] [PATCH 2 of 2] mem_event: use different ringbuffers for share, paging and access Message-ID: <20110907145519.GF41585@ocelot.phlegethon.org> References: <9b0929f3243ced27c7c3.1315397730@probook.site> Mime-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline In-Reply-To: <9b0929f3243ced27c7c3.1315397730@probook.site> User-Agent: Mutt/1.4.2.1i Cc: xen-devel@lists.xensource.com X-BeenThere: xen-devel@lists.xensource.com X-Mailman-Version: 2.1.5 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xensource.com Errors-To: xen-devel-bounces@lists.xensource.com Hi, At 14:15 +0200 on 07 Sep (1315404930), Olaf Hering wrote: > mem_event: use different ringbuffers for share, paging and access > > Up to now a single ring buffer was used for mem_share, xenpaging and > xen-access. Each helper would have to cooperate and pull only its own > requests from the ring. Unfortunately this was not implemented. And > even if it was, it would make the whole concept fragile because a crash > or early exit of one helper would stall the others. > > What happend up to now is that active xenpaging + memory_sharing would > push memsharing requests in the buffer. xenpaging is not prepared for > such requests. > > This patch creates an independet ring buffer for mem_share, xenpaging > and xen-access and adds also new functions to enable xenpaging and > xen-access. The xc_mem_event_enable/xc_mem_event_disable functions will > be removed. The various XEN_DOMCTL_MEM_EVENT_* macros were cleaned up. > Due to the removal the API changed, so the SONAME will be changed too. The Xen-side changes look OK to me. I'll leave it to the tools maintainers to comment on changing the libxc interface and version. Cheers, Tim. _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel From xen-devel-bounces@lists.xensource.com Wed Sep 07 07:57:29 2011 Return-path: Envelope-to: www-data@lists.xensource.com Delivery-date: Wed, 07 Sep 2011 07:57:29 -0700 Received: from localhost ([127.0.0.1] helo=lists.colo.xensource.com) by lists.xensource.com with esmtp (Exim 4.43) id 1R1JZB-00021P-2P; Wed, 07 Sep 2011 07:57:29 -0700 Received: from mail174.messagelabs.com ([85.158.138.51]) by lists.xensource.com with smtp (Exim 4.43) id 1R1JXU-0001TZ-Mw for xen-devel@lists.xensource.com; Wed, 07 Sep 2011 07:55:45 -0700 X-Env-Sender: Ian.Jackson@eu.citrix.com X-Msg-Ref: server-5.tower-174.messagelabs.com!1315407336!26882167!1 X-Originating-IP: [62.200.22.115] X-StarScan-Version: 6.3.6; banners=-,-,- X-VirusChecked: Checked Received: (qmail 24338 invoked from network); 7 Sep 2011 14:55:40 -0000 Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115) by server-5.tower-174.messagelabs.com with SMTP; 7 Sep 2011 14:55:40 -0000 X-IronPort-AV: E=Sophos;i="4.68,345,1312156800"; d="scan'208";a="7655825" Received: from lonpmailmx01.citrite.net ([10.30.203.162]) by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5; 07 Sep 2011 14:55:14 +0000 Received: from woking.xci-test.com (10.80.248.135) by smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id 8.3.137.0; Wed, 7 Sep 2011 15:55:14 +0100 Received: from osstest by woking.xci-test.com with local (Exim 4.69) (envelope-from ) id 1R1JWz-0003QX-PF; Wed, 07 Sep 2011 15:55:13 +0100 To: xen-devel@lists.xensource.com Message-ID: From: xen.org Date: Wed, 7 Sep 2011 15:55:13 +0100 MIME-Version: 1.0 Content-Type: text/plain Cc: ian.jackson@eu.citrix.com Subject: [Xen-devel] [xen-4.0-testing test] 8844: regressions - FAIL X-BeenThere: xen-devel@lists.xensource.com X-Mailman-Version: 2.1.5 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xensource.com Errors-To: xen-devel-bounces@lists.xensource.com flight 8844 xen-4.0-testing real [real] http://www.chiark.greenend.org.uk/~xensrcts/logs/8844/ Regressions :-( Tests which did not succeed and are blocking: build-i386-pvops 4 kernel-build fail REGR. vs. 8801 build-amd64-pvops 4 kernel-build fail REGR. vs. 8801 Tests which did not succeed, but are not blocking, including regressions (tests previously passed) regarded as allowable: test-amd64-amd64-xl-pcipt-intel 1 xen-build-check(1) blocked n/a test-i386-i386-xl 1 xen-build-check(1) blocked n/a test-amd64-i386-xl-multivcpu 1 xen-build-check(1) blocked n/a test-amd64-i386-pv 1 xen-build-check(1) blocked n/a test-i386-i386-pv 1 xen-build-check(1) blocked n/a test-amd64-amd64-pv 1 xen-build-check(1) blocked n/a test-amd64-amd64-xl 1 xen-build-check(1) blocked n/a test-amd64-i386-xl 1 xen-build-check(1) blocked n/a test-amd64-i386-xl-credit2 1 xen-build-check(1) blocked n/a test-amd64-amd64-xl-sedf 1 xen-build-check(1) blocked n/a test-amd64-amd64-pair 1 xen-build-check(1) blocked n/a test-i386-i386-pair 1 xen-build-check(1) blocked n/a test-amd64-i386-pair 1 xen-build-check(1) blocked n/a test-amd64-i386-rhel6hvm-intel 1 xen-build-check(1) blocked n/a test-amd64-i386-rhel6hvm-amd 1 xen-build-check(1) blocked n/a test-amd64-i386-win-vcpus1 1 xen-build-check(1) blocked n/a test-amd64-i386-win 1 xen-build-check(1) blocked n/a test-amd64-amd64-win 1 xen-build-check(1) blocked n/a test-i386-i386-win 1 xen-build-check(1) blocked n/a test-amd64-amd64-xl-win 1 xen-build-check(1) blocked n/a test-i386-i386-xl-win 1 xen-build-check(1) blocked n/a test-amd64-i386-xl-win-vcpus1 1 xen-build-check(1) blocked n/a version targeted for testing: xen b44346a6975c baseline version: xen 0383662ea34c ------------------------------------------------------------ People who touched revisions under test: Andrew Cooper ------------------------------------------------------------ jobs: build-amd64 pass build-i386 pass build-amd64-oldkern pass build-i386-oldkern pass build-amd64-pvops fail build-i386-pvops fail test-amd64-amd64-xl blocked test-amd64-i386-xl blocked test-i386-i386-xl blocked test-amd64-i386-rhel6hvm-amd blocked test-amd64-i386-xl-credit2 blocked test-amd64-amd64-xl-pcipt-intel blocked test-amd64-i386-rhel6hvm-intel blocked test-amd64-i386-xl-multivcpu blocked test-amd64-amd64-pair blocked test-amd64-i386-pair blocked test-i386-i386-pair blocked test-amd64-amd64-pv blocked test-amd64-i386-pv blocked test-i386-i386-pv blocked test-amd64-amd64-xl-sedf blocked test-amd64-i386-win-vcpus1 blocked test-amd64-i386-xl-win-vcpus1 blocked test-amd64-amd64-win blocked test-amd64-i386-win blocked test-i386-i386-win blocked test-amd64-amd64-xl-win blocked test-i386-i386-xl-win blocked ------------------------------------------------------------ sg-report-flight on woking.cam.xci-test.com logs: /home/xc_osstest/logs images: /home/xc_osstest/images Logs, config files, etc. are available at http://www.chiark.greenend.org.uk/~xensrcts/logs Test harness code can be found at http://xenbits.xensource.com/gitweb?p=osstest.git;a=summary Not pushing. ------------------------------------------------------------ changeset: 21533:b44346a6975c tag: tip user: Keir Fraser date: Wed Sep 07 10:41:49 2011 +0100 Added signature for changeset 8d012bc20d30 changeset: 21532:b7b51fd533d3 user: Keir Fraser date: Wed Sep 07 10:41:41 2011 +0100 Added tag 4.0.3-rc2 for changeset 8d012bc20d30 changeset: 21531:8d012bc20d30 tag: 4.0.3-rc2 user: Keir Fraser date: Wed Sep 07 10:41:35 2011 +0100 Update Xen version to 4.0.3-rc2 changeset: 21530:0383662ea34c user: Andrew Cooper date: Wed Aug 31 15:37:57 2011 +0100 IRQ: manually EOI migrating line interrupts When migrating IO-APIC line level interrupts between PCPUs, the migration code rewrites the IO-APIC entry to point to the new CPU/Vector before EOI'ing it. The EOI process says that EOI'ing the Local APIC will cause a broadcast with the vector number, which the IO-APIC must listen to to clear the IRR and Status bits. In the case of migrating, the IO-APIC has already been reprogrammed so the EOI broadcast with the old vector fails to match the new vector, leaving the IO-APIC with an outstanding vector, preventing any more use of that line interrupt. This causes a lockup especially when your root device is using PCI INTA (megaraid_sas driver *ehem*) However, the problem is mostly hidden because send_cleanup_vector() causes a cleanup of all moving vectors on the current PCPU in such a way which does not cause the problem, and if the problem has occured, the writes it makes to the IO-APIC clears the IRR and Status bits which unlocks the problem. This fix is distinctly a temporary hack, waiting on a cleanup of the irq code. It checks for the edge case where we have moved the irq, and manually EOI's the old vector with the IO-APIC which correctly clears the IRR and Status bits. Also, it protects the code which updates irq_cfg by disabling interrupts. Signed-off-by: Andrew Cooper xen-unstable changeset: 23805:7048810180de xen-unstable date: Wed Aug 31 15:19:24 2011 +0100 (qemu changes not included) _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel From xen-devel-bounces@lists.xensource.com Wed Sep 07 08:01:33 2011 Return-path: Envelope-to: www-data@lists.xensource.com Delivery-date: Wed, 07 Sep 2011 08:01:33 -0700 Received: from localhost ([127.0.0.1] helo=lists.colo.xensource.com) by lists.xensource.com with esmtp (Exim 4.43) id 1R1Jd5-0002Wa-39; Wed, 07 Sep 2011 08:01:31 -0700 Received: from mail27.messagelabs.com ([193.109.254.147]) by lists.xensource.com with smtp (Exim 4.43) id 1R1Ja6-00027v-93 for xen-devel@lists.xensource.com; Wed, 07 Sep 2011 07:58:36 -0700 X-Env-Sender: Ian.Jackson@eu.citrix.com X-Msg-Ref: server-8.tower-27.messagelabs.com!1315407485!45621705!1 X-Originating-IP: [62.200.22.115] X-StarScan-Version: 6.3.6; banners=-,-,- X-VirusChecked: Checked Received: (qmail 11061 invoked from network); 7 Sep 2011 14:58:05 -0000 Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115) by server-8.tower-27.messagelabs.com with SMTP; 7 Sep 2011 14:58:05 -0000 X-IronPort-AV: E=Sophos;i="4.68,345,1312156800"; d="scan'208";a="7655935" Received: from lonpmailmx01.citrite.net ([10.30.203.162]) by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5; 07 Sep 2011 14:58:08 +0000 Received: from woking.xci-test.com (10.80.248.135) by smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id 8.3.137.0; Wed, 7 Sep 2011 15:58:09 +0100 Received: from osstest by woking.xci-test.com with local (Exim 4.69) (envelope-from ) id 1R1JZo-0005t4-Hc; Wed, 07 Sep 2011 15:58:08 +0100 To: Message-ID: From: xen.org Date: Wed, 7 Sep 2011 15:58:08 +0100 MIME-Version: 1.0 Content-Type: text/plain Cc: ian.jackson@eu.citrix.com Subject: [Xen-devel] [xen-4.1-testing test] 8845: regressions - FAIL X-BeenThere: xen-devel@lists.xensource.com X-Mailman-Version: 2.1.5 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xensource.com Errors-To: xen-devel-bounces@lists.xensource.com flight 8845 xen-4.1-testing real [real] http://www.chiark.greenend.org.uk/~xensrcts/logs/8845/ Regressions :-( Tests which did not succeed and are blocking: build-i386-pvops 4 kernel-build fail REGR. vs. 8808 build-amd64-pvops 4 kernel-build fail REGR. vs. 8808 Tests which did not succeed, but are not blocking, including regressions (tests previously passed) regarded as allowable: test-amd64-amd64-xl-pcipt-intel 1 xen-build-check(1) blocked n/a test-amd64-amd64-pv 1 xen-build-check(1) blocked n/a test-amd64-i386-rhel6hvm-intel 1 xen-build-check(1) blocked n/a test-i386-i386-pv 1 xen-build-check(1) blocked n/a test-amd64-i386-pv 1 xen-build-check(1) blocked n/a test-amd64-i386-xl-credit2 1 xen-build-check(1) blocked n/a test-i386-i386-xl 1 xen-build-check(1) blocked n/a test-amd64-amd64-xl 1 xen-build-check(1) blocked n/a test-amd64-i386-xl-multivcpu 1 xen-build-check(1) blocked n/a test-amd64-i386-xl 1 xen-build-check(1) blocked n/a test-amd64-i386-rhel6hvm-amd 1 xen-build-check(1) blocked n/a test-amd64-amd64-pair 1 xen-build-check(1) blocked n/a test-i386-i386-pair 1 xen-build-check(1) blocked n/a test-amd64-i386-pair 1 xen-build-check(1) blocked n/a test-amd64-amd64-xl-sedf 1 xen-build-check(1) blocked n/a test-amd64-i386-win-vcpus1 1 xen-build-check(1) blocked n/a test-amd64-i386-xl-win-vcpus1 1 xen-build-check(1) blocked n/a test-amd64-i386-win 1 xen-build-check(1) blocked n/a test-amd64-amd64-win 1 xen-build-check(1) blocked n/a test-amd64-amd64-xl-win 1 xen-build-check(1) blocked n/a test-i386-i386-win 1 xen-build-check(1) blocked n/a test-i386-i386-xl-win 1 xen-build-check(1) blocked n/a version targeted for testing: xen 2376070f6685 baseline version: xen 6239209bb560 ------------------------------------------------------------ People who touched revisions under test: Jan Beulich Stefano Stabellini ------------------------------------------------------------ jobs: build-amd64 pass build-i386 pass build-amd64-oldkern pass build-i386-oldkern pass build-amd64-pvops fail build-i386-pvops fail test-amd64-amd64-xl blocked test-amd64-i386-xl blocked test-i386-i386-xl blocked test-amd64-i386-rhel6hvm-amd blocked test-amd64-i386-xl-credit2 blocked test-amd64-amd64-xl-pcipt-intel blocked test-amd64-i386-rhel6hvm-intel blocked test-amd64-i386-xl-multivcpu blocked test-amd64-amd64-pair blocked test-amd64-i386-pair blocked test-i386-i386-pair blocked test-amd64-amd64-pv blocked test-amd64-i386-pv blocked test-i386-i386-pv blocked test-amd64-amd64-xl-sedf blocked test-amd64-i386-win-vcpus1 blocked test-amd64-i386-xl-win-vcpus1 blocked test-amd64-amd64-win blocked test-amd64-i386-win blocked test-i386-i386-win blocked test-amd64-amd64-xl-win blocked test-i386-i386-xl-win blocked ------------------------------------------------------------ sg-report-flight on woking.cam.xci-test.com logs: /home/xc_osstest/logs images: /home/xc_osstest/images Logs, config files, etc. are available at http://www.chiark.greenend.org.uk/~xensrcts/logs Test harness code can be found at http://xenbits.xensource.com/gitweb?p=osstest.git;a=summary Not pushing. ------------------------------------------------------------ changeset: 23151:2376070f6685 tag: tip user: Keir Fraser date: Wed Sep 07 10:41:01 2011 +0100 Added signature for changeset 3e6a3bf83935 changeset: 23150:be0040eb0a36 user: Keir Fraser date: Wed Sep 07 10:40:51 2011 +0100 Added tag 4.1.2-rc2 for changeset 3e6a3bf83935 changeset: 23149:3e6a3bf83935 tag: 4.1.2-rc2 user: Keir Fraser date: Wed Sep 07 10:40:42 2011 +0100 Update Xen version to 4.1.2-rc2 changeset: 23148:c4172ba1a98b user: Jan Beulich date: Wed Sep 07 10:39:59 2011 +0100 bitmap_scnlistprintf() should always zero-terminate its output buffer ... as long as it has non-zero size. So far this would not happen if the passed in CPU mask was empty. Also fix the comment describing the return value to actually match reality. Signed-off-by: Jan Beulich xen-unstable changeset: 23820:ba75234a6f56 xen-unstable date: Wed Sep 07 10:36:55 2011 +0100 changeset: 23147:6239209bb560 user: Stefano Stabellini date: Wed Aug 31 15:32:47 2011 +0100 xen: __hvm_pci_intx_assert should check for gsis remapped onto pirqs If the isa irq corresponding to a particular gsi is disabled while the gsi is enabled, __hvm_pci_intx_assert will always inject the gsi through the violapic, even if the gsi has been remapped onto a pirq. This patch makes sure that even in this case we inject the notification appropriately. Signed-off-by: Stefano Stabellini xen-unstable changeset: 23807:2297b90a6a7b xen-unstable date: Wed Aug 31 15:23:34 2011 +0100 (qemu changes not included) _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel From xen-devel-bounces@lists.xensource.com Wed Sep 07 08:10:56 2011 Return-path: Envelope-to: www-data@lists.xensource.com Delivery-date: Wed, 07 Sep 2011 08:10:56 -0700 Received: from localhost ([127.0.0.1] helo=lists.colo.xensource.com) by lists.xensource.com with esmtp (Exim 4.43) id 1R1JmC-0003gt-Oi; Wed, 07 Sep 2011 08:10:56 -0700 Received: from mail216.messagelabs.com ([85.158.143.99]) by lists.xensource.com with smtp (Exim 4.43) id 1R1JfL-0002iq-7c for xen-devel@lists.xensource.com; Wed, 07 Sep 2011 08:03:52 -0700 X-Env-Sender: Andrew.Cooper3@citrix.com X-Msg-Ref: server-10.tower-216.messagelabs.com!1315407827!9337472!1 X-Originating-IP: [62.200.22.115] X-StarScan-Version: 6.3.6; banners=-,-,- X-VirusChecked: Checked Received: (qmail 17356 invoked from network); 7 Sep 2011 15:03:48 -0000 Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115) by server-10.tower-216.messagelabs.com with SMTP; 7 Sep 2011 15:03:48 -0000 X-IronPort-AV: E=Sophos;i="4.68,345,1312156800"; d="scan'208";a="7656071" Received: from lonpmailmx01.citrite.net ([10.30.203.162]) by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5; 07 Sep 2011 15:03:18 +0000 Received: from andrewcoop.uk.xensource.com (10.80.2.18) by LONPMAILMX01.citrite.net (10.30.203.162) with Microsoft SMTP Server id 8.3.137.0; Wed, 7 Sep 2011 16:03:18 +0100 Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Mercurial-Node: c7884dbb6f7de438535be6645e3b9b1d079887d3 Message-ID: User-Agent: Mercurial-patchbomb/1.4.3 Date: Wed, 7 Sep 2011 16:03:18 +0100 From: Andrew Cooper To: xen-devel@lists.xensource.com Cc: Andrew Cooper Subject: [Xen-devel] [PATCH] IRQ: Group IRQ_MOVE_CLEANUP_VECTOR with other hypervisor IPIs X-BeenThere: xen-devel@lists.xensource.com X-Mailman-Version: 2.1.5 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xensource.com Errors-To: xen-devel-bounces@lists.xensource.com Also, rename to MOVE_CLEANUP_VECTOR to be in line with the other IPI names. This requires bumping LAST_HIPRIORITY_VECTOR, but does mean that the range FIRST-LAST_HIPRIORITY_VECTORs are free once again. Signed-off-by: Andrew Cooper diff -r 0268e7380953 -r c7884dbb6f7d xen/arch/x86/apic.c --- a/xen/arch/x86/apic.c Mon Sep 05 15:10:28 2011 +0100 +++ b/xen/arch/x86/apic.c Wed Sep 07 16:00:55 2011 +0100 @@ -90,7 +90,7 @@ bool_t __read_mostly directed_eoi_enable * through the ICC by us (IPIs) */ __asm__(".section .text"); -BUILD_SMP_INTERRUPT(irq_move_cleanup_interrupt,IRQ_MOVE_CLEANUP_VECTOR) +BUILD_SMP_INTERRUPT(irq_move_cleanup_interrupt,MOVE_CLEANUP_VECTOR) BUILD_SMP_INTERRUPT(event_check_interrupt,EVENT_CHECK_VECTOR) BUILD_SMP_INTERRUPT(invalidate_interrupt,INVALIDATE_TLB_VECTOR) BUILD_SMP_INTERRUPT(call_function_interrupt,CALL_FUNCTION_VECTOR) diff -r 0268e7380953 -r c7884dbb6f7d xen/arch/x86/hvm/vmx/vmx.c --- a/xen/arch/x86/hvm/vmx/vmx.c Mon Sep 05 15:10:28 2011 +0100 +++ b/xen/arch/x86/hvm/vmx/vmx.c Wed Sep 07 16:00:55 2011 +0100 @@ -1986,7 +1986,7 @@ static void vmx_do_extint(struct cpu_use switch ( vector ) { - case IRQ_MOVE_CLEANUP_VECTOR: + case MOVE_CLEANUP_VECTOR: smp_irq_move_cleanup_interrupt(regs); break; case LOCAL_TIMER_VECTOR: diff -r 0268e7380953 -r c7884dbb6f7d xen/arch/x86/io_apic.c --- a/xen/arch/x86/io_apic.c Mon Sep 05 15:10:28 2011 +0100 +++ b/xen/arch/x86/io_apic.c Wed Sep 07 16:00:55 2011 +0100 @@ -476,7 +476,7 @@ fastcall void smp_irq_move_cleanup_inter * to myself. */ if (irr & (1 << (vector % 32))) { - genapic->send_IPI_self(IRQ_MOVE_CLEANUP_VECTOR); + genapic->send_IPI_self(MOVE_CLEANUP_VECTOR); TRACE_3D(TRC_HW_IRQ_MOVE_CLEANUP_DELAY, irq, vector, smp_processor_id()); goto unlock; @@ -513,7 +513,7 @@ static void send_cleanup_vector(struct i cpus_and(cleanup_mask, cfg->old_cpu_mask, cpu_online_map); cfg->move_cleanup_count = cpus_weight(cleanup_mask); - genapic->send_IPI_mask(&cleanup_mask, IRQ_MOVE_CLEANUP_VECTOR); + genapic->send_IPI_mask(&cleanup_mask, MOVE_CLEANUP_VECTOR); cfg->move_in_progress = 0; } diff -r 0268e7380953 -r c7884dbb6f7d xen/arch/x86/irq.c --- a/xen/arch/x86/irq.c Mon Sep 05 15:10:28 2011 +0100 +++ b/xen/arch/x86/irq.c Wed Sep 07 16:00:55 2011 +0100 @@ -338,7 +338,7 @@ int __init init_irq_data(void) set_bit(HYPERCALL_VECTOR, used_vectors); /* IRQ_MOVE_CLEANUP_VECTOR used for clean up vectors */ - set_bit(IRQ_MOVE_CLEANUP_VECTOR, used_vectors); + set_bit(MOVE_CLEANUP_VECTOR, used_vectors); return 0; } diff -r 0268e7380953 -r c7884dbb6f7d xen/arch/x86/smpboot.c --- a/xen/arch/x86/smpboot.c Mon Sep 05 15:10:28 2011 +0100 +++ b/xen/arch/x86/smpboot.c Wed Sep 07 16:00:55 2011 +0100 @@ -1027,7 +1027,7 @@ void __init smp_intr_init(void) } /* IPI for cleanuping vectors after irq move */ - set_intr_gate(IRQ_MOVE_CLEANUP_VECTOR, irq_move_cleanup_interrupt); + set_intr_gate(MOVE_CLEANUP_VECTOR, irq_move_cleanup_interrupt); /* IPI for event checking. */ set_intr_gate(EVENT_CHECK_VECTOR, event_check_interrupt); diff -r 0268e7380953 -r c7884dbb6f7d xen/include/asm-x86/mach-default/irq_vectors.h --- a/xen/include/asm-x86/mach-default/irq_vectors.h Mon Sep 05 15:10:28 2011 +0100 +++ b/xen/include/asm-x86/mach-default/irq_vectors.h Wed Sep 07 16:00:55 2011 +0100 @@ -11,12 +11,14 @@ #define LOCAL_TIMER_VECTOR 0xf9 #define PMU_APIC_VECTOR 0xf8 #define CMCI_APIC_VECTOR 0xf7 +#define MOVE_CLEANUP_VECTOR 0xf6 + /* * High-priority dynamically-allocated vectors. For interrupts that * must be higher priority than any guest-bound interrupt. */ #define FIRST_HIPRIORITY_VECTOR 0xf0 -#define LAST_HIPRIORITY_VECTOR 0xf6 +#define LAST_HIPRIORITY_VECTOR 0xf5 /* Legacy PIC uses vectors 0xe0-0xef. */ #define FIRST_LEGACY_VECTOR 0xe0 @@ -30,8 +32,6 @@ #define LAST_DYNAMIC_VECTOR 0xdf #define NR_DYNAMIC_VECTORS (LAST_DYNAMIC_VECTOR - FIRST_DYNAMIC_VECTOR + 1) -#define IRQ_MOVE_CLEANUP_VECTOR FIRST_DYNAMIC_VECTOR - #define NR_VECTORS 256 #endif /* _ASM_IRQ_VECTORS_H */ _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel From xen-devel-bounces@lists.xensource.com Wed Sep 07 08:16:01 2011 Return-path: Envelope-to: www-data@lists.xensource.com Delivery-date: Wed, 07 Sep 2011 08:16:01 -0700 Received: from localhost ([127.0.0.1] helo=lists.colo.xensource.com) by lists.xensource.com with esmtp (Exim 4.43) id 1R1Jr6-0004Fi-5t; Wed, 07 Sep 2011 08:16:00 -0700 Received: from mail174.messagelabs.com ([85.158.138.51]) by lists.xensource.com with smtp (Exim 4.43) id 1R1JqX-00043c-Nm for xen-devel@lists.xensource.com; Wed, 07 Sep 2011 08:15:26 -0700 X-Env-Sender: Ian.Jackson@eu.citrix.com X-Msg-Ref: server-2.tower-174.messagelabs.com!1315408520!30586488!1 X-Originating-IP: [62.200.22.115] X-StarScan-Version: 6.3.6; banners=-,-,- X-VirusChecked: Checked Received: (qmail 6884 invoked from network); 7 Sep 2011 15:15:20 -0000 Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115) by server-2.tower-174.messagelabs.com with SMTP; 7 Sep 2011 15:15:20 -0000 X-IronPort-AV: E=Sophos;i="4.68,346,1312156800"; d="scan'208";a="7656476" Received: from lonpmailmx01.citrite.net ([10.30.203.162]) by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5; 07 Sep 2011 15:15:19 +0000 Received: from woking.xci-test.com (10.80.248.135) by smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id 8.3.137.0; Wed, 7 Sep 2011 16:15:19 +0100 Received: from osstest by woking.xci-test.com with local (Exim 4.69) (envelope-from ) id 1R1JqR-0004Ei-9r; Wed, 07 Sep 2011 16:15:19 +0100 To: xen-devel@lists.xensource.com Message-ID: From: xen.org Date: Wed, 7 Sep 2011 16:15:19 +0100 MIME-Version: 1.0 Content-Type: text/plain Cc: ian.jackson@eu.citrix.com Subject: [Xen-devel] [xen-unstable test] 8846: regressions - FAIL X-BeenThere: xen-devel@lists.xensource.com X-Mailman-Version: 2.1.5 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xensource.com Errors-To: xen-devel-bounces@lists.xensource.com flight 8846 xen-unstable real [real] http://www.chiark.greenend.org.uk/~xensrcts/logs/8846/ Regressions :-( Tests which did not succeed and are blocking: build-amd64-pvops 4 kernel-build fail REGR. vs. 8833 build-i386-pvops 4 kernel-build fail REGR. vs. 8833 Tests which did not succeed, but are not blocking, including regressions (tests previously passed) regarded as allowable: test-amd64-amd64-xl-pcipt-intel 1 xen-build-check(1) blocked n/a test-i386-i386-pv 1 xen-build-check(1) blocked n/a test-amd64-i386-pv 1 xen-build-check(1) blocked n/a test-amd64-i386-rhel6hvm-intel 1 xen-build-check(1) blocked n/a test-amd64-amd64-pv 1 xen-build-check(1) blocked n/a test-i386-i386-xl 1 xen-build-check(1) blocked n/a test-amd64-i386-xl 1 xen-build-check(1) blocked n/a test-amd64-i386-xl-credit2 1 xen-build-check(1) blocked n/a test-amd64-i386-pair 1 xen-build-check(1) blocked n/a test-i386-i386-pair 1 xen-build-check(1) blocked n/a test-amd64-i386-xl-multivcpu 1 xen-build-check(1) blocked n/a test-amd64-amd64-xl-sedf 1 xen-build-check(1) blocked n/a test-amd64-i386-win-vcpus1 1 xen-build-check(1) blocked n/a test-amd64-i386-xl-win-vcpus1 1 xen-build-check(1) blocked n/a test-amd64-i386-rhel6hvm-amd 1 xen-build-check(1) blocked n/a test-amd64-amd64-win 1 xen-build-check(1) blocked n/a test-amd64-i386-win 1 xen-build-check(1) blocked n/a test-amd64-amd64-xl-win 1 xen-build-check(1) blocked n/a test-amd64-amd64-xl 1 xen-build-check(1) blocked n/a test-i386-i386-xl-win 1 xen-build-check(1) blocked n/a test-i386-i386-win 1 xen-build-check(1) blocked n/a test-amd64-amd64-pair 1 xen-build-check(1) blocked n/a version targeted for testing: xen bdd19847ae63 baseline version: xen 5fe770c8a8a3 ------------------------------------------------------------ People who touched revisions under test: Ian Jackson Jan Beulich Keir Fraser Olaf Hering ------------------------------------------------------------ jobs: build-amd64 pass build-i386 pass build-amd64-oldkern pass build-i386-oldkern pass build-amd64-pvops fail build-i386-pvops fail test-amd64-amd64-xl blocked test-amd64-i386-xl blocked test-i386-i386-xl blocked test-amd64-i386-rhel6hvm-amd blocked test-amd64-i386-xl-credit2 blocked test-amd64-amd64-xl-pcipt-intel blocked test-amd64-i386-rhel6hvm-intel blocked test-amd64-i386-xl-multivcpu blocked test-amd64-amd64-pair blocked test-amd64-i386-pair blocked test-i386-i386-pair blocked test-amd64-amd64-pv blocked test-amd64-i386-pv blocked test-i386-i386-pv blocked test-amd64-amd64-xl-sedf blocked test-amd64-i386-win-vcpus1 blocked test-amd64-i386-xl-win-vcpus1 blocked test-amd64-amd64-win blocked test-amd64-i386-win blocked test-i386-i386-win blocked test-amd64-amd64-xl-win blocked test-i386-i386-xl-win blocked ------------------------------------------------------------ sg-report-flight on woking.cam.xci-test.com logs: /home/xc_osstest/logs images: /home/xc_osstest/images Logs, config files, etc. are available at http://www.chiark.greenend.org.uk/~xensrcts/logs Test harness code can be found at http://xenbits.xensource.com/gitweb?p=osstest.git;a=summary Not pushing. ------------------------------------------------------------ changeset: 23822:bdd19847ae63 tag: tip user: Olaf Hering date: Wed Sep 07 10:37:48 2011 +0100 p2m-ept: remove map_domain_page check map_domain_page() can not fail, remove ASSERT in ept_set_entry(). Signed-off-by: Olaf Hering changeset: 23821:88065fb8d0aa user: Jan Beulich date: Wed Sep 07 10:37:20 2011 +0100 x86: remove unnecessary indirection from irq_complete_move()'s sole parameter Signed-off-by: Jan Beulich changeset: 23820:ba75234a6f56 user: Jan Beulich date: Wed Sep 07 10:36:55 2011 +0100 bitmap_scnlistprintf() should always zero-terminate its output buffer ... as long as it has non-zero size. So far this would not happen if the passed in CPU mask was empty. Also fix the comment describing the return value to actually match reality. Signed-off-by: Jan Beulich changeset: 23819:5fe770c8a8a3 user: Keir Fraser date: Tue Sep 06 15:49:40 2011 +0100 docs: Fix 'make docs' Signed-off-by: Keir Fraser ======================================== commit cd776ee9408ff127f934a707c1a339ee600bc127 Author: Ian Jackson Date: Tue Jun 28 13:50:53 2011 +0100 qemu-char.c: fix incorrect CONFIG_STUBDOM handling qemu-char.c:1123:7: warning: "CONFIG_STUBDOM" is not defined [-Wundef] Signed-off-by: Olaf Hering Acked-by: Ian Jackson _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel From xen-devel-bounces@lists.xensource.com Wed Sep 07 08:21:56 2011 Return-path: Envelope-to: www-data@lists.xensource.com Delivery-date: Wed, 07 Sep 2011 08:21:56 -0700 Received: from localhost ([127.0.0.1] helo=lists.colo.xensource.com) by lists.xensource.com with esmtp (Exim 4.43) id 1R1Jwq-0004hu-Sc; Wed, 07 Sep 2011 08:21:56 -0700 Received: from mail27.messagelabs.com ([193.109.254.147]) by lists.xensource.com with esmtp (Exim 4.43) id 1R1JwA-0004Vi-T2 for xen-devel@lists.xensource.com; Wed, 07 Sep 2011 08:21:15 -0700 X-Env-Sender: matthew.fioravante@jhuapl.edu X-Msg-Ref: server-9.tower-27.messagelabs.com!1315408855!43555596!1 X-Originating-IP: [128.244.251.36] X-StarScan-Version: 6.3.6; banners=-,-,- X-VirusChecked: Checked Received: (qmail 20849 invoked from network); 7 Sep 2011 15:20:56 -0000 Received: from pilot.jhuapl.edu (HELO jhuapl.edu) (128.244.251.36) by server-9.tower-27.messagelabs.com with DHE-RSA-AES256-SHA encrypted SMTP; 7 Sep 2011 15:20:56 -0000 Received: from ([128.244.207.50]) by pilot.jhuapl.edu with ESMTP with TLS id 63GHCH1.123902763; Wed, 07 Sep 2011 11:21:03 -0400 Message-ID: <4E678BDB.6000509@jhuapl.edu> Date: Wed, 07 Sep 2011 11:20:59 -0400 From: Matthew Fioravante User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.2.18) Gecko/20110617 Thunderbird/3.1.11 MIME-Version: 1.0 To: Ian Campbell Subject: Re: [Xen-devel] vTPM Manager References: <4E520471.5010804@seceng.informatik.tu-darmstadt.de> <1314002521.5010.395.camel@zakaz.uk.xensource.com> <4E5C079D.8000006@jhuapl.edu> <1314700661.10283.137.camel@zakaz.uk.xensource.com> In-Reply-To: <1314700661.10283.137.camel@zakaz.uk.xensource.com> X-Enigmail-Version: 1.1.2 Cc: "xen-devel@lists.xensource.com" X-BeenThere: xen-devel@lists.xensource.com X-Mailman-Version: 2.1.5 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============2053263620==" Sender: xen-devel-bounces@lists.xensource.com Errors-To: xen-devel-bounces@lists.xensource.com This is a cryptographically signed message in MIME format. --===============2053263620== Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha1; boundary="------------ms040609080702000308020007" This is a cryptographically signed message in MIME format. --------------ms040609080702000308020007 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable I plan to sometime in the future. There are some adjustments that need to be made first. On 08/30/2011 06:37 AM, Ian Campbell wrote: > On Mon, 2011-08-29 at 22:41 +0100, Matthew Fioravante wrote: >> You can also try to use my updated vtpm manager patches which fixes a >> lot of bugs. I haven't tried them on the latest xen unstable but they >> worked with xen at the time they were submitted. They have not been >> accepted by the developers yet. You should be able to find my earlier >> posts in the mailing list archives > These seem to have fallen through the cracks. Would you mind rebasing > and resubmitting? > > Ian. > >> On 08/22/2011 04:42 AM, Ian Campbell wrote: >>> On Mon, 2011-08-22 at 08:25 +0100, Sebastian Biedermann wrote: >>>> Dear List, >>>> >>>> I have a problem installing the vTPM extension for Xen. >>>> I selected the option vTPM Manager (=3Dy) in the Config.mk before=20 >>>> compiling the xen-tools, but there is always the same error during t= he=20 >>>> compilation in every xen version which I have tried: >>> I haven't seen anyone using or maintaining the vtpm stuff for ages no= w. >>> I expect it has bitrotted something rotten (if you'll excuse the pun)= =2E >>> I'm afraid this may mean you need to dig into the code. >>> >>> (For future reference it is useful to reproduce build errors with LAN= G=3DC >>> before posting to the lists) >>> >>>> gcc -Werror -g3 -I. -D_GNU_SOURCE=20 >>>> -DLOGGING_MODULES=3D"(BITMASK(VTPM_LOG_TCS)|BITMASK(VTPM_LOG_VTSP)|B= ITMASK(VTPM_LOG_VTPM))"=20 >>>> -I../../../tools/vtpm_manager/crypto -I../../../tools/vtpm_manager/u= til=20 >>>> -I../../../tools/vtpm_manager/tcs -I../../../tools/vtpm_manager/mana= ger=20 >>>> -c -o sym_crypto.o sym_crypto.c >>>> cc1: warnings being treated as errors >>>> sym_crypto.c: In function =C3=A2Crypto_symcrypto_initkey=C3=A2: >>>> sym_crypto.c:71:3: error: format =C3=A2%s=C3=A2 expects type =C3=A2c= har *=C3=A2, but=20 >>>> argument 6 has type =C3=A2int=C3=A2 >>> This appears to be from the TPMTRYRETURN macro in >>> tools/vtpm_manager/util/tcg.h which is: >>> // Try command c. If it fails, print error message, set status to act= ual return code. Goto abort >>> #define TPMTRYRETURN(c) do { status =3D c; \ >>> if (status !=3D TPM_SUCCESS) { \ >>> fprintf(stderr, "ERROR in %s at %s:%i = code: %s.\n", __func__, __FILE__, __LINE__, tpm_get_error_name(status)); = \ >>> goto abort_egress; \ >>> } \ >>> } while(0) =20 >>> >>> argument 6 is "tpm_get_error_name(status)" which is defined as=20 >>> const char* tpm_get_error_name (TPM_RESULT code); >>> in tools/vtpm_manager/util/log.h.=20 >>> >>> This is a "char *" as the %s requires and not an "int" like the messa= ge >>> is complaining. If the prototype for tpm_get_error_name were missing = it >>> would default to returning int but I'm pretty sure gcc would way >>> something if this were the case -- but you could maybe try adding=20 >>> #include "log.h" >>> to sym_crypto.c right above the include of tcg.h? >>> >>> Ian. >>> >>>> sym_crypto.c: In function =C3=A2Crypto_symcrypto_genkey=C3=A2: >>>> sym_crypto.c:94:3: error: format =C3=A2%s=C3=A2 expects type =C3=A2c= har *=C3=A2, but=20 >>>> argument 6 has type =C3=A2int=C3=A2 >>>> sym_crypto.c: In function =C3=A2Crypto_symcrypto_encrypt=C3=A2: >>>> sym_crypto.c:134:3: error: format =C3=A2%s=C3=A2 expects type =C3=A2= char *=C3=A2, but=20 >>>> argument 6 has type =C3=A2int=C3=A2 >>>> sym_crypto.c: In function =C3=A2Crypto_symcrypto_decrypt=C3=A2: >>>> sym_crypto.c:165:3: error: format =C3=A2%s=C3=A2 expects type =C3=A2= char *=C3=A2, but=20 >>>> argument 6 has type =C3=A2int=C3=A2 >>>> sym_crypto.c:172:3: error: format =C3=A2%s=C3=A2 expects type =C3=A2= char *=C3=A2, but=20 >>>> argument 6 has type =C3=A2int=C3=A2 >>>> make[5]: *** [sym_crypto.o] Fehler 1 >>>> make[5]: *** Warte auf noch nicht beendete Prozesse... >>>> make[5]: Verlasse Verzeichnis=20 >>>> '/home/toor/xen-4.1.1/tools/vtpm_manager/crypto' >>>> make[4]: *** [subdir-install-crypto] Fehler 2 >>>> make[4]: Verlasse Verzeichnis '/home/toor/xen-4.1.1/tools/vtpm_manag= er' >>>> make[3]: *** [subdirs-install] Fehler 2 >>>> make[3]: Verlasse Verzeichnis '/home/toor/xen-4.1.1/tools/vtpm_manag= er' >>>> make[2]: *** [subdir-install-vtpm_manager] Fehler 2 >>>> make[2]: Verlasse Verzeichnis '/home/toor/xen-4.1.1/tools' >>>> make[1]: *** [subdirs-install] Fehler 2 >>>> make[1]: Verlasse Verzeichnis '/home/toor/xen-4.1.1/tools' >>>> make: *** [install-tools] Fehler 2 >>>> >>>> Any suggestions? What is wrong? Thanks for help! >>>> >>> >>> _______________________________________________ >>> Xen-devel mailing list >>> Xen-devel@lists.xensource.com >>> http://lists.xensource.com/xen-devel >> > --------------ms040609080702000308020007 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIHZzCC A5kwggMCoAMCAQICBD/xkcEwDQYJKoZIhvcNAQEFBQAwLzELMAkGA1UEBhMCVVMxDzANBgNV BAoTBkpIVUFQTDEPMA0GA1UECxMGQklTRENBMB4XDTA5MDcxNzE1MDgwOVoXDTEyMDcxNzE1 MzgwOVowZjELMAkGA1UEBhMCVVMxDzANBgNVBAoTBkpIVUFQTDEPMA0GA1UECxMGUGVvcGxl MTUwFgYDVQQLEw9WUE5Hcm91cC1CSVNEQ0EwGwYDVQQDExRNYXR0aGV3IEUgRmlvcmF2YW50 ZTCBnzANBgkqhkiG9w0BAQEFAAOBjQAwgYkCgYEAyzeGk9zPA33fsB3uvk/Izs9GGHCpHI8b zXdBIVg6++S+jK53PoaWgmtSLr/c732ea1zPR6ACymwAWON+U5rB+VJAUZ4l/p0T3LZjE1Kq nbQJ+pgb+WAmBtdrxrtky61E9HD8dO70x37+ejhunpF9OuSU5MnOPmMx6ranvahUsOsCAwEA AaOCAYkwggGFMAsGA1UdDwQEAwIFIDAbBg0rBgEEAbMlCwMBAQEBBAoWCGZpb3JhbWUxMBsG DSsGAQQBsyULAwEBAQIEChIIMDAxMDQyNjEwWAYJYIZIAYb6ax4BBEsMSVRoZSBwcml2YXRl IGtleSBjb3JyZXNwb25kaW5nIHRvIHRoaXMgY2VydGlmaWNhdGUgbWF5IGhhdmUgYmVlbiBl eHBvcnRlZC4wKAYDVR0RBCEwH4EdTWF0dGhldy5GaW9yYXZhbnRlQGpodWFwbC5lZHUwUgYD VR0fBEswSTBHoEWgQ6RBMD8xCzAJBgNVBAYTAlVTMQ8wDQYDVQQKEwZKSFVBUEwxDzANBgNV BAsTBkJJU0RDQTEOMAwGA1UEAxMFQ1JMNDkwHwYDVR0jBBgwFoAUCDUpmxH52EU2CyWmF2EJ MB1yqeswHQYDVR0OBBYEFO3ziReJlElP3ilaLQ5gwsg0RlgoMAkGA1UdEwQCMAAwGQYJKoZI hvZ9B0EABAwwChsEVjcuMQMCBLAwDQYJKoZIhvcNAQEFBQADgYEAMOY3Zf6gx3gv/fDd11cz h2Daj+8NExx/2Le3c88gfDVhPVgVX5S52EjeFbK5yVP0Xlm82vRADO47dTA2PKbpp50rJcAZ rl5bg5tQ/WbLAaRITCtOJWVVKXD9V7X2o3Z/IM2op3hb4mmDXSDS+Hzn0Jd2mAXl4iHPfI0p XlXqA9QwggPGMIIDL6ADAgECAgQ/8cn9MA0GCSqGSIb3DQEBBQUAMC8xCzAJBgNVBAYTAlVT MQ8wDQYDVQQKEwZKSFVBUEwxDzANBgNVBAsTBkJJU0RDQTAeFw0xMDA2MTExODIyMDZaFw0x MzA2MTExODUyMDZaMGYxCzAJBgNVBAYTAlVTMQ8wDQYDVQQKEwZKSFVBUEwxDzANBgNVBAsT BlBlb3BsZTE1MBYGA1UECxMPVlBOR3JvdXAtQklTRENBMBsGA1UEAxMUTWF0dGhldyBFIEZp b3JhdmFudGUwgZ8wDQYJKoZIhvcNAQEBBQADgY0AMIGJAoGBAJ6W8FUj+qNTW+ZXFu3Xd8k6 PYgSXYu6s+JwDTjBTyuyTsuZ6SjdYoqLrJdvFP7HFCREueYD8AFmCSt7lckALAOGnYAyouQ6 A9VBw0BMKW2O4hyyXqtDT6+AamDapwhT2xOhwvM0ia6+Kip/oFVEE9/UiBanYiDycGS/BWE0 UP87AgMBAAGjggG2MIIBsjALBgNVHQ8EBAMCB4AwKwYDVR0QBCQwIoAPMjAxMDA2MTExODIy MDZagQ8yMDEyMDcxNzIyNTIwNlowGwYNKwYBBAGzJQsDAQEBAQQKFghmaW9yYW1lMTAbBg0r BgEEAbMlCwMBAQECBAoSCDAwMTA0MjYxMFgGCWCGSAGG+mseAQRLDElUaGUgcHJpdmF0ZSBr ZXkgY29ycmVzcG9uZGluZyB0byB0aGlzIGNlcnRpZmljYXRlIG1heSBoYXZlIGJlZW4gZXhw b3J0ZWQuMCgGA1UdEQQhMB+BHU1hdHRoZXcuRmlvcmF2YW50ZUBqaHVhcGwuZWR1MFIGA1Ud HwRLMEkwR6BFoEOkQTA/MQswCQYDVQQGEwJVUzEPMA0GA1UEChMGSkhVQVBMMQ8wDQYDVQQL EwZCSVNEQ0ExDjAMBgNVBAMTBUNSTDU2MB8GA1UdIwQYMBaAFAg1KZsR+dhFNgslphdhCTAd cqnrMB0GA1UdDgQWBBTui2MYOq/cB2fs3ULQR59XWf2EzTAJBgNVHRMEAjAAMBkGCSqGSIb2 fQdBAAQMMAobBFY3LjEDAgSwMA0GCSqGSIb3DQEBBQUAA4GBACTvR0IeGDQoVS87maiuQESQ EQ/CaLoxmX3aO+arr4No1xUHtrBI7y58SWYJv6b/H3WWpKuPAlsI2ByrryKe7A40xLEH6Psu 0qTfzdjbyVlOUqnytVYGLTS0UaBiVAeUNWmfg4PeYN5Kqcn6VDCEiS/CClS7SVXzeH4IBVVG GfcMMYICMTCCAi0CAQEwNzAvMQswCQYDVQQGEwJVUzEPMA0GA1UEChMGSkhVQVBMMQ8wDQYD VQQLEwZCSVNEQ0ECBD/xyf0wCQYFKw4DAhoFAKCCAVAwGAYJKoZIhvcNAQkDMQsGCSqGSIb3 DQEHATAcBgkqhkiG9w0BCQUxDxcNMTEwOTA3MTUyMDU5WjAjBgkqhkiG9w0BCQQxFgQUAKwZ S1h7LzyT50ZVVxoIvr+zFZIwRgYJKwYBBAGCNxAEMTkwNzAvMQswCQYDVQQGEwJVUzEPMA0G A1UEChMGSkhVQVBMMQ8wDQYDVQQLEwZCSVNEQ0ECBD/xkcEwSAYLKoZIhvcNAQkQAgsxOaA3 MC8xCzAJBgNVBAYTAlVTMQ8wDQYDVQQKEwZKSFVBUEwxDzANBgNVBAsTBkJJU0RDQQIEP/GR wTBfBgkqhkiG9w0BCQ8xUjBQMAsGCWCGSAFlAwQBAjAKBggqhkiG9w0DBzAOBggqhkiG9w0D AgICAIAwDQYIKoZIhvcNAwICAUAwBwYFKw4DAgcwDQYIKoZIhvcNAwICASgwDQYJKoZIhvcN AQEBBQAEgYAfbSq5wBEfP9HFyoK1pe0uJr2oELrVJzGHxIvSu418CAyWZL1JFbGP1hTuXTHX HNQ2HHnXvNt/kRb3M15uwp/5aA5ZxUeW1K3PVDTRUD1JTGAWHMfbv7J6nctgP8BqGt5AX+Dx y58hkR13jOpMVTfiq8VyH/sG8F4GGuUxOAd2cwAAAAAAAA== --------------ms040609080702000308020007-- --===============2053263620== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel --===============2053263620==-- From xen-devel-bounces@lists.xensource.com Wed Sep 07 08:23:12 2011 Return-path: Envelope-to: www-data@lists.xensource.com Delivery-date: Wed, 07 Sep 2011 08:23:12 -0700 Received: from localhost ([127.0.0.1] helo=lists.colo.xensource.com) by lists.xensource.com with esmtp (Exim 4.43) id 1R1Jy4-0005B1-J6; Wed, 07 Sep 2011 08:23:12 -0700 Received: from mail174.messagelabs.com ([85.158.138.51]) by lists.xensource.com with esmtp (Exim 4.43) id 1R1JxE-0004on-Uz for xen-devel@lists.xensource.com; Wed, 07 Sep 2011 08:22:21 -0700 X-Env-Sender: javier.manzano@edu.uah.es X-Msg-Ref: server-7.tower-174.messagelabs.com!1315408932!30564192!1 X-Originating-IP: [216.139.236.26] X-StarScan-Version: 6.3.6; banners=-,-,- X-VirusChecked: Checked Received: (qmail 18021 invoked from network); 7 Sep 2011 15:22:17 -0000 Received: from sam.nabble.com (HELO sam.nabble.com) (216.139.236.26) by server-7.tower-174.messagelabs.com with AES256-SHA encrypted SMTP; 7 Sep 2011 15:22:17 -0000 Received: from [192.168.236.26] (helo=sam.nabble.com) by sam.nabble.com with esmtp (Exim 4.72) (envelope-from ) id 1R1Jx5-0004Gb-MP for xen-devel@lists.xensource.com; Wed, 07 Sep 2011 08:22:11 -0700 Date: Wed, 7 Sep 2011 08:22:11 -0700 (PDT) From: JavMV To: xen-devel@lists.xensource.com Message-ID: <1315408931610-4778925.post@n5.nabble.com> In-Reply-To: <1315405921936-4778727.post@n5.nabble.com> References: <1315231341254-4770602.post@n5.nabble.com> <1315310225039-4774097.post@n5.nabble.com> <1315343879.61837.YahooMailNeo@web29818.mail.ird.yahoo.com> <1315382742268-4777689.post@n5.nabble.com> <1315389138.56652.YahooMailNeo@web29801.mail.ird.yahoo.com> <1315398360680-4778339.post@n5.nabble.com> <1315401901083-4778494.post@n5.nabble.com> <1315403644525-4778586.post@n5.nabble.com> <1315405372.87224.YahooMailNeo@web29801.mail.ird.yahoo.com> <1315405921936-4778727.post@n5.nabble.com> Subject: Re: Re : Re : Re : [Xen-devel] Re: Patches for VGA-Passthrough XEN 4.2 unstable MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-BeenThere: xen-devel@lists.xensource.com X-Mailman-Version: 2.1.5 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xensource.com Errors-To: xen-devel-bounces@lists.xensource.com I suppose you have modified the dsdt.asl file right? If you did it and it crashed (If you didn't try it with this let me know because I have to document the process of adapt the Tobias patches (Actually Han,Weidong patches)) then there is something that Xen devels have added between those changeset to the code that make the David's adaptation works (because David says he didn't add code to the patches). I was working on a specific computer with XEN at university and I can't try this patchset now, that is why I have to wait to end of month.. Im impatient!! Well thanks for the answers. Javier Manzano. ----- JavMV -- View this message in context: http://xen.1045712.n5.nabble.com/Patches-for-VGA-Passthrough-XEN-4-2-unstable-tp4406265p4778925.html Sent from the Xen - Dev mailing list archive at Nabble.com. _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel From xen-devel-bounces@lists.xensource.com Wed Sep 07 08:43:38 2011 Return-path: Envelope-to: www-data@lists.xensource.com Delivery-date: Wed, 07 Sep 2011 08:43:38 -0700 Received: from localhost ([127.0.0.1] helo=lists.colo.xensource.com) by lists.xensource.com with esmtp (Exim 4.43) id 1R1KHq-000659-3p; Wed, 07 Sep 2011 08:43:38 -0700 Received: from mail21.messagelabs.com ([85.158.143.35]) by lists.xensource.com with smtp (Exim 4.43) id 1R1KHM-0005t7-9g for xen-devel@lists.xensource.com; Wed, 07 Sep 2011 08:43:08 -0700 X-Env-Sender: Stefano.Stabellini@eu.citrix.com X-Msg-Ref: server-12.tower-21.messagelabs.com!1315410171!49061328!1 X-Originating-IP: [62.200.22.115] X-StarScan-Version: 6.3.6; banners=-,-,- X-VirusChecked: Checked Received: (qmail 25902 invoked from network); 7 Sep 2011 15:42:51 -0000 Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115) by server-12.tower-21.messagelabs.com with SMTP; 7 Sep 2011 15:42:51 -0000 X-IronPort-AV: E=Sophos;i="4.68,346,1312156800"; d="scan'208";a="7657246" Received: from lonpmailmx01.citrite.net ([10.30.203.162]) by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5; 07 Sep 2011 15:42:39 +0000 Received: from kaball.uk.xensource.com (10.80.2.59) by LONPMAILMX01.citrite.net (10.30.203.162) with Microsoft SMTP Server id 8.3.137.0; Wed, 7 Sep 2011 16:42:39 +0100 Date: Wed, 7 Sep 2011 16:50:57 +0100 From: Stefano Stabellini X-X-Sender: sstabellini@kaball-desktop To: xen-devel@lists.xensource.com Message-ID: User-Agent: Alpine 2.00 (DEB 1167 2008-08-23) MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Subject: [Xen-devel] [PATCH] libxl: vcpu_avail is a bitmask, use it as such X-BeenThere: xen-devel@lists.xensource.com X-Mailman-Version: 2.1.5 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xensource.com Errors-To: xen-devel-bounces@lists.xensource.com vcpu_avail is a bitmask of available cpus but we are currently using it as the number of cpus available. This patch fixes it. Signed-off-by: Stefano Stabellini diff -r 6580ff415189 tools/libxl/libxl_dm.c --- a/tools/libxl/libxl_dm.c Wed Sep 07 13:29:15 2011 +0000 +++ b/tools/libxl/libxl_dm.c Wed Sep 07 15:39:46 2011 +0000 @@ -360,8 +360,13 @@ static char ** libxl__build_device_model } if (info->vcpus > 1) { flexarray_append(dm_args, "-smp"); + /* vcpu_avail is actually a bit mask, the new qemu doesn't + * support a bitmask of available cpus but it supports a + * number of available cpus lower than the maximum number of + * cpus. Let's do that for now. */ if (info->vcpu_avail) - flexarray_append(dm_args, libxl__sprintf(gc, "%d,maxcpus=%d", info->vcpus, info->vcpu_avail)); + flexarray_append(dm_args, libxl__sprintf(gc, "%d,maxcpus=%d", + __builtin_popcount(info->vcpu_avail), info->vcpus)); else flexarray_append(dm_args, libxl__sprintf(gc, "%d", info->vcpus)); } _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel From xen-devel-bounces@lists.xensource.com Wed Sep 07 09:04:12 2011 Return-path: Envelope-to: www-data@lists.xensource.com Delivery-date: Wed, 07 Sep 2011 09:04:12 -0700 Received: from localhost ([127.0.0.1] helo=lists.colo.xensource.com) by lists.xensource.com with esmtp (Exim 4.43) id 1R1Kbj-0006mr-10; Wed, 07 Sep 2011 09:04:11 -0700 Received: from mail216.messagelabs.com ([85.158.143.99]) by lists.xensource.com with smtp (Exim 4.43) id 1R1KZc-0006YN-2p for xen-devel@lists.xensource.com; Wed, 07 Sep 2011 09:02:10 -0700 X-Env-Sender: dzickus@redhat.com X-Msg-Ref: server-3.tower-216.messagelabs.com!1315411316!16385052!1 X-Originating-IP: [209.132.183.28] X-StarScan-Version: 6.3.6; banners=-,-,- X-VirusChecked: Checked Received: (qmail 3528 invoked from network); 7 Sep 2011 16:01:56 -0000 Received: from mx1.redhat.com (HELO mx1.redhat.com) (209.132.183.28) by server-3.tower-216.messagelabs.com with SMTP; 7 Sep 2011 16:01:56 -0000 Received: from int-mx09.intmail.prod.int.phx2.redhat.com (int-mx09.intmail.prod.int.phx2.redhat.com [10.5.11.22]) by mx1.redhat.com (8.14.4/8.14.4) with ESMTP id p87G0Qp4025493 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Wed, 7 Sep 2011 12:00:26 -0400 Received: from redhat.com (dhcp-100-19-141.bos.redhat.com [10.16.19.141]) by int-mx09.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with SMTP id p87FuvCK017484; Wed, 7 Sep 2011 11:56:58 -0400 Date: Wed, 7 Sep 2011 11:56:57 -0400 From: Don Zickus To: Avi Kivity Message-ID: <20110907155657.GX5795@redhat.com> References: <1314974826.1861.1.camel@twins> <4E612EA1.20007@goop.org> <1314996468.8255.0.camel@twins> <4E614FBD.2030509@goop.org> <20110906151408.GA7459@redhat.com> <4E66615E.8070806@goop.org> <20110906182758.GR5795@redhat.com> <4E66EF86.9070200@redhat.com> <20110907134411.GV5795@redhat.com> <4E678992.5050709@redhat.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <4E678992.5050709@redhat.com> User-Agent: Mutt/1.5.21 (2010-09-15) X-Scanned-By: MIMEDefang 2.68 on 10.5.11.22 Cc: Jeremy Fitzhardinge , Marcelo Tosatti , Nick Piggin , KVM , Stefano Stabellini , Peter Zijlstra , the arch/x86 maintainers , Linux Kernel Mailing List , Andi Kleen , Jeremy Fitzhardinge , "H. Peter Anvin" , Ingo Molnar , Linus Torvalds , Xen Devel Subject: [Xen-devel] Re: [PATCH 08/13] xen/pvticketlock: disable interrupts while blocking X-BeenThere: xen-devel@lists.xensource.com X-Mailman-Version: 2.1.5 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xensource.com Errors-To: xen-devel-bounces@lists.xensource.com On Wed, Sep 07, 2011 at 06:11:14PM +0300, Avi Kivity wrote: > On 09/07/2011 04:44 PM, Don Zickus wrote: > >> > >> Is there a way to tell whether an NMI was internally or externally > >> generated? > >> > >> I don't think so, especially as two or more NMIs can be coalesced. > >> So any NMI received on this first cpu has to check the NMI reason > >> port? > > > >Well we cheat and execute all the nmi handlers first. If they come back > >as handled, we skip the check for the external NMI. > > And hope that no other NMI was generated while we're handling this > one. It's a little... fragile? No. If another NMI is generated while we are processing the current one it should get latched. Upon completion of the current one, the cpu should jump right back into the nmi exception routine again. The only downside is when multiple NMIs come in during the processing of the current one. Only one can be latched, so the others get dropped. But we are addressing that. Cheers, Don > > >But you are right, other than checking the reason port, there isn't a way > >to determine if an NMI is internally or externally generated. > > Ouch. > > > > >> > >> >> > >> >> But on the other hand, I don't really care if you can say that this path > >> >> will never be called in a virtual machine. > >> > > >> >Does virtual machines support hot remove of cpus? Probably not > >> >considering bare-metal barely supports it. > >> > > >> > >> They do. > > > >But vcpus probably don't have the notion of a bsp cpu, so perhaps virtual > >machines can get away with it easier? (I don't know enough about the hot > >cpu remove code to really explain it, just enough to know it can cause > >problems and people are trying to address it). > > > > The concept of a bsp exists in exactly the same way as on real hardware. > > -- > error compiling committee.c: too many arguments to function > _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel From xen-devel-bounces@lists.xensource.com Wed Sep 07 09:05:49 2011 Return-path: Envelope-to: www-data@lists.xensource.com Delivery-date: Wed, 07 Sep 2011 09:05:49 -0700 Received: from localhost ([127.0.0.1] helo=lists.colo.xensource.com) by lists.xensource.com with esmtp (Exim 4.43) id 1R1KdJ-0007AN-EH; Wed, 07 Sep 2011 09:05:49 -0700 Received: from mail27.messagelabs.com ([193.109.254.147]) by lists.xensource.com with esmtp (Exim 4.43) id 1R1KaP-0006ZJ-CK for xen-devel@lists.xensource.com; Wed, 07 Sep 2011 09:02:50 -0700 X-Env-Sender: JBeulich@suse.com X-Msg-Ref: server-14.tower-27.messagelabs.com!1315411353!35164707!1 X-Originating-IP: [130.57.49.28] X-StarScan-Version: 6.3.6; banners=-,-,- X-VirusChecked: Checked Received: (qmail 19953 invoked from network); 7 Sep 2011 16:02:33 -0000 Received: from nat28.tlf.novell.com (HELO nat28.tlf.novell.com) (130.57.49.28) by server-14.tower-27.messagelabs.com with DHE-RSA-AES256-SHA encrypted SMTP; 7 Sep 2011 16:02:33 -0000 Received: from EMEA1-MTA by nat28.tlf.novell.com with Novell_GroupWise; Wed, 07 Sep 2011 17:02:45 +0100 Message-Id: <4E67B1DB020000780005517A@nat28.tlf.novell.com> X-Mailer: Novell GroupWise Internet Agent 8.0.1 Date: Wed, 07 Sep 2011 17:03:07 +0100 From: "Jan Beulich" To: "Andrew Cooper" Subject: Re: [Xen-devel] [PATCH] IRQ: Group IRQ_MOVE_CLEANUP_VECTOR with other hypervisor IPIs References: In-Reply-To: Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: quoted-printable Content-Disposition: inline Cc: xen-devel@lists.xensource.com X-BeenThere: xen-devel@lists.xensource.com X-Mailman-Version: 2.1.5 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xensource.com Errors-To: xen-devel-bounces@lists.xensource.com >>> On 07.09.11 at 17:03, Andrew Cooper wrote: Are you sure this is correct? I'm suspicious that this may intentionally have been the lowest priority vector... > Also, rename to MOVE_CLEANUP_VECTOR to be in line with the other IPI > names. Why would the removal of part of the descriptive name be in line with the other names? We're dealing with the cleanup after an IRQ move here, so let the name state this. The IRQ_ prefix here has nothing to do with this being the vector for a specific IRQ. Jan > This requires bumping LAST_HIPRIORITY_VECTOR, but does mean that the > range FIRST-LAST_HIPRIORITY_VECTORs are free once again. >=20 > Signed-off-by: Andrew Cooper >=20 > diff -r 0268e7380953 -r c7884dbb6f7d xen/arch/x86/apic.c > --- a/xen/arch/x86/apic.c Mon Sep 05 15:10:28 2011 +0100 > +++ b/xen/arch/x86/apic.c Wed Sep 07 16:00:55 2011 +0100 > @@ -90,7 +90,7 @@ bool_t __read_mostly directed_eoi_enable > * through the ICC by us (IPIs) > */ > __asm__(".section .text"); > -BUILD_SMP_INTERRUPT(irq_move_cleanup_interrupt,IRQ_MOVE_CLEANUP_VECTOR) > +BUILD_SMP_INTERRUPT(irq_move_cleanup_interrupt,MOVE_CLEANUP_VECTOR) > BUILD_SMP_INTERRUPT(event_check_interrupt,EVENT_CHECK_VECTOR) > BUILD_SMP_INTERRUPT(invalidate_interrupt,INVALIDATE_TLB_VECTOR) > BUILD_SMP_INTERRUPT(call_function_interrupt,CALL_FUNCTION_VECTOR) > diff -r 0268e7380953 -r c7884dbb6f7d xen/arch/x86/hvm/vmx/vmx.c > --- a/xen/arch/x86/hvm/vmx/vmx.c Mon Sep 05 15:10:28 2011 +0100 > +++ b/xen/arch/x86/hvm/vmx/vmx.c Wed Sep 07 16:00:55 2011 +0100 > @@ -1986,7 +1986,7 @@ static void vmx_do_extint(struct cpu_use > =20 > switch ( vector ) > { > - case IRQ_MOVE_CLEANUP_VECTOR: > + case MOVE_CLEANUP_VECTOR: > smp_irq_move_cleanup_interrupt(regs); > break; > case LOCAL_TIMER_VECTOR: > diff -r 0268e7380953 -r c7884dbb6f7d xen/arch/x86/io_apic.c > --- a/xen/arch/x86/io_apic.c Mon Sep 05 15:10:28 2011 +0100 > +++ b/xen/arch/x86/io_apic.c Wed Sep 07 16:00:55 2011 +0100 > @@ -476,7 +476,7 @@ fastcall void smp_irq_move_cleanup_inter > * to myself. > */ > if (irr & (1 << (vector % 32))) { > - genapic->send_IPI_self(IRQ_MOVE_CLEANUP_VECTOR); > + genapic->send_IPI_self(MOVE_CLEANUP_VECTOR); > TRACE_3D(TRC_HW_IRQ_MOVE_CLEANUP_DELAY, > irq, vector, smp_processor_id()); > goto unlock; > @@ -513,7 +513,7 @@ static void send_cleanup_vector(struct i > =20 > cpus_and(cleanup_mask, cfg->old_cpu_mask, cpu_online_map); > cfg->move_cleanup_count =3D cpus_weight(cleanup_mask); > - genapic->send_IPI_mask(&cleanup_mask, IRQ_MOVE_CLEANUP_VECTOR); > + genapic->send_IPI_mask(&cleanup_mask, MOVE_CLEANUP_VECTOR); > =20 > cfg->move_in_progress =3D 0; > } > diff -r 0268e7380953 -r c7884dbb6f7d xen/arch/x86/irq.c > --- a/xen/arch/x86/irq.c Mon Sep 05 15:10:28 2011 +0100 > +++ b/xen/arch/x86/irq.c Wed Sep 07 16:00:55 2011 +0100 > @@ -338,7 +338,7 @@ int __init init_irq_data(void) > set_bit(HYPERCALL_VECTOR, used_vectors); > =20 > /* IRQ_MOVE_CLEANUP_VECTOR used for clean up vectors */ > - set_bit(IRQ_MOVE_CLEANUP_VECTOR, used_vectors); > + set_bit(MOVE_CLEANUP_VECTOR, used_vectors); > =20 > return 0; > } > diff -r 0268e7380953 -r c7884dbb6f7d xen/arch/x86/smpboot.c > --- a/xen/arch/x86/smpboot.c Mon Sep 05 15:10:28 2011 +0100 > +++ b/xen/arch/x86/smpboot.c Wed Sep 07 16:00:55 2011 +0100 > @@ -1027,7 +1027,7 @@ void __init smp_intr_init(void) > } > =20 > /* IPI for cleanuping vectors after irq move */ > - set_intr_gate(IRQ_MOVE_CLEANUP_VECTOR, irq_move_cleanup_interrupt); > + set_intr_gate(MOVE_CLEANUP_VECTOR, irq_move_cleanup_interrupt); > =20 > /* IPI for event checking. */ > set_intr_gate(EVENT_CHECK_VECTOR, event_check_interrupt); > diff -r 0268e7380953 -r c7884dbb6f7d=20 > xen/include/asm-x86/mach-default/irq_vectors.h > --- a/xen/include/asm-x86/mach-default/irq_vectors.h Mon Sep 05 = 15:10:28 2011=20 > +0100 > +++ b/xen/include/asm-x86/mach-default/irq_vectors.h Wed Sep 07 = 16:00:55 2011=20 > +0100 > @@ -11,12 +11,14 @@ > #define LOCAL_TIMER_VECTOR 0xf9 > #define PMU_APIC_VECTOR 0xf8 > #define CMCI_APIC_VECTOR 0xf7 > +#define MOVE_CLEANUP_VECTOR 0xf6 > + > /* > * High-priority dynamically-allocated vectors. For interrupts that > * must be higher priority than any guest-bound interrupt. > */ > #define FIRST_HIPRIORITY_VECTOR 0xf0 > -#define LAST_HIPRIORITY_VECTOR 0xf6 > +#define LAST_HIPRIORITY_VECTOR 0xf5 > =20 > /* Legacy PIC uses vectors 0xe0-0xef. */ > #define FIRST_LEGACY_VECTOR 0xe0 > @@ -30,8 +32,6 @@ > #define LAST_DYNAMIC_VECTOR 0xdf > #define NR_DYNAMIC_VECTORS (LAST_DYNAMIC_VECTOR - FIRST_DYNAMIC_VECTOR= + 1) > =20 > -#define IRQ_MOVE_CLEANUP_VECTOR FIRST_DYNAMIC_VECTOR > - > #define NR_VECTORS 256 > =20 > #endif /* _ASM_IRQ_VECTORS_H */ >=20 > _______________________________________________ > Xen-devel mailing list > Xen-devel@lists.xensource.com=20 > http://lists.xensource.com/xen-devel=20 _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel From xen-devel-bounces@lists.xensource.com Wed Sep 07 09:10:01 2011 Return-path: Envelope-to: www-data@lists.xensource.com Delivery-date: Wed, 07 Sep 2011 09:10:01 -0700 Received: from localhost ([127.0.0.1] helo=lists.colo.xensource.com) by lists.xensource.com with esmtp (Exim 4.43) id 1R1KhN-0007a7-6x; Wed, 07 Sep 2011 09:10:01 -0700 Received: from mail182.messagelabs.com ([85.158.139.83]) by lists.xensource.com with smtp (Exim 4.43) id 1R1Kgs-0007O0-Hc for xen-devel@lists.xensource.com; Wed, 07 Sep 2011 09:09:30 -0700 X-Env-Sender: avi@redhat.com X-Msg-Ref: server-14.tower-182.messagelabs.com!1315411766!17268665!1 X-Originating-IP: [209.132.183.28] X-StarScan-Version: 6.3.6; banners=-,-,- X-VirusChecked: Checked Received: (qmail 13189 invoked from network); 7 Sep 2011 16:09:27 -0000 Received: from mx1.redhat.com (HELO mx1.redhat.com) (209.132.183.28) by server-14.tower-182.messagelabs.com with SMTP; 7 Sep 2011 16:09:27 -0000 Received: from int-mx02.intmail.prod.int.phx2.redhat.com (int-mx02.intmail.prod.int.phx2.redhat.com [10.5.11.12]) by mx1.redhat.com (8.14.4/8.14.4) with ESMTP id p87FEYsD025915 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Wed, 7 Sep 2011 11:14:34 -0400 Received: from balrog.usersys.redhat.com (dhcp-1-24.tlv.redhat.com [10.35.1.24]) by int-mx02.intmail.prod.int.phx2.redhat.com (8.13.8/8.13.8) with ESMTP id p87FBFXt019571; Wed, 7 Sep 2011 11:11:15 -0400 Message-ID: <4E678992.5050709@redhat.com> Date: Wed, 07 Sep 2011 18:11:14 +0300 From: Avi Kivity User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:6.0) Gecko/20110816 Thunderbird/6.0 MIME-Version: 1.0 To: Don Zickus References: <38bb37e15f6e5056d5238adac945bc1837a996ec.1314922370.git.jeremy.fitzhardinge@citrix.com> <1314974826.1861.1.camel@twins> <4E612EA1.20007@goop.org> <1314996468.8255.0.camel@twins> <4E614FBD.2030509@goop.org> <20110906151408.GA7459@redhat.com> <4E66615E.8070806@goop.org> <20110906182758.GR5795@redhat.com> <4E66EF86.9070200@redhat.com> <20110907134411.GV5795@redhat.com> In-Reply-To: <20110907134411.GV5795@redhat.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Scanned-By: MIMEDefang 2.67 on 10.5.11.12 Cc: Jeremy Fitzhardinge , Marcelo Tosatti , Nick Piggin , KVM , Stefano Stabellini , Peter Zijlstra , the arch/x86 maintainers , Linux Kernel Mailing List , Andi Kleen , Jeremy Fitzhardinge , "H. Peter Anvin" , Ingo Molnar , Linus Torvalds , Xen Devel Subject: [Xen-devel] Re: [PATCH 08/13] xen/pvticketlock: disable interrupts while blocking X-BeenThere: xen-devel@lists.xensource.com X-Mailman-Version: 2.1.5 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xensource.com Errors-To: xen-devel-bounces@lists.xensource.com On 09/07/2011 04:44 PM, Don Zickus wrote: > > > > Is there a way to tell whether an NMI was internally or externally > > generated? > > > > I don't think so, especially as two or more NMIs can be coalesced. > > So any NMI received on this first cpu has to check the NMI reason > > port? > > Well we cheat and execute all the nmi handlers first. If they come back > as handled, we skip the check for the external NMI. And hope that no other NMI was generated while we're handling this one. It's a little... fragile? > But you are right, other than checking the reason port, there isn't a way > to determine if an NMI is internally or externally generated. Ouch. > > > > > >> > > >> But on the other hand, I don't really care if you can say that this path > > >> will never be called in a virtual machine. > > > > > >Does virtual machines support hot remove of cpus? Probably not > > >considering bare-metal barely supports it. > > > > > > > They do. > > But vcpus probably don't have the notion of a bsp cpu, so perhaps virtual > machines can get away with it easier? (I don't know enough about the hot > cpu remove code to really explain it, just enough to know it can cause > problems and people are trying to address it). > The concept of a bsp exists in exactly the same way as on real hardware. -- error compiling committee.c: too many arguments to function _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel From xen-devel-bounces@lists.xensource.com Wed Sep 07 09:22:53 2011 Return-path: Envelope-to: www-data@lists.xensource.com Delivery-date: Wed, 07 Sep 2011 09:22:53 -0700 Received: from localhost ([127.0.0.1] helo=lists.colo.xensource.com) by lists.xensource.com with esmtp (Exim 4.43) id 1R1Ktp-0000LN-MH; Wed, 07 Sep 2011 09:22:53 -0700 Received: from mail216.messagelabs.com ([85.158.143.99]) by lists.xensource.com with esmtp (Exim 4.43) id 1R1KsJ-0008D3-2M for xen-devel@lists.xensource.com; Wed, 07 Sep 2011 09:21:20 -0700 X-Env-Sender: komkon555@freenet.de X-Msg-Ref: server-2.tower-216.messagelabs.com!1315412474!17413540!1 X-Originating-IP: [216.139.236.26] X-StarScan-Version: 6.3.6; banners=-,-,- X-VirusChecked: Checked Received: (qmail 3487 invoked from network); 7 Sep 2011 16:21:16 -0000 Received: from sam.nabble.com (HELO sam.nabble.com) (216.139.236.26) by server-2.tower-216.messagelabs.com with AES256-SHA encrypted SMTP; 7 Sep 2011 16:21:16 -0000 Received: from [192.168.236.26] (helo=sam.nabble.com) by sam.nabble.com with esmtp (Exim 4.72) (envelope-from ) id 1R1KsE-00023X-F7 for xen-devel@lists.xensource.com; Wed, 07 Sep 2011 09:21:14 -0700 Date: Wed, 7 Sep 2011 09:21:14 -0700 (PDT) From: komkon555 To: xen-devel@lists.xensource.com Message-ID: <1315412474462-4779173.post@n5.nabble.com> In-Reply-To: <1315408931610-4778925.post@n5.nabble.com> References: <1315310225039-4774097.post@n5.nabble.com> <1315343879.61837.YahooMailNeo@web29818.mail.ird.yahoo.com> <1315382742268-4777689.post@n5.nabble.com> <1315389138.56652.YahooMailNeo@web29801.mail.ird.yahoo.com> <1315398360680-4778339.post@n5.nabble.com> <1315401901083-4778494.post@n5.nabble.com> <1315403644525-4778586.post@n5.nabble.com> <1315405372.87224.YahooMailNeo@web29801.mail.ird.yahoo.com> <1315405921936-4778727.post@n5.nabble.com> <1315408931610-4778925.post@n5.nabble.com> Subject: Re: Re : Re : Re : [Xen-devel] Re: Patches for VGA-Passthrough XEN 4.2 unstable MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-BeenThere: xen-devel@lists.xensource.com X-Mailman-Version: 2.1.5 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xensource.com Errors-To: xen-devel-bounces@lists.xensource.com I tested your patches without any fix on DSD. So, I'll try to test it with fixes this week. Kom -- View this message in context: http://xen.1045712.n5.nabble.com/Patches-for-VGA-Passthrough-XEN-4-2-unstable-tp4406265p4779173.html Sent from the Xen - Dev mailing list archive at Nabble.com. _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel From xen-devel-bounces@lists.xensource.com Wed Sep 07 09:23:53 2011 Return-path: Envelope-to: www-data@lists.xensource.com Delivery-date: Wed, 07 Sep 2011 09:23:53 -0700 Received: from localhost ([127.0.0.1] helo=lists.colo.xensource.com) by lists.xensource.com with esmtp (Exim 4.43) id 1R1Kum-0000iw-Qm; Wed, 07 Sep 2011 09:23:52 -0700 Received: from mail216.messagelabs.com ([85.158.143.99]) by lists.xensource.com with esmtp (Exim 4.43) id 1R1Ksn-0008Pb-PF for xen-devel@lists.xensource.com; Wed, 07 Sep 2011 09:21:50 -0700 X-Env-Sender: Ian.Campbell@eu.citrix.com X-Msg-Ref: server-4.tower-216.messagelabs.com!1315412505!17407018!1 X-Originating-IP: [66.165.176.63] X-StarScan-Version: 6.3.6; banners=-,-,- X-VirusChecked: Checked Received: (qmail 13356 invoked from network); 7 Sep 2011 16:21:46 -0000 Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63) by server-4.tower-216.messagelabs.com with RC4-SHA encrypted SMTP; 7 Sep 2011 16:21:46 -0000 X-IronPort-AV: E=Sophos;i="4.68,346,1312171200"; d="scan'208";a="162026337" Received: from ftlpmailmx02.citrite.net ([10.13.107.66]) by FTLPIPO02.CITRIX.COM with ESMTP/TLS/RC4-MD5; 07 Sep 2011 12:21:45 -0400 Received: from [127.0.0.1] (10.80.16.67) by smtprelay.citrix.com (10.13.107.66) with Microsoft SMTP Server id 8.3.137.0; Wed, 7 Sep 2011 12:21:44 -0400 Subject: Re: [Xen-devel] [PATCH 1/2] Introduce support for upstream qemu in the xen-unstable build system From: Ian Campbell To: "stefano.stabellini@eu.citrix.com" Date: Wed, 7 Sep 2011 09:21:42 -0700 In-Reply-To: <1315406398-8987-1-git-send-email-stefano.stabellini@eu.citrix.com> References: <1315406398-8987-1-git-send-email-stefano.stabellini@eu.citrix.com> Organization: Citrix Systems, Inc. Content-Type: text/plain; charset="UTF-8" X-Mailer: Evolution 3.0.3- Content-Transfer-Encoding: 7bit Message-ID: <1315412504.3180.20.camel@cthulhu.hellion.org.uk> MIME-Version: 1.0 Cc: "xen-devel@lists.xensource.com" , "keir@xen.org" X-BeenThere: xen-devel@lists.xensource.com X-Mailman-Version: 2.1.5 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xensource.com Errors-To: xen-devel-bounces@lists.xensource.com On Wed, 2011-09-07 at 10:39 -0400, stefano.stabellini@eu.citrix.com wrote: > In order to distinguish between upstream qemu and qemu-xen I am > introducing a new variable named "QEMU" that only if is equal to > "upstream" switches the build system to the new qemu. Thanks Stefano, this integrated support is overdue. Ultimately though I expect we will need a "both" mode since people will want old qemu for compatibility with their existing installed guests and new qemu for new ones. The allegation (and I don't really know how true it is or if it is pessimism or realism) is that some OSes don't cope with having the platform components etc changed under them. > Users that want to try the new qemu just have to export QEMU=upstream > before calling make in the xen-unstable top level directory. In xl/libxl we call them "qemu-xen-traditional" and "qemu-xen". Perhaps we should mirror that nomenclature here? > Signed-off-by: Stefano Stabellini > > diff -r 0ba816e077e6 Config.mk > --- a/Config.mk Wed Aug 31 16:04:37 2011 +0000 > +++ b/Config.mk Wed Sep 07 11:13:17 2011 +0000 > @@ -192,12 +192,21 @@ else > QEMU_REMOTE=git://xenbits.xensource.com/qemu-xen-unstable.git > endif > > +# Only available through the git protocol at the moment > +QEMU_UPSTREAM_URL=git://xenbits.xen.org/people/sstabellini/qemu-dm.git > +QEMU_UPSTREAM_TAG=origin/xen-stable-0.15 > + > # Specify which qemu-dm to use. This may be `ioemu' to use the old > # Mercurial in-tree version, or a local directory, or a git URL. > # CONFIG_QEMU ?= `pwd`/$(XEN_ROOT)/../qemu-xen.git > +ifeq ($(QEMU),upstream) > +CONFIG_QEMU ?= $(QEMU_UPSTREAM_URL) > +QEMU_TAG ?= $(QEMU_UPSTREAM_TAG) > +else > CONFIG_QEMU ?= $(QEMU_REMOTE) > +QEMU_TAG ?= cd776ee9408ff127f934a707c1a339ee600bc127 > +endif > > -QEMU_TAG ?= cd776ee9408ff127f934a707c1a339ee600bc127 > # Tue Jun 28 13:50:53 2011 +0100 > # qemu-char.c: fix incorrect CONFIG_STUBDOM handling > > diff -r 0ba816e077e6 tools/Makefile > --- a/tools/Makefile Wed Aug 31 16:04:37 2011 +0000 > +++ b/tools/Makefile Wed Sep 07 11:13:17 2011 +0000 > @@ -106,7 +106,19 @@ ioemu-dir-find: > set -e; \ > $(buildmakevars2shellvars); \ > cd ioemu-dir; \ > - $(QEMU_ROOT)/xen-setup $(IOEMU_CONFIGURE_CROSS) > + if [ "$(QEMU)" = upstream ]; then \ > + cd $(QEMU_ROOT); \ > + ./configure --enable-xen --target-list=i386-softmmu \ > + --extra-cflags="-I$(XEN_ROOT)/tools/include \ > + -I$(XEN_ROOT)/tools/libxc \ > + -I$(XEN_ROOT)/tools/xenstore" \ > + --extra-ldflags="-L$(XEN_ROOT)/tools/libxc \ > + -L$(XEN_ROOT)/tools/libxenstore" \ > + --disable-kvm \ > + $(IOEMU_CONFIGURE_CROSS); \ > + else \ > + $(QEMU_ROOT)/xen-setup $(IOEMU_CONFIGURE_CROSS); \ > + fi > > .PHONY: ioemu-dir-force-update > ioemu-dir-force-update: > > _______________________________________________ > Xen-devel mailing list > Xen-devel@lists.xensource.com > http://lists.xensource.com/xen-devel _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel From xen-devel-bounces@lists.xensource.com Wed Sep 07 09:26:14 2011 Return-path: Envelope-to: www-data@lists.xensource.com Delivery-date: Wed, 07 Sep 2011 09:26:14 -0700 Received: from localhost ([127.0.0.1] helo=lists.colo.xensource.com) by lists.xensource.com with esmtp (Exim 4.43) id 1R1Kx4-0001Cq-HP; Wed, 07 Sep 2011 09:26:14 -0700 Received: from mail182.messagelabs.com ([85.158.139.83]) by lists.xensource.com with smtp (Exim 4.43) id 1R1KwW-00010D-3w for xen-devel@lists.xensource.com; Wed, 07 Sep 2011 09:25:41 -0700 X-Env-Sender: davidtecher@yahoo.fr X-Msg-Ref: server-5.tower-182.messagelabs.com!1315412736!12449829!1 X-Originating-IP: [77.238.189.70] X-StarScan-Version: 6.3.6; banners=-,-,- X-VirusChecked: Checked Received: (qmail 17014 invoked from network); 7 Sep 2011 16:25:36 -0000 Received: from nm17.bullet.mail.ird.yahoo.com (HELO nm17.bullet.mail.ird.yahoo.com) (77.238.189.70) by server-5.tower-182.messagelabs.com with SMTP; 7 Sep 2011 16:25:36 -0000 Received: from [77.238.189.233] by nm17.bullet.mail.ird.yahoo.com with NNFMP; 07 Sep 2011 16:25:36 -0000 Received: from [212.82.108.246] by tm14.bullet.mail.ird.yahoo.com with NNFMP; 07 Sep 2011 16:25:36 -0000 Received: from [127.0.0.1] by omp1011.mail.ird.yahoo.com with NNFMP; 07 Sep 2011 16:25:36 -0000 X-Yahoo-Newman-Property: ymail-3 X-Yahoo-Newman-Id: 329806.95778.bm@omp1011.mail.ird.yahoo.com Received: (qmail 6454 invoked by uid 60001); 7 Sep 2011 16:25:36 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.fr; s=s1024; t=1315412736; bh=qJXeoB4Db/F3v5gB71ZooR0vJ3/QDpDqu/RRb3ANNbg=; h=X-YMail-OSG:Received:X-Mailer:References:Message-ID:Date:From:Reply-To:Subject:To:In-Reply-To:MIME-Version:Content-Type; b=afY0fJsRdEaW5pfpEkl/BWtDAWJgQBdlo9faYqSyirmEZnH9nJp5YlzMRXkFRtarYRDKiuCVs6u9Y0ktRwSl/TPz9VBQDBvcGJaJE5bvNMaNMycaE2VtK2NE7KZ4KWTl1swOQutIcCwebDM8e5+L7uZrymkhehs/7xOqdBHazrE= DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.fr; h=X-YMail-OSG:Received:X-Mailer:References:Message-ID:Date:From:Reply-To:Subject:To:In-Reply-To:MIME-Version:Content-Type; b=YZKqTwA6mgcAZnhxAzQpNt8PViuDl7noTY6PZM+fmEsi+sYYLqiTGGbhoGZXxCnMc4fiGeeckNoIIBOJ1D9aL/RXomETqLIC/6wC8UWhJHC9mVkCIxG0rMUBuwcQ7N/W5due2aBXhnKv+/zZ7Beyk65Itgkp5q7OopXjRlsLal8=; X-YMail-OSG: QCALDxsVM1kXBe1He48Y1aAyy6D8dy.Qm89Cu.J.mDxCweE K.fFG7DzsbbiaJTxoC_NgRS1s0iWYOjvECVqVJXi8zWZ3XBbpCqTujrRzU1a p4wwvJGtBRV4kCf0DFvqzZrcky0_Mou.3VUWA0Lg8xPxo6EYPdZcEq5hDOMl oHvVPWMZZ7a7jdstE5CFvWA2FJ8hWAMJ3VgwnWuCBfdSRmBOnGxSO6aTSQgq RXAXjspSc7W_NSejXeMQ4zPSo3Pi65yopLxDUddTWsQSTf8ya3fzP_JTvT_H z8vnc3AY4F.G50t63G4zSsgmVtdZtb_0s5G4NqY0Wc8otF3m58YXCTZxn4wp anxDQwq4NrFM6peJVNkxifVRvua34cLHb4O8Kz.NQYlxfQ1PUDl_hi4QUbub xKbWbIkUy6WvzQzU23zeo0sxmoHsczvP3AC6WeoSCHZn4RQsewsCQTN7JNBM _41gmuAY6BJM9g73JuXKJdgR9R2uW.zHzxaV4ToGCdtol2.eRdcqI1yVjQUW WtXT_KuQhXyJq_7iYWR5lDDnv1vY.zAMFD4Y1mGJQx8Nx3aXaOybw2eW36r6 hREntmYMfGxcq6vE1BA.tseNQElCQTqbTsBX388XYC0pPM8rCb5XWcX1O7KA 86gC.4axjSvNfunVl5BLdncbaBG5dcxWBYGUt6m0tpezfGTnFAgl7Cy71Eni rYzxLe6U0OMhoU5Qj1ALH2Zc4MeEEA0o- Received: from [195.167.237.98] by web29815.mail.ird.yahoo.com via HTTP; Wed, 07 Sep 2011 17:25:36 BST X-Mailer: YahooMailWebService/0.8.113.315625 References: <1315231341254-4770602.post@n5.nabble.com> <1315310225039-4774097.post@n5.nabble.com> <1315343879.61837.YahooMailNeo@web29818.mail.ird.yahoo.com> <1315382742268-4777689.post@n5.nabble.com> <1315389138.56652.YahooMailNeo@web29801.mail.ird.yahoo.com> <1315398360680-4778339.post@n5.nabble.com> <1315401901083-4778494.post@n5.nabble.com> <1315403644525-4778586.post@n5.nabble.com> <1315405372.87224.YahooMailNeo@web29801.mail.ird.yahoo.com> <1315405921936-4778727.post@n5.nabble.com> <1315408931610-4778925.post@n5.nabble.com> Message-ID: <1315412736.5486.YahooMailNeo@web29815.mail.ird.yahoo.com> Date: Wed, 7 Sep 2011 17:25:36 +0100 (BST) From: David TECHER Subject: Re : Re : Re : Re : [Xen-devel] Re: Patches for VGA-Passthrough XEN 4.2 unstable To: JavMV , "xen-devel@lists.xensource.com" In-Reply-To: <1315408931610-4778925.post@n5.nabble.com> MIME-Version: 1.0 Cc: X-BeenThere: xen-devel@lists.xensource.com X-Mailman-Version: 2.1.5 Precedence: list Reply-To: David TECHER List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0396712591==" Sender: xen-devel-bounces@lists.xensource.com Errors-To: xen-devel-bounces@lists.xensource.com --===============0396712591== Content-Type: multipart/alternative; boundary="0-1810994652-1315412736=:5486" --0-1810994652-1315412736=:5486 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable Javier=0A=0ASince you can test before the end of the month, please be infor= med to find the "all" patches here=0A=0AHope this helps.=0A=0ADavid=0A=0A= =0A------------------------------------------------------------=0A=0A--- to= ols/firmware/hvmloader/acpi/dsdt.asl=A0=A0=A0=A0=A0 2011-08-13 18:43:39.000= 000000 +0200=0A+++ tools/firmware/hvmloader/acpi/dsdt.asl=A0=A0=A0=A0=A0 20= 11-08-13 18:58:25.000000000 +0200=0A@@ -173,15 +173,43 @@ DefinitionBlock (= "DSDT.aml", "DSDT", 2,=0A=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0= =A0=A0=A0=A0=A0=A0=A0=A0 0x00000000,=0A=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0= =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 0x00020000)=0A=0A+=A0=A0=A0=A0=A0=A0= =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 /* reserve MMIO BARs of gfx for 1:1= mapping */=0A=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 = DWordMemory(=0A=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0= =A0=A0=A0=A0 ResourceProducer, PosDecode, MinFixed, MaxFixed,=0A=A0=A0=A0= =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 Cacheable, = ReadWrite,=0A=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0= =A0=A0=A0=A0 0x00000000,=0A-=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0= =A0=A0=A0=A0=A0=A0=A0=A0 0xF0000000,=0A-=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0= =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 0xF4FFFFFF,=0A+=A0=A0=A0=A0=A0=A0=A0= =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 0xFA000000,=0A+=A0=A0=A0= =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 0xFAFFFFFF,=0A= =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 0x= 00000000,=0A-=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0= =A0=A0=A0 0x05000000,=0A-=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0= =A0=A0=A0=A0=A0=A0=A0 ,, _Y01)=0A+=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0= =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 0x01000000)=0A+=0A+=A0=A0=A0=A0=A0=A0=A0=A0= =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 DWordMemory(=0A+=A0=A0=A0=A0=A0=A0=A0=A0= =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 ResourceProducer, PosDecode, = MinFixed, MaxFixed,=0A+=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0= =A0=A0=A0=A0=A0=A0 NonCacheable, ReadWrite,=0A+=A0=A0=A0=A0=A0=A0=A0=A0=A0= =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 0x00000000,=0A+=A0=A0=A0=A0=A0= =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 0xC0000000,=0A+=A0= =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 0xCFFFFF= FF,=0A+=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0= =A0 0x00000000,=0A+=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0= =A0=A0=A0=A0=A0 0x10000000)=0A+=0A+=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0= =A0=A0=A0=A0=A0=A0 DWordMemory(=0A+=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0= =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 ResourceProducer, PosDecode, MinFixed, MaxFi= xed,=0A+=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0= =A0 Cacheable, ReadWrite,=0A+=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0= =A0=A0=A0=A0=A0=A0=A0=A0 0x00000000,=0A+=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0= =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 0xD0000000,=0A+=A0=A0=A0=A0=A0=A0=A0= =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 0xD1FFFFFF,=0A+=A0=A0=A0= =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 0x00000000,=0A= +=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 0x02= 000000)=0A+=0A+=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 DW= ordMemory(=0A+=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0= =A0=A0=A0 ResourceProducer, PosDecode, MinFixed, MaxFixed,=0A+=A0=A0=A0=A0= =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 Cacheable, ReadWr= ite,=0A+=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0= =A0 0x00000000,=0A+=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0= =A0=A0=A0=A0=A0 0xFB000000,=0A+=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0= =A0=A0=A0=A0=A0=A0=A0=A0=A0 0xFB07FFFF,=0A+=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0= =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 0x00000000,=0A+=A0=A0=A0=A0=A0=A0= =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 0x00080000,=0A+=A0=A0= =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 ,, _Y01)=0A=A0= =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 })=0A=0A=A0=A0=A0=A0=A0=A0=A0= =A0=A0=A0=A0=A0=A0=A0=A0=A0 CreateDWordField(PRT0, \_SB.PCI0._CRS._Y01._MIN= , MMIN)=0A--- tools/firmware/hvmloader/hvmloader.c=A0=A0=A0=A0=A0=A0=A0 201= 1-08-13 18:43:39.000000000 +0200=0A+++ tools/firmware/hvmloader/hvmloader.c= =A0=A0=A0=A0=A0=A0=A0 2011-08-13 19:16:21.000000000 +0200=0A@@ -31,6 +31,7 = @@=0A=A0#include =0A=0A=A0#define ROM_INCLUDE_VGABIOS=0A+= #define ROM_INCLUDE_PTVGABIOS=0A=A0#define ROM_INCLUDE_ETHERBOOT=0A=A0#incl= ude "roms.inc"=0A=0A@@ -113,6 +114,9 @@ asm (=0A=0A=A0unsigned long scratch= _start =3D SCRATCH_PHYSICAL_ADDRESS;=0A=0A+/* virtual BDF of pass-throughed= gfx */=0A+uint8_t gfx_bdf;=0A+=0A=A0static void init_hypercalls(void)=0A= =A0{=0A=A0=A0=A0=A0 uint32_t eax, ebx, ecx, edx;=0A@@ -310,6 +314,20 @@ sta= tic int pci_load_option_roms(unsigned=0A=A0=A0=A0=A0 return rom_phys_addr -= rom_base_addr;=0A=A0}=0A=0A+static void init_vm86_tss(void)=0A+{=0A+=A0=A0= =A0 void *tss;=0A+=A0=A0=A0 struct xen_hvm_param p;=0A+=0A+=A0=A0=A0 tss = =3D mem_alloc(128, 128);=0A+=A0=A0=A0 memset(tss, 0, 128);=0A+=A0=A0=A0 p.d= omid =3D DOMID_SELF;=0A+=A0=A0=A0 p.index =3D HVM_PARAM_VM86_TSS;=0A+=A0=A0= =A0 p.value =3D virt_to_phys(tss);=0A+=A0=A0=A0 hypercall_hvm_op(HVMOP_set_= param, &p);=0A+=A0=A0=A0 printf("vm86 TSS at %08lx\n", virt_to_phys(tss));= =0A+}=0A+=0A=A0/* Replace possibly erroneous memory-size CMOS fields with c= orrect values. */=0A=A0static void cmos_write_memory_size(void)=0A=A0{=0A@@= -336,25 +354,6 @@ static void cmos_write_memory_size(void)=0A=A0=A0=A0=A0 = cmos_outb(0x35, (uint8_t)( alt_mem >> 8));=0A=A0}=0A=0A-/*=0A- * Set up an = empty TSS area for virtual 8086 mode to use.=0A- * The only important thing= is that it musn't have any bits set=0A- * in the interrupt redirection bit= map, so all zeros will do.=0A- */=0A-static void init_vm86_tss(void)=0A-{= =0A-=A0=A0=A0 void *tss;=0A-=A0=A0=A0 struct xen_hvm_param p;=0A-=0A-=A0=A0= =A0 tss =3D mem_alloc(128, 128);=0A-=A0=A0=A0 memset(tss, 0, 128);=0A-=A0= =A0=A0 p.domid =3D DOMID_SELF;=0A-=A0=A0=A0 p.index =3D HVM_PARAM_VM86_TSS;= =0A-=A0=A0=A0 p.value =3D virt_to_phys(tss);=0A-=A0=A0=A0 hypercall_hvm_op(= HVMOP_set_param, &p);=0A-=A0=A0=A0 printf("vm86 TSS at %08lx\n", virt_to_ph= ys(tss));=0A-}=0A-=0A=A0static void apic_setup(void)=0A=A0{=0A=A0=A0=A0=A0 = /* Set the IOAPIC ID to the static value used in the MP/ACPI tables. */=0A@= @ -487,8 +486,10 @@ int main(void)=0A=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 b= reak;=0A=A0=A0=A0=A0=A0=A0=A0=A0 case VGA_pt:=0A=A0=A0=A0=A0=A0=A0=A0=A0=A0= =A0=A0=A0 printf("Loading VGABIOS of passthroughed gfx ...\n");=0A-=A0=A0= =A0=A0=A0=A0=A0=A0=A0=A0=A0 vgabios_sz =3D round_option_rom(=0A-=A0=A0=A0= =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 (*(uint8_t *)(VGABIOS_PHYSICAL_ADDRESS= +2)) * 512);=0A+=A0=A0=A0=A0=A0=A0=A0 memcpy((void *)VGABIOS_PHYSICAL_ADDRE= SS,=0A+=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 vgabios_pt, sizeof(vgabio= s_pt));=0A+=A0=A0=A0=A0=A0=A0=A0 *(uint8_t *)(VGABIOS_PHYSICAL_ADDRESS + si= zeof(vgabios_pt)) =3D gfx_bdf;=0A+=A0=A0=A0=A0=A0=A0=A0 vgabios_sz =3D roun= d_option_rom(sizeof(vgabios_pt) + 1);=0A=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0= =A0 break;=0A=A0=A0=A0=A0=A0=A0=A0=A0 default:=0A=A0=A0=A0=A0=A0=A0=A0=A0= =A0=A0=A0=A0 printf("No emulated VGA adaptor ...\n");=0A@@ -525,7 +526,7 @@= int main(void)=0A=A0=A0=A0=A0=A0=A0=A0=A0 hypercall_hvm_op(HVMOP_set_param= , &p);=0A=A0=A0=A0=A0 }=0A=0A-=A0=A0=A0 init_vm86_tss();=0A+=A0=A0 init_vm8= 6_tss();=0A=0A=A0=A0=A0=A0 cmos_write_memory_size();=0A=0A--- tools/firmwar= e/hvmloader/Makefile=A0=A0 2011-08-13 18:43:39.000000000 +0200=0A+++ tools/= firmware/hvmloader/Makefile=A0=A0 2011-08-13 18:58:36.000000000 +0200=0A@@ = -56,6 +56,7 @@ CIRRUSVGA_ROM :=3D ../vgabios/VGABIOS-lgpl=0A=A0else=0A=A0CI= RRUSVGA_ROM :=3D ../vgabios/VGABIOS-lgpl-latest.cirrus.bin=0A=A0endif=0A+PT= VGA_ROM=A0=A0=A0=A0 :=3D ../vgabios/vgabios-pt.bin=0A=0A=A0.PHONY: all=0A= =A0all: subdirs-all=0A@@ -94,6 +95,11 @@ ifneq ($(CIRRUSVGA_ROM),)=0A=A0=A0= =A0=A0=A0=A0=A0 sh ./mkhex vgabios_cirrusvga $(CIRRUSVGA_ROM) >> $@.new=0A= =A0=A0=A0=A0=A0=A0=A0 echo "#endif" >> $@.new=0A=A0endif=0A+ifneq ($(PTVGA_= ROM),)=0A+=A0=A0=A0=A0=A0=A0 echo "#ifdef ROM_INCLUDE_PTVGABIOS" >> $@.new= =0A+=A0=A0=A0=A0=A0=A0 sh ./mkhex vgabios_pt $(PTVGA_ROM) >> $@.new=0A+=A0= =A0=A0=A0=A0=A0 echo "#endif" >> $@.new=0A+endif=0A=0A=A0=A0=A0=A0=A0=A0=A0= echo "#ifdef ROM_INCLUDE_ETHERBOOT" >> $@.new=0A=A0=A0=A0=A0=A0=A0=A0 cat = ../etherboot/eb-roms.h >> $@.new=0A--- tools/ioemu-remote/hw/pass-through.c= =A0=A0=A0=A0=A0=A0=A0 2011-08-13 23:15:13.000000000 +0200=0A+++ tools/ioemu= -remote/hw/pass-through.c=A0=A0=A0=A0=A0=A0=A0 2011-08-13 18:58:41.00000000= 0 +0200=0A@@ -3243,6 +3243,8 @@ static int pt_cmd_reg_read(struct pt_dev=0A= =A0}=0A=0A=A0/* read BAR */=0A+static int gfx_first_read_BAR[7] =3D {1, 1, = 1, 1, 1, 1, 1};=0A+=0A=A0static int pt_bar_reg_read(struct pt_dev *ptdev,= =0A=A0=A0=A0=A0=A0=A0=A0=A0 struct pt_reg_tbl *cfg_entry,=0A=A0=A0=A0=A0=A0= =A0=A0=A0 uint32_t *value, uint32_t valid_mask)=0A@@ -3265,6 +3267,17 @@ st= atic int pt_bar_reg_read(struct pt_dev=0A=A0=A0=A0=A0 /* use fixed-up value= from kernel sysfs */=0A=A0=A0=A0=A0 *value =3D ptdev->pci_dev->base_addr[i= ndex];=0A=0A+=A0=A0=A0 if ( ptdev->pci_dev->device_class =3D=3D 0x300 )=0A+= =A0=A0=A0 {=0A+=A0=A0=A0=A0=A0=A0=A0 if ( gfx_first_read_BAR[index] =3D=3D = 1 )=0A+=A0=A0=A0=A0=A0=A0=A0 {=0A+=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 gfx_fir= st_read_BAR[index] =3D 0;=0A+=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 PT_LOG("firs= t read BARs of gfx\n");=0A+=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 return 0;=0A+= =A0=A0=A0=A0=A0=A0=A0 }=0A+=A0=A0=A0 }=0A+=0A+=0A=A0=A0=A0=A0 /* set emulat= e mask depend on BAR flag */=0A=A0=A0=A0=A0 switch (ptdev->bases[index].bar= _flag)=0A=A0=A0=A0=A0 {=0A--- tools/firmware/hvmloader/pci.c=A0=A0=A0=A0=A0= 2011-08-13 18:43:39.000000000 +0200=0A+++ tools/firmware/hvmloader/pci.c= =A0=A0=A0=A0=A0 2011-08-13 18:58:53.000000000 +0200=0A@@ -33,6 +33,10 @@ un= signed long pci_mem_end =3D PCI_MEM_END;=0A=0A=A0enum virtual_vga virtual_v= ga =3D VGA_none;=0A=0A+/* virtual BDF of pass-throughed gfx declared in hvm= loader.c*/=0A+extern uint8_t gfx_bdf;=0A+=0A+=0A=A0void pci_setup(void)=0A= =A0{=0A=A0=A0=A0=A0 uint32_t base, devfn, bar_reg, bar_data, bar_sz, cmd, m= mio_total =3D 0;=0A@@ -93,9 +97,44 @@ void pci_setup(void)=0A=A0=A0=A0=A0= =A0=A0=A0=A0=A0=A0=A0=A0 }=0A=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 else if (= virtual_vga =3D=3D VGA_none )=0A=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 {=0A-= =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 vga_devfn =3D devfn;=0A-=A0= =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 virtual_vga =3D VGA_pt;=0A+=A0= =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 virtual_vga =3D VGA_pt;=0A+= =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 gfx_bdf =3D devfn;=0A+=0A+= =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 /* Make vBAR=3DpBAR */=0A+= =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 printf("Make vBAR =3D pBAR= of assigned gfx\n");=0A+=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 f= or ( bar =3D 0; bar < 7; bar++ )=0A+=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0= =A0=A0=A0 {=0A+=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0= bar_reg =3D PCI_BASE_ADDRESS_0 + 4*bar;=0A+=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0= =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 if ( bar =3D=3D 6 )=0A+=A0=A0=A0=A0=A0=A0=A0= =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 bar_reg =3D= PCI_ROM_ADDRESS;=0A+=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0= =A0=A0 /* When first time read, it will return physical address */=0A+=A0= =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 bar_data =3D pci_= readl(devfn, bar_reg);=0A+=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0= =A0=A0=A0=A0 pci_writel(devfn, bar_reg, bar_data);=0A+=0A+=A0=A0=A0=A0=A0= =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 /* Now enable the memory or I= /O mapping. */=0A+=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0= =A0 cmd =3D pci_readw(devfn, PCI_COMMAND);=0A+=A0=A0=A0=A0=A0=A0=A0=A0=A0= =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 if ( (bar_reg =3D=3D PCI_ROM_ADDRESS) ||= =0A+=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0= =A0=A0=A0=A0=A0=A0 ((bar_data & PCI_BASE_ADDRESS_SPACE) =3D=3D=0A+=A0=A0=A0= =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0= =A0=A0 PCI_BASE_ADDRESS_SPACE_MEMORY) )=0A+=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0= =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 cmd |=3D PCI_COMMAND_MEMOR= Y;=0A+=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 else=0A+= =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0= =A0 cmd |=3D PCI_COMMAND_IO;=0A+=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0= =A0=A0=A0=A0=A0=A0 cmd |=3D PCI_COMMAND_MASTER;=0A+=A0=A0=A0=A0=A0=A0=A0=A0= =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 pci_writew(devfn, PCI_COMMAND, cmd);= =0A+=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 }=0A+=0A+=A0=A0=A0=A0=A0= =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 /* Map the interrupt. */=0A+=A0=A0=A0=A0= =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 pin =3D pci_readb(devfn, PCI_INTERRUPT= _PIN);=0A+=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 if ( pin !=3D 0 = )=0A+=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 {=0A+=A0=A0=A0=A0=A0= =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 /* This is the barber's pole = mapping used by Xen. */=0A+=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0= =A0=A0=A0=A0 link =3D ((pin - 1) + (devfn >> 3)) & 3;=0A+=A0=A0=A0=A0=A0=A0= =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 isa_irq =3D pci_readb(PCI_ISA_DE= VFN, 0x60 + link);=0A+=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0= =A0=A0=A0 pci_writeb(devfn, PCI_INTERRUPT_LINE, isa_irq);=0A+=A0=A0=A0=A0= =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 }=0A+=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0= =A0=A0=A0=A0=A0 continue;=0A=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 }=0A+=0A= =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 break;=0A=A0=A0=A0=A0=A0=A0=A0=A0 case= 0x0680:=0A=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 /* PIIX4 ACPI PM. Special d= evice with special PCI config space. */=0A---------------------------------= ----------------------------------------------=0A=0A=0A=0A_________________= _______________=0ADe=A0: JavMV =0A=C0=A0: xen-de= vel@lists.xensource.com=0AEnvoy=E9 le : Mercredi 7 Septembre 2011 17h22=0AO= bjet=A0: Re: Re : Re : Re : [Xen-devel] Re: Patches for VGA-Passthrough XEN= 4.2 unstable=0A=0AI suppose you have modified the dsdt.asl file right? If = you did it and it=0Acrashed (If you didn't try it with this let me know bec= ause I have to=0Adocument the process of adapt the Tobias patches (Actually= Han,Weidong=0Apatches)) then there is something that Xen devels have added= between those=0Achangeset to the code that make the David's adaptation wor= ks (because David=0Asays he didn't add code to the patches). =0A=0AI was wo= rking on a specific computer with XEN at university and I can't try=0Athis = patchset now, that is why I have to wait to end of month.. Im=0Aimpatient!!= =0A=0AWell thanks for the answers.=0A=0AJavier Manzano.=0A=0A-----=0AJavMV= =0A--=0AView this message in context: http://xen.1045712.n5.nabble.com/Patc= hes-for-VGA-Passthrough-XEN-4-2-unstable-tp4406265p4778925.html=0ASent from= the Xen - Dev mailing list archive at Nabble.com.=0A=0A___________________= ____________________________=0AXen-devel mailing list=0AXen-devel@lists.xen= source.com=0Ahttp://lists.xensource.com/xen-devel --0-1810994652-1315412736=:5486 Content-Type: text/html; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable
Javier

Since you can test before t= he end of the month, please be informed to find the "all" patches here

Hope this helps.

David

-------------------------------------------------= -----------

--- tools/firmware/hvmloader/acpi/ds= dt.asl      2011-08-13 18:43:39.000000000 +0200+++ tools/firmware/hvmloader/acpi/dsdt.asl      2= 011-08-13 18:58:25.000000000 +0200
@@ -173,15 +173,43 @@ DefinitionBlock= ("DSDT.aml", "DSDT", 2,
           &n= bsp;            = ; 0x00000000,
         &nbs= p;            &= nbsp;  0x00020000)

+       &= nbsp;            /* = reserve MMIO BARs of gfx for 1:1 mapping */
    &nbs= p;            &= nbsp;   DWordMemory(
       = ;            &n= bsp;     ResourceProducer, PosDecode, MinFixed, MaxFixed,
          &= nbsp;           &nbs= p;  Cacheable, ReadWrite,
       = ;            &n= bsp;     0x00000000,
-     =             &nb= sp;      0xF0000000,
-    &= nbsp;           &nbs= p;       0xF4FFFFFF,
+   &n= bsp;            = ;        0xFA000000,
+  &nb= sp;            =          0xFAFFFFFF,
          = ;            &n= bsp;  0x00000000,
-        =             &nb= sp;   0x05000000,
-       &= nbsp;           &nbs= p;    ,, _Y01)
+       = ;            &n= bsp;    0x01000000)
+
+     &= nbsp;           &nbs= p;  DWordMemory(
+        &= nbsp;           &nbs= p;   ResourceProducer, PosDecode, MinFixed, MaxFixed,
+          =             &nb= sp; NonCacheable, ReadWrite,
+       =             &nb= sp;    0x00000000,
+      &= nbsp;           &nbs= p;     0xC0000000,
+     &n= bsp;            = ;      0xCFFFFFFF,
+    &nb= sp;            =        0x00000000,
+   &nbs= p;            &= nbsp;       0x10000000)
+
+         = ;           DWordMemory(<= br>+            = ;            Resourc= eProducer, PosDecode, MinFixed, MaxFixed,
+     = ;            &n= bsp;      Cacheable, ReadWrite,
+  &n= bsp;            = ;         0x00000000,
+ &nb= sp;            =           0xD0000000,
+&nbs= p;            &= nbsp;          0xD1FFFFFF,
+         &nbs= p;            &= nbsp; 0x00000000,
+         = ;            &n= bsp;  0x02000000)
+
+       &= nbsp;            DWo= rdMemory(
+          &= nbsp;           &nbs= p; ResourceProducer, PosDecode, MinFixed, MaxFixed,
+   &= nbsp;           &nbs= p;        Cacheable, ReadWrite,
+&nbs= p;            &= nbsp;          0x00000000,
+         &nbs= p;            &= nbsp; 0xFB000000,
+         = ;            &n= bsp;  0xFB07FFFF,
+        =             &nb= sp;   0x00000000,
+       &= nbsp;           &nbs= p;    0x00080000,
+      &n= bsp;            = ;    ,, _Y01)
       &= nbsp;         })

          &nbs= p;      CreateDWordField(PRT0, \_SB.PCI0._CRS._Y01= ._MIN, MMIN)
--- tools/firmware/hvmloader/hvmloader.c   &= nbsp;    2011-08-13 18:43:39.000000000 +0200
+++ tools/fi= rmware/hvmloader/hvmloader.c        2011= -08-13 19:16:21.000000000 +0200
@@ -31,6 +31,7 @@
 #include <= xen/hvm/params.h>

 #define ROM_INCLUDE_VGABIOS
+#define R= OM_INCLUDE_PTVGABIOS
 #define ROM_INCLUDE_ETHERBOOT
 #inclu= de "roms.inc"

@@ -113,6 +114,9 @@ asm (

 unsigned long s= cratch_start =3D SCRATCH_PHYSICAL_ADDRESS;

+/* virtual BDF of pass-t= hroughed gfx */
+uint8_t gfx_bdf;
+
 static void init_hyperca= lls(void)
 {
     uint32_t eax, ebx, ecx, ed= x;
@@ -310,6 +314,20 @@ static int pci_load_option_roms(unsigned
     return rom_phys_= addr - rom_base_addr;
 }

+static void init_vm86_tss(void)+{
+    void *tss;
+    struct xen_hvm= _param p;
+
+    tss =3D mem_alloc(128, 128);
+&nbs= p;   memset(tss, 0, 128);
+    p.domid =3D DOMI= D_SELF;
+    p.index =3D HVM_PARAM_VM86_TSS;
+ &n= bsp;  p.value =3D virt_to_phys(tss);
+    hypercall_= hvm_op(HVMOP_set_param, &p);
+    printf("vm86 TSS at= %08lx\n", virt_to_phys(tss));
+}
+
 /* Replace possibly erro= neous memory-size CMOS fields with correct values. */
 static void = cmos_write_memory_size(void)
 {
@@ -336,25 +354,6 @@ static void= cmos_write_memory_size(void)
     cmos_outb(0x35, (= uint8_t)( alt_mem >> 8));
 }

-/*
- * Set up an empt= y TSS area for virtual 8086 mode to use.
- * The only important thing is = that it musn't have any bits set
- * in the interrupt redirection bitmap= , so all zeros will do.
- */
-static void init_vm86_tss(void)
-{-    void *tss;
-    struct xen_hvm_para= m p;
-
-    tss =3D mem_alloc(128, 128);
- &nb= sp;  memset(tss, 0, 128);
-    p.domid =3D DOMID_SEL= F;
-    p.index =3D HVM_PARAM_VM86_TSS;
-  &= nbsp; p.value =3D virt_to_phys(tss);
-    hypercall_hvm_o= p(HVMOP_set_param, &p);
-    printf("vm86 TSS at %08l= x\n", virt_to_phys(tss));
-}
-
 static void apic_setup(void)<= br> {
     /* Set the IOAPIC ID to the static v= alue used in the MP/ACPI tables. */
@@ -487,8 +486,10 @@ int main(void)<= br>             break;
         case VGA_pt:             p= rintf("Loading VGABIOS of passthroughed gfx ...\n");
-   =          vgabios_sz =3D round_optio= n_rom(
-          &nbs= p;     (*(uint8_t *)(VGABIOS_PHYSICAL_ADDRESS+2)) * 512= );
+        memcpy((void *)VGABIOS_PH= YSICAL_ADDRESS,
+         &= nbsp;     vgabios_pt, sizeof(vgabios_pt));
+ &n= bsp;      *(uint8_t *)(VGABIOS_PHYSICAL_ADDRESS + = sizeof(vgabios_pt)) =3D gfx_bdf;
+      &n= bsp; vgabios_sz =3D round_option_rom(sizeof(vgabios_pt) + 1);
 &nbs= p;           break;
         default:
&nb= sp;            print= f("No emulated VGA adaptor ...\n");
@@ -525,7 +526,7 @@ int main(void)         hypercall_hvm_op(HVMOP_s= et_param, &p);
     }

-   = init_vm86_tss();
+   init_vm86_tss();

  &nbs= p;  cmos_write_memory_size();

--- tools/firmware/hvmloader/Make= file   2011-08-13 18:43:39.000000000 +0200
+++ tools/firmware/= hvmloader/Makefile   2011-08-13 18:58:36.000000000 +0200
@@ -5= 6,6 +56,7 @@ CIRRUSVGA_ROM :=3D ../vgabios/VGABIOS-lgpl
 else
&n= bsp;CIRRUSVGA_ROM :=3D ../vgabios/VGABIOS-lgpl-latest.cirrus.bin
 e= ndif
+PTVGA_ROM     :=3D ../vgabios/vgabios-pt.bin
 .PHONY: all
 all: subdirs-all
@@ -94,6 +95,11 @@ ifneq ($(CIRRUSVGA_ROM),)
        sh= ./mkhex vgabios_cirrusvga $(CIRRUSVGA_ROM) >> $@.new
  =       echo "#endif" >> $@.new
 endif=
+ifneq ($(PTVGA_ROM),)
+       echo "#= ifdef ROM_INCLUDE_PTVGABIOS" >> $@.new
+    &n= bsp;  sh ./mkhex vgabios_pt $(PTVGA_ROM) >> $@.new
+ &nb= sp;     echo "#endif" >> $@.new
+endif

=         echo "#ifdef ROM_INCLUDE_ETHERBO= OT" >> $@.new
        cat ../et= herboot/eb-roms.h >> $@.new
--- tools/ioemu-remote/hw/pass-through= .c        2011-08-13 23:15:13.000000000 = +0200
+++ tools/ioemu-remote/hw/pass-through.c    &n= bsp;   2011-08-13 18:58:41.000000000 +0200
@@ -3243,6 +3243,8 @@ static int pt_cmd_reg_read(struct pt_dev
 }

&nbs= p;/* read BAR */
+static int gfx_first_read_BAR[7] =3D {1, 1, 1, 1, 1, 1= , 1};
+
 static int pt_bar_reg_read(struct pt_dev *ptdev,
&nb= sp;        struct pt_reg_tbl *cfg_entry,=
         uint32_t *value, uint3= 2_t valid_mask)
@@ -3265,6 +3267,17 @@ static int pt_bar_reg_read(struct= pt_dev
     /* use fixed-up value from kernel sysfs= */
     *value =3D ptdev->pci_dev->base_addr[= index];

+    if ( ptdev->pci_dev->device_class = =3D=3D 0x300 )
+    {
+     &= nbsp;  if ( gfx_first_read_BAR[index] =3D=3D 1 )
+   = ;     {
+       &= nbsp;    gfx_first_read_BAR[index] =3D 0;
+            = PT_LOG("first read BARs of gfx\n");
+      = ;      return 0;
+     = ;   }
+    }
+
+
   &nb= sp; /* set emulate mask depend on BAR flag */
     s= witch (ptdev->bases[index].bar_flag)
     {
--= - tools/firmware/hvmloader/pci.c      2011-08-13 1= 8:43:39.000000000 +0200
+++ tools/firmware/hvmloader/pci.c  &n= bsp;   2011-08-13 18:58:53.000000000 +0200
@@ -33,6 +33,10 @@ = unsigned long pci_mem_end =3D PCI_MEM_END;

 enum virtual_vga vi= rtual_vga =3D VGA_none;

+/* virtual BDF of pass-throughed gfx declar= ed in hvmloader.c*/
+extern uint8_t gfx_bdf;
+
+
 void pci= _setup(void)
 {
     uint32_t base, devfn, bar_reg, bar_data, bar_sz, cmd, mmio_total =3D 0;
@@ -93,9 +97,4= 4 @@ void pci_setup(void)
       &nbs= p;     }
       &= nbsp;     else if ( virtual_vga =3D=3D VGA_none )
&n= bsp;            {-            &= nbsp;   vga_devfn =3D devfn;
-     &n= bsp;          virtual_vga =3D = VGA_pt;
+          &nb= sp;      virtual_vga =3D VGA_pt;
+  &= nbsp;           &nbs= p;  gfx_bdf =3D devfn;
+
+      &n= bsp;          /* Make vBAR=3Dp= BAR */
+           &= nbsp;     printf("Make vBAR =3D pBAR of assigned gfx\n"= );
+           &n= bsp;     for ( bar =3D 0; bar < 7; bar++ )
+ = ;            &n= bsp;   {
+        &nbs= p;            bar_re= g =3D PCI_BASE_ADDRESS_0 + 4*bar;
+      &= nbsp;           &nbs= p;  if ( bar =3D=3D 6 )
+       =             &nb= sp;         bar_reg =3D PCI_ROM_ADDRESS;
+         = ;            /* When= first time read, it will return physical address */
+   =             &nb= sp;     bar_data =3D pci_readl(devfn, bar_reg);
+&nb= sp;            =         pci_writel(devfn, bar_reg, bar_d= ata);
+
+          =            /* Now enable = the memory or I/O mapping. */
+       = ;            &n= bsp; cmd =3D pci_readw(devfn, PCI_COMMAND);
+         &n= bsp;           if ( (bar_= reg =3D=3D PCI_ROM_ADDRESS) ||
+      &nbs= p;            &= nbsp;          ((bar_data &= ; PCI_BASE_ADDRESS_SPACE) =3D=3D
+      &n= bsp;            = ;            PCI_BAS= E_ADDRESS_SPACE_MEMORY) )
+       &nb= sp;            =        cmd |=3D PCI_COMMAND_MEMORY;
+ = ;            &n= bsp;       else
+           = ;            &n= bsp;   cmd |=3D PCI_COMMAND_IO;
+     = ;            &n= bsp;   cmd |=3D PCI_COMMAND_MASTER;
+    &= nbsp;           &nbs= p;    pci_writew(devfn, PCI_COMMAND, cmd);
+  &= nbsp;           &nbs= p; }
+
+          &= nbsp;      /* Map the interrupt. */
+ &nbs= p;            &= nbsp;  pin =3D pci_readb(devfn, PCI_INTERRUPT_PIN);
+        &n= bsp;        if ( pin !=3D 0 )
+ =             &nb= sp;   {
+         = ;            /* This= is the barber's pole mapping used by Xen. */
+    &= nbsp;           &nbs= p;    link =3D ((pin - 1) + (devfn >> 3)) & 3;
= +            &n= bsp;        isa_irq =3D pci_readb(PCI_IS= A_DEVFN, 0x60 + link);
+        =              pc= i_writeb(devfn, PCI_INTERRUPT_LINE, isa_irq);
+          =        }
+     &n= bsp;           continue;<= br>            = }
+
          &nbs= p;  break;
         case 0x= 0680:
           =   /* PIIX4 ACPI PM. Special device with special PCI config space. */-------------------------------------------------------------------------= ------

De : JavMV <javier.manzano@= edu.uah.es>
=C0 : xen-devel@lists.xensource.com
E= nvoy=E9 le : Mercredi 7 Septembre 2011 17h22
Objet : Re: Re : Re : Re : [Xen-dev= el] Re: Patches for VGA-Passthrough XEN 4.2 unstable

I suppos= e you have modified the dsdt.asl file right? If you did it and it
crashe= d (If you didn't try it with this let me know because I have to
document= the process of adapt the Tobias patches (Actually Han,Weidong
patches))= then there is something that Xen devels have added between those
change= set to the code that make the David's adaptation works (because David
sa= ys he didn't add code to the patches).

I was working on a specific = computer with XEN at university and I can't try
this patchset now, that = is why I have to wait to end of month.. Im
impatient!!

Well thanks = for the answers.

Javier Manzano.

-----
JavMV
--
View= this message in context: http://xen.1045712.n5.nabble.com/Patches-for-VGA-Passthrough-XEN-4-2= -unstable-tp4406265p4778925.html
Sent from the Xen - Dev mailing lis= t archive at Nabble.com.

___________________________________________= ____
Xen-devel mailing list
Xen-devel@lists.xe= nsource.com
http://lists.xensource.com/xen-devel


--0-1810994652-1315412736=:5486-- --===============0396712591== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel --===============0396712591==-- From xen-devel-bounces@lists.xensource.com Wed Sep 07 09:28:56 2011 Return-path: Envelope-to: www-data@lists.xensource.com Delivery-date: Wed, 07 Sep 2011 09:28:56 -0700 Received: from localhost ([127.0.0.1] helo=lists.colo.xensource.com) by lists.xensource.com with esmtp (Exim 4.43) id 1R1Kzg-0002LA-6G; Wed, 07 Sep 2011 09:28:56 -0700 Received: from mail21.messagelabs.com ([85.158.143.35]) by lists.xensource.com with smtp (Exim 4.43) id 1R1Kxf-0001PX-Ik for xen-devel@lists.xensource.com; Wed, 07 Sep 2011 09:26:52 -0700 X-Env-Sender: avi@redhat.com X-Msg-Ref: server-10.tower-21.messagelabs.com!1315412794!53233073!1 X-Originating-IP: [209.132.183.28] X-StarScan-Version: 6.3.6; banners=-,-,- X-VirusChecked: Checked Received: (qmail 29054 invoked from network); 7 Sep 2011 16:26:34 -0000 Received: from mx1.redhat.com (HELO mx1.redhat.com) (209.132.183.28) by server-10.tower-21.messagelabs.com with SMTP; 7 Sep 2011 16:26:34 -0000 Received: from int-mx01.intmail.prod.int.phx2.redhat.com (int-mx01.intmail.prod.int.phx2.redhat.com [10.5.11.11]) by mx1.redhat.com (8.14.4/8.14.4) with ESMTP id p87GPUsI006972 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Wed, 7 Sep 2011 12:25:30 -0400 Received: from balrog.usersys.redhat.com (dhcp-1-24.tlv.redhat.com [10.35.1.24]) by int-mx01.intmail.prod.int.phx2.redhat.com (8.13.8/8.13.8) with ESMTP id p87GPOGn020713; Wed, 7 Sep 2011 12:25:25 -0400 Message-ID: <4E679AF4.50209@redhat.com> Date: Wed, 07 Sep 2011 19:25:24 +0300 From: Avi Kivity User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:6.0) Gecko/20110816 Thunderbird/6.0 MIME-Version: 1.0 To: Don Zickus References: <1314974826.1861.1.camel@twins> <4E612EA1.20007@goop.org> <1314996468.8255.0.camel@twins> <4E614FBD.2030509@goop.org> <20110906151408.GA7459@redhat.com> <4E66615E.8070806@goop.org> <20110906182758.GR5795@redhat.com> <4E66EF86.9070200@redhat.com> <20110907134411.GV5795@redhat.com> <4E678992.5050709@redhat.com> <20110907155657.GX5795@redhat.com> In-Reply-To: <20110907155657.GX5795@redhat.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Scanned-By: MIMEDefang 2.67 on 10.5.11.11 Cc: Jeremy Fitzhardinge , Marcelo Tosatti , Nick Piggin , KVM , Stefano Stabellini , Peter Zijlstra , the arch/x86 maintainers , Linux Kernel Mailing List , Andi Kleen , Jeremy Fitzhardinge , "H. Peter Anvin" , Ingo Molnar , Linus Torvalds , Xen Devel Subject: [Xen-devel] Re: [PATCH 08/13] xen/pvticketlock: disable interrupts while blocking X-BeenThere: xen-devel@lists.xensource.com X-Mailman-Version: 2.1.5 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xensource.com Errors-To: xen-devel-bounces@lists.xensource.com On 09/07/2011 06:56 PM, Don Zickus wrote: > > > > And hope that no other NMI was generated while we're handling this > > one. It's a little... fragile? > > No. If another NMI is generated while we are processing the current one > it should get latched. Upon completion of the current one, the cpu should > jump right back into the nmi exception routine again. The only downside > is when multiple NMIs come in during the processing of the current one. > Only one can be latched, so the others get dropped. Ah, yes, I remember now. > But we are addressing > that. > May I ask how? Detecting a back-to-back NMI? -- error compiling committee.c: too many arguments to function _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel From xen-devel-bounces@lists.xensource.com Wed Sep 07 09:30:28 2011 Return-path: Envelope-to: www-data@lists.xensource.com Delivery-date: Wed, 07 Sep 2011 09:30:28 -0700 Received: from localhost ([127.0.0.1] helo=lists.colo.xensource.com) by lists.xensource.com with esmtp (Exim 4.43) id 1R1L1A-0002jB-BM; Wed, 07 Sep 2011 09:30:28 -0700 Received: from mail216.messagelabs.com ([85.158.143.99]) by lists.xensource.com with smtp (Exim 4.43) id 1R1L0m-0002Wm-Ho for xen-devel@lists.xensource.com; Wed, 07 Sep 2011 09:30:04 -0700 X-Env-Sender: Stefano.Stabellini@eu.citrix.com X-Msg-Ref: server-9.tower-216.messagelabs.com!1315413001!17434130!1 X-Originating-IP: [62.200.22.115] X-StarScan-Version: 6.3.6; banners=-,-,- X-VirusChecked: Checked Received: (qmail 31518 invoked from network); 7 Sep 2011 16:30:01 -0000 Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115) by server-9.tower-216.messagelabs.com with SMTP; 7 Sep 2011 16:30:01 -0000 X-IronPort-AV: E=Sophos;i="4.68,346,1312156800"; d="scan'208";a="7658338" Received: from lonpmailmx01.citrite.net ([10.30.203.162]) by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5; 07 Sep 2011 16:30:01 +0000 Received: from kaball.uk.xensource.com (10.80.2.59) by LONPMAILMX01.citrite.net (10.30.203.162) with Microsoft SMTP Server id 8.3.137.0; Wed, 7 Sep 2011 17:30:01 +0100 Date: Wed, 7 Sep 2011 17:38:09 +0100 From: Stefano Stabellini X-X-Sender: sstabellini@kaball-desktop To: Konrad Rzeszutek Wilk Message-ID: User-Agent: Alpine 2.00 (DEB 1167 2008-08-23) MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Cc: linux-kernel@vger.kernel.org, Jeremy Fitzhardinge , xen-devel@lists.xensource.com, Ian Campbell , Stefano Stabellini Subject: [Xen-devel] [PATCH v3 0/2] xen: modify kernel mappings corresponding to granted pages X-BeenThere: xen-devel@lists.xensource.com X-Mailman-Version: 2.1.5 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xensource.com Errors-To: xen-devel-bounces@lists.xensource.com Hi all, this is the third version of the patch "xen: modify kernel mappings corresponding to granted pages". Compared to the latest version, following Jeremy's suggestion, I dropped support for highmem pages. That made the code much simpler, therefore I folded the multicall patch in the main patch because it didn't make much sense to keep them separate anymore. I modified gntdev to use lowmem pages only, so that we are always going to be able to successfully modify the kernel mappings directly in the m2p override. In order to do that I extended the alloc_xenballooned_pages interface with an highmem parameter that allows the caller to explicitly request for highmem or lowmem pages. Shortlog and diffstat follow: Stefano Stabellini (2): xen: add an "highmem" parameter to alloc_xenballooned_pages xen: modify kernel mappings corresponding to granted pages arch/x86/include/asm/xen/page.h | 5 ++- arch/x86/xen/p2m.c | 67 ++++++++++++++++++++++++++++++++------ drivers/xen/balloon.c | 12 +++++-- drivers/xen/gntdev.c | 29 +++++++++++++++- drivers/xen/grant-table.c | 4 +- include/xen/balloon.h | 3 +- include/xen/grant_table.h | 1 + 7 files changed, 100 insertions(+), 21 deletions(-) A git branch with the two patches on top of Linux 3.1 rc4 is available here: git://xenbits.xen.org/people/sstabellini/linux-pvhvm.git 3.1-rc4-kernel_mappings_3 Cheers, Stefano _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel From xen-devel-bounces@lists.xensource.com Wed Sep 07 09:32:02 2011 Return-path: Envelope-to: www-data@lists.xensource.com Delivery-date: Wed, 07 Sep 2011 09:32:02 -0700 Received: from localhost ([127.0.0.1] helo=lists.colo.xensource.com) by lists.xensource.com with esmtp (Exim 4.43) id 1R1L2g-00038G-DK; Wed, 07 Sep 2011 09:32:02 -0700 Received: from mail182.messagelabs.com ([85.158.139.83]) by lists.xensource.com with esmtp (Exim 4.43) id 1R1L2F-0002uw-0L for xen-devel@lists.xensource.com; Wed, 07 Sep 2011 09:31:36 -0700 X-Env-Sender: Stefano.Stabellini@eu.citrix.com X-Msg-Ref: server-13.tower-182.messagelabs.com!1315413090!17273440!1 X-Originating-IP: [66.165.176.89] X-StarScan-Version: 6.3.6; banners=-,-,- X-VirusChecked: Checked Received: (qmail 3311 invoked from network); 7 Sep 2011 16:31:31 -0000 Received: from smtp.citrix.com (HELO SMTP.CITRIX.COM) (66.165.176.89) by server-13.tower-182.messagelabs.com with RC4-SHA encrypted SMTP; 7 Sep 2011 16:31:31 -0000 X-IronPort-AV: E=Sophos;i="4.68,346,1312171200"; d="scan'208";a="16768368" Received: from ftlpmailmx02.citrite.net ([10.13.107.66]) by FTLPIPO01.CITRIX.COM with ESMTP/TLS/RC4-MD5; 07 Sep 2011 12:31:30 -0400 Received: from smtp01.ad.xensource.com (10.219.128.104) by smtprelay.citrix.com (10.13.107.66) with Microsoft SMTP Server id 8.3.137.0; Wed, 7 Sep 2011 12:31:30 -0400 Received: from localhost.localdomain (kaball.uk.xensource.com [10.80.2.59]) by smtp01.ad.xensource.com (8.13.1/8.13.1) with ESMTP id p87GVFhI025888; Wed, 7 Sep 2011 09:31:16 -0700 From: To: konrad.wilk@oracle.com Date: Wed, 7 Sep 2011 17:39:30 +0100 Message-ID: <1315413571-10938-1-git-send-email-stefano.stabellini@eu.citrix.com> X-Mailer: git-send-email 1.7.0.4 In-Reply-To: References: MIME-Version: 1.0 Content-Type: text/plain Cc: jeremy@goop.org, xen-devel@lists.xensource.com, Stefano Stabellini , Stefano.Stabellini@eu.citrix.com, linux-kernel@vger.kernel.org, Ian.Campbell@eu.citrix.com Subject: [Xen-devel] [PATCH v3 1/2] xen: add an "highmem" parameter to alloc_xenballooned_pages X-BeenThere: xen-devel@lists.xensource.com X-Mailman-Version: 2.1.5 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xensource.com Errors-To: xen-devel-bounces@lists.xensource.com From: Stefano Stabellini Add an highmem parameter to alloc_xenballooned_pages, to allow callers to request lowmem or highmem pages. Signed-off-by: Stefano Stabellini --- drivers/xen/balloon.c | 12 ++++++++---- drivers/xen/gntdev.c | 2 +- include/xen/balloon.h | 3 ++- 3 files changed, 11 insertions(+), 6 deletions(-) diff --git a/drivers/xen/balloon.c b/drivers/xen/balloon.c index 5dfd8f8..7f7d463 100644 --- a/drivers/xen/balloon.c +++ b/drivers/xen/balloon.c @@ -501,20 +501,24 @@ EXPORT_SYMBOL_GPL(balloon_set_new_target); * alloc_xenballooned_pages - get pages that have been ballooned out * @nr_pages: Number of pages to get * @pages: pages returned + * @highmem: highmem or lowmem pages * @return 0 on success, error otherwise */ -int alloc_xenballooned_pages(int nr_pages, struct page** pages) +int alloc_xenballooned_pages(int nr_pages, struct page** pages, bool highmem) { int pgno = 0; struct page* page; mutex_lock(&balloon_mutex); while (pgno < nr_pages) { - page = balloon_retrieve(true); - if (page) { + page = balloon_retrieve(highmem); + if (page && PageHighMem(page) == highmem) { pages[pgno++] = page; } else { enum bp_state st; - st = decrease_reservation(nr_pages - pgno, GFP_HIGHUSER); + if (page) + balloon_append(page); + st = decrease_reservation(nr_pages - pgno, + highmem ? GFP_HIGHUSER : GFP_USER); if (st != BP_DONE) goto out_undo; } diff --git a/drivers/xen/gntdev.c b/drivers/xen/gntdev.c index f914b26..07a56c2 100644 --- a/drivers/xen/gntdev.c +++ b/drivers/xen/gntdev.c @@ -123,7 +123,7 @@ static struct grant_map *gntdev_alloc_map(struct gntdev_priv *priv, int count) NULL == add->pages) goto err; - if (alloc_xenballooned_pages(count, add->pages)) + if (alloc_xenballooned_pages(count, add->pages, 0 /* lowmem */)) goto err; for (i = 0; i < count; i++) { diff --git a/include/xen/balloon.h b/include/xen/balloon.h index 76f7538..b1a8233 100644 --- a/include/xen/balloon.h +++ b/include/xen/balloon.h @@ -25,7 +25,8 @@ extern struct balloon_stats balloon_stats; void balloon_set_new_target(unsigned long target); -int alloc_xenballooned_pages(int nr_pages, struct page** pages); +int alloc_xenballooned_pages(int nr_pages, struct page** pages, + bool highmem); void free_xenballooned_pages(int nr_pages, struct page** pages); struct sys_device; -- 1.7.2.3 _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel From xen-devel-bounces@lists.xensource.com Wed Sep 07 09:32:47 2011 Return-path: Envelope-to: www-data@lists.xensource.com Delivery-date: Wed, 07 Sep 2011 09:32:47 -0700 Received: from localhost ([127.0.0.1] helo=lists.colo.xensource.com) by lists.xensource.com with esmtp (Exim 4.43) id 1R1L3P-0003Vv-KJ; Wed, 07 Sep 2011 09:32:47 -0700 Received: from mail216.messagelabs.com ([85.158.143.99]) by lists.xensource.com with esmtp (Exim 4.43) id 1R1L2L-0002w1-RG for xen-devel@lists.xensource.com; Wed, 07 Sep 2011 09:31:42 -0700 X-Env-Sender: Stefano.Stabellini@eu.citrix.com X-Msg-Ref: server-11.tower-216.messagelabs.com!1315413097!9844407!1 X-Originating-IP: [66.165.176.63] X-StarScan-Version: 6.3.6; banners=-,-,- X-VirusChecked: Checked Received: (qmail 29740 invoked from network); 7 Sep 2011 16:31:38 -0000 Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63) by server-11.tower-216.messagelabs.com with RC4-SHA encrypted SMTP; 7 Sep 2011 16:31:38 -0000 X-IronPort-AV: E=Sophos;i="4.68,346,1312171200"; d="scan'208";a="162028092" Received: from ftlpmailmx02.citrite.net ([10.13.107.66]) by FTLPIPO02.CITRIX.COM with ESMTP/TLS/RC4-MD5; 07 Sep 2011 12:31:37 -0400 Received: from smtp01.ad.xensource.com (10.219.128.104) by smtprelay.citrix.com (10.13.107.66) with Microsoft SMTP Server id 8.3.137.0; Wed, 7 Sep 2011 12:31:36 -0400 Received: from localhost.localdomain (kaball.uk.xensource.com [10.80.2.59]) by smtp01.ad.xensource.com (8.13.1/8.13.1) with ESMTP id p87GVFhJ025888; Wed, 7 Sep 2011 09:31:25 -0700 From: To: konrad.wilk@oracle.com Date: Wed, 7 Sep 2011 17:39:31 +0100 Message-ID: <1315413571-10938-2-git-send-email-stefano.stabellini@eu.citrix.com> X-Mailer: git-send-email 1.7.0.4 In-Reply-To: References: MIME-Version: 1.0 Content-Type: text/plain Cc: jeremy@goop.org, xen-devel@lists.xensource.com, Stefano Stabellini , Stefano.Stabellini@eu.citrix.com, linux-kernel@vger.kernel.org, Ian.Campbell@eu.citrix.com Subject: [Xen-devel] [PATCH v3 2/2] xen: modify kernel mappings corresponding to granted pages X-BeenThere: xen-devel@lists.xensource.com X-Mailman-Version: 2.1.5 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xensource.com Errors-To: xen-devel-bounces@lists.xensource.com From: Stefano Stabellini If we want to use granted pages for AIO, changing the mappings of a user vma and the corresponding p2m is not enough, we also need to update the kernel mappings accordingly. In order to avoid the complexity of dealing with highmem, we allocated the pages lowmem. We issue a HYPERVISOR_grant_table_op right away in m2p_add_override and we remove the mappings using another HYPERVISOR_grant_table_op in m2p_remove_override. Considering that m2p_add_override and m2p_remove_override are called once per page we use multicalls and hypercall batching. Use the kmap_op pointer directly as argument to do the mapping as it is guaranteed to be present up until the unmapping is done. Before issuing any unmapping multicalls, we need to make sure that the mapping has already being done, because we need the kmap->handle to be set correctly. Signed-off-by: Stefano Stabellini --- arch/x86/include/asm/xen/page.h | 5 ++- arch/x86/xen/p2m.c | 67 ++++++++++++++++++++++++++++++++------ drivers/xen/gntdev.c | 27 +++++++++++++++- drivers/xen/grant-table.c | 4 +- include/xen/grant_table.h | 1 + 5 files changed, 89 insertions(+), 15 deletions(-) diff --git a/arch/x86/include/asm/xen/page.h b/arch/x86/include/asm/xen/page.h index 7ff4669..0ce1884 100644 --- a/arch/x86/include/asm/xen/page.h +++ b/arch/x86/include/asm/xen/page.h @@ -12,6 +12,7 @@ #include #include +#include #include /* Xen machine address */ @@ -31,8 +32,10 @@ typedef struct xpaddr { #define INVALID_P2M_ENTRY (~0UL) #define FOREIGN_FRAME_BIT (1UL<<(BITS_PER_LONG-1)) #define IDENTITY_FRAME_BIT (1UL<<(BITS_PER_LONG-2)) +#define GRANT_FRAME_BIT (1UL<<(BITS_PER_LONG-3)) #define FOREIGN_FRAME(m) ((m) | FOREIGN_FRAME_BIT) #define IDENTITY_FRAME(m) ((m) | IDENTITY_FRAME_BIT) +#define GRANT_FRAME(m) ((m) | GRANT_FRAME_BIT) /* Maximum amount of memory we can handle in a domain in pages */ #define MAX_DOMAIN_PAGES \ @@ -48,7 +51,7 @@ extern unsigned long set_phys_range_identity(unsigned long pfn_s, unsigned long pfn_e); extern int m2p_add_override(unsigned long mfn, struct page *page, - bool clear_pte); + struct gnttab_map_grant_ref *kmap_op); extern int m2p_remove_override(struct page *page, bool clear_pte); extern struct page *m2p_find_override(unsigned long mfn); extern unsigned long m2p_find_override_pfn(unsigned long mfn, unsigned long pfn); diff --git a/arch/x86/xen/p2m.c b/arch/x86/xen/p2m.c index 58efeb9..6c26ac80 100644 --- a/arch/x86/xen/p2m.c +++ b/arch/x86/xen/p2m.c @@ -161,7 +161,9 @@ #include #include #include +#include +#include "multicalls.h" #include "xen-ops.h" static void __init m2p_override_init(void); @@ -676,7 +678,8 @@ static unsigned long mfn_hash(unsigned long mfn) } /* Add an MFN override for a particular page */ -int m2p_add_override(unsigned long mfn, struct page *page, bool clear_pte) +int m2p_add_override(unsigned long mfn, struct page *page, + struct gnttab_map_grant_ref *kmap_op) { unsigned long flags; unsigned long pfn; @@ -699,9 +702,20 @@ int m2p_add_override(unsigned long mfn, struct page *page, bool clear_pte) if (unlikely(!set_phys_to_machine(pfn, FOREIGN_FRAME(mfn)))) return -ENOMEM; - if (clear_pte && !PageHighMem(page)) - /* Just zap old mapping for now */ - pte_clear(&init_mm, address, ptep); + if (kmap_op != NULL) { + if (!PageHighMem(page)) { + struct multicall_space mcs = xen_mc_entry(sizeof(*kmap_op)); + + MULTI_grant_table_op(mcs.mc, + GNTTABOP_map_grant_ref, kmap_op, 1); + + xen_mc_issue(PARAVIRT_LAZY_MMU); + } + page->private |= GRANT_FRAME_BIT; + /* let's use dev_bus_addr to record the old mfn instead */ + kmap_op->dev_bus_addr = page->index; + page->index = (unsigned long) kmap_op; + } spin_lock_irqsave(&m2p_override_lock, flags); list_add(&page->lru, &m2p_overrides[mfn_hash(mfn)]); spin_unlock_irqrestore(&m2p_override_lock, flags); @@ -735,13 +749,44 @@ int m2p_remove_override(struct page *page, bool clear_pte) spin_lock_irqsave(&m2p_override_lock, flags); list_del(&page->lru); spin_unlock_irqrestore(&m2p_override_lock, flags); - set_phys_to_machine(pfn, page->index); - if (clear_pte && !PageHighMem(page)) - set_pte_at(&init_mm, address, ptep, - pfn_pte(pfn, PAGE_KERNEL)); - /* No tlb flush necessary because the caller already - * left the pte unmapped. */ + if (clear_pte) { + struct gnttab_map_grant_ref *map_op = + (struct gnttab_map_grant_ref *) page->index; + set_phys_to_machine(pfn, map_op->dev_bus_addr); + if (!PageHighMem(page)) { + struct multicall_space mcs = + xen_mc_entry(sizeof(struct gnttab_unmap_grant_ref)); + struct gnttab_unmap_grant_ref *unmap_op = mcs.args; + + /* + * Has the grant_op mapping multicall being issued? If not, + * make sure it is called now. + */ + if (map_op->handle == -1) + xen_mc_flush(); + if (map_op->handle == -1) { + printk(KERN_WARNING "m2p_remove_override: pfn %lx mfn %lx, " + "failed to modify kernel mappings", pfn, mfn); + return -1; + } + + unmap_op->host_addr = map_op->host_addr; + unmap_op->handle = map_op->handle; + unmap_op->dev_bus_addr = 0; + + MULTI_grant_table_op(mcs.mc, + GNTTABOP_unmap_grant_ref, unmap_op, 1); + + xen_mc_issue(PARAVIRT_LAZY_MMU); + + set_pte_at(&init_mm, address, ptep, + pfn_pte(pfn, PAGE_KERNEL)); + __flush_tlb_single(address); + map_op->host_addr = 0; + } + } else + set_phys_to_machine(pfn, page->index); return 0; } @@ -758,7 +803,7 @@ struct page *m2p_find_override(unsigned long mfn) spin_lock_irqsave(&m2p_override_lock, flags); list_for_each_entry(p, bucket, lru) { - if (p->private == mfn) { + if ((p->private & (~GRANT_FRAME_BIT)) == mfn) { ret = p; break; } diff --git a/drivers/xen/gntdev.c b/drivers/xen/gntdev.c index 07a56c2..783aaad 100644 --- a/drivers/xen/gntdev.c +++ b/drivers/xen/gntdev.c @@ -83,6 +83,7 @@ struct grant_map { struct ioctl_gntdev_grant_ref *grants; struct gnttab_map_grant_ref *map_ops; struct gnttab_unmap_grant_ref *unmap_ops; + struct gnttab_map_grant_ref *kmap_ops; struct page **pages; }; @@ -116,10 +117,12 @@ static struct grant_map *gntdev_alloc_map(struct gntdev_priv *priv, int count) add->grants = kzalloc(sizeof(add->grants[0]) * count, GFP_KERNEL); add->map_ops = kzalloc(sizeof(add->map_ops[0]) * count, GFP_KERNEL); add->unmap_ops = kzalloc(sizeof(add->unmap_ops[0]) * count, GFP_KERNEL); + add->kmap_ops = kzalloc(sizeof(add->kmap_ops[0]) * count, GFP_KERNEL); add->pages = kzalloc(sizeof(add->pages[0]) * count, GFP_KERNEL); if (NULL == add->grants || NULL == add->map_ops || NULL == add->unmap_ops || + NULL == add->kmap_ops || NULL == add->pages) goto err; @@ -129,6 +132,7 @@ static struct grant_map *gntdev_alloc_map(struct gntdev_priv *priv, int count) for (i = 0; i < count; i++) { add->map_ops[i].handle = -1; add->unmap_ops[i].handle = -1; + add->kmap_ops[i].handle = -1; } add->index = 0; @@ -142,6 +146,7 @@ err: kfree(add->grants); kfree(add->map_ops); kfree(add->unmap_ops); + kfree(add->kmap_ops); kfree(add); return NULL; } @@ -243,10 +248,30 @@ static int map_grant_pages(struct grant_map *map) gnttab_set_unmap_op(&map->unmap_ops[i], addr, map->flags, -1 /* handle */); } + } else { + for (i = 0; i < map->count; i++) { + unsigned level; + unsigned long address = (unsigned long) + pfn_to_kaddr(page_to_pfn(map->pages[i])); + pte_t *ptep; + u64 pte_maddr = 0; + if (!PageHighMem(map->pages[i])) { + ptep = lookup_address(address, &level); + pte_maddr = + arbitrary_virt_to_machine(ptep).maddr; + } + gnttab_set_map_op(&map->kmap_ops[i], pte_maddr, + map->flags | + GNTMAP_host_map | + GNTMAP_contains_pte, + map->grants[i].ref, + map->grants[i].domid); + } } pr_debug("map %d+%d\n", map->index, map->count); - err = gnttab_map_refs(map->map_ops, map->pages, map->count); + err = gnttab_map_refs(map->map_ops, use_ptemod ? map->kmap_ops : NULL, + map->pages, map->count); if (err) return err; diff --git a/drivers/xen/grant-table.c b/drivers/xen/grant-table.c index 4f44b34..ed6622f 100644 --- a/drivers/xen/grant-table.c +++ b/drivers/xen/grant-table.c @@ -448,6 +448,7 @@ unsigned int gnttab_max_grant_frames(void) EXPORT_SYMBOL_GPL(gnttab_max_grant_frames); int gnttab_map_refs(struct gnttab_map_grant_ref *map_ops, + struct gnttab_map_grant_ref *kmap_ops, struct page **pages, unsigned int count) { int i, ret; @@ -488,8 +489,7 @@ int gnttab_map_refs(struct gnttab_map_grant_ref *map_ops, */ return -EOPNOTSUPP; } - ret = m2p_add_override(mfn, pages[i], - map_ops[i].flags & GNTMAP_contains_pte); + ret = m2p_add_override(mfn, pages[i], &kmap_ops[i]); if (ret) return ret; } diff --git a/include/xen/grant_table.h b/include/xen/grant_table.h index b1fab6b..6b99bfb 100644 --- a/include/xen/grant_table.h +++ b/include/xen/grant_table.h @@ -156,6 +156,7 @@ unsigned int gnttab_max_grant_frames(void); #define gnttab_map_vaddr(map) ((void *)(map.host_virt_addr)) int gnttab_map_refs(struct gnttab_map_grant_ref *map_ops, + struct gnttab_map_grant_ref *kmap_ops, struct page **pages, unsigned int count); int gnttab_unmap_refs(struct gnttab_unmap_grant_ref *unmap_ops, struct page **pages, unsigned int count); -- 1.7.2.3 _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel From xen-devel-bounces@lists.xensource.com Wed Sep 07 09:35:33 2011 Return-path: Envelope-to: www-data@lists.xensource.com Delivery-date: Wed, 07 Sep 2011 09:35:33 -0700 Received: from localhost ([127.0.0.1] helo=lists.colo.xensource.com) by lists.xensource.com with esmtp (Exim 4.43) id 1R1L65-0003yM-KX; Wed, 07 Sep 2011 09:35:33 -0700 Received: from mail174.messagelabs.com ([85.158.138.51]) by lists.xensource.com with esmtp (Exim 4.43) id 1R1L5g-0003mR-V5 for xen-devel@lists.xensource.com; Wed, 07 Sep 2011 09:35:09 -0700 X-Env-Sender: pasik@iki.fi X-Msg-Ref: server-2.tower-174.messagelabs.com!1315413305!30595397!1 X-Originating-IP: [192.89.123.25] X-StarScan-Version: 6.3.6; banners=-,-,- X-VirusChecked: Checked Received: (qmail 11719 invoked from network); 7 Sep 2011 16:35:05 -0000 Received: from smtp.tele.fi (HELO smtp.tele.fi) (192.89.123.25) by server-2.tower-174.messagelabs.com with DHE-RSA-AES256-SHA encrypted SMTP; 7 Sep 2011 16:35:05 -0000 X-Originating-Ip: [194.89.68.22] Received: from ydin.reaktio.net (reaktio.net [194.89.68.22]) by smtp.tele.fi (Postfix) with ESMTP id E39FE19BC; Wed, 7 Sep 2011 19:35:04 +0300 (EEST) Received: by ydin.reaktio.net (Postfix, from userid 1001) id 9E27C20059; Wed, 7 Sep 2011 19:35:04 +0300 (EEST) Date: Wed, 7 Sep 2011 19:35:04 +0300 From: Pasi =?iso-8859-1?Q?K=E4rkk=E4inen?= To: Wei Wang2 Subject: Re: [Xen-devel] VGA Passthrough on Xen 4.1: succees (IGD) and failure (ATI) report Message-ID: <20110907163504.GH12984@reaktio.net> References: <201105241354.10400.wei.wang2@amd.com> <20110802031408.GB32373@reaktio.net> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <20110802031408.GB32373@reaktio.net> User-Agent: Mutt/1.5.18 (2008-05-17) Cc: xen-devel@lists.xensource.com, Gennady Marchenko X-BeenThere: xen-devel@lists.xensource.com X-Mailman-Version: 2.1.5 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xensource.com Errors-To: xen-devel-bounces@lists.xensource.com On Tue, Aug 02, 2011 at 06:14:09AM +0300, Pasi Kärkkäinen wrote: > On Tue, May 24, 2011 at 01:54:10PM +0200, Wei Wang2 wrote: > > How does this patch work for you? You also need to install latest ATI driver > > in guest. > > http://lists.xensource.com/archives/html/xen-devel/2010-12/msg00705.html > > > > Hello, > > Is this patch considered final and good for merging to xen-unstable? > > Recently many users have asked about Xen VGA passthru so we should > get all the related patches merged in to Xen trees! > Ping? -- Pasi > Thanks, > > -- Pasi > > > > Thanks > > Wei > > > > On Tuesday 17 May 2011 06:47:33 Gennady Marchenko wrote: > > > Hi all! > > > > > > I'm very interested with XenVGAPassthrough and tries to do it on my system > > > with vt-d support: > > > > > > CPU: Intel core2duo E8400 > > > MB: Asus p5q-vm do > > > mem: 8GB > > > > > > So I'm succeed at Intel IGD: > > > > > > 00:02.0 VGA compatible controller: Intel Corporation 4 Series Chipset > > > Integrated Graphics Controller (rev 03) > > > > > > with > > > > > > Debian Sid's XEN 4.1/Linux 2.6.39-rc7+ (from > > > git://git.kernel.org/pub/scm/linux/kernel/git/konrad/xen.git > >nel.org/pub/scm/linux/kernel/git/konrad/xen.git>) and WinXP SP2 with Intel's > > > drivers version 6.14.10.5157 > > > > > > but no success with two ATI cards: > > > > > > ATI X800GTO > > > ATI 5450 > > > (on same m.board) > > > > > > with empty screen. When I run HVM screen went from "empty" to another > > > "empty ", HVM not booting. So I don't know - is there need to do something > > > with bios and how I can do it with binary xen. Could you help me with it > > > please? > > > > > > Thanks all for this feature! > > > Gennady. > > > > > > > > > > _______________________________________________ > > Xen-devel mailing list > > Xen-devel@lists.xensource.com > > http://lists.xensource.com/xen-devel > > _______________________________________________ > Xen-devel mailing list > Xen-devel@lists.xensource.com > http://lists.xensource.com/xen-devel _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel From xen-devel-bounces@lists.xensource.com Wed Sep 07 09:46:35 2011 Return-path: Envelope-to: www-data@lists.xensource.com Delivery-date: Wed, 07 Sep 2011 09:46:35 -0700 Received: from localhost ([127.0.0.1] helo=lists.colo.xensource.com) by lists.xensource.com with esmtp (Exim 4.43) id 1R1LGk-0004ZG-BC; Wed, 07 Sep 2011 09:46:34 -0700 Received: from mail182.messagelabs.com ([85.158.139.83]) by lists.xensource.com with smtp (Exim 4.43) id 1R1LG8-0004Ma-KZ for xen-devel@lists.xensource.com; Wed, 07 Sep 2011 09:45:56 -0700 X-Env-Sender: Stefano.Stabellini@eu.citrix.com X-Msg-Ref: server-10.tower-182.messagelabs.com!1315413953!17420255!1 X-Originating-IP: [62.200.22.115] X-StarScan-Version: 6.3.6; banners=-,-,- X-VirusChecked: Checked Received: (qmail 3467 invoked from network); 7 Sep 2011 16:45:53 -0000 Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115) by server-10.tower-182.messagelabs.com with SMTP; 7 Sep 2011 16:45:53 -0000 X-IronPort-AV: E=Sophos;i="4.68,346,1312156800"; d="scan'208";a="7658700" Received: from lonpmailmx01.citrite.net ([10.30.203.162]) by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5; 07 Sep 2011 16:45:53 +0000 Received: from kaball.uk.xensource.com (10.80.2.59) by LONPMAILMX01.citrite.net (10.30.203.162) with Microsoft SMTP Server id 8.3.137.0; Wed, 7 Sep 2011 17:45:53 +0100 Date: Wed, 7 Sep 2011 17:54:01 +0100 From: Stefano Stabellini X-X-Sender: sstabellini@kaball-desktop To: Ian Campbell Subject: Re: [Xen-devel] [PATCH 1/2] Introduce support for upstream qemu in the xen-unstable build system In-Reply-To: <1315412504.3180.20.camel@cthulhu.hellion.org.uk> Message-ID: References: <1315406398-8987-1-git-send-email-stefano.stabellini@eu.citrix.com> <1315412504.3180.20.camel@cthulhu.hellion.org.uk> User-Agent: Alpine 2.00 (DEB 1167 2008-08-23) MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Cc: "xen-devel@lists.xensource.com" , "keir@xen.org" , Stefano Stabellini X-BeenThere: xen-devel@lists.xensource.com X-Mailman-Version: 2.1.5 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xensource.com Errors-To: xen-devel-bounces@lists.xensource.com On Wed, 7 Sep 2011, Ian Campbell wrote: > On Wed, 2011-09-07 at 10:39 -0400, stefano.stabellini@eu.citrix.com > wrote: > > In order to distinguish between upstream qemu and qemu-xen I am > > introducing a new variable named "QEMU" that only if is equal to > > "upstream" switches the build system to the new qemu. > > Thanks Stefano, this integrated support is overdue. > > Ultimately though I expect we will need a "both" mode since people will > want old qemu for compatibility with their existing installed guests and > new qemu for new ones. The allegation (and I don't really know how true > it is or if it is pessimism or realism) is that some OSes don't cope > with having the platform components etc changed under them. Yes. At that point we'll probably have to always build them both, including two hvmloader... > > Users that want to try the new qemu just have to export QEMU=upstream > > before calling make in the xen-unstable top level directory. > > In xl/libxl we call them "qemu-xen-traditional" and "qemu-xen". Perhaps > we should mirror that nomenclature here? I looked at libxl but I thought that QEMU=qemu-xen would be confusing for users/developers. Like you said, considering that we already have device_model_version=qemu-xen in VM config files, maybe we should go for DEVICE_MODEL=qemu-xen? _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel From xen-devel-bounces@lists.xensource.com Wed Sep 07 09:47:58 2011 Return-path: Envelope-to: www-data@lists.xensource.com Delivery-date: Wed, 07 Sep 2011 09:47:58 -0700 Received: from localhost ([127.0.0.1] helo=lists.colo.xensource.com) by lists.xensource.com with esmtp (Exim 4.43) id 1R1LI6-00051g-QZ; Wed, 07 Sep 2011 09:47:58 -0700 Received: from mail216.messagelabs.com ([85.158.143.99]) by lists.xensource.com with esmtp (Exim 4.43) id 1R1LHW-0004or-VJ for xen-devel@lists.xensource.com; Wed, 07 Sep 2011 09:47:23 -0700 X-Env-Sender: Ian.Campbell@eu.citrix.com X-Msg-Ref: server-6.tower-216.messagelabs.com!1315414038!16161759!1 X-Originating-IP: [66.165.176.63] X-StarScan-Version: 6.3.6; banners=-,-,- X-VirusChecked: Checked Received: (qmail 10261 invoked from network); 7 Sep 2011 16:47:19 -0000 Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63) by server-6.tower-216.messagelabs.com with RC4-SHA encrypted SMTP; 7 Sep 2011 16:47:19 -0000 X-IronPort-AV: E=Sophos;i="4.68,346,1312171200"; d="scan'208";a="162030682" Received: from ftlpmailmx02.citrite.net ([10.13.107.66]) by FTLPIPO02.CITRIX.COM with ESMTP/TLS/RC4-MD5; 07 Sep 2011 12:47:18 -0400 Received: from [127.0.0.1] (10.80.16.67) by smtprelay.citrix.com (10.13.107.66) with Microsoft SMTP Server id 8.3.137.0; Wed, 7 Sep 2011 12:47:17 -0400 Subject: Re: [Xen-devel] VGA Passthrough on Xen 4.1: succees (IGD) and failure (ATI) report From: Ian Campbell To: Pasi =?ISO-8859-1?Q?K=E4rkk=E4inen?= Date: Wed, 7 Sep 2011 09:47:15 -0700 In-Reply-To: <20110907163504.GH12984@reaktio.net> References: <201105241354.10400.wei.wang2@amd.com> <20110802031408.GB32373@reaktio.net> <20110907163504.GH12984@reaktio.net> Organization: Citrix Systems, Inc. Content-Type: text/plain; charset="UTF-8" X-Mailer: Evolution 3.0.3- Content-Transfer-Encoding: 8bit Message-ID: <1315414037.3180.30.camel@cthulhu.hellion.org.uk> MIME-Version: 1.0 Cc: Wei Wang2 , "xen-devel@lists.xensource.com" , Gennady Marchenko X-BeenThere: xen-devel@lists.xensource.com X-Mailman-Version: 2.1.5 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xensource.com Errors-To: xen-devel-bounces@lists.xensource.com On Wed, 2011-09-07 at 12:35 -0400, Pasi Kärkkäinen wrote: > On Tue, Aug 02, 2011 at 06:14:09AM +0300, Pasi Kärkkäinen wrote: > > On Tue, May 24, 2011 at 01:54:10PM +0200, Wei Wang2 wrote: > > > How does this patch work for you? You also need to install latest ATI driver > > > in guest. > > > http://lists.xensource.com/archives/html/xen-devel/2010-12/msg00705.html > > > > > > > Hello, > > > > Is this patch considered final and good for merging to xen-unstable? > > > > Recently many users have asked about Xen VGA passthru so we should > > get all the related patches merged in to Xen trees! > > > > Ping? As I said last time: I think someone needs to gather them together and repost them all as a series. Realistically maintainers aren't going to go trawling list archives trying to figure out which patches are necessary/correct/desirable etc. Someone who has been following this stuff needs to pickup the relevant patches and post them as a series and champion/babysit/justify that series, respond to review comments, repost etc. Upthread I see that the particular patch in question breaks the stubdom build, so my first review comment is "please don't break stubdom". Ian. > > -- Pasi > > > > > Thanks, > > > > -- Pasi > > > > > > > Thanks > > > Wei > > > > > > On Tuesday 17 May 2011 06:47:33 Gennady Marchenko wrote: > > > > Hi all! > > > > > > > > I'm very interested with XenVGAPassthrough and tries to do it on my system > > > > with vt-d support: > > > > > > > > CPU: Intel core2duo E8400 > > > > MB: Asus p5q-vm do > > > > mem: 8GB > > > > > > > > So I'm succeed at Intel IGD: > > > > > > > > 00:02.0 VGA compatible controller: Intel Corporation 4 Series Chipset > > > > Integrated Graphics Controller (rev 03) > > > > > > > > with > > > > > > > > Debian Sid's XEN 4.1/Linux 2.6.39-rc7+ (from > > > > git://git.kernel.org/pub/scm/linux/kernel/git/konrad/xen.git > > >nel.org/pub/scm/linux/kernel/git/konrad/xen.git>) and WinXP SP2 with Intel's > > > > drivers version 6.14.10.5157 > > > > > > > > but no success with two ATI cards: > > > > > > > > ATI X800GTO > > > > ATI 5450 > > > > (on same m.board) > > > > > > > > with empty screen. When I run HVM screen went from "empty" to another > > > > "empty ", HVM not booting. So I don't know - is there need to do something > > > > with bios and how I can do it with binary xen. Could you help me with it > > > > please? > > > > > > > > Thanks all for this feature! > > > > Gennady. > > > > > > > > > > > > > > > _______________________________________________ > > > Xen-devel mailing list > > > Xen-devel@lists.xensource.com > > > http://lists.xensource.com/xen-devel > > > > _______________________________________________ > > Xen-devel mailing list > > Xen-devel@lists.xensource.com > > http://lists.xensource.com/xen-devel > > _______________________________________________ > Xen-devel mailing list > Xen-devel@lists.xensource.com > http://lists.xensource.com/xen-devel _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel From xen-devel-bounces@lists.xensource.com Wed Sep 07 09:51:12 2011 Return-path: Envelope-to: www-data@lists.xensource.com Delivery-date: Wed, 07 Sep 2011 09:51:12 -0700 Received: from localhost ([127.0.0.1] helo=lists.colo.xensource.com) by lists.xensource.com with esmtp (Exim 4.43) id 1R1LLE-0005RN-AE; Wed, 07 Sep 2011 09:51:12 -0700 Received: from mail174.messagelabs.com ([85.158.138.51]) by lists.xensource.com with esmtp (Exim 4.43) id 1R1LKq-0005En-1G for xen-devel@lists.xensource.com; Wed, 07 Sep 2011 09:50:48 -0700 X-Env-Sender: keir.xen@gmail.com X-Msg-Ref: server-12.tower-174.messagelabs.com!1315414244!30582462!1 X-Originating-IP: [74.125.82.171] X-StarScan-Version: 6.3.6; banners=-,-,- X-VirusChecked: Checked Received: (qmail 25549 invoked from network); 7 Sep 2011 16:50:45 -0000 Received: from mail-wy0-f171.google.com (HELO mail-wy0-f171.google.com) (74.125.82.171) by server-12.tower-174.messagelabs.com with RC4-SHA encrypted SMTP; 7 Sep 2011 16:50:45 -0000 Received: by wyh13 with SMTP id 13so7029139wyh.30 for ; Wed, 07 Sep 2011 09:50:44 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=user-agent:date:subject:from:to:message-id:thread-topic :thread-index:in-reply-to:mime-version:content-type :content-transfer-encoding; bh=Pc4J3/xFwtXbsvXQkaTtCQUcJx5EE8kpyBj6/wAq23I=; b=IZg8EQI5vJ1/DmBy+XPP13zsxOIox01cfZJSzRDCPZ5W83am7MLEXV+LEOvwzCPfRg uLxCGTxEqwkU0HctQ29OaXBbTmLl3ukFEBbQUAPaQy+VwnTsBsEtBCJxEYUXiTbIOgv1 /izG+PeYxUscGk8r/CQArcxJ0wWVcO16Cp1jM= Received: by 10.227.116.77 with SMTP id l13mr6879800wbq.33.1315414244701; Wed, 07 Sep 2011 09:50:44 -0700 (PDT) Received: from [192.168.1.78] (host86-137-116-193.range86-137.btcentralplus.com [86.137.116.193]) by mx.google.com with ESMTPS id fa3sm1119426wbb.3.2011.09.07.09.50.39 (version=SSLv3 cipher=OTHER); Wed, 07 Sep 2011 09:50:43 -0700 (PDT) User-Agent: Microsoft-Entourage/12.30.0.110427 Date: Wed, 07 Sep 2011 17:50:36 +0100 From: Keir Fraser To: , Message-ID: Thread-Topic: [PATCH 1/2] Introduce support for upstream qemu in the xen-unstable build system Thread-Index: AcxtfkPvG0Z0OlnSy06GAJth183C3Q== In-Reply-To: <1315406398-8987-1-git-send-email-stefano.stabellini@eu.citrix.com> Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit Cc: Subject: [Xen-devel] Re: [PATCH 1/2] Introduce support for upstream qemu in the xen-unstable build system X-BeenThere: xen-devel@lists.xensource.com X-Mailman-Version: 2.1.5 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xensource.com Errors-To: xen-devel-bounces@lists.xensource.com On 07/09/2011 15:39, "stefano.stabellini@eu.citrix.com" wrote: > In order to distinguish between upstream qemu and qemu-xen I am > introducing a new variable named "QEMU" that only if is equal to > "upstream" switches the build system to the new qemu. > > Users that want to try the new qemu just have to export QEMU=upstream > before calling make in the xen-unstable top level directory. I think we should build and install both, and select between them via per-domain config option. That's basically what we need for supporting old save images. -- Keir > Signed-off-by: Stefano Stabellini > > diff -r 0ba816e077e6 Config.mk > --- a/Config.mk Wed Aug 31 16:04:37 2011 +0000 > +++ b/Config.mk Wed Sep 07 11:13:17 2011 +0000 > @@ -192,12 +192,21 @@ else > QEMU_REMOTE=git://xenbits.xensource.com/qemu-xen-unstable.git > endif > > +# Only available through the git protocol at the moment > +QEMU_UPSTREAM_URL=git://xenbits.xen.org/people/sstabellini/qemu-dm.git > +QEMU_UPSTREAM_TAG=origin/xen-stable-0.15 > + > # Specify which qemu-dm to use. This may be `ioemu' to use the old > # Mercurial in-tree version, or a local directory, or a git URL. > # CONFIG_QEMU ?= `pwd`/$(XEN_ROOT)/../qemu-xen.git > +ifeq ($(QEMU),upstream) > +CONFIG_QEMU ?= $(QEMU_UPSTREAM_URL) > +QEMU_TAG ?= $(QEMU_UPSTREAM_TAG) > +else > CONFIG_QEMU ?= $(QEMU_REMOTE) > +QEMU_TAG ?= cd776ee9408ff127f934a707c1a339ee600bc127 > +endif > > -QEMU_TAG ?= cd776ee9408ff127f934a707c1a339ee600bc127 > # Tue Jun 28 13:50:53 2011 +0100 > # qemu-char.c: fix incorrect CONFIG_STUBDOM handling > > diff -r 0ba816e077e6 tools/Makefile > --- a/tools/Makefile Wed Aug 31 16:04:37 2011 +0000 > +++ b/tools/Makefile Wed Sep 07 11:13:17 2011 +0000 > @@ -106,7 +106,19 @@ ioemu-dir-find: > set -e; \ > $(buildmakevars2shellvars); \ > cd ioemu-dir; \ > - $(QEMU_ROOT)/xen-setup $(IOEMU_CONFIGURE_CROSS) > + if [ "$(QEMU)" = upstream ]; then \ > + cd $(QEMU_ROOT); \ > + ./configure --enable-xen --target-list=i386-softmmu \ > + --extra-cflags="-I$(XEN_ROOT)/tools/include \ > + -I$(XEN_ROOT)/tools/libxc \ > + -I$(XEN_ROOT)/tools/xenstore" \ > + --extra-ldflags="-L$(XEN_ROOT)/tools/libxc \ > + -L$(XEN_ROOT)/tools/libxenstore" \ > + --disable-kvm \ > + $(IOEMU_CONFIGURE_CROSS); \ > + else \ > + $(QEMU_ROOT)/xen-setup $(IOEMU_CONFIGURE_CROSS); \ > + fi > > .PHONY: ioemu-dir-force-update > ioemu-dir-force-update: _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel From xen-devel-bounces@lists.xensource.com Wed Sep 07 09:54:03 2011 Return-path: Envelope-to: www-data@lists.xensource.com Delivery-date: Wed, 07 Sep 2011 09:54:03 -0700 Received: from localhost ([127.0.0.1] helo=lists.colo.xensource.com) by lists.xensource.com with esmtp (Exim 4.43) id 1R1LNz-0005qZ-Dm; Wed, 07 Sep 2011 09:54:03 -0700 Received: from mail21.messagelabs.com ([85.158.143.35]) by lists.xensource.com with esmtp (Exim 4.43) id 1R1LNZ-0005dl-Je for Xen-devel@lists.xensource.com; Wed, 07 Sep 2011 09:53:37 -0700 X-Env-Sender: konrad@dumpdata.com X-Msg-Ref: server-7.tower-21.messagelabs.com!1315414384!53976364!1 X-Originating-IP: [148.87.113.117] X-StarScan-Version: 6.3.6; banners=-,-,- X-VirusChecked: Checked Received: (qmail 12712 invoked from network); 7 Sep 2011 16:53:05 -0000 Received: from rcsinet15.oracle.com (HELO rcsinet15.oracle.com) (148.87.113.117) by server-7.tower-21.messagelabs.com with DHE-RSA-AES256-SHA encrypted SMTP; 7 Sep 2011 16:53:05 -0000 Received: from acsinet21.oracle.com (acsinet21.oracle.com [141.146.126.237]) by rcsinet15.oracle.com (Switch-3.4.4/Switch-3.4.4) with ESMTP id p87GrTKW012703 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Wed, 7 Sep 2011 16:53:31 GMT Received: from acsmt357.oracle.com (acsmt357.oracle.com [141.146.40.157]) by acsinet21.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id p87GrTLu002247 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 7 Sep 2011 16:53:29 GMT Received: from abhmt112.oracle.com (abhmt112.oracle.com [141.146.116.64]) by acsmt357.oracle.com (8.12.11.20060308/8.12.11) with ESMTP id p87GrNE7007219; Wed, 7 Sep 2011 11:53:23 -0500 Received: from phenom (/209.6.55.207) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Wed, 07 Sep 2011 09:53:23 -0700 Received: by phenom (Postfix, from userid 1000) id 2B2B410B8; Wed, 7 Sep 2011 12:53:11 -0400 (EDT) Date: Wed, 7 Sep 2011 12:53:11 -0400 From: Konrad Rzeszutek Wilk To: "Jinesh M.K" Subject: Re: [Xen-devel] Memory location of Vm Message-ID: <20110907165310.GG32190@dumpdata.com> References: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.21 (2010-09-15) X-Source-IP: acsinet21.oracle.com [141.146.126.237] X-Auth-Type: Internal IP X-CT-RefId: str=0001.0A090206.4E67A18B.00F6:SCFMA922111,ss=1,re=-4.000,fgs=0 Cc: Xen-devel@lists.xensource.com X-BeenThere: xen-devel@lists.xensource.com X-Mailman-Version: 2.1.5 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xensource.com Errors-To: xen-devel-bounces@lists.xensource.com On Sat, Sep 03, 2011 at 02:55:03PM +0530, Jinesh M.K wrote: > HAi, > how to identify the memory location of each vm (start and end location)from > dom0? Take a look at the migration tools - they do a lot of looking at the frame numbers. Keep in mind that the memory for the guests are not contingous at all. > > Thanks in advance > > Thanking you, > Jinesh > _______________________________________________ > Xen-devel mailing list > Xen-devel@lists.xensource.com > http://lists.xensource.com/xen-devel _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel From xen-devel-bounces@lists.xensource.com Wed Sep 07 09:55:01 2011 Return-path: Envelope-to: www-data@lists.xensource.com Delivery-date: Wed, 07 Sep 2011 09:55:01 -0700 Received: from localhost ([127.0.0.1] helo=lists.colo.xensource.com) by lists.xensource.com with esmtp (Exim 4.43) id 1R1LOu-0006Cn-UQ; Wed, 07 Sep 2011 09:55:00 -0700 Received: from mail182.messagelabs.com ([85.158.139.83]) by lists.xensource.com with smtp (Exim 4.43) id 1R1LNn-0005j2-QD for xen-devel@lists.xensource.com; Wed, 07 Sep 2011 09:53:52 -0700 X-Env-Sender: dzickus@redhat.com X-Msg-Ref: server-12.tower-182.messagelabs.com!1315414427!17289288!1 X-Originating-IP: [209.132.183.28] X-StarScan-Version: 6.3.6; banners=-,-,- X-VirusChecked: Checked Received: (qmail 4011 invoked from network); 7 Sep 2011 16:53:48 -0000 Received: from mx1.redhat.com (HELO mx1.redhat.com) (209.132.183.28) by server-12.tower-182.messagelabs.com with SMTP; 7 Sep 2011 16:53:48 -0000 Received: from int-mx02.intmail.prod.int.phx2.redhat.com (int-mx02.intmail.prod.int.phx2.redhat.com [10.5.11.12]) by mx1.redhat.com (8.14.4/8.14.4) with ESMTP id p87Gq5LG001854 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Wed, 7 Sep 2011 12:52:05 -0400 Received: from redhat.com (dhcp-100-19-141.bos.redhat.com [10.16.19.141]) by int-mx02.intmail.prod.int.phx2.redhat.com (8.13.8/8.13.8) with SMTP id p87Gq4Kk025192; Wed, 7 Sep 2011 12:52:04 -0400 Date: Wed, 7 Sep 2011 12:52:03 -0400 From: Don Zickus To: Avi Kivity Message-ID: <20110907165203.GQ6838@redhat.com> References: <1314996468.8255.0.camel@twins> <4E614FBD.2030509@goop.org> <20110906151408.GA7459@redhat.com> <4E66615E.8070806@goop.org> <20110906182758.GR5795@redhat.com> <4E66EF86.9070200@redhat.com> <20110907134411.GV5795@redhat.com> <4E678992.5050709@redhat.com> <20110907155657.GX5795@redhat.com> <4E679AF4.50209@redhat.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <4E679AF4.50209@redhat.com> User-Agent: Mutt/1.5.21 (2010-09-15) X-Scanned-By: MIMEDefang 2.67 on 10.5.11.12 Cc: Jeremy Fitzhardinge , Marcelo Tosatti , Nick Piggin , KVM , Stefano Stabellini , Peter Zijlstra , the arch/x86 maintainers , Linux Kernel Mailing List , Andi Kleen , Jeremy Fitzhardinge , "H. Peter Anvin" , Ingo Molnar , Linus Torvalds , Xen Devel Subject: [Xen-devel] Re: [PATCH 08/13] xen/pvticketlock: disable interrupts while blocking X-BeenThere: xen-devel@lists.xensource.com X-Mailman-Version: 2.1.5 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xensource.com Errors-To: xen-devel-bounces@lists.xensource.com On Wed, Sep 07, 2011 at 07:25:24PM +0300, Avi Kivity wrote: > On 09/07/2011 06:56 PM, Don Zickus wrote: > >> > >> And hope that no other NMI was generated while we're handling this > >> one. It's a little... fragile? > > > >No. If another NMI is generated while we are processing the current one > >it should get latched. Upon completion of the current one, the cpu should > >jump right back into the nmi exception routine again. The only downside > >is when multiple NMIs come in during the processing of the current one. > >Only one can be latched, so the others get dropped. > > Ah, yes, I remember now. > > >But we are addressing > >that. > > > > May I ask how? Detecting a back-to-back NMI? Pretty boring actually. Currently we execute an NMI handler until one of them returns handled. Then we stop. This may cause us to miss an NMI in the case of multiple NMIs at once. Now we are changing it to execute _all_ the handlers to make sure we didn't miss one. But then the downside here is we accidentally handle an NMI that was latched. This would cause a 'Dazed on confused' message as that NMI was already handled by the previous NMI. We are working on an algorithm to detect this condition and flag it (nothing complicated). But it may never be perfect. On the other hand, what else are we going to do with an edge-triggered shared interrupt line? Cheers, Don _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel From xen-devel-bounces@lists.xensource.com Wed Sep 07 09:57:19 2011 Return-path: Envelope-to: www-data@lists.xensource.com Delivery-date: Wed, 07 Sep 2011 09:57:19 -0700 Received: from localhost ([127.0.0.1] helo=lists.colo.xensource.com) by lists.xensource.com with esmtp (Exim 4.43) id 1R1LR8-0006dj-WA; Wed, 07 Sep 2011 09:57:19 -0700 Received: from mail174.messagelabs.com ([85.158.138.51]) by lists.xensource.com with esmtp (Exim 4.43) id 1R1LQc-0006On-Gk for xen-devel@lists.xensource.com; Wed, 07 Sep 2011 09:56:47 -0700 X-Env-Sender: keir.xen@gmail.com X-Msg-Ref: server-12.tower-174.messagelabs.com!1315414603!30583117!1 X-Originating-IP: [74.125.82.171] X-StarScan-Version: 6.3.6; banners=-,-,- X-VirusChecked: Checked Received: (qmail 6639 invoked from network); 7 Sep 2011 16:56:43 -0000 Received: from mail-wy0-f171.google.com (HELO mail-wy0-f171.google.com) (74.125.82.171) by server-12.tower-174.messagelabs.com with RC4-SHA encrypted SMTP; 7 Sep 2011 16:56:43 -0000 Received: by wyh13 with SMTP id 13so7034230wyh.30 for ; Wed, 07 Sep 2011 09:56:43 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=user-agent:date:subject:from:to:cc:message-id:thread-topic :thread-index:in-reply-to:mime-version:content-type :content-transfer-encoding; bh=5bJwCx/aXzHgbD8uZrJv3zevLQnqWVDNyjakhpeQygw=; b=F2BDao8QNe041C+LkaRFMVa9rKb1PQd85LROPsxvnXXbIgg8ry/j6GE6rLbzsFiGrf lwA7YOZua8IxIIgBnWySnJwU1RPQRi4Ga5iOK2MrVNYTY3z7TMJZN63xrKXqerGr/DwC puqxUN2aa7Kv2XG31MeWxYjUZNsgxDt/yjNd4= Received: by 10.227.174.72 with SMTP id s8mr5456513wbz.68.1315414603148; Wed, 07 Sep 2011 09:56:43 -0700 (PDT) Received: from [192.168.1.78] (host86-137-116-193.range86-137.btcentralplus.com [86.137.116.193]) by mx.google.com with ESMTPS id fo14sm1100639wbb.19.2011.09.07.09.56.39 (version=SSLv3 cipher=OTHER); Wed, 07 Sep 2011 09:56:41 -0700 (PDT) User-Agent: Microsoft-Entourage/12.30.0.110427 Date: Wed, 07 Sep 2011 17:56:32 +0100 Subject: Re: [Xen-devel] [PATCH] IRQ: Group IRQ_MOVE_CLEANUP_VECTOR with other hypervisor IPIs From: Keir Fraser To: Jan Beulich , Andrew Cooper Message-ID: Thread-Topic: [Xen-devel] [PATCH] IRQ: Group IRQ_MOVE_CLEANUP_VECTOR with other hypervisor IPIs Thread-Index: AcxtfxghQwDwjTpnMEGausZnUIEhKA== In-Reply-To: <4E67B1DB020000780005517A@nat28.tlf.novell.com> Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit Cc: xen-devel@lists.xensource.com X-BeenThere: xen-devel@lists.xensource.com X-Mailman-Version: 2.1.5 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xensource.com Errors-To: xen-devel-bounces@lists.xensource.com On 07/09/2011 17:03, "Jan Beulich" wrote: >>>> On 07.09.11 at 17:03, Andrew Cooper wrote: > > Are you sure this is correct? I'm suspicious that this may intentionally > have been the lowest priority vector... I can't see why? >> Also, rename to MOVE_CLEANUP_VECTOR to be in line with the other IPI >> names. > > Why would the removal of part of the descriptive name be in line with > the other names? We're dealing with the cleanup after an IRQ move > here, so let the name state this. The IRQ_ prefix here has nothing to > do with this being the vector for a specific IRQ. Agreed. -- Keir > Jan > >> This requires bumping LAST_HIPRIORITY_VECTOR, but does mean that the >> range FIRST-LAST_HIPRIORITY_VECTORs are free once again. >> >> Signed-off-by: Andrew Cooper >> >> diff -r 0268e7380953 -r c7884dbb6f7d xen/arch/x86/apic.c >> --- a/xen/arch/x86/apic.c Mon Sep 05 15:10:28 2011 +0100 >> +++ b/xen/arch/x86/apic.c Wed Sep 07 16:00:55 2011 +0100 >> @@ -90,7 +90,7 @@ bool_t __read_mostly directed_eoi_enable >> * through the ICC by us (IPIs) >> */ >> __asm__(".section .text"); >> -BUILD_SMP_INTERRUPT(irq_move_cleanup_interrupt,IRQ_MOVE_CLEANUP_VECTOR) >> +BUILD_SMP_INTERRUPT(irq_move_cleanup_interrupt,MOVE_CLEANUP_VECTOR) >> BUILD_SMP_INTERRUPT(event_check_interrupt,EVENT_CHECK_VECTOR) >> BUILD_SMP_INTERRUPT(invalidate_interrupt,INVALIDATE_TLB_VECTOR) >> BUILD_SMP_INTERRUPT(call_function_interrupt,CALL_FUNCTION_VECTOR) >> diff -r 0268e7380953 -r c7884dbb6f7d xen/arch/x86/hvm/vmx/vmx.c >> --- a/xen/arch/x86/hvm/vmx/vmx.c Mon Sep 05 15:10:28 2011 +0100 >> +++ b/xen/arch/x86/hvm/vmx/vmx.c Wed Sep 07 16:00:55 2011 +0100 >> @@ -1986,7 +1986,7 @@ static void vmx_do_extint(struct cpu_use >> >> switch ( vector ) >> { >> - case IRQ_MOVE_CLEANUP_VECTOR: >> + case MOVE_CLEANUP_VECTOR: >> smp_irq_move_cleanup_interrupt(regs); >> break; >> case LOCAL_TIMER_VECTOR: >> diff -r 0268e7380953 -r c7884dbb6f7d xen/arch/x86/io_apic.c >> --- a/xen/arch/x86/io_apic.c Mon Sep 05 15:10:28 2011 +0100 >> +++ b/xen/arch/x86/io_apic.c Wed Sep 07 16:00:55 2011 +0100 >> @@ -476,7 +476,7 @@ fastcall void smp_irq_move_cleanup_inter >> * to myself. >> */ >> if (irr & (1 << (vector % 32))) { >> - genapic->send_IPI_self(IRQ_MOVE_CLEANUP_VECTOR); >> + genapic->send_IPI_self(MOVE_CLEANUP_VECTOR); >> TRACE_3D(TRC_HW_IRQ_MOVE_CLEANUP_DELAY, >> irq, vector, smp_processor_id()); >> goto unlock; >> @@ -513,7 +513,7 @@ static void send_cleanup_vector(struct i >> >> cpus_and(cleanup_mask, cfg->old_cpu_mask, cpu_online_map); >> cfg->move_cleanup_count = cpus_weight(cleanup_mask); >> - genapic->send_IPI_mask(&cleanup_mask, IRQ_MOVE_CLEANUP_VECTOR); >> + genapic->send_IPI_mask(&cleanup_mask, MOVE_CLEANUP_VECTOR); >> >> cfg->move_in_progress = 0; >> } >> diff -r 0268e7380953 -r c7884dbb6f7d xen/arch/x86/irq.c >> --- a/xen/arch/x86/irq.c Mon Sep 05 15:10:28 2011 +0100 >> +++ b/xen/arch/x86/irq.c Wed Sep 07 16:00:55 2011 +0100 >> @@ -338,7 +338,7 @@ int __init init_irq_data(void) >> set_bit(HYPERCALL_VECTOR, used_vectors); >> >> /* IRQ_MOVE_CLEANUP_VECTOR used for clean up vectors */ >> - set_bit(IRQ_MOVE_CLEANUP_VECTOR, used_vectors); >> + set_bit(MOVE_CLEANUP_VECTOR, used_vectors); >> >> return 0; >> } >> diff -r 0268e7380953 -r c7884dbb6f7d xen/arch/x86/smpboot.c >> --- a/xen/arch/x86/smpboot.c Mon Sep 05 15:10:28 2011 +0100 >> +++ b/xen/arch/x86/smpboot.c Wed Sep 07 16:00:55 2011 +0100 >> @@ -1027,7 +1027,7 @@ void __init smp_intr_init(void) >> } >> >> /* IPI for cleanuping vectors after irq move */ >> - set_intr_gate(IRQ_MOVE_CLEANUP_VECTOR, irq_move_cleanup_interrupt); >> + set_intr_gate(MOVE_CLEANUP_VECTOR, irq_move_cleanup_interrupt); >> >> /* IPI for event checking. */ >> set_intr_gate(EVENT_CHECK_VECTOR, event_check_interrupt); >> diff -r 0268e7380953 -r c7884dbb6f7d >> xen/include/asm-x86/mach-default/irq_vectors.h >> --- a/xen/include/asm-x86/mach-default/irq_vectors.h Mon Sep 05 15:10:28 2011 >> +0100 >> +++ b/xen/include/asm-x86/mach-default/irq_vectors.h Wed Sep 07 16:00:55 2011 >> +0100 >> @@ -11,12 +11,14 @@ >> #define LOCAL_TIMER_VECTOR 0xf9 >> #define PMU_APIC_VECTOR 0xf8 >> #define CMCI_APIC_VECTOR 0xf7 >> +#define MOVE_CLEANUP_VECTOR 0xf6 >> + >> /* >> * High-priority dynamically-allocated vectors. For interrupts that >> * must be higher priority than any guest-bound interrupt. >> */ >> #define FIRST_HIPRIORITY_VECTOR 0xf0 >> -#define LAST_HIPRIORITY_VECTOR 0xf6 >> +#define LAST_HIPRIORITY_VECTOR 0xf5 >> >> /* Legacy PIC uses vectors 0xe0-0xef. */ >> #define FIRST_LEGACY_VECTOR 0xe0 >> @@ -30,8 +32,6 @@ >> #define LAST_DYNAMIC_VECTOR 0xdf >> #define NR_DYNAMIC_VECTORS (LAST_DYNAMIC_VECTOR - FIRST_DYNAMIC_VECTOR + 1) >> >> -#define IRQ_MOVE_CLEANUP_VECTOR FIRST_DYNAMIC_VECTOR >> - >> #define NR_VECTORS 256 >> >> #endif /* _ASM_IRQ_VECTORS_H */ >> >> _______________________________________________ >> Xen-devel mailing list >> Xen-devel@lists.xensource.com >> http://lists.xensource.com/xen-devel > > > > _______________________________________________ > Xen-devel mailing list > Xen-devel@lists.xensource.com > http://lists.xensource.com/xen-devel _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel From xen-devel-bounces@lists.xensource.com Wed Sep 07 10:01:46 2011 Return-path: Envelope-to: www-data@lists.xensource.com Delivery-date: Wed, 07 Sep 2011 10:01:46 -0700 Received: from localhost ([127.0.0.1] helo=lists.colo.xensource.com) by lists.xensource.com with esmtp (Exim 4.43) id 1R1LVQ-00073x-5R; Wed, 07 Sep 2011 10:01:45 -0700 Received: from mail182.messagelabs.com ([85.158.139.83]) by lists.xensource.com with esmtp (Exim 4.43) id 1R1LS1-0006p3-Gl for xen-devel@lists.xensource.com; Wed, 07 Sep 2011 09:58:13 -0700 X-Env-Sender: pasik@iki.fi X-Msg-Ref: server-13.tower-182.messagelabs.com!1315414690!17277269!1 X-Originating-IP: [192.89.123.25] X-StarScan-Version: 6.3.6; banners=-,-,- X-VirusChecked: Checked Received: (qmail 27363 invoked from network); 7 Sep 2011 16:58:10 -0000 Received: from smtp.tele.fi (HELO smtp.tele.fi) (192.89.123.25) by server-13.tower-182.messagelabs.com with DHE-RSA-AES256-SHA encrypted SMTP; 7 Sep 2011 16:58:10 -0000 X-Originating-Ip: [194.89.68.22] Received: from ydin.reaktio.net (reaktio.net [194.89.68.22]) by smtp.tele.fi (Postfix) with ESMTP id CF4B21BB3; Wed, 7 Sep 2011 19:58:08 +0300 (EEST) Received: by ydin.reaktio.net (Postfix, from userid 1001) id 2C38420059; Wed, 7 Sep 2011 19:58:08 +0300 (EEST) Date: Wed, 7 Sep 2011 19:58:08 +0300 From: Pasi =?iso-8859-1?Q?K=E4rkk=E4inen?= To: Ian Campbell Subject: Re: [Xen-devel] VGA Passthrough on Xen 4.1: succees (IGD) and failure (ATI) report Message-ID: <20110907165808.GI12984@reaktio.net> References: <201105241354.10400.wei.wang2@amd.com> <20110802031408.GB32373@reaktio.net> <20110907163504.GH12984@reaktio.net> <1315414037.3180.30.camel@cthulhu.hellion.org.uk> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <1315414037.3180.30.camel@cthulhu.hellion.org.uk> User-Agent: Mutt/1.5.18 (2008-05-17) Cc: Wei Wang2 , "xen-devel@lists.xensource.com" , Gennady Marchenko X-BeenThere: xen-devel@lists.xensource.com X-Mailman-Version: 2.1.5 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xensource.com Errors-To: xen-devel-bounces@lists.xensource.com On Wed, Sep 07, 2011 at 09:47:15AM -0700, Ian Campbell wrote: > On Wed, 2011-09-07 at 12:35 -0400, Pasi Kärkkäinen wrote: > > On Tue, Aug 02, 2011 at 06:14:09AM +0300, Pasi Kärkkäinen wrote: > > > On Tue, May 24, 2011 at 01:54:10PM +0200, Wei Wang2 wrote: > > > > How does this patch work for you? You also need to install latest ATI driver > > > > in guest. > > > > http://lists.xensource.com/archives/html/xen-devel/2010-12/msg00705.html > > > > > > > > > > Hello, > > > > > > Is this patch considered final and good for merging to xen-unstable? > > > > > > Recently many users have asked about Xen VGA passthru so we should > > > get all the related patches merged in to Xen trees! > > > > > > > Ping? > > As I said last time: I think someone needs to gather them together and > repost them all as a series. > Yep, I read your email but forgot to respond.. > Realistically maintainers aren't going to go trawling list archives > trying to figure out which patches are necessary/correct/desirable etc. > Someone who has been following this stuff needs to pickup the relevant > patches and post them as a series and champion/babysit/justify that > series, respond to review comments, repost etc. > I meant the "Ping" more like if Wei thought the patch was correct etc.. > Upthread I see that the particular patch in question breaks the stubdom > build, so my first review comment is "please don't break stubdom". > Yep. I think I'll stand up and collect all the VGA passthru patches, if noone else is willing to do that.. Thanks, -- Pasi > Ian. > > > > -- Pasi > > > > > > > > > Thanks, > > > > > > -- Pasi > > > > > > > > > > Thanks > > > > Wei > > > > > > > > On Tuesday 17 May 2011 06:47:33 Gennady Marchenko wrote: > > > > > Hi all! > > > > > > > > > > I'm very interested with XenVGAPassthrough and tries to do it on my system > > > > > with vt-d support: > > > > > > > > > > CPU: Intel core2duo E8400 > > > > > MB: Asus p5q-vm do > > > > > mem: 8GB > > > > > > > > > > So I'm succeed at Intel IGD: > > > > > > > > > > 00:02.0 VGA compatible controller: Intel Corporation 4 Series Chipset > > > > > Integrated Graphics Controller (rev 03) > > > > > > > > > > with > > > > > > > > > > Debian Sid's XEN 4.1/Linux 2.6.39-rc7+ (from > > > > > git://git.kernel.org/pub/scm/linux/kernel/git/konrad/xen.git > > > >nel.org/pub/scm/linux/kernel/git/konrad/xen.git>) and WinXP SP2 with Intel's > > > > > drivers version 6.14.10.5157 > > > > > > > > > > but no success with two ATI cards: > > > > > > > > > > ATI X800GTO > > > > > ATI 5450 > > > > > (on same m.board) > > > > > > > > > > with empty screen. When I run HVM screen went from "empty" to another > > > > > "empty ", HVM not booting. So I don't know - is there need to do something > > > > > with bios and how I can do it with binary xen. Could you help me with it > > > > > please? > > > > > > > > > > Thanks all for this feature! > > > > > Gennady. > > > > > > > > > > > > > > > > > > > > _______________________________________________ > > > > Xen-devel mailing list > > > > Xen-devel@lists.xensource.com > > > > http://lists.xensource.com/xen-devel > > > > > > _______________________________________________ > > > Xen-devel mailing list > > > Xen-devel@lists.xensource.com > > > http://lists.xensource.com/xen-devel > > > > _______________________________________________ > > Xen-devel mailing list > > Xen-devel@lists.xensource.com > > http://lists.xensource.com/xen-devel > > _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel From xen-devel-bounces@lists.xensource.com Wed Sep 07 10:04:51 2011 Return-path: Envelope-to: www-data@lists.xensource.com Delivery-date: Wed, 07 Sep 2011 10:04:51 -0700 Received: from localhost ([127.0.0.1] helo=lists.colo.xensource.com) by lists.xensource.com with esmtp (Exim 4.43) id 1R1LYP-0007YC-D2; Wed, 07 Sep 2011 10:04:49 -0700 Received: from mail21.messagelabs.com ([85.158.143.35]) by lists.xensource.com with esmtp (Exim 4.43) id 1R1LVa-00074W-23 for xen-devel@lists.xensource.com; Wed, 07 Sep 2011 10:02:16 -0700 X-Env-Sender: jeremy@goop.org X-Msg-Ref: server-8.tower-21.messagelabs.com!1315414894!58097298!1 X-Originating-IP: [74.207.240.146] X-StarScan-Version: 6.3.6; banners=-,-,- X-VirusChecked: Checked Received: (qmail 9288 invoked from network); 7 Sep 2011 17:01:35 -0000 Received: from claw.goop.org (HELO claw.goop.org) (74.207.240.146) by server-8.tower-21.messagelabs.com with DHE-RSA-AES256-SHA encrypted SMTP; 7 Sep 2011 17:01:35 -0000 Received: from saboo.goop.org (unknown [IPv6:2001:470:1f05:899:6801:ccff:fe7b:9751]) (Authenticated sender: smtp-saboo) by claw.goop.org (Postfix) with ESMTPSA id 47A3A9522; Wed, 7 Sep 2011 10:01:48 -0700 (PDT) Received: from saboo.goop.org (localhost [IPv6:::1]) by saboo.goop.org (Postfix) with ESMTP id B90D220929; Wed, 7 Sep 2011 10:01:43 -0700 (PDT) Message-ID: <4E67A377.3090004@goop.org> Date: Wed, 07 Sep 2011 10:01:43 -0700 From: Jeremy Fitzhardinge User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:6.0) Gecko/20110816 Thunderbird/6.0 MIME-Version: 1.0 To: stefano.stabellini@eu.citrix.com References: <1315413571-10938-1-git-send-email-stefano.stabellini@eu.citrix.com> In-Reply-To: <1315413571-10938-1-git-send-email-stefano.stabellini@eu.citrix.com> X-Enigmail-Version: 1.3.1 Content-Type: text/plain; charset=ISO-8859-15 Content-Transfer-Encoding: 7bit Cc: Ian.Campbell@eu.citrix.com, xen-devel@lists.xensource.com, linux-kernel@vger.kernel.org, konrad.wilk@oracle.com Subject: [Xen-devel] Re: [PATCH v3 1/2] xen: add an "highmem" parameter to alloc_xenballooned_pages X-BeenThere: xen-devel@lists.xensource.com X-Mailman-Version: 2.1.5 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xensource.com Errors-To: xen-devel-bounces@lists.xensource.com On 09/07/2011 09:39 AM, stefano.stabellini@eu.citrix.com wrote: > From: Stefano Stabellini > > Add an highmem parameter to alloc_xenballooned_pages, to allow callers to > request lowmem or highmem pages. > > Signed-off-by: Stefano Stabellini > --- > drivers/xen/balloon.c | 12 ++++++++---- > drivers/xen/gntdev.c | 2 +- > include/xen/balloon.h | 3 ++- > 3 files changed, 11 insertions(+), 6 deletions(-) > > diff --git a/drivers/xen/balloon.c b/drivers/xen/balloon.c > index 5dfd8f8..7f7d463 100644 > --- a/drivers/xen/balloon.c > +++ b/drivers/xen/balloon.c > @@ -501,20 +501,24 @@ EXPORT_SYMBOL_GPL(balloon_set_new_target); > * alloc_xenballooned_pages - get pages that have been ballooned out > * @nr_pages: Number of pages to get > * @pages: pages returned > + * @highmem: highmem or lowmem pages > * @return 0 on success, error otherwise > */ > -int alloc_xenballooned_pages(int nr_pages, struct page** pages) > +int alloc_xenballooned_pages(int nr_pages, struct page** pages, bool highmem) > { > int pgno = 0; > struct page* page; > mutex_lock(&balloon_mutex); > while (pgno < nr_pages) { > - page = balloon_retrieve(true); > - if (page) { > + page = balloon_retrieve(highmem); > + if (page && PageHighMem(page) == highmem) { > pages[pgno++] = page; > } else { > enum bp_state st; > - st = decrease_reservation(nr_pages - pgno, GFP_HIGHUSER); > + if (page) > + balloon_append(page); > + st = decrease_reservation(nr_pages - pgno, > + highmem ? GFP_HIGHUSER : GFP_USER); > if (st != BP_DONE) > goto out_undo; > } > diff --git a/drivers/xen/gntdev.c b/drivers/xen/gntdev.c > index f914b26..07a56c2 100644 > --- a/drivers/xen/gntdev.c > +++ b/drivers/xen/gntdev.c > @@ -123,7 +123,7 @@ static struct grant_map *gntdev_alloc_map(struct gntdev_priv *priv, int count) > NULL == add->pages) > goto err; > > - if (alloc_xenballooned_pages(count, add->pages)) > + if (alloc_xenballooned_pages(count, add->pages, 0 /* lowmem */)) If the parameter is "bool" you should pass true/false. But it might be better to just make it take a GFP_ constant directly. J _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel From xen-devel-bounces@lists.xensource.com Wed Sep 07 10:09:14 2011 Return-path: Envelope-to: www-data@lists.xensource.com Delivery-date: Wed, 07 Sep 2011 10:09:14 -0700 Received: from localhost ([127.0.0.1] helo=lists.colo.xensource.com) by lists.xensource.com with esmtp (Exim 4.43) id 1R1Lcf-0007zR-DS; Wed, 07 Sep 2011 10:09:13 -0700 Received: from mail216.messagelabs.com ([85.158.143.99]) by lists.xensource.com with esmtp (Exim 4.43) id 1R1LZk-0007k6-5R for xen-devel@lists.xensource.com; Wed, 07 Sep 2011 10:06:19 -0700 X-Env-Sender: olaf@aepfle.de X-Msg-Ref: server-15.tower-216.messagelabs.com!1315415168!17008009!1 X-Originating-IP: [81.169.146.161] X-StarScan-Version: 6.3.6; banners=-,-,- X-VirusChecked: Checked Received: (qmail 9841 invoked from network); 7 Sep 2011 17:06:08 -0000 Received: from mo-p00-ob.rzone.de (HELO mo-p00-ob.rzone.de) (81.169.146.161) by server-15.tower-216.messagelabs.com with EDH-RSA-DES-CBC3-SHA encrypted SMTP; 7 Sep 2011 17:06:08 -0000 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; t=1315415168; l=4689; s=domk; d=aepfle.de; h=To:From:Date:Subject:Content-Transfer-Encoding:MIME-Version: Content-Type:X-RZG-CLASS-ID:X-RZG-AUTH; bh=jL2R3GOa9y/UgHDitwt7mrgIt8Y=; b=uPkTvo7jrWkoMDaOsy2i1vmXflJscSlW+pWfcwcJson24RxBeDejGBMhIEpRaMtagkQ FrBjUaA1/oulgDpOZW3GJyqA9AJb2YHcOQa7RtFOeGqMvcFbbEVxYrA9rVOVdtXP5k9Vr S4qFiCYGI6XRl0gdGMaS4xQkqj7mOKkrp+c= X-RZG-AUTH: :P2EQZWCpfu+qG7CngxMFH1J+zrwiavkK6tmQaLfmwtM48/lq287pEZIt X-RZG-CLASS-ID: mo00 Received: from probook.site (dslb-084-057-072-233.pools.arcor-ip.net [84.57.72.233]) by smtp.strato.de (fruni mo41) (RZmta 26.6) with (EDH-RSA-DES-CBC3-SHA encrypted) ESMTPA id i0750en87FhTRd for ; Wed, 7 Sep 2011 19:05:58 +0200 (MEST) Received: from probook.site (localhost [IPv6:::1]) by probook.site (Postfix) with ESMTP id 0165818892 for ; Wed, 7 Sep 2011 19:05:57 +0200 (CEST) Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Mercurial-Node: 52e2fd24423147b8ad1384b5e98ce9d78be7d169 Message-Id: <52e2fd24423147b8ad13.1315415157@probook.site> User-Agent: Mercurial-patchbomb/1.7.5 Date: Wed, 07 Sep 2011 19:05:57 +0200 From: Olaf Hering To: xen-devel@lists.xensource.com Subject: [Xen-devel] [PATCH] xenpaging: use batch of pages during final page-in X-BeenThere: xen-devel@lists.xensource.com X-Mailman-Version: 2.1.5 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xensource.com Errors-To: xen-devel-bounces@lists.xensource.com # HG changeset patch # User Olaf Hering # Date 1315415105 -7200 # Node ID 52e2fd24423147b8ad1384b5e98ce9d78be7d169 # Parent 0268e73809532a4a3ca18a075efcee3c62caf458 xenpaging: use batch of pages during final page-in Map up to RING_SIZE pages in exit path to fill the ring instead of populating one page at a time. Signed-off-by: Olaf Hering diff -r 0268e7380953 -r 52e2fd244231 tools/xenpaging/pagein.c --- a/tools/xenpaging/pagein.c +++ b/tools/xenpaging/pagein.c @@ -1,14 +1,16 @@ /* Trigger a page-in in a separate thread-of-execution to avoid deadlock */ #include -#include "xc_private.h" +#include +#include "xenpaging.h" struct page_in_args { domid_t dom; + unsigned long *pagein_queue; xc_interface *xch; }; static struct page_in_args page_in_args; -static unsigned long page_in_gfn; +static unsigned long page_in_request; static unsigned int page_in_possible; static pthread_t page_in_thread; @@ -19,19 +21,28 @@ static void *page_in(void *arg) { struct page_in_args *pia = arg; void *page; - xen_pfn_t gfn; + int i, num; + xen_pfn_t gfns[XENPAGING_PAGEIN_QUEUE_SIZE]; while (1) { pthread_mutex_lock(&page_in_mutex); - while (!page_in_gfn) + while (!page_in_request) pthread_cond_wait(&page_in_cond, &page_in_mutex); - gfn = page_in_gfn; - page_in_gfn = 0; + num = 0; + for (i = 0; i < XENPAGING_PAGEIN_QUEUE_SIZE; i++) + { + if (!pia->pagein_queue[i]) + continue; + gfns[num] = pia->pagein_queue[i]; + pia->pagein_queue[i] = 0; + num++; + } + page_in_request = 0; pthread_mutex_unlock(&page_in_mutex); /* Ignore errors */ - page = xc_map_foreign_pages(pia->xch, pia->dom, PROT_READ, &gfn, 1); + page = xc_map_foreign_pages(pia->xch, pia->dom, PROT_READ, gfns, num); if (page) munmap(page, PAGE_SIZE); } @@ -39,21 +50,22 @@ static void *page_in(void *arg) pthread_exit(NULL); } -void page_in_trigger(unsigned long gfn) +void page_in_trigger(void) { if (!page_in_possible) return; pthread_mutex_lock(&page_in_mutex); - page_in_gfn = gfn; + page_in_request = 1; pthread_mutex_unlock(&page_in_mutex); pthread_cond_signal(&page_in_cond); } -void create_page_in_thread(domid_t domain_id, xc_interface *xch) +void create_page_in_thread(xenpaging_t *paging) { - page_in_args.dom = domain_id; - page_in_args.xch = xch; + page_in_args.dom = paging->mem_event.domain_id; + page_in_args.pagein_queue = paging->pagein_queue; + page_in_args.xch = paging->xc_handle; if (pthread_create(&page_in_thread, NULL, page_in, &page_in_args) == 0) page_in_possible = 1; } diff -r 0268e7380953 -r 52e2fd244231 tools/xenpaging/xenpaging.c --- a/tools/xenpaging/xenpaging.c +++ b/tools/xenpaging/xenpaging.c @@ -648,7 +648,7 @@ int main(int argc, char *argv[]) sigaction(SIGALRM, &act, NULL); /* listen for page-in events to stop pager */ - create_page_in_thread(paging->mem_event.domain_id, xch); + create_page_in_thread(paging); /* Evict pages */ for ( i = 0; i < paging->num_pages; i++ ) @@ -764,16 +764,24 @@ int main(int argc, char *argv[]) /* Write all pages back into the guest */ if ( interrupted == SIGTERM || interrupted == SIGINT ) { + int num = 0; for ( i = 0; i < paging->domain_info->max_pages; i++ ) { if ( test_bit(i, paging->bitmap) ) { - page_in_trigger(i); - break; + paging->pagein_queue[num] = i; + num++; + if ( num == XENPAGING_PAGEIN_QUEUE_SIZE ) + break; } } - /* If no more pages to process, exit loop */ - if ( i == paging->domain_info->max_pages ) + /* + * One more round if there are still pages to process. + * If no more pages to process, exit loop. + */ + if ( num ) + page_in_trigger(); + else if ( i == paging->domain_info->max_pages ) break; } else diff -r 0268e7380953 -r 52e2fd244231 tools/xenpaging/xenpaging.h --- a/tools/xenpaging/xenpaging.h +++ b/tools/xenpaging/xenpaging.h @@ -29,6 +29,8 @@ #include #include +#define XENPAGING_PAGEIN_QUEUE_SIZE 64 + typedef struct mem_event { domid_t domain_id; xc_evtchn *xce_handle; @@ -49,6 +51,7 @@ typedef struct xenpaging { mem_event_t mem_event; int num_pages; int policy_mru_size; + unsigned long pagein_queue[XENPAGING_PAGEIN_QUEUE_SIZE]; } xenpaging_t; @@ -58,8 +61,8 @@ typedef struct xenpaging_victim { } xenpaging_victim_t; -extern void create_page_in_thread(domid_t domain_id, xc_interface *xch); -extern void page_in_trigger(unsigned long gfn); +extern void create_page_in_thread(xenpaging_t *paging); +extern void page_in_trigger(void); #endif // __XEN_PAGING_H__ _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel From xen-devel-bounces@lists.xensource.com Wed Sep 07 10:12:20 2011 Return-path: Envelope-to: www-data@lists.xensource.com Delivery-date: Wed, 07 Sep 2011 10:12:20 -0700 Received: from localhost ([127.0.0.1] helo=lists.colo.xensource.com) by lists.xensource.com with esmtp (Exim 4.43) id 1R1Lff-0008Ov-3J; Wed, 07 Sep 2011 10:12:20 -0700 Received: from mail216.messagelabs.com ([85.158.143.99]) by lists.xensource.com with smtp (Exim 4.43) id 1R1Len-0008C3-5V for xen-devel@lists.xensource.com; Wed, 07 Sep 2011 10:11:26 -0700 X-Env-Sender: avi@redhat.com X-Msg-Ref: server-4.tower-216.messagelabs.com!1315415481!17412093!1 X-Originating-IP: [209.132.183.28] X-StarScan-Version: 6.3.6; banners=-,-,- X-VirusChecked: Checked Received: (qmail 13310 invoked from network); 7 Sep 2011 17:11:21 -0000 Received: from mx1.redhat.com (HELO mx1.redhat.com) (209.132.183.28) by server-4.tower-216.messagelabs.com with SMTP; 7 Sep 2011 17:11:21 -0000 Received: from int-mx09.intmail.prod.int.phx2.redhat.com (int-mx09.intmail.prod.int.phx2.redhat.com [10.5.11.22]) by mx1.redhat.com (8.14.4/8.14.4) with ESMTP id p87H9gLu011287 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Wed, 7 Sep 2011 13:09:42 -0400 Received: from balrog.usersys.redhat.com (dhcp-1-24.tlv.redhat.com [10.35.1.24]) by int-mx09.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP id p87H9bIQ016784; Wed, 7 Sep 2011 13:09:38 -0400 Message-ID: <4E67A551.4000502@redhat.com> Date: Wed, 07 Sep 2011 20:09:37 +0300 From: Avi Kivity User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:6.0) Gecko/20110816 Thunderbird/6.0 MIME-Version: 1.0 To: Don Zickus References: <1314996468.8255.0.camel@twins> <4E614FBD.2030509@goop.org> <20110906151408.GA7459@redhat.com> <4E66615E.8070806@goop.org> <20110906182758.GR5795@redhat.com> <4E66EF86.9070200@redhat.com> <20110907134411.GV5795@redhat.com> <4E678992.5050709@redhat.com> <20110907155657.GX5795@redhat.com> <4E679AF4.50209@redhat.com> <20110907165203.GQ6838@redhat.com> In-Reply-To: <20110907165203.GQ6838@redhat.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Scanned-By: MIMEDefang 2.68 on 10.5.11.22 Cc: Jeremy Fitzhardinge , Marcelo Tosatti , Nick Piggin , KVM , Stefano Stabellini , Peter Zijlstra , the arch/x86 maintainers , Linux Kernel Mailing List , Andi Kleen , Jeremy Fitzhardinge , "H. Peter Anvin" , Ingo Molnar , Linus Torvalds , Xen Devel Subject: [Xen-devel] Re: [PATCH 08/13] xen/pvticketlock: disable interrupts while blocking X-BeenThere: xen-devel@lists.xensource.com X-Mailman-Version: 2.1.5 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xensource.com Errors-To: xen-devel-bounces@lists.xensource.com On 09/07/2011 07:52 PM, Don Zickus wrote: > > > > May I ask how? Detecting a back-to-back NMI? > > Pretty boring actually. Currently we execute an NMI handler until one of > them returns handled. Then we stop. This may cause us to miss an NMI in > the case of multiple NMIs at once. Now we are changing it to execute > _all_ the handlers to make sure we didn't miss one. That's going to be pretty bad for kvm - those handlers become a lot more expensive since they involve reading MSRs. Even worse if we start using NMIs as a wakeup for pv spinlocks as provided by this patchset. > But then the downside > here is we accidentally handle an NMI that was latched. This would cause > a 'Dazed on confused' message as that NMI was already handled by the > previous NMI. > > We are working on an algorithm to detect this condition and flag it > (nothing complicated). But it may never be perfect. > > On the other hand, what else are we going to do with an edge-triggered > shared interrupt line? > How about, during NMI, save %rip to a per-cpu variable. Handle just one cause. If, on the next NMI, we hit the same %rip, assume back-to-back NMI has occured and now handle all causes. -- error compiling committee.c: too many arguments to function _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel From xen-devel-bounces@lists.xensource.com Wed Sep 07 10:14:38 2011 Return-path: Envelope-to: www-data@lists.xensource.com Delivery-date: Wed, 07 Sep 2011 10:14:38 -0700 Received: from localhost ([127.0.0.1] helo=lists.colo.xensource.com) by lists.xensource.com with esmtp (Exim 4.43) id 1R1Lhu-0000LW-4f; Wed, 07 Sep 2011 10:14:38 -0700 Received: from mail182.messagelabs.com ([85.158.139.83]) by lists.xensource.com with esmtp (Exim 4.43) id 1R1LhA-00008Z-Pk for xen-devel@lists.xensource.com; Wed, 07 Sep 2011 10:13:53 -0700 X-Env-Sender: jeremy@goop.org X-Msg-Ref: server-9.tower-182.messagelabs.com!1315415627!17433336!1 X-Originating-IP: [74.207.240.146] X-StarScan-Version: 6.3.6; banners=-,-,- X-VirusChecked: Checked Received: (qmail 21211 invoked from network); 7 Sep 2011 17:13:49 -0000 Received: from claw.goop.org (HELO claw.goop.org) (74.207.240.146) by server-9.tower-182.messagelabs.com with DHE-RSA-AES256-SHA encrypted SMTP; 7 Sep 2011 17:13:49 -0000 Received: from saboo.goop.org (unknown [IPv6:2001:470:1f05:899:6801:ccff:fe7b:9751]) (Authenticated sender: smtp-saboo) by claw.goop.org (Postfix) with ESMTPSA id 4B206958E; Wed, 7 Sep 2011 10:13:46 -0700 (PDT) Received: from saboo.goop.org (localhost [IPv6:::1]) by saboo.goop.org (Postfix) with ESMTP id 250652024D; Wed, 7 Sep 2011 10:13:42 -0700 (PDT) Message-ID: <4E67A646.7000405@goop.org> Date: Wed, 07 Sep 2011 10:13:42 -0700 From: Jeremy Fitzhardinge User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:6.0) Gecko/20110816 Thunderbird/6.0 MIME-Version: 1.0 To: stefano.stabellini@eu.citrix.com References: <1315413571-10938-2-git-send-email-stefano.stabellini@eu.citrix.com> In-Reply-To: <1315413571-10938-2-git-send-email-stefano.stabellini@eu.citrix.com> X-Enigmail-Version: 1.3.1 Content-Type: text/plain; charset=ISO-8859-15 Content-Transfer-Encoding: 7bit Cc: Ian.Campbell@eu.citrix.com, xen-devel@lists.xensource.com, linux-kernel@vger.kernel.org, konrad.wilk@oracle.com Subject: [Xen-devel] Re: [PATCH v3 2/2] xen: modify kernel mappings corresponding to granted pages X-BeenThere: xen-devel@lists.xensource.com X-Mailman-Version: 2.1.5 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xensource.com Errors-To: xen-devel-bounces@lists.xensource.com On 09/07/2011 09:39 AM, stefano.stabellini@eu.citrix.com wrote: > From: Stefano Stabellini > > If we want to use granted pages for AIO, changing the mappings of a user > vma and the corresponding p2m is not enough, we also need to update the > kernel mappings accordingly. > In order to avoid the complexity of dealing with highmem, we allocated > the pages lowmem. > We issue a HYPERVISOR_grant_table_op right away in > m2p_add_override and we remove the mappings using another > HYPERVISOR_grant_table_op in m2p_remove_override. > Considering that m2p_add_override and m2p_remove_override are called > once per page we use multicalls and hypercall batching. > > Use the kmap_op pointer directly as argument to do the mapping as it is > guaranteed to be present up until the unmapping is done. > Before issuing any unmapping multicalls, we need to make sure that the > mapping has already being done, because we need the kmap->handle to be > set correctly. > > Signed-off-by: Stefano Stabellini > --- > arch/x86/include/asm/xen/page.h | 5 ++- > arch/x86/xen/p2m.c | 67 ++++++++++++++++++++++++++++++++------ > drivers/xen/gntdev.c | 27 +++++++++++++++- > drivers/xen/grant-table.c | 4 +- > include/xen/grant_table.h | 1 + > 5 files changed, 89 insertions(+), 15 deletions(-) > > diff --git a/arch/x86/include/asm/xen/page.h b/arch/x86/include/asm/xen/page.h > index 7ff4669..0ce1884 100644 > --- a/arch/x86/include/asm/xen/page.h > +++ b/arch/x86/include/asm/xen/page.h > @@ -12,6 +12,7 @@ > #include > > #include > +#include > #include > > /* Xen machine address */ > @@ -31,8 +32,10 @@ typedef struct xpaddr { > #define INVALID_P2M_ENTRY (~0UL) > #define FOREIGN_FRAME_BIT (1UL<<(BITS_PER_LONG-1)) > #define IDENTITY_FRAME_BIT (1UL<<(BITS_PER_LONG-2)) > +#define GRANT_FRAME_BIT (1UL<<(BITS_PER_LONG-3)) > #define FOREIGN_FRAME(m) ((m) | FOREIGN_FRAME_BIT) > #define IDENTITY_FRAME(m) ((m) | IDENTITY_FRAME_BIT) > +#define GRANT_FRAME(m) ((m) | GRANT_FRAME_BIT) > > /* Maximum amount of memory we can handle in a domain in pages */ > #define MAX_DOMAIN_PAGES \ > @@ -48,7 +51,7 @@ extern unsigned long set_phys_range_identity(unsigned long pfn_s, > unsigned long pfn_e); > > extern int m2p_add_override(unsigned long mfn, struct page *page, > - bool clear_pte); > + struct gnttab_map_grant_ref *kmap_op); > extern int m2p_remove_override(struct page *page, bool clear_pte); > extern struct page *m2p_find_override(unsigned long mfn); > extern unsigned long m2p_find_override_pfn(unsigned long mfn, unsigned long pfn); > diff --git a/arch/x86/xen/p2m.c b/arch/x86/xen/p2m.c > index 58efeb9..6c26ac80 100644 > --- a/arch/x86/xen/p2m.c > +++ b/arch/x86/xen/p2m.c > @@ -161,7 +161,9 @@ > #include > #include > #include > +#include > > +#include "multicalls.h" > #include "xen-ops.h" > > static void __init m2p_override_init(void); > @@ -676,7 +678,8 @@ static unsigned long mfn_hash(unsigned long mfn) > } > > /* Add an MFN override for a particular page */ > -int m2p_add_override(unsigned long mfn, struct page *page, bool clear_pte) > +int m2p_add_override(unsigned long mfn, struct page *page, > + struct gnttab_map_grant_ref *kmap_op) > { > unsigned long flags; > unsigned long pfn; > @@ -699,9 +702,20 @@ int m2p_add_override(unsigned long mfn, struct page *page, bool clear_pte) > if (unlikely(!set_phys_to_machine(pfn, FOREIGN_FRAME(mfn)))) > return -ENOMEM; > > - if (clear_pte && !PageHighMem(page)) > - /* Just zap old mapping for now */ > - pte_clear(&init_mm, address, ptep); > + if (kmap_op != NULL) { > + if (!PageHighMem(page)) { > + struct multicall_space mcs = xen_mc_entry(sizeof(*kmap_op)); > + > + MULTI_grant_table_op(mcs.mc, > + GNTTABOP_map_grant_ref, kmap_op, 1); > + > + xen_mc_issue(PARAVIRT_LAZY_MMU); > + } > + page->private |= GRANT_FRAME_BIT; > + /* let's use dev_bus_addr to record the old mfn instead */ > + kmap_op->dev_bus_addr = page->index; > + page->index = (unsigned long) kmap_op; > + } > spin_lock_irqsave(&m2p_override_lock, flags); > list_add(&page->lru, &m2p_overrides[mfn_hash(mfn)]); > spin_unlock_irqrestore(&m2p_override_lock, flags); > @@ -735,13 +749,44 @@ int m2p_remove_override(struct page *page, bool clear_pte) > spin_lock_irqsave(&m2p_override_lock, flags); > list_del(&page->lru); > spin_unlock_irqrestore(&m2p_override_lock, flags); > - set_phys_to_machine(pfn, page->index); > > - if (clear_pte && !PageHighMem(page)) > - set_pte_at(&init_mm, address, ptep, > - pfn_pte(pfn, PAGE_KERNEL)); > - /* No tlb flush necessary because the caller already > - * left the pte unmapped. */ > + if (clear_pte) { > + struct gnttab_map_grant_ref *map_op = > + (struct gnttab_map_grant_ref *) page->index; > + set_phys_to_machine(pfn, map_op->dev_bus_addr); > + if (!PageHighMem(page)) { > + struct multicall_space mcs = > + xen_mc_entry(sizeof(struct gnttab_unmap_grant_ref)); > + struct gnttab_unmap_grant_ref *unmap_op = mcs.args; > + > + /* > + * Has the grant_op mapping multicall being issued? If not, > + * make sure it is called now. > + */ > + if (map_op->handle == -1) > + xen_mc_flush(); Hm, this will end up flushing the empty uninitialized entry you just added, which also implicitly frees the space, so all the stuff below is - at best - a noop. But also, this pattern of getting results back from batched calls is unusual - actually, I think this is unique. If you have batched up a map operation which has its map_op args allocated from the multicall buffer, then the flush will implicitly free them as well, so it isn't valid to read back from the structure later on. If you want to have an args structure you can use once the hypercall has been issued, you need to manually manage its lifetime. > + if (map_op->handle == -1) { > + printk(KERN_WARNING "m2p_remove_override: pfn %lx mfn %lx, " > + "failed to modify kernel mappings", pfn, mfn); > + return -1; > + } > + > + unmap_op->host_addr = map_op->host_addr; > + unmap_op->handle = map_op->handle; > + unmap_op->dev_bus_addr = 0; > + > + MULTI_grant_table_op(mcs.mc, > + GNTTABOP_unmap_grant_ref, unmap_op, 1); > + > + xen_mc_issue(PARAVIRT_LAZY_MMU); > + > + set_pte_at(&init_mm, address, ptep, > + pfn_pte(pfn, PAGE_KERNEL)); > + __flush_tlb_single(address); > + map_op->host_addr = 0; > + } > + } else > + set_phys_to_machine(pfn, page->index); > > return 0; > } > @@ -758,7 +803,7 @@ struct page *m2p_find_override(unsigned long mfn) > spin_lock_irqsave(&m2p_override_lock, flags); > > list_for_each_entry(p, bucket, lru) { > - if (p->private == mfn) { > + if ((p->private & (~GRANT_FRAME_BIT)) == mfn) { > ret = p; > break; > } > diff --git a/drivers/xen/gntdev.c b/drivers/xen/gntdev.c > index 07a56c2..783aaad 100644 > --- a/drivers/xen/gntdev.c > +++ b/drivers/xen/gntdev.c > @@ -83,6 +83,7 @@ struct grant_map { > struct ioctl_gntdev_grant_ref *grants; > struct gnttab_map_grant_ref *map_ops; > struct gnttab_unmap_grant_ref *unmap_ops; > + struct gnttab_map_grant_ref *kmap_ops; > struct page **pages; > }; > > @@ -116,10 +117,12 @@ static struct grant_map *gntdev_alloc_map(struct gntdev_priv *priv, int count) > add->grants = kzalloc(sizeof(add->grants[0]) * count, GFP_KERNEL); > add->map_ops = kzalloc(sizeof(add->map_ops[0]) * count, GFP_KERNEL); > add->unmap_ops = kzalloc(sizeof(add->unmap_ops[0]) * count, GFP_KERNEL); > + add->kmap_ops = kzalloc(sizeof(add->kmap_ops[0]) * count, GFP_KERNEL); > add->pages = kzalloc(sizeof(add->pages[0]) * count, GFP_KERNEL); > if (NULL == add->grants || > NULL == add->map_ops || > NULL == add->unmap_ops || > + NULL == add->kmap_ops || > NULL == add->pages) > goto err; > > @@ -129,6 +132,7 @@ static struct grant_map *gntdev_alloc_map(struct gntdev_priv *priv, int count) > for (i = 0; i < count; i++) { > add->map_ops[i].handle = -1; > add->unmap_ops[i].handle = -1; > + add->kmap_ops[i].handle = -1; > } > > add->index = 0; > @@ -142,6 +146,7 @@ err: > kfree(add->grants); > kfree(add->map_ops); > kfree(add->unmap_ops); > + kfree(add->kmap_ops); > kfree(add); > return NULL; > } > @@ -243,10 +248,30 @@ static int map_grant_pages(struct grant_map *map) > gnttab_set_unmap_op(&map->unmap_ops[i], addr, > map->flags, -1 /* handle */); > } > + } else { > + for (i = 0; i < map->count; i++) { > + unsigned level; > + unsigned long address = (unsigned long) > + pfn_to_kaddr(page_to_pfn(map->pages[i])); > + pte_t *ptep; > + u64 pte_maddr = 0; > + if (!PageHighMem(map->pages[i])) { > + ptep = lookup_address(address, &level); > + pte_maddr = > + arbitrary_virt_to_machine(ptep).maddr; > + } > + gnttab_set_map_op(&map->kmap_ops[i], pte_maddr, > + map->flags | > + GNTMAP_host_map | > + GNTMAP_contains_pte, > + map->grants[i].ref, > + map->grants[i].domid); > + } > } > > pr_debug("map %d+%d\n", map->index, map->count); > - err = gnttab_map_refs(map->map_ops, map->pages, map->count); > + err = gnttab_map_refs(map->map_ops, use_ptemod ? map->kmap_ops : NULL, > + map->pages, map->count); > if (err) > return err; > > diff --git a/drivers/xen/grant-table.c b/drivers/xen/grant-table.c > index 4f44b34..ed6622f 100644 > --- a/drivers/xen/grant-table.c > +++ b/drivers/xen/grant-table.c > @@ -448,6 +448,7 @@ unsigned int gnttab_max_grant_frames(void) > EXPORT_SYMBOL_GPL(gnttab_max_grant_frames); > > int gnttab_map_refs(struct gnttab_map_grant_ref *map_ops, > + struct gnttab_map_grant_ref *kmap_ops, > struct page **pages, unsigned int count) Formatting looks wonky here. > { > int i, ret; > @@ -488,8 +489,7 @@ int gnttab_map_refs(struct gnttab_map_grant_ref *map_ops, > */ > return -EOPNOTSUPP; > } > - ret = m2p_add_override(mfn, pages[i], > - map_ops[i].flags & GNTMAP_contains_pte); > + ret = m2p_add_override(mfn, pages[i], &kmap_ops[i]); > if (ret) > return ret; > } > diff --git a/include/xen/grant_table.h b/include/xen/grant_table.h > index b1fab6b..6b99bfb 100644 > --- a/include/xen/grant_table.h > +++ b/include/xen/grant_table.h > @@ -156,6 +156,7 @@ unsigned int gnttab_max_grant_frames(void); > #define gnttab_map_vaddr(map) ((void *)(map.host_virt_addr)) > > int gnttab_map_refs(struct gnttab_map_grant_ref *map_ops, > + struct gnttab_map_grant_ref *kmap_ops, > struct page **pages, unsigned int count); > int gnttab_unmap_refs(struct gnttab_unmap_grant_ref *unmap_ops, > struct page **pages, unsigned int count); J _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel From xen-devel-bounces@lists.xensource.com Wed Sep 07 10:18:06 2011 Return-path: Envelope-to: www-data@lists.xensource.com Delivery-date: Wed, 07 Sep 2011 10:18:06 -0700 Received: from localhost ([127.0.0.1] helo=lists.colo.xensource.com) by lists.xensource.com with esmtp (Exim 4.43) id 1R1LlG-0000mD-0Z; Wed, 07 Sep 2011 10:18:06 -0700 Received: from mail27.messagelabs.com ([193.109.254.147]) by lists.xensource.com with esmtp (Exim 4.43) id 1R1Lka-0000ZV-Jj for xen-devel@lists.xensource.com; Wed, 07 Sep 2011 10:17:25 -0700 X-Env-Sender: jeremy@goop.org X-Msg-Ref: server-9.tower-27.messagelabs.com!1315415825!43570282!1 X-Originating-IP: [74.207.240.146] X-StarScan-Version: 6.3.6; banners=-,-,- X-VirusChecked: Checked Received: (qmail 30448 invoked from network); 7 Sep 2011 17:17:06 -0000 Received: from claw.goop.org (HELO claw.goop.org) (74.207.240.146) by server-9.tower-27.messagelabs.com with DHE-RSA-AES256-SHA encrypted SMTP; 7 Sep 2011 17:17:06 -0000 Received: from saboo.goop.org (unknown [IPv6:2001:470:1f05:899:6801:ccff:fe7b:9751]) (Authenticated sender: smtp-saboo) by claw.goop.org (Postfix) with ESMTPSA id 48B2695C3; Wed, 7 Sep 2011 10:17:19 -0700 (PDT) Received: from saboo.goop.org (localhost [IPv6:::1]) by saboo.goop.org (Postfix) with ESMTP id C631D2024D; Wed, 7 Sep 2011 10:17:14 -0700 (PDT) Message-ID: <4E67A71A.5070903@goop.org> Date: Wed, 07 Sep 2011 10:17:14 -0700 From: Jeremy Fitzhardinge User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:6.0) Gecko/20110816 Thunderbird/6.0 MIME-Version: 1.0 To: Avi Kivity References: <1314996468.8255.0.camel@twins> <4E614FBD.2030509@goop.org> <20110906151408.GA7459@redhat.com> <4E66615E.8070806@goop.org> <20110906182758.GR5795@redhat.com> <4E66EF86.9070200@redhat.com> <20110907134411.GV5795@redhat.com> <4E678992.5050709@redhat.com> <20110907155657.GX5795@redhat.com> <4E679AF4.50209@redhat.com> <20110907165203.GQ6838@redhat.com> <4E67A551.4000502@redhat.com> In-Reply-To: <4E67A551.4000502@redhat.com> X-Enigmail-Version: 1.3.1 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: Don Zickus , Marcelo Tosatti , Nick Piggin , KVM , Stefano Stabellini , Peter Zijlstra , the arch/x86 maintainers , Linux Kernel Mailing List , Andi Kleen , Jeremy Fitzhardinge , "H. Peter Anvin" , Ingo Molnar , Linus Torvalds , Xen Devel Subject: [Xen-devel] Re: [PATCH 08/13] xen/pvticketlock: disable interrupts while blocking X-BeenThere: xen-devel@lists.xensource.com X-Mailman-Version: 2.1.5 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xensource.com Errors-To: xen-devel-bounces@lists.xensource.com On 09/07/2011 10:09 AM, Avi Kivity wrote: > On 09/07/2011 07:52 PM, Don Zickus wrote: >> > >> > May I ask how? Detecting a back-to-back NMI? >> >> Pretty boring actually. Currently we execute an NMI handler until >> one of >> them returns handled. Then we stop. This may cause us to miss an >> NMI in >> the case of multiple NMIs at once. Now we are changing it to execute >> _all_ the handlers to make sure we didn't miss one. > > That's going to be pretty bad for kvm - those handlers become a lot > more expensive since they involve reading MSRs. How often are you going to get NMIs in a kvm guest? > Even worse if we start using NMIs as a wakeup for pv spinlocks as > provided by this patchset. Hm, I'm interested to know what you're thinking in more detail. Can you leave an NMI pending before you block in the same way you can with "sti;halt" with normal interrupts? I was thinking you might want to do something with monitor/mwait to implement the blocking/kick ops. (Handwave) J _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel From xen-devel-bounces@lists.xensource.com Wed Sep 07 10:23:03 2011 Return-path: Envelope-to: www-data@lists.xensource.com Delivery-date: Wed, 07 Sep 2011 10:23:03 -0700 Received: from localhost ([127.0.0.1] helo=lists.colo.xensource.com) by lists.xensource.com with esmtp (Exim 4.43) id 1R1Lq3-0001Jb-4c; Wed, 07 Sep 2011 10:23:03 -0700 Received: from mail174.messagelabs.com ([85.158.138.51]) by lists.xensource.com with smtp (Exim 4.43) id 1R1Lpb-000167-SH for xen-devel@lists.xensource.com; Wed, 07 Sep 2011 10:22:36 -0700 X-Env-Sender: dzickus@redhat.com X-Msg-Ref: server-12.tower-174.messagelabs.com!1315416151!30585637!1 X-Originating-IP: [209.132.183.28] X-StarScan-Version: 6.3.6; banners=-,-,- X-VirusChecked: Checked Received: (qmail 15814 invoked from network); 7 Sep 2011 17:22:32 -0000 Received: from mx1.redhat.com (HELO mx1.redhat.com) (209.132.183.28) by server-12.tower-174.messagelabs.com with SMTP; 7 Sep 2011 17:22:32 -0000 Received: from int-mx10.intmail.prod.int.phx2.redhat.com (int-mx10.intmail.prod.int.phx2.redhat.com [10.5.11.23]) by mx1.redhat.com (8.14.4/8.14.4) with ESMTP id p87HLI3A016732 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Wed, 7 Sep 2011 13:21:19 -0400 Received: from redhat.com (dhcp-100-19-141.bos.redhat.com [10.16.19.141]) by int-mx10.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with SMTP id p87HLHkf003029; Wed, 7 Sep 2011 13:21:17 -0400 Date: Wed, 7 Sep 2011 13:21:17 -0400 From: Don Zickus To: Avi Kivity Message-ID: <20110907172117.GY5795@redhat.com> References: <20110906151408.GA7459@redhat.com> <4E66615E.8070806@goop.org> <20110906182758.GR5795@redhat.com> <4E66EF86.9070200@redhat.com> <20110907134411.GV5795@redhat.com> <4E678992.5050709@redhat.com> <20110907155657.GX5795@redhat.com> <4E679AF4.50209@redhat.com> <20110907165203.GQ6838@redhat.com> <4E67A551.4000502@redhat.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <4E67A551.4000502@redhat.com> User-Agent: Mutt/1.5.21 (2010-09-15) X-Scanned-By: MIMEDefang 2.68 on 10.5.11.23 Cc: Jeremy Fitzhardinge , Marcelo Tosatti , Nick Piggin , KVM , Stefano Stabellini , Peter Zijlstra , the arch/x86 maintainers , Linux Kernel Mailing List , Andi Kleen , Jeremy Fitzhardinge , "H. Peter Anvin" , Ingo Molnar , Linus Torvalds , Xen Devel Subject: [Xen-devel] Re: [PATCH 08/13] xen/pvticketlock: disable interrupts while blocking X-BeenThere: xen-devel@lists.xensource.com X-Mailman-Version: 2.1.5 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xensource.com Errors-To: xen-devel-bounces@lists.xensource.com On Wed, Sep 07, 2011 at 08:09:37PM +0300, Avi Kivity wrote: > On 09/07/2011 07:52 PM, Don Zickus wrote: > >> > >> May I ask how? Detecting a back-to-back NMI? > > > >Pretty boring actually. Currently we execute an NMI handler until one of > >them returns handled. Then we stop. This may cause us to miss an NMI in > >the case of multiple NMIs at once. Now we are changing it to execute > >_all_ the handlers to make sure we didn't miss one. > > That's going to be pretty bad for kvm - those handlers become a lot > more expensive since they involve reading MSRs. Even worse if we > start using NMIs as a wakeup for pv spinlocks as provided by this > patchset. Oh. > > >But then the downside > >here is we accidentally handle an NMI that was latched. This would cause > >a 'Dazed on confused' message as that NMI was already handled by the > >previous NMI. > > > >We are working on an algorithm to detect this condition and flag it > >(nothing complicated). But it may never be perfect. > > > >On the other hand, what else are we going to do with an edge-triggered > >shared interrupt line? > > > > How about, during NMI, save %rip to a per-cpu variable. Handle just > one cause. If, on the next NMI, we hit the same %rip, assume > back-to-back NMI has occured and now handle all causes. I had a similar idea a couple of months ago while debugging a continuous flow of back-to-back NMIs from a stress-test perf application and I couldn't get it to work. But let me try it again, because it does make sense as an optimization. Thanks, Don _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel From xen-devel-bounces@lists.xensource.com Wed Sep 07 10:28:15 2011 Return-path: Envelope-to: www-data@lists.xensource.com Delivery-date: Wed, 07 Sep 2011 10:28:15 -0700 Received: from localhost ([127.0.0.1] helo=lists.colo.xensource.com) by lists.xensource.com with esmtp (Exim 4.43) id 1R1Lv4-0001o5-NJ; Wed, 07 Sep 2011 10:28:14 -0700 Received: from mail182.messagelabs.com ([85.158.139.83]) by lists.xensource.com with esmtp (Exim 4.43) id 1R1LuL-0001a3-58 for xen-devel@lists.xensource.com; Wed, 07 Sep 2011 10:27:30 -0700 X-Env-Sender: jeremy@goop.org X-Msg-Ref: server-7.tower-182.messagelabs.com!1315416444!12432450!1 X-Originating-IP: [74.207.240.146] X-StarScan-Version: 6.3.6; banners=-,-,- X-VirusChecked: Checked Received: (qmail 7717 invoked from network); 7 Sep 2011 17:27:25 -0000 Received: from claw.goop.org (HELO claw.goop.org) (74.207.240.146) by server-7.tower-182.messagelabs.com with DHE-RSA-AES256-SHA encrypted SMTP; 7 Sep 2011 17:27:25 -0000 Received: from saboo.goop.org (unknown [IPv6:2001:470:1f05:899:6801:ccff:fe7b:9751]) (Authenticated sender: smtp-saboo) by claw.goop.org (Postfix) with ESMTPSA id 2CD8E8F1C; Wed, 7 Sep 2011 10:27:20 -0700 (PDT) Received: from saboo.goop.org (localhost [IPv6:::1]) by saboo.goop.org (Postfix) with ESMTP id DA5BD2024D; Wed, 7 Sep 2011 10:27:14 -0700 (PDT) Message-ID: <4E67A972.6030909@goop.org> Date: Wed, 07 Sep 2011 10:27:14 -0700 From: Jeremy Fitzhardinge User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:6.0) Gecko/20110816 Thunderbird/6.0 MIME-Version: 1.0 To: "Cihula, Joseph" Subject: Re: [Xen-devel] RE: [PATCH 2/7] x86, acpi, tboot: Have a ACPI sleep override instead of calling tboot_sleep. References: <1314815484-4668-1-git-send-email-konrad.wilk@oracle.com> <1314815484-4668-3-git-send-email-konrad.wilk@oracle.com> <9F57BF860713DF4BA3EFA4F8C6DFEDAC16F3F524@ORSMSX101.amr.corp.intel.com> In-Reply-To: <9F57BF860713DF4BA3EFA4F8C6DFEDAC16F3F524@ORSMSX101.amr.corp.intel.com> X-Enigmail-Version: 1.3.1 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: "Brown, Len" , "Tian, Kevin" , "xen-devel@lists.xensource.com" , "keir@xen.org" , Konrad Rzeszutek Wilk , "Wang, Shane" , "x86@kernel.org" , "linux-acpi@vger.kernel.org" , "tboot-devel@lists.sourceforge.net" , "liang.tang@oracle.com" , "Yu, Ke" , "hpa@zytor.com" , "tglx@linutronix.de" , "linux-pm@lists.linux-foundation.org" X-BeenThere: xen-devel@lists.xensource.com X-Mailman-Version: 2.1.5 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xensource.com Errors-To: xen-devel-bounces@lists.xensource.com On 09/06/2011 09:20 PM, Cihula, Joseph wrote: >> From: Konrad Rzeszutek Wilk [mailto:konrad.wilk@oracle.com] >> Sent: Wednesday, August 31, 2011 11:31 AM >> >> The ACPI suspend path makes a call to tboot_sleep right before it writes the PM1A, PM1B values. We >> replace the direct call to tboot via an registration callback similar to __acpi_register_gsi. >> >> CC: Thomas Gleixner >> CC: "H. Peter Anvin" >> CC: x86@kernel.org >> CC: Len Brown >> CC: Joseph Cihula >> CC: Shane Wang >> CC: xen-devel@lists.xensource.com >> CC: linux-pm@lists.linux-foundation.org >> CC: tboot-devel@lists.sourceforge.net >> CC: linux-acpi@vger.kernel.org >> Signed-off-by: Konrad Rzeszutek Wilk >> --- >> arch/x86/include/asm/acpi.h | 3 +++ >> arch/x86/kernel/acpi/boot.c | 3 +++ >> arch/x86/kernel/tboot.c | 13 +++++++++---- >> drivers/acpi/acpica/hwsleep.c | 12 ++++++++++-- >> include/linux/tboot.h | 3 ++- >> 5 files changed, 27 insertions(+), 7 deletions(-) >> >> diff --git a/arch/x86/include/asm/acpi.h b/arch/x86/include/asm/acpi.h index 610001d..49864a1 >> 100644 >> --- a/arch/x86/include/asm/acpi.h >> +++ b/arch/x86/include/asm/acpi.h >> @@ -98,6 +98,9 @@ void acpi_pic_sci_set_trigger(unsigned int, u16); extern int >> (*__acpi_register_gsi)(struct device *dev, u32 gsi, >> int trigger, int polarity); >> >> +extern int (*__acpi_override_sleep)(u8 sleep_state, u32 pm1a_ctrl, >> + u32 pm1b_ctrl, bool *skip_rest); >> + >> static inline void disable_acpi(void) >> { >> acpi_disabled = 1; >> diff --git a/arch/x86/kernel/acpi/boot.c b/arch/x86/kernel/acpi/boot.c index 4558f0d..d191b4c >> 100644 >> --- a/arch/x86/kernel/acpi/boot.c >> +++ b/arch/x86/kernel/acpi/boot.c >> @@ -552,6 +552,9 @@ static int acpi_register_gsi_ioapic(struct device *dev, u32 gsi, int >> (*__acpi_register_gsi)(struct device *dev, u32 gsi, >> int trigger, int polarity) = acpi_register_gsi_pic; >> >> +int (*__acpi_override_sleep)(u8 sleep_state, u32 pm1a_ctrl, >> + u32 pm1b_ctrl, bool *skip_rest) = NULL; >> + >> /* >> * success: return IRQ number (>=0) >> * failure: return < 0 >> diff --git a/arch/x86/kernel/tboot.c b/arch/x86/kernel/tboot.c index 30ac65d..a18070c 100644 >> --- a/arch/x86/kernel/tboot.c >> +++ b/arch/x86/kernel/tboot.c >> @@ -41,7 +41,7 @@ >> #include >> #include >> #include >> - >> +#include >> #include "acpi/realmode/wakeup.h" >> >> /* Global pointer to shared data; NULL means no measured launch. */ @@ -270,7 +270,8 @@ static >> void tboot_copy_fadt(const struct acpi_table_fadt *fadt) >> offsetof(struct acpi_table_facs, firmware_waking_vector); } >> >> -void tboot_sleep(u8 sleep_state, u32 pm1a_control, u32 pm1b_control) >> +int tboot_sleep(u8 sleep_state, u32 pm1a_control, u32 pm1b_control, >> + bool *skip_rest) > Don't you need to use the 'unused' attrib on skip_rest in order to prevent compiler warnings? No, gcc doesn't warn about unused parameters. J _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel From xen-devel-bounces@lists.xensource.com Wed Sep 07 10:29:52 2011 Return-path: Envelope-to: www-data@lists.xensource.com Delivery-date: Wed, 07 Sep 2011 10:29:52 -0700 Received: from localhost ([127.0.0.1] helo=lists.colo.xensource.com) by lists.xensource.com with esmtp (Exim 4.43) id 1R1Lwe-0002EI-7W; Wed, 07 Sep 2011 10:29:52 -0700 Received: from mail216.messagelabs.com ([85.158.143.99]) by lists.xensource.com with esmtp (Exim 4.43) id 1R1LwB-00021V-Ie for xen-devel@lists.xensource.com; Wed, 07 Sep 2011 10:29:24 -0700 X-Env-Sender: jeremy@goop.org X-Msg-Ref: server-5.tower-216.messagelabs.com!1315416558!16946418!1 X-Originating-IP: [74.207.240.146] X-StarScan-Version: 6.3.6; banners=-,-,- X-VirusChecked: Checked Received: (qmail 25563 invoked from network); 7 Sep 2011 17:29:20 -0000 Received: from claw.goop.org (HELO claw.goop.org) (74.207.240.146) by server-5.tower-216.messagelabs.com with DHE-RSA-AES256-SHA encrypted SMTP; 7 Sep 2011 17:29:20 -0000 Received: from saboo.goop.org (unknown [IPv6:2001:470:1f05:899:6801:ccff:fe7b:9751]) (Authenticated sender: smtp-saboo) by claw.goop.org (Postfix) with ESMTPSA id A5CFC55; Wed, 7 Sep 2011 10:29:17 -0700 (PDT) Received: from saboo.goop.org (localhost [IPv6:::1]) by saboo.goop.org (Postfix) with ESMTP id 3F07A20929; Wed, 7 Sep 2011 10:29:11 -0700 (PDT) Message-ID: <4E67A9E7.2020802@goop.org> Date: Wed, 07 Sep 2011 10:29:11 -0700 From: Jeremy Fitzhardinge User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:6.0) Gecko/20110816 Thunderbird/6.0 MIME-Version: 1.0 To: "Cihula, Joseph" Subject: Re: [Xen-devel] RE: [PATCH 5/7] xen/acpi: Domain0 acpi parser related platform hypercall References: <1314815484-4668-1-git-send-email-konrad.wilk@oracle.com> <1314815484-4668-6-git-send-email-konrad.wilk@oracle.com> <9F57BF860713DF4BA3EFA4F8C6DFEDAC16F3F665@ORSMSX101.amr.corp.intel.com> In-Reply-To: <9F57BF860713DF4BA3EFA4F8C6DFEDAC16F3F665@ORSMSX101.amr.corp.intel.com> X-Enigmail-Version: 1.3.1 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: "Brown, Len" , "Tian, Kevin" , "xen-devel@lists.xensource.com" , "keir@xen.org" , Fitzhardinge , Konrad Rzeszutek Wilk , "Wang, Shane" , "x86@kernel.org" , Jeremy@goop.org, "linux-acpi@vger.kernel.org" , "tboot-devel@lists.sourceforge.net" , "liang.tang@oracle.com" , "Yu, Ke" , "hpa@zytor.com" , "tglx@linutronix.de" , "linux-pm@lists.linux-foundation.org" X-BeenThere: xen-devel@lists.xensource.com X-Mailman-Version: 2.1.5 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xensource.com Errors-To: xen-devel-bounces@lists.xensource.com On 09/06/2011 10:50 PM, Cihula, Joseph wrote: >> From: Konrad Rzeszutek Wilk [mailto:konrad.wilk@oracle.com] >> Sent: Wednesday, August 31, 2011 11:31 AM >> >> From: Yu Ke >> >> This patches implements the xen_platform_op hypercall, to pass the parsed ACPI info to hypervisor. >> >> Signed-off-by: Yu Ke >> Signed-off-by: Tian Kevin >> Signed-off-by: Jeremy Fitzhardinge >> [v1: Added DEFINE_GUEST.. in appropiate headers] >> [v2: Ripped out typedefs] >> Signed-off-by: Konrad Rzeszutek Wilk >> --- >> arch/ia64/include/asm/xen/interface.h | 1 + >> arch/x86/include/asm/xen/interface.h | 1 + >> include/xen/interface/platform.h | 320 +++++++++++++++++++++++++++++++++ >> include/xen/interface/xen.h | 1 + >> 4 files changed, 323 insertions(+), 0 deletions(-) create mode 100644 >> include/xen/interface/platform.h >> >> diff --git a/arch/ia64/include/asm/xen/interface.h b/arch/ia64/include/asm/xen/interface.h >> index e951e74..1d2427d 100644 >> --- a/arch/ia64/include/asm/xen/interface.h >> +++ b/arch/ia64/include/asm/xen/interface.h >> @@ -76,6 +76,7 @@ DEFINE_GUEST_HANDLE(char); DEFINE_GUEST_HANDLE(int); >> DEFINE_GUEST_HANDLE(long); DEFINE_GUEST_HANDLE(void); >> +DEFINE_GUEST_HANDLE(uint64_t); >> >> typedef unsigned long xen_pfn_t; >> DEFINE_GUEST_HANDLE(xen_pfn_t); >> diff --git a/arch/x86/include/asm/xen/interface.h b/arch/x86/include/asm/xen/interface.h >> index 5d4922a..a1f2db5 100644 >> --- a/arch/x86/include/asm/xen/interface.h >> +++ b/arch/x86/include/asm/xen/interface.h >> @@ -55,6 +55,7 @@ DEFINE_GUEST_HANDLE(char); DEFINE_GUEST_HANDLE(int); >> DEFINE_GUEST_HANDLE(long); DEFINE_GUEST_HANDLE(void); >> +DEFINE_GUEST_HANDLE(uint64_t); >> #endif >> >> #ifndef HYPERVISOR_VIRT_START >> diff --git a/include/xen/interface/platform.h b/include/xen/interface/platform.h >> new file mode 100644 >> index 0000000..c168468 >> --- /dev/null >> +++ b/include/xen/interface/platform.h > Why are you adding so many new hypercalls that aren't being used in this patchset? May as well bring in all the platform-related hypercall definitions at once rather than be piecemeal. >> @@ -0,0 +1,320 @@ >> +/********************************************************************** >> +******** >> + * platform.h >> + * >> + * Hardware platform operations. Intended for use by domain-0 kernel. >> + * >> + * Permission is hereby granted, free of charge, to any person >> +obtaining a copy >> + * of this software and associated documentation files (the >> +"Software"), to >> + * deal in the Software without restriction, including without >> +limitation the >> + * rights to use, copy, modify, merge, publish, distribute, sublicense, >> +and/or >> + * sell copies of the Software, and to permit persons to whom the >> +Software is >> + * furnished to do so, subject to the following conditions: >> + * >> + * The above copyright notice and this permission notice shall be >> +included in >> + * all copies or substantial portions of the Software. >> + * >> + * THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, >> +EXPRESS OR >> + * IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF >> +MERCHANTABILITY, >> + * FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT >> +SHALL THE >> + * AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR >> +OTHER >> + * LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, >> +ARISING >> + * FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER >> + * DEALINGS IN THE SOFTWARE. >> + * >> + * Copyright (c) 2002-2006, K Fraser >> + */ >> + >> +#ifndef __XEN_PUBLIC_PLATFORM_H__ >> +#define __XEN_PUBLIC_PLATFORM_H__ >> + >> +#include "xen.h" >> + >> +#define XENPF_INTERFACE_VERSION 0x03000001 >> + >> +/* >> + * Set clock such that it would read after 00:00:00 UTC, >> + * 1 January, 1970 if the current system time was . >> + */ >> +#define XENPF_settime 17 >> +struct xenpf_settime { >> + /* IN variables. */ >> + uint32_t secs; >> + uint32_t nsecs; >> + uint64_t system_time; >> +}; >> +DEFINE_GUEST_HANDLE_STRUCT(xenpf_settime_t); >> + >> +/* >> + * Request memory range (@mfn, @mfn+@nr_mfns-1) to have type @type. >> + * On x86, @type is an architecture-defined MTRR memory type. >> + * On success, returns the MTRR that was used (@reg) and a handle that >> +can >> + * be passed to XENPF_DEL_MEMTYPE to accurately tear down the new setting. >> + * (x86-specific). >> + */ >> +#define XENPF_add_memtype 31 >> +struct xenpf_add_memtype { >> + /* IN variables. */ >> + unsigned long mfn; >> + uint64_t nr_mfns; >> + uint32_t type; >> + /* OUT variables. */ >> + uint32_t handle; >> + uint32_t reg; >> +}; >> +DEFINE_GUEST_HANDLE_STRUCT(xenpf_add_memtype_t); >> + >> +/* >> + * Tear down an existing memory-range type. If @handle is remembered >> +then it >> + * should be passed in to accurately tear down the correct setting (in >> +case >> + * of overlapping memory regions with differing types). If it is not >> +known >> + * then @handle should be set to zero. In all cases @reg must be set. >> + * (x86-specific). >> + */ >> +#define XENPF_del_memtype 32 >> +struct xenpf_del_memtype { >> + /* IN variables. */ >> + uint32_t handle; >> + uint32_t reg; >> +}; >> +DEFINE_GUEST_HANDLE_STRUCT(xenpf_del_memtype_t); >> + >> +/* Read current type of an MTRR (x86-specific). */ >> +#define XENPF_read_memtype 33 >> +struct xenpf_read_memtype { >> + /* IN variables. */ >> + uint32_t reg; >> + /* OUT variables. */ >> + unsigned long mfn; >> + uint64_t nr_mfns; >> + uint32_t type; >> +}; >> +DEFINE_GUEST_HANDLE_STRUCT(xenpf_read_memtype_t); >> + >> +#define XENPF_microcode_update 35 >> +struct xenpf_microcode_update { >> + /* IN variables. */ >> + GUEST_HANDLE(void) data; /* Pointer to microcode data */ >> + uint32_t length; /* Length of microcode data. */ >> +}; >> +DEFINE_GUEST_HANDLE_STRUCT(xenpf_microcode_update_t); >> + >> +#define XENPF_platform_quirk 39 >> +#define QUIRK_NOIRQBALANCING 1 /* Do not restrict IO-APIC RTE targets */ >> +#define QUIRK_IOAPIC_BAD_REGSEL 2 /* IO-APIC REGSEL forgets its value */ >> +#define QUIRK_IOAPIC_GOOD_REGSEL 3 /* IO-APIC REGSEL behaves properly */ >> +struct xenpf_platform_quirk { >> + /* IN variables. */ >> + uint32_t quirk_id; >> +}; >> +DEFINE_GUEST_HANDLE_STRUCT(xenpf_platform_quirk_t); >> + >> +#define XENPF_firmware_info 50 >> +#define XEN_FW_DISK_INFO 1 /* from int 13 AH=08/41/48 */ >> +#define XEN_FW_DISK_MBR_SIGNATURE 2 /* from MBR offset 0x1b8 */ >> +#define XEN_FW_VBEDDC_INFO 3 /* from int 10 AX=4f15 */ >> +struct xenpf_firmware_info { >> + /* IN variables. */ >> + uint32_t type; >> + uint32_t index; >> + /* OUT variables. */ >> + union { >> + struct { >> + /* Int13, Fn48: Check Extensions Present. */ >> + uint8_t device; /* %dl: bios device number */ >> + uint8_t version; /* %ah: major version */ >> + uint16_t interface_support; /* %cx: support bitmap */ >> + /* Int13, Fn08: Legacy Get Device Parameters. */ >> + uint16_t legacy_max_cylinder; /* %cl[7:6]:%ch: max cyl # */ >> + uint8_t legacy_max_head; /* %dh: max head # */ >> + uint8_t legacy_sectors_per_track; /* %cl[5:0]: max sector # */ >> + /* Int13, Fn41: Get Device Parameters (as filled into %ds:%esi). */ >> + /* NB. First uint16_t of buffer must be set to buffer size. */ >> + GUEST_HANDLE(void) edd_params; >> + } disk_info; /* XEN_FW_DISK_INFO */ >> + struct { >> + uint8_t device; /* bios device number */ >> + uint32_t mbr_signature; /* offset 0x1b8 in mbr */ >> + } disk_mbr_signature; /* XEN_FW_DISK_MBR_SIGNATURE */ >> + struct { >> + /* Int10, AX=4F15: Get EDID info. */ >> + uint8_t capabilities; >> + uint8_t edid_transfer_time; >> + /* must refer to 128-byte buffer */ >> + GUEST_HANDLE(uchar) edid; >> + } vbeddc_info; /* XEN_FW_VBEDDC_INFO */ >> + } u; >> +}; >> +DEFINE_GUEST_HANDLE_STRUCT(xenpf_firmware_info_t); >> + >> +#define XENPF_enter_acpi_sleep 51 >> +struct xenpf_enter_acpi_sleep { >> + /* IN variables */ >> + uint16_t pm1a_cnt_val; /* PM1a control value. */ >> + uint16_t pm1b_cnt_val; /* PM1b control value. */ > These are uint32_t in native Linux--why truncate in the API and not at use? Does ACPI define them as 32 or 16 bit? J _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel From xen-devel-bounces@lists.xensource.com Wed Sep 07 10:31:23 2011 Return-path: Envelope-to: www-data@lists.xensource.com Delivery-date: Wed, 07 Sep 2011 10:31:23 -0700 Received: from localhost ([127.0.0.1] helo=lists.colo.xensource.com) by lists.xensource.com with esmtp (Exim 4.43) id 1R1Ly7-0002cb-In; Wed, 07 Sep 2011 10:31:23 -0700 Received: from mail182.messagelabs.com ([85.158.139.83]) by lists.xensource.com with smtp (Exim 4.43) id 1R1Lxc-0002Pz-Dy for xen-devel@lists.xensource.com; Wed, 07 Sep 2011 10:30:52 -0700 X-Env-Sender: Stefano.Stabellini@eu.citrix.com X-Msg-Ref: server-4.tower-182.messagelabs.com!1315416649!17444526!1 X-Originating-IP: [62.200.22.115] X-StarScan-Version: 6.3.6; banners=-,-,- X-VirusChecked: Checked Received: (qmail 14140 invoked from network); 7 Sep 2011 17:30:49 -0000 Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115) by server-4.tower-182.messagelabs.com with SMTP; 7 Sep 2011 17:30:49 -0000 X-IronPort-AV: E=Sophos;i="4.68,346,1312156800"; d="scan'208";a="7659668" Received: from lonpmailmx01.citrite.net ([10.30.203.162]) by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5; 07 Sep 2011 17:30:49 +0000 Received: from kaball.uk.xensource.com (10.80.2.59) by LONPMAILMX01.citrite.net (10.30.203.162) with Microsoft SMTP Server id 8.3.137.0; Wed, 7 Sep 2011 18:30:48 +0100 Date: Wed, 7 Sep 2011 18:38:57 +0100 From: Stefano Stabellini X-X-Sender: sstabellini@kaball-desktop To: Jeremy Fitzhardinge In-Reply-To: <4E67A646.7000405@goop.org> Message-ID: References: <1315413571-10938-2-git-send-email-stefano.stabellini@eu.citrix.com> <4E67A646.7000405@goop.org> User-Agent: Alpine 2.00 (DEB 1167 2008-08-23) MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Cc: Ian Campbell , "xen-devel@lists.xensource.com" , "konrad.wilk@oracle.com" , "linux-kernel@vger.kernel.org" , Stefano Stabellini Subject: [Xen-devel] Re: [PATCH v3 2/2] xen: modify kernel mappings corresponding to granted pages X-BeenThere: xen-devel@lists.xensource.com X-Mailman-Version: 2.1.5 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xensource.com Errors-To: xen-devel-bounces@lists.xensource.com On Wed, 7 Sep 2011, Jeremy Fitzhardinge wrote: > On 09/07/2011 09:39 AM, stefano.stabellini@eu.citrix.com wrote: > > From: Stefano Stabellini > > > > If we want to use granted pages for AIO, changing the mappings of a user > > vma and the corresponding p2m is not enough, we also need to update the > > kernel mappings accordingly. > > In order to avoid the complexity of dealing with highmem, we allocated > > the pages lowmem. > > We issue a HYPERVISOR_grant_table_op right away in > > m2p_add_override and we remove the mappings using another > > HYPERVISOR_grant_table_op in m2p_remove_override. > > Considering that m2p_add_override and m2p_remove_override are called > > once per page we use multicalls and hypercall batching. > > > > Use the kmap_op pointer directly as argument to do the mapping as it is > > guaranteed to be present up until the unmapping is done. > > Before issuing any unmapping multicalls, we need to make sure that the > > mapping has already being done, because we need the kmap->handle to be > > set correctly. > > > > Signed-off-by: Stefano Stabellini > > --- > > arch/x86/include/asm/xen/page.h | 5 ++- > > arch/x86/xen/p2m.c | 67 ++++++++++++++++++++++++++++++++------ > > drivers/xen/gntdev.c | 27 +++++++++++++++- > > drivers/xen/grant-table.c | 4 +- > > include/xen/grant_table.h | 1 + > > 5 files changed, 89 insertions(+), 15 deletions(-) > > > > diff --git a/arch/x86/include/asm/xen/page.h b/arch/x86/include/asm/xen/page.h > > index 7ff4669..0ce1884 100644 > > --- a/arch/x86/include/asm/xen/page.h > > +++ b/arch/x86/include/asm/xen/page.h > > @@ -12,6 +12,7 @@ > > #include > > > > #include > > +#include > > #include > > > > /* Xen machine address */ > > @@ -31,8 +32,10 @@ typedef struct xpaddr { > > #define INVALID_P2M_ENTRY (~0UL) > > #define FOREIGN_FRAME_BIT (1UL<<(BITS_PER_LONG-1)) > > #define IDENTITY_FRAME_BIT (1UL<<(BITS_PER_LONG-2)) > > +#define GRANT_FRAME_BIT (1UL<<(BITS_PER_LONG-3)) > > #define FOREIGN_FRAME(m) ((m) | FOREIGN_FRAME_BIT) > > #define IDENTITY_FRAME(m) ((m) | IDENTITY_FRAME_BIT) > > +#define GRANT_FRAME(m) ((m) | GRANT_FRAME_BIT) > > > > /* Maximum amount of memory we can handle in a domain in pages */ > > #define MAX_DOMAIN_PAGES \ > > @@ -48,7 +51,7 @@ extern unsigned long set_phys_range_identity(unsigned long pfn_s, > > unsigned long pfn_e); > > > > extern int m2p_add_override(unsigned long mfn, struct page *page, > > - bool clear_pte); > > + struct gnttab_map_grant_ref *kmap_op); > > extern int m2p_remove_override(struct page *page, bool clear_pte); > > extern struct page *m2p_find_override(unsigned long mfn); > > extern unsigned long m2p_find_override_pfn(unsigned long mfn, unsigned long pfn); > > diff --git a/arch/x86/xen/p2m.c b/arch/x86/xen/p2m.c > > index 58efeb9..6c26ac80 100644 > > --- a/arch/x86/xen/p2m.c > > +++ b/arch/x86/xen/p2m.c > > @@ -161,7 +161,9 @@ > > #include > > #include > > #include > > +#include > > > > +#include "multicalls.h" > > #include "xen-ops.h" > > > > static void __init m2p_override_init(void); > > @@ -676,7 +678,8 @@ static unsigned long mfn_hash(unsigned long mfn) > > } > > > > /* Add an MFN override for a particular page */ > > -int m2p_add_override(unsigned long mfn, struct page *page, bool clear_pte) > > +int m2p_add_override(unsigned long mfn, struct page *page, > > + struct gnttab_map_grant_ref *kmap_op) > > { > > unsigned long flags; > > unsigned long pfn; > > @@ -699,9 +702,20 @@ int m2p_add_override(unsigned long mfn, struct page *page, bool clear_pte) > > if (unlikely(!set_phys_to_machine(pfn, FOREIGN_FRAME(mfn)))) > > return -ENOMEM; > > > > - if (clear_pte && !PageHighMem(page)) > > - /* Just zap old mapping for now */ > > - pte_clear(&init_mm, address, ptep); > > + if (kmap_op != NULL) { > > + if (!PageHighMem(page)) { > > + struct multicall_space mcs = xen_mc_entry(sizeof(*kmap_op)); > > + > > + MULTI_grant_table_op(mcs.mc, > > + GNTTABOP_map_grant_ref, kmap_op, 1); > > + > > + xen_mc_issue(PARAVIRT_LAZY_MMU); > > + } > > + page->private |= GRANT_FRAME_BIT; > > + /* let's use dev_bus_addr to record the old mfn instead */ > > + kmap_op->dev_bus_addr = page->index; > > + page->index = (unsigned long) kmap_op; > > + } > > spin_lock_irqsave(&m2p_override_lock, flags); > > list_add(&page->lru, &m2p_overrides[mfn_hash(mfn)]); > > spin_unlock_irqrestore(&m2p_override_lock, flags); > > @@ -735,13 +749,44 @@ int m2p_remove_override(struct page *page, bool clear_pte) > > spin_lock_irqsave(&m2p_override_lock, flags); > > list_del(&page->lru); > > spin_unlock_irqrestore(&m2p_override_lock, flags); > > - set_phys_to_machine(pfn, page->index); > > > > - if (clear_pte && !PageHighMem(page)) > > - set_pte_at(&init_mm, address, ptep, > > - pfn_pte(pfn, PAGE_KERNEL)); > > - /* No tlb flush necessary because the caller already > > - * left the pte unmapped. */ > > + if (clear_pte) { > > + struct gnttab_map_grant_ref *map_op = > > + (struct gnttab_map_grant_ref *) page->index; > > + set_phys_to_machine(pfn, map_op->dev_bus_addr); > > + if (!PageHighMem(page)) { > > + struct multicall_space mcs = > > + xen_mc_entry(sizeof(struct gnttab_unmap_grant_ref)); > > + struct gnttab_unmap_grant_ref *unmap_op = mcs.args; > > + > > + /* > > + * Has the grant_op mapping multicall being issued? If not, > > + * make sure it is called now. > > + */ > > + if (map_op->handle == -1) > > + xen_mc_flush(); > > Hm, this will end up flushing the empty uninitialized entry you just > added, which also implicitly frees the space, so all the stuff below is > - at best - a noop. I'll have to move it earlier. > But also, this pattern of getting results back from batched calls is > unusual - actually, I think this is unique. If you have batched up a > map operation which has its map_op args allocated from the multicall > buffer, then the flush will implicitly free them as well, so it isn't > valid to read back from the structure later on. If you want to have an > args structure you can use once the hypercall has been issued, you need > to manually manage its lifetime. But I am not using the multicall buffer as argument, I am using the kmap_op passed to m2p_add_override. _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel From xen-devel-bounces@lists.xensource.com Wed Sep 07 10:35:35 2011 Return-path: Envelope-to: www-data@lists.xensource.com Delivery-date: Wed, 07 Sep 2011 10:35:35 -0700 Received: from localhost ([127.0.0.1] helo=lists.colo.xensource.com) by lists.xensource.com with esmtp (Exim 4.43) id 1R1M2A-0003A6-9z; Wed, 07 Sep 2011 10:35:34 -0700 Received: from mail174.messagelabs.com ([85.158.138.51]) by lists.xensource.com with esmtp (Exim 4.43) id 1R1M1c-0002w1-Ez for xen-devel@lists.xensource.com; Wed, 07 Sep 2011 10:35:00 -0700 X-Env-Sender: jeremy@goop.org X-Msg-Ref: server-14.tower-174.messagelabs.com!1315416895!30603790!1 X-Originating-IP: [74.207.240.146] X-StarScan-Version: 6.3.6; banners=-,-,- X-VirusChecked: Checked Received: (qmail 8501 invoked from network); 7 Sep 2011 17:34:57 -0000 Received: from claw.goop.org (HELO claw.goop.org) (74.207.240.146) by server-14.tower-174.messagelabs.com with DHE-RSA-AES256-SHA encrypted SMTP; 7 Sep 2011 17:34:57 -0000 Received: from saboo.goop.org (unknown [IPv6:2001:470:1f05:899:6801:ccff:fe7b:9751]) (Authenticated sender: smtp-saboo) by claw.goop.org (Postfix) with ESMTPSA id 0E6B32C1; Wed, 7 Sep 2011 10:34:55 -0700 (PDT) Received: from saboo.goop.org (localhost [IPv6:::1]) by saboo.goop.org (Postfix) with ESMTP id 887EB2024D; Wed, 7 Sep 2011 10:34:49 -0700 (PDT) Message-ID: <4E67AB39.70801@goop.org> Date: Wed, 07 Sep 2011 10:34:49 -0700 From: Jeremy Fitzhardinge User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:6.0) Gecko/20110816 Thunderbird/6.0 MIME-Version: 1.0 To: Konrad Rzeszutek Wilk Subject: Re: [Xen-devel] blkfront problem in pvops kernel when barriers enabled References: <4E6357C6.6050101@mimuw.edu.pl> <20110906163213.GC5264@dumpdata.com> <4E665572.7080009@mimuw.edu.pl> <20110907014741.GD30639@dumpdata.com> In-Reply-To: <20110907014741.GD30639@dumpdata.com> X-Enigmail-Version: 1.3.1 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: "xen-devel@lists.xensource.com" , Marek Marczykowski X-BeenThere: xen-devel@lists.xensource.com X-Mailman-Version: 2.1.5 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xensource.com Errors-To: xen-devel-bounces@lists.xensource.com On 09/06/2011 06:47 PM, Konrad Rzeszutek Wilk wrote: > (on 3.1rc2) Looking to xenstore now there is 'feature-flush-cache=1' and > no 'feature-barrier'. So it is ok. > > > I can only think of 2.6.38-3 XenOLinux doing it - and it is a bug > to do it. It really ought to _not_ advertise 'feature-barrier' and > instead advertise 'feature-flush-cache'. Does that mean that older guests which don't understand flush-cache will be left with no way to force writes to stable storage? Seems to me that even if the backend would prefer flush-cache, it should also advertise barriers. However, that raises the question of how to express the preferred mechanism if multiple are available. You could assume that flush-cache is always preferred if available, but that's pretty clunky. J _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel From xen-devel-bounces@lists.xensource.com Wed Sep 07 10:37:15 2011 Return-path: Envelope-to: www-data@lists.xensource.com Delivery-date: Wed, 07 Sep 2011 10:37:15 -0700 Received: from localhost ([127.0.0.1] helo=lists.colo.xensource.com) by lists.xensource.com with esmtp (Exim 4.43) id 1R1M3n-0003da-KF; Wed, 07 Sep 2011 10:37:15 -0700 Received: from mail182.messagelabs.com ([85.158.139.83]) by lists.xensource.com with esmtp (Exim 4.43) id 1R1M3O-0003R6-Nd for xen-devel@lists.xensource.com; Wed, 07 Sep 2011 10:36:51 -0700 X-Env-Sender: konrad@dumpdata.com X-Msg-Ref: server-13.tower-182.messagelabs.com!1315417006!17282012!1 X-Originating-IP: [141.146.126.227] X-StarScan-Version: 6.3.6; banners=-,-,- X-VirusChecked: Checked Received: (qmail 7676 invoked from network); 7 Sep 2011 17:36:47 -0000 Received: from acsinet15.oracle.com (HELO acsinet15.oracle.com) (141.146.126.227) by server-13.tower-182.messagelabs.com with DHE-RSA-AES256-SHA encrypted SMTP; 7 Sep 2011 17:36:47 -0000 Received: from acsinet22.oracle.com (acsinet22.oracle.com [141.146.126.238]) by acsinet15.oracle.com (Switch-3.4.4/Switch-3.4.4) with ESMTP id p87HagJg018786 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Wed, 7 Sep 2011 17:36:43 GMT Received: from acsmt358.oracle.com (acsmt358.oracle.com [141.146.40.158]) by acsinet22.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id p87HafS8027221 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 7 Sep 2011 17:36:41 GMT Received: from abhmt112.oracle.com (abhmt112.oracle.com [141.146.116.64]) by acsmt358.oracle.com (8.12.11.20060308/8.12.11) with ESMTP id p87HaZ1i011220; Wed, 7 Sep 2011 12:36:35 -0500 Received: from phenom (/209.6.55.207) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Wed, 07 Sep 2011 10:36:35 -0700 Received: by phenom (Postfix, from userid 1000) id DFC0B10B8; Wed, 7 Sep 2011 13:36:22 -0400 (EDT) Date: Wed, 7 Sep 2011 13:36:22 -0400 From: Konrad Rzeszutek Wilk To: Marek Marczykowski Subject: Re: [Xen-devel] Memory fragmentation and PCI passthrough Message-ID: <20110907173622.GJ32190@dumpdata.com> References: <4E665E53.3@invisiblethingslab.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <4E665E53.3@invisiblethingslab.com> User-Agent: Mutt/1.5.21 (2010-09-15) X-Source-IP: acsinet22.oracle.com [141.146.126.238] X-Auth-Type: Internal IP X-CT-RefId: str=0001.0A020202.4E67ABAC.004F:SCFMA922111,ss=1,re=-4.000,fgs=0 Cc: "xen-devel@lists.xensource.com" , Joanna Rutkowska , Rafal Wojtczuk X-BeenThere: xen-devel@lists.xensource.com X-Mailman-Version: 2.1.5 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xensource.com Errors-To: xen-devel-bounces@lists.xensource.com On Tue, Sep 06, 2011 at 07:54:27PM +0200, Marek Marczykowski wrote: > Hello, > > I've hit known problem with dynamic memory management - memory > fragmentation... This dynamic memory management basically does xl > mem-set to balance memory. > > After some time of running system, xen memory is so fragmented that it > is impossible to start new VM with PCI device. Sometimes it crashes > during boot (no 64MB contiguous memory for SWIOTLB), or later - eg. > iwlagn cannot allocate memory for loading firmware (few allocs, each > bellow 100k). > > DomU kernel cmdline: console=hvc0 iommu=soft earlyprintk=xen > > There is two cases (I think): > 1. With IOMMU > 2. Without IOMMU > I've tried only the second one. > > Is there any known solution for this problem? > Some ideas: > 1. With IOMMU pass iommu=pv to Xen. AFAIU domU will not need iommu=soft > parameter then, right? Will it work then with fragmented memory? It will still need it. Otherwise the Xen SWIOTLB won't be used. But you can limit the amount of memory for the SWIOTLB, say by doing 'swiotlb=2048' > > 2. Force somehow on xen/libxl to allocate memory (for domU) in chunks > of, say 4MB, to not fragment it so badly. Is it doable? > > In tmem documentation is also described some workaround for this: > reserve some memory region for allocations with 0 tries to allocate 64MB, which much bigger than 2MB... Is it really > needed to allocate such big region of contiguous memory in one piece? Nope. It only uses that pool for 32-bit devices too - so there is not really a big need for it. > > -- > Pozdrawiam / Best Regards, > Marek Marczykowski > Invisible Things Lab > > _______________________________________________ > Xen-devel mailing list > Xen-devel@lists.xensource.com > http://lists.xensource.com/xen-devel _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel From xen-devel-bounces@lists.xensource.com Wed Sep 07 10:42:53 2011 Return-path: Envelope-to: www-data@lists.xensource.com Delivery-date: Wed, 07 Sep 2011 10:42:53 -0700 Received: from localhost ([127.0.0.1] helo=lists.colo.xensource.com) by lists.xensource.com with esmtp (Exim 4.43) id 1R1M9F-0004Au-2z; Wed, 07 Sep 2011 10:42:53 -0700 Received: from mail182.messagelabs.com ([85.158.139.83]) by lists.xensource.com with esmtp (Exim 4.43) id 1R1M8m-0003yw-Ey for xen-devel@lists.xensource.com; Wed, 07 Sep 2011 10:42:24 -0700 X-Env-Sender: konrad@dumpdata.com X-Msg-Ref: server-14.tower-182.messagelabs.com!1315417339!17279923!1 X-Originating-IP: [148.87.113.117] X-StarScan-Version: 6.3.6; banners=-,-,- X-VirusChecked: Checked Received: (qmail 9917 invoked from network); 7 Sep 2011 17:42:21 -0000 Received: from rcsinet15.oracle.com (HELO rcsinet15.oracle.com) (148.87.113.117) by server-14.tower-182.messagelabs.com with DHE-RSA-AES256-SHA encrypted SMTP; 7 Sep 2011 17:42:21 -0000 Received: from acsinet22.oracle.com (acsinet22.oracle.com [141.146.126.238]) by rcsinet15.oracle.com (Switch-3.4.4/Switch-3.4.4) with ESMTP id p87HgH5Q030485 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Wed, 7 Sep 2011 17:42:19 GMT Received: from acsmt356.oracle.com (acsmt356.oracle.com [141.146.40.156]) by acsinet22.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id p87HgGM0006924 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 7 Sep 2011 17:42:17 GMT Received: from abhmt116.oracle.com (abhmt116.oracle.com [141.146.116.68]) by acsmt356.oracle.com (8.12.11.20060308/8.12.11) with ESMTP id p87HgBAZ022766; Wed, 7 Sep 2011 12:42:11 -0500 Received: from phenom (/209.6.55.207) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Wed, 07 Sep 2011 10:42:10 -0700 Received: by phenom (Postfix, from userid 1000) id 42CE410B8; Wed, 7 Sep 2011 13:41:58 -0400 (EDT) Date: Wed, 7 Sep 2011 13:41:58 -0400 From: Konrad Rzeszutek Wilk To: Jan Beulich Subject: Re: [Xen-devel] blkfront problem in pvops kernel when barriers enabled Message-ID: <20110907174158.GL32190@dumpdata.com> References: <4E6357C6.6050101@mimuw.edu.pl> <20110906163213.GC5264@dumpdata.com> <4E665572.7080009@mimuw.edu.pl> <20110907014741.GD30639@dumpdata.com> <4E675A980200007800055050@nat28.tlf.novell.com> <4E6761630200007800055087@nat28.tlf.novell.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <4E6761630200007800055087@nat28.tlf.novell.com> User-Agent: Mutt/1.5.21 (2010-09-15) X-Source-IP: acsinet22.oracle.com [141.146.126.238] X-Auth-Type: Internal IP X-CT-RefId: str=0001.0A090204.4E67ACFB.00CB:SCFMA922111,ss=1,re=-4.000,fgs=0 Cc: "xen-devel@lists.xensource.com" , Marek Marczykowski X-BeenThere: xen-devel@lists.xensource.com X-Mailman-Version: 2.1.5 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xensource.com Errors-To: xen-devel-bounces@lists.xensource.com > >> > >> > >> I can only think of 2.6.38-3 XenOLinux doing it - and it is a bug > >> to do it. It really ought to _not_ advertise 'feature-barrier' and > >> instead advertise 'feature-flush-cache'. > > > > Indeed, I see that I added feature-flush-cache support to the frontend > > back then, but neglected to do so for the backend. Partly perhaps > > because I'm not much of a (block, network, ...) driver person... > > > > However, what I'm not understanding with dropping feature-barrier > > support from the backend - how do you deal with old frontends > > wanting to use barriers? I'm currently converting them into Just not supporting them. I know it is incredibly bad to do so - but I have not had a chance to write the code to emulate the 'feature-barrier' correctly. > > WRITE_FLUSH_FUA operations in the backend as a (hopefully) best > > effort approach. I am not sure. I need to run blktrace|blkparse to make sure it does the right think as compared to a WRITE_BARRIER. Lets ask Christopher Hellwig - he knows a lot of this. > > Also I notice you're using WRITE_ODIRECT - what's the background > of that? Ah, http://git.drbd.org/linux-2.6-drbd.git/?p=linux-2.6-drbd.git;a=commit;h=013c3ca184851078b9c04744efd4d47e52c6ecf8 > > Thanks, Jan _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel From xen-devel-bounces@lists.xensource.com Wed Sep 07 10:43:56 2011 Return-path: Envelope-to: www-data@lists.xensource.com Delivery-date: Wed, 07 Sep 2011 10:43:56 -0700 Received: from localhost ([127.0.0.1] helo=lists.colo.xensource.com) by lists.xensource.com with esmtp (Exim 4.43) id 1R1MAG-0004Yc-Qw; Wed, 07 Sep 2011 10:43:56 -0700 Received: from mail27.messagelabs.com ([193.109.254.147]) by lists.xensource.com with smtp (Exim 4.43) id 1R1M97-00046N-7u for xen-devel@lists.xensource.com; Wed, 07 Sep 2011 10:42:45 -0700 X-Env-Sender: avi@redhat.com X-Msg-Ref: server-13.tower-27.messagelabs.com!1315417350!39084369!1 X-Originating-IP: [209.132.183.28] X-StarScan-Version: 6.3.6; banners=-,-,- X-VirusChecked: Checked Received: (qmail 19259 invoked from network); 7 Sep 2011 17:42:31 -0000 Received: from mx1.redhat.com (HELO mx1.redhat.com) (209.132.183.28) by server-13.tower-27.messagelabs.com with SMTP; 7 Sep 2011 17:42:31 -0000 Received: from int-mx02.intmail.prod.int.phx2.redhat.com (int-mx02.intmail.prod.int.phx2.redhat.com [10.5.11.12]) by mx1.redhat.com (8.14.4/8.14.4) with ESMTP id p87HfM8B013534 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Wed, 7 Sep 2011 13:41:22 -0400 Received: from mermaid.qumranet.com (vpn-200-133.tlv.redhat.com [10.35.200.133]) by int-mx02.intmail.prod.int.phx2.redhat.com (8.13.8/8.13.8) with ESMTP id p87HfBIG010718; Wed, 7 Sep 2011 13:41:12 -0400 Message-ID: <4E67ACB6.40107@redhat.com> Date: Wed, 07 Sep 2011 20:41:10 +0300 From: Avi Kivity User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:6.0) Gecko/20110816 Thunderbird/6.0 MIME-Version: 1.0 To: Jeremy Fitzhardinge References: <1314996468.8255.0.camel@twins> <4E614FBD.2030509@goop.org> <20110906151408.GA7459@redhat.com> <4E66615E.8070806@goop.org> <20110906182758.GR5795@redhat.com> <4E66EF86.9070200@redhat.com> <20110907134411.GV5795@redhat.com> <4E678992.5050709@redhat.com> <20110907155657.GX5795@redhat.com> <4E679AF4.50209@redhat.com> <20110907165203.GQ6838@redhat.com> <4E67A551.4000502@redhat.com> <4E67A71A.5070903@goop.org> In-Reply-To: <4E67A71A.5070903@goop.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Scanned-By: MIMEDefang 2.67 on 10.5.11.12 Cc: Don Zickus , Marcelo Tosatti , Nick Piggin , KVM , Stefano Stabellini , Peter Zijlstra , the arch/x86 maintainers , Linux Kernel Mailing List , Andi Kleen , Jeremy Fitzhardinge , "H. Peter Anvin" , Ingo Molnar , Linus Torvalds , Xen Devel Subject: [Xen-devel] Re: [PATCH 08/13] xen/pvticketlock: disable interrupts while blocking X-BeenThere: xen-devel@lists.xensource.com X-Mailman-Version: 2.1.5 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xensource.com Errors-To: xen-devel-bounces@lists.xensource.com On 09/07/2011 08:17 PM, Jeremy Fitzhardinge wrote: > On 09/07/2011 10:09 AM, Avi Kivity wrote: > > On 09/07/2011 07:52 PM, Don Zickus wrote: > >> > > >> > May I ask how? Detecting a back-to-back NMI? > >> > >> Pretty boring actually. Currently we execute an NMI handler until > >> one of > >> them returns handled. Then we stop. This may cause us to miss an > >> NMI in > >> the case of multiple NMIs at once. Now we are changing it to execute > >> _all_ the handlers to make sure we didn't miss one. > > > > That's going to be pretty bad for kvm - those handlers become a lot > > more expensive since they involve reading MSRs. > > How often are you going to get NMIs in a kvm guest? We'll soon have the perf-based watchdog firing every 60s worth of instructions or so. But if we implement your new kick pvop using NMI then it can be _very_ often. > > > Even worse if we start using NMIs as a wakeup for pv spinlocks as > > provided by this patchset. > > Hm, I'm interested to know what you're thinking in more detail. Can you > leave an NMI pending before you block in the same way you can with > "sti;halt" with normal interrupts? Nope. But you can do if (regs->rip in critical section) regs->rip = after_halt; and effectively emulate it. The critical section is something like critical_section_start: if (woken_up) goto critical_section_end; hlt critical_section_end: > > I was thinking you might want to do something with monitor/mwait to > implement the blocking/kick ops. (Handwave) > monitor/mwait are incredibly expensive to virtualize since they require write-protecting a page, IPIs flying everywhere and flushing tlbs, not to mention my lovely hugepages being broken up mercilessly. -- I have a truly marvellous patch that fixes the bug which this signature is too narrow to contain. _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel From xen-devel-bounces@lists.xensource.com Wed Sep 07 10:44:48 2011 Return-path: Envelope-to: www-data@lists.xensource.com Delivery-date: Wed, 07 Sep 2011 10:44:48 -0700 Received: from localhost ([127.0.0.1] helo=lists.colo.xensource.com) by lists.xensource.com with esmtp (Exim 4.43) id 1R1MB6-0004vb-H0; Wed, 07 Sep 2011 10:44:48 -0700 Received: from mail21.messagelabs.com ([85.158.143.35]) by lists.xensource.com with smtp (Exim 4.43) id 1R1M9p-0004QI-OQ for xen-devel@lists.xensource.com; Wed, 07 Sep 2011 10:43:30 -0700 X-Env-Sender: avi@redhat.com X-Msg-Ref: server-8.tower-21.messagelabs.com!1315417391!58101388!1 X-Originating-IP: [209.132.183.28] X-StarScan-Version: 6.3.6; banners=-,-,- X-VirusChecked: Checked Received: (qmail 15216 invoked from network); 7 Sep 2011 17:43:11 -0000 Received: from mx1.redhat.com (HELO mx1.redhat.com) (209.132.183.28) by server-8.tower-21.messagelabs.com with SMTP; 7 Sep 2011 17:43:11 -0000 Received: from int-mx09.intmail.prod.int.phx2.redhat.com (int-mx09.intmail.prod.int.phx2.redhat.com [10.5.11.22]) by mx1.redhat.com (8.14.4/8.14.4) with ESMTP id p87HfuhN024898 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Wed, 7 Sep 2011 13:41:56 -0400 Received: from mermaid.qumranet.com (vpn-200-133.tlv.redhat.com [10.35.200.133]) by int-mx09.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP id p87Hfnpg028800; Wed, 7 Sep 2011 13:41:50 -0400 Message-ID: <4E67ACDC.90303@redhat.com> Date: Wed, 07 Sep 2011 20:41:48 +0300 From: Avi Kivity User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:6.0) Gecko/20110816 Thunderbird/6.0 MIME-Version: 1.0 To: Don Zickus References: <20110906151408.GA7459@redhat.com> <4E66615E.8070806@goop.org> <20110906182758.GR5795@redhat.com> <4E66EF86.9070200@redhat.com> <20110907134411.GV5795@redhat.com> <4E678992.5050709@redhat.com> <20110907155657.GX5795@redhat.com> <4E679AF4.50209@redhat.com> <20110907165203.GQ6838@redhat.com> <4E67A551.4000502@redhat.com> <20110907172117.GY5795@redhat.com> In-Reply-To: <20110907172117.GY5795@redhat.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Scanned-By: MIMEDefang 2.68 on 10.5.11.22 Cc: Jeremy Fitzhardinge , Marcelo Tosatti , Nick Piggin , KVM , Stefano Stabellini , Peter Zijlstra , the arch/x86 maintainers , Linux Kernel Mailing List , Andi Kleen , Jeremy Fitzhardinge , "H. Peter Anvin" , Ingo Molnar , Linus Torvalds , Xen Devel Subject: [Xen-devel] Re: [PATCH 08/13] xen/pvticketlock: disable interrupts while blocking X-BeenThere: xen-devel@lists.xensource.com X-Mailman-Version: 2.1.5 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xensource.com Errors-To: xen-devel-bounces@lists.xensource.com On 09/07/2011 08:21 PM, Don Zickus wrote: > > > > How about, during NMI, save %rip to a per-cpu variable. Handle just > > one cause. If, on the next NMI, we hit the same %rip, assume > > back-to-back NMI has occured and now handle all causes. > > I had a similar idea a couple of months ago while debugging a continuous > flow of back-to-back NMIs from a stress-test perf application and I > couldn't get it to work. But let me try it again, because it does make > sense as an optimization. > > Great, thanks. -- I have a truly marvellous patch that fixes the bug which this signature is too narrow to contain. _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel From xen-devel-bounces@lists.xensource.com Wed Sep 07 10:45:40 2011 Return-path: Envelope-to: www-data@lists.xensource.com Delivery-date: Wed, 07 Sep 2011 10:45:40 -0700 Received: from localhost ([127.0.0.1] helo=lists.colo.xensource.com) by lists.xensource.com with esmtp (Exim 4.43) id 1R1MBw-0005IZ-Td; Wed, 07 Sep 2011 10:45:40 -0700 Received: from mail27.messagelabs.com ([193.109.254.147]) by lists.xensource.com with esmtp (Exim 4.43) id 1R1MA3-0004Sk-4D for xen-devel@lists.xensource.com; Wed, 07 Sep 2011 10:43:43 -0700 X-Env-Sender: konrad@dumpdata.com X-Msg-Ref: server-10.tower-27.messagelabs.com!1315417400!34791096!1 X-Originating-IP: [148.87.113.117] X-StarScan-Version: 6.3.6; banners=-,-,- X-VirusChecked: Checked Received: (qmail 384 invoked from network); 7 Sep 2011 17:43:21 -0000 Received: from rcsinet15.oracle.com (HELO rcsinet15.oracle.com) (148.87.113.117) by server-10.tower-27.messagelabs.com with DHE-RSA-AES256-SHA encrypted SMTP; 7 Sep 2011 17:43:21 -0000 Received: from acsinet21.oracle.com (acsinet21.oracle.com [141.146.126.237]) by rcsinet15.oracle.com (Switch-3.4.4/Switch-3.4.4) with ESMTP id p87HhZRn032503 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Wed, 7 Sep 2011 17:43:36 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 p87HhYtj023241 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 7 Sep 2011 17:43:34 GMT Received: from abhmt104.oracle.com (abhmt104.oracle.com [141.146.116.56]) by acsmt358.oracle.com (8.12.11.20060308/8.12.11) with ESMTP id p87HhRYT016229; Wed, 7 Sep 2011 12:43:27 -0500 Received: from phenom (/209.6.55.207) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Wed, 07 Sep 2011 10:43:26 -0700 Received: by phenom (Postfix, from userid 1000) id 8169110B8; Wed, 7 Sep 2011 13:43:14 -0400 (EDT) Date: Wed, 7 Sep 2011 13:43:14 -0400 From: Konrad Rzeszutek Wilk To: Jeremy Fitzhardinge Subject: Re: [Xen-devel] blkfront problem in pvops kernel when barriers enabled Message-ID: <20110907174314.GM32190@dumpdata.com> References: <4E6357C6.6050101@mimuw.edu.pl> <20110906163213.GC5264@dumpdata.com> <4E665572.7080009@mimuw.edu.pl> <20110907014741.GD30639@dumpdata.com> <4E67AB39.70801@goop.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <4E67AB39.70801@goop.org> User-Agent: Mutt/1.5.21 (2010-09-15) X-Source-IP: acsinet21.oracle.com [141.146.126.237] X-Auth-Type: Internal IP X-CT-RefId: str=0001.0A090201.4E67AD49.0047:SCFMA922111,ss=1,re=-4.000,fgs=0 Cc: "xen-devel@lists.xensource.com" , Marek Marczykowski X-BeenThere: xen-devel@lists.xensource.com X-Mailman-Version: 2.1.5 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xensource.com Errors-To: xen-devel-bounces@lists.xensource.com On Wed, Sep 07, 2011 at 10:34:49AM -0700, Jeremy Fitzhardinge wrote: > On 09/06/2011 06:47 PM, Konrad Rzeszutek Wilk wrote: > > (on 3.1rc2) Looking to xenstore now there is 'feature-flush-cache=1' and > > no 'feature-barrier'. So it is ok. > > > > > > I can only think of 2.6.38-3 XenOLinux doing it - and it is a bug > > to do it. It really ought to _not_ advertise 'feature-barrier' and > > instead advertise 'feature-flush-cache'. > > Does that mean that older guests which don't understand flush-cache will > be left with no way to force writes to stable storage? Seems to me that Correct. > even if the backend would prefer flush-cache, it should also advertise > barriers. But doing it incorrectly is bad - really bad. > > However, that raises the question of how to express the preferred > mechanism if multiple are available. You could assume that flush-cache > is always preferred if available, but that's pretty clunky. That is how I did it in the frontend. > > J _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel From xen-devel-bounces@lists.xensource.com Wed Sep 07 10:46:28 2011 Return-path: Envelope-to: www-data@lists.xensource.com Delivery-date: Wed, 07 Sep 2011 10:46:28 -0700 Received: from localhost ([127.0.0.1] helo=lists.colo.xensource.com) by lists.xensource.com with esmtp (Exim 4.43) id 1R1MCi-0005fW-Dd; Wed, 07 Sep 2011 10:46:28 -0700 Received: from mail174.messagelabs.com ([85.158.138.51]) by lists.xensource.com with smtp (Exim 4.43) id 1R1MA5-0004TF-Lh for xen-devel@lists.xensource.com; Wed, 07 Sep 2011 10:43:46 -0700 X-Env-Sender: joseph.cihula@intel.com X-Msg-Ref: server-6.tower-174.messagelabs.com!1315417421!28461751!1 X-Originating-IP: [192.55.52.88] X-StarScan-Version: 6.3.6; banners=-,-,- X-VirusChecked: Checked Received: (qmail 5611 invoked from network); 7 Sep 2011 17:43:42 -0000 Received: from mga01.intel.com (HELO mga01.intel.com) (192.55.52.88) by server-6.tower-174.messagelabs.com with SMTP; 7 Sep 2011 17:43:42 -0000 Received: from fmsmga002.fm.intel.com ([10.253.24.26]) by fmsmga101.fm.intel.com with ESMTP; 07 Sep 2011 10:43:41 -0700 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="4.68,346,1312182000"; d="scan'208";a="50107068" Received: from orsmsx603.amr.corp.intel.com ([10.22.226.49]) by fmsmga002.fm.intel.com with ESMTP; 07 Sep 2011 10:43:40 -0700 Received: from orsmsx105.amr.corp.intel.com (10.22.225.132) by orsmsx603.amr.corp.intel.com (10.22.226.49) with Microsoft SMTP Server (TLS) id 8.2.255.0; Wed, 7 Sep 2011 10:43:40 -0700 Received: from orsmsx101.amr.corp.intel.com ([169.254.8.19]) by ORSMSX105.amr.corp.intel.com ([169.254.4.165]) with mapi id 14.01.0323.003; Wed, 7 Sep 2011 10:43:39 -0700 From: "Cihula, Joseph" To: Jeremy Fitzhardinge Subject: RE: [Xen-devel] RE: [PATCH 5/7] xen/acpi: Domain0 acpi parser related platform hypercall Thread-Topic: [Xen-devel] RE: [PATCH 5/7] xen/acpi: Domain0 acpi parser related platform hypercall Thread-Index: AQHMaAxZ5wNVyrMQuUW3m3AFnHdXf5VBc1bggAE5OYD//44lQA== Date: Wed, 7 Sep 2011 17:43:38 +0000 Message-ID: <9F57BF860713DF4BA3EFA4F8C6DFEDAC16F40F0B@ORSMSX101.amr.corp.intel.com> References: <1314815484-4668-1-git-send-email-konrad.wilk@oracle.com> <1314815484-4668-6-git-send-email-konrad.wilk@oracle.com> <9F57BF860713DF4BA3EFA4F8C6DFEDAC16F3F665@ORSMSX101.amr.corp.intel.com> <4E67A9E7.2020802@goop.org> In-Reply-To: <4E67A9E7.2020802@goop.org> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.22.254.140] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "Brown, Len" , "Tian, Kevin" , "xen-devel@lists.xensource.com" , "hpa@zytor.com" , Konrad Rzeszutek Wilk , "x86@kernel.org" , Fitzhardinge , "linux-acpi@vger.kernel.org" , "tboot-devel@lists.sourceforge.net" , "liang.tang@oracle.com" , "Yu, Ke" , "linux-pm@lists.linux-foundation.org" , "keir@xen.org" , "tglx@linutronix.de" , "Wei, Gang" X-BeenThere: xen-devel@lists.xensource.com X-Mailman-Version: 2.1.5 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xensource.com Errors-To: xen-devel-bounces@lists.xensource.com > From: Jeremy Fitzhardinge [mailto:jeremy@goop.org] > Sent: Wednesday, September 07, 2011 10:29 AM >=20 > On 09/06/2011 10:50 PM, Cihula, Joseph wrote: > >> From: Konrad Rzeszutek Wilk [mailto:konrad.wilk@oracle.com] > >> Sent: Wednesday, August 31, 2011 11:31 AM > >> > >> From: Yu Ke > >> > >> This patches implements the xen_platform_op hypercall, to pass the par= sed ACPI info to > hypervisor. > >> > >> Signed-off-by: Yu Ke > >> Signed-off-by: Tian Kevin > >> Signed-off-by: Jeremy Fitzhardinge > >> [v1: Added DEFINE_GUEST.. in appropiate headers] > >> [v2: Ripped out typedefs] > >> Signed-off-by: Konrad Rzeszutek Wilk > >> --- > >> arch/ia64/include/asm/xen/interface.h | 1 + > >> arch/x86/include/asm/xen/interface.h | 1 + > >> include/xen/interface/platform.h | 320 ++++++++++++++++++++++++= +++++++++ > >> include/xen/interface/xen.h | 1 + > >> 4 files changed, 323 insertions(+), 0 deletions(-) create mode > >> 100644 include/xen/interface/platform.h > >> > >> diff --git a/arch/ia64/include/asm/xen/interface.h > >> b/arch/ia64/include/asm/xen/interface.h > >> index e951e74..1d2427d 100644 > >> --- a/arch/ia64/include/asm/xen/interface.h > >> +++ b/arch/ia64/include/asm/xen/interface.h > >> @@ -76,6 +76,7 @@ DEFINE_GUEST_HANDLE(char); > >> DEFINE_GUEST_HANDLE(int); DEFINE_GUEST_HANDLE(long); > >> DEFINE_GUEST_HANDLE(void); > >> +DEFINE_GUEST_HANDLE(uint64_t); > >> > >> typedef unsigned long xen_pfn_t; > >> DEFINE_GUEST_HANDLE(xen_pfn_t); > >> diff --git a/arch/x86/include/asm/xen/interface.h > >> b/arch/x86/include/asm/xen/interface.h > >> index 5d4922a..a1f2db5 100644 > >> --- a/arch/x86/include/asm/xen/interface.h > >> +++ b/arch/x86/include/asm/xen/interface.h > >> @@ -55,6 +55,7 @@ DEFINE_GUEST_HANDLE(char); > >> DEFINE_GUEST_HANDLE(int); DEFINE_GUEST_HANDLE(long); > >> DEFINE_GUEST_HANDLE(void); > >> +DEFINE_GUEST_HANDLE(uint64_t); > >> #endif > >> > >> #ifndef HYPERVISOR_VIRT_START > >> diff --git a/include/xen/interface/platform.h > >> b/include/xen/interface/platform.h > >> new file mode 100644 > >> index 0000000..c168468 > >> --- /dev/null > >> +++ b/include/xen/interface/platform.h > > Why are you adding so many new hypercalls that aren't being used in thi= s patchset? >=20 > May as well bring in all the platform-related hypercall definitions at on= ce rather than be > piecemeal. >=20 > >> @@ -0,0 +1,320 @@ > >> +/******************************************************************* > >> +*** > >> +******** > >> + * platform.h > >> + * > >> + * Hardware platform operations. Intended for use by domain-0 kernel. > >> + * > >> + * Permission is hereby granted, free of charge, to any person > >> +obtaining a copy > >> + * of this software and associated documentation files (the > >> +"Software"), to > >> + * deal in the Software without restriction, including without > >> +limitation the > >> + * rights to use, copy, modify, merge, publish, distribute, > >> +sublicense, and/or > >> + * sell copies of the Software, and to permit persons to whom the > >> +Software is > >> + * furnished to do so, subject to the following conditions: > >> + * > >> + * The above copyright notice and this permission notice shall be > >> +included in > >> + * all copies or substantial portions of the Software. > >> + * > >> + * THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, > >> +EXPRESS OR > >> + * IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF > >> +MERCHANTABILITY, > >> + * FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT > >> +SHALL THE > >> + * AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR > >> +OTHER > >> + * LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, > >> +ARISING > >> + * FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR > >> +OTHER > >> + * DEALINGS IN THE SOFTWARE. > >> + * > >> + * Copyright (c) 2002-2006, K Fraser */ > >> + > >> +#ifndef __XEN_PUBLIC_PLATFORM_H__ > >> +#define __XEN_PUBLIC_PLATFORM_H__ > >> + > >> +#include "xen.h" > >> + > >> +#define XENPF_INTERFACE_VERSION 0x03000001 > >> + > >> +/* > >> + * Set clock such that it would read after 00:00:00 > >> +UTC, > >> + * 1 January, 1970 if the current system time was . > >> + */ > >> +#define XENPF_settime 17 > >> +struct xenpf_settime { > >> + /* IN variables. */ > >> + uint32_t secs; > >> + uint32_t nsecs; > >> + uint64_t system_time; > >> +}; > >> +DEFINE_GUEST_HANDLE_STRUCT(xenpf_settime_t); > >> + > >> +/* > >> + * Request memory range (@mfn, @mfn+@nr_mfns-1) to have type @type. > >> + * On x86, @type is an architecture-defined MTRR memory type. > >> + * On success, returns the MTRR that was used (@reg) and a handle > >> +that can > >> + * be passed to XENPF_DEL_MEMTYPE to accurately tear down the new set= ting. > >> + * (x86-specific). > >> + */ > >> +#define XENPF_add_memtype 31 > >> +struct xenpf_add_memtype { > >> + /* IN variables. */ > >> + unsigned long mfn; > >> + uint64_t nr_mfns; > >> + uint32_t type; > >> + /* OUT variables. */ > >> + uint32_t handle; > >> + uint32_t reg; > >> +}; > >> +DEFINE_GUEST_HANDLE_STRUCT(xenpf_add_memtype_t); > >> + > >> +/* > >> + * Tear down an existing memory-range type. If @handle is remembered > >> +then it > >> + * should be passed in to accurately tear down the correct setting > >> +(in case > >> + * of overlapping memory regions with differing types). If it is not > >> +known > >> + * then @handle should be set to zero. In all cases @reg must be set. > >> + * (x86-specific). > >> + */ > >> +#define XENPF_del_memtype 32 > >> +struct xenpf_del_memtype { > >> + /* IN variables. */ > >> + uint32_t handle; > >> + uint32_t reg; > >> +}; > >> +DEFINE_GUEST_HANDLE_STRUCT(xenpf_del_memtype_t); > >> + > >> +/* Read current type of an MTRR (x86-specific). */ > >> +#define XENPF_read_memtype 33 > >> +struct xenpf_read_memtype { > >> + /* IN variables. */ > >> + uint32_t reg; > >> + /* OUT variables. */ > >> + unsigned long mfn; > >> + uint64_t nr_mfns; > >> + uint32_t type; > >> +}; > >> +DEFINE_GUEST_HANDLE_STRUCT(xenpf_read_memtype_t); > >> + > >> +#define XENPF_microcode_update 35 > >> +struct xenpf_microcode_update { > >> + /* IN variables. */ > >> + GUEST_HANDLE(void) data; /* Pointer to microcode data */ > >> + uint32_t length; /* Length of microcode data. */ > >> +}; > >> +DEFINE_GUEST_HANDLE_STRUCT(xenpf_microcode_update_t); > >> + > >> +#define XENPF_platform_quirk 39 > >> +#define QUIRK_NOIRQBALANCING 1 /* Do not restrict IO-APIC RTE ta= rgets */ > >> +#define QUIRK_IOAPIC_BAD_REGSEL 2 /* IO-APIC REGSEL forgets its val= ue */ > >> +#define QUIRK_IOAPIC_GOOD_REGSEL 3 /* IO-APIC REGSEL behaves properl= y */ > >> +struct xenpf_platform_quirk { > >> + /* IN variables. */ > >> + uint32_t quirk_id; > >> +}; > >> +DEFINE_GUEST_HANDLE_STRUCT(xenpf_platform_quirk_t); > >> + > >> +#define XENPF_firmware_info 50 > >> +#define XEN_FW_DISK_INFO 1 /* from int 13 AH=3D08/41/48 */ > >> +#define XEN_FW_DISK_MBR_SIGNATURE 2 /* from MBR offset 0x1b8 */ > >> +#define XEN_FW_VBEDDC_INFO 3 /* from int 10 AX=3D4f15 */ > >> +struct xenpf_firmware_info { > >> + /* IN variables. */ > >> + uint32_t type; > >> + uint32_t index; > >> + /* OUT variables. */ > >> + union { > >> + struct { > >> + /* Int13, Fn48: Check Extensions Present. */ > >> + uint8_t device; /* %dl: bios device number */ > >> + uint8_t version; /* %ah: major version */ > >> + uint16_t interface_support; /* %cx: support bitmap */ > >> + /* Int13, Fn08: Legacy Get Device Parameters. */ > >> + uint16_t legacy_max_cylinder; /* %cl[7:6]:%ch: max cyl # */ > >> + uint8_t legacy_max_head; /* %dh: max head # */ > >> + uint8_t legacy_sectors_per_track; /* %cl[5:0]: max sector # */ > >> + /* Int13, Fn41: Get Device Parameters (as filled into %ds:%esi). *= / > >> + /* NB. First uint16_t of buffer must be set to buffer size. *= / > >> + GUEST_HANDLE(void) edd_params; > >> + } disk_info; /* XEN_FW_DISK_INFO */ > >> + struct { > >> + uint8_t device; /* bios device number */ > >> + uint32_t mbr_signature; /* offset 0x1b8 in mbr */ > >> + } disk_mbr_signature; /* XEN_FW_DISK_MBR_SIGNATURE */ > >> + struct { > >> + /* Int10, AX=3D4F15: Get EDID info. */ > >> + uint8_t capabilities; > >> + uint8_t edid_transfer_time; > >> + /* must refer to 128-byte buffer */ > >> + GUEST_HANDLE(uchar) edid; > >> + } vbeddc_info; /* XEN_FW_VBEDDC_INFO */ > >> + } u; > >> +}; > >> +DEFINE_GUEST_HANDLE_STRUCT(xenpf_firmware_info_t); > >> + > >> +#define XENPF_enter_acpi_sleep 51 > >> +struct xenpf_enter_acpi_sleep { > >> + /* IN variables */ > >> + uint16_t pm1a_cnt_val; /* PM1a control value. */ > >> + uint16_t pm1b_cnt_val; /* PM1b control value. */ > > These are uint32_t in native Linux--why truncate in the API and not at = use? >=20 > Does ACPI define them as 32 or 16 bit? The spec indicates that the length is variable and could be up to 32 bits (= AFAICT). And Linux uses 32b, which your other patch is truncating for this= call. Joe _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel From xen-devel-bounces@lists.xensource.com Wed Sep 07 10:55:59 2011 Return-path: Envelope-to: www-data@lists.xensource.com Delivery-date: Wed, 07 Sep 2011 10:55:59 -0700 Received: from localhost ([127.0.0.1] helo=lists.colo.xensource.com) by lists.xensource.com with esmtp (Exim 4.43) id 1R1MLv-0006Ff-Fl; Wed, 07 Sep 2011 10:55:59 -0700 Received: from mail27.messagelabs.com ([193.109.254.147]) by lists.xensource.com with smtp (Exim 4.43) id 1R1MLV-00063Y-OH for xen-devel@lists.xensource.com; Wed, 07 Sep 2011 10:55:34 -0700 X-Env-Sender: joseph.cihula@intel.com X-Msg-Ref: server-14.tower-27.messagelabs.com!1315418114!35178555!1 X-Originating-IP: [143.182.124.21] X-StarScan-Version: 6.3.6; banners=-,-,- X-VirusChecked: Checked Received: (qmail 9178 invoked from network); 7 Sep 2011 17:55:17 -0000 Received: from mga03.intel.com (HELO mga03.intel.com) (143.182.124.21) by server-14.tower-27.messagelabs.com with SMTP; 7 Sep 2011 17:55:17 -0000 Received: from azsmga002.ch.intel.com ([10.2.17.35]) by azsmga101.ch.intel.com with ESMTP; 07 Sep 2011 10:55:26 -0700 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="4.68,346,1312182000"; d="scan'208";a="14893677" Received: from orsmsx603.amr.corp.intel.com ([10.22.226.49]) by AZSMGA002.ch.intel.com with ESMTP; 07 Sep 2011 10:55:26 -0700 Received: from orsmsx102.amr.corp.intel.com (10.22.225.129) by orsmsx603.amr.corp.intel.com (10.22.226.49) with Microsoft SMTP Server (TLS) id 8.2.255.0; Wed, 7 Sep 2011 10:55:14 -0700 Received: from orsmsx101.amr.corp.intel.com ([169.254.8.19]) by ORSMSX102.amr.corp.intel.com ([169.254.1.122]) with mapi id 14.01.0323.003; Wed, 7 Sep 2011 10:55:14 -0700 From: "Cihula, Joseph" To: Jeremy Fitzhardinge Subject: RE: [Xen-devel] RE: [PATCH 2/7] x86, acpi, tboot: Have a ACPI sleep override instead of calling tboot_sleep. Thread-Topic: [Xen-devel] RE: [PATCH 2/7] x86, acpi, tboot: Have a ACPI sleep override instead of calling tboot_sleep. Thread-Index: AQHMaAxpmDG2lzlV9k+vsLkLH7seFZVBWmyggAFRmAD//5HyUA== Date: Wed, 7 Sep 2011 17:55:14 +0000 Message-ID: <9F57BF860713DF4BA3EFA4F8C6DFEDAC16F40FBD@ORSMSX101.amr.corp.intel.com> References: <1314815484-4668-1-git-send-email-konrad.wilk@oracle.com> <1314815484-4668-3-git-send-email-konrad.wilk@oracle.com> <9F57BF860713DF4BA3EFA4F8C6DFEDAC16F3F524@ORSMSX101.amr.corp.intel.com> <4E67A972.6030909@goop.org> In-Reply-To: <4E67A972.6030909@goop.org> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.22.254.140] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "Brown, Len" , "Tian, Kevin" , "xen-devel@lists.xensource.com" , "keir@xen.org" , Konrad Rzeszutek Wilk , "Wang, Shane" , "x86@kernel.org" , "linux-acpi@vger.kernel.org" , "tboot-devel@lists.sourceforge.net" , "liang.tang@oracle.com" , "Yu, Ke" , "hpa@zytor.com" , "tglx@linutronix.de" , "linux-pm@lists.linux-foundation.org" X-BeenThere: xen-devel@lists.xensource.com X-Mailman-Version: 2.1.5 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xensource.com Errors-To: xen-devel-bounces@lists.xensource.com > From: Jeremy Fitzhardinge [mailto:jeremy@goop.org] > Sent: Wednesday, September 07, 2011 10:27 AM >=20 > On 09/06/2011 09:20 PM, Cihula, Joseph wrote: > >> From: Konrad Rzeszutek Wilk [mailto:konrad.wilk@oracle.com] > >> Sent: Wednesday, August 31, 2011 11:31 AM > >> > >> The ACPI suspend path makes a call to tboot_sleep right before it > >> writes the PM1A, PM1B values. We replace the direct call to tboot via = an registration callback > similar to __acpi_register_gsi. > >> > >> CC: Thomas Gleixner > >> CC: "H. Peter Anvin" > >> CC: x86@kernel.org > >> CC: Len Brown > >> CC: Joseph Cihula > >> CC: Shane Wang > >> CC: xen-devel@lists.xensource.com > >> CC: linux-pm@lists.linux-foundation.org > >> CC: tboot-devel@lists.sourceforge.net > >> CC: linux-acpi@vger.kernel.org > >> Signed-off-by: Konrad Rzeszutek Wilk > >> --- > >> arch/x86/include/asm/acpi.h | 3 +++ > >> arch/x86/kernel/acpi/boot.c | 3 +++ > >> arch/x86/kernel/tboot.c | 13 +++++++++---- > >> drivers/acpi/acpica/hwsleep.c | 12 ++++++++++-- > >> include/linux/tboot.h | 3 ++- > >> 5 files changed, 27 insertions(+), 7 deletions(-) > >> > >> diff --git a/arch/x86/include/asm/acpi.h > >> b/arch/x86/include/asm/acpi.h index 610001d..49864a1 > >> 100644 > >> --- a/arch/x86/include/asm/acpi.h > >> +++ b/arch/x86/include/asm/acpi.h > >> @@ -98,6 +98,9 @@ void acpi_pic_sci_set_trigger(unsigned int, u16); > >> extern int (*__acpi_register_gsi)(struct device *dev, u32 gsi, > >> int trigger, int polarity); > >> > >> +extern int (*__acpi_override_sleep)(u8 sleep_state, u32 pm1a_ctrl, > >> + u32 pm1b_ctrl, bool *skip_rest); > >> + > >> static inline void disable_acpi(void) { > >> acpi_disabled =3D 1; > >> diff --git a/arch/x86/kernel/acpi/boot.c > >> b/arch/x86/kernel/acpi/boot.c index 4558f0d..d191b4c > >> 100644 > >> --- a/arch/x86/kernel/acpi/boot.c > >> +++ b/arch/x86/kernel/acpi/boot.c > >> @@ -552,6 +552,9 @@ static int acpi_register_gsi_ioapic(struct device > >> *dev, u32 gsi, int (*__acpi_register_gsi)(struct device *dev, u32 gsi= , > >> int trigger, int polarity) =3D acpi_register_gsi_pic; > >> > >> +int (*__acpi_override_sleep)(u8 sleep_state, u32 pm1a_ctrl, > >> + u32 pm1b_ctrl, bool *skip_rest) =3D NULL; > >> + > >> /* > >> * success: return IRQ number (>=3D0) > >> * failure: return < 0 > >> diff --git a/arch/x86/kernel/tboot.c b/arch/x86/kernel/tboot.c index > >> 30ac65d..a18070c 100644 > >> --- a/arch/x86/kernel/tboot.c > >> +++ b/arch/x86/kernel/tboot.c > >> @@ -41,7 +41,7 @@ > >> #include > >> #include > >> #include > >> - > >> +#include > >> #include "acpi/realmode/wakeup.h" > >> > >> /* Global pointer to shared data; NULL means no measured launch. */ > >> @@ -270,7 +270,8 @@ static void tboot_copy_fadt(const struct acpi_tabl= e_fadt *fadt) > >> offsetof(struct acpi_table_facs, firmware_waking_vector); } > >> > >> -void tboot_sleep(u8 sleep_state, u32 pm1a_control, u32 pm1b_control) > >> +int tboot_sleep(u8 sleep_state, u32 pm1a_control, u32 pm1b_control, > >> + bool *skip_rest) > > Don't you need to use the 'unused' attrib on skip_rest in order to prev= ent compiler warnings? >=20 > No, gcc doesn't warn about unused parameters. -Wunused-parameter While the kernel may not be compiled with this flag, it wouldn't hurt to sp= ecify it anyway; but it's not a big issue. Joe _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel From xen-devel-bounces@lists.xensource.com Wed Sep 07 11:11:17 2011 Return-path: Envelope-to: www-data@lists.xensource.com Delivery-date: Wed, 07 Sep 2011 11:11:17 -0700 Received: from localhost ([127.0.0.1] helo=lists.colo.xensource.com) by lists.xensource.com with esmtp (Exim 4.43) id 1R1Maj-0000QI-O2; Wed, 07 Sep 2011 11:11:17 -0700 Received: from mail21.messagelabs.com ([85.158.143.35]) by lists.xensource.com with esmtp (Exim 4.43) id 1R1MZV-00006j-Vm for xen-devel@lists.xensource.com; Wed, 07 Sep 2011 11:10:05 -0700 X-Env-Sender: konrad@dumpdata.com X-Msg-Ref: server-9.tower-21.messagelabs.com!1315418954!47542669!1 X-Originating-IP: [148.87.113.117] X-StarScan-Version: 6.3.6; banners=-,-,- X-VirusChecked: Checked Received: (qmail 20760 invoked from network); 7 Sep 2011 18:09:16 -0000 Received: from rcsinet15.oracle.com (HELO rcsinet15.oracle.com) (148.87.113.117) by server-9.tower-21.messagelabs.com with DHE-RSA-AES256-SHA encrypted SMTP; 7 Sep 2011 18:09:16 -0000 Received: from acsinet21.oracle.com (acsinet21.oracle.com [141.146.126.237]) by rcsinet15.oracle.com (Switch-3.4.4/Switch-3.4.4) with ESMTP id p87I9qcF013280 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Wed, 7 Sep 2011 18:09:54 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 p87I9pTL023021 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 7 Sep 2011 18:09:52 GMT Received: from abhmt117.oracle.com (abhmt117.oracle.com [141.146.116.69]) by acsmt358.oracle.com (8.12.11.20060308/8.12.11) with ESMTP id p87I9k0m004047; Wed, 7 Sep 2011 13:09:46 -0500 Received: from phenom (/209.6.55.207) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Wed, 07 Sep 2011 11:09:46 -0700 Received: by phenom (Postfix, from userid 1000) id B095E10B8; Wed, 7 Sep 2011 14:09:33 -0400 (EDT) Date: Wed, 7 Sep 2011 14:09:33 -0400 From: Konrad Rzeszutek Wilk To: David Vrabel Message-ID: <20110907180933.GA5888@dumpdata.com> References: <1313765840-22084-1-git-send-email-david.vrabel@citrix.com> <1313765840-22084-4-git-send-email-david.vrabel@citrix.com> <20110906215706.GC24860@dumpdata.com> <4E674B14.4090306@citrix.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <4E674B14.4090306@citrix.com> User-Agent: Mutt/1.5.21 (2010-09-15) X-Source-IP: acsinet21.oracle.com [141.146.126.237] X-Auth-Type: Internal IP X-CT-RefId: str=0001.0A090206.4E67B372.015F:SCFMA922111,ss=1,re=-4.000,fgs=0 Cc: "xen-devel@lists.xensource.com" Subject: [Xen-devel] Re: [PATCH 3/5] xen: allow balloon driver to use more than one memory region X-BeenThere: xen-devel@lists.xensource.com X-Mailman-Version: 2.1.5 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xensource.com Errors-To: xen-devel-bounces@lists.xensource.com On Wed, Sep 07, 2011 at 11:44:36AM +0100, David Vrabel wrote: > On 06/09/11 22:57, Konrad Rzeszutek Wilk wrote: > > On Fri, Aug 19, 2011 at 03:57:18PM +0100, David Vrabel wrote: > >> > >> +static void __init balloon_add_memory_region(unsigned long start_pfn, unsigned long pages) > > > > That looks suspiciously like it has more than 80 lines. You ran the > > _all_ of the patches through scripts/checkpath.pl right? > > Yes, I used checkpatch.pl but I tend to treat the 80 character limit as > a guideline rather than a hard limit and only pay attention to it if > breaking a line improves readability. > > I assume your preference is for an 80 character hard limit? Please. > > >> { > >> - domid_t domid = DOMID_SELF; > >> unsigned long pfn, extra_pfn_end; > >> struct page *page; > >> + > >> + /* > >> + * Initialise the balloon with excess memory space. We need > >> + * to make sure we don't add memory which doesn't exist or > >> + * logically exist. The E820 map can be trimmed to be smaller > >> + * than the amount of physical memory due to the mem= command > >> + * line parameter. And if this is a 32-bit non-HIGHMEM kernel > >> + * on a system with memory which requires highmem to access, > >> + * don't try to use it. > > > > > > That whole comment is just confusing.. But I do know that you > > just moved it, but I wonder if it makes sense to remove it or > > alter it in the future. > > I think the comment is valid. Can define "logically exist" ? or "non-HIGHMEM kernel .. don't try to use it' - but we do use it. > > >> + */ > >> + extra_pfn_end = min(min(max_pfn, e820_end_of_ram_pfn()), > >> + start_pfn + pages); > > It's this line that it's documenting. > > >> --- a/include/xen/page.h > >> +++ b/include/xen/page.h > >> @@ -3,6 +3,13 @@ > >> > >> #include > >> > >> -extern phys_addr_t xen_extra_mem_start, xen_extra_mem_size; > >> +struct xen_memory_region { > >> + phys_addr_t start; > >> + phys_addr_t size; > >> +}; > >> + > >> +#define XEN_EXTRA_MEM_MAX_REGIONS 128 /* == E820MAX */ > >> + > >> +extern struct xen_memory_region xen_extra_mem[XEN_EXTRA_MEM_MAX_REGIONS]; > > > > __initdata > > Only the definition (in arch/x86/xen/setup.c) needs the __initdata > attribute, right? Right, but you might wnat to put in here too so folks won't try to use past __init. Or just stick a comment in there warning folks about it. > > I just checked and it does end up in the .init.data section. > > David _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel From xen-devel-bounces@lists.xensource.com Wed Sep 07 11:18:20 2011 Return-path: Envelope-to: www-data@lists.xensource.com Delivery-date: Wed, 07 Sep 2011 11:18:20 -0700 Received: from localhost ([127.0.0.1] helo=lists.colo.xensource.com) by lists.xensource.com with esmtp (Exim 4.43) id 1R1MhY-0000sh-GW; Wed, 07 Sep 2011 11:18:20 -0700 Received: from mail174.messagelabs.com ([85.158.138.51]) by lists.xensource.com with esmtp (Exim 4.43) id 1R1Mh5-0000g6-9k for xen-devel@lists.xensource.com; Wed, 07 Sep 2011 11:17:53 -0700 X-Env-Sender: Ian.Campbell@eu.citrix.com X-Msg-Ref: server-11.tower-174.messagelabs.com!1315419466!30599893!1 X-Originating-IP: [66.165.176.89] X-StarScan-Version: 6.3.6; banners=-,-,- X-VirusChecked: Checked Received: (qmail 1054 invoked from network); 7 Sep 2011 18:17:48 -0000 Received: from smtp.citrix.com (HELO SMTP.CITRIX.COM) (66.165.176.89) by server-11.tower-174.messagelabs.com with RC4-SHA encrypted SMTP; 7 Sep 2011 18:17:48 -0000 X-IronPort-AV: E=Sophos;i="4.68,346,1312171200"; d="scan'208";a="16771694" Received: from ftlpmailmx02.citrite.net ([10.13.107.66]) by FTLPIPO01.CITRIX.COM with ESMTP/TLS/RC4-MD5; 07 Sep 2011 14:17:46 -0400 Received: from [127.0.0.1] (10.80.16.67) by smtprelay.citrix.com (10.13.107.66) with Microsoft SMTP Server id 8.3.137.0; Wed, 7 Sep 2011 14:17:46 -0400 Subject: Re: [Xen-devel] [PATCH 1/2] Introduce support for upstream qemu in the xen-unstable build system From: Ian Campbell To: Stefano Stabellini Date: Wed, 7 Sep 2011 11:17:43 -0700 In-Reply-To: References: <1315406398-8987-1-git-send-email-stefano.stabellini@eu.citrix.com> <1315412504.3180.20.camel@cthulhu.hellion.org.uk> Organization: Citrix Systems, Inc. Content-Type: text/plain; charset="UTF-8" X-Mailer: Evolution 3.0.3- Content-Transfer-Encoding: 7bit Message-ID: <1315419466.3180.34.camel@cthulhu.hellion.org.uk> MIME-Version: 1.0 Cc: "xen-devel@lists.xensource.com" , "keir@xen.org" X-BeenThere: xen-devel@lists.xensource.com X-Mailman-Version: 2.1.5 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xensource.com Errors-To: xen-devel-bounces@lists.xensource.com On Wed, 2011-09-07 at 12:54 -0400, Stefano Stabellini wrote: > On Wed, 7 Sep 2011, Ian Campbell wrote: > > On Wed, 2011-09-07 at 10:39 -0400, stefano.stabellini@eu.citrix.com > > wrote: > > > In order to distinguish between upstream qemu and qemu-xen I am > > > introducing a new variable named "QEMU" that only if is equal to > > > "upstream" switches the build system to the new qemu. > > > > Thanks Stefano, this integrated support is overdue. > > > > Ultimately though I expect we will need a "both" mode since people will > > want old qemu for compatibility with their existing installed guests and > > new qemu for new ones. The allegation (and I don't really know how true > > it is or if it is pessimism or realism) is that some OSes don't cope > > with having the platform components etc changed under them. > > Yes. At that point we'll probably have to always build them both, Why wait? Why not just do that now. > including two hvmloader... Only one hvmloader will be needed, it will include both rombios and seabios support and it selects the right one at boot time, since the toolstack pushes down the choice. This is what happens today if you turn on the SEABIOS option. > > > Users that want to try the new qemu just have to export QEMU=upstream > > > before calling make in the xen-unstable top level directory. > > > > In xl/libxl we call them "qemu-xen-traditional" and "qemu-xen". Perhaps > > we should mirror that nomenclature here? > > I looked at libxl but I thought that QEMU=qemu-xen would be confusing for > users/developers. > Like you said, considering that we already have > device_model_version=qemu-xen in VM config files, maybe we should go for > DEVICE_MODEL=qemu-xen? With the (current) default being DEVICE_MODEL=qemu-xen-traditional? That would makes sense to me (excepting that, as above, I think we shouldn't offer it as a choice in the first place). Ian. _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel From xen-devel-bounces@lists.xensource.com Wed Sep 07 11:26:15 2011 Return-path: Envelope-to: www-data@lists.xensource.com Delivery-date: Wed, 07 Sep 2011 11:26:15 -0700 Received: from localhost ([127.0.0.1] helo=lists.colo.xensource.com) by lists.xensource.com with esmtp (Exim 4.43) id 1R1MpD-0004hs-Bk; Wed, 07 Sep 2011 11:26:15 -0700 Received: from mail174.messagelabs.com ([85.158.138.51]) by lists.xensource.com with esmtp (Exim 4.43) id 1R1MnF-0003a0-Nh for xen-devel@lists.xensource.com; Wed, 07 Sep 2011 11:24:14 -0700 X-Env-Sender: konrad@dumpdata.com X-Msg-Ref: server-8.tower-174.messagelabs.com!1315419849!16924446!1 X-Originating-IP: [141.146.126.227] X-StarScan-Version: 6.3.6; banners=-,-,- X-VirusChecked: Checked Received: (qmail 24524 invoked from network); 7 Sep 2011 18:24:10 -0000 Received: from acsinet15.oracle.com (HELO acsinet15.oracle.com) (141.146.126.227) by server-8.tower-174.messagelabs.com with DHE-RSA-AES256-SHA encrypted SMTP; 7 Sep 2011 18:24:10 -0000 Received: from acsinet21.oracle.com (acsinet21.oracle.com [141.146.126.237]) by acsinet15.oracle.com (Switch-3.4.4/Switch-3.4.4) with ESMTP id p87INwA4000570 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Wed, 7 Sep 2011 18:24:00 GMT Received: from acsmt356.oracle.com (acsmt356.oracle.com [141.146.40.156]) by acsinet21.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id p87INwWY021596 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 7 Sep 2011 18:23:58 GMT Received: from abhmt109.oracle.com (abhmt109.oracle.com [141.146.116.61]) by acsmt356.oracle.com (8.12.11.20060308/8.12.11) with ESMTP id p87INq9J021790; Wed, 7 Sep 2011 13:23:53 -0500 Received: from phenom (/209.6.55.207) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Wed, 07 Sep 2011 11:23:52 -0700 Received: by phenom (Postfix, from userid 1000) id 6042110B8; Wed, 7 Sep 2011 14:23:40 -0400 (EDT) Date: Wed, 7 Sep 2011 14:23:40 -0400 From: Konrad Rzeszutek Wilk To: David Vrabel Message-ID: <20110907182340.GB5888@dumpdata.com> References: <1313765840-22084-1-git-send-email-david.vrabel@citrix.com> <1313765840-22084-6-git-send-email-david.vrabel@citrix.com> <20110906212046.GA24860@dumpdata.com> <4E674F82.40507@citrix.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <4E674F82.40507@citrix.com> User-Agent: Mutt/1.5.21 (2010-09-15) X-Source-IP: acsinet21.oracle.com [141.146.126.237] X-Auth-Type: Internal IP X-CT-RefId: str=0001.0A090205.4E67B6C0.01D5:SCFMA922111,ss=1,re=-4.000,fgs=0 Cc: "xen-devel@lists.xensource.com" , David Vrabel Subject: [Xen-devel] Re: [PATCH 5/5] xen: release all pages within 1-1 p2m mappings X-BeenThere: xen-devel@lists.xensource.com X-Mailman-Version: 2.1.5 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xensource.com Errors-To: xen-devel-bounces@lists.xensource.com On Wed, Sep 07, 2011 at 12:03:30PM +0100, David Vrabel wrote: > On 06/09/11 22:20, Konrad Rzeszutek Wilk wrote: > > On Fri, Aug 19, 2011 at 03:57:20PM +0100, David Vrabel wrote: > >> > >> --- a/arch/x86/xen/setup.c > >> +++ b/arch/x86/xen/setup.c > >> @@ -123,73 +123,33 @@ static unsigned long __init xen_release_chunk(phys_addr_t start_addr, > >> return len; > >> } > >> > >> -static unsigned long __init xen_return_unused_memory(unsigned long max_pfn, > >> - const struct e820entry *map, > >> - int nr_map) > >> +static unsigned long __init xen_set_identity_and_release(const struct e820entry *list, > >> + ssize_t map_size, > >> + unsigned long nr_pages) > >> { > >> - phys_addr_t max_addr = PFN_PHYS(max_pfn); > >> - phys_addr_t last_end = ISA_END_ADDRESS; > >> + phys_addr_t avail_end = PFN_PHYS(nr_pages); > >> + phys_addr_t last_end = 0; > >> unsigned long released = 0; > >> - int i; > >> - > >> - /* Free any unused memory above the low 1Mbyte. */ > >> - for (i = 0; i < nr_map && last_end < max_addr; i++) { > >> - phys_addr_t end = map[i].addr; > >> - end = min(max_addr, end); > >> - > >> - if (last_end < end) > >> - released += xen_release_chunk(last_end, end); > >> - last_end = max(last_end, map[i].addr + map[i].size); > >> - } > >> - > >> - if (last_end < max_addr) > >> - released += xen_release_chunk(last_end, max_addr); > >> - > >> - printk(KERN_INFO "released %lu pages of unused memory\n", released); > >> - return released; > >> -} > >> - > >> -static unsigned long __init xen_set_identity(const struct e820entry *list, > >> - ssize_t map_size) > >> -{ > >> - phys_addr_t last = xen_initial_domain() ? 0 : ISA_END_ADDRESS; > >> - phys_addr_t start_pci = last; > >> const struct e820entry *entry; > >> - unsigned long identity = 0; > >> int i; > >> > >> for (i = 0, entry = list; i < map_size; i++, entry++) { > >> - phys_addr_t start = entry->addr; > >> - phys_addr_t end = start + entry->size; > >> - > >> - if (start < last) > >> - start = last; > >> + phys_addr_t begin = last_end; > > > > The "begin" is a bit confusing. You are using the previous E820 entry's end - not > > the beginning of this E820 entry. Doing a s/begin/last_end/ makes > > the code a bit easier to understand. > > Really? It seems pretty clear to me that they're the beginning and end > of the memory range we're considering to release or map. > > That loop went through a number of variations and what's there is what I > think is the most readable. Please add a comment describing that. > > >> + phys_addr_t end = entry->addr + entry->size; > >> > >> - if (end <= start) > >> - continue; > >> + last_end = end; > > > > Please include the comment: > > /* This entry end. */ > > Not really in favour of little comments like this. I'll put a comment > above the loop. > > /* > * For each memory region consider whether to release and map the > * region and the preceeding gap (if any). > */ OK, can you expand it please to mention that you are evaluating the beginning and end of the memory range. Thanks! > > > OK, but you have ripped out the nice printk's that existed before. So add them > > back in: > > > > > > printk(KERN_INFO "released %lu pages of unused memory\n", released); > > printk(KERN_INFO "Set %ld page(s) to 1-1 mapping.\n", identity); > > > > as they are quite useful in the field. > > What problem are these useful for diagnosing that the remaining messages > (and the e820 map) don't tell you already? You get an idea of which are released and which ones are identity pages. The E820 won't tell you how many total got released. Well, you can figure out if you look at the E820, at the mem=X and do some decimal to hex conversations. Much easier just to look at the end result. > > xen_release_chunk: looking at area pfn 9e-100: 98 pages freed > 1-1 mapping on 9e->100 > 1-1 mapping on bf699->bf6af > 1-1 mapping on bf6af->bf6ce > 1-1 mapping on bf6ce->c0000 > 1-1 mapping on c0000->f0000 > 1-1 mapping on f0000->100000 Ok, but those are 'debug' version. The totals are for 'info' level Also, considering that the Red Hat guys posted patches to improve the look and feel of those printk's I don't want to them rip out. _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel From xen-devel-bounces@lists.xensource.com Wed Sep 07 11:37:13 2011 Return-path: Envelope-to: www-data@lists.xensource.com Delivery-date: Wed, 07 Sep 2011 11:37:13 -0700 Received: from localhost ([127.0.0.1] helo=lists.colo.xensource.com) by lists.xensource.com with esmtp (Exim 4.43) id 1R1Mzp-0005bG-CP; Wed, 07 Sep 2011 11:37:13 -0700 Received: from mail182.messagelabs.com ([85.158.139.83]) by lists.xensource.com with esmtp (Exim 4.43) id 1R1Myy-0005LP-PH for xen-devel@lists.xensource.com; Wed, 07 Sep 2011 11:36:21 -0700 X-Env-Sender: konrad@dumpdata.com X-Msg-Ref: server-8.tower-182.messagelabs.com!1315420576!17456914!1 X-Originating-IP: [141.146.126.227] X-StarScan-Version: 6.3.6; banners=-,-,- X-VirusChecked: Checked Received: (qmail 15321 invoked from network); 7 Sep 2011 18:36:17 -0000 Received: from acsinet15.oracle.com (HELO acsinet15.oracle.com) (141.146.126.227) by server-8.tower-182.messagelabs.com with DHE-RSA-AES256-SHA encrypted SMTP; 7 Sep 2011 18:36:17 -0000 Received: from acsinet21.oracle.com (acsinet21.oracle.com [141.146.126.237]) by acsinet15.oracle.com (Switch-3.4.4/Switch-3.4.4) with ESMTP id p87Ia8PC022525 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Wed, 7 Sep 2011 18:36:10 GMT Received: from acsmt358.oracle.com (acsmt358.oracle.com [141.146.40.158]) by acsinet21.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id p87Ia6He018528 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 7 Sep 2011 18:36:07 GMT Received: from abhmt101.oracle.com (abhmt101.oracle.com [141.146.116.53]) by acsmt358.oracle.com (8.12.11.20060308/8.12.11) with ESMTP id p87IZxk9023508; Wed, 7 Sep 2011 13:36:00 -0500 Received: from phenom (/209.6.55.207) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Wed, 07 Sep 2011 11:35:59 -0700 Received: by phenom (Postfix, from userid 1000) id 03A4C10B8; Wed, 7 Sep 2011 14:35:46 -0400 (EDT) Date: Wed, 7 Sep 2011 14:35:46 -0400 From: Konrad Rzeszutek Wilk To: Anthony Wright Subject: Re: [Xen-devel] Kernel bug from 3.0 (was phy disks and vifs timing out in DomU) Message-ID: <20110907183546.GB7074@dumpdata.com> References: <20110819125615.GA26558@dumpdata.com> <4E56B132.9050708@overnetdata.com> <20110826142606.GA25511@dumpdata.com> <20110826144438.GA24836@dumpdata.com> <4E5E6843.7050206@citrix.com> <20110831170711.GB13642@dumpdata.com> <1314862972.28989.74.camel@zakaz.uk.xensource.com> <20110901142356.GD23971@dumpdata.com> <4E5FA0C4.7000806@citrix.com> <4E676A52.8050907@overnetdata.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <4E676A52.8050907@overnetdata.com> User-Agent: Mutt/1.5.21 (2010-09-15) X-Source-IP: acsinet21.oracle.com [141.146.126.237] X-Auth-Type: Internal IP X-CT-RefId: str=0001.0A090201.4E67B99B.0052:SCFMA922111,ss=1,re=-4.000,fgs=0 Cc: Ian Campbell , Todd Deshane , "xen-devel@lists.xensource.com" , David Vrabel , Jeremy Fitzhardinge X-BeenThere: xen-devel@lists.xensource.com X-Mailman-Version: 2.1.5 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xensource.com Errors-To: xen-devel-bounces@lists.xensource.com > (XEN) mm.c:907:d0 Error getting mfn 3a09c (pfn 55555555) from L1 entry 000000003a09c023 for l1e_owner=0, pg_owner=0 > (XEN) mm.c:907:d0 Error getting mfn 3a09d (pfn 55555555) from L1 entry 000000003a09d023 for l1e_owner=0, pg_owner=0 > (XEN) mm.c:907:d0 Error getting mfn 3a09e (pfn 55555555) from L1 entry 000000003a09e023 for l1e_owner=0, pg_owner=0 > (XEN) mm.c:907:d0 Error getting mfn 3a09f (pfn 55555555) from L1 entry 000000003a09f023 for l1e_owner=0, pg_owner=0 > (XEN) traps.c:2388:d0 Domain attempted WRMSR c0010004 from 0x0000ab23d6d622da to 0x000000000000abcd. Do they show up during bootup? As in do you see those _when_ you launch your guests? To figure out this particular issue you should try using 'console_to_ring' (so that dom0 output and Xen output are mingled togehter) and also post this under a new subject to not confuse this email thread. > > _______________________________________________ > Xen-devel mailing list > Xen-devel@lists.xensource.com > http://lists.xensource.com/xen-devel _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel From xen-devel-bounces@lists.xensource.com Wed Sep 07 11:54:21 2011 Return-path: Envelope-to: www-data@lists.xensource.com Delivery-date: Wed, 07 Sep 2011 11:54:21 -0700 Received: from localhost ([127.0.0.1] helo=lists.colo.xensource.com) by lists.xensource.com with esmtp (Exim 4.43) id 1R1NGN-0006ZB-Th; Wed, 07 Sep 2011 11:54:19 -0700 Received: from mail216.messagelabs.com ([85.158.143.99]) by lists.xensource.com with esmtp (Exim 4.43) id 1R1NFP-0006ML-Ow for xen-devel@lists.xensource.com; Wed, 07 Sep 2011 11:53:20 -0700 X-Env-Sender: konrad@dumpdata.com X-Msg-Ref: server-8.tower-216.messagelabs.com!1315421595!15948313!1 X-Originating-IP: [148.87.113.117] X-StarScan-Version: 6.3.6; banners=-,-,- X-VirusChecked: Checked Received: (qmail 25974 invoked from network); 7 Sep 2011 18:53:16 -0000 Received: from rcsinet15.oracle.com (HELO rcsinet15.oracle.com) (148.87.113.117) by server-8.tower-216.messagelabs.com with DHE-RSA-AES256-SHA encrypted SMTP; 7 Sep 2011 18:53:16 -0000 Received: from acsinet22.oracle.com (acsinet22.oracle.com [141.146.126.238]) by rcsinet15.oracle.com (Switch-3.4.4/Switch-3.4.4) with ESMTP id p87IrAwH027024 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Wed, 7 Sep 2011 18:53:11 GMT Received: from acsmt358.oracle.com (acsmt358.oracle.com [141.146.40.158]) by acsinet22.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id p87Ir9V2017699 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 7 Sep 2011 18:53:09 GMT Received: from abhmt108.oracle.com (abhmt108.oracle.com [141.146.116.60]) by acsmt358.oracle.com (8.12.11.20060308/8.12.11) with ESMTP id p87Ir3hu004068; Wed, 7 Sep 2011 13:53:04 -0500 Received: from phenom (/209.6.55.207) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Wed, 07 Sep 2011 11:53:03 -0700 Received: by phenom (Postfix, from userid 1000) id B136E10B8; Wed, 7 Sep 2011 14:52:50 -0400 (EDT) Date: Wed, 7 Sep 2011 14:52:50 -0400 From: Konrad Rzeszutek Wilk To: David TECHER Subject: Re: Re : Re : Re : [Xen-devel] Re: Patches for VGA-Passthrough XEN 4.2 unstable Message-ID: <20110907185250.GE7074@dumpdata.com> References: <1314780568949-4753422.post@n5.nabble.com> <1314795401771-4754024.post@n5.nabble.com> <20110831151913.GE7276@reaktio.net> <1315231341254-4770602.post@n5.nabble.com> <1315310225039-4774097.post@n5.nabble.com> <1315343879.61837.YahooMailNeo@web29818.mail.ird.yahoo.com> <1315382742268-4777689.post@n5.nabble.com> <1315389138.56652.YahooMailNeo@web29801.mail.ird.yahoo.com> <1315398360680-4778339.post@n5.nabble.com> <1315399889.79555.YahooMailNeo@web29820.mail.ird.yahoo.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <1315399889.79555.YahooMailNeo@web29820.mail.ird.yahoo.com> User-Agent: Mutt/1.5.21 (2010-09-15) X-Source-IP: acsinet22.oracle.com [141.146.126.238] X-Auth-Type: Internal IP X-CT-RefId: str=0001.0A090204.4E67BD98.0053:SCFMA922111,ss=1,re=-4.000,fgs=0 Cc: komkon555 , "xen-devel@lists.xensource.com" X-BeenThere: xen-devel@lists.xensource.com X-Mailman-Version: 2.1.5 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xensource.com Errors-To: xen-devel-bounces@lists.xensource.com On Wed, Sep 07, 2011 at 01:51:29PM +0100, David TECHER wrote: > It is a great pleasure to know that is it working for you :) > > I've just updated the patchs sent by 'JavMV' on May 2011. Even if I'am not a Xen Developer > it will be a great idea if a real Xen Developer takes care of the patchs to improve it for Xen 4.2. Where are those patches? Can you attach them to this email? > > The next step was to understand how the patch for 'tools/firmware/hvmloader/acpi/dsdt.asl' > works. Once I've understood, I've patched for my own graphic card. _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel From xen-devel-bounces@lists.xensource.com Wed Sep 07 12:03:02 2011 Return-path: Envelope-to: www-data@lists.xensource.com Delivery-date: Wed, 07 Sep 2011 12:03:02 -0700 Received: from localhost ([127.0.0.1] helo=lists.colo.xensource.com) by lists.xensource.com with esmtp (Exim 4.43) id 1R1NOo-0007AM-HZ; Wed, 07 Sep 2011 12:03:02 -0700 Received: from mail21.messagelabs.com ([85.158.143.35]) by lists.xensource.com with esmtp (Exim 4.43) id 1R1NKm-0006uk-De for xen-devel@lists.xensource.com; Wed, 07 Sep 2011 11:59:46 -0700 X-Env-Sender: jeremy@goop.org X-Msg-Ref: server-11.tower-21.messagelabs.com!1315421911!41716844!1 X-Originating-IP: [74.207.240.146] X-StarScan-Version: 6.3.6; banners=-,-,- X-VirusChecked: Checked Received: (qmail 18762 invoked from network); 7 Sep 2011 18:58:32 -0000 Received: from claw.goop.org (HELO claw.goop.org) (74.207.240.146) by server-11.tower-21.messagelabs.com with DHE-RSA-AES256-SHA encrypted SMTP; 7 Sep 2011 18:58:32 -0000 Received: from saboo.goop.org (unknown [IPv6:2001:470:1f05:899:6801:ccff:fe7b:9751]) (Authenticated sender: smtp-saboo) by claw.goop.org (Postfix) with ESMTPSA id 61F638961; Wed, 7 Sep 2011 11:58:46 -0700 (PDT) Received: from saboo.goop.org (localhost [IPv6:::1]) by saboo.goop.org (Postfix) with ESMTP id 511A42021C; Wed, 7 Sep 2011 11:58:38 -0700 (PDT) Message-ID: <4E67BEDE.6080301@goop.org> Date: Wed, 07 Sep 2011 11:58:38 -0700 From: Jeremy Fitzhardinge User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:6.0) Gecko/20110816 Thunderbird/6.0 MIME-Version: 1.0 To: Konrad Rzeszutek Wilk Subject: Re: [Xen-devel] blkfront problem in pvops kernel when barriers enabled References: <4E6357C6.6050101@mimuw.edu.pl> <20110906163213.GC5264@dumpdata.com> <4E665572.7080009@mimuw.edu.pl> <20110907014741.GD30639@dumpdata.com> <4E67AB39.70801@goop.org> <20110907174314.GM32190@dumpdata.com> In-Reply-To: <20110907174314.GM32190@dumpdata.com> X-Enigmail-Version: 1.3.1 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: "xen-devel@lists.xensource.com" , Marek Marczykowski X-BeenThere: xen-devel@lists.xensource.com X-Mailman-Version: 2.1.5 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xensource.com Errors-To: xen-devel-bounces@lists.xensource.com On 09/07/2011 10:43 AM, Konrad Rzeszutek Wilk wrote: > On Wed, Sep 07, 2011 at 10:34:49AM -0700, Jeremy Fitzhardinge wrote: >> On 09/06/2011 06:47 PM, Konrad Rzeszutek Wilk wrote: >>> (on 3.1rc2) Looking to xenstore now there is 'feature-flush-cache=1' and >>> no 'feature-barrier'. So it is ok. >>> >>> >>> I can only think of 2.6.38-3 XenOLinux doing it - and it is a bug >>> to do it. It really ought to _not_ advertise 'feature-barrier' and >>> instead advertise 'feature-flush-cache'. >> Does that mean that older guests which don't understand flush-cache will >> be left with no way to force writes to stable storage? Seems to me that > Correct. >> even if the backend would prefer flush-cache, it should also advertise >> barriers. > But doing it incorrectly is bad - really bad. Well, there's "bad performance" and "bad oops we lost data". If the backend emulates a barrier by doing a drain, flush, write, drain, flush then I think that should be safe, but definitely not quick. >> However, that raises the question of how to express the preferred >> mechanism if multiple are available. You could assume that flush-cache >> is always preferred if available, but that's pretty clunky. > That is how I did it in the frontend. OK, how about this for a cheapo idea: make the feature-barrier/flush-cache files contain a priority: 0 = "do not use", non-zero = bigger the better? That way we can have barrier-preferring backends also support flush. I suppose. Really, frontends should also try to make do with whatever the backend supports, even if its not preferred as well. J _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel From xen-devel-bounces@lists.xensource.com Wed Sep 07 12:08:36 2011 Return-path: Envelope-to: www-data@lists.xensource.com Delivery-date: Wed, 07 Sep 2011 12:08:36 -0700 Received: from localhost ([127.0.0.1] helo=lists.colo.xensource.com) by lists.xensource.com with esmtp (Exim 4.43) id 1R1NUB-0008TN-UJ; Wed, 07 Sep 2011 12:08:35 -0700 Received: from mail216.messagelabs.com ([85.158.143.99]) by lists.xensource.com with esmtp (Exim 4.43) id 1R1NR9-0007ZS-Rt for xen-devel@lists.xensource.com; Wed, 07 Sep 2011 12:05:30 -0700 X-Env-Sender: jeremy@goop.org X-Msg-Ref: server-11.tower-216.messagelabs.com!1315422323!9856996!1 X-Originating-IP: [74.207.240.146] X-StarScan-Version: 6.3.6; banners=-,-,- X-VirusChecked: Checked Received: (qmail 12399 invoked from network); 7 Sep 2011 19:05:24 -0000 Received: from claw.goop.org (HELO claw.goop.org) (74.207.240.146) by server-11.tower-216.messagelabs.com with DHE-RSA-AES256-SHA encrypted SMTP; 7 Sep 2011 19:05:24 -0000 Received: from saboo.goop.org (unknown [IPv6:2001:470:1f05:899:6801:ccff:fe7b:9751]) (Authenticated sender: smtp-saboo) by claw.goop.org (Postfix) with ESMTPSA id 8FCDD8A00; Wed, 7 Sep 2011 12:05:22 -0700 (PDT) Received: from saboo.goop.org (localhost [IPv6:::1]) by saboo.goop.org (Postfix) with ESMTP id B0382200A1; Wed, 7 Sep 2011 12:05:18 -0700 (PDT) Message-ID: <4E67C06E.1030905@goop.org> Date: Wed, 07 Sep 2011 12:05:18 -0700 From: Jeremy Fitzhardinge User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:6.0) Gecko/20110816 Thunderbird/6.0 MIME-Version: 1.0 To: Stefano Stabellini References: <1315413571-10938-2-git-send-email-stefano.stabellini@eu.citrix.com> <4E67A646.7000405@goop.org> In-Reply-To: X-Enigmail-Version: 1.3.1 Content-Type: text/plain; charset=ISO-8859-15 Content-Transfer-Encoding: 7bit Cc: Ian Campbell , "xen-devel@lists.xensource.com" , "linux-kernel@vger.kernel.org" , "konrad.wilk@oracle.com" Subject: [Xen-devel] Re: [PATCH v3 2/2] xen: modify kernel mappings corresponding to granted pages X-BeenThere: xen-devel@lists.xensource.com X-Mailman-Version: 2.1.5 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xensource.com Errors-To: xen-devel-bounces@lists.xensource.com On 09/07/2011 10:38 AM, Stefano Stabellini wrote: > >> But also, this pattern of getting results back from batched calls is >> unusual - actually, I think this is unique. If you have batched up a >> map operation which has its map_op args allocated from the multicall >> buffer, then the flush will implicitly free them as well, so it isn't >> valid to read back from the structure later on. If you want to have an >> args structure you can use once the hypercall has been issued, you need >> to manually manage its lifetime. > But I am not using the multicall buffer as argument, I am using the > kmap_op passed to m2p_add_override. Yep, I overlooked that. J _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel From xen-devel-bounces@lists.xensource.com Wed Sep 07 12:09:52 2011 Return-path: Envelope-to: www-data@lists.xensource.com Delivery-date: Wed, 07 Sep 2011 12:09:52 -0700 Received: from localhost ([127.0.0.1] helo=lists.colo.xensource.com) by lists.xensource.com with esmtp (Exim 4.43) id 1R1NVQ-0000PP-C8; Wed, 07 Sep 2011 12:09:52 -0700 Received: from mail27.messagelabs.com ([193.109.254.147]) by lists.xensource.com with esmtp (Exim 4.43) id 1R1NUz-0000Cr-Q1 for xen-devel@lists.xensource.com; Wed, 07 Sep 2011 12:09:26 -0700 X-Env-Sender: jeremy@goop.org X-Msg-Ref: server-12.tower-27.messagelabs.com!1315422547!41491788!1 X-Originating-IP: [74.207.240.146] X-StarScan-Version: 6.3.6; banners=-,-,- X-VirusChecked: Checked Received: (qmail 26531 invoked from network); 7 Sep 2011 19:09:09 -0000 Received: from claw.goop.org (HELO claw.goop.org) (74.207.240.146) by server-12.tower-27.messagelabs.com with DHE-RSA-AES256-SHA encrypted SMTP; 7 Sep 2011 19:09:09 -0000 Received: from saboo.goop.org (unknown [IPv6:2001:470:1f05:899:6801:ccff:fe7b:9751]) (Authenticated sender: smtp-saboo) by claw.goop.org (Postfix) with ESMTPSA id 7E1B18A2C; Wed, 7 Sep 2011 12:09:20 -0700 (PDT) Received: from saboo.goop.org (localhost [IPv6:::1]) by saboo.goop.org (Postfix) with ESMTP id 9810320929; Wed, 7 Sep 2011 12:09:15 -0700 (PDT) Message-ID: <4E67C15B.3000408@goop.org> Date: Wed, 07 Sep 2011 12:09:15 -0700 From: Jeremy Fitzhardinge User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:6.0) Gecko/20110816 Thunderbird/6.0 MIME-Version: 1.0 To: Avi Kivity References: <1314996468.8255.0.camel@twins> <4E614FBD.2030509@goop.org> <20110906151408.GA7459@redhat.com> <4E66615E.8070806@goop.org> <20110906182758.GR5795@redhat.com> <4E66EF86.9070200@redhat.com> <20110907134411.GV5795@redhat.com> <4E678992.5050709@redhat.com> <20110907155657.GX5795@redhat.com> <4E679AF4.50209@redhat.com> <20110907165203.GQ6838@redhat.com> <4E67A551.4000502@redhat.com> <4E67A71A.5070903@goop.org> <4E67ACB6.40107@redhat.com> In-Reply-To: <4E67ACB6.40107@redhat.com> X-Enigmail-Version: 1.3.1 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: Don Zickus , Marcelo Tosatti , Nick Piggin , KVM , Stefano Stabellini , Peter Zijlstra , the arch/x86 maintainers , Linux Kernel Mailing List , Andi Kleen , Jeremy Fitzhardinge , "H. Peter Anvin" , Ingo Molnar , Linus Torvalds , Xen Devel Subject: [Xen-devel] Re: [PATCH 08/13] xen/pvticketlock: disable interrupts while blocking X-BeenThere: xen-devel@lists.xensource.com X-Mailman-Version: 2.1.5 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xensource.com Errors-To: xen-devel-bounces@lists.xensource.com On 09/07/2011 10:41 AM, Avi Kivity wrote: >> Hm, I'm interested to know what you're thinking in more detail. Can you >> leave an NMI pending before you block in the same way you can with >> "sti;halt" with normal interrupts? > > > Nope. But you can do > > if (regs->rip in critical section) > regs->rip = after_halt; > > and effectively emulate it. The critical section is something like > > critical_section_start: > if (woken_up) > goto critical_section_end; > hlt > critical_section_end: Hm. It's a pity you have to deliver an actual interrupt to implement the kick though. >> >> I was thinking you might want to do something with monitor/mwait to >> implement the blocking/kick ops. (Handwave) >> > > monitor/mwait are incredibly expensive to virtualize since they > require write-protecting a page, IPIs flying everywhere and flushing > tlbs, not to mention my lovely hugepages being broken up mercilessly. Or what about a futex-like hypercall? J _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel From xen-devel-bounces@lists.xensource.com Wed Sep 07 12:12:01 2011 Return-path: Envelope-to: www-data@lists.xensource.com Delivery-date: Wed, 07 Sep 2011 12:12:01 -0700 Received: from localhost ([127.0.0.1] helo=lists.colo.xensource.com) by lists.xensource.com with esmtp (Exim 4.43) id 1R1NXV-0000nc-1G; Wed, 07 Sep 2011 12:12:01 -0700 Received: from mail216.messagelabs.com ([85.158.143.99]) by lists.xensource.com with esmtp (Exim 4.43) id 1R1NX2-0000bT-76 for xen-devel@lists.xensource.com; Wed, 07 Sep 2011 12:11:32 -0700 X-Env-Sender: konrad@dumpdata.com X-Msg-Ref: server-6.tower-216.messagelabs.com!1315422687!16173209!1 X-Originating-IP: [141.146.126.227] X-StarScan-Version: 6.3.6; banners=-,-,- X-VirusChecked: Checked Received: (qmail 6439 invoked from network); 7 Sep 2011 19:11:29 -0000 Received: from acsinet15.oracle.com (HELO acsinet15.oracle.com) (141.146.126.227) by server-6.tower-216.messagelabs.com with DHE-RSA-AES256-SHA encrypted SMTP; 7 Sep 2011 19:11:29 -0000 Received: from rtcsinet22.oracle.com (rtcsinet22.oracle.com [66.248.204.30]) by acsinet15.oracle.com (Switch-3.4.4/Switch-3.4.4) with ESMTP id p87J7Pw1017044 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Wed, 7 Sep 2011 19:07:27 GMT Received: from acsmt357.oracle.com (acsmt357.oracle.com [141.146.40.157]) by rtcsinet22.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id p87J7J8p002484 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 7 Sep 2011 19:07:20 GMT Received: from abhmt108.oracle.com (abhmt108.oracle.com [141.146.116.60]) by acsmt357.oracle.com (8.12.11.20060308/8.12.11) with ESMTP id p87J7DSj012011; Wed, 7 Sep 2011 14:07:13 -0500 Received: from phenom (/209.6.55.207) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Wed, 07 Sep 2011 12:07:12 -0700 Received: by phenom (Postfix, from userid 1000) id 8237910B8; Wed, 7 Sep 2011 15:06:59 -0400 (EDT) Date: Wed, 7 Sep 2011 15:06:59 -0400 From: Konrad Rzeszutek Wilk To: "Cihula, Joseph" Subject: Re: [Xen-devel] RE: [PATCH 5/7] xen/acpi: Domain0 acpi parser related platform hypercall Message-ID: <20110907190659.GH7074@dumpdata.com> References: <1314815484-4668-1-git-send-email-konrad.wilk@oracle.com> <1314815484-4668-6-git-send-email-konrad.wilk@oracle.com> <9F57BF860713DF4BA3EFA4F8C6DFEDAC16F3F665@ORSMSX101.amr.corp.intel.com> <4E67A9E7.2020802@goop.org> <9F57BF860713DF4BA3EFA4F8C6DFEDAC16F40F0B@ORSMSX101.amr.corp.intel.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <9F57BF860713DF4BA3EFA4F8C6DFEDAC16F40F0B@ORSMSX101.amr.corp.intel.com> User-Agent: Mutt/1.5.21 (2010-09-15) X-Source-IP: rtcsinet22.oracle.com [66.248.204.30] X-CT-RefId: str=0001.0A02020A.4E67C0F0.010F,ss=1,re=0.000,fgs=0 Cc: "Brown, Len" , Jeremy Fitzhardinge , "xen-devel@lists.xensource.com" , "keir@xen.org" , "x86@kernel.org" , "Tian, Kevin" , "Wei, Gang" , "linux-acpi@vger.kernel.org" , "tboot-devel@lists.sourceforge.net" , Fitzhardinge , "tglx@linutronix.de" , "Yu, Ke" , "hpa@zytor.com" , "liang.tang@oracle.com" , "linux-pm@lists.linux-foundation.org" X-BeenThere: xen-devel@lists.xensource.com X-Mailman-Version: 2.1.5 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xensource.com Errors-To: xen-devel-bounces@lists.xensource.com > > >> +#define XENPF_enter_acpi_sleep 51 > > >> +struct xenpf_enter_acpi_sleep { > > >> + /* IN variables */ > > >> + uint16_t pm1a_cnt_val; /* PM1a control value. */ > > >> + uint16_t pm1b_cnt_val; /* PM1b control value. */ > > > These are uint32_t in native Linux--why truncate in the API and not at use? > > > > Does ACPI define them as 32 or 16 bit? > > The spec indicates that the length is variable and could be up to 32 bits (AFAICT). And Linux uses 32b, which your other patch is truncating for this call. Yikes! Well, looks like we need to fix the Xen ABI too. Lets get that fixed and also address all the other comments (thanks for looking at it) you pointed out. _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel From xen-devel-bounces@lists.xensource.com Wed Sep 07 12:32:50 2011 Return-path: Envelope-to: www-data@lists.xensource.com Delivery-date: Wed, 07 Sep 2011 12:32:50 -0700 Received: from localhost ([127.0.0.1] helo=lists.colo.xensource.com) by lists.xensource.com with esmtp (Exim 4.43) id 1R1Nrd-0002C0-Pv; Wed, 07 Sep 2011 12:32:49 -0700 Received: from mail174.messagelabs.com ([85.158.138.51]) by lists.xensource.com with esmtp (Exim 4.43) id 1R1Nr6-0001xo-A0 for xen-devel@lists.xensource.com; Wed, 07 Sep 2011 12:32:16 -0700 X-Env-Sender: konrad@dumpdata.com X-Msg-Ref: server-8.tower-174.messagelabs.com!1315423931!16928445!1 X-Originating-IP: [141.146.126.227] X-StarScan-Version: 6.3.6; banners=-,-,- X-VirusChecked: Checked Received: (qmail 18001 invoked from network); 7 Sep 2011 19:32:12 -0000 Received: from acsinet15.oracle.com (HELO acsinet15.oracle.com) (141.146.126.227) by server-8.tower-174.messagelabs.com with DHE-RSA-AES256-SHA encrypted SMTP; 7 Sep 2011 19:32:12 -0000 Received: from rtcsinet22.oracle.com (rtcsinet22.oracle.com [66.248.204.30]) by acsinet15.oracle.com (Switch-3.4.4/Switch-3.4.4) with ESMTP id p87JW7TN026723 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Wed, 7 Sep 2011 19:32:09 GMT Received: from acsmt356.oracle.com (acsmt356.oracle.com [141.146.40.156]) by rtcsinet22.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id p87JW5WB008281 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 7 Sep 2011 19:32:06 GMT Received: from abhmt116.oracle.com (abhmt116.oracle.com [141.146.116.68]) by acsmt356.oracle.com (8.12.11.20060308/8.12.11) with ESMTP id p87JVwvn006915; Wed, 7 Sep 2011 14:31:59 -0500 Received: from phenom (/209.6.55.207) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Wed, 07 Sep 2011 12:31:58 -0700 Received: by phenom (Postfix, from userid 1000) id 384A910B8; Wed, 7 Sep 2011 15:31:46 -0400 (EDT) Date: Wed, 7 Sep 2011 15:31:46 -0400 From: Konrad Rzeszutek Wilk To: Jeremy Fitzhardinge Subject: Re: [Xen-devel] blkfront problem in pvops kernel when barriers enabled Message-ID: <20110907193146.GJ7074@dumpdata.com> References: <4E6357C6.6050101@mimuw.edu.pl> <20110906163213.GC5264@dumpdata.com> <4E665572.7080009@mimuw.edu.pl> <20110907014741.GD30639@dumpdata.com> <4E67AB39.70801@goop.org> <20110907174314.GM32190@dumpdata.com> <4E67BEDE.6080301@goop.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <4E67BEDE.6080301@goop.org> User-Agent: Mutt/1.5.21 (2010-09-15) X-Source-IP: rtcsinet22.oracle.com [66.248.204.30] X-CT-RefId: str=0001.0A090205.4E67C6B9.00F0,ss=1,re=0.000,fgs=0 Cc: "xen-devel@lists.xensource.com" , Marek Marczykowski X-BeenThere: xen-devel@lists.xensource.com X-Mailman-Version: 2.1.5 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xensource.com Errors-To: xen-devel-bounces@lists.xensource.com On Wed, Sep 07, 2011 at 11:58:38AM -0700, Jeremy Fitzhardinge wrote: > On 09/07/2011 10:43 AM, Konrad Rzeszutek Wilk wrote: > > On Wed, Sep 07, 2011 at 10:34:49AM -0700, Jeremy Fitzhardinge wrote: > >> On 09/06/2011 06:47 PM, Konrad Rzeszutek Wilk wrote: > >>> (on 3.1rc2) Looking to xenstore now there is 'feature-flush-cache=1' and > >>> no 'feature-barrier'. So it is ok. > >>> > >>> > >>> I can only think of 2.6.38-3 XenOLinux doing it - and it is a bug > >>> to do it. It really ought to _not_ advertise 'feature-barrier' and > >>> instead advertise 'feature-flush-cache'. > >> Does that mean that older guests which don't understand flush-cache will > >> be left with no way to force writes to stable storage? Seems to me that > > Correct. > >> even if the backend would prefer flush-cache, it should also advertise > >> barriers. > > But doing it incorrectly is bad - really bad. > > Well, there's "bad performance" and "bad oops we lost data". If the > backend emulates a barrier by doing a drain, flush, write, drain, flush > then I think that should be safe, but definitely not quick. Which it looks like we need to do. Stop the processing of the ring buffer and do that sequence of events you mentioned. Which would entail waiting for all of the bio callbacks to finish. > > >> However, that raises the question of how to express the preferred > >> mechanism if multiple are available. You could assume that flush-cache > >> is always preferred if available, but that's pretty clunky. > > That is how I did it in the frontend. > > OK, how about this for a cheapo idea: make the > feature-barrier/flush-cache files contain a priority: 0 = "do not use", > non-zero = bigger the better? That way we can have barrier-preferring > backends also support flush. I suppose. Well, the "older" backends could emulate the 'feature-flush-cache' .. except it is not really right - but it will do the same thing - stop and drain the queue (except actually flushing the contents to the disk). So perhaps the right way to implement this in the "old" backends is to also send SYNC along. I think I am dense today , but the issue I am seeing is issue is with "old" frontends (RHEL5) with "new" backends (3.0 and higher) - where there is no 'feature-barrier' support. So they won't do barriers. > > Really, frontends should also try to make do with whatever the backend > supports, even if its not preferred as well. Sure. That is how they do it now. If it can do barriers - it will do BLKIF_OP_BARRIER. If it can do flush, it will do BLKIF_OP_FLUSH. Either one is used when the frontend gets REQ_FLUSH || REQ_FUA command. > > J _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel From xen-devel-bounces@lists.xensource.com Wed Sep 07 12:37:36 2011 Return-path: Envelope-to: www-data@lists.xensource.com Delivery-date: Wed, 07 Sep 2011 12:37:36 -0700 Received: from localhost ([127.0.0.1] helo=lists.colo.xensource.com) by lists.xensource.com with esmtp (Exim 4.43) id 1R1NwG-0002ha-3k; Wed, 07 Sep 2011 12:37:36 -0700 Received: from mail174.messagelabs.com ([85.158.138.51]) by lists.xensource.com with esmtp (Exim 4.43) id 1R1Nvm-0002Tj-EB for xen-devel@lists.xensource.com; Wed, 07 Sep 2011 12:37:06 -0700 X-Env-Sender: nathan@gt.net X-Msg-Ref: server-2.tower-174.messagelabs.com!1315424221!30609766!1 X-Originating-IP: [208.70.244.21] X-StarScan-Version: 6.3.6; banners=-,-,- X-VirusChecked: Checked Received: (qmail 2975 invoked from network); 7 Sep 2011 19:37:03 -0000 Received: from gossamer.nmsrv.com (HELO gossamer.nmsrv.com) (208.70.244.21) by server-2.tower-174.messagelabs.com with DHE-RSA-AES256-SHA encrypted SMTP; 7 Sep 2011 19:37:03 -0000 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=gt.net; h=message-id:date :from:mime-version:to:subject:content-type :content-transfer-encoding; s=mail; bh=7S5FaTiLxqU1Z48Kegu6lJz1L oU=; b=fy+WD74+B0oFsEd3Hj7mA9nENpFP9oWnB3FMm8xY+AX75R8ivyN15+PRM RKWCgoCFgpH4K/dnCJYm//9UziPuCuYXOhrvm5c23ylSItnVVcdW0O7LapynyPWv ll6UGbRqcCiKcfW35UEH9YotMrgAX5U60mn7tt5qMI3QaQ8sUw= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gt.net; h=message-id:date :from:mime-version:to:subject:content-type :content-transfer-encoding; q=dns; s=mail; b=H+Th4RIC6JPmnb3G1Hq rnYGmqHbXo4hoyfak2EkI7VX3QRaFhCgvNqDjuAgWLeJ2xW8wmsYzvQ3MNj0eAXC mqFu6JFPx1EwO/CP9lCT5668jH7uqUnaPsLidJmqstX9rIfmVfEuuqUGdZi+e4ar vEMNKDN9uDJSidh3Zke5R1Jk= Received: (qmail 31959 invoked from network); 7 Sep 2011 19:37:00 -0000 X-AntiVirus: Clean Received: from gateway.gossamer-threads.com (HELO ?192.168.1.152?) (nathan@gossamer-threads.com@208.70.247.145) by gossamer.nmsrv.com with ESMTPSA (DHE-RSA-CAMELLIA256-SHA encrypted); 7 Sep 2011 19:37:00 -0000 Message-ID: <4E67C7D9.1060607@gt.net> Date: Wed, 07 Sep 2011 12:36:57 -0700 From: Nathan March User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:7.0) Gecko/20110905 Thunderbird/7.0 MIME-Version: 1.0 To: xen-devel mailing list Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: [Xen-devel] Updated git locations now that kernel.org is no longer hosting? X-BeenThere: xen-devel@lists.xensource.com X-Mailman-Version: 2.1.5 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xensource.com Errors-To: xen-devel-bounces@lists.xensource.com Hi, Just wondering if anyone can point me to the new locations for xen/next-3.0 repo? git.kernel.org doesn't appear to be coming back up (http://www.theregister.co.uk/2011/09/06/linus_torvalds_dumps_kernel_for_github/) and the XenParavirtOps wiki page still refers to that. Searching the list didn't seem to come up with anything. Thanks, Nathan -- Nathan March Gossamer Threads Inc. http://www.gossamer-threads.com/ Tel: (604) 687-5804 Fax: (604) 687-5806 _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel From xen-devel-bounces@lists.xensource.com Wed Sep 07 13:02:47 2011 Return-path: Envelope-to: www-data@lists.xensource.com Delivery-date: Wed, 07 Sep 2011 13:02:47 -0700 Received: from localhost ([127.0.0.1] helo=lists.colo.xensource.com) by lists.xensource.com with esmtp (Exim 4.43) id 1R1OKb-0004U8-N9; Wed, 07 Sep 2011 13:02:46 -0700 Received: from mail216.messagelabs.com ([85.158.143.99]) by lists.xensource.com with smtp (Exim 4.43) id 1R1OHZ-0004Dy-ER for xen-devel@lists.xensource.com; Wed, 07 Sep 2011 12:59:41 -0700 X-Env-Sender: Ian.Jackson@eu.citrix.com X-Msg-Ref: server-13.tower-216.messagelabs.com!1315425574!17458144!1 X-Originating-IP: [62.200.22.115] X-StarScan-Version: 6.3.6; banners=-,-,- X-VirusChecked: Checked Received: (qmail 841 invoked from network); 7 Sep 2011 19:59:34 -0000 Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115) by server-13.tower-216.messagelabs.com with SMTP; 7 Sep 2011 19:59:34 -0000 X-IronPort-AV: E=Sophos;i="4.68,347,1312156800"; d="scan'208";a="7661443" Received: from lonpmailmx01.citrite.net ([10.30.203.162]) by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5; 07 Sep 2011 19:59:34 +0000 Received: from woking.xci-test.com (10.80.248.135) by smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id 8.3.137.0; Wed, 7 Sep 2011 20:59:34 +0100 Received: from osstest by woking.xci-test.com with local (Exim 4.69) (envelope-from ) id 1R1OHV-0007ID-DZ; Wed, 07 Sep 2011 20:59:33 +0100 To: xen-devel@lists.xensource.com Message-ID: From: xen.org Date: Wed, 7 Sep 2011 20:59:33 +0100 MIME-Version: 1.0 Content-Type: text/plain Cc: ian.jackson@eu.citrix.com Subject: [Xen-devel] [xen-4.0-testing test] 8852: regressions - FAIL X-BeenThere: xen-devel@lists.xensource.com X-Mailman-Version: 2.1.5 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xensource.com Errors-To: xen-devel-bounces@lists.xensource.com flight 8852 xen-4.0-testing real [real] http://www.chiark.greenend.org.uk/~xensrcts/logs/8852/ Regressions :-( Tests which did not succeed and are blocking: test-amd64-i386-xl-win-vcpus1 5 xen-boot fail REGR. vs. 8801 Tests which did not succeed, but are not blocking, including regressions (tests previously passed) regarded as allowable: test-amd64-amd64-xl-pcipt-intel 8 debian-fixup fail never pass test-i386-i386-xl 15 guest-stop fail never pass test-amd64-i386-xl-multivcpu 15 guest-stop fail never pass test-amd64-amd64-xl 15 guest-stop fail never pass test-amd64-i386-xl 15 guest-stop fail never pass test-amd64-i386-xl-credit2 15 guest-stop fail never pass test-amd64-amd64-xl-sedf 5 xen-boot fail like 8788 test-amd64-i386-rhel6hvm-intel 7 redhat-install fail never pass test-amd64-i386-rhel6hvm-amd 7 redhat-install fail never pass test-amd64-i386-win-vcpus1 16 leak-check/check fail never pass test-amd64-i386-win 16 leak-check/check fail never pass test-amd64-amd64-win 16 leak-check/check fail never pass test-i386-i386-win 16 leak-check/check fail never pass test-amd64-amd64-xl-win 7 windows-install fail never pass test-i386-i386-xl-win 7 windows-install fail never pass version targeted for testing: xen b44346a6975c baseline version: xen 0383662ea34c ------------------------------------------------------------ People who touched revisions under test: Andrew Cooper ------------------------------------------------------------ jobs: build-amd64 pass build-i386 pass build-amd64-oldkern pass build-i386-oldkern pass build-amd64-pvops pass build-i386-pvops pass test-amd64-amd64-xl fail test-amd64-i386-xl fail test-i386-i386-xl fail test-amd64-i386-rhel6hvm-amd fail test-amd64-i386-xl-credit2 fail test-amd64-amd64-xl-pcipt-intel fail test-amd64-i386-rhel6hvm-intel fail test-amd64-i386-xl-multivcpu fail test-amd64-amd64-pair pass test-amd64-i386-pair pass test-i386-i386-pair pass test-amd64-amd64-pv pass test-amd64-i386-pv pass test-i386-i386-pv pass test-amd64-amd64-xl-sedf fail test-amd64-i386-win-vcpus1 fail test-amd64-i386-xl-win-vcpus1 fail test-amd64-amd64-win fail test-amd64-i386-win fail test-i386-i386-win fail test-amd64-amd64-xl-win fail test-i386-i386-xl-win fail ------------------------------------------------------------ sg-report-flight on woking.cam.xci-test.com logs: /home/xc_osstest/logs images: /home/xc_osstest/images Logs, config files, etc. are available at http://www.chiark.greenend.org.uk/~xensrcts/logs Test harness code can be found at http://xenbits.xensource.com/gitweb?p=osstest.git;a=summary Not pushing. ------------------------------------------------------------ changeset: 21533:b44346a6975c tag: tip user: Keir Fraser date: Wed Sep 07 10:41:49 2011 +0100 Added signature for changeset 8d012bc20d30 changeset: 21532:b7b51fd533d3 user: Keir Fraser date: Wed Sep 07 10:41:41 2011 +0100 Added tag 4.0.3-rc2 for changeset 8d012bc20d30 changeset: 21531:8d012bc20d30 tag: 4.0.3-rc2 user: Keir Fraser date: Wed Sep 07 10:41:35 2011 +0100 Update Xen version to 4.0.3-rc2 changeset: 21530:0383662ea34c user: Andrew Cooper date: Wed Aug 31 15:37:57 2011 +0100 IRQ: manually EOI migrating line interrupts When migrating IO-APIC line level interrupts between PCPUs, the migration code rewrites the IO-APIC entry to point to the new CPU/Vector before EOI'ing it. The EOI process says that EOI'ing the Local APIC will cause a broadcast with the vector number, which the IO-APIC must listen to to clear the IRR and Status bits. In the case of migrating, the IO-APIC has already been reprogrammed so the EOI broadcast with the old vector fails to match the new vector, leaving the IO-APIC with an outstanding vector, preventing any more use of that line interrupt. This causes a lockup especially when your root device is using PCI INTA (megaraid_sas driver *ehem*) However, the problem is mostly hidden because send_cleanup_vector() causes a cleanup of all moving vectors on the current PCPU in such a way which does not cause the problem, and if the problem has occured, the writes it makes to the IO-APIC clears the IRR and Status bits which unlocks the problem. This fix is distinctly a temporary hack, waiting on a cleanup of the irq code. It checks for the edge case where we have moved the irq, and manually EOI's the old vector with the IO-APIC which correctly clears the IRR and Status bits. Also, it protects the code which updates irq_cfg by disabling interrupts. Signed-off-by: Andrew Cooper xen-unstable changeset: 23805:7048810180de xen-unstable date: Wed Aug 31 15:19:24 2011 +0100 (qemu changes not included) _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel From xen-devel-bounces@lists.xensource.com Wed Sep 07 13:05:21 2011 Return-path: Envelope-to: www-data@lists.xensource.com Delivery-date: Wed, 07 Sep 2011 13:05:21 -0700 Received: from localhost ([127.0.0.1] helo=lists.colo.xensource.com) by lists.xensource.com with esmtp (Exim 4.43) id 1R1ON7-0004sg-HQ; Wed, 07 Sep 2011 13:05:21 -0700 Received: from mail27.messagelabs.com ([193.109.254.147]) by lists.xensource.com with smtp (Exim 4.43) id 1R1OGI-0004CS-4M for xen-devel@lists.xensource.com; Wed, 07 Sep 2011 12:59:46 -0700 X-Env-Sender: davidtecher@yahoo.fr X-Msg-Ref: server-15.tower-27.messagelabs.com!1315425470!47822575!1 X-Originating-IP: [77.238.189.95] X-StarScan-Version: 6.3.6; banners=-,-,- X-VirusChecked: Checked Received: (qmail 16149 invoked from network); 7 Sep 2011 19:57:50 -0000 Received: from nm1-vm0.bullet.mail.ird.yahoo.com (HELO nm1-vm0.bullet.mail.ird.yahoo.com) (77.238.189.95) by server-15.tower-27.messagelabs.com with SMTP; 7 Sep 2011 19:57:50 -0000 Received: from [77.238.189.56] by nm1.bullet.mail.ird.yahoo.com with NNFMP; 07 Sep 2011 19:57:57 -0000 Received: from [212.82.108.250] by tm9.bullet.mail.ird.yahoo.com with NNFMP; 07 Sep 2011 19:57:57 -0000 Received: from [127.0.0.1] by omp1015.mail.ird.yahoo.com with NNFMP; 07 Sep 2011 19:57:57 -0000 X-Yahoo-Newman-Property: ymail-3 X-Yahoo-Newman-Id: 399759.73323.bm@omp1015.mail.ird.yahoo.com Received: (qmail 19614 invoked by uid 60001); 7 Sep 2011 19:57:57 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.fr; s=s1024; t=1315425477; bh=oGFl5YtPzPXdpKHBOLMJOQfgUYfrROmlcu8k5KD5uuQ=; h=X-YMail-OSG:Received:X-Mailer:References:Message-ID:Date:From:Reply-To:Subject:To:Cc:In-Reply-To:MIME-Version:Content-Type; b=mJfbT7qa0TH0nlaASobQ6o94Gzxp4nNmGB6zKNHKf8wDP9lWnYaGY5gIp1kaNbFZLBCqBmmwff8xoMHgPNdTiewLniUcmz0+ZuIoZSv0uYDtJMw5mzScfaKdyeqXhBFS3NXOSMSQlP7LG8TjJf/9TmTEFx0WIvHtYjnj0+VjIM4= DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.fr; h=X-YMail-OSG:Received:X-Mailer:References:Message-ID:Date:From:Reply-To:Subject:To:Cc:In-Reply-To:MIME-Version:Content-Type; b=uf1RwuTgPFevVDvOYW5eg8t53WsHAfJ8+aMsWs/1SSVQxJIwN/3/kk7hOmcQRBPYm6EEZpTvg9Oovi9G03JoMXDKXnOE69rqD3oNERmPPKNlp5Di9eLIs5v6cSnNeXXTHp3USUz01jVIZ7B9HpqshycBF1faACk0qoDHRjWFY4M=; X-YMail-OSG: wZ10wesVM1m8IHDKaqLT7jXVhUyex4E.yO5woGlExFsUXXB 8_W5mI9C6gHfw6rf4u9wtjThtIP30R7j4xLmUh1Q3aiej6riPEhDt.ejK8nX Xr.qmQ6E3ooCQBZ9yKd4SpugJHcgpVASaJsBZx1Oj2diONUFgqVqU.smA2sX syf9b7se_jm7gFFBQwLGjX_cDUZa84vybqA_B_eRmI7xt4gqAv6_Os9oEW.6 bJoVsvofptB1D05Qk3Ltie9Ed56MEpK_.ZIymKa9HLy4VrTdyF2mQX5LGTm4 mPRcWiTDvX3JQg3TUK85QKp.XILWbCAGPpCPVAhSzTgkQ33LE8tWNeJLpQv_ nv0J8Sx2g6fEL1lbyJUvBBjy2qbn86blWVM0ZrEpncu9deD_2WUi_6tPXIPO EYwnuhLOEE24GjmsejSQXzpkT4Q-- Received: from [83.154.246.188] by web29806.mail.ird.yahoo.com via HTTP; Wed, 07 Sep 2011 20:57:57 BST X-Mailer: YahooMailWebService/0.8.113.315625 References: <1314780568949-4753422.post@n5.nabble.com> <1314795401771-4754024.post@n5.nabble.com> <20110831151913.GE7276@reaktio.net> <1315231341254-4770602.post@n5.nabble.com> <1315310225039-4774097.post@n5.nabble.com> <1315343879.61837.YahooMailNeo@web29818.mail.ird.yahoo.com> <1315382742268-4777689.post@n5.nabble.com> <1315389138.56652.YahooMailNeo@web29801.mail.ird.yahoo.com> <1315398360680-4778339.post@n5.nabble.com> <1315399889.79555.YahooMailNeo@web29820.mail.ird.yahoo.com> <20110907185250.GE7074@dumpdata.com> Message-ID: <1315425477.3053.YahooMailNeo@web29806.mail.ird.yahoo.com> Date: Wed, 7 Sep 2011 20:57:57 +0100 (BST) From: David TECHER Subject: Re : Re : Re : Re : [Xen-devel] Re: Patches for VGA-Passthrough XEN 4.2 unstable To: Konrad Rzeszutek Wilk In-Reply-To: <20110907185250.GE7074@dumpdata.com> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="0-464971015-1315425477=:3053" Cc: komkon555 , "xen-devel@lists.xensource.com" X-BeenThere: xen-devel@lists.xensource.com X-Mailman-Version: 2.1.5 Precedence: list Reply-To: David TECHER List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xensource.com Errors-To: xen-devel-bounces@lists.xensource.com --0-464971015-1315425477=:3053 Content-Type: multipart/alternative; boundary="0-40965790-1315425477=:3053" --0-40965790-1315425477=:3053 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable Hi Konrad,=0A=0A=0AHere is.=0A=0ADavid.=0A=0A=0A=0A________________________= ________=0ADe=A0: Konrad Rzeszutek Wilk =0A=C0=A0: = David TECHER =0ACc=A0: komkon555 ; "xen-devel@lists.xensource.com" =0AEnvoy= =E9 le : Mercredi 7 Septembre 2011 20h52=0AObjet=A0: Re: Re : Re : Re : [Xe= n-devel] Re: Patches for VGA-Passthrough XEN 4.2 unstable=0A=0AOn Wed, Sep = 07, 2011 at 01:51:29PM +0100, David TECHER wrote:=0A> It is a great pleasur= e to know that is it working for you :)=0A> =0A> I've just updated the patc= hs sent by 'JavMV' on May 2011. Even if I'am not a Xen Developer=0A> it wil= l be a great idea if a real Xen Developer takes care of the patchs to impro= ve it for Xen 4.2.=0A=0AWhere are those patches? Can you attach them to thi= s email?=0A=0A> =0A> The next step was to understand how the patch for 'too= ls/firmware/hvmloader/acpi/dsdt.asl'=0A> works. Once I've understood, I've = patched for my own graphic card.=0A=0A_____________________________________= __________=0AXen-devel mailing list=0AXen-devel@lists.xensource.com=0Ahttp:= //lists.xensource.com/xen-devel --0-40965790-1315425477=:3053 Content-Type: text/html; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable
Hi Konrad,

Here is.

David.

=
De : Konrad Rzeszutek Wilk <ko= nrad.wilk@oracle.com>
=C0 = : David TECHER <davidtecher@yahoo.fr>
Cc : komkon555 <komkon555@freenet.d= e>; "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>= ;
Envoy=E9 le : Mercred= i 7 Septembre 2011 20h52
Objet : Re: Re : Re : Re : [Xen-devel] Re: Patches for VGA-Passthrough XEN 4.2 un= stable

On Wed, Sep 07, 2011 at 01:51:29PM +0100, David TECHER= wrote:
> It is a great pleasure to know that is it working for you := )
>
> I've just updated the patchs sent by 'JavMV' on May 2011= . Even if I'am not a Xen Developer
> it will be a great idea if a rea= l Xen Developer takes care of the patchs to improve it for Xen 4.2.

= Where are those patches? Can you attach them to this email?

> > The next step was to understand how the patch for 'tools/firmware/hvm= loader/acpi/dsdt.asl'
> works. Once I've understood, I've patched for= my own graphic card.

______________________________________________= _
Xen-devel mailing list
Xen-devel@lists.xensource.co= m
http://lists.xensource.com/xen-devel


--0-40965790-1315425477=:3053-- --0-464971015-1315425477=:3053 Content-Type: application/octet-stream; name="gfx.patch" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="gfx.patch" LS0tIHRvb2xzL2Zpcm13YXJlL2h2bWxvYWRlci9hY3BpL2RzZHQuYXNsCTIw MTEtMDgtMTMgMTg6NDM6MzkuMDAwMDAwMDAwICswMjAwCisrKyB0b29scy9m aXJtd2FyZS9odm1sb2FkZXIvYWNwaS9kc2R0LmFzbAkyMDExLTA4LTEzIDE4 OjU4OjI1LjAwMDAwMDAwMCArMDIwMApAQCAtMTczLDE1ICsxNzMsNDMgQEAg RGVmaW5pdGlvbkJsb2NrICgiRFNEVC5hbWwiLCAiRFNEVCIsIDIsCiAgICAg ICAgICAgICAgICAgICAgICAgICAweDAwMDAwMDAwLAogICAgICAgICAgICAg ICAgICAgICAgICAgMHgwMDAyMDAwMCkKIAorICAgICAgICAgICAgICAgICAg ICAvKiByZXNlcnZlIE1NSU8gQkFScyBvZiBnZnggZm9yIDE6MSBtYXBwaW5n ICovCiAgICAgICAgICAgICAgICAgICAgIERXb3JkTWVtb3J5KAogICAgICAg ICAgICAgICAgICAgICAgICAgUmVzb3VyY2VQcm9kdWNlciwgUG9zRGVjb2Rl LCBNaW5GaXhlZCwgTWF4Rml4ZWQsCiAgICAgICAgICAgICAgICAgICAgICAg ICBDYWNoZWFibGUsIFJlYWRXcml0ZSwKICAgICAgICAgICAgICAgICAgICAg ICAgIDB4MDAwMDAwMDAsCi0gICAgICAgICAgICAgICAgICAgICAgICAweEYw MDAwMDAwLAotICAgICAgICAgICAgICAgICAgICAgICAgMHhGNEZGRkZGRiwK KyAgICAgICAgICAgICAgICAgICAgICAgIDB4RkEwMDAwMDAsCisgICAgICAg ICAgICAgICAgICAgICAgICAweEZBRkZGRkZGLAogICAgICAgICAgICAgICAg ICAgICAgICAgMHgwMDAwMDAwMCwKLSAgICAgICAgICAgICAgICAgICAgICAg IDB4MDUwMDAwMDAsCi0gICAgICAgICAgICAgICAgICAgICAgICAsLCBfWTAx KQorICAgICAgICAgICAgICAgICAgICAgICAgMHgwMTAwMDAwMCkKKworICAg ICAgICAgICAgICAgICAgICBEV29yZE1lbW9yeSgKKyAgICAgICAgICAgICAg ICAgICAgICAgIFJlc291cmNlUHJvZHVjZXIsIFBvc0RlY29kZSwgTWluRml4 ZWQsIE1heEZpeGVkLAorICAgICAgICAgICAgICAgICAgICAgICAgTm9uQ2Fj aGVhYmxlLCBSZWFkV3JpdGUsCisgICAgICAgICAgICAgICAgICAgICAgICAw eDAwMDAwMDAwLAorICAgICAgICAgICAgICAgICAgICAgICAgMHhDMDAwMDAw MCwKKyAgICAgICAgICAgICAgICAgICAgICAgIDB4Q0ZGRkZGRkYsCisgICAg ICAgICAgICAgICAgICAgICAgICAweDAwMDAwMDAwLAorICAgICAgICAgICAg ICAgICAgICAgICAgMHgxMDAwMDAwMCkKKworICAgICAgICAgICAgICAgICAg ICBEV29yZE1lbW9yeSgKKyAgICAgICAgICAgICAgICAgICAgICAgIFJlc291 cmNlUHJvZHVjZXIsIFBvc0RlY29kZSwgTWluRml4ZWQsIE1heEZpeGVkLAor ICAgICAgICAgICAgICAgICAgICAgICAgQ2FjaGVhYmxlLCBSZWFkV3JpdGUs CisgICAgICAgICAgICAgICAgICAgICAgICAweDAwMDAwMDAwLAorICAgICAg ICAgICAgICAgICAgICAgICAgMHhEMDAwMDAwMCwKKyAgICAgICAgICAgICAg ICAgICAgICAgIDB4RDFGRkZGRkYsCisgICAgICAgICAgICAgICAgICAgICAg ICAweDAwMDAwMDAwLAorICAgICAgICAgICAgICAgICAgICAgICAgMHgwMjAw MDAwMCkKKworICAgICAgICAgICAgICAgICAgICBEV29yZE1lbW9yeSgKKyAg ICAgICAgICAgICAgICAgICAgICAgIFJlc291cmNlUHJvZHVjZXIsIFBvc0Rl Y29kZSwgTWluRml4ZWQsIE1heEZpeGVkLAorICAgICAgICAgICAgICAgICAg ICAgICAgQ2FjaGVhYmxlLCBSZWFkV3JpdGUsCisgICAgICAgICAgICAgICAg ICAgICAgICAweDAwMDAwMDAwLAorICAgICAgICAgICAgICAgICAgICAgICAg MHhGQjAwMDAwMCwKKyAgICAgICAgICAgICAgICAgICAgICAgIDB4RkIwN0ZG RkYsCisgICAgICAgICAgICAgICAgICAgICAgICAweDAwMDAwMDAwLAorICAg ICAgICAgICAgICAgICAgICAgICAgMHgwMDA4MDAwMCwgICAgICAgICAgICAg ICAgICAgICAgICAKKwkJCSwsIF9ZMDEpCiAgICAgICAgICAgICAgICAgfSkK IAogICAgICAgICAgICAgICAgIENyZWF0ZURXb3JkRmllbGQoUFJUMCwgXF9T Qi5QQ0kwLl9DUlMuX1kwMS5fTUlOLCBNTUlOKQotLS0gdG9vbHMvZmlybXdh cmUvaHZtbG9hZGVyL2h2bWxvYWRlci5jCTIwMTEtMDgtMTMgMTg6NDM6Mzku MDAwMDAwMDAwICswMjAwCisrKyB0b29scy9maXJtd2FyZS9odm1sb2FkZXIv aHZtbG9hZGVyLmMJMjAxMS0wOC0xMyAxOToxNjoyMS4wMDAwMDAwMDAgKzAy MDAKQEAgLTMxLDYgKzMxLDcgQEAKICNpbmNsdWRlIDx4ZW4vaHZtL3BhcmFt cy5oPgogCiAjZGVmaW5lIFJPTV9JTkNMVURFX1ZHQUJJT1MKKyNkZWZpbmUg Uk9NX0lOQ0xVREVfUFRWR0FCSU9TCiAjZGVmaW5lIFJPTV9JTkNMVURFX0VU SEVSQk9PVAogI2luY2x1ZGUgInJvbXMuaW5jIgogCkBAIC0xMTMsNiArMTE0 LDkgQEAgYXNtICgKIAogdW5zaWduZWQgbG9uZyBzY3JhdGNoX3N0YXJ0ID0g U0NSQVRDSF9QSFlTSUNBTF9BRERSRVNTOwogCisvKiB2aXJ0dWFsIEJERiBv ZiBwYXNzLXRocm91Z2hlZCBnZnggKi8KK3VpbnQ4X3QgZ2Z4X2JkZjsKKwog c3RhdGljIHZvaWQgaW5pdF9oeXBlcmNhbGxzKHZvaWQpCiB7CiAgICAgdWlu dDMyX3QgZWF4LCBlYngsIGVjeCwgZWR4OwpAQCAtMzEwLDYgKzMxNCwyMCBA QCBzdGF0aWMgaW50IHBjaV9sb2FkX29wdGlvbl9yb21zKHVuc2lnbmVkCiAg ICAgcmV0dXJuIHJvbV9waHlzX2FkZHIgLSByb21fYmFzZV9hZGRyOwogfQog CitzdGF0aWMgdm9pZCBpbml0X3ZtODZfdHNzKHZvaWQpCit7CisgICAgdm9p ZCAqdHNzOworICAgIHN0cnVjdCB4ZW5faHZtX3BhcmFtIHA7CisKKyAgICB0 c3MgPSBtZW1fYWxsb2MoMTI4LCAxMjgpOworICAgIG1lbXNldCh0c3MsIDAs IDEyOCk7CisgICAgcC5kb21pZCA9IERPTUlEX1NFTEY7CisgICAgcC5pbmRl eCA9IEhWTV9QQVJBTV9WTTg2X1RTUzsKKyAgICBwLnZhbHVlID0gdmlydF90 b19waHlzKHRzcyk7CisgICAgaHlwZXJjYWxsX2h2bV9vcChIVk1PUF9zZXRf cGFyYW0sICZwKTsKKyAgICBwcmludGYoInZtODYgVFNTIGF0ICUwOGx4XG4i LCB2aXJ0X3RvX3BoeXModHNzKSk7Cit9CisKIC8qIFJlcGxhY2UgcG9zc2li bHkgZXJyb25lb3VzIG1lbW9yeS1zaXplIENNT1MgZmllbGRzIHdpdGggY29y cmVjdCB2YWx1ZXMuICovCiBzdGF0aWMgdm9pZCBjbW9zX3dyaXRlX21lbW9y eV9zaXplKHZvaWQpCiB7CkBAIC0zMzYsMjUgKzM1NCw2IEBAIHN0YXRpYyB2 b2lkIGNtb3Nfd3JpdGVfbWVtb3J5X3NpemUodm9pZCkKICAgICBjbW9zX291 dGIoMHgzNSwgKHVpbnQ4X3QpKCBhbHRfbWVtID4+IDgpKTsKIH0KIAotLyoK LSAqIFNldCB1cCBhbiBlbXB0eSBUU1MgYXJlYSBmb3IgdmlydHVhbCA4MDg2 IG1vZGUgdG8gdXNlLiAKLSAqIFRoZSBvbmx5IGltcG9ydGFudCB0aGluZyBp cyB0aGF0IGl0IG11c24ndCBoYXZlIGFueSBiaXRzIHNldCAKLSAqIGluIHRo ZSBpbnRlcnJ1cHQgcmVkaXJlY3Rpb24gYml0bWFwLCBzbyBhbGwgemVyb3Mg d2lsbCBkby4KLSAqLwotc3RhdGljIHZvaWQgaW5pdF92bTg2X3Rzcyh2b2lk KQotewotICAgIHZvaWQgKnRzczsKLSAgICBzdHJ1Y3QgeGVuX2h2bV9wYXJh bSBwOwotCi0gICAgdHNzID0gbWVtX2FsbG9jKDEyOCwgMTI4KTsKLSAgICBt ZW1zZXQodHNzLCAwLCAxMjgpOwotICAgIHAuZG9taWQgPSBET01JRF9TRUxG OwotICAgIHAuaW5kZXggPSBIVk1fUEFSQU1fVk04Nl9UU1M7Ci0gICAgcC52 YWx1ZSA9IHZpcnRfdG9fcGh5cyh0c3MpOwotICAgIGh5cGVyY2FsbF9odm1f b3AoSFZNT1Bfc2V0X3BhcmFtLCAmcCk7Ci0gICAgcHJpbnRmKCJ2bTg2IFRT UyBhdCAlMDhseFxuIiwgdmlydF90b19waHlzKHRzcykpOwotfQotCiBzdGF0 aWMgdm9pZCBhcGljX3NldHVwKHZvaWQpCiB7CiAgICAgLyogU2V0IHRoZSBJ T0FQSUMgSUQgdG8gdGhlIHN0YXRpYyB2YWx1ZSB1c2VkIGluIHRoZSBNUC9B Q1BJIHRhYmxlcy4gKi8KQEAgLTQ4Nyw4ICs0ODYsMTAgQEAgaW50IG1haW4o dm9pZCkKICAgICAgICAgICAgIGJyZWFrOwogICAgICAgICBjYXNlIFZHQV9w dDoKICAgICAgICAgICAgIHByaW50ZigiTG9hZGluZyBWR0FCSU9TIG9mIHBh c3N0aHJvdWdoZWQgZ2Z4IC4uLlxuIik7Ci0gICAgICAgICAgICB2Z2FiaW9z X3N6ID0gcm91bmRfb3B0aW9uX3JvbSgKLSAgICAgICAgICAgICAgICAoKih1 aW50OF90ICopKFZHQUJJT1NfUEhZU0lDQUxfQUREUkVTUysyKSkgKiA1MTIp OworICAgICAgICBtZW1jcHkoKHZvaWQgKilWR0FCSU9TX1BIWVNJQ0FMX0FE RFJFU1MsCisgICAgICAgICAgICAgICB2Z2FiaW9zX3B0LCBzaXplb2Yodmdh Ymlvc19wdCkpOworICAgICAgICAqKHVpbnQ4X3QgKikoVkdBQklPU19QSFlT SUNBTF9BRERSRVNTICsgc2l6ZW9mKHZnYWJpb3NfcHQpKSA9IGdmeF9iZGY7 CisgICAgICAgIHZnYWJpb3Nfc3ogPSByb3VuZF9vcHRpb25fcm9tKHNpemVv Zih2Z2FiaW9zX3B0KSArIDEpOwogICAgICAgICAgICAgYnJlYWs7CiAgICAg ICAgIGRlZmF1bHQ6CiAgICAgICAgICAgICBwcmludGYoIk5vIGVtdWxhdGVk IFZHQSBhZGFwdG9yIC4uLlxuIik7CkBAIC01MjUsNyArNTI2LDcgQEAgaW50 IG1haW4odm9pZCkKICAgICAgICAgaHlwZXJjYWxsX2h2bV9vcChIVk1PUF9z ZXRfcGFyYW0sICZwKTsKICAgICB9CiAKLSAgICBpbml0X3ZtODZfdHNzKCk7 CisgICBpbml0X3ZtODZfdHNzKCk7CiAKICAgICBjbW9zX3dyaXRlX21lbW9y eV9zaXplKCk7CiAKLS0tIHRvb2xzL2Zpcm13YXJlL2h2bWxvYWRlci9NYWtl ZmlsZQkyMDExLTA4LTEzIDE4OjQzOjM5LjAwMDAwMDAwMCArMDIwMAorKysg dG9vbHMvZmlybXdhcmUvaHZtbG9hZGVyL01ha2VmaWxlCTIwMTEtMDgtMTMg MTg6NTg6MzYuMDAwMDAwMDAwICswMjAwCkBAIC01Niw2ICs1Niw3IEBAIENJ UlJVU1ZHQV9ST00gOj0gLi4vdmdhYmlvcy9WR0FCSU9TLWxncGwKIGVsc2UK IENJUlJVU1ZHQV9ST00gOj0gLi4vdmdhYmlvcy9WR0FCSU9TLWxncGwtbGF0 ZXN0LmNpcnJ1cy5iaW4KIGVuZGlmCitQVFZHQV9ST00gICAgIDo9IC4uL3Zn YWJpb3MvdmdhYmlvcy1wdC5iaW4KIAogLlBIT05ZOiBhbGwKIGFsbDogc3Vi ZGlycy1hbGwKQEAgLTk0LDYgKzk1LDExIEBAIGlmbmVxICgkKENJUlJVU1ZH QV9ST00pLCkKIAlzaCAuL21raGV4IHZnYWJpb3NfY2lycnVzdmdhICQoQ0lS UlVTVkdBX1JPTSkgPj4gJEAubmV3CiAJZWNobyAiI2VuZGlmIiA+PiAkQC5u ZXcKIGVuZGlmCitpZm5lcSAoJChQVFZHQV9ST00pLCkKKwllY2hvICIjaWZk ZWYgUk9NX0lOQ0xVREVfUFRWR0FCSU9TIiA+PiAkQC5uZXcKKwlzaCAuL21r aGV4IHZnYWJpb3NfcHQgJChQVFZHQV9ST00pID4+ICRALm5ldworCWVjaG8g IiNlbmRpZiIgPj4gJEAubmV3CitlbmRpZgogCiAJZWNobyAiI2lmZGVmIFJP TV9JTkNMVURFX0VUSEVSQk9PVCIgPj4gJEAubmV3CiAJY2F0IC4uL2V0aGVy Ym9vdC9lYi1yb21zLmggPj4gJEAubmV3Ci0tLSB0b29scy9pb2VtdS1yZW1v dGUvaHcvcGFzcy10aHJvdWdoLmMJMjAxMS0wOC0xMyAyMzoxNToxMy4wMDAw MDAwMDAgKzAyMDAKKysrIHRvb2xzL2lvZW11LXJlbW90ZS9ody9wYXNzLXRo cm91Z2guYwkyMDExLTA4LTEzIDE4OjU4OjQxLjAwMDAwMDAwMCArMDIwMApA QCAtMzI0Myw2ICszMjQzLDggQEAgc3RhdGljIGludCBwdF9jbWRfcmVnX3Jl YWQoc3RydWN0IHB0X2RldgogfQogCiAvKiByZWFkIEJBUiAqLworc3RhdGlj IGludCBnZnhfZmlyc3RfcmVhZF9CQVJbN10gPSB7MSwgMSwgMSwgMSwgMSwg MSwgMX07CisKIHN0YXRpYyBpbnQgcHRfYmFyX3JlZ19yZWFkKHN0cnVjdCBw dF9kZXYgKnB0ZGV2LAogICAgICAgICBzdHJ1Y3QgcHRfcmVnX3RibCAqY2Zn X2VudHJ5LAogICAgICAgICB1aW50MzJfdCAqdmFsdWUsIHVpbnQzMl90IHZh bGlkX21hc2spCkBAIC0zMjY1LDYgKzMyNjcsMTcgQEAgc3RhdGljIGludCBw dF9iYXJfcmVnX3JlYWQoc3RydWN0IHB0X2RldgogICAgIC8qIHVzZSBmaXhl ZC11cCB2YWx1ZSBmcm9tIGtlcm5lbCBzeXNmcyAqLwogICAgICp2YWx1ZSA9 IHB0ZGV2LT5wY2lfZGV2LT5iYXNlX2FkZHJbaW5kZXhdOwogCisgICAgaWYg KCBwdGRldi0+cGNpX2Rldi0+ZGV2aWNlX2NsYXNzID09IDB4MzAwICkKKyAg ICB7CisgICAgICAgIGlmICggZ2Z4X2ZpcnN0X3JlYWRfQkFSW2luZGV4XSA9 PSAxICkKKyAgICAgICAgeworICAgICAgICAgICAgZ2Z4X2ZpcnN0X3JlYWRf QkFSW2luZGV4XSA9IDA7CisgICAgICAgICAgICBQVF9MT0coImZpcnN0IHJl YWQgQkFScyBvZiBnZnhcbiIpOworICAgICAgICAgICAgcmV0dXJuIDA7Cisg ICAgICAgIH0KKyAgICB9CisKKwogICAgIC8qIHNldCBlbXVsYXRlIG1hc2sg ZGVwZW5kIG9uIEJBUiBmbGFnICovCiAgICAgc3dpdGNoIChwdGRldi0+YmFz ZXNbaW5kZXhdLmJhcl9mbGFnKQogICAgIHsKLS0tIHRvb2xzL2Zpcm13YXJl L2h2bWxvYWRlci9wY2kuYwkyMDExLTA4LTEzIDE4OjQzOjM5LjAwMDAwMDAw MCArMDIwMAorKysgdG9vbHMvZmlybXdhcmUvaHZtbG9hZGVyL3BjaS5jCTIw MTEtMDgtMTMgMTg6NTg6NTMuMDAwMDAwMDAwICswMjAwCkBAIC0zMyw2ICsz MywxMCBAQCB1bnNpZ25lZCBsb25nIHBjaV9tZW1fZW5kID0gUENJX01FTV9F TkQ7CiAKIGVudW0gdmlydHVhbF92Z2EgdmlydHVhbF92Z2EgPSBWR0Ffbm9u ZTsKIAorLyogdmlydHVhbCBCREYgb2YgcGFzcy10aHJvdWdoZWQgZ2Z4IGRl Y2xhcmVkIGluIGh2bWxvYWRlci5jKi8KK2V4dGVybiB1aW50OF90IGdmeF9i ZGY7CisKKwogdm9pZCBwY2lfc2V0dXAodm9pZCkKIHsKICAgICB1aW50MzJf dCBiYXNlLCBkZXZmbiwgYmFyX3JlZywgYmFyX2RhdGEsIGJhcl9zeiwgY21k LCBtbWlvX3RvdGFsID0gMDsKQEAgLTkzLDkgKzk3LDQ0IEBAIHZvaWQgcGNp X3NldHVwKHZvaWQpCiAgICAgICAgICAgICB9CiAgICAgICAgICAgICBlbHNl IGlmICggdmlydHVhbF92Z2EgPT0gVkdBX25vbmUgKQogICAgICAgICAgICAg ewotICAgICAgICAgICAgICAgIHZnYV9kZXZmbiA9IGRldmZuOwotICAgICAg ICAgICAgICAgIHZpcnR1YWxfdmdhID0gVkdBX3B0OworICAgICAgICAgICAg ICAgICB2aXJ0dWFsX3ZnYSA9IFZHQV9wdDsKKyAgICAgICAgICAgICAgICAg Z2Z4X2JkZiA9IGRldmZuOworIAorICAgICAgICAgICAgICAgICAvKiBNYWtl IHZCQVI9cEJBUiAqLworICAgICAgICAgICAgICAgICBwcmludGYoIk1ha2Ug dkJBUiA9IHBCQVIgb2YgYXNzaWduZWQgZ2Z4XG4iKTsKKyAgICAgICAgICAg ICAgICAgZm9yICggYmFyID0gMDsgYmFyIDwgNzsgYmFyKysgKQorICAgICAg ICAgICAgICAgICB7CisgICAgICAgICAgICAgICAgICAgICBiYXJfcmVnID0g UENJX0JBU0VfQUREUkVTU18wICsgNCpiYXI7CisgICAgICAgICAgICAgICAg ICAgICBpZiAoIGJhciA9PSA2ICkKKyAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgYmFyX3JlZyA9IFBDSV9ST01fQUREUkVTUzsKKyAgICAgICAgICAg ICAgICAgICAgIC8qIFdoZW4gZmlyc3QgdGltZSByZWFkLCBpdCB3aWxsIHJl dHVybiBwaHlzaWNhbCBhZGRyZXNzICovCisgICAgICAgICAgICAgICAgICAg ICBiYXJfZGF0YSA9IHBjaV9yZWFkbChkZXZmbiwgYmFyX3JlZyk7CisgICAg ICAgICAgICAgICAgICAgICBwY2lfd3JpdGVsKGRldmZuLCBiYXJfcmVnLCBi YXJfZGF0YSk7CisgCisgICAgICAgICAgICAgICAgICAgICAvKiBOb3cgZW5h YmxlIHRoZSBtZW1vcnkgb3IgSS9PIG1hcHBpbmcuICovCisgICAgICAgICAg ICAgICAgICAgICBjbWQgPSBwY2lfcmVhZHcoZGV2Zm4sIFBDSV9DT01NQU5E KTsKKyAgICAgICAgICAgICAgICAgICAgIGlmICggKGJhcl9yZWcgPT0gUENJ X1JPTV9BRERSRVNTKSB8fAorICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgKChiYXJfZGF0YSAmIFBDSV9CQVNFX0FERFJFU1NfU1BBQ0UpID09Cisg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgUENJX0JBU0VfQUREUkVT U19TUEFDRV9NRU1PUlkpICkKKyAgICAgICAgICAgICAgICAgICAgICAgICAg IGNtZCB8PSBQQ0lfQ09NTUFORF9NRU1PUlk7CisgICAgICAgICAgICAgICAg ICAgICBlbHNlCisgICAgICAgICAgICAgICAgICAgICAgICAgICBjbWQgfD0g UENJX0NPTU1BTkRfSU87CisgICAgICAgICAgICAgICAgICAgICBjbWQgfD0g UENJX0NPTU1BTkRfTUFTVEVSOworICAgICAgICAgICAgICAgICAgICAgcGNp X3dyaXRldyhkZXZmbiwgUENJX0NPTU1BTkQsIGNtZCk7CisgICAgICAgICAg ICAgICAgfQorIAorICAgICAgICAgICAgICAgICAvKiBNYXAgdGhlIGludGVy cnVwdC4gKi8KKyAgICAgICAgICAgICAgICAgcGluID0gcGNpX3JlYWRiKGRl dmZuLCBQQ0lfSU5URVJSVVBUX1BJTik7CisgICAgICAgICAgICAgICAgIGlm ICggcGluICE9IDAgKQorICAgICAgICAgICAgICAgICB7CisgICAgICAgICAg ICAgICAgICAgICAvKiBUaGlzIGlzIHRoZSBiYXJiZXIncyBwb2xlIG1hcHBp bmcgdXNlZCBieSBYZW4uICovCisgICAgICAgICAgICAgICAgICAgICBsaW5r ID0gKChwaW4gLSAxKSArIChkZXZmbiA+PiAzKSkgJiAzOworICAgICAgICAg ICAgICAgICAgICAgaXNhX2lycSA9IHBjaV9yZWFkYihQQ0lfSVNBX0RFVkZO LCAweDYwICsgbGluayk7CisgICAgICAgICAgICAgICAgICAgICBwY2lfd3Jp dGViKGRldmZuLCBQQ0lfSU5URVJSVVBUX0xJTkUsIGlzYV9pcnEpOworICAg ICAgICAgICAgICAgICB9CisgICAgICAgICAgICAgICAgIGNvbnRpbnVlOwog ICAgICAgICAgICAgfQorCiAgICAgICAgICAgICBicmVhazsKICAgICAgICAg Y2FzZSAweDA2ODA6CiAgICAgICAgICAgICAvKiBQSUlYNCBBQ1BJIFBNLiBT cGVjaWFsIGRldmljZSB3aXRoIHNwZWNpYWwgUENJIGNvbmZpZyBzcGFjZS4g Ki8K --0-464971015-1315425477=:3053 Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel --0-464971015-1315425477=:3053-- From xen-devel-bounces@lists.xensource.com Wed Sep 07 13:10:56 2011 Return-path: Envelope-to: www-data@lists.xensource.com Delivery-date: Wed, 07 Sep 2011 13:10:56 -0700 Received: from localhost ([127.0.0.1] helo=lists.colo.xensource.com) by lists.xensource.com with esmtp (Exim 4.43) id 1R1OSW-0005Ov-6G; Wed, 07 Sep 2011 13:10:56 -0700 Received: from mail182.messagelabs.com ([85.158.139.83]) by lists.xensource.com with esmtp (Exim 4.43) id 1R1OS0-0005Cp-Ej for xen-devel@lists.xensource.com; Wed, 07 Sep 2011 13:10:25 -0700 X-Env-Sender: jeremy@goop.org X-Msg-Ref: server-6.tower-182.messagelabs.com!1315426219!17443902!1 X-Originating-IP: [74.207.240.146] X-StarScan-Version: 6.3.6; banners=-,-,- X-VirusChecked: Checked Received: (qmail 6083 invoked from network); 7 Sep 2011 20:10:21 -0000 Received: from claw.goop.org (HELO claw.goop.org) (74.207.240.146) by server-6.tower-182.messagelabs.com with DHE-RSA-AES256-SHA encrypted SMTP; 7 Sep 2011 20:10:21 -0000 Received: from saboo.goop.org (unknown [IPv6:2001:470:1f05:899:6801:ccff:fe7b:9751]) (Authenticated sender: smtp-saboo) by claw.goop.org (Postfix) with ESMTPSA id 893238F28; Wed, 7 Sep 2011 13:10:18 -0700 (PDT) Received: from saboo.goop.org (localhost [IPv6:::1]) by saboo.goop.org (Postfix) with ESMTP id 21D5E2021C; Wed, 7 Sep 2011 13:10:14 -0700 (PDT) Message-ID: <4E67CFA6.1090604@goop.org> Date: Wed, 07 Sep 2011 13:10:14 -0700 From: Jeremy Fitzhardinge User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:6.0) Gecko/20110816 Thunderbird/6.0 MIME-Version: 1.0 To: Nathan March Subject: Re: [Xen-devel] Updated git locations now that kernel.org is no longer hosting? References: <4E67C7D9.1060607@gt.net> In-Reply-To: <4E67C7D9.1060607@gt.net> X-Enigmail-Version: 1.3.1 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: xen-devel mailing list X-BeenThere: xen-devel@lists.xensource.com X-Mailman-Version: 2.1.5 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xensource.com Errors-To: xen-devel-bounces@lists.xensource.com On 09/07/2011 12:36 PM, Nathan March wrote: > Hi, > > Just wondering if anyone can point me to the new locations for > xen/next-3.0 repo? That's a branch name. Which specific repo are you looking for? I'm using github (git://github.com/jsgf/linux-xen.git), but I don't recommend any the branches there for use as-is. J _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel From xen-devel-bounces@lists.xensource.com Wed Sep 07 13:15:17 2011 Return-path: Envelope-to: www-data@lists.xensource.com Delivery-date: Wed, 07 Sep 2011 13:15:17 -0700 Received: from localhost ([127.0.0.1] helo=lists.colo.xensource.com) by lists.xensource.com with esmtp (Exim 4.43) id 1R1OWj-0005pI-Cc; Wed, 07 Sep 2011 13:15:17 -0700 Received: from mail174.messagelabs.com ([85.158.138.51]) by lists.xensource.com with esmtp (Exim 4.43) id 1R1OWA-0005cY-7b for xen-devel@lists.xensource.com; Wed, 07 Sep 2011 13:14:42 -0700 X-Env-Sender: nathan@gt.net X-Msg-Ref: server-4.tower-174.messagelabs.com!1315426477!30622455!1 X-Originating-IP: [208.70.244.21] X-StarScan-Version: 6.3.6; banners=-,-,- X-VirusChecked: Checked Received: (qmail 26218 invoked from network); 7 Sep 2011 20:14:39 -0000 Received: from gossamer.nmsrv.com (HELO gossamer.nmsrv.com) (208.70.244.21) by server-4.tower-174.messagelabs.com with DHE-RSA-AES256-SHA encrypted SMTP; 7 Sep 2011 20:14:39 -0000 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=gt.net; h=message-id:date :from:mime-version:to:cc:subject:references:in-reply-to :content-type:content-transfer-encoding; s=mail; bh=K9hw4/qxLy8G rJObSDKQhlBO1Sg=; b=Hqn2qqFSm7xYd2gnlD11Mx8rk5ayOKEdbGcjEKoDMxiK QMXksOMq3gbgmfsqDvQ9QzgvSqiqMesJbLPHqGIILrkyBIwj5zDOskX9dBvJFb3/ +I/FP4Ke+tHoa3GfV7j50/QMBqsO8UA9dOQi5bp9IltZbd4gOSXjVyJ2Wk6ZXP4= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gt.net; h=message-id:date :from:mime-version:to:cc:subject:references:in-reply-to :content-type:content-transfer-encoding; q=dns; s=mail; b=yNKDAb 5q+Sv58OjwfK8EvCMuhlRlsmETGxURmzOse3mY6lrKd5iIFHweMCYW6Vu94SomAN Q/TulHeTXq/jfr7jSvdSekoR8QhqO/BhQozSxkL91XTCp3ag/31c4JtddCe+R0qJ 2VKWXVwrFvBEnAVpwFQn/ogjV2JmLXMcLJQQk= Received: (qmail 15956 invoked from network); 7 Sep 2011 20:14:36 -0000 X-AntiVirus: Clean Received: from gateway.gossamer-threads.com (HELO ?192.168.1.152?) (nathan@gossamer-threads.com@208.70.247.145) by gossamer.nmsrv.com with ESMTPSA (DHE-RSA-CAMELLIA256-SHA encrypted); 7 Sep 2011 20:14:36 -0000 Message-ID: <4E67D0A9.4030101@gt.net> Date: Wed, 07 Sep 2011 13:14:33 -0700 From: Nathan March User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:7.0) Gecko/20110905 Thunderbird/7.0 MIME-Version: 1.0 To: Jeremy Fitzhardinge Subject: Re: [Xen-devel] Updated git locations now that kernel.org is no longer hosting? References: <4E67C7D9.1060607@gt.net> <4E67CFA6.1090604@goop.org> In-Reply-To: <4E67CFA6.1090604@goop.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: xen-devel mailing list X-BeenThere: xen-devel@lists.xensource.com X-Mailman-Version: 2.1.5 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xensource.com Errors-To: xen-devel-bounces@lists.xensource.com On 9/7/2011 1:10 PM, Jeremy Fitzhardinge wrote: > On 09/07/2011 12:36 PM, Nathan March wrote: >> Hi, >> >> Just wondering if anyone can point me to the new locations for >> xen/next-3.0 repo? > That's a branch name. Which specific repo are you looking for? > > I'm using github (git://github.com/jsgf/linux-xen.git), but I don't > recommend any the branches there for use as-is. > > J Oops, was looking for either jeremy or konrad's trunk. Running into an issue with vm's not-responding under high IO load and am looking to try tapdisk2 again, switched to blkback when going to mainline linux 3.0. Looking for whatever would be considered the stable 3.x with tapdisk2 support? - Nathan _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel From xen-devel-bounces@lists.xensource.com Wed Sep 07 13:23:04 2011 Return-path: Envelope-to: www-data@lists.xensource.com Delivery-date: Wed, 07 Sep 2011 13:23:04 -0700 Received: from localhost ([127.0.0.1] helo=lists.colo.xensource.com) by lists.xensource.com with esmtp (Exim 4.43) id 1R1OeG-0006JE-9v; Wed, 07 Sep 2011 13:23:04 -0700 Received: from mail21.messagelabs.com ([85.158.143.35]) by lists.xensource.com with smtp (Exim 4.43) id 1R1Odg-00066l-RI for xen-devel@lists.xensource.com; Wed, 07 Sep 2011 13:22:29 -0700 X-Env-Sender: stefan.bader@canonical.com X-Msg-Ref: server-12.tower-21.messagelabs.com!1315426931!49083574!1 X-Originating-IP: [91.189.89.112] X-StarScan-Version: 6.3.6; banners=-,-,- X-VirusChecked: Checked Received: (qmail 14826 invoked from network); 7 Sep 2011 20:22:11 -0000 Received: from youngberry.canonical.com (HELO youngberry.canonical.com) (91.189.89.112) by server-12.tower-21.messagelabs.com with SMTP; 7 Sep 2011 20:22:11 -0000 Received: from [50.0.61.98] (helo=[10.20.1.131]) by youngberry.canonical.com with esmtpsa (TLS1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.71) (envelope-from ) id 1R1OdZ-0002lH-7F; Wed, 07 Sep 2011 20:22:21 +0000 Message-ID: <4E67D276.2060809@canonical.com> Date: Wed, 07 Sep 2011 13:22:14 -0700 From: Stefan Bader User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.2.21) Gecko/20110831 Lightning/1.0b2 Thunderbird/3.1.13 MIME-Version: 1.0 To: Konrad Rzeszutek Wilk Subject: Re: [Xen-devel] [PATCH] xen: disable PV spinlocks on HVM References: <1315327307-392-1-git-send-email-stefano.stabellini@eu.citrix.com> <20110906170255.GA29839@dumpdata.com> In-Reply-To: <20110906170255.GA29839@dumpdata.com> X-Enigmail-Version: 1.1.2 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: xen-devel@lists.xensource.com, linux-kernel@vger.kernel.org, stefano.stabellini@eu.citrix.com X-BeenThere: xen-devel@lists.xensource.com X-Mailman-Version: 2.1.5 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xensource.com Errors-To: xen-devel-bounces@lists.xensource.com On 06.09.2011 10:02, Konrad Rzeszutek Wilk wrote: > On Tue, Sep 06, 2011 at 05:41:47PM +0100, stefano.stabellini@eu.citrix.com wrote: >> From: Stefano Stabellini >> >> PV spinlocks cannot possibly work with the current code because they are >> enabled after pvops patching has already been done, and because PV >> spinlocks use a different data structure than native spinlocks so we >> cannot switch between them dynamically. A spinlock that has been taken >> once by the native code (__ticket_spin_lock) cannot be taken by >> __xen_spin_lock even after it has been released. > > Let me stick it on my 3.1-rc5 bug-fix list and add stable@kernel.org to it. > > Stefan, if you have some time this week, and can test it - I can also > stick 'Tested-by' if you would like. > > Thinking to send the patches on Friday. > >> >> Reported-by: Stefan Bader >> Signed-off-by: Stefano Stabellini >> --- >> arch/x86/xen/smp.c | 1 - >> 1 files changed, 0 insertions(+), 1 deletions(-) >> >> diff --git a/arch/x86/xen/smp.c b/arch/x86/xen/smp.c >> index e79dbb9..51339b4 100644 >> --- a/arch/x86/xen/smp.c >> +++ b/arch/x86/xen/smp.c >> @@ -522,7 +522,6 @@ static void __init xen_hvm_smp_prepare_cpus(unsigned int max_cpus) >> WARN_ON(xen_smp_intr_init(0)); >> >> xen_init_lock_cpu(0); >> - xen_init_spinlocks(); >> } >> >> static int __cpuinit xen_hvm_cpu_up(unsigned int cpu) >> -- >> 1.7.2.3 >> >> >> _______________________________________________ >> Xen-devel mailing list >> Xen-devel@lists.xensource.com >> http://lists.xensource.com/xen-devel Ok, tried with a kernel that only disables the init call and it does work the same. That said, something still is not completely right with the NIC device interrupts. Setup looks good and pings work. But doing any larger trnasfers seems to loose interrupts, resulting in tx queue being full and getting timeouts... -Stefan _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel From xen-devel-bounces@lists.xensource.com Wed Sep 07 13:46:36 2011 Return-path: Envelope-to: www-data@lists.xensource.com Delivery-date: Wed, 07 Sep 2011 13:46:36 -0700 Received: from localhost ([127.0.0.1] helo=lists.colo.xensource.com) by lists.xensource.com with esmtp (Exim 4.43) id 1R1P11-0007Xw-B9; Wed, 07 Sep 2011 13:46:35 -0700 Received: from mail21.messagelabs.com ([85.158.143.35]) by lists.xensource.com with smtp (Exim 4.43) id 1R1P0F-0007L5-UN for xen-devel@lists.xensource.com; Wed, 07 Sep 2011 13:45:48 -0700 X-Env-Sender: Ian.Jackson@eu.citrix.com X-Msg-Ref: server-10.tower-21.messagelabs.com!1315428331!53252412!1 X-Originating-IP: [62.200.22.115] X-StarScan-Version: 6.3.6; banners=-,-,- X-VirusChecked: Checked Received: (qmail 22711 invoked from network); 7 Sep 2011 20:45:31 -0000 Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115) by server-10.tower-21.messagelabs.com with SMTP; 7 Sep 2011 20:45:31 -0000 X-IronPort-AV: E=Sophos;i="4.68,347,1312156800"; d="scan'208";a="7661884" Received: from lonpmailmx01.citrite.net ([10.30.203.162]) by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5; 07 Sep 2011 20:45:44 +0000 Received: from woking.xci-test.com (10.80.248.135) by smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id 8.3.137.0; Wed, 7 Sep 2011 21:45:44 +0100 Received: from osstest by woking.xci-test.com with local (Exim 4.69) (envelope-from ) id 1R1P0B-0007hw-Po; Wed, 07 Sep 2011 21:45:43 +0100 To: xen-devel@lists.xensource.com Message-ID: From: xen.org Date: Wed, 7 Sep 2011 21:45:43 +0100 MIME-Version: 1.0 Content-Type: text/plain Cc: ian.jackson@eu.citrix.com Subject: [Xen-devel] [xen-4.1-testing test] 8853: tolerable FAIL - PUSHED X-BeenThere: xen-devel@lists.xensource.com X-Mailman-Version: 2.1.5 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xensource.com Errors-To: xen-devel-bounces@lists.xensource.com flight 8853 xen-4.1-testing real [real] http://www.chiark.greenend.org.uk/~xensrcts/logs/8853/ Failures :-/ but no regressions. Tests which did not succeed, but are not blocking, including regressions (tests previously passed) regarded as allowable: test-amd64-amd64-xl-pcipt-intel 9 guest-start fail never pass test-amd64-i386-rhel6hvm-intel 9 guest-start.2 fail never pass test-amd64-i386-rhel6hvm-amd 9 guest-start.2 fail never pass test-amd64-amd64-xl-sedf 13 guest-localmigrate.2 fail like 8802 test-amd64-i386-win-vcpus1 16 leak-check/check fail never pass test-amd64-i386-xl-win-vcpus1 13 guest-stop fail never pass test-amd64-i386-win 16 leak-check/check fail never pass test-amd64-amd64-win 16 leak-check/check fail never pass test-amd64-amd64-xl-win 13 guest-stop fail never pass test-i386-i386-win 16 leak-check/check fail never pass test-i386-i386-xl-win 13 guest-stop fail never pass version targeted for testing: xen 2376070f6685 baseline version: xen 6239209bb560 ------------------------------------------------------------ People who touched revisions under test: Jan Beulich Stefano Stabellini ------------------------------------------------------------ jobs: build-amd64 pass build-i386 pass build-amd64-oldkern pass build-i386-oldkern pass build-amd64-pvops pass build-i386-pvops pass test-amd64-amd64-xl pass test-amd64-i386-xl pass test-i386-i386-xl pass test-amd64-i386-rhel6hvm-amd fail test-amd64-i386-xl-credit2 pass test-amd64-amd64-xl-pcipt-intel fail test-amd64-i386-rhel6hvm-intel fail test-amd64-i386-xl-multivcpu pass test-amd64-amd64-pair pass test-amd64-i386-pair pass test-i386-i386-pair pass test-amd64-amd64-pv pass test-amd64-i386-pv pass test-i386-i386-pv pass test-amd64-amd64-xl-sedf fail test-amd64-i386-win-vcpus1 fail test-amd64-i386-xl-win-vcpus1 fail test-amd64-amd64-win fail test-amd64-i386-win fail test-i386-i386-win fail test-amd64-amd64-xl-win fail test-i386-i386-xl-win fail ------------------------------------------------------------ sg-report-flight on woking.cam.xci-test.com logs: /home/xc_osstest/logs images: /home/xc_osstest/images Logs, config files, etc. are available at http://www.chiark.greenend.org.uk/~xensrcts/logs Test harness code can be found at http://xenbits.xensource.com/gitweb?p=osstest.git;a=summary Pushing revision : + branch=xen-4.1-testing + revision=2376070f6685 + . cri-lock-repos ++ . cri-common +++ umask 002 +++ getconfig Repos +++ perl -e ' use Osstest; readconfigonly(); print $c{Repos} or die $!; ' ++ repos=/export/home/osstest/repos ++ repos_lock=/export/home/osstest/repos/lock ++ '[' x '!=' x/export/home/osstest/repos/lock ']' ++ OSSTEST_REPOS_LOCK_LOCKED=/export/home/osstest/repos/lock ++ exec with-lock-ex -w /export/home/osstest/repos/lock ./ap-push xen-4.1-testing 2376070f6685 + branch=xen-4.1-testing + revision=2376070f6685 + . cri-lock-repos ++ . cri-common +++ umask 002 +++ getconfig Repos +++ perl -e ' use Osstest; readconfigonly(); print $c{Repos} or die $!; ' ++ repos=/export/home/osstest/repos ++ repos_lock=/export/home/osstest/repos/lock ++ '[' x/export/home/osstest/repos/lock '!=' x/export/home/osstest/repos/lock ']' + : xen@xenbits.xensource.com + : xen@xenbits.xensource.com:git/linux-pvops + : master + : tested/2.6.39.x + case "$branch" in + cd /export/home/osstest/repos/xen-4.1-testing.hg + hg push -r 2376070f6685 ssh://xen@xenbits.xensource.com/HG/xen-4.1-testing.hg pushing to ssh://xen@xenbits.xensource.com/HG/xen-4.1-testing.hg searching for changes remote: adding changesets remote: adding manifests remote: adding file changes remote: added 4 changesets with 4 changes to 4 files _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel From xen-devel-bounces@lists.xensource.com Wed Sep 07 13:53:32 2011 Return-path: Envelope-to: www-data@lists.xensource.com Delivery-date: Wed, 07 Sep 2011 13:53:32 -0700 Received: from localhost ([127.0.0.1] helo=lists.colo.xensource.com) by lists.xensource.com with esmtp (Exim 4.43) id 1R1P7j-00085s-Vg; Wed, 07 Sep 2011 13:53:32 -0700 Received: from mail182.messagelabs.com ([85.158.139.83]) by lists.xensource.com with esmtp (Exim 4.43) id 1R1P7J-0007uD-F7 for xen-devel@lists.xensource.com; Wed, 07 Sep 2011 13:53:05 -0700 X-Env-Sender: xisisu@gmail.com X-Msg-Ref: server-14.tower-182.messagelabs.com!1315428781!17292744!1 X-Originating-IP: [74.125.83.41] X-StarScan-Version: 6.3.6; banners=-,-,- X-VirusChecked: Checked Received: (qmail 4557 invoked from network); 7 Sep 2011 20:53:02 -0000 Received: from mail-gw0-f41.google.com (HELO mail-gw0-f41.google.com) (74.125.83.41) by server-14.tower-182.messagelabs.com with RC4-SHA encrypted SMTP; 7 Sep 2011 20:53:02 -0000 Received: by gwaa20 with SMTP id a20so67932gwa.28 for ; Wed, 07 Sep 2011 13:53:01 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:from:date:message-id:subject:to:content-type; bh=J8XgH9tNy5xB4j5HeyTilR0zy8unnppQs1PpsykSaRg=; b=x8SLhf8kT8+OuGznv+ELhoS9CUp0Mz0cs6xRLSaj1GgKj+uWmwD68qG4F+6vB797Vt I199BdAk64qLvsjBVX/6pRcTbPxKolwQGPnuNUhEiaTrUSmnUpDCVhkM4GLelG0rxN/c +3METdKVGiUZgiakVFrSov1LP3Ri+UaYPH664= Received: by 10.151.50.14 with SMTP id c14mr67718ybk.113.1315428781092; Wed, 07 Sep 2011 13:53:01 -0700 (PDT) MIME-Version: 1.0 Received: by 10.150.186.4 with HTTP; Wed, 7 Sep 2011 13:52:21 -0700 (PDT) From: Sisu Xi Date: Wed, 7 Sep 2011 15:52:21 -0500 Message-ID: To: xen-devel@lists.xensource.com Content-Type: text/plain; charset=UTF-8 Subject: [Xen-devel] network IO buffer? -- Sisu X-BeenThere: xen-devel@lists.xensource.com X-Mailman-Version: 2.1.5 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xensource.com Errors-To: xen-devel-bounces@lists.xensource.com Hi, all: I want to study the latency in receiving a pkt in Xen. Here is my set up: kernel version is 2.6.32.25, applied the patch. Credit Based Scheduler is used. Dom0 is with 1 VCPU, pinned to core 0, while Dom1 and Dom2 (one VCPU each) are both pinned to another separate core. Then I run a echo program in Dom1 to another server. If there is no interference, the round trip time was like 250 microseconds. But, if I run a iperf in Dom2 to generate the maximum interference, the round trip time in Dom1 was like 40 ms, 160 times the original case! Does anyone know where is the pkt buffered? I already checked the net_rx_action in netback.c in Dom0, the length of the queue is like 1 or 2 most of the time, which meas the pkt is buffered some where else? Could anyone help me with this? Thanks very much! Best! Yours, Sisu _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel From xen-devel-bounces@lists.xensource.com Wed Sep 07 14:03:13 2011 Return-path: Envelope-to: www-data@lists.xensource.com Delivery-date: Wed, 07 Sep 2011 14:03:13 -0700 Received: from localhost ([127.0.0.1] helo=lists.colo.xensource.com) by lists.xensource.com with esmtp (Exim 4.43) id 1R1PH7-0000Aq-BQ; Wed, 07 Sep 2011 14:03:13 -0700 Received: from mail182.messagelabs.com ([85.158.139.83]) by lists.xensource.com with esmtp (Exim 4.43) id 1R1PEK-0008OH-PN for xen-devel@lists.xensource.com; Wed, 07 Sep 2011 14:00:46 -0700 X-Env-Sender: pasik@iki.fi X-Msg-Ref: server-9.tower-182.messagelabs.com!1315429216!17449883!1 X-Originating-IP: [192.89.123.25] X-StarScan-Version: 6.3.6; banners=-,-,- X-VirusChecked: Checked Received: (qmail 22789 invoked from network); 7 Sep 2011 21:00:16 -0000 Received: from smtp.tele.fi (HELO smtp.tele.fi) (192.89.123.25) by server-9.tower-182.messagelabs.com with DHE-RSA-AES256-SHA encrypted SMTP; 7 Sep 2011 21:00:16 -0000 X-Originating-Ip: [194.89.68.22] Received: from ydin.reaktio.net (reaktio.net [194.89.68.22]) by smtp.tele.fi (Postfix) with ESMTP id 7EFDC11FC; Thu, 8 Sep 2011 00:00:15 +0300 (EEST) Received: by ydin.reaktio.net (Postfix, from userid 1001) id 4963820059; Thu, 8 Sep 2011 00:00:15 +0300 (EEST) Date: Thu, 8 Sep 2011 00:00:15 +0300 From: Pasi =?iso-8859-1?Q?K=E4rkk=E4inen?= To: Konrad Rzeszutek Wilk Subject: Re: [Xen-devel] Memory fragmentation and PCI passthrough Message-ID: <20110907210015.GU12984@reaktio.net> References: <4E665E53.3@invisiblethingslab.com> <20110907173622.GJ32190@dumpdata.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20110907173622.GJ32190@dumpdata.com> User-Agent: Mutt/1.5.18 (2008-05-17) Cc: "xen-devel@lists.xensource.com" , Marek Marczykowski , Joanna Rutkowska , Rafal Wojtczuk X-BeenThere: xen-devel@lists.xensource.com X-Mailman-Version: 2.1.5 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xensource.com Errors-To: xen-devel-bounces@lists.xensource.com On Wed, Sep 07, 2011 at 01:36:22PM -0400, Konrad Rzeszutek Wilk wrote: > On Tue, Sep 06, 2011 at 07:54:27PM +0200, Marek Marczykowski wrote: > > Hello, > > > > I've hit known problem with dynamic memory management - memory > > fragmentation... This dynamic memory management basically does xl > > mem-set to balance memory. > > > > After some time of running system, xen memory is so fragmented that it > > is impossible to start new VM with PCI device. Sometimes it crashes > > during boot (no 64MB contiguous memory for SWIOTLB), or later - eg. > > iwlagn cannot allocate memory for loading firmware (few allocs, each > > bellow 100k). > > > > DomU kernel cmdline: console=hvc0 iommu=soft earlyprintk=xen > > > > There is two cases (I think): > > 1. With IOMMU > > 2. Without IOMMU > > I've tried only the second one. > > > > Is there any known solution for this problem? > > Some ideas: > > 1. With IOMMU pass iommu=pv to Xen. AFAIU domU will not need iommu=soft > > parameter then, right? Will it work then with fragmented memory? > > It will still need it. Otherwise the Xen SWIOTLB won't be used. > Btw I think Xen hypervisor "iommu=pv" is a deprecated option.. "iommu=soft" for the domU kernel is a valid option though :) -- Pasi > But you can limit the amount of memory for the SWIOTLB, say by > doing 'swiotlb=2048' > > > > > 2. Force somehow on xen/libxl to allocate memory (for domU) in chunks > > of, say 4MB, to not fragment it so badly. Is it doable? > > > > In tmem documentation is also described some workaround for this: > > reserve some memory region for allocations with 0 > tries to allocate 64MB, which much bigger than 2MB... Is it really > > needed to allocate such big region of contiguous memory in one piece? > > Nope. It only uses that pool for 32-bit devices too - so there is not > really a big need for it. > > > > > > -- > > Pozdrawiam / Best Regards, > > Marek Marczykowski > > Invisible Things Lab > > > > > > > _______________________________________________ > > Xen-devel mailing list > > Xen-devel@lists.xensource.com > > http://lists.xensource.com/xen-devel > > > _______________________________________________ > Xen-devel mailing list > Xen-devel@lists.xensource.com > http://lists.xensource.com/xen-devel _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel From xen-devel-bounces@lists.xensource.com Wed Sep 07 14:04:50 2011 Return-path: Envelope-to: www-data@lists.xensource.com Delivery-date: Wed, 07 Sep 2011 14:04:50 -0700 Received: from localhost ([127.0.0.1] helo=lists.colo.xensource.com) by lists.xensource.com with esmtp (Exim 4.43) id 1R1PIf-0000YV-QL; Wed, 07 Sep 2011 14:04:50 -0700 Received: from mail174.messagelabs.com ([85.158.138.51]) by lists.xensource.com with esmtp (Exim 4.43) id 1R1PHx-0000M2-95 for xen-devel@lists.xensource.com; Wed, 07 Sep 2011 14:04:09 -0700 X-Env-Sender: konrad@dumpdata.com X-Msg-Ref: server-3.tower-174.messagelabs.com!1315429440!24545656!1 X-Originating-IP: [141.146.126.227] X-StarScan-Version: 6.3.6; banners=-,-,- X-VirusChecked: Checked Received: (qmail 23566 invoked from network); 7 Sep 2011 21:04:02 -0000 Received: from acsinet15.oracle.com (HELO acsinet15.oracle.com) (141.146.126.227) by server-3.tower-174.messagelabs.com with DHE-RSA-AES256-SHA encrypted SMTP; 7 Sep 2011 21:04:02 -0000 Received: from acsinet21.oracle.com (acsinet21.oracle.com [141.146.126.237]) by acsinet15.oracle.com (Switch-3.4.4/Switch-3.4.4) with ESMTP id p87L3t1p011783 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Wed, 7 Sep 2011 21:03:57 GMT Received: from acsmt358.oracle.com (acsmt358.oracle.com [141.146.40.158]) by acsinet21.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id p87L3r0w005957 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 7 Sep 2011 21:03:54 GMT Received: from abhmt103.oracle.com (abhmt103.oracle.com [141.146.116.55]) by acsmt358.oracle.com (8.12.11.20060308/8.12.11) with ESMTP id p87L3lln031703; Wed, 7 Sep 2011 16:03:47 -0500 Received: from phenom (/209.6.55.207) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Wed, 07 Sep 2011 14:03:47 -0700 Received: by phenom (Postfix, from userid 1000) id 312B810D6; Wed, 7 Sep 2011 17:03:34 -0400 (EDT) Date: Wed, 7 Sep 2011 17:03:34 -0400 From: Konrad Rzeszutek Wilk To: Nathan March Subject: Re: [Xen-devel] Updated git locations now that kernel.org is no longer hosting? Message-ID: <20110907210334.GA20800@dumpdata.com> References: <4E67C7D9.1060607@gt.net> <4E67CFA6.1090604@goop.org> <4E67D0A9.4030101@gt.net> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <4E67D0A9.4030101@gt.net> User-Agent: Mutt/1.5.21 (2010-09-15) X-Source-IP: acsinet21.oracle.com [141.146.126.237] X-Auth-Type: Internal IP X-CT-RefId: str=0001.0A090202.4E67DC3E.0007:SCFMA922111,ss=1,re=-4.000,fgs=0 Cc: Jeremy Fitzhardinge , xen-devel mailing list X-BeenThere: xen-devel@lists.xensource.com X-Mailman-Version: 2.1.5 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xensource.com Errors-To: xen-devel-bounces@lists.xensource.com On Wed, Sep 07, 2011 at 01:14:33PM -0700, Nathan March wrote: > > On 9/7/2011 1:10 PM, Jeremy Fitzhardinge wrote: > >On 09/07/2011 12:36 PM, Nathan March wrote: > >>Hi, > >> > >>Just wondering if anyone can point me to the new locations for > >>xen/next-3.0 repo? > >That's a branch name. Which specific repo are you looking for? > > > >I'm using github (git://github.com/jsgf/linux-xen.git), but I don't > >recommend any the branches there for use as-is. > > > > J > > Oops, was looking for either jeremy or konrad's trunk. > > Running into an issue with vm's not-responding under high IO load > and am looking to try tapdisk2 again, switched to blkback when going > to mainline linux 3.0. Looking for whatever would be considered the > stable 3.x with tapdisk2 support? http://xenbits.xen.org/gitweb/?p=people/dstodden/blktap-debian.git;a=summary or perhaps http://xenbits.xen.org/gitweb/?p=people/dstodden/linux.git;a=summary or http://xenbits.xen.org/gitweb/?p=people/dstodden/blktap.git;a=summary ? > > - Nathan > > _______________________________________________ > Xen-devel mailing list > Xen-devel@lists.xensource.com > http://lists.xensource.com/xen-devel _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel From xen-devel-bounces@lists.xensource.com Wed Sep 07 14:27:03 2011 Return-path: Envelope-to: www-data@lists.xensource.com Delivery-date: Wed, 07 Sep 2011 14:27:03 -0700 Received: from localhost ([127.0.0.1] helo=lists.colo.xensource.com) by lists.xensource.com with esmtp (Exim 4.43) id 1R1PeB-000217-ML; Wed, 07 Sep 2011 14:27:03 -0700 Received: from mail216.messagelabs.com ([85.158.143.99]) by lists.xensource.com with esmtp (Exim 4.43) id 1R1Pbo-0001BJ-Lo for xen-devel@lists.xensource.com; Wed, 07 Sep 2011 14:24:37 -0700 X-Env-Sender: jeremy@goop.org X-Msg-Ref: server-2.tower-216.messagelabs.com!1315430672!17434369!1 X-Originating-IP: [74.207.240.146] X-StarScan-Version: 6.3.6; banners=-,-,- X-VirusChecked: Checked Received: (qmail 15102 invoked from network); 7 Sep 2011 21:24:33 -0000 Received: from claw.goop.org (HELO claw.goop.org) (74.207.240.146) by server-2.tower-216.messagelabs.com with DHE-RSA-AES256-SHA encrypted SMTP; 7 Sep 2011 21:24:33 -0000 Received: from saboo.goop.org (unknown [IPv6:2001:470:1f05:899:f459:42ff:fe6b:81d1]) (Authenticated sender: smtp-saboo) by claw.goop.org (Postfix) with ESMTPSA id C67049130; Wed, 7 Sep 2011 14:24:30 -0700 (PDT) Received: from saboo.goop.org (localhost [IPv6:::1]) by saboo.goop.org (Postfix) with ESMTP id ADD9D20277; Wed, 7 Sep 2011 14:24:26 -0700 (PDT) Message-ID: <4E67E10A.3020809@goop.org> Date: Wed, 07 Sep 2011 14:24:26 -0700 From: Jeremy Fitzhardinge User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:6.0) Gecko/20110816 Thunderbird/6.0 MIME-Version: 1.0 To: stefano.stabellini@eu.citrix.com References: <1315327307-392-1-git-send-email-stefano.stabellini@eu.citrix.com> In-Reply-To: <1315327307-392-1-git-send-email-stefano.stabellini@eu.citrix.com> X-Enigmail-Version: 1.3.1 Content-Type: text/plain; charset=ISO-8859-15 Content-Transfer-Encoding: 7bit Cc: xen-devel@lists.xensource.com, linux-kernel@vger.kernel.org, konrad.wilk@oracle.com Subject: [Xen-devel] Re: [PATCH] xen: disable PV spinlocks on HVM X-BeenThere: xen-devel@lists.xensource.com X-Mailman-Version: 2.1.5 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xensource.com Errors-To: xen-devel-bounces@lists.xensource.com On 09/06/2011 09:41 AM, stefano.stabellini@eu.citrix.com wrote: > From: Stefano Stabellini > > PV spinlocks cannot possibly work with the current code because they are > enabled after pvops patching has already been done, and because PV > spinlocks use a different data structure than native spinlocks so we > cannot switch between them dynamically. A spinlock that has been taken > once by the native code (__ticket_spin_lock) cannot be taken by > __xen_spin_lock even after it has been released. > > Reported-by: Stefan Bader > Signed-off-by: Stefano Stabellini > --- > arch/x86/xen/smp.c | 1 - > 1 files changed, 0 insertions(+), 1 deletions(-) > > diff --git a/arch/x86/xen/smp.c b/arch/x86/xen/smp.c > index e79dbb9..51339b4 100644 > --- a/arch/x86/xen/smp.c > +++ b/arch/x86/xen/smp.c > @@ -522,7 +522,6 @@ static void __init xen_hvm_smp_prepare_cpus(unsigned int max_cpus) > WARN_ON(xen_smp_intr_init(0)); > > xen_init_lock_cpu(0); > - xen_init_spinlocks(); > } Should I add this back here on the pv ticketlock branch? J _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel From xen-devel-bounces@lists.xensource.com Wed Sep 07 15:26:46 2011 Return-path: Envelope-to: www-data@lists.xensource.com Delivery-date: Wed, 07 Sep 2011 15:26:46 -0700 Received: from localhost ([127.0.0.1] helo=lists.colo.xensource.com) by lists.xensource.com with esmtp (Exim 4.43) id 1R1QZy-000423-8J; Wed, 07 Sep 2011 15:26:46 -0700 Received: from mail27.messagelabs.com ([193.109.254.147]) by lists.xensource.com with smtp (Exim 4.43) id 1R1QZN-0003pz-Lk for xen-devel@lists.xensource.com; Wed, 07 Sep 2011 15:26:13 -0700 X-Env-Sender: Andrew.Cooper3@citrix.com X-Msg-Ref: server-7.tower-27.messagelabs.com!1315434346!47717782!1 X-Originating-IP: [62.200.22.115] X-StarScan-Version: 6.3.6; banners=-,-,- X-VirusChecked: Checked Received: (qmail 31838 invoked from network); 7 Sep 2011 22:25:46 -0000 Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115) by server-7.tower-27.messagelabs.com with SMTP; 7 Sep 2011 22:25:46 -0000 X-IronPort-AV: E=Sophos;i="4.68,347,1312156800"; d="scan'208";a="7662918" Received: from lonpmailmx01.citrite.net ([10.30.203.162]) by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5; 07 Sep 2011 22:26:06 +0000 Received: from [10.30.249.79] (10.30.249.79) by LONPMAILMX01.citrite.net (10.30.203.162) with Microsoft SMTP Server id 8.3.137.0; Wed, 7 Sep 2011 23:26:06 +0100 Message-ID: <4E67EF76.4020602@citrix.com> Date: Wed, 7 Sep 2011 23:25:58 +0100 From: Andrew Cooper User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:6.0.1) Gecko/20110830 Thunderbird/6.0.1 MIME-Version: 1.0 To: Keir Fraser Subject: Re: [Xen-devel] [PATCH] IRQ: Group IRQ_MOVE_CLEANUP_VECTOR with other hypervisor IPIs References: In-Reply-To: Content-Type: text/plain; charset="ISO-8859-1" Content-Transfer-Encoding: 7bit Cc: "xen-devel@lists.xensource.com" , Jan Beulich X-BeenThere: xen-devel@lists.xensource.com X-Mailman-Version: 2.1.5 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xensource.com Errors-To: xen-devel-bounces@lists.xensource.com On 07/09/2011 17:56, Keir Fraser wrote: > On 07/09/2011 17:03, "Jan Beulich" wrote: > >>>>> On 07.09.11 at 17:03, Andrew Cooper wrote: >> Are you sure this is correct? I'm suspicious that this may intentionally >> have been the lowest priority vector... > I can't see why? It is probably the lowest priority of the Xen IPIs. Having said that, it really doesnt want to be pre-empted by something expecting to use an irq_desc or irq_cfg. However, vector 0xf0 seems to be used for IRQ0 before interrupts are set up, which is probably unintended (although doesn't seem to have any interaction problems) > >>> Also, rename to MOVE_CLEANUP_VECTOR to be in line with the other IPI >>> names. >> Why would the removal of part of the descriptive name be in line with >> the other names? We're dealing with the cleanup after an IRQ move >> here, so let the name state this. The IRQ_ prefix here has nothing to >> do with this being the vector for a specific IRQ. > Agreed. > > -- Keir Ok - I will resubmit without changing the IRQ_ prefix. I had not considered that meaning of the name. ~Andrew > >> Jan >> >>> This requires bumping LAST_HIPRIORITY_VECTOR, but does mean that the >>> range FIRST-LAST_HIPRIORITY_VECTORs are free once again. >>> >>> Signed-off-by: Andrew Cooper >>> >>> diff -r 0268e7380953 -r c7884dbb6f7d xen/arch/x86/apic.c >>> --- a/xen/arch/x86/apic.c Mon Sep 05 15:10:28 2011 +0100 >>> +++ b/xen/arch/x86/apic.c Wed Sep 07 16:00:55 2011 +0100 >>> @@ -90,7 +90,7 @@ bool_t __read_mostly directed_eoi_enable >>> * through the ICC by us (IPIs) >>> */ >>> __asm__(".section .text"); >>> -BUILD_SMP_INTERRUPT(irq_move_cleanup_interrupt,IRQ_MOVE_CLEANUP_VECTOR) >>> +BUILD_SMP_INTERRUPT(irq_move_cleanup_interrupt,MOVE_CLEANUP_VECTOR) >>> BUILD_SMP_INTERRUPT(event_check_interrupt,EVENT_CHECK_VECTOR) >>> BUILD_SMP_INTERRUPT(invalidate_interrupt,INVALIDATE_TLB_VECTOR) >>> BUILD_SMP_INTERRUPT(call_function_interrupt,CALL_FUNCTION_VECTOR) >>> diff -r 0268e7380953 -r c7884dbb6f7d xen/arch/x86/hvm/vmx/vmx.c >>> --- a/xen/arch/x86/hvm/vmx/vmx.c Mon Sep 05 15:10:28 2011 +0100 >>> +++ b/xen/arch/x86/hvm/vmx/vmx.c Wed Sep 07 16:00:55 2011 +0100 >>> @@ -1986,7 +1986,7 @@ static void vmx_do_extint(struct cpu_use >>> >>> switch ( vector ) >>> { >>> - case IRQ_MOVE_CLEANUP_VECTOR: >>> + case MOVE_CLEANUP_VECTOR: >>> smp_irq_move_cleanup_interrupt(regs); >>> break; >>> case LOCAL_TIMER_VECTOR: >>> diff -r 0268e7380953 -r c7884dbb6f7d xen/arch/x86/io_apic.c >>> --- a/xen/arch/x86/io_apic.c Mon Sep 05 15:10:28 2011 +0100 >>> +++ b/xen/arch/x86/io_apic.c Wed Sep 07 16:00:55 2011 +0100 >>> @@ -476,7 +476,7 @@ fastcall void smp_irq_move_cleanup_inter >>> * to myself. >>> */ >>> if (irr & (1 << (vector % 32))) { >>> - genapic->send_IPI_self(IRQ_MOVE_CLEANUP_VECTOR); >>> + genapic->send_IPI_self(MOVE_CLEANUP_VECTOR); >>> TRACE_3D(TRC_HW_IRQ_MOVE_CLEANUP_DELAY, >>> irq, vector, smp_processor_id()); >>> goto unlock; >>> @@ -513,7 +513,7 @@ static void send_cleanup_vector(struct i >>> >>> cpus_and(cleanup_mask, cfg->old_cpu_mask, cpu_online_map); >>> cfg->move_cleanup_count = cpus_weight(cleanup_mask); >>> - genapic->send_IPI_mask(&cleanup_mask, IRQ_MOVE_CLEANUP_VECTOR); >>> + genapic->send_IPI_mask(&cleanup_mask, MOVE_CLEANUP_VECTOR); >>> >>> cfg->move_in_progress = 0; >>> } >>> diff -r 0268e7380953 -r c7884dbb6f7d xen/arch/x86/irq.c >>> --- a/xen/arch/x86/irq.c Mon Sep 05 15:10:28 2011 +0100 >>> +++ b/xen/arch/x86/irq.c Wed Sep 07 16:00:55 2011 +0100 >>> @@ -338,7 +338,7 @@ int __init init_irq_data(void) >>> set_bit(HYPERCALL_VECTOR, used_vectors); >>> >>> /* IRQ_MOVE_CLEANUP_VECTOR used for clean up vectors */ >>> - set_bit(IRQ_MOVE_CLEANUP_VECTOR, used_vectors); >>> + set_bit(MOVE_CLEANUP_VECTOR, used_vectors); >>> >>> return 0; >>> } >>> diff -r 0268e7380953 -r c7884dbb6f7d xen/arch/x86/smpboot.c >>> --- a/xen/arch/x86/smpboot.c Mon Sep 05 15:10:28 2011 +0100 >>> +++ b/xen/arch/x86/smpboot.c Wed Sep 07 16:00:55 2011 +0100 >>> @@ -1027,7 +1027,7 @@ void __init smp_intr_init(void) >>> } >>> >>> /* IPI for cleanuping vectors after irq move */ >>> - set_intr_gate(IRQ_MOVE_CLEANUP_VECTOR, irq_move_cleanup_interrupt); >>> + set_intr_gate(MOVE_CLEANUP_VECTOR, irq_move_cleanup_interrupt); >>> >>> /* IPI for event checking. */ >>> set_intr_gate(EVENT_CHECK_VECTOR, event_check_interrupt); >>> diff -r 0268e7380953 -r c7884dbb6f7d >>> xen/include/asm-x86/mach-default/irq_vectors.h >>> --- a/xen/include/asm-x86/mach-default/irq_vectors.h Mon Sep 05 15:10:28 2011 >>> +0100 >>> +++ b/xen/include/asm-x86/mach-default/irq_vectors.h Wed Sep 07 16:00:55 2011 >>> +0100 >>> @@ -11,12 +11,14 @@ >>> #define LOCAL_TIMER_VECTOR 0xf9 >>> #define PMU_APIC_VECTOR 0xf8 >>> #define CMCI_APIC_VECTOR 0xf7 >>> +#define MOVE_CLEANUP_VECTOR 0xf6 >>> + >>> /* >>> * High-priority dynamically-allocated vectors. For interrupts that >>> * must be higher priority than any guest-bound interrupt. >>> */ >>> #define FIRST_HIPRIORITY_VECTOR 0xf0 >>> -#define LAST_HIPRIORITY_VECTOR 0xf6 >>> +#define LAST_HIPRIORITY_VECTOR 0xf5 >>> >>> /* Legacy PIC uses vectors 0xe0-0xef. */ >>> #define FIRST_LEGACY_VECTOR 0xe0 >>> @@ -30,8 +32,6 @@ >>> #define LAST_DYNAMIC_VECTOR 0xdf >>> #define NR_DYNAMIC_VECTORS (LAST_DYNAMIC_VECTOR - FIRST_DYNAMIC_VECTOR + 1) >>> >>> -#define IRQ_MOVE_CLEANUP_VECTOR FIRST_DYNAMIC_VECTOR >>> - >>> #define NR_VECTORS 256 >>> >>> #endif /* _ASM_IRQ_VECTORS_H */ >>> >>> _______________________________________________ >>> Xen-devel mailing list >>> Xen-devel@lists.xensource.com >>> http://lists.xensource.com/xen-devel >> >> >> _______________________________________________ >> Xen-devel mailing list >> Xen-devel@lists.xensource.com >> http://lists.xensource.com/xen-devel > _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel From xen-devel-bounces@lists.xensource.com Wed Sep 07 15:29:09 2011 Return-path: Envelope-to: www-data@lists.xensource.com Delivery-date: Wed, 07 Sep 2011 15:29:09 -0700 Received: from localhost ([127.0.0.1] helo=lists.colo.xensource.com) by lists.xensource.com with esmtp (Exim 4.43) id 1R1QcG-0004QG-Nm; Wed, 07 Sep 2011 15:29:09 -0700 Received: from mail21.messagelabs.com ([85.158.143.35]) by lists.xensource.com with esmtp (Exim 4.43) id 1R1QbZ-0004Db-BJ for xen-devel@lists.xensource.com; Wed, 07 Sep 2011 15:28:26 -0700 X-Env-Sender: konrad@dumpdata.com X-Msg-Ref: server-15.tower-21.messagelabs.com!1315434501!49725618!1 X-Originating-IP: [141.146.126.227] X-StarScan-Version: 6.3.6; banners=-,-,- X-VirusChecked: Checked Received: (qmail 6655 invoked from network); 7 Sep 2011 22:28:23 -0000 Received: from acsinet15.oracle.com (HELO acsinet15.oracle.com) (141.146.126.227) by server-15.tower-21.messagelabs.com with DHE-RSA-AES256-SHA encrypted SMTP; 7 Sep 2011 22:28:23 -0000 Received: from rtcsinet22.oracle.com (rtcsinet22.oracle.com [66.248.204.30]) by acsinet15.oracle.com (Switch-3.4.4/Switch-3.4.4) with ESMTP id p87MSDTT027325 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Wed, 7 Sep 2011 22:28:15 GMT Received: from acsmt356.oracle.com (acsmt356.oracle.com [141.146.40.156]) by rtcsinet22.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id p87MSAiC025825 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 7 Sep 2011 22:28:11 GMT Received: from abhmt105.oracle.com (abhmt105.oracle.com [141.146.116.57]) by acsmt356.oracle.com (8.12.11.20060308/8.12.11) with ESMTP id p87MS2qm030777; Wed, 7 Sep 2011 17:28:03 -0500 Received: from phenom (/209.6.55.207) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Wed, 07 Sep 2011 15:28:02 -0700 Received: by phenom (Postfix, from userid 1000) id AF7C010D6; Wed, 7 Sep 2011 18:27:49 -0400 (EDT) Date: Wed, 7 Sep 2011 18:27:49 -0400 From: Konrad Rzeszutek Wilk To: stefano.stabellini@eu.citrix.com Message-ID: <20110907222749.GA23258@dumpdata.com> References: <1315413571-10938-2-git-send-email-stefano.stabellini@eu.citrix.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <1315413571-10938-2-git-send-email-stefano.stabellini@eu.citrix.com> User-Agent: Mutt/1.5.21 (2010-09-15) X-Source-IP: rtcsinet22.oracle.com [66.248.204.30] X-CT-RefId: str=0001.0A090206.4E67EFFF.011A,ss=1,re=-2.300,fgs=0 Cc: Ian.Campbell@eu.citrix.com, jeremy@goop.org, xen-devel@lists.xensource.com, linux-kernel@vger.kernel.org Subject: [Xen-devel] Re: [PATCH v3 2/2] xen: modify kernel mappings corresponding to granted pages X-BeenThere: xen-devel@lists.xensource.com X-Mailman-Version: 2.1.5 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xensource.com Errors-To: xen-devel-bounces@lists.xensource.com On Wed, Sep 07, 2011 at 05:39:31PM +0100, stefano.stabellini@eu.citrix.com wrote: > From: Stefano Stabellini > > If we want to use granted pages for AIO, changing the mappings of a user > vma and the corresponding p2m is not enough, we also need to update the > kernel mappings accordingly. > In order to avoid the complexity of dealing with highmem, we allocated > the pages lowmem. > We issue a HYPERVISOR_grant_table_op right away in > m2p_add_override and we remove the mappings using another > HYPERVISOR_grant_table_op in m2p_remove_override. > Considering that m2p_add_override and m2p_remove_override are called > once per page we use multicalls and hypercall batching. > > Use the kmap_op pointer directly as argument to do the mapping as it is > guaranteed to be present up until the unmapping is done. > Before issuing any unmapping multicalls, we need to make sure that the > mapping has already being done, because we need the kmap->handle to be > set correctly. > > Signed-off-by: Stefano Stabellini > --- > arch/x86/include/asm/xen/page.h | 5 ++- > arch/x86/xen/p2m.c | 67 ++++++++++++++++++++++++++++++++------ > drivers/xen/gntdev.c | 27 +++++++++++++++- > drivers/xen/grant-table.c | 4 +- > include/xen/grant_table.h | 1 + > 5 files changed, 89 insertions(+), 15 deletions(-) > > diff --git a/arch/x86/include/asm/xen/page.h b/arch/x86/include/asm/xen/page.h > index 7ff4669..0ce1884 100644 > --- a/arch/x86/include/asm/xen/page.h > +++ b/arch/x86/include/asm/xen/page.h > @@ -12,6 +12,7 @@ > #include > > #include > +#include > #include > > /* Xen machine address */ > @@ -31,8 +32,10 @@ typedef struct xpaddr { > #define INVALID_P2M_ENTRY (~0UL) > #define FOREIGN_FRAME_BIT (1UL<<(BITS_PER_LONG-1)) > #define IDENTITY_FRAME_BIT (1UL<<(BITS_PER_LONG-2)) > +#define GRANT_FRAME_BIT (1UL<<(BITS_PER_LONG-3)) > #define FOREIGN_FRAME(m) ((m) | FOREIGN_FRAME_BIT) > #define IDENTITY_FRAME(m) ((m) | IDENTITY_FRAME_BIT) > +#define GRANT_FRAME(m) ((m) | GRANT_FRAME_BIT) > > /* Maximum amount of memory we can handle in a domain in pages */ > #define MAX_DOMAIN_PAGES \ > @@ -48,7 +51,7 @@ extern unsigned long set_phys_range_identity(unsigned long pfn_s, > unsigned long pfn_e); > > extern int m2p_add_override(unsigned long mfn, struct page *page, > - bool clear_pte); > + struct gnttab_map_grant_ref *kmap_op); > extern int m2p_remove_override(struct page *page, bool clear_pte); > extern struct page *m2p_find_override(unsigned long mfn); > extern unsigned long m2p_find_override_pfn(unsigned long mfn, unsigned long pfn); > diff --git a/arch/x86/xen/p2m.c b/arch/x86/xen/p2m.c > index 58efeb9..6c26ac80 100644 > --- a/arch/x86/xen/p2m.c > +++ b/arch/x86/xen/p2m.c > @@ -161,7 +161,9 @@ > #include > #include > #include > +#include > > +#include "multicalls.h" > #include "xen-ops.h" > > static void __init m2p_override_init(void); > @@ -676,7 +678,8 @@ static unsigned long mfn_hash(unsigned long mfn) > } > > /* Add an MFN override for a particular page */ > -int m2p_add_override(unsigned long mfn, struct page *page, bool clear_pte) > +int m2p_add_override(unsigned long mfn, struct page *page, > + struct gnttab_map_grant_ref *kmap_op) So how come you ripped out 'clear_pte' here but left it in m2p_remove_override? Is it b/c you aren't doing the pte_clear in the first place? Also there are other users of 'm2p_add_override' that you hadn't modified (blkback.c) so it will cause an compile failure. Please also test this patchset with the blkback in the picture to make sure this: cf8d91633ddef9e816ccbf3da833c79ce508988d does not happen. > { > unsigned long flags; > unsigned long pfn; > @@ -699,9 +702,20 @@ int m2p_add_override(unsigned long mfn, struct page *page, bool clear_pte) > if (unlikely(!set_phys_to_machine(pfn, FOREIGN_FRAME(mfn)))) > return -ENOMEM; > > - if (clear_pte && !PageHighMem(page)) > - /* Just zap old mapping for now */ > - pte_clear(&init_mm, address, ptep); > + if (kmap_op != NULL) { > + if (!PageHighMem(page)) { > + struct multicall_space mcs = xen_mc_entry(sizeof(*kmap_op)); > + > + MULTI_grant_table_op(mcs.mc, > + GNTTABOP_map_grant_ref, kmap_op, 1); > + > + xen_mc_issue(PARAVIRT_LAZY_MMU); > + } > + page->private |= GRANT_FRAME_BIT; > + /* let's use dev_bus_addr to record the old mfn instead */ > + kmap_op->dev_bus_addr = page->index; > + page->index = (unsigned long) kmap_op; > + } > spin_lock_irqsave(&m2p_override_lock, flags); > list_add(&page->lru, &m2p_overrides[mfn_hash(mfn)]); > spin_unlock_irqrestore(&m2p_override_lock, flags); > @@ -735,13 +749,44 @@ int m2p_remove_override(struct page *page, bool clear_pte) > spin_lock_irqsave(&m2p_override_lock, flags); > list_del(&page->lru); > spin_unlock_irqrestore(&m2p_override_lock, flags); > - set_phys_to_machine(pfn, page->index); > > - if (clear_pte && !PageHighMem(page)) > - set_pte_at(&init_mm, address, ptep, > - pfn_pte(pfn, PAGE_KERNEL)); > - /* No tlb flush necessary because the caller already > - * left the pte unmapped. */ > + if (clear_pte) { > + struct gnttab_map_grant_ref *map_op = > + (struct gnttab_map_grant_ref *) page->index; > + set_phys_to_machine(pfn, map_op->dev_bus_addr); > + if (!PageHighMem(page)) { > + struct multicall_space mcs = > + xen_mc_entry(sizeof(struct gnttab_unmap_grant_ref)); > + struct gnttab_unmap_grant_ref *unmap_op = mcs.args; > + > + /* scripts/checkpath.pl will throw a fit at the above. > + * Has the grant_op mapping multicall being issued? If not, > + * make sure it is called now. > + */ > + if (map_op->handle == -1) > + xen_mc_flush(); > + if (map_op->handle == -1) { > + printk(KERN_WARNING "m2p_remove_override: pfn %lx mfn %lx, " > + "failed to modify kernel mappings", pfn, mfn); > + return -1; > + } > + > + unmap_op->host_addr = map_op->host_addr; > + unmap_op->handle = map_op->handle; > + unmap_op->dev_bus_addr = 0; > + > + MULTI_grant_table_op(mcs.mc, > + GNTTABOP_unmap_grant_ref, unmap_op, 1); > + > + xen_mc_issue(PARAVIRT_LAZY_MMU); > + > + set_pte_at(&init_mm, address, ptep, > + pfn_pte(pfn, PAGE_KERNEL)); > + __flush_tlb_single(address); > + map_op->host_addr = 0; > + } > + } else > + set_phys_to_machine(pfn, page->index); > > return 0; > } > @@ -758,7 +803,7 @@ struct page *m2p_find_override(unsigned long mfn) > spin_lock_irqsave(&m2p_override_lock, flags); > > list_for_each_entry(p, bucket, lru) { > - if (p->private == mfn) { > + if ((p->private & (~GRANT_FRAME_BIT)) == mfn) { > ret = p; > break; > } > diff --git a/drivers/xen/gntdev.c b/drivers/xen/gntdev.c > index 07a56c2..783aaad 100644 > --- a/drivers/xen/gntdev.c > +++ b/drivers/xen/gntdev.c > @@ -83,6 +83,7 @@ struct grant_map { > struct ioctl_gntdev_grant_ref *grants; > struct gnttab_map_grant_ref *map_ops; > struct gnttab_unmap_grant_ref *unmap_ops; > + struct gnttab_map_grant_ref *kmap_ops; > struct page **pages; > }; > > @@ -116,10 +117,12 @@ static struct grant_map *gntdev_alloc_map(struct gntdev_priv *priv, int count) > add->grants = kzalloc(sizeof(add->grants[0]) * count, GFP_KERNEL); > add->map_ops = kzalloc(sizeof(add->map_ops[0]) * count, GFP_KERNEL); > add->unmap_ops = kzalloc(sizeof(add->unmap_ops[0]) * count, GFP_KERNEL); > + add->kmap_ops = kzalloc(sizeof(add->kmap_ops[0]) * count, GFP_KERNEL); > add->pages = kzalloc(sizeof(add->pages[0]) * count, GFP_KERNEL); > if (NULL == add->grants || > NULL == add->map_ops || > NULL == add->unmap_ops || > + NULL == add->kmap_ops || > NULL == add->pages) > goto err; > > @@ -129,6 +132,7 @@ static struct grant_map *gntdev_alloc_map(struct gntdev_priv *priv, int count) > for (i = 0; i < count; i++) { > add->map_ops[i].handle = -1; > add->unmap_ops[i].handle = -1; > + add->kmap_ops[i].handle = -1; > } > > add->index = 0; > @@ -142,6 +146,7 @@ err: > kfree(add->grants); > kfree(add->map_ops); > kfree(add->unmap_ops); > + kfree(add->kmap_ops); > kfree(add); > return NULL; > } > @@ -243,10 +248,30 @@ static int map_grant_pages(struct grant_map *map) > gnttab_set_unmap_op(&map->unmap_ops[i], addr, > map->flags, -1 /* handle */); > } > + } else { > + for (i = 0; i < map->count; i++) { > + unsigned level; > + unsigned long address = (unsigned long) > + pfn_to_kaddr(page_to_pfn(map->pages[i])); > + pte_t *ptep; > + u64 pte_maddr = 0; > + if (!PageHighMem(map->pages[i])) { > + ptep = lookup_address(address, &level); > + pte_maddr = > + arbitrary_virt_to_machine(ptep).maddr; > + } > + gnttab_set_map_op(&map->kmap_ops[i], pte_maddr, > + map->flags | > + GNTMAP_host_map | > + GNTMAP_contains_pte, > + map->grants[i].ref, > + map->grants[i].domid); > + } > } > > pr_debug("map %d+%d\n", map->index, map->count); > - err = gnttab_map_refs(map->map_ops, map->pages, map->count); > + err = gnttab_map_refs(map->map_ops, use_ptemod ? map->kmap_ops : NULL, > + map->pages, map->count); > if (err) > return err; > > diff --git a/drivers/xen/grant-table.c b/drivers/xen/grant-table.c > index 4f44b34..ed6622f 100644 > --- a/drivers/xen/grant-table.c > +++ b/drivers/xen/grant-table.c > @@ -448,6 +448,7 @@ unsigned int gnttab_max_grant_frames(void) > EXPORT_SYMBOL_GPL(gnttab_max_grant_frames); > > int gnttab_map_refs(struct gnttab_map_grant_ref *map_ops, > + struct gnttab_map_grant_ref *kmap_ops, > struct page **pages, unsigned int count) > { > int i, ret; > @@ -488,8 +489,7 @@ int gnttab_map_refs(struct gnttab_map_grant_ref *map_ops, > */ > return -EOPNOTSUPP; > } > - ret = m2p_add_override(mfn, pages[i], > - map_ops[i].flags & GNTMAP_contains_pte); > + ret = m2p_add_override(mfn, pages[i], &kmap_ops[i]); > if (ret) > return ret; > } > diff --git a/include/xen/grant_table.h b/include/xen/grant_table.h > index b1fab6b..6b99bfb 100644 > --- a/include/xen/grant_table.h > +++ b/include/xen/grant_table.h > @@ -156,6 +156,7 @@ unsigned int gnttab_max_grant_frames(void); > #define gnttab_map_vaddr(map) ((void *)(map.host_virt_addr)) > > int gnttab_map_refs(struct gnttab_map_grant_ref *map_ops, > + struct gnttab_map_grant_ref *kmap_ops, > struct page **pages, unsigned int count); > int gnttab_unmap_refs(struct gnttab_unmap_grant_ref *unmap_ops, > struct page **pages, unsigned int count); > -- > 1.7.2.3 _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel From xen-devel-bounces@lists.xensource.com Wed Sep 07 15:30:30 2011 Return-path: Envelope-to: www-data@lists.xensource.com Delivery-date: Wed, 07 Sep 2011 15:30:30 -0700 Received: from localhost ([127.0.0.1] helo=lists.colo.xensource.com) by lists.xensource.com with esmtp (Exim 4.43) id 1R1Qda-0004so-L5; Wed, 07 Sep 2011 15:30:30 -0700 Received: from mail174.messagelabs.com ([85.158.138.51]) by lists.xensource.com with smtp (Exim 4.43) id 1R1Qcc-0004Wm-LY for xen-devel@lists.xensource.com; Wed, 07 Sep 2011 15:29:32 -0700 X-Env-Sender: Ian.Jackson@eu.citrix.com X-Msg-Ref: server-6.tower-174.messagelabs.com!1315434567!28478260!1 X-Originating-IP: [62.200.22.115] X-StarScan-Version: 6.3.6; banners=-,-,- X-VirusChecked: Checked Received: (qmail 2571 invoked from network); 7 Sep 2011 22:29:27 -0000 Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115) by server-6.tower-174.messagelabs.com with SMTP; 7 Sep 2011 22:29:27 -0000 X-IronPort-AV: E=Sophos;i="4.68,347,1312156800"; d="scan'208";a="7662952" Received: from lonpmailmx01.citrite.net ([10.30.203.162]) by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5; 07 Sep 2011 22:29:26 +0000 Received: from woking.xci-test.com (10.80.248.135) by smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id 8.3.137.0; Wed, 7 Sep 2011 23:29:26 +0100 Received: from osstest by woking.xci-test.com with local (Exim 4.69) (envelope-from ) id 1R1QcY-0006sB-9T; Wed, 07 Sep 2011 23:29:26 +0100 To: Message-ID: From: xen.org Date: Wed, 7 Sep 2011 23:29:26 +0100 MIME-Version: 1.0 Content-Type: text/plain Cc: ian.jackson@eu.citrix.com Subject: [Xen-devel] [xen-unstable test] 8854: regressions - FAIL X-BeenThere: xen-devel@lists.xensource.com X-Mailman-Version: 2.1.5 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xensource.com Errors-To: xen-devel-bounces@lists.xensource.com flight 8854 xen-unstable real [real] http://www.chiark.greenend.org.uk/~xensrcts/logs/8854/ Regressions :-( Tests which did not succeed and are blocking: test-amd64-amd64-xl-sedf 13 guest-localmigrate.2 fail REGR. vs. 8832 Tests which did not succeed, but are not blocking, including regressions (tests previously passed) regarded as allowable: test-amd64-amd64-xl-pcipt-intel 9 guest-start fail never pass test-amd64-i386-rhel6hvm-intel 9 guest-start.2 fail never pass test-amd64-i386-win-vcpus1 16 leak-check/check fail never pass test-amd64-i386-xl-win-vcpus1 13 guest-stop fail never pass test-amd64-i386-rhel6hvm-amd 9 guest-start.2 fail never pass test-amd64-amd64-win 16 leak-check/check fail never pass test-amd64-i386-win 16 leak-check/check fail never pass test-amd64-amd64-xl-win 13 guest-stop fail never pass test-i386-i386-xl-win 13 guest-stop fail never pass test-i386-i386-win 16 leak-check/check fail never pass version targeted for testing: xen bdd19847ae63 baseline version: xen 5fe770c8a8a3 ------------------------------------------------------------ People who touched revisions under test: Ian Jackson Jan Beulich Keir Fraser Olaf Hering ------------------------------------------------------------ jobs: build-amd64 pass build-i386 pass build-amd64-oldkern pass build-i386-oldkern pass build-amd64-pvops pass build-i386-pvops pass test-amd64-amd64-xl pass test-amd64-i386-xl pass test-i386-i386-xl pass test-amd64-i386-rhel6hvm-amd fail test-amd64-i386-xl-credit2 pass test-amd64-amd64-xl-pcipt-intel fail test-amd64-i386-rhel6hvm-intel fail test-amd64-i386-xl-multivcpu pass test-amd64-amd64-pair pass test-amd64-i386-pair pass test-i386-i386-pair pass test-amd64-amd64-pv pass test-amd64-i386-pv pass test-i386-i386-pv pass test-amd64-amd64-xl-sedf fail test-amd64-i386-win-vcpus1 fail test-amd64-i386-xl-win-vcpus1 fail test-amd64-amd64-win fail test-amd64-i386-win fail test-i386-i386-win fail test-amd64-amd64-xl-win fail test-i386-i386-xl-win fail ------------------------------------------------------------ sg-report-flight on woking.cam.xci-test.com logs: /home/xc_osstest/logs images: /home/xc_osstest/images Logs, config files, etc. are available at http://www.chiark.greenend.org.uk/~xensrcts/logs Test harness code can be found at http://xenbits.xensource.com/gitweb?p=osstest.git;a=summary Not pushing. ------------------------------------------------------------ changeset: 23822:bdd19847ae63 tag: tip user: Olaf Hering date: Wed Sep 07 10:37:48 2011 +0100 p2m-ept: remove map_domain_page check map_domain_page() can not fail, remove ASSERT in ept_set_entry(). Signed-off-by: Olaf Hering changeset: 23821:88065fb8d0aa user: Jan Beulich date: Wed Sep 07 10:37:20 2011 +0100 x86: remove unnecessary indirection from irq_complete_move()'s sole parameter Signed-off-by: Jan Beulich changeset: 23820:ba75234a6f56 user: Jan Beulich date: Wed Sep 07 10:36:55 2011 +0100 bitmap_scnlistprintf() should always zero-terminate its output buffer ... as long as it has non-zero size. So far this would not happen if the passed in CPU mask was empty. Also fix the comment describing the return value to actually match reality. Signed-off-by: Jan Beulich changeset: 23819:5fe770c8a8a3 user: Keir Fraser date: Tue Sep 06 15:49:40 2011 +0100 docs: Fix 'make docs' Signed-off-by: Keir Fraser ======================================== commit cd776ee9408ff127f934a707c1a339ee600bc127 Author: Ian Jackson Date: Tue Jun 28 13:50:53 2011 +0100 qemu-char.c: fix incorrect CONFIG_STUBDOM handling qemu-char.c:1123:7: warning: "CONFIG_STUBDOM" is not defined [-Wundef] Signed-off-by: Olaf Hering Acked-by: Ian Jackson _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel From xen-devel-bounces@lists.xensource.com Wed Sep 07 16:56:54 2011 Return-path: Envelope-to: www-data@lists.xensource.com Delivery-date: Wed, 07 Sep 2011 16:56:54 -0700 Received: from localhost ([127.0.0.1] helo=lists.colo.xensource.com) by lists.xensource.com with esmtp (Exim 4.43) id 1R1RzC-0007Rh-58; Wed, 07 Sep 2011 16:56:54 -0700 Received: from mail21.messagelabs.com ([85.158.143.35]) by lists.xensource.com with esmtp (Exim 4.43) id 1R17IS-0002V4-8h for xen-devel@lists.xensource.com; Tue, 06 Sep 2011 18:51:24 -0700 X-Env-Sender: ben@decadent.org.uk X-Msg-Ref: server-15.tower-21.messagelabs.com!1315360281!49585906!1 X-Originating-IP: [88.96.1.126] X-StarScan-Version: 6.3.6; banners=-,-,- X-VirusChecked: Checked Received: (qmail 19202 invoked from network); 7 Sep 2011 01:51:22 -0000 Received: from shadbolt.e.decadent.org.uk (HELO shadbolt.e.decadent.org.uk) (88.96.1.126) by server-15.tower-21.messagelabs.com with AES256-SHA encrypted SMTP; 7 Sep 2011 01:51:22 -0000 Received: from [2001:470:1f08:1539:21c:bfff:fe03:f805] (helo=deadeye) by shadbolt.decadent.org.uk with esmtps (TLS1.0:RSA_AES_256_CBC_SHA1:32) (Exim 4.72) (envelope-from ) id 1R17IH-0001Bl-L2; Wed, 07 Sep 2011 02:51:13 +0100 Received: from ben by deadeye with local (Exim 4.76) (envelope-from ) id 1R17IE-0003jN-IA; Wed, 07 Sep 2011 02:51:10 +0100 Subject: Re: Bug#637234: [Xen-devel] Re: Bug#637234: linux-image-3.0.0-1-686-pae: I/O errors using ext4 under xen From: Ben Hutchings To: Konrad Rzeszutek Wilk , 637234@bugs.debian.org Date: Wed, 07 Sep 2011 02:51:04 +0100 In-Reply-To: <20110829140849.GA3897@dumpdata.com> References: <20110809180728.2279.11548.reportbug@mail1.gedalya.net> <1314254828.17978.720.camel@dagon.hellion.org.uk> <20110826175317.GA5043@dumpdata.com> <4E58251A.8090108@gedalya.net> <20110829140849.GA3897@dumpdata.com> X-Mailer: Evolution 3.0.2- Message-ID: <1315360270.3092.381.camel@deadeye> Mime-Version: 1.0 X-SA-Exim-Connect-IP: 2001:470:1f08:1539:21c:bfff:fe03:f805 X-SA-Exim-Mail-From: ben@decadent.org.uk X-SA-Exim-Scanned: No (on shadbolt.decadent.org.uk); SAEximRunCond expanded to false X-Mailman-Approved-At: Wed, 07 Sep 2011 16:54:30 -0700 Cc: Gedalya , xen-devel , Ian Campbell X-BeenThere: xen-devel@lists.xensource.com X-Mailman-Version: 2.1.5 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1152051550==" Sender: xen-devel-bounces@lists.xensource.com Errors-To: xen-devel-bounces@lists.xensource.com --===============1152051550== Content-Type: multipart/signed; micalg="pgp-sha512"; protocol="application/pgp-signature"; boundary="=-zXTQsl22Pex2afDMaPWD" --=-zXTQsl22Pex2afDMaPWD Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Mon, 2011-08-29 at 10:08 -0400, Konrad Rzeszutek Wilk wrote: [...] > Oh, I think I know _exactly_ what bug that is: >=20 > This git commit: > 280802657fb95c52bb5a35d43fea60351883b2af "xen/blkback: When writting barr= iers set the sector number to zero" > has to be reverted. Specifically: >=20 > commit 3f963cae3ef35d26fdd899c08797a598c5ca3e9b > Author: Jeremy Fitzhardinge > Date: Tue Jul 19 16:44:42 2011 -0700 >=20 > Revert "xen/blkback: When writting barriers set the sector number to = zero..." [...] > and this one added: >=20 > 25266338a41470a21e9b3974445be09e0640dda7 > xen/blkback: don't fail empty barrier requests [...] Which repository are these in? Ben. --=-zXTQsl22Pex2afDMaPWD Content-Type: application/pgp-signature; name="signature.asc" Content-Description: This is a digitally signed message part -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.11 (GNU/Linux) iQIVAwUATmbOCOe/yOyVhhEJAQqksw/+INR7Y83tkdKm5Bd14q2fkkoUbLFB5pds iOb0+VYt4lDl49iblP8QKFXM/5dQ26izd5Cl9NHSDdGooon7yqMFqNdtPlmhaeVL PHXWMSXqENJTjAtrPli97atcPRCj+gaj5BvqHwl6KLl/PZCFNd7bHB+7Vp1koFIW yiz6qWlLcz9OiTWVJbGkWen4bos8Ve60AJq9drx/fm1tAnasAF3/zfnwPbDYnXQ/ xsY8myllOMbBEc60mwio9A7ii2Io0N5GkoCn0qME+VxC71IoDQ29KUOHE7POutDp 73PMJg3Z1krYR00VDF+FxDLaTlMYyI5q3phVtgKGT1chUDEkjh9IlRsAjqtptSXt JO3IZAOgZomv77SOtamJSGYRt5nbKN27L4tWFTNdYdLeMvGSbi8p9JyUtZ+9cZa0 0UmW7zQvQkkSnfjPscC+GPH109sM33NtZDBrJR76fzZViHAdnMRw6f5TRVa+UtEX HY+jsKWMtFRuVO6XibRjw43uGN7vICtxQlh8QNVzwwAYwuPsuv7dkkpapQ3ZroWz DR/OnsUAipsy1TX/T3AU0D4/DwM3gqqc7kQQFPkRzxPEoL08KFPvHBXKafvLoWM/ H0lcnRzvfqJXFDmiLzo1hza0u1EwgyRYm3nbUon4dcxMOkzy1P/V5UDn4yb+zv4s XfYYEIPHqFc= =hhPh -----END PGP SIGNATURE----- --=-zXTQsl22Pex2afDMaPWD-- --===============1152051550== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel --===============1152051550==-- From xen-devel-bounces@lists.xensource.com Wed Sep 07 16:59:33 2011 Return-path: Envelope-to: www-data@lists.xensource.com Delivery-date: Wed, 07 Sep 2011 16:59:33 -0700 Received: from localhost ([127.0.0.1] helo=lists.colo.xensource.com) by lists.xensource.com with esmtp (Exim 4.43) id 1R1S1k-0007ry-MU; Wed, 07 Sep 2011 16:59:32 -0700 Received: from mail27.messagelabs.com ([193.109.254.147]) by lists.xensource.com with esmtp (Exim 4.43) id 1R1DIb-0006fK-MJ for xen-devel@lists.xensource.com; Wed, 07 Sep 2011 01:15:58 -0700 X-Env-Sender: yong.zhang0@gmail.com X-Msg-Ref: server-11.tower-27.messagelabs.com!1315383347!36364365!1 X-Originating-IP: [74.125.82.43] X-StarScan-Version: 6.3.6; banners=-,-,- X-VirusChecked: Checked Received: (qmail 13685 invoked from network); 7 Sep 2011 08:15:47 -0000 Received: from mail-ww0-f43.google.com (HELO mail-ww0-f43.google.com) (74.125.82.43) by server-11.tower-27.messagelabs.com with RC4-SHA encrypted SMTP; 7 Sep 2011 08:15:47 -0000 Received: by wwe32 with SMTP id 32so5844647wwe.24 for ; Wed, 07 Sep 2011 01:15:54 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=from:to:cc:subject:date:message-id:x-mailer:in-reply-to:references; bh=Y8zGl6D+ybWwMaFaOBCaeA3Fc8jpRm8tbWr3JGufQE0=; b=ZZ40JFMZd1vPdHI8mgN6PKixZW2cAim6GGI9WJ5BauvWy9H4sYmURvjDxNTBThoaj1 cXhIBPU9GVLobtM9kAgMXAJt+wNAjgAt3vAzSxh47L0DlZnRinuF4p74tmomX3MKOQRY x3YScI/PnNbhngdL4Y6U0xpl/HnfXdx6NqN90= Received: by 10.216.54.140 with SMTP id i12mr4718758wec.16.1315383354305; Wed, 07 Sep 2011 01:15:54 -0700 (PDT) Received: from localhost ([61.148.56.138]) by mx.google.com with ESMTPS id n12sm2825868wbp.7.2011.09.07.01.15.52 (version=TLSv1/SSLv3 cipher=OTHER); Wed, 07 Sep 2011 01:15:53 -0700 (PDT) From: Yong Zhang To: linux-kernel@vger.kernel.org Date: Wed, 7 Sep 2011 16:10:20 +0800 Message-Id: <1315383059-3673-24-git-send-email-yong.zhang0@gmail.com> X-Mailer: git-send-email 1.7.4.1 In-Reply-To: <1315383059-3673-1-git-send-email-yong.zhang0@gmail.com> References: <1315383059-3673-1-git-send-email-yong.zhang0@gmail.com> X-Mailman-Approved-At: Wed, 07 Sep 2011 16:54:31 -0700 Cc: Don Zickus , "Venkatesh Pallipadi \(Venki\)" , Andy Lutomirski , Jeremy Fitzhardinge , Konrad Rzeszutek Wilk , x86@kernel.org, virtualization@lists.linux-foundation.org, Yong Zhang , Ingo Molnar , "H. Peter Anvin" , xen-devel@lists.xensource.com, tglx@linutronix.de, mingo@elte.hu Subject: [Xen-devel] [PATCH 23/62] x86: irq: Remove IRQF_DISABLED X-BeenThere: xen-devel@lists.xensource.com X-Mailman-Version: 2.1.5 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xensource.com Errors-To: xen-devel-bounces@lists.xensource.com This flag is a NOOP and can be removed now. Signed-off-by: Yong Zhang --- arch/x86/include/asm/floppy.h | 4 ++-- arch/x86/kernel/hpet.c | 2 +- arch/x86/kernel/time.c | 2 +- arch/x86/xen/smp.c | 8 ++++---- arch/x86/xen/spinlock.c | 2 +- arch/x86/xen/time.c | 5 ++--- 6 files changed, 11 insertions(+), 12 deletions(-) diff --git a/arch/x86/include/asm/floppy.h b/arch/x86/include/asm/floppy.h index dbe82a5..22bf4d6 100644 --- a/arch/x86/include/asm/floppy.h +++ b/arch/x86/include/asm/floppy.h @@ -145,10 +145,10 @@ static int fd_request_irq(void) { if (can_use_virtual_dma) return request_irq(FLOPPY_IRQ, floppy_hardint, - IRQF_DISABLED, "floppy", NULL); + 0, "floppy", NULL); else return request_irq(FLOPPY_IRQ, floppy_interrupt, - IRQF_DISABLED, "floppy", NULL); + 0, "floppy", NULL); } static unsigned long dma_mem_alloc(unsigned long size) diff --git a/arch/x86/kernel/hpet.c b/arch/x86/kernel/hpet.c index 4aecc54..9d96096 100644 --- a/arch/x86/kernel/hpet.c +++ b/arch/x86/kernel/hpet.c @@ -515,7 +515,7 @@ static int hpet_setup_irq(struct hpet_dev *dev) { if (request_irq(dev->irq, hpet_interrupt_handler, - IRQF_TIMER | IRQF_DISABLED | IRQF_NOBALANCING, + IRQF_TIMER | IRQF_NOBALANCING, dev->name, dev)) return -1; diff --git a/arch/x86/kernel/time.c b/arch/x86/kernel/time.c index 5a64d05..e62386a 100644 --- a/arch/x86/kernel/time.c +++ b/arch/x86/kernel/time.c @@ -70,7 +70,7 @@ static irqreturn_t timer_interrupt(int irq, void *dev_id) static struct irqaction irq0 = { .handler = timer_interrupt, - .flags = IRQF_DISABLED | IRQF_NOBALANCING | IRQF_IRQPOLL | IRQF_TIMER, + .flags = IRQF_NOBALANCING | IRQF_IRQPOLL | IRQF_TIMER, .name = "timer" }; diff --git a/arch/x86/xen/smp.c b/arch/x86/xen/smp.c index e79dbb9..b20b94d 100644 --- a/arch/x86/xen/smp.c +++ b/arch/x86/xen/smp.c @@ -99,7 +99,7 @@ static int xen_smp_intr_init(unsigned int cpu) rc = bind_ipi_to_irqhandler(XEN_RESCHEDULE_VECTOR, cpu, xen_reschedule_interrupt, - IRQF_DISABLED|IRQF_PERCPU|IRQF_NOBALANCING, + IRQF_PERCPU|IRQF_NOBALANCING, resched_name, NULL); if (rc < 0) @@ -110,7 +110,7 @@ static int xen_smp_intr_init(unsigned int cpu) rc = bind_ipi_to_irqhandler(XEN_CALL_FUNCTION_VECTOR, cpu, xen_call_function_interrupt, - IRQF_DISABLED|IRQF_PERCPU|IRQF_NOBALANCING, + IRQF_PERCPU|IRQF_NOBALANCING, callfunc_name, NULL); if (rc < 0) @@ -119,7 +119,7 @@ static int xen_smp_intr_init(unsigned int cpu) debug_name = kasprintf(GFP_KERNEL, "debug%d", cpu); rc = bind_virq_to_irqhandler(VIRQ_DEBUG, cpu, xen_debug_interrupt, - IRQF_DISABLED | IRQF_PERCPU | IRQF_NOBALANCING, + IRQF_PERCPU | IRQF_NOBALANCING, debug_name, NULL); if (rc < 0) goto fail; @@ -129,7 +129,7 @@ static int xen_smp_intr_init(unsigned int cpu) rc = bind_ipi_to_irqhandler(XEN_CALL_FUNCTION_SINGLE_VECTOR, cpu, xen_call_function_single_interrupt, - IRQF_DISABLED|IRQF_PERCPU|IRQF_NOBALANCING, + IRQF_PERCPU|IRQF_NOBALANCING, callfunc_name, NULL); if (rc < 0) diff --git a/arch/x86/xen/spinlock.c b/arch/x86/xen/spinlock.c index cc9b1e1..27882f5 100644 --- a/arch/x86/xen/spinlock.c +++ b/arch/x86/xen/spinlock.c @@ -354,7 +354,7 @@ void __cpuinit xen_init_lock_cpu(int cpu) irq = bind_ipi_to_irqhandler(XEN_SPIN_UNLOCK_VECTOR, cpu, dummy_handler, - IRQF_DISABLED|IRQF_PERCPU|IRQF_NOBALANCING, + IRQF_PERCPU|IRQF_NOBALANCING, name, NULL); diff --git a/arch/x86/xen/time.c b/arch/x86/xen/time.c index 5158c50..f164ccc 100644 --- a/arch/x86/xen/time.c +++ b/arch/x86/xen/time.c @@ -393,9 +393,8 @@ void xen_setup_timer(int cpu) name = ""; irq = bind_virq_to_irqhandler(VIRQ_TIMER, cpu, xen_timer_interrupt, - IRQF_DISABLED|IRQF_PERCPU| - IRQF_NOBALANCING|IRQF_TIMER| - IRQF_FORCE_RESUME, + IRQF_PERCPU|IRQF_NOBALANCING| + IRQF_TIMER|IRQF_FORCE_RESUME, name, NULL); evt = &per_cpu(xen_clock_events, cpu); -- 1.7.4.1 _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel From xen-devel-bounces@lists.xensource.com Wed Sep 07 17:02:44 2011 Return-path: Envelope-to: www-data@lists.xensource.com Delivery-date: Wed, 07 Sep 2011 17:02:44 -0700 Received: from localhost ([127.0.0.1] helo=lists.colo.xensource.com) by lists.xensource.com with esmtp (Exim 4.43) id 1R1S4p-0008GT-Ou; Wed, 07 Sep 2011 17:02:43 -0700 Received: from mail27.messagelabs.com ([193.109.254.147]) by lists.xensource.com with esmtp (Exim 4.43) id 1R1DNM-0006kG-Ox for xen-devel@lists.xensource.com; Wed, 07 Sep 2011 01:20:53 -0700 X-Env-Sender: yong.zhang0@gmail.com X-Msg-Ref: server-10.tower-27.messagelabs.com!1315383631!34690680!1 X-Originating-IP: [74.125.82.171] X-StarScan-Version: 6.3.6; banners=-,-,- X-VirusChecked: Checked Received: (qmail 4020 invoked from network); 7 Sep 2011 08:20:31 -0000 Received: from mail-wy0-f171.google.com (HELO mail-wy0-f171.google.com) (74.125.82.171) by server-10.tower-27.messagelabs.com with RC4-SHA encrypted SMTP; 7 Sep 2011 08:20:31 -0000 Received: by wyh13 with SMTP id 13so6595903wyh.30 for ; Wed, 07 Sep 2011 01:20:49 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=from:to:cc:subject:date:message-id:x-mailer:in-reply-to:references; bh=Tm7g5Oj5zcRnPo9FwsGm5RhTCmJCMfde8OISAPPJuPo=; b=lt7sOuJ/Lv4WmvBp2HGRxa+7zBmBDUrXPlfFBrG6fzKUAZ2rm1XZhPkC4g0tKUG2za 3Q5WM5pDJem/HY0/a6FsBS+g7SP5ac1Duwtn57vM68hnKeMPb9ardTQ92Ww6YS8D+Dy1 7NKteigzPSS9LlvG+4WFNIszWNeuZifHOYU2c= Received: by 10.216.229.223 with SMTP id h73mr2109646weq.50.1315383649455; Wed, 07 Sep 2011 01:20:49 -0700 (PDT) Received: from localhost ([61.148.56.138]) by mx.google.com with ESMTPS id p19sm2820350wbm.16.2011.09.07.01.20.47 (version=TLSv1/SSLv3 cipher=OTHER); Wed, 07 Sep 2011 01:20:49 -0700 (PDT) From: Yong Zhang To: linux-kernel@vger.kernel.org Date: Wed, 7 Sep 2011 16:10:56 +0800 Message-Id: <1315383059-3673-60-git-send-email-yong.zhang0@gmail.com> X-Mailer: git-send-email 1.7.4.1 In-Reply-To: <1315383059-3673-1-git-send-email-yong.zhang0@gmail.com> References: <1315383059-3673-1-git-send-email-yong.zhang0@gmail.com> X-Mailman-Approved-At: Wed, 07 Sep 2011 16:54:31 -0700 Cc: xen-devel@lists.xensource.com, Konrad Rzeszutek Wilk , virtualization@lists.linux-foundation.org, Jeremy Fitzhardinge , tglx@linutronix.de, mingo@elte.hu Subject: [Xen-devel] [PATCH 59/62] xen: irq: Remove IRQF_DISABLED X-BeenThere: xen-devel@lists.xensource.com X-Mailman-Version: 2.1.5 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xensource.com Errors-To: xen-devel-bounces@lists.xensource.com This flag is a NOOP and can be removed now. Signed-off-by: Yong Zhang --- drivers/xen/evtchn.c | 2 +- drivers/xen/platform-pci.c | 2 +- 2 files changed, 2 insertions(+), 2 deletions(-) diff --git a/drivers/xen/evtchn.c b/drivers/xen/evtchn.c index dbc13e9..95e2507 100644 --- a/drivers/xen/evtchn.c +++ b/drivers/xen/evtchn.c @@ -265,7 +265,7 @@ static int evtchn_bind_to_user(struct per_user_data *u, int port) set_port_user(port, u); set_port_enabled(port, true); /* start enabled */ - rc = bind_evtchn_to_irqhandler(port, evtchn_interrupt, IRQF_DISABLED, + rc = bind_evtchn_to_irqhandler(port, evtchn_interrupt, 0, u->name, (void *)(unsigned long)port); if (rc >= 0) rc = 0; diff --git a/drivers/xen/platform-pci.c b/drivers/xen/platform-pci.c index 319dd0a..482beff 100644 --- a/drivers/xen/platform-pci.c +++ b/drivers/xen/platform-pci.c @@ -84,7 +84,7 @@ static irqreturn_t do_hvm_evtchn_intr(int irq, void *dev_id) static int xen_allocate_irq(struct pci_dev *pdev) { return request_irq(pdev->irq, do_hvm_evtchn_intr, - IRQF_DISABLED | IRQF_NOBALANCING | IRQF_TRIGGER_RISING, + IRQF_NOBALANCING | IRQF_TRIGGER_RISING, "xen-platform-pci", pdev); } -- 1.7.4.1 _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel From xen-devel-bounces@lists.xensource.com Wed Sep 07 17:06:15 2011 Return-path: Envelope-to: www-data@lists.xensource.com Delivery-date: Wed, 07 Sep 2011 17:06:15 -0700 Received: from localhost ([127.0.0.1] helo=lists.colo.xensource.com) by lists.xensource.com with esmtp (Exim 4.43) id 1R1S8D-0000EK-SE; Wed, 07 Sep 2011 17:06:13 -0700 Received: from mail27.messagelabs.com ([193.109.254.147]) by lists.xensource.com with esmtp (Exim 4.43) id 1R1EPy-0000Qo-KJ for xen-devel@lists.xensource.com; Wed, 07 Sep 2011 02:27:38 -0700 X-Env-Sender: 19890121wr@gmail.com X-Msg-Ref: server-13.tower-27.messagelabs.com!1315387643!38997723!1 X-Originating-IP: [209.85.218.43] X-StarScan-Version: 6.3.6; banners=-,-,- X-VirusChecked: Checked Received: (qmail 793 invoked from network); 7 Sep 2011 09:27:24 -0000 Received: from mail-yi0-f43.google.com (HELO mail-yi0-f43.google.com) (209.85.218.43) by server-13.tower-27.messagelabs.com with RC4-SHA encrypted SMTP; 7 Sep 2011 09:27:24 -0000 Received: by yia27 with SMTP id 27so7171617yia.30 for ; Wed, 07 Sep 2011 02:27:34 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:date:message-id:subject:from:to:content-type; bh=cWgXPWHnOGPtTWe2TDCWM9Kh6aFlXdt0gBkjLsZZTlY=; b=MRtdYXWIunsdIA8bNDvnXIwzQgsXqRpw69NqRbz490ZCwljsGmvcHYrLeeZzfTPoNR ZvdwsTEP0gPceAvT0So9isURcd29LKn+yexSDV331AdFE3MtCW4pOKrpOnBBJXRiHG3L mEZKtUE44L4shBBEnkDXtpKZdp/iYFnH/r3Hg= MIME-Version: 1.0 Received: by 10.68.17.193 with SMTP id q1mr1951652pbd.526.1315387638845; Wed, 07 Sep 2011 02:27:18 -0700 (PDT) Received: by 10.142.177.7 with HTTP; Wed, 7 Sep 2011 02:27:18 -0700 (PDT) Date: Wed, 7 Sep 2011 17:27:18 +0800 Message-ID: From: =?GB2312?B?zuLI8Q==?= <19890121wr@gmail.com> To: xen-devel@lists.xensource.com X-Mailman-Approved-At: Wed, 07 Sep 2011 16:54:31 -0700 Subject: [Xen-devel] can anyone shed some light on how Xen save domain X-BeenThere: xen-devel@lists.xensource.com X-Mailman-Version: 2.1.5 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1668188454==" Sender: xen-devel-bounces@lists.xensource.com Errors-To: xen-devel-bounces@lists.xensource.com --===============1668188454== Content-Type: multipart/alternative; boundary=bcaec520ea43f492a104ac568cb3 --bcaec520ea43f492a104ac568cb3 Content-Type: text/plain; charset=ISO-8859-1 Which function exactly called by Xen to save info of domain and vcpus? --bcaec520ea43f492a104ac568cb3 Content-Type: text/html; charset=ISO-8859-1 Which function exactly called by Xen to save info of domain and vcpus? --bcaec520ea43f492a104ac568cb3-- --===============1668188454== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel --===============1668188454==-- From xen-devel-bounces@lists.xensource.com Wed Sep 07 17:49:10 2011 Return-path: Envelope-to: www-data@lists.xensource.com Delivery-date: Wed, 07 Sep 2011 17:49:10 -0700 Received: from localhost ([127.0.0.1] helo=lists.colo.xensource.com) by lists.xensource.com with esmtp (Exim 4.43) id 1R1Snl-0002Ac-P8; Wed, 07 Sep 2011 17:49:09 -0700 Received: from mail21.messagelabs.com ([85.158.143.35]) by lists.xensource.com with esmtp (Exim 4.43) id 1R1Smo-0001y2-NI for xen-devel@lists.xensource.com; Wed, 07 Sep 2011 17:48:11 -0700 X-Env-Sender: eric.camachat@gmail.com X-Msg-Ref: server-11.tower-21.messagelabs.com!1315442870!41734175!1 X-Originating-IP: [209.85.161.181] X-StarScan-Version: 6.3.6; banners=-,-,- X-VirusChecked: Checked Received: (qmail 12363 invoked from network); 8 Sep 2011 00:47:51 -0000 Received: from mail-gx0-f181.google.com (HELO mail-gx0-f181.google.com) (209.85.161.181) by server-11.tower-21.messagelabs.com with RC4-SHA encrypted SMTP; 8 Sep 2011 00:47:51 -0000 Received: by gxk9 with SMTP id 9so614717gxk.12 for ; Wed, 07 Sep 2011 17:48:06 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:from:date:message-id:subject:to:content-type; bh=beYgI1bScPQwCiJolpj2dFbs701ZMNfwLoQg0V3eQwE=; b=C8C4ebvc+vPTi3CeHtxP6GqNMWDnJdDyXmKjGfzObwqu4gJCrhat0NPWJ4wd4YVoC1 OCXwWmS5wu8RnwDWga1vmVZ6hfSeXUtbhuQMZfQ4vjQcvICQ0yfrNMxgXN0oedre2E20 zjaZCIL6fKb/KpX9olfovmlqRdaOplY9R860U= Received: by 10.236.115.70 with SMTP id d46mr243432yhh.83.1315442886080; Wed, 07 Sep 2011 17:48:06 -0700 (PDT) MIME-Version: 1.0 Received: by 10.236.95.5 with HTTP; Wed, 7 Sep 2011 17:47:46 -0700 (PDT) From: Eric Camachat Date: Wed, 7 Sep 2011 17:47:46 -0700 Message-ID: To: xen-devel@lists.xensource.com Content-Type: text/plain; charset=UTF-8 Subject: [Xen-devel] Can I specify a physical memory region for a domU X-BeenThere: xen-devel@lists.xensource.com X-Mailman-Version: 2.1.5 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xensource.com Errors-To: xen-devel-bounces@lists.xensource.com Hi, I am porting our drivers to XEN's PV domU (with PV PCI passthrouth), I have to allocate a memory block and tell the hardware to access it. But the hardware can address 32-bit only, so I want dedicate a region of memory that below 2GB for the domU only. How do that in XEN? Thanks, /Eric _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel From xen-devel-bounces@lists.xensource.com Wed Sep 07 18:25:58 2011 Return-path: Envelope-to: www-data@lists.xensource.com Delivery-date: Wed, 07 Sep 2011 18:25:58 -0700 Received: from localhost ([127.0.0.1] helo=lists.colo.xensource.com) by lists.xensource.com with esmtp (Exim 4.43) id 1R1TNO-0003wN-65; Wed, 07 Sep 2011 18:25:58 -0700 Received: from mail182.messagelabs.com ([85.158.139.83]) by lists.xensource.com with esmtp (Exim 4.43) id 1R1TMb-0003kQ-QK for Xen-devel@lists.xensource.com; Wed, 07 Sep 2011 18:25:11 -0700 X-Env-Sender: mukesh.rathor@oracle.com X-Msg-Ref: server-4.tower-182.messagelabs.com!1315445105!17470503!1 X-Originating-IP: [148.87.113.117] X-StarScan-Version: 6.3.6; banners=-,-,- X-VirusChecked: Checked Received: (qmail 8486 invoked from network); 8 Sep 2011 01:25:06 -0000 Received: from rcsinet15.oracle.com (HELO rcsinet15.oracle.com) (148.87.113.117) by server-4.tower-182.messagelabs.com with DHE-RSA-AES256-SHA encrypted SMTP; 8 Sep 2011 01:25:06 -0000 Received: from rtcsinet22.oracle.com (rtcsinet22.oracle.com [66.248.204.30]) by rcsinet15.oracle.com (Switch-3.4.4/Switch-3.4.4) with ESMTP id p881P2CC010720 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Thu, 8 Sep 2011 01:25:04 GMT Received: from acsmt356.oracle.com (acsmt356.oracle.com [141.146.40.156]) by rtcsinet22.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id p881P0xm026690 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 8 Sep 2011 01:25:01 GMT Received: from abhmt109.oracle.com (abhmt109.oracle.com [141.146.116.61]) by acsmt356.oracle.com (8.12.11.20060308/8.12.11) with ESMTP id p881Ot4g030816; Wed, 7 Sep 2011 20:24:55 -0500 Received: from mantra.us.oracle.com (/130.35.68.95) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Wed, 07 Sep 2011 18:24:50 -0700 Date: Wed, 7 Sep 2011 18:24:48 -0700 From: Mukesh Rathor To: "Jan Beulich" Message-ID: <20110907182448.25b9eda8@mantra.us.oracle.com> In-Reply-To: <4E64DC220200007800054A9D@nat28.tlf.novell.com> References: <20110901122004.2c12f34f@mantra.us.oracle.com> <4E64DC220200007800054A9D@nat28.tlf.novell.com> Organization: Oracle Corporation X-Mailer: Claws Mail 3.7.6 (GTK+ 2.18.9; x86_64-redhat-linux-gnu) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-Source-IP: rtcsinet22.oracle.com [66.248.204.30] X-CT-RefId: str=0001.0A090203.4E681970.004D,ss=1,re=0.000,fgs=0 Cc: "Xen-devel@lists.xensource.com" Subject: [Xen-devel] Re: DOM0 Hang on a large box.... X-BeenThere: xen-devel@lists.xensource.com X-Mailman-Version: 2.1.5 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xensource.com Errors-To: xen-devel-bounces@lists.xensource.com On Mon, 05 Sep 2011 13:26:42 +0100 "Jan Beulich" wrote: > From the observation of most CPUs sitting in _double_lock_balance() > I would have answered yes, but the odd upcall mask I don't recall > having seen. In any case - is your Dom0 kernel (presumably derived > from ours) up-to-date? That problem I recall was fixed months ago. Yes, it's derived from yours, not quite upto date for various reasons I don't know about. If it's possible, please let me know patch c/s or id or something. I see tons there.... we must be far behind. thanks a lot, mukesh _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel From xen-devel-bounces@lists.xensource.com Wed Sep 07 18:32:00 2011 Return-path: Envelope-to: www-data@lists.xensource.com Delivery-date: Wed, 07 Sep 2011 18:32:00 -0700 Received: from localhost ([127.0.0.1] helo=lists.colo.xensource.com) by lists.xensource.com with esmtp (Exim 4.43) id 1R1TTD-0004T9-SN; Wed, 07 Sep 2011 18:31:59 -0700 Received: from mail216.messagelabs.com ([85.158.143.99]) by lists.xensource.com with smtp (Exim 4.43) id 1R1TSj-0004Gr-Mk for xen-devel@lists.xensource.com; Wed, 07 Sep 2011 18:31:30 -0700 X-Env-Sender: Ian.Jackson@eu.citrix.com X-Msg-Ref: server-14.tower-216.messagelabs.com!1315445486!17460407!1 X-Originating-IP: [62.200.22.115] X-StarScan-Version: 6.3.6; banners=-,-,- X-VirusChecked: Checked Received: (qmail 31327 invoked from network); 8 Sep 2011 01:31:26 -0000 Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115) by server-14.tower-216.messagelabs.com with SMTP; 8 Sep 2011 01:31:26 -0000 X-IronPort-AV: E=Sophos;i="4.68,348,1312156800"; d="scan'208";a="7663760" Received: from lonpmailmx01.citrite.net ([10.30.203.162]) by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5; 08 Sep 2011 01:31:26 +0000 Received: from woking.xci-test.com (10.80.248.135) by smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id 8.3.137.0; Thu, 8 Sep 2011 02:31:26 +0100 Received: from osstest by woking.xci-test.com with local (Exim 4.69) (envelope-from ) id 1R1TSf-0002h1-Rg; Thu, 08 Sep 2011 02:31:26 +0100 To: xen-devel@lists.xensource.com Message-ID: From: xen.org Date: Thu, 8 Sep 2011 02:31:25 +0100 MIME-Version: 1.0 Content-Type: text/plain Cc: ian.jackson@eu.citrix.com Subject: [Xen-devel] [xen-4.0-testing test] 8855: tolerable FAIL - PUSHED X-BeenThere: xen-devel@lists.xensource.com X-Mailman-Version: 2.1.5 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xensource.com Errors-To: xen-devel-bounces@lists.xensource.com flight 8855 xen-4.0-testing real [real] http://www.chiark.greenend.org.uk/~xensrcts/logs/8855/ Failures :-/ but no regressions. Tests which are failing intermittently (not blocking): test-amd64-i386-xl-credit2 14 guest-localmigrate/x10 fail pass in 8852 test-amd64-i386-xl-win-vcpus1 5 xen-boot fail in 8852 pass in 8855 Tests which did not succeed, but are not blocking, including regressions (tests previously passed) regarded as allowable: test-amd64-amd64-xl-pcipt-intel 8 debian-fixup fail never pass test-i386-i386-xl 15 guest-stop fail never pass test-amd64-i386-xl-multivcpu 15 guest-stop fail never pass test-amd64-amd64-xl 15 guest-stop fail never pass test-amd64-i386-xl 15 guest-stop fail never pass test-amd64-amd64-xl-sedf 5 xen-boot fail like 8788 test-amd64-i386-rhel6hvm-intel 7 redhat-install fail never pass test-amd64-i386-rhel6hvm-amd 7 redhat-install fail never pass test-amd64-i386-win-vcpus1 16 leak-check/check fail never pass test-amd64-i386-win 16 leak-check/check fail never pass test-amd64-amd64-win 16 leak-check/check fail never pass test-i386-i386-win 16 leak-check/check fail never pass test-amd64-amd64-xl-win 7 windows-install fail never pass test-amd64-i386-xl-win-vcpus1 7 windows-install fail never pass test-i386-i386-xl-win 7 windows-install fail never pass test-amd64-i386-xl-credit2 15 guest-stop fail in 8852 never pass version targeted for testing: xen b44346a6975c baseline version: xen 0383662ea34c ------------------------------------------------------------ People who touched revisions under test: Andrew Cooper ------------------------------------------------------------ jobs: build-amd64 pass build-i386 pass build-amd64-oldkern pass build-i386-oldkern pass build-amd64-pvops pass build-i386-pvops pass test-amd64-amd64-xl fail test-amd64-i386-xl fail test-i386-i386-xl fail test-amd64-i386-rhel6hvm-amd fail test-amd64-i386-xl-credit2 fail test-amd64-amd64-xl-pcipt-intel fail test-amd64-i386-rhel6hvm-intel fail test-amd64-i386-xl-multivcpu fail test-amd64-amd64-pair pass test-amd64-i386-pair pass test-i386-i386-pair pass test-amd64-amd64-pv pass test-amd64-i386-pv pass test-i386-i386-pv pass test-amd64-amd64-xl-sedf fail test-amd64-i386-win-vcpus1 fail test-amd64-i386-xl-win-vcpus1 fail test-amd64-amd64-win fail test-amd64-i386-win fail test-i386-i386-win fail test-amd64-amd64-xl-win fail test-i386-i386-xl-win fail ------------------------------------------------------------ sg-report-flight on woking.cam.xci-test.com logs: /home/xc_osstest/logs images: /home/xc_osstest/images Logs, config files, etc. are available at http://www.chiark.greenend.org.uk/~xensrcts/logs Test harness code can be found at http://xenbits.xensource.com/gitweb?p=osstest.git;a=summary Pushing revision : + branch=xen-4.0-testing + revision=b44346a6975c + . cri-lock-repos ++ . cri-common +++ umask 002 +++ getconfig Repos +++ perl -e ' use Osstest; readconfigonly(); print $c{Repos} or die $!; ' ++ repos=/export/home/osstest/repos ++ repos_lock=/export/home/osstest/repos/lock ++ '[' x '!=' x/export/home/osstest/repos/lock ']' ++ OSSTEST_REPOS_LOCK_LOCKED=/export/home/osstest/repos/lock ++ exec with-lock-ex -w /export/home/osstest/repos/lock ./ap-push xen-4.0-testing b44346a6975c + branch=xen-4.0-testing + revision=b44346a6975c + . cri-lock-repos ++ . cri-common +++ umask 002 +++ getconfig Repos +++ perl -e ' use Osstest; readconfigonly(); print $c{Repos} or die $!; ' ++ repos=/export/home/osstest/repos ++ repos_lock=/export/home/osstest/repos/lock ++ '[' x/export/home/osstest/repos/lock '!=' x/export/home/osstest/repos/lock ']' + : xen@xenbits.xensource.com + : xen@xenbits.xensource.com:git/linux-pvops + : master + : tested/2.6.39.x + case "$branch" in + cd /export/home/osstest/repos/xen-4.0-testing.hg + hg push -r b44346a6975c ssh://xen@xenbits.xensource.com/HG/xen-4.0-testing.hg pushing to ssh://xen@xenbits.xensource.com/HG/xen-4.0-testing.hg searching for changes remote: adding changesets remote: adding manifests remote: adding file changes remote: added 3 changesets with 3 changes to 3 files _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel From xen-devel-bounces@lists.xensource.com Wed Sep 07 18:33:41 2011 Return-path: Envelope-to: www-data@lists.xensource.com Delivery-date: Wed, 07 Sep 2011 18:33:41 -0700 Received: from localhost ([127.0.0.1] helo=lists.colo.xensource.com) by lists.xensource.com with esmtp (Exim 4.43) id 1R1TUq-0004rT-Tc; Wed, 07 Sep 2011 18:33:40 -0700 Received: from mail174.messagelabs.com ([85.158.138.51]) by lists.xensource.com with smtp (Exim 4.43) id 1R1TUN-0004ew-Kh for xen-devel@lists.xensource.com; Wed, 07 Sep 2011 18:33:12 -0700 X-Env-Sender: Ian.Jackson@eu.citrix.com X-Msg-Ref: server-4.tower-174.messagelabs.com!1315445588!30637881!1 X-Originating-IP: [62.200.22.115] X-StarScan-Version: 6.3.6; banners=-,-,- X-VirusChecked: Checked Received: (qmail 14711 invoked from network); 8 Sep 2011 01:33:08 -0000 Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115) by server-4.tower-174.messagelabs.com with SMTP; 8 Sep 2011 01:33:08 -0000 X-IronPort-AV: E=Sophos;i="4.68,348,1312156800"; d="scan'208";a="7663781" Received: from lonpmailmx01.citrite.net ([10.30.203.162]) by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5; 08 Sep 2011 01:33:08 +0000 Received: from woking.xci-test.com (10.80.248.135) by smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id 8.3.137.0; Thu, 8 Sep 2011 02:33:08 +0100 Received: from osstest by woking.xci-test.com with local (Exim 4.69) (envelope-from ) id 1R1TUK-0002lf-1D; Thu, 08 Sep 2011 02:33:08 +0100 To: Message-ID: From: xen.org Date: Thu, 8 Sep 2011 02:33:08 +0100 MIME-Version: 1.0 Content-Type: text/plain Cc: ian.jackson@eu.citrix.com Subject: [Xen-devel] [xen-unstable test] 8857: regressions - FAIL X-BeenThere: xen-devel@lists.xensource.com X-Mailman-Version: 2.1.5 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xensource.com Errors-To: xen-devel-bounces@lists.xensource.com flight 8857 xen-unstable real [real] http://www.chiark.greenend.org.uk/~xensrcts/logs/8857/ Regressions :-( Tests which did not succeed and are blocking: test-amd64-amd64-xl-sedf 14 guest-localmigrate/x10 fail REGR. vs. 8832 Tests which did not succeed, but are not blocking, including regressions (tests previously passed) regarded as allowable: test-amd64-amd64-xl-pcipt-intel 9 guest-start fail never pass test-amd64-i386-rhel6hvm-amd 9 guest-start.2 fail never pass test-amd64-i386-rhel6hvm-intel 9 guest-start.2 fail never pass test-amd64-i386-win-vcpus1 16 leak-check/check fail never pass test-amd64-i386-xl-win-vcpus1 13 guest-stop fail never pass test-amd64-amd64-win 16 leak-check/check fail never pass test-amd64-i386-win 16 leak-check/check fail never pass test-amd64-amd64-xl-win 13 guest-stop fail never pass test-i386-i386-xl-win 13 guest-stop fail never pass test-i386-i386-win 16 leak-check/check fail never pass version targeted for testing: xen bdd19847ae63 baseline version: xen 5fe770c8a8a3 ------------------------------------------------------------ People who touched revisions under test: Ian Jackson Jan Beulich Keir Fraser Olaf Hering ------------------------------------------------------------ jobs: build-amd64 pass build-i386 pass build-amd64-oldkern pass build-i386-oldkern pass build-amd64-pvops pass build-i386-pvops pass test-amd64-amd64-xl pass test-amd64-i386-xl pass test-i386-i386-xl pass test-amd64-i386-rhel6hvm-amd fail test-amd64-i386-xl-credit2 pass test-amd64-amd64-xl-pcipt-intel fail test-amd64-i386-rhel6hvm-intel fail test-amd64-i386-xl-multivcpu pass test-amd64-amd64-pair pass test-amd64-i386-pair pass test-i386-i386-pair pass test-amd64-amd64-pv pass test-amd64-i386-pv pass test-i386-i386-pv pass test-amd64-amd64-xl-sedf fail test-amd64-i386-win-vcpus1 fail test-amd64-i386-xl-win-vcpus1 fail test-amd64-amd64-win fail test-amd64-i386-win fail test-i386-i386-win fail test-amd64-amd64-xl-win fail test-i386-i386-xl-win fail ------------------------------------------------------------ sg-report-flight on woking.cam.xci-test.com logs: /home/xc_osstest/logs images: /home/xc_osstest/images Logs, config files, etc. are available at http://www.chiark.greenend.org.uk/~xensrcts/logs Test harness code can be found at http://xenbits.xensource.com/gitweb?p=osstest.git;a=summary Not pushing. ------------------------------------------------------------ changeset: 23822:bdd19847ae63 tag: tip user: Olaf Hering date: Wed Sep 07 10:37:48 2011 +0100 p2m-ept: remove map_domain_page check map_domain_page() can not fail, remove ASSERT in ept_set_entry(). Signed-off-by: Olaf Hering changeset: 23821:88065fb8d0aa user: Jan Beulich date: Wed Sep 07 10:37:20 2011 +0100 x86: remove unnecessary indirection from irq_complete_move()'s sole parameter Signed-off-by: Jan Beulich changeset: 23820:ba75234a6f56 user: Jan Beulich date: Wed Sep 07 10:36:55 2011 +0100 bitmap_scnlistprintf() should always zero-terminate its output buffer ... as long as it has non-zero size. So far this would not happen if the passed in CPU mask was empty. Also fix the comment describing the return value to actually match reality. Signed-off-by: Jan Beulich changeset: 23819:5fe770c8a8a3 user: Keir Fraser date: Tue Sep 06 15:49:40 2011 +0100 docs: Fix 'make docs' Signed-off-by: Keir Fraser ======================================== commit cd776ee9408ff127f934a707c1a339ee600bc127 Author: Ian Jackson Date: Tue Jun 28 13:50:53 2011 +0100 qemu-char.c: fix incorrect CONFIG_STUBDOM handling qemu-char.c:1123:7: warning: "CONFIG_STUBDOM" is not defined [-Wundef] Signed-off-by: Olaf Hering Acked-by: Ian Jackson _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel From xen-devel-bounces@lists.xensource.com Wed Sep 07 21:29:04 2011 Return-path: Envelope-to: www-data@lists.xensource.com Delivery-date: Wed, 07 Sep 2011 21:29:04 -0700 Received: from localhost ([127.0.0.1] helo=lists.colo.xensource.com) by lists.xensource.com with esmtp (Exim 4.43) id 1R1WEa-0008J2-0g; Wed, 07 Sep 2011 21:29:04 -0700 Received: from mail216.messagelabs.com ([85.158.143.99]) by lists.xensource.com with smtp (Exim 4.43) id 1R1WDc-00086e-4b for xen-devel@lists.xensource.com; Wed, 07 Sep 2011 21:28:07 -0700 X-Env-Sender: Ian.Jackson@eu.citrix.com X-Msg-Ref: server-8.tower-216.messagelabs.com!1315456079!15974437!1 X-Originating-IP: [62.200.22.115] X-StarScan-Version: 6.3.6; banners=-,-,- X-VirusChecked: Checked Received: (qmail 22227 invoked from network); 8 Sep 2011 04:27:59 -0000 Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115) by server-8.tower-216.messagelabs.com with SMTP; 8 Sep 2011 04:27:59 -0000 X-IronPort-AV: E=Sophos;i="4.68,348,1312156800"; d="scan'208";a="7664479" Received: from lonpmailmx01.citrite.net ([10.30.203.162]) by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5; 08 Sep 2011 04:27:59 +0000 Received: from woking.xci-test.com (10.80.248.135) by smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id 8.3.137.0; Thu, 8 Sep 2011 05:27:58 +0100 Received: from osstest by woking.xci-test.com with local (Exim 4.69) (envelope-from ) id 1R1WDW-0006BP-Q0; Thu, 08 Sep 2011 05:27:58 +0100 To: Message-ID: From: xen.org Date: Thu, 8 Sep 2011 05:27:58 +0100 MIME-Version: 1.0 Content-Type: text/plain Cc: ian.jackson@eu.citrix.com Subject: [Xen-devel] [xen-unstable test] 8859: regressions - FAIL X-BeenThere: xen-devel@lists.xensource.com X-Mailman-Version: 2.1.5 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xensource.com Errors-To: xen-devel-bounces@lists.xensource.com flight 8859 xen-unstable real [real] http://www.chiark.greenend.org.uk/~xensrcts/logs/8859/ Regressions :-( Tests which did not succeed and are blocking: test-amd64-amd64-xl-sedf 14 guest-localmigrate/x10 fail REGR. vs. 8832 Tests which did not succeed, but are not blocking, including regressions (tests previously passed) regarded as allowable: test-amd64-amd64-xl-pcipt-intel 9 guest-start fail never pass test-amd64-i386-rhel6hvm-intel 9 guest-start.2 fail never pass test-amd64-i386-rhel6hvm-amd 9 guest-start.2 fail never pass test-amd64-i386-win-vcpus1 16 leak-check/check fail never pass test-amd64-i386-xl-win-vcpus1 13 guest-stop fail never pass test-amd64-amd64-win 16 leak-check/check fail never pass test-amd64-i386-win 16 leak-check/check fail never pass test-amd64-amd64-xl-win 13 guest-stop fail never pass test-i386-i386-xl-win 13 guest-stop fail never pass test-i386-i386-win 16 leak-check/check fail never pass version targeted for testing: xen bdd19847ae63 baseline version: xen 5fe770c8a8a3 ------------------------------------------------------------ People who touched revisions under test: Ian Jackson Jan Beulich Keir Fraser Olaf Hering ------------------------------------------------------------ jobs: build-amd64 pass build-i386 pass build-amd64-oldkern pass build-i386-oldkern pass build-amd64-pvops pass build-i386-pvops pass test-amd64-amd64-xl pass test-amd64-i386-xl pass test-i386-i386-xl pass test-amd64-i386-rhel6hvm-amd fail test-amd64-i386-xl-credit2 pass test-amd64-amd64-xl-pcipt-intel fail test-amd64-i386-rhel6hvm-intel fail test-amd64-i386-xl-multivcpu pass test-amd64-amd64-pair pass test-amd64-i386-pair pass test-i386-i386-pair pass test-amd64-amd64-pv pass test-amd64-i386-pv pass test-i386-i386-pv pass test-amd64-amd64-xl-sedf fail test-amd64-i386-win-vcpus1 fail test-amd64-i386-xl-win-vcpus1 fail test-amd64-amd64-win fail test-amd64-i386-win fail test-i386-i386-win fail test-amd64-amd64-xl-win fail test-i386-i386-xl-win fail ------------------------------------------------------------ sg-report-flight on woking.cam.xci-test.com logs: /home/xc_osstest/logs images: /home/xc_osstest/images Logs, config files, etc. are available at http://www.chiark.greenend.org.uk/~xensrcts/logs Test harness code can be found at http://xenbits.xensource.com/gitweb?p=osstest.git;a=summary Not pushing. ------------------------------------------------------------ changeset: 23822:bdd19847ae63 tag: tip user: Olaf Hering date: Wed Sep 07 10:37:48 2011 +0100 p2m-ept: remove map_domain_page check map_domain_page() can not fail, remove ASSERT in ept_set_entry(). Signed-off-by: Olaf Hering changeset: 23821:88065fb8d0aa user: Jan Beulich date: Wed Sep 07 10:37:20 2011 +0100 x86: remove unnecessary indirection from irq_complete_move()'s sole parameter Signed-off-by: Jan Beulich changeset: 23820:ba75234a6f56 user: Jan Beulich date: Wed Sep 07 10:36:55 2011 +0100 bitmap_scnlistprintf() should always zero-terminate its output buffer ... as long as it has non-zero size. So far this would not happen if the passed in CPU mask was empty. Also fix the comment describing the return value to actually match reality. Signed-off-by: Jan Beulich changeset: 23819:5fe770c8a8a3 user: Keir Fraser date: Tue Sep 06 15:49:40 2011 +0100 docs: Fix 'make docs' Signed-off-by: Keir Fraser ======================================== commit cd776ee9408ff127f934a707c1a339ee600bc127 Author: Ian Jackson Date: Tue Jun 28 13:50:53 2011 +0100 qemu-char.c: fix incorrect CONFIG_STUBDOM handling qemu-char.c:1123:7: warning: "CONFIG_STUBDOM" is not defined [-Wundef] Signed-off-by: Olaf Hering Acked-by: Ian Jackson _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel From xen-devel-bounces@lists.xensource.com Wed Sep 07 23:11:25 2011 Return-path: Envelope-to: www-data@lists.xensource.com Delivery-date: Wed, 07 Sep 2011 23:11:25 -0700 Received: from localhost ([127.0.0.1] helo=lists.colo.xensource.com) by lists.xensource.com with esmtp (Exim 4.43) id 1R1Xpc-0002hC-Rd; Wed, 07 Sep 2011 23:11:24 -0700 Received: from mail182.messagelabs.com ([85.158.139.83]) by lists.xensource.com with smtp (Exim 4.43) id 1R1XoT-0002UG-Rz for xen-devel@lists.xensource.com; Wed, 07 Sep 2011 23:10:14 -0700 X-Env-Sender: yang.z.zhang@intel.com X-Msg-Ref: server-8.tower-182.messagelabs.com!1315462210!17490896!1 X-Originating-IP: [192.55.52.93] X-StarScan-Version: 6.3.6; banners=-,-,- X-VirusChecked: Checked Received: (qmail 14792 invoked from network); 8 Sep 2011 06:10:10 -0000 Received: from mga11.intel.com (HELO mga11.intel.com) (192.55.52.93) by server-8.tower-182.messagelabs.com with SMTP; 8 Sep 2011 06:10:10 -0000 Received: from fmsmga001.fm.intel.com ([10.253.24.23]) by fmsmga102.fm.intel.com with ESMTP; 07 Sep 2011 23:10:02 -0700 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="4.68,349,1312182000"; d="scan'208";a="49165551" Received: from pgsmsx602.gar.corp.intel.com ([10.221.43.81]) by fmsmga001.fm.intel.com with ESMTP; 07 Sep 2011 23:10:01 -0700 Received: from pgsmsx509.gar.corp.intel.com (172.30.13.17) by pgsmsx602.gar.corp.intel.com (10.221.43.81) with Microsoft SMTP Server (TLS) id 8.2.255.0; Thu, 8 Sep 2011 14:09:35 +0800 Received: from shsmsx601.ccr.corp.intel.com (10.239.4.112) by PGSMSX509.gar.corp.intel.com (172.30.13.17) with Microsoft SMTP Server (TLS) id 8.2.255.0; Thu, 8 Sep 2011 14:09:35 +0800 Received: from shsmsx501.ccr.corp.intel.com ([10.239.4.141]) by shsmsx601.ccr.corp.intel.com ([10.239.4.112]) with mapi; Thu, 8 Sep 2011 14:09:34 +0800 From: "Zhang, Yang Z" To: "xen-devel@lists.xensource.com" Date: Thu, 8 Sep 2011 14:09:31 +0800 Thread-Topic: [PATCH]Make sure processor_pminfo initialized before use it Thread-Index: Acxt7d9Yhjx7d4VVRwqjgdG2VuXt/Q== Message-ID: <749B9D3DBF0F054390025D9EAFF47F2212D149D959@shsmsx501.ccr.corp.intel.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "'Keir Fraser \(keir.xen@gmail.com\)'" Subject: [Xen-devel] [PATCH]Make sure processor_pminfo initialized before use it X-BeenThere: xen-devel@lists.xensource.com X-Mailman-Version: 2.1.5 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xensource.com Errors-To: xen-devel-bounces@lists.xensource.com Make sure processor_pminfo not null before use it If processor_pminfo not initialized, it will cause xen panic. Signed-off-by: Yang Zhang diff -r bdd19847ae63 xen/drivers/cpufreq/cpufreq.c --- a/xen/drivers/cpufreq/cpufreq.c Wed Sep 07 10:37:48 2011 +0100 +++ b/xen/drivers/cpufreq/cpufreq.c Thu Sep 08 13:40:23 2011 +0800 @@ -91,7 +91,7 @@ int __init cpufreq_register_governor(str int cpufreq_limit_change(unsigned int cpu) { - struct processor_performance *perf =3D &processor_pminfo[cpu]->perf; + struct processor_performance *perf; struct cpufreq_policy *data; struct cpufreq_policy policy; @@ -99,6 +99,7 @@ int cpufreq_limit_change(unsigned int cp !processor_pminfo[cpu]) return -ENODEV; + perf =3D &processor_pminfo[cpu]->perf; if (perf->platform_limit >=3D perf->state_count) return -EINVAL; @@ -120,12 +121,14 @@ int cpufreq_add_cpu(unsigned int cpu) struct cpufreq_dom *cpufreq_dom =3D NULL; struct cpufreq_policy new_policy; struct cpufreq_policy *policy; - struct processor_performance *perf =3D &processor_pminfo[cpu]->perf; + struct processor_performance *perf; /* to protect the case when Px was not controlled by xen */ - if (!processor_pminfo[cpu] || - !(perf->init & XEN_PX_INIT) || - !cpu_online(cpu)) + if (!processor_pminfo[cpu] || !cpu_online(cpu)) + return -EINVAL; + + perf =3D &processor_pminfo[cpu]->perf; + if (!(perf->init & XEN_PX_INIT)) return -EINVAL; if (!cpufreq_driver) @@ -261,12 +264,14 @@ int cpufreq_del_cpu(unsigned int cpu) struct list_head *pos; struct cpufreq_dom *cpufreq_dom =3D NULL; struct cpufreq_policy *policy; - struct processor_performance *perf =3D &processor_pminfo[cpu]->perf; + struct processor_performance *perf; /* to protect the case when Px was not controlled by xen */ - if (!processor_pminfo[cpu] || - !(perf->init & XEN_PX_INIT) || - !cpu_online(cpu)) + if (!processor_pminfo[cpu] || !cpu_online(cpu)) + return -EINVAL; + + perf =3D &processor_pminfo[cpu]->perf; + if (!(perf->init & XEN_PX_INIT)) return -EINVAL; if (!per_cpu(cpufreq_cpu_policy, cpu)) _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel From xen-devel-bounces@lists.xensource.com Thu Sep 08 00:40:33 2011 Return-path: Envelope-to: www-data@lists.xensource.com Delivery-date: Thu, 08 Sep 2011 00:40:33 -0700 Received: from localhost ([127.0.0.1] helo=lists.colo.xensource.com) by lists.xensource.com with esmtp (Exim 4.43) id 1R1ZDs-0004Xu-Ob; Thu, 08 Sep 2011 00:40:32 -0700 Received: from mail174.messagelabs.com ([85.158.138.51]) by lists.xensource.com with esmtp (Exim 4.43) id 1R1ZCy-0004LQ-BQ for xen-devel@lists.xensource.com; Thu, 08 Sep 2011 00:39:36 -0700 X-Env-Sender: JBeulich@suse.com X-Msg-Ref: server-7.tower-174.messagelabs.com!1315467572!30630099!1 X-Originating-IP: [130.57.49.28] X-StarScan-Version: 6.3.6; banners=-,-,- X-VirusChecked: Checked Received: (qmail 12862 invoked from network); 8 Sep 2011 07:39:33 -0000 Received: from nat28.tlf.novell.com (HELO nat28.tlf.novell.com) (130.57.49.28) by server-7.tower-174.messagelabs.com with DHE-RSA-AES256-SHA encrypted SMTP; 8 Sep 2011 07:39:33 -0000 Received: from EMEA1-MTA by nat28.tlf.novell.com with Novell_GroupWise; Thu, 08 Sep 2011 08:39:31 +0100 Message-Id: <4E688D68020000780005534E@nat28.tlf.novell.com> X-Mailer: Novell GroupWise Internet Agent 8.0.1 Date: Thu, 08 Sep 2011 08:39:52 +0100 From: "Jan Beulich" To: "Andrew Cooper" , "Keir Fraser" Subject: Re: [Xen-devel] [PATCH] IRQ: Group IRQ_MOVE_CLEANUP_VECTOR with other hypervisor IPIs References: <4E67B1DB020000780005517A@nat28.tlf.novell.com> In-Reply-To: Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: quoted-printable Content-Disposition: inline Cc: xen-devel@lists.xensource.com, xiantao.zhang@intel.com X-BeenThere: xen-devel@lists.xensource.com X-Mailman-Version: 2.1.5 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xensource.com Errors-To: xen-devel-bounces@lists.xensource.com >>> On 07.09.11 at 18:56, Keir Fraser wrote: > On 07/09/2011 17:03, "Jan Beulich" wrote: >=20 >>>>> On 07.09.11 at 17:03, Andrew Cooper = wrote: >>=20 >> Are you sure this is correct? I'm suspicious that this may intentionally= >> have been the lowest priority vector... >=20 > I can't see why? Perhaps to get all "real" interrupts serviced first, and then do a single, consolidated run through everything that needs cleaning up? All the more since smp_irq_move_cleanup_interrupt() may re-issue the interrupt to the local CPU. Cc-ing the original author in the hope that he's still at Intel. And btw., if that change is correct, then the setting of bit IRQ_MOVE_CLEANUP_VECTOR in used_vectors should actually be removed - while used_vectors currently is dimensioned as NR_VECTORS, none of the other "special" vectors get their bits set there, and the bit array could therefore easily be shrunk to just NR_DYNAMIC_VECTORS. Jan >>> Also, rename to MOVE_CLEANUP_VECTOR to be in line with the other IPI >>> names. >>=20 >> Why would the removal of part of the descriptive name be in line with >> the other names? We're dealing with the cleanup after an IRQ move >> here, so let the name state this. The IRQ_ prefix here has nothing to >> do with this being the vector for a specific IRQ. >=20 > Agreed. >=20 > -- Keir >=20 >> Jan >>=20 >>> This requires bumping LAST_HIPRIORITY_VECTOR, but does mean that the >>> range FIRST-LAST_HIPRIORITY_VECTORs are free once again. >>>=20 >>> Signed-off-by: Andrew Cooper >>>=20 >>> diff -r 0268e7380953 -r c7884dbb6f7d xen/arch/x86/apic.c >>> --- a/xen/arch/x86/apic.c Mon Sep 05 15:10:28 2011 +0100 >>> +++ b/xen/arch/x86/apic.c Wed Sep 07 16:00:55 2011 +0100 >>> @@ -90,7 +90,7 @@ bool_t __read_mostly directed_eoi_enable >>> * through the ICC by us (IPIs) >>> */ >>> __asm__(".section .text"); >>> -BUILD_SMP_INTERRUPT(irq_move_cleanup_interrupt,IRQ_MOVE_CLEANUP_VECTOR= ) >>> +BUILD_SMP_INTERRUPT(irq_move_cleanup_interrupt,MOVE_CLEANUP_VECTOR) >>> BUILD_SMP_INTERRUPT(event_check_interrupt,EVENT_CHECK_VECTOR) >>> BUILD_SMP_INTERRUPT(invalidate_interrupt,INVALIDATE_TLB_VECTOR) >>> BUILD_SMP_INTERRUPT(call_function_interrupt,CALL_FUNCTION_VECTOR) >>> diff -r 0268e7380953 -r c7884dbb6f7d xen/arch/x86/hvm/vmx/vmx.c >>> --- a/xen/arch/x86/hvm/vmx/vmx.c Mon Sep 05 15:10:28 2011 +0100 >>> +++ b/xen/arch/x86/hvm/vmx/vmx.c Wed Sep 07 16:00:55 2011 +0100 >>> @@ -1986,7 +1986,7 @@ static void vmx_do_extint(struct cpu_use >>> =20 >>> switch ( vector ) >>> { >>> - case IRQ_MOVE_CLEANUP_VECTOR: >>> + case MOVE_CLEANUP_VECTOR: >>> smp_irq_move_cleanup_interrupt(regs); >>> break; >>> case LOCAL_TIMER_VECTOR: >>> diff -r 0268e7380953 -r c7884dbb6f7d xen/arch/x86/io_apic.c >>> --- a/xen/arch/x86/io_apic.c Mon Sep 05 15:10:28 2011 +0100 >>> +++ b/xen/arch/x86/io_apic.c Wed Sep 07 16:00:55 2011 +0100 >>> @@ -476,7 +476,7 @@ fastcall void smp_irq_move_cleanup_inter >>> * to myself. >>> */ >>> if (irr & (1 << (vector % 32))) { >>> - genapic->send_IPI_self(IRQ_MOVE_CLEANUP_VECTOR); >>> + genapic->send_IPI_self(MOVE_CLEANUP_VECTOR); >>> TRACE_3D(TRC_HW_IRQ_MOVE_CLEANUP_DELAY, >>> irq, vector, smp_processor_id()); >>> goto unlock; >>> @@ -513,7 +513,7 @@ static void send_cleanup_vector(struct i >>> =20 >>> cpus_and(cleanup_mask, cfg->old_cpu_mask, cpu_online_map); >>> cfg->move_cleanup_count =3D cpus_weight(cleanup_mask); >>> - genapic->send_IPI_mask(&cleanup_mask, IRQ_MOVE_CLEANUP_VECTOR); >>> + genapic->send_IPI_mask(&cleanup_mask, MOVE_CLEANUP_VECTOR); >>> =20 >>> cfg->move_in_progress =3D 0; >>> } >>> diff -r 0268e7380953 -r c7884dbb6f7d xen/arch/x86/irq.c >>> --- a/xen/arch/x86/irq.c Mon Sep 05 15:10:28 2011 +0100 >>> +++ b/xen/arch/x86/irq.c Wed Sep 07 16:00:55 2011 +0100 >>> @@ -338,7 +338,7 @@ int __init init_irq_data(void) >>> set_bit(HYPERCALL_VECTOR, used_vectors); >>> =20 >>> /* IRQ_MOVE_CLEANUP_VECTOR used for clean up vectors */ >>> - set_bit(IRQ_MOVE_CLEANUP_VECTOR, used_vectors); >>> + set_bit(MOVE_CLEANUP_VECTOR, used_vectors); >>> =20 >>> return 0; >>> } >>> diff -r 0268e7380953 -r c7884dbb6f7d xen/arch/x86/smpboot.c >>> --- a/xen/arch/x86/smpboot.c Mon Sep 05 15:10:28 2011 +0100 >>> +++ b/xen/arch/x86/smpboot.c Wed Sep 07 16:00:55 2011 +0100 >>> @@ -1027,7 +1027,7 @@ void __init smp_intr_init(void) >>> } >>> =20 >>> /* IPI for cleanuping vectors after irq move */ >>> - set_intr_gate(IRQ_MOVE_CLEANUP_VECTOR, irq_move_cleanup_interrupt)= ; >>> + set_intr_gate(MOVE_CLEANUP_VECTOR, irq_move_cleanup_interrupt); >>> =20 >>> /* IPI for event checking. */ >>> set_intr_gate(EVENT_CHECK_VECTOR, event_check_interrupt); >>> diff -r 0268e7380953 -r c7884dbb6f7d >>> xen/include/asm-x86/mach-default/irq_vectors.h >>> --- a/xen/include/asm-x86/mach-default/irq_vectors.h Mon Sep 05 = 15:10:28 2011 >>> +0100 >>> +++ b/xen/include/asm-x86/mach-default/irq_vectors.h Wed Sep 07 = 16:00:55 2011 >>> +0100 >>> @@ -11,12 +11,14 @@ >>> #define LOCAL_TIMER_VECTOR 0xf9 >>> #define PMU_APIC_VECTOR 0xf8 >>> #define CMCI_APIC_VECTOR 0xf7 >>> +#define MOVE_CLEANUP_VECTOR 0xf6 >>> + >>> /* >>> * High-priority dynamically-allocated vectors. For interrupts that >>> * must be higher priority than any guest-bound interrupt. >>> */ >>> #define FIRST_HIPRIORITY_VECTOR 0xf0 >>> -#define LAST_HIPRIORITY_VECTOR 0xf6 >>> +#define LAST_HIPRIORITY_VECTOR 0xf5 >>> =20 >>> /* Legacy PIC uses vectors 0xe0-0xef. */ >>> #define FIRST_LEGACY_VECTOR 0xe0 >>> @@ -30,8 +32,6 @@ >>> #define LAST_DYNAMIC_VECTOR 0xdf >>> #define NR_DYNAMIC_VECTORS (LAST_DYNAMIC_VECTOR - FIRST_DYNAMIC_VECTOR= + 1) >>> =20 >>> -#define IRQ_MOVE_CLEANUP_VECTOR FIRST_DYNAMIC_VECTOR >>> - >>> #define NR_VECTORS 256 >>> =20 >>> #endif /* _ASM_IRQ_VECTORS_H */ >>>=20 >>> _______________________________________________ >>> Xen-devel mailing list >>> Xen-devel@lists.xensource.com=20 >>> http://lists.xensource.com/xen-devel=20 >>=20 >>=20 >>=20 >> _______________________________________________ >> Xen-devel mailing list >> Xen-devel@lists.xensource.com=20 >> http://lists.xensource.com/xen-devel=20 _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel From xen-devel-bounces@lists.xensource.com Thu Sep 08 00:57:07 2011 Return-path: Envelope-to: www-data@lists.xensource.com Delivery-date: Thu, 08 Sep 2011 00:57:07 -0700 Received: from localhost ([127.0.0.1] helo=lists.colo.xensource.com) by lists.xensource.com with esmtp (Exim 4.43) id 1R1ZTv-00060k-K7; Thu, 08 Sep 2011 00:57:07 -0700 Received: from mail21.messagelabs.com ([85.158.143.35]) by lists.xensource.com with smtp (Exim 4.43) id 1R1ZQX-00056E-Ek for xen-devel@lists.xensource.com; Thu, 08 Sep 2011 00:53:37 -0700 X-Env-Sender: avi@redhat.com X-Msg-Ref: server-13.tower-21.messagelabs.com!1315468408!48102413!1 X-Originating-IP: [209.132.183.28] X-StarScan-Version: 6.3.6; banners=-,-,- X-VirusChecked: Checked Received: (qmail 24556 invoked from network); 8 Sep 2011 07:53:28 -0000 Received: from mx1.redhat.com (HELO mx1.redhat.com) (209.132.183.28) by server-13.tower-21.messagelabs.com with SMTP; 8 Sep 2011 07:53:28 -0000 Received: from int-mx09.intmail.prod.int.phx2.redhat.com (int-mx09.intmail.prod.int.phx2.redhat.com [10.5.11.22]) by mx1.redhat.com (8.14.4/8.14.4) with ESMTP id p887plUb032593 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Thu, 8 Sep 2011 03:51:47 -0400 Received: from mermaid.qumranet.com (vpn-200-132.tlv.redhat.com [10.35.200.132]) by int-mx09.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP id p887pQ8p014808; Thu, 8 Sep 2011 03:51:43 -0400 Message-ID: <4E6873FE.3040603@redhat.com> Date: Thu, 08 Sep 2011 10:51:26 +0300 From: Avi Kivity User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:6.0) Gecko/20110816 Thunderbird/6.0 MIME-Version: 1.0 To: Jeremy Fitzhardinge References: <1314996468.8255.0.camel@twins> <4E614FBD.2030509@goop.org> <20110906151408.GA7459@redhat.com> <4E66615E.8070806@goop.org> <20110906182758.GR5795@redhat.com> <4E66EF86.9070200@redhat.com> <20110907134411.GV5795@redhat.com> <4E678992.5050709@redhat.com> <20110907155657.GX5795@redhat.com> <4E679AF4.50209@redhat.com> <20110907165203.GQ6838@redhat.com> <4E67A551.4000502@redhat.com> <4E67A71A.5070903@goop.org> <4E67ACB6.40107@redhat.com> <4E67C15B.3000408@goop.org> In-Reply-To: <4E67C15B.3000408@goop.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Scanned-By: MIMEDefang 2.68 on 10.5.11.22 Cc: Don Zickus , Marcelo Tosatti , Nick Piggin , KVM , Stefano Stabellini , Peter Zijlstra , the arch/x86 maintainers , Linux Kernel Mailing List , Andi Kleen , Jeremy Fitzhardinge , "H. Peter Anvin" , Ingo Molnar , Linus Torvalds , Xen Devel Subject: [Xen-devel] Re: [PATCH 08/13] xen/pvticketlock: disable interrupts while blocking X-BeenThere: xen-devel@lists.xensource.com X-Mailman-Version: 2.1.5 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xensource.com Errors-To: xen-devel-bounces@lists.xensource.com On 09/07/2011 10:09 PM, Jeremy Fitzhardinge wrote: > On 09/07/2011 10:41 AM, Avi Kivity wrote: > >> Hm, I'm interested to know what you're thinking in more detail. Can you > >> leave an NMI pending before you block in the same way you can with > >> "sti;halt" with normal interrupts? > > > > > > Nope. But you can do > > > > if (regs->rip in critical section) > > regs->rip = after_halt; > > > > and effectively emulate it. The critical section is something like > > > > critical_section_start: > > if (woken_up) > > goto critical_section_end; > > hlt > > critical_section_end: > > Hm. It's a pity you have to deliver an actual interrupt to implement > the kick though. I don't think it's that expensive, especially compared to the double-context-switch and vmexit of the spinner going to sleep. On AMD we do have to take an extra vmexit (on IRET) though. > >> > >> I was thinking you might want to do something with monitor/mwait to > >> implement the blocking/kick ops. (Handwave) > >> > > > > monitor/mwait are incredibly expensive to virtualize since they > > require write-protecting a page, IPIs flying everywhere and flushing > > tlbs, not to mention my lovely hugepages being broken up mercilessly. > > Or what about a futex-like hypercall? > Well we could have a specialized sleep/wakeup hypercall pair like Xen, but I'd like to avoid it if at all possible. -- I have a truly marvellous patch that fixes the bug which this signature is too narrow to contain. _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel From xen-devel-bounces@lists.xensource.com Thu Sep 08 01:07:24 2011 Return-path: Envelope-to: www-data@lists.xensource.com Delivery-date: Thu, 08 Sep 2011 01:07:24 -0700 Received: from localhost ([127.0.0.1] helo=lists.colo.xensource.com) by lists.xensource.com with esmtp (Exim 4.43) id 1R1Zds-0006WF-Ol; Thu, 08 Sep 2011 01:07:24 -0700 Received: from mail216.messagelabs.com ([85.158.143.99]) by lists.xensource.com with esmtp (Exim 4.43) id 1R1ZcX-0006IX-9M for xen-devel@lists.xensource.com; Thu, 08 Sep 2011 01:06:08 -0700 X-Env-Sender: JBeulich@suse.com X-Msg-Ref: server-5.tower-216.messagelabs.com!1315469147!17000993!1 X-Originating-IP: [130.57.49.28] X-StarScan-Version: 6.3.6; banners=-,-,- X-VirusChecked: Checked Received: (qmail 17430 invoked from network); 8 Sep 2011 08:05:47 -0000 Received: from nat28.tlf.novell.com (HELO nat28.tlf.novell.com) (130.57.49.28) by server-5.tower-216.messagelabs.com with DHE-RSA-AES256-SHA encrypted SMTP; 8 Sep 2011 08:05:47 -0000 Received: from EMEA1-MTA by nat28.tlf.novell.com with Novell_GroupWise; Thu, 08 Sep 2011 09:05:48 +0100 Message-Id: <4E6893910200007800055376@nat28.tlf.novell.com> X-Mailer: Novell GroupWise Internet Agent 8.0.1 Date: Thu, 08 Sep 2011 09:06:09 +0100 From: "Jan Beulich" To: "Konrad Rzeszutek Wilk" Subject: Re: [Xen-devel] blkfront problem in pvops kernel when barriers enabled References: <4E6357C6.6050101@mimuw.edu.pl> <20110906163213.GC5264@dumpdata.com> <4E665572.7080009@mimuw.edu.pl> <20110907014741.GD30639@dumpdata.com> <4E675A980200007800055050@nat28.tlf.novell.com> <4E6761630200007800055087@nat28.tlf.novell.com> <20110907174158.GL32190@dumpdata.com> In-Reply-To: <20110907174158.GL32190@dumpdata.com> Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: quoted-printable Content-Disposition: inline Cc: "xen-devel@lists.xensource.com" , Marek Marczykowski X-BeenThere: xen-devel@lists.xensource.com X-Mailman-Version: 2.1.5 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xensource.com Errors-To: xen-devel-bounces@lists.xensource.com >>> On 07.09.11 at 19:41, Konrad Rzeszutek Wilk = wrote: >> >> >> >>=20 >> >> I can only think of 2.6.38-3 XenOLinux doing it - and it is a bug >> >> to do it. It really ought to _not_ advertise 'feature-barrier' and >> >> instead advertise 'feature-flush-cache'. >> >=20 >> > Indeed, I see that I added feature-flush-cache support to the = frontend >> > back then, but neglected to do so for the backend. Partly perhaps >> > because I'm not much of a (block, network, ...) driver person... >> >=20 >> > However, what I'm not understanding with dropping feature-barrier >> > support from the backend - how do you deal with old frontends >> > wanting to use barriers? I'm currently converting them into >=20 > Just not supporting them. I know it is incredibly bad to do so - but > I have not had a chance to write the code to emulate the 'feature-barrier= ' > correctly. >=20 >> > WRITE_FLUSH_FUA operations in the backend as a (hopefully) best >> > effort approach. >=20 > I am not sure. I need to run blktrace|blkparse to make sure it does the > right think as compared to a WRITE_BARRIER. Lets ask Christopher Hellwig = - he > knows a lot of this. >=20 >>=20 >> Also I notice you're using WRITE_ODIRECT - what's the background >> of that? >=20 > Ah,=20 > http://git.drbd.org/linux-2.6-drbd.git/?p=3Dlinux-2.6-drbd.git;a=3Dcommit= ;h=3D013c3=20 > ca184851078b9c04744efd4d47e52c6ecf8 Hmm, that seems more like a band-aid than a real solution. What if with another scheduler (or after some changes to CFQ) REQ_SYNC actually hurts (as - without any data - I would have expected)? Can't/shouldn't the use of REQ_SYNC be made at least dependent on the scheduler in use on the queue? Jan _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel From xen-devel-bounces@lists.xensource.com Thu Sep 08 01:16:39 2011 Return-path: Envelope-to: www-data@lists.xensource.com Delivery-date: Thu, 08 Sep 2011 01:16:39 -0700 Received: from localhost ([127.0.0.1] helo=lists.colo.xensource.com) by lists.xensource.com with esmtp (Exim 4.43) id 1R1Zmp-0007dr-1G; Thu, 08 Sep 2011 01:16:39 -0700 Received: from mail174.messagelabs.com ([85.158.138.51]) by lists.xensource.com with esmtp (Exim 4.43) id 1R1ZmA-0007Rb-NR for xen-devel@lists.xensource.com; Thu, 08 Sep 2011 01:16:03 -0700 X-Env-Sender: keir.xen@gmail.com X-Msg-Ref: server-7.tower-174.messagelabs.com!1315469754!30636914!1 X-Originating-IP: [74.125.82.171] X-StarScan-Version: 6.3.6; banners=-,-,- X-VirusChecked: Checked Received: (qmail 12598 invoked from network); 8 Sep 2011 08:15:55 -0000 Received: from mail-wy0-f171.google.com (HELO mail-wy0-f171.google.com) (74.125.82.171) by server-7.tower-174.messagelabs.com with RC4-SHA encrypted SMTP; 8 Sep 2011 08:15:55 -0000 Received: by wyh13 with SMTP id 13so392845wyh.30 for ; Thu, 08 Sep 2011 01:15:54 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=sender:user-agent:date:subject:from:to:cc:message-id:thread-topic :thread-index:in-reply-to:mime-version:content-type :content-transfer-encoding; bh=iXoC8VIDb2o7yxfzaRsM8ajvOQ9J8MYJcmVUN1gu4bA=; b=HVe//FfsVFDiym6LOrkO3+qqSuA387dpdzgDegtonGxU0FS3U0+WV9kxNfTHqwi3CI sCZbDazkGfChOskGzxgqe1Sotf2nhtJx6UmG9kWTMWwLLDD32w2ofyMBlPc5Ktw3M66h UID+rVCwsT0XacMONzScRWPxIbHbU+OPmtZ1g= Received: by 10.216.170.72 with SMTP id o50mr378190wel.103.1315469753971; Thu, 08 Sep 2011 01:15:53 -0700 (PDT) Received: from [192.168.1.3] (host86-137-116-193.range86-137.btcentralplus.com [86.137.116.193]) by mx.google.com with ESMTPS id ev5sm3330978wbb.11.2011.09.08.01.15.48 (version=SSLv3 cipher=OTHER); Thu, 08 Sep 2011 01:15:52 -0700 (PDT) User-Agent: Microsoft-Entourage/12.30.0.110427 Date: Thu, 08 Sep 2011 09:15:45 +0100 Subject: Re: [Xen-devel] [PATCH] IRQ: Group IRQ_MOVE_CLEANUP_VECTOR with other hypervisor IPIs From: Keir Fraser To: Jan Beulich , Andrew Cooper Message-ID: Thread-Topic: [Xen-devel] [PATCH] IRQ: Group IRQ_MOVE_CLEANUP_VECTOR with other hypervisor IPIs Thread-Index: Acxt/4HhAa5tN6o8aEeFEK9+5iCa2Q== In-Reply-To: <4E688D68020000780005534E@nat28.tlf.novell.com> Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit Cc: xen-devel@lists.xensource.com, xiantao.zhang@intel.com X-BeenThere: xen-devel@lists.xensource.com X-Mailman-Version: 2.1.5 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xensource.com Errors-To: xen-devel-bounces@lists.xensource.com On 08/09/2011 08:39, "Jan Beulich" wrote: >>>> On 07.09.11 at 18:56, Keir Fraser wrote: >> On 07/09/2011 17:03, "Jan Beulich" wrote: >> >>>>>> On 07.09.11 at 17:03, Andrew Cooper wrote: >>> >>> Are you sure this is correct? I'm suspicious that this may intentionally >>> have been the lowest priority vector... >> >> I can't see why? > > Perhaps to get all "real" interrupts serviced first, and then do a single, > consolidated run through everything that needs cleaning up? All the > more since smp_irq_move_cleanup_interrupt() may re-issue the > interrupt to the local CPU. Ah, hm, that's a good point. We obviously livelock if we make IRQ_MOVE_CLEANUP_VECTOR higher priority than the vector that smp_irq_move_cleanup_interrupt() is attempting to retry. Andrew: I think we have to leave this vector where it is, but you could add a comment explaining why it is so, in your cleanup patchset. -- Keir > Cc-ing the original author in the hope that > he's still at Intel. > > And btw., if that change is correct, then the setting of > bit IRQ_MOVE_CLEANUP_VECTOR in used_vectors should actually be > removed - while used_vectors currently is dimensioned as NR_VECTORS, > none of the other "special" vectors get their bits set there, and the bit > array could therefore easily be shrunk to just NR_DYNAMIC_VECTORS. > > Jan > >>>> Also, rename to MOVE_CLEANUP_VECTOR to be in line with the other IPI >>>> names. >>> >>> Why would the removal of part of the descriptive name be in line with >>> the other names? We're dealing with the cleanup after an IRQ move >>> here, so let the name state this. The IRQ_ prefix here has nothing to >>> do with this being the vector for a specific IRQ. >> >> Agreed. >> >> -- Keir >> >>> Jan >>> >>>> This requires bumping LAST_HIPRIORITY_VECTOR, but does mean that the >>>> range FIRST-LAST_HIPRIORITY_VECTORs are free once again. >>>> >>>> Signed-off-by: Andrew Cooper >>>> >>>> diff -r 0268e7380953 -r c7884dbb6f7d xen/arch/x86/apic.c >>>> --- a/xen/arch/x86/apic.c Mon Sep 05 15:10:28 2011 +0100 >>>> +++ b/xen/arch/x86/apic.c Wed Sep 07 16:00:55 2011 +0100 >>>> @@ -90,7 +90,7 @@ bool_t __read_mostly directed_eoi_enable >>>> * through the ICC by us (IPIs) >>>> */ >>>> __asm__(".section .text"); >>>> -BUILD_SMP_INTERRUPT(irq_move_cleanup_interrupt,IRQ_MOVE_CLEANUP_VECTOR) >>>> +BUILD_SMP_INTERRUPT(irq_move_cleanup_interrupt,MOVE_CLEANUP_VECTOR) >>>> BUILD_SMP_INTERRUPT(event_check_interrupt,EVENT_CHECK_VECTOR) >>>> BUILD_SMP_INTERRUPT(invalidate_interrupt,INVALIDATE_TLB_VECTOR) >>>> BUILD_SMP_INTERRUPT(call_function_interrupt,CALL_FUNCTION_VECTOR) >>>> diff -r 0268e7380953 -r c7884dbb6f7d xen/arch/x86/hvm/vmx/vmx.c >>>> --- a/xen/arch/x86/hvm/vmx/vmx.c Mon Sep 05 15:10:28 2011 +0100 >>>> +++ b/xen/arch/x86/hvm/vmx/vmx.c Wed Sep 07 16:00:55 2011 +0100 >>>> @@ -1986,7 +1986,7 @@ static void vmx_do_extint(struct cpu_use >>>> >>>> switch ( vector ) >>>> { >>>> - case IRQ_MOVE_CLEANUP_VECTOR: >>>> + case MOVE_CLEANUP_VECTOR: >>>> smp_irq_move_cleanup_interrupt(regs); >>>> break; >>>> case LOCAL_TIMER_VECTOR: >>>> diff -r 0268e7380953 -r c7884dbb6f7d xen/arch/x86/io_apic.c >>>> --- a/xen/arch/x86/io_apic.c Mon Sep 05 15:10:28 2011 +0100 >>>> +++ b/xen/arch/x86/io_apic.c Wed Sep 07 16:00:55 2011 +0100 >>>> @@ -476,7 +476,7 @@ fastcall void smp_irq_move_cleanup_inter >>>> * to myself. >>>> */ >>>> if (irr & (1 << (vector % 32))) { >>>> - genapic->send_IPI_self(IRQ_MOVE_CLEANUP_VECTOR); >>>> + genapic->send_IPI_self(MOVE_CLEANUP_VECTOR); >>>> TRACE_3D(TRC_HW_IRQ_MOVE_CLEANUP_DELAY, >>>> irq, vector, smp_processor_id()); >>>> goto unlock; >>>> @@ -513,7 +513,7 @@ static void send_cleanup_vector(struct i >>>> >>>> cpus_and(cleanup_mask, cfg->old_cpu_mask, cpu_online_map); >>>> cfg->move_cleanup_count = cpus_weight(cleanup_mask); >>>> - genapic->send_IPI_mask(&cleanup_mask, IRQ_MOVE_CLEANUP_VECTOR); >>>> + genapic->send_IPI_mask(&cleanup_mask, MOVE_CLEANUP_VECTOR); >>>> >>>> cfg->move_in_progress = 0; >>>> } >>>> diff -r 0268e7380953 -r c7884dbb6f7d xen/arch/x86/irq.c >>>> --- a/xen/arch/x86/irq.c Mon Sep 05 15:10:28 2011 +0100 >>>> +++ b/xen/arch/x86/irq.c Wed Sep 07 16:00:55 2011 +0100 >>>> @@ -338,7 +338,7 @@ int __init init_irq_data(void) >>>> set_bit(HYPERCALL_VECTOR, used_vectors); >>>> >>>> /* IRQ_MOVE_CLEANUP_VECTOR used for clean up vectors */ >>>> - set_bit(IRQ_MOVE_CLEANUP_VECTOR, used_vectors); >>>> + set_bit(MOVE_CLEANUP_VECTOR, used_vectors); >>>> >>>> return 0; >>>> } >>>> diff -r 0268e7380953 -r c7884dbb6f7d xen/arch/x86/smpboot.c >>>> --- a/xen/arch/x86/smpboot.c Mon Sep 05 15:10:28 2011 +0100 >>>> +++ b/xen/arch/x86/smpboot.c Wed Sep 07 16:00:55 2011 +0100 >>>> @@ -1027,7 +1027,7 @@ void __init smp_intr_init(void) >>>> } >>>> >>>> /* IPI for cleanuping vectors after irq move */ >>>> - set_intr_gate(IRQ_MOVE_CLEANUP_VECTOR, irq_move_cleanup_interrupt); >>>> + set_intr_gate(MOVE_CLEANUP_VECTOR, irq_move_cleanup_interrupt); >>>> >>>> /* IPI for event checking. */ >>>> set_intr_gate(EVENT_CHECK_VECTOR, event_check_interrupt); >>>> diff -r 0268e7380953 -r c7884dbb6f7d >>>> xen/include/asm-x86/mach-default/irq_vectors.h >>>> --- a/xen/include/asm-x86/mach-default/irq_vectors.h Mon Sep 05 15:10:28 >>>> 2011 >>>> +0100 >>>> +++ b/xen/include/asm-x86/mach-default/irq_vectors.h Wed Sep 07 16:00:55 >>>> 2011 >>>> +0100 >>>> @@ -11,12 +11,14 @@ >>>> #define LOCAL_TIMER_VECTOR 0xf9 >>>> #define PMU_APIC_VECTOR 0xf8 >>>> #define CMCI_APIC_VECTOR 0xf7 >>>> +#define MOVE_CLEANUP_VECTOR 0xf6 >>>> + >>>> /* >>>> * High-priority dynamically-allocated vectors. For interrupts that >>>> * must be higher priority than any guest-bound interrupt. >>>> */ >>>> #define FIRST_HIPRIORITY_VECTOR 0xf0 >>>> -#define LAST_HIPRIORITY_VECTOR 0xf6 >>>> +#define LAST_HIPRIORITY_VECTOR 0xf5 >>>> >>>> /* Legacy PIC uses vectors 0xe0-0xef. */ >>>> #define FIRST_LEGACY_VECTOR 0xe0 >>>> @@ -30,8 +32,6 @@ >>>> #define LAST_DYNAMIC_VECTOR 0xdf >>>> #define NR_DYNAMIC_VECTORS (LAST_DYNAMIC_VECTOR - FIRST_DYNAMIC_VECTOR + >>>> 1) >>>> >>>> -#define IRQ_MOVE_CLEANUP_VECTOR FIRST_DYNAMIC_VECTOR >>>> - >>>> #define NR_VECTORS 256 >>>> >>>> #endif /* _ASM_IRQ_VECTORS_H */ >>>> >>>> _______________________________________________ >>>> Xen-devel mailing list >>>> Xen-devel@lists.xensource.com >>>> http://lists.xensource.com/xen-devel >>> >>> >>> >>> _______________________________________________ >>> Xen-devel mailing list >>> Xen-devel@lists.xensource.com >>> http://lists.xensource.com/xen-devel > > _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel From xen-devel-bounces@lists.xensource.com Thu Sep 08 01:41:55 2011 Return-path: Envelope-to: www-data@lists.xensource.com Delivery-date: Thu, 08 Sep 2011 01:41:55 -0700 Received: from localhost ([127.0.0.1] helo=lists.colo.xensource.com) by lists.xensource.com with esmtp (Exim 4.43) id 1R1aBG-0008Qf-Ul; Thu, 08 Sep 2011 01:41:54 -0700 Received: from mail21.messagelabs.com ([85.158.143.35]) by lists.xensource.com with esmtp (Exim 4.43) id 1R1aAU-0008Ei-Rc for Xen-devel@lists.xensource.com; Thu, 08 Sep 2011 01:41:07 -0700 X-Env-Sender: JBeulich@suse.com X-Msg-Ref: server-3.tower-21.messagelabs.com!1315471275!50757939!1 X-Originating-IP: [130.57.49.28] X-StarScan-Version: 6.3.6; banners=-,-,- X-VirusChecked: Checked Received: (qmail 14248 invoked from network); 8 Sep 2011 08:41:15 -0000 Received: from nat28.tlf.novell.com (HELO nat28.tlf.novell.com) (130.57.49.28) by server-3.tower-21.messagelabs.com with DHE-RSA-AES256-SHA encrypted SMTP; 8 Sep 2011 08:41:15 -0000 Received: from EMEA1-MTA by nat28.tlf.novell.com with Novell_GroupWise; Thu, 08 Sep 2011 09:41:04 +0100 Message-Id: <4E689BD502000078000553B9@nat28.tlf.novell.com> X-Mailer: Novell GroupWise Internet Agent 8.0.1 Date: Thu, 08 Sep 2011 09:41:25 +0100 From: "Jan Beulich" To: "Mukesh Rathor" References: <20110901122004.2c12f34f@mantra.us.oracle.com> <4E64DC220200007800054A9D@nat28.tlf.novell.com> <20110907182448.25b9eda8@mantra.us.oracle.com> In-Reply-To: <20110907182448.25b9eda8@mantra.us.oracle.com> Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: quoted-printable Content-Disposition: inline Cc: "Xen-devel@lists.xensource.com" Subject: [Xen-devel] Re: DOM0 Hang on a large box.... X-BeenThere: xen-devel@lists.xensource.com X-Mailman-Version: 2.1.5 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xensource.com Errors-To: xen-devel-bounces@lists.xensource.com >>> On 08.09.11 at 03:24, Mukesh Rathor wrote: > On Mon, 05 Sep 2011 13:26:42 +0100 > "Jan Beulich" wrote: >=20 >> From the observation of most CPUs sitting in _double_lock_balance() >> I would have answered yes, but the odd upcall mask I don't recall >> having seen. In any case - is your Dom0 kernel (presumably derived >> from ours) up-to-date? That problem I recall was fixed months ago. >=20 > Yes, it's derived from yours, not quite upto date for various reasons I > don't know about. If it's possible, please let me know patch c/s or id > or something. I see tons there.... we must be far behind. That's rather difficult, but the thing I have in mind was actually in one or more 2.6.32.x stable update(s) (entirely Xen-unspecific, just exposed more intensively under Xen). With kernel.org continuing to be down it's also hard to point out the upstream commits - you'd want to look for changes in kernel/smp.c. Jan _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel From xen-devel-bounces@lists.xensource.com Thu Sep 08 01:50:37 2011 Return-path: Envelope-to: www-data@lists.xensource.com Delivery-date: Thu, 08 Sep 2011 01:50:37 -0700 Received: from localhost ([127.0.0.1] helo=lists.colo.xensource.com) by lists.xensource.com with esmtp (Exim 4.43) id 1R1aJh-0000Ue-PH; Thu, 08 Sep 2011 01:50:37 -0700 Received: from mail216.messagelabs.com ([85.158.143.99]) by lists.xensource.com with esmtp (Exim 4.43) id 1R1aJC-0000IT-8E for xen-devel@lists.xensource.com; Thu, 08 Sep 2011 01:50:06 -0700 X-Env-Sender: tim@xen.org X-Msg-Ref: server-11.tower-216.messagelabs.com!1315471803!9912954!1 X-Originating-IP: [81.29.64.94] X-StarScan-Version: 6.3.6; banners=-,-,- X-VirusChecked: Checked Received: (qmail 30037 invoked from network); 8 Sep 2011 08:50:03 -0000 Received: from ocelot.phlegethon.org (HELO mail.phlegethon.org) (81.29.64.94) by server-11.tower-216.messagelabs.com with DHE-RSA-AES256-SHA encrypted SMTP; 8 Sep 2011 08:50:03 -0000 Received: from tjd by mail.phlegethon.org with local (Exim 4.67 (FreeBSD)) (envelope-from ) id 1R1aJ8-000Hpo-I7; Thu, 08 Sep 2011 08:50:02 +0000 Date: Thu, 8 Sep 2011 09:50:02 +0100 From: Tim Deegan To: Eric Camachat Subject: Re: [Xen-devel] Can I specify a physical memory region for a domU Message-ID: <20110908085002.GA68451@ocelot.phlegethon.org> References: Mime-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.4.2.1i Cc: xen-devel@lists.xensource.com X-BeenThere: xen-devel@lists.xensource.com X-Mailman-Version: 2.1.5 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xensource.com Errors-To: xen-devel-bounces@lists.xensource.com At 17:47 -0700 on 07 Sep (1315417666), Eric Camachat wrote: > Hi, > > I am porting our drivers to XEN's PV domU (with PV PCI passthrouth), I > have to allocate a memory block and tell the hardware to access it. > But the hardware can address 32-bit only, so I want dedicate a region > of memory that below 2GB for the domU only. > How do that in XEN? Use the XENMEM_echange memory_op hypercall. You can specify a bit-width for the pages you want returned. Of course, on a full Xen host there may be no 32-bit-clean memory left. Xen tries to allocate the higher addresses first to avoid that, but there's no guarantee. Tim. _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel From xen-devel-bounces@lists.xensource.com Thu Sep 08 02:12:14 2011 Return-path: Envelope-to: www-data@lists.xensource.com Delivery-date: Thu, 08 Sep 2011 02:12:14 -0700 Received: from localhost ([127.0.0.1] helo=lists.colo.xensource.com) by lists.xensource.com with esmtp (Exim 4.43) id 1R1aeb-0001HL-Bp; Thu, 08 Sep 2011 02:12:13 -0700 Received: from mail174.messagelabs.com ([85.158.138.51]) by lists.xensource.com with esmtp (Exim 4.43) id 1R1adZ-00014R-HT for xen-devel@lists.xensource.com; Thu, 08 Sep 2011 02:11:10 -0700 X-Env-Sender: Andrew.Cooper3@citrix.com X-Msg-Ref: server-5.tower-174.messagelabs.com!1315473061!26968656!1 X-Originating-IP: [66.165.176.89] X-StarScan-Version: 6.3.6; banners=-,-,- X-VirusChecked: Checked Received: (qmail 17549 invoked from network); 8 Sep 2011 09:11:06 -0000 Received: from smtp.citrix.com (HELO SMTP.CITRIX.COM) (66.165.176.89) by server-5.tower-174.messagelabs.com with RC4-SHA encrypted SMTP; 8 Sep 2011 09:11:06 -0000 X-IronPort-AV: E=Sophos;i="4.68,349,1312171200"; d="scan'208";a="16788137" Received: from ftlpmailmx01.citrite.net ([10.13.107.65]) by FTLPIPO01.CITRIX.COM with ESMTP/TLS/RC4-MD5; 08 Sep 2011 05:11:01 -0400 Received: from [10.80.2.18] (10.80.2.18) by FTLPMAILMX01.citrite.net (10.13.107.65) with Microsoft SMTP Server id 8.3.137.0; Thu, 8 Sep 2011 05:11:00 -0400 Message-ID: <4E6886A3.3060402@citrix.com> Date: Thu, 8 Sep 2011 10:10:59 +0100 From: Andrew Cooper User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.2.21) Gecko/20110831 Lightning/1.0b2 Thunderbird/3.1.13 MIME-Version: 1.0 To: Keir Fraser Subject: Re: [Xen-devel] [PATCH] IRQ: Group IRQ_MOVE_CLEANUP_VECTOR with other hypervisor IPIs References: In-Reply-To: Content-Type: text/plain; charset="ISO-8859-1" Content-Transfer-Encoding: 7bit Cc: "xen-devel@lists.xensource.com" , "xiantao.zhang@intel.com" , Jan Beulich X-BeenThere: xen-devel@lists.xensource.com X-Mailman-Version: 2.1.5 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xensource.com Errors-To: xen-devel-bounces@lists.xensource.com On 08/09/11 09:15, Keir Fraser wrote: > On 08/09/2011 08:39, "Jan Beulich" wrote: > >>>>> On 07.09.11 at 18:56, Keir Fraser wrote: >>> On 07/09/2011 17:03, "Jan Beulich" wrote: >>> >>>>>>> On 07.09.11 at 17:03, Andrew Cooper wrote: >>>> Are you sure this is correct? I'm suspicious that this may intentionally >>>> have been the lowest priority vector... >>> I can't see why? >> Perhaps to get all "real" interrupts serviced first, and then do a single, >> consolidated run through everything that needs cleaning up? All the >> more since smp_irq_move_cleanup_interrupt() may re-issue the >> interrupt to the local CPU. > Ah, hm, that's a good point. We obviously livelock if we make > IRQ_MOVE_CLEANUP_VECTOR higher priority than the vector that > smp_irq_move_cleanup_interrupt() is attempting to retry. > > Andrew: I think we have to leave this vector where it is, but you could add > a comment explaining why it is so, in your cleanup patchset. > > -- Keir Wow I was having a slow day - I was thinking that IRQ_MOVE_CLEANUP_VECTOR was the first high priority vector. In which case it should probably stay at its current vector, but FIRST_DYNAMIC_VECTOR should probably be bumped up, as it is no longer a vector dynamically allocated to guests. >> Cc-ing the original author in the hope that >> he's still at Intel. >> >> And btw., if that change is correct, then the setting of >> bit IRQ_MOVE_CLEANUP_VECTOR in used_vectors should actually be >> removed - while used_vectors currently is dimensioned as NR_VECTORS, >> none of the other "special" vectors get their bits set there, and the bit >> array could therefore easily be shrunk to just NR_DYNAMIC_VECTORS. >> >> Jan >> >>>>> Also, rename to MOVE_CLEANUP_VECTOR to be in line with the other IPI >>>>> names. >>>> Why would the removal of part of the descriptive name be in line with >>>> the other names? We're dealing with the cleanup after an IRQ move >>>> here, so let the name state this. The IRQ_ prefix here has nothing to >>>> do with this being the vector for a specific IRQ. >>> Agreed. >>> >>> -- Keir >>> >>>> Jan >>>> >>>>> This requires bumping LAST_HIPRIORITY_VECTOR, but does mean that the >>>>> range FIRST-LAST_HIPRIORITY_VECTORs are free once again. >>>>> >>>>> Signed-off-by: Andrew Cooper >>>>> >>>>> diff -r 0268e7380953 -r c7884dbb6f7d xen/arch/x86/apic.c >>>>> --- a/xen/arch/x86/apic.c Mon Sep 05 15:10:28 2011 +0100 >>>>> +++ b/xen/arch/x86/apic.c Wed Sep 07 16:00:55 2011 +0100 >>>>> @@ -90,7 +90,7 @@ bool_t __read_mostly directed_eoi_enable >>>>> * through the ICC by us (IPIs) >>>>> */ >>>>> __asm__(".section .text"); >>>>> -BUILD_SMP_INTERRUPT(irq_move_cleanup_interrupt,IRQ_MOVE_CLEANUP_VECTOR) >>>>> +BUILD_SMP_INTERRUPT(irq_move_cleanup_interrupt,MOVE_CLEANUP_VECTOR) >>>>> BUILD_SMP_INTERRUPT(event_check_interrupt,EVENT_CHECK_VECTOR) >>>>> BUILD_SMP_INTERRUPT(invalidate_interrupt,INVALIDATE_TLB_VECTOR) >>>>> BUILD_SMP_INTERRUPT(call_function_interrupt,CALL_FUNCTION_VECTOR) >>>>> diff -r 0268e7380953 -r c7884dbb6f7d xen/arch/x86/hvm/vmx/vmx.c >>>>> --- a/xen/arch/x86/hvm/vmx/vmx.c Mon Sep 05 15:10:28 2011 +0100 >>>>> +++ b/xen/arch/x86/hvm/vmx/vmx.c Wed Sep 07 16:00:55 2011 +0100 >>>>> @@ -1986,7 +1986,7 @@ static void vmx_do_extint(struct cpu_use >>>>> >>>>> switch ( vector ) >>>>> { >>>>> - case IRQ_MOVE_CLEANUP_VECTOR: >>>>> + case MOVE_CLEANUP_VECTOR: >>>>> smp_irq_move_cleanup_interrupt(regs); >>>>> break; >>>>> case LOCAL_TIMER_VECTOR: >>>>> diff -r 0268e7380953 -r c7884dbb6f7d xen/arch/x86/io_apic.c >>>>> --- a/xen/arch/x86/io_apic.c Mon Sep 05 15:10:28 2011 +0100 >>>>> +++ b/xen/arch/x86/io_apic.c Wed Sep 07 16:00:55 2011 +0100 >>>>> @@ -476,7 +476,7 @@ fastcall void smp_irq_move_cleanup_inter >>>>> * to myself. >>>>> */ >>>>> if (irr & (1 << (vector % 32))) { >>>>> - genapic->send_IPI_self(IRQ_MOVE_CLEANUP_VECTOR); >>>>> + genapic->send_IPI_self(MOVE_CLEANUP_VECTOR); >>>>> TRACE_3D(TRC_HW_IRQ_MOVE_CLEANUP_DELAY, >>>>> irq, vector, smp_processor_id()); >>>>> goto unlock; >>>>> @@ -513,7 +513,7 @@ static void send_cleanup_vector(struct i >>>>> >>>>> cpus_and(cleanup_mask, cfg->old_cpu_mask, cpu_online_map); >>>>> cfg->move_cleanup_count = cpus_weight(cleanup_mask); >>>>> - genapic->send_IPI_mask(&cleanup_mask, IRQ_MOVE_CLEANUP_VECTOR); >>>>> + genapic->send_IPI_mask(&cleanup_mask, MOVE_CLEANUP_VECTOR); >>>>> >>>>> cfg->move_in_progress = 0; >>>>> } >>>>> diff -r 0268e7380953 -r c7884dbb6f7d xen/arch/x86/irq.c >>>>> --- a/xen/arch/x86/irq.c Mon Sep 05 15:10:28 2011 +0100 >>>>> +++ b/xen/arch/x86/irq.c Wed Sep 07 16:00:55 2011 +0100 >>>>> @@ -338,7 +338,7 @@ int __init init_irq_data(void) >>>>> set_bit(HYPERCALL_VECTOR, used_vectors); >>>>> >>>>> /* IRQ_MOVE_CLEANUP_VECTOR used for clean up vectors */ >>>>> - set_bit(IRQ_MOVE_CLEANUP_VECTOR, used_vectors); >>>>> + set_bit(MOVE_CLEANUP_VECTOR, used_vectors); >>>>> >>>>> return 0; >>>>> } >>>>> diff -r 0268e7380953 -r c7884dbb6f7d xen/arch/x86/smpboot.c >>>>> --- a/xen/arch/x86/smpboot.c Mon Sep 05 15:10:28 2011 +0100 >>>>> +++ b/xen/arch/x86/smpboot.c Wed Sep 07 16:00:55 2011 +0100 >>>>> @@ -1027,7 +1027,7 @@ void __init smp_intr_init(void) >>>>> } >>>>> >>>>> /* IPI for cleanuping vectors after irq move */ >>>>> - set_intr_gate(IRQ_MOVE_CLEANUP_VECTOR, irq_move_cleanup_interrupt); >>>>> + set_intr_gate(MOVE_CLEANUP_VECTOR, irq_move_cleanup_interrupt); >>>>> >>>>> /* IPI for event checking. */ >>>>> set_intr_gate(EVENT_CHECK_VECTOR, event_check_interrupt); >>>>> diff -r 0268e7380953 -r c7884dbb6f7d >>>>> xen/include/asm-x86/mach-default/irq_vectors.h >>>>> --- a/xen/include/asm-x86/mach-default/irq_vectors.h Mon Sep 05 15:10:28 >>>>> 2011 >>>>> +0100 >>>>> +++ b/xen/include/asm-x86/mach-default/irq_vectors.h Wed Sep 07 16:00:55 >>>>> 2011 >>>>> +0100 >>>>> @@ -11,12 +11,14 @@ >>>>> #define LOCAL_TIMER_VECTOR 0xf9 >>>>> #define PMU_APIC_VECTOR 0xf8 >>>>> #define CMCI_APIC_VECTOR 0xf7 >>>>> +#define MOVE_CLEANUP_VECTOR 0xf6 >>>>> + >>>>> /* >>>>> * High-priority dynamically-allocated vectors. For interrupts that >>>>> * must be higher priority than any guest-bound interrupt. >>>>> */ >>>>> #define FIRST_HIPRIORITY_VECTOR 0xf0 >>>>> -#define LAST_HIPRIORITY_VECTOR 0xf6 >>>>> +#define LAST_HIPRIORITY_VECTOR 0xf5 >>>>> >>>>> /* Legacy PIC uses vectors 0xe0-0xef. */ >>>>> #define FIRST_LEGACY_VECTOR 0xe0 >>>>> @@ -30,8 +32,6 @@ >>>>> #define LAST_DYNAMIC_VECTOR 0xdf >>>>> #define NR_DYNAMIC_VECTORS (LAST_DYNAMIC_VECTOR - FIRST_DYNAMIC_VECTOR + >>>>> 1) >>>>> >>>>> -#define IRQ_MOVE_CLEANUP_VECTOR FIRST_DYNAMIC_VECTOR >>>>> - >>>>> #define NR_VECTORS 256 >>>>> >>>>> #endif /* _ASM_IRQ_VECTORS_H */ >>>>> >>>>> _______________________________________________ >>>>> Xen-devel mailing list >>>>> Xen-devel@lists.xensource.com >>>>> http://lists.xensource.com/xen-devel >>>> >>>> >>>> _______________________________________________ >>>> Xen-devel mailing list >>>> Xen-devel@lists.xensource.com >>>> http://lists.xensource.com/xen-devel >> > -- Andrew Cooper - Dom0 Kernel Engineer, Citrix XenServer T: +44 (0)1223 225 900, http://www.citrix.com _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel From xen-devel-bounces@lists.xensource.com Thu Sep 08 02:13:40 2011 Return-path: Envelope-to: www-data@lists.xensource.com Delivery-date: Thu, 08 Sep 2011 02:13:40 -0700 Received: from localhost ([127.0.0.1] helo=lists.colo.xensource.com) by lists.xensource.com with esmtp (Exim 4.43) id 1R1afz-0001ju-Ma; Thu, 08 Sep 2011 02:13:39 -0700 Received: from mail174.messagelabs.com ([85.158.138.51]) by lists.xensource.com with esmtp (Exim 4.43) id 1R1aev-0001Ll-GW for xen-devel@lists.xensource.com; Thu, 08 Sep 2011 02:12:34 -0700 X-Env-Sender: JBeulich@suse.com X-Msg-Ref: server-2.tower-174.messagelabs.com!1315473144!30670311!1 X-Originating-IP: [130.57.49.28] X-StarScan-Version: 6.3.6; banners=-,-,- X-VirusChecked: Checked Received: (qmail 20232 invoked from network); 8 Sep 2011 09:12:30 -0000 Received: from nat28.tlf.novell.com (HELO nat28.tlf.novell.com) (130.57.49.28) by server-2.tower-174.messagelabs.com with DHE-RSA-AES256-SHA encrypted SMTP; 8 Sep 2011 09:12:30 -0000 Received: from EMEA1-MTA by nat28.tlf.novell.com with Novell_GroupWise; Thu, 08 Sep 2011 10:12:28 +0100 Message-Id: <4E68A32C02000078000553D7@nat28.tlf.novell.com> X-Mailer: Novell GroupWise Internet Agent 8.0.1 Date: Thu, 08 Sep 2011 10:12:44 +0100 From: "Jan Beulich" To: "Yang Z Zhang" Subject: Re: [Xen-devel] [PATCH]Make sure processor_pminfo initialized before use it References: <749B9D3DBF0F054390025D9EAFF47F2212D149D959@shsmsx501.ccr.corp.intel.com> In-Reply-To: <749B9D3DBF0F054390025D9EAFF47F2212D149D959@shsmsx501.ccr.corp.intel.com> Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: quoted-printable Content-Disposition: inline Cc: "xen-devel@lists.xensource.com" , Keir Fraser X-BeenThere: xen-devel@lists.xensource.com X-Mailman-Version: 2.1.5 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xensource.com Errors-To: xen-devel-bounces@lists.xensource.com >>> On 08.09.11 at 08:09, "Zhang, Yang Z" wrote: > Make sure processor_pminfo not null before use it >=20 > If processor_pminfo not initialized, it will cause xen panic. Mind pointing out what panic you observed, because ... > Signed-off-by: Yang Zhang >=20 > diff -r bdd19847ae63 xen/drivers/cpufreq/cpufreq.c > --- a/xen/drivers/cpufreq/cpufreq.c Wed Sep 07 10:37:48 2011 +0100 > +++ b/xen/drivers/cpufreq/cpufreq.c Thu Sep 08 13:40:23 2011 +0800 > @@ -91,7 +91,7 @@ int __init cpufreq_register_governor(str >=20 > int cpufreq_limit_change(unsigned int cpu) > { > - struct processor_performance *perf =3D &processor_pminfo[cpu]->perf;= > + struct processor_performance *perf; ... this (and all other changed instances below) is not actually de-referencing processor_pminfo[cpu], and the first de-reference always is only after that one got checked against NULL. Jan > struct cpufreq_policy *data; > struct cpufreq_policy policy; >=20 > @@ -99,6 +99,7 @@ int cpufreq_limit_change(unsigned int cp > !processor_pminfo[cpu]) > return -ENODEV; >=20 > + perf =3D &processor_pminfo[cpu]->perf; > if (perf->platform_limit >=3D perf->state_count) > return -EINVAL; >=20 > @@ -120,12 +121,14 @@ int cpufreq_add_cpu(unsigned int cpu) > struct cpufreq_dom *cpufreq_dom =3D NULL; > struct cpufreq_policy new_policy; > struct cpufreq_policy *policy; > - struct processor_performance *perf =3D &processor_pminfo[cpu]->perf;= > + struct processor_performance *perf; >=20 > /* to protect the case when Px was not controlled by xen */ > - if (!processor_pminfo[cpu] || > - !(perf->init & XEN_PX_INIT) || > - !cpu_online(cpu)) > + if (!processor_pminfo[cpu] || !cpu_online(cpu)) > + return -EINVAL; > + > + perf =3D &processor_pminfo[cpu]->perf; > + if (!(perf->init & XEN_PX_INIT)) > return -EINVAL; >=20 > if (!cpufreq_driver) > @@ -261,12 +264,14 @@ int cpufreq_del_cpu(unsigned int cpu) > struct list_head *pos; > struct cpufreq_dom *cpufreq_dom =3D NULL; > struct cpufreq_policy *policy; > - struct processor_performance *perf =3D &processor_pminfo[cpu]->perf;= > + struct processor_performance *perf; >=20 > /* to protect the case when Px was not controlled by xen */ > - if (!processor_pminfo[cpu] || > - !(perf->init & XEN_PX_INIT) || > - !cpu_online(cpu)) > + if (!processor_pminfo[cpu] || !cpu_online(cpu)) > + return -EINVAL; > + > + perf =3D &processor_pminfo[cpu]->perf; > + if (!(perf->init & XEN_PX_INIT)) > return -EINVAL; >=20 > if (!per_cpu(cpufreq_cpu_policy, cpu)) >=20 >=20 >=20 > _______________________________________________ > Xen-devel mailing list > Xen-devel@lists.xensource.com=20 > http://lists.xensource.com/xen-devel=20 _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel From xen-devel-bounces@lists.xensource.com Thu Sep 08 02:14:49 2011 Return-path: Envelope-to: www-data@lists.xensource.com Delivery-date: Thu, 08 Sep 2011 02:14:49 -0700 Received: from localhost ([127.0.0.1] helo=lists.colo.xensource.com) by lists.xensource.com with esmtp (Exim 4.43) id 1R1ah7-00026z-KR; Thu, 08 Sep 2011 02:14:49 -0700 Received: from mail27.messagelabs.com ([193.109.254.147]) by lists.xensource.com with esmtp (Exim 4.43) id 1R1age-0001uc-AA for xen-devel@lists.xensource.com; Thu, 08 Sep 2011 02:14:20 -0700 X-Env-Sender: keir.xen@gmail.com X-Msg-Ref: server-6.tower-27.messagelabs.com!1315473239!48090908!1 X-Originating-IP: [74.125.82.43] X-StarScan-Version: 6.3.6; banners=-,-,- X-VirusChecked: Checked Received: (qmail 14235 invoked from network); 8 Sep 2011 09:13:59 -0000 Received: from mail-ww0-f43.google.com (HELO mail-ww0-f43.google.com) (74.125.82.43) by server-6.tower-27.messagelabs.com with RC4-SHA encrypted SMTP; 8 Sep 2011 09:13:59 -0000 Received: by wwe32 with SMTP id 32so463962wwe.24 for ; Thu, 08 Sep 2011 02:14:17 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=sender:user-agent:date:subject:from:to:cc:message-id:thread-topic :thread-index:in-reply-to:mime-version:content-type :content-transfer-encoding; bh=zUWDtt+ZioOloXTH8kUS+XQevYXASFPih/3wBxYMIwY=; b=ufgT+3wOQKMoFIVjqfLI5ZxYhuYzz9/Yybg/zPG9SmRb8a5yJw3VOKJ6UDXagvCgsU hpzfuhwy4iMThkSirm4c+Vhi2pe3DUF8d1O6+gi4Fhkb6N3NB4wvNebTWDjgCmL1NpLr axt1rsMzX6aO8W2o6DMeJQ8lZmShowl1oeAu0= Received: by 10.227.143.66 with SMTP id t2mr482437wbu.50.1315473256989; Thu, 08 Sep 2011 02:14:16 -0700 (PDT) Received: from [192.168.1.3] (host86-137-116-193.range86-137.btcentralplus.com [86.137.116.193]) by mx.google.com with ESMTPS id ft2sm3473513wbb.18.2011.09.08.02.14.10 (version=SSLv3 cipher=OTHER); Thu, 08 Sep 2011 02:14:15 -0700 (PDT) User-Agent: Microsoft-Entourage/12.30.0.110427 Date: Thu, 08 Sep 2011 10:14:02 +0100 Subject: Re: [Xen-devel] [PATCH] IRQ: Group IRQ_MOVE_CLEANUP_VECTOR with other hypervisor IPIs From: Keir Fraser To: Andrew Cooper Message-ID: Thread-Topic: [Xen-devel] [PATCH] IRQ: Group IRQ_MOVE_CLEANUP_VECTOR with other hypervisor IPIs Thread-Index: AcxuB6ZAJHfenP5aDUy5ale3TMwq+Q== In-Reply-To: <4E6886A3.3060402@citrix.com> Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit Cc: "xen-devel@lists.xensource.com" , "xiantao.zhang@intel.com" , Jan Beulich X-BeenThere: xen-devel@lists.xensource.com X-Mailman-Version: 2.1.5 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xensource.com Errors-To: xen-devel-bounces@lists.xensource.com On 08/09/2011 10:10, "Andrew Cooper" wrote: >> Andrew: I think we have to leave this vector where it is, but you could add >> a comment explaining why it is so, in your cleanup patchset. >> >> -- Keir > > Wow I was having a slow day - I was thinking that > IRQ_MOVE_CLEANUP_VECTOR was the first high priority vector. > > In which case it should probably stay at its current vector, but > FIRST_DYNAMIC_VECTOR should probably be bumped up, as it is no longer a > vector dynamically allocated to guests. Sounds reasonable. -- Keir _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel From xen-devel-bounces@lists.xensource.com Thu Sep 08 02:19:35 2011 Return-path: Envelope-to: www-data@lists.xensource.com Delivery-date: Thu, 08 Sep 2011 02:19:35 -0700 Received: from localhost ([127.0.0.1] helo=lists.colo.xensource.com) by lists.xensource.com with esmtp (Exim 4.43) id 1R1alj-0002XG-1q; Thu, 08 Sep 2011 02:19:35 -0700 Received: from mail174.messagelabs.com ([85.158.138.51]) by lists.xensource.com with esmtp (Exim 4.43) id 1R1al3-0002Ky-02 for xen-devel@lists.xensource.com; Thu, 08 Sep 2011 02:18:54 -0700 X-Env-Sender: JBeulich@suse.com X-Msg-Ref: server-13.tower-174.messagelabs.com!1315473528!30679667!1 X-Originating-IP: [130.57.49.28] X-StarScan-Version: 6.3.6; banners=-,-,- X-VirusChecked: Checked Received: (qmail 19064 invoked from network); 8 Sep 2011 09:18:49 -0000 Received: from nat28.tlf.novell.com (HELO nat28.tlf.novell.com) (130.57.49.28) by server-13.tower-174.messagelabs.com with DHE-RSA-AES256-SHA encrypted SMTP; 8 Sep 2011 09:18:49 -0000 Received: from EMEA1-MTA by nat28.tlf.novell.com with Novell_GroupWise; Thu, 08 Sep 2011 10:18:53 +0100 Message-Id: <4E68A4AC02000078000553F2@nat28.tlf.novell.com> X-Mailer: Novell GroupWise Internet Agent 8.0.1 Date: Thu, 08 Sep 2011 10:19:08 +0100 From: "Jan Beulich" To: "Keir Fraser" Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: quoted-printable Content-Disposition: inline Cc: "xen-devel@lists.xensource.com" Subject: [Xen-devel] 4.0/4.1 requests X-BeenThere: xen-devel@lists.xensource.com X-Mailman-Version: 2.1.5 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xensource.com Errors-To: xen-devel-bounces@lists.xensource.com Hi Keir, without the old IO-APIC part addressed, I wonder whether we should really have the backport of 23805:7048810180de ("IRQ: manually EOI migrating line interrupts") in both trees. I'd also like you to add 23820:ba75234a6f56 ("bitmap_scnlistprintf() should always zero-terminate its output buffer") to 4.0 (I see it's already in 4.1), as this not being fixed confuses 'e' debug key output. Jan _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel From xen-devel-bounces@lists.xensource.com Thu Sep 08 02:21:04 2011 Return-path: Envelope-to: www-data@lists.xensource.com Delivery-date: Thu, 08 Sep 2011 02:21:04 -0700 Received: from localhost ([127.0.0.1] helo=lists.colo.xensource.com) by lists.xensource.com with esmtp (Exim 4.43) id 1R1anA-0002vR-Pq; Thu, 08 Sep 2011 02:21:04 -0700 Received: from mail174.messagelabs.com ([85.158.138.51]) by lists.xensource.com with esmtp (Exim 4.43) id 1R1amk-0002ik-5T for xen-devel@lists.xensource.com; Thu, 08 Sep 2011 02:20:38 -0700 X-Env-Sender: JBeulich@suse.com X-Msg-Ref: server-13.tower-174.messagelabs.com!1315473631!30680066!1 X-Originating-IP: [130.57.49.28] X-StarScan-Version: 6.3.6; banners=-,-,- X-VirusChecked: Checked Received: (qmail 26104 invoked from network); 8 Sep 2011 09:20:34 -0000 Received: from nat28.tlf.novell.com (HELO nat28.tlf.novell.com) (130.57.49.28) by server-13.tower-174.messagelabs.com with DHE-RSA-AES256-SHA encrypted SMTP; 8 Sep 2011 09:20:34 -0000 Received: from EMEA1-MTA by nat28.tlf.novell.com with Novell_GroupWise; Thu, 08 Sep 2011 10:20:36 +0100 Message-Id: <4E68A5120200007800055400@nat28.tlf.novell.com> X-Mailer: Novell GroupWise Internet Agent 8.0.1 Date: Thu, 08 Sep 2011 10:20:50 +0100 From: "Jan Beulich" To: "Andrew Cooper" Subject: Re: [Xen-devel] [PATCH] IRQ: Group IRQ_MOVE_CLEANUP_VECTOR with other hypervisor IPIs References: <4E6886A3.3060402@citrix.com> In-Reply-To: <4E6886A3.3060402@citrix.com> Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: quoted-printable Content-Disposition: inline Cc: "xen-devel@lists.xensource.com" , Keir Fraser , "xiantao.zhang@intel.com" X-BeenThere: xen-devel@lists.xensource.com X-Mailman-Version: 2.1.5 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xensource.com Errors-To: xen-devel-bounces@lists.xensource.com >>> On 08.09.11 at 11:10, Andrew Cooper wrote: >=20 > On 08/09/11 09:15, Keir Fraser wrote: >> On 08/09/2011 08:39, "Jan Beulich" wrote: >> >>>>>> On 07.09.11 at 18:56, Keir Fraser wrote: >>>> On 07/09/2011 17:03, "Jan Beulich" wrote: >>>> >>>>>>>> On 07.09.11 at 17:03, Andrew Cooper = wrote: >>>>> Are you sure this is correct? I'm suspicious that this may intentiona= lly >>>>> have been the lowest priority vector... >>>> I can't see why? >>> Perhaps to get all "real" interrupts serviced first, and then do a = single, >>> consolidated run through everything that needs cleaning up? All the >>> more since smp_irq_move_cleanup_interrupt() may re-issue the >>> interrupt to the local CPU. >> Ah, hm, that's a good point. We obviously livelock if we make >> IRQ_MOVE_CLEANUP_VECTOR higher priority than the vector that >> smp_irq_move_cleanup_interrupt() is attempting to retry. >> >> Andrew: I think we have to leave this vector where it is, but you could = add >> a comment explaining why it is so, in your cleanup patchset. >> >> -- Keir=20 >=20 > Wow I was having a slow day - I was thinking that > IRQ_MOVE_CLEANUP_VECTOR was the first high priority vector. >=20 > In which case it should probably stay at its current vector, but > FIRST_DYNAMIC_VECTOR should probably be bumped up, as it is no longer a > vector dynamically allocated to guests. But that's merely cosmetic then, isn't it? Jan _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel From xen-devel-bounces@lists.xensource.com Thu Sep 08 02:34:34 2011 Return-path: Envelope-to: www-data@lists.xensource.com Delivery-date: Thu, 08 Sep 2011 02:34:34 -0700 Received: from localhost ([127.0.0.1] helo=lists.colo.xensource.com) by lists.xensource.com with esmtp (Exim 4.43) id 1R1b0E-0004Cz-8f; Thu, 08 Sep 2011 02:34:34 -0700 Received: from mail216.messagelabs.com ([85.158.143.99]) by lists.xensource.com with esmtp (Exim 4.43) id 1R1azf-0003z8-VZ for xen-devel@lists.xensource.com; Thu, 08 Sep 2011 02:34:00 -0700 X-Env-Sender: Andrew.Cooper3@citrix.com X-Msg-Ref: server-6.tower-216.messagelabs.com!1315474435!16241967!1 X-Originating-IP: [66.165.176.89] X-StarScan-Version: 6.3.6; banners=-,-,- X-VirusChecked: Checked Received: (qmail 17537 invoked from network); 8 Sep 2011 09:33:56 -0000 Received: from smtp.citrix.com (HELO SMTP.CITRIX.COM) (66.165.176.89) by server-6.tower-216.messagelabs.com with RC4-SHA encrypted SMTP; 8 Sep 2011 09:33:56 -0000 X-IronPort-AV: E=Sophos;i="4.68,349,1312171200"; d="scan'208";a="16788681" Received: from ftlpmailmx01.citrite.net ([10.13.107.65]) by FTLPIPO01.CITRIX.COM with ESMTP/TLS/RC4-MD5; 08 Sep 2011 05:33:55 -0400 Received: from [10.80.2.18] (10.80.2.18) by FTLPMAILMX01.citrite.net (10.13.107.65) with Microsoft SMTP Server id 8.3.137.0; Thu, 8 Sep 2011 05:33:55 -0400 Message-ID: <4E688C01.8050005@citrix.com> Date: Thu, 8 Sep 2011 10:33:53 +0100 From: Andrew Cooper User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.2.21) Gecko/20110831 Lightning/1.0b2 Thunderbird/3.1.13 MIME-Version: 1.0 To: Jan Beulich Subject: Re: [Xen-devel] [PATCH] IRQ: Group IRQ_MOVE_CLEANUP_VECTOR with other hypervisor IPIs References: <4E6886A3.3060402@citrix.com> <4E68A5120200007800055400@nat28.tlf.novell.com> In-Reply-To: <4E68A5120200007800055400@nat28.tlf.novell.com> Content-Type: text/plain; charset="ISO-8859-1" Content-Transfer-Encoding: 7bit Cc: "xen-devel@lists.xensource.com" , Keir Fraser , "xiantao.zhang@intel.com" X-BeenThere: xen-devel@lists.xensource.com X-Mailman-Version: 2.1.5 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xensource.com Errors-To: xen-devel-bounces@lists.xensource.com On 08/09/11 10:20, Jan Beulich wrote: >>>> On 08.09.11 at 11:10, Andrew Cooper wrote: >> On 08/09/11 09:15, Keir Fraser wrote: >>> On 08/09/2011 08:39, "Jan Beulich" wrote: >>> >>>>>>> On 07.09.11 at 18:56, Keir Fraser wrote: >>>>> On 07/09/2011 17:03, "Jan Beulich" wrote: >>>>> >>>>>>>>> On 07.09.11 at 17:03, Andrew Cooper wrote: >>>>>> Are you sure this is correct? I'm suspicious that this may intentionally >>>>>> have been the lowest priority vector... >>>>> I can't see why? >>>> Perhaps to get all "real" interrupts serviced first, and then do a single, >>>> consolidated run through everything that needs cleaning up? All the >>>> more since smp_irq_move_cleanup_interrupt() may re-issue the >>>> interrupt to the local CPU. >>> Ah, hm, that's a good point. We obviously livelock if we make >>> IRQ_MOVE_CLEANUP_VECTOR higher priority than the vector that >>> smp_irq_move_cleanup_interrupt() is attempting to retry. >>> >>> Andrew: I think we have to leave this vector where it is, but you could add >>> a comment explaining why it is so, in your cleanup patchset. >>> >>> -- Keir >> Wow I was having a slow day - I was thinking that >> IRQ_MOVE_CLEANUP_VECTOR was the first high priority vector. >> >> In which case it should probably stay at its current vector, but >> FIRST_DYNAMIC_VECTOR should probably be bumped up, as it is no longer a >> vector dynamically allocated to guests. > But that's merely cosmetic then, isn't it? > > Jan Yes and No. Changing NR_DYNAMIC_VECTORS removes an entry from the pending EOI stack, and alters an assert in __do_IRQ_guest(), both of which are sensible things to do. Having said that, 0x80 and 0x82 are right in the middle of the dynamic vector region, and moving them out is not really something which should be done. (It also occurs to me that now we assign randomly in the dynamic vector region, it is pot luck as to whether you MSI is going to pre-empt a hypercall or not. I don't know if this matters particularly, however) -- Andrew Cooper - Dom0 Kernel Engineer, Citrix XenServer T: +44 (0)1223 225 900, http://www.citrix.com _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel From xen-devel-bounces@lists.xensource.com Thu Sep 08 02:48:13 2011 Return-path: Envelope-to: www-data@lists.xensource.com Delivery-date: Thu, 08 Sep 2011 02:48:13 -0700 Received: from localhost ([127.0.0.1] helo=lists.colo.xensource.com) by lists.xensource.com with esmtp (Exim 4.43) id 1R1bDR-0005Vh-Ci; Thu, 08 Sep 2011 02:48:13 -0700 Received: from mail216.messagelabs.com ([85.158.143.99]) by lists.xensource.com with esmtp (Exim 4.43) id 1R1bD1-0005JW-4J for xen-devel@lists.xensource.com; Thu, 08 Sep 2011 02:47:47 -0700 X-Env-Sender: JBeulich@suse.com X-Msg-Ref: server-12.tower-216.messagelabs.com!1315475263!11771115!1 X-Originating-IP: [130.57.49.28] X-StarScan-Version: 6.3.6; banners=-,-,- X-VirusChecked: Checked Received: (qmail 12886 invoked from network); 8 Sep 2011 09:47:44 -0000 Received: from nat28.tlf.novell.com (HELO nat28.tlf.novell.com) (130.57.49.28) by server-12.tower-216.messagelabs.com with DHE-RSA-AES256-SHA encrypted SMTP; 8 Sep 2011 09:47:44 -0000 Received: from EMEA1-MTA by nat28.tlf.novell.com with Novell_GroupWise; Thu, 08 Sep 2011 10:48:10 +0100 Message-Id: <4E68AB740200007800055423@nat28.tlf.novell.com> X-Mailer: Novell GroupWise Internet Agent 8.0.1 Date: Thu, 08 Sep 2011 10:48:04 +0100 From: "Jan Beulich" To: "Andrew Cooper" Subject: Re: [Xen-devel] [PATCH] IRQ: Group IRQ_MOVE_CLEANUP_VECTOR with other hypervisor IPIs References: <4E6886A3.3060402@citrix.com> <4E68A5120200007800055400@nat28.tlf.novell.com> <4E688C01.8050005@citrix.com> In-Reply-To: <4E688C01.8050005@citrix.com> Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: quoted-printable Content-Disposition: inline Cc: "xen-devel@lists.xensource.com" , Keir Fraser , "xiantao.zhang@intel.com" X-BeenThere: xen-devel@lists.xensource.com X-Mailman-Version: 2.1.5 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xensource.com Errors-To: xen-devel-bounces@lists.xensource.com >>> On 08.09.11 at 11:33, Andrew Cooper wrote: > Having said that, 0x80 and 0x82 are right in the middle of the dynamic > vector region, and moving them out is not really something which should > be done. >=20 > (It also occurs to me that now we assign randomly in the dynamic vector > region, it is pot luck as to whether you MSI is going to pre-empt a > hypercall or not. I don't know if this matters particularly, however) No - these don't go through the LAPIC, and hence aren't subject to prioritization there. Jan _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel From xen-devel-bounces@lists.xensource.com Thu Sep 08 03:00:08 2011 Return-path: Envelope-to: www-data@lists.xensource.com Delivery-date: Thu, 08 Sep 2011 03:00:08 -0700 Received: from localhost ([127.0.0.1] helo=lists.colo.xensource.com) by lists.xensource.com with esmtp (Exim 4.43) id 1R1bOw-00067Q-SB; Thu, 08 Sep 2011 03:00:07 -0700 Received: from mail21.messagelabs.com ([85.158.143.35]) by lists.xensource.com with esmtp (Exim 4.43) id 1R1bMI-0005sY-UE for xen-devel@lists.xensource.com; Thu, 08 Sep 2011 02:57:24 -0700 X-Env-Sender: olaf@aepfle.de X-Msg-Ref: server-15.tower-21.messagelabs.com!1315475840!49793754!1 X-Originating-IP: [81.169.146.162] X-StarScan-Version: 6.3.6; banners=-,-,- X-VirusChecked: Checked Received: (qmail 30129 invoked from network); 8 Sep 2011 09:57:20 -0000 Received: from mo-p00-ob.rzone.de (HELO mo-p00-ob.rzone.de) (81.169.146.162) by server-15.tower-21.messagelabs.com with EDH-RSA-DES-CBC3-SHA encrypted SMTP; 8 Sep 2011 09:57:20 -0000 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; t=1315475839; l=26431; s=domk; d=aepfle.de; h=To:From:Date:References:In-Reply-To:Subject: Content-Transfer-Encoding:MIME-Version:Content-Type:X-RZG-CLASS-ID: X-RZG-AUTH; bh=azZ/M+Q71QLoSInTpHMpz/D38Ng=; b=Gd4NIxfakQeHpywNwPFCSldyaGd5xU/0hHxu8g3ZXRvG3dQ/IU6mntbrEB8T0pPybBk IOQMWQ5jlYaRhmjeeWt95wubiDxv/etLE63pPOuxtRJ2sFmjuMCtnyie69KyCnz8IGA3U r8E+miYFVSRmZj5G1I2r/mLp14tPuHTsXTQ= X-RZG-AUTH: :P2EQZWCpfu+qG7CngxMFH1J+zrwiavkK6tmQaLfmztM8TOFPjzIQEqmbbQ== X-RZG-CLASS-ID: mo00 Received: from probook.site (dslb-088-065-111-140.pools.arcor-ip.net [88.65.111.140]) by smtp.strato.de (klopstock mo8) (RZmta 26.6) with (EDH-RSA-DES-CBC3-SHA encrypted) ESMTPA id f01bcdn889ppbC for ; Thu, 8 Sep 2011 11:57:10 +0200 (MEST) Received: from probook.site (localhost [IPv6:::1]) by probook.site (Postfix) with ESMTP id 5C74318B66 for ; Thu, 8 Sep 2011 11:57:09 +0200 (CEST) Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Mercurial-Node: ce8a9eaca04aad17dacd5a8850f4ed88f92bd37a Message-Id: In-Reply-To: References: User-Agent: Mercurial-patchbomb/1.7.5 Date: Thu, 08 Sep 2011 11:57:10 +0200 From: Olaf Hering To: xen-devel@lists.xensource.com Subject: [Xen-devel] [PATCH 2 of 2] mem_event: use different ringbuffers for share, paging and access X-BeenThere: xen-devel@lists.xensource.com X-Mailman-Version: 2.1.5 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xensource.com Errors-To: xen-devel-bounces@lists.xensource.com # HG changeset patch # User Olaf Hering # Date 1315475748 -7200 # Node ID ce8a9eaca04aad17dacd5a8850f4ed88f92bd37a # Parent 95b5a9b92e1634cec7ade3ca2a894037181e8193 mem_event: use different ringbuffers for share, paging and access Up to now a single ring buffer was used for mem_share, xenpaging and xen-access. Each helper would have to cooperate and pull only its own requests from the ring. Unfortunately this was not implemented. And even if it was, it would make the whole concept fragile because a crash or early exit of one helper would stall the others. What happend up to now is that active xenpaging + memory_sharing would push memsharing requests in the buffer. xenpaging is not prepared for such requests. This patch creates an independet ring buffer for mem_share, xenpaging and xen-access and adds also new functions to enable xenpaging and xen-access. The xc_mem_event_enable/xc_mem_event_disable functions will be removed. The various XEN_DOMCTL_MEM_EVENT_* macros were cleaned up. Due to the removal the API changed, so the SONAME will be changed too. v2: - check if ring buffer is initialized before calling mem_access_domctl/mem_paging_domctl Signed-off-by: Olaf Hering diff -r 95b5a9b92e16 -r ce8a9eaca04a tools/libxc/Makefile --- a/tools/libxc/Makefile +++ b/tools/libxc/Makefile @@ -1,7 +1,7 @@ XEN_ROOT = $(CURDIR)/../.. include $(XEN_ROOT)/tools/Rules.mk -MAJOR = 4.0 +MAJOR = 4.2 MINOR = 0 CTRL_SRCS-y := diff -r 95b5a9b92e16 -r ce8a9eaca04a tools/libxc/xc_mem_access.c --- a/tools/libxc/xc_mem_access.c +++ b/tools/libxc/xc_mem_access.c @@ -24,12 +24,29 @@ #include "xc_private.h" +int xc_mem_access_enable(xc_interface *xch, domid_t domain_id, + void *shared_page, void *ring_page) +{ + return xc_mem_event_control(xch, domain_id, + XEN_DOMCTL_MEM_EVENT_OP_ACCESS_ENABLE, + XEN_DOMCTL_MEM_EVENT_OP_ACCESS, + shared_page, ring_page, INVALID_MFN); +} + +int xc_mem_access_disable(xc_interface *xch, domid_t domain_id) +{ + return xc_mem_event_control(xch, domain_id, + XEN_DOMCTL_MEM_EVENT_OP_ACCESS_DISABLE, + XEN_DOMCTL_MEM_EVENT_OP_ACCESS, + NULL, NULL, INVALID_MFN); +} + int xc_mem_access_resume(xc_interface *xch, domid_t domain_id, unsigned long gfn) { return xc_mem_event_control(xch, domain_id, XEN_DOMCTL_MEM_EVENT_OP_ACCESS_RESUME, - XEN_DOMCTL_MEM_EVENT_OP_ACCESS, NULL, NULL, - gfn); + XEN_DOMCTL_MEM_EVENT_OP_ACCESS, + NULL, NULL, gfn); } /* diff -r 95b5a9b92e16 -r ce8a9eaca04a tools/libxc/xc_mem_event.c --- a/tools/libxc/xc_mem_event.c +++ b/tools/libxc/xc_mem_event.c @@ -42,18 +42,3 @@ int xc_mem_event_control(xc_interface *x return do_domctl(xch, &domctl); } -int xc_mem_event_enable(xc_interface *xch, domid_t domain_id, - void *shared_page, void *ring_page) -{ - return xc_mem_event_control(xch, domain_id, - XEN_DOMCTL_MEM_EVENT_OP_ENABLE, 0, - shared_page, ring_page, INVALID_MFN); -} - -int xc_mem_event_disable(xc_interface *xch, domid_t domain_id) -{ - return xc_mem_event_control(xch, domain_id, - XEN_DOMCTL_MEM_EVENT_OP_DISABLE, 0, - NULL, NULL, INVALID_MFN); -} - diff -r 95b5a9b92e16 -r ce8a9eaca04a tools/libxc/xc_mem_paging.c --- a/tools/libxc/xc_mem_paging.c +++ b/tools/libxc/xc_mem_paging.c @@ -24,36 +24,53 @@ #include "xc_private.h" +int xc_mem_paging_enable(xc_interface *xch, domid_t domain_id, + void *shared_page, void *ring_page) +{ + return xc_mem_event_control(xch, domain_id, + XEN_DOMCTL_MEM_EVENT_OP_PAGING_ENABLE, + XEN_DOMCTL_MEM_EVENT_OP_PAGING, + shared_page, ring_page, INVALID_MFN); +} + +int xc_mem_paging_disable(xc_interface *xch, domid_t domain_id) +{ + return xc_mem_event_control(xch, domain_id, + XEN_DOMCTL_MEM_EVENT_OP_PAGING_DISABLE, + XEN_DOMCTL_MEM_EVENT_OP_PAGING, + NULL, NULL, INVALID_MFN); +} + int xc_mem_paging_nominate(xc_interface *xch, domid_t domain_id, unsigned long gfn) { return xc_mem_event_control(xch, domain_id, XEN_DOMCTL_MEM_EVENT_OP_PAGING_NOMINATE, - XEN_DOMCTL_MEM_EVENT_OP_PAGING, NULL, NULL, - gfn); + XEN_DOMCTL_MEM_EVENT_OP_PAGING, + NULL, NULL, gfn); } int xc_mem_paging_evict(xc_interface *xch, domid_t domain_id, unsigned long gfn) { return xc_mem_event_control(xch, domain_id, XEN_DOMCTL_MEM_EVENT_OP_PAGING_EVICT, - XEN_DOMCTL_MEM_EVENT_OP_PAGING, NULL, NULL, - gfn); + XEN_DOMCTL_MEM_EVENT_OP_PAGING, + NULL, NULL, gfn); } int xc_mem_paging_prep(xc_interface *xch, domid_t domain_id, unsigned long gfn) { return xc_mem_event_control(xch, domain_id, XEN_DOMCTL_MEM_EVENT_OP_PAGING_PREP, - XEN_DOMCTL_MEM_EVENT_OP_PAGING, NULL, NULL, - gfn); + XEN_DOMCTL_MEM_EVENT_OP_PAGING, + NULL, NULL, gfn); } int xc_mem_paging_resume(xc_interface *xch, domid_t domain_id, unsigned long gfn) { return xc_mem_event_control(xch, domain_id, XEN_DOMCTL_MEM_EVENT_OP_PAGING_RESUME, - XEN_DOMCTL_MEM_EVENT_OP_PAGING, NULL, NULL, - gfn); + XEN_DOMCTL_MEM_EVENT_OP_PAGING, + NULL, NULL, gfn); } diff -r 95b5a9b92e16 -r ce8a9eaca04a tools/libxc/xc_memshr.c --- a/tools/libxc/xc_memshr.c +++ b/tools/libxc/xc_memshr.c @@ -36,7 +36,7 @@ int xc_memshr_control(xc_interface *xch, domctl.interface_version = XEN_DOMCTL_INTERFACE_VERSION; domctl.domain = (domid_t)domid; op = &(domctl.u.mem_sharing_op); - op->op = XEN_DOMCTL_MEM_SHARING_OP_CONTROL; + op->op = XEN_DOMCTL_MEM_EVENT_OP_SHARING_CONTROL; op->u.enable = enable; return do_domctl(xch, &domctl); @@ -55,7 +55,7 @@ int xc_memshr_nominate_gfn(xc_interface domctl.interface_version = XEN_DOMCTL_INTERFACE_VERSION; domctl.domain = (domid_t)domid; op = &(domctl.u.mem_sharing_op); - op->op = XEN_DOMCTL_MEM_SHARING_OP_NOMINATE_GFN; + op->op = XEN_DOMCTL_MEM_EVENT_OP_SHARING_NOMINATE_GFN; op->u.nominate.u.gfn = gfn; ret = do_domctl(xch, &domctl); @@ -77,7 +77,7 @@ int xc_memshr_nominate_gref(xc_interface domctl.interface_version = XEN_DOMCTL_INTERFACE_VERSION; domctl.domain = (domid_t)domid; op = &(domctl.u.mem_sharing_op); - op->op = XEN_DOMCTL_MEM_SHARING_OP_NOMINATE_GREF; + op->op = XEN_DOMCTL_MEM_EVENT_OP_SHARING_NOMINATE_GREF; op->u.nominate.u.grant_ref = gref; ret = do_domctl(xch, &domctl); @@ -97,7 +97,7 @@ int xc_memshr_share(xc_interface *xch, domctl.interface_version = XEN_DOMCTL_INTERFACE_VERSION; domctl.domain = 0; op = &(domctl.u.mem_sharing_op); - op->op = XEN_DOMCTL_MEM_SHARING_OP_SHARE; + op->op = XEN_DOMCTL_MEM_EVENT_OP_SHARING_SHARE; op->u.share.source_handle = source_handle; op->u.share.client_handle = client_handle; @@ -114,7 +114,7 @@ int xc_memshr_domain_resume(xc_interface domctl.interface_version = XEN_DOMCTL_INTERFACE_VERSION; domctl.domain = (domid_t)domid; op = &(domctl.u.mem_sharing_op); - op->op = XEN_DOMCTL_MEM_SHARING_OP_RESUME; + op->op = XEN_DOMCTL_MEM_EVENT_OP_SHARING_RESUME; return do_domctl(xch, &domctl); } @@ -130,7 +130,7 @@ int xc_memshr_debug_gfn(xc_interface *xc domctl.interface_version = XEN_DOMCTL_INTERFACE_VERSION; domctl.domain = (domid_t)domid; op = &(domctl.u.mem_sharing_op); - op->op = XEN_DOMCTL_MEM_SHARING_OP_DEBUG_GFN; + op->op = XEN_DOMCTL_MEM_EVENT_OP_SHARING_DEBUG_GFN; op->u.debug.u.gfn = gfn; return do_domctl(xch, &domctl); @@ -147,7 +147,7 @@ int xc_memshr_debug_mfn(xc_interface *xc domctl.interface_version = XEN_DOMCTL_INTERFACE_VERSION; domctl.domain = (domid_t)domid; op = &(domctl.u.mem_sharing_op); - op->op = XEN_DOMCTL_MEM_SHARING_OP_DEBUG_MFN; + op->op = XEN_DOMCTL_MEM_EVENT_OP_SHARING_DEBUG_MFN; op->u.debug.u.mfn = mfn; return do_domctl(xch, &domctl); @@ -164,7 +164,7 @@ int xc_memshr_debug_gref(xc_interface *x domctl.interface_version = XEN_DOMCTL_INTERFACE_VERSION; domctl.domain = (domid_t)domid; op = &(domctl.u.mem_sharing_op); - op->op = XEN_DOMCTL_MEM_SHARING_OP_DEBUG_GREF; + op->op = XEN_DOMCTL_MEM_EVENT_OP_SHARING_DEBUG_GREF; op->u.debug.u.gref = gref; return do_domctl(xch, &domctl); diff -r 95b5a9b92e16 -r ce8a9eaca04a tools/libxc/xenctrl.h --- a/tools/libxc/xenctrl.h +++ b/tools/libxc/xenctrl.h @@ -1758,16 +1758,19 @@ int xc_mem_event_control(xc_interface *x unsigned int mode, void *shared_page, void *ring_page, unsigned long gfn); -int xc_mem_event_enable(xc_interface *xch, domid_t domain_id, +int xc_mem_paging_enable(xc_interface *xch, domid_t domain_id, void *shared_page, void *ring_page); -int xc_mem_event_disable(xc_interface *xch, domid_t domain_id); - +int xc_mem_paging_disable(xc_interface *xch, domid_t domain_id); int xc_mem_paging_nominate(xc_interface *xch, domid_t domain_id, unsigned long gfn); int xc_mem_paging_evict(xc_interface *xch, domid_t domain_id, unsigned long gfn); int xc_mem_paging_prep(xc_interface *xch, domid_t domain_id, unsigned long gfn); int xc_mem_paging_resume(xc_interface *xch, domid_t domain_id, unsigned long gfn); + +int xc_mem_access_enable(xc_interface *xch, domid_t domain_id, + void *shared_page, void *ring_page); +int xc_mem_access_disable(xc_interface *xch, domid_t domain_id); int xc_mem_access_resume(xc_interface *xch, domid_t domain_id, unsigned long gfn); diff -r 95b5a9b92e16 -r ce8a9eaca04a tools/tests/xen-access/xen-access.c --- a/tools/tests/xen-access/xen-access.c +++ b/tools/tests/xen-access/xen-access.c @@ -241,7 +241,7 @@ xenaccess_t *xenaccess_init(xc_interface mem_event_ring_lock_init(&xenaccess->mem_event); /* Initialise Xen */ - rc = xc_mem_event_enable(xenaccess->xc_handle, xenaccess->mem_event.domain_id, + rc = xc_mem_access_enable(xenaccess->xc_handle, xenaccess->mem_event.domain_id, xenaccess->mem_event.shared_page, xenaccess->mem_event.ring_page); if ( rc != 0 ) @@ -351,7 +351,7 @@ int xenaccess_teardown(xc_interface *xch return 0; /* Tear down domain xenaccess in Xen */ - rc = xc_mem_event_disable(xenaccess->xc_handle, xenaccess->mem_event.domain_id); + rc = xc_mem_access_disable(xenaccess->xc_handle, xenaccess->mem_event.domain_id); if ( rc != 0 ) { ERROR("Error tearing down domain xenaccess in xen"); diff -r 95b5a9b92e16 -r ce8a9eaca04a tools/xenpaging/xenpaging.c --- a/tools/xenpaging/xenpaging.c +++ b/tools/xenpaging/xenpaging.c @@ -234,7 +234,7 @@ static xenpaging_t *xenpaging_init(domid PAGE_SIZE); /* Initialise Xen */ - rc = xc_mem_event_enable(xch, paging->mem_event.domain_id, + rc = xc_mem_paging_enable(xch, paging->mem_event.domain_id, paging->mem_event.shared_page, paging->mem_event.ring_page); if ( rc != 0 ) @@ -353,7 +353,7 @@ static int xenpaging_teardown(xenpaging_ xch = paging->xc_handle; paging->xc_handle = NULL; /* Tear down domain paging in Xen */ - rc = xc_mem_event_disable(xch, paging->mem_event.domain_id); + rc = xc_mem_paging_disable(xch, paging->mem_event.domain_id); if ( rc != 0 ) { ERROR("Error tearing down domain paging in xen"); diff -r 95b5a9b92e16 -r ce8a9eaca04a xen/arch/ia64/xen/dom0_ops.c --- a/xen/arch/ia64/xen/dom0_ops.c +++ b/xen/arch/ia64/xen/dom0_ops.c @@ -688,7 +688,7 @@ long arch_do_domctl(xen_domctl_t *op, XE switch(mec->op) { - case XEN_DOMCTL_MEM_SHARING_OP_CONTROL: + case XEN_DOMCTL_MEM_EVENT_OP_SHARING_CONTROL: { if (mec->u.enable) { ret = -EINVAL; /* not implemented */ diff -r 95b5a9b92e16 -r ce8a9eaca04a xen/arch/x86/hvm/hvm.c --- a/xen/arch/x86/hvm/hvm.c +++ b/xen/arch/x86/hvm/hvm.c @@ -4025,7 +4025,7 @@ static int hvm_memory_event_traps(long p if ( (p & HVMPME_onchangeonly) && (value == old) ) return 1; - rc = mem_event_check_ring(d, &d->mem_event); + rc = mem_event_check_ring(d, &d->mem_access); if ( rc ) return rc; @@ -4048,7 +4048,7 @@ static int hvm_memory_event_traps(long p req.gla_valid = 1; } - mem_event_put_request(d, &d->mem_event, &req); + mem_event_put_request(d, &d->mem_access, &req); return 1; } diff -r 95b5a9b92e16 -r ce8a9eaca04a xen/arch/x86/mm/mem_event.c --- a/xen/arch/x86/mm/mem_event.c +++ b/xen/arch/x86/mm/mem_event.c @@ -37,24 +37,52 @@ #define mem_event_ring_lock(_med) spin_lock(&(_med)->ring_lock) #define mem_event_ring_unlock(_med) spin_unlock(&(_med)->ring_lock) -static int mem_event_enable(struct domain *d, struct mem_event_domain *med, mfn_t ring_mfn, mfn_t shared_mfn) +static int mem_event_enable(struct domain *d, + xen_domctl_mem_event_op_t *mec, + struct mem_event_domain *med) { int rc; + struct domain *dom_mem_event = current->domain; + struct vcpu *v = current; + unsigned long ring_addr = mec->ring_addr; + unsigned long shared_addr = mec->shared_addr; + l1_pgentry_t l1e; + unsigned long gfn; + p2m_type_t p2mt; + mfn_t ring_mfn; + mfn_t shared_mfn; + + /* Only one helper at a time. If the helper crashed, + * the ring is in an undefined state and so is the guest. + */ + if ( med->ring_page ) + return -EBUSY; + + /* Get MFN of ring page */ + guest_get_eff_l1e(v, ring_addr, &l1e); + gfn = l1e_get_pfn(l1e); + ring_mfn = gfn_to_mfn(dom_mem_event, gfn, &p2mt); + + if ( unlikely(!mfn_valid(mfn_x(ring_mfn))) ) + return -EINVAL; + + /* Get MFN of shared page */ + guest_get_eff_l1e(v, shared_addr, &l1e); + gfn = l1e_get_pfn(l1e); + shared_mfn = gfn_to_mfn(dom_mem_event, gfn, &p2mt); + + if ( unlikely(!mfn_valid(mfn_x(shared_mfn))) ) + return -EINVAL; /* Map ring and shared pages */ med->ring_page = map_domain_page(mfn_x(ring_mfn)); - if ( med->ring_page == NULL ) - goto err; - med->shared_page = map_domain_page(mfn_x(shared_mfn)); - if ( med->shared_page == NULL ) - goto err_ring; /* Allocate event channel */ rc = alloc_unbound_xen_event_channel(d->vcpu[0], current->domain->domain_id); if ( rc < 0 ) - goto err_shared; + goto err; ((mem_event_shared_page_t *)med->shared_page)->port = rc; med->xen_port = rc; @@ -71,14 +99,14 @@ static int mem_event_enable(struct domai return 0; - err_shared: + err: unmap_domain_page(med->shared_page); med->shared_page = NULL; - err_ring: + unmap_domain_page(med->ring_page); med->ring_page = NULL; - err: - return 1; + + return rc; } static int mem_event_disable(struct mem_event_domain *med) @@ -220,86 +248,79 @@ int mem_event_domctl(struct domain *d, x rc = -ENOSYS; - switch ( mec-> mode ) + switch ( mec->mode ) { - case 0: + case XEN_DOMCTL_MEM_EVENT_OP_PAGING: { + struct mem_event_domain *med = &d->mem_paging; + rc = -ENODEV; + /* Only HAP is supported */ + if ( !hap_enabled(d) ) + break; + + /* Currently only EPT is supported */ + if ( boot_cpu_data.x86_vendor != X86_VENDOR_INTEL ) + break; + switch( mec->op ) { - case XEN_DOMCTL_MEM_EVENT_OP_ENABLE: + case XEN_DOMCTL_MEM_EVENT_OP_PAGING_ENABLE: { - struct domain *dom_mem_event = current->domain; - struct vcpu *v = current; - struct mem_event_domain *med = &d->mem_event; - unsigned long ring_addr = mec->ring_addr; - unsigned long shared_addr = mec->shared_addr; - l1_pgentry_t l1e; - unsigned long gfn; - p2m_type_t p2mt; - mfn_t ring_mfn; - mfn_t shared_mfn; - - /* Only one xenpaging at a time. If xenpaging crashed, - * the cache is in an undefined state and so is the guest - */ - rc = -EBUSY; - if ( med->ring_page ) - break; - - /* Currently only EPT is supported */ - rc = -ENODEV; - if ( !(hap_enabled(d) && - (boot_cpu_data.x86_vendor == X86_VENDOR_INTEL)) ) - break; - - /* Get MFN of ring page */ - guest_get_eff_l1e(v, ring_addr, &l1e); - gfn = l1e_get_pfn(l1e); - ring_mfn = gfn_to_mfn(dom_mem_event, gfn, &p2mt); - - rc = -EINVAL; - if ( unlikely(!mfn_valid(mfn_x(ring_mfn))) ) - break; - - /* Get MFN of shared page */ - guest_get_eff_l1e(v, shared_addr, &l1e); - gfn = l1e_get_pfn(l1e); - shared_mfn = gfn_to_mfn(dom_mem_event, gfn, &p2mt); - - rc = -EINVAL; - if ( unlikely(!mfn_valid(mfn_x(shared_mfn))) ) - break; - - rc = -EINVAL; - if ( mem_event_enable(d, med, ring_mfn, shared_mfn) != 0 ) - break; - - rc = 0; + rc = mem_event_enable(d, mec, med); } break; - case XEN_DOMCTL_MEM_EVENT_OP_DISABLE: + case XEN_DOMCTL_MEM_EVENT_OP_PAGING_DISABLE: { - rc = mem_event_disable(&d->mem_event); + rc = mem_event_disable(med); } break; default: - rc = -ENOSYS; - break; + { + if ( med->ring_page ) + rc = mem_paging_domctl(d, mec, u_domctl); } break; + } } - case XEN_DOMCTL_MEM_EVENT_OP_PAGING: - { - rc = mem_paging_domctl(d, mec, u_domctl); - break; - } + break; + case XEN_DOMCTL_MEM_EVENT_OP_ACCESS: { - rc = mem_access_domctl(d, mec, u_domctl); + struct mem_event_domain *med = &d->mem_access; + rc = -ENODEV; + /* Only HAP is supported */ + if ( !hap_enabled(d) ) + break; + + /* Currently only EPT is supported */ + if ( boot_cpu_data.x86_vendor != X86_VENDOR_INTEL ) + break; + + switch( mec->op ) + { + case XEN_DOMCTL_MEM_EVENT_OP_ACCESS_ENABLE: + { + rc = mem_event_enable(d, mec, med); + } break; + + case XEN_DOMCTL_MEM_EVENT_OP_ACCESS_DISABLE: + { + rc = mem_event_disable(&d->mem_access); + } + break; + + default: + { + if ( med->ring_page ) + rc = mem_access_domctl(d, mec, u_domctl); + } + break; + } } + break; } return rc; diff -r 95b5a9b92e16 -r ce8a9eaca04a xen/arch/x86/mm/mem_paging.c --- a/xen/arch/x86/mm/mem_paging.c +++ b/xen/arch/x86/mm/mem_paging.c @@ -28,10 +28,6 @@ int mem_paging_domctl(struct domain *d, xen_domctl_mem_event_op_t *mec, XEN_GUEST_HANDLE(void) u_domctl) { - /* Only HAP is supported */ - if ( !hap_enabled(d) ) - return -ENODEV; - switch( mec->op ) { case XEN_DOMCTL_MEM_EVENT_OP_PAGING_NOMINATE: diff -r 95b5a9b92e16 -r ce8a9eaca04a xen/arch/x86/mm/mem_sharing.c --- a/xen/arch/x86/mm/mem_sharing.c +++ b/xen/arch/x86/mm/mem_sharing.c @@ -281,12 +281,12 @@ static struct page_info* mem_sharing_all vcpu_pause_nosync(v); req.flags |= MEM_EVENT_FLAG_VCPU_PAUSED; - if(mem_event_check_ring(d, &d->mem_event)) return page; + if(mem_event_check_ring(d, &d->mem_share)) return page; req.gfn = gfn; req.p2mt = p2m_ram_shared; req.vcpu_id = v->vcpu_id; - mem_event_put_request(d, &d->mem_event, &req); + mem_event_put_request(d, &d->mem_share, &req); return page; } @@ -301,7 +301,7 @@ int mem_sharing_sharing_resume(struct do mem_event_response_t rsp; /* Get request off the ring */ - mem_event_get_response(&d->mem_event, &rsp); + mem_event_get_response(&d->mem_share, &rsp); /* Unpause domain/vcpu */ if( rsp.flags & MEM_EVENT_FLAG_VCPU_PAUSED ) @@ -697,14 +697,14 @@ int mem_sharing_domctl(struct domain *d, switch(mec->op) { - case XEN_DOMCTL_MEM_SHARING_OP_CONTROL: + case XEN_DOMCTL_MEM_EVENT_OP_SHARING_CONTROL: { d->arch.hvm_domain.mem_sharing_enabled = mec->u.enable; rc = 0; } break; - case XEN_DOMCTL_MEM_SHARING_OP_NOMINATE_GFN: + case XEN_DOMCTL_MEM_EVENT_OP_SHARING_NOMINATE_GFN: { unsigned long gfn = mec->u.nominate.u.gfn; shr_handle_t handle; @@ -715,7 +715,7 @@ int mem_sharing_domctl(struct domain *d, } break; - case XEN_DOMCTL_MEM_SHARING_OP_NOMINATE_GREF: + case XEN_DOMCTL_MEM_EVENT_OP_SHARING_NOMINATE_GREF: { grant_ref_t gref = mec->u.nominate.u.grant_ref; unsigned long gfn; @@ -730,7 +730,7 @@ int mem_sharing_domctl(struct domain *d, } break; - case XEN_DOMCTL_MEM_SHARING_OP_SHARE: + case XEN_DOMCTL_MEM_EVENT_OP_SHARING_SHARE: { shr_handle_t sh = mec->u.share.source_handle; shr_handle_t ch = mec->u.share.client_handle; @@ -738,7 +738,7 @@ int mem_sharing_domctl(struct domain *d, } break; - case XEN_DOMCTL_MEM_SHARING_OP_RESUME: + case XEN_DOMCTL_MEM_EVENT_OP_SHARING_RESUME: { if(!mem_sharing_enabled(d)) return -EINVAL; @@ -746,21 +746,21 @@ int mem_sharing_domctl(struct domain *d, } break; - case XEN_DOMCTL_MEM_SHARING_OP_DEBUG_GFN: + case XEN_DOMCTL_MEM_EVENT_OP_SHARING_DEBUG_GFN: { unsigned long gfn = mec->u.debug.u.gfn; rc = mem_sharing_debug_gfn(d, gfn); } break; - case XEN_DOMCTL_MEM_SHARING_OP_DEBUG_MFN: + case XEN_DOMCTL_MEM_EVENT_OP_SHARING_DEBUG_MFN: { unsigned long mfn = mec->u.debug.u.mfn; rc = mem_sharing_debug_mfn(mfn); } break; - case XEN_DOMCTL_MEM_SHARING_OP_DEBUG_GREF: + case XEN_DOMCTL_MEM_EVENT_OP_SHARING_DEBUG_GREF: { grant_ref_t gref = mec->u.debug.u.gref; rc = mem_sharing_debug_gref(d, gref); diff -r 95b5a9b92e16 -r ce8a9eaca04a xen/arch/x86/mm/p2m.c --- a/xen/arch/x86/mm/p2m.c +++ b/xen/arch/x86/mm/p2m.c @@ -755,7 +755,7 @@ void p2m_mem_paging_drop_page(struct dom mem_event_request_t req; /* Check that there's space on the ring for this request */ - if ( mem_event_check_ring(d, &d->mem_event) == 0) + if ( mem_event_check_ring(d, &d->mem_paging) == 0) { /* Send release notification to pager */ memset(&req, 0, sizeof(req)); @@ -763,7 +763,7 @@ void p2m_mem_paging_drop_page(struct dom req.gfn = gfn; req.vcpu_id = v->vcpu_id; - mem_event_put_request(d, &d->mem_event, &req); + mem_event_put_request(d, &d->mem_paging, &req); } } @@ -775,7 +775,7 @@ void p2m_mem_paging_populate(struct doma struct p2m_domain *p2m = p2m_get_hostp2m(d); /* Check that there's space on the ring for this request */ - if ( mem_event_check_ring(d, &d->mem_event) ) + if ( mem_event_check_ring(d, &d->mem_paging) ) return; memset(&req, 0, sizeof(req)); @@ -803,7 +803,7 @@ void p2m_mem_paging_populate(struct doma else if ( p2mt != p2m_ram_paging_out && p2mt != p2m_ram_paged ) { /* gfn is already on its way back and vcpu is not paused */ - mem_event_put_req_producers(&d->mem_event); + mem_event_put_req_producers(&d->mem_paging); return; } @@ -812,7 +812,7 @@ void p2m_mem_paging_populate(struct doma req.p2mt = p2mt; req.vcpu_id = v->vcpu_id; - mem_event_put_request(d, &d->mem_event, &req); + mem_event_put_request(d, &d->mem_paging, &req); } int p2m_mem_paging_prep(struct domain *d, unsigned long gfn) @@ -842,7 +842,7 @@ void p2m_mem_paging_resume(struct domain mfn_t mfn; /* Pull the response off the ring */ - mem_event_get_response(&d->mem_event, &rsp); + mem_event_get_response(&d->mem_paging, &rsp); /* Fix p2m entry if the page was not dropped */ if ( !(rsp.flags & MEM_EVENT_FLAG_DROP_PAGE) ) @@ -889,7 +889,7 @@ void p2m_mem_access_check(unsigned long p2m_unlock(p2m); /* Otherwise, check if there is a memory event listener, and send the message along */ - res = mem_event_check_ring(d, &d->mem_event); + res = mem_event_check_ring(d, &d->mem_access); if ( res < 0 ) { /* No listener */ @@ -933,7 +933,7 @@ void p2m_mem_access_check(unsigned long req.vcpu_id = v->vcpu_id; - mem_event_put_request(d, &d->mem_event, &req); + mem_event_put_request(d, &d->mem_access, &req); /* VCPU paused, mem event request sent */ } @@ -943,7 +943,7 @@ void p2m_mem_access_resume(struct p2m_do struct domain *d = p2m->domain; mem_event_response_t rsp; - mem_event_get_response(&d->mem_event, &rsp); + mem_event_get_response(&d->mem_access, &rsp); /* Unpause domain */ if ( rsp.flags & MEM_EVENT_FLAG_VCPU_PAUSED ) diff -r 95b5a9b92e16 -r ce8a9eaca04a xen/include/public/domctl.h --- a/xen/include/public/domctl.h +++ b/xen/include/public/domctl.h @@ -708,20 +708,18 @@ struct xen_domctl_gdbsx_domstatus { /* XEN_DOMCTL_mem_event_op */ -/* Add and remove memory handlers */ -#define XEN_DOMCTL_MEM_EVENT_OP_ENABLE 0 -#define XEN_DOMCTL_MEM_EVENT_OP_DISABLE 1 - /* +* Domain memory paging * Page memory in and out. */ #define XEN_DOMCTL_MEM_EVENT_OP_PAGING 1 -/* Domain memory paging */ -#define XEN_DOMCTL_MEM_EVENT_OP_PAGING_NOMINATE 0 -#define XEN_DOMCTL_MEM_EVENT_OP_PAGING_EVICT 1 -#define XEN_DOMCTL_MEM_EVENT_OP_PAGING_PREP 2 -#define XEN_DOMCTL_MEM_EVENT_OP_PAGING_RESUME 3 +#define XEN_DOMCTL_MEM_EVENT_OP_PAGING_ENABLE 0 +#define XEN_DOMCTL_MEM_EVENT_OP_PAGING_DISABLE 1 +#define XEN_DOMCTL_MEM_EVENT_OP_PAGING_NOMINATE 2 +#define XEN_DOMCTL_MEM_EVENT_OP_PAGING_EVICT 3 +#define XEN_DOMCTL_MEM_EVENT_OP_PAGING_PREP 4 +#define XEN_DOMCTL_MEM_EVENT_OP_PAGING_RESUME 5 /* * Access permissions. @@ -734,11 +732,14 @@ struct xen_domctl_gdbsx_domstatus { * ACCESS_RESUME mode for the following domctl. */ #define XEN_DOMCTL_MEM_EVENT_OP_ACCESS 2 -#define XEN_DOMCTL_MEM_EVENT_OP_ACCESS_RESUME 0 + +#define XEN_DOMCTL_MEM_EVENT_OP_ACCESS_ENABLE 0 +#define XEN_DOMCTL_MEM_EVENT_OP_ACCESS_DISABLE 1 +#define XEN_DOMCTL_MEM_EVENT_OP_ACCESS_RESUME 2 struct xen_domctl_mem_event_op { - uint32_t op; /* XEN_DOMCTL_MEM_EVENT_OP_* */ - uint32_t mode; /* XEN_DOMCTL_MEM_EVENT_ENABLE_* */ + uint32_t op; /* XEN_DOMCTL_MEM_EVENT_OP_*_* */ + uint32_t mode; /* XEN_DOMCTL_MEM_EVENT_OP_* */ /* OP_ENABLE */ uint64_aligned_t shared_addr; /* IN: Virtual address of shared page */ @@ -755,14 +756,16 @@ DEFINE_XEN_GUEST_HANDLE(xen_domctl_mem_e */ /* XEN_DOMCTL_mem_sharing_op */ -#define XEN_DOMCTL_MEM_SHARING_OP_CONTROL 0 -#define XEN_DOMCTL_MEM_SHARING_OP_NOMINATE_GFN 1 -#define XEN_DOMCTL_MEM_SHARING_OP_NOMINATE_GREF 2 -#define XEN_DOMCTL_MEM_SHARING_OP_SHARE 3 -#define XEN_DOMCTL_MEM_SHARING_OP_RESUME 4 -#define XEN_DOMCTL_MEM_SHARING_OP_DEBUG_GFN 5 -#define XEN_DOMCTL_MEM_SHARING_OP_DEBUG_MFN 6 -#define XEN_DOMCTL_MEM_SHARING_OP_DEBUG_GREF 7 +#define XEN_DOMCTL_MEM_EVENT_OP_SHARING 3 + +#define XEN_DOMCTL_MEM_EVENT_OP_SHARING_CONTROL 0 +#define XEN_DOMCTL_MEM_EVENT_OP_SHARING_NOMINATE_GFN 1 +#define XEN_DOMCTL_MEM_EVENT_OP_SHARING_NOMINATE_GREF 2 +#define XEN_DOMCTL_MEM_EVENT_OP_SHARING_SHARE 3 +#define XEN_DOMCTL_MEM_EVENT_OP_SHARING_RESUME 4 +#define XEN_DOMCTL_MEM_EVENT_OP_SHARING_DEBUG_GFN 5 +#define XEN_DOMCTL_MEM_EVENT_OP_SHARING_DEBUG_MFN 6 +#define XEN_DOMCTL_MEM_EVENT_OP_SHARING_DEBUG_GREF 7 #define XEN_DOMCTL_MEM_SHARING_S_HANDLE_INVALID (-10) #define XEN_DOMCTL_MEM_SHARING_C_HANDLE_INVALID (-9) diff -r 95b5a9b92e16 -r ce8a9eaca04a xen/include/xen/sched.h --- a/xen/include/xen/sched.h +++ b/xen/include/xen/sched.h @@ -317,8 +317,12 @@ struct domain /* Non-migratable and non-restoreable? */ bool_t disable_migrate; + /* Memory sharing support */ + struct mem_event_domain mem_share; /* Memory paging support */ - struct mem_event_domain mem_event; + struct mem_event_domain mem_paging; + /* Memory access support */ + struct mem_event_domain mem_access; /* Currently computed from union of all vcpu cpu-affinity masks. */ nodemask_t node_affinity; _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel From xen-devel-bounces@lists.xensource.com Thu Sep 08 03:04:02 2011 Return-path: Envelope-to: www-data@lists.xensource.com Delivery-date: Thu, 08 Sep 2011 03:04:03 -0700 Received: from localhost ([127.0.0.1] helo=lists.colo.xensource.com) by lists.xensource.com with esmtp (Exim 4.43) id 1R1bSk-0006XS-G2; Thu, 08 Sep 2011 03:04:02 -0700 Received: from mail216.messagelabs.com ([85.158.143.99]) by lists.xensource.com with esmtp (Exim 4.43) id 1R1bMJ-0005sa-W5 for xen-devel@lists.xensource.com; Thu, 08 Sep 2011 02:57:24 -0700 X-Env-Sender: olaf@aepfle.de X-Msg-Ref: server-3.tower-216.messagelabs.com!1315475840!16477676!1 X-Originating-IP: [81.169.146.162] X-StarScan-Version: 6.3.6; banners=-,-,- X-VirusChecked: Checked Received: (qmail 12031 invoked from network); 8 Sep 2011 09:57:21 -0000 Received: from mo-p00-ob.rzone.de (HELO mo-p00-ob.rzone.de) (81.169.146.162) by server-3.tower-216.messagelabs.com with DHE-RSA-AES256-SHA encrypted SMTP; 8 Sep 2011 09:57:21 -0000 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; t=1315475840; l=12337; s=domk; d=aepfle.de; h=To:From:Date:References:In-Reply-To:Subject: Content-Transfer-Encoding:MIME-Version:Content-Type:X-RZG-CLASS-ID: X-RZG-AUTH; bh=uubK5mji69MAtqJyEgr3j8UN5vM=; b=VCOiKCL0rMeNKoE+A/ccKWijHOvpyqvwUKS5Rubr8xLME1saP+YcOPeGc5OKptkL1j+ AbT9xwvc5wmz1l0BAU/OvFm+LYZJHfUh4k+34ZEtSepFnokZGlTIEqrSGyfw2XRprXRzz nF5FCr0CdnQ2v9Wfv3Tpsh4zDKQ+zChaqK4= X-RZG-AUTH: :P2EQZWCpfu+qG7CngxMFH1J+zrwiavkK6tmQaLfmztM8TOFPjzIQEqmbbQ== X-RZG-CLASS-ID: mo00 Received: from probook.site (dslb-088-065-111-140.pools.arcor-ip.net [88.65.111.140]) by smtp.strato.de (jimi mo25) (RZmta 26.6) with (DHE-RSA-AES256-SHA encrypted) ESMTPA id 200a92n889L8vD for ; Thu, 8 Sep 2011 11:57:09 +0200 (MEST) Received: from probook.site (localhost [IPv6:::1]) by probook.site (Postfix) with ESMTP id 2912F18B65 for ; Thu, 8 Sep 2011 11:57:09 +0200 (CEST) Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Mercurial-Node: 95b5a9b92e1634cec7ade3ca2a894037181e8193 Message-Id: <95b5a9b92e1634cec7ad.1315475829@probook.site> In-Reply-To: References: User-Agent: Mercurial-patchbomb/1.7.5 Date: Thu, 08 Sep 2011 11:57:09 +0200 From: Olaf Hering To: xen-devel@lists.xensource.com Subject: [Xen-devel] [PATCH 1 of 2] mem_event: pass mem_event_domain pointer to mem_event functions X-BeenThere: xen-devel@lists.xensource.com X-Mailman-Version: 2.1.5 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xensource.com Errors-To: xen-devel-bounces@lists.xensource.com # HG changeset patch # User Olaf Hering # Date 1315475746 -7200 # Node ID 95b5a9b92e1634cec7ade3ca2a894037181e8193 # Parent 0268e73809532a4a3ca18a075efcee3c62caf458 mem_event: pass mem_event_domain pointer to mem_event functions Pass a struct mem_event_domain pointer to the various mem_event functions. This will be used in a subsequent patch which creates different ring buffers for the memshare, xenpaging and memaccess functionality. Remove the struct domain argument from some functions. v2: - pass struct domain instead of domain_id to mem_event_check_ring() - check ring_full first because its value was just evaluated Signed-off-by: Olaf Hering diff -r 0268e7380953 -r 95b5a9b92e16 xen/arch/x86/hvm/hvm.c --- a/xen/arch/x86/hvm/hvm.c +++ b/xen/arch/x86/hvm/hvm.c @@ -4025,7 +4025,7 @@ static int hvm_memory_event_traps(long p if ( (p & HVMPME_onchangeonly) && (value == old) ) return 1; - rc = mem_event_check_ring(d); + rc = mem_event_check_ring(d, &d->mem_event); if ( rc ) return rc; @@ -4048,7 +4048,7 @@ static int hvm_memory_event_traps(long p req.gla_valid = 1; } - mem_event_put_request(d, &req); + mem_event_put_request(d, &d->mem_event, &req); return 1; } diff -r 0268e7380953 -r 95b5a9b92e16 xen/arch/x86/mm/mem_event.c --- a/xen/arch/x86/mm/mem_event.c +++ b/xen/arch/x86/mm/mem_event.c @@ -33,21 +33,21 @@ #define xen_rmb() rmb() #define xen_wmb() wmb() -#define mem_event_ring_lock_init(_d) spin_lock_init(&(_d)->mem_event.ring_lock) -#define mem_event_ring_lock(_d) spin_lock(&(_d)->mem_event.ring_lock) -#define mem_event_ring_unlock(_d) spin_unlock(&(_d)->mem_event.ring_lock) +#define mem_event_ring_lock_init(_med) spin_lock_init(&(_med)->ring_lock) +#define mem_event_ring_lock(_med) spin_lock(&(_med)->ring_lock) +#define mem_event_ring_unlock(_med) spin_unlock(&(_med)->ring_lock) -static int mem_event_enable(struct domain *d, mfn_t ring_mfn, mfn_t shared_mfn) +static int mem_event_enable(struct domain *d, struct mem_event_domain *med, mfn_t ring_mfn, mfn_t shared_mfn) { int rc; /* Map ring and shared pages */ - d->mem_event.ring_page = map_domain_page(mfn_x(ring_mfn)); - if ( d->mem_event.ring_page == NULL ) + med->ring_page = map_domain_page(mfn_x(ring_mfn)); + if ( med->ring_page == NULL ) goto err; - d->mem_event.shared_page = map_domain_page(mfn_x(shared_mfn)); - if ( d->mem_event.shared_page == NULL ) + med->shared_page = map_domain_page(mfn_x(shared_mfn)); + if ( med->shared_page == NULL ) goto err_ring; /* Allocate event channel */ @@ -56,15 +56,15 @@ static int mem_event_enable(struct domai if ( rc < 0 ) goto err_shared; - ((mem_event_shared_page_t *)d->mem_event.shared_page)->port = rc; - d->mem_event.xen_port = rc; + ((mem_event_shared_page_t *)med->shared_page)->port = rc; + med->xen_port = rc; /* Prepare ring buffer */ - FRONT_RING_INIT(&d->mem_event.front_ring, - (mem_event_sring_t *)d->mem_event.ring_page, + FRONT_RING_INIT(&med->front_ring, + (mem_event_sring_t *)med->ring_page, PAGE_SIZE); - mem_event_ring_lock_init(d); + mem_event_ring_lock_init(med); /* Wake any VCPUs paused for memory events */ mem_event_unpause_vcpus(d); @@ -72,34 +72,34 @@ static int mem_event_enable(struct domai return 0; err_shared: - unmap_domain_page(d->mem_event.shared_page); - d->mem_event.shared_page = NULL; + unmap_domain_page(med->shared_page); + med->shared_page = NULL; err_ring: - unmap_domain_page(d->mem_event.ring_page); - d->mem_event.ring_page = NULL; + unmap_domain_page(med->ring_page); + med->ring_page = NULL; err: return 1; } -static int mem_event_disable(struct domain *d) +static int mem_event_disable(struct mem_event_domain *med) { - unmap_domain_page(d->mem_event.ring_page); - d->mem_event.ring_page = NULL; + unmap_domain_page(med->ring_page); + med->ring_page = NULL; - unmap_domain_page(d->mem_event.shared_page); - d->mem_event.shared_page = NULL; + unmap_domain_page(med->shared_page); + med->shared_page = NULL; return 0; } -void mem_event_put_request(struct domain *d, mem_event_request_t *req) +void mem_event_put_request(struct domain *d, struct mem_event_domain *med, mem_event_request_t *req) { mem_event_front_ring_t *front_ring; RING_IDX req_prod; - mem_event_ring_lock(d); + mem_event_ring_lock(med); - front_ring = &d->mem_event.front_ring; + front_ring = &med->front_ring; req_prod = front_ring->req_prod_pvt; /* Copy request */ @@ -107,23 +107,23 @@ void mem_event_put_request(struct domain req_prod++; /* Update ring */ - d->mem_event.req_producers--; + med->req_producers--; front_ring->req_prod_pvt = req_prod; RING_PUSH_REQUESTS(front_ring); - mem_event_ring_unlock(d); + mem_event_ring_unlock(med); - notify_via_xen_event_channel(d, d->mem_event.xen_port); + notify_via_xen_event_channel(d, med->xen_port); } -void mem_event_get_response(struct domain *d, mem_event_response_t *rsp) +void mem_event_get_response(struct mem_event_domain *med, mem_event_response_t *rsp) { mem_event_front_ring_t *front_ring; RING_IDX rsp_cons; - mem_event_ring_lock(d); + mem_event_ring_lock(med); - front_ring = &d->mem_event.front_ring; + front_ring = &med->front_ring; rsp_cons = front_ring->rsp_cons; /* Copy response */ @@ -134,7 +134,7 @@ void mem_event_get_response(struct domai front_ring->rsp_cons = rsp_cons; front_ring->sring->rsp_event = rsp_cons + 1; - mem_event_ring_unlock(d); + mem_event_ring_unlock(med); } void mem_event_unpause_vcpus(struct domain *d) @@ -152,35 +152,35 @@ void mem_event_mark_and_pause(struct vcp vcpu_sleep_nosync(v); } -void mem_event_put_req_producers(struct domain *d) +void mem_event_put_req_producers(struct mem_event_domain *med) { - mem_event_ring_lock(d); - d->mem_event.req_producers--; - mem_event_ring_unlock(d); + mem_event_ring_lock(med); + med->req_producers--; + mem_event_ring_unlock(med); } -int mem_event_check_ring(struct domain *d) +int mem_event_check_ring(struct domain *d, struct mem_event_domain *med) { struct vcpu *curr = current; int free_requests; int ring_full = 1; - if ( !d->mem_event.ring_page ) + if ( !med->ring_page ) return -1; - mem_event_ring_lock(d); + mem_event_ring_lock(med); - free_requests = RING_FREE_REQUESTS(&d->mem_event.front_ring); - if ( d->mem_event.req_producers < free_requests ) + free_requests = RING_FREE_REQUESTS(&med->front_ring); + if ( med->req_producers < free_requests ) { - d->mem_event.req_producers++; + med->req_producers++; ring_full = 0; } - if ( (curr->domain->domain_id == d->domain_id) && ring_full ) + if ( ring_full && (curr->domain == d) ) mem_event_mark_and_pause(curr); - mem_event_ring_unlock(d); + mem_event_ring_unlock(med); return ring_full; } @@ -230,6 +230,7 @@ int mem_event_domctl(struct domain *d, x { struct domain *dom_mem_event = current->domain; struct vcpu *v = current; + struct mem_event_domain *med = &d->mem_event; unsigned long ring_addr = mec->ring_addr; unsigned long shared_addr = mec->shared_addr; l1_pgentry_t l1e; @@ -242,7 +243,7 @@ int mem_event_domctl(struct domain *d, x * the cache is in an undefined state and so is the guest */ rc = -EBUSY; - if ( d->mem_event.ring_page ) + if ( med->ring_page ) break; /* Currently only EPT is supported */ @@ -270,7 +271,7 @@ int mem_event_domctl(struct domain *d, x break; rc = -EINVAL; - if ( mem_event_enable(d, ring_mfn, shared_mfn) != 0 ) + if ( mem_event_enable(d, med, ring_mfn, shared_mfn) != 0 ) break; rc = 0; @@ -279,7 +280,7 @@ int mem_event_domctl(struct domain *d, x case XEN_DOMCTL_MEM_EVENT_OP_DISABLE: { - rc = mem_event_disable(d); + rc = mem_event_disable(&d->mem_event); } break; diff -r 0268e7380953 -r 95b5a9b92e16 xen/arch/x86/mm/mem_sharing.c --- a/xen/arch/x86/mm/mem_sharing.c +++ b/xen/arch/x86/mm/mem_sharing.c @@ -281,12 +281,12 @@ static struct page_info* mem_sharing_all vcpu_pause_nosync(v); req.flags |= MEM_EVENT_FLAG_VCPU_PAUSED; - if(mem_event_check_ring(d)) return page; + if(mem_event_check_ring(d, &d->mem_event)) return page; req.gfn = gfn; req.p2mt = p2m_ram_shared; req.vcpu_id = v->vcpu_id; - mem_event_put_request(d, &req); + mem_event_put_request(d, &d->mem_event, &req); return page; } @@ -301,7 +301,7 @@ int mem_sharing_sharing_resume(struct do mem_event_response_t rsp; /* Get request off the ring */ - mem_event_get_response(d, &rsp); + mem_event_get_response(&d->mem_event, &rsp); /* Unpause domain/vcpu */ if( rsp.flags & MEM_EVENT_FLAG_VCPU_PAUSED ) diff -r 0268e7380953 -r 95b5a9b92e16 xen/arch/x86/mm/p2m.c --- a/xen/arch/x86/mm/p2m.c +++ b/xen/arch/x86/mm/p2m.c @@ -755,7 +755,7 @@ void p2m_mem_paging_drop_page(struct dom mem_event_request_t req; /* Check that there's space on the ring for this request */ - if ( mem_event_check_ring(d) == 0) + if ( mem_event_check_ring(d, &d->mem_event) == 0) { /* Send release notification to pager */ memset(&req, 0, sizeof(req)); @@ -763,7 +763,7 @@ void p2m_mem_paging_drop_page(struct dom req.gfn = gfn; req.vcpu_id = v->vcpu_id; - mem_event_put_request(d, &req); + mem_event_put_request(d, &d->mem_event, &req); } } @@ -775,7 +775,7 @@ void p2m_mem_paging_populate(struct doma struct p2m_domain *p2m = p2m_get_hostp2m(d); /* Check that there's space on the ring for this request */ - if ( mem_event_check_ring(d) ) + if ( mem_event_check_ring(d, &d->mem_event) ) return; memset(&req, 0, sizeof(req)); @@ -803,7 +803,7 @@ void p2m_mem_paging_populate(struct doma else if ( p2mt != p2m_ram_paging_out && p2mt != p2m_ram_paged ) { /* gfn is already on its way back and vcpu is not paused */ - mem_event_put_req_producers(d); + mem_event_put_req_producers(&d->mem_event); return; } @@ -812,7 +812,7 @@ void p2m_mem_paging_populate(struct doma req.p2mt = p2mt; req.vcpu_id = v->vcpu_id; - mem_event_put_request(d, &req); + mem_event_put_request(d, &d->mem_event, &req); } int p2m_mem_paging_prep(struct domain *d, unsigned long gfn) @@ -842,7 +842,7 @@ void p2m_mem_paging_resume(struct domain mfn_t mfn; /* Pull the response off the ring */ - mem_event_get_response(d, &rsp); + mem_event_get_response(&d->mem_event, &rsp); /* Fix p2m entry if the page was not dropped */ if ( !(rsp.flags & MEM_EVENT_FLAG_DROP_PAGE) ) @@ -889,7 +889,7 @@ void p2m_mem_access_check(unsigned long p2m_unlock(p2m); /* Otherwise, check if there is a memory event listener, and send the message along */ - res = mem_event_check_ring(d); + res = mem_event_check_ring(d, &d->mem_event); if ( res < 0 ) { /* No listener */ @@ -933,7 +933,7 @@ void p2m_mem_access_check(unsigned long req.vcpu_id = v->vcpu_id; - mem_event_put_request(d, &req); + mem_event_put_request(d, &d->mem_event, &req); /* VCPU paused, mem event request sent */ } @@ -943,7 +943,7 @@ void p2m_mem_access_resume(struct p2m_do struct domain *d = p2m->domain; mem_event_response_t rsp; - mem_event_get_response(d, &rsp); + mem_event_get_response(&d->mem_event, &rsp); /* Unpause domain */ if ( rsp.flags & MEM_EVENT_FLAG_VCPU_PAUSED ) diff -r 0268e7380953 -r 95b5a9b92e16 xen/include/asm-x86/mem_event.h --- a/xen/include/asm-x86/mem_event.h +++ b/xen/include/asm-x86/mem_event.h @@ -26,10 +26,10 @@ /* Pauses VCPU while marking pause flag for mem event */ void mem_event_mark_and_pause(struct vcpu *v); -int mem_event_check_ring(struct domain *d); -void mem_event_put_req_producers(struct domain *d); -void mem_event_put_request(struct domain *d, mem_event_request_t *req); -void mem_event_get_response(struct domain *d, mem_event_response_t *rsp); +int mem_event_check_ring(struct domain *d, struct mem_event_domain *med); +void mem_event_put_req_producers(struct mem_event_domain *med); +void mem_event_put_request(struct domain *d, struct mem_event_domain *med, mem_event_request_t *req); +void mem_event_get_response(struct mem_event_domain *med, mem_event_response_t *rsp); void mem_event_unpause_vcpus(struct domain *d); int mem_event_domctl(struct domain *d, xen_domctl_mem_event_op_t *mec, _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel From xen-devel-bounces@lists.xensource.com Thu Sep 08 03:06:59 2011 Return-path: Envelope-to: www-data@lists.xensource.com Delivery-date: Thu, 08 Sep 2011 03:06:59 -0700 Received: from localhost ([127.0.0.1] helo=lists.colo.xensource.com) by lists.xensource.com with esmtp (Exim 4.43) id 1R1bVZ-0006vs-WD; Thu, 08 Sep 2011 03:06:58 -0700 Received: from mail174.messagelabs.com ([85.158.138.51]) by lists.xensource.com with esmtp (Exim 4.43) id 1R1bMK-0005sc-HZ for xen-devel@lists.xensource.com; Thu, 08 Sep 2011 02:57:24 -0700 X-Env-Sender: olaf@aepfle.de X-Msg-Ref: server-11.tower-174.messagelabs.com!1315475840!30678414!1 X-Originating-IP: [81.169.146.160] X-StarScan-Version: 6.3.6; banners=-,-,- X-VirusChecked: Checked Received: (qmail 8443 invoked from network); 8 Sep 2011 09:57:21 -0000 Received: from mo-p00-ob.rzone.de (HELO mo-p00-ob.rzone.de) (81.169.146.160) by server-11.tower-174.messagelabs.com with DHE-RSA-AES256-SHA encrypted SMTP; 8 Sep 2011 09:57:21 -0000 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; t=1315475839; l=1112; s=domk; d=aepfle.de; h=To:From:Date:Subject:Content-Transfer-Encoding:MIME-Version: Content-Type:X-RZG-CLASS-ID:X-RZG-AUTH; bh=WigwoNlvWIBIgY2n4kazcXjrAW8=; b=Mat4rnfW6D5zhQUMAUz4nwIYkw7P5tSBhcQLp45BX3gRg4oIf1aYzkcepcawrZdJQab 24hNRy/EIiXAv3hBUIdGH3Q3fB0u6FYZ2f2iCR/tB0HKgF7XVCplB66NF0XFDdaNO/sAx x41L8XpsHTZFAqsB9Kw/om+nxpGTKmreWzg= X-RZG-AUTH: :P2EQZWCpfu+qG7CngxMFH1J+zrwiavkK6tmQaLfmztM8TOFPjzIQEqmbbQ== X-RZG-CLASS-ID: mo00 Received: from probook.site (dslb-088-065-111-140.pools.arcor-ip.net [88.65.111.140]) by smtp.strato.de (cohen mo24) (RZmta 26.6) with (DHE-RSA-AES256-SHA encrypted) ESMTPA id v062d0n888D5f2 for ; Thu, 8 Sep 2011 11:57:09 +0200 (MEST) Received: from probook.site (localhost [IPv6:::1]) by probook.site (Postfix) with ESMTP id EB0C518892 for ; Thu, 8 Sep 2011 11:57:08 +0200 (CEST) Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Message-Id: User-Agent: Mercurial-patchbomb/1.7.5 Date: Thu, 08 Sep 2011 11:57:08 +0200 From: Olaf Hering To: xen-devel@lists.xensource.com Subject: [Xen-devel] [PATCH 0 of 2] v2: memshare/xenpaging/xen-access fixes for xen-unstable X-BeenThere: xen-devel@lists.xensource.com X-Mailman-Version: 2.1.5 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xensource.com Errors-To: xen-devel-bounces@lists.xensource.com The following two patches allow the parallel use of memsharing, xenpaging and xen-access by using an independent ring buffer for each feature. Please review. v2: - update mem_event_check_ring arguments, check domain rather than domain_id - check ring_full first because its value was just evaluated - check if ring buffer is initialized before calling mem_access_domctl/mem_paging_domctl Olaf tools/libxc/Makefile | 2 tools/libxc/xc_mem_access.c | 21 ++- tools/libxc/xc_mem_event.c | 15 -- tools/libxc/xc_mem_paging.c | 33 +++- tools/libxc/xc_memshr.c | 16 +- tools/libxc/xenctrl.h | 9 - tools/tests/xen-access/xen-access.c | 4 tools/xenpaging/xenpaging.c | 4 xen/arch/ia64/xen/dom0_ops.c | 2 xen/arch/x86/hvm/hvm.c | 4 xen/arch/x86/mm/mem_event.c | 242 +++++++++++++++++++----------------- xen/arch/x86/mm/mem_paging.c | 4 xen/arch/x86/mm/mem_sharing.c | 22 +-- xen/arch/x86/mm/p2m.c | 18 +- xen/include/asm-x86/mem_event.h | 8 - xen/include/public/domctl.h | 43 +++--- xen/include/xen/sched.h | 6 17 files changed, 250 insertions(+), 203 deletions(-) _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel From xen-devel-bounces@lists.xensource.com Thu Sep 08 03:15:49 2011 Return-path: Envelope-to: www-data@lists.xensource.com Delivery-date: Thu, 08 Sep 2011 03:15:49 -0700 Received: from localhost ([127.0.0.1] helo=lists.colo.xensource.com) by lists.xensource.com with esmtp (Exim 4.43) id 1R1be9-0008AF-Lt; Thu, 08 Sep 2011 03:15:49 -0700 Received: from mail174.messagelabs.com ([85.158.138.51]) by lists.xensource.com with esmtp (Exim 4.43) id 1R1bdd-0007y3-Rg for xen-devel@lists.xensource.com; Thu, 08 Sep 2011 03:15:18 -0700 X-Env-Sender: JBeulich@suse.com X-Msg-Ref: server-15.tower-174.messagelabs.com!1315476747!24338827!1 X-Originating-IP: [130.57.49.28] X-StarScan-Version: 6.3.6; banners=-,-,- X-VirusChecked: Checked Received: (qmail 22541 invoked from network); 8 Sep 2011 10:15:14 -0000 Received: from nat28.tlf.novell.com (HELO nat28.tlf.novell.com) (130.57.49.28) by server-15.tower-174.messagelabs.com with DHE-RSA-AES256-SHA encrypted SMTP; 8 Sep 2011 10:15:14 -0000 Received: from EMEA1-MTA by nat28.tlf.novell.com with Novell_GroupWise; Thu, 08 Sep 2011 11:13:22 +0100 Message-Id: <4E68B13D020000780005544F@nat28.tlf.novell.com> X-Mailer: Novell GroupWise Internet Agent 8.0.1 Date: Thu, 08 Sep 2011 11:12:45 +0100 From: "Jan Beulich" To: "Keir Fraser" ,"Tim Deegan" Subject: Re: [Xen-devel] 4.0/4.1 requests References: <4E68A4AC02000078000553F2@nat28.tlf.novell.com> In-Reply-To: <4E68A4AC02000078000553F2@nat28.tlf.novell.com> Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: quoted-printable Content-Disposition: inline Cc: "xen-devel@lists.xensource.com" X-BeenThere: xen-devel@lists.xensource.com X-Mailman-Version: 2.1.5 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xensource.com Errors-To: xen-devel-bounces@lists.xensource.com >>> On 08.09.11 at 11:19, "Jan Beulich" wrote: > Hi Keir, >=20 > without the old IO-APIC part addressed, I wonder whether we should > really have the backport of 23805:7048810180de ("IRQ: manually EOI > migrating line interrupts") in both trees. >=20 > I'd also like you to add 23820:ba75234a6f56 ("bitmap_scnlistprintf() > should always zero-terminate its output buffer") to 4.0 (I see it's > already in 4.1), as this not being fixed confuses 'e' debug key output. Also shouldn't we have a backport of 23112:84e3706df07a ("Passthrough: disable bus-mastering on any card that causes an IOMMU fault.") in the 4.0 tree (even if it doesn't fully address the problem, yet - that's the case in the other trees too)? Jan _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel From xen-devel-bounces@lists.xensource.com Thu Sep 08 03:17:37 2011 Return-path: Envelope-to: www-data@lists.xensource.com Delivery-date: Thu, 08 Sep 2011 03:17:37 -0700 Received: from localhost ([127.0.0.1] helo=lists.colo.xensource.com) by lists.xensource.com with esmtp (Exim 4.43) id 1R1bft-000067-LJ; Thu, 08 Sep 2011 03:17:37 -0700 Received: from mail182.messagelabs.com ([85.158.139.83]) by lists.xensource.com with esmtp (Exim 4.43) id 1R1bfT-0008Ly-UA for xen-devel@lists.xensource.com; Thu, 08 Sep 2011 03:17:12 -0700 X-Env-Sender: keir.xen@gmail.com X-Msg-Ref: server-13.tower-182.messagelabs.com!1315477028!17368144!1 X-Originating-IP: [74.125.82.171] X-StarScan-Version: 6.3.6; banners=-,-,- X-VirusChecked: Checked Received: (qmail 7327 invoked from network); 8 Sep 2011 10:17:09 -0000 Received: from mail-wy0-f171.google.com (HELO mail-wy0-f171.google.com) (74.125.82.171) by server-13.tower-182.messagelabs.com with RC4-SHA encrypted SMTP; 8 Sep 2011 10:17:09 -0000 Received: by wyh13 with SMTP id 13so486198wyh.30 for ; Thu, 08 Sep 2011 03:17:08 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=user-agent:date:subject:from:to:cc:message-id:thread-topic :thread-index:in-reply-to:mime-version:content-type :content-transfer-encoding; bh=IbupWc8vFRcT8bL5G9Fco2kII71DlksWBYM9SBOVe8M=; b=m97vsoEYh9mG/0FBVmSBUo1oomjdiJKqOHdzrZGfarP+LtWQ7aecVXflQO0eN/gg6p rayc7KoW1NLB89a9D0fEZhmP9skpim1uqLqSE5WjZtt0j22fYdPfUnQd/EOodT3yqCSu eyh/KNuRBdm7IlPZNBSzRZCQh4QDGUSr4m0QQ= Received: by 10.227.3.4 with SMTP id 4mr555166wbl.35.1315477028792; Thu, 08 Sep 2011 03:17:08 -0700 (PDT) Received: from [192.168.1.78] (host86-137-116-193.range86-137.btcentralplus.com [86.137.116.193]) by mx.google.com with ESMTPS id fa7sm3632052wbb.26.2011.09.08.03.17.06 (version=SSLv3 cipher=OTHER); Thu, 08 Sep 2011 03:17:07 -0700 (PDT) User-Agent: Microsoft-Entourage/12.30.0.110427 Date: Thu, 08 Sep 2011 11:17:02 +0100 From: Keir Fraser To: Jan Beulich , Andrew Cooper Message-ID: Thread-Topic: 4.0/4.1 requests Thread-Index: AcxuEHNP7ry46kfcu0mDyN7TCTjlfw== In-Reply-To: <4E68A4AC02000078000553F2@nat28.tlf.novell.com> Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit Cc: "xen-devel@lists.xensource.com" Subject: [Xen-devel] Re: 4.0/4.1 requests X-BeenThere: xen-devel@lists.xensource.com X-Mailman-Version: 2.1.5 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xensource.com Errors-To: xen-devel-bounces@lists.xensource.com On 08/09/2011 10:19, "Jan Beulich" wrote: > Hi Keir, > > without the old IO-APIC part addressed, I wonder whether we should > really have the backport of 23805:7048810180de ("IRQ: manually EOI > migrating line interrupts") in both trees. It does fix a real bug. Perhaps Andrew could hack up a patch to make it dependent on IO-APIC version? > I'd also like you to add 23820:ba75234a6f56 ("bitmap_scnlistprintf() > should always zero-terminate its output buffer") to 4.0 (I see it's > already in 4.1), as this not being fixed confuses 'e' debug key output. Ok. -- Keir > Jan > _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel From xen-devel-bounces@lists.xensource.com Thu Sep 08 03:49:44 2011 Return-path: Envelope-to: www-data@lists.xensource.com Delivery-date: Thu, 08 Sep 2011 03:49:44 -0700 Received: from localhost ([127.0.0.1] helo=lists.colo.xensource.com) by lists.xensource.com with esmtp (Exim 4.43) id 1R1cAy-0001lR-MV; Thu, 08 Sep 2011 03:49:44 -0700 Received: from mail21.messagelabs.com ([85.158.143.35]) by lists.xensource.com with esmtp (Exim 4.43) id 1R1cAK-0001Z0-47 for xen-devel@lists.xensource.com; Thu, 08 Sep 2011 03:49:04 -0700 X-Env-Sender: Andrew.Cooper3@citrix.com X-Msg-Ref: server-14.tower-21.messagelabs.com!1315478932!58807356!1 X-Originating-IP: [66.165.176.89] X-StarScan-Version: 6.3.6; banners=-,-,- X-VirusChecked: Checked Received: (qmail 1447 invoked from network); 8 Sep 2011 10:48:53 -0000 Received: from smtp.citrix.com (HELO SMTP.CITRIX.COM) (66.165.176.89) by server-14.tower-21.messagelabs.com with RC4-SHA encrypted SMTP; 8 Sep 2011 10:48:53 -0000 X-IronPort-AV: E=Sophos;i="4.68,350,1312171200"; d="scan'208";a="16789952" Received: from ftlpmailmx02.citrite.net ([10.13.107.66]) by FTLPIPO01.CITRIX.COM with ESMTP/TLS/RC4-MD5; 08 Sep 2011 06:48:59 -0400 Received: from [10.80.2.18] (10.80.2.18) by FTLPMAILMX02.citrite.net (10.13.107.66) with Microsoft SMTP Server id 8.3.137.0; Thu, 8 Sep 2011 06:48:59 -0400 Message-ID: <4E689D9A.1020405@citrix.com> Date: Thu, 8 Sep 2011 11:48:58 +0100 From: Andrew Cooper User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.2.21) Gecko/20110831 Lightning/1.0b2 Thunderbird/3.1.13 MIME-Version: 1.0 To: Keir Fraser References: In-Reply-To: Content-Type: text/plain; charset="ISO-8859-1" Content-Transfer-Encoding: 7bit Cc: "xen-devel@lists.xensource.com" , Jan Beulich Subject: [Xen-devel] Re: 4.0/4.1 requests X-BeenThere: xen-devel@lists.xensource.com X-Mailman-Version: 2.1.5 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xensource.com Errors-To: xen-devel-bounces@lists.xensource.com On 08/09/11 11:17, Keir Fraser wrote: > On 08/09/2011 10:19, "Jan Beulich" wrote: > >> Hi Keir, >> >> without the old IO-APIC part addressed, I wonder whether we should >> really have the backport of 23805:7048810180de ("IRQ: manually EOI >> migrating line interrupts") in both trees. > It does fix a real bug. Perhaps Andrew could hack up a patch to make it > dependent on IO-APIC version? Now that I am not racing against a release deadline, this is a possibility. It probably means falling through to the "fake an EOI for line level interrupt code", as the Status bit is RO in the IO-APIC (The IRR bit is RW but both need updating) Does anyone know which revision of the IO-APIC was the first with an EOI register? If not, I think I have some document trawling to do. >> I'd also like you to add 23820:ba75234a6f56 ("bitmap_scnlistprintf() >> should always zero-terminate its output buffer") to 4.0 (I see it's >> already in 4.1), as this not being fixed confuses 'e' debug key output. > Ok. > > -- Keir > >> Jan >> > -- Andrew Cooper - Dom0 Kernel Engineer, Citrix XenServer T: +44 (0)1223 225 900, http://www.citrix.com _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel From xen-devel-bounces@lists.xensource.com Thu Sep 08 04:13:34 2011 Return-path: Envelope-to: www-data@lists.xensource.com Delivery-date: Thu, 08 Sep 2011 04:13:34 -0700 Received: from localhost ([127.0.0.1] helo=lists.colo.xensource.com) by lists.xensource.com with esmtp (Exim 4.43) id 1R1cY2-0003zF-0r; Thu, 08 Sep 2011 04:13:34 -0700 Received: from mail182.messagelabs.com ([85.158.139.83]) by lists.xensource.com with esmtp (Exim 4.43) id 1R1cVv-0003kz-OW for xen-devel@lists.xensource.com; Thu, 08 Sep 2011 04:12:21 -0700 X-Env-Sender: keir.xen@gmail.com X-Msg-Ref: server-10.tower-182.messagelabs.com!1315480280!17522224!1 X-Originating-IP: [74.125.82.171] X-StarScan-Version: 6.3.6; banners=-,-,- X-VirusChecked: Checked Received: (qmail 12322 invoked from network); 8 Sep 2011 11:11:20 -0000 Received: from mail-wy0-f171.google.com (HELO mail-wy0-f171.google.com) (74.125.82.171) by server-10.tower-182.messagelabs.com with RC4-SHA encrypted SMTP; 8 Sep 2011 11:11:20 -0000 Received: by wyh13 with SMTP id 13so529333wyh.30 for ; Thu, 08 Sep 2011 04:11:20 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=user-agent:date:subject:from:to:cc:message-id:thread-topic :thread-index:in-reply-to:mime-version:content-type :content-transfer-encoding; bh=rIscohS/6H6ekg/0R0VoEiOVfAkqj09c2oIZce74KCY=; b=B4Bd7t1F1SKPjQ6RsoVuYTZ4sLkvqMEDaIs4lh8q5gv/SFm6Ia9R4Tk+4hXGjQrt5y x2aDGf8I3Yi0QpmV9AldRulwXqidBaQfP9nO1r1mXM22X0VDPTxeyqwHWOZbygffODtW 2sbnpUSPrD1inBiyxMUVO4dDNDMNXd+cl+pxo= Received: by 10.216.198.145 with SMTP id v17mr628694wen.66.1315480280445; Thu, 08 Sep 2011 04:11:20 -0700 (PDT) Received: from [192.168.1.78] (host86-137-116-193.range86-137.btcentralplus.com [86.137.116.193]) by mx.google.com with ESMTPS id z18sm3804775wbm.22.2011.09.08.04.11.15 (version=SSLv3 cipher=OTHER); Thu, 08 Sep 2011 04:11:18 -0700 (PDT) User-Agent: Microsoft-Entourage/12.30.0.110427 Date: Thu, 08 Sep 2011 12:11:13 +0100 From: Keir Fraser To: Andrew Cooper Message-ID: Thread-Topic: 4.0/4.1 requests Thread-Index: AcxuGAUOrdUbIHeMrEGPfr0bvjzBMA== In-Reply-To: <4E689D9A.1020405@citrix.com> Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit Cc: "xen-devel@lists.xensource.com" , Jan Beulich Subject: [Xen-devel] Re: 4.0/4.1 requests X-BeenThere: xen-devel@lists.xensource.com X-Mailman-Version: 2.1.5 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xensource.com Errors-To: xen-devel-bounces@lists.xensource.com On 08/09/2011 11:48, "Andrew Cooper" wrote: >>> Hi Keir, >>> >>> without the old IO-APIC part addressed, I wonder whether we should >>> really have the backport of 23805:7048810180de ("IRQ: manually EOI >>> migrating line interrupts") in both trees. >> It does fix a real bug. Perhaps Andrew could hack up a patch to make it >> dependent on IO-APIC version? > Now that I am not racing against a release deadline, this is a > possibility. It probably means falling through to the "fake an EOI for > line level interrupt code", as the Status bit is RO in the IO-APIC (The > IRR bit is RW but both need updating) Falling back to the old behaviour would be acceptable. I think we're talking only very old systems here. > Does anyone know which revision of the IO-APIC was the first with an EOI > register? Jan's patches which use the IOAPIC EOI register have a version check. You can copy that. -- Keir > If not, I think I have some document trawling to do. _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel From xen-devel-bounces@lists.xensource.com Thu Sep 08 04:30:15 2011 Return-path: Envelope-to: www-data@lists.xensource.com Delivery-date: Thu, 08 Sep 2011 04:30:15 -0700 Received: from localhost ([127.0.0.1] helo=lists.colo.xensource.com) by lists.xensource.com with esmtp (Exim 4.43) id 1R1coB-0004fw-Gl; Thu, 08 Sep 2011 04:30:15 -0700 Received: from mail27.messagelabs.com ([193.109.254.147]) by lists.xensource.com with esmtp (Exim 4.43) id 1R1cnb-0004TZ-LW for xen-devel@lists.xensource.com; Thu, 08 Sep 2011 04:29:39 -0700 X-Env-Sender: keir.xen@gmail.com X-Msg-Ref: server-12.tower-27.messagelabs.com!1315481363!41587263!1 X-Originating-IP: [74.125.82.43] X-StarScan-Version: 6.3.6; banners=-,-,- X-VirusChecked: Checked Received: (qmail 5791 invoked from network); 8 Sep 2011 11:29:23 -0000 Received: from mail-ww0-f43.google.com (HELO mail-ww0-f43.google.com) (74.125.82.43) by server-12.tower-27.messagelabs.com with RC4-SHA encrypted SMTP; 8 Sep 2011 11:29:23 -0000 Received: by wwe32 with SMTP id 32so580293wwe.24 for ; Thu, 08 Sep 2011 04:29:36 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=sender:user-agent:date:subject:from:to:cc:message-id:thread-topic :thread-index:in-reply-to:mime-version:content-type :content-transfer-encoding; bh=z24FIGD7GtWp5uOWT08Wpv6XPCxp74VKRKKlsr4jtdU=; b=c8qq+8+7yNihRvTPtF7xKMKUfvn258hOGrDgyobZcNRxyPtkqw/2gXd/tfiifEmXxy PPudTxQmADZBZF0kbDP7M7AlO6wbMNp4lDk5MpH/MBGv8So23sq+fLF8gvuoczm6PlG4 Q8QNXRONSkxxkfxoTrZCHbPmoRLGmslVmcQdQ= Received: by 10.227.13.149 with SMTP id c21mr597073wba.85.1315481376102; Thu, 08 Sep 2011 04:29:36 -0700 (PDT) Received: from [192.168.1.3] (host86-137-116-193.range86-137.btcentralplus.com [86.137.116.193]) by mx.google.com with ESMTPS id fr18sm3892203wbb.9.2011.09.08.04.29.33 (version=SSLv3 cipher=OTHER); Thu, 08 Sep 2011 04:29:34 -0700 (PDT) User-Agent: Microsoft-Entourage/12.30.0.110427 Date: Thu, 08 Sep 2011 12:29:30 +0100 Subject: Re: [Xen-devel] 4.0/4.1 requests From: Keir Fraser To: Jan Beulich , Tim Deegan Message-ID: Thread-Topic: [Xen-devel] 4.0/4.1 requests Thread-Index: AcxuGpLrCCoDENtZ/0izM3gFz3AyZA== In-Reply-To: <4E68B13D020000780005544F@nat28.tlf.novell.com> Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit Cc: "xen-devel@lists.xensource.com" X-BeenThere: xen-devel@lists.xensource.com X-Mailman-Version: 2.1.5 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xensource.com Errors-To: xen-devel-bounces@lists.xensource.com On 08/09/2011 11:12, "Jan Beulich" wrote: >>>> On 08.09.11 at 11:19, "Jan Beulich" wrote: >> Hi Keir, >> >> without the old IO-APIC part addressed, I wonder whether we should >> really have the backport of 23805:7048810180de ("IRQ: manually EOI >> migrating line interrupts") in both trees. >> >> I'd also like you to add 23820:ba75234a6f56 ("bitmap_scnlistprintf() >> should always zero-terminate its output buffer") to 4.0 (I see it's >> already in 4.1), as this not being fixed confuses 'e' debug key output. > > Also shouldn't we have a backport of 23112:84e3706df07a ("Passthrough: > disable bus-mastering on any card that causes an IOMMU fault.") in the > 4.0 tree (even if it doesn't fully address the problem, yet - that's the > case in the other trees too)? Now done. -- Keir > Jan > _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel From xen-devel-bounces@lists.xensource.com Thu Sep 08 04:45:10 2011 Return-path: Envelope-to: www-data@lists.xensource.com Delivery-date: Thu, 08 Sep 2011 04:45:10 -0700 Received: from localhost ([127.0.0.1] helo=lists.colo.xensource.com) by lists.xensource.com with esmtp (Exim 4.43) id 1R1d2c-0005OK-7H; Thu, 08 Sep 2011 04:45:10 -0700 Received: from mail174.messagelabs.com ([85.158.138.51]) by lists.xensource.com with esmtp (Exim 4.43) id 1R1d1x-0005Bu-55 for xen-devel@lists.xensource.com; Thu, 08 Sep 2011 04:44:29 -0700 X-Env-Sender: JBeulich@suse.com X-Msg-Ref: server-15.tower-174.messagelabs.com!1315482262!24352677!1 X-Originating-IP: [130.57.49.28] X-StarScan-Version: 6.3.6; banners=-,-,- X-VirusChecked: Checked Received: (qmail 30523 invoked from network); 8 Sep 2011 11:44:25 -0000 Received: from nat28.tlf.novell.com (HELO nat28.tlf.novell.com) (130.57.49.28) by server-15.tower-174.messagelabs.com with DHE-RSA-AES256-SHA encrypted SMTP; 8 Sep 2011 11:44:25 -0000 Received: from EMEA1-MTA by nat28.tlf.novell.com with Novell_GroupWise; Thu, 08 Sep 2011 12:44:12 +0100 Message-Id: <4E68C6C10200007800055485@nat28.tlf.novell.com> X-Mailer: Novell GroupWise Internet Agent 8.0.1 Date: Thu, 08 Sep 2011 12:44:33 +0100 From: "Jan Beulich" To: "Andrew Cooper" References: <4E689D9A.1020405@citrix.com> In-Reply-To: <4E689D9A.1020405@citrix.com> Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: quoted-printable Content-Disposition: inline Cc: Keir Fraser , "xen-devel@lists.xensource.com" Subject: [Xen-devel] Re: 4.0/4.1 requests X-BeenThere: xen-devel@lists.xensource.com X-Mailman-Version: 2.1.5 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xensource.com Errors-To: xen-devel-bounces@lists.xensource.com >>> On 08.09.11 at 12:48, Andrew Cooper wrote: >=20 > On 08/09/11 11:17, Keir Fraser wrote: >> On 08/09/2011 10:19, "Jan Beulich" wrote: >> >>> Hi Keir, >>> >>> without the old IO-APIC part addressed, I wonder whether we should >>> really have the backport of 23805:7048810180de ("IRQ: manually EOI >>> migrating line interrupts") in both trees. >> It does fix a real bug. Perhaps Andrew could hack up a patch to make it >> dependent on IO-APIC version? > Now that I am not racing against a release deadline, this is a > possibility. It probably means falling through to the "fake an EOI for > line level interrupt code", as the Status bit is RO in the IO-APIC (The > IRR bit is RW but both need updating) >=20 > Does anyone know which revision of the IO-APIC was the first with an EOI > register? As Keir said, code already exists which does this version check. But to answer explicitly: It's version 0x20. Jan _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel From xen-devel-bounces@lists.xensource.com Thu Sep 08 04:59:44 2011 Return-path: Envelope-to: www-data@lists.xensource.com Delivery-date: Thu, 08 Sep 2011 04:59:44 -0700 Received: from localhost ([127.0.0.1] helo=lists.colo.xensource.com) by lists.xensource.com with esmtp (Exim 4.43) id 1R1dGg-0006eH-3W; Thu, 08 Sep 2011 04:59:42 -0700 Received: from mail216.messagelabs.com ([85.158.143.99]) by lists.xensource.com with esmtp (Exim 4.43) id 1R1dEL-0006MU-8d for xen-devel@lists.xensource.com; Thu, 08 Sep 2011 04:57:17 -0700 X-Env-Sender: olaf@aepfle.de X-Msg-Ref: server-7.tower-216.messagelabs.com!1315483033!17534412!1 X-Originating-IP: [81.169.146.160] X-StarScan-Version: 6.3.6; banners=-,-,- X-VirusChecked: Checked Received: (qmail 23688 invoked from network); 8 Sep 2011 11:57:14 -0000 Received: from mo-p00-ob.rzone.de (HELO mo-p00-ob.rzone.de) (81.169.146.160) by server-7.tower-216.messagelabs.com with DHE-RSA-AES256-SHA encrypted SMTP; 8 Sep 2011 11:57:14 -0000 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; t=1315483033; l=1505; s=domk; d=aepfle.de; h=Cc:To:From:Date:Subject:Content-Transfer-Encoding:MIME-Version: Content-Type:X-RZG-CLASS-ID:X-RZG-AUTH; bh=Mg7qng1EsYOuiY7jVhcIe6QcbRk=; b=oQQBJ3dsSJFEzwqFeSqvpfMDV/WuCoOQ1azfNhJvKrMNNq6GRNOyoSk77cRW7OsXs0n ZAtgaF5aoBnrzr1hXsrv5eZeMabUTWmCB6Y7+gxeOVMq24IReh5cGrsOrEb2bI2QfKgUD t/F/f4D45fOihs9efRLb7Qg97jOOCnEw3eE= X-RZG-AUTH: :P2EQZWCpfu+qG7CngxMFH1J+zrwiavkK6tmQaLfmztM8TOFPjzIQEqmbbQ== X-RZG-CLASS-ID: mo00 Received: from probook.site (dslb-088-065-111-140.pools.arcor-ip.net [88.65.111.140]) by smtp.strato.de (jimi mo55) (RZmta 26.6) with (DHE-RSA-AES256-SHA encrypted) ESMTPA id y0207fn88A8PP1 ; Thu, 8 Sep 2011 13:57:00 +0200 (MEST) Received: from probook.site (localhost [IPv6:::1]) by probook.site (Postfix) with ESMTP id 895D718892; Thu, 8 Sep 2011 13:56:59 +0200 (CEST) Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Mercurial-Node: 7829ad83ee66fbec0653ccb53ce5b8502657a71f Message-Id: <7829ad83ee66fbec0653.1315483016@probook.site> User-Agent: Mercurial-patchbomb/1.7.5 Date: Thu, 08 Sep 2011 13:56:56 +0200 From: Olaf Hering To: xen-devel@lists.xensource.com Cc: Ian Jackson Subject: [Xen-devel] [PATCH] hotplug: update xencommons script to run only when needed X-BeenThere: xen-devel@lists.xensource.com X-Mailman-Version: 2.1.5 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xensource.com Errors-To: xen-devel-bounces@lists.xensource.com # HG changeset patch # User Olaf Hering # Date 1315479698 -7200 # Node ID 7829ad83ee66fbec0653ccb53ce5b8502657a71f # Parent 7b55f33f29cd7aaa0057485b8cae53722bac8741 hotplug: update xencommons script to run only when needed Currently xencommons prints an error if /proc/xen/capabilities does not exist when started on a non-xen kernel. Update the xencommons script to run only when needed: - do not run if /proc/xen does not exist - check if /proc/xen/capabilities exists before doing the grep for dom0 Signed-off-by: Olaf Hering diff -r 7b55f33f29cd -r 7829ad83ee66 tools/hotplug/Linux/init.d/xencommons --- a/tools/hotplug/Linux/init.d/xencommons +++ b/tools/hotplug/Linux/init.d/xencommons @@ -29,15 +29,24 @@ test -f $xencommons_config/xencommons && XENCONSOLED_PIDFILE=/var/run/xenconsoled.pid shopt -s extglob +# not running in Xen dom0 or domU +if ! test -d /proc/xen ; then + exit 0 +fi + +# mount xenfs in dom0 or domU with a pv_ops kernel if test "x$1" = xstart && \ - test -d /proc/xen && \ ! test -f /proc/xen/capabilities && \ ! grep '^xenfs ' /proc/mounts >/dev/null; then mount -t xenfs xenfs /proc/xen fi -if ! grep -q "control_d" /proc/xen/capabilities ; then +# run this script only in dom0: +# no capabilities file in xenlinux domU kernel +# empty capabilities file in pv_ops domU kernel +if test -f /proc/xen/capabilities && \ + ! grep -q "control_d" /proc/xen/capabilities ; then exit 0 fi _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel From xen-devel-bounces@lists.xensource.com Thu Sep 08 05:16:39 2011 Return-path: Envelope-to: www-data@lists.xensource.com Delivery-date: Thu, 08 Sep 2011 05:16:39 -0700 Received: from localhost ([127.0.0.1] helo=lists.colo.xensource.com) by lists.xensource.com with esmtp (Exim 4.43) id 1R1dX5-000077-Cm; Thu, 08 Sep 2011 05:16:39 -0700 Received: from mail174.messagelabs.com ([85.158.138.51]) by lists.xensource.com with smtp (Exim 4.43) id 1R1dWY-0008MZ-SZ for xen-devel@lists.xensource.com; Thu, 08 Sep 2011 05:16:09 -0700 X-Env-Sender: yang.z.zhang@intel.com X-Msg-Ref: server-9.tower-174.messagelabs.com!1315484162!24673310!1 X-Originating-IP: [143.182.124.21] X-StarScan-Version: 6.3.6; banners=-,-,- X-VirusChecked: Checked Received: (qmail 21338 invoked from network); 8 Sep 2011 12:16:03 -0000 Received: from mga03.intel.com (HELO mga03.intel.com) (143.182.124.21) by server-9.tower-174.messagelabs.com with SMTP; 8 Sep 2011 12:16:03 -0000 Received: from azsmga002.ch.intel.com ([10.2.17.35]) by azsmga101.ch.intel.com with ESMTP; 08 Sep 2011 05:16:01 -0700 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="4.68,350,1312182000"; d="scan'208";a="15177428" Received: from pgsmsx601.gar.corp.intel.com ([10.221.43.69]) by AZSMGA002.ch.intel.com with ESMTP; 08 Sep 2011 05:16:00 -0700 Received: from pgsmsx509.gar.corp.intel.com (172.30.13.17) by pgsmsx601.gar.corp.intel.com (10.221.43.69) with Microsoft SMTP Server (TLS) id 8.2.255.0; Thu, 8 Sep 2011 20:15:59 +0800 Received: from shsmsx601.ccr.corp.intel.com (10.239.4.112) by PGSMSX509.gar.corp.intel.com (172.30.13.17) with Microsoft SMTP Server (TLS) id 8.2.255.0; Thu, 8 Sep 2011 20:15:59 +0800 Received: from shsmsx501.ccr.corp.intel.com ([10.239.4.141]) by shsmsx601.ccr.corp.intel.com ([10.239.4.112]) with mapi; Thu, 8 Sep 2011 20:15:58 +0800 From: "Zhang, Yang Z" To: Jan Beulich Date: Thu, 8 Sep 2011 20:15:55 +0800 Subject: RE: [Xen-devel] [PATCH]Make sure processor_pminfo initialized before use it Thread-Topic: [Xen-devel] [PATCH]Make sure processor_pminfo initialized before use it Thread-Index: AcxuB25FNKneTEi5SrmiwiYI6GbyfwAGUKhA Message-ID: <749B9D3DBF0F054390025D9EAFF47F2212D149DB92@shsmsx501.ccr.corp.intel.com> References: <749B9D3DBF0F054390025D9EAFF47F2212D149D959@shsmsx501.ccr.corp.intel.com> <4E68A32C02000078000553D7@nat28.tlf.novell.com> In-Reply-To: <4E68A32C02000078000553D7@nat28.tlf.novell.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: Keir, "xen-devel@lists.xensource.com" , Fraser X-BeenThere: xen-devel@lists.xensource.com X-Mailman-Version: 2.1.5 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xensource.com Errors-To: xen-devel-bounces@lists.xensource.com Umm... After checking, the panic due to my mistake to add the debug instruc= tion to print the value of processor_pminfo[cpu]->perf. Please just ignore = this patch. Thanks for pointing out this. best regards yang > -----Original Message----- > From: Jan Beulich [mailto:JBeulich@suse.com] > Sent: Thursday, September 08, 2011 5:13 PM > To: Zhang, Yang Z > Cc: xen-devel@lists.xensource.com; Keir Fraser > Subject: Re: [Xen-devel] [PATCH]Make sure processor_pminfo initialized be= fore > use it >=20 > >>> On 08.09.11 at 08:09, "Zhang, Yang Z" wrote: > > Make sure processor_pminfo not null before use it > > > > If processor_pminfo not initialized, it will cause xen panic. >=20 > Mind pointing out what panic you observed, because ... >=20 > > Signed-off-by: Yang Zhang > > > > diff -r bdd19847ae63 xen/drivers/cpufreq/cpufreq.c > > --- a/xen/drivers/cpufreq/cpufreq.c Wed Sep 07 10:37:48 2011 +0100 > > +++ b/xen/drivers/cpufreq/cpufreq.c Thu Sep 08 13:40:23 2011 +0800 > > @@ -91,7 +91,7 @@ int __init cpufreq_register_governor(str > > > > int cpufreq_limit_change(unsigned int cpu) { > > - struct processor_performance *perf =3D &processor_pminfo[cpu]->per= f; > > + struct processor_performance *perf; >=20 > ... this (and all other changed instances below) is not actually de-refer= encing > processor_pminfo[cpu], and the first de-reference always is only after th= at one > got checked against NULL. >=20 > Jan >=20 > > struct cpufreq_policy *data; > > struct cpufreq_policy policy; > > > > @@ -99,6 +99,7 @@ int cpufreq_limit_change(unsigned int cp > > !processor_pminfo[cpu]) > > return -ENODEV; > > > > + perf =3D &processor_pminfo[cpu]->perf; > > if (perf->platform_limit >=3D perf->state_count) > > return -EINVAL; > > > > @@ -120,12 +121,14 @@ int cpufreq_add_cpu(unsigned int cpu) > > struct cpufreq_dom *cpufreq_dom =3D NULL; > > struct cpufreq_policy new_policy; > > struct cpufreq_policy *policy; > > - struct processor_performance *perf =3D &processor_pminfo[cpu]->per= f; > > + struct processor_performance *perf; > > > > /* to protect the case when Px was not controlled by xen */ > > - if (!processor_pminfo[cpu] || > > - !(perf->init & XEN_PX_INIT) || > > - !cpu_online(cpu)) > > + if (!processor_pminfo[cpu] || !cpu_online(cpu)) > > + return -EINVAL; > > + > > + perf =3D &processor_pminfo[cpu]->perf; > > + if (!(perf->init & XEN_PX_INIT)) > > return -EINVAL; > > > > if (!cpufreq_driver) > > @@ -261,12 +264,14 @@ int cpufreq_del_cpu(unsigned int cpu) > > struct list_head *pos; > > struct cpufreq_dom *cpufreq_dom =3D NULL; > > struct cpufreq_policy *policy; > > - struct processor_performance *perf =3D &processor_pminfo[cpu]->per= f; > > + struct processor_performance *perf; > > > > /* to protect the case when Px was not controlled by xen */ > > - if (!processor_pminfo[cpu] || > > - !(perf->init & XEN_PX_INIT) || > > - !cpu_online(cpu)) > > + if (!processor_pminfo[cpu] || !cpu_online(cpu)) > > + return -EINVAL; > > + > > + perf =3D &processor_pminfo[cpu]->perf; > > + if (!(perf->init & XEN_PX_INIT)) > > return -EINVAL; > > > > if (!per_cpu(cpufreq_cpu_policy, cpu)) > > > > > > > > _______________________________________________ > > Xen-devel mailing list > > Xen-devel@lists.xensource.com > > http://lists.xensource.com/xen-devel >=20 >=20 _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel From xen-devel-bounces@lists.xensource.com Thu Sep 08 05:37:45 2011 Return-path: Envelope-to: www-data@lists.xensource.com Delivery-date: Thu, 08 Sep 2011 05:37:45 -0700 Received: from localhost ([127.0.0.1] helo=lists.colo.xensource.com) by lists.xensource.com with esmtp (Exim 4.43) id 1R1drV-0000rT-Qe; Thu, 08 Sep 2011 05:37:45 -0700 Received: from mail21.messagelabs.com ([85.158.143.35]) by lists.xensource.com with smtp (Exim 4.43) id 1R1dqu-0000fJ-5q for xen-devel@lists.xensource.com; Thu, 08 Sep 2011 05:37:08 -0700 X-Env-Sender: Stefano.Stabellini@eu.citrix.com X-Msg-Ref: server-4.tower-21.messagelabs.com!1315485391!59457112!1 X-Originating-IP: [62.200.22.115] X-StarScan-Version: 6.3.6; banners=-,-,- X-VirusChecked: Checked Received: (qmail 1234 invoked from network); 8 Sep 2011 12:36:31 -0000 Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115) by server-4.tower-21.messagelabs.com with SMTP; 8 Sep 2011 12:36:31 -0000 X-IronPort-AV: E=Sophos;i="4.68,350,1312156800"; d="scan'208";a="7675350" Received: from lonpmailmx01.citrite.net ([10.30.203.162]) by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5; 08 Sep 2011 12:37:04 +0000 Received: from kaball.uk.xensource.com (10.80.2.59) by LONPMAILMX01.citrite.net (10.30.203.162) with Microsoft SMTP Server id 8.3.137.0; Thu, 8 Sep 2011 13:37:04 +0100 Date: Thu, 8 Sep 2011 13:45:15 +0100 From: Stefano Stabellini X-X-Sender: sstabellini@kaball-desktop To: Jeremy Fitzhardinge In-Reply-To: <4E67E10A.3020809@goop.org> Message-ID: References: <1315327307-392-1-git-send-email-stefano.stabellini@eu.citrix.com> <4E67E10A.3020809@goop.org> User-Agent: Alpine 2.00 (DEB 1167 2008-08-23) MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Cc: "xen-devel@lists.xensource.com" , "konrad.wilk@oracle.com" , "linux-kernel@vger.kernel.org" , Stefano Stabellini Subject: [Xen-devel] Re: [PATCH] xen: disable PV spinlocks on HVM X-BeenThere: xen-devel@lists.xensource.com X-Mailman-Version: 2.1.5 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xensource.com Errors-To: xen-devel-bounces@lists.xensource.com On Wed, 7 Sep 2011, Jeremy Fitzhardinge wrote: > On 09/06/2011 09:41 AM, stefano.stabellini@eu.citrix.com wrote: > > From: Stefano Stabellini > > > > PV spinlocks cannot possibly work with the current code because they are > > enabled after pvops patching has already been done, and because PV > > spinlocks use a different data structure than native spinlocks so we > > cannot switch between them dynamically. A spinlock that has been taken > > once by the native code (__ticket_spin_lock) cannot be taken by > > __xen_spin_lock even after it has been released. > > > > Reported-by: Stefan Bader > > Signed-off-by: Stefano Stabellini > > --- > > arch/x86/xen/smp.c | 1 - > > 1 files changed, 0 insertions(+), 1 deletions(-) > > > > diff --git a/arch/x86/xen/smp.c b/arch/x86/xen/smp.c > > index e79dbb9..51339b4 100644 > > --- a/arch/x86/xen/smp.c > > +++ b/arch/x86/xen/smp.c > > @@ -522,7 +522,6 @@ static void __init xen_hvm_smp_prepare_cpus(unsigned int max_cpus) > > WARN_ON(xen_smp_intr_init(0)); > > > > xen_init_lock_cpu(0); > > - xen_init_spinlocks(); > > } > > Should I add this back here on the pv ticketlock branch? I think that Konrad is going to pick it up and send it as an important bug fix, CC'ing stable too. However I also have another patch to enable PV spinlock on HVM again, that relies on your pv ticket lock work. This one should probably go at the end of your series (appended). --- xen: initialize PV spinlocks for HVM guests before patching is done Signed-off-by: Stefano Stabellini diff --git a/arch/x86/xen/smp.c b/arch/x86/xen/smp.c index 51339b4..e24e9a2 100644 --- a/arch/x86/xen/smp.c +++ b/arch/x86/xen/smp.c @@ -551,4 +551,5 @@ void __init xen_hvm_smp_init(void) smp_ops.cpu_die = xen_hvm_cpu_die; smp_ops.send_call_func_ipi = xen_smp_send_call_function_ipi; smp_ops.send_call_func_single_ipi = xen_smp_send_call_function_single_ipi; + xen_init_spinlocks(); } _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel From xen-devel-bounces@lists.xensource.com Thu Sep 08 05:39:19 2011 Return-path: Envelope-to: www-data@lists.xensource.com Delivery-date: Thu, 08 Sep 2011 05:39:19 -0700 Received: from localhost ([127.0.0.1] helo=lists.colo.xensource.com) by lists.xensource.com with esmtp (Exim 4.43) id 1R1dt1-0001Hc-4t; Thu, 08 Sep 2011 05:39:19 -0700 Received: from mail21.messagelabs.com ([85.158.143.35]) by lists.xensource.com with smtp (Exim 4.43) id 1R1dsS-00014p-9e for xen-devel@lists.xensource.com; Thu, 08 Sep 2011 05:38:44 -0700 X-Env-Sender: Stefano.Stabellini@eu.citrix.com X-Msg-Ref: server-8.tower-21.messagelabs.com!1315485506!58214253!1 X-Originating-IP: [62.200.22.115] X-StarScan-Version: 6.3.6; banners=-,-,- X-VirusChecked: Checked Received: (qmail 17368 invoked from network); 8 Sep 2011 12:38:26 -0000 Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115) by server-8.tower-21.messagelabs.com with SMTP; 8 Sep 2011 12:38:26 -0000 X-IronPort-AV: E=Sophos;i="4.68,350,1312156800"; d="scan'208";a="7675413" Received: from lonpmailmx01.citrite.net ([10.30.203.162]) by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5; 08 Sep 2011 12:38:41 +0000 Received: from kaball.uk.xensource.com (10.80.2.59) by LONPMAILMX01.citrite.net (10.30.203.162) with Microsoft SMTP Server id 8.3.137.0; Thu, 8 Sep 2011 13:38:41 +0100 Date: Thu, 8 Sep 2011 13:46:52 +0100 From: Stefano Stabellini X-X-Sender: sstabellini@kaball-desktop To: Jeremy Fitzhardinge In-Reply-To: <4E67A377.3090004@goop.org> Message-ID: References: <1315413571-10938-1-git-send-email-stefano.stabellini@eu.citrix.com> <4E67A377.3090004@goop.org> User-Agent: Alpine 2.00 (DEB 1167 2008-08-23) MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Cc: Ian Campbell , "xen-devel@lists.xensource.com" , "konrad.wilk@oracle.com" , "linux-kernel@vger.kernel.org" , Stefano Stabellini Subject: [Xen-devel] Re: [PATCH v3 1/2] xen: add an "highmem" parameter to alloc_xenballooned_pages X-BeenThere: xen-devel@lists.xensource.com X-Mailman-Version: 2.1.5 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xensource.com Errors-To: xen-devel-bounces@lists.xensource.com On Wed, 7 Sep 2011, Jeremy Fitzhardinge wrote: > > diff --git a/drivers/xen/gntdev.c b/drivers/xen/gntdev.c > > index f914b26..07a56c2 100644 > > --- a/drivers/xen/gntdev.c > > +++ b/drivers/xen/gntdev.c > > @@ -123,7 +123,7 @@ static struct grant_map *gntdev_alloc_map(struct gntdev_priv *priv, int count) > > NULL == add->pages) > > goto err; > > > > - if (alloc_xenballooned_pages(count, add->pages)) > > + if (alloc_xenballooned_pages(count, add->pages, 0 /* lowmem */)) > > If the parameter is "bool" you should pass true/false. But it might be > better to just make it take a GFP_ constant directly. I would rather have a bool to be consistent with the other balloon interfaces. _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel From xen-devel-bounces@lists.xensource.com Thu Sep 08 05:48:40 2011 Return-path: Envelope-to: www-data@lists.xensource.com Delivery-date: Thu, 08 Sep 2011 05:48:40 -0700 Received: from localhost ([127.0.0.1] helo=lists.colo.xensource.com) by lists.xensource.com with esmtp (Exim 4.43) id 1R1e24-0001pV-Iz; Thu, 08 Sep 2011 05:48:40 -0700 Received: from mail216.messagelabs.com ([85.158.143.99]) by lists.xensource.com with smtp (Exim 4.43) id 1R1e1X-0001dP-1w for xen-devel@lists.xensource.com; Thu, 08 Sep 2011 05:48:07 -0700 X-Env-Sender: Stefano.Stabellini@eu.citrix.com X-Msg-Ref: server-12.tower-216.messagelabs.com!1315486084!11804057!1 X-Originating-IP: [62.200.22.115] X-StarScan-Version: 6.3.6; banners=-,-,- X-VirusChecked: Checked Received: (qmail 17783 invoked from network); 8 Sep 2011 12:48:04 -0000 Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115) by server-12.tower-216.messagelabs.com with SMTP; 8 Sep 2011 12:48:04 -0000 X-IronPort-AV: E=Sophos;i="4.68,350,1312156800"; d="scan'208";a="7675647" Received: from lonpmailmx01.citrite.net ([10.30.203.162]) by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5; 08 Sep 2011 12:47:54 +0000 Received: from kaball.uk.xensource.com (10.80.2.59) by LONPMAILMX01.citrite.net (10.30.203.162) with Microsoft SMTP Server id 8.3.137.0; Thu, 8 Sep 2011 13:47:54 +0100 Date: Thu, 8 Sep 2011 13:56:05 +0100 From: Stefano Stabellini X-X-Sender: sstabellini@kaball-desktop To: Konrad Rzeszutek Wilk In-Reply-To: <20110907222749.GA23258@dumpdata.com> Message-ID: References: <1315413571-10938-2-git-send-email-stefano.stabellini@eu.citrix.com> <20110907222749.GA23258@dumpdata.com> User-Agent: Alpine 2.00 (DEB 1167 2008-08-23) MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Cc: Ian Campbell , "jeremy@goop.org" , "xen-devel@lists.xensource.com" , "linux-kernel@vger.kernel.org" , Stefano Stabellini Subject: [Xen-devel] Re: [PATCH v3 2/2] xen: modify kernel mappings corresponding to granted pages X-BeenThere: xen-devel@lists.xensource.com X-Mailman-Version: 2.1.5 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xensource.com Errors-To: xen-devel-bounces@lists.xensource.com On Wed, 7 Sep 2011, Konrad Rzeszutek Wilk wrote: > > diff --git a/arch/x86/xen/p2m.c b/arch/x86/xen/p2m.c > > index 58efeb9..6c26ac80 100644 > > --- a/arch/x86/xen/p2m.c > > +++ b/arch/x86/xen/p2m.c > > @@ -161,7 +161,9 @@ > > #include > > #include > > #include > > +#include > > > > +#include "multicalls.h" > > #include "xen-ops.h" > > > > static void __init m2p_override_init(void); > > @@ -676,7 +678,8 @@ static unsigned long mfn_hash(unsigned long mfn) > > } > > > > /* Add an MFN override for a particular page */ > > -int m2p_add_override(unsigned long mfn, struct page *page, bool clear_pte) > > +int m2p_add_override(unsigned long mfn, struct page *page, > > + struct gnttab_map_grant_ref *kmap_op) > > So how come you ripped out 'clear_pte' here but left it in > m2p_remove_override? Is it b/c you aren't doing the pte_clear in > the first place? Because the "clear_pte" has been replaced with a proper update of the kernel mappings for these pages. If the caller doesn't need that, it can just pass NULL. > Also there are other users of 'm2p_add_override' that you hadn't modified > (blkback.c) so it will cause an compile failure. > > Please also test this patchset with the blkback in the picture to make > sure this: cf8d91633ddef9e816ccbf3da833c79ce508988d > does not happen. I think I didn't find a compilation problem because false becomes NULL with my compiler. Fixed now. > > { > > unsigned long flags; > > unsigned long pfn; > > @@ -699,9 +702,20 @@ int m2p_add_override(unsigned long mfn, struct page *page, bool clear_pte) > > if (unlikely(!set_phys_to_machine(pfn, FOREIGN_FRAME(mfn)))) > > return -ENOMEM; > > > > - if (clear_pte && !PageHighMem(page)) > > - /* Just zap old mapping for now */ > > - pte_clear(&init_mm, address, ptep); > > + if (kmap_op != NULL) { > > + if (!PageHighMem(page)) { > > + struct multicall_space mcs = xen_mc_entry(sizeof(*kmap_op)); > > + > > + MULTI_grant_table_op(mcs.mc, > > + GNTTABOP_map_grant_ref, kmap_op, 1); > > + > > + xen_mc_issue(PARAVIRT_LAZY_MMU); > > + } > > + page->private |= GRANT_FRAME_BIT; > > + /* let's use dev_bus_addr to record the old mfn instead */ > > + kmap_op->dev_bus_addr = page->index; > > + page->index = (unsigned long) kmap_op; > > + } > > spin_lock_irqsave(&m2p_override_lock, flags); > > list_add(&page->lru, &m2p_overrides[mfn_hash(mfn)]); > > spin_unlock_irqrestore(&m2p_override_lock, flags); > > @@ -735,13 +749,44 @@ int m2p_remove_override(struct page *page, bool clear_pte) > > spin_lock_irqsave(&m2p_override_lock, flags); > > list_del(&page->lru); > > spin_unlock_irqrestore(&m2p_override_lock, flags); > > - set_phys_to_machine(pfn, page->index); > > > > - if (clear_pte && !PageHighMem(page)) > > - set_pte_at(&init_mm, address, ptep, > > - pfn_pte(pfn, PAGE_KERNEL)); > > - /* No tlb flush necessary because the caller already > > - * left the pte unmapped. */ > > + if (clear_pte) { > > + struct gnttab_map_grant_ref *map_op = > > + (struct gnttab_map_grant_ref *) page->index; > > + set_phys_to_machine(pfn, map_op->dev_bus_addr); > > + if (!PageHighMem(page)) { > > + struct multicall_space mcs = > > + xen_mc_entry(sizeof(struct gnttab_unmap_grant_ref)); > > + struct gnttab_unmap_grant_ref *unmap_op = mcs.args; > > + > > + /* > > scripts/checkpath.pl will throw a fit at the above. > right, fixed. _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel From xen-devel-bounces@lists.xensource.com Thu Sep 08 05:58:37 2011 Return-path: Envelope-to: www-data@lists.xensource.com Delivery-date: Thu, 08 Sep 2011 05:58:37 -0700 Received: from localhost ([127.0.0.1] helo=lists.colo.xensource.com) by lists.xensource.com with esmtp (Exim 4.43) id 1R1eBQ-0003GW-GZ; Thu, 08 Sep 2011 05:58:20 -0700 Received: from mail182.messagelabs.com ([85.158.139.83]) by lists.xensource.com with esmtp (Exim 4.43) id 1R1eAA-00031c-3o for xen-devel@lists.xensource.com; Thu, 08 Sep 2011 05:57:02 -0700 X-Env-Sender: konrad@dumpdata.com X-Msg-Ref: server-7.tower-182.messagelabs.com!1315486617!12551329!1 X-Originating-IP: [148.87.113.117] X-StarScan-Version: 6.3.6; banners=-,-,- X-VirusChecked: Checked Received: (qmail 25098 invoked from network); 8 Sep 2011 12:56:58 -0000 Received: from rcsinet15.oracle.com (HELO rcsinet15.oracle.com) (148.87.113.117) by server-7.tower-182.messagelabs.com with DHE-RSA-AES256-SHA encrypted SMTP; 8 Sep 2011 12:56:58 -0000 Received: from rtcsinet22.oracle.com (rtcsinet22.oracle.com [66.248.204.30]) by rcsinet15.oracle.com (Switch-3.4.4/Switch-3.4.4) with ESMTP id p88CursE000738 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Thu, 8 Sep 2011 12:56:55 GMT Received: from acsmt358.oracle.com (acsmt358.oracle.com [141.146.40.158]) by rtcsinet22.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id p88CuqBp014292 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 8 Sep 2011 12:56:53 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 p88CukPU010253; Thu, 8 Sep 2011 07:56:46 -0500 Received: from phenom (/209.6.55.207) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Thu, 08 Sep 2011 05:56:46 -0700 Received: by phenom (Postfix, from userid 1000) id 83593FD1; Thu, 8 Sep 2011 08:56:32 -0400 (EDT) Date: Thu, 8 Sep 2011 08:56:32 -0400 From: Konrad Rzeszutek Wilk To: Attila Jecs Subject: Re: [Xen-devel] Re: [Xen-users] nvidia-drivers Message-ID: <20110908125632.GB28591@dumpdata.com> References: <20110831115147.GA4297@dumpdata.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.21 (2010-09-15) X-Source-IP: rtcsinet22.oracle.com [66.248.204.30] X-CT-RefId: str=0001.0A090202.4E68BB98.0050,ss=1,re=0.000,fgs=0 Cc: xen-devel@lists.xensource.com X-BeenThere: xen-devel@lists.xensource.com X-Mailman-Version: 2.1.5 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xensource.com Errors-To: xen-devel-bounces@lists.xensource.com On Thu, Sep 08, 2011 at 01:02:56PM +0200, Attila Jecs wrote: > never tried nouveau. > nopat on what command line? > kernel? xen? X? First of don't remove the CC off xen-devel. I've added that back. The nopat on the Linux command line. > > 2011/8/31 Konrad Rzeszutek Wilk > > > On Wed, Aug 31, 2011 at 12:59:38AM -0400, Todd Deshane wrote: > > > On Tue, Aug 30, 2011 at 6:21 AM, Attila Jecs > > wrote: > > > > Hello list! > > > > Well, nvidia-drivers stopped working with recent kernels (3.1) > > > > > > Adding Konrad, Pasi, and xen-devel for some more exposure on this. > > > > Hey Todd, > > > > Thanks for copying me. Attila, does the nouveau driver work? > > What happens if you use 'nopat' on the command line? > > > > > > Debugging tips: > > > > > http://wiki.xensource.com/xenwiki/XenParavirtOps#head-a9407515fe25400d0da2787d12819ec84cca9f3c > > > > > > Known issues: > > > http://wiki.xensource.com/xenwiki/Linux_30_bugs > > > > > > > My monitor tells me there is no signal, after X loaded. > > > > I'm using gentoo (~amd64). > > > > [ebuild R ] x11-base/xorg-server-1.10.4 USE="nptl udev xorg -dmx > > -doc > > > > -ipv6 -kdrive -minimal -static-libs -tslib -xnest -xvfb" 0 kB > > > > [ebuild R ] app-emulation/xen-4.1.1 USE="custom-cflags -acm > > -debug > > > > -flask -pae -xsm" 0 kB > > > > [ebuild R ] sys-kernel/git-sources-3.1_rc3-r6 USE="symlink > > -build" 0 > > > > kB > > > > [ebuild R ] x11-drivers/nvidia-drivers-275.09.07 USE="acpi > > > > custom-cflags -gtk (-multilib)" 0 kB > > > > dreamer welder # tail /var/log/Xorg.0.log.old > > > > [ 33.649] (==) NVIDIA(0): > > > > > > > > > > > > [ 33.649] (II) NVIDIA(0): Validated modes: > > > > > > > > > > > > [ 33.649] (II) NVIDIA(0): "nvidia-auto-select" > > > > [ 33.650] (II) NVIDIA(0): Virtual screen size determined to be 1366 > > x 768 > > > > [ 33.691] (--) NVIDIA(0): DPI set to (84, 84); computed from > > "UseEdidDpi" > > > > X config > > > > [ 33.691] (--) NVIDIA(0): option > > > > [ 33.691] (--) Depth 24 pixmap format is 32 bpp > > > > [ 33.691] (II) NVIDIA: Using 768.00 MB of virtual memory for > > indirect > > > > memory access. > > > > [ 55.247] (II) NVIDIA(0): Setting mode "nvidia-auto-select" > > > > [ 64.501] (EE) NVIDIA(0): WAIT: (E, 0, 0x827d, 0) > > > > dreamer welder # grep NVRM /var/log/messages > > > > Aug 28 15:09:31 localhost kernel: NVRM: PAT configuration unsupported, > > > > falling back to MTRRs. > > > > Aug 28 15:09:44 localhost kernel: NVRM: Xid (0000:02:00): 56, CMDre > > 00000000 > > > > 00000eb0 4e59b22f 00000003 00000000 > > > > Aug 28 15:09:44 localhost kernel: NVRM: Xid (0000:02:00): 56, CMDre > > 00000000 > > > > 00000eb0 4e59b22f 00000003 00000000 > > > > Aug 28 15:09:44 localhost kernel: NVRM: Xid (0000:02:00): 56, CMDre > > 00000000 > > > > 00000eb0 4e59b22f 00000003 00000000 > > > > Aug 28 15:09:44 localhost kernel: NVRM: Xid (0000:02:00): 56, CMDre > > 00000000 > > > > 00000eb0 00000000 00000003 00000000 > > > > Aug 28 15:09:44 localhost kernel: NVRM: Xid (0000:02:00): 56, CMDre > > 00000000 > > > > 00000eb0 00000000 00000003 00000000 > > > > Aug 28 15:09:48 localhost kernel: NVRM: Xid (0000:02:00): 6, PE007e > > > > Aug 28 15:09:48 localhost kernel: NVRM: Xid (0000:02:00): 6, PE007e > > > > Aug 28 15:09:48 localhost kernel: NVRM: Xid (0000:02:00): 6, PE007e > > > > Aug 28 15:09:48 localhost kernel: NVRM: Xid (0000:02:00): 6, PE007e > > > > Aug 28 15:09:48 localhost kernel: NVRM: Xid (0000:02:00): 6, PE007e > > > > Chances that i can get this to work with your help? > > > > -- > > > > Attila Jecs > > > > _______________________________________________ > > > > Xen-users mailing list > > > > Xen-users@lists.xensource.com > > > > http://lists.xensource.com/xen-users > > > > > > > > > > > > > > > > -- > > > Todd Deshane > > > http://www.linkedin.com/in/deshantm > > > http://www.xen.org/products/cloudxen.html > > > http://runningxen.com/ > > > > > > _______________________________________________ > > > Xen-devel mailing list > > > Xen-devel@lists.xensource.com > > > http://lists.xensource.com/xen-devel > > > > > > -- > Attila Jecs _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel From xen-devel-bounces@lists.xensource.com Thu Sep 08 06:02:39 2011 Return-path: Envelope-to: www-data@lists.xensource.com Delivery-date: Thu, 08 Sep 2011 06:02:39 -0700 Received: from localhost ([127.0.0.1] helo=lists.colo.xensource.com) by lists.xensource.com with esmtp (Exim 4.43) id 1R1eFa-0003gY-0B; Thu, 08 Sep 2011 06:02:38 -0700 Received: from mail216.messagelabs.com ([85.158.143.99]) by lists.xensource.com with esmtp (Exim 4.43) id 1R1eCq-0003QS-K7 for xen-devel@lists.xensource.com; Thu, 08 Sep 2011 05:59:51 -0700 X-Env-Sender: konrad@dumpdata.com X-Msg-Ref: server-6.tower-216.messagelabs.com!1315486784!16279006!1 X-Originating-IP: [148.87.113.117] X-StarScan-Version: 6.3.6; banners=-,-,- X-VirusChecked: Checked Received: (qmail 29166 invoked from network); 8 Sep 2011 12:59:45 -0000 Received: from rcsinet15.oracle.com (HELO rcsinet15.oracle.com) (148.87.113.117) by server-6.tower-216.messagelabs.com with DHE-RSA-AES256-SHA encrypted SMTP; 8 Sep 2011 12:59:45 -0000 Received: from acsinet21.oracle.com (acsinet21.oracle.com [141.146.126.237]) by rcsinet15.oracle.com (Switch-3.4.4/Switch-3.4.4) with ESMTP id p88CxfOl008398 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Thu, 8 Sep 2011 12:59:43 GMT Received: from acsmt357.oracle.com (acsmt357.oracle.com [141.146.40.157]) by acsinet21.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id p88CxefK013673 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 8 Sep 2011 12:59:41 GMT Received: from abhmt102.oracle.com (abhmt102.oracle.com [141.146.116.54]) by acsmt357.oracle.com (8.12.11.20060308/8.12.11) with ESMTP id p88CxZ1Y009077; Thu, 8 Sep 2011 07:59:35 -0500 Received: from phenom (/209.6.55.207) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Thu, 08 Sep 2011 05:59:35 -0700 Received: by phenom (Postfix, from userid 1000) id 270EBFD1; Thu, 8 Sep 2011 08:59:21 -0400 (EDT) Date: Thu, 8 Sep 2011 08:59:21 -0400 From: Konrad Rzeszutek Wilk To: Eric Camachat Subject: Re: [Xen-devel] Can I specify a physical memory region for a domU Message-ID: <20110908125920.GC28591@dumpdata.com> References: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.21 (2010-09-15) X-Source-IP: acsinet21.oracle.com [141.146.126.237] X-Auth-Type: Internal IP X-CT-RefId: str=0001.0A090206.4E68BC3F.0063:SCFMA922111,ss=1,re=-4.000,fgs=0 Cc: xen-devel@lists.xensource.com X-BeenThere: xen-devel@lists.xensource.com X-Mailman-Version: 2.1.5 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xensource.com Errors-To: xen-devel-bounces@lists.xensource.com On Wed, Sep 07, 2011 at 05:47:46PM -0700, Eric Camachat wrote: > Hi, > > I am porting our drivers to XEN's PV domU (with PV PCI passthrouth), I Use the DMA API that Linux provides (I presume that is what you meant by PV DomU), and use the dma_alloc_coherent to set your regions. Also pass in 'iommu=soft' on your Linux command line to enable the Xen SWIOTLB DMA system. > have to allocate a memory block and tell the hardware to access it. > But the hardware can address 32-bit only, so I want dedicate a region > of memory that below 2GB for the domU only. Uh, don't you mean 4GB? - 32bit is up to 4GB. > How do that in XEN? > > Thanks, > /Eric > > _______________________________________________ > Xen-devel mailing list > Xen-devel@lists.xensource.com > http://lists.xensource.com/xen-devel _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel From xen-devel-bounces@lists.xensource.com Thu Sep 08 06:13:15 2011 Return-path: Envelope-to: www-data@lists.xensource.com Delivery-date: Thu, 08 Sep 2011 06:13:15 -0700 Received: from localhost ([127.0.0.1] helo=lists.colo.xensource.com) by lists.xensource.com with esmtp (Exim 4.43) id 1R1ePr-0004CW-AR; Thu, 08 Sep 2011 06:13:15 -0700 Received: from mail21.messagelabs.com ([85.158.143.35]) by lists.xensource.com with esmtp (Exim 4.43) id 1R1eOw-000401-1B for xen-devel@lists.xensource.com; Thu, 08 Sep 2011 06:12:18 -0700 X-Env-Sender: konrad@dumpdata.com X-Msg-Ref: server-15.tower-21.messagelabs.com!1315487534!49828666!1 X-Originating-IP: [148.87.113.117] X-StarScan-Version: 6.3.6; banners=-,-,- X-VirusChecked: Checked Received: (qmail 29696 invoked from network); 8 Sep 2011 13:12:15 -0000 Received: from rcsinet15.oracle.com (HELO rcsinet15.oracle.com) (148.87.113.117) by server-15.tower-21.messagelabs.com with DHE-RSA-AES256-SHA encrypted SMTP; 8 Sep 2011 13:12:15 -0000 Received: from acsinet22.oracle.com (acsinet22.oracle.com [141.146.126.238]) by rcsinet15.oracle.com (Switch-3.4.4/Switch-3.4.4) with ESMTP id p88DCA0O002089 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Thu, 8 Sep 2011 13:12:12 GMT Received: from acsmt356.oracle.com (acsmt356.oracle.com [141.146.40.156]) by acsinet22.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id p88DC9Lv018296 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 8 Sep 2011 13:12:09 GMT Received: from abhmt110.oracle.com (abhmt110.oracle.com [141.146.116.62]) by acsmt356.oracle.com (8.12.11.20060308/8.12.11) with ESMTP id p88DC3PT032330; Thu, 8 Sep 2011 08:12:04 -0500 Received: from phenom (/209.6.55.207) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Thu, 08 Sep 2011 06:12:03 -0700 Received: by phenom (Postfix, from userid 1000) id 88D2BFD1; Thu, 8 Sep 2011 09:11:49 -0400 (EDT) Date: Thu, 8 Sep 2011 09:11:49 -0400 From: Konrad Rzeszutek Wilk To: Jan Beulich Subject: Re: [Xen-devel] blkfront problem in pvops kernel when barriers enabled Message-ID: <20110908131149.GA28944@dumpdata.com> References: <4E6357C6.6050101@mimuw.edu.pl> <20110906163213.GC5264@dumpdata.com> <4E665572.7080009@mimuw.edu.pl> <20110907014741.GD30639@dumpdata.com> <4E675A980200007800055050@nat28.tlf.novell.com> <4E6761630200007800055087@nat28.tlf.novell.com> <20110907174158.GL32190@dumpdata.com> <4E6893910200007800055376@nat28.tlf.novell.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <4E6893910200007800055376@nat28.tlf.novell.com> User-Agent: Mutt/1.5.21 (2010-09-15) X-Source-IP: acsinet22.oracle.com [141.146.126.238] X-Auth-Type: Internal IP X-CT-RefId: str=0001.0A090206.4E68BF2D.0001:SCFMA922111,ss=1,re=-4.000,fgs=0 Cc: "xen-devel@lists.xensource.com" , Marek Marczykowski X-BeenThere: xen-devel@lists.xensource.com X-Mailman-Version: 2.1.5 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xensource.com Errors-To: xen-devel-bounces@lists.xensource.com On Thu, Sep 08, 2011 at 09:06:09AM +0100, Jan Beulich wrote: > >>> On 07.09.11 at 19:41, Konrad Rzeszutek Wilk wrote: > >> >> > >> >> > >> >> I can only think of 2.6.38-3 XenOLinux doing it - and it is a bug > >> >> to do it. It really ought to _not_ advertise 'feature-barrier' and > >> >> instead advertise 'feature-flush-cache'. > >> > > >> > Indeed, I see that I added feature-flush-cache support to the frontend > >> > back then, but neglected to do so for the backend. Partly perhaps > >> > because I'm not much of a (block, network, ...) driver person... > >> > > >> > However, what I'm not understanding with dropping feature-barrier > >> > support from the backend - how do you deal with old frontends > >> > wanting to use barriers? I'm currently converting them into > > > > Just not supporting them. I know it is incredibly bad to do so - but > > I have not had a chance to write the code to emulate the 'feature-barrier' > > correctly. > > > >> > WRITE_FLUSH_FUA operations in the backend as a (hopefully) best > >> > effort approach. > > > > I am not sure. I need to run blktrace|blkparse to make sure it does the > > right think as compared to a WRITE_BARRIER. Lets ask Christopher Hellwig - he > > knows a lot of this. > > > >> > >> Also I notice you're using WRITE_ODIRECT - what's the background > >> of that? > > > > Ah, > > http://git.drbd.org/linux-2.6-drbd.git/?p=linux-2.6-drbd.git;a=commit;h=013c3 > > ca184851078b9c04744efd4d47e52c6ecf8 > > Hmm, that seems more like a band-aid than a real solution. What if with > another scheduler (or after some changes to CFQ) REQ_SYNC actually > hurts (as - without any data - I would have expected)? Can't/shouldn't > the use of REQ_SYNC be made at least dependent on the scheduler in > use on the queue? This is what the header fine says about async vs sync: * All IO is handled async in Linux. This is fine for background * writes, but for reads or writes that someone waits for completion * on, we want to notify the block layer and IO scheduler so that they * know about it. That allows them to make better scheduling * decisions. So when the below references 'sync' and 'async', it * is referencing this priority hint. To make sure I was not shooting myself in the foot, I did the change and also made sure the other schedules worked without any regressions in speeds. But keep in mind that this 'WRITE_ODIRECT' behavior is also used by AIO, and by any userspace application that stick O_DIRECT on the open call. So if another another scheduler breaks this behavior we are not the only one affected. _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel From xen-devel-bounces@lists.xensource.com Thu Sep 08 06:18:57 2011 Return-path: Envelope-to: www-data@lists.xensource.com Delivery-date: Thu, 08 Sep 2011 06:18:57 -0700 Received: from localhost ([127.0.0.1] helo=lists.colo.xensource.com) by lists.xensource.com with esmtp (Exim 4.43) id 1R1eVN-0005z7-AA; Thu, 08 Sep 2011 06:18:57 -0700 Received: from mail27.messagelabs.com ([193.109.254.147]) by lists.xensource.com with esmtp (Exim 4.43) id 1R1eUs-0005m6-PZ for xen-devel@lists.xensource.com; Thu, 08 Sep 2011 06:18:27 -0700 X-Env-Sender: Andrew.Cooper3@citrix.com X-Msg-Ref: server-5.tower-27.messagelabs.com!1315487884!44044139!1 X-Originating-IP: [66.165.176.63] X-StarScan-Version: 6.3.6; banners=-,-,- X-VirusChecked: Checked Received: (qmail 26886 invoked from network); 8 Sep 2011 13:18:05 -0000 Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63) by server-5.tower-27.messagelabs.com with RC4-SHA encrypted SMTP; 8 Sep 2011 13:18:05 -0000 X-IronPort-AV: E=Sophos;i="4.68,350,1312171200"; d="scan'208";a="162150189" Received: from ftlpmailmx02.citrite.net ([10.13.107.66]) by FTLPIPO02.CITRIX.COM with ESMTP/TLS/RC4-MD5; 08 Sep 2011 09:18:21 -0400 Received: from [10.80.2.18] (10.80.2.18) by FTLPMAILMX02.citrite.net (10.13.107.66) with Microsoft SMTP Server id 8.3.137.0; Thu, 8 Sep 2011 09:18:21 -0400 Message-ID: <4E68C09B.8050409@citrix.com> Date: Thu, 8 Sep 2011 14:18:19 +0100 From: Andrew Cooper User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.2.21) Gecko/20110831 Lightning/1.0b2 Thunderbird/3.1.13 MIME-Version: 1.0 To: Jan Beulich References: <4E689D9A.1020405@citrix.com> <4E68C6C10200007800055485@nat28.tlf.novell.com> In-Reply-To: <4E68C6C10200007800055485@nat28.tlf.novell.com> Content-Type: multipart/mixed; boundary="------------010605040307090601030904" Cc: Keir Fraser , "xen-devel@lists.xensource.com" Subject: [Xen-devel] Re: 4.0/4.1 requests - IO-APIC EOI [RFC] X-BeenThere: xen-devel@lists.xensource.com X-Mailman-Version: 2.1.5 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xensource.com Errors-To: xen-devel-bounces@lists.xensource.com --------------010605040307090601030904 Content-Type: text/plain; charset="ISO-8859-1" Content-Transfer-Encoding: 7bit --- SNIP --- Attached is my first attempt at expanding the EOI to work on older IO-APICs. It has not undergone any significant testing yet. Does this look suitable? -- Andrew Cooper - Dom0 Kernel Engineer, Citrix XenServer T: +44 (0)1223 225 900, http://www.citrix.com --------------010605040307090601030904 Content-Type: text/x-patch; name="IO-APIC-eoi.patch" Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename="IO-APIC-eoi.patch" diff -r 0268e7380953 xen/arch/x86/io_apic.c --- a/xen/arch/x86/io_apic.c Mon Sep 05 15:10:28 2011 +0100 +++ b/xen/arch/x86/io_apic.c Thu Sep 08 14:17:31 2011 +0100 @@ -357,7 +357,7 @@ static void __eoi_IO_APIC_irq(unsigned i pin = entry->pin; if (pin == -1) break; - io_apic_eoi(entry->apic, vector); + io_apic_eoi_vector(entry->apic, vector); if (!entry->next) break; entry = irq_2_pin + entry->next; @@ -397,18 +397,7 @@ static void clear_IO_APIC_pin(unsigned i entry.trigger = 1; __ioapic_write_entry(apic, pin, TRUE, entry); } - if (mp_ioapics[apic].mpc_apicver >= 0x20) - io_apic_eoi(apic, entry.vector); - else { - /* - * Mechanism by which we clear remoteIRR in this case is by - * changing the trigger mode to edge and back to level. - */ - entry.trigger = 0; - __ioapic_write_entry(apic, pin, TRUE, entry); - entry.trigger = 1; - __ioapic_write_entry(apic, pin, TRUE, entry); - } + io_apic_eoi_pin(apic, pin); } /* @@ -1750,7 +1739,7 @@ static void end_level_ioapic_irq (unsign { int ioapic; for (ioapic = 0; ioapic < nr_ioapics; ioapic++) - io_apic_eoi(ioapic, i); + io_apic_eoi_vector(ioapic, i); } v = apic_read(APIC_TMR + ((i & ~0x1f) >> 1)); @@ -2622,3 +2611,67 @@ void __init init_ioapic_mappings(void) printk(XENLOG_INFO "IRQ limits: %u GSI, %u MSI/MSI-X\n", nr_irqs_gsi, nr_irqs - nr_irqs_gsi); } + +/* EOI an IO-APIC entry given the vector it points to */ +void io_apic_eoi_vector(unsigned int apic, unsigned int vector) +{ + unsigned int flags; + + spin_lock_irqsave(&ioapic_lock, flags); + + if ( ioapic_has_eoi_reg(apic) ) + /* Prefer the use of the EOI register if available */ + *(IO_APIC_BASE(apic)+16) = vector; + else + { + /* Else search through the IO-APIC entries to find the + * correct pin */ + struct IO_APIC_route_entry entry; + unsigned int pin = 0; + + do + { + entry = __ioapic_read_entry(apic, pin, TRUE); + + if ( entry.vector == vector ) + { + /* And if found, fake an EOI by flipping the + * trigger mode to edge and back */ + entry.trigger = 0; + __ioapic_write_entry(apic, pin, TRUE, entry); + entry.trigger = 1; + __ioapic_write_entry(apic, pin, TRUE, entry); + break; + } + + } while ( pin++ < nr_ioapic_registers[apic] ); + } + + spin_unlock_irqrestore(&ioapic_lock, flags); +} + +/* EOI an IO-APIC entry given its pin */ +void io_apic_eoi_pin(unsigned int apic, unsigned int pin) +{ + struct IO_APIC_route_entry entry; + unsigned int flags; + + entry = __ioapic_read_entry(apic, pin, TRUE); + + spin_lock_irqsave(&ioapic_lock, flags); + + if ( ioapic_has_eoi_reg(apic) ) + /* Prefer the use of the EOI register if available */ + *(IO_APIC_BASE(apic)+16) = entry.vector; + else + { + /* Else fake an EOI by switching to edge triggered mode + * and back */ + entry.trigger = 0; + __ioapic_write_entry(apic, pin, TRUE, entry); + entry.trigger = 1; + __ioapic_write_entry(apic, pin, TRUE, entry); + } + + spin_unlock_irqrestore(&ioapic_lock, flags); +} diff -r 0268e7380953 xen/include/asm-x86/io_apic.h --- a/xen/include/asm-x86/io_apic.h Mon Sep 05 15:10:28 2011 +0100 +++ b/xen/include/asm-x86/io_apic.h Thu Sep 08 14:17:31 2011 +0100 @@ -157,10 +157,9 @@ static inline void io_apic_write(unsigne __io_apic_write(apic, reg, value); } -static inline void io_apic_eoi(unsigned int apic, unsigned int vector) -{ - *(IO_APIC_BASE(apic)+16) = vector; -} +#define ioapic_has_eoi_reg(apic) (mp_ioapics[(apic)].mpc_apicver >= 0x20) +void io_apic_eoi_vector(unsigned int apic, unsigned int vector); +void io_apic_eoi_pin(unsigned int apic, unsigned int pin); /* * Re-write a value: to be used for read-modify-write --------------010605040307090601030904 Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel --------------010605040307090601030904-- From xen-devel-bounces@lists.xensource.com Thu Sep 08 06:29:05 2011 Return-path: Envelope-to: www-data@lists.xensource.com Delivery-date: Thu, 08 Sep 2011 06:29:05 -0700 Received: from localhost ([127.0.0.1] helo=lists.colo.xensource.com) by lists.xensource.com with esmtp (Exim 4.43) id 1R1efB-0006V1-4V; Thu, 08 Sep 2011 06:29:05 -0700 Received: from mail174.messagelabs.com ([85.158.138.51]) by lists.xensource.com with smtp (Exim 4.43) id 1R1eeP-0006IU-O5 for xen-devel@lists.xensource.com; Thu, 08 Sep 2011 06:28:18 -0700 X-Env-Sender: Ian.Jackson@eu.citrix.com X-Msg-Ref: server-9.tower-174.messagelabs.com!1315488492!24685501!1 X-Originating-IP: [62.200.22.115] X-StarScan-Version: 6.3.6; banners=-,-,- X-VirusChecked: Checked Received: (qmail 11958 invoked from network); 8 Sep 2011 13:28:13 -0000 Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115) by server-9.tower-174.messagelabs.com with SMTP; 8 Sep 2011 13:28:13 -0000 X-IronPort-AV: E=Sophos;i="4.68,350,1312156800"; d="scan'208";a="7676835" Received: from lonpmailmx01.citrite.net ([10.30.203.162]) by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5; 08 Sep 2011 13:28:00 +0000 Received: from woking.xci-test.com (10.80.248.135) by smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id 8.3.137.0; Thu, 8 Sep 2011 14:27:58 +0100 Received: from osstest by woking.xci-test.com with local (Exim 4.69) (envelope-from ) id 1R1ee5-0003ng-TP; Thu, 08 Sep 2011 14:27:57 +0100 To: Message-ID: From: xen.org Date: Thu, 8 Sep 2011 14:27:57 +0100 MIME-Version: 1.0 Content-Type: text/plain Cc: ian.jackson@eu.citrix.com Subject: [Xen-devel] [xen-unstable test] 8862: tolerable FAIL - PUSHED X-BeenThere: xen-devel@lists.xensource.com X-Mailman-Version: 2.1.5 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xensource.com Errors-To: xen-devel-bounces@lists.xensource.com flight 8862 xen-unstable real [real] http://www.chiark.greenend.org.uk/~xensrcts/logs/8862/ Failures :-/ but no regressions. Tests which did not succeed, but are not blocking, including regressions (tests previously passed) regarded as allowable: test-amd64-amd64-xl-pcipt-intel 9 guest-start fail never pass test-amd64-i386-rhel6hvm-intel 9 guest-start.2 fail never pass test-amd64-i386-rhel6hvm-amd 9 guest-start.2 fail never pass test-amd64-i386-win-vcpus1 16 leak-check/check fail never pass test-amd64-i386-xl-win-vcpus1 13 guest-stop fail never pass test-amd64-amd64-win 16 leak-check/check fail never pass test-amd64-i386-win 16 leak-check/check fail never pass test-amd64-amd64-xl-win 13 guest-stop fail never pass test-i386-i386-xl-win 13 guest-stop fail never pass test-i386-i386-win 16 leak-check/check fail never pass version targeted for testing: xen bdd19847ae63 baseline version: xen 5fe770c8a8a3 ------------------------------------------------------------ People who touched revisions under test: Ian Jackson Jan Beulich Keir Fraser Olaf Hering ------------------------------------------------------------ jobs: build-amd64 pass build-i386 pass build-amd64-oldkern pass build-i386-oldkern pass build-amd64-pvops pass build-i386-pvops pass test-amd64-amd64-xl pass test-amd64-i386-xl pass test-i386-i386-xl pass test-amd64-i386-rhel6hvm-amd fail test-amd64-i386-xl-credit2 pass test-amd64-amd64-xl-pcipt-intel fail test-amd64-i386-rhel6hvm-intel fail test-amd64-i386-xl-multivcpu pass test-amd64-amd64-pair pass test-amd64-i386-pair pass test-i386-i386-pair pass test-amd64-amd64-pv pass test-amd64-i386-pv pass test-i386-i386-pv pass test-amd64-amd64-xl-sedf pass test-amd64-i386-win-vcpus1 fail test-amd64-i386-xl-win-vcpus1 fail test-amd64-amd64-win fail test-amd64-i386-win fail test-i386-i386-win fail test-amd64-amd64-xl-win fail test-i386-i386-xl-win fail ------------------------------------------------------------ sg-report-flight on woking.cam.xci-test.com logs: /home/xc_osstest/logs images: /home/xc_osstest/images Logs, config files, etc. are available at http://www.chiark.greenend.org.uk/~xensrcts/logs Test harness code can be found at http://xenbits.xensource.com/gitweb?p=osstest.git;a=summary Pushing revision : + branch=xen-unstable + revision=bdd19847ae63 + . cri-lock-repos ++ . cri-common +++ umask 002 +++ getconfig Repos +++ perl -e ' use Osstest; readconfigonly(); print $c{Repos} or die $!; ' ++ repos=/export/home/osstest/repos ++ repos_lock=/export/home/osstest/repos/lock ++ '[' x '!=' x/export/home/osstest/repos/lock ']' ++ OSSTEST_REPOS_LOCK_LOCKED=/export/home/osstest/repos/lock ++ exec with-lock-ex -w /export/home/osstest/repos/lock ./ap-push xen-unstable bdd19847ae63 + branch=xen-unstable + revision=bdd19847ae63 + . cri-lock-repos ++ . cri-common +++ umask 002 +++ getconfig Repos +++ perl -e ' use Osstest; readconfigonly(); print $c{Repos} or die $!; ' ++ repos=/export/home/osstest/repos ++ repos_lock=/export/home/osstest/repos/lock ++ '[' x/export/home/osstest/repos/lock '!=' x/export/home/osstest/repos/lock ']' + : xen@xenbits.xensource.com + : xen@xenbits.xensource.com:git/linux-pvops + : master + : tested/2.6.39.x + case "$branch" in + cd /export/home/osstest/repos/xen-unstable.hg + hg push -r bdd19847ae63 ssh://xen@xenbits.xensource.com/HG/xen-unstable.hg pushing to ssh://xen@xenbits.xensource.com/HG/xen-unstable.hg searching for changes remote: adding changesets remote: adding manifests remote: adding file changes remote: added 3 changesets with 7 changes to 7 files _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel From xen-devel-bounces@lists.xensource.com Thu Sep 08 06:37:44 2011 Return-path: Envelope-to: www-data@lists.xensource.com Delivery-date: Thu, 08 Sep 2011 06:37:44 -0700 Received: from localhost ([127.0.0.1] helo=lists.colo.xensource.com) by lists.xensource.com with esmtp (Exim 4.43) id 1R1enY-00084z-8n; Thu, 08 Sep 2011 06:37:44 -0700 Received: from mail27.messagelabs.com ([193.109.254.147]) by lists.xensource.com with smtp (Exim 4.43) id 1R1en9-0007tH-A3 for xen-devel@lists.xensource.com; Thu, 08 Sep 2011 06:37:19 -0700 X-Env-Sender: juergen.gross@ts.fujitsu.com X-Msg-Ref: server-6.tower-27.messagelabs.com!1315489018!48146380!1 X-Originating-IP: [80.70.172.51] X-StarScan-Version: 6.3.6; banners=-,-,- X-VirusChecked: Checked Received: (qmail 27659 invoked from network); 8 Sep 2011 13:36:58 -0000 Received: from dgate20.ts.fujitsu.com (HELO dgate20.ts.fujitsu.com) (80.70.172.51) by server-6.tower-27.messagelabs.com with SMTP; 8 Sep 2011 13:36:58 -0000 DomainKey-Signature: s=s1536a; d=ts.fujitsu.com; c=nofws; q=dns; h=X-SBRSScore:X-IronPort-AV:Received:X-IronPort-AV: Received:Received:Content-Type:MIME-Version:Subject: X-Mercurial-Node:Message-Id:Date:From:To; b=v7FpLeJVSJS1Sos+jB1bZpyX9PirOB0CYJ46RF14Nb4LITKSXybEFTfl z8GwufcDRKEdJ77ySYkzDpD+zF4/b0dEDCnryP/pvsdYoStKyeRH8PE6J tVg+HTauBC7UQFAln89bBclmY5ikSRWZjRAIq1RpNhK1Aqn8r/lw5el+k 6+2pltqXBNQWuAzYdvBg2AfD4nfz+GO8idwtIDeUlWqqzd9HWTVPhmWkY zxRoZZg9scuUg7ZF7hX0NrWFb7Lak; DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=ts.fujitsu.com; i=juergen.gross@ts.fujitsu.com; q=dns/txt; s=s1536b; t=1315489036; x=1347025036; h=mime-version:subject:message-id:date:from:to; bh=ckFqH5K4ysgOa/iADLYCCZaLiX2utc/09sX52J8midU=; b=eQSHkudWCiWMASe9m0bF5bfYyTwBHuFNb2kLqvvZ9NlYi3MgV9y5d9hS MYcTVDwDQYwMmxkcWnlXP2QATpW+KWpB0qZvXTiT7wB6lZblF44gFVJrm fOn5grGs67FbxVbifqC4iLhAz2WXJccQYxhbab/oPR+P2XZO1QKdate2B Lt03MDrp8SE9L8q2CcTRyWlSnyR5CIxr93Ch5G4lOTnKGjDum8BsRmcWD IBkSMgg/yfMrZtPOP30GjnwOVAOAI; X-SBRSScore: None X-IronPort-AV: E=Sophos;i="4.68,350,1312149600"; d="scan'208";a="73981705" Received: from abgdgate40u.abg.fsc.net ([172.25.138.90]) by dgate20u.abg.fsc.net with ESMTP; 08 Sep 2011 15:32:58 +0200 X-IronPort-AV: E=Sophos;i="4.68,349,1312149600"; d="scan'208";a="119739304" Received: from sanpedro.mch.fsc.net ([172.17.20.6]) by abgdgate40u.abg.fsc.net with ESMTP; 08 Sep 2011 15:32:57 +0200 Received: from [172.17.21.25] (nehalem1.osd.mch.fsc.net [172.17.21.25]) by sanpedro.mch.fsc.net (Postfix) with ESMTP id D64DB5645BE; Thu, 8 Sep 2011 15:32:57 +0200 (CEST) Content-Type: multipart/mixed; boundary="===============7140145364159150585==" MIME-Version: 1.0 X-Mercurial-Node: 8244f714acf1cc2bc08517a34dc241380f9648e6 Message-Id: <8244f714acf1cc2bc085.1315488574@nehalem1> Date: Thu, 08 Sep 2011 15:29:34 +0200 From: Juergen Gross To: xen-devel@lists.xensource.com Subject: [Xen-devel] [PATCH] Enable cpuid performance counter leaf for HVM X-BeenThere: xen-devel@lists.xensource.com X-Mailman-Version: 2.1.5 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xensource.com Errors-To: xen-devel-bounces@lists.xensource.com --===============7140145364159150585== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit In HVM domains the usable performance counters can be checked automatically only, if cpuid leaf 0x0000000a is accessible. Signed-off-by: juergen.gross@ts.fujitsu.com 1 file changed, 1 insertion(+) tools/libxc/xc_cpuid_x86.c | 1 + --===============7140145364159150585== Content-Type: text/x-patch; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=xen-staging.hg.patch # HG changeset patch # User Juergen Gross # Date 1315488544 -7200 # Node ID 8244f714acf1cc2bc08517a34dc241380f9648e6 # Parent bdd19847ae63b5dfb036e228cb16ec3ae678e995 Enable cpuid performance counter leaf for HVM In HVM domains the usable performance counters can be checked automatically only, if cpuid leaf 0x0000000a is accessible. Signed-off-by: juergen.gross@ts.fujitsu.com diff -r bdd19847ae63 -r 8244f714acf1 tools/libxc/xc_cpuid_x86.c --- a/tools/libxc/xc_cpuid_x86.c Wed Sep 07 10:37:48 2011 +0100 +++ b/tools/libxc/xc_cpuid_x86.c Thu Sep 08 15:29:04 2011 +0200 @@ -392,6 +392,7 @@ static void xc_cpuid_hvm_policy( case 0x00000002: /* Intel cache info (dumped by AMD policy) */ case 0x00000004: /* Intel cache info (dumped by AMD policy) */ + case 0x0000000a: /* Architectural Performance Monitor Features */ case 0x80000002: /* Processor name string */ case 0x80000003: /* ... continued */ case 0x80000004: /* ... continued */ --===============7140145364159150585== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel --===============7140145364159150585==-- From xen-devel-bounces@lists.xensource.com Thu Sep 08 06:40:15 2011 Return-path: Envelope-to: www-data@lists.xensource.com Delivery-date: Thu, 08 Sep 2011 06:40:15 -0700 Received: from localhost ([127.0.0.1] helo=lists.colo.xensource.com) by lists.xensource.com with esmtp (Exim 4.43) id 1R1epz-0000hP-05; Thu, 08 Sep 2011 06:40:15 -0700 Received: from mail182.messagelabs.com ([85.158.139.83]) by lists.xensource.com with esmtp (Exim 4.43) id 1R1epW-0000SR-PU for xen-devel@lists.xensource.com; Thu, 08 Sep 2011 06:39:47 -0700 X-Env-Sender: JBeulich@suse.com X-Msg-Ref: server-14.tower-182.messagelabs.com!1315489183!17405667!1 X-Originating-IP: [130.57.49.28] X-StarScan-Version: 6.3.6; banners=-,-,- X-VirusChecked: Checked Received: (qmail 3428 invoked from network); 8 Sep 2011 13:39:43 -0000 Received: from nat28.tlf.novell.com (HELO nat28.tlf.novell.com) (130.57.49.28) by server-14.tower-182.messagelabs.com with DHE-RSA-AES256-SHA encrypted SMTP; 8 Sep 2011 13:39:43 -0000 Received: from EMEA1-MTA by nat28.tlf.novell.com with Novell_GroupWise; Thu, 08 Sep 2011 14:39:42 +0100 Message-Id: <4E68E1D30200007800055501@nat28.tlf.novell.com> X-Mailer: Novell GroupWise Internet Agent 8.0.1 Date: Thu, 08 Sep 2011 14:40:03 +0100 From: "Jan Beulich" To: "Andrew Cooper" References: <4E689D9A.1020405@citrix.com> <4E68C6C10200007800055485@nat28.tlf.novell.com> <4E68C09B.8050409@citrix.com> In-Reply-To: <4E68C09B.8050409@citrix.com> Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: quoted-printable Content-Disposition: inline Cc: Keir Fraser , "xen-devel@lists.xensource.com" Subject: [Xen-devel] Re: 4.0/4.1 requests - IO-APIC EOI [RFC] X-BeenThere: xen-devel@lists.xensource.com X-Mailman-Version: 2.1.5 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xensource.com Errors-To: xen-devel-bounces@lists.xensource.com >>> On 08.09.11 at 15:18, Andrew Cooper wrote: > --- SNIP --- >=20 > Attached is my first attempt at expanding the EOI to work on older > IO-APICs. It has not undergone any significant testing yet. >=20 > Does this look suitable? It looks correct, but I'd prefer not having two io_apic_eoi_*() functions: Namely in the "normal" __eoi_IO_APIC_irq() case you have pin *and* vector readily available, and hence there is no need to look up anything. So perhaps a better option would be to pass both pin and vector to io_apic_eoi() (using e.g. -1 to identify the "unknown-needs-lookup" case). Jan _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel From xen-devel-bounces@lists.xensource.com Thu Sep 08 06:43:18 2011 Return-path: Envelope-to: www-data@lists.xensource.com Delivery-date: Thu, 08 Sep 2011 06:43:18 -0700 Received: from localhost ([127.0.0.1] helo=lists.colo.xensource.com) by lists.xensource.com with esmtp (Exim 4.43) id 1R1esw-00016f-Rr; Thu, 08 Sep 2011 06:43:18 -0700 Received: from mail21.messagelabs.com ([85.158.143.35]) by lists.xensource.com with esmtp (Exim 4.43) id 1R1esY-0000tu-1R for xen-devel@lists.xensource.com; Thu, 08 Sep 2011 06:42:54 -0700 X-Env-Sender: konrad@dumpdata.com X-Msg-Ref: server-14.tower-21.messagelabs.com!1315489361!58838105!1 X-Originating-IP: [148.87.113.117] X-StarScan-Version: 6.3.6; banners=-,-,- X-VirusChecked: Checked Received: (qmail 27339 invoked from network); 8 Sep 2011 13:42:42 -0000 Received: from rcsinet15.oracle.com (HELO rcsinet15.oracle.com) (148.87.113.117) by server-14.tower-21.messagelabs.com with DHE-RSA-AES256-SHA encrypted SMTP; 8 Sep 2011 13:42:42 -0000 Received: from rtcsinet22.oracle.com (rtcsinet22.oracle.com [66.248.204.30]) by rcsinet15.oracle.com (Switch-3.4.4/Switch-3.4.4) with ESMTP id p88DdF2J007965 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Thu, 8 Sep 2011 13:39:17 GMT Received: from acsmt356.oracle.com (acsmt356.oracle.com [141.146.40.156]) by rtcsinet22.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id p88Dd9LR029772 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 8 Sep 2011 13:39:11 GMT Received: from abhmt119.oracle.com (abhmt119.oracle.com [141.146.116.71]) by acsmt356.oracle.com (8.12.11.20060308/8.12.11) with ESMTP id p88Dd3g9021831; Thu, 8 Sep 2011 08:39:03 -0500 Received: from phenom (/209.6.55.207) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Thu, 08 Sep 2011 06:39:03 -0700 Received: by phenom (Postfix, from userid 1000) id 0F9C2FD1; Thu, 8 Sep 2011 09:38:48 -0400 (EDT) Date: Thu, 8 Sep 2011 09:38:48 -0400 From: Konrad Rzeszutek Wilk To: "Cihula, Joseph" Subject: Re: [Xen-devel] RE: [PATCH 5/7] xen/acpi: Domain0 acpi parser related platform hypercall Message-ID: <20110908133847.GC27132@dumpdata.com> References: <1314815484-4668-1-git-send-email-konrad.wilk@oracle.com> <1314815484-4668-6-git-send-email-konrad.wilk@oracle.com> <9F57BF860713DF4BA3EFA4F8C6DFEDAC16F3F665@ORSMSX101.amr.corp.intel.com> <4E67A9E7.2020802@goop.org> <9F57BF860713DF4BA3EFA4F8C6DFEDAC16F40F0B@ORSMSX101.amr.corp.intel.com> <20110907190659.GH7074@dumpdata.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20110907190659.GH7074@dumpdata.com> User-Agent: Mutt/1.5.21 (2010-09-15) X-Source-IP: rtcsinet22.oracle.com [66.248.204.30] X-CT-RefId: str=0001.0A090206.4E68C587.006D,ss=1,re=0.000,fgs=0 Cc: "Brown, Len" , Jeremy Fitzhardinge , "xen-devel@lists.xensource.com" , "keir@xen.org" , "x86@kernel.org" , "Tian, Kevin" , "Wei, Gang" , "linux-acpi@vger.kernel.org" , "tboot-devel@lists.sourceforge.net" , Fitzhardinge , "tglx@linutronix.de" , "Yu, Ke" , "hpa@zytor.com" , "liang.tang@oracle.com" , "linux-pm@lists.linux-foundation.org" X-BeenThere: xen-devel@lists.xensource.com X-Mailman-Version: 2.1.5 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xensource.com Errors-To: xen-devel-bounces@lists.xensource.com On Wed, Sep 07, 2011 at 03:06:59PM -0400, Konrad Rzeszutek Wilk wrote: > > > >> +#define XENPF_enter_acpi_sleep 51 > > > >> +struct xenpf_enter_acpi_sleep { > > > >> + /* IN variables */ > > > >> + uint16_t pm1a_cnt_val; /* PM1a control value. */ > > > >> + uint16_t pm1b_cnt_val; /* PM1b control value. */ > > > > These are uint32_t in native Linux--why truncate in the API and not at use? > > > > > > Does ACPI define them as 32 or 16 bit? > > > > The spec indicates that the length is variable and could be up to 32 bits (AFAICT). And Linux uses 32b, which your other patch is truncating for this call. > > Yikes! Well, looks like we need to fix the Xen ABI too. Lets get that fixed > and also address all the other comments (thanks for looking at it) you pointed > out. So read up the ACPI spec and it says that the minimum is 2 bytes and does not say anything about the maximum. The list of what the bits do stops at 16-bits (the last two are reserved) so I think we are actually OK. Albeit if the spec starts using more of them - then yes we will need to revist this Xen ABI and potentially add a new call. _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel From xen-devel-bounces@lists.xensource.com Thu Sep 08 06:58:27 2011 Return-path: Envelope-to: www-data@lists.xensource.com Delivery-date: Thu, 08 Sep 2011 06:58:27 -0700 Received: from localhost ([127.0.0.1] helo=lists.colo.xensource.com) by lists.xensource.com with esmtp (Exim 4.43) id 1R1f7a-0003EH-HI; Thu, 08 Sep 2011 06:58:26 -0700 Received: from mail21.messagelabs.com ([85.158.143.35]) by lists.xensource.com with esmtp (Exim 4.43) id 1R1f6F-0002vI-AW for xen-devel@lists.xensource.com; Thu, 08 Sep 2011 06:57:03 -0700 X-Env-Sender: Andrew.Cooper3@citrix.com X-Msg-Ref: server-10.tower-21.messagelabs.com!1315490205!53368135!1 X-Originating-IP: [66.165.176.89] X-StarScan-Version: 6.3.6; banners=-,-,- X-VirusChecked: Checked Received: (qmail 32116 invoked from network); 8 Sep 2011 13:56:46 -0000 Received: from smtp.citrix.com (HELO SMTP.CITRIX.COM) (66.165.176.89) by server-10.tower-21.messagelabs.com with RC4-SHA encrypted SMTP; 8 Sep 2011 13:56:46 -0000 X-IronPort-AV: E=Sophos;i="4.68,350,1312171200"; d="scan'208";a="16794367" Received: from ftlpmailmx02.citrite.net ([10.13.107.66]) by FTLPIPO01.CITRIX.COM with ESMTP/TLS/RC4-MD5; 08 Sep 2011 09:56:58 -0400 Received: from [10.80.2.18] (10.80.2.18) by FTLPMAILMX02.citrite.net (10.13.107.66) with Microsoft SMTP Server id 8.3.137.0; Thu, 8 Sep 2011 09:56:58 -0400 Message-ID: <4E68C9A9.8090707@citrix.com> Date: Thu, 8 Sep 2011 14:56:57 +0100 From: Andrew Cooper User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.2.21) Gecko/20110831 Lightning/1.0b2 Thunderbird/3.1.13 MIME-Version: 1.0 To: Jan Beulich References: <4E689D9A.1020405@citrix.com> <4E68C6C10200007800055485@nat28.tlf.novell.com> <4E68C09B.8050409@citrix.com> <4E68E1D30200007800055501@nat28.tlf.novell.com> In-Reply-To: <4E68E1D30200007800055501@nat28.tlf.novell.com> Content-Type: text/plain; charset="ISO-8859-1" Content-Transfer-Encoding: 7bit Cc: Keir Fraser , "xen-devel@lists.xensource.com" Subject: [Xen-devel] Re: 4.0/4.1 requests - IO-APIC EOI [RFC] X-BeenThere: xen-devel@lists.xensource.com X-Mailman-Version: 2.1.5 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xensource.com Errors-To: xen-devel-bounces@lists.xensource.com On 08/09/11 14:40, Jan Beulich wrote: >>>> On 08.09.11 at 15:18, Andrew Cooper wrote: >> --- SNIP --- >> >> Attached is my first attempt at expanding the EOI to work on older >> IO-APICs. It has not undergone any significant testing yet. >> >> Does this look suitable? > It looks correct, but I'd prefer not having two io_apic_eoi_*() functions: > Namely in the "normal" __eoi_IO_APIC_irq() case you have pin *and* > vector readily available, and hence there is no need to look up anything. > So perhaps a better option would be to pass both pin and vector to > io_apic_eoi() (using e.g. -1 to identify the "unknown-needs-lookup" > case). > > Jan Ok - I will refactor with that suggestion. Also, the code in end_level_ioapic_irq() suggests masking the entry while playing with it, so I will include that as well. -- Andrew Cooper - Dom0 Kernel Engineer, Citrix XenServer T: +44 (0)1223 225 900, http://www.citrix.com _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel From xen-devel-bounces@lists.xensource.com Thu Sep 08 07:12:17 2011 Return-path: Envelope-to: www-data@lists.xensource.com Delivery-date: Thu, 08 Sep 2011 07:12:17 -0700 Received: from localhost ([127.0.0.1] helo=lists.colo.xensource.com) by lists.xensource.com with esmtp (Exim 4.43) id 1R1fKz-00059O-2a; Thu, 08 Sep 2011 07:12:17 -0700 Received: from mail27.messagelabs.com ([193.109.254.147]) by lists.xensource.com with esmtp (Exim 4.43) id 1R1fF9-00046Z-8s for xen-devel@lists.xensource.com; Thu, 08 Sep 2011 07:06:17 -0700 X-Env-Sender: Christoph.Egger@amd.com X-Msg-Ref: server-3.tower-27.messagelabs.com!1315490749!38841453!1 X-Originating-IP: [213.199.154.142] X-StarScan-Version: 6.3.6; banners=-,-,- X-VirusChecked: Checked Received: (qmail 2408 invoked from network); 8 Sep 2011 14:05:50 -0000 Received: from db3ehsobe004.messaging.microsoft.com (HELO DB3EHSOBE004.bigfish.com) (213.199.154.142) by server-3.tower-27.messagelabs.com with AES128-SHA encrypted SMTP; 8 Sep 2011 14:05:50 -0000 Received: from mail13-db3-R.bigfish.com (10.3.81.246) by DB3EHSOBE004.bigfish.com (10.3.84.24) with Microsoft SMTP Server id 14.1.225.22; Thu, 8 Sep 2011 14:06:10 +0000 Received: from mail13-db3 (localhost.localdomain [127.0.0.1]) by mail13-db3-R.bigfish.com (Postfix) with ESMTP id B934D10103CC; Thu, 8 Sep 2011 14:06:10 +0000 (UTC) X-SpamScore: -11 X-BigFish: VPS-11(zzbb2dK1432N98dKzz1202hzz8275bhz32i668h839h61h) X-Spam-TCS-SCL: 0:0 X-Forefront-Antispam-Report: CIP:163.181.249.109; KIP:(null); UIP:(null); IPVD:NLI; H:ausb3twp02.amd.com; RD:none; EFVD:NLI Received: from mail13-db3 (localhost.localdomain [127.0.0.1]) by mail13-db3 (MessageSwitch) id 1315490770369575_24508; Thu, 8 Sep 2011 14:06:10 +0000 (UTC) Received: from DB3EHSMHS012.bigfish.com (unknown [10.3.81.251]) by mail13-db3.bigfish.com (Postfix) with ESMTP id 4AE08107804E; Thu, 8 Sep 2011 14:06:10 +0000 (UTC) Received: from ausb3twp02.amd.com (163.181.249.109) by DB3EHSMHS012.bigfish.com (10.3.87.112) with Microsoft SMTP Server id 14.1.225.22; Thu, 8 Sep 2011 14:06:07 +0000 X-WSS-ID: 0LR7J60-02-9II-02 X-M-MSG: Received: from sausexedgep02.amd.com (sausexedgep02-ext.amd.com [163.181.249.73]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by ausb3twp02.amd.com (Axway MailGate 3.8.1) with ESMTP id 2AE5FFCC007; Thu, 8 Sep 2011 09:05:59 -0500 (CDT) Received: from sausexhtp02.amd.com (163.181.3.152) by sausexedgep02.amd.com (163.181.36.59) with Microsoft SMTP Server (TLS) id 8.3.106.1; Thu, 8 Sep 2011 09:06:06 -0500 Received: from storexhtp02.amd.com (172.24.4.4) by sausexhtp02.amd.com (163.181.3.152) with Microsoft SMTP Server (TLS) id 8.3.83.0; Thu, 8 Sep 2011 09:06:01 -0500 Received: from rhodium.osrc.amd.com (165.204.15.173) by storexhtp02.amd.com (172.24.4.4) with Microsoft SMTP Server id 8.3.83.0; Thu, 8 Sep 2011 10:05:58 -0400 Message-ID: <4E68CBC5.1080902@amd.com> Date: Thu, 8 Sep 2011 16:05:57 +0200 From: Christoph Egger User-Agent: Mozilla/5.0 (X11; U; NetBSD amd64; en-US; rv:1.9.2.17) Gecko/20110523 Lightning/1.0b3pre Thunderbird/3.1.10 MIME-Version: 1.0 To: Tim Deegan Subject: Re: [Xen-devel] [PATCH 01/04] p2m: use defines for page sizes rather hardcoding them References: <4E57B184.8070601@amd.com> <20110901084041.GB3859@ocelot.phlegethon.org> <20110901084553.GC3859@ocelot.phlegethon.org> <20110905090224.GB86376@ocelot.phlegethon.org> <20110907134416.GD41585@ocelot.phlegethon.org> In-Reply-To: <20110907134416.GD41585@ocelot.phlegethon.org> Content-Type: text/plain; charset="ISO-8859-1"; format=flowed Content-Transfer-Encoding: 7bit X-OriginatorOrg: amd.com Cc: "xen-devel@lists.xensource.com" X-BeenThere: xen-devel@lists.xensource.com X-Mailman-Version: 2.1.5 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xensource.com Errors-To: xen-devel-bounces@lists.xensource.com On 09/07/11 15:44, Tim Deegan wrote: > At 10:02 +0100 on 05 Sep (1315216944), Tim Deegan wrote: >> I think they really just need trimmed back a bit before they go in. >> I'll have some time on Wednesday, so I might just do that then. > > OK, I've cut them back to just the bits that are needed by the new > callers. I ended up shuffling the code around as well, so could you > please test that the attached series works for you? Yes, the patch series works very well. Please apply them. Acked-by: Christoph Egger -- ---to satisfy European Law for business letters: Advanced Micro Devices GmbH Einsteinring 24, 85689 Dornach b. Muenchen Geschaeftsfuehrer: Alberto Bozzo, Andrew Bowd Sitz: Dornach, Gemeinde Aschheim, Landkreis Muenchen Registergericht Muenchen, HRB Nr. 43632 _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel From xen-devel-bounces@lists.xensource.com Thu Sep 08 08:03:01 2011 Return-path: Envelope-to: www-data@lists.xensource.com Delivery-date: Thu, 08 Sep 2011 08:03:01 -0700 Received: from localhost ([127.0.0.1] helo=lists.colo.xensource.com) by lists.xensource.com with esmtp (Exim 4.43) id 1R1g85-0008Sz-1m; Thu, 08 Sep 2011 08:03:01 -0700 Received: from mail27.messagelabs.com ([193.109.254.147]) by lists.xensource.com with esmtp (Exim 4.43) id 1R1g3H-0008D4-RF for xen-devel@lists.xensource.com; Thu, 08 Sep 2011 07:58:04 -0700 X-Env-Sender: david.vrabel@citrix.com X-Msg-Ref: server-7.tower-27.messagelabs.com!1315493858!47847108!1 X-Originating-IP: [66.165.176.89] X-StarScan-Version: 6.3.6; banners=-,-,- X-VirusChecked: Checked Received: (qmail 4678 invoked from network); 8 Sep 2011 14:57:39 -0000 Received: from smtp.citrix.com (HELO SMTP.CITRIX.COM) (66.165.176.89) by server-7.tower-27.messagelabs.com with RC4-SHA encrypted SMTP; 8 Sep 2011 14:57:39 -0000 X-IronPort-AV: E=Sophos;i="4.68,350,1312171200"; d="scan'208";a="16796822" Received: from ftlpmailmx02.citrite.net ([10.13.107.66]) by FTLPIPO01.CITRIX.COM with ESMTP/TLS/RC4-MD5; 08 Sep 2011 10:57:59 -0400 Received: from [10.80.2.76] (10.80.2.76) by FTLPMAILMX02.citrite.net (10.13.107.66) with Microsoft SMTP Server id 8.3.137.0; Thu, 8 Sep 2011 10:57:58 -0400 Message-ID: <4E68D8C3.2090308@citrix.com> Date: Thu, 8 Sep 2011 16:01:23 +0100 From: David Vrabel User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.1.16) Gecko/20110818 Icedove/3.0.11 MIME-Version: 1.0 To: Konrad Rzeszutek Wilk References: <1313765840-22084-1-git-send-email-david.vrabel@citrix.com> <1313765840-22084-3-git-send-email-david.vrabel@citrix.com> <20110906213139.GB24860@dumpdata.com> In-Reply-To: <20110906213139.GB24860@dumpdata.com> Content-Type: text/plain; charset="ISO-8859-1" Content-Transfer-Encoding: 7bit Cc: "xen-devel@lists.xensource.com" Subject: [Xen-devel] Re: [PATCH 2/5] xen/balloon: account for pages released during memory setup X-BeenThere: xen-devel@lists.xensource.com X-Mailman-Version: 2.1.5 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xensource.com Errors-To: xen-devel-bounces@lists.xensource.com On 06/09/11 22:31, Konrad Rzeszutek Wilk wrote: > On Fri, Aug 19, 2011 at 03:57:17PM +0100, David Vrabel wrote: >> >> --- a/drivers/xen/balloon.c >> +++ b/drivers/xen/balloon.c >> @@ -557,15 +557,20 @@ EXPORT_SYMBOL(free_xenballooned_pages); >> >> static int __init balloon_init(void) >> { >> + domid_t domid = DOMID_SELF; >> unsigned long pfn, extra_pfn_end; >> struct page *page; >> + int ret; > > long int? int looks correct to me. From arch/x86/include/asm/xen/hypercall.h: static inline int HYPERVISOR_memory_op(unsigned int cmd, void *arg) { return _hypercall2(int, memory_op, cmd, arg); } >> >> if (!xen_domain()) >> return -ENODEV; >> >> pr_info("xen/balloon: Initialising balloon driver.\n"); >> >> - balloon_stats.current_pages = xen_pv_domain() ? min(xen_start_info->nr_pages, max_pfn) : max_pfn; >> + ret = HYPERVISOR_memory_op(XENMEM_current_reservation, &domid); >> + if (ret < 0) >> + return ret; >> + balloon_stats.current_pages = ret; >> balloon_stats.target_pages = balloon_stats.current_pages; >> balloon_stats.balloon_low = 0; >> balloon_stats.balloon_high = 0; >> -- >> 1.7.2.5 _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel From xen-devel-bounces@lists.xensource.com Thu Sep 08 09:43:38 2011 Return-path: Envelope-to: www-data@lists.xensource.com Delivery-date: Thu, 08 Sep 2011 09:43:38 -0700 Received: from localhost ([127.0.0.1] helo=lists.colo.xensource.com) by lists.xensource.com with esmtp (Exim 4.43) id 1R1hhR-00048f-AU; Thu, 08 Sep 2011 09:43:37 -0700 Received: from mail174.messagelabs.com ([85.158.138.51]) by lists.xensource.com with smtp (Exim 4.43) id 1R1hgN-0003vp-JR for xen-devel@lists.xensource.com; Thu, 08 Sep 2011 09:42:34 -0700 X-Env-Sender: gcvxd-xen-devel@m.gmane.org X-Msg-Ref: server-4.tower-174.messagelabs.com!1315500148!30752891!1 X-Originating-IP: [80.91.229.12] X-StarScan-Version: 6.3.6; banners=-,-,- X-VirusChecked: Checked Received: (qmail 20118 invoked from network); 8 Sep 2011 16:42:28 -0000 Received: from lo.gmane.org (HELO lo.gmane.org) (80.91.229.12) by server-4.tower-174.messagelabs.com with SMTP; 8 Sep 2011 16:42:28 -0000 Received: from list by lo.gmane.org with local (Exim 4.69) (envelope-from ) id 1R1hgK-0005bZ-0s for xen-devel@lists.xensource.com; Thu, 08 Sep 2011 18:42:28 +0200 Received: from horkheimer.ti5.tu-harburg.de ([134.28.77.9]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Thu, 08 Sep 2011 18:42:28 +0200 Received: from sven.koehler by horkheimer.ti5.tu-harburg.de with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Thu, 08 Sep 2011 18:42:28 +0200 X-Injected-Via-Gmane: http://gmane.org/ To: xen-devel@lists.xensource.com From: =?UTF-8?B?U3ZlbiBLw7ZobGVy?= Date: Thu, 08 Sep 2011 18:42:12 +0200 Lines: 56 Message-ID: Mime-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-Complaints-To: usenet@dough.gmane.org X-Gmane-NNTP-Posting-Host: horkheimer.ti5.tu-harburg.de User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:6.0) Gecko/20110829 Thunderbird/6.0 Subject: [Xen-devel] xl vs. xm, possible bug in xl X-BeenThere: xen-devel@lists.xensource.com X-Mailman-Version: 2.1.5 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xensource.com Errors-To: xen-devel-bounces@lists.xensource.com Hi, xl is supposed to superseed xm, is this correct? How mature is xl, actually? I'm asking, because the maintainers of the gentoo's xen packages are migrating the init.d-scripts from xm to xl, but xl is causing a lot of trouble. Well, xl basically fails to start domains on my system. > # xl create /etc/xen/xen-sk1 > Parsing config file /etc/xen/xen-sk1 > libxl: error: libxl.c:2145:libxl_set_memory_target new target 0 for dom0 is below the minimum threshold > libxl: error: libxl.c:2145:libxl_set_memory_target new target 0 for dom0 is below the minimum threshold > libxl: error: libxl.c:2145:libxl_set_memory_target new target 0 for dom0 is below the minimum threshold > failed to free memory for the domain Consider, that autobaloon=1 in xl.conf. With the autobaloon=0 the errors change to > # xl create /etc/xen/xen-sk1 > Parsing config file /etc/xen/xen-sk1 > libxl: error: libxl_device.c:476:libxl__wait_for_device_model Device Model not ready > xl: fatal error: libxl_create.c:535, rc=-1: libxl__confirm_device_model_startup Note, that I use dom0_mem=512M in grub.conf. Also, xm top states, that there are 2139432k free memory. Considering the first issue, it seems like xl is trying to baloon memory away from dom0, which fails - which seems obvious wrong considering that I use dom0_mem. CONFIG_XEN_BALLOON is enabled for dom0 The second issue sounds more severe, and I'm pretty clueless. Is this a bug in xl? Starting the very same domain with xm works without a hassle. dom0: vanilla 3.0.0 with vga patch xen 4.1.1 domU config: kernel = "/usr/src/linux-domU/_domU/vmlinux" memory = 2048 vcpus = 8 root = "/dev/xvda1" extra = "ro" disk = [ "phy:/dev/md2,xvda1,w", "phy:/dev/md5,xvda2,w", ] vif = [ "bridge=xenbr0,mac=00:16:3E:00:00:01", "bridge=xenbr1,mac=00:16:3E:00:01:01", ] _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel From xen-devel-bounces@lists.xensource.com Thu Sep 08 10:10:06 2011 Return-path: Envelope-to: www-data@lists.xensource.com Delivery-date: Thu, 08 Sep 2011 10:10:06 -0700 Received: from localhost ([127.0.0.1] helo=lists.colo.xensource.com) by lists.xensource.com with esmtp (Exim 4.43) id 1R1i73-00053J-RP; Thu, 08 Sep 2011 10:10:05 -0700 Received: from mail216.messagelabs.com ([85.158.143.99]) by lists.xensource.com with esmtp (Exim 4.43) id 1R1i5R-0004pg-Ul for xen-devel@lists.xensource.com; Thu, 08 Sep 2011 10:08:27 -0700 X-Env-Sender: konrad@dumpdata.com X-Msg-Ref: server-5.tower-216.messagelabs.com!1315501701!17087404!1 X-Originating-IP: [141.146.126.227] X-StarScan-Version: 6.3.6; banners=-,-,- X-VirusChecked: Checked Received: (qmail 18180 invoked from network); 8 Sep 2011 17:08:22 -0000 Received: from acsinet15.oracle.com (HELO acsinet15.oracle.com) (141.146.126.227) by server-5.tower-216.messagelabs.com with DHE-RSA-AES256-SHA encrypted SMTP; 8 Sep 2011 17:08:22 -0000 Received: from rtcsinet22.oracle.com (rtcsinet22.oracle.com [66.248.204.30]) by acsinet15.oracle.com (Switch-3.4.4/Switch-3.4.4) with ESMTP id p88H8GA7009401 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Thu, 8 Sep 2011 17:08:18 GMT Received: from acsmt357.oracle.com (acsmt357.oracle.com [141.146.40.157]) by rtcsinet22.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id p88H8F9I029837 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 8 Sep 2011 17:08:16 GMT Received: from abhmt116.oracle.com (abhmt116.oracle.com [141.146.116.68]) by acsmt357.oracle.com (8.12.11.20060308/8.12.11) with ESMTP id p88H89kl024912; Thu, 8 Sep 2011 12:08:09 -0500 Received: from phenom (/209.6.55.207) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Thu, 08 Sep 2011 10:08:09 -0700 Received: by phenom (Postfix, from userid 1000) id 2BD59FD1; Thu, 8 Sep 2011 13:07:55 -0400 (EDT) Date: Thu, 8 Sep 2011 13:07:55 -0400 From: Konrad Rzeszutek Wilk To: Sven =?iso-8859-1?Q?K=F6hler?= , david.vrabel@citrix.com Subject: Re: [Xen-devel] xl vs. xm, possible bug in xl Message-ID: <20110908170755.GB16730@dumpdata.com> References: MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.21 (2010-09-15) Content-Transfer-Encoding: quoted-printable X-Source-IP: rtcsinet22.oracle.com [66.248.204.30] X-CT-RefId: str=0001.0A020203.4E68F683.0079,ss=1,re=0.000,fgs=0 Cc: xen-devel@lists.xensource.com X-BeenThere: xen-devel@lists.xensource.com X-Mailman-Version: 2.1.5 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xensource.com Errors-To: xen-devel-bounces@lists.xensource.com On Thu, Sep 08, 2011 at 06:42:12PM +0200, Sven K=F6hler wrote: > Hi, >=20 > xl is supposed to superseed xm, is this correct? How mature is xl, > actually? I'm asking, because the maintainers of the gentoo's xen > packages are migrating the init.d-scripts from xm to xl, but xl is > causing a lot of trouble. >=20 > Well, xl basically fails to start domains on my system. > > # xl create /etc/xen/xen-sk1 > > Parsing config file /etc/xen/xen-sk1 > > libxl: error: libxl.c:2145:libxl_set_memory_target new target 0 for d= om0 is below the minimum threshold > > libxl: error: libxl.c:2145:libxl_set_memory_target new target 0 for d= om0 is below the minimum threshold > > libxl: error: libxl.c:2145:libxl_set_memory_target new target 0 for d= om0 is below the minimum threshold > > failed to free memory for the domain >=20 > Consider, that autobaloon=3D1 in xl.conf. > With the autobaloon=3D0 the errors change to >=20 > > # xl create /etc/xen/xen-sk1 > > Parsing config file /etc/xen/xen-sk1 > > libxl: error: libxl_device.c:476:libxl__wait_for_device_model Device = Model not ready > > xl: fatal error: libxl_create.c:535, rc=3D-1: libxl__confirm_device_m= odel_startup >=20 >=20 > Note, that I use dom0_mem=3D512M in grub.conf. Also, xm top states, tha= t > there are 2139432k free memory. Considering the first issue, it seems > like xl is trying to baloon memory away from dom0, which fails - which > seems obvious wrong considering that I use dom0_mem. CONFIG_XEN_BALLOON > is enabled for dom0 Yeah, there is a bug there (in Linux kernel) that just got integrated in = 3.1-rc5. Will show up in 3.0.5. Hm, but the migrating memory away from dom0 seems bizzare. Lets ping David who has been in the thick of this. I have a feeling it is the "delta" patches .. >=20 > The second issue sounds more severe, and I'm pretty clueless. >=20 > Is this a bug in xl? > Starting the very same domain with xm works without a hassle. >=20 >=20 > dom0: > vanilla 3.0.0 with vga patch You could upgrade to 3.0.4 and then you get the VGA patch for free (and some bug-fixes too). > xen 4.1.1 >=20 > domU config: > kernel =3D "/usr/src/linux-domU/_domU/vmlinux" > memory =3D 2048 > vcpus =3D 8 >=20 > root =3D "/dev/xvda1" > extra =3D "ro" >=20 > disk =3D [ > "phy:/dev/md2,xvda1,w", > "phy:/dev/md5,xvda2,w", > ] > vif =3D [ > "bridge=3Dxenbr0,mac=3D00:16:3E:00:00:01", > "bridge=3Dxenbr1,mac=3D00:16:3E:00:01:01", > ] >=20 >=20 > _______________________________________________ > Xen-devel mailing list > Xen-devel@lists.xensource.com > http://lists.xensource.com/xen-devel _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel From xen-devel-bounces@lists.xensource.com Thu Sep 08 10:24:41 2011 Return-path: Envelope-to: www-data@lists.xensource.com Delivery-date: Thu, 08 Sep 2011 10:24:41 -0700 Received: from localhost ([127.0.0.1] helo=lists.colo.xensource.com) by lists.xensource.com with esmtp (Exim 4.43) id 1R1iLB-0006MA-Ed; Thu, 08 Sep 2011 10:24:41 -0700 Received: from mail27.messagelabs.com ([193.109.254.147]) by lists.xensource.com with esmtp (Exim 4.43) id 1R1iIz-0005XC-Id for xen-devel@lists.xensource.com; Thu, 08 Sep 2011 10:22:26 -0700 X-Env-Sender: eric.camachat@gmail.com X-Msg-Ref: server-3.tower-27.messagelabs.com!1315502520!38870507!1 X-Originating-IP: [74.125.83.41] X-StarScan-Version: 6.3.6; banners=-,-,- X-VirusChecked: Checked Received: (qmail 27939 invoked from network); 8 Sep 2011 17:22:01 -0000 Received: from mail-gw0-f41.google.com (HELO mail-gw0-f41.google.com) (74.125.83.41) by server-3.tower-27.messagelabs.com with RC4-SHA encrypted SMTP; 8 Sep 2011 17:22:01 -0000 Received: by gwaa20 with SMTP id a20so126805gwa.28 for ; Thu, 08 Sep 2011 10:22:21 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=OP/CtNf429r+cX7r39erIFeMeVjB/BdbwJPMfYPRQl8=; b=rJqN/WdYAP8hPFCqlvWlMQjo3vlHV1UQkTCGGFYmYq0qQywQXptjHAE8dzZng92wNg 6AmP5yJtpipbNrm7Hq9ZbihMNzBQct+sjOW100Qdzk5DEgpL4PH2Klo+3z+bBCJESAEV Ze9s5YCGSrlEqx3HRI3eRnYpPWCvgQ+RigxFE= Received: by 10.236.168.68 with SMTP id j44mr6203219yhl.32.1315502541233; Thu, 08 Sep 2011 10:22:21 -0700 (PDT) MIME-Version: 1.0 Received: by 10.236.95.5 with HTTP; Thu, 8 Sep 2011 10:22:01 -0700 (PDT) In-Reply-To: <20110908125920.GC28591@dumpdata.com> References: <20110908125920.GC28591@dumpdata.com> From: Eric Camachat Date: Thu, 8 Sep 2011 10:22:01 -0700 Message-ID: Subject: Re: [Xen-devel] Can I specify a physical memory region for a domU To: Konrad Rzeszutek Wilk Content-Type: text/plain; charset=UTF-8 Cc: xen-devel@lists.xensource.com X-BeenThere: xen-devel@lists.xensource.com X-Mailman-Version: 2.1.5 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xensource.com Errors-To: xen-devel-bounces@lists.xensource.com On Thu, Sep 8, 2011 at 5:59 AM, Konrad Rzeszutek Wilk wrote: > On Wed, Sep 07, 2011 at 05:47:46PM -0700, Eric Camachat wrote: >> Hi, >> >> I am porting our drivers to XEN's PV domU (with PV PCI passthrouth), I > > Use the DMA API that Linux provides (I presume that is what you meant > by PV DomU), and use the dma_alloc_coherent to set your regions. That's what I thought before. We use a shared DMA region for multiple hardware. Maybe I can dma_alloc_coherent for 1st and the others use the same region. I will try it. > > Also pass in 'iommu=soft' on your Linux command line to enable the > Xen SWIOTLB DMA system. > >> have to allocate a memory block and tell the hardware to access it. >> But the hardware can address 32-bit only, so I want dedicate a region >> of memory that below 2GB for the domU only. > > Uh, don't you mean 4GB? - 32bit is up to 4GB. The hardware uses 32-bit addressing, but the system will crash if I assigned above 2GB address to it. So, 4GB from hardware spec, 2GB from my test. I am looking into that. >> How do that in XEN? >> >> Thanks, >> /Eric >> >> _______________________________________________ >> Xen-devel mailing list >> Xen-devel@lists.xensource.com >> http://lists.xensource.com/xen-devel > _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel From xen-devel-bounces@lists.xensource.com Thu Sep 08 10:29:44 2011 Return-path: Envelope-to: www-data@lists.xensource.com Delivery-date: Thu, 08 Sep 2011 10:29:44 -0700 Received: from localhost ([127.0.0.1] helo=lists.colo.xensource.com) by lists.xensource.com with esmtp (Exim 4.43) id 1R1iQ4-0006nE-5c; Thu, 08 Sep 2011 10:29:44 -0700 Received: from mail21.messagelabs.com ([85.158.143.35]) by lists.xensource.com with esmtp (Exim 4.43) id 1R1iPf-0006bZ-IT for xen-devel@lists.xensource.com; Thu, 08 Sep 2011 10:29:19 -0700 X-Env-Sender: jeremy@goop.org X-Msg-Ref: server-4.tower-21.messagelabs.com!1315502920!59501008!1 X-Originating-IP: [74.207.240.146] X-StarScan-Version: 6.3.6; banners=-,-,- X-VirusChecked: Checked Received: (qmail 29727 invoked from network); 8 Sep 2011 17:28:41 -0000 Received: from claw.goop.org (HELO claw.goop.org) (74.207.240.146) by server-4.tower-21.messagelabs.com with DHE-RSA-AES256-SHA encrypted SMTP; 8 Sep 2011 17:28:41 -0000 Received: from saboo.goop.org (unknown [IPv6:2001:470:1f05:899:34a1:7dff:fee9:d621]) (Authenticated sender: smtp-saboo) by claw.goop.org (Postfix) with ESMTPSA id 3A9708F83; Thu, 8 Sep 2011 10:29:13 -0700 (PDT) Received: from saboo.goop.org (localhost [IPv6:::1]) by saboo.goop.org (Postfix) with ESMTP id 27F86204B4; Thu, 8 Sep 2011 10:29:08 -0700 (PDT) Message-ID: <4E68FB64.9080308@goop.org> Date: Thu, 08 Sep 2011 10:29:08 -0700 From: Jeremy Fitzhardinge User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:6.0) Gecko/20110816 Thunderbird/6.0 MIME-Version: 1.0 To: Avi Kivity References: <1314996468.8255.0.camel@twins> <4E614FBD.2030509@goop.org> <20110906151408.GA7459@redhat.com> <4E66615E.8070806@goop.org> <20110906182758.GR5795@redhat.com> <4E66EF86.9070200@redhat.com> <20110907134411.GV5795@redhat.com> <4E678992.5050709@redhat.com> <20110907155657.GX5795@redhat.com> <4E679AF4.50209@redhat.com> <20110907165203.GQ6838@redhat.com> <4E67A551.4000502@redhat.com> <4E67A71A.5070903@goop.org> <4E67ACB6.40107@redhat.com> <4E67C15B.3000408@goop.org> <4E6873FE.3040603@redhat.com> In-Reply-To: <4E6873FE.3040603@redhat.com> X-Enigmail-Version: 1.3.1 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: Don Zickus , Marcelo Tosatti , Nick Piggin , KVM , Stefano Stabellini , Peter Zijlstra , the arch/x86 maintainers , Linux Kernel Mailing List , Andi Kleen , Jeremy Fitzhardinge , "H. Peter Anvin" , Ingo Molnar , Linus Torvalds , Xen Devel Subject: [Xen-devel] Re: [PATCH 08/13] xen/pvticketlock: disable interrupts while blocking X-BeenThere: xen-devel@lists.xensource.com X-Mailman-Version: 2.1.5 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xensource.com Errors-To: xen-devel-bounces@lists.xensource.com On 09/08/2011 12:51 AM, Avi Kivity wrote: > On 09/07/2011 10:09 PM, Jeremy Fitzhardinge wrote: >> On 09/07/2011 10:41 AM, Avi Kivity wrote: >> >> Hm, I'm interested to know what you're thinking in more detail. >> Can you >> >> leave an NMI pending before you block in the same way you can with >> >> "sti;halt" with normal interrupts? >> > >> > >> > Nope. But you can do >> > >> > if (regs->rip in critical section) >> > regs->rip = after_halt; >> > >> > and effectively emulate it. The critical section is something like >> > >> > critical_section_start: >> > if (woken_up) >> > goto critical_section_end; >> > hlt >> > critical_section_end: >> >> Hm. It's a pity you have to deliver an actual interrupt to implement >> the kick though. > > I don't think it's that expensive, especially compared to the > double-context-switch and vmexit of the spinner going to sleep. On > AMD we do have to take an extra vmexit (on IRET) though. Fair enough - so if the vcpu blocks itself, it ends up being rescheduled in the NMI handler, which then returns to the lock slowpath. And if its a normal hlt, then you can also take interrupts if they're enabled while spinning. And if you get nested NMIs (since you can get multiple spurious kicks, or from other NMI sources), then one NMI will get latched and any others will get dropped? > Well we could have a specialized sleep/wakeup hypercall pair like Xen, > but I'd like to avoid it if at all possible. Yeah, that's something that just falls out of the existing event channel machinery, so it isn't something that I specifically added. But it does mean that you simply end up with a hypercall returning on kick, with no real complexities. J _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel From xen-devel-bounces@lists.xensource.com Thu Sep 08 10:33:14 2011 Return-path: Envelope-to: www-data@lists.xensource.com Delivery-date: Thu, 08 Sep 2011 10:33:14 -0700 Received: from localhost ([127.0.0.1] helo=lists.colo.xensource.com) by lists.xensource.com with esmtp (Exim 4.43) id 1R1iTS-0007IU-1T; Thu, 08 Sep 2011 10:33:14 -0700 Received: from mail216.messagelabs.com ([85.158.143.99]) by lists.xensource.com with esmtp (Exim 4.43) id 1R1iT3-00076I-6U for xen-devel@lists.xensource.com; Thu, 08 Sep 2011 10:32:49 -0700 X-Env-Sender: konrad@dumpdata.com X-Msg-Ref: server-15.tower-216.messagelabs.com!1315503163!17152563!1 X-Originating-IP: [148.87.113.117] X-StarScan-Version: 6.3.6; banners=-,-,- X-VirusChecked: Checked Received: (qmail 31353 invoked from network); 8 Sep 2011 17:32:45 -0000 Received: from rcsinet15.oracle.com (HELO rcsinet15.oracle.com) (148.87.113.117) by server-15.tower-216.messagelabs.com with DHE-RSA-AES256-SHA encrypted SMTP; 8 Sep 2011 17:32:45 -0000 Received: from rtcsinet21.oracle.com (rtcsinet21.oracle.com [66.248.204.29]) by rcsinet15.oracle.com (Switch-3.4.4/Switch-3.4.4) with ESMTP id p88HWYmQ027647 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Thu, 8 Sep 2011 17:32:36 GMT Received: from acsmt358.oracle.com (acsmt358.oracle.com [141.146.40.158]) by rtcsinet21.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id p88HWWvn007984 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 8 Sep 2011 17:32:34 GMT Received: from abhmt112.oracle.com (abhmt112.oracle.com [141.146.116.64]) by acsmt358.oracle.com (8.12.11.20060308/8.12.11) with ESMTP id p88HWRAC013947; Thu, 8 Sep 2011 12:32:27 -0500 Received: from phenom (/209.6.55.207) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Thu, 08 Sep 2011 10:32:26 -0700 Received: by phenom (Postfix, from userid 1000) id 5F024FD1; Thu, 8 Sep 2011 13:32:12 -0400 (EDT) Date: Thu, 8 Sep 2011 13:32:12 -0400 From: Konrad Rzeszutek Wilk To: Andreas Olsowski Subject: Re: [Xen-devel] xen/stable-2.6.32.x xen-4.1.1 live migration fails with kernels 2.6.39, 3.0.3 and 3.1-rc2 Message-ID: <20110908173212.GA17026@dumpdata.com> References: <4E4EA3E2.2040809@leuphana.de> <4E52224902000078000525CC@nat28.tlf.novell.com> <4E52601B.5060609@leuphana.de> <20110824203435.GA27865@dumpdata.com> <4E55F682.8060405@leuphana.de> <20110826150054.GA1793@dumpdata.com> <4E57D745.2080701@leuphana.de> <20110829194911.GC16530@dumpdata.com> <4E5E320A.60401@leuphana.de> <20110907135046.GD32190@dumpdata.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20110907135046.GD32190@dumpdata.com> User-Agent: Mutt/1.5.21 (2010-09-15) X-Source-IP: rtcsinet21.oracle.com [66.248.204.29] X-CT-RefId: str=0001.0A090207.4E68FC35.000E,ss=1,re=0.000,fgs=0 Cc: "xen-devel@lists.xensource.com" X-BeenThere: xen-devel@lists.xensource.com X-Mailman-Version: 2.1.5 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xensource.com Errors-To: xen-devel-bounces@lists.xensource.com On Wed, Sep 07, 2011 at 09:50:47AM -0400, Konrad Rzeszutek Wilk wrote: > On Wed, Aug 31, 2011 at 03:07:22PM +0200, Andreas Olsowski wrote: > > A little update, i now have all machines running on xen-4.1-testing > > with xen/stable-2.6.32.x > > That gave me the possiblity for additional tests. > > > > (I also tested xm/xend in addtion to xl/libxl, to make sure its not > > a xl/libxl problem.) > > > > I took the liberty to create a new test result matrix that should > > provide a better overview (in case someone else wants to get the > > whole picture): > > So.. I don't think the issue I am seeing is exactly the same. This is > what 'xl' gives me: Scratch that. I am seeing the error below if I: 1) Create guest on 4GB machine 2) Migrate it to the 32GB box (guest still works) 3) Migrate it to the 4GB box (guest dies - error below shows up and guest is dead). With 3.1-rc5 virgin - both Dom0 and DomU. Also Xen 4.1-testing on top of this. I tried just creating a guest on the 32GB and migrating it - and while it did migrate it was stuck in a hypercall_page call or crashed later on. Andreas, Thanks for reporting this. > > :~/ > > xl migrate 3 tst010 > root@tst010's password: > migration target: Ready to receive domain. > Saving to migration stream new xl format (info 0x0/0x0/326) > Loading new save file incoming migration stream (new xl fmt info 0x0/0x0/326) > Savefile contains xl domain config > xc: Saving memory: iter 0 (last sent 0 skipped 0): 262400/262400 100% > xc: Saving memory: iter 2 (last sent 1105 skipped 23): 262400/262400 100% > xc: Saving memory: iter 3 (last sent 74 skipped 0): 262400/262400 100% > xc: Saving memory: iter 4 (last sent 0 skipped 0): 262400/262400 100% > xc: error: unexpected PFN mapping failure pfn 19d0 map_mfn 4e7e04 p2m_mfn 4e7e04: Internal error > libxl: error: libxl_dom.c:363:libxl__domain_restore_common: restoring domain: Resource temporarily unavailable > libxl: error: libxl_create.c:483:do_domain_create: cannot (re-)build domain: -3 > libxl: error: libxl.c:733:libxl_domain_destroy: non-existant domain 4 > migration target: Domain creation failed (code -3). > libxl: error: libxl_utils.c:410:libxl_read_exactly: file/stream truncated reading ready message from migration receiver stream > libxl: info: libxl_exec.c:125:libxl_report_child_exitstatus: migration target process [5810] exited with error status 3 > Migration failed, resuming at sender. > > > And on the receiving side (tst010) I get a monster off: > > (XEN) mm.c:945:d0 Error getting mfn 4e7e04 (pfn ffffffffffffffff) from L1 entry 80000004e7e04627 for l1e_owner=0, pg_owner=4 > XEN) mm.c:945:d0 Error getting mfn 36fd19 (pfn ffffffffffffffff) from L1 entry 800000036fd19627 for l1e_owner=0, pg_owner=4 > (XEN) mm.c:945:d0 Error getting mfn 36f583 (pfn ffffffffffffffff) from L1 entry 800000036f583627 for l1e_owner=0, pg_owner=4 > .. > (XEN) mm.c:945:d0 Error getting mfn 4e7d09 (pfn ffffffffffffffff) from L1 entry 80000004e7d09627 for l1e_owner=0, pg_owner=4 > (XEN) event_channel.c:250:d3 EVTCHNOP failure: error -17 > > > The migration is from a 4GB box to a 32GB box (worked), then back to the 4GB( worked) > and then back to the 32GB (boom!). > > anyhow, let me try this with 4.1-testing branch. Running on the bleeding > edge might not be the best idea sometimes. _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel From xen-devel-bounces@lists.xensource.com Thu Sep 08 10:39:43 2011 Return-path: Envelope-to: www-data@lists.xensource.com Delivery-date: Thu, 08 Sep 2011 10:39:43 -0700 Received: from localhost ([127.0.0.1] helo=lists.colo.xensource.com) by lists.xensource.com with esmtp (Exim 4.43) id 1R1iZj-0007qi-0r; Thu, 08 Sep 2011 10:39:43 -0700 Received: from mail216.messagelabs.com ([85.158.143.99]) by lists.xensource.com with esmtp (Exim 4.43) id 1R1iZ2-0007e8-Hv for xen-devel@lists.xensource.com; Thu, 08 Sep 2011 10:39:00 -0700 X-Env-Sender: Stefano.Stabellini@eu.citrix.com X-Msg-Ref: server-14.tower-216.messagelabs.com!1315503536!17588325!1 X-Originating-IP: [66.165.176.89] X-StarScan-Version: 6.3.6; banners=-,-,- X-VirusChecked: Checked Received: (qmail 2933 invoked from network); 8 Sep 2011 17:38:57 -0000 Received: from smtp.citrix.com (HELO SMTP.CITRIX.COM) (66.165.176.89) by server-14.tower-216.messagelabs.com with RC4-SHA encrypted SMTP; 8 Sep 2011 17:38:57 -0000 X-IronPort-AV: E=Sophos;i="4.68,351,1312171200"; d="scan'208";a="16803357" Received: from ftlpmailmx02.citrite.net ([10.13.107.66]) by FTLPIPO01.CITRIX.COM with ESMTP/TLS/RC4-MD5; 08 Sep 2011 13:38:55 -0400 Received: from smtp01.ad.xensource.com (10.219.128.104) by smtprelay.citrix.com (10.13.107.66) with Microsoft SMTP Server id 8.3.137.0; Thu, 8 Sep 2011 13:38:55 -0400 Received: from localhost.localdomain (kaball.uk.xensource.com [10.80.2.59]) by smtp01.ad.xensource.com (8.13.1/8.13.1) with ESMTP id p88HcrM8029371; Thu, 8 Sep 2011 10:38:54 -0700 From: To: xen-devel@lists.xensource.com Date: Thu, 8 Sep 2011 18:47:15 +0100 Message-ID: <1315504038-21733-1-git-send-email-stefano.stabellini@eu.citrix.com> X-Mailer: git-send-email 1.7.0.4 MIME-Version: 1.0 Content-Type: text/plain Cc: keir@xen.org, Ian.Campbell@citrix.com, stefano.stabellini@eu.citrix.com Subject: [Xen-devel] [PATCH v2 1/4] Move the ioemu-dir-find shell script to an external file X-BeenThere: xen-devel@lists.xensource.com X-Mailman-Version: 2.1.5 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xensource.com Errors-To: xen-devel-bounces@lists.xensource.com Add support for configuring upstream qemu and rename ioemu-remote ioemu-dir-remote. Signed-off-by: Stefano Stabellini diff --git a/tools/Makefile b/tools/Makefile --- a/tools/Makefile +++ b/tools/Makefile @@ -70,7 +70,7 @@ clean: subdirs-clean .PHONY: distclean distclean: subdirs-distclean - rm -rf ioemu-dir ioemu-remote + rm -rf ioemu-dir ioemu-dir-remote ifneq ($(XEN_COMPILE_ARCH),$(XEN_TARGET_ARCH)) IOEMU_CONFIGURE_CROSS ?= --cpu=$(XEN_TARGET_ARCH) \ @@ -78,41 +78,14 @@ IOEMU_CONFIGURE_CROSS ?= --cpu=$(XEN_TAR --interp-prefix=$(CROSS_SYS_ROOT) endif -QEMU_ROOT := $(shell if [ -d "$(CONFIG_QEMU)" ]; then echo "$(CONFIG_QEMU)"; else echo .; fi) -ifneq ($(QEMU_ROOT),.) -export QEMU_ROOT -endif - ioemu-dir-find: - set -ex; \ - if test -d $(CONFIG_QEMU); then \ - mkdir -p ioemu-dir; \ - else \ - if [ ! -d ioemu-remote ]; then \ - rm -rf ioemu-remote ioemu-remote.tmp; \ - mkdir ioemu-remote.tmp; rmdir ioemu-remote.tmp; \ - $(GIT) clone $(CONFIG_QEMU) ioemu-remote.tmp; \ - if [ "$(QEMU_TAG)" ]; then \ - cd ioemu-remote.tmp; \ - $(GIT) branch -D dummy >/dev/null 2>&1 ||:; \ - $(GIT) checkout -b dummy $(QEMU_TAG); \ - cd ..; \ - fi; \ - mv ioemu-remote.tmp ioemu-remote; \ - fi; \ - rm -f ioemu-dir; \ - ln -sf ioemu-remote ioemu-dir; \ - fi - set -e; \ - $(buildmakevars2shellvars); \ - cd ioemu-dir; \ - $(QEMU_ROOT)/xen-setup $(IOEMU_CONFIGURE_CROSS) - + $(XEN_ROOT)/tools/qemu-checkout.sh $(CONFIG_QEMU) $(QEMU_TAG) ioemu-dir + .PHONY: ioemu-dir-force-update ioemu-dir-force-update: set -ex; \ if [ "$(QEMU_TAG)" ]; then \ - cd ioemu-remote; \ + cd ioemu-dir-remote; \ $(GIT) fetch origin; \ $(GIT) reset --hard $(QEMU_TAG); \ fi diff --git a/tools/qemu-checkout.sh b/tools/qemu-checkout.sh new file mode 100755 --- /dev/null +++ b/tools/qemu-checkout.sh @@ -0,0 +1,44 @@ +#!/bin/bash + +TREE=$1 +TAG=$2 +DIR=$3 + + +if test -d $TREE; then + mkdir -p $DIR + ROOT=$TREE +else + if test \! -d $DIR-remote; then + rm -rf $DIR-remote $DIR-remote.tmp; + mkdir $DIR-remote.tmp; rmdir $DIR-remote.tmp; + git clone $TREE $DIR-remote.tmp; + if test "$TAG" ; then + cd $DIR-remote.tmp + git branch -D dummy >/dev/null 2>&1 ||: + git checkout -b dummy $TAG + cd .. + fi + mv $DIR-remote.tmp $DIR-remote + fi + rm -f $DIR + ln -sf $DIR-remote $DIR + ROOT=. +fi + +set -e +cd $DIR +if test -f $ROOT/xen-setup; then + $ROOT/xen-setup $IOEMU_CONFIGURE_CROSS +else + cd $ROOT + ./configure --enable-xen --target-list=i386-softmmu \ + --extra-cflags="-I$XEN_ROOT/tools/include \ + -I$XEN_ROOT/tools/libxc \ + -I$XEN_ROOT/tools/xenstore" \ + --extra-ldflags="-L$XEN_ROOT/tools/libxc \ + -L$XEN_ROOT/tools/libxenstore" \ + --bindir=/usr/lib/xen/bin \ + --disable-kvm \ + $IOEMU_CONFIGURE_CROSS +fi _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel From xen-devel-bounces@lists.xensource.com Thu Sep 08 10:40:44 2011 Return-path: Envelope-to: www-data@lists.xensource.com Delivery-date: Thu, 08 Sep 2011 10:40:44 -0700 Received: from localhost ([127.0.0.1] helo=lists.colo.xensource.com) by lists.xensource.com with esmtp (Exim 4.43) id 1R1iai-0008Dk-1f; Thu, 08 Sep 2011 10:40:44 -0700 Received: from mail216.messagelabs.com ([85.158.143.99]) by lists.xensource.com with esmtp (Exim 4.43) id 1R1iZ3-0007e9-HU for xen-devel@lists.xensource.com; Thu, 08 Sep 2011 10:39:01 -0700 X-Env-Sender: Stefano.Stabellini@eu.citrix.com X-Msg-Ref: server-14.tower-216.messagelabs.com!1315503536!17588325!2 X-Originating-IP: [66.165.176.89] X-StarScan-Version: 6.3.6; banners=-,-,- X-VirusChecked: Checked Received: (qmail 2966 invoked from network); 8 Sep 2011 17:38:58 -0000 Received: from smtp.citrix.com (HELO SMTP.CITRIX.COM) (66.165.176.89) by server-14.tower-216.messagelabs.com with RC4-SHA encrypted SMTP; 8 Sep 2011 17:38:58 -0000 X-IronPort-AV: E=Sophos;i="4.68,351,1312171200"; d="scan'208";a="16803360" Received: from ftlpmailmx02.citrite.net ([10.13.107.66]) by FTLPIPO01.CITRIX.COM with ESMTP/TLS/RC4-MD5; 08 Sep 2011 13:38:58 -0400 Received: from smtp01.ad.xensource.com (10.219.128.104) by smtprelay.citrix.com (10.13.107.66) with Microsoft SMTP Server id 8.3.137.0; Thu, 8 Sep 2011 13:38:57 -0400 Received: from localhost.localdomain (kaball.uk.xensource.com [10.80.2.59]) by smtp01.ad.xensource.com (8.13.1/8.13.1) with ESMTP id p88HcrMA029371; Thu, 8 Sep 2011 10:38:56 -0700 From: To: xen-devel@lists.xensource.com Date: Thu, 8 Sep 2011 18:47:17 +0100 Message-ID: <1315504038-21733-3-git-send-email-stefano.stabellini@eu.citrix.com> X-Mailer: git-send-email 1.7.0.4 In-Reply-To: <1315504038-21733-1-git-send-email-stefano.stabellini@eu.citrix.com> References: <1315504038-21733-1-git-send-email-stefano.stabellini@eu.citrix.com> MIME-Version: 1.0 Content-Type: text/plain Cc: keir@xen.org, Ian.Campbell@citrix.com, stefano.stabellini@eu.citrix.com Subject: [Xen-devel] [PATCH v2 3/4] Clone and build upstream Qemu by default X-BeenThere: xen-devel@lists.xensource.com X-Mailman-Version: 2.1.5 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xensource.com Errors-To: xen-devel-bounces@lists.xensource.com Signed-off-by: Stefano Stabellini diff -r 80ba2c7abbd2 Config.mk --- a/Config.mk Thu Sep 08 16:59:19 2011 +0000 +++ b/Config.mk Thu Sep 08 17:18:48 2011 +0000 @@ -192,6 +192,10 @@ else QEMU_REMOTE=git://xenbits.xensource.com/qemu-xen-unstable.git endif +# Only available through the git protocol at the moment +QEMU_UPSTREAM_URL ?= git://xenbits.xen.org/people/sstabellini/qemu-dm.git +QEMU_UPSTREAM_TAG ?= origin/xen-stable-0.15 + # Specify which qemu-dm to use. This may be `ioemu' to use the old # Mercurial in-tree version, or a local directory, or a git URL. # CONFIG_QEMU ?= `pwd`/$(XEN_ROOT)/../qemu-xen.git diff -r 80ba2c7abbd2 Makefile --- a/Makefile Thu Sep 08 16:59:19 2011 +0000 +++ b/Makefile Thu Sep 08 17:18:48 2011 +0000 @@ -70,7 +70,7 @@ install-tools: $(MAKE) -C tools install ifeq ($(CONFIG_IOEMU),y) -install-tools: tools/qemu-xen-traditional-dir +install-tools: tools/qemu-xen-traditional-dir tools/qemu-xen-dir endif .PHONY: install-kernels @@ -91,6 +91,9 @@ tools/qemu-xen-traditional-dir: tools/qemu-xen-traditional-dir-force-update: $(MAKE) -C tools qemu-xen-traditional-dir-force-update +tools/qemu-xen-dir: + $(MAKE) -C tools qemu-xen-dir-find + .PHONY: install-docs install-docs: sh ./docs/check_pkgs && $(MAKE) -C docs install || true diff -r 80ba2c7abbd2 tools/Makefile --- a/tools/Makefile Thu Sep 08 16:59:19 2011 +0000 +++ b/tools/Makefile Thu Sep 08 17:18:48 2011 +0000 @@ -31,6 +31,7 @@ SUBDIRS-$(LIBXENAPI_BINDINGS) += libxen # do not recurse in to a dir we are about to delete ifneq "$(MAKECMDGOALS)" "distclean" SUBDIRS-$(CONFIG_IOEMU) += qemu-xen-traditional-dir +SUBDIRS-$(CONFIG_IOEMU) += qemu-xen-dir endif SUBDIRS-y += xenpmd @@ -71,6 +72,7 @@ clean: subdirs-clean .PHONY: distclean distclean: subdirs-distclean rm -rf qemu-xen-traditional-dir qemu-xen-traditional-dir-remote + rm -rf qemu-xen-dir qemu-xen-dir-remote ifneq ($(XEN_COMPILE_ARCH),$(XEN_TARGET_ARCH)) IOEMU_CONFIGURE_CROSS ?= --cpu=$(XEN_TARGET_ARCH) \ @@ -81,6 +83,9 @@ endif qemu-xen-traditional-dir-find: $(XEN_ROOT)/tools/qemu-checkout.sh $(CONFIG_QEMU) $(QEMU_TAG) qemu-xen-traditional-dir +qemu-xen-dir-find: + $(XEN_ROOT)/tools/qemu-checkout.sh $(QEMU_UPSTREAM_URL) $(QEMU_UPSTREAM_TAG) qemu-xen-dir + .PHONY: qemu-xen-traditional-dir-force-update qemu-xen-traditional-dir-force-update: set -ex; \ @@ -98,6 +103,14 @@ subdir-clean-qemu-xen-traditional-dir: $(MAKE) -C qemu-xen-traditional-dir clean; \ fi +subdir-all-qemu-xen-dir subdir-install-qemu-xen-dir: qemu-xen-dir-find + +subdir-clean-qemu-xen-dir: + set -e; if test -d qemu-xen-dir/.; then \ + $(buildmakevars2shellvars); \ + $(MAKE) -C qemu-xen-dir clean; \ + fi + subdir-clean-debugger/gdbsx subdir-distclean-debugger/gdbsx: .phony $(MAKE) -C debugger/gdbsx clean _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel From xen-devel-bounces@lists.xensource.com Thu Sep 08 10:41:36 2011 Return-path: Envelope-to: www-data@lists.xensource.com Delivery-date: Thu, 08 Sep 2011 10:41:36 -0700 Received: from localhost ([127.0.0.1] helo=lists.colo.xensource.com) by lists.xensource.com with esmtp (Exim 4.43) id 1R1ibX-00008w-W2; Thu, 08 Sep 2011 10:41:36 -0700 Received: from mail27.messagelabs.com ([193.109.254.147]) by lists.xensource.com with esmtp (Exim 4.43) id 1R1iZ3-0007eB-Ti for xen-devel@lists.xensource.com; Thu, 08 Sep 2011 10:39:02 -0700 X-Env-Sender: Stefano.Stabellini@eu.citrix.com X-Msg-Ref: server-4.tower-27.messagelabs.com!1315503521!39473744!1 X-Originating-IP: [66.165.176.63] X-StarScan-Version: 6.3.6; banners=-,-,- X-VirusChecked: Checked Received: (qmail 17958 invoked from network); 8 Sep 2011 17:38:42 -0000 Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63) by server-4.tower-27.messagelabs.com with RC4-SHA encrypted SMTP; 8 Sep 2011 17:38:42 -0000 X-IronPort-AV: E=Sophos;i="4.68,351,1312171200"; d="scan'208";a="162201863" Received: from ftlpmailmx02.citrite.net ([10.13.107.66]) by FTLPIPO02.CITRIX.COM with ESMTP/TLS/RC4-MD5; 08 Sep 2011 13:38:56 -0400 Received: from smtp01.ad.xensource.com (10.219.128.104) by smtprelay.citrix.com (10.13.107.66) with Microsoft SMTP Server id 8.3.137.0; Thu, 8 Sep 2011 13:38:56 -0400 Received: from localhost.localdomain (kaball.uk.xensource.com [10.80.2.59]) by smtp01.ad.xensource.com (8.13.1/8.13.1) with ESMTP id p88HcrM9029371; Thu, 8 Sep 2011 10:38:55 -0700 From: To: xen-devel@lists.xensource.com Date: Thu, 8 Sep 2011 18:47:16 +0100 Message-ID: <1315504038-21733-2-git-send-email-stefano.stabellini@eu.citrix.com> X-Mailer: git-send-email 1.7.0.4 In-Reply-To: <1315504038-21733-1-git-send-email-stefano.stabellini@eu.citrix.com> References: <1315504038-21733-1-git-send-email-stefano.stabellini@eu.citrix.com> MIME-Version: 1.0 Content-Type: text/plain Cc: keir@xen.org, Ian.Campbell@citrix.com, stefano.stabellini@eu.citrix.com Subject: [Xen-devel] [PATCH v2 2/4] Rename ioemu-dir as qemu-xen-traditional-dir X-BeenThere: xen-devel@lists.xensource.com X-Mailman-Version: 2.1.5 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xensource.com Errors-To: xen-devel-bounces@lists.xensource.com Signed-off-by: Stefano Stabellini diff -r ecafd034af0e Makefile --- a/Makefile Thu Sep 08 16:52:45 2011 +0000 +++ b/Makefile Thu Sep 08 16:59:19 2011 +0000 @@ -70,7 +70,7 @@ install-tools: $(MAKE) -C tools install ifeq ($(CONFIG_IOEMU),y) -install-tools: tools/ioemu-dir +install-tools: tools/qemu-xen-traditional-dir endif .PHONY: install-kernels @@ -78,18 +78,18 @@ install-kernels: for i in $(XKERNELS) ; do $(MAKE) $$i-install || exit 1; done .PHONY: install-stubdom -install-stubdom: tools/ioemu-dir install-tools +install-stubdom: tools/qemu-xen-traditional-dir install-tools $(MAKE) -C stubdom install ifeq (x86_64,$(XEN_TARGET_ARCH)) XEN_TARGET_ARCH=x86_32 $(MAKE) -C stubdom install-grub endif -tools/ioemu-dir: - $(MAKE) -C tools ioemu-dir-find +tools/qemu-xen-traditional-dir: + $(MAKE) -C tools qemu-xen-traditional-dir-find -.PHONY: tools/ioemu-dir-force-update -tools/ioemu-dir-force-update: - $(MAKE) -C tools ioemu-dir-force-update +.PHONY: tools/qemu-xen-traditional-dir-force-update +tools/qemu-xen-traditional-dir-force-update: + $(MAKE) -C tools qemu-xen-traditional-dir-force-update .PHONY: install-docs install-docs: diff -r ecafd034af0e tools/Makefile --- a/tools/Makefile Thu Sep 08 16:52:45 2011 +0000 +++ b/tools/Makefile Thu Sep 08 16:59:19 2011 +0000 @@ -30,7 +30,7 @@ SUBDIRS-$(LIBXENAPI_BINDINGS) += libxen # do not recurse in to a dir we are about to delete ifneq "$(MAKECMDGOALS)" "distclean" -SUBDIRS-$(CONFIG_IOEMU) += ioemu-dir +SUBDIRS-$(CONFIG_IOEMU) += qemu-xen-traditional-dir endif SUBDIRS-y += xenpmd @@ -70,7 +70,7 @@ clean: subdirs-clean .PHONY: distclean distclean: subdirs-distclean - rm -rf ioemu-dir ioemu-dir-remote + rm -rf qemu-xen-traditional-dir qemu-xen-traditional-dir-remote ifneq ($(XEN_COMPILE_ARCH),$(XEN_TARGET_ARCH)) IOEMU_CONFIGURE_CROSS ?= --cpu=$(XEN_TARGET_ARCH) \ @@ -78,24 +78,24 @@ IOEMU_CONFIGURE_CROSS ?= --cpu=$(XEN_TAR --interp-prefix=$(CROSS_SYS_ROOT) endif -ioemu-dir-find: - $(XEN_ROOT)/tools/qemu-checkout.sh $(CONFIG_QEMU) $(QEMU_TAG) ioemu-dir +qemu-xen-traditional-dir-find: + $(XEN_ROOT)/tools/qemu-checkout.sh $(CONFIG_QEMU) $(QEMU_TAG) qemu-xen-traditional-dir -.PHONY: ioemu-dir-force-update -ioemu-dir-force-update: +.PHONY: qemu-xen-traditional-dir-force-update +qemu-xen-traditional-dir-force-update: set -ex; \ if [ "$(QEMU_TAG)" ]; then \ - cd ioemu-dir-remote; \ + cd qemu-xen-traditional-dir-remote; \ $(GIT) fetch origin; \ $(GIT) reset --hard $(QEMU_TAG); \ fi -subdir-all-ioemu-dir subdir-install-ioemu-dir: ioemu-dir-find +subdir-all-qemu-xen-traditional-dir subdir-install-qemu-xen-traditional-dir: qemu-xen-traditional-dir-find -subdir-clean-ioemu-dir: - set -e; if test -d ioemu-dir/.; then \ +subdir-clean-qemu-xen-traditional-dir: + set -e; if test -d qemu-xen-traditional-dir/.; then \ $(buildmakevars2shellvars); \ - $(MAKE) -C ioemu-dir clean; \ + $(MAKE) -C qemu-xen-traditional-dir clean; \ fi subdir-clean-debugger/gdbsx subdir-distclean-debugger/gdbsx: .phony _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel From xen-devel-bounces@lists.xensource.com Thu Sep 08 10:42:24 2011 Return-path: Envelope-to: www-data@lists.xensource.com Delivery-date: Thu, 08 Sep 2011 10:42:24 -0700 Received: from localhost ([127.0.0.1] helo=lists.colo.xensource.com) by lists.xensource.com with esmtp (Exim 4.43) id 1R1icK-0000WB-H7; Thu, 08 Sep 2011 10:42:24 -0700 Received: from mail27.messagelabs.com ([193.109.254.147]) by lists.xensource.com with esmtp (Exim 4.43) id 1R1iZ4-0007eC-VG for xen-devel@lists.xensource.com; Thu, 08 Sep 2011 10:39:03 -0700 X-Env-Sender: Stefano.Stabellini@eu.citrix.com X-Msg-Ref: server-4.tower-27.messagelabs.com!1315503521!39473744!2 X-Originating-IP: [66.165.176.63] X-StarScan-Version: 6.3.6; banners=-,-,- X-VirusChecked: Checked Received: (qmail 18003 invoked from network); 8 Sep 2011 17:38:43 -0000 Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63) by server-4.tower-27.messagelabs.com with RC4-SHA encrypted SMTP; 8 Sep 2011 17:38:43 -0000 X-IronPort-AV: E=Sophos;i="4.68,351,1312171200"; d="scan'208";a="162201867" Received: from ftlpmailmx02.citrite.net ([10.13.107.66]) by FTLPIPO02.CITRIX.COM with ESMTP/TLS/RC4-MD5; 08 Sep 2011 13:38:59 -0400 Received: from smtp01.ad.xensource.com (10.219.128.104) by smtprelay.citrix.com (10.13.107.66) with Microsoft SMTP Server id 8.3.137.0; Thu, 8 Sep 2011 13:38:59 -0400 Received: from localhost.localdomain (kaball.uk.xensource.com [10.80.2.59]) by smtp01.ad.xensource.com (8.13.1/8.13.1) with ESMTP id p88HcrMB029371; Thu, 8 Sep 2011 10:38:57 -0700 From: To: xen-devel@lists.xensource.com Date: Thu, 8 Sep 2011 18:47:18 +0100 Message-ID: <1315504038-21733-4-git-send-email-stefano.stabellini@eu.citrix.com> X-Mailer: git-send-email 1.7.0.4 In-Reply-To: <1315504038-21733-1-git-send-email-stefano.stabellini@eu.citrix.com> References: <1315504038-21733-1-git-send-email-stefano.stabellini@eu.citrix.com> MIME-Version: 1.0 Content-Type: text/plain Cc: keir@xen.org, Ian.Campbell@citrix.com, stefano.stabellini@eu.citrix.com Subject: [Xen-devel] [PATCH v2 4/4] Clone and build Seabios by default X-BeenThere: xen-devel@lists.xensource.com X-Mailman-Version: 2.1.5 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xensource.com Errors-To: xen-devel-bounces@lists.xensource.com Signed-off-by: Stefano Stabellini diff -r ef27b472d4f3 Config.mk --- a/Config.mk Thu Sep 08 17:19:12 2011 +0000 +++ b/Config.mk Thu Sep 08 17:29:50 2011 +0000 @@ -195,6 +195,8 @@ endif # Only available through the git protocol at the moment QEMU_UPSTREAM_URL ?= git://xenbits.xen.org/people/sstabellini/qemu-dm.git QEMU_UPSTREAM_TAG ?= origin/xen-stable-0.15 +SEABIOS_UPSTREAM_URL=git://git.qemu.org/seabios.git +SEABIOS_UPSTREAM_TAG ?= 7fc039e9c262b4199fab497f3e12f4e425c37560 # Specify which qemu-dm to use. This may be `ioemu' to use the old # Mercurial in-tree version, or a local directory, or a git URL. @@ -208,15 +210,6 @@ QEMU_TAG ?= cd776ee9408ff127f934a707c1a3 # Short answer -- do not enable this unless you know what you are # doing and are prepared for some pain. -# SeaBIOS integration is a work in progress. Before enabling this -# option you must clone git://git.qemu.org/seabios.git/, possibly add -# some development patches and then build it yourself before pointing -# this variable to it (using an absolute path). -# -# Note that using SeaBIOS requires the use the upstream qemu as the -# device model. -SEABIOS_DIR ?= - # Optional components XENSTAT_XENTOP ?= y VTPM_TOOLS ?= n diff -r ef27b472d4f3 tools/firmware/Makefile --- a/tools/firmware/Makefile Thu Sep 08 17:19:12 2011 +0000 +++ b/tools/firmware/Makefile Thu Sep 08 17:29:50 2011 +0000 @@ -4,15 +4,35 @@ include $(XEN_ROOT)/tools/Rules.mk # hvmloader is a 32-bit protected mode binary. TARGET := hvmloader/hvmloader INST_DIR := $(DESTDIR)$(XENFIRMWAREDIR) +SEABIOS_DIR := seabios-dir SUBDIRS := +SUBDIRS += $(SEABIOS_DIR) SUBDIRS += rombios SUBDIRS += vgabios SUBDIRS += etherboot SUBDIRS += hvmloader +$(SEABIOS_DIR): + set -ex; \ + if [ ! -d seabios-remote ]; then \ + rm -rf seabios-remote seabios-remote.tmp; \ + mkdir seabios-remote.tmp; rmdir seabios-remote.tmp; \ + $(GIT) clone $(SEABIOS_UPSTREAM_URL) seabios-remote.tmp; \ + if [ "$(SEABIOS_UPSTREAM_TAG)" ]; then \ + cd seabios-remote.tmp; \ + $(GIT) branch -D dummy >/dev/null 2>&1 ||:; \ + $(GIT) checkout -b dummy $(SEABIOS_UPSTREAM_TAG); \ + cd ..; \ + fi; \ + mv seabios-remote.tmp seabios-remote; \ + fi; \ + rm -f seabios-dir; \ + ln -sf seabios-remote seabios-dir; \ + cp seabios-config seabios-dir/.config; + .PHONY: all -all: +all: $(SEABIOS_DIR) @set -e; if [ $$((`( bcc -v 2>&1 | grep version || echo 0.0.0 ) | cut -d' ' -f 3 | awk -F. '{ printf "0x%02x%02x%02x", $$1, $$2, $$3}'`)) -lt $$((0x00100e)) ] ; then \ echo "==========================================================================="; \ echo "Require dev86 rpm or bin86 & bcc debs version >= 0.16.14 to build firmware!"; \ @@ -35,4 +55,7 @@ clean: subdirs-clean distclean: subdirs-distclean subdir-distclean-etherboot: .phony - $(MAKE) -C etherboot distclean \ No newline at end of file + $(MAKE) -C etherboot distclean + +subdir-distclean-$(SEABIOS_DIR): .phony + rm -rf seabios-dir seabios-remote diff -r ef27b472d4f3 tools/firmware/hvmloader/Makefile --- a/tools/firmware/hvmloader/Makefile Thu Sep 08 17:19:12 2011 +0000 +++ b/tools/firmware/hvmloader/Makefile Thu Sep 08 17:29:50 2011 +0000 @@ -47,7 +47,7 @@ endif ifneq ($(SEABIOS_DIR),) OBJS += seabios.o CFLAGS += -DENABLE_SEABIOS -SEABIOS_ROM := $(SEABIOS_DIR)/out/bios.bin +SEABIOS_ROM := ../$(SEABIOS_DIR)/out/bios.bin endif STDVGA_ROM := ../vgabios/VGABIOS-lgpl-latest.bin diff -r ef27b472d4f3 tools/firmware/seabios-config --- /dev/null Thu Jan 01 00:00:00 1970 +0000 +++ b/tools/firmware/seabios-config Thu Sep 08 17:29:50 2011 +0000 @@ -0,0 +1,73 @@ +# +# Automatically generated make config: don't edit +# SeaBIOS Configuration +# Wed Sep 7 13:03:21 2011 +# + +# +# General Features +# +# CONFIG_COREBOOT is not set +CONFIG_XEN=y +CONFIG_THREADS=y +# CONFIG_THREAD_OPTIONROMS is not set +CONFIG_RELOCATE_INIT=y +CONFIG_BOOTMENU=y +# CONFIG_BOOTSPLASH is not set +CONFIG_BOOTORDER=y + +# +# Hardware support +# +CONFIG_ATA=y +CONFIG_ATA_DMA=y +CONFIG_ATA_PIO32=y +CONFIG_AHCI=y +CONFIG_VIRTIO_BLK=y +CONFIG_FLOPPY=y +CONFIG_PS2PORT=y +CONFIG_USB=y +CONFIG_USB_UHCI=y +CONFIG_USB_OHCI=y +CONFIG_USB_EHCI=y +CONFIG_USB_MSC=y +CONFIG_USB_HUB=y +CONFIG_USB_KEYBOARD=y +CONFIG_USB_MOUSE=y +CONFIG_SERIAL=y +CONFIG_LPT=y +# CONFIG_USE_SMM is not set +CONFIG_MTRR_INIT=y + +# +# BIOS interfaces +# +CONFIG_DRIVES=y +CONFIG_CDROM_BOOT=y +CONFIG_CDROM_EMU=y +CONFIG_PCIBIOS=y +CONFIG_APMBIOS=y +CONFIG_PNPBIOS=y +CONFIG_OPTIONROMS=y +# CONFIG_OPTIONROMS_DEPLOYED is not set +CONFIG_PMM=y +CONFIG_BOOT=y +CONFIG_KEYBOARD=y +CONFIG_KBD_CALL_INT15_4F=y +CONFIG_MOUSE=y +CONFIG_S3_RESUME=y +# CONFIG_DISABLE_A20 is not set + +# +# BIOS Tables +# +CONFIG_PIRTABLE=y +CONFIG_MPTABLE=y +CONFIG_SMBIOS=y +CONFIG_ACPI=y + +# +# Debugging +# +CONFIG_DEBUG_LEVEL=1 +# CONFIG_DEBUG_SERIAL is not set _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel From xen-devel-bounces@lists.xensource.com Thu Sep 08 10:43:29 2011 Return-path: Envelope-to: www-data@lists.xensource.com Delivery-date: Thu, 08 Sep 2011 10:43:29 -0700 Received: from localhost ([127.0.0.1] helo=lists.colo.xensource.com) by lists.xensource.com with esmtp (Exim 4.43) id 1R1idN-0000ye-NZ; Thu, 08 Sep 2011 10:43:29 -0700 Received: from mail216.messagelabs.com ([85.158.143.99]) by lists.xensource.com with smtp (Exim 4.43) id 1R1iaN-00083f-U4 for xen-devel@lists.xensource.com; Thu, 08 Sep 2011 10:40:24 -0700 X-Env-Sender: Ian.Jackson@eu.citrix.com X-Msg-Ref: server-4.tower-216.messagelabs.com!1315503621!17563292!1 X-Originating-IP: [62.200.22.115] X-StarScan-Version: 6.3.6; banners=-,-,- X-VirusChecked: Checked Received: (qmail 7001 invoked from network); 8 Sep 2011 17:40:21 -0000 Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115) by server-4.tower-216.messagelabs.com with SMTP; 8 Sep 2011 17:40:21 -0000 X-IronPort-AV: E=Sophos;i="4.68,351,1312156800"; d="scan'208";a="7683523" Received: from lonpmailmx01.citrite.net ([10.30.203.162]) by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5; 08 Sep 2011 17:40:20 +0000 Received: from woking.xci-test.com (10.80.248.135) by smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id 8.3.137.0; Thu, 8 Sep 2011 18:40:20 +0100 Received: from osstest by woking.xci-test.com with local (Exim 4.69) (envelope-from ) id 1R1iaK-00018l-0V; Thu, 08 Sep 2011 18:40:20 +0100 To: xen-devel@lists.xensource.com Message-ID: From: xen.org Date: Thu, 8 Sep 2011 18:40:20 +0100 MIME-Version: 1.0 Content-Type: text/plain Cc: ian.jackson@eu.citrix.com Subject: [Xen-devel] [xen-unstable test] 8865: tolerable FAIL - PUSHED X-BeenThere: xen-devel@lists.xensource.com X-Mailman-Version: 2.1.5 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xensource.com Errors-To: xen-devel-bounces@lists.xensource.com flight 8865 xen-unstable real [real] http://www.chiark.greenend.org.uk/~xensrcts/logs/8865/ Failures :-/ but no regressions. Tests which did not succeed, but are not blocking, including regressions (tests previously passed) regarded as allowable: test-amd64-amd64-xl-pcipt-intel 1 xen-build-check(1) blocked n/a test-amd64-i386-rhel6hvm-intel 1 xen-build-check(1) blocked n/a test-i386-i386-pv 1 xen-build-check(1) blocked n/a test-amd64-i386-pv 1 xen-build-check(1) blocked n/a test-amd64-amd64-pv 1 xen-build-check(1) blocked n/a test-i386-i386-xl 1 xen-build-check(1) blocked n/a test-amd64-i386-xl 1 xen-build-check(1) blocked n/a test-amd64-i386-xl-credit2 1 xen-build-check(1) blocked n/a test-amd64-i386-rhel6hvm-amd 1 xen-build-check(1) blocked n/a test-amd64-amd64-pair 1 xen-build-check(1) blocked n/a test-amd64-i386-pair 1 xen-build-check(1) blocked n/a test-i386-i386-pair 1 xen-build-check(1) blocked n/a build-amd64-pvops 4 kernel-build fail like 8846 build-i386-pvops 4 kernel-build fail like 8846 test-amd64-i386-xl-multivcpu 1 xen-build-check(1) blocked n/a test-amd64-amd64-xl-sedf 1 xen-build-check(1) blocked n/a test-amd64-i386-win-vcpus1 1 xen-build-check(1) blocked n/a test-amd64-i386-xl-win-vcpus1 1 xen-build-check(1) blocked n/a test-amd64-amd64-win 1 xen-build-check(1) blocked n/a test-amd64-i386-win 1 xen-build-check(1) blocked n/a test-amd64-amd64-xl-win 1 xen-build-check(1) blocked n/a test-amd64-amd64-xl 1 xen-build-check(1) blocked n/a test-i386-i386-xl-win 1 xen-build-check(1) blocked n/a test-i386-i386-win 1 xen-build-check(1) blocked n/a version targeted for testing: xen 0312575dc35e baseline version: xen bdd19847ae63 ------------------------------------------------------------ People who touched revisions under test: Christoph Egger Ian Jackson Olaf Hering Tim Deegan ------------------------------------------------------------ jobs: build-amd64 pass build-i386 pass build-amd64-oldkern pass build-i386-oldkern pass build-amd64-pvops fail build-i386-pvops fail test-amd64-amd64-xl blocked test-amd64-i386-xl blocked test-i386-i386-xl blocked test-amd64-i386-rhel6hvm-amd blocked test-amd64-i386-xl-credit2 blocked test-amd64-amd64-xl-pcipt-intel blocked test-amd64-i386-rhel6hvm-intel blocked test-amd64-i386-xl-multivcpu blocked test-amd64-amd64-pair blocked test-amd64-i386-pair blocked test-i386-i386-pair blocked test-amd64-amd64-pv blocked test-amd64-i386-pv blocked test-i386-i386-pv blocked test-amd64-amd64-xl-sedf blocked test-amd64-i386-win-vcpus1 blocked test-amd64-i386-xl-win-vcpus1 blocked test-amd64-amd64-win blocked test-amd64-i386-win blocked test-i386-i386-win blocked test-amd64-amd64-xl-win blocked test-i386-i386-xl-win blocked ------------------------------------------------------------ sg-report-flight on woking.cam.xci-test.com logs: /home/xc_osstest/logs images: /home/xc_osstest/images Logs, config files, etc. are available at http://www.chiark.greenend.org.uk/~xensrcts/logs Test harness code can be found at http://xenbits.xensource.com/gitweb?p=osstest.git;a=summary Pushing revision : + branch=xen-unstable + revision=0312575dc35e + . cri-lock-repos ++ . cri-common +++ umask 002 +++ getconfig Repos +++ perl -e ' use Osstest; readconfigonly(); print $c{Repos} or die $!; ' ++ repos=/export/home/osstest/repos ++ repos_lock=/export/home/osstest/repos/lock ++ '[' x '!=' x/export/home/osstest/repos/lock ']' ++ OSSTEST_REPOS_LOCK_LOCKED=/export/home/osstest/repos/lock ++ exec with-lock-ex -w /export/home/osstest/repos/lock ./ap-push xen-unstable 0312575dc35e + branch=xen-unstable + revision=0312575dc35e + . cri-lock-repos ++ . cri-common +++ umask 002 +++ getconfig Repos +++ perl -e ' use Osstest; readconfigonly(); print $c{Repos} or die $!; ' ++ repos=/export/home/osstest/repos ++ repos_lock=/export/home/osstest/repos/lock ++ '[' x/export/home/osstest/repos/lock '!=' x/export/home/osstest/repos/lock ']' + : xen@xenbits.xensource.com + : xen@xenbits.xensource.com:git/linux-pvops + : master + : tested/2.6.39.x + case "$branch" in + cd /export/home/osstest/repos/xen-unstable.hg + hg push -r 0312575dc35e ssh://xen@xenbits.xensource.com/HG/xen-unstable.hg pushing to ssh://xen@xenbits.xensource.com/HG/xen-unstable.hg searching for changes remote: adding changesets remote: adding manifests remote: adding file changes remote: added 3 changesets with 17 changes to 13 files _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel From xen-devel-bounces@lists.xensource.com Thu Sep 08 10:44:17 2011 Return-path: Envelope-to: www-data@lists.xensource.com Delivery-date: Thu, 08 Sep 2011 10:44:17 -0700 Received: from localhost ([127.0.0.1] helo=lists.colo.xensource.com) by lists.xensource.com with esmtp (Exim 4.43) id 1R1ie9-0001La-9H; Thu, 08 Sep 2011 10:44:17 -0700 Received: from mail27.messagelabs.com ([193.109.254.147]) by lists.xensource.com with esmtp (Exim 4.43) id 1R1iaz-0008Ke-R2 for xen-devel@lists.xensource.com; Thu, 08 Sep 2011 10:41:02 -0700 X-Env-Sender: david.vrabel@citrix.com X-Msg-Ref: server-8.tower-27.messagelabs.com!1315503642!45810778!1 X-Originating-IP: [66.165.176.89] X-StarScan-Version: 6.3.6; banners=-,-,- X-VirusChecked: Checked Received: (qmail 6459 invoked from network); 8 Sep 2011 17:40:44 -0000 Received: from smtp.citrix.com (HELO SMTP.CITRIX.COM) (66.165.176.89) by server-8.tower-27.messagelabs.com with RC4-SHA encrypted SMTP; 8 Sep 2011 17:40:44 -0000 X-IronPort-AV: E=Sophos;i="4.68,351,1312171200"; d="scan'208";a="16803435" Received: from ftlpmailmx02.citrite.net ([10.13.107.66]) by FTLPIPO01.CITRIX.COM with ESMTP/TLS/RC4-MD5; 08 Sep 2011 13:40:57 -0400 Received: from [10.80.2.76] (10.80.2.76) by FTLPMAILMX02.citrite.net (10.13.107.66) with Microsoft SMTP Server id 8.3.137.0; Thu, 8 Sep 2011 13:40:57 -0400 Message-ID: <4E68FEF6.10206@citrix.com> Date: Thu, 8 Sep 2011 18:44:22 +0100 From: David Vrabel User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.1.16) Gecko/20110818 Icedove/3.0.11 MIME-Version: 1.0 To: Konrad Rzeszutek Wilk Subject: Re: [Xen-devel] xl vs. xm, possible bug in xl References: <20110908170755.GB16730@dumpdata.com> In-Reply-To: <20110908170755.GB16730@dumpdata.com> Content-Type: text/plain; charset="ISO-8859-1" Content-Transfer-Encoding: 8bit Cc: "xen-devel@lists.xensource.com" , =?ISO-8859-1?Q?Sven_K=F6hler?= X-BeenThere: xen-devel@lists.xensource.com X-Mailman-Version: 2.1.5 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xensource.com Errors-To: xen-devel-bounces@lists.xensource.com On 08/09/11 18:07, Konrad Rzeszutek Wilk wrote: > On Thu, Sep 08, 2011 at 06:42:12PM +0200, Sven Köhler wrote: >> Hi, >> >> xl is supposed to superseed xm, is this correct? How mature is xl, >> actually? I'm asking, because the maintainers of the gentoo's xen >> packages are migrating the init.d-scripts from xm to xl, but xl is >> causing a lot of trouble. >> >> Well, xl basically fails to start domains on my system. >>> # xl create /etc/xen/xen-sk1 >>> Parsing config file /etc/xen/xen-sk1 >>> libxl: error: libxl.c:2145:libxl_set_memory_target new target 0 for dom0 is below the minimum threshold >>> libxl: error: libxl.c:2145:libxl_set_memory_target new target 0 for dom0 is below the minimum threshold >>> libxl: error: libxl.c:2145:libxl_set_memory_target new target 0 for dom0 is below the minimum threshold >>> failed to free memory for the domain >> >> Consider, that autobaloon=1 in xl.conf. >> With the autobaloon=0 the errors change to >> >>> # xl create /etc/xen/xen-sk1 >>> Parsing config file /etc/xen/xen-sk1 >>> libxl: error: libxl_device.c:476:libxl__wait_for_device_model Device Model not ready >>> xl: fatal error: libxl_create.c:535, rc=-1: libxl__confirm_device_model_startup >> >> >> Note, that I use dom0_mem=512M in grub.conf. Also, xm top states, that >> there are 2139432k free memory. Considering the first issue, it seems >> like xl is trying to baloon memory away from dom0, which fails - which >> seems obvious wrong considering that I use dom0_mem. CONFIG_XEN_BALLOON >> is enabled for dom0 > > Yeah, there is a bug there (in Linux kernel) that just got integrated in 3.1-rc5. > Will show up in 3.0.5. > > Hm, but the migrating memory away from dom0 seems bizzare. Lets ping > David who has been in the thick of this. I have a feeling it is the > "delta" patches .. This patch: http://lists.xensource.com/archives/html/xen-devel/2011-08/msg00813.html is only relevant if the initial number of pages overlaps with gaps in the memory map (typically more than 3 GB). With dom0_mem=512M you shouldn't be hitting this. So I don't think any of the patches in that series are relevant here (but you could give them a try anyway). >> The second issue sounds more severe, and I'm pretty clueless. >> >> Is this a bug in xl? > >> Starting the very same domain with xm works without a hassle. >> >> >> dom0: >> vanilla 3.0.0 with vga patch > > You could upgrade to 3.0.4 and then you get the VGA patch for free > (and some bug-fixes too). > >> xen 4.1.1 >> >> domU config: >> kernel = "/usr/src/linux-domU/_domU/vmlinux" >> memory = 2048 >> vcpus = 8 >> >> root = "/dev/xvda1" >> extra = "ro" >> >> disk = [ >> "phy:/dev/md2,xvda1,w", >> "phy:/dev/md5,xvda2,w", >> ] >> vif = [ >> "bridge=xenbr0,mac=00:16:3E:00:00:01", >> "bridge=xenbr1,mac=00:16:3E:00:01:01", >> ] _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel From xen-devel-bounces@lists.xensource.com Thu Sep 08 10:45:06 2011 Return-path: Envelope-to: www-data@lists.xensource.com Delivery-date: Thu, 08 Sep 2011 10:45:06 -0700 Received: from localhost ([127.0.0.1] helo=lists.colo.xensource.com) by lists.xensource.com with esmtp (Exim 4.43) id 1R1iew-0001iZ-Km; Thu, 08 Sep 2011 10:45:06 -0700 Received: from mail182.messagelabs.com ([85.158.139.83]) by lists.xensource.com with smtp (Exim 4.43) id 1R1idJ-0000w9-Us for xen-devel@lists.xensource.com; Thu, 08 Sep 2011 10:43:27 -0700 X-Env-Sender: Ian.Jackson@eu.citrix.com X-Msg-Ref: server-3.tower-182.messagelabs.com!1315503802!14806811!1 X-Originating-IP: [62.200.22.115] X-StarScan-Version: 6.3.6; banners=-,-,- X-VirusChecked: Checked Received: (qmail 1017 invoked from network); 8 Sep 2011 17:43:22 -0000 Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115) by server-3.tower-182.messagelabs.com with SMTP; 8 Sep 2011 17:43:22 -0000 X-IronPort-AV: E=Sophos;i="4.68,351,1312156800"; d="scan'208";a="7683601" Received: from lonpmailmx01.citrite.net ([10.30.203.162]) by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5; 08 Sep 2011 17:43:22 +0000 Received: from woking.xci-test.com (10.80.248.135) by smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id 8.3.137.0; Thu, 8 Sep 2011 18:43:22 +0100 Received: from osstest by woking.xci-test.com with local (Exim 4.69) (envelope-from ) id 1R1idG-0001Sd-17; Thu, 08 Sep 2011 18:43:22 +0100 To: xen-devel@lists.xensource.com Message-ID: From: xen.org Date: Thu, 8 Sep 2011 18:43:22 +0100 MIME-Version: 1.0 Content-Type: text/plain Cc: ian.jackson@eu.citrix.com Subject: [Xen-devel] [xen-4.0-testing test] 8863: regressions - FAIL X-BeenThere: xen-devel@lists.xensource.com X-Mailman-Version: 2.1.5 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xensource.com Errors-To: xen-devel-bounces@lists.xensource.com flight 8863 xen-4.0-testing real [real] http://www.chiark.greenend.org.uk/~xensrcts/logs/8863/ Regressions :-( Tests which did not succeed and are blocking: test-amd64-amd64-xl-win 5 xen-boot fail REGR. vs. 8855 Tests which did not succeed, but are not blocking, including regressions (tests previously passed) regarded as allowable: test-amd64-amd64-xl-pcipt-intel 8 debian-fixup fail never pass test-amd64-amd64-xl 15 guest-stop fail never pass test-amd64-i386-xl-multivcpu 15 guest-stop fail never pass test-i386-i386-xl 15 guest-stop fail never pass test-amd64-i386-xl 15 guest-stop fail never pass test-amd64-i386-xl-credit2 14 guest-localmigrate/x10 fail like 8855 test-amd64-amd64-xl-sedf 9 guest-start fail blocked in 8855 test-i386-i386-win 16 leak-check/check fail never pass test-amd64-i386-rhel6hvm-intel 7 redhat-install fail never pass test-amd64-i386-rhel6hvm-amd 7 redhat-install fail never pass test-amd64-i386-win-vcpus1 16 leak-check/check fail never pass test-amd64-amd64-win 16 leak-check/check fail never pass test-amd64-i386-win 16 leak-check/check fail never pass test-amd64-i386-xl-win-vcpus1 7 windows-install fail never pass test-i386-i386-xl-win 7 windows-install fail never pass version targeted for testing: xen 789ff1a462b8 baseline version: xen b44346a6975c ------------------------------------------------------------ People who touched revisions under test: Allen M Kay Tim Deegan Wei Wang2 ------------------------------------------------------------ jobs: build-amd64 pass build-i386 pass build-amd64-oldkern pass build-i386-oldkern pass build-amd64-pvops pass build-i386-pvops pass test-amd64-amd64-xl fail test-amd64-i386-xl fail test-i386-i386-xl fail test-amd64-i386-rhel6hvm-amd fail test-amd64-i386-xl-credit2 fail test-amd64-amd64-xl-pcipt-intel fail test-amd64-i386-rhel6hvm-intel fail test-amd64-i386-xl-multivcpu fail test-amd64-amd64-pair pass test-amd64-i386-pair pass test-i386-i386-pair pass test-amd64-amd64-pv pass test-amd64-i386-pv pass test-i386-i386-pv pass test-amd64-amd64-xl-sedf fail test-amd64-i386-win-vcpus1 fail test-amd64-i386-xl-win-vcpus1 fail test-amd64-amd64-win fail test-amd64-i386-win fail test-i386-i386-win fail test-amd64-amd64-xl-win fail test-i386-i386-xl-win fail ------------------------------------------------------------ sg-report-flight on woking.cam.xci-test.com logs: /home/xc_osstest/logs images: /home/xc_osstest/images Logs, config files, etc. are available at http://www.chiark.greenend.org.uk/~xensrcts/logs Test harness code can be found at http://xenbits.xensource.com/gitweb?p=osstest.git;a=summary Not pushing. ------------------------------------------------------------ changeset: 21535:789ff1a462b8 tag: tip user: Tim Deegan date: Thu Sep 08 12:23:52 2011 +0100 Passthrough: disable bus-mastering on any card that causes an IOMMU fault. This stops the card from raising back-to-back faults and live-locking the CPU that handles them. Signed-off-by: Tim Deegan Acked-by: Wei Wang2 Acked-by: Allen M Kay xen-unstable changeset: 23762:537ed3b74b3f xen-unstable date: Fri Aug 12 11:29:24 2011 +0100 changeset: 21534:2906ef107e97 user: Keir Fraser date: Thu Sep 08 12:23:22 2011 +0100 Update Xen version to 4.0.3-rc3-pre changeset: 21533:b44346a6975c user: Keir Fraser date: Wed Sep 07 10:41:49 2011 +0100 Added signature for changeset 8d012bc20d30 (qemu changes not included) _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel From xen-devel-bounces@lists.xensource.com Thu Sep 08 10:57:11 2011 Return-path: Envelope-to: www-data@lists.xensource.com Delivery-date: Thu, 08 Sep 2011 10:57:11 -0700 Received: from localhost ([127.0.0.1] helo=lists.colo.xensource.com) by lists.xensource.com with esmtp (Exim 4.43) id 1R1iqd-0002Pz-C8; Thu, 08 Sep 2011 10:57:11 -0700 Received: from mail216.messagelabs.com ([85.158.143.99]) by lists.xensource.com with esmtp (Exim 4.43) id 1R1iq5-0002Ci-KV for xen-devel@lists.xensource.com; Thu, 08 Sep 2011 10:56:37 -0700 X-Env-Sender: Ian.Campbell@eu.citrix.com X-Msg-Ref: server-5.tower-216.messagelabs.com!1315504592!17091884!1 X-Originating-IP: [66.165.176.63] X-StarScan-Version: 6.3.6; banners=-,-,- X-VirusChecked: Checked Received: (qmail 10120 invoked from network); 8 Sep 2011 17:56:34 -0000 Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63) by server-5.tower-216.messagelabs.com with RC4-SHA encrypted SMTP; 8 Sep 2011 17:56:34 -0000 X-IronPort-AV: E=Sophos;i="4.68,351,1312171200"; d="scan'208";a="162204921" Received: from ftlpmailmx01.citrite.net ([10.13.107.65]) by FTLPIPO02.CITRIX.COM with ESMTP/TLS/RC4-MD5; 08 Sep 2011 13:56:27 -0400 Received: from [127.0.0.1] (10.80.16.67) by smtprelay.citrix.com (10.13.107.65) with Microsoft SMTP Server id 8.3.137.0; Thu, 8 Sep 2011 13:56:26 -0400 Subject: Re: [Xen-devel] [PATCH v2 3/4] Clone and build upstream Qemu by default From: Ian Campbell To: "stefano.stabellini@eu.citrix.com" Date: Thu, 8 Sep 2011 10:56:23 -0700 In-Reply-To: <1315504038-21733-3-git-send-email-stefano.stabellini@eu.citrix.com> References: <1315504038-21733-1-git-send-email-stefano.stabellini@eu.citrix.com> <1315504038-21733-3-git-send-email-stefano.stabellini@eu.citrix.com> Organization: Citrix Systems, Inc. Content-Type: text/plain; charset="UTF-8" X-Mailer: Evolution 3.0.3- Content-Transfer-Encoding: 7bit Message-ID: <1315504587.3180.47.camel@cthulhu.hellion.org.uk> MIME-Version: 1.0 Cc: "xen-devel@lists.xensource.com" , "keir@xen.org" X-BeenThere: xen-devel@lists.xensource.com X-Mailman-Version: 2.1.5 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xensource.com Errors-To: xen-devel-bounces@lists.xensource.com On Thu, 2011-09-08 at 13:47 -0400, stefano.stabellini@eu.citrix.com wrote: > Signed-off-by: Stefano Stabellini > > diff -r 80ba2c7abbd2 Config.mk > --- a/Config.mk Thu Sep 08 16:59:19 2011 +0000 > +++ b/Config.mk Thu Sep 08 17:18:48 2011 +0000 > @@ -192,6 +192,10 @@ else > QEMU_REMOTE=git://xenbits.xensource.com/qemu-xen-unstable.git > endif > > +# Only available through the git protocol at the moment > +QEMU_UPSTREAM_URL ?= git://xenbits.xen.org/people/sstabellini/qemu-dm.git Just a nit, but we should arrange to have a "proper" tree rather than a /people/... one for the default tree. e.g. to allow automated testing to automatically push etc. > +QEMU_UPSTREAM_TAG ?= origin/xen-stable-0.15 > + > # Specify which qemu-dm to use. This may be `ioemu' to use the old > # Mercurial in-tree version, or a local directory, or a git URL. > # CONFIG_QEMU ?= `pwd`/$(XEN_ROOT)/../qemu-xen.git > diff -r 80ba2c7abbd2 Makefile > --- a/Makefile Thu Sep 08 16:59:19 2011 +0000 > +++ b/Makefile Thu Sep 08 17:18:48 2011 +0000 > @@ -70,7 +70,7 @@ install-tools: > $(MAKE) -C tools install > > ifeq ($(CONFIG_IOEMU),y) > -install-tools: tools/qemu-xen-traditional-dir > +install-tools: tools/qemu-xen-traditional-dir tools/qemu-xen-dir > endif > > .PHONY: install-kernels > @@ -91,6 +91,9 @@ tools/qemu-xen-traditional-dir: > tools/qemu-xen-traditional-dir-force-update: > $(MAKE) -C tools qemu-xen-traditional-dir-force-update > > +tools/qemu-xen-dir: > + $(MAKE) -C tools qemu-xen-dir-find > + > .PHONY: install-docs > install-docs: > sh ./docs/check_pkgs && $(MAKE) -C docs install || true > diff -r 80ba2c7abbd2 tools/Makefile > --- a/tools/Makefile Thu Sep 08 16:59:19 2011 +0000 > +++ b/tools/Makefile Thu Sep 08 17:18:48 2011 +0000 > @@ -31,6 +31,7 @@ SUBDIRS-$(LIBXENAPI_BINDINGS) += libxen > # do not recurse in to a dir we are about to delete > ifneq "$(MAKECMDGOALS)" "distclean" > SUBDIRS-$(CONFIG_IOEMU) += qemu-xen-traditional-dir > +SUBDIRS-$(CONFIG_IOEMU) += qemu-xen-dir > endif > > SUBDIRS-y += xenpmd > @@ -71,6 +72,7 @@ clean: subdirs-clean > .PHONY: distclean > distclean: subdirs-distclean > rm -rf qemu-xen-traditional-dir qemu-xen-traditional-dir-remote > + rm -rf qemu-xen-dir qemu-xen-dir-remote > > ifneq ($(XEN_COMPILE_ARCH),$(XEN_TARGET_ARCH)) > IOEMU_CONFIGURE_CROSS ?= --cpu=$(XEN_TARGET_ARCH) \ > @@ -81,6 +83,9 @@ endif > qemu-xen-traditional-dir-find: > $(XEN_ROOT)/tools/qemu-checkout.sh $(CONFIG_QEMU) $(QEMU_TAG) qemu-xen-traditional-dir > > +qemu-xen-dir-find: > + $(XEN_ROOT)/tools/qemu-checkout.sh $(QEMU_UPSTREAM_URL) $(QEMU_UPSTREAM_TAG) qemu-xen-dir > + > .PHONY: qemu-xen-traditional-dir-force-update > qemu-xen-traditional-dir-force-update: > set -ex; \ > @@ -98,6 +103,14 @@ subdir-clean-qemu-xen-traditional-dir: > $(MAKE) -C qemu-xen-traditional-dir clean; \ > fi > > +subdir-all-qemu-xen-dir subdir-install-qemu-xen-dir: qemu-xen-dir-find > + > +subdir-clean-qemu-xen-dir: > + set -e; if test -d qemu-xen-dir/.; then \ > + $(buildmakevars2shellvars); \ > + $(MAKE) -C qemu-xen-dir clean; \ > + fi > + > subdir-clean-debugger/gdbsx subdir-distclean-debugger/gdbsx: .phony > $(MAKE) -C debugger/gdbsx clean > > > _______________________________________________ > Xen-devel mailing list > Xen-devel@lists.xensource.com > http://lists.xensource.com/xen-devel _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel From xen-devel-bounces@lists.xensource.com Thu Sep 08 11:02:59 2011 Return-path: Envelope-to: www-data@lists.xensource.com Delivery-date: Thu, 08 Sep 2011 11:02:59 -0700 Received: from localhost ([127.0.0.1] helo=lists.colo.xensource.com) by lists.xensource.com with esmtp (Exim 4.43) id 1R1iwF-0002y8-5x; Thu, 08 Sep 2011 11:02:59 -0700 Received: from mail182.messagelabs.com ([85.158.139.83]) by lists.xensource.com with esmtp (Exim 4.43) id 1R1itN-0002jY-CG for xen-devel@lists.xensource.com; Thu, 08 Sep 2011 11:00:09 -0700 X-Env-Sender: kozhevnikov1993@bk.ru X-Msg-Ref: server-3.tower-182.messagelabs.com!1315504797!14808222!1 X-Originating-IP: [94.100.178.94] X-StarScan-Version: 6.3.6; banners=-,-,- X-VirusChecked: Checked Received: (qmail 26977 invoked from network); 8 Sep 2011 17:59:58 -0000 Received: from f177.mail.ru (HELO f177.mail.ru) (94.100.178.94) by server-3.tower-182.messagelabs.com with DHE-RSA-AES256-SHA encrypted SMTP; 8 Sep 2011 17:59:58 -0000 Received: from mail by f177.mail.ru with local id 1R1itJ-0007st-00 for xen-devel@lists.xensource.com; Thu, 08 Sep 2011 21:59:57 +0400 Received: from [93.175.22.144] by e.mail.ru with HTTP; Thu, 08 Sep 2011 21:59:57 +0400 From: =?UTF-8?B?TWF4aW0gS296aGV2bmlrb3Y=?= To: xen-devel@lists.xensource.com Mime-Version: 1.0 X-Mailer: mPOP Web-Mail 2.19 X-Originating-IP: [93.175.22.144] Date: Thu, 08 Sep 2011 21:59:57 +0400 Message-Id: X-Spam: Not detected X-Mras: Ok Subject: [Xen-devel] Whether xen will support intel atom cpu X-BeenThere: xen-devel@lists.xensource.com X-Mailman-Version: 2.1.5 Precedence: list Reply-To: =?UTF-8?B?TWF4aW0gS296aGV2bmlrb3Y=?= List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1393248476==" Sender: xen-devel-bounces@lists.xensource.com Errors-To: xen-devel-bounces@lists.xensource.com --===============1393248476== Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: base64 SSBoYXZlIHBjIHdpdGggaW50ZWwgYXRvbSBjcHUuIApBbmQgV2hlbiB1c2UgeGVuIGkgZ290IHRo ZSBmb2xsb3dpbmcgZXJyb3I6IAoiUGVyZm9ybWFuY2UgRXZlbnRzIDogdW5zdXBwb3J0ZWQgcDYg Q1BVIG1vZGVsIDI4IG5vIFBNVSBkcml2ZXIsIHNvZnR3YXJlIGV2ZW50cyBvbmx5LiIKU28sIGkg Y2FuIHVzZSBzdXNwZW5kIHRvIHJhbSBidXQgY2FuJ3QgdXNlIHdha2UgdXAgZnJvbSByYW0gb24g bXkgcGMuClBsZWFzZSwgdGVsbCBtZSwgd2hlbiB4ZW4gd2lsbCBzdXBwb3J0IGludGVsIGF0b20g Y3B1PwpJIHVzZSB4ZW4tdW5zdGFibGUgKDQuMik= --===============1393248476== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel --===============1393248476==-- From xen-devel-bounces@lists.xensource.com Thu Sep 08 11:05:18 2011 Return-path: Envelope-to: www-data@lists.xensource.com Delivery-date: Thu, 08 Sep 2011 11:05:18 -0700 Received: from localhost ([127.0.0.1] helo=lists.colo.xensource.com) by lists.xensource.com with esmtp (Exim 4.43) id 1R1iyT-0003Mc-G4; Thu, 08 Sep 2011 11:05:17 -0700 Received: from mail174.messagelabs.com ([85.158.138.51]) by lists.xensource.com with esmtp (Exim 4.43) id 1R1itq-0002kR-Ny for xen-devel@lists.xensource.com; Thu, 08 Sep 2011 11:00:34 -0700 X-Env-Sender: Ian.Campbell@eu.citrix.com X-Msg-Ref: server-6.tower-174.messagelabs.com!1315504825!28610729!1 X-Originating-IP: [66.165.176.89] X-StarScan-Version: 6.3.6; banners=-,-,- X-VirusChecked: Checked Received: (qmail 14514 invoked from network); 8 Sep 2011 18:00:27 -0000 Received: from smtp.citrix.com (HELO SMTP.CITRIX.COM) (66.165.176.89) by server-6.tower-174.messagelabs.com with RC4-SHA encrypted SMTP; 8 Sep 2011 18:00:27 -0000 X-IronPort-AV: E=Sophos;i="4.68,351,1312171200"; d="scan'208";a="16804089" Received: from ftlpmailmx02.citrite.net ([10.13.107.66]) by FTLPIPO01.CITRIX.COM with ESMTP/TLS/RC4-MD5; 08 Sep 2011 14:00:25 -0400 Received: from [127.0.0.1] (10.80.16.67) by smtprelay.citrix.com (10.13.107.66) with Microsoft SMTP Server id 8.3.137.0; Thu, 8 Sep 2011 14:00:25 -0400 Subject: Re: [Xen-devel] [PATCH v2 4/4] Clone and build Seabios by default From: Ian Campbell To: "stefano.stabellini@eu.citrix.com" Date: Thu, 8 Sep 2011 11:00:22 -0700 In-Reply-To: <1315504038-21733-4-git-send-email-stefano.stabellini@eu.citrix.com> References: <1315504038-21733-1-git-send-email-stefano.stabellini@eu.citrix.com> <1315504038-21733-4-git-send-email-stefano.stabellini@eu.citrix.com> Organization: Citrix Systems, Inc. Content-Type: text/plain; charset="UTF-8" X-Mailer: Evolution 3.0.3- Content-Transfer-Encoding: 7bit Message-ID: <1315504825.3180.51.camel@cthulhu.hellion.org.uk> MIME-Version: 1.0 Cc: "xen-devel@lists.xensource.com" , "keir@xen.org" X-BeenThere: xen-devel@lists.xensource.com X-Mailman-Version: 2.1.5 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xensource.com Errors-To: xen-devel-bounces@lists.xensource.com On Thu, 2011-09-08 at 13:47 -0400, stefano.stabellini@eu.citrix.com wrote: > Signed-off-by: Stefano Stabellini > > diff -r ef27b472d4f3 Config.mk > --- a/Config.mk Thu Sep 08 17:19:12 2011 +0000 > +++ b/Config.mk Thu Sep 08 17:29:50 2011 +0000 > @@ -195,6 +195,8 @@ endif > # Only available through the git protocol at the moment > QEMU_UPSTREAM_URL ?= git://xenbits.xen.org/people/sstabellini/qemu-dm.git > QEMU_UPSTREAM_TAG ?= origin/xen-stable-0.15 > +SEABIOS_UPSTREAM_URL=git://git.qemu.org/seabios.git > +SEABIOS_UPSTREAM_TAG ?= 7fc039e9c262b4199fab497f3e12f4e425c37560 I guess we should have a default tree on xenbits for this? [...] > +$(SEABIOS_DIR): > + set -ex; \ > + if [ ! -d seabios-remote ]; then \ > + rm -rf seabios-remote seabios-remote.tmp; \ > + mkdir seabios-remote.tmp; rmdir seabios-remote.tmp; \ > + $(GIT) clone $(SEABIOS_UPSTREAM_URL) seabios-remote.tmp; \ > + if [ "$(SEABIOS_UPSTREAM_TAG)" ]; then \ > + cd seabios-remote.tmp; \ > + $(GIT) branch -D dummy >/dev/null 2>&1 ||:; \ > + $(GIT) checkout -b dummy $(SEABIOS_UPSTREAM_TAG); \ > + cd ..; \ > + fi; \ > + mv seabios-remote.tmp seabios-remote; \ > + fi; \ > + rm -f seabios-dir; \ > + ln -sf seabios-remote seabios-dir; \ > + cp seabios-config seabios-dir/.config; This looks a lot like the qemu stuff which you only just moved into its own script. Can we not share it? > diff -r ef27b472d4f3 tools/firmware/hvmloader/Makefile > --- a/tools/firmware/hvmloader/Makefile Thu Sep 08 17:19:12 2011 +0000 > +++ b/tools/firmware/hvmloader/Makefile Thu Sep 08 17:29:50 2011 +0000 > @@ -47,7 +47,7 @@ endif > ifneq ($(SEABIOS_DIR),) > OBJS += seabios.o > CFLAGS += -DENABLE_SEABIOS > -SEABIOS_ROM := $(SEABIOS_DIR)/out/bios.bin > +SEABIOS_ROM := ../$(SEABIOS_DIR)/out/bios.bin > endif > > STDVGA_ROM := ../vgabios/VGABIOS-lgpl-latest.bin _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel From xen-devel-bounces@lists.xensource.com Thu Sep 08 11:07:24 2011 Return-path: Envelope-to: www-data@lists.xensource.com Delivery-date: Thu, 08 Sep 2011 11:07:24 -0700 Received: from localhost ([127.0.0.1] helo=lists.colo.xensource.com) by lists.xensource.com with esmtp (Exim 4.43) id 1R1j0W-0003kJ-OK; Thu, 08 Sep 2011 11:07:24 -0700 Received: from mail216.messagelabs.com ([85.158.143.99]) by lists.xensource.com with smtp (Exim 4.43) id 1R1iu9-0002kb-Rv for xen-devel@lists.xensource.com; Thu, 08 Sep 2011 11:00:52 -0700 X-Env-Sender: Ian.Jackson@eu.citrix.com X-Msg-Ref: server-9.tower-216.messagelabs.com!1315504846!17592600!1 X-Originating-IP: [62.200.22.115] X-StarScan-Version: 6.3.6; banners=-,-,- X-VirusChecked: Checked Received: (qmail 30941 invoked from network); 8 Sep 2011 18:00:46 -0000 Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115) by server-9.tower-216.messagelabs.com with SMTP; 8 Sep 2011 18:00:46 -0000 X-IronPort-AV: E=Sophos;i="4.68,351,1312156800"; d="scan'208";a="7683864" Received: from lonpmailmx01.citrite.net ([10.30.203.162]) by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5; 08 Sep 2011 18:00:46 +0000 Received: from woking.xci-test.com (10.80.248.135) by smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id 8.3.137.0; Thu, 8 Sep 2011 19:00:46 +0100 Received: from osstest by woking.xci-test.com with local (Exim 4.69) (envelope-from ) id 1R1iu5-0000d1-VS; Thu, 08 Sep 2011 19:00:45 +0100 To: Message-ID: From: xen.org Date: Thu, 8 Sep 2011 19:00:45 +0100 MIME-Version: 1.0 Content-Type: text/plain Cc: ian.jackson@eu.citrix.com Subject: [Xen-devel] [xen-4.1-testing test] 8864: regressions - FAIL X-BeenThere: xen-devel@lists.xensource.com X-Mailman-Version: 2.1.5 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xensource.com Errors-To: xen-devel-bounces@lists.xensource.com flight 8864 xen-4.1-testing real [real] http://www.chiark.greenend.org.uk/~xensrcts/logs/8864/ Regressions :-( Tests which did not succeed and are blocking: test-amd64-amd64-xl-sedf 10 guest-saverestore fail REGR. vs. 8853 Tests which did not succeed, but are not blocking, including regressions (tests previously passed) regarded as allowable: test-amd64-amd64-xl-pcipt-intel 9 guest-start fail never pass test-amd64-i386-rhel6hvm-intel 9 guest-start.2 fail never pass test-amd64-i386-rhel6hvm-amd 9 guest-start.2 fail never pass test-amd64-i386-win-vcpus1 16 leak-check/check fail never pass test-amd64-i386-xl-win-vcpus1 13 guest-stop fail never pass test-amd64-i386-win 16 leak-check/check fail never pass test-amd64-amd64-win 16 leak-check/check fail never pass test-amd64-amd64-xl-win 13 guest-stop fail never pass test-i386-i386-win 16 leak-check/check fail never pass test-i386-i386-xl-win 13 guest-stop fail never pass version targeted for testing: xen 78d8c5227bb1 baseline version: xen 2376070f6685 ------------------------------------------------------------ People who touched revisions under test: ------------------------------------------------------------ jobs: build-amd64 pass build-i386 pass build-amd64-oldkern pass build-i386-oldkern pass build-amd64-pvops pass build-i386-pvops pass test-amd64-amd64-xl pass test-amd64-i386-xl pass test-i386-i386-xl pass test-amd64-i386-rhel6hvm-amd fail test-amd64-i386-xl-credit2 pass test-amd64-amd64-xl-pcipt-intel fail test-amd64-i386-rhel6hvm-intel fail test-amd64-i386-xl-multivcpu pass test-amd64-amd64-pair pass test-amd64-i386-pair pass test-i386-i386-pair pass test-amd64-amd64-pv pass test-amd64-i386-pv pass test-i386-i386-pv pass test-amd64-amd64-xl-sedf fail test-amd64-i386-win-vcpus1 fail test-amd64-i386-xl-win-vcpus1 fail test-amd64-amd64-win fail test-amd64-i386-win fail test-i386-i386-win fail test-amd64-amd64-xl-win fail test-i386-i386-xl-win fail ------------------------------------------------------------ sg-report-flight on woking.cam.xci-test.com logs: /home/xc_osstest/logs images: /home/xc_osstest/images Logs, config files, etc. are available at http://www.chiark.greenend.org.uk/~xensrcts/logs Test harness code can be found at http://xenbits.xensource.com/gitweb?p=osstest.git;a=summary Not pushing. ------------------------------------------------------------ changeset: 23152:78d8c5227bb1 tag: tip user: Keir Fraser date: Thu Sep 08 12:24:35 2011 +0100 Update Xen version to 4.1.2-rc3-pre changeset: 23151:2376070f6685 user: Keir Fraser date: Wed Sep 07 10:41:01 2011 +0100 Added signature for changeset 3e6a3bf83935 (qemu changes not included) _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel From xen-devel-bounces@lists.xensource.com Thu Sep 08 11:13:21 2011 Return-path: Envelope-to: www-data@lists.xensource.com Delivery-date: Thu, 08 Sep 2011 11:13:21 -0700 Received: from localhost ([127.0.0.1] helo=lists.colo.xensource.com) by lists.xensource.com with esmtp (Exim 4.43) id 1R1j6H-0004C4-PN; Thu, 08 Sep 2011 11:13:21 -0700 Received: from mail27.messagelabs.com ([193.109.254.147]) by lists.xensource.com with esmtp (Exim 4.43) id 1R1j5W-0003zW-E2 for xen-devel@lists.xensource.com; Thu, 08 Sep 2011 11:12:35 -0700 X-Env-Sender: konrad@dumpdata.com X-Msg-Ref: server-10.tower-27.messagelabs.com!1315505531!34964088!1 X-Originating-IP: [141.146.126.227] X-StarScan-Version: 6.3.6; banners=-,-,- X-VirusChecked: Checked Received: (qmail 9831 invoked from network); 8 Sep 2011 18:12:13 -0000 Received: from acsinet15.oracle.com (HELO acsinet15.oracle.com) (141.146.126.227) by server-10.tower-27.messagelabs.com with DHE-RSA-AES256-SHA encrypted SMTP; 8 Sep 2011 18:12:13 -0000 Received: from rtcsinet22.oracle.com (rtcsinet22.oracle.com [66.248.204.30]) by acsinet15.oracle.com (Switch-3.4.4/Switch-3.4.4) with ESMTP id p88ICQcx022114 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Thu, 8 Sep 2011 18:12:28 GMT Received: from acsmt356.oracle.com (acsmt356.oracle.com [141.146.40.156]) by rtcsinet22.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id p88ICPaP019113 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 8 Sep 2011 18:12:26 GMT Received: from abhmt113.oracle.com (abhmt113.oracle.com [141.146.116.65]) by acsmt356.oracle.com (8.12.11.20060308/8.12.11) with ESMTP id p88ICJrQ023387; Thu, 8 Sep 2011 13:12:20 -0500 Received: from phenom (/209.6.55.207) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Thu, 08 Sep 2011 11:12:19 -0700 Received: by phenom (Postfix, from userid 1000) id 490C1FD1; Thu, 8 Sep 2011 14:12:05 -0400 (EDT) Date: Thu, 8 Sep 2011 14:12:05 -0400 From: Konrad Rzeszutek Wilk To: Eric Camachat Subject: Re: [Xen-devel] Can I specify a physical memory region for a domU Message-ID: <20110908181205.GA19078@dumpdata.com> References: <20110908125920.GC28591@dumpdata.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.21 (2010-09-15) X-Source-IP: rtcsinet22.oracle.com [66.248.204.30] X-CT-RefId: str=0001.0A020201.4E69058D.0054,ss=1,re=0.000,fgs=0 Cc: xen-devel@lists.xensource.com X-BeenThere: xen-devel@lists.xensource.com X-Mailman-Version: 2.1.5 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xensource.com Errors-To: xen-devel-bounces@lists.xensource.com On Thu, Sep 08, 2011 at 10:22:01AM -0700, Eric Camachat wrote: > On Thu, Sep 8, 2011 at 5:59 AM, Konrad Rzeszutek Wilk > wrote: > > On Wed, Sep 07, 2011 at 05:47:46PM -0700, Eric Camachat wrote: > >> Hi, > >> > >> I am porting our drivers to XEN's PV domU (with PV PCI passthrouth), I > > > > Use the DMA API that Linux provides (I presume that is what you meant > > by PV DomU), and use the dma_alloc_coherent to set your regions. > > That's what I thought before. We use a shared DMA region for multiple hardware. > Maybe I can dma_alloc_coherent for 1st and the others use the same region. You can definitly try it. Or use the dmapool API to get a shared pool of coherent memory. > I will try it. > > > > > Also pass in 'iommu=soft' on your Linux command line to enable the > > Xen SWIOTLB DMA system. > > > >> have to allocate a memory block and tell the hardware to access it. > >> But the hardware can address 32-bit only, so I want dedicate a region > >> of memory that below 2GB for the domU only. > > > > Uh, don't you mean 4GB? - 32bit is up to 4GB. > > The hardware uses 32-bit addressing, but the system will crash if I > assigned above 2GB address to it. Ha! so buggy hardware.. or you are not using the XEn-SWIOTLB but something else. > So, 4GB from hardware spec, 2GB from my test. I am looking into that. Make sure you set pci_set_consistent_dma_mask(dev, DMA_BIT_MASK(31)); on top of pci_set_dma_mask(dev, DMA_BIT_MASK(31)); in your driver. _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel From xen-devel-bounces@lists.xensource.com Thu Sep 08 11:14:22 2011 Return-path: Envelope-to: www-data@lists.xensource.com Delivery-date: Thu, 08 Sep 2011 11:14:22 -0700 Received: from localhost ([127.0.0.1] helo=lists.colo.xensource.com) by lists.xensource.com with esmtp (Exim 4.43) id 1R1j7G-0004Yn-OI; Thu, 08 Sep 2011 11:14:22 -0700 Received: from mail21.messagelabs.com ([85.158.143.35]) by lists.xensource.com with esmtp (Exim 4.43) id 1R1j5y-00044w-MX for xen-devel@lists.xensource.com; Thu, 08 Sep 2011 11:13:05 -0700 X-Env-Sender: konrad@dumpdata.com X-Msg-Ref: server-11.tower-21.messagelabs.com!1315505562!41871671!1 X-Originating-IP: [141.146.126.227] X-StarScan-Version: 6.3.6; banners=-,-,- X-VirusChecked: Checked Received: (qmail 19144 invoked from network); 8 Sep 2011 18:12:43 -0000 Received: from acsinet15.oracle.com (HELO acsinet15.oracle.com) (141.146.126.227) by server-11.tower-21.messagelabs.com with DHE-RSA-AES256-SHA encrypted SMTP; 8 Sep 2011 18:12:43 -0000 Received: from rtcsinet21.oracle.com (rtcsinet21.oracle.com [66.248.204.29]) by acsinet15.oracle.com (Switch-3.4.4/Switch-3.4.4) with ESMTP id p88ICn69022565 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Thu, 8 Sep 2011 18:12:51 GMT Received: from acsmt358.oracle.com (acsmt358.oracle.com [141.146.40.158]) by rtcsinet21.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id p88IClO7020813 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 8 Sep 2011 18:12:48 GMT Received: from abhmt119.oracle.com (abhmt119.oracle.com [141.146.116.71]) by acsmt358.oracle.com (8.12.11.20060308/8.12.11) with ESMTP id p88ICgIK013564; Thu, 8 Sep 2011 13:12:42 -0500 Received: from phenom (/209.6.55.207) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Thu, 08 Sep 2011 11:12:41 -0700 Received: by phenom (Postfix, from userid 1000) id 859A0FD1; Thu, 8 Sep 2011 14:12:27 -0400 (EDT) Date: Thu, 8 Sep 2011 14:12:27 -0400 From: Konrad Rzeszutek Wilk To: Andreas Olsowski Subject: Re: [Xen-devel] xen/stable-2.6.32.x xen-4.1.1 live migration fails with kernels 2.6.39, 3.0.3 and 3.1-rc2 Message-ID: <20110908181227.GB19078@dumpdata.com> References: <4E52224902000078000525CC@nat28.tlf.novell.com> <4E52601B.5060609@leuphana.de> <20110824203435.GA27865@dumpdata.com> <4E55F682.8060405@leuphana.de> <20110826150054.GA1793@dumpdata.com> <4E57D745.2080701@leuphana.de> <20110829194911.GC16530@dumpdata.com> <4E5E320A.60401@leuphana.de> <20110907135046.GD32190@dumpdata.com> <20110908173212.GA17026@dumpdata.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20110908173212.GA17026@dumpdata.com> User-Agent: Mutt/1.5.21 (2010-09-15) X-Source-IP: rtcsinet21.oracle.com [66.248.204.29] X-CT-RefId: str=0001.0A020209.4E6905A3.00E7,ss=1,re=0.000,fgs=0 Cc: "xen-devel@lists.xensource.com" X-BeenThere: xen-devel@lists.xensource.com X-Mailman-Version: 2.1.5 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xensource.com Errors-To: xen-devel-bounces@lists.xensource.com On Thu, Sep 08, 2011 at 01:32:12PM -0400, Konrad Rzeszutek Wilk wrote: > On Wed, Sep 07, 2011 at 09:50:47AM -0400, Konrad Rzeszutek Wilk wrote: > > On Wed, Aug 31, 2011 at 03:07:22PM +0200, Andreas Olsowski wrote: > > > A little update, i now have all machines running on xen-4.1-testing > > > with xen/stable-2.6.32.x > > > That gave me the possiblity for additional tests. > > > > > > (I also tested xm/xend in addtion to xl/libxl, to make sure its not > > > a xl/libxl problem.) > > > > > > I took the liberty to create a new test result matrix that should > > > provide a better overview (in case someone else wants to get the > > > whole picture): > > > > So.. I don't think the issue I am seeing is exactly the same. This is > > what 'xl' gives me: > > Scratch that. I am seeing the error below if I: > > 1) Create guest on 4GB machine > 2) Migrate it to the 32GB box (guest still works) > 3) Migrate it to the 4GB box (guest dies - error below shows up and > guest is dead). > > With 3.1-rc5 virgin - both Dom0 and DomU. Also Xen 4.1-testing on top of this. > > I tried just creating a guest on the 32GB and migrating it - and while > it did migrate it was stuck in a hypercall_page call or crashed later on. > > Andreas, > > Thanks for reporting this. Oh wait. At some point you said that 2.6.32.43 worked for you.. Is that still the case? _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel From xen-devel-bounces@lists.xensource.com Thu Sep 08 11:17:12 2011 Return-path: Envelope-to: www-data@lists.xensource.com Delivery-date: Thu, 08 Sep 2011 11:17:12 -0700 Received: from localhost ([127.0.0.1] helo=lists.colo.xensource.com) by lists.xensource.com with esmtp (Exim 4.43) id 1R1jA0-0004xf-BX; Thu, 08 Sep 2011 11:17:12 -0700 Received: from mail216.messagelabs.com ([85.158.143.99]) by lists.xensource.com with esmtp (Exim 4.43) id 1R1j9U-0004l3-Va for xen-devel@lists.xensource.com; Thu, 08 Sep 2011 11:16:41 -0700 X-Env-Sender: konrad@dumpdata.com X-Msg-Ref: server-8.tower-216.messagelabs.com!1315505796!16085758!1 X-Originating-IP: [148.87.113.117] X-StarScan-Version: 6.3.6; banners=-,-,- X-VirusChecked: Checked Received: (qmail 1791 invoked from network); 8 Sep 2011 18:16:37 -0000 Received: from rcsinet15.oracle.com (HELO rcsinet15.oracle.com) (148.87.113.117) by server-8.tower-216.messagelabs.com with DHE-RSA-AES256-SHA encrypted SMTP; 8 Sep 2011 18:16:37 -0000 Received: from acsinet22.oracle.com (acsinet22.oracle.com [141.146.126.238]) by rcsinet15.oracle.com (Switch-3.4.4/Switch-3.4.4) with ESMTP id p88IGUMX009326 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Thu, 8 Sep 2011 18:16:32 GMT Received: from acsmt357.oracle.com (acsmt357.oracle.com [141.146.40.157]) by acsinet22.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id p88IGTPt025872 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 8 Sep 2011 18:16:30 GMT Received: from abhmt107.oracle.com (abhmt107.oracle.com [141.146.116.59]) by acsmt357.oracle.com (8.12.11.20060308/8.12.11) with ESMTP id p88IGOx5012900; Thu, 8 Sep 2011 13:16:24 -0500 Received: from phenom (/209.6.55.207) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Thu, 08 Sep 2011 11:16:24 -0700 Received: by phenom (Postfix, from userid 1000) id A3E01FD1; Thu, 8 Sep 2011 14:16:09 -0400 (EDT) Date: Thu, 8 Sep 2011 14:16:09 -0400 From: Konrad Rzeszutek Wilk To: Maxim Kozhevnikov Subject: Re: [Xen-devel] Whether xen will support intel atom cpu Message-ID: <20110908181609.GC19078@dumpdata.com> References: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.21 (2010-09-15) X-Source-IP: acsinet22.oracle.com [141.146.126.238] X-Auth-Type: Internal IP X-CT-RefId: str=0001.0A090204.4E690680.00E6:SCFMA922111,ss=1,re=-4.000,fgs=0 Cc: xen-devel@lists.xensource.com X-BeenThere: xen-devel@lists.xensource.com X-Mailman-Version: 2.1.5 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xensource.com Errors-To: xen-devel-bounces@lists.xensource.com On Thu, Sep 08, 2011 at 09:59:57PM +0400, Maxim Kozhevnikov wrote: > I have pc with intel atom cpu. > And When use xen i got the following error: > "Performance Events : unsupported p6 CPU model 28 no PMU driver, software events only." > So, i can use suspend to ram but can't use wake up from ram on my pc. What are you using as Dom0? The ACPI suspend code has just been posted (http://www.gossamer-threads.com/lists/xen/devel/216684?do=post_view_threaded) so it is _not_ upstream yet. But if you want to try it out, I would suggest you try: http://oss.oracle.com/git/?p=kwilk/xen.git;a=shortlog;h=testing or git://oss.oracle.com/git/kwilk/xen.git testing which has the patches for that in it. > Please, tell me, when xen will support intel atom cpu? It works fine for me. > I use xen-unstable (4.2) _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel From xen-devel-bounces@lists.xensource.com Thu Sep 08 11:24:37 2011 Return-path: Envelope-to: www-data@lists.xensource.com Delivery-date: Thu, 08 Sep 2011 11:24:37 -0700 Received: from localhost ([127.0.0.1] helo=lists.colo.xensource.com) by lists.xensource.com with esmtp (Exim 4.43) id 1R1jHA-0005QZ-W3; Thu, 08 Sep 2011 11:24:37 -0700 Received: from mail182.messagelabs.com ([85.158.139.83]) by lists.xensource.com with smtp (Exim 4.43) id 1R1jGc-0005EC-1H for xen-devel@lists.xensource.com; Thu, 08 Sep 2011 11:24:03 -0700 X-Env-Sender: Stefano.Stabellini@eu.citrix.com X-Msg-Ref: server-15.tower-182.messagelabs.com!1315506239!16603691!1 X-Originating-IP: [62.200.22.115] X-StarScan-Version: 6.3.6; banners=-,-,- X-VirusChecked: Checked Received: (qmail 13730 invoked from network); 8 Sep 2011 18:23:59 -0000 Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115) by server-15.tower-182.messagelabs.com with SMTP; 8 Sep 2011 18:23:59 -0000 X-IronPort-AV: E=Sophos;i="4.68,351,1312156800"; d="scan'208";a="7684205" Received: from lonpmailmx01.citrite.net ([10.30.203.162]) by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5; 08 Sep 2011 18:23:58 +0000 Received: from kaball.uk.xensource.com (10.80.2.59) by LONPMAILMX01.citrite.net (10.30.203.162) with Microsoft SMTP Server id 8.3.137.0; Thu, 8 Sep 2011 19:23:58 +0100 Date: Thu, 8 Sep 2011 19:32:09 +0100 From: Stefano Stabellini X-X-Sender: sstabellini@kaball-desktop To: Konrad Rzeszutek Wilk Message-ID: User-Agent: Alpine 2.00 (DEB 1167 2008-08-23) MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Cc: Ian Campbell , Jeremy Fitzhardinge , "xen-devel@lists.xensource.com" , "linux-kernel@vger.kernel.org" , Stefano Stabellini Subject: [Xen-devel] [PATCH v4 0/2] xen: modify kernel mappings corresponding to granted pages X-BeenThere: xen-devel@lists.xensource.com X-Mailman-Version: 2.1.5 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xensource.com Errors-To: xen-devel-bounces@lists.xensource.com Hi all, this is the forth version of the patch "xen: modify kernel mappings corresponding to granted pages": changes to v3: - move the xen_mc_entry call in m2p_remove_override after the xen_mc_flush call; - use false rather than 0 as a parameter to alloc_xenballooned_pages; - update the m2p_add_override call in blkback.c, following the new interface; - fix few code style issues. Changes to v2: - drop highmem support; - fold the multicall patch into the main patch; - add another patch to extend the alloc_xenballooned_pages interface with an highmem parameter that allows the caller to explicitly request for highmem or lowmem pages; - modify gntdev to use lowmem pages only thanks to the new alloc_xenballooned_pages interface. Shortlog and diffstat follow: Stefano Stabellini (2): xen: add an "highmem" parameter to alloc_xenballooned_pages xen: modify kernel mappings corresponding to granted pages arch/x86/include/asm/xen/page.h | 5 ++- arch/x86/xen/p2m.c | 68 +++++++++++++++++++++++++++++------ drivers/block/xen-blkback/blkback.c | 2 +- drivers/xen/balloon.c | 12 ++++-- drivers/xen/gntdev.c | 29 ++++++++++++++- drivers/xen/grant-table.c | 6 ++-- include/xen/balloon.h | 3 +- include/xen/grant_table.h | 1 + 8 files changed, 103 insertions(+), 23 deletions(-) A git branch with the two patches on top of Linux 3.1 rc4 is available here: git://xenbits.xen.org/people/sstabellini/linux-pvhvm.git 3.1-rc4-kernel_mappings_4 Cheers, Stefano _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel From xen-devel-bounces@lists.xensource.com Thu Sep 08 11:36:43 2011 Return-path: Envelope-to: www-data@lists.xensource.com Delivery-date: Thu, 08 Sep 2011 11:36:43 -0700 Received: from localhost ([127.0.0.1] helo=lists.colo.xensource.com) by lists.xensource.com with esmtp (Exim 4.43) id 1R1jSt-0007OY-Ge; Thu, 08 Sep 2011 11:36:43 -0700 Received: from mail174.messagelabs.com ([85.158.138.51]) by lists.xensource.com with smtp (Exim 4.43) id 1R1jRV-0006l1-Jn for xen-devel@lists.xensource.com; Thu, 08 Sep 2011 11:35:18 -0700 X-Env-Sender: Ian.Jackson@eu.citrix.com X-Msg-Ref: server-11.tower-174.messagelabs.com!1315506914!30749376!1 X-Originating-IP: [62.200.22.115] X-StarScan-Version: 6.3.6; banners=-,-,- X-VirusChecked: Checked Received: (qmail 14481 invoked from network); 8 Sep 2011 18:35:14 -0000 Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115) by server-11.tower-174.messagelabs.com with SMTP; 8 Sep 2011 18:35:14 -0000 X-IronPort-AV: E=Sophos;i="4.68,351,1312156800"; d="scan'208";a="7684292" Received: from lonpmailmx01.citrite.net ([10.30.203.162]) by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5; 08 Sep 2011 18:35:14 +0000 Received: from woking.xci-test.com (10.80.248.135) by smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id 8.3.137.0; Thu, 8 Sep 2011 19:35:14 +0100 Received: from osstest by woking.xci-test.com with local (Exim 4.69) (envelope-from ) id 1R1jRR-0005w1-OX; Thu, 08 Sep 2011 19:35:13 +0100 To: xen-devel@lists.xensource.com Message-ID: From: xen.org Date: Thu, 8 Sep 2011 19:35:13 +0100 MIME-Version: 1.0 Content-Type: text/plain Cc: ian.jackson@eu.citrix.com Subject: [Xen-devel] [xen-4.0-testing test] 8866: tolerable FAIL - PUSHED X-BeenThere: xen-devel@lists.xensource.com X-Mailman-Version: 2.1.5 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xensource.com Errors-To: xen-devel-bounces@lists.xensource.com flight 8866 xen-4.0-testing real [real] http://www.chiark.greenend.org.uk/~xensrcts/logs/8866/ Failures :-/ but no regressions. Tests which did not succeed, but are not blocking, including regressions (tests previously passed) regarded as allowable: test-amd64-amd64-xl-pcipt-intel 1 xen-build-check(1) blocked n/a test-amd64-amd64-xl 1 xen-build-check(1) blocked n/a test-amd64-i386-xl-multivcpu 1 xen-build-check(1) blocked n/a test-amd64-i386-pv 1 xen-build-check(1) blocked n/a test-i386-i386-pv 1 xen-build-check(1) blocked n/a test-i386-i386-xl 1 xen-build-check(1) blocked n/a test-amd64-amd64-pv 1 xen-build-check(1) blocked n/a build-i386-pvops 4 kernel-build fail like 8844 test-amd64-i386-xl 1 xen-build-check(1) blocked n/a test-amd64-i386-pair 1 xen-build-check(1) blocked n/a test-amd64-i386-xl-credit2 1 xen-build-check(1) blocked n/a test-amd64-amd64-xl-sedf 1 xen-build-check(1) blocked n/a test-amd64-amd64-pair 1 xen-build-check(1) blocked n/a test-i386-i386-pair 1 xen-build-check(1) blocked n/a test-i386-i386-win 1 xen-build-check(1) blocked n/a test-amd64-i386-rhel6hvm-intel 1 xen-build-check(1) blocked n/a test-amd64-i386-rhel6hvm-amd 1 xen-build-check(1) blocked n/a test-amd64-i386-win-vcpus1 1 xen-build-check(1) blocked n/a test-amd64-amd64-win 1 xen-build-check(1) blocked n/a build-amd64-pvops 4 kernel-build fail like 8844 test-amd64-i386-win 1 xen-build-check(1) blocked n/a test-amd64-amd64-xl-win 1 xen-build-check(1) blocked n/a test-amd64-i386-xl-win-vcpus1 1 xen-build-check(1) blocked n/a test-i386-i386-xl-win 1 xen-build-check(1) blocked n/a version targeted for testing: xen 789ff1a462b8 baseline version: xen b44346a6975c ------------------------------------------------------------ People who touched revisions under test: Allen M Kay Tim Deegan Wei Wang2 ------------------------------------------------------------ jobs: build-amd64 pass build-i386 pass build-amd64-oldkern pass build-i386-oldkern pass build-amd64-pvops fail build-i386-pvops fail test-amd64-amd64-xl blocked test-amd64-i386-xl blocked test-i386-i386-xl blocked test-amd64-i386-rhel6hvm-amd blocked test-amd64-i386-xl-credit2 blocked test-amd64-amd64-xl-pcipt-intel blocked test-amd64-i386-rhel6hvm-intel blocked test-amd64-i386-xl-multivcpu blocked test-amd64-amd64-pair blocked test-amd64-i386-pair blocked test-i386-i386-pair blocked test-amd64-amd64-pv blocked test-amd64-i386-pv blocked test-i386-i386-pv blocked test-amd64-amd64-xl-sedf blocked test-amd64-i386-win-vcpus1 blocked test-amd64-i386-xl-win-vcpus1 blocked test-amd64-amd64-win blocked test-amd64-i386-win blocked test-i386-i386-win blocked test-amd64-amd64-xl-win blocked test-i386-i386-xl-win blocked ------------------------------------------------------------ sg-report-flight on woking.cam.xci-test.com logs: /home/xc_osstest/logs images: /home/xc_osstest/images Logs, config files, etc. are available at http://www.chiark.greenend.org.uk/~xensrcts/logs Test harness code can be found at http://xenbits.xensource.com/gitweb?p=osstest.git;a=summary Pushing revision : + branch=xen-4.0-testing + revision=789ff1a462b8 + . cri-lock-repos ++ . cri-common +++ umask 002 +++ getconfig Repos +++ perl -e ' use Osstest; readconfigonly(); print $c{Repos} or die $!; ' ++ repos=/export/home/osstest/repos ++ repos_lock=/export/home/osstest/repos/lock ++ '[' x '!=' x/export/home/osstest/repos/lock ']' ++ OSSTEST_REPOS_LOCK_LOCKED=/export/home/osstest/repos/lock ++ exec with-lock-ex -w /export/home/osstest/repos/lock ./ap-push xen-4.0-testing 789ff1a462b8 + branch=xen-4.0-testing + revision=789ff1a462b8 + . cri-lock-repos ++ . cri-common +++ umask 002 +++ getconfig Repos +++ perl -e ' use Osstest; readconfigonly(); print $c{Repos} or die $!; ' ++ repos=/export/home/osstest/repos ++ repos_lock=/export/home/osstest/repos/lock ++ '[' x/export/home/osstest/repos/lock '!=' x/export/home/osstest/repos/lock ']' + : xen@xenbits.xensource.com + : xen@xenbits.xensource.com:git/linux-pvops + : master + : tested/2.6.39.x + case "$branch" in + cd /export/home/osstest/repos/xen-4.0-testing.hg + hg push -r 789ff1a462b8 ssh://xen@xenbits.xensource.com/HG/xen-4.0-testing.hg pushing to ssh://xen@xenbits.xensource.com/HG/xen-4.0-testing.hg searching for changes remote: adding changesets remote: adding manifests remote: adding file changes remote: added 2 changesets with 3 changes to 3 files _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel From xen-devel-bounces@lists.xensource.com Thu Sep 08 11:37:41 2011 Return-path: Envelope-to: www-data@lists.xensource.com Delivery-date: Thu, 08 Sep 2011 11:37:41 -0700 Received: from localhost ([127.0.0.1] helo=lists.colo.xensource.com) by lists.xensource.com with esmtp (Exim 4.43) id 1R1jTp-0007qs-Ie; Thu, 08 Sep 2011 11:37:41 -0700 Received: from mail21.messagelabs.com ([85.158.143.35]) by lists.xensource.com with smtp (Exim 4.43) id 1R1jT9-0007VY-Nf for xen-devel@lists.xensource.com; Thu, 08 Sep 2011 11:37:00 -0700 X-Env-Sender: Stefano.Stabellini@eu.citrix.com X-Msg-Ref: server-15.tower-21.messagelabs.com!1315507017!49871505!1 X-Originating-IP: [62.200.22.115] X-StarScan-Version: 6.3.6; banners=-,-,- X-VirusChecked: Checked Received: (qmail 15013 invoked from network); 8 Sep 2011 18:36:57 -0000 Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115) by server-15.tower-21.messagelabs.com with SMTP; 8 Sep 2011 18:36:57 -0000 X-IronPort-AV: E=Sophos;i="4.68,351,1312156800"; d="scan'208";a="7684322" Received: from lonpmailmx01.citrite.net ([10.30.203.162]) by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5; 08 Sep 2011 18:36:56 +0000 Received: from kaball.uk.xensource.com (10.80.2.59) by LONPMAILMX01.citrite.net (10.30.203.162) with Microsoft SMTP Server id 8.3.137.0; Thu, 8 Sep 2011 19:36:56 +0100 Date: Thu, 8 Sep 2011 19:45:08 +0100 From: Stefano Stabellini X-X-Sender: sstabellini@kaball-desktop To: Konrad Rzeszutek Wilk Message-ID: User-Agent: Alpine 2.00 (DEB 1167 2008-08-23) MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Cc: Jeremy Fitzhardinge , xen-devel@lists.xensource.com, linux-kernel@vger.kernel.org, Stefano Stabellini Subject: [Xen-devel] [PATCH v4 1/2] xen: add an "highmem" parameter to alloc_xenballooned_pages X-BeenThere: xen-devel@lists.xensource.com X-Mailman-Version: 2.1.5 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xensource.com Errors-To: xen-devel-bounces@lists.xensource.com Add an highmem parameter to alloc_xenballooned_pages, to allow callers to request lowmem or highmem pages. Signed-off-by: Stefano Stabellini --- drivers/xen/balloon.c | 12 ++++++++---- drivers/xen/gntdev.c | 2 +- include/xen/balloon.h | 3 ++- 3 files changed, 11 insertions(+), 6 deletions(-) diff --git a/drivers/xen/balloon.c b/drivers/xen/balloon.c index 5dfd8f8..7f7d463 100644 --- a/drivers/xen/balloon.c +++ b/drivers/xen/balloon.c @@ -501,20 +501,24 @@ EXPORT_SYMBOL_GPL(balloon_set_new_target); * alloc_xenballooned_pages - get pages that have been ballooned out * @nr_pages: Number of pages to get * @pages: pages returned + * @highmem: highmem or lowmem pages * @return 0 on success, error otherwise */ -int alloc_xenballooned_pages(int nr_pages, struct page** pages) +int alloc_xenballooned_pages(int nr_pages, struct page** pages, bool highmem) { int pgno = 0; struct page* page; mutex_lock(&balloon_mutex); while (pgno < nr_pages) { - page = balloon_retrieve(true); - if (page) { + page = balloon_retrieve(highmem); + if (page && PageHighMem(page) == highmem) { pages[pgno++] = page; } else { enum bp_state st; - st = decrease_reservation(nr_pages - pgno, GFP_HIGHUSER); + if (page) + balloon_append(page); + st = decrease_reservation(nr_pages - pgno, + highmem ? GFP_HIGHUSER : GFP_USER); if (st != BP_DONE) goto out_undo; } diff --git a/drivers/xen/gntdev.c b/drivers/xen/gntdev.c index f914b26..7b9b1d1 100644 --- a/drivers/xen/gntdev.c +++ b/drivers/xen/gntdev.c @@ -123,7 +123,7 @@ static struct grant_map *gntdev_alloc_map(struct gntdev_priv *priv, int count) NULL == add->pages) goto err; - if (alloc_xenballooned_pages(count, add->pages)) + if (alloc_xenballooned_pages(count, add->pages, false /* lowmem */)) goto err; for (i = 0; i < count; i++) { diff --git a/include/xen/balloon.h b/include/xen/balloon.h index 76f7538..b1a8233 100644 --- a/include/xen/balloon.h +++ b/include/xen/balloon.h @@ -25,7 +25,8 @@ extern struct balloon_stats balloon_stats; void balloon_set_new_target(unsigned long target); -int alloc_xenballooned_pages(int nr_pages, struct page** pages); +int alloc_xenballooned_pages(int nr_pages, struct page** pages, + bool highmem); void free_xenballooned_pages(int nr_pages, struct page** pages); struct sys_device; -- 1.7.2.3 _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel From xen-devel-bounces@lists.xensource.com Thu Sep 08 11:38:29 2011 Return-path: Envelope-to: www-data@lists.xensource.com Delivery-date: Thu, 08 Sep 2011 11:38:29 -0700 Received: from localhost ([127.0.0.1] helo=lists.colo.xensource.com) by lists.xensource.com with esmtp (Exim 4.43) id 1R1jUb-0008HI-MD; Thu, 08 Sep 2011 11:38:29 -0700 Received: from mail216.messagelabs.com ([85.158.143.99]) by lists.xensource.com with smtp (Exim 4.43) id 1R1jTV-0007fs-IP for xen-devel@lists.xensource.com; Thu, 08 Sep 2011 11:37:22 -0700 X-Env-Sender: Stefano.Stabellini@eu.citrix.com X-Msg-Ref: server-5.tower-216.messagelabs.com!1315507038!17094589!1 X-Originating-IP: [62.200.22.115] X-StarScan-Version: 6.3.6; banners=-,-,- X-VirusChecked: Checked Received: (qmail 32271 invoked from network); 8 Sep 2011 18:37:18 -0000 Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115) by server-5.tower-216.messagelabs.com with SMTP; 8 Sep 2011 18:37:18 -0000 X-IronPort-AV: E=Sophos;i="4.68,351,1312156800"; d="scan'208";a="7684330" Received: from lonpmailmx01.citrite.net ([10.30.203.162]) by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5; 08 Sep 2011 18:37:17 +0000 Received: from kaball.uk.xensource.com (10.80.2.59) by LONPMAILMX01.citrite.net (10.30.203.162) with Microsoft SMTP Server id 8.3.137.0; Thu, 8 Sep 2011 19:37:17 +0100 Date: Thu, 8 Sep 2011 19:45:29 +0100 From: Stefano Stabellini X-X-Sender: sstabellini@kaball-desktop To: Konrad Rzeszutek Wilk Message-ID: User-Agent: Alpine 2.00 (DEB 1167 2008-08-23) MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Cc: Jeremy Fitzhardinge , xen-devel@lists.xensource.com, linux-kernel@vger.kernel.org, Stefano Stabellini Subject: [Xen-devel] [PATCH v4 2/2] xen: modify kernel mappings corresponding to granted pages X-BeenThere: xen-devel@lists.xensource.com X-Mailman-Version: 2.1.5 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xensource.com Errors-To: xen-devel-bounces@lists.xensource.com If we want to use granted pages for AIO, changing the mappings of a user vma and the corresponding p2m is not enough, we also need to update the kernel mappings accordingly. In order to avoid the complexity of dealing with highmem, we allocated the pages lowmem. We issue a HYPERVISOR_grant_table_op right away in m2p_add_override and we remove the mappings using another HYPERVISOR_grant_table_op in m2p_remove_override. Considering that m2p_add_override and m2p_remove_override are called once per page we use multicalls and hypercall batching. Use the kmap_op pointer directly as argument to do the mapping as it is guaranteed to be present up until the unmapping is done. Before issuing any unmapping multicalls, we need to make sure that the mapping has already being done, because we need the kmap->handle to be set correctly. Signed-off-by: Stefano Stabellini --- arch/x86/include/asm/xen/page.h | 5 ++- arch/x86/xen/p2m.c | 68 +++++++++++++++++++++++++++++------ drivers/block/xen-blkback/blkback.c | 2 +- drivers/xen/gntdev.c | 27 +++++++++++++- drivers/xen/grant-table.c | 6 ++-- include/xen/grant_table.h | 1 + 6 files changed, 92 insertions(+), 17 deletions(-) diff --git a/arch/x86/include/asm/xen/page.h b/arch/x86/include/asm/xen/page.h index 7ff4669..0ce1884 100644 --- a/arch/x86/include/asm/xen/page.h +++ b/arch/x86/include/asm/xen/page.h @@ -12,6 +12,7 @@ #include #include +#include #include /* Xen machine address */ @@ -31,8 +32,10 @@ typedef struct xpaddr { #define INVALID_P2M_ENTRY (~0UL) #define FOREIGN_FRAME_BIT (1UL<<(BITS_PER_LONG-1)) #define IDENTITY_FRAME_BIT (1UL<<(BITS_PER_LONG-2)) +#define GRANT_FRAME_BIT (1UL<<(BITS_PER_LONG-3)) #define FOREIGN_FRAME(m) ((m) | FOREIGN_FRAME_BIT) #define IDENTITY_FRAME(m) ((m) | IDENTITY_FRAME_BIT) +#define GRANT_FRAME(m) ((m) | GRANT_FRAME_BIT) /* Maximum amount of memory we can handle in a domain in pages */ #define MAX_DOMAIN_PAGES \ @@ -48,7 +51,7 @@ extern unsigned long set_phys_range_identity(unsigned long pfn_s, unsigned long pfn_e); extern int m2p_add_override(unsigned long mfn, struct page *page, - bool clear_pte); + struct gnttab_map_grant_ref *kmap_op); extern int m2p_remove_override(struct page *page, bool clear_pte); extern struct page *m2p_find_override(unsigned long mfn); extern unsigned long m2p_find_override_pfn(unsigned long mfn, unsigned long pfn); diff --git a/arch/x86/xen/p2m.c b/arch/x86/xen/p2m.c index 58efeb9..23f8465 100644 --- a/arch/x86/xen/p2m.c +++ b/arch/x86/xen/p2m.c @@ -161,7 +161,9 @@ #include #include #include +#include +#include "multicalls.h" #include "xen-ops.h" static void __init m2p_override_init(void); @@ -676,7 +678,8 @@ static unsigned long mfn_hash(unsigned long mfn) } /* Add an MFN override for a particular page */ -int m2p_add_override(unsigned long mfn, struct page *page, bool clear_pte) +int m2p_add_override(unsigned long mfn, struct page *page, + struct gnttab_map_grant_ref *kmap_op) { unsigned long flags; unsigned long pfn; @@ -699,9 +702,20 @@ int m2p_add_override(unsigned long mfn, struct page *page, bool clear_pte) if (unlikely(!set_phys_to_machine(pfn, FOREIGN_FRAME(mfn)))) return -ENOMEM; - if (clear_pte && !PageHighMem(page)) - /* Just zap old mapping for now */ - pte_clear(&init_mm, address, ptep); + if (kmap_op != NULL) { + if (!PageHighMem(page)) { + struct multicall_space mcs = xen_mc_entry(sizeof(*kmap_op)); + + MULTI_grant_table_op(mcs.mc, + GNTTABOP_map_grant_ref, kmap_op, 1); + + xen_mc_issue(PARAVIRT_LAZY_MMU); + } + page->private |= GRANT_FRAME_BIT; + /* let's use dev_bus_addr to record the old mfn instead */ + kmap_op->dev_bus_addr = page->index; + page->index = (unsigned long) kmap_op; + } spin_lock_irqsave(&m2p_override_lock, flags); list_add(&page->lru, &m2p_overrides[mfn_hash(mfn)]); spin_unlock_irqrestore(&m2p_override_lock, flags); @@ -735,13 +749,45 @@ int m2p_remove_override(struct page *page, bool clear_pte) spin_lock_irqsave(&m2p_override_lock, flags); list_del(&page->lru); spin_unlock_irqrestore(&m2p_override_lock, flags); - set_phys_to_machine(pfn, page->index); - if (clear_pte && !PageHighMem(page)) - set_pte_at(&init_mm, address, ptep, - pfn_pte(pfn, PAGE_KERNEL)); - /* No tlb flush necessary because the caller already - * left the pte unmapped. */ + if (clear_pte) { + struct gnttab_map_grant_ref *map_op = + (struct gnttab_map_grant_ref *) page->index; + set_phys_to_machine(pfn, map_op->dev_bus_addr); + if (!PageHighMem(page)) { + struct multicall_space mcs; + struct gnttab_unmap_grant_ref *unmap_op; + + /* + * Has the grant_op mapping multicall being issued? If not, + * make sure it is called now. + */ + if (map_op->handle == -1) + xen_mc_flush(); + if (map_op->handle == -1) { + printk(KERN_WARNING "m2p_remove_override: pfn %lx mfn %lx, " + "failed to modify kernel mappings", pfn, mfn); + return -1; + } + + mcs = xen_mc_entry(sizeof(struct gnttab_unmap_grant_ref)); + unmap_op = mcs.args; + unmap_op->host_addr = map_op->host_addr; + unmap_op->handle = map_op->handle; + unmap_op->dev_bus_addr = 0; + + MULTI_grant_table_op(mcs.mc, + GNTTABOP_unmap_grant_ref, unmap_op, 1); + + xen_mc_issue(PARAVIRT_LAZY_MMU); + + set_pte_at(&init_mm, address, ptep, + pfn_pte(pfn, PAGE_KERNEL)); + __flush_tlb_single(address); + map_op->host_addr = 0; + } + } else + set_phys_to_machine(pfn, page->index); return 0; } @@ -758,7 +804,7 @@ struct page *m2p_find_override(unsigned long mfn) spin_lock_irqsave(&m2p_override_lock, flags); list_for_each_entry(p, bucket, lru) { - if (p->private == mfn) { + if ((p->private & (~GRANT_FRAME_BIT)) == mfn) { ret = p; break; } diff --git a/drivers/block/xen-blkback/blkback.c b/drivers/block/xen-blkback/blkback.c index 2330a9a..1540792 100644 --- a/drivers/block/xen-blkback/blkback.c +++ b/drivers/block/xen-blkback/blkback.c @@ -396,7 +396,7 @@ static int xen_blkbk_map(struct blkif_request *req, continue; ret = m2p_add_override(PFN_DOWN(map[i].dev_bus_addr), - blkbk->pending_page(pending_req, i), false); + blkbk->pending_page(pending_req, i), NULL); if (ret) { pr_alert(DRV_PFX "Failed to install M2P override for %lx (ret: %d)\n", (unsigned long)map[i].dev_bus_addr, ret); diff --git a/drivers/xen/gntdev.c b/drivers/xen/gntdev.c index 7b9b1d1..bfe1271 100644 --- a/drivers/xen/gntdev.c +++ b/drivers/xen/gntdev.c @@ -83,6 +83,7 @@ struct grant_map { struct ioctl_gntdev_grant_ref *grants; struct gnttab_map_grant_ref *map_ops; struct gnttab_unmap_grant_ref *unmap_ops; + struct gnttab_map_grant_ref *kmap_ops; struct page **pages; }; @@ -116,10 +117,12 @@ static struct grant_map *gntdev_alloc_map(struct gntdev_priv *priv, int count) add->grants = kzalloc(sizeof(add->grants[0]) * count, GFP_KERNEL); add->map_ops = kzalloc(sizeof(add->map_ops[0]) * count, GFP_KERNEL); add->unmap_ops = kzalloc(sizeof(add->unmap_ops[0]) * count, GFP_KERNEL); + add->kmap_ops = kzalloc(sizeof(add->kmap_ops[0]) * count, GFP_KERNEL); add->pages = kzalloc(sizeof(add->pages[0]) * count, GFP_KERNEL); if (NULL == add->grants || NULL == add->map_ops || NULL == add->unmap_ops || + NULL == add->kmap_ops || NULL == add->pages) goto err; @@ -129,6 +132,7 @@ static struct grant_map *gntdev_alloc_map(struct gntdev_priv *priv, int count) for (i = 0; i < count; i++) { add->map_ops[i].handle = -1; add->unmap_ops[i].handle = -1; + add->kmap_ops[i].handle = -1; } add->index = 0; @@ -142,6 +146,7 @@ err: kfree(add->grants); kfree(add->map_ops); kfree(add->unmap_ops); + kfree(add->kmap_ops); kfree(add); return NULL; } @@ -243,10 +248,30 @@ static int map_grant_pages(struct grant_map *map) gnttab_set_unmap_op(&map->unmap_ops[i], addr, map->flags, -1 /* handle */); } + } else { + for (i = 0; i < map->count; i++) { + unsigned level; + unsigned long address = (unsigned long) + pfn_to_kaddr(page_to_pfn(map->pages[i])); + pte_t *ptep; + u64 pte_maddr = 0; + if (!PageHighMem(map->pages[i])) { + ptep = lookup_address(address, &level); + pte_maddr = + arbitrary_virt_to_machine(ptep).maddr; + } + gnttab_set_map_op(&map->kmap_ops[i], pte_maddr, + map->flags | + GNTMAP_host_map | + GNTMAP_contains_pte, + map->grants[i].ref, + map->grants[i].domid); + } } pr_debug("map %d+%d\n", map->index, map->count); - err = gnttab_map_refs(map->map_ops, map->pages, map->count); + err = gnttab_map_refs(map->map_ops, use_ptemod ? map->kmap_ops : NULL, + map->pages, map->count); if (err) return err; diff --git a/drivers/xen/grant-table.c b/drivers/xen/grant-table.c index 4f44b34..8c71ab8 100644 --- a/drivers/xen/grant-table.c +++ b/drivers/xen/grant-table.c @@ -448,7 +448,8 @@ unsigned int gnttab_max_grant_frames(void) EXPORT_SYMBOL_GPL(gnttab_max_grant_frames); int gnttab_map_refs(struct gnttab_map_grant_ref *map_ops, - struct page **pages, unsigned int count) + struct gnttab_map_grant_ref *kmap_ops, + struct page **pages, unsigned int count) { int i, ret; pte_t *pte; @@ -488,8 +489,7 @@ int gnttab_map_refs(struct gnttab_map_grant_ref *map_ops, */ return -EOPNOTSUPP; } - ret = m2p_add_override(mfn, pages[i], - map_ops[i].flags & GNTMAP_contains_pte); + ret = m2p_add_override(mfn, pages[i], &kmap_ops[i]); if (ret) return ret; } diff --git a/include/xen/grant_table.h b/include/xen/grant_table.h index b1fab6b..6b99bfb 100644 --- a/include/xen/grant_table.h +++ b/include/xen/grant_table.h @@ -156,6 +156,7 @@ unsigned int gnttab_max_grant_frames(void); #define gnttab_map_vaddr(map) ((void *)(map.host_virt_addr)) int gnttab_map_refs(struct gnttab_map_grant_ref *map_ops, + struct gnttab_map_grant_ref *kmap_ops, struct page **pages, unsigned int count); int gnttab_unmap_refs(struct gnttab_unmap_grant_ref *unmap_ops, struct page **pages, unsigned int count); -- 1.7.2.3 _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel From xen-devel-bounces@lists.xensource.com Thu Sep 08 11:40:07 2011 Return-path: Envelope-to: www-data@lists.xensource.com Delivery-date: Thu, 08 Sep 2011 11:40:07 -0700 Received: from localhost ([127.0.0.1] helo=lists.colo.xensource.com) by lists.xensource.com with esmtp (Exim 4.43) id 1R1jWB-0000Gn-MA; Thu, 08 Sep 2011 11:40:07 -0700 Received: from mail216.messagelabs.com ([85.158.143.99]) by lists.xensource.com with smtp (Exim 4.43) id 1R1jVk-0008Vq-B3 for xen-devel@lists.xensource.com; Thu, 08 Sep 2011 11:39:40 -0700 X-Env-Sender: Stefano.Stabellini@eu.citrix.com X-Msg-Ref: server-3.tower-216.messagelabs.com!1315507177!16549683!1 X-Originating-IP: [62.200.22.115] X-StarScan-Version: 6.3.6; banners=-,-,- X-VirusChecked: Checked Received: (qmail 16687 invoked from network); 8 Sep 2011 18:39:37 -0000 Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115) by server-3.tower-216.messagelabs.com with SMTP; 8 Sep 2011 18:39:37 -0000 X-IronPort-AV: E=Sophos;i="4.68,351,1312156800"; d="scan'208";a="7684378" Received: from lonpmailmx01.citrite.net ([10.30.203.162]) by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5; 08 Sep 2011 18:39:37 +0000 Received: from kaball.uk.xensource.com (10.80.2.59) by LONPMAILMX01.citrite.net (10.30.203.162) with Microsoft SMTP Server id 8.3.137.0; Thu, 8 Sep 2011 19:39:37 +0100 Date: Thu, 8 Sep 2011 19:47:48 +0100 From: Stefano Stabellini X-X-Sender: sstabellini@kaball-desktop To: Stefano Stabellini In-Reply-To: Message-ID: References: User-Agent: Alpine 2.00 (DEB 1167 2008-08-23) MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Cc: Ian Campbell , Jeremy Fitzhardinge , "xen-devel@lists.xensource.com" , "linux-kernel@vger.kernel.org" , Konrad Rzeszutek Wilk Subject: [Xen-devel] Re: [PATCH v4 0/2] xen: modify kernel mappings corresponding to granted pages X-BeenThere: xen-devel@lists.xensource.com X-Mailman-Version: 2.1.5 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xensource.com Errors-To: xen-devel-bounces@lists.xensource.com On Thu, 8 Sep 2011, Stefano Stabellini wrote: > Hi all, > this is the forth version of the patch "xen: modify kernel mappings > corresponding to granted pages": > > changes to v3: > > - move the xen_mc_entry call in m2p_remove_override after the > xen_mc_flush call; > > - use false rather than 0 as a parameter to alloc_xenballooned_pages; > > - update the m2p_add_override call in blkback.c, following the new > interface; > > - fix few code style issues. > Sorry for not having sent the patch with --in-reply-to but I had an issue with my git-send-email setup so I had to send them manually... _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel From xen-devel-bounces@lists.xensource.com Thu Sep 08 11:40:51 2011 Return-path: Envelope-to: www-data@lists.xensource.com Delivery-date: Thu, 08 Sep 2011 11:40:51 -0700 Received: from localhost ([127.0.0.1] helo=lists.colo.xensource.com) by lists.xensource.com with esmtp (Exim 4.43) id 1R1jWs-0000dF-Oq; Thu, 08 Sep 2011 11:40:50 -0700 Received: from mail174.messagelabs.com ([85.158.138.51]) by lists.xensource.com with smtp (Exim 4.43) id 1R1jWO-0000Mi-KZ for xen-devel@lists.xensource.com; Thu, 08 Sep 2011 11:40:21 -0700 X-Env-Sender: Ian.Jackson@eu.citrix.com X-Msg-Ref: server-3.tower-174.messagelabs.com!1315507217!24686279!1 X-Originating-IP: [62.200.22.115] X-StarScan-Version: 6.3.6; banners=-,-,- X-VirusChecked: Checked Received: (qmail 6718 invoked from network); 8 Sep 2011 18:40:17 -0000 Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115) by server-3.tower-174.messagelabs.com with SMTP; 8 Sep 2011 18:40:17 -0000 X-IronPort-AV: E=Sophos;i="4.68,351,1312156800"; d="scan'208";a="7684389" Received: from lonpmailmx01.citrite.net ([10.30.203.162]) by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5; 08 Sep 2011 18:40:17 +0000 Received: from woking.xci-test.com (10.80.248.135) by smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id 8.3.137.0; Thu, 8 Sep 2011 19:40:17 +0100 Received: from osstest by woking.xci-test.com with local (Exim 4.69) (envelope-from ) id 1R1jWL-00081J-6C; Thu, 08 Sep 2011 19:40:17 +0100 To: xen-devel@lists.xensource.com Message-ID: From: xen.org Date: Thu, 8 Sep 2011 19:40:17 +0100 MIME-Version: 1.0 Content-Type: text/plain Cc: ian.jackson@eu.citrix.com Subject: [Xen-devel] [xen-4.1-testing test] 8868: tolerable FAIL - PUSHED X-BeenThere: xen-devel@lists.xensource.com X-Mailman-Version: 2.1.5 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xensource.com Errors-To: xen-devel-bounces@lists.xensource.com flight 8868 xen-4.1-testing real [real] http://www.chiark.greenend.org.uk/~xensrcts/logs/8868/ Failures :-/ but no regressions. Tests which did not succeed, but are not blocking, including regressions (tests previously passed) regarded as allowable: test-amd64-amd64-xl-pcipt-intel 1 xen-build-check(1) blocked n/a test-amd64-amd64-pv 1 xen-build-check(1) blocked n/a build-i386-pvops 4 kernel-build fail like 8845 test-amd64-i386-rhel6hvm-intel 1 xen-build-check(1) blocked n/a test-i386-i386-pv 1 xen-build-check(1) blocked n/a test-amd64-i386-pv 1 xen-build-check(1) blocked n/a test-i386-i386-xl 1 xen-build-check(1) blocked n/a test-amd64-amd64-xl 1 xen-build-check(1) blocked n/a test-amd64-i386-xl-credit2 1 xen-build-check(1) blocked n/a test-amd64-i386-xl 1 xen-build-check(1) blocked n/a test-amd64-i386-xl-multivcpu 1 xen-build-check(1) blocked n/a test-amd64-i386-rhel6hvm-amd 1 xen-build-check(1) blocked n/a build-amd64-pvops 4 kernel-build fail like 8845 test-amd64-amd64-pair 1 xen-build-check(1) blocked n/a test-i386-i386-pair 1 xen-build-check(1) blocked n/a test-amd64-i386-pair 1 xen-build-check(1) blocked n/a test-amd64-amd64-xl-sedf 1 xen-build-check(1) blocked n/a test-amd64-i386-win-vcpus1 1 xen-build-check(1) blocked n/a test-amd64-i386-xl-win-vcpus1 1 xen-build-check(1) blocked n/a test-amd64-i386-win 1 xen-build-check(1) blocked n/a test-amd64-amd64-win 1 xen-build-check(1) blocked n/a test-amd64-amd64-xl-win 1 xen-build-check(1) blocked n/a test-i386-i386-win 1 xen-build-check(1) blocked n/a test-i386-i386-xl-win 1 xen-build-check(1) blocked n/a version targeted for testing: xen 78d8c5227bb1 baseline version: xen 2376070f6685 ------------------------------------------------------------ People who touched revisions under test: ------------------------------------------------------------ jobs: build-amd64 pass build-i386 pass build-amd64-oldkern pass build-i386-oldkern pass build-amd64-pvops fail build-i386-pvops fail test-amd64-amd64-xl blocked test-amd64-i386-xl blocked test-i386-i386-xl blocked test-amd64-i386-rhel6hvm-amd blocked test-amd64-i386-xl-credit2 blocked test-amd64-amd64-xl-pcipt-intel blocked test-amd64-i386-rhel6hvm-intel blocked test-amd64-i386-xl-multivcpu blocked test-amd64-amd64-pair blocked test-amd64-i386-pair blocked test-i386-i386-pair blocked test-amd64-amd64-pv blocked test-amd64-i386-pv blocked test-i386-i386-pv blocked test-amd64-amd64-xl-sedf blocked test-amd64-i386-win-vcpus1 blocked test-amd64-i386-xl-win-vcpus1 blocked test-amd64-amd64-win blocked test-amd64-i386-win blocked test-i386-i386-win blocked test-amd64-amd64-xl-win blocked test-i386-i386-xl-win blocked ------------------------------------------------------------ sg-report-flight on woking.cam.xci-test.com logs: /home/xc_osstest/logs images: /home/xc_osstest/images Logs, config files, etc. are available at http://www.chiark.greenend.org.uk/~xensrcts/logs Test harness code can be found at http://xenbits.xensource.com/gitweb?p=osstest.git;a=summary Pushing revision : + branch=xen-4.1-testing + revision=78d8c5227bb1 + . cri-lock-repos ++ . cri-common +++ umask 002 +++ getconfig Repos +++ perl -e ' use Osstest; readconfigonly(); print $c{Repos} or die $!; ' ++ repos=/export/home/osstest/repos ++ repos_lock=/export/home/osstest/repos/lock ++ '[' x '!=' x/export/home/osstest/repos/lock ']' ++ OSSTEST_REPOS_LOCK_LOCKED=/export/home/osstest/repos/lock ++ exec with-lock-ex -w /export/home/osstest/repos/lock ./ap-push xen-4.1-testing 78d8c5227bb1 + branch=xen-4.1-testing + revision=78d8c5227bb1 + . cri-lock-repos ++ . cri-common +++ umask 002 +++ getconfig Repos +++ perl -e ' use Osstest; readconfigonly(); print $c{Repos} or die $!; ' ++ repos=/export/home/osstest/repos ++ repos_lock=/export/home/osstest/repos/lock ++ '[' x/export/home/osstest/repos/lock '!=' x/export/home/osstest/repos/lock ']' + : xen@xenbits.xensource.com + : xen@xenbits.xensource.com:git/linux-pvops + : master + : tested/2.6.39.x + case "$branch" in + cd /export/home/osstest/repos/xen-4.1-testing.hg + hg push -r 78d8c5227bb1 ssh://xen@xenbits.xensource.com/HG/xen-4.1-testing.hg pushing to ssh://xen@xenbits.xensource.com/HG/xen-4.1-testing.hg searching for changes remote: adding changesets remote: adding manifests remote: adding file changes remote: added 1 changesets with 1 changes to 1 files _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel From xen-devel-bounces@lists.xensource.com Thu Sep 08 11:57:36 2011 Return-path: Envelope-to: www-data@lists.xensource.com Delivery-date: Thu, 08 Sep 2011 11:57:36 -0700 Received: from localhost ([127.0.0.1] helo=lists.colo.xensource.com) by lists.xensource.com with esmtp (Exim 4.43) id 1R1jn5-00028z-Ox; Thu, 08 Sep 2011 11:57:35 -0700 Received: from mail21.messagelabs.com ([85.158.143.35]) by lists.xensource.com with esmtp (Exim 4.43) id 1R1jm3-0001rX-DQ for xen-devel@lists.xensource.com; Thu, 08 Sep 2011 11:56:31 -0700 X-Env-Sender: eric.camachat@gmail.com X-Msg-Ref: server-7.tower-21.messagelabs.com!1315508158!54142294!1 X-Originating-IP: [209.85.218.43] X-StarScan-Version: 6.3.6; banners=-,-,- X-VirusChecked: Checked Received: (qmail 2553 invoked from network); 8 Sep 2011 18:55:59 -0000 Received: from mail-yi0-f43.google.com (HELO mail-yi0-f43.google.com) (209.85.218.43) by server-7.tower-21.messagelabs.com with RC4-SHA encrypted SMTP; 8 Sep 2011 18:55:59 -0000 Received: by yia27 with SMTP id 27so218655yia.30 for ; Thu, 08 Sep 2011 11:56:27 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type:content-transfer-encoding; bh=wY4k3hW55lfnKkg4EMO3c1qKU8VZfJ6C1P4ArvcPskc=; b=rIJro7RYU2bS15iBkEV1DDS8lsWmf3SG3PnBNKRnocdzW/F0rapz8D7pUEnbPIRzsO dTIM3Mb4XYqz7rkCBB8EVZQLb04qOpylNGO7aJNJ8ifU4JR9SCVEU3830LUjS+pK/8Mp +BmlI6qIJzxQxPt5NFSKUUE4l2EnhFsNGixwM= Received: by 10.236.191.74 with SMTP id f50mr6694602yhn.66.1315508187152; Thu, 08 Sep 2011 11:56:27 -0700 (PDT) MIME-Version: 1.0 Received: by 10.236.95.5 with HTTP; Thu, 8 Sep 2011 11:56:07 -0700 (PDT) In-Reply-To: <20110908181205.GA19078@dumpdata.com> References: <20110908125920.GC28591@dumpdata.com> <20110908181205.GA19078@dumpdata.com> From: Eric Camachat Date: Thu, 8 Sep 2011 11:56:07 -0700 Message-ID: Subject: Re: [Xen-devel] Can I specify a physical memory region for a domU To: Konrad Rzeszutek Wilk Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Cc: xen-devel@lists.xensource.com X-BeenThere: xen-devel@lists.xensource.com X-Mailman-Version: 2.1.5 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xensource.com Errors-To: xen-devel-bounces@lists.xensource.com On Thu, Sep 8, 2011 at 11:12 AM, Konrad Rzeszutek Wilk wrote: > On Thu, Sep 08, 2011 at 10:22:01AM -0700, Eric Camachat wrote: >> On Thu, Sep 8, 2011 at 5:59 AM, Konrad Rzeszutek Wilk >> wrote: >> > On Wed, Sep 07, 2011 at 05:47:46PM -0700, Eric Camachat wrote: >> >> Hi, >> >> >> >> I am porting our drivers to XEN's PV domU (with PV PCI passthrouth), = I >> > >> > Use the DMA API that Linux provides (I presume that is what you meant >> > by PV DomU), and use the dma_alloc_coherent to set your regions. >> >> That's what I thought before. We use a shared DMA region for multiple ha= rdware. >> Maybe I can dma_alloc_coherent for 1st and the others use the same regio= n. > > You can definitly try it. Or use the dmapool API to get a shared > pool of coherent memory. > >> I will try it. >> >> > >> > Also pass in 'iommu=3Dsoft' on your Linux command line to enable the >> > Xen SWIOTLB DMA system. >> > >> >> have to allocate a memory block and tell the hardware to access it. >> >> But the hardware can address 32-bit only, so I want dedicate a region >> >> of memory that below 2GB for the domU only. >> > >> > Uh, don't you mean 4GB? - 32bit is up to 4GB. >> >> The hardware uses 32-bit addressing, but the system will crash if I >> assigned above 2GB address to it. > > Ha! so buggy hardware.. or you are not using the XEn-SWIOTLB but somethin= g > else. >> So, 4GB from hardware spec, 2GB from my test. I am looking into that. > > Make sure you set > =C2=A0pci_set_consistent_dma_mask(dev, DMA_BIT_MASK(31)); > > on top of pci_set_dma_mask(dev, DMA_BIT_MASK(31)); > in your driver. > A lot of work to port the driver to PV domU, hope it works. Thanks for your help! _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel From xen-devel-bounces@lists.xensource.com Thu Sep 08 12:51:58 2011 Return-path: Envelope-to: www-data@lists.xensource.com Delivery-date: Thu, 08 Sep 2011 12:51:58 -0700 Received: from localhost ([127.0.0.1] helo=lists.colo.xensource.com) by lists.xensource.com with esmtp (Exim 4.43) id 1R1kdg-0003uu-M6; Thu, 08 Sep 2011 12:51:56 -0700 Received: from mail174.messagelabs.com ([85.158.138.51]) by lists.xensource.com with esmtp (Exim 4.43) id 1R1kcs-0003iS-Lc for xen-devel@lists.xensource.com; Thu, 08 Sep 2011 12:51:07 -0700 X-Env-Sender: konrad@dumpdata.com X-Msg-Ref: server-7.tower-174.messagelabs.com!1315511462!30734271!1 X-Originating-IP: [141.146.126.227] X-StarScan-Version: 6.3.6; banners=-,-,- X-VirusChecked: Checked Received: (qmail 9087 invoked from network); 8 Sep 2011 19:51:03 -0000 Received: from acsinet15.oracle.com (HELO acsinet15.oracle.com) (141.146.126.227) by server-7.tower-174.messagelabs.com with DHE-RSA-AES256-SHA encrypted SMTP; 8 Sep 2011 19:51:03 -0000 Received: from acsinet22.oracle.com (acsinet22.oracle.com [141.146.126.238]) by acsinet15.oracle.com (Switch-3.4.4/Switch-3.4.4) with ESMTP id p88JoqeH010746 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Thu, 8 Sep 2011 19:50:54 GMT Received: from acsmt358.oracle.com (acsmt358.oracle.com [141.146.40.158]) by acsinet22.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id p88Joqti027780 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 8 Sep 2011 19:50:52 GMT Received: from abhmt113.oracle.com (abhmt113.oracle.com [141.146.116.65]) by acsmt358.oracle.com (8.12.11.20060308/8.12.11) with ESMTP id p88Jokgm023352; Thu, 8 Sep 2011 14:50:46 -0500 Received: from phenom (/209.6.55.207) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Thu, 08 Sep 2011 12:50:46 -0700 Received: by phenom (Postfix, from userid 1000) id 3D9CAFD1; Thu, 8 Sep 2011 15:50:31 -0400 (EDT) Date: Thu, 8 Sep 2011 15:50:31 -0400 From: Konrad Rzeszutek Wilk To: Andreas Olsowski Subject: Re: [Xen-devel] xen/stable-2.6.32.x xen-4.1.1 live migration fails with kernels 2.6.39, 3.0.3 and 3.1-rc2 Message-ID: <20110908195031.GA21186@dumpdata.com> References: <4E52601B.5060609@leuphana.de> <20110824203435.GA27865@dumpdata.com> <4E55F682.8060405@leuphana.de> <20110826150054.GA1793@dumpdata.com> <4E57D745.2080701@leuphana.de> <20110829194911.GC16530@dumpdata.com> <4E5E320A.60401@leuphana.de> <20110907135046.GD32190@dumpdata.com> <20110908173212.GA17026@dumpdata.com> <20110908181227.GB19078@dumpdata.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20110908181227.GB19078@dumpdata.com> User-Agent: Mutt/1.5.21 (2010-09-15) X-Source-IP: acsinet22.oracle.com [141.146.126.238] X-Auth-Type: Internal IP X-CT-RefId: str=0001.0A090207.4E691C9F.000D:SCFMA922111,ss=1,re=-4.000,fgs=0 Cc: "xen-devel@lists.xensource.com" X-BeenThere: xen-devel@lists.xensource.com X-Mailman-Version: 2.1.5 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xensource.com Errors-To: xen-devel-bounces@lists.xensource.com On Thu, Sep 08, 2011 at 02:12:27PM -0400, Konrad Rzeszutek Wilk wrote: > On Thu, Sep 08, 2011 at 01:32:12PM -0400, Konrad Rzeszutek Wilk wrote: > > On Wed, Sep 07, 2011 at 09:50:47AM -0400, Konrad Rzeszutek Wilk wrote: > > > On Wed, Aug 31, 2011 at 03:07:22PM +0200, Andreas Olsowski wrote: > > > > A little update, i now have all machines running on xen-4.1-testing > > > > with xen/stable-2.6.32.x > > > > That gave me the possiblity for additional tests. > > > > > > > > (I also tested xm/xend in addtion to xl/libxl, to make sure its not > > > > a xl/libxl problem.) > > > > > > > > I took the liberty to create a new test result matrix that should > > > > provide a better overview (in case someone else wants to get the > > > > whole picture): > > > > > > So.. I don't think the issue I am seeing is exactly the same. This is > > > what 'xl' gives me: > > > > Scratch that. I am seeing the error below if I: > > > > 1) Create guest on 4GB machine > > 2) Migrate it to the 32GB box (guest still works) > > 3) Migrate it to the 4GB box (guest dies - error below shows up and > > guest is dead). > > > > With 3.1-rc5 virgin - both Dom0 and DomU. Also Xen 4.1-testing on top of this. > > > > I tried just creating a guest on the 32GB and migrating it - and while > > it did migrate it was stuck in a hypercall_page call or crashed later on. > > > > Andreas, > > > > Thanks for reporting this. > > Oh wait. At some point you said that 2.6.32.43 worked for you.. Is that still > the case? Can you please try one thing for me - can you make sure the boxes have exact same amount of memory? You can do 'mem=X' on the Xen hypervisor line to set that. I think the problem you are running into is that you are migrating between different CPU families... Is the /proc/cpuinfo drastically different between the boxes? _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel From xen-devel-bounces@lists.xensource.com Thu Sep 08 13:03:14 2011 Return-path: Envelope-to: www-data@lists.xensource.com Delivery-date: Thu, 08 Sep 2011 13:03:15 -0700 Received: from localhost ([127.0.0.1] helo=lists.colo.xensource.com) by lists.xensource.com with esmtp (Exim 4.43) id 1R1koc-0004Rk-OL; Thu, 08 Sep 2011 13:03:14 -0700 Received: from mail21.messagelabs.com ([85.158.143.35]) by lists.xensource.com with esmtp (Exim 4.43) id 1R1kmZ-0004Dx-WC for xen-devel@lists.xensource.com; Thu, 08 Sep 2011 13:01:25 -0700 X-Env-Sender: konrad@dumpdata.com X-Msg-Ref: server-9.tower-21.messagelabs.com!1315512020!47709681!1 X-Originating-IP: [148.87.113.117] X-StarScan-Version: 6.3.6; banners=-,-,- X-VirusChecked: Checked Received: (qmail 15044 invoked from network); 8 Sep 2011 20:00:22 -0000 Received: from rcsinet15.oracle.com (HELO rcsinet15.oracle.com) (148.87.113.117) by server-9.tower-21.messagelabs.com with DHE-RSA-AES256-SHA encrypted SMTP; 8 Sep 2011 20:00:22 -0000 Received: from acsinet21.oracle.com (acsinet21.oracle.com [141.146.126.237]) by rcsinet15.oracle.com (Switch-3.4.4/Switch-3.4.4) with ESMTP id p88K107o004795 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Thu, 8 Sep 2011 20:01:02 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 p88K0xDw004625 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 8 Sep 2011 20:01:00 GMT Received: from abhmt117.oracle.com (abhmt117.oracle.com [141.146.116.69]) by acsmt358.oracle.com (8.12.11.20060308/8.12.11) with ESMTP id p88K0ruB030620; Thu, 8 Sep 2011 15:00:54 -0500 Received: from phenom (/209.6.55.207) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Thu, 08 Sep 2011 13:00:53 -0700 Received: by phenom (Postfix, from userid 1000) id 2C426FD1; Thu, 8 Sep 2011 16:00:39 -0400 (EDT) Date: Thu, 8 Sep 2011 16:00:39 -0400 From: Konrad Rzeszutek Wilk To: Eric Camachat Subject: Re: [Xen-devel] Can I specify a physical memory region for a domU Message-ID: <20110908200038.GB21186@dumpdata.com> References: <20110908125920.GC28591@dumpdata.com> <20110908181205.GA19078@dumpdata.com> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.21 (2010-09-15) Content-Transfer-Encoding: quoted-printable X-Source-IP: acsinet21.oracle.com [141.146.126.237] X-Auth-Type: Internal IP X-CT-RefId: str=0001.0A090204.4E691EFE.006E:SCFMA922111,ss=1,re=-4.000,fgs=0 Cc: xen-devel@lists.xensource.com X-BeenThere: xen-devel@lists.xensource.com X-Mailman-Version: 2.1.5 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xensource.com Errors-To: xen-devel-bounces@lists.xensource.com > > Make sure you set > > =A0pci_set_consistent_dma_mask(dev, DMA_BIT_MASK(31)); > > > > on top of pci_set_dma_mask(dev, DMA_BIT_MASK(31)); > > in your driver. > > > A lot of work to port the driver to PV domU, hope it works. Hm? That is the normal way you would write drivers in the Linux kernel. You use the DMA API in it to deal with the PCI devices. Is the PV domU a Linux kernel or something else? _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel From xen-devel-bounces@lists.xensource.com Thu Sep 08 13:15:50 2011 Return-path: Envelope-to: www-data@lists.xensource.com Delivery-date: Thu, 08 Sep 2011 13:15:50 -0700 Received: from localhost ([127.0.0.1] helo=lists.colo.xensource.com) by lists.xensource.com with esmtp (Exim 4.43) id 1R1l0n-00051f-TB; Thu, 08 Sep 2011 13:15:49 -0700 Received: from mail174.messagelabs.com ([85.158.138.51]) by lists.xensource.com with esmtp (Exim 4.43) id 1R1l0D-0004pN-10 for xen-devel@lists.xensource.com; Thu, 08 Sep 2011 13:15:13 -0700 X-Env-Sender: keir.xen@gmail.com X-Msg-Ref: server-6.tower-174.messagelabs.com!1315512909!28619584!1 X-Originating-IP: [74.125.82.43] X-StarScan-Version: 6.3.6; banners=-,-,- X-VirusChecked: Checked Received: (qmail 5225 invoked from network); 8 Sep 2011 20:15:10 -0000 Received: from mail-ww0-f43.google.com (HELO mail-ww0-f43.google.com) (74.125.82.43) by server-6.tower-174.messagelabs.com with RC4-SHA encrypted SMTP; 8 Sep 2011 20:15:10 -0000 Received: by wwe32 with SMTP id 32so244416wwe.24 for ; Thu, 08 Sep 2011 13:15:09 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=user-agent:date:subject:from:to:message-id:thread-topic :thread-index:in-reply-to:mime-version:content-type :content-transfer-encoding; bh=ARtbnVweZ95faQv3VfxsS7+Bsdk9jzFH4QgKHvrYySk=; b=OtK1qEKN1H6T4rihM1uksw3nV8gKF8Jym83gXBbUsITMgLVIQNp2uXU03/U8Tw6l3L raPF9z9lgvBFw/UjqyPfJ31m1kiBmouoqoVMQ5uPgmBQuLRgeMyGbOwopclZoV2gcbHu 7TZpEqgWuE9SyON6qoYtYFFYANszFwDBsBhho= Received: by 10.227.57.66 with SMTP id b2mr1172225wbh.64.1315512909572; Thu, 08 Sep 2011 13:15:09 -0700 (PDT) Received: from [192.168.1.78] (host86-137-116-193.range86-137.btcentralplus.com [86.137.116.193]) by mx.google.com with ESMTPS id ev5sm5379886wbb.11.2011.09.08.13.15.06 (version=SSLv3 cipher=OTHER); Thu, 08 Sep 2011 13:15:07 -0700 (PDT) User-Agent: Microsoft-Entourage/12.30.0.110427 Date: Thu, 08 Sep 2011 21:15:00 +0100 Subject: Re: [Xen-devel] Whether xen will support intel atom cpu From: Keir Fraser To: Maxim Kozhevnikov , Message-ID: Thread-Topic: [Xen-devel] Whether xen will support intel atom cpu Thread-Index: AcxuY/xDemj7TChskE+ZmwuGwX0oxA== In-Reply-To: Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit Cc: X-BeenThere: xen-devel@lists.xensource.com X-Mailman-Version: 2.1.5 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xensource.com Errors-To: xen-devel-bounces@lists.xensource.com On 08/09/2011 18:59, "Maxim Kozhevnikov" wrote: > I have pc with intel atom cpu. And When use xen i got the following error: > "Performance Events : unsupported p6 CPU model 28 no PMU driver, software This message has absolutely nothing to do with support for ACPI S3 (suspend to ram). -- Keir > events only." So, i can use suspend to ram but can't use wake up from ram on > my pc. Please, tell me, when xen will support intel atom cpu? I use > xen-unstable (4.2) > _______________________________________________ > Xen-devel mailing list > Xen-devel@lists.xensource.com > http://lists.xensource.com/xen-devel _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel From xen-devel-bounces@lists.xensource.com Thu Sep 08 14:32:48 2011 Return-path: Envelope-to: www-data@lists.xensource.com Delivery-date: Thu, 08 Sep 2011 14:32:48 -0700 Received: from localhost ([127.0.0.1] helo=lists.colo.xensource.com) by lists.xensource.com with esmtp (Exim 4.43) id 1R1mDH-0007w7-Ug; Thu, 08 Sep 2011 14:32:47 -0700 Received: from mail21.messagelabs.com ([85.158.143.35]) by lists.xensource.com with smtp (Exim 4.43) id 1R1mCN-0007iR-LJ for xen-devel@lists.xensource.com; Thu, 08 Sep 2011 14:31:52 -0700 X-Env-Sender: ms@it-infrastrukturen.com X-Msg-Ref: server-7.tower-21.messagelabs.com!1315517479!54151146!1 X-Originating-IP: [88.198.203.66] X-StarScan-Version: 6.3.6; banners=-,-,- X-VirusChecked: Checked Received: (qmail 23910 invoked from network); 8 Sep 2011 21:31:19 -0000 Received: from srv1.born2b3.net (HELO srv1.born2b3.net) (88.198.203.66) by server-7.tower-21.messagelabs.com with SMTP; 8 Sep 2011 21:31:19 -0000 Received: from [192.168.1.100] (84-73-66-195.dclient.hispeed.ch [84.73.66.195]) by srv1.born2b3.net (Postfix) with ESMTPSA id 3E84AC07D8; Thu, 8 Sep 2011 21:31:48 +0000 (UTC) Message-ID: <4E6933D9.6070408@it-infrastrukturen.com> Date: Thu, 08 Sep 2011 23:30:01 +0200 From: "M. Schneider" User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.1.16) Gecko/20110307 Icedove/3.0.11 MIME-Version: 1.0 To: Konrad Rzeszutek Wilk Subject: OVM 3.0.1 missing support for P410i - Re: [Xen-devel] Solaris10-u9-ga-x86 HVM - panic[cpu0]/thread=fffffffffbc28020: BAD TRAP: type=9 Coprocessor segment overrun) rp=fffffffffbc30da8 addr=0 References: <4E5AA0F1.6010408@it-infrastrukturen.org> <4E5BF4AE.8040006@it-infrastrukturen.org> <20110831125755.GA16787@dumpdata.com> In-Reply-To: <20110831125755.GA16787@dumpdata.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Cc: Mark Schneider , xen-devel@lists.xensource.com X-BeenThere: xen-devel@lists.xensource.com X-Mailman-Version: 2.1.5 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xensource.com Errors-To: xen-devel-bounces@lists.xensource.com Am 31.08.2011 14:57, schrieb Konrad Rzeszutek Wilk: > On Mon, Aug 29, 2011 at 10:21:02PM +0200, Mark Schneider wrote: > >> Am 28.08.2011 22:11, schrieb Mark Schneider: >> >>> Hello, >>> >>> I am getting the following error (s. below and .ogv attachment) >>> when trying to boot an install iso image of solaris10-u9-ga-x86 >>> (sol-10-u9-ga-x86-dvd.iso) as HVM. >>> > So Solaris 10 (10/09) is supported by OVM3 (just released) - which is > 4.0.x based - so not sure why it does not work. Try it under OVM3 > or OVM2.2.2 > Thank you for your hints Konrad. Unfortunately the current OVM 3.0.1 *doesn't* directly support P410i RAID-controller of HP DL385g7 and I don't have any idea where to get these required drivers from. (I have just tried to install OVM 3.0.1). Regards, Mark -- IT-Infrastrukturen Schneider Wieslergasse 6 CH-8049 Zürich Phone: +41 43 818 4508 Mobile: +41 76 522 2923 ms@it-infrastrukturen.com http://www.it-infrastrukturen.com _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel From xen-devel-bounces@lists.xensource.com Thu Sep 08 15:52:19 2011 Return-path: Envelope-to: www-data@lists.xensource.com Delivery-date: Thu, 08 Sep 2011 15:52:19 -0700 Received: from localhost ([127.0.0.1] helo=lists.colo.xensource.com) by lists.xensource.com with esmtp (Exim 4.43) id 1R1nSF-0001cw-HY; Thu, 08 Sep 2011 15:52:19 -0700 Received: from mail174.messagelabs.com ([85.158.138.51]) by lists.xensource.com with smtp (Exim 4.43) id 1R1nRA-0001Q9-L7 for xen-devel@lists.xensource.com; Thu, 08 Sep 2011 15:51:14 -0700 X-Env-Sender: gcvxd-xen-devel@m.gmane.org X-Msg-Ref: server-14.tower-174.messagelabs.com!1315522269!30769199!1 X-Originating-IP: [80.91.229.12] X-StarScan-Version: 6.3.6; banners=-,-,- X-VirusChecked: Checked Received: (qmail 25622 invoked from network); 8 Sep 2011 22:51:09 -0000 Received: from lo.gmane.org (HELO lo.gmane.org) (80.91.229.12) by server-14.tower-174.messagelabs.com with SMTP; 8 Sep 2011 22:51:09 -0000 Received: from list by lo.gmane.org with local (Exim 4.69) (envelope-from ) id 1R1nR4-0002Qy-Ay for xen-devel@lists.xensource.com; Fri, 09 Sep 2011 00:51:06 +0200 Received: from 31-18-61-177-dynip.superkabel.de ([31.18.61.177]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Fri, 09 Sep 2011 00:51:06 +0200 Received: from sven.koehler by 31-18-61-177-dynip.superkabel.de with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Fri, 09 Sep 2011 00:51:06 +0200 X-Injected-Via-Gmane: http://gmane.org/ To: xen-devel@lists.xensource.com From: =?ISO-8859-1?Q?Sven_K=F6hler?= Date: Fri, 09 Sep 2011 00:53:03 +0200 Lines: 55 Message-ID: References: <20110908170755.GB16730@dumpdata.com> Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit X-Complaints-To: usenet@dough.gmane.org X-Gmane-NNTP-Posting-Host: 31-18-61-177-dynip.superkabel.de User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:6.0) Gecko/20110829 Thunderbird/6.0 In-Reply-To: <20110908170755.GB16730@dumpdata.com> X-Enigmail-Version: 1.3 Subject: [Xen-devel] Re: xl vs. xm, possible bug in xl X-BeenThere: xen-devel@lists.xensource.com X-Mailman-Version: 2.1.5 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xensource.com Errors-To: xen-devel-bounces@lists.xensource.com Am 08.09.2011 19:07, schrieb Konrad Rzeszutek Wilk: > On Thu, Sep 08, 2011 at 06:42:12PM +0200, Sven Köhler wrote: >> Hi, >> >> xl is supposed to superseed xm, is this correct? How mature is xl, >> actually? I'm asking, because the maintainers of the gentoo's xen >> packages are migrating the init.d-scripts from xm to xl, but xl is >> causing a lot of trouble. >> >> Well, xl basically fails to start domains on my system. >>> # xl create /etc/xen/xen-sk1 >>> Parsing config file /etc/xen/xen-sk1 >>> libxl: error: libxl.c:2145:libxl_set_memory_target new target 0 for dom0 is below the minimum threshold >>> libxl: error: libxl.c:2145:libxl_set_memory_target new target 0 for dom0 is below the minimum threshold >>> libxl: error: libxl.c:2145:libxl_set_memory_target new target 0 for dom0 is below the minimum threshold >>> failed to free memory for the domain >> >> Consider, that autobaloon=1 in xl.conf. >> With the autobaloon=0 the errors change to >> >>> # xl create /etc/xen/xen-sk1 >>> Parsing config file /etc/xen/xen-sk1 >>> libxl: error: libxl_device.c:476:libxl__wait_for_device_model Device Model not ready >>> xl: fatal error: libxl_create.c:535, rc=-1: libxl__confirm_device_model_startup >> >> >> Note, that I use dom0_mem=512M in grub.conf. Also, xm top states, that >> there are 2139432k free memory. Considering the first issue, it seems >> like xl is trying to baloon memory away from dom0, which fails - which >> seems obvious wrong considering that I use dom0_mem. CONFIG_XEN_BALLOON >> is enabled for dom0 > > Yeah, there is a bug there (in Linux kernel) that just got integrated in 3.1-rc5. > Will show up in 3.0.5. A bug will show up in 3.0.5/3.1-rc5 or the fix for it? Also, you seem to be replying to the first problem, the on about memory. Any clue, that the second problem is about? > # xl create /etc/xen/xen-sk1 > Parsing config file /etc/xen/xen-sk1 > libxl: error: libxl_device.c:476:libxl__wait_for_device_model Device Model not ready > xl: fatal error: libxl_create.c:535, rc=-1: libxl__confirm_device_model_startup >> dom0: >> vanilla 3.0.0 with vga patch > > You could upgrade to 3.0.4 and then you get the VGA patch for free > (and some bug-fixes too). Done. No improvement. _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel From xen-devel-bounces@lists.xensource.com Thu Sep 08 16:14:02 2011 Return-path: Envelope-to: www-data@lists.xensource.com Delivery-date: Thu, 08 Sep 2011 16:14:02 -0700 Received: from localhost ([127.0.0.1] helo=lists.colo.xensource.com) by lists.xensource.com with esmtp (Exim 4.43) id 1R1nnF-0002y9-6B; Thu, 08 Sep 2011 16:14:01 -0700 Received: from mail216.messagelabs.com ([85.158.143.99]) by lists.xensource.com with smtp (Exim 4.43) id 1R1nmL-0002m9-0a for xen-devel@lists.xensource.com; Thu, 08 Sep 2011 16:13:05 -0700 X-Env-Sender: gcvxd-xen-devel@m.gmane.org X-Msg-Ref: server-13.tower-216.messagelabs.com!1315523581!17619703!1 X-Originating-IP: [80.91.229.12] X-StarScan-Version: 6.3.6; banners=-,-,- X-VirusChecked: Checked Received: (qmail 26600 invoked from network); 8 Sep 2011 23:13:02 -0000 Received: from lo.gmane.org (HELO lo.gmane.org) (80.91.229.12) by server-13.tower-216.messagelabs.com with SMTP; 8 Sep 2011 23:13:02 -0000 Received: from list by lo.gmane.org with local (Exim 4.69) (envelope-from ) id 1R1nmH-0003o4-H2 for xen-devel@lists.xensource.com; Fri, 09 Sep 2011 01:13:01 +0200 Received: from 31-18-61-177-dynip.superkabel.de ([31.18.61.177]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Fri, 09 Sep 2011 01:13:01 +0200 Received: from sven.koehler by 31-18-61-177-dynip.superkabel.de with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Fri, 09 Sep 2011 01:13:01 +0200 X-Injected-Via-Gmane: http://gmane.org/ To: xen-devel@lists.xensource.com From: =?ISO-8859-15?Q?Sven_K=F6hler?= Date: Fri, 09 Sep 2011 01:15:00 +0200 Lines: 41 Message-ID: Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-15 Content-Transfer-Encoding: 7bit X-Complaints-To: usenet@dough.gmane.org X-Gmane-NNTP-Posting-Host: 31-18-61-177-dynip.superkabel.de User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:6.0) Gecko/20110829 Thunderbird/6.0 X-Enigmail-Version: 1.3 Subject: [Xen-devel] computer stalls instead of reboot X-BeenThere: xen-devel@lists.xensource.com X-Mailman-Version: 2.1.5 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xensource.com Errors-To: xen-devel-bounces@lists.xensource.com Hi, I'm still seeing a very strange issue here. First, let's clarify that the issue has never occurred with the good old xen 3.x and the good old 2.6.18 kernel. So the issue is, that with xen 4.x (including 4.1.1) pretty much any kernel (including kernel from [1] and vanilla 3.0.0, didn't test the 2.6.18), the machine freezes during a reboot. The machine won't come up again, not even the BIOS screen will show. It doesn't happen when running the kernel on bare metal. Also the fact that it doesn't happen with xen 3.x + 2.6.18 might meen, that this is a regression of some sort. This issue has prevented my move from xen 3.x to xen 4.x for many years now. I already asked about this issue, and nobody replied. So I hoped, that the kernel from kernel.org would solve this, once that pvops dom0 enabled kernels were available. Well, it didn't. I'm still stuck with this issue. Every time I want to reboot my machine, I have to call my hosting company to reboot the server. It's a MSI X58 Pro-E (MS-7522) motherboard, equipped with Intel Core i7 920 and an nvidia graphics card. Did anybody ever experience a similar issue? Does anybody have any suggestions how to continue? This seems to be a very weired issue, and even pushing the computers reset button doesn't seem to help. (It's a remote machine, and I can remotely push the reset button). I have already updated the BIOS, and disabled virtualization (only paravirt domUs). However, no improvement. Kind Regards, Sven [1] http://code.google.com/p/gentoo-xen-kernel/ _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel From xen-devel-bounces@lists.xensource.com Thu Sep 08 16:17:49 2011 Return-path: Envelope-to: www-data@lists.xensource.com Delivery-date: Thu, 08 Sep 2011 16:17:49 -0700 Received: from localhost ([127.0.0.1] helo=lists.colo.xensource.com) by lists.xensource.com with esmtp (Exim 4.43) id 1R1nqv-0003NC-GG; Thu, 08 Sep 2011 16:17:49 -0700 Received: from mail174.messagelabs.com ([85.158.138.51]) by lists.xensource.com with smtp (Exim 4.43) id 1R1nqU-0003BO-AT for xen-devel@lists.xensource.com; Thu, 08 Sep 2011 16:17:22 -0700 X-Env-Sender: Andrew.Cooper3@citrix.com X-Msg-Ref: server-12.tower-174.messagelabs.com!1315523839!30751446!1 X-Originating-IP: [62.200.22.115] X-StarScan-Version: 6.3.6; banners=-,-,- X-VirusChecked: Checked Received: (qmail 30986 invoked from network); 8 Sep 2011 23:17:19 -0000 Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115) by server-12.tower-174.messagelabs.com with SMTP; 8 Sep 2011 23:17:19 -0000 X-IronPort-AV: E=Sophos;i="4.68,353,1312156800"; d="scan'208";a="7686861" Received: from lonpmailmx01.citrite.net ([10.30.203.162]) by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5; 08 Sep 2011 23:17:18 +0000 Received: from [10.30.249.79] (10.30.249.79) by LONPMAILMX01.citrite.net (10.30.203.162) with Microsoft SMTP Server id 8.3.137.0; Fri, 9 Sep 2011 00:17:18 +0100 Message-ID: <4E694CFB.1060203@citrix.com> Date: Fri, 9 Sep 2011 00:17:15 +0100 From: Andrew Cooper User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:6.0.1) Gecko/20110830 Thunderbird/6.0.1 MIME-Version: 1.0 To: Subject: Re: [Xen-devel] computer stalls instead of reboot References: In-Reply-To: Content-Type: text/plain; charset="ISO-8859-15" Content-Transfer-Encoding: 8bit X-BeenThere: xen-devel@lists.xensource.com X-Mailman-Version: 2.1.5 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xensource.com Errors-To: xen-devel-bounces@lists.xensource.com On 09/09/2011 00:15, Sven Köhler wrote: > Hi, > > I'm still seeing a very strange issue here. First, let's clarify that > the issue has never occurred with the good old xen 3.x and the good old > 2.6.18 kernel. > > So the issue is, that with xen 4.x (including 4.1.1) pretty much any > kernel (including kernel from [1] and vanilla 3.0.0, didn't test the > 2.6.18), the machine freezes during a reboot. The machine won't come up > again, not even the BIOS screen will show. > > It doesn't happen when running the kernel on bare metal. Also the fact > that it doesn't happen with xen 3.x + 2.6.18 might meen, that this is a > regression of some sort. > > This issue has prevented my move from xen 3.x to xen 4.x for many years > now. I already asked about this issue, and nobody replied. So I hoped, > that the kernel from kernel.org would solve this, once that pvops dom0 > enabled kernels were available. Well, it didn't. I'm still stuck with > this issue. Every time I want to reboot my machine, I have to call my > hosting company to reboot the server. > > It's a MSI X58 Pro-E (MS-7522) motherboard, equipped with Intel Core i7 > 920 and an nvidia graphics card. > > Did anybody ever experience a similar issue? > Does anybody have any suggestions how to continue? > > This seems to be a very weired issue, and even pushing the computers > reset button doesn't seem to help. (It's a remote machine, and I can > remotely push the reset button). Does your "remote" method involve actually pushing the reset button, and does this method actually work under normal circumstances? As for the problem itself, do you have C states enabled in the BIOS? This sounds similar to several errata published for the i7 series. ~Andrew > > I have already updated the BIOS, and disabled virtualization (only > paravirt domUs). However, no improvement. > > > Kind Regards, > Sven > > > [1] http://code.google.com/p/gentoo-xen-kernel/ > > > _______________________________________________ > Xen-devel mailing list > Xen-devel@lists.xensource.com > http://lists.xensource.com/xen-devel _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel From xen-devel-bounces@lists.xensource.com Thu Sep 08 16:39:01 2011 Return-path: Envelope-to: www-data@lists.xensource.com Delivery-date: Thu, 08 Sep 2011 16:39:01 -0700 Received: from localhost ([127.0.0.1] helo=lists.colo.xensource.com) by lists.xensource.com with esmtp (Exim 4.43) id 1R1oBQ-0004In-Vo; Thu, 08 Sep 2011 16:39:01 -0700 Received: from mail21.messagelabs.com ([85.158.143.35]) by lists.xensource.com with smtp (Exim 4.43) id 1R1oAq-00046Q-PD for xen-devel@lists.xensource.com; Thu, 08 Sep 2011 16:38:25 -0700 X-Env-Sender: gcvxd-xen-devel@m.gmane.org X-Msg-Ref: server-6.tower-21.messagelabs.com!1315525082!37551038!1 X-Originating-IP: [80.91.229.12] X-StarScan-Version: 6.3.6; banners=-,-,- X-VirusChecked: Checked Received: (qmail 16958 invoked from network); 8 Sep 2011 23:38:02 -0000 Received: from lo.gmane.org (HELO lo.gmane.org) (80.91.229.12) by server-6.tower-21.messagelabs.com with SMTP; 8 Sep 2011 23:38:02 -0000 Received: from list by lo.gmane.org with local (Exim 4.69) (envelope-from ) id 1R1oAl-0005BD-G4 for xen-devel@lists.xensource.com; Fri, 09 Sep 2011 01:38:19 +0200 Received: from 31-18-61-177-dynip.superkabel.de ([31.18.61.177]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Fri, 09 Sep 2011 01:38:19 +0200 Received: from sven.koehler by 31-18-61-177-dynip.superkabel.de with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Fri, 09 Sep 2011 01:38:19 +0200 X-Injected-Via-Gmane: http://gmane.org/ To: xen-devel@lists.xensource.com From: =?ISO-8859-15?Q?Sven_K=F6hler?= Date: Fri, 09 Sep 2011 01:40:18 +0200 Lines: 22 Message-ID: References: <4E694CFB.1060203@citrix.com> Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-15 Content-Transfer-Encoding: 7bit X-Complaints-To: usenet@dough.gmane.org X-Gmane-NNTP-Posting-Host: 31-18-61-177-dynip.superkabel.de User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:6.0) Gecko/20110829 Thunderbird/6.0 In-Reply-To: <4E694CFB.1060203@citrix.com> X-Enigmail-Version: 1.3 Subject: [Xen-devel] Re: computer stalls instead of reboot X-BeenThere: xen-devel@lists.xensource.com X-Mailman-Version: 2.1.5 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xensource.com Errors-To: xen-devel-bounces@lists.xensource.com Am 09.09.2011 01:17, schrieb Andrew Cooper: > Does your "remote" method involve actually pushing the reset button, and > does this method actually work under normal circumstances? I think, there is a device connected to the connector on the motherboard, to which the reset button would normally be attached. > As for the problem itself, do you have C states enabled in the BIOS? > This sounds similar to several errata published for the i7 series. I'm not sure how to tell whether C states are disabled/enabled. What would those BIOS options typically be called? Also, should I enable or disable them, in order to workaround those errata that you mention? Should those errors have occurred with xen 3.x as well, if those were a result of the errata you mention? Regards, Sven _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel From xen-devel-bounces@lists.xensource.com Thu Sep 08 16:42:00 2011 Return-path: Envelope-to: www-data@lists.xensource.com Delivery-date: Thu, 08 Sep 2011 16:42:00 -0700 Received: from localhost ([127.0.0.1] helo=lists.colo.xensource.com) by lists.xensource.com with esmtp (Exim 4.43) id 1R1oEK-0004nY-GG; Thu, 08 Sep 2011 16:42:00 -0700 Received: from mail174.messagelabs.com ([85.158.138.51]) by lists.xensource.com with smtp (Exim 4.43) id 1R1oDl-0004bF-VF for xen-devel@lists.xensource.com; Thu, 08 Sep 2011 16:41:26 -0700 X-Env-Sender: kaushik.barde@huawei.com X-Msg-Ref: server-9.tower-174.messagelabs.com!1315525282!24734894!1 X-Originating-IP: [206.16.17.70] X-StarScan-Version: 6.3.6; banners=-,-,- X-VirusChecked: Checked Received: (qmail 23051 invoked from network); 8 Sep 2011 23:41:22 -0000 Received: from usaga02-in.huawei.com (HELO usaga02-in.huawei.com) (206.16.17.70) by server-9.tower-174.messagelabs.com with SMTP; 8 Sep 2011 23:41:22 -0000 Received: from huawei.com (localhost [127.0.0.1]) by usaga02-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0LR800GP49SX4G@usaga02-in.huawei.com> for xen-devel@lists.xensource.com; Thu, 08 Sep 2011 18:41:22 -0500 (CDT) Received: from dfweml201-edg.china.huawei.com ([172.18.4.104]) by usaga02-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTPS id <0LR800ICR9SX8C@usaga02-in.huawei.com> for xen-devel@lists.xensource.com; Thu, 08 Sep 2011 18:41:21 -0500 (CDT) Received: from DFWEML402-HUB.china.huawei.com (10.193.5.102) by dfweml201-edg.china.huawei.com (172.18.9.107) with Microsoft SMTP Server (TLS) id 14.1.270.1; Thu, 08 Sep 2011 16:41:15 -0700 Received: from BardeKaushik1 (10.193.36.116) by DFWEML402-HUB.china.huawei.com (10.193.5.102) with Microsoft SMTP Server id 14.1.270.1; Thu, 08 Sep 2011 16:41:16 -0700 Date: Thu, 08 Sep 2011 16:41:16 -0700 From: Kaushik Barde Subject: RE: [Xen-devel] Whether xen will support intel atom cpu In-reply-to: X-Originating-IP: [10.193.36.116] To: 'Keir Fraser' , 'Maxim Kozhevnikov' , xen-devel@lists.xensource.com Message-id: <012801cc6e80$cd7a37f0$686ea7d0$%barde@huawei.com> MIME-version: 1.0 X-Mailer: Microsoft Office Outlook 12.0 Content-type: text/plain; charset=us-ascii Content-language: en-us Content-transfer-encoding: 7BIT Thread-index: AcxuY/xDemj7TChskE+ZmwuGwX0oxAAHKTLw References: Cc: X-BeenThere: xen-devel@lists.xensource.com X-Mailman-Version: 2.1.5 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xensource.com Errors-To: xen-devel-bounces@lists.xensource.com Agreed, Try installing vanilla linux on that unit and see if S3 works.. -Kaushik -----Original Message----- From: xen-devel-bounces@lists.xensource.com [mailto:xen-devel-bounces@lists.xensource.com] On Behalf Of Keir Fraser Sent: Thursday, September 08, 2011 1:15 PM To: Maxim Kozhevnikov; xen-devel@lists.xensource.com Subject: Re: [Xen-devel] Whether xen will support intel atom cpu On 08/09/2011 18:59, "Maxim Kozhevnikov" wrote: > I have pc with intel atom cpu. And When use xen i got the following error: > "Performance Events : unsupported p6 CPU model 28 no PMU driver, software This message has absolutely nothing to do with support for ACPI S3 (suspend to ram). -- Keir > events only." So, i can use suspend to ram but can't use wake up from ram on > my pc. Please, tell me, when xen will support intel atom cpu? I use > xen-unstable (4.2) > _______________________________________________ > Xen-devel mailing list > Xen-devel@lists.xensource.com > http://lists.xensource.com/xen-devel _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel From xen-devel-bounces@lists.xensource.com Thu Sep 08 17:16:28 2011 Return-path: Envelope-to: www-data@lists.xensource.com Delivery-date: Thu, 08 Sep 2011 17:16:28 -0700 Received: from localhost ([127.0.0.1] helo=lists.colo.xensource.com) by lists.xensource.com with esmtp (Exim 4.43) id 1R1olg-0005hW-0u; Thu, 08 Sep 2011 17:16:28 -0700 Received: from mail27.messagelabs.com ([193.109.254.147]) by lists.xensource.com with esmtp (Exim 4.43) id 1R1okk-0005Uz-De for xen-devel@lists.xensource.com; Thu, 08 Sep 2011 17:15:30 -0700 X-Env-Sender: eric.camachat@gmail.com X-Msg-Ref: server-8.tower-27.messagelabs.com!1315527311!45834273!1 X-Originating-IP: [209.85.218.43] X-StarScan-Version: 6.3.6; banners=-,-,- X-VirusChecked: Checked Received: (qmail 9298 invoked from network); 9 Sep 2011 00:15:12 -0000 Received: from mail-yi0-f43.google.com (HELO mail-yi0-f43.google.com) (209.85.218.43) by server-8.tower-27.messagelabs.com with RC4-SHA encrypted SMTP; 9 Sep 2011 00:15:12 -0000 Received: by yia27 with SMTP id 27so523515yia.30 for ; Thu, 08 Sep 2011 17:15:26 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type:content-transfer-encoding; bh=16XPGgNwYyXXJ35BoYrKux0v9JNi6/XsYE4+6C9KR0s=; b=s3i8yxlinPDLBqxSzYsEolanjOjN72xLoYsJDXpFjWU/5j6GiWS+9oUpD0PRkmvTBZ KQos76FDO1g/s2tRdViftDnk+K4GpnaVDQNiVb6+6dvd+xlXSbSoMjij4QGaOoUaal3c Xh/GPYPFPTcJtj+irOA9AtE/vglQdUyyjEzFQ= Received: by 10.236.179.103 with SMTP id g67mr8513934yhm.49.1315527326096; Thu, 08 Sep 2011 17:15:26 -0700 (PDT) MIME-Version: 1.0 Received: by 10.236.95.5 with HTTP; Thu, 8 Sep 2011 17:15:06 -0700 (PDT) In-Reply-To: <20110908200038.GB21186@dumpdata.com> References: <20110908125920.GC28591@dumpdata.com> <20110908181205.GA19078@dumpdata.com> <20110908200038.GB21186@dumpdata.com> From: Eric Camachat Date: Thu, 8 Sep 2011 17:15:06 -0700 Message-ID: Subject: Re: [Xen-devel] Can I specify a physical memory region for a domU To: Konrad Rzeszutek Wilk Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Cc: xen-devel@lists.xensource.com X-BeenThere: xen-devel@lists.xensource.com X-Mailman-Version: 2.1.5 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xensource.com Errors-To: xen-devel-bounces@lists.xensource.com On Thu, Sep 8, 2011 at 1:00 PM, Konrad Rzeszutek Wilk wrote: >> > Make sure you set >> > =C2=A0pci_set_consistent_dma_mask(dev, DMA_BIT_MASK(31)); >> > >> > on top of pci_set_dma_mask(dev, DMA_BIT_MASK(31)); >> > in your driver. >> > >> A lot of work to port the driver to PV domU, hope it works. > > Hm? That is the normal way you would write drivers in the Linux kernel. > You use the DMA API in it to deal with the PCI devices. > > Is the PV domU a Linux kernel or something else? > Yes, the PV domU is linux kernel. I tested pci_alloc_consistent() verified on baremetal it worked with 8GB SD= RAM. But while I ran it in XEN, pci_alloc_consistent() cannot allocate memory successfully for 4MB although pci_set_dma_mask(), pci_set_consistent_dma_mask() and dma_set_mask() all succeeded. _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel From xen-devel-bounces@lists.xensource.com Thu Sep 08 18:06:55 2011 Return-path: Envelope-to: www-data@lists.xensource.com Delivery-date: Thu, 08 Sep 2011 18:06:55 -0700 Received: from localhost ([127.0.0.1] helo=lists.colo.xensource.com) by lists.xensource.com with esmtp (Exim 4.43) id 1R1pYV-0007mm-5l; Thu, 08 Sep 2011 18:06:55 -0700 Received: from mail27.messagelabs.com ([193.109.254.147]) by lists.xensource.com with esmtp (Exim 4.43) id 1R1pWq-0007Zn-Iv for xen-devel@lists.xensource.com; Thu, 08 Sep 2011 18:05:23 -0700 X-Env-Sender: konrad@dumpdata.com X-Msg-Ref: server-4.tower-27.messagelabs.com!1315530291!39500424!1 X-Originating-IP: [148.87.113.117] X-StarScan-Version: 6.3.6; banners=-,-,- X-VirusChecked: Checked Received: (qmail 23067 invoked from network); 9 Sep 2011 01:04:52 -0000 Received: from rcsinet15.oracle.com (HELO rcsinet15.oracle.com) (148.87.113.117) by server-4.tower-27.messagelabs.com with DHE-RSA-AES256-SHA encrypted SMTP; 9 Sep 2011 01:04:52 -0000 Received: from rtcsinet22.oracle.com (rtcsinet22.oracle.com [66.248.204.30]) by rcsinet15.oracle.com (Switch-3.4.4/Switch-3.4.4) with ESMTP id p89150Iu019017 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Fri, 9 Sep 2011 01:05:02 GMT Received: from acsmt358.oracle.com (acsmt358.oracle.com [141.146.40.158]) by rtcsinet22.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id p8914vW3007105 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 9 Sep 2011 01:04:58 GMT Received: from abhmt117.oracle.com (abhmt117.oracle.com [141.146.116.69]) by acsmt358.oracle.com (8.12.11.20060308/8.12.11) with ESMTP id p8914qKi026060; Thu, 8 Sep 2011 20:04:52 -0500 Received: from phenom (/209.6.55.207) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Thu, 08 Sep 2011 18:04:51 -0700 Received: by phenom (Postfix, from userid 1000) id 8BBBE139B; Thu, 8 Sep 2011 21:04:36 -0400 (EDT) Date: Thu, 8 Sep 2011 21:04:36 -0400 From: Konrad Rzeszutek Wilk To: Kaushik Barde Subject: Re: [Xen-devel] Whether xen will support intel atom cpu Message-ID: <20110909010436.GA9060@dumpdata.com> References: <012801cc6e80$cd7a37f0$686ea7d0$%barde@huawei.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <012801cc6e80$cd7a37f0$686ea7d0$%barde@huawei.com> User-Agent: Mutt/1.5.21 (2010-09-15) X-Source-IP: rtcsinet22.oracle.com [66.248.204.30] X-CT-RefId: str=0001.0A090206.4E69663E.0059,ss=1,re=0.000,fgs=0 Cc: 'Keir Fraser' , xen-devel@lists.xensource.com, 'Maxim Kozhevnikov' X-BeenThere: xen-devel@lists.xensource.com X-Mailman-Version: 2.1.5 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xensource.com Errors-To: xen-devel-bounces@lists.xensource.com On Thu, Sep 08, 2011 at 04:41:16PM -0700, Kaushik Barde wrote: > Agreed, Try installing vanilla linux on that unit and see if S3 works.. It won't. Please try the testing branch. git://oss.oracle.com/git/kwilk/xen.git #testing > > -Kaushik > -----Original Message----- > From: xen-devel-bounces@lists.xensource.com > [mailto:xen-devel-bounces@lists.xensource.com] On Behalf Of Keir Fraser > Sent: Thursday, September 08, 2011 1:15 PM > To: Maxim Kozhevnikov; xen-devel@lists.xensource.com > Subject: Re: [Xen-devel] Whether xen will support intel atom cpu > > On 08/09/2011 18:59, "Maxim Kozhevnikov" wrote: > > > I have pc with intel atom cpu. > And When use xen i got the following error: > > > "Performance Events : unsupported p6 CPU model 28 no PMU driver, software > > This message has absolutely nothing to do with support for ACPI S3 (suspend > to ram). > > -- Keir > > > events only." > So, i can use suspend to ram but can't use wake up from ram on > > my pc. > Please, tell me, when xen will support intel atom cpu? > I use > > xen-unstable (4.2) > > _______________________________________________ > > Xen-devel mailing list > > Xen-devel@lists.xensource.com > > http://lists.xensource.com/xen-devel > > > > _______________________________________________ > Xen-devel mailing list > Xen-devel@lists.xensource.com > http://lists.xensource.com/xen-devel > > > _______________________________________________ > Xen-devel mailing list > Xen-devel@lists.xensource.com > http://lists.xensource.com/xen-devel _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel From xen-devel-bounces@lists.xensource.com Thu Sep 08 18:08:21 2011 Return-path: Envelope-to: www-data@lists.xensource.com Delivery-date: Thu, 08 Sep 2011 18:08:21 -0700 Received: from localhost ([127.0.0.1] helo=lists.colo.xensource.com) by lists.xensource.com with esmtp (Exim 4.43) id 1R1pZt-0008AD-M0; Thu, 08 Sep 2011 18:08:21 -0700 Received: from mail21.messagelabs.com ([85.158.143.35]) by lists.xensource.com with esmtp (Exim 4.43) id 1R1pXv-0007h8-RI for xen-devel@lists.xensource.com; Thu, 08 Sep 2011 18:06:23 -0700 X-Env-Sender: konrad@dumpdata.com X-Msg-Ref: server-15.tower-21.messagelabs.com!1315530376!49891731!1 X-Originating-IP: [148.87.113.117] X-StarScan-Version: 6.3.6; banners=-,-,- X-VirusChecked: Checked Received: (qmail 1674 invoked from network); 9 Sep 2011 01:06:17 -0000 Received: from rcsinet15.oracle.com (HELO rcsinet15.oracle.com) (148.87.113.117) by server-15.tower-21.messagelabs.com with DHE-RSA-AES256-SHA encrypted SMTP; 9 Sep 2011 01:06:17 -0000 Received: from rtcsinet22.oracle.com (rtcsinet22.oracle.com [66.248.204.30]) by rcsinet15.oracle.com (Switch-3.4.4/Switch-3.4.4) with ESMTP id p8916CvE020326 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Fri, 9 Sep 2011 01:06:14 GMT Received: from acsmt357.oracle.com (acsmt357.oracle.com [141.146.40.157]) by rtcsinet22.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id p8916Bcw008315 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 9 Sep 2011 01:06:12 GMT Received: from abhmt118.oracle.com (abhmt118.oracle.com [141.146.116.70]) by acsmt357.oracle.com (8.12.11.20060308/8.12.11) with ESMTP id p89165bb023205; Thu, 8 Sep 2011 20:06:05 -0500 Received: from phenom (/209.6.55.207) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Thu, 08 Sep 2011 18:06:05 -0700 Received: by phenom (Postfix, from userid 1000) id AF1E0139B; Thu, 8 Sep 2011 21:05:50 -0400 (EDT) Date: Thu, 8 Sep 2011 21:05:50 -0400 From: Konrad Rzeszutek Wilk To: Eric Camachat Subject: Re: [Xen-devel] Can I specify a physical memory region for a domU Message-ID: <20110909010550.GB9060@dumpdata.com> References: <20110908125920.GC28591@dumpdata.com> <20110908181205.GA19078@dumpdata.com> <20110908200038.GB21186@dumpdata.com> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.21 (2010-09-15) Content-Transfer-Encoding: quoted-printable X-Source-IP: rtcsinet22.oracle.com [66.248.204.30] X-CT-RefId: str=0001.0A090206.4E696686.006C,ss=1,re=0.000,fgs=0 Cc: xen-devel@lists.xensource.com X-BeenThere: xen-devel@lists.xensource.com X-Mailman-Version: 2.1.5 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xensource.com Errors-To: xen-devel-bounces@lists.xensource.com On Thu, Sep 08, 2011 at 05:15:06PM -0700, Eric Camachat wrote: > On Thu, Sep 8, 2011 at 1:00 PM, Konrad Rzeszutek Wilk > wrote: > >> > Make sure you set > >> > =A0pci_set_consistent_dma_mask(dev, DMA_BIT_MASK(31)); > >> > > >> > on top of pci_set_dma_mask(dev, DMA_BIT_MASK(31)); > >> > in your driver. > >> > > >> A lot of work to port the driver to PV domU, hope it works. > > > > Hm? That is the normal way you would write drivers in the Linux kerne= l. > > You use the DMA API in it to deal with the PCI devices. > > > > Is the PV domU a Linux kernel or something else? > > >=20 > Yes, the PV domU is linux kernel. >=20 > I tested pci_alloc_consistent() verified on baremetal it worked with 8G= B SDRAM. > But while I ran it in XEN, pci_alloc_consistent() cannot allocate > memory successfully for 4MB although pci_set_dma_mask(), And what is the error? > pci_set_consistent_dma_mask() and dma_set_mask() all succeeded. And what kernel did you use? >=20 > _______________________________________________ > Xen-devel mailing list > Xen-devel@lists.xensource.com > http://lists.xensource.com/xen-devel _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel From xen-devel-bounces@lists.xensource.com Thu Sep 08 18:28:20 2011 Return-path: Envelope-to: www-data@lists.xensource.com Delivery-date: Thu, 08 Sep 2011 18:28:20 -0700 Received: from localhost ([127.0.0.1] helo=lists.colo.xensource.com) by lists.xensource.com with esmtp (Exim 4.43) id 1R1ptD-0000PH-3g; Thu, 08 Sep 2011 18:28:19 -0700 Received: from mail27.messagelabs.com ([193.109.254.147]) by lists.xensource.com with smtp (Exim 4.43) id 1R1psL-0000Bd-Ts for xen-devel@lists.xensource.com; Thu, 08 Sep 2011 18:27:26 -0700 X-Env-Sender: Ian.Jackson@eu.citrix.com X-Msg-Ref: server-2.tower-27.messagelabs.com!1315531620!54203734!1 X-Originating-IP: [62.200.22.115] X-StarScan-Version: 6.3.6; banners=-,-,- X-VirusChecked: Checked Received: (qmail 10791 invoked from network); 9 Sep 2011 01:27:00 -0000 Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115) by server-2.tower-27.messagelabs.com with SMTP; 9 Sep 2011 01:27:00 -0000 X-IronPort-AV: E=Sophos;i="4.68,353,1312156800"; d="scan'208";a="7687545" Received: from lonpmailmx01.citrite.net ([10.30.203.162]) by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5; 09 Sep 2011 01:27:22 +0000 Received: from woking.xci-test.com (10.80.248.135) by smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id 8.3.137.0; Fri, 9 Sep 2011 02:27:22 +0100 Received: from osstest by woking.xci-test.com with local (Exim 4.69) (envelope-from ) id 1R1psI-0004ex-C4; Fri, 09 Sep 2011 02:27:22 +0100 To: xen-devel@lists.xensource.com Message-ID: From: xen.org Date: Fri, 9 Sep 2011 02:27:22 +0100 MIME-Version: 1.0 Content-Type: text/plain Cc: ian.jackson@eu.citrix.com Subject: [Xen-devel] [xen-unstable test] 8869: tolerable FAIL X-BeenThere: xen-devel@lists.xensource.com X-Mailman-Version: 2.1.5 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xensource.com Errors-To: xen-devel-bounces@lists.xensource.com flight 8869 xen-unstable real [real] http://www.chiark.greenend.org.uk/~xensrcts/logs/8869/ Failures :-/ but no regressions. Tests which did not succeed, but are not blocking, including regressions (tests previously passed) regarded as allowable: test-amd64-amd64-xl-pcipt-intel 1 xen-build-check(1) blocked n/a test-amd64-i386-rhel6hvm-intel 1 xen-build-check(1) blocked n/a test-i386-i386-pv 1 xen-build-check(1) blocked n/a test-amd64-i386-pv 1 xen-build-check(1) blocked n/a test-amd64-amd64-pv 1 xen-build-check(1) blocked n/a test-i386-i386-xl 1 xen-build-check(1) blocked n/a test-amd64-i386-xl 1 xen-build-check(1) blocked n/a test-amd64-i386-xl-credit2 1 xen-build-check(1) blocked n/a test-amd64-i386-rhel6hvm-amd 1 xen-build-check(1) blocked n/a test-amd64-amd64-pair 1 xen-build-check(1) blocked n/a test-amd64-i386-pair 1 xen-build-check(1) blocked n/a test-i386-i386-pair 1 xen-build-check(1) blocked n/a build-amd64-pvops 4 kernel-build fail like 8865 build-i386-pvops 4 kernel-build fail like 8865 test-amd64-i386-xl-multivcpu 1 xen-build-check(1) blocked n/a test-amd64-amd64-xl-sedf 1 xen-build-check(1) blocked n/a test-amd64-i386-win-vcpus1 1 xen-build-check(1) blocked n/a test-amd64-i386-xl-win-vcpus1 1 xen-build-check(1) blocked n/a test-amd64-amd64-win 1 xen-build-check(1) blocked n/a test-amd64-i386-win 1 xen-build-check(1) blocked n/a test-amd64-amd64-xl-win 1 xen-build-check(1) blocked n/a test-amd64-amd64-xl 1 xen-build-check(1) blocked n/a test-i386-i386-xl-win 1 xen-build-check(1) blocked n/a test-i386-i386-win 1 xen-build-check(1) blocked n/a version targeted for testing: xen 0312575dc35e baseline version: xen 0312575dc35e jobs: build-amd64 pass build-i386 pass build-amd64-oldkern pass build-i386-oldkern pass build-amd64-pvops fail build-i386-pvops fail test-amd64-amd64-xl blocked test-amd64-i386-xl blocked test-i386-i386-xl blocked test-amd64-i386-rhel6hvm-amd blocked test-amd64-i386-xl-credit2 blocked test-amd64-amd64-xl-pcipt-intel blocked test-amd64-i386-rhel6hvm-intel blocked test-amd64-i386-xl-multivcpu blocked test-amd64-amd64-pair blocked test-amd64-i386-pair blocked test-i386-i386-pair blocked test-amd64-amd64-pv blocked test-amd64-i386-pv blocked test-i386-i386-pv blocked test-amd64-amd64-xl-sedf blocked test-amd64-i386-win-vcpus1 blocked test-amd64-i386-xl-win-vcpus1 blocked test-amd64-amd64-win blocked test-amd64-i386-win blocked test-i386-i386-win blocked test-amd64-amd64-xl-win blocked test-i386-i386-xl-win blocked ------------------------------------------------------------ sg-report-flight on woking.cam.xci-test.com logs: /home/xc_osstest/logs images: /home/xc_osstest/images Logs, config files, etc. are available at http://www.chiark.greenend.org.uk/~xensrcts/logs Test harness code can be found at http://xenbits.xensource.com/gitweb?p=osstest.git;a=summary Published tested tree is already up to date. _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel From xen-devel-bounces@lists.xensource.com Thu Sep 08 18:46:58 2011 Return-path: Envelope-to: www-data@lists.xensource.com Delivery-date: Thu, 08 Sep 2011 18:46:58 -0700 Received: from localhost ([127.0.0.1] helo=lists.colo.xensource.com) by lists.xensource.com with esmtp (Exim 4.43) id 1R1qBG-0001Fv-KS; Thu, 08 Sep 2011 18:46:58 -0700 Received: from mail27.messagelabs.com ([193.109.254.147]) by lists.xensource.com with smtp (Exim 4.43) id 1R1qAR-00013k-GE for xen-devel@lists.xensource.com; Thu, 08 Sep 2011 18:46:07 -0700 X-Env-Sender: hanweidong@huawei.com X-Msg-Ref: server-15.tower-27.messagelabs.com!1315532755!48009354!1 X-Originating-IP: [119.145.14.67] X-StarScan-Version: 6.3.6; banners=-,-,- X-VirusChecked: Checked Received: (qmail 24723 invoked from network); 9 Sep 2011 01:45:56 -0000 Received: from szxga04-in.huawei.com (HELO szxga04-in.huawei.com) (119.145.14.67) by server-15.tower-27.messagelabs.com with SMTP; 9 Sep 2011 01:45:56 -0000 Received: from huawei.com (szxga04-in [172.24.2.12]) by szxga04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0LR8006BIFKQKK@szxga04-in.huawei.com> for xen-devel@lists.xensource.com; Fri, 09 Sep 2011 09:46:02 +0800 (CST) Received: from szxrg01-dlp.huawei.com ([172.24.2.119]) by szxga04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0LR800EWRFKPSD@szxga04-in.huawei.com> for xen-devel@lists.xensource.com; Fri, 09 Sep 2011 09:46:02 +0800 (CST) Received: from szxeml205-edg.china.huawei.com ([172.24.2.119]) by szxrg01-dlp.huawei.com (MOS 4.1.9-GA) with ESMTP id ADW60678; Fri, 09 Sep 2011 09:46:01 +0800 Received: from SZXEML401-HUB.china.huawei.com (10.82.67.31) by szxeml205-edg.china.huawei.com (172.24.2.57) with Microsoft SMTP Server (TLS) id 14.1.270.1; Fri, 09 Sep 2011 09:45:55 +0800 Received: from [127.0.0.1] (10.142.102.129) by szxeml401-hub.china.huawei.com (10.82.67.31) with Microsoft SMTP Server id 14.1.270.1; Fri, 09 Sep 2011 09:45:59 +0800 Date: Fri, 09 Sep 2011 09:45:51 +0800 From: Weidong Han Subject: Re: Re : Re : Re : [Xen-devel] Re: Patches for VGA-Passthrough XEN 4.2 unstable In-reply-to: <1315399889.79555.YahooMailNeo@web29820.mail.ird.yahoo.com> X-Originating-IP: [10.142.102.129] To: David TECHER Message-id: <4E696FCF.3050407@huawei.com> MIME-version: 1.0 Content-type: text/plain; charset=ISO-8859-1; format=flowed Content-transfer-encoding: 8BIT User-Agent: Mozilla/5.0 (Windows NT 5.1; rv:6.0.1) Gecko/20110830 Thunderbird/6.0.1 X-CFilter-Loop: Reflected References: <1314778567400-4753326.post@n5.nabble.com> <20110831083832.GD7276@reaktio.net> <1314780568949-4753422.post@n5.nabble.com> <1314795401771-4754024.post@n5.nabble.com> <20110831151913.GE7276@reaktio.net> <1315231341254-4770602.post@n5.nabble.com> <1315310225039-4774097.post@n5.nabble.com> <1315343879.61837.YahooMailNeo@web29818.mail.ird.yahoo.com> <1315382742268-4777689.post@n5.nabble.com> <1315389138.56652.YahooMailNeo@web29801.mail.ird.yahoo.com> <1315398360680-4778339.post@n5.nabble.com> <1315399889.79555.YahooMailNeo@web29820.mail.ird.yahoo.com> Cc: komkon555 , "xen-devel@lists.xensource.com" X-BeenThere: xen-devel@lists.xensource.com X-Mailman-Version: 2.1.5 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xensource.com Errors-To: xen-devel-bounces@lists.xensource.com On 2011-9-7 20:51, David TECHER wrote: > It is a great pleasure to know that is it working for you :) > > I've just updated the patchs sent by 'JavMV' on May 2011. Even if I'am > not a Xen Developer > it will be a great idea if a real Xen Developer takes care of the patchs > to improve it for Xen 4.2. > > The next step was to understand how the patch for > 'tools/firmware/hvmloader/acpi/dsdt.asl' > works. Once I've understood, I've patched for my own graphic card. > > That's all. > > For my information, what kind of NVIDIA graphic card do you have? GT > 430?GT 440, GTX? > > Supporting several cards?I do not know how to do. > > My feeling is that using the same kind of manufacturer graphic card > would be possible > because qemu-dm could only support one kind of VGA BIOS. Guest needs VGA BIOS to initialize assigned graphics card in guest. qemu-dm only know how to copy video BIOS of primary graphics card which locates at 0xC0000, but don't know where are video BIOS of other graphics cards. if want to pass-through more than one graphics cards, must know how to get and load VGA BIOS to guest for other graphics cards. One method is to use tools such as NiBiTor to extract VGA BIOS from graphics card to a file, then load it to guest. Weidong > > I know that in 2009 a patch was done to support more cards but I've > tryid to updated it. > > > > ------------------------------------------------------------------------ > *De :* komkon555 > *À :* xen-devel@lists.xensource.com > *Envoyé le :* Mercredi 7 Septembre 2011 14h26 > *Objet :* Re: Re : Re : [Xen-devel] Re: Patches for VGA-Passthrough XEN > 4.2 unstable > > Perfect, with the latest fixes and configurations it works! I can run dxdiag > and see all tests functional. Important is, that cuda-programming is also > functional (is what I exactly need). Thank you a lot! The next problem is > how to pass through the second (third, fourth) nvidia card to the next one > Windows-VM? For me is most impotent to get 4 separate CUDA/OpenCL > programming areas. Have you any ideas? > > Tanks > Komkon555 > > > -- > View this message in context: > http://xen.1045712.n5.nabble.com/Patches-for-VGA-Passthrough-XEN-4-2-unstable-tp4406265p4778339.html > Sent from the Xen - Dev mailing list archive at Nabble.com. > > _______________________________________________ > Xen-devel mailing list > Xen-devel@lists.xensource.com > http://lists.xensource.com/xen-devel > > > > > _______________________________________________ > Xen-devel mailing list > Xen-devel@lists.xensource.com > http://lists.xensource.com/xen-devel _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel From xen-devel-bounces@lists.xensource.com Thu Sep 08 19:40:09 2011 Return-path: Envelope-to: www-data@lists.xensource.com Delivery-date: Thu, 08 Sep 2011 19:40:09 -0700 Received: from localhost ([127.0.0.1] helo=lists.colo.xensource.com) by lists.xensource.com with esmtp (Exim 4.43) id 1R1r0i-0002dd-J5; Thu, 08 Sep 2011 19:40:08 -0700 Received: from mail216.messagelabs.com ([85.158.143.99]) by lists.xensource.com with smtp (Exim 4.43) id 1R1qzt-0002QW-Fq for xen-devel@lists.xensource.com; Thu, 08 Sep 2011 19:39:17 -0700 X-Env-Sender: kaushik.barde@huawei.com X-Msg-Ref: server-5.tower-216.messagelabs.com!1315535953!17116868!1 X-Originating-IP: [206.16.17.180] X-StarScan-Version: 6.3.6; banners=-,-,- X-VirusChecked: Checked Received: (qmail 14796 invoked from network); 9 Sep 2011 02:39:14 -0000 Received: from usaga04-in.huawei.com (HELO usaga04-in.huawei.com) (206.16.17.180) by server-5.tower-216.messagelabs.com with SMTP; 9 Sep 2011 02:39:14 -0000 Received: from huawei.com (usaga04-in [172.18.4.101]) by usaga04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0LR8002CXI1D9S@usaga04-in.huawei.com> for xen-devel@lists.xensource.com; Thu, 08 Sep 2011 21:39:13 -0500 (CDT) Received: from dfweml201-edg.china.huawei.com ([172.18.4.104]) by usaga04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0LR8003R8I1CXN@usaga04-in.huawei.com> for xen-devel@lists.xensource.com; Thu, 08 Sep 2011 21:39:13 -0500 (CDT) Received: from DFWEML401-HUB.china.huawei.com (10.193.5.101) by dfweml201-edg.china.huawei.com (172.18.9.107) with Microsoft SMTP Server (TLS) id 14.1.270.1; Thu, 08 Sep 2011 19:39:06 -0700 Received: from DFWEML503-MBX.china.huawei.com ([169.254.3.37]) by DFWEML401-HUB.china.huawei.com ([fe80::f07f:889f:78ef:8df3%13]) with mapi id 14.01.0270.001; Thu, 08 Sep 2011 19:39:09 -0700 Date: Fri, 09 Sep 2011 02:39:08 +0000 From: Kaushik Barde Subject: RE: [Xen-devel] Whether xen will support intel atom cpu In-reply-to: <20110909010436.GA9060@dumpdata.com> X-Originating-IP: [172.18.9.109] To: Konrad Rzeszutek Wilk Message-id: <096341F6F9EB284DA012DAD3853CF02215ECB7B5@dfweml503-mbx.china.huawei.com> MIME-version: 1.0 Content-type: text/plain; charset=us-ascii Content-language: en-US Content-transfer-encoding: 7BIT Accept-Language: en-US Thread-topic: [Xen-devel] Whether xen will support intel atom cpu Thread-index: AQHMblFipReZsxQqDUGwase31bsw/JVEYK4AgAA5oQCAABdJAP//pLn0 X-MS-Has-Attach: X-MS-TNEF-Correlator: References: <012801cc6e80$cd7a37f0$686ea7d0$%barde@huawei.com> <20110909010436.GA9060@dumpdata.com> Cc: 'Keir Fraser' , "xen-devel@lists.xensource.com" , 'Maxim Kozhevnikov' X-BeenThere: xen-devel@lists.xensource.com X-Mailman-Version: 2.1.5 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xensource.com Errors-To: xen-devel-bounces@lists.xensource.com So is it also a Linux issue? ________________________________________ From: Konrad Rzeszutek Wilk [konrad.wilk@oracle.com] Sent: Thursday, September 08, 2011 6:04 PM To: Kaushik Barde Cc: 'Keir Fraser'; 'Maxim Kozhevnikov'; xen-devel@lists.xensource.com Subject: Re: [Xen-devel] Whether xen will support intel atom cpu On Thu, Sep 08, 2011 at 04:41:16PM -0700, Kaushik Barde wrote: > Agreed, Try installing vanilla linux on that unit and see if S3 works.. It won't. Please try the testing branch. git://oss.oracle.com/git/kwilk/xen.git #testing > > -Kaushik > -----Original Message----- > From: xen-devel-bounces@lists.xensource.com > [mailto:xen-devel-bounces@lists.xensource.com] On Behalf Of Keir Fraser > Sent: Thursday, September 08, 2011 1:15 PM > To: Maxim Kozhevnikov; xen-devel@lists.xensource.com > Subject: Re: [Xen-devel] Whether xen will support intel atom cpu > > On 08/09/2011 18:59, "Maxim Kozhevnikov" wrote: > > > I have pc with intel atom cpu. > And When use xen i got the following error: > > > "Performance Events : unsupported p6 CPU model 28 no PMU driver, software > > This message has absolutely nothing to do with support for ACPI S3 (suspend > to ram). > > -- Keir > > > events only." > So, i can use suspend to ram but can't use wake up from ram on > > my pc. > Please, tell me, when xen will support intel atom cpu? > I use > > xen-unstable (4.2) > > _______________________________________________ > > Xen-devel mailing list > > Xen-devel@lists.xensource.com > > http://lists.xensource.com/xen-devel > > > > _______________________________________________ > Xen-devel mailing list > Xen-devel@lists.xensource.com > http://lists.xensource.com/xen-devel > > > _______________________________________________ > Xen-devel mailing list > Xen-devel@lists.xensource.com > http://lists.xensource.com/xen-devel _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel From xen-devel-bounces@lists.xensource.com Thu Sep 08 19:45:39 2011 Return-path: Envelope-to: www-data@lists.xensource.com Delivery-date: Thu, 08 Sep 2011 19:45:39 -0700 Received: from localhost ([127.0.0.1] helo=lists.colo.xensource.com) by lists.xensource.com with esmtp (Exim 4.43) id 1R1r63-0003Ly-0p; Thu, 08 Sep 2011 19:45:39 -0700 Received: from mail216.messagelabs.com ([85.158.143.99]) by lists.xensource.com with esmtp (Exim 4.43) id 1R1r5U-00039l-Vd for xen-devel@lists.xensource.com; Thu, 08 Sep 2011 19:45:05 -0700 X-Env-Sender: konrad@dumpdata.com X-Msg-Ref: server-7.tower-216.messagelabs.com!1315536300!17609596!1 X-Originating-IP: [141.146.126.227] X-StarScan-Version: 6.3.6; banners=-,-,- X-VirusChecked: Checked Received: (qmail 2255 invoked from network); 9 Sep 2011 02:45:01 -0000 Received: from acsinet15.oracle.com (HELO acsinet15.oracle.com) (141.146.126.227) by server-7.tower-216.messagelabs.com with DHE-RSA-AES256-SHA encrypted SMTP; 9 Sep 2011 02:45:01 -0000 Received: from rtcsinet22.oracle.com (rtcsinet22.oracle.com [66.248.204.30]) by acsinet15.oracle.com (Switch-3.4.4/Switch-3.4.4) with ESMTP id p892iM9s009069 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Fri, 9 Sep 2011 02:44:24 GMT Received: from acsmt356.oracle.com (acsmt356.oracle.com [141.146.40.156]) by rtcsinet22.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id p892iLEo003732 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 9 Sep 2011 02:44:21 GMT Received: from abhmt108.oracle.com (abhmt108.oracle.com [141.146.116.60]) by acsmt356.oracle.com (8.12.11.20060308/8.12.11) with ESMTP id p892iFJa023556; Thu, 8 Sep 2011 21:44:15 -0500 Received: from phenom (/209.6.55.207) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Thu, 08 Sep 2011 19:44:15 -0700 Received: by phenom (Postfix, from userid 1000) id 41522139B; Thu, 8 Sep 2011 22:44:00 -0400 (EDT) Date: Thu, 8 Sep 2011 22:44:00 -0400 From: Konrad Rzeszutek Wilk To: Kaushik Barde Subject: Re: [Xen-devel] Whether xen will support intel atom cpu Message-ID: <20110909024400.GA13146@dumpdata.com> References: <012801cc6e80$cd7a37f0$686ea7d0$%barde@huawei.com> <20110909010436.GA9060@dumpdata.com> <096341F6F9EB284DA012DAD3853CF02215ECB7B5@dfweml503-mbx.china.huawei.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <096341F6F9EB284DA012DAD3853CF02215ECB7B5@dfweml503-mbx.china.huawei.com> User-Agent: Mutt/1.5.21 (2010-09-15) X-Source-IP: rtcsinet22.oracle.com [66.248.204.30] X-CT-RefId: str=0001.0A090209.4E697D89.0038,ss=1,re=0.000,fgs=0 Cc: 'Keir Fraser' , "xen-devel@lists.xensource.com" , 'Maxim Kozhevnikov' X-BeenThere: xen-devel@lists.xensource.com X-Mailman-Version: 2.1.5 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xensource.com Errors-To: xen-devel-bounces@lists.xensource.com On Fri, Sep 09, 2011 at 02:39:08AM +0000, Kaushik Barde wrote: > So is it also a Linux issue? I am not really sure what you are saying. The issue he is hitting is that he is trying to use ACPI S3 with Xen. But ACPI S3 won't work with Xen b/c the patches to enable that are not upstream yet. But they are in the #testing branch. > > ________________________________________ > From: Konrad Rzeszutek Wilk [konrad.wilk@oracle.com] > Sent: Thursday, September 08, 2011 6:04 PM > To: Kaushik Barde > Cc: 'Keir Fraser'; 'Maxim Kozhevnikov'; xen-devel@lists.xensource.com > Subject: Re: [Xen-devel] Whether xen will support intel atom cpu > > On Thu, Sep 08, 2011 at 04:41:16PM -0700, Kaushik Barde wrote: > > Agreed, Try installing vanilla linux on that unit and see if S3 works.. > > It won't. Please try the testing branch. > > git://oss.oracle.com/git/kwilk/xen.git #testing > > > > > -Kaushik > > -----Original Message----- > > From: xen-devel-bounces@lists.xensource.com > > [mailto:xen-devel-bounces@lists.xensource.com] On Behalf Of Keir Fraser > > Sent: Thursday, September 08, 2011 1:15 PM > > To: Maxim Kozhevnikov; xen-devel@lists.xensource.com > > Subject: Re: [Xen-devel] Whether xen will support intel atom cpu > > > > On 08/09/2011 18:59, "Maxim Kozhevnikov" wrote: > > > > > I have pc with intel atom cpu. > > And When use xen i got the following error: > > > > > "Performance Events : unsupported p6 CPU model 28 no PMU driver, software > > > > This message has absolutely nothing to do with support for ACPI S3 (suspend > > to ram). > > > > -- Keir > > > > > events only." > > So, i can use suspend to ram but can't use wake up from ram on > > > my pc. > > Please, tell me, when xen will support intel atom cpu? > > I use > > > xen-unstable (4.2) > > > _______________________________________________ > > > Xen-devel mailing list > > > Xen-devel@lists.xensource.com > > > http://lists.xensource.com/xen-devel > > > > > > > > _______________________________________________ > > Xen-devel mailing list > > Xen-devel@lists.xensource.com > > http://lists.xensource.com/xen-devel > > > > > > _______________________________________________ > > Xen-devel mailing list > > Xen-devel@lists.xensource.com > > http://lists.xensource.com/xen-devel _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel From xen-devel-bounces@lists.xensource.com Thu Sep 08 19:50:11 2011 Return-path: Envelope-to: www-data@lists.xensource.com Delivery-date: Thu, 08 Sep 2011 19:50:11 -0700 Received: from localhost ([127.0.0.1] helo=lists.colo.xensource.com) by lists.xensource.com with esmtp (Exim 4.43) id 1R1rAQ-0003mR-AO; Thu, 08 Sep 2011 19:50:10 -0700 Received: from mail182.messagelabs.com ([85.158.139.83]) by lists.xensource.com with smtp (Exim 4.43) id 1R1r9r-0003ZJ-VA for xen-devel@lists.xensource.com; Thu, 08 Sep 2011 19:49:36 -0700 X-Env-Sender: kaushik.barde@huawei.com X-Msg-Ref: server-8.tower-182.messagelabs.com!1315536572!17639513!1 X-Originating-IP: [206.16.17.180] X-StarScan-Version: 6.3.6; banners=-,-,- X-VirusChecked: Checked Received: (qmail 12506 invoked from network); 9 Sep 2011 02:49:32 -0000 Received: from usaga04-in.huawei.com (HELO usaga04-in.huawei.com) (206.16.17.180) by server-8.tower-182.messagelabs.com with SMTP; 9 Sep 2011 02:49:32 -0000 Received: from huawei.com (usaga04-in [172.18.4.101]) by usaga04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0LR80022RIIJ9S@usaga04-in.huawei.com> for xen-devel@lists.xensource.com; Thu, 08 Sep 2011 21:49:31 -0500 (CDT) Received: from dfweml202-edg.china.huawei.com ([172.18.4.104]) by usaga04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0LR8003H0IIJXN@usaga04-in.huawei.com> for xen-devel@lists.xensource.com; Thu, 08 Sep 2011 21:49:31 -0500 (CDT) Received: from DFWEML401-HUB.china.huawei.com (10.193.5.101) by dfweml202-edg.china.huawei.com (172.18.9.108) with Microsoft SMTP Server (TLS) id 14.1.270.1; Thu, 08 Sep 2011 19:49:34 -0700 Received: from DFWEML503-MBX.china.huawei.com ([169.254.3.37]) by DFWEML401-HUB.china.huawei.com ([fe80::f07f:889f:78ef:8df3%13]) with mapi id 14.01.0270.001; Thu, 08 Sep 2011 19:49:29 -0700 Date: Fri, 09 Sep 2011 02:49:27 +0000 From: Kaushik Barde Subject: RE: [Xen-devel] Whether xen will support intel atom cpu In-reply-to: <20110909024400.GA13146@dumpdata.com> X-Originating-IP: [172.18.9.109] To: Konrad Rzeszutek Wilk Message-id: <096341F6F9EB284DA012DAD3853CF02215ECB7F1@dfweml503-mbx.china.huawei.com> MIME-version: 1.0 Content-type: text/plain; charset=us-ascii Content-language: en-US Content-transfer-encoding: 7BIT Accept-Language: en-US Thread-topic: [Xen-devel] Whether xen will support intel atom cpu Thread-index: AQHMblFipReZsxQqDUGwase31bsw/JVEYK4AgAA5oQCAABdJAP//pLn0gAB3DAD//4sbCA== X-MS-Has-Attach: X-MS-TNEF-Correlator: References: <012801cc6e80$cd7a37f0$686ea7d0$%barde@huawei.com> <20110909010436.GA9060@dumpdata.com> <096341F6F9EB284DA012DAD3853CF02215ECB7B5@dfweml503-mbx.china.huawei.com> <20110909024400.GA13146@dumpdata.com> Cc: 'Keir Fraser' , "xen-devel@lists.xensource.com" , 'Maxim Kozhevnikov' X-BeenThere: xen-devel@lists.xensource.com X-Mailman-Version: 2.1.5 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xensource.com Errors-To: xen-devel-bounces@lists.xensource.com well, Maxim tried S3 with Xen on this atom system it did not resume, so I suggested trying vanilla linux on the same system. If Linux works then issue could be with xen/dom-0 else something native with the system. ________________________________________ From: Konrad Rzeszutek Wilk [konrad.wilk@oracle.com] Sent: Thursday, September 08, 2011 7:44 PM To: Kaushik Barde Cc: 'Keir Fraser'; 'Maxim Kozhevnikov'; xen-devel@lists.xensource.com Subject: Re: [Xen-devel] Whether xen will support intel atom cpu On Fri, Sep 09, 2011 at 02:39:08AM +0000, Kaushik Barde wrote: > So is it also a Linux issue? I am not really sure what you are saying. The issue he is hitting is that he is trying to use ACPI S3 with Xen. But ACPI S3 won't work with Xen b/c the patches to enable that are not upstream yet. But they are in the #testing branch. > > ________________________________________ > From: Konrad Rzeszutek Wilk [konrad.wilk@oracle.com] > Sent: Thursday, September 08, 2011 6:04 PM > To: Kaushik Barde > Cc: 'Keir Fraser'; 'Maxim Kozhevnikov'; xen-devel@lists.xensource.com > Subject: Re: [Xen-devel] Whether xen will support intel atom cpu > > On Thu, Sep 08, 2011 at 04:41:16PM -0700, Kaushik Barde wrote: > > Agreed, Try installing vanilla linux on that unit and see if S3 works.. > > It won't. Please try the testing branch. > > git://oss.oracle.com/git/kwilk/xen.git #testing > > > > > -Kaushik > > -----Original Message----- > > From: xen-devel-bounces@lists.xensource.com > > [mailto:xen-devel-bounces@lists.xensource.com] On Behalf Of Keir Fraser > > Sent: Thursday, September 08, 2011 1:15 PM > > To: Maxim Kozhevnikov; xen-devel@lists.xensource.com > > Subject: Re: [Xen-devel] Whether xen will support intel atom cpu > > > > On 08/09/2011 18:59, "Maxim Kozhevnikov" wrote: > > > > > I have pc with intel atom cpu. > > And When use xen i got the following error: > > > > > "Performance Events : unsupported p6 CPU model 28 no PMU driver, software > > > > This message has absolutely nothing to do with support for ACPI S3 (suspend > > to ram). > > > > -- Keir > > > > > events only." > > So, i can use suspend to ram but can't use wake up from ram on > > > my pc. > > Please, tell me, when xen will support intel atom cpu? > > I use > > > xen-unstable (4.2) > > > _______________________________________________ > > > Xen-devel mailing list > > > Xen-devel@lists.xensource.com > > > http://lists.xensource.com/xen-devel > > > > > > > > _______________________________________________ > > Xen-devel mailing list > > Xen-devel@lists.xensource.com > > http://lists.xensource.com/xen-devel > > > > > > _______________________________________________ > > Xen-devel mailing list > > Xen-devel@lists.xensource.com > > http://lists.xensource.com/xen-devel _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel From xen-devel-bounces@lists.xensource.com Thu Sep 08 23:00:46 2011 Return-path: Envelope-to: www-data@lists.xensource.com Delivery-date: Thu, 08 Sep 2011 23:00:46 -0700 Received: from localhost ([127.0.0.1] helo=lists.colo.xensource.com) by lists.xensource.com with esmtp (Exim 4.43) id 1R1u8s-0006Ns-5e; Thu, 08 Sep 2011 23:00:46 -0700 Received: from mail216.messagelabs.com ([85.158.143.99]) by lists.xensource.com with smtp (Exim 4.43) id 1R1u81-0006Ay-04 for xen-devel@lists.xensource.com; Thu, 08 Sep 2011 22:59:53 -0700 X-Env-Sender: andreas.olsowski@leuphana.de X-Msg-Ref: server-12.tower-216.messagelabs.com!1315547989!11880563!1 X-Originating-IP: [193.174.46.71] X-StarScan-Version: 6.3.6; banners=-,-,- X-VirusChecked: Checked Received: (qmail 3220 invoked from network); 9 Sep 2011 05:59:49 -0000 Received: from mailhost.leuphana.de (HELO leuphana.de) (193.174.46.71) by server-12.tower-216.messagelabs.com with SMTP; 9 Sep 2011 05:59:49 -0000 Received: from [195.37.28.33] (account aolsowsk@leuphana.de [195.37.28.33] verified) by leuphana.de (CommuniGate Pro SMTP 5.4.1e) with ESMTPSA id 44912178; Fri, 09 Sep 2011 07:59:47 +0200 Message-ID: <4E69AB53.5010702@leuphana.de> Date: Fri, 09 Sep 2011 07:59:47 +0200 From: Andreas Olsowski User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.2.18) Gecko/20110626 Icedove/3.1.11 MIME-Version: 1.0 To: Konrad Rzeszutek Wilk Subject: Re: [Xen-devel] xen/stable-2.6.32.x xen-4.1.1 live migration fails with kernels 2.6.39, 3.0.3 and 3.1-rc2 References: <4E52601B.5060609@leuphana.de> <20110824203435.GA27865@dumpdata.com> <4E55F682.8060405@leuphana.de> <20110826150054.GA1793@dumpdata.com> <4E57D745.2080701@leuphana.de> <20110829194911.GC16530@dumpdata.com> <4E5E320A.60401@leuphana.de> <20110907135046.GD32190@dumpdata.com> <20110908173212.GA17026@dumpdata.com> <20110908181227.GB19078@dumpdata.com> <20110908195031.GA21186@dumpdata.com> In-Reply-To: <20110908195031.GA21186@dumpdata.com> Cc: "xen-devel@lists.xensource.com" X-BeenThere: xen-devel@lists.xensource.com X-Mailman-Version: 2.1.5 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0322138462==" Sender: xen-devel-bounces@lists.xensource.com Errors-To: xen-devel-bounces@lists.xensource.com This is a cryptographically signed message in MIME format. --===============0322138462== Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha1; boundary="------------ms060600090906020307000802" This is a cryptographically signed message in MIME format. --------------ms060600090906020307000802 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: quoted-printable On 09/08/2011 09:50 PM, Konrad Rzeszutek Wilk wrote: > On Thu, Sep 08, 2011 at 02:12:27PM -0400, Konrad Rzeszutek Wilk wrote: >> On Thu, Sep 08, 2011 at 01:32:12PM -0400, Konrad Rzeszutek Wilk wrote:= >>> On Wed, Sep 07, 2011 at 09:50:47AM -0400, Konrad Rzeszutek Wilk wrote= : >>>> On Wed, Aug 31, 2011 at 03:07:22PM +0200, Andreas Olsowski wrote: >>>>> A little update, i now have all machines running on xen-4.1-testing= >>>>> with xen/stable-2.6.32.x >>>>> That gave me the possiblity for additional tests. >>>>> >>>>> (I also tested xm/xend in addtion to xl/libxl, to make sure its not= >>>>> a xl/libxl problem.) >>>>> >>>>> I took the liberty to create a new test result matrix that should >>>>> provide a better overview (in case someone else wants to get the >>>>> whole picture): >>>> >>>> So.. I don't think the issue I am seeing is exactly the same. This i= s >>>> what 'xl' gives me: >>> >>> Scratch that. I am seeing the error below if I: >>> >>> 1) Create guest on 4GB machine >>> 2) Migrate it to the 32GB box (guest still works) >>> 3) Migrate it to the 4GB box (guest dies - error below shows up and >>> guest is dead). >>> >>> With 3.1-rc5 virgin - both Dom0 and DomU. Also Xen 4.1-testing on top= of this. >>> >>> I tried just creating a guest on the 32GB and migrating it - and whil= e >>> it did migrate it was stuck in a hypercall_page call or crashed later= on. >>> >>> Andreas, >>> >>> Thanks for reporting this. >> >> Oh wait. At some point you said that 2.6.32.43 worked for you.. Is tha= t still >> the case? > (Ignore e-mail from a few minutes ago, accidentally did not reply-all) Did I? I will have to check my sent emails, but im pretty sure that if i = found a way that works i normally would use it. But i can try an older version later today. Btw. allthough you get the same error as i do, the circumstances are=20 slightly different. This does not neccessarily have sth to todo with the amount of memory. I do see this on hosts where both have the same amount of ram but are a=20 different hardware platform. > > Can you please try one thing for me - can you make sure the boxes have = exact same > amount of memory? You can do 'mem=3DX' on the Xen hypervisor line to se= t that. Running mem=3D8g and have turned balooning dom0 off. multiboot /boot/xen.gz placeholder dom0_mem=3D8192M module /boot/vmlinuz-2.6.32.45-xen0 placeholder=20 root=3DUUID=3D216ff902-b505-45c4-9bcb-9d63b4cb8992 ro mem=3D8G nomodese= t=20 console=3Dtty0 console=3DttyS1,57600 earlyprintk=3Dxen For some reason though, the two r610s show: root@netcatarina:~# cat /proc/meminfo MemTotal: 8378236 kB root@netcatarina:~# xl list |grep Domain-0 Domain-0 0 7445 8 r-----=20 124304.7 root@memoryana:~# cat /proc/meminfo MemTotal: 8378236 kB root@memoryana:~# xl list |grep Domain-0 Domain-0 0 7445 8 r-----=20 132125.0 wheras the r710: root@tarballerina:~# cat /proc/meminfo MemTotal: 7886716 kB root@tarballerina:~# xl list |grep Domain-0 Domain-0 0 7221 8 r-----=20 64497.0 On a sidenote: root@tarballerina:~# xl mem-set Domain-0 8192 libxl: error: libxl.c:2119:libxl_set_memory_target cannot get memory=20 info from /local/domain/0/memory/static-max : No such file or directory The two r610s can xl set their memory just fine > > I think the problem you are running into is that you are migrating betw= een > different CPU families... Is the /proc/cpuinfo drastically different be= tween > the boxes? diff: < model : 26 < model name : Intel(R) Xeon(R) CPU E5520 @ 2.27GHz < stepping : 5 < cpu MHz : 2261.074 < cache size : 8192 KB --- > model : 44 > model name : Intel(R) Xeon(R) CPU E5640 @ 2.67GHz > stepping : 2 > cpu MHz : 2660.050 > cache size : 12288 KB 13,14c13,14 < flags : fpu de tsc msr pae mce cx8 apic sep mtrr mca cmov pat clflush = acpi mmx fxsr sse sse2 ss ht syscall nx lm constant_tsc rep_good=20 nonstop_tsc aperfmperf pni est ssse3 cx16 sse4_1 sse4_2 popcnt=20 hypervisor lahf_lm ida < bogomips : 4522.14 --- > flags : fpu de tsc msr pae mce cx8 apic sep mtrr mca cmov pat=20 clflush acpi mmx fxsr sse sse2 ss ht syscall lm constant_tsc rep_good=20 nonstop_tsc aperfmperf pni pclmulqdq est ssse3 cx16 sse4_1 sse4_2 popcnt = aes hypervisor lahf_lm ida arat > bogomips : 5320.10 diffrent flags are: nx and aes And thats r610 and r710. The cpu in the 2950 is older, a completely=20 different platform, different chipset, no on-chip memory controller. --=20 Andreas Olsowski Leuphana Universit=E4t L=FCneburg Rechen- und Medienzentrum Scharnhorststra=DFe 1, C7.015 21335 L=FCneburg Tel: ++49 4131 677 1309 --------------ms060600090906020307000802 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIU3TCC BCEwggMJoAMCAQICAgDHMA0GCSqGSIb3DQEBBQUAMHExCzAJBgNVBAYTAkRFMRwwGgYDVQQK ExNEZXV0c2NoZSBUZWxla29tIEFHMR8wHQYDVQQLExZULVRlbGVTZWMgVHJ1c3QgQ2VudGVy MSMwIQYDVQQDExpEZXV0c2NoZSBUZWxla29tIFJvb3QgQ0EgMjAeFw0wNjEyMTkxMDI5MDBa Fw0xOTA2MzAyMzU5MDBaMFoxCzAJBgNVBAYTAkRFMRMwEQYDVQQKEwpERk4tVmVyZWluMRAw DgYDVQQLEwdERk4tUEtJMSQwIgYDVQQDExtERk4tVmVyZWluIFBDQSBHbG9iYWwgLSBHMDEw ggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQDpm8NnhfkNrvWNVMOWUDU9YuluTO2U 1wBblSJ01CDrNI/W7MAxBAuZgeKmFNJSoCgjhIt0iQReW+DieMF4yxbLKDU5ey2QRdDtoAB6 fL9KDhsAw4bpXCsxEXsM84IkQ4wcOItqaACa7txPeKvSxhObdq3u3ibo7wGvdA/BCaL2a869 080UME/15eOkyGKbghoDJzANAmVgTe3RCSMqljVYJ9N2xnG2kB3E7f81hn1vM7PbD8URwoqD oZRdQWvY0hD1TP3KUazZve+Sg7va64sWVlZDz+HVEz2mHycwzUlU28kTNJpxdcVs6qcLmPkh nSevPqM5OUhqjK3JmfvDEvK9AgMBAAGjgdkwgdYwcAYDVR0fBGkwZzBloGOgYYZfaHR0cDov L3BraS50ZWxlc2VjLmRlL2NnaS1iaW4vc2VydmljZS9hZl9Eb3dubG9hZEFSTC5jcmw/LWNy bF9mb3JtYXQ9WF81MDkmLWlzc3Vlcj1EVF9ST09UX0NBXzIwHQYDVR0OBBYEFEm3xs/oPR9/ 6kR7Eyn38QpwPt5kMB8GA1UdIwQYMBaAFDHDeRu69VPXF+CJei0XbAqzK50zMA4GA1UdDwEB /wQEAwIBBjASBgNVHRMBAf8ECDAGAQH/AgECMA0GCSqGSIb3DQEBBQUAA4IBAQA74Vp3wEgX 3KkY7IGvWonwvSiSpspZGBJw7Cjy565/lizn8l0ZMfYTK3S9vYCyufdnyTmieTvhERHua3iR M347XyYndVNljjNj7s9zw7CSI0khUHUjoR8Y4pSFPT8z6XcgjaK95qGFKUD2P3MyWA0Ja6ba hWzAP7uNZmRWJE6uDT8yNQFb6YyC2XJZT7GGhfF0hVblw/hc843uR7NTBXDn5U2KaYMo4RMJ hp5eyOpYHgwf+aTUWgRo/Sg+iwK2WLX2oSw3VwBnqyNojWOl75lrXP1LVvarQIc01BGSbOyH xQoLBzNytG8MHVQs2FHHzL8w00Ny8TK/jM5JY6gA9/IcMIIFXjCCBEagAwIBAgIEC8pR1jAN BgkqhkiG9w0BAQUFADBaMQswCQYDVQQGEwJERTETMBEGA1UEChMKREZOLVZlcmVpbjEQMA4G A1UECxMHREZOLVBLSTEkMCIGA1UEAxMbREZOLVZlcmVpbiBQQ0EgR2xvYmFsIC0gRzAxMB4X DTA4MDIwNzA5NTAwMFoXDTE5MDYzMDAwMDAwMFowgdMxCzAJBgNVBAYTAkRFMRYwFAYDVQQI Ew1OaWVkZXJzYWNoc2VuMRIwEAYDVQQHEwlMdWVuZWJ1cmcxKDAmBgNVBAoTH0xldXBoYW5h IFVuaXZlcnNpdGFldCBMdWVuZWJ1cmcxIjAgBgNVBAsTGVJlY2hlbi0gdW5kIE1lZGllbnpl bnRydW0xKzApBgNVBAMTIkxldXBoYW5hIFVuaXZlcnNpdGFldCBMdWVuZWJ1cmcgQ0ExHTAb BgkqhkiG9w0BCQEWDmNhQGxldXBoYW5hLmRlMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIB CgKCAQEAqJ+JpHih32+icKiQ2IkbhmFLjAcnK0vrnyOKbn7+1xywhvL3zkraqhQlrqEltTDy 711vIEadOVfhIx8xZYYJ/zg1OCwKUxNbIbjcsIFiOKNbWxI3/yMOsaZpXsCLW7GfHLlLADW1 Cv2gUAdnjJUATcUF3a25Bgr9Lbv+GI+3bY9ydMkGnhFYSL96LLqLxAXzGXL/MAM5t/xK8cc8 +6+mWxHAqO+85Jn+UvS1khVTtZfACrYZKFnAsVHOMM/WRugohq4ue6Jfp65exMM7HKWNPrKn UV0hotcInKFBYywcZrIa2r/6m63nOxl1gHrewxiFWEBvpgMkQ+a7PHhXsMkPdQIDAQABo4IB sDCCAawwEgYDVR0TAQH/BAgwBgEB/wIBATALBgNVHQ8EBAMCAQYwHQYDVR0OBBYEFPThaBk7 GUPHATbRNGKW8/UDoQeMMB8GA1UdIwQYMBaAFEm3xs/oPR9/6kR7Eyn38QpwPt5kMBkGA1Ud EQQSMBCBDmNhQGxldXBoYW5hLmRlMIGIBgNVHR8EgYAwfjA9oDugOYY3aHR0cDovL2NkcDEu cGNhLmRmbi5kZS9nbG9iYWwtcm9vdC1jYS9wdWIvY3JsL2NhY3JsLmNybDA9oDugOYY3aHR0 cDovL2NkcDIucGNhLmRmbi5kZS9nbG9iYWwtcm9vdC1jYS9wdWIvY3JsL2NhY3JsLmNybDCB ogYIKwYBBQUHAQEEgZUwgZIwRwYIKwYBBQUHMAKGO2h0dHA6Ly9jZHAxLnBjYS5kZm4uZGUv Z2xvYmFsLXJvb3QtY2EvcHViL2NhY2VydC9jYWNlcnQuY3J0MEcGCCsGAQUFBzAChjtodHRw Oi8vY2RwMi5wY2EuZGZuLmRlL2dsb2JhbC1yb290LWNhL3B1Yi9jYWNlcnQvY2FjZXJ0LmNy dDANBgkqhkiG9w0BAQUFAAOCAQEAmSFLUEnTM1zmNRfF4TTDRB53iHmBY0OYTlaPJvXXy4f7 jc1Dpz00HiVyFohY9gqo+jbIAm5avSCmhbL9glEWubE/BNZz9l9lyTCMMxFES0TCiC6W86Ev o9E4C5IEqxZAOlvRyM3w3u8ItBO9cG190/XMi1Ouk3iBfwRVvFINy9Favq+/8HWFwkFrphpy 6JR90AbbjtE7b7owcMxusgFtPi8A1uyc3cpR21f51K7qgmGbsyXso+U9c/8Fak0IM0qQTN7p GPmI1lfJ0x1r/QusHVYSFojAT2vQamfGeCNVELg/gH4tlTGkDbHW5QhInkASQv4obBYewNfR rLG4wgPz5TCCBacwggSPoAMCAQICBBDuKTAwDQYJKoZIhvcNAQEFBQAwgdMxCzAJBgNVBAYT AkRFMRYwFAYDVQQIEw1OaWVkZXJzYWNoc2VuMRIwEAYDVQQHEwlMdWVuZWJ1cmcxKDAmBgNV BAoTH0xldXBoYW5hIFVuaXZlcnNpdGFldCBMdWVuZWJ1cmcxIjAgBgNVBAsTGVJlY2hlbi0g dW5kIE1lZGllbnplbnRydW0xKzApBgNVBAMTIkxldXBoYW5hIFVuaXZlcnNpdGFldCBMdWVu ZWJ1cmcgQ0ExHTAbBgkqhkiG9w0BCQEWDmNhQGxldXBoYW5hLmRlMB4XDTEwMTEwMTExNTky OVoXDTEzMTAzMTExNTkyOVowajELMAkGA1UEBhMCREUxKDAmBgNVBAoTH0xldXBoYW5hIFVu aXZlcnNpdGFldCBMdWVuZWJ1cmcxFjAUBgNVBAsTDVJlY2hlbnplbnRydW0xGTAXBgNVBAMT EEFuZHJlYXMgT2xzb3dza2kwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQDBzfnZ 7pbsecrmresa6JNTMmgoBFpwyr7k7U5O+j7QlFvMlePF/Tz7TeULaEevf7H68IiA/6oGZQvg NReD/64PYXxbKfsJydY6W1K+jq2karofhW5bk5p210DEQv4qyV6M+aJRKxW0Hp32OeLk5QUH 9T2780PELXGn222r+NCSmBKLP0MHsUa6CFI+jRqztB60v+wc9TD6crMEB37ddckq7mS3QWk1 m2/68bmCsHWRLTpWn9hT4S8eBSL/3YLR9DF8kfWl0wEgy8/tJY1nz5IlSI3S2v1ys7rwXBAp YHRpeHM/WNNNV4kiH09g2vlxFebQN0xTyoO1+PX6iPeAh0NbAgMBAAGjggHpMIIB5TAJBgNV HRMEAjAAMAsGA1UdDwQEAwIF4DApBgNVHSUEIjAgBggrBgEFBQcDAgYIKwYBBQUHAwQGCisG AQQBgjcUAgIwHQYDVR0OBBYEFMrca499fLnPczMLjRm2Nck06YCyMB8GA1UdIwQYMBaAFPTh aBk7GUPHATbRNGKW8/UDoQeMMCcGA1UdEQQgMB6BHGFuZHJlYXMub2xzb3dza2lAbGV1cGhh bmEuZGUwgY0GA1UdHwSBhTCBgjA/oD2gO4Y5aHR0cDovL2NkcDEucGNhLmRmbi5kZS91bmkt bHVlbmVidXJnLWNhL3B1Yi9jcmwvY2FjcmwuY3JsMD+gPaA7hjlodHRwOi8vY2RwMi5wY2Eu ZGZuLmRlL3VuaS1sdWVuZWJ1cmctY2EvcHViL2NybC9jYWNybC5jcmwwgaYGCCsGAQUFBwEB BIGZMIGWMEkGCCsGAQUFBzAChj1odHRwOi8vY2RwMS5wY2EuZGZuLmRlL3VuaS1sdWVuZWJ1 cmctY2EvcHViL2NhY2VydC9jYWNlcnQuY3J0MEkGCCsGAQUFBzAChj1odHRwOi8vY2RwMi5w Y2EuZGZuLmRlL3VuaS1sdWVuZWJ1cmctY2EvcHViL2NhY2VydC9jYWNlcnQuY3J0MA0GCSqG SIb3DQEBBQUAA4IBAQANa3ZG/UAmpRcAXqOFOKXBfzN9vZilIdAUxSaXzN9gmXBNptDEcLfD ccoA228Qc0BSdpvqMdE/21ahqE6oYI1CTfqbuYdoi/cmGoXo6+MdKCKxAD9LokkHdZFhr8re NrsVkqxyY++Cek777HKZWn1Ft9864LA6vDar3K/sUHlBNxO6VhVzt09NQIFrA50lCkNd6iCG 7Hji624SI49aWjzysBOBdcP68tzSYM+nJLod1NZ3S/W3v+IlPlMeu1JZ5hRnzoTC5qHKKdoQ kwSmQmv8/uXD46TXutmLXxH3SyBUIM4ks6RN8+VbJ9+61nOQjtazZzvgz9cnYquQC9Dm2s+q MIIFpzCCBI+gAwIBAgIEEO4pMDANBgkqhkiG9w0BAQUFADCB0zELMAkGA1UEBhMCREUxFjAU BgNVBAgTDU5pZWRlcnNhY2hzZW4xEjAQBgNVBAcTCUx1ZW5lYnVyZzEoMCYGA1UEChMfTGV1 cGhhbmEgVW5pdmVyc2l0YWV0IEx1ZW5lYnVyZzEiMCAGA1UECxMZUmVjaGVuLSB1bmQgTWVk aWVuemVudHJ1bTErMCkGA1UEAxMiTGV1cGhhbmEgVW5pdmVyc2l0YWV0IEx1ZW5lYnVyZyBD QTEdMBsGCSqGSIb3DQEJARYOY2FAbGV1cGhhbmEuZGUwHhcNMTAxMTAxMTE1OTI5WhcNMTMx MDMxMTE1OTI5WjBqMQswCQYDVQQGEwJERTEoMCYGA1UEChMfTGV1cGhhbmEgVW5pdmVyc2l0 YWV0IEx1ZW5lYnVyZzEWMBQGA1UECxMNUmVjaGVuemVudHJ1bTEZMBcGA1UEAxMQQW5kcmVh cyBPbHNvd3NraTCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAMHN+dnulux5yuat 6xrok1MyaCgEWnDKvuTtTk76PtCUW8yV48X9PPtN5QtoR69/sfrwiID/qgZlC+A1F4P/rg9h fFsp+wnJ1jpbUr6OraRquh+FbluTmnbXQMRC/irJXoz5olErFbQenfY54uTlBQf1PbvzQ8Qt cafbbav40JKYEos/QwexRroIUj6NGrO0HrS/7Bz1MPpyswQHft11ySruZLdBaTWbb/rxuYKw dZEtOlaf2FPhLx4FIv/dgtH0MXyR9aXTASDLz+0ljWfPkiVIjdLa/XKzuvBcEClgdGl4cz9Y 001XiSIfT2Da+XEV5tA3TFPKg7X49fqI94CHQ1sCAwEAAaOCAekwggHlMAkGA1UdEwQCMAAw CwYDVR0PBAQDAgXgMCkGA1UdJQQiMCAGCCsGAQUFBwMCBggrBgEFBQcDBAYKKwYBBAGCNxQC AjAdBgNVHQ4EFgQUytxrj318uc9zMwuNGbY1yTTpgLIwHwYDVR0jBBgwFoAU9OFoGTsZQ8cB NtE0Ypbz9QOhB4wwJwYDVR0RBCAwHoEcYW5kcmVhcy5vbHNvd3NraUBsZXVwaGFuYS5kZTCB jQYDVR0fBIGFMIGCMD+gPaA7hjlodHRwOi8vY2RwMS5wY2EuZGZuLmRlL3VuaS1sdWVuZWJ1 cmctY2EvcHViL2NybC9jYWNybC5jcmwwP6A9oDuGOWh0dHA6Ly9jZHAyLnBjYS5kZm4uZGUv dW5pLWx1ZW5lYnVyZy1jYS9wdWIvY3JsL2NhY3JsLmNybDCBpgYIKwYBBQUHAQEEgZkwgZYw SQYIKwYBBQUHMAKGPWh0dHA6Ly9jZHAxLnBjYS5kZm4uZGUvdW5pLWx1ZW5lYnVyZy1jYS9w dWIvY2FjZXJ0L2NhY2VydC5jcnQwSQYIKwYBBQUHMAKGPWh0dHA6Ly9jZHAyLnBjYS5kZm4u ZGUvdW5pLWx1ZW5lYnVyZy1jYS9wdWIvY2FjZXJ0L2NhY2VydC5jcnQwDQYJKoZIhvcNAQEF BQADggEBAA1rdkb9QCalFwBeo4U4pcF/M329mKUh0BTFJpfM32CZcE2m0MRwt8NxygDbbxBz QFJ2m+ox0T/bVqGoTqhgjUJN+pu5h2iL9yYahejr4x0oIrEAP0uiSQd1kWGvyt42uxWSrHJj 74J6TvvscplafUW33zrgsDq8Nqvcr+xQeUE3E7pWFXO3T01AgWsDnSUKQ13qIIbseOLrbhIj j1paPPKwE4F1w/ry3NJgz6ckuh3U1ndL9be/4iU+Ux67UlnmFGfOhMLmocop2hCTBKZCa/z+ 5cPjpNe62YtfEfdLIFQgziSzpE3z5Vsn37rWc5CO1rNnO+DP1ydiq5AL0Obaz6oxggSoMIIE pAIBATCB3DCB0zELMAkGA1UEBhMCREUxFjAUBgNVBAgTDU5pZWRlcnNhY2hzZW4xEjAQBgNV BAcTCUx1ZW5lYnVyZzEoMCYGA1UEChMfTGV1cGhhbmEgVW5pdmVyc2l0YWV0IEx1ZW5lYnVy ZzEiMCAGA1UECxMZUmVjaGVuLSB1bmQgTWVkaWVuemVudHJ1bTErMCkGA1UEAxMiTGV1cGhh bmEgVW5pdmVyc2l0YWV0IEx1ZW5lYnVyZyBDQTEdMBsGCSqGSIb3DQEJARYOY2FAbGV1cGhh bmEuZGUCBBDuKTAwCQYFKw4DAhoFAKCCAqAwGAYJKoZIhvcNAQkDMQsGCSqGSIb3DQEHATAc BgkqhkiG9w0BCQUxDxcNMTEwOTA5MDU1OTQ3WjAjBgkqhkiG9w0BCQQxFgQUqlPcDzn4cKsM /KbQWIDailNoOMAwXwYJKoZIhvcNAQkPMVIwUDALBglghkgBZQMEAQIwCgYIKoZIhvcNAwcw DgYIKoZIhvcNAwICAgCAMA0GCCqGSIb3DQMCAgFAMAcGBSsOAwIHMA0GCCqGSIb3DQMCAgEo MIHtBgkrBgEEAYI3EAQxgd8wgdwwgdMxCzAJBgNVBAYTAkRFMRYwFAYDVQQIEw1OaWVkZXJz YWNoc2VuMRIwEAYDVQQHEwlMdWVuZWJ1cmcxKDAmBgNVBAoTH0xldXBoYW5hIFVuaXZlcnNp dGFldCBMdWVuZWJ1cmcxIjAgBgNVBAsTGVJlY2hlbi0gdW5kIE1lZGllbnplbnRydW0xKzAp BgNVBAMTIkxldXBoYW5hIFVuaXZlcnNpdGFldCBMdWVuZWJ1cmcgQ0ExHTAbBgkqhkiG9w0B CQEWDmNhQGxldXBoYW5hLmRlAgQQ7ikwMIHvBgsqhkiG9w0BCRACCzGB36CB3DCB0zELMAkG A1UEBhMCREUxFjAUBgNVBAgTDU5pZWRlcnNhY2hzZW4xEjAQBgNVBAcTCUx1ZW5lYnVyZzEo MCYGA1UEChMfTGV1cGhhbmEgVW5pdmVyc2l0YWV0IEx1ZW5lYnVyZzEiMCAGA1UECxMZUmVj aGVuLSB1bmQgTWVkaWVuemVudHJ1bTErMCkGA1UEAxMiTGV1cGhhbmEgVW5pdmVyc2l0YWV0 IEx1ZW5lYnVyZyBDQTEdMBsGCSqGSIb3DQEJARYOY2FAbGV1cGhhbmEuZGUCBBDuKTAwDQYJ KoZIhvcNAQEBBQAEggEADcDAICWBcrIeKV7anf2005XlSKJ9Z/Kn1cma7ExkbnaO9MwwzDu6 a4csWZ1A2gTU5f9d+FVqzzBT+gu7km5z4Dh37x3Z7IS0QMg/WdVZoXm4I9FHQcblKwYME7RQ xfZcozxu7s0KDhb9BlsfxJ2ZvdfbVqNBOQLeGRuv+aHImkXpJgppwP05j3aClfp2TTHkLGwX Fo6ZtWH702MG4IglZvuSCq9LSu6VJtMSLQ592l2QlJ+opSmydqlgM4I73y28qMnjI6Lh8afW eEVLJVci6jF9kXHoGCqgzxxfoeFso5fe1yzwrqqS3+MO3JOCTwiIW/vWlWXcc5Mkwff6zNAf hAAAAAAAAA== --------------ms060600090906020307000802-- --===============0322138462== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel --===============0322138462==-- From xen-devel-bounces@lists.xensource.com Fri Sep 09 00:50:57 2011 Return-path: Envelope-to: www-data@lists.xensource.com Delivery-date: Fri, 09 Sep 2011 00:50:57 -0700 Received: from localhost ([127.0.0.1] helo=lists.colo.xensource.com) by lists.xensource.com with esmtp (Exim 4.43) id 1R1vrU-0005rm-UN; Fri, 09 Sep 2011 00:50:56 -0700 Received: from mail21.messagelabs.com ([85.158.143.35]) by lists.xensource.com with smtp (Exim 4.43) id 1R1vql-0005ee-U9 for xen-devel@lists.xensource.com; Fri, 09 Sep 2011 00:50:12 -0700 X-Env-Sender: muehlenhoff@univention.de X-Msg-Ref: server-13.tower-21.messagelabs.com!1315554603!48255875!1 X-Originating-IP: [82.198.197.8] X-StarScan-Version: 6.3.6; banners=-,-,- X-VirusChecked: Checked Received: (qmail 31747 invoked from network); 9 Sep 2011 07:50:03 -0000 Received: from mail.univention.de (HELO mail.univention.de) (82.198.197.8) by server-13.tower-21.messagelabs.com with SMTP; 9 Sep 2011 07:50:03 -0000 Received: from localhost (localhost [127.0.0.1]) by slugis.knut.univention.de (Postfix) with ESMTP id 7E2FB6EA106 for ; Fri, 9 Sep 2011 09:50:06 +0200 (CEST) Received: from localhost (localhost [127.0.0.1]) by slugis.knut.univention.de (Postfix) with ESMTP id 712D86EA1DC for ; Fri, 9 Sep 2011 09:50:06 +0200 (CEST) X-Virus-Scanned: by amavisd-new-2.6.1 (20080629) (Debian) at knut.univention.de Received: from mail.univention.de ([127.0.0.1]) by localhost (slugis.knut.univention.de [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7AGvWk+1+hM5 for ; Fri, 9 Sep 2011 09:50:06 +0200 (CEST) Received: from vurm.localnet (vurm.knut.univention.de [192.168.0.132]) by slugis.knut.univention.de (Postfix) with ESMTPSA id 10F156EA106 for ; Fri, 9 Sep 2011 09:50:06 +0200 (CEST) From: Moritz =?iso-8859-1?q?M=FChlenhoff?= To: "xen-devel@lists.xensource.com" Date: Fri, 9 Sep 2011 09:50:04 +0200 User-Agent: KMail/1.13.5 (Linux/2.6.32-ucs44-amd64; KDE/4.4.5; x86_64; ; ) MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Message-Id: <201109090950.05043.muehlenhoff@univention.de> Subject: [Xen-devel] Signed GPLPV drivers available for download X-BeenThere: xen-devel@lists.xensource.com X-Mailman-Version: 2.1.5 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xensource.com Errors-To: xen-devel-bounces@lists.xensource.com Hi, for inclusion in Univention Corporate Server - a Linux distribution based o= n=20 Debian targeted towards enterprise environments, which also includes Xen fo= r=20 virtualisation - we're now building/signing the excellent GPLPV drivers=20 written by James Harper with a Software Publishers Certificate obtained fro= m=20 GlobalSign. [1] This allows installation of the GPLPV drivers on 64 bit Windows without the= =20 need to enable the test mode. The drivers are available from http://apt.univention.de/download/addons/gpl= pv- drivers/ and should be compatible with any Xen installation. The installation is detailed in=20 http://wiki.univention.de/index.php?title=3DInstalling-signed-GPLPV-drivers So far only new installation of the GPLPV drivers have been tested. We welc= ome=20 general feedback and experiences with upgrades from test-signed versions of= =20 GPLPV. Cheers, Moritz =46ootnotes: [1] We're well aware of the recent claims of a potential compromise of that= =20 CA, but as of today this is still under investigation: http://www.globalsign.com/company/press/090611-security-response.html =2D-=20 Moritz M=FChlenhoff muehlenhoff@univention.de Open Source Software Engineer and Consultant Univention GmbH Linux for Your Business fon: +49 421 22 232- 0 Mary-Somerville-Str.1 28359 Bremen fax: +49 421 22 232-99 http://www.univention.de _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel From xen-devel-bounces@lists.xensource.com Fri Sep 09 00:54:54 2011 Return-path: Envelope-to: www-data@lists.xensource.com Delivery-date: Fri, 09 Sep 2011 00:54:54 -0700 Received: from localhost ([127.0.0.1] helo=lists.colo.xensource.com) by lists.xensource.com with esmtp (Exim 4.43) id 1R1vvK-0006Yx-MH; Fri, 09 Sep 2011 00:54:54 -0700 Received: from mail27.messagelabs.com ([193.109.254.147]) by lists.xensource.com with esmtp (Exim 4.43) id 1R1vue-0006Bl-5p for xen-devel@lists.xensource.com; Fri, 09 Sep 2011 00:54:13 -0700 X-Env-Sender: komkon555@freenet.de X-Msg-Ref: server-15.tower-27.messagelabs.com!1315554840!48037535!1 X-Originating-IP: [216.139.236.26] X-StarScan-Version: 6.3.6; banners=-,-,- X-VirusChecked: Checked Received: (qmail 23991 invoked from network); 9 Sep 2011 07:54:01 -0000 Received: from sam.nabble.com (HELO sam.nabble.com) (216.139.236.26) by server-15.tower-27.messagelabs.com with AES256-SHA encrypted SMTP; 9 Sep 2011 07:54:01 -0000 Received: from [192.168.236.26] (helo=sam.nabble.com) by sam.nabble.com with esmtp (Exim 4.72) (envelope-from ) id 1R1vuZ-000335-73 for xen-devel@lists.xensource.com; Fri, 09 Sep 2011 00:54:07 -0700 Date: Fri, 9 Sep 2011 00:54:07 -0700 (PDT) From: komkon555 To: xen-devel@lists.xensource.com Message-ID: <1315554847212-4785386.post@n5.nabble.com> In-Reply-To: <1315408931610-4778925.post@n5.nabble.com> References: <1315310225039-4774097.post@n5.nabble.com> <1315343879.61837.YahooMailNeo@web29818.mail.ird.yahoo.com> <1315382742268-4777689.post@n5.nabble.com> <1315389138.56652.YahooMailNeo@web29801.mail.ird.yahoo.com> <1315398360680-4778339.post@n5.nabble.com> <1315401901083-4778494.post@n5.nabble.com> <1315403644525-4778586.post@n5.nabble.com> <1315405372.87224.YahooMailNeo@web29801.mail.ird.yahoo.com> <1315405921936-4778727.post@n5.nabble.com> <1315408931610-4778925.post@n5.nabble.com> Subject: Re: Re : Re : Re : [Xen-devel] Re: Patches for VGA-Passthrough XEN 4.2 unstable MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-BeenThere: xen-devel@lists.xensource.com X-Mailman-Version: 2.1.5 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xensource.com Errors-To: xen-devel-bounces@lists.xensource.com Hi. There is the promised report to JavMV: with fixes on dsd are your patches also functional. Windows XP starts and GTX260 works perfect with driver version 275.33. Some news more: The best results I got with this configuration: xen 4.1-unstable changeset 21668 (patched clearly with these http://lists.xensource.com/archives/html/xen-devel/2010-05/msg00441.html patches , dsd fixed according to David TECHER) + jeremi xen kernel 2.6.32.45 (xenfs static). This configuration works excellent both: with primary and secondary vga-adapter (GTX260). There are two Problem with all configurations: 1. DomU can be started only once. Being correctly shouted down, starts DomU no more. 2. Physical usb- keyboard and mouse can not be assigned to DomU (regular usb assignment has no effect, PVUSB crashes) Best regards Kom. -- View this message in context: http://xen.1045712.n5.nabble.com/Patches-for-VGA-Passthrough-XEN-4-2-unstable-tp4406265p4785386.html Sent from the Xen - Dev mailing list archive at Nabble.com. _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel From xen-devel-bounces@lists.xensource.com Fri Sep 09 01:08:58 2011 Return-path: Envelope-to: www-data@lists.xensource.com Delivery-date: Fri, 09 Sep 2011 01:08:58 -0700 Received: from localhost ([127.0.0.1] helo=lists.colo.xensource.com) by lists.xensource.com with esmtp (Exim 4.43) id 1R1w8v-00079L-0z; Fri, 09 Sep 2011 01:08:57 -0700 Received: from mail27.messagelabs.com ([193.109.254.147]) by lists.xensource.com with esmtp (Exim 4.43) id 1R1w7v-0006wW-Em for xen-devel@lists.xensource.com; Fri, 09 Sep 2011 01:07:55 -0700 X-Env-Sender: komkon555@freenet.de X-Msg-Ref: server-7.tower-27.messagelabs.com!1315555650!47927224!1 X-Originating-IP: [216.139.236.26] X-StarScan-Version: 6.3.6; banners=-,-,- X-VirusChecked: Checked Received: (qmail 7665 invoked from network); 9 Sep 2011 08:07:31 -0000 Received: from sam.nabble.com (HELO sam.nabble.com) (216.139.236.26) by server-7.tower-27.messagelabs.com with AES256-SHA encrypted SMTP; 9 Sep 2011 08:07:31 -0000 Received: from [192.168.236.26] (helo=sam.nabble.com) by sam.nabble.com with esmtp (Exim 4.72) (envelope-from ) id 1R1w7q-0003pL-MJ for xen-devel@lists.xensource.com; Fri, 09 Sep 2011 01:07:50 -0700 Date: Fri, 9 Sep 2011 01:07:50 -0700 (PDT) From: komkon555 To: xen-devel@lists.xensource.com Message-ID: <1315555670684-4785425.post@n5.nabble.com> In-Reply-To: <4E696FCF.3050407@huawei.com> References: <1314795401771-4754024.post@n5.nabble.com> <20110831151913.GE7276@reaktio.net> <1315231341254-4770602.post@n5.nabble.com> <1315310225039-4774097.post@n5.nabble.com> <1315343879.61837.YahooMailNeo@web29818.mail.ird.yahoo.com> <1315382742268-4777689.post@n5.nabble.com> <1315389138.56652.YahooMailNeo@web29801.mail.ird.yahoo.com> <1315398360680-4778339.post@n5.nabble.com> <1315399889.79555.YahooMailNeo@web29820.mail.ird.yahoo.com> <4E696FCF.3050407@huawei.com> Subject: Re: Re : Re : Re : [Xen-devel] Re: Patches for VGA-Passthrough XEN 4.2 unstable MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-BeenThere: xen-devel@lists.xensource.com X-Mailman-Version: 2.1.5 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xensource.com Errors-To: xen-devel-bounces@lists.xensource.com Weidong Han wrote: > > Guest needs VGA BIOS to initialize assigned graphics card in guest. > qemu-dm only know how to copy video BIOS of primary graphics card which > locates at 0xC0000, but don't know where are video BIOS of other > graphics cards. if want to pass-through more than one graphics cards, > must know how to get and load VGA BIOS to guest for other graphics > cards. One method is to use tools such as NiBiTor to extract VGA BIOS > from graphics card to a file, then load it to guest. > > Weidong > Hallo. What about ATI/AMD cards: are they in the same situation? Is it possible for today to pass through multiple ATI/AMD devices? Thank you. Best regards Kom. -- View this message in context: http://xen.1045712.n5.nabble.com/Patches-for-VGA-Passthrough-XEN-4-2-unstable-tp4406265p4785425.html Sent from the Xen - Dev mailing list archive at Nabble.com. _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel From xen-devel-bounces@lists.xensource.com Fri Sep 09 01:55:47 2011 Return-path: Envelope-to: www-data@lists.xensource.com Delivery-date: Fri, 09 Sep 2011 01:55:47 -0700 Received: from localhost ([127.0.0.1] helo=lists.colo.xensource.com) by lists.xensource.com with esmtp (Exim 4.43) id 1R1wsD-00004u-40; Fri, 09 Sep 2011 01:55:46 -0700 Received: from mail21.messagelabs.com ([85.158.143.35]) by lists.xensource.com with smtp (Exim 4.43) id 1R1wrS-0008Jr-9l for xen-devel@lists.xensource.com; Fri, 09 Sep 2011 01:54:58 -0700 X-Env-Sender: mad@wol.de X-Msg-Ref: server-12.tower-21.messagelabs.com!1315558481!49290707!1 X-Originating-IP: [193.158.62.4] X-StarScan-Version: 6.3.6; banners=-,-,- X-VirusChecked: Checked Received: (qmail 31656 invoked from network); 9 Sep 2011 08:54:41 -0000 Received: from cmx.wol.de (HELO cmx.wol.de) (193.158.62.4) by server-12.tower-21.messagelabs.com with SMTP; 9 Sep 2011 08:54:41 -0000 Received: from localhost (localhost.localdomain [127.0.0.1]) by cmx.wol.de (Postfix) with ESMTP id EC97A5C11A for ; Fri, 9 Sep 2011 10:54:54 +0200 (CEST) Received: from cmx.wol.de ([127.0.0.1]) by localhost (cmx.wol.de [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id eNu37o5aacaO for ; Fri, 9 Sep 2011 10:54:52 +0200 (CEST) Received: from [192.168.2.69] (pulsar.wol.de [193.158.62.6]) by cmx.wol.de (Postfix) with ESMTP id 614D25C094 for ; Fri, 9 Sep 2011 10:54:52 +0200 (CEST) From: "Marc - A. Dahlhaus" To: xen-devel@lists.xensource.com In-Reply-To: <4E6933D9.6070408@it-infrastrukturen.com> References: <4E5AA0F1.6010408@it-infrastrukturen.org> <4E5BF4AE.8040006@it-infrastrukturen.org> <20110831125755.GA16787@dumpdata.com> <4E6933D9.6070408@it-infrastrukturen.com> Content-Type: text/plain; charset="UTF-8" Date: Fri, 09 Sep 2011 10:55:01 +0200 Message-ID: <1315558501.23927.6.camel@marc> Mime-Version: 1.0 X-Mailer: Evolution 2.32.2 Content-Transfer-Encoding: 7bit Subject: [Xen-devel] Re: OVM 3.0.1 missing support for P410i X-BeenThere: xen-devel@lists.xensource.com X-Mailman-Version: 2.1.5 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xensource.com Errors-To: xen-devel-bounces@lists.xensource.com Am Donnerstag, den 08.09.2011, 23:30 +0200 schrieb M. Schneider: > Unfortunately the current OVM 3.0.1 *doesn't* directly support P410i > RAID-controller of HP DL385g7 and I don't have any idea where to get > these required drivers from. (I have just tried to install OVM 3.0.1). Hello Mark, you will need a newer version of the hpsa or the older cciss driver for the controller to work. You should be able to get the sources from cciss.sf.net or precompiled modules from the support dowload area on hp.com (if the oracle vm dom0 kernel is compatible to one of the from hp supported rhel versions)... Marc _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel From xen-devel-bounces@lists.xensource.com Fri Sep 09 02:19:39 2011 Return-path: Envelope-to: www-data@lists.xensource.com Delivery-date: Fri, 09 Sep 2011 02:19:39 -0700 Received: from localhost ([127.0.0.1] helo=lists.colo.xensource.com) by lists.xensource.com with esmtp (Exim 4.43) id 1R1xFK-0000s0-TQ; Fri, 09 Sep 2011 02:19:38 -0700 Received: from mail21.messagelabs.com ([85.158.143.35]) by lists.xensource.com with smtp (Exim 4.43) id 1R1xDp-0000ev-Hn for xen-devel@lists.xensource.com; Fri, 09 Sep 2011 02:18:09 -0700 X-Env-Sender: andreas.olsowski@leuphana.de X-Msg-Ref: server-6.tower-21.messagelabs.com!1315559863!37597003!1 X-Originating-IP: [193.174.46.71] X-StarScan-Version: 6.3.6; banners=-,-,- X-VirusChecked: Checked Received: (qmail 25586 invoked from network); 9 Sep 2011 09:17:43 -0000 Received: from mailhost.leuphana.de (HELO leuphana.de) (193.174.46.71) by server-6.tower-21.messagelabs.com with SMTP; 9 Sep 2011 09:17:43 -0000 Received: from [141.39.215.216] (account aolsowsk@leuphana.de [141.39.215.216] verified) by leuphana.de (CommuniGate Pro SMTP 5.4.1e) with ESMTPSA id 44921491; Fri, 09 Sep 2011 11:18:01 +0200 Message-ID: <4E69D9C9.3000505@leuphana.de> Date: Fri, 09 Sep 2011 11:18:01 +0200 From: Andreas Olsowski User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.2.18) Gecko/20110626 Icedove/3.1.11 MIME-Version: 1.0 To: Konrad Rzeszutek Wilk Subject: Re: [Xen-devel] xen/stable-2.6.32.x xen-4.1.1 live migration fails with kernels 2.6.39, 3.0.3 and 3.1-rc2 References: <4E52601B.5060609@leuphana.de> <20110824203435.GA27865@dumpdata.com> <4E55F682.8060405@leuphana.de> <20110826150054.GA1793@dumpdata.com> <4E57D745.2080701@leuphana.de> <20110829194911.GC16530@dumpdata.com> <4E5E320A.60401@leuphana.de> <20110907135046.GD32190@dumpdata.com> <20110908173212.GA17026@dumpdata.com> <20110908181227.GB19078@dumpdata.com> <20110908195031.GA21186@dumpdata.com> <19825_1315548082_p8961G08009635_4E69AB53.5010702@leuphana.de> In-Reply-To: <19825_1315548082_p8961G08009635_4E69AB53.5010702@leuphana.de> Cc: "xen-devel@lists.xensource.com" X-BeenThere: xen-devel@lists.xensource.com X-Mailman-Version: 2.1.5 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1342921186==" Sender: xen-devel-bounces@lists.xensource.com Errors-To: xen-devel-bounces@lists.xensource.com This is a cryptographically signed message in MIME format. --===============1342921186== Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha1; boundary="------------ms010305080108070604070400" This is a cryptographically signed message in MIME format. --------------ms010305080108070604070400 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: quoted-printable >>> On Thu, Sep 08, 2011 at 01:32:12PM -0400, Konrad Rzeszutek Wilk wrote= : >>> Oh wait. At some point you said that 2.6.32.43 worked for you.. Is >>> that still >>> the case? I tested 2.6.32.43 and 2.6.32.40 (to be sure) again, they dont work eithe= r. >> Can you please try one thing for me - can you make sure the boxes have= >> exact same >> amount of memory? You can do 'mem=3DX' on the Xen hypervisor line to s= et >> that. > Running mem=3D8g and have turned balooning dom0 off. > > multiboot /boot/xen.gz placeholder dom0_mem=3D8192M > module /boot/vmlinuz-2.6.32.45-xen0 placeholder > root=3DUUID=3D216ff902-b505-45c4-9bcb-9d63b4cb8992 ro mem=3D8G nomodese= t > console=3Dtty0 console=3DttyS1,57600 earlyprintk=3Dxen > > > For some reason though, the two r610s show: > root@netcatarina:~# cat /proc/meminfo > MemTotal: 8378236 kB > root@netcatarina:~# xl list |grep Domain-0 > Domain-0 0 7445 8 r----- 124304.7 > > root@memoryana:~# cat /proc/meminfo > MemTotal: 8378236 kB > root@memoryana:~# xl list |grep Domain-0 > Domain-0 0 7445 8 r----- 132125.0 > > wheras the r710: > root@tarballerina:~# cat /proc/meminfo > MemTotal: 7886716 kB > root@tarballerina:~# xl list |grep Domain-0 > Domain-0 0 7221 8 r----- 64497.0 After reboot it went back up to 8378236KB. I dont understand why the dom0 memory sometimes changes. The two 32gb PE2950s show 8378236 KB after boot and then drop to sth=20 like 6575996 KB. The R610s stay at 8378236 KB, always. --=20 Andreas Olsowski Leuphana Universit=E4t L=FCneburg Rechen- und Medienzentrum Scharnhorststra=DFe 1, C7.015 21335 L=FCneburg Tel: ++49 4131 677 1309 --------------ms010305080108070604070400 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIU3TCC BCEwggMJoAMCAQICAgDHMA0GCSqGSIb3DQEBBQUAMHExCzAJBgNVBAYTAkRFMRwwGgYDVQQK ExNEZXV0c2NoZSBUZWxla29tIEFHMR8wHQYDVQQLExZULVRlbGVTZWMgVHJ1c3QgQ2VudGVy MSMwIQYDVQQDExpEZXV0c2NoZSBUZWxla29tIFJvb3QgQ0EgMjAeFw0wNjEyMTkxMDI5MDBa Fw0xOTA2MzAyMzU5MDBaMFoxCzAJBgNVBAYTAkRFMRMwEQYDVQQKEwpERk4tVmVyZWluMRAw DgYDVQQLEwdERk4tUEtJMSQwIgYDVQQDExtERk4tVmVyZWluIFBDQSBHbG9iYWwgLSBHMDEw ggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQDpm8NnhfkNrvWNVMOWUDU9YuluTO2U 1wBblSJ01CDrNI/W7MAxBAuZgeKmFNJSoCgjhIt0iQReW+DieMF4yxbLKDU5ey2QRdDtoAB6 fL9KDhsAw4bpXCsxEXsM84IkQ4wcOItqaACa7txPeKvSxhObdq3u3ibo7wGvdA/BCaL2a869 080UME/15eOkyGKbghoDJzANAmVgTe3RCSMqljVYJ9N2xnG2kB3E7f81hn1vM7PbD8URwoqD oZRdQWvY0hD1TP3KUazZve+Sg7va64sWVlZDz+HVEz2mHycwzUlU28kTNJpxdcVs6qcLmPkh nSevPqM5OUhqjK3JmfvDEvK9AgMBAAGjgdkwgdYwcAYDVR0fBGkwZzBloGOgYYZfaHR0cDov L3BraS50ZWxlc2VjLmRlL2NnaS1iaW4vc2VydmljZS9hZl9Eb3dubG9hZEFSTC5jcmw/LWNy bF9mb3JtYXQ9WF81MDkmLWlzc3Vlcj1EVF9ST09UX0NBXzIwHQYDVR0OBBYEFEm3xs/oPR9/ 6kR7Eyn38QpwPt5kMB8GA1UdIwQYMBaAFDHDeRu69VPXF+CJei0XbAqzK50zMA4GA1UdDwEB /wQEAwIBBjASBgNVHRMBAf8ECDAGAQH/AgECMA0GCSqGSIb3DQEBBQUAA4IBAQA74Vp3wEgX 3KkY7IGvWonwvSiSpspZGBJw7Cjy565/lizn8l0ZMfYTK3S9vYCyufdnyTmieTvhERHua3iR M347XyYndVNljjNj7s9zw7CSI0khUHUjoR8Y4pSFPT8z6XcgjaK95qGFKUD2P3MyWA0Ja6ba hWzAP7uNZmRWJE6uDT8yNQFb6YyC2XJZT7GGhfF0hVblw/hc843uR7NTBXDn5U2KaYMo4RMJ hp5eyOpYHgwf+aTUWgRo/Sg+iwK2WLX2oSw3VwBnqyNojWOl75lrXP1LVvarQIc01BGSbOyH xQoLBzNytG8MHVQs2FHHzL8w00Ny8TK/jM5JY6gA9/IcMIIFXjCCBEagAwIBAgIEC8pR1jAN BgkqhkiG9w0BAQUFADBaMQswCQYDVQQGEwJERTETMBEGA1UEChMKREZOLVZlcmVpbjEQMA4G A1UECxMHREZOLVBLSTEkMCIGA1UEAxMbREZOLVZlcmVpbiBQQ0EgR2xvYmFsIC0gRzAxMB4X DTA4MDIwNzA5NTAwMFoXDTE5MDYzMDAwMDAwMFowgdMxCzAJBgNVBAYTAkRFMRYwFAYDVQQI Ew1OaWVkZXJzYWNoc2VuMRIwEAYDVQQHEwlMdWVuZWJ1cmcxKDAmBgNVBAoTH0xldXBoYW5h IFVuaXZlcnNpdGFldCBMdWVuZWJ1cmcxIjAgBgNVBAsTGVJlY2hlbi0gdW5kIE1lZGllbnpl bnRydW0xKzApBgNVBAMTIkxldXBoYW5hIFVuaXZlcnNpdGFldCBMdWVuZWJ1cmcgQ0ExHTAb BgkqhkiG9w0BCQEWDmNhQGxldXBoYW5hLmRlMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIB CgKCAQEAqJ+JpHih32+icKiQ2IkbhmFLjAcnK0vrnyOKbn7+1xywhvL3zkraqhQlrqEltTDy 711vIEadOVfhIx8xZYYJ/zg1OCwKUxNbIbjcsIFiOKNbWxI3/yMOsaZpXsCLW7GfHLlLADW1 Cv2gUAdnjJUATcUF3a25Bgr9Lbv+GI+3bY9ydMkGnhFYSL96LLqLxAXzGXL/MAM5t/xK8cc8 +6+mWxHAqO+85Jn+UvS1khVTtZfACrYZKFnAsVHOMM/WRugohq4ue6Jfp65exMM7HKWNPrKn UV0hotcInKFBYywcZrIa2r/6m63nOxl1gHrewxiFWEBvpgMkQ+a7PHhXsMkPdQIDAQABo4IB sDCCAawwEgYDVR0TAQH/BAgwBgEB/wIBATALBgNVHQ8EBAMCAQYwHQYDVR0OBBYEFPThaBk7 GUPHATbRNGKW8/UDoQeMMB8GA1UdIwQYMBaAFEm3xs/oPR9/6kR7Eyn38QpwPt5kMBkGA1Ud EQQSMBCBDmNhQGxldXBoYW5hLmRlMIGIBgNVHR8EgYAwfjA9oDugOYY3aHR0cDovL2NkcDEu cGNhLmRmbi5kZS9nbG9iYWwtcm9vdC1jYS9wdWIvY3JsL2NhY3JsLmNybDA9oDugOYY3aHR0 cDovL2NkcDIucGNhLmRmbi5kZS9nbG9iYWwtcm9vdC1jYS9wdWIvY3JsL2NhY3JsLmNybDCB ogYIKwYBBQUHAQEEgZUwgZIwRwYIKwYBBQUHMAKGO2h0dHA6Ly9jZHAxLnBjYS5kZm4uZGUv Z2xvYmFsLXJvb3QtY2EvcHViL2NhY2VydC9jYWNlcnQuY3J0MEcGCCsGAQUFBzAChjtodHRw Oi8vY2RwMi5wY2EuZGZuLmRlL2dsb2JhbC1yb290LWNhL3B1Yi9jYWNlcnQvY2FjZXJ0LmNy dDANBgkqhkiG9w0BAQUFAAOCAQEAmSFLUEnTM1zmNRfF4TTDRB53iHmBY0OYTlaPJvXXy4f7 jc1Dpz00HiVyFohY9gqo+jbIAm5avSCmhbL9glEWubE/BNZz9l9lyTCMMxFES0TCiC6W86Ev o9E4C5IEqxZAOlvRyM3w3u8ItBO9cG190/XMi1Ouk3iBfwRVvFINy9Favq+/8HWFwkFrphpy 6JR90AbbjtE7b7owcMxusgFtPi8A1uyc3cpR21f51K7qgmGbsyXso+U9c/8Fak0IM0qQTN7p GPmI1lfJ0x1r/QusHVYSFojAT2vQamfGeCNVELg/gH4tlTGkDbHW5QhInkASQv4obBYewNfR rLG4wgPz5TCCBacwggSPoAMCAQICBBDuKTAwDQYJKoZIhvcNAQEFBQAwgdMxCzAJBgNVBAYT AkRFMRYwFAYDVQQIEw1OaWVkZXJzYWNoc2VuMRIwEAYDVQQHEwlMdWVuZWJ1cmcxKDAmBgNV BAoTH0xldXBoYW5hIFVuaXZlcnNpdGFldCBMdWVuZWJ1cmcxIjAgBgNVBAsTGVJlY2hlbi0g dW5kIE1lZGllbnplbnRydW0xKzApBgNVBAMTIkxldXBoYW5hIFVuaXZlcnNpdGFldCBMdWVu ZWJ1cmcgQ0ExHTAbBgkqhkiG9w0BCQEWDmNhQGxldXBoYW5hLmRlMB4XDTEwMTEwMTExNTky OVoXDTEzMTAzMTExNTkyOVowajELMAkGA1UEBhMCREUxKDAmBgNVBAoTH0xldXBoYW5hIFVu aXZlcnNpdGFldCBMdWVuZWJ1cmcxFjAUBgNVBAsTDVJlY2hlbnplbnRydW0xGTAXBgNVBAMT EEFuZHJlYXMgT2xzb3dza2kwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQDBzfnZ 7pbsecrmresa6JNTMmgoBFpwyr7k7U5O+j7QlFvMlePF/Tz7TeULaEevf7H68IiA/6oGZQvg NReD/64PYXxbKfsJydY6W1K+jq2karofhW5bk5p210DEQv4qyV6M+aJRKxW0Hp32OeLk5QUH 9T2780PELXGn222r+NCSmBKLP0MHsUa6CFI+jRqztB60v+wc9TD6crMEB37ddckq7mS3QWk1 m2/68bmCsHWRLTpWn9hT4S8eBSL/3YLR9DF8kfWl0wEgy8/tJY1nz5IlSI3S2v1ys7rwXBAp YHRpeHM/WNNNV4kiH09g2vlxFebQN0xTyoO1+PX6iPeAh0NbAgMBAAGjggHpMIIB5TAJBgNV HRMEAjAAMAsGA1UdDwQEAwIF4DApBgNVHSUEIjAgBggrBgEFBQcDAgYIKwYBBQUHAwQGCisG AQQBgjcUAgIwHQYDVR0OBBYEFMrca499fLnPczMLjRm2Nck06YCyMB8GA1UdIwQYMBaAFPTh aBk7GUPHATbRNGKW8/UDoQeMMCcGA1UdEQQgMB6BHGFuZHJlYXMub2xzb3dza2lAbGV1cGhh bmEuZGUwgY0GA1UdHwSBhTCBgjA/oD2gO4Y5aHR0cDovL2NkcDEucGNhLmRmbi5kZS91bmkt bHVlbmVidXJnLWNhL3B1Yi9jcmwvY2FjcmwuY3JsMD+gPaA7hjlodHRwOi8vY2RwMi5wY2Eu ZGZuLmRlL3VuaS1sdWVuZWJ1cmctY2EvcHViL2NybC9jYWNybC5jcmwwgaYGCCsGAQUFBwEB BIGZMIGWMEkGCCsGAQUFBzAChj1odHRwOi8vY2RwMS5wY2EuZGZuLmRlL3VuaS1sdWVuZWJ1 cmctY2EvcHViL2NhY2VydC9jYWNlcnQuY3J0MEkGCCsGAQUFBzAChj1odHRwOi8vY2RwMi5w Y2EuZGZuLmRlL3VuaS1sdWVuZWJ1cmctY2EvcHViL2NhY2VydC9jYWNlcnQuY3J0MA0GCSqG SIb3DQEBBQUAA4IBAQANa3ZG/UAmpRcAXqOFOKXBfzN9vZilIdAUxSaXzN9gmXBNptDEcLfD ccoA228Qc0BSdpvqMdE/21ahqE6oYI1CTfqbuYdoi/cmGoXo6+MdKCKxAD9LokkHdZFhr8re NrsVkqxyY++Cek777HKZWn1Ft9864LA6vDar3K/sUHlBNxO6VhVzt09NQIFrA50lCkNd6iCG 7Hji624SI49aWjzysBOBdcP68tzSYM+nJLod1NZ3S/W3v+IlPlMeu1JZ5hRnzoTC5qHKKdoQ kwSmQmv8/uXD46TXutmLXxH3SyBUIM4ks6RN8+VbJ9+61nOQjtazZzvgz9cnYquQC9Dm2s+q MIIFpzCCBI+gAwIBAgIEEO4pMDANBgkqhkiG9w0BAQUFADCB0zELMAkGA1UEBhMCREUxFjAU BgNVBAgTDU5pZWRlcnNhY2hzZW4xEjAQBgNVBAcTCUx1ZW5lYnVyZzEoMCYGA1UEChMfTGV1 cGhhbmEgVW5pdmVyc2l0YWV0IEx1ZW5lYnVyZzEiMCAGA1UECxMZUmVjaGVuLSB1bmQgTWVk aWVuemVudHJ1bTErMCkGA1UEAxMiTGV1cGhhbmEgVW5pdmVyc2l0YWV0IEx1ZW5lYnVyZyBD QTEdMBsGCSqGSIb3DQEJARYOY2FAbGV1cGhhbmEuZGUwHhcNMTAxMTAxMTE1OTI5WhcNMTMx MDMxMTE1OTI5WjBqMQswCQYDVQQGEwJERTEoMCYGA1UEChMfTGV1cGhhbmEgVW5pdmVyc2l0 YWV0IEx1ZW5lYnVyZzEWMBQGA1UECxMNUmVjaGVuemVudHJ1bTEZMBcGA1UEAxMQQW5kcmVh cyBPbHNvd3NraTCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAMHN+dnulux5yuat 6xrok1MyaCgEWnDKvuTtTk76PtCUW8yV48X9PPtN5QtoR69/sfrwiID/qgZlC+A1F4P/rg9h fFsp+wnJ1jpbUr6OraRquh+FbluTmnbXQMRC/irJXoz5olErFbQenfY54uTlBQf1PbvzQ8Qt cafbbav40JKYEos/QwexRroIUj6NGrO0HrS/7Bz1MPpyswQHft11ySruZLdBaTWbb/rxuYKw dZEtOlaf2FPhLx4FIv/dgtH0MXyR9aXTASDLz+0ljWfPkiVIjdLa/XKzuvBcEClgdGl4cz9Y 001XiSIfT2Da+XEV5tA3TFPKg7X49fqI94CHQ1sCAwEAAaOCAekwggHlMAkGA1UdEwQCMAAw CwYDVR0PBAQDAgXgMCkGA1UdJQQiMCAGCCsGAQUFBwMCBggrBgEFBQcDBAYKKwYBBAGCNxQC AjAdBgNVHQ4EFgQUytxrj318uc9zMwuNGbY1yTTpgLIwHwYDVR0jBBgwFoAU9OFoGTsZQ8cB NtE0Ypbz9QOhB4wwJwYDVR0RBCAwHoEcYW5kcmVhcy5vbHNvd3NraUBsZXVwaGFuYS5kZTCB jQYDVR0fBIGFMIGCMD+gPaA7hjlodHRwOi8vY2RwMS5wY2EuZGZuLmRlL3VuaS1sdWVuZWJ1 cmctY2EvcHViL2NybC9jYWNybC5jcmwwP6A9oDuGOWh0dHA6Ly9jZHAyLnBjYS5kZm4uZGUv dW5pLWx1ZW5lYnVyZy1jYS9wdWIvY3JsL2NhY3JsLmNybDCBpgYIKwYBBQUHAQEEgZkwgZYw SQYIKwYBBQUHMAKGPWh0dHA6Ly9jZHAxLnBjYS5kZm4uZGUvdW5pLWx1ZW5lYnVyZy1jYS9w dWIvY2FjZXJ0L2NhY2VydC5jcnQwSQYIKwYBBQUHMAKGPWh0dHA6Ly9jZHAyLnBjYS5kZm4u ZGUvdW5pLWx1ZW5lYnVyZy1jYS9wdWIvY2FjZXJ0L2NhY2VydC5jcnQwDQYJKoZIhvcNAQEF BQADggEBAA1rdkb9QCalFwBeo4U4pcF/M329mKUh0BTFJpfM32CZcE2m0MRwt8NxygDbbxBz QFJ2m+ox0T/bVqGoTqhgjUJN+pu5h2iL9yYahejr4x0oIrEAP0uiSQd1kWGvyt42uxWSrHJj 74J6TvvscplafUW33zrgsDq8Nqvcr+xQeUE3E7pWFXO3T01AgWsDnSUKQ13qIIbseOLrbhIj j1paPPKwE4F1w/ry3NJgz6ckuh3U1ndL9be/4iU+Ux67UlnmFGfOhMLmocop2hCTBKZCa/z+ 5cPjpNe62YtfEfdLIFQgziSzpE3z5Vsn37rWc5CO1rNnO+DP1ydiq5AL0Obaz6oxggSoMIIE pAIBATCB3DCB0zELMAkGA1UEBhMCREUxFjAUBgNVBAgTDU5pZWRlcnNhY2hzZW4xEjAQBgNV BAcTCUx1ZW5lYnVyZzEoMCYGA1UEChMfTGV1cGhhbmEgVW5pdmVyc2l0YWV0IEx1ZW5lYnVy ZzEiMCAGA1UECxMZUmVjaGVuLSB1bmQgTWVkaWVuemVudHJ1bTErMCkGA1UEAxMiTGV1cGhh bmEgVW5pdmVyc2l0YWV0IEx1ZW5lYnVyZyBDQTEdMBsGCSqGSIb3DQEJARYOY2FAbGV1cGhh bmEuZGUCBBDuKTAwCQYFKw4DAhoFAKCCAqAwGAYJKoZIhvcNAQkDMQsGCSqGSIb3DQEHATAc BgkqhkiG9w0BCQUxDxcNMTEwOTA5MDkxODAxWjAjBgkqhkiG9w0BCQQxFgQUbPi14r/kAA8Q +G8O6ETCdR9OLnowXwYJKoZIhvcNAQkPMVIwUDALBglghkgBZQMEAQIwCgYIKoZIhvcNAwcw DgYIKoZIhvcNAwICAgCAMA0GCCqGSIb3DQMCAgFAMAcGBSsOAwIHMA0GCCqGSIb3DQMCAgEo MIHtBgkrBgEEAYI3EAQxgd8wgdwwgdMxCzAJBgNVBAYTAkRFMRYwFAYDVQQIEw1OaWVkZXJz YWNoc2VuMRIwEAYDVQQHEwlMdWVuZWJ1cmcxKDAmBgNVBAoTH0xldXBoYW5hIFVuaXZlcnNp dGFldCBMdWVuZWJ1cmcxIjAgBgNVBAsTGVJlY2hlbi0gdW5kIE1lZGllbnplbnRydW0xKzAp BgNVBAMTIkxldXBoYW5hIFVuaXZlcnNpdGFldCBMdWVuZWJ1cmcgQ0ExHTAbBgkqhkiG9w0B CQEWDmNhQGxldXBoYW5hLmRlAgQQ7ikwMIHvBgsqhkiG9w0BCRACCzGB36CB3DCB0zELMAkG A1UEBhMCREUxFjAUBgNVBAgTDU5pZWRlcnNhY2hzZW4xEjAQBgNVBAcTCUx1ZW5lYnVyZzEo MCYGA1UEChMfTGV1cGhhbmEgVW5pdmVyc2l0YWV0IEx1ZW5lYnVyZzEiMCAGA1UECxMZUmVj aGVuLSB1bmQgTWVkaWVuemVudHJ1bTErMCkGA1UEAxMiTGV1cGhhbmEgVW5pdmVyc2l0YWV0 IEx1ZW5lYnVyZyBDQTEdMBsGCSqGSIb3DQEJARYOY2FAbGV1cGhhbmEuZGUCBBDuKTAwDQYJ KoZIhvcNAQEBBQAEggEAD6OXhb53eUdsyh0sJYGfVfQWkaKQDvFyEhXG5TUMTmhHykVQs2bU Xbim79vexA3dbGXYUx/NgmvnTuCxP6HFgeaZ3LY11YGzdvh2wCeA493i8iq8W7/CTcpyiSmv 4wRmx/reCOiDLhGMRiPRHmmGJvVq71OY6SXjtI0t/qhgZpILU8B37rc7dKcoZdRf4vN57aS9 XGANOiqgCSwg2rVy01SL/YuwbHoBT/A4mz8OoGl+wEpRXXbXZ049hU8UJ/LqIHnTs43jgZNM IlLi23nRG2sefo6RjgvZZNvSEhyE6kNADdSQMc+UUArkV9vFG/W/MjneBpBCNTbI2nWSqSMo eAAAAAAAAA== --------------ms010305080108070604070400-- --===============1342921186== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel --===============1342921186==-- From xen-devel-bounces@lists.xensource.com Fri Sep 09 03:12:13 2011 Return-path: Envelope-to: www-data@lists.xensource.com Delivery-date: Fri, 09 Sep 2011 03:12:13 -0700 Received: from localhost ([127.0.0.1] helo=lists.colo.xensource.com) by lists.xensource.com with esmtp (Exim 4.43) id 1R1y4C-0003CX-5i; Fri, 09 Sep 2011 03:12:12 -0700 Received: from mail27.messagelabs.com ([193.109.254.147]) by lists.xensource.com with smtp (Exim 4.43) id 1R1y2I-0002z2-Td for xen-devel@lists.xensource.com; Fri, 09 Sep 2011 03:10:36 -0700 X-Env-Sender: Stefano.Stabellini@eu.citrix.com X-Msg-Ref: server-11.tower-27.messagelabs.com!1315563005!36715259!1 X-Originating-IP: [62.200.22.115] X-StarScan-Version: 6.3.6; banners=-,-,- X-VirusChecked: Checked Received: (qmail 25527 invoked from network); 9 Sep 2011 10:10:05 -0000 Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115) by server-11.tower-27.messagelabs.com with SMTP; 9 Sep 2011 10:10:05 -0000 X-IronPort-AV: E=Sophos;i="4.68,355,1312156800"; d="scan'208";a="7693409" Received: from lonpmailmx01.citrite.net ([10.30.203.162]) by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5; 09 Sep 2011 10:10:11 +0000 Received: from kaball.uk.xensource.com (10.80.2.59) by LONPMAILMX01.citrite.net (10.30.203.162) with Microsoft SMTP Server id 8.3.137.0; Fri, 9 Sep 2011 11:10:11 +0100 Date: Fri, 9 Sep 2011 11:18:07 +0100 From: Stefano Stabellini X-X-Sender: sstabellini@kaball-desktop To: Ian Campbell Subject: Re: [Xen-devel] [PATCH v2 3/4] Clone and build upstream Qemu by default In-Reply-To: <1315504587.3180.47.camel@cthulhu.hellion.org.uk> Message-ID: References: <1315504038-21733-1-git-send-email-stefano.stabellini@eu.citrix.com> <1315504038-21733-3-git-send-email-stefano.stabellini@eu.citrix.com> <1315504587.3180.47.camel@cthulhu.hellion.org.uk> User-Agent: Alpine 2.00 (DEB 1167 2008-08-23) MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Cc: "xen-devel@lists.xensource.com" , "keir@xen.org" , Stefano Stabellini X-BeenThere: xen-devel@lists.xensource.com X-Mailman-Version: 2.1.5 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xensource.com Errors-To: xen-devel-bounces@lists.xensource.com On Thu, 8 Sep 2011, Ian Campbell wrote: > On Thu, 2011-09-08 at 13:47 -0400, stefano.stabellini@eu.citrix.com > wrote: > > Signed-off-by: Stefano Stabellini > > > > diff -r 80ba2c7abbd2 Config.mk > > --- a/Config.mk Thu Sep 08 16:59:19 2011 +0000 > > +++ b/Config.mk Thu Sep 08 17:18:48 2011 +0000 > > @@ -192,6 +192,10 @@ else > > QEMU_REMOTE=git://xenbits.xensource.com/qemu-xen-unstable.git > > endif > > > > +# Only available through the git protocol at the moment > > +QEMU_UPSTREAM_URL ?= git://xenbits.xen.org/people/sstabellini/qemu-dm.git > > Just a nit, but we should arrange to have a "proper" tree rather than > a /people/... one for the default tree. e.g. to allow automated testing > to automatically push etc. Like Linus said, thanks to distributed version control systems, it doesn't actually matter where the repository is anymore :-) _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel From xen-devel-bounces@lists.xensource.com Fri Sep 09 03:13:41 2011 Return-path: Envelope-to: www-data@lists.xensource.com Delivery-date: Fri, 09 Sep 2011 03:13:41 -0700 Received: from localhost ([127.0.0.1] helo=lists.colo.xensource.com) by lists.xensource.com with esmtp (Exim 4.43) id 1R1y5d-0003ZN-7L; Fri, 09 Sep 2011 03:13:41 -0700 Received: from mail27.messagelabs.com ([193.109.254.147]) by lists.xensource.com with smtp (Exim 4.43) id 1R1y3D-00033E-5x for xen-devel@lists.xensource.com; Fri, 09 Sep 2011 03:11:16 -0700 X-Env-Sender: Stefano.Stabellini@eu.citrix.com X-Msg-Ref: server-3.tower-27.messagelabs.com!1315563047!38954876!1 X-Originating-IP: [62.200.22.115] X-StarScan-Version: 6.3.6; banners=-,-,- X-VirusChecked: Checked Received: (qmail 31402 invoked from network); 9 Sep 2011 10:10:47 -0000 Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115) by server-3.tower-27.messagelabs.com with SMTP; 9 Sep 2011 10:10:47 -0000 X-IronPort-AV: E=Sophos;i="4.68,355,1312156800"; d="scan'208";a="7693441" Received: from lonpmailmx01.citrite.net ([10.30.203.162]) by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5; 09 Sep 2011 10:11:08 +0000 Received: from kaball.uk.xensource.com (10.80.2.59) by LONPMAILMX01.citrite.net (10.30.203.162) with Microsoft SMTP Server id 8.3.137.0; Fri, 9 Sep 2011 11:11:07 +0100 Date: Fri, 9 Sep 2011 11:19:21 +0100 From: Stefano Stabellini X-X-Sender: sstabellini@kaball-desktop To: Ian Campbell Subject: Re: [Xen-devel] [PATCH v2 4/4] Clone and build Seabios by default In-Reply-To: <1315504825.3180.51.camel@cthulhu.hellion.org.uk> Message-ID: References: <1315504038-21733-1-git-send-email-stefano.stabellini@eu.citrix.com> <1315504038-21733-4-git-send-email-stefano.stabellini@eu.citrix.com> <1315504825.3180.51.camel@cthulhu.hellion.org.uk> User-Agent: Alpine 2.00 (DEB 1167 2008-08-23) MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Cc: "xen-devel@lists.xensource.com" , "keir@xen.org" , Stefano Stabellini X-BeenThere: xen-devel@lists.xensource.com X-Mailman-Version: 2.1.5 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xensource.com Errors-To: xen-devel-bounces@lists.xensource.com On Thu, 8 Sep 2011, Ian Campbell wrote: > On Thu, 2011-09-08 at 13:47 -0400, stefano.stabellini@eu.citrix.com > wrote: > > Signed-off-by: Stefano Stabellini > > > > diff -r ef27b472d4f3 Config.mk > > --- a/Config.mk Thu Sep 08 17:19:12 2011 +0000 > > +++ b/Config.mk Thu Sep 08 17:29:50 2011 +0000 > > @@ -195,6 +195,8 @@ endif > > # Only available through the git protocol at the moment > > QEMU_UPSTREAM_URL ?= git://xenbits.xen.org/people/sstabellini/qemu-dm.git > > QEMU_UPSTREAM_TAG ?= origin/xen-stable-0.15 > > +SEABIOS_UPSTREAM_URL=git://git.qemu.org/seabios.git > > +SEABIOS_UPSTREAM_TAG ?= 7fc039e9c262b4199fab497f3e12f4e425c37560 > > I guess we should have a default tree on xenbits for this? I am not sure it is a good idea, after all we don't plan to fork it, right? It is the same thing as with ipxe: we just use the official repo. > [...] > > +$(SEABIOS_DIR): > > + set -ex; \ > > + if [ ! -d seabios-remote ]; then \ > > + rm -rf seabios-remote seabios-remote.tmp; \ > > + mkdir seabios-remote.tmp; rmdir seabios-remote.tmp; \ > > + $(GIT) clone $(SEABIOS_UPSTREAM_URL) seabios-remote.tmp; \ > > + if [ "$(SEABIOS_UPSTREAM_TAG)" ]; then \ > > + cd seabios-remote.tmp; \ > > + $(GIT) branch -D dummy >/dev/null 2>&1 ||:; \ > > + $(GIT) checkout -b dummy $(SEABIOS_UPSTREAM_TAG); \ > > + cd ..; \ > > + fi; \ > > + mv seabios-remote.tmp seabios-remote; \ > > + fi; \ > > + rm -f seabios-dir; \ > > + ln -sf seabios-remote seabios-dir; \ > > + cp seabios-config seabios-dir/.config; > > This looks a lot like the qemu stuff which you only just moved into its > own script. Can we not share it? Yep, I'll do that. _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel From xen-devel-bounces@lists.xensource.com Fri Sep 09 03:37:45 2011 Return-path: Envelope-to: www-data@lists.xensource.com Delivery-date: Fri, 09 Sep 2011 03:37:45 -0700 Received: from localhost ([127.0.0.1] helo=lists.colo.xensource.com) by lists.xensource.com with esmtp (Exim 4.43) id 1R1ySv-0004SC-NV; Fri, 09 Sep 2011 03:37:45 -0700 Received: from mail174.messagelabs.com ([85.158.138.51]) by lists.xensource.com with esmtp (Exim 4.43) id 1R1ySF-0004Fi-Ck for xen-devel@lists.xensource.com; Fri, 09 Sep 2011 03:37:03 -0700 X-Env-Sender: dunlapg@gmail.com X-Msg-Ref: server-11.tower-174.messagelabs.com!1315564619!30824067!1 X-Originating-IP: [74.125.82.41] X-StarScan-Version: 6.3.6; banners=-,-,- X-VirusChecked: Checked Received: (qmail 28096 invoked from network); 9 Sep 2011 10:37:00 -0000 Received: from mail-ww0-f41.google.com (HELO mail-ww0-f41.google.com) (74.125.82.41) by server-11.tower-174.messagelabs.com with RC4-SHA encrypted SMTP; 9 Sep 2011 10:37:00 -0000 Received: by wwi18 with SMTP id 18so1512439wwi.0 for ; Fri, 09 Sep 2011 03:36:55 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=OTn8b3fIhJaOzq3+jnn3CreOfPfH67zlG+ZWZ9QU58w=; b=eGGMEUMkpkNPiIBtpxo/NwguZHid7InqkNItSe3dlczloxsb1aJj/CG9eX4ZrJF1p6 ZdPnleEwEe0kEkHeFioYs32B/O/Hommhtp+lF6Gla+oxYflwu6vlY18+MI3+j72nvJB+ OXQA4PbUKExM9TIZgMfeXRMDq2+YwLXWWnoWI= MIME-Version: 1.0 Received: by 10.216.229.88 with SMTP id g66mr1028788weq.9.1315564615668; Fri, 09 Sep 2011 03:36:55 -0700 (PDT) Received: by 10.216.176.81 with HTTP; Fri, 9 Sep 2011 03:36:55 -0700 (PDT) In-Reply-To: References: <1315504038-21733-1-git-send-email-stefano.stabellini@eu.citrix.com> <1315504038-21733-4-git-send-email-stefano.stabellini@eu.citrix.com> <1315504825.3180.51.camel@cthulhu.hellion.org.uk> Date: Fri, 9 Sep 2011 11:36:55 +0100 X-Google-Sender-Auth: YJjCVEfjz8xXpwaYJxTHAMRt-b4 Message-ID: Subject: Re: [Xen-devel] [PATCH v2 4/4] Clone and build Seabios by default From: George Dunlap To: Stefano Stabellini Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: "xen-devel@lists.xensource.com" , "keir@xen.org" , Ian Campbell X-BeenThere: xen-devel@lists.xensource.com X-Mailman-Version: 2.1.5 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xensource.com Errors-To: xen-devel-bounces@lists.xensource.com On Fri, Sep 9, 2011 at 11:19 AM, Stefano Stabellini wrote: > On Thu, 8 Sep 2011, Ian Campbell wrote: >> On Thu, 2011-09-08 at 13:47 -0400, stefano.stabellini@eu.citrix.com >> wrote: >> > Signed-off-by: Stefano Stabellini >> > >> > diff -r ef27b472d4f3 Config.mk >> > --- a/Config.mk =A0 =A0 Thu Sep 08 17:19:12 2011 +0000 >> > +++ b/Config.mk =A0 =A0 Thu Sep 08 17:29:50 2011 +0000 >> > @@ -195,6 +195,8 @@ endif >> > =A0# Only available through the git protocol at the moment >> > =A0QEMU_UPSTREAM_URL ?=3D git://xenbits.xen.org/people/sstabellini/qem= u-dm.git >> > =A0QEMU_UPSTREAM_TAG ?=3D origin/xen-stable-0.15 >> > +SEABIOS_UPSTREAM_URL=3Dgit://git.qemu.org/seabios.git >> > +SEABIOS_UPSTREAM_TAG ?=3D 7fc039e9c262b4199fab497f3e12f4e425c37560 >> >> I guess we should have a default tree on xenbits for this? > > I am not sure it is a good idea, after all we don't plan to fork it, > right? > It is the same thing as with ipxe: we just use the official repo. But that means that if the sites hosting ipxe or qemu go down, people can't build Xen. Keeping a copy on xen.org removes external dependencies we don't have any control over. > > > >> [...] >> > +$(SEABIOS_DIR): >> > + =A0 set -ex; \ >> > + =A0 if [ ! -d seabios-remote ]; then \ >> > + =A0 =A0 =A0 =A0 =A0 rm -rf seabios-remote seabios-remote.tmp; \ >> > + =A0 =A0 =A0 =A0 =A0 mkdir seabios-remote.tmp; rmdir seabios-remote.t= mp; \ >> > + =A0 =A0 =A0 =A0 =A0 $(GIT) clone $(SEABIOS_UPSTREAM_URL) seabios-rem= ote.tmp; \ >> > + =A0 =A0 =A0 =A0 =A0 if [ "$(SEABIOS_UPSTREAM_TAG)" ]; then =A0 =A0 = =A0 =A0 =A0 =A0 =A0 =A0 =A0\ >> > + =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 cd seabios-remote.tmp; =A0 =A0 = =A0 =A0 =A0 =A0 =A0 =A0 =A0\ >> > + =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 $(GIT) branch -D dummy >/dev/nul= l 2>&1 ||:; \ >> > + =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 $(GIT) checkout -b dummy $(SEABI= OS_UPSTREAM_TAG); =A0 =A0 =A0 \ >> > + =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 cd ..; =A0 =A0 =A0 =A0 =A0 =A0 = =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0\ >> > + =A0 =A0 =A0 =A0 =A0 fi; =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 = =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 \ >> > + =A0 =A0 =A0 =A0 =A0 mv seabios-remote.tmp seabios-remote; \ >> > + =A0 fi; \ >> > + =A0 rm -f seabios-dir; \ >> > + =A0 ln -sf seabios-remote seabios-dir; \ >> > + =A0 cp seabios-config seabios-dir/.config; >> >> This looks a lot like the qemu stuff which you only just moved into its >> own script. Can we not share it? > > Yep, I'll do that. > > > > _______________________________________________ > Xen-devel mailing list > Xen-devel@lists.xensource.com > http://lists.xensource.com/xen-devel > _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel From xen-devel-bounces@lists.xensource.com Fri Sep 09 03:39:09 2011 Return-path: Envelope-to: www-data@lists.xensource.com Delivery-date: Fri, 09 Sep 2011 03:39:09 -0700 Received: from localhost ([127.0.0.1] helo=lists.colo.xensource.com) by lists.xensource.com with esmtp (Exim 4.43) id 1R1yUH-0004pl-Jn; Fri, 09 Sep 2011 03:39:09 -0700 Received: from mail174.messagelabs.com ([85.158.138.51]) by lists.xensource.com with smtp (Exim 4.43) id 1R1yTg-0004dP-3l for xen-devel@lists.xensource.com; Fri, 09 Sep 2011 03:38:32 -0700 X-Env-Sender: Stefano.Stabellini@eu.citrix.com X-Msg-Ref: server-2.tower-174.messagelabs.com!1315564707!30826493!1 X-Originating-IP: [62.200.22.115] X-StarScan-Version: 6.3.6; banners=-,-,- X-VirusChecked: Checked Received: (qmail 20088 invoked from network); 9 Sep 2011 10:38:28 -0000 Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115) by server-2.tower-174.messagelabs.com with SMTP; 9 Sep 2011 10:38:28 -0000 X-IronPort-AV: E=Sophos;i="4.68,355,1312156800"; d="scan'208";a="7694169" Received: from lonpmailmx01.citrite.net ([10.30.203.162]) by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5; 09 Sep 2011 10:38:25 +0000 Received: from kaball.uk.xensource.com (10.80.2.59) by LONPMAILMX01.citrite.net (10.30.203.162) with Microsoft SMTP Server id 8.3.137.0; Fri, 9 Sep 2011 11:38:25 +0100 Date: Fri, 9 Sep 2011 11:46:38 +0100 From: Stefano Stabellini X-X-Sender: sstabellini@kaball-desktop To: George Dunlap Subject: Re: [Xen-devel] [PATCH v2 4/4] Clone and build Seabios by default In-Reply-To: Message-ID: References: <1315504038-21733-1-git-send-email-stefano.stabellini@eu.citrix.com> <1315504038-21733-4-git-send-email-stefano.stabellini@eu.citrix.com> <1315504825.3180.51.camel@cthulhu.hellion.org.uk> User-Agent: Alpine 2.00 (DEB 1167 2008-08-23) MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="8323329-121865035-1315565214=:12963" Cc: Ian Campbell , "xen-devel@lists.xensource.com" , "keir@xen.org" , Stefano Stabellini X-BeenThere: xen-devel@lists.xensource.com X-Mailman-Version: 2.1.5 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xensource.com Errors-To: xen-devel-bounces@lists.xensource.com --8323329-121865035-1315565214=:12963 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: 8BIT On Fri, 9 Sep 2011, George Dunlap wrote: > On Fri, Sep 9, 2011 at 11:19 AM, Stefano Stabellini > wrote: > > On Thu, 8 Sep 2011, Ian Campbell wrote: > >> On Thu, 2011-09-08 at 13:47 -0400, stefano.stabellini@eu.citrix.com > >> wrote: > >> > Signed-off-by: Stefano Stabellini > >> > > >> > diff -r ef27b472d4f3 Config.mk > >> > --- a/Config.mk     Thu Sep 08 17:19:12 2011 +0000 > >> > +++ b/Config.mk     Thu Sep 08 17:29:50 2011 +0000 > >> > @@ -195,6 +195,8 @@ endif > >> >  # Only available through the git protocol at the moment > >> >  QEMU_UPSTREAM_URL ?= git://xenbits.xen.org/people/sstabellini/qemu-dm.git > >> >  QEMU_UPSTREAM_TAG ?= origin/xen-stable-0.15 > >> > +SEABIOS_UPSTREAM_URL=git://git.qemu.org/seabios.git > >> > +SEABIOS_UPSTREAM_TAG ?= 7fc039e9c262b4199fab497f3e12f4e425c37560 > >> > >> I guess we should have a default tree on xenbits for this? > > > > I am not sure it is a good idea, after all we don't plan to fork it, > > right? > > It is the same thing as with ipxe: we just use the official repo. > > But that means that if the sites hosting ipxe or qemu go down, people > can't build Xen. Keeping a copy on xen.org removes external > dependencies we don't have any control over. AKA single point of failure? --8323329-121865035-1315565214=:12963 Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel --8323329-121865035-1315565214=:12963-- From xen-devel-bounces@lists.xensource.com Fri Sep 09 04:11:54 2011 Return-path: Envelope-to: www-data@lists.xensource.com Delivery-date: Fri, 09 Sep 2011 04:11:54 -0700 Received: from localhost ([127.0.0.1] helo=lists.colo.xensource.com) by lists.xensource.com with esmtp (Exim 4.43) id 1R1yzx-0005y3-AJ; Fri, 09 Sep 2011 04:11:53 -0700 Received: from mail174.messagelabs.com ([85.158.138.51]) by lists.xensource.com with smtp (Exim 4.43) id 1R1ywR-0005gK-6B for xen-devel@lists.xensource.com; Fri, 09 Sep 2011 04:08:19 -0700 X-Env-Sender: Stefano.Stabellini@eu.citrix.com X-Msg-Ref: server-9.tower-174.messagelabs.com!1315566491!24796524!1 X-Originating-IP: [62.200.22.115] X-StarScan-Version: 6.3.6; banners=-,-,- X-VirusChecked: Checked Received: (qmail 12403 invoked from network); 9 Sep 2011 11:08:12 -0000 Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115) by server-9.tower-174.messagelabs.com with SMTP; 9 Sep 2011 11:08:12 -0000 X-IronPort-AV: E=Sophos;i="4.68,355,1312156800"; d="scan'208";a="7694865" Received: from lonpmailmx01.citrite.net ([10.30.203.162]) by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5; 09 Sep 2011 11:08:02 +0000 Received: from kaball.uk.xensource.com (10.80.2.59) by LONPMAILMX01.citrite.net (10.30.203.162) with Microsoft SMTP Server id 8.3.137.0; Fri, 9 Sep 2011 12:08:02 +0100 Date: Fri, 9 Sep 2011 12:16:16 +0100 From: Stefano Stabellini X-X-Sender: sstabellini@kaball-desktop To: Message-ID: User-Agent: Alpine 2.00 (DEB 1167 2008-08-23) MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Cc: Keir Fraser , Ian Campbell , Stefano Stabellini Subject: [Xen-devel] [PATCH v3] build upstream qemu and seabios by default X-BeenThere: xen-devel@lists.xensource.com X-Mailman-Version: 2.1.5 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xensource.com Errors-To: xen-devel-bounces@lists.xensource.com Hi all, this is the third version of the patch series to introduce upstream qemu and seabios in the xen-unstable build system. Changes to v2: - move tools/git-checkout.sh to scripts/git-checkout.sh; - use git-checkout.sh for seabios; - improve seabios integration with tools/firmware make system; - add qemu-xen-traditional, qemu-xen and seabios dir entries to .hgignore. Changes to v1: - always build upstream qemu and seabios, rather than introducing them as an option. Cheers, Stefano _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel From xen-devel-bounces@lists.xensource.com Fri Sep 09 04:13:13 2011 Return-path: Envelope-to: www-data@lists.xensource.com Delivery-date: Fri, 09 Sep 2011 04:13:13 -0700 Received: from localhost ([127.0.0.1] helo=lists.colo.xensource.com) by lists.xensource.com with esmtp (Exim 4.43) id 1R1z1E-0006Lp-RD; Fri, 09 Sep 2011 04:13:12 -0700 Received: from mail21.messagelabs.com ([85.158.143.35]) by lists.xensource.com with esmtp (Exim 4.43) id 1R1yxh-0005p1-OW for xen-devel@lists.xensource.com; Fri, 09 Sep 2011 04:11:24 -0700 X-Env-Sender: Stefano.Stabellini@eu.citrix.com X-Msg-Ref: server-12.tower-21.messagelabs.com!1315566555!49311461!1 X-Originating-IP: [66.165.176.89] X-StarScan-Version: 6.3.6; banners=-,-,- X-VirusChecked: Checked Received: (qmail 19650 invoked from network); 9 Sep 2011 11:09:16 -0000 Received: from smtp.citrix.com (HELO SMTP.CITRIX.COM) (66.165.176.89) by server-12.tower-21.messagelabs.com with RC4-SHA encrypted SMTP; 9 Sep 2011 11:09:16 -0000 X-IronPort-AV: E=Sophos;i="4.68,355,1312171200"; d="scan'208";a="16821327" Received: from ftlpmailmx02.citrite.net ([10.13.107.66]) by FTLPIPO01.CITRIX.COM with ESMTP/TLS/RC4-MD5; 09 Sep 2011 07:09:29 -0400 Received: from smtp01.ad.xensource.com (10.219.128.104) by smtprelay.citrix.com (10.13.107.66) with Microsoft SMTP Server id 8.3.137.0; Fri, 9 Sep 2011 07:09:29 -0400 Received: from localhost.localdomain (kaball.uk.xensource.com [10.80.2.59]) by smtp01.ad.xensource.com (8.13.1/8.13.1) with ESMTP id p89B9LGU031889; Fri, 9 Sep 2011 04:09:22 -0700 From: To: xen-devel@lists.xensource.com Date: Fri, 9 Sep 2011 12:17:46 +0100 Message-ID: <1315567069-28775-1-git-send-email-stefano.stabellini@eu.citrix.com> X-Mailer: git-send-email 1.7.0.4 In-Reply-To: References: MIME-Version: 1.0 Content-Type: text/plain Cc: Stefano Stabellini , keir@xen.org, Ian.Campbell@citrix.com, Stefano.Stabellini@eu.citrix.com Subject: [Xen-devel] [PATCH v3 1/4] Move the ioemu-dir-find shell script to an external file X-BeenThere: xen-devel@lists.xensource.com X-Mailman-Version: 2.1.5 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xensource.com Errors-To: xen-devel-bounces@lists.xensource.com Add support for configuring upstream qemu and rename ioemu-remote ioemu-dir-remote. Signed-off-by: Stefano Stabellini diff --git a/.hgignore b/.hgignore --- a/.hgignore +++ b/.hgignore @@ -291,7 +291,7 @@ ^tools/xm-test/lib/XmTestLib/config.py$ ^tools/xm-test/lib/XmTestReport/xmtest.py$ ^tools/xm-test/tests/.*\.test$ -^tools/ioemu-remote +^tools/ioemu-dir-remote ^tools/ioemu-dir$ ^tools/ocaml/.*/.*\.annot$ ^tools/ocaml/.*/.*\.cmx?a$ diff --git a/scripts/git-checkout.sh b/scripts/git-checkout.sh new file mode 100755 --- /dev/null +++ b/scripts/git-checkout.sh @@ -0,0 +1,46 @@ +#!/bin/bash + +TREE=$1 +TAG=$2 +DIR=$3 + + +if test -d $TREE; then + mkdir -p $DIR + ROOT=$TREE +else + if test \! -d $DIR-remote; then + rm -rf $DIR-remote $DIR-remote.tmp; + mkdir $DIR-remote.tmp; rmdir $DIR-remote.tmp; + git clone $TREE $DIR-remote.tmp; + if test "$TAG" ; then + cd $DIR-remote.tmp + git branch -D dummy >/dev/null 2>&1 ||: + git checkout -b dummy $TAG + cd .. + fi + mv $DIR-remote.tmp $DIR-remote + fi + rm -f $DIR + ln -sf $DIR-remote $DIR + ROOT=. +fi + +set -e +cd $DIR +# is this qemu-xen-traditional? +if test -f $ROOT/xen-setup; then + $ROOT/xen-setup $IOEMU_CONFIGURE_CROSS +# is this qemu-xen? +elif test -f $ROOT/configure; then + cd $ROOT + ./configure --enable-xen --target-list=i386-softmmu \ + --extra-cflags="-I$XEN_ROOT/tools/include \ + -I$XEN_ROOT/tools/libxc \ + -I$XEN_ROOT/tools/xenstore" \ + --extra-ldflags="-L$XEN_ROOT/tools/libxc \ + -L$XEN_ROOT/tools/libxenstore" \ + --bindir=/usr/lib/xen/bin \ + --disable-kvm \ + $IOEMU_CONFIGURE_CROSS +fi diff --git a/tools/Makefile b/tools/Makefile --- a/tools/Makefile +++ b/tools/Makefile @@ -70,7 +70,7 @@ clean: subdirs-clean .PHONY: distclean distclean: subdirs-distclean - rm -rf ioemu-dir ioemu-remote + rm -rf ioemu-dir ioemu-dir-remote ifneq ($(XEN_COMPILE_ARCH),$(XEN_TARGET_ARCH)) IOEMU_CONFIGURE_CROSS ?= --cpu=$(XEN_TARGET_ARCH) \ @@ -78,41 +78,14 @@ IOEMU_CONFIGURE_CROSS ?= --cpu=$(XEN_TAR --interp-prefix=$(CROSS_SYS_ROOT) endif -QEMU_ROOT := $(shell if [ -d "$(CONFIG_QEMU)" ]; then echo "$(CONFIG_QEMU)"; else echo .; fi) -ifneq ($(QEMU_ROOT),.) -export QEMU_ROOT -endif - ioemu-dir-find: - set -ex; \ - if test -d $(CONFIG_QEMU); then \ - mkdir -p ioemu-dir; \ - else \ - if [ ! -d ioemu-remote ]; then \ - rm -rf ioemu-remote ioemu-remote.tmp; \ - mkdir ioemu-remote.tmp; rmdir ioemu-remote.tmp; \ - $(GIT) clone $(CONFIG_QEMU) ioemu-remote.tmp; \ - if [ "$(QEMU_TAG)" ]; then \ - cd ioemu-remote.tmp; \ - $(GIT) branch -D dummy >/dev/null 2>&1 ||:; \ - $(GIT) checkout -b dummy $(QEMU_TAG); \ - cd ..; \ - fi; \ - mv ioemu-remote.tmp ioemu-remote; \ - fi; \ - rm -f ioemu-dir; \ - ln -sf ioemu-remote ioemu-dir; \ - fi - set -e; \ - $(buildmakevars2shellvars); \ - cd ioemu-dir; \ - $(QEMU_ROOT)/xen-setup $(IOEMU_CONFIGURE_CROSS) - + $(XEN_ROOT)/scripts/git-checkout.sh $(CONFIG_QEMU) $(QEMU_TAG) ioemu-dir + .PHONY: ioemu-dir-force-update ioemu-dir-force-update: set -ex; \ if [ "$(QEMU_TAG)" ]; then \ - cd ioemu-remote; \ + cd ioemu-dir-remote; \ $(GIT) fetch origin; \ $(GIT) reset --hard $(QEMU_TAG); \ fi _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel From xen-devel-bounces@lists.xensource.com Fri Sep 09 04:14:00 2011 Return-path: Envelope-to: www-data@lists.xensource.com Delivery-date: Fri, 09 Sep 2011 04:14:00 -0700 Received: from localhost ([127.0.0.1] helo=lists.colo.xensource.com) by lists.xensource.com with esmtp (Exim 4.43) id 1R1z1z-0006hw-SM; Fri, 09 Sep 2011 04:14:00 -0700 Received: from mail182.messagelabs.com ([85.158.139.83]) by lists.xensource.com with esmtp (Exim 4.43) id 1R1yxp-0005pC-Lx for xen-devel@lists.xensource.com; Fri, 09 Sep 2011 04:11:24 -0700 X-Env-Sender: Stefano.Stabellini@eu.citrix.com X-Msg-Ref: server-8.tower-182.messagelabs.com!1315566575!17696127!2 X-Originating-IP: [66.165.176.63] X-StarScan-Version: 6.3.6; banners=-,-,- X-VirusChecked: Checked Received: (qmail 12572 invoked from network); 9 Sep 2011 11:09:38 -0000 Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63) by server-8.tower-182.messagelabs.com with RC4-SHA encrypted SMTP; 9 Sep 2011 11:09:38 -0000 X-IronPort-AV: E=Sophos;i="4.68,355,1312171200"; d="scan'208";a="162301752" Received: from ftlpmailmx02.citrite.net ([10.13.107.66]) by FTLPIPO02.CITRIX.COM with ESMTP/TLS/RC4-MD5; 09 Sep 2011 07:09:38 -0400 Received: from smtp01.ad.xensource.com (10.219.128.104) by smtprelay.citrix.com (10.13.107.66) with Microsoft SMTP Server id 8.3.137.0; Fri, 9 Sep 2011 07:09:37 -0400 Received: from localhost.localdomain (kaball.uk.xensource.com [10.80.2.59]) by smtp01.ad.xensource.com (8.13.1/8.13.1) with ESMTP id p89B9LGX031889; Fri, 9 Sep 2011 04:09:26 -0700 From: To: xen-devel@lists.xensource.com Date: Fri, 9 Sep 2011 12:17:49 +0100 Message-ID: <1315567069-28775-4-git-send-email-stefano.stabellini@eu.citrix.com> X-Mailer: git-send-email 1.7.0.4 In-Reply-To: References: MIME-Version: 1.0 Content-Type: text/plain Cc: Stefano Stabellini , keir@xen.org, Ian.Campbell@citrix.com, Stefano.Stabellini@eu.citrix.com Subject: [Xen-devel] [PATCH v3 2/4] Clone and build Seabios by default X-BeenThere: xen-devel@lists.xensource.com X-Mailman-Version: 2.1.5 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xensource.com Errors-To: xen-devel-bounces@lists.xensource.com Signed-off-by: Stefano Stabellini diff -r b62e9640049f .hgignore --- a/.hgignore Fri Sep 09 10:35:45 2011 +0000 +++ b/.hgignore Fri Sep 09 11:03:38 2011 +0000 @@ -295,6 +295,8 @@ ^tools/qemu-xen-traditional-dir$ ^tools/qemu-xen-dir-remote ^tools/qemu-xen-dir$ +^tools/tools/firmware/seabios-dir-remote +^tools/tools/firmware/seabios-dir$ ^tools/ocaml/.*/.*\.annot$ ^tools/ocaml/.*/.*\.cmx?a$ ^tools/ocaml/.*/META$ diff -r b62e9640049f Config.mk --- a/Config.mk Fri Sep 09 10:35:45 2011 +0000 +++ b/Config.mk Fri Sep 09 11:03:38 2011 +0000 @@ -195,6 +195,8 @@ endif # Only available through the git protocol at the moment QEMU_UPSTREAM_URL ?= git://xenbits.xen.org/people/sstabellini/qemu-dm.git QEMU_UPSTREAM_TAG ?= origin/xen-stable-0.15 +SEABIOS_UPSTREAM_URL=git://git.qemu.org/seabios.git +SEABIOS_UPSTREAM_TAG ?= 7fc039e9c262b4199fab497f3e12f4e425c37560 # Specify which qemu-dm to use. This may be `ioemu' to use the old # Mercurial in-tree version, or a local directory, or a git URL. @@ -208,15 +210,6 @@ QEMU_TAG ?= cd776ee9408ff127f934a707c1a3 # Short answer -- do not enable this unless you know what you are # doing and are prepared for some pain. -# SeaBIOS integration is a work in progress. Before enabling this -# option you must clone git://git.qemu.org/seabios.git/, possibly add -# some development patches and then build it yourself before pointing -# this variable to it (using an absolute path). -# -# Note that using SeaBIOS requires the use the upstream qemu as the -# device model. -SEABIOS_DIR ?= - # Optional components XENSTAT_XENTOP ?= y VTPM_TOOLS ?= n diff -r b62e9640049f tools/firmware/Makefile --- a/tools/firmware/Makefile Fri Sep 09 10:35:45 2011 +0000 +++ b/tools/firmware/Makefile Fri Sep 09 11:03:38 2011 +0000 @@ -6,13 +6,18 @@ TARGET := hvmloader/hvmloader INST_DIR := $(DESTDIR)$(XENFIRMWAREDIR) SUBDIRS := +SUBDIRS += seabios-dir SUBDIRS += rombios SUBDIRS += vgabios SUBDIRS += etherboot SUBDIRS += hvmloader +seabios-dir: + $(XEN_ROOT)/scripts/git-checkout.sh $(SEABIOS_UPSTREAM_URL) $(SEABIOS_UPSTREAM_TAG) seabios-dir + cp seabios-config seabios-dir/.config; + .PHONY: all -all: +all: seabios-dir @set -e; if [ $$((`( bcc -v 2>&1 | grep version || echo 0.0.0 ) | cut -d' ' -f 3 | awk -F. '{ printf "0x%02x%02x%02x", $$1, $$2, $$3}'`)) -lt $$((0x00100e)) ] ; then \ echo "==========================================================================="; \ echo "Require dev86 rpm or bin86 & bcc debs version >= 0.16.14 to build firmware!"; \ @@ -35,4 +40,7 @@ clean: subdirs-clean distclean: subdirs-distclean subdir-distclean-etherboot: .phony - $(MAKE) -C etherboot distclean \ No newline at end of file + $(MAKE) -C etherboot distclean + +subdir-distclean-seabios-dir: .phony + rm -rf seabios-dir seabios-dir-remote diff -r b62e9640049f tools/firmware/hvmloader/Makefile --- a/tools/firmware/hvmloader/Makefile Fri Sep 09 10:35:45 2011 +0000 +++ b/tools/firmware/hvmloader/Makefile Fri Sep 09 11:03:38 2011 +0000 @@ -44,6 +44,7 @@ CFLAGS += -DENABLE_ROMBIOS ROMBIOS_ROM := $(ROMBIOS_DIR)/BIOS-bochs-latest endif +SEABIOS_DIR := ../seabios-dir ifneq ($(SEABIOS_DIR),) OBJS += seabios.o CFLAGS += -DENABLE_SEABIOS diff -r b62e9640049f tools/firmware/seabios-config --- /dev/null Thu Jan 01 00:00:00 1970 +0000 +++ b/tools/firmware/seabios-config Fri Sep 09 11:03:38 2011 +0000 @@ -0,0 +1,73 @@ +# +# Automatically generated make config: don't edit +# SeaBIOS Configuration +# Wed Sep 7 13:03:21 2011 +# + +# +# General Features +# +# CONFIG_COREBOOT is not set +CONFIG_XEN=y +CONFIG_THREADS=y +# CONFIG_THREAD_OPTIONROMS is not set +CONFIG_RELOCATE_INIT=y +CONFIG_BOOTMENU=y +# CONFIG_BOOTSPLASH is not set +CONFIG_BOOTORDER=y + +# +# Hardware support +# +CONFIG_ATA=y +CONFIG_ATA_DMA=y +CONFIG_ATA_PIO32=y +CONFIG_AHCI=y +CONFIG_VIRTIO_BLK=y +CONFIG_FLOPPY=y +CONFIG_PS2PORT=y +CONFIG_USB=y +CONFIG_USB_UHCI=y +CONFIG_USB_OHCI=y +CONFIG_USB_EHCI=y +CONFIG_USB_MSC=y +CONFIG_USB_HUB=y +CONFIG_USB_KEYBOARD=y +CONFIG_USB_MOUSE=y +CONFIG_SERIAL=y +CONFIG_LPT=y +# CONFIG_USE_SMM is not set +CONFIG_MTRR_INIT=y + +# +# BIOS interfaces +# +CONFIG_DRIVES=y +CONFIG_CDROM_BOOT=y +CONFIG_CDROM_EMU=y +CONFIG_PCIBIOS=y +CONFIG_APMBIOS=y +CONFIG_PNPBIOS=y +CONFIG_OPTIONROMS=y +# CONFIG_OPTIONROMS_DEPLOYED is not set +CONFIG_PMM=y +CONFIG_BOOT=y +CONFIG_KEYBOARD=y +CONFIG_KBD_CALL_INT15_4F=y +CONFIG_MOUSE=y +CONFIG_S3_RESUME=y +# CONFIG_DISABLE_A20 is not set + +# +# BIOS Tables +# +CONFIG_PIRTABLE=y +CONFIG_MPTABLE=y +CONFIG_SMBIOS=y +CONFIG_ACPI=y + +# +# Debugging +# +CONFIG_DEBUG_LEVEL=1 +# CONFIG_DEBUG_SERIAL is not set _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel From xen-devel-bounces@lists.xensource.com Fri Sep 09 04:14:48 2011 Return-path: Envelope-to: www-data@lists.xensource.com Delivery-date: Fri, 09 Sep 2011 04:14:48 -0700 Received: from localhost ([127.0.0.1] helo=lists.colo.xensource.com) by lists.xensource.com with esmtp (Exim 4.43) id 1R1z2l-00074f-RG; Fri, 09 Sep 2011 04:14:47 -0700 Received: from mail27.messagelabs.com ([193.109.254.147]) by lists.xensource.com with esmtp (Exim 4.43) id 1R1yxx-0005pr-OB for xen-devel@lists.xensource.com; Fri, 09 Sep 2011 04:11:24 -0700 X-Env-Sender: Stefano.Stabellini@eu.citrix.com X-Msg-Ref: server-11.tower-27.messagelabs.com!1315566578!36724459!1 X-Originating-IP: [66.165.176.89] X-StarScan-Version: 6.3.6; banners=-,-,- X-VirusChecked: Checked Received: (qmail 27044 invoked from network); 9 Sep 2011 11:09:39 -0000 Received: from smtp.citrix.com (HELO SMTP.CITRIX.COM) (66.165.176.89) by server-11.tower-27.messagelabs.com with RC4-SHA encrypted SMTP; 9 Sep 2011 11:09:39 -0000 X-IronPort-AV: E=Sophos;i="4.68,355,1312171200"; d="scan'208";a="16821328" Received: from ftlpmailmx02.citrite.net ([10.13.107.66]) by FTLPIPO01.CITRIX.COM with ESMTP/TLS/RC4-MD5; 09 Sep 2011 07:09:36 -0400 Received: from smtp01.ad.xensource.com (10.219.128.104) by smtprelay.citrix.com (10.13.107.66) with Microsoft SMTP Server id 8.3.137.0; Fri, 9 Sep 2011 07:09:36 -0400 Received: from localhost.localdomain (kaball.uk.xensource.com [10.80.2.59]) by smtp01.ad.xensource.com (8.13.1/8.13.1) with ESMTP id p89B9LGW031889; Fri, 9 Sep 2011 04:09:25 -0700 From: To: xen-devel@lists.xensource.com Date: Fri, 9 Sep 2011 12:17:48 +0100 Message-ID: <1315567069-28775-3-git-send-email-stefano.stabellini@eu.citrix.com> X-Mailer: git-send-email 1.7.0.4 In-Reply-To: References: MIME-Version: 1.0 Content-Type: text/plain Cc: Stefano Stabellini , keir@xen.org, Ian.Campbell@citrix.com, Stefano.Stabellini@eu.citrix.com Subject: [Xen-devel] [PATCH v3 2/4] Clone and build upstream Qemu by default X-BeenThere: xen-devel@lists.xensource.com X-Mailman-Version: 2.1.5 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xensource.com Errors-To: xen-devel-bounces@lists.xensource.com Signed-off-by: Stefano Stabellini diff -r 4280714efabd .hgignore --- a/.hgignore Fri Sep 09 10:35:08 2011 +0000 +++ b/.hgignore Fri Sep 09 10:35:45 2011 +0000 @@ -293,6 +293,8 @@ ^tools/xm-test/tests/.*\.test$ ^tools/qemu-xen-traditional-dir-remote ^tools/qemu-xen-traditional-dir$ +^tools/qemu-xen-dir-remote +^tools/qemu-xen-dir$ ^tools/ocaml/.*/.*\.annot$ ^tools/ocaml/.*/.*\.cmx?a$ ^tools/ocaml/.*/META$ diff -r 4280714efabd Config.mk --- a/Config.mk Fri Sep 09 10:35:08 2011 +0000 +++ b/Config.mk Fri Sep 09 10:35:45 2011 +0000 @@ -192,6 +192,10 @@ else QEMU_REMOTE=git://xenbits.xensource.com/qemu-xen-unstable.git endif +# Only available through the git protocol at the moment +QEMU_UPSTREAM_URL ?= git://xenbits.xen.org/people/sstabellini/qemu-dm.git +QEMU_UPSTREAM_TAG ?= origin/xen-stable-0.15 + # Specify which qemu-dm to use. This may be `ioemu' to use the old # Mercurial in-tree version, or a local directory, or a git URL. # CONFIG_QEMU ?= `pwd`/$(XEN_ROOT)/../qemu-xen.git diff -r 4280714efabd Makefile --- a/Makefile Fri Sep 09 10:35:08 2011 +0000 +++ b/Makefile Fri Sep 09 10:35:45 2011 +0000 @@ -70,7 +70,7 @@ install-tools: $(MAKE) -C tools install ifeq ($(CONFIG_IOEMU),y) -install-tools: tools/qemu-xen-traditional-dir +install-tools: tools/qemu-xen-traditional-dir tools/qemu-xen-dir endif .PHONY: install-kernels @@ -91,6 +91,9 @@ tools/qemu-xen-traditional-dir: tools/qemu-xen-traditional-dir-force-update: $(MAKE) -C tools qemu-xen-traditional-dir-force-update +tools/qemu-xen-dir: + $(MAKE) -C tools qemu-xen-dir-find + .PHONY: install-docs install-docs: sh ./docs/check_pkgs && $(MAKE) -C docs install || true diff -r 4280714efabd tools/Makefile --- a/tools/Makefile Fri Sep 09 10:35:08 2011 +0000 +++ b/tools/Makefile Fri Sep 09 10:35:45 2011 +0000 @@ -31,6 +31,7 @@ SUBDIRS-$(LIBXENAPI_BINDINGS) += libxen # do not recurse in to a dir we are about to delete ifneq "$(MAKECMDGOALS)" "distclean" SUBDIRS-$(CONFIG_IOEMU) += qemu-xen-traditional-dir +SUBDIRS-$(CONFIG_IOEMU) += qemu-xen-dir endif SUBDIRS-y += xenpmd @@ -71,6 +72,7 @@ clean: subdirs-clean .PHONY: distclean distclean: subdirs-distclean rm -rf qemu-xen-traditional-dir qemu-xen-traditional-dir-remote + rm -rf qemu-xen-dir qemu-xen-dir-remote ifneq ($(XEN_COMPILE_ARCH),$(XEN_TARGET_ARCH)) IOEMU_CONFIGURE_CROSS ?= --cpu=$(XEN_TARGET_ARCH) \ @@ -81,6 +83,9 @@ endif qemu-xen-traditional-dir-find: $(XEN_ROOT)/scripts/git-checkout.sh $(CONFIG_QEMU) $(QEMU_TAG) qemu-xen-traditional-dir +qemu-xen-dir-find: + $(XEN_ROOT)/scripts/git-checkout.sh $(QEMU_UPSTREAM_URL) $(QEMU_UPSTREAM_TAG) qemu-xen-dir + .PHONY: qemu-xen-traditional-dir-force-update qemu-xen-traditional-dir-force-update: set -ex; \ @@ -98,6 +103,14 @@ subdir-clean-qemu-xen-traditional-dir: $(MAKE) -C qemu-xen-traditional-dir clean; \ fi +subdir-all-qemu-xen-dir subdir-install-qemu-xen-dir: qemu-xen-dir-find + +subdir-clean-qemu-xen-dir: + set -e; if test -d qemu-xen-dir/.; then \ + $(buildmakevars2shellvars); \ + $(MAKE) -C qemu-xen-dir clean; \ + fi + subdir-clean-debugger/gdbsx subdir-distclean-debugger/gdbsx: .phony $(MAKE) -C debugger/gdbsx clean _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel From xen-devel-bounces@lists.xensource.com Fri Sep 09 04:15:43 2011 Return-path: Envelope-to: www-data@lists.xensource.com Delivery-date: Fri, 09 Sep 2011 04:15:43 -0700 Received: from localhost ([127.0.0.1] helo=lists.colo.xensource.com) by lists.xensource.com with esmtp (Exim 4.43) id 1R1z3f-0007RY-0O; Fri, 09 Sep 2011 04:15:43 -0700 Received: from mail182.messagelabs.com ([85.158.139.83]) by lists.xensource.com with esmtp (Exim 4.43) id 1R1yxo-0005p7-0h for xen-devel@lists.xensource.com; Fri, 09 Sep 2011 04:11:25 -0700 X-Env-Sender: Stefano.Stabellini@eu.citrix.com X-Msg-Ref: server-8.tower-182.messagelabs.com!1315566575!17696127!1 X-Originating-IP: [66.165.176.63] X-StarScan-Version: 6.3.6; banners=-,-,- X-VirusChecked: Checked Received: (qmail 12531 invoked from network); 9 Sep 2011 11:09:36 -0000 Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63) by server-8.tower-182.messagelabs.com with RC4-SHA encrypted SMTP; 9 Sep 2011 11:09:36 -0000 X-IronPort-AV: E=Sophos;i="4.68,355,1312171200"; d="scan'208";a="162301743" Received: from ftlpmailmx02.citrite.net ([10.13.107.66]) by FTLPIPO02.CITRIX.COM with ESMTP/TLS/RC4-MD5; 09 Sep 2011 07:09:35 -0400 Received: from smtp01.ad.xensource.com (10.219.128.104) by smtprelay.citrix.com (10.13.107.66) with Microsoft SMTP Server id 8.3.137.0; Fri, 9 Sep 2011 07:09:35 -0400 Received: from localhost.localdomain (kaball.uk.xensource.com [10.80.2.59]) by smtp01.ad.xensource.com (8.13.1/8.13.1) with ESMTP id p89B9LGV031889; Fri, 9 Sep 2011 04:09:23 -0700 From: To: xen-devel@lists.xensource.com Date: Fri, 9 Sep 2011 12:17:47 +0100 Message-ID: <1315567069-28775-2-git-send-email-stefano.stabellini@eu.citrix.com> X-Mailer: git-send-email 1.7.0.4 In-Reply-To: References: MIME-Version: 1.0 Content-Type: text/plain Cc: Stefano Stabellini , keir@xen.org, Ian.Campbell@citrix.com, Stefano.Stabellini@eu.citrix.com Subject: [Xen-devel] [PATCH v3 2/4] Rename ioemu-dir as qemu-xen-traditional-dir X-BeenThere: xen-devel@lists.xensource.com X-Mailman-Version: 2.1.5 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xensource.com Errors-To: xen-devel-bounces@lists.xensource.com Signed-off-by: Stefano Stabellini diff -r f27aff6f2cfe .hgignore --- a/.hgignore Fri Sep 09 10:34:25 2011 +0000 +++ b/.hgignore Fri Sep 09 10:35:08 2011 +0000 @@ -291,8 +291,8 @@ ^tools/xm-test/lib/XmTestLib/config.py$ ^tools/xm-test/lib/XmTestReport/xmtest.py$ ^tools/xm-test/tests/.*\.test$ -^tools/ioemu-dir-remote -^tools/ioemu-dir$ +^tools/qemu-xen-traditional-dir-remote +^tools/qemu-xen-traditional-dir$ ^tools/ocaml/.*/.*\.annot$ ^tools/ocaml/.*/.*\.cmx?a$ ^tools/ocaml/.*/META$ diff -r f27aff6f2cfe Makefile --- a/Makefile Fri Sep 09 10:34:25 2011 +0000 +++ b/Makefile Fri Sep 09 10:35:08 2011 +0000 @@ -70,7 +70,7 @@ install-tools: $(MAKE) -C tools install ifeq ($(CONFIG_IOEMU),y) -install-tools: tools/ioemu-dir +install-tools: tools/qemu-xen-traditional-dir endif .PHONY: install-kernels @@ -78,18 +78,18 @@ install-kernels: for i in $(XKERNELS) ; do $(MAKE) $$i-install || exit 1; done .PHONY: install-stubdom -install-stubdom: tools/ioemu-dir install-tools +install-stubdom: tools/qemu-xen-traditional-dir install-tools $(MAKE) -C stubdom install ifeq (x86_64,$(XEN_TARGET_ARCH)) XEN_TARGET_ARCH=x86_32 $(MAKE) -C stubdom install-grub endif -tools/ioemu-dir: - $(MAKE) -C tools ioemu-dir-find +tools/qemu-xen-traditional-dir: + $(MAKE) -C tools qemu-xen-traditional-dir-find -.PHONY: tools/ioemu-dir-force-update -tools/ioemu-dir-force-update: - $(MAKE) -C tools ioemu-dir-force-update +.PHONY: tools/qemu-xen-traditional-dir-force-update +tools/qemu-xen-traditional-dir-force-update: + $(MAKE) -C tools qemu-xen-traditional-dir-force-update .PHONY: install-docs install-docs: diff -r f27aff6f2cfe tools/Makefile --- a/tools/Makefile Fri Sep 09 10:34:25 2011 +0000 +++ b/tools/Makefile Fri Sep 09 10:35:08 2011 +0000 @@ -30,7 +30,7 @@ SUBDIRS-$(LIBXENAPI_BINDINGS) += libxen # do not recurse in to a dir we are about to delete ifneq "$(MAKECMDGOALS)" "distclean" -SUBDIRS-$(CONFIG_IOEMU) += ioemu-dir +SUBDIRS-$(CONFIG_IOEMU) += qemu-xen-traditional-dir endif SUBDIRS-y += xenpmd @@ -70,7 +70,7 @@ clean: subdirs-clean .PHONY: distclean distclean: subdirs-distclean - rm -rf ioemu-dir ioemu-dir-remote + rm -rf qemu-xen-traditional-dir qemu-xen-traditional-dir-remote ifneq ($(XEN_COMPILE_ARCH),$(XEN_TARGET_ARCH)) IOEMU_CONFIGURE_CROSS ?= --cpu=$(XEN_TARGET_ARCH) \ @@ -78,24 +78,24 @@ IOEMU_CONFIGURE_CROSS ?= --cpu=$(XEN_TAR --interp-prefix=$(CROSS_SYS_ROOT) endif -ioemu-dir-find: - $(XEN_ROOT)/scripts/git-checkout.sh $(CONFIG_QEMU) $(QEMU_TAG) ioemu-dir +qemu-xen-traditional-dir-find: + $(XEN_ROOT)/scripts/git-checkout.sh $(CONFIG_QEMU) $(QEMU_TAG) qemu-xen-traditional-dir -.PHONY: ioemu-dir-force-update -ioemu-dir-force-update: +.PHONY: qemu-xen-traditional-dir-force-update +qemu-xen-traditional-dir-force-update: set -ex; \ if [ "$(QEMU_TAG)" ]; then \ - cd ioemu-dir-remote; \ + cd qemu-xen-traditional-dir-remote; \ $(GIT) fetch origin; \ $(GIT) reset --hard $(QEMU_TAG); \ fi -subdir-all-ioemu-dir subdir-install-ioemu-dir: ioemu-dir-find +subdir-all-qemu-xen-traditional-dir subdir-install-qemu-xen-traditional-dir: qemu-xen-traditional-dir-find -subdir-clean-ioemu-dir: - set -e; if test -d ioemu-dir/.; then \ +subdir-clean-qemu-xen-traditional-dir: + set -e; if test -d qemu-xen-traditional-dir/.; then \ $(buildmakevars2shellvars); \ - $(MAKE) -C ioemu-dir clean; \ + $(MAKE) -C qemu-xen-traditional-dir clean; \ fi subdir-clean-debugger/gdbsx subdir-distclean-debugger/gdbsx: .phony _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel From xen-devel-bounces@lists.xensource.com Fri Sep 09 04:19:50 2011 Return-path: Envelope-to: www-data@lists.xensource.com Delivery-date: Fri, 09 Sep 2011 04:19:50 -0700 Received: from localhost ([127.0.0.1] helo=lists.colo.xensource.com) by lists.xensource.com with esmtp (Exim 4.43) id 1R1z7d-0007wq-G9; Fri, 09 Sep 2011 04:19:49 -0700 Received: from mail27.messagelabs.com ([193.109.254.147]) by lists.xensource.com with smtp (Exim 4.43) id 1R1z6t-0007k4-Tl for xen-devel@lists.xensource.com; Fri, 09 Sep 2011 04:19:04 -0700 X-Env-Sender: Stefano.Stabellini@eu.citrix.com X-Msg-Ref: server-15.tower-27.messagelabs.com!1315567133!48073139!1 X-Originating-IP: [62.200.22.115] X-StarScan-Version: 6.3.6; banners=-,-,- X-VirusChecked: Checked Received: (qmail 2659 invoked from network); 9 Sep 2011 11:18:53 -0000 Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115) by server-15.tower-27.messagelabs.com with SMTP; 9 Sep 2011 11:18:53 -0000 X-IronPort-AV: E=Sophos;i="4.68,355,1312156800"; d="scan'208";a="7695234" Received: from lonpmailmx01.citrite.net ([10.30.203.162]) by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5; 09 Sep 2011 11:19:00 +0000 Received: from kaball.uk.xensource.com (10.80.2.59) by LONPMAILMX01.citrite.net (10.30.203.162) with Microsoft SMTP Server id 8.3.137.0; Fri, 9 Sep 2011 12:19:01 +0100 Date: Fri, 9 Sep 2011 12:27:14 +0100 From: Stefano Stabellini X-X-Sender: sstabellini@kaball-desktop To: =?UTF-8?Q?Sven_K=C3=B6hler?= Subject: Re: [Xen-devel] Re: xl vs. xm, possible bug in xl In-Reply-To: Message-ID: References: <20110908170755.GB16730@dumpdata.com> User-Agent: Alpine 2.00 (DEB 1167 2008-08-23) MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="8323329-1168301751-1315567623=:12963" Content-ID: Cc: "xen-devel@lists.xensource.com" X-BeenThere: xen-devel@lists.xensource.com X-Mailman-Version: 2.1.5 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xensource.com Errors-To: xen-devel-bounces@lists.xensource.com --8323329-1168301751-1315567623=:12963 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: 8BIT Content-ID: On Thu, 8 Sep 2011, Sven Köhler wrote: > Am 08.09.2011 19:07, schrieb Konrad Rzeszutek Wilk: > > On Thu, Sep 08, 2011 at 06:42:12PM +0200, Sven Köhler wrote: > >> Hi, > >> > >> xl is supposed to superseed xm, is this correct? How mature is xl, > >> actually? I'm asking, because the maintainers of the gentoo's xen > >> packages are migrating the init.d-scripts from xm to xl, but xl is > >> causing a lot of trouble. > >> > >> Well, xl basically fails to start domains on my system. > >>> # xl create /etc/xen/xen-sk1 > >>> Parsing config file /etc/xen/xen-sk1 > >>> libxl: error: libxl.c:2145:libxl_set_memory_target new target 0 for dom0 is below the minimum threshold > >>> libxl: error: libxl.c:2145:libxl_set_memory_target new target 0 for dom0 is below the minimum threshold > >>> libxl: error: libxl.c:2145:libxl_set_memory_target new target 0 for dom0 is below the minimum threshold > >>> failed to free memory for the domain > >> > >> Consider, that autobaloon=1 in xl.conf. > >> With the autobaloon=0 the errors change to > >> > >>> # xl create /etc/xen/xen-sk1 > >>> Parsing config file /etc/xen/xen-sk1 > >>> libxl: error: libxl_device.c:476:libxl__wait_for_device_model Device Model not ready > >>> xl: fatal error: libxl_create.c:535, rc=-1: libxl__confirm_device_model_startup > >> > >> > >> Note, that I use dom0_mem=512M in grub.conf. Also, xm top states, that > >> there are 2139432k free memory. Considering the first issue, it seems > >> like xl is trying to baloon memory away from dom0, which fails - which > >> seems obvious wrong considering that I use dom0_mem. CONFIG_XEN_BALLOON > >> is enabled for dom0 > > > > Yeah, there is a bug there (in Linux kernel) that just got integrated in 3.1-rc5. > > Will show up in 3.0.5. > > A bug will show up in 3.0.5/3.1-rc5 or the fix for it? > > Also, you seem to be replying to the first problem, the on about memory. > > Any clue, that the second problem is about? > > # xl create /etc/xen/xen-sk1 > > Parsing config file /etc/xen/xen-sk1 > > libxl: error: libxl_device.c:476:libxl__wait_for_device_model Device Model not ready > > xl: fatal error: libxl_create.c:535, rc=-1: libxl__confirm_device_model_startup That means that qemu failed to start. Could you please cat /var/log/xen/qemu-dm-domainname.log? --8323329-1168301751-1315567623=:12963 Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel --8323329-1168301751-1315567623=:12963-- From xen-devel-bounces@lists.xensource.com Fri Sep 09 04:25:22 2011 Return-path: Envelope-to: www-data@lists.xensource.com Delivery-date: Fri, 09 Sep 2011 04:25:22 -0700 Received: from localhost ([127.0.0.1] helo=lists.colo.xensource.com) by lists.xensource.com with esmtp (Exim 4.43) id 1R1zD0-0008Oo-8E; Fri, 09 Sep 2011 04:25:22 -0700 Received: from mail21.messagelabs.com ([85.158.143.35]) by lists.xensource.com with esmtp (Exim 4.43) id 1R1zBt-0008Bh-HT for xen-devel@lists.xensource.com; Fri, 09 Sep 2011 04:24:13 -0700 X-Env-Sender: keir.xen@gmail.com X-Msg-Ref: server-11.tower-21.messagelabs.com!1315567434!41956783!1 X-Originating-IP: [74.125.82.43] X-StarScan-Version: 6.3.6; banners=-,-,- X-VirusChecked: Checked Received: (qmail 1636 invoked from network); 9 Sep 2011 11:23:54 -0000 Received: from mail-ww0-f43.google.com (HELO mail-ww0-f43.google.com) (74.125.82.43) by server-11.tower-21.messagelabs.com with RC4-SHA encrypted SMTP; 9 Sep 2011 11:23:54 -0000 Received: by wwe32 with SMTP id 32so776086wwe.24 for ; Fri, 09 Sep 2011 04:24:10 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=user-agent:date:subject:from:to:cc:message-id:thread-topic :thread-index:in-reply-to:mime-version:content-type :content-transfer-encoding; bh=jNRvWVXYZdJDDs4OVATp8VkWfsghSmcD2o1cWJ2Rxo0=; b=ov3uC6DfuH5kQT15YNVXBaWK1lfF+AU+MpGltJbIw6ajIDWCUGD8e/6MaRehWSd8an vW7L1VgXhS2geZjsZhXsTA+IEOY1JHUOUtmBUSiKVjP66QLPgwH8qqvfaLUDdHIZJgQE zlwdKBOBkdCpSIoPKVW+rQdJWymNfNP/AhupA= Received: by 10.227.154.66 with SMTP id n2mr1936275wbw.3.1315567450209; Fri, 09 Sep 2011 04:24:10 -0700 (PDT) Received: from [192.168.1.78] (host86-137-116-193.range86-137.btcentralplus.com [86.137.116.193]) by mx.google.com with ESMTPS id fq9sm7166939wbb.15.2011.09.09.04.24.02 (version=SSLv3 cipher=OTHER); Fri, 09 Sep 2011 04:24:06 -0700 (PDT) User-Agent: Microsoft-Entourage/12.30.0.110427 Date: Fri, 09 Sep 2011 12:23:59 +0100 Subject: Re: [Xen-devel] [PATCH v2 4/4] Clone and build Seabios by default From: Keir Fraser To: Stefano Stabellini , George Dunlap Message-ID: Thread-Topic: [Xen-devel] [PATCH v2 4/4] Clone and build Seabios by default Thread-Index: Acxu4vgKvzK4azcO7keOUu/6ruJGEw== In-Reply-To: Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit Cc: Ian Campbell , "xen-devel@lists.xensource.com" , "keir@xen.org" X-BeenThere: xen-devel@lists.xensource.com X-Mailman-Version: 2.1.5 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xensource.com Errors-To: xen-devel-bounces@lists.xensource.com On 09/09/2011 11:46, "Stefano Stabellini" wrote: >> But that means that if the sites hosting ipxe or qemu go down, people >> can't build Xen. Keeping a copy on xen.org removes external >> dependencies we don't have any control over. > > AKA single point of failure? Better than multiple independent points of failure. However, we already depend on the upstream ipxe site. Changing over to all downloads from a single site under our control would be a separate issue and patch, imo. -- Keir _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel From xen-devel-bounces@lists.xensource.com Fri Sep 09 04:27:50 2011 Return-path: Envelope-to: www-data@lists.xensource.com Delivery-date: Fri, 09 Sep 2011 04:27:50 -0700 Received: from localhost ([127.0.0.1] helo=lists.colo.xensource.com) by lists.xensource.com with esmtp (Exim 4.43) id 1R1zFO-0000Lj-Bi; Fri, 09 Sep 2011 04:27:50 -0700 Received: from mail174.messagelabs.com ([85.158.138.51]) by lists.xensource.com with esmtp (Exim 4.43) id 1R1zEr-00009K-Eu for xen-devel@lists.xensource.com; Fri, 09 Sep 2011 04:27:17 -0700 X-Env-Sender: sven.koehler@gmail.com X-Msg-Ref: server-3.tower-174.messagelabs.com!1315567630!24767127!1 X-Originating-IP: [209.85.214.43] X-StarScan-Version: 6.3.6; banners=-,-,- X-VirusChecked: Checked Received: (qmail 20262 invoked from network); 9 Sep 2011 11:27:14 -0000 Received: from mail-bw0-f43.google.com (HELO mail-bw0-f43.google.com) (209.85.214.43) by server-3.tower-174.messagelabs.com with RC4-SHA encrypted SMTP; 9 Sep 2011 11:27:14 -0000 Received: by bkas6 with SMTP id s6so1305829bka.30 for ; Fri, 09 Sep 2011 04:27:10 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:x-enigmail-version:content-type; bh=Txo3cEXuQkAptdzO4ytts+9P2EbdvbvriwN+jR7Ol58=; b=e+8cFVTXZClToDsR+F0X0+W3Pm1BJugmijuD0PGpTcb79jhynSq5p5JfwhJoVkXIRZ DYIVF7U0lCtWy7AeVlEdsy7qBl5QaVNygldRQ4dTbv7sK6+TcgEePAarSkcsFYjxu7p3 lRc94nHtWEtjMWWo84mlM1o9mQeWE7ZscC4O4= Received: by 10.204.0.79 with SMTP id 15mr1300693bka.26.1315567630289; Fri, 09 Sep 2011 04:27:10 -0700 (PDT) Received: from [192.168.77.158] (horkheimer.ti5.tu-harburg.de [134.28.77.9]) by mx.google.com with ESMTPS id o13sm979998bkc.0.2011.09.09.04.27.08 (version=SSLv3 cipher=OTHER); Fri, 09 Sep 2011 04:27:09 -0700 (PDT) Message-ID: <4E69F80A.5060905@gmail.com> Date: Fri, 09 Sep 2011 13:27:06 +0200 From: =?UTF-8?B?U3ZlbiBLw7ZobGVy?= User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:6.0) Gecko/20110829 Thunderbird/6.0 MIME-Version: 1.0 To: Stefano Stabellini Subject: Re: [Xen-devel] Re: xl vs. xm, possible bug in xl References: <20110908170755.GB16730@dumpdata.com> In-Reply-To: X-Enigmail-Version: 1.3 Cc: "xen-devel@lists.xensource.com" X-BeenThere: xen-devel@lists.xensource.com X-Mailman-Version: 2.1.5 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0454413187==" Sender: xen-devel-bounces@lists.xensource.com Errors-To: xen-devel-bounces@lists.xensource.com This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --===============0454413187== Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="------------enig451C3E9953E132B9DFDF3A38" This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enig451C3E9953E132B9DFDF3A38 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Am 09.09.2011 13:27, schrieb Stefano Stabellini: >> Any clue, that the second problem is about? >>> # xl create /etc/xen/xen-sk1 >>> Parsing config file /etc/xen/xen-sk1 >>> libxl: error: libxl_device.c:476:libxl__wait_for_device_model Device = Model not ready >>> xl: fatal error: libxl_create.c:535, rc=3D-1: libxl__confirm_device_m= odel_startup >=20 > That means that qemu failed to start. Could you please cat > /var/log/xen/qemu-dm-domainname.log? There is no such file (my domain config lacks a name=3D"something" line).= However qemu-dm-test.log does exist and is of recent date, and it says that qemu cannot be started. This is very plausible, since qemu is not even installed. This machine is supposed to start paravirt guests only. And xen has been compiled without support for hvm guests. (Not sure right now, what the gentoo people do to disable support support for hvm guests). Does my config file for the domain (see one of my previous emails in this thread) indicate, that the machine is a hvm domain? How can I tell xl that this a paravirt domain, and qemu is not needed and should not be used? (As previously mentioned, xm works just fine with the very same domain config file) Regards, Sven --------------enig451C3E9953E132B9DFDF3A38 Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.17 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAk5p+AsACgkQ7Ww7FjRBE4DHrACfbi3uCGLevRkHesTx9yNF0kQI y+8AoJefNZLw+u2ea9vnoKDvHzHUMVRz =8URh -----END PGP SIGNATURE----- --------------enig451C3E9953E132B9DFDF3A38-- --===============0454413187== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel --===============0454413187==-- From xen-devel-bounces@lists.xensource.com Fri Sep 09 04:32:25 2011 Return-path: Envelope-to: www-data@lists.xensource.com Delivery-date: Fri, 09 Sep 2011 04:32:25 -0700 Received: from localhost ([127.0.0.1] helo=lists.colo.xensource.com) by lists.xensource.com with esmtp (Exim 4.43) id 1R1zJo-0000su-Tl; Fri, 09 Sep 2011 04:32:24 -0700 Received: from mail216.messagelabs.com ([85.158.143.99]) by lists.xensource.com with esmtp (Exim 4.43) id 1R1zJ9-0000ch-IK for xen-devel@lists.xensource.com; Fri, 09 Sep 2011 04:31:43 -0700 X-Env-Sender: xieliwei@gmail.com X-Msg-Ref: server-3.tower-216.messagelabs.com!1315567899!16629890!1 X-Originating-IP: [209.85.160.171] X-StarScan-Version: 6.3.6; banners=-,-,- X-VirusChecked: Checked Received: (qmail 31884 invoked from network); 9 Sep 2011 11:31:40 -0000 Received: from mail-gy0-f171.google.com (HELO mail-gy0-f171.google.com) (209.85.160.171) by server-3.tower-216.messagelabs.com with RC4-SHA encrypted SMTP; 9 Sep 2011 11:31:40 -0000 Received: by gyh3 with SMTP id 3so185502gyh.30 for ; Fri, 09 Sep 2011 04:31:39 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:from:date:message-id:subject:to:cc:content-type; bh=8/Znc5GDpG4IqkUpjAVeFZvG5G6fJyrlzyL8K65Mo9Q=; b=l4bu9A8eI4Kpfs4fdUHI5DRLjWklDO1OU0z7S64EXCO+nXTwAoCTmVuHZ48DdwQ5ft BHo1eDuo/yAfKLNuTgZ5Tv0QcOY1mhlc82gFjtyuskF4dsDgX4mwxdHAzzpYyVnl6h+H 4kkaQ2mtBsrrfxsgt1cbL0p8X7/PtHPaKpeXE= Received: by 10.101.181.23 with SMTP id i23mr1652688anp.69.1315567899074; Fri, 09 Sep 2011 04:31:39 -0700 (PDT) MIME-Version: 1.0 Received: by 10.100.191.1 with HTTP; Fri, 9 Sep 2011 04:31:19 -0700 (PDT) From: Liwei Date: Fri, 9 Sep 2011 19:31:19 +0800 Message-ID: To: komkon555 Content-Type: text/plain; charset=ISO-8859-1 Cc: xen-devel Subject: [Xen-devel] Re: Patches for VGA-Passthrough XEN 4.2 unstable X-BeenThere: xen-devel@lists.xensource.com X-Mailman-Version: 2.1.5 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xensource.com Errors-To: xen-devel-bounces@lists.xensource.com > Date: Fri, 9 Sep 2011 01:07:50 -0700 (PDT) > From: komkon555 > Subject: Re: Re : Re : Re : [Xen-devel] Re: Patches for > VGA-Passthrough XEN 4.2 unstable > To: xen-devel@lists.xensource.com > Message-ID: <1315555670684-4785425.post@n5.nabble.com> > Content-Type: text/plain; charset=us-ascii > > > Weidong Han wrote: > > > > Guest needs VGA BIOS to initialize assigned graphics card in guest. > > qemu-dm only know how to copy video BIOS of primary graphics card which > > locates at 0xC0000, but don't know where are video BIOS of other > > graphics cards. if want to pass-through more than one graphics cards, > > must know how to get and load VGA BIOS to guest for other graphics > > cards. One method is to use tools such as NiBiTor to extract VGA BIOS > > from graphics card to a file, then load it to guest. > > > > Weidong > > > > Hallo. What about ATI/AMD cards: are they in the same situation? Is it > possible for today to pass through multiple ATI/AMD devices? > Thank you. > Personally I'm having positive experiences with AMD cards. Currently running two ATI 6870s in a 64-bit Windows 7 DomU. Best thing is, they're working alright without any patches on xen-unstable. However, similar to what you have experienced, DomU cannot be restarted in this configuration. It can be fixed, but I haven't got the time to get down to it. Regarding your problem with passing through the USB controller, have you tried it without the VGA passthrough patches? IMO it may not be related to the passthrough patches. > Best regards > Kom. > _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel From xen-devel-bounces@lists.xensource.com Fri Sep 09 05:00:10 2011 Return-path: Envelope-to: www-data@lists.xensource.com Delivery-date: Fri, 09 Sep 2011 05:00:10 -0700 Received: from localhost ([127.0.0.1] helo=lists.colo.xensource.com) by lists.xensource.com with esmtp (Exim 4.43) id 1R1zkf-0001qD-4B; Fri, 09 Sep 2011 05:00:09 -0700 Received: from mail182.messagelabs.com ([85.158.139.83]) by lists.xensource.com with smtp (Exim 4.43) id 1R1zi3-0001bN-16 for xen-devel@lists.xensource.com; Fri, 09 Sep 2011 04:57:28 -0700 X-Env-Sender: Stefano.Stabellini@eu.citrix.com X-Msg-Ref: server-11.tower-182.messagelabs.com!1315569443!17697932!1 X-Originating-IP: [62.200.22.115] X-StarScan-Version: 6.3.6; banners=-,-,- X-VirusChecked: Checked Received: (qmail 17044 invoked from network); 9 Sep 2011 11:57:23 -0000 Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115) by server-11.tower-182.messagelabs.com with SMTP; 9 Sep 2011 11:57:23 -0000 X-IronPort-AV: E=Sophos;i="4.68,355,1312156800"; d="scan'208";a="7696100" Received: from lonpmailmx01.citrite.net ([10.30.203.162]) by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5; 09 Sep 2011 11:57:23 +0000 Received: from kaball.uk.xensource.com (10.80.2.59) by LONPMAILMX01.citrite.net (10.30.203.162) with Microsoft SMTP Server id 8.3.137.0; Fri, 9 Sep 2011 12:57:23 +0100 Date: Fri, 9 Sep 2011 13:05:36 +0100 From: Stefano Stabellini X-X-Sender: sstabellini@kaball-desktop To: =?UTF-8?Q?Sven_K=C3=B6hler?= Subject: Re: [Xen-devel] Re: xl vs. xm, possible bug in xl In-Reply-To: <4E69F80A.5060905@gmail.com> Message-ID: References: <20110908170755.GB16730@dumpdata.com> <4E69F80A.5060905@gmail.com> User-Agent: Alpine 2.00 (DEB 1167 2008-08-23) MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="8323329-1055616589-1315569952=:12963" Cc: "xen-devel@lists.xensource.com" , Stefano Stabellini X-BeenThere: xen-devel@lists.xensource.com X-Mailman-Version: 2.1.5 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xensource.com Errors-To: xen-devel-bounces@lists.xensource.com --8323329-1055616589-1315569952=:12963 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: 8BIT On Fri, 9 Sep 2011, Sven Köhler wrote: > Am 09.09.2011 13:27, schrieb Stefano Stabellini: > >> Any clue, that the second problem is about? > >>> # xl create /etc/xen/xen-sk1 > >>> Parsing config file /etc/xen/xen-sk1 > >>> libxl: error: libxl_device.c:476:libxl__wait_for_device_model Device Model not ready > >>> xl: fatal error: libxl_create.c:535, rc=-1: libxl__confirm_device_model_startup > > > > That means that qemu failed to start. Could you please cat > > /var/log/xen/qemu-dm-domainname.log? > > There is no such file (my domain config lacks a name="something" line). > However qemu-dm-test.log does exist and is of recent date, and it says > that qemu cannot be started. This is very plausible, since qemu is not > even installed. This machine is supposed to start paravirt guests only. > And xen has been compiled without support for hvm guests. (Not sure > right now, what the gentoo people do to disable support support for hvm > guests). > > Does my config file for the domain (see one of my previous emails in > this thread) indicate, that the machine is a hvm domain? How can I tell > xl that this a paravirt domain, and qemu is not needed and should not be > used? I think I have found the issue: if blktap2 is not enabled xl is going to start qemu (to provide a disk backend) even if it is not actually needed because the user wants to use blkback. We have a patch upstream to fix this issue but it hasn't been backported to 4.1: # HG changeset patch # User Ian Campbell # Date 1300213187 0 # Node ID d4ca456c0c25c3c3daedc216c657296f2895482a # Parent 3caed2112c65791855e8bf0fd34c15e3160bbc78 libxl: do not start a xenpv qemu solely for tap devices if blktap is available qemu is used as a fallback for DISK_BACKEND_TAP if no blktap is available but if blktap is available, or for DISK_BACKEND_PHY, we don't need a qemu process. Signed-off-by: Ian Campbell Acked-by: Ian Jackson Committed-by: Ian Jackson diff -r 3caed2112c65 -r d4ca456c0c25 tools/libxl/libxl_dm.c --- a/tools/libxl/libxl_dm.c Tue Mar 15 10:14:27 2011 +0000 +++ b/tools/libxl/libxl_dm.c Tue Mar 15 18:19:47 2011 +0000 @@ -828,8 +828,29 @@ int libxl__need_xenpv_qemu(libxl_ctx *ct goto out; } - if (nr_disks > 0 && !libxl__blktap_enabled(&gc)) - ret = 1; + if (nr_disks > 0) { + int blktap_enabled = -1; + for (i = 0; i < nr_disks; i++) { + switch (disks[i].backend) { + case DISK_BACKEND_TAP: + if (blktap_enabled == -1) + blktap_enabled = libxl__blktap_enabled(&gc); + if (!blktap_enabled) { + ret = 1; + goto out; + } + break; + + case DISK_BACKEND_QDISK: + ret = 1; + goto out; + + case DISK_BACKEND_PHY: + case DISK_BACKEND_UNKNOWN: + break; + } + } + } out: LIbxl__free_all(&gc); --8323329-1055616589-1315569952=:12963 Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel --8323329-1055616589-1315569952=:12963-- From xen-devel-bounces@lists.xensource.com Fri Sep 09 05:02:35 2011 Return-path: Envelope-to: www-data@lists.xensource.com Delivery-date: Fri, 09 Sep 2011 05:02:35 -0700 Received: from localhost ([127.0.0.1] helo=lists.colo.xensource.com) by lists.xensource.com with esmtp (Exim 4.43) id 1R1zmz-0002EF-9I; Fri, 09 Sep 2011 05:02:33 -0700 Received: from mail21.messagelabs.com ([85.158.143.35]) by lists.xensource.com with smtp (Exim 4.43) id 1R1zje-0001jN-Mg for xen-devel@lists.xensource.com; Fri, 09 Sep 2011 04:59:15 -0700 X-Env-Sender: Stefano.Stabellini@eu.citrix.com X-Msg-Ref: server-4.tower-21.messagelabs.com!1315569505!59590641!1 X-Originating-IP: [62.200.22.115] X-StarScan-Version: 6.3.6; banners=-,-,- X-VirusChecked: Checked Received: (qmail 18057 invoked from network); 9 Sep 2011 11:58:25 -0000 Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115) by server-4.tower-21.messagelabs.com with SMTP; 9 Sep 2011 11:58:25 -0000 X-IronPort-AV: E=Sophos;i="4.68,355,1312156800"; d="scan'208";a="7696130" Received: from lonpmailmx01.citrite.net ([10.30.203.162]) by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5; 09 Sep 2011 11:58:28 +0000 Received: from kaball.uk.xensource.com (10.80.2.59) by LONPMAILMX01.citrite.net (10.30.203.162) with Microsoft SMTP Server id 8.3.137.0; Fri, 9 Sep 2011 12:58:28 +0100 Date: Fri, 9 Sep 2011 13:06:42 +0100 From: Stefano Stabellini X-X-Sender: sstabellini@kaball-desktop To: Stefano Stabellini Subject: Re: [Xen-devel] Re: xl vs. xm, possible bug in xl In-Reply-To: Message-ID: References: <20110908170755.GB16730@dumpdata.com> <4E69F80A.5060905@gmail.com> User-Agent: Alpine 2.00 (DEB 1167 2008-08-23) MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="8323329-1975714483-1315570017=:12963" Cc: "xen-devel@lists.xensource.com" , =?UTF-8?Q?Sven_K=C3=B6hler?= X-BeenThere: xen-devel@lists.xensource.com X-Mailman-Version: 2.1.5 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xensource.com Errors-To: xen-devel-bounces@lists.xensource.com --8323329-1975714483-1315570017=:12963 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: 8BIT CC'ing IanJ to make sure he is going to read this On Fri, 9 Sep 2011, Stefano Stabellini wrote: > On Fri, 9 Sep 2011, Sven Köhler wrote: > > Am 09.09.2011 13:27, schrieb Stefano Stabellini: > > >> Any clue, that the second problem is about? > > >>> # xl create /etc/xen/xen-sk1 > > >>> Parsing config file /etc/xen/xen-sk1 > > >>> libxl: error: libxl_device.c:476:libxl__wait_for_device_model Device Model not ready > > >>> xl: fatal error: libxl_create.c:535, rc=-1: libxl__confirm_device_model_startup > > > > > > That means that qemu failed to start. Could you please cat > > > /var/log/xen/qemu-dm-domainname.log? > > > > There is no such file (my domain config lacks a name="something" line). > > However qemu-dm-test.log does exist and is of recent date, and it says > > that qemu cannot be started. This is very plausible, since qemu is not > > even installed. This machine is supposed to start paravirt guests only. > > And xen has been compiled without support for hvm guests. (Not sure > > right now, what the gentoo people do to disable support support for hvm > > guests). > > > > Does my config file for the domain (see one of my previous emails in > > this thread) indicate, that the machine is a hvm domain? How can I tell > > xl that this a paravirt domain, and qemu is not needed and should not be > > used? > > I think I have found the issue: if blktap2 is not enabled xl is going to > start qemu (to provide a disk backend) even if it is not actually needed > because the user wants to use blkback. > > We have a patch upstream to fix this issue but it hasn't been backported > to 4.1: > > > > # HG changeset patch > # User Ian Campbell > # Date 1300213187 0 > # Node ID d4ca456c0c25c3c3daedc216c657296f2895482a > # Parent 3caed2112c65791855e8bf0fd34c15e3160bbc78 > libxl: do not start a xenpv qemu solely for tap devices if blktap is available > > qemu is used as a fallback for DISK_BACKEND_TAP if no blktap is > available but if blktap is available, or for DISK_BACKEND_PHY, we > don't need a qemu process. > > Signed-off-by: Ian Campbell > Acked-by: Ian Jackson > Committed-by: Ian Jackson > > diff -r 3caed2112c65 -r d4ca456c0c25 tools/libxl/libxl_dm.c > --- a/tools/libxl/libxl_dm.c Tue Mar 15 10:14:27 2011 +0000 > +++ b/tools/libxl/libxl_dm.c Tue Mar 15 18:19:47 2011 +0000 > @@ -828,8 +828,29 @@ int libxl__need_xenpv_qemu(libxl_ctx *ct > goto out; > } > > - if (nr_disks > 0 && !libxl__blktap_enabled(&gc)) > - ret = 1; > + if (nr_disks > 0) { > + int blktap_enabled = -1; > + for (i = 0; i < nr_disks; i++) { > + switch (disks[i].backend) { > + case DISK_BACKEND_TAP: > + if (blktap_enabled == -1) > + blktap_enabled = libxl__blktap_enabled(&gc); > + if (!blktap_enabled) { > + ret = 1; > + goto out; > + } > + break; > + > + case DISK_BACKEND_QDISK: > + ret = 1; > + goto out; > + > + case DISK_BACKEND_PHY: > + case DISK_BACKEND_UNKNOWN: > + break; > + } > + } > + } > > out: > LIbxl__free_all(&gc); --8323329-1975714483-1315570017=:12963 Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel --8323329-1975714483-1315570017=:12963-- From xen-devel-bounces@lists.xensource.com Fri Sep 09 05:06:18 2011 Return-path: Envelope-to: www-data@lists.xensource.com Delivery-date: Fri, 09 Sep 2011 05:06:18 -0700 Received: from localhost ([127.0.0.1] helo=lists.colo.xensource.com) by lists.xensource.com with esmtp (Exim 4.43) id 1R1zqb-0002iy-CC; Fri, 09 Sep 2011 05:06:17 -0700 Received: from mail174.messagelabs.com ([85.158.138.51]) by lists.xensource.com with esmtp (Exim 4.43) id 1R1zmV-00027d-MD for xen-devel@lists.xensource.com; Fri, 09 Sep 2011 05:02:10 -0700 X-Env-Sender: Andrew.Cooper3@citrix.com X-Msg-Ref: server-8.tower-174.messagelabs.com!1315569718!17157762!1 X-Originating-IP: [66.165.176.63] X-StarScan-Version: 6.3.6; banners=-,-,- X-VirusChecked: Checked Received: (qmail 2096 invoked from network); 9 Sep 2011 12:02:00 -0000 Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63) by server-8.tower-174.messagelabs.com with RC4-SHA encrypted SMTP; 9 Sep 2011 12:02:00 -0000 X-IronPort-AV: E=Sophos;i="4.68,355,1312171200"; d="scan'208";a="162307294" Received: from ftlpmailmx01.citrite.net ([10.13.107.65]) by FTLPIPO02.CITRIX.COM with ESMTP/TLS/RC4-MD5; 09 Sep 2011 08:01:57 -0400 Received: from [10.80.2.18] (10.80.2.18) by FTLPMAILMX01.citrite.net (10.13.107.65) with Microsoft SMTP Server id 8.3.137.0; Fri, 9 Sep 2011 08:01:57 -0400 Message-ID: <4E6A0034.10706@citrix.com> Date: Fri, 9 Sep 2011 13:01:56 +0100 From: Andrew Cooper User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.2.21) Gecko/20110831 Lightning/1.0b2 Thunderbird/3.1.13 MIME-Version: 1.0 To: Subject: Re: [Xen-devel] Re: computer stalls instead of reboot References: <4E694CFB.1060203@citrix.com> In-Reply-To: Content-Type: text/plain; charset="ISO-8859-15" Content-Transfer-Encoding: 8bit X-BeenThere: xen-devel@lists.xensource.com X-Mailman-Version: 2.1.5 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xensource.com Errors-To: xen-devel-bounces@lists.xensource.com On 09/09/11 00:40, Sven Köhler wrote: > Am 09.09.2011 01:17, schrieb Andrew Cooper: >> Does your "remote" method involve actually pushing the reset button, and >> does this method actually work under normal circumstances? > I think, there is a device connected to the connector on the > motherboard, to which the reset button would normally be attached. Ok, in which case the state your computer is getting into is a very broken state, if the reset button is not working >> As for the problem itself, do you have C states enabled in the BIOS? >> This sounds similar to several errata published for the i7 series. > I'm not sure how to tell whether C states are disabled/enabled. > What would those BIOS options typically be called? That is too bios dependent to say for sure, but typically "C states" or "deep sleep", with some intel ones going for "C1e" > Also, should I enable or disable them, in order to workaround those > errata that you mention? They should be disabled. The errata state that there are several situations when moving in and our of deep c states which cause processors to lock up irreparably. > Should those errors have occurred with xen 3.x as well, if those were a > result of the errata you mention? The power management code has changed quite a lot between 3.x and 4.x, so it is quite possible that xen 3.x just managed to miss these errata. > > Regards, > Sven > > > _______________________________________________ > Xen-devel mailing list > Xen-devel@lists.xensource.com > http://lists.xensource.com/xen-devel -- Andrew Cooper - Dom0 Kernel Engineer, Citrix XenServer T: +44 (0)1223 225 900, http://www.citrix.com _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel From xen-devel-bounces@lists.xensource.com Fri Sep 09 05:18:43 2011 Return-path: Envelope-to: www-data@lists.xensource.com Delivery-date: Fri, 09 Sep 2011 05:18:43 -0700 Received: from localhost ([127.0.0.1] helo=lists.colo.xensource.com) by lists.xensource.com with esmtp (Exim 4.43) id 1R202d-0003vh-8U; Fri, 09 Sep 2011 05:18:43 -0700 Received: from mail21.messagelabs.com ([85.158.143.35]) by lists.xensource.com with esmtp (Exim 4.43) id 1R2028-0003ju-3e for xen-devel@lists.xensource.com; Fri, 09 Sep 2011 05:18:13 -0700 X-Env-Sender: Andrew.Cooper3@citrix.com X-Msg-Ref: server-11.tower-21.messagelabs.com!1315570671!41965812!1 X-Originating-IP: [66.165.176.89] X-StarScan-Version: 6.3.6; banners=-,-,- X-VirusChecked: Checked Received: (qmail 30634 invoked from network); 9 Sep 2011 12:17:53 -0000 Received: from smtp.citrix.com (HELO SMTP.CITRIX.COM) (66.165.176.89) by server-11.tower-21.messagelabs.com with RC4-SHA encrypted SMTP; 9 Sep 2011 12:17:53 -0000 X-IronPort-AV: E=Sophos;i="4.68,356,1312171200"; d="scan'208";a="16822299" Received: from ftlpmailmx02.citrite.net ([10.13.107.66]) by FTLPIPO01.CITRIX.COM with ESMTP/TLS/RC4-MD5; 09 Sep 2011 08:18:07 -0400 Received: from [10.80.2.18] (10.80.2.18) by FTLPMAILMX02.citrite.net (10.13.107.66) with Microsoft SMTP Server id 8.3.137.0; Fri, 9 Sep 2011 08:18:07 -0400 Message-ID: <4E6A03FE.8090202@citrix.com> Date: Fri, 9 Sep 2011 13:18:06 +0100 From: Andrew Cooper User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.2.21) Gecko/20110831 Lightning/1.0b2 Thunderbird/3.1.13 MIME-Version: 1.0 To: Content-Type: text/plain; charset="ISO-8859-1" Content-Transfer-Encoding: 7bit Cc: "xen-devel@lists.xensource.com" Subject: [Xen-devel] Query about cpuidle X-BeenThere: xen-devel@lists.xensource.com X-Mailman-Version: 2.1.5 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xensource.com Errors-To: xen-devel-bounces@lists.xensource.com Hello, We have recently had a support escalation about Xen-4.1.1 being unable to boot on HP BL460c G7 blades. The problem turned out to be a null function pointer deference (ns_to_tick in cpu_idle.c) during early boot of dom0, in the set_cx_pminfo function. I applied your patch, changeset 23662:2faba14bac13, about initializing default C state information, and this appears to have fixed the problem. However, I see in the patch that setting up the function pointers (ns_to_tick, tick_to_ns etc) is predicated on the hypercall coming in on CPU0. What guarantees are in place to ensure that these function pointers get set up? I cant see anything obvious from the code, but have to admit that the null pointer deference appears to have gone away. Thanks in advance, -- Andrew Cooper - Dom0 Kernel Engineer, Citrix XenServer T: +44 (0)1223 225 900, http://www.citrix.com _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel From xen-devel-bounces@lists.xensource.com Fri Sep 09 05:30:07 2011 Return-path: Envelope-to: www-data@lists.xensource.com Delivery-date: Fri, 09 Sep 2011 05:30:07 -0700 Received: from localhost ([127.0.0.1] helo=lists.colo.xensource.com) by lists.xensource.com with esmtp (Exim 4.43) id 1R20De-0004UN-0h; Fri, 09 Sep 2011 05:30:06 -0700 Received: from mail182.messagelabs.com ([85.158.139.83]) by lists.xensource.com with esmtp (Exim 4.43) id 1R20Cf-0004HO-2w for xen-devel@lists.xensource.com; Fri, 09 Sep 2011 05:29:05 -0700 X-Env-Sender: javier.manzano@edu.uah.es X-Msg-Ref: server-7.tower-182.messagelabs.com!1315571340!12693216!1 X-Originating-IP: [216.139.236.26] X-StarScan-Version: 6.3.6; banners=-,-,- X-VirusChecked: Checked Received: (qmail 24645 invoked from network); 9 Sep 2011 12:29:02 -0000 Received: from sam.nabble.com (HELO sam.nabble.com) (216.139.236.26) by server-7.tower-182.messagelabs.com with AES256-SHA encrypted SMTP; 9 Sep 2011 12:29:02 -0000 Received: from [192.168.236.26] (helo=sam.nabble.com) by sam.nabble.com with esmtp (Exim 4.72) (envelope-from ) id 1R20Ca-0008PT-7H for xen-devel@lists.xensource.com; Fri, 09 Sep 2011 05:29:00 -0700 Date: Fri, 9 Sep 2011 05:29:00 -0700 (PDT) From: JavMV To: xen-devel@lists.xensource.com Message-ID: <1315571340218-4786166.post@n5.nabble.com> In-Reply-To: <1315554847212-4785386.post@n5.nabble.com> References: <1315343879.61837.YahooMailNeo@web29818.mail.ird.yahoo.com> <1315382742268-4777689.post@n5.nabble.com> <1315389138.56652.YahooMailNeo@web29801.mail.ird.yahoo.com> <1315398360680-4778339.post@n5.nabble.com> <1315401901083-4778494.post@n5.nabble.com> <1315403644525-4778586.post@n5.nabble.com> <1315405372.87224.YahooMailNeo@web29801.mail.ird.yahoo.com> <1315405921936-4778727.post@n5.nabble.com> <1315408931610-4778925.post@n5.nabble.com> <1315554847212-4785386.post@n5.nabble.com> Subject: Re: Re : Re : Re : [Xen-devel] Re: Patches for VGA-Passthrough XEN 4.2 unstable MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-BeenThere: xen-devel@lists.xensource.com X-Mailman-Version: 2.1.5 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xensource.com Errors-To: xen-devel-bounces@lists.xensource.com Thank you very much Kom It seems that AMD cards works better with passthru, I should try it ----- JavMV -- View this message in context: http://xen.1045712.n5.nabble.com/Patches-for-VGA-Passthrough-XEN-4-2-unstable-tp4406265p4786166.html Sent from the Xen - Dev mailing list archive at Nabble.com. _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel From xen-devel-bounces@lists.xensource.com Fri Sep 09 05:44:31 2011 Return-path: Envelope-to: www-data@lists.xensource.com Delivery-date: Fri, 09 Sep 2011 05:44:31 -0700 Received: from localhost ([127.0.0.1] helo=lists.colo.xensource.com) by lists.xensource.com with esmtp (Exim 4.43) id 1R20Rb-00053D-LA; Fri, 09 Sep 2011 05:44:31 -0700 Received: from mail27.messagelabs.com ([193.109.254.147]) by lists.xensource.com with esmtp (Exim 4.43) id 1R20Qj-0004qU-5F for xen-devel@lists.xensource.com; Fri, 09 Sep 2011 05:43:37 -0700 X-Env-Sender: sven.koehler@gmail.com X-Msg-Ref: server-3.tower-27.messagelabs.com!1315572192!38982547!1 X-Originating-IP: [209.85.214.43] X-StarScan-Version: 6.3.6; banners=-,-,- X-VirusChecked: Checked Received: (qmail 10058 invoked from network); 9 Sep 2011 12:43:12 -0000 Received: from mail-bw0-f43.google.com (HELO mail-bw0-f43.google.com) (209.85.214.43) by server-3.tower-27.messagelabs.com with RC4-SHA encrypted SMTP; 9 Sep 2011 12:43:12 -0000 Received: by bkas6 with SMTP id s6so1376316bka.30 for ; Fri, 09 Sep 2011 05:43:33 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:x-enigmail-version:content-type; bh=K4MJkNsigVMqg7Ih6ktm0s/tlodZ+Gpppx7xNLwZXe8=; b=VntU/e30ou3jjy1WFiYfpyCwAlzh+Lf4dZ9b+kKQH7Fw40Z3oXjaigjNKBYE3q+LAC hesgpOcGfpp1HfSNdGc9rewVMztKLSoo4Biwi/KCBtzFo8JGY5OZ30qS+uAw7s3b+xZi ns/FhzH0H+kNbECzb8MGk8MshzVEMfGsT+gdo= Received: by 10.204.135.17 with SMTP id l17mr235715bkt.125.1315572213334; Fri, 09 Sep 2011 05:43:33 -0700 (PDT) Received: from [192.168.77.158] (horkheimer.ti5.tu-harburg.de [134.28.77.9]) by mx.google.com with ESMTPS id k8sm2225856bku.7.2011.09.09.05.43.31 (version=SSLv3 cipher=OTHER); Fri, 09 Sep 2011 05:43:32 -0700 (PDT) Message-ID: <4E6A09F2.4040405@gmail.com> Date: Fri, 09 Sep 2011 14:43:30 +0200 From: =?UTF-8?B?U3ZlbiBLw7ZobGVy?= User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:6.0) Gecko/20110829 Thunderbird/6.0 MIME-Version: 1.0 To: Stefano Stabellini Subject: Re: [Xen-devel] Re: xl vs. xm, possible bug in xl References: <20110908170755.GB16730@dumpdata.com> <4E69F80A.5060905@gmail.com> In-Reply-To: X-Enigmail-Version: 1.3 Cc: "xen-devel@lists.xensource.com" X-BeenThere: xen-devel@lists.xensource.com X-Mailman-Version: 2.1.5 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0589543495==" Sender: xen-devel-bounces@lists.xensource.com Errors-To: xen-devel-bounces@lists.xensource.com This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --===============0589543495== Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="------------enigDCBC8482E67F6FEFDDE6E96D" This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enigDCBC8482E67F6FEFDDE6E96D Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Am 09.09.2011 14:05, schrieb Stefano Stabellini: > On Fri, 9 Sep 2011, Sven K=C3=B6hler wrote: >> Am 09.09.2011 13:27, schrieb Stefano Stabellini: >>>> Any clue, that the second problem is about? >>>>> # xl create /etc/xen/xen-sk1 >>>>> Parsing config file /etc/xen/xen-sk1 >>>>> libxl: error: libxl_device.c:476:libxl__wait_for_device_model Devic= e Model not ready >>>>> xl: fatal error: libxl_create.c:535, rc=3D-1: libxl__confirm_device= _model_startup >>> >>> That means that qemu failed to start. Could you please cat >>> /var/log/xen/qemu-dm-domainname.log? >> >> There is no such file (my domain config lacks a name=3D"something" lin= e). >> However qemu-dm-test.log does exist and is of recent date, and it says= >> that qemu cannot be started. This is very plausible, since qemu is not= >> even installed. This machine is supposed to start paravirt guests only= =2E >> And xen has been compiled without support for hvm guests. (Not sure >> right now, what the gentoo people do to disable support support for hv= m >> guests). >> >> Does my config file for the domain (see one of my previous emails in >> this thread) indicate, that the machine is a hvm domain? How can I tel= l >> xl that this a paravirt domain, and qemu is not needed and should not = be >> used? >=20 > I think I have found the issue: if blktap2 is not enabled xl is going t= o > start qemu (to provide a disk backend) even if it is not actually neede= d > because the user wants to use blkback. >=20 > We have a patch upstream to fix this issue but it hasn't been backporte= d > to 4.1: Thanks, sounds like this will fix my problem. Is there any chance that this is going to be in 4.1.2 final? Regards, Sven --------------enigDCBC8482E67F6FEFDDE6E96D Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.17 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAk5qCfMACgkQ7Ww7FjRBE4C0PQCfd1+9FLmYP3POAXMkb3N0uZoi ZCMAn3e8XkNKW9ZA1SeH+qzrA0/XFOo6 =6Uo8 -----END PGP SIGNATURE----- --------------enigDCBC8482E67F6FEFDDE6E96D-- --===============0589543495== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel --===============0589543495==-- From xen-devel-bounces@lists.xensource.com Fri Sep 09 05:45:49 2011 Return-path: Envelope-to: www-data@lists.xensource.com Delivery-date: Fri, 09 Sep 2011 05:45:49 -0700 Received: from localhost ([127.0.0.1] helo=lists.colo.xensource.com) by lists.xensource.com with esmtp (Exim 4.43) id 1R20Sr-0005Uz-Ij; Fri, 09 Sep 2011 05:45:49 -0700 Received: from mail216.messagelabs.com ([85.158.143.99]) by lists.xensource.com with esmtp (Exim 4.43) id 1R20Qm-0004qe-TR for xen-devel@lists.xensource.com; Fri, 09 Sep 2011 05:43:41 -0700 X-Env-Sender: tim@xen.org X-Msg-Ref: server-13.tower-216.messagelabs.com!1315572217!17696575!1 X-Originating-IP: [81.29.64.94] X-StarScan-Version: 6.3.6; banners=-,-,- X-VirusChecked: Checked Received: (qmail 28822 invoked from network); 9 Sep 2011 12:43:37 -0000 Received: from ocelot.phlegethon.org (HELO mail.phlegethon.org) (81.29.64.94) by server-13.tower-216.messagelabs.com with DHE-RSA-AES256-SHA encrypted SMTP; 9 Sep 2011 12:43:37 -0000 Received: from tjd by mail.phlegethon.org with local (Exim 4.67 (FreeBSD)) (envelope-from ) id 1R20Qi-000PNp-L2; Fri, 09 Sep 2011 12:43:36 +0000 Date: Fri, 9 Sep 2011 13:43:36 +0100 From: Tim Deegan To: Christoph Egger Message-ID: <20110909124336.GB93737@ocelot.phlegethon.org> References: <4E69FDBA.6090409@amd.com> Mime-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline In-Reply-To: <4E69FDBA.6090409@amd.com> User-Agent: Mutt/1.4.2.1i Cc: xen-devel@lists.xensource.com Subject: [Xen-devel] Re: nested virtualization: cpuid PSE36 X-BeenThere: xen-devel@lists.xensource.com X-Mailman-Version: 2.1.5 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xensource.com Errors-To: xen-devel-bounces@lists.xensource.com cc-ing xen-devel. Hi, At 13:51 +0200 on 09 Sep (1315576282), Christoph Egger wrote: > I am trying to get Hyper-V up and running as l1 hypervisor. > It claims the cpu does not provide the > required feature: leaf 0x1, edx, bit 17 (= PSE36). Huh. Is this 32-bit Hyper-V? If it's only needed for 32-bit then it's not so important (32-bit Hyper-V is going away in Win8 anyway). I wonder if it's actually used - I guess if you don't need 4k protection granularity for high mappings then it saves on pagetable space and TLB pressure. > Xen does indeed not propagate this feature bit to the l1 guest. > > What do you think how should this be done to support this feature bit > for the hap case? I think that for HAP it would be enough to add support to the guest_walk.c page walker (and gate the cpuid bit so we never advertise it to shadow-paging guests). It shouldn't be hard to add it to the shadow pagetables either; it was just never needed before. Cheers, Tim. _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel From xen-devel-bounces@lists.xensource.com Fri Sep 09 05:47:00 2011 Return-path: Envelope-to: www-data@lists.xensource.com Delivery-date: Fri, 09 Sep 2011 05:47:00 -0700 Received: from localhost ([127.0.0.1] helo=lists.colo.xensource.com) by lists.xensource.com with esmtp (Exim 4.43) id 1R20U0-0005wQ-8S; Fri, 09 Sep 2011 05:47:00 -0700 Received: from mail174.messagelabs.com ([85.158.138.51]) by lists.xensource.com with smtp (Exim 4.43) id 1R20Sy-0005XB-Pm for xen-devel@lists.xensource.com; Fri, 09 Sep 2011 05:45:57 -0700 X-Env-Sender: Stefano.Stabellini@eu.citrix.com X-Msg-Ref: server-9.tower-174.messagelabs.com!1315572353!24811055!1 X-Originating-IP: [62.200.22.115] X-StarScan-Version: 6.3.6; banners=-,-,- X-VirusChecked: Checked Received: (qmail 26295 invoked from network); 9 Sep 2011 12:45:53 -0000 Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115) by server-9.tower-174.messagelabs.com with SMTP; 9 Sep 2011 12:45:53 -0000 X-IronPort-AV: E=Sophos;i="4.68,356,1312156800"; d="scan'208";a="7697682" Received: from lonpmailmx01.citrite.net ([10.30.203.162]) by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5; 09 Sep 2011 12:45:53 +0000 Received: from kaball.uk.xensource.com (10.80.2.59) by LONPMAILMX01.citrite.net (10.30.203.162) with Microsoft SMTP Server id 8.3.137.0; Fri, 9 Sep 2011 13:45:53 +0100 Date: Fri, 9 Sep 2011 13:54:07 +0100 From: Stefano Stabellini X-X-Sender: sstabellini@kaball-desktop To: =?UTF-8?Q?Sven_K=C3=B6hler?= Subject: Re: [Xen-devel] Re: xl vs. xm, possible bug in xl In-Reply-To: <4E6A09F2.4040405@gmail.com> Message-ID: References: <20110908170755.GB16730@dumpdata.com> <4E69F80A.5060905@gmail.com> <4E6A09F2.4040405@gmail.com> User-Agent: Alpine 2.00 (DEB 1167 2008-08-23) MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="8323329-1884503695-1315572862=:12963" Cc: Ian Jackson , "xen-devel@lists.xensource.com" , Keir Fraser , Stefano Stabellini X-BeenThere: xen-devel@lists.xensource.com X-Mailman-Version: 2.1.5 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xensource.com Errors-To: xen-devel-bounces@lists.xensource.com --8323329-1884503695-1315572862=:12963 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: 8BIT On Fri, 9 Sep 2011, Sven Köhler wrote: > Am 09.09.2011 14:05, schrieb Stefano Stabellini: > > On Fri, 9 Sep 2011, Sven Köhler wrote: > >> Am 09.09.2011 13:27, schrieb Stefano Stabellini: > >>>> Any clue, that the second problem is about? > >>>>> # xl create /etc/xen/xen-sk1 > >>>>> Parsing config file /etc/xen/xen-sk1 > >>>>> libxl: error: libxl_device.c:476:libxl__wait_for_device_model Device Model not ready > >>>>> xl: fatal error: libxl_create.c:535, rc=-1: libxl__confirm_device_model_startup > >>> > >>> That means that qemu failed to start. Could you please cat > >>> /var/log/xen/qemu-dm-domainname.log? > >> > >> There is no such file (my domain config lacks a name="something" line). > >> However qemu-dm-test.log does exist and is of recent date, and it says > >> that qemu cannot be started. This is very plausible, since qemu is not > >> even installed. This machine is supposed to start paravirt guests only. > >> And xen has been compiled without support for hvm guests. (Not sure > >> right now, what the gentoo people do to disable support support for hvm > >> guests). > >> > >> Does my config file for the domain (see one of my previous emails in > >> this thread) indicate, that the machine is a hvm domain? How can I tell > >> xl that this a paravirt domain, and qemu is not needed and should not be > >> used? > > > > I think I have found the issue: if blktap2 is not enabled xl is going to > > start qemu (to provide a disk backend) even if it is not actually needed > > because the user wants to use blkback. > > > > We have a patch upstream to fix this issue but it hasn't been backported > > to 4.1: > > Thanks, sounds like this will fix my problem. > > Is there any chance that this is going to be in 4.1.2 final? I think it should be! --8323329-1884503695-1315572862=:12963 Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel --8323329-1884503695-1315572862=:12963-- From xen-devel-bounces@lists.xensource.com Fri Sep 09 05:50:59 2011 Return-path: Envelope-to: www-data@lists.xensource.com Delivery-date: Fri, 09 Sep 2011 05:50:59 -0700 Received: from localhost ([127.0.0.1] helo=lists.colo.xensource.com) by lists.xensource.com with esmtp (Exim 4.43) id 1R20Xr-00070q-7U; Fri, 09 Sep 2011 05:50:59 -0700 Received: from mail216.messagelabs.com ([85.158.143.99]) by lists.xensource.com with esmtp (Exim 4.43) id 1R20XR-0006p2-3j for xen-devel@lists.xensource.com; Fri, 09 Sep 2011 05:50:33 -0700 X-Env-Sender: keir.xen@gmail.com X-Msg-Ref: server-11.tower-216.messagelabs.com!1315572630!10094396!1 X-Originating-IP: [74.125.82.171] X-StarScan-Version: 6.3.6; banners=-,-,- X-VirusChecked: Checked Received: (qmail 3044 invoked from network); 9 Sep 2011 12:50:30 -0000 Received: from mail-wy0-f171.google.com (HELO mail-wy0-f171.google.com) (74.125.82.171) by server-11.tower-216.messagelabs.com with RC4-SHA encrypted SMTP; 9 Sep 2011 12:50:30 -0000 Received: by wyh13 with SMTP id 13so1647490wyh.30 for ; Fri, 09 Sep 2011 05:50:29 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=user-agent:date:subject:from:to:cc:message-id:thread-topic :thread-index:in-reply-to:mime-version:content-type :content-transfer-encoding; bh=95q/3bAFRJsM1bF2CMkS4n886L8yYaQWIxBySbD5fk8=; b=sOJBZ5Vp4KS7eTwoaSTDJcs8YMiXwT1fUFbSj5hSLIclI3MAm4v2P5g4XsxQW6SC4E N617Rzr0m5FpMWuTXe6+FAow1YII5S/Z30uBHBsaP8bhHnROM9QUSSzeAmeuqDaIGL+L tRrg9wHS7IsXpQ/S14hwK+BuuzC92aahNgut4= Received: by 10.216.137.88 with SMTP id x66mr1823966wei.101.1315572629610; Fri, 09 Sep 2011 05:50:29 -0700 (PDT) Received: from [192.168.1.78] (host86-137-116-193.range86-137.btcentralplus.com [86.137.116.193]) by mx.google.com with ESMTPS id fd4sm7399942wbb.21.2011.09.09.05.50.26 (version=SSLv3 cipher=OTHER); Fri, 09 Sep 2011 05:50:28 -0700 (PDT) User-Agent: Microsoft-Entourage/12.30.0.110427 Date: Fri, 09 Sep 2011 13:50:22 +0100 Subject: Re: [Xen-devel] Query about cpuidle From: Keir Fraser To: Andrew Cooper , Message-ID: Thread-Topic: [Xen-devel] Query about cpuidle Thread-Index: Acxu7wlZP9sSwgg3gkygHpKUqoss2Q== In-Reply-To: <4E6A03FE.8090202@citrix.com> Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit Cc: "xen-devel@lists.xensource.com" X-BeenThere: xen-devel@lists.xensource.com X-Mailman-Version: 2.1.5 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xensource.com Errors-To: xen-devel-bounces@lists.xensource.com On 09/09/2011 13:18, "Andrew Cooper" wrote: > Hello, > > We have recently had a support escalation about Xen-4.1.1 being unable > to boot on HP BL460c G7 blades. The problem turned out to be a null > function pointer deference (ns_to_tick in cpu_idle.c) during early boot > of dom0, in the set_cx_pminfo function. > > I applied your patch, changeset 23662:2faba14bac13, about initializing > default C state information, and this appears to have fixed the problem. > > However, I see in the patch that setting up the function pointers > (ns_to_tick, tick_to_ns etc) is predicated on the hypercall coming in on > CPU0. Firstly, it's predicated on the hypercall addressing CPU0, rather than being executed on CPU0. Secondly, the cpuidle_init_cpu() functiomn is *also* called from the CPU-hotplug path in Xen, and is called directly from the presmp_initcall path for CPU0. I don't know why it is called both on a hypercall path and on a hotplug path, it seems weird. But anyhow, this means that the function pointers will guaranteed get set up early during Xen boot? I can only sympathise and agree that the code is complicated and opaque, however. -- Keir > What guarantees are in place to ensure that these function > pointers get set up? I cant see anything obvious from the code, but > have to admit that the null pointer deference appears to have gone away. > > Thanks in advance, _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel From xen-devel-bounces@lists.xensource.com Fri Sep 09 05:56:20 2011 Return-path: Envelope-to: www-data@lists.xensource.com Delivery-date: Fri, 09 Sep 2011 05:56:20 -0700 Received: from localhost ([127.0.0.1] helo=lists.colo.xensource.com) by lists.xensource.com with esmtp (Exim 4.43) id 1R20d2-0007SG-Am; Fri, 09 Sep 2011 05:56:20 -0700 Received: from mail216.messagelabs.com ([85.158.143.99]) by lists.xensource.com with smtp (Exim 4.43) id 1R20cb-0007Ft-LQ for xen-devel@lists.xensource.com; Fri, 09 Sep 2011 05:55:53 -0700 X-Env-Sender: gcvxd-xen-devel@m.gmane.org X-Msg-Ref: server-9.tower-216.messagelabs.com!1315572950!17686461!1 X-Originating-IP: [80.91.229.12] X-StarScan-Version: 6.3.6; banners=-,-,- X-VirusChecked: Checked Received: (qmail 9987 invoked from network); 9 Sep 2011 12:55:50 -0000 Received: from lo.gmane.org (HELO lo.gmane.org) (80.91.229.12) by server-9.tower-216.messagelabs.com with SMTP; 9 Sep 2011 12:55:50 -0000 Received: from list by lo.gmane.org with local (Exim 4.69) (envelope-from ) id 1R20cY-0007eR-B0 for xen-devel@lists.xensource.com; Fri, 09 Sep 2011 14:55:50 +0200 Received: from horkheimer.ti5.tu-harburg.de ([134.28.77.9]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Fri, 09 Sep 2011 14:55:50 +0200 Received: from sven.koehler by horkheimer.ti5.tu-harburg.de with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Fri, 09 Sep 2011 14:55:50 +0200 X-Injected-Via-Gmane: http://gmane.org/ To: xen-devel@lists.xensource.com From: =?UTF-8?B?U3ZlbiBLw7ZobGVy?= Date: Fri, 09 Sep 2011 14:55:38 +0200 Lines: 40 Message-ID: References: <4E694CFB.1060203@citrix.com> <4E6A0034.10706@citrix.com> Mime-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit X-Complaints-To: usenet@dough.gmane.org X-Gmane-NNTP-Posting-Host: horkheimer.ti5.tu-harburg.de User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:6.0) Gecko/20110829 Thunderbird/6.0 In-Reply-To: <4E6A0034.10706@citrix.com> Subject: [Xen-devel] Re: computer stalls instead of reboot X-BeenThere: xen-devel@lists.xensource.com X-Mailman-Version: 2.1.5 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xensource.com Errors-To: xen-devel-bounces@lists.xensource.com Am 09.09.2011 14:01, schrieb Andrew Cooper: > On 09/09/11 00:40, Sven Köhler wrote: >> Am 09.09.2011 01:17, schrieb Andrew Cooper: >>> Does your "remote" method involve actually pushing the reset button, and >>> does this method actually work under normal circumstances? >> I think, there is a device connected to the connector on the >> motherboard, to which the reset button would normally be attached. > > Ok, in which case the state your computer is getting into is a very > broken state, if the reset button is not working > >>> As for the problem itself, do you have C states enabled in the BIOS? >>> This sounds similar to several errata published for the i7 series. >> I'm not sure how to tell whether C states are disabled/enabled. >> What would those BIOS options typically be called? > > That is too bios dependent to say for sure, but typically "C states" or > "deep sleep", with some intel ones going for "C1e" > >> Also, should I enable or disable them, in order to workaround those >> errata that you mention? > > They should be disabled. The errata state that there are several > situations when moving in and our of deep c states which cause > processors to lock up irreparably. Thanks for you help so far. I will try to disable the C-states as soon as I have the time. One more thing: are you aware of any way for telling from inside dom0 whether these C-states are enabled/disabled? Is the kernel or the xen hypervisor able to tell whether they are active? Also, is there any xen hypervisor command line option to disable the use of them? Regards, Sven _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel From xen-devel-bounces@lists.xensource.com Fri Sep 09 06:15:41 2011 Return-path: Envelope-to: www-data@lists.xensource.com Delivery-date: Fri, 09 Sep 2011 06:15:41 -0700 Received: from localhost ([127.0.0.1] helo=lists.colo.xensource.com) by lists.xensource.com with esmtp (Exim 4.43) id 1R20vl-0008Go-Ok; Fri, 09 Sep 2011 06:15:41 -0700 Received: from mail174.messagelabs.com ([85.158.138.51]) by lists.xensource.com with esmtp (Exim 4.43) id 1R20uu-00083k-V7; Fri, 09 Sep 2011 06:14:49 -0700 X-Env-Sender: pasik@iki.fi X-Msg-Ref: server-8.tower-174.messagelabs.com!1315574080!17168920!1 X-Originating-IP: [192.89.123.25] X-StarScan-Version: 6.3.6; banners=-,-,- X-VirusChecked: Checked Received: (qmail 4804 invoked from network); 9 Sep 2011 13:14:45 -0000 Received: from smtp.tele.fi (HELO smtp.tele.fi) (192.89.123.25) by server-8.tower-174.messagelabs.com with DHE-RSA-AES256-SHA encrypted SMTP; 9 Sep 2011 13:14:45 -0000 X-Originating-Ip: [194.89.68.22] Received: from ydin.reaktio.net (reaktio.net [194.89.68.22]) by smtp.tele.fi (Postfix) with ESMTP id E7A122ADF; Fri, 9 Sep 2011 16:14:38 +0300 (EEST) Received: by ydin.reaktio.net (Postfix, from userid 1001) id B374C20057; Fri, 9 Sep 2011 16:14:38 +0300 (EEST) Date: Fri, 9 Sep 2011 16:14:38 +0300 From: Pasi =?iso-8859-1?Q?K=E4rkk=E4inen?= To: jim burns Message-ID: <20110909131438.GY12984@reaktio.net> References: <201107231426.56811.jim_burn@bellsouth.net> <1816797.G1BumNNXCy@dell4550> <3588908.GoxUj34Eqr@dell4550> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <3588908.GoxUj34Eqr@dell4550> User-Agent: Mutt/1.5.18 (2008-05-17) Cc: Todd Deshane , xen-devel@lists.xensource.com, xen-users@lists.xensource.com, Fedora Xen List Subject: [Xen-devel] Re: Continuing BUG:-iness booting Fedora Rawhide 3.1.0-rc's (was Summary: Experiences setting up a debug serial port) X-BeenThere: xen-devel@lists.xensource.com X-Mailman-Version: 2.1.5 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xensource.com Errors-To: xen-devel-bounces@lists.xensource.com Hello, Added xen-devel to CC.. On Thu, Sep 08, 2011 at 08:36:04PM -0400, jim burns wrote: > > Rawhide is up to 3.1.0-0.rc5.git0.0.fc17 , and still the same dom0 boot bugs > as in rc4. Can you please post the full Xen + 3.1-rc5 dom0 boot logs again.. -- Pasi _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel From xen-devel-bounces@lists.xensource.com Fri Sep 09 06:29:13 2011 Return-path: Envelope-to: www-data@lists.xensource.com Delivery-date: Fri, 09 Sep 2011 06:29:13 -0700 Received: from localhost ([127.0.0.1] helo=lists.colo.xensource.com) by lists.xensource.com with esmtp (Exim 4.43) id 1R218p-00019E-Kx; Fri, 09 Sep 2011 06:29:12 -0700 Received: from mail27.messagelabs.com ([193.109.254.147]) by lists.xensource.com with esmtp (Exim 4.43) id 1R2186-0000wY-K2 for xen-devel@lists.xensource.com; Fri, 09 Sep 2011 06:28:26 -0700 X-Env-Sender: pasik@iki.fi X-Msg-Ref: server-14.tower-27.messagelabs.com!1315574890!35466490!1 X-Originating-IP: [192.89.123.25] X-StarScan-Version: 6.3.6; banners=-,-,- X-VirusChecked: Checked Received: (qmail 12230 invoked from network); 9 Sep 2011 13:28:10 -0000 Received: from smtp.tele.fi (HELO smtp.tele.fi) (192.89.123.25) by server-14.tower-27.messagelabs.com with DHE-RSA-AES256-SHA encrypted SMTP; 9 Sep 2011 13:28:10 -0000 X-Originating-Ip: [194.89.68.22] Received: from ydin.reaktio.net (reaktio.net [194.89.68.22]) by smtp.tele.fi (Postfix) with ESMTP id EB2631669; Fri, 9 Sep 2011 16:28:22 +0300 (EEST) Received: by ydin.reaktio.net (Postfix, from userid 1001) id D227F20057; Fri, 9 Sep 2011 16:28:22 +0300 (EEST) Date: Fri, 9 Sep 2011 16:28:22 +0300 From: Pasi =?iso-8859-1?Q?K=E4rkk=E4inen?= To: komkon555 Subject: Re: Re : Re : Re : [Xen-devel] Re: Patches for VGA-Passthrough XEN 4.2 unstable Message-ID: <20110909132822.GZ12984@reaktio.net> References: <1315343879.61837.YahooMailNeo@web29818.mail.ird.yahoo.com> <1315382742268-4777689.post@n5.nabble.com> <1315389138.56652.YahooMailNeo@web29801.mail.ird.yahoo.com> <1315398360680-4778339.post@n5.nabble.com> <1315401901083-4778494.post@n5.nabble.com> <1315403644525-4778586.post@n5.nabble.com> <1315405372.87224.YahooMailNeo@web29801.mail.ird.yahoo.com> <1315405921936-4778727.post@n5.nabble.com> <1315408931610-4778925.post@n5.nabble.com> <1315554847212-4785386.post@n5.nabble.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <1315554847212-4785386.post@n5.nabble.com> User-Agent: Mutt/1.5.18 (2008-05-17) Cc: xen-devel@lists.xensource.com X-BeenThere: xen-devel@lists.xensource.com X-Mailman-Version: 2.1.5 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xensource.com Errors-To: xen-devel-bounces@lists.xensource.com On Fri, Sep 09, 2011 at 12:54:07AM -0700, komkon555 wrote: > Hi. There is the promised report to JavMV: with fixes on dsd are > your patches also functional. Windows XP starts and GTX260 works perfect > with driver version 275.33. > Some news more: The best results I got with this configuration: > xen 4.1-unstable changeset 21668 (patched clearly with these > http://lists.xensource.com/archives/html/xen-devel/2010-05/msg00441.html > patches , dsd fixed according to David TECHER) + jeremi xen kernel 2.6.32.45 > (xenfs static). This configuration works excellent both: with primary and > secondary vga-adapter (GTX260). There are two Problem with all > configurations: > 1. DomU can be started only once. Being correctly shouted down, starts > DomU no more. > 2. Physical usb- keyboard and mouse can not be assigned to DomU (regular usb > assignment has no effect, PVUSB crashes) > Did you try normal PCI passthru? passthru the whole USB controller pci device.. -- Pasi _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel From xen-devel-bounces@lists.xensource.com Fri Sep 09 06:32:46 2011 Return-path: Envelope-to: www-data@lists.xensource.com Delivery-date: Fri, 09 Sep 2011 06:32:46 -0700 Received: from localhost ([127.0.0.1] helo=lists.colo.xensource.com) by lists.xensource.com with esmtp (Exim 4.43) id 1R21CI-0001fb-Ce; Fri, 09 Sep 2011 06:32:46 -0700 Received: from mail182.messagelabs.com ([85.158.139.83]) by lists.xensource.com with esmtp (Exim 4.43) id 1R21Bc-0001QT-97 for xen-devel@lists.xensource.com; Fri, 09 Sep 2011 06:32:04 -0700 X-Env-Sender: modelnine@modelnine.org X-Msg-Ref: server-6.tower-182.messagelabs.com!1315575120!17702907!1 X-Originating-IP: [178.63.106.162] X-StarScan-Version: 6.3.6; banners=-,-,- X-VirusChecked: Checked Received: (qmail 4497 invoked from network); 9 Sep 2011 13:32:01 -0000 Received: from mail.modelnine.org (HELO mail.modelnine.org) (178.63.106.162) by server-6.tower-182.messagelabs.com with DHE-RSA-AES256-SHA encrypted SMTP; 9 Sep 2011 13:32:01 -0000 Received: from [10.2.254.2] (unknown [81.14.211.35]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) (Authenticated sender: modelnine@modelnine.org) by mail.modelnine.org (Postfix) with ESMTPSA id 7E234E1AA for ; Fri, 9 Sep 2011 15:32:00 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=modelnine.org; s=modelnine1012; t=1315575120; bh=UP7nzW6Qc2Q1GLxHOEEdoci0o+Ez5fKyPhTTi0+6JjM=; h=Message-ID:Date:From:MIME-Version:To:Subject:References: In-Reply-To:Content-Type:Content-Transfer-Encoding; b=OSAmYhO/m0fK/ETSEXL6UOkA3ow5xvN38jljaKDG41mW5mY9vXv5hR+BfjGeRFthl BWSNhwY6ZPmFKVTQYAHbBBkcOZZyel5+7Rmoc1dgizLoZz+F3WLKcn3l2av+0dc+iw pHIRikgUkBnEMOPaiEuCfB9nI5DRWmAwnSlZgSmU= Message-ID: <4E6A1549.90806@modelnine.org> Date: Fri, 09 Sep 2011 15:31:53 +0200 From: Heiko Wundram User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:7.0) Gecko/20110905 Thunderbird/7.0 MIME-Version: 1.0 To: xen-devel@lists.xensource.com Subject: Re: [Xen-devel] Re: computer stalls instead of reboot References: <4E694CFB.1060203@citrix.com> <4E6A0034.10706@citrix.com> In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit X-BeenThere: xen-devel@lists.xensource.com X-Mailman-Version: 2.1.5 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xensource.com Errors-To: xen-devel-bounces@lists.xensource.com Am 09.09.2011 14:55, schrieb Sven Köhler: > Without knowing much of the previous discussion: is this related to Hetzner-servers (from seeing the mainboard type, I can only guess that it's a machine from the "new" Hetzner-series)? If that's the case, use: "acpi=off" on the Dom0-kernel commandline (I use a Gentoo-adapted xen-sources-2.6.38 [rebased SuSE-Dom0-kernel]), that should solve the reboot problems. IIRC somewhere on the Hetzner-site they mention this, too. No reboot hangs/problems for me after that. -- --- Heiko. _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel From xen-devel-bounces@lists.xensource.com Fri Sep 09 06:47:04 2011 Return-path: Envelope-to: www-data@lists.xensource.com Delivery-date: Fri, 09 Sep 2011 06:47:04 -0700 Received: from localhost ([127.0.0.1] helo=lists.colo.xensource.com) by lists.xensource.com with esmtp (Exim 4.43) id 1R21Q8-0002La-9d; Fri, 09 Sep 2011 06:47:04 -0700 Received: from mail27.messagelabs.com ([193.109.254.147]) by lists.xensource.com with smtp (Exim 4.43) id 1R21PR-000293-AR for xen-devel@lists.xensource.com; Fri, 09 Sep 2011 06:46:21 -0700 X-Env-Sender: gcvxd-xen-devel@m.gmane.org X-Msg-Ref: server-12.tower-27.messagelabs.com!1315575964!41767338!1 X-Originating-IP: [80.91.229.12] X-StarScan-Version: 6.3.6; banners=-,-,- X-VirusChecked: Checked Received: (qmail 25989 invoked from network); 9 Sep 2011 13:46:04 -0000 Received: from lo.gmane.org (HELO lo.gmane.org) (80.91.229.12) by server-12.tower-27.messagelabs.com with SMTP; 9 Sep 2011 13:46:04 -0000 Received: from list by lo.gmane.org with local (Exim 4.69) (envelope-from ) id 1R21PJ-0000BV-SL for xen-devel@lists.xensource.com; Fri, 09 Sep 2011 15:46:13 +0200 Received: from horkheimer.ti5.tu-harburg.de ([134.28.77.9]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Fri, 09 Sep 2011 15:46:13 +0200 Received: from sven.koehler by horkheimer.ti5.tu-harburg.de with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Fri, 09 Sep 2011 15:46:13 +0200 X-Injected-Via-Gmane: http://gmane.org/ To: xen-devel@lists.xensource.com From: =?UTF-8?B?U3ZlbiBLw7ZobGVy?= Date: Fri, 09 Sep 2011 15:45:56 +0200 Lines: 28 Message-ID: References: <4E694CFB.1060203@citrix.com> <4E6A0034.10706@citrix.com> <4E6A1549.90806@modelnine.org> Mime-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit X-Complaints-To: usenet@dough.gmane.org X-Gmane-NNTP-Posting-Host: horkheimer.ti5.tu-harburg.de User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:6.0) Gecko/20110829 Thunderbird/6.0 In-Reply-To: <4E6A1549.90806@modelnine.org> Subject: [Xen-devel] Re: computer stalls instead of reboot X-BeenThere: xen-devel@lists.xensource.com X-Mailman-Version: 2.1.5 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xensource.com Errors-To: xen-devel-bounces@lists.xensource.com Am 09.09.2011 15:31, schrieb Heiko Wundram: > Am 09.09.2011 14:55, schrieb Sven Köhler: >> > > Without knowing much of the previous discussion: is this related to > Hetzner-servers (from seeing the mainboard type, I can only guess that > it's a machine from the "new" Hetzner-series)? Yes it is a Hetzner machine! > If that's the case, use: "acpi=off" on the Dom0-kernel commandline (I > use a Gentoo-adapted xen-sources-2.6.38 [rebased SuSE-Dom0-kernel]), > that should solve the reboot problems. IIRC somewhere on the > Hetzner-site they mention this, too. No reboot hangs/problems for me > after that. I will try acpi=off as soon as possible. I wonder, what the disadvantage are. The hypervisor will still regulate CPU frequency, will it not? Also, is the dom0 kernel doing something that it shouldn't do? (maybe something that collides with the ACPI-related activities of the hypervisor, if there are any?) Regards, Sven _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel From xen-devel-bounces@lists.xensource.com Fri Sep 09 06:52:54 2011 Return-path: Envelope-to: www-data@lists.xensource.com Delivery-date: Fri, 09 Sep 2011 06:52:54 -0700 Received: from localhost ([127.0.0.1] helo=lists.colo.xensource.com) by lists.xensource.com with esmtp (Exim 4.43) id 1R21Vm-0002lv-Dv; Fri, 09 Sep 2011 06:52:54 -0700 Received: from mail174.messagelabs.com ([85.158.138.51]) by lists.xensource.com with esmtp (Exim 4.43) id 1R21VF-0002aE-Hx for xen-devel@lists.xensource.com; Fri, 09 Sep 2011 06:52:21 -0700 X-Env-Sender: modelnine@modelnine.org X-Msg-Ref: server-5.tower-174.messagelabs.com!1315576337!27152561!1 X-Originating-IP: [178.63.106.162] X-StarScan-Version: 6.3.6; banners=-,-,- X-VirusChecked: Checked Received: (qmail 32540 invoked from network); 9 Sep 2011 13:52:18 -0000 Received: from mail.modelnine.org (HELO mail.modelnine.org) (178.63.106.162) by server-5.tower-174.messagelabs.com with DHE-RSA-AES256-SHA encrypted SMTP; 9 Sep 2011 13:52:18 -0000 Received: from [10.2.254.2] (unknown [81.14.211.35]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) (Authenticated sender: modelnine@modelnine.org) by mail.modelnine.org (Postfix) with ESMTPSA id B6696E1AA for ; Fri, 9 Sep 2011 15:52:17 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=modelnine.org; s=modelnine1012; t=1315576337; bh=sQNNGiYX0V3teO46Pb0KywY5BDA3fAMuuneUIJoIfOY=; h=Message-ID:Date:From:MIME-Version:To:Subject:References: In-Reply-To:Content-Type:Content-Transfer-Encoding; b=WzkzamP+DgxaTODwTVtphEfzbLBcRQ5kDzolMp0vU436pVwfWcpgggBOLpaZG+YLh wCKHFv2aZ72FBGMABhUdSy+bwMLaAtO3uDoU7VrZ/2z0EAH5Djc2dwtagKC0aDI1Ig 5p3DVO1WvB4mR2cB0KCTkw710hm7G8c42nYbyT04= Message-ID: <4E6A1A0A.5040401@modelnine.org> Date: Fri, 09 Sep 2011 15:52:10 +0200 From: Heiko Wundram User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:7.0) Gecko/20110905 Thunderbird/7.0 MIME-Version: 1.0 To: xen-devel@lists.xensource.com Subject: Re: [Xen-devel] Re: computer stalls instead of reboot References: <4E694CFB.1060203@citrix.com> <4E6A0034.10706@citrix.com> <4E6A1549.90806@modelnine.org> In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit X-BeenThere: xen-devel@lists.xensource.com X-Mailman-Version: 2.1.5 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xensource.com Errors-To: xen-devel-bounces@lists.xensource.com Am 09.09.2011 15:45, schrieb Sven Köhler: > I wonder, what the disadvantage are. > The hypervisor will still regulate CPU frequency, will it not? No, it will not. > Also, is the dom0 kernel doing something that it shouldn't do? > (maybe something that collides with the ACPI-related activities of the > hypervisor, if there are any?) I guess the BIOS is simply reporting broken ACPI tables to the operating system (the board is a "consumer" board, so you can guess that the manufacturer only tests the ACPI-tables for compatability with Windows). The ACPI tables (AFAIK, someone correct me) also contain a method for rebooting the system, which simply doesn't work/is broken when Xen is involved. Forcing acpi=off means that the normal triple-fault or kbd-controller reset machinery is always used, as ACPI isn't even initialized. What struck me as odd, though: you can configure Linux to use "some other" form of hard reset through a kernel parameter, but setting that to explicitly use triple-faults didn't work, either (same hangs), so possibly it's some form of additional interaction between Xen, the board and the hypervisor. Anyway, the Hetzner "recommended" fix is just what I sent you, and I can confirm that works. -- --- Heiko. _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel From xen-devel-bounces@lists.xensource.com Fri Sep 09 06:54:29 2011 Return-path: Envelope-to: www-data@lists.xensource.com Delivery-date: Fri, 09 Sep 2011 06:54:29 -0700 Received: from localhost ([127.0.0.1] helo=lists.colo.xensource.com) by lists.xensource.com with esmtp (Exim 4.43) id 1R21XJ-00039x-Nw; Fri, 09 Sep 2011 06:54:29 -0700 Received: from mail21.messagelabs.com ([85.158.143.35]) by lists.xensource.com with smtp (Exim 4.43) id 1R21Vr-0002n8-BN for xen-devel@lists.xensource.com; Fri, 09 Sep 2011 06:53:08 -0700 X-Env-Sender: jim_burn@bellsouth.net X-Msg-Ref: server-8.tower-21.messagelabs.com!1315576359!58365816!1 X-Originating-IP: [98.139.44.162] X-StarScan-Version: 6.3.6; banners=-,-,- X-VirusChecked: Checked Received: (qmail 24279 invoked from network); 9 Sep 2011 13:52:40 -0000 Received: from nm14-vm0.access.bullet.mail.sp2.yahoo.com (HELO nm14-vm0.access.bullet.mail.sp2.yahoo.com) (98.139.44.162) by server-8.tower-21.messagelabs.com with SMTP; 9 Sep 2011 13:52:40 -0000 Received: from [98.139.44.97] by nm14.access.bullet.mail.sp2.yahoo.com with NNFMP; 09 Sep 2011 13:52:53 -0000 Received: from [98.139.44.90] by tm2.access.bullet.mail.sp2.yahoo.com with NNFMP; 09 Sep 2011 13:52:53 -0000 Received: from [127.0.0.1] by omp1027.access.mail.sp2.yahoo.com with NNFMP; 09 Sep 2011 13:52:53 -0000 X-Yahoo-Newman-Id: 735583.93055.bm@omp1027.access.mail.sp2.yahoo.com Received: (qmail 228 invoked from network); 9 Sep 2011 13:52:53 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=bellsouth.net; s=s1024; t=1315576373; bh=Rp/9EIDUD1zeZVnKj9p2PeBf7zzvkHQi08gLSc8C1nM=; h=X-Yahoo-Newman-Property:X-YMail-OSG:X-Yahoo-SMTP:Received:From:To:Cc:Subject:Date:Message-ID:User-Agent:In-Reply-To:References:MIME-Version:Content-Type:Content-Transfer-Encoding; b=acXVilhzuQ10gPKM7dQKXXS6V4mPszrCR3ZcW9b6yIorjBal3Wc3gXiNc5zRd3FNpAv9i8aQq4QP7xoCG05UabvXD8OjNie+TOEM6SIsNS+WPzREAdt8XnDG53TRZHhnGnqmBQCJe/niqJIJA1oILUxOoEBvvKYeYEsZ5G15yjw= X-Yahoo-Newman-Property: ymail-3 X-YMail-OSG: K9.7Rc8VM1k7zRKcfFiv_FStqwiLIErAgNOV8knmvSkcDaA hLfsOrg.wu3xIfFzKX9U6ztnQt8QI2Z8GUgAUJ66756_XqlVo6O4TnU6V.W0 TyQXi3Kq2IqOg92XnYD.MbuRWKaZrPd2kNn8CmlyZtobHzmyzNv0jHNNUjq7 osnIbhvzpA4l_s_fQmdsxdoe9zUlaQAEn.UXS.FjqCHlQVXr9VKS0pqk8h.I 8ge7X9qyH8sVvLPWFulcRA08fX6rAtfg.9aYGFBndpQZ7UE3w5AytPkpEbtZ Dw_OwkZ1iYp1fT8bjZYHRUng9rrLO8ZDpqgCBrWbOeNMWf6BNvGBE.YAITFG cx1ZvFltDC8sWPZXSyG8BYFx1t2_z1HvqCI9xnc8SfvfIOCsDoOgzix9l9d8 26av3Un6ByFvYSwa3Gso2FfQkFhSCSpvxDnQhPqcBKrCxfN5p3Vm3RiKWhRx Qlb1Uvw-- X-Yahoo-SMTP: g0AhWW2swBA2djJKuhuwxPlPqLrHlDrycdPnfR9kZNrpKCA- Received: from dell4550.localnet (jim_burn@72.145.175.32 with plain) by smtp101.sbc.mail.gq1.yahoo.com with SMTP; 09 Sep 2011 06:52:49 -0700 PDT From: jim burns To: Pasi =?ISO-8859-1?Q?K=E4rkk=E4inen?= , xen-users@lists.xensource.com, xen-devel@lists.xensource.com Date: Fri, 09 Sep 2011 09:52:41 -0400 Message-ID: <13293012.CAopQqStiY@dell4550> User-Agent: KMail/4.7.0 (Linux/2.6.37.6-0.7-default; KDE/4.7.1; i686; ; ) In-Reply-To: <20110909131438.GY12984@reaktio.net> References: <201107231426.56811.jim_burn@bellsouth.net> <3588908.GoxUj34Eqr@dell4550> <20110909131438.GY12984@reaktio.net> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="nextPart3309830.VdPcCRNokM" Content-Transfer-Encoding: 7Bit Cc: Todd Deshane , Fedora Xen List Subject: [Xen-devel] Re: Continuing BUG:-iness booting Fedora Rawhide 3.1.0-rc's (was Summary: Experiences setting up a debug serial port) X-BeenThere: xen-devel@lists.xensource.com X-Mailman-Version: 2.1.5 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xensource.com Errors-To: xen-devel-bounces@lists.xensource.com --nextPart3309830.VdPcCRNokM Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="iso-8859-1" On Fri September 9 2011, 4:14:38 PM, Pasi K=E4rkk=E4inen wrote: > Hello, >=20 > Added xen-devel to CC.. >=20 > On Thu, Sep 08, 2011 at 08:36:04PM -0400, jim burns wrote: > > Rawhide is up to 3.1.0-0.rc5.git0.0.fc17 , and still the same dom0 = boot > > bugs as in rc4. >=20 > Can you please post the full Xen + 3.1-rc5 dom0 boot logs again.. >=20 > -- Pasi Sure, thanx, attached. Do you need a debug log also (initcall_debug deb= ug=20 loglevel=3D10)? The last four BUG:s (from Sep 8 17:12:20 on) were from starting a winx= p domu=20 (first 3 BUG:s), and destroying it at grub (the last BUG:). --nextPart3309830.VdPcCRNokM Content-Disposition: attachment; filename="messages" Content-Transfer-Encoding: 7Bit Content-Type: text/plain; charset="UTF-8"; name="messages" Sep 8 16:59:12 Insp6400 kernel: imklog 5.8.2, log source = /proc/kmsg started. Sep 8 16:59:12 Insp6400 rsyslogd: [origin software="rsyslogd" swVersion="5.8.2" x-pid="789" x-info="http://www.rsyslog.com"] start Sep 8 16:59:12 Insp6400 kernel: [ 0.000000] Initializing cgroup subsys cpuset Sep 8 16:59:12 Insp6400 kernel: [ 0.000000] Initializing cgroup subsys cpu Sep 8 16:59:12 Insp6400 kernel: [ 0.000000] Linux version 3.1.0-0.rc5.git0.0.fc17.x86_64 (mockbuild@x86-06.phx2.fedoraproject.org) (gcc version 4.6.1 20110804 (Red Hat 4.6.1-7) (GCC) ) #1 SMP Wed Sep 7 20:28:26 UTC 2011 Sep 8 16:59:12 Insp6400 kernel: [ 0.000000] Command line: ro root=/dev/mapper/vg_insp6400-lv_root SYSFONT=latarcyrheb-sun16 LANG=en_US.UTF-8 KEYTABLE=us xen-pciback.permissive xen-pciback.hide=(0b:00.0) Sep 8 16:59:12 Insp6400 kernel: [ 0.000000] released 0 pages of unused memory Sep 8 16:59:12 Insp6400 kernel: [ 0.000000] Set 526733 page(s) to 1-1 mapping. Sep 8 16:59:12 Insp6400 kernel: [ 0.000000] BIOS-provided physical RAM map: Sep 8 16:59:12 Insp6400 kernel: [ 0.000000] Xen: 0000000000000000 - 000000000009f000 (usable) Sep 8 16:59:12 Insp6400 kernel: [ 0.000000] Xen: 000000000009f000 - 0000000000100000 (reserved) Sep 8 16:59:12 Insp6400 kernel: [ 0.000000] Xen: 0000000000100000 - 0000000075fce000 (usable) Sep 8 16:59:12 Insp6400 kernel: [ 0.000000] Xen: 0000000075fce000 - 000000007f6d3000 (unusable) Sep 8 16:59:12 Insp6400 kernel: [ 0.000000] Xen: 000000007f6d3400 - 0000000080000000 (reserved) Sep 8 16:59:12 Insp6400 kernel: [ 0.000000] Xen: 00000000f0000000 - 00000000f4007000 (reserved) Sep 8 16:59:12 Insp6400 kernel: [ 0.000000] Xen: 00000000f4008000 - 00000000f400c000 (reserved) Sep 8 16:59:12 Insp6400 kernel: [ 0.000000] Xen: 00000000fec00000 - 00000000fec10000 (reserved) Sep 8 16:59:12 Insp6400 kernel: [ 0.000000] Xen: 00000000fed20000 - 00000000feda0000 (reserved) Sep 8 16:59:12 Insp6400 kernel: [ 0.000000] Xen: 00000000fee00000 - 00000000fee10000 (reserved) Sep 8 16:59:12 Insp6400 kernel: [ 0.000000] Xen: 00000000ffb00000 - 0000000100000000 (reserved) Sep 8 16:59:12 Insp6400 kernel: [ 0.000000] Xen: 0000000100000000 - 0000000109705000 (usable) Sep 8 16:59:12 Insp6400 kernel: [ 0.000000] NX (Execute Disable) protection: active Sep 8 16:59:12 Insp6400 kernel: [ 0.000000] DMI 2.4 present. Sep 8 16:59:12 Insp6400 kernel: [ 0.000000] No AGP bridge found Sep 8 16:59:12 Insp6400 kernel: [ 0.000000] last_pfn = 0x109705 max_arch_pfn = 0x400000000 Sep 8 16:59:12 Insp6400 kernel: [ 0.000000] last_pfn = 0x75fce max_arch_pfn = 0x400000000 Sep 8 16:59:12 Insp6400 kernel: [ 0.000000] init_memory_mapping: 0000000000000000-0000000075fce000 Sep 8 16:59:12 Insp6400 kernel: [ 0.000000] init_memory_mapping: 0000000100000000-0000000109705000 Sep 8 16:59:12 Insp6400 kernel: [ 0.000000] RAMDISK: 02ae5000 - 0533f000 Sep 8 16:59:12 Insp6400 kernel: [ 0.000000] ACPI: RSDP 00000000000fc1d0 00014 (v00 DELL ) Sep 8 16:59:12 Insp6400 kernel: [ 0.000000] ACPI: RSDT 000000007f6d3a0f 00040 (v01 DELL M07 27D7060D ASL 00000061) Sep 8 16:59:12 Insp6400 kernel: [ 0.000000] ACPI: FACP 000000007f6d4800 00074 (v01 DELL M07 27D7060D ASL 00000061) Sep 8 16:59:12 Insp6400 kernel: [ 0.000000] ACPI: DSDT 000000007f6d5400 04766 (v01 INT430 SYSFexxx 00001001 INTL 20050624) Sep 8 16:59:12 Insp6400 kernel: [ 0.000000] ACPI: FACS 000000007f6e3c00 00040 Sep 8 16:59:12 Insp6400 kernel: [ 0.000000] ACPI: HPET 000000007f6d4f00 00038 (v01 DELL M07 00000001 ASL 00000061) Sep 8 16:59:12 Insp6400 kernel: [ 0.000000] ACPI: APIC 000000007f6d5000 00068 (v01 DELL M07 27D7060D ASL 00000047) Sep 8 16:59:12 Insp6400 kernel: [ 0.000000] ACPI: MCFG 000000007f6d4fc0 0003E (v16 DELL M07 27D7060D ASL 00000061) Sep 8 16:59:12 Insp6400 kernel: [ 0.000000] ACPI: SLIC 000000007f6d509c 00176 (v01 DELL M07 27D7060D ASL 00000061) Sep 8 16:59:12 Insp6400 kernel: [ 0.000000] ACPI: BOOT 000000007f6d4bc0 00028 (v01 DELL M07 27D7060D ASL 00000061) Sep 8 16:59:12 Insp6400 kernel: [ 0.000000] ACPI: SSDT 000000007f6d3a4f 004DC (v01 PmRef CpuPm 00003000 INTL 20050624) Sep 8 16:59:12 Insp6400 kernel: [ 0.000000] No NUMA configuration found Sep 8 16:59:12 Insp6400 kernel: [ 0.000000] Faking a node at 0000000000000000-0000000109705000 Sep 8 16:59:12 Insp6400 kernel: [ 0.000000] Initmem setup node 0 0000000000000000-0000000109705000 Sep 8 16:59:10 Insp6400 avahi-daemon[755]: Found user 'avahi' (UID 498) and group 'avahi' (GID 491). Sep 8 16:59:10 Insp6400 avahi-daemon[755]: Successfully dropped root privileges. Sep 8 16:59:10 Insp6400 avahi-daemon[755]: avahi-daemon 0.6.30 starting up. Sep 8 16:59:10 Insp6400 avahi-daemon[755]: WARNING: No NSS support for mDNS detected, consider installing nss-mdns! Sep 8 16:59:12 Insp6400 kernel: [ 0.000000] NODE_DATA [0000000075fb9000 - 0000000075fcdfff] Sep 8 16:59:12 Insp6400 kernel: [ 0.000000] Zone PFN ranges: Sep 8 16:59:12 Insp6400 kernel: [ 0.000000] DMA 0x00000010 -> 0x00001000 Sep 8 16:59:12 Insp6400 kernel: [ 0.000000] DMA32 0x00001000 -> 0x00100000 Sep 8 16:59:12 Insp6400 kernel: [ 0.000000] Normal 0x00100000 -> 0x00109705 Sep 8 16:59:12 Insp6400 kernel: [ 0.000000] Movable zone start PFN for each node Sep 8 16:59:12 Insp6400 kernel: [ 0.000000] early_node_map[3] active PFN ranges Sep 8 16:59:12 Insp6400 kernel: [ 0.000000] 0: 0x00000010 -> 0x0000009f Sep 8 16:59:12 Insp6400 kernel: [ 0.000000] 0: 0x00000100 -> 0x00075fce Sep 8 16:59:12 Insp6400 kernel: [ 0.000000] 0: 0x00100000 -> 0x00109705 Sep 8 16:59:12 Insp6400 kernel: [ 0.000000] ACPI: PM-Timer IO Port: 0x1008 Sep 8 16:59:12 Insp6400 kernel: [ 0.000000] ACPI: LAPIC (acpi_id[0x00] lapic_id[0x00] enabled) Sep 8 16:59:12 Insp6400 kernel: [ 0.000000] BIOS bug: APIC version is 0 for CPU 0/0x0, fixing up to 0x10 Sep 8 16:59:12 Insp6400 kernel: [ 0.000000] ACPI: LAPIC (acpi_id[0x01] lapic_id[0x01] enabled) Sep 8 16:59:12 Insp6400 kernel: [ 0.000000] ACPI: LAPIC_NMI (acpi_id[0x00] high edge lint[0x1]) Sep 8 16:59:12 Insp6400 kernel: [ 0.000000] ACPI: LAPIC_NMI (acpi_id[0x01] high edge lint[0x1]) Sep 8 16:59:12 Insp6400 kernel: [ 0.000000] ACPI: IOAPIC (id[0x02] address[0xfec00000] gsi_base[0]) Sep 8 16:59:12 Insp6400 kernel: [ 0.000000] IOAPIC[0]: apic_id 2, version 255, address 0xfec00000, GSI 0-255 Sep 8 16:59:12 Insp6400 kernel: [ 0.000000] ACPI: INT_SRC_OVR (bus 0 bus_irq 0 global_irq 2 dfl dfl) Sep 8 16:59:12 Insp6400 kernel: [ 0.000000] ACPI: INT_SRC_OVR (bus 0 bus_irq 9 global_irq 9 high level) Sep 8 16:59:12 Insp6400 kernel: [ 0.000000] Using ACPI (MADT) for SMP configuration information Sep 8 16:59:12 Insp6400 kernel: [ 0.000000] ACPI: HPET id: 0x8086a201 base: 0xfed00000 Sep 8 16:59:12 Insp6400 kernel: [ 0.000000] SMP: Allowing 2 CPUs, 0 hotplug CPUs Sep 8 16:59:12 Insp6400 kernel: [ 0.000000] PM: Registered nosave memory: 000000000009f000 - 0000000000100000 Sep 8 16:59:12 Insp6400 kernel: [ 0.000000] PM: Registered nosave memory: 0000000075fce000 - 000000007f6d3000 Sep 8 16:59:12 Insp6400 kernel: [ 0.000000] PM: Registered nosave memory: 000000007f6d3000 - 000000007f6d4000 Sep 8 16:59:12 Insp6400 kernel: [ 0.000000] PM: Registered nosave memory: 000000007f6d4000 - 0000000080000000 Sep 8 16:59:12 Insp6400 kernel: [ 0.000000] PM: Registered nosave memory: 0000000080000000 - 00000000f0000000 Sep 8 16:59:12 Insp6400 kernel: [ 0.000000] PM: Registered nosave memory: 00000000f0000000 - 00000000f4007000 Sep 8 16:59:12 Insp6400 kernel: [ 0.000000] PM: Registered nosave memory: 00000000f4007000 - 00000000f4008000 Sep 8 16:59:12 Insp6400 kernel: [ 0.000000] PM: Registered nosave memory: 00000000f4008000 - 00000000f400c000 Sep 8 16:59:12 Insp6400 kernel: [ 0.000000] PM: Registered nosave memory: 00000000f400c000 - 00000000fec00000 Sep 8 16:59:12 Insp6400 kernel: [ 0.000000] PM: Registered nosave memory: 00000000fec00000 - 00000000fec10000 Sep 8 16:59:12 Insp6400 kernel: [ 0.000000] PM: Registered nosave memory: 00000000fec10000 - 00000000fed20000 Sep 8 16:59:12 Insp6400 kernel: [ 0.000000] PM: Registered nosave memory: 00000000fed20000 - 00000000feda0000 Sep 8 16:59:12 Insp6400 kernel: [ 0.000000] PM: Registered nosave memory: 00000000feda0000 - 00000000fee00000 Sep 8 16:59:12 Insp6400 kernel: [ 0.000000] PM: Registered nosave memory: 00000000fee00000 - 00000000fee10000 Sep 8 16:59:12 Insp6400 kernel: [ 0.000000] PM: Registered nosave memory: 00000000fee10000 - 00000000ffb00000 Sep 8 16:59:12 Insp6400 kernel: [ 0.000000] PM: Registered nosave memory: 00000000ffb00000 - 0000000100000000 Sep 8 16:59:12 Insp6400 kernel: [ 0.000000] Allocating PCI resources starting at 80000000 (gap: 80000000:70000000) Sep 8 16:59:12 Insp6400 kernel: [ 0.000000] Booting paravirtualized kernel on Xen Sep 8 16:59:12 Insp6400 kernel: [ 0.000000] Xen version: 4.1.1 (preserve-AD) Sep 8 16:59:12 Insp6400 kernel: [ 0.000000] setup_percpu: NR_CPUS:512 nr_cpumask_bits:512 nr_cpu_ids:2 nr_node_ids:1 Sep 8 16:59:12 Insp6400 kernel: [ 0.000000] PERCPU: Embedded 476 pages/cpu @ffff88007575b000 s1918464 r8192 d23040 u1949696 Sep 8 16:59:12 Insp6400 kernel: [ 0.000000] Built 1 zonelists in Node order, mobility grouping on. Total pages: 504832 Sep 8 16:59:12 Insp6400 kernel: [ 0.000000] Policy zone: Normal Sep 8 16:59:12 Insp6400 kernel: [ 0.000000] Kernel command line: ro root=/dev/mapper/vg_insp6400-lv_root SYSFONT=latarcyrheb-sun16 LANG=en_US.UTF-8 KEYTABLE=us xen-pciback.permissive xen-pciback.hide=(0b:00.0) Sep 8 16:59:12 Insp6400 kernel: [ 0.000000] PID hash table entries: 4096 (order: 3, 32768 bytes) Sep 8 16:59:12 Insp6400 kernel: [ 0.000000] Placing 64MB software IO TLB between ffff88006f000000 - ffff880073000000 Sep 8 16:59:12 Insp6400 kernel: [ 0.000000] software IO TLB at phys 0x6f000000 - 0x73000000 Sep 8 16:59:12 Insp6400 kernel: [ 0.000000] Memory: 1751204k/4348948k available (5185k kernel code, 2261644k absent, 336100k reserved, 6577k data, 2780k init) Sep 8 16:59:12 Insp6400 kernel: [ 0.000000] SLUB: Genslabs=15, HWalign=64, Order=0-3, MinObjects=0, CPUs=2, Nodes=1 Sep 8 16:59:12 Insp6400 kernel: [ 0.000000] Hierarchical RCU implementation. Sep 8 16:59:12 Insp6400 kernel: [ 0.000000] RCU dyntick-idle grace-period acceleration is enabled. Sep 8 16:59:12 Insp6400 kernel: [ 0.000000] RCU lockdep checking is enabled. Sep 8 16:59:12 Insp6400 kernel: [ 0.000000] NR_IRQS:33024 nr_irqs:512 16 Sep 8 16:59:12 Insp6400 kernel: [ 0.000000] xen: sci override: global_irq=9 trigger=0 polarity=0 Sep 8 16:59:12 Insp6400 kernel: [ 0.000000] xen: acpi sci 9 Sep 8 16:59:12 Insp6400 kernel: [ 0.000000] xen_map_pirq_gsi: returning irq 9 for gsi 9 Sep 8 16:59:12 Insp6400 kernel: [ 0.000000] Console: colour VGA+ 80x25 Sep 8 16:59:12 Insp6400 kernel: [ 0.000000] console [tty0] enabled Sep 8 16:59:12 Insp6400 kernel: [ 0.000000] Lock dependency validator: Copyright (c) 2006 Red Hat, Inc., Ingo Molnar Sep 8 16:59:12 Insp6400 kernel: [ 0.000000] ... MAX_LOCKDEP_SUBCLASSES: 8 Sep 8 16:59:12 Insp6400 kernel: [ 0.000000] ... MAX_LOCK_DEPTH: 48 Sep 8 16:59:12 Insp6400 kernel: [ 0.000000] ... MAX_LOCKDEP_KEYS: 8191 Sep 8 16:59:12 Insp6400 kernel: [ 0.000000] ... CLASSHASH_SIZE: 4096 Sep 8 16:59:12 Insp6400 kernel: [ 0.000000] ... MAX_LOCKDEP_ENTRIES: 16384 Sep 8 16:59:12 Insp6400 kernel: [ 0.000000] ... MAX_LOCKDEP_CHAINS: 32768 Sep 8 16:59:12 Insp6400 kernel: [ 0.000000] ... CHAINHASH_SIZE: 16384 Sep 8 16:59:12 Insp6400 kernel: [ 0.000000] memory used by lock dependency info: 6367 kB Sep 8 16:59:12 Insp6400 kernel: [ 0.000000] per task-struct memory footprint: 2688 bytes Sep 8 16:59:12 Insp6400 kernel: [ 0.000000] allocated 17825792 bytes of page_cgroup Sep 8 16:59:12 Insp6400 kernel: [ 0.000000] please try 'cgroup_disable=memory' option if you don't want memory cgroups Sep 8 16:59:12 Insp6400 kernel: [ 0.000000] installing Xen timer for CPU 0 Sep 8 16:59:12 Insp6400 kernel: [ 0.000000] Detected 1828.796 MHz processor. Sep 8 16:59:12 Insp6400 kernel: [ 0.000999] Calibrating delay loop (skipped), value calculated using timer frequency.. 3657.59 BogoMIPS (lpj=1828796) Sep 8 16:59:12 Insp6400 kernel: [ 0.000999] pid_max: default: 32768 minimum: 301 Sep 8 16:59:12 Insp6400 kernel: [ 0.000999] Security Framework initialized Sep 8 16:59:12 Insp6400 kernel: [ 0.000999] SELinux: Initializing. Sep 8 16:59:12 Insp6400 kernel: [ 0.002648] Dentry cache hash table entries: 262144 (order: 9, 2097152 bytes) Sep 8 16:59:12 Insp6400 kernel: [ 0.005103] Inode-cache hash table entries: 131072 (order: 8, 1048576 bytes) Sep 8 16:59:12 Insp6400 kernel: [ 0.005999] Mount-cache hash table entries: 256 Sep 8 16:59:12 Insp6400 kernel: [ 0.009803] Initializing cgroup subsys cpuacct Sep 8 16:59:12 Insp6400 kernel: [ 0.009974] Initializing cgroup subsys memory Sep 8 16:59:12 Insp6400 kernel: [ 0.010283] Initializing cgroup subsys devices Sep 8 16:59:12 Insp6400 kernel: [ 0.010428] Initializing cgroup subsys freezer Sep 8 16:59:12 Insp6400 kernel: [ 0.010561] Initializing cgroup subsys net_cls Sep 8 16:59:12 Insp6400 kernel: [ 0.010696] Initializing cgroup subsys blkio Sep 8 16:59:12 Insp6400 kernel: [ 0.010979] Initializing cgroup subsys perf_event Sep 8 16:59:12 Insp6400 kernel: [ 0.011518] CPU: Physical Processor ID: 0 Sep 8 16:59:12 Insp6400 kernel: [ 0.011639] CPU: Processor Core ID: 0 Sep 8 16:59:12 Insp6400 kernel: [ 0.012814] ACPI: Core revision 20110623 Sep 8 16:59:12 Insp6400 kernel: [ 0.072895] ftrace: allocating 25821 entries in 102 pages Sep 8 16:59:12 Insp6400 kernel: [ 0.075083] Performance Events: unsupported p6 CPU model 15 no PMU driver, software events only. Sep 8 16:59:12 Insp6400 kernel: [ 0.076993] NMI watchdog disabled (cpu0): hardware events not enabled Sep 8 16:59:12 Insp6400 kernel: [ 0.078517] installing Xen timer for CPU 1 Sep 8 16:59:12 Insp6400 kernel: [ 0.078827] lockdep: fixing up alternatives. Sep 8 16:59:12 Insp6400 kernel: [ 0.079572] NMI watchdog disabled (cpu1): hardware events not enabled Sep 8 16:59:12 Insp6400 kernel: [ 0.079944] Brought up 2 CPUs Sep 8 16:59:12 Insp6400 kernel: [ 0.083384] devtmpfs: initialized Sep 8 16:59:12 Insp6400 kernel: [ 0.098213] atomic64 test passed for x86-64 platform with CX8 and with SSE Sep 8 16:59:12 Insp6400 kernel: [ 0.098681] Grant table initialized Sep 8 16:59:12 Insp6400 kernel: [ 0.098839] RTC time: 20:58:03, date: 09/08/11 Sep 8 16:59:12 Insp6400 kernel: [ 0.099810] NET: Registered protocol family 16 Sep 8 16:59:12 Insp6400 kernel: [ 0.106273] ACPI: bus type pci registered Sep 8 16:59:12 Insp6400 kernel: [ 0.107787] PCI: MMCONFIG for domain 0000 [bus 00-3f] at [mem 0xf0000000-0xf3ffffff] (base 0xf0000000) Sep 8 16:59:12 Insp6400 kernel: [ 0.107988] PCI: MMCONFIG at [mem 0xf0000000-0xf3ffffff] reserved in E820 Sep 8 16:59:12 Insp6400 kernel: [ 0.131441] PCI: Using configuration type 1 for base access Sep 8 16:59:12 Insp6400 kernel: [ 0.131566] dmi type 0xB1 record - unknown flag Sep 8 16:59:12 Insp6400 kernel: [ 0.156193] bio: create slab at 0 Sep 8 16:59:12 Insp6400 kernel: [ 0.157763] ACPI: Added _OSI(Module Device) Sep 8 16:59:12 Insp6400 kernel: [ 0.157905] ACPI: Added _OSI(Processor Device) Sep 8 16:59:12 Insp6400 kernel: [ 0.157984] ACPI: Added _OSI(3.0 _SCP Extensions) Sep 8 16:59:12 Insp6400 kernel: [ 0.157984] ACPI: Added _OSI(Processor Aggregator Device) Sep 8 16:59:12 Insp6400 kernel: [ 0.198978] ACPI: SSDT 000000007f6d4176 00202 (v01 PmRef Cpu0Ist 00003000 INTL 20050624) Sep 8 16:59:12 Insp6400 kernel: [ 0.198978] ACPI: Dynamic OEM Table Load: Sep 8 16:59:12 Insp6400 kernel: [ 0.198978] ACPI: SSDT (null) 00202 (v01 PmRef Cpu0Ist 00003000 INTL 20050624) Sep 8 16:59:12 Insp6400 kernel: [ 0.198978] ACPI: SSDT 000000007f6d3f2b 001C6 (v01 PmRef Cpu0Cst 00003001 INTL 20050624) Sep 8 16:59:12 Insp6400 kernel: [ 0.198978] ACPI: Dynamic OEM Table Load: Sep 8 16:59:12 Insp6400 kernel: [ 0.198978] ACPI: SSDT (null) 001C6 (v01 PmRef Cpu0Cst 00003001 INTL 20050624) Sep 8 16:59:12 Insp6400 kernel: [ 0.198978] ACPI: SSDT 000000007f6d4378 000C4 (v01 PmRef Cpu1Ist 00003000 INTL 20050624) Sep 8 16:59:12 Insp6400 kernel: [ 0.198978] ACPI: Dynamic OEM Table Load: Sep 8 16:59:12 Insp6400 kernel: [ 0.198978] ACPI: SSDT (null) 000C4 (v01 PmRef Cpu1Ist 00003000 INTL 20050624) Sep 8 16:59:12 Insp6400 kernel: [ 0.200036] ACPI: SSDT 000000007f6d40f1 00085 (v01 PmRef Cpu1Cst 00003000 INTL 20050624) Sep 8 16:59:12 Insp6400 kernel: [ 0.200978] ACPI: Dynamic OEM Table Load: Sep 8 16:59:12 Insp6400 kernel: [ 0.200978] ACPI: SSDT (null) 00085 (v01 PmRef Cpu1Cst 00003000 INTL 20050624) Sep 8 16:59:12 Insp6400 kernel: [ 0.200978] ACPI: Interpreter enabled Sep 8 16:59:12 Insp6400 kernel: [ 0.200978] ACPI: (supports S0 S3 S4 S5) Sep 8 16:59:12 Insp6400 kernel: [ 0.200978] ACPI: Using IOAPIC for interrupt routing Sep 8 16:59:12 Insp6400 kernel: [ 0.482935] ACPI: No dock devices found. Sep 8 16:59:12 Insp6400 kernel: [ 0.482935] HEST: Table not found. Sep 8 16:59:12 Insp6400 kernel: [ 0.482935] PCI: Ignoring host bridge windows from ACPI; if necessary, use "pci=use_crs" and report a bug Sep 8 16:59:12 Insp6400 kernel: [ 0.503932] ACPI: PCI Root Bridge [PCI0] (domain 0000 [bus 00-ff]) Sep 8 16:59:12 Insp6400 kernel: [ 0.553924] pci 0000:00:1f.0: quirk: [io 0x1000-0x107f] claimed by ICH6 ACPI/GPIO/TCO Sep 8 16:59:12 Insp6400 kernel: [ 0.553924] pci 0000:00:1f.0: quirk: [io 0x1080-0x10bf] claimed by ICH6 GPIO Sep 8 16:59:12 Insp6400 kernel: [ 0.553924] pci 0000:00:1f.0: ICH7 LPC Generic IO decode 1 PIO at 0900 (mask 007f) Sep 8 16:59:12 Insp6400 kernel: [ 0.553924] pci 0000:00:1f.0: ICH7 LPC Generic IO decode 3 PIO at 0c80 (mask 003f) Sep 8 16:59:12 Insp6400 kernel: [ 0.556351] pci 0000:0b:00.0: disabling ASPM on pre-1.1 PCIe device. You can enable it with 'pcie_aspm=force' Sep 8 16:59:12 Insp6400 kernel: [ 0.556718] pci 0000:00:1c.0: PCI bridge to [bus 0b-0b] Sep 8 16:59:12 Insp6400 kernel: [ 0.557827] pci 0000:00:1c.3: PCI bridge to [bus 0c-0d] Sep 8 16:59:12 Insp6400 kernel: [ 0.560923] pci 0000:00:1e.0: PCI bridge to [bus 03-03] (subtractive decode) Sep 8 16:59:12 Insp6400 kernel: [ 0.560923] pci 0000:00:1c.0: Dev MPS 128 MPSS 128 MRRS 128 Sep 8 16:59:12 Insp6400 kernel: [ 0.560923] pci 0000:00:1c.0: Dev MPS 128 MPSS 128 MRRS 128 Sep 8 16:59:12 Insp6400 kernel: [ 0.560923] pci 0000:0b:00.0: Dev MPS 128 MPSS 128 MRRS 128 Sep 8 16:59:12 Insp6400 kernel: [ 0.560923] pci 0000:0b:00.0: Dev MPS 128 MPSS 128 MRRS 128 Sep 8 16:59:12 Insp6400 kernel: [ 0.560923] pci 0000:00:1c.3: Dev MPS 128 MPSS 128 MRRS 128 Sep 8 16:59:12 Insp6400 kernel: [ 0.560923] pci 0000:00:1c.3: Dev MPS 128 MPSS 128 MRRS 128 Sep 8 16:59:12 Insp6400 kernel: [ 0.560923] pci 0000:0c:00.0: Dev MPS 128 MPSS 128 MRRS 512 Sep 8 16:59:12 Insp6400 kernel: [ 0.560923] pci 0000:0c:00.0: Dev MPS 128 MPSS 128 MRRS 128 Sep 8 16:59:12 Insp6400 kernel: [ 0.563923] pci0000:00: Requesting ACPI _OSC control (0x1d) Sep 8 16:59:12 Insp6400 kernel: [ 0.563923] pci0000:00: ACPI _OSC request failed (AE_NOT_FOUND), returned control mask: 0x1d Sep 8 16:59:12 Insp6400 kernel: [ 0.563923] ACPI _OSC control for PCIe not granted, disabling ASPM Sep 8 16:59:12 Insp6400 kernel: [ 0.596918] ACPI: PCI Interrupt Link [LNKA] (IRQs 9 10 *11) Sep 8 16:59:12 Insp6400 kernel: [ 0.597918] ACPI: PCI Interrupt Link [LNKB] (IRQs 5 7) *4 Sep 8 16:59:12 Insp6400 kernel: [ 0.598917] ACPI: PCI Interrupt Link [LNKC] (IRQs 9 10 *11) Sep 8 16:59:12 Insp6400 kernel: [ 0.599917] ACPI: PCI Interrupt Link [LNKD] (IRQs 5 7 9 10 11) *3 Sep 8 16:59:12 Insp6400 kernel: [ 0.601917] ACPI: PCI Interrupt Link [LNKE] (IRQs 3 4 5 6 7 *9 10 11 12 14 15) Sep 8 16:59:12 Insp6400 kernel: [ 0.602917] ACPI: PCI Interrupt Link [LNKF] (IRQs 3 4 5 6 7 9 *10 11 12 14 15) Sep 8 16:59:12 Insp6400 kernel: [ 0.603917] ACPI: PCI Interrupt Link [LNKG] (IRQs 3 4 5 6 *7 9 10 11 12 14 15) Sep 8 16:59:12 Insp6400 kernel: [ 0.604917] ACPI: PCI Interrupt Link [LNKH] (IRQs 3 4 *5 6 7 9 10 11 12 14 15) Sep 8 16:59:12 Insp6400 kernel: [ 0.605055] xen/balloon: Initialising balloon driver. Sep 8 16:59:12 Insp6400 kernel: [ 0.605209] last_pfn = 0x109705 max_arch_pfn = 0x400000000 Sep 8 16:59:12 Insp6400 kernel: [ 0.607009] xen-balloon: Initialising balloon driver. Sep 8 16:59:12 Insp6400 kernel: [ 0.607682] xen/balloon: Xen selfballooning driver disabled for domain0. Sep 8 16:59:12 Insp6400 kernel: [ 0.608752] vgaarb: device added: PCI:0000:00:02.0,decodes=io+mem,owns=io+mem,locks=none Sep 8 16:59:12 Insp6400 kernel: [ 0.608916] vgaarb: loaded Sep 8 16:59:12 Insp6400 kernel: [ 0.608916] vgaarb: bridge control possible 0000:00:02.0 Sep 8 16:59:12 Insp6400 kernel: [ 0.611750] SCSI subsystem initialized Sep 8 16:59:12 Insp6400 kernel: [ 0.613519] usbcore: registered new interface driver usbfs Sep 8 16:59:12 Insp6400 kernel: [ 0.613915] usbcore: registered new interface driver hub Sep 8 16:59:12 Insp6400 kernel: [ 0.614163] usbcore: registered new device driver usb Sep 8 16:59:12 Insp6400 kernel: [ 0.615756] PCI: Using ACPI for IRQ routing Sep 8 16:59:12 Insp6400 kernel: [ 0.618444] NetLabel: Initializing Sep 8 16:59:12 Insp6400 kernel: [ 0.618560] NetLabel: domain hash size = 128 Sep 8 16:59:12 Insp6400 kernel: [ 0.618677] NetLabel: protocols = UNLABELED CIPSOv4 Sep 8 16:59:12 Insp6400 kernel: [ 0.618914] NetLabel: unlabeled traffic allowed by default Sep 8 16:59:12 Insp6400 kernel: [ 0.618914] Switching to clocksource xen Sep 8 16:59:12 Insp6400 kernel: [ 0.619312] Switched to NOHz mode on CPU #1 Sep 8 16:59:12 Insp6400 kernel: [ 0.620099] Switched to NOHz mode on CPU #0 Sep 8 16:59:12 Insp6400 kernel: [ 0.989037] pnp: PnP ACPI init Sep 8 16:59:12 Insp6400 kernel: [ 0.989190] ACPI: bus type pnp registered Sep 8 16:59:12 Insp6400 kernel: [ 1.456722] system 00:00: [mem 0x00000000-0x0009fbff] could not be reserved Sep 8 16:59:12 Insp6400 kernel: [ 1.456898] system 00:00: [mem 0x0009fc00-0x0009ffff] could not be reserved Sep 8 16:59:12 Insp6400 kernel: [ 1.457013] system 00:00: [mem 0x000c0000-0x000cffff] could not be reserved Sep 8 16:59:12 Insp6400 kernel: [ 1.457013] system 00:00: [mem 0x000e0000-0x000fffff] could not be reserved Sep 8 16:59:12 Insp6400 kernel: [ 1.457013] system 00:00: [mem 0x00100000-0x7f6d33ff] could not be reserved Sep 8 16:59:12 Insp6400 kernel: [ 1.457013] system 00:00: [mem 0x7f6d3400-0x7f6fffff] has been reserved Sep 8 16:59:12 Insp6400 kernel: [ 1.457013] system 00:00: [mem 0x7f700000-0x7f7fffff] has been reserved Sep 8 16:59:12 Insp6400 kernel: [ 1.457013] system 00:00: [mem 0x7f700000-0x7fefffff] could not be reserved Sep 8 16:59:12 Insp6400 kernel: [ 1.457013] system 00:00: [mem 0xffb00000-0xffffffff] has been reserved Sep 8 16:59:12 Insp6400 kernel: [ 1.457013] system 00:00: [mem 0xfec00000-0xfec0ffff] could not be reserved Sep 8 16:59:12 Insp6400 kernel: [ 1.457013] system 00:00: [mem 0xfee00000-0xfee0ffff] has been reserved Sep 8 16:59:12 Insp6400 kernel: [ 1.457013] system 00:00: [mem 0xfed20000-0xfed9ffff] has been reserved Sep 8 16:59:12 Insp6400 kernel: [ 1.457013] system 00:00: [mem 0xffa80000-0xffa83fff] could not be reserved Sep 8 16:59:12 Insp6400 kernel: [ 1.457013] system 00:00: [mem 0xf4000000-0xf4003fff] has been reserved Sep 8 16:59:12 Insp6400 kernel: [ 1.457013] system 00:00: [mem 0xf4004000-0xf4004fff] has been reserved Sep 8 16:59:12 Insp6400 kernel: [ 1.459154] system 00:00: [mem 0xf4005000-0xf4005fff] has been reserved Sep 8 16:59:12 Insp6400 kernel: [ 1.459308] system 00:00: [mem 0xf4006000-0xf4006fff] has been reserved Sep 8 16:59:12 Insp6400 kernel: [ 1.459460] system 00:00: [mem 0xf4008000-0xf400bfff] has been reserved Sep 8 16:59:12 Insp6400 kernel: [ 1.459612] system 00:00: [mem 0xf0000000-0xf3ffffff] has been reserved Sep 8 16:59:12 Insp6400 kernel: [ 1.807294] pnp 00:02: disabling [io 0x1000-0x1005] because it overlaps 0000:00:1f.0 BAR 13 [io 0x1000-0x107f] Sep 8 16:59:12 Insp6400 kernel: [ 1.807294] pnp 00:02: disabling [io 0x1008-0x100f] because it overlaps 0000:00:1f.0 BAR 13 [io 0x1000-0x107f] Sep 8 16:59:12 Insp6400 kernel: [ 1.808907] system 00:02: [io 0x04d0-0x04d1] has been reserved Sep 8 16:59:12 Insp6400 kernel: [ 1.810282] pnp 00:03: disabling [io 0x1006-0x1007] because it overlaps 0000:00:1f.0 BAR 13 [io 0x1000-0x107f] Sep 8 16:59:12 Insp6400 kernel: [ 1.810485] pnp 00:03: disabling [io 0x100a-0x1059] because it overlaps 0000:00:1f.0 BAR 13 [io 0x1000-0x107f] Sep 8 16:59:12 Insp6400 kernel: [ 1.810687] pnp 00:03: disabling [io 0x1060-0x107f] because it overlaps 0000:00:1f.0 BAR 13 [io 0x1000-0x107f] Sep 8 16:59:12 Insp6400 kernel: [ 1.810888] pnp 00:03: disabling [io 0x1010-0x102f] because it overlaps 0000:00:1f.0 BAR 13 [io 0x1000-0x107f] Sep 8 16:59:12 Insp6400 kernel: [ 1.812279] system 00:03: [io 0xf400-0xf4fe] has been reserved Sep 8 16:59:12 Insp6400 kernel: [ 1.812427] system 00:03: [io 0x1080-0x10bf] has been reserved Sep 8 16:59:12 Insp6400 kernel: [ 1.812573] system 00:03: [io 0x10c0-0x10df] has been reserved Sep 8 16:59:12 Insp6400 kernel: [ 1.812720] system 00:03: [io 0x0809] has been reserved Sep 8 16:59:12 Insp6400 kernel: [ 1.813570] xen_map_pirq_gsi: returning irq 12 for gsi 12 Sep 8 16:59:12 Insp6400 kernel: [ 1.815255] xen_map_pirq_gsi: returning irq 1 for gsi 1 Sep 8 16:59:12 Insp6400 kernel: [ 1.816800] xen_map_pirq_gsi: returning irq 8 for gsi 8 Sep 8 16:59:12 Insp6400 kernel: [ 1.821590] system 00:08: [io 0x0c80-0x0cff] could not be reserved Sep 8 16:59:12 Insp6400 kernel: [ 1.821740] system 00:08: [io 0x0910-0x091f] has been reserved Sep 8 16:59:12 Insp6400 kernel: [ 1.821886] system 00:08: [io 0x0920-0x092f] has been reserved Sep 8 16:59:12 Insp6400 kernel: [ 1.822034] system 00:08: [io 0x0cb0-0x0cbf] has been reserved Sep 8 16:59:12 Insp6400 kernel: [ 1.822220] system 00:08: [io 0x0930-0x097f] has been reserved Sep 8 16:59:12 Insp6400 kernel: [ 1.824669] xen_map_pirq_gsi: returning irq 13 for gsi 13 Sep 8 16:59:12 Insp6400 kernel: [ 1.829472] system 00:0b: [mem 0xfed00000-0xfed003ff] has been reserved Sep 8 16:59:12 Insp6400 kernel: [ 1.830351] pnp: PnP ACPI: found 12 devices Sep 8 16:59:12 Insp6400 kernel: [ 1.830351] ACPI: ACPI bus type pnp unregistered Sep 8 16:59:12 Insp6400 kernel: [ 1.917290] PM-Timer failed consistency check (0x0xffffff) - aborting. Sep 8 16:59:12 Insp6400 kernel: [ 1.918064] pci 0000:00:1c.0: BAR 15: assigned [mem 0x80000000-0x801fffff 64bit pref] Sep 8 16:59:12 Insp6400 kernel: [ 1.918064] pci 0000:00:1c.0: BAR 13: assigned [io 0x2000-0x2fff] Sep 8 16:59:12 Insp6400 kernel: [ 1.918064] pci 0000:00:1c.0: PCI bridge to [bus 0b-0b] Sep 8 16:59:12 Insp6400 kernel: [ 1.918064] pci 0000:00:1c.0: bridge window [io 0x2000-0x2fff] Sep 8 16:59:12 Insp6400 kernel: [ 1.918064] pci 0000:00:1c.0: bridge window [mem 0xefd00000-0xefdfffff] Sep 8 16:59:12 Insp6400 kernel: [ 1.918064] pci 0000:00:1c.0: bridge window [mem 0x80000000-0x801fffff 64bit pref] Sep 8 16:59:12 Insp6400 kernel: [ 1.918064] pci 0000:00:1c.3: PCI bridge to [bus 0c-0d] Sep 8 16:59:12 Insp6400 kernel: [ 1.918064] pci 0000:00:1c.3: bridge window [io 0xd000-0xdfff] Sep 8 16:59:12 Insp6400 kernel: [ 1.918064] pci 0000:00:1c.3: bridge window [mem 0xefb00000-0xefcfffff] Sep 8 16:59:12 Insp6400 kernel: [ 1.918064] pci 0000:00:1c.3: bridge window [mem 0xe0000000-0xe01fffff 64bit pref] Sep 8 16:59:12 Insp6400 kernel: [ 1.918064] pci 0000:00:1e.0: PCI bridge to [bus 03-03] Sep 8 16:59:12 Insp6400 kernel: [ 1.918064] pci 0000:00:1e.0: bridge window [mem 0xefa00000-0xefafffff] Sep 8 16:59:12 Insp6400 kernel: [ 1.920218] pci 0000:00:1c.0: PCI INT A -> GSI 16 (level, low) -> IRQ 16 Sep 8 16:59:12 Insp6400 kernel: [ 1.920458] pci 0000:00:1c.3: PCI INT D -> GSI 19 (level, low) -> IRQ 19 Sep 8 16:59:12 Insp6400 kernel: [ 1.921279] NET: Registered protocol family 2 Sep 8 16:59:12 Insp6400 kernel: [ 1.923153] IP route cache hash table entries: 65536 (order: 7, 524288 bytes) Sep 8 16:59:12 Insp6400 kernel: [ 1.931845] TCP established hash table entries: 262144 (order: 10, 4194304 bytes) Sep 8 16:59:12 Insp6400 kernel: [ 1.940386] TCP bind hash table entries: 65536 (order: 10, 5242880 bytes) Sep 8 16:59:12 Insp6400 kernel: [ 1.954064] TCP: Hash tables configured (established 262144 bind 65536) Sep 8 16:59:12 Insp6400 kernel: [ 1.954064] TCP reno registered Sep 8 16:59:12 Insp6400 kernel: [ 1.956489] UDP hash table entries: 1024 (order: 5, 196608 bytes) Sep 8 16:59:12 Insp6400 kernel: [ 1.957465] UDP-Lite hash table entries: 1024 (order: 5, 196608 bytes) Sep 8 16:59:12 Insp6400 kernel: [ 1.959559] NET: Registered protocol family 1 Sep 8 16:59:12 Insp6400 kernel: [ 1.962217] Unpacking initramfs... Sep 8 16:59:12 Insp6400 kernel: [ 2.873066] Freeing initrd memory: 41320k freed Sep 8 16:59:12 Insp6400 kernel: [ 3.259725] DMA-API: preallocated 32768 debug entries Sep 8 16:59:12 Insp6400 kernel: [ 3.259856] DMA-API: debugging enabled by kernel config Sep 8 16:59:12 Insp6400 kernel: [ 3.260062] Simple Boot Flag at 0x79 set to 0x80 Sep 8 16:59:12 Insp6400 kernel: [ 3.271644] Intel AES-NI instructions are not detected. Sep 8 16:59:12 Insp6400 kernel: [ 3.271653] cryptomgr_test used greatest stack depth: 6088 bytes left Sep 8 16:59:12 Insp6400 kernel: [ 3.274831] audit: initializing netlink socket (disabled) Sep 8 16:59:12 Insp6400 kernel: [ 3.275128] type=2000 audit(1315515487.194:1): initialized Sep 8 16:59:12 Insp6400 kernel: [ 3.311148] HugeTLB registered 2 MB page size, pre-allocated 0 pages Sep 8 16:59:12 Insp6400 kernel: [ 3.397870] VFS: Disk quotas dquot_6.5.2 Sep 8 16:59:12 Insp6400 kernel: [ 3.399100] Dquot-cache hash table entries: 512 (order 0, 4096 bytes) Sep 8 16:59:12 Insp6400 kernel: [ 3.413418] msgmni has been set to 3501 Sep 8 16:59:12 Insp6400 kernel: [ 3.420261] cryptomgr_test used greatest stack depth: 5512 bytes left Sep 8 16:59:12 Insp6400 kernel: [ 3.422194] cryptomgr_test used greatest stack depth: 5448 bytes left Sep 8 16:59:12 Insp6400 kernel: [ 3.422470] alg: No test for stdrng (krng) Sep 8 16:59:12 Insp6400 kernel: [ 3.422652] NET: Registered protocol family 38 Sep 8 16:59:12 Insp6400 kernel: [ 3.423923] Block layer SCSI generic (bsg) driver version 0.4 loaded (major 253) Sep 8 16:59:12 Insp6400 kernel: [ 3.424491] io scheduler noop registered Sep 8 16:59:12 Insp6400 kernel: [ 3.424610] io scheduler deadline registered Sep 8 16:59:12 Insp6400 kernel: [ 3.426320] io scheduler cfq registered (default) Sep 8 16:59:12 Insp6400 kernel: [ 3.426438] start plist test Sep 8 16:59:12 Insp6400 kernel: [ 3.427727] end plist test Sep 8 16:59:12 Insp6400 kernel: [ 3.443402] BUG: scheduling while atomic: swapper/1/0x10000002 Sep 8 16:59:12 Insp6400 kernel: [ 3.443521] 3 locks held by swapper/1: Sep 8 16:59:12 Insp6400 kernel: [ 3.443632] #0: (&__lockdep_no_validate__){......}, at: [] __driver_attach+0x3b/0x82 Sep 8 16:59:12 Insp6400 kernel: [ 3.443945] #1: (&__lockdep_no_validate__){......}, at: [] __driver_attach+0x49/0x82 Sep 8 16:59:12 Insp6400 kernel: [ 3.444258] #2: (irq_mapping_update_lock){+.+.+.}, at: [] xen_bind_pirq_msi_to_irq+0x31/0xda Sep 8 16:59:12 Insp6400 kernel: [ 3.444371] Modules linked in: Sep 8 16:59:12 Insp6400 kernel: [ 3.444371] Pid: 1, comm: swapper Not tainted 3.1.0-0.rc5.git0.0.fc17.x86_64 #1 Sep 8 16:59:12 Insp6400 kernel: [ 3.444371] Call Trace: Sep 8 16:59:12 Insp6400 kernel: [ 3.444371] [] __schedule_bug+0x75/0x7a Sep 8 16:59:12 Insp6400 kernel: [ 3.444371] [] schedule+0x95/0x7bb Sep 8 16:59:12 Insp6400 kernel: [ 3.444371] [] ? xen_force_evtchn_callback+0xd/0xf Sep 8 16:59:12 Insp6400 kernel: [ 3.444371] [] ? xen_force_evtchn_callback+0xd/0xf Sep 8 16:59:12 Insp6400 kernel: [ 3.444371] [] __cond_resched+0x28/0x34 Sep 8 16:59:12 Insp6400 kernel: [ 3.444371] [] _cond_resched+0x19/0x22 Sep 8 16:59:12 Insp6400 kernel: [ 3.444371] [] mutex_lock_nested+0x2a/0x45 Sep 8 16:59:12 Insp6400 kernel: [ 3.444371] [] __irq_alloc_descs+0x50/0x18b Sep 8 16:59:12 Insp6400 kernel: [ 3.444371] [] ? kzalloc.constprop.1+0x2/0x15 Sep 8 16:59:12 Insp6400 kernel: [ 3.444371] [] xen_allocate_irq_dynamic+0x49/0x58 Sep 8 16:59:12 Insp6400 kernel: [ 3.444371] [] xen_bind_pirq_msi_to_irq+0x36/0xda Sep 8 16:59:12 Insp6400 kernel: [ 3.444371] [] xen_initdom_setup_msi_irqs+0x129/0x15d Sep 8 16:59:12 Insp6400 kernel: [ 3.444371] [] pci_enable_msi_block+0x1c0/0x225 Sep 8 16:59:12 Insp6400 kernel: [ 3.444371] [] pcie_port_device_register+0x308/0x464 Sep 8 16:59:12 Insp6400 kernel: [ 3.444371] [] ? check_events+0x12/0x20 Sep 8 16:59:12 Insp6400 kernel: [ 3.444371] [] ? xen_restore_fl_direct_reloc+0x4/0x4 Sep 8 16:59:12 Insp6400 kernel: [ 3.444371] [] pcie_portdrv_probe+0x57/0x6e Sep 8 16:59:12 Insp6400 kernel: [ 3.444371] [] local_pci_probe+0x44/0x75 Sep 8 16:59:12 Insp6400 kernel: [ 3.444371] [] pci_device_probe+0xd0/0xff Sep 8 16:59:12 Insp6400 kernel: [ 3.444371] [] driver_probe_device+0x131/0x213 Sep 8 16:59:12 Insp6400 kernel: [ 3.444371] [] __driver_attach+0x5e/0x82 Sep 8 16:59:12 Insp6400 kernel: [ 3.444371] [] ? driver_probe_device+0x213/0x213 Sep 8 16:59:12 Insp6400 kernel: [ 3.444371] [] bus_for_each_dev+0x59/0x8f Sep 8 16:59:12 Insp6400 kernel: [ 3.444371] [] driver_attach+0x1e/0x20 Sep 8 16:59:12 Insp6400 kernel: [ 3.444371] [] bus_add_driver+0xd4/0x22a Sep 8 16:59:12 Insp6400 kernel: [ 3.444371] [] ? dmi_pcie_pme_disable_msi+0x21/0x21 Sep 8 16:59:12 Insp6400 kernel: [ 3.444371] [] driver_register+0x98/0x105 Sep 8 16:59:12 Insp6400 kernel: [ 3.444371] [] ? dmi_pcie_pme_disable_msi+0x21/0x21 Sep 8 16:59:12 Insp6400 kernel: [ 3.444371] [] __pci_register_driver+0x66/0xd2 Sep 8 16:59:12 Insp6400 kernel: [ 3.444371] [] ? dmi_pcie_pme_disable_msi+0x21/0x21 Sep 8 16:59:12 Insp6400 kernel: [ 3.444371] [] pcie_portdrv_init+0x66/0x77 Sep 8 16:59:12 Insp6400 kernel: [ 3.444371] [] do_one_initcall+0x7f/0x13a Sep 8 16:59:12 Insp6400 kernel: [ 3.444371] [] kernel_init+0xdf/0x159 Sep 8 16:59:12 Insp6400 kernel: [ 3.444371] [] kernel_thread_helper+0x4/0x10 Sep 8 16:59:12 Insp6400 kernel: [ 3.444371] [] ? retint_restore_args+0x13/0x13 Sep 8 16:59:12 Insp6400 kernel: [ 3.444371] [] ? gs_change+0x13/0x13 Sep 8 16:59:12 Insp6400 kernel: [ 3.454101] pci_hotplug: PCI Hot Plug PCI Core version: 0.5 Sep 8 16:59:12 Insp6400 kernel: [ 3.455760] pciehp: PCI Express Hot Plug Controller Driver version: 0.4 Sep 8 16:59:12 Insp6400 kernel: [ 3.455881] acpiphp: ACPI Hot Plug PCI Controller Driver version: 0.5 Sep 8 16:59:12 Insp6400 kernel: [ 3.466064] acpiphp: Slot [1] registered Sep 8 16:59:12 Insp6400 kernel: [ 3.473115] ACPI: Deprecated procfs I/F for AC is loaded, please retry with CONFIG_ACPI_PROCFS_POWER cleared Sep 8 16:59:12 Insp6400 kernel: [ 3.478671] ACPI: AC Adapter [AC] (on-line) Sep 8 16:59:12 Insp6400 kernel: [ 3.484582] input: Lid Switch as /devices/LNXSYSTM:00/device:00/PNP0C0D:00/input/input0 Sep 8 16:59:12 Insp6400 kernel: [ 3.491334] ACPI: Lid Switch [LID] Sep 8 16:59:12 Insp6400 kernel: [ 3.492686] input: Power Button as /devices/LNXSYSTM:00/device:00/PNP0C0C:00/input/input1 Sep 8 16:59:12 Insp6400 kernel: [ 3.492984] ACPI: Power Button [PBTN] Sep 8 16:59:12 Insp6400 kernel: [ 3.494386] input: Sleep Button as /devices/LNXSYSTM:00/device:00/PNP0C0E:00/input/input2 Sep 8 16:59:12 Insp6400 kernel: [ 3.494619] ACPI: Sleep Button [SBTN] Sep 8 16:59:12 Insp6400 kernel: [ 3.677074] thermal LNXTHERM:00: registered as thermal_zone0 Sep 8 16:59:12 Insp6400 kernel: [ 3.677074] ACPI: Thermal Zone [THM] (67 C) Sep 8 16:59:12 Insp6400 kernel: [ 3.677074] ERST: Table is not found! Sep 8 16:59:12 Insp6400 kernel: [ 3.677074] GHES: HEST is not enabled! Sep 8 16:59:12 Insp6400 kernel: [ 3.697940] Serial: 8250/16550 driver, 4 ports, IRQ sharing enabled Sep 8 16:59:12 Insp6400 kernel: [ 4.212769] hpet_acpi_add: no address or irqs in _CRS Sep 8 16:59:12 Insp6400 kernel: [ 4.214384] Non-volatile memory driver v1.3 Sep 8 16:59:12 Insp6400 kernel: [ 4.214500] Linux agpgart interface v0.103 Sep 8 16:59:12 Insp6400 kernel: [ 4.216385] agpgart-intel 0000:00:00.0: Intel 945GM Chipset Sep 8 16:59:12 Insp6400 kernel: [ 4.223021] agpgart-intel 0000:00:00.0: detected gtt size: 262144K total, 262144K mappable Sep 8 16:59:12 Insp6400 kernel: [ 4.224301] agpgart-intel 0000:00:00.0: detected 8192K stolen memory Sep 8 16:59:12 Insp6400 kernel: [ 4.228213] agpgart-intel 0000:00:00.0: AGP aperture is 256M @ 0xd0000000 Sep 8 16:59:12 Insp6400 kernel: [ 4.254675] loop: module loaded Sep 8 16:59:12 Insp6400 kernel: [ 4.258041] ata_piix 0000:00:1f.2: PCI INT B -> GSI 17 (level, low) -> IRQ 17 Sep 8 16:59:12 Insp6400 kernel: [ 4.258195] ata_piix 0000:00:1f.2: MAP [ P0 P2 IDE IDE ] Sep 8 16:59:12 Insp6400 kernel: [ 4.271431] scsi0 : ata_piix Sep 8 16:59:12 Insp6400 kernel: [ 4.276528] scsi1 : ata_piix Sep 8 16:59:12 Insp6400 kernel: [ 4.392230] ACPI: Deprecated procfs I/F for battery is loaded, please retry with CONFIG_ACPI_PROCFS_POWER cleared Sep 8 16:59:12 Insp6400 kernel: [ 4.392657] ACPI: Battery Slot [BAT0] (battery present) Sep 8 16:59:12 Insp6400 kernel: [ 4.393060] ata1: SATA max UDMA/133 cmd 0x1f0 ctl 0x3f6 bmdma 0xbfa0 irq 14 Sep 8 16:59:12 Insp6400 kernel: [ 4.393060] ata2: PATA max UDMA/100 cmd 0x170 ctl 0x376 bmdma 0xbfa8 irq 15 Sep 8 16:59:12 Insp6400 kernel: [ 4.424981] Fixed MDIO Bus: probed Sep 8 16:59:12 Insp6400 kernel: [ 4.426586] ehci_hcd: USB 2.0 'Enhanced' Host Controller (EHCI) Driver Sep 8 16:59:12 Insp6400 kernel: [ 4.427023] ehci_hcd 0000:00:1d.7: PCI INT A -> GSI 20 (level, low) -> IRQ 20 Sep 8 16:59:12 Insp6400 kernel: [ 4.427370] ehci_hcd 0000:00:1d.7: EHCI Host Controller Sep 8 16:59:12 Insp6400 kernel: [ 4.430277] ehci_hcd 0000:00:1d.7: new USB bus registered, assigned bus number 1 Sep 8 16:59:12 Insp6400 kernel: [ 4.430996] ehci_hcd 0000:00:1d.7: using broken periodic workaround Sep 8 16:59:12 Insp6400 kernel: [ 4.431157] ehci_hcd 0000:00:1d.7: debug port 1 Sep 8 16:59:12 Insp6400 kernel: [ 4.435644] ehci_hcd 0000:00:1d.7: irq 20, io mem 0xffa80000 Sep 8 16:59:12 Insp6400 kernel: [ 4.445141] ehci_hcd 0000:00:1d.7: USB 2.0 started, EHCI 1.00 Sep 8 16:59:12 Insp6400 kernel: [ 4.446274] usb usb1: New USB device found, idVendor=1d6b, idProduct=0002 Sep 8 16:59:12 Insp6400 kernel: [ 4.446395] usb usb1: New USB device strings: Mfr=3, Product=2, SerialNumber=1 Sep 8 16:59:12 Insp6400 kernel: [ 4.446594] usb usb1: Product: EHCI Host Controller Sep 8 16:59:12 Insp6400 kernel: [ 4.446709] usb usb1: Manufacturer: Linux 3.1.0-0.rc5.git0.0.fc17.x86_64 ehci_hcd Sep 8 16:59:12 Insp6400 kernel: [ 4.446910] usb usb1: SerialNumber: 0000:00:1d.7 Sep 8 16:59:12 Insp6400 kernel: [ 4.451034] hub 1-0:1.0: USB hub found Sep 8 16:59:12 Insp6400 kernel: [ 4.451501] hub 1-0:1.0: 8 ports detected Sep 8 16:59:12 Insp6400 kernel: [ 4.455464] ohci_hcd: USB 1.1 'Open' Host Controller (OHCI) Driver Sep 8 16:59:12 Insp6400 kernel: [ 4.455903] uhci_hcd: USB Universal Host Controller Interface driver Sep 8 16:59:12 Insp6400 kernel: [ 4.457042] xen_map_pirq_gsi: returning irq 20 for gsi 20 Sep 8 16:59:12 Insp6400 kernel: [ 4.457197] Already setup the GSI :20 Sep 8 16:59:12 Insp6400 kernel: [ 4.457312] uhci_hcd 0000:00:1d.0: PCI INT A -> GSI 20 (level, low) -> IRQ 20 Sep 8 16:59:12 Insp6400 kernel: [ 4.457556] uhci_hcd 0000:00:1d.0: UHCI Host Controller Sep 8 16:59:12 Insp6400 kernel: [ 4.459067] uhci_hcd 0000:00:1d.0: new USB bus registered, assigned bus number 2 Sep 8 16:59:12 Insp6400 kernel: [ 4.459582] uhci_hcd 0000:00:1d.0: irq 20, io base 0x0000bf80 Sep 8 16:59:12 Insp6400 kernel: [ 4.460826] usb usb2: New USB device found, idVendor=1d6b, idProduct=0001 Sep 8 16:59:12 Insp6400 kernel: [ 4.460946] usb usb2: New USB device strings: Mfr=3, Product=2, SerialNumber=1 Sep 8 16:59:12 Insp6400 kernel: [ 4.461107] usb usb2: Product: UHCI Host Controller Sep 8 16:59:12 Insp6400 kernel: [ 4.461107] usb usb2: Manufacturer: Linux 3.1.0-0.rc5.git0.0.fc17.x86_64 uhci_hcd Sep 8 16:59:12 Insp6400 kernel: [ 4.461107] usb usb2: SerialNumber: 0000:00:1d.0 Sep 8 16:59:12 Insp6400 kernel: [ 4.464642] hub 2-0:1.0: USB hub found Sep 8 16:59:12 Insp6400 kernel: [ 4.465008] hub 2-0:1.0: 2 ports detected Sep 8 16:59:12 Insp6400 kernel: [ 4.467877] uhci_hcd 0000:00:1d.1: PCI INT B -> GSI 21 (level, low) -> IRQ 21 Sep 8 16:59:12 Insp6400 kernel: [ 4.468100] uhci_hcd 0000:00:1d.1: UHCI Host Controller Sep 8 16:59:12 Insp6400 kernel: [ 4.469667] uhci_hcd 0000:00:1d.1: new USB bus registered, assigned bus number 3 Sep 8 16:59:12 Insp6400 kernel: [ 4.470616] uhci_hcd 0000:00:1d.1: irq 21, io base 0x0000bf60 Sep 8 16:59:12 Insp6400 kernel: [ 4.471789] usb usb3: New USB device found, idVendor=1d6b, idProduct=0001 Sep 8 16:59:12 Insp6400 kernel: [ 4.471906] usb usb3: New USB device strings: Mfr=3, Product=2, SerialNumber=1 Sep 8 16:59:12 Insp6400 kernel: [ 4.472067] usb usb3: Product: UHCI Host Controller Sep 8 16:59:12 Insp6400 kernel: [ 4.472067] usb usb3: Manufacturer: Linux 3.1.0-0.rc5.git0.0.fc17.x86_64 uhci_hcd Sep 8 16:59:12 Insp6400 kernel: [ 4.472067] usb usb3: SerialNumber: 0000:00:1d.1 Sep 8 16:59:12 Insp6400 kernel: [ 4.475616] hub 3-0:1.0: USB hub found Sep 8 16:59:12 Insp6400 kernel: [ 4.475997] hub 3-0:1.0: 2 ports detected Sep 8 16:59:12 Insp6400 kernel: [ 4.478904] uhci_hcd 0000:00:1d.2: PCI INT C -> GSI 22 (level, low) -> IRQ 22 Sep 8 16:59:12 Insp6400 kernel: [ 4.479125] uhci_hcd 0000:00:1d.2: UHCI Host Controller Sep 8 16:59:12 Insp6400 kernel: [ 4.480689] uhci_hcd 0000:00:1d.2: new USB bus registered, assigned bus number 4 Sep 8 16:59:12 Insp6400 kernel: [ 4.481497] uhci_hcd 0000:00:1d.2: irq 22, io base 0x0000bf40 Sep 8 16:59:12 Insp6400 kernel: [ 4.482727] usb usb4: New USB device found, idVendor=1d6b, idProduct=0001 Sep 8 16:59:12 Insp6400 kernel: [ 4.482847] usb usb4: New USB device strings: Mfr=3, Product=2, SerialNumber=1 Sep 8 16:59:12 Insp6400 kernel: [ 4.483045] usb usb4: Product: UHCI Host Controller Sep 8 16:59:12 Insp6400 kernel: [ 4.483112] usb usb4: Manufacturer: Linux 3.1.0-0.rc5.git0.0.fc17.x86_64 uhci_hcd Sep 8 16:59:12 Insp6400 kernel: [ 4.483112] usb usb4: SerialNumber: 0000:00:1d.2 Sep 8 16:59:12 Insp6400 kernel: [ 4.487100] hub 4-0:1.0: USB hub found Sep 8 16:59:12 Insp6400 kernel: [ 4.487448] hub 4-0:1.0: 2 ports detected Sep 8 16:59:12 Insp6400 kernel: [ 4.490377] uhci_hcd 0000:00:1d.3: PCI INT D -> GSI 23 (level, low) -> IRQ 23 Sep 8 16:59:12 Insp6400 kernel: [ 4.490603] uhci_hcd 0000:00:1d.3: UHCI Host Controller Sep 8 16:59:12 Insp6400 kernel: [ 4.492088] uhci_hcd 0000:00:1d.3: new USB bus registered, assigned bus number 5 Sep 8 16:59:12 Insp6400 kernel: [ 4.492944] uhci_hcd 0000:00:1d.3: irq 23, io base 0x0000bf20 Sep 8 16:59:12 Insp6400 kernel: [ 4.494309] usb usb5: New USB device found, idVendor=1d6b, idProduct=0001 Sep 8 16:59:12 Insp6400 kernel: [ 4.494428] usb usb5: New USB device strings: Mfr=3, Product=2, SerialNumber=1 Sep 8 16:59:12 Insp6400 kernel: [ 4.494624] usb usb5: Product: UHCI Host Controller Sep 8 16:59:12 Insp6400 kernel: [ 4.494738] usb usb5: Manufacturer: Linux 3.1.0-0.rc5.git0.0.fc17.x86_64 uhci_hcd Sep 8 16:59:12 Insp6400 kernel: [ 4.494932] usb usb5: SerialNumber: 0000:00:1d.3 Sep 8 16:59:12 Insp6400 kernel: [ 4.497976] hub 5-0:1.0: USB hub found Sep 8 16:59:12 Insp6400 kernel: [ 4.498443] hub 5-0:1.0: 2 ports detected Sep 8 16:59:12 Insp6400 kernel: [ 4.502842] usbcore: registered new interface driver usbserial Sep 8 16:59:12 Insp6400 kernel: [ 4.503371] USB Serial support registered for generic Sep 8 16:59:12 Insp6400 kernel: [ 4.503830] usbcore: registered new interface driver usbserial_generic Sep 8 16:59:12 Insp6400 kernel: [ 4.503946] usbserial: USB Serial Driver core Sep 8 16:59:12 Insp6400 kernel: [ 4.504766] i8042: PNP: PS/2 Controller [PNP0303:KBC,PNP0f13:PS2M] at 0x60,0x64 irq 1,12 Sep 8 16:59:12 Insp6400 kernel: [ 4.508443] serio: i8042 KBD port at 0x60,0x64 irq 1 Sep 8 16:59:12 Insp6400 kernel: [ 4.508800] serio: i8042 AUX port at 0x60,0x64 irq 12 Sep 8 16:59:12 Insp6400 kernel: [ 4.511728] mousedev: PS/2 mouse device common for all mice Sep 8 16:59:12 Insp6400 kernel: [ 4.516800] rtc_cmos 00:06: RTC can wake from S4 Sep 8 16:59:12 Insp6400 kernel: [ 4.519077] rtc_cmos 00:06: rtc core: registered rtc_cmos as rtc0 Sep 8 16:59:12 Insp6400 kernel: [ 4.519522] rtc0: alarms up to one month, y3k, 114 bytes nvram Sep 8 16:59:12 Insp6400 kernel: [ 4.522072] input: AT Translated Set 2 keyboard as /devices/platform/i8042/serio0/input/input3 Sep 8 16:59:12 Insp6400 kernel: [ 4.526931] device-mapper: uevent: version 1.0.3 Sep 8 16:59:12 Insp6400 kernel: [ 4.530694] device-mapper: ioctl: 4.21.0-ioctl (2011-07-06) initialised: dm-devel@redhat.com Sep 8 16:59:12 Insp6400 kernel: [ 4.542007] EFI Variables Facility v0.08 2004-May-17 Sep 8 16:59:12 Insp6400 kernel: [ 4.547159] usbcore: registered new interface driver usbhid Sep 8 16:59:12 Insp6400 kernel: [ 4.547280] usbhid: USB HID core driver Sep 8 16:59:12 Insp6400 kernel: [ 4.554367] ip_tables: (C) 2000-2006 Netfilter Core Team Sep 8 16:59:12 Insp6400 kernel: [ 4.554688] TCP cubic registered Sep 8 16:59:12 Insp6400 kernel: [ 4.554804] Initializing XFRM netlink socket Sep 8 16:59:12 Insp6400 kernel: [ 4.559769] NET: Registered protocol family 10 Sep 8 16:59:12 Insp6400 kernel: [ 4.574100] Mobile IPv6 Sep 8 16:59:12 Insp6400 kernel: [ 4.574591] NET: Registered protocol family 17 Sep 8 16:59:12 Insp6400 kernel: [ 4.575116] Registering the dns_resolver key type Sep 8 16:59:12 Insp6400 kernel: [ 4.578852] ata1.00: HPA detected: current 75200265, native 78140160 Sep 8 16:59:12 Insp6400 kernel: [ 4.578978] ata1.00: ATA-6: TOSHIBA MK4032GSX, AS212D, max UDMA/100 Sep 8 16:59:12 Insp6400 kernel: [ 4.579098] ata1.00: 75200265 sectors, multi 8: LBA48 NCQ (depth 0/32) Sep 8 16:59:12 Insp6400 kernel: [ 4.580054] registered taskstats version 1 Sep 8 16:59:12 Insp6400 kernel: [ 4.581431] IMA: No TPM chip found, activating TPM-bypass! Sep 8 16:59:12 Insp6400 kernel: [ 4.587959] ata1.00: configured for UDMA/100 Sep 8 16:59:12 Insp6400 kernel: [ 4.590949] scsi 0:0:0:0: Direct-Access ATA TOSHIBA MK4032GS AS21 PQ: 0 ANSI: 5 Sep 8 16:59:12 Insp6400 kernel: [ 4.593951] ata2.00: ATAPI: TSSTcorpCD-RW/DVD-ROM TSL462C, DE01, max UDMA/33 Sep 8 16:59:12 Insp6400 kernel: [ 4.595845] Magic number: 11:184:1003 Sep 8 16:59:12 Insp6400 kernel: [ 4.596143] input input0: hash matches Sep 8 16:59:12 Insp6400 kernel: [ 4.596301] vc vcs: hash matches Sep 8 16:59:12 Insp6400 kernel: [ 4.596421] i8042 kbd 00:05: hash matches Sep 8 16:59:12 Insp6400 kernel: [ 4.597332] rtc_cmos 00:06: setting system clock to 2011-09-08 20:58:10 UTC (1315515490) Sep 8 16:59:12 Insp6400 kernel: [ 4.605886] sd 0:0:0:0: [sda] 75200265 512-byte logical blocks: (38.5 GB/35.8 GiB) Sep 8 16:59:12 Insp6400 kernel: [ 4.607916] sd 0:0:0:0: [sda] Write Protect is off Sep 8 16:59:12 Insp6400 kernel: [ 4.608795] sd 0:0:0:0: [sda] Write cache: enabled, read cache: enabled, doesn't support DPO or FUA Sep 8 16:59:12 Insp6400 kernel: [ 4.613095] sd 0:0:0:0: Attached scsi generic sg0 type 0 Sep 8 16:59:12 Insp6400 kernel: [ 4.616777] ata2.00: configured for UDMA/33 Sep 8 16:59:12 Insp6400 kernel: [ 4.622502] scsi 1:0:0:0: CD-ROM TSSTcorp CDRW/DVD TSL462C DE01 PQ: 0 ANSI: 5 Sep 8 16:59:12 Insp6400 kernel: [ 4.625298] Initializing network drop monitor service Sep 8 16:59:12 Insp6400 kernel: [ 4.627200] sr0: scsi3-mmc drive: 24x/24x writer cd/rw xa/form2 cdda tray Sep 8 16:59:12 Insp6400 kernel: [ 4.627339] cdrom: Uniform CD-ROM driver Revision: 3.20 Sep 8 16:59:12 Insp6400 kernel: [ 4.634936] sr 1:0:0:0: Attached scsi generic sg1 type 5 Sep 8 16:59:12 Insp6400 kernel: [ 4.659570] sda: sda1 sda2 sda3 Sep 8 16:59:12 Insp6400 kernel: [ 4.668851] sd 0:0:0:0: [sda] Attached SCSI disk Sep 8 16:59:12 Insp6400 kernel: [ 4.674686] Freeing unused kernel memory: 2780k freed Sep 8 16:59:12 Insp6400 kernel: [ 4.676066] Write protecting the kernel read-only data: 10240k Sep 8 16:59:12 Insp6400 kernel: [ 4.698892] Freeing unused kernel memory: 940k freed Sep 8 16:59:12 Insp6400 kernel: [ 4.703360] Freeing unused kernel memory: 1424k freed Sep 8 16:59:12 Insp6400 kernel: [ 4.727089] mknod used greatest stack depth: 5120 bytes left Sep 8 16:59:12 Insp6400 kernel: [ 4.895081] mount used greatest stack depth: 4968 bytes left Sep 8 16:59:12 Insp6400 kernel: [ 5.214678] Synaptics Touchpad, model: 1, fw: 6.2, id: 0x180b1, caps: 0xa04713/0x200000/0x0 Sep 8 16:59:12 Insp6400 kernel: [ 5.253303] input: SynPS/2 Synaptics TouchPad as /devices/platform/i8042/serio1/input/input4 Sep 8 16:59:12 Insp6400 kernel: [ 5.676103] udevadm used greatest stack depth: 4904 bytes left Sep 8 16:59:12 Insp6400 kernel: [ 6.138176] console_init used greatest stack depth: 4848 bytes left Sep 8 16:59:12 Insp6400 kernel: [ 6.342404] acpi device:28: registered as cooling_device2 Sep 8 16:59:12 Insp6400 kernel: [ 6.350194] input: Video Bus as /devices/LNXSYSTM:00/device:00/PNP0A03:00/LNXVIDEO:01/input/input5 Sep 8 16:59:12 Insp6400 kernel: [ 6.352172] ACPI: Video Device [VID1] (multi-head: yes rom: no post: no) Sep 8 16:59:12 Insp6400 kernel: [ 6.352796] [Firmware Bug]: Duplicate ACPI video bus devices for the same VGA controller, please try module parameter "video.allow_duplicates=1"if the current driver doesn't work. Sep 8 16:59:12 Insp6400 kernel: [ 6.386874] [drm] Initialized drm 1.1.0 20060810 Sep 8 16:59:12 Insp6400 kernel: [ 6.424884] xen_map_pirq_gsi: returning irq 16 for gsi 16 Sep 8 16:59:12 Insp6400 kernel: [ 6.425012] Already setup the GSI :16 Sep 8 16:59:12 Insp6400 kernel: [ 6.425068] i915 0000:00:02.0: PCI INT A -> GSI 16 (level, low) -> IRQ 16 Sep 8 16:59:12 Insp6400 kernel: [ 6.859099] [drm] MTRR allocation failed. Graphics performance may suffer. Sep 8 16:59:12 Insp6400 kernel: [ 6.882694] [drm] Supports vblank timestamp caching Rev 1 (10.10.2010). Sep 8 16:59:12 Insp6400 kernel: [ 6.882817] [drm] Driver supports precise vblank timestamp query. Sep 8 16:59:12 Insp6400 kernel: [ 6.884526] vgaarb: device changed decodes: PCI:0000:00:02.0,olddecodes=io+mem,decodes=io+mem:owns=io+mem Sep 8 16:59:12 Insp6400 kernel: [ 7.201153] [drm] initialized overlay support Sep 8 16:59:12 Insp6400 kernel: [ 7.483956] fbcon: inteldrmfb (fb0) is primary device Sep 8 16:59:12 Insp6400 kernel: [ 7.671279] Console: switching to colour frame buffer device 160x50 Sep 8 16:59:12 Insp6400 kernel: [ 7.676066] fb0: inteldrmfb frame buffer device Sep 8 16:59:12 Insp6400 kernel: [ 7.676066] drm: registered panic notifier Sep 8 16:59:12 Insp6400 kernel: [ 7.676415] [drm] Initialized i915 1.6.0 20080730 for 0000:00:02.0 on minor 0 Sep 8 16:59:12 Insp6400 kernel: [ 7.682068] modprobe used greatest stack depth: 2800 bytes left Sep 8 16:59:12 Insp6400 kernel: [ 9.301111] wmi: Mapper loaded Sep 8 16:59:12 Insp6400 kernel: [ 9.665528] xen_map_pirq_gsi: returning irq 19 for gsi 19 Sep 8 16:59:12 Insp6400 kernel: [ 9.665588] Already setup the GSI :19 Sep 8 16:59:12 Insp6400 kernel: [ 9.665622] firewire_ohci 0000:03:01.0: PCI INT A -> GSI 19 (level, low) -> IRQ 19 Sep 8 16:59:12 Insp6400 kernel: [ 9.696404] sdhci: Secure Digital Host Controller Interface driver Sep 8 16:59:12 Insp6400 kernel: [ 9.696465] sdhci: Copyright(c) Pierre Ossman Sep 8 16:59:12 Insp6400 kernel: [ 9.727406] firewire_ohci: Added fw-ohci device 0000:03:01.0, OHCI v1.10, 4 IR + 4 IT contexts, quirks 0x1 Sep 8 16:59:12 Insp6400 kernel: [ 9.732408] sdhci-pci 0000:03:01.1: SDHCI controller found [1180:0822] (rev 19) Sep 8 16:59:12 Insp6400 kernel: [ 9.732532] BUG: sleeping function called from invalid context at kernel/mutex.c:271 Sep 8 16:59:12 Insp6400 kernel: [ 9.732592] in_atomic(): 1, irqs_disabled(): 0, pid: 245, name: modprobe Sep 8 16:59:12 Insp6400 kernel: [ 9.732645] 3 locks held by modprobe/245: Sep 8 16:59:12 Insp6400 kernel: [ 9.732679] #0: (&__lockdep_no_validate__){......}, at: [] __driver_attach+0x3b/0x82 Sep 8 16:59:12 Insp6400 kernel: [ 9.732784] #1: (&__lockdep_no_validate__){......}, at: [] __driver_attach+0x49/0x82 Sep 8 16:59:12 Insp6400 kernel: [ 9.732885] #2: (irq_mapping_update_lock){+.+.+.}, at: [] xen_bind_pirq_gsi_to_irq+0x2e/0x1a2 Sep 8 16:59:12 Insp6400 kernel: [ 9.732988] Pid: 245, comm: modprobe Not tainted 3.1.0-0.rc5.git0.0.fc17.x86_64 #1 Sep 8 16:59:12 Insp6400 kernel: [ 9.733046] Call Trace: Sep 8 16:59:12 Insp6400 kernel: [ 9.733067] [] __might_sleep+0x103/0x108 Sep 8 16:59:12 Insp6400 kernel: [ 9.733067] [] mutex_lock_nested+0x25/0x45 Sep 8 16:59:12 Insp6400 kernel: [ 9.733067] [] __irq_alloc_descs+0x50/0x18b Sep 8 16:59:12 Insp6400 kernel: [ 9.733067] [] xen_bind_pirq_gsi_to_irq+0xb2/0x1a2 Sep 8 16:59:12 Insp6400 kernel: [ 9.733067] [] ? arch_local_irq_restore+0xb/0xd Sep 8 16:59:12 Insp6400 kernel: [ 9.733067] [] xen_register_pirq+0x8b/0xb7 Sep 8 16:59:12 Insp6400 kernel: [ 9.733067] [] xen_register_gsi.part.2+0x41/0x9f Sep 8 16:59:12 Insp6400 kernel: [ 9.733067] [] acpi_register_gsi_xen+0x1e/0x20 Sep 8 16:59:12 Insp6400 kernel: [ 9.733067] [] acpi_register_gsi+0xf/0x18 Sep 8 16:59:12 Insp6400 kernel: [ 9.733067] [] acpi_pci_irq_enable+0x172/0x246 Sep 8 16:59:12 Insp6400 kernel: [ 9.733067] [] pcibios_enable_device+0x2b/0x30 Sep 8 16:59:12 Insp6400 kernel: [ 9.733067] [] do_pci_enable_device+0x30/0x48 Sep 8 16:59:12 Insp6400 kernel: [ 9.749832] [] __pci_enable_device_flags+0x77/0x8a Sep 8 16:59:12 Insp6400 kernel: [ 9.749832] [] pci_enable_device+0x13/0x15 Sep 8 16:59:12 Insp6400 kernel: [ 9.749832] [] sdhci_pci_probe+0xf0/0x416 [sdhci_pci] Sep 8 16:59:12 Insp6400 kernel: [ 9.749832] [] ? xen_restore_fl_direct_reloc+0x4/0x4 Sep 8 16:59:12 Insp6400 kernel: [ 9.749832] [] ? arch_local_irq_restore+0xb/0xd Sep 8 16:59:12 Insp6400 kernel: [ 9.749832] [] ? _raw_spin_unlock_irqrestore+0x4d/0x61 Sep 8 16:59:12 Insp6400 kernel: [ 9.749832] [] local_pci_probe+0x44/0x75 Sep 8 16:59:12 Insp6400 kernel: [ 9.749832] [] pci_device_probe+0xd0/0xff Sep 8 16:59:12 Insp6400 kernel: [ 9.749832] [] driver_probe_device+0x131/0x213 Sep 8 16:59:12 Insp6400 kernel: [ 9.749832] [] __driver_attach+0x5e/0x82 Sep 8 16:59:12 Insp6400 kernel: [ 9.749832] [] ? driver_probe_device+0x213/0x213 Sep 8 16:59:12 Insp6400 kernel: [ 9.749832] [] bus_for_each_dev+0x59/0x8f Sep 8 16:59:12 Insp6400 kernel: [ 9.749832] [] driver_attach+0x1e/0x20 Sep 8 16:59:12 Insp6400 kernel: [ 9.749832] [] bus_add_driver+0xd4/0x22a Sep 8 16:59:12 Insp6400 kernel: [ 9.749832] [] ? 0xffffffffa00fbfff Sep 8 16:59:12 Insp6400 kernel: [ 9.749832] [] driver_register+0x98/0x105 Sep 8 16:59:12 Insp6400 kernel: [ 9.749832] [] ? 0xffffffffa00fbfff Sep 8 16:59:12 Insp6400 kernel: [ 9.749832] [] __pci_register_driver+0x66/0xd2 Sep 8 16:59:12 Insp6400 kernel: [ 9.749832] [] ? 0xffffffffa00fbfff Sep 8 16:59:12 Insp6400 kernel: [ 9.749832] [] sdhci_drv_init+0x1e/0x1000 [sdhci_pci] Sep 8 16:59:12 Insp6400 kernel: [ 9.749832] [] do_one_initcall+0x7f/0x13a Sep 8 16:59:12 Insp6400 kernel: [ 9.749832] [] ? 0xffffffffa00fbfff Sep 8 16:59:12 Insp6400 kernel: [ 9.749832] [] sys_init_module+0x114/0x267 Sep 8 16:59:12 Insp6400 kernel: [ 9.749832] [] system_call_fastpath+0x16/0x1b Sep 8 16:59:12 Insp6400 kernel: [ 9.749832] BUG: scheduling while atomic: modprobe/245/0x10000002 Sep 8 16:59:12 Insp6400 kernel: [ 9.749832] 3 locks held by modprobe/245: Sep 8 16:59:12 Insp6400 kernel: [ 9.749832] #0: (&__lockdep_no_validate__){......}, at: [] __driver_attach+0x3b/0x82 Sep 8 16:59:12 Insp6400 kernel: [ 9.749832] #1: (&__lockdep_no_validate__){......}, at: [] __driver_attach+0x49/0x82 Sep 8 16:59:12 Insp6400 kernel: [ 9.749832] #2: (irq_mapping_update_lock){+.+.+.}, at: [] xen_bind_pirq_gsi_to_irq+0x2e/0x1a2 Sep 8 16:59:12 Insp6400 kernel: [ 9.749832] Modules linked in: sdhci_pci(+) sdhci mmc_core firewire_ohci firewire_core crc_itu_t wmi i915 drm_kms_helper drm i2c_algo_bit i2c_core video Sep 8 16:59:12 Insp6400 kernel: [ 9.749832] Pid: 245, comm: modprobe Not tainted 3.1.0-0.rc5.git0.0.fc17.x86_64 #1 Sep 8 16:59:12 Insp6400 kernel: [ 9.749832] Call Trace: Sep 8 16:59:12 Insp6400 kernel: [ 9.749832] [] __schedule_bug+0x75/0x7a Sep 8 16:59:12 Insp6400 kernel: [ 9.749832] [] schedule+0x95/0x7bb Sep 8 16:59:12 Insp6400 kernel: [ 9.749832] [] ? show_trace_log_lvl+0x54/0x5d Sep 8 16:59:12 Insp6400 kernel: [ 9.749832] [] ? show_trace+0x15/0x17 Sep 8 16:59:12 Insp6400 kernel: [ 9.749832] [] __cond_resched+0x28/0x34 Sep 8 16:59:12 Insp6400 kernel: [ 9.749832] [] _cond_resched+0x19/0x22 Sep 8 16:59:12 Insp6400 kernel: [ 9.749832] [] mutex_lock_nested+0x2a/0x45 Sep 8 16:59:12 Insp6400 kernel: [ 9.749832] [] __irq_alloc_descs+0x50/0x18b Sep 8 16:59:12 Insp6400 kernel: [ 9.749832] [] xen_bind_pirq_gsi_to_irq+0xb2/0x1a2 Sep 8 16:59:12 Insp6400 kernel: [ 9.749832] [] ? arch_local_irq_restore+0xb/0xd Sep 8 16:59:12 Insp6400 kernel: [ 9.749832] [] xen_register_pirq+0x8b/0xb7 Sep 8 16:59:12 Insp6400 kernel: [ 9.749832] [] xen_register_gsi.part.2+0x41/0x9f Sep 8 16:59:12 Insp6400 kernel: [ 9.749832] [] acpi_register_gsi_xen+0x1e/0x20 Sep 8 16:59:12 Insp6400 kernel: [ 9.749832] [] acpi_register_gsi+0xf/0x18 Sep 8 16:59:12 Insp6400 kernel: [ 9.749832] [] acpi_pci_irq_enable+0x172/0x246 Sep 8 16:59:12 Insp6400 kernel: [ 9.749832] [] pcibios_enable_device+0x2b/0x30 Sep 8 16:59:12 Insp6400 kernel: [ 9.749832] [] do_pci_enable_device+0x30/0x48 Sep 8 16:59:12 Insp6400 kernel: [ 9.749832] [] __pci_enable_device_flags+0x77/0x8a Sep 8 16:59:12 Insp6400 kernel: [ 9.749832] [] pci_enable_device+0x13/0x15 Sep 8 16:59:12 Insp6400 kernel: [ 9.749832] [] sdhci_pci_probe+0xf0/0x416 [sdhci_pci] Sep 8 16:59:12 Insp6400 kernel: [ 9.749832] [] ? xen_restore_fl_direct_reloc+0x4/0x4 Sep 8 16:59:12 Insp6400 kernel: [ 9.749832] [] ? arch_local_irq_restore+0xb/0xd Sep 8 16:59:12 Insp6400 kernel: [ 9.749832] [] ? _raw_spin_unlock_irqrestore+0x4d/0x61 Sep 8 16:59:12 Insp6400 kernel: [ 9.749832] [] local_pci_probe+0x44/0x75 Sep 8 16:59:12 Insp6400 kernel: [ 9.749832] [] pci_device_probe+0xd0/0xff Sep 8 16:59:12 Insp6400 kernel: [ 9.749832] [] driver_probe_device+0x131/0x213 Sep 8 16:59:12 Insp6400 kernel: [ 9.749832] [] __driver_attach+0x5e/0x82 Sep 8 16:59:12 Insp6400 kernel: [ 9.749832] [] ? driver_probe_device+0x213/0x213 Sep 8 16:59:12 Insp6400 kernel: [ 9.749832] [] bus_for_each_dev+0x59/0x8f Sep 8 16:59:12 Insp6400 kernel: [ 9.749832] [] driver_attach+0x1e/0x20 Sep 8 16:59:12 Insp6400 kernel: [ 9.749832] [] bus_add_driver+0xd4/0x22a Sep 8 16:59:12 Insp6400 kernel: [ 9.749832] [] ? 0xffffffffa00fbfff Sep 8 16:59:12 Insp6400 kernel: [ 9.749832] [] driver_register+0x98/0x105 Sep 8 16:59:12 Insp6400 kernel: [ 9.749832] [] ? 0xffffffffa00fbfff Sep 8 16:59:12 Insp6400 kernel: [ 9.749832] [] __pci_register_driver+0x66/0xd2 Sep 8 16:59:12 Insp6400 kernel: [ 9.749832] [] ? 0xffffffffa00fbfff Sep 8 16:59:12 Insp6400 kernel: [ 9.749832] [] sdhci_drv_init+0x1e/0x1000 [sdhci_pci] Sep 8 16:59:12 Insp6400 kernel: [ 9.749832] [] do_one_initcall+0x7f/0x13a Sep 8 16:59:12 Insp6400 kernel: [ 9.749832] [] ? 0xffffffffa00fbfff Sep 8 16:59:12 Insp6400 kernel: [ 9.749832] [] sys_init_module+0x114/0x267 Sep 8 16:59:12 Insp6400 kernel: [ 9.749832] [] system_call_fastpath+0x16/0x1b Sep 8 16:59:12 Insp6400 kernel: [ 9.935093] sdhci-pci 0000:03:01.1: PCI INT B -> GSI 18 (level, low) -> IRQ 18 Sep 8 16:59:12 Insp6400 kernel: [ 9.949666] mmc0: SDHCI controller on PCI [0000:03:01.1] using DMA Sep 8 16:59:12 Insp6400 kernel: [ 10.232950] firewire_core: created device fw0: GUID 444fc0000e8ad921, S400 Sep 8 16:59:12 Insp6400 kernel: [ 17.102941] EXT4-fs (dm-0): mounted filesystem with ordered data mode. Opts: (null) Sep 8 16:59:12 Insp6400 kernel: [ 17.489192] EXT4-fs (dm-0): mounted filesystem with ordered data mode. Opts: (null) Sep 8 16:59:12 Insp6400 kernel: [ 38.466327] type=1403 audit(1315515524.369:2): policy loaded auid=4294967295 ses=4294967295 Sep 8 16:59:12 Insp6400 kernel: [ 47.240444] EXT4-fs (dm-0): re-mounted. Opts: (null) Sep 8 16:59:12 Insp6400 kernel: [ 48.864074] Event-channel device installed. Sep 8 16:59:12 Insp6400 kernel: [ 50.134162] tun: Universal TUN/TAP device driver, 1.6 Sep 8 16:59:12 Insp6400 kernel: [ 50.135064] tun: (C) 1999-2004 Max Krasnyansky Sep 8 16:59:12 Insp6400 kernel: [ 52.495009] intel_rng: FWH not detected Sep 8 16:59:12 Insp6400 kernel: [ 52.664154] iTCO_vendor_support: vendor-support=0 Sep 8 16:59:12 Insp6400 kernel: [ 52.789276] iTCO_wdt: Intel TCO WatchDog Timer Driver v1.06 Sep 8 16:59:12 Insp6400 kernel: [ 52.825541] iTCO_wdt: Found a ICH7-M or ICH7-U TCO device (Version=2, TCOBASE=0x1060) Sep 8 16:59:12 Insp6400 kernel: [ 52.945236] iTCO_wdt: initialized. heartbeat=30 sec (nowayout=0) Sep 8 16:59:12 Insp6400 kernel: [ 52.954853] r8169 Gigabit Ethernet driver 2.3LK-NAPI loaded Sep 8 16:59:12 Insp6400 kernel: [ 52.959351] xen_map_pirq_gsi: returning irq 19 for gsi 19 Sep 8 16:59:12 Insp6400 kernel: [ 52.960876] Already setup the GSI :19 Sep 8 16:59:12 Insp6400 kernel: [ 52.961768] r8169 0000:0c:00.0: PCI INT A -> GSI 19 (level, low) -> IRQ 19 Sep 8 16:59:12 Insp6400 kernel: [ 52.971581] BUG: sleeping function called from invalid context at kernel/mutex.c:271 Sep 8 16:59:12 Insp6400 kernel: [ 52.972086] in_atomic(): 1, irqs_disabled(): 0, pid: 510, name: modprobe Sep 8 16:59:12 Insp6400 kernel: [ 52.972086] 3 locks held by modprobe/510: Sep 8 16:59:12 Insp6400 kernel: [ 52.972086] #0: (&__lockdep_no_validate__){......}, at: [] __driver_attach+0x3b/0x82 Sep 8 16:59:12 Insp6400 kernel: [ 52.972086] #1: (&__lockdep_no_validate__){......}, at: [] __driver_attach+0x49/0x82 Sep 8 16:59:12 Insp6400 kernel: [ 52.972086] #2: (irq_mapping_update_lock){+.+.+.}, at: [] xen_bind_pirq_msi_to_irq+0x31/0xda Sep 8 16:59:12 Insp6400 kernel: [ 52.972086] Pid: 510, comm: modprobe Not tainted 3.1.0-0.rc5.git0.0.fc17.x86_64 #1 Sep 8 16:59:12 Insp6400 kernel: [ 52.972086] Call Trace: Sep 8 16:59:12 Insp6400 kernel: [ 52.972086] [] __might_sleep+0x103/0x108 Sep 8 16:59:12 Insp6400 kernel: [ 52.972086] [] mutex_lock_nested+0x25/0x45 Sep 8 16:59:12 Insp6400 kernel: [ 52.972086] [] __irq_alloc_descs+0x50/0x18b Sep 8 16:59:12 Insp6400 kernel: [ 52.972086] [] ? kzalloc.constprop.1+0x2/0x15 Sep 8 16:59:12 Insp6400 kernel: [ 52.972086] [] xen_allocate_irq_dynamic+0x49/0x58 Sep 8 16:59:12 Insp6400 kernel: [ 52.972086] [] xen_bind_pirq_msi_to_irq+0x36/0xda Sep 8 16:59:12 Insp6400 kernel: [ 52.972086] [] xen_initdom_setup_msi_irqs+0x129/0x15d Sep 8 16:59:12 Insp6400 kernel: [ 52.972086] [] pci_enable_msi_block+0x1c0/0x225 Sep 8 16:59:12 Insp6400 kernel: [ 52.972086] [] rtl8169_init_one+0x515/0x85c [r8169] Sep 8 16:59:12 Insp6400 kernel: [ 52.972086] [] ? xen_restore_fl_direct_reloc+0x4/0x4 Sep 8 16:59:12 Insp6400 kernel: [ 52.972086] [] ? arch_local_irq_restore+0xb/0xd Sep 8 16:59:12 Insp6400 kernel: [ 52.972086] [] local_pci_probe+0x44/0x75 Sep 8 16:59:12 Insp6400 kernel: [ 52.972086] [] pci_device_probe+0xd0/0xff Sep 8 16:59:12 Insp6400 kernel: [ 52.972086] [] driver_probe_device+0x131/0x213 Sep 8 16:59:12 Insp6400 kernel: [ 52.972086] [] __driver_attach+0x5e/0x82 Sep 8 16:59:12 Insp6400 kernel: [ 52.972086] [] ? driver_probe_device+0x213/0x213 Sep 8 16:59:12 Insp6400 kernel: [ 52.972086] [] bus_for_each_dev+0x59/0x8f Sep 8 16:59:12 Insp6400 kernel: [ 52.972086] [] driver_attach+0x1e/0x20 Sep 8 16:59:12 Insp6400 kernel: [ 52.972086] [] bus_add_driver+0xd4/0x22a Sep 8 16:59:12 Insp6400 kernel: [ 52.972086] [] ? 0xffffffffa01befff Sep 8 16:59:12 Insp6400 kernel: [ 52.972086] [] driver_register+0x98/0x105 Sep 8 16:59:12 Insp6400 kernel: [ 52.972086] [] ? 0xffffffffa01befff Sep 8 16:59:12 Insp6400 kernel: [ 52.972086] [] __pci_register_driver+0x66/0xd2 Sep 8 16:59:12 Insp6400 kernel: [ 52.972086] [] ? 0xffffffffa01befff Sep 8 16:59:12 Insp6400 kernel: [ 52.972086] [] rtl8169_init_module+0x1e/0x1000 [r8169] Sep 8 16:59:12 Insp6400 kernel: [ 52.972086] [] do_one_initcall+0x7f/0x13a Sep 8 16:59:12 Insp6400 kernel: [ 52.972086] [] ? 0xffffffffa01befff Sep 8 16:59:12 Insp6400 kernel: [ 52.972086] [] sys_init_module+0x114/0x267 Sep 8 16:59:12 Insp6400 kernel: [ 52.972086] [] system_call_fastpath+0x16/0x1b Sep 8 16:59:12 Insp6400 kernel: [ 53.125576] cfg80211: Calling CRDA to update world regulatory domain Sep 8 16:59:12 Insp6400 kernel: [ 53.225315] microcode: CPU0 sig=0x6f6, pf=0x20, revision=0xc7 Sep 8 16:59:12 Insp6400 kernel: [ 53.390418] r8169 0000:0c:00.0: eth0: RTL8168d/8111d at 0xffffc90000378000, 00:e0:4c:68:23:0d, XID 081000c0 IRQ 286 Sep 8 16:59:12 Insp6400 kernel: [ 53.457417] dcdbas dcdbas: Dell Systems Management Base Driver (version 5.6.0-3.2) Sep 8 16:59:12 Insp6400 kernel: [ 53.463253] xen_map_pirq_gsi: returning irq 17 for gsi 17 Sep 8 16:59:12 Insp6400 kernel: [ 53.465100] Already setup the GSI :17 Sep 8 16:59:12 Insp6400 kernel: [ 53.466083] i801_smbus 0000:00:1f.3: PCI INT B -> GSI 17 (level, low) -> IRQ 17 Sep 8 16:59:12 Insp6400 kernel: [ 53.675021] xen_map_pirq_gsi: returning irq 17 for gsi 17 Sep 8 16:59:12 Insp6400 kernel: [ 53.676759] Already setup the GSI :17 Sep 8 16:59:12 Insp6400 kernel: [ 53.677696] b44 0000:03:00.0: PCI INT A -> GSI 17 (level, low) -> IRQ 17 Sep 8 16:59:12 Insp6400 kernel: [ 53.799234] ssb: Sonics Silicon Backplane found on PCI device 0000:03:00.0 Sep 8 16:59:12 Insp6400 kernel: [ 53.952106] b44: Broadcom 44xx/47xx 10/100 PCI ethernet driver version 2.0 Sep 8 16:59:12 Insp6400 kernel: [ 54.034482] xen_map_pirq_gsi: returning irq 18 for gsi 18 Sep 8 16:59:12 Insp6400 kernel: [ 54.036108] Already setup the GSI :18 Sep 8 16:59:12 Insp6400 kernel: [ 54.037461] r592 0000:03:01.2: PCI INT B -> GSI 18 (level, low) -> IRQ 18 Sep 8 16:59:12 Insp6400 kernel: [ 54.051070] b44 ssb0:0: eth1: Broadcom 44xx/47xx 10/100 PCI ethernet driver 00:15:c5:04:7d:4f Sep 8 16:59:12 Insp6400 kernel: [ 54.058267] r592: driver successfully loaded Sep 8 16:59:12 Insp6400 kernel: [ 54.301138] leds_ss4200: no LED devices found Sep 8 16:59:12 Insp6400 kernel: [ 54.361679] xen_map_pirq_gsi: returning irq 18 for gsi 18 Sep 8 16:59:12 Insp6400 kernel: [ 54.363448] Already setup the GSI :18 Sep 8 16:59:12 Insp6400 kernel: [ 54.364263] r852 0000:03:01.3: PCI INT B -> GSI 18 (level, low) -> IRQ 18 Sep 8 16:59:12 Insp6400 kernel: [ 54.444011] r852: Non dma capable device detected, dma disabled Sep 8 16:59:12 Insp6400 kernel: [ 54.445864] r852: driver loaded successfully Sep 8 16:59:12 Insp6400 kernel: [ 55.004011] microcode: CPU0 update to revision 0xd1 failed Sep 8 16:59:12 Insp6400 kernel: [ 55.006025] microcode: CPU1 sig=0x6f6, pf=0x20, revision=0xc7 Sep 8 16:59:12 Insp6400 kernel: [ 55.009410] iwl3945: Intel(R) PRO/Wireless 3945ABG/BG Network Connection driver for Linux, in-tree:ds Sep 8 16:59:12 Insp6400 kernel: [ 55.010066] iwl3945: Copyright(c) 2003-2011 Intel Corporation Sep 8 16:59:12 Insp6400 kernel: [ 55.013555] xen_map_pirq_gsi: returning irq 16 for gsi 16 Sep 8 16:59:12 Insp6400 kernel: [ 55.015264] Already setup the GSI :16 Sep 8 16:59:12 Insp6400 kernel: [ 55.016248] iwl3945 0000:0b:00.0: PCI INT A -> GSI 16 (level, low) -> IRQ 16 Sep 8 16:59:12 Insp6400 kernel: [ 55.070827] microcode: CPU1 update to revision 0xd1 failed Sep 8 16:59:12 Insp6400 kernel: [ 55.080017] microcode: Microcode Update Driver: v2.00 , Peter Oruba Sep 8 16:59:12 Insp6400 kernel: [ 55.087930] iwl3945 0000:0b:00.0: Tunable channels: 11 802.11bg, 13 802.11a channels Sep 8 16:59:12 Insp6400 kernel: [ 55.088151] iwl3945 0000:0b:00.0: Detected Intel Wireless WiFi Link 3945ABG Sep 8 16:59:12 Insp6400 kernel: [ 55.092221] BUG: sleeping function called from invalid context at kernel/mutex.c:271 Sep 8 16:59:12 Insp6400 kernel: [ 55.093017] in_atomic(): 1, irqs_disabled(): 0, pid: 516, name: modprobe Sep 8 16:59:12 Insp6400 kernel: [ 55.093017] 3 locks held by modprobe/516: Sep 8 16:59:12 Insp6400 kernel: [ 55.093017] #0: (&__lockdep_no_validate__){......}, at: [] __driver_attach+0x3b/0x82 Sep 8 16:59:12 Insp6400 kernel: [ 55.093017] #1: (&__lockdep_no_validate__){......}, at: [] __driver_attach+0x49/0x82 Sep 8 16:59:12 Insp6400 kernel: [ 55.093017] #2: (irq_mapping_update_lock){+.+.+.}, at: [] xen_bind_pirq_msi_to_irq+0x31/0xda Sep 8 16:59:12 Insp6400 kernel: [ 55.093017] Pid: 516, comm: modprobe Not tainted 3.1.0-0.rc5.git0.0.fc17.x86_64 #1 Sep 8 16:59:12 Insp6400 kernel: [ 55.093017] Call Trace: Sep 8 16:59:12 Insp6400 kernel: [ 55.093017] [] __might_sleep+0x103/0x108 Sep 8 16:59:12 Insp6400 kernel: [ 55.093017] [] mutex_lock_nested+0x25/0x45 Sep 8 16:59:12 Insp6400 kernel: [ 55.093017] [] __irq_alloc_descs+0x50/0x18b Sep 8 16:59:12 Insp6400 kernel: [ 55.093017] [] ? kzalloc.constprop.1+0x2/0x15 Sep 8 16:59:12 Insp6400 kernel: [ 55.093017] [] xen_allocate_irq_dynamic+0x49/0x58 Sep 8 16:59:12 Insp6400 kernel: [ 55.093017] [] xen_bind_pirq_msi_to_irq+0x36/0xda Sep 8 16:59:12 Insp6400 kernel: [ 55.093017] [] xen_initdom_setup_msi_irqs+0x129/0x15d Sep 8 16:59:12 Insp6400 kernel: [ 55.093017] [] pci_enable_msi_block+0x1c0/0x225 Sep 8 16:59:12 Insp6400 kernel: [ 55.093017] [] iwl3945_pci_probe+0x6b7/0xc51 [iwl3945] Sep 8 16:59:12 Insp6400 kernel: [ 55.093017] [] local_pci_probe+0x44/0x75 Sep 8 16:59:12 Insp6400 kernel: [ 55.093017] [] pci_device_probe+0xd0/0xff Sep 8 16:59:12 Insp6400 kernel: [ 55.093017] [] driver_probe_device+0x131/0x213 Sep 8 16:59:12 Insp6400 kernel: [ 55.093017] [] __driver_attach+0x5e/0x82 Sep 8 16:59:12 Insp6400 kernel: [ 55.093017] [] ? driver_probe_device+0x213/0x213 Sep 8 16:59:12 Insp6400 kernel: [ 55.093017] [] bus_for_each_dev+0x59/0x8f Sep 8 16:59:12 Insp6400 kernel: [ 55.093017] [] driver_attach+0x1e/0x20 Sep 8 16:59:12 Insp6400 kernel: [ 55.093017] [] bus_add_driver+0xd4/0x22a Sep 8 16:59:12 Insp6400 kernel: [ 55.093017] [] ? 0xffffffffa0287fff Sep 8 16:59:12 Insp6400 kernel: [ 55.093017] [] driver_register+0x98/0x105 Sep 8 16:59:12 Insp6400 kernel: [ 55.093017] [] ? 0xffffffffa0287fff Sep 8 16:59:12 Insp6400 kernel: [ 55.093017] [] __pci_register_driver+0x66/0xd2 Sep 8 16:59:12 Insp6400 kernel: [ 55.093017] [] ? 0xffffffffa0287fff Sep 8 16:59:12 Insp6400 kernel: [ 55.093017] [] iwl3945_init+0x59/0x1000 [iwl3945] Sep 8 16:59:12 Insp6400 kernel: [ 55.093017] [] do_one_initcall+0x7f/0x13a Sep 8 16:59:12 Insp6400 kernel: [ 55.093017] [] ? 0xffffffffa0287fff Sep 8 16:59:12 Insp6400 kernel: [ 55.093017] [] sys_init_module+0x114/0x267 Sep 8 16:59:12 Insp6400 kernel: [ 55.093017] [] system_call_fastpath+0x16/0x1b Sep 8 16:59:12 Insp6400 kernel: [ 55.093017] BUG: scheduling while atomic: modprobe/516/0x10000002 Sep 8 16:59:12 Insp6400 kernel: [ 55.093017] 3 locks held by modprobe/516: Sep 8 16:59:12 Insp6400 kernel: [ 55.093017] #0: (&__lockdep_no_validate__){......}, at: [] __driver_attach+0x3b/0x82 Sep 8 16:59:12 Insp6400 kernel: [ 55.093017] #1: (&__lockdep_no_validate__){......}, at: [] __driver_attach+0x49/0x82 Sep 8 16:59:12 Insp6400 kernel: [ 55.093017] #2: (irq_mapping_update_lock){+.+.+.}, at: [] xen_bind_pirq_msi_to_irq+0x31/0xda Sep 8 16:59:12 Insp6400 kernel: [ 55.093017] Modules linked in: sparse_keymap iwl3945(+) iwl_legacy snd_timer mac80211 r852 sm_common nand snd r592 nand_ids memstick dell_laptop nand_ecc mtd b44 soundcore joydev i2c_i801 dcdbas snd_page_alloc microcode r8169 ssb cfg80211 iTCO_wdt iTCO_vendor_support mii rfkill tun xen_gntalloc xen_netback xen_blkback xen_gntdev xen_evtchn xenfs binfmt_misc sdhci_pci sdhci mmc_core firewire_ohci firewire_core crc_itu_t wmi i915 drm_kms_helper drm i2c_algo_bit i2c_core video Sep 8 16:59:12 Insp6400 kernel: [ 55.093017] Pid: 516, comm: modprobe Not tainted 3.1.0-0.rc5.git0.0.fc17.x86_64 #1 Sep 8 16:59:12 Insp6400 kernel: [ 55.093017] Call Trace: Sep 8 16:59:12 Insp6400 kernel: [ 55.093017] [] __schedule_bug+0x75/0x7a Sep 8 16:59:12 Insp6400 kernel: [ 55.093017] [] schedule+0x95/0x7bb Sep 8 16:59:12 Insp6400 kernel: [ 55.093017] [] ? show_trace_log_lvl+0x54/0x5d Sep 8 16:59:12 Insp6400 kernel: [ 55.093017] [] ? show_trace+0x15/0x17 Sep 8 16:59:12 Insp6400 kernel: [ 55.093017] [] __cond_resched+0x28/0x34 Sep 8 16:59:12 Insp6400 kernel: [ 55.093017] [] _cond_resched+0x19/0x22 Sep 8 16:59:12 Insp6400 kernel: [ 55.093017] [] mutex_lock_nested+0x2a/0x45 Sep 8 16:59:12 Insp6400 kernel: [ 55.093017] [] __irq_alloc_descs+0x50/0x18b Sep 8 16:59:12 Insp6400 kernel: [ 55.093017] [] ? kzalloc.constprop.1+0x2/0x15 Sep 8 16:59:12 Insp6400 kernel: [ 55.093017] [] xen_allocate_irq_dynamic+0x49/0x58 Sep 8 16:59:12 Insp6400 kernel: [ 55.093017] [] xen_bind_pirq_msi_to_irq+0x36/0xda Sep 8 16:59:12 Insp6400 kernel: [ 55.093017] [] xen_initdom_setup_msi_irqs+0x129/0x15d Sep 8 16:59:12 Insp6400 kernel: [ 55.093017] [] pci_enable_msi_block+0x1c0/0x225 Sep 8 16:59:12 Insp6400 kernel: [ 55.195564] [] iwl3945_pci_probe+0x6b7/0xc51 [iwl3945] Sep 8 16:59:12 Insp6400 kernel: [ 55.195564] [] local_pci_probe+0x44/0x75 Sep 8 16:59:12 Insp6400 kernel: [ 55.195564] [] pci_device_probe+0xd0/0xff Sep 8 16:59:12 Insp6400 kernel: [ 55.195564] [] driver_probe_device+0x131/0x213 Sep 8 16:59:12 Insp6400 kernel: [ 55.195564] [] __driver_attach+0x5e/0x82 Sep 8 16:59:12 Insp6400 kernel: [ 55.195564] [] ? driver_probe_device+0x213/0x213 Sep 8 16:59:12 Insp6400 kernel: [ 55.195564] [] bus_for_each_dev+0x59/0x8f Sep 8 16:59:12 Insp6400 kernel: [ 55.195564] [] driver_attach+0x1e/0x20 Sep 8 16:59:12 Insp6400 kernel: [ 55.195564] [] bus_add_driver+0xd4/0x22a Sep 8 16:59:12 Insp6400 kernel: [ 55.195564] [] ? 0xffffffffa0287fff Sep 8 16:59:12 Insp6400 kernel: [ 55.195564] [] driver_register+0x98/0x105 Sep 8 16:59:12 Insp6400 kernel: [ 55.195564] [] ? 0xffffffffa0287fff Sep 8 16:59:12 Insp6400 kernel: [ 55.195564] [] __pci_register_driver+0x66/0xd2 Sep 8 16:59:12 Insp6400 kernel: [ 55.195564] [] ? 0xffffffffa0287fff Sep 8 16:59:12 Insp6400 kernel: [ 55.195564] [] iwl3945_init+0x59/0x1000 [iwl3945] Sep 8 16:59:12 Insp6400 kernel: [ 55.195564] [] do_one_initcall+0x7f/0x13a Sep 8 16:59:12 Insp6400 kernel: [ 55.195564] [] ? 0xffffffffa0287fff Sep 8 16:59:12 Insp6400 kernel: [ 55.195564] [] sys_init_module+0x114/0x267 Sep 8 16:59:12 Insp6400 kernel: [ 55.195564] [] system_call_fastpath+0x16/0x1b Sep 8 16:59:12 Insp6400 kernel: [ 55.548175] input: Dell WMI hotkeys as /devices/virtual/input/input6 Sep 8 16:59:12 Insp6400 kernel: [ 56.324005] Adding 4063228k swap on /dev/mapper/vg_insp6400-lv_swap. Priority:0 extents:1 across:4063228k Sep 8 16:59:12 Insp6400 kernel: [ 56.817354] cfg80211: World regulatory domain updated: Sep 8 16:59:12 Insp6400 kernel: [ 56.818070] cfg80211: (start_freq - end_freq @ bandwidth), (max_antenna_gain, max_eirp) Sep 8 16:59:12 Insp6400 kernel: [ 56.818070] cfg80211: (2402000 KHz - 2472000 KHz @ 40000 KHz), (300 mBi, 2000 mBm) Sep 8 16:59:12 Insp6400 kernel: [ 56.818070] cfg80211: (2457000 KHz - 2482000 KHz @ 20000 KHz), (300 mBi, 2000 mBm) Sep 8 16:59:12 Insp6400 kernel: [ 56.818070] cfg80211: (2474000 KHz - 2494000 KHz @ 20000 KHz), (300 mBi, 2000 mBm) Sep 8 16:59:12 Insp6400 kernel: [ 56.818070] cfg80211: (5170000 KHz - 5250000 KHz @ 40000 KHz), (300 mBi, 2000 mBm) Sep 8 16:59:12 Insp6400 kernel: [ 56.818070] cfg80211: (5735000 KHz - 5835000 KHz @ 40000 KHz), (300 mBi, 2000 mBm) Sep 8 16:59:12 Insp6400 kernel: [ 57.216613] cfg80211: Calling CRDA for country: US Sep 8 16:59:12 Insp6400 kernel: [ 57.268160] xen_map_pirq_gsi: returning irq 21 for gsi 21 Sep 8 16:59:12 Insp6400 kernel: [ 57.269571] Already setup the GSI :21 Sep 8 16:59:12 Insp6400 kernel: [ 57.270549] snd_hda_intel 0000:00:1b.0: PCI INT A -> GSI 21 (level, low) -> IRQ 21 Sep 8 16:59:12 Insp6400 kernel: [ 57.273449] BUG: sleeping function called from invalid context at kernel/mutex.c:271 Sep 8 16:59:12 Insp6400 kernel: [ 57.274153] in_atomic(): 1, irqs_disabled(): 0, pid: 505, name: modprobe Sep 8 16:59:12 Insp6400 kernel: [ 57.274153] 3 locks held by modprobe/505: Sep 8 16:59:12 Insp6400 kernel: [ 57.274153] #0: (&__lockdep_no_validate__){......}, at: [] __driver_attach+0x3b/0x82 Sep 8 16:59:12 Insp6400 kernel: [ 57.274153] #1: (&__lockdep_no_validate__){......}, at: [] __driver_attach+0x49/0x82 Sep 8 16:59:12 Insp6400 kernel: [ 57.274153] #2: (irq_mapping_update_lock){+.+.+.}, at: [] xen_bind_pirq_msi_to_irq+0x31/0xda Sep 8 16:59:12 Insp6400 kernel: [ 57.274153] Pid: 505, comm: modprobe Not tainted 3.1.0-0.rc5.git0.0.fc17.x86_64 #1 Sep 8 16:59:12 Insp6400 kernel: [ 57.274153] Call Trace: Sep 8 16:59:12 Insp6400 kernel: [ 57.274153] [] __might_sleep+0x103/0x108 Sep 8 16:59:12 Insp6400 kernel: [ 57.274153] [] mutex_lock_nested+0x25/0x45 Sep 8 16:59:12 Insp6400 kernel: [ 57.274153] [] __irq_alloc_descs+0x50/0x18b Sep 8 16:59:12 Insp6400 kernel: [ 57.274153] [] ? kzalloc.constprop.1+0x2/0x15 Sep 8 16:59:12 Insp6400 kernel: [ 57.291640] [] xen_allocate_irq_dynamic+0x49/0x58 Sep 8 16:59:12 Insp6400 kernel: [ 57.292557] [] xen_bind_pirq_msi_to_irq+0x36/0xda Sep 8 16:59:12 Insp6400 kernel: [ 57.292557] [] xen_initdom_setup_msi_irqs+0x129/0x15d Sep 8 16:59:12 Insp6400 kernel: [ 57.292557] [] pci_enable_msi_block+0x1c0/0x225 Sep 8 16:59:12 Insp6400 kernel: [ 57.292557] [] azx_probe+0x437/0x982 [snd_hda_intel] Sep 8 16:59:12 Insp6400 kernel: [ 57.292557] [] local_pci_probe+0x44/0x75 Sep 8 16:59:12 Insp6400 kernel: [ 57.292557] [] pci_device_probe+0xd0/0xff Sep 8 16:59:12 Insp6400 kernel: [ 57.292557] [] driver_probe_device+0x131/0x213 Sep 8 16:59:12 Insp6400 kernel: [ 57.292557] [] __driver_attach+0x5e/0x82 Sep 8 16:59:12 Insp6400 kernel: [ 57.292557] [] ? driver_probe_device+0x213/0x213 Sep 8 16:59:12 Insp6400 kernel: [ 57.292557] [] bus_for_each_dev+0x59/0x8f Sep 8 16:59:12 Insp6400 kernel: [ 57.292557] [] driver_attach+0x1e/0x20 Sep 8 16:59:12 Insp6400 kernel: [ 57.292557] [] bus_add_driver+0xd4/0x22a Sep 8 16:59:12 Insp6400 kernel: [ 57.292557] [] ? 0xffffffffa0326fff Sep 8 16:59:12 Insp6400 kernel: [ 57.292557] [] driver_register+0x98/0x105 Sep 8 16:59:12 Insp6400 kernel: [ 57.292557] [] ? 0xffffffffa0326fff Sep 8 16:59:12 Insp6400 kernel: [ 57.292557] [] __pci_register_driver+0x66/0xd2 Sep 8 16:59:12 Insp6400 kernel: [ 57.292557] [] ? 0xffffffffa0326fff Sep 8 16:59:12 Insp6400 kernel: [ 57.292557] [] alsa_card_azx_init+0x1e/0x1000 [snd_hda_intel] Sep 8 16:59:12 Insp6400 kernel: [ 57.292557] [] do_one_initcall+0x7f/0x13a Sep 8 16:59:12 Insp6400 kernel: [ 57.292557] [] ? 0xffffffffa0326fff Sep 8 16:59:12 Insp6400 kernel: [ 57.292557] [] sys_init_module+0x114/0x267 Sep 8 16:59:12 Insp6400 kernel: [ 57.292557] [] system_call_fastpath+0x16/0x1b Sep 8 16:59:12 Insp6400 kernel: [ 57.292557] BUG: scheduling while atomic: modprobe/505/0x10000002 Sep 8 16:59:12 Insp6400 kernel: [ 57.292557] 3 locks held by modprobe/505: Sep 8 16:59:12 Insp6400 kernel: [ 57.292557] #0: (&__lockdep_no_validate__){......}, at: [] __driver_attach+0x3b/0x82 Sep 8 16:59:12 Insp6400 kernel: [ 57.292557] #1: (&__lockdep_no_validate__){......}, at: [] __driver_attach+0x49/0x82 Sep 8 16:59:12 Insp6400 kernel: [ 57.292557] #2: (irq_mapping_update_lock){+.+.+.}, at: [] xen_bind_pirq_msi_to_irq+0x31/0xda Sep 8 16:59:12 Insp6400 kernel: [ 57.292557] Modules linked in: snd_hda_intel(+) snd_hda_codec snd_hwdep snd_seq snd_seq_device snd_pcm dell_wmi arc4 sparse_keymap iwl3945 iwl_legacy snd_timer mac80211 r852 sm_common nand snd r592 nand_ids memstick dell_laptop nand_ecc mtd b44 soundcore joydev i2c_i801 dcdbas snd_page_alloc microcode r8169 ssb cfg80211 iTCO_wdt iTCO_vendor_support mii rfkill tun xen_gntalloc xen_netback xen_blkback xen_gntdev xen_evtchn xenfs binfmt_misc sdhci_pci sdhci mmc_core firewire_ohci firewire_core crc_itu_t wmi i915 drm_kms_helper drm i2c_algo_bit i2c_core video Sep 8 16:59:12 Insp6400 kernel: [ 57.292557] Pid: 505, comm: modprobe Not tainted 3.1.0-0.rc5.git0.0.fc17.x86_64 #1 Sep 8 16:59:12 Insp6400 kernel: [ 57.292557] Call Trace: Sep 8 16:59:12 Insp6400 kernel: [ 57.292557] [] __schedule_bug+0x75/0x7a Sep 8 16:59:12 Insp6400 kernel: [ 57.292557] [] schedule+0x95/0x7bb Sep 8 16:59:12 Insp6400 kernel: [ 57.292557] [] ? show_trace_log_lvl+0x54/0x5d Sep 8 16:59:12 Insp6400 kernel: [ 57.292557] [] ? show_trace+0x15/0x17 Sep 8 16:59:12 Insp6400 kernel: [ 57.292557] [] __cond_resched+0x28/0x34 Sep 8 16:59:12 Insp6400 kernel: [ 57.292557] [] _cond_resched+0x19/0x22 Sep 8 16:59:12 Insp6400 kernel: [ 57.292557] [] mutex_lock_nested+0x2a/0x45 Sep 8 16:59:12 Insp6400 kernel: [ 57.292557] [] __irq_alloc_descs+0x50/0x18b Sep 8 16:59:12 Insp6400 kernel: [ 57.292557] [] ? kzalloc.constprop.1+0x2/0x15 Sep 8 16:59:12 Insp6400 kernel: [ 57.292557] [] xen_allocate_irq_dynamic+0x49/0x58 Sep 8 16:59:12 Insp6400 kernel: [ 57.292557] [] xen_bind_pirq_msi_to_irq+0x36/0xda Sep 8 16:59:12 Insp6400 kernel: [ 57.292557] [] xen_initdom_setup_msi_irqs+0x129/0x15d Sep 8 16:59:12 Insp6400 kernel: [ 57.292557] [] pci_enable_msi_block+0x1c0/0x225 Sep 8 16:59:12 Insp6400 kernel: [ 57.292557] [] azx_probe+0x437/0x982 [snd_hda_intel] Sep 8 16:59:12 Insp6400 kernel: [ 57.292557] [] local_pci_probe+0x44/0x75 Sep 8 16:59:12 Insp6400 kernel: [ 57.292557] [] pci_device_probe+0xd0/0xff Sep 8 16:59:12 Insp6400 kernel: [ 57.292557] [] driver_probe_device+0x131/0x213 Sep 8 16:59:12 Insp6400 kernel: [ 57.292557] [] __driver_attach+0x5e/0x82 Sep 8 16:59:12 Insp6400 kernel: [ 57.292557] [] ? driver_probe_device+0x213/0x213 Sep 8 16:59:12 Insp6400 kernel: [ 57.292557] [] bus_for_each_dev+0x59/0x8f Sep 8 16:59:12 Insp6400 kernel: [ 57.292557] [] driver_attach+0x1e/0x20 Sep 8 16:59:12 Insp6400 kernel: [ 57.292557] [] bus_add_driver+0xd4/0x22a Sep 8 16:59:12 Insp6400 kernel: [ 57.292557] [] ? 0xffffffffa0326fff Sep 8 16:59:12 Insp6400 kernel: [ 57.292557] [] driver_register+0x98/0x105 Sep 8 16:59:12 Insp6400 kernel: [ 57.292557] [] ? 0xffffffffa0326fff Sep 8 16:59:12 Insp6400 kernel: [ 57.292557] [] __pci_register_driver+0x66/0xd2 Sep 8 16:59:12 Insp6400 kernel: [ 57.292557] [] ? 0xffffffffa0326fff Sep 8 16:59:12 Insp6400 kernel: [ 57.292557] [] alsa_card_azx_init+0x1e/0x1000 [snd_hda_intel] Sep 8 16:59:12 Insp6400 kernel: [ 57.292557] [] do_one_initcall+0x7f/0x13a Sep 8 16:59:12 Insp6400 kernel: [ 57.292557] [] ? 0xffffffffa0326fff Sep 8 16:59:12 Insp6400 kernel: [ 57.292557] [] sys_init_module+0x114/0x267 Sep 8 16:59:12 Insp6400 kernel: [ 57.292557] [] system_call_fastpath+0x16/0x1b Sep 8 16:59:12 Insp6400 kernel: [ 57.394726] BUG: spinlock wrong CPU on CPU#1, modprobe/505 Sep 8 16:59:12 Insp6400 kernel: [ 57.395079] lock: ffffffff81a7de60, .magic: dead4ead, .owner: modprobe/505, .owner_cpu: 0 Sep 8 16:59:12 Insp6400 kernel: [ 57.395079] Pid: 505, comm: modprobe Not tainted 3.1.0-0.rc5.git0.0.fc17.x86_64 #1 Sep 8 16:59:12 Insp6400 kernel: [ 57.395079] Call Trace: Sep 8 16:59:12 Insp6400 kernel: [ 57.395079] [] spin_bug+0xa3/0xab Sep 8 16:59:12 Insp6400 kernel: [ 57.395079] [] do_raw_spin_unlock+0x75/0x8b Sep 8 16:59:12 Insp6400 kernel: [ 57.395079] [] _raw_spin_unlock+0x28/0x3b Sep 8 16:59:12 Insp6400 kernel: [ 57.395079] [] xen_bind_pirq_msi_to_irq+0xae/0xda Sep 8 16:59:12 Insp6400 kernel: [ 57.395079] [] xen_initdom_setup_msi_irqs+0x129/0x15d Sep 8 16:59:12 Insp6400 kernel: [ 57.409377] [] pci_enable_msi_block+0x1c0/0x225 Sep 8 16:59:12 Insp6400 kernel: [ 57.409377] [] azx_probe+0x437/0x982 [snd_hda_intel] Sep 8 16:59:12 Insp6400 kernel: [ 57.409377] [] local_pci_probe+0x44/0x75 Sep 8 16:59:12 Insp6400 kernel: [ 57.409377] [] pci_device_probe+0xd0/0xff Sep 8 16:59:12 Insp6400 kernel: [ 57.409377] [] driver_probe_device+0x131/0x213 Sep 8 16:59:12 Insp6400 kernel: [ 57.409377] [] __driver_attach+0x5e/0x82 Sep 8 16:59:12 Insp6400 kernel: [ 57.409377] [] ? driver_probe_device+0x213/0x213 Sep 8 16:59:12 Insp6400 kernel: [ 57.409377] [] bus_for_each_dev+0x59/0x8f Sep 8 16:59:12 Insp6400 kernel: [ 57.419915] cfg80211: Regulatory domain changed to country: US Sep 8 16:59:12 Insp6400 kernel: [ 57.419919] cfg80211: (start_freq - end_freq @ bandwidth), (max_antenna_gain, max_eirp) Sep 8 16:59:12 Insp6400 kernel: [ 57.419924] cfg80211: (2402000 KHz - 2472000 KHz @ 40000 KHz), (300 mBi, 2700 mBm) Sep 8 16:59:12 Insp6400 kernel: [ 57.419927] cfg80211: (5170000 KHz - 5250000 KHz @ 40000 KHz), (300 mBi, 1700 mBm) Sep 8 16:59:12 Insp6400 kernel: [ 57.419931] cfg80211: (5250000 KHz - 5330000 KHz @ 40000 KHz), (300 mBi, 2000 mBm) Sep 8 16:59:12 Insp6400 kernel: [ 57.419935] cfg80211: (5490000 KHz - 5600000 KHz @ 40000 KHz), (300 mBi, 2000 mBm) Sep 8 16:59:12 Insp6400 kernel: [ 57.419939] cfg80211: (5650000 KHz - 5710000 KHz @ 40000 KHz), (300 mBi, 2000 mBm) Sep 8 16:59:12 Insp6400 kernel: [ 57.419942] cfg80211: (5735000 KHz - 5835000 KHz @ 40000 KHz), (300 mBi, 3000 mBm) Sep 8 16:59:12 Insp6400 kernel: [ 57.409377] [] driver_attach+0x1e/0x20 Sep 8 16:59:12 Insp6400 kernel: [ 57.409377] [] bus_add_driver+0xd4/0x22a Sep 8 16:59:12 Insp6400 kernel: [ 57.409377] [] ? 0xffffffffa0326fff Sep 8 16:59:12 Insp6400 kernel: [ 57.409377] [] driver_register+0x98/0x105 Sep 8 16:59:12 Insp6400 kernel: [ 57.409377] [] ? 0xffffffffa0326fff Sep 8 16:59:12 Insp6400 kernel: [ 57.409377] [] __pci_register_driver+0x66/0xd2 Sep 8 16:59:12 Insp6400 kernel: [ 57.409377] [] ? 0xffffffffa0326fff Sep 8 16:59:12 Insp6400 kernel: [ 57.409377] [] alsa_card_azx_init+0x1e/0x1000 [snd_hda_intel] Sep 8 16:59:12 Insp6400 kernel: [ 57.409377] [] do_one_initcall+0x7f/0x13a Sep 8 16:59:12 Insp6400 kernel: [ 57.409377] [] ? 0xffffffffa0326fff Sep 8 16:59:12 Insp6400 kernel: [ 57.409377] [] sys_init_module+0x114/0x267 Sep 8 16:59:12 Insp6400 kernel: [ 57.409377] [] system_call_fastpath+0x16/0x1b Sep 8 16:59:12 Insp6400 kernel: [ 57.621754] input: HDA Intel Mic at Ext Right Jack as /devices/pci0000:00/0000:00:1b.0/sound/card0/input7 Sep 8 16:59:12 Insp6400 kernel: [ 57.636306] input: HDA Intel HP Out at Ext Right Jack as /devices/pci0000:00/0000:00:1b.0/sound/card0/input8 Sep 8 16:59:12 Insp6400 kernel: [ 58.445701] EXT4-fs (sda2): mounting ext3 file system using the ext4 subsystem Sep 8 16:59:12 Insp6400 kernel: [ 58.497772] EXT4-fs (sda2): mounted filesystem with ordered data mode. Opts: (null) Sep 8 16:59:12 Insp6400 kernel: [ 64.030601] ip6_tables: (C) 2000-2006 Netfilter Core Team Sep 8 16:59:12 Insp6400 kernel: [ 65.208998] Loading iSCSI transport class v2.0-870. Sep 8 16:59:12 Insp6400 kernel: [ 65.232872] nf_conntrack version 0.5.0 (16384 buckets, 65536 max) Sep 8 16:59:12 Insp6400 kernel: [ 65.862081] iscsi: registered transport (tcp) Sep 8 16:59:13 Insp6400 kernel: [ 67.636361] iscsi: registered transport (iser) Sep 8 16:59:15 Insp6400 dbus: avc: netlink poll: error 4 Sep 8 16:59:16 Insp6400 abrtd: Init complete, entering main loop Sep 8 16:59:16 Insp6400 avahi-daemon[755]: Successfully called chroot(). Sep 8 16:59:16 Insp6400 avahi-daemon[755]: Successfully dropped remaining capabilities. Sep 8 16:59:16 Insp6400 avahi-daemon[755]: Loading service file /services/ssh.service. Sep 8 16:59:16 Insp6400 kernel: [ 70.153389] libcxgbi:libcxgbi_init_module: tag itt 0x1fff, 13 bits, age 0xf, 4 bits. Sep 8 16:59:16 Insp6400 kernel: [ 70.154133] libcxgbi:ddp_setup_host_page_size: system PAGE 4096, ddp idx 0. Sep 8 16:59:16 Insp6400 avahi-daemon[755]: Loading service file /services/udisks.service. Sep 8 16:59:16 Insp6400 avahi-daemon[755]: Network interface enumeration completed. Sep 8 16:59:16 Insp6400 avahi-daemon[755]: Registering HINFO record with values 'X86_64'/'LINUX'. Sep 8 16:59:16 Insp6400 avahi-daemon[755]: Server startup complete. Host name is insp6400.local. Local service cookie is 1645585705. Sep 8 16:59:16 Insp6400 avahi-daemon[755]: Service "insp6400" (/services/udisks.service) successfully established. Sep 8 16:59:16 Insp6400 avahi-daemon[755]: Service "insp6400" (/services/ssh.service) successfully established. Sep 8 16:59:16 Insp6400 kernel: [ 70.277955] Chelsio T3 iSCSI Driver cxgb3i v2.0.0 (Jun. 2010) Sep 8 16:59:16 Insp6400 kernel: [ 70.280171] iscsi: registered transport (cxgb3i) Sep 8 16:59:16 Insp6400 kernel: [ 70.533004] cnic: Broadcom NetXtreme II CNIC Driver cnic v2.5.7 (July 20, 2011) Sep 8 16:59:16 Insp6400 kernel: [ 70.597280] Broadcom NetXtreme II iSCSI Driver bnx2i v2.7.0.3 (Jun 15, 2011) Sep 8 16:59:16 Insp6400 kernel: [ 70.616921] iscsi: registered transport (bnx2i) Sep 8 16:59:16 Insp6400 kernel: [ 70.807620] iscsi: registered transport (be2iscsi) Sep 8 16:59:17 Insp6400 iscsid: iSCSI logger with pid=908 started! Sep 8 16:59:17 Insp6400 kernel: [ 71.418730] iscsid (909): /proc/909/oom_adj is deprecated, please use /proc/909/oom_score_adj instead. Sep 8 16:59:18 Insp6400 iscsid: transport class version 2.0-870. iscsid version 2.0-872 Sep 8 16:59:18 Insp6400 iscsid: iSCSI daemon with pid=909 started! Sep 8 16:59:21 Insp6400 kernel: [ 75.137582] bonding: Ethernet Channel Bonding Driver: v3.7.1 (April 27, 2011) Sep 8 16:59:21 Insp6400 kernel: [ 75.181503] bonding: bond0 is being created... Sep 8 16:59:21 Insp6400 kernel: [ 75.184019] bonding: bond0 already exists. Sep 8 16:59:21 Insp6400 kernel: [ 75.470879] bonding: bond0: setting mode to balance-tlb (5). Sep 8 16:59:21 Insp6400 kernel: [ 75.473430] bonding: bond0: Setting MII monitoring interval to 5. Sep 8 16:59:21 Insp6400 kernel: [ 75.475896] bonding: bond0: Setting down delay to 2000. Sep 8 16:59:21 Insp6400 kernel: [ 75.494222] ADDRCONF(NETDEV_UP): bond0: link is not ready Sep 8 16:59:21 Insp6400 kernel: [ 75.832493] bonding: bond0: Adding slave eth0. Sep 8 16:59:21 Insp6400 kernel: [ 75.848342] bonding: bond0: enslaving eth0 as an active interface with a down link. Sep 8 16:59:22 Insp6400 kernel: [ 76.117901] bonding: bond0: Adding slave eth1. Sep 8 16:59:22 Insp6400 kernel: [ 76.250834] r8169 0000:0c:00.0: eth1: link down Sep 8 16:59:22 Insp6400 kernel: [ 76.251060] r8169 0000:0c:00.0: eth1: link down Sep 8 16:59:22 Insp6400 kernel: [ 76.257039] bonding: bond0: enslaving eth1 as an active interface with a down link. Sep 8 16:59:22 Insp6400 kernel: [ 76.460299] Bridge firewalling registered Sep 8 16:59:22 Insp6400 kernel: [ 76.535875] device bond0 entered promiscuous mode Sep 8 16:59:23 Insp6400 kernel: [ 77.187656] ADDRCONF(NETDEV_UP): xenbr0: link is not ready Sep 8 16:59:24 Insp6400 kernel: [ 78.680876] r8169 0000:0c:00.0: eth1: link up Sep 8 16:59:24 Insp6400 kernel: [ 78.685920] bonding: bond0: link status definitely up for interface eth1, 1000 Mbps full duplex. Sep 8 16:59:24 Insp6400 kernel: [ 78.686063] bonding: bond0: making interface eth1 the new active one. Sep 8 16:59:24 Insp6400 kernel: [ 78.686063] device eth1 entered promiscuous mode Sep 8 16:59:24 Insp6400 kernel: [ 78.692304] bonding: bond0: first active interface up! Sep 8 16:59:24 Insp6400 kernel: [ 78.694863] ADDRCONF(NETDEV_CHANGE): bond0: link becomes ready Sep 8 16:59:24 Insp6400 kernel: [ 78.697756] xenbr0: port 1(bond0) entering forwarding state Sep 8 16:59:24 Insp6400 kernel: [ 78.698140] xenbr0: port 1(bond0) entering forwarding state Sep 8 16:59:24 Insp6400 kernel: [ 78.702807] ADDRCONF(NETDEV_CHANGE): xenbr0: link becomes ready Sep 8 16:59:24 Insp6400 kernel: [ 78.704820] b44 ssb0:0: eth0: Link is up at 100 Mbps, full duplex Sep 8 16:59:24 Insp6400 kernel: [ 78.705626] b44 ssb0:0: eth0: Flow control is off for TX and off for RX Sep 8 16:59:24 Insp6400 kernel: [ 78.709983] bonding: bond0: link status definitely up for interface eth0, 100 Mbps full duplex. Sep 8 16:59:25 Insp6400 avahi-daemon[755]: Registering new address record for fe80::215:c5ff:fe04:7d4f on bond0.*. Sep 8 16:59:26 Insp6400 dhclient[1579]: DHCPREQUEST on xenbr0 to 255.255.255.255 port 67 Sep 8 16:59:26 Insp6400 dhclient[1579]: DHCPACK from 192.168.1.1 Sep 8 16:59:26 Insp6400 avahi-daemon[755]: Joining mDNS multicast group on interface xenbr0.IPv4 with address 192.168.1.100. Sep 8 16:59:26 Insp6400 avahi-daemon[755]: New relevant interface xenbr0.IPv4 for mDNS. Sep 8 16:59:26 Insp6400 avahi-daemon[755]: Registering new address record for 192.168.1.100 on xenbr0.IPv4. Sep 8 16:59:26 Insp6400 avahi-daemon[755]: Registering new address record for fe80::215:c5ff:fe04:7d4f on xenbr0.*. Sep 8 16:59:26 Insp6400 NET[1788]: /sbin/dhclient-script : updated /etc/resolv.conf Sep 8 16:59:27 Insp6400 dhclient[1579]: bound to 192.168.1.100 -- renewal in 65745 seconds. Sep 8 16:59:28 Insp6400 kernel: [ 82.661777] FS-Cache: Loaded Sep 8 16:59:28 Insp6400 kernel: [ 82.758652] FS-Cache: Netfs 'cifs' registered for caching Sep 8 16:59:28 Insp6400 kernel: [ 82.867310] CIFS VFS: default security mechanism requested. The default security mechanism will be upgraded from ntlm to ntlmv2 in kernel release 3.1 Sep 8 16:59:34 Insp6400 ntpdate[1977]: step time server 67.18.208.240 offset 0.453408 sec Sep 8 16:59:34 Insp6400 ntpd[2153]: ntpd 4.2.6p3@1.2290-o Fri May 6 16:26:49 UTC 2011 (1) Sep 8 16:59:34 Insp6400 ntpd[2153]: proto: precision = 1.720 usec Sep 8 16:59:34 Insp6400 ntpd[2153]: 0.0.0.0 c01d 0d kern kernel time sync enabled Sep 8 16:59:34 Insp6400 ntpd[2153]: Listen and drop on 0 v4wildcard 0.0.0.0 UDP 123 Sep 8 16:59:34 Insp6400 ntpd[2153]: Listen and drop on 1 v6wildcard :: UDP 123 Sep 8 16:59:34 Insp6400 ntpd[2153]: Listen normally on 2 lo 127.0.0.1 UDP 123 Sep 8 16:59:34 Insp6400 ntpd[2153]: Listen normally on 3 xenbr0 192.168.1.100 UDP 123 Sep 8 16:59:34 Insp6400 ntpd[2153]: Listen normally on 4 xenbr0 fe80::215:c5ff:fe04:7d4f UDP 123 Sep 8 16:59:34 Insp6400 ntpd[2153]: Listen normally on 5 bond0 fe80::215:c5ff:fe04:7d4f UDP 123 Sep 8 16:59:34 Insp6400 ntpd[2153]: Listen normally on 6 lo ::1 UDP 123 Sep 8 16:59:34 Insp6400 ntpd[2153]: peers refreshed Sep 8 16:59:34 Insp6400 ntpd[2153]: Listening on routing socket on fd #23 for interface updates Sep 8 16:59:36 Insp6400 ntpd[2153]: 0.0.0.0 c016 06 restart Sep 8 16:59:36 Insp6400 ntpd[2153]: 0.0.0.0 c012 02 freq_set kernel 1.500 PPM Sep 8 16:59:50 Insp6400 auditd[2741]: Started dispatcher: /sbin/audispd pid: 2743 Sep 8 16:59:50 Insp6400 auditd[2741]: Init complete, auditd 2.1.3 listening for events (startup state enable) Sep 8 16:59:50 Insp6400 audispd: audispd initialized with q_depth=120 and 1 active plugins Sep 8 16:59:51 Insp6400 kernel: [ 104.683571] scsi2 : iSCSI Initiator over TCP/IP Sep 8 16:59:51 Insp6400 kernel: [ 105.119216] scsi 2:0:0:0: RAID IET Controller 0001 PQ: 0 ANSI: 5 Sep 8 16:59:51 Insp6400 kernel: [ 105.163374] scsi 2:0:0:0: Attached scsi generic sg2 type 12 Sep 8 16:59:51 Insp6400 kernel: [ 105.182535] scsi 2:0:0:1: Direct-Access IET VIRTUAL-DISK 0001 PQ: 0 ANSI: 5 Sep 8 16:59:51 Insp6400 kernel: [ 105.195288] sd 2:0:0:1: [sdb] 312581808 512-byte logical blocks: (160 GB/149 GiB) Sep 8 16:59:51 Insp6400 kernel: [ 105.201707] sd 2:0:0:1: [sdb] Write Protect is off Sep 8 16:59:51 Insp6400 kernel: [ 105.213193] sd 2:0:0:1: Attached scsi generic sg3 type 0 Sep 8 16:59:51 Insp6400 kernel: [ 105.219746] sd 2:0:0:1: [sdb] Write cache: enabled, read cache: enabled, doesn't support DPO or FUA Sep 8 16:59:51 Insp6400 iscsid: Connection1:0 to [target: iqn.2001-04.com.Dell4550-iqn.2009-09.net.bellsouth.sda:041b7d3f-b008-4367-b1f2-b4799d15e4cd, portal: 192.168.1.101,3260] through [iface: default] is operational now Sep 8 16:59:51 Insp6400 kernel: [ 105.266929] sdb: sdb1 sdb2 sdb3 Sep 8 16:59:51 Insp6400 kernel: [ 105.280033] sd 2:0:0:1: [sdb] Attached SCSI disk Sep 8 16:59:52 Insp6400 kernel: [ 106.571909] iwl3945 0000:0b:00.0: loaded firmware version 15.32.2.9 Sep 8 16:59:53 Insp6400 kernel: [ 106.794916] ADDRCONF(NETDEV_UP): wlan0: link is not ready Sep 8 16:59:53 Insp6400 rpc.statd[2928]: Version 1.2.4 starting Sep 8 16:59:54 Insp6400 sm-notify[2933]: Version 1.2.4 starting Sep 8 16:59:55 Insp6400 kernel: [ 108.705060] RPC: Registered named UNIX socket transport module. Sep 8 16:59:55 Insp6400 kernel: [ 108.705060] RPC: Registered udp transport module. Sep 8 16:59:55 Insp6400 kernel: [ 108.705060] RPC: Registered tcp transport module. Sep 8 16:59:55 Insp6400 kernel: [ 108.705060] RPC: Registered tcp NFSv4.1 backchannel transport module. Sep 8 16:59:55 Insp6400 kernel: [ 108.933995] Installing knfsd (copyright (C) 1996 okir@monad.swb.de). Sep 8 16:59:56 Insp6400 kernel: [ 109.739661] ADDRCONF(NETDEV_CHANGE): wlan0: link becomes ready Sep 8 16:59:56 Insp6400 kernel: [ 109.896771] NFSD: Using /var/lib/nfs/v4recovery as the NFSv4 state recovery directory Sep 8 16:59:56 Insp6400 kernel: [ 109.916136] NFSD: starting 90-second grace period Sep 8 16:59:56 Insp6400 rpc.mountd[3018]: Version 1.2.4 starting Sep 8 16:59:57 Insp6400 avahi-daemon[755]: Registering new address record for fe80::213:2ff:fe1a:f185 on wlan0.*. Sep 8 16:59:57 Insp6400 systemd[1]: avguard.service: control process exited, code=exited status=2 Sep 8 16:59:57 Insp6400 systemd[1]: Unit avguard.service entered failed state. Sep 8 16:59:58 Insp6400 ntpd[2153]: Listen normally on 7 wlan0 fe80::213:2ff:fe1a:f185 UDP 123 Sep 8 16:59:58 Insp6400 ntpd[2153]: peers refreshed Sep 8 17:00:02 Insp6400 kernel: [ 116.591656] xen-pciback: backend is vpci Sep 8 17:00:03 Insp6400 xenstored: Checking store ... Sep 8 17:00:03 Insp6400 xenstored: Checking store complete. Sep 8 17:00:03 Insp6400 kernel: [ 116.911469] BUG: sleeping function called from invalid context at kernel/mutex.c:271 Sep 8 17:00:03 Insp6400 kernel: [ 116.912065] in_atomic(): 1, irqs_disabled(): 0, pid: 3208, name: xenstored Sep 8 17:00:03 Insp6400 kernel: [ 116.912065] INFO: lockdep is turned off. Sep 8 17:00:03 Insp6400 kernel: [ 116.912065] Pid: 3208, comm: xenstored Not tainted 3.1.0-0.rc5.git0.0.fc17.x86_64 #1 Sep 8 17:00:03 Insp6400 kernel: [ 116.912065] Call Trace: Sep 8 17:00:03 Insp6400 kernel: [ 116.912065] [] __might_sleep+0x103/0x108 Sep 8 17:00:03 Insp6400 kernel: [ 116.912065] [] mutex_lock_nested+0x25/0x45 Sep 8 17:00:03 Insp6400 kernel: [ 116.912065] [] __irq_alloc_descs+0x50/0x18b Sep 8 17:00:03 Insp6400 kernel: [ 116.912065] [] ? pnp_register_protocol+0x39/0xb4 Sep 8 17:00:03 Insp6400 kernel: [ 116.912065] [] xen_allocate_irq_dynamic+0x49/0x58 Sep 8 17:00:03 Insp6400 kernel: [ 116.912065] [] bind_evtchn_to_irq+0x32/0x82 Sep 8 17:00:03 Insp6400 kernel: [ 116.912065] [] bind_evtchn_to_irqhandler+0x25/0x63 Sep 8 17:00:03 Insp6400 kernel: [ 116.912065] [] ? set_port_enabled+0x31/0x31 [xen_evtchn] Sep 8 17:00:03 Insp6400 kernel: [ 116.912065] [] evtchn_bind_to_user+0x56/0x64 [xen_evtchn] Sep 8 17:00:03 Insp6400 kernel: [ 116.912065] [] evtchn_ioctl+0x129/0x2ef [xen_evtchn] Sep 8 17:00:03 Insp6400 kernel: [ 116.912065] [] do_vfs_ioctl+0x472/0x4b3 Sep 8 17:00:03 Insp6400 kernel: [ 116.912065] [] sys_ioctl+0x56/0x7a Sep 8 17:00:03 Insp6400 kernel: [ 116.912065] [] system_call_fastpath+0x16/0x1b Sep 8 17:00:03 Insp6400 kernel: [ 116.946247] XENBUS: Unable to read cpu state Sep 8 17:00:03 Insp6400 kernel: [ 116.949075] XENBUS: Unable to read cpu state Sep 8 17:00:03 Insp6400 kernel: [ 116.966668] cfg80211: Calling CRDA to update world regulatory domain Sep 8 17:00:03 Insp6400 avahi-daemon[755]: Withdrawing address record for fe80::213:2ff:fe1a:f185 on wlan0. Sep 8 17:00:03 Insp6400 avahi-daemon[755]: Withdrawing workstation service for wlan0. Sep 8 17:00:03 Insp6400 kernel: [ 117.137705] iwl3945 0000:0b:00.0: PCI INT A disabled Sep 8 17:00:03 Insp6400 kernel: [ 117.142092] pciback 0000:0b:00.0: seizing device Sep 8 17:00:03 Insp6400 kernel: [ 117.146295] xen_map_pirq_gsi: returning irq 16 for gsi 16 Sep 8 17:00:03 Insp6400 kernel: [ 117.149952] Already setup the GSI :16 Sep 8 17:00:03 Insp6400 kernel: [ 117.150936] pciback 0000:0b:00.0: PCI INT A -> GSI 16 (level, low) -> IRQ 16 Sep 8 17:00:03 Insp6400 kernel: [ 117.150936] pciback 0000:0b:00.0: PCI INT A disabled Sep 8 17:00:03 Insp6400 smbd[3172]: [2011/09/08 17:00:03.572080, 0] smbd/server.c:501(smbd_open_one_socket) Sep 8 17:00:03 Insp6400 smbd[3172]: smbd_open_once_socket: open_socket_in: Address already in use Sep 8 17:00:03 Insp6400 smbd[3172]: [2011/09/08 17:00:03.581039, 0] smbd/server.c:501(smbd_open_one_socket) Sep 8 17:00:03 Insp6400 smbd[3172]: smbd_open_once_socket: open_socket_in: Address already in use Sep 8 17:00:03 Insp6400 kernel: [ 117.385355] cfg80211: World regulatory domain updated: Sep 8 17:00:03 Insp6400 kernel: [ 117.386066] cfg80211: (start_freq - end_freq @ bandwidth), (max_antenna_gain, max_eirp) Sep 8 17:00:03 Insp6400 kernel: [ 117.386066] cfg80211: (2402000 KHz - 2472000 KHz @ 40000 KHz), (300 mBi, 2000 mBm) Sep 8 17:00:03 Insp6400 kernel: [ 117.386066] cfg80211: (2457000 KHz - 2482000 KHz @ 20000 KHz), (300 mBi, 2000 mBm) Sep 8 17:00:03 Insp6400 kernel: [ 117.386066] cfg80211: (2474000 KHz - 2494000 KHz @ 20000 KHz), (300 mBi, 2000 mBm) Sep 8 17:00:03 Insp6400 kernel: [ 117.386066] cfg80211: (5170000 KHz - 5250000 KHz @ 40000 KHz), (300 mBi, 2000 mBm) Sep 8 17:00:03 Insp6400 kernel: [ 117.386066] cfg80211: (5735000 KHz - 5835000 KHz @ 40000 KHz), (300 mBi, 2000 mBm) Sep 8 17:00:03 Insp6400 kernel: [ 117.398125] cfg80211: Calling CRDA for country: US Sep 8 17:00:03 Insp6400 kernel: [ 117.529792] cfg80211: Regulatory domain changed to country: US Sep 8 17:00:03 Insp6400 kernel: [ 117.530194] cfg80211: (start_freq - end_freq @ bandwidth), (max_antenna_gain, max_eirp) Sep 8 17:00:03 Insp6400 kernel: [ 117.530194] cfg80211: (2402000 KHz - 2472000 KHz @ 40000 KHz), (300 mBi, 2700 mBm) Sep 8 17:00:03 Insp6400 kernel: [ 117.530194] cfg80211: (5170000 KHz - 5250000 KHz @ 40000 KHz), (300 mBi, 1700 mBm) Sep 8 17:00:03 Insp6400 kernel: [ 117.530194] cfg80211: (5250000 KHz - 5330000 KHz @ 40000 KHz), (300 mBi, 2000 mBm) Sep 8 17:00:03 Insp6400 kernel: [ 117.530194] cfg80211: (5490000 KHz - 5600000 KHz @ 40000 KHz), (300 mBi, 2000 mBm) Sep 8 17:00:03 Insp6400 kernel: [ 117.530194] cfg80211: (5650000 KHz - 5710000 KHz @ 40000 KHz), (300 mBi, 2000 mBm) Sep 8 17:00:03 Insp6400 kernel: [ 117.530194] cfg80211: (5735000 KHz - 5835000 KHz @ 40000 KHz), (300 mBi, 3000 mBm) Sep 8 17:00:04 Insp6400 ntpd[2153]: Deleting interface #7 wlan0, fe80::213:2ff:fe1a:f185#123, interface stats: received=0, sent=0, dropped=0, active_time=6 secs Sep 8 17:00:04 Insp6400 ntpd[2153]: peers refreshed Sep 8 17:00:07 Insp6400 systemd[1]: vncserver.service: control process exited, code=exited status=2 Sep 8 17:00:08 Insp6400 systemd[1]: Unit vncserver.service entered failed state. Sep 8 17:00:15 Insp6400 dbus: [system] Activating via systemd: service name='org.freedesktop.ConsoleKit' unit='console-kit-daemon.service' Sep 8 17:00:16 Insp6400 dbus: [system] Activating service name='org.freedesktop.PolicyKit1' (using servicehelper) Sep 8 17:00:16 Insp6400 polkitd[3467]: started daemon version 0.101 using authority implementation `local' version `0.101' Sep 8 17:00:16 Insp6400 dbus: [system] Successfully activated service 'org.freedesktop.PolicyKit1' Sep 8 17:00:16 Insp6400 dbus: [system] Successfully activated service 'org.freedesktop.ConsoleKit' Sep 8 17:00:25 Insp6400 nmbd[3169]: [2011/09/08 17:00:25.301440, 0] nmbd/nmbd_become_lmb.c:395(become_local_master_stage2) Sep 8 17:00:25 Insp6400 nmbd[3169]: ***** Sep 8 17:00:25 Insp6400 nmbd[3169]: Sep 8 17:00:25 Insp6400 nmbd[3169]: Samba name server INSP6400 is now a local master browser for workgroup LINKSYS on subnet 192.168.1.100 Sep 8 17:00:25 Insp6400 nmbd[3169]: Sep 8 17:00:25 Insp6400 nmbd[3169]: ***** Sep 8 17:00:25 Insp6400 systemd[1]: Startup finished in 4s 787ms 508us (kernel) + 35s 406ms 337us (initrd) + 1min 39s 39ms 614us (userspace) = 2min 19s 233ms 459us. Sep 8 17:00:27 Insp6400 avahi-daemon[755]: Joining mDNS multicast group on interface virbr0.IPv4 with address 192.168.122.1. Sep 8 17:00:27 Insp6400 avahi-daemon[755]: New relevant interface virbr0.IPv4 for mDNS. Sep 8 17:00:27 Insp6400 avahi-daemon[755]: Registering new address record for 192.168.122.1 on virbr0.IPv4. Sep 8 17:00:27 Insp6400 kernel: [ 140.751611] ADDRCONF(NETDEV_UP): virbr0: link is not ready Sep 8 17:00:27 Insp6400 dnsmasq[3670]: started, version 2.52 cachesize 150 Sep 8 17:00:27 Insp6400 dnsmasq[3670]: compile time options: IPv6 GNU-getopt DBus no-I18N DHCP TFTP Sep 8 17:00:27 Insp6400 dnsmasq-dhcp[3670]: DHCP, IP range 192.168.122.2 -- 192.168.122.254, lease time 1h Sep 8 17:00:27 Insp6400 dnsmasq[3670]: reading /etc/resolv.conf Sep 8 17:00:27 Insp6400 dnsmasq[3670]: using nameserver 205.152.132.23#53 Sep 8 17:00:27 Insp6400 dnsmasq[3670]: using nameserver 205.152.144.23#53 Sep 8 17:00:27 Insp6400 dnsmasq[3670]: using nameserver 205.152.37.23#53 Sep 8 17:00:27 Insp6400 dnsmasq[3670]: read /etc/hosts - 4855 addresses Sep 8 17:00:28 Insp6400 ntpd[2153]: Listen normally on 8 virbr0 192.168.122.1 UDP 123 Sep 8 17:00:28 Insp6400 ntpd[2153]: peers refreshed Sep 8 17:00:29 Insp6400 kernel: [ 143.253210] Ebtables v2.0 registered Sep 8 17:00:29 Insp6400 dbus: [system] Activating via systemd: service name='org.freedesktop.RealtimeKit1' unit='rtkit-daemon.service' Sep 8 17:00:30 Insp6400 dbus: [system] Successfully activated service 'org.freedesktop.RealtimeKit1' Sep 8 21:00:31 Insp6400 rtkit-daemon[3702]: Successfully made thread 3699 of process 3699 (/usr/bin/pulseaudio) owned by '42' high priority at nice level -11. Sep 8 21:00:33 Insp6400 rtkit-daemon[3702]: Failed to make thread 3713 RT: Operation not permitted Sep 8 21:00:33 Insp6400 rtkit-daemon[3702]: Failed to make thread 3713 RT: Operation not permitted Sep 8 21:00:33 Insp6400 rtkit-daemon[3702]: Failed to make thread 3716 RT: Operation not permitted Sep 8 21:00:33 Insp6400 rtkit-daemon[3702]: Failed to make thread 3716 RT: Operation not permitted Sep 8 17:00:33 Insp6400 kernel: [ 146.796609] hda-intel: Invalid position buffer, using LPIB read method instead. Sep 8 17:00:35 Insp6400 dbus: [system] Activating service name='org.freedesktop.UDisks' (using servicehelper) Sep 8 17:00:36 Insp6400 dbus: [system] Successfully activated service 'org.freedesktop.UDisks' Sep 8 17:00:36 Insp6400 dbus: [system] Activating service name='org.freedesktop.UPower' (using servicehelper) Sep 8 17:00:36 Insp6400 dbus: [system] Successfully activated service 'org.freedesktop.UPower' Sep 8 17:00:39 Insp6400 gdm-simple-greeter[3726]: Gtk-WARNING: gtkwidget.c:6796: widget not within a GtkWindow Sep 8 17:00:39 Insp6400 gdm-simple-greeter[3726]: Gtk-WARNING: gtk_widget_size_allocate(): attempt to allocate widget with width -47 and height -47 Sep 8 17:00:40 Insp6400 dbus: [system] Activating via systemd: service name='org.freedesktop.Accounts' unit='accounts-daemon.service' Sep 8 17:00:40 Insp6400 dbus: [system] Successfully activated service 'org.freedesktop.Accounts' Sep 8 17:00:40 Insp6400 accounts-daemon[3808]: started daemon version 0.6.10 Sep 8 17:02:38 Insp6400 nmbd[3169]: [2011/09/08 17:02:38.529251, 0] nmbd/nmbd_become_lmb.c:395(become_local_master_stage2) Sep 8 17:02:38 Insp6400 nmbd[3169]: ***** Sep 8 17:02:38 Insp6400 nmbd[3169]: Sep 8 17:02:38 Insp6400 nmbd[3169]: Samba name server INSP6400 is now a local master browser for workgroup LINKSYS on subnet 192.168.122.1 Sep 8 17:02:38 Insp6400 nmbd[3169]: Sep 8 17:02:38 Insp6400 nmbd[3169]: ***** Sep 8 17:02:53 Insp6400 ntpd[2153]: 0.0.0.0 c615 05 clock_sync Sep 8 17:12:20 Insp6400 dbus: [system] Activating service name='net.reactivated.Fprint' (using servicehelper) Sep 8 17:12:21 Insp6400 dbus: [system] Successfully activated service 'net.reactivated.Fprint' Sep 8 17:12:33 Insp6400 kernel: [ 867.118180] BUG: sleeping function called from invalid context at kernel/mutex.c:271 Sep 8 17:12:33 Insp6400 kernel: [ 867.118188] in_atomic(): 1, irqs_disabled(): 0, pid: 3208, name: xenstored Sep 8 17:12:33 Insp6400 kernel: [ 867.118193] INFO: lockdep is turned off. Sep 8 17:12:33 Insp6400 kernel: [ 867.118199] Pid: 3208, comm: xenstored Not tainted 3.1.0-0.rc5.git0.0.fc17.x86_64 #1 Sep 8 17:12:33 Insp6400 kernel: [ 867.118203] Call Trace: Sep 8 17:12:33 Insp6400 kernel: [ 867.118215] [] __might_sleep+0x103/0x108 Sep 8 17:12:33 Insp6400 kernel: [ 867.118224] [] mutex_lock_nested+0x25/0x45 Sep 8 17:12:33 Insp6400 kernel: [ 867.118232] [] __irq_alloc_descs+0x50/0x18b Sep 8 17:12:33 Insp6400 kernel: [ 867.118240] [] ? pnp_register_protocol+0x39/0xb4 Sep 8 17:12:33 Insp6400 kernel: [ 867.118248] [] xen_allocate_irq_dynamic+0x49/0x58 Sep 8 17:12:33 Insp6400 kernel: [ 867.118254] [] bind_evtchn_to_irq+0x32/0x82 Sep 8 17:12:33 Insp6400 kernel: [ 867.118260] [] bind_evtchn_to_irqhandler+0x25/0x63 Sep 8 17:12:33 Insp6400 kernel: [ 867.118292] [] ? set_port_enabled+0x31/0x31 [xen_evtchn] Sep 8 17:12:33 Insp6400 kernel: [ 867.118302] [] evtchn_bind_to_user+0x56/0x64 [xen_evtchn] Sep 8 17:12:33 Insp6400 kernel: [ 867.118313] [] evtchn_ioctl+0x129/0x2ef [xen_evtchn] Sep 8 17:12:33 Insp6400 kernel: [ 867.118321] [] do_vfs_ioctl+0x472/0x4b3 Sep 8 17:12:33 Insp6400 kernel: [ 867.118327] [] sys_ioctl+0x56/0x7a Sep 8 17:12:33 Insp6400 kernel: [ 867.118335] [] system_call_fastpath+0x16/0x1b Sep 8 17:12:34 Insp6400 kernel: [ 868.191636] device tap1.0 entered promiscuous mode Sep 8 17:12:34 Insp6400 kernel: [ 868.192285] xenbr0: port 2(tap1.0) entering forwarding state Sep 8 17:12:34 Insp6400 kernel: [ 868.192341] xenbr0: port 2(tap1.0) entering forwarding state Sep 8 17:12:34 Insp6400 kernel: [ 868.353440] BUG: sleeping function called from invalid context at kernel/mutex.c:271 Sep 8 17:12:34 Insp6400 kernel: [ 868.353448] in_atomic(): 1, irqs_disabled(): 0, pid: 4171, name: qemu-dm Sep 8 17:12:34 Insp6400 kernel: [ 868.353452] INFO: lockdep is turned off. Sep 8 17:12:34 Insp6400 kernel: [ 868.353458] Pid: 4171, comm: qemu-dm Not tainted 3.1.0-0.rc5.git0.0.fc17.x86_64 #1 Sep 8 17:12:34 Insp6400 kernel: [ 868.353462] Call Trace: Sep 8 17:12:34 Insp6400 kernel: [ 868.353474] [] __might_sleep+0x103/0x108 Sep 8 17:12:34 Insp6400 kernel: [ 868.353483] [] mutex_lock_nested+0x25/0x45 Sep 8 17:12:34 Insp6400 kernel: [ 868.353491] [] __irq_alloc_descs+0x50/0x18b Sep 8 17:12:34 Insp6400 kernel: [ 868.353499] [] ? pnp_register_protocol+0x39/0xb4 Sep 8 17:12:34 Insp6400 kernel: [ 868.353507] [] xen_allocate_irq_dynamic+0x49/0x58 Sep 8 17:12:34 Insp6400 kernel: [ 868.353513] [] bind_evtchn_to_irq+0x32/0x82 Sep 8 17:12:34 Insp6400 kernel: [ 868.353519] [] bind_evtchn_to_irqhandler+0x25/0x63 Sep 8 17:12:34 Insp6400 kernel: [ 868.353532] [] ? set_port_enabled+0x31/0x31 [xen_evtchn] Sep 8 17:12:34 Insp6400 kernel: [ 868.353543] [] evtchn_bind_to_user+0x56/0x64 [xen_evtchn] Sep 8 17:12:34 Insp6400 kernel: [ 868.353553] [] evtchn_ioctl+0x129/0x2ef [xen_evtchn] Sep 8 17:12:34 Insp6400 kernel: [ 868.353561] [] do_vfs_ioctl+0x472/0x4b3 Sep 8 17:12:34 Insp6400 kernel: [ 868.353568] [] sys_ioctl+0x56/0x7a Sep 8 17:12:34 Insp6400 kernel: [ 868.353576] [] system_call_fastpath+0x16/0x1b Sep 8 17:12:35 Insp6400 kernel: [ 869.241732] xenbr0: port 2(tap1.0) entering forwarding state Sep 8 17:12:35 Insp6400 kernel: [ 869.336479] xenbr0: port 2(tap1.0) entering forwarding state Sep 8 17:12:35 Insp6400 kernel: [ 869.336566] xenbr0: port 2(tap1.0) entering forwarding state Sep 8 17:12:36 Insp6400 /etc/sysconfig/network-scripts/ifup-aliases: Missing config file tap1.0. Sep 8 17:12:36 Insp6400 kernel: [ 870.457363] device vif1.0 entered promiscuous mode Sep 8 17:12:36 Insp6400 kernel: [ 870.471816] ADDRCONF(NETDEV_UP): vif1.0: link is not ready Sep 8 17:12:36 Insp6400 avahi-daemon[755]: Registering new address record for fe80::fcff:ffff:feff:ffff on tap1.0.*. Sep 8 17:12:38 Insp6400 ntpd[2153]: Listen normally on 9 tap1.0 fe80::fcff:ffff:feff:ffff UDP 123 Sep 8 17:12:38 Insp6400 ntpd[2153]: peers refreshed Sep 8 17:15:36 Insp6400 kernel: [ 1049.819851] BUG: sleeping function called from invalid context at kernel/mutex.c:271 Sep 8 17:15:36 Insp6400 kernel: [ 1049.819859] in_atomic(): 1, irqs_disabled(): 0, pid: 3208, name: xenstored Sep 8 17:15:36 Insp6400 kernel: [ 1049.819864] INFO: lockdep is turned off. Sep 8 17:15:36 Insp6400 kernel: [ 1049.819869] Pid: 3208, comm: xenstored Not tainted 3.1.0-0.rc5.git0.0.fc17.x86_64 #1 Sep 8 17:15:36 Insp6400 kernel: [ 1049.819873] Call Trace: Sep 8 17:15:36 Insp6400 kernel: [ 1049.819886] [] __might_sleep+0x103/0x108 Sep 8 17:15:36 Insp6400 kernel: [ 1049.819894] [] mutex_lock_nested+0x25/0x45 Sep 8 17:15:36 Insp6400 kernel: [ 1049.819902] [] free_desc+0x30/0x64 Sep 8 17:15:36 Insp6400 kernel: [ 1049.819908] [] irq_free_descs+0x39/0x72 Sep 8 17:15:36 Insp6400 kernel: [ 1049.819917] [] xen_free_irq+0x49/0x4e Sep 8 17:15:36 Insp6400 kernel: [ 1049.819923] [] unbind_from_irq+0xde/0xf5 Sep 8 17:15:36 Insp6400 kernel: [ 1049.819929] [] unbind_from_irqhandler+0x19/0x1d Sep 8 17:15:36 Insp6400 kernel: [ 1049.819940] [] evtchn_unbind_from_user+0x1e/0x32 [xen_evtchn] Sep 8 17:15:36 Insp6400 kernel: [ 1049.819950] [] evtchn_ioctl+0x229/0x2ef [xen_evtchn] Sep 8 17:15:36 Insp6400 kernel: [ 1049.819959] [] do_vfs_ioctl+0x472/0x4b3 Sep 8 17:15:36 Insp6400 kernel: [ 1049.819965] [] sys_ioctl+0x56/0x7a Sep 8 17:15:36 Insp6400 kernel: [ 1049.819973] [] system_call_fastpath+0x16/0x1b Sep 8 17:15:36 Insp6400 kernel: [ 1049.878662] xenbr0: port 2(tap1.0) entering forwarding state Sep 8 17:15:36 Insp6400 avahi-daemon[755]: Withdrawing address record for fe80::fcff:ffff:feff:ffff on tap1.0. Sep 8 17:15:36 Insp6400 kernel: [ 1049.882314] xenbr0: port 2(tap1.0) entering disabled state Sep 8 17:15:36 Insp6400 kernel: [ 1049.883411] xenbr0: port 2(tap1.0) entering disabled state Sep 8 17:15:36 Insp6400 avahi-daemon[755]: Withdrawing workstation service for tap1.0. Sep 8 17:15:36 Insp6400 kernel: [ 1050.510285] xenbr0: port 3(vif1.0) entering disabled state Sep 8 17:15:36 Insp6400 kernel: [ 1050.511039] xenbr0: port 3(vif1.0) entering disabled state Sep 8 17:15:36 Insp6400 avahi-daemon[755]: Withdrawing workstation service for vif1.0. Sep 8 17:15:37 Insp6400 ntpd[2153]: Deleting interface #9 tap1.0, fe80::fcff:ffff:feff:ffff#123, interface stats: received=0, sent=0, dropped=0, active_time=179 secs Sep 8 17:15:37 Insp6400 ntpd[2153]: peers refreshed Sep 8 17:17:37 Insp6400 kernel: [ 1171.421852] BUG: sleeping function called from invalid context at kernel/mutex.c:271 Sep 8 17:17:37 Insp6400 kernel: [ 1171.421860] in_atomic(): 1, irqs_disabled(): 0, pid: 3230, name: xenconsoled Sep 8 17:17:37 Insp6400 kernel: [ 1171.421864] INFO: lockdep is turned off. Sep 8 17:17:37 Insp6400 kernel: [ 1171.421870] Pid: 3230, comm: xenconsoled Not tainted 3.1.0-0.rc5.git0.0.fc17.x86_64 #1 Sep 8 17:17:37 Insp6400 kernel: [ 1171.421874] Call Trace: Sep 8 17:17:37 Insp6400 kernel: [ 1171.421886] [] __might_sleep+0x103/0x108 Sep 8 17:17:37 Insp6400 kernel: [ 1171.421895] [] mutex_lock_nested+0x25/0x45 Sep 8 17:17:37 Insp6400 kernel: [ 1171.421903] [] free_desc+0x30/0x64 Sep 8 17:17:37 Insp6400 kernel: [ 1171.421909] [] irq_free_descs+0x39/0x72 Sep 8 17:17:37 Insp6400 kernel: [ 1171.421918] [] xen_free_irq+0x49/0x4e Sep 8 17:17:37 Insp6400 kernel: [ 1171.421924] [] unbind_from_irq+0xde/0xf5 Sep 8 17:17:37 Insp6400 kernel: [ 1171.421930] [] unbind_from_irqhandler+0x19/0x1d Sep 8 17:17:37 Insp6400 kernel: [ 1171.421942] [] evtchn_unbind_from_user+0x1e/0x32 [xen_evtchn] Sep 8 17:17:37 Insp6400 kernel: [ 1171.421952] [] evtchn_release+0x84/0xab [xen_evtchn] Sep 8 17:17:37 Insp6400 kernel: [ 1171.421960] [] fput+0x127/0x1f5 Sep 8 17:17:37 Insp6400 kernel: [ 1171.421966] [] filp_close+0x70/0x7b Sep 8 17:17:37 Insp6400 kernel: [ 1171.421974] [] put_files_struct+0xca/0x18d Sep 8 17:17:37 Insp6400 kernel: [ 1171.421980] [] exit_files+0x48/0x50 Sep 8 17:17:37 Insp6400 kernel: [ 1171.421987] [] do_exit+0x2d0/0x82c Sep 8 17:17:37 Insp6400 kernel: [ 1171.421995] [] ? xen_restore_fl_direct_reloc+0x4/0x4 Sep 8 17:17:37 Insp6400 kernel: [ 1171.422003] [] ? arch_local_irq_restore+0xb/0xd Sep 8 17:17:37 Insp6400 kernel: [ 1171.422010] [] do_group_exit+0x88/0xb6 Sep 8 17:17:37 Insp6400 kernel: [ 1171.422017] [] get_signal_to_deliver+0x528/0x57d Sep 8 17:17:37 Insp6400 kernel: [ 1171.422025] [] do_signal+0x3e/0x629 Sep 8 17:17:37 Insp6400 kernel: [ 1171.422033] [] ? security_file_permission+0x2e/0x33 Sep 8 17:17:37 Insp6400 kernel: [ 1171.422040] [] ? rw_verify_area+0xb6/0xd3 Sep 8 17:17:37 Insp6400 kernel: [ 1171.422046] [] do_notify_resume+0x28/0x83 Sep 8 17:17:37 Insp6400 kernel: [ 1171.422055] [] int_signal+0x12/0x17 Sep 8 17:17:38 Insp6400 systemd[1]: xenstored.service: control process exited, code=exited status=1 Sep 8 17:17:38 Insp6400 systemd[1]: Unit xenstored.service entered failed state. Sep 8 17:17:47 Insp6400 kernel: Kernel logging (proc) stopped. Sep 8 17:17:47 Insp6400 rsyslogd: [origin software="rsyslogd" swVersion="5.8.2" x-pid="789" x-info="http://www.rsyslog.com"] exiting on signal 15. --nextPart3309830.VdPcCRNokM Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel --nextPart3309830.VdPcCRNokM-- From xen-devel-bounces@lists.xensource.com Fri Sep 09 07:04:44 2011 Return-path: Envelope-to: www-data@lists.xensource.com Delivery-date: Fri, 09 Sep 2011 07:04:44 -0700 Received: from localhost ([127.0.0.1] helo=lists.colo.xensource.com) by lists.xensource.com with esmtp (Exim 4.43) id 1R21hC-0004bG-Tb; Fri, 09 Sep 2011 07:04:43 -0700 Received: from mail27.messagelabs.com ([193.109.254.147]) by lists.xensource.com with esmtp (Exim 4.43) id 1R21cd-0004E9-Mg for xen-devel@lists.xensource.com; Fri, 09 Sep 2011 07:00:05 -0700 X-Env-Sender: Ian.Campbell@eu.citrix.com X-Msg-Ref: server-14.tower-27.messagelabs.com!1315576781!35471247!1 X-Originating-IP: [66.165.176.89] X-StarScan-Version: 6.3.6; banners=-,-,- X-VirusChecked: Checked Received: (qmail 13039 invoked from network); 9 Sep 2011 13:59:43 -0000 Received: from smtp.citrix.com (HELO SMTP.CITRIX.COM) (66.165.176.89) by server-14.tower-27.messagelabs.com with RC4-SHA encrypted SMTP; 9 Sep 2011 13:59:43 -0000 X-IronPort-AV: E=Sophos;i="4.68,356,1312171200"; d="scan'208";a="16826085" Received: from ftlpmailmx02.citrite.net ([10.13.107.66]) by FTLPIPO01.CITRIX.COM with ESMTP/TLS/RC4-MD5; 09 Sep 2011 09:59:48 -0400 Received: from [127.0.0.1] (10.80.16.67) by smtprelay.citrix.com (10.13.107.66) with Microsoft SMTP Server id 8.3.137.0; Fri, 9 Sep 2011 09:59:47 -0400 Subject: Re: [Xen-devel] [PATCH v2 3/4] Clone and build upstream Qemu by default From: Ian Campbell To: Stefano Stabellini Date: Fri, 9 Sep 2011 06:59:46 -0700 In-Reply-To: References: <1315504038-21733-1-git-send-email-stefano.stabellini@eu.citrix.com> <1315504038-21733-3-git-send-email-stefano.stabellini@eu.citrix.com> <1315504587.3180.47.camel@cthulhu.hellion.org.uk> Organization: Citrix Systems, Inc. Content-Type: text/plain; charset="UTF-8" X-Mailer: Evolution 3.0.3- Content-Transfer-Encoding: 7bit Message-ID: <1315576788.3180.60.camel@cthulhu.hellion.org.uk> MIME-Version: 1.0 Cc: "xen-devel@lists.xensource.com" , "keir@xen.org" X-BeenThere: xen-devel@lists.xensource.com X-Mailman-Version: 2.1.5 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xensource.com Errors-To: xen-devel-bounces@lists.xensource.com On Fri, 2011-09-09 at 06:18 -0400, Stefano Stabellini wrote: > On Thu, 8 Sep 2011, Ian Campbell wrote: > > On Thu, 2011-09-08 at 13:47 -0400, stefano.stabellini@eu.citrix.com > > wrote: > > > Signed-off-by: Stefano Stabellini > > > > > > diff -r 80ba2c7abbd2 Config.mk > > > --- a/Config.mk Thu Sep 08 16:59:19 2011 +0000 > > > +++ b/Config.mk Thu Sep 08 17:18:48 2011 +0000 > > > @@ -192,6 +192,10 @@ else > > > QEMU_REMOTE=git://xenbits.xensource.com/qemu-xen-unstable.git > > > endif > > > > > > +# Only available through the git protocol at the moment > > > +QEMU_UPSTREAM_URL ?= git://xenbits.xen.org/people/sstabellini/qemu-dm.git > > > > Just a nit, but we should arrange to have a "proper" tree rather than > > a /people/... one for the default tree. e.g. to allow automated testing > > to automatically push etc. > > Like Linus said, thanks to distributed version control systems, it > doesn't actually matter where the repository is anymore :-) In technical terms perhaps not but for practical reasons we want the default tree which we point people to live next to all the other default trees, otherwise they won't be able to reliably find it the sea of suchs trees which we will eventually have under /people/. Linus' tree being just one of a thousand trees under git.kernel.org was always a pain IMHO. We also want to test and automatically push a tested branch like we do for the other trees and we really don't want to give the test system access to your (or anyone else's) xenbits account. With the number of trees which we have now we should maybe consider putting each branch in a subdir: [/staging]/xen-unstable/xen.hg /qemu-xen.hg /qemu.git /seabios.git [/staging]/xen-4.2/xen.hg /... ? (staging could also go after the dir I suppose) Ian. _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel From xen-devel-bounces@lists.xensource.com Fri Sep 09 07:14:56 2011 Return-path: Envelope-to: www-data@lists.xensource.com Delivery-date: Fri, 09 Sep 2011 07:14:56 -0700 Received: from localhost ([127.0.0.1] helo=lists.colo.xensource.com) by lists.xensource.com with esmtp (Exim 4.43) id 1R21r6-00056O-2n; Fri, 09 Sep 2011 07:14:56 -0700 Received: from mail21.messagelabs.com ([85.158.143.35]) by lists.xensource.com with esmtp (Exim 4.43) id 1R21pa-0004ta-Ns for xen-devel@lists.xensource.com; Fri, 09 Sep 2011 07:13:29 -0700 X-Env-Sender: Ian.Campbell@eu.citrix.com X-Msg-Ref: server-4.tower-21.messagelabs.com!1315577564!59611951!1 X-Originating-IP: [66.165.176.89] X-StarScan-Version: 6.3.6; banners=-,-,- X-VirusChecked: Checked Received: (qmail 4577 invoked from network); 9 Sep 2011 14:12:45 -0000 Received: from smtp.citrix.com (HELO SMTP.CITRIX.COM) (66.165.176.89) by server-4.tower-21.messagelabs.com with RC4-SHA encrypted SMTP; 9 Sep 2011 14:12:45 -0000 X-IronPort-AV: E=Sophos;i="4.68,356,1312171200"; d="scan'208";a="16826596" Received: from ftlpmailmx02.citrite.net ([10.13.107.66]) by FTLPIPO01.CITRIX.COM with ESMTP/TLS/RC4-MD5; 09 Sep 2011 10:13:18 -0400 Received: from [127.0.0.1] (10.80.16.67) by smtprelay.citrix.com (10.13.107.66) with Microsoft SMTP Server id 8.3.137.0; Fri, 9 Sep 2011 10:13:17 -0400 Subject: Re: [Xen-devel] [PATCH v2 4/4] Clone and build Seabios by default From: Ian Campbell To: Stefano Stabellini Date: Fri, 9 Sep 2011 07:13:14 -0700 In-Reply-To: References: <1315504038-21733-1-git-send-email-stefano.stabellini@eu.citrix.com> <1315504038-21733-4-git-send-email-stefano.stabellini@eu.citrix.com> <1315504825.3180.51.camel@cthulhu.hellion.org.uk> Organization: Citrix Systems, Inc. Content-Type: text/plain; charset="UTF-8" X-Mailer: Evolution 3.0.3- Content-Transfer-Encoding: 7bit Message-ID: <1315577598.3180.65.camel@cthulhu.hellion.org.uk> MIME-Version: 1.0 Cc: "xen-devel@lists.xensource.com" , "keir@xen.org" X-BeenThere: xen-devel@lists.xensource.com X-Mailman-Version: 2.1.5 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xensource.com Errors-To: xen-devel-bounces@lists.xensource.com On Fri, 2011-09-09 at 06:19 -0400, Stefano Stabellini wrote: > On Thu, 8 Sep 2011, Ian Campbell wrote: > > On Thu, 2011-09-08 at 13:47 -0400, stefano.stabellini@eu.citrix.com > > wrote: > > > Signed-off-by: Stefano Stabellini > > > > > > diff -r ef27b472d4f3 Config.mk > > > --- a/Config.mk Thu Sep 08 17:19:12 2011 +0000 > > > +++ b/Config.mk Thu Sep 08 17:29:50 2011 +0000 > > > @@ -195,6 +195,8 @@ endif > > > # Only available through the git protocol at the moment > > > QEMU_UPSTREAM_URL ?= git://xenbits.xen.org/people/sstabellini/qemu-dm.git > > > QEMU_UPSTREAM_TAG ?= origin/xen-stable-0.15 > > > +SEABIOS_UPSTREAM_URL=git://git.qemu.org/seabios.git > > > +SEABIOS_UPSTREAM_TAG ?= 7fc039e9c262b4199fab497f3e12f4e425c37560 > > > > I guess we should have a default tree on xenbits for this? > > I am not sure it is a good idea, after all we don't plan to fork it, > right? Planning not to fork is not the same as not forking. For example, imagine a bug (or security issue) is discovered in seabios and we want to backport it to our (by then) xen-4.2-testing branch. Do we take all the other updates to seabios trunk into our stable branch to get the one we want or do we ask them to push it to a branch just for us? Or do we now need to scrabble to setup trees, update the links and retest etc while trying to get an (perhaps critical) update out? Far better to just start off hosting a tree on xenbits, even if it doesn't diverge at all. > It is the same thing as with ipxe: we just use the official repo. That's a bad thing, for the same reasons. Ian. > > > > > [...] > > > +$(SEABIOS_DIR): > > > + set -ex; \ > > > + if [ ! -d seabios-remote ]; then \ > > > + rm -rf seabios-remote seabios-remote.tmp; \ > > > + mkdir seabios-remote.tmp; rmdir seabios-remote.tmp; \ > > > + $(GIT) clone $(SEABIOS_UPSTREAM_URL) seabios-remote.tmp; \ > > > + if [ "$(SEABIOS_UPSTREAM_TAG)" ]; then \ > > > + cd seabios-remote.tmp; \ > > > + $(GIT) branch -D dummy >/dev/null 2>&1 ||:; \ > > > + $(GIT) checkout -b dummy $(SEABIOS_UPSTREAM_TAG); \ > > > + cd ..; \ > > > + fi; \ > > > + mv seabios-remote.tmp seabios-remote; \ > > > + fi; \ > > > + rm -f seabios-dir; \ > > > + ln -sf seabios-remote seabios-dir; \ > > > + cp seabios-config seabios-dir/.config; > > > > This looks a lot like the qemu stuff which you only just moved into its > > own script. Can we not share it? > > Yep, I'll do that. > > _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel From xen-devel-bounces@lists.xensource.com Fri Sep 09 07:16:14 2011 Return-path: Envelope-to: www-data@lists.xensource.com Delivery-date: Fri, 09 Sep 2011 07:16:14 -0700 Received: from localhost ([127.0.0.1] helo=lists.colo.xensource.com) by lists.xensource.com with esmtp (Exim 4.43) id 1R21sM-0005Ti-4B; Fri, 09 Sep 2011 07:16:14 -0700 Received: from mail216.messagelabs.com ([85.158.143.99]) by lists.xensource.com with smtp (Exim 4.43) id 1R21q4-0004wa-Nd for xen-devel@lists.xensource.com; Fri, 09 Sep 2011 07:13:54 -0700 X-Env-Sender: gcvxd-xen-devel@m.gmane.org X-Msg-Ref: server-13.tower-216.messagelabs.com!1315577629!17710371!1 X-Originating-IP: [80.91.229.12] X-StarScan-Version: 6.3.6; banners=-,-,- X-VirusChecked: Checked Received: (qmail 16442 invoked from network); 9 Sep 2011 14:13:49 -0000 Received: from lo.gmane.org (HELO lo.gmane.org) (80.91.229.12) by server-13.tower-216.messagelabs.com with SMTP; 9 Sep 2011 14:13:49 -0000 Received: from list by lo.gmane.org with local (Exim 4.69) (envelope-from ) id 1R21q0-0006cJ-O5 for xen-devel@lists.xensource.com; Fri, 09 Sep 2011 16:13:48 +0200 Received: from horkheimer.ti5.tu-harburg.de ([134.28.77.9]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Fri, 09 Sep 2011 16:13:48 +0200 Received: from sven.koehler by horkheimer.ti5.tu-harburg.de with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Fri, 09 Sep 2011 16:13:48 +0200 X-Injected-Via-Gmane: http://gmane.org/ To: xen-devel@lists.xensource.com From: =?UTF-8?B?U3ZlbiBLw7ZobGVy?= Date: Fri, 09 Sep 2011 16:13:35 +0200 Lines: 50 Message-ID: References: <4E694CFB.1060203@citrix.com> <4E6A0034.10706@citrix.com> <4E6A1549.90806@modelnine.org> <4E6A1A0A.5040401@modelnine.org> Mime-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit X-Complaints-To: usenet@dough.gmane.org X-Gmane-NNTP-Posting-Host: horkheimer.ti5.tu-harburg.de User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:6.0) Gecko/20110829 Thunderbird/6.0 In-Reply-To: <4E6A1A0A.5040401@modelnine.org> Subject: [Xen-devel] Re: computer stalls instead of reboot X-BeenThere: xen-devel@lists.xensource.com X-Mailman-Version: 2.1.5 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xensource.com Errors-To: xen-devel-bounces@lists.xensource.com Am 09.09.2011 15:52, schrieb Heiko Wundram: > Am 09.09.2011 15:45, schrieb Sven Köhler: >> I wonder, what the disadvantage are. >> The hypervisor will still regulate CPU frequency, will it not? > > No, it will not. In xen 3.x, the hypervisor did the cpufreq-like CPU frequency switching. Has this changes in xen 4.x and the dom0 kernel is now responsible? >> Also, is the dom0 kernel doing something that it shouldn't do? >> (maybe something that collides with the ACPI-related activities of the >> hypervisor, if there are any?) > > I guess the BIOS is simply reporting broken ACPI tables to the operating > system (the board is a "consumer" board, so you can guess that the > manufacturer only tests the ACPI-tables for compatability with Windows). > > The ACPI tables (AFAIK, someone correct me) also contain a method for > rebooting the system, which simply doesn't work/is broken when Xen is > involved. Forcing acpi=off means that the normal triple-fault or > kbd-controller reset machinery is always used, as ACPI isn't even > initialized. > > What struck me as odd, though: you can configure Linux to use "some > other" form of hard reset through a kernel parameter, but setting that > to explicitly use triple-faults didn't work, either (same hangs), so > possibly it's some form of additional interaction between Xen, the board > and the hypervisor. Anyway, the Hetzner "recommended" fix is just what I > sent you, and I can confirm that works. Thanks for the explanation. Here's another thing: why does rebooting work, if xen is not involved, i.e. if the same kernel runs without xen? (I'm pretty sure this was true the last time I tried) I would assume, that broken ACPI tables would result in no reboot no matter what. Also, does the dom0 kernel do the reboot, or the hypervisor? In the past, there were some reboot/poweroff related patches for the xen part of the kernel. I assumed, that the dom0 kernel is not using the "normal" reboot/poweroff code and instead instructs the hypervisor reboot/poweroff the machine. On the other hand, all the patches that went into linux 3.0 which were aimed at making poweroff/reboot as similar to windows as possible sounded promising, but didn't help in the Hetzner case :-( Regards, Sven _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel From xen-devel-bounces@lists.xensource.com Fri Sep 09 07:18:27 2011 Return-path: Envelope-to: www-data@lists.xensource.com Delivery-date: Fri, 09 Sep 2011 07:18:27 -0700 Received: from localhost ([127.0.0.1] helo=lists.colo.xensource.com) by lists.xensource.com with esmtp (Exim 4.43) id 1R21uU-0005sH-Vd; Fri, 09 Sep 2011 07:18:27 -0700 Received: from mail21.messagelabs.com ([85.158.143.35]) by lists.xensource.com with esmtp (Exim 4.43) id 1R21u3-0005fU-EI for xen-devel@lists.xensource.com; Fri, 09 Sep 2011 07:17:59 -0700 X-Env-Sender: Ian.Campbell@eu.citrix.com X-Msg-Ref: server-12.tower-21.messagelabs.com!1315577861!49340975!1 X-Originating-IP: [66.165.176.89] X-StarScan-Version: 6.3.6; banners=-,-,- X-VirusChecked: Checked Received: (qmail 6395 invoked from network); 9 Sep 2011 14:17:42 -0000 Received: from smtp.citrix.com (HELO SMTP.CITRIX.COM) (66.165.176.89) by server-12.tower-21.messagelabs.com with RC4-SHA encrypted SMTP; 9 Sep 2011 14:17:42 -0000 X-IronPort-AV: E=Sophos;i="4.68,356,1312171200"; d="scan'208";a="16826746" Received: from ftlpmailmx02.citrite.net ([10.13.107.66]) by FTLPIPO01.CITRIX.COM with ESMTP/TLS/RC4-MD5; 09 Sep 2011 10:17:54 -0400 Received: from [127.0.0.1] (10.80.16.67) by smtprelay.citrix.com (10.13.107.66) with Microsoft SMTP Server id 8.3.137.0; Fri, 9 Sep 2011 10:17:54 -0400 Subject: Re: [Xen-devel] Re: xl vs. xm, possible bug in xl From: Ian Campbell To: Stefano Stabellini Date: Fri, 9 Sep 2011 07:16:50 -0700 In-Reply-To: References: <20110908170755.GB16730@dumpdata.com> <4E69F80A.5060905@gmail.com> <4E6A09F2.4040405@gmail.com> Organization: Citrix Systems, Inc. Content-Type: text/plain; charset="UTF-8" X-Mailer: Evolution 3.0.3- Content-Transfer-Encoding: 7bit Message-ID: <1315577875.3180.67.camel@cthulhu.hellion.org.uk> MIME-Version: 1.0 Cc: Keir Fraser , "xen-devel@lists.xensource.com" , Ian Jackson , Sven =?ISO-8859-1?Q?K=F6hler?= X-BeenThere: xen-devel@lists.xensource.com X-Mailman-Version: 2.1.5 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xensource.com Errors-To: xen-devel-bounces@lists.xensource.com On Fri, 2011-09-09 at 08:54 -0400, Stefano Stabellini wrote: > > > We have a patch upstream to fix this issue but it hasn't been backported > > > to 4.1: > > > > Thanks, sounds like this will fix my problem. > > > > Is there any chance that this is going to be in 4.1.2 final? > > I think it should be! Ack! I'm sure I asked for it before, must've fallen through the cracks. Ian. _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel From xen-devel-bounces@lists.xensource.com Fri Sep 09 07:24:37 2011 Return-path: Envelope-to: www-data@lists.xensource.com Delivery-date: Fri, 09 Sep 2011 07:24:37 -0700 Received: from localhost ([127.0.0.1] helo=lists.colo.xensource.com) by lists.xensource.com with esmtp (Exim 4.43) id 1R220T-0006Kf-20; Fri, 09 Sep 2011 07:24:37 -0700 Received: from mail174.messagelabs.com ([85.158.138.51]) by lists.xensource.com with smtp (Exim 4.43) id 1R21zj-00067y-M8 for xen-devel@lists.xensource.com; Fri, 09 Sep 2011 07:23:52 -0700 X-Env-Sender: Stefano.Stabellini@eu.citrix.com X-Msg-Ref: server-4.tower-174.messagelabs.com!1315578228!30870978!1 X-Originating-IP: [62.200.22.115] X-StarScan-Version: 6.3.6; banners=-,-,- X-VirusChecked: Checked Received: (qmail 25187 invoked from network); 9 Sep 2011 14:23:48 -0000 Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115) by server-4.tower-174.messagelabs.com with SMTP; 9 Sep 2011 14:23:48 -0000 X-IronPort-AV: E=Sophos;i="4.68,356,1312156800"; d="scan'208";a="7700528" Received: from lonpmailmx01.citrite.net ([10.30.203.162]) by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5; 09 Sep 2011 14:23:47 +0000 Received: from kaball.uk.xensource.com (10.80.2.59) by LONPMAILMX01.citrite.net (10.30.203.162) with Microsoft SMTP Server id 8.3.137.0; Fri, 9 Sep 2011 15:23:47 +0100 Date: Fri, 9 Sep 2011 15:32:00 +0100 From: Stefano Stabellini X-X-Sender: sstabellini@kaball-desktop To: Ian Campbell Subject: Re: [Xen-devel] [PATCH v2 4/4] Clone and build Seabios by default In-Reply-To: <1315577598.3180.65.camel@cthulhu.hellion.org.uk> Message-ID: References: <1315504038-21733-1-git-send-email-stefano.stabellini@eu.citrix.com> <1315504038-21733-4-git-send-email-stefano.stabellini@eu.citrix.com> <1315504825.3180.51.camel@cthulhu.hellion.org.uk> <1315577598.3180.65.camel@cthulhu.hellion.org.uk> User-Agent: Alpine 2.00 (DEB 1167 2008-08-23) MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Cc: "xen-devel@lists.xensource.com" , "keir@xen.org" , Stefano Stabellini X-BeenThere: xen-devel@lists.xensource.com X-Mailman-Version: 2.1.5 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xensource.com Errors-To: xen-devel-bounces@lists.xensource.com On Fri, 9 Sep 2011, Ian Campbell wrote: > On Fri, 2011-09-09 at 06:19 -0400, Stefano Stabellini wrote: > > On Thu, 8 Sep 2011, Ian Campbell wrote: > > > On Thu, 2011-09-08 at 13:47 -0400, stefano.stabellini@eu.citrix.com > > > wrote: > > > > Signed-off-by: Stefano Stabellini > > > > > > > > diff -r ef27b472d4f3 Config.mk > > > > --- a/Config.mk Thu Sep 08 17:19:12 2011 +0000 > > > > +++ b/Config.mk Thu Sep 08 17:29:50 2011 +0000 > > > > @@ -195,6 +195,8 @@ endif > > > > # Only available through the git protocol at the moment > > > > QEMU_UPSTREAM_URL ?= git://xenbits.xen.org/people/sstabellini/qemu-dm.git > > > > QEMU_UPSTREAM_TAG ?= origin/xen-stable-0.15 > > > > +SEABIOS_UPSTREAM_URL=git://git.qemu.org/seabios.git > > > > +SEABIOS_UPSTREAM_TAG ?= 7fc039e9c262b4199fab497f3e12f4e425c37560 > > > > > > I guess we should have a default tree on xenbits for this? > > > > I am not sure it is a good idea, after all we don't plan to fork it, > > right? > > Planning not to fork is not the same as not forking. > > For example, imagine a bug (or security issue) is discovered in seabios > and we want to backport it to our (by then) xen-4.2-testing branch. Do > we take all the other updates to seabios trunk into our stable branch to > get the one we want or do we ask them to push it to a branch just for > us? Or do we now need to scrabble to setup trees, update the links and > retest etc while trying to get an (perhaps critical) update out? Far > better to just start off hosting a tree on xenbits, even if it doesn't > diverge at all. > Seabios already provides two stable branches: if a security issue is discovered, the Seabios guys will backport the fix to their stable branches and we just need to update the TAG (or set the TAG to 0.6.1-stable to begin with). The only problem is that no stable branches have xen support yet. _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel From xen-devel-bounces@lists.xensource.com Fri Sep 09 07:32:34 2011 Return-path: Envelope-to: www-data@lists.xensource.com Delivery-date: Fri, 09 Sep 2011 07:32:34 -0700 Received: from localhost ([127.0.0.1] helo=lists.colo.xensource.com) by lists.xensource.com with esmtp (Exim 4.43) id 1R2289-0006qu-Ej; Fri, 09 Sep 2011 07:32:33 -0700 Received: from mail27.messagelabs.com ([193.109.254.147]) by lists.xensource.com with esmtp (Exim 4.43) id 1R227R-0006co-66 for xen-devel@lists.xensource.com; Fri, 09 Sep 2011 07:31:50 -0700 X-Env-Sender: Ian.Campbell@eu.citrix.com X-Msg-Ref: server-5.tower-27.messagelabs.com!1315578686!44214077!1 X-Originating-IP: [66.165.176.63] X-StarScan-Version: 6.3.6; banners=-,-,- X-VirusChecked: Checked Received: (qmail 17949 invoked from network); 9 Sep 2011 14:31:28 -0000 Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63) by server-5.tower-27.messagelabs.com with RC4-SHA encrypted SMTP; 9 Sep 2011 14:31:28 -0000 X-IronPort-AV: E=Sophos;i="4.68,356,1312171200"; d="scan'208";a="162330874" Received: from ftlpmailmx02.citrite.net ([10.13.107.66]) by FTLPIPO02.CITRIX.COM with ESMTP/TLS/RC4-MD5; 09 Sep 2011 10:31:39 -0400 Received: from [127.0.0.1] (10.80.16.67) by smtprelay.citrix.com (10.13.107.66) with Microsoft SMTP Server id 8.3.137.0; Fri, 9 Sep 2011 10:31:38 -0400 Subject: Re: [Xen-devel] [PATCH v2 3/4] Clone and build upstream Qemu by default From: Ian Campbell To: Stefano Stabellini Date: Fri, 9 Sep 2011 07:31:35 -0700 In-Reply-To: <1315576788.3180.60.camel@cthulhu.hellion.org.uk> References: <1315504038-21733-1-git-send-email-stefano.stabellini@eu.citrix.com> <1315504038-21733-3-git-send-email-stefano.stabellini@eu.citrix.com> <1315504587.3180.47.camel@cthulhu.hellion.org.uk> <1315576788.3180.60.camel@cthulhu.hellion.org.uk> Organization: Citrix Systems, Inc. Content-Type: text/plain; charset="UTF-8" X-Mailer: Evolution 3.0.3- Content-Transfer-Encoding: 7bit Message-ID: <1315578699.3180.68.camel@cthulhu.hellion.org.uk> MIME-Version: 1.0 Cc: "xen-devel@lists.xensource.com" , "keir@xen.org" X-BeenThere: xen-devel@lists.xensource.com X-Mailman-Version: 2.1.5 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xensource.com Errors-To: xen-devel-bounces@lists.xensource.com On Fri, 2011-09-09 at 09:59 -0400, Ian Campbell wrote: > > With the number of trees which we have now we should maybe consider > putting each branch in a subdir: > [/staging]/xen-unstable/xen.hg > /qemu-xen.hg > /qemu.git > /seabios.git > [/staging]/xen-4.2/xen.hg > /... > > ? (staging could also go after the dir I suppose) Or we could make use of git and hg's internal branching capabilities I guess. Ian. _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel From xen-devel-bounces@lists.xensource.com Fri Sep 09 07:34:08 2011 Return-path: Envelope-to: www-data@lists.xensource.com Delivery-date: Fri, 09 Sep 2011 07:34:08 -0700 Received: from localhost ([127.0.0.1] helo=lists.colo.xensource.com) by lists.xensource.com with esmtp (Exim 4.43) id 1R229g-0007FS-EP; Fri, 09 Sep 2011 07:34:08 -0700 Received: from mail21.messagelabs.com ([85.158.143.35]) by lists.xensource.com with esmtp (Exim 4.43) id 1R227f-0006gv-Uq for xen-devel@lists.xensource.com; Fri, 09 Sep 2011 07:32:04 -0700 X-Env-Sender: 19890121wr@gmail.com X-Msg-Ref: server-5.tower-21.messagelabs.com!1315578687!47522554!1 X-Originating-IP: [209.85.160.171] X-StarScan-Version: 6.3.6; banners=-,-,- X-VirusChecked: Checked Received: (qmail 28172 invoked from network); 9 Sep 2011 14:31:28 -0000 Received: from mail-gy0-f171.google.com (HELO mail-gy0-f171.google.com) (209.85.160.171) by server-5.tower-21.messagelabs.com with RC4-SHA encrypted SMTP; 9 Sep 2011 14:31:28 -0000 Received: by gyh3 with SMTP id 3so359289gyh.30 for ; Fri, 09 Sep 2011 07:31:59 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:date:message-id:subject:from:to:content-type; bh=HNUUF64wWzTUoSAU//lhlvBDAXOQKe5T2tPCKovlPNE=; b=GMkzxh6SSYB4Bs2j6eG+ksECuMEAH8q8Nj9o9ACnhbQUY2K9la/ifZKIbCSUkoXmYa Z4/9QcqtcCFXK60wjaIRRgPGvJpaTaqJ/pJWdiqZsSQ/pSWHqNXjBLvocOyFOpAYvwhu rraZo15JHJzo4zl1D3QzsZ3VAhxqYl7hGngqE= MIME-Version: 1.0 Received: by 10.68.15.39 with SMTP id u7mr2666768pbc.476.1315578719065; Fri, 09 Sep 2011 07:31:59 -0700 (PDT) Received: by 10.142.177.7 with HTTP; Fri, 9 Sep 2011 07:31:58 -0700 (PDT) Date: Fri, 9 Sep 2011 22:31:58 +0800 Message-ID: From: =?GB2312?B?zuLI8Q==?= <19890121wr@gmail.com> To: xen-devel@lists.xensource.com Subject: [Xen-devel] about page table X-BeenThere: xen-devel@lists.xensource.com X-Mailman-Version: 2.1.5 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1465837716==" Sender: xen-devel-bounces@lists.xensource.com Errors-To: xen-devel-bounces@lists.xensource.com --===============1465837716== Content-Type: multipart/alternative; boundary=bcaec520e5e93956f904ac830a71 --bcaec520e5e93956f904ac830a71 Content-Type: text/plain; charset=ISO-8859-1 Hi,everyone I have been using dbg_pv_va2mfn() function to scan PV dom's page table.However,when i intended to modify the page table's entry.Something went wrong. Should I modify the P2M and M2P table,either?But I kind of lose track of how things work at P2M and M2P table.Can someone tell me something about these tables. Or can someone can tell me which function can come in handy,or where to look in. I am in the middle of a project that needs to manipulate the page table in dom. Thanks --bcaec520e5e93956f904ac830a71 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
Hi,everyone
I have been using dbg_pv_va2mfn() function to scan PV= dom's page table.However,when i intended to modify the page table'= s entry.Something went wrong.
Should I modify the P2M and M2P table,eit= her?But I kind of lose track of how things work at P2M and M2P table.Can so= meone tell me something about these tables.
Or can someone can tell me which function can come in handy,or where t= o look in.
I am in the middle of =A0a project that needs to manip= ulate the page table in dom.
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 = =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0= =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 = =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0= =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 = =A0 =A0 =A0 =A0 =A0Thanks
--bcaec520e5e93956f904ac830a71-- --===============1465837716== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel --===============1465837716==-- From xen-devel-bounces@lists.xensource.com Fri Sep 09 08:10:24 2011 Return-path: Envelope-to: www-data@lists.xensource.com Delivery-date: Fri, 09 Sep 2011 08:10:24 -0700 Received: from localhost ([127.0.0.1] helo=lists.colo.xensource.com) by lists.xensource.com with esmtp (Exim 4.43) id 1R22il-0000gF-6L; Fri, 09 Sep 2011 08:10:23 -0700 Received: from mail182.messagelabs.com ([85.158.139.83]) by lists.xensource.com with esmtp (Exim 4.43) id 1R22fI-0000Ow-GW for xen-devel@lists.xensource.com; Fri, 09 Sep 2011 08:06:49 -0700 X-Env-Sender: Andrew.Cooper3@citrix.com X-Msg-Ref: server-11.tower-182.messagelabs.com!1315580803!17727666!1 X-Originating-IP: [66.165.176.63] X-StarScan-Version: 6.3.6; banners=-,-,- X-VirusChecked: Checked Received: (qmail 5318 invoked from network); 9 Sep 2011 15:06:45 -0000 Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63) by server-11.tower-182.messagelabs.com with RC4-SHA encrypted SMTP; 9 Sep 2011 15:06:45 -0000 X-IronPort-AV: E=Sophos;i="4.68,356,1312171200"; d="scan'208";a="162337327" Received: from ftlpmailmx02.citrite.net ([10.13.107.66]) by FTLPIPO02.CITRIX.COM with ESMTP/TLS/RC4-MD5; 09 Sep 2011 11:06:41 -0400 Received: from [10.80.2.18] (10.80.2.18) by FTLPMAILMX02.citrite.net (10.13.107.66) with Microsoft SMTP Server id 8.3.137.0; Fri, 9 Sep 2011 11:06:41 -0400 Message-ID: <4E6A2B7F.6060006@citrix.com> Date: Fri, 9 Sep 2011 16:06:39 +0100 From: Andrew Cooper User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.2.21) Gecko/20110831 Lightning/1.0b2 Thunderbird/3.1.13 MIME-Version: 1.0 To: Jan Beulich Subject: Re: [Xen-devel] Re: 4.0/4.1 requests - IO-APIC EOI v2 [RFC] References: <4E689D9A.1020405@citrix.com> <4E68C6C10200007800055485@nat28.tlf.novell.com> <4E68C09B.8050409@citrix.com> <4E68E1D30200007800055501@nat28.tlf.novell.com> <4E68C9A9.8090707@citrix.com> In-Reply-To: <4E68C9A9.8090707@citrix.com> Content-Type: multipart/mixed; boundary="------------000902070101040807010002" Cc: Keir Fraser , "xen-devel@lists.xensource.com" X-BeenThere: xen-devel@lists.xensource.com X-Mailman-Version: 2.1.5 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xensource.com Errors-To: xen-devel-bounces@lists.xensource.com --------------000902070101040807010002 Content-Type: text/plain; charset="ISO-8859-1" Content-Transfer-Encoding: 7bit ---SNIP--- v2 of the EOI patch. This provides one function to perform EOI'ing, taking a vector or a pin (or both). -- Andrew Cooper - Dom0 Kernel Engineer, Citrix XenServer T: +44 (0)1223 225 900, http://www.citrix.com --------------000902070101040807010002 Content-Type: text/x-patch; name="IO-APIC-eoi.patch" Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename="IO-APIC-eoi.patch" diff -r 0268e7380953 xen/arch/x86/io_apic.c --- a/xen/arch/x86/io_apic.c Mon Sep 05 15:10:28 2011 +0100 +++ b/xen/arch/x86/io_apic.c Fri Sep 09 15:58:59 2011 +0100 @@ -357,7 +357,7 @@ static void __eoi_IO_APIC_irq(unsigned i pin = entry->pin; if (pin == -1) break; - io_apic_eoi(entry->apic, vector); + __io_apic_eoi(entry->apic, vector, pin); if (!entry->next) break; entry = irq_2_pin + entry->next; @@ -397,18 +397,7 @@ static void clear_IO_APIC_pin(unsigned i entry.trigger = 1; __ioapic_write_entry(apic, pin, TRUE, entry); } - if (mp_ioapics[apic].mpc_apicver >= 0x20) - io_apic_eoi(apic, entry.vector); - else { - /* - * Mechanism by which we clear remoteIRR in this case is by - * changing the trigger mode to edge and back to level. - */ - entry.trigger = 0; - __ioapic_write_entry(apic, pin, TRUE, entry); - entry.trigger = 1; - __ioapic_write_entry(apic, pin, TRUE, entry); - } + io_apic_eoi(apic, entry.vector, pin); } /* @@ -1750,7 +1739,7 @@ static void end_level_ioapic_irq (unsign { int ioapic; for (ioapic = 0; ioapic < nr_ioapics; ioapic++) - io_apic_eoi(ioapic, i); + io_apic_eoi_vector(ioapic, i); } v = apic_read(APIC_TMR + ((i & ~0x1f) >> 1)); @@ -2622,3 +2611,86 @@ void __init init_ioapic_mappings(void) printk(XENLOG_INFO "IRQ limits: %u GSI, %u MSI/MSI-X\n", nr_irqs_gsi, nr_irqs - nr_irqs_gsi); } + +/* EOI an IO-APIC entry. One of vector or pin may be -1, indicating that + * it should be worked out using the other. This function disables interrupts + * and takes the ioapic_lock */ +void io_apic_eoi(unsigned int apic, unsigned int vector, unsigned int pin) +{ + unsigned int flags; + spin_lock_irqsave(&ioapic_lock, flags); + __io_apic_eoi(apic, vector, pin); + spin_unlock_irqrestore(&ioapic_lock, flags); +} + +/* EOI an IO-APIC entry. One of vector or pin may be -1, indicating that + * it should be worked out using the other. This function */ +void __io_apic_eoi(unsigned int apic, unsigned int vector, unsigned int pin) +{ + ASSERT( spin_is_locked(&ioapic_lock) ); + ASSERT( !local_irq_is_enabled() ); + + /* Ensure some useful information is passed in */ + BUG_ON( !(vector == -1 && pin != -1) ); + + /* Prefer the use of the EOI register if available */ + if ( ioapic_has_eoi_reg(apic) ) + { + /* If vector is unknown, read it from the IO-APIC */ + if ( vector == -1 ) + vector = __ioapic_read_entry(apic, pin, TRUE).vector; + + *(IO_APIC_BASE(apic)+16) = vector; + } + else + { + /* Else fake an EOI by switching to edge triggered mode + * and back */ + struct IO_APIC_route_entry entry; + bool_t need_to_unmask = 0; + + /* If pin is unknown, search for it */ + if ( pin == -1 ) + { + unsigned int p; + for ( p = 0; p < nr_ioapic_registers[apic]; ++p ) + if ( __ioapic_read_entry(apic, p, TRUE).vector == vector ) + { + pin = p; + break; + } + + /* If search fails, nothing to do */ + if ( pin == -1 ) + return; + } + + /* If vector is unknown, read it from the IO-APIC */ + if ( vector == -1 ) + vector = __ioapic_read_entry(apic, pin, TRUE).vector; + + entry = __ioapic_read_entry(apic, pin, TRUE); + + if ( ! entry.mask ) + { + /* If entry is not currently masked, mask it and make + * a note to unmask it later */ + entry.mask = 1; + __ioapic_write_entry(apic, pin, TRUE, entry); + need_to_unmask = 1; + } + + /* Flip the trigger mode to edge and back */ + entry.trigger = 0; + __ioapic_write_entry(apic, pin, TRUE, entry); + entry.trigger = 1; + __ioapic_write_entry(apic, pin, TRUE, entry); + + if ( need_to_unmask ) + { + /* Unmask if neccesary */ + entry.mask = 0; + __ioapic_write_entry(apic, pin, TRUE, entry); + } + } +} diff -r 0268e7380953 xen/include/asm-x86/io_apic.h --- a/xen/include/asm-x86/io_apic.h Mon Sep 05 15:10:28 2011 +0100 +++ b/xen/include/asm-x86/io_apic.h Fri Sep 09 15:58:59 2011 +0100 @@ -157,10 +157,13 @@ static inline void io_apic_write(unsigne __io_apic_write(apic, reg, value); } -static inline void io_apic_eoi(unsigned int apic, unsigned int vector) -{ - *(IO_APIC_BASE(apic)+16) = vector; -} +#define ioapic_has_eoi_reg(apic) (mp_ioapics[(apic)].mpc_apicver >= 0x20) + +void __io_apic_eoi(unsigned int apic, unsigned int vector, unsigned int pin); +void io_apic_eoi(unsigned int apic, unsigned int vector, unsigned int pin); + +#define io_apic_eoi_vector(apic, vector) io_apic_eoi((apic), (vector), -1) +#define io_apic_eoi_pin(apic, pin) io_apic_eoi((apic), -1, (pin)) /* * Re-write a value: to be used for read-modify-write --------------000902070101040807010002 Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel --------------000902070101040807010002-- From xen-devel-bounces@lists.xensource.com Fri Sep 09 08:40:13 2011 Return-path: Envelope-to: www-data@lists.xensource.com Delivery-date: Fri, 09 Sep 2011 08:40:13 -0700 Received: from localhost ([127.0.0.1] helo=lists.colo.xensource.com) by lists.xensource.com with esmtp (Exim 4.43) id 1R23Bb-0002Od-Ko; Fri, 09 Sep 2011 08:40:11 -0700 Received: from mail182.messagelabs.com ([85.158.139.83]) by lists.xensource.com with esmtp (Exim 4.43) id 1R23Ax-0002Af-Kk for xen-devel@lists.xensource.com; Fri, 09 Sep 2011 08:39:31 -0700 X-Env-Sender: JBeulich@suse.com X-Msg-Ref: server-2.tower-182.messagelabs.com!1315582768!16734241!1 X-Originating-IP: [130.57.49.28] X-StarScan-Version: 6.3.6; banners=-,-,- X-VirusChecked: Checked Received: (qmail 1788 invoked from network); 9 Sep 2011 15:39:28 -0000 Received: from nat28.tlf.novell.com (HELO nat28.tlf.novell.com) (130.57.49.28) by server-2.tower-182.messagelabs.com with DHE-RSA-AES256-SHA encrypted SMTP; 9 Sep 2011 15:39:28 -0000 Received: from EMEA1-MTA by nat28.tlf.novell.com with Novell_GroupWise; Fri, 09 Sep 2011 16:39:27 +0100 Message-Id: <4E6A4F66020000780005589B@nat28.tlf.novell.com> X-Mailer: Novell GroupWise Internet Agent 8.0.1 Date: Fri, 09 Sep 2011 16:39:50 +0100 From: "Jan Beulich" To: "Andrew Cooper" Subject: Re: [Xen-devel] Re: 4.0/4.1 requests - IO-APIC EOI v2 [RFC] References: <4E689D9A.1020405@citrix.com> <4E68C6C10200007800055485@nat28.tlf.novell.com> <4E68C09B.8050409@citrix.com> <4E68E1D30200007800055501@nat28.tlf.novell.com> <4E68C9A9.8090707@citrix.com> <4E6A2B7F.6060006@citrix.com> In-Reply-To: <4E6A2B7F.6060006@citrix.com> Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: quoted-printable Content-Disposition: inline Cc: Keir Fraser , "xen-devel@lists.xensource.com" X-BeenThere: xen-devel@lists.xensource.com X-Mailman-Version: 2.1.5 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xensource.com Errors-To: xen-devel-bounces@lists.xensource.com >>> On 09.09.11 at 17:06, Andrew Cooper wrote: >@@ -397,18 +397,7 @@ static void clear_IO_APIC_pin(unsigned i > entry.trigger =3D 1; > __ioapic_write_entry(apic, pin, TRUE, entry); > } >- if (mp_ioapics[apic].mpc_apicver >=3D 0x20) >- io_apic_eoi(apic, entry.vector); >- else { >- /* >- * Mechanism by which we clear remoteIRR in this case is by >- * changing the trigger mode to edge and back to level. >- */ >- entry.trigger =3D 0; >- __ioapic_write_entry(apic, pin, TRUE, entry); >- entry.trigger =3D 1; >- __ioapic_write_entry(apic, pin, TRUE, entry); >- } >+ io_apic_eoi(apic, entry.vector, pin); This should be __io_apic_eoi() - all other functions called here are the non-locking ones, too. > } >=20 > /* >... >@@ -2622,3 +2611,86 @@ void __init init_ioapic_mappings(void) > printk(XENLOG_INFO "IRQ limits: %u GSI, %u MSI/MSI-X\n", > nr_irqs_gsi, nr_irqs - nr_irqs_gsi); > } >+ >+/* EOI an IO-APIC entry. One of vector or pin may be -1, indicating = that >+ * it should be worked out using the other. This function disables = interrupts >+ * and takes the ioapic_lock */ >+void io_apic_eoi(unsigned int apic, unsigned int vector, unsigned int = pin) static? >+{ >+ unsigned int flags; >+ spin_lock_irqsave(&ioapic_lock, flags); >+ __io_apic_eoi(apic, vector, pin); >+ spin_unlock_irqrestore(&ioapic_lock, flags); >+} >+ >+/* EOI an IO-APIC entry. One of vector or pin may be -1, indicating = that >+ * it should be worked out using the other. This function */ >+void __io_apic_eoi(unsigned int apic, unsigned int vector, unsigned int = pin) static! >+ { >+ /* Else fake an EOI by switching to edge triggered mode >+ * and back */ >+ struct IO_APIC_route_entry entry; >+ bool_t need_to_unmask =3D 0; >+ You may want to assert that at least one of vector and pin is not -1. >+ /* If pin is unknown, search for it */ >+ if ( pin =3D=3D -1 ) >+ { >+ unsigned int p; >+ for ( p =3D 0; p < nr_ioapic_registers[apic]; ++p ) >+ if ( __ioapic_read_entry(apic, p, TRUE).vector =3D=3D = vector ) >+ { >+ pin =3D p; >+ break; While we seem to agree that sharing of vectors within an IO-APIC must be prevented, I don't think this is currently being enforced, and hence you can't just "break" here - you need to handle all matching pins. >+ } >+ =20 >+ /* If search fails, nothing to do */ >+ if ( pin =3D=3D -1 ) >+ return; >+ } >+ >+ /* If vector is unknown, read it from the IO-APIC */ >+ if ( vector =3D=3D -1 ) >+ vector =3D __ioapic_read_entry(apic, pin, TRUE).vector; You don't seem to use vector further down. >+ >+ entry =3D __ioapic_read_entry(apic, pin, TRUE); >+ >+ if ( ! entry.mask ) >+ { >+ /* If entry is not currently masked, mask it and make >+ * a note to unmask it later */ >+ entry.mask =3D 1; >+ __ioapic_write_entry(apic, pin, TRUE, entry); >+ need_to_unmask =3D 1; >+ } >+ >+ /* Flip the trigger mode to edge and back */ >+ entry.trigger =3D 0; >+ __ioapic_write_entry(apic, pin, TRUE, entry); >+ entry.trigger =3D 1; >+ __ioapic_write_entry(apic, pin, TRUE, entry); >+ >+ if ( need_to_unmask ) >+ { >+ /* Unmask if neccesary */ >+ entry.mask =3D 0; >+ __ioapic_write_entry(apic, pin, TRUE, entry); >+ } >+ } >+} >diff -r 0268e7380953 xen/include/asm-x86/io_apic.h >--- a/xen/include/asm-x86/io_apic.h Mon Sep 05 15:10:28 2011 +0100 >+++ b/xen/include/asm-x86/io_apic.h Fri Sep 09 15:58:59 2011 +0100 >@@ -157,10 +157,13 @@ static inline void io_apic_write(unsigne > __io_apic_write(apic, reg, value); > } >=20 >-static inline void io_apic_eoi(unsigned int apic, unsigned int vector) >-{ >- *(IO_APIC_BASE(apic)+16) =3D vector; >-} >+#define ioapic_has_eoi_reg(apic) (mp_ioapics[(apic)].mpc_apicver >=3D = 0x20) Is this used outside of io_apic.c? >+ >+void __io_apic_eoi(unsigned int apic, unsigned int vector, unsigned int = pin); >+void io_apic_eoi(unsigned int apic, unsigned int vector, unsigned int = pin); >+ >+#define io_apic_eoi_vector(apic, vector) io_apic_eoi((apic), (vector), = -1) >+#define io_apic_eoi_pin(apic, pin) io_apic_eoi((apic), -1, (pin)) None of these should be either (see also above). Jan >=20 > /* > * Re-write a value: to be used for read-modify-write _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel From xen-devel-bounces@lists.xensource.com Fri Sep 09 08:56:16 2011 Return-path: Envelope-to: www-data@lists.xensource.com Delivery-date: Fri, 09 Sep 2011 08:56:16 -0700 Received: from localhost ([127.0.0.1] helo=lists.colo.xensource.com) by lists.xensource.com with esmtp (Exim 4.43) id 1R23R9-000311-Ul; Fri, 09 Sep 2011 08:56:16 -0700 Received: from mail27.messagelabs.com ([193.109.254.147]) by lists.xensource.com with esmtp (Exim 4.43) id 1R23QS-0002oF-Sj for xen-devel@lists.xensource.com; Fri, 09 Sep 2011 08:55:33 -0700 X-Env-Sender: Andrew.Cooper3@citrix.com X-Msg-Ref: server-2.tower-27.messagelabs.com!1315583705!54317086!1 X-Originating-IP: [66.165.176.63] X-StarScan-Version: 6.3.6; banners=-,-,- X-VirusChecked: Checked Received: (qmail 24776 invoked from network); 9 Sep 2011 15:55:06 -0000 Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63) by server-2.tower-27.messagelabs.com with RC4-SHA encrypted SMTP; 9 Sep 2011 15:55:06 -0000 X-IronPort-AV: E=Sophos;i="4.68,357,1312171200"; d="scan'208";a="162346168" Received: from ftlpmailmx02.citrite.net ([10.13.107.66]) by FTLPIPO02.CITRIX.COM with ESMTP/TLS/RC4-MD5; 09 Sep 2011 11:55:25 -0400 Received: from [10.80.2.18] (10.80.2.18) by FTLPMAILMX02.citrite.net (10.13.107.66) with Microsoft SMTP Server id 8.3.137.0; Fri, 9 Sep 2011 11:55:24 -0400 Message-ID: <4E6A36EB.6000802@citrix.com> Date: Fri, 9 Sep 2011 16:55:23 +0100 From: Andrew Cooper User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.2.21) Gecko/20110831 Lightning/1.0b2 Thunderbird/3.1.13 MIME-Version: 1.0 To: Jan Beulich Subject: Re: [Xen-devel] Re: 4.0/4.1 requests - IO-APIC EOI v2 [RFC] References: <4E689D9A.1020405@citrix.com> <4E68C6C10200007800055485@nat28.tlf.novell.com> <4E68C09B.8050409@citrix.com> <4E68E1D30200007800055501@nat28.tlf.novell.com> <4E68C9A9.8090707@citrix.com> <4E6A2B7F.6060006@citrix.com> <4E6A4F66020000780005589B@nat28.tlf.novell.com> In-Reply-To: <4E6A4F66020000780005589B@nat28.tlf.novell.com> Content-Type: text/plain; charset="ISO-8859-1" Content-Transfer-Encoding: 7bit Cc: Keir Fraser , "xen-devel@lists.xensource.com" X-BeenThere: xen-devel@lists.xensource.com X-Mailman-Version: 2.1.5 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xensource.com Errors-To: xen-devel-bounces@lists.xensource.com On 09/09/11 16:39, Jan Beulich wrote: >>>> On 09.09.11 at 17:06, Andrew Cooper wrote: >> @@ -397,18 +397,7 @@ static void clear_IO_APIC_pin(unsigned i >> entry.trigger = 1; >> __ioapic_write_entry(apic, pin, TRUE, entry); >> } >> - if (mp_ioapics[apic].mpc_apicver >= 0x20) >> - io_apic_eoi(apic, entry.vector); >> - else { >> - /* >> - * Mechanism by which we clear remoteIRR in this case is by >> - * changing the trigger mode to edge and back to level. >> - */ >> - entry.trigger = 0; >> - __ioapic_write_entry(apic, pin, TRUE, entry); >> - entry.trigger = 1; >> - __ioapic_write_entry(apic, pin, TRUE, entry); >> - } >> + io_apic_eoi(apic, entry.vector, pin); > This should be __io_apic_eoi() - all other functions called here are the > non-locking ones, too. Questionable - I traced the calls and at this point and cant see the ioapic lock being taken. I guess it might be safer overall to use non-locking and leave the problem to whoever cleans up the irq code... >> } >> >> /* >> ... >> @@ -2622,3 +2611,86 @@ void __init init_ioapic_mappings(void) >> printk(XENLOG_INFO "IRQ limits: %u GSI, %u MSI/MSI-X\n", >> nr_irqs_gsi, nr_irqs - nr_irqs_gsi); >> } >> + >> +/* EOI an IO-APIC entry. One of vector or pin may be -1, indicating that >> + * it should be worked out using the other. This function disables interrupts >> + * and takes the ioapic_lock */ >> +void io_apic_eoi(unsigned int apic, unsigned int vector, unsigned int pin) > static? > >> +{ >> + unsigned int flags; >> + spin_lock_irqsave(&ioapic_lock, flags); >> + __io_apic_eoi(apic, vector, pin); >> + spin_unlock_irqrestore(&ioapic_lock, flags); >> +} >> + >> +/* EOI an IO-APIC entry. One of vector or pin may be -1, indicating that >> + * it should be worked out using the other. This function */ >> +void __io_apic_eoi(unsigned int apic, unsigned int vector, unsigned int pin) > static! > >> + { >> + /* Else fake an EOI by switching to edge triggered mode >> + * and back */ >> + struct IO_APIC_route_entry entry; >> + bool_t need_to_unmask = 0; >> + > You may want to assert that at least one of vector and pin is not -1. There is a BUG_ON at the top of the function if both vector and pin are -1. >> + /* If pin is unknown, search for it */ >> + if ( pin == -1 ) >> + { >> + unsigned int p; >> + for ( p = 0; p < nr_ioapic_registers[apic]; ++p ) >> + if ( __ioapic_read_entry(apic, p, TRUE).vector == vector ) >> + { >> + pin = p; >> + break; > While we seem to agree that sharing of vectors within an IO-APIC must > be prevented, I don't think this is currently being enforced, and hence > you can't just "break" here - you need to handle all matching pins. Good point - I will leave a comment to remove it when fixed. >> + } >> + >> + /* If search fails, nothing to do */ >> + if ( pin == -1 ) >> + return; >> + } >> + >> + /* If vector is unknown, read it from the IO-APIC */ >> + if ( vector == -1 ) >> + vector = __ioapic_read_entry(apic, pin, TRUE).vector; > You don't seem to use vector further down. So I dont. >> + >> + entry = __ioapic_read_entry(apic, pin, TRUE); >> + >> + if ( ! entry.mask ) >> + { >> + /* If entry is not currently masked, mask it and make >> + * a note to unmask it later */ >> + entry.mask = 1; >> + __ioapic_write_entry(apic, pin, TRUE, entry); >> + need_to_unmask = 1; >> + } >> + >> + /* Flip the trigger mode to edge and back */ >> + entry.trigger = 0; >> + __ioapic_write_entry(apic, pin, TRUE, entry); >> + entry.trigger = 1; >> + __ioapic_write_entry(apic, pin, TRUE, entry); >> + >> + if ( need_to_unmask ) >> + { >> + /* Unmask if neccesary */ >> + entry.mask = 0; >> + __ioapic_write_entry(apic, pin, TRUE, entry); >> + } >> + } >> +} >> diff -r 0268e7380953 xen/include/asm-x86/io_apic.h >> --- a/xen/include/asm-x86/io_apic.h Mon Sep 05 15:10:28 2011 +0100 >> +++ b/xen/include/asm-x86/io_apic.h Fri Sep 09 15:58:59 2011 +0100 >> @@ -157,10 +157,13 @@ static inline void io_apic_write(unsigne >> __io_apic_write(apic, reg, value); >> } >> >> -static inline void io_apic_eoi(unsigned int apic, unsigned int vector) >> -{ >> - *(IO_APIC_BASE(apic)+16) = vector; >> -} >> +#define ioapic_has_eoi_reg(apic) (mp_ioapics[(apic)].mpc_apicver >= 0x20) > Is this used outside of io_apic.c? Not according to cscope - I will adjust them appropriately. >> + >> +void __io_apic_eoi(unsigned int apic, unsigned int vector, unsigned int pin); >> +void io_apic_eoi(unsigned int apic, unsigned int vector, unsigned int pin); >> + >> +#define io_apic_eoi_vector(apic, vector) io_apic_eoi((apic), (vector), -1) >> +#define io_apic_eoi_pin(apic, pin) io_apic_eoi((apic), -1, (pin)) > None of these should be either (see also above). > > Jan > >> /* >> * Re-write a value: to be used for read-modify-write -- Andrew Cooper - Dom0 Kernel Engineer, Citrix XenServer T: +44 (0)1223 225 900, http://www.citrix.com _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel From xen-devel-bounces@lists.xensource.com Fri Sep 09 09:05:04 2011 Return-path: Envelope-to: www-data@lists.xensource.com Delivery-date: Fri, 09 Sep 2011 09:05:04 -0700 Received: from localhost ([127.0.0.1] helo=lists.colo.xensource.com) by lists.xensource.com with esmtp (Exim 4.43) id 1R23Zf-0003W9-Dl; Fri, 09 Sep 2011 09:05:03 -0700 Received: from mail182.messagelabs.com ([85.158.139.83]) by lists.xensource.com with esmtp (Exim 4.43) id 1R23XU-0003Hk-Tx for xen-devel@lists.xensource.com; Fri, 09 Sep 2011 09:03:17 -0700 X-Env-Sender: JBeulich@suse.com X-Msg-Ref: server-2.tower-182.messagelabs.com!1315584165!16737679!1 X-Originating-IP: [130.57.49.28] X-StarScan-Version: 6.3.6; banners=-,-,- X-VirusChecked: Checked Received: (qmail 24703 invoked from network); 9 Sep 2011 16:02:46 -0000 Received: from nat28.tlf.novell.com (HELO nat28.tlf.novell.com) (130.57.49.28) by server-2.tower-182.messagelabs.com with DHE-RSA-AES256-SHA encrypted SMTP; 9 Sep 2011 16:02:46 -0000 Received: from EMEA1-MTA by nat28.tlf.novell.com with Novell_GroupWise; Fri, 09 Sep 2011 17:02:45 +0100 Message-Id: <4E6A54DB02000078000558B6@nat28.tlf.novell.com> X-Mailer: Novell GroupWise Internet Agent 8.0.1 Date: Fri, 09 Sep 2011 17:03:07 +0100 From: "Jan Beulich" To: "Andrew Cooper" Subject: Re: [Xen-devel] Re: 4.0/4.1 requests - IO-APIC EOI v2 [RFC] References: <4E689D9A.1020405@citrix.com> <4E68C6C10200007800055485@nat28.tlf.novell.com> <4E68C09B.8050409@citrix.com> <4E68E1D30200007800055501@nat28.tlf.novell.com> <4E68C9A9.8090707@citrix.com> <4E6A2B7F.6060006@citrix.com> <4E6A4F66020000780005589B@nat28.tlf.novell.com> <4E6A36EB.6000802@citrix.com> In-Reply-To: <4E6A36EB.6000802@citrix.com> Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: quoted-printable Content-Disposition: inline Cc: Keir Fraser , "xen-devel@lists.xensource.com" X-BeenThere: xen-devel@lists.xensource.com X-Mailman-Version: 2.1.5 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xensource.com Errors-To: xen-devel-bounces@lists.xensource.com >>> On 09.09.11 at 17:55, Andrew Cooper wrote: > On 09/09/11 16:39, Jan Beulich wrote: >>>>> On 09.09.11 at 17:06, Andrew Cooper = wrote: >>> @@ -397,18 +397,7 @@ static void clear_IO_APIC_pin(unsigned i >>> entry.trigger =3D 1; >>> __ioapic_write_entry(apic, pin, TRUE, entry); >>> } >>> - if (mp_ioapics[apic].mpc_apicver >=3D 0x20) >>> - io_apic_eoi(apic, entry.vector); >>> - else { >>> - /* >>> - * Mechanism by which we clear remoteIRR in this case is = by >>> - * changing the trigger mode to edge and back to level. >>> - */ >>> - entry.trigger =3D 0; >>> - __ioapic_write_entry(apic, pin, TRUE, entry); >>> - entry.trigger =3D 1; >>> - __ioapic_write_entry(apic, pin, TRUE, entry); >>> - } >>> + io_apic_eoi(apic, entry.vector, pin); >> This should be __io_apic_eoi() - all other functions called here are = the >> non-locking ones, too. >=20 > Questionable - I traced the calls and at this point and cant see the > ioapic lock being taken. I guess it might be safer overall to use > non-locking and leave the problem to whoever cleans up the irq code... It indeed is not being taken, and as you say this is deliberate (we may be cleaning up in a crashed environment here). >>> + { >>> + /* Else fake an EOI by switching to edge triggered mode >>> + * and back */ >>> + struct IO_APIC_route_entry entry; >>> + bool_t need_to_unmask =3D 0; >>> + >> You may want to assert that at least one of vector and pin is not -1. >=20 > There is a BUG_ON at the top of the function if both vector and pin are = -1. Sorry, I must have missed that. Jan _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel From xen-devel-bounces@lists.xensource.com Fri Sep 09 09:06:50 2011 Return-path: Envelope-to: www-data@lists.xensource.com Delivery-date: Fri, 09 Sep 2011 09:06:50 -0700 Received: from localhost ([127.0.0.1] helo=lists.colo.xensource.com) by lists.xensource.com with esmtp (Exim 4.43) id 1R23bN-0003sk-Pr; Fri, 09 Sep 2011 09:06:49 -0700 Received: from mail21.messagelabs.com ([85.158.143.35]) by lists.xensource.com with smtp (Exim 4.43) id 1R23ak-0003h0-0b for xen-devel@lists.xensource.com; Fri, 09 Sep 2011 09:06:10 -0700 X-Env-Sender: Stefano.Stabellini@eu.citrix.com X-Msg-Ref: server-11.tower-21.messagelabs.com!1315584350!41998127!1 X-Originating-IP: [62.200.22.115] X-StarScan-Version: 6.3.6; banners=-,-,- X-VirusChecked: Checked Received: (qmail 13782 invoked from network); 9 Sep 2011 16:05:50 -0000 Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115) by server-11.tower-21.messagelabs.com with SMTP; 9 Sep 2011 16:05:50 -0000 X-IronPort-AV: E=Sophos;i="4.68,357,1312156800"; d="scan'208";a="7702895" Received: from lonpmailmx01.citrite.net ([10.30.203.162]) by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5; 09 Sep 2011 16:06:06 +0000 Received: from kaball.uk.xensource.com (10.80.2.59) by LONPMAILMX01.citrite.net (10.30.203.162) with Microsoft SMTP Server id 8.3.137.0; Fri, 9 Sep 2011 17:06:06 +0100 Date: Fri, 9 Sep 2011 17:14:20 +0100 From: Stefano Stabellini X-X-Sender: sstabellini@kaball-desktop To: Message-ID: User-Agent: Alpine 2.00 (DEB 1167 2008-08-23) MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="8323329-1145984451-1315584876=:12963" Cc: Benjamin Schweikert , Keir Fraser Subject: [Xen-devel] [PATCH] xen: if mapping GSIs we run out of pirq < nr_irqs_gsi, use the others X-BeenThere: xen-devel@lists.xensource.com X-Mailman-Version: 2.1.5 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xensource.com Errors-To: xen-devel-bounces@lists.xensource.com --8323329-1145984451-1315584876=:12963 Content-Type: text/plain; charset="US-ASCII" PV on HVM guests can have more GSIs than the host, in that case we could run out of pirq < nr_irqs_gsi. When that happens use pirq >= nr_irqs_gsi rather than returning an error. This patch should be backported to xen 4.1, the backport is attached. Signed-off-by: Stefano Stabellini Tested-by: Benjamin Schweikert diff -r 5260d04148cb xen/arch/x86/irq.c --- a/xen/arch/x86/irq.c Fri Sep 09 11:03:38 2011 +0000 +++ b/xen/arch/x86/irq.c Fri Sep 09 15:06:40 2011 +0000 @@ -1646,15 +1646,12 @@ int get_free_pirq(struct domain *d, int return i; } } - else - { - for ( i = d->nr_pirqs - 1; i >= nr_irqs_gsi; i-- ) - if ( is_free_pirq(d, pirq_info(d, i)) ) - { - pirq_get_info(d, i); - return i; - } - } + for ( i = d->nr_pirqs - 1; i >= nr_irqs_gsi; i-- ) + if ( is_free_pirq(d, pirq_info(d, i)) ) + { + pirq_get_info(d, i); + return i; + } return -ENOSPC; } --8323329-1145984451-1315584876=:12963 Content-Type: text/plain; charset="US-ASCII"; name="patch" Content-Transfer-Encoding: BASE64 Content-ID: Content-Description: Content-Disposition: attachment; filename="patch" DQpkaWZmIC1yIDc4ZDhjNTIyN2JiMSB4ZW4vYXJjaC94ODYvaXJxLmMNCi0t LSBhL3hlbi9hcmNoL3g4Ni9pcnEuYwlUaHUgU2VwIDA4IDEyOjI0OjM1IDIw MTEgKzAxMDANCisrKyBiL3hlbi9hcmNoL3g4Ni9pcnEuYwlGcmkgU2VwIDA5 IDE1OjA0OjQ0IDIwMTEgKzAwMDANCkBAIC0xNDYzLDI0ICsxNDYzLDE4IEBA IGludCBnZXRfZnJlZV9waXJxKHN0cnVjdCBkb21haW4gKmQsIGludCANCiAg ICAgICAgICAgICB7DQogICAgICAgICAgICAgICAgIGlmICggIWlzX2h2bV9k b21haW4oZCkgfHwNCiAgICAgICAgICAgICAgICAgICAgICAgICBkLT5hcmNo LnBpcnFfZW11aXJxW2ldID09IElSUV9VTkJPVU5EICkNCi0gICAgICAgICAg ICAgICAgICAgIGJyZWFrOw0KKyAgICAgICAgICAgICAgICAgICAgcmV0dXJu IGk7DQogICAgICAgICAgICAgfQ0KLSAgICAgICAgaWYgKCBpID09IG5yX2ly cXNfZ3NpICkNCi0gICAgICAgICAgICByZXR1cm4gLUVOT1NQQzsNCiAgICAg fQ0KLSAgICBlbHNlDQotICAgIHsNCi0gICAgICAgIGZvciAoIGkgPSBkLT5u cl9waXJxcyAtIDE7IGkgPj0gbnJfaXJxc19nc2k7IGktLSApDQotICAgICAg ICAgICAgaWYgKCAhZC0+YXJjaC5waXJxX2lycVtpXSApDQotICAgICAgICAg ICAgew0KLSAgICAgICAgICAgICAgICBpZiAoICFpc19odm1fZG9tYWluKGQp IHx8DQotICAgICAgICAgICAgICAgICAgICAgICAgZC0+YXJjaC5waXJxX2Vt dWlycVtpXSA9PSBJUlFfVU5CT1VORCApDQotICAgICAgICAgICAgICAgICAg ICBicmVhazsNCi0gICAgICAgICAgICB9DQotICAgICAgICBpZiAoIGkgPCBu cl9pcnFzX2dzaSApDQotICAgICAgICAgICAgcmV0dXJuIC1FTk9TUEM7DQot ICAgIH0NCi0NCisgICAgZm9yICggaSA9IGQtPm5yX3BpcnFzIC0gMTsgaSA+ PSBucl9pcnFzX2dzaTsgaS0tICkNCisgICAgICAgIGlmICggIWQtPmFyY2gu cGlycV9pcnFbaV0gKQ0KKyAgICAgICAgew0KKyAgICAgICAgICAgIGlmICgg IWlzX2h2bV9kb21haW4oZCkgfHwNCisgICAgICAgICAgICAgICAgICAgIGQt PmFyY2gucGlycV9lbXVpcnFbaV0gPT0gSVJRX1VOQk9VTkQgKQ0KKyAgICAg ICAgICAgICAgICBicmVhazsNCisgICAgICAgIH0NCisgICAgaWYgKCBpIDwg bnJfaXJxc19nc2kgKQ0KKyAgICAgICAgcmV0dXJuIC1FTk9TUEM7DQogICAg IHJldHVybiBpOw0KIH0NCiANCg== --8323329-1145984451-1315584876=:12963 Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel --8323329-1145984451-1315584876=:12963-- From xen-devel-bounces@lists.xensource.com Fri Sep 09 09:10:47 2011 Return-path: Envelope-to: www-data@lists.xensource.com Delivery-date: Fri, 09 Sep 2011 09:10:47 -0700 Received: from localhost ([127.0.0.1] helo=lists.colo.xensource.com) by lists.xensource.com with esmtp (Exim 4.43) id 1R23fC-0004I0-9G; Fri, 09 Sep 2011 09:10:46 -0700 Received: from mail21.messagelabs.com ([85.158.143.35]) by lists.xensource.com with esmtp (Exim 4.43) id 1R23eV-00045j-Hm for xen-devel@lists.xensource.com; Fri, 09 Sep 2011 09:10:03 -0700 X-Env-Sender: Wei.Huang2@amd.com X-Msg-Ref: server-3.tower-21.messagelabs.com!1315584610!50977289!1 X-Originating-IP: [65.55.88.14] X-StarScan-Version: 6.3.6; banners=-,-,- X-VirusChecked: Checked Received: (qmail 24358 invoked from network); 9 Sep 2011 16:10:12 -0000 Received: from tx2ehsobe004.messaging.microsoft.com (HELO TX2EHSOBE008.bigfish.com) (65.55.88.14) by server-3.tower-21.messagelabs.com with AES128-SHA encrypted SMTP; 9 Sep 2011 16:10:12 -0000 Received: from mail123-tx2-R.bigfish.com (10.9.14.245) by TX2EHSOBE008.bigfish.com (10.9.40.28) with Microsoft SMTP Server id 14.1.225.22; Fri, 9 Sep 2011 16:09:59 +0000 Received: from mail123-tx2 (localhost.localdomain [127.0.0.1]) by mail123-tx2-R.bigfish.com (Postfix) with ESMTP id 030DF1070199; Fri, 9 Sep 2011 16:09:59 +0000 (UTC) X-SpamScore: 1 X-BigFish: VPS1(zzbb2dK9371Kc89bh1432N98dKzz1202hzz8275bhz32i668h839haaw) X-Forefront-Antispam-Report: CIP:163.181.249.108; KIP:(null); UIP:(null); IPVD:NLI; H:ausb3twp01.amd.com; RD:none; EFVD:NLI Received: from mail123-tx2 (localhost.localdomain [127.0.0.1]) by mail123-tx2 (MessageSwitch) id 1315584596872911_29908; Fri, 9 Sep 2011 16:09:56 +0000 (UTC) Received: from TX2EHSMHS006.bigfish.com (unknown [10.9.14.248]) by mail123-tx2.bigfish.com (Postfix) with ESMTP id C526915D8055; Fri, 9 Sep 2011 16:09:56 +0000 (UTC) Received: from ausb3twp01.amd.com (163.181.249.108) by TX2EHSMHS006.bigfish.com (10.9.99.106) with Microsoft SMTP Server id 14.1.225.22; Fri, 9 Sep 2011 16:09:55 +0000 X-WSS-ID: 0LR9JKH-01-3FC-02 X-M-MSG: Received: from sausexedgep02.amd.com (sausexedgep02-ext.amd.com [163.181.249.73]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by ausb3twp01.amd.com (Axway MailGate 3.8.1) with ESMTP id 2F87C10280D3; Fri, 9 Sep 2011 11:09:52 -0500 (CDT) Received: from sausexhtp01.amd.com (163.181.3.165) by sausexedgep02.amd.com (163.181.36.59) with Microsoft SMTP Server (TLS) id 8.3.106.1; Fri, 9 Sep 2011 11:09:59 -0500 Received: from [10.236.48.105] (10.236.48.105) by sausexhtp01.amd.com (163.181.3.165) with Microsoft SMTP Server id 8.3.83.0; Fri, 9 Sep 2011 11:09:52 -0500 Message-ID: <4E6A3A51.7020903@amd.com> Date: Fri, 9 Sep 2011 11:09:53 -0500 From: Wei Huang User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.2.14) Gecko/20110223 Thunderbird/3.1.8 MIME-Version: 1.0 To: =?ISO-8859-1?Q?Pasi_K=E4rkk=E4inen?= Subject: Re: Re : Re : Re : [Xen-devel] Re: Patches for VGA-Passthrough XEN 4.2 unstable References: <1315343879.61837.YahooMailNeo@web29818.mail.ird.yahoo.com> <1315382742268-4777689.post@n5.nabble.com> <1315389138.56652.YahooMailNeo@web29801.mail.ird.yahoo.com> <1315398360680-4778339.post@n5.nabble.com> <1315401901083-4778494.post@n5.nabbleZ12984@reaktio.net> In-Reply-To: <20110909132822.GZ12984@reaktio.net> Content-Type: text/plain; charset="ISO-8859-1"; format=flowed Content-Transfer-Encoding: quoted-printable X-OriginatorOrg: amd.com Cc: komkon555 , "xen-devel@lists.xensource.com" X-BeenThere: xen-devel@lists.xensource.com X-Mailman-Version: 2.1.5 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xensource.com Errors-To: xen-devel-bounces@lists.xensource.com I used this approach before and it worked for me. -Wei On 09/09/2011 08:28 AM, Pasi K=E4rkk=E4inen wrote: > On Fri, Sep 09, 2011 at 12:54:07AM -0700, komkon555 wrote: >> Hi. There is the promised report to JavMV: with fixes on d= sd are >> your patches also functional. Windows XP starts and GTX260 works perfe= ct >> with driver version 275.33. >> Some news more: The best results I got with this configurat= ion: >> xen 4.1-unstable changeset 21668 (patched clearly with these >> http://lists.xensource.com/archives/html/xen-devel/2010-05/msg00441.ht= ml >> patches , dsd fixed according to David TECHER) + jeremi xen kernel 2.6= .32.45 >> (xenfs static). This configuration works excellent both: with primary = and >> secondary vga-adapter (GTX260). There are two Problem with all >> configurations: >> 1. DomU can be started only once. Being correctly shouted down, star= ts >> DomU no more. >> 2. Physical usb- keyboard and mouse can not be assigned to DomU (regul= ar usb >> assignment has no effect, PVUSB crashes) >> > Did you try normal PCI passthru? passthru the whole USB controller pci = device.. > > -- Pasi > > > _______________________________________________ > Xen-devel mailing list > Xen-devel@lists.xensource.com > http://lists.xensource.com/xen-devel > _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel From xen-devel-bounces@lists.xensource.com Fri Sep 09 09:11:51 2011 Return-path: Envelope-to: www-data@lists.xensource.com Delivery-date: Fri, 09 Sep 2011 09:11:51 -0700 Received: from localhost ([127.0.0.1] helo=lists.colo.xensource.com) by lists.xensource.com with esmtp (Exim 4.43) id 1R23gE-0004et-VK; Fri, 09 Sep 2011 09:11:50 -0700 Received: from mail216.messagelabs.com ([85.158.143.99]) by lists.xensource.com with esmtp (Exim 4.43) id 1R23fh-0004Rn-SC for xen-devel@lists.xensource.com; Fri, 09 Sep 2011 09:11:19 -0700 X-Env-Sender: eric.camachat@gmail.com X-Msg-Ref: server-3.tower-216.messagelabs.com!1315584673!16668565!1 X-Originating-IP: [74.125.83.41] X-StarScan-Version: 6.3.6; banners=-,-,- X-VirusChecked: Checked Received: (qmail 5028 invoked from network); 9 Sep 2011 16:11:14 -0000 Received: from mail-gw0-f41.google.com (HELO mail-gw0-f41.google.com) (74.125.83.41) by server-3.tower-216.messagelabs.com with RC4-SHA encrypted SMTP; 9 Sep 2011 16:11:14 -0000 Received: by gwaa20 with SMTP id a20so1278493gwa.28 for ; Fri, 09 Sep 2011 09:11:13 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type:content-transfer-encoding; bh=SYU0MAD5lBZ1uzLiNaCOFGbe/lxe7F/ReMLWlicC45M=; b=J5bK0JEApdB+cmHt4k7U9+iQs2cQQAOR71F4wx/Ldr9X7rYM4KNrojcjZVTYTdfFqH 3DqUEfZ1XHcGQfmbmpYvVmwwxqJE6ncKdnABrvFacLUhBGRPNs7ODAIJBjwcERwxQCuA 8ziFoO3sUhuBswNUcwW477O/Hw51CaaYKe3hs= Received: by 10.236.191.74 with SMTP id f50mr12964989yhn.66.1315584673258; Fri, 09 Sep 2011 09:11:13 -0700 (PDT) MIME-Version: 1.0 Received: by 10.236.95.5 with HTTP; Fri, 9 Sep 2011 09:10:53 -0700 (PDT) In-Reply-To: <20110909010550.GB9060@dumpdata.com> References: <20110908125920.GC28591@dumpdata.com> <20110908181205.GA19078@dumpdata.com> <20110908200038.GB21186@dumpdata.com> <20110909010550.GB9060@dumpdata.com> From: Eric Camachat Date: Fri, 9 Sep 2011 09:10:53 -0700 Message-ID: Subject: Re: [Xen-devel] Can I specify a physical memory region for a domU To: Konrad Rzeszutek Wilk Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Cc: xen-devel@lists.xensource.com X-BeenThere: xen-devel@lists.xensource.com X-Mailman-Version: 2.1.5 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xensource.com Errors-To: xen-devel-bounces@lists.xensource.com On Thu, Sep 8, 2011 at 6:05 PM, Konrad Rzeszutek Wilk wrote: > On Thu, Sep 08, 2011 at 05:15:06PM -0700, Eric Camachat wrote: >> On Thu, Sep 8, 2011 at 1:00 PM, Konrad Rzeszutek Wilk >> wrote: >> >> > Make sure you set >> >> > =C2=A0pci_set_consistent_dma_mask(dev, DMA_BIT_MASK(31)); >> >> > >> >> > on top of pci_set_dma_mask(dev, DMA_BIT_MASK(31)); >> >> > in your driver. >> >> > >> >> A lot of work to port the driver to PV domU, hope it works. >> > >> > Hm? That is the normal way you would write drivers in the Linux kernel= . >> > You use the DMA API in it to deal with the PCI devices. >> > >> > Is the PV domU a Linux kernel or something else? >> > >> >> Yes, the PV domU is linux kernel. >> >> I tested pci_alloc_consistent() verified on baremetal it worked with 8GB= SDRAM. >> But while I ran it in XEN, pci_alloc_consistent() cannot allocate >> memory successfully for 4MB although pci_set_dma_mask(), > > And what is the error? I cannot see any error, it just returned NULL. > >> pci_set_consistent_dma_mask() and dma_set_mask() all succeeded. > > And what kernel did you use? I am using linux-2.6.32.24. >> >> _______________________________________________ >> Xen-devel mailing list >> Xen-devel@lists.xensource.com >> http://lists.xensource.com/xen-devel > _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel From xen-devel-bounces@lists.xensource.com Fri Sep 09 09:17:51 2011 Return-path: Envelope-to: www-data@lists.xensource.com Delivery-date: Fri, 09 Sep 2011 09:17:51 -0700 Received: from localhost ([127.0.0.1] helo=lists.colo.xensource.com) by lists.xensource.com with esmtp (Exim 4.43) id 1R23m3-0005Ay-FT; Fri, 09 Sep 2011 09:17:51 -0700 Received: from mail182.messagelabs.com ([85.158.139.83]) by lists.xensource.com with esmtp (Exim 4.43) id 1R23la-0004zO-Hk for xen-devel@lists.xensource.com; Fri, 09 Sep 2011 09:17:22 -0700 X-Env-Sender: Wei.Huang2@amd.com X-Msg-Ref: server-11.tower-182.messagelabs.com!1315585038!17738420!1 X-Originating-IP: [216.32.181.183] X-StarScan-Version: 6.3.6; banners=-,-,- X-VirusChecked: Checked Received: (qmail 22786 invoked from network); 9 Sep 2011 16:17:19 -0000 Received: from ch1ehsobe003.messaging.microsoft.com (HELO ch1outboundpool.messaging.microsoft.com) (216.32.181.183) by server-11.tower-182.messagelabs.com with AES128-SHA encrypted SMTP; 9 Sep 2011 16:17:19 -0000 Received: from mail155-ch1-R.bigfish.com (216.32.181.172) by CH1EHSOBE006.bigfish.com (10.43.70.56) with Microsoft SMTP Server id 14.1.225.22; Fri, 9 Sep 2011 16:17:17 +0000 Received: from mail155-ch1 (localhost.localdomain [127.0.0.1]) by mail155-ch1-R.bigfish.com (Postfix) with ESMTP id B626EDD04A7; Fri, 9 Sep 2011 16:17:17 +0000 (UTC) X-SpamScore: 10 X-BigFish: VPS10(zz1432Nzz1202hzz8275bhz32i668h839haaw62h) X-Spam-TCS-SCL: 1:0 X-Forefront-Antispam-Report: CIP:163.181.249.108; KIP:(null); UIP:(null); IPVD:NLI; H:ausb3twp01.amd.com; RD:none; EFVD:NLI Received: from mail155-ch1 (localhost.localdomain [127.0.0.1]) by mail155-ch1 (MessageSwitch) id 1315585037607089_22159; Fri, 9 Sep 2011 16:17:17 +0000 (UTC) Received: from CH1EHSMHS022.bigfish.com (snatpool1.int.messaging.microsoft.com [10.43.68.247]) by mail155-ch1.bigfish.com (Postfix) with ESMTP id 8895B140052; Fri, 9 Sep 2011 16:17:17 +0000 (UTC) Received: from ausb3twp01.amd.com (163.181.249.108) by CH1EHSMHS022.bigfish.com (10.43.70.22) with Microsoft SMTP Server id 14.1.225.22; Fri, 9 Sep 2011 16:17:08 +0000 X-WSS-ID: 0LR9JWG-01-3VK-02 X-M-MSG: Received: from sausexedgep02.amd.com (sausexedgep02-ext.amd.com [163.181.249.73]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by ausb3twp01.amd.com (Axway MailGate 3.8.1) with ESMTP id 274F310280CC; Fri, 9 Sep 2011 11:17:04 -0500 (CDT) Received: from sausexhtp01.amd.com (163.181.3.165) by sausexedgep02.amd.com (163.181.36.59) with Microsoft SMTP Server (TLS) id 8.3.106.1; Fri, 9 Sep 2011 11:17:11 -0500 Received: from [10.236.48.105] (10.236.48.105) by sausexhtp01.amd.com (163.181.3.165) with Microsoft SMTP Server id 8.3.83.0; Fri, 9 Sep 2011 11:17:04 -0500 Message-ID: <4E6A3C00.9060401@amd.com> Date: Fri, 9 Sep 2011 11:17:04 -0500 From: Wei Huang User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.2.14) Gecko/20110223 Thunderbird/3.1.8 MIME-Version: 1.0 To: Liwei Subject: Re: [Xen-devel] Re: Patches for VGA-Passthrough XEN 4.2 unstable References: In-Reply-To: Content-Type: text/plain; charset="ISO-8859-1"; format=flowed Content-Transfer-Encoding: 7bit X-OriginatorOrg: amd.com Cc: komkon555 , xen-devel X-BeenThere: xen-devel@lists.xensource.com X-Mailman-Version: 2.1.5 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xensource.com Errors-To: xen-devel-bounces@lists.xensource.com Curiously, have you tried crossfire with these two 6870 cards? -Wei > Personally I'm having positive experiences with AMD cards. Currently > running two ATI 6870s in a 64-bit Windows 7 DomU. Best thing is, > they're working alright without any patches on xen-unstable. However, > similar to what you have experienced, DomU cannot be restarted in this > configuration. It can be fixed, but I haven't got the time to get down > to it. > > Regarding your problem with passing through the USB controller, have > you tried it without the VGA passthrough patches? IMO it may not be > related to the passthrough patches. > >> Best regards >> Kom. >> > _______________________________________________ > Xen-devel mailing list > Xen-devel@lists.xensource.com > http://lists.xensource.com/xen-devel > _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel From xen-devel-bounces@lists.xensource.com Fri Sep 09 09:24:30 2011 Return-path: Envelope-to: www-data@lists.xensource.com Delivery-date: Fri, 09 Sep 2011 09:24:30 -0700 Received: from localhost ([127.0.0.1] helo=lists.colo.xensource.com) by lists.xensource.com with esmtp (Exim 4.43) id 1R23sT-0005dK-VC; Fri, 09 Sep 2011 09:24:29 -0700 Received: from mail174.messagelabs.com ([85.158.138.51]) by lists.xensource.com with esmtp (Exim 4.43) id 1R23s0-0005R4-Vn for xen-devel@lists.xensource.com; Fri, 09 Sep 2011 09:24:01 -0700 X-Env-Sender: Andrew.Cooper3@citrix.com X-Msg-Ref: server-4.tower-174.messagelabs.com!1315585373!30885337!1 X-Originating-IP: [66.165.176.63] X-StarScan-Version: 6.3.6; banners=-,-,- X-VirusChecked: Checked Received: (qmail 14793 invoked from network); 9 Sep 2011 16:23:57 -0000 Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63) by server-4.tower-174.messagelabs.com with RC4-SHA encrypted SMTP; 9 Sep 2011 16:23:57 -0000 X-IronPort-AV: E=Sophos;i="4.68,357,1312171200"; d="scan'208";a="162351204" Received: from ftlpmailmx02.citrite.net ([10.13.107.66]) by FTLPIPO02.CITRIX.COM with ESMTP/TLS/RC4-MD5; 09 Sep 2011 12:22:52 -0400 Received: from [10.80.2.18] (10.80.2.18) by FTLPMAILMX02.citrite.net (10.13.107.66) with Microsoft SMTP Server id 8.3.137.0; Fri, 9 Sep 2011 12:22:52 -0400 Message-ID: <4E6A3D5B.5010104@citrix.com> Date: Fri, 9 Sep 2011 17:22:51 +0100 From: Andrew Cooper User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.2.21) Gecko/20110831 Lightning/1.0b2 Thunderbird/3.1.13 MIME-Version: 1.0 To: Jan Beulich Subject: Re: [Xen-devel] Re: 4.0/4.1 requests - IO-APIC EOI v3 [RFC] References: <4E689D9A.1020405@citrix.com> <4E68C6C10200007800055485@nat28.tlf.novell.com> <4E68C09B.8050409@citrix.com> <4E68E1D30200007800055501@nat28.tlf.novell.com> <4E68C9A9.8090707@citrix.com> <4E6A2B7F.6060006@citrix.com> <4E6A4F66020000780005589B@nat28.tlf.novell.com> <4E6A36EB.6000802@citrix.com> <4E6A54DB02000078000558B6@nat28.tlf.novell.com> In-Reply-To: <4E6A54DB02000078000558B6@nat28.tlf.novell.com> Content-Type: multipart/mixed; boundary="------------070607040802090401010001" Cc: Keir Fraser , "xen-devel@lists.xensource.com" X-BeenThere: xen-devel@lists.xensource.com X-Mailman-Version: 2.1.5 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xensource.com Errors-To: xen-devel-bounces@lists.xensource.com --------------070607040802090401010001 Content-Type: text/plain; charset="ISO-8859-1" Content-Transfer-Encoding: 7bit ---SNIP--- Version 3. Applied Jan's suggestions, and extended some of the comments. -- Andrew Cooper - Dom0 Kernel Engineer, Citrix XenServer T: +44 (0)1223 225 900, http://www.citrix.com --------------070607040802090401010001 Content-Type: text/x-patch; name="IO-APIC-eoi.patch" Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename="IO-APIC-eoi.patch" diff -r 0268e7380953 xen/arch/x86/io_apic.c --- a/xen/arch/x86/io_apic.c Mon Sep 05 15:10:28 2011 +0100 +++ b/xen/arch/x86/io_apic.c Fri Sep 09 17:20:49 2011 +0100 @@ -68,6 +68,16 @@ int __read_mostly nr_ioapics; #define MAX_PLUS_SHARED_IRQS nr_irqs_gsi #define PIN_MAP_SIZE (MAX_PLUS_SHARED_IRQS + nr_irqs_gsi) + +#define ioapic_has_eoi_reg(apic) (mp_ioapics[(apic)].mpc_apicver >= 0x20) + +static void __io_apic_eoi(unsigned int apic, unsigned int vector, unsigned int pin); +static void io_apic_eoi(unsigned int apic, unsigned int vector, unsigned int pin); + +#define io_apic_eoi_vector(apic, vector) io_apic_eoi((apic), (vector), -1) +#define io_apic_eoi_pin(apic, pin) io_apic_eoi((apic), -1, (pin)) + + /* * This is performance-critical, we want to do it O(1) * @@ -357,7 +367,7 @@ static void __eoi_IO_APIC_irq(unsigned i pin = entry->pin; if (pin == -1) break; - io_apic_eoi(entry->apic, vector); + __io_apic_eoi(entry->apic, vector, pin); if (!entry->next) break; entry = irq_2_pin + entry->next; @@ -397,18 +407,7 @@ static void clear_IO_APIC_pin(unsigned i entry.trigger = 1; __ioapic_write_entry(apic, pin, TRUE, entry); } - if (mp_ioapics[apic].mpc_apicver >= 0x20) - io_apic_eoi(apic, entry.vector); - else { - /* - * Mechanism by which we clear remoteIRR in this case is by - * changing the trigger mode to edge and back to level. - */ - entry.trigger = 0; - __ioapic_write_entry(apic, pin, TRUE, entry); - entry.trigger = 1; - __ioapic_write_entry(apic, pin, TRUE, entry); - } + __io_apic_eoi(apic, entry.vector, pin); } /* @@ -1750,7 +1749,7 @@ static void end_level_ioapic_irq (unsign { int ioapic; for (ioapic = 0; ioapic < nr_ioapics; ioapic++) - io_apic_eoi(ioapic, i); + io_apic_eoi_vector(ioapic, i); } v = apic_read(APIC_TMR + ((i & ~0x1f) >> 1)); @@ -2622,3 +2621,124 @@ void __init init_ioapic_mappings(void) printk(XENLOG_INFO "IRQ limits: %u GSI, %u MSI/MSI-X\n", nr_irqs_gsi, nr_irqs - nr_irqs_gsi); } + +/* EOI an IO-APIC entry. One of vector or pin may be -1, indicating that + * it should be worked out using the other. This function disables interrupts + * and takes the ioapic_lock */ +static void io_apic_eoi(unsigned int apic, unsigned int vector, unsigned int pin) +{ + unsigned int flags; + spin_lock_irqsave(&ioapic_lock, flags); + __io_apic_eoi(apic, vector, pin); + spin_unlock_irqrestore(&ioapic_lock, flags); +} + +/* EOI an IO-APIC entry. One of vector or pin may be -1, indicating that + * it should be worked out using the other. This function expect that the + * ioapic_lock is taken, and interrupts are disabled (or there is a good reason + * not to), and that if both pin and vector are passed, that they refer to the + * same redirection entry in the IO-APIC. */ +static void __io_apic_eoi(unsigned int apic, unsigned int vector, unsigned int pin) +{ + /* Ensure some useful information is passed in */ + BUG_ON( !(vector == -1 && pin != -1) ); + + /* Prefer the use of the EOI register if available */ + if ( ioapic_has_eoi_reg(apic) ) + { + /* If vector is unknown, read it from the IO-APIC */ + if ( vector == -1 ) + vector = __ioapic_read_entry(apic, pin, TRUE).vector; + + *(IO_APIC_BASE(apic)+16) = vector; + } + else + { + /* Else fake an EOI by switching to edge triggered mode + * and back */ + struct IO_APIC_route_entry entry; + bool_t need_to_unmask = 0; + + /* If pin is unknown, search for it */ + if ( pin == -1 ) + { + unsigned int p; + for ( p = 0; p < nr_ioapic_registers[apic]; ++p ) + { + entry = __ioapic_read_entry(apic, p, TRUE); + if ( entry.vector == vector ) + { + pin = p; + /* break; */ + + /* Here should be a break out of the loop, but at the + * Xen code doesn't actually prevent multiple IO-APIC + * entries being assigned the same vector, so EOI all + * pins which have the correct vector. + * + * Remove the following code when the above assertion + * is fulfilled. */ + + if ( ! entry.mask ) + { + /* If entry is not currently masked, mask it and make + * a note to unmask it later */ + entry.mask = 1; + __ioapic_write_entry(apic, pin, TRUE, entry); + need_to_unmask = 1; + } + + /* Flip the trigger mode to edge and back */ + entry.trigger = 0; + __ioapic_write_entry(apic, pin, TRUE, entry); + entry.trigger = 1; + __ioapic_write_entry(apic, pin, TRUE, entry); + + if ( need_to_unmask ) + { + /* Unmask if neccesary */ + entry.mask = 0; + __ioapic_write_entry(apic, pin, TRUE, entry); + } + + } + } + + /* If search fails, nothing to do */ + + /* if ( pin == -1 ) */ + + /* Because the loop wasn't broken out of (see comment above), + * all relevant pins have been EOI, so we can always return. + * + * Re-instate the if statement above when the Xen logic has been + * fixed.*/ + + return; + } + + entry = __ioapic_read_entry(apic, pin, TRUE); + + if ( ! entry.mask ) + { + /* If entry is not currently masked, mask it and make + * a note to unmask it later */ + entry.mask = 1; + __ioapic_write_entry(apic, pin, TRUE, entry); + need_to_unmask = 1; + } + + /* Flip the trigger mode to edge and back */ + entry.trigger = 0; + __ioapic_write_entry(apic, pin, TRUE, entry); + entry.trigger = 1; + __ioapic_write_entry(apic, pin, TRUE, entry); + + if ( need_to_unmask ) + { + /* Unmask if neccesary */ + entry.mask = 0; + __ioapic_write_entry(apic, pin, TRUE, entry); + } + } +} diff -r 0268e7380953 xen/include/asm-x86/io_apic.h --- a/xen/include/asm-x86/io_apic.h Mon Sep 05 15:10:28 2011 +0100 +++ b/xen/include/asm-x86/io_apic.h Fri Sep 09 17:20:49 2011 +0100 @@ -157,11 +157,6 @@ static inline void io_apic_write(unsigne __io_apic_write(apic, reg, value); } -static inline void io_apic_eoi(unsigned int apic, unsigned int vector) -{ - *(IO_APIC_BASE(apic)+16) = vector; -} - /* * Re-write a value: to be used for read-modify-write * cycles where the read already set up the index register. --------------070607040802090401010001 Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel --------------070607040802090401010001-- From xen-devel-bounces@lists.xensource.com Fri Sep 09 09:35:23 2011 Return-path: Envelope-to: www-data@lists.xensource.com Delivery-date: Fri, 09 Sep 2011 09:35:23 -0700 Received: from localhost ([127.0.0.1] helo=lists.colo.xensource.com) by lists.xensource.com with esmtp (Exim 4.43) id 1R2431-0006J5-Hf; Fri, 09 Sep 2011 09:35:23 -0700 Received: from mail21.messagelabs.com ([85.158.143.35]) by lists.xensource.com with smtp (Exim 4.43) id 1R242U-00065H-77 for xen-devel@lists.xensource.com; Fri, 09 Sep 2011 09:34:51 -0700 X-Env-Sender: Stefano.Stabellini@eu.citrix.com X-Msg-Ref: server-8.tower-21.messagelabs.com!1315586072!58384858!1 X-Originating-IP: [62.200.22.115] X-StarScan-Version: 6.3.6; banners=-,-,- X-VirusChecked: Checked Received: (qmail 22427 invoked from network); 9 Sep 2011 16:34:32 -0000 Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115) by server-8.tower-21.messagelabs.com with SMTP; 9 Sep 2011 16:34:32 -0000 X-IronPort-AV: E=Sophos;i="4.68,357,1312156800"; d="scan'208";a="7703470" Received: from lonpmailmx01.citrite.net ([10.30.203.162]) by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5; 09 Sep 2011 16:34:47 +0000 Received: from kaball.uk.xensource.com (10.80.2.59) by LONPMAILMX01.citrite.net (10.30.203.162) with Microsoft SMTP Server id 8.3.137.0; Fri, 9 Sep 2011 17:34:47 +0100 Date: Fri, 9 Sep 2011 17:43:01 +0100 From: Stefano Stabellini X-X-Sender: sstabellini@kaball-desktop To: Ian Campbell Subject: Re: [Xen-devel] [PATCH v2 3/4] Clone and build upstream Qemu by default In-Reply-To: <1315576788.3180.60.camel@cthulhu.hellion.org.uk> Message-ID: References: <1315504038-21733-1-git-send-email-stefano.stabellini@eu.citrix.com> <1315504038-21733-3-git-send-email-stefano.stabellini@eu.citrix.com> <1315504587.3180.47.camel@cthulhu.hellion.org.uk> <1315576788.3180.60.camel@cthulhu.hellion.org.uk> User-Agent: Alpine 2.00 (DEB 1167 2008-08-23) MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Cc: "xen-devel@lists.xensource.com" , "keir@xen.org" , Stefano Stabellini X-BeenThere: xen-devel@lists.xensource.com X-Mailman-Version: 2.1.5 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xensource.com Errors-To: xen-devel-bounces@lists.xensource.com On Fri, 9 Sep 2011, Ian Campbell wrote: > In technical terms perhaps not but for practical reasons we want the > default tree which we point people to live next to all the other default > trees, otherwise they won't be able to reliably find it the sea of suchs > trees which we will eventually have under /people/. Linus' tree being > just one of a thousand trees under git.kernel.org was always a pain > IMHO. > > We also want to test and automatically push a tested branch like we do > for the other trees and we really don't want to give the test system > access to your (or anyone else's) xenbits account. > > With the number of trees which we have now we should maybe consider > putting each branch in a subdir: > [/staging]/xen-unstable/xen.hg > /qemu-xen.hg > /qemu.git > /seabios.git > [/staging]/xen-4.2/xen.hg > /... > > ? (staging could also go after the dir I suppose) Fair enough. However it shouldn't block these patches. _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel From xen-devel-bounces@lists.xensource.com Fri Sep 09 09:43:22 2011 Return-path: Envelope-to: www-data@lists.xensource.com Delivery-date: Fri, 09 Sep 2011 09:43:22 -0700 Received: from localhost ([127.0.0.1] helo=lists.colo.xensource.com) by lists.xensource.com with esmtp (Exim 4.43) id 1R24Ak-0006qF-Dr; Fri, 09 Sep 2011 09:43:22 -0700 Received: from mail182.messagelabs.com ([85.158.139.83]) by lists.xensource.com with esmtp (Exim 4.43) id 1R24AH-0006dy-HS for xen-devel@lists.xensource.com; Fri, 09 Sep 2011 09:42:53 -0700 X-Env-Sender: xieliwei@gmail.com X-Msg-Ref: server-3.tower-182.messagelabs.com!1315586569!14941892!1 X-Originating-IP: [209.85.160.171] X-StarScan-Version: 6.3.6; banners=-,-,- X-VirusChecked: Checked Received: (qmail 25232 invoked from network); 9 Sep 2011 16:42:50 -0000 Received: from mail-gy0-f171.google.com (HELO mail-gy0-f171.google.com) (209.85.160.171) by server-3.tower-182.messagelabs.com with RC4-SHA encrypted SMTP; 9 Sep 2011 16:42:50 -0000 Received: by gyh3 with SMTP id 3so490426gyh.30 for ; Fri, 09 Sep 2011 09:42:49 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=CTxntXDcLibTL9elAX6hA1vqFer/nljWnYJ/+1TagLg=; b=Z1jh/J6GAqH1IAnD9OX5RwpQZlCyTR+ItIvtPv2ztBBEzToEKrSdjuFpMOK9uNgZUo LFBrcapqVxeyf3q69TvKUlZ0C1cWrIuG8wDdpvHS0SqouYhFkPi92n+EHTRUeTUX5iTN 4kHqgJ6nCgxZVPWdkkMYEtwfueQ9ZEc++Ruxc= Received: by 10.101.131.14 with SMTP id i14mr2107693ann.47.1315586569132; Fri, 09 Sep 2011 09:42:49 -0700 (PDT) MIME-Version: 1.0 Received: by 10.100.191.1 with HTTP; Fri, 9 Sep 2011 09:42:29 -0700 (PDT) In-Reply-To: <4E6A3C00.9060401@amd.com> References: <4E6A3C00.9060401@amd.com> From: Liwei Date: Sat, 10 Sep 2011 00:42:29 +0800 Message-ID: Subject: Re: [Xen-devel] Re: Patches for VGA-Passthrough XEN 4.2 unstable To: Wei Huang Content-Type: text/plain; charset=ISO-8859-1 Cc: komkon555 , xen-devel X-BeenThere: xen-devel@lists.xensource.com X-Mailman-Version: 2.1.5 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xensource.com Errors-To: xen-devel-bounces@lists.xensource.com On 10 September 2011 00:17, Wei Huang wrote: > Curiously, have you tried crossfire with these two 6870 cards? > > -Wei > Unfortunately no, the motherboard doesn't support crossfire (only SLI) nor does it come with the required ribbon cable. Maybe I'll source one from someone else or eBay and give it a try. I'm curious about it too. _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel From xen-devel-bounces@lists.xensource.com Fri Sep 09 09:47:49 2011 Return-path: Envelope-to: www-data@lists.xensource.com Delivery-date: Fri, 09 Sep 2011 09:47:49 -0700 Received: from localhost ([127.0.0.1] helo=lists.colo.xensource.com) by lists.xensource.com with esmtp (Exim 4.43) id 1R24F3-0007HI-Iq; Fri, 09 Sep 2011 09:47:49 -0700 Received: from mail21.messagelabs.com ([85.158.143.35]) by lists.xensource.com with esmtp (Exim 4.43) id 1R24ET-000757-Qj for xen-devel@lists.xensource.com; Fri, 09 Sep 2011 09:47:14 -0700 X-Env-Sender: Andrew.Cooper3@citrix.com X-Msg-Ref: server-11.tower-21.messagelabs.com!1315586813!42002082!1 X-Originating-IP: [66.165.176.89] X-StarScan-Version: 6.3.6; banners=-,-,- X-VirusChecked: Checked Received: (qmail 26400 invoked from network); 9 Sep 2011 16:46:54 -0000 Received: from smtp.citrix.com (HELO SMTP.CITRIX.COM) (66.165.176.89) by server-11.tower-21.messagelabs.com with RC4-SHA encrypted SMTP; 9 Sep 2011 16:46:54 -0000 X-IronPort-AV: E=Sophos;i="4.68,357,1312171200"; d="scan'208";a="16832502" Received: from ftlpmailmx01.citrite.net ([10.13.107.65]) by FTLPIPO01.CITRIX.COM with ESMTP/TLS/RC4-MD5; 09 Sep 2011 12:47:08 -0400 Received: from [10.80.2.18] (10.80.2.18) by FTLPMAILMX01.citrite.net (10.13.107.65) with Microsoft SMTP Server id 8.3.137.0; Fri, 9 Sep 2011 12:47:08 -0400 Message-ID: <4E6A430B.30308@citrix.com> Date: Fri, 9 Sep 2011 17:47:07 +0100 From: Andrew Cooper User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.2.21) Gecko/20110831 Lightning/1.0b2 Thunderbird/3.1.13 MIME-Version: 1.0 To: Jan Beulich Subject: Re: [Xen-devel] Re: 4.0/4.1 requests - IO-APIC EOI v4 [RFC] References: <4E689D9A.1020405@citrix.com> <4E68C6C10200007800055485@nat28.tlf.novell.com> <4E68C09B.8050409@citrix.com> <4E68E1D30200007800055501@nat28.tlf.novell.com> <4E68C9A9.8090707@citrix.com> <4E6A2B7F.6060006@citrix.com> <4E6A4F66020000780005589B@nat28.tlf.novell.com> <4E6A36EB.6000802@citrix.com> <4E6A54DB02000078000558B6@nat28.tlf.novell.com> <4E6A3D5B.5010104@citrix.com> In-Reply-To: <4E6A3D5B.5010104@citrix.com> Content-Type: multipart/mixed; boundary="------------010506050200090001050102" Cc: Keir Fraser , "xen-devel@lists.xensource.com" X-BeenThere: xen-devel@lists.xensource.com X-Mailman-Version: 2.1.5 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xensource.com Errors-To: xen-devel-bounces@lists.xensource.com --------------010506050200090001050102 Content-Type: text/plain; charset="ISO-8859-1" Content-Transfer-Encoding: 7bit On 09/09/11 17:22, Andrew Cooper wrote: > ---SNIP--- > > Version 3. Applied Jan's suggestions, and extended some of the comments. > V4 - get the BUG_ON logic correct (oops). I have now done a few reboot tests and a kexec test with this patch. Are there any other tests you would suggest, or shall I formally submit the patch for unstable and backporting? -- Andrew Cooper - Dom0 Kernel Engineer, Citrix XenServer T: +44 (0)1223 225 900, http://www.citrix.com --------------010506050200090001050102 Content-Type: text/x-patch; name="IO-APIC-eoi.patch" Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename="IO-APIC-eoi.patch" diff -r 0268e7380953 xen/arch/x86/io_apic.c --- a/xen/arch/x86/io_apic.c Mon Sep 05 15:10:28 2011 +0100 +++ b/xen/arch/x86/io_apic.c Fri Sep 09 17:20:49 2011 +0100 @@ -68,6 +68,16 @@ int __read_mostly nr_ioapics; #define MAX_PLUS_SHARED_IRQS nr_irqs_gsi #define PIN_MAP_SIZE (MAX_PLUS_SHARED_IRQS + nr_irqs_gsi) + +#define ioapic_has_eoi_reg(apic) (mp_ioapics[(apic)].mpc_apicver >= 0x20) + +static void __io_apic_eoi(unsigned int apic, unsigned int vector, unsigned int pin); +static void io_apic_eoi(unsigned int apic, unsigned int vector, unsigned int pin); + +#define io_apic_eoi_vector(apic, vector) io_apic_eoi((apic), (vector), -1) +#define io_apic_eoi_pin(apic, pin) io_apic_eoi((apic), -1, (pin)) + + /* * This is performance-critical, we want to do it O(1) * @@ -357,7 +367,7 @@ static void __eoi_IO_APIC_irq(unsigned i pin = entry->pin; if (pin == -1) break; - io_apic_eoi(entry->apic, vector); + __io_apic_eoi(entry->apic, vector, pin); if (!entry->next) break; entry = irq_2_pin + entry->next; @@ -397,18 +407,7 @@ static void clear_IO_APIC_pin(unsigned i entry.trigger = 1; __ioapic_write_entry(apic, pin, TRUE, entry); } - if (mp_ioapics[apic].mpc_apicver >= 0x20) - io_apic_eoi(apic, entry.vector); - else { - /* - * Mechanism by which we clear remoteIRR in this case is by - * changing the trigger mode to edge and back to level. - */ - entry.trigger = 0; - __ioapic_write_entry(apic, pin, TRUE, entry); - entry.trigger = 1; - __ioapic_write_entry(apic, pin, TRUE, entry); - } + __io_apic_eoi(apic, entry.vector, pin); } /* @@ -1750,7 +1749,7 @@ static void end_level_ioapic_irq (unsign { int ioapic; for (ioapic = 0; ioapic < nr_ioapics; ioapic++) - io_apic_eoi(ioapic, i); + io_apic_eoi_vector(ioapic, i); } v = apic_read(APIC_TMR + ((i & ~0x1f) >> 1)); @@ -2622,3 +2621,124 @@ void __init init_ioapic_mappings(void) printk(XENLOG_INFO "IRQ limits: %u GSI, %u MSI/MSI-X\n", nr_irqs_gsi, nr_irqs - nr_irqs_gsi); } + +/* EOI an IO-APIC entry. One of vector or pin may be -1, indicating that + * it should be worked out using the other. This function disables interrupts + * and takes the ioapic_lock */ +static void io_apic_eoi(unsigned int apic, unsigned int vector, unsigned int pin) +{ + unsigned int flags; + spin_lock_irqsave(&ioapic_lock, flags); + __io_apic_eoi(apic, vector, pin); + spin_unlock_irqrestore(&ioapic_lock, flags); +} + +/* EOI an IO-APIC entry. One of vector or pin may be -1, indicating that + * it should be worked out using the other. This function expect that the + * ioapic_lock is taken, and interrupts are disabled (or there is a good reason + * not to), and that if both pin and vector are passed, that they refer to the + * same redirection entry in the IO-APIC. */ +static void __io_apic_eoi(unsigned int apic, unsigned int vector, unsigned int pin) +{ + /* Ensure some useful information is passed in */ + BUG_ON( !(vector == -1 && pin != -1) ); + + /* Prefer the use of the EOI register if available */ + if ( ioapic_has_eoi_reg(apic) ) + { + /* If vector is unknown, read it from the IO-APIC */ + if ( vector == -1 ) + vector = __ioapic_read_entry(apic, pin, TRUE).vector; + + *(IO_APIC_BASE(apic)+16) = vector; + } + else + { + /* Else fake an EOI by switching to edge triggered mode + * and back */ + struct IO_APIC_route_entry entry; + bool_t need_to_unmask = 0; + + /* If pin is unknown, search for it */ + if ( pin == -1 ) + { + unsigned int p; + for ( p = 0; p < nr_ioapic_registers[apic]; ++p ) + { + entry = __ioapic_read_entry(apic, p, TRUE); + if ( entry.vector == vector ) + { + pin = p; + /* break; */ + + /* Here should be a break out of the loop, but at the + * Xen code doesn't actually prevent multiple IO-APIC + * entries being assigned the same vector, so EOI all + * pins which have the correct vector. + * + * Remove the following code when the above assertion + * is fulfilled. */ + + if ( ! entry.mask ) + { + /* If entry is not currently masked, mask it and make + * a note to unmask it later */ + entry.mask = 1; + __ioapic_write_entry(apic, pin, TRUE, entry); + need_to_unmask = 1; + } + + /* Flip the trigger mode to edge and back */ + entry.trigger = 0; + __ioapic_write_entry(apic, pin, TRUE, entry); + entry.trigger = 1; + __ioapic_write_entry(apic, pin, TRUE, entry); + + if ( need_to_unmask ) + { + /* Unmask if neccesary */ + entry.mask = 0; + __ioapic_write_entry(apic, pin, TRUE, entry); + } + + } + } + + /* If search fails, nothing to do */ + + /* if ( pin == -1 ) */ + + /* Because the loop wasn't broken out of (see comment above), + * all relevant pins have been EOI, so we can always return. + * + * Re-instate the if statement above when the Xen logic has been + * fixed.*/ + + return; + } + + entry = __ioapic_read_entry(apic, pin, TRUE); + + if ( ! entry.mask ) + { + /* If entry is not currently masked, mask it and make + * a note to unmask it later */ + entry.mask = 1; + __ioapic_write_entry(apic, pin, TRUE, entry); + need_to_unmask = 1; + } + + /* Flip the trigger mode to edge and back */ + entry.trigger = 0; + __ioapic_write_entry(apic, pin, TRUE, entry); + entry.trigger = 1; + __ioapic_write_entry(apic, pin, TRUE, entry); + + if ( need_to_unmask ) + { + /* Unmask if neccesary */ + entry.mask = 0; + __ioapic_write_entry(apic, pin, TRUE, entry); + } + } +} diff -r 0268e7380953 xen/include/asm-x86/io_apic.h --- a/xen/include/asm-x86/io_apic.h Mon Sep 05 15:10:28 2011 +0100 +++ b/xen/include/asm-x86/io_apic.h Fri Sep 09 17:20:49 2011 +0100 @@ -157,11 +157,6 @@ static inline void io_apic_write(unsigne __io_apic_write(apic, reg, value); } -static inline void io_apic_eoi(unsigned int apic, unsigned int vector) -{ - *(IO_APIC_BASE(apic)+16) = vector; -} - /* * Re-write a value: to be used for read-modify-write * cycles where the read already set up the index register. --------------010506050200090001050102 Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel --------------010506050200090001050102-- From xen-devel-bounces@lists.xensource.com Fri Sep 09 09:49:12 2011 Return-path: Envelope-to: www-data@lists.xensource.com Delivery-date: Fri, 09 Sep 2011 09:49:12 -0700 Received: from localhost ([127.0.0.1] helo=lists.colo.xensource.com) by lists.xensource.com with esmtp (Exim 4.43) id 1R24GO-0007kE-Dk; Fri, 09 Sep 2011 09:49:12 -0700 Received: from mail27.messagelabs.com ([193.109.254.147]) by lists.xensource.com with esmtp (Exim 4.43) id 1R24Ff-0007Sl-Ix for xen-devel@lists.xensource.com; Fri, 09 Sep 2011 09:48:28 -0700 X-Env-Sender: eric.camachat@gmail.com X-Msg-Ref: server-10.tower-27.messagelabs.com!1315586885!35104973!1 X-Originating-IP: [209.85.213.43] X-StarScan-Version: 6.3.6; banners=-,-,- X-VirusChecked: Checked Received: (qmail 18779 invoked from network); 9 Sep 2011 16:48:06 -0000 Received: from mail-yw0-f43.google.com (HELO mail-yw0-f43.google.com) (209.85.213.43) by server-10.tower-27.messagelabs.com with RC4-SHA encrypted SMTP; 9 Sep 2011 16:48:06 -0000 Received: by ywm21 with SMTP id 21so369251ywm.30 for ; Fri, 09 Sep 2011 09:48:23 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type:content-transfer-encoding; bh=YQI6/wXjceZ//Ut0XNYv3Cn3tQO97kY7iJWIeQWo26w=; b=wDLltDRoFDRdTI4AlcOX7ODxLfxbQCaspgbP0U1TeWhkOckCXr82udMm5RtXPXtfq7 KeW6WKCUiIimF004tfFGr0qDyj7WWlX0sZG8B1CBi/Pt3J9XhhguxrODY1GvSlQfNsOw SvqS8p98vXWKAq+J+YgJ6nZ3u/e2pRMj+QHBg= Received: by 10.236.77.232 with SMTP id d68mr13320795yhe.15.1315586903164; Fri, 09 Sep 2011 09:48:23 -0700 (PDT) MIME-Version: 1.0 Received: by 10.236.95.5 with HTTP; Fri, 9 Sep 2011 09:48:03 -0700 (PDT) In-Reply-To: References: <20110908125920.GC28591@dumpdata.com> <20110908181205.GA19078@dumpdata.com> <20110908200038.GB21186@dumpdata.com> <20110909010550.GB9060@dumpdata.com> From: Eric Camachat Date: Fri, 9 Sep 2011 09:48:03 -0700 Message-ID: Subject: Re: [Xen-devel] Can I specify a physical memory region for a domU To: Konrad Rzeszutek Wilk Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Cc: xen-devel@lists.xensource.com X-BeenThere: xen-devel@lists.xensource.com X-Mailman-Version: 2.1.5 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xensource.com Errors-To: xen-devel-bounces@lists.xensource.com On Fri, Sep 9, 2011 at 9:10 AM, Eric Camachat wro= te: > On Thu, Sep 8, 2011 at 6:05 PM, Konrad Rzeszutek Wilk > wrote: >> On Thu, Sep 08, 2011 at 05:15:06PM -0700, Eric Camachat wrote: >>> On Thu, Sep 8, 2011 at 1:00 PM, Konrad Rzeszutek Wilk >>> wrote: >>> >> > Make sure you set >>> >> > =C2=A0pci_set_consistent_dma_mask(dev, DMA_BIT_MASK(31)); >>> >> > >>> >> > on top of pci_set_dma_mask(dev, DMA_BIT_MASK(31)); >>> >> > in your driver. >>> >> > >>> >> A lot of work to port the driver to PV domU, hope it works. >>> > >>> > Hm? That is the normal way you would write drivers in the Linux kerne= l. >>> > You use the DMA API in it to deal with the PCI devices. >>> > >>> > Is the PV domU a Linux kernel or something else? >>> > >>> >>> Yes, the PV domU is linux kernel. >>> >>> I tested pci_alloc_consistent() verified on baremetal it worked with 8G= B SDRAM. >>> But while I ran it in XEN, pci_alloc_consistent() cannot allocate >>> memory successfully for 4MB although pci_set_dma_mask(), >> >> And what is the error? > > I cannot see any error, it just returned NULL. BTW, I will succeed if I allocate 2MB only. > >> >>> pci_set_consistent_dma_mask() and dma_set_mask() all succeeded. >> >> And what kernel did you use? > I am using linux-2.6.32.24. > >>> >>> _______________________________________________ >>> Xen-devel mailing list >>> Xen-devel@lists.xensource.com >>> http://lists.xensource.com/xen-devel >> > _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel From xen-devel-bounces@lists.xensource.com Fri Sep 09 09:51:23 2011 Return-path: Envelope-to: www-data@lists.xensource.com Delivery-date: Fri, 09 Sep 2011 09:51:23 -0700 Received: from localhost ([127.0.0.1] helo=lists.colo.xensource.com) by lists.xensource.com with esmtp (Exim 4.43) id 1R24IV-00087m-GM; Fri, 09 Sep 2011 09:51:23 -0700 Received: from mail216.messagelabs.com ([85.158.143.99]) by lists.xensource.com with esmtp (Exim 4.43) id 1R24I5-0007vD-4V for xen-devel@lists.xensource.com; Fri, 09 Sep 2011 09:50:57 -0700 X-Env-Sender: Andrew.Cooper3@citrix.com X-Msg-Ref: server-13.tower-216.messagelabs.com!1315587052!17727629!1 X-Originating-IP: [66.165.176.89] X-StarScan-Version: 6.3.6; banners=-,-,- X-VirusChecked: Checked Received: (qmail 4380 invoked from network); 9 Sep 2011 16:50:53 -0000 Received: from smtp.citrix.com (HELO SMTP.CITRIX.COM) (66.165.176.89) by server-13.tower-216.messagelabs.com with RC4-SHA encrypted SMTP; 9 Sep 2011 16:50:53 -0000 X-IronPort-AV: E=Sophos;i="4.68,357,1312171200"; d="scan'208";a="16832670" Received: from ftlpmailmx02.citrite.net ([10.13.107.66]) by FTLPIPO01.CITRIX.COM with ESMTP/TLS/RC4-MD5; 09 Sep 2011 12:50:52 -0400 Received: from [10.80.2.18] (10.80.2.18) by FTLPMAILMX02.citrite.net (10.13.107.66) with Microsoft SMTP Server id 8.3.137.0; Fri, 9 Sep 2011 12:50:52 -0400 Message-ID: <4E6A43EA.8060700@citrix.com> Date: Fri, 9 Sep 2011 17:50:50 +0100 From: Andrew Cooper User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.2.21) Gecko/20110831 Lightning/1.0b2 Thunderbird/3.1.13 MIME-Version: 1.0 To: Subject: Re: [Xen-devel] Re: 4.0/4.1 requests - IO-APIC EOI v4 [RFC] References: <4E689D9A.1020405@citrix.com> <4E68C6C10200007800055485@nat28.tlf.novell.com> <4E68C09B.8050409@citrix.com> <4E68E1D30200007800055501@nat28.tlf.novell.com> <4E68C9A9.8090707@citrix.com> <4E6A2B7F.6060006@citrix.com> <4E6A4F66020000780005589B@nat28.tlf.novell.com> <4E6A36EB.6000802@citrix.com> <4E6A54DB02000078000558B6@nat28.tlf.novell.com> <4E6A3D5B.5010104@citrix.com> <4E6A430B.30308@citrix.com> In-Reply-To: <4E6A430B.30308@citrix.com> Content-Type: multipart/mixed; boundary="------------080404060101050305050700" X-BeenThere: xen-devel@lists.xensource.com X-Mailman-Version: 2.1.5 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xensource.com Errors-To: xen-devel-bounces@lists.xensource.com --------------080404060101050305050700 Content-Type: text/plain; charset="ISO-8859-1" Content-Transfer-Encoding: 7bit On 09/09/11 17:47, Andrew Cooper wrote: > On 09/09/11 17:22, Andrew Cooper wrote: >> ---SNIP--- >> >> Version 3. Applied Jan's suggestions, and extended some of the comments. >> > V4 - get the BUG_ON logic correct (oops). > > I have now done a few reboot tests and a kexec test with this patch. > > Are there any other tests you would suggest, or shall I formally submit > the patch for unstable and backporting? > Remember to qrefresh this time. -- Andrew Cooper - Dom0 Kernel Engineer, Citrix XenServer T: +44 (0)1223 225 900, http://www.citrix.com --------------080404060101050305050700 Content-Type: text/x-patch; name="IO-APIC-eoi.patch" Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename="IO-APIC-eoi.patch" diff -r 0268e7380953 xen/arch/x86/io_apic.c --- a/xen/arch/x86/io_apic.c Mon Sep 05 15:10:28 2011 +0100 +++ b/xen/arch/x86/io_apic.c Fri Sep 09 17:48:33 2011 +0100 @@ -68,6 +68,16 @@ int __read_mostly nr_ioapics; #define MAX_PLUS_SHARED_IRQS nr_irqs_gsi #define PIN_MAP_SIZE (MAX_PLUS_SHARED_IRQS + nr_irqs_gsi) + +#define ioapic_has_eoi_reg(apic) (mp_ioapics[(apic)].mpc_apicver >= 0x20) + +static void __io_apic_eoi(unsigned int apic, unsigned int vector, unsigned int pin); +static void io_apic_eoi(unsigned int apic, unsigned int vector, unsigned int pin); + +#define io_apic_eoi_vector(apic, vector) io_apic_eoi((apic), (vector), -1) +#define io_apic_eoi_pin(apic, pin) io_apic_eoi((apic), -1, (pin)) + + /* * This is performance-critical, we want to do it O(1) * @@ -357,7 +367,7 @@ static void __eoi_IO_APIC_irq(unsigned i pin = entry->pin; if (pin == -1) break; - io_apic_eoi(entry->apic, vector); + __io_apic_eoi(entry->apic, vector, pin); if (!entry->next) break; entry = irq_2_pin + entry->next; @@ -397,18 +407,7 @@ static void clear_IO_APIC_pin(unsigned i entry.trigger = 1; __ioapic_write_entry(apic, pin, TRUE, entry); } - if (mp_ioapics[apic].mpc_apicver >= 0x20) - io_apic_eoi(apic, entry.vector); - else { - /* - * Mechanism by which we clear remoteIRR in this case is by - * changing the trigger mode to edge and back to level. - */ - entry.trigger = 0; - __ioapic_write_entry(apic, pin, TRUE, entry); - entry.trigger = 1; - __ioapic_write_entry(apic, pin, TRUE, entry); - } + __io_apic_eoi(apic, entry.vector, pin); } /* @@ -1750,7 +1749,7 @@ static void end_level_ioapic_irq (unsign { int ioapic; for (ioapic = 0; ioapic < nr_ioapics; ioapic++) - io_apic_eoi(ioapic, i); + io_apic_eoi_vector(ioapic, i); } v = apic_read(APIC_TMR + ((i & ~0x1f) >> 1)); @@ -2622,3 +2621,124 @@ void __init init_ioapic_mappings(void) printk(XENLOG_INFO "IRQ limits: %u GSI, %u MSI/MSI-X\n", nr_irqs_gsi, nr_irqs - nr_irqs_gsi); } + +/* EOI an IO-APIC entry. One of vector or pin may be -1, indicating that + * it should be worked out using the other. This function disables interrupts + * and takes the ioapic_lock */ +static void io_apic_eoi(unsigned int apic, unsigned int vector, unsigned int pin) +{ + unsigned int flags; + spin_lock_irqsave(&ioapic_lock, flags); + __io_apic_eoi(apic, vector, pin); + spin_unlock_irqrestore(&ioapic_lock, flags); +} + +/* EOI an IO-APIC entry. One of vector or pin may be -1, indicating that + * it should be worked out using the other. This function expect that the + * ioapic_lock is taken, and interrupts are disabled (or there is a good reason + * not to), and that if both pin and vector are passed, that they refer to the + * same redirection entry in the IO-APIC. */ +static void __io_apic_eoi(unsigned int apic, unsigned int vector, unsigned int pin) +{ + /* Ensure some useful information is passed in */ + BUG_ON( (vector == -1 && pin == -1) ); + + /* Prefer the use of the EOI register if available */ + if ( ioapic_has_eoi_reg(apic) ) + { + /* If vector is unknown, read it from the IO-APIC */ + if ( vector == -1 ) + vector = __ioapic_read_entry(apic, pin, TRUE).vector; + + *(IO_APIC_BASE(apic)+16) = vector; + } + else + { + /* Else fake an EOI by switching to edge triggered mode + * and back */ + struct IO_APIC_route_entry entry; + bool_t need_to_unmask = 0; + + /* If pin is unknown, search for it */ + if ( pin == -1 ) + { + unsigned int p; + for ( p = 0; p < nr_ioapic_registers[apic]; ++p ) + { + entry = __ioapic_read_entry(apic, p, TRUE); + if ( entry.vector == vector ) + { + pin = p; + /* break; */ + + /* Here should be a break out of the loop, but at the + * Xen code doesn't actually prevent multiple IO-APIC + * entries being assigned the same vector, so EOI all + * pins which have the correct vector. + * + * Remove the following code when the above assertion + * is fulfilled. */ + + if ( ! entry.mask ) + { + /* If entry is not currently masked, mask it and make + * a note to unmask it later */ + entry.mask = 1; + __ioapic_write_entry(apic, pin, TRUE, entry); + need_to_unmask = 1; + } + + /* Flip the trigger mode to edge and back */ + entry.trigger = 0; + __ioapic_write_entry(apic, pin, TRUE, entry); + entry.trigger = 1; + __ioapic_write_entry(apic, pin, TRUE, entry); + + if ( need_to_unmask ) + { + /* Unmask if neccesary */ + entry.mask = 0; + __ioapic_write_entry(apic, pin, TRUE, entry); + } + + } + } + + /* If search fails, nothing to do */ + + /* if ( pin == -1 ) */ + + /* Because the loop wasn't broken out of (see comment above), + * all relevant pins have been EOI, so we can always return. + * + * Re-instate the if statement above when the Xen logic has been + * fixed.*/ + + return; + } + + entry = __ioapic_read_entry(apic, pin, TRUE); + + if ( ! entry.mask ) + { + /* If entry is not currently masked, mask it and make + * a note to unmask it later */ + entry.mask = 1; + __ioapic_write_entry(apic, pin, TRUE, entry); + need_to_unmask = 1; + } + + /* Flip the trigger mode to edge and back */ + entry.trigger = 0; + __ioapic_write_entry(apic, pin, TRUE, entry); + entry.trigger = 1; + __ioapic_write_entry(apic, pin, TRUE, entry); + + if ( need_to_unmask ) + { + /* Unmask if neccesary */ + entry.mask = 0; + __ioapic_write_entry(apic, pin, TRUE, entry); + } + } +} diff -r 0268e7380953 xen/include/asm-x86/io_apic.h --- a/xen/include/asm-x86/io_apic.h Mon Sep 05 15:10:28 2011 +0100 +++ b/xen/include/asm-x86/io_apic.h Fri Sep 09 17:48:33 2011 +0100 @@ -157,11 +157,6 @@ static inline void io_apic_write(unsigne __io_apic_write(apic, reg, value); } -static inline void io_apic_eoi(unsigned int apic, unsigned int vector) -{ - *(IO_APIC_BASE(apic)+16) = vector; -} - /* * Re-write a value: to be used for read-modify-write * cycles where the read already set up the index register. --------------080404060101050305050700 Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel --------------080404060101050305050700-- From xen-devel-bounces@lists.xensource.com Fri Sep 09 10:19:16 2011 Return-path: Envelope-to: www-data@lists.xensource.com Delivery-date: Fri, 09 Sep 2011 10:19:16 -0700 Received: from localhost ([127.0.0.1] helo=lists.colo.xensource.com) by lists.xensource.com with esmtp (Exim 4.43) id 1R24jU-00019t-19; Fri, 09 Sep 2011 10:19:16 -0700 Received: from mail174.messagelabs.com ([85.158.138.51]) by lists.xensource.com with esmtp (Exim 4.43) id 1R24ih-0000xC-SQ for xen-devel@lists.xensource.com; Fri, 09 Sep 2011 10:18:29 -0700 X-Env-Sender: Ian.Campbell@eu.citrix.com X-Msg-Ref: server-14.tower-174.messagelabs.com!1315588703!30882561!1 X-Originating-IP: [66.165.176.63] X-StarScan-Version: 6.3.6; banners=-,-,- X-VirusChecked: Checked Received: (qmail 21831 invoked from network); 9 Sep 2011 17:18:24 -0000 Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63) by server-14.tower-174.messagelabs.com with RC4-SHA encrypted SMTP; 9 Sep 2011 17:18:24 -0000 X-IronPort-AV: E=Sophos;i="4.68,357,1312171200"; d="scan'208";a="162361107" Received: from ftlpmailmx02.citrite.net ([10.13.107.66]) by FTLPIPO02.CITRIX.COM with ESMTP/TLS/RC4-MD5; 09 Sep 2011 13:18:22 -0400 Received: from [127.0.0.1] (10.80.16.67) by smtprelay.citrix.com (10.13.107.66) with Microsoft SMTP Server id 8.3.137.0; Fri, 9 Sep 2011 13:18:22 -0400 Subject: Re: [Xen-devel] [PATCH v2 3/4] Clone and build upstream Qemu by default From: Ian Campbell To: Stefano Stabellini Date: Fri, 9 Sep 2011 10:18:21 -0700 In-Reply-To: References: <1315504038-21733-1-git-send-email-stefano.stabellini@eu.citrix.com> <1315504038-21733-3-git-send-email-stefano.stabellini@eu.citrix.com> <1315504587.3180.47.camel@cthulhu.hellion.org.uk> <1315576788.3180.60.camel@cthulhu.hellion.org.uk> Organization: Citrix Systems, Inc. Content-Type: text/plain; charset="UTF-8" X-Mailer: Evolution 3.0.3- Content-Transfer-Encoding: 7bit Message-ID: <1315588703.3180.69.camel@cthulhu.hellion.org.uk> MIME-Version: 1.0 Cc: "xen-devel@lists.xensource.com" , "keir@xen.org" X-BeenThere: xen-devel@lists.xensource.com X-Mailman-Version: 2.1.5 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xensource.com Errors-To: xen-devel-bounces@lists.xensource.com On Fri, 2011-09-09 at 12:43 -0400, Stefano Stabellini wrote: > On Fri, 9 Sep 2011, Ian Campbell wrote: > > With the number of trees which we have now we should maybe consider > > putting each branch in a subdir: [...] > > Fair enough. However it shouldn't block these patches. Absolutely, I was just pondering ;-) Ian. _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel From xen-devel-bounces@lists.xensource.com Fri Sep 09 11:07:59 2011 Return-path: Envelope-to: www-data@lists.xensource.com Delivery-date: Fri, 09 Sep 2011 11:07:59 -0700 Received: from localhost ([127.0.0.1] helo=lists.colo.xensource.com) by lists.xensource.com with esmtp (Exim 4.43) id 1R25Ud-0002Oi-9l; Fri, 09 Sep 2011 11:07:59 -0700 Received: from mail27.messagelabs.com ([193.109.254.147]) by lists.xensource.com with esmtp (Exim 4.43) id 1R25TE-0002Bu-J0 for xen-devel@lists.xensource.com; Fri, 09 Sep 2011 11:06:33 -0700 X-Env-Sender: konrad@oracle.com X-Msg-Ref: server-15.tower-27.messagelabs.com!1315591580!48134260!1 X-Originating-IP: [141.146.126.227] X-StarScan-Version: 6.3.6; banners=-,-,- X-VirusChecked: Checked Received: (qmail 9564 invoked from network); 9 Sep 2011 18:06:21 -0000 Received: from acsinet15.oracle.com (HELO acsinet15.oracle.com) (141.146.126.227) by server-15.tower-27.messagelabs.com with DHE-RSA-AES256-SHA encrypted SMTP; 9 Sep 2011 18:06:21 -0000 Received: from rtcsinet21.oracle.com (rtcsinet21.oracle.com [66.248.204.29]) by acsinet15.oracle.com (Switch-3.4.4/Switch-3.4.4) with ESMTP id p89I6PrF025356 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Fri, 9 Sep 2011 18:06:27 GMT Received: from acsmt356.oracle.com (acsmt356.oracle.com [141.146.40.156]) by rtcsinet21.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id p89I6NAn009614 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 9 Sep 2011 18:06:24 GMT Received: from abhmt104.oracle.com (abhmt104.oracle.com [141.146.116.56]) by acsmt356.oracle.com (8.12.11.20060308/8.12.11) with ESMTP id p89I6INP005156; Fri, 9 Sep 2011 13:06:18 -0500 Received: from oracle.com (/209.6.55.207) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Fri, 09 Sep 2011 11:06:18 -0700 Received: by oracle.com (Postfix, from userid 1000) id D2F79121C; Fri, 9 Sep 2011 14:06:01 -0400 (EDT) Date: Fri, 9 Sep 2011 14:06:01 -0400 From: Konrad Rzeszutek Wilk To: Eric Camachat Subject: Re: [Xen-devel] Can I specify a physical memory region for a domU Message-ID: <20110909180601.GA5560@oracle.com> References: <20110908125920.GC28591@dumpdata.com> <20110908181205.GA19078@dumpdata.com> <20110908200038.GB21186@dumpdata.com> <20110909010550.GB9060@dumpdata.com> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.21 (2010-09-15) Content-Transfer-Encoding: quoted-printable X-Source-IP: rtcsinet21.oracle.com [66.248.204.29] X-CT-RefId: str=0001.0A090208.4E6A55A3.0033,ss=1,re=0.000,fgs=0 Cc: xen-devel@lists.xensource.com X-BeenThere: xen-devel@lists.xensource.com X-Mailman-Version: 2.1.5 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xensource.com Errors-To: xen-devel-bounces@lists.xensource.com On Fri, Sep 09, 2011 at 09:48:03AM -0700, Eric Camachat wrote: > On Fri, Sep 9, 2011 at 9:10 AM, Eric Camachat = wrote: > > On Thu, Sep 8, 2011 at 6:05 PM, Konrad Rzeszutek Wilk > > wrote: > >> On Thu, Sep 08, 2011 at 05:15:06PM -0700, Eric Camachat wrote: > >>> On Thu, Sep 8, 2011 at 1:00 PM, Konrad Rzeszutek Wilk > >>> wrote: > >>> >> > Make sure you set > >>> >> > =A0pci_set_consistent_dma_mask(dev, DMA_BIT_MASK(31)); > >>> >> > > >>> >> > on top of pci_set_dma_mask(dev, DMA_BIT_MASK(31)); > >>> >> > in your driver. > >>> >> > > >>> >> A lot of work to port the driver to PV domU, hope it works. > >>> > > >>> > Hm? That is the normal way you would write drivers in the Linux k= ernel. > >>> > You use the DMA API in it to deal with the PCI devices. > >>> > > >>> > Is the PV domU a Linux kernel or something else? > >>> > > >>> > >>> Yes, the PV domU is linux kernel. > >>> > >>> I tested pci_alloc_consistent() verified on baremetal it worked wit= h 8GB SDRAM. > >>> But while I ran it in XEN, pci_alloc_consistent() cannot allocate > >>> memory successfully for 4MB although pci_set_dma_mask(), > >> > >> And what is the error? > > > > I cannot see any error, it just returned NULL. >=20 > BTW, I will succeed if I allocate 2MB only. Ok, that is unsurprising. I don't know if you can do it any better on bar= emetal. But I am failing to understand why you need such large swaths of contingo= us memory. You can't do scatter gather? Or scatter gather on 2MB chunks? _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel From xen-devel-bounces@lists.xensource.com Fri Sep 09 11:32:26 2011 Return-path: Envelope-to: www-data@lists.xensource.com Delivery-date: Fri, 09 Sep 2011 11:32:26 -0700 Received: from localhost ([127.0.0.1] helo=lists.colo.xensource.com) by lists.xensource.com with esmtp (Exim 4.43) id 1R25sI-00038Y-3a; Fri, 09 Sep 2011 11:32:26 -0700 Received: from mail182.messagelabs.com ([85.158.139.83]) by lists.xensource.com with esmtp (Exim 4.43) id 1R25ra-0002vU-6T for xen-devel@lists.xensource.com; Fri, 09 Sep 2011 11:31:42 -0700 X-Env-Sender: konrad@oracle.com X-Msg-Ref: server-2.tower-182.messagelabs.com!1315593097!16750221!1 X-Originating-IP: [148.87.113.117] X-StarScan-Version: 6.3.6; banners=-,-,- X-VirusChecked: Checked Received: (qmail 10409 invoked from network); 9 Sep 2011 18:31:39 -0000 Received: from rcsinet15.oracle.com (HELO rcsinet15.oracle.com) (148.87.113.117) by server-2.tower-182.messagelabs.com with DHE-RSA-AES256-SHA encrypted SMTP; 9 Sep 2011 18:31:39 -0000 Received: from rtcsinet22.oracle.com (rtcsinet22.oracle.com [66.248.204.30]) by rcsinet15.oracle.com (Switch-3.4.4/Switch-3.4.4) with ESMTP id p89IVQFQ021724 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Fri, 9 Sep 2011 18:31:28 GMT Received: from acsmt356.oracle.com (acsmt356.oracle.com [141.146.40.156]) by rtcsinet22.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id p89IVO4G018818 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 9 Sep 2011 18:31:25 GMT Received: from abhmt115.oracle.com (abhmt115.oracle.com [141.146.116.67]) by acsmt356.oracle.com (8.12.11.20060308/8.12.11) with ESMTP id p89IVJig024177; Fri, 9 Sep 2011 13:31:19 -0500 Received: from oracle.com (/209.6.55.207) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Fri, 09 Sep 2011 11:31:19 -0700 Received: by oracle.com (Postfix, from userid 1000) id 005E4121C; Fri, 9 Sep 2011 14:31:01 -0400 (EDT) From: Konrad Rzeszutek Wilk To: linux-kernel@vger.kernel.org Date: Fri, 9 Sep 2011 14:30:58 -0400 Message-Id: <1315593060-20031-1-git-send-email-konrad.wilk@oracle.com> X-Mailer: git-send-email 1.7.4.1 X-Source-IP: rtcsinet22.oracle.com [66.248.204.30] X-CT-RefId: str=0001.0A090207.4E6A5B80.00B1,ss=1,re=0.000,fgs=0 Cc: axboe@kernel.dk, xen-devel@lists.xensource.com, jeremy.fitzhardinge@citrix.com, JBeulich@novell.com Subject: [Xen-devel] [PATCH] xen-blk[front|back] FUA additions. X-BeenThere: xen-devel@lists.xensource.com X-Mailman-Version: 2.1.5 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xensource.com Errors-To: xen-devel-bounces@lists.xensource.com I am proposing these two patches for 3.2. They allow the backend to process the REQ_FUA request as well. Previous to these patches it only did REQ_FLUSH. There is also a bug-fix for the logic of how barrier/flushes were handled. The patches are based on a branch which also has 'feature-discard' patches, so they won't apply nativly on top of 3.1-rc5. Please review and if there are no concerns I will send a proper git pull to Jens to pick up the whole branch for 3.2. drivers/block/xen-blkback/blkback.c | 11 ++++++----- drivers/block/xen-blkfront.c | 12 ++++++------ drivers/block/xen-blkfront.c | 8 ++++---- 3 files changed, 16 insertions(+), 15 deletions(-) The full git tree is currently at my backup git tree: git://oss.oracle.com/git/kwilk/xen.git stable/for-jens-3.2 _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel From xen-devel-bounces@lists.xensource.com Fri Sep 09 11:33:30 2011 Return-path: Envelope-to: www-data@lists.xensource.com Delivery-date: Fri, 09 Sep 2011 11:33:30 -0700 Received: from localhost ([127.0.0.1] helo=lists.colo.xensource.com) by lists.xensource.com with esmtp (Exim 4.43) id 1R25tK-0003VM-1G; Fri, 09 Sep 2011 11:33:30 -0700 Received: from mail21.messagelabs.com ([85.158.143.35]) by lists.xensource.com with esmtp (Exim 4.43) id 1R25rc-0002vW-JG for xen-devel@lists.xensource.com; Fri, 09 Sep 2011 11:31:45 -0700 X-Env-Sender: konrad@oracle.com X-Msg-Ref: server-4.tower-21.messagelabs.com!1315593066!59637059!1 X-Originating-IP: [141.146.126.227] X-StarScan-Version: 6.3.6; banners=-,-,- X-VirusChecked: Checked Received: (qmail 26735 invoked from network); 9 Sep 2011 18:31:07 -0000 Received: from acsinet15.oracle.com (HELO acsinet15.oracle.com) (141.146.126.227) by server-4.tower-21.messagelabs.com with DHE-RSA-AES256-SHA encrypted SMTP; 9 Sep 2011 18:31:07 -0000 Received: from acsinet22.oracle.com (acsinet22.oracle.com [141.146.126.238]) by acsinet15.oracle.com (Switch-3.4.4/Switch-3.4.4) with ESMTP id p89IVPRD008006 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Fri, 9 Sep 2011 18:31:27 GMT Received: from acsmt356.oracle.com (acsmt356.oracle.com [141.146.40.156]) by acsinet22.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id p89IVObL004593 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 9 Sep 2011 18:31:24 GMT Received: from abhmt101.oracle.com (abhmt101.oracle.com [141.146.116.53]) by acsmt356.oracle.com (8.12.11.20060308/8.12.11) with ESMTP id p89IVJgm024174; Fri, 9 Sep 2011 13:31:19 -0500 Received: from oracle.com (/209.6.55.207) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Fri, 09 Sep 2011 11:31:19 -0700 Received: by oracle.com (Postfix, from userid 1000) id 093D21227; Fri, 9 Sep 2011 14:31:02 -0400 (EDT) From: Konrad Rzeszutek Wilk To: linux-kernel@vger.kernel.org Date: Fri, 9 Sep 2011 14:30:59 -0400 Message-Id: <1315593060-20031-2-git-send-email-konrad.wilk@oracle.com> X-Mailer: git-send-email 1.7.4.1 In-Reply-To: <1315593060-20031-1-git-send-email-konrad.wilk@oracle.com> References: <1315593060-20031-1-git-send-email-konrad.wilk@oracle.com> X-Source-IP: acsinet22.oracle.com [141.146.126.238] X-Auth-Type: Internal IP X-CT-RefId: str=0001.0A090203.4E6A5B7F.0067:SCFMA922111,ss=1,re=-4.000,fgs=0 Cc: axboe@kernel.dk, xen-devel@lists.xensource.com, jeremy.fitzhardinge@citrix.com, JBeulich@novell.com, Konrad Rzeszutek Wilk Subject: [Xen-devel] [PATCH 1/3] xen/blk[front|back]: Use the full FLUSH | FUA instead of just FLUSH. X-BeenThere: xen-devel@lists.xensource.com X-Mailman-Version: 2.1.5 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xensource.com Errors-To: xen-devel-bounces@lists.xensource.com During a FLUSH we can pass sector number that we want to have flushed - which is what FUA requests are. Signed-off-by: Konrad Rzeszutek Wilk --- drivers/block/xen-blkback/blkback.c | 11 ++++++----- drivers/block/xen-blkfront.c | 12 ++++++------ 2 files changed, 12 insertions(+), 11 deletions(-) diff --git a/drivers/block/xen-blkback/blkback.c b/drivers/block/xen-blkback/blkback.c index 9713d5a..6ade8ab 100644 --- a/drivers/block/xen-blkback/blkback.c +++ b/drivers/block/xen-blkback/blkback.c @@ -603,7 +603,7 @@ static int dispatch_rw_block_io(struct xen_blkif *blkif, break; case BLKIF_OP_FLUSH_DISKCACHE: blkif->st_f_req++; - operation = WRITE_FLUSH; + operation = WRITE_FLUSH_FUA; break; case BLKIF_OP_DISCARD: blkif->st_ds_req++; @@ -618,7 +618,7 @@ static int dispatch_rw_block_io(struct xen_blkif *blkif, /* Check that the number of segments is sane. */ nseg = req->nr_segments; - if (unlikely(nseg == 0 && operation != WRITE_FLUSH && + if (unlikely(nseg == 0 && operation != WRITE_FLUSH_FUA && operation != REQ_DISCARD) || unlikely(nseg > BLKIF_MAX_SEGMENTS_PER_REQUEST)) { pr_debug(DRV_PFX "Bad number of segments in request (%d)\n", @@ -707,9 +707,10 @@ static int dispatch_rw_block_io(struct xen_blkif *blkif, /* This will be hit if the operation was a flush or discard. */ if (!bio) { - BUG_ON(operation != WRITE_FLUSH && operation != REQ_DISCARD); + BUG_ON(operation != WRITE_FLUSH_FUA && + operation != REQ_DISCARD); - if (operation == WRITE_FLUSH) { + if (operation == WRITE_FLUSH_FUA) { bio = bio_alloc(GFP_KERNEL, 0); if (unlikely(bio == NULL)) goto fail_put_bio; @@ -743,7 +744,7 @@ static int dispatch_rw_block_io(struct xen_blkif *blkif, if (operation == READ) blkif->st_rd_sect += preq.nr_sects; - else if (operation == WRITE || operation == WRITE_FLUSH) + else if (operation == WRITE || operation == WRITE_FLUSH_FUA) blkif->st_wr_sect += preq.nr_sects; return 0; diff --git a/drivers/block/xen-blkfront.c b/drivers/block/xen-blkfront.c index 86e2c63..e205d91 100644 --- a/drivers/block/xen-blkfront.c +++ b/drivers/block/xen-blkfront.c @@ -1220,10 +1220,9 @@ static void blkfront_connect(struct blkfront_info *info) * * If there are barriers, then we use flush. */ - if (!err && barrier) { - info->feature_flush = REQ_FLUSH | REQ_FUA; + if (!err && barrier) info->flush_op = BLKIF_OP_WRITE_BARRIER; - } + /* * And if there is "feature-flush-cache" use that above * barriers. @@ -1232,10 +1231,11 @@ static void blkfront_connect(struct blkfront_info *info) "feature-flush-cache", "%d", &flush, NULL); - if (!err && flush) { - info->feature_flush = REQ_FLUSH; + if (!err && flush) info->flush_op = BLKIF_OP_FLUSH_DISKCACHE; - } + + if (info->flush_op) + info->feature_flush = REQ_FLUSH | REQ_FUA; err = xenbus_gather(XBT_NIL, info->xbdev->otherend, "feature-discard", "%d", &discard, -- 1.7.4.1 _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel From xen-devel-bounces@lists.xensource.com Fri Sep 09 11:34:50 2011 Return-path: Envelope-to: www-data@lists.xensource.com Delivery-date: Fri, 09 Sep 2011 11:34:50 -0700 Received: from localhost ([127.0.0.1] helo=lists.colo.xensource.com) by lists.xensource.com with esmtp (Exim 4.43) id 1R25ub-0003yH-PS; Fri, 09 Sep 2011 11:34:49 -0700 Received: from mail174.messagelabs.com ([85.158.138.51]) by lists.xensource.com with esmtp (Exim 4.43) id 1R25s4-00033F-Jd for xen-devel@lists.xensource.com; Fri, 09 Sep 2011 11:32:13 -0700 X-Env-Sender: konrad@oracle.com X-Msg-Ref: server-12.tower-174.messagelabs.com!1315593127!30867456!1 X-Originating-IP: [148.87.113.117] X-StarScan-Version: 6.3.6; banners=-,-,- X-VirusChecked: Checked Received: (qmail 1906 invoked from network); 9 Sep 2011 18:32:09 -0000 Received: from rcsinet15.oracle.com (HELO rcsinet15.oracle.com) (148.87.113.117) by server-12.tower-174.messagelabs.com with DHE-RSA-AES256-SHA encrypted SMTP; 9 Sep 2011 18:32:09 -0000 Received: from acsinet21.oracle.com (acsinet21.oracle.com [141.146.126.237]) by rcsinet15.oracle.com (Switch-3.4.4/Switch-3.4.4) with ESMTP id p89IVPaG021708 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Fri, 9 Sep 2011 18:31:27 GMT Received: from acsmt357.oracle.com (acsmt357.oracle.com [141.146.40.157]) by acsinet21.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id p89IVO9i023680 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 9 Sep 2011 18:31:24 GMT Received: from abhmt102.oracle.com (abhmt102.oracle.com [141.146.116.54]) by acsmt357.oracle.com (8.12.11.20060308/8.12.11) with ESMTP id p89IVJ2o007286; Fri, 9 Sep 2011 13:31:19 -0500 Received: from oracle.com (/209.6.55.207) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Fri, 09 Sep 2011 11:31:19 -0700 Received: by oracle.com (Postfix, from userid 1000) id 134B3123A; Fri, 9 Sep 2011 14:31:02 -0400 (EDT) From: Konrad Rzeszutek Wilk To: linux-kernel@vger.kernel.org Date: Fri, 9 Sep 2011 14:31:00 -0400 Message-Id: <1315593060-20031-3-git-send-email-konrad.wilk@oracle.com> X-Mailer: git-send-email 1.7.4.1 In-Reply-To: <1315593060-20031-1-git-send-email-konrad.wilk@oracle.com> References: <1315593060-20031-1-git-send-email-konrad.wilk@oracle.com> X-Source-IP: acsinet21.oracle.com [141.146.126.237] X-Auth-Type: Internal IP X-CT-RefId: str=0001.0A090204.4E6A5B80.006A:SCFMA922111,ss=1,re=-4.000,fgs=0 Cc: axboe@kernel.dk, xen-devel@lists.xensource.com, Konrad Rzeszutek Wilk , JBeulich@novell.com, jeremy.fitzhardinge@citrix.com, stable@kernel.org Subject: [Xen-devel] [PATCH 3/3] xen-blkfront: If no barrier or flush is supported, use invalid operation. X-BeenThere: xen-devel@lists.xensource.com X-Mailman-Version: 2.1.5 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xensource.com Errors-To: xen-devel-bounces@lists.xensource.com By default we would set the info->flush_op=0, and zero maps to BLKIF_OP_READ request code. So if the backend did not support either barrier ('feature-barrier') or flush ('feature-flush-cache') we would end up using that opcode for the flush/barrier request, meaning we actually do a READ request. Fortunatly for us, __generic_make_request checks q->flush_flags and realizes that we don't do FLUSH and removes the REQ_FLUSH | REQ_FUA so we never end up issuing a READ request for a flush request. However, other third party implementations of __make_request might not be so smart, so lets fix this up. CC: stable@kernel.org Signed-off-by: Konrad Rzeszutek Wilk --- drivers/block/xen-blkfront.c | 8 ++++---- 1 files changed, 4 insertions(+), 4 deletions(-) diff --git a/drivers/block/xen-blkfront.c b/drivers/block/xen-blkfront.c index e205d91..c4aa9da 100644 --- a/drivers/block/xen-blkfront.c +++ b/drivers/block/xen-blkfront.c @@ -97,7 +97,7 @@ struct blkfront_info struct blk_shadow shadow[BLK_RING_SIZE]; unsigned long shadow_free; unsigned int feature_flush; - unsigned int flush_op; + int flush_op; unsigned int feature_discard; unsigned int discard_granularity; unsigned int discard_alignment; @@ -774,7 +774,7 @@ static irqreturn_t blkif_interrupt(int irq, void *dev_id) if (error == -EOPNOTSUPP) error = 0; info->feature_flush = 0; - info->flush_op = 0; + info->flush_op = -1; /* 0 is BLKIF_OP_READ */ xlvbd_flush(info); } /* fall through */ @@ -1207,7 +1207,7 @@ static void blkfront_connect(struct blkfront_info *info) } info->feature_flush = 0; - info->flush_op = 0; + info->flush_op = -1; /* 0 is BLKIF_OP_READ */ err = xenbus_gather(XBT_NIL, info->xbdev->otherend, "feature-barrier", "%d", &barrier, @@ -1234,7 +1234,7 @@ static void blkfront_connect(struct blkfront_info *info) if (!err && flush) info->flush_op = BLKIF_OP_FLUSH_DISKCACHE; - if (info->flush_op) + if (info->flush_op > 0) info->feature_flush = REQ_FLUSH | REQ_FUA; err = xenbus_gather(XBT_NIL, info->xbdev->otherend, -- 1.7.4.1 _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel From xen-devel-bounces@lists.xensource.com Fri Sep 09 12:20:48 2011 Return-path: Envelope-to: www-data@lists.xensource.com Delivery-date: Fri, 09 Sep 2011 12:20:48 -0700 Received: from localhost ([127.0.0.1] helo=lists.colo.xensource.com) by lists.xensource.com with esmtp (Exim 4.43) id 1R26d6-0007QK-0H; Fri, 09 Sep 2011 12:20:48 -0700 Received: from mail182.messagelabs.com ([85.158.139.83]) by lists.xensource.com with esmtp (Exim 4.43) id 1R26cf-0007ES-HM for xen-devel@lists.xensource.com; Fri, 09 Sep 2011 12:20:22 -0700 X-Env-Sender: eric.camachat@gmail.com X-Msg-Ref: server-3.tower-182.messagelabs.com!1315596017!14951835!1 X-Originating-IP: [209.85.161.181] X-StarScan-Version: 6.3.6; banners=-,-,- X-VirusChecked: Checked Received: (qmail 20380 invoked from network); 9 Sep 2011 19:20:18 -0000 Received: from mail-gx0-f181.google.com (HELO mail-gx0-f181.google.com) (209.85.161.181) by server-3.tower-182.messagelabs.com with RC4-SHA encrypted SMTP; 9 Sep 2011 19:20:18 -0000 Received: by gxk9 with SMTP id 9so2050241gxk.12 for ; Fri, 09 Sep 2011 12:20:17 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type:content-transfer-encoding; bh=+72pnfWuoHHr7w3vmXZ+hZHI5JhO9Ic2dNThEl8psWY=; b=NCXE6dSYVXzV4f2tWUp0cz+hz25TZkcGfyLi43IvjVbZyHVz2vi2ug1pEOxRe8sbNw D4PwnxzVUTZEHv68JMsJUdfKJnAhoZKqmk5ippD+yrMRE4SqO6q8go8rSVhYGy6Jx8yW 30PzdiyQd2p9PiJuQHSRS/BGc450u2X252+YM= Received: by 10.236.201.168 with SMTP id b28mr3673473yho.117.1315596017130; Fri, 09 Sep 2011 12:20:17 -0700 (PDT) MIME-Version: 1.0 Received: by 10.236.95.5 with HTTP; Fri, 9 Sep 2011 12:19:57 -0700 (PDT) In-Reply-To: <20110909180601.GA5560@oracle.com> References: <20110908125920.GC28591@dumpdata.com> <20110908181205.GA19078@dumpdata.com> <20110908200038.GB21186@dumpdata.com> <20110909010550.GB9060@dumpdata.com> <20110909180601.GA5560@oracle.com> From: Eric Camachat Date: Fri, 9 Sep 2011 12:19:57 -0700 Message-ID: Subject: Re: [Xen-devel] Can I specify a physical memory region for a domU To: Konrad Rzeszutek Wilk Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Cc: xen-devel@lists.xensource.com X-BeenThere: xen-devel@lists.xensource.com X-Mailman-Version: 2.1.5 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xensource.com Errors-To: xen-devel-bounces@lists.xensource.com On Fri, Sep 9, 2011 at 11:06 AM, Konrad Rzeszutek Wilk wrote: > On Fri, Sep 09, 2011 at 09:48:03AM -0700, Eric Camachat wrote: >> On Fri, Sep 9, 2011 at 9:10 AM, Eric Camachat = wrote: >> > On Thu, Sep 8, 2011 at 6:05 PM, Konrad Rzeszutek Wilk >> > wrote: >> >> On Thu, Sep 08, 2011 at 05:15:06PM -0700, Eric Camachat wrote: >> >>> On Thu, Sep 8, 2011 at 1:00 PM, Konrad Rzeszutek Wilk >> >>> wrote: >> >>> >> > Make sure you set >> >>> >> > =C2=A0pci_set_consistent_dma_mask(dev, DMA_BIT_MASK(31)); >> >>> >> > >> >>> >> > on top of pci_set_dma_mask(dev, DMA_BIT_MASK(31)); >> >>> >> > in your driver. >> >>> >> > >> >>> >> A lot of work to port the driver to PV domU, hope it works. >> >>> > >> >>> > Hm? That is the normal way you would write drivers in the Linux ke= rnel. >> >>> > You use the DMA API in it to deal with the PCI devices. >> >>> > >> >>> > Is the PV domU a Linux kernel or something else? >> >>> > >> >>> >> >>> Yes, the PV domU is linux kernel. >> >>> >> >>> I tested pci_alloc_consistent() verified on baremetal it worked with= 8GB SDRAM. >> >>> But while I ran it in XEN, pci_alloc_consistent() cannot allocate >> >>> memory successfully for 4MB although pci_set_dma_mask(), >> >> >> >> And what is the error? >> > >> > I cannot see any error, it just returned NULL. >> >> BTW, I will succeed if I allocate 2MB only. > > Ok, that is unsurprising. I don't know if you can do it any better on bar= emetal. > But I am failing to understand why you need such large swaths of contingo= us > memory. You can't do scatter gather? Or scatter gather on 2MB chunks? > I changed MAX_CONTIG_ORDER, and MAX_ORDER to 13 to fix this problem, finall= y. _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel From xen-devel-bounces@lists.xensource.com Fri Sep 09 12:58:06 2011 Return-path: Envelope-to: www-data@lists.xensource.com Delivery-date: Fri, 09 Sep 2011 12:58:06 -0700 Received: from localhost ([127.0.0.1] helo=lists.colo.xensource.com) by lists.xensource.com with esmtp (Exim 4.43) id 1R27DA-0000BX-EK; Fri, 09 Sep 2011 12:58:04 -0700 Received: from mail21.messagelabs.com ([85.158.143.35]) by lists.xensource.com with smtp (Exim 4.43) id 1R27C2-0008Ll-0n for xen-devel@lists.xensource.com; Fri, 09 Sep 2011 12:56:56 -0700 X-Env-Sender: davidtecher@yahoo.fr X-Msg-Ref: server-2.tower-21.messagelabs.com!1315598210!33520823!1 X-Originating-IP: [77.238.189.199] X-StarScan-Version: 6.3.6; banners=-,-,- X-VirusChecked: Checked Received: (qmail 11030 invoked from network); 9 Sep 2011 19:56:50 -0000 Received: from nm2-vm0.bullet.mail.ird.yahoo.com (HELO nm2-vm0.bullet.mail.ird.yahoo.com) (77.238.189.199) by server-2.tower-21.messagelabs.com with SMTP; 9 Sep 2011 19:56:50 -0000 Received: from [77.238.189.56] by nm2.bullet.mail.ird.yahoo.com with NNFMP; 09 Sep 2011 19:56:50 -0000 Received: from [212.82.108.247] by tm9.bullet.mail.ird.yahoo.com with NNFMP; 09 Sep 2011 19:56:50 -0000 Received: from [127.0.0.1] by omp1012.mail.ird.yahoo.com with NNFMP; 09 Sep 2011 19:56:50 -0000 X-Yahoo-Newman-Property: ymail-3 X-Yahoo-Newman-Id: 670002.9295.bm@omp1012.mail.ird.yahoo.com Received: (qmail 2471 invoked by uid 60001); 9 Sep 2011 19:56:50 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.fr; s=s1024; t=1315598210; bh=ZaDNL2i2gvq1YyQorSFxCvlut/PmbcGgsZajB8YmQYY=; h=X-YMail-OSG:Received:X-Mailer:References:Message-ID:Date:From:Reply-To:Subject:To:In-Reply-To:MIME-Version:Content-Type; b=IrF4bMYrHhil0A4h8z9p8UxjH75jCowUsoJki8Sd1Lj15/eblu85SEgpZ83/KPxRwWdaRKay5F7KBx2l1vRdGIXbXsmt5KqGl9ytdXapCbBOk9RzFetiNJWlo6aB8cvWAG2TJqLbi35LvfUb1iIdDyztln3zrTeu2Fz/iNtwAnQ= DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.fr; h=X-YMail-OSG:Received:X-Mailer:References:Message-ID:Date:From:Reply-To:Subject:To:In-Reply-To:MIME-Version:Content-Type; b=AJIa1zJJbmwKMhV/Sw2sa0iu6YNyPxLV3qDCCPe9PemiXA+3NPrTOaiE4KWM3jIv04n9LhlB/t2pcrpItdQRBxeNcsdn/Wuts1qihsKRxHBVKus/U3F2380sj+eZmfLXic/zjuV/udr/5QF8kITHX/RnMx6p0BrEz+MbLFQVklo=; X-YMail-OSG: FtRT0SwVM1npGMOPGj4Zw53HE7yJM3UbYHyq0g8s76CQWy1 JSLw2TMVnyTpr6b7FTgVuj9AiaI10HM6mMfKx7uBu55iXBzl9XLLZxUpDAsQ eARYxbcs2aJH3rn9gWbgTDWDB00kp_MLFKmSGc1RQrURk62ZP5TBTeTYZtK1 daXWEaiZAqKwNANNsD9S.w2EZqyBi4yzL0N0vs4uj.yJiHmvwnt8TTOkxJ4Y hYBEq8w_D3k9cyzqs3Tn1wT88pbxZcJB7cP498db4S0j7_gRQeWH8BjVj_gM sUig4TNajK1dnEFyqLwiuUxa5mZ2StjvRed13bcY5mK4S6plTPYo9yquu8fQ 8bbRzk8Z5YZ41M2yjnWzS1N8gkH2XE9jF2gAd0M57.nVRILf2yRq3elvcvaR qpswxkEfbOYjitrz8zNXlvbh6owvjEnkJH8az7CCqbGDCT4QFlFbs_A0JTK5 _86Ey0YtdPNq6Il5W3CbNk0gB3wyQk42lgYgYbmXAOoX8OAXoLE9cYJ.41lO PkmBZIGk8q7Sv5h9bHbjmS9btrS1ZXyBzV_So4G2Ov0UJ8tKVtldS4Rposrq Ya7tl9SJYYLGDZ5MBfq_eU.gudOTT7EXblW7SDlJNWxn00CJLHACOeGzoPHO 6tuNeTNTbFsXp9dFlHYSTs7_TqKbJcIHkDO5825V5C1Y6jZp.N4FiwIYaMHv ZbFIrbW_v_yjZN5trLY_0cVBUdS.N9VjgYjpYNcvsAM4rPu9k5Nvn57GflHJ 052X0.Xol0Cg- Received: from [83.154.246.188] by web29815.mail.ird.yahoo.com via HTTP; Fri, 09 Sep 2011 20:56:50 BST X-Mailer: YahooMailWebService/0.8.113.315625 References: <1315310225039-4774097.post@n5.nabble.com> <1315343879.61837.YahooMailNeo@web29818.mail.ird.yahoo.com> <1315382742268-4777689.post@n5.nabble.com> <1315389138.56652.YahooMailNeo@web29801.mail.ird.yahoo.com> <1315398360680-4778339.post@n5.nabble.com> <1315401901083-4778494.post@n5.nabble.com> <1315403644525-4778586.post@n5.nabble.com> <1315405372.87224.YahooMailNeo@web29801.mail.ird.yahoo.com> <1315405921936-4778727.post@n5.nabble.com> <1315408931610-4778925.post@n5.nabble.com> <1315554847212-4785386.post@n5.nabble.com> Message-ID: <1315598210.99532.YahooMailNeo@web29815.mail.ird.yahoo.com> Date: Fri, 9 Sep 2011 20:56:50 +0100 (BST) From: David TECHER Subject: Re : Re : Re : Re : [Xen-devel] Re: Patches for VGA-Passthrough XEN 4.2 unstable To: komkon555 , "xen-devel@lists.xensource.com" In-Reply-To: <1315554847212-4785386.post@n5.nabble.com> MIME-Version: 1.0 Cc: X-BeenThere: xen-devel@lists.xensource.com X-Mailman-Version: 2.1.5 Precedence: list Reply-To: David TECHER List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1610218236==" Sender: xen-devel-bounces@lists.xensource.com Errors-To: xen-devel-bounces@lists.xensource.com --===============1610218236== Content-Type: multipart/alternative; boundary="0-1230709877-1315598210=:99532" --0-1230709877-1315598210=:99532 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable Please have a look on http://wiki.xensource.com/xenwiki/VTdHowTo.=0A=0AI've= just applied what it is recommended on the wiki. It works=A0 like a charm.= =0A=0A=0A=0AFor VGA,=0A=3D=3D=3D=3D=3D=3D=3D=3D=0A=0Ayou can use PCI_STUB, = I do not use it as module =0A=0Aroot@mercury:~# grep pci_stub -i /boot/conf= ig-2.6.39.3=0ACONFIG_PCI_STUB=3Dy=0A=0Aroot@mercury:~# lspci |grep VGA=0A01= :00.0 VGA compatible controller: nVidia Corporation Device 0de0 (rev a1)=0A= =0A=0A=0Aroot@mercury:~# lspci -s 01:00.0 -n=0A01:00.0 0300: 10de:0de0 (rev= a1)=0A=0ACreate a script with the following content=0A=0Aroot@mercury:~# g= rep -vE '^(#|$)' start_windows.sh =0Aecho "10de 0de0" > /sys/bus/pci/driver= s/pci-stub/new_id=0Aecho "0000:01:00.0" > /sys/bus/pci/devices/0000:01:00.0= /driver/unbind=0Aecho "0000:01:00.0" > /sys/bus/pci/drivers/pci-stub/bind= =0Axl=A0 create /etc/xen/machines/mercury-xen03.cfg=0A=0AFor KeyBoard and M= ouse=0A=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=0A=0AUse p= assthrough. =0A=0Aroot@mercury:~# grep CONFIG_XEN_PCIDEV_BACKEND=3D=A0 /boo= t/config-2.6.39.3=0ACONFIG_XEN_PCIDEV_BACKEND=3Dy=0A=0AI've got two USB con= trollers (1: mouse + keyboard, 2: for sound Logitech USB Speaker)=0A=0Aroot= @mercury:~# lspci |grep USB=0A00:1a.0 USB Controller: Intel Corporation Cou= gar Point USB Enhanced Host Controller #2 (rev 05)=0A00:1d.0 USB Controller= : Intel Corporation Cougar Point USB Enhanced Host Controller #1 (rev 05)= =0A=0APut it on grub so that dom0 will not use it=0A=0Aroot@mercury:~# grep= permissive /boot/grub/grub.cfg =0A=A0=A0=A0=A0=A0=A0=A0 module=A0 /boot/vm= linuz-2.6.39.3 placeholder root=3DUUID=3D1cd457ae-85f4-4626-8f94-1f444fcf6d= 5c ro nomodeset xen-pciback.permissive xen-pciback.hide=3D(00:1a.0)(00:1d.0= ) quiet=0A=0AIn my=A0 domU configuration file=0A=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=0Aroot@mercury:~# grep ^pci /etc/xe= n/machines/mercury-xen03.cfg=0Apci=A0 =3D [ '01:00.0','00:1a.0','00:1d.0' ]= =0A=0A=0A=0A=0A=0A=0A________________________________=0ADe=A0: komkon555 =0A=C0=A0: xen-devel@lists.xensource.com=0AEnvoy=E9 le = : Vendredi 9 Septembre 2011 9h54=0AObjet=A0: Re: Re : Re : Re : [Xen-devel]= Re: Patches for VGA-Passthrough XEN 4.2 unstable=0A=0A=A0 =A0 =A0 =A0 =A0 = Hi. There is the promised report to JavMV: with fixes on dsd are=0Ayour pa= tches also functional. Windows XP starts and GTX260 works perfect=0Awith dr= iver version 275.33.=0A=A0 =A0 =A0 =A0 =A0 Some news more: The best results= I got with this configuration:=0Axen 4.1-unstable changeset 21668 (patched= clearly with these =0Ahttp://lists.xensource.com/archives/html/xen-devel/2= 010-05/msg00441.html=0Apatches , dsd fixed according to David TECHER) + jer= emi xen kernel 2.6.32.45=0A(xenfs static). This configuration works excelle= nt both: with primary and=0Asecondary vga-adapter (GTX260). There are two P= roblem with all=0Aconfigurations:=0A1. DomU can be started only once. Being= =A0 correctly shouted=A0 down, starts=0ADomU no more.=0A2. Physical usb- ke= yboard and mouse can not be assigned to DomU (regular usb=0Aassignment has = no effect, PVUSB crashes)=0A=0ABest regards=0AKom.=0A=0A=0A--=0AView this m= essage in context: http://xen.1045712.n5.nabble.com/Patches-for-VGA-Passthr= ough-XEN-4-2-unstable-tp4406265p4785386.html=0ASent from the Xen - Dev mail= ing list archive at Nabble.com.=0A=0A______________________________________= _________=0AXen-devel mailing list=0AXen-devel@lists.xensource.com=0Ahttp:/= /lists.xensource.com/xen-devel --0-1230709877-1315598210=:99532 Content-Type: text/html; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable
Please hav= e a look on http://wiki.xensource.com/xenwiki/VTdHowTo.
I've just applied what it is recommended on= the wiki. It works  like a charm.

<= /div>


For= VGA,
=3D=3D=3D=3D=3D=3D=3D=3D
= you can use PCI_STUB, I do not use it as module

root@mercury:~# grep pci_stub -i /boot/config-2.6.3= 9.3
CONFIG_PCI_STUB=3Dy

root@mercury:~# lspci |grep VGA
01:00.= 0 VGA compatible controller: nVidia Corporation Device 0de0 (rev a1)


root@mercury:~# lspci -s 01:00.0 -n
01:00.0 0300: 10de:0de0 (re= v a1)

Create a script with the following content

root@mercury= :~# grep -vE '^(#|$)' start_windows.sh
echo "10de 0de0" > /sys/bus/pci/drivers/p= ci-stub/new_id
echo "0000:01:00.0" > /sys/bus/pci/devices/0000:01:00.= 0/driver/unbind
echo "0000:01:00.0" > /sys/bus/pci/drivers/pci-stub/b= ind
xl  create /etc/xen/machines/mercury-xen03.cfg

For KeyBo= ard and Mouse
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D<= br>
Use passthrough.

root@mercury:~# grep CONFIG_XEN_PCIDEV_BACK= END=3D  /boot/config-2.6.39.3
CONFIG_XEN_PCIDEV_BACKEND=3Dy

= I've got two USB controllers (1: mouse + keyboard, 2: for sound Logitech US= B Speaker)

root@mercury:~# lspci |grep USB
00:1a.0 USB Controller= : Intel Corporation Cougar Point USB Enhanced Host Controller #2 (rev 05)00:1d.0 USB Controller: Intel Corporation Cougar Point USB Enhanced Host = Controller #1 (rev 05)

Put it on grub so that dom0 will not use it
root@mercury:~# grep permissive /boot/grub/grub.cfg
  &= nbsp;     module  /boot/vmlinuz-2.6.39.3 placeholder root=3DUUID=3D1cd457ae-85f= 4-4626-8f94-1f444fcf6d5c ro nomodeset xen-pciback.permissive xen-pciback.hi= de=3D(00:1a.0)(00:1d.0) quiet

In my  domU configuration file=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
root= @mercury:~# grep ^pci /etc/xen/machines/mercury-xen03.cfg
pci  =3D = [ '01:00.0','00:1a.0','00:1d.0' ]




De : komkon555 <komkon555@freenet= .de>
=C0 : xen-= devel@lists.xensource.com
Envoy=E9= le : Vendredi 9 Septembre 2011 9h54
Objet : Re: Re : Re : Re : [Xen-devel] Re: Patches for VGA-Passthrough XEN 4.2 unstable

  &nbs= p;       Hi. There is the promised report to JavMV: with fi= xes on dsd are
your patches also functional. Windows XP starts and GTX26= 0 works perfect
with driver version 275.33.
      &nbs= p;   Some news more: The best results I got with this configuration:xen 4.1-unstable changeset 21668 (patched clearly with these
http://lists.xensource.com/archives/html/xen-devel/201= 0-05/msg00441.html
patches , dsd fixed according to David TECHER) + = jeremi xen kernel 2.6.32.45
(xenfs static). This configuration works exc= ellent both: with primary and
secondary vga-adapter (GTX260). There are = two Problem with all
configurations:
1. DomU can be started only once= . Being  correctly shouted  down, starts
DomU no more.
2. Physical usb- keyboard and mouse can not be assigned to DomU (regular usb<= br>assignment has no effect, PVUSB crashes)

Best regards
Kom.
=

--
View this message in context: http://xen.1045712.n5.nabble.com/Patches-for-VGA-P= assthrough-XEN-4-2-unstable-tp4406265p4785386.html
Sent from the Xen= - Dev mailing list archive at Nabble.com.

_________________________= ______________________
Xen-devel mailing list
= Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

--0-1230709877-1315598210=:99532-- --===============1610218236== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel --===============1610218236==-- From xen-devel-bounces@lists.xensource.com Fri Sep 09 15:22:57 2011 Return-path: Envelope-to: www-data@lists.xensource.com Delivery-date: Fri, 09 Sep 2011 15:22:57 -0700 Received: from localhost ([127.0.0.1] helo=lists.colo.xensource.com) by lists.xensource.com with esmtp (Exim 4.43) id 1R29TM-0006Bz-Ri; Fri, 09 Sep 2011 15:22:56 -0700 Received: from mail182.messagelabs.com ([85.158.139.83]) by lists.xensource.com with smtp (Exim 4.43) id 1R29Sh-0005zU-QS for xen-devel@lists.xensource.com; Fri, 09 Sep 2011 15:22:17 -0700 X-Env-Sender: therion@ninth-art.de X-Msg-Ref: server-10.tower-182.messagelabs.com!1315606932!17737354!1 X-Originating-IP: [88.198.12.237] X-StarScan-Version: 6.3.6; banners=-,-,- X-VirusChecked: Checked Received: (qmail 12394 invoked from network); 9 Sep 2011 22:22:12 -0000 Received: from coruscant.unix.io (HELO mail.unix.io) (88.198.12.237) by server-10.tower-182.messagelabs.com with SMTP; 9 Sep 2011 22:22:12 -0000 Received: from coruscant.unix.io (localhost [127.0.0.1]) by mail.unix.io (Postfix) with ESMTP id EB1659BCA6 for ; Sat, 10 Sep 2011 00:22:11 +0200 (CEST) X-Virus-Scanned: amavisd-new at unix.io Received: from mail.unix.io ([127.0.0.1]) by coruscant.unix.io (mail.unix.io [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jKHQab_B2tYW for ; Sat, 10 Sep 2011 00:22:04 +0200 (CEST) Received: from [192.168.2.2] (dslb-084-062-144-204.pools.arcor-ip.net [84.62.144.204]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.unix.io (Postfix) with ESMTPSA id 3D7639BCA5 for ; Sat, 10 Sep 2011 00:22:02 +0200 (CEST) From: Georg Bege To: xen-devel@lists.xensource.com Content-Type: multipart/mixed; boundary="=-D3WmHD95xIQTgQFeJxa9" Date: Sat, 10 Sep 2011 00:21:56 +0200 Message-ID: <1315606916.3323.6.camel@kali.ninth-art.net> Mime-Version: 1.0 X-Mailer: Evolution 2.32.2 Subject: [Xen-devel] Intel-VTd problem X-BeenThere: xen-devel@lists.xensource.com X-Mailman-Version: 2.1.5 Precedence: list Reply-To: therion@ninth-art.de List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xensource.com Errors-To: xen-devel-bounces@lists.xensource.com --=-D3WmHD95xIQTgQFeJxa9 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: 7bit Hello to you guys, yeah Im also one of the people who seem to have a corrupted BIOS. I read already stuff about the issue's with certain vendors - and I guess in one particular area it was made clear that even you cant do a lot about it you still collect details. CPU Intel Core i7 X980 Mainboard Asus P6T WS Professional (X58/LGA1333)(bios 1207) rev. 1.01G I also have two other questions (last time I was testing Xen it was back in '06). A) (XEN) Enabled directed EOI with ioapic_ack_old on! (XEN) ENABLING IO-APIC IRQs (XEN) -> Using old ACK method What does this mean? B) When the hypervisor tries to load my DOM0 it takes a long time until it continues the boot process (it hangs somewhere after freeing unused memory (loaded the initrd)) - what could that be? I append my dmesg logs (both XEN and DOM0). My host OS is a Gentoo GNU/Linux running 2.6.38-xen kernel. therion@kali ~ > qlist -Iv xen app-emulation/xen-4.1.1 app-emulation/xen-tools-4.1.1-r1 sys-kernel/xen-sources-2.6.38 cheers -- Georg Bege --=-D3WmHD95xIQTgQFeJxa9 Content-Disposition: attachment; filename="xen-dmesg.log" Content-Type: text/x-log; name="xen-dmesg.log"; charset="UTF-8" Content-Transfer-Encoding: 7bit __ __ _ _ _ _ \ \/ /___ _ __ | || | / | / | \ // _ \ '_ \ | || |_ | | | | / \ __/ | | | |__ _|| |_| | /_/\_\___|_| |_| |_|(_)_(_)_| (XEN) Xen version 4.1.1 (root@ninth-art.net) (gcc version 4.5.3 (Gentoo 4.5.3-r1 p1.0, pie-0.4.5) ) Fri Sep 9 21:36:17 CEST 2011 (XEN) Latest ChangeSet: unavailable (XEN) Bootloader: GNU GRUB 0.97 (XEN) Command line: iommu=verbose iommu_inclusive_mapping=1 (XEN) Video information: (XEN) VGA is text mode 80x25, font 8x16 (XEN) VBE/DDC methods: none; EDID transfer time: 0 seconds (XEN) EDID info not retrieved because no DDC retrieval method detected (XEN) Disc information: (XEN) Found 0 MBR signatures (XEN) Found 6 EDD information structures (XEN) Xen-e820 RAM map: (XEN) 0000000000000000 - 000000000009c000 (usable) (XEN) 000000000009c000 - 00000000000a0000 (reserved) (XEN) 00000000000e5000 - 0000000000100000 (reserved) (XEN) 0000000000100000 - 00000000bf780000 (usable) (XEN) 00000000bf780000 - 00000000bf798000 (ACPI data) (XEN) 00000000bf798000 - 00000000bf7dc000 (ACPI NVS) (XEN) 00000000bf7dc000 - 00000000c0000000 (reserved) (XEN) 00000000fee00000 - 00000000fee01000 (reserved) (XEN) 00000000ffe00000 - 0000000100000000 (reserved) (XEN) 0000000100000000 - 0000000340000000 (usable) (XEN) ACPI: RSDP 000FB2C0, 0024 (r2 ACPIAM) (XEN) ACPI: XSDT BF780100, 0064 (r1 092410 XSDT1941 20100924 MSFT 97) (XEN) ACPI: FACP BF780290, 00F4 (r3 092410 FACP1941 20100924 MSFT 97) (XEN) ACPI: DSDT BF7804B0, B119 (r1 A1095 A1095001 1 INTL 20060113) (XEN) ACPI: FACS BF798000, 0040 (XEN) ACPI: APIC BF780390, 00D8 (r1 092410 APIC1941 20100924 MSFT 97) (XEN) ACPI: MCFG BF780470, 003C (r1 092410 OEMMCFG 20100924 MSFT 97) (XEN) ACPI: OEMB BF798040, 0072 (r1 092410 OEMB1941 20100924 MSFT 97) (XEN) ACPI: HPET BF78F4B0, 0038 (r1 092410 OEMHPET 20100924 MSFT 97) (XEN) ACPI: DMAR BF7980C0, 0138 (r1 AMI OEMDMAR 1 MSFT 97) (XEN) ACPI: OSFR BF78F4F0, 00B0 (r1 092410 OEMOSFR 20100924 MSFT 97) (XEN) ACPI: SSDT BF79C360, 0363 (r1 DpgPmm CpuPm 12 INTL 20060113) (XEN) System RAM: 12279MB (12573808kB) (XEN) Domain heap initialised (XEN) Processor #0 6:12 APIC version 21 (XEN) Processor #2 6:12 APIC version 21 (XEN) Processor #4 6:12 APIC version 21 (XEN) Processor #16 6:12 APIC version 21 (XEN) Processor #18 6:12 APIC version 21 (XEN) Processor #20 6:12 APIC version 21 (XEN) Processor #1 6:12 APIC version 21 (XEN) Processor #3 6:12 APIC version 21 (XEN) Processor #5 6:12 APIC version 21 (XEN) Processor #17 6:12 APIC version 21 (XEN) Processor #19 6:12 APIC version 21 (XEN) Processor #21 6:12 APIC version 21 (XEN) IOAPIC[0]: apic_id 6, version 32, address 0xfec00000, GSI 0-23 (XEN) IOAPIC[1]: apic_id 7, version 32, address 0xfec8a000, GSI 24-47 (XEN) Enabling APIC mode: Phys. Using 2 I/O APICs (XEN) [VT-D]dmar.c:702: Host address width 39 (XEN) [VT-D]dmar.c:717: found ACPI_DMAR_DRHD: (XEN) [VT-D]dmar.c:413: dmaru->address = fbfff000 (XEN) [VT-D]iommu.c:1114: drhd->address = fbfff000 iommu->reg = ffff82c3fff57000 (XEN) [VT-D]iommu.c:1116: cap = c9008010e60262 ecap = f0207a (XEN) [VT-D]dmar.c:341: endpoint: 0:1b.0 (XEN) [VT-D]dmar.c:717: found ACPI_DMAR_DRHD: (XEN) [VT-D]dmar.c:413: dmaru->address = fbffe000 (XEN) [VT-D]iommu.c:1114: drhd->address = fbffe000 iommu->reg = ffff82c3fff56000 (XEN) [VT-D]iommu.c:1116: cap = c90780106f0462 ecap = f020fe (XEN) [VT-D]dmar.c:356: IOAPIC: f0:1f.7 (XEN) [VT-D]dmar.c:356: IOAPIC: 0:13.0 (XEN) [VT-D]dmar.c:427: flags: INCLUDE_ALL (XEN) [VT-D]dmar.c:722: found ACPI_DMAR_RMRR: (XEN) [VT-D]dmar.c:341: endpoint: 0:1d.0 (XEN) [VT-D]dmar.c:341: endpoint: 0:1d.1 (XEN) [VT-D]dmar.c:341: endpoint: 0:1d.2 (XEN) [VT-D]dmar.c:341: endpoint: 0:1d.7 (XEN) [VT-D]dmar.c:341: endpoint: 0:1a.0 (XEN) [VT-D]dmar.c:341: endpoint: 0:1a.1 (XEN) [VT-D]dmar.c:341: endpoint: 0:1a.2 (XEN) [VT-D]dmar.c:341: endpoint: 0:1a.7 (XEN) [VT-D]dmar.c:594: RMRR region: base_addr ec000 end_address effff (XEN) [VT-D]dmar.c:722: found ACPI_DMAR_RMRR: (XEN) [VT-D]dmar.c:527: RMRR address range not in reserved memory base = bf7dc000 end = bf7dbfff; iommu_inclusive_mapping=1 parameter may be needed. (XEN) [VT-D]dmar.c:341: endpoint: 0:1d.0 (XEN) [VT-D]dmar.c:341: endpoint: 0:1d.1 (XEN) [VT-D]dmar.c:341: endpoint: 0:1d.2 (XEN) [VT-D]dmar.c:341: endpoint: 0:1d.7 (XEN) [VT-D]dmar.c:341: endpoint: 0:1a.0 (XEN) [VT-D]dmar.c:341: endpoint: 0:1a.1 (XEN) [VT-D]dmar.c:341: endpoint: 0:1a.2 (XEN) [VT-D]dmar.c:341: endpoint: 0:1a.7 (XEN) [VT-D]dmar.c:584: The RMRR (bf7dc000, bf7dbfff) is incorrect! (XEN) Failed to parse ACPI DMAR. Disabling VT-d. (XEN) Table is not found! (XEN) Using scheduler: SMP Credit Scheduler (credit) (XEN) Detected 3340.984 MHz processor. (XEN) Initing memory sharing. (XEN) I/O virtualisation disabled (XEN) Enabled directed EOI with ioapic_ack_old on! (XEN) ENABLING IO-APIC IRQs (XEN) -> Using old ACK method (XEN) Platform timer is 14.318MHz HPET (XEN) Allocated console ring of 32 KiB. (XEN) VMX: Supported advanced features: (XEN) - APIC MMIO access virtualisation (XEN) - APIC TPR shadow (XEN) - Extended Page Tables (EPT) (XEN) - Virtual-Processor Identifiers (VPID) (XEN) - Virtual NMI (XEN) - MSR direct-access bitmap (XEN) - Unrestricted Guest (XEN) EPT supports 1GB super page. (XEN) EPT supports 2MB super page. (XEN) HVM: ASIDs enabled. (XEN) HVM: VMX enabled (XEN) HVM: Hardware Assisted Paging detected. (XEN) Brought up 12 CPUs (XEN) *** LOADING DOMAIN 0 *** (XEN) Xen kernel: 64-bit, lsb, compat32 (XEN) Dom0 kernel: 64-bit, lsb, paddr 0x1000000 -> 0x16d5000 (XEN) PHYSICAL MEMORY ARRANGEMENT: (XEN) Dom0 alloc.: 0000000334000000->0000000336000000 (3066033 pages to be allocated) (XEN) Init. ramdisk: 000000033fbb6000->0000000340000000 (XEN) VIRTUAL MEMORY ARRANGEMENT: (XEN) Loaded kernel: ffffffff81000000->ffffffff816d5000 (XEN) Init. ramdisk: 0000000000000000->0000000000000000 (XEN) Phys-Mach map: ffffea0000000000->ffffea00017767d8 (XEN) Start info: ffffffff816d5000->ffffffff816d54b4 (XEN) Page tables: ffffffff816d6000->ffffffff816e5000 (XEN) Boot stack: ffffffff816e5000->ffffffff816e6000 (XEN) TOTAL: ffffffff80000000->ffffffff81800000 (XEN) ENTRY ADDRESS: ffffffff81000000 (XEN) Dom0 has maximum 12 VCPUs (XEN) Scrubbing Free RAM: .done. (XEN) Xen trace buffers: disabled (XEN) Std. Loglevel: Errors and warnings (XEN) Guest Loglevel: Nothing (Rate-limited: Errors and warnings) (XEN) Xen is relinquishing VGA console. (XEN) *** Serial input -> DOM0 (type 'CTRL-a' three times to switch input to Xen) (XEN) Freed 216kB init memory. --=-D3WmHD95xIQTgQFeJxa9 Content-Disposition: attachment; filename="gentoo-dmesg.log" Content-Type: text/x-log; name="gentoo-dmesg.log"; charset="UTF-8" Content-Transfer-Encoding: 7bit [ 0.000000] Initializing cgroup subsys cpu [ 0.000000] Linux version 2.6.38-xen-kali (root@kali) (gcc version 4.5.3 (Gentoo 4.5.3-r1 p1.0, pie-0.4.5) ) #3 SMP Fri Sep 9 23:25:46 CEST 2011 [ 0.000000] Command line: root=/dev/ram0 real_root=/dev/md0 init=/init intel_iommu=on [ 0.000000] Xen-provided machine memory map: [ 0.000000] BIOS: 0000000000000000 - 000000000009c000 (usable) [ 0.000000] BIOS: 000000000009c000 - 00000000000a0000 (reserved) [ 0.000000] BIOS: 00000000000e5000 - 0000000000100000 (reserved) [ 0.000000] BIOS: 0000000000100000 - 00000000bf780000 (usable) [ 0.000000] BIOS: 00000000bf780000 - 00000000bf798000 (ACPI data) [ 0.000000] BIOS: 00000000bf798000 - 00000000bf7dc000 (ACPI NVS) [ 0.000000] BIOS: 00000000bf7dc000 - 00000000c0000000 (reserved) [ 0.000000] BIOS: 00000000fec00000 - 00000000fec01000 (reserved) [ 0.000000] BIOS: 00000000fec8a000 - 00000000fec8b000 (reserved) [ 0.000000] BIOS: 00000000fee00000 - 00000000fee01000 (reserved) [ 0.000000] BIOS: 00000000ffe00000 - 0000000100000000 (reserved) [ 0.000000] BIOS: 0000000100000000 - 0000000340000000 (usable) [ 0.000000] Xen-provided physical RAM map: [ 0.000000] Xen: 0000000000000000 - 00000002ef4fb000 (usable) [ 0.000000] NX (Execute Disable) protection: active [ 0.000000] DMI 2.5 present. [ 0.000000] DMI: System manufacturer System Product Name/P6T WS PRO, BIOS 1205 09/24/2010 [ 0.000000] last_pfn = 0x2ef4fb max_arch_pfn = 0x80000000 [ 0.000000] last_pfn = 0x100000 max_arch_pfn = 0x80000000 [ 0.000000] initial memory mapped : 0 - 00000000 [ 0.000000] init_memory_mapping: 0000000000000000-0000000100000000 [ 0.000000] 0000000000 - 0100000000 page 4k [ 0.000000] kernel direct mapping tables up to 100000000 @ 16e5000-1eea000 [ 0.000000] init_memory_mapping: 0000000100000000-00000002ef4fb000 [ 0.000000] 0100000000 - 02ef4fb000 page 4k [ 0.000000] kernel direct mapping tables up to 2ef4fb000 @ 1eea000-3672000 [ 0.000000] RAMDISK: 02000000 - 0244a000 [ 0.000000] ACPI: RSDP 00000000000fb2c0 00024 (v02 ACPIAM) [ 0.000000] ACPI: XSDT 00000000bf780100 00064 (v01 092410 XSDT1941 20100924 MSFT 00000097) [ 0.000000] ACPI: FACP 00000000bf780290 000F4 (v03 092410 FACP1941 20100924 MSFT 00000097) [ 0.000000] ACPI: DSDT 00000000bf7804b0 0B119 (v01 A1095 A1095001 00000001 INTL 20060113) [ 0.000000] ACPI: FACS 00000000bf798000 00040 [ 0.000000] ACPI: APIC 00000000bf780390 000D8 (v01 092410 APIC1941 20100924 MSFT 00000097) [ 0.000000] ACPI: MCFG 00000000bf780470 0003C (v01 092410 OEMMCFG 20100924 MSFT 00000097) [ 0.000000] ACPI: OEMB 00000000bf798040 00072 (v01 092410 OEMB1941 20100924 MSFT 00000097) [ 0.000000] ACPI: HPET 00000000bf78f4b0 00038 (v01 092410 OEMHPET 20100924 MSFT 00000097) [ 0.000000] ACPI: XMAR 00000000bf7980c0 00138 (v01 AMI OEMDMAR 00000001 MSFT 00000097) [ 0.000000] ACPI: OSFR 00000000bf78f4f0 000B0 (v01 092410 OEMOSFR 20100924 MSFT 00000097) [ 0.000000] ACPI: SSDT 00000000bf79c360 00363 (v01 DpgPmm CpuPm 00000012 INTL 20060113) [ 0.000000] Zone PFN ranges: [ 0.000000] DMA 0x00000000 -> 0x00001000 [ 0.000000] DMA32 0x00001000 -> 0x00100000 [ 0.000000] Normal 0x00100000 -> 0x002ef4fb [ 0.000000] Movable zone start PFN for each node [ 0.000000] early_node_map[2] active PFN ranges [ 0.000000] 0: 0x00000000 -> 0x002eecfb [ 0.000000] 0: 0x002ef4fb -> 0x002ef4fb [ 0.000000] On node 0 totalpages: 3075323 [ 0.000000] free_area_init_node: node 0, pgdat ffffffff815b5500, node_mem_map ffff8802e4897000 [ 0.000000] DMA zone: 56 pages used for memmap [ 0.000000] DMA zone: 0 pages reserved [ 0.000000] DMA zone: 4040 pages, LIFO batch:0 [ 0.000000] DMA32 zone: 14280 pages used for memmap [ 0.000000] DMA32 zone: 1030200 pages, LIFO batch:31 [ 0.000000] Normal zone: 27738 pages used for memmap [ 0.000000] Normal zone: 1999009 pages, LIFO batch:31 [ 0.000000] ACPI: LAPIC (acpi_id[0x01] lapic_id[0x00] enabled) [ 0.000000] ACPI: LAPIC (acpi_id[0x02] lapic_id[0x02] enabled) [ 0.000000] ACPI: LAPIC (acpi_id[0x03] lapic_id[0x04] enabled) [ 0.000000] ACPI: LAPIC (acpi_id[0x04] lapic_id[0x10] enabled) [ 0.000000] ACPI: LAPIC (acpi_id[0x05] lapic_id[0x12] enabled) [ 0.000000] ACPI: LAPIC (acpi_id[0x06] lapic_id[0x14] enabled) [ 0.000000] ACPI: LAPIC (acpi_id[0x07] lapic_id[0x01] enabled) [ 0.000000] ACPI: LAPIC (acpi_id[0x08] lapic_id[0x03] enabled) [ 0.000000] ACPI: LAPIC (acpi_id[0x09] lapic_id[0x05] enabled) [ 0.000000] ACPI: LAPIC (acpi_id[0x0a] lapic_id[0x11] enabled) [ 0.000000] ACPI: LAPIC (acpi_id[0x0b] lapic_id[0x13] enabled) [ 0.000000] ACPI: LAPIC (acpi_id[0x0c] lapic_id[0x15] enabled) [ 0.000000] ACPI: LAPIC (acpi_id[0x0d] lapic_id[0x8c] disabled) [ 0.000000] ACPI: LAPIC (acpi_id[0x0e] lapic_id[0x8d] disabled) [ 0.000000] ACPI: LAPIC (acpi_id[0x0f] lapic_id[0x8e] disabled) [ 0.000000] ACPI: LAPIC (acpi_id[0x10] lapic_id[0x8f] disabled) [ 0.000000] ACPI: IOAPIC (id[0x06] address[0xfec00000] gsi_base[0]) [ 0.000000] IOAPIC[0]: apic_id 6, version 32, address 0xfec00000, GSI 0-23 [ 0.000000] ACPI: IOAPIC (id[0x07] address[0xfec8a000] gsi_base[24]) [ 0.000000] IOAPIC[1]: apic_id 7, version 32, address 0xfec8a000, GSI 24-47 [ 0.000000] ACPI: INT_SRC_OVR (bus 0 bus_irq 0 global_irq 2 dfl dfl) [ 0.000000] ACPI: INT_SRC_OVR (bus 0 bus_irq 9 global_irq 9 high level) [ 0.000000] ACPI: IRQ0 used by override. [ 0.000000] ACPI: IRQ2 used by override. [ 0.000000] ACPI: IRQ9 used by override. [ 0.000000] Using ACPI (MADT) for SMP configuration information [ 0.000000] Allocating PCI resources starting at c0000000 (gap: c0000000:3ec00000) [ 0.000000] setup_percpu: NR_CPUS:12 nr_cpumask_bits:12 nr_cpu_ids:12 nr_node_ids:1 [ 0.000000] PERCPU: Embedded 18 pages/cpu @ffff8802e3002000 s41856 r8192 d23680 u73728 [ 0.000000] pcpu-alloc: s41856 r8192 d23680 u73728 alloc=18*4096 [ 0.000000] pcpu-alloc: [0] 00 [0] 01 [0] 02 [0] 03 [0] 04 [0] 05 [0] 06 [0] 07 [ 0.000000] pcpu-alloc: [0] 08 [0] 09 [0] 10 [0] 11 [ 0.000000] Swapping MFNs for PFN 15c1 and 2e3008 (MFN 3355c1 and 13c13) [ 0.000000] Built 1 zonelists in Zone order, mobility grouping on. Total pages: 3033249 [ 0.000000] Kernel command line: root=/dev/ram0 real_root=/dev/md0 init=/init intel_iommu=on [ 0.000000] PID hash table entries: 4096 (order: 3, 32768 bytes) [ 0.000000] Dentry cache hash table entries: 2097152 (order: 12, 16777216 bytes) [ 0.000000] Inode-cache hash table entries: 1048576 (order: 11, 8388608 bytes) [ 0.000000] Software IO TLB enabled: [ 0.000000] Aperture: 64 megabytes [ 0.000000] Address size: 27 bits [ 0.000000] Kernel range: ffff8802dd7fa000 - ffff8802e17fa000 [ 0.000000] PCI-DMA: Using software bounce buffering for IO (SWIOTLB) [ 0.000000] Memory: 11981808k/12309484k available (4167k kernel code, 8192k absent, 319484k reserved, 1695k data, 376k init) [ 0.000000] SLUB: Genslabs=15, HWalign=64, Order=0-3, MinObjects=0, CPUs=12, Nodes=1 [ 0.000000] Hierarchical RCU implementation. [ 0.000000] nr_pirqs: 64 [ 0.000000] NR_IRQS:5376 nr_irqs:1088 16 [ 0.000000] Extended CMOS year: 2000 [ 0.000000] Xen reported: 3340.984 MHz processor. [ 0.000000] Console: colour VGA+ 80x25 [ 0.000000] console [tty0] enabled [ 0.000000] console [xvc-1] enabled [ 0.059996] Calibrating delay using timer specific routine.. 7040.49 BogoMIPS (lpj=3520248) [ 0.060093] pid_max: default: 32768 minimum: 301 [ 0.060163] Mount-cache hash table entries: 256 [ 0.060287] Initializing cgroup subsys blkio [ 0.060359] mce: CPU supports 9 MCE banks [ 0.060453] Freeing SMP alternatives: 12k freed [ 0.060505] ACPI: Core revision 20110112 [ 0.067478] Brought up 12 CPUs [ 0.067545] devtmpfs: initialized [ 0.067545] xor: automatically using best checksumming function: generic_sse [ 0.071996] generic_sse: 11216.000 MB/sec [ 0.072044] xor: using function: generic_sse (11216.000 MB/sec) [ 0.072123] NET: Registered protocol family 16 [ 0.072189] ACPI: bus type pci registered [ 0.072189] PCI: MMCONFIG for domain 0000 [bus 00-ff] at [mem 0xe0000000-0xefffffff] (base 0xe0000000) [ 0.072189] PCI: not using MMCONFIG [ 0.072189] PCI: Using configuration type 1 for base access [ 0.075031] bio: create slab at 0 [ 0.092008] raid6: int64x1 3945 MB/s [ 0.109004] raid6: int64x2 3867 MB/s [ 0.125993] raid6: int64x4 3402 MB/s [ 0.143003] raid6: int64x8 3164 MB/s [ 0.159990] raid6: sse2x1 9707 MB/s [ 0.176989] raid6: sse2x2 11238 MB/s [ 0.193981] raid6: sse2x4 12945 MB/s [ 0.194030] raid6: using algorithm sse2x4 (12945 MB/s) [ 0.194596] ACPI: EC: Look up EC in DSDT [ 0.195378] ACPI: Executed 1 blocks of module-level executable AML code [ 0.223087] ACPI: SSDT 00000000bf798200 03978 (v01 DpgPmm P001Ist 00000011 INTL 20060113) [ 0.223490] ACPI: Dynamic OEM Table Load: [ 0.223594] ACPI: SSDT (null) 03978 (v01 DpgPmm P001Ist 00000011 INTL 20060113) [ 0.223859] ACPI: SSDT 00000000bf79bb80 007DD (v01 PmRef P001Cst 00003001 INTL 20060113) [ 0.224091] ACPI: Dynamic OEM Table Load: [ 0.224196] ACPI: SSDT (null) 007DD (v01 PmRef P001Cst 00003001 INTL 20060113) [ 0.228166] ACPI: Interpreter enabled [ 0.228216] ACPI: (supports S0 S5) [ 0.228323] ACPI: Using IOAPIC for interrupt routing [ 0.228397] PCI: MMCONFIG for domain 0000 [bus 00-ff] at [mem 0xe0000000-0xefffffff] (base 0xe0000000) [ 0.229315] PCI: MMCONFIG at [mem 0xe0000000-0xefffffff] reserved in ACPI motherboard resources [ 0.300038] ACPI: No dock devices found. [ 0.300088] HEST: Table not found. [ 0.300137] PCI: Using host bridge windows from ACPI; if necessary, use "pci=nocrs" and report a bug [ 0.300293] ACPI: PCI Root Bridge [PCI0] (domain 0000 [bus 00-ff]) [ 0.300373] pci_root PNP0A08:00: host bridge window [io 0x0000-0x0cf7] [ 0.300373] pci_root PNP0A08:00: host bridge window [io 0x0d00-0xffff] [ 0.300373] pci_root PNP0A08:00: host bridge window [mem 0x000a0000-0x000bffff] [ 0.300373] pci_root PNP0A08:00: host bridge window [mem 0x000d0000-0x000dffff] [ 0.300373] pci_root PNP0A08:00: host bridge window [mem 0xc0000000-0xdfffffff] [ 0.300967] pci_root PNP0A08:00: host bridge window [mem 0xf0000000-0xfed8ffff] [ 0.301051] pci 0000:00:00.0: [8086:3405] type 0 class 0x000600 [ 0.301118] pci 0000:00:00.0: PME# supported from D0 D3hot D3cold [ 0.301122] pci 0000:00:00.0: PME# disabled [ 0.301152] pci 0000:00:01.0: [8086:3408] type 1 class 0x000604 [ 0.301218] pci 0000:00:01.0: PME# supported from D0 D3hot D3cold [ 0.301222] pci 0000:00:01.0: PME# disabled [ 0.301252] pci 0000:00:03.0: [8086:340a] type 1 class 0x000604 [ 0.301318] pci 0000:00:03.0: PME# supported from D0 D3hot D3cold [ 0.301321] pci 0000:00:03.0: PME# disabled [ 0.301354] pci 0000:00:07.0: [8086:340e] type 1 class 0x000604 [ 0.301420] pci 0000:00:07.0: PME# supported from D0 D3hot D3cold [ 0.301423] pci 0000:00:07.0: PME# disabled [ 0.301461] pci 0000:00:14.0: [8086:342e] type 0 class 0x000800 [ 0.301549] pci 0000:00:14.1: [8086:3422] type 0 class 0x000800 [ 0.301637] pci 0000:00:14.2: [8086:3423] type 0 class 0x000800 [ 0.301721] pci 0000:00:14.3: [8086:3438] type 0 class 0x000800 [ 0.301809] pci 0000:00:1a.0: [8086:3a37] type 0 class 0x000c03 [ 0.301869] pci 0000:00:1a.0: reg 20: [io 0xb800-0xb81f] [ 0.301928] pci 0000:00:1a.1: [8086:3a38] type 0 class 0x000c03 [ 0.301963] pci 0000:00:1a.1: reg 20: [io 0xb880-0xb89f] [ 0.301963] pci 0000:00:1a.2: [8086:3a39] type 0 class 0x000c03 [ 0.302018] pci 0000:00:1a.2: reg 20: [io 0xbc00-0xbc1f] [ 0.302091] pci 0000:00:1a.7: [8086:3a3c] type 0 class 0x000c03 [ 0.302118] pci 0000:00:1a.7: reg 10: [mem 0xf7eff000-0xf7eff3ff] [ 0.302217] pci 0000:00:1a.7: PME# supported from D0 D3hot D3cold [ 0.302222] pci 0000:00:1a.7: PME# disabled [ 0.302251] pci 0000:00:1b.0: [8086:3a3e] type 0 class 0x000403 [ 0.302271] pci 0000:00:1b.0: reg 10: [mem 0xf7ef8000-0xf7efbfff 64bit] [ 0.302348] pci 0000:00:1b.0: PME# supported from D0 D3hot D3cold [ 0.302352] pci 0000:00:1b.0: PME# disabled [ 0.302377] pci 0000:00:1c.0: [8086:3a40] type 1 class 0x000604 [ 0.302455] pci 0000:00:1c.0: PME# supported from D0 D3hot D3cold [ 0.302459] pci 0000:00:1c.0: PME# disabled [ 0.302486] pci 0000:00:1c.1: [8086:3a42] type 1 class 0x000604 [ 0.302563] pci 0000:00:1c.1: PME# supported from D0 D3hot D3cold [ 0.302567] pci 0000:00:1c.1: PME# disabled [ 0.302603] pci 0000:00:1d.0: [8086:3a34] type 0 class 0x000c03 [ 0.302663] pci 0000:00:1d.0: reg 20: [io 0xb080-0xb09f] [ 0.302721] pci 0000:00:1d.1: [8086:3a35] type 0 class 0x000c03 [ 0.302780] pci 0000:00:1d.1: reg 20: [io 0xb400-0xb41f] [ 0.302840] pci 0000:00:1d.2: [8086:3a36] type 0 class 0x000c03 [ 0.302899] pci 0000:00:1d.2: reg 20: [io 0xb480-0xb49f] [ 0.302963] pci 0000:00:1d.7: [8086:3a3a] type 0 class 0x000c03 [ 0.302963] pci 0000:00:1d.7: reg 10: [mem 0xf7efe000-0xf7efe3ff] [ 0.303010] pci 0000:00:1d.7: PME# supported from D0 D3hot D3cold [ 0.303015] pci 0000:00:1d.7: PME# disabled [ 0.303040] pci 0000:00:1e.0: [8086:244e] type 1 class 0x000604 [ 0.303119] pci 0000:00:1f.0: [8086:3a16] type 0 class 0x000601 [ 0.303224] pci 0000:00:1f.0: ICH7 LPC Generic IO decode 1 PIO at 0294 (mask 0003) [ 0.303297] pci 0000:00:1f.0: ICH7 LPC Generic IO decode 3 PIO at 4700 (mask 001f) [ 0.303415] pci 0000:00:1f.2: [8086:3a22] type 0 class 0x000106 [ 0.303441] pci 0000:00:1f.2: reg 10: [io 0xac00-0xac07] [ 0.303452] pci 0000:00:1f.2: reg 14: [io 0xa880-0xa883] [ 0.303462] pci 0000:00:1f.2: reg 18: [io 0xa800-0xa807] [ 0.303472] pci 0000:00:1f.2: reg 1c: [io 0xa480-0xa483] [ 0.303483] pci 0000:00:1f.2: reg 20: [io 0xa400-0xa41f] [ 0.303493] pci 0000:00:1f.2: reg 24: [mem 0xf7efc000-0xf7efc7ff] [ 0.303540] pci 0000:00:1f.2: PME# supported from D3hot [ 0.303544] pci 0000:00:1f.2: PME# disabled [ 0.303565] pci 0000:00:1f.3: [8086:3a30] type 0 class 0x000c05 [ 0.303586] pci 0000:00:1f.3: reg 10: [mem 0xf7efd000-0xf7efd0ff 64bit] [ 0.303615] pci 0000:00:1f.3: reg 20: [io 0x0400-0x041f] [ 0.303711] pci 0000:01:00.0: [1033:0125] type 1 class 0x000604 [ 0.303794] pci 0000:01:00.0: supports D1 [ 0.303795] pci 0000:01:00.0: PME# supported from D0 D1 D3hot D3cold [ 0.303800] pci 0000:01:00.0: PME# disabled [ 0.303831] pci 0000:01:00.1: [1033:0125] type 1 class 0x000604 [ 0.303856] pci 0000:01:00.1: reg 10: [mem 0xf7fffc00-0xf7fffc7f 64bit] [ 0.303919] pci 0000:01:00.1: supports D1 [ 0.303920] pci 0000:01:00.1: PME# supported from D0 D1 D3hot D3cold [ 0.303925] pci 0000:01:00.1: PME# disabled [ 0.303960] pci 0000:01:00.0: disabling ASPM on pre-1.1 PCIe device. You can enable it with 'pcie_aspm=force' [ 0.303963] pci 0000:00:01.0: PCI bridge to [bus 01-03] [ 0.303969] pci 0000:00:01.0: bridge window [io 0xf000-0x0000] (disabled) [ 0.303972] pci 0000:00:01.0: bridge window [mem 0xf7f00000-0xf7ffffff] [ 0.303979] pci 0000:00:01.0: bridge window [mem 0xcff00000-0xcfffffff 64bit pref] [ 0.304081] pci 0000:01:00.0: PCI bridge to [bus 03-03] [ 0.304139] pci 0000:01:00.0: bridge window [io 0xf000-0x0000] (disabled) [ 0.304144] pci 0000:01:00.0: bridge window [mem 0xfff00000-0x000fffff] (disabled) [ 0.304153] pci 0000:01:00.0: bridge window [mem 0xfff00000-0x000fffff pref] (disabled) [ 0.304269] pci 0000:01:00.1: PCI bridge to [bus 02-02] [ 0.304327] pci 0000:01:00.1: bridge window [io 0xf000-0x0000] (disabled) [ 0.304332] pci 0000:01:00.1: bridge window [mem 0xfff00000-0x000fffff] (disabled) [ 0.304340] pci 0000:01:00.1: bridge window [mem 0xcff00000-0xcfffffff 64bit pref] [ 0.304423] pci 0000:04:00.0: [10de:05e3] type 0 class 0x000300 [ 0.304436] pci 0000:04:00.0: reg 10: [mem 0xfa000000-0xfaffffff] [ 0.304451] pci 0000:04:00.0: reg 14: [mem 0xd0000000-0xdfffffff 64bit pref] [ 0.304466] pci 0000:04:00.0: reg 1c: [mem 0xf8000000-0xf9ffffff 64bit] [ 0.304477] pci 0000:04:00.0: reg 24: [io 0xcc00-0xcc7f] [ 0.304487] pci 0000:04:00.0: reg 30: [mem 0xfbb80000-0xfbbfffff pref] [ 0.305986] pci 0000:00:03.0: PCI bridge to [bus 04-04] [ 0.306057] pci 0000:00:03.0: bridge window [io 0xc000-0xcfff] [ 0.306061] pci 0000:00:03.0: bridge window [mem 0xf8000000-0xfbbfffff] [ 0.306067] pci 0000:00:03.0: bridge window [mem 0xd0000000-0xdfffffff 64bit pref] [ 0.306138] pci 0000:05:00.0: [12d8:e130] type 1 class 0x000604 [ 0.306212] pci 0000:05:00.0: PME# supported from D0 D3hot D3cold [ 0.306217] pci 0000:05:00.0: PME# disabled [ 0.307984] pci 0000:00:07.0: PCI bridge to [bus 05-06] [ 0.308050] pci 0000:00:07.0: bridge window [io 0xd000-0xdfff] [ 0.308054] pci 0000:00:07.0: bridge window [mem 0xfbc00000-0xfbcfffff] [ 0.308060] pci 0000:00:07.0: bridge window [mem 0xfff00000-0x000fffff pref] (disabled) [ 0.308124] pci 0000:06:00.0: [1095:3124] type 0 class 0x000104 [ 0.308155] pci 0000:06:00.0: reg 10: [mem 0xfbcffc00-0xfbcffc7f 64bit] [ 0.308174] pci 0000:06:00.0: reg 18: [mem 0xfbcf0000-0xfbcf7fff 64bit] [ 0.308186] pci 0000:06:00.0: reg 20: [io 0xdc00-0xdc0f] [ 0.308209] pci 0000:06:00.0: reg 30: [mem 0xfbc00000-0xfbc7ffff pref] [ 0.308241] pci 0000:06:00.0: supports D1 D2 [ 0.308302] pci 0000:05:00.0: PCI bridge to [bus 06-06] [ 0.308359] pci 0000:05:00.0: bridge window [io 0xd000-0xdfff] [ 0.308363] pci 0000:05:00.0: bridge window [mem 0xfbc00000-0xfbcfffff] [ 0.308370] pci 0000:05:00.0: bridge window [mem 0xfff00000-0x000fffff pref] (disabled) [ 0.308433] pci 0000:00:1c.0: PCI bridge to [bus 08-08] [ 0.308487] pci 0000:00:1c.0: bridge window [io 0xf000-0x0000] (disabled) [ 0.308491] pci 0000:00:1c.0: bridge window [mem 0xfff00000-0x000fffff] (disabled) [ 0.308498] pci 0000:00:1c.0: bridge window [mem 0xf6f00000-0xf6ffffff 64bit pref] [ 0.308574] pci 0000:07:00.0: [10ec:8168] type 0 class 0x000200 [ 0.308594] pci 0000:07:00.0: reg 10: [io 0xe800-0xe8ff] [ 0.308629] pci 0000:07:00.0: reg 18: [mem 0xfbdff000-0xfbdfffff 64bit] [ 0.308651] pci 0000:07:00.0: reg 20: [mem 0xf6ef0000-0xf6efffff 64bit pref] [ 0.308666] pci 0000:07:00.0: reg 30: [mem 0xfbdc0000-0xfbddffff pref] [ 0.308715] pci 0000:07:00.0: supports D1 D2 [ 0.308716] pci 0000:07:00.0: PME# supported from D0 D1 D2 D3hot D3cold [ 0.308721] pci 0000:07:00.0: PME# disabled [ 0.309991] pci 0000:00:1c.1: PCI bridge to [bus 07-07] [ 0.310056] pci 0000:00:1c.1: bridge window [io 0xe000-0xefff] [ 0.310060] pci 0000:00:1c.1: bridge window [mem 0xfbd00000-0xfbdfffff] [ 0.310067] pci 0000:00:1c.1: bridge window [mem 0xf6e00000-0xf6efffff 64bit pref] [ 0.310117] pci 0000:09:04.0: [11c1:5811] type 0 class 0x000c00 [ 0.310139] pci 0000:09:04.0: reg 10: [mem 0xfbeff000-0xfbefffff] [ 0.310227] pci 0000:09:04.0: supports D1 D2 [ 0.310228] pci 0000:09:04.0: PME# supported from D0 D1 D2 D3hot [ 0.310233] pci 0000:09:04.0: PME# disabled [ 0.310284] pci 0000:00:1e.0: PCI bridge to [bus 09-09] (subtractive decode) [ 0.310341] pci 0000:00:1e.0: bridge window [io 0xf000-0x0000] (disabled) [ 0.310345] pci 0000:00:1e.0: bridge window [mem 0xfbe00000-0xfbefffff] [ 0.310352] pci 0000:00:1e.0: bridge window [mem 0xfff00000-0x000fffff pref] (disabled) [ 0.310354] pci 0000:00:1e.0: bridge window [io 0x0000-0x0cf7] (subtractive decode) [ 0.310356] pci 0000:00:1e.0: bridge window [io 0x0d00-0xffff] (subtractive decode) [ 0.310358] pci 0000:00:1e.0: bridge window [mem 0x000a0000-0x000bffff] (subtractive decode) [ 0.310360] pci 0000:00:1e.0: bridge window [mem 0x000d0000-0x000dffff] (subtractive decode) [ 0.310361] pci 0000:00:1e.0: bridge window [mem 0xc0000000-0xdfffffff] (subtractive decode) [ 0.310363] pci 0000:00:1e.0: bridge window [mem 0xf0000000-0xfed8ffff] (subtractive decode) [ 0.310396] pci_bus 0000:00: on NUMA node 0 [ 0.310399] ACPI: PCI Interrupt Routing Table [\_SB_.PCI0._PRT] [ 0.310582] ACPI: PCI Interrupt Routing Table [\_SB_.PCI0.P0P1._PRT] [ 0.310628] ACPI: PCI Interrupt Routing Table [\_SB_.PCI0.P0P4._PRT] [ 0.310651] ACPI: PCI Interrupt Routing Table [\_SB_.PCI0.P0P5._PRT] [ 0.310677] ACPI: PCI Interrupt Routing Table [\_SB_.PCI0.NPE1._PRT] [ 0.310699] ACPI: PCI Interrupt Routing Table [\_SB_.PCI0.NPE1.PXHA._PRT] [ 0.310736] ACPI: PCI Interrupt Routing Table [\_SB_.PCI0.NPE3._PRT] [ 0.310758] ACPI: PCI Interrupt Routing Table [\_SB_.PCI0.NPE7._PRT] [ 0.310781] pci0000:00: Requesting ACPI _OSC control (0x1d) [ 0.319000] ACPI: PCI Interrupt Link [LNKA] (IRQs 3 4 6 7 *10 11 12 14 15) [ 0.319394] ACPI: PCI Interrupt Link [LNKB] (IRQs *5) [ 0.319562] ACPI: PCI Interrupt Link [LNKC] (IRQs 3 4 6 7 10 11 12 14 *15) [ 0.320129] ACPI: PCI Interrupt Link [LNKD] (IRQs 3 4 6 7 10 *11 12 14 15) [ 0.320520] ACPI: PCI Interrupt Link [LNKE] (IRQs 3 4 6 7 10 11 12 14 15) *0, disabled. [ 0.320960] ACPI: PCI Interrupt Link [LNKF] (IRQs 3 4 6 7 10 11 12 *14 15) [ 0.321269] ACPI: PCI Interrupt Link [LNKG] (IRQs *3 4 6 7 10 11 12 14 15) [ 0.321661] ACPI: PCI Interrupt Link [LNKH] (IRQs 3 4 6 7 *10 11 12 14 15) [ 0.321973] pci 0000:00:1a.0: GSI16: level-low [ 0.322028] pci 0000:00:1a.1: GSI21: level-low [ 0.322079] pci 0000:00:1a.2: GSI19: level-low [ 0.322129] pci 0000:00:1a.7: GSI18: level-low [ 0.322180] pci 0000:00:1b.0: GSI22: level-low [ 0.322231] pci 0000:00:1c.0: GSI17: level-low [ 0.322282] pci 0000:00:1d.0: GSI23: level-low [ 0.322337] pci 0000:01:00.1: GSI28: level-low [ 0.322389] pci 0000:04:00.0: GSI24: level-low [ 0.322441] pci 0000:05:00.0: GSI30: level-low [ 0.322507] vgaarb: device added: PCI:0000:04:00.0,decodes=io+mem,owns=io+mem,locks=none [ 0.322507] vgaarb: loaded [ 0.322507] xen_mem: Initialising balloon driver. [ 0.323044] SCSI subsystem initialized [ 0.323044] libata version 3.00 loaded. [ 0.323044] usbcore: registered new interface driver usbfs [ 0.323044] usbcore: registered new interface driver hub [ 0.323044] usbcore: registered new device driver usb [ 0.323044] Advanced Linux Sound Architecture Driver Version 1.0.23. [ 0.323044] PCI: Using ACPI for IRQ routing [ 0.323075] PCI: pci_cache_line_size set to 64 bytes [ 0.323188] reserve RAM buffer: 000000000009c000 - 000000000009ffff [ 0.323190] reserve RAM buffer: 00000000bf780000 - 00000000bfffffff [ 0.323988] cfg80211: Calling CRDA to update world regulatory domain [ 0.324163] Switching to clocksource xen [ 0.324468] Switched to NOHz mode on CPU #10 [ 0.324482] Switched to NOHz mode on CPU #2 [ 0.324484] Switched to NOHz mode on CPU #3 [ 0.324496] Switched to NOHz mode on CPU #6 [ 0.324498] Switched to NOHz mode on CPU #8 [ 0.324555] Switched to NOHz mode on CPU #7 [ 0.324558] Switched to NOHz mode on CPU #11 [ 0.324563] Switched to NOHz mode on CPU #9 [ 0.324568] Switched to NOHz mode on CPU #1 [ 0.324570] Switched to NOHz mode on CPU #4 [ 0.324691] Switched to NOHz mode on CPU #0 [ 0.324731] Switched to NOHz mode on CPU #5 [ 0.326718] pnp: PnP ACPI init [ 0.326774] ACPI: bus type pnp registered [ 0.326908] pnp 00:00: [bus 00-ff] [ 0.326910] pnp 00:00: [io 0x0cf8-0x0cff] [ 0.326912] pnp 00:00: [io 0x0000-0x0cf7 window] [ 0.326913] pnp 00:00: [io 0x0d00-0xffff window] [ 0.326914] pnp 00:00: [mem 0x000a0000-0x000bffff window] [ 0.326916] pnp 00:00: [mem 0x000d0000-0x000dffff window] [ 0.326917] pnp 00:00: [mem 0xc0000000-0xdfffffff window] [ 0.326919] pnp 00:00: [mem 0xf0000000-0xfed8ffff window] [ 0.326970] pnp 00:00: Plug and Play ACPI device, IDs PNP0a08 PNP0a03 (active) [ 0.326979] pnp 00:01: [mem 0xfbf00000-0xfbffffff] [ 0.326980] pnp 00:01: [mem 0xfc000000-0xfcffffff] [ 0.326981] pnp 00:01: [mem 0xfd000000-0xfdffffff] [ 0.326983] pnp 00:01: [mem 0xfe000000-0xfebfffff] [ 0.326984] pnp 00:01: [mem 0xfec8a000-0xfec8afff] [ 0.326985] pnp 00:01: [mem 0xfed10000-0xfed10fff] [ 0.327038] system 00:01: [mem 0xfbf00000-0xfbffffff] has been reserved [ 0.327097] system 00:01: [mem 0xfc000000-0xfcffffff] has been reserved [ 0.327151] system 00:01: [mem 0xfd000000-0xfdffffff] has been reserved [ 0.327205] system 00:01: [mem 0xfe000000-0xfebfffff] has been reserved [ 0.327258] system 00:01: [mem 0xfec8a000-0xfec8afff] has been reserved [ 0.327312] system 00:01: [mem 0xfed10000-0xfed10fff] has been reserved [ 0.327367] system 00:01: Plug and Play ACPI device, IDs PNP0c01 (active) [ 0.327395] pnp 00:02: [dma 4] [ 0.327396] pnp 00:02: [io 0x0000-0x000f] [ 0.327397] pnp 00:02: [io 0x0081-0x0083] [ 0.327398] pnp 00:02: [io 0x0087] [ 0.327399] pnp 00:02: [io 0x0089-0x008b] [ 0.327401] pnp 00:02: [io 0x008f] [ 0.327402] pnp 00:02: [io 0x00c0-0x00df] [ 0.327443] pnp 00:02: Plug and Play ACPI device, IDs PNP0200 (active) [ 0.327451] pnp 00:03: [io 0x0070-0x0071] [ 0.327458] pnp 00:03: [irq 8] [ 0.327495] pnp 00:03: Plug and Play ACPI device, IDs PNP0b00 (active) [ 0.327502] pnp 00:04: [io 0x0061] [ 0.327539] pnp 00:04: Plug and Play ACPI device, IDs PNP0800 (active) [ 0.327546] pnp 00:05: [io 0x00f0-0x00ff] [ 0.327551] pnp 00:05: [irq 13] [ 0.327587] pnp 00:05: Plug and Play ACPI device, IDs PNP0c04 (active) [ 0.327654] pnp 00:06: [io 0x0000-0xffffffffffffffff disabled] [ 0.327655] pnp 00:06: [io 0x0000-0xffffffffffffffff disabled] [ 0.327657] pnp 00:06: [io 0x0290-0x029f] [ 0.327712] system 00:06: [io 0x0290-0x029f] has been reserved [ 0.327766] system 00:06: Plug and Play ACPI device, IDs PNP0c02 (active) [ 0.327917] pnp 00:07: [io 0x0010-0x001f] [ 0.327919] pnp 00:07: [io 0x0022-0x003f] [ 0.327920] pnp 00:07: [io 0x0044-0x004d] [ 0.327921] pnp 00:07: [io 0x0050-0x005f] [ 0.327922] pnp 00:07: [io 0x0062-0x0063] [ 0.327924] pnp 00:07: [io 0x0065-0x006f] [ 0.327925] pnp 00:07: [io 0x0072-0x007f] [ 0.327926] pnp 00:07: [io 0x0080] [ 0.327927] pnp 00:07: [io 0x0084-0x0086] [ 0.327928] pnp 00:07: [io 0x0088] [ 0.327930] pnp 00:07: [io 0x008c-0x008e] [ 0.327931] pnp 00:07: [io 0x0090-0x009f] [ 0.327932] pnp 00:07: [io 0x00a2-0x00bf] [ 0.327933] pnp 00:07: [io 0x00e0-0x00ef] [ 0.327935] pnp 00:07: [io 0x04d0-0x04d1] [ 0.327936] pnp 00:07: [io 0x0800-0x087f] [ 0.327937] pnp 00:07: [io 0x0400-0x03ff disabled] [ 0.327938] pnp 00:07: [io 0x0500-0x057f] [ 0.327940] pnp 00:07: [mem 0xfed1c000-0xfed1ffff] [ 0.327941] pnp 00:07: [mem 0xfed20000-0xfed3ffff] [ 0.327942] pnp 00:07: [mem 0xfed40000-0xfed8ffff] [ 0.328011] system 00:07: [io 0x04d0-0x04d1] has been reserved [ 0.328068] system 00:07: [io 0x0800-0x087f] has been reserved [ 0.328121] system 00:07: [io 0x0500-0x057f] has been reserved [ 0.328174] system 00:07: [mem 0xfed1c000-0xfed1ffff] has been reserved [ 0.328228] system 00:07: [mem 0xfed20000-0xfed3ffff] has been reserved [ 0.328281] system 00:07: [mem 0xfed40000-0xfed8ffff] has been reserved [ 0.328335] system 00:07: Plug and Play ACPI device, IDs PNP0c02 (active) [ 0.328390] pnp 00:08: [mem 0xfed00000-0xfed003ff] [ 0.328433] pnp 00:08: Plug and Play ACPI device, IDs PNP0103 (active) [ 0.328480] pnp 00:09: [mem 0xffa00000-0xffbfffff] [ 0.328482] pnp 00:09: [mem 0xffe00000-0xffffffff] [ 0.328521] pnp 00:09: Plug and Play ACPI device, IDs INT0800 (active) [ 0.328565] pnp 00:0a: [mem 0xffc00000-0xffdfffff] [ 0.328620] system 00:0a: [mem 0xffc00000-0xffdfffff] has been reserved [ 0.328676] system 00:0a: Plug and Play ACPI device, IDs PNP0c02 (active) [ 0.328759] pnp 00:0b: [io 0x0060] [ 0.328760] pnp 00:0b: [io 0x0064] [ 0.328762] pnp 00:0b: [mem 0xfec00000-0xfec00fff] [ 0.328763] pnp 00:0b: [mem 0xfee00000-0xfee00fff] [ 0.328819] system 00:0b: [mem 0xfec00000-0xfec00fff] has been reserved [ 0.328875] system 00:0b: [mem 0xfee00000-0xfee00fff] has been reserved [ 0.328929] system 00:0b: Plug and Play ACPI device, IDs PNP0c02 (active) [ 0.328994] pnp 00:0c: [mem 0xe0000000-0xefffffff] [ 0.329051] system 00:0c: [mem 0xe0000000-0xefffffff] has been reserved [ 0.329109] system 00:0c: Plug and Play ACPI device, IDs PNP0c02 (active) [ 0.329247] pnp 00:0d: [mem 0x00000000-0x0009ffff] [ 0.329249] pnp 00:0d: [mem 0x000c0000-0x000cffff] [ 0.329250] pnp 00:0d: [mem 0x000e0000-0x000fffff] [ 0.329252] pnp 00:0d: [mem 0x00100000-0xbfffffff] [ 0.329253] pnp 00:0d: [mem 0xfed90000-0xffffffff] [ 0.329316] system 00:0d: [mem 0x00000000-0x0009ffff] could not be reserved [ 0.329372] system 00:0d: [mem 0x000c0000-0x000cffff] has been reserved [ 0.329426] system 00:0d: [mem 0x000e0000-0x000fffff] could not be reserved [ 0.329480] system 00:0d: [mem 0x00100000-0xbfffffff] could not be reserved [ 0.329534] system 00:0d: [mem 0xfed90000-0xffffffff] could not be reserved [ 0.329589] system 00:0d: Plug and Play ACPI device, IDs PNP0c01 (active) [ 0.329692] pnp: PnP ACPI: found 14 devices [ 0.329742] ACPI: ACPI bus type pnp unregistered [ 0.330048] pci 0000:00:1c.0: BAR 14: can't assign mem (size 0x400000) [ 0.330109] pci 0000:00:1c.0: BAR 13: assigned [io 0x1000-0x1fff] [ 0.330162] pci 0000:01:00.0: PCI bridge to [bus 03-03] [ 0.330213] pci 0000:01:00.0: bridge window [io disabled] [ 0.330270] pci 0000:01:00.0: bridge window [mem disabled] [ 0.330326] pci 0000:01:00.0: bridge window [mem pref disabled] [ 0.330385] pci 0000:01:00.1: PCI bridge to [bus 02-02] [ 0.330436] pci 0000:01:00.1: bridge window [io disabled] [ 0.330493] pci 0000:01:00.1: bridge window [mem disabled] [ 0.330548] pci 0000:01:00.1: bridge window [mem 0xcff00000-0xcfffffff 64bit pref] [ 0.330625] pci 0000:00:01.0: PCI bridge to [bus 01-03] [ 0.330675] pci 0000:00:01.0: bridge window [io disabled] [ 0.330731] pci 0000:00:01.0: bridge window [mem 0xf7f00000-0xf7ffffff] [ 0.330787] pci 0000:00:01.0: bridge window [mem 0xcff00000-0xcfffffff 64bit pref] [ 0.335625] pci 0000:00:03.0: PCI bridge to [bus 04-04] [ 0.335678] pci 0000:00:03.0: bridge window [io 0xc000-0xcfff] [ 0.335734] pci 0000:00:03.0: bridge window [mem 0xf8000000-0xfbbfffff] [ 0.335790] pci 0000:00:03.0: bridge window [mem 0xd0000000-0xdfffffff 64bit pref] [ 0.335864] pci 0000:05:00.0: PCI bridge to [bus 06-06] [ 0.335916] pci 0000:05:00.0: bridge window [io 0xd000-0xdfff] [ 0.335973] pci 0000:05:00.0: bridge window [mem 0xfbc00000-0xfbcfffff] [ 0.336029] pci 0000:05:00.0: bridge window [mem pref disabled] [ 0.336089] pci 0000:00:07.0: PCI bridge to [bus 05-06] [ 0.336142] pci 0000:00:07.0: bridge window [io 0xd000-0xdfff] [ 0.336198] pci 0000:00:07.0: bridge window [mem 0xfbc00000-0xfbcfffff] [ 0.336253] pci 0000:00:07.0: bridge window [mem pref disabled] [ 0.336310] pci 0000:00:1c.0: PCI bridge to [bus 08-08] [ 0.336363] pci 0000:00:1c.0: bridge window [io 0x1000-0x1fff] [ 0.336419] pci 0000:00:1c.0: bridge window [mem disabled] [ 0.336473] pci 0000:00:1c.0: bridge window [mem 0xf6f00000-0xf6ffffff 64bit pref] [ 0.336548] pci 0000:00:1c.1: PCI bridge to [bus 07-07] [ 0.336600] pci 0000:00:1c.1: bridge window [io 0xe000-0xefff] [ 0.336656] pci 0000:00:1c.1: bridge window [mem 0xfbd00000-0xfbdfffff] [ 0.336712] pci 0000:00:1c.1: bridge window [mem 0xf6e00000-0xf6efffff 64bit pref] [ 0.336787] pci 0000:00:1e.0: PCI bridge to [bus 09-09] [ 0.336838] pci 0000:00:1e.0: bridge window [io disabled] [ 0.336893] pci 0000:00:1e.0: bridge window [mem 0xfbe00000-0xfbefffff] [ 0.336949] pci 0000:00:1e.0: bridge window [mem pref disabled] [ 0.337014] pci 0000:00:01.0: setting latency timer to 64 [ 0.337023] pci 0000:01:00.0: setting latency timer to 64 [ 0.337036] pci 0000:01:00.1: PCI INT A -> GSI 28 (level, low) -> IRQ 28 [ 0.337098] pci 0000:01:00.1: setting latency timer to 64 [ 0.337106] pci 0000:00:03.0: setting latency timer to 64 [ 0.337113] pci 0000:00:07.0: setting latency timer to 64 [ 0.337122] pci 0000:05:00.0: PCI INT A -> GSI 30 (level, low) -> IRQ 30 [ 0.337179] pci 0000:05:00.0: setting latency timer to 64 [ 0.337185] pci 0000:00:1c.0: enabling device (0106 -> 0107) [ 0.337241] pci 0000:00:1c.0: PCI INT A -> GSI 17 (level, low) -> IRQ 17 [ 0.337297] pci 0000:00:1c.0: setting latency timer to 64 [ 0.337305] pci 0000:00:1c.1: PCI INT B -> GSI 16 (level, low) -> IRQ 16 [ 0.337362] pci 0000:00:1c.1: setting latency timer to 64 [ 0.337369] pci 0000:00:1e.0: setting latency timer to 64 [ 0.337372] pci_bus 0000:00: resource 4 [io 0x0000-0x0cf7] [ 0.337374] pci_bus 0000:00: resource 5 [io 0x0d00-0xffff] [ 0.337375] pci_bus 0000:00: resource 6 [mem 0x000a0000-0x000bffff] [ 0.337376] pci_bus 0000:00: resource 7 [mem 0x000d0000-0x000dffff] [ 0.337378] pci_bus 0000:00: resource 8 [mem 0xc0000000-0xdfffffff] [ 0.337379] pci_bus 0000:00: resource 9 [mem 0xf0000000-0xfed8ffff] [ 0.337381] pci_bus 0000:01: resource 1 [mem 0xf7f00000-0xf7ffffff] [ 0.337382] pci_bus 0000:01: resource 2 [mem 0xcff00000-0xcfffffff 64bit pref] [ 0.337384] pci_bus 0000:02: resource 2 [mem 0xcff00000-0xcfffffff 64bit pref] [ 0.337386] pci_bus 0000:04: resource 0 [io 0xc000-0xcfff] [ 0.337387] pci_bus 0000:04: resource 1 [mem 0xf8000000-0xfbbfffff] [ 0.337388] pci_bus 0000:04: resource 2 [mem 0xd0000000-0xdfffffff 64bit pref] [ 0.337390] pci_bus 0000:05: resource 0 [io 0xd000-0xdfff] [ 0.337391] pci_bus 0000:05: resource 1 [mem 0xfbc00000-0xfbcfffff] [ 0.337393] pci_bus 0000:06: resource 0 [io 0xd000-0xdfff] [ 0.337394] pci_bus 0000:06: resource 1 [mem 0xfbc00000-0xfbcfffff] [ 0.337396] pci_bus 0000:08: resource 0 [io 0x1000-0x1fff] [ 0.337397] pci_bus 0000:08: resource 2 [mem 0xf6f00000-0xf6ffffff 64bit pref] [ 0.337399] pci_bus 0000:07: resource 0 [io 0xe000-0xefff] [ 0.337400] pci_bus 0000:07: resource 1 [mem 0xfbd00000-0xfbdfffff] [ 0.337402] pci_bus 0000:07: resource 2 [mem 0xf6e00000-0xf6efffff 64bit pref] [ 0.337403] pci_bus 0000:09: resource 1 [mem 0xfbe00000-0xfbefffff] [ 0.337405] pci_bus 0000:09: resource 4 [io 0x0000-0x0cf7] [ 0.337406] pci_bus 0000:09: resource 5 [io 0x0d00-0xffff] [ 0.337408] pci_bus 0000:09: resource 6 [mem 0x000a0000-0x000bffff] [ 0.337409] pci_bus 0000:09: resource 7 [mem 0x000d0000-0x000dffff] [ 0.337411] pci_bus 0000:09: resource 8 [mem 0xc0000000-0xdfffffff] [ 0.337412] pci_bus 0000:09: resource 9 [mem 0xf0000000-0xfed8ffff] [ 0.337426] NET: Registered protocol family 2 [ 0.337502] IP route cache hash table entries: 524288 (order: 10, 4194304 bytes) [ 0.337998] TCP established hash table entries: 262144 (order: 10, 4194304 bytes) [ 0.338561] TCP bind hash table entries: 65536 (order: 8, 1048576 bytes) [ 0.338733] TCP: Hash tables configured (established 262144 bind 65536) [ 0.338787] TCP reno registered [ 0.338836] UDP hash table entries: 8192 (order: 6, 262144 bytes) [ 0.338923] UDP-Lite hash table entries: 8192 (order: 6, 262144 bytes) [ 0.339086] NET: Registered protocol family 1 [ 0.339194] RPC: Registered udp transport module. [ 0.339245] RPC: Registered tcp transport module. [ 0.339295] RPC: Registered tcp NFSv4.1 backchannel transport module. [ 0.339418] pci 0000:00:1a.0: uhci_check_and_reset_hc: legsup = 0x0f30 [ 0.339419] pci 0000:00:1a.0: Performing full reset [ 0.339444] pci 0000:00:1a.1: uhci_check_and_reset_hc: legsup = 0x0030 [ 0.339445] pci 0000:00:1a.1: Performing full reset [ 0.339469] pci 0000:00:1a.2: uhci_check_and_reset_hc: legsup = 0x0030 [ 0.339470] pci 0000:00:1a.2: Performing full reset [ 0.339567] pci 0000:00:1d.0: uhci_check_and_reset_hc: legsup = 0x0f30 [ 0.339569] pci 0000:00:1d.0: Performing full reset [ 0.339592] pci 0000:00:1d.1: uhci_check_and_reset_hc: legsup = 0x0030 [ 0.339594] pci 0000:00:1d.1: Performing full reset [ 0.339617] pci 0000:00:1d.2: uhci_check_and_reset_hc: legsup = 0x0030 [ 0.339618] pci 0000:00:1d.2: Performing full reset [ 0.339734] pci 0000:04:00.0: Boot video device [ 0.339790] PCI: CLS 256 bytes, default 64 [ 0.339812] Trying to unpack rootfs image as initramfs... [ 0.342042] Freeing initrd memory: 4392k freed [ 0.344455] MCE: bind virq for DOM0 logging [ 0.344477] MCE_DOM0_LOG: enter dom0 mce vIRQ handler [ 0.344478] MCE_DOM0_LOG: No more urgent data [ 0.344479] MCE_DOM0_LOG: No more nonurgent data [ 60.895135] microcode: Microcode Update Driver: v2.00-xen , Peter Oruba [ 60.898615] ROMFS MTD (C) 2007 Red Hat, Inc. [ 60.898737] SGI XFS with ACLs, security attributes, large block/inode numbers, no debug enabled [ 60.899208] SGI XFS Quota Management subsystem [ 60.899538] Btrfs loaded [ 60.899589] msgmni has been set to 24034 [ 60.900047] Block layer SCSI generic (bsg) driver version 0.4 loaded (major 253) [ 60.900121] io scheduler noop registered [ 60.900217] io scheduler cfq registered (default) [ 60.900488] pcieport 0000:00:1c.0: setting latency timer to 64 [ 60.900549] pcieport 0000:00:1c.0: irq 68 (303) for MSI/MSI-X [ 60.900641] pcieport 0000:00:1c.1: setting latency timer to 64 [ 60.900698] pcieport 0000:00:1c.1: irq 69 (302) for MSI/MSI-X [ 60.900860] pci_hotplug: PCI Hot Plug PCI Core version: 0.5 [ 60.900986] pciehp: PCI Express Hot Plug Controller Driver version: 0.4 [ 60.901125] Non-volatile memory driver v1.3 [ 60.901458] input: Power Button as /devices/LNXSYSTM:00/device:00/PNP0C0C:00/input/input0 [ 60.901530] ACPI: Power Button [PWRB] [ 60.901629] input: Power Button as /devices/LNXSYSTM:00/LNXPWRBN:00/input/input1 [ 60.901700] ACPI: Power Button [PWRF] [ 60.959334] ERST: Table is not found! [ 60.960792] brd: module loaded [ 60.961519] loop: module loaded [ 60.961734] Xen virtual console successfully installed as xvc0 [ 60.961829] Event-channel device installed. [ 60.963568] ahci 0000:00:1f.2: version 3.0 [ 60.963585] ahci 0000:00:1f.2: PCI INT B -> GSI 19 (level, low) -> IRQ 19 [ 60.963694] ahci 0000:00:1f.2: irq 71 (301) for MSI/MSI-X [ 60.963717] ahci: SSS flag set, parallel bus scan disabled [ 60.963803] ahci 0000:00:1f.2: AHCI 0001.0200 32 slots 6 ports 3 Gbps 0x3f impl SATA mode [ 60.963874] ahci 0000:00:1f.2: flags: 64bit ncq sntf stag pm led clo pmp pio slum part ccc ems sxs [ 60.963949] ahci 0000:00:1f.2: setting latency timer to 64 [ 60.974812] scsi0 : ahci [ 60.974956] scsi1 : ahci [ 60.975087] scsi2 : ahci [ 60.975213] scsi3 : ahci [ 60.975340] scsi4 : ahci [ 60.975467] scsi5 : ahci [ 60.975634] ata1: SATA max UDMA/133 abar m2048@0xf7efc000 port 0xf7efc100 irq 71 [ 60.975704] ata2: SATA max UDMA/133 irq_stat 0x00400040, connection status changed irq 71 [ 60.975774] ata3: SATA max UDMA/133 irq_stat 0x00400040, connection status changed irq 71 [ 60.975845] ata4: SATA max UDMA/133 irq_stat 0x00400040, connection status changed irq 71 [ 60.975915] ata5: SATA max UDMA/133 irq_stat 0x00400040, connection status changed irq 71 [ 60.975985] ata6: SATA max UDMA/133 irq_stat 0x00400040, connection status changed irq 71 [ 60.976275] sata_sil24 0000:06:00.0: version 1.1 [ 60.976286] sata_sil24 0000:06:00.0: PCI INT A -> GSI 30 (level, low) -> IRQ 30 [ 60.976424] sata_sil24 0000:06:00.0: Applying completion IRQ loss on PCI-X errata fix [ 60.977505] scsi6 : sata_sil24 [ 60.977654] scsi7 : sata_sil24 [ 60.977801] scsi8 : sata_sil24 [ 60.977948] scsi9 : sata_sil24 [ 60.978089] ata7: SATA max UDMA/100 host m128@0xfbcffc00 port 0xfbcf0000 irq 30 [ 60.978159] ata8: SATA max UDMA/100 host m128@0xfbcffc00 port 0xfbcf2000 irq 30 [ 60.978228] ata9: SATA max UDMA/100 host m128@0xfbcffc00 port 0xfbcf4000 irq 30 [ 60.978298] ata10: SATA max UDMA/100 host m128@0xfbcffc00 port 0xfbcf6000 irq 30 [ 60.978491] r8169 Gigabit Ethernet driver 2.3LK-NAPI loaded [ 60.978555] r8169 0000:07:00.0: PCI INT A -> GSI 17 (level, low) -> IRQ 17 [ 60.978648] r8169 0000:07:00.0: setting latency timer to 64 [ 60.978723] r8169 0000:07:00.0: irq 72 (300) for MSI/MSI-X [ 60.978885] r8169 0000:07:00.0: eth0: RTL8168c/8111c at 0xffffc9000001e000, 00:24:8c:0a:ab:91, XID 1c4000c0 IRQ 72 [ 60.979005] ehci_hcd: USB 2.0 'Enhanced' Host Controller (EHCI) Driver [ 60.979067] ehci_hcd: block sizes: qh 104 qtd 96 itd 192 sitd 96 [ 60.979087] ehci_hcd 0000:00:1a.7: PCI INT C -> GSI 18 (level, low) -> IRQ 18 [ 60.979159] ehci_hcd 0000:00:1a.7: setting latency timer to 64 [ 60.979163] ehci_hcd 0000:00:1a.7: EHCI Host Controller [ 60.979217] ehci_hcd 0000:00:1a.7: new USB bus registered, assigned bus number 1 [ 60.979290] ehci_hcd 0000:00:1a.7: reset hcs_params 0x103206 dbg=1 cc=3 pcc=2 ordered !ppc ports=6 [ 60.979293] ehci_hcd 0000:00:1a.7: reset hcc_params 16871 thresh 7 uframes 1024 64 bit addr hw prefetch [ 60.979324] ehci_hcd 0000:00:1a.7: debug port 1 [ 60.979377] ehci_hcd 0000:00:1a.7: reset command 0080002 (park)=0 ithresh=8 period=1024 Reset HALT [ 60.983262] ehci_hcd 0000:00:1a.7: cache line size of 256 is not supported [ 60.983263] ehci_hcd 0000:00:1a.7: supports USB remote wakeup [ 60.983276] ehci_hcd 0000:00:1a.7: irq 18, io mem 0xf7eff000 [ 60.983330] ehci_hcd 0000:00:1a.7: reset command 0080002 (park)=0 ithresh=8 period=1024 Reset HALT [ 60.987224] ehci_hcd 0000:00:1a.7: init command 0010001 (park)=0 ithresh=1 period=1024 RUN [ 60.993077] ehci_hcd 0000:00:1a.7: USB 2.0 started, EHCI 1.00 [ 60.993198] usb usb1: default language 0x0409 [ 60.993204] usb usb1: udev 1, busnum 1, minor = 0 [ 60.993206] usb usb1: New USB device found, idVendor=1d6b, idProduct=0002 [ 60.993265] usb usb1: New USB device strings: Mfr=3, Product=2, SerialNumber=1 [ 60.993338] usb usb1: Product: EHCI Host Controller [ 60.993392] usb usb1: Manufacturer: Linux 2.6.38-xen-kali ehci_hcd [ 60.993449] usb usb1: SerialNumber: 0000:00:1a.7 [ 60.993614] usb usb1: usb_probe_device [ 60.993617] usb usb1: configuration #1 chosen from 1 choice [ 60.993624] usb usb1: adding 1-0:1.0 (config #1, interface 0) [ 60.993688] hub 1-0:1.0: usb_probe_interface [ 60.993690] hub 1-0:1.0: usb_probe_interface - got id [ 60.993692] hub 1-0:1.0: USB hub found [ 60.993749] hub 1-0:1.0: 6 ports detected [ 60.993802] hub 1-0:1.0: standalone hub [ 60.993804] hub 1-0:1.0: no power switching (usb 1.0) [ 60.993805] hub 1-0:1.0: individual port over-current protection [ 60.993807] hub 1-0:1.0: power on to power good time: 20ms [ 60.993810] hub 1-0:1.0: local power source is good [ 60.993812] hub 1-0:1.0: trying to enable port power on non-switchable hub [ 60.993866] ehci_hcd 0000:00:1d.7: PCI INT A -> GSI 23 (level, low) -> IRQ 23 [ 60.993993] ehci_hcd 0000:00:1d.7: setting latency timer to 64 [ 60.993997] ehci_hcd 0000:00:1d.7: EHCI Host Controller [ 60.994113] ehci_hcd 0000:00:1d.7: new USB bus registered, assigned bus number 2 [ 60.994192] ehci_hcd 0000:00:1d.7: reset hcs_params 0x103206 dbg=1 cc=3 pcc=2 ordered !ppc ports=6 [ 60.994198] ehci_hcd 0000:00:1d.7: reset hcc_params 16871 thresh 7 uframes 1024 64 bit addr hw prefetch [ 60.994293] ehci_hcd 0000:00:1d.7: debug port 1 [ 60.994350] ehci_hcd 0000:00:1d.7: reset command 0080002 (park)=0 ithresh=8 period=1024 Reset HALT [ 60.998241] ehci_hcd 0000:00:1d.7: cache line size of 256 is not supported [ 60.998243] ehci_hcd 0000:00:1d.7: supports USB remote wakeup [ 60.998259] ehci_hcd 0000:00:1d.7: irq 23, io mem 0xf7efe000 [ 60.998318] ehci_hcd 0000:00:1d.7: reset command 0080002 (park)=0 ithresh=8 period=1024 Reset HALT [ 61.002203] ehci_hcd 0000:00:1d.7: init command 0010001 (park)=0 ithresh=1 period=1024 RUN [ 61.008126] ehci_hcd 0000:00:1d.7: USB 2.0 started, EHCI 1.00 [ 61.008258] usb usb2: default language 0x0409 [ 61.008265] usb usb2: udev 1, busnum 2, minor = 128 [ 61.008268] usb usb2: New USB device found, idVendor=1d6b, idProduct=0002 [ 61.008331] usb usb2: New USB device strings: Mfr=3, Product=2, SerialNumber=1 [ 61.008409] usb usb2: Product: EHCI Host Controller [ 61.008468] usb usb2: Manufacturer: Linux 2.6.38-xen-kali ehci_hcd [ 61.008529] usb usb2: SerialNumber: 0000:00:1d.7 [ 61.008743] usb usb2: usb_probe_device [ 61.008748] usb usb2: configuration #1 chosen from 1 choice [ 61.008756] usb usb2: adding 2-0:1.0 (config #1, interface 0) [ 61.008845] hub 2-0:1.0: usb_probe_interface [ 61.008848] hub 2-0:1.0: usb_probe_interface - got id [ 61.008850] hub 2-0:1.0: USB hub found [ 61.008912] hub 2-0:1.0: 6 ports detected [ 61.008969] hub 2-0:1.0: standalone hub [ 61.008971] hub 2-0:1.0: no power switching (usb 1.0) [ 61.008973] hub 2-0:1.0: individual port over-current protection [ 61.008975] hub 2-0:1.0: power on to power good time: 20ms [ 61.008979] hub 2-0:1.0: local power source is good [ 61.008981] hub 2-0:1.0: trying to enable port power on non-switchable hub [ 61.009405] i8042: PNP: No PS/2 controller found. Probing ports directly. [ 61.012278] serio: i8042 KBD port at 0x60,0x64 irq 1 [ 61.012342] serio: i8042 AUX port at 0x60,0x64 irq 12 [ 61.012701] mousedev: PS/2 mouse device common for all mice [ 61.012862] rtc_cmos 00:03: RTC can wake from S4 [ 61.013014] rtc_cmos 00:03: rtc core: registered rtc_cmos as rtc0 [ 61.013120] rtc0: alarms up to one month, y3k, 114 bytes nvram [ 61.013242] i2c /dev entries driver [ 61.013406] md: raid0 personality registered for level 0 [ 61.013468] md: raid6 personality registered for level 6 [ 61.013528] md: raid5 personality registered for level 5 [ 61.013587] md: raid4 personality registered for level 4 [ 61.014470] usbcore: registered new interface driver usbhid [ 61.014532] usbhid: USB HID core driver [ 61.015208] ALSA device list: [ 61.015266] No soundcards found. [ 61.015330] IPv4 over IPv4 tunneling driver [ 61.015601] TCP cubic registered [ 61.015660] NET: Registered protocol family 17 [ 61.015731] Registering the dns_resolver key type [ 61.016694] PCI IO multiplexer device installed [ 61.017070] rtc_cmos 00:03: setting system clock to 2011-09-10 00:10:27 UTC (1315613427) [ 61.093133] ehci_hcd 0000:00:1a.7: GetStatus port:1 status 001803 0 ACK POWER sig=j CSC CONNECT [ 61.093140] hub 1-0:1.0: port 1: status 0501 change 0001 [ 61.093152] ehci_hcd 0000:00:1a.7: GetStatus port:3 status 001803 0 ACK POWER sig=j CSC CONNECT [ 61.093157] hub 1-0:1.0: port 3: status 0501 change 0001 [ 61.108139] ehci_hcd 0000:00:1d.7: GetStatus port:5 status 001403 0 ACK POWER sig=k CSC CONNECT [ 61.108145] hub 2-0:1.0: port 5: status 0501 change 0001 [ 61.108155] ehci_hcd 0000:00:1d.7: GetStatus port:6 status 001403 0 ACK POWER sig=k CSC CONNECT [ 61.108159] hub 2-0:1.0: port 6: status 0501 change 0001 [ 61.193221] hub 1-0:1.0: state 7 ports 6 chg 000a evt 0000 [ 61.193238] hub 1-0:1.0: port 1, status 0501, change 0000, 480 Mb/s [ 61.244381] ehci_hcd 0000:00:1a.7: port 1 high speed [ 61.244388] ehci_hcd 0000:00:1a.7: GetStatus port:1 status 001005 0 ACK POWER sig=se0 PE CONNECT [ 61.281135] ata1: SATA link down (SStatus 0 SControl 300) [ 61.295134] usb 1-1: new high speed USB device using ehci_hcd and address 2 [ 61.346377] ehci_hcd 0000:00:1a.7: port 1 high speed [ 61.346385] ehci_hcd 0000:00:1a.7: GetStatus port:1 status 001005 0 ACK POWER sig=se0 PE CONNECT [ 61.410289] usb 1-1: default language 0x0409 [ 61.411270] usb 1-1: udev 2, busnum 1, minor = 1 [ 61.411273] usb 1-1: New USB device found, idVendor=058f, idProduct=6362 [ 61.411344] usb 1-1: New USB device strings: Mfr=1, Product=2, SerialNumber=3 [ 61.411413] usb 1-1: Product: Mass Storage Device [ 61.411476] usb 1-1: Manufacturer: Generic [ 61.411538] usb 1-1: SerialNumber: 058F312D81B [ 61.416615] usb 1-1: usb_probe_device [ 61.416619] usb 1-1: configuration #1 chosen from 1 choice [ 61.416793] usb 1-1: adding 1-1:1.0 (config #1, interface 0) [ 61.416934] hub 1-0:1.0: port 3, status 0501, change 0000, 480 Mb/s [ 61.467376] ehci_hcd 0000:00:1a.7: port 3 high speed [ 61.467382] ehci_hcd 0000:00:1a.7: GetStatus port:3 status 001005 0 ACK POWER sig=se0 PE CONNECT [ 61.518094] usb 1-3: new high speed USB device using ehci_hcd and address 3 [ 61.571372] ehci_hcd 0000:00:1a.7: port 3 high speed [ 61.571379] ehci_hcd 0000:00:1a.7: GetStatus port:3 status 001005 0 ACK POWER sig=se0 PE CONNECT [ 61.645158] usb 1-3: default language 0x0409 [ 61.661285] usb 1-3: udev 3, busnum 1, minor = 2 [ 61.661289] usb 1-3: New USB device found, idVendor=148f, idProduct=3070 [ 61.661358] usb 1-3: New USB device strings: Mfr=1, Product=2, SerialNumber=3 [ 61.661426] usb 1-3: Product: 802.11 n WLAN [ 61.661489] usb 1-3: Manufacturer: Ralink [ 61.661699] usb 1-3: usb_probe_device [ 61.661703] usb 1-3: configuration #1 chosen from 1 choice [ 61.661766] usb 1-3: adding 1-3:1.0 (config #1, interface 0) [ 61.672832] hub 2-0:1.0: state 7 ports 6 chg 0060 evt 0000 [ 61.672839] hub 2-0:1.0: port 5, status 0501, change 0000, 480 Mb/s [ 61.672846] ehci_hcd 0000:00:1d.7: port 5 low speed --> companion [ 61.723098] ehci_hcd 0000:00:1d.7: GetStatus port:5 status 003002 0 ACK POWER OWNER sig=se0 CSC [ 61.723118] hub 2-0:1.0: port 6, status 0501, change 0000, 480 Mb/s [ 61.723126] ehci_hcd 0000:00:1d.7: port 6 low speed --> companion [ 61.774095] ehci_hcd 0000:00:1d.7: GetStatus port:6 status 003002 0 ACK POWER OWNER sig=se0 CSC [ 61.774113] hub 2-0:1.0: state 7 ports 6 chg 0000 evt 0040 [ 62.004101] ata2: SATA link up 3.0 Gbps (SStatus 123 SControl 300) [ 62.005311] ata2.00: ATA-8: WDC WD5000AAKX-001CA0, 15.01H15, max UDMA/133 [ 62.005381] ata2.00: 976773168 sectors, multi 16: LBA48 NCQ (depth 31/32), AA [ 62.007634] ata2.00: configured for UDMA/133 [ 62.007796] scsi 1:0:0:0: Direct-Access ATA WDC WD5000AAKX-0 15.0 PQ: 0 ANSI: 5 [ 62.008207] sd 1:0:0:0: [sda] 976773168 512-byte logical blocks: (500 GB/465 GiB) [ 62.008437] sd 1:0:0:0: [sda] Write Protect is off [ 62.008511] sd 1:0:0:0: [sda] Mode Sense: 00 3a 00 00 [ 62.008585] sd 1:0:0:0: [sda] Write cache: enabled, read cache: enabled, doesn't support DPO or FUA [ 62.019445] sda: sda1 sda2 sda3 sda4 [ 62.020528] sd 1:0:0:0: [sda] Attached SCSI disk [ 62.731135] ata3: SATA link up 3.0 Gbps (SStatus 123 SControl 300) [ 62.737446] ata3.00: ATA-8: SAMSUNG HD204UI, 1AQ10001, max UDMA/133 [ 62.737518] ata3.00: 3907029168 sectors, multi 16: LBA48 NCQ (depth 31/32), AA [ 62.743813] ata3.00: configured for UDMA/133 [ 62.744000] scsi 2:0:0:0: Direct-Access ATA SAMSUNG HD204UI 1AQ1 PQ: 0 ANSI: 5 [ 62.744709] sd 2:0:0:0: [sdb] 3907029168 512-byte logical blocks: (2.00 TB/1.81 TiB) [ 62.744924] sd 2:0:0:0: [sdb] Write Protect is off [ 62.745005] sd 2:0:0:0: [sdb] Mode Sense: 00 3a 00 00 [ 62.745039] sd 2:0:0:0: [sdb] Write cache: enabled, read cache: enabled, doesn't support DPO or FUA [ 62.758920] sdb: sdb1 [ 62.759720] sd 2:0:0:0: [sdb] Attached SCSI disk [ 63.110141] ata7: SATA link up 3.0 Gbps (SStatus 123 SControl 0) [ 63.118340] ata7.00: ATA-8: OCZ-REVODRIVE, 1.23, max UDMA/133 [ 63.118410] ata7.00: 78161328 sectors, multi 16: LBA48 NCQ (depth 31/32) [ 63.128303] ata7.00: configured for UDMA/100 [ 63.467136] ata4: SATA link up 3.0 Gbps (SStatus 123 SControl 300) [ 63.473457] ata4.00: ATA-8: SAMSUNG HD204UI, 1AQ10001, max UDMA/133 [ 63.473529] ata4.00: 3907029168 sectors, multi 16: LBA48 NCQ (depth 31/32), AA [ 63.479944] ata4.00: configured for UDMA/133 [ 63.480117] scsi 3:0:0:0: Direct-Access ATA SAMSUNG HD204UI 1AQ1 PQ: 0 ANSI: 5 [ 63.480912] sd 3:0:0:0: [sdc] 3907029168 512-byte logical blocks: (2.00 TB/1.81 TiB) [ 63.481150] sd 3:0:0:0: [sdc] Write Protect is off [ 63.481229] sd 3:0:0:0: [sdc] Mode Sense: 00 3a 00 00 [ 63.481264] sd 3:0:0:0: [sdc] Write cache: enabled, read cache: enabled, doesn't support DPO or FUA [ 63.487218] sdc: unknown partition table [ 63.487932] sd 3:0:0:0: [sdc] Attached SCSI disk [ 64.204134] ata5: SATA link up 3.0 Gbps (SStatus 123 SControl 300) [ 64.210452] ata5.00: ATA-8: SAMSUNG HD204UI, 1AQ10001, max UDMA/133 [ 64.210523] ata5.00: 3907029168 sectors, multi 16: LBA48 NCQ (depth 31/32), AA [ 64.216851] ata5.00: configured for UDMA/133 [ 64.217016] scsi 4:0:0:0: Direct-Access ATA SAMSUNG HD204UI 1AQ1 PQ: 0 ANSI: 5 [ 64.217674] sd 4:0:0:0: [sdd] 3907029168 512-byte logical blocks: (2.00 TB/1.81 TiB) [ 64.217904] sd 4:0:0:0: [sdd] Write Protect is off [ 64.217983] sd 4:0:0:0: [sdd] Mode Sense: 00 3a 00 00 [ 64.218022] sd 4:0:0:0: [sdd] Write cache: enabled, read cache: enabled, doesn't support DPO or FUA [ 64.233356] sdd: unknown partition table [ 64.233934] sd 4:0:0:0: [sdd] Attached SCSI disk [ 64.940136] ata6: SATA link up 1.5 Gbps (SStatus 113 SControl 300) [ 64.942826] ata6.00: ATAPI: HL-DT-ST DVDRAM GH20NS10, EL00, max UDMA/100 [ 64.946491] ata6.00: configured for UDMA/100 [ 65.057829] scsi 5:0:0:0: CD-ROM HL-DT-ST DVDRAM GH20NS10 EL00 PQ: 0 ANSI: 5 [ 65.166773] sr0: scsi3-mmc drive: 48x/48x writer dvd-ram cd/rw xa/form2 cdda tray [ 65.166860] cdrom: Uniform CD-ROM driver Revision: 3.20 [ 65.167235] sr 5:0:0:0: Attached scsi CD-ROM sr0 [ 65.167631] scsi 6:0:0:0: Direct-Access ATA OCZ-REVODRIVE 1.23 PQ: 0 ANSI: 5 [ 65.168002] sd 6:0:0:0: [sde] 78161328 512-byte logical blocks: (40.0 GB/37.2 GiB) [ 65.168225] sd 6:0:0:0: [sde] Write Protect is off [ 65.168293] sd 6:0:0:0: [sde] Mode Sense: 00 3a 00 00 [ 65.168318] sd 6:0:0:0: [sde] Write cache: enabled, read cache: enabled, doesn't support DPO or FUA [ 65.168835] sde: sde1 [ 65.169514] sd 6:0:0:0: [sde] Attached SCSI disk [ 67.300137] ata8: SATA link up 3.0 Gbps (SStatus 123 SControl 0) [ 67.302854] ata8.00: ATA-8: OCZ-REVODRIVE, 1.23, max UDMA/133 [ 67.302925] ata8.00: 78161328 sectors, multi 16: LBA48 NCQ (depth 31/32) [ 67.312828] ata8.00: configured for UDMA/100 [ 67.313041] scsi 7:0:0:0: Direct-Access ATA OCZ-REVODRIVE 1.23 PQ: 0 ANSI: 5 [ 67.313780] sd 7:0:0:0: [sdf] 78161328 512-byte logical blocks: (40.0 GB/37.2 GiB) [ 67.314018] sd 7:0:0:0: [sdf] Write Protect is off [ 67.314130] sd 7:0:0:0: [sdf] Mode Sense: 00 3a 00 00 [ 67.314230] sd 7:0:0:0: [sdf] Write cache: enabled, read cache: enabled, doesn't support DPO or FUA [ 67.314857] sdf: sdf1 [ 67.315794] sd 7:0:0:0: [sdf] Attached SCSI disk [ 69.345154] ata9: SATA link down (SStatus 0 SControl 0) [ 71.387137] ata10: SATA link down (SStatus 0 SControl 0) [ 71.387843] Freeing unused kernel memory: 376k freed [ 71.517626] md: md0 stopped. [ 71.518798] md: bind [ 71.518981] md: bind [ 71.519294] bio: create slab at 1 [ 71.519364] md/raid0:md0: looking at sde1 [ 71.519427] md/raid0:md0: comparing sde1(78155776) with sde1(78155776) [ 71.519534] md/raid0:md0: END [ 71.519594] md/raid0:md0: ==> UNIQUE [ 71.519655] md/raid0:md0: 1 zones [ 71.519716] md/raid0:md0: looking at sdf1 [ 71.519778] md/raid0:md0: comparing sdf1(78155776) with sde1(78155776) [ 71.519885] md/raid0:md0: EQUAL [ 71.519945] md/raid0:md0: FINAL 1 zones [ 71.520008] md/raid0:md0: done. [ 71.520079] md/raid0:md0: md_size is 156311552 sectors. [ 71.520144] ******* md0 configuration ********* [ 71.520206] zone0=[sde1/sdf1/] [ 71.520384] zone offset=0kb device offset=0kb size=78155776kb [ 71.520450] ********************************** [ 71.520451] [ 71.520576] md0: detected capacity change from 0 to 80031514624 [ 71.521295] md0: unknown partition table [ 71.768281] UDF-fs: No partition found (1) [ 71.792552] device label system devid 1 transid 228397 /dev/md0 [ 72.396385] udev[1197]: starting version 164 [ 72.477654] i801_smbus 0000:00:1f.3: PCI INT C -> GSI 18 (level, low) -> IRQ 18 [ 72.477660] ACPI: resource 0000:00:1f.3 [io 0x0400-0x041f] conflicts with ACPI region SMRG [io 0x400-0x40f] [ 72.477663] ACPI: If an ACPI driver is available for this device, you should use it instead of the native driver [ 72.477881] input: PC Speaker as /devices/platform/pcspkr/input/input2 [ 72.481704] uhci_hcd: USB Universal Host Controller Interface driver [ 72.481815] uhci_hcd 0000:00:1a.0: PCI INT A -> GSI 16 (level, low) -> IRQ 16 [ 72.481828] uhci_hcd 0000:00:1a.0: setting latency timer to 64 [ 72.481832] uhci_hcd 0000:00:1a.0: UHCI Host Controller [ 72.481840] uhci_hcd 0000:00:1a.0: new USB bus registered, assigned bus number 3 [ 72.481850] uhci_hcd 0000:00:1a.0: detected 2 ports [ 72.481857] uhci_hcd 0000:00:1a.0: uhci_check_and_reset_hc: cmd = 0x0000 [ 72.481859] uhci_hcd 0000:00:1a.0: Performing full reset [ 72.481878] uhci_hcd 0000:00:1a.0: supports USB remote wakeup [ 72.481907] uhci_hcd 0000:00:1a.0: irq 16, io base 0x0000b800 [ 72.481978] usb usb3: default language 0x0409 [ 72.481984] usb usb3: udev 1, busnum 3, minor = 256 [ 72.481985] usb usb3: New USB device found, idVendor=1d6b, idProduct=0001 [ 72.481987] usb usb3: New USB device strings: Mfr=3, Product=2, SerialNumber=1 [ 72.481989] usb usb3: Product: UHCI Host Controller [ 72.481992] usb usb3: Manufacturer: Linux 2.6.38-xen-kali uhci_hcd [ 72.481993] usb usb3: SerialNumber: 0000:00:1a.0 [ 72.482105] usb usb3: usb_probe_device [ 72.482109] usb usb3: configuration #1 chosen from 1 choice [ 72.482118] usb usb3: adding 3-0:1.0 (config #1, interface 0) [ 72.482141] hub 3-0:1.0: usb_probe_interface [ 72.482143] hub 3-0:1.0: usb_probe_interface - got id [ 72.482145] hub 3-0:1.0: USB hub found [ 72.482150] hub 3-0:1.0: 2 ports detected [ 72.482152] hub 3-0:1.0: standalone hub [ 72.482153] hub 3-0:1.0: no power switching (usb 1.0) [ 72.482154] hub 3-0:1.0: individual port over-current protection [ 72.482157] hub 3-0:1.0: power on to power good time: 2ms [ 72.482160] hub 3-0:1.0: local power source is good [ 72.482163] hub 3-0:1.0: trying to enable port power on non-switchable hub [ 72.482232] uhci_hcd 0000:00:1a.1: PCI INT B -> GSI 21 (level, low) -> IRQ 21 [ 72.482241] uhci_hcd 0000:00:1a.1: setting latency timer to 64 [ 72.482244] uhci_hcd 0000:00:1a.1: UHCI Host Controller [ 72.482250] uhci_hcd 0000:00:1a.1: new USB bus registered, assigned bus number 4 [ 72.482259] uhci_hcd 0000:00:1a.1: detected 2 ports [ 72.482264] uhci_hcd 0000:00:1a.1: uhci_check_and_reset_hc: cmd = 0x0000 [ 72.482266] uhci_hcd 0000:00:1a.1: Performing full reset [ 72.482284] uhci_hcd 0000:00:1a.1: supports USB remote wakeup [ 72.482301] uhci_hcd 0000:00:1a.1: irq 21, io base 0x0000b880 [ 72.482361] usb usb4: default language 0x0409 [ 72.482368] usb usb4: udev 1, busnum 4, minor = 384 [ 72.482370] usb usb4: New USB device found, idVendor=1d6b, idProduct=0001 [ 72.482371] usb usb4: New USB device strings: Mfr=3, Product=2, SerialNumber=1 [ 72.482373] usb usb4: Product: UHCI Host Controller [ 72.482375] usb usb4: Manufacturer: Linux 2.6.38-xen-kali uhci_hcd [ 72.482377] usb usb4: SerialNumber: 0000:00:1a.1 [ 72.482444] usb usb4: usb_probe_device [ 72.482446] usb usb4: configuration #1 chosen from 1 choice [ 72.482452] usb usb4: adding 4-0:1.0 (config #1, interface 0) [ 72.482476] hub 4-0:1.0: usb_probe_interface [ 72.482478] hub 4-0:1.0: usb_probe_interface - got id [ 72.482480] hub 4-0:1.0: USB hub found [ 72.482484] hub 4-0:1.0: 2 ports detected [ 72.482485] hub 4-0:1.0: standalone hub [ 72.482486] hub 4-0:1.0: no power switching (usb 1.0) [ 72.482488] hub 4-0:1.0: individual port over-current protection [ 72.482489] hub 4-0:1.0: power on to power good time: 2ms [ 72.482492] hub 4-0:1.0: local power source is good [ 72.482494] hub 4-0:1.0: trying to enable port power on non-switchable hub [ 72.482550] uhci_hcd 0000:00:1a.2: PCI INT D -> GSI 19 (level, low) -> IRQ 19 [ 72.482559] uhci_hcd 0000:00:1a.2: setting latency timer to 64 [ 72.482563] uhci_hcd 0000:00:1a.2: UHCI Host Controller [ 72.482571] uhci_hcd 0000:00:1a.2: new USB bus registered, assigned bus number 5 [ 72.482579] uhci_hcd 0000:00:1a.2: detected 2 ports [ 72.482586] uhci_hcd 0000:00:1a.2: uhci_check_and_reset_hc: cmd = 0x0000 [ 72.482588] uhci_hcd 0000:00:1a.2: Performing full reset [ 72.482606] uhci_hcd 0000:00:1a.2: supports USB remote wakeup [ 72.482625] uhci_hcd 0000:00:1a.2: irq 19, io base 0x0000bc00 [ 72.482684] usb usb5: default language 0x0409 [ 72.482690] usb usb5: udev 1, busnum 5, minor = 512 [ 72.482692] usb usb5: New USB device found, idVendor=1d6b, idProduct=0001 [ 72.482694] usb usb5: New USB device strings: Mfr=3, Product=2, SerialNumber=1 [ 72.482697] usb usb5: Product: UHCI Host Controller [ 72.482698] usb usb5: Manufacturer: Linux 2.6.38-xen-kali uhci_hcd [ 72.482700] usb usb5: SerialNumber: 0000:00:1a.2 [ 72.482775] usb usb5: usb_probe_device [ 72.482777] usb usb5: configuration #1 chosen from 1 choice [ 72.482784] usb usb5: adding 5-0:1.0 (config #1, interface 0) [ 72.482807] hub 5-0:1.0: usb_probe_interface [ 72.482809] hub 5-0:1.0: usb_probe_interface - got id [ 72.482811] hub 5-0:1.0: USB hub found [ 72.482815] hub 5-0:1.0: 2 ports detected [ 72.482816] hub 5-0:1.0: standalone hub [ 72.482817] hub 5-0:1.0: no power switching (usb 1.0) [ 72.482818] hub 5-0:1.0: individual port over-current protection [ 72.482820] hub 5-0:1.0: power on to power good time: 2ms [ 72.482823] hub 5-0:1.0: local power source is good [ 72.482824] hub 5-0:1.0: trying to enable port power on non-switchable hub [ 72.482888] uhci_hcd 0000:00:1d.0: PCI INT A -> GSI 23 (level, low) -> IRQ 23 [ 72.482901] uhci_hcd 0000:00:1d.0: setting latency timer to 64 [ 72.482905] uhci_hcd 0000:00:1d.0: UHCI Host Controller [ 72.482912] uhci_hcd 0000:00:1d.0: new USB bus registered, assigned bus number 6 [ 72.482922] uhci_hcd 0000:00:1d.0: detected 2 ports [ 72.482927] uhci_hcd 0000:00:1d.0: uhci_check_and_reset_hc: cmd = 0x0000 [ 72.482928] uhci_hcd 0000:00:1d.0: Performing full reset [ 72.482947] uhci_hcd 0000:00:1d.0: supports USB remote wakeup [ 72.482957] uhci_hcd 0000:00:1d.0: irq 23, io base 0x0000b080 [ 72.483016] usb usb6: default language 0x0409 [ 72.483023] usb usb6: udev 1, busnum 6, minor = 640 [ 72.483025] usb usb6: New USB device found, idVendor=1d6b, idProduct=0001 [ 72.483027] usb usb6: New USB device strings: Mfr=3, Product=2, SerialNumber=1 [ 72.483030] usb usb6: Product: UHCI Host Controller [ 72.483031] usb usb6: Manufacturer: Linux 2.6.38-xen-kali uhci_hcd [ 72.483033] usb usb6: SerialNumber: 0000:00:1d.0 [ 72.483128] usb usb6: usb_probe_device [ 72.483130] usb usb6: configuration #1 chosen from 1 choice [ 72.483139] usb usb6: adding 6-0:1.0 (config #1, interface 0) [ 72.483163] hub 6-0:1.0: usb_probe_interface [ 72.483164] hub 6-0:1.0: usb_probe_interface - got id [ 72.483166] hub 6-0:1.0: USB hub found [ 72.483171] hub 6-0:1.0: 2 ports detected [ 72.483172] hub 6-0:1.0: standalone hub [ 72.483173] hub 6-0:1.0: no power switching (usb 1.0) [ 72.483174] hub 6-0:1.0: individual port over-current protection [ 72.483176] hub 6-0:1.0: power on to power good time: 2ms [ 72.483182] hub 6-0:1.0: local power source is good [ 72.483183] hub 6-0:1.0: trying to enable port power on non-switchable hub [ 72.483248] uhci_hcd 0000:00:1d.1: PCI INT B -> GSI 19 (level, low) -> IRQ 19 [ 72.483256] uhci_hcd 0000:00:1d.1: setting latency timer to 64 [ 72.483259] uhci_hcd 0000:00:1d.1: UHCI Host Controller [ 72.483264] uhci_hcd 0000:00:1d.1: new USB bus registered, assigned bus number 7 [ 72.483272] uhci_hcd 0000:00:1d.1: detected 2 ports [ 72.483277] uhci_hcd 0000:00:1d.1: uhci_check_and_reset_hc: cmd = 0x0000 [ 72.483279] uhci_hcd 0000:00:1d.1: Performing full reset [ 72.483297] uhci_hcd 0000:00:1d.1: supports USB remote wakeup [ 72.483304] uhci_hcd 0000:00:1d.1: irq 19, io base 0x0000b400 [ 72.483363] usb usb7: default language 0x0409 [ 72.483368] usb usb7: udev 1, busnum 7, minor = 768 [ 72.483370] usb usb7: New USB device found, idVendor=1d6b, idProduct=0001 [ 72.483372] usb usb7: New USB device strings: Mfr=3, Product=2, SerialNumber=1 [ 72.483373] usb usb7: Product: UHCI Host Controller [ 72.483375] usb usb7: Manufacturer: Linux 2.6.38-xen-kali uhci_hcd [ 72.483376] usb usb7: SerialNumber: 0000:00:1d.1 [ 72.483467] usb usb7: usb_probe_device [ 72.483469] usb usb7: configuration #1 chosen from 1 choice [ 72.483477] usb usb7: adding 7-0:1.0 (config #1, interface 0) [ 72.483504] hub 7-0:1.0: usb_probe_interface [ 72.483505] hub 7-0:1.0: usb_probe_interface - got id [ 72.483509] hub 7-0:1.0: USB hub found [ 72.483513] hub 7-0:1.0: 2 ports detected [ 72.483515] hub 7-0:1.0: standalone hub [ 72.483516] hub 7-0:1.0: no power switching (usb 1.0) [ 72.483517] hub 7-0:1.0: individual port over-current protection [ 72.483519] hub 7-0:1.0: power on to power good time: 2ms [ 72.483521] hub 7-0:1.0: local power source is good [ 72.483523] hub 7-0:1.0: trying to enable port power on non-switchable hub [ 72.483582] uhci_hcd 0000:00:1d.2: PCI INT C -> GSI 18 (level, low) -> IRQ 18 [ 72.483590] uhci_hcd 0000:00:1d.2: setting latency timer to 64 [ 72.483594] uhci_hcd 0000:00:1d.2: UHCI Host Controller [ 72.483599] uhci_hcd 0000:00:1d.2: new USB bus registered, assigned bus number 8 [ 72.483608] uhci_hcd 0000:00:1d.2: detected 2 ports [ 72.483613] uhci_hcd 0000:00:1d.2: uhci_check_and_reset_hc: cmd = 0x0000 [ 72.483614] uhci_hcd 0000:00:1d.2: Performing full reset [ 72.483632] uhci_hcd 0000:00:1d.2: supports USB remote wakeup [ 72.483640] uhci_hcd 0000:00:1d.2: irq 18, io base 0x0000b480 [ 72.483690] nvidia: module license 'NVIDIA' taints kernel. [ 72.483693] Disabling lock debugging due to kernel taint [ 72.483695] usb usb8: default language 0x0409 [ 72.483700] usb usb8: udev 1, busnum 8, minor = 896 [ 72.483701] usb usb8: New USB device found, idVendor=1d6b, idProduct=0001 [ 72.483703] usb usb8: New USB device strings: Mfr=3, Product=2, SerialNumber=1 [ 72.483705] usb usb8: Product: UHCI Host Controller [ 72.483707] usb usb8: Manufacturer: Linux 2.6.38-xen-kali uhci_hcd [ 72.483709] usb usb8: SerialNumber: 0000:00:1d.2 [ 72.483783] usb usb8: usb_probe_device [ 72.483786] usb usb8: configuration #1 chosen from 1 choice [ 72.483793] usb usb8: adding 8-0:1.0 (config #1, interface 0) [ 72.483817] hub 8-0:1.0: usb_probe_interface [ 72.483819] hub 8-0:1.0: usb_probe_interface - got id [ 72.483822] hub 8-0:1.0: USB hub found [ 72.483825] hub 8-0:1.0: 2 ports detected [ 72.483827] hub 8-0:1.0: standalone hub [ 72.483829] hub 8-0:1.0: no power switching (usb 1.0) [ 72.483831] hub 8-0:1.0: individual port over-current protection [ 72.483832] hub 8-0:1.0: power on to power good time: 2ms [ 72.483838] hub 8-0:1.0: local power source is good [ 72.483840] hub 8-0:1.0: trying to enable port power on non-switchable hub [ 72.489025] firewire_ohci 0000:09:04.0: PCI INT A -> GSI 19 (level, low) -> IRQ 19 [ 72.499351] sd 1:0:0:0: Attached scsi generic sg0 type 0 [ 72.499373] sd 2:0:0:0: Attached scsi generic sg1 type 0 [ 72.499393] sd 3:0:0:0: Attached scsi generic sg2 type 0 [ 72.499415] sd 4:0:0:0: Attached scsi generic sg3 type 0 [ 72.499436] sr 5:0:0:0: Attached scsi generic sg4 type 5 [ 72.499462] sd 6:0:0:0: Attached scsi generic sg5 type 0 [ 72.499483] sd 7:0:0:0: Attached scsi generic sg6 type 0 [ 72.506699] Initializing USB Mass Storage driver... [ 72.506715] usb-storage 1-1:1.0: usb_probe_interface [ 72.506719] usb-storage 1-1:1.0: usb_probe_interface - got id [ 72.506780] scsi10 : usb-storage 1-1:1.0 [ 72.506849] usbcore: registered new interface driver usb-storage [ 72.506850] USB Mass Storage support registered. [ 72.510399] rt2800usb 1-3:1.0: usb_probe_interface [ 72.510403] rt2800usb 1-3:1.0: usb_probe_interface - got id [ 72.515487] HDA Intel 0000:00:1b.0: PCI INT A -> GSI 22 (level, low) -> IRQ 22 [ 72.515579] HDA Intel 0000:00:1b.0: irq 73 (299) for MSI/MSI-X [ 72.515616] HDA Intel 0000:00:1b.0: setting latency timer to 64 [ 72.533500] ieee80211 phy0: Selected rate control algorithm 'minstrel_ht' [ 72.533639] Registered led device: rt2800usb-phy0::radio [ 72.533653] Registered led device: rt2800usb-phy0::assoc [ 72.533667] Registered led device: rt2800usb-phy0::quality [ 72.533910] usbcore: registered new interface driver rt2800usb [ 72.540181] firewire_ohci: Added fw-ohci device 0000:09:04.0, OHCI v1.0, 8 IR + 8 IT contexts, quirks 0x0 [ 72.583148] uhci_hcd 0000:00:1a.0: port 1 portsc 0082,00 [ 72.583166] uhci_hcd 0000:00:1a.1: port 1 portsc 0082,00 [ 72.583197] hub 5-0:1.0: state 7 ports 2 chg 0000 evt 0000 [ 72.583201] hub 6-0:1.0: state 7 ports 2 chg 0000 evt 0000 [ 72.583214] uhci_hcd 0000:00:1d.2: port 1 portsc 01ab,00 [ 72.583216] hub 7-0:1.0: state 7 ports 2 chg 0000 evt 0000 [ 72.583219] hub 8-0:1.0: port 1: status 0301 change 0003 [ 72.583231] uhci_hcd 0000:00:1d.2: port 2 portsc 01ab,00 [ 72.583233] hub 8-0:1.0: port 2: status 0301 change 0003 [ 72.684174] hub 3-0:1.0: state 7 ports 2 chg 0000 evt 0000 [ 72.684177] hub 4-0:1.0: state 7 ports 2 chg 0000 evt 0000 [ 72.684179] hub 8-0:1.0: state 7 ports 2 chg 0006 evt 0000 [ 72.684189] hub 8-0:1.0: port 1, status 0301, change 0000, 1.5 Mb/s [ 72.787061] usb 8-1: new low speed USB device using uhci_hcd and address 2 [ 72.929692] usb 8-1: skipped 1 descriptor after interface [ 72.934689] usb 8-1: default language 0x0409 [ 72.940283] nvidia 0000:04:00.0: PCI INT A -> GSI 24 (level, low) -> IRQ 24 [ 72.940291] nvidia 0000:04:00.0: setting latency timer to 64 [ 72.940295] vgaarb: device changed decodes: PCI:0000:04:00.0,olddecodes=io+mem,decodes=none:owns=io+mem [ 72.940574] NVRM: loading NVIDIA UNIX x86_64 Kernel Module 275.09.07 Wed Jun 8 14:16:46 PDT 2011 [ 72.946208] udev[1211]: renamed network interface wlan0 to wlan3 [ 72.951700] usb 8-1: udev 2, busnum 8, minor = 897 [ 72.951703] usb 8-1: New USB device found, idVendor=046d, idProduct=c00e [ 72.951705] usb 8-1: New USB device strings: Mfr=1, Product=2, SerialNumber=0 [ 72.951707] usb 8-1: Product: USB-PS/2 Optical Mouse [ 72.951708] usb 8-1: Manufacturer: Logitech [ 72.951774] usb 8-1: usb_probe_device [ 72.951777] usb 8-1: configuration #1 chosen from 1 choice [ 72.954692] usb 8-1: adding 8-1:1.0 (config #1, interface 0) [ 72.954712] usbhid 8-1:1.0: usb_probe_interface [ 72.954714] usbhid 8-1:1.0: usb_probe_interface - got id [ 72.967841] input: Logitech USB-PS/2 Optical Mouse as /devices/pci0000:00/0000:00:1d.2/usb8/8-1/8-1:1.0/input/input3 [ 72.967869] generic-usb 0003:046D:C00E.0001: input: USB HID v1.10 Mouse [Logitech USB-PS/2 Optical Mouse] on usb-0000:00:1d.2-1/input0 [ 72.967898] hub 8-0:1.0: port 2, status 0301, change 0000, 1.5 Mb/s [ 72.990466] md: bind [ 72.996780] md: bind [ 73.003277] md: bind [ 73.006539] md/raid:md1: device sdc operational as raid disk 0 [ 73.006545] md/raid:md1: device sdb operational as raid disk 2 [ 73.006549] md/raid:md1: device sdd operational as raid disk 1 [ 73.006973] md/raid:md1: allocated 3230kB [ 73.007040] md/raid:md1: raid level 5 active with 3 out of 3 devices, algorithm 2 [ 73.007043] RAID conf printout: [ 73.007046] --- level:5 rd:3 wd:3 [ 73.007049] disk 0, o:1, dev:sdc [ 73.007065] disk 1, o:1, dev:sdd [ 73.007067] disk 2, o:1, dev:sdb [ 73.007111] md1: detected capacity change from 0 to 4000794542080 [ 73.031303] md1: unknown partition table [ 73.041199] firewire_core: created device fw0: GUID 001e8c0001b90592, S400 [ 73.070094] usb 8-2: new low speed USB device using uhci_hcd and address 3 [ 73.273742] usb 8-2: skipped 1 descriptor after interface [ 73.273747] usb 8-2: skipped 1 descriptor after interface [ 73.282736] usb 8-2: default language 0x0409 [ 73.340741] usb 8-2: udev 3, busnum 8, minor = 898 [ 73.340745] usb 8-2: New USB device found, idVendor=06a3, idProduct=8021 [ 73.340749] usb 8-2: New USB device strings: Mfr=1, Product=2, SerialNumber=0 [ 73.340752] usb 8-2: Product: Saitek Eclipse II Keyboard [ 73.340755] usb 8-2: Manufacturer: Chicony [ 73.340838] usb 8-2: usb_probe_device [ 73.340843] usb 8-2: configuration #1 chosen from 1 choice [ 73.344740] usb 8-2: adding 8-2:1.0 (config #1, interface 0) [ 73.344778] usbhid 8-2:1.0: usb_probe_interface [ 73.344781] usbhid 8-2:1.0: usb_probe_interface - got id [ 73.393944] input: Chicony Saitek Eclipse II Keyboard as /devices/pci0000:00/0000:00:1d.2/usb8/8-2/8-2:1.0/input/input4 [ 73.393956] uhci_hcd 0000:00:1d.2: reserve dev 3 ep81-INT, period 8, phase 4, 118 us [ 73.393963] generic-usb 0003:06A3:8021.0002: input: USB HID v1.11 Keyboard [Chicony Saitek Eclipse II Keyboard] on usb-0000:00:1d.2-2/input0 [ 73.393983] usb 8-2: adding 8-2:1.1 (config #1, interface 1) [ 73.394016] usbhid 8-2:1.1: usb_probe_interface [ 73.394019] usbhid 8-2:1.1: usb_probe_interface - got id [ 73.508213] scsi 10:0:0:0: Direct-Access Generic USB SD Reader 1.00 PQ: 0 ANSI: 0 [ 73.508831] scsi 10:0:0:1: Direct-Access Generic USB CF Reader 1.01 PQ: 0 ANSI: 0 [ 73.509437] scsi 10:0:0:2: Direct-Access Generic USB SM Reader 1.02 PQ: 0 ANSI: 0 [ 73.510069] scsi 10:0:0:3: Direct-Access Generic USB MS Reader 1.03 PQ: 0 ANSI: 0 [ 73.510943] sd 10:0:0:0: Attached scsi generic sg7 type 0 [ 73.511228] sd 10:0:0:1: Attached scsi generic sg8 type 0 [ 73.511390] sd 10:0:0:2: Attached scsi generic sg9 type 0 [ 73.512464] sd 10:0:0:3: Attached scsi generic sg10 type 0 [ 73.547779] input: Chicony Saitek Eclipse II Keyboard as /devices/pci0000:00/0000:00:1d.2/usb8/8-2/8-2:1.1/input/input5 [ 73.547790] uhci_hcd 0000:00:1d.2: reserve dev 3 ep82-INT, period 8, phase 4, 93 us [ 73.547805] usbhid 8-2:1.1: looking for a minor, starting at 96 [ 73.547865] generic-usb 0003:06A3:8021.0003: input,hiddev0: USB HID v1.11 Device [Chicony Saitek Eclipse II Keyboard] on usb-0000:00:1d.2-2/input1 [ 73.658372] sd 10:0:0:2: [sdi] 16000 512-byte logical blocks: (8.19 MB/7.81 MiB) [ 73.660167] sd 10:0:0:3: [sdj] Attached SCSI removable disk [ 73.660918] sd 10:0:0:2: [sdi] Write Protect is off [ 73.660924] sd 10:0:0:2: [sdi] Mode Sense: 03 00 00 00 [ 73.662169] sd 10:0:0:1: [sdh] Attached SCSI removable disk [ 73.663195] sd 10:0:0:0: [sdg] Attached SCSI removable disk [ 73.663533] sd 10:0:0:2: [sdi] No Caching mode page present [ 73.663537] sd 10:0:0:2: [sdi] Assuming drive cache: write through [ 73.668466] sd 10:0:0:2: [sdi] No Caching mode page present [ 73.668471] sd 10:0:0:2: [sdi] Assuming drive cache: write through [ 73.703109] usb usb5: suspend_rh (auto-stop) [ 73.703143] usb usb6: suspend_rh (auto-stop) [ 73.703175] usb usb7: suspend_rh (auto-stop) [ 73.703206] usb usb3: suspend_rh (auto-stop) [ 73.703238] usb usb4: suspend_rh (auto-stop) [ 73.761728] sdi: sdi1 [ 73.766819] sd 10:0:0:2: [sdi] No Caching mode page present [ 73.766824] sd 10:0:0:2: [sdi] Assuming drive cache: write through [ 73.766827] sd 10:0:0:2: [sdi] Attached SCSI removable disk [ 74.156537] coretemp coretemp.0: TjMax is 101 C. [ 74.156957] coretemp coretemp.2: TjMax is 101 C. [ 74.157550] coretemp coretemp.4: TjMax is 101 C. [ 74.158560] coretemp coretemp.6: TjMax is 101 C. [ 74.158970] coretemp coretemp.8: TjMax is 101 C. [ 74.159439] coretemp coretemp.10: TjMax is 101 C. [ 74.314543] NET: Registered protocol family 10 [ 74.642572] device-mapper: ioctl: 4.19.1-ioctl (2011-01-07) initialised: dm-devel@redhat.com [ 76.778633] btrfs: use ssd allocation scheme [ 76.958370] XFS mounting filesystem dm-0 [ 77.303947] Ending clean XFS mount for filesystem: dm-0 [ 78.753020] ADDRCONF(NETDEV_UP): wlan3: link is not ready [ 78.978781] r8169 0000:07:00.0: eth0: link down [ 78.982546] ADDRCONF(NETDEV_UP): eth0: link is not ready [ 80.114266] wlan3: authenticate with d8:5d:4c:ba:d4:7a (try 1) [ 80.115763] wlan3: authenticated [ 81.220156] wlan3: associate with d8:5d:4c:ba:d4:7a (try 1) [ 81.222163] wlan3: RX AssocResp from d8:5d:4c:ba:d4:7a (capab=0x431 status=0 aid=1) [ 81.222167] wlan3: associated [ 81.234021] ADDRCONF(NETDEV_CHANGE): wlan3: link becomes ready [ 81.329524] ------------[ cut here ]------------ [ 81.329534] WARNING: at kernel/printk.c:288 do_syslog+0x85/0x448() [ 81.329537] Hardware name: System Product Name [ 81.329539] Attempt to access syslog with CAP_SYS_ADMIN but no CAP_SYSLOG (deprecated). [ 81.329542] Modules linked in: dm_crypt dm_mod ipv6 nls_cp850 nls_cp437 coretemp xts gf128mul nvidia(P) snd_hda_intel rt2800usb usb_storage rt2800lib sg snd_hda_codec rt2x00usb rt2x00lib firewire_ohci firewire_core uhci_hcd i2c_i801 pcspkr asus_atk0110 [ 81.329562] Pid: 2290, comm: syslog-ng Tainted: P 2.6.38-xen-kali #3 [ 81.329565] Call Trace: [ 81.329570] [] ? warn_slowpath_common+0x78/0x8c [ 81.329576] [] ? kmsg_release+0x0/0x1b [ 81.329580] [] ? warn_slowpath_fmt+0x45/0x4a [ 81.329586] [] ? proc_lookup_de+0xa3/0xbb [ 81.329590] [] ? do_syslog+0x85/0x448 [ 81.329595] [] ? need_resched+0x1a/0x23 [ 81.329599] [] ? should_resched+0x5/0x24 [ 81.329605] [] ? _cond_resched+0x9/0x20 [ 81.329610] [] ? slab_pre_alloc_hook.clone.45+0x15/0x1c [ 81.329614] [] ? kmsg_release+0x0/0x1b [ 81.329618] [] ? proc_reg_open+0x9f/0x13f [ 81.329621] [] ? kmsg_open+0x0/0x1b [ 81.329625] [] ? proc_reg_open+0x0/0x13f [ 81.329630] [] ? __dentry_open.clone.14+0x110/0x21a [ 81.329634] [] ? finish_open+0x97/0x159 [ 81.329638] [] ? do_path_lookup+0x7d/0xe1 [ 81.329642] [] ? do_filp_open+0x15e/0x5cf [ 81.329648] [] ? fsnotify_clear_marks_by_inode+0x84/0xc3 [ 81.329652] [] ? need_resched+0x1a/0x23 [ 81.329656] [] ? should_resched+0x5/0x24 [ 81.329660] [] ? _cond_resched+0x9/0x20 [ 81.329664] [] ? need_resched+0x1a/0x23 [ 81.329668] [] ? should_resched+0x5/0x24 [ 81.329672] [] ? need_resched+0x1a/0x23 [ 81.329676] [] ? should_resched+0x5/0x24 [ 81.329680] [] ? alloc_fd+0x103/0x115 [ 81.329684] [] ? do_sys_open+0x56/0xe4 [ 81.329689] [] ? system_call_fastpath+0x16/0x1b [ 81.329693] [] ? system_call+0x0/0x52 [ 81.329695] ---[ end trace f5e9ca4210e44b47 ]--- [ 83.478110] uhci_hcd 0000:00:1d.2: reserve dev 2 ep81-INT, period 8, phase 4, 93 us [ 83.487710] uhci_hcd 0000:00:1d.2: release dev 2 ep81-INT, period 8, phase 4, 93 us [ 83.502072] uhci_hcd 0000:00:1d.2: reserve dev 2 ep81-INT, period 8, phase 4, 93 us [ 83.511709] uhci_hcd 0000:00:1d.2: release dev 2 ep81-INT, period 8, phase 4, 93 us [ 83.526072] uhci_hcd 0000:00:1d.2: reserve dev 2 ep81-INT, period 8, phase 4, 93 us [ 91.673068] wlan3: no IPv6 routers present [ 93.522509] ata2.00: configured for UDMA/133 [ 93.522513] ata2: EH complete [ 94.365986] ata3.00: configured for UDMA/133 [ 94.365989] ata3: EH complete [ 94.454397] ata4.00: configured for UDMA/133 [ 94.454400] ata4: EH complete [ 94.615036] ata5.00: configured for UDMA/133 [ 94.615040] ata5: EH complete [ 94.638617] ata7.00: configured for UDMA/100 [ 94.638622] ata7: EH complete [ 94.663118] ata8.00: configured for UDMA/100 [ 94.663123] ata8: EH complete [ 99.881918] Adding 524284k swap on /warehouse/swapfile.0. Priority:-1 extents:1 across:524284k [ 196.896292] chrome_sandbox (3307): /proc/3305/oom_adj is deprecated, please use /proc/3305/oom_score_adj instead. --=-D3WmHD95xIQTgQFeJxa9 Content-Disposition: attachment; filename="lspci.log" Content-Type: text/x-log; name="lspci.log"; charset="UTF-8" Content-Transfer-Encoding: 7bit 00:00.0 Host bridge: Intel Corporation 5520/5500/X58 I/O Hub to ESI Port (rev 12) 00:01.0 PCI bridge: Intel Corporation 5520/5500/X58 I/O Hub PCI Express Root Port 1 (rev 12) 00:03.0 PCI bridge: Intel Corporation 5520/5500/X58 I/O Hub PCI Express Root Port 3 (rev 12) 00:07.0 PCI bridge: Intel Corporation 5520/5500/X58 I/O Hub PCI Express Root Port 7 (rev 12) 00:14.0 PIC: Intel Corporation 5520/5500/X58 I/O Hub System Management Registers (rev 12) 00:14.1 PIC: Intel Corporation 5520/5500/X58 I/O Hub GPIO and Scratch Pad Registers (rev 12) 00:14.2 PIC: Intel Corporation 5520/5500/X58 I/O Hub Control Status and RAS Registers (rev 12) 00:14.3 PIC: Intel Corporation 5520/5500/X58 I/O Hub Throttle Registers (rev 12) 00:1a.0 USB Controller: Intel Corporation 82801JI (ICH10 Family) USB UHCI Controller #4 00:1a.1 USB Controller: Intel Corporation 82801JI (ICH10 Family) USB UHCI Controller #5 00:1a.2 USB Controller: Intel Corporation 82801JI (ICH10 Family) USB UHCI Controller #6 00:1a.7 USB Controller: Intel Corporation 82801JI (ICH10 Family) USB2 EHCI Controller #2 00:1b.0 Audio device: Intel Corporation 82801JI (ICH10 Family) HD Audio Controller 00:1c.0 PCI bridge: Intel Corporation 82801JI (ICH10 Family) PCI Express Root Port 1 00:1c.1 PCI bridge: Intel Corporation 82801JI (ICH10 Family) PCI Express Port 2 00:1d.0 USB Controller: Intel Corporation 82801JI (ICH10 Family) USB UHCI Controller #1 00:1d.1 USB Controller: Intel Corporation 82801JI (ICH10 Family) USB UHCI Controller #2 00:1d.2 USB Controller: Intel Corporation 82801JI (ICH10 Family) USB UHCI Controller #3 00:1d.7 USB Controller: Intel Corporation 82801JI (ICH10 Family) USB2 EHCI Controller #1 00:1e.0 PCI bridge: Intel Corporation 82801 PCI Bridge (rev 90) 00:1f.0 ISA bridge: Intel Corporation 82801JIR (ICH10R) LPC Interface Controller 00:1f.2 SATA controller: Intel Corporation 82801JI (ICH10 Family) SATA AHCI Controller 00:1f.3 SMBus: Intel Corporation 82801JI (ICH10 Family) SMBus Controller 01:00.0 PCI bridge: NEC Corporation uPD720400 PCI Express - PCI/PCI-X Bridge (rev 06) 01:00.1 PCI bridge: NEC Corporation uPD720400 PCI Express - PCI/PCI-X Bridge (rev 06) 04:00.0 VGA compatible controller: nVidia Corporation GT200b [GeForce GTX 285] (rev a1) 05:00.0 PCI bridge: Pericom Semiconductor PCI Express to PCI-XPI7C9X130 PCI-X Bridge (rev 04) 06:00.0 RAID bus controller: Silicon Image, Inc. SiI 3124 PCI-X Serial ATA Controller (rev 02) 07:00.0 Ethernet controller: Realtek Semiconductor Co., Ltd. RTL8111/8168B PCI Express Gigabit Ethernet controller (rev 02) 09:04.0 FireWire (IEEE 1394): Agere Systems FW322/323 (rev 70) --=-D3WmHD95xIQTgQFeJxa9 Content-Disposition: attachment; filename="lscpu.log" Content-Type: text/x-log; name="lscpu.log"; charset="UTF-8" Content-Transfer-Encoding: 7bit Architecture: x86_64 CPU op-mode(s): 32-bit, 64-bit Byte Order: Little Endian CPU(s): 12 On-line CPU(s) list: 0-11 Thread(s) per core: 1 Core(s) per socket: 1 Socket(s): 12 Vendor ID: GenuineIntel CPU family: 6 Model: 44 Stepping: 2 CPU MHz: 3340.984 BogoMIPS: 7040.49 Hypervisor vendor: Xen Virtualization type: para L1d cache: 32K L1i cache: 32K L2 cache: 256K L3 cache: 12288K --=-D3WmHD95xIQTgQFeJxa9 Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel --=-D3WmHD95xIQTgQFeJxa9-- From xen-users-bounces@lists.xensource.com Fri Sep 09 17:33:00 2011 Return-path: Envelope-to: www-data@lists.xensource.com Delivery-date: Fri, 09 Sep 2011 17:33:00 -0700 Received: from localhost ([127.0.0.1] helo=lists.colo.xensource.com) by lists.xensource.com with esmtp (Exim 4.43) id 1R2BVD-0003RB-Rf; Fri, 09 Sep 2011 17:32:59 -0700 Received: from mail182.messagelabs.com ([85.158.139.83]) by lists.xensource.com with esmtp (Exim 4.43) id 1R2BUX-00037O-FA; Fri, 09 Sep 2011 17:32:17 -0700 X-Env-Sender: shriganeshs@gmail.com X-Msg-Ref: server-11.tower-182.messagelabs.com!1315614733!17764175!1 X-Originating-IP: [209.85.160.171] X-StarScan-Version: 6.3.6; banners=-,-,- X-VirusChecked: Checked Received: (qmail 3614 invoked from network); 10 Sep 2011 00:32:14 -0000 Received: from mail-gy0-f171.google.com (HELO mail-gy0-f171.google.com) (209.85.160.171) by server-11.tower-182.messagelabs.com with RC4-SHA encrypted SMTP; 10 Sep 2011 00:32:14 -0000 Received: by gyh3 with SMTP id 3so861400gyh.30 for ; Fri, 09 Sep 2011 17:32:12 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:date:message-id:subject:from:to:content-type; bh=aQ08AyMC0XFWi8YDojPgx+ynIKxA8hAtUZZ5f19kID4=; b=Yr+vNujINYZ3lsjfiVIwK2LS4MzFxlrKN+mFKWptNcxD0AVmc+t4GC48jFkJs7MrBi hilDcW7kljZWpf0KBSJ9DeCQbPYzy4DipUAQtgxs38ojAAbtYUsSagBi2lDtzPSiO2s9 M7dKri5r6U1fhO8uLB75jrXwxqhKph5Woml4c= MIME-Version: 1.0 Received: by 10.43.132.71 with SMTP id ht7mr157192icc.258.1315614732186; Fri, 09 Sep 2011 17:32:12 -0700 (PDT) Received: by 10.231.157.209 with HTTP; Fri, 9 Sep 2011 17:32:11 -0700 (PDT) Date: Fri, 9 Sep 2011 17:32:11 -0700 Message-ID: From: Shriganesh Shintre To: Xen-users@lists.xensource.com, xen-devel@lists.xensource.com Cc: Subject: [Xen-users] xen 4.1.1 missing veth0 <--> vif0.0 pairs X-BeenThere: xen-users@lists.xensource.com X-Mailman-Version: 2.1.5 Precedence: list List-Id: Xen user discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1749393168==" Sender: xen-users-bounces@lists.xensource.com Errors-To: xen-users-bounces@lists.xensource.com --===============1749393168== Content-Type: multipart/alternative; boundary=20cf307d03d4c5f4ce04ac8b6cf3 --20cf307d03d4c5f4ce04ac8b6cf3 Content-Type: text/plain; charset=ISO-8859-1 Hi, I am using Xen 4.1.1 with Linux 3.0.1 kernel. Previously (Xen 3.4.4 and linux kernel 2.6.18) Xen by default created veth0 <--> vif0.0 pair in dom0. With Xen 4.1.1 these pairs are missing in dom0. Using command 'ip link add type veth' I can create veth0 and veth1 but vif0.0 is still missing in dom0. (When new domU created I can see vif1.x created) Could you please help me with understanding following things 1) Is veth is replaced by something? and if yes what is it? 2) How to create veth0 <--> vif0.0 pairs? Or how to create vif0.x interfaces? 3) In which version of Xen these changes regarding veth - vif0.0 are made? Thank you in advance. SG --20cf307d03d4c5f4ce04ac8b6cf3 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Hi,

I am using Xen 4.1.1 with Linux 3.0.1 kernel. Previously (Xen 3.= 4.4 and linux kernel 2.6.18) Xen by default created veth0 <--> vif0.0= pair in dom0. With Xen 4.1.1 these pairs are missing in dom0.
Using co= mmand 'ip link add type veth' I can create veth0 and veth1 but vif0= .0 is still missing in dom0. (When new domU created I can see vif1.x create= d)
Could you please help me with understanding following things
1) Is veth = is replaced by something? and if yes what is it?
2) How to create veth0 = <--> vif0.0 pairs? Or how to create vif0.x interfaces?
3) In which= version of Xen these changes regarding veth - vif0.0 are made?

Thank you in advance.
SG
--20cf307d03d4c5f4ce04ac8b6cf3-- --===============1749393168== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Xen-users mailing list Xen-users@lists.xensource.com http://lists.xensource.com/xen-users --===============1749393168==-- From xen-users-bounces@lists.xensource.com Fri Sep 09 18:31:11 2011 Return-path: Envelope-to: www-data@lists.xensource.com Delivery-date: Fri, 09 Sep 2011 18:31:11 -0700 Received: from localhost ([127.0.0.1] helo=lists.colo.xensource.com) by lists.xensource.com with esmtp (Exim 4.43) id 1R2CPX-0004wz-1P; Fri, 09 Sep 2011 18:31:11 -0700 Received: from mail174.messagelabs.com ([85.158.138.51]) by lists.xensource.com with esmtp (Exim 4.43) id 1R2COB-0004cj-9v; Fri, 09 Sep 2011 18:29:47 -0700 X-Env-Sender: todd.deshane.xen@gmail.com X-Msg-Ref: server-15.tower-174.messagelabs.com!1315618182!24550303!1 X-Originating-IP: [209.85.213.43] X-StarScan-Version: 6.3.6; banners=-,-,- X-VirusChecked: Checked Received: (qmail 335 invoked from network); 10 Sep 2011 01:29:43 -0000 Received: from mail-yw0-f43.google.com (HELO mail-yw0-f43.google.com) (209.85.213.43) by server-15.tower-174.messagelabs.com with RC4-SHA encrypted SMTP; 10 Sep 2011 01:29:43 -0000 Received: by ywm21 with SMTP id 21so762427ywm.30 for ; Fri, 09 Sep 2011 18:29:42 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:sender:in-reply-to:references:from:date :x-google-sender-auth:message-id:subject:to:cc:content-type; bh=210l53/YH6EeGiAjKWHtcJ5dZoDYM8MliuWIqN3iTdE=; b=M87tdaVruLdLs60MnFvuZtG1hgYjoo7b6YLndm6uh+ZyNPkN8i5vm/mzn44ggHFOia Ol3ll87rArwWowjg+njCvZkZOOWhj6pukntexPYDuoVLKfMUZqsW31wXrgTj+uI3JYks oUk+oahLcqy8HcsouT6DPo923lgSb58h5s0aA= Received: by 10.231.62.84 with SMTP id w20mr3224245ibh.4.1315618182079; Fri, 09 Sep 2011 18:29:42 -0700 (PDT) MIME-Version: 1.0 Received: by 10.231.206.136 with HTTP; Fri, 9 Sep 2011 18:29:22 -0700 (PDT) In-Reply-To: References: From: Todd Deshane Date: Fri, 9 Sep 2011 21:29:22 -0400 X-Google-Sender-Auth: OCmjtmr4t-BH4WTM4X0nO7wBFHM Message-ID: Subject: Re: [Xen-users] xen 4.1.1 missing veth0 <--> vif0.0 pairs To: Shriganesh Shintre Content-Type: text/plain; charset=ISO-8859-1 Cc: xen-devel@lists.xensource.com, Xen-users@lists.xensource.com X-BeenThere: xen-users@lists.xensource.com X-Mailman-Version: 2.1.5 Precedence: list List-Id: Xen user discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-users-bounces@lists.xensource.com Errors-To: xen-users-bounces@lists.xensource.com On Fri, Sep 9, 2011 at 8:32 PM, Shriganesh Shintre wrote: > Hi, > > I am using Xen 4.1.1 with Linux 3.0.1 kernel. Previously (Xen 3.4.4 and > linux kernel 2.6.18) Xen by default created veth0 <--> vif0.0 pair in dom0. > With Xen 4.1.1 these pairs are missing in dom0. > Using command 'ip link add type veth' I can create veth0 and veth1 but > vif0.0 is still missing in dom0. (When new domU created I can see vif1.x > created) > Could you please help me with understanding following things > 1) Is veth is replaced by something? and if yes what is it? > 2) How to create veth0 <--> vif0.0 pairs? Or how to create vif0.x > interfaces? > 3) In which version of Xen these changes regarding veth - vif0.0 are made? > I'm not sure what you are trying to do exactly, but I would recommend taking a look at: http://wiki.xensource.com/xenwiki/MigrationGuideToXen4.1%2B Guest networking/bridging should now be handled by the distro and not with the xend network scripts anymore. Hope that helps. Thanks, Todd -- Todd Deshane http://www.linkedin.com/in/deshantm http://www.xen.org/products/cloudxen.html http://runningxen.com/ _______________________________________________ Xen-users mailing list Xen-users@lists.xensource.com http://lists.xensource.com/xen-users From xen-devel-bounces@lists.xensource.com Fri Sep 09 18:40:52 2011 Return-path: Envelope-to: www-data@lists.xensource.com Delivery-date: Fri, 09 Sep 2011 18:40:52 -0700 Received: from localhost ([127.0.0.1] helo=lists.colo.xensource.com) by lists.xensource.com with esmtp (Exim 4.43) id 1R2CYu-0006kV-IM; Fri, 09 Sep 2011 18:40:52 -0700 Received: from mail216.messagelabs.com ([85.158.143.99]) by lists.xensource.com with smtp (Exim 4.43) id 1R2CYH-0006Vg-1N for xen-devel@lists.xensource.com; Fri, 09 Sep 2011 18:40:14 -0700 X-Env-Sender: Ian.Jackson@eu.citrix.com X-Msg-Ref: server-2.tower-216.messagelabs.com!1315618810!17723466!1 X-Originating-IP: [62.200.22.115] X-StarScan-Version: 6.3.6; banners=-,-,- X-VirusChecked: Checked Received: (qmail 28578 invoked from network); 10 Sep 2011 01:40:10 -0000 Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115) by server-2.tower-216.messagelabs.com with SMTP; 10 Sep 2011 01:40:10 -0000 X-IronPort-AV: E=Sophos;i="4.68,359,1312156800"; d="scan'208";a="7706755" Received: from lonpmailmx01.citrite.net ([10.30.203.162]) by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5; 10 Sep 2011 01:40:09 +0000 Received: from woking.xci-test.com (10.80.248.135) by smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id 8.3.137.0; Sat, 10 Sep 2011 02:40:09 +0100 Received: from osstest by woking.xci-test.com with local (Exim 4.69) (envelope-from ) id 1R2CYD-00044N-FR; Sat, 10 Sep 2011 02:40:09 +0100 To: xen-devel@lists.xensource.com Message-ID: From: xen.org Date: Sat, 10 Sep 2011 02:40:09 +0100 MIME-Version: 1.0 Content-Type: text/plain Cc: ian.jackson@eu.citrix.com Subject: [Xen-devel] [xen-unstable test] 8870: tolerable FAIL X-BeenThere: xen-devel@lists.xensource.com X-Mailman-Version: 2.1.5 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xensource.com Errors-To: xen-devel-bounces@lists.xensource.com flight 8870 xen-unstable real [real] http://www.chiark.greenend.org.uk/~xensrcts/logs/8870/ Failures :-/ but no regressions. Tests which did not succeed, but are not blocking, including regressions (tests previously passed) regarded as allowable: test-amd64-amd64-xl-pcipt-intel 1 xen-build-check(1) blocked n/a test-amd64-i386-rhel6hvm-intel 1 xen-build-check(1) blocked n/a test-i386-i386-pv 1 xen-build-check(1) blocked n/a test-amd64-i386-pv 1 xen-build-check(1) blocked n/a test-amd64-amd64-pv 1 xen-build-check(1) blocked n/a test-i386-i386-xl 1 xen-build-check(1) blocked n/a test-amd64-i386-xl 1 xen-build-check(1) blocked n/a test-amd64-i386-xl-credit2 1 xen-build-check(1) blocked n/a test-amd64-i386-rhel6hvm-amd 1 xen-build-check(1) blocked n/a test-amd64-amd64-pair 1 xen-build-check(1) blocked n/a test-amd64-i386-pair 1 xen-build-check(1) blocked n/a test-i386-i386-pair 1 xen-build-check(1) blocked n/a build-amd64-pvops 4 kernel-build fail like 8869 build-i386-pvops 4 kernel-build fail like 8869 test-amd64-i386-xl-multivcpu 1 xen-build-check(1) blocked n/a test-amd64-amd64-xl-sedf 1 xen-build-check(1) blocked n/a test-amd64-i386-win-vcpus1 1 xen-build-check(1) blocked n/a test-amd64-i386-xl-win-vcpus1 1 xen-build-check(1) blocked n/a test-amd64-amd64-win 1 xen-build-check(1) blocked n/a test-amd64-i386-win 1 xen-build-check(1) blocked n/a test-amd64-amd64-xl-win 1 xen-build-check(1) blocked n/a test-amd64-amd64-xl 1 xen-build-check(1) blocked n/a test-i386-i386-xl-win 1 xen-build-check(1) blocked n/a test-i386-i386-win 1 xen-build-check(1) blocked n/a version targeted for testing: xen 0312575dc35e baseline version: xen 0312575dc35e jobs: build-amd64 pass build-i386 pass build-amd64-oldkern pass build-i386-oldkern pass build-amd64-pvops fail build-i386-pvops fail test-amd64-amd64-xl blocked test-amd64-i386-xl blocked test-i386-i386-xl blocked test-amd64-i386-rhel6hvm-amd blocked test-amd64-i386-xl-credit2 blocked test-amd64-amd64-xl-pcipt-intel blocked test-amd64-i386-rhel6hvm-intel blocked test-amd64-i386-xl-multivcpu blocked test-amd64-amd64-pair blocked test-amd64-i386-pair blocked test-i386-i386-pair blocked test-amd64-amd64-pv blocked test-amd64-i386-pv blocked test-i386-i386-pv blocked test-amd64-amd64-xl-sedf blocked test-amd64-i386-win-vcpus1 blocked test-amd64-i386-xl-win-vcpus1 blocked test-amd64-amd64-win blocked test-amd64-i386-win blocked test-i386-i386-win blocked test-amd64-amd64-xl-win blocked test-i386-i386-xl-win blocked ------------------------------------------------------------ sg-report-flight on woking.cam.xci-test.com logs: /home/xc_osstest/logs images: /home/xc_osstest/images Logs, config files, etc. are available at http://www.chiark.greenend.org.uk/~xensrcts/logs Test harness code can be found at http://xenbits.xensource.com/gitweb?p=osstest.git;a=summary Published tested tree is already up to date. _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel From xen-devel-bounces@lists.xensource.com Sat Sep 10 03:28:34 2011 Return-path: Envelope-to: www-data@lists.xensource.com Delivery-date: Sat, 10 Sep 2011 03:28:34 -0700 Received: from localhost ([127.0.0.1] helo=lists.colo.xensource.com) by lists.xensource.com with esmtp (Exim 4.43) id 1R2Kna-0002JL-Bw; Sat, 10 Sep 2011 03:28:34 -0700 Received: from mail21.messagelabs.com ([85.158.143.35]) by lists.xensource.com with esmtp (Exim 4.43) id 1R2Kmz-00026y-EW for xen-devel@lists.xensource.com; Sat, 10 Sep 2011 03:27:57 -0700 X-Env-Sender: pasik@iki.fi X-Msg-Ref: server-5.tower-21.messagelabs.com!1315650441!47599592!1 X-Originating-IP: [192.89.123.25] X-StarScan-Version: 6.3.6; banners=-,-,- X-VirusChecked: Checked Received: (qmail 23390 invoked from network); 10 Sep 2011 10:27:22 -0000 Received: from smtp.tele.fi (HELO smtp.tele.fi) (192.89.123.25) by server-5.tower-21.messagelabs.com with DHE-RSA-AES256-SHA encrypted SMTP; 10 Sep 2011 10:27:22 -0000 X-Originating-Ip: [194.89.68.22] Received: from ydin.reaktio.net (reaktio.net [194.89.68.22]) by smtp.tele.fi (Postfix) with ESMTP id 7AEA32A40; Sat, 10 Sep 2011 13:27:53 +0300 (EEST) Received: by ydin.reaktio.net (Postfix, from userid 1001) id 53FEF20057; Sat, 10 Sep 2011 13:27:53 +0300 (EEST) Date: Sat, 10 Sep 2011 13:27:53 +0300 From: Pasi =?iso-8859-1?Q?K=E4rkk=E4inen?= To: David TECHER Subject: Re: Re : Re : Re : Re : [Xen-devel] Re: Patches for VGA-Passthrough XEN 4.2 unstable Message-ID: <20110910102753.GA12984@reaktio.net> References: <1315382742268-4777689.post@n5.nabble.com> <1315389138.56652.YahooMailNeo@web29801.mail.ird.yahoo.com> <1315398360680-4778339.post@n5.nabble.com> <1315401901083-4778494.post@n5.nabble.com> <1315403644525-4778586.post@n5.nabble.com> <1315405372.87224.YahooMailNeo@web29801.mail.ird.yahoo.com> <1315405921936-4778727.post@n5.nabble.com> <1315408931610-4778925.post@n5.nabble.com> <1315554847212-4785386.post@n5.nabble.com> <1315598210.99532.YahooMailNeo@web29815.mail.ird.yahoo.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <1315598210.99532.YahooMailNeo@web29815.mail.ird.yahoo.com> User-Agent: Mutt/1.5.18 (2008-05-17) Cc: komkon555 , "xen-devel@lists.xensource.com" X-BeenThere: xen-devel@lists.xensource.com X-Mailman-Version: 2.1.5 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xensource.com Errors-To: xen-devel-bounces@lists.xensource.com On Fri, Sep 09, 2011 at 08:56:50PM +0100, David TECHER wrote: > Please have a look on http://wiki.xensource.com/xenwiki/VTdHowTo. And in general: http://wiki.xen.org/xenwiki/XenPCIpassthrough -- Pasi _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel From xen-users-bounces@lists.xensource.com Sat Sep 10 03:33:30 2011 Return-path: Envelope-to: www-data@lists.xensource.com Delivery-date: Sat, 10 Sep 2011 03:33:30 -0700 Received: from localhost ([127.0.0.1] helo=lists.colo.xensource.com) by lists.xensource.com with esmtp (Exim 4.43) id 1R2KsM-0002uW-1K; Sat, 10 Sep 2011 03:33:30 -0700 Received: from mail182.messagelabs.com ([85.158.139.83]) by lists.xensource.com with esmtp (Exim 4.43) id 1R2KrP-0002Zp-Nk; Sat, 10 Sep 2011 03:32:32 -0700 X-Env-Sender: pasik@iki.fi X-Msg-Ref: server-3.tower-182.messagelabs.com!1315650747!14999821!1 X-Originating-IP: [192.89.123.25] X-StarScan-Version: 6.3.6; banners=-,-,- X-VirusChecked: Checked Received: (qmail 13603 invoked from network); 10 Sep 2011 10:32:27 -0000 Received: from smtp.tele.fi (HELO smtp.tele.fi) (192.89.123.25) by server-3.tower-182.messagelabs.com with DHE-RSA-AES256-SHA encrypted SMTP; 10 Sep 2011 10:32:27 -0000 X-Originating-Ip: [194.89.68.22] Received: from ydin.reaktio.net (reaktio.net [194.89.68.22]) by smtp.tele.fi (Postfix) with ESMTP id 907441AC3; Sat, 10 Sep 2011 13:32:25 +0300 (EEST) Received: by ydin.reaktio.net (Postfix, from userid 1001) id 7515A20057; Sat, 10 Sep 2011 13:32:25 +0300 (EEST) Date: Sat, 10 Sep 2011 13:32:25 +0300 From: Pasi =?iso-8859-1?Q?K=E4rkk=E4inen?= To: Todd Deshane Subject: Re: [Xen-devel] Re: [Xen-users] xen 4.1.1 missing veth0 <--> vif0.0 pairs Message-ID: <20110910103225.GB12984@reaktio.net> References: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.18 (2008-05-17) Cc: xen-devel@lists.xensource.com, Shriganesh Shintre , Xen-users@lists.xensource.com X-BeenThere: xen-users@lists.xensource.com X-Mailman-Version: 2.1.5 Precedence: list List-Id: Xen user discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-users-bounces@lists.xensource.com Errors-To: xen-users-bounces@lists.xensource.com On Fri, Sep 09, 2011 at 09:29:22PM -0400, Todd Deshane wrote: > On Fri, Sep 9, 2011 at 8:32 PM, Shriganesh Shintre > wrote: > > Hi, > > > > I am using Xen 4.1.1 with Linux 3.0.1 kernel. Previously (Xen 3.4.4 and > > linux kernel 2.6.18) Xen by default created veth0 <--> vif0.0 pair in dom0. > > With Xen 4.1.1 these pairs are missing in dom0. > > Using command 'ip link add type veth' I can create veth0 and veth1 but > > vif0.0 is still missing in dom0. (When new domU created I can see vif1.x > > created) > > Could you please help me with understanding following things > > 1) Is veth is replaced by something? and if yes what is it? > > 2) How to create veth0 <--> vif0.0 pairs? Or how to create vif0.x > > interfaces? > > 3) In which version of Xen these changes regarding veth - vif0.0 are made? > > > > I'm not sure what you are trying to do exactly, but I would recommend > taking a look at: > http://wiki.xensource.com/xenwiki/MigrationGuideToXen4.1%2B > > Guest networking/bridging should now be handled by the distro and not > with the xend network scripts anymore. > Yep, see the end of: http://wiki.xen.org/xenwiki/XenBestPractices which has a link to: http://wiki.xen.org/xenwiki/HostConfiguration/Networking veth0 <-> vif0.0 was just a local loopback in dom0, nothing Xen specific in it really. You can get the same behaviour by creating, say, dummy0, and use that.. (if you really want that behaviour). -- Pasi _______________________________________________ Xen-users mailing list Xen-users@lists.xensource.com http://lists.xensource.com/xen-users From xen-devel-bounces@lists.xensource.com Sat Sep 10 11:10:07 2011 Return-path: Envelope-to: www-data@lists.xensource.com Delivery-date: Sat, 10 Sep 2011 11:10:07 -0700 Received: from localhost ([127.0.0.1] helo=lists.colo.xensource.com) by lists.xensource.com with esmtp (Exim 4.43) id 1R2S0D-0005Lb-Bv; Sat, 10 Sep 2011 11:10:06 -0700 Received: from mail182.messagelabs.com ([85.158.139.83]) by lists.xensource.com with esmtp (Exim 4.43) id 1R2Rz9-00058P-Kk for xen-devel@lists.xensource.com; Sat, 10 Sep 2011 11:09:00 -0700 X-Env-Sender: BATV+0de5a6ec783e6ea0252b+2939+infradead.org+hch@bombadil.s rs.infradead.org X-Msg-Ref: server-12.tower-182.messagelabs.com!1315678135!17678280!1 X-Originating-IP: [173.166.109.252] X-StarScan-Version: 6.3.6; banners=-,-,- X-VirusChecked: Checked Received: (qmail 9164 invoked from network); 10 Sep 2011 18:08:56 -0000 Received: from 173-166-109-252-newengland.hfc.comcastbusiness.net (HELO bombadil.infradead.org) (173.166.109.252) by server-12.tower-182.messagelabs.com with DHE-RSA-AES256-SHA encrypted SMTP; 10 Sep 2011 18:08:56 -0000 Received: from hch by bombadil.infradead.org with local (Exim 4.76 #1 (Red Hat Linux)) id 1R2Ryz-0002Yx-9w; Sat, 10 Sep 2011 18:08:49 +0000 Date: Sat, 10 Sep 2011 14:08:49 -0400 From: Christoph Hellwig To: Konrad Rzeszutek Wilk Message-ID: <20110910180849.GA6621@infradead.org> References: <1315593060-20031-1-git-send-email-konrad.wilk@oracle.com> <1315593060-20031-2-git-send-email-konrad.wilk@oracle.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <1315593060-20031-2-git-send-email-konrad.wilk@oracle.com> User-Agent: Mutt/1.5.21 (2010-09-15) X-SRS-Rewrite: SMTP reverse-path rewritten from by bombadil.infradead.org See http://www.infradead.org/rpr.html Cc: axboe@kernel.dk, xen-devel@lists.xensource.com, linux-kernel@vger.kernel.org, JBeulich@novell.com, jeremy.fitzhardinge@citrix.com Subject: [Xen-devel] Re: [PATCH 1/3] xen/blk[front|back]: Use the full FLUSH | FUA instead of just FLUSH. X-BeenThere: xen-devel@lists.xensource.com X-Mailman-Version: 2.1.5 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xensource.com Errors-To: xen-devel-bounces@lists.xensource.com On Fri, Sep 09, 2011 at 02:30:59PM -0400, Konrad Rzeszutek Wilk wrote: > During a FLUSH we can pass sector number that we want to > have flushed - which is what FUA requests are. No, that is not the case. REQ_FLUSH without data -> pure flush REQ_FLUSH with data -> preflush plus write REQ_FUA -> write and ranged postflush _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel From xen-devel-bounces@lists.xensource.com Sat Sep 10 13:52:00 2011 Return-path: Envelope-to: www-data@lists.xensource.com Delivery-date: Sat, 10 Sep 2011 13:52:00 -0700 Received: from localhost ([127.0.0.1] helo=lists.colo.xensource.com) by lists.xensource.com with esmtp (Exim 4.43) id 1R2UWs-0000Ht-DZ; Sat, 10 Sep 2011 13:51:58 -0700 Received: from mail174.messagelabs.com ([85.158.138.51]) by lists.xensource.com with smtp (Exim 4.43) id 1R2UW2-00005J-IJ for xen-devel@lists.xensource.com; Sat, 10 Sep 2011 13:51:08 -0700 X-Env-Sender: anthony@overnetdata.com X-Msg-Ref: server-6.tower-174.messagelabs.com!1315687863!28827548!1 X-Originating-IP: [81.137.131.225] X-StarScan-Version: 6.3.6; banners=-,-,- X-VirusChecked: Checked Received: (qmail 31722 invoked from network); 10 Sep 2011 20:51:03 -0000 Received: from host81-137-131-225.in-addr.btopenworld.com (HELO zimbra.overnetdata.com) (81.137.131.225) by server-6.tower-174.messagelabs.com with SMTP; 10 Sep 2011 20:51:03 -0000 Received: from localhost (localhost.localdomain [127.0.0.1]) by zimbra.overnetdata.com (Postfix) with ESMTP id 7315616157D; Sat, 10 Sep 2011 21:50:53 +0100 (BST) X-Virus-Scanned: amavisd-new at overnetdata.com Received: from zimbra.overnetdata.com ([127.0.0.1]) by localhost (zimbra.overnetdata.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id O0N-42SuuS3X; Sat, 10 Sep 2011 21:50:52 +0100 (BST) Received: from [192.168.2.100] (82-68-241-78.dsl.in-addr.zen.co.uk [82.68.241.78]) by zimbra.overnetdata.com (Postfix) with ESMTPSA id 4724A161575; Sat, 10 Sep 2011 21:50:52 +0100 (BST) Message-ID: <4E6BCDA9.3030700@overnetdata.com> Date: Sat, 10 Sep 2011 21:50:49 +0100 From: Anthony Wright User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:6.0.2) Gecko/20110902 Thunderbird/6.0.2 MIME-Version: 1.0 To: Konrad Rzeszutek Wilk Subject: Re: [Xen-devel] VM hangs during boot on 3.0.4 dom0 kernel, works on alternative hardware References: <4E64A4F4.1040402@overnetdata.com> <20110906161638.GB5264@dumpdata.com> In-Reply-To: <20110906161638.GB5264@dumpdata.com> X-Enigmail-Version: 1.3.1 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: "xen-devel@lists.xensource.com" X-BeenThere: xen-devel@lists.xensource.com X-Mailman-Version: 2.1.5 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xensource.com Errors-To: xen-devel-bounces@lists.xensource.com On 06/09/2011 17:16, Konrad Rzeszutek Wilk wrote: > On Mon, Sep 05, 2011 at 11:31:16AM +0100, Anthony Wright wrote: >> I have two machines with identical Dom0's and DomUs, but different >> hardware. The Dom0 has a patch which I produced myself based on the "Re: >> [Xen-devel] Kernel bug from 3.0 (was phy disks and vifs timing out in >> DomU)" thread. The patch calls vmalloc_sync_all after every >> alloc_vm_area, and I realise this isn't the best solution, but it >> allowed me to move forward. > >> The patch fixes the problem I had on one machine, so that now the VMs >> boot correctly, but I have another system with an identical setup >> (identical Dom0 & DomU kernels, identical startup for DomU) and the VM >> fails to start. I have attached a copy of the console log from the good >> VM and the bad VM. > And what does the dom0 and xen hypervisor log give you? > > It looks to be hanging at identifying the CPU - is the hardware > quite different from one setup to another? Have you toyed with > using the cpuid flag in the guest to mimic the lowest CPU type? I've found a solution to my problem. The PV DomU was running a 32 bit linux kernel version 2.6.30.1. I hoped that a new kernel would be able to handle to CPU more effectively, and so I upgraded my DomU kernel to 3.0.4, and now the DomU boots. This solves the problem for me, but I'm slightly concerned that my original kernel wouldn't work with this CPU (the CPU type for the kernel builds is set to Pentium Pro). I'll try the 2.6.30.1 kernel on bare metal on monday to try to see if this is a xen/Dom0 kernel issue or a CPU/DomU issue. Anthony _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel From xen-devel-bounces@lists.xensource.com Sat Sep 10 15:41:50 2011 Return-path: Envelope-to: www-data@lists.xensource.com Delivery-date: Sat, 10 Sep 2011 15:41:50 -0700 Received: from localhost ([127.0.0.1] helo=lists.colo.xensource.com) by lists.xensource.com with esmtp (Exim 4.43) id 1R2WFC-0004OJ-M4; Sat, 10 Sep 2011 15:41:50 -0700 Received: from mail182.messagelabs.com ([85.158.139.83]) by lists.xensource.com with smtp (Exim 4.43) id 1R2WEg-0004CZ-D7 for xen-devel@lists.xensource.com; Sat, 10 Sep 2011 15:41:19 -0700 X-Env-Sender: gcvxd-xen-devel@m.gmane.org X-Msg-Ref: server-8.tower-182.messagelabs.com!1315694475!17850183!1 X-Originating-IP: [80.91.229.12] X-StarScan-Version: 6.3.6; banners=-,-,- X-VirusChecked: Checked Received: (qmail 21035 invoked from network); 10 Sep 2011 22:41:15 -0000 Received: from lo.gmane.org (HELO lo.gmane.org) (80.91.229.12) by server-8.tower-182.messagelabs.com with SMTP; 10 Sep 2011 22:41:15 -0000 Received: from list by lo.gmane.org with local (Exim 4.69) (envelope-from ) id 1R2WEc-0000Uo-Lf for xen-devel@lists.xensource.com; Sun, 11 Sep 2011 00:41:14 +0200 Received: from dslb-178-009-021-201.pools.arcor-ip.net ([178.9.21.201]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Sun, 11 Sep 2011 00:41:14 +0200 Received: from sven.koehler by dslb-178-009-021-201.pools.arcor-ip.net with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Sun, 11 Sep 2011 00:41:14 +0200 X-Injected-Via-Gmane: http://gmane.org/ To: xen-devel@lists.xensource.com From: =?ISO-8859-15?Q?Sven_K=F6hler?= Date: Sun, 11 Sep 2011 00:43:18 +0200 Lines: 10 Message-ID: Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-15 Content-Transfer-Encoding: 7bit X-Complaints-To: usenet@dough.gmane.org X-Gmane-NNTP-Posting-Host: dslb-178-009-021-201.pools.arcor-ip.net User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:6.0) Gecko/20110829 Thunderbird/6.0 X-Enigmail-Version: 1.3 Subject: [Xen-devel] 3.0.4 and 3.1-rc4 based dom0 won't boot with acpi=off X-BeenThere: xen-devel@lists.xensource.com X-Mailman-Version: 2.1.5 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xensource.com Errors-To: xen-devel-bounces@lists.xensource.com Hi, when using acpi=off in the kernel or xen command line, the system won't boot. On real hardware, I saw a few interrupt related warnings from the usb drivers. The system then seemed to lock up when trying to do I/O via AHCI. Same in virtualbox. System won't come up. Regards, Sven _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel From xen-devel-bounces@lists.xensource.com Sat Sep 10 17:29:22 2011 Return-path: Envelope-to: www-data@lists.xensource.com Delivery-date: Sat, 10 Sep 2011 17:29:22 -0700 Received: from localhost ([127.0.0.1] helo=lists.colo.xensource.com) by lists.xensource.com with esmtp (Exim 4.43) id 1R2XvG-00074Y-DI; Sat, 10 Sep 2011 17:29:22 -0700 Received: from mail21.messagelabs.com ([85.158.143.35]) by lists.xensource.com with esmtp (Exim 4.43) id 1R2XuM-0006s5-1z for xen-devel@lists.xensource.com; Sat, 10 Sep 2011 17:28:28 -0700 X-Env-Sender: konrad@oracle.com X-Msg-Ref: server-10.tower-21.messagelabs.com!1315700887!53633421!1 X-Originating-IP: [148.87.113.117] X-StarScan-Version: 6.3.6; banners=-,-,- X-VirusChecked: Checked Received: (qmail 18629 invoked from network); 11 Sep 2011 00:28:08 -0000 Received: from rcsinet15.oracle.com (HELO rcsinet15.oracle.com) (148.87.113.117) by server-10.tower-21.messagelabs.com with DHE-RSA-AES256-SHA encrypted SMTP; 11 Sep 2011 00:28:08 -0000 Received: from rtcsinet22.oracle.com (rtcsinet22.oracle.com [66.248.204.30]) by rcsinet15.oracle.com (Switch-3.4.4/Switch-3.4.4) with ESMTP id p8B0SIDW025726 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Sun, 11 Sep 2011 00:28:20 GMT Received: from acsmt358.oracle.com (acsmt358.oracle.com [141.146.40.158]) by rtcsinet22.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id p8B0SHca024411 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sun, 11 Sep 2011 00:28:17 GMT Received: from abhmt116.oracle.com (abhmt116.oracle.com [141.146.116.68]) by acsmt358.oracle.com (8.12.11.20060308/8.12.11) with ESMTP id p8B0SBKq021901; Sat, 10 Sep 2011 19:28:11 -0500 Received: from oracle.com (/209.6.55.207) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Sat, 10 Sep 2011 17:28:11 -0700 Received: by oracle.com (Postfix, from userid 1000) id 17735135F; Sat, 10 Sep 2011 20:28:08 -0400 (EDT) Date: Sat, 10 Sep 2011 20:28:07 -0400 From: Konrad Rzeszutek Wilk To: Sven =?iso-8859-1?Q?K=F6hler?= Subject: Re: [Xen-devel] 3.0.4 and 3.1-rc4 based dom0 won't boot with acpi=off Message-ID: <20110911002807.GA9989@oracle.com> References: MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.21 (2010-09-15) Content-Transfer-Encoding: quoted-printable X-Source-IP: rtcsinet22.oracle.com [66.248.204.30] X-CT-RefId: str=0001.0A090201.4E6C00A4.0082,ss=1,re=0.000,fgs=0 Cc: xen-devel@lists.xensource.com X-BeenThere: xen-devel@lists.xensource.com X-Mailman-Version: 2.1.5 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xensource.com Errors-To: xen-devel-bounces@lists.xensource.com On Sun, Sep 11, 2011 at 12:43:18AM +0200, Sven K=F6hler wrote: > Hi, >=20 > when using acpi=3Doff in the kernel or xen command line, the system won= 't > boot. On real hardware, I saw a few interrupt related warnings from the > usb drivers. The system then seemed to lock up when trying to do I/O vi= a > AHCI. Same in virtualbox. System won't come up. Not surprised. Without the ACPI we can't find parse the interrupt table, so you don't get any interrupts. This is result of the reboot issue you have been seeing with your box? You might want to try some parameters on the Xen line to alter how it is suppose to reboot. /* * reboot=3Db[ios] | t[riple] | k[bd] | n[o] [, [w]arm | [c]old] * warm Don't set the cold reboot flag * cold Set the cold reboot flag * bios Reboot by jumping through the BIOS (only for X86_32) * triple Force a triple fault (init) * kbd Use the keyboard controller. cold reset (default) * acpi Use the RESET_REG in the FADT */ _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel From xen-devel-bounces@lists.xensource.com Sat Sep 10 17:34:49 2011 Return-path: Envelope-to: www-data@lists.xensource.com Delivery-date: Sat, 10 Sep 2011 17:34:49 -0700 Received: from localhost ([127.0.0.1] helo=lists.colo.xensource.com) by lists.xensource.com with esmtp (Exim 4.43) id 1R2Y0X-0007W2-Ri; Sat, 10 Sep 2011 17:34:49 -0700 Received: from mail174.messagelabs.com ([85.158.138.51]) by lists.xensource.com with esmtp (Exim 4.43) id 1R2Xzo-0007JW-UB for xen-devel@lists.xensource.com; Sat, 10 Sep 2011 17:34:05 -0700 X-Env-Sender: konrad@oracle.com X-Msg-Ref: server-10.tower-174.messagelabs.com!1315701240!30964191!1 X-Originating-IP: [141.146.126.227] X-StarScan-Version: 6.3.6; banners=-,-,- X-VirusChecked: Checked Received: (qmail 28077 invoked from network); 11 Sep 2011 00:34:01 -0000 Received: from acsinet15.oracle.com (HELO acsinet15.oracle.com) (141.146.126.227) by server-10.tower-174.messagelabs.com with DHE-RSA-AES256-SHA encrypted SMTP; 11 Sep 2011 00:34:01 -0000 Received: from acsinet22.oracle.com (acsinet22.oracle.com [141.146.126.238]) by acsinet15.oracle.com (Switch-3.4.4/Switch-3.4.4) with ESMTP id p8B0XJEC022592 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Sun, 11 Sep 2011 00:33:20 GMT Received: from acsmt357.oracle.com (acsmt357.oracle.com [141.146.40.157]) by acsinet22.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id p8B0XIIX015335 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sun, 11 Sep 2011 00:33:18 GMT Received: from abhmt109.oracle.com (abhmt109.oracle.com [141.146.116.61]) by acsmt357.oracle.com (8.12.11.20060308/8.12.11) with ESMTP id p8B0XBTu018432; Sat, 10 Sep 2011 19:33:11 -0500 Received: from oracle.com (/209.6.55.207) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Sat, 10 Sep 2011 17:33:11 -0700 Received: by oracle.com (Postfix, from userid 1000) id BFC961211; Sat, 10 Sep 2011 20:33:06 -0400 (EDT) Date: Sat, 10 Sep 2011 20:33:06 -0400 From: Konrad Rzeszutek Wilk To: Christoph Hellwig Message-ID: <20110911003306.GB9989@oracle.com> References: <1315593060-20031-1-git-send-email-konrad.wilk@oracle.com> <1315593060-20031-2-git-send-email-konrad.wilk@oracle.com> <20110910180849.GA6621@infradead.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20110910180849.GA6621@infradead.org> User-Agent: Mutt/1.5.21 (2010-09-15) X-Source-IP: acsinet22.oracle.com [141.146.126.238] X-Auth-Type: Internal IP X-CT-RefId: str=0001.0A090206.4E6C01D1.0072:SCFMA922111,ss=1,re=-4.000,fgs=0 Cc: axboe@kernel.dk, xen-devel@lists.xensource.com, linux-kernel@vger.kernel.org, JBeulich@novell.com, jeremy.fitzhardinge@citrix.com Subject: [Xen-devel] Re: [PATCH 1/3] xen/blk[front|back]: Use the full FLUSH | FUA instead of just FLUSH. X-BeenThere: xen-devel@lists.xensource.com X-Mailman-Version: 2.1.5 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xensource.com Errors-To: xen-devel-bounces@lists.xensource.com On Sat, Sep 10, 2011 at 02:08:49PM -0400, Christoph Hellwig wrote: > On Fri, Sep 09, 2011 at 02:30:59PM -0400, Konrad Rzeszutek Wilk wrote: > > During a FLUSH we can pass sector number that we want to > > have flushed - which is what FUA requests are. > > No, that is not the case. > > REQ_FLUSH without data -> pure flush > REQ_FLUSH with data -> preflush plus write Excellent. So we have been doing it right all along. > REQ_FUA -> write and ranged postflush Ah, somehow I was thinking that you can't write data with a REQ_FLUSH, but that is nonsense as the block/blk-flush.c explains in great details. Will drop this patch - and thanks for clarifying it! _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel From xen-devel-bounces@lists.xensource.com Sat Sep 10 17:43:00 2011 Return-path: Envelope-to: www-data@lists.xensource.com Delivery-date: Sat, 10 Sep 2011 17:43:00 -0700 Received: from localhost ([127.0.0.1] helo=lists.colo.xensource.com) by lists.xensource.com with esmtp (Exim 4.43) id 1R2Y8S-0000da-9N; Sat, 10 Sep 2011 17:43:00 -0700 Received: from mail21.messagelabs.com ([85.158.143.35]) by lists.xensource.com with esmtp (Exim 4.43) id 1R2Y7u-0000RK-7J for xen-devel@lists.xensource.com; Sat, 10 Sep 2011 17:42:26 -0700 X-Env-Sender: sven.koehler@gmail.com X-Msg-Ref: server-9.tower-21.messagelabs.com!1315701699!47935630!1 X-Originating-IP: [209.85.161.43] X-StarScan-Version: 6.3.6; banners=-,-,- X-VirusChecked: Checked Received: (qmail 16465 invoked from network); 11 Sep 2011 00:41:40 -0000 Received: from mail-fx0-f43.google.com (HELO mail-fx0-f43.google.com) (209.85.161.43) by server-9.tower-21.messagelabs.com with RC4-SHA encrypted SMTP; 11 Sep 2011 00:41:40 -0000 Received: by fxh19 with SMTP id 19so1041984fxh.30 for ; Sat, 10 Sep 2011 17:42:22 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:x-enigmail-version:content-type; bh=hfvLv6Qxy0/6pAC6zln36dV4M+3s6Fxs59EafmH3ngI=; b=XnuWSm05b5HN0l4UVZ2Miy4NRDjjEjsiJtt63zbe8IMaFNX4mh1bvXRkGDTUmjVomD xnUdeK/j+JBOYthdFc+icSO3T1XvBRppybCzjDNAwnsPmDYLgV/ZcZR9uxUq1lFtphE/ Q9zlsdOC9fRQvm6rOEdSfwZ/ld/zxlcnWhoxU= Received: by 10.223.51.216 with SMTP id e24mr1986445fag.105.1315701742697; Sat, 10 Sep 2011 17:42:22 -0700 (PDT) Received: from [10.1.1.24] (dslb-178-009-021-201.pools.arcor-ip.net [178.9.21.201]) by mx.google.com with ESMTPS id q23sm5319860fae.1.2011.09.10.17.42.21 (version=SSLv3 cipher=OTHER); Sat, 10 Sep 2011 17:42:21 -0700 (PDT) Message-ID: <4E6C0473.8090905@gmail.com> Date: Sun, 11 Sep 2011 02:44:35 +0200 From: =?ISO-8859-1?Q?Sven_K=F6hler?= User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:6.0) Gecko/20110829 Thunderbird/6.0 MIME-Version: 1.0 To: Konrad Rzeszutek Wilk Subject: Re: [Xen-devel] 3.0.4 and 3.1-rc4 based dom0 won't boot with acpi=off References: <20110911002807.GA9989@oracle.com> In-Reply-To: <20110911002807.GA9989@oracle.com> X-Enigmail-Version: 1.3 Cc: xen-devel@lists.xensource.com X-BeenThere: xen-devel@lists.xensource.com X-Mailman-Version: 2.1.5 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0853529892==" Sender: xen-devel-bounces@lists.xensource.com Errors-To: xen-devel-bounces@lists.xensource.com This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --===============0853529892== Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="------------enigC0AA432E925193931C5D6F0B" This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enigC0AA432E925193931C5D6F0B Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Am 11.09.2011 02:28, schrieb Konrad Rzeszutek Wilk: > On Sun, Sep 11, 2011 at 12:43:18AM +0200, Sven K=F6hler wrote: >> Hi, >> >> when using acpi=3Doff in the kernel or xen command line, the system wo= n't >> boot. On real hardware, I saw a few interrupt related warnings from th= e >> usb drivers. The system then seemed to lock up when trying to do I/O v= ia >> AHCI. Same in virtualbox. System won't come up. >=20 > Not surprised. Without the ACPI we can't find parse the interrupt table= , > so you don't get any interrupts. Thanks for explaining. Now what about the future? Will there be some solution for the acpi=3Doff case? I'm a bit confused, since your words don't sound like there is a way to boot with acpi=3Doff. But other dom0 kernels actually boot with acpi=3Dof= f. So after all, some other way for setting up interrupts seems to exist. > This is result of the reboot issue you have been seeing with your box? Yes. > You might want to try some parameters on the Xen line to alter how > it is suppose to reboot. >=20 > /* > * reboot=3Db[ios] | t[riple] | k[bd] | n[o] [, [w]arm | [c]old] Thanks for the list. I guess, both reboot=3Dbios and reboot=3Db is accepted? BTW: "no" is missing in the list below. acpi is missing in the list above. And actually what's the source for list? (I never find any documentation about the hypervisor options, which is pretty frustrating sometimes) > * warm Don't set the cold reboot flag > * cold Set the cold reboot flag > * bios Reboot by jumping through the BIOS (only for X86_32) > * triple Force a triple fault (init) > * kbd Use the keyboard controller. cold reset (default) > * acpi Use the RESET_REG in the FADT > */ So in fact, xen is doing the reboot, and not the dom0 kernel, right? (Some people have claimed otherwise) Could you imagine to adapt xen's reboot code to the one of linux 3.0 (which was tweaked quite a lot for maximum compatibility) Regards, Sven --------------enigC0AA432E925193931C5D6F0B Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.17 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAk5sBHMACgkQ7Ww7FjRBE4AW1gCaAqrrjYM6wNbvTvixXJgj7Ilg AmsAnA0lahX3O+yyLZfLPAagwoIWWs9U =OlIk -----END PGP SIGNATURE----- --------------enigC0AA432E925193931C5D6F0B-- --===============0853529892== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel --===============0853529892==-- From xen-devel-bounces@lists.xensource.com Sat Sep 10 17:53:57 2011 Return-path: Envelope-to: www-data@lists.xensource.com Delivery-date: Sat, 10 Sep 2011 17:53:57 -0700 Received: from localhost ([127.0.0.1] helo=lists.colo.xensource.com) by lists.xensource.com with esmtp (Exim 4.43) id 1R2YJ3-000191-Kz; Sat, 10 Sep 2011 17:53:57 -0700 Received: from mail27.messagelabs.com ([193.109.254.147]) by lists.xensource.com with smtp (Exim 4.43) id 1R2YId-0000ww-TB for xen-devel@lists.xensource.com; Sat, 10 Sep 2011 17:53:32 -0700 X-Env-Sender: gcvxd-xen-devel@m.gmane.org X-Msg-Ref: server-11.tower-27.messagelabs.com!1315702401!36895501!1 X-Originating-IP: [80.91.229.12] X-StarScan-Version: 6.3.6; banners=-,-,- X-VirusChecked: Checked Received: (qmail 7761 invoked from network); 11 Sep 2011 00:53:21 -0000 Received: from lo.gmane.org (HELO lo.gmane.org) (80.91.229.12) by server-11.tower-27.messagelabs.com with SMTP; 11 Sep 2011 00:53:21 -0000 Received: from list by lo.gmane.org with local (Exim 4.69) (envelope-from ) id 1R2YIZ-0007JE-CP for xen-devel@lists.xensource.com; Sun, 11 Sep 2011 02:53:27 +0200 Received: from dslb-178-009-021-201.pools.arcor-ip.net ([178.9.21.201]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Sun, 11 Sep 2011 02:53:27 +0200 Received: from sven.koehler by dslb-178-009-021-201.pools.arcor-ip.net with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Sun, 11 Sep 2011 02:53:27 +0200 X-Injected-Via-Gmane: http://gmane.org/ To: xen-devel@lists.xensource.com From: =?UTF-8?B?U3ZlbiBLw7ZobGVy?= Date: Sun, 11 Sep 2011 02:55:24 +0200 Lines: 21 Message-ID: References: <4E694CFB.1060203@citrix.com> <4E6A0034.10706@citrix.com> <4E6A1549.90806@modelnine.org> Mime-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit X-Complaints-To: usenet@dough.gmane.org X-Gmane-NNTP-Posting-Host: dslb-178-009-021-201.pools.arcor-ip.net User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:6.0) Gecko/20110829 Thunderbird/6.0 In-Reply-To: <4E6A1549.90806@modelnine.org> X-Enigmail-Version: 1.3 Subject: [Xen-devel] Re: computer stalls instead of reboot X-BeenThere: xen-devel@lists.xensource.com X-Mailman-Version: 2.1.5 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xensource.com Errors-To: xen-devel-bounces@lists.xensource.com Am 09.09.2011 15:31, schrieb Heiko Wundram: > Am 09.09.2011 14:55, schrieb Sven Köhler: >> > > Without knowing much of the previous discussion: is this related to > Hetzner-servers (from seeing the mainboard type, I can only guess that > it's a machine from the "new" Hetzner-series)? > > If that's the case, use: "acpi=off" on the Dom0-kernel commandline (I > use a Gentoo-adapted xen-sources-2.6.38 [rebased SuSE-Dom0-kernel]), > that should solve the reboot problems. In the wiki, I found the use of acpi=off in the xen command line. Well, I have tried acpi=off on the xen command line and/or the domß kernel command line. The kernel would refuse to boot (see the other thread I started). So to anyone who's using upstream kernels: don't even bother trying acpi=off Regards, Sven _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel From xen-devel-bounces@lists.xensource.com Sat Sep 10 18:03:11 2011 Return-path: Envelope-to: www-data@lists.xensource.com Delivery-date: Sat, 10 Sep 2011 18:03:11 -0700 Received: from localhost ([127.0.0.1] helo=lists.colo.xensource.com) by lists.xensource.com with esmtp (Exim 4.43) id 1R2YRy-0001eW-I0; Sat, 10 Sep 2011 18:03:10 -0700 Received: from mail216.messagelabs.com ([85.158.143.99]) by lists.xensource.com with smtp (Exim 4.43) id 1R2YP6-0001Pq-3I for xen-devel@lists.xensource.com; Sat, 10 Sep 2011 18:00:33 -0700 X-Env-Sender: gcvxd-xen-devel@m.gmane.org X-Msg-Ref: server-6.tower-216.messagelabs.com!1315702808!16545820!1 X-Originating-IP: [80.91.229.12] X-StarScan-Version: 6.3.6; banners=-,-,- X-VirusChecked: Checked Received: (qmail 518 invoked from network); 11 Sep 2011 01:00:08 -0000 Received: from lo.gmane.org (HELO lo.gmane.org) (80.91.229.12) by server-6.tower-216.messagelabs.com with SMTP; 11 Sep 2011 01:00:08 -0000 Received: from list by lo.gmane.org with local (Exim 4.69) (envelope-from ) id 1R2YOz-0000Cj-Dv for xen-devel@lists.xensource.com; Sun, 11 Sep 2011 03:00:05 +0200 Received: from dslb-178-009-021-201.pools.arcor-ip.net ([178.9.21.201]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Sun, 11 Sep 2011 03:00:05 +0200 Received: from sven.koehler by dslb-178-009-021-201.pools.arcor-ip.net with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Sun, 11 Sep 2011 03:00:05 +0200 X-Injected-Via-Gmane: http://gmane.org/ To: xen-devel@lists.xensource.com From: =?ISO-8859-15?Q?Sven_K=F6hler?= Date: Sun, 11 Sep 2011 02:57:58 +0200 Lines: 16 Message-ID: References: <4E694CFB.1060203@citrix.com> <4E6A0034.10706@citrix.com> Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-15 Content-Transfer-Encoding: 7bit X-Complaints-To: usenet@dough.gmane.org X-Gmane-NNTP-Posting-Host: dslb-178-009-021-201.pools.arcor-ip.net User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:6.0) Gecko/20110829 Thunderbird/6.0 In-Reply-To: <4E6A0034.10706@citrix.com> X-Enigmail-Version: 1.3 Subject: [Xen-devel] Re: computer stalls instead of reboot X-BeenThere: xen-devel@lists.xensource.com X-Mailman-Version: 2.1.5 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xensource.com Errors-To: xen-devel-bounces@lists.xensource.com Am 09.09.2011 14:01, schrieb Andrew Cooper: >>> As for the problem itself, do you have C states enabled in the BIOS? >>> This sounds similar to several errata published for the i7 series. >> I'm not sure how to tell whether C states are disabled/enabled. >> What would those BIOS options typically be called? > > That is too bios dependent to say for sure, but typically "C states" or > "deep sleep", with some intel ones going for "C1e" I found two BIOS options for C1E and C2, C3, etc. I disabled both options. So C-states should have been disabled. However, the issue reoccured. So it's not C-state related. Regards, Sven _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel From xen-devel-bounces@lists.xensource.com Sat Sep 10 18:45:08 2011 Return-path: Envelope-to: www-data@lists.xensource.com Delivery-date: Sat, 10 Sep 2011 18:45:08 -0700 Received: from localhost ([127.0.0.1] helo=lists.colo.xensource.com) by lists.xensource.com with esmtp (Exim 4.43) id 1R2Z6Z-0002kY-UP; Sat, 10 Sep 2011 18:45:07 -0700 Received: from mail27.messagelabs.com ([193.109.254.147]) by lists.xensource.com with esmtp (Exim 4.43) id 1R2Z5Z-0002Xv-Dc for xen-devel@lists.xensource.com; Sat, 10 Sep 2011 18:44:06 -0700 X-Env-Sender: Ian.Jackson@eu.citrix.com X-Msg-Ref: server-8.tower-27.messagelabs.com!1315705427!46074853!1 X-Originating-IP: [62.200.22.115] X-StarScan-Version: 6.3.6; banners=-,-,- X-VirusChecked: Checked Received: (qmail 29285 invoked from network); 11 Sep 2011 01:43:47 -0000 Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115) by server-8.tower-27.messagelabs.com with RC4-SHA encrypted SMTP; 11 Sep 2011 01:43:47 -0000 X-IronPort-AV: E=Sophos;i="4.68,362,1312156800"; d="scan'208";a="7711969" Received: from lonpmailmx01.citrite.net ([10.30.203.162]) by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5; 11 Sep 2011 01:44:01 +0000 Received: from woking.xci-test.com (10.80.248.135) by smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id 8.3.137.0; Sun, 11 Sep 2011 02:44:02 +0100 Received: from osstest by woking.xci-test.com with local (Exim 4.69) (envelope-from ) id 1R2Z5V-0006hP-GL; Sun, 11 Sep 2011 02:44:01 +0100 To: xen-devel@lists.xensource.com Message-ID: From: xen.org Date: Sun, 11 Sep 2011 02:44:01 +0100 MIME-Version: 1.0 Content-Type: text/plain Cc: ian.jackson@eu.citrix.com Subject: [Xen-devel] [xen-unstable test] 8871: tolerable FAIL X-BeenThere: xen-devel@lists.xensource.com X-Mailman-Version: 2.1.5 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xensource.com Errors-To: xen-devel-bounces@lists.xensource.com flight 8871 xen-unstable real [real] http://www.chiark.greenend.org.uk/~xensrcts/logs/8871/ Failures :-/ but no regressions. Tests which did not succeed, but are not blocking, including regressions (tests previously passed) regarded as allowable: test-amd64-amd64-xl-pcipt-intel 1 xen-build-check(1) blocked n/a test-amd64-i386-rhel6hvm-intel 1 xen-build-check(1) blocked n/a test-i386-i386-pv 1 xen-build-check(1) blocked n/a test-amd64-i386-pv 1 xen-build-check(1) blocked n/a test-amd64-amd64-pv 1 xen-build-check(1) blocked n/a test-i386-i386-xl 1 xen-build-check(1) blocked n/a test-amd64-i386-xl 1 xen-build-check(1) blocked n/a test-amd64-i386-xl-credit2 1 xen-build-check(1) blocked n/a test-amd64-i386-rhel6hvm-amd 1 xen-build-check(1) blocked n/a test-amd64-amd64-pair 1 xen-build-check(1) blocked n/a test-amd64-i386-pair 1 xen-build-check(1) blocked n/a test-i386-i386-pair 1 xen-build-check(1) blocked n/a build-amd64-pvops 4 kernel-build fail like 8870 build-i386-pvops 4 kernel-build fail like 8870 test-amd64-i386-xl-multivcpu 1 xen-build-check(1) blocked n/a test-amd64-amd64-xl-sedf 1 xen-build-check(1) blocked n/a test-amd64-i386-win-vcpus1 1 xen-build-check(1) blocked n/a test-amd64-i386-xl-win-vcpus1 1 xen-build-check(1) blocked n/a test-amd64-amd64-win 1 xen-build-check(1) blocked n/a test-amd64-i386-win 1 xen-build-check(1) blocked n/a test-amd64-amd64-xl-win 1 xen-build-check(1) blocked n/a test-amd64-amd64-xl 1 xen-build-check(1) blocked n/a test-i386-i386-xl-win 1 xen-build-check(1) blocked n/a test-i386-i386-win 1 xen-build-check(1) blocked n/a version targeted for testing: xen 0312575dc35e baseline version: xen 0312575dc35e jobs: build-amd64 pass build-i386 pass build-amd64-oldkern pass build-i386-oldkern pass build-amd64-pvops fail build-i386-pvops fail test-amd64-amd64-xl blocked test-amd64-i386-xl blocked test-i386-i386-xl blocked test-amd64-i386-rhel6hvm-amd blocked test-amd64-i386-xl-credit2 blocked test-amd64-amd64-xl-pcipt-intel blocked test-amd64-i386-rhel6hvm-intel blocked test-amd64-i386-xl-multivcpu blocked test-amd64-amd64-pair blocked test-amd64-i386-pair blocked test-i386-i386-pair blocked test-amd64-amd64-pv blocked test-amd64-i386-pv blocked test-i386-i386-pv blocked test-amd64-amd64-xl-sedf blocked test-amd64-i386-win-vcpus1 blocked test-amd64-i386-xl-win-vcpus1 blocked test-amd64-amd64-win blocked test-amd64-i386-win blocked test-i386-i386-win blocked test-amd64-amd64-xl-win blocked test-i386-i386-xl-win blocked ------------------------------------------------------------ sg-report-flight on woking.cam.xci-test.com logs: /home/xc_osstest/logs images: /home/xc_osstest/images Logs, config files, etc. are available at http://www.chiark.greenend.org.uk/~xensrcts/logs Test harness code can be found at http://xenbits.xensource.com/gitweb?p=osstest.git;a=summary Published tested tree is already up to date. _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel From xen-devel-bounces@lists.xensource.com Sun Sep 11 03:01:17 2011 Return-path: Envelope-to: www-data@lists.xensource.com Delivery-date: Sun, 11 Sep 2011 03:01:17 -0700 Received: from localhost ([127.0.0.1] helo=lists.colo.xensource.com) by lists.xensource.com with esmtp (Exim 4.43) id 1R2gqj-00055Q-CB; Sun, 11 Sep 2011 03:01:17 -0700 Received: from mail27.messagelabs.com ([193.109.254.147]) by lists.xensource.com with smtp (Exim 4.43) id 1R2gpt-0004sR-1t for xen-devel@lists.xensource.com; Sun, 11 Sep 2011 03:00:25 -0700 X-Env-Sender: avi@redhat.com X-Msg-Ref: server-10.tower-27.messagelabs.com!1315735197!35243566!1 X-Originating-IP: [209.132.183.28] X-StarScan-Version: 6.3.6; banners=-,-,- X-VirusChecked: Checked Received: (qmail 20290 invoked from network); 11 Sep 2011 09:59:58 -0000 Received: from mx1.redhat.com (HELO mx1.redhat.com) (209.132.183.28) by server-10.tower-27.messagelabs.com with SMTP; 11 Sep 2011 09:59:58 -0000 Received: from int-mx09.intmail.prod.int.phx2.redhat.com (int-mx09.intmail.prod.int.phx2.redhat.com [10.5.11.22]) by mx1.redhat.com (8.14.4/8.14.4) with ESMTP id p8B9xh0D010281 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Sun, 11 Sep 2011 05:59:43 -0400 Received: from balrog.usersys.redhat.com (dhcp-1-24.tlv.redhat.com [10.35.1.24]) by int-mx09.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP id p8B9xbYg028522; Sun, 11 Sep 2011 05:59:38 -0400 Message-ID: <4E6C8688.6090706@redhat.com> Date: Sun, 11 Sep 2011 12:59:36 +0300 From: Avi Kivity User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:6.0) Gecko/20110816 Thunderbird/6.0 MIME-Version: 1.0 To: Jeremy Fitzhardinge References: <1314996468.8255.0.camel@twins> <4E614FBD.2030509@goop.org> <20110906151408.GA7459@redhat.com> <4E66615E.8070806@goop.org> <20110906182758.GR5795@redhat.com> <4E66EF86.9070200@redhat.com> <20110907134411.GV5795@redhat.com> <4E678992.5050709@redhat.com> <20110907155657.GX5795@redhat.com> <4E679AF4.50209@redhat.com> <20110907165203.GQ6838@redhat.com> <4E67A551.4000502@redhat.com> <4E67A71A.5070903@goop.org> <4E67ACB6.40107@redhat.com> <4E67C15B.3000408@goop.org> <4E6873FE.3040603@redhat.com> <4E68FB64.9080308@goop.org> In-Reply-To: <4E68FB64.9080308@goop.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Scanned-By: MIMEDefang 2.68 on 10.5.11.22 Cc: Don Zickus , Marcelo Tosatti , Nick Piggin , KVM , Stefano Stabellini , Peter Zijlstra , the arch/x86 maintainers , Linux Kernel Mailing List , Andi Kleen , Jeremy Fitzhardinge , "H. Peter Anvin" , Ingo Molnar , Linus Torvalds , Xen Devel Subject: [Xen-devel] Re: [PATCH 08/13] xen/pvticketlock: disable interrupts while blocking X-BeenThere: xen-devel@lists.xensource.com X-Mailman-Version: 2.1.5 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xensource.com Errors-To: xen-devel-bounces@lists.xensource.com On 09/08/2011 08:29 PM, Jeremy Fitzhardinge wrote: > > I don't think it's that expensive, especially compared to the > > double-context-switch and vmexit of the spinner going to sleep. On > > AMD we do have to take an extra vmexit (on IRET) though. > > Fair enough - so if the vcpu blocks itself, it ends up being rescheduled > in the NMI handler, which then returns to the lock slowpath. And if its > a normal hlt, then you can also take interrupts if they're enabled while > spinning. Yes. To be clear, just execute 'hlt' and inherit the interrupt enable flag from the environment. > And if you get nested NMIs (since you can get multiple spurious kicks, > or from other NMI sources), then one NMI will get latched and any others > will get dropped? While we're in the NMI handler, any further NMIs will be collapsed and queued (so one NMI can be in service and just one other queued behind it). We can detect this condition by checking %rip on stack. > > > Well we could have a specialized sleep/wakeup hypercall pair like Xen, > > but I'd like to avoid it if at all possible. > > Yeah, that's something that just falls out of the existing event channel > machinery, so it isn't something that I specifically added. But it does > mean that you simply end up with a hypercall returning on kick, with no > real complexities. It also has to return on interrupt, MNI, INIT etc. "No real complexities" is a meaningless phrase on x86, though it is fertile ground for math puns. -- error compiling committee.c: too many arguments to function _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel From xen-devel-bounces@lists.xensource.com Sun Sep 11 05:18:16 2011 Return-path: Envelope-to: www-data@lists.xensource.com Delivery-date: Sun, 11 Sep 2011 05:18:16 -0700 Received: from localhost ([127.0.0.1] helo=lists.colo.xensource.com) by lists.xensource.com with esmtp (Exim 4.43) id 1R2izH-0001SR-9v; Sun, 11 Sep 2011 05:18:15 -0700 Received: from mail27.messagelabs.com ([193.109.254.147]) by lists.xensource.com with esmtp (Exim 4.43) id 1R2iy9-0001FY-8J for xen-devel@lists.xensource.com; Sun, 11 Sep 2011 05:17:06 -0700 X-Env-Sender: Ian.Campbell@eu.citrix.com X-Msg-Ref: server-11.tower-27.messagelabs.com!1315743413!36929366!1 X-Originating-IP: [66.165.176.63] X-StarScan-Version: 6.3.6; banners=-,-,- X-VirusChecked: Checked Received: (qmail 2905 invoked from network); 11 Sep 2011 12:16:55 -0000 Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63) by server-11.tower-27.messagelabs.com with RC4-SHA encrypted SMTP; 11 Sep 2011 12:16:55 -0000 X-IronPort-AV: E=Sophos;i="4.68,363,1312171200"; d="scan'208";a="162476956" Received: from ftlpmailmx02.citrite.net ([10.13.107.66]) by FTLPIPO02.CITRIX.COM with ESMTP/TLS/RC4-MD5; 11 Sep 2011 08:16:49 -0400 Received: from [127.0.0.1] (10.80.16.67) by smtprelay.citrix.com (10.13.107.66) with Microsoft SMTP Server id 8.3.137.0; Sun, 11 Sep 2011 08:16:49 -0400 Subject: Re: [Xen-devel] 3.0.4 and 3.1-rc4 based dom0 won't boot with acpi=off From: Ian Campbell To: Sven =?ISO-8859-1?Q?K=F6hler?= Date: Sun, 11 Sep 2011 13:16:47 +0100 In-Reply-To: <4E6C0473.8090905@gmail.com> References: <20110911002807.GA9989@oracle.com> <4E6C0473.8090905@gmail.com> Organization: Citrix Systems, Inc. Content-Type: text/plain; charset="UTF-8" X-Mailer: Evolution 3.0.3- Content-Transfer-Encoding: 8bit Message-ID: <1315743409.2925.16.camel@cthulhu.hellion.org.uk> MIME-Version: 1.0 Cc: "xen-devel@lists.xensource.com" , Konrad Rzeszutek Wilk X-BeenThere: xen-devel@lists.xensource.com X-Mailman-Version: 2.1.5 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xensource.com Errors-To: xen-devel-bounces@lists.xensource.com On Sat, 2011-09-10 at 20:44 -0400, Sven Köhler wrote: > Am 11.09.2011 02:28, schrieb Konrad Rzeszutek Wilk: > > On Sun, Sep 11, 2011 at 12:43:18AM +0200, Sven Köhler wrote: > >> Hi, > >> > >> when using acpi=off in the kernel or xen command line, the system won't > >> boot. On real hardware, I saw a few interrupt related warnings from the > >> usb drivers. The system then seemed to lock up when trying to do I/O via > >> AHCI. Same in virtualbox. System won't come up. > > > > Not surprised. Without the ACPI we can't find parse the interrupt table, > > so you don't get any interrupts. > > Thanks for explaining. Now what about the future? Will there be some > solution for the acpi=off case? > > I'm a bit confused, since your words don't sound like there is a way to > boot with acpi=off. But other dom0 kernels actually boot with acpi=off. > So after all, some other way for setting up interrupts seems to exist. Using acpi=off is sometimes a useful way to diagnose an issue, and once upon a time it may have even done more good than harm and been a useful solution to get a machine to work (on native as well under Xen) but on a modern system disabling ACPI is likely to do more harm than good, it's simply too ingrained into the way things work these days (again, on native as much as under Xen). > So in fact, xen is doing the reboot, and not the dom0 kernel, right? > (Some people have claimed otherwise) The dom0 kernel reboot method is always "via Xen", which is probably where the confusion arises, in many cases dom0 _initiates_ the reboot but doesn't actually do the reboot itself, Xen does the actual rebooting since it is the only entity with access to the required mechanisms in most cases. > Could you imagine to adapt xen's reboot code to the one of linux 3.0 > (which was tweaked quite a lot for maximum compatibility) It's probably worth revisiting and resyncing with what Linux does, IIRC Matthew Garret did a bunch of work on this recently. In particular commit 660e34cebf0a11d54f2d5dd8838607452355f321 Author: Matthew Garrett Date: Mon Apr 4 13:55:05 2011 -0400 x86: Reorder reboot method preferences but also all the stuff in the quirks file I suppose. Ian. > > > Regards, > Sven > _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel From xen-devel-bounces@lists.xensource.com Sun Sep 11 06:51:27 2011 Return-path: Envelope-to: www-data@lists.xensource.com Delivery-date: Sun, 11 Sep 2011 06:51:27 -0700 Received: from localhost ([127.0.0.1] helo=lists.colo.xensource.com) by lists.xensource.com with esmtp (Exim 4.43) id 1R2kRT-0003GS-QO; Sun, 11 Sep 2011 06:51:27 -0700 Received: from mail21.messagelabs.com ([85.158.143.35]) by lists.xensource.com with smtp (Exim 4.43) id 1R2kPr-000338-4m for xen-devel@lists.xensource.com; Sun, 11 Sep 2011 06:49:54 -0700 X-Env-Sender: jmdebruin@xmsnet.nl X-Msg-Ref: server-9.tower-21.messagelabs.com!1315748940!47974521!1 X-Originating-IP: [217.149.192.65] X-StarScan-Version: 6.3.6; banners=-,-,- X-VirusChecked: Checked Received: (qmail 15786 invoked from network); 11 Sep 2011 13:49:01 -0000 Received: from smtp10.mail.sp.isp-net.nl (HELO smtp10.mail.sp.isp-net.nl) (217.149.192.65) by server-9.tower-21.messagelabs.com with SMTP; 11 Sep 2011 13:49:01 -0000 Received: from [10.10.0.3] by smtp10.mail.sp.isp-net.nl via [92.254.124.152] with ESMTP for id p8BDngOi025811 (8.13.2/2.04); Sun, 11 Sep 2011 15:49:42 +0200 (MEST) Message-ID: <4E6CBC76.1030303@xmsnet.nl> Date: Sun, 11 Sep 2011 15:49:42 +0200 From: Hans de Bruin User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.2.15) Gecko/20110323 Thunderbird/3.1.9 MIME-Version: 1.0 To: xen-devel@lists.xensource.com Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Scanned: InterNLnet Mail Scan System V2.03 Subject: [Xen-devel] Xen PCI Pass-through: 0xbf701000 is using VM_IO, but it is 0xfffffffffffff000! X-BeenThere: xen-devel@lists.xensource.com X-Mailman-Version: 2.1.5 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xensource.com Errors-To: xen-devel-bounces@lists.xensource.com Hi, I get a warning in the domU kernels when I pass-through the ehcu/uhci devices. The usb-ports seem to work. I can use usb-sticks and a sundtek DVB-C stick. A microsoft usb-mouse is not recognized. Can I ignore the warning or do I have some serious issue/misconfiguration? Dom0: xm info: host : luna release : 3.1.0-rc5+ version : #6 SMP Sat Sep 10 10:30:18 CEST 2011 machine : x86_64 nr_cpus : 4 nr_nodes : 1 cores_per_socket : 2 threads_per_core : 2 cpu_mhz : 1666 hw_caps : bfebfbff:20100800:00000000:00000940:0040e31d:00000000:00000001:00000000 virt_caps : total_memory : 4086 free_memory : 1988 free_cpus : 0 xen_major : 4 xen_minor : 1 xen_extra : .1 xen_caps : xen-3.0-x86_64 xen-3.0-x86_32p xen_scheduler : credit xen_pagesize : 4096 platform_params : virt_start=0xffff800000000000 xen_changeset : unavailable xen_commandline : dom0_mem=768M dom0_max_vcpus=2 loglvl=all guest_loglvl=all com1=115200,8n1 console=com1,vga cc_compiler : gcc version 4.5.2 (GCC) cc_compile_by : hans cc_compile_domain : system cc_compile_date : Wed Jun 29 13:29:41 CEST 2011 xend_config_format : 4 Dom0: /proc/cmdline root=/dev/md2 ro console=hvc0 earlyprintk=xen xen-pciback.hide=(00:1a.0)(00:1a.1)(00:1a.7)(00:1d.0)(00:1d.1)(00:1d.2)(00:1d.7) pci=resource_alignment=00:1a.7;00:1d.7 Dom0: cat /etc/xen/vm/aries kernel = "/etc/xen/boot/vmlinuz-3.1.0-rc5" builder = 'linux' memory = 512 name = "aries" vcpus = 1 pci = [ '00:1a.0', '00:1a.1','00:1a.7' ] vif = [ 'mac=00:00:00:00:00:09,bridge=br_lan' ] disk = [ 'phy:vg2/aries_root,xvda,w', 'phy:vg2/aries_nfs,xvdb,w', 'phy:vg2/aries_video,xvdc,w' ] root = "/dev/xvda2 ro" extra = "3 iommu=soft" on_poweroff = 'destroy' on_reboot = 'restart' on_crash = 'restart' Dom0: cat /etc/xen/vm/orion kernel = "/etc/xen/boot/vmlinuz-3.1.0-rc5" builder = 'linux' memory = 512 name = "orion" vcpus = 2 pci = [ '00:1d.0', '00:1d.1','00:1d.2','00:1d.7'] vif = [ 'mac=00:00:00:00:00:2,bridge=br_lan' ] disk = [ 'phy:vg2/orion_root,xvda,w' ] root = "/dev/xvda2 ro" extra = "3 iommu=soft" on_poweroff = 'destroy' on_reboot = 'restart' on_crash = 'restart' DomU Aries: dmesg: [ 0.704330] ehci_hcd: USB 2.0 'Enhanced' Host Controller (EHCI) Driver [ 0.704816] ehci_hcd 0000:00:00.7: enabling device (0000 -> 0002) [ 0.705842] ehci_hcd 0000:00:00.7: Xen PCI mapped GSI18 to IRQ28 [ 0.705951] ------------[ cut here ]------------ pte_debug+0x154/0x160() [ 0.706099] 0xbf700000 is using VM_IO, but it is 0xfffffffffffff000! [ 0.706155] Modules linked in: [ 0.706251] Pid: 1, comm: swapper Not tainted 3.1.0-rc5+ #6 [ 0.706294] Call Trace: [ 0.706356] [] warn_slowpath_common+0x7f/0xc0 [ 0.706418] [] warn_slowpath_fmt+0x46/0x50 [ 0.706481] [] ? xen_clocksource_read+0x20/0x30 [ 0.706542] [] xen_make_pte_debug+0x154/0x160 [ 0.706604] [] __raw_callee_save_xen_make_pte_debug+0x11/0x1e [ 0.706669] [] ? ioremap_page_range+0x22f/0x300 [ 0.706738] [] __ioremap_caller+0x2ae/0x3a0 [ 0.706755] [] ? usb_hcd_pci_probe+0x18f/0x340 [ 0.706755] [] ? try_to_wake_up+0x2b0/0x2b0 [ 0.706755] [] ioremap_nocache+0x17/0x20 [ 0.706755] [] usb_hcd_pci_probe+0x18f/0x340 [ 0.706755] [] ? _raw_spin_unlock_irqrestore+0x1e/0x30 [ 0.706755] [] local_pci_probe+0x5f/0xd0 [ 0.706755] [] pci_device_probe+0x88/0xb0 [ 0.706755] [] ? driver_sysfs_add+0x7a/0xb0 [ 0.706755] [] driver_probe_device+0x96/0x1c0 [ 0.706755] [] ? driver_probe_device+0x1c0/0x1c0 [ 0.706755] [] __driver_attach+0xab/0xb0 [ 0.706755] [] ? driver_probe_device+0x1c0/0x1c0 [ 0.706755] [] bus_for_each_dev+0x5e/0x90 [ 0.706755] [] driver_attach+0x1e/0x20 [ 0.706755] [] bus_add_driver+0xc5/0x280 [ 0.706755] [] ? mon_bin_init+0xb5/0xb5 [ 0.706755] [] driver_register+0x76/0x140 [ 0.706755] [] ? printk+0x41/0x43 [ 0.706755] [] ? mon_bin_init+0xb5/0xb5 [ 0.706755] [] __pci_register_driver+0x56/0xd0 [ 0.706755] [] ehci_hcd_init+0x6a/0x78 [ 0.706755] [] do_one_initcall+0x44/0x190 [ 0.706755] [] kernel_init+0xc8/0x14d [ 0.706755] [] kernel_thread_helper+0x4/0x10 [ 0.706755] [] ? int_ret_from_sys_call+0x7/0x1b [ 0.706755] [] ? retint_restore_args+0x5/0x6 [ 0.706755] [] ? gs_change+0x13/0x13 [ 0.706755] ---[ end trace 55922f9402942cd3 ]--- DomU Orion: dmesg: [ 0.890404] ehci_hcd: USB 2.0 'Enhanced' Host Controller (EHCI) Driver [ 0.891167] ehci_hcd 0000:00:00.7: enabling device (0000 -> 0002) [ 0.892300] ehci_hcd 0000:00:00.7: Xen PCI mapped GSI23 to IRQ32 [ 0.892412] ------------[ cut here ]------------ [ 0.892484] WARNING: at /home/hans/linux-2.6/arch/x86/xen/mmu.c:519 xen_make_pte_debug+0x154/0x160() [ 0.892556] 0xbf701000 is using VM_IO, but it is 0xfffffffffffff000! [ 0.892617] Modules linked in: [ 0.892712] Pid: 1, comm: swapper Not tainted 3.1.0-rc5+ #6 [ 0.892769] Call Trace: [ 0.892867] [] warn_slowpath_common+0x7f/0xc0 [ 0.892960] [] warn_slowpath_fmt+0x46/0x50 [ 0.893052] [] ? xen_clocksource_read+0x20/0x30 [ 0.893146] [] xen_make_pte_debug+0x154/0x160 [ 0.893230] [] __raw_callee_save_xen_make_pte_debug+0x11/0x1e [ 0.893299] [] ? ioremap_page_range+0x22f/0x300 [ 0.893364] [] __ioremap_caller+0x2ae/0x3a0 [ 0.893521] [] ? usb_hcd_pci_probe+0x18f/0x340 [ 0.893585] [] ? try_to_wake_up+0x2b0/0x2b0 [ 0.893624] [] ioremap_nocache+0x17/0x20 [ 0.893624] [] usb_hcd_pci_probe+0x18f/0x340 [ 0.893624] [] ? _raw_spin_unlock_irqrestore+0x1e/0x30 [ 0.893624] [] local_pci_probe+0x5f/0xd0 [ 0.893624] [] pci_device_probe+0x88/0xb0 [ 0.893624] [] ? driver_sysfs_add+0x7a/0xb0 [ 0.893624] [] driver_probe_device+0x96/0x1c0 [ 0.893624] [] ? driver_probe_device+0x1c0/0x1c0 [ 0.893624] [] __driver_attach+0xab/0xb0 [ 0.893624] [] ? driver_probe_device+0x1c0/0x1c0 [ 0.893624] [] bus_for_each_dev+0x5e/0x90 [ 0.893624] [] driver_attach+0x1e/0x20 [ 0.893624] [] bus_add_driver+0xc5/0x280 [ 0.893624] [] ? mon_bin_init+0xb5/0xb5 [ 0.893624] [] driver_register+0x76/0x140 [ 0.893624] [] ? printk+0x41/0x43 [ 0.893624] [] ? mon_bin_init+0xb5/0xb5 [ 0.893624] [] __pci_register_driver+0x56/0xd0 [ 0.893624] [] ehci_hcd_init+0x6a/0x78 [ 0.893624] [] do_one_initcall+0x44/0x190 [ 0.893624] [] kernel_init+0xc8/0x14d [ 0.893624] [] kernel_thread_helper+0x4/0x10 [ 0.893624] [] ? int_ret_from_sys_call+0x7/0x1b [ 0.893624] [] ? retint_restore_args+0x5/0x6 [ 0.893624] [] ? gs_change+0x13/0x13 [ 0.893624] ---[ end trace d4aaccc7a6a84eaa ]--- By the way, when I attach all the uhci/ehci devices to one DomU the error occurs only on detection of the first ehci device. -- Hans _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel From xen-devel-bounces@lists.xensource.com Sun Sep 11 18:15:07 2011 Return-path: Envelope-to: www-data@lists.xensource.com Delivery-date: Sun, 11 Sep 2011 18:15:07 -0700 Received: from localhost ([127.0.0.1] helo=lists.colo.xensource.com) by lists.xensource.com with esmtp (Exim 4.43) id 1R2v75-0000xB-4l; Sun, 11 Sep 2011 18:15:07 -0700 Received: from mail174.messagelabs.com ([85.158.138.51]) by lists.xensource.com with esmtp (Exim 4.43) id 1R2v6L-0000kH-Tt for xen-devel@lists.xensource.com; Sun, 11 Sep 2011 18:14:22 -0700 X-Env-Sender: Ian.Jackson@eu.citrix.com X-Msg-Ref: server-9.tower-174.messagelabs.com!1315790058!25008108!1 X-Originating-IP: [62.200.22.115] X-StarScan-Version: 6.3.6; banners=-,-,- X-VirusChecked: Checked Received: (qmail 23088 invoked from network); 12 Sep 2011 01:14:18 -0000 Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115) by server-9.tower-174.messagelabs.com with RC4-SHA encrypted SMTP; 12 Sep 2011 01:14:18 -0000 X-IronPort-AV: E=Sophos;i="4.68,365,1312156800"; d="scan'208";a="7717766" Received: from lonpmailmx01.citrite.net ([10.30.203.162]) by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5; 12 Sep 2011 01:14:17 +0000 Received: from woking.xci-test.com (10.80.248.135) by smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id 8.3.137.0; Mon, 12 Sep 2011 02:14:17 +0100 Received: from osstest by woking.xci-test.com with local (Exim 4.69) (envelope-from ) id 1R2v6H-0007LZ-DZ; Mon, 12 Sep 2011 02:14:17 +0100 To: xen-devel@lists.xensource.com Message-ID: From: xen.org Date: Mon, 12 Sep 2011 02:14:17 +0100 MIME-Version: 1.0 Content-Type: text/plain Cc: ian.jackson@eu.citrix.com Subject: [Xen-devel] [xen-unstable test] 8872: tolerable FAIL X-BeenThere: xen-devel@lists.xensource.com X-Mailman-Version: 2.1.5 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xensource.com Errors-To: xen-devel-bounces@lists.xensource.com flight 8872 xen-unstable real [real] http://www.chiark.greenend.org.uk/~xensrcts/logs/8872/ Failures :-/ but no regressions. Tests which did not succeed, but are not blocking, including regressions (tests previously passed) regarded as allowable: test-amd64-amd64-xl-pcipt-intel 1 xen-build-check(1) blocked n/a test-amd64-i386-rhel6hvm-intel 1 xen-build-check(1) blocked n/a test-i386-i386-pv 1 xen-build-check(1) blocked n/a test-amd64-i386-pv 1 xen-build-check(1) blocked n/a test-amd64-amd64-pv 1 xen-build-check(1) blocked n/a test-i386-i386-xl 1 xen-build-check(1) blocked n/a test-amd64-i386-xl 1 xen-build-check(1) blocked n/a test-amd64-i386-xl-credit2 1 xen-build-check(1) blocked n/a test-amd64-i386-rhel6hvm-amd 1 xen-build-check(1) blocked n/a test-amd64-amd64-pair 1 xen-build-check(1) blocked n/a test-amd64-i386-pair 1 xen-build-check(1) blocked n/a test-i386-i386-pair 1 xen-build-check(1) blocked n/a build-amd64-pvops 4 kernel-build fail like 8871 build-i386-pvops 4 kernel-build fail like 8871 test-amd64-i386-xl-multivcpu 1 xen-build-check(1) blocked n/a test-amd64-amd64-xl-sedf 1 xen-build-check(1) blocked n/a test-amd64-i386-win-vcpus1 1 xen-build-check(1) blocked n/a test-amd64-i386-xl-win-vcpus1 1 xen-build-check(1) blocked n/a test-amd64-amd64-win 1 xen-build-check(1) blocked n/a test-amd64-i386-win 1 xen-build-check(1) blocked n/a test-amd64-amd64-xl-win 1 xen-build-check(1) blocked n/a test-amd64-amd64-xl 1 xen-build-check(1) blocked n/a test-i386-i386-xl-win 1 xen-build-check(1) blocked n/a test-i386-i386-win 1 xen-build-check(1) blocked n/a version targeted for testing: xen 0312575dc35e baseline version: xen 0312575dc35e jobs: build-amd64 pass build-i386 pass build-amd64-oldkern pass build-i386-oldkern pass build-amd64-pvops fail build-i386-pvops fail test-amd64-amd64-xl blocked test-amd64-i386-xl blocked test-i386-i386-xl blocked test-amd64-i386-rhel6hvm-amd blocked test-amd64-i386-xl-credit2 blocked test-amd64-amd64-xl-pcipt-intel blocked test-amd64-i386-rhel6hvm-intel blocked test-amd64-i386-xl-multivcpu blocked test-amd64-amd64-pair blocked test-amd64-i386-pair blocked test-i386-i386-pair blocked test-amd64-amd64-pv blocked test-amd64-i386-pv blocked test-i386-i386-pv blocked test-amd64-amd64-xl-sedf blocked test-amd64-i386-win-vcpus1 blocked test-amd64-i386-xl-win-vcpus1 blocked test-amd64-amd64-win blocked test-amd64-i386-win blocked test-i386-i386-win blocked test-amd64-amd64-xl-win blocked test-i386-i386-xl-win blocked ------------------------------------------------------------ sg-report-flight on woking.cam.xci-test.com logs: /home/xc_osstest/logs images: /home/xc_osstest/images Logs, config files, etc. are available at http://www.chiark.greenend.org.uk/~xensrcts/logs Test harness code can be found at http://xenbits.xensource.com/gitweb?p=osstest.git;a=summary Published tested tree is already up to date. _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel From xen-devel-bounces@lists.xensource.com Sun Sep 11 19:33:00 2011 Return-path: Envelope-to: www-data@lists.xensource.com Delivery-date: Sun, 11 Sep 2011 19:33:00 -0700 Received: from localhost ([127.0.0.1] helo=lists.colo.xensource.com) by lists.xensource.com with esmtp (Exim 4.43) id 1R2wKS-0003wN-Qs; Sun, 11 Sep 2011 19:33:00 -0700 Received: from mail21.messagelabs.com ([85.158.143.35]) by lists.xensource.com with esmtp (Exim 4.43) id 1R2wJr-0003jJ-PW for xen-devel@lists.xensource.com; Sun, 11 Sep 2011 19:32:24 -0700 X-Env-Sender: james.harper@bendigoit.com.au X-Msg-Ref: server-3.tower-21.messagelabs.com!1315794748!51164303!1 X-Originating-IP: [203.16.207.99] X-StarScan-Version: 6.3.6; banners=-,-,- X-VirusChecked: Checked Received: (qmail 19577 invoked from network); 12 Sep 2011 02:32:32 -0000 Received: from mail.bendigoit.com.au (HELO smtp2.bendigoit.com.au) (203.16.207.99) by server-3.tower-21.messagelabs.com with AES256-SHA encrypted SMTP; 12 Sep 2011 02:32:32 -0000 Received: from trantor.int.sbss.com.au ([192.168.200.206] helo=mail.bendigoit.com.au) by smtp2.bendigoit.com.au with esmtp (Exim 4.72) (envelope-from ) id 1R2wJj-0001Lt-Ru for xen-devel@lists.xensource.com; Mon, 12 Sep 2011 12:32:15 +1000 X-MimeOLE: Produced By Microsoft Exchange V6.5 MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable x-cr-puzzleid: {417C5934-C46D-434A-B6B7-D9A38C48E7F3} x-cr-hashedpuzzle: C9hI DpFZ Dtq0 D2IS EH00 ETXb ET7I FA1G GOmF GftA Ggbx Gw+x HOnC HcJY K1p/ K8qK; 1; eABlAG4ALQBkAGUAdgBlAGwAQABsAGkAcwB0AHMALgB4AGUAbgBzAG8AdQByAGMAZQAuAGMAbwBtAA==; Sosha1_v1; 7; {417C5934-C46D-434A-B6B7-D9A38C48E7F3}; agBhAG0AZQBzAC4AaABhAHIAcABlAHIAQABiAGUAbgBkAGkAZwBvAGkAdAAuAGMAbwBtAC4AYQB1AA==; Mon, 12 Sep 2011 02:32:13 GMT; ZwBpAHQALgBrAGUAcgBuAGUAbAAuAG8AcgBnAA== Content-class: urn:content-classes:message Date: Mon, 12 Sep 2011 12:32:13 +1000 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: git.kernel.org Thread-Index: Acxw9C37KUtStzWaQpGDTrTJthdQEw== From: "James Harper" To: X-Really-From-Bendigo-IT: magichashvalue Subject: [Xen-devel] git.kernel.org X-BeenThere: xen-devel@lists.xensource.com X-Mailman-Version: 2.1.5 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xensource.com Errors-To: xen-devel-bounces@lists.xensource.com I had a search of the list and can't find anything... where should we be pulling our linux pvops kernels from while kernel.org sorts itself out after the recent security issues? git.kernel.org doesn't resolve? Thanks James _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel From xen-devel-bounces@lists.xensource.com Sun Sep 11 23:51:28 2011 Return-path: Envelope-to: www-data@lists.xensource.com Delivery-date: Sun, 11 Sep 2011 23:51:28 -0700 Received: from localhost ([127.0.0.1] helo=lists.colo.xensource.com) by lists.xensource.com with esmtp (Exim 4.43) id 1R30MZ-0000l3-Up; Sun, 11 Sep 2011 23:51:28 -0700 Received: from mail216.messagelabs.com ([85.158.143.99]) by lists.xensource.com with esmtp (Exim 4.43) id 1R30Ln-0000YH-2S for xen-devel@lists.xensource.com; Sun, 11 Sep 2011 23:50:39 -0700 X-Env-Sender: JBeulich@suse.com X-Msg-Ref: server-4.tower-216.messagelabs.com!1315810235!17876618!1 X-Originating-IP: [130.57.49.28] X-StarScan-Version: 6.3.6; banners=-,-,- X-VirusChecked: Checked Received: (qmail 1224 invoked from network); 12 Sep 2011 06:50:36 -0000 Received: from nat28.tlf.novell.com (HELO nat28.tlf.novell.com) (130.57.49.28) by server-4.tower-216.messagelabs.com with DHE-RSA-AES256-SHA encrypted SMTP; 12 Sep 2011 06:50:36 -0000 Received: from EMEA1-MTA by nat28.tlf.novell.com with Novell_GroupWise; Mon, 12 Sep 2011 07:50:35 +0100 Message-Id: <4E6DC7D80200007800055AB1@nat28.tlf.novell.com> X-Mailer: Novell GroupWise Internet Agent 8.0.1 Date: Mon, 12 Sep 2011 07:50:32 +0100 From: "Jan Beulich" To: "Andrew Cooper" Subject: Re: [Xen-devel] Re: 4.0/4.1 requests - IO-APIC EOI v4 [RFC] References: <4E689D9A.1020405@citrix.com> <4E68C6C10200007800055485@nat28.tlf.novell.com> <4E68C09B.8050409@citrix.com> <4E68E1D30200007800055501@nat28.tlf.novell.com> <4E68C9A9.8090707@citrix.com> <4E6A2B7F.6060006@citrix.com> <4E6A4F66020000780005589B@nat28.tlf.novell.com> <4E6A36EB.6000802@citrix.com> <4E6A54DB02000078000558B6@nat28.tlf.novell.com> <4E6A3D5B.5010104@citrix.com> <4E6A430B.30308@citrix.com> In-Reply-To: <4E6A430B.30308@citrix.com> Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: quoted-printable Content-Disposition: inline Cc: Keir Fraser , "xen-devel@lists.xensource.com" X-BeenThere: xen-devel@lists.xensource.com X-Mailman-Version: 2.1.5 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xensource.com Errors-To: xen-devel-bounces@lists.xensource.com >>> On 09.09.11 at 18:47, Andrew Cooper wrote: > On 09/09/11 17:22, Andrew Cooper wrote: >> ---SNIP--- >> >> Version 3. Applied Jan's suggestions, and extended some of the = comments. >> >=20 > V4 - get the BUG_ON logic correct (oops). >=20 > I have now done a few reboot tests and a kexec test with this patch. >=20 > Are there any other tests you would suggest, or shall I formally submit > the patch for unstable and backporting? Looks technically good now, but there are a few cosmetic comments still: >--- a/xen/arch/x86/io_apic.c Mon Sep 05 15:10:28 2011 +0100 >+++ b/xen/arch/x86/io_apic.c Fri Sep 09 17:20:49 2011 +0100 >@@ -68,6 +68,16 @@ int __read_mostly nr_ioapics; > #define MAX_PLUS_SHARED_IRQS nr_irqs_gsi > #define PIN_MAP_SIZE (MAX_PLUS_SHARED_IRQS + nr_irqs_gsi) >=20 >+ >+#define ioapic_has_eoi_reg(apic) (mp_ioapics[(apic)].mpc_apicver >=3D = 0x20) >+ >+static void __io_apic_eoi(unsigned int apic, unsigned int vector, = unsigned int pin); >+static void io_apic_eoi(unsigned int apic, unsigned int vector, unsigned = int pin); No need to declare these here if you move the definitions up before the first use (would fit well after ioapic_write_entry()). >+ >+#define io_apic_eoi_vector(apic, vector) io_apic_eoi((apic), (vector), = -1) >+#define io_apic_eoi_pin(apic, pin) io_apic_eoi((apic), -1, (pin)) >+ >+ > /* > * This is performance-critical, we want to do it O(1) > * >... >@@ -2622,3 +2621,124 @@ void __init init_ioapic_mappings(void) > printk(XENLOG_INFO "IRQ limits: %u GSI, %u MSI/MSI-X\n", > nr_irqs_gsi, nr_irqs - nr_irqs_gsi); > } >+ >+/* EOI an IO-APIC entry. One of vector or pin may be -1, indicating = that >+ * it should be worked out using the other. This function disables = interrupts >+ * and takes the ioapic_lock */ >+static void io_apic_eoi(unsigned int apic, unsigned int vector, unsigned = int pin) >+{ >+ unsigned int flags; >+ spin_lock_irqsave(&ioapic_lock, flags); >+ __io_apic_eoi(apic, vector, pin); >+ spin_unlock_irqrestore(&ioapic_lock, flags); >+} >+ >+/* EOI an IO-APIC entry. One of vector or pin may be -1, indicating = that >+ * it should be worked out using the other. This function expect that = the >+ * ioapic_lock is taken, and interrupts are disabled (or there is a good = reason >+ * not to), and that if both pin and vector are passed, that they refer = to the >+ * same redirection entry in the IO-APIC. */ >+static void __io_apic_eoi(unsigned int apic, unsigned int vector, = unsigned int pin) >+{ >+ /* Ensure some useful information is passed in */ >+ BUG_ON( !(vector =3D=3D -1 && pin !=3D -1) ); >+ =20 >+ /* Prefer the use of the EOI register if available */ >+ if ( ioapic_has_eoi_reg(apic) ) >+ { >+ /* If vector is unknown, read it from the IO-APIC */ >+ if ( vector =3D=3D -1 ) >+ vector =3D __ioapic_read_entry(apic, pin, TRUE).vector; >+ >+ *(IO_APIC_BASE(apic)+16) =3D vector; >+ } >+ else >+ { >+ /* Else fake an EOI by switching to edge triggered mode >+ * and back */ >+ struct IO_APIC_route_entry entry; >+ bool_t need_to_unmask =3D 0; >+ >+ /* If pin is unknown, search for it */ >+ if ( pin =3D=3D -1 ) >+ { >+ unsigned int p; >+ for ( p =3D 0; p < nr_ioapic_registers[apic]; ++p ) >+ { >+ entry =3D __ioapic_read_entry(apic, p, TRUE); >+ if ( entry.vector =3D=3D vector ) >+ { >+ pin =3D p; >+ /* break; */ >+ >+ /* Here should be a break out of the loop, but at = the=20 ... moment ... >+ * Xen code doesn't actually prevent multiple = IO-APIC >+ * entries being assigned the same vector, so EOI = all >+ * pins which have the correct vector. >+ * >+ * Remove the following code when the above = assertion >+ * is fulfilled. */ >+ Why don't you just call __io_apic_eoi() recursively here? Jan >+ if ( ! entry.mask ) >+ { >+ /* If entry is not currently masked, mask it and = make >+ * a note to unmask it later */ >+ entry.mask =3D 1; >+ __ioapic_write_entry(apic, pin, TRUE, entry); >+ need_to_unmask =3D 1; >+ } >+ >+ /* Flip the trigger mode to edge and back */ >+ entry.trigger =3D 0; >+ __ioapic_write_entry(apic, pin, TRUE, entry); >+ entry.trigger =3D 1; >+ __ioapic_write_entry(apic, pin, TRUE, entry); >+ >+ if ( need_to_unmask ) >+ { >+ /* Unmask if neccesary */ >+ entry.mask =3D 0; >+ __ioapic_write_entry(apic, pin, TRUE, entry); >+ } >+ >+ } >+ } >+ =20 >+ /* If search fails, nothing to do */ >+ >+ /* if ( pin =3D=3D -1 ) */ >+ >+ /* Because the loop wasn't broken out of (see comment = above), >+ * all relevant pins have been EOI, so we can always return. >+ *=20 >+ * Re-instate the if statement above when the Xen logic has = been >+ * fixed.*/ >+ >+ return; >+ } >+ >+ entry =3D __ioapic_read_entry(apic, pin, TRUE); >+ >+ if ( ! entry.mask ) >+ { >+ /* If entry is not currently masked, mask it and make >+ * a note to unmask it later */ >+ entry.mask =3D 1; >+ __ioapic_write_entry(apic, pin, TRUE, entry); >+ need_to_unmask =3D 1; >+ } >+ >+ /* Flip the trigger mode to edge and back */ >+ entry.trigger =3D 0; >+ __ioapic_write_entry(apic, pin, TRUE, entry); >+ entry.trigger =3D 1; >+ __ioapic_write_entry(apic, pin, TRUE, entry); >+ >+ if ( need_to_unmask ) >+ { >+ /* Unmask if neccesary */ >+ entry.mask =3D 0; >+ __ioapic_write_entry(apic, pin, TRUE, entry); >+ } >+ } >+} >... _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel From xen-devel-bounces@lists.xensource.com Mon Sep 12 00:37:46 2011 Return-path: Envelope-to: www-data@lists.xensource.com Delivery-date: Mon, 12 Sep 2011 00:37:46 -0700 Received: from localhost ([127.0.0.1] helo=lists.colo.xensource.com) by lists.xensource.com with esmtp (Exim 4.43) id 1R315N-0004U7-Qb; Mon, 12 Sep 2011 00:37:45 -0700 Received: from mail182.messagelabs.com ([85.158.139.83]) by lists.xensource.com with esmtp (Exim 4.43) id 1R3148-00047z-G8; Mon, 12 Sep 2011 00:36:30 -0700 X-Env-Sender: pasik@iki.fi X-Msg-Ref: server-4.tower-182.messagelabs.com!1315812984!17942448!1 X-Originating-IP: [192.89.123.25] X-StarScan-Version: 6.3.6; banners=-,-,- X-VirusChecked: Checked Received: (qmail 13501 invoked from network); 12 Sep 2011 07:36:25 -0000 Received: from smtp.tele.fi (HELO smtp.tele.fi) (192.89.123.25) by server-4.tower-182.messagelabs.com with DHE-RSA-AES256-SHA encrypted SMTP; 12 Sep 2011 07:36:25 -0000 X-Originating-Ip: [194.89.68.22] Received: from ydin.reaktio.net (reaktio.net [194.89.68.22]) by smtp.tele.fi (Postfix) with ESMTP id D9E921C15; Mon, 12 Sep 2011 10:36:23 +0300 (EEST) Received: by ydin.reaktio.net (Postfix, from userid 1001) id 9182D20059; Mon, 12 Sep 2011 10:36:23 +0300 (EEST) Date: Mon, 12 Sep 2011 10:36:23 +0300 From: Pasi =?iso-8859-1?Q?K=E4rkk=E4inen?= To: jim burns Message-ID: <20110912073623.GF12984@reaktio.net> References: <201107231426.56811.jim_burn@bellsouth.net> <3588908.GoxUj34Eqr@dell4550> <20110909131438.GY12984@reaktio.net> <13293012.CAopQqStiY@dell4550> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <13293012.CAopQqStiY@dell4550> User-Agent: Mutt/1.5.18 (2008-05-17) Cc: Todd Deshane , xen-devel@lists.xensource.com, xen-users@lists.xensource.com, Fedora Xen List Subject: [Xen-devel] Re: Continuing BUG:-iness booting Fedora Rawhide 3.1.0-rc's (was Summary: Experiences setting up a debug serial port) X-BeenThere: xen-devel@lists.xensource.com X-Mailman-Version: 2.1.5 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xensource.com Errors-To: xen-devel-bounces@lists.xensource.com On Fri, Sep 09, 2011 at 09:52:41AM -0400, jim burns wrote: > On Fri September 9 2011, 4:14:38 PM, Pasi Kärkkäinen wrote: > > Hello, > > > > Added xen-devel to CC.. > > > > On Thu, Sep 08, 2011 at 08:36:04PM -0400, jim burns wrote: > > > Rawhide is up to 3.1.0-0.rc5.git0.0.fc17 , and still the same dom0 boot > > > bugs as in rc4. > > > > Can you please post the full Xen + 3.1-rc5 dom0 boot logs again.. > > > > -- Pasi > > Sure, thanx, attached. Do you need a debug log also (initcall_debug debug > loglevel=10)? > Sure, it doesn't hurt.. > The last four BUG:s (from Sep 8 17:12:20 on) were from starting a winxp domu > (first 3 BUG:s), and destroying it at grub (the last BUG:). > Ok, so there are BUGs when booting up, and also when starting HVM guests. -- Pasi > Sep 8 16:59:12 Insp6400 kernel: imklog 5.8.2, log source = /proc/kmsg started. > Sep 8 16:59:12 Insp6400 rsyslogd: [origin software="rsyslogd" swVersion="5.8.2" x-pid="789" x-info="http://www.rsyslog.com"] start > Sep 8 16:59:12 Insp6400 kernel: [ 0.000000] Initializing cgroup subsys cpuset > Sep 8 16:59:12 Insp6400 kernel: [ 0.000000] Initializing cgroup subsys cpu > Sep 8 16:59:12 Insp6400 kernel: [ 0.000000] Linux version 3.1.0-0.rc5.git0.0.fc17.x86_64 (mockbuild@x86-06.phx2.fedoraproject.org) (gcc version 4.6.1 20110804 (Red Hat 4.6.1-7) (GCC) ) #1 SMP Wed Sep 7 20:28:26 UTC 2011 > Sep 8 16:59:12 Insp6400 kernel: [ 0.000000] Command line: ro root=/dev/mapper/vg_insp6400-lv_root SYSFONT=latarcyrheb-sun16 LANG=en_US.UTF-8 KEYTABLE=us xen-pciback.permissive xen-pciback.hide=(0b:00.0) > Sep 8 16:59:12 Insp6400 kernel: [ 0.000000] released 0 pages of unused memory > Sep 8 16:59:12 Insp6400 kernel: [ 0.000000] Set 526733 page(s) to 1-1 mapping. > Sep 8 16:59:12 Insp6400 kernel: [ 0.000000] BIOS-provided physical RAM map: > Sep 8 16:59:12 Insp6400 kernel: [ 0.000000] Xen: 0000000000000000 - 000000000009f000 (usable) > Sep 8 16:59:12 Insp6400 kernel: [ 0.000000] Xen: 000000000009f000 - 0000000000100000 (reserved) > Sep 8 16:59:12 Insp6400 kernel: [ 0.000000] Xen: 0000000000100000 - 0000000075fce000 (usable) > Sep 8 16:59:12 Insp6400 kernel: [ 0.000000] Xen: 0000000075fce000 - 000000007f6d3000 (unusable) > Sep 8 16:59:12 Insp6400 kernel: [ 0.000000] Xen: 000000007f6d3400 - 0000000080000000 (reserved) > Sep 8 16:59:12 Insp6400 kernel: [ 0.000000] Xen: 00000000f0000000 - 00000000f4007000 (reserved) > Sep 8 16:59:12 Insp6400 kernel: [ 0.000000] Xen: 00000000f4008000 - 00000000f400c000 (reserved) > Sep 8 16:59:12 Insp6400 kernel: [ 0.000000] Xen: 00000000fec00000 - 00000000fec10000 (reserved) > Sep 8 16:59:12 Insp6400 kernel: [ 0.000000] Xen: 00000000fed20000 - 00000000feda0000 (reserved) > Sep 8 16:59:12 Insp6400 kernel: [ 0.000000] Xen: 00000000fee00000 - 00000000fee10000 (reserved) > Sep 8 16:59:12 Insp6400 kernel: [ 0.000000] Xen: 00000000ffb00000 - 0000000100000000 (reserved) > Sep 8 16:59:12 Insp6400 kernel: [ 0.000000] Xen: 0000000100000000 - 0000000109705000 (usable) > Sep 8 16:59:12 Insp6400 kernel: [ 0.000000] NX (Execute Disable) protection: active > Sep 8 16:59:12 Insp6400 kernel: [ 0.000000] DMI 2.4 present. > Sep 8 16:59:12 Insp6400 kernel: [ 0.000000] No AGP bridge found > Sep 8 16:59:12 Insp6400 kernel: [ 0.000000] last_pfn = 0x109705 max_arch_pfn = 0x400000000 > Sep 8 16:59:12 Insp6400 kernel: [ 0.000000] last_pfn = 0x75fce max_arch_pfn = 0x400000000 > Sep 8 16:59:12 Insp6400 kernel: [ 0.000000] init_memory_mapping: 0000000000000000-0000000075fce000 > Sep 8 16:59:12 Insp6400 kernel: [ 0.000000] init_memory_mapping: 0000000100000000-0000000109705000 > Sep 8 16:59:12 Insp6400 kernel: [ 0.000000] RAMDISK: 02ae5000 - 0533f000 > Sep 8 16:59:12 Insp6400 kernel: [ 0.000000] ACPI: RSDP 00000000000fc1d0 00014 (v00 DELL ) > Sep 8 16:59:12 Insp6400 kernel: [ 0.000000] ACPI: RSDT 000000007f6d3a0f 00040 (v01 DELL M07 27D7060D ASL 00000061) > Sep 8 16:59:12 Insp6400 kernel: [ 0.000000] ACPI: FACP 000000007f6d4800 00074 (v01 DELL M07 27D7060D ASL 00000061) > Sep 8 16:59:12 Insp6400 kernel: [ 0.000000] ACPI: DSDT 000000007f6d5400 04766 (v01 INT430 SYSFexxx 00001001 INTL 20050624) > Sep 8 16:59:12 Insp6400 kernel: [ 0.000000] ACPI: FACS 000000007f6e3c00 00040 > Sep 8 16:59:12 Insp6400 kernel: [ 0.000000] ACPI: HPET 000000007f6d4f00 00038 (v01 DELL M07 00000001 ASL 00000061) > Sep 8 16:59:12 Insp6400 kernel: [ 0.000000] ACPI: APIC 000000007f6d5000 00068 (v01 DELL M07 27D7060D ASL 00000047) > Sep 8 16:59:12 Insp6400 kernel: [ 0.000000] ACPI: MCFG 000000007f6d4fc0 0003E (v16 DELL M07 27D7060D ASL 00000061) > Sep 8 16:59:12 Insp6400 kernel: [ 0.000000] ACPI: SLIC 000000007f6d509c 00176 (v01 DELL M07 27D7060D ASL 00000061) > Sep 8 16:59:12 Insp6400 kernel: [ 0.000000] ACPI: BOOT 000000007f6d4bc0 00028 (v01 DELL M07 27D7060D ASL 00000061) > Sep 8 16:59:12 Insp6400 kernel: [ 0.000000] ACPI: SSDT 000000007f6d3a4f 004DC (v01 PmRef CpuPm 00003000 INTL 20050624) > Sep 8 16:59:12 Insp6400 kernel: [ 0.000000] No NUMA configuration found > Sep 8 16:59:12 Insp6400 kernel: [ 0.000000] Faking a node at 0000000000000000-0000000109705000 > Sep 8 16:59:12 Insp6400 kernel: [ 0.000000] Initmem setup node 0 0000000000000000-0000000109705000 > Sep 8 16:59:10 Insp6400 avahi-daemon[755]: Found user 'avahi' (UID 498) and group 'avahi' (GID 491). > Sep 8 16:59:10 Insp6400 avahi-daemon[755]: Successfully dropped root privileges. > Sep 8 16:59:10 Insp6400 avahi-daemon[755]: avahi-daemon 0.6.30 starting up. > Sep 8 16:59:10 Insp6400 avahi-daemon[755]: WARNING: No NSS support for mDNS detected, consider installing nss-mdns! > Sep 8 16:59:12 Insp6400 kernel: [ 0.000000] NODE_DATA [0000000075fb9000 - 0000000075fcdfff] > Sep 8 16:59:12 Insp6400 kernel: [ 0.000000] Zone PFN ranges: > Sep 8 16:59:12 Insp6400 kernel: [ 0.000000] DMA 0x00000010 -> 0x00001000 > Sep 8 16:59:12 Insp6400 kernel: [ 0.000000] DMA32 0x00001000 -> 0x00100000 > Sep 8 16:59:12 Insp6400 kernel: [ 0.000000] Normal 0x00100000 -> 0x00109705 > Sep 8 16:59:12 Insp6400 kernel: [ 0.000000] Movable zone start PFN for each node > Sep 8 16:59:12 Insp6400 kernel: [ 0.000000] early_node_map[3] active PFN ranges > Sep 8 16:59:12 Insp6400 kernel: [ 0.000000] 0: 0x00000010 -> 0x0000009f > Sep 8 16:59:12 Insp6400 kernel: [ 0.000000] 0: 0x00000100 -> 0x00075fce > Sep 8 16:59:12 Insp6400 kernel: [ 0.000000] 0: 0x00100000 -> 0x00109705 > Sep 8 16:59:12 Insp6400 kernel: [ 0.000000] ACPI: PM-Timer IO Port: 0x1008 > Sep 8 16:59:12 Insp6400 kernel: [ 0.000000] ACPI: LAPIC (acpi_id[0x00] lapic_id[0x00] enabled) > Sep 8 16:59:12 Insp6400 kernel: [ 0.000000] BIOS bug: APIC version is 0 for CPU 0/0x0, fixing up to 0x10 > Sep 8 16:59:12 Insp6400 kernel: [ 0.000000] ACPI: LAPIC (acpi_id[0x01] lapic_id[0x01] enabled) > Sep 8 16:59:12 Insp6400 kernel: [ 0.000000] ACPI: LAPIC_NMI (acpi_id[0x00] high edge lint[0x1]) > Sep 8 16:59:12 Insp6400 kernel: [ 0.000000] ACPI: LAPIC_NMI (acpi_id[0x01] high edge lint[0x1]) > Sep 8 16:59:12 Insp6400 kernel: [ 0.000000] ACPI: IOAPIC (id[0x02] address[0xfec00000] gsi_base[0]) > Sep 8 16:59:12 Insp6400 kernel: [ 0.000000] IOAPIC[0]: apic_id 2, version 255, address 0xfec00000, GSI 0-255 > Sep 8 16:59:12 Insp6400 kernel: [ 0.000000] ACPI: INT_SRC_OVR (bus 0 bus_irq 0 global_irq 2 dfl dfl) > Sep 8 16:59:12 Insp6400 kernel: [ 0.000000] ACPI: INT_SRC_OVR (bus 0 bus_irq 9 global_irq 9 high level) > Sep 8 16:59:12 Insp6400 kernel: [ 0.000000] Using ACPI (MADT) for SMP configuration information > Sep 8 16:59:12 Insp6400 kernel: [ 0.000000] ACPI: HPET id: 0x8086a201 base: 0xfed00000 > Sep 8 16:59:12 Insp6400 kernel: [ 0.000000] SMP: Allowing 2 CPUs, 0 hotplug CPUs > Sep 8 16:59:12 Insp6400 kernel: [ 0.000000] PM: Registered nosave memory: 000000000009f000 - 0000000000100000 > Sep 8 16:59:12 Insp6400 kernel: [ 0.000000] PM: Registered nosave memory: 0000000075fce000 - 000000007f6d3000 > Sep 8 16:59:12 Insp6400 kernel: [ 0.000000] PM: Registered nosave memory: 000000007f6d3000 - 000000007f6d4000 > Sep 8 16:59:12 Insp6400 kernel: [ 0.000000] PM: Registered nosave memory: 000000007f6d4000 - 0000000080000000 > Sep 8 16:59:12 Insp6400 kernel: [ 0.000000] PM: Registered nosave memory: 0000000080000000 - 00000000f0000000 > Sep 8 16:59:12 Insp6400 kernel: [ 0.000000] PM: Registered nosave memory: 00000000f0000000 - 00000000f4007000 > Sep 8 16:59:12 Insp6400 kernel: [ 0.000000] PM: Registered nosave memory: 00000000f4007000 - 00000000f4008000 > Sep 8 16:59:12 Insp6400 kernel: [ 0.000000] PM: Registered nosave memory: 00000000f4008000 - 00000000f400c000 > Sep 8 16:59:12 Insp6400 kernel: [ 0.000000] PM: Registered nosave memory: 00000000f400c000 - 00000000fec00000 > Sep 8 16:59:12 Insp6400 kernel: [ 0.000000] PM: Registered nosave memory: 00000000fec00000 - 00000000fec10000 > Sep 8 16:59:12 Insp6400 kernel: [ 0.000000] PM: Registered nosave memory: 00000000fec10000 - 00000000fed20000 > Sep 8 16:59:12 Insp6400 kernel: [ 0.000000] PM: Registered nosave memory: 00000000fed20000 - 00000000feda0000 > Sep 8 16:59:12 Insp6400 kernel: [ 0.000000] PM: Registered nosave memory: 00000000feda0000 - 00000000fee00000 > Sep 8 16:59:12 Insp6400 kernel: [ 0.000000] PM: Registered nosave memory: 00000000fee00000 - 00000000fee10000 > Sep 8 16:59:12 Insp6400 kernel: [ 0.000000] PM: Registered nosave memory: 00000000fee10000 - 00000000ffb00000 > Sep 8 16:59:12 Insp6400 kernel: [ 0.000000] PM: Registered nosave memory: 00000000ffb00000 - 0000000100000000 > Sep 8 16:59:12 Insp6400 kernel: [ 0.000000] Allocating PCI resources starting at 80000000 (gap: 80000000:70000000) > Sep 8 16:59:12 Insp6400 kernel: [ 0.000000] Booting paravirtualized kernel on Xen > Sep 8 16:59:12 Insp6400 kernel: [ 0.000000] Xen version: 4.1.1 (preserve-AD) > Sep 8 16:59:12 Insp6400 kernel: [ 0.000000] setup_percpu: NR_CPUS:512 nr_cpumask_bits:512 nr_cpu_ids:2 nr_node_ids:1 > Sep 8 16:59:12 Insp6400 kernel: [ 0.000000] PERCPU: Embedded 476 pages/cpu @ffff88007575b000 s1918464 r8192 d23040 u1949696 > Sep 8 16:59:12 Insp6400 kernel: [ 0.000000] Built 1 zonelists in Node order, mobility grouping on. Total pages: 504832 > Sep 8 16:59:12 Insp6400 kernel: [ 0.000000] Policy zone: Normal > Sep 8 16:59:12 Insp6400 kernel: [ 0.000000] Kernel command line: ro root=/dev/mapper/vg_insp6400-lv_root SYSFONT=latarcyrheb-sun16 LANG=en_US.UTF-8 KEYTABLE=us xen-pciback.permissive xen-pciback.hide=(0b:00.0) > Sep 8 16:59:12 Insp6400 kernel: [ 0.000000] PID hash table entries: 4096 (order: 3, 32768 bytes) > Sep 8 16:59:12 Insp6400 kernel: [ 0.000000] Placing 64MB software IO TLB between ffff88006f000000 - ffff880073000000 > Sep 8 16:59:12 Insp6400 kernel: [ 0.000000] software IO TLB at phys 0x6f000000 - 0x73000000 > Sep 8 16:59:12 Insp6400 kernel: [ 0.000000] Memory: 1751204k/4348948k available (5185k kernel code, 2261644k absent, 336100k reserved, 6577k data, 2780k init) > Sep 8 16:59:12 Insp6400 kernel: [ 0.000000] SLUB: Genslabs=15, HWalign=64, Order=0-3, MinObjects=0, CPUs=2, Nodes=1 > Sep 8 16:59:12 Insp6400 kernel: [ 0.000000] Hierarchical RCU implementation. > Sep 8 16:59:12 Insp6400 kernel: [ 0.000000] RCU dyntick-idle grace-period acceleration is enabled. > Sep 8 16:59:12 Insp6400 kernel: [ 0.000000] RCU lockdep checking is enabled. > Sep 8 16:59:12 Insp6400 kernel: [ 0.000000] NR_IRQS:33024 nr_irqs:512 16 > Sep 8 16:59:12 Insp6400 kernel: [ 0.000000] xen: sci override: global_irq=9 trigger=0 polarity=0 > Sep 8 16:59:12 Insp6400 kernel: [ 0.000000] xen: acpi sci 9 > Sep 8 16:59:12 Insp6400 kernel: [ 0.000000] xen_map_pirq_gsi: returning irq 9 for gsi 9 > Sep 8 16:59:12 Insp6400 kernel: [ 0.000000] Console: colour VGA+ 80x25 > Sep 8 16:59:12 Insp6400 kernel: [ 0.000000] console [tty0] enabled > Sep 8 16:59:12 Insp6400 kernel: [ 0.000000] Lock dependency validator: Copyright (c) 2006 Red Hat, Inc., Ingo Molnar > Sep 8 16:59:12 Insp6400 kernel: [ 0.000000] ... MAX_LOCKDEP_SUBCLASSES: 8 > Sep 8 16:59:12 Insp6400 kernel: [ 0.000000] ... MAX_LOCK_DEPTH: 48 > Sep 8 16:59:12 Insp6400 kernel: [ 0.000000] ... MAX_LOCKDEP_KEYS: 8191 > Sep 8 16:59:12 Insp6400 kernel: [ 0.000000] ... CLASSHASH_SIZE: 4096 > Sep 8 16:59:12 Insp6400 kernel: [ 0.000000] ... MAX_LOCKDEP_ENTRIES: 16384 > Sep 8 16:59:12 Insp6400 kernel: [ 0.000000] ... MAX_LOCKDEP_CHAINS: 32768 > Sep 8 16:59:12 Insp6400 kernel: [ 0.000000] ... CHAINHASH_SIZE: 16384 > Sep 8 16:59:12 Insp6400 kernel: [ 0.000000] memory used by lock dependency info: 6367 kB > Sep 8 16:59:12 Insp6400 kernel: [ 0.000000] per task-struct memory footprint: 2688 bytes > Sep 8 16:59:12 Insp6400 kernel: [ 0.000000] allocated 17825792 bytes of page_cgroup > Sep 8 16:59:12 Insp6400 kernel: [ 0.000000] please try 'cgroup_disable=memory' option if you don't want memory cgroups > Sep 8 16:59:12 Insp6400 kernel: [ 0.000000] installing Xen timer for CPU 0 > Sep 8 16:59:12 Insp6400 kernel: [ 0.000000] Detected 1828.796 MHz processor. > Sep 8 16:59:12 Insp6400 kernel: [ 0.000999] Calibrating delay loop (skipped), value calculated using timer frequency.. 3657.59 BogoMIPS (lpj=1828796) > Sep 8 16:59:12 Insp6400 kernel: [ 0.000999] pid_max: default: 32768 minimum: 301 > Sep 8 16:59:12 Insp6400 kernel: [ 0.000999] Security Framework initialized > Sep 8 16:59:12 Insp6400 kernel: [ 0.000999] SELinux: Initializing. > Sep 8 16:59:12 Insp6400 kernel: [ 0.002648] Dentry cache hash table entries: 262144 (order: 9, 2097152 bytes) > Sep 8 16:59:12 Insp6400 kernel: [ 0.005103] Inode-cache hash table entries: 131072 (order: 8, 1048576 bytes) > Sep 8 16:59:12 Insp6400 kernel: [ 0.005999] Mount-cache hash table entries: 256 > Sep 8 16:59:12 Insp6400 kernel: [ 0.009803] Initializing cgroup subsys cpuacct > Sep 8 16:59:12 Insp6400 kernel: [ 0.009974] Initializing cgroup subsys memory > Sep 8 16:59:12 Insp6400 kernel: [ 0.010283] Initializing cgroup subsys devices > Sep 8 16:59:12 Insp6400 kernel: [ 0.010428] Initializing cgroup subsys freezer > Sep 8 16:59:12 Insp6400 kernel: [ 0.010561] Initializing cgroup subsys net_cls > Sep 8 16:59:12 Insp6400 kernel: [ 0.010696] Initializing cgroup subsys blkio > Sep 8 16:59:12 Insp6400 kernel: [ 0.010979] Initializing cgroup subsys perf_event > Sep 8 16:59:12 Insp6400 kernel: [ 0.011518] CPU: Physical Processor ID: 0 > Sep 8 16:59:12 Insp6400 kernel: [ 0.011639] CPU: Processor Core ID: 0 > Sep 8 16:59:12 Insp6400 kernel: [ 0.012814] ACPI: Core revision 20110623 > Sep 8 16:59:12 Insp6400 kernel: [ 0.072895] ftrace: allocating 25821 entries in 102 pages > Sep 8 16:59:12 Insp6400 kernel: [ 0.075083] Performance Events: unsupported p6 CPU model 15 no PMU driver, software events only. > Sep 8 16:59:12 Insp6400 kernel: [ 0.076993] NMI watchdog disabled (cpu0): hardware events not enabled > Sep 8 16:59:12 Insp6400 kernel: [ 0.078517] installing Xen timer for CPU 1 > Sep 8 16:59:12 Insp6400 kernel: [ 0.078827] lockdep: fixing up alternatives. > Sep 8 16:59:12 Insp6400 kernel: [ 0.079572] NMI watchdog disabled (cpu1): hardware events not enabled > Sep 8 16:59:12 Insp6400 kernel: [ 0.079944] Brought up 2 CPUs > Sep 8 16:59:12 Insp6400 kernel: [ 0.083384] devtmpfs: initialized > Sep 8 16:59:12 Insp6400 kernel: [ 0.098213] atomic64 test passed for x86-64 platform with CX8 and with SSE > Sep 8 16:59:12 Insp6400 kernel: [ 0.098681] Grant table initialized > Sep 8 16:59:12 Insp6400 kernel: [ 0.098839] RTC time: 20:58:03, date: 09/08/11 > Sep 8 16:59:12 Insp6400 kernel: [ 0.099810] NET: Registered protocol family 16 > Sep 8 16:59:12 Insp6400 kernel: [ 0.106273] ACPI: bus type pci registered > Sep 8 16:59:12 Insp6400 kernel: [ 0.107787] PCI: MMCONFIG for domain 0000 [bus 00-3f] at [mem 0xf0000000-0xf3ffffff] (base 0xf0000000) > Sep 8 16:59:12 Insp6400 kernel: [ 0.107988] PCI: MMCONFIG at [mem 0xf0000000-0xf3ffffff] reserved in E820 > Sep 8 16:59:12 Insp6400 kernel: [ 0.131441] PCI: Using configuration type 1 for base access > Sep 8 16:59:12 Insp6400 kernel: [ 0.131566] dmi type 0xB1 record - unknown flag > Sep 8 16:59:12 Insp6400 kernel: [ 0.156193] bio: create slab at 0 > Sep 8 16:59:12 Insp6400 kernel: [ 0.157763] ACPI: Added _OSI(Module Device) > Sep 8 16:59:12 Insp6400 kernel: [ 0.157905] ACPI: Added _OSI(Processor Device) > Sep 8 16:59:12 Insp6400 kernel: [ 0.157984] ACPI: Added _OSI(3.0 _SCP Extensions) > Sep 8 16:59:12 Insp6400 kernel: [ 0.157984] ACPI: Added _OSI(Processor Aggregator Device) > Sep 8 16:59:12 Insp6400 kernel: [ 0.198978] ACPI: SSDT 000000007f6d4176 00202 (v01 PmRef Cpu0Ist 00003000 INTL 20050624) > Sep 8 16:59:12 Insp6400 kernel: [ 0.198978] ACPI: Dynamic OEM Table Load: > Sep 8 16:59:12 Insp6400 kernel: [ 0.198978] ACPI: SSDT (null) 00202 (v01 PmRef Cpu0Ist 00003000 INTL 20050624) > Sep 8 16:59:12 Insp6400 kernel: [ 0.198978] ACPI: SSDT 000000007f6d3f2b 001C6 (v01 PmRef Cpu0Cst 00003001 INTL 20050624) > Sep 8 16:59:12 Insp6400 kernel: [ 0.198978] ACPI: Dynamic OEM Table Load: > Sep 8 16:59:12 Insp6400 kernel: [ 0.198978] ACPI: SSDT (null) 001C6 (v01 PmRef Cpu0Cst 00003001 INTL 20050624) > Sep 8 16:59:12 Insp6400 kernel: [ 0.198978] ACPI: SSDT 000000007f6d4378 000C4 (v01 PmRef Cpu1Ist 00003000 INTL 20050624) > Sep 8 16:59:12 Insp6400 kernel: [ 0.198978] ACPI: Dynamic OEM Table Load: > Sep 8 16:59:12 Insp6400 kernel: [ 0.198978] ACPI: SSDT (null) 000C4 (v01 PmRef Cpu1Ist 00003000 INTL 20050624) > Sep 8 16:59:12 Insp6400 kernel: [ 0.200036] ACPI: SSDT 000000007f6d40f1 00085 (v01 PmRef Cpu1Cst 00003000 INTL 20050624) > Sep 8 16:59:12 Insp6400 kernel: [ 0.200978] ACPI: Dynamic OEM Table Load: > Sep 8 16:59:12 Insp6400 kernel: [ 0.200978] ACPI: SSDT (null) 00085 (v01 PmRef Cpu1Cst 00003000 INTL 20050624) > Sep 8 16:59:12 Insp6400 kernel: [ 0.200978] ACPI: Interpreter enabled > Sep 8 16:59:12 Insp6400 kernel: [ 0.200978] ACPI: (supports S0 S3 S4 S5) > Sep 8 16:59:12 Insp6400 kernel: [ 0.200978] ACPI: Using IOAPIC for interrupt routing > Sep 8 16:59:12 Insp6400 kernel: [ 0.482935] ACPI: No dock devices found. > Sep 8 16:59:12 Insp6400 kernel: [ 0.482935] HEST: Table not found. > Sep 8 16:59:12 Insp6400 kernel: [ 0.482935] PCI: Ignoring host bridge windows from ACPI; if necessary, use "pci=use_crs" and report a bug > Sep 8 16:59:12 Insp6400 kernel: [ 0.503932] ACPI: PCI Root Bridge [PCI0] (domain 0000 [bus 00-ff]) > Sep 8 16:59:12 Insp6400 kernel: [ 0.553924] pci 0000:00:1f.0: quirk: [io 0x1000-0x107f] claimed by ICH6 ACPI/GPIO/TCO > Sep 8 16:59:12 Insp6400 kernel: [ 0.553924] pci 0000:00:1f.0: quirk: [io 0x1080-0x10bf] claimed by ICH6 GPIO > Sep 8 16:59:12 Insp6400 kernel: [ 0.553924] pci 0000:00:1f.0: ICH7 LPC Generic IO decode 1 PIO at 0900 (mask 007f) > Sep 8 16:59:12 Insp6400 kernel: [ 0.553924] pci 0000:00:1f.0: ICH7 LPC Generic IO decode 3 PIO at 0c80 (mask 003f) > Sep 8 16:59:12 Insp6400 kernel: [ 0.556351] pci 0000:0b:00.0: disabling ASPM on pre-1.1 PCIe device. You can enable it with 'pcie_aspm=force' > Sep 8 16:59:12 Insp6400 kernel: [ 0.556718] pci 0000:00:1c.0: PCI bridge to [bus 0b-0b] > Sep 8 16:59:12 Insp6400 kernel: [ 0.557827] pci 0000:00:1c.3: PCI bridge to [bus 0c-0d] > Sep 8 16:59:12 Insp6400 kernel: [ 0.560923] pci 0000:00:1e.0: PCI bridge to [bus 03-03] (subtractive decode) > Sep 8 16:59:12 Insp6400 kernel: [ 0.560923] pci 0000:00:1c.0: Dev MPS 128 MPSS 128 MRRS 128 > Sep 8 16:59:12 Insp6400 kernel: [ 0.560923] pci 0000:00:1c.0: Dev MPS 128 MPSS 128 MRRS 128 > Sep 8 16:59:12 Insp6400 kernel: [ 0.560923] pci 0000:0b:00.0: Dev MPS 128 MPSS 128 MRRS 128 > Sep 8 16:59:12 Insp6400 kernel: [ 0.560923] pci 0000:0b:00.0: Dev MPS 128 MPSS 128 MRRS 128 > Sep 8 16:59:12 Insp6400 kernel: [ 0.560923] pci 0000:00:1c.3: Dev MPS 128 MPSS 128 MRRS 128 > Sep 8 16:59:12 Insp6400 kernel: [ 0.560923] pci 0000:00:1c.3: Dev MPS 128 MPSS 128 MRRS 128 > Sep 8 16:59:12 Insp6400 kernel: [ 0.560923] pci 0000:0c:00.0: Dev MPS 128 MPSS 128 MRRS 512 > Sep 8 16:59:12 Insp6400 kernel: [ 0.560923] pci 0000:0c:00.0: Dev MPS 128 MPSS 128 MRRS 128 > Sep 8 16:59:12 Insp6400 kernel: [ 0.563923] pci0000:00: Requesting ACPI _OSC control (0x1d) > Sep 8 16:59:12 Insp6400 kernel: [ 0.563923] pci0000:00: ACPI _OSC request failed (AE_NOT_FOUND), returned control mask: 0x1d > Sep 8 16:59:12 Insp6400 kernel: [ 0.563923] ACPI _OSC control for PCIe not granted, disabling ASPM > Sep 8 16:59:12 Insp6400 kernel: [ 0.596918] ACPI: PCI Interrupt Link [LNKA] (IRQs 9 10 *11) > Sep 8 16:59:12 Insp6400 kernel: [ 0.597918] ACPI: PCI Interrupt Link [LNKB] (IRQs 5 7) *4 > Sep 8 16:59:12 Insp6400 kernel: [ 0.598917] ACPI: PCI Interrupt Link [LNKC] (IRQs 9 10 *11) > Sep 8 16:59:12 Insp6400 kernel: [ 0.599917] ACPI: PCI Interrupt Link [LNKD] (IRQs 5 7 9 10 11) *3 > Sep 8 16:59:12 Insp6400 kernel: [ 0.601917] ACPI: PCI Interrupt Link [LNKE] (IRQs 3 4 5 6 7 *9 10 11 12 14 15) > Sep 8 16:59:12 Insp6400 kernel: [ 0.602917] ACPI: PCI Interrupt Link [LNKF] (IRQs 3 4 5 6 7 9 *10 11 12 14 15) > Sep 8 16:59:12 Insp6400 kernel: [ 0.603917] ACPI: PCI Interrupt Link [LNKG] (IRQs 3 4 5 6 *7 9 10 11 12 14 15) > Sep 8 16:59:12 Insp6400 kernel: [ 0.604917] ACPI: PCI Interrupt Link [LNKH] (IRQs 3 4 *5 6 7 9 10 11 12 14 15) > Sep 8 16:59:12 Insp6400 kernel: [ 0.605055] xen/balloon: Initialising balloon driver. > Sep 8 16:59:12 Insp6400 kernel: [ 0.605209] last_pfn = 0x109705 max_arch_pfn = 0x400000000 > Sep 8 16:59:12 Insp6400 kernel: [ 0.607009] xen-balloon: Initialising balloon driver. > Sep 8 16:59:12 Insp6400 kernel: [ 0.607682] xen/balloon: Xen selfballooning driver disabled for domain0. > Sep 8 16:59:12 Insp6400 kernel: [ 0.608752] vgaarb: device added: PCI:0000:00:02.0,decodes=io+mem,owns=io+mem,locks=none > Sep 8 16:59:12 Insp6400 kernel: [ 0.608916] vgaarb: loaded > Sep 8 16:59:12 Insp6400 kernel: [ 0.608916] vgaarb: bridge control possible 0000:00:02.0 > Sep 8 16:59:12 Insp6400 kernel: [ 0.611750] SCSI subsystem initialized > Sep 8 16:59:12 Insp6400 kernel: [ 0.613519] usbcore: registered new interface driver usbfs > Sep 8 16:59:12 Insp6400 kernel: [ 0.613915] usbcore: registered new interface driver hub > Sep 8 16:59:12 Insp6400 kernel: [ 0.614163] usbcore: registered new device driver usb > Sep 8 16:59:12 Insp6400 kernel: [ 0.615756] PCI: Using ACPI for IRQ routing > Sep 8 16:59:12 Insp6400 kernel: [ 0.618444] NetLabel: Initializing > Sep 8 16:59:12 Insp6400 kernel: [ 0.618560] NetLabel: domain hash size = 128 > Sep 8 16:59:12 Insp6400 kernel: [ 0.618677] NetLabel: protocols = UNLABELED CIPSOv4 > Sep 8 16:59:12 Insp6400 kernel: [ 0.618914] NetLabel: unlabeled traffic allowed by default > Sep 8 16:59:12 Insp6400 kernel: [ 0.618914] Switching to clocksource xen > Sep 8 16:59:12 Insp6400 kernel: [ 0.619312] Switched to NOHz mode on CPU #1 > Sep 8 16:59:12 Insp6400 kernel: [ 0.620099] Switched to NOHz mode on CPU #0 > Sep 8 16:59:12 Insp6400 kernel: [ 0.989037] pnp: PnP ACPI init > Sep 8 16:59:12 Insp6400 kernel: [ 0.989190] ACPI: bus type pnp registered > Sep 8 16:59:12 Insp6400 kernel: [ 1.456722] system 00:00: [mem 0x00000000-0x0009fbff] could not be reserved > Sep 8 16:59:12 Insp6400 kernel: [ 1.456898] system 00:00: [mem 0x0009fc00-0x0009ffff] could not be reserved > Sep 8 16:59:12 Insp6400 kernel: [ 1.457013] system 00:00: [mem 0x000c0000-0x000cffff] could not be reserved > Sep 8 16:59:12 Insp6400 kernel: [ 1.457013] system 00:00: [mem 0x000e0000-0x000fffff] could not be reserved > Sep 8 16:59:12 Insp6400 kernel: [ 1.457013] system 00:00: [mem 0x00100000-0x7f6d33ff] could not be reserved > Sep 8 16:59:12 Insp6400 kernel: [ 1.457013] system 00:00: [mem 0x7f6d3400-0x7f6fffff] has been reserved > Sep 8 16:59:12 Insp6400 kernel: [ 1.457013] system 00:00: [mem 0x7f700000-0x7f7fffff] has been reserved > Sep 8 16:59:12 Insp6400 kernel: [ 1.457013] system 00:00: [mem 0x7f700000-0x7fefffff] could not be reserved > Sep 8 16:59:12 Insp6400 kernel: [ 1.457013] system 00:00: [mem 0xffb00000-0xffffffff] has been reserved > Sep 8 16:59:12 Insp6400 kernel: [ 1.457013] system 00:00: [mem 0xfec00000-0xfec0ffff] could not be reserved > Sep 8 16:59:12 Insp6400 kernel: [ 1.457013] system 00:00: [mem 0xfee00000-0xfee0ffff] has been reserved > Sep 8 16:59:12 Insp6400 kernel: [ 1.457013] system 00:00: [mem 0xfed20000-0xfed9ffff] has been reserved > Sep 8 16:59:12 Insp6400 kernel: [ 1.457013] system 00:00: [mem 0xffa80000-0xffa83fff] could not be reserved > Sep 8 16:59:12 Insp6400 kernel: [ 1.457013] system 00:00: [mem 0xf4000000-0xf4003fff] has been reserved > Sep 8 16:59:12 Insp6400 kernel: [ 1.457013] system 00:00: [mem 0xf4004000-0xf4004fff] has been reserved > Sep 8 16:59:12 Insp6400 kernel: [ 1.459154] system 00:00: [mem 0xf4005000-0xf4005fff] has been reserved > Sep 8 16:59:12 Insp6400 kernel: [ 1.459308] system 00:00: [mem 0xf4006000-0xf4006fff] has been reserved > Sep 8 16:59:12 Insp6400 kernel: [ 1.459460] system 00:00: [mem 0xf4008000-0xf400bfff] has been reserved > Sep 8 16:59:12 Insp6400 kernel: [ 1.459612] system 00:00: [mem 0xf0000000-0xf3ffffff] has been reserved > Sep 8 16:59:12 Insp6400 kernel: [ 1.807294] pnp 00:02: disabling [io 0x1000-0x1005] because it overlaps 0000:00:1f.0 BAR 13 [io 0x1000-0x107f] > Sep 8 16:59:12 Insp6400 kernel: [ 1.807294] pnp 00:02: disabling [io 0x1008-0x100f] because it overlaps 0000:00:1f.0 BAR 13 [io 0x1000-0x107f] > Sep 8 16:59:12 Insp6400 kernel: [ 1.808907] system 00:02: [io 0x04d0-0x04d1] has been reserved > Sep 8 16:59:12 Insp6400 kernel: [ 1.810282] pnp 00:03: disabling [io 0x1006-0x1007] because it overlaps 0000:00:1f.0 BAR 13 [io 0x1000-0x107f] > Sep 8 16:59:12 Insp6400 kernel: [ 1.810485] pnp 00:03: disabling [io 0x100a-0x1059] because it overlaps 0000:00:1f.0 BAR 13 [io 0x1000-0x107f] > Sep 8 16:59:12 Insp6400 kernel: [ 1.810687] pnp 00:03: disabling [io 0x1060-0x107f] because it overlaps 0000:00:1f.0 BAR 13 [io 0x1000-0x107f] > Sep 8 16:59:12 Insp6400 kernel: [ 1.810888] pnp 00:03: disabling [io 0x1010-0x102f] because it overlaps 0000:00:1f.0 BAR 13 [io 0x1000-0x107f] > Sep 8 16:59:12 Insp6400 kernel: [ 1.812279] system 00:03: [io 0xf400-0xf4fe] has been reserved > Sep 8 16:59:12 Insp6400 kernel: [ 1.812427] system 00:03: [io 0x1080-0x10bf] has been reserved > Sep 8 16:59:12 Insp6400 kernel: [ 1.812573] system 00:03: [io 0x10c0-0x10df] has been reserved > Sep 8 16:59:12 Insp6400 kernel: [ 1.812720] system 00:03: [io 0x0809] has been reserved > Sep 8 16:59:12 Insp6400 kernel: [ 1.813570] xen_map_pirq_gsi: returning irq 12 for gsi 12 > Sep 8 16:59:12 Insp6400 kernel: [ 1.815255] xen_map_pirq_gsi: returning irq 1 for gsi 1 > Sep 8 16:59:12 Insp6400 kernel: [ 1.816800] xen_map_pirq_gsi: returning irq 8 for gsi 8 > Sep 8 16:59:12 Insp6400 kernel: [ 1.821590] system 00:08: [io 0x0c80-0x0cff] could not be reserved > Sep 8 16:59:12 Insp6400 kernel: [ 1.821740] system 00:08: [io 0x0910-0x091f] has been reserved > Sep 8 16:59:12 Insp6400 kernel: [ 1.821886] system 00:08: [io 0x0920-0x092f] has been reserved > Sep 8 16:59:12 Insp6400 kernel: [ 1.822034] system 00:08: [io 0x0cb0-0x0cbf] has been reserved > Sep 8 16:59:12 Insp6400 kernel: [ 1.822220] system 00:08: [io 0x0930-0x097f] has been reserved > Sep 8 16:59:12 Insp6400 kernel: [ 1.824669] xen_map_pirq_gsi: returning irq 13 for gsi 13 > Sep 8 16:59:12 Insp6400 kernel: [ 1.829472] system 00:0b: [mem 0xfed00000-0xfed003ff] has been reserved > Sep 8 16:59:12 Insp6400 kernel: [ 1.830351] pnp: PnP ACPI: found 12 devices > Sep 8 16:59:12 Insp6400 kernel: [ 1.830351] ACPI: ACPI bus type pnp unregistered > Sep 8 16:59:12 Insp6400 kernel: [ 1.917290] PM-Timer failed consistency check (0x0xffffff) - aborting. > Sep 8 16:59:12 Insp6400 kernel: [ 1.918064] pci 0000:00:1c.0: BAR 15: assigned [mem 0x80000000-0x801fffff 64bit pref] > Sep 8 16:59:12 Insp6400 kernel: [ 1.918064] pci 0000:00:1c.0: BAR 13: assigned [io 0x2000-0x2fff] > Sep 8 16:59:12 Insp6400 kernel: [ 1.918064] pci 0000:00:1c.0: PCI bridge to [bus 0b-0b] > Sep 8 16:59:12 Insp6400 kernel: [ 1.918064] pci 0000:00:1c.0: bridge window [io 0x2000-0x2fff] > Sep 8 16:59:12 Insp6400 kernel: [ 1.918064] pci 0000:00:1c.0: bridge window [mem 0xefd00000-0xefdfffff] > Sep 8 16:59:12 Insp6400 kernel: [ 1.918064] pci 0000:00:1c.0: bridge window [mem 0x80000000-0x801fffff 64bit pref] > Sep 8 16:59:12 Insp6400 kernel: [ 1.918064] pci 0000:00:1c.3: PCI bridge to [bus 0c-0d] > Sep 8 16:59:12 Insp6400 kernel: [ 1.918064] pci 0000:00:1c.3: bridge window [io 0xd000-0xdfff] > Sep 8 16:59:12 Insp6400 kernel: [ 1.918064] pci 0000:00:1c.3: bridge window [mem 0xefb00000-0xefcfffff] > Sep 8 16:59:12 Insp6400 kernel: [ 1.918064] pci 0000:00:1c.3: bridge window [mem 0xe0000000-0xe01fffff 64bit pref] > Sep 8 16:59:12 Insp6400 kernel: [ 1.918064] pci 0000:00:1e.0: PCI bridge to [bus 03-03] > Sep 8 16:59:12 Insp6400 kernel: [ 1.918064] pci 0000:00:1e.0: bridge window [mem 0xefa00000-0xefafffff] > Sep 8 16:59:12 Insp6400 kernel: [ 1.920218] pci 0000:00:1c.0: PCI INT A -> GSI 16 (level, low) -> IRQ 16 > Sep 8 16:59:12 Insp6400 kernel: [ 1.920458] pci 0000:00:1c.3: PCI INT D -> GSI 19 (level, low) -> IRQ 19 > Sep 8 16:59:12 Insp6400 kernel: [ 1.921279] NET: Registered protocol family 2 > Sep 8 16:59:12 Insp6400 kernel: [ 1.923153] IP route cache hash table entries: 65536 (order: 7, 524288 bytes) > Sep 8 16:59:12 Insp6400 kernel: [ 1.931845] TCP established hash table entries: 262144 (order: 10, 4194304 bytes) > Sep 8 16:59:12 Insp6400 kernel: [ 1.940386] TCP bind hash table entries: 65536 (order: 10, 5242880 bytes) > Sep 8 16:59:12 Insp6400 kernel: [ 1.954064] TCP: Hash tables configured (established 262144 bind 65536) > Sep 8 16:59:12 Insp6400 kernel: [ 1.954064] TCP reno registered > Sep 8 16:59:12 Insp6400 kernel: [ 1.956489] UDP hash table entries: 1024 (order: 5, 196608 bytes) > Sep 8 16:59:12 Insp6400 kernel: [ 1.957465] UDP-Lite hash table entries: 1024 (order: 5, 196608 bytes) > Sep 8 16:59:12 Insp6400 kernel: [ 1.959559] NET: Registered protocol family 1 > Sep 8 16:59:12 Insp6400 kernel: [ 1.962217] Unpacking initramfs... > Sep 8 16:59:12 Insp6400 kernel: [ 2.873066] Freeing initrd memory: 41320k freed > Sep 8 16:59:12 Insp6400 kernel: [ 3.259725] DMA-API: preallocated 32768 debug entries > Sep 8 16:59:12 Insp6400 kernel: [ 3.259856] DMA-API: debugging enabled by kernel config > Sep 8 16:59:12 Insp6400 kernel: [ 3.260062] Simple Boot Flag at 0x79 set to 0x80 > Sep 8 16:59:12 Insp6400 kernel: [ 3.271644] Intel AES-NI instructions are not detected. > Sep 8 16:59:12 Insp6400 kernel: [ 3.271653] cryptomgr_test used greatest stack depth: 6088 bytes left > Sep 8 16:59:12 Insp6400 kernel: [ 3.274831] audit: initializing netlink socket (disabled) > Sep 8 16:59:12 Insp6400 kernel: [ 3.275128] type=2000 audit(1315515487.194:1): initialized > Sep 8 16:59:12 Insp6400 kernel: [ 3.311148] HugeTLB registered 2 MB page size, pre-allocated 0 pages > Sep 8 16:59:12 Insp6400 kernel: [ 3.397870] VFS: Disk quotas dquot_6.5.2 > Sep 8 16:59:12 Insp6400 kernel: [ 3.399100] Dquot-cache hash table entries: 512 (order 0, 4096 bytes) > Sep 8 16:59:12 Insp6400 kernel: [ 3.413418] msgmni has been set to 3501 > Sep 8 16:59:12 Insp6400 kernel: [ 3.420261] cryptomgr_test used greatest stack depth: 5512 bytes left > Sep 8 16:59:12 Insp6400 kernel: [ 3.422194] cryptomgr_test used greatest stack depth: 5448 bytes left > Sep 8 16:59:12 Insp6400 kernel: [ 3.422470] alg: No test for stdrng (krng) > Sep 8 16:59:12 Insp6400 kernel: [ 3.422652] NET: Registered protocol family 38 > Sep 8 16:59:12 Insp6400 kernel: [ 3.423923] Block layer SCSI generic (bsg) driver version 0.4 loaded (major 253) > Sep 8 16:59:12 Insp6400 kernel: [ 3.424491] io scheduler noop registered > Sep 8 16:59:12 Insp6400 kernel: [ 3.424610] io scheduler deadline registered > Sep 8 16:59:12 Insp6400 kernel: [ 3.426320] io scheduler cfq registered (default) > Sep 8 16:59:12 Insp6400 kernel: [ 3.426438] start plist test > Sep 8 16:59:12 Insp6400 kernel: [ 3.427727] end plist test > Sep 8 16:59:12 Insp6400 kernel: [ 3.443402] BUG: scheduling while atomic: swapper/1/0x10000002 > Sep 8 16:59:12 Insp6400 kernel: [ 3.443521] 3 locks held by swapper/1: > Sep 8 16:59:12 Insp6400 kernel: [ 3.443632] #0: (&__lockdep_no_validate__){......}, at: [] __driver_attach+0x3b/0x82 > Sep 8 16:59:12 Insp6400 kernel: [ 3.443945] #1: (&__lockdep_no_validate__){......}, at: [] __driver_attach+0x49/0x82 > Sep 8 16:59:12 Insp6400 kernel: [ 3.444258] #2: (irq_mapping_update_lock){+.+.+.}, at: [] xen_bind_pirq_msi_to_irq+0x31/0xda > Sep 8 16:59:12 Insp6400 kernel: [ 3.444371] Modules linked in: > Sep 8 16:59:12 Insp6400 kernel: [ 3.444371] Pid: 1, comm: swapper Not tainted 3.1.0-0.rc5.git0.0.fc17.x86_64 #1 > Sep 8 16:59:12 Insp6400 kernel: [ 3.444371] Call Trace: > Sep 8 16:59:12 Insp6400 kernel: [ 3.444371] [] __schedule_bug+0x75/0x7a > Sep 8 16:59:12 Insp6400 kernel: [ 3.444371] [] schedule+0x95/0x7bb > Sep 8 16:59:12 Insp6400 kernel: [ 3.444371] [] ? xen_force_evtchn_callback+0xd/0xf > Sep 8 16:59:12 Insp6400 kernel: [ 3.444371] [] ? xen_force_evtchn_callback+0xd/0xf > Sep 8 16:59:12 Insp6400 kernel: [ 3.444371] [] __cond_resched+0x28/0x34 > Sep 8 16:59:12 Insp6400 kernel: [ 3.444371] [] _cond_resched+0x19/0x22 > Sep 8 16:59:12 Insp6400 kernel: [ 3.444371] [] mutex_lock_nested+0x2a/0x45 > Sep 8 16:59:12 Insp6400 kernel: [ 3.444371] [] __irq_alloc_descs+0x50/0x18b > Sep 8 16:59:12 Insp6400 kernel: [ 3.444371] [] ? kzalloc.constprop.1+0x2/0x15 > Sep 8 16:59:12 Insp6400 kernel: [ 3.444371] [] xen_allocate_irq_dynamic+0x49/0x58 > Sep 8 16:59:12 Insp6400 kernel: [ 3.444371] [] xen_bind_pirq_msi_to_irq+0x36/0xda > Sep 8 16:59:12 Insp6400 kernel: [ 3.444371] [] xen_initdom_setup_msi_irqs+0x129/0x15d > Sep 8 16:59:12 Insp6400 kernel: [ 3.444371] [] pci_enable_msi_block+0x1c0/0x225 > Sep 8 16:59:12 Insp6400 kernel: [ 3.444371] [] pcie_port_device_register+0x308/0x464 > Sep 8 16:59:12 Insp6400 kernel: [ 3.444371] [] ? check_events+0x12/0x20 > Sep 8 16:59:12 Insp6400 kernel: [ 3.444371] [] ? xen_restore_fl_direct_reloc+0x4/0x4 > Sep 8 16:59:12 Insp6400 kernel: [ 3.444371] [] pcie_portdrv_probe+0x57/0x6e > Sep 8 16:59:12 Insp6400 kernel: [ 3.444371] [] local_pci_probe+0x44/0x75 > Sep 8 16:59:12 Insp6400 kernel: [ 3.444371] [] pci_device_probe+0xd0/0xff > Sep 8 16:59:12 Insp6400 kernel: [ 3.444371] [] driver_probe_device+0x131/0x213 > Sep 8 16:59:12 Insp6400 kernel: [ 3.444371] [] __driver_attach+0x5e/0x82 > Sep 8 16:59:12 Insp6400 kernel: [ 3.444371] [] ? driver_probe_device+0x213/0x213 > Sep 8 16:59:12 Insp6400 kernel: [ 3.444371] [] bus_for_each_dev+0x59/0x8f > Sep 8 16:59:12 Insp6400 kernel: [ 3.444371] [] driver_attach+0x1e/0x20 > Sep 8 16:59:12 Insp6400 kernel: [ 3.444371] [] bus_add_driver+0xd4/0x22a > Sep 8 16:59:12 Insp6400 kernel: [ 3.444371] [] ? dmi_pcie_pme_disable_msi+0x21/0x21 > Sep 8 16:59:12 Insp6400 kernel: [ 3.444371] [] driver_register+0x98/0x105 > Sep 8 16:59:12 Insp6400 kernel: [ 3.444371] [] ? dmi_pcie_pme_disable_msi+0x21/0x21 > Sep 8 16:59:12 Insp6400 kernel: [ 3.444371] [] __pci_register_driver+0x66/0xd2 > Sep 8 16:59:12 Insp6400 kernel: [ 3.444371] [] ? dmi_pcie_pme_disable_msi+0x21/0x21 > Sep 8 16:59:12 Insp6400 kernel: [ 3.444371] [] pcie_portdrv_init+0x66/0x77 > Sep 8 16:59:12 Insp6400 kernel: [ 3.444371] [] do_one_initcall+0x7f/0x13a > Sep 8 16:59:12 Insp6400 kernel: [ 3.444371] [] kernel_init+0xdf/0x159 > Sep 8 16:59:12 Insp6400 kernel: [ 3.444371] [] kernel_thread_helper+0x4/0x10 > Sep 8 16:59:12 Insp6400 kernel: [ 3.444371] [] ? retint_restore_args+0x13/0x13 > Sep 8 16:59:12 Insp6400 kernel: [ 3.444371] [] ? gs_change+0x13/0x13 > Sep 8 16:59:12 Insp6400 kernel: [ 3.454101] pci_hotplug: PCI Hot Plug PCI Core version: 0.5 > Sep 8 16:59:12 Insp6400 kernel: [ 3.455760] pciehp: PCI Express Hot Plug Controller Driver version: 0.4 > Sep 8 16:59:12 Insp6400 kernel: [ 3.455881] acpiphp: ACPI Hot Plug PCI Controller Driver version: 0.5 > Sep 8 16:59:12 Insp6400 kernel: [ 3.466064] acpiphp: Slot [1] registered > Sep 8 16:59:12 Insp6400 kernel: [ 3.473115] ACPI: Deprecated procfs I/F for AC is loaded, please retry with CONFIG_ACPI_PROCFS_POWER cleared > Sep 8 16:59:12 Insp6400 kernel: [ 3.478671] ACPI: AC Adapter [AC] (on-line) > Sep 8 16:59:12 Insp6400 kernel: [ 3.484582] input: Lid Switch as /devices/LNXSYSTM:00/device:00/PNP0C0D:00/input/input0 > Sep 8 16:59:12 Insp6400 kernel: [ 3.491334] ACPI: Lid Switch [LID] > Sep 8 16:59:12 Insp6400 kernel: [ 3.492686] input: Power Button as /devices/LNXSYSTM:00/device:00/PNP0C0C:00/input/input1 > Sep 8 16:59:12 Insp6400 kernel: [ 3.492984] ACPI: Power Button [PBTN] > Sep 8 16:59:12 Insp6400 kernel: [ 3.494386] input: Sleep Button as /devices/LNXSYSTM:00/device:00/PNP0C0E:00/input/input2 > Sep 8 16:59:12 Insp6400 kernel: [ 3.494619] ACPI: Sleep Button [SBTN] > Sep 8 16:59:12 Insp6400 kernel: [ 3.677074] thermal LNXTHERM:00: registered as thermal_zone0 > Sep 8 16:59:12 Insp6400 kernel: [ 3.677074] ACPI: Thermal Zone [THM] (67 C) > Sep 8 16:59:12 Insp6400 kernel: [ 3.677074] ERST: Table is not found! > Sep 8 16:59:12 Insp6400 kernel: [ 3.677074] GHES: HEST is not enabled! > Sep 8 16:59:12 Insp6400 kernel: [ 3.697940] Serial: 8250/16550 driver, 4 ports, IRQ sharing enabled > Sep 8 16:59:12 Insp6400 kernel: [ 4.212769] hpet_acpi_add: no address or irqs in _CRS > Sep 8 16:59:12 Insp6400 kernel: [ 4.214384] Non-volatile memory driver v1.3 > Sep 8 16:59:12 Insp6400 kernel: [ 4.214500] Linux agpgart interface v0.103 > Sep 8 16:59:12 Insp6400 kernel: [ 4.216385] agpgart-intel 0000:00:00.0: Intel 945GM Chipset > Sep 8 16:59:12 Insp6400 kernel: [ 4.223021] agpgart-intel 0000:00:00.0: detected gtt size: 262144K total, 262144K mappable > Sep 8 16:59:12 Insp6400 kernel: [ 4.224301] agpgart-intel 0000:00:00.0: detected 8192K stolen memory > Sep 8 16:59:12 Insp6400 kernel: [ 4.228213] agpgart-intel 0000:00:00.0: AGP aperture is 256M @ 0xd0000000 > Sep 8 16:59:12 Insp6400 kernel: [ 4.254675] loop: module loaded > Sep 8 16:59:12 Insp6400 kernel: [ 4.258041] ata_piix 0000:00:1f.2: PCI INT B -> GSI 17 (level, low) -> IRQ 17 > Sep 8 16:59:12 Insp6400 kernel: [ 4.258195] ata_piix 0000:00:1f.2: MAP [ P0 P2 IDE IDE ] > Sep 8 16:59:12 Insp6400 kernel: [ 4.271431] scsi0 : ata_piix > Sep 8 16:59:12 Insp6400 kernel: [ 4.276528] scsi1 : ata_piix > Sep 8 16:59:12 Insp6400 kernel: [ 4.392230] ACPI: Deprecated procfs I/F for battery is loaded, please retry with CONFIG_ACPI_PROCFS_POWER cleared > Sep 8 16:59:12 Insp6400 kernel: [ 4.392657] ACPI: Battery Slot [BAT0] (battery present) > Sep 8 16:59:12 Insp6400 kernel: [ 4.393060] ata1: SATA max UDMA/133 cmd 0x1f0 ctl 0x3f6 bmdma 0xbfa0 irq 14 > Sep 8 16:59:12 Insp6400 kernel: [ 4.393060] ata2: PATA max UDMA/100 cmd 0x170 ctl 0x376 bmdma 0xbfa8 irq 15 > Sep 8 16:59:12 Insp6400 kernel: [ 4.424981] Fixed MDIO Bus: probed > Sep 8 16:59:12 Insp6400 kernel: [ 4.426586] ehci_hcd: USB 2.0 'Enhanced' Host Controller (EHCI) Driver > Sep 8 16:59:12 Insp6400 kernel: [ 4.427023] ehci_hcd 0000:00:1d.7: PCI INT A -> GSI 20 (level, low) -> IRQ 20 > Sep 8 16:59:12 Insp6400 kernel: [ 4.427370] ehci_hcd 0000:00:1d.7: EHCI Host Controller > Sep 8 16:59:12 Insp6400 kernel: [ 4.430277] ehci_hcd 0000:00:1d.7: new USB bus registered, assigned bus number 1 > Sep 8 16:59:12 Insp6400 kernel: [ 4.430996] ehci_hcd 0000:00:1d.7: using broken periodic workaround > Sep 8 16:59:12 Insp6400 kernel: [ 4.431157] ehci_hcd 0000:00:1d.7: debug port 1 > Sep 8 16:59:12 Insp6400 kernel: [ 4.435644] ehci_hcd 0000:00:1d.7: irq 20, io mem 0xffa80000 > Sep 8 16:59:12 Insp6400 kernel: [ 4.445141] ehci_hcd 0000:00:1d.7: USB 2.0 started, EHCI 1.00 > Sep 8 16:59:12 Insp6400 kernel: [ 4.446274] usb usb1: New USB device found, idVendor=1d6b, idProduct=0002 > Sep 8 16:59:12 Insp6400 kernel: [ 4.446395] usb usb1: New USB device strings: Mfr=3, Product=2, SerialNumber=1 > Sep 8 16:59:12 Insp6400 kernel: [ 4.446594] usb usb1: Product: EHCI Host Controller > Sep 8 16:59:12 Insp6400 kernel: [ 4.446709] usb usb1: Manufacturer: Linux 3.1.0-0.rc5.git0.0.fc17.x86_64 ehci_hcd > Sep 8 16:59:12 Insp6400 kernel: [ 4.446910] usb usb1: SerialNumber: 0000:00:1d.7 > Sep 8 16:59:12 Insp6400 kernel: [ 4.451034] hub 1-0:1.0: USB hub found > Sep 8 16:59:12 Insp6400 kernel: [ 4.451501] hub 1-0:1.0: 8 ports detected > Sep 8 16:59:12 Insp6400 kernel: [ 4.455464] ohci_hcd: USB 1.1 'Open' Host Controller (OHCI) Driver > Sep 8 16:59:12 Insp6400 kernel: [ 4.455903] uhci_hcd: USB Universal Host Controller Interface driver > Sep 8 16:59:12 Insp6400 kernel: [ 4.457042] xen_map_pirq_gsi: returning irq 20 for gsi 20 > Sep 8 16:59:12 Insp6400 kernel: [ 4.457197] Already setup the GSI :20 > Sep 8 16:59:12 Insp6400 kernel: [ 4.457312] uhci_hcd 0000:00:1d.0: PCI INT A -> GSI 20 (level, low) -> IRQ 20 > Sep 8 16:59:12 Insp6400 kernel: [ 4.457556] uhci_hcd 0000:00:1d.0: UHCI Host Controller > Sep 8 16:59:12 Insp6400 kernel: [ 4.459067] uhci_hcd 0000:00:1d.0: new USB bus registered, assigned bus number 2 > Sep 8 16:59:12 Insp6400 kernel: [ 4.459582] uhci_hcd 0000:00:1d.0: irq 20, io base 0x0000bf80 > Sep 8 16:59:12 Insp6400 kernel: [ 4.460826] usb usb2: New USB device found, idVendor=1d6b, idProduct=0001 > Sep 8 16:59:12 Insp6400 kernel: [ 4.460946] usb usb2: New USB device strings: Mfr=3, Product=2, SerialNumber=1 > Sep 8 16:59:12 Insp6400 kernel: [ 4.461107] usb usb2: Product: UHCI Host Controller > Sep 8 16:59:12 Insp6400 kernel: [ 4.461107] usb usb2: Manufacturer: Linux 3.1.0-0.rc5.git0.0.fc17.x86_64 uhci_hcd > Sep 8 16:59:12 Insp6400 kernel: [ 4.461107] usb usb2: SerialNumber: 0000:00:1d.0 > Sep 8 16:59:12 Insp6400 kernel: [ 4.464642] hub 2-0:1.0: USB hub found > Sep 8 16:59:12 Insp6400 kernel: [ 4.465008] hub 2-0:1.0: 2 ports detected > Sep 8 16:59:12 Insp6400 kernel: [ 4.467877] uhci_hcd 0000:00:1d.1: PCI INT B -> GSI 21 (level, low) -> IRQ 21 > Sep 8 16:59:12 Insp6400 kernel: [ 4.468100] uhci_hcd 0000:00:1d.1: UHCI Host Controller > Sep 8 16:59:12 Insp6400 kernel: [ 4.469667] uhci_hcd 0000:00:1d.1: new USB bus registered, assigned bus number 3 > Sep 8 16:59:12 Insp6400 kernel: [ 4.470616] uhci_hcd 0000:00:1d.1: irq 21, io base 0x0000bf60 > Sep 8 16:59:12 Insp6400 kernel: [ 4.471789] usb usb3: New USB device found, idVendor=1d6b, idProduct=0001 > Sep 8 16:59:12 Insp6400 kernel: [ 4.471906] usb usb3: New USB device strings: Mfr=3, Product=2, SerialNumber=1 > Sep 8 16:59:12 Insp6400 kernel: [ 4.472067] usb usb3: Product: UHCI Host Controller > Sep 8 16:59:12 Insp6400 kernel: [ 4.472067] usb usb3: Manufacturer: Linux 3.1.0-0.rc5.git0.0.fc17.x86_64 uhci_hcd > Sep 8 16:59:12 Insp6400 kernel: [ 4.472067] usb usb3: SerialNumber: 0000:00:1d.1 > Sep 8 16:59:12 Insp6400 kernel: [ 4.475616] hub 3-0:1.0: USB hub found > Sep 8 16:59:12 Insp6400 kernel: [ 4.475997] hub 3-0:1.0: 2 ports detected > Sep 8 16:59:12 Insp6400 kernel: [ 4.478904] uhci_hcd 0000:00:1d.2: PCI INT C -> GSI 22 (level, low) -> IRQ 22 > Sep 8 16:59:12 Insp6400 kernel: [ 4.479125] uhci_hcd 0000:00:1d.2: UHCI Host Controller > Sep 8 16:59:12 Insp6400 kernel: [ 4.480689] uhci_hcd 0000:00:1d.2: new USB bus registered, assigned bus number 4 > Sep 8 16:59:12 Insp6400 kernel: [ 4.481497] uhci_hcd 0000:00:1d.2: irq 22, io base 0x0000bf40 > Sep 8 16:59:12 Insp6400 kernel: [ 4.482727] usb usb4: New USB device found, idVendor=1d6b, idProduct=0001 > Sep 8 16:59:12 Insp6400 kernel: [ 4.482847] usb usb4: New USB device strings: Mfr=3, Product=2, SerialNumber=1 > Sep 8 16:59:12 Insp6400 kernel: [ 4.483045] usb usb4: Product: UHCI Host Controller > Sep 8 16:59:12 Insp6400 kernel: [ 4.483112] usb usb4: Manufacturer: Linux 3.1.0-0.rc5.git0.0.fc17.x86_64 uhci_hcd > Sep 8 16:59:12 Insp6400 kernel: [ 4.483112] usb usb4: SerialNumber: 0000:00:1d.2 > Sep 8 16:59:12 Insp6400 kernel: [ 4.487100] hub 4-0:1.0: USB hub found > Sep 8 16:59:12 Insp6400 kernel: [ 4.487448] hub 4-0:1.0: 2 ports detected > Sep 8 16:59:12 Insp6400 kernel: [ 4.490377] uhci_hcd 0000:00:1d.3: PCI INT D -> GSI 23 (level, low) -> IRQ 23 > Sep 8 16:59:12 Insp6400 kernel: [ 4.490603] uhci_hcd 0000:00:1d.3: UHCI Host Controller > Sep 8 16:59:12 Insp6400 kernel: [ 4.492088] uhci_hcd 0000:00:1d.3: new USB bus registered, assigned bus number 5 > Sep 8 16:59:12 Insp6400 kernel: [ 4.492944] uhci_hcd 0000:00:1d.3: irq 23, io base 0x0000bf20 > Sep 8 16:59:12 Insp6400 kernel: [ 4.494309] usb usb5: New USB device found, idVendor=1d6b, idProduct=0001 > Sep 8 16:59:12 Insp6400 kernel: [ 4.494428] usb usb5: New USB device strings: Mfr=3, Product=2, SerialNumber=1 > Sep 8 16:59:12 Insp6400 kernel: [ 4.494624] usb usb5: Product: UHCI Host Controller > Sep 8 16:59:12 Insp6400 kernel: [ 4.494738] usb usb5: Manufacturer: Linux 3.1.0-0.rc5.git0.0.fc17.x86_64 uhci_hcd > Sep 8 16:59:12 Insp6400 kernel: [ 4.494932] usb usb5: SerialNumber: 0000:00:1d.3 > Sep 8 16:59:12 Insp6400 kernel: [ 4.497976] hub 5-0:1.0: USB hub found > Sep 8 16:59:12 Insp6400 kernel: [ 4.498443] hub 5-0:1.0: 2 ports detected > Sep 8 16:59:12 Insp6400 kernel: [ 4.502842] usbcore: registered new interface driver usbserial > Sep 8 16:59:12 Insp6400 kernel: [ 4.503371] USB Serial support registered for generic > Sep 8 16:59:12 Insp6400 kernel: [ 4.503830] usbcore: registered new interface driver usbserial_generic > Sep 8 16:59:12 Insp6400 kernel: [ 4.503946] usbserial: USB Serial Driver core > Sep 8 16:59:12 Insp6400 kernel: [ 4.504766] i8042: PNP: PS/2 Controller [PNP0303:KBC,PNP0f13:PS2M] at 0x60,0x64 irq 1,12 > Sep 8 16:59:12 Insp6400 kernel: [ 4.508443] serio: i8042 KBD port at 0x60,0x64 irq 1 > Sep 8 16:59:12 Insp6400 kernel: [ 4.508800] serio: i8042 AUX port at 0x60,0x64 irq 12 > Sep 8 16:59:12 Insp6400 kernel: [ 4.511728] mousedev: PS/2 mouse device common for all mice > Sep 8 16:59:12 Insp6400 kernel: [ 4.516800] rtc_cmos 00:06: RTC can wake from S4 > Sep 8 16:59:12 Insp6400 kernel: [ 4.519077] rtc_cmos 00:06: rtc core: registered rtc_cmos as rtc0 > Sep 8 16:59:12 Insp6400 kernel: [ 4.519522] rtc0: alarms up to one month, y3k, 114 bytes nvram > Sep 8 16:59:12 Insp6400 kernel: [ 4.522072] input: AT Translated Set 2 keyboard as /devices/platform/i8042/serio0/input/input3 > Sep 8 16:59:12 Insp6400 kernel: [ 4.526931] device-mapper: uevent: version 1.0.3 > Sep 8 16:59:12 Insp6400 kernel: [ 4.530694] device-mapper: ioctl: 4.21.0-ioctl (2011-07-06) initialised: dm-devel@redhat.com > Sep 8 16:59:12 Insp6400 kernel: [ 4.542007] EFI Variables Facility v0.08 2004-May-17 > Sep 8 16:59:12 Insp6400 kernel: [ 4.547159] usbcore: registered new interface driver usbhid > Sep 8 16:59:12 Insp6400 kernel: [ 4.547280] usbhid: USB HID core driver > Sep 8 16:59:12 Insp6400 kernel: [ 4.554367] ip_tables: (C) 2000-2006 Netfilter Core Team > Sep 8 16:59:12 Insp6400 kernel: [ 4.554688] TCP cubic registered > Sep 8 16:59:12 Insp6400 kernel: [ 4.554804] Initializing XFRM netlink socket > Sep 8 16:59:12 Insp6400 kernel: [ 4.559769] NET: Registered protocol family 10 > Sep 8 16:59:12 Insp6400 kernel: [ 4.574100] Mobile IPv6 > Sep 8 16:59:12 Insp6400 kernel: [ 4.574591] NET: Registered protocol family 17 > Sep 8 16:59:12 Insp6400 kernel: [ 4.575116] Registering the dns_resolver key type > Sep 8 16:59:12 Insp6400 kernel: [ 4.578852] ata1.00: HPA detected: current 75200265, native 78140160 > Sep 8 16:59:12 Insp6400 kernel: [ 4.578978] ata1.00: ATA-6: TOSHIBA MK4032GSX, AS212D, max UDMA/100 > Sep 8 16:59:12 Insp6400 kernel: [ 4.579098] ata1.00: 75200265 sectors, multi 8: LBA48 NCQ (depth 0/32) > Sep 8 16:59:12 Insp6400 kernel: [ 4.580054] registered taskstats version 1 > Sep 8 16:59:12 Insp6400 kernel: [ 4.581431] IMA: No TPM chip found, activating TPM-bypass! > Sep 8 16:59:12 Insp6400 kernel: [ 4.587959] ata1.00: configured for UDMA/100 > Sep 8 16:59:12 Insp6400 kernel: [ 4.590949] scsi 0:0:0:0: Direct-Access ATA TOSHIBA MK4032GS AS21 PQ: 0 ANSI: 5 > Sep 8 16:59:12 Insp6400 kernel: [ 4.593951] ata2.00: ATAPI: TSSTcorpCD-RW/DVD-ROM TSL462C, DE01, max UDMA/33 > Sep 8 16:59:12 Insp6400 kernel: [ 4.595845] Magic number: 11:184:1003 > Sep 8 16:59:12 Insp6400 kernel: [ 4.596143] input input0: hash matches > Sep 8 16:59:12 Insp6400 kernel: [ 4.596301] vc vcs: hash matches > Sep 8 16:59:12 Insp6400 kernel: [ 4.596421] i8042 kbd 00:05: hash matches > Sep 8 16:59:12 Insp6400 kernel: [ 4.597332] rtc_cmos 00:06: setting system clock to 2011-09-08 20:58:10 UTC (1315515490) > Sep 8 16:59:12 Insp6400 kernel: [ 4.605886] sd 0:0:0:0: [sda] 75200265 512-byte logical blocks: (38.5 GB/35.8 GiB) > Sep 8 16:59:12 Insp6400 kernel: [ 4.607916] sd 0:0:0:0: [sda] Write Protect is off > Sep 8 16:59:12 Insp6400 kernel: [ 4.608795] sd 0:0:0:0: [sda] Write cache: enabled, read cache: enabled, doesn't support DPO or FUA > Sep 8 16:59:12 Insp6400 kernel: [ 4.613095] sd 0:0:0:0: Attached scsi generic sg0 type 0 > Sep 8 16:59:12 Insp6400 kernel: [ 4.616777] ata2.00: configured for UDMA/33 > Sep 8 16:59:12 Insp6400 kernel: [ 4.622502] scsi 1:0:0:0: CD-ROM TSSTcorp CDRW/DVD TSL462C DE01 PQ: 0 ANSI: 5 > Sep 8 16:59:12 Insp6400 kernel: [ 4.625298] Initializing network drop monitor service > Sep 8 16:59:12 Insp6400 kernel: [ 4.627200] sr0: scsi3-mmc drive: 24x/24x writer cd/rw xa/form2 cdda tray > Sep 8 16:59:12 Insp6400 kernel: [ 4.627339] cdrom: Uniform CD-ROM driver Revision: 3.20 > Sep 8 16:59:12 Insp6400 kernel: [ 4.634936] sr 1:0:0:0: Attached scsi generic sg1 type 5 > Sep 8 16:59:12 Insp6400 kernel: [ 4.659570] sda: sda1 sda2 sda3 > Sep 8 16:59:12 Insp6400 kernel: [ 4.668851] sd 0:0:0:0: [sda] Attached SCSI disk > Sep 8 16:59:12 Insp6400 kernel: [ 4.674686] Freeing unused kernel memory: 2780k freed > Sep 8 16:59:12 Insp6400 kernel: [ 4.676066] Write protecting the kernel read-only data: 10240k > Sep 8 16:59:12 Insp6400 kernel: [ 4.698892] Freeing unused kernel memory: 940k freed > Sep 8 16:59:12 Insp6400 kernel: [ 4.703360] Freeing unused kernel memory: 1424k freed > Sep 8 16:59:12 Insp6400 kernel: [ 4.727089] mknod used greatest stack depth: 5120 bytes left > Sep 8 16:59:12 Insp6400 kernel: [ 4.895081] mount used greatest stack depth: 4968 bytes left > Sep 8 16:59:12 Insp6400 kernel: [ 5.214678] Synaptics Touchpad, model: 1, fw: 6.2, id: 0x180b1, caps: 0xa04713/0x200000/0x0 > Sep 8 16:59:12 Insp6400 kernel: [ 5.253303] input: SynPS/2 Synaptics TouchPad as /devices/platform/i8042/serio1/input/input4 > Sep 8 16:59:12 Insp6400 kernel: [ 5.676103] udevadm used greatest stack depth: 4904 bytes left > Sep 8 16:59:12 Insp6400 kernel: [ 6.138176] console_init used greatest stack depth: 4848 bytes left > Sep 8 16:59:12 Insp6400 kernel: [ 6.342404] acpi device:28: registered as cooling_device2 > Sep 8 16:59:12 Insp6400 kernel: [ 6.350194] input: Video Bus as /devices/LNXSYSTM:00/device:00/PNP0A03:00/LNXVIDEO:01/input/input5 > Sep 8 16:59:12 Insp6400 kernel: [ 6.352172] ACPI: Video Device [VID1] (multi-head: yes rom: no post: no) > Sep 8 16:59:12 Insp6400 kernel: [ 6.352796] [Firmware Bug]: Duplicate ACPI video bus devices for the same VGA controller, please try module parameter "video.allow_duplicates=1"if the current driver doesn't work. > Sep 8 16:59:12 Insp6400 kernel: [ 6.386874] [drm] Initialized drm 1.1.0 20060810 > Sep 8 16:59:12 Insp6400 kernel: [ 6.424884] xen_map_pirq_gsi: returning irq 16 for gsi 16 > Sep 8 16:59:12 Insp6400 kernel: [ 6.425012] Already setup the GSI :16 > Sep 8 16:59:12 Insp6400 kernel: [ 6.425068] i915 0000:00:02.0: PCI INT A -> GSI 16 (level, low) -> IRQ 16 > Sep 8 16:59:12 Insp6400 kernel: [ 6.859099] [drm] MTRR allocation failed. Graphics performance may suffer. > Sep 8 16:59:12 Insp6400 kernel: [ 6.882694] [drm] Supports vblank timestamp caching Rev 1 (10.10.2010). > Sep 8 16:59:12 Insp6400 kernel: [ 6.882817] [drm] Driver supports precise vblank timestamp query. > Sep 8 16:59:12 Insp6400 kernel: [ 6.884526] vgaarb: device changed decodes: PCI:0000:00:02.0,olddecodes=io+mem,decodes=io+mem:owns=io+mem > Sep 8 16:59:12 Insp6400 kernel: [ 7.201153] [drm] initialized overlay support > Sep 8 16:59:12 Insp6400 kernel: [ 7.483956] fbcon: inteldrmfb (fb0) is primary device > Sep 8 16:59:12 Insp6400 kernel: [ 7.671279] Console: switching to colour frame buffer device 160x50 > Sep 8 16:59:12 Insp6400 kernel: [ 7.676066] fb0: inteldrmfb frame buffer device > Sep 8 16:59:12 Insp6400 kernel: [ 7.676066] drm: registered panic notifier > Sep 8 16:59:12 Insp6400 kernel: [ 7.676415] [drm] Initialized i915 1.6.0 20080730 for 0000:00:02.0 on minor 0 > Sep 8 16:59:12 Insp6400 kernel: [ 7.682068] modprobe used greatest stack depth: 2800 bytes left > Sep 8 16:59:12 Insp6400 kernel: [ 9.301111] wmi: Mapper loaded > Sep 8 16:59:12 Insp6400 kernel: [ 9.665528] xen_map_pirq_gsi: returning irq 19 for gsi 19 > Sep 8 16:59:12 Insp6400 kernel: [ 9.665588] Already setup the GSI :19 > Sep 8 16:59:12 Insp6400 kernel: [ 9.665622] firewire_ohci 0000:03:01.0: PCI INT A -> GSI 19 (level, low) -> IRQ 19 > Sep 8 16:59:12 Insp6400 kernel: [ 9.696404] sdhci: Secure Digital Host Controller Interface driver > Sep 8 16:59:12 Insp6400 kernel: [ 9.696465] sdhci: Copyright(c) Pierre Ossman > Sep 8 16:59:12 Insp6400 kernel: [ 9.727406] firewire_ohci: Added fw-ohci device 0000:03:01.0, OHCI v1.10, 4 IR + 4 IT contexts, quirks 0x1 > Sep 8 16:59:12 Insp6400 kernel: [ 9.732408] sdhci-pci 0000:03:01.1: SDHCI controller found [1180:0822] (rev 19) > Sep 8 16:59:12 Insp6400 kernel: [ 9.732532] BUG: sleeping function called from invalid context at kernel/mutex.c:271 > Sep 8 16:59:12 Insp6400 kernel: [ 9.732592] in_atomic(): 1, irqs_disabled(): 0, pid: 245, name: modprobe > Sep 8 16:59:12 Insp6400 kernel: [ 9.732645] 3 locks held by modprobe/245: > Sep 8 16:59:12 Insp6400 kernel: [ 9.732679] #0: (&__lockdep_no_validate__){......}, at: [] __driver_attach+0x3b/0x82 > Sep 8 16:59:12 Insp6400 kernel: [ 9.732784] #1: (&__lockdep_no_validate__){......}, at: [] __driver_attach+0x49/0x82 > Sep 8 16:59:12 Insp6400 kernel: [ 9.732885] #2: (irq_mapping_update_lock){+.+.+.}, at: [] xen_bind_pirq_gsi_to_irq+0x2e/0x1a2 > Sep 8 16:59:12 Insp6400 kernel: [ 9.732988] Pid: 245, comm: modprobe Not tainted 3.1.0-0.rc5.git0.0.fc17.x86_64 #1 > Sep 8 16:59:12 Insp6400 kernel: [ 9.733046] Call Trace: > Sep 8 16:59:12 Insp6400 kernel: [ 9.733067] [] __might_sleep+0x103/0x108 > Sep 8 16:59:12 Insp6400 kernel: [ 9.733067] [] mutex_lock_nested+0x25/0x45 > Sep 8 16:59:12 Insp6400 kernel: [ 9.733067] [] __irq_alloc_descs+0x50/0x18b > Sep 8 16:59:12 Insp6400 kernel: [ 9.733067] [] xen_bind_pirq_gsi_to_irq+0xb2/0x1a2 > Sep 8 16:59:12 Insp6400 kernel: [ 9.733067] [] ? arch_local_irq_restore+0xb/0xd > Sep 8 16:59:12 Insp6400 kernel: [ 9.733067] [] xen_register_pirq+0x8b/0xb7 > Sep 8 16:59:12 Insp6400 kernel: [ 9.733067] [] xen_register_gsi.part.2+0x41/0x9f > Sep 8 16:59:12 Insp6400 kernel: [ 9.733067] [] acpi_register_gsi_xen+0x1e/0x20 > Sep 8 16:59:12 Insp6400 kernel: [ 9.733067] [] acpi_register_gsi+0xf/0x18 > Sep 8 16:59:12 Insp6400 kernel: [ 9.733067] [] acpi_pci_irq_enable+0x172/0x246 > Sep 8 16:59:12 Insp6400 kernel: [ 9.733067] [] pcibios_enable_device+0x2b/0x30 > Sep 8 16:59:12 Insp6400 kernel: [ 9.733067] [] do_pci_enable_device+0x30/0x48 > Sep 8 16:59:12 Insp6400 kernel: [ 9.749832] [] __pci_enable_device_flags+0x77/0x8a > Sep 8 16:59:12 Insp6400 kernel: [ 9.749832] [] pci_enable_device+0x13/0x15 > Sep 8 16:59:12 Insp6400 kernel: [ 9.749832] [] sdhci_pci_probe+0xf0/0x416 [sdhci_pci] > Sep 8 16:59:12 Insp6400 kernel: [ 9.749832] [] ? xen_restore_fl_direct_reloc+0x4/0x4 > Sep 8 16:59:12 Insp6400 kernel: [ 9.749832] [] ? arch_local_irq_restore+0xb/0xd > Sep 8 16:59:12 Insp6400 kernel: [ 9.749832] [] ? _raw_spin_unlock_irqrestore+0x4d/0x61 > Sep 8 16:59:12 Insp6400 kernel: [ 9.749832] [] local_pci_probe+0x44/0x75 > Sep 8 16:59:12 Insp6400 kernel: [ 9.749832] [] pci_device_probe+0xd0/0xff > Sep 8 16:59:12 Insp6400 kernel: [ 9.749832] [] driver_probe_device+0x131/0x213 > Sep 8 16:59:12 Insp6400 kernel: [ 9.749832] [] __driver_attach+0x5e/0x82 > Sep 8 16:59:12 Insp6400 kernel: [ 9.749832] [] ? driver_probe_device+0x213/0x213 > Sep 8 16:59:12 Insp6400 kernel: [ 9.749832] [] bus_for_each_dev+0x59/0x8f > Sep 8 16:59:12 Insp6400 kernel: [ 9.749832] [] driver_attach+0x1e/0x20 > Sep 8 16:59:12 Insp6400 kernel: [ 9.749832] [] bus_add_driver+0xd4/0x22a > Sep 8 16:59:12 Insp6400 kernel: [ 9.749832] [] ? 0xffffffffa00fbfff > Sep 8 16:59:12 Insp6400 kernel: [ 9.749832] [] driver_register+0x98/0x105 > Sep 8 16:59:12 Insp6400 kernel: [ 9.749832] [] ? 0xffffffffa00fbfff > Sep 8 16:59:12 Insp6400 kernel: [ 9.749832] [] __pci_register_driver+0x66/0xd2 > Sep 8 16:59:12 Insp6400 kernel: [ 9.749832] [] ? 0xffffffffa00fbfff > Sep 8 16:59:12 Insp6400 kernel: [ 9.749832] [] sdhci_drv_init+0x1e/0x1000 [sdhci_pci] > Sep 8 16:59:12 Insp6400 kernel: [ 9.749832] [] do_one_initcall+0x7f/0x13a > Sep 8 16:59:12 Insp6400 kernel: [ 9.749832] [] ? 0xffffffffa00fbfff > Sep 8 16:59:12 Insp6400 kernel: [ 9.749832] [] sys_init_module+0x114/0x267 > Sep 8 16:59:12 Insp6400 kernel: [ 9.749832] [] system_call_fastpath+0x16/0x1b > Sep 8 16:59:12 Insp6400 kernel: [ 9.749832] BUG: scheduling while atomic: modprobe/245/0x10000002 > Sep 8 16:59:12 Insp6400 kernel: [ 9.749832] 3 locks held by modprobe/245: > Sep 8 16:59:12 Insp6400 kernel: [ 9.749832] #0: (&__lockdep_no_validate__){......}, at: [] __driver_attach+0x3b/0x82 > Sep 8 16:59:12 Insp6400 kernel: [ 9.749832] #1: (&__lockdep_no_validate__){......}, at: [] __driver_attach+0x49/0x82 > Sep 8 16:59:12 Insp6400 kernel: [ 9.749832] #2: (irq_mapping_update_lock){+.+.+.}, at: [] xen_bind_pirq_gsi_to_irq+0x2e/0x1a2 > Sep 8 16:59:12 Insp6400 kernel: [ 9.749832] Modules linked in: sdhci_pci(+) sdhci mmc_core firewire_ohci firewire_core crc_itu_t wmi i915 drm_kms_helper drm i2c_algo_bit i2c_core video > Sep 8 16:59:12 Insp6400 kernel: [ 9.749832] Pid: 245, comm: modprobe Not tainted 3.1.0-0.rc5.git0.0.fc17.x86_64 #1 > Sep 8 16:59:12 Insp6400 kernel: [ 9.749832] Call Trace: > Sep 8 16:59:12 Insp6400 kernel: [ 9.749832] [] __schedule_bug+0x75/0x7a > Sep 8 16:59:12 Insp6400 kernel: [ 9.749832] [] schedule+0x95/0x7bb > Sep 8 16:59:12 Insp6400 kernel: [ 9.749832] [] ? show_trace_log_lvl+0x54/0x5d > Sep 8 16:59:12 Insp6400 kernel: [ 9.749832] [] ? show_trace+0x15/0x17 > Sep 8 16:59:12 Insp6400 kernel: [ 9.749832] [] __cond_resched+0x28/0x34 > Sep 8 16:59:12 Insp6400 kernel: [ 9.749832] [] _cond_resched+0x19/0x22 > Sep 8 16:59:12 Insp6400 kernel: [ 9.749832] [] mutex_lock_nested+0x2a/0x45 > Sep 8 16:59:12 Insp6400 kernel: [ 9.749832] [] __irq_alloc_descs+0x50/0x18b > Sep 8 16:59:12 Insp6400 kernel: [ 9.749832] [] xen_bind_pirq_gsi_to_irq+0xb2/0x1a2 > Sep 8 16:59:12 Insp6400 kernel: [ 9.749832] [] ? arch_local_irq_restore+0xb/0xd > Sep 8 16:59:12 Insp6400 kernel: [ 9.749832] [] xen_register_pirq+0x8b/0xb7 > Sep 8 16:59:12 Insp6400 kernel: [ 9.749832] [] xen_register_gsi.part.2+0x41/0x9f > Sep 8 16:59:12 Insp6400 kernel: [ 9.749832] [] acpi_register_gsi_xen+0x1e/0x20 > Sep 8 16:59:12 Insp6400 kernel: [ 9.749832] [] acpi_register_gsi+0xf/0x18 > Sep 8 16:59:12 Insp6400 kernel: [ 9.749832] [] acpi_pci_irq_enable+0x172/0x246 > Sep 8 16:59:12 Insp6400 kernel: [ 9.749832] [] pcibios_enable_device+0x2b/0x30 > Sep 8 16:59:12 Insp6400 kernel: [ 9.749832] [] do_pci_enable_device+0x30/0x48 > Sep 8 16:59:12 Insp6400 kernel: [ 9.749832] [] __pci_enable_device_flags+0x77/0x8a > Sep 8 16:59:12 Insp6400 kernel: [ 9.749832] [] pci_enable_device+0x13/0x15 > Sep 8 16:59:12 Insp6400 kernel: [ 9.749832] [] sdhci_pci_probe+0xf0/0x416 [sdhci_pci] > Sep 8 16:59:12 Insp6400 kernel: [ 9.749832] [] ? xen_restore_fl_direct_reloc+0x4/0x4 > Sep 8 16:59:12 Insp6400 kernel: [ 9.749832] [] ? arch_local_irq_restore+0xb/0xd > Sep 8 16:59:12 Insp6400 kernel: [ 9.749832] [] ? _raw_spin_unlock_irqrestore+0x4d/0x61 > Sep 8 16:59:12 Insp6400 kernel: [ 9.749832] [] local_pci_probe+0x44/0x75 > Sep 8 16:59:12 Insp6400 kernel: [ 9.749832] [] pci_device_probe+0xd0/0xff > Sep 8 16:59:12 Insp6400 kernel: [ 9.749832] [] driver_probe_device+0x131/0x213 > Sep 8 16:59:12 Insp6400 kernel: [ 9.749832] [] __driver_attach+0x5e/0x82 > Sep 8 16:59:12 Insp6400 kernel: [ 9.749832] [] ? driver_probe_device+0x213/0x213 > Sep 8 16:59:12 Insp6400 kernel: [ 9.749832] [] bus_for_each_dev+0x59/0x8f > Sep 8 16:59:12 Insp6400 kernel: [ 9.749832] [] driver_attach+0x1e/0x20 > Sep 8 16:59:12 Insp6400 kernel: [ 9.749832] [] bus_add_driver+0xd4/0x22a > Sep 8 16:59:12 Insp6400 kernel: [ 9.749832] [] ? 0xffffffffa00fbfff > Sep 8 16:59:12 Insp6400 kernel: [ 9.749832] [] driver_register+0x98/0x105 > Sep 8 16:59:12 Insp6400 kernel: [ 9.749832] [] ? 0xffffffffa00fbfff > Sep 8 16:59:12 Insp6400 kernel: [ 9.749832] [] __pci_register_driver+0x66/0xd2 > Sep 8 16:59:12 Insp6400 kernel: [ 9.749832] [] ? 0xffffffffa00fbfff > Sep 8 16:59:12 Insp6400 kernel: [ 9.749832] [] sdhci_drv_init+0x1e/0x1000 [sdhci_pci] > Sep 8 16:59:12 Insp6400 kernel: [ 9.749832] [] do_one_initcall+0x7f/0x13a > Sep 8 16:59:12 Insp6400 kernel: [ 9.749832] [] ? 0xffffffffa00fbfff > Sep 8 16:59:12 Insp6400 kernel: [ 9.749832] [] sys_init_module+0x114/0x267 > Sep 8 16:59:12 Insp6400 kernel: [ 9.749832] [] system_call_fastpath+0x16/0x1b > Sep 8 16:59:12 Insp6400 kernel: [ 9.935093] sdhci-pci 0000:03:01.1: PCI INT B -> GSI 18 (level, low) -> IRQ 18 > Sep 8 16:59:12 Insp6400 kernel: [ 9.949666] mmc0: SDHCI controller on PCI [0000:03:01.1] using DMA > Sep 8 16:59:12 Insp6400 kernel: [ 10.232950] firewire_core: created device fw0: GUID 444fc0000e8ad921, S400 > Sep 8 16:59:12 Insp6400 kernel: [ 17.102941] EXT4-fs (dm-0): mounted filesystem with ordered data mode. Opts: (null) > Sep 8 16:59:12 Insp6400 kernel: [ 17.489192] EXT4-fs (dm-0): mounted filesystem with ordered data mode. Opts: (null) > Sep 8 16:59:12 Insp6400 kernel: [ 38.466327] type=1403 audit(1315515524.369:2): policy loaded auid=4294967295 ses=4294967295 > Sep 8 16:59:12 Insp6400 kernel: [ 47.240444] EXT4-fs (dm-0): re-mounted. Opts: (null) > Sep 8 16:59:12 Insp6400 kernel: [ 48.864074] Event-channel device installed. > Sep 8 16:59:12 Insp6400 kernel: [ 50.134162] tun: Universal TUN/TAP device driver, 1.6 > Sep 8 16:59:12 Insp6400 kernel: [ 50.135064] tun: (C) 1999-2004 Max Krasnyansky > Sep 8 16:59:12 Insp6400 kernel: [ 52.495009] intel_rng: FWH not detected > Sep 8 16:59:12 Insp6400 kernel: [ 52.664154] iTCO_vendor_support: vendor-support=0 > Sep 8 16:59:12 Insp6400 kernel: [ 52.789276] iTCO_wdt: Intel TCO WatchDog Timer Driver v1.06 > Sep 8 16:59:12 Insp6400 kernel: [ 52.825541] iTCO_wdt: Found a ICH7-M or ICH7-U TCO device (Version=2, TCOBASE=0x1060) > Sep 8 16:59:12 Insp6400 kernel: [ 52.945236] iTCO_wdt: initialized. heartbeat=30 sec (nowayout=0) > Sep 8 16:59:12 Insp6400 kernel: [ 52.954853] r8169 Gigabit Ethernet driver 2.3LK-NAPI loaded > Sep 8 16:59:12 Insp6400 kernel: [ 52.959351] xen_map_pirq_gsi: returning irq 19 for gsi 19 > Sep 8 16:59:12 Insp6400 kernel: [ 52.960876] Already setup the GSI :19 > Sep 8 16:59:12 Insp6400 kernel: [ 52.961768] r8169 0000:0c:00.0: PCI INT A -> GSI 19 (level, low) -> IRQ 19 > Sep 8 16:59:12 Insp6400 kernel: [ 52.971581] BUG: sleeping function called from invalid context at kernel/mutex.c:271 > Sep 8 16:59:12 Insp6400 kernel: [ 52.972086] in_atomic(): 1, irqs_disabled(): 0, pid: 510, name: modprobe > Sep 8 16:59:12 Insp6400 kernel: [ 52.972086] 3 locks held by modprobe/510: > Sep 8 16:59:12 Insp6400 kernel: [ 52.972086] #0: (&__lockdep_no_validate__){......}, at: [] __driver_attach+0x3b/0x82 > Sep 8 16:59:12 Insp6400 kernel: [ 52.972086] #1: (&__lockdep_no_validate__){......}, at: [] __driver_attach+0x49/0x82 > Sep 8 16:59:12 Insp6400 kernel: [ 52.972086] #2: (irq_mapping_update_lock){+.+.+.}, at: [] xen_bind_pirq_msi_to_irq+0x31/0xda > Sep 8 16:59:12 Insp6400 kernel: [ 52.972086] Pid: 510, comm: modprobe Not tainted 3.1.0-0.rc5.git0.0.fc17.x86_64 #1 > Sep 8 16:59:12 Insp6400 kernel: [ 52.972086] Call Trace: > Sep 8 16:59:12 Insp6400 kernel: [ 52.972086] [] __might_sleep+0x103/0x108 > Sep 8 16:59:12 Insp6400 kernel: [ 52.972086] [] mutex_lock_nested+0x25/0x45 > Sep 8 16:59:12 Insp6400 kernel: [ 52.972086] [] __irq_alloc_descs+0x50/0x18b > Sep 8 16:59:12 Insp6400 kernel: [ 52.972086] [] ? kzalloc.constprop.1+0x2/0x15 > Sep 8 16:59:12 Insp6400 kernel: [ 52.972086] [] xen_allocate_irq_dynamic+0x49/0x58 > Sep 8 16:59:12 Insp6400 kernel: [ 52.972086] [] xen_bind_pirq_msi_to_irq+0x36/0xda > Sep 8 16:59:12 Insp6400 kernel: [ 52.972086] [] xen_initdom_setup_msi_irqs+0x129/0x15d > Sep 8 16:59:12 Insp6400 kernel: [ 52.972086] [] pci_enable_msi_block+0x1c0/0x225 > Sep 8 16:59:12 Insp6400 kernel: [ 52.972086] [] rtl8169_init_one+0x515/0x85c [r8169] > Sep 8 16:59:12 Insp6400 kernel: [ 52.972086] [] ? xen_restore_fl_direct_reloc+0x4/0x4 > Sep 8 16:59:12 Insp6400 kernel: [ 52.972086] [] ? arch_local_irq_restore+0xb/0xd > Sep 8 16:59:12 Insp6400 kernel: [ 52.972086] [] local_pci_probe+0x44/0x75 > Sep 8 16:59:12 Insp6400 kernel: [ 52.972086] [] pci_device_probe+0xd0/0xff > Sep 8 16:59:12 Insp6400 kernel: [ 52.972086] [] driver_probe_device+0x131/0x213 > Sep 8 16:59:12 Insp6400 kernel: [ 52.972086] [] __driver_attach+0x5e/0x82 > Sep 8 16:59:12 Insp6400 kernel: [ 52.972086] [] ? driver_probe_device+0x213/0x213 > Sep 8 16:59:12 Insp6400 kernel: [ 52.972086] [] bus_for_each_dev+0x59/0x8f > Sep 8 16:59:12 Insp6400 kernel: [ 52.972086] [] driver_attach+0x1e/0x20 > Sep 8 16:59:12 Insp6400 kernel: [ 52.972086] [] bus_add_driver+0xd4/0x22a > Sep 8 16:59:12 Insp6400 kernel: [ 52.972086] [] ? 0xffffffffa01befff > Sep 8 16:59:12 Insp6400 kernel: [ 52.972086] [] driver_register+0x98/0x105 > Sep 8 16:59:12 Insp6400 kernel: [ 52.972086] [] ? 0xffffffffa01befff > Sep 8 16:59:12 Insp6400 kernel: [ 52.972086] [] __pci_register_driver+0x66/0xd2 > Sep 8 16:59:12 Insp6400 kernel: [ 52.972086] [] ? 0xffffffffa01befff > Sep 8 16:59:12 Insp6400 kernel: [ 52.972086] [] rtl8169_init_module+0x1e/0x1000 [r8169] > Sep 8 16:59:12 Insp6400 kernel: [ 52.972086] [] do_one_initcall+0x7f/0x13a > Sep 8 16:59:12 Insp6400 kernel: [ 52.972086] [] ? 0xffffffffa01befff > Sep 8 16:59:12 Insp6400 kernel: [ 52.972086] [] sys_init_module+0x114/0x267 > Sep 8 16:59:12 Insp6400 kernel: [ 52.972086] [] system_call_fastpath+0x16/0x1b > Sep 8 16:59:12 Insp6400 kernel: [ 53.125576] cfg80211: Calling CRDA to update world regulatory domain > Sep 8 16:59:12 Insp6400 kernel: [ 53.225315] microcode: CPU0 sig=0x6f6, pf=0x20, revision=0xc7 > Sep 8 16:59:12 Insp6400 kernel: [ 53.390418] r8169 0000:0c:00.0: eth0: RTL8168d/8111d at 0xffffc90000378000, 00:e0:4c:68:23:0d, XID 081000c0 IRQ 286 > Sep 8 16:59:12 Insp6400 kernel: [ 53.457417] dcdbas dcdbas: Dell Systems Management Base Driver (version 5.6.0-3.2) > Sep 8 16:59:12 Insp6400 kernel: [ 53.463253] xen_map_pirq_gsi: returning irq 17 for gsi 17 > Sep 8 16:59:12 Insp6400 kernel: [ 53.465100] Already setup the GSI :17 > Sep 8 16:59:12 Insp6400 kernel: [ 53.466083] i801_smbus 0000:00:1f.3: PCI INT B -> GSI 17 (level, low) -> IRQ 17 > Sep 8 16:59:12 Insp6400 kernel: [ 53.675021] xen_map_pirq_gsi: returning irq 17 for gsi 17 > Sep 8 16:59:12 Insp6400 kernel: [ 53.676759] Already setup the GSI :17 > Sep 8 16:59:12 Insp6400 kernel: [ 53.677696] b44 0000:03:00.0: PCI INT A -> GSI 17 (level, low) -> IRQ 17 > Sep 8 16:59:12 Insp6400 kernel: [ 53.799234] ssb: Sonics Silicon Backplane found on PCI device 0000:03:00.0 > Sep 8 16:59:12 Insp6400 kernel: [ 53.952106] b44: Broadcom 44xx/47xx 10/100 PCI ethernet driver version 2.0 > Sep 8 16:59:12 Insp6400 kernel: [ 54.034482] xen_map_pirq_gsi: returning irq 18 for gsi 18 > Sep 8 16:59:12 Insp6400 kernel: [ 54.036108] Already setup the GSI :18 > Sep 8 16:59:12 Insp6400 kernel: [ 54.037461] r592 0000:03:01.2: PCI INT B -> GSI 18 (level, low) -> IRQ 18 > Sep 8 16:59:12 Insp6400 kernel: [ 54.051070] b44 ssb0:0: eth1: Broadcom 44xx/47xx 10/100 PCI ethernet driver 00:15:c5:04:7d:4f > Sep 8 16:59:12 Insp6400 kernel: [ 54.058267] r592: driver successfully loaded > Sep 8 16:59:12 Insp6400 kernel: [ 54.301138] leds_ss4200: no LED devices found > Sep 8 16:59:12 Insp6400 kernel: [ 54.361679] xen_map_pirq_gsi: returning irq 18 for gsi 18 > Sep 8 16:59:12 Insp6400 kernel: [ 54.363448] Already setup the GSI :18 > Sep 8 16:59:12 Insp6400 kernel: [ 54.364263] r852 0000:03:01.3: PCI INT B -> GSI 18 (level, low) -> IRQ 18 > Sep 8 16:59:12 Insp6400 kernel: [ 54.444011] r852: Non dma capable device detected, dma disabled > Sep 8 16:59:12 Insp6400 kernel: [ 54.445864] r852: driver loaded successfully > Sep 8 16:59:12 Insp6400 kernel: [ 55.004011] microcode: CPU0 update to revision 0xd1 failed > Sep 8 16:59:12 Insp6400 kernel: [ 55.006025] microcode: CPU1 sig=0x6f6, pf=0x20, revision=0xc7 > Sep 8 16:59:12 Insp6400 kernel: [ 55.009410] iwl3945: Intel(R) PRO/Wireless 3945ABG/BG Network Connection driver for Linux, in-tree:ds > Sep 8 16:59:12 Insp6400 kernel: [ 55.010066] iwl3945: Copyright(c) 2003-2011 Intel Corporation > Sep 8 16:59:12 Insp6400 kernel: [ 55.013555] xen_map_pirq_gsi: returning irq 16 for gsi 16 > Sep 8 16:59:12 Insp6400 kernel: [ 55.015264] Already setup the GSI :16 > Sep 8 16:59:12 Insp6400 kernel: [ 55.016248] iwl3945 0000:0b:00.0: PCI INT A -> GSI 16 (level, low) -> IRQ 16 > Sep 8 16:59:12 Insp6400 kernel: [ 55.070827] microcode: CPU1 update to revision 0xd1 failed > Sep 8 16:59:12 Insp6400 kernel: [ 55.080017] microcode: Microcode Update Driver: v2.00 , Peter Oruba > Sep 8 16:59:12 Insp6400 kernel: [ 55.087930] iwl3945 0000:0b:00.0: Tunable channels: 11 802.11bg, 13 802.11a channels > Sep 8 16:59:12 Insp6400 kernel: [ 55.088151] iwl3945 0000:0b:00.0: Detected Intel Wireless WiFi Link 3945ABG > Sep 8 16:59:12 Insp6400 kernel: [ 55.092221] BUG: sleeping function called from invalid context at kernel/mutex.c:271 > Sep 8 16:59:12 Insp6400 kernel: [ 55.093017] in_atomic(): 1, irqs_disabled(): 0, pid: 516, name: modprobe > Sep 8 16:59:12 Insp6400 kernel: [ 55.093017] 3 locks held by modprobe/516: > Sep 8 16:59:12 Insp6400 kernel: [ 55.093017] #0: (&__lockdep_no_validate__){......}, at: [] __driver_attach+0x3b/0x82 > Sep 8 16:59:12 Insp6400 kernel: [ 55.093017] #1: (&__lockdep_no_validate__){......}, at: [] __driver_attach+0x49/0x82 > Sep 8 16:59:12 Insp6400 kernel: [ 55.093017] #2: (irq_mapping_update_lock){+.+.+.}, at: [] xen_bind_pirq_msi_to_irq+0x31/0xda > Sep 8 16:59:12 Insp6400 kernel: [ 55.093017] Pid: 516, comm: modprobe Not tainted 3.1.0-0.rc5.git0.0.fc17.x86_64 #1 > Sep 8 16:59:12 Insp6400 kernel: [ 55.093017] Call Trace: > Sep 8 16:59:12 Insp6400 kernel: [ 55.093017] [] __might_sleep+0x103/0x108 > Sep 8 16:59:12 Insp6400 kernel: [ 55.093017] [] mutex_lock_nested+0x25/0x45 > Sep 8 16:59:12 Insp6400 kernel: [ 55.093017] [] __irq_alloc_descs+0x50/0x18b > Sep 8 16:59:12 Insp6400 kernel: [ 55.093017] [] ? kzalloc.constprop.1+0x2/0x15 > Sep 8 16:59:12 Insp6400 kernel: [ 55.093017] [] xen_allocate_irq_dynamic+0x49/0x58 > Sep 8 16:59:12 Insp6400 kernel: [ 55.093017] [] xen_bind_pirq_msi_to_irq+0x36/0xda > Sep 8 16:59:12 Insp6400 kernel: [ 55.093017] [] xen_initdom_setup_msi_irqs+0x129/0x15d > Sep 8 16:59:12 Insp6400 kernel: [ 55.093017] [] pci_enable_msi_block+0x1c0/0x225 > Sep 8 16:59:12 Insp6400 kernel: [ 55.093017] [] iwl3945_pci_probe+0x6b7/0xc51 [iwl3945] > Sep 8 16:59:12 Insp6400 kernel: [ 55.093017] [] local_pci_probe+0x44/0x75 > Sep 8 16:59:12 Insp6400 kernel: [ 55.093017] [] pci_device_probe+0xd0/0xff > Sep 8 16:59:12 Insp6400 kernel: [ 55.093017] [] driver_probe_device+0x131/0x213 > Sep 8 16:59:12 Insp6400 kernel: [ 55.093017] [] __driver_attach+0x5e/0x82 > Sep 8 16:59:12 Insp6400 kernel: [ 55.093017] [] ? driver_probe_device+0x213/0x213 > Sep 8 16:59:12 Insp6400 kernel: [ 55.093017] [] bus_for_each_dev+0x59/0x8f > Sep 8 16:59:12 Insp6400 kernel: [ 55.093017] [] driver_attach+0x1e/0x20 > Sep 8 16:59:12 Insp6400 kernel: [ 55.093017] [] bus_add_driver+0xd4/0x22a > Sep 8 16:59:12 Insp6400 kernel: [ 55.093017] [] ? 0xffffffffa0287fff > Sep 8 16:59:12 Insp6400 kernel: [ 55.093017] [] driver_register+0x98/0x105 > Sep 8 16:59:12 Insp6400 kernel: [ 55.093017] [] ? 0xffffffffa0287fff > Sep 8 16:59:12 Insp6400 kernel: [ 55.093017] [] __pci_register_driver+0x66/0xd2 > Sep 8 16:59:12 Insp6400 kernel: [ 55.093017] [] ? 0xffffffffa0287fff > Sep 8 16:59:12 Insp6400 kernel: [ 55.093017] [] iwl3945_init+0x59/0x1000 [iwl3945] > Sep 8 16:59:12 Insp6400 kernel: [ 55.093017] [] do_one_initcall+0x7f/0x13a > Sep 8 16:59:12 Insp6400 kernel: [ 55.093017] [] ? 0xffffffffa0287fff > Sep 8 16:59:12 Insp6400 kernel: [ 55.093017] [] sys_init_module+0x114/0x267 > Sep 8 16:59:12 Insp6400 kernel: [ 55.093017] [] system_call_fastpath+0x16/0x1b > Sep 8 16:59:12 Insp6400 kernel: [ 55.093017] BUG: scheduling while atomic: modprobe/516/0x10000002 > Sep 8 16:59:12 Insp6400 kernel: [ 55.093017] 3 locks held by modprobe/516: > Sep 8 16:59:12 Insp6400 kernel: [ 55.093017] #0: (&__lockdep_no_validate__){......}, at: [] __driver_attach+0x3b/0x82 > Sep 8 16:59:12 Insp6400 kernel: [ 55.093017] #1: (&__lockdep_no_validate__){......}, at: [] __driver_attach+0x49/0x82 > Sep 8 16:59:12 Insp6400 kernel: [ 55.093017] #2: (irq_mapping_update_lock){+.+.+.}, at: [] xen_bind_pirq_msi_to_irq+0x31/0xda > Sep 8 16:59:12 Insp6400 kernel: [ 55.093017] Modules linked in: sparse_keymap iwl3945(+) iwl_legacy snd_timer mac80211 r852 sm_common nand snd r592 nand_ids memstick dell_laptop nand_ecc mtd b44 soundcore joydev i2c_i801 dcdbas snd_page_alloc microcode r8169 ssb cfg80211 iTCO_wdt iTCO_vendor_support mii rfkill tun xen_gntalloc xen_netback xen_blkback xen_gntdev xen_evtchn xenfs binfmt_misc sdhci_pci sdhci mmc_core firewire_ohci firewire_core crc_itu_t wmi i915 drm_kms_helper drm i2c_algo_bit i2c_core video > Sep 8 16:59:12 Insp6400 kernel: [ 55.093017] Pid: 516, comm: modprobe Not tainted 3.1.0-0.rc5.git0.0.fc17.x86_64 #1 > Sep 8 16:59:12 Insp6400 kernel: [ 55.093017] Call Trace: > Sep 8 16:59:12 Insp6400 kernel: [ 55.093017] [] __schedule_bug+0x75/0x7a > Sep 8 16:59:12 Insp6400 kernel: [ 55.093017] [] schedule+0x95/0x7bb > Sep 8 16:59:12 Insp6400 kernel: [ 55.093017] [] ? show_trace_log_lvl+0x54/0x5d > Sep 8 16:59:12 Insp6400 kernel: [ 55.093017] [] ? show_trace+0x15/0x17 > Sep 8 16:59:12 Insp6400 kernel: [ 55.093017] [] __cond_resched+0x28/0x34 > Sep 8 16:59:12 Insp6400 kernel: [ 55.093017] [] _cond_resched+0x19/0x22 > Sep 8 16:59:12 Insp6400 kernel: [ 55.093017] [] mutex_lock_nested+0x2a/0x45 > Sep 8 16:59:12 Insp6400 kernel: [ 55.093017] [] __irq_alloc_descs+0x50/0x18b > Sep 8 16:59:12 Insp6400 kernel: [ 55.093017] [] ? kzalloc.constprop.1+0x2/0x15 > Sep 8 16:59:12 Insp6400 kernel: [ 55.093017] [] xen_allocate_irq_dynamic+0x49/0x58 > Sep 8 16:59:12 Insp6400 kernel: [ 55.093017] [] xen_bind_pirq_msi_to_irq+0x36/0xda > Sep 8 16:59:12 Insp6400 kernel: [ 55.093017] [] xen_initdom_setup_msi_irqs+0x129/0x15d > Sep 8 16:59:12 Insp6400 kernel: [ 55.093017] [] pci_enable_msi_block+0x1c0/0x225 > Sep 8 16:59:12 Insp6400 kernel: [ 55.195564] [] iwl3945_pci_probe+0x6b7/0xc51 [iwl3945] > Sep 8 16:59:12 Insp6400 kernel: [ 55.195564] [] local_pci_probe+0x44/0x75 > Sep 8 16:59:12 Insp6400 kernel: [ 55.195564] [] pci_device_probe+0xd0/0xff > Sep 8 16:59:12 Insp6400 kernel: [ 55.195564] [] driver_probe_device+0x131/0x213 > Sep 8 16:59:12 Insp6400 kernel: [ 55.195564] [] __driver_attach+0x5e/0x82 > Sep 8 16:59:12 Insp6400 kernel: [ 55.195564] [] ? driver_probe_device+0x213/0x213 > Sep 8 16:59:12 Insp6400 kernel: [ 55.195564] [] bus_for_each_dev+0x59/0x8f > Sep 8 16:59:12 Insp6400 kernel: [ 55.195564] [] driver_attach+0x1e/0x20 > Sep 8 16:59:12 Insp6400 kernel: [ 55.195564] [] bus_add_driver+0xd4/0x22a > Sep 8 16:59:12 Insp6400 kernel: [ 55.195564] [] ? 0xffffffffa0287fff > Sep 8 16:59:12 Insp6400 kernel: [ 55.195564] [] driver_register+0x98/0x105 > Sep 8 16:59:12 Insp6400 kernel: [ 55.195564] [] ? 0xffffffffa0287fff > Sep 8 16:59:12 Insp6400 kernel: [ 55.195564] [] __pci_register_driver+0x66/0xd2 > Sep 8 16:59:12 Insp6400 kernel: [ 55.195564] [] ? 0xffffffffa0287fff > Sep 8 16:59:12 Insp6400 kernel: [ 55.195564] [] iwl3945_init+0x59/0x1000 [iwl3945] > Sep 8 16:59:12 Insp6400 kernel: [ 55.195564] [] do_one_initcall+0x7f/0x13a > Sep 8 16:59:12 Insp6400 kernel: [ 55.195564] [] ? 0xffffffffa0287fff > Sep 8 16:59:12 Insp6400 kernel: [ 55.195564] [] sys_init_module+0x114/0x267 > Sep 8 16:59:12 Insp6400 kernel: [ 55.195564] [] system_call_fastpath+0x16/0x1b > Sep 8 16:59:12 Insp6400 kernel: [ 55.548175] input: Dell WMI hotkeys as /devices/virtual/input/input6 > Sep 8 16:59:12 Insp6400 kernel: [ 56.324005] Adding 4063228k swap on /dev/mapper/vg_insp6400-lv_swap. Priority:0 extents:1 across:4063228k > Sep 8 16:59:12 Insp6400 kernel: [ 56.817354] cfg80211: World regulatory domain updated: > Sep 8 16:59:12 Insp6400 kernel: [ 56.818070] cfg80211: (start_freq - end_freq @ bandwidth), (max_antenna_gain, max_eirp) > Sep 8 16:59:12 Insp6400 kernel: [ 56.818070] cfg80211: (2402000 KHz - 2472000 KHz @ 40000 KHz), (300 mBi, 2000 mBm) > Sep 8 16:59:12 Insp6400 kernel: [ 56.818070] cfg80211: (2457000 KHz - 2482000 KHz @ 20000 KHz), (300 mBi, 2000 mBm) > Sep 8 16:59:12 Insp6400 kernel: [ 56.818070] cfg80211: (2474000 KHz - 2494000 KHz @ 20000 KHz), (300 mBi, 2000 mBm) > Sep 8 16:59:12 Insp6400 kernel: [ 56.818070] cfg80211: (5170000 KHz - 5250000 KHz @ 40000 KHz), (300 mBi, 2000 mBm) > Sep 8 16:59:12 Insp6400 kernel: [ 56.818070] cfg80211: (5735000 KHz - 5835000 KHz @ 40000 KHz), (300 mBi, 2000 mBm) > Sep 8 16:59:12 Insp6400 kernel: [ 57.216613] cfg80211: Calling CRDA for country: US > Sep 8 16:59:12 Insp6400 kernel: [ 57.268160] xen_map_pirq_gsi: returning irq 21 for gsi 21 > Sep 8 16:59:12 Insp6400 kernel: [ 57.269571] Already setup the GSI :21 > Sep 8 16:59:12 Insp6400 kernel: [ 57.270549] snd_hda_intel 0000:00:1b.0: PCI INT A -> GSI 21 (level, low) -> IRQ 21 > Sep 8 16:59:12 Insp6400 kernel: [ 57.273449] BUG: sleeping function called from invalid context at kernel/mutex.c:271 > Sep 8 16:59:12 Insp6400 kernel: [ 57.274153] in_atomic(): 1, irqs_disabled(): 0, pid: 505, name: modprobe > Sep 8 16:59:12 Insp6400 kernel: [ 57.274153] 3 locks held by modprobe/505: > Sep 8 16:59:12 Insp6400 kernel: [ 57.274153] #0: (&__lockdep_no_validate__){......}, at: [] __driver_attach+0x3b/0x82 > Sep 8 16:59:12 Insp6400 kernel: [ 57.274153] #1: (&__lockdep_no_validate__){......}, at: [] __driver_attach+0x49/0x82 > Sep 8 16:59:12 Insp6400 kernel: [ 57.274153] #2: (irq_mapping_update_lock){+.+.+.}, at: [] xen_bind_pirq_msi_to_irq+0x31/0xda > Sep 8 16:59:12 Insp6400 kernel: [ 57.274153] Pid: 505, comm: modprobe Not tainted 3.1.0-0.rc5.git0.0.fc17.x86_64 #1 > Sep 8 16:59:12 Insp6400 kernel: [ 57.274153] Call Trace: > Sep 8 16:59:12 Insp6400 kernel: [ 57.274153] [] __might_sleep+0x103/0x108 > Sep 8 16:59:12 Insp6400 kernel: [ 57.274153] [] mutex_lock_nested+0x25/0x45 > Sep 8 16:59:12 Insp6400 kernel: [ 57.274153] [] __irq_alloc_descs+0x50/0x18b > Sep 8 16:59:12 Insp6400 kernel: [ 57.274153] [] ? kzalloc.constprop.1+0x2/0x15 > Sep 8 16:59:12 Insp6400 kernel: [ 57.291640] [] xen_allocate_irq_dynamic+0x49/0x58 > Sep 8 16:59:12 Insp6400 kernel: [ 57.292557] [] xen_bind_pirq_msi_to_irq+0x36/0xda > Sep 8 16:59:12 Insp6400 kernel: [ 57.292557] [] xen_initdom_setup_msi_irqs+0x129/0x15d > Sep 8 16:59:12 Insp6400 kernel: [ 57.292557] [] pci_enable_msi_block+0x1c0/0x225 > Sep 8 16:59:12 Insp6400 kernel: [ 57.292557] [] azx_probe+0x437/0x982 [snd_hda_intel] > Sep 8 16:59:12 Insp6400 kernel: [ 57.292557] [] local_pci_probe+0x44/0x75 > Sep 8 16:59:12 Insp6400 kernel: [ 57.292557] [] pci_device_probe+0xd0/0xff > Sep 8 16:59:12 Insp6400 kernel: [ 57.292557] [] driver_probe_device+0x131/0x213 > Sep 8 16:59:12 Insp6400 kernel: [ 57.292557] [] __driver_attach+0x5e/0x82 > Sep 8 16:59:12 Insp6400 kernel: [ 57.292557] [] ? driver_probe_device+0x213/0x213 > Sep 8 16:59:12 Insp6400 kernel: [ 57.292557] [] bus_for_each_dev+0x59/0x8f > Sep 8 16:59:12 Insp6400 kernel: [ 57.292557] [] driver_attach+0x1e/0x20 > Sep 8 16:59:12 Insp6400 kernel: [ 57.292557] [] bus_add_driver+0xd4/0x22a > Sep 8 16:59:12 Insp6400 kernel: [ 57.292557] [] ? 0xffffffffa0326fff > Sep 8 16:59:12 Insp6400 kernel: [ 57.292557] [] driver_register+0x98/0x105 > Sep 8 16:59:12 Insp6400 kernel: [ 57.292557] [] ? 0xffffffffa0326fff > Sep 8 16:59:12 Insp6400 kernel: [ 57.292557] [] __pci_register_driver+0x66/0xd2 > Sep 8 16:59:12 Insp6400 kernel: [ 57.292557] [] ? 0xffffffffa0326fff > Sep 8 16:59:12 Insp6400 kernel: [ 57.292557] [] alsa_card_azx_init+0x1e/0x1000 [snd_hda_intel] > Sep 8 16:59:12 Insp6400 kernel: [ 57.292557] [] do_one_initcall+0x7f/0x13a > Sep 8 16:59:12 Insp6400 kernel: [ 57.292557] [] ? 0xffffffffa0326fff > Sep 8 16:59:12 Insp6400 kernel: [ 57.292557] [] sys_init_module+0x114/0x267 > Sep 8 16:59:12 Insp6400 kernel: [ 57.292557] [] system_call_fastpath+0x16/0x1b > Sep 8 16:59:12 Insp6400 kernel: [ 57.292557] BUG: scheduling while atomic: modprobe/505/0x10000002 > Sep 8 16:59:12 Insp6400 kernel: [ 57.292557] 3 locks held by modprobe/505: > Sep 8 16:59:12 Insp6400 kernel: [ 57.292557] #0: (&__lockdep_no_validate__){......}, at: [] __driver_attach+0x3b/0x82 > Sep 8 16:59:12 Insp6400 kernel: [ 57.292557] #1: (&__lockdep_no_validate__){......}, at: [] __driver_attach+0x49/0x82 > Sep 8 16:59:12 Insp6400 kernel: [ 57.292557] #2: (irq_mapping_update_lock){+.+.+.}, at: [] xen_bind_pirq_msi_to_irq+0x31/0xda > Sep 8 16:59:12 Insp6400 kernel: [ 57.292557] Modules linked in: snd_hda_intel(+) snd_hda_codec snd_hwdep snd_seq snd_seq_device snd_pcm dell_wmi arc4 sparse_keymap iwl3945 iwl_legacy snd_timer mac80211 r852 sm_common nand snd r592 nand_ids memstick dell_laptop nand_ecc mtd b44 soundcore joydev i2c_i801 dcdbas snd_page_alloc microcode r8169 ssb cfg80211 iTCO_wdt iTCO_vendor_support mii rfkill tun xen_gntalloc xen_netback xen_blkback xen_gntdev xen_evtchn xenfs binfmt_misc sdhci_pci sdhci mmc_core firewire_ohci firewire_core crc_itu_t wmi i915 drm_kms_helper drm i2c_algo_bit i2c_core video > Sep 8 16:59:12 Insp6400 kernel: [ 57.292557] Pid: 505, comm: modprobe Not tainted 3.1.0-0.rc5.git0.0.fc17.x86_64 #1 > Sep 8 16:59:12 Insp6400 kernel: [ 57.292557] Call Trace: > Sep 8 16:59:12 Insp6400 kernel: [ 57.292557] [] __schedule_bug+0x75/0x7a > Sep 8 16:59:12 Insp6400 kernel: [ 57.292557] [] schedule+0x95/0x7bb > Sep 8 16:59:12 Insp6400 kernel: [ 57.292557] [] ? show_trace_log_lvl+0x54/0x5d > Sep 8 16:59:12 Insp6400 kernel: [ 57.292557] [] ? show_trace+0x15/0x17 > Sep 8 16:59:12 Insp6400 kernel: [ 57.292557] [] __cond_resched+0x28/0x34 > Sep 8 16:59:12 Insp6400 kernel: [ 57.292557] [] _cond_resched+0x19/0x22 > Sep 8 16:59:12 Insp6400 kernel: [ 57.292557] [] mutex_lock_nested+0x2a/0x45 > Sep 8 16:59:12 Insp6400 kernel: [ 57.292557] [] __irq_alloc_descs+0x50/0x18b > Sep 8 16:59:12 Insp6400 kernel: [ 57.292557] [] ? kzalloc.constprop.1+0x2/0x15 > Sep 8 16:59:12 Insp6400 kernel: [ 57.292557] [] xen_allocate_irq_dynamic+0x49/0x58 > Sep 8 16:59:12 Insp6400 kernel: [ 57.292557] [] xen_bind_pirq_msi_to_irq+0x36/0xda > Sep 8 16:59:12 Insp6400 kernel: [ 57.292557] [] xen_initdom_setup_msi_irqs+0x129/0x15d > Sep 8 16:59:12 Insp6400 kernel: [ 57.292557] [] pci_enable_msi_block+0x1c0/0x225 > Sep 8 16:59:12 Insp6400 kernel: [ 57.292557] [] azx_probe+0x437/0x982 [snd_hda_intel] > Sep 8 16:59:12 Insp6400 kernel: [ 57.292557] [] local_pci_probe+0x44/0x75 > Sep 8 16:59:12 Insp6400 kernel: [ 57.292557] [] pci_device_probe+0xd0/0xff > Sep 8 16:59:12 Insp6400 kernel: [ 57.292557] [] driver_probe_device+0x131/0x213 > Sep 8 16:59:12 Insp6400 kernel: [ 57.292557] [] __driver_attach+0x5e/0x82 > Sep 8 16:59:12 Insp6400 kernel: [ 57.292557] [] ? driver_probe_device+0x213/0x213 > Sep 8 16:59:12 Insp6400 kernel: [ 57.292557] [] bus_for_each_dev+0x59/0x8f > Sep 8 16:59:12 Insp6400 kernel: [ 57.292557] [] driver_attach+0x1e/0x20 > Sep 8 16:59:12 Insp6400 kernel: [ 57.292557] [] bus_add_driver+0xd4/0x22a > Sep 8 16:59:12 Insp6400 kernel: [ 57.292557] [] ? 0xffffffffa0326fff > Sep 8 16:59:12 Insp6400 kernel: [ 57.292557] [] driver_register+0x98/0x105 > Sep 8 16:59:12 Insp6400 kernel: [ 57.292557] [] ? 0xffffffffa0326fff > Sep 8 16:59:12 Insp6400 kernel: [ 57.292557] [] __pci_register_driver+0x66/0xd2 > Sep 8 16:59:12 Insp6400 kernel: [ 57.292557] [] ? 0xffffffffa0326fff > Sep 8 16:59:12 Insp6400 kernel: [ 57.292557] [] alsa_card_azx_init+0x1e/0x1000 [snd_hda_intel] > Sep 8 16:59:12 Insp6400 kernel: [ 57.292557] [] do_one_initcall+0x7f/0x13a > Sep 8 16:59:12 Insp6400 kernel: [ 57.292557] [] ? 0xffffffffa0326fff > Sep 8 16:59:12 Insp6400 kernel: [ 57.292557] [] sys_init_module+0x114/0x267 > Sep 8 16:59:12 Insp6400 kernel: [ 57.292557] [] system_call_fastpath+0x16/0x1b > Sep 8 16:59:12 Insp6400 kernel: [ 57.394726] BUG: spinlock wrong CPU on CPU#1, modprobe/505 > Sep 8 16:59:12 Insp6400 kernel: [ 57.395079] lock: ffffffff81a7de60, .magic: dead4ead, .owner: modprobe/505, .owner_cpu: 0 > Sep 8 16:59:12 Insp6400 kernel: [ 57.395079] Pid: 505, comm: modprobe Not tainted 3.1.0-0.rc5.git0.0.fc17.x86_64 #1 > Sep 8 16:59:12 Insp6400 kernel: [ 57.395079] Call Trace: > Sep 8 16:59:12 Insp6400 kernel: [ 57.395079] [] spin_bug+0xa3/0xab > Sep 8 16:59:12 Insp6400 kernel: [ 57.395079] [] do_raw_spin_unlock+0x75/0x8b > Sep 8 16:59:12 Insp6400 kernel: [ 57.395079] [] _raw_spin_unlock+0x28/0x3b > Sep 8 16:59:12 Insp6400 kernel: [ 57.395079] [] xen_bind_pirq_msi_to_irq+0xae/0xda > Sep 8 16:59:12 Insp6400 kernel: [ 57.395079] [] xen_initdom_setup_msi_irqs+0x129/0x15d > Sep 8 16:59:12 Insp6400 kernel: [ 57.409377] [] pci_enable_msi_block+0x1c0/0x225 > Sep 8 16:59:12 Insp6400 kernel: [ 57.409377] [] azx_probe+0x437/0x982 [snd_hda_intel] > Sep 8 16:59:12 Insp6400 kernel: [ 57.409377] [] local_pci_probe+0x44/0x75 > Sep 8 16:59:12 Insp6400 kernel: [ 57.409377] [] pci_device_probe+0xd0/0xff > Sep 8 16:59:12 Insp6400 kernel: [ 57.409377] [] driver_probe_device+0x131/0x213 > Sep 8 16:59:12 Insp6400 kernel: [ 57.409377] [] __driver_attach+0x5e/0x82 > Sep 8 16:59:12 Insp6400 kernel: [ 57.409377] [] ? driver_probe_device+0x213/0x213 > Sep 8 16:59:12 Insp6400 kernel: [ 57.409377] [] bus_for_each_dev+0x59/0x8f > Sep 8 16:59:12 Insp6400 kernel: [ 57.419915] cfg80211: Regulatory domain changed to country: US > Sep 8 16:59:12 Insp6400 kernel: [ 57.419919] cfg80211: (start_freq - end_freq @ bandwidth), (max_antenna_gain, max_eirp) > Sep 8 16:59:12 Insp6400 kernel: [ 57.419924] cfg80211: (2402000 KHz - 2472000 KHz @ 40000 KHz), (300 mBi, 2700 mBm) > Sep 8 16:59:12 Insp6400 kernel: [ 57.419927] cfg80211: (5170000 KHz - 5250000 KHz @ 40000 KHz), (300 mBi, 1700 mBm) > Sep 8 16:59:12 Insp6400 kernel: [ 57.419931] cfg80211: (5250000 KHz - 5330000 KHz @ 40000 KHz), (300 mBi, 2000 mBm) > Sep 8 16:59:12 Insp6400 kernel: [ 57.419935] cfg80211: (5490000 KHz - 5600000 KHz @ 40000 KHz), (300 mBi, 2000 mBm) > Sep 8 16:59:12 Insp6400 kernel: [ 57.419939] cfg80211: (5650000 KHz - 5710000 KHz @ 40000 KHz), (300 mBi, 2000 mBm) > Sep 8 16:59:12 Insp6400 kernel: [ 57.419942] cfg80211: (5735000 KHz - 5835000 KHz @ 40000 KHz), (300 mBi, 3000 mBm) > Sep 8 16:59:12 Insp6400 kernel: [ 57.409377] [] driver_attach+0x1e/0x20 > Sep 8 16:59:12 Insp6400 kernel: [ 57.409377] [] bus_add_driver+0xd4/0x22a > Sep 8 16:59:12 Insp6400 kernel: [ 57.409377] [] ? 0xffffffffa0326fff > Sep 8 16:59:12 Insp6400 kernel: [ 57.409377] [] driver_register+0x98/0x105 > Sep 8 16:59:12 Insp6400 kernel: [ 57.409377] [] ? 0xffffffffa0326fff > Sep 8 16:59:12 Insp6400 kernel: [ 57.409377] [] __pci_register_driver+0x66/0xd2 > Sep 8 16:59:12 Insp6400 kernel: [ 57.409377] [] ? 0xffffffffa0326fff > Sep 8 16:59:12 Insp6400 kernel: [ 57.409377] [] alsa_card_azx_init+0x1e/0x1000 [snd_hda_intel] > Sep 8 16:59:12 Insp6400 kernel: [ 57.409377] [] do_one_initcall+0x7f/0x13a > Sep 8 16:59:12 Insp6400 kernel: [ 57.409377] [] ? 0xffffffffa0326fff > Sep 8 16:59:12 Insp6400 kernel: [ 57.409377] [] sys_init_module+0x114/0x267 > Sep 8 16:59:12 Insp6400 kernel: [ 57.409377] [] system_call_fastpath+0x16/0x1b > Sep 8 16:59:12 Insp6400 kernel: [ 57.621754] input: HDA Intel Mic at Ext Right Jack as /devices/pci0000:00/0000:00:1b.0/sound/card0/input7 > Sep 8 16:59:12 Insp6400 kernel: [ 57.636306] input: HDA Intel HP Out at Ext Right Jack as /devices/pci0000:00/0000:00:1b.0/sound/card0/input8 > Sep 8 16:59:12 Insp6400 kernel: [ 58.445701] EXT4-fs (sda2): mounting ext3 file system using the ext4 subsystem > Sep 8 16:59:12 Insp6400 kernel: [ 58.497772] EXT4-fs (sda2): mounted filesystem with ordered data mode. Opts: (null) > Sep 8 16:59:12 Insp6400 kernel: [ 64.030601] ip6_tables: (C) 2000-2006 Netfilter Core Team > Sep 8 16:59:12 Insp6400 kernel: [ 65.208998] Loading iSCSI transport class v2.0-870. > Sep 8 16:59:12 Insp6400 kernel: [ 65.232872] nf_conntrack version 0.5.0 (16384 buckets, 65536 max) > Sep 8 16:59:12 Insp6400 kernel: [ 65.862081] iscsi: registered transport (tcp) > Sep 8 16:59:13 Insp6400 kernel: [ 67.636361] iscsi: registered transport (iser) > Sep 8 16:59:15 Insp6400 dbus: avc: netlink poll: error 4 > Sep 8 16:59:16 Insp6400 abrtd: Init complete, entering main loop > Sep 8 16:59:16 Insp6400 avahi-daemon[755]: Successfully called chroot(). > Sep 8 16:59:16 Insp6400 avahi-daemon[755]: Successfully dropped remaining capabilities. > Sep 8 16:59:16 Insp6400 avahi-daemon[755]: Loading service file /services/ssh.service. > Sep 8 16:59:16 Insp6400 kernel: [ 70.153389] libcxgbi:libcxgbi_init_module: tag itt 0x1fff, 13 bits, age 0xf, 4 bits. > Sep 8 16:59:16 Insp6400 kernel: [ 70.154133] libcxgbi:ddp_setup_host_page_size: system PAGE 4096, ddp idx 0. > Sep 8 16:59:16 Insp6400 avahi-daemon[755]: Loading service file /services/udisks.service. > Sep 8 16:59:16 Insp6400 avahi-daemon[755]: Network interface enumeration completed. > Sep 8 16:59:16 Insp6400 avahi-daemon[755]: Registering HINFO record with values 'X86_64'/'LINUX'. > Sep 8 16:59:16 Insp6400 avahi-daemon[755]: Server startup complete. Host name is insp6400.local. Local service cookie is 1645585705. > Sep 8 16:59:16 Insp6400 avahi-daemon[755]: Service "insp6400" (/services/udisks.service) successfully established. > Sep 8 16:59:16 Insp6400 avahi-daemon[755]: Service "insp6400" (/services/ssh.service) successfully established. > Sep 8 16:59:16 Insp6400 kernel: [ 70.277955] Chelsio T3 iSCSI Driver cxgb3i v2.0.0 (Jun. 2010) > Sep 8 16:59:16 Insp6400 kernel: [ 70.280171] iscsi: registered transport (cxgb3i) > Sep 8 16:59:16 Insp6400 kernel: [ 70.533004] cnic: Broadcom NetXtreme II CNIC Driver cnic v2.5.7 (July 20, 2011) > Sep 8 16:59:16 Insp6400 kernel: [ 70.597280] Broadcom NetXtreme II iSCSI Driver bnx2i v2.7.0.3 (Jun 15, 2011) > Sep 8 16:59:16 Insp6400 kernel: [ 70.616921] iscsi: registered transport (bnx2i) > Sep 8 16:59:16 Insp6400 kernel: [ 70.807620] iscsi: registered transport (be2iscsi) > Sep 8 16:59:17 Insp6400 iscsid: iSCSI logger with pid=908 started! > Sep 8 16:59:17 Insp6400 kernel: [ 71.418730] iscsid (909): /proc/909/oom_adj is deprecated, please use /proc/909/oom_score_adj instead. > Sep 8 16:59:18 Insp6400 iscsid: transport class version 2.0-870. iscsid version 2.0-872 > Sep 8 16:59:18 Insp6400 iscsid: iSCSI daemon with pid=909 started! > Sep 8 16:59:21 Insp6400 kernel: [ 75.137582] bonding: Ethernet Channel Bonding Driver: v3.7.1 (April 27, 2011) > Sep 8 16:59:21 Insp6400 kernel: [ 75.181503] bonding: bond0 is being created... > Sep 8 16:59:21 Insp6400 kernel: [ 75.184019] bonding: bond0 already exists. > Sep 8 16:59:21 Insp6400 kernel: [ 75.470879] bonding: bond0: setting mode to balance-tlb (5). > Sep 8 16:59:21 Insp6400 kernel: [ 75.473430] bonding: bond0: Setting MII monitoring interval to 5. > Sep 8 16:59:21 Insp6400 kernel: [ 75.475896] bonding: bond0: Setting down delay to 2000. > Sep 8 16:59:21 Insp6400 kernel: [ 75.494222] ADDRCONF(NETDEV_UP): bond0: link is not ready > Sep 8 16:59:21 Insp6400 kernel: [ 75.832493] bonding: bond0: Adding slave eth0. > Sep 8 16:59:21 Insp6400 kernel: [ 75.848342] bonding: bond0: enslaving eth0 as an active interface with a down link. > Sep 8 16:59:22 Insp6400 kernel: [ 76.117901] bonding: bond0: Adding slave eth1. > Sep 8 16:59:22 Insp6400 kernel: [ 76.250834] r8169 0000:0c:00.0: eth1: link down > Sep 8 16:59:22 Insp6400 kernel: [ 76.251060] r8169 0000:0c:00.0: eth1: link down > Sep 8 16:59:22 Insp6400 kernel: [ 76.257039] bonding: bond0: enslaving eth1 as an active interface with a down link. > Sep 8 16:59:22 Insp6400 kernel: [ 76.460299] Bridge firewalling registered > Sep 8 16:59:22 Insp6400 kernel: [ 76.535875] device bond0 entered promiscuous mode > Sep 8 16:59:23 Insp6400 kernel: [ 77.187656] ADDRCONF(NETDEV_UP): xenbr0: link is not ready > Sep 8 16:59:24 Insp6400 kernel: [ 78.680876] r8169 0000:0c:00.0: eth1: link up > Sep 8 16:59:24 Insp6400 kernel: [ 78.685920] bonding: bond0: link status definitely up for interface eth1, 1000 Mbps full duplex. > Sep 8 16:59:24 Insp6400 kernel: [ 78.686063] bonding: bond0: making interface eth1 the new active one. > Sep 8 16:59:24 Insp6400 kernel: [ 78.686063] device eth1 entered promiscuous mode > Sep 8 16:59:24 Insp6400 kernel: [ 78.692304] bonding: bond0: first active interface up! > Sep 8 16:59:24 Insp6400 kernel: [ 78.694863] ADDRCONF(NETDEV_CHANGE): bond0: link becomes ready > Sep 8 16:59:24 Insp6400 kernel: [ 78.697756] xenbr0: port 1(bond0) entering forwarding state > Sep 8 16:59:24 Insp6400 kernel: [ 78.698140] xenbr0: port 1(bond0) entering forwarding state > Sep 8 16:59:24 Insp6400 kernel: [ 78.702807] ADDRCONF(NETDEV_CHANGE): xenbr0: link becomes ready > Sep 8 16:59:24 Insp6400 kernel: [ 78.704820] b44 ssb0:0: eth0: Link is up at 100 Mbps, full duplex > Sep 8 16:59:24 Insp6400 kernel: [ 78.705626] b44 ssb0:0: eth0: Flow control is off for TX and off for RX > Sep 8 16:59:24 Insp6400 kernel: [ 78.709983] bonding: bond0: link status definitely up for interface eth0, 100 Mbps full duplex. > Sep 8 16:59:25 Insp6400 avahi-daemon[755]: Registering new address record for fe80::215:c5ff:fe04:7d4f on bond0.*. > Sep 8 16:59:26 Insp6400 dhclient[1579]: DHCPREQUEST on xenbr0 to 255.255.255.255 port 67 > Sep 8 16:59:26 Insp6400 dhclient[1579]: DHCPACK from 192.168.1.1 > Sep 8 16:59:26 Insp6400 avahi-daemon[755]: Joining mDNS multicast group on interface xenbr0.IPv4 with address 192.168.1.100. > Sep 8 16:59:26 Insp6400 avahi-daemon[755]: New relevant interface xenbr0.IPv4 for mDNS. > Sep 8 16:59:26 Insp6400 avahi-daemon[755]: Registering new address record for 192.168.1.100 on xenbr0.IPv4. > Sep 8 16:59:26 Insp6400 avahi-daemon[755]: Registering new address record for fe80::215:c5ff:fe04:7d4f on xenbr0.*. > Sep 8 16:59:26 Insp6400 NET[1788]: /sbin/dhclient-script : updated /etc/resolv.conf > Sep 8 16:59:27 Insp6400 dhclient[1579]: bound to 192.168.1.100 -- renewal in 65745 seconds. > Sep 8 16:59:28 Insp6400 kernel: [ 82.661777] FS-Cache: Loaded > Sep 8 16:59:28 Insp6400 kernel: [ 82.758652] FS-Cache: Netfs 'cifs' registered for caching > Sep 8 16:59:28 Insp6400 kernel: [ 82.867310] CIFS VFS: default security mechanism requested. The default security mechanism will be upgraded from ntlm to ntlmv2 in kernel release 3.1 > Sep 8 16:59:34 Insp6400 ntpdate[1977]: step time server 67.18.208.240 offset 0.453408 sec > Sep 8 16:59:34 Insp6400 ntpd[2153]: ntpd 4.2.6p3@1.2290-o Fri May 6 16:26:49 UTC 2011 (1) > Sep 8 16:59:34 Insp6400 ntpd[2153]: proto: precision = 1.720 usec > Sep 8 16:59:34 Insp6400 ntpd[2153]: 0.0.0.0 c01d 0d kern kernel time sync enabled > Sep 8 16:59:34 Insp6400 ntpd[2153]: Listen and drop on 0 v4wildcard 0.0.0.0 UDP 123 > Sep 8 16:59:34 Insp6400 ntpd[2153]: Listen and drop on 1 v6wildcard :: UDP 123 > Sep 8 16:59:34 Insp6400 ntpd[2153]: Listen normally on 2 lo 127.0.0.1 UDP 123 > Sep 8 16:59:34 Insp6400 ntpd[2153]: Listen normally on 3 xenbr0 192.168.1.100 UDP 123 > Sep 8 16:59:34 Insp6400 ntpd[2153]: Listen normally on 4 xenbr0 fe80::215:c5ff:fe04:7d4f UDP 123 > Sep 8 16:59:34 Insp6400 ntpd[2153]: Listen normally on 5 bond0 fe80::215:c5ff:fe04:7d4f UDP 123 > Sep 8 16:59:34 Insp6400 ntpd[2153]: Listen normally on 6 lo ::1 UDP 123 > Sep 8 16:59:34 Insp6400 ntpd[2153]: peers refreshed > Sep 8 16:59:34 Insp6400 ntpd[2153]: Listening on routing socket on fd #23 for interface updates > Sep 8 16:59:36 Insp6400 ntpd[2153]: 0.0.0.0 c016 06 restart > Sep 8 16:59:36 Insp6400 ntpd[2153]: 0.0.0.0 c012 02 freq_set kernel 1.500 PPM > Sep 8 16:59:50 Insp6400 auditd[2741]: Started dispatcher: /sbin/audispd pid: 2743 > Sep 8 16:59:50 Insp6400 auditd[2741]: Init complete, auditd 2.1.3 listening for events (startup state enable) > Sep 8 16:59:50 Insp6400 audispd: audispd initialized with q_depth=120 and 1 active plugins > Sep 8 16:59:51 Insp6400 kernel: [ 104.683571] scsi2 : iSCSI Initiator over TCP/IP > Sep 8 16:59:51 Insp6400 kernel: [ 105.119216] scsi 2:0:0:0: RAID IET Controller 0001 PQ: 0 ANSI: 5 > Sep 8 16:59:51 Insp6400 kernel: [ 105.163374] scsi 2:0:0:0: Attached scsi generic sg2 type 12 > Sep 8 16:59:51 Insp6400 kernel: [ 105.182535] scsi 2:0:0:1: Direct-Access IET VIRTUAL-DISK 0001 PQ: 0 ANSI: 5 > Sep 8 16:59:51 Insp6400 kernel: [ 105.195288] sd 2:0:0:1: [sdb] 312581808 512-byte logical blocks: (160 GB/149 GiB) > Sep 8 16:59:51 Insp6400 kernel: [ 105.201707] sd 2:0:0:1: [sdb] Write Protect is off > Sep 8 16:59:51 Insp6400 kernel: [ 105.213193] sd 2:0:0:1: Attached scsi generic sg3 type 0 > Sep 8 16:59:51 Insp6400 kernel: [ 105.219746] sd 2:0:0:1: [sdb] Write cache: enabled, read cache: enabled, doesn't support DPO or FUA > Sep 8 16:59:51 Insp6400 iscsid: Connection1:0 to [target: iqn.2001-04.com.Dell4550-iqn.2009-09.net.bellsouth.sda:041b7d3f-b008-4367-b1f2-b4799d15e4cd, portal: 192.168.1.101,3260] through [iface: default] is operational now > Sep 8 16:59:51 Insp6400 kernel: [ 105.266929] sdb: sdb1 sdb2 sdb3 > Sep 8 16:59:51 Insp6400 kernel: [ 105.280033] sd 2:0:0:1: [sdb] Attached SCSI disk > Sep 8 16:59:52 Insp6400 kernel: [ 106.571909] iwl3945 0000:0b:00.0: loaded firmware version 15.32.2.9 > Sep 8 16:59:53 Insp6400 kernel: [ 106.794916] ADDRCONF(NETDEV_UP): wlan0: link is not ready > Sep 8 16:59:53 Insp6400 rpc.statd[2928]: Version 1.2.4 starting > Sep 8 16:59:54 Insp6400 sm-notify[2933]: Version 1.2.4 starting > Sep 8 16:59:55 Insp6400 kernel: [ 108.705060] RPC: Registered named UNIX socket transport module. > Sep 8 16:59:55 Insp6400 kernel: [ 108.705060] RPC: Registered udp transport module. > Sep 8 16:59:55 Insp6400 kernel: [ 108.705060] RPC: Registered tcp transport module. > Sep 8 16:59:55 Insp6400 kernel: [ 108.705060] RPC: Registered tcp NFSv4.1 backchannel transport module. > Sep 8 16:59:55 Insp6400 kernel: [ 108.933995] Installing knfsd (copyright (C) 1996 okir@monad.swb.de). > Sep 8 16:59:56 Insp6400 kernel: [ 109.739661] ADDRCONF(NETDEV_CHANGE): wlan0: link becomes ready > Sep 8 16:59:56 Insp6400 kernel: [ 109.896771] NFSD: Using /var/lib/nfs/v4recovery as the NFSv4 state recovery directory > Sep 8 16:59:56 Insp6400 kernel: [ 109.916136] NFSD: starting 90-second grace period > Sep 8 16:59:56 Insp6400 rpc.mountd[3018]: Version 1.2.4 starting > Sep 8 16:59:57 Insp6400 avahi-daemon[755]: Registering new address record for fe80::213:2ff:fe1a:f185 on wlan0.*. > Sep 8 16:59:57 Insp6400 systemd[1]: avguard.service: control process exited, code=exited status=2 > Sep 8 16:59:57 Insp6400 systemd[1]: Unit avguard.service entered failed state. > Sep 8 16:59:58 Insp6400 ntpd[2153]: Listen normally on 7 wlan0 fe80::213:2ff:fe1a:f185 UDP 123 > Sep 8 16:59:58 Insp6400 ntpd[2153]: peers refreshed > Sep 8 17:00:02 Insp6400 kernel: [ 116.591656] xen-pciback: backend is vpci > Sep 8 17:00:03 Insp6400 xenstored: Checking store ... > Sep 8 17:00:03 Insp6400 xenstored: Checking store complete. > Sep 8 17:00:03 Insp6400 kernel: [ 116.911469] BUG: sleeping function called from invalid context at kernel/mutex.c:271 > Sep 8 17:00:03 Insp6400 kernel: [ 116.912065] in_atomic(): 1, irqs_disabled(): 0, pid: 3208, name: xenstored > Sep 8 17:00:03 Insp6400 kernel: [ 116.912065] INFO: lockdep is turned off. > Sep 8 17:00:03 Insp6400 kernel: [ 116.912065] Pid: 3208, comm: xenstored Not tainted 3.1.0-0.rc5.git0.0.fc17.x86_64 #1 > Sep 8 17:00:03 Insp6400 kernel: [ 116.912065] Call Trace: > Sep 8 17:00:03 Insp6400 kernel: [ 116.912065] [] __might_sleep+0x103/0x108 > Sep 8 17:00:03 Insp6400 kernel: [ 116.912065] [] mutex_lock_nested+0x25/0x45 > Sep 8 17:00:03 Insp6400 kernel: [ 116.912065] [] __irq_alloc_descs+0x50/0x18b > Sep 8 17:00:03 Insp6400 kernel: [ 116.912065] [] ? pnp_register_protocol+0x39/0xb4 > Sep 8 17:00:03 Insp6400 kernel: [ 116.912065] [] xen_allocate_irq_dynamic+0x49/0x58 > Sep 8 17:00:03 Insp6400 kernel: [ 116.912065] [] bind_evtchn_to_irq+0x32/0x82 > Sep 8 17:00:03 Insp6400 kernel: [ 116.912065] [] bind_evtchn_to_irqhandler+0x25/0x63 > Sep 8 17:00:03 Insp6400 kernel: [ 116.912065] [] ? set_port_enabled+0x31/0x31 [xen_evtchn] > Sep 8 17:00:03 Insp6400 kernel: [ 116.912065] [] evtchn_bind_to_user+0x56/0x64 [xen_evtchn] > Sep 8 17:00:03 Insp6400 kernel: [ 116.912065] [] evtchn_ioctl+0x129/0x2ef [xen_evtchn] > Sep 8 17:00:03 Insp6400 kernel: [ 116.912065] [] do_vfs_ioctl+0x472/0x4b3 > Sep 8 17:00:03 Insp6400 kernel: [ 116.912065] [] sys_ioctl+0x56/0x7a > Sep 8 17:00:03 Insp6400 kernel: [ 116.912065] [] system_call_fastpath+0x16/0x1b > Sep 8 17:00:03 Insp6400 kernel: [ 116.946247] XENBUS: Unable to read cpu state > Sep 8 17:00:03 Insp6400 kernel: [ 116.949075] XENBUS: Unable to read cpu state > Sep 8 17:00:03 Insp6400 kernel: [ 116.966668] cfg80211: Calling CRDA to update world regulatory domain > Sep 8 17:00:03 Insp6400 avahi-daemon[755]: Withdrawing address record for fe80::213:2ff:fe1a:f185 on wlan0. > Sep 8 17:00:03 Insp6400 avahi-daemon[755]: Withdrawing workstation service for wlan0. > Sep 8 17:00:03 Insp6400 kernel: [ 117.137705] iwl3945 0000:0b:00.0: PCI INT A disabled > Sep 8 17:00:03 Insp6400 kernel: [ 117.142092] pciback 0000:0b:00.0: seizing device > Sep 8 17:00:03 Insp6400 kernel: [ 117.146295] xen_map_pirq_gsi: returning irq 16 for gsi 16 > Sep 8 17:00:03 Insp6400 kernel: [ 117.149952] Already setup the GSI :16 > Sep 8 17:00:03 Insp6400 kernel: [ 117.150936] pciback 0000:0b:00.0: PCI INT A -> GSI 16 (level, low) -> IRQ 16 > Sep 8 17:00:03 Insp6400 kernel: [ 117.150936] pciback 0000:0b:00.0: PCI INT A disabled > Sep 8 17:00:03 Insp6400 smbd[3172]: [2011/09/08 17:00:03.572080, 0] smbd/server.c:501(smbd_open_one_socket) > Sep 8 17:00:03 Insp6400 smbd[3172]: smbd_open_once_socket: open_socket_in: Address already in use > Sep 8 17:00:03 Insp6400 smbd[3172]: [2011/09/08 17:00:03.581039, 0] smbd/server.c:501(smbd_open_one_socket) > Sep 8 17:00:03 Insp6400 smbd[3172]: smbd_open_once_socket: open_socket_in: Address already in use > Sep 8 17:00:03 Insp6400 kernel: [ 117.385355] cfg80211: World regulatory domain updated: > Sep 8 17:00:03 Insp6400 kernel: [ 117.386066] cfg80211: (start_freq - end_freq @ bandwidth), (max_antenna_gain, max_eirp) > Sep 8 17:00:03 Insp6400 kernel: [ 117.386066] cfg80211: (2402000 KHz - 2472000 KHz @ 40000 KHz), (300 mBi, 2000 mBm) > Sep 8 17:00:03 Insp6400 kernel: [ 117.386066] cfg80211: (2457000 KHz - 2482000 KHz @ 20000 KHz), (300 mBi, 2000 mBm) > Sep 8 17:00:03 Insp6400 kernel: [ 117.386066] cfg80211: (2474000 KHz - 2494000 KHz @ 20000 KHz), (300 mBi, 2000 mBm) > Sep 8 17:00:03 Insp6400 kernel: [ 117.386066] cfg80211: (5170000 KHz - 5250000 KHz @ 40000 KHz), (300 mBi, 2000 mBm) > Sep 8 17:00:03 Insp6400 kernel: [ 117.386066] cfg80211: (5735000 KHz - 5835000 KHz @ 40000 KHz), (300 mBi, 2000 mBm) > Sep 8 17:00:03 Insp6400 kernel: [ 117.398125] cfg80211: Calling CRDA for country: US > Sep 8 17:00:03 Insp6400 kernel: [ 117.529792] cfg80211: Regulatory domain changed to country: US > Sep 8 17:00:03 Insp6400 kernel: [ 117.530194] cfg80211: (start_freq - end_freq @ bandwidth), (max_antenna_gain, max_eirp) > Sep 8 17:00:03 Insp6400 kernel: [ 117.530194] cfg80211: (2402000 KHz - 2472000 KHz @ 40000 KHz), (300 mBi, 2700 mBm) > Sep 8 17:00:03 Insp6400 kernel: [ 117.530194] cfg80211: (5170000 KHz - 5250000 KHz @ 40000 KHz), (300 mBi, 1700 mBm) > Sep 8 17:00:03 Insp6400 kernel: [ 117.530194] cfg80211: (5250000 KHz - 5330000 KHz @ 40000 KHz), (300 mBi, 2000 mBm) > Sep 8 17:00:03 Insp6400 kernel: [ 117.530194] cfg80211: (5490000 KHz - 5600000 KHz @ 40000 KHz), (300 mBi, 2000 mBm) > Sep 8 17:00:03 Insp6400 kernel: [ 117.530194] cfg80211: (5650000 KHz - 5710000 KHz @ 40000 KHz), (300 mBi, 2000 mBm) > Sep 8 17:00:03 Insp6400 kernel: [ 117.530194] cfg80211: (5735000 KHz - 5835000 KHz @ 40000 KHz), (300 mBi, 3000 mBm) > Sep 8 17:00:04 Insp6400 ntpd[2153]: Deleting interface #7 wlan0, fe80::213:2ff:fe1a:f185#123, interface stats: received=0, sent=0, dropped=0, active_time=6 secs > Sep 8 17:00:04 Insp6400 ntpd[2153]: peers refreshed > Sep 8 17:00:07 Insp6400 systemd[1]: vncserver.service: control process exited, code=exited status=2 > Sep 8 17:00:08 Insp6400 systemd[1]: Unit vncserver.service entered failed state. > Sep 8 17:00:15 Insp6400 dbus: [system] Activating via systemd: service name='org.freedesktop.ConsoleKit' unit='console-kit-daemon.service' > Sep 8 17:00:16 Insp6400 dbus: [system] Activating service name='org.freedesktop.PolicyKit1' (using servicehelper) > Sep 8 17:00:16 Insp6400 polkitd[3467]: started daemon version 0.101 using authority implementation `local' version `0.101' > Sep 8 17:00:16 Insp6400 dbus: [system] Successfully activated service 'org.freedesktop.PolicyKit1' > Sep 8 17:00:16 Insp6400 dbus: [system] Successfully activated service 'org.freedesktop.ConsoleKit' > Sep 8 17:00:25 Insp6400 nmbd[3169]: [2011/09/08 17:00:25.301440, 0] nmbd/nmbd_become_lmb.c:395(become_local_master_stage2) > Sep 8 17:00:25 Insp6400 nmbd[3169]: ***** > Sep 8 17:00:25 Insp6400 nmbd[3169]: > Sep 8 17:00:25 Insp6400 nmbd[3169]: Samba name server INSP6400 is now a local master browser for workgroup LINKSYS on subnet 192.168.1.100 > Sep 8 17:00:25 Insp6400 nmbd[3169]: > Sep 8 17:00:25 Insp6400 nmbd[3169]: ***** > Sep 8 17:00:25 Insp6400 systemd[1]: Startup finished in 4s 787ms 508us (kernel) + 35s 406ms 337us (initrd) + 1min 39s 39ms 614us (userspace) = 2min 19s 233ms 459us. > Sep 8 17:00:27 Insp6400 avahi-daemon[755]: Joining mDNS multicast group on interface virbr0.IPv4 with address 192.168.122.1. > Sep 8 17:00:27 Insp6400 avahi-daemon[755]: New relevant interface virbr0.IPv4 for mDNS. > Sep 8 17:00:27 Insp6400 avahi-daemon[755]: Registering new address record for 192.168.122.1 on virbr0.IPv4. > Sep 8 17:00:27 Insp6400 kernel: [ 140.751611] ADDRCONF(NETDEV_UP): virbr0: link is not ready > Sep 8 17:00:27 Insp6400 dnsmasq[3670]: started, version 2.52 cachesize 150 > Sep 8 17:00:27 Insp6400 dnsmasq[3670]: compile time options: IPv6 GNU-getopt DBus no-I18N DHCP TFTP > Sep 8 17:00:27 Insp6400 dnsmasq-dhcp[3670]: DHCP, IP range 192.168.122.2 -- 192.168.122.254, lease time 1h > Sep 8 17:00:27 Insp6400 dnsmasq[3670]: reading /etc/resolv.conf > Sep 8 17:00:27 Insp6400 dnsmasq[3670]: using nameserver 205.152.132.23#53 > Sep 8 17:00:27 Insp6400 dnsmasq[3670]: using nameserver 205.152.144.23#53 > Sep 8 17:00:27 Insp6400 dnsmasq[3670]: using nameserver 205.152.37.23#53 > Sep 8 17:00:27 Insp6400 dnsmasq[3670]: read /etc/hosts - 4855 addresses > Sep 8 17:00:28 Insp6400 ntpd[2153]: Listen normally on 8 virbr0 192.168.122.1 UDP 123 > Sep 8 17:00:28 Insp6400 ntpd[2153]: peers refreshed > Sep 8 17:00:29 Insp6400 kernel: [ 143.253210] Ebtables v2.0 registered > Sep 8 17:00:29 Insp6400 dbus: [system] Activating via systemd: service name='org.freedesktop.RealtimeKit1' unit='rtkit-daemon.service' > Sep 8 17:00:30 Insp6400 dbus: [system] Successfully activated service 'org.freedesktop.RealtimeKit1' > Sep 8 21:00:31 Insp6400 rtkit-daemon[3702]: Successfully made thread 3699 of process 3699 (/usr/bin/pulseaudio) owned by '42' high priority at nice level -11. > Sep 8 21:00:33 Insp6400 rtkit-daemon[3702]: Failed to make thread 3713 RT: Operation not permitted > Sep 8 21:00:33 Insp6400 rtkit-daemon[3702]: Failed to make thread 3713 RT: Operation not permitted > Sep 8 21:00:33 Insp6400 rtkit-daemon[3702]: Failed to make thread 3716 RT: Operation not permitted > Sep 8 21:00:33 Insp6400 rtkit-daemon[3702]: Failed to make thread 3716 RT: Operation not permitted > Sep 8 17:00:33 Insp6400 kernel: [ 146.796609] hda-intel: Invalid position buffer, using LPIB read method instead. > Sep 8 17:00:35 Insp6400 dbus: [system] Activating service name='org.freedesktop.UDisks' (using servicehelper) > Sep 8 17:00:36 Insp6400 dbus: [system] Successfully activated service 'org.freedesktop.UDisks' > Sep 8 17:00:36 Insp6400 dbus: [system] Activating service name='org.freedesktop.UPower' (using servicehelper) > Sep 8 17:00:36 Insp6400 dbus: [system] Successfully activated service 'org.freedesktop.UPower' > Sep 8 17:00:39 Insp6400 gdm-simple-greeter[3726]: Gtk-WARNING: gtkwidget.c:6796: widget not within a GtkWindow > Sep 8 17:00:39 Insp6400 gdm-simple-greeter[3726]: Gtk-WARNING: gtk_widget_size_allocate(): attempt to allocate widget with width -47 and height -47 > Sep 8 17:00:40 Insp6400 dbus: [system] Activating via systemd: service name='org.freedesktop.Accounts' unit='accounts-daemon.service' > Sep 8 17:00:40 Insp6400 dbus: [system] Successfully activated service 'org.freedesktop.Accounts' > Sep 8 17:00:40 Insp6400 accounts-daemon[3808]: started daemon version 0.6.10 > Sep 8 17:02:38 Insp6400 nmbd[3169]: [2011/09/08 17:02:38.529251, 0] nmbd/nmbd_become_lmb.c:395(become_local_master_stage2) > Sep 8 17:02:38 Insp6400 nmbd[3169]: ***** > Sep 8 17:02:38 Insp6400 nmbd[3169]: > Sep 8 17:02:38 Insp6400 nmbd[3169]: Samba name server INSP6400 is now a local master browser for workgroup LINKSYS on subnet 192.168.122.1 > Sep 8 17:02:38 Insp6400 nmbd[3169]: > Sep 8 17:02:38 Insp6400 nmbd[3169]: ***** > Sep 8 17:02:53 Insp6400 ntpd[2153]: 0.0.0.0 c615 05 clock_sync > Sep 8 17:12:20 Insp6400 dbus: [system] Activating service name='net.reactivated.Fprint' (using servicehelper) > Sep 8 17:12:21 Insp6400 dbus: [system] Successfully activated service 'net.reactivated.Fprint' > Sep 8 17:12:33 Insp6400 kernel: [ 867.118180] BUG: sleeping function called from invalid context at kernel/mutex.c:271 > Sep 8 17:12:33 Insp6400 kernel: [ 867.118188] in_atomic(): 1, irqs_disabled(): 0, pid: 3208, name: xenstored > Sep 8 17:12:33 Insp6400 kernel: [ 867.118193] INFO: lockdep is turned off. > Sep 8 17:12:33 Insp6400 kernel: [ 867.118199] Pid: 3208, comm: xenstored Not tainted 3.1.0-0.rc5.git0.0.fc17.x86_64 #1 > Sep 8 17:12:33 Insp6400 kernel: [ 867.118203] Call Trace: > Sep 8 17:12:33 Insp6400 kernel: [ 867.118215] [] __might_sleep+0x103/0x108 > Sep 8 17:12:33 Insp6400 kernel: [ 867.118224] [] mutex_lock_nested+0x25/0x45 > Sep 8 17:12:33 Insp6400 kernel: [ 867.118232] [] __irq_alloc_descs+0x50/0x18b > Sep 8 17:12:33 Insp6400 kernel: [ 867.118240] [] ? pnp_register_protocol+0x39/0xb4 > Sep 8 17:12:33 Insp6400 kernel: [ 867.118248] [] xen_allocate_irq_dynamic+0x49/0x58 > Sep 8 17:12:33 Insp6400 kernel: [ 867.118254] [] bind_evtchn_to_irq+0x32/0x82 > Sep 8 17:12:33 Insp6400 kernel: [ 867.118260] [] bind_evtchn_to_irqhandler+0x25/0x63 > Sep 8 17:12:33 Insp6400 kernel: [ 867.118292] [] ? set_port_enabled+0x31/0x31 [xen_evtchn] > Sep 8 17:12:33 Insp6400 kernel: [ 867.118302] [] evtchn_bind_to_user+0x56/0x64 [xen_evtchn] > Sep 8 17:12:33 Insp6400 kernel: [ 867.118313] [] evtchn_ioctl+0x129/0x2ef [xen_evtchn] > Sep 8 17:12:33 Insp6400 kernel: [ 867.118321] [] do_vfs_ioctl+0x472/0x4b3 > Sep 8 17:12:33 Insp6400 kernel: [ 867.118327] [] sys_ioctl+0x56/0x7a > Sep 8 17:12:33 Insp6400 kernel: [ 867.118335] [] system_call_fastpath+0x16/0x1b > Sep 8 17:12:34 Insp6400 kernel: [ 868.191636] device tap1.0 entered promiscuous mode > Sep 8 17:12:34 Insp6400 kernel: [ 868.192285] xenbr0: port 2(tap1.0) entering forwarding state > Sep 8 17:12:34 Insp6400 kernel: [ 868.192341] xenbr0: port 2(tap1.0) entering forwarding state > Sep 8 17:12:34 Insp6400 kernel: [ 868.353440] BUG: sleeping function called from invalid context at kernel/mutex.c:271 > Sep 8 17:12:34 Insp6400 kernel: [ 868.353448] in_atomic(): 1, irqs_disabled(): 0, pid: 4171, name: qemu-dm > Sep 8 17:12:34 Insp6400 kernel: [ 868.353452] INFO: lockdep is turned off. > Sep 8 17:12:34 Insp6400 kernel: [ 868.353458] Pid: 4171, comm: qemu-dm Not tainted 3.1.0-0.rc5.git0.0.fc17.x86_64 #1 > Sep 8 17:12:34 Insp6400 kernel: [ 868.353462] Call Trace: > Sep 8 17:12:34 Insp6400 kernel: [ 868.353474] [] __might_sleep+0x103/0x108 > Sep 8 17:12:34 Insp6400 kernel: [ 868.353483] [] mutex_lock_nested+0x25/0x45 > Sep 8 17:12:34 Insp6400 kernel: [ 868.353491] [] __irq_alloc_descs+0x50/0x18b > Sep 8 17:12:34 Insp6400 kernel: [ 868.353499] [] ? pnp_register_protocol+0x39/0xb4 > Sep 8 17:12:34 Insp6400 kernel: [ 868.353507] [] xen_allocate_irq_dynamic+0x49/0x58 > Sep 8 17:12:34 Insp6400 kernel: [ 868.353513] [] bind_evtchn_to_irq+0x32/0x82 > Sep 8 17:12:34 Insp6400 kernel: [ 868.353519] [] bind_evtchn_to_irqhandler+0x25/0x63 > Sep 8 17:12:34 Insp6400 kernel: [ 868.353532] [] ? set_port_enabled+0x31/0x31 [xen_evtchn] > Sep 8 17:12:34 Insp6400 kernel: [ 868.353543] [] evtchn_bind_to_user+0x56/0x64 [xen_evtchn] > Sep 8 17:12:34 Insp6400 kernel: [ 868.353553] [] evtchn_ioctl+0x129/0x2ef [xen_evtchn] > Sep 8 17:12:34 Insp6400 kernel: [ 868.353561] [] do_vfs_ioctl+0x472/0x4b3 > Sep 8 17:12:34 Insp6400 kernel: [ 868.353568] [] sys_ioctl+0x56/0x7a > Sep 8 17:12:34 Insp6400 kernel: [ 868.353576] [] system_call_fastpath+0x16/0x1b > Sep 8 17:12:35 Insp6400 kernel: [ 869.241732] xenbr0: port 2(tap1.0) entering forwarding state > Sep 8 17:12:35 Insp6400 kernel: [ 869.336479] xenbr0: port 2(tap1.0) entering forwarding state > Sep 8 17:12:35 Insp6400 kernel: [ 869.336566] xenbr0: port 2(tap1.0) entering forwarding state > Sep 8 17:12:36 Insp6400 /etc/sysconfig/network-scripts/ifup-aliases: Missing config file tap1.0. > Sep 8 17:12:36 Insp6400 kernel: [ 870.457363] device vif1.0 entered promiscuous mode > Sep 8 17:12:36 Insp6400 kernel: [ 870.471816] ADDRCONF(NETDEV_UP): vif1.0: link is not ready > Sep 8 17:12:36 Insp6400 avahi-daemon[755]: Registering new address record for fe80::fcff:ffff:feff:ffff on tap1.0.*. > Sep 8 17:12:38 Insp6400 ntpd[2153]: Listen normally on 9 tap1.0 fe80::fcff:ffff:feff:ffff UDP 123 > Sep 8 17:12:38 Insp6400 ntpd[2153]: peers refreshed > Sep 8 17:15:36 Insp6400 kernel: [ 1049.819851] BUG: sleeping function called from invalid context at kernel/mutex.c:271 > Sep 8 17:15:36 Insp6400 kernel: [ 1049.819859] in_atomic(): 1, irqs_disabled(): 0, pid: 3208, name: xenstored > Sep 8 17:15:36 Insp6400 kernel: [ 1049.819864] INFO: lockdep is turned off. > Sep 8 17:15:36 Insp6400 kernel: [ 1049.819869] Pid: 3208, comm: xenstored Not tainted 3.1.0-0.rc5.git0.0.fc17.x86_64 #1 > Sep 8 17:15:36 Insp6400 kernel: [ 1049.819873] Call Trace: > Sep 8 17:15:36 Insp6400 kernel: [ 1049.819886] [] __might_sleep+0x103/0x108 > Sep 8 17:15:36 Insp6400 kernel: [ 1049.819894] [] mutex_lock_nested+0x25/0x45 > Sep 8 17:15:36 Insp6400 kernel: [ 1049.819902] [] free_desc+0x30/0x64 > Sep 8 17:15:36 Insp6400 kernel: [ 1049.819908] [] irq_free_descs+0x39/0x72 > Sep 8 17:15:36 Insp6400 kernel: [ 1049.819917] [] xen_free_irq+0x49/0x4e > Sep 8 17:15:36 Insp6400 kernel: [ 1049.819923] [] unbind_from_irq+0xde/0xf5 > Sep 8 17:15:36 Insp6400 kernel: [ 1049.819929] [] unbind_from_irqhandler+0x19/0x1d > Sep 8 17:15:36 Insp6400 kernel: [ 1049.819940] [] evtchn_unbind_from_user+0x1e/0x32 [xen_evtchn] > Sep 8 17:15:36 Insp6400 kernel: [ 1049.819950] [] evtchn_ioctl+0x229/0x2ef [xen_evtchn] > Sep 8 17:15:36 Insp6400 kernel: [ 1049.819959] [] do_vfs_ioctl+0x472/0x4b3 > Sep 8 17:15:36 Insp6400 kernel: [ 1049.819965] [] sys_ioctl+0x56/0x7a > Sep 8 17:15:36 Insp6400 kernel: [ 1049.819973] [] system_call_fastpath+0x16/0x1b > Sep 8 17:15:36 Insp6400 kernel: [ 1049.878662] xenbr0: port 2(tap1.0) entering forwarding state > Sep 8 17:15:36 Insp6400 avahi-daemon[755]: Withdrawing address record for fe80::fcff:ffff:feff:ffff on tap1.0. > Sep 8 17:15:36 Insp6400 kernel: [ 1049.882314] xenbr0: port 2(tap1.0) entering disabled state > Sep 8 17:15:36 Insp6400 kernel: [ 1049.883411] xenbr0: port 2(tap1.0) entering disabled state > Sep 8 17:15:36 Insp6400 avahi-daemon[755]: Withdrawing workstation service for tap1.0. > Sep 8 17:15:36 Insp6400 kernel: [ 1050.510285] xenbr0: port 3(vif1.0) entering disabled state > Sep 8 17:15:36 Insp6400 kernel: [ 1050.511039] xenbr0: port 3(vif1.0) entering disabled state > Sep 8 17:15:36 Insp6400 avahi-daemon[755]: Withdrawing workstation service for vif1.0. > Sep 8 17:15:37 Insp6400 ntpd[2153]: Deleting interface #9 tap1.0, fe80::fcff:ffff:feff:ffff#123, interface stats: received=0, sent=0, dropped=0, active_time=179 secs > Sep 8 17:15:37 Insp6400 ntpd[2153]: peers refreshed > Sep 8 17:17:37 Insp6400 kernel: [ 1171.421852] BUG: sleeping function called from invalid context at kernel/mutex.c:271 > Sep 8 17:17:37 Insp6400 kernel: [ 1171.421860] in_atomic(): 1, irqs_disabled(): 0, pid: 3230, name: xenconsoled > Sep 8 17:17:37 Insp6400 kernel: [ 1171.421864] INFO: lockdep is turned off. > Sep 8 17:17:37 Insp6400 kernel: [ 1171.421870] Pid: 3230, comm: xenconsoled Not tainted 3.1.0-0.rc5.git0.0.fc17.x86_64 #1 > Sep 8 17:17:37 Insp6400 kernel: [ 1171.421874] Call Trace: > Sep 8 17:17:37 Insp6400 kernel: [ 1171.421886] [] __might_sleep+0x103/0x108 > Sep 8 17:17:37 Insp6400 kernel: [ 1171.421895] [] mutex_lock_nested+0x25/0x45 > Sep 8 17:17:37 Insp6400 kernel: [ 1171.421903] [] free_desc+0x30/0x64 > Sep 8 17:17:37 Insp6400 kernel: [ 1171.421909] [] irq_free_descs+0x39/0x72 > Sep 8 17:17:37 Insp6400 kernel: [ 1171.421918] [] xen_free_irq+0x49/0x4e > Sep 8 17:17:37 Insp6400 kernel: [ 1171.421924] [] unbind_from_irq+0xde/0xf5 > Sep 8 17:17:37 Insp6400 kernel: [ 1171.421930] [] unbind_from_irqhandler+0x19/0x1d > Sep 8 17:17:37 Insp6400 kernel: [ 1171.421942] [] evtchn_unbind_from_user+0x1e/0x32 [xen_evtchn] > Sep 8 17:17:37 Insp6400 kernel: [ 1171.421952] [] evtchn_release+0x84/0xab [xen_evtchn] > Sep 8 17:17:37 Insp6400 kernel: [ 1171.421960] [] fput+0x127/0x1f5 > Sep 8 17:17:37 Insp6400 kernel: [ 1171.421966] [] filp_close+0x70/0x7b > Sep 8 17:17:37 Insp6400 kernel: [ 1171.421974] [] put_files_struct+0xca/0x18d > Sep 8 17:17:37 Insp6400 kernel: [ 1171.421980] [] exit_files+0x48/0x50 > Sep 8 17:17:37 Insp6400 kernel: [ 1171.421987] [] do_exit+0x2d0/0x82c > Sep 8 17:17:37 Insp6400 kernel: [ 1171.421995] [] ? xen_restore_fl_direct_reloc+0x4/0x4 > Sep 8 17:17:37 Insp6400 kernel: [ 1171.422003] [] ? arch_local_irq_restore+0xb/0xd > Sep 8 17:17:37 Insp6400 kernel: [ 1171.422010] [] do_group_exit+0x88/0xb6 > Sep 8 17:17:37 Insp6400 kernel: [ 1171.422017] [] get_signal_to_deliver+0x528/0x57d > Sep 8 17:17:37 Insp6400 kernel: [ 1171.422025] [] do_signal+0x3e/0x629 > Sep 8 17:17:37 Insp6400 kernel: [ 1171.422033] [] ? security_file_permission+0x2e/0x33 > Sep 8 17:17:37 Insp6400 kernel: [ 1171.422040] [] ? rw_verify_area+0xb6/0xd3 > Sep 8 17:17:37 Insp6400 kernel: [ 1171.422046] [] do_notify_resume+0x28/0x83 > Sep 8 17:17:37 Insp6400 kernel: [ 1171.422055] [] int_signal+0x12/0x17 > Sep 8 17:17:38 Insp6400 systemd[1]: xenstored.service: control process exited, code=exited status=1 > Sep 8 17:17:38 Insp6400 systemd[1]: Unit xenstored.service entered failed state. > Sep 8 17:17:47 Insp6400 kernel: Kernel logging (proc) stopped. > Sep 8 17:17:47 Insp6400 rsyslogd: [origin software="rsyslogd" swVersion="5.8.2" x-pid="789" x-info="http://www.rsyslog.com"] exiting on signal 15. _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel From xen-devel-bounces@lists.xensource.com Mon Sep 12 01:04:13 2011 Return-path: Envelope-to: www-data@lists.xensource.com Delivery-date: Mon, 12 Sep 2011 01:04:13 -0700 Received: from localhost ([127.0.0.1] helo=lists.colo.xensource.com) by lists.xensource.com with esmtp (Exim 4.43) id 1R31Uz-0006GO-Bq; Mon, 12 Sep 2011 01:04:13 -0700 Received: from mail27.messagelabs.com ([193.109.254.147]) by lists.xensource.com with esmtp (Exim 4.43) id 1R31SP-000615-19 for xen-devel@lists.xensource.com; Mon, 12 Sep 2011 01:01:57 -0700 X-Env-Sender: JBeulich@suse.com X-Msg-Ref: server-6.tower-27.messagelabs.com!1315814471!48553765!1 X-Originating-IP: [130.57.49.28] X-StarScan-Version: 6.3.6; banners=-,-,- X-VirusChecked: Checked Received: (qmail 28706 invoked from network); 12 Sep 2011 08:01:11 -0000 Received: from nat28.tlf.novell.com (HELO nat28.tlf.novell.com) (130.57.49.28) by server-6.tower-27.messagelabs.com with DHE-RSA-AES256-SHA encrypted SMTP; 12 Sep 2011 08:01:11 -0000 Received: from EMEA1-MTA by nat28.tlf.novell.com with Novell_GroupWise; Mon, 12 Sep 2011 09:01:28 +0100 Message-Id: <4E6DD8750200007800055ADA@nat28.tlf.novell.com> X-Mailer: Novell GroupWise Internet Agent 8.0.1 Date: Mon, 12 Sep 2011 09:01:25 +0100 From: "Jan Beulich" To: "Konrad Rzeszutek Wilk" References: <1315593060-20031-1-git-send-email-konrad.wilk@oracle.com> <1315593060-20031-3-git-send-email-konrad.wilk@oracle.com> In-Reply-To: <1315593060-20031-3-git-send-email-konrad.wilk@oracle.com> Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: quoted-printable Content-Disposition: inline Cc: axboe@kernel.dk, xen-devel@lists.xensource.com, jeremy.fitzhardinge@citrix.com, stable@kernel.org, linux-kernel@vger.kernel.org Subject: [Xen-devel] Re: [PATCH 3/3] xen-blkfront: If no barrier or flush is supported, use invalid operation. X-BeenThere: xen-devel@lists.xensource.com X-Mailman-Version: 2.1.5 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xensource.com Errors-To: xen-devel-bounces@lists.xensource.com >>> On 09.09.11 at 20:31, Konrad Rzeszutek Wilk = wrote: > By default we would set the info->flush_op=3D0, and zero maps > to BLKIF_OP_READ request code. So if the backend did not support > either barrier ('feature-barrier') or flush ('feature-flush-cache') > we would end up using that opcode for the flush/barrier request, meaning > we actually do a READ request. Fortunatly for us, __generic_make_request > checks q->flush_flags and realizes that we don't do FLUSH and removes > the REQ_FLUSH | REQ_FUA so we never end up issuing a READ request > for a flush request. However, other third party implementations of > __make_request might not be so smart, so lets fix this up. Wouldn't it be better to simply have blkif_queue_request() fail in that case (and then it doesn't matter whether flush_op is set to 0 or -1)? Not the least because older (forward-port) backends stall the incoming queue and are possibly verbose for invalid requests seen. Jan > CC: stable@kernel.org=20 > Signed-off-by: Konrad Rzeszutek Wilk > --- > drivers/block/xen-blkfront.c | 8 ++++---- > 1 files changed, 4 insertions(+), 4 deletions(-) >=20 > diff --git a/drivers/block/xen-blkfront.c b/drivers/block/xen-blkfront.c > index e205d91..c4aa9da 100644 > --- a/drivers/block/xen-blkfront.c > +++ b/drivers/block/xen-blkfront.c > @@ -97,7 +97,7 @@ struct blkfront_info > struct blk_shadow shadow[BLK_RING_SIZE]; > unsigned long shadow_free; > unsigned int feature_flush; > - unsigned int flush_op; > + int flush_op; > unsigned int feature_discard; > unsigned int discard_granularity; > unsigned int discard_alignment; > @@ -774,7 +774,7 @@ static irqreturn_t blkif_interrupt(int irq, void = *dev_id) > if (error =3D=3D -EOPNOTSUPP) > error =3D 0; > info->feature_flush =3D 0; > - info->flush_op =3D 0; > + info->flush_op =3D -1; /* 0 is BLKIF_OP_REA= D */ > xlvbd_flush(info); > } > /* fall through */ > @@ -1207,7 +1207,7 @@ static void blkfront_connect(struct blkfront_info= =20 > *info) > } > =20 > info->feature_flush =3D 0; > - info->flush_op =3D 0; > + info->flush_op =3D -1; /* 0 is BLKIF_OP_READ */ > =20 > err =3D xenbus_gather(XBT_NIL, info->xbdev->otherend, > "feature-barrier", "%d", &barrier, > @@ -1234,7 +1234,7 @@ static void blkfront_connect(struct blkfront_info= =20 > *info) > if (!err && flush) > info->flush_op =3D BLKIF_OP_FLUSH_DISKCACHE; > =20 > - if (info->flush_op) > + if (info->flush_op > 0) > info->feature_flush =3D REQ_FLUSH | REQ_FUA; > =20 > err =3D xenbus_gather(XBT_NIL, info->xbdev->otherend, _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel From xen-devel-bounces@lists.xensource.com Mon Sep 12 02:17:36 2011 Return-path: Envelope-to: www-data@lists.xensource.com Delivery-date: Mon, 12 Sep 2011 02:17:36 -0700 Received: from localhost ([127.0.0.1] helo=lists.colo.xensource.com) by lists.xensource.com with esmtp (Exim 4.43) id 1R32e0-0007oh-0j; Mon, 12 Sep 2011 02:17:36 -0700 Received: from mail182.messagelabs.com ([85.158.139.83]) by lists.xensource.com with esmtp (Exim 4.43) id 1R32d5-0007bm-07 for xen-devel@lists.xensource.com; Mon, 12 Sep 2011 02:16:40 -0700 X-Env-Sender: 19890121wr@gmail.com X-Msg-Ref: server-15.tower-182.messagelabs.com!1315818994!16957351!1 X-Originating-IP: [209.85.161.181] X-StarScan-Version: 6.3.6; banners=-,-,- X-VirusChecked: Checked Received: (qmail 18833 invoked from network); 12 Sep 2011 09:16:35 -0000 Received: from mail-gx0-f181.google.com (HELO mail-gx0-f181.google.com) (209.85.161.181) by server-15.tower-182.messagelabs.com with RC4-SHA encrypted SMTP; 12 Sep 2011 09:16:35 -0000 Received: by gxk9 with SMTP id 9so4502771gxk.12 for ; Mon, 12 Sep 2011 02:16:34 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :content-type; bh=p+3Yf5gWIkoQPX2mWTaQa08Qbwkwa/zSq2THy43Nnb4=; b=NQiuBbUt0rJ9fPJrusVKiDS5cTKU/iCmJRD4pQnhJeSxLYRuzjk3bb3pxB1vLzyDR3 qpjjzzFAB/kWN/V59hQU0sDB+efgg7m7FKIAP6y8QpkSt6vICf+BCmE4p1vBYYrnxeXZ KYWvyrp50yP/QrP8NCaiP2i81R1S2dIECxj6w= MIME-Version: 1.0 Received: by 10.68.199.227 with SMTP id jn3mr4097205pbc.409.1315818993961; Mon, 12 Sep 2011 02:16:33 -0700 (PDT) Received: by 10.142.177.7 with HTTP; Mon, 12 Sep 2011 02:16:33 -0700 (PDT) In-Reply-To: References: Date: Mon, 12 Sep 2011 17:16:33 +0800 Message-ID: From: =?GB2312?B?zuLI8Q==?= <19890121wr@gmail.com> To: xen-devel@lists.xensource.com Subject: [Xen-devel] Fwd: about page table X-BeenThere: xen-devel@lists.xensource.com X-Mailman-Version: 2.1.5 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1015080626==" Sender: xen-devel-bounces@lists.xensource.com Errors-To: xen-devel-bounces@lists.xensource.com --===============1015080626== Content-Type: multipart/alternative; boundary=e89a8f642d44b9498804acbafbd1 --e89a8f642d44b9498804acbafbd1 Content-Type: text/plain; charset=ISO-8859-1 Hi,everyone I have been using dbg_pv_va2mfn() function to scan PV dom's page table.However,when i intended to modify the page table's entry.Something went wrong. Should I modify the P2M and M2P table,either?But I kind of lose track of how things work at P2M and M2P table.Can someone tell me something about these tables. Or can someone can tell me which function can come in handy,or where to look in. I am in the middle of a project that needs to manipulate the page table in dom. For example, static unsigned long dbg_pv_va2mfn(dbgva_t vaddr, struct domain *dp, uint64_t pgd3val) { l3_pgentry_t l3e, *l3t; l2_pgentry_t l2e, *l2t; l1_pgentry_t l1e, *l1t; unsigned long cr3 = (pgd3val ? pgd3val : dp->vcpu[0]->arch.cr3); unsigned long mfn = cr3 >> PAGE_SHIFT; DBGP2("vaddr:%lx domid:%d cr3:%lx pgd3:%lx\n", vaddr, dp->domain_id, cr3, pgd3val); if ( pgd3val == 0 ) { l3t = map_domain_page(mfn); l3t += (cr3 & 0xFE0UL) >> 3; l3e = l3t[l3_table_offset(vaddr)]; mfn = l3e_get_pfn(l3e); unmap_domain_page(l3t); if ( !(l3e_get_flags(l3e) & _PAGE_PRESENT) ) return INVALID_MFN; } l2t = map_domain_page(mfn); l2e = l2t[l2_table_offset(vaddr)]; mfn = l2e_get_pfn(l2e); unmap_domain_page(l2t); if ( !(l2e_get_flags(l2e) & _PAGE_PRESENT) || (l2e_get_flags(l2e) & _PAGE_PSE) ) return INVALID_MFN; l1t = map_domain_page(mfn); l1e = l1t[l1_table_offset(vaddr)];----------------------------------(1) mfn = l1e_get_pfn(l1e);----------------------------------------------(2) unmap_domain_page(l1t); return mfn_valid(mfn) ? mfn : INVALID_MFN; } What should i do if i want to change the l1e page table entry.I allocate a page using the function alloc_domheap_page,and use l1e_from_page() to write the l1e entry,but it proved to be wrong,and my system keeps reboot itself. Can anyone gives me a hand? Thanks --e89a8f642d44b9498804acbafbd1 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
Hi,everyone
I have been using dbg_pv_va2mfn()= function to scan PV dom's page table.However,when i intended to modify= the page table's entry.Something went wrong.
Should I modify the P= 2M and M2P table,either?But I kind of lose track of how things work at P2M = and M2P table.Can someone tell me something about these tables.
Or can someone can tell me which function can come in handy,or where t= o look in.
I am in the middle of =A0a project that needs to manip= ulate the page table in dom.
For example,
static u= nsigned long=A0
dbg_pv_va2mfn(dbgva_t vaddr, struct domain *dp, uint64_t pgd3val)
{
=A0 =A0 l3_pgentry_t l3e, *l3t;
=A0 =A0 l2_pgen= try_t l2e, *l2t;
=A0 =A0 l1_pgentry_t l1e, *l1t;
=A0 = =A0 unsigned long cr3 =3D (pgd3val ? pgd3val : dp->vcpu[0]->arch.cr3)= ;
=A0 =A0 unsigned long mfn =3D cr3 >> PAGE_SHIFT;

<= /div>
=A0 =A0 DBGP2("vaddr:%lx domid:%d cr3:%lx pgd3:%lx\n", = vaddr, dp->domain_id,=A0
=A0 =A0 =A0 =A0 =A0 cr3, pgd3val);

=A0 =A0 if ( pgd3val =3D=3D 0 )
=A0 =A0 {
=A0 =A0 = =A0 =A0 l3t =A0=3D map_domain_page(mfn);
=A0 =A0 =A0 =A0 l3t +=3D= (cr3 & 0xFE0UL) >> 3;
=A0 =A0 =A0 =A0 l3e =3D l3t[l3_t= able_offset(vaddr)];
=A0 =A0 =A0 =A0 mfn =3D l3e_get_pfn(l3e);
=A0 =A0 =A0 =A0 unmap_domain_page(l3t);
=A0 =A0 =A0 =A0 if (= !(l3e_get_flags(l3e) & _PAGE_PRESENT) )
=A0 =A0 =A0 =A0 =A0 = =A0 return INVALID_MFN;
=A0 =A0 }

=A0 = =A0 l2t =3D map_domain_page(mfn);
=A0 =A0 l2e =3D l2t[l2_table_offset(vaddr)];
=A0 =A0 mfn =3D= l2e_get_pfn(l2e);
=A0 =A0 unmap_domain_page(l2t);
=A0 = =A0 if ( !(l2e_get_flags(l2e) & _PAGE_PRESENT) ||=A0
=A0 =A0 = =A0 =A0 =A0(l2e_get_flags(l2e) & _PAGE_PSE) )
=A0 =A0 =A0 =A0 return INVALID_MFN;

=A0 =A0 l= 1t =3D map_domain_page(mfn);
=A0 =A0 l1e =3D l1t[l1_table_offset(= vaddr)];----------------------------------(1)
=A0 =A0 mfn =3D l1e= _get_pfn(l1e);----------------------------------------------(2) =A0 =A0=A0<= /div>
=A0 =A0 unmap_domain_page(l1t);

=A0 =A0 retur= n mfn_valid(mfn) ? mfn : INVALID_MFN;
}
What shou= ld i do if i want to change the l1e page table entry.I allocate a page usin= g the function alloc_domheap_page,and use l1e_from_page() to write the l1e = entry,but it proved to be wrong,and my system keeps reboot itself.
Can anyone gives me a hand?=A0
=A0 =A0 =A0 =A0 =A0 =A0 =A0 = =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0= =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 = =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0= =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 = =A0 =A0 =A0 =A0 =A0 =A0 =A0Thanks

--e89a8f642d44b9498804acbafbd1-- --===============1015080626== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel --===============1015080626==-- From xen-devel-bounces@lists.xensource.com Mon Sep 12 02:44:10 2011 Return-path: Envelope-to: www-data@lists.xensource.com Delivery-date: Mon, 12 Sep 2011 02:44:10 -0700 Received: from localhost ([127.0.0.1] helo=lists.colo.xensource.com) by lists.xensource.com with esmtp (Exim 4.43) id 1R333i-0000FX-7N; Mon, 12 Sep 2011 02:44:10 -0700 Received: from mail27.messagelabs.com ([193.109.254.147]) by lists.xensource.com with esmtp (Exim 4.43) id 1R332q-0008Qf-Lx for xen-devel@lists.xensource.com; Mon, 12 Sep 2011 02:43:17 -0700 X-Env-Sender: Andrew.Cooper3@citrix.com X-Msg-Ref: server-6.tower-27.messagelabs.com!1315820574!48573044!1 X-Originating-IP: [66.165.176.89] X-StarScan-Version: 6.3.6; banners=-,-,- X-VirusChecked: Checked Received: (qmail 23664 invoked from network); 12 Sep 2011 09:42:55 -0000 Received: from smtp.citrix.com (HELO SMTP.CITRIX.COM) (66.165.176.89) by server-6.tower-27.messagelabs.com with RC4-SHA encrypted SMTP; 12 Sep 2011 09:42:55 -0000 X-IronPort-AV: E=Sophos;i="4.68,367,1312171200"; d="scan'208";a="16865466" Received: from ftlpmailmx02.citrite.net ([10.13.107.66]) by FTLPIPO01.CITRIX.COM with ESMTP/TLS/RC4-MD5; 12 Sep 2011 05:43:11 -0400 Received: from [10.80.2.18] (10.80.2.18) by FTLPMAILMX02.citrite.net (10.13.107.66) with Microsoft SMTP Server id 8.3.137.0; Mon, 12 Sep 2011 05:43:11 -0400 Message-ID: <4E6DD42E.6010305@citrix.com> Date: Mon, 12 Sep 2011 10:43:10 +0100 From: Andrew Cooper User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.2.21) Gecko/20110831 Lightning/1.0b2 Thunderbird/3.1.13 MIME-Version: 1.0 To: Subject: Re: [Xen-devel] Intel-VTd problem References: <1315606916.3323.6.camel@kali.ninth-art.net> In-Reply-To: <1315606916.3323.6.camel@kali.ninth-art.net> Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: 7bit Cc: xen-devel@lists.xensource.com X-BeenThere: xen-devel@lists.xensource.com X-Mailman-Version: 2.1.5 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xensource.com Errors-To: xen-devel-bounces@lists.xensource.com On 09/09/11 23:21, Georg Bege wrote: > Hello to you guys, > > yeah Im also one of the people who seem to have a corrupted BIOS. > I read already stuff about the issue's with certain vendors - > and I guess in one particular area it was made clear that even you > cant do a lot about it you still collect details. > > CPU Intel Core i7 X980 > Mainboard Asus P6T WS Professional (X58/LGA1333)(bios 1207) > rev. 1.01G > > I also have two other questions (last time I was testing Xen it was back > in '06). > > A) > (XEN) Enabled directed EOI with ioapic_ack_old on! > (XEN) ENABLING IO-APIC IRQs > (XEN) -> Using old ACK method > What does this mean? There are two methods for ACKing an interrupt from the IO-APIC. The old ACK method is faster, but unfortunately breaks certain old chipsets which didn't follow the spec and tried to be clever working out whether your OS was new enough to understand what an IO-APIC really was. As a result, there are two ACK methods in Xen, so people who run into this problem can switch their ACK method to the slower one which works on their hardware. > B) > When the hypervisor tries to load my DOM0 it takes a long time until it > continues the boot process (it hangs somewhere after freeing unused > memory (loaded the initrd)) - what could that be? > > I append my dmesg logs (both XEN and DOM0). > My host OS is a Gentoo GNU/Linux running 2.6.38-xen kernel. > > therion@kali ~ > qlist -Iv xen > app-emulation/xen-4.1.1 > app-emulation/xen-tools-4.1.1-r1 > sys-kernel/xen-sources-2.6.38 > > > cheers Sorry I cant help with anything else, -- Andrew Cooper - Dom0 Kernel Engineer, Citrix XenServer T: +44 (0)1223 225 900, http://www.citrix.com _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel From xen-devel-bounces@lists.xensource.com Mon Sep 12 03:11:59 2011 Return-path: Envelope-to: www-data@lists.xensource.com Delivery-date: Mon, 12 Sep 2011 03:11:59 -0700 Received: from localhost ([127.0.0.1] helo=lists.colo.xensource.com) by lists.xensource.com with esmtp (Exim 4.43) id 1R33Ud-0001gy-IP; Mon, 12 Sep 2011 03:11:59 -0700 Received: from mail174.messagelabs.com ([85.158.138.51]) by lists.xensource.com with esmtp (Exim 4.43) id 1R33Tc-0001UQ-8w for xen-devel@lists.xensource.com; Mon, 12 Sep 2011 03:10:57 -0700 X-Env-Sender: tim@xen.org X-Msg-Ref: server-6.tower-174.messagelabs.com!1315822248!28952928!1 X-Originating-IP: [81.29.64.94] X-StarScan-Version: 6.3.6; banners=-,-,- X-VirusChecked: Checked Received: (qmail 5103 invoked from network); 12 Sep 2011 10:10:52 -0000 Received: from ocelot.phlegethon.org (HELO mail.phlegethon.org) (81.29.64.94) by server-6.tower-174.messagelabs.com with DHE-RSA-AES256-SHA encrypted SMTP; 12 Sep 2011 10:10:52 -0000 Received: from tjd by mail.phlegethon.org with local (Exim 4.67 (FreeBSD)) (envelope-from ) id 1R33TT-000LDM-Ed; Mon, 12 Sep 2011 10:10:47 +0000 Date: Mon, 12 Sep 2011 11:10:47 +0100 From: Tim Deegan To: ???? <19890121wr@gmail.com> Subject: Re: [Xen-devel] Fwd: about page table Message-ID: <20110912101047.GB79171@ocelot.phlegethon.org> References: Mime-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.4.2.1i Cc: xen-devel@lists.xensource.com X-BeenThere: xen-devel@lists.xensource.com X-Mailman-Version: 2.1.5 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xensource.com Errors-To: xen-devel-bounces@lists.xensource.com Hello, Please read http://wiki.xen.org/xenwiki/AskingXenDevelQuestions before posting again; it's pretty unclear from your email what you're trying to do and how it fails. At 17:16 +0800 on 12 Sep (1315847793), ???? wrote: > Hi,everyone > I have been using dbg_pv_va2mfn() function to scan PV dom's page > table.However,when i intended to modify the page table's entry.Something > went wrong. > Should I modify the P2M and M2P table,either?But I kind of lose track of how > things work at P2M and M2P table.Can someone tell me something about these > tables. > Or can someone can tell me which function can come in handy,or where to look > in. > I am in the middle of a project that needs to manipulate the page table in > dom. OK, I guess from the code below that you want to change the contents of a PV guest's pagetables from inside Xen? That's not really allowed -- since PV guests make their own pagetables you need to have the guest OS's cooperation. If you tell us what the project is, and _why_ you want to do this, we might be able to suggest a better approach. Cheers, Tim. > For example, > static unsigned long > dbg_pv_va2mfn(dbgva_t vaddr, struct domain *dp, uint64_t pgd3val) > { > l3_pgentry_t l3e, *l3t; > l2_pgentry_t l2e, *l2t; > l1_pgentry_t l1e, *l1t; > unsigned long cr3 = (pgd3val ? pgd3val : dp->vcpu[0]->arch.cr3); > unsigned long mfn = cr3 >> PAGE_SHIFT; > > DBGP2("vaddr:%lx domid:%d cr3:%lx pgd3:%lx\n", vaddr, dp->domain_id, > cr3, pgd3val); > > if ( pgd3val == 0 ) > { > l3t = map_domain_page(mfn); > l3t += (cr3 & 0xFE0UL) >> 3; > l3e = l3t[l3_table_offset(vaddr)]; > mfn = l3e_get_pfn(l3e); > unmap_domain_page(l3t); > if ( !(l3e_get_flags(l3e) & _PAGE_PRESENT) ) > return INVALID_MFN; > } > > l2t = map_domain_page(mfn); > l2e = l2t[l2_table_offset(vaddr)]; > mfn = l2e_get_pfn(l2e); > unmap_domain_page(l2t); > if ( !(l2e_get_flags(l2e) & _PAGE_PRESENT) || > (l2e_get_flags(l2e) & _PAGE_PSE) ) > return INVALID_MFN; > > l1t = map_domain_page(mfn); > l1e = l1t[l1_table_offset(vaddr)];----------------------------------(1) > mfn = l1e_get_pfn(l1e);----------------------------------------------(2) > > unmap_domain_page(l1t); > > return mfn_valid(mfn) ? mfn : INVALID_MFN; > } > What should i do if i want to change the l1e page table entry.I allocate a > page using the function alloc_domheap_page,and use l1e_from_page() to write > the l1e entry,but it proved to be wrong,and my system keeps reboot itself. > Can anyone gives me a hand? > > > Thanks > _______________________________________________ > Xen-devel mailing list > Xen-devel@lists.xensource.com > http://lists.xensource.com/xen-devel _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel From xen-devel-bounces@lists.xensource.com Mon Sep 12 03:15:53 2011 Return-path: Envelope-to: www-data@lists.xensource.com Delivery-date: Mon, 12 Sep 2011 03:15:53 -0700 Received: from localhost ([127.0.0.1] helo=lists.colo.xensource.com) by lists.xensource.com with esmtp (Exim 4.43) id 1R33YP-00026b-JQ; Mon, 12 Sep 2011 03:15:53 -0700 Received: from mail21.messagelabs.com ([85.158.143.35]) by lists.xensource.com with esmtp (Exim 4.43) id 1R33Xo-0001uk-Oi for xen-devel@lists.xensource.com; Mon, 12 Sep 2011 03:15:17 -0700 X-Env-Sender: Andrew.Cooper3@citrix.com X-Msg-Ref: server-8.tower-21.messagelabs.com!1315822497!58616855!1 X-Originating-IP: [66.165.176.89] X-StarScan-Version: 6.3.6; banners=-,-,- X-VirusChecked: Checked Received: (qmail 13329 invoked from network); 12 Sep 2011 10:14:58 -0000 Received: from smtp.citrix.com (HELO SMTP.CITRIX.COM) (66.165.176.89) by server-8.tower-21.messagelabs.com with RC4-SHA encrypted SMTP; 12 Sep 2011 10:14:58 -0000 X-IronPort-AV: E=Sophos;i="4.68,367,1312171200"; d="scan'208";a="16866080" Received: from ftlpmailmx01.citrite.net ([10.13.107.65]) by FTLPIPO01.CITRIX.COM with ESMTP/TLS/RC4-MD5; 12 Sep 2011 06:15:12 -0400 Received: from [10.80.2.18] (10.80.2.18) by FTLPMAILMX01.citrite.net (10.13.107.65) with Microsoft SMTP Server id 8.3.137.0; Mon, 12 Sep 2011 06:15:11 -0400 Message-ID: <4E6DDBAE.6060104@citrix.com> Date: Mon, 12 Sep 2011 11:15:10 +0100 From: Andrew Cooper User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.2.21) Gecko/20110831 Lightning/1.0b2 Thunderbird/3.1.13 MIME-Version: 1.0 To: Jan Beulich Subject: Re: [Xen-devel] Re: 4.0/4.1 requests - IO-APIC EOI v4 [RFC] References: <4E689D9A.1020405@citrix.com> <4E68C6C10200007800055485@nat28.tlf.novell.com> <4E68C09B.8050409@citrix.com> <4E68E1D30200007800055501@nat28.tlf.novell.com> <4E68C9A9.8090707@citrix.com> <4E6A2B7F.6060006@citrix.com> <4E6A4F66020000780005589B@nat28.tlf.novell.com> <4E6A36EB.6000802@citrix.com> <4E6A54DB02000078000558B6@nat28.tlf.novell.com> <4E6A3D5B.5010104@citrix.com> <4E6A430B.30308@citrix.com> <4E6DC7D80200007800055AB1@nat28.tlf.novell.com> In-Reply-To: <4E6DC7D80200007800055AB1@nat28.tlf.novell.com> Content-Type: text/plain; charset="ISO-8859-1" Content-Transfer-Encoding: 7bit Cc: Keir Fraser , "xen-devel@lists.xensource.com" X-BeenThere: xen-devel@lists.xensource.com X-Mailman-Version: 2.1.5 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xensource.com Errors-To: xen-devel-bounces@lists.xensource.com On 12/09/11 07:50, Jan Beulich wrote: >>>> On 09.09.11 at 18:47, Andrew Cooper wrote: >> On 09/09/11 17:22, Andrew Cooper wrote: >>> ---SNIP--- >>> >>> Version 3. Applied Jan's suggestions, and extended some of the comments. >>> >> V4 - get the BUG_ON logic correct (oops). >> >> I have now done a few reboot tests and a kexec test with this patch. >> >> Are there any other tests you would suggest, or shall I formally submit >> the patch for unstable and backporting? > > Looks technically good now, but there are a few cosmetic comments still: > >> --- a/xen/arch/x86/io_apic.c Mon Sep 05 15:10:28 2011 +0100 >> +++ b/xen/arch/x86/io_apic.c Fri Sep 09 17:20:49 2011 +0100 >> @@ -68,6 +68,16 @@ int __read_mostly nr_ioapics; >> #define MAX_PLUS_SHARED_IRQS nr_irqs_gsi >> #define PIN_MAP_SIZE (MAX_PLUS_SHARED_IRQS + nr_irqs_gsi) >> >> + >> +#define ioapic_has_eoi_reg(apic) (mp_ioapics[(apic)].mpc_apicver >= 0x20) >> + >> +static void __io_apic_eoi(unsigned int apic, unsigned int vector, unsigned int pin); >> +static void io_apic_eoi(unsigned int apic, unsigned int vector, unsigned int pin); > No need to declare these here if you move the definitions up before > the first use (would fit well after ioapic_write_entry()). Ok >> + >> +#define io_apic_eoi_vector(apic, vector) io_apic_eoi((apic), (vector), -1) >> +#define io_apic_eoi_pin(apic, pin) io_apic_eoi((apic), -1, (pin)) >> + >> + >> /* >> * This is performance-critical, we want to do it O(1) >> * >> ... >> @@ -2622,3 +2621,124 @@ void __init init_ioapic_mappings(void) >> printk(XENLOG_INFO "IRQ limits: %u GSI, %u MSI/MSI-X\n", >> nr_irqs_gsi, nr_irqs - nr_irqs_gsi); >> } >> + >> +/* EOI an IO-APIC entry. One of vector or pin may be -1, indicating that >> + * it should be worked out using the other. This function disables interrupts >> + * and takes the ioapic_lock */ >> +static void io_apic_eoi(unsigned int apic, unsigned int vector, unsigned int pin) >> +{ >> + unsigned int flags; >> + spin_lock_irqsave(&ioapic_lock, flags); >> + __io_apic_eoi(apic, vector, pin); >> + spin_unlock_irqrestore(&ioapic_lock, flags); >> +} >> + >> +/* EOI an IO-APIC entry. One of vector or pin may be -1, indicating that >> + * it should be worked out using the other. This function expect that the >> + * ioapic_lock is taken, and interrupts are disabled (or there is a good reason >> + * not to), and that if both pin and vector are passed, that they refer to the >> + * same redirection entry in the IO-APIC. */ >> +static void __io_apic_eoi(unsigned int apic, unsigned int vector, unsigned int pin) >> +{ >> + /* Ensure some useful information is passed in */ >> + BUG_ON( !(vector == -1 && pin != -1) ); >> + >> + /* Prefer the use of the EOI register if available */ >> + if ( ioapic_has_eoi_reg(apic) ) >> + { >> + /* If vector is unknown, read it from the IO-APIC */ >> + if ( vector == -1 ) >> + vector = __ioapic_read_entry(apic, pin, TRUE).vector; >> + >> + *(IO_APIC_BASE(apic)+16) = vector; >> + } >> + else >> + { >> + /* Else fake an EOI by switching to edge triggered mode >> + * and back */ >> + struct IO_APIC_route_entry entry; >> + bool_t need_to_unmask = 0; >> + >> + /* If pin is unknown, search for it */ >> + if ( pin == -1 ) >> + { >> + unsigned int p; >> + for ( p = 0; p < nr_ioapic_registers[apic]; ++p ) >> + { >> + entry = __ioapic_read_entry(apic, p, TRUE); >> + if ( entry.vector == vector ) >> + { >> + pin = p; >> + /* break; */ >> + >> + /* Here should be a break out of the loop, but at the > ... moment ... > >> + * Xen code doesn't actually prevent multiple IO-APIC >> + * entries being assigned the same vector, so EOI all >> + * pins which have the correct vector. >> + * >> + * Remove the following code when the above assertion >> + * is fulfilled. */ >> + > Why don't you just call __io_apic_eoi() recursively here? > > Jan If I call the function recursively, it will loop forever. Anyway, the need to clear multiple pins is only temorary until George finishes his per-device AMD interrupt remap patch which will enforce vector uniqueness in each IO-APIC. My expectation is that this issue will be fixed in the next few weeks. >> + if ( ! entry.mask ) >> + { >> + /* If entry is not currently masked, mask it and make >> + * a note to unmask it later */ >> + entry.mask = 1; >> + __ioapic_write_entry(apic, pin, TRUE, entry); >> + need_to_unmask = 1; >> + } >> + >> + /* Flip the trigger mode to edge and back */ >> + entry.trigger = 0; >> + __ioapic_write_entry(apic, pin, TRUE, entry); >> + entry.trigger = 1; >> + __ioapic_write_entry(apic, pin, TRUE, entry); >> + >> + if ( need_to_unmask ) >> + { >> + /* Unmask if neccesary */ >> + entry.mask = 0; >> + __ioapic_write_entry(apic, pin, TRUE, entry); >> + } >> + >> + } >> + } >> + >> + /* If search fails, nothing to do */ >> + >> + /* if ( pin == -1 ) */ >> + >> + /* Because the loop wasn't broken out of (see comment above), >> + * all relevant pins have been EOI, so we can always return. >> + * >> + * Re-instate the if statement above when the Xen logic has been >> + * fixed.*/ >> + >> + return; >> + } >> + >> + entry = __ioapic_read_entry(apic, pin, TRUE); >> + >> + if ( ! entry.mask ) >> + { >> + /* If entry is not currently masked, mask it and make >> + * a note to unmask it later */ >> + entry.mask = 1; >> + __ioapic_write_entry(apic, pin, TRUE, entry); >> + need_to_unmask = 1; >> + } >> + >> + /* Flip the trigger mode to edge and back */ >> + entry.trigger = 0; >> + __ioapic_write_entry(apic, pin, TRUE, entry); >> + entry.trigger = 1; >> + __ioapic_write_entry(apic, pin, TRUE, entry); >> + >> + if ( need_to_unmask ) >> + { >> + /* Unmask if neccesary */ >> + entry.mask = 0; >> + __ioapic_write_entry(apic, pin, TRUE, entry); >> + } >> + } >> +} >> ... I will formally submit the patch for inclusion now. -- Andrew Cooper - Dom0 Kernel Engineer, Citrix XenServer T: +44 (0)1223 225 900, http://www.citrix.com _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel From xen-devel-bounces@lists.xensource.com Mon Sep 12 03:24:04 2011 Return-path: Envelope-to: www-data@lists.xensource.com Delivery-date: Mon, 12 Sep 2011 03:24:04 -0700 Received: from localhost ([127.0.0.1] helo=lists.colo.xensource.com) by lists.xensource.com with esmtp (Exim 4.43) id 1R33gK-0002h6-AT; Mon, 12 Sep 2011 03:24:04 -0700 Received: from mail174.messagelabs.com ([85.158.138.51]) by lists.xensource.com with esmtp (Exim 4.43) id 1R33fY-0002UU-0k for xen-devel@lists.xensource.com; Mon, 12 Sep 2011 03:23:16 -0700 X-Env-Sender: JBeulich@suse.com X-Msg-Ref: server-2.tower-174.messagelabs.com!1315822990!31094123!1 X-Originating-IP: [130.57.49.28] X-StarScan-Version: 6.3.6; banners=-,-,- X-VirusChecked: Checked Received: (qmail 13479 invoked from network); 12 Sep 2011 10:23:12 -0000 Received: from nat28.tlf.novell.com (HELO nat28.tlf.novell.com) (130.57.49.28) by server-2.tower-174.messagelabs.com with DHE-RSA-AES256-SHA encrypted SMTP; 12 Sep 2011 10:23:12 -0000 Received: from EMEA1-MTA by nat28.tlf.novell.com with Novell_GroupWise; Mon, 12 Sep 2011 11:23:10 +0100 Message-Id: <4E6DF9AB0200007800055B2F@nat28.tlf.novell.com> X-Mailer: Novell GroupWise Internet Agent 8.0.1 Date: Mon, 12 Sep 2011 11:23:07 +0100 From: "Jan Beulich" To: "Andrew Cooper" Subject: Re: [Xen-devel] Re: 4.0/4.1 requests - IO-APIC EOI v4 [RFC] References: <4E689D9A.1020405@citrix.com> <4E68C6C10200007800055485@nat28.tlf.novell.com> <4E68C09B.8050409@citrix.com> <4E68E1D30200007800055501@nat28.tlf.novell.com> <4E68C9A9.8090707@citrix.com> <4E6A2B7F.6060006@citrix.com> <4E6A4F66020000780005589B@nat28.tlf.novell.com> <4E6A36EB.6000802@citrix.com> <4E6A54DB02000078000558B6@nat28.tlf.novell.com> <4E6A3D5B.5010104@citrix.com> <4E6A430B.30308@citrix.com> <4E6DC7D80200007800055AB1@nat28.tlf.novell.com> <4E6DDBAE.6060104@citrix.com> In-Reply-To: <4E6DDBAE.6060104@citrix.com> Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: quoted-printable Content-Disposition: inline Cc: Keir Fraser , "xen-devel@lists.xensource.com" X-BeenThere: xen-devel@lists.xensource.com X-Mailman-Version: 2.1.5 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xensource.com Errors-To: xen-devel-bounces@lists.xensource.com >>> On 12.09.11 at 12:15, Andrew Cooper wrote: > On 12/09/11 07:50, Jan Beulich wrote: >>>>> On 09.09.11 at 18:47, Andrew Cooper = wrote: >>> + * Xen code doesn't actually prevent multiple = IO-APIC >>> + * entries being assigned the same vector, so EOI = all >>> + * pins which have the correct vector. >>> + * >>> + * Remove the following code when the above = assertion >>> + * is fulfilled. */ >>> + >> Why don't you just call __io_apic_eoi() recursively here? >> >> Jan >=20 > If I call the function recursively, it will loop forever. Anyway, the Why would it loop forever? You get in here only with pin =3D=3D -1, and for the recursive call you'd pass the pin number you determined. > need to clear multiple pins is only temorary until George finishes his > per-device AMD interrupt remap patch which will enforce vector > uniqueness in each IO-APIC. My expectation is that this issue will be > fixed in the next few weeks. Sure. Jan _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel From xen-devel-bounces@lists.xensource.com Mon Sep 12 03:28:05 2011 Return-path: Envelope-to: www-data@lists.xensource.com Delivery-date: Mon, 12 Sep 2011 03:28:05 -0700 Received: from localhost ([127.0.0.1] helo=lists.colo.xensource.com) by lists.xensource.com with esmtp (Exim 4.43) id 1R33kD-000373-8E; Mon, 12 Sep 2011 03:28:05 -0700 Received: from mail174.messagelabs.com ([85.158.138.51]) by lists.xensource.com with esmtp (Exim 4.43) id 1R33jX-0002uV-Qo for xen-devel@lists.xensource.com; Mon, 12 Sep 2011 03:27:24 -0700 X-Env-Sender: Stefano.Stabellini@eu.citrix.com X-Msg-Ref: server-2.tower-174.messagelabs.com!1315823235!31094750!1 X-Originating-IP: [62.200.22.115] X-StarScan-Version: 6.3.6; banners=-,-,- X-VirusChecked: Checked Received: (qmail 31124 invoked from network); 12 Sep 2011 10:27:20 -0000 Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115) by server-2.tower-174.messagelabs.com with RC4-SHA encrypted SMTP; 12 Sep 2011 10:27:20 -0000 X-IronPort-AV: E=Sophos;i="4.68,367,1312156800"; d="scan'208";a="7724687" Received: from lonpmailmx01.citrite.net ([10.30.203.162]) by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5; 12 Sep 2011 10:27:15 +0000 Received: from kaball.uk.xensource.com (10.80.2.59) by LONPMAILMX01.citrite.net (10.30.203.162) with Microsoft SMTP Server id 8.3.137.0; Mon, 12 Sep 2011 11:27:15 +0100 Date: Mon, 12 Sep 2011 11:35:38 +0100 From: Stefano Stabellini X-X-Sender: sstabellini@kaball-desktop To: =?UTF-8?Q?Sven_K=C3=B6hler?= Subject: Re: [Xen-devel] 3.0.4 and 3.1-rc4 based dom0 won't boot with acpi=off In-Reply-To: <4E6C0473.8090905@gmail.com> Message-ID: References: <20110911002807.GA9989@oracle.com> <4E6C0473.8090905@gmail.com> User-Agent: Alpine 2.00 (DEB 1167 2008-08-23) MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="8323329-389003941-1315823753=:12963" Cc: "xen-devel@lists.xensource.com" , Konrad Rzeszutek Wilk X-BeenThere: xen-devel@lists.xensource.com X-Mailman-Version: 2.1.5 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xensource.com Errors-To: xen-devel-bounces@lists.xensource.com --8323329-389003941-1315823753=:12963 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: 8BIT On Sun, 11 Sep 2011, Sven Köhler wrote: > Thanks for explaining. Now what about the future? Will there be some > solution for the acpi=off case? Not likely. > I'm a bit confused, since your words don't sound like there is a way to > boot with acpi=off. But other dom0 kernels actually boot with acpi=off. > So after all, some other way for setting up interrupts seems to exist. It exists in xenlinux kernels, where xen support is maintained in an out of tree patch queue by distros. Currently Linux mainline only offers acpi and msi registration hooks to subsystems. --8323329-389003941-1315823753=:12963 Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel --8323329-389003941-1315823753=:12963-- From xen-devel-bounces@lists.xensource.com Mon Sep 12 03:34:51 2011 Return-path: Envelope-to: www-data@lists.xensource.com Delivery-date: Mon, 12 Sep 2011 03:34:51 -0700 Received: from localhost ([127.0.0.1] helo=lists.colo.xensource.com) by lists.xensource.com with esmtp (Exim 4.43) id 1R33qk-0003ZX-Lh; Mon, 12 Sep 2011 03:34:50 -0700 Received: from mail216.messagelabs.com ([85.158.143.99]) by lists.xensource.com with esmtp (Exim 4.43) id 1R33q2-0003NY-Jq for xen-devel@lists.xensource.com; Mon, 12 Sep 2011 03:34:07 -0700 X-Env-Sender: Andrew.Cooper3@citrix.com X-Msg-Ref: server-7.tower-216.messagelabs.com!1315823643!17934552!1 X-Originating-IP: [62.200.22.115] X-StarScan-Version: 6.3.6; banners=-,-,- X-VirusChecked: Checked Received: (qmail 13655 invoked from network); 12 Sep 2011 10:34:03 -0000 Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115) by server-7.tower-216.messagelabs.com with RC4-SHA encrypted SMTP; 12 Sep 2011 10:34:03 -0000 X-IronPort-AV: E=Sophos;i="4.68,367,1312156800"; d="scan'208";a="7724851" Received: from lonpmailmx01.citrite.net ([10.30.203.162]) by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5; 12 Sep 2011 10:33:37 +0000 Received: from andrewcoop.uk.xensource.com (10.80.2.18) by LONPMAILMX01.citrite.net (10.30.203.162) with Microsoft SMTP Server id 8.3.137.0; Mon, 12 Sep 2011 11:33:37 +0100 Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Mercurial-Node: 3c5869cb1744c00a4568d3d41b8743b2bcf99524 Message-ID: <3c5869cb1744c00a4568.1315823616@andrewcoop.uk.xensource.com> User-Agent: Mercurial-patchbomb/1.4.3 Date: Mon, 12 Sep 2011 11:33:36 +0100 From: Andrew Cooper To: xen-devel@lists.xensource.com Cc: Andrew Cooper Subject: [Xen-devel] [PATCH] IRQ: IO-APIC support End Of Interrupt for older IO-APICs X-BeenThere: xen-devel@lists.xensource.com X-Mailman-Version: 2.1.5 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xensource.com Errors-To: xen-devel-bounces@lists.xensource.com The old io_apic_eoi() function using the EOI register only works for IO-APICs with a version of 0x20. Older IO-APICs do not have an EOI register so line level interrupts have to be EOI'd by flipping the mode to edge and back, which clears the IRR and Delivery Status bits. This patch replaces the current io_apic_eoi() function with one which takes into account the version of the IO-APIC and EOI's appropriately. Signed-off-by: Andrew Cooper diff -r 0268e7380953 -r 3c5869cb1744 xen/arch/x86/io_apic.c --- a/xen/arch/x86/io_apic.c Mon Sep 05 15:10:28 2011 +0100 +++ b/xen/arch/x86/io_apic.c Mon Sep 12 11:32:01 2011 +0100 @@ -68,6 +68,13 @@ int __read_mostly nr_ioapics; #define MAX_PLUS_SHARED_IRQS nr_irqs_gsi #define PIN_MAP_SIZE (MAX_PLUS_SHARED_IRQS + nr_irqs_gsi) + +#define ioapic_has_eoi_reg(apic) (mp_ioapics[(apic)].mpc_apicver >= 0x20) + +#define io_apic_eoi_vector(apic, vector) io_apic_eoi((apic), (vector), -1) +#define io_apic_eoi_pin(apic, pin) io_apic_eoi((apic), -1, (pin)) + + /* * This is performance-critical, we want to do it O(1) * @@ -208,6 +215,127 @@ static void ioapic_write_entry( spin_unlock_irqrestore(&ioapic_lock, flags); } +/* EOI an IO-APIC entry. One of vector or pin may be -1, indicating that + * it should be worked out using the other. This function expect that the + * ioapic_lock is taken, and interrupts are disabled (or there is a good reason + * not to), and that if both pin and vector are passed, that they refer to the + * same redirection entry in the IO-APIC. */ +static void __io_apic_eoi(unsigned int apic, unsigned int vector, unsigned int pin) +{ + /* Ensure some useful information is passed in */ + BUG_ON( (vector == -1 && pin == -1) ); + + /* Prefer the use of the EOI register if available */ + if ( ioapic_has_eoi_reg(apic) ) + { + /* If vector is unknown, read it from the IO-APIC */ + if ( vector == -1 ) + vector = __ioapic_read_entry(apic, pin, TRUE).vector; + + *(IO_APIC_BASE(apic)+16) = vector; + } + else + { + /* Else fake an EOI by switching to edge triggered mode + * and back */ + struct IO_APIC_route_entry entry; + bool_t need_to_unmask = 0; + + /* If pin is unknown, search for it */ + if ( pin == -1 ) + { + unsigned int p; + for ( p = 0; p < nr_ioapic_registers[apic]; ++p ) + { + entry = __ioapic_read_entry(apic, p, TRUE); + if ( entry.vector == vector ) + { + pin = p; + /* break; */ + + /* Here should be a break out of the loop, but at the + * Xen code doesn't actually prevent multiple IO-APIC + * entries being assigned the same vector, so EOI all + * pins which have the correct vector. + * + * Remove the following code when the above assertion + * is fulfilled. */ + + if ( ! entry.mask ) + { + /* If entry is not currently masked, mask it and make + * a note to unmask it later */ + entry.mask = 1; + __ioapic_write_entry(apic, pin, TRUE, entry); + need_to_unmask = 1; + } + + /* Flip the trigger mode to edge and back */ + entry.trigger = 0; + __ioapic_write_entry(apic, pin, TRUE, entry); + entry.trigger = 1; + __ioapic_write_entry(apic, pin, TRUE, entry); + + if ( need_to_unmask ) + { + /* Unmask if neccesary */ + entry.mask = 0; + __ioapic_write_entry(apic, pin, TRUE, entry); + } + + } + } + + /* If search fails, nothing to do */ + + /* if ( pin == -1 ) */ + + /* Because the loop wasn't broken out of (see comment above), + * all relevant pins have been EOI, so we can always return. + * + * Re-instate the if statement above when the Xen logic has been + * fixed.*/ + + return; + } + + entry = __ioapic_read_entry(apic, pin, TRUE); + + if ( ! entry.mask ) + { + /* If entry is not currently masked, mask it and make + * a note to unmask it later */ + entry.mask = 1; + __ioapic_write_entry(apic, pin, TRUE, entry); + need_to_unmask = 1; + } + + /* Flip the trigger mode to edge and back */ + entry.trigger = 0; + __ioapic_write_entry(apic, pin, TRUE, entry); + entry.trigger = 1; + __ioapic_write_entry(apic, pin, TRUE, entry); + + if ( need_to_unmask ) + { + /* Unmask if neccesary */ + entry.mask = 0; + __ioapic_write_entry(apic, pin, TRUE, entry); + } + } +} + +/* EOI an IO-APIC entry. One of vector or pin may be -1, indicating that + * it should be worked out using the other. This function disables interrupts + * and takes the ioapic_lock */ +static void io_apic_eoi(unsigned int apic, unsigned int vector, unsigned int pin) +{ + unsigned int flags; + spin_lock_irqsave(&ioapic_lock, flags); + __io_apic_eoi(apic, vector, pin); + spin_unlock_irqrestore(&ioapic_lock, flags); +} + /* * Saves all the IO-APIC RTE's */ @@ -357,7 +485,7 @@ static void __eoi_IO_APIC_irq(unsigned i pin = entry->pin; if (pin == -1) break; - io_apic_eoi(entry->apic, vector); + __io_apic_eoi(entry->apic, vector, pin); if (!entry->next) break; entry = irq_2_pin + entry->next; @@ -397,18 +525,7 @@ static void clear_IO_APIC_pin(unsigned i entry.trigger = 1; __ioapic_write_entry(apic, pin, TRUE, entry); } - if (mp_ioapics[apic].mpc_apicver >= 0x20) - io_apic_eoi(apic, entry.vector); - else { - /* - * Mechanism by which we clear remoteIRR in this case is by - * changing the trigger mode to edge and back to level. - */ - entry.trigger = 0; - __ioapic_write_entry(apic, pin, TRUE, entry); - entry.trigger = 1; - __ioapic_write_entry(apic, pin, TRUE, entry); - } + __io_apic_eoi(apic, entry.vector, pin); } /* @@ -1750,7 +1867,7 @@ static void end_level_ioapic_irq (unsign { int ioapic; for (ioapic = 0; ioapic < nr_ioapics; ioapic++) - io_apic_eoi(ioapic, i); + io_apic_eoi_vector(ioapic, i); } v = apic_read(APIC_TMR + ((i & ~0x1f) >> 1)); @@ -2622,3 +2739,4 @@ void __init init_ioapic_mappings(void) printk(XENLOG_INFO "IRQ limits: %u GSI, %u MSI/MSI-X\n", nr_irqs_gsi, nr_irqs - nr_irqs_gsi); } + diff -r 0268e7380953 -r 3c5869cb1744 xen/include/asm-x86/io_apic.h --- a/xen/include/asm-x86/io_apic.h Mon Sep 05 15:10:28 2011 +0100 +++ b/xen/include/asm-x86/io_apic.h Mon Sep 12 11:32:01 2011 +0100 @@ -157,11 +157,6 @@ static inline void io_apic_write(unsigne __io_apic_write(apic, reg, value); } -static inline void io_apic_eoi(unsigned int apic, unsigned int vector) -{ - *(IO_APIC_BASE(apic)+16) = vector; -} - /* * Re-write a value: to be used for read-modify-write * cycles where the read already set up the index register. _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel From xen-devel-bounces@lists.xensource.com Mon Sep 12 04:31:57 2011 Return-path: Envelope-to: www-data@lists.xensource.com Delivery-date: Mon, 12 Sep 2011 04:31:57 -0700 Received: from localhost ([127.0.0.1] helo=lists.colo.xensource.com) by lists.xensource.com with esmtp (Exim 4.43) id 1R34jz-0005VC-Pw; Mon, 12 Sep 2011 04:31:55 -0700 Received: from mail216.messagelabs.com ([85.158.143.99]) by lists.xensource.com with esmtp (Exim 4.43) id 1R34j9-0005IE-S8 for xen-devel@lists.xensource.com; Mon, 12 Sep 2011 04:31:04 -0700 X-Env-Sender: keir.xen@gmail.com X-Msg-Ref: server-4.tower-216.messagelabs.com!1315827060!17918042!1 X-Originating-IP: [74.125.82.43] X-StarScan-Version: 6.3.6; banners=-,-,- X-VirusChecked: Checked Received: (qmail 32084 invoked from network); 12 Sep 2011 11:31:00 -0000 Received: from mail-ww0-f43.google.com (HELO mail-ww0-f43.google.com) (74.125.82.43) by server-4.tower-216.messagelabs.com with RC4-SHA encrypted SMTP; 12 Sep 2011 11:31:00 -0000 Received: by wwf27 with SMTP id 27so1064912wwf.24 for ; Mon, 12 Sep 2011 04:31:00 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=user-agent:date:subject:from:to:cc:message-id:thread-topic :thread-index:in-reply-to:mime-version:content-type :content-transfer-encoding; bh=3Ryw2g0/sZl1I67wzC9qTp2b1daMJTRiBixIINwkfS8=; b=AqIIeZSiB5NvtCcSgIIwW1oNNgLcmtgyDOu+vp2Zkj981pepq2lXsJ+jiQZ0lgtnKU hTKjZBl2kWKNrln9UgWMGNXmHl5Eg+4A0ehrOuJ3DwRAt0fBRDIcHkjnirw+m9Y9KpP0 lLSoJPgXaa/LrL2UaoRX1KMmMfN4UDqPQv3Y4= Received: by 10.216.185.207 with SMTP id u57mr2297780wem.109.1315827060147; Mon, 12 Sep 2011 04:31:00 -0700 (PDT) Received: from [192.168.1.78] (host86-137-116-193.range86-137.btcentralplus.com [86.137.116.193]) by mx.google.com with ESMTPS id fr18sm15918874wbb.9.2011.09.12.04.30.58 (version=SSLv3 cipher=OTHER); Mon, 12 Sep 2011 04:30:59 -0700 (PDT) User-Agent: Microsoft-Entourage/12.30.0.110427 Date: Mon, 12 Sep 2011 12:30:54 +0100 Subject: Re: [Xen-devel] Re: 4.0/4.1 requests - IO-APIC EOI v4 [RFC] From: Keir Fraser To: Jan Beulich , Andrew Cooper Message-ID: Thread-Topic: [Xen-devel] Re: 4.0/4.1 requests - IO-APIC EOI v4 [RFC] Thread-Index: AcxxP26jSANcPtfEZ0qJP1OmRs/uww== In-Reply-To: <4E6DF9AB0200007800055B2F@nat28.tlf.novell.com> Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit Cc: "xen-devel@lists.xensource.com" X-BeenThere: xen-devel@lists.xensource.com X-Mailman-Version: 2.1.5 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xensource.com Errors-To: xen-devel-bounces@lists.xensource.com On 12/09/2011 11:23, "Jan Beulich" wrote: >>>> On 12.09.11 at 12:15, Andrew Cooper wrote: >> On 12/09/11 07:50, Jan Beulich wrote: >>>>>> On 09.09.11 at 18:47, Andrew Cooper wrote: >>>> + * Xen code doesn't actually prevent multiple IO-APIC >>>> + * entries being assigned the same vector, so EOI all >>>> + * pins which have the correct vector. >>>> + * >>>> + * Remove the following code when the above assertion >>>> + * is fulfilled. */ >>>> + >>> Why don't you just call __io_apic_eoi() recursively here? >>> >>> Jan >> >> If I call the function recursively, it will loop forever. Anyway, the > > Why would it loop forever? You get in here only with pin == -1, and > for the recursive call you'd pass the pin number you determined. Exactly. Please re-send the patch with the recursive call. It makes the function quite a bit shorter. -- Keir >> need to clear multiple pins is only temorary until George finishes his >> per-device AMD interrupt remap patch which will enforce vector >> uniqueness in each IO-APIC. My expectation is that this issue will be >> fixed in the next few weeks. > > Sure. > > Jan > _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel From xen-devel-bounces@lists.xensource.com Mon Sep 12 04:41:48 2011 Return-path: Envelope-to: www-data@lists.xensource.com Delivery-date: Mon, 12 Sep 2011 04:41:48 -0700 Received: from localhost ([127.0.0.1] helo=lists.colo.xensource.com) by lists.xensource.com with esmtp (Exim 4.43) id 1R34tY-00066h-3W; Mon, 12 Sep 2011 04:41:48 -0700 Received: from mail27.messagelabs.com ([193.109.254.147]) by lists.xensource.com with esmtp (Exim 4.43) id 1R34sk-0005tn-0p for xen-devel@lists.xensource.com; Mon, 12 Sep 2011 04:40:58 -0700 X-Env-Sender: Andrew.Cooper3@citrix.com X-Msg-Ref: server-15.tower-27.messagelabs.com!1315827645!48390959!1 X-Originating-IP: [66.165.176.89] X-StarScan-Version: 6.3.6; banners=-,-,- X-VirusChecked: Checked Received: (qmail 23483 invoked from network); 12 Sep 2011 11:40:46 -0000 Received: from smtp.citrix.com (HELO SMTP.CITRIX.COM) (66.165.176.89) by server-15.tower-27.messagelabs.com with RC4-SHA encrypted SMTP; 12 Sep 2011 11:40:46 -0000 X-IronPort-AV: E=Sophos;i="4.68,367,1312171200"; d="scan'208";a="16867189" Received: from ftlpmailmx02.citrite.net ([10.13.107.66]) by FTLPIPO01.CITRIX.COM with ESMTP/TLS/RC4-MD5; 12 Sep 2011 07:40:53 -0400 Received: from [10.80.2.18] (10.80.2.18) by FTLPMAILMX02.citrite.net (10.13.107.66) with Microsoft SMTP Server id 8.3.137.0; Mon, 12 Sep 2011 07:40:53 -0400 Message-ID: <4E6DEFC3.3000809@citrix.com> Date: Mon, 12 Sep 2011 12:40:51 +0100 From: Andrew Cooper User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.2.21) Gecko/20110831 Lightning/1.0b2 Thunderbird/3.1.13 MIME-Version: 1.0 To: "xen-devel@lists.xensource.com" References: <3c5869cb1744c00a4568.1315823616@andrewcoop.uk.xensource.com> In-Reply-To: <3c5869cb1744c00a4568.1315823616@andrewcoop.uk.xensource.com> Content-Type: multipart/mixed; boundary="------------020901090302070601010405" Cc: Keir Fraser , Jan Beulich Subject: [Xen-devel] [PATCH] IRQ: IO-APIC support End Of Interrupt for older IO-APICs v2 X-BeenThere: xen-devel@lists.xensource.com X-Mailman-Version: 2.1.5 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xensource.com Errors-To: xen-devel-bounces@lists.xensource.com --------------020901090302070601010405 Content-Type: text/plain; charset="ISO-8859-1" Content-Transfer-Encoding: 7bit Version 2. Make recursive call to reduce code size -- Andrew Cooper - Dom0 Kernel Engineer, Citrix XenServer T: +44 (0)1223 225 900, http://www.citrix.com --------------020901090302070601010405 Content-Type: text/x-patch; name="IO-APIC-eoi.patch" Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename="IO-APIC-eoi.patch" IRQ: IO-APIC support End Of Interrupt for older IO-APICs The old io_apic_eoi() function using the EOI register only works for IO-APICs with a version of 0x20. Older IO-APICs do not have an EOI register so line level interrupts have to be EOI'd by flipping the mode to edge and back, which clears the IRR and Delivery Status bits. This patch replaces the current io_apic_eoi() function with one which takes into account the version of the IO-APIC and EOI's appropriately. v2: make recursive call to __io_apic_eoi() to reduce code size. Signed-off-by: Andrew Cooper diff -r 0268e7380953 xen/arch/x86/io_apic.c --- a/xen/arch/x86/io_apic.c Mon Sep 05 15:10:28 2011 +0100 +++ b/xen/arch/x86/io_apic.c Mon Sep 12 12:40:18 2011 +0100 @@ -68,6 +68,13 @@ int __read_mostly nr_ioapics; #define MAX_PLUS_SHARED_IRQS nr_irqs_gsi #define PIN_MAP_SIZE (MAX_PLUS_SHARED_IRQS + nr_irqs_gsi) + +#define ioapic_has_eoi_reg(apic) (mp_ioapics[(apic)].mpc_apicver >= 0x20) + +#define io_apic_eoi_vector(apic, vector) io_apic_eoi((apic), (vector), -1) +#define io_apic_eoi_pin(apic, pin) io_apic_eoi((apic), -1, (pin)) + + /* * This is performance-critical, we want to do it O(1) * @@ -208,6 +215,105 @@ static void ioapic_write_entry( spin_unlock_irqrestore(&ioapic_lock, flags); } +/* EOI an IO-APIC entry. One of vector or pin may be -1, indicating that + * it should be worked out using the other. This function expect that the + * ioapic_lock is taken, and interrupts are disabled (or there is a good reason + * not to), and that if both pin and vector are passed, that they refer to the + * same redirection entry in the IO-APIC. */ +static void __io_apic_eoi(unsigned int apic, unsigned int vector, unsigned int pin) +{ + /* Ensure some useful information is passed in */ + BUG_ON( (vector == -1 && pin == -1) ); + + /* Prefer the use of the EOI register if available */ + if ( ioapic_has_eoi_reg(apic) ) + { + /* If vector is unknown, read it from the IO-APIC */ + if ( vector == -1 ) + vector = __ioapic_read_entry(apic, pin, TRUE).vector; + + *(IO_APIC_BASE(apic)+16) = vector; + } + else + { + /* Else fake an EOI by switching to edge triggered mode + * and back */ + struct IO_APIC_route_entry entry; + bool_t need_to_unmask = 0; + + /* If pin is unknown, search for it */ + if ( pin == -1 ) + { + unsigned int p; + for ( p = 0; p < nr_ioapic_registers[apic]; ++p ) + { + entry = __ioapic_read_entry(apic, p, TRUE); + if ( entry.vector == vector ) + { + pin = p; + /* break; */ + + /* Here should be a break out of the loop, but at the + * Xen code doesn't actually prevent multiple IO-APIC + * entries being assigned the same vector, so EOI all + * pins which have the correct vector. + * + * Remove the following code when the above assertion + * is fulfilled. */ + __io_apic_eoi(apic, vector, p); + } + } + + /* If search fails, nothing to do */ + + /* if ( pin == -1 ) */ + + /* Because the loop wasn't broken out of (see comment above), + * all relevant pins have been EOI, so we can always return. + * + * Re-instate the if statement above when the Xen logic has been + * fixed.*/ + + return; + } + + entry = __ioapic_read_entry(apic, pin, TRUE); + + if ( ! entry.mask ) + { + /* If entry is not currently masked, mask it and make + * a note to unmask it later */ + entry.mask = 1; + __ioapic_write_entry(apic, pin, TRUE, entry); + need_to_unmask = 1; + } + + /* Flip the trigger mode to edge and back */ + entry.trigger = 0; + __ioapic_write_entry(apic, pin, TRUE, entry); + entry.trigger = 1; + __ioapic_write_entry(apic, pin, TRUE, entry); + + if ( need_to_unmask ) + { + /* Unmask if neccesary */ + entry.mask = 0; + __ioapic_write_entry(apic, pin, TRUE, entry); + } + } +} + +/* EOI an IO-APIC entry. One of vector or pin may be -1, indicating that + * it should be worked out using the other. This function disables interrupts + * and takes the ioapic_lock */ +static void io_apic_eoi(unsigned int apic, unsigned int vector, unsigned int pin) +{ + unsigned int flags; + spin_lock_irqsave(&ioapic_lock, flags); + __io_apic_eoi(apic, vector, pin); + spin_unlock_irqrestore(&ioapic_lock, flags); +} + /* * Saves all the IO-APIC RTE's */ @@ -357,7 +463,7 @@ static void __eoi_IO_APIC_irq(unsigned i pin = entry->pin; if (pin == -1) break; - io_apic_eoi(entry->apic, vector); + __io_apic_eoi(entry->apic, vector, pin); if (!entry->next) break; entry = irq_2_pin + entry->next; @@ -397,18 +503,7 @@ static void clear_IO_APIC_pin(unsigned i entry.trigger = 1; __ioapic_write_entry(apic, pin, TRUE, entry); } - if (mp_ioapics[apic].mpc_apicver >= 0x20) - io_apic_eoi(apic, entry.vector); - else { - /* - * Mechanism by which we clear remoteIRR in this case is by - * changing the trigger mode to edge and back to level. - */ - entry.trigger = 0; - __ioapic_write_entry(apic, pin, TRUE, entry); - entry.trigger = 1; - __ioapic_write_entry(apic, pin, TRUE, entry); - } + __io_apic_eoi(apic, entry.vector, pin); } /* @@ -1750,7 +1845,7 @@ static void end_level_ioapic_irq (unsign { int ioapic; for (ioapic = 0; ioapic < nr_ioapics; ioapic++) - io_apic_eoi(ioapic, i); + io_apic_eoi_vector(ioapic, i); } v = apic_read(APIC_TMR + ((i & ~0x1f) >> 1)); @@ -2622,3 +2717,4 @@ void __init init_ioapic_mappings(void) printk(XENLOG_INFO "IRQ limits: %u GSI, %u MSI/MSI-X\n", nr_irqs_gsi, nr_irqs - nr_irqs_gsi); } + diff -r 0268e7380953 xen/include/asm-x86/io_apic.h --- a/xen/include/asm-x86/io_apic.h Mon Sep 05 15:10:28 2011 +0100 +++ b/xen/include/asm-x86/io_apic.h Mon Sep 12 12:40:18 2011 +0100 @@ -157,11 +157,6 @@ static inline void io_apic_write(unsigne __io_apic_write(apic, reg, value); } -static inline void io_apic_eoi(unsigned int apic, unsigned int vector) -{ - *(IO_APIC_BASE(apic)+16) = vector; -} - /* * Re-write a value: to be used for read-modify-write * cycles where the read already set up the index register. --------------020901090302070601010405 Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel --------------020901090302070601010405-- From xen-devel-bounces@lists.xensource.com Mon Sep 12 05:50:52 2011 Return-path: Envelope-to: www-data@lists.xensource.com Delivery-date: Mon, 12 Sep 2011 05:50:52 -0700 Received: from localhost ([127.0.0.1] helo=lists.colo.xensource.com) by lists.xensource.com with esmtp (Exim 4.43) id 1R35yN-0000Sz-W6; Mon, 12 Sep 2011 05:50:52 -0700 Received: from mail21.messagelabs.com ([85.158.143.35]) by lists.xensource.com with smtp (Exim 4.43) id 1R35xa-0000Ft-Ub for xen-devel@lists.xensource.com; Mon, 12 Sep 2011 05:50:03 -0700 X-Env-Sender: tobias.geiger@vido.info X-Msg-Ref: server-6.tower-21.messagelabs.com!1315831780!37916612!1 X-Originating-IP: [78.47.43.171] X-StarScan-Version: 6.3.6; banners=-,-,- X-VirusChecked: Checked Received: (qmail 10663 invoked from network); 12 Sep 2011 12:49:40 -0000 Received: from www.vido.info (HELO mail.vido.info) (78.47.43.171) by server-6.tower-21.messagelabs.com with SMTP; 12 Sep 2011 12:49:40 -0000 Received: from localhost (ip6-localhost [127.0.0.1]) by mail.vido.info (Postfix) with ESMTP id A00FED348A6 for ; Mon, 12 Sep 2011 14:49:59 +0200 (CEST) X-Virus-Scanned: by amavis at mail.vido.info Received: from mail.vido.info ([127.0.0.1]) by localhost (mail.vido.info [127.0.0.1]) (amavisd-new, port 10024) with LMTP id 9kgLPvf3K8jS for ; Mon, 12 Sep 2011 14:49:52 +0200 (CEST) Received: from pc.localnet (HSI-KBW-085-216-123-237.hsi.kabelbw.de [85.216.123.237]) by mail.vido.info (Postfix) with ESMTPSA id 58809D341C4 for ; Mon, 12 Sep 2011 14:49:52 +0200 (CEST) From: Tobias Geiger Organization: VIDO IT Service To: xen-devel@lists.xensource.com Subject: Re: [Xen-devel] Re: Patches for VGA-Passthrough XEN 4.2 unstable Date: Mon, 12 Sep 2011 14:49:51 +0200 User-Agent: KMail/1.13.7 (Linux/3.1.0-rc2; KDE/4.6.5; x86_64; ; ) References: In-Reply-To: X-Face: xgskrgi{H F4fZpv|5DziL_T'Mwu[q`AwB~jd(QE]|akb9=VF%p5d_iR(ZNP[`l`EMmF*nohYL|:=kM`7<4"> MIME-Version: 1.0 Content-Type: Text/Plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Message-Id: <201109121449.51792.tobias.geiger@vido.info> X-BeenThere: xen-devel@lists.xensource.com X-Mailman-Version: 2.1.5 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xensource.com Errors-To: xen-devel-bounces@lists.xensource.com Am Freitag 09 September 2011, 13:31:19 schrieb Liwei: > Personally I'm having positive experiences with AMD cards. Currently > running two ATI 6870s in a 64-bit Windows 7 DomU. Best thing is, > they're working alright without any patches on xen-unstable. However, > similar to what you have experienced, DomU cannot be restarted in this > configuration. It can be fixed, but I haven't got the time to get down > to it. Can you elaborate a little further what needs to be done to fix this problem? It hits me nearly every day (windows still likes to reboot after nearly every windows update, so...). Best regards Tobias _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel From xen-devel-bounces@lists.xensource.com Mon Sep 12 06:02:44 2011 Return-path: Envelope-to: www-data@lists.xensource.com Delivery-date: Mon, 12 Sep 2011 06:02:44 -0700 Received: from localhost ([127.0.0.1] helo=lists.colo.xensource.com) by lists.xensource.com with esmtp (Exim 4.43) id 1R369q-00015L-LN; Mon, 12 Sep 2011 06:02:43 -0700 Received: from mail182.messagelabs.com ([85.158.139.83]) by lists.xensource.com with esmtp (Exim 4.43) id 1R367O-0000ru-Ee for xen-devel@lists.xensource.com; Mon, 12 Sep 2011 06:00:28 -0700 X-Env-Sender: xieliwei@gmail.com X-Msg-Ref: server-8.tower-182.messagelabs.com!1315832406!18011168!1 X-Originating-IP: [209.85.213.171] X-StarScan-Version: 6.3.6; banners=-,-,- X-VirusChecked: Checked Received: (qmail 15104 invoked from network); 12 Sep 2011 13:00:07 -0000 Received: from mail-yx0-f171.google.com (HELO mail-yx0-f171.google.com) (209.85.213.171) by server-8.tower-182.messagelabs.com with RC4-SHA encrypted SMTP; 12 Sep 2011 13:00:07 -0000 Received: by yxt3 with SMTP id 3so181215yxt.30 for ; Mon, 12 Sep 2011 06:00:06 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=R1+HRh1PLvKLL7IaGx8vB4YvZwiBMOTBM+CC8knNdvc=; b=NdxXSHWpcSUS+nbSdgrbpVLZSGsdr8Q6PX3+4bBlze2WhQPqKUEp7RMfSy86MY6nrM uBhPDnqDlaS9rbQZ/sAIP0iWXMJam8RJHfpLXZDF+piliCGU7N5nuVVreKbQFRAQQ3KE h0WI0OBX1mLp9/u7Cn9w+F/id0jIMyUFrgPKA= Received: by 10.101.136.4 with SMTP id o4mr2703326ann.157.1315832406110; Mon, 12 Sep 2011 06:00:06 -0700 (PDT) MIME-Version: 1.0 Received: by 10.100.191.1 with HTTP; Mon, 12 Sep 2011 05:59:46 -0700 (PDT) In-Reply-To: <201109121450.39331.tobias.geiger@vido.info> References: <201109121450.39331.tobias.geiger@vido.info> From: Liwei Date: Mon, 12 Sep 2011 20:59:46 +0800 Message-ID: Subject: Re: [Xen-devel] Re: Patches for VGA-Passthrough XEN 4.2 unstable To: Tobias Geiger Content-Type: text/plain; charset=ISO-8859-1 Cc: xen-devel X-BeenThere: xen-devel@lists.xensource.com X-Mailman-Version: 2.1.5 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xensource.com Errors-To: xen-devel-bounces@lists.xensource.com On 12 September 2011 20:50, Tobias Geiger wrote: > Am Freitag 09 September 2011, 13:31:19 schrieb Liwei: >> Personally I'm having positive experiences with AMD cards. Currently >> running two ATI 6870s in a 64-bit Windows 7 DomU. Best thing is, >> they're working alright without any patches on xen-unstable. However, >> similar to what you have experienced, DomU cannot be restarted in this >> configuration. It can be fixed, but I haven't got the time to get down >> to it. > > Can you elaborate a little further what needs to be done to fix this problem? > > It hits me nearly every day (windows still likes to reboot after nearly every > windows update, so...). > > Best regards > Tobias > Actually I'm living with it currently. Disabled automatic reboots and manually reboot the system at a convenient time. It'll be sweet to fix it, but I just don't have the time now. I do know that reboots with VGA/PCI passthrough worked at one point in the past with older kernel and xen versions, but something in the new versions have broken that. So if you really need to and have the time, try testing older (I think it was sometime in March or April) versions. _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel From xen-devel-bounces@lists.xensource.com Mon Sep 12 06:15:35 2011 Return-path: Envelope-to: www-data@lists.xensource.com Delivery-date: Mon, 12 Sep 2011 06:15:35 -0700 Received: from localhost ([127.0.0.1] helo=lists.colo.xensource.com) by lists.xensource.com with esmtp (Exim 4.43) id 1R36MJ-0001cY-Fp; Mon, 12 Sep 2011 06:15:35 -0700 Received: from mail21.messagelabs.com ([85.158.143.35]) by lists.xensource.com with esmtp (Exim 4.43) id 1R36Le-0001QD-7C for xen-devel@lists.xensource.com; Mon, 12 Sep 2011 06:14:57 -0700 X-Env-Sender: wongthai@gmail.com X-Msg-Ref: server-4.tower-21.messagelabs.com!1315833255!59896341!1 X-Originating-IP: [216.139.236.26] X-StarScan-Version: 6.3.6; banners=-,-,- X-VirusChecked: Checked Received: (qmail 2545 invoked from network); 12 Sep 2011 13:14:16 -0000 Received: from sam.nabble.com (HELO sam.nabble.com) (216.139.236.26) by server-4.tower-21.messagelabs.com with AES256-SHA encrypted SMTP; 12 Sep 2011 13:14:16 -0000 Received: from [192.168.236.26] (helo=sam.nabble.com) by sam.nabble.com with esmtp (Exim 4.72) (envelope-from ) id 1R36LZ-00089s-B0 for xen-devel@lists.xensource.com; Mon, 12 Sep 2011 06:14:49 -0700 Date: Mon, 12 Sep 2011 06:14:49 -0700 (PDT) From: Winai Wongthai To: xen-devel@lists.xensource.com Message-ID: <1315833289278-4794145.post@n5.nabble.com> In-Reply-To: <123657B31765C64CB9BC722F4EE9C3DA16E9D8B1@ORSMSX101.amr.corp.intel.com> References: <1314744792065-4752119.post@n5.nabble.com> <123657B31765C64CB9BC722F4EE9C3DA16E9D8B1@ORSMSX101.amr.corp.intel.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Subject: [Xen-devel] RE: Questions about the GVTPM framework X-BeenThere: xen-devel@lists.xensource.com X-Mailman-Version: 2.1.5 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xensource.com Errors-To: xen-devel-bounces@lists.xensource.com Hi , Thank you very much for your reply, I also would like to ask a question about the vTPM in this paper(vTPM: Virtualizing the Trusted Platform Module , http://domino.research.ibm.com/library/cyberdig.nsf/papers/A0163FFF5B1A61FE85257178004EEE39/$File/rc23879.pdf). Is there an open-source and concrete implementation of its 'vTPM instance migration'? Best Regards, Winai Wongthai -- View this message in context: http://xen.1045712.n5.nabble.com/Questions-about-the-GVTPM-framework-tp4752119p4794145.html Sent from the Xen - Dev mailing list archive at Nabble.com. _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel From xen-devel-bounces@lists.xensource.com Mon Sep 12 06:32:47 2011 Return-path: Envelope-to: www-data@lists.xensource.com Delivery-date: Mon, 12 Sep 2011 06:32:47 -0700 Received: from localhost ([127.0.0.1] helo=lists.colo.xensource.com) by lists.xensource.com with esmtp (Exim 4.43) id 1R36cx-0002HR-Gg; Mon, 12 Sep 2011 06:32:47 -0700 Received: from mail21.messagelabs.com ([85.158.143.35]) by lists.xensource.com with smtp (Exim 4.43) id 1R36cH-00025a-AF for xen-devel@lists.xensource.com; Mon, 12 Sep 2011 06:32:06 -0700 X-Env-Sender: muehlenhoff@univention.de X-Msg-Ref: server-8.tower-21.messagelabs.com!1315834307!58653622!1 X-Originating-IP: [82.198.197.8] X-StarScan-Version: 6.3.6; banners=-,-,- X-VirusChecked: Checked Received: (qmail 1376 invoked from network); 12 Sep 2011 13:31:47 -0000 Received: from mail.univention.de (HELO mail.univention.de) (82.198.197.8) by server-8.tower-21.messagelabs.com with SMTP; 12 Sep 2011 13:31:47 -0000 Received: from localhost (localhost [127.0.0.1]) by slugis.knut.univention.de (Postfix) with ESMTP id DAE5FA63101 for ; Mon, 12 Sep 2011 15:31:59 +0200 (CEST) Received: from localhost (localhost [127.0.0.1]) by slugis.knut.univention.de (Postfix) with ESMTP id CE79BA63105 for ; Mon, 12 Sep 2011 15:31:59 +0200 (CEST) X-Virus-Scanned: by amavisd-new-2.6.1 (20080629) (Debian) at knut.univention.de Received: from mail.univention.de ([127.0.0.1]) by localhost (slugis.knut.univention.de [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yuxfVmfhHFrc for ; Mon, 12 Sep 2011 15:31:59 +0200 (CEST) Received: from vurm.localnet (vurm.knut.univention.de [192.168.0.132]) by slugis.knut.univention.de (Postfix) with ESMTPSA id 445CCA63101 for ; Mon, 12 Sep 2011 15:31:59 +0200 (CEST) From: Moritz =?iso-8859-1?q?M=FChlenhoff?= To: xen-devel@lists.xensource.com Subject: Re: [Xen-devel] Signed GPLPV drivers available for download Date: Mon, 12 Sep 2011 15:31:58 +0200 User-Agent: KMail/1.13.5 (Linux/2.6.32-ucs44-amd64; KDE/4.4.5; x86_64; ; ) References: <201109090950.05043.muehlenhoff@univention.de> In-Reply-To: <201109090950.05043.muehlenhoff@univention.de> MIME-Version: 1.0 Content-Type: Text/Plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Message-Id: <201109121531.58987.muehlenhoff@univention.de> X-BeenThere: xen-devel@lists.xensource.com X-Mailman-Version: 2.1.5 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xensource.com Errors-To: xen-devel-bounces@lists.xensource.com Moritz M=FChlenhoff wrote: > The drivers are available from > http://apt.univention.de/download/addons/gplpv- drivers/ and should be > compatible with any Xen installation. >=20 > The installation is detailed in > http://wiki.univention.de/index.php?title=3DInstalling-signed-GPLPV-drive= rs >=20 > So far only new installation of the GPLPV drivers have been tested.=20 =46YI; we've now also tested/documented the upgrade path from the test-sign= ed drivers from meadowcourt.org to the SPC-signed drivers. The installation docs have been amended: http://wiki.univention.de/index.php?title=3DInstalling-signed-GPLPV-drivers Cheers, Moritz =2D-=20 Moritz M=FChlenhoff muehlenhoff@univention.de Open Source Software Engineer and Consultant Univention GmbH Linux for Your Business fon: +49 421 22 232- 0 Mary-Somerville-Str.1 28359 Bremen fax: +49 421 22 232-99 http://www.univention.de _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel From xen-devel-bounces@lists.xensource.com Mon Sep 12 06:58:59 2011 Return-path: Envelope-to: www-data@lists.xensource.com Delivery-date: Mon, 12 Sep 2011 06:58:59 -0700 Received: from localhost ([127.0.0.1] helo=lists.colo.xensource.com) by lists.xensource.com with esmtp (Exim 4.43) id 1R372H-0003AN-8I; Mon, 12 Sep 2011 06:58:57 -0700 Received: from mail21.messagelabs.com ([85.158.143.35]) by lists.xensource.com with esmtp (Exim 4.43) id 1R370i-0002xV-Je for xen-devel@lists.xensource.com; Mon, 12 Sep 2011 06:57:21 -0700 X-Env-Sender: tim@xen.org X-Msg-Ref: server-11.tower-21.messagelabs.com!1315835821!42274534!1 X-Originating-IP: [81.29.64.94] X-StarScan-Version: 6.3.6; banners=-,-,- X-VirusChecked: Checked Received: (qmail 15057 invoked from network); 12 Sep 2011 13:57:01 -0000 Received: from ocelot.phlegethon.org (HELO mail.phlegethon.org) (81.29.64.94) by server-11.tower-21.messagelabs.com with DHE-RSA-AES256-SHA encrypted SMTP; 12 Sep 2011 13:57:01 -0000 Received: from tjd by mail.phlegethon.org with local (Exim 4.67 (FreeBSD)) (envelope-from ) id 1R370f-000Lx7-2o; Mon, 12 Sep 2011 13:57:17 +0000 Date: Mon, 12 Sep 2011 14:57:17 +0100 From: Tim Deegan To: Olaf Hering Subject: Re: [Xen-devel] [PATCH 0 of 2] v2: memshare/xenpaging/xen-access fixes for xen-unstable Message-ID: <20110912135717.GC79171@ocelot.phlegethon.org> References: Mime-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.4.2.1i Cc: xen-devel@lists.xensource.com X-BeenThere: xen-devel@lists.xensource.com X-Mailman-Version: 2.1.5 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xensource.com Errors-To: xen-devel-bounces@lists.xensource.com At 11:57 +0200 on 08 Sep (1315483028), Olaf Hering wrote: > > The following two patches allow the parallel use of memsharing, xenpaging and > xen-access by using an independent ring buffer for each feature. > > Please review. As I said, the Xen side looks fine but I'd like the opinion of the tools maintainers about the API changes before I apply anything. Maybe this is something that can happen at the hackathon. Cheers, Tim. _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel From xen-devel-bounces@lists.xensource.com Mon Sep 12 08:03:08 2011 Return-path: Envelope-to: www-data@lists.xensource.com Delivery-date: Mon, 12 Sep 2011 08:03:08 -0700 Received: from localhost ([127.0.0.1] helo=lists.colo.xensource.com) by lists.xensource.com with esmtp (Exim 4.43) id 1R382N-0004gJ-5Y; Mon, 12 Sep 2011 08:03:07 -0700 Received: from mail27.messagelabs.com ([193.109.254.147]) by lists.xensource.com with esmtp (Exim 4.43) id 1R37z7-0004Qc-ME for xen-devel@lists.xensource.com; Mon, 12 Sep 2011 08:00:15 -0700 X-Env-Sender: konrad@oracle.com X-Msg-Ref: server-5.tower-27.messagelabs.com!1315839562!44537145!1 X-Originating-IP: [148.87.113.117] X-StarScan-Version: 6.3.6; banners=-,-,- X-VirusChecked: Checked Received: (qmail 7755 invoked from network); 12 Sep 2011 14:59:24 -0000 Received: from rcsinet15.oracle.com (HELO rcsinet15.oracle.com) (148.87.113.117) by server-5.tower-27.messagelabs.com with DHE-RSA-AES256-SHA encrypted SMTP; 12 Sep 2011 14:59:24 -0000 Received: from acsinet22.oracle.com (acsinet22.oracle.com [141.146.126.238]) by rcsinet15.oracle.com (Switch-3.4.4/Switch-3.4.4) with ESMTP id p8CEwv49016990 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Mon, 12 Sep 2011 14:58:59 GMT Received: from acsmt358.oracle.com (acsmt358.oracle.com [141.146.40.158]) by acsinet22.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id p8CEwuWL000255 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 12 Sep 2011 14:58:57 GMT Received: from abhmt108.oracle.com (abhmt108.oracle.com [141.146.116.60]) by acsmt358.oracle.com (8.12.11.20060308/8.12.11) with ESMTP id p8CEwoYL012731; Mon, 12 Sep 2011 09:58:51 -0500 Received: from oracle.com (/209.6.55.207) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Mon, 12 Sep 2011 07:58:50 -0700 Received: by oracle.com (Postfix, from userid 1000) id 146AF1334; Mon, 12 Sep 2011 10:58:44 -0400 (EDT) Date: Mon, 12 Sep 2011 10:58:43 -0400 From: Konrad Rzeszutek Wilk To: James Harper Subject: Re: [Xen-devel] git.kernel.org Message-ID: <20110912145843.GB15778@oracle.com> References: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.21 (2010-09-15) X-Source-IP: acsinet22.oracle.com [141.146.126.238] X-Auth-Type: Internal IP X-CT-RefId: str=0001.0A090202.4E6E1E33.00AE:SCFMA922111,ss=1,re=-4.000,fgs=0 Cc: xen-devel@lists.xensource.com X-BeenThere: xen-devel@lists.xensource.com X-Mailman-Version: 2.1.5 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xensource.com Errors-To: xen-devel-bounces@lists.xensource.com On Mon, Sep 12, 2011 at 12:32:13PM +1000, James Harper wrote: > I had a search of the list and can't find anything... where should we be > pulling our linux pvops kernels from while kernel.org sorts itself out > after the recent security issues? git.kernel.org doesn't resolve? github. Search for torvalds. If you want a specific branch, you can also look at http://oss.oracle.com/git/kwilk/xen.git/?p=kwilk/xen.git;a=summary _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel From xen-devel-bounces@lists.xensource.com Mon Sep 12 08:05:26 2011 Return-path: Envelope-to: www-data@lists.xensource.com Delivery-date: Mon, 12 Sep 2011 08:05:26 -0700 Received: from localhost ([127.0.0.1] helo=lists.colo.xensource.com) by lists.xensource.com with esmtp (Exim 4.43) id 1R384c-00056M-LF; Mon, 12 Sep 2011 08:05:26 -0700 Received: from mail216.messagelabs.com ([85.158.143.99]) by lists.xensource.com with esmtp (Exim 4.43) id 1R3808-0004Rl-6t for xen-devel@lists.xensource.com; Mon, 12 Sep 2011 08:01:04 -0700 X-Env-Sender: konrad@oracle.com X-Msg-Ref: server-15.tower-216.messagelabs.com!1315839403!17534793!1 X-Originating-IP: [141.146.126.227] X-StarScan-Version: 6.3.6; banners=-,-,- X-VirusChecked: Checked Received: (qmail 18203 invoked from network); 12 Sep 2011 14:56:44 -0000 Received: from acsinet15.oracle.com (HELO acsinet15.oracle.com) (141.146.126.227) by server-15.tower-216.messagelabs.com with DHE-RSA-AES256-SHA encrypted SMTP; 12 Sep 2011 14:56:44 -0000 Received: from rtcsinet21.oracle.com (rtcsinet21.oracle.com [66.248.204.29]) by acsinet15.oracle.com (Switch-3.4.4/Switch-3.4.4) with ESMTP id p8CEueuQ013166 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Mon, 12 Sep 2011 14:56:42 GMT Received: from acsmt357.oracle.com (acsmt357.oracle.com [141.146.40.157]) by rtcsinet21.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id p8CEucsO000287 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 12 Sep 2011 14:56:39 GMT Received: from abhmt105.oracle.com (abhmt105.oracle.com [141.146.116.57]) by acsmt357.oracle.com (8.12.11.20060308/8.12.11) with ESMTP id p8CEuXAQ003725; Mon, 12 Sep 2011 09:56:33 -0500 Received: from oracle.com (/209.6.55.207) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Mon, 12 Sep 2011 07:56:33 -0700 Received: by oracle.com (Postfix, from userid 1000) id 96E7B1334; Mon, 12 Sep 2011 10:56:26 -0400 (EDT) Date: Mon, 12 Sep 2011 10:56:26 -0400 From: Konrad Rzeszutek Wilk To: Hans de Bruin Subject: Re: [Xen-devel] Xen PCI Pass-through: 0xbf701000 is using VM_IO, but it is 0xfffffffffffff000! Message-ID: <20110912145626.GA15778@oracle.com> References: <4E6CBC76.1030303@xmsnet.nl> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <4E6CBC76.1030303@xmsnet.nl> User-Agent: Mutt/1.5.21 (2010-09-15) X-Source-IP: rtcsinet21.oracle.com [66.248.204.29] X-CT-RefId: str=0001.0A020202.4E6E1DAA.021D,ss=1,re=0.000,fgs=0 Cc: xen-devel@lists.xensource.com X-BeenThere: xen-devel@lists.xensource.com X-Mailman-Version: 2.1.5 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xensource.com Errors-To: xen-devel-bounces@lists.xensource.com On Sun, Sep 11, 2011 at 03:49:42PM +0200, Hans de Bruin wrote: > Hi, > > I get a warning in the domU kernels when I pass-through the > ehcu/uhci devices. The usb-ports seem to work. I can use usb-sticks > and a sundtek DVB-C stick. A microsoft usb-mouse is not recognized. > Can I ignore the warning or do I have some serious issue/misconfiguration? You can ignore it. There is a patch for 3.2 to remove this. _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel From xen-devel-bounces@lists.xensource.com Mon Sep 12 08:06:57 2011 Return-path: Envelope-to: www-data@lists.xensource.com Delivery-date: Mon, 12 Sep 2011 08:06:57 -0700 Received: from localhost ([127.0.0.1] helo=lists.colo.xensource.com) by lists.xensource.com with esmtp (Exim 4.43) id 1R3865-0005Vh-5l; Mon, 12 Sep 2011 08:06:57 -0700 Received: from mail27.messagelabs.com ([193.109.254.147]) by lists.xensource.com with esmtp (Exim 4.43) id 1R385b-0005JK-20 for xen-devel@lists.xensource.com; Mon, 12 Sep 2011 08:06:27 -0700 X-Env-Sender: konrad@oracle.com X-Msg-Ref: server-9.tower-27.messagelabs.com!1315839967!44201010!1 X-Originating-IP: [141.146.126.227] X-StarScan-Version: 6.3.6; banners=-,-,- X-VirusChecked: Checked Received: (qmail 15470 invoked from network); 12 Sep 2011 15:06:08 -0000 Received: from acsinet15.oracle.com (HELO acsinet15.oracle.com) (141.146.126.227) by server-9.tower-27.messagelabs.com with DHE-RSA-AES256-SHA encrypted SMTP; 12 Sep 2011 15:06:08 -0000 Received: from rtcsinet21.oracle.com (rtcsinet21.oracle.com [66.248.204.29]) by acsinet15.oracle.com (Switch-3.4.4/Switch-3.4.4) with ESMTP id p8CF6JYE005090 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Mon, 12 Sep 2011 15:06:21 GMT Received: from acsmt357.oracle.com (acsmt357.oracle.com [141.146.40.157]) by rtcsinet21.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id p8CF6Ifk024650 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 12 Sep 2011 15:06:19 GMT Received: from abhmt105.oracle.com (abhmt105.oracle.com [141.146.116.57]) by acsmt357.oracle.com (8.12.11.20060308/8.12.11) with ESMTP id p8CF6Duu013073; Mon, 12 Sep 2011 10:06:13 -0500 Received: from oracle.com (/209.6.55.207) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Mon, 12 Sep 2011 08:06:13 -0700 Received: by oracle.com (Postfix, from userid 1000) id A5BFB1334; Mon, 12 Sep 2011 11:06:06 -0400 (EDT) Date: Mon, 12 Sep 2011 11:06:06 -0400 From: Konrad Rzeszutek Wilk To: Sven =?iso-8859-1?Q?K=F6hler?= Subject: Re: [Xen-devel] 3.0.4 and 3.1-rc4 based dom0 won't boot with acpi=off Message-ID: <20110912150606.GC15778@oracle.com> References: <20110911002807.GA9989@oracle.com> <4E6C0473.8090905@gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline In-Reply-To: <4E6C0473.8090905@gmail.com> User-Agent: Mutt/1.5.21 (2010-09-15) Content-Transfer-Encoding: quoted-printable X-Source-IP: rtcsinet21.oracle.com [66.248.204.29] X-CT-RefId: str=0001.0A090207.4E6E1FED.0170,ss=1,re=3.899,fgs=0 Cc: xen-devel@lists.xensource.com X-BeenThere: xen-devel@lists.xensource.com X-Mailman-Version: 2.1.5 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xensource.com Errors-To: xen-devel-bounces@lists.xensource.com On Sun, Sep 11, 2011 at 02:44:35AM +0200, Sven K=F6hler wrote: > Am 11.09.2011 02:28, schrieb Konrad Rzeszutek Wilk: > > On Sun, Sep 11, 2011 at 12:43:18AM +0200, Sven K=F6hler wrote: > >> Hi, > >> > >> when using acpi=3Doff in the kernel or xen command line, the system = won't > >> boot. On real hardware, I saw a few interrupt related warnings from = the > >> usb drivers. The system then seemed to lock up when trying to do I/O= via > >> AHCI. Same in virtualbox. System won't come up. > >=20 > > Not surprised. Without the ACPI we can't find parse the interrupt tab= le, > > so you don't get any interrupts. >=20 > Thanks for explaining. Now what about the future? Will there be some > solution for the acpi=3Doff case? No. >=20 > I'm a bit confused, since your words don't sound like there is a way to > boot with acpi=3Doff. But other dom0 kernels actually boot with acpi=3D= off. Sure. > So after all, some other way for setting up interrupts seems to exist. The older kernels (XenOLinux) made it possible by copying a lot of the generic code in its own and making it work. That is not possible with the upstream kernel. Well, maybe it is possible, but I am not sure if it is worth the effort. >=20 > > This is result of the reboot issue you have been seeing with your box= ? >=20 > Yes. >=20 > > You might want to try some parameters on the Xen line to alter how > > it is suppose to reboot. > >=20 > > /* > > * reboot=3Db[ios] | t[riple] | k[bd] | n[o] [, [w]arm | [c]old] >=20 > Thanks for the list. > I guess, both reboot=3Dbios and reboot=3Db is accepted? > BTW: "no" is missing in the list below. acpi is missing in the list > above. And actually what's the source for list? Xen hypervisor source. I just did a quick search for 'reboot=3D' > (I never find any documentation about the hypervisor options, which is > pretty frustrating sometimes) >=20 > > * warm Don't set the cold reboot flag > > * cold Set the cold reboot flag > > * bios Reboot by jumping through the BIOS (only for X86_32) > > * triple Force a triple fault (init) > > * kbd Use the keyboard controller. cold reset (default) > > * acpi Use the RESET_REG in the FADT > > */ >=20 > So in fact, xen is doing the reboot, and not the dom0 kernel, right? Yes. Dom0 triggers it though (by invoking an hypercall that tells Xen to reboot/shutdown the machine). > (Some people have claimed otherwise) >=20 > Could you imagine to adapt xen's reboot code to the one of linux 3.0 > (which was tweaked quite a lot for maximum compatibility) I can imagine it.. but without any ideas of why your machine is not reboo= ting it is a bit .. difficult. You could also try on the Xen hypervisor line (Ctlr-A three times) try th= e 'R' and see if it does anything. >=20 >=20 >=20 > Regards, > Sven >=20 _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel From xen-devel-bounces@lists.xensource.com Mon Sep 12 09:09:59 2011 Return-path: Envelope-to: www-data@lists.xensource.com Delivery-date: Mon, 12 Sep 2011 09:09:59 -0700 Received: from localhost ([127.0.0.1] helo=lists.colo.xensource.com) by lists.xensource.com with esmtp (Exim 4.43) id 1R3954-0007gA-PC; Mon, 12 Sep 2011 09:09:58 -0700 Received: from mail174.messagelabs.com ([85.158.138.51]) by lists.xensource.com with smtp (Exim 4.43) id 1R392F-0007RW-3n for xen-devel@lists.xensource.com; Mon, 12 Sep 2011 09:07:11 -0700 X-Env-Sender: caker@theshore.net X-Msg-Ref: server-3.tower-174.messagelabs.com!1315843618!25089391!1 X-Originating-IP: [67.18.92.50] X-StarScan-Version: 6.3.6; banners=-,-,- X-VirusChecked: Checked Received: (qmail 10021 invoked from network); 12 Sep 2011 16:06:59 -0000 Received: from ns.theshore.net (HELO www.theshore.net) (67.18.92.50) by server-3.tower-174.messagelabs.com with SMTP; 12 Sep 2011 16:06:59 -0000 Received: from beefcake.linlan (173-161-199-49-Philadelphia.hfc.comcastbusiness.net [173.161.199.49]) by www.theshore.net (8.13.6/8.9.1) with ESMTP id p8CG6fej018453; Mon, 12 Sep 2011 12:06:41 -0400 Message-ID: <4E6E2E11.1030602@theshore.net> Date: Mon, 12 Sep 2011 12:06:41 -0400 From: "Christopher S. Aker" User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.6; en-US; rv:1.9.2.22) Gecko/20110902 Lightning/1.0b2 Thunderbird/3.1.14 MIME-Version: 1.0 To: Konrad Rzeszutek Wilk Subject: Re: [Xen-devel] Re: kernel BUG at mm/swapfile.c:2527! [was 3.0.0 Xen pv guest - BUG: Unable to handle] References: <9CAEB881-07FE-437C-8A6B-DB7B690CEABE@linode.com> <4E5BA49D.5060800@theshore.net> <20110829150734.GB24825@dumpdata.com> <1314704744.28989.2.camel@zakaz.uk.xensource.com> <4E5E9CDB.3070706@theshore.net> <20110906171319.GB29839@dumpdata.com> In-Reply-To: <20110906171319.GB29839@dumpdata.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: Jeremy Fitzhardinge , "xen-devel@lists.xensource.com" , Ian Campbell , LKML X-BeenThere: xen-devel@lists.xensource.com X-Mailman-Version: 2.1.5 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xensource.com Errors-To: xen-devel-bounces@lists.xensource.com On 9/6/11 1:13 PM, Konrad Rzeszutek Wilk wrote: > So .. just to confirm this b/c you have been seeing this for some time. Did you > see this with a 2.6.32 DomU? Asking b/c in 2.6.37 we removed some code: 2.6.32 was NOT affected and our problems began right around 2.6.37. This looks promising! > It would really neat if the issue you have been hitting was exactly this > and just having you revert the ef691947d8a3d479e67652312783aedcf629320a > would fix it. Reverted, built, deployed, and set as default. We shall see! Thanks, -Chris _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel From xen-devel-bounces@lists.xensource.com Mon Sep 12 09:13:31 2011 Return-path: Envelope-to: www-data@lists.xensource.com Delivery-date: Mon, 12 Sep 2011 09:13:31 -0700 Received: from localhost ([127.0.0.1] helo=lists.colo.xensource.com) by lists.xensource.com with esmtp (Exim 4.43) id 1R398U-00085y-G9; Mon, 12 Sep 2011 09:13:30 -0700 Received: from mail216.messagelabs.com ([85.158.143.99]) by lists.xensource.com with esmtp (Exim 4.43) id 1R396v-0007sN-3b for xen-devel@lists.xensource.com; Mon, 12 Sep 2011 09:11:55 -0700 X-Env-Sender: konrad@oracle.com X-Msg-Ref: server-13.tower-216.messagelabs.com!1315843908!18008467!1 X-Originating-IP: [141.146.126.227] X-StarScan-Version: 6.3.6; banners=-,-,- X-VirusChecked: Checked Received: (qmail 17772 invoked from network); 12 Sep 2011 16:11:49 -0000 Received: from acsinet15.oracle.com (HELO acsinet15.oracle.com) (141.146.126.227) by server-13.tower-216.messagelabs.com with DHE-RSA-AES256-SHA encrypted SMTP; 12 Sep 2011 16:11:49 -0000 Received: from rtcsinet22.oracle.com (rtcsinet22.oracle.com [66.248.204.30]) by acsinet15.oracle.com (Switch-3.4.4/Switch-3.4.4) with ESMTP id p8CGBfrF011333 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Mon, 12 Sep 2011 16:11:43 GMT Received: from acsmt357.oracle.com (acsmt357.oracle.com [141.146.40.157]) by rtcsinet22.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id p8CGBdlM005186 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 12 Sep 2011 16:11:40 GMT Received: from abhmt105.oracle.com (abhmt105.oracle.com [141.146.116.57]) by acsmt357.oracle.com (8.12.11.20060308/8.12.11) with ESMTP id p8CGBYIf004246; Mon, 12 Sep 2011 11:11:34 -0500 Received: from oracle.com (/209.6.55.207) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Mon, 12 Sep 2011 09:11:34 -0700 Received: by oracle.com (Postfix, from userid 1000) id 99B3D1334; Mon, 12 Sep 2011 12:11:27 -0400 (EDT) Date: Mon, 12 Sep 2011 12:11:27 -0400 From: Konrad Rzeszutek Wilk To: "Christopher S. Aker" Subject: Re: [Xen-devel] Re: kernel BUG at mm/swapfile.c:2527! [was 3.0.0 Xen pv guest - BUG: Unable to handle] Message-ID: <20110912161127.GB16100@oracle.com> References: <9CAEB881-07FE-437C-8A6B-DB7B690CEABE@linode.com> <4E5BA49D.5060800@theshore.net> <20110829150734.GB24825@dumpdata.com> <1314704744.28989.2.camel@zakaz.uk.xensource.com> <4E5E9CDB.3070706@theshore.net> <20110906171319.GB29839@dumpdata.com> <4E6E2E11.1030602@theshore.net> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <4E6E2E11.1030602@theshore.net> User-Agent: Mutt/1.5.21 (2010-09-15) X-Source-IP: rtcsinet22.oracle.com [66.248.204.30] X-CT-RefId: str=0001.0A02020A.4E6E2F40.0057,ss=1,re=0.000,fgs=0 Cc: Jeremy Fitzhardinge , "xen-devel@lists.xensource.com" , Ian Campbell , LKML X-BeenThere: xen-devel@lists.xensource.com X-Mailman-Version: 2.1.5 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xensource.com Errors-To: xen-devel-bounces@lists.xensource.com On Mon, Sep 12, 2011 at 12:06:41PM -0400, Christopher S. Aker wrote: > On 9/6/11 1:13 PM, Konrad Rzeszutek Wilk wrote: > >So .. just to confirm this b/c you have been seeing this for some time. Did you > >see this with a 2.6.32 DomU? Asking b/c in 2.6.37 we removed some code: > > 2.6.32 was NOT affected and our problems began right around 2.6.37. > This looks promising! > > >It would really neat if the issue you have been hitting was exactly this > >and just having you revert the ef691947d8a3d479e67652312783aedcf629320a > >would fix it. > > Reverted, built, deployed, and set as default. We shall see! _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel From xen-devel-bounces@lists.xensource.com Mon Sep 12 09:49:13 2011 Return-path: Envelope-to: www-data@lists.xensource.com Delivery-date: Mon, 12 Sep 2011 09:49:13 -0700 Received: from localhost ([127.0.0.1] helo=lists.colo.xensource.com) by lists.xensource.com with esmtp (Exim 4.43) id 1R39h2-0000mI-UP; Mon, 12 Sep 2011 09:49:12 -0700 Received: from mail27.messagelabs.com ([193.109.254.147]) by lists.xensource.com with esmtp (Exim 4.43) id 1R39gF-0000ZJ-Ov for xen-devel@lists.xensource.com; Mon, 12 Sep 2011 09:48:24 -0700 X-Env-Sender: konrad@oracle.com X-Msg-Ref: server-4.tower-27.messagelabs.com!1315846082!39943423!1 X-Originating-IP: [141.146.126.227] X-StarScan-Version: 6.3.6; banners=-,-,- X-VirusChecked: Checked Received: (qmail 6209 invoked from network); 12 Sep 2011 16:48:03 -0000 Received: from acsinet15.oracle.com (HELO acsinet15.oracle.com) (141.146.126.227) by server-4.tower-27.messagelabs.com with DHE-RSA-AES256-SHA encrypted SMTP; 12 Sep 2011 16:48:03 -0000 Received: from rtcsinet21.oracle.com (rtcsinet21.oracle.com [66.248.204.29]) by acsinet15.oracle.com (Switch-3.4.4/Switch-3.4.4) with ESMTP id p8CGmAXi027045 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Mon, 12 Sep 2011 16:48:12 GMT Received: from acsmt357.oracle.com (acsmt357.oracle.com [141.146.40.157]) by rtcsinet21.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id p8CGm9hu026670 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 12 Sep 2011 16:48:10 GMT Received: from abhmt114.oracle.com (abhmt114.oracle.com [141.146.116.66]) by acsmt357.oracle.com (8.12.11.20060308/8.12.11) with ESMTP id p8CGm3s6000384; Mon, 12 Sep 2011 11:48:03 -0500 Received: from oracle.com (/209.6.55.207) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Mon, 12 Sep 2011 09:48:03 -0700 Received: by oracle.com (Postfix, from userid 1000) id E03771334; Mon, 12 Sep 2011 12:47:56 -0400 (EDT) Date: Mon, 12 Sep 2011 12:47:56 -0400 From: Konrad Rzeszutek Wilk To: Andreas Olsowski Subject: Re: [Xen-devel] xen/stable-2.6.32.x xen-4.1.1 live migration fails with kernels 2.6.39, 3.0.3 and 3.1-rc2.. between different physical machines and CPUs. Message-ID: <20110912164756.GA31301@oracle.com> References: <4E55F682.8060405@leuphana.de> <20110826150054.GA1793@dumpdata.com> <4E57D745.2080701@leuphana.de> <20110829194911.GC16530@dumpdata.com> <4E5E320A.60401@leuphana.de> <20110907135046.GD32190@dumpdata.com> <20110908173212.GA17026@dumpdata.com> <20110908181227.GB19078@dumpdata.com> <20110908195031.GA21186@dumpdata.com> <4E69AB53.5010702@leuphana.de> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <4E69AB53.5010702@leuphana.de> User-Agent: Mutt/1.5.21 (2010-09-15) X-Source-IP: rtcsinet21.oracle.com [66.248.204.29] X-CT-RefId: str=0001.0A090206.4E6E37CD.0035,ss=1,re=0.000,fgs=0 Cc: "xen-devel@lists.xensource.com" X-BeenThere: xen-devel@lists.xensource.com X-Mailman-Version: 2.1.5 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xensource.com Errors-To: xen-devel-bounces@lists.xensource.com > This does not neccessarily have sth to todo with the amount of memory. > I do see this on hosts where both have the same amount of ram but > are a different hardware platform. Let me modify the subject a bit to reflect this. > >I think the problem you are running into is that you are migrating between > >different CPU families... Is the /proc/cpuinfo drastically different between > >the boxes? > diff: > < model : 26 > < model name : Intel(R) Xeon(R) CPU E5520 @ 2.27GHz > < stepping : 5 > < cpu MHz : 2261.074 > < cache size : 8192 KB > --- > > model : 44 > > model name : Intel(R) Xeon(R) CPU E5640 @ 2.67GHz > > stepping : 2 > > cpu MHz : 2660.050 > > cache size : 12288 KB > 13,14c13,14 > < flags : fpu de tsc msr pae mce cx8 apic sep mtrr mca cmov pat > clflush acpi mmx fxsr sse sse2 ss ht syscall nx lm constant_tsc > rep_good nonstop_tsc aperfmperf pni est ssse3 cx16 sse4_1 sse4_2 > popcnt hypervisor lahf_lm ida > < bogomips : 4522.14 > --- > > flags : fpu de tsc msr pae mce cx8 apic sep mtrr mca cmov pat > clflush acpi mmx fxsr sse sse2 ss ht syscall lm constant_tsc > rep_good nonstop_tsc aperfmperf pni pclmulqdq est ssse3 cx16 sse4_1 > sse4_2 popcnt aes hypervisor lahf_lm ida arat > > bogomips : 5320.10 > > diffrent flags are: nx and aes On the Linux command line, try using 'noexec=off' - that should take care of the 'nx' bit. The aes.. the 'xl' command has a bit easier syntax for setting the CPUID: cpuid='host,family=15,model=26,stepping=5,aes=s' That ought to take care of that. I don't really understand how the old 'cpuid=['...']' syntax worked (the one that 'xm' used). It looks quite arcane - so I think doing some Google search is the only way to figure that out. But co-workers of mine remind me that CPUID instructions is trapped by the hypervisor (both HVM and PV - PV via a special opcode - look in arch/x86/include/asm/xen/interface.h for details) for the kernel _only_. There is no such guarantee for applications. Meaning that if the application uses the 'cpuid' to figure out if 'aes' is available instead of using /proc/cpuinfo, it _will_ get the 'aes' on one machine. This application using CPUID and getting and not getting the right filtered value is not present with HVM guests - as the CPUID instruction is trapped there irregardless of whether it is running in the kernel or user-land. _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel From xen-devel-bounces@lists.xensource.com Mon Sep 12 12:53:09 2011 Return-path: Envelope-to: www-data@lists.xensource.com Delivery-date: Mon, 12 Sep 2011 12:53:10 -0700 Received: from localhost ([127.0.0.1] helo=lists.colo.xensource.com) by lists.xensource.com with esmtp (Exim 4.43) id 1R3CZ3-00064Y-0M; Mon, 12 Sep 2011 12:53:09 -0700 Received: from mail174.messagelabs.com ([85.158.138.51]) by lists.xensource.com with esmtp (Exim 4.43) id 1R3CYA-0005rg-KE for xen-devel@lists.xensource.com; Mon, 12 Sep 2011 12:52:15 -0700 X-Env-Sender: nathan@gt.net X-Msg-Ref: server-10.tower-174.messagelabs.com!1315857129!31156247!1 X-Originating-IP: [208.70.244.21] X-StarScan-Version: 6.3.6; banners=-,-,- X-VirusChecked: Checked Received: (qmail 26731 invoked from network); 12 Sep 2011 19:52:11 -0000 Received: from gossamer.nmsrv.com (HELO gossamer.nmsrv.com) (208.70.244.21) by server-10.tower-174.messagelabs.com with DHE-RSA-AES256-SHA encrypted SMTP; 12 Sep 2011 19:52:11 -0000 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=gt.net; h=message-id:date :from:mime-version:to:subject:content-type :content-transfer-encoding; s=mail; bh=LMmQI0hHvHbybp7FnMtbiZkxD 9k=; b=qeoZm67ucybiz6/5jvGHWSaUNZ7jyAHkHU9efS52DmmqQCEXFSHJL4B3a k166jbypBSLHlTpbNbP+j90IXCfSU/1YiXIQ30nk9Hjs62F60/51/nKfjKIUBQ55 hM2iCj6n5wdHw8O8KdAd9GGq7NZSEufd1AAwQrLpjBlsqKZuG8= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gt.net; h=message-id:date :from:mime-version:to:subject:content-type :content-transfer-encoding; q=dns; s=mail; b=0eDW3U67PWJxV0LlolD NMGp578ZfKiS7jWVsYvICZdvyXj0z+EnJjUbmbLErY0wcI0c4f370OY0JxcGVCxk oA2yfKe1SboEMGG99Nv/7tFxYJsx55uIbWSnIMTR4ZlftwvA2xnHN3e39wyJHxlc qYKQAOfmbZLPiXB3XyIwKd2I= Received: (qmail 16304 invoked from network); 12 Sep 2011 19:52:08 -0000 X-AntiVirus: Clean Received: from gateway.gossamer-threads.com (HELO ?192.168.1.152?) (nathan@gossamer-threads.com@208.70.247.145) by gossamer.nmsrv.com with ESMTPSA (DHE-RSA-CAMELLIA256-SHA encrypted); 12 Sep 2011 19:52:08 -0000 Message-ID: <4E6E62E8.4050400@gt.net> Date: Mon, 12 Sep 2011 12:52:08 -0700 From: Nathan March User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:7.0) Gecko/20110905 Thunderbird/7.0 MIME-Version: 1.0 To: xen-devel@lists.xensource.com Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: [Xen-devel] SLUB allocation error on 3.0.3 / 4.1.1 X-BeenThere: xen-devel@lists.xensource.com X-Mailman-Version: 2.1.5 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xensource.com Errors-To: xen-devel-bounces@lists.xensource.com Hi All, Running into temporary pauses in our VMs which correspond to these errors in dmesg on the dom0: [1721485.352560] SLUB: Unable to allocate memory on node -1 (gfp=0x20) [1721485.352563] cache: kmalloc-2048, object size: 2048, buffer size: 2048, default order: 3, min order: 0 [1721485.352566] node 0: slabs: 81, objs: 1296, free: 0 [1721485.352576] swapper: page allocation failure: order:0, mode:0x4020 [1721485.352579] Pid: 0, comm: swapper Not tainted 3.0.3 #1 [1721485.352582] Call Trace: [1721485.352584] [] warn_alloc_failed+0x12b/0x142 [1721485.352595] [] ? get_page_from_freelist+0x51c/0x547 [1721485.352601] [] ? xen_force_evtchn_callback+0xd/0xf [1721485.352605] [] __alloc_pages_nodemask+0x606/0x67d [1721485.352610] [] ? xen_restore_fl_direct_reloc+0x4/0x4 [1721485.352614] [] new_slab+0x7e/0x1f6 [1721485.352617] [] __slab_alloc+0x19a/0x33c [1721485.352623] [] ? __netdev_alloc_skb+0x1d/0x3c [1721485.352627] [] __kmalloc_track_caller+0x106/0x145 [1721485.352631] [] ? __netdev_alloc_skb+0x1d/0x3c [1721485.352634] [] __alloc_skb+0x69/0x129 [1721485.352638] [] __netdev_alloc_skb+0x1d/0x3c [1721485.352643] [] e1000_alloc_rx_buffers+0x7f/0x14c [1721485.352647] [] e1000_clean_rx_irq+0x265/0x28c [1721485.352651] [] ? xen_force_evtchn_callback+0xd/0xf [1721485.352655] [] e1000_clean+0x75/0x24e [1721485.352658] [] ? xen_restore_fl_direct_reloc+0x4/0x4 [1721485.352663] [] net_rx_action+0xdd/0x20f [1721485.352668] [] __do_softirq+0xd3/0x1bb [1721485.352673] [] ? handle_edge_irq+0x9d/0xbc [1721485.352678] [] call_softirq+0x1c/0x30 [1721485.352682] [] do_softirq+0x61/0xbf [1721485.352686] [] irq_exit+0x43/0xb2 [1721485.352691] [] xen_evtchn_do_upcall+0x2f/0x3c [1721485.352695] [] xen_do_hypervisor_callback+0x1e/0x30 [1721485.352697] [] ? hypercall_page+0x3aa/0x1000 [1721485.352705] [] ? hypercall_page+0x3aa/0x1000 [1721485.352709] [] ? xen_safe_halt+0x10/0x1a [1721485.352714] [] ? default_idle+0x5e/0xa6 [1721485.352718] [] ? cpu_idle+0x6d/0xa3 [1721485.352723] [] ? rest_init+0x68/0x6a [1721485.352729] [] ? start_kernel+0x412/0x41d [1721485.352733] [] ? x86_64_start_reservations+0xb6/0xba [1721485.352737] [] ? xen_start_kernel+0x59b/0x5a2 [1721485.352739] Mem-Info: [1721485.352741] DMA per-cpu: [1721485.352744] CPU 0: hi: 0, btch: 1 usd: 0 [1721485.352746] DMA32 per-cpu: [1721485.352748] CPU 0: hi: 186, btch: 31 usd: 176 [1721485.352750] Normal per-cpu: [1721485.352752] CPU 0: hi: 186, btch: 31 usd: 0 [1721485.352757] active_anon:2403 inactive_anon:13164 isolated_anon:0 [1721485.352758] active_file:66256 inactive_file:75740 isolated_file:0 [1721485.352759] unevictable:507 dirty:3175 writeback:40742 unstable:0 [1721485.352760] free:13180 slab_reclaimable:5805 slab_unreclaimable:9005 [1721485.352761] mapped:1983 shmem:4 pagetables:1147 bounce:0 [1721485.352768] DMA free:15904kB min:16kB low:20kB high:24kB active_anon:0kB inactive_anon:0kB active_file:0kB inactive_file:0kB unevictable:0kB isolated(anon):0kB isolated(file):0kB present:15680kB mlocked:0kB dirty:0kB writeback:0kB mapped:0kB shmem:0kB slab_reclaimable:0kB slab_unreclaimable:0kB kernel_stack:0kB pagetables:0kB unstable:0kB bounce:0kB writeback_tmp:0kB pages_scanned:0 all_unreclaimable? yes [1721485.352774] lowmem_reserve[]: 0 952 10042 10042 [1721485.352784] DMA32 free:36816kB min:1212kB low:1512kB high:1816kB active_anon:9612kB inactive_anon:52656kB active_file:265024kB inactive_file:302960kB unevictable:2028kB isolated(anon):0kB isolated(file):0kB present:975072kB mlocked:2028kB dirty:12700kB writeback:162968kB mapped:7932kB shmem:16kB slab_reclaimable:23220kB slab_unreclaimable:36020kB kernel_stack:2360kB pagetables:4588kB unstable:0kB bounce:0kB writeback_tmp:0kB pages_scanned:0 all_unreclaimable? no [1721485.352790] lowmem_reserve[]: 0 0 9090 9090 [1721485.352799] Normal free:0kB min:11600kB low:14500kB high:17400kB active_anon:0kB inactive_anon:0kB active_file:0kB inactive_file:0kB unevictable:0kB isolated(anon):0kB isolated(file):0kB present:9308160kB mlocked:0kB dirty:0kB writeback:0kB mapped:0kB shmem:0kB slab_reclaimable:0kB slab_unreclaimable:0kB kernel_stack:0kB pagetables:0kB unstable:0kB bounce:0kB writeback_tmp:0kB pages_scanned:0 all_unreclaimable? yes [1721485.352805] lowmem_reserve[]: 0 0 0 0 [1721485.352810] DMA: 0*4kB 0*8kB 0*16kB 1*32kB 2*64kB 1*128kB 1*256kB 0*512kB 1*1024kB 1*2048kB 3*4096kB = 15904kB [1721485.352822] DMA32: 588*4kB 256*8kB 150*16kB 168*32kB 285*64kB 34*128kB 6*256kB 1*512kB 0*1024kB 0*2048kB 0*4096kB = 36816kB [1721485.352834] Normal: 0*4kB 0*8kB 0*16kB 0*32kB 0*64kB 0*128kB 0*256kB 0*512kB 0*1024kB 0*2048kB 0*4096kB = 0kB [1721485.352845] 153277 total pagecache pages [1721485.352848] 10888 pages in swap cache [1721485.352850] Swap cache stats: add 3069760, delete 3058872, find 3791763/4300237 [1721485.352852] Free swap = 1816844kB [1721485.352854] Total swap = 1943856kB [1721485.377309] 2621424 pages RAM [1721485.377312] 2427446 pages reserved [1721485.377313] 108302 pages shared [1721485.377315] 126166 pages non-shared [1721485.377319] SLUB: Unable to allocate memory on node -1 (gfp=0x20) [1721485.377323] cache: kmalloc-2048, object size: 2048, buffer size: 2048, default order: 3, min order: 0 [1721485.377326] node 0: slabs: 81, objs: 1296, free: 0 [1721485.377560] SLUB: Unable to allocate memory on node -1 (gfp=0x20) [1721485.377564] cache: kmalloc-2048, object size: 2048, buffer size: 2048, default order: 3, min order: 0 [1721485.377567] node 0: slabs: 81, objs: 1296, free: 0 xen7 ~ # xm info host : xen7 release : 3.0.3 version : #1 SMP Mon Aug 22 14:25:38 PDT 2011 machine : x86_64 nr_cpus : 24 nr_nodes : 2 cores_per_socket : 6 threads_per_core : 2 cpu_mhz : 2266 hw_caps : bfebfbff:2c100800:00000000:00003f40:009ee3fd:00000000:00000001:00000000 virt_caps : hvm hvm_directio total_memory : 98294 free_memory : 36580 free_cpus : 0 xen_major : 4 xen_minor : 1 xen_extra : .1 xen_caps : xen-3.0-x86_64 xen-3.0-x86_32p hvm-3.0-x86_32 hvm-3.0-x86_32p hvm-3.0-x86_64 xen_scheduler : credit xen_pagesize : 4096 platform_params : virt_start=0xffff800000000000 xen_changeset : unavailable xen_commandline : console=com1,com2,vga com1=115200,8n1 com2=115200,8n1 dom0_mem=1024M dom0_max_vcpus=1 dom0_vcpus_pin=true cc_compiler : gcc version 4.3.4 (Gentoo 4.3.4 p1.1, pie-10.1.5) cc_compile_by : root cc_compile_domain : nmsrv.com cc_compile_date : Mon Aug 22 11:28:50 PDT 2011 xend_config_format : 4 Seeing this on multiple dom0's which are all running identical hardware (Supermicro X8DTT w/ Intel 82574L gige). Dom0's are limited to 1gb (dom0_mem=1024M dom0_max_vcpus=1 dom0_vcpus_pin=true) although they don't go above 250mb used. Not sure if this is a xen bug, network driver issue or something else? - Nathan -- Nathan March Gossamer Threads Inc. http://www.gossamer-threads.com/ Tel: (604) 687-5804 Fax: (604) 687-5806 _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel From xen-users-bounces@lists.xensource.com Mon Sep 12 13:09:20 2011 Return-path: Envelope-to: www-data@lists.xensource.com Delivery-date: Mon, 12 Sep 2011 13:09:20 -0700 Received: from localhost ([127.0.0.1] helo=lists.colo.xensource.com) by lists.xensource.com with esmtp (Exim 4.43) id 1R3Coi-0006qE-3B; Mon, 12 Sep 2011 13:09:20 -0700 Received: from mail27.messagelabs.com ([193.109.254.147]) by lists.xensource.com with smtp (Exim 4.43) id 1R3Cmy-0006VN-HY for xen-users@lists.xensource.com; Mon, 12 Sep 2011 13:07:33 -0700 X-Env-Sender: jim_burn@bellsouth.net X-Msg-Ref: server-7.tower-27.messagelabs.com!1315858027!48354960!1 X-Originating-IP: [66.94.237.94] X-StarScan-Version: 6.3.6; banners=-,-,- X-VirusChecked: Checked Received: (qmail 6660 invoked from network); 12 Sep 2011 20:07:07 -0000 Received: from nm29.access.bullet.mail.mud.yahoo.com (HELO nm29.access.bullet.mail.mud.yahoo.com) (66.94.237.94) by server-7.tower-27.messagelabs.com with SMTP; 12 Sep 2011 20:07:07 -0000 Received: from [66.94.237.201] by nm29.access.bullet.mail.mud.yahoo.com with NNFMP; 12 Sep 2011 20:07:28 -0000 Received: from [66.94.237.120] by tm12.access.bullet.mail.mud.yahoo.com with NNFMP; 12 Sep 2011 20:07:28 -0000 Received: from [127.0.0.1] by omp1025.access.mail.mud.yahoo.com with NNFMP; 12 Sep 2011 20:07:28 -0000 X-Yahoo-Newman-Id: 622229.9978.bm@omp1025.access.mail.mud.yahoo.com Received: (qmail 93153 invoked from network); 12 Sep 2011 20:07:28 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=bellsouth.net; s=s1024; t=1315858048; bh=YLHSexQUEj9lw8zt7MSb8ej4LVc1k1P3+orhhptI85s=; h=X-Yahoo-Newman-Property:X-YMail-OSG:X-Yahoo-SMTP:Received:From:To:Cc:Subject:Date:Message-ID:User-Agent:In-Reply-To:References:MIME-Version:Content-Transfer-Encoding:Content-Type; b=t+JisIjmxxeBtuFPb7zKq8BrA/eZrjELixaeoh1nfoGZDrDRstwxKxsFU4sqAYH+YgcE1YNpGJiIuY9qKfc5ME2+//DBQftshSAXrgQ9G0YlMvT/0ayaA9UBAOYPhWW3COtqwb+63P0t/mvzKdtOnR1P0AZNF+eLOw4MM8JoE0c= X-Yahoo-Newman-Property: ymail-3 X-YMail-OSG: 6C9Jrs0VM1k_8P3Oi2bbKsI7WwmPEZ0puKkmX2gCabfXkcI S6kQo4PwTkwXpUypcVe6VX_i27TnuzAmVcEQ4_X.ZpIpOjv.WSOHZUQnkqrv Mms8HuL6VLTVvNtMvh8shPBEJK440gHdAI_GVc_YBkhk4YGIk.qmsTuLj6ZC hRcVHbAUUQU5GA0cOkfT86bdyCc7IE3Xo6vNFxUfaRaSWCjMpOjM84afwksy TfT8vMqyGw3zVd_sPaJLGxWitiKe4P.dQZQu08DPMl0lEIm5uwe3CQXlAAtH SkXu25YoAP9K13QuAP_x3paEWJNj9UXhsg7vim2k8YekT5sU44jYus.b8ZwR yMLlcmtGCjH1vCwC4LvxzZPzgwZDZ0iTgzRkQ4cGRQ1lZgEv0oLUTlByEZRN lZXMLjNQjhmXMDQGi3uoaM.XdNzM6n1dS90lrmA-- X-Yahoo-SMTP: g0AhWW2swBA2djJKuhuwxPlPqLrHlDrycdPnfR9kZNrpKCA- Received: from dell4550.localnet (jim_burn@72.145.181.238 with plain) by smtp109.sbc.mail.bf1.yahoo.com with SMTP; 12 Sep 2011 13:07:27 -0700 PDT From: jim burns To: Pasi =?ISO-8859-1?Q?K=E4rkk=E4inen?= Date: Mon, 12 Sep 2011 16:07:21 -0400 Message-ID: <1342436.B0x3ddQn4U@dell4550> User-Agent: KMail/4.7.1 (Linux/2.6.37.6-0.7-default; KDE/4.7.1; i686; ; ) In-Reply-To: <20110912073623.GF12984@reaktio.net> References: <201107231426.56811.jim_burn@bellsouth.net> <13293012.CAopQqStiY@dell4550> <20110912073623.GF12984@reaktio.net> MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="iso-8859-1" Cc: Todd Deshane , xen-devel@lists.xensource.com, xen-users@lists.xensource.com, Fedora Xen List Subject: [Xen-users] Re: Continuing BUG:-iness booting Fedora Rawhide 3.1.0-rc's (was Summary: Experiences setting up a debug serial port) X-BeenThere: xen-users@lists.xensource.com X-Mailman-Version: 2.1.5 Precedence: list List-Id: Xen user discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-users-bounces@lists.xensource.com Errors-To: xen-users-bounces@lists.xensource.com On Mon September 12 2011, 10:36:23 AM, Pasi K=E4rkk=E4inen wrote: > > Sure, thanx, attached. Do you need a debug log also (initcall_debug= > > debug loglevel=3D10)? > > >=20 > Sure, it doesn't hurt.. I'll get it to you in a couple of days. > > The last four BUG:s (from Sep 8 17:12:20 on) were from starting a = winxp > > domu (first 3 BUG:s), and destroying it at grub (the last BUG:). >=20 > Ok, so there are BUGs when booting up, and also when starting HVM gue= sts. Right, from Sep 8, 17:12 on. The 'comm:'s referenced are xenstored (2x)= and=20 qemu-dm (1x) when starting the guest (as far as grub), and xenconsoled = when=20 'xm destroy'-ing it. Thanx for your interest. _______________________________________________ Xen-users mailing list Xen-users@lists.xensource.com http://lists.xensource.com/xen-users From xen-devel-bounces@lists.xensource.com Mon Sep 12 13:14:03 2011 Return-path: Envelope-to: www-data@lists.xensource.com Delivery-date: Mon, 12 Sep 2011 13:14:03 -0700 Received: from localhost ([127.0.0.1] helo=lists.colo.xensource.com) by lists.xensource.com with esmtp (Exim 4.43) id 1R3CtH-0007oT-GA; Mon, 12 Sep 2011 13:14:03 -0700 Received: from mail182.messagelabs.com ([85.158.139.83]) by lists.xensource.com with esmtp (Exim 4.43) id 1R3Cso-0007c0-Hj for xen-devel@lists.xensource.com; Mon, 12 Sep 2011 13:13:35 -0700 X-Env-Sender: konrad@oracle.com X-Msg-Ref: server-9.tower-182.messagelabs.com!1315858409!18041737!1 X-Originating-IP: [148.87.113.117] X-StarScan-Version: 6.3.6; banners=-,-,- X-VirusChecked: Checked Received: (qmail 4026 invoked from network); 12 Sep 2011 20:13:31 -0000 Received: from rcsinet15.oracle.com (HELO rcsinet15.oracle.com) (148.87.113.117) by server-9.tower-182.messagelabs.com with DHE-RSA-AES256-SHA encrypted SMTP; 12 Sep 2011 20:13:31 -0000 Received: from acsinet22.oracle.com (acsinet22.oracle.com [141.146.126.238]) by rcsinet15.oracle.com (Switch-3.4.4/Switch-3.4.4) with ESMTP id p8CKDQQj000669 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Mon, 12 Sep 2011 20:13:28 GMT Received: from acsmt357.oracle.com (acsmt357.oracle.com [141.146.40.157]) by acsinet22.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id p8CKDQDC012765 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 12 Sep 2011 20:13:26 GMT Received: from abhmt109.oracle.com (abhmt109.oracle.com [141.146.116.61]) by acsmt357.oracle.com (8.12.11.20060308/8.12.11) with ESMTP id p8CKDLgs032474; Mon, 12 Sep 2011 15:13:21 -0500 Received: from oracle.com (/209.6.55.207) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Mon, 12 Sep 2011 13:13:20 -0700 Received: by oracle.com (Postfix, from userid 1000) id D5F3B1362; Mon, 12 Sep 2011 16:13:19 -0400 (EDT) Date: Mon, 12 Sep 2011 16:13:19 -0400 From: Konrad Rzeszutek Wilk To: david.vrabel@citrix.com, xen-devel@lists.xensource.com Message-ID: <20110912201319.GA11900@oracle.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.5.21 (2010-09-15) X-Source-IP: acsinet22.oracle.com [141.146.126.238] X-Auth-Type: Internal IP X-CT-RefId: str=0001.0A090207.4E6E67E8.0163:SCFMA922111,ss=1,re=-4.000,fgs=0 Cc: Subject: [Xen-devel] fix for "xen: use maximum reservation to limit amount of usable RAM" - patch titled: "xen/e820: if there is not dom0_mem, don't tweak extra_pages." X-BeenThere: xen-devel@lists.xensource.com X-Mailman-Version: 2.1.5 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xensource.com Errors-To: xen-devel-bounces@lists.xensource.com .breaks one of my boxes (Core i3-2100), with Xen 4.1.1 (with and w/out the 23790 changset in it). I've traced it down to the fact that I booted my dom0 without dom0_mem=X flag with a machine that has more than 8GB. Weirdly enough I can only reproduce this under Intel boxes. Anyhow this patch fixes it for me. commit e4297f5719e982d95788cd53e284a7a389eedb45 Author: Konrad Rzeszutek Wilk Date: Mon Sep 12 15:58:25 2011 -0400 xen/e820: if there is not dom0_mem, don't tweak extra_pages. The patch "xen: use maximum reservation to limit amount of usable RAM" (d312ae878b6aed3912e1acaaf5d0b2a9d08a4f11) breaks machines that do not use 'dom0_mem=' argument with: reserve RAM buffer: 000000133f2e2000 - 000000133fffffff (XEN) mm.c:4976:d0 Global bit is set to kernel page fffff8117e (XEN) domain_crash_sync called from entry.S (XEN) Domain 0 (vcpu#0) crashed on cpu#0: ... The reason being that the last E820 entry is created using the 'extra_pages' (which is based on how many pages have been freed). The mentioned git commit sets the initial value of 'extra_pages' using a hypercall which returns the number of pages (if dom0_mem has been used) or -1 otherwise. If the later we return with MAX_DOMAIN_PAGES as basis for calculation: return min(max_pages, MAX_DOMAIN_PAGES); and use it: extra_limit = xen_get_max_pages(); if (extra_limit >= max_pfn) extra_pages = extra_limit - max_pfn; else extra_pages = 0; which means we end up with extra_pages = 128GB in PFNs (33554432) - 8GB in PFNs (2097152, on this specific box, can be larger or smaller), and then we add that value to the E820 making it: Xen: 00000000ff000000 - 0000000100000000 (reserved) Xen: 0000000100000000 - 000000133f2e2000 (usable) which is clearly wrong. It should look as so: Xen: 00000000ff000000 - 0000000100000000 (reserved) Xen: 0000000100000000 - 000000027fbda000 (usable) Naturally this problem does not present itself if dom0_mem=max:X is used. CC: David Vrabel Signed-off-by: Konrad Rzeszutek Wilk diff --git a/arch/x86/xen/setup.c b/arch/x86/xen/setup.c index c3b8d44..0632de1 100644 --- a/arch/x86/xen/setup.c +++ b/arch/x86/xen/setup.c @@ -185,16 +185,18 @@ static unsigned long __init xen_set_identity(const struct e820entry *list, return identity; } -static unsigned long __init xen_get_max_pages(void) +static bool __init xen_get_max_pages(unsigned long *max_pages) { - unsigned long max_pages = MAX_DOMAIN_PAGES; domid_t domid = DOMID_SELF; int ret; ret = HYPERVISOR_memory_op(XENMEM_maximum_reservation, &domid); - if (ret > 0) - max_pages = ret; - return min(max_pages, MAX_DOMAIN_PAGES); + /* If dom0_mem=X is not used, it will return -1. */ + if (ret > 0) { + *max_pages = (unsigned long)min(ret, MAX_DOMAIN_PAGES); + return true; + } + return false; } /** @@ -210,7 +212,7 @@ char * __init xen_memory_setup(void) int rc; struct xen_memory_map memmap; unsigned long extra_pages = 0; - unsigned long extra_limit; + unsigned long extra_limit = 0; unsigned long identity_pages = 0; int i; int op; @@ -305,11 +307,12 @@ char * __init xen_memory_setup(void) sanitize_e820_map(e820.map, ARRAY_SIZE(e820.map), &e820.nr_map); - extra_limit = xen_get_max_pages(); - if (extra_limit >= max_pfn) - extra_pages = extra_limit - max_pfn; - else - extra_pages = 0; + if (xen_get_max_pages(&extra_limit)) { + if (extra_limit >= max_pfn) + extra_pages = extra_limit - max_pfn; + else + extra_pages = 0; + } extra_pages += xen_return_unused_memory(xen_start_info->nr_pages, &e820); _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel From xen-devel-bounces@lists.xensource.com Mon Sep 12 13:18:32 2011 Return-path: Envelope-to: www-data@lists.xensource.com Delivery-date: Mon, 12 Sep 2011 13:18:32 -0700 Received: from localhost ([127.0.0.1] helo=lists.colo.xensource.com) by lists.xensource.com with esmtp (Exim 4.43) id 1R3Cxc-0008FD-Sm; Mon, 12 Sep 2011 13:18:32 -0700 Received: from mail174.messagelabs.com ([85.158.138.51]) by lists.xensource.com with esmtp (Exim 4.43) id 1R3Cx2-00082e-Qe for xen-devel@lists.xensource.com; Mon, 12 Sep 2011 13:17:57 -0700 X-Env-Sender: konrad@oracle.com X-Msg-Ref: server-8.tower-174.messagelabs.com!1315858672!17487334!1 X-Originating-IP: [141.146.126.227] X-StarScan-Version: 6.3.6; banners=-,-,- X-VirusChecked: Checked Received: (qmail 7966 invoked from network); 12 Sep 2011 20:17:53 -0000 Received: from acsinet15.oracle.com (HELO acsinet15.oracle.com) (141.146.126.227) by server-8.tower-174.messagelabs.com with DHE-RSA-AES256-SHA encrypted SMTP; 12 Sep 2011 20:17:53 -0000 Received: from rtcsinet22.oracle.com (rtcsinet22.oracle.com [66.248.204.30]) by acsinet15.oracle.com (Switch-3.4.4/Switch-3.4.4) with ESMTP id p8CKHm4b014949 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Mon, 12 Sep 2011 20:17:50 GMT Received: from acsmt356.oracle.com (acsmt356.oracle.com [141.146.40.156]) by rtcsinet22.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id p8CKHkiN001960 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 12 Sep 2011 20:17:47 GMT Received: from abhmt108.oracle.com (abhmt108.oracle.com [141.146.116.60]) by acsmt356.oracle.com (8.12.11.20060308/8.12.11) with ESMTP id p8CKHfZE024910; Mon, 12 Sep 2011 15:17:41 -0500 Received: from oracle.com (/209.6.55.207) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Mon, 12 Sep 2011 13:17:41 -0700 Received: by oracle.com (Postfix, from userid 1000) id B1EE91362; Mon, 12 Sep 2011 16:17:40 -0400 (EDT) Date: Mon, 12 Sep 2011 16:17:40 -0400 From: Konrad Rzeszutek Wilk To: Nathan March Subject: Re: [Xen-devel] SLUB allocation error on 3.0.3 / 4.1.1 Message-ID: <20110912201740.GB11900@oracle.com> References: <4E6E62E8.4050400@gt.net> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <4E6E62E8.4050400@gt.net> User-Agent: Mutt/1.5.21 (2010-09-15) X-Source-IP: rtcsinet22.oracle.com [66.248.204.30] X-CT-RefId: str=0001.0A090203.4E6E68EE.0137,ss=1,re=0.000,fgs=0 Cc: xen-devel@lists.xensource.com X-BeenThere: xen-devel@lists.xensource.com X-Mailman-Version: 2.1.5 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xensource.com Errors-To: xen-devel-bounces@lists.xensource.com > total_memory : 98294 > free_memory : 36580 > free_cpus : 0 > xen_major : 4 > xen_minor : 1 > xen_extra : .1 > xen_caps : xen-3.0-x86_64 xen-3.0-x86_32p > hvm-3.0-x86_32 hvm-3.0-x86_32p hvm-3.0-x86_64 > xen_scheduler : credit > xen_pagesize : 4096 > platform_params : virt_start=0xffff800000000000 > xen_changeset : unavailable > xen_commandline : console=com1,com2,vga com1=115200,8n1 > com2=115200,8n1 dom0_mem=1024M dom0_max_vcpus=1 dom0_vcpus_pin=true > cc_compiler : gcc version 4.3.4 (Gentoo 4.3.4 p1.1, pie-10.1.5) > cc_compile_by : root > cc_compile_domain : nmsrv.com > cc_compile_date : Mon Aug 22 11:28:50 PDT 2011 > xend_config_format : 4 > > Seeing this on multiple dom0's which are all running identical > hardware (Supermicro X8DTT w/ Intel 82574L gige). Dom0's are limited > to 1gb (dom0_mem=1024M dom0_max_vcpus=1 dom0_vcpus_pin=true) > although they don't go above 250mb used. > > Not sure if this is a xen bug, network driver issue or something else? It is a Linux kernel bug. It does not respect the dom0_mem=max:X argument so you end up with 98GB of pagetables in Dom0 and you can't allocate enough memory for your normal drivers (since most of the memory is used for your non-used pagetables). The workaround is to put in your Linux command-line: "mem=1GB" (and keep the dom0_mem=..) arguments. A patch in 3.0.4 (or 3.0.5) should soon surface which will fix this. _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel From xen-users-bounces@lists.xensource.com Mon Sep 12 13:55:27 2011 Return-path: Envelope-to: www-data@lists.xensource.com Delivery-date: Mon, 12 Sep 2011 13:55:27 -0700 Received: from localhost ([127.0.0.1] helo=lists.colo.xensource.com) by lists.xensource.com with esmtp (Exim 4.43) id 1R3DXK-00010n-KZ; Mon, 12 Sep 2011 13:55:26 -0700 Received: from mail182.messagelabs.com ([85.158.139.83]) by lists.xensource.com with esmtp (Exim 4.43) id 1R3DVq-0000fe-8D; Mon, 12 Sep 2011 13:53:54 -0700 X-Env-Sender: hwang.jinho@gmail.com X-Msg-Ref: server-12.tower-182.messagelabs.com!1315860829!17901373!1 X-Originating-IP: [209.85.161.175] X-StarScan-Version: 6.3.6; banners=-,-,- X-VirusChecked: Checked Received: (qmail 30974 invoked from network); 12 Sep 2011 20:53:50 -0000 Received: from mail-gx0-f175.google.com (HELO mail-gx0-f175.google.com) (209.85.161.175) by server-12.tower-182.messagelabs.com with RC4-SHA encrypted SMTP; 12 Sep 2011 20:53:50 -0000 Received: by gxk4 with SMTP id 4so448442gxk.6 for ; Mon, 12 Sep 2011 13:53:49 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:from:date:message-id:subject:to:content-type; bh=vIknSPROq4/5zgpSLn0M5TZByj9uN56fzxMIoG/VXOg=; b=Jab78Zj0O7GcS3STMVrpg0m3q5WCnWm969S2aK8VARj8RUKTkK1nZFKlABczZs3dQk A6ubxSLIjqVZweuB5+swqj4x8mE+NjiXxbqiza7S4c6SuSMXb2vzK9yoR9DyWTgmt7ZT IuTkPEeCPU5ZcwEtdHWL3OysIB+OfqKPmyuFQ= Received: by 10.150.63.2 with SMTP id l2mr2139863yba.63.1315860829309; Mon, 12 Sep 2011 13:53:49 -0700 (PDT) MIME-Version: 1.0 Received: by 10.151.154.16 with HTTP; Mon, 12 Sep 2011 13:53:29 -0700 (PDT) From: jinho hwang Date: Mon, 12 Sep 2011 16:53:29 -0400 Message-ID: To: xen-devel@lists.xensource.com, xen-users@lists.xensource.com Cc: Subject: [Xen-users] Can anyone share xen kernel 2.6.32 stable version? X-BeenThere: xen-users@lists.xensource.com X-Mailman-Version: 2.1.5 Precedence: list List-Id: Xen user discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1858591464==" Sender: xen-users-bounces@lists.xensource.com Errors-To: xen-users-bounces@lists.xensource.com --===============1858591464== Content-Type: multipart/alternative; boundary=000e0cd3b27c4e0bca04acc4b933 --000e0cd3b27c4e0bca04acc4b933 Content-Type: text/plain; charset=ISO-8859-1 Hi Everyone, Since the kernel.org is under construction, can anyone share the latest xen kernel from git.kernel.org? I really tried all the possibilities with kernel 2.6.27 from xenbits.xensource.com in Ubuntu 11.04 and 10.04 as well, but it didn't work with so many problems. Thank you, Jinho -- Jinho Hwang PhD Student Department of Computer Science The George Washington University Washington, DC 20052 hwang.jinho@gmail.com (email) 276.336.0971 (Cell) 202.994.4875 (fax) 070.8285.6546 (myLg070) --000e0cd3b27c4e0bca04acc4b933 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable

Hi Everyone,=A0

Since the kernel.org is under construction, can anyone share the l= atest xen kernel from git.kernel.org?= =A0
I really tried all the possibilities with kernel 2.6.27 from xenbits.xensource.com in Ubuntu 11.04= and 10.04 as well, but it didn't work with so many problems. =A0

Thank you,

Jinho
--
Jinho Hwang
PhD Student
Department of Computer Science<= br>The George Washington University
Washington, DC 20052
hwang.jinho@gmail.com (email)
276.336.0971 (Cell)
202.994.4875 (fax)
070.8285.6546 (myLg070)
--000e0cd3b27c4e0bca04acc4b933-- --===============1858591464== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Xen-users mailing list Xen-users@lists.xensource.com http://lists.xensource.com/xen-users --===============1858591464==-- From xen-devel-bounces@lists.xensource.com Mon Sep 12 14:11:40 2011 Return-path: Envelope-to: www-data@lists.xensource.com Delivery-date: Mon, 12 Sep 2011 14:11:40 -0700 Received: from localhost ([127.0.0.1] helo=lists.colo.xensource.com) by lists.xensource.com with esmtp (Exim 4.43) id 1R3Dn2-0002V6-Kx; Mon, 12 Sep 2011 14:11:40 -0700 Received: from mail21.messagelabs.com ([85.158.143.35]) by lists.xensource.com with esmtp (Exim 4.43) id 1R34vc-0006jz-Nr for xen-devel@lists.xensource.com; Mon, 12 Sep 2011 04:43:57 -0700 X-Env-Sender: amamonov@kupivip.ru X-Msg-Ref: server-5.tower-21.messagelabs.com!1315827800!47785027!1 X-Originating-IP: [195.208.3.4] X-StarScan-Version: 6.3.6; banners=-,-,- X-VirusChecked: Checked Received: (qmail 28725 invoked from network); 12 Sep 2011 11:43:21 -0000 Received: from relay03.nicmail.ru (HELO relay03.nicmail.ru) (195.208.3.4) by server-5.tower-21.messagelabs.com with DHE-RSA-AES256-SHA encrypted SMTP; 12 Sep 2011 11:43:21 -0000 Received: from [194.85.88.231] (port=54663 helo=nicmail.ru) by f06.mail.nic.ru with esmtp (Exim 5.55) (envelope-from ) id 1R34vY-000Omn-Tl for xen-devel@lists.xensource.com; Mon, 12 Sep 2011 15:43:52 +0400 Received: from [89.221.54.106] (account amamonov@kupivip.ru HELO [10.1.10.15]) by fcgp02.nicmail.ru (CommuniGate Pro SMTP 5.2.3) with ESMTPA id 37984326 for xen-devel@lists.xensource.com; Mon, 12 Sep 2011 15:43:52 +0400 From: "Alexey M." To: xen-devel@lists.xensource.com Content-Type: text/plain; charset="UTF-8" Organization: kupivip Date: Mon, 12 Sep 2011 15:43:31 +0400 Message-ID: <1315827811.597.4.camel@Hronos> Mime-Version: 1.0 X-Mailer: Evolution 2.32.2 Content-Transfer-Encoding: 7bit X-Mailman-Approved-At: Mon, 12 Sep 2011 14:09:43 -0700 Subject: [Xen-devel] gentoo cant attach bridge X-BeenThere: xen-devel@lists.xensource.com X-Mailman-Version: 2.1.5 Precedence: list Reply-To: alexit@kupivip.ru List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xensource.com Errors-To: xen-devel-bounces@lists.xensource.com Hi, i configure xen 4.1.1 on gentoo and configured bridge in this system xenbr0 brctl show bridge name bridge id STP enabled interfaces xenbr0 8000.984be16d4aac yes vlan201 then chenged: /etc/xen/xend-config.sxp (vif-script vif-bridge) (network-script /bin/true) cat /etc/xen/guest|grep vif vif = [ "mac=00:16:36:6b:93:ef, bridge=xenbr0" ] But: xl create guest brctl show bridge name bridge id STP enabled interfaces xenbr0 8000.984be16d4aac yes vlan201 No any new interfaces. In log xend: 2011-09-12 15:11:41 2373] INFO (XendNetwork:114) Not recreating missing unmanaged network vlan121 [2011-09-12 15:11:41 2373] INFO (XendNetwork:114) Not recreating missing unmanaged network eth0 [2011-09-12 15:11:41 2373] INFO (XendNetwork:114) Not recreating missing unmanaged network xenbr1 I have vlan121 eth0 xenbr1, but do not use in any xen files Please show me the right path! -- B-rs, Alexey Mamonov, System Administratioin "Privat Trade" LLC Russia www.kupivip.ruB-rs, _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel From xen-devel-bounces@lists.xensource.com Mon Sep 12 14:12:31 2011 Return-path: Envelope-to: www-data@lists.xensource.com Delivery-date: Mon, 12 Sep 2011 14:12:31 -0700 Received: from localhost ([127.0.0.1] helo=lists.colo.xensource.com) by lists.xensource.com with esmtp (Exim 4.43) id 1R3Dnr-0002s2-AQ; Mon, 12 Sep 2011 14:12:31 -0700 Received: from mail182.messagelabs.com ([85.158.139.83]) by lists.xensource.com with esmtp (Exim 4.43) id 1R3DHH-0000Nk-40 for xen-devel@lists.xensource.com; Mon, 12 Sep 2011 13:38:51 -0700 X-Env-Sender: xenlist@suykerbuyk.org X-Msg-Ref: server-10.tower-182.messagelabs.com!1315859926!18037408!1 X-Originating-IP: [216.139.236.26] X-StarScan-Version: 6.3.6; banners=-,-,- X-VirusChecked: Checked Received: (qmail 30252 invoked from network); 12 Sep 2011 20:38:48 -0000 Received: from sam.nabble.com (HELO sam.nabble.com) (216.139.236.26) by server-10.tower-182.messagelabs.com with AES256-SHA encrypted SMTP; 12 Sep 2011 20:38:48 -0000 Received: from [192.168.236.26] (helo=sam.nabble.com) by sam.nabble.com with esmtp (Exim 4.72) (envelope-from ) id 1R3DHB-0005s3-PY for xen-devel@lists.xensource.com; Mon, 12 Sep 2011 13:38:45 -0700 Date: Mon, 12 Sep 2011 13:38:45 -0700 (PDT) From: JohnSuykerbuyk To: xen-devel@lists.xensource.com Message-ID: <1315859925763-4795821.post@n5.nabble.com> In-Reply-To: <20110912145843.GB15778@oracle.com> References: <20110912145843.GB15778@oracle.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Mailman-Approved-At: Mon, 12 Sep 2011 14:09:43 -0700 Subject: [Xen-devel] Re: git.kernel.org X-BeenThere: xen-devel@lists.xensource.com X-Mailman-Version: 2.1.5 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xensource.com Errors-To: xen-devel-bounces@lists.xensource.com Could you provide the URLs? I can't seem to find it. Thanks - John "S" -- View this message in context: http://xen.1045712.n5.nabble.com/git-kernel-org-tp4792977p4795821.html Sent from the Xen - Dev mailing list archive at Nabble.com. _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel From xen-devel-bounces@lists.xensource.com Mon Sep 12 14:17:27 2011 Return-path: Envelope-to: www-data@lists.xensource.com Delivery-date: Mon, 12 Sep 2011 14:17:27 -0700 Received: from localhost ([127.0.0.1] helo=lists.colo.xensource.com) by lists.xensource.com with esmtp (Exim 4.43) id 1R3Dsd-0003kD-F3; Mon, 12 Sep 2011 14:17:27 -0700 Received: from mail174.messagelabs.com ([85.158.138.51]) by lists.xensource.com with esmtp (Exim 4.43) id 1R3Ds7-0003XO-DB for xen-devel@lists.xensource.com; Mon, 12 Sep 2011 14:16:56 -0700 X-Env-Sender: konrad@oracle.com X-Msg-Ref: server-4.tower-174.messagelabs.com!1315862210!31183576!1 X-Originating-IP: [141.146.126.227] X-StarScan-Version: 6.3.6; banners=-,-,- X-VirusChecked: Checked Received: (qmail 9241 invoked from network); 12 Sep 2011 21:16:52 -0000 Received: from acsinet15.oracle.com (HELO acsinet15.oracle.com) (141.146.126.227) by server-4.tower-174.messagelabs.com with DHE-RSA-AES256-SHA encrypted SMTP; 12 Sep 2011 21:16:52 -0000 Received: from rtcsinet21.oracle.com (rtcsinet21.oracle.com [66.248.204.29]) by acsinet15.oracle.com (Switch-3.4.4/Switch-3.4.4) with ESMTP id p8CLGlnl005392 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Mon, 12 Sep 2011 21:16:49 GMT Received: from acsmt356.oracle.com (acsmt356.oracle.com [141.146.40.156]) by rtcsinet21.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id p8CLGkAN019558 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 12 Sep 2011 21:16:47 GMT Received: from abhmt106.oracle.com (abhmt106.oracle.com [141.146.116.58]) by acsmt356.oracle.com (8.12.11.20060308/8.12.11) with ESMTP id p8CLGfaD002828; Mon, 12 Sep 2011 16:16:41 -0500 Received: from oracle.com (/209.6.55.207) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Mon, 12 Sep 2011 14:16:41 -0700 Received: by oracle.com (Postfix, from userid 1000) id 88A111362; Mon, 12 Sep 2011 17:16:40 -0400 (EDT) Date: Mon, 12 Sep 2011 17:16:40 -0400 From: Konrad Rzeszutek Wilk To: JohnSuykerbuyk Subject: Re: [Xen-devel] Re: git.kernel.org Message-ID: <20110912211640.GA14805@phenom.oracle.com> References: <20110912145843.GB15778@oracle.com> <1315859925763-4795821.post@n5.nabble.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <1315859925763-4795821.post@n5.nabble.com> User-Agent: Mutt/1.5.21 (2010-09-15) X-Source-IP: rtcsinet21.oracle.com [66.248.204.29] X-CT-RefId: str=0001.0A090205.4E6E76C2.000F,ss=1,re=0.000,fgs=0 Cc: xen-devel@lists.xensource.com X-BeenThere: xen-devel@lists.xensource.com X-Mailman-Version: 2.1.5 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xensource.com Errors-To: xen-devel-bounces@lists.xensource.com On Mon, Sep 12, 2011 at 01:38:45PM -0700, JohnSuykerbuyk wrote: > Could you provide the URLs? I can't seem to find it. http://lmgtfy.com/?q=github+torvalds > > Thanks > > - John "S" > > -- > View this message in context: http://xen.1045712.n5.nabble.com/git-kernel-org-tp4792977p4795821.html > Sent from the Xen - Dev mailing list archive at Nabble.com. > > _______________________________________________ > Xen-devel mailing list > Xen-devel@lists.xensource.com > http://lists.xensource.com/xen-devel _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel From xen-devel-bounces@lists.xensource.com Mon Sep 12 14:38:45 2011 Return-path: Envelope-to: www-data@lists.xensource.com Delivery-date: Mon, 12 Sep 2011 14:38:45 -0700 Received: from localhost ([127.0.0.1] helo=lists.colo.xensource.com) by lists.xensource.com with esmtp (Exim 4.43) id 1R3EDF-0004W2-HD; Mon, 12 Sep 2011 14:38:45 -0700 Received: from mail174.messagelabs.com ([85.158.138.51]) by lists.xensource.com with esmtp (Exim 4.43) id 1R3ECg-0004Jm-Bp for xen-devel@lists.xensource.com; Mon, 12 Sep 2011 14:38:10 -0700 X-Env-Sender: sven.koehler@gmail.com X-Msg-Ref: server-10.tower-174.messagelabs.com!1315863486!31161924!1 X-Originating-IP: [209.85.214.43] X-StarScan-Version: 6.3.6; banners=-,-,- X-VirusChecked: Checked Received: (qmail 4948 invoked from network); 12 Sep 2011 21:38:07 -0000 Received: from mail-bw0-f43.google.com (HELO mail-bw0-f43.google.com) (209.85.214.43) by server-10.tower-174.messagelabs.com with RC4-SHA encrypted SMTP; 12 Sep 2011 21:38:07 -0000 Received: by bkas6 with SMTP id s6so4630085bka.30 for ; Mon, 12 Sep 2011 14:38:06 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:x-enigmail-version:content-type; bh=5gS9lzU83EU5sGp9e50uYraXlyko36zEykLtdY9U3aY=; b=CXeDgUhcKhvP8Gf+ytKbL1qSHjaBzGsOdNMrTLEadfv+tftiJsTbalEx7FQqbsqsaK pUPZ6nEpZO5rLM4fdVYbpy1+7vy0wSKyb24wwuSGPYXreGnQDQFKAtYfiuu3vheVI4fE /QzQDXm8a3YOByR0ymhi7ewGWoCNVtH/dvOHI= Received: by 10.204.152.66 with SMTP id f2mr204218bkw.63.1315863486803; Mon, 12 Sep 2011 14:38:06 -0700 (PDT) Received: from [10.1.2.24] (31-18-61-177-dynip.superkabel.de [31.18.61.177]) by mx.google.com with ESMTPS id m25sm5734887fam.0.2011.09.12.14.38.04 (version=SSLv3 cipher=OTHER); Mon, 12 Sep 2011 14:38:05 -0700 (PDT) Message-ID: <4E6E7C44.7030809@gmail.com> Date: Mon, 12 Sep 2011 23:40:20 +0200 From: =?ISO-8859-1?Q?Sven_K=F6hler?= User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:6.0) Gecko/20110829 Thunderbird/6.0 MIME-Version: 1.0 To: Konrad Rzeszutek Wilk Subject: Re: [Xen-devel] 3.0.4 and 3.1-rc4 based dom0 won't boot with acpi=off References: <20110911002807.GA9989@oracle.com> <4E6C0473.8090905@gmail.com> <20110912150606.GC15778@oracle.com> In-Reply-To: <20110912150606.GC15778@oracle.com> X-Enigmail-Version: 1.3 Cc: xen-devel@lists.xensource.com X-BeenThere: xen-devel@lists.xensource.com X-Mailman-Version: 2.1.5 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0557448854==" Sender: xen-devel-bounces@lists.xensource.com Errors-To: xen-devel-bounces@lists.xensource.com This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --===============0557448854== Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="------------enig62809DAA6116B28DC1FA90F5" This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enig62809DAA6116B28DC1FA90F5 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable > You could also try on the Xen hypervisor line (Ctlr-A three times) try = the 'R' > and see if it does anything. As long as I have been using Xen, I have never managed to make this work (getting to the hypervisor line by pressing Ctrl-A I mean). I have never seen the prompt, if there is any. Right now, I'm pressing Ctrl-A like a mad man. Nothing happens :-( The key stroke is valid at any time? I'm pressing Ctrl-A-A-A (without releasing the Ctrl) when dom0 has booted. Also tried before dom0 kernel started. Nothing so far :-( Regards, Sven --------------enig62809DAA6116B28DC1FA90F5 Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.17 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAk5ufEQACgkQ7Ww7FjRBE4AfKgCeJmpNL57ZSXu+EQ+zj5cCa8R1 af8AoIYOTh06BzrQ6tslozA5p97a/4X+ =0mB9 -----END PGP SIGNATURE----- --------------enig62809DAA6116B28DC1FA90F5-- --===============0557448854== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel --===============0557448854==-- From xen-devel-bounces@lists.xensource.com Mon Sep 12 14:39:47 2011 Return-path: Envelope-to: www-data@lists.xensource.com Delivery-date: Mon, 12 Sep 2011 14:39:47 -0700 Received: from localhost ([127.0.0.1] helo=lists.colo.xensource.com) by lists.xensource.com with esmtp (Exim 4.43) id 1R3EEE-0004tA-MT; Mon, 12 Sep 2011 14:39:46 -0700 Received: from mail174.messagelabs.com ([85.158.138.51]) by lists.xensource.com with smtp (Exim 4.43) id 1R3EDk-0004gn-9t for xen-devel@lists.xensource.com; Mon, 12 Sep 2011 14:39:16 -0700 X-Env-Sender: ml-xen-devel@hfp.de X-Msg-Ref: server-3.tower-174.messagelabs.com!1315863553!25112493!1 X-Originating-IP: [88.205.101.6] X-StarScan-Version: 6.3.6; banners=-,-,- X-VirusChecked: Checked Received: (qmail 1859 invoked from network); 12 Sep 2011 21:39:13 -0000 Received: from rootsrv.hfp.de (HELO rootsrv.hfp.de) (88.205.101.6) by server-3.tower-174.messagelabs.com with SMTP; 12 Sep 2011 21:39:13 -0000 Received: from localhost (localhost [127.0.0.1]) by rootsrv.hfp.de (Postfix) with ESMTP id 764191A8D39; Mon, 12 Sep 2011 23:39:12 +0200 (CEST) X-Virus-Scanned: amavisd-new/ClamAV at rootsrv.hfp.de Received: from rootsrv.hfp.de ([127.0.0.1]) by localhost (rootsrv.hfp.de [127.0.0.1]) (amavisd-new, port 10026) with ESMTP id CLzUTPtgWfyF; Mon, 12 Sep 2011 23:39:12 +0200 (CEST) Received: from [10.0.0.1] (p5DCB6B55.dip.t-dialin.net [93.203.107.85]) by rootsrv.hfp.de (Postfix) with ESMTPA; Mon, 12 Sep 2011 23:39:12 +0200 (CEST) Message-ID: <4E6E7C01.4020708@hfp.de> Date: Mon, 12 Sep 2011 23:39:13 +0200 From: Andreas Kinzler User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:6.0.1) Gecko/20110830 Thunderbird/6.0.1 MIME-Version: 1.0 To: James Harper , xen-devel@lists.xensource.com Subject: Re: [Xen-devel] RE: Stability report GPLPV 0.11.0.308 References: <4E64A0DF.2070007@hfp.de> <4E64D569.5030607@hfp.de> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: X-BeenThere: xen-devel@lists.xensource.com X-Mailman-Version: 2.1.5 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xensource.com Errors-To: xen-devel-bounces@lists.xensource.com On 06.09.2011 07:21, James Harper wrote: > I actually looked back through the changes and there is still a fix to come - basically > xennet allocates new buffers when it needs them, but never frees them again so if > there is a really big burst of traffic it could end up taking all the available memory. That > could cause the problem you are seeing. I'm a bit busy with some other things at the > moment but I hope to have a fix by the end of the week. I am currently running the torture test on 0.11.0.312 and did not see any increase in usage of kernel memory (uptime is over 7 days now with quite extreme load on net/disk). Anything new about your fix? Regards Andreas _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel From xen-devel-bounces@lists.xensource.com Mon Sep 12 15:49:57 2011 Return-path: Envelope-to: www-data@lists.xensource.com Delivery-date: Mon, 12 Sep 2011 15:49:57 -0700 Received: from localhost ([127.0.0.1] helo=lists.colo.xensource.com) by lists.xensource.com with esmtp (Exim 4.43) id 1R3FK8-0006S0-QD; Mon, 12 Sep 2011 15:49:56 -0700 Received: from mail174.messagelabs.com ([85.158.138.51]) by lists.xensource.com with esmtp (Exim 4.43) id 1R3FIy-0006Er-CI for xen-devel@lists.xensource.com; Mon, 12 Sep 2011 15:48:45 -0700 X-Env-Sender: Ian.Campbell@eu.citrix.com X-Msg-Ref: server-10.tower-174.messagelabs.com!1315867718!31165103!1 X-Originating-IP: [66.165.176.63] X-StarScan-Version: 6.3.6; banners=-,-,- X-VirusChecked: Checked Received: (qmail 30109 invoked from network); 12 Sep 2011 22:48:41 -0000 Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63) by server-10.tower-174.messagelabs.com with RC4-SHA encrypted SMTP; 12 Sep 2011 22:48:41 -0000 X-IronPort-AV: E=Sophos;i="4.68,370,1312171200"; d="scan'208";a="162663794" Received: from ftlpmailmx02.citrite.net ([10.13.107.66]) by FTLPIPO02.CITRIX.COM with ESMTP/TLS/RC4-MD5; 12 Sep 2011 18:48:38 -0400 Received: from [127.0.0.1] (10.80.16.67) by smtprelay.citrix.com (10.13.107.66) with Microsoft SMTP Server id 8.3.137.0; Mon, 12 Sep 2011 18:48:38 -0400 Subject: Re: [Xen-devel] 3.0.4 and 3.1-rc4 based dom0 won't boot with acpi=off From: Ian Campbell To: Sven =?ISO-8859-1?Q?K=F6hler?= Date: Tue, 13 Sep 2011 00:48:37 +0200 In-Reply-To: <4E6E7C44.7030809@gmail.com> References: <20110911002807.GA9989@oracle.com> <4E6C0473.8090905@gmail.com> <20110912150606.GC15778@oracle.com> <4E6E7C44.7030809@gmail.com> Organization: Citrix Systems, Inc. Content-Type: text/plain; charset="UTF-8" X-Mailer: Evolution 3.0.3- Content-Transfer-Encoding: 8bit Message-ID: <1315867718.2892.0.camel@cthulhu.hellion.org.uk> MIME-Version: 1.0 Cc: "xen-devel@lists.xensource.com" , Konrad Rzeszutek Wilk X-BeenThere: xen-devel@lists.xensource.com X-Mailman-Version: 2.1.5 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xensource.com Errors-To: xen-devel-bounces@lists.xensource.com .On Mon, 2011-09-12 at 17:40 -0400, Sven Köhler wrote: > > You could also try on the Xen hypervisor line (Ctlr-A three times) try the 'R' > > and see if it does anything. > > As long as I have been using Xen, I have never managed to make this work > (getting to the hypervisor line by pressing Ctrl-A I mean). I have never > seen the prompt, if there is any. > > Right now, I'm pressing Ctrl-A like a mad man. Nothing happens :-( > > The key stroke is valid at any time? I'm pressing Ctrl-A-A-A (without > releasing the Ctrl) when dom0 has booted. Also tried before dom0 kernel > started. Nothing so far :-( This sequence is only valid on serial console not on VGA console if that's what you are doing. Ian. _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel From xen-devel-bounces@lists.xensource.com Mon Sep 12 16:16:50 2011 Return-path: Envelope-to: www-data@lists.xensource.com Delivery-date: Mon, 12 Sep 2011 16:16:50 -0700 Received: from localhost ([127.0.0.1] helo=lists.colo.xensource.com) by lists.xensource.com with esmtp (Exim 4.43) id 1R3FkA-0007tg-O7; Mon, 12 Sep 2011 16:16:50 -0700 Received: from mail21.messagelabs.com ([85.158.143.35]) by lists.xensource.com with esmtp (Exim 4.43) id 1R3FjP-0007h9-5A for xen-devel@lists.xensource.com; Mon, 12 Sep 2011 16:16:04 -0700 X-Env-Sender: jeremy@goop.org X-Msg-Ref: server-15.tower-21.messagelabs.com!1315869359!50319129!1 X-Originating-IP: [74.207.240.146] X-StarScan-Version: 6.3.6; banners=-,-,- X-VirusChecked: Checked Received: (qmail 9719 invoked from network); 12 Sep 2011 23:16:01 -0000 Received: from claw.goop.org (HELO claw.goop.org) (74.207.240.146) by server-15.tower-21.messagelabs.com with DHE-RSA-AES256-SHA encrypted SMTP; 12 Sep 2011 23:16:01 -0000 Received: from saboo.goop.org (unknown [IPv6:2001:470:1f05:899:34bf:b7ff:fef0:d529]) (Authenticated sender: smtp-saboo) by claw.goop.org (Postfix) with ESMTPSA id 0819BA371; Mon, 12 Sep 2011 16:15:58 -0700 (PDT) Received: from saboo.goop.org (localhost [IPv6:::1]) by saboo.goop.org (Postfix) with ESMTP id 19EE22037E; Mon, 12 Sep 2011 16:15:55 -0700 (PDT) Message-ID: <4E6E92AB.5050504@goop.org> Date: Mon, 12 Sep 2011 16:15:55 -0700 From: Jeremy Fitzhardinge User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:6.0.2) Gecko/20110906 Thunderbird/6.0.2 MIME-Version: 1.0 To: Linus Torvalds X-Enigmail-Version: 1.3.1 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Cc: Avi Kivity , "xen-devel@lists.xensource.com" , Linux Kernel Mailing List , Konrad Rzeszutek Wilk Subject: [Xen-devel] [GIT PULL] Little bugfix to prevent recursion with tracing timestamps X-BeenThere: xen-devel@lists.xensource.com X-Mailman-Version: 2.1.5 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xensource.com Errors-To: xen-devel-bounces@lists.xensource.com -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 Hi Linus, When starting a PV kernel under Xen with full boot-time trace testing enabled, it crashes due to infinite recursion. In principle it could happen at other times too (when just using preempt tracing perhaps?). This fixes it. BTW, I think this same problem also affects KVM. Erm, I'm not sure how to authenticate this github as being really from me; I'm signing the mail with my long-standing pgp key in the hope that it helps... Also, the patch is self-evident. Thanks, J The following changes since commit b6fd41e29dea9c6753b1843a77e50433e6123bcb: Linux 3.1-rc6 (2011-09-12 14:02:02 -0700) are available in the git repository at: git://github.com/jsgf/linux-xen.git upstream/bugfix Jeremy Fitzhardinge (1): xen: use non-tracing preempt in xen_clocksource_read() arch/x86/xen/time.c | 5 +++-- 1 files changed, 3 insertions(+), 2 deletions(-) diff --git a/arch/x86/xen/time.c b/arch/x86/xen/time.c index 5158c50..163b467 100644 - --- a/arch/x86/xen/time.c +++ b/arch/x86/xen/time.c @@ -168,9 +168,10 @@ cycle_t xen_clocksource_read(void) struct pvclock_vcpu_time_info *src; cycle_t ret; - - src = &get_cpu_var(xen_vcpu)->time; + preempt_disable_notrace(); + src = &__get_cpu_var(xen_vcpu)->time; ret = pvclock_clocksource_read(src); - - put_cpu_var(xen_vcpu); + preempt_enable_notrace(); return ret; } -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.11 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iQEkBAEBCAAGBQJObpKlAAoJEAUkni6MUg7HKoYIPjZxR2owmacxLomFAY+3wc0d qgRorBOqTrfs5gF/JmW/I77UnJyqPymhPHn9Mbd5fuxjTLLVmS8UfZvRcz6Rjejy oePhizOqWfEtB8wg1BsOtQ+YxsWIPwphkotedfOwcYczq8CwRKO09EuqA/YsxOcr C20XES5weBck+5KDWNBkprzuPUzo3zZbqFlBEWSTYk9mbQ2ZcEPDxKEUJqzcuQ81 2ue3iCv5XU8jupWrf8W+os1Js1ivgsq4ntH7F7hOv4KShtj7AB9xL5/6oUEwKG59 wTFyZ5Smz3DFfe3tTDBUb06qy/aTj1Lqig/KcR966EhHkjNnloMwn/FGowwkQzT8 JJcReYgXAQ== =5H3T -----END PGP SIGNATURE----- _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel From xen-devel-bounces@lists.xensource.com Mon Sep 12 16:38:12 2011 Return-path: Envelope-to: www-data@lists.xensource.com Delivery-date: Mon, 12 Sep 2011 16:38:12 -0700 Received: from localhost ([127.0.0.1] helo=lists.colo.xensource.com) by lists.xensource.com with esmtp (Exim 4.43) id 1R3G4p-0000IW-7V; Mon, 12 Sep 2011 16:38:11 -0700 Received: from mail27.messagelabs.com ([193.109.254.147]) by lists.xensource.com with esmtp (Exim 4.43) id 1R3G43-00005X-Se for xen-devel@lists.xensource.com; Mon, 12 Sep 2011 16:37:24 -0700 X-Env-Sender: jeremy@goop.org X-Msg-Ref: server-6.tower-27.messagelabs.com!1315870621!48679129!1 X-Originating-IP: [74.207.240.146] X-StarScan-Version: 6.3.6; banners=-,-,- X-VirusChecked: Checked Received: (qmail 28835 invoked from network); 12 Sep 2011 23:37:02 -0000 Received: from claw.goop.org (HELO claw.goop.org) (74.207.240.146) by server-6.tower-27.messagelabs.com with DHE-RSA-AES256-SHA encrypted SMTP; 12 Sep 2011 23:37:02 -0000 Received: from saboo.goop.org (unknown [IPv6:2001:470:1f05:899:34bf:b7ff:fef0:d529]) (Authenticated sender: smtp-saboo) by claw.goop.org (Postfix) with ESMTPSA id 80B6CA384; Mon, 12 Sep 2011 16:37:18 -0700 (PDT) Received: from saboo.goop.org (localhost [IPv6:::1]) by saboo.goop.org (Postfix) with ESMTP id 567B62037E; Mon, 12 Sep 2011 16:37:16 -0700 (PDT) Message-ID: <4E6E97AC.8020707@goop.org> Date: Mon, 12 Sep 2011 16:37:16 -0700 From: Jeremy Fitzhardinge User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:6.0.2) Gecko/20110906 Thunderbird/6.0.2 MIME-Version: 1.0 To: Linus Torvalds References: <4E6E92AB.5050504@goop.org> In-Reply-To: <4E6E92AB.5050504@goop.org> X-Enigmail-Version: 1.3.1 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Cc: Avi Kivity , "xen-devel@lists.xensource.com" , Linux Kernel Mailing List , Konrad Rzeszutek Wilk Subject: [Xen-devel] Re: [GIT PULL] Little bugfix to prevent recursion with tracing timestamps X-BeenThere: xen-devel@lists.xensource.com X-Mailman-Version: 2.1.5 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xensource.com Errors-To: xen-devel-bounces@lists.xensource.com -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 [ Sigh, for some reason that doesn't verify. Let's see if this works. Anyway, I pushed a signed tag "upstream-bugfix-for-linus" on that changeset. - J ] Hi Linus, When starting a PV kernel under Xen with full boot-time trace testing enabled, it crashes due to infinite recursion. In principle it could happen at other times too (when just using preempt tracing perhaps?). This fixes it. BTW, I think this same problem also affects KVM. Erm, I'm not sure how to authenticate this github as being really from me; I'm signing the mail with my long-standing pgp key in the hope that it helps... Also, the patch is self-evident. Thanks, J The following changes since commit b6fd41e29dea9c6753b1843a77e50433e6123bcb: Linux 3.1-rc6 (2011-09-12 14:02:02 -0700) are available in the git repository at: git://github.com/jsgf/linux-xen.git upstream/bugfix Jeremy Fitzhardinge (1): xen: use non-tracing preempt in xen_clocksource_read() arch/x86/xen/time.c | 5 +++-- 1 files changed, 3 insertions(+), 2 deletions(-) diff --git a/arch/x86/xen/time.c b/arch/x86/xen/time.c index 5158c50..163b467 100644 - - --- a/arch/x86/xen/time.c +++ b/arch/x86/xen/time.c @@ -168,9 +168,10 @@ cycle_t xen_clocksource_read(void) struct pvclock_vcpu_time_info *src; cycle_t ret; - - - src = &get_cpu_var(xen_vcpu)->time; + preempt_disable_notrace(); + src = &__get_cpu_var(xen_vcpu)->time; ret = pvclock_clocksource_read(src); - - - put_cpu_var(xen_vcpu); + preempt_enable_notrace(); return ret; } -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.11 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iQEkBAEBCAAGBQJObpesAAoJEAUkni6MUg7HMnAIP0bR68/akTif/RVfis0Cot/a ONlz5GsGGA7AlHfp/l/M8GZo5fUIC7Ja+EqTnpUWMNbubLoe5kALt5k/uQwADtoI cyvi5j2tlXDGDZOgQ900pQQYMBFVwaCm5XwSuDTbysPUx4v7E5Ha/RL2xapbuFnP txCyO62xx4EsKqkupM4qnTCBId6ksRNo9EVESxFzpJk/l0fabTLM98RigA1KJmdo +Rr+1SzfNnNQLLXG48EHITthfYaBOw9jyGanbe5i9Iw79J85vjI5V65TMlDztWaN kyUGiWD9f1i9ixCO31qhszdRire8c2N8hDTTN5z1919Gtlkq93Oj3F8zkUlbapyh tD4e8GObdA== =MA3l -----END PGP SIGNATURE----- _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel From xen-devel-bounces@lists.xensource.com Mon Sep 12 16:47:21 2011 Return-path: Envelope-to: www-data@lists.xensource.com Delivery-date: Mon, 12 Sep 2011 16:47:21 -0700 Received: from localhost ([127.0.0.1] helo=lists.colo.xensource.com) by lists.xensource.com with esmtp (Exim 4.43) id 1R3GDg-0000pT-Pj; Mon, 12 Sep 2011 16:47:20 -0700 Received: from mail27.messagelabs.com ([193.109.254.147]) by lists.xensource.com with esmtp (Exim 4.43) id 1R3GD7-0000cZ-9v for xen-devel@lists.xensource.com; Mon, 12 Sep 2011 16:46:45 -0700 X-Env-Sender: jeremy@goop.org X-Msg-Ref: server-5.tower-27.messagelabs.com!1315871182!44581782!1 X-Originating-IP: [74.207.240.146] X-StarScan-Version: 6.3.6; banners=-,-,- X-VirusChecked: Checked Received: (qmail 32631 invoked from network); 12 Sep 2011 23:46:24 -0000 Received: from claw.goop.org (HELO claw.goop.org) (74.207.240.146) by server-5.tower-27.messagelabs.com with DHE-RSA-AES256-SHA encrypted SMTP; 12 Sep 2011 23:46:24 -0000 Received: from saboo.goop.org (unknown [IPv6:2001:470:1f05:899:34bf:b7ff:fef0:d529]) (Authenticated sender: smtp-saboo) by claw.goop.org (Postfix) with ESMTPSA id 20F1DA396; Mon, 12 Sep 2011 16:46:40 -0700 (PDT) Received: from saboo.goop.org (localhost [IPv6:::1]) by saboo.goop.org (Postfix) with ESMTP id 7967C2037E; Mon, 12 Sep 2011 16:46:34 -0700 (PDT) Message-ID: <4E6E99DA.5060804@goop.org> Date: Mon, 12 Sep 2011 16:46:34 -0700 From: Jeremy Fitzhardinge User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:6.0.2) Gecko/20110906 Thunderbird/6.0.2 MIME-Version: 1.0 To: Ian Jackson , Lars Kurth X-Enigmail-Version: 1.3.1 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Cc: "xen-devel@lists.xensource.com" Subject: [Xen-devel] Xen.org gpg public keys on xen.org X-BeenThere: xen-devel@lists.xensource.com X-Mailman-Version: 2.1.5 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xensource.com Errors-To: xen-devel-bounces@lists.xensource.com Hey all, Did we ever end up publishing the Xen.org gpg keys on the xen.org website? I couldn't find them from a quick look; there's no sign of "pgp@xen.org" or 79BAD9D8. Thanks, J _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel From xen-devel-bounces@lists.xensource.com Mon Sep 12 18:33:12 2011 Return-path: Envelope-to: www-data@lists.xensource.com Delivery-date: Mon, 12 Sep 2011 18:33:12 -0700 Received: from localhost ([127.0.0.1] helo=lists.colo.xensource.com) by lists.xensource.com with esmtp (Exim 4.43) id 1R3Hs8-0005hp-Hv; Mon, 12 Sep 2011 18:33:12 -0700 Received: from mail216.messagelabs.com ([85.158.143.99]) by lists.xensource.com with esmtp (Exim 4.43) id 1R3Hrb-0005V5-DU for xen-devel@lists.xensource.com; Mon, 12 Sep 2011 18:32:39 -0700 X-Env-Sender: 19890121wr@gmail.com X-Msg-Ref: server-14.tower-216.messagelabs.com!1315877555!18029579!1 X-Originating-IP: [209.85.218.43] X-StarScan-Version: 6.3.6; banners=-,-,- X-VirusChecked: Checked Received: (qmail 23524 invoked from network); 13 Sep 2011 01:32:36 -0000 Received: from mail-yi0-f43.google.com (HELO mail-yi0-f43.google.com) (209.85.218.43) by server-14.tower-216.messagelabs.com with RC4-SHA encrypted SMTP; 13 Sep 2011 01:32:36 -0000 Received: by yia27 with SMTP id 27so45262yia.30 for ; Mon, 12 Sep 2011 18:32:35 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=OXt0mgq6/SsR5Kl55VDGzxgtgsmD1+6Lxb/6SiwVn/0=; b=OZGW4B4FGVIDzcYUWlR/4FAzZdtctQII9NxSbit/9Zoo7KeSde/dXKHyvsb3st61v8 fWTTOGRzJxlIPZSdXxtOWTnt6k19DlkYyoiL50RCju5+cWb7Tzic2NrcOLtMnbNTNvNu 7sf8Z6EYzCoMNPRUIP8TYoic5wOiMnQzC/AQ0= MIME-Version: 1.0 Received: by 10.68.15.39 with SMTP id u7mr4692195pbc.476.1315877554561; Mon, 12 Sep 2011 18:32:34 -0700 (PDT) Received: by 10.142.177.7 with HTTP; Mon, 12 Sep 2011 18:32:34 -0700 (PDT) In-Reply-To: <20110912101047.GB79171@ocelot.phlegethon.org> References: <20110912101047.GB79171@ocelot.phlegethon.org> Date: Tue, 13 Sep 2011 09:32:34 +0800 Message-ID: Subject: Re: [Xen-devel] Fwd: about page table From: =?GB2312?B?zuLI8Q==?= <19890121wr@gmail.com> To: Tim Deegan Content-Type: text/plain; charset=ISO-8859-1 Cc: xen-devel@lists.xensource.com X-BeenThere: xen-devel@lists.xensource.com X-Mailman-Version: 2.1.5 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xensource.com Errors-To: xen-devel-bounces@lists.xensource.com Hi, Sorry for my posting question in such a bad manner.Actually I want to rebuild a GuestOS including vcpu and memory , and allow dom0 to modify the memory such as page table.In this way, I can experiment some test such as monitor attack and rebuild the attack for the sake of researching.Back to my problem,I have discover a piece of code in Xen to get the mfn from virtual address inside Guest OS.But when I eager to change the mfn that the entry points to.Something went wrong. /*=============================*/ static unsigned long dbg_pv_va2mfn(dbgva_t vaddr, struct domain *dp, uint64_t pgd3val) { l3_pgentry_t l3e, *l3t; l2_pgentry_t l2e, *l2t; l1_pgentry_t l1e, *l1t; unsigned long cr3 = (pgd3val ? pgd3val : dp->vcpu[0]->arch.cr3); unsigned long mfn = cr3 >> PAGE_SHIFT; DBGP2("vaddr:%lx domid:%d cr3:%lx pgd3:%lx\n", vaddr, dp->domain_id, cr3, pgd3val); if ( pgd3val == 0 ) { l3t = map_domain_page(mfn); l3t += (cr3 & 0xFE0UL) >> 3; l3e = l3t[l3_table_offset(vaddr)]; mfn = l3e_get_pfn(l3e); unmap_domain_page(l3t); if ( !(l3e_get_flags(l3e) & _PAGE_PRESENT) ) return INVALID_MFN; } l2t = map_domain_page(mfn); l2e = l2t[l2_table_offset(vaddr)]; mfn = l2e_get_pfn(l2e); unmap_domain_page(l2t); if ( !(l2e_get_flags(l2e) & _PAGE_PRESENT) || (l2e_get_flags(l2e) & _PAGE_PSE) ) return INVALID_MFN; l1t = map_domain_page(mfn); l1e = l1t[l1_table_offset(vaddr)]; //--------------------------(1) mfn = l1e_get_pfn(l1e); //--------------------------(1) unmap_domain_page(l1t); return mfn_valid(mfn) ? mfn : INVALID_MFN; } For example,what should I do if I want to modify the mfn that l1e entry points to?Seems that changing the value of l1e is not enough.Now I am working through my way to modify do_mmu_update to make it available inside the Xen and use it to modify the page table.Am I in the right path.Thank you for answering it. Thanks 2011/9/12, Tim Deegan : > Hello, > > Please read http://wiki.xen.org/xenwiki/AskingXenDevelQuestions before > posting again; it's pretty unclear from your email what you're trying to > do and how it fails. > > At 17:16 +0800 on 12 Sep (1315847793), ???? wrote: >> Hi,everyone >> I have been using dbg_pv_va2mfn() function to scan PV dom's page >> table.However,when i intended to modify the page table's entry.Something >> went wrong. >> Should I modify the P2M and M2P table,either?But I kind of lose track of >> how >> things work at P2M and M2P table.Can someone tell me something about these >> tables. >> Or can someone can tell me which function can come in handy,or where to >> look >> in. >> I am in the middle of a project that needs to manipulate the page table >> in >> dom. > > OK, I guess from the code below that you want to change the contents of > a PV guest's pagetables from inside Xen? That's not really allowed -- > since PV guests make their own pagetables you need to have the guest > OS's cooperation. > > If you tell us what the project is, and _why_ you want to do this, we > might be able to suggest a better approach. > > Cheers, > > Tim. > >> For example, >> static unsigned long >> dbg_pv_va2mfn(dbgva_t vaddr, struct domain *dp, uint64_t pgd3val) >> { >> l3_pgentry_t l3e, *l3t; >> l2_pgentry_t l2e, *l2t; >> l1_pgentry_t l1e, *l1t; >> unsigned long cr3 = (pgd3val ? pgd3val : dp->vcpu[0]->arch.cr3); >> unsigned long mfn = cr3 >> PAGE_SHIFT; >> >> DBGP2("vaddr:%lx domid:%d cr3:%lx pgd3:%lx\n", vaddr, dp->domain_id, >> cr3, pgd3val); >> >> if ( pgd3val == 0 ) >> { >> l3t = map_domain_page(mfn); >> l3t += (cr3 & 0xFE0UL) >> 3; >> l3e = l3t[l3_table_offset(vaddr)]; >> mfn = l3e_get_pfn(l3e); >> unmap_domain_page(l3t); >> if ( !(l3e_get_flags(l3e) & _PAGE_PRESENT) ) >> return INVALID_MFN; >> } >> >> l2t = map_domain_page(mfn); >> l2e = l2t[l2_table_offset(vaddr)]; >> mfn = l2e_get_pfn(l2e); >> unmap_domain_page(l2t); >> if ( !(l2e_get_flags(l2e) & _PAGE_PRESENT) || >> (l2e_get_flags(l2e) & _PAGE_PSE) ) >> return INVALID_MFN; >> >> l1t = map_domain_page(mfn); >> l1e = >> l1t[l1_table_offset(vaddr)];----------------------------------(1) >> mfn = >> l1e_get_pfn(l1e);----------------------------------------------(2) >> >> unmap_domain_page(l1t); >> >> return mfn_valid(mfn) ? mfn : INVALID_MFN; >> } >> What should i do if i want to change the l1e page table entry.I allocate a >> page using the function alloc_domheap_page,and use l1e_from_page() to >> write >> the l1e entry,but it proved to be wrong,and my system keeps reboot itself. >> Can anyone gives me a hand? >> >> >> Thanks > >> _______________________________________________ >> Xen-devel mailing list >> Xen-devel@lists.xensource.com >> http://lists.xensource.com/xen-devel > > _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel From xen-devel-bounces@lists.xensource.com Mon Sep 12 18:37:49 2011 Return-path: Envelope-to: www-data@lists.xensource.com Delivery-date: Mon, 12 Sep 2011 18:37:49 -0700 Received: from localhost ([127.0.0.1] helo=lists.colo.xensource.com) by lists.xensource.com with esmtp (Exim 4.43) id 1R3Hwb-0006Dh-73; Mon, 12 Sep 2011 18:37:49 -0700 Received: from mail182.messagelabs.com ([85.158.139.83]) by lists.xensource.com with esmtp (Exim 4.43) id 1R3Hvz-00061S-S3 for xen-devel@lists.xensource.com; Mon, 12 Sep 2011 18:37:12 -0700 X-Env-Sender: Ian.Jackson@eu.citrix.com X-Msg-Ref: server-10.tower-182.messagelabs.com!1315877828!18050629!1 X-Originating-IP: [62.200.22.115] X-StarScan-Version: 6.3.6; banners=-,-,- X-VirusChecked: Checked Received: (qmail 4323 invoked from network); 13 Sep 2011 01:37:08 -0000 Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115) by server-10.tower-182.messagelabs.com with RC4-SHA encrypted SMTP; 13 Sep 2011 01:37:08 -0000 X-IronPort-AV: E=Sophos;i="4.68,371,1312156800"; d="scan'208";a="7741835" Received: from lonpmailmx01.citrite.net ([10.30.203.162]) by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5; 13 Sep 2011 01:37:08 +0000 Received: from woking.xci-test.com (10.80.248.135) by smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id 8.3.137.0; Tue, 13 Sep 2011 02:37:08 +0100 Received: from osstest by woking.xci-test.com with local (Exim 4.69) (envelope-from ) id 1R3Hvw-0006mY-1W; Tue, 13 Sep 2011 02:37:08 +0100 To: xen-devel@lists.xensource.com Message-ID: From: xen.org Date: Tue, 13 Sep 2011 02:37:08 +0100 MIME-Version: 1.0 Content-Type: text/plain Cc: ian.jackson@eu.citrix.com Subject: [Xen-devel] [xen-unstable test] 8873: tolerable FAIL X-BeenThere: xen-devel@lists.xensource.com X-Mailman-Version: 2.1.5 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xensource.com Errors-To: xen-devel-bounces@lists.xensource.com flight 8873 xen-unstable real [real] http://www.chiark.greenend.org.uk/~xensrcts/logs/8873/ Failures :-/ but no regressions. Tests which did not succeed, but are not blocking, including regressions (tests previously passed) regarded as allowable: test-amd64-amd64-xl-pcipt-intel 1 xen-build-check(1) blocked n/a test-amd64-i386-rhel6hvm-intel 1 xen-build-check(1) blocked n/a test-i386-i386-pv 1 xen-build-check(1) blocked n/a test-amd64-i386-pv 1 xen-build-check(1) blocked n/a test-amd64-amd64-pv 1 xen-build-check(1) blocked n/a test-i386-i386-xl 1 xen-build-check(1) blocked n/a test-amd64-i386-xl 1 xen-build-check(1) blocked n/a test-amd64-i386-xl-credit2 1 xen-build-check(1) blocked n/a test-amd64-i386-rhel6hvm-amd 1 xen-build-check(1) blocked n/a test-amd64-amd64-pair 1 xen-build-check(1) blocked n/a test-amd64-i386-pair 1 xen-build-check(1) blocked n/a test-i386-i386-pair 1 xen-build-check(1) blocked n/a build-amd64-pvops 4 kernel-build fail like 8872 build-i386-pvops 4 kernel-build fail like 8872 test-amd64-i386-xl-multivcpu 1 xen-build-check(1) blocked n/a test-amd64-amd64-xl-sedf 1 xen-build-check(1) blocked n/a test-amd64-i386-win-vcpus1 1 xen-build-check(1) blocked n/a test-amd64-i386-xl-win-vcpus1 1 xen-build-check(1) blocked n/a test-amd64-amd64-win 1 xen-build-check(1) blocked n/a test-amd64-i386-win 1 xen-build-check(1) blocked n/a test-amd64-amd64-xl-win 1 xen-build-check(1) blocked n/a test-amd64-amd64-xl 1 xen-build-check(1) blocked n/a test-i386-i386-xl-win 1 xen-build-check(1) blocked n/a test-i386-i386-win 1 xen-build-check(1) blocked n/a version targeted for testing: xen 0312575dc35e baseline version: xen 0312575dc35e jobs: build-amd64 pass build-i386 pass build-amd64-oldkern pass build-i386-oldkern pass build-amd64-pvops fail build-i386-pvops fail test-amd64-amd64-xl blocked test-amd64-i386-xl blocked test-i386-i386-xl blocked test-amd64-i386-rhel6hvm-amd blocked test-amd64-i386-xl-credit2 blocked test-amd64-amd64-xl-pcipt-intel blocked test-amd64-i386-rhel6hvm-intel blocked test-amd64-i386-xl-multivcpu blocked test-amd64-amd64-pair blocked test-amd64-i386-pair blocked test-i386-i386-pair blocked test-amd64-amd64-pv blocked test-amd64-i386-pv blocked test-i386-i386-pv blocked test-amd64-amd64-xl-sedf blocked test-amd64-i386-win-vcpus1 blocked test-amd64-i386-xl-win-vcpus1 blocked test-amd64-amd64-win blocked test-amd64-i386-win blocked test-i386-i386-win blocked test-amd64-amd64-xl-win blocked test-i386-i386-xl-win blocked ------------------------------------------------------------ sg-report-flight on woking.cam.xci-test.com logs: /home/xc_osstest/logs images: /home/xc_osstest/images Logs, config files, etc. are available at http://www.chiark.greenend.org.uk/~xensrcts/logs Test harness code can be found at http://xenbits.xensource.com/gitweb?p=osstest.git;a=summary Published tested tree is already up to date. _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel From xen-devel-bounces@lists.xensource.com Mon Sep 12 20:20:30 2011 Return-path: Envelope-to: www-data@lists.xensource.com Delivery-date: Mon, 12 Sep 2011 20:20:30 -0700 Received: from localhost ([127.0.0.1] helo=lists.colo.xensource.com) by lists.xensource.com with esmtp (Exim 4.43) id 1R3JXy-0001EU-Lg; Mon, 12 Sep 2011 20:20:30 -0700 Received: from mail27.messagelabs.com ([193.109.254.147]) by lists.xensource.com with smtp (Exim 4.43) id 1R3JXC-00011t-VP for xen-devel@lists.xensource.com; Mon, 12 Sep 2011 20:19:43 -0700 X-Env-Sender: kevin.tian@intel.com X-Msg-Ref: server-14.tower-27.messagelabs.com!1315883965!35854161!1 X-Originating-IP: [134.134.136.20] X-StarScan-Version: 6.3.6; banners=-,-,- X-VirusChecked: Checked Received: (qmail 18657 invoked from network); 13 Sep 2011 03:19:26 -0000 Received: from mga02.intel.com (HELO mga02.intel.com) (134.134.136.20) by server-14.tower-27.messagelabs.com with SMTP; 13 Sep 2011 03:19:26 -0000 Received: from orsmga002.jf.intel.com ([10.7.209.21]) by orsmga101.jf.intel.com with ESMTP; 12 Sep 2011 20:19:34 -0700 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="4.67,351,1309762800"; d="scan'208";a="47589230" Received: from pgsmsx602.gar.corp.intel.com ([10.221.43.81]) by orsmga002.jf.intel.com with ESMTP; 12 Sep 2011 20:19:33 -0700 Received: from shsmsx601.ccr.corp.intel.com (10.239.4.112) by pgsmsx602.gar.corp.intel.com (10.221.43.81) with Microsoft SMTP Server (TLS) id 8.2.255.0; Tue, 13 Sep 2011 11:18:40 +0800 Received: from shsmsx502.ccr.corp.intel.com ([10.239.4.96]) by shsmsx601.ccr.corp.intel.com ([10.239.4.112]) with mapi; Tue, 13 Sep 2011 11:18:38 +0800 From: "Tian, Kevin" To: Keir Fraser , Andrew Cooper Date: Tue, 13 Sep 2011 11:18:37 +0800 Subject: RE: [Xen-devel] Query about cpuidle Thread-Topic: [Xen-devel] Query about cpuidle Thread-Index: Acxu7wlZP9sSwgg3gkygHpKUqoss2QC0zXAA Message-ID: <625BA99ED14B2D499DC4E29D8138F150632893F44B@shsmsx502.ccr.corp.intel.com> References: <4E6A03FE.8090202@citrix.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "xen-devel@lists.xensource.com" X-BeenThere: xen-devel@lists.xensource.com X-Mailman-Version: 2.1.5 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xensource.com Errors-To: xen-devel-bounces@lists.xensource.com > From: Keir Fraser [mailto:keir.xen@gmail.com] > Sent: Friday, September 09, 2011 8:50 PM >=20 > On 09/09/2011 13:18, "Andrew Cooper" wrote: >=20 > > Hello, > > > > We have recently had a support escalation about Xen-4.1.1 being unable > > to boot on HP BL460c G7 blades. The problem turned out to be a null > > function pointer deference (ns_to_tick in cpu_idle.c) during early boot > > of dom0, in the set_cx_pminfo function. > > > > I applied your patch, changeset 23662:2faba14bac13, about initializing > > default C state information, and this appears to have fixed the problem= . > > > > However, I see in the patch that setting up the function pointers > > (ns_to_tick, tick_to_ns etc) is predicated on the hypercall coming in o= n > > CPU0. >=20 > Firstly, it's predicated on the hypercall addressing CPU0, rather than be= ing > executed on CPU0. Secondly, the cpuidle_init_cpu() functiomn is *also* > called from the CPU-hotplug path in Xen, and is called directly from the > presmp_initcall path for CPU0. I don't know why it is called both on a > hypercall path and on a hotplug path, it seems weird. But anyhow, this me= ans > that the function pointers will guaranteed get set up early during Xen bo= ot? yes. do it in hypercall path is b/c present ACPI processors may not be onli= ne by Xen yet. do it in CPU-hotplug path is b/c we may want to do some resourc= e housekeeping according to CPU-hotplug event, though now only CPU_ONLINE is handled. It's a bit overkilled, but should be ok for saneness reason. Thanks Kevin _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel From xen-devel-bounces@lists.xensource.com Mon Sep 12 20:21:40 2011 Return-path: Envelope-to: www-data@lists.xensource.com Delivery-date: Mon, 12 Sep 2011 20:21:40 -0700 Received: from localhost ([127.0.0.1] helo=lists.colo.xensource.com) by lists.xensource.com with esmtp (Exim 4.43) id 1R3JZ6-0001bn-Mw; Mon, 12 Sep 2011 20:21:40 -0700 Received: from mail216.messagelabs.com ([85.158.143.99]) by lists.xensource.com with smtp (Exim 4.43) id 1R3JXl-00019p-SF for xen-devel@lists.xensource.com; Mon, 12 Sep 2011 20:20:18 -0700 X-Env-Sender: kevin.tian@intel.com X-Msg-Ref: server-6.tower-216.messagelabs.com!1315884014!16760967!1 X-Originating-IP: [134.134.136.24] X-StarScan-Version: 6.3.6; banners=-,-,- X-VirusChecked: Checked Received: (qmail 31797 invoked from network); 13 Sep 2011 03:20:14 -0000 Received: from mga09.intel.com (HELO mga09.intel.com) (134.134.136.24) by server-6.tower-216.messagelabs.com with SMTP; 13 Sep 2011 03:20:14 -0000 Received: from orsmga002.jf.intel.com ([10.7.209.21]) by orsmga102.jf.intel.com with ESMTP; 12 Sep 2011 20:20:13 -0700 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="4.67,351,1309762800"; d="scan'208";a="47589423" Received: from pgsmsx602.gar.corp.intel.com ([10.221.43.81]) by orsmga002.jf.intel.com with ESMTP; 12 Sep 2011 20:20:12 -0700 Received: from pgsmsx103.gar.corp.intel.com (10.221.44.82) by pgsmsx602.gar.corp.intel.com (10.221.43.81) with Microsoft SMTP Server (TLS) id 8.2.255.0; Tue, 13 Sep 2011 11:19:45 +0800 Received: from shsmsx602.ccr.corp.intel.com (10.239.4.104) by PGSMSX103.gar.corp.intel.com (10.221.44.82) with Microsoft SMTP Server (TLS) id 14.1.323.3; Tue, 13 Sep 2011 11:19:44 +0800 Received: from shsmsx502.ccr.corp.intel.com ([10.239.4.96]) by SHSMSX602.ccr.corp.intel.com ([10.239.4.104]) with mapi; Tue, 13 Sep 2011 11:19:13 +0800 From: "Tian, Kevin" To: Andrew Cooper Date: Tue, 13 Sep 2011 11:19:11 +0800 Thread-Topic: Query about cpuidle Thread-Index: Acxu6opoEyAJzQDxSH+ExUnzCqsGFgC1q5TQAACqAaA= Message-ID: <625BA99ED14B2D499DC4E29D8138F150632893F44C@shsmsx502.ccr.corp.intel.com> References: <4E6A03FE.8090202@citrix.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "xen-devel@lists.xensource.com" Subject: [Xen-devel] RE: Query about cpuidle X-BeenThere: xen-devel@lists.xensource.com X-Mailman-Version: 2.1.5 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xensource.com Errors-To: xen-devel-bounces@lists.xensource.com forgot to CC the list > -----Original Message----- > From: Tian, Kevin > Sent: Tuesday, September 13, 2011 11:07 AM > To: 'Andrew Cooper' > Subject: RE: Query about cpuidle >=20 > > From: Andrew Cooper [mailto:andrew.cooper3@citrix.com] > > Sent: Friday, September 09, 2011 8:18 PM > > > > Hello, > > > > We have recently had a support escalation about Xen-4.1.1 being unable > > to boot on HP BL460c G7 blades. The problem turned out to be a null > > function pointer deference (ns_to_tick in cpu_idle.c) during early boot > > of dom0, in the set_cx_pminfo function. >=20 > one possible reason is related to the order of how ACPI processor objects > are found. CPU0 may not be always the 1st item there, and thus the > ns_to_tick is not initialized accordingly. >=20 > you can easily verify this by adding printk in set_cx_pminfo. >=20 > > > > I applied your patch, changeset 23662:2faba14bac13, about initializing > > default C state information, and this appears to have fixed the problem= . >=20 > with this patch function pointers are initialized when Xen is bringing up > CPUs, which happens before dom0 and thus should avoid the problem >=20 > > > > However, I see in the patch that setting up the function pointers > > (ns_to_tick, tick_to_ns etc) is predicated on the hypercall coming in o= n > > CPU0. What guarantees are in place to ensure that these function > > pointers get set up? I cant see anything obvious from the code, but > > have to admit that the null pointer deference appears to have gone away= . >=20 > this is due to the cpu notifier coming in the latter part of the patch. >=20 > having said that, original logic looks error-prone, since there's no > guarantee that cpu0 will be always firstly registered. We should just > look at whether ns_to_tick is NULL, and if yes then do appropriate > initialization at the 1st place, if you don't want to pull the whole 2366= 2 > into your version. >=20 > Thanks > Kevin >=20 _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel From xen-devel-bounces@lists.xensource.com Mon Sep 12 21:10:47 2011 Return-path: Envelope-to: www-data@lists.xensource.com Delivery-date: Mon, 12 Sep 2011 21:10:47 -0700 Received: from localhost ([127.0.0.1] helo=lists.colo.xensource.com) by lists.xensource.com with esmtp (Exim 4.43) id 1R3KKd-0002sv-7D; Mon, 12 Sep 2011 21:10:47 -0700 Received: from mail174.messagelabs.com ([85.158.138.51]) by lists.xensource.com with esmtp (Exim 4.43) id 1R3KJD-0002ft-Jt for xen-devel@lists.xensource.com; Mon, 12 Sep 2011 21:09:34 -0700 X-Env-Sender: dushmanta.mohapatra@gmail.com X-Msg-Ref: server-9.tower-174.messagelabs.com!1315886955!25152959!1 X-Originating-IP: [209.85.216.47] X-StarScan-Version: 6.3.6; banners=-,-,- X-VirusChecked: Checked Received: (qmail 26640 invoked from network); 13 Sep 2011 04:09:16 -0000 Received: from mail-qw0-f47.google.com (HELO mail-qw0-f47.google.com) (209.85.216.47) by server-9.tower-174.messagelabs.com with RC4-SHA encrypted SMTP; 13 Sep 2011 04:09:16 -0000 Received: by qwh5 with SMTP id 5so126702qwh.6 for ; Mon, 12 Sep 2011 21:09:15 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:date:message-id:subject:from:to:content-type; bh=UhvamoldHsnWrReJAudE18xc8Uhzf6hK0A/1afkJ+1s=; b=QMtAboEgCtlQ/RliEet53fjes79duRjlQ2FOETPKmmstVNGHz8eitgZClDiSGHWLPA YWYbwSs997HlEPQtCZuZpU+UJSE3RQhx/u2zoL5KMmnsnu51oYW4twu7mZdbIwOwbP5h sOwdeJbogPgLkurZsXdXiLI0oAzKLMChO+/P8= MIME-Version: 1.0 Received: by 10.229.65.84 with SMTP id h20mr728319qci.52.1315886954896; Mon, 12 Sep 2011 21:09:14 -0700 (PDT) Received: by 10.229.84.76 with HTTP; Mon, 12 Sep 2011 21:09:14 -0700 (PDT) Date: Tue, 13 Sep 2011 00:09:14 -0400 Message-ID: From: Dushmanta Mohapatra To: xen-devel@lists.xensource.com Subject: [Xen-devel] Graphics passthrough related issue X-BeenThere: xen-devel@lists.xensource.com X-Mailman-Version: 2.1.5 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0906142628==" Sender: xen-devel-bounces@lists.xensource.com Errors-To: xen-devel-bounces@lists.xensource.com --===============0906142628== Content-Type: multipart/alternative; boundary=0016e64e91ac82df7b04accace48 --0016e64e91ac82df7b04accace48 Content-Type: text/plain; charset=ISO-8859-1 Hi, I am facing an issue with enabling my graphics passthrough properly in Xen. I am using Xen 4.1.1 and 2.6.32.41 based PVOPS kernel as my Dom0. Machine: core i5 vPro based Thinkpad T 520 laptop. I use Windows 7 and XP as my HVM DomUs. I have an Intel Integrated Graphics Controller. I can pass through the graphics device (using boot time passthrough) and the HVM DomUs boot fine and show me the log in screen. But somehow I lose my control over input devices (mouse/keyboard). My laptop has a PS/2 keypad and I do not know how to pass that through. So instead, I plugin an external keyboard and mouse to the USB slots that are available and pass them through to DomU. But those are not accessible when I boot my DomU in the graphics pass through mode. (If I boot without graphics pass-through mode, then I can pass external keyboard and mouse to the DomUs and they work fine.) I have not applied any patch to the Xen 4.1.1 that I built from source obtained from xen.org and I am not doing any manual device/memory region mapping. I am not sure if I need any patch for the integrated graphics driver that I use. Could any one provide me some input about what might be going wrong for me and how I could solve the issue. I am including the lspci output for reference. If some more information is needed from my side, please let me know. Thanks For enabling graphics passthrough, I hide and passthrough the devices highlighted. root@dm-ThinkPad-T520:~# lspci 00:00.0 Host bridge: Intel Corporation 2nd Generation Core Processor Family DRAM Controller (rev 09) 00:02.0 VGA compatible controller: Intel Corporation 2nd Generation Core Processor Family Integrated Graphics Controller (rev 09) 00:16.0 Communication controller: Intel Corporation 6 Series Chipset Family MEI Controller #1 (rev 04) 00:16.3 Serial controller: Intel Corporation 6 Series Chipset Family KT Controller (rev 04) 00:19.0 Ethernet controller: Intel Corporation 82579LM Gigabit Network Connection (rev 04) 00:1a.0 USB Controller: Intel Corporation 6 Series Chipset Family USB Enhanced Host Controller #2 (rev 04) 00:1b.0 Audio device: Intel Corporation 6 Series Chipset Family High Definition Audio Controller (rev 04) 00:1c.0 PCI bridge: Intel Corporation 6 Series Chipset Family PCI Express Root Port 1 (rev b4) 00:1c.1 PCI bridge: Intel Corporation 6 Series Chipset Family PCI Express Root Port 2 (rev b4) 00:1c.3 PCI bridge: Intel Corporation 6 Series Chipset Family PCI Express Root Port 4 (rev b4) 00:1c.4 PCI bridge: Intel Corporation 6 Series Chipset Family PCI Express Root Port 5 (rev b4) 00:1d.0 USB Controller: Intel Corporation 6 Series Chipset Family USB Enhanced Host Controller #1 (rev 04) 00:1f.0 ISA bridge: Intel Corporation 6 Series Chipset Family LPC Controller (rev 04) 00:1f.2 SATA controller: Intel Corporation 6 Series Chipset Family 6 port SATA AHCI Controller (rev 04) 00:1f.3 SMBus: Intel Corporation 6 Series Chipset Family SMBus Controller (rev 04) 03:00.0 Network controller: Intel Corporation Centrino Advanced-N 6205 (rev 34) 0d:00.0 System peripheral: Ricoh Co Ltd Device e823 (rev 05) 0d:00.3 FireWire (IEEE 1394): Ricoh Co Ltd FireWire Host Controller (rev 04) --0016e64e91ac82df7b04accace48 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
Hi,
=A0
I am facing an issue with enabling my graphics passthrough=20 properly in Xen.

I am using =A0Xen 4.1.1 and 2.6.32.41 based PV= OPS kernel as my Dom0.
Machine:=A0core i5 vPro based Thinkpad T 520 lapt= op.=A0
I use Windows 7 and XP as my HVM DomUs.

I= have an Intel Integrated Graphics Controller.
I can pass through the graphics device (using boot time passthrough) a= nd the HVM DomUs boot fine and show me the log in screen.

But somehow I=A0 lose my control over input devices (mouse/keyboard). = My laptop has a PS/2 keypad and I do not know how to pass that through. So = instead, I plugin an external keyboard and mouse to the USB slots that are = available and pass them through to DomU.

But those are not accessible when I boot my DomU in the graphics pass=20 through mode. (If I boot without graphics pass-through mode,
then I can pass external keyboard and mouse to the DomUs and they work= fine.)

I have not applied any patch to the Xen 4.= 1.1 that I built from source obtained from xen.org and I am not doing any manual device/memory region mapping. I am not=20 sure if I need any patch for the integrated graphics driver that I use.

Could any one provide me some input about what might be= going wrong for me and how I could solve the issue. I am including the lsp= ci output for reference. If some more information is needed from my side, p= lease let me know.

Thanks



For enabling graphics pass= through, I hide and passthrough the devices highlighted.

= root@dm-ThinkPad-T520:~# lspci
00:00.0 Host bridge: Intel Corporation 2n= d Generation Core Processor Family DRAM Controller (rev 09)
00:02.0 VGA compatible=20 controller: Intel Corporation 2nd Generation Core Processor Family=20 Integrated Graphics Controller (rev 09)
00:16.0 Communication controller: Intel Corporation 6 Series Chipset Family= MEI Controller #1 (rev 04)
00:16.3 Serial controller: Intel Corporation= 6 Series Chipset Family KT Controller (rev 04)
00:19.0 Ethernet control= ler: Intel Corporation 82579LM Gigabit Network Connection (rev 04)
00:1a.0 USB Controller: I= ntel Corporation 6 Series Chipset Family USB Enhanced Host Controller #2 (r= ev 04)
00:1b.0 Audio = device: Intel Corporation 6 Series Chipset Family High Definition Audio Con= troller (rev 04)
00:1c.0 PCI bridge: Intel Corporation 6 Series Chipset Family PCI Express R= oot Port 1 (rev b4)
00:1c.1 PCI bridge: Intel Corporation 6 Series Chips= et Family PCI Express Root Port 2 (rev b4)
00:1c.3 PCI bridge: Intel Cor= poration 6 Series Chipset Family PCI Express Root Port 4 (rev b4)
00:1c.4 PCI bridge: Intel Corporation 6 Series Chipset Family PCI Express R= oot Port 5 (rev b4)
00= :1d.0 USB Controller: Intel Corporation 6 Series Chipset Family USB Enhance= d Host Controller #1 (rev 04)
00:1f.0 ISA bridge: Intel Corporation 6 Series Chipset Family LPC Controlle= r (rev 04)
00:1f.2 SATA controller: Intel Corporation 6 Series Chipset F= amily 6 port SATA AHCI Controller (rev 04)
00:1f.3 SMBus: Intel Corporat= ion 6 Series Chipset Family SMBus Controller (rev 04)
03:00.0 Network controller: Intel Corporation Centrino Advanced-N 6205 (rev= 34)
0d:00.0 System peripheral: Ricoh Co Ltd Device e823 (rev 05)
0d:= 00.3 FireWire (IEEE 1394): Ricoh Co Ltd FireWire Host Controller (rev 04)

--0016e64e91ac82df7b04accace48-- --===============0906142628== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel --===============0906142628==-- From xen-devel-bounces@lists.xensource.com Tue Sep 13 01:00:43 2011 Return-path: Envelope-to: www-data@lists.xensource.com Delivery-date: Tue, 13 Sep 2011 01:00:43 -0700 Received: from localhost ([127.0.0.1] helo=lists.colo.xensource.com) by lists.xensource.com with esmtp (Exim 4.43) id 1R3Nv8-0001E8-Qd; Tue, 13 Sep 2011 01:00:42 -0700 Received: from mail21.messagelabs.com ([85.158.143.35]) by lists.xensource.com with esmtp (Exim 4.43) id 1R3NuN-00011J-CO for xen-devel@lists.xensource.com; Tue, 13 Sep 2011 00:59:55 -0700 X-Env-Sender: fbcyborg@gmail.com X-Msg-Ref: server-7.tower-21.messagelabs.com!1315900761!54619527!1 X-Originating-IP: [209.85.212.47] X-StarScan-Version: 6.3.6; banners=-,-,- X-VirusChecked: Checked Received: (qmail 21156 invoked from network); 13 Sep 2011 07:59:22 -0000 Received: from mail-vw0-f47.google.com (HELO mail-vw0-f47.google.com) (209.85.212.47) by server-7.tower-21.messagelabs.com with RC4-SHA encrypted SMTP; 13 Sep 2011 07:59:22 -0000 Received: by vwe42 with SMTP id 42so722559vwe.6 for ; Tue, 13 Sep 2011 00:59:51 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :content-type:content-transfer-encoding; bh=YCC7nlEwxbZEnjOYu2M8o/tAT2w04uhC8+UrRXirqQM=; b=tXxeyk5YoGvPxwHaDlmsnonOvrCNiKcQxbEOQT2J2gPdpg6uPRVvPNWeKIvcun3wGR RVuqenfcCfsSd2JnrrVG9Q8baVNXVuI0yHSGEnSK94ThDTFXjrt/f5DU4BY3uw7dEAMZ PL+81p0+M2I59yHEmhzQV03hA2Y/Adm8Yc2yQ= Received: by 10.52.92.233 with SMTP id cp9mr3201213vdb.513.1315900791095; Tue, 13 Sep 2011 00:59:51 -0700 (PDT) MIME-Version: 1.0 Received: by 10.220.108.72 with HTTP; Tue, 13 Sep 2011 00:59:31 -0700 (PDT) In-Reply-To: <1315827811.597.4.camel@Hronos> References: <1315827811.597.4.camel@Hronos> From: Flavio Date: Tue, 13 Sep 2011 09:59:31 +0200 Message-ID: Subject: Re: [Xen-devel] gentoo cant attach bridge To: xen-devel@lists.xensource.com Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable X-BeenThere: xen-devel@lists.xensource.com X-Mailman-Version: 2.1.5 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xensource.com Errors-To: xen-devel-bounces@lists.xensource.com On 12 September 2011 13:43, Alexey M. wrote: > Hi, i configure xen 4.1.1 on gentoo and configured bridge in this system > xenbr0 Hi! I have configured the bridge xenbr0 for my gentoo too and I don't have this problem. > > brctl show > bridge name bridge id STP enabled interfaces > xenbr0 8000.984be16d4aac yes vlan201 You have vlan201 (?) I use eth0, but this is not so relevant I guess, and I don't use STP. Remember that with the new toolstack xl, the xend daemon is no longer used. Actually, you may see that with the new version of xen-tools the "xend" use flag has been disabled. So, get rid of that now and configure the bridge at system l= evel. This is the content of my /etc/conf.d/net file, to have the bridge ON at startup: config_eth0=3D"null" bridge_xenbr0=3D"eth0" brctl_xenbr0=3D( "setfd 0" "stp off" ) config_xenbr0=3D( "dhcp" ) Then I've put net.xenbr0 in the default runlevel in order to have it up automatically at boot time. > > then chenged: > =A0/etc/xen/xend-config.sxp > (vif-script vif-bridge) > (network-script /bin/true) This is no longer needed. The only bridge settings I've found is in the /etc/xen/xl.conf file. > > cat /etc/xen/guest|grep vif > > vif =3D [ "mac=3D00:16:36:6b:93:ef, bridge=3Dxenbr0" ] > > But: > xl create guest > brctl show > bridge name bridge id STP enabled interfaces > xenbr0 8000.984be16d4aac yes vlan201 > > No any new interfaces. I never see new interfaces there, but the guest always started with the network activated. Now I have other problems which I've posted to this list yesterday, but no replies yet :( In any case, don't forget to migrate to the new toolstack as suggested. Bye --=20 Flavio _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel From xen-devel-bounces@lists.xensource.com Tue Sep 13 01:01:48 2011 Return-path: Envelope-to: www-data@lists.xensource.com Delivery-date: Tue, 13 Sep 2011 01:01:48 -0700 Received: from localhost ([127.0.0.1] helo=lists.colo.xensource.com) by lists.xensource.com with esmtp (Exim 4.43) id 1R3NwC-0001bX-P1; Tue, 13 Sep 2011 01:01:48 -0700 Received: from mail27.messagelabs.com ([193.109.254.147]) by lists.xensource.com with esmtp (Exim 4.43) id 1R3NvF-0001Fb-LV for xen-devel@lists.xensource.com; Tue, 13 Sep 2011 01:00:50 -0700 X-Env-Sender: tim@xen.org X-Msg-Ref: server-11.tower-27.messagelabs.com!1315900839!37165765!1 X-Originating-IP: [81.29.64.94] X-StarScan-Version: 6.3.6; banners=-,-,- X-VirusChecked: Checked Received: (qmail 2933 invoked from network); 13 Sep 2011 08:00:39 -0000 Received: from ocelot.phlegethon.org (HELO mail.phlegethon.org) (81.29.64.94) by server-11.tower-27.messagelabs.com with DHE-RSA-AES256-SHA encrypted SMTP; 13 Sep 2011 08:00:39 -0000 Received: from tjd by mail.phlegethon.org with local (Exim 4.67 (FreeBSD)) (envelope-from ) id 1R3NvB-0001my-Al; Tue, 13 Sep 2011 08:00:45 +0000 Date: Tue, 13 Sep 2011 09:00:45 +0100 From: Tim Deegan To: ???? <19890121wr@gmail.com> Subject: Re: [Xen-devel] Fwd: about page table Message-ID: <20110913080045.GE79171@ocelot.phlegethon.org> References: <20110912101047.GB79171@ocelot.phlegethon.org> Mime-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.4.2.1i Cc: xen-devel@lists.xensource.com X-BeenThere: xen-devel@lists.xensource.com X-Mailman-Version: 2.1.5 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xensource.com Errors-To: xen-devel-bounces@lists.xensource.com Hello, Please don't top-post. At 09:32 +0800 on 13 Sep (1315906354), ???? wrote: > Sorry for my posting question in such a bad manner.Actually I want to > rebuild a GuestOS including vcpu and memory , and allow dom0 to modify > the memory such as page table.In this way, I can experiment some test > such as monitor attack and rebuild the attack for the sake of > researching.Back to my problem,I have discover a piece of code in Xen > to get the mfn from virtual address inside Guest OS.But when I eager > to change the mfn that the entry points to.Something went wrong. What? What went wrong? > /*=============================*/ > static unsigned long > dbg_pv_va2mfn(dbgva_t vaddr, struct domain *dp, uint64_t pgd3val) > { > l3_pgentry_t l3e, *l3t; > l2_pgentry_t l2e, *l2t; > l1_pgentry_t l1e, *l1t; > unsigned long cr3 = (pgd3val ? pgd3val : dp->vcpu[0]->arch.cr3); > unsigned long mfn = cr3 >> PAGE_SHIFT; > > DBGP2("vaddr:%lx domid:%d cr3:%lx pgd3:%lx\n", vaddr, dp->domain_id, > cr3, pgd3val); > > if ( pgd3val == 0 ) > { > l3t = map_domain_page(mfn); > l3t += (cr3 & 0xFE0UL) >> 3; > l3e = l3t[l3_table_offset(vaddr)]; > mfn = l3e_get_pfn(l3e); > unmap_domain_page(l3t); > if ( !(l3e_get_flags(l3e) & _PAGE_PRESENT) ) > return INVALID_MFN; > } > > l2t = map_domain_page(mfn); > l2e = l2t[l2_table_offset(vaddr)]; > mfn = l2e_get_pfn(l2e); > unmap_domain_page(l2t); > if ( !(l2e_get_flags(l2e) & _PAGE_PRESENT) || > (l2e_get_flags(l2e) & _PAGE_PSE) ) > return INVALID_MFN; > > l1t = map_domain_page(mfn); > l1e = l1t[l1_table_offset(vaddr)]; //--------------------------(1) > mfn = l1e_get_pfn(l1e); //--------------------------(1) > unmap_domain_page(l1t); > > return mfn_valid(mfn) ? mfn : INVALID_MFN; > } > > For example,what should I do if I want to modify the mfn that l1e > entry points to?Seems that changing the value of l1e is not enough. Yes, like I said: > > OK, I guess from the code below that you want to change the contents of > > a PV guest's pagetables from inside Xen? That's not really allowed -- > > since PV guests make their own pagetables you need to have the guest > > OS's cooperation. so you can't just batter this guy's pagetables without having him involved - otherwise your guest OS will probably crash in its own reference counting code when it comes to modify its pagetables later. In fact, just changing the MFN will break xen's own reference counting as well. > Now > I am working through my way to modify do_mmu_update to make it > available inside the Xen and use it to modify the page table.Am I in > the right path.Thank you for answering it. That's a better idea but you still have to worry about the guest. If you want to change the VA->MA mapping without the guest seeing what you've done you should turn on shadow pagetables for the guest, and make whatever changes you like there (in _sh_propagate()). The problem with that is that Xen's shadow pagetables don't index by VA, they shadow actual pagetable pages, so (a) if the guest uses the same pagetable page in the mapping of two different VA ranges, your modification will apply to both (Thta's true of the approach you're taking above, as well). (b) it's not always clear which pagetable page maps which VA so it might be tricky to know when to make your changes. Now, if you step back and look at your original problem, I think it might be better to either - have the guest make the pagetables that you wanted in the first place and then just have the PT verification code in 86/mm.c check that it has done the right thing; or - see if you can do what you want in a HVM guest by making changes to the guest-physical-to-machine-physical (p2m) mappings. Cheers, Tim. _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel From xen-devel-bounces@lists.xensource.com Tue Sep 13 01:34:19 2011 Return-path: Envelope-to: www-data@lists.xensource.com Delivery-date: Tue, 13 Sep 2011 01:34:19 -0700 Received: from localhost ([127.0.0.1] helo=lists.colo.xensource.com) by lists.xensource.com with esmtp (Exim 4.43) id 1R3ORf-0002am-4A; Tue, 13 Sep 2011 01:34:19 -0700 Received: from mail27.messagelabs.com ([193.109.254.147]) by lists.xensource.com with esmtp (Exim 4.43) id 1R3OQv-0002OD-IR for xen-devel@lists.xensource.com; Tue, 13 Sep 2011 01:33:34 -0700 X-Env-Sender: jerry87905@gmail.com X-Msg-Ref: server-3.tower-27.messagelabs.com!1315902787!39409620!1 X-Originating-IP: [209.85.212.47] X-StarScan-Version: 6.3.6; banners=-,-,- X-VirusChecked: Checked Received: (qmail 15704 invoked from network); 13 Sep 2011 08:33:08 -0000 Received: from mail-vw0-f47.google.com (HELO mail-vw0-f47.google.com) (209.85.212.47) by server-3.tower-27.messagelabs.com with RC4-SHA encrypted SMTP; 13 Sep 2011 08:33:08 -0000 Received: by vwe42 with SMTP id 42so784656vwe.6 for ; Tue, 13 Sep 2011 01:33:29 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; bh=pgRZuzK9P0lJv6INuA9pisVH1dvDJa3iJ1NYUMariJI=; b=ZjTTIwR66K54JXIcA4L/dtrblbEs0yzeNgA9qGxIg/SqFlG66gUAlqoR43NqdJmgn+ /ptUgibFw+LvxMX1txSZMJ8wd6WfxlnDBDWnowoXN1XwU48jD7RcGw+NlqyYuO/2K1vF L0zisLVbozp3uBNt/cnmO/XTgPZUUkwx9dOmQ= MIME-Version: 1.0 Received: by 10.52.70.47 with SMTP id j15mr2739231vdu.482.1315902807539; Tue, 13 Sep 2011 01:33:27 -0700 (PDT) Received: by 10.52.184.99 with HTTP; Tue, 13 Sep 2011 01:33:27 -0700 (PDT) In-Reply-To: <20110901152534.GA6965@dumpdata.com> References: <20110901152534.GA6965@dumpdata.com> Date: Tue, 13 Sep 2011 16:33:27 +0800 Message-ID: From: Li Dongyang To: Konrad Rzeszutek Wilk Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: xen-devel@lists.xensource.com, owen.smith@citrix.com, JBeulich@novell.com Subject: [Xen-devel] Re: [PATCH V4 2/3] xen-blkfront: teach blkfront driver to handle discard requests X-BeenThere: xen-devel@lists.xensource.com X-Mailman-Version: 2.1.5 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xensource.com Errors-To: xen-devel-bounces@lists.xensource.com Hi, Konrad On Thu, Sep 1, 2011 at 11:25 PM, Konrad Rzeszutek Wilk wrote: > On Thu, Sep 01, 2011 at 06:39:09PM +0800, Li Dongyang wrote: >> The blkfront driver now will read discard related nodes from xenstore, >> and set up the request queue, then we can forward the >> discard requests to backend driver. > > > A better description is as follow: > > xen-blkfront: Handle discard requests. > > =A0 =A0If the backend advertises 'feature-discard', then interrogate > =A0 =A0the backend for alignment, granularity, and max discard block size= . > =A0 =A0Setup the request queue with the appropiate values and send the > =A0 =A0discard operation as required. > > >> >> Signed-off-by: Li Dongyang >> --- >> =A0drivers/block/xen-blkfront.c | =A0111 +++++++++++++++++++++++++++++++= ++--------- >> =A01 files changed, 88 insertions(+), 23 deletions(-) >> >> diff --git a/drivers/block/xen-blkfront.c b/drivers/block/xen-blkfront.c >> index 9ea8c25..86e2c63 100644 >> --- a/drivers/block/xen-blkfront.c >> +++ b/drivers/block/xen-blkfront.c >> @@ -98,6 +98,9 @@ struct blkfront_info >> =A0 =A0 =A0 unsigned long shadow_free; >> =A0 =A0 =A0 unsigned int feature_flush; >> =A0 =A0 =A0 unsigned int flush_op; >> + =A0 =A0 unsigned int feature_discard; >> + =A0 =A0 unsigned int discard_granularity; >> + =A0 =A0 unsigned int discard_alignment; >> =A0 =A0 =A0 int is_ready; >> =A0}; >> >> @@ -302,29 +305,36 @@ static int blkif_queue_request(struct request *req= ) >> =A0 =A0 =A0 =A0 =A0 =A0 =A0 ring_req->operation =3D info->flush_op; >> =A0 =A0 =A0 } >> >> - =A0 =A0 ring_req->nr_segments =3D blk_rq_map_sg(req->q, req, info->sg)= ; >> - =A0 =A0 BUG_ON(ring_req->nr_segments > BLKIF_MAX_SEGMENTS_PER_REQUEST)= ; >> + =A0 =A0 if (unlikely(req->cmd_flags & REQ_DISCARD)) { >> + =A0 =A0 =A0 =A0 =A0 =A0 /* id, sector_number and handle are set above.= */ >> + =A0 =A0 =A0 =A0 =A0 =A0 ring_req->operation =3D BLKIF_OP_DISCARD; >> + =A0 =A0 =A0 =A0 =A0 =A0 ring_req->nr_segments =3D 0; >> + =A0 =A0 =A0 =A0 =A0 =A0 ring_req->u.discard.nr_sectors =3D blk_rq_sect= ors(req); >> + =A0 =A0 } else { >> + =A0 =A0 =A0 =A0 =A0 =A0 ring_req->nr_segments =3D blk_rq_map_sg(req->q= , req, info->sg); >> + =A0 =A0 =A0 =A0 =A0 =A0 BUG_ON(ring_req->nr_segments > BLKIF_MAX_SEGME= NTS_PER_REQUEST); >> >> - =A0 =A0 for_each_sg(info->sg, sg, ring_req->nr_segments, i) { >> - =A0 =A0 =A0 =A0 =A0 =A0 buffer_mfn =3D pfn_to_mfn(page_to_pfn(sg_page(= sg))); >> - =A0 =A0 =A0 =A0 =A0 =A0 fsect =3D sg->offset >> 9; >> - =A0 =A0 =A0 =A0 =A0 =A0 lsect =3D fsect + (sg->length >> 9) - 1; >> - =A0 =A0 =A0 =A0 =A0 =A0 /* install a grant reference. */ >> - =A0 =A0 =A0 =A0 =A0 =A0 ref =3D gnttab_claim_grant_reference(&gref_hea= d); >> - =A0 =A0 =A0 =A0 =A0 =A0 BUG_ON(ref =3D=3D -ENOSPC); >> + =A0 =A0 =A0 =A0 =A0 =A0 for_each_sg(info->sg, sg, ring_req->nr_segment= s, i) { >> + =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 buffer_mfn =3D pfn_to_mfn(page= _to_pfn(sg_page(sg))); >> + =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 fsect =3D sg->offset >> 9; >> + =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 lsect =3D fsect + (sg->length = >> 9) - 1; >> + =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 /* install a grant reference. = */ >> + =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 ref =3D gnttab_claim_grant_ref= erence(&gref_head); >> + =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 BUG_ON(ref =3D=3D -ENOSPC); >> >> - =A0 =A0 =A0 =A0 =A0 =A0 gnttab_grant_foreign_access_ref( >> - =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 ref, >> - =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 info->xbdev->o= therend_id, >> - =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 buffer_mfn, >> - =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 rq_data_dir(re= q) ); >> - >> - =A0 =A0 =A0 =A0 =A0 =A0 info->shadow[id].frame[i] =3D mfn_to_pfn(buffe= r_mfn); >> - =A0 =A0 =A0 =A0 =A0 =A0 ring_req->u.rw.seg[i] =3D >> - =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 (struct blkif_= request_segment) { >> - =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 = =A0 .gref =A0 =A0 =A0 =3D ref, >> - =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 = =A0 .first_sect =3D fsect, >> - =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 = =A0 .last_sect =A0=3D lsect }; >> + =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 gnttab_grant_foreign_access_re= f( >> + =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 = =A0 ref, >> + =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 = =A0 info->xbdev->otherend_id, >> + =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 = =A0 buffer_mfn, >> + =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 = =A0 rq_data_dir(req)); >> + >> + =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 info->shadow[id].frame[i] =3D = mfn_to_pfn(buffer_mfn); >> + =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 ring_req->u.rw.seg[i] =3D >> + =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 = =A0 (struct blkif_request_segment) { >> + =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 = =A0 =A0 =A0 =A0 =A0 .gref =A0 =A0 =A0 =3D ref, >> + =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 = =A0 =A0 =A0 =A0 =A0 .first_sect =3D fsect, >> + =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 = =A0 =A0 =A0 =A0 =A0 .last_sect =A0=3D lsect }; >> + =A0 =A0 =A0 =A0 =A0 =A0 } >> =A0 =A0 =A0 } >> >> =A0 =A0 =A0 info->ring.req_prod_pvt++; >> @@ -399,6 +409,7 @@ wait: >> =A0static int xlvbd_init_blk_queue(struct gendisk *gd, u16 sector_size) >> =A0{ >> =A0 =A0 =A0 struct request_queue *rq; >> + =A0 =A0 struct blkfront_info *info =3D gd->private_data; >> >> =A0 =A0 =A0 rq =3D blk_init_queue(do_blkif_request, &blkif_io_lock); >> =A0 =A0 =A0 if (rq =3D=3D NULL) >> @@ -406,6 +417,13 @@ static int xlvbd_init_blk_queue(struct gendisk *gd,= u16 sector_size) >> >> =A0 =A0 =A0 queue_flag_set_unlocked(QUEUE_FLAG_VIRT, rq); >> >> + =A0 =A0 if (info->feature_discard) { >> + =A0 =A0 =A0 =A0 =A0 =A0 queue_flag_set_unlocked(QUEUE_FLAG_DISCARD, rq= ); >> + =A0 =A0 =A0 =A0 =A0 =A0 blk_queue_max_discard_sectors(rq, get_capacity= (gd)); > > This is not correct. I took a look at the SCSI support for this > ('sd_config_discard') and if you look there carefully you will see that > the value can be 64KB for example. > > You need to provide a mechanism similar to 'discard-*' to fetch that data > from the backend. > >> + =A0 =A0 =A0 =A0 =A0 =A0 rq->limits.discard_granularity =3D info->disca= rd_granularity; >> + =A0 =A0 =A0 =A0 =A0 =A0 rq->limits.discard_alignment =3D info->discard= _alignment; >> + =A0 =A0 } >> + >> =A0 =A0 =A0 /* Hard sector size and max sectors impersonate the equiv. h= ardware. */ >> =A0 =A0 =A0 blk_queue_logical_block_size(rq, sector_size); >> =A0 =A0 =A0 blk_queue_max_hw_sectors(rq, 512); >> @@ -722,6 +740,19 @@ static irqreturn_t blkif_interrupt(int irq, void *d= ev_id) >> >> =A0 =A0 =A0 =A0 =A0 =A0 =A0 error =3D (bret->status =3D=3D BLKIF_RSP_OKA= Y) ? 0 : -EIO; >> =A0 =A0 =A0 =A0 =A0 =A0 =A0 switch (bret->operation) { >> + =A0 =A0 =A0 =A0 =A0 =A0 case BLKIF_OP_DISCARD: >> + =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 if (unlikely(bret->status =3D= =3D BLKIF_RSP_EOPNOTSUPP)) { >> + =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 struct request= _queue *rq =3D info->rq; >> + =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 printk(KERN_WA= RNING "blkfront: %s: discard op failed\n", >> + =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 = =A0 =A0 =A0info->gd->disk_name); >> + =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 error =3D -EOP= NOTSUPP; >> + =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 info->feature_= discard =3D 0; >> + =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 spin_lock(rq->= queue_lock); we should not take the spin_lock here, as the rq->queue_lock is actually blkif_io_lock, we pass the blkif_io_lock to blk_init_queue when we init the queue, and blkif_io_lock has already acquired above in blkif_interrupt(), so we will deadlock here. I'm so sorry if this has already in your tree, I've tested with BLKIF_RSP_ERROR but forgot the EOPNOTSUPP case, I feel like I'm a stupid ass. could u get rid od the spin_lock and spin_unlock below? Thanks Li Dongyang >> + =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 queue_flag_cle= ar(QUEUE_FLAG_DISCARD, rq); >> + =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 spin_unlock(rq= ->queue_lock); >> + =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 } >> + =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 __blk_end_request_all(req, err= or); >> + =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 break; >> =A0 =A0 =A0 =A0 =A0 =A0 =A0 case BLKIF_OP_FLUSH_DISKCACHE: >> =A0 =A0 =A0 =A0 =A0 =A0 =A0 case BLKIF_OP_WRITE_BARRIER: >> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 if (unlikely(bret->status = =3D=3D BLKIF_RSP_EOPNOTSUPP)) { >> @@ -1098,6 +1129,33 @@ blkfront_closing(struct blkfront_info *info) >> =A0 =A0 =A0 bdput(bdev); >> =A0} >> >> +static void blkfront_setup_discard(struct blkfront_info *info) >> +{ >> + =A0 =A0 int err; >> + =A0 =A0 char *type; >> + =A0 =A0 unsigned int discard_granularity; >> + =A0 =A0 unsigned int discard_alignment; >> + >> + =A0 =A0 type =3D xenbus_read(XBT_NIL, info->xbdev->otherend, "type", N= ULL); >> + =A0 =A0 if (IS_ERR(type)) >> + =A0 =A0 =A0 =A0 =A0 =A0 return; >> + >> + =A0 =A0 if (strncmp(type, "phy", 3) =3D=3D 0) { >> + =A0 =A0 =A0 =A0 =A0 =A0 err =3D xenbus_gather(XBT_NIL, info->xbdev->ot= herend, >> + =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 "discard-granularity", "%u", &= discard_granularity, >> + =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 "discard-alignment", "%u", &di= scard_alignment, >> + =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 NULL); >> + =A0 =A0 =A0 =A0 =A0 =A0 if (!err) { >> + =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 info->feature_discard =3D 1; >> + =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 info->discard_granularity =3D = discard_granularity; >> + =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 info->discard_alignment =3D di= scard_alignment; >> + =A0 =A0 =A0 =A0 =A0 =A0 } >> + =A0 =A0 } else if (strncmp(type, "file", 4) =3D=3D 0) >> + =A0 =A0 =A0 =A0 =A0 =A0 info->feature_discard =3D 1; >> + >> + =A0 =A0 kfree(type); >> +} >> + >> =A0/* >> =A0 * Invoked when the backend is finally 'ready' (and has told produced >> =A0 * the details about the physical device - #sectors, size, etc). >> @@ -1108,7 +1166,7 @@ static void blkfront_connect(struct blkfront_info = *info) >> =A0 =A0 =A0 unsigned long sector_size; >> =A0 =A0 =A0 unsigned int binfo; >> =A0 =A0 =A0 int err; >> - =A0 =A0 int barrier, flush; >> + =A0 =A0 int barrier, flush, discard; >> >> =A0 =A0 =A0 switch (info->connected) { >> =A0 =A0 =A0 case BLKIF_STATE_CONNECTED: >> @@ -1178,7 +1236,14 @@ static void blkfront_connect(struct blkfront_info= *info) >> =A0 =A0 =A0 =A0 =A0 =A0 =A0 info->feature_flush =3D REQ_FLUSH; >> =A0 =A0 =A0 =A0 =A0 =A0 =A0 info->flush_op =3D BLKIF_OP_FLUSH_DISKCACHE; >> =A0 =A0 =A0 } >> - >> + >> + =A0 =A0 err =3D xenbus_gather(XBT_NIL, info->xbdev->otherend, >> + =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 "feature-discard", "%d= ", &discard, >> + =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 NULL); >> + >> + =A0 =A0 if (!err && discard) >> + =A0 =A0 =A0 =A0 =A0 =A0 blkfront_setup_discard(info); >> + >> =A0 =A0 =A0 err =3D xlvbd_alloc_gendisk(sectors, info, binfo, sector_siz= e); >> =A0 =A0 =A0 if (err) { >> =A0 =A0 =A0 =A0 =A0 =A0 =A0 xenbus_dev_fatal(info->xbdev, err, "xlvbd_ad= d at %s", >> -- >> 1.7.6 > _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel From xen-devel-bounces@lists.xensource.com Tue Sep 13 01:56:53 2011 Return-path: Envelope-to: www-data@lists.xensource.com Delivery-date: Tue, 13 Sep 2011 01:56:53 -0700 Received: from localhost ([127.0.0.1] helo=lists.colo.xensource.com) by lists.xensource.com with esmtp (Exim 4.43) id 1R3OnU-0003RR-A6; Tue, 13 Sep 2011 01:56:52 -0700 Received: from mail27.messagelabs.com ([193.109.254.147]) by lists.xensource.com with esmtp (Exim 4.43) id 1R3Omi-0003F2-OV; Tue, 13 Sep 2011 01:56:05 -0700 X-Env-Sender: pasik@iki.fi X-Msg-Ref: server-6.tower-27.messagelabs.com!1315904143!48726168!1 X-Originating-IP: [192.89.123.25] X-StarScan-Version: 6.3.6; banners=-,-,- X-VirusChecked: Checked Received: (qmail 7752 invoked from network); 13 Sep 2011 08:55:43 -0000 Received: from smtp.tele.fi (HELO smtp.tele.fi) (192.89.123.25) by server-6.tower-27.messagelabs.com with DHE-RSA-AES256-SHA encrypted SMTP; 13 Sep 2011 08:55:43 -0000 X-Originating-Ip: [194.89.68.22] Received: from ydin.reaktio.net (reaktio.net [194.89.68.22]) by smtp.tele.fi (Postfix) with ESMTP id 327D92062; Tue, 13 Sep 2011 11:56:00 +0300 (EEST) Received: by ydin.reaktio.net (Postfix, from userid 1001) id 1769A20059; Tue, 13 Sep 2011 11:56:00 +0300 (EEST) Date: Tue, 13 Sep 2011 11:55:59 +0300 From: Pasi =?iso-8859-1?Q?K=E4rkk=E4inen?= To: jim burns Message-ID: <20110913085559.GG12984@reaktio.net> References: <201107231426.56811.jim_burn@bellsouth.net> <13293012.CAopQqStiY@dell4550> <20110912073623.GF12984@reaktio.net> <1342436.B0x3ddQn4U@dell4550> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <1342436.B0x3ddQn4U@dell4550> User-Agent: Mutt/1.5.18 (2008-05-17) Cc: Todd Deshane , xen-devel@lists.xensource.com, xen-users@lists.xensource.com, Fedora Xen List Subject: [Xen-devel] Re: [Xen-users] Re: Continuing BUG:-iness booting Fedora Rawhide 3.1.0-rc's (was Summary: Experiences setting up a debug serial port) X-BeenThere: xen-devel@lists.xensource.com X-Mailman-Version: 2.1.5 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xensource.com Errors-To: xen-devel-bounces@lists.xensource.com On Mon, Sep 12, 2011 at 04:07:21PM -0400, jim burns wrote: > On Mon September 12 2011, 10:36:23 AM, Pasi Kärkkäinen wrote: > > > Sure, thanx, attached. Do you need a debug log also (initcall_debug > > > debug loglevel=10)? > > > > > > > Sure, it doesn't hurt.. > > I'll get it to you in a couple of days. > Ok, thanks! also: I assume you won't get any BUGs when booting the same kernel on baremetal/native? > > > The last four BUG:s (from Sep 8 17:12:20 on) were from starting a winxp > > > domu (first 3 BUG:s), and destroying it at grub (the last BUG:). > > > > Ok, so there are BUGs when booting up, and also when starting HVM guests. > > Right, from Sep 8, 17:12 on. The 'comm:'s referenced are xenstored (2x) and > qemu-dm (1x) when starting the guest (as far as grub), and xenconsoled when > 'xm destroy'-ing it. > > Thanx for your interest. > -- Pasi _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel From xen-devel-bounces@lists.xensource.com Tue Sep 13 02:03:54 2011 Return-path: Envelope-to: www-data@lists.xensource.com Delivery-date: Tue, 13 Sep 2011 02:03:54 -0700 Received: from localhost ([127.0.0.1] helo=lists.colo.xensource.com) by lists.xensource.com with esmtp (Exim 4.43) id 1R3OuH-0004bK-M1; Tue, 13 Sep 2011 02:03:53 -0700 Received: from mail27.messagelabs.com ([193.109.254.147]) by lists.xensource.com with esmtp (Exim 4.43) id 1R3OpQ-0003pl-Rb for xen-devel@lists.xensource.com; Tue, 13 Sep 2011 01:58:53 -0700 X-Env-Sender: fbcyborg@gmail.com X-Msg-Ref: server-15.tower-27.messagelabs.com!1315904306!48526200!1 X-Originating-IP: [209.85.212.47] X-StarScan-Version: 6.3.6; banners=-,-,- X-VirusChecked: Checked Received: (qmail 21330 invoked from network); 13 Sep 2011 08:58:27 -0000 Received: from mail-vw0-f47.google.com (HELO mail-vw0-f47.google.com) (209.85.212.47) by server-15.tower-27.messagelabs.com with RC4-SHA encrypted SMTP; 13 Sep 2011 08:58:27 -0000 Received: by vwe42 with SMTP id 42so828919vwe.6 for ; Tue, 13 Sep 2011 01:58:34 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :content-type; bh=hTMoHNrSme8BHZCZgPXSRWXp3oiSteONBl7IgEtSzd8=; b=gOTMZyt5VsHD0iHMzGS0kH7uLB8clxi/B8T6tcK+3EseRFD4ycDO3K87fK+BQcL0eZ FWsqgmJ53NILu0+DKEOvXOQCP5wPu6aqa4/wngJj+8S8VbzrBWf4hHr3kAnLP0r5xeOj wiJgSTlA3unOiAiVnpXepFghOTOT9WVrZsIQg= Received: by 10.52.92.233 with SMTP id cp9mr3253148vdb.513.1315904314047; Tue, 13 Sep 2011 01:58:34 -0700 (PDT) MIME-Version: 1.0 Received: by 10.220.108.72 with HTTP; Tue, 13 Sep 2011 01:58:14 -0700 (PDT) In-Reply-To: References: From: Flavio Date: Tue, 13 Sep 2011 10:58:14 +0200 Message-ID: To: xen-devel Content-Type: text/plain; charset=ISO-8859-1 Subject: [Xen-devel] Help with the migration to XEN-4.1 please X-BeenThere: xen-devel@lists.xensource.com X-Mailman-Version: 2.1.5 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xensource.com Errors-To: xen-devel-bounces@lists.xensource.com Hello, I recently installed XEN on my Gentoo Linux that I use mainly as a Desktop and I had to switch from xm to xl tool stack. Since also the gentoo-sources support XEN natively I installed XEN on my Desktop distribution too. Well, I started installing XEN as usual, and I was using it only with the xm tool stack. Now I read about the migration to the new toolstack at http://wiki.xensource.com/xenwiki/MigrationGuideToXen4.1%2B but I have some problem and some question to do. First of all, let me list my environment: OS: Gentoo Linux 10.0 kernel: gentoo-sources-3.0.4 arch x86_64 app-emulation/xen-4.1.1-r1 app-emulation/xen-tools-4.1.1-r3 with USE flags: "hvm ioemu" I also completed the following checklist: - Configure your host networking using the configuration tools provided by your distribution. - Remove any python code from domU configuration files. - Disable xend startup script (it doesn't exist anymore) - Use xl command instead of xm (xm doesn't exist anymore) 1) Now the xend initscript has been removed. Well, I had some domain registered with the command 'xm new vm_name.cfg'. Actually, performing a "xm list" it was showing them in the list of the domains after the dom0. Now that xend has been removed, it is no longer running and 'xl list' doesn't show any domU in the list. How does it work now? I tried to put the vm configuration file in /etc/xen/auto but in this way it starts the vm and not simply it adds to the xen domain store, letting me decide if starting the vm or not. I was looking for the analogue command as "xm new config_file.cfg" in xl if exists. 2) If I try to run a gentoo linux guest (for instance) running 'xl vm_config_file.cfg -c' I get the following error: xenconsole: Could not read tty from store: No such file or directory But the vm starts even if the networking doesn't work now, of course. I've already searched and found several results on Google but the problem is still there. :( 3) the network for the guest OS doesn't work, even the xenbr0 is up and the vm configuration file explicitly says it has to use that bridge. Furthermore, due to the error at point 2, I can't see anything in the VM. I also tried to add the following line in the /etc/xen/xl.conf but the network doesn't work anyway: vifscript="vif-bridge" 4) xl shutdown seems to be not working. I have to destroy the VM in order to have it powered off. Can somebody help me to correct these problems please? -- Flavio _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel From xen-devel-bounces@lists.xensource.com Tue Sep 13 02:10:25 2011 Return-path: Envelope-to: www-data@lists.xensource.com Delivery-date: Tue, 13 Sep 2011 02:10:25 -0700 Received: from localhost ([127.0.0.1] helo=lists.colo.xensource.com) by lists.xensource.com with esmtp (Exim 4.43) id 1R3P0a-00053l-VE; Tue, 13 Sep 2011 02:10:25 -0700 Received: from mail174.messagelabs.com ([85.158.138.51]) by lists.xensource.com with smtp (Exim 4.43) id 1R3Oz4-0004qD-Mt for xen-devel@lists.xensource.com; Tue, 13 Sep 2011 02:08:53 -0700 X-Env-Sender: imammedo@redhat.com X-Msg-Ref: server-9.tower-174.messagelabs.com!1315904926!25188086!1 X-Originating-IP: [209.132.183.28] X-StarScan-Version: 6.3.6; banners=-,-,- X-VirusChecked: Checked Received: (qmail 11715 invoked from network); 13 Sep 2011 09:08:46 -0000 Received: from mx1.redhat.com (HELO mx1.redhat.com) (209.132.183.28) by server-9.tower-174.messagelabs.com with SMTP; 13 Sep 2011 09:08:46 -0000 Received: from int-mx10.intmail.prod.int.phx2.redhat.com (int-mx10.intmail.prod.int.phx2.redhat.com [10.5.11.23]) by mx1.redhat.com (8.14.4/8.14.4) with ESMTP id p8D98jp5014793 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK) for ; Tue, 13 Sep 2011 05:08:45 -0400 Received: from nial.brq.redhat.com (dhcp-1-247.brq.redhat.com [10.34.1.247]) by int-mx10.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP id p8D98itZ027401 for ; Tue, 13 Sep 2011 05:08:44 -0400 From: Igor Mammedov To: xen-devel@lists.xensource.com Date: Tue, 13 Sep 2011 11:08:40 +0200 Message-Id: <1315904920-12533-1-git-send-email-imammedo@redhat.com> X-Scanned-By: MIMEDefang 2.68 on 10.5.11.23 Subject: [Xen-devel] xen: Clear IRQ_GUEST bit from irq_desc status if its action is NULL X-BeenThere: xen-devel@lists.xensource.com X-Mailman-Version: 2.1.5 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xensource.com Errors-To: xen-devel-bounces@lists.xensource.com On a system with Intel C600 series Patsburg SAS controller if following command are executed: rmmod isci modprobe isci the host will crash in pirq_guest_bind in attempt to dereference NULL action pointer. This is caused by isci driver which does not cleanup irq properly, removing device first and then os tries to unbind its irqs afterwards. c/s 20093 and 20844 fixed host crashes when removing isci module. However in dynamic_irq_cleanup 'action' field of irq_desc is set to NULL but IRQ_GUEST flag in 'status' field is not cleared. So on next attempt to bind pirq (modprobe isci) with IRQ_GUEST flag set, branch if ( !(desc->status & IRQ_GUEST) ) is skipped and host ends up with dereferencing NULL pointer 'action'. Second hunk is a bit of code cleanup, removing duplicate code and keeps IRQ_GUEST flag reset at one place. Please review. Signed-off-by: Igor Mammedov diff -r 0312575dc35e xen/arch/x86/irq.c --- a/xen/arch/x86/irq.c Thu Sep 08 15:13:06 2011 +0100 +++ b/xen/arch/x86/irq.c Tue Sep 13 09:27:12 2011 +0200 @@ -1472,6 +1472,7 @@ static irq_guest_action_t *__pirq_guest_ if ( unlikely(action == NULL) ) { + desc->status &= ~IRQ_GUEST; dprintk(XENLOG_G_WARNING, "dom%d: pirq %d: desc->action is NULL!\n", d->domain_id, pirq->pirq); return NULL; @@ -1598,17 +1599,14 @@ static int pirq_guest_force_unbind(struc action = (irq_guest_action_t *)desc->action; if ( unlikely(action == NULL) ) - { - dprintk(XENLOG_G_WARNING, "dom%d: pirq %d: desc->action is NULL!\n", - d->domain_id, pirq->pirq); - goto out; - } + goto unbind; for ( i = 0; (i < action->nr_guests) && (action->guest[i] != d); i++ ) continue; if ( i == action->nr_guests ) goto out; + unbind: bound = 1; oldaction = __pirq_guest_unbind(d, pirq, desc); _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel From xen-devel-bounces@lists.xensource.com Tue Sep 13 02:13:16 2011 Return-path: Envelope-to: www-data@lists.xensource.com Delivery-date: Tue, 13 Sep 2011 02:13:16 -0700 Received: from localhost ([127.0.0.1] helo=lists.colo.xensource.com) by lists.xensource.com with esmtp (Exim 4.43) id 1R3P3M-0005TH-MT; Tue, 13 Sep 2011 02:13:16 -0700 Received: from mail216.messagelabs.com ([85.158.143.99]) by lists.xensource.com with esmtp (Exim 4.43) id 1R3P2k-0005GY-Ob for xen-devel@lists.xensource.com; Tue, 13 Sep 2011 02:12:39 -0700 X-Env-Sender: dunlapg@gmail.com X-Msg-Ref: server-7.tower-216.messagelabs.com!1315905155!18066148!1 X-Originating-IP: [74.125.82.43] X-StarScan-Version: 6.3.6; banners=-,-,- X-VirusChecked: Checked Received: (qmail 12856 invoked from network); 13 Sep 2011 09:12:35 -0000 Received: from mail-ww0-f43.google.com (HELO mail-ww0-f43.google.com) (74.125.82.43) by server-7.tower-216.messagelabs.com with RC4-SHA encrypted SMTP; 13 Sep 2011 09:12:35 -0000 Received: by wwf27 with SMTP id 27so333010wwf.24 for ; Tue, 13 Sep 2011 02:12:35 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=Lk2Bt2Up+esLJasLYa80hryCjC0YNVF/Sej02c8gnx0=; b=b+UIcUv0kWbDgPTkegLEygBWKOEAy3CNXHdLDInYa9/iRsHbEn2zZf9IFAuproWR8P 6qM+S8KEJfouHQXfpK1OrQf3uCv5WraFZGI2Q5hj0Q1vUKlZ3wX4ptX4pZRMDQxTezVz iPVxFDpPCD+UnogkGIPKhpsY8nZHdUzt3CNvY= MIME-Version: 1.0 Received: by 10.216.131.39 with SMTP id l39mr2668754wei.39.1315905155488; Tue, 13 Sep 2011 02:12:35 -0700 (PDT) Received: by 10.216.176.81 with HTTP; Tue, 13 Sep 2011 02:12:35 -0700 (PDT) In-Reply-To: References: Date: Tue, 13 Sep 2011 10:12:35 +0100 X-Google-Sender-Auth: yao2zHWGm1G6MSbYlFfQvO1DRgM Message-ID: Subject: Re: [Xen-devel] [PATCH] xen, vtd: Fix device check for devices behind PCIe-to-PCI bridges From: George Dunlap To: xen-devel@lists.xensource.com Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: Keir Fraser X-BeenThere: xen-devel@lists.xensource.com X-Mailman-Version: 2.1.5 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xensource.com Errors-To: xen-devel-bounces@lists.xensource.com So what was the verdict on this one? Is someone going to commit to doing a "fake pdev" thing? If that's not going to happen before the 4.2 release, I suggest we take this patch in the mean time. -George On Thu, Sep 1, 2011 at 3:20 PM, George Dunlap wrote: > On some systems, requests devices behind a PCIe-to-PCI bridge all > appear to the IOMMU as though they come from from slot 0, function > 0 on that device; so the mapping code much punch a hole for X:0.0 > in the IOMMU for such devices. =A0When punching the hole, if that device > has already been mapped once, we simply need to check ownership to > make sure it's legal. =A0To do so, domain_context_mapping_one() will look > up the device for the mapping with pci_get_pdev() and look for the owner. > > However, if there is no device in X:0.0, this look up will fail. > > Rather than returning -ENODEV in this situation (causing a failure in > mapping the device), try to get the domain ownership from the iommu conte= xt > mapping itself. > > Signed-off-by: George Dunlap > > diff -r 4a4882df5649 -r ede81b0552be xen/drivers/passthrough/vtd/iommu.c > --- a/xen/drivers/passthrough/vtd/iommu.c =A0 =A0 =A0 Wed Aug 31 15:23:49= 2011 +0100 > +++ b/xen/drivers/passthrough/vtd/iommu.c =A0 =A0 =A0 Thu Sep 01 15:18:18= 2011 +0100 > @@ -113,6 +113,27 @@ static int context_set_domain_id(struct > =A0 =A0 return 0; > =A0} > > +static int context_get_domain_id(struct context_entry *context, > + =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 struct = iommu *iommu) > +{ > + =A0 =A0unsigned long dom_index, nr_dom; > + =A0 =A0int domid =3D -1; > + > + =A0 =A0if (iommu && context) > + =A0 =A0{ > + =A0 =A0 =A0 =A0nr_dom =3D cap_ndoms(iommu->cap); > + > + =A0 =A0 =A0 =A0dom_index =3D context_domain_id(*context); > + > + =A0 =A0 =A0 =A0if ( dom_index < nr_dom && iommu->domid_map) > + =A0 =A0 =A0 =A0 =A0 =A0domid =3D iommu->domid_map[dom_index]; > + =A0 =A0 =A0 =A0else > + =A0 =A0 =A0 =A0 =A0 =A0dprintk(XENLOG_DEBUG VTDPREFIX, "%s: dom_index %= lu exceeds nr_dom %lu or iommu has no domid_map\n", > + =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0__func__, dom_index, nr_dom); > + =A0 =A0} > + =A0 =A0return domid; > +} > + > =A0static struct intel_iommu *__init alloc_intel_iommu(void) > =A0{ > =A0 =A0 struct intel_iommu *intel; > @@ -1237,7 +1258,6 @@ int domain_context_mapping_one( > =A0 =A0 struct hvm_iommu *hd =3D domain_hvm_iommu(domain); > =A0 =A0 struct context_entry *context, *context_entries; > =A0 =A0 u64 maddr, pgd_maddr; > - =A0 =A0struct pci_dev *pdev =3D NULL; > =A0 =A0 int agaw; > > =A0 =A0 ASSERT(spin_is_locked(&pcidevs_lock)); > @@ -1249,12 +1269,45 @@ int domain_context_mapping_one( > =A0 =A0 if ( context_present(*context) ) > =A0 =A0 { > =A0 =A0 =A0 =A0 int res =3D 0; > + =A0 =A0 =A0 =A0struct pci_dev *pdev =3D NULL; > > + =A0 =A0 =A0 =A0/* First try to get domain ownership from device structu= re. =A0If that's > + =A0 =A0 =A0 =A0 * not available, try to read it from the context itself= . */ > =A0 =A0 =A0 =A0 pdev =3D pci_get_pdev(bus, devfn); > - =A0 =A0 =A0 =A0if (!pdev) > - =A0 =A0 =A0 =A0 =A0 =A0res =3D -ENODEV; > - =A0 =A0 =A0 =A0else if (pdev->domain !=3D domain) > - =A0 =A0 =A0 =A0 =A0 =A0res =3D -EINVAL; > + =A0 =A0 =A0 =A0if ( pdev ) > + =A0 =A0 =A0 =A0{ > + =A0 =A0 =A0 =A0 =A0 =A0if ( pdev->domain !=3D domain ) > + =A0 =A0 =A0 =A0 =A0 =A0{ > + =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0dprintk(XENLOG_INFO VTDPREFIX, "d%d: bdf= =3D %x:%x.%x owned by d%d!", > + =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0domain->domain_id, > + =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0bus, PCI_SLOT(devfn), PC= I_FUNC(devfn), > + =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0(pdev->domain) > + =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0? pdev->domain->domain_i= d : -1); > + =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0res =3D -EINVAL; > + =A0 =A0 =A0 =A0 =A0 =A0} > + =A0 =A0 =A0 =A0} > + =A0 =A0 =A0 =A0else > + =A0 =A0 =A0 =A0{ > + =A0 =A0 =A0 =A0 =A0 =A0int cdomain; > + =A0 =A0 =A0 =A0 =A0 =A0cdomain =3D context_get_domain_id(context, iommu= ); > + > + =A0 =A0 =A0 =A0 =A0 =A0if ( cdomain < 0 ) > + =A0 =A0 =A0 =A0 =A0 =A0{ > + =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0dprintk(VTDPREFIX, "d%d: bdf =3D %x:%x.%= x mapped, but can't find owner!\n", > + =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0domain->domain_id, > + =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0bus, PCI_SLOT(devfn), PC= I_FUNC(devfn)); > + =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0res =3D -EINVAL; > + =A0 =A0 =A0 =A0 =A0 =A0} > + =A0 =A0 =A0 =A0 =A0 =A0else if ( cdomain !=3D domain->domain_id ) > + =A0 =A0 =A0 =A0 =A0 =A0{ > + =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0dprintk(XENLOG_INFO VTDPREFIX, "d%d: bdf= =3D %x:%x.%x already mapped to d%d!", > + =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0domain->domain_id, > + =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0bus, PCI_SLOT(devfn), PC= I_FUNC(devfn), > + =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0cdomain); > + =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0res =3D -EINVAL; > + =A0 =A0 =A0 =A0 =A0 =A0} > + =A0 =A0 =A0 =A0} > + > =A0 =A0 =A0 =A0 unmap_vtd_domain_page(context_entries); > =A0 =A0 =A0 =A0 spin_unlock(&iommu->lock); > =A0 =A0 =A0 =A0 return res; > > _______________________________________________ > Xen-devel mailing list > Xen-devel@lists.xensource.com > http://lists.xensource.com/xen-devel > _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel From xen-devel-bounces@lists.xensource.com Tue Sep 13 02:26:08 2011 Return-path: Envelope-to: www-data@lists.xensource.com Delivery-date: Tue, 13 Sep 2011 02:26:08 -0700 Received: from localhost ([127.0.0.1] helo=lists.colo.xensource.com) by lists.xensource.com with esmtp (Exim 4.43) id 1R3PFo-00069o-Kl; Tue, 13 Sep 2011 02:26:08 -0700 Received: from mail174.messagelabs.com ([85.158.138.51]) by lists.xensource.com with esmtp (Exim 4.43) id 1R3PF1-0005wr-1Q for xen-devel@lists.xensource.com; Tue, 13 Sep 2011 02:25:19 -0700 X-Env-Sender: dunlapg@gmail.com X-Msg-Ref: server-2.tower-174.messagelabs.com!1315905911!31227626!1 X-Originating-IP: [74.125.82.171] X-StarScan-Version: 6.3.6; banners=-,-,- X-VirusChecked: Checked Received: (qmail 9854 invoked from network); 13 Sep 2011 09:25:15 -0000 Received: from mail-wy0-f171.google.com (HELO mail-wy0-f171.google.com) (74.125.82.171) by server-2.tower-174.messagelabs.com with RC4-SHA encrypted SMTP; 13 Sep 2011 09:25:15 -0000 Received: by wyh13 with SMTP id 13so367258wyh.30 for ; Tue, 13 Sep 2011 02:25:08 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=Q1koB7PGsHHlofrkmZsWbFGzlZDfuFmT5TOEb7m9Sxc=; b=DworvN280Rxoh2ozNOvIn6nLiE+qvb3PEad6ghyBYm0UpfyxglGrHI+6KFe4btP4tQ Nm6zW3aqnOSa7UMBe5/s116L1O+frwS239Uj6etOVmE08ZBcEVviGtfZr5FKFmTg/2C3 LDCvqBUsF2LwMDUJCIdwdy3THj4l1WE+KM0uE= MIME-Version: 1.0 Received: by 10.216.131.39 with SMTP id l39mr2684424wei.39.1315905908086; Tue, 13 Sep 2011 02:25:08 -0700 (PDT) Received: by 10.216.176.81 with HTTP; Tue, 13 Sep 2011 02:25:07 -0700 (PDT) In-Reply-To: <782284c5b1bccc4f1acf.1314891026@elijah> References: <782284c5b1bccc4f1acf.1314891026@elijah> Date: Tue, 13 Sep 2011 10:25:07 +0100 X-Google-Sender-Auth: PSKNEkdAjv5DS2mN5EmSzz7VIy8 Message-ID: Subject: Re: [Xen-devel] [PATCH] xen,credit1: Add variable timeslice From: George Dunlap To: xen-devel@lists.xensource.com Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: george.dunlap@eu.citrix.com, Tim Deegan , Keir Fraser X-BeenThere: xen-devel@lists.xensource.com X-Mailman-Version: 2.1.5 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xensource.com Errors-To: xen-devel-bounces@lists.xensource.com Ping? On Thu, Sep 1, 2011 at 4:30 PM, George Dunlap wrote: > Add a xen command-line parameter, sched_credit_tslice_ms, > to set the timeslice of the credit1 scheduler. > > Signed-off-by: George Dunlap > > diff -r 4a4882df5649 -r 782284c5b1bc xen/common/sched_credit.c > --- a/xen/common/sched_credit.c Wed Aug 31 15:23:49 2011 +0100 > +++ b/xen/common/sched_credit.c Thu Sep 01 16:29:50 2011 +0100 > @@ -41,15 +41,9 @@ > =A0*/ > =A0#define CSCHED_DEFAULT_WEIGHT =A0 =A0 =A0 256 > =A0#define CSCHED_TICKS_PER_TSLICE =A0 =A0 3 > -#define CSCHED_TICKS_PER_ACCT =A0 =A0 =A0 3 > -#define CSCHED_MSECS_PER_TICK =A0 =A0 =A0 10 > -#define CSCHED_MSECS_PER_TSLICE =A0 =A0 \ > - =A0 =A0(CSCHED_MSECS_PER_TICK * CSCHED_TICKS_PER_TSLICE) > +/* Default timeslice: 30ms */ > +#define CSCHED_DEFAULT_TSLICE_MS =A0 =A030 > =A0#define CSCHED_CREDITS_PER_MSEC =A0 =A0 10 > -#define CSCHED_CREDITS_PER_TSLICE =A0 \ > - =A0 =A0(CSCHED_CREDITS_PER_MSEC * CSCHED_MSECS_PER_TSLICE) > -#define CSCHED_CREDITS_PER_ACCT =A0 =A0 \ > - =A0 =A0(CSCHED_CREDITS_PER_MSEC * CSCHED_MSECS_PER_TICK * CSCHED_TICKS_= PER_ACCT) > > > =A0/* > @@ -113,6 +107,8 @@ > =A0*/ > =A0static bool_t __read_mostly sched_credit_default_yield; > =A0boolean_param("sched_credit_default_yield", sched_credit_default_yield= ); > +static int __read_mostly sched_credit_tslice_ms =3D CSCHED_DEFAULT_TSLIC= E_MS; > +integer_param("sched_credit_tslice_ms", sched_credit_tslice_ms); > > =A0/* > =A0* Physical CPU > @@ -176,6 +172,9 @@ struct csched_private { > =A0 =A0 uint32_t credit; > =A0 =A0 int credit_balance; > =A0 =A0 uint32_t runq_sort; > + =A0 =A0/* Period of master and tick in milliseconds */ > + =A0 =A0unsigned tslice_ms, tick_period_us, ticks_per_tslice; > + =A0 =A0unsigned credits_per_tslice; > =A0}; > > =A0static void csched_tick(void *_cpu); > @@ -326,7 +325,7 @@ csched_free_pdata(const struct scheduler > > =A0 =A0 spin_lock_irqsave(&prv->lock, flags); > > - =A0 =A0prv->credit -=3D CSCHED_CREDITS_PER_ACCT; > + =A0 =A0prv->credit -=3D prv->credits_per_tslice; > =A0 =A0 prv->ncpus--; > =A0 =A0 cpu_clear(cpu, prv->idlers); > =A0 =A0 cpu_clear(cpu, prv->cpus); > @@ -360,19 +359,19 @@ csched_alloc_pdata(const struct schedule > =A0 =A0 spin_lock_irqsave(&prv->lock, flags); > > =A0 =A0 /* Initialize/update system-wide config */ > - =A0 =A0prv->credit +=3D CSCHED_CREDITS_PER_ACCT; > + =A0 =A0prv->credit +=3D prv->credits_per_tslice; > =A0 =A0 prv->ncpus++; > =A0 =A0 cpu_set(cpu, prv->cpus); > =A0 =A0 if ( prv->ncpus =3D=3D 1 ) > =A0 =A0 { > =A0 =A0 =A0 =A0 prv->master =3D cpu; > =A0 =A0 =A0 =A0 init_timer(&prv->master_ticker, csched_acct, prv, cpu); > - =A0 =A0 =A0 =A0set_timer(&prv->master_ticker, NOW() + > - =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0MILLISECS(CSCHED_MSECS_PER_TICK) * C= SCHED_TICKS_PER_ACCT); > + =A0 =A0 =A0 =A0set_timer(&prv->master_ticker, > + =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0NOW() + MILLISECS(prv->tslice_ms)); > =A0 =A0 } > > =A0 =A0 init_timer(&spc->ticker, csched_tick, (void *)(unsigned long)cpu,= cpu); > - =A0 =A0set_timer(&spc->ticker, NOW() + MILLISECS(CSCHED_MSECS_PER_TICK)= ); > + =A0 =A0set_timer(&spc->ticker, NOW() + MICROSECS(prv->tick_period_us) )= ; > > =A0 =A0 INIT_LIST_HEAD(&spc->runq); > =A0 =A0 spc->runq_sort_last =3D prv->runq_sort; > @@ -1002,7 +1001,7 @@ csched_acct(void* dummy) > =A0 =A0 =A0 =A0 =A0* for one full accounting period. We allow a domain to= earn more > =A0 =A0 =A0 =A0 =A0* only when the system-wide credit balance is negative= . > =A0 =A0 =A0 =A0 =A0*/ > - =A0 =A0 =A0 =A0credit_peak =3D sdom->active_vcpu_count * CSCHED_CREDITS= _PER_ACCT; > + =A0 =A0 =A0 =A0credit_peak =3D sdom->active_vcpu_count * prv->credits_p= er_tslice; > =A0 =A0 =A0 =A0 if ( prv->credit_balance < 0 ) > =A0 =A0 =A0 =A0 { > =A0 =A0 =A0 =A0 =A0 =A0 credit_peak +=3D ( ( -prv->credit_balance > @@ -1014,7 +1013,7 @@ csched_acct(void* dummy) > > =A0 =A0 =A0 =A0 if ( sdom->cap !=3D 0U ) > =A0 =A0 =A0 =A0 { > - =A0 =A0 =A0 =A0 =A0 =A0credit_cap =3D ((sdom->cap * CSCHED_CREDITS_PER_= ACCT) + 99) / 100; > + =A0 =A0 =A0 =A0 =A0 =A0credit_cap =3D ((sdom->cap * prv->credits_per_ts= lice) + 99) / 100; > =A0 =A0 =A0 =A0 =A0 =A0 if ( credit_cap < credit_peak ) > =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 credit_peak =3D credit_cap; > > @@ -1092,10 +1091,10 @@ csched_acct(void* dummy) > =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 } > > =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 /* Lower bound on credits */ > - =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0if ( credit < -CSCHED_CREDITS_PER_TSLICE= ) > + =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0if ( credit < -prv->credits_per_tslice ) > =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 { > =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 CSCHED_STAT_CRANK(acct_min_credit= ); > - =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0credit =3D -CSCHED_CREDITS_PER_T= SLICE; > + =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0credit =3D -prv->credits_per_tsl= ice; > =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 atomic_set(&svc->credit, credit); > =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 } > =A0 =A0 =A0 =A0 =A0 =A0 } > @@ -1117,7 +1116,7 @@ csched_acct(void* dummy) > =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 } > > =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 /* Upper bound on credits means VCPU stop= s earning */ > - =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0if ( credit > CSCHED_CREDITS_PER_TSLICE = ) > + =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0if ( credit > prv->credits_per_tslice ) > =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 { > =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 __csched_vcpu_acct_stop_locked(pr= v, svc); > =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 /* Divide credits in half, so tha= t when it starts > @@ -1141,8 +1140,8 @@ csched_acct(void* dummy) > =A0 =A0 prv->runq_sort++; > > =A0out: > - =A0 =A0set_timer( &prv->master_ticker, NOW() + > - =A0 =A0 =A0 =A0 =A0 =A0MILLISECS(CSCHED_MSECS_PER_TICK) * CSCHED_TICKS_= PER_ACCT ); > + =A0 =A0set_timer( &prv->master_ticker, > + =A0 =A0 =A0 =A0 =A0 =A0 =A0 NOW() + MILLISECS(prv->tslice_ms)); > =A0} > > =A0static void > @@ -1169,7 +1168,7 @@ csched_tick(void *_cpu) > =A0 =A0 =A0*/ > =A0 =A0 csched_runq_sort(prv, cpu); > > - =A0 =A0set_timer(&spc->ticker, NOW() + MILLISECS(CSCHED_MSECS_PER_TICK)= ); > + =A0 =A0set_timer(&spc->ticker, NOW() + MICROSECS(prv->tick_period_us) )= ; > =A0} > > =A0static struct csched_vcpu * > @@ -1375,7 +1374,7 @@ csched_schedule( > =A0 =A0 =A0* Return task to run next... > =A0 =A0 =A0*/ > =A0 =A0 ret.time =3D (is_idle_vcpu(snext->vcpu) ? > - =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0-1 : MILLISECS(CSCHED_MSECS_PER_TSLICE))= ; > + =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0-1 : MILLISECS(prv->tslice_ms)); > =A0 =A0 ret.task =3D snext->vcpu; > > =A0 =A0 CSCHED_VCPU_CHECK(ret.task); > @@ -1469,10 +1468,9 @@ csched_dump(const struct scheduler *ops) > =A0 =A0 =A0 =A0 =A0 =A0"\tweight =A0 =A0 =A0 =A0 =A0 =A0 =3D %u\n" > =A0 =A0 =A0 =A0 =A0 =A0"\trunq_sort =A0 =A0 =A0 =A0 =A0=3D %u\n" > =A0 =A0 =A0 =A0 =A0 =A0"\tdefault-weight =A0 =A0 =3D %d\n" > - =A0 =A0 =A0 =A0 =A0 "\tmsecs per tick =A0 =A0 =3D %dms\n" > + =A0 =A0 =A0 =A0 =A0 "\ttslice =A0 =A0 =A0 =A0 =A0 =A0 =3D %dms\n" > =A0 =A0 =A0 =A0 =A0 =A0"\tcredits per msec =A0 =3D %d\n" > =A0 =A0 =A0 =A0 =A0 =A0"\tticks per tslice =A0 =3D %d\n" > - =A0 =A0 =A0 =A0 =A0 "\tticks per acct =A0 =A0 =3D %d\n" > =A0 =A0 =A0 =A0 =A0 =A0"\tmigration delay =A0 =A0=3D %uus\n", > =A0 =A0 =A0 =A0 =A0 =A0prv->ncpus, > =A0 =A0 =A0 =A0 =A0 =A0prv->master, > @@ -1481,10 +1479,9 @@ csched_dump(const struct scheduler *ops) > =A0 =A0 =A0 =A0 =A0 =A0prv->weight, > =A0 =A0 =A0 =A0 =A0 =A0prv->runq_sort, > =A0 =A0 =A0 =A0 =A0 =A0CSCHED_DEFAULT_WEIGHT, > - =A0 =A0 =A0 =A0 =A0 CSCHED_MSECS_PER_TICK, > + =A0 =A0 =A0 =A0 =A0 prv->tslice_ms, > =A0 =A0 =A0 =A0 =A0 =A0CSCHED_CREDITS_PER_MSEC, > - =A0 =A0 =A0 =A0 =A0 CSCHED_TICKS_PER_TSLICE, > - =A0 =A0 =A0 =A0 =A0 CSCHED_TICKS_PER_ACCT, > + =A0 =A0 =A0 =A0 =A0 prv->ticks_per_tslice, > =A0 =A0 =A0 =A0 =A0 =A0vcpu_migration_delay); > > =A0 =A0 cpumask_scnprintf(idlers_buf, sizeof(idlers_buf), prv->idlers); > @@ -1526,6 +1523,13 @@ csched_init(struct scheduler *ops) > =A0 =A0 INIT_LIST_HEAD(&prv->active_sdom); > =A0 =A0 prv->master =3D UINT_MAX; > > + =A0 =A0prv->tslice_ms =3D sched_credit_tslice_ms; > + =A0 =A0prv->ticks_per_tslice =3D CSCHED_TICKS_PER_TSLICE; > + =A0 =A0if ( prv->tslice_ms < prv->ticks_per_tslice ) > + =A0 =A0 =A0 =A0prv->ticks_per_tslice =3D 1; > + =A0 =A0prv->tick_period_us =3D prv->tslice_ms * 1000 / prv->ticks_per_t= slice; > + =A0 =A0prv->credits_per_tslice =3D CSCHED_CREDITS_PER_MSEC * prv->tslic= e_ms; > + > =A0 =A0 return 0; > =A0} > > @@ -1550,13 +1554,16 @@ static void csched_tick_suspend(const st > > =A0static void csched_tick_resume(const struct scheduler *ops, unsigned i= nt cpu) > =A0{ > + =A0 =A0struct csched_private *prv; > =A0 =A0 struct csched_pcpu *spc; > =A0 =A0 uint64_t now =3D NOW(); > > =A0 =A0 spc =3D CSCHED_PCPU(cpu); > > - =A0 =A0set_timer(&spc->ticker, now + MILLISECS(CSCHED_MSECS_PER_TICK) > - =A0 =A0 =A0 =A0 =A0 =A0- now % MILLISECS(CSCHED_MSECS_PER_TICK) ); > + =A0 =A0prv =3D CSCHED_PRIV(ops); > + > + =A0 =A0set_timer(&spc->ticker, now + MICROSECS(prv->tick_period_us) > + =A0 =A0 =A0 =A0 =A0 =A0- now % MICROSECS(prv->tick_period_us) ); > =A0} > > =A0static struct csched_private _csched_priv; > > _______________________________________________ > Xen-devel mailing list > Xen-devel@lists.xensource.com > http://lists.xensource.com/xen-devel > _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel From xen-devel-bounces@lists.xensource.com Tue Sep 13 02:45:20 2011 Return-path: Envelope-to: www-data@lists.xensource.com Delivery-date: Tue, 13 Sep 2011 02:45:20 -0700 Received: from localhost ([127.0.0.1] helo=lists.colo.xensource.com) by lists.xensource.com with esmtp (Exim 4.43) id 1R3PYO-0006ug-FB; Tue, 13 Sep 2011 02:45:20 -0700 Received: from mail174.messagelabs.com ([85.158.138.51]) by lists.xensource.com with esmtp (Exim 4.43) id 1R3PXX-0006hh-Ua for xen-devel@lists.xensource.com; Tue, 13 Sep 2011 02:44:28 -0700 X-Env-Sender: keir.xen@gmail.com X-Msg-Ref: server-10.tower-174.messagelabs.com!1315907063!31218786!1 X-Originating-IP: [74.125.82.171] X-StarScan-Version: 6.3.6; banners=-,-,- X-VirusChecked: Checked Received: (qmail 31558 invoked from network); 13 Sep 2011 09:44:24 -0000 Received: from mail-wy0-f171.google.com (HELO mail-wy0-f171.google.com) (74.125.82.171) by server-10.tower-174.messagelabs.com with RC4-SHA encrypted SMTP; 13 Sep 2011 09:44:24 -0000 Received: by wyh13 with SMTP id 13so386708wyh.30 for ; Tue, 13 Sep 2011 02:44:13 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=sender:user-agent:date:subject:from:to:cc:message-id:thread-topic :thread-index:in-reply-to:mime-version:content-type :content-transfer-encoding; bh=DRsEJMjbB8e2tUvSJza9/cIAed6WP9Y9iA4N0T49Wa4=; b=Aq5f10GzGLTNWZovBiiLg2zsgyMYde073Ck4GwyLZIbBI4Z/U4btEtpWHZuwsT6xTB 2nNaH+zzCacN0mBb4qvDAoO77xqrZvsY79wgc/o/VhU0K5SgkxgxRUSzkQ6k1upEH6DF r71sMjCkqLgqH4BaGgLzjWXAVXENDmVxWwA7Q= Received: by 10.227.184.5 with SMTP id ci5mr2420857wbb.8.1315907053340; Tue, 13 Sep 2011 02:44:13 -0700 (PDT) Received: from [192.168.1.3] (host86-137-116-193.range86-137.btcentralplus.com [86.137.116.193]) by mx.google.com with ESMTPS id fg18sm1193994wbb.24.2011.09.13.02.44.09 (version=SSLv3 cipher=OTHER); Tue, 13 Sep 2011 02:44:12 -0700 (PDT) User-Agent: Microsoft-Entourage/12.30.0.110427 Date: Tue, 13 Sep 2011 10:44:06 +0100 Subject: Re: [Xen-devel] [PATCH] xen,credit1: Add variable timeslice From: Keir Fraser To: George Dunlap , Message-ID: Thread-Topic: [Xen-devel] [PATCH] xen,credit1: Add variable timeslice Thread-Index: Acxx+a2WmH73pbfm+kS3KRKQYlmA/A== In-Reply-To: Mime-version: 1.0 Content-type: text/plain; charset="ISO-8859-1" Content-transfer-encoding: quoted-printable Cc: Tim Deegan X-BeenThere: xen-devel@lists.xensource.com X-Mailman-Version: 2.1.5 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xensource.com Errors-To: xen-devel-bounces@lists.xensource.com On 13/09/2011 10:25, "George Dunlap" wrote: > Ping? Now done. -- Keir > On Thu, Sep 1, 2011 at 4:30 PM, George Dunlap > wrote: >> Add a xen command-line parameter, sched_credit_tslice_ms, >> to set the timeslice of the credit1 scheduler. >>=20 >> Signed-off-by: George Dunlap >>=20 >> diff -r 4a4882df5649 -r 782284c5b1bc xen/common/sched_credit.c >> --- a/xen/common/sched_credit.c Wed Aug 31 15:23:49 2011 +0100 >> +++ b/xen/common/sched_credit.c Thu Sep 01 16:29:50 2011 +0100 >> @@ -41,15 +41,9 @@ >> =A0*/ >> =A0#define CSCHED_DEFAULT_WEIGHT =A0 =A0 =A0 256 >> =A0#define CSCHED_TICKS_PER_TSLICE =A0 =A0 3 >> -#define CSCHED_TICKS_PER_ACCT =A0 =A0 =A0 3 >> -#define CSCHED_MSECS_PER_TICK =A0 =A0 =A0 10 >> -#define CSCHED_MSECS_PER_TSLICE =A0 =A0 \ >> - =A0 =A0(CSCHED_MSECS_PER_TICK * CSCHED_TICKS_PER_TSLICE) >> +/* Default timeslice: 30ms */ >> +#define CSCHED_DEFAULT_TSLICE_MS =A0 =A030 >> =A0#define CSCHED_CREDITS_PER_MSEC =A0 =A0 10 >> -#define CSCHED_CREDITS_PER_TSLICE =A0 \ >> - =A0 =A0(CSCHED_CREDITS_PER_MSEC * CSCHED_MSECS_PER_TSLICE) >> -#define CSCHED_CREDITS_PER_ACCT =A0 =A0 \ >> - =A0 =A0(CSCHED_CREDITS_PER_MSEC * CSCHED_MSECS_PER_TICK * >> CSCHED_TICKS_PER_ACCT) >>=20 >>=20 >> =A0/* >> @@ -113,6 +107,8 @@ >> =A0*/ >> =A0static bool_t __read_mostly sched_credit_default_yield; >> =A0boolean_param("sched_credit_default_yield", sched_credit_default_yield)= ; >> +static int __read_mostly sched_credit_tslice_ms =3D CSCHED_DEFAULT_TSLICE= _MS; >> +integer_param("sched_credit_tslice_ms", sched_credit_tslice_ms); >>=20 >> =A0/* >> =A0* Physical CPU >> @@ -176,6 +172,9 @@ struct csched_private { >> =A0 =A0 uint32_t credit; >> =A0 =A0 int credit_balance; >> =A0 =A0 uint32_t runq_sort; >> + =A0 =A0/* Period of master and tick in milliseconds */ >> + =A0 =A0unsigned tslice_ms, tick_period_us, ticks_per_tslice; >> + =A0 =A0unsigned credits_per_tslice; >> =A0}; >>=20 >> =A0static void csched_tick(void *_cpu); >> @@ -326,7 +325,7 @@ csched_free_pdata(const struct scheduler >>=20 >> =A0 =A0 spin_lock_irqsave(&prv->lock, flags); >>=20 >> - =A0 =A0prv->credit -=3D CSCHED_CREDITS_PER_ACCT; >> + =A0 =A0prv->credit -=3D prv->credits_per_tslice; >> =A0 =A0 prv->ncpus--; >> =A0 =A0 cpu_clear(cpu, prv->idlers); >> =A0 =A0 cpu_clear(cpu, prv->cpus); >> @@ -360,19 +359,19 @@ csched_alloc_pdata(const struct schedule >> =A0 =A0 spin_lock_irqsave(&prv->lock, flags); >>=20 >> =A0 =A0 /* Initialize/update system-wide config */ >> - =A0 =A0prv->credit +=3D CSCHED_CREDITS_PER_ACCT; >> + =A0 =A0prv->credit +=3D prv->credits_per_tslice; >> =A0 =A0 prv->ncpus++; >> =A0 =A0 cpu_set(cpu, prv->cpus); >> =A0 =A0 if ( prv->ncpus =3D=3D 1 ) >> =A0 =A0 { >> =A0 =A0 =A0 =A0 prv->master =3D cpu; >> =A0 =A0 =A0 =A0 init_timer(&prv->master_ticker, csched_acct, prv, cpu); >> - =A0 =A0 =A0 =A0set_timer(&prv->master_ticker, NOW() + >> - =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0MILLISECS(CSCHED_MSECS_PER_TICK) * CSCHED_TICKS_PER_A= CCT); >> + =A0 =A0 =A0 =A0set_timer(&prv->master_ticker, >> + =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0NOW() + MILLISECS(prv->tslice_ms)); >> =A0 =A0 } >>=20 >> =A0 =A0 init_timer(&spc->ticker, csched_tick, (void *)(unsigned long)cpu, cp= u); >> - =A0 =A0set_timer(&spc->ticker, NOW() + MILLISECS(CSCHED_MSECS_PER_TICK)); >> + =A0 =A0set_timer(&spc->ticker, NOW() + MICROSECS(prv->tick_period_us) ); >>=20 >> =A0 =A0 INIT_LIST_HEAD(&spc->runq); >> =A0 =A0 spc->runq_sort_last =3D prv->runq_sort; >> @@ -1002,7 +1001,7 @@ csched_acct(void* dummy) >> =A0 =A0 =A0 =A0 =A0* for one full accounting period. We allow a domain to earn mor= e >> =A0 =A0 =A0 =A0 =A0* only when the system-wide credit balance is negative. >> =A0 =A0 =A0 =A0 =A0*/ >> - =A0 =A0 =A0 =A0credit_peak =3D sdom->active_vcpu_count * CSCHED_CREDITS_PER_ACCT= ; >> + =A0 =A0 =A0 =A0credit_peak =3D sdom->active_vcpu_count * prv->credits_per_tslice= ; >> =A0 =A0 =A0 =A0 if ( prv->credit_balance < 0 ) >> =A0 =A0 =A0 =A0 { >> =A0 =A0 =A0 =A0 =A0 =A0 credit_peak +=3D ( ( -prv->credit_balance >> @@ -1014,7 +1013,7 @@ csched_acct(void* dummy) >>=20 >> =A0 =A0 =A0 =A0 if ( sdom->cap !=3D 0U ) >> =A0 =A0 =A0 =A0 { >> - =A0 =A0 =A0 =A0 =A0 =A0credit_cap =3D ((sdom->cap * CSCHED_CREDITS_PER_ACCT) + 99) /= 100; >> + =A0 =A0 =A0 =A0 =A0 =A0credit_cap =3D ((sdom->cap * prv->credits_per_tslice) + 99) /= 100; >> =A0 =A0 =A0 =A0 =A0 =A0 if ( credit_cap < credit_peak ) >> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 credit_peak =3D credit_cap; >>=20 >> @@ -1092,10 +1091,10 @@ csched_acct(void* dummy) >> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 } >>=20 >> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 /* Lower bound on credits */ >> - =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0if ( credit < -CSCHED_CREDITS_PER_TSLICE ) >> + =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0if ( credit < -prv->credits_per_tslice ) >> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 { >> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 CSCHED_STAT_CRANK(acct_min_credit); >> - =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0credit =3D -CSCHED_CREDITS_PER_TSLICE; >> + =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0credit =3D -prv->credits_per_tslice; >> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 atomic_set(&svc->credit, credit); >> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 } >> =A0 =A0 =A0 =A0 =A0 =A0 } >> @@ -1117,7 +1116,7 @@ csched_acct(void* dummy) >> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 } >>=20 >> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 /* Upper bound on credits means VCPU stops earning */ >> - =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0if ( credit > CSCHED_CREDITS_PER_TSLICE ) >> + =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0if ( credit > prv->credits_per_tslice ) >> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 { >> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 __csched_vcpu_acct_stop_locked(prv, svc); >> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 /* Divide credits in half, so that when it starts >> @@ -1141,8 +1140,8 @@ csched_acct(void* dummy) >> =A0 =A0 prv->runq_sort++; >>=20 >> =A0out: >> - =A0 =A0set_timer( &prv->master_ticker, NOW() + >> - =A0 =A0 =A0 =A0 =A0 =A0MILLISECS(CSCHED_MSECS_PER_TICK) * CSCHED_TICKS_PER_ACCT ); >> + =A0 =A0set_timer( &prv->master_ticker, >> + =A0 =A0 =A0 =A0 =A0 =A0 =A0 NOW() + MILLISECS(prv->tslice_ms)); >> =A0} >>=20 >> =A0static void >> @@ -1169,7 +1168,7 @@ csched_tick(void *_cpu) >> =A0 =A0 =A0*/ >> =A0 =A0 csched_runq_sort(prv, cpu); >>=20 >> - =A0 =A0set_timer(&spc->ticker, NOW() + MILLISECS(CSCHED_MSECS_PER_TICK)); >> + =A0 =A0set_timer(&spc->ticker, NOW() + MICROSECS(prv->tick_period_us) ); >> =A0} >>=20 >> =A0static struct csched_vcpu * >> @@ -1375,7 +1374,7 @@ csched_schedule( >> =A0 =A0 =A0* Return task to run next... >> =A0 =A0 =A0*/ >> =A0 =A0 ret.time =3D (is_idle_vcpu(snext->vcpu) ? >> - =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0-1 : MILLISECS(CSCHED_MSECS_PER_TSLICE)); >> + =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0-1 : MILLISECS(prv->tslice_ms)); >> =A0 =A0 ret.task =3D snext->vcpu; >>=20 >> =A0 =A0 CSCHED_VCPU_CHECK(ret.task); >> @@ -1469,10 +1468,9 @@ csched_dump(const struct scheduler *ops) >> =A0 =A0 =A0 =A0 =A0 =A0"\tweight =A0 =A0 =A0 =A0 =A0 =A0 =3D %u\n" >> =A0 =A0 =A0 =A0 =A0 =A0"\trunq_sort =A0 =A0 =A0 =A0 =A0=3D %u\n" >> =A0 =A0 =A0 =A0 =A0 =A0"\tdefault-weight =A0 =A0 =3D %d\n" >> - =A0 =A0 =A0 =A0 =A0 "\tmsecs per tick =A0 =A0 =3D %dms\n" >> + =A0 =A0 =A0 =A0 =A0 "\ttslice =A0 =A0 =A0 =A0 =A0 =A0 =3D %dms\n" >> =A0 =A0 =A0 =A0 =A0 =A0"\tcredits per msec =A0 =3D %d\n" >> =A0 =A0 =A0 =A0 =A0 =A0"\tticks per tslice =A0 =3D %d\n" >> - =A0 =A0 =A0 =A0 =A0 "\tticks per acct =A0 =A0 =3D %d\n" >> =A0 =A0 =A0 =A0 =A0 =A0"\tmigration delay =A0 =A0=3D %uus\n", >> =A0 =A0 =A0 =A0 =A0 =A0prv->ncpus, >> =A0 =A0 =A0 =A0 =A0 =A0prv->master, >> @@ -1481,10 +1479,9 @@ csched_dump(const struct scheduler *ops) >> =A0 =A0 =A0 =A0 =A0 =A0prv->weight, >> =A0 =A0 =A0 =A0 =A0 =A0prv->runq_sort, >> =A0 =A0 =A0 =A0 =A0 =A0CSCHED_DEFAULT_WEIGHT, >> - =A0 =A0 =A0 =A0 =A0 CSCHED_MSECS_PER_TICK, >> + =A0 =A0 =A0 =A0 =A0 prv->tslice_ms, >> =A0 =A0 =A0 =A0 =A0 =A0CSCHED_CREDITS_PER_MSEC, >> - =A0 =A0 =A0 =A0 =A0 CSCHED_TICKS_PER_TSLICE, >> - =A0 =A0 =A0 =A0 =A0 CSCHED_TICKS_PER_ACCT, >> + =A0 =A0 =A0 =A0 =A0 prv->ticks_per_tslice, >> =A0 =A0 =A0 =A0 =A0 =A0vcpu_migration_delay); >>=20 >> =A0 =A0 cpumask_scnprintf(idlers_buf, sizeof(idlers_buf), prv->idlers); >> @@ -1526,6 +1523,13 @@ csched_init(struct scheduler *ops) >> =A0 =A0 INIT_LIST_HEAD(&prv->active_sdom); >> =A0 =A0 prv->master =3D UINT_MAX; >>=20 >> + =A0 =A0prv->tslice_ms =3D sched_credit_tslice_ms; >> + =A0 =A0prv->ticks_per_tslice =3D CSCHED_TICKS_PER_TSLICE; >> + =A0 =A0if ( prv->tslice_ms < prv->ticks_per_tslice ) >> + =A0 =A0 =A0 =A0prv->ticks_per_tslice =3D 1; >> + =A0 =A0prv->tick_period_us =3D prv->tslice_ms * 1000 / prv->ticks_per_tslice= ; >> + =A0 =A0prv->credits_per_tslice =3D CSCHED_CREDITS_PER_MSEC * prv->tslice_ms; >> + >> =A0 =A0 return 0; >> =A0} >>=20 >> @@ -1550,13 +1554,16 @@ static void csched_tick_suspend(const st >>=20 >> =A0static void csched_tick_resume(const struct scheduler *ops, unsigned in= t >> cpu) >> =A0{ >> + =A0 =A0struct csched_private *prv; >> =A0 =A0 struct csched_pcpu *spc; >> =A0 =A0 uint64_t now =3D NOW(); >>=20 >> =A0 =A0 spc =3D CSCHED_PCPU(cpu); >>=20 >> - =A0 =A0set_timer(&spc->ticker, now + MILLISECS(CSCHED_MSECS_PER_TICK) >> - =A0 =A0 =A0 =A0 =A0 =A0- now % MILLISECS(CSCHED_MSECS_PER_TICK) ); >> + =A0 =A0prv =3D CSCHED_PRIV(ops); >> + >> + =A0 =A0set_timer(&spc->ticker, now + MICROSECS(prv->tick_period_us) >> + =A0 =A0 =A0 =A0 =A0 =A0- now % MICROSECS(prv->tick_period_us) ); >> =A0} >>=20 >> =A0static struct csched_private _csched_priv; >>=20 >> _______________________________________________ >> Xen-devel mailing list >> Xen-devel@lists.xensource.com >> http://lists.xensource.com/xen-devel >>=20 _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel From xen-devel-bounces@lists.xensource.com Tue Sep 13 02:46:58 2011 Return-path: Envelope-to: www-data@lists.xensource.com Delivery-date: Tue, 13 Sep 2011 02:46:58 -0700 Received: from localhost ([127.0.0.1] helo=lists.colo.xensource.com) by lists.xensource.com with esmtp (Exim 4.43) id 1R3PZy-0007IL-Kl; Tue, 13 Sep 2011 02:46:58 -0700 Received: from mail21.messagelabs.com ([85.158.143.35]) by lists.xensource.com with esmtp (Exim 4.43) id 1R3PZS-000763-UT for xen-devel@lists.xensource.com; Tue, 13 Sep 2011 02:46:28 -0700 X-Env-Sender: Ian.Campbell@eu.citrix.com X-Msg-Ref: server-7.tower-21.messagelabs.com!1315907153!54638849!1 X-Originating-IP: [66.165.176.63] X-StarScan-Version: 6.4.1; banners=-,-,- X-VirusChecked: Checked Received: (qmail 557 invoked from network); 13 Sep 2011 09:45:54 -0000 Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63) by server-7.tower-21.messagelabs.com with RC4-SHA encrypted SMTP; 13 Sep 2011 09:45:54 -0000 X-IronPort-AV: E=Sophos;i="4.68,373,1312171200"; d="scan'208";a="162714172" Received: from ftlpmailmx02.citrite.net ([10.13.107.66]) by FTLPIPO02.CITRIX.COM with ESMTP/TLS/RC4-MD5; 13 Sep 2011 05:46:18 -0400 Received: from [127.0.0.1] (10.80.16.67) by smtprelay.citrix.com (10.13.107.66) with Microsoft SMTP Server id 8.3.137.0; Tue, 13 Sep 2011 05:46:18 -0400 Subject: Re: [Xen-devel] Help with the migration to XEN-4.1 please From: Ian Campbell To: Flavio Date: Tue, 13 Sep 2011 11:46:17 +0200 In-Reply-To: References: Organization: Citrix Systems, Inc. Content-Type: text/plain; charset="UTF-8" X-Mailer: Evolution 3.0.3- Content-Transfer-Encoding: 7bit Message-ID: <1315907178.2892.7.camel@cthulhu.hellion.org.uk> MIME-Version: 1.0 Cc: xen-devel X-BeenThere: xen-devel@lists.xensource.com X-Mailman-Version: 2.1.5 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xensource.com Errors-To: xen-devel-bounces@lists.xensource.com On Tue, 2011-09-13 at 04:58 -0400, Flavio wrote: > Hello, > > I recently installed XEN on my Gentoo Linux that I use mainly as a > Desktop and I had to switch from xm to xl tool stack. > Since also the gentoo-sources support XEN natively I installed XEN on > my Desktop > distribution too. Well, I started installing XEN as usual, and I was > using it only with the xm tool stack. > Now I read about the migration to the new toolstack at > http://wiki.xensource.com/xenwiki/MigrationGuideToXen4.1%2B but > I have some problem and some question to do. > > First of all, let me list my environment: > OS: Gentoo Linux 10.0 kernel: gentoo-sources-3.0.4 arch x86_64 > app-emulation/xen-4.1.1-r1 > app-emulation/xen-tools-4.1.1-r3 with USE flags: "hvm ioemu" > > I also completed the following checklist: > - Configure your host networking using the configuration tools > provided by your distribution. > - Remove any python code from domU configuration files. > - Disable xend startup script (it doesn't exist anymore) > - Use xl command instead of xm (xm doesn't exist anymore) > > 1) Now the xend initscript has been removed. Well, I had some domain > registered with the command 'xm new vm_name.cfg'. > Actually, performing a "xm list" it was showing them in the list of > the domains after the dom0. > Now that xend has been removed, it is no longer running and 'xl list' > doesn't show any domU in the list. How does it work now? I'm afraid that xl does not support this style of "managed" domain. The /etc/xen/auto type stuff ought to still work although there have been a bunch of fixes to that recently, I think they are all queued for 4.1.2 but it might be worth confirming that tools/hotplug in your tree looks similar to that in xen-unstable.hg > I tried to put the vm configuration file in /etc/xen/auto but in this > way it starts the vm and not simply it adds to the xen domain store, > letting me decide if starting the vm or not. I was looking for the > analogue command as "xm new config_file.cfg" in xl if exists. > > 2) If I try to run a gentoo linux guest (for instance) running > 'xl vm_config_file.cfg -c' I get the following error: You mean 'xl create vm_config....'? > xenconsole: Could not read tty from store: No such file or directory > But the vm starts even if the networking doesn't work now, of course. > I've already searched and found several results on Google but the > problem is still there. :( Did you start xenstored and xenconsoled? i.e. did you add the "xencommons" initscript to your startup? > 3) the network for the guest OS doesn't work, even the xenbr0 is up > and the vm configuration file > explicitly says it has to use that bridge. Furthermore, due to the > error at point 2, I can't see anything > in the VM. > I also tried to add the following line in the /etc/xen/xl.conf but the > network doesn't work anyway: > vifscript="vif-bridge" > > 4) xl shutdown seems to be not working. I have to > destroy the VM in order to have it powered off. > > Can somebody help me to correct these problems please? Both of these sound as if xenstored is not working properly for you. Is it running? You didn't restart it did you? (you cannot restart xenstored, unfortunately if you did this you need to reboot). Did you also change kernel when you moved to 4.1? Do you have the /dev/xen nodes, especially evtchn loaded and available? With pvops many kernels are more standard distro kernels rather than xen-specific and therefore stuff which was historically statically built in to the kernel are now modular. Ian. > > -- > Flavio > > _______________________________________________ > Xen-devel mailing list > Xen-devel@lists.xensource.com > http://lists.xensource.com/xen-devel _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel From xen-devel-bounces@lists.xensource.com Tue Sep 13 02:53:24 2011 Return-path: Envelope-to: www-data@lists.xensource.com Delivery-date: Tue, 13 Sep 2011 02:53:24 -0700 Received: from localhost ([127.0.0.1] helo=lists.colo.xensource.com) by lists.xensource.com with esmtp (Exim 4.43) id 1R3PgC-0007lb-O9; Tue, 13 Sep 2011 02:53:24 -0700 Received: from mail21.messagelabs.com ([85.158.143.35]) by lists.xensource.com with smtp (Exim 4.43) id 1R3Pfi-0007Yl-Qn for xen-devel@lists.xensource.com; Tue, 13 Sep 2011 02:52:55 -0700 X-Env-Sender: anthony@overnetdata.com X-Msg-Ref: server-13.tower-21.messagelabs.com!1315907566!48712212!1 X-Originating-IP: [81.137.131.225] X-StarScan-Version: 6.4.1; banners=-,-,- X-VirusChecked: Checked Received: (qmail 18282 invoked from network); 13 Sep 2011 09:52:46 -0000 Received: from host81-137-131-225.in-addr.btopenworld.com (HELO zimbra.overnetdata.com) (81.137.131.225) by server-13.tower-21.messagelabs.com with SMTP; 13 Sep 2011 09:52:46 -0000 Received: from localhost (localhost.localdomain [127.0.0.1]) by zimbra.overnetdata.com (Postfix) with ESMTP id 7C0CB161572; Tue, 13 Sep 2011 10:52:51 +0100 (BST) X-Virus-Scanned: amavisd-new at overnetdata.com Received: from zimbra.overnetdata.com ([127.0.0.1]) by localhost (zimbra.overnetdata.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KuunT-yx5vgO; Tue, 13 Sep 2011 10:52:40 +0100 (BST) Received: from zimbra.overnetdata.com (zimbra.overnetdata.com [192.168.1.204]) by zimbra.overnetdata.com (Postfix) with ESMTP id A29DC161571; Tue, 13 Sep 2011 10:52:40 +0100 (BST) Date: Tue, 13 Sep 2011 10:52:40 +0100 (BST) From: Anthony Wright To: Konrad Rzeszutek Wilk Message-ID: <8813601.2.1315907560404.JavaMail.root@zimbra.overnetdata.com> In-Reply-To: <4E6BCDA9.3030700@overnetdata.com> Subject: Re: [Xen-devel] VM hangs during boot on 3.0.4 dom0 kernel, works on alternative hardware MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit X-Originating-IP: [192.168.1.54] X-Mailer: Zimbra 6.0.8_GA_2661 (ZimbraWebClient - FF3.0 (Win)/6.0.8_GA_2661) Cc: xen-devel@lists.xensource.com X-BeenThere: xen-devel@lists.xensource.com X-Mailman-Version: 2.1.5 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xensource.com Errors-To: xen-devel-bounces@lists.xensource.com ----- Original Message ----- > On 06/09/2011 17:16, Konrad Rzeszutek Wilk wrote: > > On Mon, Sep 05, 2011 at 11:31:16AM +0100, Anthony Wright wrote: > >> I have two machines with identical Dom0's and DomUs, but different > >> hardware. The Dom0 has a patch which I produced myself based on the > >> "Re: > >> [Xen-devel] Kernel bug from 3.0 (was phy disks and vifs timing out > >> in > >> DomU)" thread. The patch calls vmalloc_sync_all after every > >> alloc_vm_area, and I realise this isn't the best solution, but it > >> allowed me to move forward. > > > >> The patch fixes the problem I had on one machine, so that now the > >> VMs > >> boot correctly, but I have another system with an identical setup > >> (identical Dom0 & DomU kernels, identical startup for DomU) and the > >> VM > >> fails to start. I have attached a copy of the console log from the > >> good > >> VM and the bad VM. > > And what does the dom0 and xen hypervisor log give you? > > > > It looks to be hanging at identifying the CPU - is the hardware > > quite different from one setup to another? Have you toyed with > > using the cpuid flag in the guest to mimic the lowest CPU type? > I've found a solution to my problem. The PV DomU was running a 32 bit > linux kernel version 2.6.30.1. I hoped that a new kernel would be able > to handle to CPU more effectively, and so I upgraded my DomU kernel to > 3.0.4, and now the DomU boots. > > This solves the problem for me, but I'm slightly concerned that my > original kernel wouldn't work with this CPU (the CPU type for the > kernel > builds is set to Pentium Pro). I'll try the 2.6.30.1 kernel on bare > metal on monday to try to see if this is a xen/Dom0 kernel issue or a > CPU/DomU issue. > > Anthony I've tried the 2.6.30.1 kernel on bare metal and it boots correctly, so it looks like some xen/Dom0 interaction is causing it to fail when run as a DomU. I have a work around (upgrading to 3.0.4 kernel), so it's not affecting me but I'm happy to do any diagnostics to help identify the cause of the problem. _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel From xen-devel-bounces@lists.xensource.com Tue Sep 13 03:04:27 2011 Return-path: Envelope-to: www-data@lists.xensource.com Delivery-date: Tue, 13 Sep 2011 03:04:27 -0700 Received: from localhost ([127.0.0.1] helo=lists.colo.xensource.com) by lists.xensource.com with esmtp (Exim 4.43) id 1R3Pqt-0008PS-NM; Tue, 13 Sep 2011 03:04:27 -0700 Received: from mail182.messagelabs.com ([85.158.139.83]) by lists.xensource.com with esmtp (Exim 4.43) id 1R3Poh-0008BV-Jf for xen-devel@lists.xensource.com; Tue, 13 Sep 2011 03:02:21 -0700 X-Env-Sender: david.vrabel@citrix.com X-Msg-Ref: server-11.tower-182.messagelabs.com!1315908126!18123487!1 X-Originating-IP: [66.165.176.89] X-StarScan-Version: 6.3.6; banners=-,-,- X-VirusChecked: Checked Received: (qmail 2589 invoked from network); 13 Sep 2011 10:02:07 -0000 Received: from smtp.citrix.com (HELO SMTP.CITRIX.COM) (66.165.176.89) by server-11.tower-182.messagelabs.com with RC4-SHA encrypted SMTP; 13 Sep 2011 10:02:07 -0000 X-IronPort-AV: E=Sophos;i="4.68,373,1312171200"; d="scan'208";a="16916879" Received: from ftlpmailmx01.citrite.net ([10.13.107.65]) by FTLPIPO01.CITRIX.COM with ESMTP/TLS/RC4-MD5; 13 Sep 2011 06:02:05 -0400 Received: from [192.168.0.1] (10.31.1.113) by FTLPMAILMX01.citrite.net (10.13.107.65) with Microsoft SMTP Server id 8.3.137.0; Tue, 13 Sep 2011 06:02:05 -0400 Message-ID: <4E6F2A0E.6040208@citrix.com> Date: Tue, 13 Sep 2011 11:01:50 +0100 From: David Vrabel User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.1.16) Gecko/20110818 Icedove/3.0.11 MIME-Version: 1.0 To: Konrad Rzeszutek Wilk References: <20110912201319.GA11900@oracle.com> In-Reply-To: <20110912201319.GA11900@oracle.com> Content-Type: text/plain; charset="ISO-8859-1" Content-Transfer-Encoding: 7bit Cc: "xen-devel@lists.xensource.com" Subject: [Xen-devel] Re: fix for "xen: use maximum reservation to limit amount of usable RAM" - patch titled: "xen/e820: if there is not dom0_mem, don't tweak extra_pages." X-BeenThere: xen-devel@lists.xensource.com X-Mailman-Version: 2.1.5 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xensource.com Errors-To: xen-devel-bounces@lists.xensource.com On 12/09/11 21:13, Konrad Rzeszutek Wilk wrote: > .breaks one of my boxes (Core i3-2100), with Xen 4.1.1 (with and w/out the > 23790 changset in it). > > I've traced it down to the fact that I booted my dom0 without > dom0_mem=X flag with a machine that has more than 8GB. Weirdly enough > I can only reproduce this under Intel boxes. > > Anyhow this patch fixes it for me. I think this patch is simpler. Does it fix the issue? diff --git a/arch/x86/xen/setup.c b/arch/x86/xen/setup.c index c3b8d44..46d6d21 100644 --- a/arch/x86/xen/setup.c +++ b/arch/x86/xen/setup.c @@ -306,10 +306,12 @@ char * __init xen_memory_setup(void) sanitize_e820_map(e820.map, ARRAY_SIZE(e820.map), &e820.nr_map); extra_limit = xen_get_max_pages(); - if (extra_limit >= max_pfn) - extra_pages = extra_limit - max_pfn; - else - extra_pages = 0; + if (max_pfn + extra_pages > extra_limit) { + if (extra_limit > max_pfn) + extra_pages = extra_limit - max_pfn; + else + extra_pages = 0; + } extra_pages += xen_return_unused_memory(xen_start_info->nr_pages, &e820); David _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel From xen-devel-bounces@lists.xensource.com Tue Sep 13 03:05:42 2011 Return-path: Envelope-to: www-data@lists.xensource.com Delivery-date: Tue, 13 Sep 2011 03:05:42 -0700 Received: from localhost ([127.0.0.1] helo=lists.colo.xensource.com) by lists.xensource.com with esmtp (Exim 4.43) id 1R3Ps6-0000L8-6b; Tue, 13 Sep 2011 03:05:42 -0700 Received: from mail27.messagelabs.com ([193.109.254.147]) by lists.xensource.com with esmtp (Exim 4.43) id 1R3PpM-0008Br-LU for xen-devel@lists.xensource.com; Tue, 13 Sep 2011 03:03:04 -0700 X-Env-Sender: Christoph.Egger@amd.com X-Msg-Ref: server-5.tower-27.messagelabs.com!1315908151!44641269!1 X-Originating-IP: [213.199.154.204] X-StarScan-Version: 6.3.6; banners=-,-,- X-VirusChecked: Checked Received: (qmail 25018 invoked from network); 13 Sep 2011 10:02:31 -0000 Received: from am1ehsobe001.messaging.microsoft.com (HELO AM1EHSOBE001.bigfish.com) (213.199.154.204) by server-5.tower-27.messagelabs.com with AES128-SHA encrypted SMTP; 13 Sep 2011 10:02:31 -0000 Received: from mail64-am1-R.bigfish.com (10.3.201.251) by AM1EHSOBE001.bigfish.com (10.3.204.21) with Microsoft SMTP Server id 14.1.225.22; Tue, 13 Sep 2011 10:02:48 +0000 Received: from mail64-am1 (localhost.localdomain [127.0.0.1]) by mail64-am1-R.bigfish.com (Postfix) with ESMTP id 130E110C833A; Tue, 13 Sep 2011 10:02:49 +0000 (UTC) X-SpamScore: 4 X-BigFish: VPS4(zzbb2dK1432N98dKzz1202hzz8275bhz32i668h839haaw61h) X-Spam-TCS-SCL: 0:0 X-Forefront-Antispam-Report: CIP:163.181.249.108; KIP:(null); UIP:(null); IPVD:NLI; H:ausb3twp01.amd.com; RD:none; EFVD:NLI Received: from mail64-am1 (localhost.localdomain [127.0.0.1]) by mail64-am1 (MessageSwitch) id 1315908135112087_9799; Tue, 13 Sep 2011 10:02:15 +0000 (UTC) Received: from AM1EHSMHS002.bigfish.com (unknown [10.3.201.241]) by mail64-am1.bigfish.com (Postfix) with ESMTP id B39951AF80AD; Tue, 13 Sep 2011 10:00:34 +0000 (UTC) Received: from ausb3twp01.amd.com (163.181.249.108) by AM1EHSMHS002.bigfish.com (10.3.207.102) with Microsoft SMTP Server id 14.1.225.22; Tue, 13 Sep 2011 10:00:34 +0000 X-WSS-ID: 0LRGH4P-01-00J-02 X-M-MSG: Received: from sausexedgep01.amd.com (sausexedgep01-ext.amd.com [163.181.249.72]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by ausb3twp01.amd.com (Axway MailGate 3.8.1) with ESMTP id 2817AD10013; Tue, 13 Sep 2011 05:00:08 -0500 (CDT) Received: from SAUSEXDAG02.amd.com (163.181.55.2) by sausexedgep01.amd.com (163.181.36.54) with Microsoft SMTP Server (TLS) id 8.3.106.1; Tue, 13 Sep 2011 05:00:30 -0500 Received: from storexhtp01.amd.com (172.24.4.3) by sausexdag02.amd.com (163.181.55.2) with Microsoft SMTP Server (TLS) id 14.1.289.1; Tue, 13 Sep 2011 05:00:11 -0500 Received: from [10.224.148.192] (10.224.148.192) by storexhtp01.amd.com (172.24.4.3) with Microsoft SMTP Server id 8.3.83.0; Tue, 13 Sep 2011 06:00:07 -0400 Message-ID: <4E6F29A3.3000502@amd.com> Date: Tue, 13 Sep 2011 12:00:03 +0200 From: Christoph Egger User-Agent: Mozilla/5.0 (X11; U; NetBSD amd64; en-US; rv:1.9.2.17) Gecko/20110523 Lightning/1.0b3pre Thunderbird/3.1.10 MIME-Version: 1.0 To: "stefano.stabellini@eu.citrix.com" Subject: Re: [Xen-devel] [PATCH v3 1/4] Move the ioemu-dir-find shell script to an external file References: <1315567069-28775-1-git-send-email-stefano.stabellini@eu.citrix.com> In-Reply-To: <1315567069-28775-1-git-send-email-stefano.stabellini@eu.citrix.com> Content-Type: text/plain; charset="ISO-8859-1"; format=flowed Content-Transfer-Encoding: 7bit X-OriginatorOrg: amd.com Cc: "xen-devel@lists.xensource.com" , "keir@xen.org" , "Ian.Campbell@citrix.com" X-BeenThere: xen-devel@lists.xensource.com X-Mailman-Version: 2.1.5 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xensource.com Errors-To: xen-devel-bounces@lists.xensource.com On 09/09/11 13:17, stefano.stabellini@eu.citrix.com wrote: > Add support for configuring upstream qemu and rename ioemu-remote > ioemu-dir-remote. > > Signed-off-by: Stefano Stabellini > > diff --git a/.hgignore b/.hgignore > --- a/.hgignore > +++ b/.hgignore > @@ -291,7 +291,7 @@ > ^tools/xm-test/lib/XmTestLib/config.py$ > ^tools/xm-test/lib/XmTestReport/xmtest.py$ > ^tools/xm-test/tests/.*\.test$ > -^tools/ioemu-remote > +^tools/ioemu-dir-remote > ^tools/ioemu-dir$ > ^tools/ocaml/.*/.*\.annot$ > ^tools/ocaml/.*/.*\.cmx?a$ > diff --git a/scripts/git-checkout.sh b/scripts/git-checkout.sh > new file mode 100755 > --- /dev/null > +++ b/scripts/git-checkout.sh > @@ -0,0 +1,46 @@ > +#!/bin/bash There is no bashism. This should be #!/bin/sh. Christoph > + > +TREE=$1 > +TAG=$2 > +DIR=$3 > + > + > +if test -d $TREE; then > + mkdir -p $DIR > + ROOT=$TREE > +else > + if test \! -d $DIR-remote; then > + rm -rf $DIR-remote $DIR-remote.tmp; > + mkdir $DIR-remote.tmp; rmdir $DIR-remote.tmp; > + git clone $TREE $DIR-remote.tmp; > + if test "$TAG" ; then > + cd $DIR-remote.tmp > + git branch -D dummy>/dev/null 2>&1 ||: > + git checkout -b dummy $TAG > + cd .. > + fi > + mv $DIR-remote.tmp $DIR-remote > + fi > + rm -f $DIR > + ln -sf $DIR-remote $DIR > + ROOT=. > +fi > + > +set -e > +cd $DIR > +# is this qemu-xen-traditional? > +if test -f $ROOT/xen-setup; then > + $ROOT/xen-setup $IOEMU_CONFIGURE_CROSS > +# is this qemu-xen? > +elif test -f $ROOT/configure; then > + cd $ROOT > + ./configure --enable-xen --target-list=i386-softmmu \ > + --extra-cflags="-I$XEN_ROOT/tools/include \ > + -I$XEN_ROOT/tools/libxc \ > + -I$XEN_ROOT/tools/xenstore" \ > + --extra-ldflags="-L$XEN_ROOT/tools/libxc \ > + -L$XEN_ROOT/tools/libxenstore" \ > + --bindir=/usr/lib/xen/bin \ > + --disable-kvm \ > + $IOEMU_CONFIGURE_CROSS > +fi > diff --git a/tools/Makefile b/tools/Makefile > --- a/tools/Makefile > +++ b/tools/Makefile > @@ -70,7 +70,7 @@ clean: subdirs-clean > > .PHONY: distclean > distclean: subdirs-distclean > - rm -rf ioemu-dir ioemu-remote > + rm -rf ioemu-dir ioemu-dir-remote > > ifneq ($(XEN_COMPILE_ARCH),$(XEN_TARGET_ARCH)) > IOEMU_CONFIGURE_CROSS ?= --cpu=$(XEN_TARGET_ARCH) \ > @@ -78,41 +78,14 @@ IOEMU_CONFIGURE_CROSS ?= --cpu=$(XEN_TAR > --interp-prefix=$(CROSS_SYS_ROOT) > endif > > -QEMU_ROOT := $(shell if [ -d "$(CONFIG_QEMU)" ]; then echo "$(CONFIG_QEMU)"; else echo .; fi) > -ifneq ($(QEMU_ROOT),.) > -export QEMU_ROOT > -endif > - > ioemu-dir-find: > - set -ex; \ > - if test -d $(CONFIG_QEMU); then \ > - mkdir -p ioemu-dir; \ > - else \ > - if [ ! -d ioemu-remote ]; then \ > - rm -rf ioemu-remote ioemu-remote.tmp; \ > - mkdir ioemu-remote.tmp; rmdir ioemu-remote.tmp; \ > - $(GIT) clone $(CONFIG_QEMU) ioemu-remote.tmp; \ > - if [ "$(QEMU_TAG)" ]; then \ > - cd ioemu-remote.tmp; \ > - $(GIT) branch -D dummy>/dev/null 2>&1 ||:; \ > - $(GIT) checkout -b dummy $(QEMU_TAG); \ > - cd ..; \ > - fi; \ > - mv ioemu-remote.tmp ioemu-remote; \ > - fi; \ > - rm -f ioemu-dir; \ > - ln -sf ioemu-remote ioemu-dir; \ > - fi > - set -e; \ > - $(buildmakevars2shellvars); \ > - cd ioemu-dir; \ > - $(QEMU_ROOT)/xen-setup $(IOEMU_CONFIGURE_CROSS) > - > + $(XEN_ROOT)/scripts/git-checkout.sh $(CONFIG_QEMU) $(QEMU_TAG) ioemu-dir > + > .PHONY: ioemu-dir-force-update > ioemu-dir-force-update: > set -ex; \ > if [ "$(QEMU_TAG)" ]; then \ > - cd ioemu-remote; \ > + cd ioemu-dir-remote; \ > $(GIT) fetch origin; \ > $(GIT) reset --hard $(QEMU_TAG); \ > fi -- ---to satisfy European Law for business letters: Advanced Micro Devices GmbH Einsteinring 24, 85689 Dornach b. Muenchen Geschaeftsfuehrer: Alberto Bozzo, Andrew Bowd Sitz: Dornach, Gemeinde Aschheim, Landkreis Muenchen Registergericht Muenchen, HRB Nr. 43632 _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel From xen-devel-bounces@lists.xensource.com Tue Sep 13 03:12:14 2011 Return-path: Envelope-to: www-data@lists.xensource.com Delivery-date: Tue, 13 Sep 2011 03:12:14 -0700 Received: from localhost ([127.0.0.1] helo=lists.colo.xensource.com) by lists.xensource.com with esmtp (Exim 4.43) id 1R3PyQ-0000oT-KS; Tue, 13 Sep 2011 03:12:14 -0700 Received: from mail182.messagelabs.com ([85.158.139.83]) by lists.xensource.com with esmtp (Exim 4.43) id 1R3Pxi-0000by-3l for xen-devel@lists.xensource.com; Tue, 13 Sep 2011 03:11:30 -0700 X-Env-Sender: Stefano.Stabellini@eu.citrix.com X-Msg-Ref: server-5.tower-182.messagelabs.com!1315908687!13137289!1 X-Originating-IP: [62.200.22.115] X-StarScan-Version: 6.3.6; banners=-,-,- X-VirusChecked: Checked Received: (qmail 24681 invoked from network); 13 Sep 2011 10:11:27 -0000 Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115) by server-5.tower-182.messagelabs.com with RC4-SHA encrypted SMTP; 13 Sep 2011 10:11:27 -0000 X-IronPort-AV: E=Sophos;i="4.68,373,1312156800"; d="scan'208";a="7755697" Received: from lonpmailmx01.citrite.net ([10.30.203.162]) by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5; 13 Sep 2011 10:11:26 +0000 Received: from kaball.uk.xensource.com (10.80.2.59) by LONPMAILMX01.citrite.net (10.30.203.162) with Microsoft SMTP Server id 8.3.137.0; Tue, 13 Sep 2011 11:11:26 +0100 Date: Tue, 13 Sep 2011 11:19:53 +0100 From: Stefano Stabellini X-X-Sender: sstabellini@kaball-desktop To: Christoph Egger Subject: Re: [Xen-devel] [PATCH v3 1/4] Move the ioemu-dir-find shell script to an external file In-Reply-To: <4E6F29A3.3000502@amd.com> Message-ID: References: <1315567069-28775-1-git-send-email-stefano.stabellini@eu.citrix.com> <4E6F29A3.3000502@amd.com> User-Agent: Alpine 2.00 (DEB 1167 2008-08-23) MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Cc: Ian Campbell , "xen-devel@lists.xensource.com" , "keir@xen.org" , Stefano Stabellini X-BeenThere: xen-devel@lists.xensource.com X-Mailman-Version: 2.1.5 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xensource.com Errors-To: xen-devel-bounces@lists.xensource.com On Tue, 13 Sep 2011, Christoph Egger wrote: > On 09/09/11 13:17, stefano.stabellini@eu.citrix.com wrote: > > Add support for configuring upstream qemu and rename ioemu-remote > > ioemu-dir-remote. > > > > Signed-off-by: Stefano Stabellini > > > > diff --git a/.hgignore b/.hgignore > > --- a/.hgignore > > +++ b/.hgignore > > @@ -291,7 +291,7 @@ > > ^tools/xm-test/lib/XmTestLib/config.py$ > > ^tools/xm-test/lib/XmTestReport/xmtest.py$ > > ^tools/xm-test/tests/.*\.test$ > > -^tools/ioemu-remote > > +^tools/ioemu-dir-remote > > ^tools/ioemu-dir$ > > ^tools/ocaml/.*/.*\.annot$ > > ^tools/ocaml/.*/.*\.cmx?a$ > > diff --git a/scripts/git-checkout.sh b/scripts/git-checkout.sh > > new file mode 100755 > > --- /dev/null > > +++ b/scripts/git-checkout.sh > > @@ -0,0 +1,46 @@ > > +#!/bin/bash > > There is no bashism. This should be #!/bin/sh. yep, you are right. _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel From xen-devel-bounces@lists.xensource.com Tue Sep 13 03:14:01 2011 Return-path: Envelope-to: www-data@lists.xensource.com Delivery-date: Tue, 13 Sep 2011 03:14:01 -0700 Received: from localhost ([127.0.0.1] helo=lists.colo.xensource.com) by lists.xensource.com with esmtp (Exim 4.43) id 1R3Q09-0001C0-M1; Tue, 13 Sep 2011 03:14:01 -0700 Received: from mail216.messagelabs.com ([85.158.143.99]) by lists.xensource.com with esmtp (Exim 4.43) id 1R3PzY-0000zv-6m for xen-devel@lists.xensource.com; Tue, 13 Sep 2011 03:13:24 -0700 X-Env-Sender: fbcyborg@gmail.com X-Msg-Ref: server-6.tower-216.messagelabs.com!1315908800!16807058!1 X-Originating-IP: [209.85.212.47] X-StarScan-Version: 6.3.6; banners=-,-,- X-VirusChecked: Checked Received: (qmail 6642 invoked from network); 13 Sep 2011 10:13:21 -0000 Received: from mail-vw0-f47.google.com (HELO mail-vw0-f47.google.com) (209.85.212.47) by server-6.tower-216.messagelabs.com with RC4-SHA encrypted SMTP; 13 Sep 2011 10:13:21 -0000 Received: by vwe42 with SMTP id 42so956113vwe.6 for ; Tue, 13 Sep 2011 03:13:19 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=ETNYByHMMul/LUdrQejX1B/rUrOb/GDhZbQPQxXY87g=; b=R8ij4xC8pRGpbGD+QyX8q3OUO6furZY8M6kvIEBKn1RKgXUiwRXsMKMqIJ/vzzLh0P mlDUEJvl4QADWCMKZbBBp51RM22pZC23HoCGaGLF2BA3heZOcXN0DpBIXCvb3qjNHsHl tR5Du6DGEg8AqN4WSAaMdQerWHcxDEOuiINO0= Received: by 10.220.141.195 with SMTP id n3mr1231488vcu.152.1315908448120; Tue, 13 Sep 2011 03:07:28 -0700 (PDT) MIME-Version: 1.0 Received: by 10.220.108.72 with HTTP; Tue, 13 Sep 2011 03:07:08 -0700 (PDT) In-Reply-To: <1315907178.2892.7.camel@cthulhu.hellion.org.uk> References: <1315907178.2892.7.camel@cthulhu.hellion.org.uk> From: Flavio Date: Tue, 13 Sep 2011 12:07:08 +0200 Message-ID: Subject: Re: [Xen-devel] Help with the migration to XEN-4.1 please To: Ian Campbell Content-Type: text/plain; charset=ISO-8859-1 Cc: xen-devel@lists.xensource.com X-BeenThere: xen-devel@lists.xensource.com X-Mailman-Version: 2.1.5 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xensource.com Errors-To: xen-devel-bounces@lists.xensource.com On 13 September 2011 11:46, Ian Campbell wrote: > I'm afraid that xl does not support this style of "managed" domain. > The /etc/xen/auto type stuff ought to still work although there have > been a bunch of fixes to that recently, I think they are all queued for > 4.1.2 but it might be worth confirming that tools/hotplug in your tree > looks similar to that in xen-unstable.hg Thank you for replying Ian, ok. >> 2) If I try to run a gentoo linux guest (for instance) running >> 'xl vm_config_file.cfg -c' I get the following error: > > You mean 'xl create vm_config....'? Yes, please excuse me, it was a typing error. > > Did you start xenstored and xenconsoled? Of course yes. I added xendomains in the default runlevel, which strictly depends on xenstored and xenconsoled as you know. And it has been the first check I've done once I encountered that problem. > i.e. did you add the > "xencommons" initscript to your startup? I don't know if it is a bug or something missing in the gentoo package of xen-tools but I don't have any inistscript called xencommons in my /etc/init.d directory. I only have the file /etc/xen/xencommons configuration file on my system. > >> 3) the network for the guest OS doesn't work, even the xenbr0 is up >> and the vm configuration file >> explicitly says it has to use that bridge. Furthermore, due to the >> error at point 2, I can't see anything >> in the VM. >> I also tried to add the following line in the /etc/xen/xl.conf but the >> network doesn't work anyway: >> vifscript="vif-bridge" > >> >> 4) xl shutdown seems to be not working. I have to >> destroy the VM in order to have it powered off. >> >> Can somebody help me to correct these problems please? > > Both of these sound as if xenstored is not working properly for you. Is > it running? Of course it is. The virtual machines start, but they are not accessible via ssh due to the network issue or console for the error reported above. > You didn't restart it did you? (you cannot restart > xenstored, unfortunately if you did this you need to reboot). :-| I can reboot, but it doesn't solve the problem so. > > Did you also change kernel when you moved to 4.1? No, before installing XEN on this system I installed the gentoo-sources-3.0.4 kernel. To be honest, if I remember correctly I already had xen-tools and xen 4.1.1 as a first install on my system. Now I have 4.1.1-r3. At the beginning, prior the migration I was using xm and the VMs were starting without any problem, and the network was working too through the bridge. > Do you have > the /dev/xen nodes, especially evtchn loaded and available? I only have evtchn under /dev/xen. > With pvops > many kernels are more standard distro kernels rather than xen-specific > and therefore stuff which was historically statically built in to the > kernel are now modular. So do you mean I have to check my kernel configuration or add/remove something, or make it as module? Thank you very much, -- Flavio _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel From xen-devel-bounces@lists.xensource.com Tue Sep 13 03:42:46 2011 Return-path: Envelope-to: www-data@lists.xensource.com Delivery-date: Tue, 13 Sep 2011 03:42:46 -0700 Received: from localhost ([127.0.0.1] helo=lists.colo.xensource.com) by lists.xensource.com with esmtp (Exim 4.43) id 1R3QRx-0002D7-TL; Tue, 13 Sep 2011 03:42:45 -0700 Received: from mail216.messagelabs.com ([85.158.143.99]) by lists.xensource.com with esmtp (Exim 4.43) id 1R3QRB-00020Y-G9 for xen-devel@lists.xensource.com; Tue, 13 Sep 2011 03:42:00 -0700 X-Env-Sender: juergen.gross@ts.fujitsu.com X-Msg-Ref: server-5.tower-216.messagelabs.com!1315910399!17569631!1 X-Originating-IP: [80.70.172.51] X-StarScan-Version: 6.3.6; banners=-,-,- X-VirusChecked: Checked Received: (qmail 27894 invoked from network); 13 Sep 2011 10:40:00 -0000 Received: from dgate20.ts.fujitsu.com (HELO dgate20.ts.fujitsu.com) (80.70.172.51) by server-5.tower-216.messagelabs.com with RC4-SHA encrypted SMTP; 13 Sep 2011 10:40:00 -0000 DomainKey-Signature: s=s1536a; d=ts.fujitsu.com; c=nofws; q=dns; h=X-SBRSScore:X-IronPort-AV:Received:X-IronPort-AV: Received:Received:Content-Type:MIME-Version:Subject: X-Mercurial-Node:Message-Id:Date:From:To; b=puqI2P4Ku9/h2KHwwfaEqNFpFPhaaQw94R+6Apdvcl7CAgMHzyjgfC6u nl6avQOq1Xqxo8FH/2Bg6CYiU9Em7OY+/BCVONa4NHj02wLcXLve78RFH 2CKR/9jjNaHLVzXe9Zq4eCNT5O2VoXeG43GhQO92HVm8ZKLEf+bIp/y/b oBH8bR+aCdjMJ1WKX3Co3jPqygOheJqldRKfFgABsjEewC9zG21b0fZXJ 6xBpVc8/83UFeHwQMQDkP5E2ROXgD; DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=ts.fujitsu.com; i=juergen.gross@ts.fujitsu.com; q=dns/txt; s=s1536b; t=1315910400; x=1347446400; h=mime-version:subject:message-id:date:from:to; bh=qunIxFt2DdZXyljt3hJEqBuyiWRdfqbe/ZG8inLRnH4=; b=A5dQPTNyfYPr8BwUs7LJtIOWlItayHf+PykMFsuyYNZFfZJNdj/Dqtw1 a1gKd6m9dtfDfhdmuDGyLk4JmTEDExXlrqUVgNM04UhD7JfDEaRhfLxei 9+ziSE42zPNBILIqikGYrbgnr5BC28y5cXUOdyZmxYiwqy3NsPw76l9i1 JXPuguqSfMM766uWDNaqnNtDPir8VwnZAPWEi8JKFCZC199zAVhKy9BN6 FWKZYubh3/FpnATr+MGAIJG4R91dp; X-SBRSScore: None X-IronPort-AV: E=Sophos;i="4.68,373,1312149600"; d="scan'208";a="74276482" Received: from abgdgate40u.abg.fsc.net ([172.25.138.90]) by dgate20u.abg.fsc.net with ESMTP; 13 Sep 2011 12:39:59 +0200 X-IronPort-AV: E=Sophos;i="4.68,373,1312149600"; d="scan'208";a="120065409" Received: from sanpedro.mch.fsc.net ([172.17.20.6]) by abgdgate40u.abg.fsc.net with ESMTP; 13 Sep 2011 12:39:59 +0200 Received: from [172.17.21.25] (nehalem1.osd.mch.fsc.net [172.17.21.25]) by sanpedro.mch.fsc.net (Postfix) with ESMTP id 7A77256A5E3; Tue, 13 Sep 2011 12:39:59 +0200 (CEST) Content-Type: multipart/mixed; boundary="===============3026161607226046105==" MIME-Version: 1.0 X-Mercurial-Node: 86f2a3a45ecbcc49aba88d06bf13bbcaf5a9b89b Message-Id: <86f2a3a45ecbcc49aba8.1315910179@nehalem1> Date: Tue, 13 Sep 2011 12:36:19 +0200 From: Juergen Gross To: xen-devel@lists.xensource.com Subject: [Xen-devel] [PATCH] Avoid race in schedule() when switching schedulers X-BeenThere: xen-devel@lists.xensource.com X-Mailman-Version: 2.1.5 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xensource.com Errors-To: xen-devel-bounces@lists.xensource.com --===============3026161607226046105== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Selecting the scheduler to call must be done under lock. Otherwise a race might occur when switching schedulers in a cpupool Signed-off-by: juergen.gross@ts.fujitsu.com 1 file changed, 2 insertions(+), 1 deletion(-) xen/common/schedule.c | 3 ++- --===============3026161607226046105== Content-Type: text/x-patch; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=xen-staging.hg.patch # HG changeset patch # User Juergen Gross # Date 1315910154 -7200 # Node ID 86f2a3a45ecbcc49aba88d06bf13bbcaf5a9b89b # Parent 64aab9a077ea937b31fd678b02f755139b924184 Avoid race in schedule() when switching schedulers Selecting the scheduler to call must be done under lock. Otherwise a race might occur when switching schedulers in a cpupool Signed-off-by: juergen.gross@ts.fujitsu.com diff -r 64aab9a077ea -r 86f2a3a45ecb xen/common/schedule.c --- a/xen/common/schedule.c Tue Sep 13 11:20:57 2011 +0100 +++ b/xen/common/schedule.c Tue Sep 13 12:35:54 2011 +0200 @@ -1107,7 +1107,7 @@ static void schedule(void) { struct vcpu *prev = current, *next = NULL; s_time_t now = NOW(); - struct scheduler *sched = this_cpu(scheduler); + struct scheduler *sched; unsigned long *tasklet_work = &this_cpu(tasklet_work_to_do); bool_t tasklet_work_scheduled = 0; struct schedule_data *sd; @@ -1141,6 +1141,7 @@ static void schedule(void) stop_timer(&sd->s_timer); /* get policy-specific decision on scheduling... */ + sched = this_cpu(scheduler); next_slice = sched->do_schedule(sched, now, tasklet_work_scheduled); next = next_slice.task; --===============3026161607226046105== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel --===============3026161607226046105==-- From xen-devel-bounces@lists.xensource.com Tue Sep 13 03:54:20 2011 Return-path: Envelope-to: www-data@lists.xensource.com Delivery-date: Tue, 13 Sep 2011 03:54:20 -0700 Received: from localhost ([127.0.0.1] helo=lists.colo.xensource.com) by lists.xensource.com with esmtp (Exim 4.43) id 1R3Qd9-0002lg-JR; Tue, 13 Sep 2011 03:54:19 -0700 Received: from mail27.messagelabs.com ([193.109.254.147]) by lists.xensource.com with esmtp (Exim 4.43) id 1R3QcL-0002Z2-G1 for xen-devel@lists.xensource.com; Tue, 13 Sep 2011 03:53:30 -0700 X-Env-Sender: JBeulich@suse.com X-Msg-Ref: server-8.tower-27.messagelabs.com!1315911191!46376012!1 X-Originating-IP: [130.57.49.28] X-StarScan-Version: 6.3.6; banners=-,-,- X-VirusChecked: Checked Received: (qmail 27806 invoked from network); 13 Sep 2011 10:53:11 -0000 Received: from nat28.tlf.novell.com (HELO nat28.tlf.novell.com) (130.57.49.28) by server-8.tower-27.messagelabs.com with DHE-RSA-AES256-SHA encrypted SMTP; 13 Sep 2011 10:53:11 -0000 Received: from EMEA1-MTA by nat28.tlf.novell.com with Novell_GroupWise; Tue, 13 Sep 2011 11:53:27 +0100 Message-Id: <4E6F52430200007800055D18@nat28.tlf.novell.com> X-Mailer: Novell GroupWise Internet Agent 8.0.1 Date: Tue, 13 Sep 2011 11:53:23 +0100 From: "Jan Beulich" To: "George Dunlap" Subject: Re: [Xen-devel] [PATCH] xen, vtd: Fix device check for devices behind PCIe-to-PCI bridges References: In-Reply-To: Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: quoted-printable Content-Disposition: inline Cc: xen-devel@lists.xensource.com, Keir Fraser X-BeenThere: xen-devel@lists.xensource.com X-Mailman-Version: 2.1.5 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xensource.com Errors-To: xen-devel-bounces@lists.xensource.com >>> On 13.09.11 at 11:12, George Dunlap = wrote: > So what was the verdict on this one? Is someone going to commit to > doing a "fake pdev" thing? If that's not going to happen before the > 4.2 release, I suggest we take this patch in the mean time. Isn't this -unstable c/s 23813:5535d7ce2673? Jan > On Thu, Sep 1, 2011 at 3:20 PM, George Dunlap > wrote: >> On some systems, requests devices behind a PCIe-to-PCI bridge all >> appear to the IOMMU as though they come from from slot 0, function >> 0 on that device; so the mapping code much punch a hole for X:0.0 >> in the IOMMU for such devices. When punching the hole, if that device >> has already been mapped once, we simply need to check ownership to >> make sure it's legal. To do so, domain_context_mapping_one() will look >> up the device for the mapping with pci_get_pdev() and look for the = owner. >> >> However, if there is no device in X:0.0, this look up will fail. >> >> Rather than returning -ENODEV in this situation (causing a failure in >> mapping the device), try to get the domain ownership from the iommu = context >> mapping itself. >> >> Signed-off-by: George Dunlap >> >> diff -r 4a4882df5649 -r ede81b0552be xen/drivers/passthrough/vtd/iommu.c= >> --- a/xen/drivers/passthrough/vtd/iommu.c Wed Aug 31 15:23:49 = 2011 +0100 >> +++ b/xen/drivers/passthrough/vtd/iommu.c Thu Sep 01 15:18:18 = 2011=20 > +0100 >> @@ -113,6 +113,27 @@ static int context_set_domain_id(struct >> return 0; >> } >> >> +static int context_get_domain_id(struct context_entry *context, >> + struct iommu *iommu) >> +{ >> + unsigned long dom_index, nr_dom; >> + int domid =3D -1; >> + >> + if (iommu && context) >> + { >> + nr_dom =3D cap_ndoms(iommu->cap); >> + >> + dom_index =3D context_domain_id(*context); >> + >> + if ( dom_index < nr_dom && iommu->domid_map) >> + domid =3D iommu->domid_map[dom_index]; >> + else >> + dprintk(XENLOG_DEBUG VTDPREFIX, "%s: dom_index %lu = exceeds=20 > nr_dom %lu or iommu has no domid_map\n", >> + __func__, dom_index, nr_dom); >> + } >> + return domid; >> +} >> + >> static struct intel_iommu *__init alloc_intel_iommu(void) >> { >> struct intel_iommu *intel; >> @@ -1237,7 +1258,6 @@ int domain_context_mapping_one( >> struct hvm_iommu *hd =3D domain_hvm_iommu(domain); >> struct context_entry *context, *context_entries; >> u64 maddr, pgd_maddr; >> - struct pci_dev *pdev =3D NULL; >> int agaw; >> >> ASSERT(spin_is_locked(&pcidevs_lock)); >> @@ -1249,12 +1269,45 @@ int domain_context_mapping_one( >> if ( context_present(*context) ) >> { >> int res =3D 0; >> + struct pci_dev *pdev =3D NULL; >> >> + /* First try to get domain ownership from device structure. = If=20 > that's >> + * not available, try to read it from the context itself. */ >> pdev =3D pci_get_pdev(bus, devfn); >> - if (!pdev) >> - res =3D -ENODEV; >> - else if (pdev->domain !=3D domain) >> - res =3D -EINVAL; >> + if ( pdev ) >> + { >> + if ( pdev->domain !=3D domain ) >> + { >> + dprintk(XENLOG_INFO VTDPREFIX, "d%d: bdf =3D %x:%x.%x = owned=20 > by d%d!", >> + domain->domain_id, >> + bus, PCI_SLOT(devfn), PCI_FUNC(devfn), >> + (pdev->domain) >> + ? pdev->domain->domain_id : -1); >> + res =3D -EINVAL; >> + } >> + } >> + else >> + { >> + int cdomain; >> + cdomain =3D context_get_domain_id(context, iommu); >> + >> + if ( cdomain < 0 ) >> + { >> + dprintk(VTDPREFIX, "d%d: bdf =3D %x:%x.%x mapped, but = can't=20 > find owner!\n", >> + domain->domain_id, >> + bus, PCI_SLOT(devfn), PCI_FUNC(devfn)); >> + res =3D -EINVAL; >> + } >> + else if ( cdomain !=3D domain->domain_id ) >> + { >> + dprintk(XENLOG_INFO VTDPREFIX, "d%d: bdf =3D %x:%x.%x = already=20 > mapped to d%d!", >> + domain->domain_id, >> + bus, PCI_SLOT(devfn), PCI_FUNC(devfn), >> + cdomain); >> + res =3D -EINVAL; >> + } >> + } >> + >> unmap_vtd_domain_page(context_entries); >> spin_unlock(&iommu->lock); >> return res; >> >> _______________________________________________ >> Xen-devel mailing list >> Xen-devel@lists.xensource.com=20 >> http://lists.xensource.com/xen-devel=20 >> _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel From xen-devel-bounces@lists.xensource.com Tue Sep 13 04:06:42 2011 Return-path: Envelope-to: www-data@lists.xensource.com Delivery-date: Tue, 13 Sep 2011 04:06:42 -0700 Received: from localhost ([127.0.0.1] helo=lists.colo.xensource.com) by lists.xensource.com with esmtp (Exim 4.43) id 1R3Qp7-0003YE-3M; Tue, 13 Sep 2011 04:06:41 -0700 Received: from mail182.messagelabs.com ([85.158.139.83]) by lists.xensource.com with esmtp (Exim 4.43) id 1R3QoF-0003H8-RM for xen-devel@lists.xensource.com; Tue, 13 Sep 2011 04:05:48 -0700 X-Env-Sender: david.vrabel@citrix.com X-Msg-Ref: server-5.tower-182.messagelabs.com!1315911943!13146122!1 X-Originating-IP: [66.165.176.63] X-StarScan-Version: 6.3.6; banners=-,-,- X-VirusChecked: Checked Received: (qmail 8057 invoked from network); 13 Sep 2011 11:05:44 -0000 Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63) by server-5.tower-182.messagelabs.com with RC4-SHA encrypted SMTP; 13 Sep 2011 11:05:44 -0000 X-IronPort-AV: E=Sophos;i="4.68,373,1312171200"; d="scan'208";a="162722539" Received: from ftlpmailmx01.citrite.net ([10.13.107.65]) by FTLPIPO02.CITRIX.COM with ESMTP/TLS/RC4-MD5; 13 Sep 2011 07:05:42 -0400 Received: from smtp01.ad.xensource.com (10.219.128.104) by smtprelay.citrix.com (10.13.107.65) with Microsoft SMTP Server id 8.3.137.0; Tue, 13 Sep 2011 07:05:42 -0400 Received: from minsc.citrite.net ([10.31.1.113]) by smtp01.ad.xensource.com (8.13.1/8.13.1) with ESMTP id p8DB5emX020940; Tue, 13 Sep 2011 04:05:41 -0700 From: David Vrabel To: xen-devel@lists.xensource.com Date: Tue, 13 Sep 2011 12:05:20 +0100 Message-ID: <1315911922-4855-1-git-send-email-david.vrabel@citrix.com> X-Mailer: git-send-email 1.7.2.5 MIME-Version: 1.0 Content-Type: text/plain Cc: Konrad Rzeszutek Wilk Subject: [Xen-devel] Use xenbus API for mapping foreign pages X-BeenThere: xen-devel@lists.xensource.com X-Mailman-Version: 2.1.5 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xensource.com Errors-To: xen-devel-bounces@lists.xensource.com Xenbus provides an API for mapping foreign pages. Make use of it in the netback and blkback drivers so when the method for mapping foreign pages is changed it only need to be updated in one place. David _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel From xen-devel-bounces@lists.xensource.com Tue Sep 13 04:07:58 2011 Return-path: Envelope-to: www-data@lists.xensource.com Delivery-date: Tue, 13 Sep 2011 04:07:58 -0700 Received: from localhost ([127.0.0.1] helo=lists.colo.xensource.com) by lists.xensource.com with esmtp (Exim 4.43) id 1R3QqM-0003vX-9C; Tue, 13 Sep 2011 04:07:58 -0700 Received: from mail182.messagelabs.com ([85.158.139.83]) by lists.xensource.com with esmtp (Exim 4.43) id 1R3QoH-0003H9-FP for xen-devel@lists.xensource.com; Tue, 13 Sep 2011 04:05:50 -0700 X-Env-Sender: david.vrabel@citrix.com X-Msg-Ref: server-5.tower-182.messagelabs.com!1315911943!13146122!2 X-Originating-IP: [66.165.176.63] X-StarScan-Version: 6.3.6; banners=-,-,- X-VirusChecked: Checked Received: (qmail 8147 invoked from network); 13 Sep 2011 11:05:46 -0000 Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63) by server-5.tower-182.messagelabs.com with RC4-SHA encrypted SMTP; 13 Sep 2011 11:05:46 -0000 X-IronPort-AV: E=Sophos;i="4.68,373,1312171200"; d="scan'208";a="162722543" Received: from ftlpmailmx01.citrite.net ([10.13.107.65]) by FTLPIPO02.CITRIX.COM with ESMTP/TLS/RC4-MD5; 13 Sep 2011 07:05:45 -0400 Received: from smtp01.ad.xensource.com (10.219.128.104) by smtprelay.citrix.com (10.13.107.65) with Microsoft SMTP Server id 8.3.137.0; Tue, 13 Sep 2011 07:05:45 -0400 Received: from minsc.citrite.net ([10.31.1.113]) by smtp01.ad.xensource.com (8.13.1/8.13.1) with ESMTP id p8DB5emZ020940; Tue, 13 Sep 2011 04:05:44 -0700 From: David Vrabel To: xen-devel@lists.xensource.com Date: Tue, 13 Sep 2011 12:05:22 +0100 Message-ID: <1315911922-4855-3-git-send-email-david.vrabel@citrix.com> X-Mailer: git-send-email 1.7.2.5 In-Reply-To: <1315911922-4855-1-git-send-email-david.vrabel@citrix.com> References: <1315911922-4855-1-git-send-email-david.vrabel@citrix.com> MIME-Version: 1.0 Content-Type: text/plain Cc: Ian Campbell , David Vrabel , Konrad Rzeszutek Wilk Subject: [Xen-devel] [PATCH 2/2] net: xen-netback: use API provided by xenbus module to map rings X-BeenThere: xen-devel@lists.xensource.com X-Mailman-Version: 2.1.5 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xensource.com Errors-To: xen-devel-bounces@lists.xensource.com From: David Vrabel The xenbus module provides xenbus_map_ring_valloc() and xenbus_map_ring_vfree(). Use these to map the Tx and Rx ring pages granted by the frontend. Signed-off-by: David Vrabel Cc: Ian Campbell --- drivers/net/xen-netback/common.h | 11 ++--- drivers/net/xen-netback/netback.c | 80 ++++++++----------------------------- 2 files changed, 22 insertions(+), 69 deletions(-) diff --git a/drivers/net/xen-netback/common.h b/drivers/net/xen-netback/common.h index 161f207..94b79c3 100644 --- a/drivers/net/xen-netback/common.h +++ b/drivers/net/xen-netback/common.h @@ -58,10 +58,6 @@ struct xenvif { u8 fe_dev_addr[6]; /* Physical parameters of the comms window. */ - grant_handle_t tx_shmem_handle; - grant_ref_t tx_shmem_ref; - grant_handle_t rx_shmem_handle; - grant_ref_t rx_shmem_ref; unsigned int irq; /* List of frontends to notify after a batch of frames sent. */ @@ -70,8 +66,6 @@ struct xenvif { /* The shared rings and indexes. */ struct xen_netif_tx_back_ring tx; struct xen_netif_rx_back_ring rx; - struct vm_struct *tx_comms_area; - struct vm_struct *rx_comms_area; /* Frontend feature information. */ u8 can_sg:1; @@ -106,6 +100,11 @@ struct xenvif { wait_queue_head_t waiting_to_free; }; +static inline struct xenbus_device *xenvif_to_xenbus_device(struct xenvif *vif) +{ + return to_xenbus_device(vif->dev->dev.parent); +} + #define XEN_NETIF_TX_RING_SIZE __CONST_RING_SIZE(xen_netif_tx, PAGE_SIZE) #define XEN_NETIF_RX_RING_SIZE __CONST_RING_SIZE(xen_netif_rx, PAGE_SIZE) diff --git a/drivers/net/xen-netback/netback.c b/drivers/net/xen-netback/netback.c index fd00f25..3af2924 100644 --- a/drivers/net/xen-netback/netback.c +++ b/drivers/net/xen-netback/netback.c @@ -1577,88 +1577,42 @@ static int xen_netbk_kthread(void *data) void xen_netbk_unmap_frontend_rings(struct xenvif *vif) { - struct gnttab_unmap_grant_ref op; - - if (vif->tx.sring) { - gnttab_set_unmap_op(&op, (unsigned long)vif->tx_comms_area->addr, - GNTMAP_host_map, vif->tx_shmem_handle); - - if (HYPERVISOR_grant_table_op(GNTTABOP_unmap_grant_ref, &op, 1)) - BUG(); - } - - if (vif->rx.sring) { - gnttab_set_unmap_op(&op, (unsigned long)vif->rx_comms_area->addr, - GNTMAP_host_map, vif->rx_shmem_handle); - - if (HYPERVISOR_grant_table_op(GNTTABOP_unmap_grant_ref, &op, 1)) - BUG(); - } - if (vif->rx_comms_area) - free_vm_area(vif->rx_comms_area); - if (vif->tx_comms_area) - free_vm_area(vif->tx_comms_area); + if (vif->tx.sring) + xenbus_unmap_ring_vfree(xenvif_to_xenbus_device(vif), + vif->tx.sring); + if (vif->rx.sring) + xenbus_unmap_ring_vfree(xenvif_to_xenbus_device(vif), + vif->rx.sring); } int xen_netbk_map_frontend_rings(struct xenvif *vif, grant_ref_t tx_ring_ref, grant_ref_t rx_ring_ref) { - struct gnttab_map_grant_ref op; + void *addr; struct xen_netif_tx_sring *txs; struct xen_netif_rx_sring *rxs; int err = -ENOMEM; - vif->tx_comms_area = alloc_vm_area(PAGE_SIZE); - if (vif->tx_comms_area == NULL) + err = xenbus_map_ring_valloc(xenvif_to_xenbus_device(vif), + tx_ring_ref, &addr); + if (err) goto err; - vif->rx_comms_area = alloc_vm_area(PAGE_SIZE); - if (vif->rx_comms_area == NULL) - goto err; - - gnttab_set_map_op(&op, (unsigned long)vif->tx_comms_area->addr, - GNTMAP_host_map, tx_ring_ref, vif->domid); - - if (HYPERVISOR_grant_table_op(GNTTABOP_map_grant_ref, &op, 1)) - BUG(); - - if (op.status) { - netdev_warn(vif->dev, - "failed to map tx ring. err=%d status=%d\n", - err, op.status); - err = op.status; - goto err; - } - - vif->tx_shmem_ref = tx_ring_ref; - vif->tx_shmem_handle = op.handle; - - txs = (struct xen_netif_tx_sring *)vif->tx_comms_area->addr; + txs = (struct xen_netif_tx_sring *)addr; BACK_RING_INIT(&vif->tx, txs, PAGE_SIZE); - gnttab_set_map_op(&op, (unsigned long)vif->rx_comms_area->addr, - GNTMAP_host_map, rx_ring_ref, vif->domid); - - if (HYPERVISOR_grant_table_op(GNTTABOP_map_grant_ref, &op, 1)) - BUG(); - - if (op.status) { - netdev_warn(vif->dev, - "failed to map rx ring. err=%d status=%d\n", - err, op.status); - err = op.status; + err = xenbus_map_ring_valloc(xenvif_to_xenbus_device(vif), + rx_ring_ref, &addr); + if (err) goto err; - } - - vif->rx_shmem_ref = rx_ring_ref; - vif->rx_shmem_handle = op.handle; - vif->rx_req_cons_peek = 0; - rxs = (struct xen_netif_rx_sring *)vif->rx_comms_area->addr; + rxs = (struct xen_netif_rx_sring *)addr; BACK_RING_INIT(&vif->rx, rxs, PAGE_SIZE); + vif->rx_req_cons_peek = 0; + return 0; err: -- 1.7.2.5 _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel From xen-devel-bounces@lists.xensource.com Tue Sep 13 04:09:59 2011 Return-path: Envelope-to: www-data@lists.xensource.com Delivery-date: Tue, 13 Sep 2011 04:09:59 -0700 Received: from localhost ([127.0.0.1] helo=lists.colo.xensource.com) by lists.xensource.com with esmtp (Exim 4.43) id 1R3QsI-0004LU-Lh; Tue, 13 Sep 2011 04:09:59 -0700 Received: from mail21.messagelabs.com ([85.158.143.35]) by lists.xensource.com with esmtp (Exim 4.43) id 1R3QoJ-0003HF-VU for xen-devel@lists.xensource.com; Tue, 13 Sep 2011 04:05:52 -0700 X-Env-Sender: david.vrabel@citrix.com X-Msg-Ref: server-5.tower-21.messagelabs.com!1315911912!47927917!1 X-Originating-IP: [66.165.176.89] X-StarScan-Version: 6.4.1; banners=-,-,- X-VirusChecked: Checked Received: (qmail 24523 invoked from network); 13 Sep 2011 11:05:14 -0000 Received: from smtp.citrix.com (HELO SMTP.CITRIX.COM) (66.165.176.89) by server-5.tower-21.messagelabs.com with RC4-SHA encrypted SMTP; 13 Sep 2011 11:05:14 -0000 X-IronPort-AV: E=Sophos;i="4.68,373,1312171200"; d="scan'208";a="16919044" Received: from ftlpmailmx01.citrite.net ([10.13.107.65]) by FTLPIPO01.CITRIX.COM with ESMTP/TLS/RC4-MD5; 13 Sep 2011 07:05:44 -0400 Received: from smtp01.ad.xensource.com (10.219.128.104) by smtprelay.citrix.com (10.13.107.65) with Microsoft SMTP Server id 8.3.137.0; Tue, 13 Sep 2011 07:05:43 -0400 Received: from minsc.citrite.net ([10.31.1.113]) by smtp01.ad.xensource.com (8.13.1/8.13.1) with ESMTP id p8DB5emY020940; Tue, 13 Sep 2011 04:05:42 -0700 From: David Vrabel To: xen-devel@lists.xensource.com Date: Tue, 13 Sep 2011 12:05:21 +0100 Message-ID: <1315911922-4855-2-git-send-email-david.vrabel@citrix.com> X-Mailer: git-send-email 1.7.2.5 In-Reply-To: <1315911922-4855-1-git-send-email-david.vrabel@citrix.com> References: <1315911922-4855-1-git-send-email-david.vrabel@citrix.com> MIME-Version: 1.0 Content-Type: text/plain Cc: David Vrabel , Konrad Rzeszutek Wilk Subject: [Xen-devel] [PATCH 1/2] block: xen-blkback: use API provided by xenbus module to map rings X-BeenThere: xen-devel@lists.xensource.com X-Mailman-Version: 2.1.5 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xensource.com Errors-To: xen-devel-bounces@lists.xensource.com From: David Vrabel The xenbus module provides xenbus_map_ring_valloc() and xenbus_map_ring_vfree(). Use these to map the ring pages granted by the frontend. Signed-off-by: David Vrabel --- drivers/block/xen-blkback/common.h | 5 +-- drivers/block/xen-blkback/xenbus.c | 54 ++++------------------------------- 2 files changed, 8 insertions(+), 51 deletions(-) diff --git a/drivers/block/xen-blkback/common.h b/drivers/block/xen-blkback/common.h index 9e40b28..07dd177 100644 --- a/drivers/block/xen-blkback/common.h +++ b/drivers/block/xen-blkback/common.h @@ -139,7 +139,7 @@ struct xen_blkif { /* Comms information. */ enum blkif_protocol blk_protocol; union blkif_back_rings blk_rings; - struct vm_struct *blk_ring_area; + void *blk_ring; /* The VBD attached to this interface. */ struct xen_vbd vbd; /* Back pointer to the backend_info. */ @@ -163,9 +163,6 @@ struct xen_blkif { int st_wr_sect; wait_queue_head_t waiting_to_free; - - grant_handle_t shmem_handle; - grant_ref_t shmem_ref; }; diff --git a/drivers/block/xen-blkback/xenbus.c b/drivers/block/xen-blkback/xenbus.c index 3f129b4..73703d5 100644 --- a/drivers/block/xen-blkback/xenbus.c +++ b/drivers/block/xen-blkback/xenbus.c @@ -120,38 +120,6 @@ static struct xen_blkif *xen_blkif_alloc(domid_t domid) return blkif; } -static int map_frontend_page(struct xen_blkif *blkif, unsigned long shared_page) -{ - struct gnttab_map_grant_ref op; - - gnttab_set_map_op(&op, (unsigned long)blkif->blk_ring_area->addr, - GNTMAP_host_map, shared_page, blkif->domid); - - if (HYPERVISOR_grant_table_op(GNTTABOP_map_grant_ref, &op, 1)) - BUG(); - - if (op.status) { - DPRINTK("Grant table operation failure !\n"); - return op.status; - } - - blkif->shmem_ref = shared_page; - blkif->shmem_handle = op.handle; - - return 0; -} - -static void unmap_frontend_page(struct xen_blkif *blkif) -{ - struct gnttab_unmap_grant_ref op; - - gnttab_set_unmap_op(&op, (unsigned long)blkif->blk_ring_area->addr, - GNTMAP_host_map, blkif->shmem_handle); - - if (HYPERVISOR_grant_table_op(GNTTABOP_unmap_grant_ref, &op, 1)) - BUG(); -} - static int xen_blkif_map(struct xen_blkif *blkif, unsigned long shared_page, unsigned int evtchn) { @@ -161,35 +129,29 @@ static int xen_blkif_map(struct xen_blkif *blkif, unsigned long shared_page, if (blkif->irq) return 0; - blkif->blk_ring_area = alloc_vm_area(PAGE_SIZE); - if (!blkif->blk_ring_area) - return -ENOMEM; - - err = map_frontend_page(blkif, shared_page); - if (err) { - free_vm_area(blkif->blk_ring_area); + err = xenbus_map_ring_valloc(blkif->be->dev, shared_page, &blkif->blk_ring); + if (err < 0) return err; - } switch (blkif->blk_protocol) { case BLKIF_PROTOCOL_NATIVE: { struct blkif_sring *sring; - sring = (struct blkif_sring *)blkif->blk_ring_area->addr; + sring = (struct blkif_sring *)blkif->blk_ring; BACK_RING_INIT(&blkif->blk_rings.native, sring, PAGE_SIZE); break; } case BLKIF_PROTOCOL_X86_32: { struct blkif_x86_32_sring *sring_x86_32; - sring_x86_32 = (struct blkif_x86_32_sring *)blkif->blk_ring_area->addr; + sring_x86_32 = (struct blkif_x86_32_sring *)blkif->blk_ring; BACK_RING_INIT(&blkif->blk_rings.x86_32, sring_x86_32, PAGE_SIZE); break; } case BLKIF_PROTOCOL_X86_64: { struct blkif_x86_64_sring *sring_x86_64; - sring_x86_64 = (struct blkif_x86_64_sring *)blkif->blk_ring_area->addr; + sring_x86_64 = (struct blkif_x86_64_sring *)blkif->blk_ring; BACK_RING_INIT(&blkif->blk_rings.x86_64, sring_x86_64, PAGE_SIZE); break; } @@ -201,8 +163,7 @@ static int xen_blkif_map(struct xen_blkif *blkif, unsigned long shared_page, xen_blkif_be_int, 0, "blkif-backend", blkif); if (err < 0) { - unmap_frontend_page(blkif); - free_vm_area(blkif->blk_ring_area); + xenbus_unmap_ring_vfree(blkif->be->dev, blkif->blk_ring); blkif->blk_rings.common.sring = NULL; return err; } @@ -228,8 +189,7 @@ static void xen_blkif_disconnect(struct xen_blkif *blkif) } if (blkif->blk_rings.common.sring) { - unmap_frontend_page(blkif); - free_vm_area(blkif->blk_ring_area); + xenbus_unmap_ring_vfree(blkif->be->dev, blkif->blk_ring); blkif->blk_rings.common.sring = NULL; } } -- 1.7.2.5 _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel From xen-devel-bounces@lists.xensource.com Tue Sep 13 04:12:54 2011 Return-path: Envelope-to: www-data@lists.xensource.com Delivery-date: Tue, 13 Sep 2011 04:12:54 -0700 Received: from localhost ([127.0.0.1] helo=lists.colo.xensource.com) by lists.xensource.com with esmtp (Exim 4.43) id 1R3Qv8-0004ly-3N; Tue, 13 Sep 2011 04:12:54 -0700 Received: from mail216.messagelabs.com ([85.158.143.99]) by lists.xensource.com with smtp (Exim 4.43) id 1R3QuQ-0004Zr-Ki for Xen-devel@lists.xensource.com; Tue, 13 Sep 2011 04:12:11 -0700 X-Env-Sender: sfr@canb.auug.org.au X-Msg-Ref: server-7.tower-216.messagelabs.com!1315912326!18085145!1 X-Originating-IP: [203.10.76.15] X-StarScan-Version: 6.3.6; banners=-,-,- X-VirusChecked: Checked Received: (qmail 26462 invoked from network); 13 Sep 2011 11:12:06 -0000 Received: from calzone.tip.net.au (HELO calzone.tip.net.au) (203.10.76.15) by server-7.tower-216.messagelabs.com with SMTP; 13 Sep 2011 11:12:06 -0000 Received: from canb.auug.org.au (ash.rothwell.emu.id.au [IPv6:2402:b800:7003:7010:223:14ff:fe30:c8e4]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by calzone.tip.net.au (Postfix) with ESMTPSA id AB52F128436; Tue, 13 Sep 2011 21:12:00 +1000 (EST) Date: Tue, 13 Sep 2011 21:11:54 +1000 From: Stephen Rothwell To: "H. Peter Anvin" Message-Id: <20110913211154.fe53ca8c1d608def77a69022@canb.auug.org.au> In-Reply-To: <20110826125441.709aa423cdf072ce085fb91c@canb.auug.org.au> References: <20110825142450.c84e02d8763cfd1a93411844@canb.auug.org.au> <4E5690C3.2050706@goop.org> <4E5693DD.2010307@zytor.com> <20110826090619.7588d424798f53a6f3621eb2@canb.auug.org.au> <4E56D6E1.6030405@zytor.com> <20110826125441.709aa423cdf072ce085fb91c@canb.auug.org.au> X-Mailer: Sylpheed 3.2.0beta3 (GTK+ 2.24.6; i486-pc-linux-gnu) Mime-Version: 1.0 Cc: Jeremy Fitzhardinge , Ingo, Peter Zijlstra , linux-kernel@vger.kernel.org, Xen Devel , linux-next@vger.kernel.org, Thomas Gleixner , Molnar Subject: [Xen-devel] Re: linux-next: manual merge of the xen tree with the tip tree X-BeenThere: xen-devel@lists.xensource.com X-Mailman-Version: 2.1.5 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0381580579==" Sender: xen-devel-bounces@lists.xensource.com Errors-To: xen-devel-bounces@lists.xensource.com --===============0381580579== Content-Type: multipart/signed; protocol="application/pgp-signature"; micalg="PGP-SHA1"; boundary="Signature=_Tue__13_Sep_2011_21_11_54_+1000_SXNVjjU1Z9dcqLFp" --Signature=_Tue__13_Sep_2011_21_11_54_+1000_SXNVjjU1Z9dcqLFp Content-Type: text/plain; charset=US-ASCII Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Hi, On Fri, 26 Aug 2011 12:54:41 +1000 Stephen Rothwell = wrote: > > On Thu, 25 Aug 2011 16:12:33 -0700 "H. Peter Anvin" wrote: > > > > On 08/25/2011 04:06 PM, Stephen Rothwell wrote: > > >> > > >> Stephen: the x86/spinlocks branch in the -tip tree is obsolete and > > >> should be dropped. > > >=20 > > > That's a bit tricky as I get a rolled up tip tree. The best I could = do > > > is revert the commit that merges the x86/spinlocks branch into > > > auto-latest ... I'll do that for today (unless something happens to = the > > > tip tree in the next hour). > > >=20 > >=20 > > OK, let me bother Ingo about it. >=20 > For today, I have done "git revert -m 1 6f8fa39c81f1" after merging the > tip tree. I am still doing this in each linux-next, and it doesn't appear to have been fixed up the the tree on tesla.tglx.de, yet, I think. --=20 Cheers, Stephen Rothwell sfr@canb.auug.org.au http://www.canb.auug.org.au/~sfr/ --Signature=_Tue__13_Sep_2011_21_11_54_+1000_SXNVjjU1Z9dcqLFp Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.11 (GNU/Linux) iQEcBAEBAgAGBQJObzp6AAoJEDMEi1NhKgbsM0sH/j3HijOarIxiI5SiFbEOXd0w /ca84Jd+zy69PVuwMUgna3Q6p31bgt28+URzvcdslvX7Ev9gJHyZsW+bLnAvlyci BAB1+XVFiYDoRTirUTQ7GGpIqSQ2XQkj0lFXnjr284mpi6Xy0a6JQXtCUVcu58GR Z/M4PgiCf5wdFLKDT/jrJ48B5XDR/nSfff8RX0CZKPXctqt4VmP5XrBVjBXGYwom db8XWffLGDfBpC3NaSmSBioLcZguI1BJO6/ONhveVUIpy1m52SDtz2e1si7KvmFt zxnHL+xVOyr/gsXmRODwXp+TqGM7MbB9PoDTEcZRp6Wd3q2ww4YmqIYtM4dYMq8= =V0pR -----END PGP SIGNATURE----- --Signature=_Tue__13_Sep_2011_21_11_54_+1000_SXNVjjU1Z9dcqLFp-- --===============0381580579== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel --===============0381580579==-- From xen-devel-bounces@lists.xensource.com Tue Sep 13 04:24:09 2011 Return-path: Envelope-to: www-data@lists.xensource.com Delivery-date: Tue, 13 Sep 2011 04:24:09 -0700 Received: from localhost ([127.0.0.1] helo=lists.colo.xensource.com) by lists.xensource.com with esmtp (Exim 4.43) id 1R3R61-0005O1-RX; Tue, 13 Sep 2011 04:24:09 -0700 Received: from mail216.messagelabs.com ([85.158.143.99]) by lists.xensource.com with esmtp (Exim 4.43) id 1R3R5P-0005BL-6A for xen-devel@lists.xensource.com; Tue, 13 Sep 2011 04:23:31 -0700 X-Env-Sender: Ian.Jackson@eu.citrix.com X-Msg-Ref: server-14.tower-216.messagelabs.com!1315913008!18090781!1 X-Originating-IP: [62.200.22.115] X-StarScan-Version: 6.3.6; banners=-,-,- X-VirusChecked: Checked Received: (qmail 31004 invoked from network); 13 Sep 2011 11:23:28 -0000 Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115) by server-14.tower-216.messagelabs.com with RC4-SHA encrypted SMTP; 13 Sep 2011 11:23:28 -0000 X-IronPort-AV: E=Sophos;i="4.68,374,1312156800"; d="scan'208";a="7758649" Received: from lonpmailmx01.citrite.net ([10.30.203.162]) by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5; 13 Sep 2011 11:23:27 +0000 Received: from woking.xci-test.com (10.80.248.135) by smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id 8.3.137.0; Tue, 13 Sep 2011 12:23:27 +0100 Received: from osstest by woking.xci-test.com with local (Exim 4.69) (envelope-from ) id 1R3R5L-0007Cr-99; Tue, 13 Sep 2011 12:23:27 +0100 To: xen-devel@lists.xensource.com Message-ID: From: xen.org Date: Tue, 13 Sep 2011 12:23:27 +0100 MIME-Version: 1.0 Content-Type: text/plain Cc: ian.jackson@eu.citrix.com Subject: [Xen-devel] [xen-4.0-testing test] 8874: tolerable FAIL - PUSHED X-BeenThere: xen-devel@lists.xensource.com X-Mailman-Version: 2.1.5 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xensource.com Errors-To: xen-devel-bounces@lists.xensource.com flight 8874 xen-4.0-testing real [real] http://www.chiark.greenend.org.uk/~xensrcts/logs/8874/ Failures :-/ but no regressions. Tests which did not succeed, but are not blocking, including regressions (tests previously passed) regarded as allowable: test-amd64-amd64-xl-pcipt-intel 1 xen-build-check(1) blocked n/a test-amd64-amd64-xl 1 xen-build-check(1) blocked n/a test-amd64-i386-pair 1 xen-build-check(1) blocked n/a test-i386-i386-pair 1 xen-build-check(1) blocked n/a test-amd64-i386-xl-multivcpu 1 xen-build-check(1) blocked n/a test-amd64-i386-pv 1 xen-build-check(1) blocked n/a test-i386-i386-pv 1 xen-build-check(1) blocked n/a test-i386-i386-xl 1 xen-build-check(1) blocked n/a test-amd64-amd64-pv 1 xen-build-check(1) blocked n/a build-i386-pvops 4 kernel-build fail like 8866 test-amd64-i386-xl 1 xen-build-check(1) blocked n/a test-amd64-i386-xl-credit2 1 xen-build-check(1) blocked n/a test-amd64-amd64-xl-sedf 1 xen-build-check(1) blocked n/a test-amd64-amd64-pair 1 xen-build-check(1) blocked n/a test-i386-i386-win 1 xen-build-check(1) blocked n/a test-amd64-i386-rhel6hvm-intel 1 xen-build-check(1) blocked n/a test-amd64-i386-rhel6hvm-amd 1 xen-build-check(1) blocked n/a test-amd64-i386-win-vcpus1 1 xen-build-check(1) blocked n/a test-amd64-amd64-win 1 xen-build-check(1) blocked n/a build-amd64-pvops 4 kernel-build fail like 8866 test-amd64-i386-win 1 xen-build-check(1) blocked n/a test-amd64-amd64-xl-win 1 xen-build-check(1) blocked n/a test-amd64-i386-xl-win-vcpus1 1 xen-build-check(1) blocked n/a test-i386-i386-xl-win 1 xen-build-check(1) blocked n/a version targeted for testing: xen 487d9e650584 baseline version: xen 789ff1a462b8 ------------------------------------------------------------ People who touched revisions under test: Allen M Kay Andrew Cooper Jan Beulich Tim Deegan Wei Wang2 ------------------------------------------------------------ jobs: build-amd64 pass build-i386 pass build-amd64-oldkern pass build-i386-oldkern pass build-amd64-pvops fail build-i386-pvops fail test-amd64-amd64-xl blocked test-amd64-i386-xl blocked test-i386-i386-xl blocked test-amd64-i386-rhel6hvm-amd blocked test-amd64-i386-xl-credit2 blocked test-amd64-amd64-xl-pcipt-intel blocked test-amd64-i386-rhel6hvm-intel blocked test-amd64-i386-xl-multivcpu blocked test-amd64-amd64-pair blocked test-amd64-i386-pair blocked test-i386-i386-pair blocked test-amd64-amd64-pv blocked test-amd64-i386-pv blocked test-i386-i386-pv blocked test-amd64-amd64-xl-sedf blocked test-amd64-i386-win-vcpus1 blocked test-amd64-i386-xl-win-vcpus1 blocked test-amd64-amd64-win blocked test-amd64-i386-win blocked test-i386-i386-win blocked test-amd64-amd64-xl-win blocked test-i386-i386-xl-win blocked ------------------------------------------------------------ sg-report-flight on woking.cam.xci-test.com logs: /home/xc_osstest/logs images: /home/xc_osstest/images Logs, config files, etc. are available at http://www.chiark.greenend.org.uk/~xensrcts/logs Test harness code can be found at http://xenbits.xensource.com/gitweb?p=osstest.git;a=summary Pushing revision : + branch=xen-4.0-testing + revision=487d9e650584 + . cri-lock-repos ++ . cri-common +++ umask 002 +++ getconfig Repos +++ perl -e ' use Osstest; readconfigonly(); print $c{Repos} or die $!; ' ++ repos=/export/home/osstest/repos ++ repos_lock=/export/home/osstest/repos/lock ++ '[' x '!=' x/export/home/osstest/repos/lock ']' ++ OSSTEST_REPOS_LOCK_LOCKED=/export/home/osstest/repos/lock ++ exec with-lock-ex -w /export/home/osstest/repos/lock ./ap-push xen-4.0-testing 487d9e650584 + branch=xen-4.0-testing + revision=487d9e650584 + . cri-lock-repos ++ . cri-common +++ umask 002 +++ getconfig Repos +++ perl -e ' use Osstest; readconfigonly(); print $c{Repos} or die $!; ' ++ repos=/export/home/osstest/repos ++ repos_lock=/export/home/osstest/repos/lock ++ '[' x/export/home/osstest/repos/lock '!=' x/export/home/osstest/repos/lock ']' + : xen@xenbits.xensource.com + : xen@xenbits.xensource.com:git/linux-pvops + : master + : tested/2.6.39.x + case "$branch" in + cd /export/home/osstest/repos/xen-4.0-testing.hg + hg push -r 487d9e650584 ssh://xen@xenbits.xensource.com/HG/xen-4.0-testing.hg pushing to ssh://xen@xenbits.xensource.com/HG/xen-4.0-testing.hg searching for changes remote: adding changesets remote: adding manifests remote: adding file changes remote: added 2 changesets with 3 changes to 3 files _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel From xen-devel-bounces@lists.xensource.com Tue Sep 13 04:26:21 2011 Return-path: Envelope-to: www-data@lists.xensource.com Delivery-date: Tue, 13 Sep 2011 04:26:21 -0700 Received: from localhost ([127.0.0.1] helo=lists.colo.xensource.com) by lists.xensource.com with esmtp (Exim 4.43) id 1R3R89-0005qA-Gv; Tue, 13 Sep 2011 04:26:21 -0700 Received: from mail174.messagelabs.com ([85.158.138.51]) by lists.xensource.com with esmtp (Exim 4.43) id 1R3R7b-0005d9-RN for xen-devel@lists.xensource.com; Tue, 13 Sep 2011 04:25:48 -0700 X-Env-Sender: Ian.Jackson@eu.citrix.com X-Msg-Ref: server-9.tower-174.messagelabs.com!1315913141!25207642!1 X-Originating-IP: [62.200.22.115] X-StarScan-Version: 6.3.6; banners=-,-,- X-VirusChecked: Checked Received: (qmail 4402 invoked from network); 13 Sep 2011 11:25:44 -0000 Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115) by server-9.tower-174.messagelabs.com with RC4-SHA encrypted SMTP; 13 Sep 2011 11:25:44 -0000 X-IronPort-AV: E=Sophos;i="4.68,374,1312156800"; d="scan'208";a="7758717" Received: from lonpmailmx01.citrite.net ([10.30.203.162]) by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5; 13 Sep 2011 11:25:41 +0000 Received: from woking.xci-test.com (10.80.248.135) by smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id 8.3.137.0; Tue, 13 Sep 2011 12:25:40 +0100 Received: from osstest by woking.xci-test.com with local (Exim 4.69) (envelope-from ) id 1R3R7U-0007C6-K5; Tue, 13 Sep 2011 12:25:40 +0100 To: Message-ID: From: xen.org Date: Tue, 13 Sep 2011 12:25:40 +0100 MIME-Version: 1.0 Content-Type: text/plain Cc: ian.jackson@eu.citrix.com Subject: [Xen-devel] [xen-4.1-testing test] 8875: tolerable FAIL - PUSHED X-BeenThere: xen-devel@lists.xensource.com X-Mailman-Version: 2.1.5 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xensource.com Errors-To: xen-devel-bounces@lists.xensource.com flight 8875 xen-4.1-testing real [real] http://www.chiark.greenend.org.uk/~xensrcts/logs/8875/ Failures :-/ but no regressions. Tests which did not succeed, but are not blocking, including regressions (tests previously passed) regarded as allowable: test-amd64-amd64-xl-pcipt-intel 1 xen-build-check(1) blocked n/a test-amd64-amd64-pv 1 xen-build-check(1) blocked n/a build-i386-pvops 4 kernel-build fail like 8868 test-amd64-i386-rhel6hvm-intel 1 xen-build-check(1) blocked n/a test-i386-i386-pv 1 xen-build-check(1) blocked n/a test-amd64-i386-pv 1 xen-build-check(1) blocked n/a test-i386-i386-xl 1 xen-build-check(1) blocked n/a test-amd64-i386-xl-credit2 1 xen-build-check(1) blocked n/a test-amd64-amd64-xl 1 xen-build-check(1) blocked n/a test-amd64-i386-xl 1 xen-build-check(1) blocked n/a test-amd64-i386-xl-multivcpu 1 xen-build-check(1) blocked n/a test-amd64-i386-rhel6hvm-amd 1 xen-build-check(1) blocked n/a build-amd64-pvops 4 kernel-build fail like 8868 test-amd64-amd64-pair 1 xen-build-check(1) blocked n/a test-amd64-i386-pair 1 xen-build-check(1) blocked n/a test-i386-i386-pair 1 xen-build-check(1) blocked n/a test-amd64-amd64-xl-sedf 1 xen-build-check(1) blocked n/a test-amd64-i386-win-vcpus1 1 xen-build-check(1) blocked n/a test-amd64-i386-xl-win-vcpus1 1 xen-build-check(1) blocked n/a test-amd64-amd64-win 1 xen-build-check(1) blocked n/a test-amd64-i386-win 1 xen-build-check(1) blocked n/a test-amd64-amd64-xl-win 1 xen-build-check(1) blocked n/a test-i386-i386-win 1 xen-build-check(1) blocked n/a test-i386-i386-xl-win 1 xen-build-check(1) blocked n/a version targeted for testing: xen 829c4fd73b10 baseline version: xen 78d8c5227bb1 ------------------------------------------------------------ People who touched revisions under test: Andrew Cooper Benjamin Schweikert Stefano Stabellini ------------------------------------------------------------ jobs: build-amd64 pass build-i386 pass build-amd64-oldkern pass build-i386-oldkern pass build-amd64-pvops fail build-i386-pvops fail test-amd64-amd64-xl blocked test-amd64-i386-xl blocked test-i386-i386-xl blocked test-amd64-i386-rhel6hvm-amd blocked test-amd64-i386-xl-credit2 blocked test-amd64-amd64-xl-pcipt-intel blocked test-amd64-i386-rhel6hvm-intel blocked test-amd64-i386-xl-multivcpu blocked test-amd64-amd64-pair blocked test-amd64-i386-pair blocked test-i386-i386-pair blocked test-amd64-amd64-pv blocked test-amd64-i386-pv blocked test-i386-i386-pv blocked test-amd64-amd64-xl-sedf blocked test-amd64-i386-win-vcpus1 blocked test-amd64-i386-xl-win-vcpus1 blocked test-amd64-amd64-win blocked test-amd64-i386-win blocked test-i386-i386-win blocked test-amd64-amd64-xl-win blocked test-i386-i386-xl-win blocked ------------------------------------------------------------ sg-report-flight on woking.cam.xci-test.com logs: /home/xc_osstest/logs images: /home/xc_osstest/images Logs, config files, etc. are available at http://www.chiark.greenend.org.uk/~xensrcts/logs Test harness code can be found at http://xenbits.xensource.com/gitweb?p=osstest.git;a=summary Pushing revision : + branch=xen-4.1-testing + revision=829c4fd73b10 + . cri-lock-repos ++ . cri-common +++ umask 002 +++ getconfig Repos +++ perl -e ' use Osstest; readconfigonly(); print $c{Repos} or die $!; ' ++ repos=/export/home/osstest/repos ++ repos_lock=/export/home/osstest/repos/lock ++ '[' x '!=' x/export/home/osstest/repos/lock ']' ++ OSSTEST_REPOS_LOCK_LOCKED=/export/home/osstest/repos/lock ++ exec with-lock-ex -w /export/home/osstest/repos/lock ./ap-push xen-4.1-testing 829c4fd73b10 + branch=xen-4.1-testing + revision=829c4fd73b10 + . cri-lock-repos ++ . cri-common +++ umask 002 +++ getconfig Repos +++ perl -e ' use Osstest; readconfigonly(); print $c{Repos} or die $!; ' ++ repos=/export/home/osstest/repos ++ repos_lock=/export/home/osstest/repos/lock ++ '[' x/export/home/osstest/repos/lock '!=' x/export/home/osstest/repos/lock ']' + : xen@xenbits.xensource.com + : xen@xenbits.xensource.com:git/linux-pvops + : master + : tested/2.6.39.x + case "$branch" in + cd /export/home/osstest/repos/xen-4.1-testing.hg + hg push -r 829c4fd73b10 ssh://xen@xenbits.xensource.com/HG/xen-4.1-testing.hg pushing to ssh://xen@xenbits.xensource.com/HG/xen-4.1-testing.hg searching for changes remote: adding changesets remote: adding manifests remote: adding file changes remote: added 2 changesets with 3 changes to 3 files _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel From xen-devel-bounces@lists.xensource.com Tue Sep 13 04:46:18 2011 Return-path: Envelope-to: www-data@lists.xensource.com Delivery-date: Tue, 13 Sep 2011 04:46:18 -0700 Received: from localhost ([127.0.0.1] helo=lists.colo.xensource.com) by lists.xensource.com with esmtp (Exim 4.43) id 1R3RRS-0006o9-0y; Tue, 13 Sep 2011 04:46:18 -0700 Received: from mail174.messagelabs.com ([85.158.138.51]) by lists.xensource.com with esmtp (Exim 4.43) id 1R3RQx-0006Zs-7a for xen-devel@lists.xensource.com; Tue, 13 Sep 2011 04:45:47 -0700 X-Env-Sender: JBeulich@suse.com X-Msg-Ref: server-8.tower-174.messagelabs.com!1315914340!17565941!1 X-Originating-IP: [130.57.49.28] X-StarScan-Version: 6.3.6; banners=-,-,- X-VirusChecked: Checked Received: (qmail 19274 invoked from network); 13 Sep 2011 11:45:42 -0000 Received: from nat28.tlf.novell.com (HELO nat28.tlf.novell.com) (130.57.49.28) by server-8.tower-174.messagelabs.com with DHE-RSA-AES256-SHA encrypted SMTP; 13 Sep 2011 11:45:42 -0000 Received: from EMEA1-MTA by nat28.tlf.novell.com with Novell_GroupWise; Tue, 13 Sep 2011 12:46:06 +0100 Message-Id: <4E6F5E830200007800055D49@nat28.tlf.novell.com> X-Mailer: Novell GroupWise Internet Agent 8.0.1 Date: Tue, 13 Sep 2011 12:45:39 +0100 From: "Jan Beulich" To: "Igor Mammedov" Subject: Re: [Xen-devel] xen: Clear IRQ_GUEST bit from irq_desc status if its action is NULL References: <1315904920-12533-1-git-send-email-imammedo@redhat.com> In-Reply-To: <1315904920-12533-1-git-send-email-imammedo@redhat.com> Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: quoted-printable Content-Disposition: inline Cc: xen-devel@lists.xensource.com X-BeenThere: xen-devel@lists.xensource.com X-Mailman-Version: 2.1.5 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xensource.com Errors-To: xen-devel-bounces@lists.xensource.com >>> On 13.09.11 at 11:08, Igor Mammedov wrote: > On a system with Intel C600 series Patsburg SAS controller > if following command are executed: >=20 > rmmod isci > modprobe isci >=20 > the host will crash in pirq_guest_bind in attempt to dereference > NULL action pointer. >=20 > This is caused by isci driver which does not cleanup irq properly, > removing device first and then os tries to unbind its irqs afterwards. >=20 > c/s 20093 and 20844 fixed host crashes when removing isci module. >=20 > However in dynamic_irq_cleanup 'action' field of irq_desc is set to > NULL but IRQ_GUEST flag in 'status' field is not cleared. So on next So why don't you clear the bit there? > attempt to bind pirq (modprobe isci) with IRQ_GUEST flag set, branch > if ( !(desc->status & IRQ_GUEST) ) > is skipped and host ends up with dereferencing NULL pointer 'action'. > > Second hunk is a bit of code cleanup, removing duplicate code and keeps > IRQ_GUEST flag reset at one place. This is not just cleanup - till now, when action =3D=3D NULL, the function would return 0, while with your patch it would return 1 (which is wrong afaict), so you'll minimally need to move down the unbind: label by one line. But the cleanup here would better be a separate patch anyway. Jan > Please review. >=20 > Signed-off-by: Igor Mammedov >=20 > diff -r 0312575dc35e xen/arch/x86/irq.c > --- a/xen/arch/x86/irq.c Thu Sep 08 15:13:06 2011 +0100 > +++ b/xen/arch/x86/irq.c Tue Sep 13 09:27:12 2011 +0200 > @@ -1472,6 +1472,7 @@ static irq_guest_action_t *__pirq_guest_ > =20 > if ( unlikely(action =3D=3D NULL) ) > { > + desc->status &=3D ~IRQ_GUEST; > dprintk(XENLOG_G_WARNING, "dom%d: pirq %d: desc->action is = NULL!\n", > d->domain_id, pirq->pirq); > return NULL; > @@ -1598,17 +1599,14 @@ static int pirq_guest_force_unbind(struc > =20 > action =3D (irq_guest_action_t *)desc->action; > if ( unlikely(action =3D=3D NULL) ) > - { > - dprintk(XENLOG_G_WARNING, "dom%d: pirq %d: desc->action is = NULL!\n", > - d->domain_id, pirq->pirq); > - goto out; > - } > + goto unbind; > =20 > for ( i =3D 0; (i < action->nr_guests) && (action->guest[i] !=3D = d); i++ ) > continue; > if ( i =3D=3D action->nr_guests ) > goto out; > =20 > + unbind: > bound =3D 1; > oldaction =3D __pirq_guest_unbind(d, pirq, desc); > =20 >=20 > _______________________________________________ > Xen-devel mailing list > Xen-devel@lists.xensource.com=20 > http://lists.xensource.com/xen-devel=20 _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel From xen-devel-bounces@lists.xensource.com Tue Sep 13 04:51:26 2011 Return-path: Envelope-to: www-data@lists.xensource.com Delivery-date: Tue, 13 Sep 2011 04:51:26 -0700 Received: from localhost ([127.0.0.1] helo=lists.colo.xensource.com) by lists.xensource.com with esmtp (Exim 4.43) id 1R3RWQ-0007GC-B5; Tue, 13 Sep 2011 04:51:26 -0700 Received: from mail174.messagelabs.com ([85.158.138.51]) by lists.xensource.com with esmtp (Exim 4.43) id 1R3RVx-00073o-SC for xen-devel@lists.xensource.com; Tue, 13 Sep 2011 04:50:58 -0700 X-Env-Sender: Ian.Jackson@eu.citrix.com X-Msg-Ref: server-8.tower-174.messagelabs.com!1315914643!17566811!1 X-Originating-IP: [62.200.22.115] X-StarScan-Version: 6.3.6; banners=-,-,- X-VirusChecked: Checked Received: (qmail 9054 invoked from network); 13 Sep 2011 11:50:54 -0000 Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115) by server-8.tower-174.messagelabs.com with RC4-SHA encrypted SMTP; 13 Sep 2011 11:50:54 -0000 X-IronPort-AV: E=Sophos;i="4.68,374,1312156800"; d="scan'208";a="7759715" Received: from lonpmailmx01.citrite.net ([10.30.203.162]) by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5; 13 Sep 2011 11:50:43 +0000 Received: from woking.xci-test.com (10.80.248.135) by smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id 8.3.137.0; Tue, 13 Sep 2011 12:50:43 +0100 Received: from osstest by woking.xci-test.com with local (Exim 4.69) (envelope-from ) id 1R3RVj-0007J7-4A; Tue, 13 Sep 2011 12:50:43 +0100 To: xen-devel@lists.xensource.com Message-ID: From: xen.org Date: Tue, 13 Sep 2011 12:50:43 +0100 MIME-Version: 1.0 Content-Type: text/plain Cc: ian.jackson@eu.citrix.com Subject: [Xen-devel] [xen-unstable test] 8876: regressions - trouble: blocked/fail X-BeenThere: xen-devel@lists.xensource.com X-Mailman-Version: 2.1.5 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xensource.com Errors-To: xen-devel-bounces@lists.xensource.com flight 8876 xen-unstable real [real] http://www.chiark.greenend.org.uk/~xensrcts/logs/8876/ Regressions :-( Tests which did not succeed and are blocking: build-amd64 4 xen-build fail REGR. vs. 8873 build-i386 4 xen-build fail REGR. vs. 8873 build-i386-oldkern 4 xen-build fail REGR. vs. 8873 build-amd64-oldkern 4 xen-build fail REGR. vs. 8873 Tests which did not succeed, but are not blocking, including regressions (tests previously passed) regarded as allowable: test-amd64-amd64-xl-pcipt-intel 1 xen-build-check(1) blocked n/a test-amd64-i386-rhel6hvm-intel 1 xen-build-check(1) blocked n/a test-i386-i386-pv 1 xen-build-check(1) blocked n/a test-amd64-i386-pv 1 xen-build-check(1) blocked n/a test-amd64-amd64-pv 1 xen-build-check(1) blocked n/a test-i386-i386-xl 1 xen-build-check(1) blocked n/a test-amd64-i386-xl 1 xen-build-check(1) blocked n/a test-amd64-i386-xl-credit2 1 xen-build-check(1) blocked n/a test-amd64-i386-rhel6hvm-amd 1 xen-build-check(1) blocked n/a test-amd64-amd64-pair 1 xen-build-check(1) blocked n/a test-amd64-i386-pair 1 xen-build-check(1) blocked n/a test-i386-i386-pair 1 xen-build-check(1) blocked n/a build-amd64-pvops 4 kernel-build fail like 8873 build-i386-pvops 4 kernel-build fail like 8873 test-amd64-i386-xl-multivcpu 1 xen-build-check(1) blocked n/a test-amd64-amd64-xl-sedf 1 xen-build-check(1) blocked n/a test-amd64-i386-win-vcpus1 1 xen-build-check(1) blocked n/a test-amd64-i386-xl-win-vcpus1 1 xen-build-check(1) blocked n/a test-amd64-amd64-win 1 xen-build-check(1) blocked n/a test-amd64-i386-win 1 xen-build-check(1) blocked n/a test-amd64-amd64-xl-win 1 xen-build-check(1) blocked n/a test-amd64-amd64-xl 1 xen-build-check(1) blocked n/a test-i386-i386-xl-win 1 xen-build-check(1) blocked n/a test-i386-i386-win 1 xen-build-check(1) blocked n/a version targeted for testing: xen 64aab9a077ea baseline version: xen 0312575dc35e ------------------------------------------------------------ People who touched revisions under test: Andrew Cooper Benjamin Schweikert Christoph Egger George Dunlap Ian Campbell Ian Jackson Keir Fraser Olaf Hering Stefano Stabellini Tim Deegan ------------------------------------------------------------ jobs: build-amd64 fail build-i386 fail build-amd64-oldkern fail build-i386-oldkern fail build-amd64-pvops fail build-i386-pvops fail test-amd64-amd64-xl blocked test-amd64-i386-xl blocked test-i386-i386-xl blocked test-amd64-i386-rhel6hvm-amd blocked test-amd64-i386-xl-credit2 blocked test-amd64-amd64-xl-pcipt-intel blocked test-amd64-i386-rhel6hvm-intel blocked test-amd64-i386-xl-multivcpu blocked test-amd64-amd64-pair blocked test-amd64-i386-pair blocked test-i386-i386-pair blocked test-amd64-amd64-pv blocked test-amd64-i386-pv blocked test-i386-i386-pv blocked test-amd64-amd64-xl-sedf blocked test-amd64-i386-win-vcpus1 blocked test-amd64-i386-xl-win-vcpus1 blocked test-amd64-amd64-win blocked test-amd64-i386-win blocked test-i386-i386-win blocked test-amd64-amd64-xl-win blocked test-i386-i386-xl-win blocked ------------------------------------------------------------ sg-report-flight on woking.cam.xci-test.com logs: /home/xc_osstest/logs images: /home/xc_osstest/images Logs, config files, etc. are available at http://www.chiark.greenend.org.uk/~xensrcts/logs Test harness code can be found at http://xenbits.xensource.com/gitweb?p=osstest.git;a=summary Not pushing. ------------------------------------------------------------ changeset: 23835:64aab9a077ea tag: tip user: Keir Fraser date: Tue Sep 13 11:20:57 2011 +0100 scripts/git-checkout.sh: Is not bash specific. Invoke with /bin/sh. Signed-off-by: Keir Fraser changeset: 23834:1d40b2793723 user: George Dunlap date: Tue Sep 13 10:43:43 2011 +0100 xen,credit1: Add variable timeslice Add a xen command-line parameter, sched_credit_tslice_ms, to set the timeslice of the credit1 scheduler. Signed-off-by: George Dunlap changeset: 23833:ffe8e65f6687 user: Andrew Cooper date: Tue Sep 13 10:33:10 2011 +0100 IRQ: IO-APIC support End Of Interrupt for older IO-APICs The old io_apic_eoi() function using the EOI register only works for IO-APICs with a version of 0x20. Older IO-APICs do not have an EOI register so line level interrupts have to be EOI'd by flipping the mode to edge and back, which clears the IRR and Delivery Status bits. This patch replaces the current io_apic_eoi() function with one which takes into account the version of the IO-APIC and EOI's appropriately. v2: make recursive call to __io_apic_eoi() to reduce code size. Signed-off-by: Andrew Cooper changeset: 23832:ad3b4bb097cb user: Stefano Stabellini date: Tue Sep 13 10:32:24 2011 +0100 xen: if mapping GSIs we run out of pirq < nr_irqs_gsi, use the others PV on HVM guests can have more GSIs than the host, in that case we could run out of pirq < nr_irqs_gsi. When that happens use pirq >= nr_irqs_gsi rather than returning an error. Signed-off-by: Stefano Stabellini Tested-by: Benjamin Schweikert changeset: 23831:53416e7c0529 user: Stefano Stabellini date: Tue Sep 13 10:30:09 2011 +0100 Clone and build Seabios by default Signed-off-by: Stefano Stabellini changeset: 23830:1b80eaeeba7b user: Stefano Stabellini date: Tue Sep 13 10:29:14 2011 +0100 Clone and build upstream Qemu by default Signed-off-by: Stefano Stabellini changeset: 23829:9a541243aeaf user: Stefano Stabellini date: Tue Sep 13 10:27:53 2011 +0100 Rename ioemu-dir as qemu-xen-traditional-dir Signed-off-by: Stefano Stabellini changeset: 23828:0d21b68f528b user: Stefano Stabellini date: Tue Sep 13 10:27:20 2011 +0100 Move the ioemu-dir-find shell script to an external file Add support for configuring upstream qemu and rename ioemu-remote ioemu-dir-remote. Signed-off-by: Stefano Stabellini changeset: 23827:d1d6abc1db20 user: Olaf Hering date: Tue Sep 13 10:25:32 2011 +0100 xenpaging: use batch of pages during final page-in Map up to RING_SIZE pages in exit path to fill the ring instead of populating one page at a time. Signed-off-by: Olaf Hering changeset: 23826:ad958e87db79 user: Ian Campbell date: Tue Sep 13 10:22:03 2011 +0100 hvmloader: don't clear acpi_info after filling in some fields In particular the madt_lapic0_addr and madt_csum_addr fields are filled in while building the tables. This fixes a bluescreen on shutdown with certain versions of Windows. Signed-off-by: Ian Campbell Reported-by: Christoph Egger Tested-and-acked-by: Christoph Egger changeset: 23825:0312575dc35e user: Tim Deegan date: Thu Sep 08 15:13:06 2011 +0100 x86/mm: use new page-order interfaces in nested HAP code to make 2M and 1G mappings in the nested p2m tables. Signed-off-by: Christoph Egger Signed-off-by: Tim Deegan Committed-by: Tim Deegan ======================================== commit cd776ee9408ff127f934a707c1a339ee600bc127 Author: Ian Jackson Date: Tue Jun 28 13:50:53 2011 +0100 qemu-char.c: fix incorrect CONFIG_STUBDOM handling qemu-char.c:1123:7: warning: "CONFIG_STUBDOM" is not defined [-Wundef] Signed-off-by: Olaf Hering Acked-by: Ian Jackson _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel From xen-devel-bounces@lists.xensource.com Tue Sep 13 05:33:10 2011 Return-path: Envelope-to: www-data@lists.xensource.com Delivery-date: Tue, 13 Sep 2011 05:33:10 -0700 Received: from localhost ([127.0.0.1] helo=lists.colo.xensource.com) by lists.xensource.com with esmtp (Exim 4.43) id 1R3SAo-0008OM-K0; Tue, 13 Sep 2011 05:33:10 -0700 Received: from mail182.messagelabs.com ([85.158.139.83]) by lists.xensource.com with smtp (Exim 4.43) id 1R3S9m-0008Bb-9Z for xen-devel@lists.xensource.com; Tue, 13 Sep 2011 05:32:10 -0700 X-Env-Sender: imammedo@redhat.com X-Msg-Ref: server-15.tower-182.messagelabs.com!1315917122!17146409!1 X-Originating-IP: [209.132.183.28] X-StarScan-Version: 6.3.6; banners=-,-,- X-VirusChecked: Checked Received: (qmail 7991 invoked from network); 13 Sep 2011 12:32:02 -0000 Received: from mx1.redhat.com (HELO mx1.redhat.com) (209.132.183.28) by server-15.tower-182.messagelabs.com with SMTP; 13 Sep 2011 12:32:02 -0000 Received: from int-mx10.intmail.prod.int.phx2.redhat.com (int-mx10.intmail.prod.int.phx2.redhat.com [10.5.11.23]) by mx1.redhat.com (8.14.4/8.14.4) with ESMTP id p8DCW1Tl021282 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK) for ; Tue, 13 Sep 2011 08:32:01 -0400 Received: from ns3.rdu.redhat.com (ns3.rdu.redhat.com [10.11.255.199]) by int-mx10.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP id p8DCW1XG025547 for ; Tue, 13 Sep 2011 08:32:01 -0400 Received: from nial.usersys.redhat.com (dhcp-1-247.brq.redhat.com [10.34.1.247]) by ns3.rdu.redhat.com (8.13.8/8.13.8) with ESMTP id p8DCW0Kd010359 for ; Tue, 13 Sep 2011 08:32:00 -0400 Message-ID: <4E6F4D3F.7060904@redhat.com> Date: Tue, 13 Sep 2011 14:31:59 +0200 From: Igor Mammedov User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.2.22) Gecko/20110904 Red Hat/3.1.14-1.el6_1 Lightning/1.0b2 Thunderbird/3.1.14 MIME-Version: 1.0 To: xen-devel@lists.xensource.com Subject: Re: [Xen-devel] xen: Clear IRQ_GUEST bit from irq_desc status if its action is NULL References: <1315904920-12533-1-git-send-email-imammedo@redhat.com> <4E6F5E830200007800055D49@nat28.tlf.novell.com> In-Reply-To: <4E6F5E830200007800055D49@nat28.tlf.novell.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Scanned-By: MIMEDefang 2.68 on 10.5.11.23 X-BeenThere: xen-devel@lists.xensource.com X-Mailman-Version: 2.1.5 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xensource.com Errors-To: xen-devel-bounces@lists.xensource.com On 09/13/2011 01:45 PM, Jan Beulich wrote: >>>> On 13.09.11 at 11:08, Igor Mammedov wrote: >> On a system with Intel C600 series Patsburg SAS controller >> if following command are executed: >> >> rmmod isci >> modprobe isci >> >> the host will crash in pirq_guest_bind in attempt to dereference >> NULL action pointer. >> >> This is caused by isci driver which does not cleanup irq properly, >> removing device first and then os tries to unbind its irqs afterwards. >> >> c/s 20093 and 20844 fixed host crashes when removing isci module. >> >> However in dynamic_irq_cleanup 'action' field of irq_desc is set to >> NULL but IRQ_GUEST flag in 'status' field is not cleared. So on next > > So why don't you clear the bit there? > >> attempt to bind pirq (modprobe isci) with IRQ_GUEST flag set, branch >> if ( !(desc->status& IRQ_GUEST) ) >> is skipped and host ends up with dereferencing NULL pointer 'action'. >> >> Second hunk is a bit of code cleanup, removing duplicate code and keeps >> IRQ_GUEST flag reset at one place. > > This is not just cleanup - till now, when action == NULL, the function > would return 0, while with your patch it would return 1 (which is wrong > afaict), so you'll minimally need to move down the unbind: label by one > line. But the cleanup here would better be a separate patch anyway. > > Jan Thanks for review. I'll fix it and re-post it as 2 patches. > >> Please review. >> >> Signed-off-by: Igor Mammedov >> >> diff -r 0312575dc35e xen/arch/x86/irq.c >> --- a/xen/arch/x86/irq.c Thu Sep 08 15:13:06 2011 +0100 >> +++ b/xen/arch/x86/irq.c Tue Sep 13 09:27:12 2011 +0200 >> @@ -1472,6 +1472,7 @@ static irq_guest_action_t *__pirq_guest_ >> >> if ( unlikely(action == NULL) ) >> { >> + desc->status&= ~IRQ_GUEST; >> dprintk(XENLOG_G_WARNING, "dom%d: pirq %d: desc->action is NULL!\n", >> d->domain_id, pirq->pirq); >> return NULL; >> @@ -1598,17 +1599,14 @@ static int pirq_guest_force_unbind(struc >> >> action = (irq_guest_action_t *)desc->action; >> if ( unlikely(action == NULL) ) >> - { >> - dprintk(XENLOG_G_WARNING, "dom%d: pirq %d: desc->action is NULL!\n", >> - d->domain_id, pirq->pirq); >> - goto out; >> - } >> + goto unbind; >> >> for ( i = 0; (i< action->nr_guests)&& (action->guest[i] != d); i++ ) >> continue; >> if ( i == action->nr_guests ) >> goto out; >> >> + unbind: >> bound = 1; >> oldaction = __pirq_guest_unbind(d, pirq, desc); >> >> >> _______________________________________________ >> Xen-devel mailing list >> Xen-devel@lists.xensource.com >> http://lists.xensource.com/xen-devel > > > > > _______________________________________________ > Xen-devel mailing list > Xen-devel@lists.xensource.com > http://lists.xensource.com/xen-devel -- Thanks, Igor _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel From xen-devel-bounces@lists.xensource.com Tue Sep 13 05:37:16 2011 Return-path: Envelope-to: www-data@lists.xensource.com Delivery-date: Tue, 13 Sep 2011 05:37:16 -0700 Received: from localhost ([127.0.0.1] helo=lists.colo.xensource.com) by lists.xensource.com with esmtp (Exim 4.43) id 1R3SEm-0000Nz-95; Tue, 13 Sep 2011 05:37:16 -0700 Received: from mail216.messagelabs.com ([85.158.143.99]) by lists.xensource.com with smtp (Exim 4.43) id 1R3SED-0000Aw-N4 for xen-devel@lists.xensource.com; Tue, 13 Sep 2011 05:36:42 -0700 X-Env-Sender: imammedo@redhat.com X-Msg-Ref: server-4.tower-216.messagelabs.com!1315917397!18079054!1 X-Originating-IP: [209.132.183.28] X-StarScan-Version: 6.3.6; banners=-,-,- X-VirusChecked: Checked Received: (qmail 11323 invoked from network); 13 Sep 2011 12:36:38 -0000 Received: from mx1.redhat.com (HELO mx1.redhat.com) (209.132.183.28) by server-4.tower-216.messagelabs.com with SMTP; 13 Sep 2011 12:36:38 -0000 Received: from int-mx12.intmail.prod.int.phx2.redhat.com (int-mx12.intmail.prod.int.phx2.redhat.com [10.5.11.25]) by mx1.redhat.com (8.14.4/8.14.4) with ESMTP id p8DCabvM002431 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK) for ; Tue, 13 Sep 2011 08:36:37 -0400 Received: from ns3.rdu.redhat.com (ns3.rdu.redhat.com [10.11.255.199]) by int-mx12.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP id p8DCaa6u001026 for ; Tue, 13 Sep 2011 08:36:37 -0400 Received: from nial.usersys.redhat.com (dhcp-1-247.brq.redhat.com [10.34.1.247]) by ns3.rdu.redhat.com (8.13.8/8.13.8) with ESMTP id p8DCaZeq011144 for ; Tue, 13 Sep 2011 08:36:36 -0400 Message-ID: <4E6F4E53.3010100@redhat.com> Date: Tue, 13 Sep 2011 14:36:35 +0200 From: Igor Mammedov User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.2.22) Gecko/20110904 Red Hat/3.1.14-1.el6_1 Lightning/1.0b2 Thunderbird/3.1.14 MIME-Version: 1.0 To: xen-devel@lists.xensource.com Subject: Re: [Xen-devel] xen: Clear IRQ_GUEST bit from irq_desc status if its action is NULL References: <1315904920-12533-1-git-send-email-imammedo@redhat.com> <4E6F5E830200007800055D49@nat28.tlf.novell.com> In-Reply-To: <4E6F5E830200007800055D49@nat28.tlf.novell.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Scanned-By: MIMEDefang 2.68 on 10.5.11.25 X-BeenThere: xen-devel@lists.xensource.com X-Mailman-Version: 2.1.5 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xensource.com Errors-To: xen-devel-bounces@lists.xensource.com On 09/13/2011 01:45 PM, Jan Beulich wrote: >>>> On 13.09.11 at 11:08, Igor Mammedov wrote: >> On a system with Intel C600 series Patsburg SAS controller >> if following command are executed: >> >> rmmod isci >> modprobe isci >> >> the host will crash in pirq_guest_bind in attempt to dereference >> NULL action pointer. >> >> This is caused by isci driver which does not cleanup irq properly, >> removing device first and then os tries to unbind its irqs afterwards. >> >> c/s 20093 and 20844 fixed host crashes when removing isci module. >> >> However in dynamic_irq_cleanup 'action' field of irq_desc is set to >> NULL but IRQ_GUEST flag in 'status' field is not cleared. So on next > > So why don't you clear the bit there? then we may hit BUG_ON(!(desc->status & IRQ_GUEST)); in pirq_guest_unbind -> __pirq_guest_unbind It seams safer for me to clear bit in __pirq_guest_unbind _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel From xen-devel-bounces@lists.xensource.com Tue Sep 13 06:12:19 2011 Return-path: Envelope-to: www-data@lists.xensource.com Delivery-date: Tue, 13 Sep 2011 06:12:19 -0700 Received: from localhost ([127.0.0.1] helo=lists.colo.xensource.com) by lists.xensource.com with esmtp (Exim 4.43) id 1R3Smh-0001RA-2y; Tue, 13 Sep 2011 06:12:19 -0700 Received: from mail21.messagelabs.com ([85.158.143.35]) by lists.xensource.com with esmtp (Exim 4.43) id 1R3SlS-0001Dl-5G for xen-devel@lists.xensource.com; Tue, 13 Sep 2011 06:11:03 -0700 X-Env-Sender: JBeulich@suse.com X-Msg-Ref: server-2.tower-21.messagelabs.com!1315919458!33924500!1 X-Originating-IP: [130.57.49.28] X-StarScan-Version: 6.4.1; banners=-,-,- X-VirusChecked: Checked Received: (qmail 10428 invoked from network); 13 Sep 2011 13:10:58 -0000 Received: from nat28.tlf.novell.com (HELO nat28.tlf.novell.com) (130.57.49.28) by server-2.tower-21.messagelabs.com with DHE-RSA-AES256-SHA encrypted SMTP; 13 Sep 2011 13:10:58 -0000 Received: from EMEA1-MTA by nat28.tlf.novell.com with Novell_GroupWise; Tue, 13 Sep 2011 14:10:58 +0100 Message-Id: <4E6F72810200007800055D60@nat28.tlf.novell.com> X-Mailer: Novell GroupWise Internet Agent 8.0.1 Date: Tue, 13 Sep 2011 14:10:57 +0100 From: "Jan Beulich" To: "Igor Mammedov" Subject: Re: [Xen-devel] xen: Clear IRQ_GUEST bit from irq_desc status if its action is NULL References: <1315904920-12533-1-git-send-email-imammedo@redhat.com> <4E6F5E830200007800055D49@nat28.tlf.novell.com> <4E6F4E53.3010100@redhat.com> In-Reply-To: <4E6F4E53.3010100@redhat.com> Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: quoted-printable Content-Disposition: inline Cc: xen-devel@lists.xensource.com X-BeenThere: xen-devel@lists.xensource.com X-Mailman-Version: 2.1.5 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xensource.com Errors-To: xen-devel-bounces@lists.xensource.com >>> On 13.09.11 at 14:36, Igor Mammedov wrote: > On 09/13/2011 01:45 PM, Jan Beulich wrote: >>>>> On 13.09.11 at 11:08, Igor Mammedov wrote: >>> On a system with Intel C600 series Patsburg SAS controller >>> if following command are executed: >>> >>> rmmod isci >>> modprobe isci >>> >>> the host will crash in pirq_guest_bind in attempt to dereference >>> NULL action pointer. >>> >>> This is caused by isci driver which does not cleanup irq properly, >>> removing device first and then os tries to unbind its irqs afterwards. >>> >>> c/s 20093 and 20844 fixed host crashes when removing isci module. >>> >>> However in dynamic_irq_cleanup 'action' field of irq_desc is set to >>> NULL but IRQ_GUEST flag in 'status' field is not cleared. So on next >> >> So why don't you clear the bit there? >=20 > then we may hit >=20 > BUG_ON(!(desc->status & IRQ_GUEST)); >=20 > in pirq_guest_unbind -> __pirq_guest_unbind >=20 > It seams safer for me to clear bit in __pirq_guest_unbind Makes sense - could you say so in the description when re-submitting? Jan _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel From xen-devel-bounces@lists.xensource.com Tue Sep 13 06:16:24 2011 Return-path: Envelope-to: www-data@lists.xensource.com Delivery-date: Tue, 13 Sep 2011 06:16:24 -0700 Received: from localhost ([127.0.0.1] helo=lists.colo.xensource.com) by lists.xensource.com with esmtp (Exim 4.43) id 1R3Sqe-0001qi-NW; Tue, 13 Sep 2011 06:16:24 -0700 Received: from mail182.messagelabs.com ([85.158.139.83]) by lists.xensource.com with esmtp (Exim 4.43) id 1R3Spr-0001du-Th for xen-devel@lists.xensource.com; Tue, 13 Sep 2011 06:15:37 -0700 X-Env-Sender: konrad@oracle.com X-Msg-Ref: server-11.tower-182.messagelabs.com!1315919731!18159154!1 X-Originating-IP: [141.146.126.227] X-StarScan-Version: 6.3.6; banners=-,-,- X-VirusChecked: Checked Received: (qmail 22719 invoked from network); 13 Sep 2011 13:15:32 -0000 Received: from acsinet15.oracle.com (HELO acsinet15.oracle.com) (141.146.126.227) by server-11.tower-182.messagelabs.com with DHE-RSA-AES256-SHA encrypted SMTP; 13 Sep 2011 13:15:32 -0000 Received: from rtcsinet22.oracle.com (rtcsinet22.oracle.com [66.248.204.30]) by acsinet15.oracle.com (Switch-3.4.4/Switch-3.4.4) with ESMTP id p8DDFQJS006787 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Tue, 13 Sep 2011 13:15:28 GMT Received: from acsmt358.oracle.com (acsmt358.oracle.com [141.146.40.158]) by rtcsinet22.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id p8DDFPkd009736 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 13 Sep 2011 13:15:26 GMT Received: from abhmt120.oracle.com (abhmt120.oracle.com [141.146.116.72]) by acsmt358.oracle.com (8.12.11.20060308/8.12.11) with ESMTP id p8DDFJhi032620; Tue, 13 Sep 2011 08:15:19 -0500 Received: from oracle.com (/209.6.55.207) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Tue, 13 Sep 2011 06:15:19 -0700 Received: by oracle.com (Postfix, from userid 1000) id 49AC51211; Tue, 13 Sep 2011 09:15:17 -0400 (EDT) Date: Tue, 13 Sep 2011 09:15:17 -0400 From: Konrad Rzeszutek Wilk To: Li Dongyang Message-ID: <20110913131517.GB25632@phenom.oracle.com> References: <20110901152534.GA6965@dumpdata.com> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.21 (2010-09-15) Content-Transfer-Encoding: quoted-printable X-Source-IP: rtcsinet22.oracle.com [66.248.204.30] X-CT-RefId: str=0001.0A090201.4E6F5771.00D8,ss=1,re=1.599,fgs=0 Cc: xen-devel@lists.xensource.com, owen.smith@citrix.com, JBeulich@novell.com Subject: [Xen-devel] Re: [PATCH V4 2/3] xen-blkfront: teach blkfront driver to handle discard requests X-BeenThere: xen-devel@lists.xensource.com X-Mailman-Version: 2.1.5 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xensource.com Errors-To: xen-devel-bounces@lists.xensource.com On Tue, Sep 13, 2011 at 04:33:27PM +0800, Li Dongyang wrote: > Hi, Konrad > On Thu, Sep 1, 2011 at 11:25 PM, Konrad Rzeszutek Wilk > wrote: > > On Thu, Sep 01, 2011 at 06:39:09PM +0800, Li Dongyang wrote: > >> The blkfront driver now will read discard related nodes from xenstor= e, > >> and set up the request queue, then we can forward the > >> discard requests to backend driver. > > > > > > A better description is as follow: > > > > xen-blkfront: Handle discard requests. > > > > =A0 =A0If the backend advertises 'feature-discard', then interrogate > > =A0 =A0the backend for alignment, granularity, and max discard block = size. > > =A0 =A0Setup the request queue with the appropiate values and send th= e > > =A0 =A0discard operation as required. > > > > > >> > >> Signed-off-by: Li Dongyang > >> --- > >> =A0drivers/block/xen-blkfront.c | =A0111 +++++++++++++++++++++++++++= ++++++--------- > >> =A01 files changed, 88 insertions(+), 23 deletions(-) > >> > >> diff --git a/drivers/block/xen-blkfront.c b/drivers/block/xen-blkfro= nt.c > >> index 9ea8c25..86e2c63 100644 > >> --- a/drivers/block/xen-blkfront.c > >> +++ b/drivers/block/xen-blkfront.c > >> @@ -98,6 +98,9 @@ struct blkfront_info > >> =A0 =A0 =A0 unsigned long shadow_free; > >> =A0 =A0 =A0 unsigned int feature_flush; > >> =A0 =A0 =A0 unsigned int flush_op; > >> + =A0 =A0 unsigned int feature_discard; > >> + =A0 =A0 unsigned int discard_granularity; > >> + =A0 =A0 unsigned int discard_alignment; > >> =A0 =A0 =A0 int is_ready; > >> =A0}; > >> > >> @@ -302,29 +305,36 @@ static int blkif_queue_request(struct request = *req) > >> =A0 =A0 =A0 =A0 =A0 =A0 =A0 ring_req->operation =3D info->flush_op; > >> =A0 =A0 =A0 } > >> > >> - =A0 =A0 ring_req->nr_segments =3D blk_rq_map_sg(req->q, req, info-= >sg); > >> - =A0 =A0 BUG_ON(ring_req->nr_segments > BLKIF_MAX_SEGMENTS_PER_REQU= EST); > >> + =A0 =A0 if (unlikely(req->cmd_flags & REQ_DISCARD)) { > >> + =A0 =A0 =A0 =A0 =A0 =A0 /* id, sector_number and handle are set ab= ove. */ > >> + =A0 =A0 =A0 =A0 =A0 =A0 ring_req->operation =3D BLKIF_OP_DISCARD; > >> + =A0 =A0 =A0 =A0 =A0 =A0 ring_req->nr_segments =3D 0; > >> + =A0 =A0 =A0 =A0 =A0 =A0 ring_req->u.discard.nr_sectors =3D blk_rq_= sectors(req); > >> + =A0 =A0 } else { > >> + =A0 =A0 =A0 =A0 =A0 =A0 ring_req->nr_segments =3D blk_rq_map_sg(re= q->q, req, info->sg); > >> + =A0 =A0 =A0 =A0 =A0 =A0 BUG_ON(ring_req->nr_segments > BLKIF_MAX_S= EGMENTS_PER_REQUEST); > >> > >> - =A0 =A0 for_each_sg(info->sg, sg, ring_req->nr_segments, i) { > >> - =A0 =A0 =A0 =A0 =A0 =A0 buffer_mfn =3D pfn_to_mfn(page_to_pfn(sg_p= age(sg))); > >> - =A0 =A0 =A0 =A0 =A0 =A0 fsect =3D sg->offset >> 9; > >> - =A0 =A0 =A0 =A0 =A0 =A0 lsect =3D fsect + (sg->length >> 9) - 1; > >> - =A0 =A0 =A0 =A0 =A0 =A0 /* install a grant reference. */ > >> - =A0 =A0 =A0 =A0 =A0 =A0 ref =3D gnttab_claim_grant_reference(&gref= _head); > >> - =A0 =A0 =A0 =A0 =A0 =A0 BUG_ON(ref =3D=3D -ENOSPC); > >> + =A0 =A0 =A0 =A0 =A0 =A0 for_each_sg(info->sg, sg, ring_req->nr_seg= ments, i) { > >> + =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 buffer_mfn =3D pfn_to_mfn(= page_to_pfn(sg_page(sg))); > >> + =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 fsect =3D sg->offset >> 9; > >> + =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 lsect =3D fsect + (sg->len= gth >> 9) - 1; > >> + =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 /* install a grant referen= ce. */ > >> + =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 ref =3D gnttab_claim_grant= _reference(&gref_head); > >> + =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 BUG_ON(ref =3D=3D -ENOSPC)= ; > >> > >> - =A0 =A0 =A0 =A0 =A0 =A0 gnttab_grant_foreign_access_ref( > >> - =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 ref, > >> - =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 info->xbde= v->otherend_id, > >> - =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 buffer_mfn= , > >> - =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 rq_data_di= r(req) ); > >> - > >> - =A0 =A0 =A0 =A0 =A0 =A0 info->shadow[id].frame[i] =3D mfn_to_pfn(b= uffer_mfn); > >> - =A0 =A0 =A0 =A0 =A0 =A0 ring_req->u.rw.seg[i] =3D > >> - =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 (struct bl= kif_request_segment) { > >> - =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0= =A0 .gref =A0 =A0 =A0 =3D ref, > >> - =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0= =A0 .first_sect =3D fsect, > >> - =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0= =A0 .last_sect =A0=3D lsect }; > >> + =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 gnttab_grant_foreign_acces= s_ref( > >> + =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0= =A0 ref, > >> + =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0= =A0 info->xbdev->otherend_id, > >> + =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0= =A0 buffer_mfn, > >> + =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0= =A0 rq_data_dir(req)); > >> + > >> + =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 info->shadow[id].frame[i] = =3D mfn_to_pfn(buffer_mfn); > >> + =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 ring_req->u.rw.seg[i] =3D > >> + =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0= =A0 (struct blkif_request_segment) { > >> + =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0= =A0 =A0 =A0 =A0 =A0 .gref =A0 =A0 =A0 =3D ref, > >> + =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0= =A0 =A0 =A0 =A0 =A0 .first_sect =3D fsect, > >> + =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0= =A0 =A0 =A0 =A0 =A0 .last_sect =A0=3D lsect }; > >> + =A0 =A0 =A0 =A0 =A0 =A0 } > >> =A0 =A0 =A0 } > >> > >> =A0 =A0 =A0 info->ring.req_prod_pvt++; > >> @@ -399,6 +409,7 @@ wait: > >> =A0static int xlvbd_init_blk_queue(struct gendisk *gd, u16 sector_si= ze) > >> =A0{ > >> =A0 =A0 =A0 struct request_queue *rq; > >> + =A0 =A0 struct blkfront_info *info =3D gd->private_data; > >> > >> =A0 =A0 =A0 rq =3D blk_init_queue(do_blkif_request, &blkif_io_lock); > >> =A0 =A0 =A0 if (rq =3D=3D NULL) > >> @@ -406,6 +417,13 @@ static int xlvbd_init_blk_queue(struct gendisk = *gd, u16 sector_size) > >> > >> =A0 =A0 =A0 queue_flag_set_unlocked(QUEUE_FLAG_VIRT, rq); > >> > >> + =A0 =A0 if (info->feature_discard) { > >> + =A0 =A0 =A0 =A0 =A0 =A0 queue_flag_set_unlocked(QUEUE_FLAG_DISCARD= , rq); > >> + =A0 =A0 =A0 =A0 =A0 =A0 blk_queue_max_discard_sectors(rq, get_capa= city(gd)); > > > > This is not correct. I took a look at the SCSI support for this > > ('sd_config_discard') and if you look there carefully you will see th= at > > the value can be 64KB for example. > > > > You need to provide a mechanism similar to 'discard-*' to fetch that = data > > from the backend. > > > >> + =A0 =A0 =A0 =A0 =A0 =A0 rq->limits.discard_granularity =3D info->d= iscard_granularity; > >> + =A0 =A0 =A0 =A0 =A0 =A0 rq->limits.discard_alignment =3D info->dis= card_alignment; > >> + =A0 =A0 } > >> + > >> =A0 =A0 =A0 /* Hard sector size and max sectors impersonate the equi= v. hardware. */ > >> =A0 =A0 =A0 blk_queue_logical_block_size(rq, sector_size); > >> =A0 =A0 =A0 blk_queue_max_hw_sectors(rq, 512); > >> @@ -722,6 +740,19 @@ static irqreturn_t blkif_interrupt(int irq, voi= d *dev_id) > >> > >> =A0 =A0 =A0 =A0 =A0 =A0 =A0 error =3D (bret->status =3D=3D BLKIF_RSP= _OKAY) ? 0 : -EIO; > >> =A0 =A0 =A0 =A0 =A0 =A0 =A0 switch (bret->operation) { > >> + =A0 =A0 =A0 =A0 =A0 =A0 case BLKIF_OP_DISCARD: > >> + =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 if (unlikely(bret->status = =3D=3D BLKIF_RSP_EOPNOTSUPP)) { > >> + =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 struct req= uest_queue *rq =3D info->rq; > >> + =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 printk(KER= N_WARNING "blkfront: %s: discard op failed\n", > >> + =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0= =A0 =A0 =A0info->gd->disk_name); > >> + =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 error =3D = -EOPNOTSUPP; > >> + =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 info->feat= ure_discard =3D 0; > >> + =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 spin_lock(= rq->queue_lock); > we should not take the spin_lock here, > as the rq->queue_lock is actually blkif_io_lock, we pass the > blkif_io_lock to blk_init_queue > when we init the queue, > and blkif_io_lock has already acquired above in blkif_interrupt(), so > we will deadlock here. >=20 > I'm so sorry if this has already in your tree, I've tested with > BLKIF_RSP_ERROR but forgot the EOPNOTSUPP case, > I feel like I'm a stupid ass. > could u get rid od the spin_lock and spin_unlock below? Thanks Just send me a patch with the change and I will apply it to the tree. Thanks for testing it even further! _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel From xen-devel-bounces@lists.xensource.com Tue Sep 13 06:46:58 2011 Return-path: Envelope-to: www-data@lists.xensource.com Delivery-date: Tue, 13 Sep 2011 06:46:58 -0700 Received: from localhost ([127.0.0.1] helo=lists.colo.xensource.com) by lists.xensource.com with esmtp (Exim 4.43) id 1R3TKD-0003Sc-RQ; Tue, 13 Sep 2011 06:46:57 -0700 Received: from mail182.messagelabs.com ([85.158.139.83]) by lists.xensource.com with smtp (Exim 4.43) id 1R3THq-0002jF-0P for xen-devel@lists.xensource.com; Tue, 13 Sep 2011 06:44:30 -0700 X-Env-Sender: imammedo@redhat.com X-Msg-Ref: server-14.tower-182.messagelabs.com!1315921465!18000980!1 X-Originating-IP: [209.132.183.28] X-StarScan-Version: 6.3.6; banners=-,-,- X-VirusChecked: Checked Received: (qmail 10122 invoked from network); 13 Sep 2011 13:44:26 -0000 Received: from mx1.redhat.com (HELO mx1.redhat.com) (209.132.183.28) by server-14.tower-182.messagelabs.com with SMTP; 13 Sep 2011 13:44:26 -0000 Received: from int-mx12.intmail.prod.int.phx2.redhat.com (int-mx12.intmail.prod.int.phx2.redhat.com [10.5.11.25]) by mx1.redhat.com (8.14.4/8.14.4) with ESMTP id p8DDiO3h002452 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Tue, 13 Sep 2011 09:44:24 -0400 Received: from nial.brq.redhat.com (dhcp-1-247.brq.redhat.com [10.34.1.247]) by int-mx12.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP id p8DDiMZg028134; Tue, 13 Sep 2011 09:44:23 -0400 From: Igor Mammedov To: xen-devel@lists.xensource.com Date: Tue, 13 Sep 2011 15:44:17 +0200 Message-Id: <1315921459-17059-1-git-send-email-imammedo@redhat.com> X-Scanned-By: MIMEDefang 2.68 on 10.5.11.25 Cc: keir.fraser@citrix.com, JBeulich@suse.com Subject: [Xen-devel] [PATCH 0/2] Prevent host crash after executing in dom0 'rmmod isci; modprobe isci' X-BeenThere: xen-devel@lists.xensource.com X-Mailman-Version: 2.1.5 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xensource.com Errors-To: xen-devel-bounces@lists.xensource.com [PATCH 1/2] xen: Clear IRQ_GUEST bit from irq_desc status if its action is NULL [PATCH 2/2] xen: remove duplicate code and keep IRQ_GUEST flag reset at one place Changes since first patch "xen: Clear IRQ_GUEST bit from irq_desc status if its action is NULL" - split patch in 2, fix (1) and cleanup (2) - move 'unbind' label after 'bound = 1;' _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel From xen-devel-bounces@lists.xensource.com Tue Sep 13 06:47:53 2011 Return-path: Envelope-to: www-data@lists.xensource.com Delivery-date: Tue, 13 Sep 2011 06:47:53 -0700 Received: from localhost ([127.0.0.1] helo=lists.colo.xensource.com) by lists.xensource.com with esmtp (Exim 4.43) id 1R3TL7-0003pU-3B; Tue, 13 Sep 2011 06:47:53 -0700 Received: from mail27.messagelabs.com ([193.109.254.147]) by lists.xensource.com with smtp (Exim 4.43) id 1R3THq-0002jS-Q0 for xen-devel@lists.xensource.com; Tue, 13 Sep 2011 06:44:31 -0700 X-Env-Sender: imammedo@redhat.com X-Msg-Ref: server-11.tower-27.messagelabs.com!1315921459!37231397!1 X-Originating-IP: [209.132.183.28] X-StarScan-Version: 6.3.6; banners=-,-,- X-VirusChecked: Checked Received: (qmail 23279 invoked from network); 13 Sep 2011 13:44:20 -0000 Received: from mx1.redhat.com (HELO mx1.redhat.com) (209.132.183.28) by server-11.tower-27.messagelabs.com with SMTP; 13 Sep 2011 13:44:20 -0000 Received: from int-mx12.intmail.prod.int.phx2.redhat.com (int-mx12.intmail.prod.int.phx2.redhat.com [10.5.11.25]) by mx1.redhat.com (8.14.4/8.14.4) with ESMTP id p8DDiPaY031695 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Tue, 13 Sep 2011 09:44:25 -0400 Received: from nial.brq.redhat.com (dhcp-1-247.brq.redhat.com [10.34.1.247]) by int-mx12.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP id p8DDiMZh028134; Tue, 13 Sep 2011 09:44:24 -0400 From: Igor Mammedov To: xen-devel@lists.xensource.com Date: Tue, 13 Sep 2011 15:44:18 +0200 Message-Id: <1315921459-17059-2-git-send-email-imammedo@redhat.com> In-Reply-To: <1315921459-17059-1-git-send-email-imammedo@redhat.com> References: <1315921459-17059-1-git-send-email-imammedo@redhat.com> X-Scanned-By: MIMEDefang 2.68 on 10.5.11.25 Cc: keir.fraser@citrix.com, JBeulich@suse.com Subject: [Xen-devel] [PATCH 1/2] xen: Clear IRQ_GUEST bit from irq_desc status if its action is NULL X-BeenThere: xen-devel@lists.xensource.com X-Mailman-Version: 2.1.5 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xensource.com Errors-To: xen-devel-bounces@lists.xensource.com On a system with Intel C600 series Patsburg SAS controller if following commands are executed: rmmod isci modprobe isci the host will crash in pirq_guest_bind in attempt to dereference NULL 'action' pointer. This is caused by isci driver which does not cleanup irq properly, removing device first and then os tries to unbind its irqs afterwards. c/s 20093 and 20844 fixed host crashes when removing isci module. However in dynamic_irq_cleanup 'action' field of irq_desc is set to NULL but IRQ_GUEST flag in 'status' field is not cleared. So on next attempt to bind pirq (modprobe isci) in pirq_guest_bind with IRQ_GUEST flag set, the branch if ( !(desc->status & IRQ_GUEST) ) is skipped and host ends up with dereferencing NULL pointer 'action'. __pirq_guest_unbind is the only place where IRQ_GUEST flag is cleared, lets keep it this way. Besides it is not safe to clear IRQ_GUEST flag in dynamic_irq_cleanup, because we can later hit BUG_ON(!(desc->status & IRQ_GUEST)); in pirq_guest_unbind -> __pirq_guest_unbind Signed-off-by: Igor Mammedov Reviewed-by: Jan Beulich diff -r 0312575dc35e -r 2049f7ca3177 xen/arch/x86/irq.c --- a/xen/arch/x86/irq.c Thu Sep 08 15:13:06 2011 +0100 +++ b/xen/arch/x86/irq.c Tue Sep 13 14:44:59 2011 +0200 @@ -1472,6 +1472,7 @@ static irq_guest_action_t *__pirq_guest_ if ( unlikely(action == NULL) ) { + desc->status &= ~IRQ_GUEST; dprintk(XENLOG_G_WARNING, "dom%d: pirq %d: desc->action is NULL!\n", d->domain_id, pirq->pirq); return NULL; @@ -1599,6 +1600,7 @@ static int pirq_guest_force_unbind(struc action = (irq_guest_action_t *)desc->action; if ( unlikely(action == NULL) ) { + desc->status &= ~IRQ_GUEST; dprintk(XENLOG_G_WARNING, "dom%d: pirq %d: desc->action is NULL!\n", d->domain_id, pirq->pirq); goto out; _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel From xen-devel-bounces@lists.xensource.com Tue Sep 13 06:48:37 2011 Return-path: Envelope-to: www-data@lists.xensource.com Delivery-date: Tue, 13 Sep 2011 06:48:37 -0700 Received: from localhost ([127.0.0.1] helo=lists.colo.xensource.com) by lists.xensource.com with esmtp (Exim 4.43) id 1R3TLp-0004CP-Pn; Tue, 13 Sep 2011 06:48:37 -0700 Received: from mail21.messagelabs.com ([85.158.143.35]) by lists.xensource.com with smtp (Exim 4.43) id 1R3THr-0002jo-Ui for xen-devel@lists.xensource.com; Tue, 13 Sep 2011 06:44:32 -0700 X-Env-Sender: imammedo@redhat.com X-Msg-Ref: server-10.tower-21.messagelabs.com!1315921453!53944946!1 X-Originating-IP: [209.132.183.28] X-StarScan-Version: 6.4.1; banners=-,-,- X-VirusChecked: Checked Received: (qmail 18857 invoked from network); 13 Sep 2011 13:44:14 -0000 Received: from mx1.redhat.com (HELO mx1.redhat.com) (209.132.183.28) by server-10.tower-21.messagelabs.com with SMTP; 13 Sep 2011 13:44:14 -0000 Received: from int-mx12.intmail.prod.int.phx2.redhat.com (int-mx12.intmail.prod.int.phx2.redhat.com [10.5.11.25]) by mx1.redhat.com (8.14.4/8.14.4) with ESMTP id p8DDiQDr002460 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Tue, 13 Sep 2011 09:44:27 -0400 Received: from nial.brq.redhat.com (dhcp-1-247.brq.redhat.com [10.34.1.247]) by int-mx12.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP id p8DDiMZi028134; Tue, 13 Sep 2011 09:44:26 -0400 From: Igor Mammedov To: xen-devel@lists.xensource.com Date: Tue, 13 Sep 2011 15:44:19 +0200 Message-Id: <1315921459-17059-3-git-send-email-imammedo@redhat.com> In-Reply-To: <1315921459-17059-1-git-send-email-imammedo@redhat.com> References: <1315921459-17059-1-git-send-email-imammedo@redhat.com> X-Scanned-By: MIMEDefang 2.68 on 10.5.11.25 Cc: keir.fraser@citrix.com, JBeulich@suse.com Subject: [Xen-devel] [PATCH 1/2] xen: Clear IRQ_GUEST bit from irq_desc status if its action is NULL X-BeenThere: xen-devel@lists.xensource.com X-Mailman-Version: 2.1.5 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xensource.com Errors-To: xen-devel-bounces@lists.xensource.com Signed-off-by: Igor Mammedov Reviewed-by: Jan Beulich diff -r 2049f7ca3177 -r 884814bfc22e xen/arch/x86/irq.c --- a/xen/arch/x86/irq.c Tue Sep 13 14:44:59 2011 +0200 +++ b/xen/arch/x86/irq.c Tue Sep 13 14:47:46 2011 +0200 @@ -1599,12 +1599,7 @@ static int pirq_guest_force_unbind(struc action = (irq_guest_action_t *)desc->action; if ( unlikely(action == NULL) ) - { - desc->status &= ~IRQ_GUEST; - dprintk(XENLOG_G_WARNING, "dom%d: pirq %d: desc->action is NULL!\n", - d->domain_id, pirq->pirq); - goto out; - } + goto unbind; for ( i = 0; (i < action->nr_guests) && (action->guest[i] != d); i++ ) continue; @@ -1612,6 +1607,7 @@ static int pirq_guest_force_unbind(struc goto out; bound = 1; + unbind: oldaction = __pirq_guest_unbind(d, pirq, desc); out: _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel From xen-devel-bounces@lists.xensource.com Tue Sep 13 06:54:39 2011 Return-path: Envelope-to: www-data@lists.xensource.com Delivery-date: Tue, 13 Sep 2011 06:54:39 -0700 Received: from localhost ([127.0.0.1] helo=lists.colo.xensource.com) by lists.xensource.com with esmtp (Exim 4.43) id 1R3TRf-0005Iq-Hs; Tue, 13 Sep 2011 06:54:39 -0700 Received: from mail27.messagelabs.com ([193.109.254.147]) by lists.xensource.com with esmtp (Exim 4.43) id 1R3TQt-0004to-02 for xen-devel@lists.xensource.com; Tue, 13 Sep 2011 06:53:51 -0700 X-Env-Sender: Ian.Jackson@eu.citrix.com X-Msg-Ref: server-9.tower-27.messagelabs.com!1315922012!44346202!1 X-Originating-IP: [62.200.22.115] X-StarScan-Version: 6.3.6; banners=-,-,- X-VirusChecked: Checked Received: (qmail 26785 invoked from network); 13 Sep 2011 13:53:32 -0000 Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115) by server-9.tower-27.messagelabs.com with RC4-SHA encrypted SMTP; 13 Sep 2011 13:53:32 -0000 X-IronPort-AV: E=Sophos;i="4.68,374,1312156800"; d="scan'208";a="7764972" Received: from lonpmailmx01.citrite.net ([10.30.203.162]) by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5; 13 Sep 2011 13:53:47 +0000 Received: from norwich.cam.xci-test.com (10.80.248.129) by smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id 8.3.137.0; Tue, 13 Sep 2011 14:53:47 +0100 Received: from mariner.cam.xci-test.com ([10.80.2.22] helo=mariner.uk.xensource.com ident=Debian-exim) by norwich.cam.xci-test.com with esmtp (Exim 4.72) (envelope-from ) id 1R3TQp-0003wQ-Ea for xen-devel@lists.xensource.com; Tue, 13 Sep 2011 13:53:47 +0000 Received: from iwj by mariner.uk.xensource.com with local (Exim 4.69) (envelope-from ) id 1R3TQp-0007Zq-Ds for xen-devel@lists.xensource.com; Tue, 13 Sep 2011 14:53:47 +0100 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Message-ID: <20079.24683.396507.666146@mariner.uk.xensource.com> Date: Tue, 13 Sep 2011 14:53:47 +0100 To: xen-devel@lists.xensource.com X-Mailer: VM 7.19 under Emacs 21.4.1 From: Ian Jackson Subject: [Xen-devel] [PATCH] tools: fix permissions of git-checkout.sh X-BeenThere: xen-devel@lists.xensource.com X-Mailman-Version: 2.1.5 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xensource.com Errors-To: xen-devel-bounces@lists.xensource.com I have just applied this. The permissions of scripts/git-checkout.sh aren't visible below; what I did was just chmod +x. Ian. # HG changeset patch # User Ian Jackson # Date 1315921942 -3600 # Node ID e564f2f1b737bc756410b34d886a15711caa288a # Parent 64aab9a077ea937b31fd678b02f755139b924184 tools: fix permissions of git-checkout.sh 23828:0d21b68f528b introduced a new scripts/git-checkout.sh, but it had the wrong permissions. chmod +x it, and add a blank line at the end to make sure it actually gets updated. Signed-off-by: Ian Jackson diff -r 64aab9a077ea -r e564f2f1b737 scripts/git-checkout.sh --- a/scripts/git-checkout.sh Tue Sep 13 11:20:57 2011 +0100 +++ b/scripts/git-checkout.sh Tue Sep 13 14:52:22 2011 +0100 @@ -44,3 +44,4 @@ elif test -f $ROOT/configure; then --disable-kvm \ $IOEMU_CONFIGURE_CROSS fi + _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel From xen-devel-bounces@lists.xensource.com Tue Sep 13 06:55:25 2011 Return-path: Envelope-to: www-data@lists.xensource.com Delivery-date: Tue, 13 Sep 2011 06:55:25 -0700 Received: from localhost ([127.0.0.1] helo=lists.colo.xensource.com) by lists.xensource.com with esmtp (Exim 4.43) id 1R3TSP-0005fh-5n; Tue, 13 Sep 2011 06:55:25 -0700 Received: from mail182.messagelabs.com ([85.158.139.83]) by lists.xensource.com with smtp (Exim 4.43) id 1R3TRF-00054S-1W for xen-devel@lists.xensource.com; Tue, 13 Sep 2011 06:54:13 -0700 X-Env-Sender: imammedo@redhat.com X-Msg-Ref: server-12.tower-182.messagelabs.com!1315922049!18009243!1 X-Originating-IP: [209.132.183.28] X-StarScan-Version: 6.3.6; banners=-,-,- X-VirusChecked: Checked Received: (qmail 3164 invoked from network); 13 Sep 2011 13:54:09 -0000 Received: from mx1.redhat.com (HELO mx1.redhat.com) (209.132.183.28) by server-12.tower-182.messagelabs.com with SMTP; 13 Sep 2011 13:54:09 -0000 Received: from int-mx02.intmail.prod.int.phx2.redhat.com (int-mx02.intmail.prod.int.phx2.redhat.com [10.5.11.12]) by mx1.redhat.com (8.14.4/8.14.4) with ESMTP id p8DDs7va027647 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Tue, 13 Sep 2011 09:54:07 -0400 Received: from nial.brq.redhat.com (dhcp-1-247.brq.redhat.com [10.34.1.247]) by int-mx02.intmail.prod.int.phx2.redhat.com (8.13.8/8.13.8) with ESMTP id p8DDs5r6026463; Tue, 13 Sep 2011 09:54:06 -0400 From: Igor Mammedov To: xen-devel@lists.xensource.com Date: Tue, 13 Sep 2011 15:54:02 +0200 Message-Id: <1315922042-17297-1-git-send-email-imammedo@redhat.com> In-Reply-To: <1315921459-17059-1-git-send-email-imammedo@redhat.com> References: <1315921459-17059-1-git-send-email-imammedo@redhat.com> X-Scanned-By: MIMEDefang 2.67 on 10.5.11.12 Cc: keir.fraser@citrix.com, JBeulich@suse.com Subject: [Xen-devel] [PATCH 2/2] xen: remove duplicate code and keep IRQ_GUEST flag reset at one place X-BeenThere: xen-devel@lists.xensource.com X-Mailman-Version: 2.1.5 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xensource.com Errors-To: xen-devel-bounces@lists.xensource.com Signed-off-by: Igor Mammedov Reviewed-by: Jan Beulich diff -r 2049f7ca3177 -r 884814bfc22e xen/arch/x86/irq.c --- a/xen/arch/x86/irq.c Tue Sep 13 14:44:59 2011 +0200 +++ b/xen/arch/x86/irq.c Tue Sep 13 14:47:46 2011 +0200 @@ -1599,12 +1599,7 @@ static int pirq_guest_force_unbind(struc action = (irq_guest_action_t *)desc->action; if ( unlikely(action == NULL) ) - { - desc->status &= ~IRQ_GUEST; - dprintk(XENLOG_G_WARNING, "dom%d: pirq %d: desc->action is NULL!\n", - d->domain_id, pirq->pirq); - goto out; - } + goto unbind; for ( i = 0; (i < action->nr_guests) && (action->guest[i] != d); i++ ) continue; @@ -1612,6 +1607,7 @@ static int pirq_guest_force_unbind(struc goto out; bound = 1; + unbind: oldaction = __pirq_guest_unbind(d, pirq, desc); out: _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel From xen-devel-bounces@lists.xensource.com Tue Sep 13 06:57:23 2011 Return-path: Envelope-to: www-data@lists.xensource.com Delivery-date: Tue, 13 Sep 2011 06:57:23 -0700 Received: from localhost ([127.0.0.1] helo=lists.colo.xensource.com) by lists.xensource.com with esmtp (Exim 4.43) id 1R3TUI-00065Z-Sw; Tue, 13 Sep 2011 06:57:22 -0700 Received: from mail21.messagelabs.com ([85.158.143.35]) by lists.xensource.com with smtp (Exim 4.43) id 1R3TTg-0005rF-V4 for xen-devel@lists.xensource.com; Tue, 13 Sep 2011 06:56:45 -0700 X-Env-Sender: imammedo@redhat.com X-Msg-Ref: server-9.tower-21.messagelabs.com!1315922157!48248010!1 X-Originating-IP: [209.132.183.28] X-StarScan-Version: 6.4.1; banners=-,-,- X-VirusChecked: Checked Received: (qmail 10291 invoked from network); 13 Sep 2011 13:55:58 -0000 Received: from mx1.redhat.com (HELO mx1.redhat.com) (209.132.183.28) by server-9.tower-21.messagelabs.com with SMTP; 13 Sep 2011 13:55:58 -0000 Received: from int-mx09.intmail.prod.int.phx2.redhat.com (int-mx09.intmail.prod.int.phx2.redhat.com [10.5.11.22]) by mx1.redhat.com (8.14.4/8.14.4) with ESMTP id p8DDuell004169 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Tue, 13 Sep 2011 09:56:40 -0400 Received: from ns3.rdu.redhat.com (ns3.rdu.redhat.com [10.11.255.199]) by int-mx09.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP id p8DDudYm009106; Tue, 13 Sep 2011 09:56:39 -0400 Received: from nial.usersys.redhat.com (dhcp-1-247.brq.redhat.com [10.34.1.247]) by ns3.rdu.redhat.com (8.13.8/8.13.8) with ESMTP id p8DDubRv024318; Tue, 13 Sep 2011 09:56:38 -0400 Message-ID: <4E6F6115.4060204@redhat.com> Date: Tue, 13 Sep 2011 15:56:37 +0200 From: Igor Mammedov User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.2.22) Gecko/20110904 Red Hat/3.1.14-1.el6_1 Lightning/1.0b2 Thunderbird/3.1.14 MIME-Version: 1.0 To: xen-devel@lists.xensource.com Subject: Re: [Xen-devel] [PATCH 1/2] xen: Clear IRQ_GUEST bit from irq_desc status if its action is NULL References: <1315921459-17059-1-git-send-email-imammedo@redhat.com> <1315921459-17059-3-git-send-email-imammedo@redhat.com> In-Reply-To: <1315921459-17059-3-git-send-email-imammedo@redhat.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Scanned-By: MIMEDefang 2.68 on 10.5.11.22 Cc: keir.fraser@citrix.com, JBeulich@suse.com X-BeenThere: xen-devel@lists.xensource.com X-Mailman-Version: 2.1.5 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xensource.com Errors-To: xen-devel-bounces@lists.xensource.com This one has wrong Subject. Just forget about it, please. I'll send it with correct subj. On 09/13/2011 03:44 PM, Igor Mammedov wrote: > Signed-off-by: Igor Mammedov > Reviewed-by: Jan Beulich > > diff -r 2049f7ca3177 -r 884814bfc22e xen/arch/x86/irq.c > --- a/xen/arch/x86/irq.c Tue Sep 13 14:44:59 2011 +0200 > +++ b/xen/arch/x86/irq.c Tue Sep 13 14:47:46 2011 +0200 > @@ -1599,12 +1599,7 @@ static int pirq_guest_force_unbind(struc > > action = (irq_guest_action_t *)desc->action; > if ( unlikely(action == NULL) ) > - { > - desc->status&= ~IRQ_GUEST; > - dprintk(XENLOG_G_WARNING, "dom%d: pirq %d: desc->action is NULL!\n", > - d->domain_id, pirq->pirq); > - goto out; > - } > + goto unbind; > > for ( i = 0; (i< action->nr_guests)&& (action->guest[i] != d); i++ ) > continue; > @@ -1612,6 +1607,7 @@ static int pirq_guest_force_unbind(struc > goto out; > > bound = 1; > + unbind: > oldaction = __pirq_guest_unbind(d, pirq, desc); > > out: > > _______________________________________________ > Xen-devel mailing list > Xen-devel@lists.xensource.com > http://lists.xensource.com/xen-devel -- Thanks, Igor _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel From xen-devel-bounces@lists.xensource.com Tue Sep 13 07:09:41 2011 Return-path: Envelope-to: www-data@lists.xensource.com Delivery-date: Tue, 13 Sep 2011 07:09:41 -0700 Received: from localhost ([127.0.0.1] helo=lists.colo.xensource.com) by lists.xensource.com with esmtp (Exim 4.43) id 1R3TgC-0007IH-Gq; Tue, 13 Sep 2011 07:09:40 -0700 Received: from mail182.messagelabs.com ([85.158.139.83]) by lists.xensource.com with esmtp (Exim 4.43) id 1R3TdZ-0006kp-Jg for xen-devel@lists.xensource.com; Tue, 13 Sep 2011 07:07:01 -0700 X-Env-Sender: Ian.Campbell@eu.citrix.com X-Msg-Ref: server-5.tower-182.messagelabs.com!1315922813!13181308!1 X-Originating-IP: [66.165.176.89] X-StarScan-Version: 6.3.6; banners=-,-,- X-VirusChecked: Checked Received: (qmail 23049 invoked from network); 13 Sep 2011 14:06:54 -0000 Received: from smtp.citrix.com (HELO SMTP.CITRIX.COM) (66.165.176.89) by server-5.tower-182.messagelabs.com with RC4-SHA encrypted SMTP; 13 Sep 2011 14:06:54 -0000 X-IronPort-AV: E=Sophos;i="4.68,374,1312171200"; d="scan'208";a="16928233" Received: from ftlpmailmx02.citrite.net ([10.13.107.66]) by FTLPIPO01.CITRIX.COM with ESMTP/TLS/RC4-MD5; 13 Sep 2011 10:06:52 -0400 Received: from smtp01.ad.xensource.com (10.219.128.104) by smtprelay.citrix.com (10.13.107.66) with Microsoft SMTP Server id 8.3.137.0; Tue, 13 Sep 2011 10:06:52 -0400 Received: from cosworth.uk.xensource.com (cosworth.uk.xensource.com [10.80.16.52]) by smtp01.ad.xensource.com (8.13.1/8.13.1) with ESMTP id p8DE6pqI021302; Tue, 13 Sep 2011 07:06:51 -0700 Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Mercurial-Node: 311080019e01809614dac0321b210ef1a9bbcb44 Message-ID: <311080019e01809614da.1315922810@cosworth.uk.xensource.com> User-Agent: Mercurial-patchbomb/1.6.4 Date: Tue, 13 Sep 2011 15:06:50 +0100 From: Ian Campbell To: xen-devel@lists.xensource.com Cc: Ian Campbell Subject: [Xen-devel] [PATCH] xl: fixup "xl save" command line handling X-BeenThere: xen-devel@lists.xensource.com X-Mailman-Version: 2.1.5 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xensource.com Errors-To: xen-devel-bounces@lists.xensource.com # HG changeset patch # User Ian Campbell # Date 1315922772 -3600 # Node ID 311080019e01809614dac0321b210ef1a9bbcb44 # Parent 4309ff9535001bdca8db93a439edd86bb4c447cd xl: fixup "xl save" command line handling. The save file paramter is required so ensure we have enough arguments. The config filename is optional so do not use argv[optind+3], which may well happen to be NULL when the paramter is not present but relying on that is pretty gross. Signed-off-by: Ian Campbell diff -r 4309ff953500 -r 311080019e01 tools/libxl/xl_cmdimpl.c --- a/tools/libxl/xl_cmdimpl.c Thu Sep 01 17:34:41 2011 +0100 +++ b/tools/libxl/xl_cmdimpl.c Tue Sep 13 15:06:12 2011 +0100 @@ -2856,8 +2856,8 @@ int main_migrate_receive(int argc, char int main_save(int argc, char **argv) { - const char *filename = NULL, *p = NULL; - const char *config_filename; + const char *filename, *p; + const char *config_filename = NULL; int checkpoint = 0; int opt; @@ -2871,14 +2871,16 @@ int main_save(int argc, char **argv) } } - if (argc-optind > 3) { + if (argc-optind < 2 || argc-optind > 3) { help("save"); return 2; } p = argv[optind]; filename = argv[optind + 1]; - config_filename = argv[optind + 2]; + if ( argc - optind >= 3 ) + config_filename = argv[optind + 2]; + save_domain(p, filename, checkpoint, config_filename); return 0; } _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel From xen-devel-bounces@lists.xensource.com Tue Sep 13 07:14:09 2011 Return-path: Envelope-to: www-data@lists.xensource.com Delivery-date: Tue, 13 Sep 2011 07:14:09 -0700 Received: from localhost ([127.0.0.1] helo=lists.colo.xensource.com) by lists.xensource.com with esmtp (Exim 4.43) id 1R3TkX-0007jr-FM; Tue, 13 Sep 2011 07:14:09 -0700 Received: from mail182.messagelabs.com ([85.158.139.83]) by lists.xensource.com with esmtp (Exim 4.43) id 1R3Tjs-0007Wi-Li for xen-devel@lists.xensource.com; Tue, 13 Sep 2011 07:13:29 -0700 X-Env-Sender: konrad.wilk@oracle.com X-Msg-Ref: server-4.tower-182.messagelabs.com!1315923204!18164951!1 X-Originating-IP: [141.146.126.227] X-StarScan-Version: 6.3.6; banners=-,-,- X-VirusChecked: Checked Received: (qmail 9331 invoked from network); 13 Sep 2011 14:13:25 -0000 Received: from acsinet15.oracle.com (HELO acsinet15.oracle.com) (141.146.126.227) by server-4.tower-182.messagelabs.com with DHE-RSA-AES256-SHA encrypted SMTP; 13 Sep 2011 14:13:25 -0000 Received: from rtcsinet21.oracle.com (rtcsinet21.oracle.com [66.248.204.29]) by acsinet15.oracle.com (Switch-3.4.4/Switch-3.4.4) with ESMTP id p8DED77T023754 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Tue, 13 Sep 2011 14:13:09 GMT Received: from acsmt356.oracle.com (acsmt356.oracle.com [141.146.40.156]) by rtcsinet21.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id p8DED4xC010507 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 13 Sep 2011 14:13:05 GMT Received: from abhmt112.oracle.com (abhmt112.oracle.com [141.146.116.64]) by acsmt356.oracle.com (8.12.11.20060308/8.12.11) with ESMTP id p8DECwcP001019; Tue, 13 Sep 2011 09:12:59 -0500 Received: from oracle.com (/209.6.55.207) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Tue, 13 Sep 2011 07:12:58 -0700 From: Konrad Rzeszutek Wilk To: thellstrom@vmware.com, linux-kernel@vger.kernel.org, xen-devel@lists.xensource.com, dri-devel@lists.freedesktop.org, thomas@shipmail.org Date: Tue, 13 Sep 2011 10:12:45 -0400 Message-Id: <1315923170-25568-3-git-send-email-konrad.wilk@oracle.com> X-Mailer: git-send-email 1.7.4.1 In-Reply-To: <1315923170-25568-1-git-send-email-konrad.wilk@oracle.com> References: <1315923170-25568-1-git-send-email-konrad.wilk@oracle.com> X-Source-IP: rtcsinet21.oracle.com [66.248.204.29] X-CT-RefId: str=0001.0A090201.4E6F64F6.0078,ss=1,re=0.000,fgs=0 Cc: Konrad Rzeszutek Wilk , airlied@linux.ie, Pekka Paalanen , bskeggs@redhat.com, alexdeucher@gmail.com, airlied@redhat.com, j.glisse@redhat.com Subject: [Xen-devel] [PATCH 2/7] ttm: Introduce ttm_page_alloc_func structure. X-BeenThere: xen-devel@lists.xensource.com X-Mailman-Version: 2.1.5 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xensource.com Errors-To: xen-devel-bounces@lists.xensource.com Which has the function members for all of the current page pool operations defined. The old calls (ttm_put_pages, ttm_get_pages, etc) are plumbed through little functions which lookup in the ttm_page_alloc_func the appropiate implementation and call it. There is currently only one page pool code so the default registration goes to 'ttm_page_alloc_default'. The subsequent patch "ttm: Provide a DMA aware TTM page pool code." introduces the one to be used when the SWIOTLB code is turned on (that implementation is a union of the default TTM pool code with the DMA pool code). Signed-off-by: Konrad Rzeszutek Wilk --- drivers/gpu/drm/ttm/ttm_memory.c | 3 ++ drivers/gpu/drm/ttm/ttm_page_alloc.c | 58 ++++++++++++++++++++++++++++---- include/drm/ttm/ttm_page_alloc.h | 60 ++++++++++++++++++++++++++++++++++ 3 files changed, 113 insertions(+), 8 deletions(-) diff --git a/drivers/gpu/drm/ttm/ttm_memory.c b/drivers/gpu/drm/ttm/ttm_memory.c index e70ddd8..c7d97a5 100644 --- a/drivers/gpu/drm/ttm/ttm_memory.c +++ b/drivers/gpu/drm/ttm/ttm_memory.c @@ -356,6 +356,8 @@ static int ttm_mem_init_dma32_zone(struct ttm_mem_global *glob, } #endif +struct ttm_page_alloc_func *ttm_page_alloc; + int ttm_mem_global_init(struct ttm_mem_global *glob) { struct sysinfo si; @@ -394,6 +396,7 @@ int ttm_mem_global_init(struct ttm_mem_global *glob) "Zone %7s: Available graphics memory: %llu kiB.\n", zone->name, (unsigned long long) zone->max_mem >> 10); } + ttm_page_alloc = &ttm_page_alloc_default; ttm_page_alloc_init(glob, glob->zone_kernel->max_mem/(2*PAGE_SIZE)); return 0; out_no_zone: diff --git a/drivers/gpu/drm/ttm/ttm_page_alloc.c b/drivers/gpu/drm/ttm/ttm_page_alloc.c index d948575..6a888f8 100644 --- a/drivers/gpu/drm/ttm/ttm_page_alloc.c +++ b/drivers/gpu/drm/ttm/ttm_page_alloc.c @@ -664,9 +664,9 @@ out: * On success pages list will hold count number of correctly * cached pages. */ -int ttm_get_pages(struct list_head *pages, int flags, - enum ttm_caching_state cstate, unsigned count, - dma_addr_t *dma_address) +int __ttm_get_pages(struct list_head *pages, int flags, + enum ttm_caching_state cstate, unsigned count, + dma_addr_t *dma_address) { struct ttm_page_pool *pool = ttm_get_pool(flags, cstate); struct page *p = NULL; @@ -734,8 +734,8 @@ int ttm_get_pages(struct list_head *pages, int flags, } /* Put all pages in pages list to correct pool to wait for reuse */ -void ttm_put_pages(struct list_head *pages, unsigned page_count, int flags, - enum ttm_caching_state cstate, dma_addr_t *dma_address) +void __ttm_put_pages(struct list_head *pages, unsigned page_count, int flags, + enum ttm_caching_state cstate, dma_addr_t *dma_address) { unsigned long irq_flags; struct ttm_page_pool *pool = ttm_get_pool(flags, cstate); @@ -785,7 +785,7 @@ static void ttm_page_pool_init_locked(struct ttm_page_pool *pool, int flags, pool->name = name; } -int ttm_page_alloc_init(struct ttm_mem_global *glob, unsigned max_pages) +int __ttm_page_alloc_init(struct ttm_mem_global *glob, unsigned max_pages) { int ret; @@ -822,7 +822,7 @@ int ttm_page_alloc_init(struct ttm_mem_global *glob, unsigned max_pages) return 0; } -void ttm_page_alloc_fini(void) +void __ttm_page_alloc_fini(void) { int i; @@ -836,7 +836,7 @@ void ttm_page_alloc_fini(void) _manager = NULL; } -int ttm_page_alloc_debugfs(struct seq_file *m, void *data) +int __ttm_page_alloc_debugfs(struct seq_file *m, void *data) { struct ttm_page_pool *p; unsigned i; @@ -856,4 +856,46 @@ int ttm_page_alloc_debugfs(struct seq_file *m, void *data) } return 0; } + +struct ttm_page_alloc_func ttm_page_alloc_default = { + .get_pages = __ttm_get_pages, + .put_pages = __ttm_put_pages, + .alloc_init = __ttm_page_alloc_init, + .alloc_fini = __ttm_page_alloc_fini, + .debugfs = __ttm_page_alloc_debugfs, +}; + +int ttm_get_pages(struct list_head *pages, int flags, + enum ttm_caching_state cstate, unsigned count, + dma_addr_t *dma_address) +{ + if (ttm_page_alloc && ttm_page_alloc->get_pages) + return ttm_page_alloc->get_pages(pages, flags, cstate, count, + dma_address); + return -1; +} +void ttm_put_pages(struct list_head *pages, unsigned page_count, int flags, + enum ttm_caching_state cstate, dma_addr_t *dma_address) +{ + if (ttm_page_alloc && ttm_page_alloc->put_pages) + ttm_page_alloc->put_pages(pages, page_count, flags, cstate, + dma_address); +} +int ttm_page_alloc_init(struct ttm_mem_global *glob, unsigned max_pages) +{ + if (ttm_page_alloc && ttm_page_alloc->alloc_init) + return ttm_page_alloc->alloc_init(glob, max_pages); + return -1; +} +void ttm_page_alloc_fini(void) +{ + if (ttm_page_alloc && ttm_page_alloc->alloc_fini) + ttm_page_alloc->alloc_fini(); +} +int ttm_page_alloc_debugfs(struct seq_file *m, void *data) +{ + if (ttm_page_alloc && ttm_page_alloc->debugfs) + return ttm_page_alloc->debugfs(m, data); + return -1; +} EXPORT_SYMBOL(ttm_page_alloc_debugfs); diff --git a/include/drm/ttm/ttm_page_alloc.h b/include/drm/ttm/ttm_page_alloc.h index 0017b17..6e8d73a 100644 --- a/include/drm/ttm/ttm_page_alloc.h +++ b/include/drm/ttm/ttm_page_alloc.h @@ -29,6 +29,66 @@ #include "ttm_bo_driver.h" #include "ttm_memory.h" +struct ttm_page_alloc_func { + /** + * struct ttm_page_alloc_func member get_pages + * Get count number of pages from pool to pages list. + * + * @pages: head of empty linked list where pages are filled. + * @flags: ttm flags for page allocation. + * @cstate: ttm caching state for the page. + * @count: number of pages to allocate. + * @dma_address: The DMA (bus) address of pages (by default zero). + */ + int (*get_pages) (struct list_head *pages, + int flags, + enum ttm_caching_state cstate, + unsigned count, + dma_addr_t *dma_address); + /** + * struct ttm_page_alloc_func member put_pages. + * + * Put linked list of pages to pool. + * + * @pages: list of pages to free. + * @page_count: number of pages in the list. Zero can be passed for + * unknown count. + * @flags: ttm flags for page allocation. + * @cstate: ttm caching state. + * @dma_address: The DMA (bus) address of pages (by default zero). + */ + void (*put_pages)(struct list_head *pages, + unsigned page_count, + int flags, + enum ttm_caching_state cstate, + dma_addr_t *dma_address); + /** + * struct ttm_page_alloc_func member alloc_init. + * + * Initialize pool allocator. + */ + int (*alloc_init)(struct ttm_mem_global *glob, unsigned max_pages); + + /** + * struct ttm_page_alloc_func member alloc_fini. + * + * Free pool allocator. + */ + void (*alloc_fini)(void); + + /** + * struct ttm_page_alloc_func member debugfs. + * + * Output the state of pools to debugfs file + */ + int (*debugfs)(struct seq_file *m, void *data); +}; + +extern struct ttm_page_alloc_func *ttm_page_alloc; + +/* Defined in ttm_page_alloc.c */ +extern struct ttm_page_alloc_func ttm_page_alloc_default; + /** * Get count number of pages from pool to pages list. * -- 1.7.4.1 _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel From xen-devel-bounces@lists.xensource.com Tue Sep 13 07:15:24 2011 Return-path: Envelope-to: www-data@lists.xensource.com Delivery-date: Tue, 13 Sep 2011 07:15:24 -0700 Received: from localhost ([127.0.0.1] helo=lists.colo.xensource.com) by lists.xensource.com with esmtp (Exim 4.43) id 1R3Tlj-00087I-Hc; Tue, 13 Sep 2011 07:15:23 -0700 Received: from mail27.messagelabs.com ([193.109.254.147]) by lists.xensource.com with esmtp (Exim 4.43) id 1R3Tjs-0007Wj-S5 for xen-devel@lists.xensource.com; Tue, 13 Sep 2011 07:13:29 -0700 X-Env-Sender: konrad.wilk@oracle.com X-Msg-Ref: server-9.tower-27.messagelabs.com!1315923188!44349532!1 X-Originating-IP: [148.87.113.117] X-StarScan-Version: 6.3.6; banners=-,-,- X-VirusChecked: Checked Received: (qmail 29980 invoked from network); 13 Sep 2011 14:13:10 -0000 Received: from rcsinet15.oracle.com (HELO rcsinet15.oracle.com) (148.87.113.117) by server-9.tower-27.messagelabs.com with DHE-RSA-AES256-SHA encrypted SMTP; 13 Sep 2011 14:13:10 -0000 Received: from rtcsinet21.oracle.com (rtcsinet21.oracle.com [66.248.204.29]) by rcsinet15.oracle.com (Switch-3.4.4/Switch-3.4.4) with ESMTP id p8DED7BI023966 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Tue, 13 Sep 2011 14:13:09 GMT Received: from acsmt357.oracle.com (acsmt357.oracle.com [141.146.40.157]) by rtcsinet21.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id p8DED5ho010549 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 13 Sep 2011 14:13:06 GMT Received: from abhmt112.oracle.com (abhmt112.oracle.com [141.146.116.64]) by acsmt357.oracle.com (8.12.11.20060308/8.12.11) with ESMTP id p8DED06j009614; Tue, 13 Sep 2011 09:13:00 -0500 Received: from oracle.com (/209.6.55.207) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Tue, 13 Sep 2011 07:12:59 -0700 From: Konrad Rzeszutek Wilk To: thellstrom@vmware.com, linux-kernel@vger.kernel.org, xen-devel@lists.xensource.com, dri-devel@lists.freedesktop.org, thomas@shipmail.org Date: Tue, 13 Sep 2011 10:12:46 -0400 Message-Id: <1315923170-25568-4-git-send-email-konrad.wilk@oracle.com> X-Mailer: git-send-email 1.7.4.1 In-Reply-To: <1315923170-25568-1-git-send-email-konrad.wilk@oracle.com> References: <1315923170-25568-1-git-send-email-konrad.wilk@oracle.com> X-Source-IP: rtcsinet21.oracle.com [66.248.204.29] X-CT-RefId: str=0001.0A090209.4E6F64F6.002A,ss=1,re=-2.300,fgs=0 Cc: Konrad Rzeszutek Wilk , airlied@linux.ie, Pekka Paalanen , bskeggs@redhat.com, alexdeucher@gmail.com, airlied@redhat.com, j.glisse@redhat.com Subject: [Xen-devel] [PATCH 3/7] ttm: Pass in 'struct device' to TTM so it can do DMA API on behalf of device. X-BeenThere: xen-devel@lists.xensource.com X-Mailman-Version: 2.1.5 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xensource.com Errors-To: xen-devel-bounces@lists.xensource.com We want to pass in the 'struct device' to the TTM layer so that the TTM DMA pool code (if enabled) can use it. The DMA API code needs the 'struct device' to do the DMA API operations. Signed-off-by: Konrad Rzeszutek Wilk --- drivers/gpu/drm/nouveau/nouveau_mem.c | 3 ++- drivers/gpu/drm/radeon/radeon_ttm.c | 3 ++- drivers/gpu/drm/ttm/ttm_bo.c | 4 +++- drivers/gpu/drm/ttm/ttm_page_alloc.c | 17 ++++++++++------- drivers/gpu/drm/ttm/ttm_tt.c | 5 +++-- drivers/gpu/drm/vmwgfx/vmwgfx_drv.c | 4 ++-- include/drm/ttm/ttm_bo_driver.h | 7 ++++++- include/drm/ttm/ttm_page_alloc.h | 16 ++++++++++++---- 8 files changed, 40 insertions(+), 19 deletions(-) diff --git a/drivers/gpu/drm/nouveau/nouveau_mem.c b/drivers/gpu/drm/nouveau/nouveau_mem.c index 5ee14d2..a2d7e35 100644 --- a/drivers/gpu/drm/nouveau/nouveau_mem.c +++ b/drivers/gpu/drm/nouveau/nouveau_mem.c @@ -417,7 +417,8 @@ nouveau_mem_vram_init(struct drm_device *dev) ret = ttm_bo_device_init(&dev_priv->ttm.bdev, dev_priv->ttm.bo_global_ref.ref.object, &nouveau_bo_driver, DRM_FILE_PAGE_OFFSET, - dma_bits <= 32 ? true : false); + dma_bits <= 32 ? true : false, + dev->dev); if (ret) { NV_ERROR(dev, "Error initialising bo driver: %d\n", ret); return ret; diff --git a/drivers/gpu/drm/radeon/radeon_ttm.c b/drivers/gpu/drm/radeon/radeon_ttm.c index 60125dd..dbc6bcb 100644 --- a/drivers/gpu/drm/radeon/radeon_ttm.c +++ b/drivers/gpu/drm/radeon/radeon_ttm.c @@ -517,7 +517,8 @@ int radeon_ttm_init(struct radeon_device *rdev) r = ttm_bo_device_init(&rdev->mman.bdev, rdev->mman.bo_global_ref.ref.object, &radeon_bo_driver, DRM_FILE_PAGE_OFFSET, - rdev->need_dma32); + rdev->need_dma32, + rdev->dev); if (r) { DRM_ERROR("failed initializing buffer object driver(%d).\n", r); return r; diff --git a/drivers/gpu/drm/ttm/ttm_bo.c b/drivers/gpu/drm/ttm/ttm_bo.c index 2e618b5..0358889 100644 --- a/drivers/gpu/drm/ttm/ttm_bo.c +++ b/drivers/gpu/drm/ttm/ttm_bo.c @@ -1527,12 +1527,14 @@ int ttm_bo_device_init(struct ttm_bo_device *bdev, struct ttm_bo_global *glob, struct ttm_bo_driver *driver, uint64_t file_page_offset, - bool need_dma32) + bool need_dma32, + struct device *dev) { int ret = -EINVAL; rwlock_init(&bdev->vm_lock); bdev->driver = driver; + bdev->dev = dev; memset(bdev->man, 0, sizeof(bdev->man)); diff --git a/drivers/gpu/drm/ttm/ttm_page_alloc.c b/drivers/gpu/drm/ttm/ttm_page_alloc.c index 6a888f8..f9a4d83 100644 --- a/drivers/gpu/drm/ttm/ttm_page_alloc.c +++ b/drivers/gpu/drm/ttm/ttm_page_alloc.c @@ -666,7 +666,7 @@ out: */ int __ttm_get_pages(struct list_head *pages, int flags, enum ttm_caching_state cstate, unsigned count, - dma_addr_t *dma_address) + dma_addr_t *dma_address, struct device *dev) { struct ttm_page_pool *pool = ttm_get_pool(flags, cstate); struct page *p = NULL; @@ -724,7 +724,8 @@ int __ttm_get_pages(struct list_head *pages, int flags, printk(KERN_ERR TTM_PFX "Failed to allocate extra pages " "for large request."); - ttm_put_pages(pages, 0, flags, cstate, NULL); + ttm_put_pages(pages, 0, flags, cstate, dma_address, + dev); return r; } } @@ -735,7 +736,8 @@ int __ttm_get_pages(struct list_head *pages, int flags, /* Put all pages in pages list to correct pool to wait for reuse */ void __ttm_put_pages(struct list_head *pages, unsigned page_count, int flags, - enum ttm_caching_state cstate, dma_addr_t *dma_address) + enum ttm_caching_state cstate, dma_addr_t *dma_address, + struct device *dev) { unsigned long irq_flags; struct ttm_page_pool *pool = ttm_get_pool(flags, cstate); @@ -867,19 +869,20 @@ struct ttm_page_alloc_func ttm_page_alloc_default = { int ttm_get_pages(struct list_head *pages, int flags, enum ttm_caching_state cstate, unsigned count, - dma_addr_t *dma_address) + dma_addr_t *dma_address, struct device *dev) { if (ttm_page_alloc && ttm_page_alloc->get_pages) return ttm_page_alloc->get_pages(pages, flags, cstate, count, - dma_address); + dma_address, dev); return -1; } void ttm_put_pages(struct list_head *pages, unsigned page_count, int flags, - enum ttm_caching_state cstate, dma_addr_t *dma_address) + enum ttm_caching_state cstate, dma_addr_t *dma_address, + struct device *dev) { if (ttm_page_alloc && ttm_page_alloc->put_pages) ttm_page_alloc->put_pages(pages, page_count, flags, cstate, - dma_address); + dma_address, dev); } int ttm_page_alloc_init(struct ttm_mem_global *glob, unsigned max_pages) { diff --git a/drivers/gpu/drm/ttm/ttm_tt.c b/drivers/gpu/drm/ttm/ttm_tt.c index 58c271e..1f11a33 100644 --- a/drivers/gpu/drm/ttm/ttm_tt.c +++ b/drivers/gpu/drm/ttm/ttm_tt.c @@ -111,7 +111,7 @@ static struct page *__ttm_tt_get_page(struct ttm_tt *ttm, int index) INIT_LIST_HEAD(&h); ret = ttm_get_pages(&h, ttm->page_flags, ttm->caching_state, 1, - &ttm->dma_address[index]); + &ttm->dma_address[index], ttm->dev); if (ret != 0) return NULL; @@ -305,7 +305,7 @@ static void ttm_tt_free_alloced_pages(struct ttm_tt *ttm) } } ttm_put_pages(&h, count, ttm->page_flags, ttm->caching_state, - ttm->dma_address); + ttm->dma_address, ttm->dev); ttm->state = tt_unpopulated; ttm->first_himem_page = ttm->num_pages; ttm->last_lomem_page = -1; @@ -398,6 +398,7 @@ struct ttm_tt *ttm_tt_create(struct ttm_bo_device *bdev, unsigned long size, ttm->last_lomem_page = -1; ttm->caching_state = tt_cached; ttm->page_flags = page_flags; + ttm->dev = bdev->dev; ttm->dummy_read_page = dummy_read_page; diff --git a/drivers/gpu/drm/vmwgfx/vmwgfx_drv.c b/drivers/gpu/drm/vmwgfx/vmwgfx_drv.c index 96949b9..d266ae7 100644 --- a/drivers/gpu/drm/vmwgfx/vmwgfx_drv.c +++ b/drivers/gpu/drm/vmwgfx/vmwgfx_drv.c @@ -322,11 +322,11 @@ static int vmw_driver_load(struct drm_device *dev, unsigned long chipset) ttm_lock_set_kill(&dev_priv->fbdev_master.lock, false, SIGTERM); dev_priv->active_master = &dev_priv->fbdev_master; - ret = ttm_bo_device_init(&dev_priv->bdev, dev_priv->bo_global_ref.ref.object, &vmw_bo_driver, VMWGFX_FILE_PAGE_OFFSET, - false); + false, + dev->dev); if (unlikely(ret != 0)) { DRM_ERROR("Failed initializing TTM buffer object driver.\n"); goto out_err1; diff --git a/include/drm/ttm/ttm_bo_driver.h b/include/drm/ttm/ttm_bo_driver.h index 09af2d7..9a7ecae 100644 --- a/include/drm/ttm/ttm_bo_driver.h +++ b/include/drm/ttm/ttm_bo_driver.h @@ -177,6 +177,7 @@ struct ttm_tt { tt_unpopulated, } state; dma_addr_t *dma_address; + struct device *dev; }; #define TTM_MEMTYPE_FLAG_FIXED (1 << 0) /* Fixed (on-card) PCI memory */ @@ -551,6 +552,7 @@ struct ttm_bo_device { struct list_head device_list; struct ttm_bo_global *glob; struct ttm_bo_driver *driver; + struct device *dev; rwlock_t vm_lock; struct ttm_mem_type_manager man[TTM_NUM_MEM_TYPES]; spinlock_t fence_lock; @@ -791,6 +793,8 @@ extern int ttm_bo_device_release(struct ttm_bo_device *bdev); * @file_page_offset: Offset into the device address space that is available * for buffer data. This ensures compatibility with other users of the * address space. + * @need_dma32: Allocate pages under 4GB + * @dev: 'struct device' of the PCI device. * * Initializes a struct ttm_bo_device: * Returns: @@ -799,7 +803,8 @@ extern int ttm_bo_device_release(struct ttm_bo_device *bdev); extern int ttm_bo_device_init(struct ttm_bo_device *bdev, struct ttm_bo_global *glob, struct ttm_bo_driver *driver, - uint64_t file_page_offset, bool need_dma32); + uint64_t file_page_offset, bool need_dma32, + struct device *dev); /** * ttm_bo_unmap_virtual diff --git a/include/drm/ttm/ttm_page_alloc.h b/include/drm/ttm/ttm_page_alloc.h index 6e8d73a..8fc92f2 100644 --- a/include/drm/ttm/ttm_page_alloc.h +++ b/include/drm/ttm/ttm_page_alloc.h @@ -39,12 +39,14 @@ struct ttm_page_alloc_func { * @cstate: ttm caching state for the page. * @count: number of pages to allocate. * @dma_address: The DMA (bus) address of pages (by default zero). + * @dev: The device that needs this. */ int (*get_pages) (struct list_head *pages, int flags, enum ttm_caching_state cstate, unsigned count, - dma_addr_t *dma_address); + dma_addr_t *dma_address, + struct device *dev); /** * struct ttm_page_alloc_func member put_pages. * @@ -56,12 +58,14 @@ struct ttm_page_alloc_func { * @flags: ttm flags for page allocation. * @cstate: ttm caching state. * @dma_address: The DMA (bus) address of pages (by default zero). + * @dev: The device that needs this. */ void (*put_pages)(struct list_head *pages, unsigned page_count, int flags, enum ttm_caching_state cstate, - dma_addr_t *dma_address); + dma_addr_t *dma_address, + struct device *dev); /** * struct ttm_page_alloc_func member alloc_init. * @@ -97,12 +101,14 @@ extern struct ttm_page_alloc_func ttm_page_alloc_default; * @cstate: ttm caching state for the page. * @count: number of pages to allocate. * @dma_address: The DMA (bus) address of pages - (by default zero). + * @dev: The device that needs this. */ int ttm_get_pages(struct list_head *pages, int flags, enum ttm_caching_state cstate, unsigned count, - dma_addr_t *dma_address); + dma_addr_t *dma_address, + struct device *dev); /** * Put linked list of pages to pool. * @@ -112,12 +118,14 @@ int ttm_get_pages(struct list_head *pages, * @flags: ttm flags for page allocation. * @cstate: ttm caching state. * @dma_address: The DMA (bus) address of pages (by default zero). + * @dev: The device that needs this. */ void ttm_put_pages(struct list_head *pages, unsigned page_count, int flags, enum ttm_caching_state cstate, - dma_addr_t *dma_address); + dma_addr_t *dma_address, + struct device *dev); /** * Initialize pool allocator. */ -- 1.7.4.1 _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel From xen-devel-bounces@lists.xensource.com Tue Sep 13 07:16:36 2011 Return-path: Envelope-to: www-data@lists.xensource.com Delivery-date: Tue, 13 Sep 2011 07:16:36 -0700 Received: from localhost ([127.0.0.1] helo=lists.colo.xensource.com) by lists.xensource.com with esmtp (Exim 4.43) id 1R3Tmu-00007l-Na; Tue, 13 Sep 2011 07:16:36 -0700 Received: from mail21.messagelabs.com ([85.158.143.35]) by lists.xensource.com with esmtp (Exim 4.43) id 1R3Tjw-0007Wu-L5 for xen-devel@lists.xensource.com; Tue, 13 Sep 2011 07:13:33 -0700 X-Env-Sender: konrad.wilk@oracle.com X-Msg-Ref: server-2.tower-21.messagelabs.com!1315923207!33933383!1 X-Originating-IP: [148.87.113.117] X-StarScan-Version: 6.4.1; banners=-,-,- X-VirusChecked: Checked Received: (qmail 5641 invoked from network); 13 Sep 2011 14:13:28 -0000 Received: from rcsinet15.oracle.com (HELO rcsinet15.oracle.com) (148.87.113.117) by server-2.tower-21.messagelabs.com with DHE-RSA-AES256-SHA encrypted SMTP; 13 Sep 2011 14:13:28 -0000 Received: from acsinet21.oracle.com (acsinet21.oracle.com [141.146.126.237]) by rcsinet15.oracle.com (Switch-3.4.4/Switch-3.4.4) with ESMTP id p8DEDAK9024118 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Tue, 13 Sep 2011 14:13:12 GMT Received: from acsmt357.oracle.com (acsmt357.oracle.com [141.146.40.157]) by acsinet21.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id p8DED9LQ016217 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 13 Sep 2011 14:13:09 GMT Received: from abhmt112.oracle.com (abhmt112.oracle.com [141.146.116.64]) by acsmt357.oracle.com (8.12.11.20060308/8.12.11) with ESMTP id p8DED4JQ009702; Tue, 13 Sep 2011 09:13:04 -0500 Received: from oracle.com (/209.6.55.207) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Tue, 13 Sep 2011 07:13:04 -0700 From: Konrad Rzeszutek Wilk To: thellstrom@vmware.com, linux-kernel@vger.kernel.org, xen-devel@lists.xensource.com, dri-devel@lists.freedesktop.org, thomas@shipmail.org Date: Tue, 13 Sep 2011 10:12:50 -0400 Message-Id: <1315923170-25568-8-git-send-email-konrad.wilk@oracle.com> X-Mailer: git-send-email 1.7.4.1 In-Reply-To: <1315923170-25568-1-git-send-email-konrad.wilk@oracle.com> References: <1315923170-25568-1-git-send-email-konrad.wilk@oracle.com> X-Source-IP: acsinet21.oracle.com [141.146.126.237] X-Auth-Type: Internal IP X-CT-RefId: str=0001.0A090203.4E6F64F9.0004:SCFMA922111,ss=1,re=-4.000,fgs=0 Cc: Konrad Rzeszutek Wilk , airlied@linux.ie, Pekka Paalanen , bskeggs@redhat.com, alexdeucher@gmail.com, airlied@redhat.com, j.glisse@redhat.com Subject: [Xen-devel] [PATCH 7/7] nouveau/radeon: Set coherent DMA mask X-BeenThere: xen-devel@lists.xensource.com X-Mailman-Version: 2.1.5 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xensource.com Errors-To: xen-devel-bounces@lists.xensource.com All the storage devices that use the dmapool set the coherent DMA mask so they can properly use the dmapool. Since the TTM DMA pool code is based on that and dma_alloc_coherent checks the 'coherent_dma_mask' and not 'dma_mask' we want to set it. Signed-off-by: Konrad Rzeszutek Wilk --- drivers/gpu/drm/nouveau/nouveau_mem.c | 5 +++++ drivers/gpu/drm/radeon/radeon_device.c | 6 ++++++ 2 files changed, 11 insertions(+), 0 deletions(-) diff --git a/drivers/gpu/drm/nouveau/nouveau_mem.c b/drivers/gpu/drm/nouveau/nouveau_mem.c index a2d7e35..bb6ccbd 100644 --- a/drivers/gpu/drm/nouveau/nouveau_mem.c +++ b/drivers/gpu/drm/nouveau/nouveau_mem.c @@ -408,6 +408,11 @@ nouveau_mem_vram_init(struct drm_device *dev) if (ret) return ret; + ret = pci_set_consistent_dma_mask(dev->pdev, DMA_BIT_MASK(dma_bits)); + if (ret) { + /* Reset to default value. */ + pci_set_consistent_dma_mask(dev->pdev, DMA_BIT_MASK(32)); + } dev_priv->fb_phys = pci_resource_start(dev->pdev, 1); ret = nouveau_ttm_global_init(dev_priv); diff --git a/drivers/gpu/drm/radeon/radeon_device.c b/drivers/gpu/drm/radeon/radeon_device.c index 7cfaa7e..0c0a970 100644 --- a/drivers/gpu/drm/radeon/radeon_device.c +++ b/drivers/gpu/drm/radeon/radeon_device.c @@ -757,8 +757,14 @@ int radeon_device_init(struct radeon_device *rdev, r = pci_set_dma_mask(rdev->pdev, DMA_BIT_MASK(dma_bits)); if (r) { rdev->need_dma32 = true; + dma_bits = 32; printk(KERN_WARNING "radeon: No suitable DMA available.\n"); } + r = pci_set_consistent_dma_mask(rdev->pdev, DMA_BIT_MASK(dma_bits)); + if (r) { + pci_set_consistent_dma_mask(rdev->pdev, DMA_BIT_MASK(32)); + printk(KERN_WARNING "radeon: No coherent DMA available.\n"); + } /* Registers mapping */ /* TODO: block userspace mapping of io register */ -- 1.7.4.1 _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel From xen-devel-bounces@lists.xensource.com Tue Sep 13 07:17:32 2011 Return-path: Envelope-to: www-data@lists.xensource.com Delivery-date: Tue, 13 Sep 2011 07:17:32 -0700 Received: from localhost ([127.0.0.1] helo=lists.colo.xensource.com) by lists.xensource.com with esmtp (Exim 4.43) id 1R3Tno-0000VJ-Al; Tue, 13 Sep 2011 07:17:32 -0700 Received: from mail27.messagelabs.com ([193.109.254.147]) by lists.xensource.com with esmtp (Exim 4.43) id 1R3Tjy-0007Wx-3s for xen-devel@lists.xensource.com; Tue, 13 Sep 2011 07:13:35 -0700 X-Env-Sender: konrad.wilk@oracle.com X-Msg-Ref: server-15.tower-27.messagelabs.com!1315923201!48584748!1 X-Originating-IP: [141.146.126.227] X-StarScan-Version: 6.3.6; banners=-,-,- X-VirusChecked: Checked Received: (qmail 9699 invoked from network); 13 Sep 2011 14:13:23 -0000 Received: from acsinet15.oracle.com (HELO acsinet15.oracle.com) (141.146.126.227) by server-15.tower-27.messagelabs.com with DHE-RSA-AES256-SHA encrypted SMTP; 13 Sep 2011 14:13:23 -0000 Received: from rtcsinet21.oracle.com (rtcsinet21.oracle.com [66.248.204.29]) by acsinet15.oracle.com (Switch-3.4.4/Switch-3.4.4) with ESMTP id p8DEDAIa023914 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Tue, 13 Sep 2011 14:13:13 GMT Received: from acsmt358.oracle.com (acsmt358.oracle.com [141.146.40.158]) by rtcsinet21.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id p8DED9CO010760 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 13 Sep 2011 14:13:10 GMT Received: from abhmt112.oracle.com (abhmt112.oracle.com [141.146.116.64]) by acsmt358.oracle.com (8.12.11.20060308/8.12.11) with ESMTP id p8DED3Zj017502; Tue, 13 Sep 2011 09:13:03 -0500 Received: from oracle.com (/209.6.55.207) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Tue, 13 Sep 2011 07:13:03 -0700 From: Konrad Rzeszutek Wilk To: thellstrom@vmware.com, linux-kernel@vger.kernel.org, xen-devel@lists.xensource.com, dri-devel@lists.freedesktop.org, thomas@shipmail.org Date: Tue, 13 Sep 2011 10:12:49 -0400 Message-Id: <1315923170-25568-7-git-send-email-konrad.wilk@oracle.com> X-Mailer: git-send-email 1.7.4.1 In-Reply-To: <1315923170-25568-1-git-send-email-konrad.wilk@oracle.com> References: <1315923170-25568-1-git-send-email-konrad.wilk@oracle.com> X-Source-IP: rtcsinet21.oracle.com [66.248.204.29] X-CT-RefId: str=0001.0A090204.4E6F64F9.0144,ss=1,re=0.000,fgs=0 Cc: Konrad Rzeszutek Wilk , airlied@linux.ie, Pekka Paalanen , bskeggs@redhat.com, alexdeucher@gmail.com, airlied@redhat.com, j.glisse@redhat.com Subject: [Xen-devel] [PATCH 6/7] ttm: Add 'no_dma' parameter to turn the TTM DMA pool off during runtime. X-BeenThere: xen-devel@lists.xensource.com X-Mailman-Version: 2.1.5 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xensource.com Errors-To: xen-devel-bounces@lists.xensource.com The TTM DMA only gets turned on when the SWIOTLB is enabled - but we might also want to turn it off when SWIOTLB is on to use the non-DMA TTM pool code. In the future this parameter can be removed. Signed-off-by: Konrad Rzeszutek Wilk --- drivers/gpu/drm/ttm/ttm_page_alloc_dma.c | 4 ++++ include/drm/ttm/ttm_page_alloc.h | 4 ++-- 2 files changed, 6 insertions(+), 2 deletions(-) diff --git a/drivers/gpu/drm/ttm/ttm_page_alloc_dma.c b/drivers/gpu/drm/ttm/ttm_page_alloc_dma.c index 5a5739c..5909d28 100644 --- a/drivers/gpu/drm/ttm/ttm_page_alloc_dma.c +++ b/drivers/gpu/drm/ttm/ttm_page_alloc_dma.c @@ -51,6 +51,10 @@ #include #endif +int __read_mostly dma_ttm_disable; +MODULE_PARM_DESC(no_dma, "Disable TTM DMA pool"); +module_param_named(no_dma, dma_ttm_disable, bool, S_IRUGO); + #define NUM_PAGES_TO_ALLOC (PAGE_SIZE/sizeof(struct page *)) #define SMALL_ALLOCATION 16 #define FREE_ALL_PAGES (~0U) diff --git a/include/drm/ttm/ttm_page_alloc.h b/include/drm/ttm/ttm_page_alloc.h index 192c5f8..e75af77 100644 --- a/include/drm/ttm/ttm_page_alloc.h +++ b/include/drm/ttm/ttm_page_alloc.h @@ -103,10 +103,10 @@ extern struct ttm_page_alloc_func ttm_page_alloc_default; #ifdef CONFIG_SWIOTLB /* Defined in ttm_page_alloc_dma.c */ extern struct ttm_page_alloc_func ttm_page_alloc_dma; - +extern int dma_ttm_disable; static inline bool ttm_page_alloc_need_dma(void) { - if (swiotlb_enabled()) { + if (!dma_ttm_disable && swiotlb_enabled()) { ttm_page_alloc = &ttm_page_alloc_dma; return true; } -- 1.7.4.1 _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel From xen-devel-bounces@lists.xensource.com Tue Sep 13 07:18:28 2011 Return-path: Envelope-to: www-data@lists.xensource.com Delivery-date: Tue, 13 Sep 2011 07:18:28 -0700 Received: from localhost ([127.0.0.1] helo=lists.colo.xensource.com) by lists.xensource.com with esmtp (Exim 4.43) id 1R3Toh-0000sS-TE; Tue, 13 Sep 2011 07:18:27 -0700 Received: from mail21.messagelabs.com ([85.158.143.35]) by lists.xensource.com with esmtp (Exim 4.43) id 1R3Tk2-0007YQ-OX for xen-devel@lists.xensource.com; Tue, 13 Sep 2011 07:13:41 -0700 X-Env-Sender: konrad.wilk@oracle.com X-Msg-Ref: server-15.tower-21.messagelabs.com!1315923215!50417210!1 X-Originating-IP: [141.146.126.227] X-StarScan-Version: 6.4.1; banners=-,-,- X-VirusChecked: Checked Received: (qmail 4539 invoked from network); 13 Sep 2011 14:13:36 -0000 Received: from acsinet15.oracle.com (HELO acsinet15.oracle.com) (141.146.126.227) by server-15.tower-21.messagelabs.com with DHE-RSA-AES256-SHA encrypted SMTP; 13 Sep 2011 14:13:36 -0000 Received: from rtcsinet22.oracle.com (rtcsinet22.oracle.com [66.248.204.30]) by acsinet15.oracle.com (Switch-3.4.4/Switch-3.4.4) with ESMTP id p8DED9to023857 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Tue, 13 Sep 2011 14:13:11 GMT Received: from acsmt356.oracle.com (acsmt356.oracle.com [141.146.40.156]) by rtcsinet22.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id p8DED7MC001611 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 13 Sep 2011 14:13:08 GMT Received: from abhmt112.oracle.com (abhmt112.oracle.com [141.146.116.64]) by acsmt356.oracle.com (8.12.11.20060308/8.12.11) with ESMTP id p8DED2iQ001109; Tue, 13 Sep 2011 09:13:02 -0500 Received: from oracle.com (/209.6.55.207) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Tue, 13 Sep 2011 07:13:02 -0700 From: Konrad Rzeszutek Wilk To: thellstrom@vmware.com, linux-kernel@vger.kernel.org, xen-devel@lists.xensource.com, dri-devel@lists.freedesktop.org, thomas@shipmail.org Date: Tue, 13 Sep 2011 10:12:48 -0400 Message-Id: <1315923170-25568-6-git-send-email-konrad.wilk@oracle.com> X-Mailer: git-send-email 1.7.4.1 In-Reply-To: <1315923170-25568-1-git-send-email-konrad.wilk@oracle.com> References: <1315923170-25568-1-git-send-email-konrad.wilk@oracle.com> MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit X-Source-IP: rtcsinet22.oracle.com [66.248.204.30] X-CT-RefId: str=0001.0A090201.4E6F64F8.0093,ss=1,re=-2.601,fgs=0 Cc: Konrad Rzeszutek Wilk , airlied@linux.ie, Pekka Paalanen , bskeggs@redhat.com, alexdeucher@gmail.com, airlied@redhat.com, j.glisse@redhat.com Subject: [Xen-devel] [PATCH 5/7] ttm: Provide a DMA aware TTM page pool code. X-BeenThere: xen-devel@lists.xensource.com X-Mailman-Version: 2.1.5 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xensource.com Errors-To: xen-devel-bounces@lists.xensource.com In TTM world the pages for the graphic drivers are kept in three different pools: write combined, uncached, and cached (write-back). When the pages are used by the graphic driver the graphic adapter via its built in MMU (or AGP) programs these pages in. The programming requires the virtual address (from the graphic adapter perspective) and the physical address (either System RAM or the memory on the card) which is obtained using the pci_map_* calls (which does the virtual to physical - or bus address translation). During the graphic application's "life" those pages can be shuffled around, swapped out to disk, moved from the VRAM to System RAM or vice-versa. This all works with the existing TTM pool code - except when we want to use the software IOTLB (SWIOTLB) code to "map" the physical addresses to the graphic adapter MMU. We end up programming the bounce buffer's physical address instead of the TTM pool memory's and get a non-worky driver. There are two solutions: 1) using the DMA API to allocate pages that are screened by the DMA API, or 2) using the pci_sync_* calls to copy the pages from the bounce-buffer and back. This patch fixes the issue by allocating pages using the DMA API. The second is a viable option - but it has performance drawbacks and potential correctness issues - think of the write cache page being bounced (SWIOTLB->TTM), the WC is set on the TTM page and the copy from SWIOTLB not making it to the TTM page until the page has been recycled in the pool (and used by another application). The bounce buffer does not get activated often - only in cases where we have a 32-bit capable card and we want to use a page that is allocated above the 4GB limit. The bounce buffer offers the solution of copying the contents of that 4GB page to an location below 4GB and then back when the operation has been completed (or vice-versa). This is done by using the 'pci_sync_*' calls. Note: If you look carefully enough in the existing TTM page pool code you will notice the GFP_DMA32 flag is used - which should guarantee that the provided page is under 4GB. It certainly is the case, except this gets ignored in two cases: - If user specifies 'swiotlb=force' which bounces _every_ page. - If user is using a Xen's PV Linux guest (which uses the SWIOTLB and the underlaying PFN's aren't necessarily under 4GB). To not have this extra copying done the other option is to allocate the pages using the DMA API so that there is not need to map the page and perform the expensive 'pci_sync_*' calls. This DMA API capable TTM pool requires for this the 'struct device' to properly call the DMA API. It also has to track the virtual and bus address of the page being handed out in case it ends up being swapped out or de-allocated - to make sure it is de-allocated using the proper's 'struct device'. Implementation wise the code keeps two lists: one that is attached to the 'struct device' (via the dev->dma_pools list) and a global one to be used when the 'struct device' is unavailable (think shrinker code). The global list can iterate over all of the 'struct device' and its associated dma_pool. The list in dev->dma_pools can only iterate the device's dma_pool. /[struct device_pool]\ /---------------------------------------------------| dev | / +-------| dma_pool | /-----+------\ / \--------------------/ |struct device| /-->[struct dma_pool for WC][struct dma_pool for uncached]<-/--| dma_pool | \-----+------/ / \--------------------/ \----------------------------------------------/ [Two pools associated with the device (WC and UC), and the parallel list containing the 'struct dev' and 'struct dma_pool' entries] The maximum amount of dma pools a device can have is six: write-combined, uncached, and cached; then there are the DMA32 variants which are: write-combined dma32, uncached dma32, and cached dma32. Currently this code only gets activated when any variant of the SWIOTLB IOMMU code is running (Intel without VT-d, AMD without GART, IBM Calgary and Xen PV with PCI devices). Signed-off-by: Konrad Rzeszutek Wilk Tested-by: Michel Dänzer --- drivers/gpu/drm/ttm/Makefile | 3 + drivers/gpu/drm/ttm/ttm_memory.c | 2 + drivers/gpu/drm/ttm/ttm_page_alloc_dma.c | 1313 ++++++++++++++++++++++++++++++ include/drm/ttm/ttm_page_alloc.h | 32 +- 4 files changed, 1346 insertions(+), 4 deletions(-) create mode 100644 drivers/gpu/drm/ttm/ttm_page_alloc_dma.c diff --git a/drivers/gpu/drm/ttm/Makefile b/drivers/gpu/drm/ttm/Makefile index f3cf6f0..8300bc0 100644 --- a/drivers/gpu/drm/ttm/Makefile +++ b/drivers/gpu/drm/ttm/Makefile @@ -7,4 +7,7 @@ ttm-y := ttm_agp_backend.o ttm_memory.o ttm_tt.o ttm_bo.o \ ttm_object.o ttm_lock.o ttm_execbuf_util.o ttm_page_alloc.o \ ttm_bo_manager.o +ifeq ($(CONFIG_SWIOTLB),y) +ttm-y += ttm_page_alloc_dma.o +endif obj-$(CONFIG_DRM_TTM) += ttm.o diff --git a/drivers/gpu/drm/ttm/ttm_memory.c b/drivers/gpu/drm/ttm/ttm_memory.c index c7d97a5..57323fe 100644 --- a/drivers/gpu/drm/ttm/ttm_memory.c +++ b/drivers/gpu/drm/ttm/ttm_memory.c @@ -397,6 +397,8 @@ int ttm_mem_global_init(struct ttm_mem_global *glob) zone->name, (unsigned long long) zone->max_mem >> 10); } ttm_page_alloc = &ttm_page_alloc_default; + if (ttm_page_alloc_need_dma()) + printk(KERN_INFO TTM_PFX "Using DMA aware pool.\n"); ttm_page_alloc_init(glob, glob->zone_kernel->max_mem/(2*PAGE_SIZE)); return 0; out_no_zone: diff --git a/drivers/gpu/drm/ttm/ttm_page_alloc_dma.c b/drivers/gpu/drm/ttm/ttm_page_alloc_dma.c new file mode 100644 index 0000000..5a5739c --- /dev/null +++ b/drivers/gpu/drm/ttm/ttm_page_alloc_dma.c @@ -0,0 +1,1313 @@ +/* + * Copyright 2011 (c) Oracle Corp. + + * Permission is hereby granted, free of charge, to any person obtaining a + * copy of this software and associated documentation files (the "Software"), + * to deal in the Software without restriction, including without limitation + * the rights to use, copy, modify, merge, publish, distribute, sub license, + * and/or sell copies of the Software, and to permit persons to whom the + * Software is furnished to do so, subject to the following conditions: + * + * The above copyright notice and this permission notice (including the + * next paragraph) shall be included in all copies or substantial portions + * of the Software. + * + * THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR + * IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY, + * FITNESS FOR A PARTICULAR PURPOSE AND NON-INFRINGEMENT. IN NO EVENT SHALL + * THE AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER + * LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING + * FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER + * DEALINGS IN THE SOFTWARE. + * + * Author: Konrad Rzeszutek Wilk + */ + +/* + * A simple DMA pool losely based on dmapool.c. It has certain advantages + * over the DMA pools: + * - Pool collects resently freed pages for reuse (and hooks up to + * the shrinker). + * - Tracks currently in use pages + * - Tracks whether the page is UC, WB or cached (and reverts to WB + * when freed). + */ + +#include +#include +#include /* for seq_printf */ +#include +#include +#include +#include +#include +#include +#include +#include +#include +#include "ttm/ttm_bo_driver.h" +#include "ttm/ttm_page_alloc.h" +#ifdef TTM_HAS_AGP +#include +#endif + +#define NUM_PAGES_TO_ALLOC (PAGE_SIZE/sizeof(struct page *)) +#define SMALL_ALLOCATION 16 +#define FREE_ALL_PAGES (~0U) +/* times are in msecs */ +#define IS_UNDEFINED (0) +#define IS_WC (1<<1) +#define IS_UC (1<<2) +#define IS_CACHED (1<<3) +#define IS_DMA32 (1<<4) + +enum pool_type { + POOL_IS_UNDEFINED, + POOL_IS_WC = IS_WC, + POOL_IS_UC = IS_UC, + POOL_IS_CACHED = IS_CACHED, + POOL_IS_WC_DMA32 = IS_WC | IS_DMA32, + POOL_IS_UC_DMA32 = IS_UC | IS_DMA32, + POOL_IS_CACHED_DMA32 = IS_CACHED | IS_DMA32, +}; +/* + * The pool structure. There are usually six pools: + * - generic (not restricted to DMA32): + * - write combined, uncached, cached. + * - dma32 (up to 2^32 - so up 4GB): + * - write combined, uncached, cached. + * for each 'struct device'. The 'cached' is for pages that are actively used. + * The other ones can be shrunk by the shrinker API if neccessary. + * @pools: The 'struct device->dma_pools' link. + * @type: Type of the pool + * @lock: Protects the page_list from concurrnet access. Must be used with + * irqsave/irqrestore variants because pool allocator maybe called from + * delayed work. + * @page_list: Pool of all pages (both in use and free). + * @dev: The device that is associated with these pools. + * @size: Size used during DMA allocation. + * @npages_free: Count of available pages for re-use. + * @npages_in_use: Count of pages that are in use (each of them + * is marked in_use. + * @nfrees: Stats when pool is shrinking. + * @nrefills: Stats when the pool is grown. + * @gfp_flags: Flags to pass for alloc_page. + * @name: Name of the pool. + * @dev_name: Name derieved from dev - similar to how dev_info works. + * Used during shutdown as the dev_info during release is unavailable. + */ +struct dma_pool { + struct list_head pools; /* The 'struct device->dma_pools link */ + enum pool_type type; + spinlock_t lock; + struct list_head page_list; + struct device *dev; + unsigned size; + unsigned npages_free; + unsigned npages_in_use; + unsigned long nfrees; /* Stats when shrunk. */ + unsigned long nrefills; /* Stats when grown. */ + gfp_t gfp_flags; + char name[13]; /* "cached dma32" */ + char dev_name[64]; /* Constructed from dev */ +}; + +/* + * The accounting page keeping track of the allocated page along with + * the DMA address. + * @page_list: The link to the 'page_list' in 'struct dma_pool'. + * @vaddr: The virtual address of the page + * @dma: The bus address of the page. If the page is not allocated + * via the DMA API, it will be -1. + * @in_use: Set to true if in use. Should not be freed. + */ +struct dma_page { + struct list_head page_list; + void *vaddr; + dma_addr_t dma; + unsigned int in_use:1; +}; + +/* + * Limits for the pool. They are handled without locks because only place where + * they may change is in sysfs store. They won't have immediate effect anyway + * so forcing serialization to access them is pointless. + */ + +struct ttm_pool_opts { + unsigned alloc_size; + unsigned max_size; + unsigned small; +}; + +/* + * Contains the list of all of the 'struct device' and their corresponding + * DMA pools. Guarded by _mutex->lock. + * @pools: The link to 'struct ttm_pool_manager->pools' + * @dev: The 'struct device' associated with the 'pool' + * @pool: The 'struct dma_pool' associated with the 'dev' + */ +struct device_pools { + struct list_head pools; + struct device *dev; + struct dma_pool *pool; +}; + +/* + * struct ttm_pool_manager - Holds memory pools for fast allocation + * + * @lock: Lock used when adding/removing from pools + * @pools: List of 'struct device' and 'struct dma_pool' tuples. + * @options: Limits for the pool. + * @npools: Total amount of pools in existence. + * @shrinker: The structure used by [un|]register_shrinker + */ +struct ttm_pool_manager { + struct mutex lock; + struct list_head pools; + struct ttm_pool_opts options; + unsigned npools; + struct shrinker mm_shrink; + struct kobject kobj; +}; + +static struct ttm_pool_manager *_manager; + +static struct attribute ttm_page_pool_max = { + .name = "pool_max_size", + .mode = S_IRUGO | S_IWUSR +}; +static struct attribute ttm_page_pool_small = { + .name = "pool_small_allocation", + .mode = S_IRUGO | S_IWUSR +}; +static struct attribute ttm_page_pool_alloc_size = { + .name = "pool_allocation_size", + .mode = S_IRUGO | S_IWUSR +}; + +static struct attribute *ttm_pool_attrs[] = { + &ttm_page_pool_max, + &ttm_page_pool_small, + &ttm_page_pool_alloc_size, + NULL +}; + +static void ttm_pool_kobj_release(struct kobject *kobj) +{ + struct ttm_pool_manager *m = + container_of(kobj, struct ttm_pool_manager, kobj); + kfree(m); +} + +static ssize_t ttm_pool_store(struct kobject *kobj, struct attribute *attr, + const char *buffer, size_t size) +{ + struct ttm_pool_manager *m = + container_of(kobj, struct ttm_pool_manager, kobj); + int chars; + unsigned val; + chars = sscanf(buffer, "%u", &val); + if (chars == 0) + return size; + + /* Convert kb to number of pages */ + val = val / (PAGE_SIZE >> 10); + + if (attr == &ttm_page_pool_max) + m->options.max_size = val; + else if (attr == &ttm_page_pool_small) + m->options.small = val; + else if (attr == &ttm_page_pool_alloc_size) { + if (val > NUM_PAGES_TO_ALLOC*8) { + printk(KERN_ERR TTM_PFX + "Setting allocation size to %lu " + "is not allowed. Recommended size is " + "%lu\n", + NUM_PAGES_TO_ALLOC*(PAGE_SIZE >> 7), + NUM_PAGES_TO_ALLOC*(PAGE_SIZE >> 10)); + return size; + } else if (val > NUM_PAGES_TO_ALLOC) { + printk(KERN_WARNING TTM_PFX + "Setting allocation size to " + "larger than %lu is not recommended.\n", + NUM_PAGES_TO_ALLOC*(PAGE_SIZE >> 10)); + } + m->options.alloc_size = val; + } + + return size; +} + +static ssize_t ttm_pool_show(struct kobject *kobj, struct attribute *attr, + char *buffer) +{ + struct ttm_pool_manager *m = + container_of(kobj, struct ttm_pool_manager, kobj); + unsigned val = 0; + + if (attr == &ttm_page_pool_max) + val = m->options.max_size; + else if (attr == &ttm_page_pool_small) + val = m->options.small; + else if (attr == &ttm_page_pool_alloc_size) + val = m->options.alloc_size; + + val = val * (PAGE_SIZE >> 10); + + return snprintf(buffer, PAGE_SIZE, "%u\n", val); +} + +static const struct sysfs_ops ttm_pool_sysfs_ops = { + .show = &ttm_pool_show, + .store = &ttm_pool_store, +}; + +static struct kobj_type ttm_pool_kobj_type = { + .release = &ttm_pool_kobj_release, + .sysfs_ops = &ttm_pool_sysfs_ops, + .default_attrs = ttm_pool_attrs, +}; + +#ifndef CONFIG_X86 +static int set_pages_array_wb(struct page **pages, int addrinarray) +{ +#ifdef TTM_HAS_AGP + int i; + + for (i = 0; i < addrinarray; i++) + unmap_page_from_agp(pages[i]); +#endif + return 0; +} + +static int set_pages_array_wc(struct page **pages, int addrinarray) +{ +#ifdef TTM_HAS_AGP + int i; + + for (i = 0; i < addrinarray; i++) + map_page_into_agp(pages[i]); +#endif + return 0; +} + +static int set_pages_array_uc(struct page **pages, int addrinarray) +{ +#ifdef TTM_HAS_AGP + int i; + + for (i = 0; i < addrinarray; i++) + map_page_into_agp(pages[i]); +#endif + return 0; +} +#endif /* for !CONFIG_X86 */ + +static int ttm_set_pages_caching(struct dma_pool *pool, + struct page **pages, unsigned cpages) +{ + int r = 0; + /* Set page caching */ + if (pool->type & IS_UC) { + r = set_pages_array_uc(pages, cpages); + if (r) + pr_err(TTM_PFX + "%s: Failed to set %d pages to uc!\n", + pool->dev_name, cpages); + } + if (pool->type & IS_WC) { + r = set_pages_array_wc(pages, cpages); + if (r) + pr_err(TTM_PFX + "%s: Failed to set %d pages to wc!\n", + pool->dev_name, cpages); + } + return r; +} + +static void __ttm_dma_free_page(struct dma_pool *pool, struct dma_page *d_page) +{ + dma_addr_t dma = d_page->dma; + + pr_debug("%s: (%s:%d) Freeing %p (%p) (DMA:0x%lx)\n", + pool->dev_name, pool->name, current->pid, d_page->vaddr, + virt_to_page(d_page->vaddr), (unsigned long)dma); + + dma_free_coherent(pool->dev, pool->size, d_page->vaddr, dma); + + kfree(d_page); + d_page = NULL; +} +static struct dma_page *__ttm_dma_alloc_page(struct dma_pool *pool) +{ + struct dma_page *d_page; + + d_page = kmalloc(sizeof(struct dma_page), GFP_KERNEL); + if (!d_page) + return NULL; + + d_page->vaddr = dma_alloc_coherent(pool->dev, pool->size, + &d_page->dma, + pool->gfp_flags); + if (d_page->vaddr) { + pr_debug("%s: (%s:%d) Allocated %p (%p) (DMA:0x%lx)\n", + pool->dev_name, pool->name, current->pid, d_page->vaddr, + virt_to_page(d_page->vaddr), + (unsigned long)d_page->dma); + d_page->in_use = 0; + } else { + kfree(d_page); + d_page = NULL; + } + + return d_page; +} +static enum pool_type ttm_to_type(int flags, enum ttm_caching_state cstate) +{ + enum pool_type type = IS_UNDEFINED; + + if (flags & TTM_PAGE_FLAG_DMA32) + type |= IS_DMA32; + if (cstate == tt_cached) + type |= IS_CACHED; + else if (cstate == tt_uncached) + type |= IS_UC; + else + type |= IS_WC; + + return type; +} +static void ttm_pool_update_inuse(struct dma_pool *pool, unsigned count) +{ + unsigned long irq_flags; + + spin_lock_irqsave(&pool->lock, irq_flags); + pool->npages_free += count; + pool->npages_in_use -= count; + spin_unlock_irqrestore(&pool->lock, irq_flags); +} +static void ttm_pool_update_free_locked(struct dma_pool *pool, + unsigned freed_pages) +{ + pool->npages_free -= freed_pages; + pool->nfrees += freed_pages; + +} +/* set memory back to wb and free the pages. */ +static void ttm_dma_pages_put(struct dma_pool *pool, struct list_head *d_pages, + struct page *pages[], unsigned npages) +{ + struct dma_page *d_page, *tmp; + + if (npages && set_pages_array_wb(pages, npages)) + pr_err(TTM_PFX "%s: Failed to set %d pages to wb!\n", + pool->dev_name, npages); + + pr_debug("%s: (%s:%d) Freeing %d pages at once.\n", + pool->dev_name, pool->name, current->pid, npages); + + list_for_each_entry_safe(d_page, tmp, d_pages, page_list) { + list_del(&d_page->page_list); + __ttm_dma_free_page(pool, d_page); + } +} +/* + * Free pages from pool. + * + * To prevent hogging the ttm_swap process we only free NUM_PAGES_TO_ALLOC + * number of pages in one go. + * + * @pool: to free the pages from + * @nr_free: If set to true will free all pages in pool + **/ +static unsigned ttm_dma_page_pool_free(struct dma_pool *pool, unsigned nr_free) +{ + unsigned long irq_flags; + struct dma_page *dma_p, *tmp; + struct page **pages_to_free; + struct list_head d_pages; + unsigned freed_pages = 0, + npages_to_free = nr_free; + + if (NUM_PAGES_TO_ALLOC < nr_free) + npages_to_free = NUM_PAGES_TO_ALLOC; + + pages_to_free = kmalloc(npages_to_free * sizeof(struct dma_page *), + GFP_KERNEL); + + if (!pages_to_free) { + pr_err(TTM_PFX + "%s: Failed to allocate memory for pool free operation.\n", + pool->dev_name); + return 0; + } + INIT_LIST_HEAD(&d_pages); +restart: + spin_lock_irqsave(&pool->lock, irq_flags); + list_for_each_entry_safe_reverse(dma_p, tmp, &pool->page_list, + page_list) { + if (freed_pages >= npages_to_free) + break; + + if (dma_p->in_use) + continue; + + pr_debug("%s: (%s:%d) %p (%p) (DMA:0x%lx) is expunged.\n", + pool->dev_name, pool->name, current->pid, dma_p->vaddr, + virt_to_page(dma_p->vaddr), + (unsigned long)dma_p->dma); + + /* Move the dma_page from one list to another. */ + list_del(&dma_p->page_list); + list_add(&dma_p->page_list, &d_pages); + + pages_to_free[freed_pages++] = virt_to_page(dma_p->vaddr); + /* We can only remove NUM_PAGES_TO_ALLOC at a time. */ + if (freed_pages >= NUM_PAGES_TO_ALLOC) { + + ttm_pool_update_free_locked(pool, freed_pages); + /** + * Because changing page caching is costly + * we unlock the pool to prevent stalling. + */ + spin_unlock_irqrestore(&pool->lock, irq_flags); + + ttm_dma_pages_put(pool, &d_pages, pages_to_free, + freed_pages); + + INIT_LIST_HEAD(&d_pages); + + if (likely(nr_free != FREE_ALL_PAGES)) + nr_free -= freed_pages; + + if (NUM_PAGES_TO_ALLOC >= nr_free) + npages_to_free = nr_free; + else + npages_to_free = NUM_PAGES_TO_ALLOC; + + freed_pages = 0; + + /* free all so restart the processing */ + if (nr_free) + goto restart; + + /* Not allowed to fall tough or break because + * following context is inside spinlock while we are + * outside here. + */ + goto out; + + } + } + + /* remove range of pages from the pool */ + if (freed_pages) { + ttm_pool_update_free_locked(pool, freed_pages); + nr_free -= freed_pages; + } + + spin_unlock_irqrestore(&pool->lock, irq_flags); + + if (freed_pages) + ttm_dma_pages_put(pool, &d_pages, pages_to_free, freed_pages); +out: + kfree(pages_to_free); + return nr_free; +} + +static void ttm_dma_free_pool(struct device *dev, enum pool_type type) +{ + struct device_pools *p; + struct dma_pool *pool; + struct dma_page *d_page, *d_tmp; + + if (!dev) + return; + + mutex_lock(&_manager->lock); + list_for_each_entry_reverse(p, &_manager->pools, pools) { + if (p->dev != dev) + continue; + pool = p->pool; + if (pool->type != type) + continue; + pr_debug("%s: (%s:%d) of device pool freed "\ + "(has %d free, and %d in use).\n", + pool->dev_name, pool->name, current->pid, + pool->npages_free, pool->npages_in_use); + list_del(&p->pools); + kfree(p); + _manager->npools--; + break; + } + list_for_each_entry_reverse(pool, &dev->dma_pools, pools) { + unsigned long irq_save; + if (pool->type != type) + continue; + /* Takes a spinlock.. */ + ttm_dma_page_pool_free(pool, FREE_ALL_PAGES); + /* .. but afterwards we can take it too */ + spin_lock_irqsave(&pool->lock, irq_save); + list_for_each_entry_safe(d_page, d_tmp, &pool->page_list, + page_list) { + if (d_page->in_use) { + pr_err("%s: (%s:%d) %p (%p DMA:0x%lx) busy!\n", + pool->dev_name, pool->name, + current->pid, d_page->vaddr, + virt_to_page(d_page->vaddr), + (unsigned long)d_page->dma); + list_del(&d_page->page_list); + kfree(d_page); + pool->npages_in_use--; + } + } + spin_unlock_irqrestore(&pool->lock, irq_save); + WARN_ON(((pool->npages_in_use + pool->npages_free) != 0)); + /* This code path is called after _all_ references to the + * struct device has been dropped - so nobody should be + * touching it. In case somebody is trying to _add_ we are + * guarded by the mutex. */ + list_del(&pool->pools); + kfree(pool); + break; + } + mutex_unlock(&_manager->lock); +} +/* + * On free-ing of the 'struct device' this deconstructor is run. + * Albeit the pool might have already been freed earlier. + */ +static void ttm_dma_pool_release(struct device *dev, void *res) +{ + struct dma_pool *pool = *(struct dma_pool **)res; + + if (pool) + ttm_dma_free_pool(dev, pool->type); +} + +static int ttm_dma_pool_match(struct device *dev, void *res, void *match_data) +{ + return *(struct dma_pool **)res == match_data; +} + +static struct dma_pool *ttm_dma_pool_init(struct device *dev, gfp_t flags, + enum pool_type type) +{ + char *n[] = {"wc", "uc", "cached", " dma32", "unknown",}; + enum pool_type t[] = {IS_WC, IS_UC, IS_CACHED, IS_DMA32, IS_UNDEFINED}; + struct device_pools *sec_pool = NULL; + struct dma_pool *pool = NULL, **ptr; + unsigned i; + int ret = -ENODEV; + char *p; + + if (!dev) + return NULL; + + ptr = devres_alloc(ttm_dma_pool_release, sizeof(*ptr), GFP_KERNEL); + if (!ptr) + return NULL; + + ret = -ENOMEM; + + pool = kmalloc_node(sizeof(struct dma_pool), GFP_KERNEL, + dev_to_node(dev)); + if (!pool) + goto err_mem; + + sec_pool = kmalloc_node(sizeof(struct device_pools), GFP_KERNEL, + dev_to_node(dev)); + if (!sec_pool) + goto err_mem; + + INIT_LIST_HEAD(&sec_pool->pools); + sec_pool->dev = dev; + sec_pool->pool = pool; + + INIT_LIST_HEAD(&pool->page_list); + INIT_LIST_HEAD(&pool->pools); + spin_lock_init(&pool->lock); + pool->dev = dev; + pool->npages_free = pool->npages_in_use = 0; + pool->nfrees = 0; + pool->gfp_flags = flags; + pool->size = PAGE_SIZE; + pool->type = type; + pool->nrefills = 0; + p = pool->name; + for (i = 0; i < 5; i++) { + if (type & t[i]) { + p += snprintf(p, sizeof(pool->name) - (p - pool->name), + "%s", n[i]); + } + } + *p = 0; + /* We copy the name for pr_ calls b/c when dma_pool_destroy is called + * - the kobj->name has already been deallocated.*/ + snprintf(pool->dev_name, sizeof(pool->dev_name), "%s %s", + dev_driver_string(dev), dev_name(dev)); + mutex_lock(&_manager->lock); + /* You can get the dma_pool from either the global: */ + list_add(&sec_pool->pools, &_manager->pools); + _manager->npools++; + /* or from 'struct device': */ + list_add(&pool->pools, &dev->dma_pools); + mutex_unlock(&_manager->lock); + + *ptr = pool; + devres_add(dev, ptr); + + return pool; +err_mem: + devres_free(ptr); + kfree(sec_pool); + kfree(pool); + return ERR_PTR(ret); +} +static struct dma_pool *ttm_dma_find_pool(struct device *dev, + enum pool_type type) +{ + struct dma_pool *pool, *tmp, *found = NULL; + + if (type == IS_UNDEFINED) + return found; + /* NB: We iterate on the 'struct dev' which has no spinlock, but + * it does have a kref which we have taken. */ + list_for_each_entry_safe(pool, tmp, &dev->dma_pools, pools) { + if (pool->type != type) + continue; + found = pool; + } + if (found) + pr_debug("%s: (%s:%d) Found. It has %d free pages (%d in use)\n", + found->dev_name, found->name, current->pid, + found->npages_free, found->npages_in_use); + return found; +} + +/* + * Free pages the pages that failed to change the caching state. If there is + * any pages that have changed their caching state already put them to the + * pool. + */ +static void ttm_dma_handle_caching_state_failure(struct dma_pool *pool, + struct page **failed_pages, + unsigned cpages) +{ + unsigned long irq_flags; + unsigned i; + struct dma_page *dma_p, *t; + struct list_head d_pages; + + /* Failed pages have to be freed */ + i = cpages; + + INIT_LIST_HEAD(&d_pages); + + /* To make it faster we only take the spinlock on list + * removal, and later on do the free-ing at our leisure. */ + spin_lock_irqsave(&pool->lock, irq_flags); + list_for_each_entry_safe(dma_p, t, &pool->page_list, page_list) { + struct page *p = failed_pages[i]; + if (virt_to_page(dma_p->vaddr) != p) { + pr_debug("%s: (%s:%d) Skipping %p (%p) (DMA:0x%lx)\n", + pool->dev_name, pool->name, current->pid, + dma_p->vaddr, + virt_to_page(dma_p->vaddr), + (unsigned long)dma_p->dma); + continue; + } + list_del(&dma_p->page_list); + list_add(&dma_p->page_list, &d_pages); + list_del(&failed_pages[i]->lru); + if (--i == 0) + break; + } + ttm_pool_update_free_locked(pool, (cpages - i)); + spin_unlock_irqrestore(&pool->lock, irq_flags); + + ttm_dma_pages_put(pool, &d_pages, NULL/* Don't try to set WB on them */, + cpages - i); +} + +static int ttm_dma_pool_alloc_new_pages(struct dma_pool *pool, + struct list_head *pages, + dma_addr_t *dma_address, + unsigned dma_offset, unsigned count) +{ + struct page **caching_array; + struct dma_page *dma_p; + struct page *p; + int r = 0; + unsigned i, cpages; + unsigned long irq_flags; + unsigned max_cpages = min(count, + (unsigned)(PAGE_SIZE/sizeof(struct page *))); + + /* allocate array for page caching change */ + caching_array = kmalloc(max_cpages*sizeof(struct page *), GFP_KERNEL); + + if (!caching_array) { + pr_err(TTM_PFX + "%s: Unable to allocate table for new pages.", + pool->dev_name); + return -ENOMEM; + } + pr_debug("%s: (%s:%d) Getting %d pages @ %d idx\n", + pool->dev_name, pool->name, current->pid, + count, dma_offset); + for (i = 0, cpages = 0; i < count; ++i) { + dma_p = __ttm_dma_alloc_page(pool); + if (!dma_p) { + pr_err(TTM_PFX "%s: Unable to get page %u.\n", + pool->dev_name, i); + + /* store already allocated pages in the pool after + * setting the caching state */ + if (cpages) { + r = ttm_set_pages_caching(pool, caching_array, + cpages); + if (r) + ttm_dma_handle_caching_state_failure( + pool, caching_array, cpages); + } + r = -ENOMEM; + goto out; + } + p = virt_to_page(dma_p->vaddr); + /* Take ownership of that page. */ + dma_p->in_use = true; + /* And now add it in without having to worry about it being + * immediately picked up by another thread. */ + spin_lock_irqsave(&pool->lock, irq_flags); + list_add(&dma_p->page_list, &pool->page_list); + pool->npages_in_use++; + spin_unlock_irqrestore(&pool->lock, irq_flags); +#ifdef CONFIG_HIGHMEM + /* gfp flags of highmem page should never be dma32 so we + * we should be fine in such case + */ + if (!PageHighMem(p)) +#endif + { + caching_array[cpages++] = p; + if (cpages == max_cpages) { + + r = ttm_set_pages_caching(pool, caching_array, + cpages); + if (r) { + ttm_dma_handle_caching_state_failure( + pool, caching_array, cpages); + goto out; + } + cpages = 0; + } + } + /* Note: We do _not_ add the pages to the cached pool here. */ + list_add_tail(&p->lru, pages); + dma_address[dma_offset + i] = dma_p->dma; + } + + if (cpages) { + r = ttm_set_pages_caching(pool, caching_array, cpages); + if (r) + ttm_dma_handle_caching_state_failure(pool, + caching_array, cpages); + } +out: + kfree(caching_array); + return r; +} +/* + * Recycle (or delete) the 'pages' that are on the 'pool'. + * @pool: The pool that the pages are associated with. + * @pages: The list of pages we are done with. + * @page_count: Count of how many pages (or zero if all). + * @erase: Instead of recycling - just free them. + */ +static int ttm_dma_put_pages_in_pool(struct dma_pool *pool, + struct list_head *pages, + unsigned page_count, + bool erase) +{ + unsigned long uninitialized_var(irq_flags); + struct list_head uninitialized_var(d_pages); + struct page **uninitialized_var(pages_to_free); + unsigned uninitialized_var(freed_pages); + struct dma_page *d_page, *d_tmp; + struct page *p, *tmp; + bool found = false; + unsigned count = 0; + + if (list_empty(pages)) + return 0; + + if (page_count == 0) { + list_for_each_entry_safe(p, tmp, pages, lru) + ++page_count; + } + pr_debug("%s: (%s:%d) %s %d pages\n", + pool->dev_name, pool->name, current->pid, + erase ? "Destroying" : "Recycling", page_count); + + if (erase) { + INIT_LIST_HEAD(&d_pages); + pages_to_free = kmalloc(page_count * sizeof(struct dma_page *), + GFP_KERNEL); + if (!pages_to_free) { + dev_err(pool->dev, TTM_PFX + "Failed to allocate memory for pool free operation.\n"); + return 0; + } + spin_lock_irqsave(&pool->lock, irq_flags); + freed_pages = 0; + } + list_for_each_entry_safe_reverse(p, tmp, pages, lru) { + found = false; + /* We only hold the lock when erasing. Otherwise we just + * set the d_page->in_use bit. */ + list_for_each_entry_safe(d_page, d_tmp, &pool->page_list, + page_list) { + if (p != virt_to_page(d_page->vaddr)) + continue; + found = true; + break; + } + if (!found) + break; /* We could continue, but why bother..*/ + + WARN_ON(!d_page->in_use); + d_page->in_use = false; + count++; + list_del_init(&p->lru); + if (erase) { + list_del(&d_page->page_list); + list_add(&d_page->page_list, &d_pages); + pages_to_free[freed_pages++] = + virt_to_page(d_page->vaddr); + } + /* Do not advance past what we were asked to delete. */ + if (count == page_count) + break; + } + if (erase) { + spin_unlock_irqrestore(&pool->lock, irq_flags); + ttm_dma_pages_put(pool, &d_pages, pages_to_free /* to set WB */, + freed_pages); + kfree(pages_to_free); + } + pr_debug("%s: (%s:%d) Put %d/%d pages in the pool.\n", + pool->dev_name, pool->name, current->pid, count, page_count); + return count; +} +/* + * @return count of pages still required to fulfill the request. +*/ +static int ttm_dma_page_pool_fill_locked(struct dma_pool *pool, + struct list_head *pages, + dma_addr_t *dma_address, + unsigned count, + unsigned long *irq_flags) +{ + int r = count; + + if (count < _manager->options.small && + count > pool->npages_free) { + /* Do NOT try to get more than count. This is b/c + * dma_address[count++] will fail. */ + unsigned alloc_size = min(count, _manager->options.alloc_size); + + spin_unlock_irqrestore(&pool->lock, *irq_flags); + /* Returns how many more are neccessary to fulfill the + * request. */ + r = ttm_dma_pool_alloc_new_pages(pool, pages, dma_address, + 0 /* no offset */, alloc_size); + spin_lock_irqsave(&pool->lock, *irq_flags); + + if (!r) { + ++pool->nrefills; + } else { + pr_err(TTM_PFX "%s: Failed to fill %s pool (r:%d)!\n", + pool->dev_name, pool->name, r); + spin_unlock_irqrestore(&pool->lock, *irq_flags); + count = ttm_dma_put_pages_in_pool(pool, pages, + 0 /* no WB */, + false /* recycle */); + spin_lock_irqsave(&pool->lock, *irq_flags); + pool->npages_free += count; + pool->npages_in_use -= count; + } + } + return r; + +} + +/* + * @return count of pages still required to fulfill the request. + */ +static int ttm_dma_pool_get_pages(struct dma_pool *pool, + struct list_head *pages, + dma_addr_t *dma_address, unsigned count) +{ + unsigned long irq_flags; + int r = 0; + unsigned i; + struct page *p; + struct dma_page *dma_p; + + spin_lock_irqsave(&pool->lock, irq_flags); + r = ttm_dma_page_pool_fill_locked(pool, pages, dma_address, + count, &irq_flags); + pr_debug("%s: (%s:%d) Asked for %d, got %d %s.\n", + pool->dev_name, pool->name, current->pid, count, r, + (r < 0) ? "err:" : "pages"); + + if (r < 0) + goto out; + + if (r > count) { + /* This should never happen. */ + WARN_ON(1); + /* But just in case, limit it to what we requested. */ + r = count; + } + /* How many "left" we need to pick off the free list */ + count = r; + /* And in case we have gotten all the pages we need - we exit. */ + if (count == 0) + goto out; + /* NB: Don't set r=0 at the start of the loop, otherwise you will + * overwrite the previously dma_address[x] fields. */ + r = count - r; + i = 0; + pr_debug("%s: (%s:%d) Scavenging for %d pages - inserting @ %d idx " \ + "(have %d pages free)\n", + pool->dev_name, pool->name, current->pid, count, r, + pool->npages_free); + /* Copy as many as we need from the pool to fulfill the request.*/ + list_for_each_entry(dma_p, &pool->page_list, page_list) { + if (dma_p->in_use) + continue; + p = virt_to_page(dma_p->vaddr); + list_add_tail(&p->lru, pages); + dma_address[r++] = dma_p->dma; + pr_debug("%s: (%s:%d) Salvaged %p (%p) (DMA:0x%lx)\n", + pool->dev_name, pool->name, current->pid, dma_p->vaddr, + virt_to_page(dma_p->vaddr), + (unsigned long)dma_p->dma); + + /* Take ownership of that page. */ + dma_p->in_use = true; + if (++i == count) + break; + } + pool->npages_in_use += i; + pool->npages_free -= i; + count -= i; + pr_debug("%s: (%s:%d) Have taken %d pages, need %d more.\n", + pool->dev_name, pool->name, current->pid, r, count); +out: + spin_unlock_irqrestore(&pool->lock, irq_flags); + return count; +} +/* + * On success pages list will hold count number of correctly + * cached pages. On failure will hold the negative return value (-ENOMEM, etc). + */ +static int ttm_dma_get_pages(struct list_head *pages, int flags, + enum ttm_caching_state cstate, unsigned count, + dma_addr_t *dma_address, struct device *dev) + +{ + int r = -ENOMEM; + struct dma_pool *pool; + gfp_t gfp_flags; + enum pool_type type; + unsigned pages_got = count; + + type = ttm_to_type(flags, cstate); + + if (flags & TTM_PAGE_FLAG_DMA32) + gfp_flags = GFP_USER | GFP_DMA32; + else + gfp_flags = GFP_HIGHUSER; + + if (flags & TTM_PAGE_FLAG_ZERO_ALLOC) + gfp_flags |= __GFP_ZERO; + + pool = ttm_dma_find_pool(dev, type); + if (!pool) { + pool = ttm_dma_pool_init(dev, gfp_flags, type); + if (IS_ERR_OR_NULL(pool)) + return -ENOMEM; + } + /* Take pages out of a pool (if applicable) */ + r = ttm_dma_pool_get_pages(pool, pages, dma_address, count); + /* clear the pages coming from the pool if requested */ + if (flags & TTM_PAGE_FLAG_ZERO_ALLOC) { + struct page *p; + list_for_each_entry(p, pages, lru) { + clear_page(page_address(p)); + } + } + pages_got = count - r; + /* If pool didn't have enough pages allocate new one. */ + if (r > 0) { + unsigned pages_need = r; + r = ttm_dma_pool_alloc_new_pages(pool, pages, dma_address, + pages_got /* offset in dma_address*/, + pages_need); + if (r >= 0) + pages_got += pages_need - r; + + pr_debug("%s: (%s:%d) have %d pages, %s %d.\n", + pool->dev_name, + pool->name, current->pid, pages_got, + pages_got == count ? + "got them all" : "need more - (err):", r); + if (r) { + /* If there is any pages in the list put them back to + * the pool. */ + pr_err(TTM_PFX + "%s: Failed to allocate extra pages " + "for large request.", + pool->dev_name); + count = ttm_dma_put_pages_in_pool(pool, pages, + 0 /* no WB */, + false /* recycle */); + INIT_LIST_HEAD(pages); + ttm_pool_update_inuse(pool, count); + return count; + } + } + return r; +} + +/* Put all pages in pages list to correct pool to wait for reuse */ +static void ttm_dma_put_pages(struct list_head *pages, unsigned page_count, + int flags, enum ttm_caching_state cstate, + dma_addr_t *dma_address, struct device *dev) +{ + struct dma_pool *pool; + enum pool_type type; + bool is_cached = false; + unsigned count, i; + unsigned long irq_flags; + + if (list_empty(pages)) + return; + + type = ttm_to_type(flags, cstate); + pool = ttm_dma_find_pool(dev, type); + if (!pool) { + WARN_ON(!pool); + return; + } + is_cached = (ttm_dma_find_pool(pool->dev, + ttm_to_type(flags, tt_cached)) == pool); + + dev_dbg(pool->dev, "(%s:%d) %s %d pages.\n", pool->name, current->pid, + (is_cached) ? "Destroying" : "Recycling", page_count); + + count = ttm_dma_put_pages_in_pool(pool, pages, page_count, is_cached); + + for (i = 0; i < count; i++) + dma_address[i] = 0; + + spin_lock_irqsave(&pool->lock, irq_flags); + pool->npages_in_use -= count; + if (!is_cached) + pool->npages_free += count; + spin_unlock_irqrestore(&pool->lock, irq_flags); + + page_count -= count; + WARN(page_count != 0, + "Only freed %d page(s) in %s. Could not free %d rest!\n", + count, pool->name, page_count); + + if (pool->npages_free > _manager->options.max_size) { + page_count = pool->npages_free - _manager->options.max_size; + if (page_count < NUM_PAGES_TO_ALLOC) + page_count = NUM_PAGES_TO_ALLOC; + } + if (page_count) + ttm_dma_page_pool_free(pool, page_count); +} + +/* Get good estimation how many pages are free in pools */ +static int ttm_pool_get_num_unused_pages(void) +{ + struct device_pools *p; + unsigned total = 0; + + mutex_lock(&_manager->lock); + list_for_each_entry(p, &_manager->pools, pools) + total += p->pool->npages_free; + mutex_unlock(&_manager->lock); + return total; +} + +/** + * Callback for mm to request pool to reduce number of page held. + */ +static int ttm_pool_mm_shrink(struct shrinker *shrink, + struct shrink_control *sc) +{ + static atomic_t start_pool = ATOMIC_INIT(0); + unsigned idx = 0; + unsigned pool_offset = atomic_add_return(1, &start_pool); + unsigned shrink_pages = sc->nr_to_scan; + struct device_pools *p; + + mutex_lock(&_manager->lock); + pool_offset = pool_offset % _manager->npools; + + list_for_each_entry(p, &_manager->pools, pools) { + unsigned nr_free; + + if (!p->dev) + continue; + if (shrink_pages == 0) + break; + /* Do it in round-robin fashion. */ + if (++idx < pool_offset) + continue; + nr_free = shrink_pages; + shrink_pages = ttm_dma_page_pool_free(p->pool, nr_free); + pr_debug("%s: (%s:%d) Asked to shrink %d, have %d more to go\n", + p->pool->dev_name, p->pool->name, current->pid, nr_free, + shrink_pages); + } + mutex_unlock(&_manager->lock); + /* return estimated number of unused pages in pool */ + return ttm_pool_get_num_unused_pages(); +} + +static void ttm_pool_mm_shrink_init(struct ttm_pool_manager *manager) +{ + manager->mm_shrink.shrink = &ttm_pool_mm_shrink; + manager->mm_shrink.seeks = 1; + register_shrinker(&manager->mm_shrink); +} +static void ttm_pool_mm_shrink_fini(struct ttm_pool_manager *manager) +{ + unregister_shrinker(&manager->mm_shrink); +} + +static int ttm_dma_page_alloc_init(struct ttm_mem_global *glob, + unsigned max_pages) +{ + int ret = -ENOMEM; + + WARN_ON(_manager); + + printk(KERN_INFO TTM_PFX "Initializing DMA pool allocator.\n"); + + _manager = kzalloc(sizeof(*_manager), GFP_KERNEL); + if (!_manager) + goto err_manager; + + mutex_init(&_manager->lock); + INIT_LIST_HEAD(&_manager->pools); + + _manager->options.max_size = max_pages; + _manager->options.small = SMALL_ALLOCATION; + _manager->options.alloc_size = NUM_PAGES_TO_ALLOC; + + /* This takes care of auto-freeing the _manager */ + ret = kobject_init_and_add(&_manager->kobj, &ttm_pool_kobj_type, + &glob->kobj, "pool"); + if (unlikely(ret != 0)) { + kobject_put(&_manager->kobj); + goto err; + } + ttm_pool_mm_shrink_init(_manager); + + return 0; +err_manager: + kfree(_manager); + _manager = NULL; +err: + return ret; +} +static void ttm_dma_page_alloc_fini(void) +{ + struct device_pools *p, *t; + + printk(KERN_INFO TTM_PFX "Finalizing DMA pool allocator.\n"); + + ttm_pool_mm_shrink_fini(_manager); + + list_for_each_entry_safe_reverse(p, t, &_manager->pools, pools) { + dev_dbg(p->dev, "(%s:%d) Freeing.\n", p->pool->name, + current->pid); + WARN_ON(devres_destroy(p->dev, ttm_dma_pool_release, + ttm_dma_pool_match, p->pool)); + ttm_dma_free_pool(p->dev, p->pool->type); + } + kobject_put(&_manager->kobj); + _manager = NULL; +} + +static int ttm_dma_page_alloc_debugfs(struct seq_file *m, void *data) +{ + struct device_pools *p; + struct dma_pool *pool = NULL; + char *h[] = {"pool", "refills", "pages freed", "inuse", "available", + "name", "virt", "busaddr"}; + + if (!_manager) { + seq_printf(m, "No pool allocator running.\n"); + return 0; + } + seq_printf(m, "%13s %12s %13s %8s %8s %8s\n", + h[0], h[1], h[2], h[3], h[4], h[5]); + mutex_lock(&_manager->lock); + list_for_each_entry(p, &_manager->pools, pools) { + struct device *dev = p->dev; + if (!dev) + continue; + pool = p->pool; + seq_printf(m, "%13s %12ld %13ld %8d %8d %8s\n", + pool->name, pool->nrefills, + pool->nfrees, pool->npages_in_use, + pool->npages_free, + pool->dev_name); + } +#ifdef DEBUG + seq_printf(m, "%13s %8s %12s %12s %8s\n", + h[0], h[3], h[6], h[7], h[5]); + list_for_each_entry(p, &_manager->pools, pools) { + struct dma_page *d_page; + struct device *dev = p->dev; + if (!dev) + continue; + pool = p->pool; + + if ((pool->npages_free + pool->npages_in_use) == 0) + continue; + + spin_lock(&pool->lock); + list_for_each_entry(d_page, &pool->page_list, page_list) { + seq_printf(m, + "%13s %8s %12lx %12lx %8s\n", + pool->name, d_page->in_use ? "Busy" : "Free", + (unsigned long)d_page->vaddr, + (unsigned long)d_page->dma, + pool->dev_name); + } + spin_unlock(&pool->lock); + } +#endif + mutex_unlock(&_manager->lock); + return 0; +} + +struct ttm_page_alloc_func ttm_page_alloc_dma = { + .get_pages = ttm_dma_get_pages, + .put_pages = ttm_dma_put_pages, + .alloc_init = ttm_dma_page_alloc_init, + .alloc_fini = ttm_dma_page_alloc_fini, + .debugfs = ttm_dma_page_alloc_debugfs, +}; diff --git a/include/drm/ttm/ttm_page_alloc.h b/include/drm/ttm/ttm_page_alloc.h index 8fc92f2..192c5f8 100644 --- a/include/drm/ttm/ttm_page_alloc.h +++ b/include/drm/ttm/ttm_page_alloc.h @@ -29,6 +29,11 @@ #include "ttm_bo_driver.h" #include "ttm_memory.h" +#ifdef CONFIG_SWIOTLB +#include +#include +#endif + struct ttm_page_alloc_func { /** * struct ttm_page_alloc_func member get_pages @@ -38,7 +43,8 @@ struct ttm_page_alloc_func { * @flags: ttm flags for page allocation. * @cstate: ttm caching state for the page. * @count: number of pages to allocate. - * @dma_address: The DMA (bus) address of pages (by default zero). + * @dma_address: The DMA (bus) address of pages (if + * TTM DMA pool is used - otherwise it is zero). * @dev: The device that needs this. */ int (*get_pages) (struct list_head *pages, @@ -57,7 +63,8 @@ struct ttm_page_alloc_func { * unknown count. * @flags: ttm flags for page allocation. * @cstate: ttm caching state. - * @dma_address: The DMA (bus) address of pages (by default zero). + * @dma_address: The DMA (bus) address of pages (if + * TTM DMA pool is used - otherwise it is zero). * @dev: The device that needs this. */ void (*put_pages)(struct list_head *pages, @@ -93,6 +100,21 @@ extern struct ttm_page_alloc_func *ttm_page_alloc; /* Defined in ttm_page_alloc.c */ extern struct ttm_page_alloc_func ttm_page_alloc_default; +#ifdef CONFIG_SWIOTLB +/* Defined in ttm_page_alloc_dma.c */ +extern struct ttm_page_alloc_func ttm_page_alloc_dma; + +static inline bool ttm_page_alloc_need_dma(void) +{ + if (swiotlb_enabled()) { + ttm_page_alloc = &ttm_page_alloc_dma; + return true; + } + return false; +} +#else +static inline bool ttm_page_alloc_need_dma(void) { return false; } +#endif /** * Get count number of pages from pool to pages list. * @@ -100,7 +122,8 @@ extern struct ttm_page_alloc_func ttm_page_alloc_default; * @flags: ttm flags for page allocation. * @cstate: ttm caching state for the page. * @count: number of pages to allocate. - * @dma_address: The DMA (bus) address of pages - (by default zero). + * @dma_address: The DMA (bus) address of pages (if TTM DMA pool is used - + * otherwise the value is zero). * @dev: The device that needs this. */ int ttm_get_pages(struct list_head *pages, @@ -117,7 +140,8 @@ int ttm_get_pages(struct list_head *pages, * count. * @flags: ttm flags for page allocation. * @cstate: ttm caching state. - * @dma_address: The DMA (bus) address of pages (by default zero). + * @dma_address: The DMA (bus) address of pages (if TTM DMA pool is used - + * otherwise the value is zero). * @dev: The device that needs this. */ void ttm_put_pages(struct list_head *pages, -- 1.7.4.1 _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel From xen-devel-bounces@lists.xensource.com Tue Sep 13 07:19:50 2011 Return-path: Envelope-to: www-data@lists.xensource.com Delivery-date: Tue, 13 Sep 2011 07:19:50 -0700 Received: from localhost ([127.0.0.1] helo=lists.colo.xensource.com) by lists.xensource.com with esmtp (Exim 4.43) id 1R3Tq2-0001L4-CL; Tue, 13 Sep 2011 07:19:50 -0700 Received: from mail216.messagelabs.com ([85.158.143.99]) by lists.xensource.com with esmtp (Exim 4.43) id 1R3Tkm-0007nk-9P for xen-devel@lists.xensource.com; Tue, 13 Sep 2011 07:14:24 -0700 X-Env-Sender: konrad.wilk@oracle.com X-Msg-Ref: server-9.tower-216.messagelabs.com!1315923259!18120225!1 X-Originating-IP: [141.146.126.227] X-StarScan-Version: 6.3.6; banners=-,-,- X-VirusChecked: Checked Received: (qmail 19162 invoked from network); 13 Sep 2011 14:14:21 -0000 Received: from acsinet15.oracle.com (HELO acsinet15.oracle.com) (141.146.126.227) by server-9.tower-216.messagelabs.com with DHE-RSA-AES256-SHA encrypted SMTP; 13 Sep 2011 14:14:21 -0000 Received: from acsinet21.oracle.com (acsinet21.oracle.com [141.146.126.237]) by acsinet15.oracle.com (Switch-3.4.4/Switch-3.4.4) with ESMTP id p8DED4q7023620 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Tue, 13 Sep 2011 14:13:06 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 p8DED3br015849 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 13 Sep 2011 14:13:04 GMT Received: from abhmt112.oracle.com (abhmt112.oracle.com [141.146.116.64]) by acsmt358.oracle.com (8.12.11.20060308/8.12.11) with ESMTP id p8DECvEn017393; Tue, 13 Sep 2011 09:12:58 -0500 Received: from oracle.com (/209.6.55.207) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Tue, 13 Sep 2011 07:12:57 -0700 From: Konrad Rzeszutek Wilk To: thellstrom@vmware.com, linux-kernel@vger.kernel.org, xen-devel@lists.xensource.com, dri-devel@lists.freedesktop.org, thomas@shipmail.org Date: Tue, 13 Sep 2011 10:12:44 -0400 Message-Id: <1315923170-25568-2-git-send-email-konrad.wilk@oracle.com> X-Mailer: git-send-email 1.7.4.1 In-Reply-To: <1315923170-25568-1-git-send-email-konrad.wilk@oracle.com> References: <1315923170-25568-1-git-send-email-konrad.wilk@oracle.com> X-Source-IP: acsinet21.oracle.com [141.146.126.237] X-Auth-Type: Internal IP X-CT-RefId: str=0001.0A090201.4E6F64F3.0091:SCFMA922111,ss=1,re=-4.000,fgs=0 Cc: Konrad Rzeszutek Wilk , airlied@linux.ie, Pekka Paalanen , bskeggs@redhat.com, alexdeucher@gmail.com, airlied@redhat.com, j.glisse@redhat.com Subject: [Xen-devel] [PATCH 1/7] ttm/radeon/nouveau: Check the DMA address from TTM against known value. X-BeenThere: xen-devel@lists.xensource.com X-Mailman-Version: 2.1.5 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xensource.com Errors-To: xen-devel-bounces@lists.xensource.com . instead of checking against the DMA_ERROR_CODE value which is per-platform specific. The zero value is a known invalid value that the TTM layer sets on the dma_address array if it is not used (ttm_tt_alloc_page_directory calls drm_calloc_large which creates a page with GFP_ZERO). We can't use pci_dma_mapping_error as that is IOMMU specific (some check for a specific physical address, some for ranges, some just do a check against zero). Also update the comments in the header about the true state of that parameter. Signed-off-by: Konrad Rzeszutek Wilk --- drivers/gpu/drm/nouveau/nouveau_sgdma.c | 3 +-- drivers/gpu/drm/radeon/radeon_gart.c | 4 +--- include/drm/ttm/ttm_page_alloc.h | 4 ++-- 3 files changed, 4 insertions(+), 7 deletions(-) diff --git a/drivers/gpu/drm/nouveau/nouveau_sgdma.c b/drivers/gpu/drm/nouveau/nouveau_sgdma.c index 82fad91..9b570c3 100644 --- a/drivers/gpu/drm/nouveau/nouveau_sgdma.c +++ b/drivers/gpu/drm/nouveau/nouveau_sgdma.c @@ -42,8 +42,7 @@ nouveau_sgdma_populate(struct ttm_backend *be, unsigned long num_pages, nvbe->nr_pages = 0; while (num_pages--) { - /* this code path isn't called and is incorrect anyways */ - if (0) { /*dma_addrs[nvbe->nr_pages] != DMA_ERROR_CODE)*/ + if (dma_addrs[nvbe->nr_pages] != 0) { nvbe->pages[nvbe->nr_pages] = dma_addrs[nvbe->nr_pages]; nvbe->ttm_alloced[nvbe->nr_pages] = true; diff --git a/drivers/gpu/drm/radeon/radeon_gart.c b/drivers/gpu/drm/radeon/radeon_gart.c index a533f52..068ba09 100644 --- a/drivers/gpu/drm/radeon/radeon_gart.c +++ b/drivers/gpu/drm/radeon/radeon_gart.c @@ -181,9 +181,7 @@ int radeon_gart_bind(struct radeon_device *rdev, unsigned offset, p = t / (PAGE_SIZE / RADEON_GPU_PAGE_SIZE); for (i = 0; i < pages; i++, p++) { - /* we reverted the patch using dma_addr in TTM for now but this - * code stops building on alpha so just comment it out for now */ - if (0) { /*dma_addr[i] != DMA_ERROR_CODE) */ + if (dma_addr[i] != 0) { rdev->gart.ttm_alloced[p] = true; rdev->gart.pages_addr[p] = dma_addr[i]; } else { diff --git a/include/drm/ttm/ttm_page_alloc.h b/include/drm/ttm/ttm_page_alloc.h index 8062890..0017b17 100644 --- a/include/drm/ttm/ttm_page_alloc.h +++ b/include/drm/ttm/ttm_page_alloc.h @@ -36,7 +36,7 @@ * @flags: ttm flags for page allocation. * @cstate: ttm caching state for the page. * @count: number of pages to allocate. - * @dma_address: The DMA (bus) address of pages (if TTM_PAGE_FLAG_DMA32 set). + * @dma_address: The DMA (bus) address of pages - (by default zero). */ int ttm_get_pages(struct list_head *pages, int flags, @@ -51,7 +51,7 @@ int ttm_get_pages(struct list_head *pages, * count. * @flags: ttm flags for page allocation. * @cstate: ttm caching state. - * @dma_address: The DMA (bus) address of pages (if TTM_PAGE_FLAG_DMA32 set). + * @dma_address: The DMA (bus) address of pages (by default zero). */ void ttm_put_pages(struct list_head *pages, unsigned page_count, -- 1.7.4.1 _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel From xen-devel-bounces@lists.xensource.com Tue Sep 13 07:20:45 2011 Return-path: Envelope-to: www-data@lists.xensource.com Delivery-date: Tue, 13 Sep 2011 07:20:45 -0700 Received: from localhost ([127.0.0.1] helo=lists.colo.xensource.com) by lists.xensource.com with esmtp (Exim 4.43) id 1R3Tqv-0001hv-0k; Tue, 13 Sep 2011 07:20:45 -0700 Received: from mail174.messagelabs.com ([85.158.138.51]) by lists.xensource.com with esmtp (Exim 4.43) id 1R3TlF-0007wj-Gi for xen-devel@lists.xensource.com; Tue, 13 Sep 2011 07:14:53 -0700 X-Env-Sender: konrad.wilk@oracle.com X-Msg-Ref: server-6.tower-174.messagelabs.com!1315923207!29129370!1 X-Originating-IP: [148.87.113.117] X-StarScan-Version: 6.3.6; banners=-,-,- X-VirusChecked: Checked Received: (qmail 5168 invoked from network); 13 Sep 2011 14:14:50 -0000 Received: from rcsinet15.oracle.com (HELO rcsinet15.oracle.com) (148.87.113.117) by server-6.tower-174.messagelabs.com with DHE-RSA-AES256-SHA encrypted SMTP; 13 Sep 2011 14:14:50 -0000 Received: from acsinet22.oracle.com (acsinet22.oracle.com [141.146.126.238]) by rcsinet15.oracle.com (Switch-3.4.4/Switch-3.4.4) with ESMTP id p8DED4db023820 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Tue, 13 Sep 2011 14:13:06 GMT Received: from acsmt358.oracle.com (acsmt358.oracle.com [141.146.40.158]) by acsinet22.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id p8DED3Rn021106 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 13 Sep 2011 14:13:03 GMT Received: from abhmt112.oracle.com (abhmt112.oracle.com [141.146.116.64]) by acsmt358.oracle.com (8.12.11.20060308/8.12.11) with ESMTP id p8DECu1O017383; Tue, 13 Sep 2011 09:12:57 -0500 Received: from oracle.com (/209.6.55.207) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Tue, 13 Sep 2011 07:12:56 -0700 From: Konrad Rzeszutek Wilk To: thellstrom@vmware.com, linux-kernel@vger.kernel.org, xen-devel@lists.xensource.com, dri-devel@lists.freedesktop.org, thomas@shipmail.org Date: Tue, 13 Sep 2011 10:12:43 -0400 Message-Id: <1315923170-25568-1-git-send-email-konrad.wilk@oracle.com> X-Mailer: git-send-email 1.7.4.1 X-Source-IP: acsinet22.oracle.com [141.146.126.238] X-Auth-Type: Internal IP X-CT-RefId: str=0001.0A090202.4E6F64F3.0045:SCFMA922111,ss=1,re=-4.000,fgs=0 Cc: airlied@linux.ie, Pekka Paalanen , bskeggs@redhat.com, alexdeucher@gmail.com, airlied@redhat.com, j.glisse@redhat.com Subject: [Xen-devel] [PATCH] TTM DMA v1.8 X-BeenThere: xen-devel@lists.xensource.com X-Mailman-Version: 2.1.5 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xensource.com Errors-To: xen-devel-bounces@lists.xensource.com Since v1.7: [https://lkml.org/lkml/2011/8/30/460] - Fixed checking the DMA address in radeon/nouveau code. Since v1: [http://lwn.net/Articles/456246/] - Ran it through the gauntlet of SubmitChecklist and fixed issues - Made radeon/nouveau driver set coherent_dma (which is required for dmapool) [.. and this is what I said in v1 post]: Way back in January this patchset: http://lists.freedesktop.org/archives/dri-devel/2011-January/006905.html was merged in, but pieces of it had to be reverted b/c they did not work properly under PowerPC, ARM, and when swapping out pages to disk. After a bit of discussion on the mailing list http://marc.info/?i=4D769726.2030307@shipmail.org I started working on it, but got waylaid by other things .. and finally I am able to post the RFC patches. There was a lot of discussion about it and I am not sure if I captured everybody's thoughts - if I did not - that is _not_ intentional - it has just been quite some time.. Anyhow .. the patches explore what the "lib/dmapool.c" does - which is to have a DMA pool that the device has associated with. I kind of married that code along with drivers/gpu/drm/ttm/ttm_page_alloc.c to create a TTM DMA pool code. The end result is DMA pool with extra features: can do write-combine, uncached, writeback (and tracks them and sets back to WB when freed); tracks "cached" pages that don't really need to be returned to a pool; and hooks up to the shrinker code so that the pools can be shrunk. If you guys think this set of patches make sense - my future plans were 1) Get this in large crowd of testing .. and if it works for a kernel release 2) to move a bulk of this in the lib/dmapool.c (I spoke with Matthew Wilcox about it and he is OK as long as I don't introduce performance regressions). But before I do any of that a second set of eyes taking a look at these patches would be most welcome. In regards to testing, I've been running them non-stop for the last two weeks (and found some issues which I've fixed up) - and been quite happy with how they work. I finally got my Intel VT-d box online so will test that shortly. Michel (thanks!) took a spin of the patches on his PowerPC and they did not cause any regressions (wheew). The patches are also located in a git tree: git://oss.oracle.com/git/kwilk/xen.git devel/ttm.dma_pool.v1.8 drivers/gpu/drm/nouveau/nouveau_mem.c | 8 +- drivers/gpu/drm/nouveau/nouveau_sgdma.c | 3 +- drivers/gpu/drm/radeon/radeon_device.c | 6 + drivers/gpu/drm/radeon/radeon_gart.c | 4 +- drivers/gpu/drm/radeon/radeon_ttm.c | 3 +- drivers/gpu/drm/ttm/Makefile | 3 + drivers/gpu/drm/ttm/ttm_bo.c | 4 +- drivers/gpu/drm/ttm/ttm_memory.c | 5 + drivers/gpu/drm/ttm/ttm_page_alloc.c | 63 ++- drivers/gpu/drm/ttm/ttm_page_alloc_dma.c | 1317 ++++++++++++++++++++++++++++++ drivers/gpu/drm/ttm/ttm_tt.c | 5 +- drivers/gpu/drm/vmwgfx/vmwgfx_drv.c | 4 +- drivers/xen/swiotlb-xen.c | 2 +- include/drm/ttm/ttm_bo_driver.h | 7 +- include/drm/ttm/ttm_page_alloc.h | 100 +++- include/linux/swiotlb.h | 7 +- lib/swiotlb.c | 5 +- 17 files changed, 1516 insertions(+), 30 deletions(-) _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel From xen-devel-bounces@lists.xensource.com Tue Sep 13 07:21:35 2011 Return-path: Envelope-to: www-data@lists.xensource.com Delivery-date: Tue, 13 Sep 2011 07:21:35 -0700 Received: from localhost ([127.0.0.1] helo=lists.colo.xensource.com) by lists.xensource.com with esmtp (Exim 4.43) id 1R3Tri-00024j-U5; Tue, 13 Sep 2011 07:21:34 -0700 Received: from mail174.messagelabs.com ([85.158.138.51]) by lists.xensource.com with esmtp (Exim 4.43) id 1R3TlQ-000809-Ld for xen-devel@lists.xensource.com; Tue, 13 Sep 2011 07:15:05 -0700 X-Env-Sender: konrad.wilk@oracle.com X-Msg-Ref: server-7.tower-174.messagelabs.com!1315923245!31247498!1 X-Originating-IP: [141.146.126.227] X-StarScan-Version: 6.3.6; banners=-,-,- X-VirusChecked: Checked Received: (qmail 15708 invoked from network); 13 Sep 2011 14:14:59 -0000 Received: from acsinet15.oracle.com (HELO acsinet15.oracle.com) (141.146.126.227) by server-7.tower-174.messagelabs.com with DHE-RSA-AES256-SHA encrypted SMTP; 13 Sep 2011 14:14:59 -0000 Received: from rtcsinet22.oracle.com (rtcsinet22.oracle.com [66.248.204.30]) by acsinet15.oracle.com (Switch-3.4.4/Switch-3.4.4) with ESMTP id p8DED9dO023862 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Tue, 13 Sep 2011 14:13:11 GMT Received: from acsmt357.oracle.com (acsmt357.oracle.com [141.146.40.157]) by rtcsinet22.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id p8DED6fo001587 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 13 Sep 2011 14:13:07 GMT Received: from abhmt112.oracle.com (abhmt112.oracle.com [141.146.116.64]) by acsmt357.oracle.com (8.12.11.20060308/8.12.11) with ESMTP id p8DED1kI009646; Tue, 13 Sep 2011 09:13:01 -0500 Received: from oracle.com (/209.6.55.207) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Tue, 13 Sep 2011 07:13:00 -0700 From: Konrad Rzeszutek Wilk To: thellstrom@vmware.com, linux-kernel@vger.kernel.org, xen-devel@lists.xensource.com, dri-devel@lists.freedesktop.org, thomas@shipmail.org Date: Tue, 13 Sep 2011 10:12:47 -0400 Message-Id: <1315923170-25568-5-git-send-email-konrad.wilk@oracle.com> X-Mailer: git-send-email 1.7.4.1 In-Reply-To: <1315923170-25568-1-git-send-email-konrad.wilk@oracle.com> References: <1315923170-25568-1-git-send-email-konrad.wilk@oracle.com> X-Source-IP: rtcsinet22.oracle.com [66.248.204.30] X-CT-RefId: str=0001.0A090206.4E6F64F8.0117,ss=1,re=0.000,fgs=0 Cc: Konrad Rzeszutek Wilk , airlied@linux.ie, Pekka Paalanen , FUJITA Tomonori , bskeggs@redhat.com, alexdeucher@gmail.com, airlied@redhat.com, j.glisse@redhat.com Subject: [Xen-devel] [PATCH 4/7] swiotlb: Expose swiotlb_nr_tlb function to modules as swiotlb_enabled X-BeenThere: xen-devel@lists.xensource.com X-Mailman-Version: 2.1.5 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xensource.com Errors-To: xen-devel-bounces@lists.xensource.com As a mechanism to detect whether SWIOTLB is enabled or not. And as such, we might as well wrap it within an 'swiotlb_enabled()' function that will call the swiotlb_nr_tlb. We also fix the spelling - it was swioltb instead of swiotlb. CC: FUJITA Tomonori Signed-off-by: Konrad Rzeszutek Wilk --- drivers/xen/swiotlb-xen.c | 2 +- include/linux/swiotlb.h | 7 ++++++- lib/swiotlb.c | 5 +++-- 3 files changed, 10 insertions(+), 4 deletions(-) diff --git a/drivers/xen/swiotlb-xen.c b/drivers/xen/swiotlb-xen.c index 6e8c15a..cbcd8cc 100644 --- a/drivers/xen/swiotlb-xen.c +++ b/drivers/xen/swiotlb-xen.c @@ -149,7 +149,7 @@ void __init xen_swiotlb_init(int verbose) int rc; unsigned long nr_tbl; - nr_tbl = swioltb_nr_tbl(); + nr_tbl = swiotlb_nr_tbl(); if (nr_tbl) xen_io_tlb_nslabs = nr_tbl; else { diff --git a/include/linux/swiotlb.h b/include/linux/swiotlb.h index 445702c..014ff53 100644 --- a/include/linux/swiotlb.h +++ b/include/linux/swiotlb.h @@ -24,7 +24,12 @@ extern int swiotlb_force; extern void swiotlb_init(int verbose); extern void swiotlb_init_with_tbl(char *tlb, unsigned long nslabs, int verbose); -extern unsigned long swioltb_nr_tbl(void); +extern unsigned long swiotlb_nr_tbl(void); + +static inline bool swiotlb_enabled(void) +{ + return !!swiotlb_nr_tbl(); +} /* * Enumeration for sync targets diff --git a/lib/swiotlb.c b/lib/swiotlb.c index 99093b3..058935e 100644 --- a/lib/swiotlb.c +++ b/lib/swiotlb.c @@ -110,11 +110,11 @@ setup_io_tlb_npages(char *str) __setup("swiotlb=", setup_io_tlb_npages); /* make io_tlb_overflow tunable too? */ -unsigned long swioltb_nr_tbl(void) +unsigned long swiotlb_nr_tbl(void) { return io_tlb_nslabs; } - +EXPORT_SYMBOL_GPL(swiotlb_nr_tbl); /* Note that this doesn't work with highmem page */ static dma_addr_t swiotlb_virt_to_bus(struct device *hwdev, volatile void *address) @@ -321,6 +321,7 @@ void __init swiotlb_free(void) free_bootmem_late(__pa(io_tlb_start), PAGE_ALIGN(io_tlb_nslabs << IO_TLB_SHIFT)); } + io_tlb_nslabs = 0; } static int is_swiotlb_buffer(phys_addr_t paddr) -- 1.7.4.1 _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel From xen-devel-bounces@lists.xensource.com Tue Sep 13 07:22:30 2011 Return-path: Envelope-to: www-data@lists.xensource.com Delivery-date: Tue, 13 Sep 2011 07:22:30 -0700 Received: from localhost ([127.0.0.1] helo=lists.colo.xensource.com) by lists.xensource.com with esmtp (Exim 4.43) id 1R3Tsb-0002Rp-Vk; Tue, 13 Sep 2011 07:22:30 -0700 Received: from mail216.messagelabs.com ([85.158.143.99]) by lists.xensource.com with esmtp (Exim 4.43) id 1R3Tmv-00006b-FH for xen-devel@lists.xensource.com; Tue, 13 Sep 2011 07:16:38 -0700 X-Env-Sender: konrad@oracle.com X-Msg-Ref: server-14.tower-216.messagelabs.com!1315923393!18120262!1 X-Originating-IP: [148.87.113.117] X-StarScan-Version: 6.3.6; banners=-,-,- X-VirusChecked: Checked Received: (qmail 15709 invoked from network); 13 Sep 2011 14:16:34 -0000 Received: from rcsinet15.oracle.com (HELO rcsinet15.oracle.com) (148.87.113.117) by server-14.tower-216.messagelabs.com with DHE-RSA-AES256-SHA encrypted SMTP; 13 Sep 2011 14:16:34 -0000 Received: from acsinet22.oracle.com (acsinet22.oracle.com [141.146.126.238]) by rcsinet15.oracle.com (Switch-3.4.4/Switch-3.4.4) with ESMTP id p8DEGSgF000527 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Tue, 13 Sep 2011 14:16:30 GMT Received: from acsmt358.oracle.com (acsmt358.oracle.com [141.146.40.158]) by acsinet22.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id p8DEGSJL004566 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 13 Sep 2011 14:16:28 GMT Received: from abhmt107.oracle.com (abhmt107.oracle.com [141.146.116.59]) by acsmt358.oracle.com (8.12.11.20060308/8.12.11) with ESMTP id p8DEGMqi020614; Tue, 13 Sep 2011 09:16:22 -0500 Received: from oracle.com (/209.6.55.207) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Tue, 13 Sep 2011 07:16:22 -0700 Received: by oracle.com (Postfix, from userid 1000) id 133BC1211; Tue, 13 Sep 2011 10:16:22 -0400 (EDT) Date: Tue, 13 Sep 2011 10:16:21 -0400 From: Konrad Rzeszutek Wilk To: David Vrabel Message-ID: <20110913141621.GA25628@phenom.oracle.com> References: <20110912201319.GA11900@oracle.com> <4E6F2A0E.6040208@citrix.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <4E6F2A0E.6040208@citrix.com> User-Agent: Mutt/1.5.21 (2010-09-15) X-Source-IP: acsinet22.oracle.com [141.146.126.238] X-Auth-Type: Internal IP X-CT-RefId: str=0001.0A090204.4E6F65BE.01AE:SCFMA922111,ss=1,re=-4.000,fgs=0 Cc: "xen-devel@lists.xensource.com" Subject: [Xen-devel] Re: fix for "xen: use maximum reservation to limit amount of usable RAM" - patch titled: "xen/e820: if there is not dom0_mem, don't tweak extra_pages." X-BeenThere: xen-devel@lists.xensource.com X-Mailman-Version: 2.1.5 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xensource.com Errors-To: xen-devel-bounces@lists.xensource.com On Tue, Sep 13, 2011 at 11:01:50AM +0100, David Vrabel wrote: > On 12/09/11 21:13, Konrad Rzeszutek Wilk wrote: > > .breaks one of my boxes (Core i3-2100), with Xen 4.1.1 (with and w/out the > > 23790 changset in it). > > > > I've traced it down to the fact that I booted my dom0 without > > dom0_mem=X flag with a machine that has more than 8GB. Weirdly enough > > I can only reproduce this under Intel boxes. > > > > Anyhow this patch fixes it for me. > > I think this patch is simpler. Does it fix the issue? Yes. Let me use that instead. > > diff --git a/arch/x86/xen/setup.c b/arch/x86/xen/setup.c > index c3b8d44..46d6d21 100644 > --- a/arch/x86/xen/setup.c > +++ b/arch/x86/xen/setup.c > @@ -306,10 +306,12 @@ char * __init xen_memory_setup(void) > sanitize_e820_map(e820.map, ARRAY_SIZE(e820.map), &e820.nr_map); > > extra_limit = xen_get_max_pages(); > - if (extra_limit >= max_pfn) > - extra_pages = extra_limit - max_pfn; > - else > - extra_pages = 0; > + if (max_pfn + extra_pages > extra_limit) { > + if (extra_limit > max_pfn) > + extra_pages = extra_limit - max_pfn; > + else > + extra_pages = 0; > + } > > extra_pages += xen_return_unused_memory(xen_start_info->nr_pages, &e820); > > David _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel From xen-devel-bounces@lists.xensource.com Tue Sep 13 07:35:28 2011 Return-path: Envelope-to: www-data@lists.xensource.com Delivery-date: Tue, 13 Sep 2011 07:35:28 -0700 Received: from localhost ([127.0.0.1] helo=lists.colo.xensource.com) by lists.xensource.com with esmtp (Exim 4.43) id 1R3U5A-00034e-Ec; Tue, 13 Sep 2011 07:35:28 -0700 Received: from mail216.messagelabs.com ([85.158.143.99]) by lists.xensource.com with esmtp (Exim 4.43) id 1R3U4T-0002rg-GC for xen-devel@lists.xensource.com; Tue, 13 Sep 2011 07:34:46 -0700 X-Env-Sender: Ian.Jackson@eu.citrix.com X-Msg-Ref: server-8.tower-216.messagelabs.com!1315924469!16591694!1 X-Originating-IP: [62.200.22.115] X-StarScan-Version: 6.3.6; banners=-,-,- X-VirusChecked: Checked Received: (qmail 10509 invoked from network); 13 Sep 2011 14:34:32 -0000 Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115) by server-8.tower-216.messagelabs.com with RC4-SHA encrypted SMTP; 13 Sep 2011 14:34:32 -0000 X-IronPort-AV: E=Sophos;i="4.68,374,1312156800"; d="scan'208";a="7766683" Received: from lonpmailmx01.citrite.net ([10.30.203.162]) by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5; 13 Sep 2011 14:33:59 +0000 Received: from woking.xci-test.com (10.80.248.135) by smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id 8.3.137.0; Tue, 13 Sep 2011 15:33:59 +0100 Received: from osstest by woking.xci-test.com with local (Exim 4.69) (envelope-from ) id 1R3U3j-00018C-2b; Tue, 13 Sep 2011 15:33:59 +0100 To: Message-ID: From: xen.org Date: Tue, 13 Sep 2011 15:33:59 +0100 MIME-Version: 1.0 Content-Type: text/plain Cc: ian.jackson@eu.citrix.com Subject: [Xen-devel] [xen-unstable test] 8884: regressions - trouble: blocked/fail X-BeenThere: xen-devel@lists.xensource.com X-Mailman-Version: 2.1.5 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xensource.com Errors-To: xen-devel-bounces@lists.xensource.com flight 8884 xen-unstable real [real] http://www.chiark.greenend.org.uk/~xensrcts/logs/8884/ Regressions :-( Tests which did not succeed and are blocking: build-amd64 4 xen-build fail REGR. vs. 8873 build-i386 4 xen-build fail REGR. vs. 8873 build-i386-oldkern 4 xen-build fail REGR. vs. 8873 build-amd64-oldkern 4 xen-build fail REGR. vs. 8873 Tests which did not succeed, but are not blocking, including regressions (tests previously passed) regarded as allowable: test-amd64-amd64-xl-pcipt-intel 1 xen-build-check(1) blocked n/a test-amd64-i386-rhel6hvm-intel 1 xen-build-check(1) blocked n/a test-i386-i386-pv 1 xen-build-check(1) blocked n/a test-amd64-i386-pv 1 xen-build-check(1) blocked n/a test-amd64-amd64-pv 1 xen-build-check(1) blocked n/a test-i386-i386-xl 1 xen-build-check(1) blocked n/a test-amd64-i386-xl 1 xen-build-check(1) blocked n/a test-amd64-i386-xl-credit2 1 xen-build-check(1) blocked n/a test-amd64-i386-rhel6hvm-amd 1 xen-build-check(1) blocked n/a test-amd64-amd64-pair 1 xen-build-check(1) blocked n/a test-amd64-i386-pair 1 xen-build-check(1) blocked n/a test-i386-i386-pair 1 xen-build-check(1) blocked n/a build-amd64-pvops 4 kernel-build fail like 8873 build-i386-pvops 4 kernel-build fail like 8873 test-amd64-i386-xl-multivcpu 1 xen-build-check(1) blocked n/a test-amd64-amd64-xl-sedf 1 xen-build-check(1) blocked n/a test-amd64-i386-win-vcpus1 1 xen-build-check(1) blocked n/a test-amd64-i386-xl-win-vcpus1 1 xen-build-check(1) blocked n/a test-amd64-amd64-win 1 xen-build-check(1) blocked n/a test-amd64-i386-win 1 xen-build-check(1) blocked n/a test-amd64-amd64-xl-win 1 xen-build-check(1) blocked n/a test-amd64-amd64-xl 1 xen-build-check(1) blocked n/a test-i386-i386-xl-win 1 xen-build-check(1) blocked n/a test-i386-i386-win 1 xen-build-check(1) blocked n/a version targeted for testing: xen e564f2f1b737 baseline version: xen 0312575dc35e ------------------------------------------------------------ People who touched revisions under test: Andrew Cooper Benjamin Schweikert Christoph Egger George Dunlap Ian Campbell Ian Jackson Keir Fraser Olaf Hering Stefano Stabellini Tim Deegan ------------------------------------------------------------ jobs: build-amd64 fail build-i386 fail build-amd64-oldkern fail build-i386-oldkern fail build-amd64-pvops fail build-i386-pvops fail test-amd64-amd64-xl blocked test-amd64-i386-xl blocked test-i386-i386-xl blocked test-amd64-i386-rhel6hvm-amd blocked test-amd64-i386-xl-credit2 blocked test-amd64-amd64-xl-pcipt-intel blocked test-amd64-i386-rhel6hvm-intel blocked test-amd64-i386-xl-multivcpu blocked test-amd64-amd64-pair blocked test-amd64-i386-pair blocked test-i386-i386-pair blocked test-amd64-amd64-pv blocked test-amd64-i386-pv blocked test-i386-i386-pv blocked test-amd64-amd64-xl-sedf blocked test-amd64-i386-win-vcpus1 blocked test-amd64-i386-xl-win-vcpus1 blocked test-amd64-amd64-win blocked test-amd64-i386-win blocked test-i386-i386-win blocked test-amd64-amd64-xl-win blocked test-i386-i386-xl-win blocked ------------------------------------------------------------ sg-report-flight on woking.cam.xci-test.com logs: /home/xc_osstest/logs images: /home/xc_osstest/images Logs, config files, etc. are available at http://www.chiark.greenend.org.uk/~xensrcts/logs Test harness code can be found at http://xenbits.xensource.com/gitweb?p=osstest.git;a=summary Not pushing. ------------------------------------------------------------ changeset: 23836:e564f2f1b737 tag: tip user: Ian Jackson date: Tue Sep 13 14:52:22 2011 +0100 tools: fix permissions of git-checkout.sh 23828:0d21b68f528b introduced a new scripts/git-checkout.sh, but it had the wrong permissions. chmod +x it, and add a blank line at the end to make sure it actually gets updated. Signed-off-by: Ian Jackson changeset: 23835:64aab9a077ea user: Keir Fraser date: Tue Sep 13 11:20:57 2011 +0100 scripts/git-checkout.sh: Is not bash specific. Invoke with /bin/sh. Signed-off-by: Keir Fraser changeset: 23834:1d40b2793723 user: George Dunlap date: Tue Sep 13 10:43:43 2011 +0100 xen,credit1: Add variable timeslice Add a xen command-line parameter, sched_credit_tslice_ms, to set the timeslice of the credit1 scheduler. Signed-off-by: George Dunlap changeset: 23833:ffe8e65f6687 user: Andrew Cooper date: Tue Sep 13 10:33:10 2011 +0100 IRQ: IO-APIC support End Of Interrupt for older IO-APICs The old io_apic_eoi() function using the EOI register only works for IO-APICs with a version of 0x20. Older IO-APICs do not have an EOI register so line level interrupts have to be EOI'd by flipping the mode to edge and back, which clears the IRR and Delivery Status bits. This patch replaces the current io_apic_eoi() function with one which takes into account the version of the IO-APIC and EOI's appropriately. v2: make recursive call to __io_apic_eoi() to reduce code size. Signed-off-by: Andrew Cooper changeset: 23832:ad3b4bb097cb user: Stefano Stabellini date: Tue Sep 13 10:32:24 2011 +0100 xen: if mapping GSIs we run out of pirq < nr_irqs_gsi, use the others PV on HVM guests can have more GSIs than the host, in that case we could run out of pirq < nr_irqs_gsi. When that happens use pirq >= nr_irqs_gsi rather than returning an error. Signed-off-by: Stefano Stabellini Tested-by: Benjamin Schweikert changeset: 23831:53416e7c0529 user: Stefano Stabellini date: Tue Sep 13 10:30:09 2011 +0100 Clone and build Seabios by default Signed-off-by: Stefano Stabellini changeset: 23830:1b80eaeeba7b user: Stefano Stabellini date: Tue Sep 13 10:29:14 2011 +0100 Clone and build upstream Qemu by default Signed-off-by: Stefano Stabellini changeset: 23829:9a541243aeaf user: Stefano Stabellini date: Tue Sep 13 10:27:53 2011 +0100 Rename ioemu-dir as qemu-xen-traditional-dir Signed-off-by: Stefano Stabellini changeset: 23828:0d21b68f528b user: Stefano Stabellini date: Tue Sep 13 10:27:20 2011 +0100 Move the ioemu-dir-find shell script to an external file Add support for configuring upstream qemu and rename ioemu-remote ioemu-dir-remote. Signed-off-by: Stefano Stabellini changeset: 23827:d1d6abc1db20 user: Olaf Hering date: Tue Sep 13 10:25:32 2011 +0100 xenpaging: use batch of pages during final page-in Map up to RING_SIZE pages in exit path to fill the ring instead of populating one page at a time. Signed-off-by: Olaf Hering changeset: 23826:ad958e87db79 user: Ian Campbell date: Tue Sep 13 10:22:03 2011 +0100 hvmloader: don't clear acpi_info after filling in some fields In particular the madt_lapic0_addr and madt_csum_addr fields are filled in while building the tables. This fixes a bluescreen on shutdown with certain versions of Windows. Signed-off-by: Ian Campbell Reported-by: Christoph Egger Tested-and-acked-by: Christoph Egger changeset: 23825:0312575dc35e user: Tim Deegan date: Thu Sep 08 15:13:06 2011 +0100 x86/mm: use new page-order interfaces in nested HAP code to make 2M and 1G mappings in the nested p2m tables. Signed-off-by: Christoph Egger Signed-off-by: Tim Deegan Committed-by: Tim Deegan ======================================== commit cd776ee9408ff127f934a707c1a339ee600bc127 Author: Ian Jackson Date: Tue Jun 28 13:50:53 2011 +0100 qemu-char.c: fix incorrect CONFIG_STUBDOM handling qemu-char.c:1123:7: warning: "CONFIG_STUBDOM" is not defined [-Wundef] Signed-off-by: Olaf Hering Acked-by: Ian Jackson _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel From xen-devel-bounces@lists.xensource.com Tue Sep 13 07:40:48 2011 Return-path: Envelope-to: www-data@lists.xensource.com Delivery-date: Tue, 13 Sep 2011 07:40:48 -0700 Received: from localhost ([127.0.0.1] helo=lists.colo.xensource.com) by lists.xensource.com with esmtp (Exim 4.43) id 1R3UAK-0003as-Im; Tue, 13 Sep 2011 07:40:48 -0700 Received: from mail21.messagelabs.com ([85.158.143.35]) by lists.xensource.com with esmtp (Exim 4.43) id 1R3U9o-0003Ot-JB for xen-devel@lists.xensource.com; Tue, 13 Sep 2011 07:40:16 -0700 X-Env-Sender: Stefano.Stabellini@eu.citrix.com X-Msg-Ref: server-6.tower-21.messagelabs.com!1315924793!38083748!1 X-Originating-IP: [62.200.22.115] X-StarScan-Version: 6.4.1; banners=-,-,- X-VirusChecked: Checked Received: (qmail 14531 invoked from network); 13 Sep 2011 14:39:54 -0000 Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115) by server-6.tower-21.messagelabs.com with RC4-SHA encrypted SMTP; 13 Sep 2011 14:39:54 -0000 X-IronPort-AV: E=Sophos;i="4.68,374,1312156800"; d="scan'208";a="7766957" Received: from lonpmailmx01.citrite.net ([10.30.203.162]) by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5; 13 Sep 2011 14:40:13 +0000 Received: from kaball.uk.xensource.com (10.80.2.59) by LONPMAILMX01.citrite.net (10.30.203.162) with Microsoft SMTP Server id 8.3.137.0; Tue, 13 Sep 2011 15:40:13 +0100 Date: Tue, 13 Sep 2011 15:48:50 +0100 From: Stefano Stabellini X-X-Sender: sstabellini@kaball-desktop To: xen-devel@lists.xensource.com Message-ID: User-Agent: Alpine 2.00 (DEB 1167 2008-08-23) MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Subject: [Xen-devel] [PATCH] fix the build when CONFIG_QEMU is specified by the user X-BeenThere: xen-devel@lists.xensource.com X-Mailman-Version: 2.1.5 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xensource.com Errors-To: xen-devel-bounces@lists.xensource.com fix the build when CONFIG_QEMU is specified by the user Signed-off-by: Stefano Stabellini Committed-by: Stefano Stabellini diff -r e564f2f1b737 -r 51913fe3d25a scripts/git-checkout.sh --- a/scripts/git-checkout.sh Tue Sep 13 14:52:22 2011 +0100 +++ b/scripts/git-checkout.sh Tue Sep 13 15:46:47 2011 +0100 @@ -30,7 +30,7 @@ set -e cd $DIR # is this qemu-xen-traditional? if test -f $ROOT/xen-setup; then - $ROOT/xen-setup $IOEMU_CONFIGURE_CROSS + QEMU_ROOT=$ROOT $ROOT/xen-setup $IOEMU_CONFIGURE_CROSS # is this qemu-xen? elif test -f $ROOT/configure; then cd $ROOT _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel From xen-devel-bounces@lists.xensource.com Tue Sep 13 08:09:09 2011 Return-path: Envelope-to: www-data@lists.xensource.com Delivery-date: Tue, 13 Sep 2011 08:09:09 -0700 Received: from localhost ([127.0.0.1] helo=lists.colo.xensource.com) by lists.xensource.com with esmtp (Exim 4.43) id 1R3Ubj-0006rk-KJ; Tue, 13 Sep 2011 08:09:08 -0700 Received: from mail174.messagelabs.com ([85.158.138.51]) by lists.xensource.com with esmtp (Exim 4.43) id 1R3UaW-0006eE-JC for Xen-devel@lists.xensource.com; Tue, 13 Sep 2011 08:07:53 -0700 X-Env-Sender: tglx@linutronix.de X-Msg-Ref: server-14.tower-174.messagelabs.com!1315926465!31278927!1 X-Originating-IP: [62.245.132.108] X-StarScan-Version: 6.3.6; banners=-,-,- X-VirusChecked: Checked Received: (qmail 23341 invoked from network); 13 Sep 2011 15:07:48 -0000 Received: from www.linutronix.de (HELO Galois.linutronix.de) (62.245.132.108) by server-14.tower-174.messagelabs.com with AES256-SHA encrypted SMTP; 13 Sep 2011 15:07:48 -0000 Received: from localhost ([127.0.0.1]) by Galois.linutronix.de with esmtps (TLS1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.72) (envelope-from ) id 1R3UaE-00010q-RL; Tue, 13 Sep 2011 17:07:35 +0200 Date: Tue, 13 Sep 2011 17:07:33 +0200 (CEST) From: Thomas Gleixner To: Stephen Rothwell In-Reply-To: <20110913211154.fe53ca8c1d608def77a69022@canb.auug.org.au> Message-ID: References: <20110825142450.c84e02d8763cfd1a93411844@canb.auug.org.au> <4E5690C3.2050706@goop.org> <4E5693DD.2010307@zytor.com> <20110826090619.7588d424798f53a6f3621eb2@canb.auug.org.au> <4E56D6E1.6030405@zytor.com> <20110826125441.709aa423cdf072ce085fb91c@canb.auug.org.au> <20110913211154.fe53ca8c1d608def77a69022@canb.auug.org.au> User-Agent: Alpine 2.02 (LFD 1266 2009-07-14) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Linutronix-Spam-Score: -1.0 X-Linutronix-Spam-Level: - X-Linutronix-Spam-Status: No , -1.0 points, 5.0 required, ALL_TRUSTED=-1, SHORTCIRCUIT=-0.0001 Cc: Jeremy Fitzhardinge , Xen Devel , Peter Zijlstra , linux-kernel@vger.kernel.org, linux-next@vger.kernel.org, "H. Peter Anvin" , Ingo Molnar Subject: [Xen-devel] Re: linux-next: manual merge of the xen tree with the tip tree X-BeenThere: xen-devel@lists.xensource.com X-Mailman-Version: 2.1.5 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xensource.com Errors-To: xen-devel-bounces@lists.xensource.com On Tue, 13 Sep 2011, Stephen Rothwell wrote: > Hi, > > On Fri, 26 Aug 2011 12:54:41 +1000 Stephen Rothwell wrote: > > > > On Thu, 25 Aug 2011 16:12:33 -0700 "H. Peter Anvin" wrote: > > > > > > On 08/25/2011 04:06 PM, Stephen Rothwell wrote: > > > >> > > > >> Stephen: the x86/spinlocks branch in the -tip tree is obsolete and > > > >> should be dropped. > > > > > > > > That's a bit tricky as I get a rolled up tip tree. The best I could do > > > > is revert the commit that merges the x86/spinlocks branch into > > > > auto-latest ... I'll do that for today (unless something happens to the > > > > tip tree in the next hour). > > > > > > > > > > OK, let me bother Ingo about it. > > > > For today, I have done "git revert -m 1 6f8fa39c81f1" after merging the > > tip tree. > > I am still doing this in each linux-next, and it doesn't appear to have > been fixed up the the tree on tesla.tglx.de, yet, I think. We'll take it out. Thanks, tglx _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel From xen-devel-bounces@lists.xensource.com Tue Sep 13 08:28:31 2011 Return-path: Envelope-to: www-data@lists.xensource.com Delivery-date: Tue, 13 Sep 2011 08:28:31 -0700 Received: from localhost ([127.0.0.1] helo=lists.colo.xensource.com) by lists.xensource.com with esmtp (Exim 4.43) id 1R3UuV-0008Cz-6c; Tue, 13 Sep 2011 08:28:31 -0700 Received: from mail21.messagelabs.com ([85.158.143.35]) by lists.xensource.com with esmtp (Exim 4.43) id 1R3Utr-00080g-ME for xen-devel@lists.xensource.com; Tue, 13 Sep 2011 08:27:52 -0700 X-Env-Sender: Ian.Jackson@eu.citrix.com X-Msg-Ref: server-7.tower-21.messagelabs.com!1315927639!54695509!1 X-Originating-IP: [62.200.22.115] X-StarScan-Version: 6.4.1; banners=-,-,- X-VirusChecked: Checked Received: (qmail 6835 invoked from network); 13 Sep 2011 15:27:19 -0000 Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115) by server-7.tower-21.messagelabs.com with RC4-SHA encrypted SMTP; 13 Sep 2011 15:27:19 -0000 X-IronPort-AV: E=Sophos;i="4.68,374,1312156800"; d="scan'208";a="7768969" Received: from lonpmailmx01.citrite.net ([10.30.203.162]) by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5; 13 Sep 2011 15:27:48 +0000 Received: from woking.xci-test.com (10.80.248.135) by smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id 8.3.137.0; Tue, 13 Sep 2011 16:27:48 +0100 Received: from osstest by woking.xci-test.com with local (Exim 4.69) (envelope-from ) id 1R3Uto-0001wF-84; Tue, 13 Sep 2011 16:27:48 +0100 To: xen-devel@lists.xensource.com Message-ID: From: xen.org Date: Tue, 13 Sep 2011 16:27:48 +0100 MIME-Version: 1.0 Content-Type: text/plain Cc: ian.jackson@eu.citrix.com, keir@xen.org, stefano.stabellini@eu.citrix.com Subject: [Xen-devel] [xen-unstable bisection] complete build-amd64 X-BeenThere: xen-devel@lists.xensource.com X-Mailman-Version: 2.1.5 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xensource.com Errors-To: xen-devel-bounces@lists.xensource.com branch xen-unstable xen branch xen-unstable job build-amd64 test xen-build Tree: xen http://hg.uk.xensource.com/xen-unstable.hg *** Found and reproduced problem changeset *** Bug is in tree: xen http://hg.uk.xensource.com/xen-unstable.hg Bug introduced: 0d21b68f528b Bug not present: d1d6abc1db20 changeset: 23828:0d21b68f528b user: Stefano Stabellini date: Tue Sep 13 10:27:20 2011 +0100 Move the ioemu-dir-find shell script to an external file Add support for configuring upstream qemu and rename ioemu-remote ioemu-dir-remote. Signed-off-by: Stefano Stabellini For bisection revision-tuple graph see: http://www.chiark.greenend.org.uk/~xensrcts/results/bisect.xen-unstable.build-amd64.xen-build.html Revision IDs in each graph node refer, respectively, to the Trees above. ---------------------------------------- Searching for failure / basis pass: 8884 fail [host=moss-bug] / 8873 ok. Failure / basis pass flights: 8884 / 8873 (tree in basispass but not in latest: qemu) Tree: xen http://hg.uk.xensource.com/xen-unstable.hg Latest e564f2f1b737 Basis pass 0312575dc35e Generating revisions with ./adhoc-revtuple-generator http://hg.uk.xensource.com/xen-unstable.hg#0312575dc35e-e564f2f1b737 pulling from http://hg.uk.xensource.com/xen-unstable.hg searching for changes no changes found pulling from http://hg.uk.xensource.com/xen-unstable.hg searching for changes no changes found Loaded 1001 nodes in revision graph Searching for test results: 8865 [host=woodlouse] 8869 [host=itch-mite] 8870 [host=itch-mite] 8871 [host=itch-mite] 8872 [host=itch-mite] 8873 pass 0312575dc35e 8876 fail 64aab9a077ea 8877 pass 0312575dc35e 8878 fail 64aab9a077ea 8880 fail 1b80eaeeba7b 8881 pass d1d6abc1db20 8882 fail 0d21b68f528b 8883 pass d1d6abc1db20 8885 fail 0d21b68f528b 8886 pass d1d6abc1db20 8884 fail e564f2f1b737 8887 pass 0312575dc35e 8888 fail e564f2f1b737 8889 fail 0d21b68f528b Searching for interesting versions Result found: flight 8873 (pass), for basis pass Result found: flight 8884 (fail), for basis failure Repro found: flight 8887 (pass), for basis pass Repro found: flight 8888 (fail), for basis failure 0 revisions at d1d6abc1db20 No revisions left to test, checking graph state. Result found: flight 8881 (pass), for last pass Result found: flight 8882 (fail), for first failure Repro found: flight 8883 (pass), for last pass Repro found: flight 8885 (fail), for first failure Repro found: flight 8886 (pass), for last pass Repro found: flight 8889 (fail), for first failure *** Found and reproduced problem changeset *** Bug is in tree: xen http://hg.uk.xensource.com/xen-unstable.hg Bug introduced: 0d21b68f528b Bug not present: d1d6abc1db20 pulling from http://hg.uk.xensource.com/xen-unstable.hg searching for changes no changes found changeset: 23828:0d21b68f528b user: Stefano Stabellini date: Tue Sep 13 10:27:20 2011 +0100 Move the ioemu-dir-find shell script to an external file Add support for configuring upstream qemu and rename ioemu-remote ioemu-dir-remote. Signed-off-by: Stefano Stabellini Revision graph left in /home/xc_osstest/results/bisect.xen-unstable.build-amd64.xen-build.{dot,ps,png,html}. ---------------------------------------- 8889: ALL FAIL flight 8889 xen-unstable real-bisect [real] http://www.chiark.greenend.org.uk/~xensrcts/logs/8889/ jobs: build-amd64 fail ------------------------------------------------------------ sg-report-flight on woking.cam.xci-test.com logs: /home/xc_osstest/logs images: /home/xc_osstest/images Logs, config files, etc. are available at http://www.chiark.greenend.org.uk/~xensrcts/logs Test harness code can be found at http://xenbits.xensource.com/gitweb?p=osstest.git;a=summary _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel From xen-devel-bounces@lists.xensource.com Tue Sep 13 09:11:21 2011 Return-path: Envelope-to: www-data@lists.xensource.com Delivery-date: Tue, 13 Sep 2011 09:11:21 -0700 Received: from localhost ([127.0.0.1] helo=lists.colo.xensource.com) by lists.xensource.com with esmtp (Exim 4.43) id 1R3VZx-0005Hr-Fq; Tue, 13 Sep 2011 09:11:21 -0700 Received: from mail182.messagelabs.com ([85.158.139.83]) by lists.xensource.com with esmtp (Exim 4.43) id 1R3VYj-00054U-CP for xen-devel@lists.xensource.com; Tue, 13 Sep 2011 09:10:10 -0700 X-Env-Sender: fbcyborg@gmail.com X-Msg-Ref: server-2.tower-182.messagelabs.com!1315930200!17190787!1 X-Originating-IP: [209.85.216.178] X-StarScan-Version: 6.3.6; banners=-,-,- X-VirusChecked: Checked Received: (qmail 29145 invoked from network); 13 Sep 2011 16:10:02 -0000 Received: from mail-qy0-f178.google.com (HELO mail-qy0-f178.google.com) (209.85.216.178) by server-2.tower-182.messagelabs.com with RC4-SHA encrypted SMTP; 13 Sep 2011 16:10:02 -0000 Received: by qyg14 with SMTP id 14so639072qyg.9 for ; Tue, 13 Sep 2011 09:10:00 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :content-type; bh=Vutd+vW0ivDh3KITUA0kGT1BiS9SCNpVA7NXyfi/zK8=; b=dApZ/ISiF5Ebd8FVbQsTt9bFM1q/LOupsTYUs2T04VW6b4JZk+b/i2IS3r5rcItU+W EOrHAGMZ0PYTKqE2S4uuuSsGLW4Sy5raNOrpjwfQgQETFpMZsoNHZs6coCoaVmrc8L7E 48Rz+vPHrMHgVuCRB4cT6I8egdtWVzxnMkxaU= Received: by 10.52.92.233 with SMTP id cp9mr90829vdb.513.1315930200052; Tue, 13 Sep 2011 09:10:00 -0700 (PDT) MIME-Version: 1.0 Received: by 10.220.108.72 with HTTP; Tue, 13 Sep 2011 09:09:40 -0700 (PDT) In-Reply-To: References: From: Flavio Date: Tue, 13 Sep 2011 18:09:40 +0200 Message-ID: To: xen-devel Content-Type: text/plain; charset=ISO-8859-1 Subject: [Xen-devel] Re: Help with the migration to XEN-4.1 please X-BeenThere: xen-devel@lists.xensource.com X-Mailman-Version: 2.1.5 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xensource.com Errors-To: xen-devel-bounces@lists.xensource.com I have recently upgraded to xen-tools-4.1.1-r4 but no luck with it. On 13 September 2011 10:58, Flavio wrote: > 2) If I try to run a gentoo linux guest (for instance) running > 'xl create vm_config_file.cfg -c' I get the following error: > xenconsole: Could not read tty from store: No such file or directory I would like to know what "file or directory" that message refers to. What XEN is expecting to find as a "file or directory" and where? -- Flavio _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel From xen-devel-bounces@lists.xensource.com Tue Sep 13 09:22:32 2011 Return-path: Envelope-to: www-data@lists.xensource.com Delivery-date: Tue, 13 Sep 2011 09:22:32 -0700 Received: from localhost ([127.0.0.1] helo=lists.colo.xensource.com) by lists.xensource.com with esmtp (Exim 4.43) id 1R3Vkm-0005rT-BJ; Tue, 13 Sep 2011 09:22:32 -0700 Received: from mail21.messagelabs.com ([85.158.143.35]) by lists.xensource.com with esmtp (Exim 4.43) id 1R3VkB-0005cw-I8 for xen-devel@lists.xensource.com; Tue, 13 Sep 2011 09:21:56 -0700 X-Env-Sender: xenlist@suykerbuyk.org X-Msg-Ref: server-5.tower-21.messagelabs.com!1315930878!47979141!1 X-Originating-IP: [216.139.236.26] X-StarScan-Version: 6.4.1; banners=-,-,- X-VirusChecked: Checked Received: (qmail 9694 invoked from network); 13 Sep 2011 16:21:19 -0000 Received: from sam.nabble.com (HELO sam.nabble.com) (216.139.236.26) by server-5.tower-21.messagelabs.com with AES256-SHA encrypted SMTP; 13 Sep 2011 16:21:19 -0000 Received: from [192.168.236.26] (helo=sam.nabble.com) by sam.nabble.com with esmtp (Exim 4.72) (envelope-from ) id 1R3Vk6-0004y3-Mm for xen-devel@lists.xensource.com; Tue, 13 Sep 2011 09:21:50 -0700 Date: Tue, 13 Sep 2011 09:21:50 -0700 (PDT) From: JohnSuykerbuyk To: xen-devel@lists.xensource.com Message-ID: <1315930910700-4799120.post@n5.nabble.com> In-Reply-To: <20110912211640.GA14805@phenom.oracle.com> References: <20110912145843.GB15778@oracle.com> <1315859925763-4795821.post@n5.nabble.com> <20110912211640.GA14805@phenom.oracle.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Subject: [Xen-devel] Re: git.kernel.org X-BeenThere: xen-devel@lists.xensource.com X-Mailman-Version: 2.1.5 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xensource.com Errors-To: xen-devel-bounces@lists.xensource.com That was entertaining! Entertaining, but not so helpful. Let me try again. I'm building from SuSE sources. In the buildconfigs of Xen 4.0 , there is a make file, "mk.linux-2.6-pvops" that initializes the following repository URL: http://www.kernel.org/pub/scm/linux/kernel/git/jeremy/xen.git Perhaps this is a specialization on the part of SuSE. Any help in finding these magical repositories, or in inserting a crowbar such that Xen can build in place without a network connection would be greatly appreciated. - John "S" PS: Yes, I have googled for Jeremy, Xen, etc. Discovered the repo was made by Jeremy Fitzhardinge, found his home pages, caught several education presentations & interviews he's given, but I still don't know of a way to build Xen with kernel.org being tits-up. -- View this message in context: http://xen.1045712.n5.nabble.com/git-kernel-org-tp4792977p4799120.html Sent from the Xen - Dev mailing list archive at Nabble.com. _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel From xen-devel-bounces@lists.xensource.com Tue Sep 13 10:30:36 2011 Return-path: Envelope-to: www-data@lists.xensource.com Delivery-date: Tue, 13 Sep 2011 10:30:36 -0700 Received: from localhost ([127.0.0.1] helo=lists.colo.xensource.com) by lists.xensource.com with esmtp (Exim 4.43) id 1R3Woc-0001gb-Oj; Tue, 13 Sep 2011 10:30:34 -0700 Received: from mail27.messagelabs.com ([193.109.254.147]) by lists.xensource.com with esmtp (Exim 4.43) id 1R3Wne-0001Tz-Oz for xen-devel@lists.xensource.com; Tue, 13 Sep 2011 10:29:41 -0700 X-Env-Sender: Ian.Jackson@eu.citrix.com X-Msg-Ref: server-11.tower-27.messagelabs.com!1315934964!37265127!1 X-Originating-IP: [62.200.22.115] X-StarScan-Version: 6.3.6; banners=-,-,- X-VirusChecked: Checked Received: (qmail 3930 invoked from network); 13 Sep 2011 17:29:24 -0000 Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115) by server-11.tower-27.messagelabs.com with RC4-SHA encrypted SMTP; 13 Sep 2011 17:29:24 -0000 X-IronPort-AV: E=Sophos;i="4.68,375,1312156800"; d="scan'208";a="7773201" Received: from lonpmailmx01.citrite.net ([10.30.203.162]) by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5; 13 Sep 2011 17:29:06 +0000 Received: from woking.xci-test.com (10.80.248.135) by smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id 8.3.137.0; Tue, 13 Sep 2011 18:29:07 +0100 Received: from osstest by woking.xci-test.com with local (Exim 4.69) (envelope-from ) id 1R3WnC-0004dZ-KA; Tue, 13 Sep 2011 18:29:06 +0100 To: Message-ID: From: xen.org Date: Tue, 13 Sep 2011 18:29:06 +0100 MIME-Version: 1.0 Content-Type: text/plain Cc: ian.jackson@eu.citrix.com Subject: [Xen-devel] [xen-unstable test] 8895: regressions - trouble: blocked/fail X-BeenThere: xen-devel@lists.xensource.com X-Mailman-Version: 2.1.5 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xensource.com Errors-To: xen-devel-bounces@lists.xensource.com flight 8895 xen-unstable real [real] http://www.chiark.greenend.org.uk/~xensrcts/logs/8895/ Regressions :-( Tests which did not succeed and are blocking: build-amd64 4 xen-build fail REGR. vs. 8873 build-i386 4 xen-build fail REGR. vs. 8873 build-i386-oldkern 4 xen-build fail REGR. vs. 8873 build-amd64-oldkern 4 xen-build fail REGR. vs. 8873 Tests which did not succeed, but are not blocking, including regressions (tests previously passed) regarded as allowable: test-amd64-amd64-xl-pcipt-intel 1 xen-build-check(1) blocked n/a test-amd64-i386-rhel6hvm-intel 1 xen-build-check(1) blocked n/a test-i386-i386-pv 1 xen-build-check(1) blocked n/a test-amd64-i386-pv 1 xen-build-check(1) blocked n/a test-amd64-amd64-pv 1 xen-build-check(1) blocked n/a test-i386-i386-xl 1 xen-build-check(1) blocked n/a test-amd64-i386-xl 1 xen-build-check(1) blocked n/a test-amd64-i386-xl-credit2 1 xen-build-check(1) blocked n/a test-amd64-i386-rhel6hvm-amd 1 xen-build-check(1) blocked n/a test-amd64-amd64-pair 1 xen-build-check(1) blocked n/a test-amd64-i386-pair 1 xen-build-check(1) blocked n/a test-i386-i386-pair 1 xen-build-check(1) blocked n/a build-amd64-pvops 4 kernel-build fail like 8873 build-i386-pvops 4 kernel-build fail like 8873 test-amd64-i386-xl-multivcpu 1 xen-build-check(1) blocked n/a test-amd64-amd64-xl-sedf 1 xen-build-check(1) blocked n/a test-amd64-i386-win-vcpus1 1 xen-build-check(1) blocked n/a test-amd64-i386-xl-win-vcpus1 1 xen-build-check(1) blocked n/a test-amd64-amd64-win 1 xen-build-check(1) blocked n/a test-amd64-i386-win 1 xen-build-check(1) blocked n/a test-amd64-amd64-xl-win 1 xen-build-check(1) blocked n/a test-amd64-amd64-xl 1 xen-build-check(1) blocked n/a test-i386-i386-xl-win 1 xen-build-check(1) blocked n/a test-i386-i386-win 1 xen-build-check(1) blocked n/a version targeted for testing: xen 51913fe3d25a baseline version: xen 0312575dc35e ------------------------------------------------------------ People who touched revisions under test: Andrew Cooper Benjamin Schweikert Christoph Egger George Dunlap Ian Campbell Ian Jackson Keir Fraser Olaf Hering Stefano Stabellini Tim Deegan ------------------------------------------------------------ jobs: build-amd64 fail build-i386 fail build-amd64-oldkern fail build-i386-oldkern fail build-amd64-pvops fail build-i386-pvops fail test-amd64-amd64-xl blocked test-amd64-i386-xl blocked test-i386-i386-xl blocked test-amd64-i386-rhel6hvm-amd blocked test-amd64-i386-xl-credit2 blocked test-amd64-amd64-xl-pcipt-intel blocked test-amd64-i386-rhel6hvm-intel blocked test-amd64-i386-xl-multivcpu blocked test-amd64-amd64-pair blocked test-amd64-i386-pair blocked test-i386-i386-pair blocked test-amd64-amd64-pv blocked test-amd64-i386-pv blocked test-i386-i386-pv blocked test-amd64-amd64-xl-sedf blocked test-amd64-i386-win-vcpus1 blocked test-amd64-i386-xl-win-vcpus1 blocked test-amd64-amd64-win blocked test-amd64-i386-win blocked test-i386-i386-win blocked test-amd64-amd64-xl-win blocked test-i386-i386-xl-win blocked ------------------------------------------------------------ sg-report-flight on woking.cam.xci-test.com logs: /home/xc_osstest/logs images: /home/xc_osstest/images Logs, config files, etc. are available at http://www.chiark.greenend.org.uk/~xensrcts/logs Test harness code can be found at http://xenbits.xensource.com/gitweb?p=osstest.git;a=summary Not pushing. ------------------------------------------------------------ changeset: 23837:51913fe3d25a tag: tip user: Stefano Stabellini date: Tue Sep 13 15:46:47 2011 +0100 fix the build when CONFIG_QEMU is specified by the user Signed-off-by: Stefano Stabellini Committed-by: Stefano Stabellini changeset: 23836:e564f2f1b737 user: Ian Jackson date: Tue Sep 13 14:52:22 2011 +0100 tools: fix permissions of git-checkout.sh 23828:0d21b68f528b introduced a new scripts/git-checkout.sh, but it had the wrong permissions. chmod +x it, and add a blank line at the end to make sure it actually gets updated. Signed-off-by: Ian Jackson changeset: 23835:64aab9a077ea user: Keir Fraser date: Tue Sep 13 11:20:57 2011 +0100 scripts/git-checkout.sh: Is not bash specific. Invoke with /bin/sh. Signed-off-by: Keir Fraser changeset: 23834:1d40b2793723 user: George Dunlap date: Tue Sep 13 10:43:43 2011 +0100 xen,credit1: Add variable timeslice Add a xen command-line parameter, sched_credit_tslice_ms, to set the timeslice of the credit1 scheduler. Signed-off-by: George Dunlap changeset: 23833:ffe8e65f6687 user: Andrew Cooper date: Tue Sep 13 10:33:10 2011 +0100 IRQ: IO-APIC support End Of Interrupt for older IO-APICs The old io_apic_eoi() function using the EOI register only works for IO-APICs with a version of 0x20. Older IO-APICs do not have an EOI register so line level interrupts have to be EOI'd by flipping the mode to edge and back, which clears the IRR and Delivery Status bits. This patch replaces the current io_apic_eoi() function with one which takes into account the version of the IO-APIC and EOI's appropriately. v2: make recursive call to __io_apic_eoi() to reduce code size. Signed-off-by: Andrew Cooper changeset: 23832:ad3b4bb097cb user: Stefano Stabellini date: Tue Sep 13 10:32:24 2011 +0100 xen: if mapping GSIs we run out of pirq < nr_irqs_gsi, use the others PV on HVM guests can have more GSIs than the host, in that case we could run out of pirq < nr_irqs_gsi. When that happens use pirq >= nr_irqs_gsi rather than returning an error. Signed-off-by: Stefano Stabellini Tested-by: Benjamin Schweikert changeset: 23831:53416e7c0529 user: Stefano Stabellini date: Tue Sep 13 10:30:09 2011 +0100 Clone and build Seabios by default Signed-off-by: Stefano Stabellini changeset: 23830:1b80eaeeba7b user: Stefano Stabellini date: Tue Sep 13 10:29:14 2011 +0100 Clone and build upstream Qemu by default Signed-off-by: Stefano Stabellini changeset: 23829:9a541243aeaf user: Stefano Stabellini date: Tue Sep 13 10:27:53 2011 +0100 Rename ioemu-dir as qemu-xen-traditional-dir Signed-off-by: Stefano Stabellini changeset: 23828:0d21b68f528b user: Stefano Stabellini date: Tue Sep 13 10:27:20 2011 +0100 Move the ioemu-dir-find shell script to an external file Add support for configuring upstream qemu and rename ioemu-remote ioemu-dir-remote. Signed-off-by: Stefano Stabellini changeset: 23827:d1d6abc1db20 user: Olaf Hering date: Tue Sep 13 10:25:32 2011 +0100 xenpaging: use batch of pages during final page-in Map up to RING_SIZE pages in exit path to fill the ring instead of populating one page at a time. Signed-off-by: Olaf Hering changeset: 23826:ad958e87db79 user: Ian Campbell date: Tue Sep 13 10:22:03 2011 +0100 hvmloader: don't clear acpi_info after filling in some fields In particular the madt_lapic0_addr and madt_csum_addr fields are filled in while building the tables. This fixes a bluescreen on shutdown with certain versions of Windows. Signed-off-by: Ian Campbell Reported-by: Christoph Egger Tested-and-acked-by: Christoph Egger changeset: 23825:0312575dc35e user: Tim Deegan date: Thu Sep 08 15:13:06 2011 +0100 x86/mm: use new page-order interfaces in nested HAP code to make 2M and 1G mappings in the nested p2m tables. Signed-off-by: Christoph Egger Signed-off-by: Tim Deegan Committed-by: Tim Deegan ======================================== commit cd776ee9408ff127f934a707c1a339ee600bc127 Author: Ian Jackson Date: Tue Jun 28 13:50:53 2011 +0100 qemu-char.c: fix incorrect CONFIG_STUBDOM handling qemu-char.c:1123:7: warning: "CONFIG_STUBDOM" is not defined [-Wundef] Signed-off-by: Olaf Hering Acked-by: Ian Jackson _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel From xen-devel-bounces@lists.xensource.com Tue Sep 13 11:42:21 2011 Return-path: Envelope-to: www-data@lists.xensource.com Delivery-date: Tue, 13 Sep 2011 11:42:21 -0700 Received: from localhost ([127.0.0.1] helo=lists.colo.xensource.com) by lists.xensource.com with esmtp (Exim 4.43) id 1R3Xw3-00044N-KD; Tue, 13 Sep 2011 11:42:19 -0700 Received: from mail182.messagelabs.com ([85.158.139.83]) by lists.xensource.com with smtp (Exim 4.43) id 1R3XvB-0003rT-8N for xen-devel@lists.xensource.com; Tue, 13 Sep 2011 11:41:27 -0700 X-Env-Sender: dzickus@redhat.com X-Msg-Ref: server-12.tower-182.messagelabs.com!1315939281!18044668!1 X-Originating-IP: [209.132.183.28] X-StarScan-Version: 6.3.6; banners=-,-,- X-VirusChecked: Checked Received: (qmail 7367 invoked from network); 13 Sep 2011 18:41:21 -0000 Received: from mx1.redhat.com (HELO mx1.redhat.com) (209.132.183.28) by server-12.tower-182.messagelabs.com with SMTP; 13 Sep 2011 18:41:21 -0000 Received: from int-mx01.intmail.prod.int.phx2.redhat.com (int-mx01.intmail.prod.int.phx2.redhat.com [10.5.11.11]) by mx1.redhat.com (8.14.4/8.14.4) with ESMTP id p8DIemeH013071 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Tue, 13 Sep 2011 14:40:48 -0400 Received: from redhat.com (dhcp-100-19-141.bos.redhat.com [10.16.19.141]) by int-mx01.intmail.prod.int.phx2.redhat.com (8.13.8/8.13.8) with SMTP id p8DIei7v005459; Tue, 13 Sep 2011 14:40:44 -0400 Date: Tue, 13 Sep 2011 14:40:44 -0400 From: Don Zickus To: Avi Kivity Message-ID: <20110913184044.GN5795@redhat.com> References: <20110906151408.GA7459@redhat.com> <4E66615E.8070806@goop.org> <20110906182758.GR5795@redhat.com> <4E66EF86.9070200@redhat.com> <20110907134411.GV5795@redhat.com> <4E678992.5050709@redhat.com> <20110907155657.GX5795@redhat.com> <4E679AF4.50209@redhat.com> <20110907165203.GQ6838@redhat.com> <4E67A551.4000502@redhat.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <4E67A551.4000502@redhat.com> User-Agent: Mutt/1.5.21 (2010-09-15) X-Scanned-By: MIMEDefang 2.67 on 10.5.11.11 Cc: Jeremy Fitzhardinge , Marcelo Tosatti , Nick Piggin , KVM , Stefano Stabellini , Peter Zijlstra , the arch/x86 maintainers , Linux Kernel Mailing List , Andi Kleen , Jeremy Fitzhardinge , "H. Peter Anvin" , Ingo Molnar , Linus Torvalds , Xen Devel Subject: [Xen-devel] Re: [PATCH 08/13] xen/pvticketlock: disable interrupts while blocking X-BeenThere: xen-devel@lists.xensource.com X-Mailman-Version: 2.1.5 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xensource.com Errors-To: xen-devel-bounces@lists.xensource.com On Wed, Sep 07, 2011 at 08:09:37PM +0300, Avi Kivity wrote: > >But then the downside > >here is we accidentally handle an NMI that was latched. This would cause > >a 'Dazed on confused' message as that NMI was already handled by the > >previous NMI. > > > >We are working on an algorithm to detect this condition and flag it > >(nothing complicated). But it may never be perfect. > > > >On the other hand, what else are we going to do with an edge-triggered > >shared interrupt line? > > > > How about, during NMI, save %rip to a per-cpu variable. Handle just > one cause. If, on the next NMI, we hit the same %rip, assume > back-to-back NMI has occured and now handle all causes. So I got around to implementing this and it seems to work great. The back to back NMIs are detected properly using the %rip and that info is passed to the NMI notifier. That info is used to determine if only the first handler to report 'handled' is executed or _all_ the handlers are executed. I think all the 'unknown' NMIs I generated with various perf runs have disappeared. I'll post a new version of my nmi notifier rewrite soon. Thanks for the great suggestion Avi! Cheers, Don _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel From xen-devel-bounces@lists.xensource.com Tue Sep 13 12:05:59 2011 Return-path: Envelope-to: www-data@lists.xensource.com Delivery-date: Tue, 13 Sep 2011 12:05:59 -0700 Received: from localhost ([127.0.0.1] helo=lists.colo.xensource.com) by lists.xensource.com with esmtp (Exim 4.43) id 1R3YIw-0005kA-Es; Tue, 13 Sep 2011 12:05:58 -0700 Received: from mail21.messagelabs.com ([85.158.143.35]) by lists.xensource.com with esmtp (Exim 4.43) id 1R3YGU-0005Gk-Nf for xen-devel@lists.xensource.com; Tue, 13 Sep 2011 12:03:28 -0700 X-Env-Sender: andi@firstfloor.org X-Msg-Ref: server-6.tower-21.messagelabs.com!1315940584!38112162!1 X-Originating-IP: [213.235.205.2] X-StarScan-Version: 6.4.1; banners=-,-,- X-VirusChecked: Checked Received: (qmail 16215 invoked from network); 13 Sep 2011 19:03:04 -0000 Received: from one.firstfloor.org (HELO one.firstfloor.org) (213.235.205.2) by server-6.tower-21.messagelabs.com with DHE-RSA-AES256-SHA encrypted SMTP; 13 Sep 2011 19:03:04 -0000 Received: by one.firstfloor.org (Postfix, from userid 503) id ADD531A980C9; Tue, 13 Sep 2011 21:03:20 +0200 (CEST) Date: Tue, 13 Sep 2011 21:03:20 +0200 From: Andi Kleen To: Don Zickus Message-ID: <20110913190320.GR7761@one.firstfloor.org> References: <4E66615E.8070806@goop.org> <20110906182758.GR5795@redhat.com> <4E66EF86.9070200@redhat.com> <20110907134411.GV5795@redhat.com> <4E678992.5050709@redhat.com> <20110907155657.GX5795@redhat.com> <4E679AF4.50209@redhat.com> <20110907165203.GQ6838@redhat.com> <4E67A551.4000502@redhat.com> <20110913184044.GN5795@redhat.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20110913184044.GN5795@redhat.com> User-Agent: Mutt/1.4.2.2i Cc: Jeremy Fitzhardinge , Marcelo Tosatti , Nick Piggin , KVM , Stefano Stabellini , Peter Zijlstra , the arch/x86 maintainers , Linux Kernel Mailing List , Andi Kleen , Avi Kivity , Jeremy Fitzhardinge , "H. Peter Anvin" , Ingo Molnar , Linus Torvalds , Xen Devel Subject: [Xen-devel] Re: [PATCH 08/13] xen/pvticketlock: disable interrupts while blocking X-BeenThere: xen-devel@lists.xensource.com X-Mailman-Version: 2.1.5 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xensource.com Errors-To: xen-devel-bounces@lists.xensource.com > So I got around to implementing this and it seems to work great. The back > to back NMIs are detected properly using the %rip and that info is passed to > the NMI notifier. That info is used to determine if only the first > handler to report 'handled' is executed or _all_ the handlers are > executed. > > I think all the 'unknown' NMIs I generated with various perf runs have > disappeared. I'll post a new version of my nmi notifier rewrite soon. This will fail when the system is idle. -Andi _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel From xen-devel-bounces@lists.xensource.com Tue Sep 13 12:08:11 2011 Return-path: Envelope-to: www-data@lists.xensource.com Delivery-date: Tue, 13 Sep 2011 12:08:11 -0700 Received: from localhost ([127.0.0.1] helo=lists.colo.xensource.com) by lists.xensource.com with esmtp (Exim 4.43) id 1R3YL5-00069a-52; Tue, 13 Sep 2011 12:08:11 -0700 Received: from mail21.messagelabs.com ([85.158.143.35]) by lists.xensource.com with esmtp (Exim 4.43) id 1R3YKW-0005ww-2u for xen-devel@lists.xensource.com; Tue, 13 Sep 2011 12:07:36 -0700 X-Env-Sender: Ian.Jackson@eu.citrix.com X-Msg-Ref: server-4.tower-21.messagelabs.com!1315940818!60085465!1 X-Originating-IP: [62.200.22.115] X-StarScan-Version: 6.4.1; banners=-,-,- X-VirusChecked: Checked Received: (qmail 30406 invoked from network); 13 Sep 2011 19:06:58 -0000 Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115) by server-4.tower-21.messagelabs.com with RC4-SHA encrypted SMTP; 13 Sep 2011 19:06:58 -0000 X-IronPort-AV: E=Sophos;i="4.68,375,1312156800"; d="scan'208";a="7776325" Received: from lonpmailmx01.citrite.net ([10.30.203.162]) by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5; 13 Sep 2011 19:07:32 +0000 Received: from woking.xci-test.com (10.80.248.135) by smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id 8.3.137.0; Tue, 13 Sep 2011 20:07:31 +0100 Received: from osstest by woking.xci-test.com with local (Exim 4.69) (envelope-from ) id 1R3YKR-0007YQ-Qp; Tue, 13 Sep 2011 20:07:31 +0100 To: Message-ID: From: xen.org Date: Tue, 13 Sep 2011 20:07:31 +0100 MIME-Version: 1.0 Content-Type: text/plain Cc: ian.jackson@eu.citrix.com, keir@xen.org, stefano.stabellini@eu.citrix.com Subject: [Xen-devel] [xen-unstable bisection] complete build-i386 X-BeenThere: xen-devel@lists.xensource.com X-Mailman-Version: 2.1.5 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xensource.com Errors-To: xen-devel-bounces@lists.xensource.com branch xen-unstable xen branch xen-unstable job build-i386 test xen-build Tree: xen http://hg.uk.xensource.com/xen-unstable.hg *** Found and reproduced problem changeset *** Bug is in tree: xen http://hg.uk.xensource.com/xen-unstable.hg Bug introduced: 0d21b68f528b Bug not present: d1d6abc1db20 changeset: 23828:0d21b68f528b user: Stefano Stabellini date: Tue Sep 13 10:27:20 2011 +0100 Move the ioemu-dir-find shell script to an external file Add support for configuring upstream qemu and rename ioemu-remote ioemu-dir-remote. Signed-off-by: Stefano Stabellini For bisection revision-tuple graph see: http://www.chiark.greenend.org.uk/~xensrcts/results/bisect.xen-unstable.build-i386.xen-build.html Revision IDs in each graph node refer, respectively, to the Trees above. ---------------------------------------- Searching for failure / basis pass: 8895 fail [host=lace-bug] / 8873 ok. Failure / basis pass flights: 8895 / 8873 (tree in basispass but not in latest: qemu) Tree: xen http://hg.uk.xensource.com/xen-unstable.hg Latest 51913fe3d25a Basis pass 0312575dc35e Generating revisions with ./adhoc-revtuple-generator http://hg.uk.xensource.com/xen-unstable.hg#0312575dc35e-51913fe3d25a pulling from http://hg.uk.xensource.com/xen-unstable.hg searching for changes no changes found pulling from http://hg.uk.xensource.com/xen-unstable.hg searching for changes no changes found Loaded 1001 nodes in revision graph Searching for test results: 8865 [host=itch-mite] 8869 [host=woodlouse] 8870 [host=woodlouse] 8871 [host=woodlouse] 8872 pass 0312575dc35e 8873 pass 0312575dc35e 8901 pass d1d6abc1db20 8876 [host=woodlouse] 8904 fail 0d21b68f528b 8884 fail e564f2f1b737 8890 pass 0312575dc35e 8891 fail e564f2f1b737 8892 fail 1b80eaeeba7b 8893 pass d1d6abc1db20 8896 fail 0d21b68f528b 8895 fail 51913fe3d25a 8897 pass d1d6abc1db20 8898 pass 0312575dc35e 8899 fail 51913fe3d25a 8900 fail 0d21b68f528b Searching for interesting versions Result found: flight 8872 (pass), for basis pass Result found: flight 8895 (fail), for basis failure Repro found: flight 8898 (pass), for basis pass Repro found: flight 8899 (fail), for basis failure 0 revisions at d1d6abc1db20 No revisions left to test, checking graph state. Result found: flight 8893 (pass), for last pass Result found: flight 8896 (fail), for first failure Repro found: flight 8897 (pass), for last pass Repro found: flight 8900 (fail), for first failure Repro found: flight 8901 (pass), for last pass Repro found: flight 8904 (fail), for first failure *** Found and reproduced problem changeset *** Bug is in tree: xen http://hg.uk.xensource.com/xen-unstable.hg Bug introduced: 0d21b68f528b Bug not present: d1d6abc1db20 pulling from http://hg.uk.xensource.com/xen-unstable.hg searching for changes no changes found changeset: 23828:0d21b68f528b user: Stefano Stabellini date: Tue Sep 13 10:27:20 2011 +0100 Move the ioemu-dir-find shell script to an external file Add support for configuring upstream qemu and rename ioemu-remote ioemu-dir-remote. Signed-off-by: Stefano Stabellini Revision graph left in /home/xc_osstest/results/bisect.xen-unstable.build-i386.xen-build.{dot,ps,png,html}. ---------------------------------------- 8904: ALL FAIL flight 8904 xen-unstable real-bisect [real] http://www.chiark.greenend.org.uk/~xensrcts/logs/8904/ jobs: build-i386 fail ------------------------------------------------------------ sg-report-flight on woking.cam.xci-test.com logs: /home/xc_osstest/logs images: /home/xc_osstest/images Logs, config files, etc. are available at http://www.chiark.greenend.org.uk/~xensrcts/logs Test harness code can be found at http://xenbits.xensource.com/gitweb?p=osstest.git;a=summary _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel From xen-devel-bounces@lists.xensource.com Tue Sep 13 12:28:11 2011 Return-path: Envelope-to: www-data@lists.xensource.com Delivery-date: Tue, 13 Sep 2011 12:28:11 -0700 Received: from localhost ([127.0.0.1] helo=lists.colo.xensource.com) by lists.xensource.com with esmtp (Exim 4.43) id 1R3YeR-0006p0-2R; Tue, 13 Sep 2011 12:28:11 -0700 Received: from mail182.messagelabs.com ([85.158.139.83]) by lists.xensource.com with smtp (Exim 4.43) id 1R3Ydz-0006bd-28 for xen-devel@lists.xensource.com; Tue, 13 Sep 2011 12:27:43 -0700 X-Env-Sender: dzickus@redhat.com X-Msg-Ref: server-11.tower-182.messagelabs.com!1315942059!18204736!1 X-Originating-IP: [209.132.183.28] X-StarScan-Version: 6.3.6; banners=-,-,- X-VirusChecked: Checked Received: (qmail 2548 invoked from network); 13 Sep 2011 19:27:39 -0000 Received: from mx1.redhat.com (HELO mx1.redhat.com) (209.132.183.28) by server-11.tower-182.messagelabs.com with SMTP; 13 Sep 2011 19:27:39 -0000 Received: from int-mx12.intmail.prod.int.phx2.redhat.com (int-mx12.intmail.prod.int.phx2.redhat.com [10.5.11.25]) by mx1.redhat.com (8.14.4/8.14.4) with ESMTP id p8DJR8Ec006485 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Tue, 13 Sep 2011 15:27:08 -0400 Received: from redhat.com (dhcp-100-19-141.bos.redhat.com [10.16.19.141]) by int-mx12.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with SMTP id p8DJR6Qr003912; Tue, 13 Sep 2011 15:27:06 -0400 Date: Tue, 13 Sep 2011 15:27:06 -0400 From: Don Zickus To: Andi Kleen Message-ID: <20110913192706.GP5795@redhat.com> References: <20110906182758.GR5795@redhat.com> <4E66EF86.9070200@redhat.com> <20110907134411.GV5795@redhat.com> <4E678992.5050709@redhat.com> <20110907155657.GX5795@redhat.com> <4E679AF4.50209@redhat.com> <20110907165203.GQ6838@redhat.com> <4E67A551.4000502@redhat.com> <20110913184044.GN5795@redhat.com> <20110913190320.GR7761@one.firstfloor.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20110913190320.GR7761@one.firstfloor.org> User-Agent: Mutt/1.5.21 (2010-09-15) X-Scanned-By: MIMEDefang 2.68 on 10.5.11.25 Cc: Jeremy Fitzhardinge , Marcelo Tosatti , Nick Piggin , KVM , Stefano Stabellini , Peter Zijlstra , the arch/x86 maintainers , Linux Kernel Mailing List , Xen Devel , Avi Kivity , Jeremy Fitzhardinge , "H. Peter Anvin" , Ingo Molnar , Linus Torvalds Subject: [Xen-devel] Re: [PATCH 08/13] xen/pvticketlock: disable interrupts while blocking X-BeenThere: xen-devel@lists.xensource.com X-Mailman-Version: 2.1.5 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xensource.com Errors-To: xen-devel-bounces@lists.xensource.com On Tue, Sep 13, 2011 at 09:03:20PM +0200, Andi Kleen wrote: > > So I got around to implementing this and it seems to work great. The back > > to back NMIs are detected properly using the %rip and that info is passed to > > the NMI notifier. That info is used to determine if only the first > > handler to report 'handled' is executed or _all_ the handlers are > > executed. > > > > I think all the 'unknown' NMIs I generated with various perf runs have > > disappeared. I'll post a new version of my nmi notifier rewrite soon. > > This will fail when the system is idle. Oh one other thing I forgot to mention is that an NMI handler has to return a value greater than 1, meaning that it handle multiple NMI events during this NMI to even enable the 'NMI swallowing' algorithm. Cheers, Don _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel From xen-devel-bounces@lists.xensource.com Tue Sep 13 12:30:47 2011 Return-path: Envelope-to: www-data@lists.xensource.com Delivery-date: Tue, 13 Sep 2011 12:30:47 -0700 Received: from localhost ([127.0.0.1] helo=lists.colo.xensource.com) by lists.xensource.com with esmtp (Exim 4.43) id 1R3Ygw-0007Fb-H5; Tue, 13 Sep 2011 12:30:46 -0700 Received: from mail21.messagelabs.com ([85.158.143.35]) by lists.xensource.com with esmtp (Exim 4.43) id 1R3YgS-00073L-N5 for xen-devel@lists.xensource.com; Tue, 13 Sep 2011 12:30:17 -0700 X-Env-Sender: xenlist@suykerbuyk.org X-Msg-Ref: server-3.tower-21.messagelabs.com!1315942223!51437573!1 X-Originating-IP: [216.139.236.26] X-StarScan-Version: 6.4.1; banners=-,-,- X-VirusChecked: Checked Received: (qmail 14665 invoked from network); 13 Sep 2011 19:30:25 -0000 Received: from sam.nabble.com (HELO sam.nabble.com) (216.139.236.26) by server-3.tower-21.messagelabs.com with AES256-SHA encrypted SMTP; 13 Sep 2011 19:30:25 -0000 Received: from [192.168.236.26] (helo=sam.nabble.com) by sam.nabble.com with esmtp (Exim 4.72) (envelope-from ) id 1R3YgN-0006OU-Vg for xen-devel@lists.xensource.com; Tue, 13 Sep 2011 12:30:11 -0700 Date: Tue, 13 Sep 2011 12:30:11 -0700 (PDT) From: JohnSuykerbuyk To: xen-devel@lists.xensource.com Message-ID: <1315942211975-4799764.post@n5.nabble.com> In-Reply-To: <1315930910700-4799120.post@n5.nabble.com> References: <20110912145843.GB15778@oracle.com> <1315859925763-4795821.post@n5.nabble.com> <20110912211640.GA14805@phenom.oracle.com> <1315930910700-4799120.post@n5.nabble.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Subject: [Xen-devel] Re: git.kernel.org X-BeenThere: xen-devel@lists.xensource.com X-Mailman-Version: 2.1.5 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xensource.com Errors-To: xen-devel-bounces@lists.xensource.com And the answer is.... Searching the xen mailing list for the past month, I see Jeremy has moved his archive to: https://github.com/jsgf/linux-xen Hope this helps the next guy. -- View this message in context: http://xen.1045712.n5.nabble.com/git-kernel-org-tp4792977p4799764.html Sent from the Xen - Dev mailing list archive at Nabble.com. _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel From xen-devel-bounces@lists.xensource.com Tue Sep 13 12:33:13 2011 Return-path: Envelope-to: www-data@lists.xensource.com Delivery-date: Tue, 13 Sep 2011 12:33:13 -0700 Received: from localhost ([127.0.0.1] helo=lists.colo.xensource.com) by lists.xensource.com with esmtp (Exim 4.43) id 1R3YjI-0007eI-DN; Tue, 13 Sep 2011 12:33:12 -0700 Received: from mail216.messagelabs.com ([85.158.143.99]) by lists.xensource.com with smtp (Exim 4.43) id 1R3YiV-0007RV-I5 for xen-devel@lists.xensource.com; Tue, 13 Sep 2011 12:32:23 -0700 X-Env-Sender: dzickus@redhat.com X-Msg-Ref: server-8.tower-216.messagelabs.com!1315942339!16619115!1 X-Originating-IP: [209.132.183.28] X-StarScan-Version: 6.3.6; banners=-,-,- X-VirusChecked: Checked Received: (qmail 21761 invoked from network); 13 Sep 2011 19:32:19 -0000 Received: from mx1.redhat.com (HELO mx1.redhat.com) (209.132.183.28) by server-8.tower-216.messagelabs.com with SMTP; 13 Sep 2011 19:32:19 -0000 Received: from int-mx12.intmail.prod.int.phx2.redhat.com (int-mx12.intmail.prod.int.phx2.redhat.com [10.5.11.25]) by mx1.redhat.com (8.14.4/8.14.4) with ESMTP id p8DJVqJI031115 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Tue, 13 Sep 2011 15:31:58 -0400 Received: from redhat.com (dhcp-100-19-141.bos.redhat.com [10.16.19.141]) by int-mx12.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with SMTP id p8DJLqMd002117; Tue, 13 Sep 2011 15:21:52 -0400 Date: Tue, 13 Sep 2011 15:21:52 -0400 From: Don Zickus To: Andi Kleen Message-ID: <20110913192152.GO5795@redhat.com> References: <20110906182758.GR5795@redhat.com> <4E66EF86.9070200@redhat.com> <20110907134411.GV5795@redhat.com> <4E678992.5050709@redhat.com> <20110907155657.GX5795@redhat.com> <4E679AF4.50209@redhat.com> <20110907165203.GQ6838@redhat.com> <4E67A551.4000502@redhat.com> <20110913184044.GN5795@redhat.com> <20110913190320.GR7761@one.firstfloor.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20110913190320.GR7761@one.firstfloor.org> User-Agent: Mutt/1.5.21 (2010-09-15) X-Scanned-By: MIMEDefang 2.68 on 10.5.11.25 Cc: Jeremy Fitzhardinge , Marcelo Tosatti , Nick Piggin , KVM , Stefano Stabellini , Peter Zijlstra , the arch/x86 maintainers , Linux Kernel Mailing List , Xen Devel , Avi Kivity , Jeremy Fitzhardinge , "H. Peter Anvin" , Ingo Molnar , Linus Torvalds Subject: [Xen-devel] Re: [PATCH 08/13] xen/pvticketlock: disable interrupts while blocking X-BeenThere: xen-devel@lists.xensource.com X-Mailman-Version: 2.1.5 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xensource.com Errors-To: xen-devel-bounces@lists.xensource.com On Tue, Sep 13, 2011 at 09:03:20PM +0200, Andi Kleen wrote: > > So I got around to implementing this and it seems to work great. The back > > to back NMIs are detected properly using the %rip and that info is passed to > > the NMI notifier. That info is used to determine if only the first > > handler to report 'handled' is executed or _all_ the handlers are > > executed. > > > > I think all the 'unknown' NMIs I generated with various perf runs have > > disappeared. I'll post a new version of my nmi notifier rewrite soon. > > This will fail when the system is idle. Heh. I don't think I explained what I was doing properly. I had a bunch of perf runs going simultaneously on my Core2quad. Probably generated around 40,000 NMIs in a few minutes. I think around a 1000 or so detected back-to-back NMIs. With the current NMI detection algorithm in perf to determine back-to-back NMIs, I can usually use the above scenario to generate an 'unknown' NMI. Actually numerous ones before the box freezes. It is a false positive. With my current code and Avi's idea, all those disappeared as they are now 'swallowed' by the algorithm. That seemed like a positive. However, being cautious, I decided to instrument lkdtm to inject NMIs to force unknown NMI conditions (apic->send_IPI_mask(cpumask_of(smp_processor_id(), NMI_VECTOR))) I tried to inject the NMIs while my trace_printk buffer was flooding my screen with 'back-to-back NMIs detected'. I did this 4 or 5 times and every single one of them were detected as an 'unknown' NMI. So this was good too, in the sense it was not swallowing 'real' unknown NMIs. Does that make sense? Or are you saying an NMI in an idle system will have the same %rip thus falsely detecting a back-to-back NMI? Cheers, Don > > -Andi > _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel From xen-devel-bounces@lists.xensource.com Tue Sep 13 12:37:26 2011 Return-path: Envelope-to: www-data@lists.xensource.com Delivery-date: Tue, 13 Sep 2011 12:37:26 -0700 Received: from localhost ([127.0.0.1] helo=lists.colo.xensource.com) by lists.xensource.com with esmtp (Exim 4.43) id 1R3YnN-0008Ae-Va; Tue, 13 Sep 2011 12:37:25 -0700 Received: from mail182.messagelabs.com ([85.158.139.83]) by lists.xensource.com with esmtp (Exim 4.43) id 1R3Ymc-0007vh-Mc for xen-devel@lists.xensource.com; Tue, 13 Sep 2011 12:36:39 -0700 X-Env-Sender: Ian.Jackson@eu.citrix.com X-Msg-Ref: server-12.tower-182.messagelabs.com!1315942595!18048159!1 X-Originating-IP: [62.200.22.115] X-StarScan-Version: 6.3.6; banners=-,-,- X-VirusChecked: Checked Received: (qmail 11738 invoked from network); 13 Sep 2011 19:36:35 -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; 13 Sep 2011 19:36:35 -0000 X-IronPort-AV: E=Sophos;i="4.68,375,1312156800"; d="scan'208";a="7777017" Received: from lonpmailmx01.citrite.net ([10.30.203.162]) by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5; 13 Sep 2011 19:36:35 +0000 Received: from woking.xci-test.com (10.80.248.135) by smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id 8.3.137.0; Tue, 13 Sep 2011 20:36:35 +0100 Received: from osstest by woking.xci-test.com with local (Exim 4.69) (envelope-from ) id 1R3YmZ-000863-6B; Tue, 13 Sep 2011 20:36:35 +0100 To: xen-devel@lists.xensource.com Message-ID: From: xen.org Date: Tue, 13 Sep 2011 20:36:35 +0100 MIME-Version: 1.0 Content-Type: text/plain Cc: ian.jackson@eu.citrix.com Subject: [Xen-devel] [xen-unstable test] 8903: regressions - trouble: blocked/fail X-BeenThere: xen-devel@lists.xensource.com X-Mailman-Version: 2.1.5 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xensource.com Errors-To: xen-devel-bounces@lists.xensource.com flight 8903 xen-unstable real [real] http://www.chiark.greenend.org.uk/~xensrcts/logs/8903/ Regressions :-( Tests which did not succeed and are blocking: build-amd64 4 xen-build fail REGR. vs. 8873 build-i386 4 xen-build fail REGR. vs. 8873 build-i386-oldkern 4 xen-build fail REGR. vs. 8873 build-amd64-oldkern 4 xen-build fail REGR. vs. 8873 Tests which did not succeed, but are not blocking, including regressions (tests previously passed) regarded as allowable: test-amd64-amd64-xl-pcipt-intel 1 xen-build-check(1) blocked n/a test-amd64-i386-rhel6hvm-intel 1 xen-build-check(1) blocked n/a test-i386-i386-pv 1 xen-build-check(1) blocked n/a test-amd64-i386-pv 1 xen-build-check(1) blocked n/a test-amd64-amd64-pv 1 xen-build-check(1) blocked n/a test-i386-i386-xl 1 xen-build-check(1) blocked n/a test-amd64-i386-xl 1 xen-build-check(1) blocked n/a test-amd64-i386-xl-credit2 1 xen-build-check(1) blocked n/a test-amd64-i386-rhel6hvm-amd 1 xen-build-check(1) blocked n/a test-amd64-amd64-pair 1 xen-build-check(1) blocked n/a test-amd64-i386-pair 1 xen-build-check(1) blocked n/a test-i386-i386-pair 1 xen-build-check(1) blocked n/a build-amd64-pvops 4 kernel-build fail like 8873 build-i386-pvops 4 kernel-build fail like 8873 test-amd64-i386-xl-multivcpu 1 xen-build-check(1) blocked n/a test-amd64-amd64-xl-sedf 1 xen-build-check(1) blocked n/a test-amd64-i386-win-vcpus1 1 xen-build-check(1) blocked n/a test-amd64-i386-xl-win-vcpus1 1 xen-build-check(1) blocked n/a test-amd64-amd64-win 1 xen-build-check(1) blocked n/a test-amd64-i386-win 1 xen-build-check(1) blocked n/a test-amd64-amd64-xl-win 1 xen-build-check(1) blocked n/a test-amd64-amd64-xl 1 xen-build-check(1) blocked n/a test-i386-i386-xl-win 1 xen-build-check(1) blocked n/a test-i386-i386-win 1 xen-build-check(1) blocked n/a version targeted for testing: xen 51913fe3d25a baseline version: xen 0312575dc35e ------------------------------------------------------------ People who touched revisions under test: Andrew Cooper Benjamin Schweikert Christoph Egger George Dunlap Ian Campbell Ian Jackson Keir Fraser Olaf Hering Stefano Stabellini Tim Deegan ------------------------------------------------------------ jobs: build-amd64 fail build-i386 fail build-amd64-oldkern fail build-i386-oldkern fail build-amd64-pvops fail build-i386-pvops fail test-amd64-amd64-xl blocked test-amd64-i386-xl blocked test-i386-i386-xl blocked test-amd64-i386-rhel6hvm-amd blocked test-amd64-i386-xl-credit2 blocked test-amd64-amd64-xl-pcipt-intel blocked test-amd64-i386-rhel6hvm-intel blocked test-amd64-i386-xl-multivcpu blocked test-amd64-amd64-pair blocked test-amd64-i386-pair blocked test-i386-i386-pair blocked test-amd64-amd64-pv blocked test-amd64-i386-pv blocked test-i386-i386-pv blocked test-amd64-amd64-xl-sedf blocked test-amd64-i386-win-vcpus1 blocked test-amd64-i386-xl-win-vcpus1 blocked test-amd64-amd64-win blocked test-amd64-i386-win blocked test-i386-i386-win blocked test-amd64-amd64-xl-win blocked test-i386-i386-xl-win blocked ------------------------------------------------------------ sg-report-flight on woking.cam.xci-test.com logs: /home/xc_osstest/logs images: /home/xc_osstest/images Logs, config files, etc. are available at http://www.chiark.greenend.org.uk/~xensrcts/logs Test harness code can be found at http://xenbits.xensource.com/gitweb?p=osstest.git;a=summary Not pushing. ------------------------------------------------------------ changeset: 23837:51913fe3d25a tag: tip user: Stefano Stabellini date: Tue Sep 13 15:46:47 2011 +0100 fix the build when CONFIG_QEMU is specified by the user Signed-off-by: Stefano Stabellini Committed-by: Stefano Stabellini changeset: 23836:e564f2f1b737 user: Ian Jackson date: Tue Sep 13 14:52:22 2011 +0100 tools: fix permissions of git-checkout.sh 23828:0d21b68f528b introduced a new scripts/git-checkout.sh, but it had the wrong permissions. chmod +x it, and add a blank line at the end to make sure it actually gets updated. Signed-off-by: Ian Jackson changeset: 23835:64aab9a077ea user: Keir Fraser date: Tue Sep 13 11:20:57 2011 +0100 scripts/git-checkout.sh: Is not bash specific. Invoke with /bin/sh. Signed-off-by: Keir Fraser changeset: 23834:1d40b2793723 user: George Dunlap date: Tue Sep 13 10:43:43 2011 +0100 xen,credit1: Add variable timeslice Add a xen command-line parameter, sched_credit_tslice_ms, to set the timeslice of the credit1 scheduler. Signed-off-by: George Dunlap changeset: 23833:ffe8e65f6687 user: Andrew Cooper date: Tue Sep 13 10:33:10 2011 +0100 IRQ: IO-APIC support End Of Interrupt for older IO-APICs The old io_apic_eoi() function using the EOI register only works for IO-APICs with a version of 0x20. Older IO-APICs do not have an EOI register so line level interrupts have to be EOI'd by flipping the mode to edge and back, which clears the IRR and Delivery Status bits. This patch replaces the current io_apic_eoi() function with one which takes into account the version of the IO-APIC and EOI's appropriately. v2: make recursive call to __io_apic_eoi() to reduce code size. Signed-off-by: Andrew Cooper changeset: 23832:ad3b4bb097cb user: Stefano Stabellini date: Tue Sep 13 10:32:24 2011 +0100 xen: if mapping GSIs we run out of pirq < nr_irqs_gsi, use the others PV on HVM guests can have more GSIs than the host, in that case we could run out of pirq < nr_irqs_gsi. When that happens use pirq >= nr_irqs_gsi rather than returning an error. Signed-off-by: Stefano Stabellini Tested-by: Benjamin Schweikert changeset: 23831:53416e7c0529 user: Stefano Stabellini date: Tue Sep 13 10:30:09 2011 +0100 Clone and build Seabios by default Signed-off-by: Stefano Stabellini changeset: 23830:1b80eaeeba7b user: Stefano Stabellini date: Tue Sep 13 10:29:14 2011 +0100 Clone and build upstream Qemu by default Signed-off-by: Stefano Stabellini changeset: 23829:9a541243aeaf user: Stefano Stabellini date: Tue Sep 13 10:27:53 2011 +0100 Rename ioemu-dir as qemu-xen-traditional-dir Signed-off-by: Stefano Stabellini changeset: 23828:0d21b68f528b user: Stefano Stabellini date: Tue Sep 13 10:27:20 2011 +0100 Move the ioemu-dir-find shell script to an external file Add support for configuring upstream qemu and rename ioemu-remote ioemu-dir-remote. Signed-off-by: Stefano Stabellini changeset: 23827:d1d6abc1db20 user: Olaf Hering date: Tue Sep 13 10:25:32 2011 +0100 xenpaging: use batch of pages during final page-in Map up to RING_SIZE pages in exit path to fill the ring instead of populating one page at a time. Signed-off-by: Olaf Hering changeset: 23826:ad958e87db79 user: Ian Campbell date: Tue Sep 13 10:22:03 2011 +0100 hvmloader: don't clear acpi_info after filling in some fields In particular the madt_lapic0_addr and madt_csum_addr fields are filled in while building the tables. This fixes a bluescreen on shutdown with certain versions of Windows. Signed-off-by: Ian Campbell Reported-by: Christoph Egger Tested-and-acked-by: Christoph Egger changeset: 23825:0312575dc35e user: Tim Deegan date: Thu Sep 08 15:13:06 2011 +0100 x86/mm: use new page-order interfaces in nested HAP code to make 2M and 1G mappings in the nested p2m tables. Signed-off-by: Christoph Egger Signed-off-by: Tim Deegan Committed-by: Tim Deegan ======================================== commit cd776ee9408ff127f934a707c1a339ee600bc127 Author: Ian Jackson Date: Tue Jun 28 13:50:53 2011 +0100 qemu-char.c: fix incorrect CONFIG_STUBDOM handling qemu-char.c:1123:7: warning: "CONFIG_STUBDOM" is not defined [-Wundef] Signed-off-by: Olaf Hering Acked-by: Ian Jackson _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel From xen-devel-bounces@lists.xensource.com Tue Sep 13 13:03:58 2011 Return-path: Envelope-to: www-data@lists.xensource.com Delivery-date: Tue, 13 Sep 2011 13:03:59 -0700 Received: from localhost ([127.0.0.1] helo=lists.colo.xensource.com) by lists.xensource.com with esmtp (Exim 4.43) id 1R3ZD3-0000g7-Jq; Tue, 13 Sep 2011 13:03:57 -0700 Received: from mail182.messagelabs.com ([85.158.139.83]) by lists.xensource.com with esmtp (Exim 4.43) id 1R3Z7y-0000Pe-Sk for xen-devel@lists.xensource.com; Tue, 13 Sep 2011 12:58:53 -0700 X-Env-Sender: andi@firstfloor.org X-Msg-Ref: server-4.tower-182.messagelabs.com!1315943918!18203423!1 X-Originating-IP: [213.235.205.2] X-StarScan-Version: 6.3.6; banners=-,-,- X-VirusChecked: Checked Received: (qmail 18492 invoked from network); 13 Sep 2011 19:58:38 -0000 Received: from one.firstfloor.org (HELO one.firstfloor.org) (213.235.205.2) by server-4.tower-182.messagelabs.com with DHE-RSA-AES256-SHA encrypted SMTP; 13 Sep 2011 19:58:38 -0000 Received: by one.firstfloor.org (Postfix, from userid 503) id 173E21ED80AD; Tue, 13 Sep 2011 21:58:38 +0200 (CEST) Date: Tue, 13 Sep 2011 21:58:38 +0200 From: Andi Kleen To: Don Zickus Message-ID: <20110913195838.GS7761@one.firstfloor.org> References: <4E66EF86.9070200@redhat.com> <20110907134411.GV5795@redhat.com> <4E678992.5050709@redhat.com> <20110907155657.GX5795@redhat.com> <4E679AF4.50209@redhat.com> <20110907165203.GQ6838@redhat.com> <4E67A551.4000502@redhat.com> <20110913184044.GN5795@redhat.com> <20110913190320.GR7761@one.firstfloor.org> <20110913192152.GO5795@redhat.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20110913192152.GO5795@redhat.com> User-Agent: Mutt/1.4.2.2i Cc: Jeremy Fitzhardinge , Marcelo Tosatti , Nick Piggin , KVM , Stefano Stabellini , Peter Zijlstra , the arch/x86 maintainers , Linux Kernel Mailing List , Andi Kleen , Avi Kivity , Jeremy Fitzhardinge , "H. Peter Anvin" , Ingo Molnar , Linus Torvalds , Xen Devel Subject: [Xen-devel] Re: [PATCH 08/13] xen/pvticketlock: disable interrupts while blocking X-BeenThere: xen-devel@lists.xensource.com X-Mailman-Version: 2.1.5 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xensource.com Errors-To: xen-devel-bounces@lists.xensource.com > Or are you saying an NMI in an idle system will have the same %rip thus > falsely detecting a back-to-back NMI? Yup. Another problem is very long running instructions, like WBINVD and some others. If there's a high frequency NMI it may well hit multiple times in a single instance. -Andi -- ak@linux.intel.com -- Speaking for myself only. _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel From xen-devel-bounces@lists.xensource.com Tue Sep 13 13:54:41 2011 Return-path: Envelope-to: www-data@lists.xensource.com Delivery-date: Tue, 13 Sep 2011 13:54:41 -0700 Received: from localhost ([127.0.0.1] helo=lists.colo.xensource.com) by lists.xensource.com with esmtp (Exim 4.43) id 1R3a06-0001t9-Td; Tue, 13 Sep 2011 13:54:38 -0700 Received: from mail21.messagelabs.com ([85.158.143.35]) by lists.xensource.com with smtp (Exim 4.43) id 1R3ZzK-0001ga-8g for xen-devel@lists.xensource.com; Tue, 13 Sep 2011 13:53:50 -0700 X-Env-Sender: dzickus@redhat.com X-Msg-Ref: server-4.tower-21.messagelabs.com!1315947191!60091973!1 X-Originating-IP: [209.132.183.28] X-StarScan-Version: 6.4.1; banners=-,-,- X-VirusChecked: Checked Received: (qmail 29702 invoked from network); 13 Sep 2011 20:53:12 -0000 Received: from mx1.redhat.com (HELO mx1.redhat.com) (209.132.183.28) by server-4.tower-21.messagelabs.com with SMTP; 13 Sep 2011 20:53:12 -0000 Received: from int-mx01.intmail.prod.int.phx2.redhat.com (int-mx01.intmail.prod.int.phx2.redhat.com [10.5.11.11]) by mx1.redhat.com (8.14.4/8.14.4) with ESMTP id p8DKrKuR028839 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Tue, 13 Sep 2011 16:53:20 -0400 Received: from redhat.com (dhcp-100-19-141.bos.redhat.com [10.16.19.141]) by int-mx01.intmail.prod.int.phx2.redhat.com (8.13.8/8.13.8) with SMTP id p8DKrITg019894; Tue, 13 Sep 2011 16:53:18 -0400 Date: Tue, 13 Sep 2011 16:53:18 -0400 From: Don Zickus To: Andi Kleen Message-ID: <20110913205318.GQ5795@redhat.com> References: <20110907134411.GV5795@redhat.com> <4E678992.5050709@redhat.com> <20110907155657.GX5795@redhat.com> <4E679AF4.50209@redhat.com> <20110907165203.GQ6838@redhat.com> <4E67A551.4000502@redhat.com> <20110913184044.GN5795@redhat.com> <20110913190320.GR7761@one.firstfloor.org> <20110913192152.GO5795@redhat.com> <20110913195838.GS7761@one.firstfloor.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20110913195838.GS7761@one.firstfloor.org> User-Agent: Mutt/1.5.21 (2010-09-15) X-Scanned-By: MIMEDefang 2.67 on 10.5.11.11 Cc: Jeremy Fitzhardinge , Marcelo Tosatti , Nick Piggin , KVM , Stefano Stabellini , Peter Zijlstra , the arch/x86 maintainers , Linux Kernel Mailing List , Xen Devel , Avi Kivity , Jeremy Fitzhardinge , "H. Peter Anvin" , Ingo Molnar , Linus Torvalds Subject: [Xen-devel] Re: [PATCH 08/13] xen/pvticketlock: disable interrupts while blocking X-BeenThere: xen-devel@lists.xensource.com X-Mailman-Version: 2.1.5 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xensource.com Errors-To: xen-devel-bounces@lists.xensource.com On Tue, Sep 13, 2011 at 09:58:38PM +0200, Andi Kleen wrote: > > Or are you saying an NMI in an idle system will have the same %rip thus > > falsely detecting a back-to-back NMI? > > Yup. Hmm. That sucks. Is there another register that can be used in conjunction to seperate it, like sp or something? Or we can we assume than an idle cpu isn't doing much for local NMI IPIs and that the only NMIs that would interrupt it would be external ones? > > Another problem is very long running instructions, like WBINVD and some others. > If there's a high frequency NMI it may well hit multiple times in a single > instance. I thought NMIs happen on instruction boundaries, maybe not. Honestly, our current implementation would probably be tripped up with those examples too, so I don't think I am making things worse (assuming the only high frequency NMI is coming from perf). Cheers, Don _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel From xen-devel-bounces@lists.xensource.com Tue Sep 13 13:55:46 2011 Return-path: Envelope-to: www-data@lists.xensource.com Delivery-date: Tue, 13 Sep 2011 13:55:46 -0700 Received: from localhost ([127.0.0.1] helo=lists.colo.xensource.com) by lists.xensource.com with esmtp (Exim 4.43) id 1R3a1B-0002G8-Vf; Tue, 13 Sep 2011 13:55:46 -0700 Received: from mail216.messagelabs.com ([85.158.143.99]) by lists.xensource.com with esmtp (Exim 4.43) id 1R3ZzK-0001gb-V0 for Xen-devel@lists.xensource.com; Tue, 13 Sep 2011 13:53:51 -0700 X-Env-Sender: jeremy@goop.org X-Msg-Ref: server-2.tower-216.messagelabs.com!1315947226!18143727!1 X-Originating-IP: [74.207.240.146] X-StarScan-Version: 6.3.6; banners=-,-,- X-VirusChecked: Checked Received: (qmail 23076 invoked from network); 13 Sep 2011 20:53:47 -0000 Received: from claw.goop.org (HELO claw.goop.org) (74.207.240.146) by server-2.tower-216.messagelabs.com with DHE-RSA-AES256-SHA encrypted SMTP; 13 Sep 2011 20:53:47 -0000 Received: from saboo.goop.org (c-67-164-98-198.hsd1.ca.comcast.net [67.164.98.198]) (Authenticated sender: smtp-saboo) by claw.goop.org (Postfix) with ESMTPSA id CA094951B; Tue, 13 Sep 2011 13:53:44 -0700 (PDT) Received: from saboo.goop.org (localhost [IPv6:::1]) by saboo.goop.org (Postfix) with ESMTP id 7BC0F20026; Tue, 13 Sep 2011 13:53:39 -0700 (PDT) Message-ID: <4E6FC2D3.2060408@goop.org> Date: Tue, 13 Sep 2011 13:53:39 -0700 From: Jeremy Fitzhardinge User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:6.0.2) Gecko/20110906 Thunderbird/6.0.2 MIME-Version: 1.0 To: Thomas Gleixner References: <20110825142450.c84e02d8763cfd1a93411844@canb.auug.org.au> <4E5690C3.2050706@goop.org> <4E5693DD.2010307@zytor.com> <20110826090619.7588d424798f53a6f3621eb2@canb.auug.org.au> <4E56D6E1.6030405@zytor.com> <20110826125441.709aa423cdf072ce085fb91c@canb.auug.org.au> <20110913211154.fe53ca8c1d608def77a69022@canb.auug.org.au> In-Reply-To: X-Enigmail-Version: 1.3.1 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: Stephen Rothwell , Xen Devel , Peter Zijlstra , linux-kernel@vger.kernel.org, linux-next@vger.kernel.org, "H. Peter Anvin" , Ingo Molnar Subject: [Xen-devel] Re: linux-next: manual merge of the xen tree with the tip tree X-BeenThere: xen-devel@lists.xensource.com X-Mailman-Version: 2.1.5 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xensource.com Errors-To: xen-devel-bounces@lists.xensource.com On 09/13/2011 08:07 AM, Thomas Gleixner wrote: > On Tue, 13 Sep 2011, Stephen Rothwell wrote: >> Hi, >> >> On Fri, 26 Aug 2011 12:54:41 +1000 Stephen Rothwell wrote: >>> On Thu, 25 Aug 2011 16:12:33 -0700 "H. Peter Anvin" wrote: >>>> On 08/25/2011 04:06 PM, Stephen Rothwell wrote: >>>>>> Stephen: the x86/spinlocks branch in the -tip tree is obsolete and >>>>>> should be dropped. >>>>> That's a bit tricky as I get a rolled up tip tree. The best I could do >>>>> is revert the commit that merges the x86/spinlocks branch into >>>>> auto-latest ... I'll do that for today (unless something happens to the >>>>> tip tree in the next hour). >>>>> >>>> OK, let me bother Ingo about it. >>> For today, I have done "git revert -m 1 6f8fa39c81f1" after merging the >>> tip tree. >> I am still doing this in each linux-next, and it doesn't appear to have >> been fixed up the the tree on tesla.tglx.de, yet, I think. > We'll take it out. Actually, the tip x86/spinlocks was the most up-to-date version of those patches (since hpa had rebased them to a more recent version of mainline). But never mind. Stephen, could you use git://github.com/jsgf/linux-xen.git upstream/xen for linux-next instead of the kernel.org xen.git, and I've re-added the up-to-date spinlock changes there. Thanks, J _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel From xen-devel-bounces@lists.xensource.com Tue Sep 13 13:56:55 2011 Return-path: Envelope-to: www-data@lists.xensource.com Delivery-date: Tue, 13 Sep 2011 13:56:55 -0700 Received: from localhost ([127.0.0.1] helo=lists.colo.xensource.com) by lists.xensource.com with esmtp (Exim 4.43) id 1R3a2J-0002dl-G5; Tue, 13 Sep 2011 13:56:55 -0700 Received: from mail182.messagelabs.com ([85.158.139.83]) by lists.xensource.com with esmtp (Exim 4.43) id 1R3a1h-0002RJ-8e for Xen-devel@lists.xensource.com; Tue, 13 Sep 2011 13:56:17 -0700 X-Env-Sender: tglx@linutronix.de X-Msg-Ref: server-4.tower-182.messagelabs.com!1315947374!18206588!1 X-Originating-IP: [62.245.132.108] X-StarScan-Version: 6.3.6; banners=-,-,- X-VirusChecked: Checked Received: (qmail 13610 invoked from network); 13 Sep 2011 20:56:14 -0000 Received: from www.linutronix.de (HELO Galois.linutronix.de) (62.245.132.108) by server-4.tower-182.messagelabs.com with AES256-SHA encrypted SMTP; 13 Sep 2011 20:56:14 -0000 Received: from localhost ([127.0.0.1]) by Galois.linutronix.de with esmtps (TLS1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.72) (envelope-from ) id 1R3a1Y-0002kE-Qw; Tue, 13 Sep 2011 22:56:09 +0200 Date: Tue, 13 Sep 2011 22:56:07 +0200 (CEST) From: Thomas Gleixner To: Jeremy Fitzhardinge In-Reply-To: <4E6FC2D3.2060408@goop.org> Message-ID: References: <20110825142450.c84e02d8763cfd1a93411844@canb.auug.org.au> <4E5690C3.2050706@goop.org> <4E5693DD.2010307@zytor.com> <20110826090619.7588d424798f53a6f3621eb2@canb.auug.org.au> <4E56D6E1.6030405@zytor.com> <20110826125441.709aa423cdf072ce085fb91c@canb.auug.org.au> <20110913211154.fe53ca8c1d608def77a69022@canb.auug.org.au> <4E6FC2D3.2060408@goop.org> User-Agent: Alpine 2.02 (LFD 1266 2009-07-14) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Linutronix-Spam-Score: -1.0 X-Linutronix-Spam-Level: - X-Linutronix-Spam-Status: No , -1.0 points, 5.0 required, ALL_TRUSTED=-1, SHORTCIRCUIT=-0.0001 Cc: Stephen Rothwell , Xen Devel , Peter Zijlstra , linux-kernel@vger.kernel.org, linux-next@vger.kernel.org, "H. Peter Anvin" , Ingo Molnar Subject: [Xen-devel] Re: linux-next: manual merge of the xen tree with the tip tree X-BeenThere: xen-devel@lists.xensource.com X-Mailman-Version: 2.1.5 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xensource.com Errors-To: xen-devel-bounces@lists.xensource.com On Tue, 13 Sep 2011, Jeremy Fitzhardinge wrote: > On 09/13/2011 08:07 AM, Thomas Gleixner wrote: > > On Tue, 13 Sep 2011, Stephen Rothwell wrote: > >> Hi, > >> > >> On Fri, 26 Aug 2011 12:54:41 +1000 Stephen Rothwell wrote: > >>> On Thu, 25 Aug 2011 16:12:33 -0700 "H. Peter Anvin" wrote: > >>>> On 08/25/2011 04:06 PM, Stephen Rothwell wrote: > >>>>>> Stephen: the x86/spinlocks branch in the -tip tree is obsolete and > >>>>>> should be dropped. > >>>>> That's a bit tricky as I get a rolled up tip tree. The best I could do > >>>>> is revert the commit that merges the x86/spinlocks branch into > >>>>> auto-latest ... I'll do that for today (unless something happens to the > >>>>> tip tree in the next hour). > >>>>> > >>>> OK, let me bother Ingo about it. > >>> For today, I have done "git revert -m 1 6f8fa39c81f1" after merging the > >>> tip tree. > >> I am still doing this in each linux-next, and it doesn't appear to have > >> been fixed up the the tree on tesla.tglx.de, yet, I think. > > We'll take it out. > > Actually, the tip x86/spinlocks was the most up-to-date version of those > patches (since hpa had rebased them to a more recent version of mainline). Mooo. You tell that after we did a nasty rebase from hell :( Thanks, tglx _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel From xen-devel-bounces@lists.xensource.com Tue Sep 13 14:03:15 2011 Return-path: Envelope-to: www-data@lists.xensource.com Delivery-date: Tue, 13 Sep 2011 14:03:15 -0700 Received: from localhost ([127.0.0.1] helo=lists.colo.xensource.com) by lists.xensource.com with esmtp (Exim 4.43) id 1R3a8R-000370-Hc; Tue, 13 Sep 2011 14:03:15 -0700 Received: from mail174.messagelabs.com ([85.158.138.51]) by lists.xensource.com with esmtp (Exim 4.43) id 1R3a6m-0002te-Pf for xen-devel@lists.xensource.com; Tue, 13 Sep 2011 14:01:38 -0700 X-Env-Sender: nathan@gt.net X-Msg-Ref: server-11.tower-174.messagelabs.com!1315947687!31300380!1 X-Originating-IP: [208.70.244.21] X-StarScan-Version: 6.3.6; banners=-,-,- X-VirusChecked: Checked Received: (qmail 16426 invoked from network); 13 Sep 2011 21:01:29 -0000 Received: from gossamer.nmsrv.com (HELO gossamer.nmsrv.com) (208.70.244.21) by server-11.tower-174.messagelabs.com with DHE-RSA-AES256-SHA encrypted SMTP; 13 Sep 2011 21:01:29 -0000 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=gt.net; h=message-id:date :from:mime-version:to:subject:content-type :content-transfer-encoding; s=mail; bh=hxdmYRZGPJAJm0ZGzCIP0hrM1 Zw=; b=sTPMt+dcvZOD228nq7LWlZl5eySjVRfMKq+ayeXk7h5keACTdj3xbb+ly /72EEXH/dZnyX0n8zCFEDc3imdbEx7NBaoLmSgP2IIrPR80dWofZG+l3StmofDee plJl7o+B98vb0JnLFMAEmjSZY+eiLsU30eaUjS54b7JO23bnsY= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gt.net; h=message-id:date :from:mime-version:to:subject:content-type :content-transfer-encoding; q=dns; s=mail; b=b2yQkv8Yytl334IdpnX L+dhNJeZNEEivsMqrJmqk4qZBy4EypXxUh+H88Mcs8qQ5J3Kt8My0aFoJi/dvQWo YJdiRyEAen74xYvc5kIf+yzqU+Rp9FBaP8C0apeiWfF+495QUYJ+Vveh8qwxc13+ 2j9fs8Ti4vHtT4kXFII7S7qM= Received: (qmail 10798 invoked from network); 13 Sep 2011 21:01:27 -0000 X-AntiVirus: Clean Received: from gateway.gossamer-threads.com (HELO ?192.168.1.152?) (nathan@gossamer-threads.com@208.70.247.145) by gossamer.nmsrv.com with ESMTPSA (DHE-RSA-CAMELLIA256-SHA encrypted); 13 Sep 2011 21:01:27 -0000 Message-ID: <4E6FC4A6.5040304@gt.net> Date: Tue, 13 Sep 2011 14:01:26 -0700 From: Nathan March User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:7.0) Gecko/20110905 Thunderbird/7.0 MIME-Version: 1.0 To: xen-devel@lists.xensource.com Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: [Xen-devel] Internal error during live migration saving X-BeenThere: xen-devel@lists.xensource.com X-Mailman-Version: 2.1.5 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xensource.com Errors-To: xen-devel-bounces@lists.xensource.com Just wondering if this is a known bug? Trying to migrate the VM off to a diff dom0 results in the below error. Other VMs migrated off fine (started at around the same time as this vm) and I've tried a few different target servers, all resulting in the same thing. [2011-09-13 13:48:24 3996] DEBUG (XendCheckpoint:124) [xc_save]: /usr/lib/xen/bin/xc_save 29 77 0 0 1 [2011-09-13 13:48:24 3996] INFO (XendCheckpoint:423) xc_save: failed to get the suspend evtchn port [2011-09-13 13:48:24 3996] INFO (XendCheckpoint:423) [2011-09-13 13:49:03 3996] DEBUG (XendCheckpoint:394) suspend [2011-09-13 13:49:03 3996] DEBUG (XendCheckpoint:127) In saveInputHandler suspend [2011-09-13 13:49:03 3996] DEBUG (XendCheckpoint:129) Suspending 77 ... [2011-09-13 13:49:03 3996] DEBUG (XendDomainInfo:524) XendDomainInfo.shutdown(suspend) [2011-09-13 13:49:03 3996] DEBUG (XendDomainInfo:1881) XendDomainInfo.handleShutdownWatch [2011-09-13 13:50:06 3996] DEBUG (XendDomainInfo:1881) XendDomainInfo.handleShutdownWatch [2011-09-13 13:50:06 3996] INFO (XendCheckpoint:423) xc: error: Suspend request failed: Internal error [2011-09-13 13:50:06 3996] INFO (XendCheckpoint:423) xc: error: Domain appears not to have suspended: Internal error [2011-09-13 13:50:06 3996] ERROR (XendCheckpoint:185) Save failed on domain globish (77) - resuming. Traceback (most recent call last): File "/usr/lib64/python2.6/site-packages/xen/xend/XendCheckpoint.py", line 146, in save forkHelper(cmd, fd, saveInputHandler, False) File "/usr/lib64/python2.6/site-packages/xen/xend/XendCheckpoint.py", line 395, in forkHelper inputHandler(line, child.tochild) File "/usr/lib64/python2.6/site-packages/xen/xend/XendCheckpoint.py", line 131, in saveInputHandler dominfo.waitForSuspend() File "/usr/lib64/python2.6/site-packages/xen/xend/XendDomainInfo.py", line 2998, in waitForSuspend raise XendError(msg) XendError: Timeout waiting for domain 77 to suspend [2011-09-13 13:50:06 3996] DEBUG (XendDomainInfo:3135) XendDomainInfo.resumeDomain(77) xend-debug.log and the target dom0 logs don't show anything of value. This is xen 4.1.1 on linux 3.0.3 - Nathan -- Nathan March Gossamer Threads Inc. http://www.gossamer-threads.com/ Tel: (604) 687-5804 Fax: (604) 687-5806 _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel From xen-devel-bounces@lists.xensource.com Tue Sep 13 14:04:43 2011 Return-path: Envelope-to: www-data@lists.xensource.com Delivery-date: Tue, 13 Sep 2011 14:04:43 -0700 Received: from localhost ([127.0.0.1] helo=lists.colo.xensource.com) by lists.xensource.com with esmtp (Exim 4.43) id 1R3a9r-0003UP-7s; Tue, 13 Sep 2011 14:04:43 -0700 Received: from mail21.messagelabs.com ([85.158.143.35]) by lists.xensource.com with esmtp (Exim 4.43) id 1R3a6G-0002ss-Ah for Xen-devel@lists.xensource.com; Tue, 13 Sep 2011 14:01:33 -0700 X-Env-Sender: jeremy@goop.org X-Msg-Ref: server-8.tower-21.messagelabs.com!1315947638!58846504!1 X-Originating-IP: [74.207.240.146] X-StarScan-Version: 6.4.1; banners=-,-,- X-VirusChecked: Checked Received: (qmail 29838 invoked from network); 13 Sep 2011 21:00:39 -0000 Received: from claw.goop.org (HELO claw.goop.org) (74.207.240.146) by server-8.tower-21.messagelabs.com with DHE-RSA-AES256-SHA encrypted SMTP; 13 Sep 2011 21:00:39 -0000 Received: from saboo.goop.org (c-67-164-98-198.hsd1.ca.comcast.net [67.164.98.198]) (Authenticated sender: smtp-saboo) by claw.goop.org (Postfix) with ESMTPSA id 3F6B7952B; Tue, 13 Sep 2011 14:00:52 -0700 (PDT) Received: from saboo.goop.org (localhost [IPv6:::1]) by saboo.goop.org (Postfix) with ESMTP id 23B6E20026; Tue, 13 Sep 2011 14:00:49 -0700 (PDT) Message-ID: <4E6FC481.6040505@goop.org> Date: Tue, 13 Sep 2011 14:00:49 -0700 From: Jeremy Fitzhardinge User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:6.0.2) Gecko/20110906 Thunderbird/6.0.2 MIME-Version: 1.0 To: Thomas Gleixner References: <20110825142450.c84e02d8763cfd1a93411844@canb.auug.org.au> <4E5690C3.2050706@goop.org> <4E5693DD.2010307@zytor.com> <20110826090619.7588d424798f53a6f3621eb2@canb.auug.org.au> <4E56D6E1.6030405@zytor.com> <20110826125441.709aa423cdf072ce085fb91c@canb.auug.org.au> <20110913211154.fe53ca8c1d608def77a69022@canb.auug.org.au> <4E6FC2D3.2060408@goop.org> In-Reply-To: X-Enigmail-Version: 1.3.1 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: Stephen Rothwell , Xen Devel , Peter Zijlstra , linux-kernel@vger.kernel.org, linux-next@vger.kernel.org, "H. Peter Anvin" , Ingo Molnar Subject: [Xen-devel] Re: linux-next: manual merge of the xen tree with the tip tree X-BeenThere: xen-devel@lists.xensource.com X-Mailman-Version: 2.1.5 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xensource.com Errors-To: xen-devel-bounces@lists.xensource.com On 09/13/2011 01:56 PM, Thomas Gleixner wrote: > On Tue, 13 Sep 2011, Jeremy Fitzhardinge wrote: > >> On 09/13/2011 08:07 AM, Thomas Gleixner wrote: >>> On Tue, 13 Sep 2011, Stephen Rothwell wrote: >>>> Hi, >>>> >>>> On Fri, 26 Aug 2011 12:54:41 +1000 Stephen Rothwell wrote: >>>>> On Thu, 25 Aug 2011 16:12:33 -0700 "H. Peter Anvin" wrote: >>>>>> On 08/25/2011 04:06 PM, Stephen Rothwell wrote: >>>>>>>> Stephen: the x86/spinlocks branch in the -tip tree is obsolete and >>>>>>>> should be dropped. >>>>>>> That's a bit tricky as I get a rolled up tip tree. The best I could do >>>>>>> is revert the commit that merges the x86/spinlocks branch into >>>>>>> auto-latest ... I'll do that for today (unless something happens to the >>>>>>> tip tree in the next hour). >>>>>>> >>>>>> OK, let me bother Ingo about it. >>>>> For today, I have done "git revert -m 1 6f8fa39c81f1" after merging the >>>>> tip tree. >>>> I am still doing this in each linux-next, and it doesn't appear to have >>>> been fixed up the the tree on tesla.tglx.de, yet, I think. >>> We'll take it out. >> Actually, the tip x86/spinlocks was the most up-to-date version of those >> patches (since hpa had rebased them to a more recent version of mainline). > Mooo. You tell that after we did a nasty rebase from hell :( I'd been meaning to take it out of my tree to solve Stephen's problem, but, well, kernel.org. J _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel From xen-devel-bounces@lists.xensource.com Tue Sep 13 14:05:47 2011 Return-path: Envelope-to: www-data@lists.xensource.com Delivery-date: Tue, 13 Sep 2011 14:05:47 -0700 Received: from localhost ([127.0.0.1] helo=lists.colo.xensource.com) by lists.xensource.com with esmtp (Exim 4.43) id 1R3aAt-0003rH-Hg; Tue, 13 Sep 2011 14:05:47 -0700 Received: from mail182.messagelabs.com ([85.158.139.83]) by lists.xensource.com with esmtp (Exim 4.43) id 1R3a9a-0003S1-Rc for xen-devel@lists.xensource.com; Tue, 13 Sep 2011 14:04:37 -0700 X-Env-Sender: andi@firstfloor.org X-Msg-Ref: server-3.tower-182.messagelabs.com!1315947863!15412531!1 X-Originating-IP: [213.235.205.2] X-StarScan-Version: 6.3.6; banners=-,-,- X-VirusChecked: Checked Received: (qmail 6977 invoked from network); 13 Sep 2011 21:04:23 -0000 Received: from one.firstfloor.org (HELO one.firstfloor.org) (213.235.205.2) by server-3.tower-182.messagelabs.com with DHE-RSA-AES256-SHA encrypted SMTP; 13 Sep 2011 21:04:23 -0000 Received: by one.firstfloor.org (Postfix, from userid 503) id 2CEB91ED80B4; Tue, 13 Sep 2011 23:04:23 +0200 (CEST) Date: Tue, 13 Sep 2011 23:04:23 +0200 From: Andi Kleen To: Don Zickus Message-ID: <20110913210423.GT7761@one.firstfloor.org> References: <4E678992.5050709@redhat.com> <20110907155657.GX5795@redhat.com> <4E679AF4.50209@redhat.com> <20110907165203.GQ6838@redhat.com> <4E67A551.4000502@redhat.com> <20110913184044.GN5795@redhat.com> <20110913190320.GR7761@one.firstfloor.org> <20110913192152.GO5795@redhat.com> <20110913195838.GS7761@one.firstfloor.org> <20110913205318.GQ5795@redhat.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20110913205318.GQ5795@redhat.com> User-Agent: Mutt/1.4.2.2i Cc: Jeremy Fitzhardinge , Marcelo Tosatti , Nick Piggin , KVM , Stefano Stabellini , Peter Zijlstra , the arch/x86 maintainers , Linux Kernel Mailing List , Andi Kleen , Avi Kivity , Jeremy Fitzhardinge , "H. Peter Anvin" , Ingo Molnar , Linus Torvalds , Xen Devel Subject: [Xen-devel] Re: [PATCH 08/13] xen/pvticketlock: disable interrupts while blocking X-BeenThere: xen-devel@lists.xensource.com X-Mailman-Version: 2.1.5 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xensource.com Errors-To: xen-devel-bounces@lists.xensource.com On Tue, Sep 13, 2011 at 04:53:18PM -0400, Don Zickus wrote: > On Tue, Sep 13, 2011 at 09:58:38PM +0200, Andi Kleen wrote: > > > Or are you saying an NMI in an idle system will have the same %rip thus > > > falsely detecting a back-to-back NMI? > > > > Yup. > > Hmm. That sucks. Is there another register that can be used in > conjunction to seperate it, like sp or something? Or we can we assume Not that I know of. > than an idle cpu isn't doing much for local NMI IPIs and that the only > NMIs that would interrupt it would be external ones? There can be still activity on the "idle" system, e.g. SMM or some Hypervisor in the background. If you profile events those might trigger samples, but they will be all accounted to the MWAIT. > > Another problem is very long running instructions, like WBINVD and some others. > > If there's a high frequency NMI it may well hit multiple times in a single > > instance. > > I thought NMIs happen on instruction boundaries, maybe not. Yes, but there may be multiple queued up when the instruction has finished executing. So you get multiple at the boundary. > Honestly, our current implementation would probably be tripped up with > those examples too, so I don't think I am making things worse (assuming > the only high frequency NMI is coming from perf). I wish perf/oprofile would just stop using NMIs. The interrupt off regions are getting smaller and smaller and they can be profiled in a limited way using PEBS anyways. Or maybe make it a knob with default to off. -Andi _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel From xen-devel-bounces@lists.xensource.com Tue Sep 13 14:16:32 2011 Return-path: Envelope-to: www-data@lists.xensource.com Delivery-date: Tue, 13 Sep 2011 14:16:32 -0700 Received: from localhost ([127.0.0.1] helo=lists.colo.xensource.com) by lists.xensource.com with esmtp (Exim 4.43) id 1R3aLI-0004NK-H7; Tue, 13 Sep 2011 14:16:32 -0700 Received: from mail216.messagelabs.com ([85.158.143.99]) by lists.xensource.com with esmtp (Exim 4.43) id 1R3aKh-0004Aa-Pl; Tue, 13 Sep 2011 14:15:56 -0700 X-Env-Sender: hwang.jinho@gmail.com X-Msg-Ref: server-5.tower-216.messagelabs.com!1315948550!17638207!1 X-Originating-IP: [209.85.213.171] X-StarScan-Version: 6.3.6; banners=-,-,- X-VirusChecked: Checked Received: (qmail 11602 invoked from network); 13 Sep 2011 21:15:51 -0000 Received: from mail-yx0-f171.google.com (HELO mail-yx0-f171.google.com) (209.85.213.171) by server-5.tower-216.messagelabs.com with RC4-SHA encrypted SMTP; 13 Sep 2011 21:15:51 -0000 Received: by yxt3 with SMTP id 3so1052278yxt.30 for ; Tue, 13 Sep 2011 14:15:50 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:from:date:message-id:subject:to:content-type; bh=K1TCl+bByVgyjm6Z9jpUel8J+t1onyHDXuGl69h/WVw=; b=BR3vTZVUVA497+22wKLq3nDWvNUNjYcNolGRhcrNJxk0g5xPVDLmLPkysn8gwxVqWp amA2UumlFJ+Eu5+b0IUovGU8B54EgdMlkDj0q9+PQTCpyA8mos4WnZ9N+aAgxWOo68R4 o796hKTrVsGlY+DvT0pOAX4BZRVn/mHFxeIVs= Received: by 10.150.2.8 with SMTP id 8mr1716605ybb.234.1315948548114; Tue, 13 Sep 2011 14:15:48 -0700 (PDT) MIME-Version: 1.0 Received: by 10.151.154.16 with HTTP; Tue, 13 Sep 2011 14:15:28 -0700 (PDT) From: jinho hwang Date: Tue, 13 Sep 2011 17:15:28 -0400 Message-ID: To: xen-devel@lists.xensource.com, xen-users@lists.xensource.com Cc: Subject: [Xen-devel] [Xen-users] current xen linux kernel branch? X-BeenThere: xen-devel@lists.xensource.com X-Mailman-Version: 2.1.5 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0133457325==" Sender: xen-devel-bounces@lists.xensource.com Errors-To: xen-devel-bounces@lists.xensource.com --===============0133457325== Content-Type: multipart/alternative; boundary=000e0cd3efdec0c9b604acd92582 --000e0cd3efdec0c9b604acd92582 Content-Type: text/plain; charset=ISO-8859-1 Hi, Where can I find the current xen linux kernel branch? The git.kernel.org has been down for maintenance reason, so I can't find any kernel source except xenbits.xensource.com. However, this repository does not have current linux dom0 kernel such as 2.6.32.*. Can anyone share with me the kernel source because I have to install xen environment in my intel 32/64bits machine. Thank you so much, Jinho -- Jinho Hwang PhD Student Department of Computer Science The George Washington University Washington, DC 20052 hwang.jinho@gmail.com (email) 276.336.0971 (Cell) 202.994.4875 (fax) 070.8285.6546 (myLg070) --000e0cd3efdec0c9b604acd92582 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable

Hi,=A0


Thank you so much,=A0

Jinho --000e0cd3efdec0c9b604acd92582-- --===============0133457325== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel --===============0133457325==-- From xen-devel-bounces@lists.xensource.com Tue Sep 13 14:49:58 2011 Return-path: Envelope-to: www-data@lists.xensource.com Delivery-date: Tue, 13 Sep 2011 14:49:58 -0700 Received: from localhost ([127.0.0.1] helo=lists.colo.xensource.com) by lists.xensource.com with esmtp (Exim 4.43) id 1R3ard-00062n-SK; Tue, 13 Sep 2011 14:49:57 -0700 Received: from mail174.messagelabs.com ([85.158.138.51]) by lists.xensource.com with esmtp (Exim 4.43) id 1R3aqb-0005px-89 for xen-devel@lists.xensource.com; Tue, 13 Sep 2011 14:48:53 -0700 X-Env-Sender: nathan@gt.net X-Msg-Ref: server-9.tower-174.messagelabs.com!1315950528!25272161!1 X-Originating-IP: [208.70.244.21] X-StarScan-Version: 6.3.6; banners=-,-,- X-VirusChecked: Checked Received: (qmail 19019 invoked from network); 13 Sep 2011 21:48:49 -0000 Received: from gossamer.nmsrv.com (HELO gossamer.nmsrv.com) (208.70.244.21) by server-9.tower-174.messagelabs.com with DHE-RSA-AES256-SHA encrypted SMTP; 13 Sep 2011 21:48:49 -0000 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=gt.net; h=message-id:date :from:mime-version:to:cc:subject:references:in-reply-to :content-type; s=mail; bh=R1wOo+Fm5nYSe3w2OzcoP5lVHjk=; b=Hbk2P9 AsUBo+QvpYQ9WECxhV8a/uEXgnGjmnCU2fPKQKPiNCR8KNKR9U4BkOnQaFHFtH86 VeRK5S7j+YU+uCXdAHjA8SrnMcHgHckLZm7v0K5xYbL6FwRpAxaJL8btQPG3TBmP bqWEt6BqAdFwKj7Rhm9Aw53Q8iaym+JsU+HBk= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gt.net; h=message-id:date :from:mime-version:to:cc:subject:references:in-reply-to :content-type; q=dns; s=mail; b=hfloy0e4cvjsPMd4c62zdf73XvE7PLqU F1J82zvcjqJX1wy9/Pf8juGwCgb0YuFSkG5QavXhyhMREr/kxBNgLwUogD26yXKL q/rpzYN8Y9+PPdSMC388XMfpETkOJAvREcMgQfaIBvl0mLt/jhfysRZv/7olIdsO o9zSV9UNVJ8= Received: (qmail 4770 invoked from network); 13 Sep 2011 21:48:47 -0000 X-AntiVirus: Clean Received: from gateway.gossamer-threads.com (HELO ?192.168.1.152?) (nathan@gossamer-threads.com@208.70.247.145) by gossamer.nmsrv.com with ESMTPSA (DHE-RSA-CAMELLIA256-SHA encrypted); 13 Sep 2011 21:48:47 -0000 Message-ID: <4E6FCFBE.7080305@gt.net> Date: Tue, 13 Sep 2011 14:48:46 -0700 From: Nathan March User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:7.0) Gecko/20110905 Thunderbird/7.0 MIME-Version: 1.0 To: jinho hwang References: In-Reply-To: Cc: xen-devel@lists.xensource.com, xen-users@lists.xensource.com Subject: [Xen-devel] Re: [Xen-users] current xen linux kernel branch? X-BeenThere: xen-devel@lists.xensource.com X-Mailman-Version: 2.1.5 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1362254451==" Sender: xen-devel-bounces@lists.xensource.com Errors-To: xen-devel-bounces@lists.xensource.com This is a multi-part message in MIME format. --===============1362254451== Content-Type: multipart/alternative; boundary="------------050808030008090504000404" This is a multi-part message in MIME format. --------------050808030008090504000404 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit On 9/13/2011 2:15 PM, jinho hwang wrote: > > Hi, > > Where can I find the current xen linux kernel branch? The > git.kernel.org has been down for maintenance > reason, so I can't find any kernel source except xenbits.xensource.com > . However, this repository does not have > current linux dom0 kernel such as 2.6.32.*. Can anyone share with me > the kernel source because I have to install xen environment in my > intel 32/64bits machine. > > Thank you so much, > > Jinho You probably just want the mainstream linux 3.x kernel now. Otherwise: https://github.com/jsgf/linux-xen http://xenbits.xen.org/gitweb/?p=people/dstodden/blktap-debian.git;a=summary http://xenbits.xen.org/gitweb/?p=people/dstodden/linux.git;a=summary http://xenbits.xen.org/gitweb/?p=people/dstodden/blktap.git;a=summary - Nathan --------------050808030008090504000404 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit On 9/13/2011 2:15 PM, jinho hwang wrote:

Hi, 

Where can I find the current xen linux kernel branch? The git.kernel.org has been down for maintenance reason, so I can't find any kernel source except xenbits.xensource.com. However, this repository does not have current linux dom0 kernel such as 2.6.32.*. Can anyone share with me the kernel source because I have to install xen environment in my intel 32/64bits machine. 

Thank you so much, 

Jinho

You probably just want the mainstream linux 3.x kernel now.

Otherwise:
https://github.com/jsgf/linux-xen

http://xenbits.xen.org/gitweb/?p=people/dstodden/blktap-debian.git;a=summary

http://xenbits.xen.org/gitweb/?p=people/dstodden/linux.git;a=summary

http://xenbits.xen.org/gitweb/?p=people/dstodden/blktap.git;a=summary


- Nathan --------------050808030008090504000404-- --===============1362254451== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel --===============1362254451==-- From xen-devel-bounces@lists.xensource.com Tue Sep 13 15:02:03 2011 Return-path: Envelope-to: www-data@lists.xensource.com Delivery-date: Tue, 13 Sep 2011 15:02:03 -0700 Received: from localhost ([127.0.0.1] helo=lists.colo.xensource.com) by lists.xensource.com with esmtp (Exim 4.43) id 1R3b3J-0007Fm-Nj; Tue, 13 Sep 2011 15:02:01 -0700 Received: from mail21.messagelabs.com ([85.158.143.35]) by lists.xensource.com with esmtp (Exim 4.43) id 1R3azc-0006zu-Ur; Tue, 13 Sep 2011 14:59:14 -0700 X-Env-Sender: hwang.jinho@gmail.com X-Msg-Ref: server-8.tower-21.messagelabs.com!1315951069!58849731!1 X-Originating-IP: [209.85.160.171] X-StarScan-Version: 6.4.1; banners=-,-,- X-VirusChecked: Checked Received: (qmail 26017 invoked from network); 13 Sep 2011 21:57:50 -0000 Received: from mail-gy0-f171.google.com (HELO mail-gy0-f171.google.com) (209.85.160.171) by server-8.tower-21.messagelabs.com with RC4-SHA encrypted SMTP; 13 Sep 2011 21:57:50 -0000 Received: by gyh3 with SMTP id 3so1088370gyh.30 for ; Tue, 13 Sep 2011 14:58:04 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=4BODO2rL57UpWPXP+87noBz5po5W6bCGe6Vatz/uteE=; b=BsNrbbIYc0L9bXmpNB2rmICihEKz0f0GliU9Bh0vsiEz95VZ0WMl/JB5lpdwN2VJN9 6bXLeq5Kak40j/Li9KO636605HNJ4DZilOINviuIueGqX3AwGOJ77f5TBAQ7XwbBgDFF PW13U2jlCGrBGutx1ed4J3JStn8HzrNjnA3aU= Received: by 10.150.215.17 with SMTP id n17mr2903265ybg.6.1315951083084; Tue, 13 Sep 2011 14:58:03 -0700 (PDT) MIME-Version: 1.0 Received: by 10.151.154.16 with HTTP; Tue, 13 Sep 2011 14:57:43 -0700 (PDT) In-Reply-To: <4E6FCFBE.7080305@gt.net> References: <4E6FCFBE.7080305@gt.net> From: jinho hwang Date: Tue, 13 Sep 2011 17:57:43 -0400 Message-ID: To: Nathan March Cc: xen-devel@lists.xensource.com, xen-users@lists.xensource.com Subject: [Xen-devel] Re: [Xen-users] current xen linux kernel branch? X-BeenThere: xen-devel@lists.xensource.com X-Mailman-Version: 2.1.5 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1105747361==" Sender: xen-devel-bounces@lists.xensource.com Errors-To: xen-devel-bounces@lists.xensource.com --===============1105747361== Content-Type: multipart/alternative; boundary=000e0cd2e6acd95bdf04acd9bc34 --000e0cd2e6acd95bdf04acd9bc34 Content-Type: text/plain; charset=ISO-8859-1 Hi Nathan, Thank you so much for replying. Do you mean that I can use mainstream linux 3.x for dom0 and domU as well? I never found an article or instruction that any one successfully installed mainstream as dom0. Can you tell me any material that I can refer to for this? Thank you, Jinho On Tue, Sep 13, 2011 at 5:48 PM, Nathan March wrote: > On 9/13/2011 2:15 PM, jinho hwang wrote: > > > Hi, > > Where can I find the current xen linux kernel branch? The git.kernel.orghas been down for maintenance reason, so I can't find any kernel source > except xenbits.xensource.com. However, this repository does not have > current linux dom0 kernel such as 2.6.32.*. Can anyone share with me the > kernel source because I have to install xen environment in my intel > 32/64bits machine. > > Thank you so much, > > Jinho > > > You probably just want the mainstream linux 3.x kernel now. > > Otherwise: > https://github.com/jsgf/linux-xen > > > http://xenbits.xen.org/gitweb/?p=people/dstodden/blktap-debian.git;a=summary > > http://xenbits.xen.org/gitweb/?p=people/dstodden/linux.git;a=summary > > http://xenbits.xen.org/gitweb/?p=people/dstodden/blktap.git;a=summary > > > - Nathan > -- Jinho Hwang PhD Student Department of Computer Science The George Washington University Washington, DC 20052 hwang.jinho@gmail.com (email) 276.336.0971 (Cell) 202.994.4875 (fax) 070.8285.6546 (myLg070) --000e0cd2e6acd95bdf04acd9bc34 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable

Hi Nathan,=A0

Thank you so much for reply= ing. Do you mean that I can use mainstream linux 3.x for dom0 and domU as w= ell? I never found an article or instruction that any one successfully inst= alled mainstream as dom0. Can you tell me any material that I can refer to = for this?=A0

Thank you,=A0

Jinho
=
On Tue, Sep 13, 2011 at 5:48 PM, Nathan Marc= h <nathan@gt.net&= gt; wrote:
=20 =20 =20
On 9/13/2011 2:15 PM, jinho hwang wrote:

Hi,=A0

Where can I find the current xen linux kernel branch? The git.kernel.org has been down for maintenance reason, so I can't find any kerne= l source except xenbits.xensource.com. However, this repository does not have current linux dom0 kernel such as 2.6.32.*. Can anyone share with me the kernel source because I have to install xen environment in my intel 32/64bits machine.=A0

Thank you so much,=A0

Jinho

You probably just want the mainstream linux 3.x kernel now.

Otherwise:
https:/= /github.com/jsgf/linux-xen

http://xenbits.xen.org/gitweb/?p=3Dpeop= le/dstodden/blktap-debian.git;a=3Dsummary

http://xenbits.xen.org/gitweb/?p=3Dpeople/d= stodden/linux.git;a=3Dsummary

http://xenbits.xen.org/gitweb/?p=3Dpeople/dst= odden/blktap.git;a=3Dsummary


- Nathan



--
Jinho Hwang<= br>PhD Student
Department of Computer Science
The George Washington U= niversity
Washington, DC 20052
hwang.jinho@gmail.com (email)
276.336.0971 (Cell)
202.994.4875 (fax)
070.8285.6546 (myLg070)
--000e0cd2e6acd95bdf04acd9bc34-- --===============1105747361== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel --===============1105747361==-- From xen-devel-bounces@lists.xensource.com Tue Sep 13 15:08:30 2011 Return-path: Envelope-to: www-data@lists.xensource.com Delivery-date: Tue, 13 Sep 2011 15:08:30 -0700 Received: from localhost ([127.0.0.1] helo=lists.colo.xensource.com) by lists.xensource.com with esmtp (Exim 4.43) id 1R3b9Z-0008Lm-SI; Tue, 13 Sep 2011 15:08:30 -0700 Received: from mail174.messagelabs.com ([85.158.138.51]) by lists.xensource.com with esmtp (Exim 4.43) id 1R3b2y-0007C1-Tb for xen-devel@lists.xensource.com; Tue, 13 Sep 2011 15:01:49 -0700 X-Env-Sender: nathan@gt.net X-Msg-Ref: server-14.tower-174.messagelabs.com!1315951295!31312035!1 X-Originating-IP: [208.70.244.21] X-StarScan-Version: 6.3.6; banners=-,-,- X-VirusChecked: Checked Received: (qmail 13817 invoked from network); 13 Sep 2011 22:01:37 -0000 Received: from gossamer.nmsrv.com (HELO gossamer.nmsrv.com) (208.70.244.21) by server-14.tower-174.messagelabs.com with DHE-RSA-AES256-SHA encrypted SMTP; 13 Sep 2011 22:01:37 -0000 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=gt.net; h=message-id:date :from:mime-version:to:cc:subject:references:in-reply-to :content-type; s=mail; bh=EgOyqrA66EAhKnCX0Gle4OzGQrA=; b=SOhkNu A1cl/II8ETNiyG5K49ocCYL5hUt9zpxi3BkwQkTpLt/RS3rdNnuduo/RshArhpRP sD1BX395EtETVFP+u0a3lb0HeK2Fb/vyfv89Mjtft35jEWq+COCdiW3jCRrUbOd7 G35AYG8AE3gnx00Rq69jK1xRr+zv0//vcbWc4= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gt.net; h=message-id:date :from:mime-version:to:cc:subject:references:in-reply-to :content-type; q=dns; s=mail; b=X2qXMX8wlJbAsgGU2l8NlnsMeUFdi0pJ pd0vSlq1defk2SWLpy0ICbTmjwkz1LXtEW66sofOohOlK0Gw0aWM8daU5sEsavgT Q0wfRXJWoSIZfEiALhNQljSdM0yh4Ywy7a9wH6hoOg6eMgV0BbUossSxIlMqA1q2 ZHUgE6sTs1Y= Received: (qmail 7545 invoked from network); 13 Sep 2011 22:01:35 -0000 X-AntiVirus: Clean Received: from gateway.gossamer-threads.com (HELO ?192.168.1.152?) (nathan@gossamer-threads.com@208.70.247.145) by gossamer.nmsrv.com with ESMTPSA (DHE-RSA-CAMELLIA256-SHA encrypted); 13 Sep 2011 22:01:35 -0000 Message-ID: <4E6FD2BE.8070501@gt.net> Date: Tue, 13 Sep 2011 15:01:34 -0700 From: Nathan March User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:7.0) Gecko/20110905 Thunderbird/7.0 MIME-Version: 1.0 To: jinho hwang References: <4E6FCFBE.7080305@gt.net> In-Reply-To: Cc: xen-devel@lists.xensource.com, xen-users@lists.xensource.com Subject: [Xen-devel] Re: [Xen-users] current xen linux kernel branch? X-BeenThere: xen-devel@lists.xensource.com X-Mailman-Version: 2.1.5 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0475894693==" Sender: xen-devel-bounces@lists.xensource.com Errors-To: xen-devel-bounces@lists.xensource.com This is a multi-part message in MIME format. --===============0475894693== Content-Type: multipart/alternative; boundary="------------010608000309060005020100" This is a multi-part message in MIME format. --------------010608000309060005020100 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Correct, 3.x has both dom0 and domU support in it. If you limit your dom0 memory, make sure to also do "mem=XX" on the kernel line (Due to a bug, see my recent posts in xen-devel). IE, I'm using: kernel /boot/xen.gz console=com1,com2,vga com1=115200,8n1 com2=115200,8n1 dom0_mem=1024M dom0_max_vcpus=1 dom0_vcpus_pin=true module /boot/vmlinuz root=/dev/md0 max_loop=512 mem=1GB console=tty0 console=ttyS0,115200 console=ttyS1,115200 - Nathan On 9/13/2011 2:57 PM, jinho hwang wrote: > > Hi Nathan, > > Thank you so much for replying. Do you mean that I can use mainstream > linux 3.x for dom0 and domU as well? I never found an article or > instruction that any one successfully installed mainstream as dom0. > Can you tell me any material that I can refer to for this? > > Thank you, > > Jinho > > On Tue, Sep 13, 2011 at 5:48 PM, Nathan March > wrote: > > On 9/13/2011 2:15 PM, jinho hwang wrote: >> >> Hi, >> >> Where can I find the current xen linux kernel branch? The >> git.kernel.org has been down for >> maintenance reason, so I can't find any kernel source except >> xenbits.xensource.com . However, >> this repository does not have current linux dom0 kernel such as >> 2.6.32.*. Can anyone share with me the kernel source because I >> have to install xen environment in my intel 32/64bits machine. >> >> Thank you so much, >> >> Jinho > > You probably just want the mainstream linux 3.x kernel now. > > Otherwise: > https://github.com/jsgf/linux-xen > > http://xenbits.xen.org/gitweb/?p=people/dstodden/blktap-debian.git;a=summary > > http://xenbits.xen.org/gitweb/?p=people/dstodden/linux.git;a=summary > > http://xenbits.xen.org/gitweb/?p=people/dstodden/blktap.git;a=summary > > > - Nathan > > > > > -- > Jinho Hwang > PhD Student > Department of Computer Science > The George Washington University > Washington, DC 20052 > hwang.jinho@gmail.com (email) > 276.336.0971 (Cell) > 202.994.4875 (fax) > 070.8285.6546 (myLg070) --------------010608000309060005020100 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Correct, 3.x has both dom0 and domU support in it.

If you limit your dom0 memory, make sure to also do "mem=XX" on the kernel line (Due to a bug, see my recent posts in xen-devel).

IE, I'm using:

    kernel /boot/xen.gz console=com1,com2,vga com1=115200,8n1 com2=115200,8n1 dom0_mem=1024M dom0_max_vcpus=1 dom0_vcpus_pin=true
    module /boot/vmlinuz root=/dev/md0 max_loop=512 mem=1GB console=tty0 console=ttyS0,115200 console=ttyS1,115200

- Nathan

On 9/13/2011 2:57 PM, jinho hwang wrote:

Hi Nathan, 

Thank you so much for replying. Do you mean that I can use mainstream linux 3.x for dom0 and domU as well? I never found an article or instruction that any one successfully installed mainstream as dom0. Can you tell me any material that I can refer to for this? 

Thank you, 

Jinho

On Tue, Sep 13, 2011 at 5:48 PM, Nathan March <nathan@gt.net> wrote:
On 9/13/2011 2:15 PM, jinho hwang wrote:

Hi, 

Where can I find the current xen linux kernel branch? The git.kernel.org has been down for maintenance reason, so I can't find any kernel source except xenbits.xensource.com. However, this repository does not have current linux dom0 kernel such as 2.6.32.*. Can anyone share with me the kernel source because I have to install xen environment in my intel 32/64bits machine. 

Thank you so much, 

Jinho

You probably just want the mainstream linux 3.x kernel now.

Otherwise:
https://github.com/jsgf/linux-xen

http://xenbits.xen.org/gitweb/?p=people/dstodden/blktap-debian.git;a=summary

http://xenbits.xen.org/gitweb/?p=people/dstodden/linux.git;a=summary

http://xenbits.xen.org/gitweb/?p=people/dstodden/blktap.git;a=summary


- Nathan



--
Jinho Hwang
PhD Student
Department of Computer Science
The George Washington University
Washington, DC 20052
hwang.jinho@gmail.com (email)
276.336.0971 (Cell)
202.994.4875 (fax)
070.8285.6546 (myLg070)
--------------010608000309060005020100-- --===============0475894693== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel --===============0475894693==-- From xen-devel-bounces@lists.xensource.com Tue Sep 13 15:12:42 2011 Return-path: Envelope-to: www-data@lists.xensource.com Delivery-date: Tue, 13 Sep 2011 15:12:43 -0700 Received: from localhost ([127.0.0.1] helo=lists.colo.xensource.com) by lists.xensource.com with esmtp (Exim 4.43) id 1R3bDe-0000z9-Mb; Tue, 13 Sep 2011 15:12:42 -0700 Received: from mail174.messagelabs.com ([85.158.138.51]) by lists.xensource.com with smtp (Exim 4.43) id 1R3bBC-0000Di-Fm for xen-devel@lists.xensource.com; Tue, 13 Sep 2011 15:10:14 -0700 X-Env-Sender: therion@ninth-art.de X-Msg-Ref: server-6.tower-174.messagelabs.com!1315951806!29169891!1 X-Originating-IP: [88.198.12.237] X-StarScan-Version: 6.3.6; banners=-,-,- X-VirusChecked: Checked Received: (qmail 11352 invoked from network); 13 Sep 2011 22:10:06 -0000 Received: from coruscant.unix.io (HELO mail.unix.io) (88.198.12.237) by server-6.tower-174.messagelabs.com with SMTP; 13 Sep 2011 22:10:06 -0000 Received: from coruscant.unix.io (localhost [127.0.0.1]) by mail.unix.io (Postfix) with ESMTP id 99A859BCA6 for ; Wed, 14 Sep 2011 00:10:06 +0200 (CEST) X-Virus-Scanned: amavisd-new at unix.io Received: from mail.unix.io ([127.0.0.1]) by coruscant.unix.io (mail.unix.io [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jF2Yz6M9_bux for ; Wed, 14 Sep 2011 00:10:01 +0200 (CEST) Received: from [192.168.2.2] (dslb-084-062-130-173.pools.arcor-ip.net [84.62.130.173]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.unix.io (Postfix) with ESMTPSA id B1DF89BCA5 for ; Wed, 14 Sep 2011 00:10:00 +0200 (CEST) From: Georg Bege To: xen-devel@lists.xensource.com Content-Type: multipart/mixed; boundary="=-q9XhtxH26qUP7nMwdumE" Date: Wed, 14 Sep 2011 00:09:08 +0200 Message-ID: <1315951748.7224.5.camel@kali.ninth-art.net> Mime-Version: 1.0 X-Mailer: Evolution 2.32.2 Subject: [Xen-devel] Several issues with Xen 4.1.1 regarding Windows guests (and more...) X-BeenThere: xen-devel@lists.xensource.com X-Mailman-Version: 2.1.5 Precedence: list Reply-To: therion@ninth-art.de List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xensource.com Errors-To: xen-devel-bounces@lists.xensource.com --=-q9XhtxH26qUP7nMwdumE Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: 7bit Hello Im experiencing serveral issues right now, Im not well Xen experienced - I tried it first in '06 and staid off from it since last week. a) Im unable to install Windows 7 guests, I can install them perfectly but on "Setup is preparing your computer for first use" it simply stalls. xentop says its in blocking mode, its consuming some cpu but just 1% or so. b) I managed to install Windows XP fine, however the performance (I/O in general) is quite poor compared to VirtualBox. c) If the XM hypervisor starts it holds several seconds on its initialization. (After the last loading module... line from grub) d) Problem c) occurs again if the Dom0 kernel loads. Additionally I'll append some outputs of xm dmesg, info and dmesg. Im running Gentoo (mostly stable stuff / 64bit). Im gonna give you my configs I used: ----------winxp-testing.hvm-------------- # -*- mode: python; -*- import os, re arch = os.uname()[4] if re.search('64', arch): arch_libdir = 'lib64'; else: arch_libdir = 'lib'; kernel="/usr/lib/xen/boot/hvmloader" builder='hvm' memory=2048 name="WinXP-testing" vcpus=2 pae=0 acpi=1 apic=1 # ignored if vcpus > 1 xen_extended_power_mgmt=0 cpus="" vif=[ 'ip=10.0.0.1' ] disk=[ 'tap:aio:/warehouse/xen-drives/winxp-testing.img,hda,w', 'file:/warehouse/images/windows/windows_aio.iso,hdc:cdrom,r' ] boot="cd" device_model='/usr/' + arch_libdir + '/xen/bin/qemu-dm' snapshot=0 sdl=1 opengl=1 # depends on sdl vnc=0 monitor=1 stdvga=0 serial='pty' tsc_mode=0 localtime=1 usb=1 usbdevice='tablet' keymap='de' xen_platform_pci=1 pci_power_mgmt=1 on_poweroff='destroy' on_reboot='restart' -----------------snip---------------------- -----------------win7-testing.hvm---------- # -*- mode: python; -*- import os, re arch = os.uname()[4] if re.search('64', arch): arch_libdir = 'lib64'; else: arch_libdir = 'lib'; kernel="/usr/lib/xen/boot/hvmloader" builder='hvm' memory=2048 name="Win7-testing" vcpus=2 pae=1 acpi=1 apic=1 # ignored if vcpus > 1 xen_extended_power_mgmt=0 cpus="" vif=[ 'ip=10.0.0.1' ] disk=[ 'tap:aio:/warehouse/xen-drives/win7-testing.img,hda,w', 'file:/warehouse/images/windows/win7_aio/win7aio.iso,hdc:cdrom,r' ] boot="dc" device_model='/usr/' + arch_libdir + '/xen/bin/qemu-dm' snapshot=0 sdl=1 opengl=1 # depends on sdl vnc=0 monitor=1 stdvga=0 serial='pty' tsc_mode=0 localtime=1 usb=1 usbdevice='tablet' keymap='de' xen_platform_pci=1 pci_power_mgmt=1 on_poweroff='destroy' on_reboot='restart' on_crash='restart' --------------------snip----------------------------------- -- Georg Bege --=-q9XhtxH26qUP7nMwdumE Content-Disposition: attachment; filename="lscpu.txt" Content-Type: text/plain; name="lscpu.txt"; charset="UTF-8" Content-Transfer-Encoding: 7bit Architecture: x86_64 CPU op-mode(s): 32-bit, 64-bit Byte Order: Little Endian CPU(s): 12 On-line CPU(s) list: 0-11 Thread(s) per core: 1 Core(s) per socket: 1 Socket(s): 12 Vendor ID: GenuineIntel CPU family: 6 Model: 44 Stepping: 2 CPU MHz: 2800.162 BogoMIPS: 5902.51 Hypervisor vendor: Xen Virtualization type: none L1d cache: 32K L1i cache: 32K L2 cache: 256K L3 cache: 12288K --=-q9XhtxH26qUP7nMwdumE Content-Disposition: attachment; filename="xm-dmesg.txt" Content-Type: text/plain; name="xm-dmesg.txt"; charset="UTF-8" Content-Transfer-Encoding: 7bit __ __ _ _ _ _ \ \/ /___ _ __ | || | / | / | \ // _ \ \047_ \ | || |_ | | | | / \ __/ | | | |__ _|| |_| | /_/\_\___|_| |_| |_|(_)_(_)_| (XEN) Xen version 4.1.1 (root@ninth-art.net) (gcc version 4.5.3 (Gentoo 4.5.3-r1 p1.0, pie-0.4.5) ) Fri Sep 9 21:36:17 CEST 2011 (XEN) Latest ChangeSet: unavailable (XEN) Bootloader: GNU GRUB 0.97 (XEN) Command line: iommu=1 (XEN) Video information: (XEN) VGA is text mode 80x25, font 8x16 (XEN) VBE/DDC methods: none; EDID transfer time: 0 seconds (XEN) EDID info not retrieved because no DDC retrieval method detected (XEN) Disc information: (XEN) Found 5 MBR signatures (XEN) Found 5 EDD information structures (XEN) Xen-e820 RAM map: (XEN) 0000000000000000 - 000000000008f000 (usable) (XEN) 000000000008f000 - 0000000000090000 (reserved) (XEN) 0000000000090000 - 000000000009a400 (usable) (XEN) 000000000009a400 - 00000000000a0000 (reserved) (XEN) 00000000000e0000 - 0000000000100000 (reserved) (XEN) 0000000000100000 - 00000000cf49d000 (usable) (XEN) 00000000cf49d000 - 00000000cf4bf000 (reserved) (XEN) 00000000cf4bf000 - 00000000cf57d000 (usable) (XEN) 00000000cf57d000 - 00000000cf7bf000 (ACPI NVS) (XEN) 00000000cf7bf000 - 00000000cf7df000 (usable) (XEN) 00000000cf7df000 - 00000000cf7ff000 (ACPI data) (XEN) 00000000cf7ff000 - 00000000cf800000 (usable) (XEN) 00000000cf800000 - 00000000d0000000 (reserved) (XEN) 00000000f8000000 - 00000000fd000000 (reserved) (XEN) 00000000ffe00000 - 0000000100000000 (reserved) (XEN) 0000000100000000 - 0000000330000000 (usable) (XEN) ACPI: RSDP 000FE020, 0024 (r2 INTEL ) (XEN) ACPI: XSDT CF7FE120, 0074 (r1 INTEL DX58SO2 25B 1000013) (XEN) ACPI: FACP CF7FD000, 00F4 (r3 INTEL DX58SO2 25B MSFT 100000D) (XEN) ACPI Warning (tbfadt-0444): Optional field "Pm2ControlBlock" has zero address or length: 0000000000000450/0 [20070126] (XEN) ACPI: DSDT CF7F8000, 40AD (r2 INTEL DX58SO2 25B MSFT 100000D) (XEN) ACPI: FACS CF72A000, 0040 (XEN) ACPI: APIC CF7F7000, 0138 (r2 INTEL DX58SO2 25B MSFT 100000D) (XEN) ACPI: WDDT CF7F6000, 0040 (r1 INTEL DX58SO2 25B MSFT 100000D) (XEN) ACPI: MCFG CF7F5000, 003C (r1 INTEL DX58SO2 25B MSFT 100000D) (XEN) ACPI: ASF! CF7F4000, 00AC (r32 INTEL DX58SO2 25B MSFT 100000D) (XEN) ACPI: HPET CF7F3000, 0038 (r1 INTEL DX58SO2 25B MSFT 100000D) (XEN) ACPI: SSDT CF7E2000, E014 (r1 INTEL SSDT PM 25B MSFT 100000D) (XEN) ACPI: DMAR CF7DF000, 0180 (r1 INTEL DX58SO2 25B MSFT 100000D) (XEN) ACPI: WDTT CF7F1000, 020C (r2 INTEL DX58SO2 25B MSFT 100000D) (XEN) ACPI: ASPT CF7F2000, 0034 (r6 INTEL PerfTune 25B MSFT 100000D) (XEN) System RAM: 12277MB (12571732kB) (XEN) Domain heap initialised (XEN) Processor #0 6:12 APIC version 21 (XEN) Processor #16 6:12 APIC version 21 (XEN) Processor #2 6:12 APIC version 21 (XEN) Processor #18 6:12 APIC version 21 (XEN) Processor #4 6:12 APIC version 21 (XEN) Processor #20 6:12 APIC version 21 (XEN) Processor #1 6:12 APIC version 21 (XEN) Processor #17 6:12 APIC version 21 (XEN) Processor #3 6:12 APIC version 21 (XEN) Processor #19 6:12 APIC version 21 (XEN) Processor #5 6:12 APIC version 21 (XEN) Processor #21 6:12 APIC version 21 (XEN) IOAPIC[0]: apic_id 8, version 32, address 0xfec00000, GSI 0-23 (XEN) Enabling APIC mode: Phys. Using 1 I/O APICs (XEN) Table is not found! (XEN) Using scheduler: SMP Credit Scheduler (credit) (XEN) Detected 2800.163 MHz processor. (XEN) Initing memory sharing. (XEN) Intel VT-d Snoop Control not enabled. (XEN) Intel VT-d Dom0 DMA Passthrough not enabled. (XEN) Intel VT-d Queued Invalidation enabled. (XEN) Intel VT-d Interrupt Remapping enabled. (XEN) Intel VT-d Shared EPT tables not enabled. (XEN) I/O virtualisation enabled (XEN) - Dom0 mode: Relaxed (XEN) Enabled directed EOI with ioapic_ack_old on! (XEN) ENABLING IO-APIC IRQs (XEN) -> Using old ACK method (XEN) Platform timer is 14.318MHz HPET (XEN) Allocated console ring of 32 KiB. (XEN) VMX: Supported advanced features: (XEN) - APIC MMIO access virtualisation (XEN) - APIC TPR shadow (XEN) - Extended Page Tables (EPT) (XEN) - Virtual-Processor Identifiers (VPID) (XEN) - Virtual NMI (XEN) - MSR direct-access bitmap (XEN) - Unrestricted Guest (XEN) EPT supports 1GB super page. (XEN) EPT supports 2MB super page. (XEN) HVM: ASIDs enabled. (XEN) HVM: VMX enabled (XEN) HVM: Hardware Assisted Paging detected. (XEN) Brought up 12 CPUs (XEN) *** LOADING DOMAIN 0 *** (XEN) Xen kernel: 64-bit, lsb, compat32 (XEN) Dom0 kernel: 64-bit, lsb, paddr 0x1000000 -> 0x16c0000 (XEN) PHYSICAL MEMORY ARRANGEMENT: (XEN) Dom0 alloc.: 0000000324000000->0000000326000000 (3057929 pages to be allocated) (XEN) Init. ramdisk: 000000032fbb6000->0000000330000000 (XEN) VIRTUAL MEMORY ARRANGEMENT: (XEN) Loaded kernel: ffffffff81000000->ffffffff816c0000 (XEN) Init. ramdisk: 0000000000000000->0000000000000000 (XEN) Phys-Mach map: ffffea0000000000->ffffea0001766a98 (XEN) Start info: ffffffff816c0000->ffffffff816c04b4 (XEN) Page tables: ffffffff816c1000->ffffffff816d0000 (XEN) Boot stack: ffffffff816d0000->ffffffff816d1000 (XEN) TOTAL: ffffffff80000000->ffffffff81800000 (XEN) ENTRY ADDRESS: ffffffff81000000 (XEN) Dom0 has maximum 12 VCPUs (XEN) Scrubbing Free RAM: .done. (XEN) Xen trace buffers: disabled (XEN) Std. Loglevel: Errors and warnings (XEN) Guest Loglevel: Nothing (Rate-limited: Errors and warnings) (XEN) Xen is relinquishing VGA console. (XEN) *** Serial input -> DOM0 (type \047CTRL-a\047 three times to switch input to Xen) (XEN) Freed 216kB init memory. --=-q9XhtxH26qUP7nMwdumE Content-Disposition: attachment; filename="xm-info.txt" Content-Type: text/plain; name="xm-info.txt"; charset="UTF-8" Content-Transfer-Encoding: 7bit host : kali release : 2.6.38-xen-kali version : #6 SMP Tue Sep 13 23:10:53 CEST 2011 machine : x86_64 nr_cpus : 12 nr_nodes : 1 cores_per_socket : 6 threads_per_core : 2 cpu_mhz : 2800 hw_caps : bfebfbff:2c100800:00000000:00003f40:029ae3bf:00000000:00000001:00000000 virt_caps : hvm hvm_directio total_memory : 12277 free_memory : 15 free_cpus : 0 xen_major : 4 xen_minor : 1 xen_extra : .1 xen_caps : xen-3.0-x86_64 xen-3.0-x86_32p hvm-3.0-x86_32 hvm-3.0-x86_32p hvm-3.0-x86_64 xen_scheduler : credit xen_pagesize : 4096 platform_params : virt_start=0xffff800000000000 xen_changeset : unavailable xen_commandline : iommu=1 cc_compiler : gcc version 4.5.3 (Gentoo 4.5.3-r1 p1.0, pie-0.4.5) cc_compile_by : root cc_compile_domain : ninth-art.net cc_compile_date : Fri Sep 9 21:36:17 CEST 2011 xend_config_format : 4 --=-q9XhtxH26qUP7nMwdumE Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel --=-q9XhtxH26qUP7nMwdumE-- From xen-devel-bounces@lists.xensource.com Tue Sep 13 15:43:43 2011 Return-path: Envelope-to: www-data@lists.xensource.com Delivery-date: Tue, 13 Sep 2011 15:43:43 -0700 Received: from localhost ([127.0.0.1] helo=lists.colo.xensource.com) by lists.xensource.com with esmtp (Exim 4.43) id 1R3bhf-0001yx-I5; Tue, 13 Sep 2011 15:43:43 -0700 Received: from mail182.messagelabs.com ([85.158.139.83]) by lists.xensource.com with esmtp (Exim 4.43) id 1R3bgm-0001m6-V6 for xen-devel@lists.xensource.com; Tue, 13 Sep 2011 15:42:49 -0700 X-Env-Sender: Ian.Jackson@eu.citrix.com X-Msg-Ref: server-5.tower-182.messagelabs.com!1315953765!13227834!1 X-Originating-IP: [62.200.22.115] X-StarScan-Version: 6.3.6; banners=-,-,- X-VirusChecked: Checked Received: (qmail 14728 invoked from network); 13 Sep 2011 22:42:45 -0000 Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115) by server-5.tower-182.messagelabs.com with RC4-SHA encrypted SMTP; 13 Sep 2011 22:42:45 -0000 X-IronPort-AV: E=Sophos;i="4.68,376,1312156800"; d="scan'208";a="7781147" Received: from lonpmailmx01.citrite.net ([10.30.203.162]) by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5; 13 Sep 2011 22:42:45 +0000 Received: from woking.xci-test.com (10.80.248.135) by smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id 8.3.137.0; Tue, 13 Sep 2011 23:42:45 +0100 Received: from osstest by woking.xci-test.com with local (Exim 4.69) (envelope-from ) id 1R3bgi-0003Xw-P8; Tue, 13 Sep 2011 23:42:44 +0100 To: xen-devel@lists.xensource.com Message-ID: From: xen.org Date: Tue, 13 Sep 2011 23:42:44 +0100 MIME-Version: 1.0 Content-Type: text/plain Cc: ian.jackson@eu.citrix.com, keir@xen.org, stefano.stabellini@eu.citrix.com Subject: [Xen-devel] [xen-unstable bisection] complete build-i386-oldkern X-BeenThere: xen-devel@lists.xensource.com X-Mailman-Version: 2.1.5 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xensource.com Errors-To: xen-devel-bounces@lists.xensource.com branch xen-unstable xen branch xen-unstable job build-i386-oldkern test xen-build Tree: linux http://hg.uk.xensource.com/linux-2.6.18-xen.hg Tree: xen http://hg.uk.xensource.com/xen-unstable.hg *** Found and reproduced problem changeset *** Bug is in tree: xen http://hg.uk.xensource.com/xen-unstable.hg Bug introduced: 0d21b68f528b Bug not present: d1d6abc1db20 changeset: 23828:0d21b68f528b user: Stefano Stabellini date: Tue Sep 13 10:27:20 2011 +0100 Move the ioemu-dir-find shell script to an external file Add support for configuring upstream qemu and rename ioemu-remote ioemu-dir-remote. Signed-off-by: Stefano Stabellini For bisection revision-tuple graph see: http://www.chiark.greenend.org.uk/~xensrcts/results/bisect.xen-unstable.build-i386-oldkern.xen-build.html Revision IDs in each graph node refer, respectively, to the Trees above. ---------------------------------------- Searching for failure / basis pass: 8903 fail [host=itch-mite] / 8873 [host=lace-bug] 8872 [host=lace-bug] 8871 [host=woodlouse] 8870 [host=lace-bug] 8869 [host=woodlouse] 8865 ok. Failure / basis pass flights: 8903 / 8865 (tree in basispass but not in latest: qemu) Tree: linux http://hg.uk.xensource.com/linux-2.6.18-xen.hg Tree: xen http://hg.uk.xensource.com/xen-unstable.hg Latest 700f70b60d4b 51913fe3d25a Basis pass 700f70b60d4b 0312575dc35e Generating revisions with ./adhoc-revtuple-generator http://hg.uk.xensource.com/linux-2.6.18-xen.hg#700f70b60d4b-700f70b60d4b http://hg.uk.xensource.com/xen-unstable.hg#0312575dc35e-51913fe3d25a pulling from http://hg.uk.xensource.com/xen-unstable.hg searching for changes no changes found pulling from http://hg.uk.xensource.com/xen-unstable.hg searching for changes no changes found Loaded 1001 nodes in revision graph Searching for test results: 8865 pass 700f70b60d4b 0312575dc35e 8869 [host=woodlouse] 8870 [host=lace-bug] 8871 [host=woodlouse] 8872 [host=lace-bug] 8873 [host=lace-bug] 8876 fail 700f70b60d4b 64aab9a077ea 8903 fail 700f70b60d4b 51913fe3d25a 8905 [host=lace-bug] 8906 pass 700f70b60d4b 0312575dc35e 8907 fail 700f70b60d4b 51913fe3d25a 8884 [host=lace-bug] 8908 fail 700f70b60d4b 1b80eaeeba7b 8909 pass 700f70b60d4b d1d6abc1db20 8910 fail 700f70b60d4b 0d21b68f528b 8911 pass 700f70b60d4b d1d6abc1db20 8912 fail 700f70b60d4b 0d21b68f528b 8895 [host=lace-bug] 8913 pass 700f70b60d4b d1d6abc1db20 8914 fail 700f70b60d4b 0d21b68f528b Searching for interesting versions Result found: flight 8865 (pass), for basis pass Result found: flight 8903 (fail), for basis failure Repro found: flight 8906 (pass), for basis pass Repro found: flight 8907 (fail), for basis failure 0 revisions at 700f70b60d4b d1d6abc1db20 No revisions left to test, checking graph state. Result found: flight 8909 (pass), for last pass Result found: flight 8910 (fail), for first failure Repro found: flight 8911 (pass), for last pass Repro found: flight 8912 (fail), for first failure Repro found: flight 8913 (pass), for last pass Repro found: flight 8914 (fail), for first failure *** Found and reproduced problem changeset *** Bug is in tree: xen http://hg.uk.xensource.com/xen-unstable.hg Bug introduced: 0d21b68f528b Bug not present: d1d6abc1db20 pulling from http://hg.uk.xensource.com/xen-unstable.hg searching for changes no changes found changeset: 23828:0d21b68f528b user: Stefano Stabellini date: Tue Sep 13 10:27:20 2011 +0100 Move the ioemu-dir-find shell script to an external file Add support for configuring upstream qemu and rename ioemu-remote ioemu-dir-remote. Signed-off-by: Stefano Stabellini Revision graph left in /home/xc_osstest/results/bisect.xen-unstable.build-i386-oldkern.xen-build.{dot,ps,png,html}. ---------------------------------------- 8914: ALL FAIL flight 8914 xen-unstable real-bisect [real] http://www.chiark.greenend.org.uk/~xensrcts/logs/8914/ jobs: build-i386-oldkern fail ------------------------------------------------------------ sg-report-flight on woking.cam.xci-test.com logs: /home/xc_osstest/logs images: /home/xc_osstest/images Logs, config files, etc. are available at http://www.chiark.greenend.org.uk/~xensrcts/logs Test harness code can be found at http://xenbits.xensource.com/gitweb?p=osstest.git;a=summary _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel From xen-devel-bounces@lists.xensource.com Tue Sep 13 16:15:32 2011 Return-path: Envelope-to: www-data@lists.xensource.com Delivery-date: Tue, 13 Sep 2011 16:15:32 -0700 Received: from localhost ([127.0.0.1] helo=lists.colo.xensource.com) by lists.xensource.com with esmtp (Exim 4.43) id 1R3cCR-0002p5-Tn; Tue, 13 Sep 2011 16:15:31 -0700 Received: from mail27.messagelabs.com ([193.109.254.147]) by lists.xensource.com with esmtp (Exim 4.43) id 1R3cBN-0002cF-Au for xen-devel@lists.xensource.com; Tue, 13 Sep 2011 16:14:27 -0700 X-Env-Sender: nathan@gt.net X-Msg-Ref: server-10.tower-27.messagelabs.com!1315955641!35610480!1 X-Originating-IP: [208.70.244.21] X-StarScan-Version: 6.3.6; banners=-,-,- X-VirusChecked: Checked Received: (qmail 3114 invoked from network); 13 Sep 2011 23:14:03 -0000 Received: from gossamer.nmsrv.com (HELO gossamer.nmsrv.com) (208.70.244.21) by server-10.tower-27.messagelabs.com with DHE-RSA-AES256-SHA encrypted SMTP; 13 Sep 2011 23:14:03 -0000 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=gt.net; h=message-id:date :from:mime-version:to:cc:subject:references:in-reply-to :content-type:content-transfer-encoding; s=mail; bh=kMBRUYOcYb95 nEhnQZ9iqkc7mB0=; b=F5e0yevBis0oCYbpHq5Y0HhPzdFqbtkSVnYlHrAJibGp e/6fQuSg/pcdZJa8Kpz4PzXskXMju2dHyOBgAqIi5TQJ2mQF3kLhAMAWOwmuBQHG p5WsvbpxytG83hAoLHSTzF8k7FzFQTVJrB5iylI2wwkuSPhtGoWAcvXG3JIxCO4= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gt.net; h=message-id:date :from:mime-version:to:cc:subject:references:in-reply-to :content-type:content-transfer-encoding; q=dns; s=mail; b=JDFY7i Sp5Vki5x0rCBjShSevXqM7ixAnrU5IZHJa/I19rkQLgHnoFXN0hs4JbDXPU8Y5Ta FL6iTDfUwHp95x1loIA3HEvwqGkFUKBTns7FQMg+uHOy33zC12JXXDHhqp5kHRUL f3r9aVsj+1w5gzOg/jnrKkjC3XkneeBAfzRrA= Received: (qmail 24287 invoked from network); 13 Sep 2011 23:14:19 -0000 X-AntiVirus: Clean Received: from gateway.gossamer-threads.com (HELO ?192.168.1.152?) (nathan@gossamer-threads.com@208.70.247.145) by gossamer.nmsrv.com with ESMTPSA (DHE-RSA-CAMELLIA256-SHA encrypted); 13 Sep 2011 23:14:19 -0000 Message-ID: <4E6FE3CB.30209@gt.net> Date: Tue, 13 Sep 2011 16:14:19 -0700 From: Nathan March User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:7.0) Gecko/20110905 Thunderbird/7.0 MIME-Version: 1.0 To: therion@ninth-art.de Subject: Re: [Xen-devel] Several issues with Xen 4.1.1 regarding Windows guests (and more...) References: <1315951748.7224.5.camel@kali.ninth-art.net> In-Reply-To: <1315951748.7224.5.camel@kali.ninth-art.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: xen-devel@lists.xensource.com X-BeenThere: xen-devel@lists.xensource.com X-Mailman-Version: 2.1.5 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xensource.com Errors-To: xen-devel-bounces@lists.xensource.com On 9/13/2011 3:09 PM, Georg Bege wrote: > Hello > > Im experiencing serveral issues right now, Im not well Xen experienced - > I tried it first in '06 and staid off from it since last week. > > b) I managed to install Windows XP fine, however the performance (I/O in > general) is quite poor compared to VirtualBox. Can't comment on the rest, but have you installed the gplpv drivers? http://www.meadowcourt.org/downloads/ The wiki has some details but is quite out of date: http://wiki.xensource.com/xenwiki/XenWindowsGplPv On win2008 I install the OS, do a "bcedit /set testsigning on", reboot, then install the gplpv. - Nathan _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel From xen-devel-bounces@lists.xensource.com Tue Sep 13 16:52:18 2011 Return-path: Envelope-to: www-data@lists.xensource.com Delivery-date: Tue, 13 Sep 2011 16:52:18 -0700 Received: from localhost ([127.0.0.1] helo=lists.colo.xensource.com) by lists.xensource.com with esmtp (Exim 4.43) id 1R3cm2-0003o6-8I; Tue, 13 Sep 2011 16:52:18 -0700 Received: from mail182.messagelabs.com ([85.158.139.83]) by lists.xensource.com with smtp (Exim 4.43) id 1R3cl3-0003bA-KJ for xen-devel@lists.xensource.com; Tue, 13 Sep 2011 16:51:19 -0700 X-Env-Sender: jim_burn@bellsouth.net X-Msg-Ref: server-7.tower-182.messagelabs.com!1315957871!13211167!1 X-Originating-IP: [66.94.237.138] X-StarScan-Version: 6.3.6; banners=-,-,- X-VirusChecked: Checked Received: (qmail 22131 invoked from network); 13 Sep 2011 23:51:12 -0000 Received: from nm4-vm0.access.bullet.mail.mud.yahoo.com (HELO nm4-vm0.access.bullet.mail.mud.yahoo.com) (66.94.237.138) by server-7.tower-182.messagelabs.com with SMTP; 13 Sep 2011 23:51:12 -0000 Received: from [66.94.237.195] by nm4.access.bullet.mail.mud.yahoo.com with NNFMP; 13 Sep 2011 23:51:11 -0000 Received: from [66.94.237.99] by tm6.access.bullet.mail.mud.yahoo.com with NNFMP; 13 Sep 2011 23:51:10 -0000 Received: from [127.0.0.1] by omp1004.access.mail.mud.yahoo.com with NNFMP; 13 Sep 2011 23:51:10 -0000 X-Yahoo-Newman-Id: 938171.49717.bm@omp1004.access.mail.mud.yahoo.com Received: (qmail 60123 invoked from network); 13 Sep 2011 23:51:10 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=bellsouth.net; s=s1024; t=1315957870; bh=HYs9rh6PHYNsFLETtemQgOC1fpOf5YlbpuIAvZMdKsc=; h=X-Yahoo-Newman-Property:X-YMail-OSG:X-Yahoo-SMTP:Received:From:To:Cc:Subject:Date:Message-ID:User-Agent:In-Reply-To:References:MIME-Version:Content-Type:Content-Transfer-Encoding; b=Ftd9Bbx7afeJotLsulOvLQKwmllzdishxI8UDwRAD0nX0sQR77Lpv3LUe0WvVhMJw1IlDlomhn06+vUw7geHTJvmDU1cS9+scY6cBcCYZnsqOVWEJfM404d2qkryRxI1Z0usM9pRdWKGxcGRiFaLeLuhxgMo5UerFxWuH5kNlcU= X-Yahoo-Newman-Property: ymail-3 X-YMail-OSG: lZcKNAMVM1n.UhmINgEATa1CqVmLi7XZlY9Nv8ozu3Tejq8 lYKKXjvaEqLsDxLO2b02YORWBodKOhEVvWXuWLOgPEyxW.kQmIeZ4VSQ0iPr ecwCoWaDiiWEFz59I39angay7Y0szStFNAC0tK8.uqmPvBqmq1PkpiZuwqy1 sXK7AqYFGOOrT7hLThY0Ho_qqTuNc_lN9DUye_LC444AOuQioQLmCPdoRT9p H.tTsZ7MAI3q5lBKZkehEtBiPewqXkZleQcCrKH.ucxLmyUdYUQ7EiJS1Cix 4Q6kulLS5_yTlOaIEOIxG7uJnIielmhon0dRR3VSOhdET2T1R4EB9rPxc3gp BAq_6a3t_t5fty4x.wmyAekkKrw3QD0XDrRNXCLOFpeWNPT_FHncS3v65mKG KMaDmYhv6 X-Yahoo-SMTP: g0AhWW2swBA2djJKuhuwxPlPqLrHlDrycdPnfR9kZNrpKCA- Received: from dell4550.localnet (jim_burn@74.232.119.247 with plain) by smtp103.sbc.mail.mud.yahoo.com with SMTP; 13 Sep 2011 16:51:02 -0700 PDT From: jim burns To: Pasi =?ISO-8859-1?Q?K=E4rkk=E4inen?= , xen-devel@lists.xensource.com, xen-users@lists.xensource.com Date: Tue, 13 Sep 2011 19:50:55 -0400 Message-ID: <1856036.eYCcuDQrZC@dell4550> User-Agent: KMail/4.7.1 (Linux/2.6.37.6-0.7-default; KDE/4.7.1; i686; ; ) In-Reply-To: <20110913085559.GG12984@reaktio.net> References: <201107231426.56811.jim_burn@bellsouth.net> <1342436.B0x3ddQn4U@dell4550> <20110913085559.GG12984@reaktio.net> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="nextPart1926288.ImhURyU77f" Content-Transfer-Encoding: 7Bit Cc: Todd Deshane , Fedora Xen List Subject: [Xen-devel] Re: [Xen-users] Continuing BUG:-iness booting Fedora Rawhide 3.1.0-rc's (was Summary: Experiences setting up a debug serial port) X-BeenThere: xen-devel@lists.xensource.com X-Mailman-Version: 2.1.5 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xensource.com Errors-To: xen-devel-bounces@lists.xensource.com --nextPart1926288.ImhURyU77f Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8" On Tue September 13 2011, 11:55:59 AM, Pasi K=C3=A4rkk=C3=A4inen wrote:= > On Mon, Sep 12, 2011 at 04:07:21PM -0400, jim burns wrote: > > On Mon September 12 2011, 10:36:23 AM, Pasi K=C3=A4rkk=C3=A4inen wr= ote: > > > > Sure, thanx, attached. Do you need a debug log also > > > > (initcall_debug > > > > debug loglevel=3D10)? > > > > > >=20 > > > > > > Sure, it doesn't hurt.. > > > >=20 > > > > I'll get it to you in a couple of days. > > > >=20 >=20 > Ok, thanks! Rawhide just came out with 3.1.0-0.rc6.git0.0.fc17.x86_64 , and the BUG= :s are=20 still the same as in the last log I sent. However, as promised I have a= ttached=20 the initcall_debug log, but for rc6. I had an interesting problem with my grub stanza that made me fear that= it was=20 back to not booting at all under xen. It looked just like the same prob= lem=20 that rc0 and rc1 had. The problem was that the xen option=20 'serial_tx_buffer=3D64k' was too small, and was causing the boot to sta= ll. I=20 upped the buffer to 256k. I'm including the output from the too small b= uffer=20 below, merely for amusement - it was my problem, not xen's. Using the following grub stanza: title Xen Dom0 w/debug console (3.1.0-0.rcx.gity.z.fc17.x86_64) root (hd0,1) kernel /xen.gz cpufreq=3Dxen loglvl=3Dall guest_loglvl=3Dall=20= serial_tx_buffer=3D256k console_to_ring noreboot com1=3D115200,8n1,0xdf= f8,19=20 console=3Dcom1 module /vmlinuz ro root=3D/dev/mapper/vg_insp6400-lv_root=20 SYSFONT=3Dlatarcyrheb-sun16 LANG=3Den_US.UTF-8 KEYTABLE=3Dus console=3D= hvc0=20 earlyprintk=3Dxen nomodeset initcall_debug debug loglevel=3D10 module /initramfs where vmlinuz and initramfs are soft links, and x,y,z is rc5.git0.0 for= the=20 attached file with 'initcall_debug', and rc6.git0.0 for the (unimportan= t)=20 crash shown below (with the 64k buffer). > also: I assume you won't get any BUGs when booting the same kernel > on baremetal/native? That has been correct for rc2 - rc6. From an earlier post in the origin= al=20 'Summary: Experiences setting up a debug serial port' thread: > On Mon August 15 2011, 4:04:20 AM, jim burns wrote: >> Pls cc me with responses, as I'm not subscribed. > Yay! After a string of fedora rawhide 3.1.0-rc0 and -rc1's that did n= ot > boot under xen, 3.1.0-0.rc2.git0.1.fc17.x86_64 boots under xen, it h= as the > vga patch, and xen-pciback correctly siezes my wireless device. > Unfortunately, while a baremetal boot is clean, a xen boot has severa= l > BUG:'s of the form: The (unimportant) rc6 crash: __ __ _ _ _ _ _____ __ _ _____=20 \ \/ /___ _ __ | || | / | / | |___ / / _| ___/ |___ | \ // _ \ '_ \ | || |_ | | | |__ |_ \ | |_ / __| | / /=20 / \ __/ | | | |__ _|| |_| |__|__) || _| (__| | / / =20 /_/\_\___|_| |_| |_|(_)_(_)_| |____(_)_| \___|_|/_/ =20 =20 (XEN) Xen version 4.1.1 (mockbuild@phx2.fedoraproject.org) (gcc version= 4.6.1=20 20110715 (Red Hat 4.6.1-3) (GCC) ) Sun Aug 14 14:14:02 UTC 2011 (XEN) Latest ChangeSet: unavailable (XEN) Bootloader: GNU GRUB 0.97-71.fc15 (XEN) Command line: cpufreq=3Dxen loglvl=3Dall guest_loglvl=3Dall=20 serial_tx_buffer=3D64k console_to_ring noreboot com1=3D115200,8n1,0xdff= 8,19=20 console=3Dcom1 (XEN) Video information: (XEN) VGA is text mode 80x25, font 8x16 (XEN) VBE/DDC methods: V2; EDID transfer time: 1 seconds (XEN) Disc information: (XEN) Found 1 MBR signatures (XEN) Found 1 EDD information structures (XEN) Xen-e820 RAM map: (XEN) 0000000000000000 - 000000000009f000 (usable) (XEN) 000000000009f000 - 00000000000a0000 (reserved) (XEN) 0000000000100000 - 000000007f6d3400 (usable) (XEN) 000000007f6d3400 - 0000000080000000 (reserved) (XEN) 00000000f0000000 - 00000000f4007000 (reserved) (XEN) 00000000f4008000 - 00000000f400c000 (reserved) (XEN) 00000000fec00000 - 00000000fec10000 (reserved) (XEN) 00000000fed20000 - 00000000feda0000 (reserved) (XEN) 00000000fee00000 - 00000000fee10000 (reserved) (XEN) 00000000ffb00000 - 0000000100000000 (reserved) (XEN) System RAM: 2038MB (2087368kB) (XEN) ACPI: RSDP 000FC1D0, 0014 (r0 DELL ) (XEN) ACPI: RSDT 7F6D3A0F, 0040 (r1 DELL M07 27D7060D ASL = 61) (XEN) ACPI: FACP 7F6D4800, 0074 (r1 DELL M07 27D7060D ASL = 61) (XEN) ACPI: DSDT 7F6D5400, 4766 (r1 INT430 SYSFexxx 1001 INTL 20050= 624) (XEN) ACPI: FACS 7F6E3C00, 0040 (XEN) ACPI: HPET 7F6D4F00, 0038 (r1 DELL M07 1 ASL = 61) (XEN) ACPI: APIC 7F6D5000, 0068 (r1 DELL M07 27D7060D ASL = 47) (XEN) ACPI: MCFG 7F6D4FC0, 003E (r16 DELL M07 27D7060D ASL = 61) (XEN) ACPI: SLIC 7F6D509C, 0176 (r1 DELL M07 27D7060D ASL = 61) (XEN) ACPI: BOOT 7F6D4BC0, 0028 (r1 DELL M07 27D7060D ASL = 61) (XEN) ACPI: SSDT 7F6D3A4F, 04DC (r1 PmRef CpuPm 3000 INTL 20050= 624) (XEN) No NUMA configuration found (XEN) Faking a node at 0000000000000000-000000007f6d3000 (XEN) Domain heap initialised (XEN) DMI 2.4 present. (XEN) Using APIC driver default (XEN) ACPI: PM-Timer IO Port: 0x1008 (XEN) ACPI: ACPI SLEEP INFO: pm1x_cnt[1004,0], pm1x_evt[1000,0] (XEN) ACPI: wakeup_vec[7f6e3c0c], vec_size[20] (XEN) ACPI: Local APIC address 0xfee00000 (XEN) ACPI: LAPIC (acpi_id[0x00] lapic_id[0x00] enabled) (XEN) Processor #0 6:15 APIC version 20 (XEN) ACPI: LAPIC (acpi_id[0x01] lapic_id[0x01] enabled) (XEN) Processor #1 6:15 APIC version 20 (XEN) ACPI: LAPIC_NMI (acpi_id[0x00] high edge lint[0x1]) (XEN) ACPI: LAPIC_NMI (acpi_id[0x01] high edge lint[0x1]) (XEN) ACPI: IOAPIC (id[0x02] address[0xfec00000] gsi_base[0]) (XEN) IOAPIC[0]: apic_id 2, version 32, address 0xfec00000, GSI 0-23 (XEN) ACPI: INT_SRC_OVR (bus 0 bus_irq 0 global_irq 2 dfl dfl) (XEN) ACPI: INT_SRC_OVR (bus 0 bus_irq 9 global_irq 9 high level) (XEN) ACPI: IRQ0 used by override. (XEN) ACPI: IRQ2 used by override. (XEN) ACPI: IRQ9 used by override. (XEN) Enabling APIC mode: Flat. Using 1 I/O APICs (XEN) ACPI: HPET id: 0x8086a201 base: 0xfed00000 (XEN) PCI: MCFG configuration 0: base f0000000 segment 0 buses 0 - 63 (XEN) PCI: MCFG area at f0000000 reserved in E820 (XEN) Table is not found! (XEN) Using ACPI (MADT) for SMP configuration information (XEN) IRQ limits: 24 GSI, 376 MSI/MSI-X (XEN) Using scheduler: SMP Credit Scheduler (credit) (XEN) Detected 1828.797 MHz processor. (XEN) Initing memory sharing. (XEN) mce_intel.c:1162: MCA Capability: BCAST 1 SER 0 CMCI 0 firstbank = 1=20 extended MCE MSR 0 (XEN) Intel machine check reporting enabled (XEN) I/O virtualisation disabled (XEN) ENABLING IO-APIC IRQs (XEN) -> Using new ACK method (XEN) ..TIMER: vector=3D0xF0 apic1=3D0 pin1=3D2 apic2=3D-1 pin2=3D-1 (XEN) Platform timer is 14.318MHz HPET =EF=BF=BD(XEN) Allocated console ring of 16 KiB. (XEN) VMX: Supported advanced features: (XEN) - APIC TPR shadow (XEN) - MSR direct-access bitmap (XEN) HVM: ASIDs disabled. (XEN) HVM: VMX enabled (XEN) Brought up 2 CPUs (XEN) HPET: 3 timers in total, 0 timers will be used for broadcast (XEN) ACPI sleep modes: S3 (XEN) mcheck_poll: Machine check polling timer started. (XEN) *** LOADING DOMAIN 0 *** (XEN) Xen kernel: 64-bit, lsb, compat32 (XEN) Dom0 kernel: 64-bit, PAE, lsb, paddr 0x1000000 -> 0x2ae6000 (XEN) PHYSICAL MEMORY ARRANGEMENT: (XEN) Dom0 alloc.: 0000000074000000->0000000078000000 (456574 pages = to be=20 allocated) (XEN) Init. ramdisk: 000000007c9bf000->000000007f1ff200 (XEN) VIRTUAL MEMORY ARRANGEMENT: (XEN) Loaded kernel: ffffffff81000000->ffffffff82ae6000 (XEN) Init. ramdisk: ffffffff82ae6000->ffffffff85326200 (XEN) Phys-Mach map: ffffffff85327000->ffffffff856d6df8 (XEN) Start info: ffffffff856d7000->ffffffff856d74b4 (XEN) Page tables: ffffffff856d8000->ffffffff85707000 (XEN) Boot stack: ffffffff85707000->ffffffff85708000 (XEN) TOTAL: ffffffff80000000->ffffffff85800000 (XEN) ENTRY ADDRESS: ffffffff81d53200 (XEN) Dom0 has maximum 2 VCPUs (XEN) Scrubbing Free RAM: .done. (XEN) Xen trace buffers: disabled (XEN) Std. Loglevel: All (XEN) Guest Loglevel: All (XEN) *** Serial input -> DOM0 (type 'CTRL-a' three times to switch inp= ut to=20 Xen) (XEN) Freed 224kB init memory. mapping kernel into physical memory Xen: setup ISA identity maps about to get started... [ 0.000000] Initializing cgroup subsys cpuset [ 0.000000] Initializing cgroup subsys cpu [ 0.000000] Linux version 3.1.0-0.rc6.git0.0.fc17.x86_64=20 (mockbuild@x86-02.phx2.fedoraproject.org) (gcc version 4.6.1 20110824 (= Red Hat=20 4.6.1-8) (GCC) ) #1 SMP Mon Sep 12 22:56:38 UTC 2011 [ 0.000000] Command line: ro root=3D/dev/mapper/vg_insp6400-lv_root=20= SYSFONT=3Dlatarcyrheb-sun16 LANG=3Den_US.UTF-8 KEYTABLE=3Dus console=3D= hvc0=20 earlyprintk=3Dxen nomodeset initcall_debug debug loglevel=3D10 [ 0.000000] released 0 pages of unused memory [ 0.000000] Set 526733 page(s) to 1-1 mapping. [ 0.000000] BIOS-provided physical RAM map: [ 0.000000] Xen: 0000000000000000 - 000000000009f000 (usable) [ 0.000000] Xen: 000000000009f000 - 0000000000100000 (reserved) [ 0.000000] Xen: 0000000000100000 - 0000000075fbf000 (usable) [ 0.000000] Xen: 0000000075fbf000 - 000000007f6d3000 (unusable) [ 0.000000] Xen: 000000007f6d3400 - 0000000080000000 (reserved) [ 0.000000] Xen: 00000000f0000000 - 00000000f4007000 (reserved) [ 0.000000] Xen: 00000000f4008000 - 00000000f400c000 (reserved) [ 0.000000] Xen: 00000000fec00000 - 00000000fec10000 (reserved) [ 0.000000] Xen: 00000000fed20000 - 00000000feda0000 (reserved) [ 0.000000] Xen: 00000000fee00000 - 00000000fee10000 (reserved) [ 0.000000] Xen: 00000000ffb00000 - 0000000100000000 (reserved) [ 0.000000] Xen: 0000000100000000 - 0000000525db7000 (usable) [ 0.000000] bootconsole [xenboot0] enabled [ 0.000000] NX (Execute Disable) protection: active [ 0.000000] DMI 2.4 present. [ 0.000000] DMI: Dell Inc. MM061 /0KD882, = BIOS=20 A17 06/13/2007 [ 0.000000] e820 update range: 0000000000000000 - 0000000000010000 (= usable)=20 =3D=3D> (reserved) [ 0.000000] e820 remove range: 00000000000a0000 - 0000000000100000 (= usable) [ 0.000000] No AGP bridge found [ 0.000000] last_pfn =3D 0x525db7 max_arch_pfn =3D 0x400000000 [ 0.000000] last_pfn =3D 0x75fbf max_arch_pfn =3D 0x400000000 [ 0.000000] initial memory mapped : 0 - 05327000 [ 0.000000] Base memory trampoline at [ffff88000009a000] 9a000 size = 20480 [ 0.000000] init_memory_mapping: 0000000000000000-0000000075fbf000 [ 0.000000] 0000000000 - 0075fbf000 page 4k [ 0.000000] kernel direct mapping tables up to 75fbf000 @ 75c0c000-7= 5fbf000 [ 0.000000] xen: setting RW the range 75f8d000 - 75fbf000 [ 0.000000] init_memory_mapping: 0000000100000000-0000000525db7000 [ 0.000000] 0100000000 - 0525db7000 page 4k [ 0.000000] kernel direct mapping tables up to 525db7000 @=20 732c7000-75c0c000 [ 0.000000] xen: setting RW the range 75407000 - 75c0c000 [ 0.000000] RAMDISK: 02ae6000 - 05327000 [ 0.000000] ACPI: RSDP 00000000000fc1d0 00014 (v00 DELL ) [ 0.000000] ACPI: RSDT 000000007f6d3a0f 00040 (v01 DELL M07 2= 7D7060D=20 ASL 00000061) [ 0.000000] ACPI: FACP 000000007f6d4800 00074 (v01 DELL M07 2= 7D7060D=20 ASL 00000061) [ 0.000000] ACPI: DSDT 000000007f6d5400 04766 (v01 INT430 SYSFexxx 0= 0001001=20 INTL 20050624) [ 0.000000] ACPI: FACS 000000007f6e3c00 00040 [ 0.000000] ACPI: HPET 000000007f6d4f00 00038 (v01 DELL M07 0= 0000001=20 ASL 00000061) [ 0.000000] ACPI: APIC 000000007f6d5000 00068 (v01 DELL M07 2= 7D7060D=20 ASL 00000047) [ 0.000000] ACPI: MCFG 000000007f6d4fc0 0003E (v16 DELL M07 2= 7D7060D=20 ASL 00000061) [ 0.000000] ACPI: SLIC 000000007f6d509c 00176 (v01 DELL M07 2= 7D7060D=20 ASL 00000061) [ 0.000000] ACPI: BOOT 000000007f6d4bc0 00028 (v01 DELL M07 2= 7D7060D=20 ASL 00000061) [ 0.000000] ACPI: SSDT 000000007f6d3a4f 004DC (v01 PmRef CpuPm 0= 0003000=20 INTL 20050624) [ 0.000000] ACPI: Local APIC address 0xfee00000 [ 0.000000] No NUMA configuration found [ 0.000000] Faking a node at 0000000000000000-0000000525db7000 [ 0.000000] Initmem setup node 0 0000000000000000-0000000525db7000 [ 0.000000] NODE_DATA [0000000075faa000 - 0000000075fbefff] [ 0.000000] Zone PFN ranges: [ 0.000000] DMA 0x00000010 -> 0x00001000 [ 0.000000] DMA32 0x00001000 -> 0x00100000 [ 0.000000] Normal 0x00100000 -> 0x00525db7 [ 0.000000] Movable zone start PFN for each node [ 0.000000] early_node_map[3] active PFN ranges [ 0.000000] 0: 0x00000010 -> 0x0000009f [ 0.000000] 0: 0x00000100 -> 0x00075fbf [ 0.000000] 0: 0x00100000 -> 0x00525db7 [ 0.000000] On node 0 totalpages: 4832517 [ 0.000000] DMA zone: 64 pages used for memmap [ 0.000000] DMA zone: 5 pages reserved [ 0.000000] DMA zone: 3914 pages, LIFO batch:0 [ 0.000000] DMA32 zone: 16320 pages used for memmap [ 0.000000] DMA32 zone: 462847 pages, LIFO batch:31 [ 0.000000] Normal zone: 67959 pages used for memmap [ 0.000000] Normal zone: 4281408 pages, LIFO batch:31 [ 0.000000] BUG: unable to handle kernel NULL pointer dereference at= =20 (null) [ 0.000000] IP: [] __xen_set_pte+0x51/0x5b [ 0.000000] PGD 0=20 [ 0.000000] Oops: 0003 [#1] SMP=20 [ 0.000000] CPU 0=20 [ 0.000000] Modules linked in: [ 0.000000]=20 [ 0.000000] Pid: 0, comm: swapper Not tainted=20 3.1.0-0.rc6.git0.0.fc17.x86_64 #1 Dell Inc. MM061 = =20 /0KD882 [ 0.000000] RIP: e030:[] []=20 __xen_set_pte+0x51/0x5b [ 0.000000] RSP: e02b:ffffffff81a01dc8 EFLAGS: 00010096 [ 0.000000] RAX: 00000000ffffffff RBX: ffff880075b01000 RCX:=20 ffffffff829b2000 [ 0.000000] RDX: 0000000010000001 RSI: 8000000075a02065 RDI:=20 ffff880075b01000 [ 0.000000] RBP: ffffffff81a01de8 R08: 0000000000000000 R09:=20 0000000000007ff0 [ 0.000000] R10: 0000000000007ff0 R11: 0000000000007ff0 R12:=20 8000000075a02065 [ 0.000000] R13: 0000000001a02000 R14: ffffffffffffffff R15:=20 0000000000000000 [ 0.000000] FS: 0000000000000000(0000) GS:ffffffff81b7e000(0000)=20= knlGS:0000000000000000 [ 0.000000] CS: e033 DS: 0000 ES: 0000 CR0: 0000000080050033 [ 0.000000] CR2: 0000000000000000 CR3: 0000000001a05000 CR4:=20 0000000000002660 [ 0.000000] DR0: 0000000000000000 DR1: 0000000000000000 DR2:=20 0000000000000000 [ 0.000000] DR3: 0000000000000000 DR6: 0000000000000000 DR7:=20 0000000000000000 [ 0.000000] Process swapper (pid: 0, threadinfo ffffffff81a00000, ta= sk=20 ffffffff81a0d020) [ 0.000000] Stack: [ 0.000000] 00003ffffffff000 ffffffff829b2000 ffff880075b01000=20 8000000075a02065 [ 0.000000] ffffffff81a01e18 ffffffff8100655c 0000000000007ff0=20 ffffffffff600000 [ 0.000000] 8000000075a02065 0000000001a02000 ffffffff81a01e28=20 ffffffff81032ddc [ 0.000000] Call Trace: [ 0.000000] [] xen_set_pte+0x75/0x95 [ 0.000000] [] set_pte+0x10/0x12 [ 0.000000] [] set_pte_vaddr_pud+0x3c/0x4b [ 0.000000] [] xen_set_fixmap+0xb4/0xbb [ 0.000000] [] map_vsyscall+0x50/0x69 [ 0.000000] [] setup_arch+0xa7e/0xb2f [ 0.000000] [] ? printk+0x51/0x53 [ 0.000000] [] start_kernel+0xe1/0x3ea [ 0.000000] [] x86_64_start_reservations+0xaf/0xb= 3 [ 0.000000] [] xen_start_kernel+0x588/0x58f [ 0.000000] Code: df e8 4a 04 03 00 48 89 c7 e8 82 ee ff ff 48 8d 7d= e0 48=20 89 45 e0 4c 89 65 e8 e8 fd f4 ff ff bf 01 00 00 00 e8 a4 f7 ff ff eb 03= <4c>=20 89 23 58 5a 5b 41 5c 5d c3 55 48 89 e5 41 57 41 56 41 55 41=20 [ 0.000000] RIP [] __xen_set_pte+0x51/0x5b [ 0.000000] RSP [ 0.000000] CR2: 0000000000000000 [ 0.000000] ---[ end trace a7919e7f17c0a725 ]--- [ 0.000000] Kernel panic - not syncing: Attempted to kill the idle t= ask! [ 0.000000] Pid: 0, comm: swapper Tainted: G D =20 3.1.0-0.rc6.git0.0.fc17.x86_64 #1 [ 0.000000] Call Trace: [ 0.000000] [] panic+0xa0/0x1b9 [ 0.000000] [] do_exit+0x9e/0x82c [ 0.000000] [] ? kmsg_dump+0x131/0x14f [ 0.000000] [] ? kmsg_dump+0x89/0x14f [ 0.000000] [] oops_end+0xbc/0xc5 [ 0.000000] [] no_context+0x208/0x217 [ 0.000000] [] ? __lock_acquire+0xc5d/0xd0c [ 0.000000] [] __bad_area_nosemaphore+0x1d0/0x1f1= [ 0.000000] [] ?=20 __raw_callee_save_xen_restore_fl+0x11/0x1e [ 0.000000] [] ? __raw_callee_save_xen_save_fl+0x= 11/0x1e [ 0.000000] [] bad_area_nosemaphore+0x13/0x15 [ 0.000000] [] do_page_fault+0x1b1/0x3a2 [ 0.000000] [] ? __raw_callee_save_xen_save_fl+0x= 11/0x1e [ 0.000000] [] ? error_sti+0x5/0x6 [ 0.000000] [] ? restore_args+0x30/0x30 [ 0.000000] [] ? arch_local_save_flags+0xb/0xd [ 0.000000] [] ? trace_hardirqs_off_caller+0x33/0= x90 [ 0.000000] [] ? trace_hardirqs_off_thunk+0x3a/0x= 3c [ 0.000000] [] page_fault+0x25/0x30 [ 0.000000] [] ? __xen_set_pte+0x51/0x5b [ 0.000000] [] ? __xen_set_pte+0x1b/0x5b [ 0.000000] [] xen_set_pte+0x75/0x95 [ 0.000000] [] set_pte+0x10/0x12 [ 0.000000] [] set_pte_vaddr_pud+0x3c/0x4b [ 0.000000] [] xen_set_fixmap+0xb4/0xbb [ 0.000000] [] map_vsyscall+0x50/0x69 [ 0.000000] [] setup_arch+0xa7e/0xb2f [ 0.000000] [] ? printk+0x51/0x53 [ 0.000000] [] start_kernel+0xe1/0x3ea [ 0.000000] [] x86_64_start_reservations+0xaf/0xb= 3 [ 0.000000] [] xen_start_kernel+0x588/0x58f (XEN) Domain 0 crashed: 'noreboot' set - not rebooting. --nextPart1926288.ImhURyU77f Content-Disposition: attachment; filename="konsole.txt" Content-Transfer-Encoding: base64 Content-Type: text/plain; charset="UTF-8"; name="konsole.txt" CgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKIF9fICBfXyAgICAgICAgICAgIF8gIF8gICAgXyAgIF8g ICBfX19fXyAgIF9fICAgICAgXyBfX19fXwogXCBcLyAvX19fIF8gX18gICB8IHx8IHwgIC8gfCAv IHwgfF9fXyAvICAvIF98IF9fXy8gfF9fXyAgfAogIFwgIC8vIF8gXCAnXyBcICB8IHx8IHxfIHwg fCB8IHxfXyB8XyBcIHwgfF8gLyBfX3wgfCAgLyAvCiAgLyAgXCAgX18vIHwgfCB8IHxfXyAgIF98 fCB8X3wgfF9ffF9fKSB8fCAgX3wgKF9ffCB8IC8gLwogL18vXF9cX19ffF98IHxffCAgICB8X3wo XylfKF8pX3wgfF9fX18oXylffCAgXF9fX3xffC9fLwoKKFhFTikgWGVuIHZlcnNpb24gNC4xLjEg KG1vY2tidWlsZEBwaHgyLmZlZG9yYXByb2plY3Qub3JnKSAoZ2NjIHZlcnNpb24gNC42LjEgMjAx MTA3MTUgKFJlZCBIYXQgNC42LjEtMykgKEdDQykgKSBTdW4gQXVnIDE0IDE0OjE0OjAyIFVUQyAy MDExCihYRU4pIExhdGVzdCBDaGFuZ2VTZXQ6IHVuYXZhaWxhYmxlCihYRU4pIEJvb3Rsb2FkZXI6 IEdOVSBHUlVCIDAuOTctNzEuZmMxNQooWEVOKSBDb21tYW5kIGxpbmU6IGNwdWZyZXE9eGVuIGxv Z2x2bD1hbGwgZ3Vlc3RfbG9nbHZsPWFsbCBzZXJpYWxfdHhfYnVmZmVyPTI1NmsgY29uc29sZV90 b19yaW5nIG5vcmVib290IGNvbTE9MTE1MjAwLDhuMSwweGRmZjgsMTkgY29uc29sZT1jb20xCihY RU4pIFZpZGVvIGluZm9ybWF0aW9uOgooWEVOKSAgVkdBIGlzIHRleHQgbW9kZSA4MHgyNSwgZm9u dCA4eDE2CihYRU4pICBWQkUvRERDIG1ldGhvZHM6IFYyOyBFRElEIHRyYW5zZmVyIHRpbWU6IDEg c2Vjb25kcwooWEVOKSBEaXNjIGluZm9ybWF0aW9uOgooWEVOKSAgRm91bmQgMSBNQlIgc2lnbmF0 dXJlcwooWEVOKSAgRm91bmQgMSBFREQgaW5mb3JtYXRpb24gc3RydWN0dXJlcwooWEVOKSBYZW4t ZTgyMCBSQU0gbWFwOgooWEVOKSAgMDAwMDAwMDAwMDAwMDAwMCAtIDAwMDAwMDAwMDAwOWYwMDAg KHVzYWJsZSkKKFhFTikgIDAwMDAwMDAwMDAwOWYwMDAgLSAwMDAwMDAwMDAwMGEwMDAwIChyZXNl cnZlZCkKKFhFTikgIDAwMDAwMDAwMDAxMDAwMDAgLSAwMDAwMDAwMDdmNmQzNDAwICh1c2FibGUp CihYRU4pICAwMDAwMDAwMDdmNmQzNDAwIC0gMDAwMDAwMDA4MDAwMDAwMCAocmVzZXJ2ZWQpCihY RU4pICAwMDAwMDAwMGY0MDA4MDAwIC0gMDAwMDAwMDBmNDAwYzAwMCAocmVzZXJ2ZWQpCihYRU4p ICAwMDAwMDAwMGZlYzAwMDAwIC0gMDAwMDAwMDBmZWMxMDAwMCAocmVzZXJ2ZWQpCihYRU4pICAw MDAwMDAwMGZlZDIwMDAwIC0gMDAwMDAwMDBmZWRhMDAwMCAocmVzZXJ2ZWQpCihYRU4pICAwMDAw MDAwMGZlZTAwMDAwIC0gMDAwMDAwMDBmZWUxMDAwMCAocmVzZXJ2ZWQpCihYRU4pICAwMDAwMDAw MGZmYjAwMDAwIC0gMDAwMDAwMDEwMDAwMDAwMCAocmVzZXJ2ZWQpCihYRU4pIFN5c3RlbSBSQU06 IDIwMzhNQiAoMjA4NzM2OGtCKQooWEVOKSBBQ1BJOiBSU0RQIDAwMEZDMUQwLCAwMDE0IChyMCBE RUxMICApCihYRU4pIEFDUEk6IFJTRFQgN0Y2RDNBMEYsIDAwNDAgKHIxIERFTEwgICAgTTA3ICAg ICAyN0Q3MDYwRCBBU0wgICAgICAgIDYxKQooWEVOKSBBQ1BJOiBGQUNQIDdGNkQ0ODAwLCAwMDc0 IChyMSBERUxMICAgIE0wNyAgICAgMjdENzA2MEQgQVNMICAgICAgICA2MSkKKFhFTikgQUNQSTog RFNEVCA3RjZENTQwMCwgNDc2NiAocjEgSU5UNDMwIFNZU0ZleHh4ICAgICAxMDAxIElOVEwgMjAw NTA2MjQpCihYRU4pIEFDUEk6IEZBQ1MgN0Y2RTNDMDAsIDAwNDAKKFhFTikgQUNQSTogSFBFVCA3 RjZENEYwMCwgMDAzOCAocjEgREVMTCAgICBNMDcgICAgICAgICAgICAxIEFTTCAgICAgICAgNjEp CihYRU4pIEFDUEk6IEFQSUMgN0Y2RDUwMDAsIDAwNjggKHIxIERFTEwgICAgTTA3ICAgICAyN0Q3 MDYwRCBBU0wgICAgICAgIDQ3KQooWEVOKSBBQ1BJOiBNQ0ZHIDdGNkQ0RkMwLCAwMDNFIChyMTYg REVMTCAgICBNMDcgICAgIDI3RDcwNjBEIEFTTCAgICAgICAgNjEpCihYRU4pIEFDUEk6IFNMSUMg N0Y2RDUwOUMsIDAxNzYgKHIxIERFTEwgICAgTTA3ICAgICAyN0Q3MDYwRCBBU0wgICAgICAgIDYx KQooWEVOKSBBQ1BJOiBCT09UIDdGNkQ0QkMwLCAwMDI4IChyMSBERUxMICAgIE0wNyAgICAgMjdE NzA2MEQgQVNMICAgICAgICA2MSkKKFhFTikgQUNQSTogU1NEVCA3RjZEM0E0RiwgMDREQyAocjEg IFBtUmVmICAgIENwdVBtICAgICAzMDAwIElOVEwgMjAwNTA2MjQpCihYRU4pIE5vIE5VTUEgY29u ZmlndXJhdGlvbiBmb3VuZAooWEVOKSBGYWtpbmcgYSBub2RlIGF0IDAwMDAwMDAwMDAwMDAwMDAt MDAwMDAwMDA3ZjZkMzAwMAooWEVOKSBEb21haW4gaGVhcCBpbml0aWFsaXNlZAooWEVOKSBETUkg Mi40IHByZXNlbnQuCihYRU4pIFVzaW5nIEFQSUMgZHJpdmVyIGRlZmF1bHQKKFhFTikgQUNQSTog UE0tVGltZXIgSU8gUG9ydDogMHgxMDA4CihYRU4pIEFDUEk6IEFDUEkgU0xFRVAgSU5GTzogcG0x eF9jbnRbMTAwNCwwXSwgcG0xeF9ldnRbMTAwMCwwXQooWEVOKSBBQ1BJOiAgICAgICAgICAgICAg ICAgIHdha2V1cF92ZWNbN2Y2ZTNjMGNdLCB2ZWNfc2l6ZVsyMF0KKFhFTikgQUNQSTogTG9jYWwg QVBJQyBhZGRyZXNzIDB4ZmVlMDAwMDAKKFhFTikgQUNQSTogTEFQSUMgKGFjcGlfaWRbMHgwMF0g bGFwaWNfaWRbMHgwMF0gZW5hYmxlZCkKKFhFTikgUHJvY2Vzc29yICMwIDY6MTUgQVBJQyB2ZXJz aW9uIDIwCihYRU4pIEFDUEk6IExBUElDIChhY3BpX2lkWzB4MDFdIGxhcGljX2lkWzB4MDFdIGVu YWJsZWQpCihYRU4pIFByb2Nlc3NvciAjMSA2OjE1IEFQSUMgdmVyc2lvbiAyMAooWEVOKSBBQ1BJ OiBMQVBJQ19OTUkgKGFjcGlfaWRbMHgwMF0gaGlnaCBlZGdlIGxpbnRbMHgxXSkKKFhFTikgQUNQ STogTEFQSUNfTk1JIChhY3BpX2lkWzB4MDFdIGhpZ2ggZWRnZSBsaW50WzB4MV0pCihYRU4pIEFD UEk6IElPQVBJQyAoaWRbMHgwMl0gYWRkcmVzc1sweGZlYzAwMDAwXSBnc2lfYmFzZVswXSkKKFhF TikgSU9BUElDWzBdOiBhcGljX2lkIDIsIHZlcnNpb24gMzIsIGFkZHJlc3MgMHhmZWMwMDAwMCwg R1NJIDAtMjMKKFhFTikgQUNQSTogSU5UX1NSQ19PVlIgKGJ1cyAwIGJ1c19pcnEgMCBnbG9iYWxf aXJxIDIgZGZsIGRmbCkKKFhFTikgQUNQSTogSU5UX1NSQ19PVlIgKGJ1cyAwIGJ1c19pcnEgOSBn bG9iYWxfaXJxIDkgaGlnaCBsZXZlbCkKKFhFTikgQUNQSTogSVJRMCB1c2VkIGJ5IG92ZXJyaWRl LgooWEVOKSBBQ1BJOiBJUlEyIHVzZWQgYnkgb3ZlcnJpZGUuCihYRU4pIEFDUEk6IElSUTkgdXNl ZCBieSBvdmVycmlkZS4KKFhFTikgRW5hYmxpbmcgQVBJQyBtb2RlOiAgRmxhdC4gIFVzaW5nIDEg SS9PIEFQSUNzCihYRU4pIEFDUEk6IEhQRVQgaWQ6IDB4ODA4NmEyMDEgYmFzZTogMHhmZWQwMDAw MAooWEVOKSBQQ0k6IE1DRkcgY29uZmlndXJhdGlvbiAwOiBiYXNlIGYwMDAwMDAwIHNlZ21lbnQg MCBidXNlcyAwIC0gNjMKKFhFTikgUENJOiBNQ0ZHIGFyZWEgYXQgZjAwMDAwMDAgcmVzZXJ2ZWQg aW4gRTgyMAooWEVOKSBUYWJsZSBpcyBub3QgZm91bmQhCihYRU4pIFVzaW5nIEFDUEkgKE1BRFQp IGZvciBTTVAgY29uZmlndXJhdGlvbiBpbmZvcm1hdGlvbgooWEVOKSBJUlEgbGltaXRzOiAyNCBH U0ksIDM3NiBNU0kvTVNJLVgKKFhFTikgVXNpbmcgc2NoZWR1bGVyOiBTTVAgQ3JlZGl0IFNjaGVk dWxlciAoY3JlZGl0KQooWEVOKSBEZXRlY3RlZCAxODI4LjgzMSBNSHogcHJvY2Vzc29yLgooWEVO KSBJbml0aW5nIG1lbW9yeSBzaGFyaW5nLgooWEVOKSBtY2VfaW50ZWwuYzoxMTYyOiBNQ0EgQ2Fw YWJpbGl0eTogQkNBU1QgMSBTRVIgMCBDTUNJIDAgZmlyc3RiYW5rIDEgZXh0ZW5kZWQgTUNFIE1T UiAwCihYRU4pIEludGVsIG1hY2hpbmUgY2hlY2sgcmVwb3J0aW5nIGVuYWJsZWQKKFhFTikgSS9P IHZpcnR1YWxpc2F0aW9uIGRpc2FibGVkCihYRU4pIEVOQUJMSU5HIElPLUFQSUMgSVJRcwooWEVO KSAgLT4gVXNpbmcgbmV3IEFDSyBtZXRob2QKKFhFTikgLi5USU1FUjogdmVjdG9yPTB4RjAgYXBp YzE9MCBwaW4xPTIgYXBpYzI9LTEgcGluMj0tMQooWEVOKSBQbGF0Zm9ybSB0aW1lciBpcyAxNC4z MThNSHogSFBFVArvv70oWEVOKSBBbGxvY2F0ZWQgY29uc29sZSByaW5nIG9mIDE2IEtpQi4KKFhF TikgVk1YOiBTdXBwb3J0ZWQgYWR2YW5jZWQgZmVhdHVyZXM6CihYRU4pICAtIE1TUiBkaXJlY3Qt YWNjZXNzIGJpdG1hcAooWEVOKSBIVk06IEFTSURzIGRpc2FibGVkLgooWEVOKSBIVk06IFZNWCBl bmFibGVkCihYRU4pIEJyb3VnaHQgdXAgMiBDUFVzCihYRU4pIEhQRVQ6IDMgdGltZXJzIGluIHRv dGFsLCAwIHRpbWVycyB3aWxsIGJlIHVzZWQgZm9yIGJyb2FkY2FzdAooWEVOKSBBQ1BJIHNsZWVw IG1vZGVzOiBTMwooWEVOKSBtY2hlY2tfcG9sbDogTWFjaGluZSBjaGVjayBwb2xsaW5nIHRpbWVy IHN0YXJ0ZWQuCihYRU4pICoqKiBMT0FESU5HIERPTUFJTiAwICoqKgooWEVOKSAgWGVuICBrZXJu ZWw6IDY0LWJpdCwgbHNiLCBjb21wYXQzMgooWEVOKSAgRG9tMCBrZXJuZWw6IDY0LWJpdCwgUEFF LCBsc2IsIHBhZGRyIDB4MTAwMDAwMCAtPiAweDJhZTYwMDAKKFhFTikgUEhZU0lDQUwgTUVNT1JZ IEFSUkFOR0VNRU5UOgooWEVOKSAgRG9tMCBhbGxvYy46ICAgMDAwMDAwMDA3NDAwMDAwMC0+MDAw MDAwMDA3ODAwMDAwMCAoNDU2NTI5IHBhZ2VzIHRvIGJlIGFsbG9jYXRlZCkKKFhFTikgIEluaXQu IHJhbWRpc2s6IDAwMDAwMDAwN2M5YmYwMDAtPjAwMDAwMDAwN2YxZmYyMDAKKFhFTikgVklSVFVB TCBNRU1PUlkgQVJSQU5HRU1FTlQ6CihYRU4pICBMb2FkZWQga2VybmVsOiBmZmZmZmZmZjgxMDAw MDAwLT5mZmZmZmZmZjgyYWU2MDAwCihYRU4pICBJbml0LiByYW1kaXNrOiBmZmZmZmZmZjgyYWU2 MDAwLT5mZmZmZmZmZjg1MzI2MjAwCihYRU4pICBQaHlzLU1hY2ggbWFwOiBmZmZmZmZmZjg1MzI3 MDAwLT5mZmZmZmZmZjg1NmQ2YzkwCihYRU4pICBTdGFydCBpbmZvOiAgICBmZmZmZmZmZjg1NmQ3 MDAwLT5mZmZmZmZmZjg1NmQ3NGI0CihYRU4pICBQYWdlIHRhYmxlczogICBmZmZmZmZmZjg1NmQ4 MDAwLT5mZmZmZmZmZjg1NzA3MDAwCihYRU4pICBCb290IHN0YWNrOiAgICBmZmZmZmZmZjg1NzA3 MDAwLT5mZmZmZmZmZjg1NzA4MDAwCihYRU4pICBUT1RBTDogICAgICAgICBmZmZmZmZmZjgwMDAw MDAwLT5mZmZmZmZmZjg1ODAwMDAwCihYRU4pICBFTlRSWSBBRERSRVNTOiBmZmZmZmZmZjgxZDUz MjAwCihYRU4pIERvbTAgaGFzIG1heGltdW0gMiBWQ1BVcwooWEVOKSBTY3J1YmJpbmcgRnJlZSBS QU06IC5kb25lLgooWEVOKSBYZW4gdHJhY2UgYnVmZmVyczogZGlzYWJsZWQKKFhFTikgU3RkLiBM b2dsZXZlbDogQWxsCihYRU4pIEd1ZXN0IExvZ2xldmVsOiBBbGwKKFhFTikgKioqIFNlcmlhbCBp bnB1dCAtPiBET00wICh0eXBlICdDVFJMLWEnIHRocmVlIHRpbWVzIHRvIHN3aXRjaCBpbnB1dCB0 byBYZW4pCihYRU4pIEZyZWVkIDIyNGtCIGluaXQgbWVtb3J5LgptYXBwaW5nIGtlcm5lbCBpbnRv IHBoeXNpY2FsIG1lbW9yeQpYZW46IHNldHVwIElTQSBpZGVudGl0eSBtYXBzCmFib3V0IHRvIGdl dCBzdGFydGVkLi4uClsgICAgMC4wMDAwMDBdIEluaXRpYWxpemluZyBjZ3JvdXAgc3Vic3lzIGNw dXNldApbICAgIDAuMDAwMDAwXSBJbml0aWFsaXppbmcgY2dyb3VwIHN1YnN5cyBjcHUKWyAgICAw LjAwMDAwMF0gTGludXggdmVyc2lvbiAzLjEuMC0wLnJjNi5naXQwLjAuZmMxNy54ODZfNjQgKG1v Y2tidWlsZEB4ODYtMDIucGh4Mi5mZWRvcmFwcm9qZWN0Lm9yZykgKGdjYyB2ZXJzaW9uIDQuNi4x IDIwMTEwODI0IChSZWQgSGF0IDQuNi4xLTgpIChHQ0MpICkgIzEgU01QIE1vbiBTZXAgMTIgMjI6 NTY6MzggVVRDIDIwMTEKWyAgICAwLjAwMDAwMF0gQ29tbWFuZCBsaW5lOiBybyByb290PS9kZXYv bWFwcGVyL3ZnX2luc3A2NDAwLWx2X3Jvb3QgU1lTRk9OVD1sYXRhcmN5cmhlYi1zdW4xNiBMQU5H PWVuX1VTLlVURi04IEtFWVRBQkxFPXVzIGNvbnNvbGU9aHZjMCBlYXJseXByaW50az14ZW4gbm9t b2Rlc2V0IGluaXRjYWxsX2RlYnVnIGRlYnVnIGxvZ2xldmVsPTEwClsgICAgMC4wMDAwMDBdIHJl bGVhc2VkIDAgcGFnZXMgb2YgdW51c2VkIG1lbW9yeQpbICAgIDAuMDAwMDAwXSBTZXQgNTI2NzMz IHBhZ2UocykgdG8gMS0xIG1hcHBpbmcuClsgICAgMC4wMDAwMDBdIEJJT1MtcHJvdmlkZWQgcGh5 c2ljYWwgUkFNIG1hcDoKWyAgICAwLjAwMDAwMF0gIFhlbjogMDAwMDAwMDAwMDAwMDAwMCAtIDAw MDAwMDAwMDAwOWYwMDAgKHVzYWJsZSkKWyAgICAwLjAwMDAwMF0gIFhlbjogMDAwMDAwMDAwMDA5 ZjAwMCAtIDAwMDAwMDAwMDAxMDAwMDAgKHJlc2VydmVkKQpbICAgIDAuMDAwMDAwXSAgWGVuOiAw MDAwMDAwMDAwMTAwMDAwIC0gMDAwMDAwMDA3NWY5MjAwMCAodXNhYmxlKQpbICAgIDAuMDAwMDAw XSAgWGVuOiAwMDAwMDAwMDc1ZjkyMDAwIC0gMDAwMDAwMDA3ZjZkMzAwMCAodW51c2FibGUpClsg ICAgMC4wMDAwMDBdICBYZW46IDAwMDAwMDAwN2Y2ZDM0MDAgLSAwMDAwMDAwMDgwMDAwMDAwIChy ZXNlcnZlZCkKWyAgICAwLjAwMDAwMF0gIFhlbjogMDAwMDAwMDBmMDAwMDAwMCAtIDAwMDAwMDAw ZjQwMDcwMDAgKHJlc2VydmVkKQpbICAgIDAuMDAwMDAwXSAgWGVuOiAwMDAwMDAwMGY0MDA4MDAw IC0gMDAwMDAwMDBmNDAwYzAwMCAocmVzZXJ2ZWQpClsgICAgMC4wMDAwMDBdICBYZW46IDAwMDAw MDAwZmVjMDAwMDAgLSAwMDAwMDAwMGZlYzEwMDAwIChyZXNlcnZlZCkKWyAgICAwLjAwMDAwMF0g IFhlbjogMDAwMDAwMDBmZWQyMDAwMCAtIDAwMDAwMDAwZmVkYTAwMDAgKHJlc2VydmVkKQpbICAg IDAuMDAwMDAwXSAgWGVuOiAwMDAwMDAwMGZlZTAwMDAwIC0gMDAwMDAwMDBmZWUxMDAwMCAocmVz ZXJ2ZWQpClsgICAgMC4wMDAwMDBdICBYZW46IDAwMDAwMDAwZmZiMDAwMDAgLSAwMDAwMDAwMTAw MDAwMDAwIChyZXNlcnZlZCkKWyAgICAwLjAwMDAwMF0gIFhlbjogMDAwMDAwMDEwMDAwMDAwMCAt IDAwMDAwMDA1MjVjMjIwMDAgKHVzYWJsZSkKWyAgICAwLjAwMDAwMF0gYm9vdGNvbnNvbGUgW3hl bmJvb3QwXSBlbmFibGVkClsgICAgMC4wMDAwMDBdIE5YIChFeGVjdXRlIERpc2FibGUpIHByb3Rl Y3Rpb246IGFjdGl2ZQpbICAgIDAuMDAwMDAwXSBETUk6IERlbGwgSW5jLiBNTTA2MSAgICAgICAg ICAgICAgICAgICAgICAgICAgIC8wS0Q4ODIsIEJJT1MgQTE3IDA2LzEzLzIwMDcKWyAgICAwLjAw MDAwMF0gZTgyMCB1cGRhdGUgcmFuZ2U6IDAwMDAwMDAwMDAwMDAwMDAgLSAwMDAwMDAwMDAwMDEw MDAwICh1c2FibGUpID09PiAocmVzZXJ2ZWQpClsgICAgMC4wMDAwMDBdIGU4MjAgcmVtb3ZlIHJh bmdlOiAwMDAwMDAwMDAwMGEwMDAwIC0gMDAwMDAwMDAwMDEwMDAwMCAodXNhYmxlKQpbICAgIDAu MDAwMDAwXSBObyBBR1AgYnJpZGdlIGZvdW5kClsgICAgMC4wMDAwMDBdIGxhc3RfcGZuID0gMHg1 MjVjMjIgbWF4X2FyY2hfcGZuID0gMHg0MDAwMDAwMDAKWyAgICAwLjAwMDAwMF0gbGFzdF9wZm4g PSAweDc1ZjkyIG1heF9hcmNoX3BmbiA9IDB4NDAwMDAwMDAwClsgICAgMC4wMDAwMDBdIGluaXRp YWwgbWVtb3J5IG1hcHBlZCA6IDAgLSAwNTMyNzAwMApbICAgIDAuMDAwMDAwXSBCYXNlIG1lbW9y eSB0cmFtcG9saW5lIGF0IFtmZmZmODgwMDAwMDlhMDAwXSA5YTAwMCBzaXplIDIwNDgwClsgICAg MC4wMDAwMDBdIGluaXRfbWVtb3J5X21hcHBpbmc6IDAwMDAwMDAwMDAwMDAwMDAtMDAwMDAwMDA3 NWY5MjAwMApbICAgIDAuMDAwMDAwXSAgMDAwMDAwMDAwMCAtIDAwNzVmOTIwMDAgcGFnZSA0awpb ICAgIDAuMDAwMDAwXSBrZXJuZWwgZGlyZWN0IG1hcHBpbmcgdGFibGVzIHVwIHRvIDc1ZjkyMDAw IEAgNzViZGYwMDAtNzVmOTIwMDAKWyAgICAwLjAwMDAwMF0geGVuOiBzZXR0aW5nIFJXIHRoZSBy YW5nZSA3NWY2MDAwMCAtIDc1ZjkyMDAwClsgICAgMC4wMDAwMDBdIGluaXRfbWVtb3J5X21hcHBp bmc6IDAwMDAwMDAxMDAwMDAwMDAtMDAwMDAwMDUyNWMyMjAwMApbICAgIDAuMDAwMDAwXSAgMDEw MDAwMDAwMCAtIDA1MjVjMjIwMDAgcGFnZSA0awpbICAgIDAuMDAwMDAwXSBrZXJuZWwgZGlyZWN0 IG1hcHBpbmcgdGFibGVzIHVwIHRvIDUyNWMyMjAwMCBAIDczMjlhMDAwLTc1YmRmMDAwClsgICAg MC4wMDAwMDBdIHhlbjogc2V0dGluZyBSVyB0aGUgcmFuZ2UgNzUzZGEwMDAgLSA3NWJkZjAwMApb ICAgIDAuMDAwMDAwXSBSQU1ESVNLOiAwMmFlNjAwMCAtIDA1MzI3MDAwClsgICAgMC4wMDAwMDBd IEFDUEk6IFJTRFAgMDAwMDAwMDAwMDBmYzFkMCAwMDAxNCAodjAwIERFTEwgICkKWyAgICAwLjAw MDAwMF0gQUNQSTogUlNEVCAwMDAwMDAwMDdmNmQzYTBmIDAwMDQwICh2MDEgREVMTCAgICBNMDcg ICAgIDI3RDcwNjBEIEFTTCAgMDAwMDAwNjEpClsgICAgMC4wMDAwMDBdIEFDUEk6IEZBQ1AgMDAw MDAwMDA3ZjZkNDgwMCAwMDA3NCAodjAxIERFTEwgICAgTTA3ICAgICAyN0Q3MDYwRCBBU0wgIDAw MDAwMDYxKQpbICAgIDAuMDAwMDAwXSBBQ1BJOiBEU0RUIDAwMDAwMDAwN2Y2ZDU0MDAgMDQ3NjYg KHYwMSBJTlQ0MzAgU1lTRmV4eHggMDAwMDEwMDEgSU5UTCAyMDA1MDYyNCkKWyAgICAwLjAwMDAw MF0gQUNQSTogRkFDUyAwMDAwMDAwMDdmNmUzYzAwIDAwMDQwClsgICAgMC4wMDAwMDBdIEFDUEk6 IEhQRVQgMDAwMDAwMDA3ZjZkNGYwMCAwMDAzOCAodjAxIERFTEwgICAgTTA3ICAgICAwMDAwMDAw MSBBU0wgIDAwMDAwMDYxKQpbICAgIDAuMDAwMDAwXSBBQ1BJOiBBUElDIDAwMDAwMDAwN2Y2ZDUw MDAgMDAwNjggKHYwMSBERUxMICAgIE0wNyAgICAgMjdENzA2MEQgQVNMICAwMDAwMDA0NykKWyAg ICAwLjAwMDAwMF0gQUNQSTogTUNGRyAwMDAwMDAwMDdmNmQ0ZmMwIDAwMDNFICh2MTYgREVMTCAg ICBNMDcgICAgIDI3RDcwNjBEIEFTTCAgMDAwMDAwNjEpClsgICAgMC4wMDAwMDBdIEFDUEk6IFNM SUMgMDAwMDAwMDA3ZjZkNTA5YyAwMDE3NiAodjAxIERFTEwgICAgTTA3ICAgICAyN0Q3MDYwRCBB U0wgIDAwMDAwMDYxKQpbICAgIDAuMDAwMDAwXSBBQ1BJOiBCT09UIDAwMDAwMDAwN2Y2ZDRiYzAg MDAwMjggKHYwMSBERUxMICAgIE0wNyAgICAgMjdENzA2MEQgQVNMICAwMDAwMDA2MSkKWyAgICAw LjAwMDAwMF0gQUNQSTogU1NEVCAwMDAwMDAwMDdmNmQzYTRmIDAwNERDICh2MDEgIFBtUmVmICAg IENwdVBtIDAwMDAzMDAwIElOVEwgMjAwNTA2MjQpClsgICAgMC4wMDAwMDBdIEFDUEk6IExvY2Fs IEFQSUMgYWRkcmVzcyAweGZlZTAwMDAwClsgICAgMC4wMDAwMDBdIE5vIE5VTUEgY29uZmlndXJh dGlvbiBmb3VuZApbICAgIDAuMDAwMDAwXSBGYWtpbmcgYSBub2RlIGF0IDAwMDAwMDAwMDAwMDAw MDAtMDAwMDAwMDUyNWMyMjAwMApbICAgIDAuMDAwMDAwXSBJbml0bWVtIHNldHVwIG5vZGUgMCAw MDAwMDAwMDAwMDAwMDAwLTAwMDAwMDA1MjVjMjIwMDAKWyAgICAwLjAwMDAwMF0gICBOT0RFX0RB VEEgWzAwMDAwMDAwNzVmN2QwMDAgLSAwMDAwMDAwMDc1ZjkxZmZmXQpbICAgIDAuMDAwMDAwXSBa b25lIFBGTiByYW5nZXM6ClsgICAgMC4wMDAwMDBdICAgRE1BICAgICAgMHgwMDAwMDAxMCAtPiAw eDAwMDAxMDAwClsgICAgMC4wMDAwMDBdICAgRE1BMzIgICAgMHgwMDAwMTAwMCAtPiAweDAwMTAw MDAwClsgICAgMC4wMDAwMDBdICAgTm9ybWFsICAgMHgwMDEwMDAwMCAtPiAweDAwNTI1YzIyClsg ICAgMC4wMDAwMDBdIE1vdmFibGUgem9uZSBzdGFydCBQRk4gZm9yIGVhY2ggbm9kZQpbICAgIDAu MDAwMDAwXSBlYXJseV9ub2RlX21hcFszXSBhY3RpdmUgUEZOIHJhbmdlcwpbICAgIDAuMDAwMDAw XSAgICAgMDogMHgwMDAwMDAxMCAtPiAweDAwMDAwMDlmClsgICAgMC4wMDAwMDBdICAgICAwOiAw eDAwMDAwMTAwIC0+IDB4MDAwNzVmOTIKWyAgICAwLjAwMDAwMF0gICAgIDA6IDB4MDAxMDAwMDAg LT4gMHgwMDUyNWMyMgpbICAgIDAuMDAwMDAwXSBPbiBub2RlIDAgdG90YWxwYWdlczogNDgzMjA2 NwpbICAgIDAuMDAwMDAwXSAgIERNQSB6b25lOiA2NCBwYWdlcyB1c2VkIGZvciBtZW1tYXAKWyAg ICAwLjAwMDAwMF0gICBETUEgem9uZTogNSBwYWdlcyByZXNlcnZlZApbICAgIDAuMDAwMDAwXSAg IERNQSB6b25lOiAzOTE0IHBhZ2VzLCBMSUZPIGJhdGNoOjAKWyAgICAwLjAwMDAwMF0gICBETUEz MiB6b25lOiAxNjMyMCBwYWdlcyB1c2VkIGZvciBtZW1tYXAKWyAgICAwLjAwMDAwMF0gICBETUEz MiB6b25lOiA0NjI4MDIgcGFnZXMsIExJRk8gYmF0Y2g6MzEKWyAgICAwLjAwMDAwMF0gICBOb3Jt YWwgem9uZTogNDI4MTAwOSBwYWdlcywgTElGTyBiYXRjaDozMQpbICAgIDAuMDAwMDAwXSBBQ1BJ OiBQTS1UaW1lciBJTyBQb3J0OiAweDEwMDgKWyAgICAwLjAwMDAwMF0gQUNQSTogTG9jYWwgQVBJ QyBhZGRyZXNzIDB4ZmVlMDAwMDAKWyAgICAwLjAwMDAwMF0gQUNQSTogTEFQSUMgKGFjcGlfaWRb MHgwMF0gbGFwaWNfaWRbMHgwMF0gZW5hYmxlZCkKWyAgICAwLjAwMDAwMF0gQklPUyBidWc6IEFQ SUMgdmVyc2lvbiBpcyAwIGZvciBDUFUgMC8weDAsIGZpeGluZyB1cCB0byAweDEwClsgICAgMC4w MDAwMDBdIEFDUEk6IExBUElDIChhY3BpX2lkWzB4MDFdIGxhcGljX2lkWzB4MDFdIGVuYWJsZWQp ClsgICAgMC4wMDAwMDBdIEFDUEk6IExBUElDX05NSSAoYWNwaV9pZFsweDAwXSBoaWdoIGVkZ2Ug bGludFsweDFdKQpbICAgIDAuMDAwMDAwXSBBQ1BJOiBMQVBJQ19OTUkgKGFjcGlfaWRbMHgwMV0g aGlnaCBlZGdlIGxpbnRbMHgxXSkKWyAgICAwLjAwMDAwMF0gQUNQSTogSU9BUElDIChpZFsweDAy XSBhZGRyZXNzWzB4ZmVjMDAwMDBdIGdzaV9iYXNlWzBdKQpbICAgIDAuMDAwMDAwXSBJT0FQSUNb MF06IGFwaWNfaWQgMiwgdmVyc2lvbiAyNTUsIGFkZHJlc3MgMHhmZWMwMDAwMCwgR1NJIDAtMjU1 ClsgICAgMC4wMDAwMDBdIEFDUEk6IElOVF9TUkNfT1ZSIChidXMgMCBidXNfaXJxIDAgZ2xvYmFs X2lycSAyIGRmbCBkZmwpClsgICAgMC4wMDAwMDBdIEFDUEk6IElOVF9TUkNfT1ZSIChidXMgMCBi dXNfaXJxIDkgZ2xvYmFsX2lycSA5IGhpZ2ggbGV2ZWwpClsgICAgMC4wMDAwMDBdIEFDUEk6IElS UTAgdXNlZCBieSBvdmVycmlkZS4KWyAgICAwLjAwMDAwMF0gQUNQSTogSVJRMiB1c2VkIGJ5IG92 ZXJyaWRlLgpbICAgIDAuMDAwMDAwXSBBQ1BJOiBJUlE5IHVzZWQgYnkgb3ZlcnJpZGUuClsgICAg MC4wMDAwMDBdIFVzaW5nIEFDUEkgKE1BRFQpIGZvciBTTVAgY29uZmlndXJhdGlvbiBpbmZvcm1h dGlvbgpbICAgIDAuMDAwMDAwXSBBQ1BJOiBIUEVUIGlkOiAweDgwODZhMjAxIGJhc2U6IDB4ZmVk MDAwMDAKWyAgICAwLjAwMDAwMF0gU01QOiBBbGxvd2luZyAyIENQVXMsIDAgaG90cGx1ZyBDUFVz ClsgICAgMC4wMDAwMDBdIG5yX2lycXNfZ3NpOiAyNzIKWyAgICAwLjAwMDAwMF0gUE06IFJlZ2lz dGVyZWQgbm9zYXZlIG1lbW9yeTogMDAwMDAwMDAwMDA5ZjAwMCAtIDAwMDAwMDAwMDAxMDAwMDAK WyAgICAwLjAwMDAwMF0gUE06IFJlZ2lzdGVyZWQgbm9zYXZlIG1lbW9yeTogMDAwMDAwMDA3NWY5 MjAwMCAtIDAwMDAwMDAwN2Y2ZDMwMDAKWyAgICAwLjAwMDAwMF0gUE06IFJlZ2lzdGVyZWQgbm9z YXZlIG1lbW9yeTogMDAwMDAwMDA3ZjZkMzAwMCAtIDAwMDAwMDAwN2Y2ZDQwMDAKWyAgICAwLjAw MDAwMF0gUE06IFJlZ2lzdGVyZWQgbm9zYXZlIG1lbW9yeTogMDAwMDAwMDA3ZjZkNDAwMCAtIDAw MDAwMDAwODAwMDAwMDAKWyAgICAwLjAwMDAwMF0gUE06IFJlZ2lzdGVyZWQgbm9zYXZlIG1lbW9y eTogMDAwMDAwMDA4MDAwMDAwMCAtIDAwMDAwMDAwZjAwMDAwMDAKWyAgICAwLjAwMDAwMF0gUE06 IFJlZ2lzdGVyZWQgbm9zYXZlIG1lbW9yeTogMDAwMDAwMDBmMDAwMDAwMCAtIDAwMDAwMDAwZjQw MDcwMDAKWyAgICAwLjAwMDAwMF0gUE06IFJlZ2lzdGVyZWQgbm9zYXZlIG1lbW9yeTogMDAwMDAw MDBmNDAwNzAwMCAtIDAwMDAwMDAwZjQwMDgwMDAKWyAgICAwLjAwMDAwMF0gUE06IFJlZ2lzdGVy ZWQgbm9zYXZlIG1lbW9yeTogMDAwMDAwMDBmNDAwODAwMCAtIDAwMDAwMDAwZjQwMGMwMDAKWyAg ICAwLjAwMDAwMF0gUE06IFJlZ2lzdGVyZWQgbm9zYXZlIG1lbW9yeTogMDAwMDAwMDBmNDAwYzAw MCAtIDAwMDAwMDAwZmVjMDAwMDAKWyAgICAwLjAwMDAwMF0gUE06IFJlZ2lzdGVyZWQgbm9zYXZl IG1lbW9yeTogMDAwMDAwMDBmZWMwMDAwMCAtIDAwMDAwMDAwZmVjMTAwMDAKWyAgICAwLjAwMDAw MF0gUE06IFJlZ2lzdGVyZWQgbm9zYXZlIG1lbW9yeTogMDAwMDAwMDBmZWMxMDAwMCAtIDAwMDAw MDAwZmVkMjAwMDAKWyAgICAwLjAwMDAwMF0gUE06IFJlZ2lzdGVyZWQgbm9zYXZlIG1lbW9yeTog MDAwMDAwMDBmZWQyMDAwMCAtIDAwMDAwMDAwZmVkYTAwMDAKWyAgICAwLjAwMDAwMF0gUE06IFJl Z2lzdGVyZWQgbm9zYXZlIG1lbW9yeTogMDAwMDAwMDBmZWRhMDAwMCAtIDAwMDAwMDAwZmVlMDAw MDAKWyAgICAwLjAwMDAwMF0gUE06IFJlZ2lzdGVyZWQgbm9zYXZlIG1lbW9yeTogMDAwMDAwMDBm ZWUwMDAwMCAtIDAwMDAwMDAwZmVlMTAwMDAKWyAgICAwLjAwMDAwMF0gUE06IFJlZ2lzdGVyZWQg bm9zYXZlIG1lbW9yeTogMDAwMDAwMDBmZWUxMDAwMCAtIDAwMDAwMDAwZmZiMDAwMDAKWyAgICAw LjAwMDAwMF0gUE06IFJlZ2lzdGVyZWQgbm9zYXZlIG1lbW9yeTogMDAwMDAwMDBmZmIwMDAwMCAt IDAwMDAwMDAxMDAwMDAwMDAKWyAgICAwLjAwMDAwMF0gQWxsb2NhdGluZyBQQ0kgcmVzb3VyY2Vz IHN0YXJ0aW5nIGF0IDgwMDAwMDAwIChnYXA6IDgwMDAwMDAwOjcwMDAwMDAwKQpbICAgIDAuMDAw MDAwXSBCb290aW5nIHBhcmF2aXJ0dWFsaXplZCBrZXJuZWwgb24gWGVuClsgICAgMC4wMDAwMDBd IFhlbiB2ZXJzaW9uOiA0LjEuMSAocHJlc2VydmUtQUQpClsgICAgMC4wMDAwMDBdIHNldHVwX3Bl cmNwdTogTlJfQ1BVUzo1MTIgbnJfY3B1bWFza19iaXRzOjUxMiBucl9jcHVfaWRzOjIgbnJfbm9k ZV9pZHM6MQpbICAgIDAuMDAwMDAwXSBQRVJDUFU6IEVtYmVkZGVkIDQ3NiBwYWdlcy9jcHUgQGZm ZmY4ODAwNzU3MTgwMDAgczE5MTg0NjQgcjgxOTIgZDIzMDQwIHUxOTQ5Njk2ClsgICAgMC4wMDAw MDBdIHBjcHUtYWxsb2M6IHMxOTE4NDY0IHI4MTkyIGQyMzA0MCB1MTk0OTY5NiBhbGxvYz00NzYq NDA5NgpbICAgIDAuMDAwMDAwXSBwY3B1LWFsbG9jOiBbMF0gMCBbMF0gMQpbICAgIDAuMDAwMDAw XSBCdWlsdCAxIHpvbmVsaXN0cyBpbiBab25lIG9yZGVyLCBtb2JpbGl0eSBncm91cGluZyBvbi4g IFRvdGFsIHBhZ2VzOiA0NzQ3NzI1ClsgICAgMC4wMDAwMDBdIFBvbGljeSB6b25lOiBOb3JtYWwK WyAgICAwLjAwMDAwMF0gS2VybmVsIGNvbW1hbmQgbGluZTogcm8gcm9vdD0vZGV2L21hcHBlci92 Z19pbnNwNjQwMC1sdl9yb290IFNZU0ZPTlQ9bGF0YXJjeXJoZWItc3VuMTYgTEFORz1lbl9VUy5V VEYtOCBLRVlUQUJMRT11cyBjb25zb2xlPWh2YzAgZWFybHlwcmludGs9eGVuIG5vbW9kZXNldCBp bml0Y2FsbF9kZWJ1ZyBkZWJ1ZyBsb2dsZXZlbD0xMApbICAgIDAuMDAwMDAwXSBQSUQgaGFzaCB0 YWJsZSBlbnRyaWVzOiA0MDk2IChvcmRlcjogMywgMzI3NjggYnl0ZXMpClsgICAgMC4wMDAwMDBd IFBsYWNpbmcgNjRNQiBzb2Z0d2FyZSBJTyBUTEIgYmV0d2VlbiBmZmZmODgwMDVjYTAwMDAwIC0g ZmZmZjg4MDA2MGEwMDAwMApbICAgIDAuMDAwMDAwXSBzb2Z0d2FyZSBJTyBUTEIgYXQgcGh5cyAw eDVjYTAwMDAwIC0gMHg2MGEwMDAwMApbICAgIDAuMDAwMDAwXSBNZW1vcnk6IDE0NDg1MDBrLzIx NTkwMTUyayBhdmFpbGFibGUgKDUxODZrIGtlcm5lbCBjb2RlLCAyMjYxODg0ayBhYnNlbnQsIDE3 ODc5NzY4ayByZXNlcnZlZCwgNjU3N2sgZGF0YSwgMjc4NGsgaW5pdCkKWyAgICAwLjAwMDAwMF0g U0xVQjogR2Vuc2xhYnM9MTUsIEhXYWxpZ249NjQsIE9yZGVyPTAtMywgTWluT2JqZWN0cz0wLCBD UFVzPTIsIE5vZGVzPTEKWyAgICAwLjAwMDAwMF0gIFJDVSBkeW50aWNrLWlkbGUgZ3JhY2UtcGVy aW9kIGFjY2VsZXJhdGlvbiBpcyBlbmFibGVkLgpbICAgIDAuMDAwMDAwXSAgUkNVIGxvY2tkZXAg Y2hlY2tpbmcgaXMgZW5hYmxlZC4KWyAgICAwLjAwMDAwMF0gTlJfSVJRUzozMzAyNCBucl9pcnFz OjUxMiAxNgpbICAgIDAuMDAwMDAwXSB4ZW46IHNjaSBvdmVycmlkZTogZ2xvYmFsX2lycT05IHRy aWdnZXI9MCBwb2xhcml0eT0wClsgICAgMC4wMDAwMDBdIHhlbjogcmVnaXN0ZXJpbmcgZ3NpIDkg dHJpZ2dlcmluZyAwIHBvbGFyaXR5IDAKWyAgICAwLjAwMDAwMF0geGVuOiAtLT4gcGlycT05IC0+ IGlycT05IChnc2k9OSkKWyAgICAwLjAwMDAwMF0geGVuOiBhY3BpIHNjaSA5ClsgICAgMC4wMDAw MDBdIHhlbjogLS0+IHBpcnE9MSAtPiBpcnE9MSAoZ3NpPTEpClsgICAgMC4wMDAwMDBdIHhlbjog LS0+IHBpcnE9MiAtPiBpcnE9MiAoZ3NpPTIpClsgICAgMC4wMDAwMDBdIHhlbjogLS0+IHBpcnE9 MyAtPiBpcnE9MyAoZ3NpPTMpClsgICAgMC4wMDAwMDBdIHhlbjogLS0+IHBpcnE9NCAtPiBpcnE9 NCAoZ3NpPTQpClsgICAgMC4wMDAwMDBdIHhlbjogLS0+IHBpcnE9NSAtPiBpcnE9NSAoZ3NpPTUp ClsgICAgMC4wMDAwMDBdIHhlbjogLS0+IHBpcnE9NiAtPiBpcnE9NiAoZ3NpPTYpClsgICAgMC4w MDAwMDBdIHhlbjogLS0+IHBpcnE9NyAtPiBpcnE9NyAoZ3NpPTcpClsgICAgMC4wMDAwMDBdIHhl bjogLS0+IHBpcnE9OCAtPiBpcnE9OCAoZ3NpPTgpClsgICAgMC4wMDAwMDBdIHhlbl9tYXBfcGly cV9nc2k6IHJldHVybmluZyBpcnEgOSBmb3IgZ3NpIDkKWyAgICAwLjAwMDAwMF0geGVuOiAtLT4g cGlycT05IC0+IGlycT05IChnc2k9OSkKWyAgICAwLjAwMDAwMF0geGVuOiAtLT4gcGlycT0xMCAt PiBpcnE9MTAgKGdzaT0xMCkKWyAgICAwLjAwMDAwMF0geGVuOiAtLT4gcGlycT0xMSAtPiBpcnE9 MTEgKGdzaT0xMSkKWyAgICAwLjAwMDAwMF0geGVuOiAtLT4gcGlycT0xMiAtPiBpcnE9MTIgKGdz aT0xMikKWyAgICAwLjAwMDAwMF0geGVuOiAtLT4gcGlycT0xMyAtPiBpcnE9MTMgKGdzaT0xMykK WyAgICAwLjAwMDAwMF0geGVuOiAtLT4gcGlycT0xNCAtPiBpcnE9MTQgKGdzaT0xNCkKWyAgICAw LjAwMDAwMF0geGVuOiAtLT4gcGlycT0xNSAtPiBpcnE9MTUgKGdzaT0xNSkKWyAgICAwLjAwMDAw MF0gQ29uc29sZTogY29sb3VyIFZHQSsgODB4MjUKWyAgICAwLjAwMDAwMF0gY29uc29sZSBbaHZj MF0gZW5hYmxlZCwgYm9vdGNvbnNvbGUgZGlzYWJsZWQKWyAgICAwLjAwMDAwMF0gY29uc29sZSBb aHZjMF0gZW5hYmxlZCwgYm9vdGNvbnNvbGUgZGlzYWJsZWQKWyAgICAwLjAwMDAwMF0gTG9jayBk ZXBlbmRlbmN5IHZhbGlkYXRvcjogQ29weXJpZ2h0IChjKSAyMDA2IFJlZCBIYXQsIEluYy4sIElu Z28gTW9sbmFyClsgICAgMC4wMDAwMDBdIC4uLiBNQVhfTE9DS0RFUF9TVUJDTEFTU0VTOiAgOApb ICAgIDAuMDAwMDAwXSAuLi4gTUFYX0xPQ0tfREVQVEg6ICAgICAgICAgIDQ4ClsgICAgMC4wMDAw MDBdIC4uLiBNQVhfTE9DS0RFUF9LRVlTOiAgICAgICAgODE5MQpbICAgIDAuMDAwMDAwXSAuLi4g Q0xBU1NIQVNIX1NJWkU6ICAgICAgICAgIDQwOTYKWyAgICAwLjAwMDAwMF0gLi4uIE1BWF9MT0NL REVQX0VOVFJJRVM6ICAgICAxNjM4NApbICAgIDAuMDAwMDAwXSAuLi4gTUFYX0xPQ0tERVBfQ0hB SU5TOiAgICAgIDMyNzY4ClsgICAgMC4wMDAwMDBdIC4uLiBDSEFJTkhBU0hfU0laRTogICAgICAg ICAgMTYzODQKWyAgICAwLjAwMDAwMF0gIG1lbW9yeSB1c2VkIGJ5IGxvY2sgZGVwZW5kZW5jeSBp bmZvOiA2MzY3IGtCClsgICAgMC4wMDAwMDBdICBwZXIgdGFzay1zdHJ1Y3QgbWVtb3J5IGZvb3Rw cmludDogMjY4OCBieXRlcwpbICAgIDAuMDAwMDAwXSBhbGxvY2F0ZWQgMTU1MTg5MjQ4IGJ5dGVz IG9mIHBhZ2VfY2dyb3VwClsgICAgMC4wMDAwMDBdIHBsZWFzZSB0cnkgJ2Nncm91cF9kaXNhYmxl PW1lbW9yeScgb3B0aW9uIGlmIHlvdSBkb24ndCB3YW50IG1lbW9yeSBjZ3JvdXBzClsgICAgMC4w MDAwMDBdIE9ERUJVRzogMTEgb2YgMTEgYWN0aXZlIG9iamVjdHMgcmVwbGFjZWQKWyAgICAwLjAw MDAwMF0gWGVuOiB1c2luZyB2Y3B1b3AgdGltZXIgaW50ZXJmYWNlClsgICAgMC4wMDAwMDBdIGlu c3RhbGxpbmcgWGVuIHRpbWVyIGZvciBDUFUgMApbICAgIDAuMDAwMDAwXSBEZXRlY3RlZCAxODI4 LjgzMSBNSHogcHJvY2Vzc29yLgpbICAgIDAuMDAwOTk5XSBDYWxpYnJhdGluZyBkZWxheSBsb29w IChza2lwcGVkKSwgdmFsdWUgY2FsY3VsYXRlZCB1c2luZyB0aW1lciBmcmVxdWVuY3kuLiAzNjU3 LjY2IEJvZ29NSVBTIChscGo9MTgyODgzMSkKWyAgICAwLjAwMDk5OV0gcGlkX21heDogZGVmYXVs dDogMzI3NjggbWluaW11bTogMzAxClsgICAgMC4wMDA5OTldIFNlY3VyaXR5IEZyYW1ld29yayBp bml0aWFsaXplZApbICAgIDAuMDAwOTk5XSBTRUxpbnV4OiAgSW5pdGlhbGl6aW5nLgpbICAgIDAu MDAwOTk5XSBTRUxpbnV4OiAgU3RhcnRpbmcgaW4gcGVybWlzc2l2ZSBtb2RlClsgICAgMC4wMjAy NjVdIERlbnRyeSBjYWNoZSBoYXNoIHRhYmxlIGVudHJpZXM6IDQxOTQzMDQgKG9yZGVyOiAxMywg MzM1NTQ0MzIgYnl0ZXMpClsgICAgMC4wNTUxMDldIElub2RlLWNhY2hlIGhhc2ggdGFibGUgZW50 cmllczogMjA5NzE1MiAob3JkZXI6IDEyLCAxNjc3NzIxNiBieXRlcykKWyAgICAwLjA2ODgzM10g TW91bnQtY2FjaGUgaGFzaCB0YWJsZSBlbnRyaWVzOiAyNTYKWyAgICAwLjA3MjgzOV0gSW5pdGlh bGl6aW5nIGNncm91cCBzdWJzeXMgY3B1YWNjdApbICAgIDAuMDcyOTUxXSBJbml0aWFsaXppbmcg Y2dyb3VwIHN1YnN5cyBtZW1vcnkKWyAgICAwLjA3MzI3MV0gSW5pdGlhbGl6aW5nIGNncm91cCBz dWJzeXMgZGV2aWNlcwpbICAgIDAuMDczMzE3XSBJbml0aWFsaXppbmcgY2dyb3VwIHN1YnN5cyBm cmVlemVyClsgICAgMC4wNzMzODNdIEluaXRpYWxpemluZyBjZ3JvdXAgc3Vic3lzIGJsa2lvClsg ICAgMC4wNzM1NjVdIEluaXRpYWxpemluZyBjZ3JvdXAgc3Vic3lzIHBlcmZfZXZlbnQKWyAgICAw LjA3NDA3N10gQ1BVOiBQaHlzaWNhbCBQcm9jZXNzb3IgSUQ6IDAKWyAgICAwLjA3NDA5NV0gQ1BV OiBQcm9jZXNzb3IgQ29yZSBJRDogMApbICAgIDAuMDc1MjIzXSBBQ1BJOiBDb3JlIHJldmlzaW9u IDIwMTEwNjIzClsgICAgMC4xNDI4NzJdIGZ0cmFjZTogYWxsb2NhdGluZyAyNTgyOSBlbnRyaWVz IGluIDEwMiBwYWdlcwpbICAgIDAuMTQ1MTI2XSBjYWxsaW5nICB0cmFjZV9pbml0X2ZsYWdzX3N5 c19leGl0KzB4MC8weDEyIEAgMQpbICAgIDAuMTQ1MTY0XSBpbml0Y2FsbCB0cmFjZV9pbml0X2Zs YWdzX3N5c19leGl0KzB4MC8weDEyIHJldHVybmVkIDAgYWZ0ZXIgMCB1c2VjcwpbICAgIDAuMTQ1 MTk0XSBjYWxsaW5nICB0cmFjZV9pbml0X2ZsYWdzX3N5c19lbnRlcisweDAvMHgxMiBAIDEKWyAg ICAwLjE0NTIyMF0gaW5pdGNhbGwgdHJhY2VfaW5pdF9mbGFnc19zeXNfZW50ZXIrMHgwLzB4MTIg cmV0dXJuZWQgMCBhZnRlciAwIHVzZWNzClsgICAgMC4xNDUyNTBdIGNhbGxpbmcgIGluaXRfaHdf cGVyZl9ldmVudHMrMHgwLzB4ZGZlIEAgMQpbICAgIDAuMTQ1MjcwXSBQZXJmb3JtYW5jZSBFdmVu dHM6IHVuc3VwcG9ydGVkIHA2IENQVSBtb2RlbCAxNSBubyBQTVUgZHJpdmVyLCBzb2Z0d2FyZSBl dmVudHMgb25seS4KWyAgICAwLjE0NTMxNV0gaW5pdGNhbGwgaW5pdF9od19wZXJmX2V2ZW50cysw eDAvMHhkZmUgcmV0dXJuZWQgMCBhZnRlciAwIHVzZWNzClsgICAgMC4xNDUzNDJdIGNhbGxpbmcg IHJlZ2lzdGVyX3RyaWdnZXJfYWxsX2NwdV9iYWNrdHJhY2UrMHgwLzB4MTQgQCAxClsgICAgMC4x NDUzODZdIGluaXRjYWxsIHJlZ2lzdGVyX3RyaWdnZXJfYWxsX2NwdV9iYWNrdHJhY2UrMHgwLzB4 MTQgcmV0dXJuZWQgMCBhZnRlciAwIHVzZWNzClsgICAgMC4xNDU0MTldIGNhbGxpbmcgIG1pZ3Jh dGlvbl9pbml0KzB4MC8weDZjIEAgMQpbICAgIDAuMTQ1NDUzXSBpbml0Y2FsbCBtaWdyYXRpb25f aW5pdCsweDAvMHg2YyByZXR1cm5lZCAwIGFmdGVyIDAgdXNlY3MKWyAgICAwLjE0NTQ4NF0gY2Fs bGluZyAgc3Bhd25fa3NvZnRpcnFkKzB4MC8weDUxIEAgMQpbICAgIDAuMTQ1ODEzXSBpbml0Y2Fs bCBzcGF3bl9rc29mdGlycWQrMHgwLzB4NTEgcmV0dXJuZWQgMCBhZnRlciAwIHVzZWNzClsgICAg MC4xNDU4NDJdIGNhbGxpbmcgIGluaXRfd29ya3F1ZXVlcysweDAvMHgyYWEgQCAxClsgICAgMC4x NDY4MjddIGluaXRjYWxsIGluaXRfd29ya3F1ZXVlcysweDAvMHgyYWEgcmV0dXJuZWQgMCBhZnRl ciA5NzYgdXNlY3MKWyAgICAwLjE0Njg1Nl0gY2FsbGluZyAgY3B1X3N0b3BfaW5pdCsweDAvMHhj NiBAIDEKWyAgICAwLjE0NzExMF0gaW5pdGNhbGwgY3B1X3N0b3BfaW5pdCsweDAvMHhjNiByZXR1 cm5lZCAwIGFmdGVyIDk3NiB1c2VjcwpbICAgIDAuMTQ3MTM5XSBjYWxsaW5nICByY3Vfc2NoZWR1 bGVyX3JlYWxseV9zdGFydGVkKzB4MC8weDEyIEAgMQpbICAgIDAuMTQ3MTY1XSBpbml0Y2FsbCBy Y3Vfc2NoZWR1bGVyX3JlYWxseV9zdGFydGVkKzB4MC8weDEyIHJldHVybmVkIDAgYWZ0ZXIgMCB1 c2VjcwpbICAgIDAuMTQ3MTk0XSBjYWxsaW5nICByZWxheV9pbml0KzB4MC8weDE0IEAgMQpbICAg IDAuMTQ3MjE5XSBpbml0Y2FsbCByZWxheV9pbml0KzB4MC8weDE0IHJldHVybmVkIDAgYWZ0ZXIg MCB1c2VjcwpbICAgIDAuMTQ3MjQ1XSBjYWxsaW5nICB0cmFjZXJfYWxsb2NfYnVmZmVycysweDAv MHgxYmQgQCAxClsgICAgMC4xNDc1MTldIGluaXRjYWxsIHRyYWNlcl9hbGxvY19idWZmZXJzKzB4 MC8weDFiZCByZXR1cm5lZCAwIGFmdGVyIDAgdXNlY3MKWyAgICAwLjE0NzU1MF0gY2FsbGluZyAg aW5pdF90cmFjZV9wcmludGsrMHgwLzB4MTIgQCAxClsgICAgMC4xNDc1NzJdIGluaXRjYWxsIGlu aXRfdHJhY2VfcHJpbnRrKzB4MC8weDEyIHJldHVybmVkIDAgYWZ0ZXIgMCB1c2VjcwpbICAgIDAu MTQ3NTk5XSBjYWxsaW5nICBqdW1wX2xhYmVsX2luaXRfbW9kdWxlKzB4MC8weDEyIEAgMQpbICAg IDAuMTQ3NjIxXSBpbml0Y2FsbCBqdW1wX2xhYmVsX2luaXRfbW9kdWxlKzB4MC8weDEyIHJldHVy bmVkIDAgYWZ0ZXIgMCB1c2VjcwpbICAgIDAuMTQ3NjUxXSBjYWxsaW5nICBqdW1wX2xhYmVsX2lu aXQrMHgwLzB4OTAgQCAxClsgICAgMC4xNDc5ODVdIGluaXRjYWxsIGp1bXBfbGFiZWxfaW5pdCsw eDAvMHg5MCByZXR1cm5lZCAwIGFmdGVyIDAgdXNlY3MKWyAgICAwLjE0Nzk4NV0gTk1JIHdhdGNo ZG9nIGRpc2FibGVkIChjcHUwKTogaGFyZHdhcmUgZXZlbnRzIG5vdCBlbmFibGVkClsgICAgMC4x NDk1MTRdIGluc3RhbGxpbmcgWGVuIHRpbWVyIGZvciBDUFUgMQpbICAgIDAuMTQ5NzMwXSBsb2Nr ZGVwOiBmaXhpbmcgdXAgYWx0ZXJuYXRpdmVzLgpbICAgIDAuMTUwMzEwXSBOTUkgd2F0Y2hkb2cg ZGlzYWJsZWQgKGNwdTEpOiBoYXJkd2FyZSBldmVudHMgbm90IGVuYWJsZWQKWyAgICAwLjE1MDU4 OV0gQnJvdWdodCB1cCAyIENQVXMKWyAgICAwLjE1NDE4NF0gZGV2dG1wZnM6IGluaXRpYWxpemVk ClsgICAgMC4xODg4MTBdIGNhbGxpbmcgIGlwY19uc19pbml0KzB4MC8weDE0IEAgMQpbICAgIDAu MTg4ODQwXSBpbml0Y2FsbCBpcGNfbnNfaW5pdCsweDAvMHgxNCByZXR1cm5lZCAwIGFmdGVyIDAg dXNlY3MKWyAgICAwLjE4ODg2Nl0gY2FsbGluZyAgaW5pdF9tbWFwX21pbl9hZGRyKzB4MC8weGQg QCAxClsgICAgMC4xODg4ODhdIGluaXRjYWxsIGluaXRfbW1hcF9taW5fYWRkcisweDAvMHhkIHJl dHVybmVkIDAgYWZ0ZXIgMCB1c2VjcwpbICAgIDAuMTg4OTE3XSBjYWxsaW5nICBpbml0X2NwdWZy ZXFfdHJhbnNpdGlvbl9ub3RpZmllcl9saXN0KzB4MC8weDFiIEAgMQpbICAgIDAuMTg4OTU1XSBp bml0Y2FsbCBpbml0X2NwdWZyZXFfdHJhbnNpdGlvbl9ub3RpZmllcl9saXN0KzB4MC8weDFiIHJl dHVybmVkIDAgYWZ0ZXIgMCB1c2VjcwpbICAgIDAuMTg4OTgwXSBjYWxsaW5nICBuZXRfbnNfaW5p dCsweDAvMHhmNCBAIDEKWyAgICAwLjE4OTMyOV0gaW5pdGNhbGwgbmV0X25zX2luaXQrMHgwLzB4 ZjQgcmV0dXJuZWQgMCBhZnRlciA5NzYgdXNlY3MKWyAgICAwLjE4OTMyOV0gY2FsbGluZyAgZTgy MF9tYXJrX252c19tZW1vcnkrMHgwLzB4M2QgQCAxClsgICAgMC4xODkzMjldIGluaXRjYWxsIGU4 MjBfbWFya19udnNfbWVtb3J5KzB4MC8weDNkIHJldHVybmVkIDAgYWZ0ZXIgMCB1c2VjcwpbICAg IDAuMTg5MzI5XSBjYWxsaW5nICBjcHVmcmVxX3RzYysweDAvMHgzMCBAIDEKWyAgICAwLjE4OTMy OV0gaW5pdGNhbGwgY3B1ZnJlcV90c2MrMHgwLzB4MzAgcmV0dXJuZWQgMCBhZnRlciAwIHVzZWNz ClsgICAgMC4xODkzNTBdIGluaXRjYWxsIHBjaV9yZWJvb3RfaW5pdCsweDAvMHgxNCByZXR1cm5l ZCAwIGFmdGVyIDAgdXNlY3MKWyAgICAwLjE4OTM3Nl0gY2FsbGluZyAgaW5pdF9sYXBpY19zeXNm cysweDAvMHgyMCBAIDEKWyAgICAwLjE4OTQyMl0gaW5pdGNhbGwgaW5pdF9sYXBpY19zeXNmcysw eDAvMHgyMCByZXR1cm5lZCAwIGFmdGVyIDAgdXNlY3MKWyAgICAwLjE4OTQ1Ml0gY2FsbGluZyAg aW5pdF9zbXBfZmx1c2grMHgwLzB4NDcgQCAxClsgICAgMC4xODk0OTBdIGluaXRjYWxsIGluaXRf c21wX2ZsdXNoKzB4MC8weDQ3IHJldHVybmVkIDAgYWZ0ZXIgMCB1c2VjcwpbICAgIDAuMTg5NTE4 XSBjYWxsaW5nICBhbGxvY19mcm96ZW5fY3B1cysweDAvMHhkIEAgMQpbICAgIDAuMTg5NTM5XSBp bml0Y2FsbCBhbGxvY19mcm96ZW5fY3B1cysweDAvMHhkIHJldHVybmVkIDAgYWZ0ZXIgMCB1c2Vj cwpbICAgIDAuMTg5NTY2XSBjYWxsaW5nICBzeXNjdGxfaW5pdCsweDAvMHgzMiBAIDEKWyAgICAw LjE4OTk3OV0gaW5pdGNhbGwgc3lzY3RsX2luaXQrMHgwLzB4MzIgcmV0dXJuZWQgMCBhZnRlciAw IHVzZWNzClsgICAgMC4xODk5NzldIGNhbGxpbmcgIGtzeXNmc19pbml0KzB4MC8weDkxIEAgMQpb ICAgIDAuMTkwMDk1XSBpbml0Y2FsbCBrc3lzZnNfaW5pdCsweDAvMHg5MSByZXR1cm5lZCAwIGFm dGVyIDk3NiB1c2VjcwpbICAgIDAuMTkwMTI0XSBjYWxsaW5nICBpbml0X2ppZmZpZXNfY2xvY2tz b3VyY2UrMHgwLzB4MTIgQCAxClsgICAgMC4xOTAxNTRdIGluaXRjYWxsIGluaXRfamlmZmllc19j bG9ja3NvdXJjZSsweDAvMHgxMiByZXR1cm5lZCAwIGFmdGVyIDAgdXNlY3MKWyAgICAwLjE5MDE4 NF0gY2FsbGluZyAgcG1faW5pdCsweDAvMHg2ZiBAIDEKWyAgICAwLjE5MDM2MF0gaW5pdGNhbGwg cG1faW5pdCsweDAvMHg2ZiByZXR1cm5lZCAwIGFmdGVyIDAgdXNlY3MKWyAgICAwLjE5MDM4N10g Y2FsbGluZyAgcG1fZGlza19pbml0KzB4MC8weDE5IEAgMQpbICAgIDAuMTkwNDY4XSBpbml0Y2Fs bCBwbV9kaXNrX2luaXQrMHgwLzB4MTkgcmV0dXJuZWQgMCBhZnRlciAwIHVzZWNzClsgICAgMC4x OTA0OTddIGNhbGxpbmcgIHN3c3VzcF9oZWFkZXJfaW5pdCsweDAvMHgzMSBAIDEKWyAgICAwLjE5 MDUyNl0gaW5pdGNhbGwgc3dzdXNwX2hlYWRlcl9pbml0KzB4MC8weDMxIHJldHVybmVkIDAgYWZ0 ZXIgMCB1c2VjcwpbICAgIDAuMTkwNTUyXSBjYWxsaW5nICBpbml0X2Z0cmFjZV9zeXNjYWxscysw eDAvMHg4NyBAIDEKWyAgICAwLjE5MTQzM10gaW5pdGNhbGwgaW5pdF9mdHJhY2Vfc3lzY2FsbHMr MHgwLzB4ODcgcmV0dXJuZWQgMCBhZnRlciA5NzYgdXNlY3MKWyAgICAwLjE5MTQ2Nl0gY2FsbGlu ZyAgaW5pdF96ZXJvX3BmbisweDAvMHgxZiBAIDEKWyAgICAwLjE5MTQ4OF0gaW5pdGNhbGwgaW5p dF96ZXJvX3BmbisweDAvMHgxZiByZXR1cm5lZCAwIGFmdGVyIDAgdXNlY3MKWyAgICAwLjE5MTUx NF0gY2FsbGluZyAgbWVtb3J5X2ZhaWx1cmVfaW5pdCsweDAvMHhmNCBAIDEKWyAgICAwLjE5MTU0 OF0gaW5pdGNhbGwgbWVtb3J5X2ZhaWx1cmVfaW5pdCsweDAvMHhmNCByZXR1cm5lZCAwIGFmdGVy IDAgdXNlY3MKWyAgICAwLjE5MTU3NF0gY2FsbGluZyAgZnNub3RpZnlfaW5pdCsweDAvMHgzNCBA IDEKWyAgICAwLjE5MTYwNV0gaW5pdGNhbGwgZnNub3RpZnlfaW5pdCsweDAvMHgzNCByZXR1cm5l ZCAwIGFmdGVyIDAgdXNlY3MKWyAgICAwLjE5MTYzMl0gY2FsbGluZyAgZmlsZWxvY2tfaW5pdCsw eDAvMHgyYSBAIDEKWyAgICAwLjE5MTY5OF0gaW5pdGNhbGwgZmlsZWxvY2tfaW5pdCsweDAvMHgy YSByZXR1cm5lZCAwIGFmdGVyIDAgdXNlY3MKWyAgICAwLjE5MTcyNV0gY2FsbGluZyAgaW5pdF9z Y3JpcHRfYmluZm10KzB4MC8weDE0IEAgMQpbICAgIDAuMTkxNzY4XSBpbml0Y2FsbCBpbml0X3Nj cmlwdF9iaW5mbXQrMHgwLzB4MTQgcmV0dXJuZWQgMCBhZnRlciAwIHVzZWNzClsgICAgMC4xOTE3 OTVdIGNhbGxpbmcgIGluaXRfZWxmX2JpbmZtdCsweDAvMHgxNCBAIDEKWyAgICAwLjE5MTgyMF0g aW5pdGNhbGwgaW5pdF9lbGZfYmluZm10KzB4MC8weDE0IHJldHVybmVkIDAgYWZ0ZXIgMCB1c2Vj cwpbICAgIDAuMTkxODQ2XSBjYWxsaW5nICBpbml0X2NvbXBhdF9lbGZfYmluZm10KzB4MC8weDE0 IEAgMQpbICAgIDAuMTkxODcwXSBpbml0Y2FsbCBpbml0X2NvbXBhdF9lbGZfYmluZm10KzB4MC8w eDE0IHJldHVybmVkIDAgYWZ0ZXIgMCB1c2VjcwpbICAgIDAuMTkxOTAwXSBjYWxsaW5nICBkZWJ1 Z2ZzX2luaXQrMHgwLzB4NTcgQCAxClsgICAgMC4xOTE5NzldIGluaXRjYWxsIGRlYnVnZnNfaW5p dCsweDAvMHg1NyByZXR1cm5lZCAwIGFmdGVyIDAgdXNlY3MKWyAgICAwLjE5MTk3OV0gY2FsbGlu ZyAgc2VjdXJpdHlmc19pbml0KzB4MC8weDRlIEAgMQpbICAgIDAuMTkxOTc5XSBpbml0Y2FsbCBz ZWN1cml0eWZzX2luaXQrMHgwLzB4NGUgcmV0dXJuZWQgMCBhZnRlciAwIHVzZWNzClsgICAgMC4x OTE5NzldIGNhbGxpbmcgIHJhbmRvbTMyX2luaXQrMHgwLzB4ZDYgQCAxClsgICAgMC4xOTE5Nzld IGluaXRjYWxsIHJhbmRvbTMyX2luaXQrMHgwLzB4ZDYgcmV0dXJuZWQgMCBhZnRlciAwIHVzZWNz ClsgICAgMC4xOTE5NzldIGNhbGxpbmcgIHRlc3RfYXRvbWljNjQrMHgwLzB4M2M2IEAgMQpbICAg IDAuMTkxOTc5XSBhdG9taWM2NCB0ZXN0IHBhc3NlZCBmb3IgeDg2LTY0IHBsYXRmb3JtIHdpdGgg Q1g4IGFuZCB3aXRoIFNTRQpbICAgIDAuMTkxOTc5XSBpbml0Y2FsbCB0ZXN0X2F0b21pYzY0KzB4 MC8weDNjNiByZXR1cm5lZCAwIGFmdGVyIDAgdXNlY3MKWyAgICAwLjE5MTk3OV0gY2FsbGluZyAg c2ZpX3N5c2ZzX2luaXQrMHgwLzB4ZDQgQCAxClsgICAgMC4xOTE5NzldIGluaXRjYWxsIHNmaV9z eXNmc19pbml0KzB4MC8weGQ0IHJldHVybmVkIDAgYWZ0ZXIgMCB1c2VjcwpbICAgIDAuMTkxOTc5 XSBjYWxsaW5nICB2aXJ0aW9faW5pdCsweDAvMHgyYiBAIDEKWyAgICAwLjE5MjQxM10gaW5pdGNh bGwgdmlydGlvX2luaXQrMHgwLzB4MmIgcmV0dXJuZWQgMCBhZnRlciA5NzYgdXNlY3MKWyAgICAw LjE5MjQ0M10gY2FsbGluZyAgX19nbnR0YWJfaW5pdCsweDAvMHgyMSBAIDEKWyAgICAwLjE5MjU0 OV0gR3JhbnQgdGFibGUgaW5pdGlhbGl6ZWQKWyAgICAwLjE5MjU3MF0gaW5pdGNhbGwgX19nbnR0 YWJfaW5pdCsweDAvMHgyMSByZXR1cm5lZCAwIGFmdGVyIDAgdXNlY3MKWyAgICAwLjE5MjU5Nl0g Y2FsbGluZyAgZWFybHlfcmVzdW1lX2luaXQrMHgwLzB4MTlmIEAgMQpbICAgIDAuMTkyNjY1XSBS VEMgdGltZTogMjM6MDU6NDAsIGRhdGU6IDA5LzEzLzExClsgICAgMC4xOTI3MzBdIGluaXRjYWxs IGVhcmx5X3Jlc3VtZV9pbml0KzB4MC8weDE5ZiByZXR1cm5lZCAwIGFmdGVyIDAgdXNlY3MKWyAg ICAwLjE5Mjc1Nl0gY2FsbGluZyAgY3B1ZnJlcV9jb3JlX2luaXQrMHgwLzB4YTAgQCAxClsgICAg MC4xOTI4NDddIGluaXRjYWxsIGNwdWZyZXFfY29yZV9pbml0KzB4MC8weGEwIHJldHVybmVkIDAg YWZ0ZXIgMCB1c2VjcwpbICAgIDAuMTkyODc1XSBjYWxsaW5nICBjcHVpZGxlX2luaXQrMHgwLzB4 M2QgQCAxClsgICAgMC4xOTI4OTddIGluaXRjYWxsIGNwdWlkbGVfaW5pdCsweDAvMHgzZCByZXR1 cm5lZCAtMTkgYWZ0ZXIgMCB1c2VjcwpbICAgIDAuMTkzNDAyXSBpbml0Y2FsbCBzb2NrX2luaXQr MHgwLzB4ODIgcmV0dXJuZWQgMCBhZnRlciA5NzYgdXNlY3MKWyAgICAwLjE5MzQzMV0gY2FsbGlu ZyAgbmV0X2ludXNlX2luaXQrMHgwLzB4MjYgQCAxClsgICAgMC4xOTM0NzZdIGluaXRjYWxsIG5l dF9pbnVzZV9pbml0KzB4MC8weDI2IHJldHVybmVkIDAgYWZ0ZXIgMCB1c2VjcwpbICAgIDAuMTkz NTEwXSBjYWxsaW5nICBuZXRwb2xsX2luaXQrMHgwLzB4NDEgQCAxClsgICAgMC4xOTM1MzJdIGlu aXRjYWxsIG5ldHBvbGxfaW5pdCsweDAvMHg0MSByZXR1cm5lZCAwIGFmdGVyIDAgdXNlY3MKWyAg ICAwLjE5MzU1OF0gY2FsbGluZyAgbmV0bGlua19wcm90b19pbml0KzB4MC8weDFhOSBAIDEKWyAg ICAwLjE5Mzk1OF0gTkVUOiBSZWdpc3RlcmVkIHByb3RvY29sIGZhbWlseSAxNgpbICAgIDAuMTk0 MDI2XSBpbml0Y2FsbCBuZXRsaW5rX3Byb3RvX2luaXQrMHgwLzB4MWE5IHJldHVybmVkIDAgYWZ0 ZXIgOTc2IHVzZWNzClsgICAgMC4xOTQwNThdIGNhbGxpbmcgIGJkaV9jbGFzc19pbml0KzB4MC8w eDQ5IEAgMQpbICAgIDAuMTk0NzQzXSBpbml0Y2FsbCBiZGlfY2xhc3NfaW5pdCsweDAvMHg0OSBy ZXR1cm5lZCAwIGFmdGVyIDAgdXNlY3MKWyAgICAwLjE5NDc3MV0gY2FsbGluZyAga29iamVjdF91 ZXZlbnRfaW5pdCsweDAvMHgyMSBAIDEKWyAgICAwLjE5NDkzN10gaW5pdGNhbGwga29iamVjdF91 ZXZlbnRfaW5pdCsweDAvMHgyMSByZXR1cm5lZCAwIGFmdGVyIDAgdXNlY3MKWyAgICAwLjE5NDk2 NV0gY2FsbGluZyAgZ3Bpb2xpYl9zeXNmc19pbml0KzB4MC8weDk0IEAgMQpbICAgIDAuMTk1MTky XSBpbml0Y2FsbCBncGlvbGliX3N5c2ZzX2luaXQrMHgwLzB4OTQgcmV0dXJuZWQgMCBhZnRlciA5 NzYgdXNlY3MKWyAgICAwLjE5NTIyMV0gY2FsbGluZyAgcGNpYnVzX2NsYXNzX2luaXQrMHgwLzB4 MTkgQCAxClsgICAgMC4xOTU0MjVdIGluaXRjYWxsIHBjaWJ1c19jbGFzc19pbml0KzB4MC8weDE5 IHJldHVybmVkIDAgYWZ0ZXIgMCB1c2VjcwpbICAgIDAuMTk1NDUzXSBjYWxsaW5nICBwY2lfZHJp dmVyX2luaXQrMHgwLzB4MTIgQCAxClsgICAgMC4xOTU4NTJdIGluaXRjYWxsIHBjaV9kcml2ZXJf aW5pdCsweDAvMHgxMiByZXR1cm5lZCAwIGFmdGVyIDAgdXNlY3MKWyAgICAwLjE5NTg4MV0gY2Fs bGluZyAgYmFja2xpZ2h0X2NsYXNzX2luaXQrMHgwLzB4NWQgQCAxClsgICAgMC4xOTU5NzldIGlu aXRjYWxsIGJhY2tsaWdodF9jbGFzc19pbml0KzB4MC8weDVkIHJldHVybmVkIDAgYWZ0ZXIgMCB1 c2VjcwpbICAgIDAuMTk1OTc5XSBjYWxsaW5nICB4ZW5idXNfaW5pdCsweDAvMHgyNzIgQCAxClsg ICAgMC4xOTY2ODBdIGluaXRjYWxsIHhlbmJ1c19pbml0KzB4MC8weDI3MiByZXR1cm5lZCAwIGFm dGVyIDk3NiB1c2VjcwpbICAgIDAuMTk2NjgwXSBjYWxsaW5nICB0dHlfY2xhc3NfaW5pdCsweDAv MHgzNCBAIDEKWyAgICAwLjE5NjY4MF0gaW5pdGNhbGwgdHR5X2NsYXNzX2luaXQrMHgwLzB4MzQg cmV0dXJuZWQgMCBhZnRlciAwIHVzZWNzClsgICAgMC4xOTY2ODBdIGNhbGxpbmcgIHZ0Y29uc29s ZV9jbGFzc19pbml0KzB4MC8weGUxIEAgMQpbICAgIDAuMTk3NzA4XSBpbml0Y2FsbCB2dGNvbnNv bGVfY2xhc3NfaW5pdCsweDAvMHhlMSByZXR1cm5lZCAwIGFmdGVyIDk3NiB1c2VjcwpbICAgIDAu MTk3NzQyXSBjYWxsaW5nICB3YWtldXBfc291cmNlc19kZWJ1Z2ZzX2luaXQrMHgwLzB4MmIgQCAx ClsgICAgMC4xOTc4NDBdIGluaXRjYWxsIHdha2V1cF9zb3VyY2VzX2RlYnVnZnNfaW5pdCsweDAv MHgyYiByZXR1cm5lZCAwIGFmdGVyIDAgdXNlY3MKWyAgICAwLjE5NzkxNF0gY2FsbGluZyAgcmVn aXN0ZXJfbm9kZV90eXBlKzB4MC8weDJiIEAgMQpbICAgIDAuMTk3OTc4XSBpbml0Y2FsbCByZWdp c3Rlcl9ub2RlX3R5cGUrMHgwLzB4MmIgcmV0dXJuZWQgMCBhZnRlciAwIHVzZWNzClsgICAgMC4x OTc5NzhdIGNhbGxpbmcgIGFtZF9wb3N0Y29yZV9pbml0KzB4MC8weDE1NSBAIDEKWyAgICAwLjE5 Nzk3OF0gaW5pdGNhbGwgYW1kX3Bvc3Rjb3JlX2luaXQrMHgwLzB4MTU1IHJldHVybmVkIDAgYWZ0 ZXIgMCB1c2VjcwpbICAgIDAuMTk3OTc4XSBjYWxsaW5nICBhcmNoX2tkZWJ1Z2ZzX2luaXQrMHgw LzB4MjI0IEAgMQpbICAgIDAuMTk4MTUzXSBpbml0Y2FsbCBhcmNoX2tkZWJ1Z2ZzX2luaXQrMHgw LzB4MjI0IHJldHVybmVkIDAgYWZ0ZXIgOTc2IHVzZWNzClsgICAgMC4xOTgxODZdIGNhbGxpbmcg IGNvbmZpZ3VyZV90cmFtcG9saW5lcysweDAvMHgyNiBAIDEKWyAgICAwLjE5ODIzN10gaW5pdGNh bGwgY29uZmlndXJlX3RyYW1wb2xpbmVzKzB4MC8weDI2IHJldHVybmVkIDAgYWZ0ZXIgMCB1c2Vj cwpbICAgIDAuMTk4MjY3XSBjYWxsaW5nICBtdHJyX2lmX2luaXQrMHgwLzB4NjQgQCAxClsgICAg MC4xOTgyODldIGluaXRjYWxsIG10cnJfaWZfaW5pdCsweDAvMHg2NCByZXR1cm5lZCAtMTkgYWZ0 ZXIgMCB1c2VjcwpbICAgIDAuMTk4MzE1XSBjYWxsaW5nICBmZmhfY3N0YXRlX2luaXQrMHgwLzB4 MmEgQCAxCgpbICAgIDAuMTk4MzQ1XSBpbml0Y2FsbCBmZmhfY3N0YXRlX2luaXQrMHgwLzB4MmEg cmV0dXJuZWQgMCBhZnRlciAwIHVzZWNzClsgICAgMC4xOTgzNzFdIGNhbGxpbmcgIGFjdGl2YXRl X2p1bXBfbGFiZWxzKzB4MC8weDMyIEAgMQpbICAgIDAuMTk4Mzk0XSBpbml0Y2FsbCBhY3RpdmF0 ZV9qdW1wX2xhYmVscysweDAvMHgzMiByZXR1cm5lZCAwIGFmdGVyIDAgdXNlY3MKWyAgICAwLjE5 ODQyMF0gY2FsbGluZyAgZHluYW1pY19kZWJ1Z19pbml0KzB4MC8weDEyMyBAIDEKWyAgICAwLjIw MDQ0N10gaW5pdGNhbGwgZHluYW1pY19kZWJ1Z19pbml0KzB4MC8weDEyMyByZXR1cm5lZCAwIGFm dGVyIDE5NTIgdXNlY3MKWyAgICAwLjIwMDQ3OV0gY2FsbGluZyAgYWNwaV9wY2lfaW5pdCsweDAv MHg2MSBAIDEKWyAgICAwLjIwMDUyMV0gQUNQSTogYnVzIHR5cGUgcGNpIHJlZ2lzdGVyZWQKWyAg ICAwLjIwMDU0MF0gaW5pdGNhbGwgYWNwaV9wY2lfaW5pdCsweDAvMHg2MSByZXR1cm5lZCAwIGFm dGVyIDAgdXNlY3MKWyAgICAwLjIwMDU2Nl0gY2FsbGluZyAgZG1hX2J1c19pbml0KzB4MC8weDE5 IEAgMQpbICAgIDAuMjAwNzQxXSBpbml0Y2FsbCBkbWFfYnVzX2luaXQrMHgwLzB4MTkgcmV0dXJu ZWQgMCBhZnRlciAwIHVzZWNzClsgICAgMC4yMDA3NjhdIGNhbGxpbmcgIGRtYV9jaGFubmVsX3Rh YmxlX2luaXQrMHgwLzB4ZDIgQCAxClsgICAgMC4yMDA4NDRdIGluaXRjYWxsIGRtYV9jaGFubmVs X3RhYmxlX2luaXQrMHgwLzB4ZDIgcmV0dXJuZWQgMCBhZnRlciAwIHVzZWNzClsgICAgMC4yMDA4 NzRdIGNhbGxpbmcgIHNldHVwX3ZjcHVfaG90cGx1Z19ldmVudCsweDAvMHgyMiBAIDEKWyAgICAw LjIwMDg5Nl0gaW5pdGNhbGwgc2V0dXBfdmNwdV9ob3RwbHVnX2V2ZW50KzB4MC8weDIyIHJldHVy bmVkIDAgYWZ0ZXIgMCB1c2VjcwpbICAgIDAuMjAwOTI2XSBjYWxsaW5nICByZWdpc3Rlcl94ZW5f cGNpX25vdGlmaWVyKzB4MC8weDMxIEAgMQpbICAgIDAuMjAwOTc4XSBpbml0Y2FsbCByZWdpc3Rl cl94ZW5fcGNpX25vdGlmaWVyKzB4MC8weDMxIHJldHVybmVkIDAgYWZ0ZXIgMCB1c2VjcwpbICAg IDAuMjAwOTc4XSBjYWxsaW5nICBkbWlfaWRfaW5pdCsweDAvMHgzMTggQCAxClsgICAgMC4yMDE5 NzhdIGNhbGxpbmcgIHBjaV9hcmNoX2luaXQrMHgwLzB4NjYgQCAxClsgICAgMC4yMDIwMTZdIFBD STogTU1DT05GSUcgZm9yIGRvbWFpbiAwMDAwIFtidXMgMDAtM2ZdIGF0IFttZW0gMHhmMDAwMDAw MC0weGYzZmZmZmZmXSAoYmFzZSAweGYwMDAwMDAwKQpbICAgIDAuMjAyMDUzXSBQQ0k6IE1NQ09O RklHIGF0IFttZW0gMHhmMDAwMDAwMC0weGYzZmZmZmZmXSByZXNlcnZlZCBpbiBFODIwClsgICAg MC4yMzQ4MzNdIFBDSTogVXNpbmcgY29uZmlndXJhdGlvbiB0eXBlIDEgZm9yIGJhc2UgYWNjZXNz ClsgICAgMC4yMzQ4NjddIGRtaSB0eXBlIDB4QjEgcmVjb3JkIC0gdW5rbm93biBmbGFnClsgICAg MC4yMzQ4OTJdIGluaXRjYWxsIHBjaV9hcmNoX2luaXQrMHgwLzB4NjYgcmV0dXJuZWQgMCBhZnRl ciAzMjIyMSB1c2VjcwpbICAgIDAuMjM0OTE4XSBjYWxsaW5nICB0b3BvbG9neV9pbml0KzB4MC8w eDlkIEAgMQpbICAgIDAuMjQyOTM1XSBpbml0Y2FsbCB0b3BvbG9neV9pbml0KzB4MC8weDlkIHJl dHVybmVkIDAgYWZ0ZXIgNzgxMSB1c2VjcwpbICAgIDAuMjQyOTY2XSBjYWxsaW5nICBtdHJyX2lu aXRfZmluaWFsaXplKzB4MC8weDM2IEAgMQpbICAgIDAuMjQyOTcyXSBpbml0Y2FsbCBtdHJyX2lu aXRfZmluaWFsaXplKzB4MC8weDM2IHJldHVybmVkIDAgYWZ0ZXIgMCB1c2VjcwpbICAgIDAuMjQy OTcyXSBjYWxsaW5nICBpbml0X3Zkc28rMHgwLzB4MTI1IEAgMQpbICAgIDAuMjQyOTcyXSBpbml0 Y2FsbCBpbml0X3Zkc28rMHgwLzB4MTI1IHJldHVybmVkIDAgYWZ0ZXIgMCB1c2VjcwpbICAgIDAu MjQyOTcyXSBjYWxsaW5nICBzeXNlbnRlcl9zZXR1cCsweDAvMHgyYzMgQCAxClsgICAgMC4yNDI5 NzJdIGluaXRjYWxsIHN5c2VudGVyX3NldHVwKzB4MC8weDJjMyByZXR1cm5lZCAwIGFmdGVyIDAg dXNlY3MKWyAgICAwLjI0Mjk3Ml0gY2FsbGluZyAgcGFyYW1fc3lzZnNfaW5pdCsweDAvMHgxYTEg QCAxClsgICAgMC4yNjk5MTFdIGluaXRjYWxsIHBhcmFtX3N5c2ZzX2luaXQrMHgwLzB4MWExIHJl dHVybmVkIDAgYWZ0ZXIgMjYzNjMgdXNlY3MKWyAgICAwLjI2OTk0OV0gY2FsbGluZyAgcG1fc3lz cnFfaW5pdCsweDAvMHgxZSBAIDEKWyAgICAwLjI2OTk2OF0gaW5pdGNhbGwgcG1fc3lzcnFfaW5p dCsweDAvMHgxZSByZXR1cm5lZCAwIGFmdGVyIDAgdXNlY3MKWyAgICAwLjI2OTk2OF0gY2FsbGlu ZyAgZGVmYXVsdF9iZGlfaW5pdCsweDAvMHhhZiBAIDEKWyAgICAwLjI3MTI0MV0gaW5pdGNhbGwg ZGVmYXVsdF9iZGlfaW5pdCsweDAvMHhhZiByZXR1cm5lZCAwIGFmdGVyIDE5NTIgdXNlY3MKWyAg ICAwLjI3MTI3Ml0gY2FsbGluZyAgaW5pdF9iaW8rMHgwLzB4ZmUgQCAxClsgICAgMC4yNzIxNzVd IGJpbzogY3JlYXRlIHNsYWIgPGJpby0wPiBhdCAwClsgICAgMC4yNzI0NDVdIGluaXRjYWxsIGlu aXRfYmlvKzB4MC8weGZlIHJldHVybmVkIDAgYWZ0ZXIgOTc2IHVzZWNzClsgICAgMC4yNzI0NzNd IGNhbGxpbmcgIGZzbm90aWZ5X25vdGlmaWNhdGlvbl9pbml0KzB4MC8weDhiIEAgMQpbICAgIDAu MjcyNjEzXSBpbml0Y2FsbCBmc25vdGlmeV9ub3RpZmljYXRpb25faW5pdCsweDAvMHg4YiByZXR1 cm5lZCAwIGFmdGVyIDAgdXNlY3MKWyAgICAwLjI3MjY0NV0gY2FsbGluZyAgY3J5cHRvbWdyX2lu aXQrMHgwLzB4MTIgQCAxClsgICAgMC4yNzI2NjddIGluaXRjYWxsIGNyeXB0b21ncl9pbml0KzB4 MC8weDEyIHJldHVybmVkIDAgYWZ0ZXIgMCB1c2VjcwpbICAgIDAuMjcyNjkzXSBjYWxsaW5nICBj cnlwdGRfaW5pdCsweDAvMHhlOCBAIDEKWyAgICAwLjI3Mjc3OV0gaW5pdGNhbGwgY3J5cHRkX2lu aXQrMHgwLzB4ZTggcmV0dXJuZWQgMCBhZnRlciAwIHVzZWNzClsgICAgMC4yNzI4MDZdIGNhbGxp bmcgIGJsa19zZXR0aW5nc19pbml0KzB4MC8weDJhIEAgMQpbICAgIDAuMjcyODI4XSBpbml0Y2Fs bCBibGtfc2V0dGluZ3NfaW5pdCsweDAvMHgyYSByZXR1cm5lZCAwIGFmdGVyIDAgdXNlY3MKWyAg ICAwLjI3Mjg1NF0gY2FsbGluZyAgYmxrX2lvY19pbml0KzB4MC8weDJhIEAgMQpbICAgIDAuMjcy OTE4XSBpbml0Y2FsbCBibGtfaW9jX2luaXQrMHgwLzB4MmEgcmV0dXJuZWQgMCBhZnRlciAwIHVz ZWNzClsgICAgMC4yNzI5NDVdIGNhbGxpbmcgIGJsa19zb2Z0aXJxX2luaXQrMHgwLzB4NmQgQCAx ClsgICAgMC4yNzI5NjddIGluaXRjYWxsIGJsa19zb2Z0aXJxX2luaXQrMHgwLzB4NmQgcmV0dXJu ZWQgMCBhZnRlciAwIHVzZWNzClsgICAgMC4yNzI5NjddIGNhbGxpbmcgIGJsa19pb3BvbGxfc2V0 dXArMHgwLzB4NmQgQCAxClsgICAgMC4yNzI5NjddIGluaXRjYWxsIGJsa19pb3BvbGxfc2V0dXAr MHgwLzB4NmQgcmV0dXJuZWQgMCBhZnRlciAwIHVzZWNzClsgICAgMC4yNzI5NjddIGNhbGxpbmcg IGdlbmhkX2RldmljZV9pbml0KzB4MC8weDc5IEAgMQpbICAgIDAuMjczMjEzXSBpbml0Y2FsbCBn ZW5oZF9kZXZpY2VfaW5pdCsweDAvMHg3OSByZXR1cm5lZCAwIGFmdGVyIDk3NiB1c2VjcwpbICAg IDAuMjczMjI2XSBjYWxsaW5nICBibGtfZGV2X2ludGVncml0eV9pbml0KzB4MC8weDJhIEAgMQpb ICAgIDAuMjczMjkxXSBpbml0Y2FsbCBibGtfZGV2X2ludGVncml0eV9pbml0KzB4MC8weDJhIHJl dHVybmVkIDAgYWZ0ZXIgMCB1c2VjcwpbICAgIDAuMjczMzIzXSBjYWxsaW5nICBncGlvbGliX2Rl YnVnZnNfaW5pdCsweDAvMHgyNCBAIDEKWyAgICAwLjI3MzQxN10gaW5pdGNhbGwgZ3Bpb2xpYl9k ZWJ1Z2ZzX2luaXQrMHgwLzB4MjQgcmV0dXJuZWQgMCBhZnRlciAwIHVzZWNzClsgICAgMC4yNzM0 NDZdIGNhbGxpbmcgIHBjaV9zbG90X2luaXQrMHgwLzB4NGEgQCAxClsgICAgMC4yNzM1MTldIGlu aXRjYWxsIHBjaV9zbG90X2luaXQrMHgwLzB4NGEgcmV0dXJuZWQgMCBhZnRlciAwIHVzZWNzClsg ICAgMC4yNzM1NDZdIGNhbGxpbmcgIGZibWVtX2luaXQrMHgwLzB4OTggQCAxClsgICAgMC4yNzM4 OTRdIGluaXRjYWxsIGZibWVtX2luaXQrMHgwLzB4OTggcmV0dXJuZWQgMCBhZnRlciAwIHVzZWNz ClsgICAgMC4yNzM5MjJdIGNhbGxpbmcgIGFjcGlfaW5pdCsweDAvMHgyYWIgQCAxClsgICAgMC4y NzM5NjddIEFDUEk6IEFkZGVkIF9PU0koTW9kdWxlIERldmljZSkKWyAgICAwLjI3Mzk2N10gQUNQ STogQWRkZWQgX09TSShQcm9jZXNzb3IgRGV2aWNlKQpbICAgIDAuMjczOTY3XSBBQ1BJOiBBZGRl ZCBfT1NJKDMuMCBfU0NQIEV4dGVuc2lvbnMpClsgICAgMC4yNzM5NjddIEFDUEk6IEFkZGVkIF9P U0koUHJvY2Vzc29yIEFnZ3JlZ2F0b3IgRGV2aWNlKQpbICAgIDAuMjc1MzM4XSBBQ1BJOiBFQzog TG9vayB1cCBFQyBpbiBEU0RUClsgICAgMC4zMTk5ODJdIEFDUEk6IFNTRFQgMDAwMDAwMDA3ZjZk NDE3NiAwMDIwMiAodjAxICBQbVJlZiAgQ3B1MElzdCAwMDAwMzAwMCBJTlRMIDIwMDUwNjI0KQpb ICAgIDAuMzIwOTYwXSBBQ1BJOiBEeW5hbWljIE9FTSBUYWJsZSBMb2FkOgpbICAgIDAuMzIwOTYw XSBBQ1BJOiBTU0RUICAgICAgICAgICAobnVsbCkgMDAyMDIgKHYwMSAgUG1SZWYgIENwdTBJc3Qg MDAwMDMwMDAgSVsgICAgMC4zMjE5NjBdIEFDUEk6IFNTRFQgMDAwMDAwMDA3ZjZkM2YyYiAwMDFD NiAodjAxICBQbVJlZiAgQ3B1MENzdCAwMDAwMzAwMSBJTlRMIDIwMDUwNjI0KQpbICAgIDAuMzIy MzMyXSBBQ1BJOiBEeW5hbWljIE9FTSBUYWJsZSBMb2FkOgpbICAgIDAuMzIyMzY0XSBBQ1BJOiBT U0RUICAgICAgICAgICAobnVsbCkgMDAxQzYgKHYwMSAgUG1SZWYgIENwdTBDc3QgMDAwMDMwMDEg SU5UTCAyMDA1MDYyNCkKWyAgICAwLjMyMjk2MF0gQUNQSTogU1NEVCAwMDAwMDAwMDdmNmQ0Mzc4 IDAwMEM0ICh2MDEgIFBtUmVmICBDcHUxSXN0IDAwMDAzMDAwIElOVEwgMjAwNTA2MjQpClsgICAg MC4zMjM5NjBdIEFDUEk6IER5bmFtaWMgT0VNIFRhYmxlIExvYWQ6ClsgICAgMC4zMjM5NjBdIEFD UEk6IFNTRFQgICAgICAgICAgIChudWxsKSAwMDBDNCAodjAxICBQbVJlZiAgQ3B1MUlzdCAwMDAw MzAwMCBJTlRMIDIwMDUwNjI0KQpbICAgIDAuMzI1MDE3XSBBQ1BJOiBTU0RUIDAwMDAwMDAwN2Y2 ZDQwZjEgMDAwODUgKHYwMSAgUG1SZWYgIENwdTFDc3QgMDAwMDMwMDAgSU5UTCAyMDA1MDYyNCkK WyAgICAwLjMyNTk1OV0gQUNQSTogRHluYW1pYyBPRU0gVGFibGUgTG9hZDoKWyAgICAwLjMyNTk1 OV0gQUNQSTogU1NEVCAgICAgICAgICAgKG51bGwpIDAwMDg1ICh2MDEgIFBtUmVmICBDcHUxQ3N0 IDAwMDAzMDAwIElOVEwgMjAwNTA2MjQpClsgICAgMC4zMjU5NTldIEFDUEk6IEludGVycHJldGVy IGVuYWJsZWQKWyAgICAwLjMyNTk1OV0gQUNQSTogKHN1cHBvcnRzIFMwIFMzIFM0IFM1KQpbICAg IDAuMzI1OTU5XSBBQ1BJOiBVc2luZyBJT0FQSUMgZm9yIGludGVycnVwdCByb3V0aW5nClsgICAg MC42MTUzNTldIGluaXRjYWxsIGFjcGlfaW5pdCsweDAvMHgyYWIgcmV0dXJuZWQgMCBhZnRlciAz MzM5MzMgdXNlY3MKWyAgICAwLjYxNTM5OV0gY2FsbGluZyAgZG9ja19pbml0KzB4MC8weGE1IEAg MQpbICAgIDAuNjIwOTE0XSBBQ1BJOiBObyBkb2NrIGRldmljZXMgZm91bmQuClsgICAgMC42MjA5 MTRdIGluaXRjYWxsIGRvY2tfaW5pdCsweDAvMHhhNSByZXR1cm5lZCAwIGFmdGVyIDQ4ODIgdXNl Y3MKWyAgICAwLjYyMDkxNF0gY2FsbGluZyAgYWNwaV9wY2lfcm9vdF9pbml0KzB4MC8weDJkIEAg MQpbICAgIDAuNjIwOTE0XSBIRVNUOiBUYWJsZSBub3QgZm91bmQuClsgICAgMC42MjA5MTRdIFBD STogSWdub3JpbmcgaG9zdCBicmlkZ2Ugd2luZG93cyBmcm9tIEFDUEk7IGlmIG5lY2Vzc2FyeSwg dXNlICJwY2k9dXNlX2NycyIgYW5kIHJlcG9ydCBhIGJ1ZwpbICAgIDAuNjYxOTA4XSBBQ1BJOiBQ Q0kgUm9vdCBCcmlkZ2UgW1BDSTBdIChkb21haW4gMDAwMCBbYnVzIDAwLWZmXSkKWyAgICAwLjcz NTg5N10gcGNpX3Jvb3QgUE5QMEEwMzowMDogaG9zdCBicmlkZ2Ugd2luZG93IFtpbyAgMHgwMDAw LTB4MGNmN10gKGlnbm9yZWQpClsgICAgMC43MzU4OTddIHBjaV9yb290IFBOUDBBMDM6MDA6IGhv c3QgYnJpZGdlIHdpbmRvdyBbaW8gIDB4MGQwMC0weGZmZmZdIChpZ25vcmVkKQpbICAgIDAuNzM1 ODk3XSBwY2lfcm9vdCBQTlAwQTAzOjAwOiBob3N0IGJyaWRnZSB3aW5kb3cgW21lbSAweDAwMGEw MDAwLTB4MDAwYmZmZmZdIChpZ25vcmVkKQpbICAgIDAuNzM1ODk3XSBwY2lfcm9vdCBQTlAwQTAz OjAwOiBob3N0IGJyaWRnZSB3aW5kb3cgW21lbSAweDAwMGQwMDAwLTB4MDAwZGZmZmZdIChpZ25v cmVkKQpbICAgIDAuNzM1ODk3XSBwY2lfcm9vdCBQTlAwQTAzOjAwOiBob3N0IGJyaWRnZSB3aW5k b3cgW21lbSAweDgwMDAwMDAwLTB4ZWZmZmZmZmZdIChpZ25vcmVkKQpbICAgIDAuNzM1ODk3XSBw Y2lfcm9vdCBQTlAwQTAzOjAwOiBob3N0IGJyaWRnZSB3aW5kb3cgW21lbSAweGY0MDA3MDAwLTB4 ZjQwMDdmZmZdIChpZ25vcmVkKQpbICAgIDAuNzM1ODk3XSBwY2lfcm9vdCBQTlAwQTAzOjAwOiBo b3N0IGJyaWRnZSB3aW5kb3cgW21lbSAweGY0MDBjMDAwLTB4ZmViZmZmZmZdIChpZ25vcmVkKQpb ICAgIDAuNzM1ODk3XSBwY2lfcm9vdCBQTlAwQTAzOjAwOiBob3N0IGJyaWRnZSB3aW5kb3cgW21l bSAweGZlYzEwMDAwLTB4ZmVjZmZmZmZdIChpZ25vcmVkKQpbICAgIDAuNzM1ODk3XSBwY2lfcm9v dCBQTlAwQTAzOjAwOiBob3N0IGJyaWRnZSB3aW5kb3cgW21lbSAweGZlZDAwNDAwLTB4ZmVkMWZm ZmZdIChpZ25vcmVkKQpbICAgIDAuNzM1ODk3XSBwY2lfcm9vdCBQTlAwQTAzOjAwOiBob3N0IGJy aWRnZSB3aW5kb3cgW21lbSAweGZlZTEwMDAwLTB4ZmZhZmZmZmZdIChpZ25vcmVkKQpbICAgIDAu NzM1ODk3XSBwY2kgMDAwMDowMDowMC4wOiBbODA4NjoyN2EwXSB0eXBlIDAgY2xhc3MgMHgwMDA2 MDAKWyAgICAwLjczNjA0OF0gcGNpIDAwMDA6MDA6MDIuMDogWzgwODY6MjdhMl0gdHlwZSAwIGNs YXNzIDB4MDAwMzAwClsgICAgMC43MzYxNThdIHBjaSAwMDAwOjAwOjAyLjA6IHJlZyAxMDogW21l bSAweGVmZjAwMDAwLTB4ZWZmN2ZmZmZdClsgICAgMC43MzYyMjNdIHBjaSAwMDAwOjAwOjAyLjA6 IHJlZyAxNDogW2lvICAweGVmZjgtMHhlZmZmXQpbICAgIDAuNzM2MjkwXSBwY2kgMDAwMDowMDow Mi4wOiByZWcgMTg6IFttZW0gMHhkMDAwMDAwMC0weGRmZmZmZmZmIHByZWZdClsgICAgMC43MzYz NTRdIHBjaSAwMDAwOjAwOjAyLjA6IHJlZyAxYzogW21lbSAweGVmZWMwMDAwLTB4ZWZlZmZmZmZd ClsgICAgMC43MzY3NTVdIHBjaSAwMDAwOjAwOjAyLjE6IFs4MDg2OjI3YTZdIHR5cGUgMCBjbGFz cyAweDAwMDM4MApbICAgIDAuNzM2ODQ4XSBwY2kgMDAwMDowMDowMi4xOiByZWcgMTA6IFttZW0g MHhlZmY4MDAwMC0weGVmZmZmZmZmXQpbICAgIDAuNzM3MzM5XSBwY2kgMDAwMDowMDoxYi4wOiBb ODA4NjoyN2Q4XSB0eXBlIDAgY2xhc3MgMHgwMDA0MDMKWyAgICAwLjczNzQ1MV0gcGNpIDAwMDA6 MDA6MWIuMDogcmVnIDEwOiBbbWVtIDB4ZWZlYmMwMDAtMHhlZmViZmZmZiA2NGJpdF0KWyAgICAw LjczNzg5Nl0gcGNpIDAwMDA6MDA6MWIuMDogUE1FIyBzdXBwb3J0ZWQgZnJvbSBEMCBEM2hvdCBE M2NvbGQKWyAgICAwLjczNzg5Nl0gcGNpIDAwMDA6MDA6MWIuMDogUE1FIyBkaXNhYmxlZApbICAg IDAuNzM3OTcxXSBwY2kgMDAwMDowMDoxYy4wOiBQTUUjIHN1cHBvcnRlZCBmcm9tIEQwIEQzaG90 IEQzY29sZApbICAgIDAuNzM4MDExXSBwY2kgMDAwMDowMDoxYy4wOiBQTUUjIGRpc2FibGVkClsg ICAgMC43MzgyMDNdIHBjaSAwMDAwOjAwOjFjLjM6IFs4MDg2OjI3ZDZdIHR5cGUgMSBjbGFzcyAw eDAwMDYwNApbICAgIDAuNzM4NjkyXSBwY2kgMDAwMDowMDoxYy4zOiBQTUUjIHN1cHBvcnRlZCBm cm9tIEQwIEQzaG90IEQzY29sZApbICAgIDAuNzM4NzMyXSBwY2kgMDAwMDowMDoxYy4zOiBQTUUj IGRpc2FibGVkClsgICAgMC43Mzg4OTZdIHBjaSAwMDAwOjAwOjFkLjA6IFs4MDg2OjI3YzhdIHR5 cGUgMCBjbGFzcyAweDAwMGMwMwpbICAgIDAuNzM4ODk2XSBwY2kgMDAwMDowMDoxZC4wOiByZWcg MjA6IFtpbyAgMHhiZjgwLTB4YmY5Zl0KWyAgICAwLjczOTAwMV0gcGNpIDAwMDA6MDA6MWQuMTog WzgwODY6MjdjOV0gdHlwZSAwIGNsYXNzIDB4MDAwYzAzClsgICAgMC43MzkyNzBdIHBjaSAwMDAw OjAwOjFkLjE6IHJlZyAyMDogW2lvICAweGJmNjAtMHhiZjdmXQpbICAgIDAuNzM5NTI2XSBwY2kg MDAwMDowMDoxZC4yOiBbODA4NjoyN2NhXSB0eXBlIDAgY2xhc3MgMHgwMDBjMDMKWyAgICAwLjcz OTc4N10gcGNpIDAwMDA6MDA6MWQuMjogcmVnIDIwOiBbaW8gIDB4YmY0MC0weGJmNWZdClsgICAg MC43Mzk4OTZdIHBjaSAwMDAwOjAwOjFkLjM6IFs4MDg2OjI3Y2JdIHR5cGUgMCBjbGFzcyAweDAw MGMwMwpbICAgIDAuNzM5ODk2XSBwY2kgMDAwMDowMDoxZC4zOiByZWcgMjA6IFtpbyAgMHhiZjIw LTB4YmYzZl0KWyAgICAwLjc0MDAzNl0gcGNpIDAwMDA6MDA6MWQuNzogWzgwODY6MjdjY10gdHlw ZSAwIGNsYXNzIDB4MDAwYzAzClsgICAgMC43NDAxNThdIHBjaSAwMDAwOjAwOjFkLjc6IHJlZyAx MDogW21lbSAweGZmYTgwMDAwLTB4ZmZhODAzZmZdClsgICAgMC43NDA2MDRdIHBjaSAwMDAwOjAw OjFkLjc6IFBNRSMgc3VwcG9ydGVkIGZyb20gRDAgRDNob3QgRDNjb2xkClsgICAgMC43NDA2NDRd IHBjaSAwMDAwOjAwOjFkLjc6IFBNRSMgZGlzYWJsZWQKWyAgICAwLjc0MDc4Nl0gcGNpIDAwMDA6 MDA6MWUuMDogWzgwODY6MjQ0OF0gdHlwZSAxIGNsYXNzIDB4MDAwNjA0ClsgICAgMC43NDEwMzld IHBjaSAwMDAwOjAwOjFmLjA6IFs4MDg2OjI3YjldIHR5cGUgMCBjbGFzcyAweDAwMDYwMQpbICAg IDAuNzQxNTU2XSBwY2kgMDAwMDowMDoxZi4wOiBxdWlyazogW2lvICAweDEwMDAtMHgxMDdmXSBj bGFpbWVkIGJ5IElDSDYgQUNQSS9HUElPL1RDTwpbICAgIDAuNzQxNjA0XSBwY2kgMDAwMDowMDox Zi4wOiBxdWlyazogW2lvICAweDEwODAtMHgxMGJmXSBjbGFpbWVkIGJ5IElDSDYgR1BJTwpbICAg IDAuNzQxNjQyXSBwY2kgMDAwMDowMDoxZi4wOiBJQ0g3IExQQyBHZW5lcmljIElPIGRlY29kZSAx IFBJTyBhdCAwOTAwIChtYXNrIDAwN2YpClsgICAgMC43NDE2ODVdIHBjaSAwMDAwOjAwOjFmLjA6 IElDSDcgTFBDIEdlbmVyaWMgSU8gZGVjb2RlIDMgUElPIGF0IDBjODAgKG1hc2sgMDAzZikKWyAg ICAwLjc0MTg5Nl0gcGNpIDAwMDA6MDA6MWYuMjogWzgwODY6MjdjNF0gdHlwZSAwIGNsYXNzIDB4 MDAwMTAxClsgICAgMC43NDE4OTZdIHBjaSAwMDAwOjAwOjFmLjI6IHJlZyAxMDogW2lvICAweDAx ZjAtMHgwMWY3XQpbICAgIDAuNzQxODk2XSBwY2kgMDAwMDowMDoxZi4yOiByZWcgMTQ6IFtpbyAg MHgwM2Y0LTB4MDNmN10KWyAgICAwLjc0MTg5Nl0gcGNpIDAwMDA6MDA6MWYuMjogcmVnIDE4OiBb aW8gIDB4MDE3MC0weDAxNzddClsgICAgMC43NDE4OTZdIHBjaSAwMDAwOjAwOjFmLjI6IHJlZyAx YzogW2lvICAweDAzNzQtMHgwMzc3XQpbICAgIDAuNzQxODk2XSBwY2kgMDAwMDowMDoxZi4yOiBy ZWcgMjA6IFtpbyAgMHhiZmEwLTB4YmZhZl0KWyAgICAwLjc0MTkzM10gcGNpIDAwMDA6MDA6MWYu MjogUE1FIyBzdXBwb3J0ZWQgZnJvbSBEM2hvdApbICAgIDAuNzQxOTc2XSBwY2kgMDAwMDowMDox Zi4yOiBQTUUjIGRpc2FibGVkClsgICAgMC43NDIxMTNdIHBjaSAwMDAwOjAwOjFmLjM6IFs4MDg2 OjI3ZGFdIHR5cGUgMCBjbGFzcyAweDAwMGMwNQpbICAgIDAuNzQyMzkyXSBwY2kgMDAwMDowMDox Zi4zOiByZWcgMjA6IFtpbyAgMHgxMGMwLTB4MTBkZl0KWyAgICAwLjc0Mjg5NV0gcGNpIDAwMDA6 MGI6MDAuMDogWzgwODY6NDIyMl0gdHlwZSAwIGNsYXNzIDB4MDAwMjgwClsgICAgMC43NDI4OTVd IHBjaSAwMDAwOjBiOjAwLjA6IHJlZyAxMDogW21lbSAweGVmZGZmMDAwLTB4ZWZkZmZmZmZdClsg ICAgMC43NDI5NDldIHBjaSAwMDAwOjBiOjAwLjA6IFBNRSMgc3VwcG9ydGVkIGZyb20gRDAgRDNo b3QgRDNjb2xkClsgICAgMC43NDI5OTddIHBjaSAwMDAwOjBiOjAwLjA6IFBNRSMgZGlzYWJsZWQK WyAgICAwLjc0MzE1NF0gcGNpIDAwMDA6MGI6MDAuMDogZGlzYWJsaW5nIEFTUE0gb24gcHJlLTEu MSBQQ0llIGRldmljZS4gIFlvdSBjYW4gZW5hYmxlIGl0IHdpdGggJ3BjaWVfYXNwbT1mb3JjZScK WyAgICAwLjc0MzM2NF0gcGNpIDAwMDA6MDA6MWMuMDogUENJIGJyaWRnZSB0byBbYnVzIDBiLTBi XQpbICAgIDAuNzQzNDEzXSBwY2kgMDAwMDowMDoxYy4wOiAgIGJyaWRnZSB3aW5kb3cgW21lbSAw eGVmZDAwMDAwLTB4ZWZkZmZmZmZdClsgICAgMC43NDM4NjFdIHBjaSAwMDAwOjBjOjAwLjA6IFs5 NzEwOjk5MjJdIHR5cGUgMCBjbGFzcyAweDAwMDcwMApbICAgIDAuNzQzODk1XSBwY2kgMDAwMDow YzowMC4wOiByZWcgMTA6IFtpbyAgMHhkZmY4LTB4ZGZmZl0KWyAgICAwLjc0Mzg5NV0gcGNpIDAw MDA6MGM6MDAuMDogcmVnIDE0OiBbbWVtIDB4ZWZjZmUwMDAtMHhlZmNmZWZmZl0KWyAgICAwLjc0 Mzg5NV0gcGNpIDAwMDA6MGM6MDAuMDogcmVnIDI0OiBbbWVtIDB4ZWZjZmYwMDAtMHhlZmNmZmZm Zl0KWyAgICAwLjc0Mzk1Ml0gcGNpIDAwMDA6MGM6MDAuMDogUE1FIyBzdXBwb3J0ZWQgZnJvbSBE M2hvdCBEM2NvbGQKWyAgICAwLjc0Mzk5M10gcGNpIDAwMDA6MGM6MDAuMDogUE1FIyBkaXNhYmxl ZApbICAgIDAuNzQ0Mjg4XSBwY2kgMDAwMDowMDoxYy4zOiBQQ0kgYnJpZGdlIHRvIFtidXMgMGMt MGRdClsgICAgMC43NDQzMjNdIHBjaSAwMDAwOjAwOjFjLjM6ICAgYnJpZGdlIHdpbmRvdyBbaW8g IDB4ZDAwMC0weGRmZmZdClsgICAgMC43NDQzNjFdIHBjaSAwMDAwOjAwOjFjLjM6ICAgYnJpZGdl IHdpbmRvdyBbbWVtIDB4ZWZiMDAwMDAtMHhlZmNmZmZmZl0KWyAgICAwLjc0NDQxMl0gcGNpIDAw MDA6MDA6MWMuMzogICBicmlkZ2Ugd2luZG93IFttZW0gMHhlMDAwMDAwMC0weGUwMWZmZmZmIDY0 Yml0IHByZWZdClsgICAgMC43NDQ2ODhdIHBjaSAwMDAwOjAzOjAwLjA6IFsxNGU0OjE3MGNdIHR5 cGUgMCBjbGFzcyAweDAwMDIwMApbICAgIDAuNzQ0Nzk2XSBwY2kgMDAwMDowMzowMC4wOiByZWcg MTA6IFttZW0gMHhlZmFmZTAwMC0weGVmYWZmZmZmXQpbICAgIDAuNzQ0OTMzXSBwY2kgMDAwMDow MzowMC4wOiBzdXBwb3J0cyBEMSBEMgpbICAgIDAuNzQ0OTU2XSBwY2kgMDAwMDowMzowMC4wOiBQ TUUjIHN1cHBvcnRlZCBmcm9tIEQwIEQxIEQyIEQzaG90IEQzY29sZApbICAgIDAuNzQ1MTY5XSBw Y2kgMDAwMDowMzowMS4wOiBbMTE4MDowODMyXSB0eXBlIDAgY2xhc3MgMHgwMDBjMDAKWyAgICAw Ljc0NTI5NV0gcGNpIDAwMDA6MDM6MDEuMDogcHJvcHJpZXRhcnkgUmljb2ggTU1DIGNvbnRyb2xs ZXIgZGlzYWJsZWQgKHZpYSBmaXJld2lyZSBmdW5jdGlvbikKWyAgICAwLjc0NTMyOV0gcGNpIDAw MDA6MDM6MDEuMDogTU1DIGNhcmRzIGFyZSBub3cgc3VwcG9ydGVkIGJ5IHN0YW5kYXJkIFNESENJ IGNvbnRyb2xsZXIKWyAgICAwLjc0NTQxN10gcGNpIDAwMDA6MDM6MDEuMDogcmVnIDEwOiBbbWVt IDB4ZWZhZmQ4MDAtMHhlZmFmZGZmZl0KWyAgICAwLjc0NTg0NV0gcGNpIDAwMDA6MDM6MDEuMDog c3VwcG9ydHMgRDEgRDIKWyAgICAwLjc0NTg2N10gcGNpIDAwMDA6MDM6MDEuMDogUE1FIyBzdXBw b3J0ZWQgZnJvbSBEMCBEMSBEMiBEM2hvdCBEM2NvbGQKWyAgICAwLjc0NTg5NV0gcGNpIDAwMDA6 MDM6MDEuMDogUE1FIyBkaXNhYmxlZApbICAgIDAuNzQ1ODk1XSBwY2kgMDAwMDowMzowMS4xOiBb MTE4MDowODIyXSB0eXBlIDAgY2xhc3MgMHgwMDA4MDUKWyAgICAwLjc0NTg5NV0gcGNpIDAwMDA6 MDM6MDEuMTogcmVnIDEwOiBbbWVtIDB4ZWZhZmQ0MDAtMHhlZmFmZDRmZl0KWyAgICAwLjc0NTkz NF0gcGNpIDAwMDA6MDM6MDEuMTogc3VwcG9ydHMgRDEgRDIKWyAgICAwLjc0NTk1Nl0gcGNpIDAw MDA6MDM6MDEuMTogUE1FIyBzdXBwb3J0ZWQgZnJvbSBEMCBEMSBEMiBEM2hvdCBEM2NvbGQKWyAg ICAwLjc0NTk5OF0gcGNpIDAwMDA6MDM6MDEuMTogUE1FIyBkaXNhYmxlZApbICAgIDAuNzQ2MTIz XSBwY2kgMDAwMDowMzowMS4yOiBbMTE4MDowNTkyXSB0eXBlIDAgY2xhc3MgMHgwMDA4ODAKWyAg ICAwLjc0NjIzMl0gcGNpIDAwMDA6MDM6MDEuMjogcmVnIDEwOiBbbWVtIDB4ZWZhZmQ2MDAtMHhl ZmFmZDZmZl0KWyAgICAwLjc0NjY2MV0gcGNpIDAwMDA6MDM6MDEuMjogc3VwcG9ydHMgRDEgRDIK WyAgICAwLjc0NjY4M10gcGNpIDAwMDA6MDM6MDEuMjogUE1FIyBzdXBwb3J0ZWQgZnJvbSBEMCBE MSBEMiBEM2hvdCBEM2NvbGQKWyAgICAwLjc0Njc2N10gcGNpIDAwMDA6MDM6MDEuMjogUE1FIyBk aXNhYmxlZApbICAgIDAuNzQ2ODk1XSBwY2kgMDAwMDowMzowMS4zOiBbMTE4MDowODUyXSB0eXBl IDAgY2xhc3MgMHgwMDA4ODAKWyAgICAwLjc0Njg5NV0gcGNpIDAwMDA6MDM6MDEuMzogcmVnIDEw OiBbbWVtIDB4ZWZhZmQ3MDAtMHhlZmFmZDdmZl0KWyAgICAwLjc0NzMwMl0gcGNpIDAwMDA6MDM6 MDEuMzogc3VwcG9ydHMgRDEgRDIKWyAgICAwLjc0NzMyNV0gcGNpIDAwMDA6MDM6MDEuMzogUE1F IyBzdXBwb3J0ZWQgZnJvbSBEMCBEMSBEMiBEM2hvdCBEM2NvbGQKWyAgICAwLjc0NzM2Nl0gcGNp IDAwMDA6MDM6MDEuMzogUE1FIyBkaXNhYmxlZApbICAgIDAuNzQ3Njk0XSBwY2kgMDAwMDowMDox ZS4wOiBQQ0kgYnJpZGdlIHRvIFtidXMgMDMtMDNdIChzdWJ0cmFjdGl2ZSBkZWNvZGUpClsgICAg MC43NDc3NTBdIHBjaSAwMDAwOjAwOjFlLjA6ICAgYnJpZGdlIHdpbmRvdyBbbWVtIDB4ZWZhMDAw MDAtMHhlZmFmZmZmZl0KWyAgICAwLjc0NzgxOV0gcGNpIDAwMDA6MDA6MWUuMDogICBicmlkZ2Ug d2luZG93IFtpbyAgMHgwMDAwLTB4ZmZmZl0gKHN1YnRyYWN0aXZlIGRlY29kZSkKWyAgICAwLjc0 Nzg2NV0gcGNpIDAwMDA6MDA6MWUuMDogICBicmlkZ2Ugd2luZG93IFttZW0gMHgwMDAwMDAwMC0w eGZmZmZmZmZmZl0gKHN1YnRyYWN0aXZlIGRlY29kZSkKWyAgICAwLjc0Nzg5NV0gQUNQSTogUENJ IEludGVycnVwdCBSb3V0aW5nIFRhYmxlIFtcX1NCXy5QQ0kwLl9QUlRdClsgICAgMC43NTA4OTRd IEFDUEk6IFBDSSBJbnRlcnJ1cHQgUm91dGluZyBUYWJsZSBbXF9TQl8uUENJMC5QQ0lFLl9QUlRd ClsgICAgMC43NTI0MjFdIEFDUEk6IFBDSSBJbnRlcnJ1cHQgUm91dGluZyBUYWJsZSBbXF9TQl8u UENJMC5SUDAxLl9QUlRdClsgICAgMC43NTI4OTRdIEFDUEk6IFBDSSBJbnRlcnJ1cHQgUm91dGlu ZyBUYWJsZSBbXF9TQl8uUENJMC5SUDA0Ll9QUlRdClsgICAgMC43NTQ0ODNdICBwY2kwMDAwOjAw OiBSZXF1ZXN0aW5nIEFDUEkgX09TQyBjb250cm9sICgweDFkKQpbICAgIDAuNzU0NTQzXSAgcGNp MDAwMDowMDogQUNQSSBfT1NDIHJlcXVlc3QgZmFpbGVkIChBRV9OT1RfRk9VTkQpLCByZXR1cm5l ZCBjb250cm9sIG1hc2s6IDB4MWQKWyAgICAwLjc1NDU3N10gQUNQSSBfT1NDIGNvbnRyb2wgZm9y IFBDSWUgbm90IGdyYW50ZWQsIGRpc2FibGluZyBBU1BNCihYRU4pIFBDSSBhZGQgZGV2aWNlIDAw OjAwLjAKKFhFTikgUENJIGFkZCBkZXZpY2UgMDA6MDIuMAooWEVOKSBQQ0kgYWRkIGRldmljZSAw MDowMi4xCihYRU4pIFBDSSBhZGQgZGV2aWNlIDAwOjFiLjAKKFhFTikgUENJIGFkZCBkZXZpY2Ug MDA6MWMuMAooWEVOKSBQQ0kgYWRkIGRldmljZSAwMDoxYy4zCihYRU4pIFBDSSBhZGQgZGV2aWNl IDAwOjFkLjAKKFhFTikgUENJIGFkZCBkZXZpY2UgMDA6MWQuMQooWEVOKSBQQ0kgYWRkIGRldmlj ZSAwMDoxZC4yCihYRU4pIFBDSSBhZGQgZGV2aWNlIDAwOjFkLjMKKFhFTikgUENJIGFkZCBkZXZp Y2UgMDA6MWQuNwooWEVOKSBQQ0kgYWRkIGRldmljZSAwMDoxZS4wCihYRU4pIFBDSSBhZGQgZGV2 aWNlIDAwOjFmLjAKKFhFTikgUENJIGFkZCBkZXZpY2UgMDA6MWYuMgooWEVOKSBQQ0kgYWRkIGRl dmljZSAwMDoxZi4zCihYRU4pIFBDSSBhZGQgZGV2aWNlIDBiOjAwLjAKKFhFTikgUENJIGFkZCBk ZXZpY2UgMGM6MDAuMAooWEVOKSBQQ0kgYWRkIGRldmljZSAwMzowMC4wCihYRU4pIFBDSSBhZGQg ZGV2aWNlIDAzOjAxLjAKKFhFTikgUENJIGFkZCBkZXZpY2UgMDM6MDEuMQooWEVOKSBQQ0kgYWRk IGRldmljZSAwMzowMS4yClsgICAgMC43OTY4ODddIGluaXRjYWxsIGFjcGlfcGNpX3Jvb3RfaW5p dCsweDAvMHgyZCByZXR1cm5lZCAwIGFmdGVyIDE3MTg0OCB1c2VjcwpbICAgIDAuNzk2ODg3XSBj YWxsaW5nICBhY3BpX3BjaV9saW5rX2luaXQrMHgwLzB4M2UgQCAxClsgICAgMC43OTc4ODddIEFD UEk6IFBDSSBJbnRlcnJ1cHQgTGluayBbTE5LQV0gKElSUXMgOSAxMCAqMTEpClsgICAgMC43OTk4 ODddIEFDUEk6IFBDSSBJbnRlcnJ1cHQgTGluayBbTE5LQl0gKElSUXMgNSA3KSAqNApbICAgIDAu ODAxODg2XSBBQ1BJOiBQQ0kgSW50ZXJydXB0IExpbmsgW0xOS0NdIChJUlFzIDkgMTAgKjExKQpb ICAgIDAuODAyODg2XSBBQ1BJOiBQQ0kgSW50ZXJydXB0IExpbmsgW0xOS0RdIChJUlFzIDUgNyA5 IDEwIDExKSAqMwpbICAgIDAuODAzODg2XSBBQ1BJOiBQQ0kgSW50ZXJydXB0IExpbmsgW0xOS0Vd IChJUlFzIDMgNCA1IDYgNyAqOSAxMCAxMSAxMiAxNCAxNSkKWyAgICAwLjgwNTg4Nl0gQUNQSTog UENJIEludGVycnVwdCBMaW5rIFtMTktGXSAoSVJRcyAzIDQgNSA2IDcgOSAqMTAgMTEgMTIgMTQg MTUpClsgICAgMC44MDY4ODZdIEFDUEk6IFBDSSBJbnRlcnJ1cHQgTGluayBbTE5LR10gKElSUXMg MyA0IDUgNiAqNyA5IDEwIDExIDEyIDE0IDE1KQpbICAgIDAuODA3ODg2XSBBQ1BJOiBQQ0kgSW50 ZXJydXB0IExpbmsgW0xOS0hdIChJUlFzIDMgNCAqNSA2IDcgOSAxMCAxMSAxMiAxNCAxNSkKWyAg ICAwLjgwODA0NF0gaW5pdGNhbGwgYWNwaV9wY2lfbGlua19pbml0KzB4MC8weDNlIHJldHVybmVk IDAgYWZ0ZXIgMTE3MTYgdXNlY3MKWyAgICAwLjgwODA3N10gY2FsbGluZyAgcG5wX2luaXQrMHgw LzB4MTIgQCAxClsgICAgMC44MDgzOTVdIGluaXRjYWxsIHBucF9pbml0KzB4MC8weDEyIHJldHVy bmVkIDAgYWZ0ZXIgMCB1c2VjcwpbICAgIDAuODA4NDI1XSBjYWxsaW5nICB4ZW5fc2V0dXBfc2h1 dGRvd25fZXZlbnQrMHgwLzB4MjcgQCAxClsgICAgMC44MDg0OTFdIGluaXRjYWxsIHhlbl9zZXR1 cF9zaHV0ZG93bl9ldmVudCsweDAvMHgyNyByZXR1cm5lZCAwIGFmdGVyIDAgdXNlY3MKWyAgICAw LjgwODUyMV0gY2FsbGluZyAgYmFsbG9vbl9pbml0KzB4MC8weDE0NCBAIDEKWyAgICAwLjgwODU0 MV0geGVuL2JhbGxvb246IEluaXRpYWxpc2luZyBiYWxsb29uIGRyaXZlci4KWyAgICAwLjgwODYw MV0gbGFzdF9wZm4gPSAweDUyNWMyMiBtYXhfYXJjaF9wZm4gPSAweDQwMDAwMDAwMApbICAgIDEu MDEyODU0XSBpbml0Y2FsbCBiYWxsb29uX2luaXQrMHgwLzB4MTQ0IHJldHVybmVkIDAgYWZ0ZXIg MTk5MTg4IHVzZWNzClsgICAgMS4wMTI4NTRdIGNhbGxpbmcgIHhlbmJ1c19wcm9iZV9iYWNrZW5k X2luaXQrMHgwLzB4NTQgQCAxClsgICAgMS4wMTI4NTRdIGluaXRjYWxsIHhlbmJ1c19wcm9iZV9i YWNrZW5kX2luaXQrMHgwLzB4NTQgcmV0dXJuZWQgMCBhZnRlciAwIHVzZWNzClsgICAgMS4wMTI4 NTRdIGNhbGxpbmcgIHhlbmJ1c19wcm9iZV9mcm9udGVuZF9pbml0KzB4MC8weDU0IEAgMQpbICAg IDEuMDEyOTYyXSBpbml0Y2FsbCB4ZW5idXNfcHJvYmVfZnJvbnRlbmRfaW5pdCsweDAvMHg1NCBy ZXR1cm5lZCAwIGFmdGVyIDk3NiB1c2VjcwpbICAgIDEuMDEyOTk1XSBjYWxsaW5nICBiYWxsb29u X2luaXQrMHgwLzB4MTEyIEAgMQpbICAgIDEuMDEzMDE1XSB4ZW4tYmFsbG9vbjogSW5pdGlhbGlz aW5nIGJhbGxvb24gZHJpdmVyLgpbICAgIDEuMDEzNTg0XSBpbml0Y2FsbCBiYWxsb29uX2luaXQr MHgwLzB4MTEyIHJldHVybmVkIDAgYWZ0ZXIgMCB1c2VjcwpbICAgIDEuMDEzNjEyXSBjYWxsaW5n ICB4ZW5fc2VsZmJhbGxvb25faW5pdCsweDAvMHg4MyBAIDEKWyAgICAxLjAxMzYzM10geGVuL2Jh bGxvb246IFhlbiBzZWxmYmFsbG9vbmluZyBkcml2ZXIgZGlzYWJsZWQgZm9yIGRvbWFpbjAuClsg ICAgMS4wMTM2NjBdIGluaXRjYWxsIHhlbl9zZWxmYmFsbG9vbl9pbml0KzB4MC8weDgzIHJldHVy bmVkIC0xOSBhZnRlciAwIHVzZWNzClsgICAgMS4wMTM2ODldIGNhbGxpbmcgIG1pc2NfaW5pdCsw eDAvMHhiNiBAIDEKWyAgICAxLjAxMzg1NF0gaW5pdGNhbGwgbWlzY19pbml0KzB4MC8weGI2IHJl dHVybmVkIDAgYWZ0ZXIgMCB1c2VjcwpbICAgIDEuMDEzODU0XSBjYWxsaW5nICB2Z2FfYXJiX2Rl dmljZV9pbml0KzB4MC8weGU5IEAgMQpbICAgIDEuMDE0NDI5XSB2Z2FhcmI6IGRldmljZSBhZGRl ZDogUENJOjAwMDA6MDA6MDIuMCxkZWNvZGVzPWlvK21lbSxvd25zPWlvK21lbSxsb2Nrcz1ub25l ClsgICAgMS4wMTQ4NTRdIHZnYWFyYjogbG9hZGVkClsgICAgMS4wMTQ4NTRdIHZnYWFyYjogYnJp ZGdlIGNvbnRyb2wgcG9zc2libGUgMDAwMDowMDowMi4wClsgICAgMS4wMTQ4NTRdIGluaXRjYWxs IHZnYV9hcmJfZGV2aWNlX2luaXQrMHgwLzB4ZTkgcmV0dXJuZWQgMCBhZnRlciA5NzYgdXNlY3MK WyAgICAxLjAxNDg1NF0gY2FsbGluZyAgY25faW5pdCsweDAvMHhhMCBAIDEKWyAgICAxLjAxNTAx Ml0gaW5pdGNhbGwgY25faW5pdCsweDAvMHhhMCByZXR1cm5lZCAwIGFmdGVyIDk3NiB1c2Vjcwpb ICAgIDEuMDE1MDQwXSBjYWxsaW5nICBpbml0X3Njc2krMHgwLzB4OGUgQCAxClsgICAgMS4wMTc3 MTldIFNDU0kgc3Vic3lzdGVtIGluaXRpYWxpemVkClsgICAgMS4wMTc3NDFdIGluaXRjYWxsIGlu aXRfc2NzaSsweDAvMHg4ZSByZXR1cm5lZCAwIGFmdGVyIDE5NTIgdXNlY3MKWyAgICAxLjAxNzc2 N10gY2FsbGluZyAgYXRhX2luaXQrMHgwLzB4MzRlIEAgMQpbICAgIDEuMDE4NDcxXSBsaWJhdGEg dmVyc2lvbiAzLjAwIGxvYWRlZC4KWyAgICAxLjAxODQ5NF0gaW5pdGNhbGwgYXRhX2luaXQrMHgw LzB4MzRlIHJldHVybmVkIDAgYWZ0ZXIgOTc2IHVzZWNzClsgICAgMS4wMTg1MjBdIGNhbGxpbmcg IHBoeV9pbml0KzB4MC8weDJlIEAgMQpbICAgIDEuMDE5MDgzXSBpbml0Y2FsbCBwaHlfaW5pdCsw eDAvMHgyZSByZXR1cm5lZCAwIGFmdGVyIDk3NiB1c2VjcwpbICAgIDEuMDE5MTEyXSBjYWxsaW5n ICBpbml0X3BjbWNpYV9jcysweDAvMHgzNiBAIDEKWyAgICAxLjAxOTI4NV0gaW5pdGNhbGwgaW5p dF9wY21jaWFfY3MrMHgwLzB4MzYgcmV0dXJuZWQgMCBhZnRlciAwIHVzZWNzClsgICAgMS4wMTkz MTJdIGNhbGxpbmcgIHVzYl9pbml0KzB4MC8weDE3MCBAIDEKWyAgICAxLjAxOTg1M10gdXNiY29y ZTogcmVnaXN0ZXJlZCBuZXcgaW50ZXJmYWNlIGRyaXZlciB1c2JmcwpbICAgIDEuMDIwMTMxXSB1 c2Jjb3JlOiByZWdpc3RlcmVkIG5ldyBkZXZpY2UgZHJpdmVyIHVzYgpbICAgIDEuMDIwMTU3XSBp bml0Y2FsbCB1c2JfaW5pdCsweDAvMHgxNzAgcmV0dXJuZWQgMCBhZnRlciA5NzYgdXNlY3MKWyAg ICAxLjAyMDE4NF0gY2FsbGluZyAgc2VyaW9faW5pdCsweDAvMHgyZSBAIDEKWyAgICAxLjAyMDUx MF0gaW5pdGNhbGwgc2VyaW9faW5pdCsweDAvMHgyZSByZXR1cm5lZCAwIGFmdGVyIDAgdXNlY3MK WyAgICAxLjAyMDUzOF0gY2FsbGluZyAgaW5wdXRfaW5pdCsweDAvMHgxMDkgQCAxClsgICAgMS4w MjA4NTNdIGluaXRjYWxsIGlucHV0X2luaXQrMHgwLzB4MTA5IHJldHVybmVkIDAgYWZ0ZXIgMCB1 c2VjcwpbICAgIDEuMDIwODUzXSBjYWxsaW5nICBydGNfaW5pdCsweDAvMHg2YSBAIDEKWyAgICAx LjAyMTA0OV0gaW5pdGNhbGwgcnRjX2luaXQrMHgwLzB4NmEgcmV0dXJuZWQgMCBhZnRlciA5NzYg dXNlY3MKWyAgICAxLjAyMTA3N10gY2FsbGluZyAgcG93ZXJfc3VwcGx5X2NsYXNzX2luaXQrMHgw LzB4NDAgQCAxClsgICAgMS4wMjEyNjFdIGluaXRjYWxsIHBvd2VyX3N1cHBseV9jbGFzc19pbml0 KzB4MC8weDQwIHJldHVybmVkIDAgYWZ0ZXIgMCB1c2VjcwpbICAgIDEuMDIxMjkzXSBjYWxsaW5n ICBod21vbl9pbml0KzB4MC8weGVlIEAgMQpbICAgIDEuMDIxNTYzXSBpbml0Y2FsbCBod21vbl9p bml0KzB4MC8weGVlIHJldHVybmVkIDAgYWZ0ZXIgMCB1c2VjcwpbICAgIDEuMDIxNTkxXSBjYWxs aW5nICBtZF9pbml0KzB4MC8weDE0YSBAIDEKWyAgICAxLjAyMTg1M10gaW5pdGNhbGwgbWRfaW5p dCsweDAvMHgxNGEgcmV0dXJuZWQgMCBhZnRlciAwIHVzZWNzClsgICAgMS4wMjE4NTNdIGNhbGxp bmcgIGxlZHNfaW5pdCsweDAvMHg0NCBAIDEKWyAgICAxLjAyMTg1M10gaW5pdGNhbGwgbGVkc19p bml0KzB4MC8weDQ0IHJldHVybmVkIDAgYWZ0ZXIgMCB1c2VjcwpbICAgIDEuMDIxODUzXSBjYWxs aW5nICBwY2lfc3Vic3lzX2luaXQrMHgwLzB4NGEgQCAxClsgICAgMS4wMjE4NTNdIFBDSTogVXNp bmcgQUNQSSBmb3IgSVJRIHJvdXRpbmcKWyAgICAxLjAyMTg1M10gUENJOiBwY2lfY2FjaGVfbGlu ZV9zaXplIHNldCB0byA2NCBieXRlcwpbICAgIDEuMDIyNTQ1XSByZXNlcnZlIFJBTSBidWZmZXI6 IDAwMDAwMDAwMDAwOWYwMDAgLSAwMDAwMDAwMDAwMDlmZmZmClsgICAgMS4wMjI2MTNdIHJlc2Vy dmUgUkFNIGJ1ZmZlcjogMDAwMDAwMDA3NWY5MjAwMCAtIDAwMDAwMDAwNzdmZmZmZmYKWyAgICAx LjAyMjY2NV0gcmVzZXJ2ZSBSQU0gYnVmZmVyOiAwMDAwMDAwNTI1YzIyMDAwIC0gMDAwMDAwMDUy N2ZmZmZmZgpbICAgIDEuMDIyNzEzXSBpbml0Y2FsbCBwY2lfc3Vic3lzX2luaXQrMHgwLzB4NGEg cmV0dXJuZWQgMCBhZnRlciA5NzYgdXNlY3MKWyAgICAxLjAyMjc0NV0gY2FsbGluZyAgcHJvdG9f aW5pdCsweDAvMHgxMiBAIDEKWyAgICAxLjAyMjgyMV0gaW5pdGNhbGwgcHJvdG9faW5pdCsweDAv MHgxMiByZXR1cm5lZCAwIGFmdGVyIDAgdXNlY3MKWyAgICAxLjAyMjg0OV0gY2FsbGluZyAgbmV0 X2Rldl9pbml0KzB4MC8weDI0OSBAIDEKWyAgICAxLjAyNDg1Ml0gaW5pdGNhbGwgbmV0X2Rldl9p bml0KzB4MC8weDI0OSByZXR1cm5lZCAwIGFmdGVyIDE5NTIgdXNlY3MKWyAgICAxLjAyNDg1Ml0g Y2FsbGluZyAgbmVpZ2hfaW5pdCsweDAvMHg4MCBAIDEKWyAgICAxLjAyNDg1Ml0gaW5pdGNhbGwg bmVpZ2hfaW5pdCsweDAvMHg4MCByZXR1cm5lZCAwIGFmdGVyIDAgdXNlY3MKWyAgICAxLjAyNDg1 Ml0gY2FsbGluZyAgZmliX3J1bGVzX2luaXQrMHgwLzB4YWMgQCAxClsgICAgMS4wMjQ4NTJdIGlu aXRjYWxsIGZpYl9ydWxlc19pbml0KzB4MC8weGFjIHJldHVybmVkIDAgYWZ0ZXIgMCB1c2Vjcwpb ICAgIDEuMDI0ODUyXSBjYWxsaW5nICBwa3RzY2hlZF9pbml0KzB4MC8weGZiIEAgMQpbICAgIDEu MDI0ODUyXSBpbml0Y2FsbCBwa3RzY2hlZF9pbml0KzB4MC8weGZiIHJldHVybmVkIDAgYWZ0ZXIg MCB1c2VjcwpbICAgIDEuMDI0ODUyXSBjYWxsaW5nICB0Y19maWx0ZXJfaW5pdCsweDAvMHg1NSBA IDEKWyAgICAxLjAyNDg1Ml0gaW5pdGNhbGwgdGNfZmlsdGVyX2luaXQrMHgwLzB4NTUgcmV0dXJu ZWQgMCBhZnRlciAwIHVzZWNzClsgICAgMS4wMjQ4NTJdIGNhbGxpbmcgIHRjX2FjdGlvbl9pbml0 KzB4MC8weDU1IEAgMQpbICAgIDEuMDI0ODUyXSBpbml0Y2FsbCB0Y19hY3Rpb25faW5pdCsweDAv MHg1NSByZXR1cm5lZCAwIGFmdGVyIDAgdXNlY3MKWyAgICAxLjAyNDg1Ml0gY2FsbGluZyAgZ2Vu bF9pbml0KzB4MC8weDkxIEAgMQpbICAgIDEuMDI0OTU0XSBpbml0Y2FsbCBnZW5sX2luaXQrMHgw LzB4OTEgcmV0dXJuZWQgMCBhZnRlciA5NzYgdXNlY3MKWyAgICAxLjAyNDk4Ml0gY2FsbGluZyAg Y2lwc29fdjRfaW5pdCsweDAvMHg4NSBAIDEKWyAgICAxLjAyNTA1Ml0gaW5pdGNhbGwgY2lwc29f djRfaW5pdCsweDAvMHg4NSByZXR1cm5lZCAwIGFmdGVyIDAgdXNlY3MKWyAgICAxLjAyNTA4MF0g Y2FsbGluZyAgd2lyZWxlc3NfbmxldmVudF9pbml0KzB4MC8weDEyIEAgMQpbICAgIDEuMDI1MTA3 XSBpbml0Y2FsbCB3aXJlbGVzc19ubGV2ZW50X2luaXQrMHgwLzB4MTIgcmV0dXJuZWQgMCBhZnRl ciAwIHVzZWNzClsgICAgMS4wMjUxMzddIGNhbGxpbmcgIG5ldGxibF9pbml0KzB4MC8weDgxIEAg MQpbICAgIDEuMDI1MTU3XSBOZXRMYWJlbDogSW5pdGlhbGl6aW5nClsgICAgMS4wMjUxNzNdIE5l dExhYmVsOiAgZG9tYWluIGhhc2ggc2l6ZSA9IDEyOApbICAgIDEuMDI1MTkzXSBOZXRMYWJlbDog IHByb3RvY29scyA9IFVOTEFCRUxFRCBDSVBTT3Y0ClsgICAgMS4wMjU1NTddIE5ldExhYmVsOiAg dW5sYWJlbGVkIHRyYWZmaWMgYWxsb3dlZCBieSBkZWZhdWx0ClsgICAgMS4wMjU1ODJdIGluaXRj YWxsIG5ldGxibF9pbml0KzB4MC8weDgxIHJldHVybmVkIDAgYWZ0ZXIgMCB1c2VjcwpbICAgIDEu MDI1NjA5XSBjYWxsaW5nICBzeXNjdGxfaW5pdCsweDAvMHg0OCBAIDEKWyAgICAxLjAyNTYzOF0g aW5pdGNhbGwgc3lzY3RsX2luaXQrMHgwLzB4NDggcmV0dXJuZWQgMCBhZnRlciAwIHVzZWNzClsg ICAgMS4wMjU2NjZdIGNhbGxpbmcgIGhwZXRfbGF0ZV9pbml0KzB4MC8weGY0IEAgMQpbICAgIDEu MDI1Njg4XSBpbml0Y2FsbCBocGV0X2xhdGVfaW5pdCsweDAvMHhmNCByZXR1cm5lZCAtMTkgYWZ0 ZXIgMCB1c2VjcwpbICAgIDEuMDI1NzE0XSBjYWxsaW5nICBpbml0X2FtZF9uYnMrMHgwLzB4YTQg QCAxClsgICAgMS4wMjU4NTJdIGluaXRjYWxsIGluaXRfYW1kX25icysweDAvMHhhNCByZXR1cm5l ZCAwIGFmdGVyIDAgdXNlY3MKWyAgICAxLjAyNTg1Ml0gY2FsbGluZyAgY2xvY2tzb3VyY2VfZG9u ZV9ib290aW5nKzB4MC8weDVlIEAgMQpbICAgIDEuMDI1ODUyXSBTd2l0Y2hpbmcgdG8gY2xvY2tz b3VyY2UgeGVuClsgICAgMS4wMjU4NTJdIGluaXRjYWxsIGNsb2Nrc291cmNlX2RvbmVfYm9vdGlu ZysweDAvMHg1ZSByZXR1cm5lZCAwIGFmdGVyIDEwNDUgWyAgICAxLjAyNTg1Ml0gY2FsbGluZyAg ZnRyYWNlX2luaXRfZGVidWdmcysweDAvMHgyMGMgQCAxClsgICAgMS4wMjU4NTJdIGluaXRjYWxs IGZ0cmFjZV9pbml0X2RlYnVnZnMrMHgwLzB4MjBjIHJldHVybmVkIDAgYWZ0ZXIgODUyIHVzZWNz ClsgICAgMS4wMjU4NTJdIGNhbGxpbmcgIHJiX2luaXRfZGVidWdmcysweDAvMHgyZiBAIDEKWyAg ICAxLjAyNTg1Ml0gaW5pdGNhbGwgcmJfaW5pdF9kZWJ1Z2ZzKzB4MC8weDJmIHJldHVybmVkIDAg YWZ0ZXIgNjYgdXNlY3MKWyAgICAxLjAyNTg1Ml0gY2FsbGluZyAgdHJhY2VyX2luaXRfZGVidWdm cysweDAvMHgzYmEgQCAxClsgICAgMS4wMjcxMjhdIFN3aXRjaGVkIHRvIE5PSHogbW9kZSBvbiBD UFUgIzAKWyAgICAxLjAyNzM1NV0gU3dpdGNoZWQgdG8gTk9IeiBtb2RlIG9uIENQVSAjMQpbICAg IDEuMDMwNjkwXSBpbml0Y2FsbCB0cmFjZXJfaW5pdF9kZWJ1Z2ZzKzB4MC8weDNiYSByZXR1cm5l ZCAwIGFmdGVyIDM1NjkgdXNlY3MKWyAgICAxLjAzMDcyM10gY2FsbGluZyAgaW5pdF90cmFjZV9w cmludGtfZnVuY3Rpb25fZXhwb3J0KzB4MC8weDJmIEAgMQpbICAgIDEuMDMwODI5XSBpbml0Y2Fs bCBpbml0X3RyYWNlX3ByaW50a19mdW5jdGlvbl9leHBvcnQrMHgwLzB4MmYgcmV0dXJuZWQgMCBh ZnRlciA3NiB1c2VjcwpbICAgIDEuMDMwODYwXSBjYWxsaW5nICBldmVudF90cmFjZV9pbml0KzB4 MC8weDJiNiBAIDEKWyAgICAxLjM5NDgyN10gaW5pdGNhbGwgZXZlbnRfdHJhY2VfaW5pdCsweDAv MHgyYjYgcmV0dXJuZWQgMCBhZnRlciAzNTU0MDUgdXNlY3MKWyAgICAxLjM5NDg3N10gY2FsbGlu ZyAgaW5pdF9rcHJvYmVfdHJhY2UrMHgwLzB4OTQgQCAxClsgICAgMS4zOTUwMzBdIGluaXRjYWxs IGluaXRfa3Byb2JlX3RyYWNlKzB4MC8weDk0IHJldHVybmVkIDAgYWZ0ZXIgMTI3IHVzZWNzClsg ICAgMS4zOTUwNjFdIGNhbGxpbmcgIGluaXRfcGlwZV9mcysweDAvMHg0OSBAIDEKWyAgICAxLjM5 NTE2OF0gaW5pdGNhbGwgaW5pdF9waXBlX2ZzKzB4MC8weDQ5IHJldHVybmVkIDAgYWZ0ZXIgMzY4 IHVzZWNzClsgICAgMS4zOTUxNjhdIGNhbGxpbmcgIGV2ZW50cG9sbF9pbml0KzB4MC8weGExIEAg MQpbICAgIDEuMzk1NjgzXSBpbml0Y2FsbCBldmVudHBvbGxfaW5pdCsweDAvMHhhMSByZXR1cm5l ZCAwIGFmdGVyIDE2NCB1c2VjcwpbICAgIDEuMzk1NzEzXSBjYWxsaW5nICBhbm9uX2lub2RlX2lu aXQrMHgwLzB4MTJhIEAgMQpbICAgIDEuMzk2MTAwXSBpbml0Y2FsbCBhbm9uX2lub2RlX2luaXQr MHgwLzB4MTJhIHJldHVybmVkIDAgYWZ0ZXIgMzU1IHVzZWNzClsgICAgMS4zOTYxMzBdIGNhbGxp bmcgIGJsa19zY3NpX2lvY3RsX2luaXQrMHgwLzB4Mjg5IEAgMQpbICAgIDEuMzk2MTU0XSBpbml0 Y2FsbCBibGtfc2NzaV9pb2N0bF9pbml0KzB4MC8weDI4OSByZXR1cm5lZCAwIGFmdGVyIDEgdXNl Y3MKWyAgICAxLjM5NjE4MV0gY2FsbGluZyAgYWNwaV9ldmVudF9pbml0KzB4MC8weDUyIEAgMQpb ICAgIDEuMzk2Mzc1XSBpbml0Y2FsbCBhY3BpX2V2ZW50X2luaXQrMHgwLzB4NTIgcmV0dXJuZWQg MCBhZnRlciAxNjcgdXNlY3MKWyAgICAxLjM5NjQwNF0gY2FsbGluZyAgcG5wX3N5c3RlbV9pbml0 KzB4MC8weDEyIEAgMQpbICAgIDEuMzk2NjUxXSBpbml0Y2FsbCBwbnBfc3lzdGVtX2luaXQrMHgw LzB4MTIgcmV0dXJuZWQgMCBhZnRlciAyMTggdXNlY3MKWyAgICAxLjM5NjY3OV0gY2FsbGluZyAg cG5wYWNwaV9pbml0KzB4MC8weDhjIEAgMQpbICAgIDEuMzk2NzAwXSBwbnA6IFBuUCBBQ1BJIGlu aXQKWyAgICAxLjM5NzA1MV0gQUNQSTogYnVzIHR5cGUgcG5wIHJlZ2lzdGVyZWQKWyAgICAxLjc4 ODc0OF0gcG5wIDAwOjAwOiBbbWVtIDB4MDAwMDAwMDAtMHgwMDA5ZmJmZl0KWyAgICAxLjc4ODc0 OF0gcG5wIDAwOjAwOiBbbWVtIDB4MDAwOWZjMDAtMHgwMDA5ZmZmZl0KWyAgICAxLjc4ODc0OF0g cG5wIDAwOjAwOiBbbWVtIDB4MDAwYzAwMDAtMHgwMDBjZmZmZl0KWyAgICAxLjg1OTI2NF0gcG5w IDAwOjAwOiBbbWVtIDB4MDAwZTAwMDAtMHgwMDBmZmZmZl0KWyAgICAxLjg1OTMwMV0gcG5wIDAw OjAwOiBbbWVtIDB4MDAxMDAwMDAtMHg3ZjZkMzNmZl0KWyAgICAxLjg1OTMzNl0gcG5wIDAwOjAw OiBbbWVtIDB4N2Y2ZDM0MDAtMHg3ZjZmZmZmZl0KWyAgICAxLjg1OTM3Ml0gcG5wIDAwOjAwOiBb bWVtIDB4N2Y3MDAwMDAtMHg3ZjdmZmZmZl0KWyAgICAxLjg1OTQwNl0gcG5wIDAwOjAwOiBbbWVt IDB4N2Y3MDAwMDAtMHg3ZmVmZmZmZl0KWyAgICAxLjg1OTQ0MV0gcG5wIDAwOjAwOiBbbWVtIDB4 ZmZiMDAwMDAtMHhmZmZmZmZmZl0KWyAgICAxLjg1OTQ3NV0gcG5wIDAwOjAwOiBbbWVtIDB4ZmVj MDAwMDAtMHhmZWMwZmZmZl0KWyAgICAxLjg1OTUwOV0gcG5wIDAwOjAwOiBbbWVtIDB4ZmVlMDAw MDAtMHhmZWUwZmZmZl0KWyAgICAxLjg1OTU3Nl0gcG5wIDAwOjAwOiBbbWVtIDB4ZmVkMjAwMDAt MHhmZWQ5ZmZmZl0KWyAgICAxLjg1OTYxMF0gcG5wIDAwOjAwOiBbbWVtIDB4ZmZhODAwMDAtMHhm ZmE4M2ZmZl0KWyAgICAxLjg1OTY0NF0gcG5wIDAwOjAwOiBbbWVtIDB4ZjQwMDAwMDAtMHhmNDAw M2ZmZl0KWyAgICAxLjg1OTY3OF0gcG5wIDAwOjAwOiBbbWVtIDB4ZjQwMDQwMDAtMHhmNDAwNGZm Zl0KWyAgICAxLjg1OTcxMl0gcG5wIDAwOjAwOiBbbWVtIDB4ZjQwMDUwMDAtMHhmNDAwNWZmZl0K WyAgICAxLjg1OTc0Nl0gcG5wIDAwOjAwOiBbbWVtIDB4ZjQwMDYwMDAtMHhmNDAwNmZmZl0KWyAg ICAxLjg1OTc4MF0gcG5wIDAwOjAwOiBbbWVtIDB4ZjQwMDgwMDAtMHhmNDAwYmZmZl0KWyAgICAx Ljg1OTgxNF0gcG5wIDAwOjAwOiBbbWVtIDB4ZjAwMDAwMDAtMHhmM2ZmZmZmZl0KWyAgICAxLjg2 MTUyN10gc3lzdGVtIDAwOjAwOiBbbWVtIDB4MDAwMDAwMDAtMHgwMDA5ZmJmZl0gY291bGQgbm90 IGJlIHJlc2VydmVkClsgICAgMS44NjE2MTNdIHN5c3RlbSAwMDowMDogW21lbSAweDAwMDlmYzAw LTB4MDAwOWZmZmZdIGNvdWxkIG5vdCBiZSByZXNlcnZlZApbICAgIDEuODYxNjk3XSBzeXN0ZW0g MDA6MDA6IFttZW0gMHgwMDBjMDAwMC0weDAwMGNmZmZmXSBjb3VsZCBub3QgYmUgcmVzZXJ2ZWQK WyAgICAxLjg2MTc4MV0gc3lzdGVtIDAwOjAwOiBbbWVtIDB4MDAwZTAwMDAtMHgwMDBmZmZmZl0g Y291bGQgbm90IGJlIHJlc2VydmVkClsgICAgMS44NjE4NjVdIHN5c3RlbSAwMDowMDogW21lbSAw eDAwMTAwMDAwLTB4N2Y2ZDMzZmZdIGNvdWxkIG5vdCBiZSByZXNlcnZlZApbICAgIDEuODYxOTIz XSBzeXN0ZW0gMDA6MDA6IFttZW0gMHg3ZjZkMzQwMC0weDdmNmZmZmZmXSBoYXMgYmVlbiByZXNl cnZlZApbICAgIDEuODYxOTgxXSBzeXN0ZW0gMDA6MDA6IFttZW0gMHg3ZjcwMDAwMC0weDdmN2Zm ZmZmXSBoYXMgYmVlbiByZXNlcnZlZApbICAgIDEuODYyMDY1XSBzeXN0ZW0gMDA6MDA6IFttZW0g MHg3ZjcwMDAwMC0weDdmZWZmZmZmXSBjb3VsZCBub3QgYmUgcmVzZXJ2ZWQKWyAgICAxLjg2MjEy Ml0gc3lzdGVtIDAwOjAwOiBbbWVtIDB4ZmZiMDAwMDAtMHhmZmZmZmZmZl0gaGFzIGJlZW4gcmVz ZXJ2ZWQKWyAgICAxLjg2MjI1OV0gc3lzdGVtIDAwOjAwOiBbbWVtIDB4ZmVlMDAwMDAtMHhmZWUw ZmZmZl0gaGFzIGJlZW4gcmVzZXJ2ZWQKWyAgICAxLjg2MjMxNV0gc3lzdGVtIDAwOjAwOiBbbWVt IDB4ZmVkMjAwMDAtMHhmZWQ5ZmZmZl0gaGFzIGJlZW4gcmVzZXJ2ZWQKWyAgICAxLjg2MjQ0Ml0g c3lzdGVtIDAwOjAwOiBbbWVtIDB4ZmZhODAwMDAtMHhmZmE4M2ZmZl0gY291bGQgbm90IGJlIHJl c2VydmVkClsgICAgMS44NjI1MDJdIHN5c3RlbSAwMDowMDogW21lbSAweGY0MDAwMDAwLTB4ZjQw MDNmZmZdIGhhcyBiZWVuIHJlc2VydmVkClsgICAgMS44NjI1NjFdIHN5c3RlbSAwMDowMDogW21l bSAweGY0MDA0MDAwLTB4ZjQwMDRmZmZdIGhhcyBiZWVuIHJlc2VydmVkClsgICAgMS44NjI2MjBd IHN5c3RlbSAwMDowMDogW21lbSAweGY0MDA1MDAwLTB4ZjQwMDVmZmZdIGhhcyBiZWVuIHJlc2Vy dmVkClsgICAgMS44NjI2NzhdIHN5c3RlbSAwMDowMDogW21lbSAweGY0MDA2MDAwLTB4ZjQwMDZm ZmZdIGhhcyBiZWVuIHJlc2VydmVkClsgICAgMS44NjI3MzZdIHN5c3RlbSAwMDowMDogW21lbSAw eGY0MDA4MDAwLTB4ZjQwMGJmZmZdIGhhcyBiZWVuIHJlc2VydmVkClsgICAgMS44NjI3OTRdIHN5 c3RlbSAwMDowMDogW21lbSAweGYwMDAwMDAwLTB4ZjNmZmZmZmZdIGhhcyBiZWVuIHJlc2VydmVk ClsgICAgMS44NjI4MzldIHN5c3RlbSAwMDowMDogUGx1ZyBhbmQgUGxheSBBQ1BJIGRldmljZSwg SURzIFBOUDBjMDEgKGFjdGl2ZSkKWyAgICAyLjA0NjE2OF0gcG5wIDAwOjAxOiBbYnVzIDAwLWZm XQpbICAgIDIuMDQ2MTY4XSBwbnAgMDA6MDE6IFtpbyAgMHgwMDAwLTB4MGNmNyB3aW5kb3ddClsg ICAgMi4wNDYxNjhdIHBucCAwMDowMTogW2lvICAweDBjZjgtMHgwY2ZmXQpbICAgIDIuMjA2NDYz XSBwbnAgMDA6MDE6IFtpbyAgMHgwZDAwLTB4ZmZmZiB3aW5kb3ddClsgICAgMi4yMDY1MDBdIHBu cCAwMDowMTogW21lbSAweDAwMGEwMDAwLTB4MDAwYmZmZmYgd2luZG93XQpbICAgIDIuMjA2NTM1 XSBwbnAgMDA6MDE6IFttZW0gMHgwMDBkMDAwMC0weDAwMGRmZmZmIHdpbmRvd10KWyAgICAyLjIw NjU3MF0gcG5wIDAwOjAxOiBbbWVtIDB4ODAwMDAwMDAtMHhlZmZmZmZmZiB3aW5kb3ddClsgICAg Mi4yMDY2MDVdIHBucCAwMDowMTogW21lbSAweGY0MDA3MDAwLTB4ZjQwMDdmZmYgd2luZG93XQpb ICAgIDIuMjA2NjM5XSBwbnAgMDA6MDE6IFttZW0gMHhmNDAwYzAwMC0weGZlYmZmZmZmIHdpbmRv d10KWyAgICAyLjIwNjY3NF0gcG5wIDAwOjAxOiBbbWVtIDB4ZmVjMTAwMDAtMHhmZWNmZmZmZiB3 aW5kb3ddClsgICAgMi4yMDY3MDhdIHBucCAwMDowMTogW21lbSAweGZlZDAwNDAwLTB4ZmVkMWZm ZmYgd2luZG93XQpbICAgIDIuMjA2NzQzXSBwbnAgMDA6MDE6IFttZW0gMHhmZWRhMDAwMC0weGZl ZDlmZmZmIHdpbmRvdyBkaXNhYmxlZF0KWyAgICAyLjIwNjc4MV0gcG5wIDAwOjAxOiBbbWVtIDB4 ZmVlMTAwMDAtMHhmZmFmZmZmZiB3aW5kb3ddClsgICAgMi4yMDc5NDJdIHBucCAwMDowMTogUGx1 ZyBhbmQgUGxheSBBQ1BJIGRldmljZSwgSURzIFBOUDBhMDMgKGFjdGl2ZSkKWyAgICAyLjIwODYy Ml0gcG5wIDAwOjAyOiBbaW8gIDB4MDA5Ml0KWyAgICAyLjIwODY1NF0gcG5wIDAwOjAyOiBbaW8g IDB4MDBiMl0KWyAgICAyLjIwODY4M10gcG5wIDAwOjAyOiBbaW8gIDB4MDAyMC0weDAwMjFdClsg ICAgMi4yMDg3MTNdIHBucCAwMDowMjogW2lvICAweDAwYTAtMHgwMGExXQpbICAgIDIuMjA4NzQ0 XSBwbnAgMDA6MDI6IFtpcnEgMCBkaXNhYmxlZF0KWyAgICAyLjIwODc3M10gcG5wIDAwOjAyOiBb aW8gIDB4MDRkMC0weDA0ZDFdClsgICAgMi4yMDg4MDNdIHBucCAwMDowMjogW2lvICAweDEwMDAt MHgxMDA1XQpbICAgIDIuMjA4ODMyXSBwbnAgMDA6MDI6IFtpbyAgMHgxMDA4LTB4MTAwZl0KWyAg ICAyLjIwOTA2NF0gcG5wIDAwOjAyOiBkaXNhYmxpbmcgW2lvICAweDEwMDAtMHgxMDA1XSBiZWNh dXNlIGl0IG92ZXJsYXBzIDAwMDA6MDA6MWYuMCBCQVIgMTMgW2lvICAweDEwMDAtMHgxMDdmXQpb ICAgIDIuMjA5MDY0XSBwbnAgMDA6MDI6IGRpc2FibGluZyBbaW8gIDB4MTAwOC0weDEwMGZdIGJl Y2F1c2UgaXQgb3ZlcmxhcHMgMDAwMDowMDoxZi4wIEJBUiAxMyBbaW8gIDB4MTAwMC0weDEwN2Zd ClsgICAgMi4yMTA0ODddIHN5c3RlbSAwMDowMjogW2lvICAweDA0ZDAtMHgwNGQxXSBoYXMgYmVl biByZXNlcnZlZApbICAgIDIuMjEwNTMwXSBzeXN0ZW0gMDA6MDI6IFBsdWcgYW5kIFBsYXkgQUNQ SSBkZXZpY2UsIElEcyBQTlAwYzAxIChhY3RpdmUpClsgICAgMi4yMTEyMDFdIHBucCAwMDowMzog W2lvICAweGY0MDAtMHhmNGZlXQpbICAgIDIuMjExMjczXSBwbnAgMDA6MDM6IFtpbyAgMHgwMDg2 XQpbICAgIDIuMjExMzA1XSBwbnAgMDA6MDM6IFtpbyAgMHgwMGIzXQpbICAgIDIuMjExMzM1XSBw bnAgMDA6MDM6IFtpbyAgMHgxMDA2LTB4MTAwN10KWyAgICAyLjIxMTM2NV0gcG5wIDAwOjAzOiBb aW8gIDB4MTAwYS0weDEwNTldClsgICAgMi4yMTEzOTVdIHBucCAwMDowMzogW2lvICAweDEwNjAt MHgxMDdmXQpbICAgIDIuMjExNDI1XSBwbnAgMDA6MDM6IFtpbyAgMHgxMDgwLTB4MTBiZl0KWyAg ICAyLjIxMTQ1NV0gcG5wIDAwOjAzOiBbaW8gIDB4MTBjMC0weDEwZGZdClsgICAgMi4yMTE0ODZd IHBucCAwMDowMzogW2lvICAweDEwMTAtMHgxMDJmXQpbICAgIDIuMjExNTE2XSBwbnAgMDA6MDM6 IFtpbyAgMHgwODA5XQpbICAgIDIuMjExOTUwXSBwbnAgMDA6MDM6IGRpc2FibGluZyBbaW8gIDB4 MTAwNi0weDEwMDddIGJlY2F1c2UgaXQgb3ZlcmxhcHMgMDAwMDowMDoxZi4wIEJBUiAxMyBbaW8g IDB4MTAwMC0weDEwN2ZdClsgICAgMi4yMTE5OTBdIHBucCAwMDowMzogZGlzYWJsaW5nIFtpbyAg MHgxMDBhLTB4MTA1OV0gYmVjYXVzZSBpdCBvdmVybGFwcyAwMDAwOjAwOjFmLjAgQkFSIDEzIFtp byAgMHgxMDAwLTB4MTA3Zl0KWyAgICAyLjIxMjAyOV0gcG5wIDAwOjAzOiBkaXNhYmxpbmcgW2lv ICAweDEwNjAtMHgxMDdmXSBiZWNhdXNlIGl0IG92ZXJsYXBzIDAwMDA6MDA6MWYuMCBCQVIgMTMg W2lvICAweDEwMDAtMHgxMDdmXQpbICAgIDIuMjEyMDY4XSBwbnAgMDA6MDM6IGRpc2FibGluZyBb aW8gIDB4MTAxMC0weDEwMmZdIGJlY2F1c2UgaXQgb3ZlcmxhcHMgMDAwMDowMDoxZi4wIEJBUiAx MyBbaW8gIDB4MTAwMC0weDEwN2ZdClsgICAgMi4yMTMyNDNdIHN5c3RlbSAwMDowMzogW2lvICAw eGY0MDAtMHhmNGZlXSBoYXMgYmVlbiByZXNlcnZlZApbICAgIDIuMjEzMzAyXSBzeXN0ZW0gMDA6 MDM6IFtpbyAgMHgxMDgwLTB4MTBiZl0gaGFzIGJlZW4gcmVzZXJ2ZWQKWyAgICAyLjIxMzM1OF0g c3lzdGVtIDAwOjAzOiBbaW8gIDB4MTBjMC0weDEwZGZdIGhhcyBiZWVuIHJlc2VydmVkClsgICAg Mi4yMTM0NTBdIHN5c3RlbSAwMDowMzogUGx1ZyBhbmQgUGxheSBBQ1BJIGRldmljZSwgSURzIFBO UDBjMDEgKGFjdGl2ZSkKWyAgICAyLjIxNDEyM10geGVuOiByZWdpc3RlcmluZyBnc2kgMTIgdHJp Z2dlcmluZyAxIHBvbGFyaXR5IDAKWyAgICAyLjIxNDI0N10geGVuX21hcF9waXJxX2dzaTogcmV0 dXJuaW5nIGlycSAxMiBmb3IgZ3NpIDEyClsgICAgMi4yMTQyNzJdIHhlbjogLS0+IHBpcnE9MTIg LT4gaXJxPTEyIChnc2k9MTIpClsgICAgMi4yMTQzMTVdIHBucCAwMDowNDogW2lycSAxMl0KWyAg ICAyLjIxNTExNV0gcG5wIDAwOjA0OiBQbHVnIGFuZCBQbGF5IEFDUEkgZGV2aWNlLCBJRHMgUE5Q MGYxMyAoYWN0aXZlKQpbICAgIDIuMjE1ODE5XSBwbnAgMDA6MDU6IFtpbyAgMHgwMDYwXQpbICAg IDIuMjE1ODUyXSBwbnAgMDA6MDU6IFtpbyAgMHgwMDY0XQpbICAgIDIuMjE1ODgxXSBwbnAgMDA6 MDU6IFtpbyAgMHgwMDYyXQoKWyAgICAyLjIxNTkxMF0gcG5wIDAwOjA1OiBbaW8gIDB4MDA2Nl0K WyAgICAyLjIxNTkyOF0geGVuOiByZWdpc3RlcmluZyBnc2kgMSB0cmlnZ2VyaW5nIDEgcG9sYXJp dHkgMApbICAgIDIuMjE1OTUyXSB4ZW5fbWFwX3BpcnFfZ3NpOiByZXR1cm5pbmcgaXJxIDEgZm9y IGdzaSAxClsgICAgMi4yMTU5NzNdIHhlbjogLS0+IHBpcnE9MSAtPiBpcnE9MSAoZ3NpPTEpClsg ICAgMi4yMTYwMTBdIHBucCAwMDowNTogW2lycSAxXQpbICAgIDIuMjE2ODI2XSBwbnAgMDA6MDU6 IFBsdWcgYW5kIFBsYXkgQUNQSSBkZXZpY2UsIElEcyBQTlAwMzAzIChhY3RpdmUpClsgICAgMi4y MTcwNTNdIHBucCAwMDowNjogW2lvICAweDAwNzAtMHgwMDcxXQpbICAgIDIuMjE3MDUzXSB4ZW46 IHJlZ2lzdGVyaW5nIGdzaSA4IHRyaWdnZXJpbmcgMSBwb2xhcml0eSAwClsgICAgMi4yMTc1NDBd IHhlbl9tYXBfcGlycV9nc2k6IHJldHVybmluZyBpcnEgOCBmb3IgZ3NpIDgKWyAgICAyLjIxNzU2 M10geGVuOiAtLT4gcGlycT04IC0+IGlycT04IChnc2k9OCkKWyAgICAyLjIxNzYwMF0gcG5wIDAw OjA2OiBbaXJxIDhdClsgICAgMi4yMTc2MzBdIHBucCAwMDowNjogW2lvICAweDAwNzItMHgwMDc3 XQpbICAgIDIuMjE4NDU0XSBwbnAgMDA6MDY6IFBsdWcgYW5kIFBsYXkgQUNQSSBkZXZpY2UsIElE cyBQTlAwYjAwIChhY3RpdmUpClsgICAgMi4yMTkyMzJdIHBucCAwMDowNzogW2lvICAweDAwNjFd ClsgICAgMi4yMTkyNjRdIHBucCAwMDowNzogW2lvICAweDAwNjNdClsgICAgMi4yMTkyOTRdIHBu cCAwMDowNzogW2lvICAweDAwNjVdClsgICAgMi4yMTkzMjRdIHBucCAwMDowNzogW2lvICAweDAw NjddClsgICAgMi4yMjAxMjFdIHBucCAwMDowNzogUGx1ZyBhbmQgUGxheSBBQ1BJIGRldmljZSwg SURzIFBOUDA4MDAgKGFjdGl2ZSkKWyAgICAyLjIyMDgyMF0gcG5wIDAwOjA4OiBbaW8gIDB4MGM4 MC0weDBjZmZdClsgICAgMi4yMjA4NTNdIHBucCAwMDowODogW2lvICAweDA5MTAtMHgwOTFmXQpb ICAgIDIuMjIwODgzXSBwbnAgMDA6MDg6IFtpbyAgMHgwOTIwLTB4MDkyZl0KWyAgICAyLjIyMDkx M10gcG5wIDAwOjA4OiBbaW8gIDB4MGNiMC0weDBjYmZdClsgICAgMi4yMjA5NDJdIHBucCAwMDow ODogW2lvICAweDA5MzAtMHgwOTdmXQpbICAgIDIuMjIyNTM1XSBzeXN0ZW0gMDA6MDg6IFtpbyAg MHgwYzgwLTB4MGNmZl0gY291bGQgbm90IGJlIHJlc2VydmVkClsgICAgMi4yMjI1OTVdIHN5c3Rl bSAwMDowODogW2lvICAweDA5MTAtMHgwOTFmXSBoYXMgYmVlbiByZXNlcnZlZApbICAgIDIuMjIy NjUzXSBzeXN0ZW0gMDA6MDg6IFtpbyAgMHgwOTIwLTB4MDkyZl0gaGFzIGJlZW4gcmVzZXJ2ZWQK WyAgICAyLjIyMjcxMF0gc3lzdGVtIDAwOjA4OiBbaW8gIDB4MGNiMC0weDBjYmZdIGhhcyBiZWVu IHJlc2VydmVkClsgICAgMi4yMjI3NjddIHN5c3RlbSAwMDowODogW2lvICAweDA5MzAtMHgwOTdm XSBoYXMgYmVlbiByZXNlcnZlZApbICAgIDIuMjIyODA2XSBzeXN0ZW0gMDA6MDg6IFBsdWcgYW5k IFBsYXkgQUNQSSBkZXZpY2UsIElEcyBQTlAwYzAxIChhY3RpdmUpClsgICAgMi4yMjMzODRdIHBu cCAwMDowOTogW2RtYSA0XQpbICAgIDIuMjIzMzg0XSBwbnAgMDA6MDk6IFtpbyAgMHgwMDAwLTB4 MDAwZl0KWyAgICAyLjIyMzM4NF0gcG5wIDAwOjA5OiBbaW8gIDB4MDA4MC0weDAwODVdClsgICAg Mi4yMjMzODRdIHBucCAwMDowOTogW2lvICAweDAwODctMHgwMDhmXQpbICAgIDIuMjIzMzg0XSBw bnAgMDA6MDk6IFtpbyAgMHgwMGMwLTB4MDBkZl0KWyAgICAyLjIyMzM4NF0gcG5wIDAwOjA5OiBb aW8gIDB4MDAxMC0weDAwMWZdClsgICAgMi4yMjMzODRdIHBucCAwMDowOTogW2lvICAweDAwOTAt MHgwMDkxXQpbICAgIDIuMjIzMzg0XSBwbnAgMDA6MDk6IFtpbyAgMHgwMDkzLTB4MDA5Zl0KWyAg ICAyLjIyNDYwMF0gcG5wIDAwOjA5OiBQbHVnIGFuZCBQbGF5IEFDUEkgZGV2aWNlLCBJRHMgUE5Q MDIwMCAoYWN0aXZlKQpbICAgIDIuMjI1MjQ4XSBwbnAgMDA6MGE6IFtpbyAgMHgwMGYwLTB4MDBm Zl0KWyAgICAyLjIyNTI2OF0geGVuOiByZWdpc3RlcmluZyBnc2kgMTMgdHJpZ2dlcmluZyAxIHBv bGFyaXR5IDAKWyAgICAyLjIyNTMyMF0geGVuX21hcF9waXJxX2dzaTogcmV0dXJuaW5nIGlycSAx MyBmb3IgZ3NpIDEzClsgICAgMi4yMjUzNDJdIHhlbjogLS0+IHBpcnE9MTMgLT4gaXJxPTEzIChn c2k9MTMpClsgICAgMi4yMjUzODBdIHBucCAwMDowYTogW2lycSAxM10KWyAgICAyLjIyNjIwNl0g cG5wIDAwOjBhOiBQbHVnIGFuZCBQbGF5IEFDUEkgZGV2aWNlLCBJRHMgUE5QMGMwNCAoYWN0aXZl KQpbICAgIDIuMjI2MzAzXSBwbnAgMDA6MGI6IFttZW0gMHhmZWQwMDAwMC0weGZlZDAwM2ZmXQpb ICAgIDIuMjMwMDM4XSBzeXN0ZW0gMDA6MGI6IFttZW0gMHhmZWQwMDAwMC0weGZlZDAwM2ZmXSBo YXMgYmVlbiByZXNlcnZlZApbICAgIDIuMjMwMDc5XSBzeXN0ZW0gMDA6MGI6IFBsdWcgYW5kIFBs YXkgQUNQSSBkZXZpY2UsIElEcyBQTlAwMTAzIFBOUDBjMDEgKGFjdGl2ZSkKWyAgICAyLjIzMDY2 OF0gcG5wOiBQblAgQUNQSTogZm91bmQgMTIgZGV2aWNlcwpbICAgIDIuMjMwNjY4XSBBQ1BJOiBB Q1BJIGJ1cyB0eXBlIHBucCB1bnJlZ2lzdGVyZWQKWyAgICAyLjIzMDY2OF0gY2FsbGluZyAgY2hy X2Rldl9pbml0KzB4MC8weGMxIEAgMQpbICAgIDIuMzEyMTc5XSBpbml0Y2FsbCBjaHJfZGV2X2lu aXQrMHgwLzB4YzEgcmV0dXJuZWQgMCBhZnRlciA2NDEzMiB1c2VjcwpbICAgIDIuMzEyMjE2XSBj YWxsaW5nICBmaXJtd2FyZV9jbGFzc19pbml0KzB4MC8weDE5IEAgMQpbICAgIDIuMzEyNDI4XSBp bml0Y2FsbCBmaXJtd2FyZV9jbGFzc19pbml0KzB4MC8weDE5IHJldHVybmVkIDAgYWZ0ZXIgMTgz IHVzZWNzClsgICAgMi4zMTI0NjJdIGNhbGxpbmcgIGluaXRfcGNtY2lhX2J1cysweDAvMHg2MiBA IDEKWyAgICAyLjMxMjg2Nl0gaW5pdGNhbGwgaW5pdF9wY21jaWFfYnVzKzB4MC8weDYyIHJldHVy bmVkIDAgYWZ0ZXIgMzcxIHVzZWNzClsgICAgMi4zMTI4OTVdIGNhbGxpbmcgIHRoZXJtYWxfaW5p dCsweDAvMHg4YiBAIDEKWyAgICAyLjMxMzIyN10gaW5pdGNhbGwgdGhlcm1hbF9pbml0KzB4MC8w eDhiIHJldHVybmVkIDAgYWZ0ZXIgMzAxIHVzZWNzClsgICAgMi4zMTMyNTZdIGNhbGxpbmcgIGNw dWZyZXFfZ292X3BlcmZvcm1hbmNlX2luaXQrMHgwLzB4MTIgQCAxClsgICAgMi4zMTMzMDldIGlu aXRjYWxsIGNwdWZyZXFfZ292X3BlcmZvcm1hbmNlX2luaXQrMHgwLzB4MTIgcmV0dXJuZWQgMCBh ZnRlciAyNCB1c2VjcwpbICAgIDIuMzEzMzQxXSBjYWxsaW5nICBjcHVmcmVxX2dvdl9kYnNfaW5p dCsweDAvMHg3YSBAIDEKWyAgICAyLjMxMzM2OF0gaW5pdGNhbGwgY3B1ZnJlcV9nb3ZfZGJzX2lu aXQrMHgwLzB4N2EgcmV0dXJuZWQgMCBhZnRlciAzIHVzZWNzClsgICAgMi4zMTMzOTVdIGNhbGxp bmcgIGluaXRfYWNwaV9wbV9jbG9ja3NvdXJjZSsweDAvMHhkYSBAIDEKWyAgICAyLjMyMDAxNF0g UE0tVGltZXIgZmFpbGVkIGNvbnNpc3RlbmN5IGNoZWNrICAoMHgweGZmZmZmZikgLSBhYm9ydGlu Zy4KWyAgICAyLjMyMDA0M10gaW5pdGNhbGwgaW5pdF9hY3BpX3BtX2Nsb2Nrc291cmNlKzB4MC8w eGRhIHJldHVybmVkIC0xOSBhZnRlciA2NDcwIHVzZWNzClsgICAgMi4zMjAwNjRdIGNhbGxpbmcg IHBjaWJpb3NfYXNzaWduX3Jlc291cmNlcysweDAvMHg3MSBAIDEKWyAgICAyLjMyMDA2NF0gUENJ OiBtYXggYnVzIGRlcHRoOiAxIHBjaV90cnlfbnVtOiAyClsgICAgMi4zMjAwNjRdIHBjaSAwMDAw OjAwOjFjLjA6IEJBUiAxNTogYXNzaWduZWQgW21lbSAweDgwMDAwMDAwLTB4ODAxZmZmZmYgNjRi aXQgcHJlZl0KWyAgICAyLjMyMDA2NF0gcGNpIDAwMDA6MDA6MWMuMDogQkFSIDEzOiBhc3NpZ25l ZCBbaW8gIDB4MjAwMC0weDJmZmZdClsgICAgMi4zMjAwNjRdIHBjaSAwMDAwOjAwOjFjLjA6IFBD SSBicmlkZ2UgdG8gW2J1cyAwYi0wYl0KWyAgICAyLjMyMDA2NF0gcGNpIDAwMDA6MDA6MWMuMDog ICBicmlkZ2Ugd2luZG93IFtpbyAgMHgyMDAwLTB4MmZmZl0KWyAgICAyLjMyMDA2NF0gcGNpIDAw MDA6MDA6MWMuMDogICBicmlkZ2Ugd2luZG93IFttZW0gMHhlZmQwMDAwMC0weGVmZGZmZmZmXQpb ICAgIDIuMzIwMDY0XSBwY2kgMDAwMDowMDoxYy4wOiAgIGJyaWRnZSB3aW5kb3cgW21lbSAweDgw MDAwMDAwLTB4ODAxZmZmZmYgNjRiaXQgcHJlZl0KWyAgICAyLjMyMDA2NF0gcGNpIDAwMDA6MDA6 MWMuMzogUENJIGJyaWRnZSB0byBbYnVzIDBjLTBkXQpbICAgIDIuMzIwMDY0XSBwY2kgMDAwMDow MDoxYy4zOiAgIGJyaWRnZSB3aW5kb3cgW2lvICAweGQwMDAtMHhkZmZmXQpbICAgIDIuMzIwMDY0 XSBwY2kgMDAwMDowMDoxYy4zOiAgIGJyaWRnZSB3aW5kb3cgW21lbSAweGVmYjAwMDAwLTB4ZWZj ZmZmZmZdClsgICAgMi4zMjAwNjRdIHBjaSAwMDAwOjAwOjFjLjM6ICAgYnJpZGdlIHdpbmRvdyBb bWVtIDB4ZTAwMDAwMDAtMHhlMDFmZmZmZiA2NGJpdCBwcmVmXQpbICAgIDIuMzIwMDY0XSBwY2kg MDAwMDowMDoxZS4wOiBQQ0kgYnJpZGdlIHRvIFtidXMgMDMtMDNdClsgICAgMi4zMjAwNjRdIHBj aSAwMDAwOjAwOjFlLjA6ICAgYnJpZGdlIHdpbmRvdyBbbWVtIDB4ZWZhMDAwMDAtMHhlZmFmZmZm Zl0KWyAgICAyLjMyMDA2NF0geGVuOiByZWdpc3RlcmluZyBnc2kgMTYgdHJpZ2dlcmluZyAwIHBv bGFyaXR5IDEKWyAgICAyLjMyMTU3Ml0geGVuOiAtLT4gcGlycT0xNiAtPiBpcnE9MTYgKGdzaT0x NikKWyAgICAyLjMyMTYwMV0gcGNpIDAwMDA6MDA6MWMuMDogUENJIElOVCBBIC0+IEdTSSAxNiAo bGV2ZWwsIGxvdykgLT4gSVJRIDE2ClsgICAgMi4zMjE2NDNdIHBjaSAwMDAwOjAwOjFjLjA6IHNl dHRpbmcgbGF0ZW5jeSB0aW1lciB0byA2NApbICAgIDIuMzIxNjk3XSB4ZW46IHJlZ2lzdGVyaW5n IGdzaSAxOSB0cmlnZ2VyaW5nIDAgcG9sYXJpdHkgMQpbICAgIDIuMzIxNzc3XSB4ZW46IC0tPiBw aXJxPTE5IC0+IGlycT0xOSAoZ3NpPTE5KQpbICAgIDIuMzIxODA0XSBwY2kgMDAwMDowMDoxYy4z OiBQQ0kgSU5UIEQgLT4gR1NJIDE5IChsZXZlbCwgbG93KSAtPiBJUlEgMTkKWyAgICAyLjMyMTg0 M10gcGNpIDAwMDA6MDA6MWMuMzogc2V0dGluZyBsYXRlbmN5IHRpbWVyIHRvIDY0ClsgICAgMi4z MjE5MDBdIHBjaSAwMDAwOjAwOjFlLjA6IHNldHRpbmcgbGF0ZW5jeSB0aW1lciB0byA2NApbICAg IDIuMzIxOTMwXSBwY2lfYnVzIDAwMDA6MDA6IHJlc291cmNlIDAgW2lvICAweDAwMDAtMHhmZmZm XQpbICAgIDIuMzIxOTUyXSBwY2lfYnVzIDAwMDA6MDA6IHJlc291cmNlIDEgW21lbSAweDAwMDAw MDAwLTB4ZmZmZmZmZmZmXQpbICAgIDIuMzIxOTc3XSBwY2lfYnVzIDAwMDA6MGI6IHJlc291cmNl IDAgW2lvICAweDIwMDAtMHgyZmZmXQpbICAgIDIuMzIxOTk5XSBwY2lfYnVzIDAwMDA6MGI6IHJl c291cmNlIDEgW21lbSAweGVmZDAwMDAwLTB4ZWZkZmZmZmZdClsgICAgMi4zMjIwMjRdIHBjaV9i dXMgMDAwMDowYjogcmVzb3VyY2UgMiBbbWVtIDB4ODAwMDAwMDAtMHg4MDFmZmZmZiA2NGJpdCBw cmVmXQpbICAgIDIuMzIyMDU1XSBwY2lfYnVzIDAwMDA6MGM6IHJlc291cmNlIDAgW2lvICAweGQw MDAtMHhkZmZmXQpbICAgIDIuMzIyMDc3XSBwY2lfYnVzIDAwMDA6MGM6IHJlc291cmNlIDEgW21l bSAweGVmYjAwMDAwLTB4ZWZjZmZmZmZdClsgICAgMi4zMjIxMDJdIHBjaV9idXMgMDAwMDowYzog cmVzb3VyY2UgMiBbbWVtIDB4ZTAwMDAwMDAtMHhlMDFmZmZmZiA2NGJpdCBwcmVmXQpbICAgIDIu MzIyMTMxXSBwY2lfYnVzIDAwMDA6MDM6IHJlc291cmNlIDEgW21lbSAweGVmYTAwMDAwLTB4ZWZh ZmZmZmZdClsgICAgMi4zMjIxNTZdIHBjaV9idXMgMDAwMDowMzogcmVzb3VyY2UgNCBbaW8gIDB4 MDAwMC0weGZmZmZdClsgICAgMi4zMjIxNzddIHBjaV9idXMgMDAwMDowMzogcmVzb3VyY2UgNSBb bWVtIDB4MDAwMDAwMDAtMHhmZmZmZmZmZmZdClsgICAgMi4zMjIyMTFdIGluaXRjYWxsIHBjaWJp b3NfYXNzaWduX3Jlc291cmNlcysweDAvMHg3MSByZXR1cm5lZCAwIGFmdGVyIDIwNTcgdXNlY3MK WyAgICAyLjMyMjI0Ml0gY2FsbGluZyAgc3lzY3RsX2NvcmVfaW5pdCsweDAvMHgzOCBAIDEKWyAg ICAyLjMyMjU1NV0gY2FsbGluZyAgaW5ldF9pbml0KzB4MC8weDI3ZCBAIDEKWyAgICAyLjMyMjg4 NV0gTkVUOiBSZWdpc3RlcmVkIHByb3RvY29sIGZhbWlseSAyClsgICAgMi4zMjg0NDVdIElQIHJv dXRlIGNhY2hlIGhhc2ggdGFibGUgZW50cmllczogNTI0Mjg4IChvcmRlcjogMTAsIDQxOTQzMDQg Ynl0ZXMpClsgICAgMi4zNDMzNDZdIFRDUCBlc3RhYmxpc2hlZCBoYXNoIHRhYmxlIGVudHJpZXM6 IDUyNDI4OCAob3JkZXI6IDExLCA4Mzg4NjA4IGJ5dGVzKQpbICAgIDIuMzU1NzUzXSBUQ1AgYmlu ZCBoYXNoIHRhYmxlIGVudHJpZXM6IDY1NTM2IChvcmRlcjogMTAsIDUyNDI4ODAgYnl0ZXMpClsg ICAgMi4zNzEwMjBdIFRDUDogSGFzaCB0YWJsZXMgY29uZmlndXJlZCAoZXN0YWJsaXNoZWQgNTI0 Mjg4IGJpbmQgNjU1MzYpClsgICAgMi4zNzEwNjRdIFRDUCByZW5vIHJlZ2lzdGVyZWQKWyAgICAy LjM3NDU4MV0gVURQIGhhc2ggdGFibGUgZW50cmllczogMTYzODQgKG9yZGVyOiA5LCAzMTQ1NzI4 IGJ5dGVzKQpbICAgIDIuMzg3NjMxXSBVRFAtTGl0ZSBoYXNoIHRhYmxlIGVudHJpZXM6IDE2Mzg0 IChvcmRlcjogOSwgMzE0NTcyOCBieXRlcykKWyAgICAyLjM5ODU2MF0gaW5pdGNhbGwgaW5ldF9p bml0KzB4MC8weDI3ZCByZXR1cm5lZCAwIGFmdGVyIDc0MTg2IHVzZWNzClsgICAgMi4zOTg2MDhd IGNhbGxpbmcgIGFmX3VuaXhfaW5pdCsweDAvMHg1MiBAIDEKWyAgICAyLjM5ODY5MV0gTkVUOiBS ZWdpc3RlcmVkIHByb3RvY29sIGZhbWlseSAxClsgICAgMi4zOTg4NzJdIGluaXRjYWxsIGFmX3Vu aXhfaW5pdCsweDAvMHg1MiByZXR1cm5lZCAwIGFmdGVyIDIzNCB1c2VjcwpbICAgIDIuMzk4OTAx XSBjYWxsaW5nICBwY2lfYXBwbHlfZmluYWxfcXVpcmtzKzB4MC8weGYyIEAgMQpbICAgIDIuMzk5 MDE2XSBwY2kgMDAwMDowMDowMi4wOiBCb290IHZpZGVvIGRldmljZQpbICAgIDIuNDAwMTI2XSBQ Q0k6IENMUyA2NCBieXRlcywgZGVmYXVsdCA2NApbICAgIDIuNDAwMTQ4XSBpbml0Y2FsbCBwY2lf YXBwbHlfZmluYWxfcXVpcmtzKzB4MC8weGYyIHJldHVybmVkIDAgYWZ0ZXIgMTE5NCB1c2Vjcwpb ICAgIDIuNDAwMjU0XSBjYWxsaW5nICBwb3B1bGF0ZV9yb290ZnMrMHgwLzB4MTA1IEAgMQpbICAg IDIuNDAxNzkxXSBVbnBhY2tpbmcgaW5pdHJhbWZzLi4uClsgICAgMy4zNTAwNjJdIEZyZWVpbmcg aW5pdHJkIG1lbW9yeTogNDEyMjBrIGZyZWVkClsgICAgMy40MDg1MjhdIGluaXRjYWxsIHBvcHVs YXRlX3Jvb3RmcysweDAvMHgxMDUgcmV0dXJuZWQgMCBhZnRlciA5ODQ2MDMgdXNlY3MKWyAgICAz LjQwODU4Ml0gY2FsbGluZyAgcGNpX2lvbW11X2luaXQrMHgwLzB4NTQgQCAxClsgICAgMy43MzE0 NzVdIERNQS1BUEk6IHByZWFsbG9jYXRlZCAzMjc2OCBkZWJ1ZyBlbnRyaWVzClsgICAgMy43MzE1 NjldIERNQS1BUEk6IGRlYnVnZ2luZyBlbmFibGVkIGJ5IGtlcm5lbCBjb25maWcKWyAgICAzLjcz MTYxNl0gaW5pdGNhbGwgcGNpX2lvbW11X2luaXQrMHgwLzB4NTQgcmV0dXJuZWQgMCBhZnRlciAz MTU0MzUgdXNlY3MKWyAgICAzLjczMTY0Nl0gY2FsbGluZyAgY2FsZ2FyeV9maXh1cF90Y2Vfc3Bh Y2VzKzB4MC8weGYwIEAgMQpbICAgIDMuNzMxNjY5XSBpbml0Y2FsbCBjYWxnYXJ5X2ZpeHVwX3Rj ZV9zcGFjZXMrMHgwLzB4ZjAgcmV0dXJuZWQgLTE5IGFmdGVyIDAgdXNlY3MKWyAgICAzLjczMTY5 OV0gY2FsbGluZyAgaTgyNTlBX2luaXRfb3BzKzB4MC8weDIxIEAgMQpbICAgIDMuNzMxNzI4XSBp bml0Y2FsbCBpODI1OUFfaW5pdF9vcHMrMHgwLzB4MjEgcmV0dXJuZWQgMCBhZnRlciA2IHVzZWNz ClsgICAgMy43MzE3NTNdIGNhbGxpbmcgIHZzeXNjYWxsX2luaXQrMHgwLzB4MjcgQCAxClsgICAg My43MzE4MjNdIGluaXRjYWxsIHZzeXNjYWxsX2luaXQrMHgwLzB4MjcgcmV0dXJuZWQgMCBhZnRl ciA0NiB1c2VjcwpbICAgIDMuNzMxODUwXSBjYWxsaW5nICBzYmZfaW5pdCsweDAvMHhlNyBAIDEK WyAgICAzLjczMTg4M10gU2ltcGxlIEJvb3QgRmxhZyBhdCAweDc5IHNldCB0byAweDgwClsgICAg My43MzE5MTJdIGluaXRjYWxsIHNiZl9pbml0KzB4MC8weGU3IHJldHVybmVkIDAgYWZ0ZXIgNDIg dXNlY3MKWyAgICAzLjczMTkzOF0gY2FsbGluZyAgaW5pdF90c2NfY2xvY2tzb3VyY2UrMHgwLzB4 NWYgQCAxClsgICAgMy43MzE5OThdIGluaXRjYWxsIGluaXRfdHNjX2Nsb2Nrc291cmNlKzB4MC8w eDVmIHJldHVybmVkIDAgYWZ0ZXIgMzYgdXNlY3MKWyAgICAzLjczMjAyOF0gY2FsbGluZyAgYWRk X3J0Y19jbW9zKzB4MC8weDk3IEAgMQpbICAgIDMuNzMyMDk4XSBpbml0Y2FsbCBhZGRfcnRjX2Nt b3MrMHgwLzB4OTcgcmV0dXJuZWQgMCBhZnRlciA0NiB1c2VjcwpbICAgIDMuNzMyMTI2XSBjYWxs aW5nICBpODIzN0FfaW5pdF9vcHMrMHgwLzB4MTQgQCAxClsgICAgMy43MzIzNTJdIGluaXRjYWxs IGk4MjM3QV9pbml0X29wcysweDAvMHgxNCByZXR1cm5lZCAwIGFmdGVyIDE5NyB1c2VjcwpbICAg IDMuNzMyMzgzXSBjYWxsaW5nICBjYWNoZV9zeXNmc19pbml0KzB4MC8weDY0IEAgMQpbICAgIDMu NzM0NjEzXSBpbml0Y2FsbCBjYWNoZV9zeXNmc19pbml0KzB4MC8weDY0IHJldHVybmVkIDAgYWZ0 ZXIgMjE1NSB1c2VjcwpbICAgIDMuNzM0NjQyXSBjYWxsaW5nICBtY2hlY2tfaW5pdF9kZXZpY2Ur MHgwLzB4MTBlIEAgMQpbICAgIDMuNzM0NjY1XSBpbml0Y2FsbCBtY2hlY2tfaW5pdF9kZXZpY2Ur MHgwLzB4MTBlIHJldHVybmVkIC01IGFmdGVyIDAgdXNlY3MKWyAgICAzLjczNDY5Ml0gaW5pdGNh bGwgbWNoZWNrX2luaXRfZGV2aWNlKzB4MC8weDEwZSByZXR1cm5lZCB3aXRoIGVycm9yIGNvZGUg LTUgClsgICAgMy43MzQ3MjJdIGNhbGxpbmcgIHRocmVzaG9sZF9pbml0X2RldmljZSsweDAvMHg0 ZiBAIDEKWyAgICAzLjczNDc0NV0gaW5pdGNhbGwgdGhyZXNob2xkX2luaXRfZGV2aWNlKzB4MC8w eDRmIHJldHVybmVkIDAgYWZ0ZXIgMSB1c2VjcwpbICAgIDMuNzM0Nzc1XSBjYWxsaW5nICB0aGVy bWFsX3Rocm90dGxlX2luaXRfZGV2aWNlKzB4MC8weDljIEAgMQpbICAgIDMuNzM0ODAyXSBpbml0 Y2FsbCB0aGVybWFsX3Rocm90dGxlX2luaXRfZGV2aWNlKzB4MC8weDljIHJldHVybmVkIDAgYWZ0 ZXIgMCB1c2VjcwpbICAgIDMuNzM0ODMyXSBjYWxsaW5nICBtc3JfaW5pdCsweDAvMHgxMWQgQCAx ClsgICAgMy43Mzc5OTFdIGluaXRjYWxsIG1zcl9pbml0KzB4MC8weDExZCByZXR1cm5lZCAwIGFm dGVyIDMwNjUgdXNlY3MKWyAgICAzLjczODAyMV0gY2FsbGluZyAgY3B1aWRfaW5pdCsweDAvMHgx MWQgQCAxClsgICAgMy43Mzk5NDddIGluaXRjYWxsIGNwdWlkX2luaXQrMHgwLzB4MTFkIHJldHVy bmVkIDAgYWZ0ZXIgMTg1NyB1c2VjcwpbICAgIDMuNzQwMDAzXSBpbml0Y2FsbCBpb2FwaWNfaW5p dF9vcHMrMHgwLzB4MTQgcmV0dXJuZWQgMCBhZnRlciAzIHVzZWNzClsgICAgMy43NDAwMjldIGNh bGxpbmcgIGFkZF9wY3Nwa3IrMHgwLzB4MzggQCAxClsgICAgMy43NDA1NzJdIGluaXRjYWxsIGFk ZF9wY3Nwa3IrMHgwLzB4MzggcmV0dXJuZWQgMCBhZnRlciA1MDcgdXNlY3MKWyAgICAzLjc0MDYw MF0gY2FsbGluZyAgYXVkaXRfY2xhc3Nlc19pbml0KzB4MC8weGFmIEAgMQpbICAgIDMuNzQwNzI3 XSBpbml0Y2FsbCBhdWRpdF9jbGFzc2VzX2luaXQrMHgwLzB4YWYgcmV0dXJuZWQgMCBhZnRlciAx MDEgdXNlY3MKWyAgICAzLjc0MDc1Nl0gY2FsbGluZyAgcHRfZHVtcF9pbml0KzB4MC8weDMwIEAg MQpbICAgIDMuNzQwODU2XSBpbml0Y2FsbCBwdF9kdW1wX2luaXQrMHgwLzB4MzAgcmV0dXJuZWQg MCBhZnRlciA3NSB1c2VjcwpbICAgIDMuNzQwODg0XSBjYWxsaW5nICBhZXNfaW5pdCsweDAvMHgx MiBAIDEKWyAgICAzLjc0MTYwNV0gaW5pdGNhbGwgYWVzX2luaXQrMHgwLzB4MTIgcmV0dXJuZWQg MCBhZnRlciA2ODUgdXNlY3MKWyAgICAzLjc0MTYxMl0gY3J5cHRvbWdyX3Rlc3QgdXNlZCBncmVh dGVzdCBzdGFjayBkZXB0aDogNjA4OCBieXRlcyBsZWZ0ClsgICAgMy43NDE2NTVdIGNhbGxpbmcg IGFlc25pX2luaXQrMHgwLzB4MjAxIEAgMQpbICAgIDMuNzQxNjc1XSBJbnRlbCBBRVMtTkkgaW5z dHJ1Y3Rpb25zIGFyZSBub3QgZGV0ZWN0ZWQuClsgICAgMy43NDE2OThdIGluaXRjYWxsIGFlc25p X2luaXQrMHgwLzB4MjAxIHJldHVybmVkIC0xOSBhZnRlciAyMCB1c2VjcwpbICAgIDMuNzQxNzI0 XSBjYWxsaW5nICBpYTMyX2JpbmZtdF9pbml0KzB4MC8weDE0IEAgMQpbICAgIDMuNzQxODExXSBp bml0Y2FsbCBpYTMyX2JpbmZtdF9pbml0KzB4MC8weDE0IHJldHVybmVkIDAgYWZ0ZXIgNjIgdXNl Y3MKWyAgICAzLjc0MTgzOV0gY2FsbGluZyAgaW5pdF9zY2hlZF9kZWJ1Z19wcm9jZnMrMHgwLzB4 MmMgQCAxClsgICAgMy43NDE5MTJdIGluaXRjYWxsIGluaXRfc2NoZWRfZGVidWdfcHJvY2ZzKzB4 MC8weDJjIHJldHVybmVkIDAgYWZ0ZXIgNDggdXNlY3MKWyAgICAzLjc0MTk0M10gY2FsbGluZyAg cHJvY19zY2hlZHN0YXRfaW5pdCsweDAvMHgyMiBAIDEKWyAgICAzLjc0MjAwN10gaW5pdGNhbGwg cHJvY19zY2hlZHN0YXRfaW5pdCsweDAvMHgyMiByZXR1cm5lZCAwIGFmdGVyIDQwIHVzZWNzClsg ICAgMy43NDIwMzVdIGNhbGxpbmcgIHByb2NfZXhlY2RvbWFpbnNfaW5pdCsweDAvMHgyMiBAIDEK WyAgICAzLjc0MjEwMF0gaW5pdGNhbGwgcHJvY19leGVjZG9tYWluc19pbml0KzB4MC8weDIyIHJl dHVybmVkIDAgYWZ0ZXIgNDAgdXNlY3MKWyAgICAzLjc0MjEzMV0gY2FsbGluZyAgaW9yZXNvdXJj ZXNfaW5pdCsweDAvMHgzYyBAIDEKWyAgICAzLjc0MjIyN10gaW5pdGNhbGwgaW9yZXNvdXJjZXNf aW5pdCsweDAvMHgzYyByZXR1cm5lZCAwIGFmdGVyIDcyIHVzZWNzClsgICAgMy43NDIyNTNdIGNh bGxpbmcgIHVpZF9jYWNoZV9pbml0KzB4MC8weDhjIEAgMQpbICAgIDMuNzQyNDQyXSBpbml0Y2Fs bCB1aWRfY2FjaGVfaW5pdCsweDAvMHg4YyByZXR1cm5lZCAwIGFmdGVyIDE2MiB1c2VjcwpbICAg IDMuNzQyNDcxXSBjYWxsaW5nICBpbml0X3Bvc2l4X3RpbWVycysweDAvMHgxYzMgQCAxClsgICAg My43NDI1NDZdIGluaXRjYWxsIGluaXRfcG9zaXhfdGltZXJzKzB4MC8weDFjMyByZXR1cm5lZCAw IGFmdGVyIDUwIHVzZWNzClsgICAgMy43NDI1NzNdIGNhbGxpbmcgIGluaXRfcG9zaXhfY3B1X3Rp bWVycysweDAvMHhjMiBAIDEKWyAgICAzLjc0MjU5Nl0gaW5pdGNhbGwgaW5pdF9wb3NpeF9jcHVf dGltZXJzKzB4MC8weGMyIHJldHVybmVkIDAgYWZ0ZXIgMCB1c2VjcwpbICAgIDMuNzQyNjI3XSBj YWxsaW5nICBjcmVhdGVfcHJvY19wcm9maWxlKzB4MC8weDIzYiBAIDEKWyAgICAzLjc0MjY1MF0g aW5pdGNhbGwgY3JlYXRlX3Byb2NfcHJvZmlsZSsweDAvMHgyM2IgcmV0dXJuZWQgMCBhZnRlciAw IHVzZWNzClsgICAgMy43NDI2NzZdIGNhbGxpbmcgIHRpbWVrZWVwaW5nX2luaXRfb3BzKzB4MC8w eDE0IEAgMQpbICAgIDMuNzQyNzQ3XSBpbml0Y2FsbCB0aW1la2VlcGluZ19pbml0X29wcysweDAv MHgxNCByZXR1cm5lZCAwIGFmdGVyIDMgdXNlY3MKWyAgICAzLjc0Mjc3M10gY2FsbGluZyAgaW5p dF9jbG9ja3NvdXJjZV9zeXNmcysweDAvMHg1MCBAIDEKWyAgICAzLjc0MzExNF0gaW5pdGNhbGwg aW5pdF9jbG9ja3NvdXJjZV9zeXNmcysweDAvMHg1MCByZXR1cm5lZCAwIGFmdGVyIDMxMCB1c2Vj cwpbICAgIDMuNzQzMTQ3XSBjYWxsaW5nICBpbml0X3RpbWVyX2xpc3RfcHJvY2ZzKzB4MC8weDJj IEAgMQpbICAgIDMuNzQzMjEwXSBpbml0Y2FsbCBpbml0X3RpbWVyX2xpc3RfcHJvY2ZzKzB4MC8w eDJjIHJldHVybmVkIDAgYWZ0ZXIgMzggdXNlY3MKWyAgICAzLjc0MzI0MV0gY2FsbGluZyAgYWxh cm10aW1lcl9pbml0KzB4MC8weDE0MyBAIDEKWyAgICAzLjc0NDA5Ml0gaW5pdGNhbGwgYWxhcm10 aW1lcl9pbml0KzB4MC8weDE0MyByZXR1cm5lZCAwIGFmdGVyIDgwOCB1c2VjcwpbICAgIDMuNzQ0 MTY1XSBjYWxsaW5nICBpbml0X3RzdGF0c19wcm9jZnMrMHgwLzB4MmMgQCAxClsgICAgMy43NDQy MjldIGluaXRjYWxsIGluaXRfdHN0YXRzX3Byb2NmcysweDAvMHgyYyByZXR1cm5lZCAwIGFmdGVy IDM5IHVzZWNzClsgICAgMy43NDQyNTZdIGNhbGxpbmcgIGxvY2tkZXBfcHJvY19pbml0KzB4MC8w eDdjIEAgMQpbICAgIDMuNzQ0Mjg2XSBpbml0Y2FsbCBsb2NrZGVwX3Byb2NfaW5pdCsweDAvMHg3 YyByZXR1cm5lZCAwIGFmdGVyIDE0MyB1c2VjcwpbICAgIDMuNzQ0Mjg2XSBjYWxsaW5nICBmdXRl eF9pbml0KzB4MC8weDZmIEAgMQpbICAgIDMuNzQ0NTgwXSBpbml0Y2FsbCBmdXRleF9pbml0KzB4 MC8weDZmIHJldHVybmVkIDAgYWZ0ZXIgMTAyIHVzZWNzClsgICAgMy43NDQ2MDhdIGNhbGxpbmcg IHByb2NfZG1hX2luaXQrMHgwLzB4MjIgQCAxClsgICAgMy43NDQ2NzNdIGluaXRjYWxsIHByb2Nf ZG1hX2luaXQrMHgwLzB4MjIgcmV0dXJuZWQgMCBhZnRlciA0MSB1c2VjcwpbICAgIDMuNzQ0NzAx XSBjYWxsaW5nICBwcm9jX21vZHVsZXNfaW5pdCsweDAvMHgyMiBAIDEKWyAgICAzLjc0NDc2NV0g aW5pdGNhbGwgcHJvY19tb2R1bGVzX2luaXQrMHgwLzB4MjIgcmV0dXJuZWQgMCBhZnRlciA0MSB1 c2VjcwpbICAgIDMuNzQ0NzkyXSBjYWxsaW5nICBrYWxsc3ltc19pbml0KzB4MC8weDI1IEAgMQpb ICAgIDMuNzQ0ODU2XSBpbml0Y2FsbCBrYWxsc3ltc19pbml0KzB4MC8weDI1IHJldHVybmVkIDAg YWZ0ZXIgNDAgdXNlY3MKWyAgICAzLjc0NDg4M10gY2FsbGluZyAgc25hcHNob3RfZGV2aWNlX2lu aXQrMHgwLzB4MTIgQCAxClsgICAgMy43NDU2ODBdIGluaXRjYWxsIHNuYXBzaG90X2RldmljZV9p bml0KzB4MC8weDEyIHJldHVybmVkIDAgYWZ0ZXIgNzU0IHVzZWNzClsgICAgMy43NDU3MTNdIGNh bGxpbmcgIGNyYXNoX3NhdmVfdm1jb3JlaW5mb19pbml0KzB4MC8weDQ2ZCBAIDEKWyAgICAzLjc0 NTc2N10gaW5pdGNhbGwgY3Jhc2hfc2F2ZV92bWNvcmVpbmZvX2luaXQrMHgwLzB4NDZkIHJldHVy bmVkIDAgYWZ0ZXIgMjYgdXNlY3MKWyAgICAzLjc0NTgyOF0gaW5pdGNhbGwgY3Jhc2hfbm90ZXNf bWVtb3J5X2luaXQrMHgwLzB4MzYgcmV0dXJuZWQgMCBhZnRlciA3IHVzZWNzClsgICAgMy43NDU4 NTldIGNhbGxpbmcgIHVzZXJfbmFtZXNwYWNlc19pbml0KzB4MC8weDJkIEAgMQpbICAgIDMuNzQ1 OTI2XSBpbml0Y2FsbCB1c2VyX25hbWVzcGFjZXNfaW5pdCsweDAvMHgyZCByZXR1cm5lZCAwIGFm dGVyIDQyIHVzZWNzClsgICAgMy43NDU5NThdIGNhbGxpbmcgIHBpZF9uYW1lc3BhY2VzX2luaXQr MHgwLzB4MmQgQCAxClsgICAgMy43NDYwMjNdIGluaXRjYWxsIHBpZF9uYW1lc3BhY2VzX2luaXQr MHgwLzB4MmQgcmV0dXJuZWQgMCBhZnRlciA0MCB1c2VjcwpbICAgIDMuNzQ2MDUyXSBjYWxsaW5n ICB1dHJhY2VfaW5pdCsweDAvMHg1MiBAIDEKWyAgICAzLjc0NjI1Ml0gaW5pdGNhbGwgdXRyYWNl X2luaXQrMHgwLzB4NTIgcmV0dXJuZWQgMCBhZnRlciAxNzEgdXNlY3MKWyAgICAzLjc0NjI4MF0g Y2FsbGluZyAgYXVkaXRfaW5pdCsweDAvMHgxNjAgQCAxClsgICAgMy43NDYzMDFdIGF1ZGl0OiBp bml0aWFsaXppbmcgbmV0bGluayBzb2NrZXQgKGRpc2FibGVkKQpbICAgIDMuNzQ2NTIwXSB0eXBl PTIwMDAgYXVkaXQoMTMxNTk1NTE0My43OTI6MSk6IGluaXRpYWxpemVkClsgICAgMy43NDY1NzJd IGluaXRjYWxsIGF1ZGl0X2luaXQrMHgwLzB4MTYwIHJldHVybmVkIDAgYWZ0ZXIgMjYyIHVzZWNz ClsgICAgMy43NDY1OTldIGNhbGxpbmcgIGF1ZGl0X3dhdGNoX2luaXQrMHgwLzB4M2EgQCAxClsg ICAgMy43NDY2MzRdIGluaXRjYWxsIGF1ZGl0X3dhdGNoX2luaXQrMHgwLzB4M2EgcmV0dXJuZWQg MCBhZnRlciAxMSB1c2VjcwpbICAgIDMuNzQ2NjYwXSBjYWxsaW5nICBhdWRpdF90cmVlX2luaXQr MHgwLzB4NTggQCAxClsgICAgMy43NDY2OTVdIGluaXRjYWxsIGF1ZGl0X3RyZWVfaW5pdCsweDAv MHg1OCByZXR1cm5lZCAwIGFmdGVyIDEyIHVzZWNzClsgICAgMy43NDY3MjJdIGNhbGxpbmcgIGlu aXRfa3Byb2JlcysweDAvMHgxOTUgQCAxClsgICAgMy43ODcyMDNdIGluaXRjYWxsIGluaXRfa3By b2JlcysweDAvMHgxOTUgcmV0dXJuZWQgMCBhZnRlciAzOTUwOSB1c2VjcwpbICAgIDMuNzg3MjMz XSBjYWxsaW5nICBodW5nX3Rhc2tfaW5pdCsweDAvMHg1MyBAIDEKWyAgICAzLjc4NzU3Ml0gaW5p dGNhbGwgaHVuZ190YXNrX2luaXQrMHgwLzB4NTMgcmV0dXJuZWQgMCBhZnRlciAzMDggdXNlY3MK WyAgICAzLjc4NzYwMF0gY2FsbGluZyAgdXRzbmFtZV9zeXNjdGxfaW5pdCsweDAvMHgxNCBAIDEK WyAgICAzLjc4NzgzN10gaW5pdGNhbGwgdXRzbmFtZV9zeXNjdGxfaW5pdCsweDAvMHgxNCByZXR1 cm5lZCAwIGFmdGVyIDIwOCB1c2VjcwpbICAgIDMuNzg3ODY5XSBjYWxsaW5nICBpbml0X3RyYWNl cG9pbnRzKzB4MC8weDE3IEAgMQpbICAgIDMuNzg3ODkxXSBpbml0Y2FsbCBpbml0X3RyYWNlcG9p bnRzKzB4MC8weDE3IHJldHVybmVkIDAgYWZ0ZXIgMCB1c2VjcwpbICAgIDMuNzg3OTYxXSBjYWxs aW5nICBpbml0X2xzdGF0c19wcm9jZnMrMHgwLzB4MjUgQCAxClsgICAgMy43ODgwMzJdIGluaXRj YWxsIGluaXRfbHN0YXRzX3Byb2NmcysweDAvMHgyNSByZXR1cm5lZCAwIGFmdGVyIDQ3IHVzZWNz ClsgICAgMy43ODgwNjFdIGNhbGxpbmcgIGZ0cmFjZV9tb2RfY21kX2luaXQrMHgwLzB4MTIgQCAx ClsgICAgMy43ODgxMjBdIGluaXRjYWxsIGZ0cmFjZV9tb2RfY21kX2luaXQrMHgwLzB4MTIgcmV0 dXJuZWQgMCBhZnRlciAzNSB1c2VjcwpbICAgIDMuNzg4MTQ4XSBjYWxsaW5nICBpbml0X2V2ZW50 cysweDAvMHg2MCBAIDEKWyAgICAzLjc4ODE4OF0gaW5pdGNhbGwgaW5pdF9ldmVudHMrMHgwLzB4 NjAgcmV0dXJuZWQgMCBhZnRlciAxOCB1c2VjcwpbICAgIDMuNzg4MjE0XSBjYWxsaW5nICBpbml0 X2Z1bmN0aW9uX3RyYWNlKzB4MC8weDNlIEAgMQpbICAgIDMuNzg4MjQ1XSBpbml0Y2FsbCBpbml0 X2Z1bmN0aW9uX3RyYWNlKzB4MC8weDNlIHJldHVybmVkIDAgYWZ0ZXIgOCB1c2VjcwpbICAgIDMu Nzg4MjcyXSBjYWxsaW5nICBpbml0X3dha2V1cF90cmFjZXIrMHgwLzB4MjIgQCAxClsgICAgMy43 ODgyOTldIGluaXRjYWxsIGluaXRfd2FrZXVwX3RyYWNlcisweDAvMHgyMiByZXR1cm5lZCAwIGFm dGVyIDQgdXNlY3MKWyAgICAzLjc4ODMyNF0gY2FsbGluZyAgc3RhY2tfdHJhY2VfaW5pdCsweDAv MHg2OCBAIDEKWyAgICAzLjc4ODQ3Nl0gaW5pdGNhbGwgc3RhY2tfdHJhY2VfaW5pdCsweDAvMHg2 OCByZXR1cm5lZCAwIGFmdGVyIDEyNSB1c2VjcwpbICAgIDMuNzg4NTAzXSBjYWxsaW5nICBpbml0 X21taW9fdHJhY2UrMHgwLzB4MTIgQCAxClsgICAgMy43ODg1MjFdIGluaXRjYWxsIGluaXRfbW1p b190cmFjZSsweDAvMHgxMiByZXR1cm5lZCAwIGFmdGVyIDMgdXNlY3MKWyAgICAzLjc4ODUyMV0g Y2FsbGluZyAgaW5pdF9ncmFwaF90cmFjZSsweDAvMHg2NSBAIDEKWyAgICAzLjc4ODUyMV0gaW5p dGNhbGwgaW5pdF9ncmFwaF90cmFjZSsweDAvMHg2NSByZXR1cm5lZCAwIGFmdGVyIDcgdXNlY3MK WyAgICAzLjc4ODUyMV0gY2FsbGluZyAgaW5pdF9ibGtfdHJhY2VyKzB4MC8weDU3IEAgMQpbICAg IDMuNzg4NTIxXSBpbml0Y2FsbCBpbml0X2Jsa190cmFjZXIrMHgwLzB4NTcgcmV0dXJuZWQgMCBh ZnRlciA0IHVzZWNzClsgICAgMy43ODg1MjFdIGNhbGxpbmcgIHBlcmZfZXZlbnRfc3lzZnNfaW5p dCsweDAvMHg5NSBAIDEKWyAgICAzLjc5MDY0MF0gaW5pdGNhbGwgcGVyZl9ldmVudF9zeXNmc19p bml0KzB4MC8weDk1IHJldHVybmVkIDAgYWZ0ZXIgMTkwOCB1c2VjcwpbICAgIDMuNzkwNjc1XSBj YWxsaW5nICBpbml0X3Blcl96b25lX3dtYXJrX21pbisweDAvMHg4MyBAIDEKWyAgICAzLjc5MTI3 OF0gaW5pdGNhbGwgaW5pdF9wZXJfem9uZV93bWFya19taW4rMHgwLzB4ODMgcmV0dXJuZWQgMCBh ZnRlciA2MTQwIHVzZWNzClsgICAgMy43OTEyNzhdIGNhbGxpbmcgIGtzd2FwZF9pbml0KzB4MC8w eDdjIEAgMQpbICAgIDMuNzk3NTk5XSBpbml0Y2FsbCBrc3dhcGRfaW5pdCsweDAvMHg3YyByZXR1 cm5lZCAwIGFmdGVyIDUyNSB1c2VjcwpbICAgIDMuNzk3NjI5XSBjYWxsaW5nICBleHRmcmFnX2Rl YnVnX2luaXQrMHgwLzB4NzcgQCAxClsgICAgMy43OTc5MzNdIGluaXRjYWxsIGV4dGZyYWdfZGVi dWdfaW5pdCsweDAvMHg3NyByZXR1cm5lZCAwIGFmdGVyIDI3MyB1c2VjcwpbICAgIDMuNzk3OTYw XSBjYWxsaW5nICBzZXR1cF92bXN0YXQrMHgwLzB4YzAgQCAxClsgICAgMy43OTgxODZdIGluaXRj YWxsIHNldHVwX3Ztc3RhdCsweDAvMHhjMCByZXR1cm5lZCAwIGFmdGVyIDE5OCB1c2VjcwpbICAg IDMuNzk4MjEzXSBjYWxsaW5nICBtbV9zeXNmc19pbml0KzB4MC8weDI5IEAgMQpbICAgIDMuNzk4 MjkzXSBpbml0Y2FsbCBtbV9zeXNmc19pbml0KzB4MC8weDI5IHJldHVybmVkIDAgYWZ0ZXIgNTYg dXNlY3MKWyAgICAzLjc5ODMyMF0gY2FsbGluZyAgcHJvY192bWFsbG9jX2luaXQrMHgwLzB4MjUg QCAxClsgICAgMy43OTgzODFdIGluaXRjYWxsIHByb2Nfdm1hbGxvY19pbml0KzB4MC8weDI1IHJl dHVybmVkIDAgYWZ0ZXIgMzcgdXNlY3MKWyAgICAzLjc5ODQwOV0gY2FsbGluZyAgcHJvY3N3YXBz X2luaXQrMHgwLzB4MjIgQCAxClsgICAgMy43OTg0OTZdIGNhbGxpbmcgIGh1Z2V0bGJfaW5pdCsw eDAvMHgzOTMgQCAxClsgICAgMy43OTg1MjFdIEh1Z2VUTEIgcmVnaXN0ZXJlZCAyIE1CIHBhZ2Ug c2l6ZSwgcHJlLWFsbG9jYXRlZCAwIHBhZ2VzClsgICAgMy43OTg5NDRdIGluaXRjYWxsIGh1Z2V0 bGJfaW5pdCsweDAvMHgzOTMgcmV0dXJuZWQgMCBhZnRlciA0MTQgdXNlY3MKWyAgICAzLjc5ODk3 M10gY2FsbGluZyAga3NtX2luaXQrMHgwLzB4MTZmIEAgMQpbICAgIDMuNzk5NjIzXSBpbml0Y2Fs bCBrc21faW5pdCsweDAvMHgxNmYgcmV0dXJuZWQgMCBhZnRlciA2MTUgdXNlY3MKWyAgICAzLjc5 OTY1Ml0gY2FsbGluZyAgc2xhYl9wcm9jX2luaXQrMHgwLzB4MjUgQCAxClsgICAgMy43OTk3Mjhd IGluaXRjYWxsIHNsYWJfcHJvY19pbml0KzB4MC8weDI1IHJldHVybmVkIDAgYWZ0ZXIgNTEgdXNl Y3MKWyAgICAzLjc5OTc1NV0gY2FsbGluZyAgc2xhYl9zeXNmc19pbml0KzB4MC8weDEwNCBAIDEK WyAgICAzLjg4MDM3OV0gaW5pdGNhbGwgc2xhYl9zeXNmc19pbml0KzB4MC8weDEwNCByZXR1cm5l ZCAwIGFmdGVyIDc4NzA0IHVzZWNzClsgICAgMy44ODA0MjBdIGNhbGxpbmcgIGh1Z2VwYWdlX2lu aXQrMHgwLzB4MTM3IEAgMQpbICAgIDMuODgwNDQzXSBpbml0Y2FsbCBodWdlcGFnZV9pbml0KzB4 MC8weDEzNyByZXR1cm5lZCAtMjIgYWZ0ZXIgMCB1c2VjcwpbICAgIDMuODgwNDcyXSBpbml0Y2Fs bCBodWdlcGFnZV9pbml0KzB4MC8weDEzNyByZXR1cm5lZCB3aXRoIGVycm9yIGNvZGUgLTIyClsg ICAgMy44ODA0OTldIGNhbGxpbmcgIGluaXRfY2xlYW5jYWNoZSsweDAvMHgxYiBAIDEKWyAgICAz Ljg4MDYxMV0gaW5pdGNhbGwgaW5pdF9jbGVhbmNhY2hlKzB4MC8weDFiIHJldHVybmVkIDAgYWZ0 ZXIgODcgdXNlY3MKWyAgICAzLjg4MDYzOF0gY2FsbGluZyAgZmNudGxfaW5pdCsweDAvMHgyYSBA IDEKWyAgICAzLjg4MTQzNV0gaW5pdGNhbGwgZmNudGxfaW5pdCsweDAvMHgyYSByZXR1cm5lZCAw IGFmdGVyIDc1NiB1c2VjcwpbICAgIDMuODgxNDY0XSBjYWxsaW5nICBwcm9jX2ZpbGVzeXN0ZW1z X2luaXQrMHgwLzB4MjIgQCAxClsgICAgMy44ODE1MzZdIGluaXRjYWxsIHByb2NfZmlsZXN5c3Rl bXNfaW5pdCsweDAvMHgyMiByZXR1cm5lZCAwIGFmdGVyIDQ4IHVzZWNzClsgICAgMy44ODE1Njhd IGNhbGxpbmcgIGZzbm90aWZ5X21hcmtfaW5pdCsweDAvMHg0MCBAIDEKWyAgICAzLjg4MTk3OF0g aW5pdGNhbGwgZnNub3RpZnlfbWFya19pbml0KzB4MC8weDQwIHJldHVybmVkIDAgYWZ0ZXIgMzc4 IHVzZWNzClsgICAgMy44ODIwMDddIGNhbGxpbmcgIGRub3RpZnlfaW5pdCsweDAvMHg3YiBAIDEK WyAgICAzLjg4MzUxOF0gaW5pdGNhbGwgZG5vdGlmeV9pbml0KzB4MC8weDdiIHJldHVybmVkIDAg YWZ0ZXIgMTQ1MSB1c2VjcwpbICAgIDMuODgzNTQ4XSBjYWxsaW5nICBpbm90aWZ5X3VzZXJfc2V0 dXArMHgwLzB4NzAgQCAxClsgICAgMy44ODQ5OTFdIGluaXRjYWxsIGlub3RpZnlfdXNlcl9zZXR1 cCsweDAvMHg3MCByZXR1cm5lZCAwIGFmdGVyIDEzODYgdXNlY3MKWyAgICAzLjg4NTAyNF0gY2Fs bGluZyAgZmFub3RpZnlfdXNlcl9zZXR1cCsweDAvMHg1MiBAIDEKWyAgICAzLjg4NjU5M10gaW5p dGNhbGwgZmFub3RpZnlfdXNlcl9zZXR1cCsweDAvMHg1MiByZXR1cm5lZCAwIGFmdGVyIDE1MDgg dXNlY3MKWyAgICAzLjg4NjYyNl0gY2FsbGluZyAgYWlvX3NldHVwKzB4MC8weGEwIEAgMQpbICAg IDMuODg4MDkzXSBpbml0Y2FsbCBhaW9fc2V0dXArMHgwLzB4YTAgcmV0dXJuZWQgMCBhZnRlciAx NDEzIHVzZWNzClsgICAgMy44ODgxMjFdIGNhbGxpbmcgIHByb2NfbG9ja3NfaW5pdCsweDAvMHgy MiBAIDEKWyAgICAzLjg4ODE4NV0gaW5pdGNhbGwgcHJvY19sb2Nrc19pbml0KzB4MC8weDIyIHJl dHVybmVkIDAgYWZ0ZXIgNDAgdXNlY3MKWyAgICAzLjg4ODIyNl0gY2FsbGluZyAgaW5pdF9zeXMz Ml9pb2N0bCsweDAvMHgyOCBAIDEKWyAgICAzLjg4ODIyNl0gaW5pdGNhbGwgaW5pdF9zeXMzMl9p b2N0bCsweDAvMHgyOCByZXR1cm5lZCAwIGFmdGVyIDk5IHVzZWNzClsgICAgMy44ODgyMjZdIGNh bGxpbmcgIGluaXRfbWJjYWNoZSsweDAvMHgxNCBAIDEKWyAgICAzLjg4ODIyNl0gaW5pdGNhbGwg aW5pdF9tYmNhY2hlKzB4MC8weDE0IHJldHVybmVkIDAgYWZ0ZXIgMyB1c2VjcwpbICAgIDMuODg4 MjI2XSBjYWxsaW5nICBkcXVvdF9pbml0KzB4MC8weDExNSBAIDEKWyAgICAzLjg4ODIyNl0gVkZT OiBEaXNrIHF1b3RhcyBkcXVvdF82LjUuMgpbICAgIDMuODg5NTkyXSBEcXVvdC1jYWNoZSBoYXNo IHRhYmxlIGVudHJpZXM6IDUxMiAob3JkZXIgMCwgNDA5NiBieXRlcykKWyAgICAzLjg4OTY2OV0g aW5pdGNhbGwgZHF1b3RfaW5pdCsweDAvMHgxMTUgcmV0dXJuZWQgMCBhZnRlciAxMTYwIHVzZWNz ClsgICAgMy44ODk2OTVdIGNhbGxpbmcgIGluaXRfdjJfcXVvdGFfZm9ybWF0KzB4MC8weDIyIEAg MQpbICAgIDMuODg5NzQ3XSBpbml0Y2FsbCBpbml0X3YyX3F1b3RhX2Zvcm1hdCsweDAvMHgyMiBy ZXR1cm5lZCAwIGFmdGVyIDI3IHVzZWNzClsgICAgMy44ODk3NzddIGNhbGxpbmcgIHF1b3RhX2lu aXQrMHgwLzB4MjYgQCAxClsgICAgMy44ODk4NzBdIGluaXRjYWxsIHF1b3RhX2luaXQrMHgwLzB4 MjYgcmV0dXJuZWQgMCBhZnRlciA2OCB1c2VjcwpbICAgIDMuODg5ODk3XSBjYWxsaW5nICBwcm9j X2NtZGxpbmVfaW5pdCsweDAvMHgyMiBAIDEKWyAgICAzLjg4OTk2M10gaW5pdGNhbGwgcHJvY19j bWRsaW5lX2luaXQrMHgwLzB4MjIgcmV0dXJuZWQgMCBhZnRlciA0MSB1c2VjcwpbICAgIDMuODg5 OTkwXSBjYWxsaW5nICBwcm9jX2NvbnNvbGVzX2luaXQrMHgwLzB4MjIgQCAxClsgICAgMy44OTAw NjldIGluaXRjYWxsIHByb2NfY29uc29sZXNfaW5pdCsweDAvMHgyMiByZXR1cm5lZCAwIGFmdGVy IDU1IHVzZWNzClsgICAgMy44OTAwOThdIGNhbGxpbmcgIHByb2NfY3B1aW5mb19pbml0KzB4MC8w eDIyIEAgMQpbICAgIDMuODkwMTMzXSBpbml0Y2FsbCBwcm9jX2NwdWluZm9faW5pdCsweDAvMHgy MiByZXR1cm5lZCAwIGFmdGVyIDM4IHVzZWNzClsgICAgMy44OTAxMzNdIGNhbGxpbmcgIHByb2Nf ZGV2aWNlc19pbml0KzB4MC8weDIyIEAgMQpbICAgIDMuODkwMTMzXSBpbml0Y2FsbCBwcm9jX2Rl dmljZXNfaW5pdCsweDAvMHgyMiByZXR1cm5lZCAwIGFmdGVyIDM3IHVzZWNzClsgICAgMy44OTAx MzNdIGNhbGxpbmcgIHByb2NfaW50ZXJydXB0c19pbml0KzB4MC8weDIyIEAgMQpbICAgIDMuODkw MTMzXSBpbml0Y2FsbCBwcm9jX2ludGVycnVwdHNfaW5pdCsweDAvMHgyMiByZXR1cm5lZCAwIGFm dGVyIDM3IHVzZWNzClsgICAgMy44OTAxMzNdIGNhbGxpbmcgIHByb2NfbG9hZGF2Z19pbml0KzB4 MC8weDIyIEAgMQpbICAgIDMuODkwMTMzXSBpbml0Y2FsbCBwcm9jX2xvYWRhdmdfaW5pdCsweDAv MHgyMiByZXR1cm5lZCAwIGFmdGVyIDM3IHVzZWNzClsgICAgMy44OTAxMzNdIGNhbGxpbmcgIHBy b2NfbWVtaW5mb19pbml0KzB4MC8weDIyIEAgMQpbICAgIDMuODkwMTMzXSBpbml0Y2FsbCBwcm9j X21lbWluZm9faW5pdCsweDAvMHgyMiByZXR1cm5lZCAwIGFmdGVyIDM3IHVzZWNzClsgICAgMy44 OTAxMzNdIGNhbGxpbmcgIHByb2Nfc3RhdF9pbml0KzB4MC8weDIyIEAgMQpbICAgIDMuODkwMTMz XSBpbml0Y2FsbCBwcm9jX3N0YXRfaW5pdCsweDAvMHgyMiByZXR1cm5lZCAwIGFmdGVyIDM3IHVz ZWNzClsgICAgMy44OTAxMzNdIGNhbGxpbmcgIHByb2NfdXB0aW1lX2luaXQrMHgwLzB4MjIgQCAx ClsgICAgMy44OTAxMzNdIGNhbGxpbmcgIHByb2NfdmVyc2lvbl9pbml0KzB4MC8weDIyIEAgMQpb ICAgIDMuODkwMTMzXSBpbml0Y2FsbCBwcm9jX3ZlcnNpb25faW5pdCsweDAvMHgyMiByZXR1cm5l ZCAwIGFmdGVyIDM3IHVzZWNzClsgICAgMy44OTAxMzNdIGNhbGxpbmcgIHByb2Nfc29mdGlycXNf aW5pdCsweDAvMHgyMiBAIDEKWyAgICAzLjg5MDEzM10gaW5pdGNhbGwgcHJvY19zb2Z0aXJxc19p bml0KzB4MC8weDIyIHJldHVybmVkIDAgYWZ0ZXIgMzcgdXNlY3MKWyAgICAzLjg5MDEzM10gY2Fs bGluZyAgcHJvY19rY29yZV9pbml0KzB4MC8weGI1IEAgMQpbICAgIDMuODkwMTMzXSBpbml0Y2Fs bCBwcm9jX2tjb3JlX2luaXQrMHgwLzB4YjUgcmV0dXJuZWQgMCBhZnRlciAxNjUgdXNlY3MKWyAg ICAzLjg5MDEzM10gY2FsbGluZyAgdm1jb3JlX2luaXQrMHgwLzB4NTFiIEAgMQpbICAgIDMuODkw MTMzXSBpbml0Y2FsbCB2bWNvcmVfaW5pdCsweDAvMHg1MWIgcmV0dXJuZWQgMCBhZnRlciAwIHVz ZWNzClsgICAgMy44OTAxMzNdIGNhbGxpbmcgIHByb2Nfa21zZ19pbml0KzB4MC8weDI1IEAgMQpb ICAgIDMuODkwMTMzXSBpbml0Y2FsbCBwcm9jX2ttc2dfaW5pdCsweDAvMHgyNSByZXR1cm5lZCAw IGFmdGVyIDM4IHVzZWNzClsgICAgMy44OTAxMzNdIGNhbGxpbmcgIHByb2NfcGFnZV9pbml0KzB4 MC8weDQyIEAgMQpbICAgIDMuODkwMTMzXSBpbml0Y2FsbCBwcm9jX3BhZ2VfaW5pdCsweDAvMHg0 MiByZXR1cm5lZCAwIGFmdGVyIDcyIHVzZWNzClsgICAgMy44OTAxMzNdIGNhbGxpbmcgIGluaXRf ZGV2cHRzX2ZzKzB4MC8weDRhIEAgMQpbICAgIDMuODkwMTMzXSBpbml0Y2FsbCBpbml0X2RldnB0 c19mcysweDAvMHg0YSByZXR1cm5lZCAwIGFmdGVyIDQ2OCB1c2VjcwpbICAgIDMuODkwMTMzXSBj YWxsaW5nICBleHQ0X2luaXRfZnMrMHgwLzB4MjY2IEAgMQpbICAgIDMuODk4NTgxXSBpbml0Y2Fs bCBleHQ0X2luaXRfZnMrMHgwLzB4MjY2IHJldHVybmVkIDAgYWZ0ZXIgNjQ5NiB1c2VjcwpbICAg IDMuODk4NjExXSBjYWxsaW5nICBqb3VybmFsX2luaXQrMHgwLzB4MTQ1IEAgMQpbICAgIDMuOTAy NTczXSBpbml0Y2FsbCBqb3VybmFsX2luaXQrMHgwLzB4MTQ1IHJldHVybmVkIDAgYWZ0ZXIgMzg0 NiB1c2VjcwpbICAgIDMuOTAyNjAyXSBjYWxsaW5nICBpbml0X3JhbWZzX2ZzKzB4MC8weDEyIEAg MQpbICAgIDMuOTAyNjI4XSBpbml0Y2FsbCBpbml0X3JhbWZzX2ZzKzB4MC8weDEyIHJldHVybmVk IDAgYWZ0ZXIgMyB1c2VjcwpbICAgIDMuOTAyNjUzXSBjYWxsaW5nICBpbml0X2h1Z2V0bGJmc19m cysweDAvMHg5NiBAIDEKWyAgICAzLjkwMzkwNl0gaW5pdGNhbGwgaW5pdF9odWdldGxiZnNfZnMr MHgwLzB4OTYgcmV0dXJuZWQgMCBhZnRlciAxMjAxIHVzZWNzClsgICAgMy45MDM5MzVdIGNhbGxp bmcgIGluaXRfaXNvOTY2MF9mcysweDAvMHg2ZSBAIDEKWyAgICAzLjkwNDc5MV0gaW5pdGNhbGwg aW5pdF9pc285NjYwX2ZzKzB4MC8weDZlIHJldHVybmVkIDAgYWZ0ZXIgODEzIHVzZWNzClsgICAg My45MDQ4MjBdIGNhbGxpbmcgIGluaXRfbmxzX2NwNDM3KzB4MC8weDEyIEAgMQpbICAgIDMuOTA0 ODY1XSBpbml0Y2FsbCBpbml0X25sc19jcDQzNysweDAvMHgxMiByZXR1cm5lZCAwIGFmdGVyIDIy IHVzZWNzClsgICAgMy45MDQ4OTFdIGNhbGxpbmcgIGluaXRfbmxzX2FzY2lpKzB4MC8weDEyIEAg MQpbICAgIDMuOTA0OTE1XSBpbml0Y2FsbCBpbml0X25sc19hc2NpaSsweDAvMHgxMiByZXR1cm5l ZCAwIGFmdGVyIDIgdXNlY3MKWyAgICAzLjkwNDk0MV0gY2FsbGluZyAgaW5pdF9hdXRvZnM0X2Zz KzB4MC8weDIzIEAgMQpbICAgIDMuOTA1ODI5XSBpbml0Y2FsbCBpbml0X2F1dG9mczRfZnMrMHgw LzB4MjMgcmV0dXJuZWQgMCBhZnRlciA4NDUgdXNlY3MKWyAgICAzLjkwNTg1OF0gY2FsbGluZyAg aW5pdF9wc3RvcmVfZnMrMHgwLzB4MTIgQCAxClsgICAgMy45MDU4ODRdIGluaXRjYWxsIGluaXRf cHN0b3JlX2ZzKzB4MC8weDEyIHJldHVybmVkIDAgYWZ0ZXIgNCB1c2VjcwpbICAgIDMuOTA1OTEw XSBjYWxsaW5nICBpcGNfaW5pdCsweDAvMHgyZiBAIDEKWyAgICAzLjkwNTk4OF0gbXNnbW5pIGhh cyBiZWVuIHNldCB0byAyOTA5ClsgICAgMy45MDYxMTFdIGluaXRjYWxsIGlwY19pbml0KzB4MC8w eDJmIHJldHVybmVkIDAgYWZ0ZXIgMTc4IHVzZWNzClsgICAgMy45MDYxMzhdIGNhbGxpbmcgIGlw Y19zeXNjdGxfaW5pdCsweDAvMHgxNCBAIDEKWyAgICAzLjkwNjQwOF0gaW5pdGNhbGwgaXBjX3N5 c2N0bF9pbml0KzB4MC8weDE0IHJldHVybmVkIDAgYWZ0ZXIgMjcyIHVzZWNzClsgICAgMy45MDY0 MDhdIGNhbGxpbmcgIGluaXRfbXF1ZXVlX2ZzKzB4MC8weGM1IEAgMQpbICAgIDMuOTA3ODgzXSBp bml0Y2FsbCBpbml0X21xdWV1ZV9mcysweDAvMHhjNSByZXR1cm5lZCAwIGFmdGVyIDEzNjIgdXNl Y3MKWyAgICAzLjkwNzkxMl0gY2FsbGluZyAga2V5X3Byb2NfaW5pdCsweDAvMHg1OSBAIDEKWyAg ICAzLjkwODA2Ml0gaW5pdGNhbGwga2V5X3Byb2NfaW5pdCsweDAvMHg1OSByZXR1cm5lZCAwIGFm dGVyIDEyNSB1c2VjcwpbICAgIDMuOTA4MDkwXSBjYWxsaW5nICBzZWxpbnV4X25mX2lwX2luaXQr MHgwLzB4NjIgQCAxClsgICAgMy45MDgwOTVdIFNFTGludXg6ICBSZWdpc3RlcmluZyBuZXRmaWx0 ZXIgaG9va3MKWyAgICAzLjkwODA5NV0gaW5pdGNhbGwgc2VsaW51eF9uZl9pcF9pbml0KzB4MC8w eDYyIHJldHVybmVkIDAgYWZ0ZXIgNTIgdXNlY3MKWyAgICAzLjkwODA5NV0gY2FsbGluZyAgaW5p dF9zZWxfZnMrMHgwLzB4OWIgQCAxClsgICAgMy45MTE3MzBdIGluaXRjYWxsIGluaXRfc2VsX2Zz KzB4MC8weDliIHJldHVybmVkIDAgYWZ0ZXIgMzQzMSB1c2VjcwpbICAgIDMuOTExNzU4XSBjYWxs aW5nICBzZWxubF9pbml0KzB4MC8weDRkIEAgMQpbICAgIDMuOTExODc2XSBpbml0Y2FsbCBzZWxu bF9pbml0KzB4MC8weDRkIHJldHVybmVkIDAgYWZ0ZXIgOTMgdXNlY3MKWyAgICAzLjkxMTkwNF0g Y2FsbGluZyAgc2VsX25ldGlmX2luaXQrMHgwLzB4NzMgQCAxClsgICAgMy45MTE5NDVdIGluaXRj YWxsIHNlbF9uZXRpZl9pbml0KzB4MC8weDczIHJldHVybmVkIDAgYWZ0ZXIgMTggdXNlY3MKWyAg ICAzLjkxMTk3Ml0gY2FsbGluZyAgc2VsX25ldG5vZGVfaW5pdCsweDAvMHg3NCBAIDEKWyAgICAz LjkxMjAwN10gaW5pdGNhbGwgc2VsX25ldG5vZGVfaW5pdCsweDAvMHg3NCByZXR1cm5lZCAwIGFm dGVyIDEzIHVzZWNzClsgICAgMy45MTIwMzNdIGNhbGxpbmcgIHNlbF9uZXRwb3J0X2luaXQrMHgw LzB4NzQgQCAxClsgICAgMy45MTIwNjldIGluaXRjYWxsIHNlbF9uZXRwb3J0X2luaXQrMHgwLzB4 NzQgcmV0dXJuZWQgMCBhZnRlciAxMiB1c2VjcwpbICAgIDMuOTEyMDk2XSBjYWxsaW5nICBhdXJ1 bGVfaW5pdCsweDAvMHgzNyBAIDEKWyAgICAzLjkxMjEyOF0gaW5pdGNhbGwgYXVydWxlX2luaXQr MHgwLzB4MzcgcmV0dXJuZWQgMCBhZnRlciAxMCB1c2VjcwpbICAgIDMuOTEyMTU0XSBjYWxsaW5n ICBjcnlwdG9fd3FfaW5pdCsweDAvMHgzNiBAIDEKWyAgICAzLjkxMjYyOF0gaW5pdGNhbGwgY3J5 cHRvX3dxX2luaXQrMHgwLzB4MzYgcmV0dXJuZWQgMCBhZnRlciA0NDEgdXNlY3MKWyAgICAzLjkx MjY1N10gY2FsbGluZyAgY3J5cHRvX2FsZ2FwaV9pbml0KzB4MC8weGQgQCAxClsgICAgMy45MTI4 MThdIGNhbGxpbmcgIHNrY2lwaGVyX21vZHVsZV9pbml0KzB4MC8weDM1IEAgMQpbICAgIDMuOTEy ODQwXSBpbml0Y2FsbCBza2NpcGhlcl9tb2R1bGVfaW5pdCsweDAvMHgzNSByZXR1cm5lZCAwIGFm dGVyIDAgdXNlY3MKWyAgICAzLjkxMjg2Nl0gY2FsbGluZyAgY2hhaW5pdl9tb2R1bGVfaW5pdCsw eDAvMHgxMiBAIDEKWyAgICAzLjkxMjg5N10gaW5pdGNhbGwgY2hhaW5pdl9tb2R1bGVfaW5pdCsw eDAvMHgxMiByZXR1cm5lZCAwIGFmdGVyIDggdXNlY3MKWyAgICAzLjkxMjkyM10gY2FsbGluZyAg ZXNlcWl2X21vZHVsZV9pbml0KzB4MC8weDEyIEAgMQpbICAgIDMuOTEyOTUwXSBpbml0Y2FsbCBl c2VxaXZfbW9kdWxlX2luaXQrMHgwLzB4MTIgcmV0dXJuZWQgMCBhZnRlciA0IHVzZWNzClsgICAg My45MTI5NzZdIGNhbGxpbmcgIHNlcWl2X21vZHVsZV9pbml0KzB4MC8weDEyIEAgMQpbICAgIDMu OTEzMDAzXSBpbml0Y2FsbCBzZXFpdl9tb2R1bGVfaW5pdCsweDAvMHgxMiByZXR1cm5lZCAwIGFm dGVyIDQgdXNlY3MKWyAgICAzLjkxMzAzMF0gY2FsbGluZyAgaG1hY19tb2R1bGVfaW5pdCsweDAv MHgxMiBAIDEKWyAgICAzLjkxMzA1Nl0gaW5pdGNhbGwgaG1hY19tb2R1bGVfaW5pdCsweDAvMHgx MiByZXR1cm5lZCAwIGFmdGVyIDQgdXNlY3MKWyAgICAzLjkxMzA4M10gY2FsbGluZyAgbWQ1X21v ZF9pbml0KzB4MC8weDEyIEAgMQpbICAgIDMuOTEzNzMzXSBjcnlwdG9tZ3JfdGVzdCB1c2VkIGdy ZWF0ZXN0IHN0YWNrIGRlcHRoOiA1NTEyIGJ5dGVzIGxlZnQKWyAgICAzLjkxMzc0NV0gaW5pdGNh bGwgbWQ1X21vZF9pbml0KzB4MC8weDEyIHJldHVybmVkIDAgYWZ0ZXIgNjIzIHVzZWNzClsgICAg My45MTM3NTBdIGNhbGxpbmcgIHNoYTFfZ2VuZXJpY19tb2RfaW5pdCsweDAvMHgxMiBAIDEKWyAg ICAzLjkxNDUxMl0gaW5pdGNhbGwgc2hhMV9nZW5lcmljX21vZF9pbml0KzB4MC8weDEyIHJldHVy bmVkIDAgYWZ0ZXIgNzM5IHVzZWNzClsgICAgMy45MTQ1NDZdIGNhbGxpbmcgIGNyeXB0b19lY2Jf bW9kdWxlX2luaXQrMHgwLzB4MTIgQCAxClsgICAgMy45MTQ1NzVdIGluaXRjYWxsIGNyeXB0b19l Y2JfbW9kdWxlX2luaXQrMHgwLzB4MTIgcmV0dXJuZWQgMCBhZnRlciA2IHVzZWNzClsgICAgMy45 MTQ2MDZdIGNhbGxpbmcgIGNyeXB0b19jYmNfbW9kdWxlX2luaXQrMHgwLzB4MTIgQCAxClsgICAg My45MTQ2MzNdIGluaXRjYWxsIGNyeXB0b19jYmNfbW9kdWxlX2luaXQrMHgwLzB4MTIgcmV0dXJu ZWQgMCBhZnRlciA0IHVzZWNzClsgICAgMy45MTQ2NjJdIGNhbGxpbmcgIGNyeXB0b19jdHJfbW9k dWxlX2luaXQrMHgwLzB4M2MgQCAxClsgICAgMy45MTQ2OTRdIGluaXRjYWxsIGNyeXB0b19jdHJf bW9kdWxlX2luaXQrMHgwLzB4M2MgcmV0dXJuZWQgMCBhZnRlciA4IHVzZWNzClsgICAgMy45MTQ3 MjNdIGNhbGxpbmcgIGFlc19pbml0KzB4MC8weDEyIEAgMQpbICAgIDMuOTE1NTk0XSBpbml0Y2Fs bCBhZXNfaW5pdCsweDAvMHgxMiByZXR1cm5lZCAwIGFmdGVyIDgzMSB1c2VjcwpbICAgIDMuOTE1 NjIzXSBjYWxsaW5nICBjcmMzMmNfbW9kX2luaXQrMHgwLzB4MTIgQCAxClsgICAgMy45MTY4NDNd IGluaXRjYWxsIGNyYzMyY19tb2RfaW5pdCsweDAvMHgxMiByZXR1cm5lZCAwIGFmdGVyIDExNjgg dXNlY3MKWyAgICAzLjkxNjg1N10gY3J5cHRvbWdyX3Rlc3QgdXNlZCBncmVhdGVzdCBzdGFjayBk ZXB0aDogNTQ0OCBieXRlcyBsZWZ0ClsgICAgMy45MTY4OTNdIGNhbGxpbmcgIGtybmdfbW9kX2lu aXQrMHgwLzB4MTIgQCAxClsgICAgMy45MTcyNzFdIGFsZzogTm8gdGVzdCBmb3Igc3Rkcm5nIChr cm5nKQpbICAgIDMuOTE3MzU0XSBpbml0Y2FsbCBrcm5nX21vZF9pbml0KzB4MC8weDEyIHJldHVy bmVkIDAgYWZ0ZXIgNDI4IHVzZWNzClsgICAgMy45MTczODNdIGNhbGxpbmcgIGFmX2FsZ19pbml0 KzB4MC8weDNlIEAgMQpbICAgIDMuOTE3NDExXSBORVQ6IFJlZ2lzdGVyZWQgcHJvdG9jb2wgZmFt aWx5IDM4ClsgICAgMy45MTc0MzNdIGluaXRjYWxsIGFmX2FsZ19pbml0KzB4MC8weDNlIHJldHVy bmVkIDAgYWZ0ZXIgMjcgdXNlY3MKWyAgICAzLjkxNzQ1OV0gY2FsbGluZyAgYWxnaWZfaGFzaF9p bml0KzB4MC8weDEyIEAgMQpbICAgIDMuOTE3NTM3XSBpbml0Y2FsbCBhbGdpZl9oYXNoX2luaXQr MHgwLzB4MTIgcmV0dXJuZWQgMCBhZnRlciA1MyB1c2VjcwpbICAgIDMuOTE3NTY0XSBjYWxsaW5n ICBhbGdpZl9za2NpcGhlcl9pbml0KzB4MC8weDEyIEAgMQpbICAgIDMuOTE3NjAwXSBpbml0Y2Fs bCBhbGdpZl9za2NpcGhlcl9pbml0KzB4MC8weDEyIHJldHVybmVkIDAgYWZ0ZXIgMTQgdXNlY3MK WyAgICAzLjkxNzYyN10gY2FsbGluZyAgcHJvY19nZW5oZF9pbml0KzB4MC8weDNjIEAgMQpbICAg IDMuOTE3NzMzXSBpbml0Y2FsbCBwcm9jX2dlbmhkX2luaXQrMHgwLzB4M2MgcmV0dXJuZWQgMCBh ZnRlciA4MiB1c2VjcwpbICAgIDMuOTE3NzYwXSBjYWxsaW5nICBic2dfaW5pdCsweDAvMHgxMmUg QCAxClsgICAgMy45MTg4NDFdIEJsb2NrIGxheWVyIFNDU0kgZ2VuZXJpYyAoYnNnKSBkcml2ZXIg dmVyc2lvbiAwLjQgbG9hZGVkIChtYWpvciAyNTMpClsgICAgMy45MTg4NzRdIGluaXRjYWxsIGJz Z19pbml0KzB4MC8weDEyZSByZXR1cm5lZCAwIGFmdGVyIDEwNzAgdXNlY3MKWyAgICAzLjkxODkw MF0gY2FsbGluZyAgaW5pdF9jZ3JvdXBfYmxraW8rMHgwLzB4MTIgQCAxClsgICAgMy45MTg5MjNd IGluaXRjYWxsIGluaXRfY2dyb3VwX2Jsa2lvKzB4MC8weDEyIHJldHVybmVkIDAgYWZ0ZXIgMSB1 c2VjcwpbICAgIDMuOTE4OTQ5XSBjYWxsaW5nICB0aHJvdGxfaW5pdCsweDAvMHg0OSBAIDEKWyAg ICAzLjkxOTM1NV0gaW5pdGNhbGwgdGhyb3RsX2luaXQrMHgwLzB4NDkgcmV0dXJuZWQgMCBhZnRl ciAzNzQgdXNlY3MKWyAgICAzLjkxOTM4NV0gY2FsbGluZyAgbm9vcF9pbml0KzB4MC8weDE0IEAg MQpbICAgIDMuOTE5NDIzXSBpbyBzY2hlZHVsZXIgbm9vcCByZWdpc3RlcmVkClsgICAgMy45MTk0 NDJdIGluaXRjYWxsIG5vb3BfaW5pdCsweDAvMHgxNCByZXR1cm5lZCAwIGFmdGVyIDM4IHVzZWNz ClsgICAgMy45MTk0NjddIGNhbGxpbmcgIGRlYWRsaW5lX2luaXQrMHgwLzB4MTQgQCAxClsgICAg My45MTk0OTBdIGlvIHNjaGVkdWxlciBkZWFkbGluZSByZWdpc3RlcmVkClsgICAgMy45MTk1MTJd IGluaXRjYWxsIGRlYWRsaW5lX2luaXQrMHgwLzB4MTQgcmV0dXJuZWQgMCBhZnRlciAyMiB1c2Vj cwpbICAgIDMuOTE5NTM4XSBjYWxsaW5nICBjZnFfaW5pdCsweDAvMHhiMyBAIDEKWyAgICAzLjky MDk5MF0gaW8gc2NoZWR1bGVyIGNmcSByZWdpc3RlcmVkIChkZWZhdWx0KQpbICAgIDMuOTIxMDE3 XSBpbml0Y2FsbCBjZnFfaW5pdCsweDAvMHhiMyByZXR1cm5lZCAwIGFmdGVyIDE0MjYgdXNlY3MK WyAgICAzLjkyMTA0NF0gY2FsbGluZyAgcGxpc3RfdGVzdCsweDAvMHgxNWUgQCAxClsgICAgMy45 MjEwNjddIHN0YXJ0IHBsaXN0IHRlc3QKWyAgICAzLjkyMjM2Nl0gZW5kIHBsaXN0IHRlc3QKWyAg ICAzLjkyMjQwOV0gY2FsbGluZyAgbGlzdF9zb3J0X3Rlc3QrMHgwLzB4MWU2IEAgMQpbICAgIDMu OTIyNDI5XSBsaXN0X3NvcnRfdGVzdDogc3RhcnQgdGVzdGluZyBsaXN0X3NvcnQoKQpbICAgIDMu OTI5MTIzXSBpbml0Y2FsbCBsaXN0X3NvcnRfdGVzdCsweDAvMHgxZTYgcmV0dXJuZWQgMCBhZnRl ciAxMTExNCB1c2VjcwpbICAgIDMuOTI5MTIzXSBjYWxsaW5nICBidHJlZV9tb2R1bGVfaW5pdCsw eDAvMHgyYSBAIDEKWyAgICAzLjkzNDU3M10gaW5pdGNhbGwgYnRyZWVfbW9kdWxlX2luaXQrMHgw LzB4MmEgcmV0dXJuZWQgMCBhZnRlciA2OTEgdXNlY3MKWyAgICAzLjkzNDYwMl0gY2FsbGluZyAg ZGVidWdfb2JqZWN0c19pbml0X2RlYnVnZnMrMHgwLzB4NjMgQCAxClsgICAgMy45MzQ3ODddIGlu aXRjYWxsIGRlYnVnX29iamVjdHNfaW5pdF9kZWJ1Z2ZzKzB4MC8weDYzIHJldHVybmVkIDAgYWZ0 ZXIgMTUzIHVzZWNzClsgICAgMy45MzQ4NjNdIGNhbGxpbmcgIHBlcmNwdV9jb3VudGVyX3N0YXJ0 dXArMHgwLzB4MTkgQCAxClsgICAgMy45MzQ4OTJdIGluaXRjYWxsIHBlcmNwdV9jb3VudGVyX3N0 YXJ0dXArMHgwLzB4MTkgcmV0dXJuZWQgMCBhZnRlciA2IHVzZWNzClsgICAgMy45MzQ5MjNdIGNh bGxpbmcgIGR5bmFtaWNfZGVidWdfaW5pdF9kZWJ1Z2ZzKzB4MC8weDY2IEAgMQpbICAgIDMuOTM1 MDI5XSBpbml0Y2FsbCBkeW5hbWljX2RlYnVnX2luaXRfZGVidWdmcysweDAvMHg2NiByZXR1cm5l ZCAwIGFmdGVyIDEyOSB1c2VjcwpbICAgIDMuOTM1MDI5XSBjYWxsaW5nICBsbndfZ3Bpb19pbml0 KzB4MC8weDQ1IEAgMQpbICAgIDMuOTM1NzEwXSBpbml0Y2FsbCBsbndfZ3Bpb19pbml0KzB4MC8w eDQ1IHJldHVybmVkIDAgYWZ0ZXIgNTU5IHVzZWNzClsgICAgMy45MzU3MzldIGNhbGxpbmcgIHBj aV9wcm9jX2luaXQrMHgwLzB4NjcgQCAxClsgICAgMy45Mzc1MTZdIGluaXRjYWxsIHBjaV9wcm9j X2luaXQrMHgwLzB4NjcgcmV0dXJuZWQgMCBhZnRlciAxNzEyIHVzZWNzClsgICAgMy45Mzc1NDVd IGNhbGxpbmcgIHBjaWVfcG9ydGRydl9pbml0KzB4MC8weDc3IEAgMQpbICAgIDMuOTM4MTQ5XSBw Y2llcG9ydCAwMDAwOjAwOjFjLjA6IHNldHRpbmcgbGF0ZW5jeSB0aW1lciB0byA2NApbICAgIDMu OTM4NDkxXSBCVUc6IHNjaGVkdWxpbmcgd2hpbGUgYXRvbWljOiBzd2FwcGVyLzEvMHgxMDAwMDAw MgpbICAgIDMuOTM4NTE4XSAzIGxvY2tzIGhlbGQgYnkgc3dhcHBlci8xOgpbICAgIDMuOTM4NTM0 XSAgIzA6ICAoJl9fbG9ja2RlcF9ub192YWxpZGF0ZV9fKXsuLi4uLi59LCBhdDogWzxmZmZmZmZm ZjgxMzE3NmQwPl0gX19kcml2ZXJfYXR0YWNoKzB4M2IvMHg4MgpbICAgIDMuOTM4NTg5XSAgIzE6 ICAoJl9fbG9ja2RlcF9ub192YWxpZGF0ZV9fKXsuLi4uLi59LCBhdDogWzxmZmZmZmZmZjgxMzE3 NmRlPl0gX19kcml2ZXJfYXR0YWNoKzB4NDkvMHg4MgpbICAgIDMuOTM4NjQwXSAgIzI6ICAoaXJx X21hcHBpbmdfdXBkYXRlX2xvY2speysuKy4rLn0sIGF0OiBbPGZmZmZmZmZmODEyZGE2ZTY+XSB4 ZW5fYmluZF9waXJxX21zaV90b19pcnErMHgzMS8weGRhClsgICAgMy45Mzg2OTZdIE1vZHVsZXMg bGlua2VkIGluOgpbICAgIDMuOTM4NzIwXSBQaWQ6IDEsIGNvbW06IHN3YXBwZXIgTm90IHRhaW50 ZWQgMy4xLjAtMC5yYzYuZ2l0MC4wLmZjMTcueDg2XzY0ICMxClsgICAgMy45Mzg3NDldIENhbGwg VHJhY2U6ClsgICAgMy45Mzg3NjhdICBbPGZmZmZmZmZmODE0ZjllNDQ+XSBfX3NjaGVkdWxlX2J1 ZysweDc1LzB4N2EKWyAgICAzLjkzODc5Ml0gIFs8ZmZmZmZmZmY4MTUwMjEwZD5dIF9fc2NoZWR1 bGUrMHg5NS8weDc2MQpbICAgIDMuOTM4ODE4XSAgWzxmZmZmZmZmZjgxMDA3NzQ2Pl0gPyB4ZW5f Zm9yY2VfZXZ0Y2huX2NhbGxiYWNrKzB4ZC8weGYKWyAgICAzLjkzODg0Nl0gIFs8ZmZmZmZmZmY4 MTAwNzc0Nj5dID8geGVuX2ZvcmNlX2V2dGNobl9jYWxsYmFjaysweGQvMHhmClsgICAgMy45Mzg4 NzZdICBbPGZmZmZmZmZmODEwNTZjMjg+XSBfX2NvbmRfcmVzY2hlZCsweDI4LzB4MzQKWyAgICAz LjkzODg5OV0gIFs8ZmZmZmZmZmY4MTUwMjgzNT5dIF9jb25kX3Jlc2NoZWQrMHgxOS8weDIyCgpb ICAgIDMuOTM4OTIzXSAgWzxmZmZmZmZmZjgxNTAzNWY3Pl0gbXV0ZXhfbG9ja19uZXN0ZWQrMHgy YS8weDQ1ClsgICAgMy45Mzg5NTFdICBbPGZmZmZmZmZmODE0ZTEzY2Q+XSBfX2lycV9hbGxvY19k ZXNjcysweDUwLzB4MThiClsgICAgMy45Mzg5ODBdICBbPGZmZmZmZmZmODEyZDAyZTY+XSA/IGdo ZXNfcHJvY19pbl9pcnErMHg1Yi8weGE1ClsgICAgMy45MzkwMDhdICBbPGZmZmZmZmZmODEyZDlj MGU+XSB4ZW5fYWxsb2NhdGVfaXJxX2R5bmFtaWMrMHg0OS8weDU4ClsgICAgMy45MzkwMzVdICBb PGZmZmZmZmZmODEyZGE2ZWI+XSB4ZW5fYmluZF9waXJxX21zaV90b19pcnErMHgzNi8weGRhClsg ICAgMy45MzkxMTFdICBbPGZmZmZmZmZmODE0MDAxZTM+XSB4ZW5faW5pdGRvbV9zZXR1cF9tc2lf aXJxcysweDEyOS8weDE1ZApbICAgIDMuOTM5MTQyXSAgWzxmZmZmZmZmZjgxMjdkMjE4Pl0gcGNp X2VuYWJsZV9tc2lfYmxvY2srMHgxYzAvMHgyMjUKWyAgICAzLjkzOTE3MV0gIFs8ZmZmZmZmZmY4 MTI3NDA5MT5dIHBjaWVfcG9ydF9kZXZpY2VfcmVnaXN0ZXIrMHgzMDgvMHg0NjQKWyAgICAzLjkz OTE5OV0gIFs8ZmZmZmZmZmY4MTUwNGU3Nz5dID8gX3Jhd19zcGluX3VubG9ja19pcnFyZXN0b3Jl KzB4NDUvMHg2MQpbICAgIDMuOTM5MjI4XSAgWzxmZmZmZmZmZjgxMDhmNGZmPl0gPyB0cmFjZV9o YXJkaXJxc19vbl9jYWxsZXIrMHgxMjEvMHgxNTgKWyAgICAzLjkzOTI1Nl0gIFs8ZmZmZmZmZmY4 MTRlNmE1Yj5dIHBjaWVfcG9ydGRydl9wcm9iZSsweDU3LzB4NmUKWyAgICAzLjkzOTI4M10gIFs8 ZmZmZmZmZmY4MTI2ZDA0Mz5dIGxvY2FsX3BjaV9wcm9iZSsweDQ0LzB4NzUKWyAgICAzLjkzOTMw Nl0gIFs8ZmZmZmZmZmY4MTI2ZGJjOT5dIHBjaV9kZXZpY2VfcHJvYmUrMHhkMC8weGZmClsgICAg My45MzkzMzRdICBbPGZmZmZmZmZmODEzMTc1YjM+XSBkcml2ZXJfcHJvYmVfZGV2aWNlKzB4MTMx LzB4MjEzClsgICAgMy45MzkzNjFdICBbPGZmZmZmZmZmODEzMTc2ZjM+XSBfX2RyaXZlcl9hdHRh Y2grMHg1ZS8weDgyClsgICAgMy45MzkzODRdICBbPGZmZmZmZmZmODEzMTc2OTU+XSA/IGRyaXZl cl9wcm9iZV9kZXZpY2UrMHgyMTMvMHgyMTMKWyAgICAzLjkzOTQxMl0gIFs8ZmZmZmZmZmY4MTMx NjVmND5dIGJ1c19mb3JfZWFjaF9kZXYrMHg1OS8weDhmClsgICAgMy45Mzk0MzldICBbPGZmZmZm ZmZmODEzMTcxODc+XSBkcml2ZXJfYXR0YWNoKzB4MWUvMHgyMApbICAgIDMuOTM5NDYxXSAgWzxm ZmZmZmZmZjgxMzE2ZDlmPl0gYnVzX2FkZF9kcml2ZXIrMHhkNC8weDIyYQpbICAgIDMuOTM5NDYx XSAgWzxmZmZmZmZmZjgxZDgwNzQzPl0gPyBkbWlfcGNpZV9wbWVfZGlzYWJsZV9tc2krMHgyMS8w eDIxClsgICAgMy45Mzk0NjFdICBbPGZmZmZmZmZmODEzMTdiYjY+XSBkcml2ZXJfcmVnaXN0ZXIr MHg5OC8weDEwNQpbICAgIDMuOTM5NDYxXSAgWzxmZmZmZmZmZjgxZDgwNzQzPl0gPyBkbWlfcGNp ZV9wbWVfZGlzYWJsZV9tc2krMHgyMS8weDIxClsgICAgMy45Mzk0NjFdICBbPGZmZmZmZmZmODFk ODA3NDM+XSA/IGRtaV9wY2llX3BtZV9kaXNhYmxlX21zaSsweDIxLzB4MjEKWyAgICAzLjkzOTQ2 MV0gIFs8ZmZmZmZmZmY4MWQ4MDdhOT5dIHBjaWVfcG9ydGRydl9pbml0KzB4NjYvMHg3NwpbICAg IDMuOTM5NDYxXSAgWzxmZmZmZmZmZjgxMDAyMDcxPl0gZG9fb25lX2luaXRjYWxsKzB4NTcvMHgx M2EKWyAgICAzLjkzOTQ2MV0gIFs8ZmZmZmZmZmY4MWQ1M2M4Yj5dIGtlcm5lbF9pbml0KzB4ZGYv MHgxNTkKWyAgICAzLjkzOTQ2MV0gIFs8ZmZmZmZmZmY4MTUwZGU4ND5dIGtlcm5lbF90aHJlYWRf aGVscGVyKzB4NC8weDEwClsgICAgMy45Mzk0NjFdICBbPGZmZmZmZmZmODE1MDUyZjQ+XSA/IHJl dGludF9yZXN0b3JlX2FyZ3MrMHgxMy8weDEzClsgICAgMy45Mzk0NjFdICBbPGZmZmZmZmZmODE1 MGRlODA+XSA/IGdzX2NoYW5nZSsweDEzLzB4MTMKWyAgICAzLjk0MDkxNV0gcGNpZXBvcnQgMDAw MDowMDoxYy4zOiBzZXR0aW5nIGxhdGVuY3kgdGltZXIgdG8gNjQKWyAgICAzLjk0MjMzOV0gaW5p dGNhbGwgcGNpZV9wb3J0ZHJ2X2luaXQrMHgwLzB4NzcgcmV0dXJuZWQgMCBhZnRlciA0NjU4IHVz ZWNzClsgICAgMy45NDIzNjldIGNhbGxpbmcgIGFlcl9zZXJ2aWNlX2luaXQrMHgwLzB4MzMgQCAx ClsgICAgMy45NDI2MDFdIGluaXRjYWxsIGFlcl9zZXJ2aWNlX2luaXQrMHgwLzB4MzMgcmV0dXJu ZWQgMCBhZnRlciAyMDMgdXNlY3MKWyAgICAzLjk0MjYyOV0gY2FsbGluZyAgcGNpZV9wbWVfc2Vy dmljZV9pbml0KzB4MC8weDEyIEAgMQpbICAgIDMuOTQyODcwXSBpbml0Y2FsbCBwY2llX3BtZV9z ZXJ2aWNlX2luaXQrMHgwLzB4MTIgcmV0dXJuZWQgMCBhZnRlciAyMTIgdXNlY3MKWyAgICAzLjk0 MjkwMl0gY2FsbGluZyAgaW9hcGljX2luaXQrMHgwLzB4MWIgQCAxClsgICAgMy45NDMzMjFdIGlu aXRjYWxsIGlvYXBpY19pbml0KzB4MC8weDFiIHJldHVybmVkIDAgYWZ0ZXIgMzQzIHVzZWNzClsg ICAgMy45NDMzNDldIGNhbGxpbmcgIHBjaV9ob3RwbHVnX2luaXQrMHgwLzB4MWQgQCAxClsgICAg My45NDMzNzBdIHBjaV9ob3RwbHVnOiBQQ0kgSG90IFBsdWcgUENJIENvcmUgdmVyc2lvbjogMC41 ClsgICAgMy45NDMzOTJdIGluaXRjYWxsIHBjaV9ob3RwbHVnX2luaXQrMHgwLzB4MWQgcmV0dXJu ZWQgMCBhZnRlciAyMCB1c2VjcwpbICAgIDMuOTQzNDE4XSBjYWxsaW5nICBwY2llZF9pbml0KzB4 MC8weGZmIEAgMQpbICAgIDMuOTQ0MDY2XSBwY2llaHA6IFBDSSBFeHByZXNzIEhvdCBQbHVnIENv bnRyb2xsZXIgRHJpdmVyIHZlcnNpb246IDAuNApbICAgIDMuOTQ0MDY2XSBpbml0Y2FsbCBwY2ll ZF9pbml0KzB4MC8weGZmIHJldHVybmVkIDAgYWZ0ZXIgNzkwIHVzZWNzClsgICAgMy45NDQwNjZd IGNhbGxpbmcgIGFjcGlwaHBfaW5pdCsweDAvMHg1YyBAIDEKWyAgICAzLjk0NDA2Nl0gYWNwaXBo cDogQUNQSSBIb3QgUGx1ZyBQQ0kgQ29udHJvbGxlciBEcml2ZXIgdmVyc2lvbjogMC41ClsgICAg My45NTU1NzhdIGFjcGlwaHA6IFNsb3QgWzFdIHJlZ2lzdGVyZWQKWyAgICAzLjk1NjIzMl0gaW5p dGNhbGwgYWNwaXBocF9pbml0KzB4MC8weDVjIHJldHVybmVkIDAgYWZ0ZXIgMTE3NTUgdXNlY3MK WyAgICAzLjk1NjIzMl0gY2FsbGluZyAgcGNpX3N0dWJfaW5pdCsweDAvMHgxNDAgQCAxClsgICAg My45NTYyMzJdIGluaXRjYWxsIHBjaV9zdHViX2luaXQrMHgwLzB4MTQwIHJldHVybmVkIDAgYWZ0 ZXIgMjc3IHVzZWNzClsgICAgMy45NTYyMzJdIGNhbGxpbmcgIGZiX2NvbnNvbGVfaW5pdCsweDAv MHgxMWMgQCAxClsgICAgMy45NTc1MzNdIGluaXRjYWxsIGZiX2NvbnNvbGVfaW5pdCsweDAvMHgx MWMgcmV0dXJuZWQgMCBhZnRlciA3ODkgdXNlY3MKWyAgICAzLjk1NzU2Ml0gY2FsbGluZyAgeGVu ZmJfaW5pdCsweDAvMHg1MSBAIDEKWyAgICAzLjk1NzU4NV0gaW5pdGNhbGwgeGVuZmJfaW5pdCsw eDAvMHg1MSByZXR1cm5lZCAtMTkgYWZ0ZXIgMCB1c2VjcwpbICAgIDMuOTU3NjExXSBjYWxsaW5n ICB2ZXNhZmJfaW5pdCsweDAvMHgyNDcgQCAxClsgICAgMy45NTkxNzRdIGluaXRjYWxsIHZlc2Fm Yl9pbml0KzB4MC8weDI0NyByZXR1cm5lZCAtMTkgYWZ0ZXIgMTcxMiB1c2VjcwpbICAgIDMuOTU5 MTc0XSBjYWxsaW5nICBlZmlmYl9pbml0KzB4MC8weDFmYiBAIDEKWyAgICAzLjk1OTE3NF0gaW5p dGNhbGwgZWZpZmJfaW5pdCsweDAvMHgxZmIgcmV0dXJuZWQgLTE5IGFmdGVyIDcgdXNlY3MKWyAg ICAzLjk1OTE3NF0gY2FsbGluZyAgaW50ZWxfaWRsZV9pbml0KzB4MC8weDM4NiBAIDEKWyAgICAz Ljk1OTE3NF0gaW5pdGNhbGwgaW50ZWxfaWRsZV9pbml0KzB4MC8weDM4NiByZXR1cm5lZCAtMTkg YWZ0ZXIgMCB1c2VjcwpbICAgIDMuOTU5MTc0XSBjYWxsaW5nICBhY3BpX3Jlc2VydmVfcmVzb3Vy Y2VzKzB4MC8weGViIEAgMQpbICAgIDMuOTU5MTc0XSBpbml0Y2FsbCBhY3BpX3Jlc2VydmVfcmVz b3VyY2VzKzB4MC8weGViIHJldHVybmVkIDAgYWZ0ZXIgNTYgdXNlY3MKWyAgICAzLjk1OTE3NF0g Y2FsbGluZyAgaXJxcm91dGVyX2luaXRfb3BzKzB4MC8weDI2IEAgMQpbICAgIDMuOTU5MTc0XSBp bml0Y2FsbCBpcnFyb3V0ZXJfaW5pdF9vcHMrMHgwLzB4MjYgcmV0dXJuZWQgMCBhZnRlciAzIHVz ZWNzClsgICAgMy45NTkxNzRdIGNhbGxpbmcgIGFjcGlfYWNfaW5pdCsweDAvMHg1MCBAIDEKWyAg ICAzLjk2MzQ0MF0gQUNQSTogRGVwcmVjYXRlZCBwcm9jZnMgSS9GIGZvciBBQyBpcyBsb2FkZWQs IHBsZWFzZSByZXRyeSB3aXRoIENPTkZJR19BQ1BJX1BST0NGU19QT1dFUiBjbGVhcmVkClsgICAg My45NjgyNTBdIEFDUEk6IEFDIEFkYXB0ZXIgW0FDXSAob24tbGluZSkKWyAgICAzLjk2OTc3MV0g aW5pdGNhbGwgYWNwaV9hY19pbml0KzB4MC8weDUwIHJldHVybmVkIDAgYWZ0ZXIgOTgyNSB1c2Vj cwpbICAgIDMuOTY5ODAyXSBjYWxsaW5nICBhY3BpX2J1dHRvbl9pbml0KzB4MC8weDEyIEAgMQpb ICAgIDMuOTcxNTY5XSBpbnB1dDogTGlkIFN3aXRjaCBhcyAvZGV2aWNlcy9MTlhTWVNUTTowMC9k ZXZpY2U6MDAvUE5QMEMwRDowMC9pbnB1dC9pbnB1dDAKWyAgICAzLjk3NjM3MF0gQUNQSTogTGlk IFN3aXRjaCBbTElEXQpbICAgIDMuOTc3ODc2XSBpbnB1dDogUG93ZXIgQnV0dG9uIGFzIC9kZXZp Y2VzL0xOWFNZU1RNOjAwL2RldmljZTowMC9QTlAwQzBDOjAwL2lucHV0L2lucHV0MQpbICAgIDMu OTc4MDEwXSBBQ1BJOiBQb3dlciBCdXR0b24gW1BCVE5dClsgICAgMy45NzkxMDNdIGlucHV0OiBT bGVlcCBCdXR0b24gYXMgL2RldmljZXMvTE5YU1lTVE06MDAvZGV2aWNlOjAwL1BOUDBDMEU6MDAv aW5wdXQvaW5wdXQyClsgICAgMy45NzkxMDNdIEFDUEk6IFNsZWVwIEJ1dHRvbiBbU0JUTl0KWyAg ICAzLjk3OTcyNV0gaW5pdGNhbGwgYWNwaV9idXR0b25faW5pdCsweDAvMHgxMiByZXR1cm5lZCAw IGFmdGVyIDk2NjYgdXNlY3MKWyAgICAzLjk4MDE1N10gaW5pdGNhbGwgYWNwaV9mYW5faW5pdCsw eDAvMHgxOCByZXR1cm5lZCAwIGFmdGVyIDM3MiB1c2VjcwpbICAgIDMuOTgwMTg1XSBjYWxsaW5n ICBhY3BpX3BjaV9zbG90X2luaXQrMHgwLzB4MjAgQCAxClsgICAgMy45ODA1NzJdIGluaXRjYWxs IGFjcGlfcGNpX3Nsb3RfaW5pdCsweDAvMHgyMCByZXR1cm5lZCAwIGFmdGVyIDc5NTMgdXNlY3MK WyAgICAzLjk4MDU3Ml0gY2FsbGluZyAgYWNwaV9wcm9jZXNzb3JfaW5pdCsweDAvMHhjZCBAIDEK WyAgICAzLjk4MDU3Ml0gQUNQSTogYWNwaV9pZGxlIHlpZWxkaW5nIHRvIChudWxsKQpbICAgIDMu OTkyMTQ2XSBpbml0Y2FsbCBhY3BpX3Byb2Nlc3Nvcl9pbml0KzB4MC8weGNkIHJldHVybmVkIDAg YWZ0ZXIgMzY0OSB1c2VjcwpbICAgIDMuOTkyMTU2XSBjYWxsaW5nICBhY3BpX2NvbnRhaW5lcl9p bml0KzB4MC8weDRhIEAgMQpbICAgIDQuMDY0MTMxXSBpbml0Y2FsbCBhY3BpX2NvbnRhaW5lcl9p bml0KzB4MC8weDRhIHJldHVybmVkIDAgYWZ0ZXIgODc2MDcgdXNlY3MKWyAgICA0LjA2NDEzMV0g Y2FsbGluZyAgYWNwaV90aGVybWFsX2luaXQrMHgwLzB4NDIgQCAxClsgICAgNC4xNjEwODJdIHRo ZXJtYWwgTE5YVEhFUk06MDA6IHJlZ2lzdGVyZWQgYXMgdGhlcm1hbF96b25lMApbICAgIDQuMTYx MDgyXSBBQ1BJOiBUaGVybWFsIFpvbmUgW1RITV0gKDczIEMpClsgICAgNC4xNjY3NzVdIGluaXRj YWxsIGFjcGlfdGhlcm1hbF9pbml0KzB4MC8weDQyIHJldHVybmVkIDAgYWZ0ZXIgODI4MTQgdXNl Y3MKWyAgICA0LjE2NjgwN10gY2FsbGluZyAgYWNwaV9iYXR0ZXJ5X2luaXQrMHgwLzB4MTYgQCAx ClsgICAgNC4xNjY4OTBdIGluaXRjYWxsIGFjcGlfYmF0dGVyeV9pbml0KzB4MC8weDE2IHJldHVy bmVkIDAgYWZ0ZXIgNTggdXNlY3MKWyAgICA0LjE2NjkxN10gY2FsbGluZyAgYWNwaV9oZWRfaW5p dCsweDAvMHgyNiBAIDEKWyAgICA0LjE2NzM3MV0gaW5pdGNhbGwgYWNwaV9oZWRfaW5pdCsweDAv MHgyNiByZXR1cm5lZCAwIGFmdGVyIDQyMCB1c2VjcwpbICAgIDQuMTY3Mzk5XSBjYWxsaW5nICBl cnN0X2luaXQrMHgwLzB4MjlhIEAgMQpbICAgIDQuMTY3NDIxXSBFUlNUOiBUYWJsZSBpcyBub3Qg Zm91bmQhClsgICAgNC4xNjc0MjldIGNhbGxpbmcgIDFfYWNwaV9iYXR0ZXJ5X2luaXRfYXN5bmMr MHgwLzB4M2MgQCA1ClsgICAgNC4xNjc0NTZdIGluaXRjYWxsIGVyc3RfaW5pdCsweDAvMHgyOWEg cmV0dXJuZWQgMCBhZnRlciAzNCB1c2VjcwpbICAgIDQuMTY3NDgyXSBjYWxsaW5nICBnaGVzX2lu aXQrMHgwLzB4MTU0IEAgMQpbICAgIDQuMTY3NTA0XSBHSEVTOiBIRVNUIGlzIG5vdCBlbmFibGVk IQpbICAgIDQuMTY3NTIyXSBpbml0Y2FsbCBnaGVzX2luaXQrMHgwLzB4MTU0IHJldHVybmVkIC0y MiBhZnRlciAxNiB1c2VjcwpbICAgIDQuMTY3NTQ4XSBpbml0Y2FsbCBnaGVzX2luaXQrMHgwLzB4 MTU0IHJldHVybmVkIHdpdGggZXJyb3IgY29kZSAtMjIKWyAgICA0LjE2NzU3NF0gY2FsbGluZyAg dmlydGlvX3BjaV9pbml0KzB4MC8weDFiIEAgMQpbICAgIDQuMTY4MTIwXSBpbml0Y2FsbCB2aXJ0 aW9fcGNpX2luaXQrMHgwLzB4MWIgcmV0dXJuZWQgMCBhZnRlciA1MTAgdXNlY3MKWyAgICA0LjE2 ODE0OV0gY2FsbGluZyAgeGVuYnVzX3Byb2JlX2luaXRjYWxsKzB4MC8weDM5IEAgMQpbICAgIDQu MTY4MTczXSBpbml0Y2FsbCB4ZW5idXNfcHJvYmVfaW5pdGNhbGwrMHgwLzB4MzkgcmV0dXJuZWQg MCBhZnRlciAwIHVzZWNzClsgICAgNC4xNjgyMDRdIGNhbGxpbmcgIGh5cGVydmlzb3Jfc3Vic3lz X2luaXQrMHgwLzB4MjUgQCAxClsgICAgNC4xNjgyMjddIGluaXRjYWxsIGh5cGVydmlzb3Jfc3Vi c3lzX2luaXQrMHgwLzB4MjUgcmV0dXJuZWQgMCBhZnRlciAwIHVzZWNzClsgICAgNC4xNjgyNTdd IGNhbGxpbmcgIGh5cGVyX3N5c2ZzX2luaXQrMHgwLzB4ZmIgQCAxClsgICAgNC4xNjg1NTVdIGlu aXRjYWxsIGh5cGVyX3N5c2ZzX2luaXQrMHgwLzB4ZmIgcmV0dXJuZWQgMCBhZnRlciAyNjggdXNl Y3MKWyAgICA0LjE2ODU4Ml0gY2FsbGluZyAgeGVuX3RtZW1faW5pdCsweDAvMHg1YyBAIDEKWyAg ICA0LjE2ODYwNV0gaW5pdGNhbGwgeGVuX3RtZW1faW5pdCsweDAvMHg1YyByZXR1cm5lZCAwIGFm dGVyIDAgdXNlY3MKWyAgICA0LjE2ODYzMF0gY2FsbGluZyAgcHR5X2luaXQrMHgwLzB4MjZhIEAg MQpbICAgIDQuMTY5NjY1XSBpbml0Y2FsbCBwdHlfaW5pdCsweDAvMHgyNmEgcmV0dXJuZWQgMCBh ZnRlciA5OTEgdXNlY3MKWyAgICA0LjE2OTY5NV0gY2FsbGluZyAgc3lzcnFfaW5pdCsweDAvMHg0 NCBAIDEKWyAgICA0LjE2OTc3Nl0gaW5pdGNhbGwgc3lzcnFfaW5pdCsweDAvMHg0NCByZXR1cm5l ZCAwIGFmdGVyIDU3IHVzZWNzClsgICAgNC4xNjk4MDNdIGNhbGxpbmcgIHhlbl9odmNfaW5pdCsw eDAvMHhjZiBAIDEKWyAgICA0LjE3Njc0NF0gaW5pdGNhbGwgeGVuX2h2Y19pbml0KzB4MC8weGNm IHJldHVybmVkIDAgYWZ0ZXIgNjc1NCB1c2VjcwpbICAgIDQuMTc2Nzc2XSBjYWxsaW5nICBzZXJp YWw4MjUwX2luaXQrMHgwLzB4MTg4IEAgMQpbICAgIDQuMTc2Nzk4XSBTZXJpYWw6IDgyNTAvMTY1 NTAgZHJpdmVyLCA0IHBvcnRzLCBJUlEgc2hhcmluZyBlbmFibGVkClsgICAgNC4yMTc0NDZdIGlu aXRjYWxsIHNlcmlhbDgyNTBfaW5pdCsweDAvMHgxODggcmV0dXJuZWQgMCBhZnRlciAzOTY5MSB1 c2VjcwpbICAgIDQuMjE3NDc4XSBjYWxsaW5nICBzZXJpYWw4MjUwX3BucF9pbml0KzB4MC8weDEy IEAgMQpbICAgIDQuMjE3ODk0XSBpbml0Y2FsbCBzZXJpYWw4MjUwX3BucF9pbml0KzB4MC8weDEy IHJldHVybmVkIDAgYWZ0ZXIgMzgzIHVzZWNzClsgICAgNC4yMTc5MjZdIGNhbGxpbmcgIHNlcmlh bDgyNTBfcGNpX2luaXQrMHgwLzB4MWIgQCAxClsgICAgNC4yMTgyNjRdIHhlbjogcmVnaXN0ZXJp bmcgZ3NpIDE5IHRyaWdnZXJpbmcgMCBwb2xhcml0eSAxClsgICAgNC4yMTgyOTZdIHhlbl9tYXBf cGlycV9nc2k6IHJldHVybmluZyBpcnEgMTkgZm9yIGdzaSAxOQpbICAgIDQuMjE4MzE5XSB4ZW46 IC0tPiBwaXJxPTE5IC0+IGlycT0xOSAoZ3NpPTE5KQpbICAgIDQuMjE4MzQwXSBBbHJlYWR5IHNl dHVwIHRoZSBHU0kgOjE5ClsgICAgNC4yMTgzNTldIHNlcmlhbCAwMDAwOjBjOjAwLjA6IFBDSSBJ TlQgQSAtPiBHU0kgMTkgKGxldmVsLCBsb3cpIC0+IElSUSAxOQpbICAgIDQuMjU5NTA1XSBpbml0 Y2FsbCBzZXJpYWw4MjUwX3BjaV9pbml0KzB4MC8weDFiIHJldHVybmVkIDAgYWZ0ZXIgNDA1Nzkg dXNlY3MKWyAgICA0LjI1OTU0MV0gY2FsbGluZyAgaW5pdF9rZ2Rib2MrMHgwLzB4MTYgQCAxClsg ICAgNC4yNTk2MDddIGluaXRjYWxsIGluaXRfa2dkYm9jKzB4MC8weDE2IHJldHVybmVkIDAgYWZ0 ZXIgNDEgdXNlY3MKWyAgICA0LjI1OTYzNl0gY2FsbGluZyAgcmFuZF9pbml0aWFsaXplKzB4MC8w eDMxIEAgMQpbICAgIDQuMjU5NzA2XSBpbml0Y2FsbCByYW5kX2luaXRpYWxpemUrMHgwLzB4MzEg cmV0dXJuZWQgMCBhZnRlciA0NSB1c2VjcwpbICAgIDQuMjU5NzMzXSBjYWxsaW5nICBpbml0KzB4 MC8weGE2IEAgMQpbICAgIDQuMjYwMDY3XSBjYWxsaW5nICByYXdfaW5pdCsweDAvMHgxNTggQCAx ClsgICAgNC4yNjE3ODldIGluaXRjYWxsIHJhd19pbml0KzB4MC8weDE1OCByZXR1cm5lZCAwIGFm dGVyIDE1MDUgdXNlY3MKWyAgICA0LjI2MTgxOV0gY2FsbGluZyAgaHBldF9pbml0KzB4MC8weDY3 IEAgMQpbICAgIDQuNzEwNzEyXSBocGV0X2FjcGlfYWRkOiBubyBhZGRyZXNzIG9yIGlycXMgaW4g X0NSUwpbICAgIDQuNzExMTA5XSBpbml0Y2FsbCBocGV0X2luaXQrMHgwLzB4NjcgcmV0dXJuZWQg MCBhZnRlciA0Mzg3MzkgdXNlY3MKWyAgICA0LjcxMTEzN10gY2FsbGluZyAgbnZyYW1faW5pdCsw eDAvMHg4MCBAIDEKWyAgICA0LjcxMTk4Ml0gTm9uLXZvbGF0aWxlIG1lbW9yeSBkcml2ZXIgdjEu MwpbICAgIDQuNzEyMDA0XSBpbml0Y2FsbCBudnJhbV9pbml0KzB4MC8weDgwIHJldHVybmVkIDAg YWZ0ZXIgODI0IHVzZWNzClsgICAgNC43MTIwMzFdIGNhbGxpbmcgIGFncF9pbml0KzB4MC8weDI2 IEAgMQpbICAgIDQuNzEyMDQ5XSBMaW51eCBhZ3BnYXJ0IGludGVyZmFjZSB2MC4xMDMKWyAgICA0 LjcxMjA2OF0gaW5pdGNhbGwgYWdwX2luaXQrMHgwLzB4MjYgcmV0dXJuZWQgMCBhZnRlciAxNyB1 c2VjcwpbICAgIDQuNzEyMDk0XSBjYWxsaW5nICBhZ3BfYW1kNjRfbW9kX2luaXQrMHgwLzB4MjIg QCAxClsgICAgNC43MTI5MDldIGluaXRjYWxsIGFncF9hbWQ2NF9tb2RfaW5pdCsweDAvMHgyMiBy ZXR1cm5lZCAtMTkgYWZ0ZXIgNzcxIHVzZWNzClsgICAgNC43MTI5NDJdIGNhbGxpbmcgIGFncF9p bnRlbF9pbml0KzB4MC8weDI5IEAgMQpbICAgIDQuNzEzMjc2XSBhZ3BnYXJ0LWludGVsIDAwMDA6 MDA6MDAuMDogSW50ZWwgOTQ1R00gQ2hpcHNldApbICAgIDQuNzE5OTkzXSBhZ3BnYXJ0LWludGVs IDAwMDA6MDA6MDAuMDogZGV0ZWN0ZWQgZ3R0IHNpemU6IDI2MjE0NEsgdG90YWwsIDI2MjE0NEsg bWFwcGFibGUKWyAgICA0LjcyMTA2OF0gYWdwZ2FydC1pbnRlbCAwMDAwOjAwOjAwLjA6IGRldGVj dGVkIDgxOTJLIHN0b2xlbiBtZW1vcnkKWyAgICA0LjcyMzA2NV0gYWdwZ2FydC1pbnRlbCAwMDAw OjAwOjAwLjA6IEFHUCBhcGVydHVyZSBpcyAyNTZNIEAgMHhkMDAwMDAwMApbICAgIDQuNzIzNjgw XSBpbml0Y2FsbCBhZ3BfaW50ZWxfaW5pdCsweDAvMHgyOSByZXR1cm5lZCAwIGFmdGVyIDEwNDU5 IHVzZWNzClsgICAgNC43MjM3MTBdIGNhbGxpbmcgIGFncF9zaXNfaW5pdCsweDAvMHgyOSBAIDEK WyAgICA0LjcyNDA2NF0gaW5pdGNhbGwgYWdwX3Npc19pbml0KzB4MC8weDI5IHJldHVybmVkIDAg YWZ0ZXIgMzIzIHVzZWNzClsgICAgNC43MjQwOTJdIGNhbGxpbmcgIGFncF92aWFfaW5pdCsweDAv MHgyOSBAIDEKWyAgICA0LjcyNDQ0Nl0gaW5pdGNhbGwgYWdwX3ZpYV9pbml0KzB4MC8weDI5IHJl dHVybmVkIDAgYWZ0ZXIgMzc2IHVzZWNzClsgICAgNC43MjQ0NDZdIGNhbGxpbmcgIGluaXRfdGlz KzB4MC8weDk4IEAgMQpbICAgIDQuNzI0OTE0XSBpbml0Y2FsbCBpbml0X3RpcysweDAvMHg5OCBy ZXR1cm5lZCAwIGFmdGVyIDM1NyB1c2VjcwpbICAgIDQuNzI0OTQyXSBjYWxsaW5nICBjbl9wcm9j X2luaXQrMHgwLzB4M2EgQCAxClsgICAgNC43MjUwMDhdIGluaXRjYWxsIGNuX3Byb2NfaW5pdCsw eDAvMHgzYSByZXR1cm5lZCAwIGFmdGVyIDQyIHVzZWNzClsgICAgNC43MjUwMzhdIGNhbGxpbmcg IHRvcG9sb2d5X3N5c2ZzX2luaXQrMHgwLzB4NjAgQCAxClsgICAgNC43MjUzMjddIGluaXRjYWxs IHRvcG9sb2d5X3N5c2ZzX2luaXQrMHgwLzB4NjAgcmV0dXJuZWQgMCBhZnRlciAyNTcgdXNlY3MK WyAgICA0LjcyNTM1OV0gY2FsbGluZyAgbG9vcF9pbml0KzB4MC8weDEzMiBAIDEKWyAgICA0Ljc0 OTMwN10gbG9vcDogbW9kdWxlIGxvYWRlZApbICAgIDQuNzQ5MzM5XSBpbml0Y2FsbCBsb29wX2lu aXQrMHgwLzB4MTMyIHJldHVybmVkIDAgYWZ0ZXIgMjMzOTIgdXNlY3MKWyAgICA0Ljc0OTM2Nl0g Y2FsbGluZyAgaW5pdF9rZ2RidHMrMHgwLzB4MTYgQCAxClsgICAgNC43NDkzOTBdIGluaXRjYWxs IGluaXRfa2dkYnRzKzB4MC8weDE2IHJldHVybmVkIDAgYWZ0ZXIgMCB1c2VjcwpbICAgIDQuNzQ5 NDE2XSBjYWxsaW5nICBtYWNfaGlkX2luaXQrMHgwLzB4MjIgQCAxClsgICAgNC43NDk2MjBdIGlu aXRjYWxsIG1hY19oaWRfaW5pdCsweDAvMHgyMiByZXR1cm5lZCAwIGFmdGVyIDE3NiB1c2Vjcwpb ICAgIDQuNzQ5NjQ3XSBjYWxsaW5nICBzY3NpX2RoX2luaXQrMHgwLzB4NTMgQCAxClsgICAgNC43 NDk2ODhdIGluaXRjYWxsIHNjc2lfZGhfaW5pdCsweDAvMHg1MyByZXR1cm5lZCAwIGFmdGVyIDE3 IHVzZWNzClsgICAgNC43NDk3MTVdIGNhbGxpbmcgIGluaXRfc2QrMHgwLzB4MTMxIEAgMQpbICAg IDQuNzUyNDUzXSBpbml0Y2FsbCBpbml0X3NkKzB4MC8weDEzMSByZXR1cm5lZCAwIGFmdGVyIDI2 NTUgdXNlY3MKWyAgICA0Ljc1MjQ4M10gY2FsbGluZyAgaW5pdF9zcisweDAvMHg0NiBAIDEKWyAg ICA0Ljc1MjczMl0gaW5pdGNhbGwgaW5pdF9zcisweDAvMHg0NiByZXR1cm5lZCAwIGFmdGVyIDIy NCB1c2VjcwpbICAgIDQuNzUyNzYwXSBjYWxsaW5nICBpbml0X3NnKzB4MC8weDEyOSBAIDEKWyAg ICA0Ljc1MzM2NF0gaW5pdGNhbGwgaW5pdF9zZysweDAvMHgxMjkgcmV0dXJuZWQgMCBhZnRlciA1 NzAgdXNlY3MKWyAgICA0Ljc1MzM5M10gY2FsbGluZyAgYWhjaV9pbml0KzB4MC8weDFiIEAgMQpb ICAgIDQuNzUzOTI2XSBpbml0Y2FsbCBhaGNpX2luaXQrMHgwLzB4MWIgcmV0dXJuZWQgMCBhZnRl ciA1MDEgdXNlY3MKWyAgICA0Ljc1Mzk1NF0gY2FsbGluZyAgcGlpeF9pbml0KzB4MC8weDI5IEAg MQpbICAgIDQuNzU0MjAwXSBhdGFfcGlpeCAwMDAwOjAwOjFmLjI6IHZlcnNpb24gMi4xMwpbICAg IDQuNzU0MjgyXSB4ZW46IHJlZ2lzdGVyaW5nIGdzaSAxNyB0cmlnZ2VyaW5nIDAgcG9sYXJpdHkg MQpbICAgIDQuNzU0Mzg0XSB4ZW46IC0tPiBwaXJxPTE3IC0+IGlycT0xNyAoZ3NpPTE3KQpbICAg IDQuNzU0NDI5XSBhdGFfcGlpeCAwMDAwOjAwOjFmLjI6IFBDSSBJTlQgQiAtPiBHU0kgMTcgKGxl dmVsLCBsb3cpIC0+IElSUSAxNwpbICAgIDQuNzU0NDkxXSBhdGFfcGlpeCAwMDAwOjAwOjFmLjI6 IE1BUCBbIFAwIFAyIElERSBJREUgXQpbICAgIDQuNzU1MjAzXSBhdGFfcGlpeCAwMDAwOjAwOjFm LjI6IHNldHRpbmcgbGF0ZW5jeSB0aW1lciB0byA2NApbICAgIDQuNzY2ODMwXSBzY3NpMCA6IGF0 YV9waWl4ClsgICAgNC43NzExOTRdIHNjc2kxIDogYXRhX3BpaXgKWyAgICA0Ljg5NDE1NF0gQUNQ STogRGVwcmVjYXRlZCBwcm9jZnMgSS9GIGZvciBiYXR0ZXJ5IGlzIGxvYWRlZCwgcGxlYXNlIHJl dHJ5IHdpdGggQ09ORklHX0FDUElfUFJPQ0ZTX1BPV0VSIGNsZWFyZWQKWyAgICA0Ljg5NDQ2OF0g QUNQSTogQmF0dGVyeSBTbG90IFtCQVQwXSAoYmF0dGVyeSBwcmVzZW50KQo2NiB1c2VjcwpbICAg IDQuOTAxMDIwXSBhdGExOiBTQVRBIG1heCBVRE1BLzEzMyBjbWQgMHgxZjAgY3RsIDB4M2Y2IGJt ZG1hIDB4YmZhMCBpcnEgMTQKWyAgICA0LjkwMTAyMF0gYXRhMjogUEFUQSBtYXggVURNQS8xMDAg Y21kIDB4MTcwIGN0bCAweDM3NiBibWRtYSAweGJmYTggaXJxIDE1ClsgICAgNC45MjQ4OTJdIGNh bGxpbmcgIDJfYXN5bmNfcG9ydF9wcm9iZSsweDAvMHg0ZiBAIDUKWyAgICA0LjkyNTU0M10gY2Fs bGluZyAgM19hc3luY19wb3J0X3Byb2JlKzB4MC8weDRmIEAgMzgKWyAgICA0LjkyNTYxMl0gaW5p dGNhbGwgcGlpeF9pbml0KzB4MC8weDI5IHJldHVybmVkIDAgYWZ0ZXIgMTY3NjE0IHVzZWNzClsg ICAgNC45MjU2NDJdIGNhbGxpbmcgIGZpeGVkX21kaW9fYnVzX2luaXQrMHgwLzB4ZmMgQCAxClsg ICAgNC45MjcxMzJdIEZpeGVkIE1ESU8gQnVzOiBwcm9iZWQKWyAgICA0LjkyNzE1NV0gaW5pdGNh bGwgZml4ZWRfbWRpb19idXNfaW5pdCsweDAvMHhmYyByZXR1cm5lZCAwIGFmdGVyIDE0NTMgdXNl Y3MKWyAgICA0LjkyNzE2MF0gY2FsbGluZyAgbmV0X29sZGRldnNfaW5pdCsweDAvMHg5ZSBAIDEK WyAgICA0LjkyNzE2MF0gaW5pdGNhbGwgbmV0X29sZGRldnNfaW5pdCsweDAvMHg5ZSByZXR1cm5l ZCAwIGFmdGVyIDUgdXNlY3MKWyAgICA0LjkyNzE2MF0gY2FsbGluZyAgY2Ryb21faW5pdCsweDAv MHgxNiBAIDEKWyAgICA0LjkyNzE2MF0gaW5pdGNhbGwgY2Ryb21faW5pdCsweDAvMHgxNiByZXR1 cm5lZCAwIGFmdGVyIDIzMCB1c2VjcwpbICAgIDQuOTI3MTYwXSBjYWxsaW5nICBub25zdGF0aWNf c3lzZnNfaW5pdCsweDAvMHgxMiBAIDEKWyAgICA0LjkyNzE2MF0gaW5pdGNhbGwgbm9uc3RhdGlj X3N5c2ZzX2luaXQrMHgwLzB4MTIgcmV0dXJuZWQgMCBhZnRlciA1IHVzZWNzClsgICAgNC45Mjcx NjBdIGNhbGxpbmcgIG1vbl9pbml0KzB4MC8weDEwZSBAIDEKWyAgICA0LjkyODgzN10gaW5pdGNh bGwgbW9uX2luaXQrMHgwLzB4MTBlIHJldHVybmVkIDAgYWZ0ZXIgMTIwOSB1c2VjcwpbICAgIDQu OTI4ODY3XSBjYWxsaW5nICBlaGNpX2hjZF9pbml0KzB4MC8weGJlIEAgMQpbICAgIDQuOTI4ODg4 XSBlaGNpX2hjZDogVVNCIDIuMCAnRW5oYW5jZWQnIEhvc3QgQ29udHJvbGxlciAoRUhDSSkgRHJp dmVyClsgICAgNC45MjkwNjldIHhlbjogcmVnaXN0ZXJpbmcgZ3NpIDIwIHRyaWdnZXJpbmcgMCBw b2xhcml0eSAxClsgICAgNC45MjkyNjVdIHhlbjogLS0+IHBpcnE9MjAgLT4gaXJxPTIwIChnc2k9 MjApClsgICAgNC45MjkyOTVdIGVoY2lfaGNkIDAwMDA6MDA6MWQuNzogUENJIElOVCBBIC0+IEdT SSAyMCAobGV2ZWwsIGxvdykgLT4gSVJRIDIwClsgICAgNC45Mjk1MzFdIGVoY2lfaGNkIDAwMDA6 MDA6MWQuNzogc2V0dGluZyBsYXRlbmN5IHRpbWVyIHRvIDY0ClsgICAgNC45Mjk1OTNdIGVoY2lf aGNkIDAwMDA6MDA6MWQuNzogRUhDSSBIb3N0IENvbnRyb2xsZXIKWyAgICA0LjkzMjM1N10gZWhj aV9oY2QgMDAwMDowMDoxZC43OiBuZXcgVVNCIGJ1cyByZWdpc3RlcmVkLCBhc3NpZ25lZCBidXMg bnVtYmVyIDEKWyAgICA0LjkzMjkyNF0gZWhjaV9oY2QgMDAwMDowMDoxZC43OiB1c2luZyBicm9r ZW4gcGVyaW9kaWMgd29ya2Fyb3VuZApbICAgIDQuOTMyOTk1XSBlaGNpX2hjZCAwMDAwOjAwOjFk Ljc6IGRlYnVnIHBvcnQgMQpbICAgIDQuOTM2OTMwXSBlaGNpX2hjZCAwMDAwOjAwOjFkLjc6IGNh Y2hlIGxpbmUgc2l6ZSBvZiA2NCBpcyBub3Qgc3VwcG9ydGVkClsgICAgNC45MzcwNjVdIGVoY2lf aGNkIDAwMDA6MDA6MWQuNzogaXJxIDIwLCBpbyBtZW0gMHhmZmE4MDAwMApbICAgIDQuOTQ3MTQw XSBlaGNpX2hjZCAwMDAwOjAwOjFkLjc6IFVTQiAyLjAgc3RhcnRlZCwgRUhDSSAxLjAwClsgICAg NC45NDgxNzRdIHVzYiB1c2IxOiBOZXcgVVNCIGRldmljZSBmb3VuZCwgaWRWZW5kb3I9MWQ2Yiwg aWRQcm9kdWN0PTAwMDIKWyAgICA0Ljk0ODIwMl0gdXNiIHVzYjE6IE5ldyBVU0IgZGV2aWNlIHN0 cmluZ3M6IE1mcj0zLCBQcm9kdWN0PTIsIFNlcmlhbE51bWJlcj0xClsgICAgNC45NDgyMzJdIHVz YiB1c2IxOiBQcm9kdWN0OiBFSENJIEhvc3QgQ29udHJvbGxlcgpbICAgIDQuOTQ4MjUzXSB1c2Ig dXNiMTogTWFudWZhY3R1cmVyOiBMaW51eCAzLjEuMC0wLnJjNi5naXQwLjAuZmMxNy54ODZfNjQg ZWhjaV9oY2QKWyAgICA0Ljk0ODI4Ml0gdXNiIHVzYjE6IFNlcmlhbE51bWJlcjogMDAwMDowMDox ZC43ClsgICAgNC45NTIwNDddIGh1YiAxLTA6MS4wOiBVU0IgaHViIGZvdW5kClsgICAgNC45NTI0 MTJdIGh1YiAxLTA6MS4wOiA4IHBvcnRzIGRldGVjdGVkClsgICAgNC45NTYxNjVdIGluaXRjYWxs IGVoY2lfaGNkX2luaXQrMHgwLzB4YmUgcmV0dXJuZWQgMCBhZnRlciAyNjYzNCB1c2VjcwpbICAg IDQuOTU2MTk1XSBjYWxsaW5nICBvaGNpX2hjZF9tb2RfaW5pdCsweDAvMHg4NCBAIDEKWyAgICA0 Ljk1NjIxN10gb2hjaV9oY2Q6IFVTQiAxLjEgJ09wZW4nIEhvc3QgQ29udHJvbGxlciAoT0hDSSkg RHJpdmVyClsgICAgNC45NTY1NjldIGluaXRjYWxsIG9oY2lfaGNkX21vZF9pbml0KzB4MC8weDg0 IHJldHVybmVkIDAgYWZ0ZXIgMzQyIHVzZWNzClsgICAgNC45NTY1OThdIGNhbGxpbmcgIHVoY2lf aGNkX2luaXQrMHgwLzB4YzMgQCAxClsgICAgNC45NTY2MTldIHVoY2lfaGNkOiBVU0IgVW5pdmVy c2FsIEhvc3QgQ29udHJvbGxlciBJbnRlcmZhY2UgZHJpdmVyClsgICAgNC45NTc3MjddIHhlbjog cmVnaXN0ZXJpbmcgZ3NpIDIwIHRyaWdnZXJpbmcgMCBwb2xhcml0eSAxClsgICAgNC45NTc3NTZd IHhlbl9tYXBfcGlycV9nc2k6IHJldHVybmluZyBpcnEgMjAgZm9yIGdzaSAyMApbICAgIDQuOTU3 Nzc4XSB4ZW46IC0tPiBwaXJxPTIwIC0+IGlycT0yMCAoZ3NpPTIwKQpbICAgIDQuOTU3ODI4XSBB bHJlYWR5IHNldHVwIHRoZSBHU0kgOjIwClsgICAgNC45NTc4NDhdIHVoY2lfaGNkIDAwMDA6MDA6 MWQuMDogUENJIElOVCBBIC0+IEdTSSAyMCAobGV2ZWwsIGxvdykgLT4gSVJRIDIwClsgICAgNC45 NTc5NjBdIHVoY2lfaGNkIDAwMDA6MDA6MWQuMDogc2V0dGluZyBsYXRlbmN5IHRpbWVyIHRvIDY0 ClsgICAgNC45NTc5OTNdIHVoY2lfaGNkIDAwMDA6MDA6MWQuMDogVUhDSSBIb3N0IENvbnRyb2xs ZXIKWyAgICA0Ljk1OTQ3N10gdWhjaV9oY2QgMDAwMDowMDoxZC4wOiBuZXcgVVNCIGJ1cyByZWdp c3RlcmVkLCBhc3NpZ25lZCBidXMgbnVtYmVyIDIKWyAgICA0Ljk1OTc1MV0gdWhjaV9oY2QgMDAw MDowMDoxZC4wOiBpcnEgMjAsIGlvIGJhc2UgMHgwMDAwYmY4MApbICAgIDQuOTYwODY5XSB1c2Ig dXNiMjogTmV3IFVTQiBkZXZpY2UgZm91bmQsIGlkVmVuZG9yPTFkNmIsIGlkUHJvZHVjdD0wMDAx ClsgICAgNC45NjA4OThdIHVzYiB1c2IyOiBOZXcgVVNCIGRldmljZSBzdHJpbmdzOiBNZnI9Mywg UHJvZHVjdD0yLCBTZXJpYWxOdW1iZXI9MQpbICAgIDQuOTYwOTQ4XSB1c2IgdXNiMjogTWFudWZh Y3R1cmVyOiBMaW51eCAzLjEuMC0wLnJjNi5naXQwLjAuZmMxNy54ODZfNjQgdWhjaV9oY2QKWyAg ICA0Ljk2MDk3N10gdXNiIHVzYjI6IFNlcmlhbE51bWJlcjogMDAwMDowMDoxZC4wClsgICAgNC45 NjM5OTRdIGh1YiAyLTA6MS4wOiBVU0IgaHViIGZvdW5kClsgICAgNC45NjQzMTBdIGh1YiAyLTA6 MS4wOiAyIHBvcnRzIGRldGVjdGVkClsgICAgNC45NjcwOTZdIHhlbjogcmVnaXN0ZXJpbmcgZ3Np IDIxIHRyaWdnZXJpbmcgMCBwb2xhcml0eSAxClsgICAgNC45NjcyMjBdIHhlbjogLS0+IHBpcnE9 MjEgLT4gaXJxPTIxIChnc2k9MjEpClsgICAgNC45NjcyNDddIHVoY2lfaGNkIDAwMDA6MDA6MWQu MTogUENJIElOVCBCIC0+IEdTSSAyMSAobGV2ZWwsIGxvdykgLT4gSVJRIDIxClsgICAgNC45Njcz NzJdIHVoY2lfaGNkIDAwMDA6MDA6MWQuMTogc2V0dGluZyBsYXRlbmN5IHRpbWVyIHRvIDY0Clsg ICAgNC45Njc0MDVdIHVoY2lfaGNkIDAwMDA6MDA6MWQuMTogVUhDSSBIb3N0IENvbnRyb2xsZXIK WyAgICA0Ljk2ODg3NF0gdWhjaV9oY2QgMDAwMDowMDoxZC4xOiBuZXcgVVNCIGJ1cyByZWdpc3Rl cmVkLCBhc3NpZ25lZCBidXMgbnVtYmVyIDMKWyAgICA0Ljk2OTU4OV0gdWhjaV9oY2QgMDAwMDow MDoxZC4xOiBpcnEgMjEsIGlvIGJhc2UgMHgwMDAwYmY2MApbICAgIDQuOTcwNjYyXSB1c2IgdXNi MzogTmV3IFVTQiBkZXZpY2UgZm91bmQsIGlkVmVuZG9yPTFkNmIsIGlkUHJvZHVjdD0wMDAxClsg ICAgNC45NzA2OTBdIHVzYiB1c2IzOiBOZXcgVVNCIGRldmljZSBzdHJpbmdzOiBNZnI9MywgUHJv ZHVjdD0yLCBTZXJpYWxOdW1iZXI9MQpbICAgIDQuOTcwNzIwXSB1c2IgdXNiMzogUHJvZHVjdDog VUhDSSBIb3N0IENvbnRyb2xsZXIKWyAgICA0Ljk3MDc0MV0gdXNiIHVzYjM6IE1hbnVmYWN0dXJl cjogTGludXggMy4xLjAtMC5yYzYuZ2l0MC4wLmZjMTcueDg2XzY0IHVoY2lfaGNkClsgICAgNC45 NzA3NzBdIHVzYiB1c2IzOiBTZXJpYWxOdW1iZXI6IDAwMDA6MDA6MWQuMQpbICAgIDQuOTc0NDAx XSBodWIgMy0wOjEuMDogVVNCIGh1YiBmb3VuZApbICAgIDQuOTc0NjUzXSBodWIgMy0wOjEuMDog MiBwb3J0cyBkZXRlY3RlZApbICAgIDQuOTc3Mzc3XSB4ZW46IHJlZ2lzdGVyaW5nIGdzaSAyMiB0 cmlnZ2VyaW5nIDAgcG9sYXJpdHkgMQpbICAgIDQuOTc3NDY4XSB4ZW46IC0tPiBwaXJxPTIyIC0+ IGlycT0yMiAoZ3NpPTIyKQpbICAgIDQuOTc3NDk0XSB1aGNpX2hjZCAwMDAwOjAwOjFkLjI6IFBD SSBJTlQgQyAtPiBHU0kgMjIgKGxldmVsLCBsb3cpIC0+IElSUSAyMgpbICAgIDQuOTc3NjE3XSB1 aGNpX2hjZCAwMDAwOjAwOjFkLjI6IHNldHRpbmcgbGF0ZW5jeSB0aW1lciB0byA2NApbICAgIDQu OTc3NjUwXSB1aGNpX2hjZCAwMDAwOjAwOjFkLjI6IFVIQ0kgSG9zdCBDb250cm9sbGVyClsgICAg NC45NzkwNjddIHVoY2lfaGNkIDAwMDA6MDA6MWQuMjogbmV3IFVTQiBidXMgcmVnaXN0ZXJlZCwg YXNzaWduZWQgYnVzIG51bWJlciA0ClsgICAgNC45Nzk3NzldIHVoY2lfaGNkIDAwMDA6MDA6MWQu MjogaXJxIDIyLCBpbyBiYXNlIDB4MDAwMGJmNDAKWyAgICA0Ljk4MDg0M10gdXNiIHVzYjQ6IE5l dyBVU0IgZGV2aWNlIGZvdW5kLCBpZFZlbmRvcj0xZDZiLCBpZFByb2R1Y3Q9MDAwMQpbICAgIDQu OTgwODcxXSB1c2IgdXNiNDogTmV3IFVTQiBkZXZpY2Ugc3RyaW5nczogTWZyPTMsIFByb2R1Y3Q9 MiwgU2VyaWFsTnVtYmVyPTEKWyAgICA0Ljk4MDkwMV0gdXNiIHVzYjQ6IFByb2R1Y3Q6IFVIQ0kg SG9zdCBDb250cm9sbGVyClsgICAgNC45ODA5MjJdIHVzYiB1c2I0OiBNYW51ZmFjdHVyZXI6IExp bnV4IDMuMS4wLTAucmM2LmdpdDAuMC5mYzE3Lng4Nl82NCB1aGNpX2hjZApbICAgIDQuOTgwOTUx XSB1c2IgdXNiNDogU2VyaWFsTnVtYmVyOiAwMDAwOjAwOjFkLjIKWyAgICA0Ljk4NDA1Ml0gaHVi IDQtMDoxLjA6IFVTQiBodWIgZm91bmQKWyAgICA0Ljk4NDM2M10gaHViIDQtMDoxLjA6IDIgcG9y dHMgZGV0ZWN0ZWQKWyAgICA0Ljk4NzEyMl0geGVuOiByZWdpc3RlcmluZyBnc2kgMjMgdHJpZ2dl cmluZyAwIHBvbGFyaXR5IDEKWyAgICA0Ljk4NzIxNV0geGVuOiAtLT4gcGlycT0yMyAtPiBpcnE9 MjMgKGdzaT0yMykKWyAgICA0Ljk4NzI0MF0gdWhjaV9oY2QgMDAwMDowMDoxZC4zOiBQQ0kgSU5U IEQgLT4gR1NJIDIzIChsZXZlbCwgbG93KSAtPiBJUlEgMjMKWyAgICA0Ljk4NzM2NV0gdWhjaV9o Y2QgMDAwMDowMDoxZC4zOiBzZXR0aW5nIGxhdGVuY3kgdGltZXIgdG8gNjQKWyAgICA0Ljk4NzM5 OV0gdWhjaV9oY2QgMDAwMDowMDoxZC4zOiBVSENJIEhvc3QgQ29udHJvbGxlcgpbICAgIDQuOTg4 ODYzXSB1aGNpX2hjZCAwMDAwOjAwOjFkLjM6IG5ldyBVU0IgYnVzIHJlZ2lzdGVyZWQsIGFzc2ln bmVkIGJ1cyBudW1iZXIgNQpbICAgIDQuOTg5NjQ0XSB1aGNpX2hjZCAwMDAwOjAwOjFkLjM6IGly cSAyMywgaW8gYmFzZSAweDAwMDBiZjIwClsgICAgNC45OTA3NDZdIHVzYiB1c2I1OiBOZXcgVVNC IGRldmljZSBmb3VuZCwgaWRWZW5kb3I9MWQ2YiwgaWRQcm9kdWN0PTAwMDEKWyAgICA0Ljk5MDc3 NV0gdXNiIHVzYjU6IE5ldyBVU0IgZGV2aWNlIHN0cmluZ3M6IE1mcj0zLCBQcm9kdWN0PTIsIFNl cmlhbE51bWJlcj0xClsgICAgNC45OTA4MDVdIHVzYiB1c2I1OiBQcm9kdWN0OiBVSENJIEhvc3Qg Q29udHJvbGxlcgpbICAgIDQuOTkwODI2XSB1c2IgdXNiNTogTWFudWZhY3R1cmVyOiBMaW51eCAz LjEuMC0wLnJjNi5naXQwLjAuZmMxNy54ODZfNjQgdWhjaV9oY2QKWyAgICA0Ljk5MDg1NV0gdXNi IHVzYjU6IFNlcmlhbE51bWJlcjogMDAwMDowMDoxZC4zClsgICAgNC45OTM4NTJdIGh1YiA1LTA6 MS4wOiBVU0IgaHViIGZvdW5kClsgICAgNC45OTQxNjddIGh1YiA1LTA6MS4wOiAyIHBvcnRzIGRl dGVjdGVkClsgICAgNC45OTcwMTFdIGluaXRjYWxsIHVoY2lfaGNkX2luaXQrMHgwLzB4YzMgcmV0 dXJuZWQgMCBhZnRlciAzOTQ0MCB1c2VjcwpbICAgIDQuOTk3MDQxXSBjYWxsaW5nICB4aGNpX2hj ZF9pbml0KzB4MC8weDI5IEAgMQpbICAgIDQuOTk3NzE2XSBpbml0Y2FsbCB4aGNpX2hjZF9pbml0 KzB4MC8weDI5IHJldHVybmVkIDAgYWZ0ZXIgNjM1IHVzZWNzClsgICAgNC45OTg1NzNdIHVzYmNv cmU6IHJlZ2lzdGVyZWQgbmV3IGludGVyZmFjZSBkcml2ZXIgdXNic2VyaWFsClsgICAgNC45OTg5 ODJdIFVTQiBTZXJpYWwgc3VwcG9ydCByZWdpc3RlcmVkIGZvciBnZW5lcmljClsgICAgNC45OTky NDZdIHVzYmNvcmU6IHJlZ2lzdGVyZWQgbmV3IGludGVyZmFjZSBkcml2ZXIgdXNic2VyaWFsX2dl bmVyaWMKWyAgICA0Ljk5OTI0Nl0gdXNic2VyaWFsOiBVU0IgU2VyaWFsIERyaXZlciBjb3JlClsg ICAgNC45OTkyNDZdIGluaXRjYWxsIHVzYl9zZXJpYWxfaW5pdCsweDAvMHgxZTEgcmV0dXJuZWQg MCBhZnRlciAxNTY4IHVzZWNzClsgICAgNC45OTkyNDZdIGNhbGxpbmcgIGtnZGJkYmdwX3N0YXJ0 X3RocmVhZCsweDAvMHg0ZiBAIDEKWyAgICA0Ljk5OTI0Nl0gaW5pdGNhbGwga2dkYmRiZ3Bfc3Rh cnRfdGhyZWFkKzB4MC8weDRmIHJldHVybmVkIDAgYWZ0ZXIgMCB1c2VjcwpbICAgIDQuOTk5MjQ2 XSBjYWxsaW5nICBpODA0Ml9pbml0KzB4MC8weDNiZSBAIDEKWyAgICA1LjAwMDIyNV0gaTgwNDI6 IFBOUDogUFMvMiBDb250cm9sbGVyIFtQTlAwMzAzOktCQyxQTlAwZjEzOlBTMk1dIGF0IDB4NjAs MHg2NCBpcnEgMSwxMgpbICAgIDUuMDAxMDY3XSBzZXJpbzogaTgwNDIgS0JEIHBvcnQgYXQgMHg2 MCwweDY0IGlycSAxClsgICAgNS4wMDEwNjddIHNlcmlvOiBpODA0MiBBVVggcG9ydCBhdCAweDYw LDB4NjQgaXJxIDEyClsgICAgNS4wMDU5ODFdIGluaXRjYWxsIGk4MDQyX2luaXQrMHgwLzB4M2Jl IHJldHVybmVkIDAgYWZ0ZXIgNjM0OCB1c2VjcwpbICAgIDUuMDA2MDEwXSBjYWxsaW5nICBzZXJw b3J0X2luaXQrMHgwLzB4MzEgQCAxClsgICAgNS4wMDYwMzZdIGluaXRjYWxsIHNlcnBvcnRfaW5p dCsweDAvMHgzMSByZXR1cm5lZCAwIGFmdGVyIDMgdXNlY3MKWyAgICA1LjAwNjA2M10gY2FsbGlu ZyAgbW91c2VkZXZfaW5pdCsweDAvMHg1ZSBAIDEKWyAgICA1LjAwNzA5N10gbW91c2VkZXY6IFBT LzIgbW91c2UgZGV2aWNlIGNvbW1vbiBmb3IgYWxsIG1pY2UKWyAgICA1LjAwNzA5OV0gaW5pdGNh bGwgbW91c2VkZXZfaW5pdCsweDAvMHg1ZSByZXR1cm5lZCAwIGFmdGVyIDEwMTEgdXNlY3MKWyAg ICA1LjAwNzA5OV0gY2FsbGluZyAgZXZkZXZfaW5pdCsweDAvMHgxMiBAIDEKWyAgICA1LjAwOTk4 MF0gaW5pdGNhbGwgZXZkZXZfaW5pdCsweDAvMHgxMiByZXR1cm5lZCAwIGFmdGVyIDI3NDEgdXNl Y3MKWyAgICA1LjAxMDAxMV0gY2FsbGluZyAgYXRrYmRfaW5pdCsweDAvMHgyNyBAIDEKWyAgICA1 LjAxMDIwNl0gaW5pdGNhbGwgYXRrYmRfaW5pdCsweDAvMHgyNyByZXR1cm5lZCAwIGFmdGVyIDI3 OSB1c2VjcwpbICAgIDUuMDEwMjA2XSBjYWxsaW5nICBwc21vdXNlX2luaXQrMHgwLzB4N2UgQCAx ClsgICAgNS4wMTIwMTBdIGluaXRjYWxsIHBzbW91c2VfaW5pdCsweDAvMHg3ZSByZXR1cm5lZCAw IGFmdGVyIDE2MDAgdXNlY3MKWyAgICA1LjAxMjA0MV0gY2FsbGluZyAgY21vc19pbml0KzB4MC8w eDZhIEAgMQpbICAgIDUuMDEyMzYzXSBydGNfY21vcyAwMDowNjogUlRDIGNhbiB3YWtlIGZyb20g UzQKWyAgICA1LjAxNDYwOV0gcnRjX2Ntb3MgMDA6MDY6IHJ0YyBjb3JlOiByZWdpc3RlcmVkIHJ0 Y19jbW9zIGFzIHJ0YzAKWyAgICA1LjAxNDk1NF0gcnRjMDogYWxhcm1zIHVwIHRvIG9uZSBtb250 aCwgeTNrLCAxMTQgYnl0ZXMgbnZyYW0KWyAgICA1LjAxNTA2N10gaW5pdGNhbGwgY21vc19pbml0 KzB4MC8weDZhIHJldHVybmVkIDAgYWZ0ZXIgMzAxNCB1c2VjcwpbICAgIDUuMDE1MDY3XSBjYWxs aW5nICBkbV9pbml0KzB4MC8weDQ1IEAgMQpbICAgIDUuMDE3NzM0XSBpbnB1dDogQVQgVHJhbnNs YXRlZCBTZXQgMiBrZXlib2FyZCBhcyAvZGV2aWNlcy9wbGF0Zm9ybS9pODA0Mi9zZXJpbzAvaW5w dXQvaW5wdXQzClsgICAgNS4wMjIzOTFdIGRldmljZS1tYXBwZXI6IHVldmVudDogdmVyc2lvbiAx LjAuMwpbICAgIDUuMDI2MDAxXSBkZXZpY2UtbWFwcGVyOiBpb2N0bDogNC4yMS4wLWlvY3RsICgy MDExLTA3LTA2KSBpbml0aWFsaXNlZDogZG0tZGV2ZWxAcmVkaGF0LmNvbQpbICAgIDUuMDI2MDQz XSBpbml0Y2FsbCBkbV9pbml0KzB4MC8weDQ1IHJldHVybmVkIDAgYWZ0ZXIgMTA1ODggdXNlY3MK WyAgICA1LjAyNjA3Ml0gY2FsbGluZyAgZG1fc25hcHNob3RfaW5pdCsweDAvMHgyMTMgQCAxClsg ICAgNS4wMjg3OTRdIGluaXRjYWxsIGRtX3NuYXBzaG90X2luaXQrMHgwLzB4MjEzIHJldHVybmVk IDAgYWZ0ZXIgMjYzNSB1c2VjcwpbICAgIDUuMDI4ODI1XSBjYWxsaW5nICBkbV9taXJyb3JfaW5p dCsweDAvMHg3NiBAIDEKWyAgICA1LjAyOTU5N10gaW5pdGNhbGwgZG1fbWlycm9yX2luaXQrMHgw LzB4NzYgcmV0dXJuZWQgMCBhZnRlciA3MzAgdXNlY3MKWyAgICA1LjAyOTYyNV0gY2FsbGluZyAg ZG1fZGlydHlfbG9nX2luaXQrMHgwLzB4NTggQCAxClsgICAgNS4wMjk2NzhdIGluaXRjYWxsIGRt X2RpcnR5X2xvZ19pbml0KzB4MC8weDU4IHJldHVybmVkIDAgYWZ0ZXIgMjggdXNlY3MKWyAgICA1 LjAyOTcwNl0gY2FsbGluZyAgZG1femVyb19pbml0KzB4MC8weDJlIEAgMQpbICAgIDUuMDI5NzMx XSBpbml0Y2FsbCBkbV96ZXJvX2luaXQrMHgwLzB4MmUgcmV0dXJuZWQgMCBhZnRlciAyIHVzZWNz ClsgICAgNS4wMjk3NTddIGNhbGxpbmcgIGNwdWZyZXFfZ292X3Bvd2Vyc2F2ZV9pbml0KzB4MC8w eDEyIEAgMQpbICAgIDUuMDI5Nzg5XSBpbml0Y2FsbCBjcHVmcmVxX2dvdl9wb3dlcnNhdmVfaW5p dCsweDAvMHgxMiByZXR1cm5lZCAwIGFmdGVyIDQgdXNlY3MKWyAgICA1LjAyOTg1NF0gY2FsbGlu ZyAgY3B1ZnJlcV9nb3ZfdXNlcnNwYWNlX2luaXQrMHgwLzB4MTIgQCAxClsgICAgNS4wMjk4ODRd IGluaXRjYWxsIGNwdWZyZXFfZ292X3VzZXJzcGFjZV9pbml0KzB4MC8weDEyIHJldHVybmVkIDAg YWZ0ZXIgMyB1c2VjcwpbICAgIDUuMDI5OTE1XSBjYWxsaW5nICBjcHVmcmVxX2dvdl9kYnNfaW5p dCsweDAvMHgxMiBAIDEKWyAgICA1LjAyOTk0MF0gaW5pdGNhbGwgY3B1ZnJlcV9nb3ZfZGJzX2lu aXQrMHgwLzB4MTIgcmV0dXJuZWQgMCBhZnRlciAzIHVzZWNzClsgICAgNS4wMjk5NjddIGNhbGxp bmcgIGluaXRfbGFkZGVyKzB4MC8weDEyIEAgMQpbICAgIDUuMDI5OTkwXSBpbml0Y2FsbCBpbml0 X2xhZGRlcisweDAvMHgxMiByZXR1cm5lZCAtMTkgYWZ0ZXIgMCB1c2VjcwpbICAgIDUuMDMwMDE2 XSBjYWxsaW5nICBpbml0X21lbnUrMHgwLzB4MTIgQCAxClsgICAgNS4wMzAwMzRdIGluaXRjYWxs IGluaXRfbWVudSsweDAvMHgxMiByZXR1cm5lZCAtMTkgYWZ0ZXIgMCB1c2VjcwpbICAgIDUuMDMw MDYxXSBjYWxsaW5nICBkbWlfc3lzZnNfaW5pdCsweDAvMHhiNCBAIDEKWyAgICA1LjAzNzgwMV0g aW5pdGNhbGwgZG1pX3N5c2ZzX2luaXQrMHgwLzB4YjQgcmV0dXJuZWQgMCBhZnRlciA3NTM1IHVz ZWNzClsgICAgNS4wMzc4MzFdIGNhbGxpbmcgIGVmaXZhcnNfaW5pdCsweDAvMHhmMyBAIDEKWyAg ICA1LjAzNzg3NF0gaW5pdGNhbGwgZWZpdmFyc19pbml0KzB4MC8weGYzIHJldHVybmVkIDAgYWZ0 ZXIgMjAgdXNlY3MKWyAgICA1LjAzNzkwMF0gY2FsbGluZyAgaGlkX2luaXQrMHgwLzB4NjMgQCAx ClsgICAgNS4wMzg2MDFdIGluaXRjYWxsIGhpZF9pbml0KzB4MC8weDYzIHJldHVybmVkIDAgYWZ0 ZXIgNjY2IHVzZWNzClsgICAgNS4wMzg2MzBdIGNhbGxpbmcgIGE0X2luaXQrMHgwLzB4MWIgQCAx ClsgICAgNS4wMzg4OTZdIGluaXRjYWxsIGE0X2luaXQrMHgwLzB4MWIgcmV0dXJuZWQgMCBhZnRl ciAyNDEgdXNlY3MKWyAgICA1LjAzODkyM10gY2FsbGluZyAgYXBwbGVfaW5pdCsweDAvMHgzNSBA IDEKWyAgICA1LjAzOTEzNF0gaW5pdGNhbGwgYXBwbGVfaW5pdCsweDAvMHgzNSByZXR1cm5lZCAw IGFmdGVyIDMzMiB1c2VjcwpbICAgIDUuMDM5MTM0XSBjYWxsaW5nICBiZWxraW5faW5pdCsweDAv MHgxYiBAIDEKWyAgICA1LjAzOTYxMl0gaW5pdGNhbGwgYmVsa2luX2luaXQrMHgwLzB4MWIgcmV0 dXJuZWQgMCBhZnRlciAyNjkgdXNlY3MKWyAgICA1LjAzOTY0MF0gY2FsbGluZyAgY2hfaW5pdCsw eDAvMHgxYiBAIDEKWyAgICA1LjAzOTg4NV0gaW5pdGNhbGwgY2hfaW5pdCsweDAvMHgxYiByZXR1 cm5lZCAwIGFmdGVyIDIyMSB1c2VjcwpbICAgIDUuMDM5OTEyXSBjYWxsaW5nICBjaF9pbml0KzB4 MC8weDFiIEAgMQpbICAgIDUuMDQwMTkxXSBpbml0Y2FsbCBjaF9pbml0KzB4MC8weDFiIHJldHVy bmVkIDAgYWZ0ZXIgMjUyIHVzZWNzClsgICAgNS4wNDAyMThdIGNhbGxpbmcgIGNwX2luaXQrMHgw LzB4MWIgQCAxClsgICAgNS4wNDA0NzBdIGluaXRjYWxsIGNwX2luaXQrMHgwLzB4MWIgcmV0dXJu ZWQgMCBhZnRlciAyMjggdXNlY3MKWyAgICA1LjA0MDQ5OF0gY2FsbGluZyAgZXpfaW5pdCsweDAv MHgxYiBAIDEKWyAgICA1LjA0MDc1NV0gaW5pdGNhbGwgZXpfaW5pdCsweDAvMHgxYiByZXR1cm5l ZCAwIGFmdGVyIDIzMiB1c2VjcwpbICAgIDUuMDQwNzgyXSBjYWxsaW5nICBrc19pbml0KzB4MC8w eDFiIEAgMQpbICAgIDUuMDQxMDI4XSBpbml0Y2FsbCBrc19pbml0KzB4MC8weDFiIHJldHVybmVk IDAgYWZ0ZXIgMjIxIHVzZWNzClsgICAgNS4wNDEwNTZdIGNhbGxpbmcgIGt5ZV9pbml0KzB4MC8w eDFiIEAgMQpbICAgIDUuMDQxMTgwXSBpbml0Y2FsbCBreWVfaW5pdCsweDAvMHgxYiByZXR1cm5l ZCAwIGFmdGVyIDIwNSB1c2VjcwpbICAgIDUuMDQxMTgwXSBjYWxsaW5nICBsZ19pbml0KzB4MC8w eDFiIEAgMQpbICAgIDUuMDQxNzI1XSBpbml0Y2FsbCBsZ19pbml0KzB4MC8weDFiIHJldHVybmVk IDAgYWZ0ZXIgMzg1IHVzZWNzClsgICAgNS4wNDE3NTRdIGNhbGxpbmcgIG1zX2luaXQrMHgwLzB4 MWIgQCAxClsgICAgNS4wNDE5ODVdIGluaXRjYWxsIG1zX2luaXQrMHgwLzB4MWIgcmV0dXJuZWQg MCBhZnRlciAyMDcgdXNlY3MKWyAgICA1LjA0MjAxMl0gY2FsbGluZyAgbXJfaW5pdCsweDAvMHgx YiBAIDEKWyAgICA1LjA0MjI0MF0gaW5pdGNhbGwgbXJfaW5pdCsweDAvMHgxYiByZXR1cm5lZCAw IGFmdGVyIDIwNSB1c2VjcwpbICAgIDUuMDQyMjY3XSBjYWxsaW5nICBudHJpZ19pbml0KzB4MC8w eDFiIEAgMQpbICAgIDUuMDQyODg3XSBpbml0Y2FsbCBudHJpZ19pbml0KzB4MC8weDFiIHJldHVy bmVkIDAgYWZ0ZXIgNTgyIHVzZWNzClsgICAgNS4wNDI5MTVdIGNhbGxpbmcgIHF1YW50YV9pbml0 KzB4MC8weDFiIEAgMQpbICAgIDUuMDQzMTYwXSBpbml0Y2FsbCBxdWFudGFfaW5pdCsweDAvMHgx YiByZXR1cm5lZCAwIGFmdGVyIDIxNyB1c2VjcwpbICAgIDUuMDQzMTg3XSBjYWxsaW5nICBoaWRf aW5pdCsweDAvMHg3NSBAIDEKWyAgICA1LjA0MzkxMl0gdXNiY29yZTogcmVnaXN0ZXJlZCBuZXcg aW50ZXJmYWNlIGRyaXZlciB1c2JoaWQKWyAgICA1LjA0MzkzNl0gdXNiaGlkOiBVU0IgSElEIGNv cmUgZHJpdmVyClsgICAgNS4wNDM5ODhdIGluaXRjYWxsIGhpZF9pbml0KzB4MC8weDc1IHJldHVy bmVkIDAgYWZ0ZXIgNzYzIHVzZWNzClsgICAgNS4wNDQwMTVdIGNhbGxpbmcgIHN0YWdpbmdfaW5p dCsweDAvMHg4IEAgMQpbICAgIDUuMDQ0MDM3XSBpbml0Y2FsbCBzdGFnaW5nX2luaXQrMHgwLzB4 OCByZXR1cm5lZCAwIGFmdGVyIDAgdXNlY3MKWyAgICA1LjA0NDA2NV0gY2FsbGluZyAgZmxvd19j YWNoZV9pbml0X2dsb2JhbCsweDAvMHgxMzIgQCAxClsgICAgNS4wNDQ4NTBdIGluaXRjYWxsIGZs b3dfY2FjaGVfaW5pdF9nbG9iYWwrMHgwLzB4MTMyIHJldHVybmVkIDAgYWZ0ZXIgNzQ0IHVzZWNz ClsgICAgNS4wNDQ4ODNdIGNhbGxpbmcgIGJsYWNraG9sZV9tb2R1bGVfaW5pdCsweDAvMHgxMiBA IDEKWyAgICA1LjA0NDkxMF0gaW5pdGNhbGwgYmxhY2tob2xlX21vZHVsZV9pbml0KzB4MC8weDEy IHJldHVybmVkIDAgYWZ0ZXIgNCB1c2VjcwpbICAgIDUuMDQ0OTQwXSBjYWxsaW5nICBpbml0X2Nn cm91cF9jbHMrMHgwLzB4M2MgQCAxClsgICAgNS4wNDUwMDJdIGluaXRjYWxsIGluaXRfY2dyb3Vw X2NscysweDAvMHgzYyByZXR1cm5lZCAwIGFmdGVyIDM4IHVzZWNzClsgICAgNS4wNDUwMjldIGNh bGxpbmcgIHh0X2luaXQrMHgwLzB4MTJkIEAgMQpbICAgIDUuMDQ1MDkzXSBpbml0Y2FsbCB4dF9p bml0KzB4MC8weDEyZCByZXR1cm5lZCAwIGFmdGVyIDQzIHVzZWNzClsgICAgNS4wNDUxMjBdIGNh bGxpbmcgIHRjcHVkcF9tdF9pbml0KzB4MC8weDE3IEAgMQpbICAgIDUuMDQ1MTg0XSBpbml0Y2Fs bCB0Y3B1ZHBfbXRfaW5pdCsweDAvMHgxNyByZXR1cm5lZCAwIGFmdGVyIDQwIHVzZWNzClsgICAg NS4wNDUyMTFdIGNhbGxpbmcgIHN5c2N0bF9pcHY0X2luaXQrMHgwLzB4ODQgQCAxClsgICAgNS4w NDcyMTJdIGluaXRjYWxsIHN5c2N0bF9pcHY0X2luaXQrMHgwLzB4ODQgcmV0dXJuZWQgMCBhZnRl ciAyODE3IHVzZWNzClsgICAgNS4wNDcyMTJdIGNhbGxpbmcgIGluaXRfc3luY29va2llcysweDAv MHgxOSBAIDEKWyAgICA1LjA0NzIxMl0gaW5pdGNhbGwgaW5pdF9zeW5jb29raWVzKzB4MC8weDE5 IHJldHVybmVkIDAgYWZ0ZXIgNTEgdXNlY3MKWyAgICA1LjA0NzIxMl0gY2FsbGluZyAgaXB2NF9u ZXRmaWx0ZXJfaW5pdCsweDAvMHgxNyBAIDEKWyAgICA1LjA0NzIxMl0gaW5pdGNhbGwgaXB2NF9u ZXRmaWx0ZXJfaW5pdCsweDAvMHgxNyByZXR1cm5lZCAwIGFmdGVyIDI2IHVzZWNzClsgICAgNS4w NDcyMTJdIGNhbGxpbmcgIGlwX3RhYmxlc19pbml0KzB4MC8weGFhIEAgMQpbICAgIDUuMDQ4NzI1 XSBpcF90YWJsZXM6IChDKSAyMDAwLTIwMDYgTmV0ZmlsdGVyIENvcmUgVGVhbQpbICAgIDUuMDQ4 NzUxXSBpbml0Y2FsbCBpcF90YWJsZXNfaW5pdCsweDAvMHhhYSByZXR1cm5lZCAwIGFmdGVyIDM5 MCB1c2VjcwpbICAgIDUuMDQ4Nzc4XSBjYWxsaW5nICBpcHRhYmxlX2ZpbHRlcl9pbml0KzB4MC8w eDZjIEAgMQpbICAgIDUuMDQ5MTY1XSBpbml0Y2FsbCBpcHRhYmxlX2ZpbHRlcl9pbml0KzB4MC8w eDZjIHJldHVybmVkIDAgYWZ0ZXIgMzUzIHVzZWNzClsgICAgNS4wNDkyMjNdIGluaXRjYWxsIHJl amVjdF90Z19pbml0KzB4MC8weDEyIHJldHVybmVkIDAgYWZ0ZXIgMyB1c2VjcwpbICAgIDUuMDQ5 MjUwXSBjYWxsaW5nICBjdWJpY3RjcF9yZWdpc3RlcisweDAvMHg1OSBAIDEKWyAgICA1LjA0OTI3 NF0gVENQIGN1YmljIHJlZ2lzdGVyZWQKWyAgICA1LjA0OTI5M10gaW5pdGNhbGwgY3ViaWN0Y3Bf cmVnaXN0ZXIrMHgwLzB4NTkgcmV0dXJuZWQgMCBhZnRlciAyMCB1c2VjcwpbICAgIDUuMDQ5MzE5 XSBjYWxsaW5nICB4ZnJtX3VzZXJfaW5pdCsweDAvMHg0YSBAIDEKWyAgICA1LjA0OTM0MF0gSW5p dGlhbGl6aW5nIFhGUk0gbmV0bGluayBzb2NrZXQKWyAgICA1LjA0OTUxMF0gaW5pdGNhbGwgeGZy bV91c2VyX2luaXQrMHgwLzB4NGEgcmV0dXJuZWQgMCBhZnRlciAxNjMgdXNlY3MKWyAgICA1LjA0 OTUzOF0gY2FsbGluZyAgaW5ldDZfaW5pdCsweDAvMHgyYjYgQCAxClsgICAgNS4wNTUyMzNdIE5F VDogUmVnaXN0ZXJlZCBwcm90b2NvbCBmYW1pbHkgMTAKWyAgICA1LjA3MDkyMl0gaW5pdGNhbGwg aW5ldDZfaW5pdCsweDAvMHgyYjYgcmV0dXJuZWQgMCBhZnRlciAyMDg1NiB1c2VjcwpbICAgIDUu MDcwOTU2XSBjYWxsaW5nICBtaXA2X2luaXQrMHgwLzB4YmMgQCAxClsgICAgNS4wNzA5NzNdIE1v YmlsZSBJUHY2ClsgICAgNS4wNzA5OTNdIGluaXRjYWxsIG1pcDZfaW5pdCsweDAvMHhiYyByZXR1 cm5lZCAwIGFmdGVyIDE3IHVzZWNzClsgICAgNS4wNzEwMTldIGNhbGxpbmcgIHBhY2tldF9pbml0 KzB4MC8weDQ0IEAgMQpbICAgIDUuMDcxMDQ1XSBORVQ6IFJlZ2lzdGVyZWQgcHJvdG9jb2wgZmFt aWx5IDE3ClsgICAgNS4wNzEyOTJdIGluaXRjYWxsIHBhY2tldF9pbml0KzB4MC8weDQ0IHJldHVy bmVkIDAgYWZ0ZXIgMjQzIHVzZWNzClsgICAgNS4wNzEzMjBdIGNhbGxpbmcgIGRzYV9pbml0X21v ZHVsZSsweDAvMHgxNCBAIDEKWyAgICA1LjA3MTM0NV0gaW5pdGNhbGwgZHNhX2luaXRfbW9kdWxl KzB4MC8weDE0IHJldHVybmVkIDAgYWZ0ZXIgMiB1c2VjcwpbICAgIDUuMDcxMzcxXSBjYWxsaW5n ICBlZHNhX2luaXRfbW9kdWxlKzB4MC8weDE0IEAgMQpbICAgIDUuMDcxMzk3XSBpbml0Y2FsbCBl ZHNhX2luaXRfbW9kdWxlKzB4MC8weDE0IHJldHVybmVkIDAgYWZ0ZXIgMiB1c2VjcwpbICAgIDUu MDcxNDI0XSBjYWxsaW5nICB0cmFpbGVyX2luaXRfbW9kdWxlKzB4MC8weDE0IEAgMQpbICAgIDUu MDcxNDQ4XSBpbml0Y2FsbCB0cmFpbGVyX2luaXRfbW9kdWxlKzB4MC8weDE0IHJldHVybmVkIDAg YWZ0ZXIgMSB1c2VjcwpbICAgIDUuMDcxNDc0XSBjYWxsaW5nICBtdjg4ZTYwNjBfaW5pdCsweDAv MHgxNCBAIDEKWyAgICA1LjA3MTUyNV0gaW5pdGNhbGwgbXY4OGU2MDYwX2luaXQrMHgwLzB4MTQg cmV0dXJuZWQgMCBhZnRlciAyNyB1c2VjcwpbICAgIDUuMDcxNTUzXSBjYWxsaW5nICBtdjg4ZTYx MjNfNjFfNjVfaW5pdCsweDAvMHgxNCBAIDEKWyAgICA1LjA3MTU3OF0gaW5pdGNhbGwgbXY4OGU2 MTIzXzYxXzY1X2luaXQrMHgwLzB4MTQgcmV0dXJuZWQgMCBhZnRlciAyIHVzZWNzClsgICAgNS4w NzE2MDVdIGNhbGxpbmcgIG12ODhlNjEzMV9pbml0KzB4MC8weDE0IEAgMQpbICAgIDUuMDcxNjI5 XSBpbml0Y2FsbCBtdjg4ZTYxMzFfaW5pdCsweDAvMHgxNCByZXR1cm5lZCAwIGFmdGVyIDIgdXNl Y3MKWyAgICA1LjA3MTY1NV0gY2FsbGluZyAgZHNhX2luaXRfbW9kdWxlKzB4MC8weDEyIEAgMQpb ICAgIDUuMDcxODk0XSBpbml0Y2FsbCBkc2FfaW5pdF9tb2R1bGUrMHgwLzB4MTIgcmV0dXJuZWQg MCBhZnRlciAyMDkgdXNlY3MKWyAgICA1LjA3MTkyMl0gY2FsbGluZyAgZGNibmxfaW5pdCsweDAv MHg0ZCBAIDEKWyAgICA1LjA3MTk0NV0gaW5pdGNhbGwgZGNibmxfaW5pdCsweDAvMHg0ZCByZXR1 cm5lZCAwIGFmdGVyIDAgdXNlY3MKWyAgICA1LjA3MTk3MV0gY2FsbGluZyAgaW5pdF9kbnNfcmVz b2x2ZXIrMHgwLzB4ZmUgQCAxClsgICAgNS4wNzE5OTJdIFJlZ2lzdGVyaW5nIHRoZSBkbnNfcmVz b2x2ZXIga2V5IHR5cGUKWyAgICA1LjA3MjQzMl0gaW5pdGNhbGwgaW5pdF9kbnNfcmVzb2x2ZXIr MHgwLzB4ZmUgcmV0dXJuZWQgMCBhZnRlciA0MjYgdXNlY3MKWyAgICA1LjA3MjQ2Ml0gY2FsbGlu ZyAgdGJvb3RfbGF0ZV9pbml0KzB4MC8weDIyOSBAIDEKWyAgICA1LjA3MjQ4Nl0gaW5pdGNhbGwg dGJvb3RfbGF0ZV9pbml0KzB4MC8weDIyOSByZXR1cm5lZCAwIGFmdGVyIDEgdXNlY3MKWyAgICA1 LjA3MjUxMl0gY2FsbGluZyAgbWNoZWNrX2RlYnVnZnNfaW5pdCsweDAvMHgzYiBAIDEKWyAgICA1 LjA3MjY4M10gaW5pdGNhbGwgbWNoZWNrX2RlYnVnZnNfaW5pdCsweDAvMHgzYiByZXR1cm5lZCAw IGFmdGVyIDE0NCB1c2VjcwpbICAgIDUuMDcyNzE0XSBjYWxsaW5nICBzZXZlcml0aWVzX2RlYnVn ZnNfaW5pdCsweDAvMHgzYiBAIDEKWyAgICA1LjA3MjgwNF0gaW5pdGNhbGwgc2V2ZXJpdGllc19k ZWJ1Z2ZzX2luaXQrMHgwLzB4M2IgcmV0dXJuZWQgMCBhZnRlciA2NSB1c2VjcwpbICAgIDUuMDcy ODM2XSBjYWxsaW5nICBocGV0X2luc2VydF9yZXNvdXJjZSsweDAvMHgyMyBAIDEKWyAgICA1LjA3 Mjg2NF0gaW5pdGNhbGwgaHBldF9pbnNlcnRfcmVzb3VyY2UrMHgwLzB4MjMgcmV0dXJuZWQgMCBh ZnRlciA1IHVzZWNzClsgICAgNS4wNzI4OTFdIGNhbGxpbmcgIHVwZGF0ZV9tcF90YWJsZSsweDAv MHg0NTAgQCAxClsgICAgNS4wNzI5MTRdIGluaXRjYWxsIHVwZGF0ZV9tcF90YWJsZSsweDAvMHg0 NTAgcmV0dXJuZWQgMCBhZnRlciAwIHVzZWNzClsgICAgNS4wNzI5NDFdIGNhbGxpbmcgIGxhcGlj X2luc2VydF9yZXNvdXJjZSsweDAvMHgzZiBAIDEKWyAgICA1LjA3Mjk2Nl0gaW5pdGNhbGwgbGFw aWNfaW5zZXJ0X3Jlc291cmNlKzB4MC8weDNmIHJldHVybmVkIDAgYWZ0ZXIgMiB1c2VjcwpbICAg IDUuMDcyOTk2XSBjYWxsaW5nICBpb19hcGljX2J1Z19maW5hbGl6ZSsweDAvMHgxYiBAIDEKWyAg ICA1LjA3MzAxOV0gaW5pdGNhbGwgaW9fYXBpY19idWdfZmluYWxpemUrMHgwLzB4MWIgcmV0dXJu ZWQgMCBhZnRlciAwIHVzZWNzClsgICAgNS4wNzMwNDddIGNhbGxpbmcgIHByaW50X0lDcysweDAv MHg1YWYgQCAxClsgICAgNS4wNzMwNzBdIGluaXRjYWxsIHByaW50X0lDcysweDAvMHg1YWYgcmV0 dXJuZWQgMCBhZnRlciAwIHVzZWNzClsgICAgNS4wNzMwODldIGNhbGxpbmcgIGNoZWNrX2Vhcmx5 X2lvcmVtYXBfbGVhaysweDAvMHg1MCBAIDEKWyAgICA1LjA3MzA4OV0gaW5pdGNhbGwgY2hlY2tf ZWFybHlfaW9yZW1hcF9sZWFrKzB4MC8weDUwIHJldHVybmVkIDAgYWZ0ZXIgMCB1c2VjcwpbICAg IDUuMDczMDg5XSBjYWxsaW5nICBwYXRfbWVtdHlwZV9saXN0X2luaXQrMHgwLzB4MzIgQCAxClsg ICAgNS4wNzMyODJdIGluaXRjYWxsIHBhdF9tZW10eXBlX2xpc3RfaW5pdCsweDAvMHgzMiByZXR1 cm5lZCAwIGFmdGVyIDEwNyB1c2VjcwpbICAgIDUuMDczMzE1XSBjYWxsaW5nICBzY2hlZF9pbml0 X2RlYnVnKzB4MC8weDI0IEAgMQpbICAgIDUuMDczNDM1XSBjYWxsaW5nICBpbml0X29vcHNfaWQr MHgwLzB4MzYgQCAxClsgICAgNS4wNzM0NjldIGluaXRjYWxsIGluaXRfb29wc19pZCsweDAvMHgz NiByZXR1cm5lZCAwIGFmdGVyIDEyIHVzZWNzClsgICAgNS4wNzM0OTVdIGNhbGxpbmcgIHByaW50 a19sYXRlX2luaXQrMHgwLzB4NTYgQCAxClsgICAgNS4wNzM1MjRdIGluaXRjYWxsIHByaW50a19s YXRlX2luaXQrMHgwLzB4NTYgcmV0dXJuZWQgMCBhZnRlciA1IHVzZWNzClsgICAgNS4wNzM1NTJd IGNhbGxpbmcgIHBtX3Fvc19wb3dlcl9pbml0KzB4MC8weGM3IEAgMQpbICAgIDUuMDc2MDM2XSBp bml0Y2FsbCBwbV9xb3NfcG93ZXJfaW5pdCsweDAvMHhjNyByZXR1cm5lZCAwIGFmdGVyIDI0MDMg dXNlY3MKClsgICAgNS4wNzYwNjhdIGNhbGxpbmcgIHRlc3Rfc3VzcGVuZCsweDAvMHgxYWUgQCAx ClsgICAgNS4wNzYwOTFdIGluaXRjYWxsIHRlc3Rfc3VzcGVuZCsweDAvMHgxYWUgcmV0dXJuZWQg MCBhZnRlciAwIHVzZWNzClsgICAgNS4wNzYxMTldIGNhbGxpbmcgIHNvZnR3YXJlX3Jlc3VtZSsw eDAvMHgxZjIgQCAxClsgICAgNS4wNzYxNjVdIFBNOiBIaWJlcm5hdGlvbiBpbWFnZSBub3QgcHJl c2VudCBvciBjb3VsZCBub3QgYmUgbG9hZGVkLgpbICAgIDUuMDc2MTkzXSBpbml0Y2FsbCBzb2Z0 d2FyZV9yZXN1bWUrMHgwLzB4MWYyIHJldHVybmVkIC0yIGFmdGVyIDUwIHVzZWNzClsgICAgNS4w NzYyMTldIGluaXRjYWxsIHNvZnR3YXJlX3Jlc3VtZSsweDAvMHgxZjIgcmV0dXJuZWQgd2l0aCBl cnJvciBjb2RlIC0yClsgICAgNS4wNzYyMzVdIGNhbGxpbmcgIGRlYnVnZnNfa3Byb2JlX2luaXQr MHgwLzB4OWYgQCAxClsgICAgNS4wNzYyMzVdIGluaXRjYWxsIGRlYnVnZnNfa3Byb2JlX2luaXQr MHgwLzB4OWYgcmV0dXJuZWQgMCBhZnRlciAxNjMgdXNlY3MKWyAgICA1LjA3NjIzNV0gY2FsbGlu ZyAgdGFza3N0YXRzX2luaXQrMHgwLzB4OTUgQCAxClsgICAgNS4wNzYyMzVdIHJlZ2lzdGVyZWQg dGFza3N0YXRzIHZlcnNpb24gMQpbICAgIDUuMDc2MjM1XSBpbml0Y2FsbCB0YXNrc3RhdHNfaW5p dCsweDAvMHg5NSByZXR1cm5lZCAwIGFmdGVyIDg3IHVzZWNzClsgICAgNS4wNzYyMzVdIGNhbGxp bmcgIGNsZWFyX2Jvb3RfdHJhY2VyKzB4MC8weDJkIEAgMQpbICAgIDUuMDc2MjM1XSBpbml0Y2Fs bCBjbGVhcl9ib290X3RyYWNlcisweDAvMHgyZCByZXR1cm5lZCAwIGFmdGVyIDAgdXNlY3MKWyAg ICA1LjA3NjIzNV0gY2FsbGluZyAga2RiX2Z0cmFjZV9yZWdpc3RlcisweDAvMHgyZiBAIDEKWyAg ICA1LjA3NjIzNV0gaW5pdGNhbGwga2RiX2Z0cmFjZV9yZWdpc3RlcisweDAvMHgyZiByZXR1cm5l ZCAwIGFmdGVyIDQgdXNlY3MKWyAgICA1LjA3NjIzNV0gY2FsbGluZyAgZmFpbF9wYWdlX2FsbG9j X2RlYnVnZnMrMHgwLzB4OWQgQCAxClsgICAgNS4wNzg2NDZdIGF0YTEuMDA6IEhQQSBkZXRlY3Rl ZDogY3VycmVudCA3NTIwMDI2NSwgbmF0aXZlIDc4MTQwMTYwClsgICAgNS4wNzg2ODBdIGF0YTEu MDA6IEFUQS02OiBUT1NISUJBIE1LNDAzMkdTWCwgQVMyMTJELCBtYXggVURNQS8xMDAKWyAgICA1 LjA3ODcwN10gYXRhMS4wMDogNzUyMDAyNjUgc2VjdG9ycywgbXVsdGkgODogTEJBNDggTkNRIChk ZXB0aCAwLzMyKQpbICAgIDUuMDc5MDc2XSBpbml0Y2FsbCBmYWlsX3BhZ2VfYWxsb2NfZGVidWdm cysweDAvMHg5ZCByZXR1cm5lZCAwIGFmdGVyIDIyNzggdXNlY3MKWyAgICA1LjA3OTA3Nl0gY2Fs bGluZyAgbWF4X3N3YXBmaWxlc19jaGVjaysweDAvMHg4IEAgMQpbICAgIDUuMDc5MDc2XSBpbml0 Y2FsbCBtYXhfc3dhcGZpbGVzX2NoZWNrKzB4MC8weDggcmV0dXJuZWQgMCBhZnRlciAwIHVzZWNz ClsgICAgNS4wNzkwNzZdIGNhbGxpbmcgIGZhaWxzbGFiX2RlYnVnZnNfaW5pdCsweDAvMHg3ZCBA IDEKWyAgICA1LjA3OTc4NV0gaW5pdGNhbGwgZmFpbHNsYWJfZGVidWdmc19pbml0KzB4MC8weDdk IHJldHVybmVkIDAgYWZ0ZXIgNTc4IHVzZWNzClsgICAgNS4wNzk4MjBdIGNhbGxpbmcgIHNldF9y ZWNvbW1lbmRlZF9taW5fZnJlZV9rYnl0ZXMrMHgwLzB4ODUgQCAxClsgICAgNS4wNzk4NDddIGlu aXRjYWxsIHNldF9yZWNvbW1lbmRlZF9taW5fZnJlZV9rYnl0ZXMrMHgwLzB4ODUgcmV0dXJuZWQg MCBhZnRlciAwIHVzZWNzClsgICAgNS4wNzk4NzddIGNhbGxpbmcgIGluaXRfaW1hKzB4MC8weDE1 IEAgMQpbICAgIDUuMDc5ODk3XSBJTUE6IE5vIFRQTSBjaGlwIGZvdW5kLCBhY3RpdmF0aW5nIFRQ TS1ieXBhc3MhClsgICAgNS4wODA5MDddIGluaXRjYWxsIGluaXRfaW1hKzB4MC8weDE1IHJldHVy bmVkIDAgYWZ0ZXIgOTg3IHVzZWNzClsgICAgNS4wODA5MzhdIGNhbGxpbmcgIGZhaWxfbWFrZV9y ZXF1ZXN0X2RlYnVnZnMrMHgwLzB4MjggQCAxClsgICAgNS4wODEzNzldIGluaXRjYWxsIGZhaWxf bWFrZV9yZXF1ZXN0X2RlYnVnZnMrMHgwLzB4MjggcmV0dXJuZWQgMCBhZnRlciA0MDcgdXNlY3MK WyAgICA1LjA4MTQxMV0gY2FsbGluZyAgZmFpbF9pb190aW1lb3V0X2RlYnVnZnMrMHgwLzB4Mjgg QCAxClsgICAgNS4wODE2NDBdIGF0YTEuMDA6IGNvbmZpZ3VyZWQgZm9yIFVETUEvMTAwClsgICAg NS4wODE3NzldIGFzeW5jX3dhaXRpbmcgQCA1ClsgICAgNS4wODE4MDFdIGFzeW5jX2NvbnRpbnVp bmcgQCA1IGFmdGVyIDMgdXNlYwpbICAgIDUuMDgyMDc5XSBpbml0Y2FsbCBmYWlsX2lvX3RpbWVv dXRfZGVidWdmcysweDAvMHgyOCByZXR1cm5lZCAwIGFmdGVyIDYyOSB1c2VjcwpbICAgIDUuMDgy MTQwXSBjYWxsaW5nICByYW5kb20zMl9yZXNlZWQrMHgwLzB4YTIgQCAxClsgICAgNS4wODIxOTJd IGluaXRjYWxsIHJhbmRvbTMyX3Jlc2VlZCsweDAvMHhhMiByZXR1cm5lZCAwIGFmdGVyIDI5IHVz ZWNzClsgICAgNS4wODIyMjBdIGNhbGxpbmcgIHBjaV9yZXNvdXJjZV9hbGlnbm1lbnRfc3lzZnNf aW5pdCsweDAvMHgxOSBAIDEKWyAgICA1LjA4MjI2OV0gaW5pdGNhbGwgcGNpX3Jlc291cmNlX2Fs aWdubWVudF9zeXNmc19pbml0KzB4MC8weDE5IHJldHVybmVkIDAgYWZ0ZXIgMjAgdXNlY3MKWyAg ICA1LjA4MjMwMF0gY2FsbGluZyAgcGNpX3N5c2ZzX2luaXQrMHgwLzB4NTEgQCAxClsgICAgNS4w ODQ1NTJdIHNjc2kgMDowOjA6MDogRGlyZWN0LUFjY2VzcyAgICAgQVRBICAgICAgVE9TSElCQSBN SzQwMzJHUyBBUzIxIFBROiAwIEFOU0k6IDUKWyAgICA1LjA4OTY1NV0gaW5pdGNhbGwgcGNpX3N5 c2ZzX2luaXQrMHgwLzB4NTEgcmV0dXJuZWQgMCBhZnRlciA3MTU2IHVzZWNzClsgICAgNS4wODk2 OTBdIGNhbGxpbmcgIGJvb3Rfd2FpdF9mb3JfZGV2aWNlcysweDAvMHgzMCBAIDEKWyAgICA1LjA4 OTcxOV0gaW5pdGNhbGwgYm9vdF93YWl0X2Zvcl9kZXZpY2VzKzB4MC8weDMwIHJldHVybmVkIDAg YWZ0ZXIgNSB1c2VjcwpbICAgIDUuMDg5NzUwXSBjYWxsaW5nICByYW5kb21faW50X3NlY3JldF9p bml0KzB4MC8weDE5IEAgMQpzClsgICAgNS4wODk4MzhdIGNhbGxpbmcgIGxhdGVfcmVzdW1lX2lu aXQrMHgwLzB4ZjYgQCAxClsgICAgNS4wODk4NjBdICAgTWFnaWMgbnVtYmVyOiAxMTo5NDc6OTkK WyAgICA1LjA5MDAyMV0gaW5pdGNhbGwgbGF0ZV9yZXN1bWVfaW5pdCsweDAvMHhmNiByZXR1cm5l ZCAwIGFmdGVyIDE1NiB1c2VjcwpbICAgIDUuMDkwMDUzXSBjYWxsaW5nICBzY3NpX2NvbXBsZXRl X2FzeW5jX3NjYW5zKzB4MC8weDEwZCBAIDEKWyAgICA1LjA5MDA4MF0gaW5pdGNhbGwgc2NzaV9j b21wbGV0ZV9hc3luY19zY2FucysweDAvMHgxMGQgcmV0dXJuZWQgMCBhZnRlciAwIHVzZWNzClsg ICAgNS4wOTAwODZdIGNhbGxpbmcgIHJ0Y19oY3Rvc3lzKzB4MC8weDEwMiBAIDEKWyAgICA1LjA5 MDgwNV0gcnRjX2Ntb3MgMDA6MDY6IHNldHRpbmcgc3lzdGVtIGNsb2NrIHRvIDIwMTEtMDktMTMg MjM6MDU6NDcgVVRDICgxMzE1OTU1MTQ3KQpbICAgIDUuMDkwODM5XSBpbml0Y2FsbCBydGNfaGN0 b3N5cysweDAvMHgxMDIgcmV0dXJuZWQgMCBhZnRlciA2ODcgdXNlY3MKWyAgICA1LjA5MDg2OF0g Y2FsbGluZyAgcG93ZXJub3drOF9pbml0KzB4MC8weDFhZCBAIDEKWyAgICA1LjA5MDk0Nl0gaW5p dGNhbGwgcG93ZXJub3drOF9pbml0KzB4MC8weDFhZCByZXR1cm5lZCAtMTkgYWZ0ZXIgNTMgdXNl Y3MKWyAgICA1LjA5MDk3Nl0gY2FsbGluZyAgYWNwaV9jcHVmcmVxX2luaXQrMHgwLzB4ZmMgQCAx ClsgICAgNS4wOTE4MjJdIHNkIDA6MDowOjA6IEF0dGFjaGVkIHNjc2kgZ2VuZXJpYyBzZzAgdHlw ZSAwClsgICAgNS4wOTQwNjFdIGluaXRjYWxsIDJfYXN5bmNfcG9ydF9wcm9iZSsweDAvMHg0ZiBy ZXR1cm5lZCAwIGFmdGVyIDE2NTIzNiB1c2VjcwpbICAgIDUuMDk0MjI0XSBjYWxsaW5nICA0X3Nk X3Byb2JlX2FzeW5jKzB4MC8weDFjMiBAIDUKWyAgICA1LjA5NDkyMF0gc2QgMDowOjA6MDogW3Nk YV0gNzUyMDAyNjUgNTEyLWJ5dGUgbG9naWNhbCBibG9ja3M6ICgzOC41IEdCLzM1LjggR2lCKQpb ICAgIDUuMDk2NjMzXSBzZCAwOjA6MDowOiBbc2RhXSBXcml0ZSBQcm90ZWN0IGlzIG9mZgpbICAg IDUuMDk2NjU4XSBzZCAwOjA6MDowOiBbc2RhXSBNb2RlIFNlbnNlOiAwMCAzYSAwMCAwMApbICAg IDUuMDk3MzY0XSBzZCAwOjA6MDowOiBbc2RhXSBXcml0ZSBjYWNoZTogZW5hYmxlZCwgcmVhZCBj YWNoZTogZW5hYmxlZCwgZG9lc24ndCBzdXBwb3J0IERQTyBvciBGVUEKWyAgICA1LjA5OTY5MV0g YXRhMi4wMDogQVRBUEk6IFRTU1Rjb3JwQ0QtUlcvRFZELVJPTSBUU0w0NjJDLCBERTAxLCBtYXgg VURNQS8zMwpbICAgIDUuMTE3OTgyXSBpbml0Y2FsbCBhY3BpX2NwdWZyZXFfaW5pdCsweDAvMHhm YyByZXR1cm5lZCAwIGFmdGVyIDI2MzQ3IHVzZWNzClsgICAgNS4xMTgwMjFdIGNhbGxpbmcgIHBj Y19jcHVmcmVxX2luaXQrMHgwLzB4NGQxIEAgMQpbICAgIDUuMTE4MDk5XSBpbml0Y2FsbCBwY2Nf Y3B1ZnJlcV9pbml0KzB4MC8weDRkMSByZXR1cm5lZCAtMTkgYWZ0ZXIgNTMgdXNlY3MKWyAgICA1 LjExODEyN10gY2FsbGluZyAgY3B1ZnJlcV9wNF9pbml0KzB4MC8weDVjIEAgMQpbICAgIDUuMTE4 MTQ5XSBpbml0Y2FsbCBjcHVmcmVxX3A0X2luaXQrMHgwLzB4NWMgcmV0dXJuZWQgLTE5IGFmdGVy IDAgdXNlY3MKWyAgICA1LjExODE3NV0gY2FsbGluZyAgbWVtbWFwX2luaXQrMHgwLzB4MzEgQCAx ClsgICAgNS4xMTk0MTFdIGluaXRjYWxsIG1lbW1hcF9pbml0KzB4MC8weDMxIHJldHVybmVkIDAg YWZ0ZXIgMTE4NCB1c2VjcwpbICAgIDUuMTE5NDQwXSBjYWxsaW5nICBwY2lfbW1jZmdfbGF0ZV9p bnNlcnRfcmVzb3VyY2VzKzB4MC8weDViIEAgMQpbICAgIDUuMTE5NDczXSBpbml0Y2FsbCBwY2lf bW1jZmdfbGF0ZV9pbnNlcnRfcmVzb3VyY2VzKzB4MC8weDViIHJldHVybmVkIDAgYWZ0ZXIgNSB1 c2VjcwpbICAgIDUuMTE5NTA0XSBjYWxsaW5nICBuZXRfc2VjcmV0X2luaXQrMHgwLzB4MTkgQCAx ClsgICAgNS4xMTk1NTldIGluaXRjYWxsIG5ldF9zZWNyZXRfaW5pdCsweDAvMHgxOSByZXR1cm5l ZCAwIGFmdGVyIDMyIHVzZWNzClsgICAgNS4xMTk1ODZdIGNhbGxpbmcgIGluaXRfbmV0X2Ryb3Bf bW9uaXRvcisweDAvMHgxNTUgQCAxClsgICAgNS4xMTk2MDZdIEluaXRpYWxpemluZyBuZXR3b3Jr IGRyb3AgbW9uaXRvciBzZXJ2aWNlClsgICAgNS4xMTk4NzRdIGluaXRjYWxsIGluaXRfbmV0X2Ry b3BfbW9uaXRvcisweDAvMHgxNTUgcmV0dXJuZWQgMCBhZnRlciAyNTkgdXNlY3MKWyAgICA1LjEx OTkwNl0gY2FsbGluZyAgdGNwX2Nvbmdlc3Rpb25fZGVmYXVsdCsweDAvMHgxMiBAIDEKWyAgICA1 LjExOTkzM10gaW5pdGNhbGwgdGNwX2Nvbmdlc3Rpb25fZGVmYXVsdCsweDAvMHgxMiByZXR1cm5l ZCAwIGFmdGVyIDQgdXNlY3MKWyAgICA1LjExOTk2NF0gY2FsbGluZyAgaW5pdGlhbGl6ZV9oYXNo cm5kKzB4MC8weDE5IEAgMQpbICAgIDUuMTE5OTk4XSBpbml0Y2FsbCBpbml0aWFsaXplX2hhc2hy bmQrMHgwLzB4MTkgcmV0dXJuZWQgMCBhZnRlciAxMSB1c2VjcwpbICAgIDUuMTIyNDY2XSBhc3lu Y193YWl0aW5nIEAgMQpbICAgIDUuMTM1MzAwXSAgc2RhOiBzZGExIHNkYTIgc2RhMwpbICAgIDUu MTQ1MzMzXSBzZCAwOjA6MDowOiBbc2RhXSBBdHRhY2hlZCBTQ1NJIGRpc2sKWyAgICA1LjE0NTM2 N10gaW5pdGNhbGwgNF9zZF9wcm9iZV9hc3luYysweDAvMHgxYzIgcmV0dXJuZWQgMCBhZnRlciA0 OTkxNiB1c2VjcwpbICAgIDUuMTk2NTExXSBhdGEyLjAwOiBjb25maWd1cmVkIGZvciBVRE1BLzMz ClsgICAgNS4zNjg1NzhdIGFzeW5jX3dhaXRpbmcgQCAzOApbICAgIDUuMzY4NjAxXSBhc3luY19j b250aW51aW5nIEAgMzggYWZ0ZXIgMiB1c2VjClsgICAgNS40Mzc0ODddIHNjc2kgMTowOjA6MDog Q0QtUk9NICAgICAgICAgICAgVFNTVGNvcnAgQ0RSVy9EVkQgVFNMNDYyQyBERTAxIFBROiAwIEFO U0k6IDUKWyAgICA1LjUwNjczNV0gc3IwOiBzY3NpMy1tbWMgZHJpdmU6IDI0eC8yNHggd3JpdGVy IGNkL3J3IHhhL2Zvcm0yIGNkZGEgdHJheQpbICAgIDUuNTA2NzgyXSBjZHJvbTogVW5pZm9ybSBD RC1ST00gZHJpdmVyIFJldmlzaW9uOiAzLjIwClsgICAgNS41MTExNzVdIHNyIDE6MDowOjA6IEF0 dGFjaGVkIHNjc2kgQ0QtUk9NIHNyMApbICAgIDUuNTE0MTQxXSBzciAxOjA6MDowOiBBdHRhY2hl ZCBzY3NpIGdlbmVyaWMgc2cxIHR5cGUgNQpbICAgIDUuNTE1NDU1XSBpbml0Y2FsbCAzX2FzeW5j X3BvcnRfcHJvYmUrMHgwLzB4NGYgcmV0dXJuZWQgMCBhZnRlciA1NzYwNTYgdXNlY1sgICAgNS41 MTgyODBdIGFzeW5jX2NvbnRpbnVpbmcgQCAxIGFmdGVyIDM4NjUxMyB1c2VjClsgICAgNS41MjEw NjNdIEZyZWVpbmcgdW51c2VkIGtlcm5lbCBtZW1vcnk6IDI3ODRrIGZyZWVkClsgICAgNS41MjEw NjNdIFdyaXRlIHByb3RlY3RpbmcgdGhlIGtlcm5lbCByZWFkLW9ubHkgZGF0YTogMTAyNDBrClsg ICAgNS41NDUyMDFdIEZyZWVpbmcgdW51c2VkIGtlcm5lbCBtZW1vcnk6IDk0MGsgZnJlZWQKWyAg ICA1LjU0ODg0NV0gRnJlZWluZyB1bnVzZWQga2VybmVsIG1lbW9yeTogMTQyNGsgZnJlZWQKWyAg ICA1LjU3MzIxN10gbWtub2QgdXNlZCBncmVhdGVzdCBzdGFjayBkZXB0aDogNTEyMCBieXRlcyBs ZWZ0ClsgICAgNS43MzgzODVdIFN5bmFwdGljcyBUb3VjaHBhZCwgbW9kZWw6IDEsIGZ3OiA2LjIs IGlkOiAweDE4MGIxLCBjYXBzOiAweGEwNDcxMy8weDIwMDAwMC8weDAKWyAgICA1Ljc0ODA2OF0g bW91bnQgdXNlZCBncmVhdGVzdCBzdGFjayBkZXB0aDogNDk2OCBieXRlcyBsZWZ0ClsgICAgNS43 ODAwNjRdIGlucHV0OiBTeW5QUy8yIFN5bmFwdGljcyBUb3VjaFBhZCBhcyAvZGV2aWNlcy9wbGF0 Zm9ybS9pODA0Mi9zZXJpbzEvaW5wdXQvaW5wdXQ0ClsgICAgNi4wMTU0MDZdIGRyYWN1dDogZHJh Y3V0LTAwOS0xMi5mYzE1ClJ1bm5pbmcgaW4gUFYgY29udGV4dCBvbiBYZW4gdjQuMS4KWyAgICA2 LjIzODkzOV0gdWRldlsxMTRdOiBzdGFydGluZyB2ZXJzaW9uIDE2NwpbICAgIDYuNTQzMTE3XSB1 ZGV2YWRtIHVzZWQgZ3JlYXRlc3Qgc3RhY2sgZGVwdGg6IDQ5MDQgYnl0ZXMgbGVmdApbICAgIDYu NTY4MTQ5XSBjYWxsaW5nICBhY3BpX3ZpZGVvX2luaXQrMHgwLzB4ZmVlIFt2aWRlb10gQCAxMjIK WyAgICA3LjAzMzA2M10gY29uc29sZV9pbml0IHVzZWQgZ3JlYXRlc3Qgc3RhY2sgZGVwdGg6IDQ4 NDggYnl0ZXMgbGVmdApbICAgIDcuMTAxMTc1XSBhY3BpIGRldmljZToyODogcmVnaXN0ZXJlZCBh cyBjb29saW5nX2RldmljZTIKWyAgICA3LjExMDIxOV0gaW5wdXQ6IFZpZGVvIEJ1cyBhcyAvZGV2 aWNlcy9MTlhTWVNUTTowMC9kZXZpY2U6MDAvUE5QMEEwMzowMC9MTlhWSURFTzowMS9pbnB1dC9p bnB1dDUKWyAgICA3LjExMjAyNF0gQUNQSTogVmlkZW8gRGV2aWNlIFtWSUQxXSAobXVsdGktaGVh ZDogeWVzICByb206IG5vICBwb3N0OiBubykKWyAgICA3LjExMjY0Nl0gW0Zpcm13YXJlIEJ1Z106 IER1cGxpY2F0ZSBBQ1BJIHZpZGVvIGJ1cyBkZXZpY2VzIGZvciB0aGUgc2FtZSBWR0EgY29udHJv bGxlciwgcGxlYXNlIHRyeSBtb2R1bGUgcGFyYW1ldGVyICJ2aWRlby5hbGxvd19kdXBsaWNhdGVz PTEiaWYgdGhlIGN1cnJlbnQgZHJpdmVyIGRvZXNuJ3Qgd29yay4KWyAgICA3LjExMzA2N10gaW5p dGNhbGwgYWNwaV92aWRlb19pbml0KzB4MC8weGZlZSBbdmlkZW9dIHJldHVybmVkIDAgYWZ0ZXIg NTMyMTAyIHVzZWNzClsgICAgNy4xMjE5NDBdIGNhbGxpbmcgIGkyY19pbml0KzB4MC8weDEwMDAg W2kyY19jb3JlXSBAIDEyMgpbICAgIDcuMTIyOTU2XSBpbml0Y2FsbCBpMmNfaW5pdCsweDAvMHgx MDAwIFtpMmNfY29yZV0gcmV0dXJuZWQgMCBhZnRlciA5NTQgdXNlY3MKWyAgICA3LjE0NzM4M10g Y2FsbGluZyAgZHJtX2NvcmVfaW5pdCsweDAvMHgxMDAwIFtkcm1dIEAgMTIyClsgICAgNy4xNDc4 NTBdIFtkcm1dIEluaXRpYWxpemVkIGRybSAxLjEuMCAyMDA2MDgxMApbICAgIDcuMTQ3ODg2XSBp bml0Y2FsbCBkcm1fY29yZV9pbml0KzB4MC8weDEwMDAgW2RybV0gcmV0dXJuZWQgMCBhZnRlciA0 NDYgdXNlY3MKWyAgICA3LjE4NjIxM10gY2FsbGluZyAgaTkxNV9pbml0KzB4MC8weDhkIFtpOTE1 XSBAIDEyMgpbICAgIDcuMTg2OTg1XSB4ZW46IHJlZ2lzdGVyaW5nIGdzaSAxNiB0cmlnZ2VyaW5n IDAgcG9sYXJpdHkgMQpbICAgIDcuMTg3MDE3XSB4ZW5fbWFwX3BpcnFfZ3NpOiByZXR1cm5pbmcg aXJxIDE2IGZvciBnc2kgMTYKWyAgICA3LjE4NzAzOV0geGVuOiAtLT4gcGlycT0xNiAtPiBpcnE9 MTYgKGdzaT0xNikKWyAgICA3LjE4NzA5M10gQWxyZWFkeSBzZXR1cCB0aGUgR1NJIDoxNgpbICAg IDcuMTg3MTE1XSBwY2kgMDAwMDowMDowMi4wOiBQQ0kgSU5UIEEgLT4gR1NJIDE2IChsZXZlbCwg bG93KSAtPiBJUlEgMTYKWyAgICA3LjE4NzE1NV0gcGNpIDAwMDA6MDA6MDIuMDogc2V0dGluZyBs YXRlbmN5IHRpbWVyIHRvIDY0ClsgICAgNy42MjY1MzddIFtkcm1dIE1UUlIgYWxsb2NhdGlvbiBm YWlsZWQuICBHcmFwaGljcyBwZXJmb3JtYW5jZSBtYXkgc3VmZmVyLgpbICAgIDcuNjQ0NzAxXSBb ZHJtXSBTdXBwb3J0cyB2YmxhbmsgdGltZXN0YW1wIGNhY2hpbmcgUmV2IDEgKDEwLjEwLjIwMTAp LgpbICAgIDcuNjQ0NzM0XSBbZHJtXSBObyBkcml2ZXIgc3VwcG9ydCBmb3IgdmJsYW5rIHRpbWVz dGFtcCBxdWVyeS4KWyAgICA3LjY0NDkxN10gW2RybV0gSW5pdGlhbGl6ZWQgaTkxNSAxLjYuMCAy MDA4MDczMCBmb3IgMDAwMDowMDowMi4wIG9uIG1pbm9yIDAKWyAgICA3LjY0NTA2Nl0gaW5pdGNh bGwgaTkxNV9pbml0KzB4MC8weDhkIFtpOTE1XSByZXR1cm5lZCAwIGFmdGVyIDQ0OTc2NCB1c2Vj cwpbICAgIDcuNjQ5NTIwXSBtb2Rwcm9iZSB1c2VkIGdyZWF0ZXN0IHN0YWNrIGRlcHRoOiA0NDk2 IGJ5dGVzIGxlZnQKWyAgICA3LjczOTYxOV0gZHJhY3V0OiBTdGFydGluZyBwbHltb3V0aCBkYWVt b24KWyAgICA4LjM0NjAxMl0gdWRldmFkbSB1c2VkIGdyZWF0ZXN0IHN0YWNrIGRlcHRoOiA0Mjg4 IGJ5dGVzIGxlZnQKWyAgICA4LjczMzM4NF0gY2FsbGluZyAgYWNwaV93bWlfaW5pdCsweDAvMHgx MDAwIFt3bWldIEAgMjIwClsgICAgOC43NjY4MjVdIHdtaTogTWFwcGVyIGxvYWRlZApbICAgIDgu NzY2ODYyXSBpbml0Y2FsbCBhY3BpX3dtaV9pbml0KzB4MC8weDEwMDAgW3dtaV0gcmV0dXJuZWQg MCBhZnRlciAzMjY1MiB1c2VjcwpbICAgIDkuMTE0NjY5XSBjYWxsaW5nICBmd19jb3JlX2luaXQr MHgwLzB4MTAwMCBbZmlyZXdpcmVfY29yZV0gQCAyMzkKWyAgICA5LjEzMTc5N10gaW5pdGNhbGwg ZndfY29yZV9pbml0KzB4MC8weDEwMDAgW2ZpcmV3aXJlX2NvcmVdIHJldHVybmVkIDAgYWZ0ZXIg MTY2NzUgdXNlY3MKWyAgICA5LjE0MDY3NF0gY2FsbGluZyAgZndfb2hjaV9pbml0KzB4MC8weDEw MDAgW2ZpcmV3aXJlX29oY2ldIEAgMjM5ClsgICAgOS4xNDExMjFdIHhlbjogcmVnaXN0ZXJpbmcg Z3NpIDE5IHRyaWdnZXJpbmcgMCBwb2xhcml0eSAxClsgICAgOS4xNDExNTRdIHhlbl9tYXBfcGly cV9nc2k6IHJldHVybmluZyBpcnEgMTkgZm9yIGdzaSAxOQpbICAgIDkuMTQxMTc2XSB4ZW46IC0t PiBwaXJxPTE5IC0+IGlycT0xOSAoZ3NpPTE5KQpbICAgIDkuMTQxMjE5XSBmaXJld2lyZV9vaGNp IDAwMDA6MDM6MDEuMDogUENJIElOVCBBIC0+IEdTSSAxOSAobGV2ZWwsIGxvdykgLT4gSVJRIDE5 ClsgICAgOS4xNzI3MjVdIGNhbGxpbmcgIG1tY19pbml0KzB4MC8weDEwMDAgW21tY19jb3JlXSBA IDI0MApbICAgIDkuMTczODE5XSBpbml0Y2FsbCBtbWNfaW5pdCsweDAvMHgxMDAwIFttbWNfY29y ZV0gcmV0dXJuZWQgMCBhZnRlciAxMDI3IHVzZWNzClsgICAgOS4xODU3NTRdIGNhbGxpbmcgIHNk aGNpX2Rydl9pbml0KzB4MC8weDEwMDAgW3NkaGNpXSBAIDI0MApbICAgIDkuMTg1NzkyXSBzZGhj aTogU2VjdXJlIERpZ2l0YWwgSG9zdCBDb250cm9sbGVyIEludGVyZmFjZSBkcml2ZXIKWyAgICA5 LjE4NTgxN10gc2RoY2k6IENvcHlyaWdodChjKSBQaWVycmUgT3NzbWFuClsgICAgOS4xODU4NDFd IGluaXRjYWxsIHNkaGNpX2Rydl9pbml0KzB4MC8weDEwMDAgW3NkaGNpXSByZXR1cm5lZCAwIGFm dGVyIDQ0IHVzZWNzClsgICAgOS4xOTQ5OTddIGNhbGxpbmcgIHNkaGNpX2Rydl9pbml0KzB4MC8w eDEwMDAgW3NkaGNpX3BjaV0gQCAyNDAKKFhFTikgaXJxLmM6MTE5NTpkMCBDYW5ub3QgYmluZCBJ UlEgMTkgdG8gZ3Vlc3QuIEluIHVzZSBieSAnbnMxNjU1MCcuClsgICAgOS4yMDUyODldIGZpcmV3 aXJlX29oY2k6IEFkZGVkIGZ3LW9oY2kgZGV2aWNlIDAwMDA6MDM6MDEuMCwgT0hDSSB2MS4xMCwg NCBJUiArIDQgSVQgY29udGV4dHMsIHF1aXJrcyAweDEKWyAgICA5LjIwNjU4M10gc2RoY2ktcGNp IDAwMDA6MDM6MDEuMTogU0RIQ0kgY29udHJvbGxlciBmb3VuZCBbMTE4MDowODIyXSAocmV2IDE5 KQpbICAgIDkuMjA2NjY0XSB4ZW46IHJlZ2lzdGVyaW5nIGdzaSAxOCB0cmlnZ2VyaW5nIDAgcG9s YXJpdHkgMQpbICAgIDkuMjA2Njk4XSBCVUc6IHNsZWVwaW5nIGZ1bmN0aW9uIGNhbGxlZCBmcm9t IGludmFsaWQgY29udGV4dCBhdCBrZXJuZWwvbXV0ZXguYzoyNzEKWyAgICA5LjIwNjcyOV0gaW5f YXRvbWljKCk6IDEsIGlycXNfZGlzYWJsZWQoKTogMCwgcGlkOiAyNDAsIG5hbWU6IG1vZHByb2Jl ClsgICAgOS4yMDY3NTZdIDMgbG9ja3MgaGVsZCBieSBtb2Rwcm9iZS8yNDA6ClsgICAgOS4yMDY3 NzJdICAjMDogICgmX19sb2NrZGVwX25vX3ZhbGlkYXRlX18pey4uLi4uLn0sIGF0OiBbPGZmZmZm ZmZmODEzMTc2ZDA+XSBfX2RyaXZlcl9hdHRhY2grMHgzYi8weDgyClsgICAgOS4yMDY4MjldICAj MTogICgmX19sb2NrZGVwX25vX3ZhbGlkYXRlX18pey4uLi4uLn0sIGF0OiBbPGZmZmZmZmZmODEz MTc2ZGU+XSBfX2RyaXZlcl9hdHRhY2grMHg0OS8weDgyClsgICAgOS4yMDY4ODFdICAjMjogIChp cnFfbWFwcGluZ191cGRhdGVfbG9jayl7Ky4rLisufSwgYXQ6IFs8ZmZmZmZmZmY4MTJkYTRkYT5d IHhlbl9iaW5kX3BpcnFfZ3NpX3RvX2lycSsweDJlLzB4MWEyClsgICAgOS4yMDY5NDFdIFBpZDog MjQwLCBjb21tOiBtb2Rwcm9iZSBOb3QgdGFpbnRlZCAzLjEuMC0wLnJjNi5naXQwLjAuZmMxNy54 ODZfNjQgIzEKWyAgICA5LjIwNjk3MF0gQ2FsbCBUcmFjZToKWyAgICA5LjIwNjk4OV0gIFs8ZmZm ZmZmZmY4MTA0ZjZkNT5dIF9fbWlnaHRfc2xlZXArMHgxMDMvMHgxMDgKWyAgICA5LjIwNzAxNV0g IFs8ZmZmZmZmZmY4MTUwMzVmMj5dIG11dGV4X2xvY2tfbmVzdGVkKzB4MjUvMHg0NQpbICAgIDku MjA3MDQ1XSAgWzxmZmZmZmZmZjgxNGUxM2NkPl0gX19pcnFfYWxsb2NfZGVzY3MrMHg1MC8weDE4 YgpbICAgIDkuMjA3MDUyXSAgWzxmZmZmZmZmZjgxMmRhNTVlPl0geGVuX2JpbmRfcGlycV9nc2lf dG9faXJxKzB4YjIvMHgxYTIKWyAgICA5LjIwNzA1Ml0gIFs8ZmZmZmZmZmY4MTA4YWRkOD5dID8g YXJjaF9sb2NhbF9pcnFfcmVzdG9yZSsweGIvMHhkClsgICAgOS4yMDcwNTJdICBbPGZmZmZmZmZm ODE0MDAwNmM+XSB4ZW5fcmVnaXN0ZXJfcGlycSsweDhiLzB4YjcKWyAgICA5LjIwNzA1Ml0gIFs8 ZmZmZmZmZmY4MTQwMDI1OD5dIHhlbl9yZWdpc3Rlcl9nc2kucGFydC4yKzB4NDEvMHg5ZgpbICAg IDkuMjA3MDUyXSAgWzxmZmZmZmZmZjgxNDAwMmQ0Pl0gYWNwaV9yZWdpc3Rlcl9nc2lfeGVuKzB4 MWUvMHgyMApbICAgIDkuMjA3MDUyXSAgWzxmZmZmZmZmZjgxMDI1NmRmPl0gYWNwaV9yZWdpc3Rl cl9nc2krMHhmLzB4MTgKWyAgICA5LjIwNzA1Ml0gIFs8ZmZmZmZmZmY4MTJhMDg4Yz5dIGFjcGlf cGNpX2lycV9lbmFibGUrMHgxNzIvMHgyNDYKWyAgICA5LjIwNzA1Ml0gIFs8ZmZmZmZmZmY4MTQw MTk4Mj5dIHBjaWJpb3NfZW5hYmxlX2RldmljZSsweDJiLzB4MzAKWyAgICA5LjIwNzA1Ml0gIFs8 ZmZmZmZmZmY4MTI2YzBhNz5dIGRvX3BjaV9lbmFibGVfZGV2aWNlKzB4MzAvMHg0OApbICAgIDku MjA3MDUyXSAgWzxmZmZmZmZmZjgxMjZjMTM2Pl0gX19wY2lfZW5hYmxlX2RldmljZV9mbGFncysw eDc3LzB4OGEKWyAgICA5LjIwNzA1Ml0gIFs8ZmZmZmZmZmY4MTI2YzE1Yz5dIHBjaV9lbmFibGVf ZGV2aWNlKzB4MTMvMHgxNQpbICAgIDkuMjA3MDUyXSAgWzxmZmZmZmZmZmEwMGRlYjFiPl0gc2Ro Y2lfcGNpX3Byb2JlKzB4ZjAvMHg0MTYgW3NkaGNpX3BjaV0KWyAgICA5LjIwNzA1Ml0gIFs8ZmZm ZmZmZmY4MTAwN2Q1Zj5dID8geGVuX3Jlc3RvcmVfZmxfZGlyZWN0X3JlbG9jKzB4NC8weDQKWyAg ICA5LjIwNzA1Ml0gIFs8ZmZmZmZmZmY4MTA5NTdkNz5dID8gYXJjaF9sb2NhbF9pcnFfcmVzdG9y ZSsweGIvMHhkClsgICAgOS4yMDcwNTJdICBbPGZmZmZmZmZmODE1MDRlN2Y+XSA/IF9yYXdfc3Bp bl91bmxvY2tfaXJxcmVzdG9yZSsweDRkLzB4NjEKWyAgICA5LjIwNzA1Ml0gIFs8ZmZmZmZmZmY4 MTI2ZDA0Mz5dIGxvY2FsX3BjaV9wcm9iZSsweDQ0LzB4NzUKWyAgICA5LjIwNzA1Ml0gIFs8ZmZm ZmZmZmY4MTI2ZGJjOT5dIHBjaV9kZXZpY2VfcHJvYmUrMHhkMC8weGZmClsgICAgOS4yMDcwNTJd ICBbPGZmZmZmZmZmODEzMTc1YjM+XSBkcml2ZXJfcHJvYmVfZGV2aWNlKzB4MTMxLzB4MjEzClsg ICAgOS4yMDcwNTJdICBbPGZmZmZmZmZmODEzMTc2ZjM+XSBfX2RyaXZlcl9hdHRhY2grMHg1ZS8w eDgyClsgICAgOS4yMDcwNTJdICBbPGZmZmZmZmZmODEzMTc2OTU+XSA/IGRyaXZlcl9wcm9iZV9k ZXZpY2UrMHgyMTMvMHgyMTMKWyAgICA5LjIwNzA1Ml0gIFs8ZmZmZmZmZmY4MTMxNjVmND5dIGJ1 c19mb3JfZWFjaF9kZXYrMHg1OS8weDhmClsgICAgOS4yMDcwNTJdICBbPGZmZmZmZmZmODEzMTcx ODc+XSBkcml2ZXJfYXR0YWNoKzB4MWUvMHgyMApbICAgIDkuMjA3MDUyXSAgWzxmZmZmZmZmZjgx MzE2ZDlmPl0gYnVzX2FkZF9kcml2ZXIrMHhkNC8weDIyYQpbICAgIDkuMjA3MDUyXSAgWzxmZmZm ZmZmZmEwMTA2MDAwPl0gPyAweGZmZmZmZmZmYTAxMDVmZmYKWyAgICA5LjIwNzA1Ml0gIFs8ZmZm ZmZmZmY4MTMxN2JiNj5dIGRyaXZlcl9yZWdpc3RlcisweDk4LzB4MTA1ClsgICAgOS4yMDcwNTJd ICBbPGZmZmZmZmZmYTAxMDYwMDA+XSA/IDB4ZmZmZmZmZmZhMDEwNWZmZgpbICAgIDkuMjA3MDUy XSAgWzxmZmZmZmZmZmEwMTA2MDAwPl0gPyAweGZmZmZmZmZmYTAxMDVmZmYKWyAgICA5LjIwNzA1 Ml0gIFs8ZmZmZmZmZmZhMDEwNjAxZT5dIHNkaGNpX2Rydl9pbml0KzB4MWUvMHgxMDAwIFtzZGhj aV9wY2ldClsgICAgOS4yMDcwNTJdICBbPGZmZmZmZmZmODEwMDIwNzE+XSBkb19vbmVfaW5pdGNh bGwrMHg1Ny8weDEzYQpbICAgIDkuMjA3MDUyXSAgWzxmZmZmZmZmZmEwMTA2MDAwPl0gPyAweGZm ZmZmZmZmYTAxMDVmZmYKWyAgICA5LjIwNzA1Ml0gIFs8ZmZmZmZmZmY4MTA5YTY3MD5dIHN5c19p bml0X21vZHVsZSsweDExNC8weDI2NwpbICAgIDkuMjA3MDUyXSAgWzxmZmZmZmZmZjgxNTBiYzgy Pl0gc3lzdGVtX2NhbGxfZmFzdHBhdGgrMHgxNi8weDFiClsgICAgOS4yMDgxNTddIHhlbjogLS0+ IHBpcnE9MTggLT4gaXJxPTE4IChnc2k9MTgpClsgICAgOS4yMDgxOTBdIHNkaGNpLXBjaSAwMDAw OjAzOjAxLjE6IFBDSSBJTlQgQiAtPiBHU0kgMTggKGxldmVsLCBsb3cpIC0+IElSUSAxOApbICAg IDkuMjExNjE5XSBpbml0Y2FsbCBmd19vaGNpX2luaXQrMHgwLzB4MTAwMCBbZmlyZXdpcmVfb2hj aV0gcmV0dXJuZWQgMCBhZnRlciA2OTIyOCB1c2VjcwpbICAgIDkuMjQyOTc3XSBSZWdpc3RlcmVk IGxlZCBkZXZpY2U6IG1tYzA6OgpbICAgIDkuMjQ1MzE4XSBtbWMwOiBTREhDSSBjb250cm9sbGVy IG9uIFBDSSBbMDAwMDowMzowMS4xXSB1c2luZyBETUEKWyAgICA5LjI0NTMxOF0gaW5pdGNhbGwg c2RoY2lfZHJ2X2luaXQrMHgwLzB4MTAwMCBbc2RoY2lfcGNpXSByZXR1cm5lZCAwIGFmdGVyIDQ5 NTMzIHVzZWNzClsgICAxMS43NzEyNDFdIGNkcm9tX2lkIHVzZWQgZ3JlYXRlc3Qgc3RhY2sgZGVw dGg6IDM2MDAgYnl0ZXMgbGVmdApbICAgMTUuNzc3OTkwXSBkcmFjdXQ6IFNjYW5uaW5nIGRldmlj ZXMgc2RhMyAgZm9yIExWTSB2b2x1bWUgZ3JvdXBzClsgICAxNS45NTUwMzBdIGRyYWN1dDogUmVh ZGluZyBhbGwgcGh5c2ljYWwgdm9sdW1lcy4gVGhpcyBtYXkgdGFrZSBhIHdoaWxlLi4uClsgICAx NS45NTYxMDNdIGRyYWN1dDogRm91bmQgdm9sdW1lIGdyb3VwICJ2Z19pbnNwNjQwMCIgdXNpbmcg bWV0YWRhdGEgdHlwZSBsdm0yClsgICAxNi45NTc0MDddIGRyYWN1dDogMiBsb2dpY2FsIHZvbHVt ZShzKSBpbiB2b2x1bWUgZ3JvdXAgInZnX2luc3A2NDAwIiBub3cgYWN0aXZlClsgICAxNy4xNzEx NTZdIEVYVDQtZnMgKGRtLTApOiBJTkZPOiByZWNvdmVyeSByZXF1aXJlZCBvbiByZWFkb25seSBm aWxlc3lzdGVtClsgICAxNy4xNzEyODFdIEVYVDQtZnMgKGRtLTApOiB3cml0ZSBhY2Nlc3Mgd2ls bCBiZSBlbmFibGVkIGR1cmluZyByZWNvdmVyeQpbICAgMTkuOTM4NzMzXSBFWFQ0LWZzIChkbS0w KTogcmVjb3ZlcnkgY29tcGxldGUKWyAgIDE5Ljk0Mjg2NV0gRVhUNC1mcyAoZG0tMCk6IG1vdW50 ZWQgZmlsZXN5c3RlbSB3aXRoIG9yZGVyZWQgZGF0YSBtb2RlLiBPcHRzOiAobnVsbCkKWyAgIDE5 Ljk1NDg5Ml0gbW91bnQgdXNlZCBncmVhdGVzdCBzdGFjayBkZXB0aDogMzQ4OCBieXRlcyBsZWZ0 ClsgICAyMC4yOTM2NDFdIGRyYWN1dDogQ2hlY2tpbmcgZmlsZXN5c3RlbXMKWyAgIDIwLjI5NDQ0 MF0gZHJhY3V0OiBmc2NrIC1UIC10IG5vb3B0cz1fbmV0ZGV2IC1BIC1hClsgICAyMC42MjM5MzJd IGRyYWN1dDogL2Rldi9tYXBwZXIvdmdfaW5zcDY0MDAtbHZfcm9vdDogY2xlYW4sIDM1ODM3Ni8y MDcyNTc2IGZpbGVzLCA3NDE2MDQzLzgyODEwODggYmxvY2tzClsgICAyMC42MjY0NTBdIGRyYWN1 dDogUmVtb3VudGluZyAvZGV2L21hcHBlci92Z19pbnNwNjQwMC1sdl9yb290IHdpdGggLW8gcm8s ClsgICAyMC42OTg4NDldIEVYVDQtZnMgKGRtLTApOiBtb3VudGVkIGZpbGVzeXN0ZW0gd2l0aCBv cmRlcmVkIGRhdGEgbW9kZS4gT3B0czogKG51bGwpClsgICAyMC43MjgzOTldIGRyYWN1dDogTW91 bnRlZCByb290IGZpbGVzeXN0ZW0gL2Rldi9tYXBwZXIvdmdfaW5zcDY0MDAtbHZfcm9vdApbICAg MjEuNTA5ODE0XSBkcmFjdXQ6IFN3aXRjaGluZyByb290ClsgICAyMy43NDU0MThdIFNFTGludXg6 IDIwNDggYXZ0YWIgaGFzaCBzbG90cywgMjI1OTEyIHJ1bGVzLgpbICAgMjguMzM4MDY5XSBTRUxp bnV4OiAyMDQ4IGF2dGFiIGhhc2ggc2xvdHMsIDIyNTkxMiBydWxlcy4KWyAgIDQxLjMwNzM5M10g U0VMaW51eDogIDkgdXNlcnMsIDEzIHJvbGVzLCAzNjQxIHR5cGVzLCAxOTIgYm9vbHMsIDEgc2Vu cywgMTAyNCBjYXRzClsgICA0MS4zMDc0ODhdIFNFTGludXg6ICA4MSBjbGFzc2VzLCAyMjU5MTIg cnVsZXMKWyAgIDQxLjcwOTA3Ml0gU0VMaW51eDogIENvbXBsZXRpbmcgaW5pdGlhbGl6YXRpb24u ClsgICA0MS43MDkwNzJdIFNFTGludXg6ICBTZXR0aW5nIHVwIGV4aXN0aW5nIHN1cGVyYmxvY2tz LgpbICAgNDEuNzA5MDcyXSBTRUxpbnV4OiBpbml0aWFsaXplZCAoZGV2IHN5c2ZzLCB0eXBlIHN5 c2ZzKSwgdXNlcyBnZW5mc19jb250ZXh0cwpbICAgNDEuNzA5MDcyXSBTRUxpbnV4OiBpbml0aWFs aXplZCAoZGV2IHJvb3RmcywgdHlwZSByb290ZnMpLCB1c2VzIGdlbmZzX2NvbnRleHRzClsgICA0 MS43MDkwNzJdIFNFTGludXg6IGluaXRpYWxpemVkIChkZXYgYmRldiwgdHlwZSBiZGV2KSwgdXNl cyBnZW5mc19jb250ZXh0cwpbICAgNDEuNzA5MDcyXSBTRUxpbnV4OiBpbml0aWFsaXplZCAoZGV2 IHByb2MsIHR5cGUgcHJvYyksIHVzZXMgZ2VuZnNfY29udGV4dHMKWyAgIDQxLjcwOTA3Ml0gU0VM aW51eDogaW5pdGlhbGl6ZWQgKGRldiB0bXBmcywgdHlwZSB0bXBmcyksIHVzZXMgdHJhbnNpdGlv biBTSURzClsgICA0MS43MDkwNzJdIFNFTGludXg6IGluaXRpYWxpemVkIChkZXYgZGV2dG1wZnMs IHR5cGUgZGV2dG1wZnMpLCB1c2VzIHRyYW5zaXRpb24gU0lEcwpbICAgNDEuNzEyNzkyXSBTRUxp bnV4OiBpbml0aWFsaXplZCAoZGV2IHNvY2tmcywgdHlwZSBzb2NrZnMpLCB1c2VzIHRhc2sgU0lE cwpbICAgNDEuNzEyNzkyXSBTRUxpbnV4OiBpbml0aWFsaXplZCAoZGV2IGRlYnVnZnMsIHR5cGUg ZGVidWdmcyksIHVzZXMgZ2VuZnNfY29udGV4dHMKWyAgIDQxLjcyODA2NV0gU0VMaW51eDogaW5p dGlhbGl6ZWQgKGRldiBwaXBlZnMsIHR5cGUgcGlwZWZzKSwgdXNlcyB0YXNrIFNJRHMKWyAgIDQx LjcyODA2NV0gU0VMaW51eDogaW5pdGlhbGl6ZWQgKGRldiBhbm9uX2lub2RlZnMsIHR5cGUgYW5v bl9pbm9kZWZzKSwgdXNlcyBnZW5mc19jb250ZXh0cwpbICAgNDEuNzI4MDY1XSBTRUxpbnV4OiBp bml0aWFsaXplZCAoZGV2IGRldnB0cywgdHlwZSBkZXZwdHMpLCB1c2VzIHRyYW5zaXRpb24gU1sg ICA0MS43MjgwNjVdIFNFTGludXg6IGluaXRpYWxpemVkIChkZXYgaHVnZXRsYmZzLCB0eXBlIGh1 Z2V0bGJmcyksIHVzZXMgdHJhbnNpdGlvbiBTSURzClsgICA0MS43MjgwNjVdIFNFTGludXg6IGlu aXRpYWxpemVkIChkZXYgbXF1ZXVlLCB0eXBlIG1xdWV1ZSksIHVzZXMgdHJhbnNpdGlvbiBTSURz ClsgICA0MS43MjgwNjVdIFNFTGludXg6IGluaXRpYWxpemVkIChkZXYgc2VsaW51eGZzLCB0eXBl IHNlbGludXhmcyksIHVzZXMgZ2VuZnNfY29udGV4dHMKWyAgIDQxLjcyODA2NV0gU0VMaW51eDog aW5pdGlhbGl6ZWQgKGRldiB1c2JmcywgdHlwZSB1c2JmcyksIHVzZXMgZ2VuZnNfY29udGV4dHMK WyAgIDQxLjcyODA2NV0gU0VMaW51eDogaW5pdGlhbGl6ZWQgKGRldiBzZWN1cml0eWZzLCB0eXBl IHNlY3VyaXR5ZnMpLCB1c2VzIGdlbmZzX2NvbnRleHRzClsgICA0MS43MjgwNjVdIFNFTGludXg6 IGluaXRpYWxpemVkIChkZXYgc3lzZnMsIHR5cGUgc3lzZnMpLCB1c2VzIGdlbmZzX2NvbnRleHRz ClsgICA0MS43NDcyMjNdIFNFTGludXg6IGluaXRpYWxpemVkIChkZXYgdG1wZnMsIHR5cGUgdG1w ZnMpLCB1c2VzIHRyYW5zaXRpb24gU0lEcwpbICAgNDEuNzQ3MjIzXSBTRUxpbnV4OiBpbml0aWFs aXplZCAoZGV2IHRtcGZzLCB0eXBlIHRtcGZzKSwgdXNlcyB0cmFuc2l0aW9uIFNJRHMKWyAgIDQx Ljc1Mzk0MF0gU0VMaW51eDogaW5pdGlhbGl6ZWQgKGRldiBkbS0wLCB0eXBlIGV4dDQpLCB1c2Vz IHhhdHRyClsgICA0MS44NzIwNjZdIHR5cGU9MTQwMyBhdWRpdCgxMzE1OTU1MTg0LjI4MDoyKTog cG9saWN5IGxvYWRlZCBhdWlkPTQyOTQ5NjcyOTUgc2VzPTQyOTQ5NjcyOTUKWyAgIDQyLjczMTc1 MV0gU0VMaW51eDogaW5pdGlhbGl6ZWQgKGRldiB0bXBmcywgdHlwZSB0bXBmcyksIHVzZXMgdHJh bnNpdGlvbiBTSURzClsgICA0Mi43NDAyMjRdIFNFTGludXg6IGluaXRpYWxpemVkIChkZXYgY2dy b3VwLCB0eXBlIGNncm91cCksIHVzZXMgZ2VuZnNfY29udGV4dHMKWyAgIDQzLjM4NTk5NV0gU0VM aW51eDogaW5pdGlhbGl6ZWQgKGRldiBjZ3JvdXAsIHR5cGUgY2dyb3VwKSwgdXNlcyBnZW5mc19j b250ZXh0cwpbICAgNDMuMzkyMzQ2XSBTRUxpbnV4OiBpbml0aWFsaXplZCAoZGV2IGNncm91cCwg dHlwZSBjZ3JvdXApLCB1c2VzIGdlbmZzX2NvbnRleHRzClsgICA0My4zOTg2NDddIFNFTGludXg6 IGluaXRpYWxpemVkIChkZXYgY2dyb3VwLCB0eXBlIGNncm91cCksIHVzZXMgZ2VuZnNfY29udGV4 dHMKWyAgIDQzLjQwNjEzNV0gU0VMaW51eDogaW5pdGlhbGl6ZWQgKGRldiBjZ3JvdXAsIHR5cGUg Y2dyb3VwKSwgdXNlcyBnZW5mc19jb250ZXh0cwpbICAgNDMuNDEyMDc4XSBTRUxpbnV4OiBpbml0 aWFsaXplZCAoZGV2IGNncm91cCwgdHlwZSBjZ3JvdXApLCB1c2VzIGdlbmZzX2NvbnRleHRzClsg ICA0My40MTgyNzNdIFNFTGludXg6IGluaXRpYWxpemVkIChkZXYgY2dyb3VwLCB0eXBlIGNncm91 cCksIHVzZXMgZ2VuZnNfY29udGV4dHMKWyAgIDQzLjQyNDAwOV0gU0VMaW51eDogaW5pdGlhbGl6 ZWQgKGRldiBjZ3JvdXAsIHR5cGUgY2dyb3VwKSwgdXNlcyBnZW5mc19jb250ZXh0cwpbICAgNDMu NDMxOTM2XSBTRUxpbnV4OiBpbml0aWFsaXplZCAoZGV2IGNncm91cCwgdHlwZSBjZ3JvdXApLCB1 c2VzIGdlbmZzX2NvbnRleHRzClsgICA0My40MzgxNDBdIFNFTGludXg6IGluaXRpYWxpemVkIChk ZXYgY2dyb3VwLCB0eXBlIGNncm91cCksIHVzZXMgZ2VuZnNfY29udGV4dHMKWyAgIDQzLjU0NDQ3 Ml0gc3lzdGVtZFsxXTogc3lzdGVtZCAyNiBydW5uaW5nIGluIHN5c3RlbSBtb2RlLiAoK1BBTSAr TElCV1JBUCArQVVESVQgK1NFTElOVVggK1NZU1ZJTklUICtMSUJDUllQVFNFVFVQOyBmZWRvcmEp CgpXZWxjb21lIHRvIEZlZG9yYSByZWxlYXNlIDE1IChMb3ZlbG9jaykhCgpbICAgNDMuNTkxNTEz XSBzeXN0ZW1kWzFdOiBTZXQgaG9zdG5hbWUgdG8gPGluc3A2NDAwPi4KWyAgIDQ0LjM1MTQ3NV0g c3lzdGVtZC1nZXR0eS1nZW5lcmF0b3JbMzU5XTogRmFpbGVkIHRvIGNyZWF0ZSBzeW1saW5rIGZy b20gL2xpYi9zeXN0ZW1kL3N5c3RlbS9zZXJpYWwtZ2V0dHlALnNlcnZpY2UgdG8gL3J1bi9zeXN0 ZW1kL2dlbmVyYXRvci9nZXR0eS50YXJnZXQud2FudHMvc2VyaWFsLWdldHR5QGh2YzAuc2Vydmlj ZTogRmlsZSBleGlzdHMKWyAgIDQ0LjM1OTI0MF0gc3lzdGVtZFsxXTogL2xpYi9zeXN0ZW1kL3N5 c3RlbS1nZW5lcmF0b3JzL3N5c3RlbWQtZ2V0dHktZ2VuZXJhdG9yIGV4aXRlZCB3aXRoIGV4aXQg c3RhdHVzIDEuClN0YXJ0aW5nIEJvb3R1cCBoYWNrLi4uClN0YXJ0aW5nIExvYWQgbGVnYWN5IG1v ZHVsZSBjb25maWd1cmF0aW9uLi4uClsgICA0OS40NzIwNjddIHRvdWNoIHVzZWQgZ3JlYXRlc3Qg c3RhY2sgZGVwdGg6IDMzMTIgYnl0ZXMgbGVmdApbICAgNDkuNDk1MDAyXSBTRUxpbnV4OiBpbml0 aWFsaXplZCAoZGV2IGF1dG9mcywgdHlwZSBhdXRvZnMpLCB1c2VzIGdlbmZzX2NvbnRleHRzClN0 YXJ0aW5nIFN5c2xvZyBLZXJuZWwgTG9nIEJ1ZmZlciBCcmlkZ2UuLi4KU3RhcnRlZCBTeXNsb2cg S2VybmVsIExvZyBCdWZmZXIgQnJpZGdlLgpbICAgNDkuNTg2MTc1XSBTRUxpbnV4OiBpbml0aWFs aXplZCAoZGV2IGF1dG9mcywgdHlwZSBhdXRvZnMpLCB1c2VzIGdlbmZzX2NvbnRleHRzClsgICA0 OS42NzYwNzJdIFNFTGludXg6IGluaXRpYWxpemVkIChkZXYgYXV0b2ZzLCB0eXBlIGF1dG9mcyks IHVzZXMgZ2VuZnNfY29udGV4dHMKWyAgIDQ5LjY4NjM2OF0gU0VMaW51eDogaW5pdGlhbGl6ZWQg KGRldiBhdXRvZnMsIHR5cGUgYXV0b2ZzKSwgdXNlcyBnZW5mc19jb250ZXh0cwpTdGFydGVkIExv YWQgS2VybmVsIE1vZHVsZXMuClN0YXJ0aW5nIEFwcGx5IEtlcm5lbCBWYXJpYWJsZXMuLi4KWyAg IDQ5Ljg4MjYzN10gU0VMaW51eDogaW5pdGlhbGl6ZWQgKGRldiBhdXRvZnMsIHR5cGUgYXV0b2Zz KSwgdXNlcyBnZW5mc19jb250ZXh0cwpTdGFydGluZyB1ZGV2IEtlcm5lbCBEZXZpY2UgTWFuYWdl ci4uLgpTdGFydGluZyBSZW1vdW50IEFQSSBWRlMuLi4KU3RhcnRpbmcgTWVkaWEgRGlyZWN0b3J5 Li4uClN0YXJ0aW5nIFJ1bnRpbWUgRGlyZWN0b3J5Li4uClN0YXJ0ZWQgRmlsZSBTeXN0ZW0gQ2hl Y2sgb24gUm9vdCBEZXZpY2UuClN0YXJ0aW5nIFJlbW91bnQgUm9vdCBGUy4uLgpTdGFydGluZyBM b2NrIERpcmVjdG9yeS4uLgpTdGFydGluZyBTZXR1cCBWaXJ0dWFsIENvbnNvbGUuLi4KU3RhcnRl ZCBCb290dXAgaGFjay4KWyAgIDUwLjk2MzAyOF0gU0VMaW51eDogaW5pdGlhbGl6ZWQgKGRldiB0 bXBmcywgdHlwZSB0bXBmcyksIHVzZXMgdHJhbnNpdGlvbiBTSURzClN0YXJ0ZWQgQXBwbHkgS2Vy bmVsIFZhcmlhYmxlcy4KU3RhcnRlZCBSdW50aW1lIERpcmVjdG9yeS4KU3RhcnRlZCBNZWRpYSBE aXJlY3RvcnkuClN0YXJ0aW5nIEFyYml0cmFyeSBFeGVjdXRhYmxlIEZpbGUgRm9ybWF0cyBGaWxl IFN5c3RlbS4uLgpTdGFydGluZyBTdGRpbyBTeXNsb2cgQnJpZGdlLi4uClsgICA1MS4yMDk3MTld IEVYVDQtZnMgKGRtLTApOiByZS1tb3VudGVkLiBPcHRzOiAobnVsbCkKU3RhcnRlZCBTdGRpbyBT eXNsb2cgQnJpZGdlLgpTdGFydGVkIFJlbW91bnQgUm9vdCBGUy4KU3RhcnRlZCBMb2NrIERpcmVj dG9yeS4KU3RhcnRpbmcgQ29uZmlndXJlIHJlYWQtb25seSByb290IHN1cHBvcnQuLi4KU3RhcnRl ZCBSZW1vdW50IEFQSSBWRlMuClsgICA1Mi4zMjAwMDddIGNhbGxpbmcgIGluaXRfbWlzY19iaW5m bXQrMHgwLzB4MTAwMCBbYmluZm10X21pc2NdIEAgMzk0ClsgICA1Mi4zMjAyNDNdIGluaXRjYWxs IGluaXRfbWlzY19iaW5mbXQrMHgwLzB4MTAwMCBbYmluZm10X21pc2NdIHJldHVybmVkIDAgYWZ0 ZXIgMTAyIHVzZWNzClsgICA1Mi4zMjUwODVdIFNFTGludXg6IGluaXRpYWxpemVkIChkZXYgYmlu Zm10X21pc2MsIHR5cGUgYmluZm10X21pc2MpLCB1c2VzIGdlbmZzX2NvbnRleHRzClN0YXJ0ZWQg QXJiaXRyYXJ5IEV4ZWN1dGFibGUgRmlsZSBGb3JtYXRzIEZpbGUgU3lzdGVtLgpTdGFydGVkIFNl dCBVcCBBZGRpdGlvbmFsIEJpbmFyeSBGb3JtYXRzLgpTdGFydGVkIENvbmZpZ3VyZSByZWFkLW9u bHkgcm9vdCBzdXBwb3J0LgpbICAgNTMuNDE3NjI5XSBjYWxsaW5nICB4ZW5mc19pbml0KzB4MC8w eDEwMDAgW3hlbmZzXSBAIDQxMApbICAgNTMuNDE3NzE4XSBpbml0Y2FsbCB4ZW5mc19pbml0KzB4 MC8weDEwMDAgW3hlbmZzXSByZXR1cm5lZCAwIGFmdGVyIDEwIHVzZWNzClsgICA1My40MjAwNTdd IFNFTGludXg6IGluaXRpYWxpemVkIChkZXYgeGVuZnMsIHR5cGUgeGVuZnMpLCB1c2VzIGdlbmZz X2NvbnRleHRzClN0YXJ0ZWQgU2V0dXAgVmlydHVhbCBDb25zb2xlLgpbICAgNTMuNzAzMzc3XSBj YWxsaW5nICBldnRjaG5faW5pdCsweDAvMHgxMDAwIFt4ZW5fZXZ0Y2huXSBAIDQxNApbICAgNTMu NzA4ODc2XSBFdmVudC1jaGFubmVsIGRldmljZSBpbnN0YWxsZWQuClsgICA1My43MDg5MDZdIGlu aXRjYWxsIGV2dGNobl9pbml0KzB4MC8weDEwMDAgW3hlbl9ldnRjaG5dIHJldHVybmVkIDAgYWZ0 ZXIgNTMxNyB1c2VjcwpbICAgNTMuODQ1OTQ1XSBjYWxsaW5nICBnbnRkZXZfaW5pdCsweDAvMHgx MDAwIFt4ZW5fZ250ZGV2XSBAIDQxNgpbICAgNTMuODQ3MzA5XSBpbml0Y2FsbCBnbnRkZXZfaW5p dCsweDAvMHgxMDAwIFt4ZW5fZ250ZGV2XSByZXR1cm5lZCAwIGFmdGVyIDEyNTEgdXNlY3MKWyAg IDU0LjAzMDQ1NF0gY2FsbGluZyAgeGVuX2Jsa2lmX2luaXQrMHgwLzB4MjhlIFt4ZW5fYmxrYmFj a10gQCA0MTgKWyAgIDU0LjAzMzgwN10gaW5pdGNhbGwgeGVuX2Jsa2lmX2luaXQrMHgwLzB4Mjhl IFt4ZW5fYmxrYmFja10gcmV0dXJuZWQgMCBhZnRlciAzMTk1IHVzZWNzClsgICA1NC4yMDc1Mzdd IGNhbGxpbmcgIG5ldGJhY2tfaW5pdCsweDAvMHgxMDAwIFt4ZW5fbmV0YmFja10gQCA0MTkKWyAg IDU0LjIxMTg1NF0gaW5pdGNhbGwgbmV0YmFja19pbml0KzB4MC8weDEwMDAgW3hlbl9uZXRiYWNr XSByZXR1cm5lZCAwIGFmdGVyIDQwNzYgdXNlY3MKWyAgIDU0LjIzMTk2Ml0gdWRldlszNjddOiBz dGFydGluZyB2ZXJzaW9uIDE2NwpTdGFydGVkIHVkZXYgS2VybmVsIERldmljZSBNYW5hZ2VyLgpT dGFydGluZyB1ZGV2IENvbGRwbHVnIGFsbCBEZXZpY2VzLi4uClsgICA1NC43NjAzNDBdIGNhbGxp bmcgIGdudGFsbG9jX2luaXQrMHgwLzB4MTAwMCBbeGVuX2dudGFsbG9jXSBAIDQ0MAogMjA4MiB1 c2VjcwpbICAgNTQuODMyODE3XSBjYWxsaW5nICB0dW5faW5pdCsweDAvMHgxMDAwIFt0dW5dIEAg NDQzClsgICA1NC44MzI4OTFdIHR1bjogVW5pdmVyc2FsIFRVTi9UQVAgZGV2aWNlIGRyaXZlciwg MS42ClsgICA1NC44MzI5MTJdIHR1bjogKEMpIDE5OTktMjAwNCBNYXggS3Jhc255YW5za3kgPG1h eGtAcXVhbGNvbW0uY29tPgpbICAgNTQuODMzOTY0XSBpbml0Y2FsbCB0dW5faW5pdCsweDAvMHgx MDAwIFt0dW5dIHJldHVybmVkIDAgYWZ0ZXIgMTA0NCB1c2VjcwpbICAgNTQuOTY2ODQ0XSBzeXN0 ZW1kWzFdOiBmZWRvcmEtbG9hZG1vZHVsZXMuc2VydmljZTogbWFpbiBwcm9jZXNzIGV4aXRlZCwg Y29kZT1leGl0ZWQsIHN0YXR1cz0xClsgICA1NS4wMTEzNzddIHN5c3RlbWRbMV06IFVuaXQgZmVk b3JhLWxvYWRtb2R1bGVzLnNlcnZpY2UgZW50ZXJlZCBmYWlsZWQgc3RhdGUuClN0YXJ0aW5nIExv YWQgbGVnYWN5IG1vZHVsZSBjb25maWd1cmF0aW9uIGZhaWxlZCwgc2VlICdzeXN0ZW1jdGwgc3Rh dHVzIGZlZG9yYS1sb2FkbW9kdWxlcy5zZXJ2aWNlJyBmb3IgZGV0YWlscy4KU3RhcnRlZCB1ZGV2 IENvbGRwbHVnIGFsbCBEZXZpY2VzLgpTdGFydGluZyB1ZGV2IFdhaXQgZm9yIENvbXBsZXRlIERl dmljZSBJbml0aWFsaXphdGlvbi4uLgpbICAgNTYuMTU1Njk5XSBjYWxsaW5nICBzbmRfbWVtX2lu aXQrMHgwLzB4MTAwMCBbc25kX3BhZ2VfYWxsb2NdIEAgNDU5ClsgICA1Ni4xODU5ODZdIGluaXRj YWxsIHNuZF9tZW1faW5pdCsweDAvMHgxMDAwIFtzbmRfcGFnZV9hbGxvY10gcmV0dXJuZWQgMCBh ZnRlciAyOTQzNCB1c2VjcwpTdGFydGVkIHVkZXYgS2VybmVsIERldmljZSBNYW5hZ2VyLgpbICAg NTYuMzA3MDMwXSBjYWxsaW5nICBpbml0X3NvdW5kY29yZSsweDAvMHgxMDAwIFtzb3VuZGNvcmVd IEAgNDU5ClsgICA1Ni4zMDgxMjNdIGluaXRjYWxsIGluaXRfc291bmRjb3JlKzB4MC8weDEwMDAg W3NvdW5kY29yZV0gcmV0dXJuZWQgMCBhZnRlciA5ODYgdXNlY3MKWyAgIDU2LjMxMjgxM10gY2Fs bGluZyAgcmZraWxsX2luaXQrMHgwLzB4OTQgW3Jma2lsbF0gQCA0NjIKWyAgIDU2LjMzMzA2NV0g aW5pdGNhbGwgcmZraWxsX2luaXQrMHgwLzB4OTQgW3Jma2lsbF0gcmV0dXJuZWQgMCBhZnRlciAx OTkwNSB1c2VjcwpbICAgNTYuMzkxNTYxXSBjYWxsaW5nICBhbHNhX3NvdW5kX2luaXQrMHgwLzB4 OTYgW3NuZF0gQCA0NTkKWyAgIDU2LjQyMDU2N10gaW5pdGNhbGwgYWxzYV9zb3VuZF9pbml0KzB4 MC8weDk2IFtzbmRdIHJldHVybmVkIDAgYWZ0ZXIgMjgyMzkgdXNlY3MKWyAgIDU2LjUzOTQzOV0g Y2FsbGluZyAgY2ZnODAyMTFfaW5pdCsweDAvMHhjOCBbY2ZnODAyMTFdIEAgNDYyClsgICA1Ni41 NzEwNzBdIGNmZzgwMjExOiBDYWxsaW5nIENSREEgdG8gdXBkYXRlIHdvcmxkIHJlZ3VsYXRvcnkg ZG9tYWluClsgICA1Ni41NzgxNzBdIGluaXRjYWxsIGNmZzgwMjExX2luaXQrMHgwLzB4YzggW2Nm ZzgwMjExXSByZXR1cm5lZCAwIGFmdGVyIDM3NzI3IHVzZWNzClsgICA1Ni41OTEyMTNdIGNhbGxp bmcgIGFsc2FfdGltZXJfaW5pdCsweDAvMHgxMDAwIFtzbmRfdGltZXJdIEAgNDU5ClsgICA1Ni41 OTUwNjRdIGluaXRjYWxsIGFsc2FfdGltZXJfaW5pdCsweDAvMHgxMDAwIFtzbmRfdGltZXJdIHJl dHVybmVkIDAgYWZ0ZXIgNDE0NCB1c2VjcwpbICAgNTYuODQ4ODI1XSBjYWxsaW5nICBpZWVlODAy MTFfaW5pdCsweDAvMHgzYiBbbWFjODAyMTFdIEAgNDYyClsgICA1Ni44NDkwNjVdIGluaXRjYWxs IGllZWU4MDIxMV9pbml0KzB4MC8weDNiIFttYWM4MDIxMV0gcmV0dXJuZWQgMCBhZnRlciA5NjIg dXNlY3MKWyAgIDU3LjkxNjIyMV0gY2FsbGluZyAgbW9kX2luaXQrMHgwLzB4ZjI2IFtpbnRlbF9y bmddIEAgNTE4ClsgICA1OC4wMTcwNzZdIGludGVsX3JuZzogRldIIG5vdCBkZXRlY3RlZApbICAg NTguMDI0ODc0XSBjYWxsaW5nICBpd2wzOTQ1X2luaXQrMHgwLzB4MTAwMCBbaXdsMzk0NV0gQCA0 NjIKWyAgIDU4LjAyNTAwMl0gaXdsMzk0NTogSW50ZWwoUikgUFJPL1dpcmVsZXNzIDM5NDVBQkcv QkcgTmV0d29yayBDb25uZWN0aW9uIGRyaXZlciBmb3IgTGludXgsIGluLXRyZWU6ZHMKWyAgIDU4 LjAyNTA3Nl0gaXdsMzk0NTogQ29weXJpZ2h0KGMpIDIwMDMtMjAxMSBJbnRlbCBDb3Jwb3JhdGlv bgpbICAgNTguMDI5MTcyXSBpbml0Y2FsbCBtb2RfaW5pdCsweDAvMHhmMjYgW2ludGVsX3JuZ10g cmV0dXJuZWQgLTE5IGFmdGVyIDExMDIyNCB1c2VjcwpbICAgNTguMDU4Nzg1XSB4ZW46IHJlZ2lz dGVyaW5nIGdzaSAxNiB0cmlnZ2VyaW5nIDAgcG9sYXJpdHkgMQpbICAgNTguMDU4OTI3XSB4ZW5f bWFwX3BpcnFfZ3NpOiByZXR1cm5pbmcgaXJxIDE2IGZvciBnc2kgMTYKWyAgIDU4LjA1ODk3Nl0g eGVuOiAtLT4gcGlycT0xNiAtPiBpcnE9MTYgKGdzaT0xNikKWyAgIDU4LjA1OTAyM10gQWxyZWFk eSBzZXR1cCB0aGUgR1NJIDoxNgpbICAgNTguMDU5MTU5XSBpd2wzOTQ1IDAwMDA6MGI6MDAuMDog UENJIElOVCBBIC0+IEdTSSAxNiAobGV2ZWwsIGxvdykgLT4gSVJRIDE2ClsgICA1OC4wNTkyNzFd IGl3bDM5NDUgMDAwMDowYjowMC4wOiBzZXR0aW5nIGxhdGVuY3kgdGltZXIgdG8gNjQKWyAgIDU4 LjE3MzYzNl0gY2FsbGluZyAgaVRDT192ZW5kb3JfaW5pdF9tb2R1bGUrMHgwLzB4MTAwMCBbaVRD T192ZW5kb3Jfc3VwcG9ydF0gQCA1MTgKWyAgIDU4LjE3MzY5OV0gaVRDT192ZW5kb3Jfc3VwcG9y dDogdmVuZG9yLXN1cHBvcnQ9MApbICAgNTguMTczNzI0XSBpbml0Y2FsbCBpVENPX3ZlbmRvcl9p bml0X21vZHVsZSsweDAvMHgxMDAwIFtpVENPX3ZlbmRvcl9zdXBwb3J0XSByZXR1cm5lZCAwIGFm dGVyIDIxIHVzZWNzClsgICA1OC4yMjI1ODRdIGl3bDM5NDUgMDAwMDowYjowMC4wOiBUdW5hYmxl IGNoYW5uZWxzOiAxMSA4MDIuMTFiZywgMTMgODAyLjExYSBjaGFubmVscwpbICAgNTguMjIyNzI2 XSBpd2wzOTQ1IDAwMDA6MGI6MDAuMDogRGV0ZWN0ZWQgSW50ZWwgV2lyZWxlc3MgV2lGaSBMaW5r IDM5NDVBQkcKWyAgIDU4LjIyMzkxNV0gQlVHOiBzbGVlcGluZyBmdW5jdGlvbiBjYWxsZWQgZnJv bSBpbnZhbGlkIGNvbnRleHQgYXQga2VybmVsL211dGV4LmM6MjcxClsgICA1OC4yMjQwODNdIDMg bG9ja3MgaGVsZCBieSBtb2Rwcm9iZS80NjI6ClsgICA1OC4yMjQxMTVdICAjMDogICgmX19sb2Nr ZGVwX25vX3ZhbGlkYXRlX18pey4uLi4uLn0sIGF0OiBbPGZmZmZmZmZmODEzMTc2ZDA+XSBfX2Ry aXZlcl9hdHRhY2grMHgzYi8weDgyClsgICA1OC4yMjQzOTJdICAjMTogICgmX19sb2NrZGVwX25v X3ZhbGlkYXRlX18pey4uLi4uLn0sIGF0OiBbPGZmZmZmZmZmODEzMTc2ZGU+XSBfX2RyaXZlcl9h dHRhY2grMHg0OS8weDgyClsgICA1OC4yMjQ1MDZdICAjMjogIChpcnFfbWFwcGluZ191cGRhdGVf bG9jayl7Ky4rLisufSwgYXQ6IFs8ZmZmZmZmZmY4MTJkYTZlNj5dIHhlbl9iaW5kX3BpcnFfbXNp X3RvX2lycSsweDMxLzB4ZGEKWyAgIDU4LjIyNDYzNF0gUGlkOiA0NjIsIGNvbW06IG1vZHByb2Jl IE5vdCB0YWludGVkIDMuMS4wLTAucmM2LmdpdDAuMC5mYzE3Lng4Nl82NCAjMQpbICAgNTguMjI0 NjkzXSBDYWxsIFRyYWNlOgpbICAgNTguMjI0NzM1XSAgWzxmZmZmZmZmZjgxMDRmNmQ1Pl0gX19t aWdodF9zbGVlcCsweDEwMy8weDEwOApbICAgNTguMjI0Nzg5XSAgWzxmZmZmZmZmZjgxNTAzNWYy Pl0gbXV0ZXhfbG9ja19uZXN0ZWQrMHgyNS8weDQ1ClsgICA1OC4yMjQ4NDhdICBbPGZmZmZmZmZm ODE0ZTEzY2Q+XSBfX2lycV9hbGxvY19kZXNjcysweDUwLzB4MThiClsgICA1OC4yMjQ5MTRdICBb PGZmZmZmZmZmODEyZDAyZTY+XSA/IGdoZXNfcHJvY19pbl9pcnErMHg1Yi8weGE1ClsgICA1OC4y MjQ5NzddICBbPGZmZmZmZmZmODEyZDljMGU+XSB4ZW5fYWxsb2NhdGVfaXJxX2R5bmFtaWMrMHg0 OS8weDU4ClsgICA1OC4yMjUwMzhdICBbPGZmZmZmZmZmODEyZGE2ZWI+XSB4ZW5fYmluZF9waXJx X21zaV90b19pcnErMHgzNi8weGRhClsgICA1OC4yMjUxODVdICBbPGZmZmZmZmZmODE0MDAxZTM+ XSB4ZW5faW5pdGRvbV9zZXR1cF9tc2lfaXJxcysweDEyOS8weDE1ZApbICAgNTguMjI1MjU4XSAg WzxmZmZmZmZmZjgxMjdkMjE4Pl0gcGNpX2VuYWJsZV9tc2lfYmxvY2srMHgxYzAvMHgyMjUKWyAg IDU4LjIyNTMzOV0gIFs8ZmZmZmZmZmZhMDIzZDUxOT5dIGl3bDM5NDVfcGNpX3Byb2JlKzB4NmI3 LzB4YzUxIFtpd2wzOTQ1XQpbICAgNTguMjI1NDQ4XSAgWzxmZmZmZmZmZjgxMjZkMDQzPl0gbG9j YWxfcGNpX3Byb2JlKzB4NDQvMHg3NQpbICAgNTguMjI1NDk3XSAgWzxmZmZmZmZmZjgxMjZkYmM5 Pl0gcGNpX2RldmljZV9wcm9iZSsweGQwLzB4ZmYKWyAgIDU4LjIyNTU2NF0gIFs8ZmZmZmZmZmY4 MTMxNzViMz5dIGRyaXZlcl9wcm9iZV9kZXZpY2UrMHgxMzEvMHgyMTMKWyAgIDU4LjIyNTYyN10g IFs8ZmZmZmZmZmY4MTMxNzZmMz5dIF9fZHJpdmVyX2F0dGFjaCsweDVlLzB4ODIKWyAgIDU4LjIy NTY4MV0gIFs8ZmZmZmZmZmY4MTMxNzY5NT5dID8gZHJpdmVyX3Byb2JlX2RldmljZSsweDIxMy8w eDIxMwpbICAgNTguMjI1NzQzXSAgWzxmZmZmZmZmZjgxMzE2NWY0Pl0gYnVzX2Zvcl9lYWNoX2Rl disweDU5LzB4OGYKWyAgIDU4LjIyNTgwM10gIFs8ZmZmZmZmZmY4MTMxNzE4Nz5dIGRyaXZlcl9h dHRhY2grMHgxZS8weDIwClsgICA1OC4yMjU4NTVdICBbPGZmZmZmZmZmODEzMTZkOWY+XSBidXNf YWRkX2RyaXZlcisweGQ0LzB4MjJhClsgICA1OC4yMjU5MThdICBbPGZmZmZmZmZmYTAyMDQwMDA+ XSA/IDB4ZmZmZmZmZmZhMDIwM2ZmZgpbICAgNTguMjI1OTcwXSAgWzxmZmZmZmZmZjgxMzE3YmI2 Pl0gZHJpdmVyX3JlZ2lzdGVyKzB4OTgvMHgxMDUKWyAgIDU4LjIyNjAzM10gIFs8ZmZmZmZmZmZh MDIwNDAwMD5dID8gMHhmZmZmZmZmZmEwMjAzZmZmClsgICA1OC4yMjYxNzJdICBbPGZmZmZmZmZm ODEyNmU0OWM+XSBfX3BjaV9yZWdpc3Rlcl9kcml2ZXIrMHg2Ni8weGQyClsgICA1OC4yMjYyMzNd ICBbPGZmZmZmZmZmYTAyMDQwMDA+XSA/IDB4ZmZmZmZmZmZhMDIwM2ZmZgpbICAgNTguMjI2MzAy XSAgWzxmZmZmZmZmZmEwMjA0MDU5Pl0gaXdsMzk0NV9pbml0KzB4NTkvMHgxMDAwIFtpd2wzOTQ1 XQpbICAgNTguMjI2MzcyXSAgWzxmZmZmZmZmZjgxMDAyMDcxPl0gZG9fb25lX2luaXRjYWxsKzB4 NTcvMHgxM2EKClsgICA1OC4yMjY0MzZdICBbPGZmZmZmZmZmYTAyMDQwMDA+XSA/IDB4ZmZmZmZm ZmZhMDIwM2ZmZgpbICAgNTguMjI2NDkxXSAgWzxmZmZmZmZmZjgxMDlhNjcwPl0gc3lzX2luaXRf bW9kdWxlKzB4MTE0LzB4MjY3ClsgICA1OC4yMjY1NTZdICBbPGZmZmZmZmZmODE1MGJjODI+XSBz eXN0ZW1fY2FsbF9mYXN0cGF0aCsweDE2LzB4MWIKWyAgIDU4LjIyNjYxMV0gQlVHOiBzY2hlZHVs aW5nIHdoaWxlIGF0b21pYzogbW9kcHJvYmUvNDYyLzB4MTAwMDAwMDIKWyAgIDU4LjIyNjY2OV0g MyBsb2NrcyBoZWxkIGJ5IG1vZHByb2JlLzQ2MjoKWyAgIDU4LjIyNjcwNV0gICMwOiAgKCZfX2xv Y2tkZXBfbm9fdmFsaWRhdGVfXyl7Li4uLi4ufSwgYXQ6IFs8ZmZmZmZmZmY4MTMxNzZkMD5dIF9f ZHJpdmVyX2F0dGFjaCsweDNiLzB4ODIKWyAgIDU4LjIyNjg1NV0gICMxOiAgKCZfX2xvY2tkZXBf bm9fdmFsaWRhdGVfXyl7Li4uLi4ufSwgYXQ6IFs8ZmZmZmZmZmY4MTMxNzZkZT5dIF9fZHJpdmVy X2F0dGFjaCsweDQ5LzB4ODIKWyAgIDU4LjIyNjk2NV0gICMyOiAgKGlycV9tYXBwaW5nX3VwZGF0 ZV9sb2NrKXsrLisuKy59LCBhdDogWzxmZmZmZmZmZjgxMmRhNmU2Pl0geGVuX2JpbmRfcGlycV9t c2lfdG9faXJxKzB4MzEvMHhkYQpbICAgNTguMjI3MDg5XSBNb2R1bGVzIGxpbmtlZCBpbjogaTJj X2k4MDEoKykgaVRDT192ZW5kb3Jfc3VwcG9ydCBpd2wzOTQ1KCspIGl3bF9sZWdhY3kgbWFjODAy MTEgc25kX3RpbWVyIGNmZzgwMjExIHNuZCByZmtpbGwgc291bmRjb3JlIHNuZF9wYWdlX2FsbG9j IHR1biB4ZW5fZ250YWxsb2MgeGVuX25ldGJhY2sgeGVuX2Jsa2JhY2sgeGVuX2dudGRldiB4ZW5f ZXZ0Y2huIHhlbmZzIGJpbmZtdF9taXNjIHNkaGNpX3BjaSBzZGhjaSBtbWNfY29yZSBmaXJld2ly ZV9vaGNpIGZpcmV3aXJlX2NvcmUgY3JjX2l0dV90IHdtaSBpOTE1IGRybV9rbXNfaGVscGVyIGRy bSBpMmNfYWxnb19iaXQgaTJjX2NvcmUgdmlkZW8KWyAgIDU4LjIyNzEyNl0gUGlkOiA0NjIsIGNv bW06IG1vZHByb2JlIE5vdCB0YWludGVkIDMuMS4wLTAucmM2LmdpdDAuMC5mYzE3Lng4Nl82NCAj MQpbICAgNTguMjI3MTI2XSBDYWxsIFRyYWNlOgpbICAgNTguMjI3MTI2XSAgWzxmZmZmZmZmZjgx NGY5ZTQ0Pl0gX19zY2hlZHVsZV9idWcrMHg3NS8weDdhClsgICA1OC4yMjcxMjZdICBbPGZmZmZm ZmZmODE1MDIxMGQ+XSBfX3NjaGVkdWxlKzB4OTUvMHg3NjEKWyAgIDU4LjIyNzEyNl0gIFs8ZmZm ZmZmZmY4MTAxMWUxNz5dID8gc2hvd190cmFjZV9sb2dfbHZsKzB4NTQvMHg1ZApbICAgNTguMjI3 MTI2XSAgWzxmZmZmZmZmZjgxMDExZTM1Pl0gPyBzaG93X3RyYWNlKzB4MTUvMHgxNwpbICAgNTgu MjI3MTI2XSAgWzxmZmZmZmZmZjgxMDU2YzI4Pl0gX19jb25kX3Jlc2NoZWQrMHgyOC8weDM0Clsg ICA1OC4yMjcxMjZdICBbPGZmZmZmZmZmODE1MDI4MzU+XSBfY29uZF9yZXNjaGVkKzB4MTkvMHgy MgpbICAgNTguMjI3MTI2XSAgWzxmZmZmZmZmZjgxNGUxM2NkPl0gX19pcnFfYWxsb2NfZGVzY3Mr MHg1MC8weDE4YgpbICAgNTguMjI3MTI2XSAgWzxmZmZmZmZmZjgxMmQwMmU2Pl0gPyBnaGVzX3By b2NfaW5faXJxKzB4NWIvMHhhNQpbICAgNTguMjI3MTI2XSAgWzxmZmZmZmZmZjgxMmQ5YzBlPl0g eGVuX2FsbG9jYXRlX2lycV9keW5hbWljKzB4NDkvMHg1OApbICAgNTguMjI3MTI2XSAgWzxmZmZm ZmZmZjgxMmRhNmViPl0geGVuX2JpbmRfcGlycV9tc2lfdG9faXJxKzB4MzYvMHhkYQpbICAgNTgu MjI3MTI2XSAgWzxmZmZmZmZmZjgxNDAwMWUzPl0geGVuX2luaXRkb21fc2V0dXBfbXNpX2lycXMr MHgxMjkvMHgxNWQKWyAgIDU4LjIyOTI0MV0gIFs8ZmZmZmZmZmY4MTI3ZDIxOD5dIHBjaV9lbmFi bGVfbXNpX2Jsb2NrKzB4MWMwLzB4MjI1ClsgICA1OC4yMjkzMjRdICBbPGZmZmZmZmZmYTAyM2Q1 MTk+XSBpd2wzOTQ1X3BjaV9wcm9iZSsweDZiNy8weGM1MSBbaXdsMzk0NV0KWyAgIDU4LjIyOTM4 OF0gIFs8ZmZmZmZmZmY4MTI2ZDA0Mz5dIGxvY2FsX3BjaV9wcm9iZSsweDQ0LzB4NzUKWyAgIDU4 LjIyOTQ0MF0gIFs8ZmZmZmZmZmY4MTI2ZGJjOT5dIHBjaV9kZXZpY2VfcHJvYmUrMHhkMC8weGZm ClsgICA1OC4yMjk1MDNdICBbPGZmZmZmZmZmODEzMTc1YjM+XSBkcml2ZXJfcHJvYmVfZGV2aWNl KzB4MTMxLzB4MjEzClsgICA1OC4yMjk1NjZdICBbPGZmZmZmZmZmODEzMTc2ZjM+XSBfX2RyaXZl cl9hdHRhY2grMHg1ZS8weDgyClsgICA1OC4yMjk2NTldICBbPGZmZmZmZmZmODEzMTc2OTU+XSA/ IGRyaXZlcl9wcm9iZV9kZXZpY2UrMHgyMTMvMHgyMTMKWyAgIDU4LjIyOTcyMV0gIFs8ZmZmZmZm ZmY4MTMxNjVmND5dIGJ1c19mb3JfZWFjaF9kZXYrMHg1OS8weDhmClsgICA1OC4yMjk3ODNdICBb PGZmZmZmZmZmODEzMTcxODc+XSBkcml2ZXJfYXR0YWNoKzB4MWUvMHgyMApbICAgNTguMjI5ODMz XSAgWzxmZmZmZmZmZjgxMzE2ZDlmPl0gYnVzX2FkZF9kcml2ZXIrMHhkNC8weDIyYQpbICAgNTgu MjI5ODkwXSAgWzxmZmZmZmZmZmEwMjA0MDAwPl0gPyAweGZmZmZmZmZmYTAyMDNmZmYKWyAgIDU4 LjIyOTk0Ml0gIFs8ZmZmZmZmZmY4MTMxN2JiNj5dIGRyaXZlcl9yZWdpc3RlcisweDk4LzB4MTA1 ClsgICA1OC4yMzAwMDVdICBbPGZmZmZmZmZmYTAyMDQwMDA+XSA/IDB4ZmZmZmZmZmZhMDIwM2Zm ZgpbICAgNTguMjMwMDYyXSAgWzxmZmZmZmZmZjgxMjZlNDljPl0gX19wY2lfcmVnaXN0ZXJfZHJp dmVyKzB4NjYvMHhkMgpbICAgNTguMjMwMTkyXSAgWzxmZmZmZmZmZmEwMjA0MDAwPl0gPyAweGZm ZmZmZmZmYTAyMDNmZmYKWyAgIDU4LjIzMDI1Nl0gIFs8ZmZmZmZmZmZhMDIwNDA1OT5dIGl3bDM5 NDVfaW5pdCsweDU5LzB4MTAwMCBbaXdsMzk0NV0KWyAgIDU4LjIzMDMyNl0gIFs8ZmZmZmZmZmY4 MTAwMjA3MT5dIGRvX29uZV9pbml0Y2FsbCsweDU3LzB4MTNhClsgICA1OC4yMzAzODldICBbPGZm ZmZmZmZmYTAyMDQwMDA+XSA/IDB4ZmZmZmZmZmZhMDIwM2ZmZgpbICAgNTguMjMwNDQxXSAgWzxm ZmZmZmZmZjgxMDlhNjcwPl0gc3lzX2luaXRfbW9kdWxlKzB4MTE0LzB4MjY3ClsgICA1OC4yMzA1 MDBdICBbPGZmZmZmZmZmODE1MGJjODI+XSBzeXN0ZW1fY2FsbF9mYXN0cGF0aCsweDE2LzB4MWIK WyAgIDU4LjIzNzc1NF0gY2FsbGluZyAgaTJjX2k4MDFfaW5pdCsweDAvMHgxMDAwIFtpMmNfaTgw MV0gQCA1MjAKWyAgIDU4LjIzODExNl0geGVuOiByZWdpc3RlcmluZyBnc2kgMTcgdHJpZ2dlcmlu ZyAwIHBvbGFyaXR5IDEKWyAgIDU4LjI0NDgyNl0geGVuX21hcF9waXJxX2dzaTogcmV0dXJuaW5n IGlycSAxNyBmb3IgZ3NpIDE3ClsgICA1OC4yNDQ4NTRdIHhlbjogLS0+IHBpcnE9MTcgLT4gaXJx PTE3IChnc2k9MTcpClsgICA1OC4yNDQ4NzZdIEFscmVhZHkgc2V0dXAgdGhlIEdTSSA6MTcKWyAg IDU4LjI0NDg5Nl0gaTgwMV9zbWJ1cyAwMDAwOjAwOjFmLjM6IFBDSSBJTlQgQiAtPiBHU0kgMTcg KGxldmVsLCBsb3cpIC0+IElSUSAxNwpbICAgNTguMjc0MDgzXSBpbml0Y2FsbCBpMmNfaTgwMV9p bml0KzB4MC8weDEwMDAgW2kyY19pODAxXSByZXR1cm5lZCAwIGFmdGVyIDM2MDYwIHVzZWNzClsg ICA1OC4zMjQ0MTddIFJlZ2lzdGVyZWQgbGVkIGRldmljZTogcGh5MC1sZWQKWyAgIDU4LjM3NjY3 MF0gY2FsbGluZyAgbWVtc3RpY2tfaW5pdCsweDAvMHgxMDAwIFttZW1zdGlja10gQCA1MjkKWyAg IDU4LjM4MTA4Ml0gaW5pdGNhbGwgbWVtc3RpY2tfaW5pdCsweDAvMHgxMDAwIFttZW1zdGlja10g cmV0dXJuZWQgMCBhZnRlciA0MzY1IHVzZWNzClsgICA1OC40MzMyNDRdIGNhbGxpbmcgIHI1OTJf bW9kdWxlX2luaXQrMHgwLzB4MTAwMCBbcjU5Ml0gQCA1MjkKWyAgIDU4LjQzNzU4NF0gY2FsbGlu ZyAgaW5pdF9tdGQrMHgwLzB4ZmMwIFttdGRdIEAgNTI4ClsgICA1OC40Mzg4ODhdIHhlbjogcmVn aXN0ZXJpbmcgZ3NpIDE4IHRyaWdnZXJpbmcgMCBwb2xhcml0eSAxClsgICA1OC40Mzg5MjVdIHhl bl9tYXBfcGlycV9nc2k6IHJldHVybmluZyBpcnEgMTggZm9yIGdzaSAxOApbICAgNTguNDM4OTQ5 XSB4ZW46IC0tPiBwaXJxPTE4IC0+IGlycT0xOCAoZ3NpPTE4KQpbICAgNTguNDM4OTcxXSBBbHJl YWR5IHNldHVwIHRoZSBHU0kgOjE4ClsgICA1OC40Mzg5OTBdIHI1OTIgMDAwMDowMzowMS4yOiBQ Q0kgSU5UIEIgLT4gR1NJIDE4IChsZXZlbCwgbG93KSAtPiBJUlEgMTgKWyAgIDU4LjQzOTA0NF0g cjU5MiAwMDAwOjAzOjAxLjI6IHNldHRpbmcgbGF0ZW5jeSB0aW1lciB0byA2NApbICAgNTguNDQz ODM2XSByNTkyOiBkcml2ZXIgc3VjY2Vzc2Z1bGx5IGxvYWRlZApbICAgNTguNDQ0ODc3XSBpbml0 Y2FsbCByNTkyX21vZHVsZV9pbml0KzB4MC8weDEwMDAgW3I1OTJdIHJldHVybmVkIDAgYWZ0ZXIg MTEzMTQgdXNlY3MKWyAgIDU4LjQ3NjMzMl0gY2FsbGluZyAgam95ZGV2X2luaXQrMHgwLzB4MTAw MCBbam95ZGV2XSBAIDUzMQpbICAgNTguNDc2MzgxXSBpbml0Y2FsbCBqb3lkZXZfaW5pdCsweDAv MHgxMDAwIFtqb3lkZXZdIHJldHVybmVkIDAgYWZ0ZXIgMTEgdXNlY3MKWyAgIDU4LjQ5NjQzNF0g Y2FsbGluZyAgaVRDT193ZHRfaW5pdF9tb2R1bGUrMHgwLzB4MTAwMCBbaVRDT193ZHRdIEAgNTE4 ClsgICA1OC40OTY0NzNdIGlUQ09fd2R0OiBJbnRlbCBUQ08gV2F0Y2hEb2cgVGltZXIgRHJpdmVy IHYxLjA2ClsgICA1OC40OTg0MThdIGlUQ09fd2R0OiBGb3VuZCBhIElDSDctTSBvciBJQ0g3LVUg VENPIGRldmljZSAoVmVyc2lvbj0yLCBUQ09CQVNFPTB4MTA2MCkKWyAgIDU4LjUxNzA2OF0gaVRD T193ZHQ6IGluaXRpYWxpemVkLiBoZWFydGJlYXQ9MzAgc2VjIChub3dheW91dD0wKQpbICAgNTgu NTE3MDY4XSBpbml0Y2FsbCBpVENPX3dkdF9pbml0X21vZHVsZSsweDAvMHgxMDAwIFtpVENPX3dk dF0gcmV0dXJuZWQgMCBhZnRlciAyMDU1MSB1c2VjcwpbICAgNTguNTUyMjk4XSBpbml0Y2FsbCBp bml0X210ZCsweDAvMHhmYzAgW210ZF0gcmV0dXJuZWQgMCBhZnRlciAxMTE5ODkgdXNlY3MKWyAg IDU4LjYyMzAwMF0gaW5pdGNhbGwgc3NiX21vZGluaXQrMHgwLzB4NWYgW3NzYl0gcmV0dXJuZWQg MCBhZnRlciA2OTI5OCB1c2VjcwpbICAgNTguNjI4MTY4XSBjYWxsaW5nICBhbHNhX3BjbV9pbml0 KzB4MC8weDEwMDAgW3NuZF9wY21dIEAgNTE2ClsgICA1OC42MjkyMzRdIGluaXRjYWxsIGFsc2Ff cGNtX2luaXQrMHgwLzB4MTAwMCBbc25kX3BjbV0gcmV0dXJuZWQgMCBhZnRlciA5NTEgdXNlY3MK WyAgIDU4LjYzNTU2Nl0gY2FsbGluZyAgbmFzX2dwaW9faW5pdCsweDAvMHhmZTMgW2xlZHNfc3M0 MjAwXSBAIDUxOApbICAgNTguNjM1NjA1XSBsZWRzX3NzNDIwMDogbm8gTEVEIGRldmljZXMgZm91 bmQKWyAgIDU4LjYzNTYzMF0gaW5pdGNhbGwgbmFzX2dwaW9faW5pdCsweDAvMHhmZTMgW2xlZHNf c3M0MjAwXSByZXR1cm5lZCAtMTkgYWZ0ZXIgMjMgdXNlY3MKWyAgIDU4LjY3NzMzNF0gY2FsbGlu ZyAgYXJjNF9pbml0KzB4MC8weDEwMDAgW2FyYzRdIEAgNTM3ClsgICA1OC42ODA2NTFdIGluaXRj YWxsIGFyYzRfaW5pdCsweDAvMHgxMDAwIFthcmM0XSByZXR1cm5lZCAwIGFmdGVyIDMxMTUgdXNl Y3MKWyAgIDU4LjcyMjMzM10gaWVlZTgwMjExIHBoeTA6IFNlbGVjdGVkIHJhdGUgY29udHJvbCBh bGdvcml0aG0gJ2l3bC0zOTQ1LXJzJwpbICAgNTguNzc0OTI1XSBjYWxsaW5nICBiNDRfaW5pdCsw eDAvMHgxMDAwIFtiNDRdIEAgNTI3ClsgICA1OC43NzUzMjZdIHhlbjogcmVnaXN0ZXJpbmcgZ3Np IDE3IHRyaWdnZXJpbmcgMCBwb2xhcml0eSAxClsgICA1OC43NzUzNTldIHhlbl9tYXBfcGlycV9n c2k6IHJldHVybmluZyBpcnEgMTcgZm9yIGdzaSAxNwpbICAgNTguNzc1MzgxXSB4ZW46IC0tPiBw aXJxPTE3IC0+IGlycT0xNyAoZ3NpPTE3KQpbICAgNTguNzc1NDAzXSBBbHJlYWR5IHNldHVwIHRo ZSBHU0kgOjE3ClsgICA1OC43NzU0MjJdIGI0NCAwMDAwOjAzOjAwLjA6IFBDSSBJTlQgQSAtPiBH U0kgMTcgKGxldmVsLCBsb3cpIC0+IElSUSAxNwpbICAgNTguNzgzNjcyXSBzc2I6IENvcmUgMCBm b3VuZDogRmFzdCBFdGhlcm5ldCAoY2MgMHg4MDYsIHJldiAweDA3LCB2ZW5kb3IgMHg0MjQzKQpb ICAgNTguNzgzNzM0XSBzc2I6IENvcmUgMSBmb3VuZDogVjkwIChjYyAweDgwNywgcmV2IDB4MDMs IHZlbmRvciAweDQyNDMpClsgICA1OC43ODM3NzddIHNzYjogQ29yZSAyIGZvdW5kOiBQQ0kgKGNj IDB4ODA0LCByZXYgMHgwQSwgdmVuZG9yIDB4NDI0MykKWyAgIDU4Ljc5ODM4OV0gY2FsbGluZyAg YWxzYV9zZXFfZGV2aWNlX2luaXQrMHgwLzB4MTAwMCBbc25kX3NlcV9kZXZpY2VdIEAgNTQxClsg ICA1OC43OTg2NDNdIGluaXRjYWxsIGFsc2Ffc2VxX2RldmljZV9pbml0KzB4MC8weDEwMDAgW3Nu ZF9zZXFfZGV2aWNlXSByZXR1cm5lZCAwIGFmdGVyIDIwNiB1c2VjcwpbICAgNTguODM1MDc4XSBz c2I6IFNvbmljcyBTaWxpY29uIEJhY2twbGFuZSBmb3VuZCBvbiBQQ0kgZGV2aWNlIDAwMDA6MDM6 MDAuMApbICAgNTguODQ0OTczXSBiNDQ6IEJyb2FkY29tIDQ0eHgvNDd4eCAxMC8xMDAgUENJIGV0 aGVybmV0IGRyaXZlciB2ZXJzaW9uIDIuMApbICAgNTguOTEyMzg0XSBjYWxsaW5nICBuYW5kX2Jh c2VfaW5pdCsweDAvMHgxMDAwIFtuYW5kXSBAIDUyOApbICAgNTguOTE0ODI5XSBpbml0Y2FsbCBu YW5kX2Jhc2VfaW5pdCsweDAvMHgxMDAwIFtuYW5kXSByZXR1cm5lZCAwIGFmdGVyIDIzNDggdXNl Y3MKWyAgIDU4Ljk1NzcxNV0gY2FsbGluZyAgYWxzYV9zZXFfaW5pdCsweDAvMHg0YyBbc25kX3Nl cV0gQCA1NDEKWyAgIDU4Ljk5NjYwNF0gY2FsbGluZyAgcjg1Ml9tb2R1bGVfaW5pdCsweDAvMHgx MDAwIFtyODUyXSBAIDUyOApbICAgNTguOTk2OTc1XSB4ZW46IHJlZ2lzdGVyaW5nIGdzaSAxOCB0 cmlnZ2VyaW5nIDAgcG9sYXJpdHkgMQpbICAgNTguOTk3MDA5XSB4ZW5fbWFwX3BpcnFfZ3NpOiBy ZXR1cm5pbmcgaXJxIDE4IGZvciBnc2kgMTgKWyAgIDU4Ljk5NzAzMl0geGVuOiAtLT4gcGlycT0x OCAtPiBpcnE9MTggKGdzaT0xOCkKWyAgIDU4Ljk5NzA4N10gQWxyZWFkeSBzZXR1cCB0aGUgR1NJ IDoxOApbICAgNTguOTk3MTA5XSByODUyIDAwMDA6MDM6MDEuMzogUENJIElOVCBCIC0+IEdTSSAx OCAobGV2ZWwsIGxvdykgLT4gSVJRIDE4ClsgICA1OC45OTcxNjFdIHI4NTIgMDAwMDowMzowMS4z OiBzZXR0aW5nIGxhdGVuY3kgdGltZXIgdG8gNjQKWyAgIDU5LjAxMTE2Ml0gcjg1MjogTm9uIGRt YSBjYXBhYmxlIGRldmljZSBkZXRlY3RlZCwgZG1hIGRpc2FibGVkClsgICA1OS4wMTE0ODRdIHI4 NTI6IGRyaXZlciBsb2FkZWQgc3VjY2Vzc2Z1bGx5ClsgICA1OS4wMTIwNjBdIGluaXRjYWxsIHI4 NTJfbW9kdWxlX2luaXQrMHgwLzB4MTAwMCBbcjg1Ml0gcmV0dXJuZWQgMCBhZnRlciAxNTA1NyB1 c2VjcwpbICAgNTkuMDM2MjEzXSBiNDQgc3NiMDowOiBldGgwOiBCcm9hZGNvbSA0NHh4LzQ3eHgg MTAvMTAwIFBDSSBldGhlcm5ldCBkcml2ZXIgMDA6MTU6YzU6MDQ6N2Q6NGYKWyAgIDU5LjAzNzQ5 OV0gaW5pdGNhbGwgYjQ0X2luaXQrMHgwLzB4MTAwMCBbYjQ0XSByZXR1cm5lZCAwIGFmdGVyIDI1 NjM3OCB1c2VjcwpbICAgNTkuMTIwMDY3XSBpbml0Y2FsbCBhbHNhX3NlcV9pbml0KzB4MC8weDRj IFtzbmRfc2VxXSByZXR1cm5lZCAwIGFmdGVyIDE1OTYxOSB1c2VjcwpbICAgNTkuMTMzODMzXSBp bml0Y2FsbCBpd2wzOTQ1X2luaXQrMHgwLzB4MTAwMCBbaXdsMzk0NV0gcmV0dXJuZWQgMCBhZnRl ciAxMDgyODMwIHVzZWNzClsgICA1OS4xNDUzMjBdIGNhbGxpbmcgIGFsc2FfaHdkZXBfaW5pdCsw eDAvMHgxMDAwIFtzbmRfaHdkZXBdIEAgNDU5ClsgICA1OS4xNDU2OTRdIGluaXRjYWxsIGFsc2Ff aHdkZXBfaW5pdCsweDAvMHgxMDAwIFtzbmRfaHdkZXBdIHJldHVybmVkIDAgYWZ0ZXIgMzIzIHVz ZWNzClsgICA1OS42MzE0NTRdIGNhbGxpbmcgIGFsc2FfY2FyZF9henhfaW5pdCsweDAvMHgxMDAw IFtzbmRfaGRhX2ludGVsXSBAIDQ1OQpbICAgNTkuNjU1MTA1XSB4ZW46IHJlZ2lzdGVyaW5nIGdz aSAyMSB0cmlnZ2VyaW5nIDAgcG9sYXJpdHkgMQpbICAgNTkuNjU1NTYzXSB4ZW5fbWFwX3BpcnFf Z3NpOiByZXR1cm5pbmcgaXJxIDIxIGZvciBnc2kgMjEKWyAgIDU5LjY1NTU4OF0geGVuOiAtLT4g cGlycT0yMSAtPiBpcnE9MjEgKGdzaT0yMSkKWyAgIDU5LjY1NTYxMV0gQWxyZWFkeSBzZXR1cCB0 aGUgR1NJIDoyMQpbICAgNTkuNjU1NjMyXSBzbmRfaGRhX2ludGVsIDAwMDA6MDA6MWIuMDogUENJ IElOVCBBIC0+IEdTSSAyMSAobGV2ZWwsIGxvdykgLT4gSVJRIDIxCnguYzoyNzEKWyAgIDU5LjY2 NDY1NV0gaW5fYXRvbWljKCk6IDEsIGlycXNfZGlzYWJsZWQoKTogMCwgcGlkOiA0NTksIG5hbWU6 IG1vZHByb2JlClsgICA1OS42NjQ2ODJdIDMgbG9ja3MgaGVsZCBieSBtb2Rwcm9iZS80NTk6Clsg ICA1OS42NjQ2OThdICAjMDogICgmX19sb2NrZGVwX25vX3ZhbGlkYXRlX18pey4uLi4uLn0sIGF0 OiBbPGZmZmZmZmZmODEzMTc2ZDA+XSBfX2RyaXZlcl9hdHRhY2grMHgzYi8weDgyClsgICA1OS42 NjQ3NTZdICAjMTogICgmX19sb2NrZGVwX25vX3ZhbGlkYXRlX18pey4uLi4uLn0sIGF0OiBbPGZm ZmZmZmZmODEzMTc2ZGU+XSBfX2RyaXZlcl9hdHRhY2grMHg0OS8weDgyClsgICA1OS42NjQ4MDhd ICAjMjogIChpcnFfbWFwcGluZ191cGRhdGVfbG9jayl7Ky4rLisufSwgYXQ6IFs8ZmZmZmZmZmY4 MTJkYTZlNj5dIHhlbl9iaW5kX3BpcnFfbXNpX3RvX2lycSsweDMxLzB4ZGEKWyAgIDU5LjY2NDg2 N10gUGlkOiA0NTksIGNvbW06IG1vZHByb2JlIE5vdCB0YWludGVkIDMuMS4wLTAucmM2LmdpdDAu MC5mYzE3Lng4Nl82NCAjMQpbICAgNTkuNjY0ODk3XSBDYWxsIFRyYWNlOgpbICAgNTkuNjY0OTE3 XSAgWzxmZmZmZmZmZjgxMDRmNmQ1Pl0gX19taWdodF9zbGVlcCsweDEwMy8weDEwOApbICAgNTku NjY0OTQzXSAgWzxmZmZmZmZmZjgxNTAzNWYyPl0gbXV0ZXhfbG9ja19uZXN0ZWQrMHgyNS8weDQ1 ClsgICA1OS42NjQ5NzFdICBbPGZmZmZmZmZmODE0ZTEzY2Q+XSBfX2lycV9hbGxvY19kZXNjcysw eDUwLzB4MThiClsgICA1OS42NjUwMDFdICBbPGZmZmZmZmZmODEyZDAyZTY+XSA/IGdoZXNfcHJv Y19pbl9pcnErMHg1Yi8weGE1ClsgICA1OS42NjUwMjldICBbPGZmZmZmZmZmODEyZDljMGU+XSB4 ZW5fYWxsb2NhdGVfaXJxX2R5bmFtaWMrMHg0OS8weDU4ClsgICA1OS42NjUwNThdICBbPGZmZmZm ZmZmODEyZGE2ZWI+XSB4ZW5fYmluZF9waXJxX21zaV90b19pcnErMHgzNi8weGRhClsgICA1OS42 NjUwNjZdICBbPGZmZmZmZmZmODE0MDAxZTM+XSB4ZW5faW5pdGRvbV9zZXR1cF9tc2lfaXJxcysw eDEyOS8weDE1ZApbICAgNTkuNjY1MDY2XSAgWzxmZmZmZmZmZjgxMjdkMjE4Pl0gcGNpX2VuYWJs ZV9tc2lfYmxvY2srMHgxYzAvMHgyMjUKWyAgIDU5LjY2NTA2Nl0gIFs8ZmZmZmZmZmZhMDIwNjhk YT5dIGF6eF9wcm9iZSsweDQzNy8weDk4MiBbc25kX2hkYV9pbnRlbF0KWyAgIDU5LjY2NTA2Nl0g IFs8ZmZmZmZmZmY4MTI2ZDA0Mz5dIGxvY2FsX3BjaV9wcm9iZSsweDQ0LzB4NzUKWyAgIDU5LjY2 NTA2Nl0gIFs8ZmZmZmZmZmY4MTI2ZGJjOT5dIHBjaV9kZXZpY2VfcHJvYmUrMHhkMC8weGZmClsg ICA1OS42NjUwNjZdICBbPGZmZmZmZmZmODEzMTc1YjM+XSBkcml2ZXJfcHJvYmVfZGV2aWNlKzB4 MTMxLzB4MjEzClsgICA1OS42NjUwNjZdICBbPGZmZmZmZmZmODEzMTc2ZjM+XSBfX2RyaXZlcl9h dHRhY2grMHg1ZS8weDgyClsgICA1OS42NjUwNjZdICBbPGZmZmZmZmZmODEzMTc2OTU+XSA/IGRy aXZlcl9wcm9iZV9kZXZpY2UrMHgyMTMvMHgyMTMKWyAgIDU5LjY2NTA2Nl0gIFs8ZmZmZmZmZmY4 MTMxNjVmND5dIGJ1c19mb3JfZWFjaF9kZXYrMHg1OS8weDhmClsgICA1OS42NjUwNjZdICBbPGZm ZmZmZmZmODEzMTcxODc+XSBkcml2ZXJfYXR0YWNoKzB4MWUvMHgyMApbICAgNTkuNjY1MDY2XSAg WzxmZmZmZmZmZjgxMzE2ZDlmPl0gYnVzX2FkZF9kcml2ZXIrMHhkNC8weDIyYQpbICAgNTkuNjY1 MDY2XSAgWzxmZmZmZmZmZmEwMmJmMDAwPl0gPyAweGZmZmZmZmZmYTAyYmVmZmYKWyAgIDU5LjY2 NTA2Nl0gIFs8ZmZmZmZmZmY4MTMxN2JiNj5dIGRyaXZlcl9yZWdpc3RlcisweDk4LzB4MTA1Clsg ICA1OS42NjUwNjZdICBbPGZmZmZmZmZmYTAyYmYwMDA+XSA/IDB4ZmZmZmZmZmZhMDJiZWZmZgpb ICAgNTkuNjY1MDY2XSAgWzxmZmZmZmZmZjgxMjZlNDljPl0gX19wY2lfcmVnaXN0ZXJfZHJpdmVy KzB4NjYvMHhkMgpbICAgNTkuNjY1MDY2XSAgWzxmZmZmZmZmZmEwMmJmMDAwPl0gPyAweGZmZmZm ZmZmYTAyYmVmZmYKWyAgIDU5LjY2NTA2Nl0gIFs8ZmZmZmZmZmZhMDJiZjAxZT5dIGFsc2FfY2Fy ZF9henhfaW5pdCsweDFlLzB4MTAwMCBbc25kX2hkYV9pbnRlbF0KWyAgIDU5LjY2NTA2Nl0gIFs8 ZmZmZmZmZmY4MTAwMjA3MT5dIGRvX29uZV9pbml0Y2FsbCsweDU3LzB4MTNhClsgICA1OS42NjUw NjZdICBbPGZmZmZmZmZmYTAyYmYwMDA+XSA/IDB4ZmZmZmZmZmZhMDJiZWZmZgpbICAgNTkuNjY1 MDY2XSAgWzxmZmZmZmZmZjgxMDlhNjcwPl0gc3lzX2luaXRfbW9kdWxlKzB4MTE0LzB4MjY3Clsg ICA1OS42NjUwNjZdICBbPGZmZmZmZmZmODE1MGJjODI+XSBzeXN0ZW1fY2FsbF9mYXN0cGF0aCsw eDE2LzB4MWIKWyAgIDU5LjY2NjU0Ml0gc25kX2hkYV9pbnRlbCAwMDAwOjAwOjFiLjA6IHNldHRp bmcgbGF0ZW5jeSB0aW1lciB0byA2NApbICAgNTkuNzA4MzY1XSBjYWxsaW5nICBkY2RiYXNfaW5p dCsweDAvMHgxMDAwIFtkY2RiYXNdIEAgNTU3ClsgICA1OS43MTMwNTNdIGRjZGJhcyBkY2RiYXM6 IERlbGwgU3lzdGVtcyBNYW5hZ2VtZW50IEJhc2UgRHJpdmVyICh2ZXJzaW9uIDUuNi4wLTMuMikK WyAgIDU5LjcxMzA5NF0gaW5pdGNhbGwgZGNkYmFzX2luaXQrMHgwLzB4MTAwMCBbZGNkYmFzXSBy ZXR1cm5lZCAwIGFmdGVyIDQ1OTkgdXNlY3MKWyAgIDU5LjgwOTI5NV0gY2FsbGluZyAgbWljcm9j b2RlX2luaXQrMHgwLzB4MTQwIFttaWNyb2NvZGVdIEAgNTYwClsgICA1OS44NDkzMjVdIG1pY3Jv Y29kZTogQ1BVMCBzaWc9MHg2ZjYsIHBmPTB4MjAsIHJldmlzaW9uPTB4YzcKWyAgIDYwLjA0MjM3 NV0gY2FsbGluZyAgZGVsbF9pbml0KzB4MC8weGY2MyBbZGVsbF9sYXB0b3BdIEAgNTU3ClsgICA2 MC4xNzI1ODldIGluaXRjYWxsIGRlbGxfaW5pdCsweDAvMHhmNjMgW2RlbGxfbGFwdG9wXSByZXR1 cm5lZCAwIGFmdGVyIDEyNzAxNiB1c2VjcwpbICAgNjAuMjI1NDQ2XSBjYWxsaW5nICBwYXRjaF9z aWdtYXRlbF9pbml0KzB4MC8weDEwMDAgW3NuZF9oZGFfY29kZWNfaWR0XSBAIDU3NQpbICAgNjAu MjI4MjgwXSBpbml0Y2FsbCBwYXRjaF9zaWdtYXRlbF9pbml0KzB4MC8weDEwMDAgW3NuZF9oZGFf Y29kZWNfaWR0XSByZXR1cm5lZCAwIGFmdGVyIDI2MDUgdXNlY3MKWyAgIDYwLjIzODg4MV0gQUxT QSBzb3VuZC9wY2kvaGRhL2hkYV9jb2RlYy5jOjQ4NzMgYXV0b2NvbmZpZzogbGluZV9vdXRzPTEg KDB4ZS8weDAvMHgwLzB4MC8weDApIHR5cGU6c3BlYWtlcgpbICAgNjAuMjM4OTgxXSBBTFNBIHNv dW5kL3BjaS9oZGEvaGRhX2NvZGVjLmM6NDg3NyAgICBzcGVha2VyX291dHM9MCAoMHgwLzB4MC8w eDAvMHgwLzB4MCkKWyAgIDYwLjIzOTA0N10gQUxTQSBzb3VuZC9wY2kvaGRhL2hkYV9jb2RlYy5j OjQ4ODEgICAgaHBfb3V0cz0xICgweGQvMHgwLzB4MC8weDBbICAgNjAuMjM5MTE4XSBBTFNBIHNv dW5kL3BjaS9oZGEvaGRhX2NvZGVjLmM6NDg4MiAgICBtb25vOiBtb25vX291dD0weDAKWyAgIDYw LjIzOTEzOF0gQUxTQSBzb3VuZC9wY2kvaGRhL2hkYV9jb2RlYy5jOjQ4ODUgICAgZGlnLW91dD0w eDkvMHgwClsgICA2MC4yMzkxMzhdIEFMU0Egc291bmQvcGNpL2hkYS9oZGFfY29kZWMuYzo0ODg2 ICAgIGlucHV0czoKWyAgIDYwLjIzOTEzOF0gQUxTQSBzb3VuZC9wY2kvaGRhL2hkYV9jb2RlYy5j OjQ4OTAgIE1pYz0weDEwClsgICA2MC4yMzkxMzhdIEFMU0Egc291bmQvcGNpL2hkYS9oZGFfY29k ZWMuYzo0ODkyClsgICA2MC45Nzc0OTZdIGlucHV0OiBIREEgSW50ZWwgTWljIGF0IEV4dCBSaWdo dCBKYWNrIGFzIC9kZXZpY2VzL3BjaTAwMDA6MDAvMDAwMDowMDoxYi4wL3NvdW5kL2NhcmQwL2lu cHV0NgpbICAgNjEuMTQyMTUzXSBpbnB1dDogSERBIEludGVsIEhQIE91dCBhdCBFeHQgUmlnaHQg SmFjayBhcyAvZGV2aWNlcy9wY2kwMDAwOjAwLzAwMDA6MDA6MWIuMC9zb3VuZC9jYXJkMC9pbnB1 dDcKWyAgIDYxLjQ5NDc1MF0gY2FsbGluZyAgZGVsbF93bWlfaW5pdCsweDAvMHhmZTEgW2RlbGxf d21pXSBAIDU4NgpbICAgNjEuNTA2NTAxXSBpbml0Y2FsbCBhbHNhX2NhcmRfYXp4X2luaXQrMHgw LzB4MTAwMCBbc25kX2hkYV9pbnRlbF0gcmV0dXJuZWQgMCBhZnRlciAxODMzNDAxIHVzZWNzClsg ICA2MS41MjQ4ODRdIGlucHV0OiBEZWxsIFdNSSBob3RrZXlzIGFzIC9kZXZpY2VzL3ZpcnR1YWwv aW5wdXQvaW5wdXQ4ClsgICA2MS41Mjg0NDVdIGluaXRjYWxsIGRlbGxfd21pX2luaXQrMHgwLzB4 ZmUxIFtkZWxsX3dtaV0gcmV0dXJuZWQgMCBhZnRlciAzMzYzNiB1c2VjcwpTdGFydGluZyAvZGV2 L21hcHBlci92Z19pbnNwNjQwMC1sdl9zd2FwLi4uClsgICA2Mi41NTQ2ODldIEFkZGluZyA0MDYz MjI4ayBzd2FwIG9uIC9kZXYvbWFwcGVyL3ZnX2luc3A2NDAwLWx2X3N3YXAuICBQcmlvcml0eTow IGV4dGVudHM6MSBhY3Jvc3M6NDA2MzIyOGsKU3RhcnRlZCAvZGV2L21hcHBlci92Z19pbnNwNjQw MC1sdl9zd2FwLgooWEVOKSB0cmFwcy5jOjI5NTY6IEdQRiAoMDAwMCk6IGZmZmY4MmM0ODAxN2Mw OTggLT4gZmZmZjgyYzQ4MDIwMDQ1OAooWEVOKSB0cmFwcy5jOjIzODg6ZDAgRG9tYWluIGF0dGVt cHRlZCBXUk1TUiAwMDAwMDAwMDAwMDAwMDc5IGZyb20gMHgwMDAwMDAwMDAwMDAwMDAwIHRvIDB4 ZmZmZmM5MDAwODdlNjAzMC4KWyAgIDYzLjEzMDU4NF0gbWljcm9jb2RlOiBDUFUwIHVwZGF0ZSB0 byByZXZpc2lvbiAweGQxIGZhaWxlZApbICAgNjMuMTMwODA4XSBtaWNyb2NvZGU6IENQVTEgc2ln PTB4NmY2LCBwZj0weDIwLCByZXZpc2lvbj0weGM3CihYRU4pIHRyYXBzLmM6Mjk1NjogR1BGICgw MDAwKTogZmZmZjgyYzQ4MDE3YzA5OCAtPiBmZmZmODJjNDgwMjAwNDU4CihYRU4pIHRyYXBzLmM6 MjM4ODpkMCBEb21haW4gYXR0ZW1wdGVkIFdSTVNSIDAwMDAwMDAwMDAwMDAwNzkgZnJvbSAweDAw MDAwMDAwMDAwMDAwMDAgdG8gMHhmZmZmYzkwMDA4N2YxMDMwLgpbICAgNjMuMTc5MDcwXSBtaWNy b2NvZGU6IENQVTEgdXBkYXRlIHRvIHJldmlzaW9uIDB4ZDEgZmFpbGVkClsgICA2My4xODU0MjVd IG1pY3JvY29kZTogTWljcm9jb2RlIFVwZGF0ZSBEcml2ZXI6IHYyLjAwIDx0aWdyYW5AYWl2YXpp YW4uZnNuZXQuY28udWs+LCBQZXRlciBPcnViYQpbICAgNjMuMTg1NDc2XSBpbml0Y2FsbCBtaWNy b2NvZGVfaW5pdCsweDAvMHgxNDAgW21pY3JvY29kZV0gcmV0dXJuZWQgMCBhZnRlciAzMjk2OTcx IHVzZWNzClN0YXJ0aW5nIEZpbGUgU3lzdGVtIENoZWNrIG9uIC9kZXYvZGlzay9ieS11dWlkLzcx MTVmMzhlLTI4MjUtNGEzZS1iZjRiLTA0OWY0YTRkN2UwMS4uLgpbICAgNjMuOTE0OTc5XSBjZmc4 MDIxMTogV29ybGQgcmVndWxhdG9yeSBkb21haW4gdXBkYXRlZDoKWyAgIDYzLjkxNTA1N10gY2Zn ODAyMTE6ICAgICAoc3RhcnRfZnJlcSAtIGVuZF9mcmVxIEAgYmFuZHdpZHRoKSwgKG1heF9hbnRl bm5hX2dhaW4sIG1heF9laXJwKQpbICAgNjMuOTE1MDcyXSBjZmc4MDIxMTogICAgICgyNDAyMDAw IEtIeiAtIDI0NzIwMDAgS0h6IEAgNDAwMDAgS0h6KSwgKDMwMCBtQmksIDIwMDAgbUJtKQpbICAg NjMuOTE1MDcyXSBjZmc4MDIxMTogICAgICgyNDU3MDAwIEtIeiAtIDI0ODIwMDAgS0h6IEAgMjAw MDAgS0h6KSwgKDMwMCBtQmksIDIwMDAgbUJtKQpbICAgNjMuOTE1MDcyXSBjZmc4MDIxMTogICAg ICgyNDc0MDAwIEtIeiAtIDI0OTQwMDAgS0h6IEAgMjAwMDAgS0h6KSwgKDMwMCBtQmksIDIwMDAg bUJtKQpbICAgNjMuOTE1MDcyXSBjZmc4MDIxMTogICAgICg1MTcwMDAwIEtIeiAtIDUyNTAwMDAg S0h6IEAgNDAwMDAgS0h6KSwgKDMwMCBtQmksIDIwMDAgbUJtKQpbICAgNjMuOTE1MDcyXSBjZmc4 MDIxMTogICAgICg1NzM1MDAwIEtIeiAtIDU4MzUwMDAgS0h6IEAgNDAwMDAgS0h6KSwgKDMwMCBt QmksIDIwMDAgbUJtKQpTdGFydGluZyBIdWdlIFBhZ2VzIEZpbGUgU3lzdGVtLi4uClsgICA2NC4z NDg3NzhdIGNmZzgwMjExOiBDYWxsaW5nIENSREEgZm9yIGNvdW50cnk6IFVTClsgICA2NC40Njk2 NjBdIGNmZzgwMjExOiBSZWd1bGF0b3J5IGRvbWFpbiBjaGFuZ2VkIHRvIGNvdW50cnk6IFVTClsg ICA2NC40Njk3MTZdIGNmZzgwMjExOiAgICAgKHN0YXJ0X2ZyZXEgLSBlbmRfZnJlcSBAIGJhbmR3 aWR0aCksIChtYXhfYW50ZW5uYV9nYWluLCBtYXhfZWlycCkKWyAgIDY0LjQ2OTc0OV0gY2ZnODAy MTE6ICAgICAoMjQwMjAwMCBLSHogLSAyNDcyMDAwIEtIeiBAIDQwMDAwIEtIeiksICgzMDAgbUJp LCAyNzAwIG1CbSkKWyAgIDY0LjQ2OTgxNV0gY2ZnODAyMTE6ICAgICAoNTE3MDAwMCBLSHogLSA1 MjUwMDAwIEtIeiBAIDQwMDAwIEtIeiksICgzMDAgbUJpLCAxNzAwIG1CbSkKWyAgIDY0LjQ2OTg0 Nl0gY2ZnODAyMTE6ICAgICAoNTI1MDAwMCBLSHogLSA1MzMwMDAwIEtIeiBAIDQwMDAwIEtIeiks ICgzMDAgbUJpLCAyMDAwIG1CbSkKWyAgIDY0LjQ2OTg3N10gY2ZnODAyMTE6ICAgICAoNTQ5MDAw MCBLSHogLSA1NjAwMDAwIEtIeiBAIDQwMDAwIEtIeiksICgzMDAgbUJpLCBbICAgNjQuNDY5OTA4 XSBjZmc4MDIxMTogICAgICg1NjUwMDAwIEtIeiAtIDU3MTAwMDAgS0h6IEAgNDAwMDAgS0h6KSwg KDMwMCBtQmksIDIwMDAgbUJtKQpbICAgNjQuNDY5OTM5XSBjZmc4MDIxMTogICAgICg1NzM1MDAw IEtIeiAtIDU4MzUwMDAgS0h6IEAgNDAwMDAgS0h6KSwgKDMwMCBtQmksIDMwMDAgbUJtKQpbICAg NjQuNDgzODY5XSBTRUxpbnV4OiBpbml0aWFsaXplZCAoZGV2IGh1Z2V0bGJmcywgdHlwZSBodWdl dGxiZnMpLCB1c2VzIHRyYW5zaXRpb24gU0lEcwpTdGFydGVkIEh1Z2UgUGFnZXMgRmlsZSBTeXN0 ZW0uClN0YXJ0aW5nIFBPU0lYIE1lc3NhZ2UgUXVldWUgRmlsZSBTeXN0ZW0uLi4KU3RhcnRlZCB1 ZGV2IFdhaXQgZm9yIENvbXBsZXRlIERldmljZSBJbml0aWFsaXphdGlvbi4KU3RhcnRlZCBQT1NJ WCBNZXNzYWdlIFF1ZXVlIEZpbGUgU3lzdGVtLgpTdGFydGluZyBXYWl0IGZvciBzdG9yYWdlIHNj YW4uLi4KWyAgIDY0Ljg3OTk3MF0gc3lzdGVtZC1mc2NrWzYzN106IC9kZXYvc2RhMjogcmVjb3Zl cmluZyBqb3VybmFsCnN5c3RlbWQtZnNja1s2MzddOiAvZGV2L3NkYTI6IHJlY292ZXJpbmcgam91 cm5hbApTdGFydGVkIFNob3cgUGx5bW91dGggQm9vdCBTY3JlZW4uClsgICA2NS42Mjk2MDldIHN5 c3RlbWQtZnNja1s2MzddOiAvZGV2L3NkYTI6IGNsZWFuLCA2MC81MTIwMCBmaWxlcywgMTMwNzA1 LzIwNDgwMCBibG9ja3MKc3lzdGVtZC1mc2NrWzYzN106IC9kZXYvc2RhMjogY2xlYW4sIDYwLzUx MjAwIGZpbGVzLCAxMzA3MDUvMjA0ODAwIGJsb2NrcwpbICAgNjUuNjY1MDkxXSBjYWxsaW5nICB3 YWl0X3NjYW5faW5pdCsweDAvMHgxMDAwIFtzY3NpX3dhaXRfc2Nhbl0gQCA2NTgKWyAgIDY1LjY2 NTE0N10gaW5pdGNhbGwgd2FpdF9zY2FuX2luaXQrMHgwLzB4MTAwMCBbc2NzaV93YWl0X3NjYW5d IHJldHVybmVkIDAgYWZ0ZXIgNCB1c2VjcwpbICAgNjUuODMzOTUyXSB1ZGlza3MtbHZtLXB2LWUg dXNlZCBncmVhdGVzdCBzdGFjayBkZXB0aDogMzIwMCBieXRlcyBsZWZ0ClN0YXJ0ZWQgRmlsZSBT eXN0ZW0gQ2hlY2sgb24gL2Rldi9kaXNrL2J5LXV1aWQvNzExNWYzOGUtMjgyNS00YTNlLWJmNGIt MDQ5ZjRhNGQ3ZTAxLgpTdGFydGVkIFdhaXQgZm9yIHN0b3JhZ2Ugc2Nhbi4KU3RhcnRpbmcgSW5p dGlhbGl6ZSBzdG9yYWdlIHN1YnN5c3RlbXMgKFJBSUQsIExWTSwgZXRjLikuLi4KU3RhcnRpbmcg L2Jvb3QuLi4KWyAgIDY2LjExODcyNF0gRVhUNC1mcyAoc2RhMik6IG1vdW50aW5nIGV4dDMgZmls ZSBzeXN0ZW0gdXNpbmcgdGhlIGV4dDQgc3Vic3lzdGVtClsgICA2Ni4yMTQwNjRdIEVYVDQtZnMg KHNkYTIpOiBtb3VudGVkIGZpbGVzeXN0ZW0gd2l0aCBvcmRlcmVkIGRhdGEgbW9kZS4gT3B0czog KG51bGwpClsgICA2Ni4yMjQ5NzNdIFNFTGludXg6IGluaXRpYWxpemVkIChkZXYgc2RhMiwgdHlw ZSBleHQzKSwgdXNlcyB4YXR0cgpTdGFydGVkIC9ib290LgpTdGFydGVkIEluaXRpYWxpemUgc3Rv cmFnZSBzdWJzeXN0ZW1zIChSQUlELCBMVk0sIGV0Yy4pLgpTdGFydGluZyBJbml0aWFsaXplIHN0 b3JhZ2Ugc3Vic3lzdGVtcyAoUkFJRCwgTFZNLCBldGMuKS4uLgpTdGFydGVkIEluaXRpYWxpemUg c3RvcmFnZSBzdWJzeXN0ZW1zIChSQUlELCBMVk0sIGV0Yy4pLgpTdGFydGVkIFJlY29uZmlndXJl IHRoZSBzeXN0ZW0gb24gYWRtaW5pc3RyYXRvciByZXF1ZXN0LgpTdGFydGluZyBFbmFibGUgYWxs IGRldGVjdGVkIHN3YXAgcGFydGl0aW9ucy4uLgpTdGFydGVkIE1hcmsgdGhlIG5lZWQgdG8gcmVs YWJlbCBhZnRlciByZWJvb3QuClN0YXJ0ZWQgUmVsYWJlbCBhbGwgZmlsZXN5c3RlbXMsIGlmIG5l Y2Vzc2FyeS4KU3RhcnRpbmcgUmVjcmVhdGUgVm9sYXRpbGUgRmlsZXMgYW5kIERpcmVjdG9yaWVz Li4uClN0YXJ0aW5nIExvYWQgUmFuZG9tIFNlZWQuLi4KU3RhcnRpbmcgVGVsbCBQbHltb3V0aCBU byBXcml0ZSBPdXQgUnVudGltZSBEYXRhLi4uClN0YXJ0ZWQgRW5hYmxlIGFsbCBkZXRlY3RlZCBz d2FwIHBhcnRpdGlvbnMuClN0YXJ0ZWQgTG9hZCBSYW5kb20gU2VlZC4KU3RhcnRlZCBUZWxsIFBs eW1vdXRoIFRvIFdyaXRlIE91dCBSdW50aW1lIERhdGEuClN0YXJ0ZWQgUmVjcmVhdGUgVm9sYXRp bGUgRmlsZXMgYW5kIERpcmVjdG9yaWVzLgpTdGFydGluZyBDb25zb2xlIFN5c3RlbSBTdGFydHVw IExvZ2dpbmcuLi4KU3RhcnRpbmcgUmVzdG9yZSBTb3VuZCBDYXJkIFN0YXRlLi4uClN0YXJ0aW5n IEJvb3R1cCB1bmhhY2suLi4KU3RhcnRpbmcgSm9iIHNwb29saW5nIHRvb2xzLi4uClN0YXJ0ZWQg Sm9iIHNwb29saW5nIHRvb2xzLgpTdGFydGluZyBMU0I6IHN0YXJ0IGFuZCBzdG9wIGlwdGFibGVz IGZpcmV3YWxsLi4uClN0YXJ0aW5nIEFCUlQgQXV0b21hdGVkIEJ1ZyBSZXBvcnRpbmcgVG9vbC4u LgpTdGFydGluZyBMU0I6IFN0YXJ0cyBhbmQgc3RvcHMgbG9naW4gaVNDU0kgZGFlbW9uLi4uLgpT dGFydGluZyBMU0I6IENvbmV4YW50IEhTRiBzb2Z0bW9kZW0uLi4KU3RhcnRpbmcgTFNCOiBzdGFy dCBhbmQgc3RvcCBpcDZ0YWJsZXMgZmlyZXdhbGwuLi4KU3RhcnRpbmcgQ29uZXhhbnQgSFNGIHNv ZnRtb2RlbQpbICAgNzEuNzk4Nzc4XSBhYnJ0ZFs3MDddOiBVbnJlY29nbml6ZWQgdmFyaWFibGUg J0R1bXBMb2NhdGlvbicgaW4gJy9ldGMvYWJydC9hYnJ0LmNvbmYnClN0YXJ0aW5nIExTQjogTW9u aXRvcmluZyBvZiBMVk0yIG1pcnJvcnMsIHNuYXBzaG90cyBldGMuIHVzaW5nIGRtZXZlbnRkIG9y IHByb2dyZXNzIHBvbGxpbmcuLi4KU3RhcnRpbmcgQXZhaGkgbUROUy9ETlMtU0QgU3RhY2suLi4K U3RhcnRpbmcgU3lzdGVtIExvZ2dpbmcgU2VydmljZS4uLgpbICAgNzIuNDIwMjQxXSBjYWxsaW5n ICBwaHlzZGV2X210X2luaXQrMHgwLzB4MTAwMCBbeHRfcGh5c2Rldl0gQCA3MzcKWyAgIDcyLjQy MDI4Nl0gaW5pdGNhbGwgcGh5c2Rldl9tdF9pbml0KzB4MC8weDEwMDAgW3h0X3BoeXNkZXZdIHJl dHVybmVkIDAgYWZ0ZXIgNSB1c2VjcwpbICAgNzIuNDg5NDQ2XSAvdXNyL3NiaW4vZ3BtWzc0MV06 ICoqKiBpbmZvIFtkYWVtb24vc3RhcnR1cC5jKDEzNildOgpbICAgNzIuNDkzNjA1XSAvdXNyL3Ni aW4vZ3BtWzc0MV06IFN0YXJ0ZWQgZ3BtIHN1Y2Nlc3NmdWxseS4gRW50ZXJlZCBkYWVtb24gbW9k ZS4KWyAgIDcyLjUxOTk5NV0gY2FsbGluZyAgbG9nX3RnX2luaXQrMHgwLzB4MTAwMCBbaXB0X0xP R10gQCA3NDMKWyAgIDcyLjUyMDA2Ml0gaW5pdGNhbGwgbG9nX3RnX2luaXQrMHgwLzB4MTAwMCBb aXB0X0xPR10gcmV0dXJuZWQgMCBhZnRlciAxMjAgdXNlY3MKU3RhcnRpbmcgaXJxYmFsYW5jZSBk YWVtb24uLi4KWyAgIDcyLjcxNDU4M10gY2FsbGluZyAgbmZfY29ubnRyYWNrX3N0YW5kYWxvbmVf aW5pdCsweDAvMHgxMDAwIFtuZl9jb25udHJhY2tdIEAgNzQ4ClsgICA3Mi43MTQ4NTldIG5mX2Nv bm50cmFjayB2ZXJzaW9uIDAuNS4wICgxNjM4NCBidWNrZXRzLCA2NTUzNiBtYXgpClsgICA3Mi43 Mjg5NzBdIGluaXRjYWxsIG5mX2Nvbm50cmFja19zdGFuZGFsb25lX2luaXQrMHgwLzB4MTAwMCBb bmZfY29ubnRyYWNrXSByZXR1cm5lZCAwIGFmdGVyIDEzODgzIHVzZWNzClsgICA3Mi43ODMyNzNd IGNhbGxpbmcgIHN0YXRlX210X2luaXQrMHgwLzB4MTAwMCBbeHRfc3RhdGVdIEAgNzQ4ClsgICA3 Mi43ODM0MjFdIGluaXRjYWxsIHN0YXRlX210X2luaXQrMHgwLzB4MTAwMCBbeHRfc3RhdGVdIHJl dHVybmVkIDAgYWZ0ZXIgMTMgdXNlY3MKU3RhcnRpbmcgQ29tbWFuZCBTY2hlZHVsZXIuLi4KWyAg IDcyLjg5OTAzM10gY2FsbGluZyAgbmZfZGVmcmFnX2luaXQrMHgwLzB4MTAwMCBbbmZfZGVmcmFn X2lwdjRdIEAgNzU0ClsgICA3Mi44OTkyNzRdIGluaXRjYWxsIG5mX2RlZnJhZ19pbml0KzB4MC8w eDEwMDAgW25mX2RlZnJhZ19pcHY0XSByZXR1cm5lZCAwIGFmdGVyIDk2IHVzZWNzClN0YXJ0ZWQg Q29tbWFuZCBTY2hlZHVsZXIuClN0YXJ0aW5nIE1hY2hpbmUgQ2hlY2sgRXhjZXB0aW9uIExvZ2dp bmcgRGFlbW9uLi4uClN0YXJ0aW5nIEQtQnVzIFN5c3RlbSBNZXNzYWdlIEJ1cy4uLgpbICAgNzMu MDMxMTgxXSBjYWxsaW5nICBuZl9jb25udHJhY2tfbDNwcm90b19pcHY0X2luaXQrMHgwLzB4MTAw MCBbbmZfY29ubnRyYWNrX2lwdjRdIEAgNzU0ClsgICA3My4wNDQ2OThdIGluaXRjYWxsIG5mX2Nv bm50cmFja19sM3Byb3RvX2lwdjRfaW5pdCsweDAvMHgxMDAwIFtuZl9jb25udHJhY2tfaXB2NF0g cmV0dXJuZWQgMCBhZnRlciAxMzA0NyB1c2VjcwpbICAgNzMuMTk4Nzk2XSBjYWxsaW5nICBjb21t ZW50X210X2luaXQrMHgwLzB4MTAwMCBbeHRfY29tbWVudF0gQCA3NjQKWyAgIDczLjE5ODk0N10g aW5pdGNhbGwgY29tbWVudF9tdF9pbml0KzB4MC8weDEwMDAgW3h0X2NvbW1lbnRdIHJldHVybmVk IDAgYWZ0ZXIgMTQgdXNlY3MKU3RhcnRlZCBDb25zb2xlIFN5c3RlbSBTdGFydHVwIExvZ2dpbmcu ClsgIE9LICBdClN0YXJ0ZWQgUmVzdG9yZSBTb3VuZCBDYXJkIFN0YXRlLgpTdGFydGVkIEJvb3R1 cCB1bmhhY2suClN0YXJ0ZWQgQ29uc29sZSBNb3VzZSBtYW5hZ2VyLgpTdG9wcGluZyBTeXNsb2cg S2VybmVsIExvZyBCdWZmZXIgQnJpZGdlLi4uClN0b3BwZWQgU3lzbG9nIEtlcm5lbCBMb2cgQnVm ZmVyIEJyaWRnZS4KU3RhcnRlZCBTeXN0ZW0gTG9nZ2luZyBTZXJ2aWNlLgpTdGFydGVkIExTQjog c3RhcnQgYW5kIHN0b3AgaXB0YWJsZXMgZmlyZXdhbGwuClN0YXJ0ZWQgaXJxYmFsYW5jZSBkYWVt b24uCmlwNnRhYmxlczogQXBwbHlpbmcgZmlyZXdhbGwgcnVsZXM6IFN0YXJ0ZWQgRC1CdXMgU3lz dGVtIE1lc3NhZ2UgQnVzLgpbICAgNzQuOTk4ODUzXSBjYWxsaW5nICBpcDZfdGFibGVzX2luaXQr MHgwLzB4MTAwMCBbaXA2X3RhYmxlc10gQCA3OTEKWyAgIDc0Ljk5OTA2Nl0gaXA2X3RhYmxlczog KEMpIDIwMDAtMjAwNiBOZXRmaWx0ZXIgQ29yZSBUZWFtClsgICA3NC45OTkwNjZdIGluaXRjYWxs IGlwNl90YWJsZXNfaW5pdCsweDAvMHgxMDAwIFtpcDZfdGFibGVzXSByZXR1cm5lZCAwIGFmdGVy IDIxOCB1c2VjcwpTdGFydGluZyBpc2NzaWQ6IFsgICA3NS4yNDAzMDZdIGNhbGxpbmcgIGlwNnRh YmxlX2ZpbHRlcl9pbml0KzB4MC8weDEwMDAgW2lwNnRhYmxlX2ZpbHRlcl0gQCA3OTMKWyAgIDc1 LjI0MDU4Nl0gaW5pdGNhbGwgaXA2dGFibGVfZmlsdGVyX2luaXQrMHgwLzB4MTAwMCBbaXA2dGFi bGVfZmlsdGVyXSByZXR1cm5lZCAwIGFmdGVyIDE4OCB1c2VjcwpbICAgNzUuMzU3NzQ5XSBjYWxs aW5nICBuZl9kZWZyYWdfaW5pdCsweDAvMHgxMDAwIFtuZl9kZWZyYWdfaXB2Nl0gQCA3OTkKWyAg IDc1LjM1ODQ2NF0gaW5pdGNhbGwgbmZfZGVmcmFnX2luaXQrMHgwLzB4MTAwMCBbbmZfZGVmcmFn X2lwdjZdIHJldHVybmVkIDAgYWZ0ZXIgNjE3IHVzZWNzClsgICA3NS4zNjU0NDddIGNhbGxpbmcg IG5mX2Nvbm50cmFja19sM3Byb3RvX2lwdjZfaW5pdCsweDAvMHgxMDAwIFtuZl9jb25udHJhY2tf WyAgIDc1LjM4MDA2OF0gaW5pdGNhbGwgbmZfY29ubnRyYWNrX2wzcHJvdG9faXB2Nl9pbml0KzB4 MC8weDEwMDAgW25mX2Nvbm50cmFja19pcHY2XSByZXR1cm5lZCAwIGFmdGVyIDE0NDE4IHVzZWNz ClsgICA3NS4zODMzNjhdIGNhbGxpbmcgIGlzY3NpX3RyYW5zcG9ydF9pbml0KzB4MC8weDEwMDAg W3Njc2lfdHJhbnNwb3J0X2lzY3NpXSBAIDc5NApbICAgNzUuMzgzNDA3XSBMb2FkaW5nIGlTQ1NJ IHRyYW5zcG9ydCBjbGFzcyB2Mi4wLTg3MC4KWyAgIDc1LjQwMTM0OV0gaW5pdGNhbGwgaXNjc2lf dHJhbnNwb3J0X2luaXQrMHgwLzB4MTAwMCBbc2NzaV90cmFuc3BvcnRfaXNjc2ldIHJldHVybmVk IDAgYWZ0ZXIgMTc1MTAgdXNlY3MKWyAgIDc1LjQ0Mzc4NV0gY2FsbGluZyAgcmVqZWN0X3RnNl9p bml0KzB4MC8weDEwMDAgW2lwNnRfUkVKRUNUXSBAIDgwMgpbICAgNzUuNDQzODcyXSBpbml0Y2Fs bCByZWplY3RfdGc2X2luaXQrMHgwLzB4MTAwMCBbaXA2dF9SRUpFQ1RdIHJldHVybmVkIDAgYWZ0 ZXIgNSB1c2VjcwpbICBPSyAgXQpbICAgNzUuNzM3NzM4XSBjYWxsaW5nICBpc2NzaV9zd190Y3Bf aW5pdCsweDAvMHgxMDAwIFtpc2NzaV90Y3BdIEAgNzk0ClsgICA3NS43NTY1NzRdIGlzY3NpOiBy ZWdpc3RlcmVkIHRyYW5zcG9ydCAodGNwKQpbICAgNzUuNzU2NjU1XSBpbml0Y2FsbCBpc2NzaV9z d190Y3BfaW5pdCsweDAvMHgxMDAwIFtpc2NzaV90Y3BdIHJldHVybmVkIDAgYWZ0ZXIgMTgzNDYg dXNlY3MKWyAgIDc2LjAxMDc1NV0gY2FsbGluZyAgYWRkcl9pbml0KzB4MC8weDEwMDAgW2liX2Fk ZHJdIEAgODE0ClsgICA3Ni4wMTkzMjBdIGluaXRjYWxsIGFkZHJfaW5pdCsweDAvMHgxMDAwIFtp Yl9hZGRyXSByZXR1cm5lZCAwIGFmdGVyIDgyODIgdXNlY3MKWyAgIDc2LjEyMDc5Nl0gY2FsbGlu ZyAgaWJfY29yZV9pbml0KzB4MC8weDljIFtpYl9jb3JlXSBAIDgxNApbICAgNzYuMTI4ODMyXSBp bml0Y2FsbCBpYl9jb3JlX2luaXQrMHgwLzB4OWMgW2liX2NvcmVdIHJldHVybmVkIDAgYWZ0ZXIg Nzc1OSB1c2VjcwpbICAgNzYuMTY5Njg0XSBjYWxsaW5nICBpYl9tYWRfaW5pdF9tb2R1bGUrMHgw LzB4MTAwMCBbaWJfbWFkXSBAIDgxNApbICAgNzYuMTcxNDEwXSBpbml0Y2FsbCBpYl9tYWRfaW5p dF9tb2R1bGUrMHgwLzB4MTAwMCBbaWJfbWFkXSByZXR1cm5lZCAwIGFmdGVyIDE2NzEgdXNlY3MK WyAgIDc2LjI0MzY2M10gY2FsbGluZyAgaWJfc2FfaW5pdCsweDAvMHgxMDAwIFtpYl9zYV0gQCA4 MTQKWyAgIDc2LjI0OTg4MF0gaW5pdGNhbGwgaWJfc2FfaW5pdCsweDAvMHgxMDAwIFtpYl9zYV0g cmV0dXJuZWQgMCBhZnRlciA1OTkzIHVzZWNzClsgICA3Ni4yNzEzMjVdIGNhbGxpbmcgIGl3X2Nt X2luaXQrMHgwLzB4MTAwMCBbaXdfY21dIEAgODE0ClsgICA3Ni4yNzk1OTBdIGluaXRjYWxsIGl3 X2NtX2luaXQrMHgwLzB4MTAwMCBbaXdfY21dIHJldHVybmVkIDAgYWZ0ZXIgNzk4OSB1c2Vjcwpb ICAgNzYuMzMxMzIxXSBjYWxsaW5nICBpYl9jbV9pbml0KzB4MC8weDEwMDAgW2liX2NtXSBAIDgx NApbICAgNzYuMzQyMzc1XSBpbml0Y2FsbCBpYl9jbV9pbml0KzB4MC8weDEwMDAgW2liX2NtXSBy ZXR1cm5lZCAwIGFmdGVyIDEwNzAwIHVzZWNzClN0YXJ0aW5nIG1vbml0b3JpbmcgZm9yIFZHIHZn X2luc3A2NDAwOiBbICAgNzYuNDYwNTgzXSBjYWxsaW5nICBjbWFfaW5pdCsweDAvMHgxMDAwIFty ZG1hX2NtXSBAIDgxNApbICAgNzYuNDg1MTI3XSBpbml0Y2FsbCBjbWFfaW5pdCsweDAvMHgxMDAw IFtyZG1hX2NtXSByZXR1cm5lZCAwIGFmdGVyIDI0MDcyIHVzZWNzClsgICA3Ni44NDg0MjddIGNh bGxpbmcgIGlzZXJfaW5pdCsweDAvMHgxMDAwIFtpYl9pc2VyXSBAIDgxNApbICAgNzYuODUzODU5 XSBpc2NzaTogcmVnaXN0ZXJlZCB0cmFuc3BvcnQgKGlzZXIpClsgICA3Ni44NTM5MDRdIGluaXRj YWxsIGlzZXJfaW5pdCsweDAvMHgxMDAwIFtpYl9pc2VyXSByZXR1cm5lZCAwIGFmdGVyIDUyNjcg dXNlY3MKWyAgIDc3LjM3MTUxMl0gY2FsbGluZyAgY3hnYjNfaW5pdF9tb2R1bGUrMHgwLzB4MjUg W2N4Z2IzXSBAIDgzNgpbICAgNzcuMzg4NTAyXSBpbml0Y2FsbCBjeGdiM19pbml0X21vZHVsZSsw eDAvMHgyNSBbY3hnYjNdIHJldHVybmVkIDAgYWZ0ZXIgMTY1MjYgdXNlY3MKWyAgIDc3LjU0NjAw NF0gY2FsbGluZyAgaXdjaF9pbml0X21vZHVsZSsweDAvMHgzYSBbaXdfY3hnYjNdIEAgODM3CgpO byBwcmUtYnVpbHQgbW9kdWxlcyBmb3I6IEZlZG9yYS0xNSBsaW51eC0zLjEuMC0wLnJjNi5naXQw LjAuZmMxNy54ODZfNjQgeDg2XzY0LVNNUApbICAgNzcuNTU5NjM2XSBpbml0Y2FsbCBpd2NoX2lu aXRfbW9kdWxlKzB4MC8weDNhIFtpd19jeGdiM10gcmV0dXJuZWQgMCBhZnRlciAxMzE5OCB1c2Vj cwoKVHJ5aW5nIHRvIGF1dG9tYXRpY2FsbHkgYnVpbGQgdGhlIGRyaXZlciBtb2R1bGVzLi4uCih0 aGlzIHJlcXVpcmVzIGEgQyBjb21waWxlciBhbmQgcHJvcGVyIGtlcm5lbCBzb3VyY2VzIHRvIGJl IGluc3RhbGxlZCkKWyAgIDc3Ljk2NDQzM10gY2FsbGluZyAgbGliY3hnYmlfaW5pdF9tb2R1bGUr MHgwLzB4MTAwMCBbbGliY3hnYmldIEAgODMyClsgICA3Ny45NjQ1MTZdIGxpYmN4Z2JpOmxpYmN4 Z2JpX2luaXRfbW9kdWxlOiB0YWcgaXR0IDB4MWZmZiwgMTMgYml0cywgYWdlIDB4ZiwgNCBiaXRz LgpbICAgNzcuOTY0NTQ2XSBsaWJjeGdiaTpkZHBfc2V0dXBfaG9zdF9wYWdlX3NpemU6IHN5c3Rl bSBQQUdFIDQwOTYsIGRkcCBpZHggMC4KWyAgIDc3Ljk2NDU3Nl0gaW5pdGNhbGwgbGliY3hnYmlf aW5pdF9tb2R1bGUrMHgwLzB4MTAwMCBbbGliY3hnYmldIHJldHVybmVkIDAgYWZ0ZXIgNTYgdXNl Y3MKWyAgIDc4LjI4MDI5Nl0gQ2hlbHNpbyBUMyBpU0NTSSBEcml2ZXIgY3hnYjNpIHYyLjAuMCAo SnVuLiAyMDEwKQpbICAgNzguMjg1MjM3XSBpc2NzaTogcmVnaXN0ZXJlZCB0cmFuc3BvcnQgKGN4 Z2IzaSkKWyAgIDc4LjI4NTMzMl0gaW5pdGNhbGwgY3hnYjNpX2luaXRfbW9kdWxlKzB4MC8weDEw MDAgW2N4Z2IzaV0gcmV0dXJuZWQgMCBhZnRlciA0OTAyIHVzZWNzCiAgMiBsb2dpY2FsIHZvbHVt ZShzKSBpbiB2b2x1bWUgZ3JvdXAgInZnX2luc3A2NDAwIiBtb25pdG9yZWQKU3RhcnRlZCBMU0I6 IHN0YXJ0IGFuZCBzdG9wIGlwNnRhYmxlcyBmaXJld2FsbC4KU3RhcnRlZCBNYWNoaW5lIENoZWNr IEV4Y2VwdGlvbiBMb2dnaW5nIERhZW1vbi4KU3RhcnRlZCBBdmFoaSBtRE5TL0ROUy1TRCBTdGFj ay4KU3RhcnRlZCBBQlJUIEF1dG9tYXRlZCBCdWcgUmVwb3J0aW5nIFRvb2wuClsgIE9LICBdClsg ICA3OS4yOTM1ODhdIGNhbGxpbmcgIHVpb19pbml0KzB4MC8weDEwMDAgW3Vpb10gQCA4NDcKWyAg IDc5LjI5Mzk1OF0gaW5pdGNhbGwgdWlvX2luaXQrMHgwLzB4MTAwMCBbdWlvXSByZXR1cm5lZCAw IGFmdGVyIDI4MSB1c2VjcwpbICAgNzkuNDAyNjcxXSBjYWxsaW5nICBjbmljX2luaXQrMHgwLzB4 MTAwMCBbY25pY10gQCA4NDcKWyAgIDc5LjQwMjgwNl0gY25pYzogQnJvYWRjb20gTmV0WHRyZW1l IElJIENOSUMgRHJpdmVyIGNuaWMgdjIuNS43IChKdWx5IDIwLCAyMDExKQpbICAgNzkuNDUyOTkw XSBpbml0Y2FsbCBjbmljX2luaXQrMHgwLzB4MTAwMCBbY25pY10gcmV0dXJuZWQgMCBhZnRlciA0 ODk4NyB1c2VjcwpTdGFydGVkIExTQjogTW9uaXRvcmluZyBvZiBMVk0yIG1pcnJvcnMsIHNuYXBz aG90cyBldGMuIHVzaW5nIGRtZXZlbnRkIG9yIHByb2dyZXNzIHBvbGxpbmcuClsgICA3OS43MjA2 ODRdIGNhbGxpbmcgIGJueDJpX21vZF9pbml0KzB4MC8weDEwMDAgW2JueDJpXSBAIDg0NwpbICAg NzkuNzIwNzY0XSBCcm9hZGNvbSBOZXRYdHJlbWUgSUkgaVNDU0kgRHJpdmVyIGJueDJpIHYyLjcu MC4zIChKdW4gMTUsIDIwMTEpClsgICA3OS43MjE4MjJdIGlzY3NpOiByZWdpc3RlcmVkIHRyYW5z cG9ydCAoYm54MmkpClsgICA3OS43NDMzNzJdIGluaXRjYWxsIGJueDJpX21vZF9pbml0KzB4MC8w eDEwMDAgW2JueDJpXSByZXR1cm5lZCAwIGFmdGVyIDIyMDY5IHVzZWNzClsgICA4MC4wNzM5MDFd IGNhbGxpbmcgIGJlaXNjc2lfbW9kdWxlX2luaXQrMHgwLzB4MTAwMCBbYmUyaXNjc2ldIEAgODU2 ClsgICA4MC4wNzUyNzNdIGlzY3NpOiByZWdpc3RlcmVkIHRyYW5zcG9ydCAoYmUyaXNjc2kpClsg ICA4MC4wNzYzOTBdIGluaXRjYWxsIGJlaXNjc2lfbW9kdWxlX2luaXQrMHgwLzB4MTAwMCBbYmUy aXNjc2ldIHJldHVybmVkIDAgYWZ0ZXIgMjM0NiB1c2VjcwoKQnVpbGRpbmcgbW9kdWxlcyBmb3Ig a2VybmVsIDMuMS4wLTAucmM2LmdpdDAuMC5mYzE3Lng4Nl82NCwgdXNpbmcgc291cmNlIGRpcmVj dG9yeQovbGliL21vZHVsZXMvMy4xLjAtMC5yYzYuZ2l0MC4wLmZjMTcueDg2XzY0L2J1aWxkLiBQ bGVhc2Ugd2FpdC4uLgpbICBPSyAgXQpbICAgODAuOTUxODc4XSBpc2NzaWQgKDg3MSk6IC9wcm9j Lzg3MS9vb21fYWRqIGlzIGRlcHJlY2F0ZWQsIHBsZWFzZSB1c2UgL3Byb2MvODcxL29vbV9zY29y ZV9hZGogaW5zdGVhZC4KU3RhcnRlZCBMU0I6IFN0YXJ0cyBhbmQgc3RvcHMgbG9naW4gaVNDU0kg ZGFlbW9uLi4KU3RhcnRpbmcgU1lTVjogc3RhcnQgYW5kIHN0b3AgSVNETiBzZXJ2aWNlcy4uLgpT dGFydGVkIFNZU1Y6IHN0YXJ0IGFuZCBzdG9wIElTRE4gc2VydmljZXMuClN0YXJ0aW5nIExTQjog QnJpbmcgdXAvZG93biBuZXR3b3JraW5nLi4uClN0YXJ0aW5nIExTQjogUG9ydCByZXNlcnZhdGlv biB1dGlsaXR5Li4uClN0YXJ0aW5nIHBvcnRyZXNlcnZlOiBbICBPSyAgXQpTdGFydGVkIExTQjog UG9ydCByZXNlcnZhdGlvbiB1dGlsaXR5LgpCcmluZ2luZyB1cCBsb29wYmFjayBpbnRlcmZhY2U6 ICBbICBPSyAgXQpCcmluZ2luZyB1cCBpbnRlcmZhY2UgYm9uZDA6ICBbICAgODkuMjA2NzgxXSBj YWxsaW5nICBib25kaW5nX2luaXQrMHgwLzB4MTAwMCBbYm9uZGluZ10gQCAxMTY0ClsgICA4OS4y MDY5MTRdIGJvbmRpbmc6IEV0aGVybmV0IENoYW5uZWwgQm9uZGluZyBEcml2ZXI6IHYzLjcuMSAo QXByaWwgMjcsIDIwMTEpClsgICA4OS4zMDMzMjldIGluaXRjYWxsIGJvbmRpbmdfaW5pdCsweDAv MHgxMDAwIFtib25kaW5nXSByZXR1cm5lZCAwIGFmdGVyIDk0MTQwIHVzZWNzClsgICA4OS4zMzAy MzBdIGJvbmRpbmc6IGJvbmQwIGlzIGJlaW5nIGNyZWF0ZWQuLi4KWyAgIDg5LjMzMDgzNV0gYm9u ZGluZzogYm9uZDAgYWxyZWFkeSBleGlzdHMuClsgICA5MC4xMDU4NjhdIGJvbmRpbmc6IGJvbmQw OiBzZXR0aW5nIG1vZGUgdG8gYmFsYW5jZS10bGIgKDUpLgpbICAgOTAuMTA3MjgyXSBib25kaW5n OiBib25kMDogU2V0dGluZyBNSUkgbW9uaXRvcmluZyBpbnRlcnZhbCB0byA1LgpbICAgOTAuMTA4 MDMwXSBib25kaW5nOiBib25kMDogU2V0dGluZyBkb3duIGRlbGF5IHRvIDIwMDAuClsgICA5MC4x ODQ1ODFdIEFERFJDT05GKE5FVERFVl9VUCk6IGJvbmQwOiBsaW5rIGlzIG5vdCByZWFkeQpbICAg OTAuNzIwNjgzXSBib25kaW5nOiBib25kMDogQWRkaW5nIHNsYXZlIGV0aDAuClsgICA5MC44Nzgz MjFdIGJvbmRpbmc6IGJvbmQwOiBlbnNsYXZpbmcgZXRoMCBhcyBhbiBhY3RpdmUgaW50ZXJmYWNl IHdpdGggYSBkb3duIGxpbmsuCkVSUk9SICAgIDogWy9ldGMvc3lzY29uZmlnL25ldHdvcmstc2Ny aXB0cy9pZnVwLWV0aF0gRGV2aWNlIGV0aDEgZG9lcyBub3Qgc2VlbSB0byBiZSBwcmVzZW50LCBk ZWxheWluZyBpbml0aWFsaXphdGlvbi4KWyAgIDkyLjYwMjY1Nl0gY2FsbGluZyAgbGxjX2luaXQr MHgwLzB4MTAwMCBbbGxjXSBAIDEzMjUKWyAgIDkyLjY3OTkxMF0gY2FsbGluZyAgYnJfaW5pdCsw eDAvMHhiZCBbYnJpZGdlXSBAIDEzMjUKWyAgIDkyLjY4MTIzNF0gQnJpZGdlIGZpcmV3YWxsaW5n IHJlZ2lzdGVyZWQKWyAgIDkyLjY4MTIzNF0gaW5pdGNhbGwgYnJfaW5pdCsweDAvMHhiZCBbYnJp ZGdlXSByZXR1cm5lZCAwIGFmdGVyIDE2ODQgdXNlY3MKClsgICA5Mi43OTk3MDFdIGRldmljZSBi b25kMCBlbnRlcmVkIHByb21pc2N1b3VzIG1vZGUKWyAgT0sgIF0KQnJpbmdpbmcgdXAgaW50ZXJm YWNlIHhlbmJyMDogIFsgICA5My43MDQ5MDhdIGI0NCBzc2IwOjA6IGV0aDA6IExpbmsgaXMgdXAg YXQgMTAwIE1icHMsIGZ1bGwgZHVwbGV4ClsgICA5My43MDQ5NjJdIGI0NCBzc2IwOjA6IGV0aDA6 IEZsb3cgY29udHJvbCBpcyBvZmYgZm9yIFRYIGFuZCBvZmYgZm9yIFJYClsgICA5My43OTE2MDFd IGJvbmRpbmc6IGJvbmQwOiBsaW5rIHN0YXR1cyBkZWZpbml0ZWx5IHVwIGZvciBpbnRlcmZhY2Ug ZXRoMCwgMTAwIE1icHMgZnVsbCBkdXBsZXguClsgICA5My43OTE3NjVdIGJvbmRpbmc6IGJvbmQw OiBtYWtpbmcgaW50ZXJmYWNlIGV0aDAgdGhlIG5ldyBhY3RpdmUgb25lLgpbICAgOTMuNzkxODIz XSBkZXZpY2UgZXRoMCBlbnRlcmVkIHByb21pc2N1b3VzIG1vZGUKWyAgIDkzLjc5OTIwMV0gYm9u ZGluZzogYm9uZDA6IGZpcnN0IGFjdGl2ZSBpbnRlcmZhY2UgdXAhCgpEZXRlcm1pbmluZyBJUCBp bmZvcm1hdGlvbiBmb3IgeGVuYnIwLi4uWyAgIDk0LjEzMTYzNV0gQUREUkNPTkYoTkVUREVWX0NI QU5HRSk6IGJvbmQwOiBsaW5rIGJlY29tZXMgcmVhZHkKWyAgIDk0LjE2MzA2N10geGVuYnIwOiBw b3J0IDEoYm9uZDApIGVudGVyaW5nIGZvcndhcmRpbmcgc3RhdGUKWyAgIDk0LjE2MzUzMV0geGVu YnIwOiBwb3J0IDEoYm9uZDApIGVudGVyaW5nIGZvcndhcmRpbmcgc3RhdGUKIGRvbmUuClsgIE9L ICBdClN0YXJ0ZWQgTFNCOiBCcmluZyB1cC9kb3duIG5ldHdvcmtpbmcuClN0YXJ0aW5nIC93aW5k b3dzL0MuLi4KU3RhcnRpbmcgL3dpbmRvd3MvRGlnaS4uLgpTdGFydGluZyBTZXQgdGltZSB2aWEg TlRQLi4uClsgIDEwMS4zNTA1MjJdIGNhbGxpbmcgIGZzY2FjaGVfaW5pdCsweDAvMHgyMTYgW2Zz Y2FjaGVdIEAgMTc2MwpbICAxMDEuMzUxOTk5XSBGUy1DYWNoZTogTG9hZGVkClsgIDEwMS4zNTIw MjZdIGluaXRjYWxsIGZzY2FjaGVfaW5pdCsweDAvMHgyMTYgW2ZzY2FjaGVdIHJldHVybmVkIDAg YWZ0ZXIgMTM4NSB1c2VjcwpbICAxMDEuNDczMDQ2XSBjYWxsaW5nICBpbml0X2NpZnMrMHgwLzB4 MTAwMCBbY2lmc10gQCAxNzYzClsgIDEwMS40NzQwMTddIEZTLUNhY2hlOiBOZXRmcyAnY2lmcycg cmVnaXN0ZXJlZCBmb3IgY2FjaGluZwpbICAxMDEuNDc5OTgwXSBpbml0Y2FsbCBpbml0X2NpZnMr MHgwLzB4MTAwMCBbY2lmc10gcmV0dXJuZWQgMCBhZnRlciA2Njc4IHVzZWNzClsgIDEwMS41NjY2 NDhdIGNhbGxpbmcgIGluaXRfbmxzX3V0ZjgrMHgwLzB4MTAwMCBbbmxzX3V0ZjhdIEAgMTc3NApb ICAxMDEuNTY2NzMzXSBpbml0Y2FsbCBpbml0X25sc191dGY4KzB4MC8weDEwMDAgW25sc191dGY4 XSByZXR1cm5lZCAwIGFmdGVyIDMgdXNlY3MKWyAgMTAxLjc3NDYzOF0gQ0lGUyBWRlM6IGRlZmF1 bHQgc2VjdXJpdHkgbWVjaGFuaXNtIHJlcXVlc3RlZC4gIFRoZSBkZWZhdWx0IHNlY3VyaXR5IG1l Y2hhbmlzbSB3aWxsIGJlIHVwZ3JhZGVkIGZyb20gbnRsbSB0byBudGxtdjIgaW4ga2VybmVsIHJl bGVhc2UgMy4xClsgIDEwMS44ODYyMzZdIGNhbGxpbmcgIG1kNF9tb2RfaW5pdCsweDAvMHgxMDAw IFttZDRdIEAgMTgwMgpbICAxMDEuODkxMTMzXSBpbml0Y2FsbCBtZDRfbW9kX2luaXQrMHgwLzB4 MTAwMCBbbWQ0XSByZXR1cm5lZCAwIGFmdGVyIDQ3MjIgdXNlY3MKWyAgMTAyLjE2NzQ4M10gY2Fs bGluZyAgZGVzX2dlbmVyaWNfbW9kX2luaXQrMHgwLzB4MTAwMCBbZGVzX2dlbmVyaWNdIEAgMTgy NgpbICAxMDIuMTc0NzkyXSBpbml0Y2FsbCBkZXNfZ2VuZXJpY19tb2RfaW5pdCsweDAvMHgxMDAw IFtkZXNfZ2VuZXJpY10gcmV0dXJuZWQgMCBhZnRlciA3MDUzIHVzZWNzClsgIDEwMi4yNzg3MDZd IFNFTGludXg6IGluaXRpYWxpemVkIChkZXYgY2lmcywgdHlwZSBjaWZzKSwgdXNlcyBnZW5mc19j b250ZXh0cwpbICAxMDIuMjgxNjk5XSBTRUxpbnV4OiBpbml0aWFsaXplZCAoZGV2IGNpZnMsIHR5 cGUgY2lmcyksIHVzZXMgZ2VuZnNfY29udGV4dHMKU3RhcnRlZCAvd2luZG93cy9EaWdpLgpTdGFy dGVkIC93aW5kb3dzL0MuClsgIDEwMi4yOTQ5NDZdIG1vdW50LmNpZnMgdXNlZCBncmVhdGVzdCBz dGFjayBkZXB0aDogMjkyOCBieXRlcyBsZWZ0ClsgIDEwNC4zODcwOTJdIHhlbmJyMDogbm8gSVB2 NiByb3V0ZXJzIHByZXNlbnQKWyAgMTA0LjY3NDIxNV0gYm9uZDA6IG5vIElQdjYgcm91dGVycyBw cmVzZW50ClN0YXJ0ZWQgU2V0IHRpbWUgdmlhIE5UUC4KU3RhcnRpbmcgTmV0d29yayBUaW1lIFNl cnZpY2UuLi4KU3RhcnRlZCBOZXR3b3JrIFRpbWUgU2VydmljZS4KWyAgMTI0LjMwNTg3OF0KWyAg MTI0LjMwNTg4NF0gPT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09 PT09PT09PT09ClsgIDEyNC4zMDYwMzZdIFsgSU5GTzogSEFSRElSUS1zYWZlIC0+IEhBUkRJUlEt dW5zYWZlIGxvY2sgb3JkZXIgZGV0ZWN0ZWQgXQpbICAxMjQuMzA2MDk1XSAzLjEuMC0wLnJjNi5n aXQwLjAuZmMxNy54ODZfNjQgIzEKWyAgMTI0LjMwNjEzOF0gLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tClsgIDEyNC4zMDYxOTZdIHN3YXBwZXIv MCBbSEMwWzBdOlNDMVszXTpIRTA6U0UwXSBpcyB0cnlpbmcgdG8gYWNxdWlyZToKWyAgMTI0LjMw NjI1NF0gIChuZl9jb25udHJhY2tfbG9jayl7Ky4tLi4ufSwgYXQ6IFs8ZmZmZmZmZmZhMDMzYzdi Nz5dIGRlc3Ryb3lfY29bICAxMjQuMzA2Mzk3XQpbICAxMjQuMzA2Mzk5XSBhbmQgdGhpcyB0YXNr IGlzIGFscmVhZHkgaG9sZGluZzoKWyAgMTI0LjMwNjQ2Ml0gICgmKCZicC0+bG9jayktPnJsb2Nr KXstLi0uLi59LCBhdDogWzxmZmZmZmZmZmEwMmE0YTZhPl0gYjQ0X3BvbGwrMHgyOC8weDNlYyBb YjQ0XQpbICAxMjQuMzA2NTY4XSB3aGljaCB3b3VsZCBjcmVhdGUgYSBuZXcgbG9jayBkZXBlbmRl bmN5OgpbICAxMjQuMzA2NjEyXSAgKCYoJmJwLT5sb2NrKS0+cmxvY2spey0uLS4uLn0gLT4gKG5m X2Nvbm50cmFja19sb2NrKXsrLi0uLi59ClsgIDEyNC4zMDY3MjNdClsgIDEyNC4zMDY3MjddIGJ1 dCB0aGlzIG5ldyBkZXBlbmRlbmN5IGNvbm5lY3RzIGEgSEFSRElSUS1pcnEtc2FmZSBsb2NrOgpb ICAxMjQuMzA2NzgyXSAgKCYoJmJwLT5sb2NrKS0+cmxvY2spey0uLS4uLn0KWyAgMTI0LjMwNjc4 Ml0gLi4uIHdoaWNoIGJlY2FtZSBIQVJESVJRLWlycS1zYWZlIGF0OgpbICAxMjQuMzA2NzgyXSAg IFs8ZmZmZmZmZmY4MTA4ZTE3Nj5dIF9fbG9ja19hY3F1aXJlKzB4MmNlLzB4ZDBjClsgIDEyNC4z MDY3ODJdICAgWzxmZmZmZmZmZjgxMDhmMGI3Pl0gbG9ja19hY3F1aXJlKzB4ZjMvMHgxM2UKWyAg MTI0LjMwNjc4Ml0gICBbPGZmZmZmZmZmODE1MDQ0ZWQ+XSBfcmF3X3NwaW5fbG9jaysweDQ1LzB4 NzkKWyAgMTI0LjMwNjc4Ml0gICBbPGZmZmZmZmZmYTAyYTI3MjU+XSBiNDRfaW50ZXJydXB0KzB4 MjUvMHhkOSBbYjQ0XQpbICAxMjQuMzA2NzgyXSAgIFs8ZmZmZmZmZmY4MTBjMjk1OD5dIGhhbmRs ZV9pcnFfZXZlbnRfcGVyY3B1KzB4YjQvMHgyNzEKWyAgMTI0LjMwNjc4Ml0gICBbPGZmZmZmZmZm ODEwYzJiNWM+XSBoYW5kbGVfaXJxX2V2ZW50KzB4NDcvMHg2NwpbICAxMjQuMzA2NzgyXSAgIFs8 ZmZmZmZmZmY4MTBjNGVmMD5dIGhhbmRsZV9mYXN0ZW9pX2lycSsweDhhLzB4YjAKWyAgMTI0LjMw Njc4Ml0gICBbPGZmZmZmZmZmODEyZDk4NmY+XSBfX3hlbl9ldnRjaG5fZG9fdXBjYWxsKzB4MTVl LzB4MjAzClsgIDEyNC4zMDY3ODJdICAgWzxmZmZmZmZmZjgxMmRhZjU0Pl0geGVuX2V2dGNobl9k b191cGNhbGwrMHgyYy8weDNlClsgIDEyNC4zMDY3ODJdICAgWzxmZmZmZmZmZjgxNTBkZmNlPl0g eGVuX2RvX2h5cGVydmlzb3JfY2FsbGJhY2srMHgxZS8weDMwClsgIDEyNC4zMDY3ODJdClsgIDEy NC4zMDY3ODJdIHRvIGEgSEFSRElSUS1pcnEtdW5zYWZlIGxvY2s6ClsgIDEyNC4zMDY3ODJdICAo bmZfY29ubnRyYWNrX2xvY2speysuLS4uLn0KWyAgMTI0LjMwNjc4Ml0gLi4uIHdoaWNoIGJlY2Ft ZSBIQVJESVJRLWlycS11bnNhZmUgYXQ6ClsgIDEyNC4zMDY3ODJdIC4uLiAgWzxmZmZmZmZmZjgx MDhlMWVkPl0gX19sb2NrX2FjcXVpcmUrMHgzNDUvMHhkMGMKWyAgMTI0LjMwNjc4Ml0gICBbPGZm ZmZmZmZmODEwOGYwYjc+XSBsb2NrX2FjcXVpcmUrMHhmMy8weDEzZQpbICAxMjQuMzA2NzgyXSAg IFs8ZmZmZmZmZmY4MTUwNDgzNj5dIF9yYXdfc3Bpbl9sb2NrX2JoKzB4NGEvMHg3ZQpbICAxMjQu MzA2NzgyXSAgIFs8ZmZmZmZmZmZhMDMzZGY0OD5dIG5mX2Nvbm50cmFja19pbisweDQ2MS8weDdk YyBbbmZfY29ubnRyYWNrXQpbICAxMjQuMzA2NzgyXSAgIFs8ZmZmZmZmZmZhMDM1NjVmZj5dIGlw djRfY29ubnRyYWNrX2luKzB4MjEvMHgyMyBbbmZfY29ubnRyYWNrX2lwdjRdClsgIDEyNC4zMDY3 ODJdICAgWzxmZmZmZmZmZjgxNDNjOTZkPl0gbmZfaXRlcmF0ZSsweDRjLzB4OGMKWyAgMTI0LjMw Njc4Ml0gICBbPGZmZmZmZmZmODE0M2NhMjk+XSBuZl9ob29rX3Nsb3crMHg3Yy8weDEyMwpbICAx MjQuMzA2NzgyXSAgIFs8ZmZmZmZmZmY4MTQ0NjIwZj5dIE5GX0hPT0suY29uc3Rwcm9wLjQrMHg0 Ni8weDVhClsgIDEyNC4zMDY3ODJdICAgWzxmZmZmZmZmZjgxNDQ2OGM5Pl0gaXBfcmN2KzB4MjM5 LzB4MjY0ClsgIDEyNC4zMDY3ODJdICAgWzxmZmZmZmZmZjgxNDE1ZGU1Pl0gX19uZXRpZl9yZWNl aXZlX3NrYisweDRhZi8weDUwOApbICAxMjQuMzA2NzgyXSAgIFs8ZmZmZmZmZmY4MTQxNWVjOD5d IHByb2Nlc3NfYmFja2xvZysweDhhLzB4MTUxClsgIDEyNC4zMDY3ODJdICAgWzxmZmZmZmZmZjgx NDE3YmZhPl0gbmV0X3J4X2FjdGlvbisweGFlLzB4MjFjClsgIDEyNC4zMDY3ODJdICAgWzxmZmZm ZmZmZjgxMDYyYjJlPl0gX19kb19zb2Z0aXJxKzB4MTEyLzB4MjVhClsgIDEyNC4zMDY3ODJdICAg WzxmZmZmZmZmZjgxNTBkZjdjPl0gY2FsbF9zb2Z0aXJxKzB4MWMvMHgzMApbICAxMjQuMzA2Nzgy XSAgIFs8ZmZmZmZmZmY4MTAxMGJmZD5dIGRvX3NvZnRpcnErMHg0Yi8weGEyClsgIDEyNC4zMDY3 ODJdICAgWzxmZmZmZmZmZjgxMDYyZWRkPl0gaXJxX2V4aXQrMHg1ZC8weGNmClsgIDEyNC4zMDY3 ODJdICAgWzxmZmZmZmZmZjgxMmRhZjU5Pl0geGVuX2V2dGNobl9kb191cGNhbGwrMHgzMS8weDNl ClsgIDEyNC4zMDY3ODJdICAgWzxmZmZmZmZmZjgxNTBkZmNlPl0geGVuX2RvX2h5cGVydmlzb3Jf Y2FsbGJhY2srMHgxZS8weDMwClsgIDEyNC4zMDY3ODJdClsgIDEyNC4zMDY3ODJdIG90aGVyIGlu Zm8gdGhhdCBtaWdodCBoZWxwIHVzIGRlYnVnIHRoaXM6ClsgIDEyNC4zMDY3ODJdClsgIDEyNC4z MDY3ODJdICBQb3NzaWJsZSBpbnRlcnJ1cHQgdW5zYWZlIGxvY2tpbmcgc2NlbmFyaW86ClsgIDEy NC4zMDY3ODJdClsgIDEyNC4zMDY3ODJdICAgICAgICBDUFUwICAgICAgICAgICAgICAgICAgICBD UFUxClsgIDEyNC4zMDY3ODJdICAgICAgICAtLS0tICAgICAgICAgICAgICAgICAgICAtLS0tClsg IDEyNC4zMDY3ODJdICAgbG9jayhuZl9jb25udHJhY2tfbG9jayk7ClsgIDEyNC4zMDY3ODJdICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICBsb2NhbF9pcnFfZGlzYWJsZSgpOwpbICAxMjQu MzA2NzgyXSAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgbG9jaygmKCZicC0+bG9jaykt PnJsb2NrKTsKWyAgMTI0LjMwNjc4Ml0gICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIGxv Y2sobmZfY29ubnRyYWNrX2xvY2spOwpbICAxMjQuMzA2NzgyXSAgIDxJbnRlcnJ1cHQ+ClsgIDEy NC4zMDY3ODJdICAgICBsb2NrKCYoJmJwLT5sb2NrKS0+cmxvY2spOwpbICAxMjQuMzA2NzgyXQpb ICAxMjQuMzA2NzgyXSAgKioqIERFQURMT0NLICoqKgpbICAxMjQuMzA2NzgyXQpbICAxMjQuMzA2 NzgyXSAgIzA6ICAoJigmYnAtPmxvY2spLT5ybG9jayl7LS4tLi4ufSwgYXQ6IFs8ZmZmZmZmZmZh MDJhNGE2YT5dIGI0NF9wb2xsKzB4MjgvMHgzZWMgW2I0NF0KWyAgMTI0LjMwNjc4Ml0gICMxOiAg KHJjdV9yZWFkX2xvY2spey4rLisuLn0sIGF0OiBbPGZmZmZmZmZmODE0M2M1NDg+XSByY3VfcmVh ZF9sb2NrKzB4MC8weDQ0ClsgIDEyNC4zMDY3ODJdClsgIDEyNC4zMDY3ODJdIHRoZSBkZXBlbmRl bmNpZXMgYmV0d2VlbiBIQVJESVJRLWlycS1zYWZlIGxvY2sgYW5kIHRoZSBob2xkaW5nIGxvY2s6 ClsgIDEyNC4zMDY3ODJdIC0+ICgmKCZicC0+bG9jayktPnJsb2NrKXstLi0uLi59IG9wczogNzQx IHsKWyAgMTI0LjMwNjc4Ml0gICAgSU4tSEFSRElSUS1XIGF0OgpbICAxMjQuMzA2NzgyXSAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICBbPGZmZmZmZmZmODEwOGUxNzY+XSBf X2xvY2tfYWNxdWlyZSsweDJjZS8weGQwYwpbICAxMjQuMzA2NzgyXSAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICBbPGZmZmZmZmZmODEwOGYwYjc+XSBsb2NrX2FjcXVpcmUr MHhmMy8weDEzZQpbICAxMjQuMzA2NzgyXSAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICBbPGZmZmZmZmZmODE1MDQ0ZWQ+XSBfcmF3X3NwaW5fbG9jaysweDQ1LzB4NzkKWyAg MTI0LjMwNjc4Ml0gICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgWzxmZmZm ZmZmZmEwMmEyNzI1Pl0gYjQ0X2ludGVycnVwdCsweDI1LzB4ZDkgW2I0NF0KWyAgMTI0LjMwNjc4 Ml0gICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgWzxmZmZmZmZmZjgxMGMy OTU4Pl0gaGFuZGxlX2lycV9ldmVudF9wZXJjcHUrMHhiNC8weDI3MQpbICAxMjQuMzA2NzgyXSAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICBbPGZmZmZmZmZmODEwYzJiNWM+ XSBoYW5kbGVfaXJxX2V2ZW50KzB4NDcvMHg2NwpbICAxMjQuMzA2NzgyXSAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICBbPGZmZmZmZmZmODEwYzRlZjA+XSBoYW5kbGVfZmFz dGVvaV9pcnErMHg4YS8weGIwClsgIDEyNC4zMDY3ODJdICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgIFs8ZmZmZmZmZmY4MTJkOTg2Zj5dIF9feGVuX2V2dGNobl9kb191cGNh bGwrMHgxNWUvMHgyMDMKWyAgMTI0LjMwNjc4Ml0gICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgWzxmZmZmZmZmZjgxMmRhZjU0Pl0geGVuX2V2dGNobl9kb191cGNhbGwrMHgy Yy8weDNlClsgIDEyNC4zMDY3ODJdICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgIFs8ZmZmZmZmZmY4MTUwZGZjZT5dIHhlbl9kb19oeXBlcnZpc29yX2NhbGxiYWNrKzB4MWUv MHgzMApbICAxMjQuMzA2NzgyXSAgICBJTi1TT0ZUSVJRLVcgYXQ6ClsgIDEyNC4zMDY3ODJdICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIFs8ZmZmZmZmZmY4MTA4ZTE5ZD5d IF9fbG9ja19hY3F1aXJlKzB4MmY1LzB4ZDBjClsgIDEyNC4zMDY3ODJdICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgIFs8ZmZmZmZmZmY4MTA4ZjBiNz5dIGxvY2tfYWNxdWly ZSsweGYzLzB4MTNlClsgIDEyNC4zMDY3ODJdICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgIFs8ZmZmZmZmZmY4MTUwNDYwMj5dIF9yYXdfc3Bpbl9sb2NrX2lycSsweDRmLzB4 ODIKWyAgMTI0LjMwNjc4Ml0gICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg WzxmZmZmZmZmZmEwMmEzOGEyPl0gYjQ0X3RpbWVyKzB4MTMvMHg1MSBbYjQ0XQpbICAxMjQuMzA2 NzgyXSAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICBbPGZmZmZmZmZmODEw NmE4M2M+XSBydW5fdGltZXJfc29mdGlycSsweDIxOC8weDM3MgpbICAxMjQuMzA2NzgyXSAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICBbPGZmZmZmZmZmODEwNjJiMmU+XSBf X2RvX3NvZnRpcnErMHgxMTIvMHgyNWEKWyAgMTI0LjMwNjc4Ml0gICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgWzxmZmZmZmZmZjgxNTBkZjdjPl0gY2FsbF9zb2Z0aXJxKzB4 MWMvMHgzMApbICAxMjQuMzA2NzgyXSAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICBbPGZmZmZmZmZmODEwMTBiZmQ+XSBkb19zb2Z0aXJxKzB4NGIvMHhhMgpbICAxMjQuMzA2 NzgyXSAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICBbPGZmZmZmZmZmODEw NjJlZGQ+XSBpcnFfZXhpdCsweDVkLzB4Y2YKWyAgMTI0LjMwNjc4Ml0gICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgWzxmZmZmZmZmZjgxMmRhZjU5Pl0geGVuX2V2dGNobl9k b191cGNhbGwrMHgzMS8weDNlClsgIDEyNC4zMDY3ODJdICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgIFs8ZmZmZmZmZmY4MTUwZGZjZT5dIHhlbl9kb19oeXBlcnZpc29yX2Nh bGxiYWNrKzB4MWUvMHgzMApbICAxMjQuMzA2NzgyXSAgICBJTklUSUFMIFVTRSBhdDoKWyAgMTI0 LjMwNjc4Ml0gICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICBbPGZmZmZmZmZm ODEwOGUyNjI+XSBfX2xvY2tfYWNxdWlyZSsweDNiYS8weGQwYwpbICAxMjQuMzA2NzgyXSAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIFs8ZmZmZmZmZmY4MTA4ZjBiNz5dIGxv Y2tfYWNxdWlyZSsweGYzLzB4MTNlClsgIDEyNC4zMDY3ODJdICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgWzxmZmZmZmZmZjgxNTA0NjAyPl0gX3Jhd19zcGluX2xvY2tfaXJx KzB4NGYvMHg4Mgp0X21hY19hZGRyKzB4NWEvMHg4MiBbYjQ0XQpbICAxMjQuMzA2NzgyXSAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIFs8ZmZmZmZmZmY4MTQxNDg3ZD5dIGRl dl9zZXRfbWFjX2FkZHJlc3MrMHgzZS8weDU4ClsgIDEyNC4zMDY3ODJdICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgWzxmZmZmZmZmZmEwNGE1OTg1Pl0gYm9uZF9lbnNsYXZl KzB4M2U2LzB4YTQ4IFtib25kaW5nXQpbICAxMjQuMzA2NzgyXSAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgIFs8ZmZmZmZmZmZhMDRhYzQ1OD5dIGJvbmRpbmdfc3RvcmVfc2xh dmVzKzB4MTA2LzB4MTc0IFtib25kaW5nXQpbICAxMjQuMzA2NzgyXSAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgIFs8ZmZmZmZmZmY4MTMxMzhiMD5dIGRldl9hdHRyX3N0b3Jl KzB4MjAvMHgyMgpbICAxMjQuMzA2NzgyXSAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgIFs8ZmZmZmZmZmY4MTFhMGQ1ZD5dIHN5c2ZzX3dyaXRlX2ZpbGUrMHgxMDgvMHgxNDQK WyAgMTI0LjMwNjc4Ml0gICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICBbPGZm ZmZmZmZmODExNDJiZGE+XSB2ZnNfd3JpdGUrMHhhZi8weGY2ClsgIDEyNC4zMDY3ODJdICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgWzxmZmZmZmZmZjgxMTQyZGQ1Pl0gc3lz X3dyaXRlKzB4NGQvMHg3NApbICAxMjQuMzA2NzgyXSAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgIFs8ZmZmZmZmZmY4MTUwYmM4Mj5dIHN5c3RlbV9jYWxsX2Zhc3RwYXRoKzB4 MTYvMHgxYgpbICAxMjQuMzA2NzgyXSAgfQpbICAxMjQuMzA2NzgyXSAgLi4uIGtleSAgICAgIGF0 OiBbPGZmZmZmZmZmYTAyYTg0NDg+XSBfX2tleS4zNzAzNCsweDAvMHhmZmZmZmZmZmZmZmZkYmI4 IFtiNDRdClsgIDEyNC4zMDY3ODJdICAuLi4gYWNxdWlyZWQgYXQ6ClsgIDEyNC4zMDY3ODJdICAg IFs8ZmZmZmZmZmY4MTA4ZGI3Yz5dIGNoZWNrX2lycV91c2FnZSsweDQyLzB4ODgKWyAgMTI0LjMw Njc4Ml0gICAgWzxmZmZmZmZmZjgxMDhlOGZhPl0gX19sb2NrX2FjcXVpcmUrMHhhNTIvMHhkMGMK WyAgMTI0LjMwNjc4Ml0gICAgWzxmZmZmZmZmZjgxMDhmMGI3Pl0gbG9ja19hY3F1aXJlKzB4ZjMv MHgxM2UKWyAgMTI0LjMwNjc4Ml0gICAgWzxmZmZmZmZmZjgxNTA0ODM2Pl0gX3Jhd19zcGluX2xv Y2tfYmgrMHg0YS8weDdlClsgIDEyNC4zMDY3ODJdICAgIFs8ZmZmZmZmZmZhMDMzYzdiNz5dIGRl c3Ryb3lfY29ubnRyYWNrKzB4NzAvMHhlYyBbbmZfY29ubnRyYWNrXQpbICAxMjQuMzA2NzgyXSAg ICBbPGZmZmZmZmZmODE0M2M4NGM+XSBuZl9jb25udHJhY2tfZGVzdHJveSsweDVhLzB4NjQKWyAg MTI0LjMwNjc4Ml0gICAgWzxmZmZmZmZmZjgxNDBkODdkPl0gc2tiX3JlbGVhc2VfaGVhZF9zdGF0 ZSsweGE3LzB4ZWYKWyAgMTI0LjMwNjc4Ml0gICAgWzxmZmZmZmZmZjgxNDBkNTIwPl0gX19rZnJl ZV9za2IrMHgxMy8weDgzClsgIDEyNC4zMDY3ODJdICAgIFs8ZmZmZmZmZmY4MTQwZDYzNT5dIGNv bnN1bWVfc2tiKzB4YTUvMHhkMQpbICAxMjQuMzA2NzgyXSAgICBbPGZmZmZmZmZmYTAyYTRhZjE+ XSBiNDRfcG9sbCsweGFmLzB4M2VjIFtiNDRdClsgIDEyNC4zMDY3ODJdICAgIFs8ZmZmZmZmZmY4 MTQxN2JmYT5dIG5ldF9yeF9hY3Rpb24rMHhhZS8weDIxYwpbICAxMjQuMzA2NzgyXSAgICBbPGZm ZmZmZmZmODEwNjJiMmU+XSBfX2RvX3NvZnRpcnErMHgxMTIvMHgyNWEKWyAgMTI0LjMwNjc4Ml0g ICAgWzxmZmZmZmZmZjgxNTBkZjdjPl0gY2FsbF9zb2Z0aXJxKzB4MWMvMHgzMApbICAxMjQuMzA2 NzgyXSAgICBbPGZmZmZmZmZmODEwMTBiZmQ+XSBkb19zb2Z0aXJxKzB4NGIvMHhhMgpbICAxMjQu MzA2NzgyXSAgICBbPGZmZmZmZmZmODEwNjJlZGQ+XSBpcnFfZXhpdCsweDVkLzB4Y2YKWyAgMTI0 LjMwNjc4Ml0gICAgWzxmZmZmZmZmZjgxMmRhZjU5Pl0geGVuX2V2dGNobl9kb191cGNhbGwrMHgz MS8weDNlClsgIDEyNC4zMDY3ODJdICAgIFs8ZmZmZmZmZmY4MTUwZGZjZT5dIHhlbl9kb19oeXBl cnZpc29yX2NhbGxiYWNrKzB4MWUvMHgzMApbICAxMjQuMzA2NzgyXQpbICAxMjQuMzA2NzgyXQpb ICAxMjQuMzA2NzgyXSB0aGUgZGVwZW5kZW5jaWVzIGJldHdlZW4gdGhlIGxvY2sgdG8gYmUgYWNx dWlyZWQgYW5kIEhBUkRJUlEtaXJxLXVuc2FmZSBsb2NrOgpbICAxMjQuMzE0ODE5XSAtPiAobmZf Y29ubnRyYWNrX2xvY2speysuLS4uLn0gb3BzOiA1MiB7ClsgIDEyNC4zMTQ4MTldICAgIEhBUkRJ UlEtT04tVyBhdDoKWyAgMTI0LjMxNDgxOV0gICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgWzxmZmZmZmZmZjgxMDhlMWVkPl0gX19sb2NrX2FjcXVpcmUrMHgzNDUvMHhkMGMK WyAgMTI0LjMxNDgxOV0gICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgWzxm ZmZmZmZmZjgxMDhmMGI3Pl0gbG9ja19hY3F1aXJlKzB4ZjMvMHgxM2UKWyAgMTI0LjMxNDgxOV0g ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgWzxmZmZmZmZmZjgxNTA0ODM2 Pl0gX3Jhd19zcGluX2xvY2tfYmgrMHg0YS8weDdlClsgIDEyNC4zMTQ4MTldICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgIFs8ZmZmZmZmZmZhMDMzZGY0OD5dIG5mX2Nvbm50 cmFja19pbisweDQ2MS8weDdkYyBbbmZfY29ubnRyYWNrXQpbICAxMjQuMzE0ODE5XSAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICBbPGZmZmZmZmZmYTAzNTY1ZmY+XSBpcHY0 X2Nvbm50cmFja19pbisweDIxLzB4MjMgW25mX2Nvbm50cmFja19pcHY0XQpbICAxMjQuMzE0ODE5 XSAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICBbPGZmZmZmZmZmODE0M2M5 NmQ+XSBuZl9pdGVyYXRlKzB4NGMvMHg4YwpbICAxMjQuMzE0ODE5XSAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICBbPGZmZmZmZmZmODE0M2NhMjk+XSBuZl9ob29rX3Nsb3cr MHg3Yy8weDEyMwpPSy5jb25zdHByb3AuNCsweDQ2LzB4NWEKWyAgMTI0LjMxNDgxOV0gICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgWzxmZmZmZmZmZjgxNDQ2OGM5Pl0gaXBf cmN2KzB4MjM5LzB4MjY0ClsgIDEyNC4zMTQ4MTldICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgIFs8ZmZmZmZmZmY4MTQxNWRlNT5dIF9fbmV0aWZfcmVjZWl2ZV9za2IrMHg0 YWYvMHg1MDgKWyAgMTI0LjMxNDgxOV0gICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgWzxmZmZmZmZmZjgxNDE1ZWM4Pl0gcHJvY2Vzc19iYWNrbG9nKzB4OGEvMHgxNTEKWyAg MTI0LjMxNDgxOV0gICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgWzxmZmZm ZmZmZjgxNDE3YmZhPl0gbmV0X3J4X2FjdGlvbisweGFlLzB4MjFjClsgIDEyNC4zMTQ4MTldICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIFs8ZmZmZmZmZmY4MTA2MmIyZT5d IF9fZG9fc29mdGlycSsweDExMi8weDI1YQpbICAxMjQuMzE0ODE5XSAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICBbPGZmZmZmZmZmODE1MGRmN2M+XSBjYWxsX3NvZnRpcnEr MHgxYy8weDMwClsgIDEyNC4zMTQ4MTldICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgIFs8ZmZmZmZmZmY4MTAxMGJmZD5dIGRvX3NvZnRpcnErMHg0Yi8weGEyClsgIDEyNC4z MTQ4MTldICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIFs8ZmZmZmZmZmY4 MTA2MmVkZD5dIGlycV9leGl0KzB4NWQvMHhjZgpbICAxMjQuMzE0ODE5XSAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICBbPGZmZmZmZmZmODEyZGFmNTk+XSB4ZW5fZXZ0Y2hu X2RvX3VwY2FsbCsweDMxLzB4M2UKWyAgMTI0LjMxNDgxOV0gICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgWzxmZmZmZmZmZjgxNTBkZmNlPl0geGVuX2RvX2h5cGVydmlzb3Jf Y2FsbGJhY2srMHgxZS8weDMwClsgIDEyNC4zMTQ4MTldICAgIElOLVNPRlRJUlEtVyBhdDoKWyAg MTI0LjMxNDgxOV0gICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgWzxmZmZm ZmZmZjgxMDhlMTlkPl0gX19sb2NrX2FjcXVpcmUrMHgyZjUvMHhkMGMKWyAgMTI0LjMxNDgxOV0g ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgWzxmZmZmZmZmZjgxMDhmMGI3 Pl0gbG9ja19hY3F1aXJlKzB4ZjMvMHgxM2UKWyAgMTI0LjMxNDgxOV0gICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgWzxmZmZmZmZmZjgxNTA0ODM2Pl0gX3Jhd19zcGluX2xv Y2tfYmgrMHg0YS8weDdlClsgIDEyNC4zMTQ4MTldICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgIFs8ZmZmZmZmZmZhMDMzZGY0OD5dIG5mX2Nvbm50cmFja19pbisweDQ2MS8w eDdkYyBbbmZfY29ubnRyYWNrXQpbICAxMjQuMzE0ODE5XSAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICBbPGZmZmZmZmZmYTAzNTY1ZmY+XSBpcHY0X2Nvbm50cmFja19pbisw eDIxLzB4MjMgW25mX2Nvbm50cmFja19pcHY0XQpbICAxMjQuMzE0ODE5XSAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICBbPGZmZmZmZmZmODE0M2M5NmQ+XSBuZl9pdGVyYXRl KzB4NGMvMHg4YwpbICAxMjQuMzE0ODE5XSAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICBbPGZmZmZmZmZmODE0M2NhMjk+XSBuZl9ob29rX3Nsb3crMHg3Yy8weDEyMwpbICAx MjQuMzE0ODE5XSAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICBbPGZmZmZm ZmZmODE0NDYyMGY+XSBORl9IT09LLmNvbnN0cHJvcC40KzB4NDYvMHg1YQpbICAxMjQuMzE0ODE5 XSAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICBbPGZmZmZmZmZmODE0NDY4 Yzk+XSBpcF9yY3YrMHgyMzkvMHgyNjQKWyAgMTI0LjMxNDgxOV0gICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgWzxmZmZmZmZmZjgxNDE1ZGU1Pl0gX19uZXRpZl9yZWNlaXZl X3NrYisweDRhZi8weDUwOApbICAxMjQuMzE0ODE5XSAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICBbPGZmZmZmZmZmODE0MTVlYzg+XSBwcm9jZXNzX2JhY2tsb2crMHg4YS8w eDE1MQpbICAxMjQuMzE0ODE5XSAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICBbPGZmZmZmZmZmODE0MTdiZmE+XSBuZXRfcnhfYWN0aW9uKzB4YWUvMHgyMWMKWyAgMTI0LjMx NDgxOV0gICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgWzxmZmZmZmZmZjgx MDYyYjJlPl0gX19kb19zb2Z0aXJxKzB4MTEyLzB4MjVhClsgIDEyNC4zMTQ4MTldICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIFs8ZmZmZmZmZmY4MTUwZGY3Yz5dIGNhbGxf c29mdGlycSsweDFjLzB4MzAKWyAgMTI0LjMxNDgxOV0gICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgWzxmZmZmZmZmZjgxMDEwYmZkPl0gZG9fc29mdGlycSsweDRiLzB4YTIK WyAgMTI0LjMxNDgxOV0gICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgWzxm ZmZmZmZmZjgxMDYyZWRkPl0gaXJxX2V4aXQrMHg1ZC8weGNmClsgIDEyNC4zMTQ4MTldICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIFs8ZmZmZmZmZmY4MTJkYWY1OT5dIHhl bl9ldnRjaG5fZG9fdXBjYWxsKzB4MzEvMHgzZQpbICAxMjQuMzE0ODE5XSAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICBbPGZmZmZmZmZmODE1MGRmY2U+XSB4ZW5fZG9faHlw ZXJ2aXNvcl9jYWxsYmFjaysweDFlLzB4MzAKWyAgMTI0LjMxNDgxOV0gICAgSU5JVElBTCBVU0Ug YXQ6Cl9hY3F1aXJlKzB4M2JhLzB4ZDBjClsgIDEyNC4zMTQ4MTldICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgWzxmZmZmZmZmZjgxMDhmMGI3Pl0gbG9ja19hY3F1aXJlKzB4 ZjMvMHgxM2UKWyAgMTI0LjMxNDgxOV0gICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICBbPGZmZmZmZmZmODE1MDQ4MzY+XSBfcmF3X3NwaW5fbG9ja19iaCsweDRhLzB4N2UKWyAg MTI0LjMxNDgxOV0gICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICBbPGZmZmZm ZmZmYTAzM2RmNDg+XSBuZl9jb25udHJhY2tfaW4rMHg0NjEvMHg3ZGMgW25mX2Nvbm50cmFja10K WyAgMTI0LjMxNDgxOV0gICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICBbPGZm ZmZmZmZmYTAzNTY1ZmY+XSBpcHY0X2Nvbm50cmFja19pbisweDIxLzB4MjMgW25mX2Nvbm50cmFj a19pcHY0XQpbICAxMjQuMzE0ODE5XSAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgIFs8ZmZmZmZmZmY4MTQzYzk2ZD5dIG5mX2l0ZXJhdGUrMHg0Yy8weDhjClsgIDEyNC4zMTQ4 MTldICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgWzxmZmZmZmZmZjgxNDNj YTI5Pl0gbmZfaG9va19zbG93KzB4N2MvMHgxMjMKWyAgMTI0LjMxNDgxOV0gICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICBbPGZmZmZmZmZmODE0NDYyMGY+XSBORl9IT09LLmNv bnN0cHJvcC40KzB4NDYvMHg1YQpbICAxMjQuMzE0ODE5XSAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgIFs8ZmZmZmZmZmY4MTQ0NjhjOT5dIGlwX3JjdisweDIzOS8weDI2NApb ICAxMjQuMzE0ODE5XSAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIFs8ZmZm ZmZmZmY4MTQxNWRlNT5dIF9fbmV0aWZfcmVjZWl2ZV9za2IrMHg0YWYvMHg1MDgKWyAgMTI0LjMx NDgxOV0gICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICBbPGZmZmZmZmZmODE0 MTVlYzg+XSBwcm9jZXNzX2JhY2tsb2crMHg4YS8weDE1MQpbICAxMjQuMzE0ODE5XSAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIFs8ZmZmZmZmZmY4MTQxN2JmYT5dIG5ldF9y eF9hY3Rpb24rMHhhZS8weDIxYwpbICAxMjQuMzE0ODE5XSAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgIFs8ZmZmZmZmZmY4MTA2MmIyZT5dIF9fZG9fc29mdGlycSsweDExMi8w eDI1YQpbICAxMjQuMzE0ODE5XSAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg IFs8ZmZmZmZmZmY4MTUwZGY3Yz5dIGNhbGxfc29mdGlycSsweDFjLzB4MzAKWyAgMTI0LjMxNDgx OV0gICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICBbPGZmZmZmZmZmODEwMTBi ZmQ+XSBkb19zb2Z0aXJxKzB4NGIvMHhhMgpbICAxMjQuMzE0ODE5XSAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgIFs8ZmZmZmZmZmY4MTA2MmVkZD5dIGlycV9leGl0KzB4NWQv MHhjZgpbICAxMjQuMzE0ODE5XSAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg IFs8ZmZmZmZmZmY4MTJkYWY1OT5dIHhlbl9ldnRjaG5fZG9fdXBjYWxsKzB4MzEvMHgzZQpbICAx MjQuMzE0ODE5XSAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIFs8ZmZmZmZm ZmY4MTUwZGZjZT5dIHhlbl9kb19oeXBlcnZpc29yX2NhbGxiYWNrKzB4MWUvMHgzMApbICAxMjQu MzE0ODE5XSAgfQpbICAxMjQuMzE0ODE5XSAgLi4uIGtleSAgICAgIGF0OiBbPGZmZmZmZmZmYTAz NDgwMTg+XSBuZl9jb25udHJhY2tfbG9jaysweDE4LzB4ZmZmZmZmZmZmZmZmZDAwMCBbbmZfY29u bnRyYWNrXQpbICAxMjQuMzE0ODE5XSAgLi4uIGFjcXVpcmVkIGF0OgpbICAxMjQuMzE0ODE5XSAg ICBbPGZmZmZmZmZmODEwOGRiN2M+XSBjaGVja19pcnFfdXNhZ2UrMHg0Mi8weDg4ClsgIDEyNC4z MTQ4MTldICAgIFs8ZmZmZmZmZmY4MTA4ZThmYT5dIF9fbG9ja19hY3F1aXJlKzB4YTUyLzB4ZDBj ClsgIDEyNC4zMTQ4MTldICAgIFs8ZmZmZmZmZmY4MTA4ZjBiNz5dIGxvY2tfYWNxdWlyZSsweGYz LzB4MTNlClsgIDEyNC4zMTQ4MTldICAgIFs8ZmZmZmZmZmY4MTUwNDgzNj5dIF9yYXdfc3Bpbl9s b2NrX2JoKzB4NGEvMHg3ZQpbICAxMjQuMzE0ODE5XSAgICBbPGZmZmZmZmZmYTAzM2M3Yjc+XSBk ZXN0cm95X2Nvbm50cmFjaysweDcwLzB4ZWMgW25mX2Nvbm50cmFja10KWyAgMTI0LjMxNDgxOV0g ICAgWzxmZmZmZmZmZjgxNDNjODRjPl0gbmZfY29ubnRyYWNrX2Rlc3Ryb3krMHg1YS8weDY0Clsg IDEyNC4zMTQ4MTldICAgIFs8ZmZmZmZmZmY4MTQwZDg3ZD5dIHNrYl9yZWxlYXNlX2hlYWRfc3Rh dGUrMHhhNy8weGVmClsgIDEyNC4zMTQ4MTldICAgIFs8ZmZmZmZmZmY4MTQwZDUyMD5dIF9fa2Zy ZWVfc2tiKzB4MTMvMHg4MwpbICAxMjQuMzE0ODE5XSAgICBbPGZmZmZmZmZmODE0MGQ2MzU+XSBj b25zdW1lX3NrYisweGE1LzB4ZDEKWyAgMTI0LjMxNDgxOV0gICAgWzxmZmZmZmZmZmEwMmE0YWYx Pl0gYjQ0X3BvbGwrMHhhZi8weDNlYyBbYjQ0XQpbICAxMjQuMzE0ODE5XSAgICBbPGZmZmZmZmZm ODE0MTdiZmE+XSBuZXRfcnhfYWN0aW9uKzB4YWUvMHgyMWMKWyAgMTI0LjMxNDgxOV0gICAgWzxm ZmZmZmZmZjgxMDYyYjJlPl0gX19kb19zb2Z0aXJxKzB4MTEyLzB4MjVhClsgIDEyNC4zMTQ4MTld ICAgIFs8ZmZmZmZmZmY4MTUwZGY3Yz5dIGNhbGxfc29mdGlycSsweDFjLzB4MzAKWyAgMTI0LjMx NDgxOV0gICAgWzxmZmZmZmZmZjgxMDEwYmZkPl0gZG9fc29mdGlycSsweDRiLzB4YTIKWyAgMTI0 LjMxNDgxOV0gICAgWzxmZmZmZmZmZjgxMDYyZWRkPl0gaXJxX2V4aXQrMHg1ZC8weGNmClsgIDEy NC4zMTQ4MTldICAgIFs8ZmZmZmZmZmY4MTJkYWY1OT5dIHhlbl9ldnRjaG5fZG9fdXBjYWxsKzB4 MzEvMHgzZQpbICAxMjQuMzE0ODE5XSAgICBbPGZmZmZmZmZmODE1MGRmY2U+XSB4ZW5fZG9faHlw ZXJ2aXNvcl9jYWxsYmFjaysweDFlLzB4MzAKWyAgMTI0LjMxNDgxOV0KWyAgMTI0LjMxNDgxOV0K WyAgMTI0LjMxNDgxOV0gUGlkOiAwLCBjb21tOiBzd2FwcGVyIE5vdCB0YWludGVkIDMuMS4wLTAu cmM2LmdpdDAuMC5mYzE3Lng4Nl82NCAjMQpbICAxMjQuMzE0ODE5XSBDYWxsIFRyYWNlOgpbICAx MjQuMzE0ODE5XSAgPElSUT4gIFs8ZmZmZmZmZmY4MTA4ZGIyNT5dIGNoZWNrX3VzYWdlKzB4Mzdm LzB4Mzk0ClsgIDEyNC4zMTQ4MTldICBbPGZmZmZmZmZmODEwMDdkNzI+XSA/IGNoZWNrX2V2ZW50 cysweDEyLzB4MjAKWyAgMTI0LjMxNDgxOV0gIFs8ZmZmZmZmZmY4MTA4ZGI3Yz5dIGNoZWNrX2ly cV91c2FnZSsweDQyLzB4ODgKWyAgMTI0LjMxNDgxOV0gIFs8ZmZmZmZmZmY4MTA4ZThmYT5dIF9f bG9ja19hY3F1aXJlKzB4YTUyLzB4ZDBjClsgIDEyNC4zMTQ4MTldICBbPGZmZmZmZmZmYTAzM2M0 NWQ+XSA/IHJjdV9yZWFkX2xvY2srMHg0NC8weDQ0IFtuZl9jb25udHJhY2tdClsgIDEyNC4zMTQ4 MTldICBbPGZmZmZmZmZmODEwMDc3NDY+XSA/IHhlbl9mb3JjZV9ldnRjaG5fY2FsbGJhY2srMHhk LzB4ZgpbICAxMjQuMzE0ODE5XSAgWzxmZmZmZmZmZjgxMDA3ZDcyPl0gPyBjaGVja19ldmVudHMr MHgxMi8weDIwClsgIDEyNC4zMTQ4MTldICBbPGZmZmZmZmZmODEwMDc3NDY+XSA/IHhlbl9mb3Jj ZV9ldnRjaG5fY2FsbGJhY2srMHhkLzB4ZgpbICAxMjQuMzE0ODE5XSAgWzxmZmZmZmZmZmEwMzNj N2I3Pl0gPyBkZXN0cm95X2Nvbm50cmFjaysweDcwLzB4ZWMgW25mX2Nvbm50cmFja10KWyAgMTI0 LjMxNDgxOV0gIFs8ZmZmZmZmZmY4MTA4ZjBiNz5dIGxvY2tfYWNxdWlyZSsweGYzLzB4MTNlClsg IDEyNC4zMTQ4MTldICBbPGZmZmZmZmZmYTAzM2M3Yjc+XSA/IGRlc3Ryb3lfY29ubnRyYWNrKzB4 NzAvMHhlYyBbbmZfY29ubnRyYWNrXQpbICAxMjQuMzE0ODE5XSAgWzxmZmZmZmZmZjgxMDA3ZDVm Pl0gPyB4ZW5fcmVzdG9yZV9mbF9kaXJlY3RfcmVsb2MrMHg0LzB4NApbICAxMjQuMzE0ODE5XSAg WzxmZmZmZmZmZjgxNTA0ODM2Pl0gX3Jhd19zcGluX2xvY2tfYmgrMHg0YS8weDdlClsgIDEyNC4z MTQ4MTldICBbPGZmZmZmZmZmYTAzM2M3Yjc+XSA/IGRlc3Ryb3lfY29ubnRyYWNrKzB4NzAvMHhl YyBbbmZfY29ubnRyYWNrXQpbICAxMjQuMzE0ODE5XSAgWzxmZmZmZmZmZmEwMzNjN2I3Pl0gZGVz dHJveV9jb25udHJhY2srMHg3MC8weGVjIFtuZl9jb25udHJhY2tdClsgIDEyNC4zMTQ4MTldICBb PGZmZmZmZmZmYTAzM2M3NDc+XSA/IG5mX2Nvbm50cmFja19mcmVlKzB4NTgvMHg1OCBbbmZfY29u bnRyYWNrXQpbICAxMjQuMzE0ODE5XSAgWzxmZmZmZmZmZjgxNDNjODRjPl0gbmZfY29ubnRyYWNr X2Rlc3Ryb3krMHg1YS8weDY0ClsgIDEyNC4zMTQ4MTldICBbPGZmZmZmZmZmODE0MGQ4N2Q+XSBz a2JfcmVsZWFzZV9oZWFkX3N0YXRlKzB4YTcvMHhlZgpbICAxMjQuMzE0ODE5XSAgWzxmZmZmZmZm ZjgxNDBkNTIwPl0gX19rZnJlZV9za2IrMHgxMy8weDgzClsgIDEyNC4zMTQ4MTldICBbPGZmZmZm ZmZmODE0MGQ2MzU+XSBjb25zdW1lX3NrYisweGE1LzB4ZDEKWyAgMTI0LjMxNDgxOV0gIFs8ZmZm ZmZmZmZhMDJhNGFmMT5dIGI0NF9wb2xsKzB4YWYvMHgzZWMgW2I0NF0KWyAgMTI0LjMxNDgxOV0g IFs8ZmZmZmZmZmY4MTQxN2JmYT5dIG5ldF9yeF9hY3Rpb24rMHhhZS8weDIxYwpbICAxMjQuMzE0 ODE5XSAgWzxmZmZmZmZmZjgxMDYyYTlhPl0gPyBfX2RvX3NvZnRpcnErMHg3ZS8weDI1YQpbICAx MjQuMzE0ODE5XSAgWzxmZmZmZmZmZjgxMDYyYjJlPl0gX19kb19zb2Z0aXJxKzB4MTEyLzB4MjVh ClsgIDEyNC4zMTQ4MTldICBbPGZmZmZmZmZmODE1MGRmN2M+XSBjYWxsX3NvZnRpcnErMHgxYy8w eDMwClsgIDEyNC4zMTQ4MTldICBbPGZmZmZmZmZmODEwMTBiZmQ+XSBkb19zb2Z0aXJxKzB4NGIv MHhhMgpbICAxMjQuMzE0ODE5XSAgWzxmZmZmZmZmZjgxMDYyZWRkPl0gaXJxX2V4aXQrMHg1ZC8w eGNmClsgIDEyNC4zMTQ4MTldICBbPGZmZmZmZmZmODEyZGFmNTk+XSB4ZW5fZXZ0Y2huX2RvX3Vw Y2FsbCsweDMxLzB4M2UKWyAgMTI0LjMxNDgxOV0gIFs8ZmZmZmZmZmY4MTUwZGZjZT5dIHhlbl9k b19oeXBlcnZpc29yX2NhbGxiYWNrKzB4MWUvMHgzMApbICAxMjQuMzE0ODE5XSAgPEVPST4gIFs8 ZmZmZmZmZmY4MTAwMTNhYT5dID8gaHlwZXJjYWxsX3BhZ2UrMHgzYWEvMHgxMDAwClsgIDEyNC4z MTQ4MTldICBbPGZmZmZmZmZmODEwMDEzYWE+XSA/IGh5cGVyY2FsbF9wYWdlKzB4M2FhLzB4MTAw MApbICAxMjQuMzE0ODE5XSAgWzxmZmZmZmZmZjgxMDA3NzAxPl0gPyB4ZW5fc2FmZV9oYWx0KzB4 MTAvMHgxOApbICAxMjQuMzE0ODE5XSAgWzxmZmZmZmZmZjgxMDE2MDFlPl0gPyBkZWZhdWx0X2lk bGUrMHg1My8weDkwClsgIDEyNC4zMTQ4MTldICBbPGZmZmZmZmZmODEwMGUyZjk+XSA/IGNwdV9p ZGxlKzB4YjUvMHgxMDEKWyAgMTI0LjMxNDgxOV0gIFs8ZmZmZmZmZmY4MTRlMDMwOD5dID8gcmVz dF9pbml0KzB4ZGMvMHhlMwpbICAxMjQuMzE0ODE5XSAgWzxmZmZmZmZmZjgxNGUwMjJjPl0gPyBj c3VtX3BhcnRpYWxfY29weV9nZW5lcmljKzB4MTZjLzB4MTZjClsgIDEyNC4zMTQ4MTldICBbPGZm ZmZmZmZmODFkNTNiOWY+XSA/IHN0YXJ0X2tlcm5lbCsweDNkZC8weDNlYQpbICAxMjQuMzE0ODE5 XSAgWzxmZmZmZmZmZjgxZDUzMmM0Pl0gPyB4ODZfNjRfc3RhcnRfcmVzZXJ2YXRpb25zKzB4YWYv MHhiMwpbICAxMjQuMzE0ODE5XSAgWzxmZmZmZmZmZjgxZDU1ZjE4Pl0gPyB4ZW5fc3RhcnRfa2Vy bmVsKzB4NTg4LzB4NThmClsgIDEyNC4zMTQ4MTldIC0tLS0tLS0tLS0tLVsgY3V0IGhlcmUgXS0t LS0tLS0tLS0tLQpbICAxMjQuMzE0ODE5XSBXQVJOSU5HOiBhdCBrZXJuZWwvc29mdGlycS5jOjE1 OSBfbG9jYWxfYmhfZW5hYmxlX2lwKzB4NDkvMHhjZSgpClsgIDEyNC4zMTQ4MTldIEhhcmR3YXJl IG5hbWU6IE1NMDYxClsgIDEyNC4zMTQ4MTldIE1vZHVsZXMgbGlua2VkIGluOiBkZXNfZ2VuZXJp YyBtZDQgbmxzX3V0ZjggY2lmcyBmc2NhY2hlIGJyaWRnZSBzdHAgbGxjIGJvbmRpbmcgYmUyaXNj c2kgaXNjc2lfYm9vdF9zeXNmcyBibngyaSBjbmljIHVpbyBjeGdiM2kgbGliY3hnYmkgaXdfY3hn YjMgY3hnYjMgbWRpbyBpYl9pc2VyIHJkbWFfY20gaWJfY20gaXdfY20gaWJfc2EgaWJfbWFkIGli X2NvcmUgaWJfYWRkciBpc2NzaV90Y3AgbGliaXNjc2lfdGNwIGxpYmlzY3NpIGlwNnRfUkVKRUNU IG5mX2Nvbm50cmFja19pcHY2IG5mX2RlZnJhZ19pcHY2IHNjc2lfdHJhbnNwb3J0X2lzY3NpIGlw NnRhYmxlX2ZpbHRlciBpcDZfdGFibGVzIHh0X2NvbW1lbnQgbmZfY29ubnRyYWNrX2lwdjQgbmZf ZGVmcmFnX2lwdjQgeHRfc3RhdGUgbmZfY29ubnRyYWNrIGlwdF9MT0cgeHRfcGh5c2RldiBkZWxs X3dtaSBzcGFyc2Vfa2V5bWFwIHNuZF9oZGFfY29kZWNfaWR0IGRlbGxfbGFwdG9wIG1pY3JvY29k ZSBkY2RiYXMgc25kX2hkYV9pbnRlbCBzbmRfaGRhX2NvZGVjIHNuZF9od2RlcCByODUyIHNtX2Nv bW1vbiBuYW5kIG5hbmRfaWRzIHNuZF9zZXEgc25kX3NlcV9kZXZpY2UgYjQ0IG5hbmRfZWNjIGFy YzQgc25kX3BjbSBzc2IgaVRDT193ZHQgam95ZGV2IHI1OTIgbXRkIG1lbXN0aWNrIG1paSBpMmNf aTgwMSBpVENPX3ZlbmRvcl9zdXBwb3J0IGl3bDM5NDUgaXdsX2xlZ2FjeSBtYWM4MDIxMSBzbmRf dGltZXIgY2ZnODAyMTEgc25kIHJma2lsbCBzb3VuZGNvcmUgc25kX3BhZ2VfYWxsb2MgdHVuIHhl bl9nbnRhbGxvYyB4ZW5fY29yZSBmaXJld2lyZV9vaGNpIGZpcmV3aXJlX2NvcmUgY3JjX2l0dV90 IHdtaSBpOTE1IGRybV9rbXNfaGVscGVyIGRybSBpMmNfYWxnb19iaXQgaTJjX2NvcmUgdmlkZW8g W2xhc3QgdW5sb2FkZWQ6IHNjc2lfd2FpdF9zY2FuXQpbICAxMjQuMzE0ODE5XSBQaWQ6IDAsIGNv bW06IHN3YXBwZXIgTm90IHRhaW50ZWQgMy4xLjAtMC5yYzYuZ2l0MC4wLmZjMTcueDg2XzY0ICMx ClsgIDEyNC4zMTQ4MTldIENhbGwgVHJhY2U6ClsgIDEyNC4zMTQ4MTldICA8SVJRPiAgWzxmZmZm ZmZmZjgxMDVjNGEwPl0gd2Fybl9zbG93cGF0aF9jb21tb24rMHg4My8weDliClsgIDEyNC4zMTQ4 MTldICBbPGZmZmZmZmZmYTAzM2M3ZjQ+XSA/IGRlc3Ryb3lfY29ubnRyYWNrKzB4YWQvMHhlYyBb bmZfY29ubnRyYWNrXQpbICAxMjQuMzE0ODE5XSAgWzxmZmZmZmZmZjgxMDVjNGQyPl0gd2Fybl9z bG93cGF0aF9udWxsKzB4MWEvMHgxYwpbICAxMjQuMzE0ODE5XSAgWzxmZmZmZmZmZjgxMDYyNTk4 Pl0gX2xvY2FsX2JoX2VuYWJsZV9pcCsweDQ5LzB4Y2UKWyAgMTI0LjMxNDgxOV0gIFs8ZmZmZmZm ZmY4MTA2MjYyYj5dIGxvY2FsX2JoX2VuYWJsZV9pcCsweGUvMHgxMApbICAxMjQuMzE0ODE5XSAg WzxmZmZmZmZmZjgxNTA0ZGU5Pl0gX3Jhd19zcGluX3VubG9ja19iaCsweDQwLzB4NDQKWyAgMTI0 LjMxNDgxOV0gIFs8ZmZmZmZmZmZhMDMzYzdmND5dIGRlc3Ryb3lfY29ubnRyYWNrKzB4YWQvMHhl YyBbbmZfY29ubnRyYWNrXQpbICAxMjQuMzE0ODE5XSAgWzxmZmZmZmZmZmEwMzNjNzQ3Pl0gPyBu Zl9jb25udHJhY2tfZnJlZSsweDU4LzB4NTggW25mX2Nvbm50cmFja10KWyAgMTI0LjMxNDgxOV0g IFs8ZmZmZmZmZmY4MTQzYzg0Yz5dIG5mX2Nvbm50cmFja19kZXN0cm95KzB4NWEvMHg2NApbICAx MjQuMzE0ODE5XSAgWzxmZmZmZmZmZjgxNDBkODdkPl0gc2tiX3JlbGVhc2VfaGVhZF9zdGF0ZSsw eGE3LzB4ZWYKWyAgMTI0LjMxNDgxOV0gIFs8ZmZmZmZmZmY4MTQwZDUyMD5dIF9fa2ZyZWVfc2ti KzB4MTMvMHg4MwpbICAxMjQuMzE0ODE5XSAgWzxmZmZmZmZmZjgxNDBkNjM1Pl0gY29uc3VtZV9z a2IrMHhhNS8weGQxClsgIDEyNC4zMTQ4MTldICBbPGZmZmZmZmZmYTAyYTRhZjE+XSBiNDRfcG9s bCsweGFmLzB4M2VjIFtiNDRdClsgIDEyNC4zMTQ4MTldICBbPGZmZmZmZmZmODE0MTdiZmE+XSBu ZXRfcnhfYWN0aW9uKzB4YWUvMHgyMWMKWyAgMTI0LjMxNDgxOV0gIFs8ZmZmZmZmZmY4MTA2MmE5 YT5dID8gX19kb19zb2Z0aXJxKzB4N2UvMHgyNWEKWyAgMTI0LjMxNDgxOV0gIFs8ZmZmZmZmZmY4 MTA2MmIyZT5dIF9fZG9fc29mdGlycSsweDExMi8weDI1YQpbICAxMjQuMzE0ODE5XSAgWzxmZmZm ZmZmZjgxNTBkZjdjPl0gY2FsbF9zb2Z0aXJxKzB4MWMvMHgzMApbICAxMjQuMzE0ODE5XSAgWzxm ZmZmZmZmZjgxMDEwYmZkPl0gZG9fc29mdGlycSsweDRiLzB4YTIKWyAgMTI0LjMxNDgxOV0gIFs8 ZmZmZmZmZmY4MTA2MmVkZD5dIGlycV9leGl0KzB4NWQvMHhjZgpbICAxMjQuMzE0ODE5XSAgWzxm ZmZmZmZmZjgxMmRhZjU5Pl0geGVuX2V2dGNobl9kb191cGNhbGwrMHgzMS8weDNlClsgIDEyNC4z MTQ4MTldICBbPGZmZmZmZmZmODE1MGRmY2U+XSB4ZW5fZG9faHlwZXJ2aXNvcl9jYWxsYmFjaysw eDFlLzB4MzAKWyAgMTI0LjMxNDgxOV0gIDxFT0k+ICBbPGZmZmZmZmZmODEwMDEzYWE+XSA/IGh5 cGVyY2FsbF9wYWdlKzB4M2FhLzB4MTAwMApbICAxMjQuMzE0ODE5XSAgWzxmZmZmZmZmZjgxMDAx M2FhPl0gPyBoeXBlcmNhbGxfcGFnZSsweDNhYS8weDEwMDAKWyAgMTI0LjMxNDgxOV0gIFs8ZmZm ZmZmZmY4MTAwNzcwMT5dID8geGVuX3NhZmVfaGFsdCsweDEwLzB4MTgKWyAgMTI0LjMxNDgxOV0g IFs8ZmZmZmZmZmY4MTAxNjAxZT5dID8gZGVmYXVsdF9pZGxlKzB4NTMvMHg5MApbICAxMjQuMzE0 ODE5XSAgWzxmZmZmZmZmZjgxMDBlMmY5Pl0gPyBjcHVfaWRsZSsweGI1LzB4MTAxClsgIDEyNC4z MTQ4MTldICBbPGZmZmZmZmZmODE0ZTAzMDg+XSA/IHJlc3RfaW5pdCsweGRjLzB4ZTMKWyAgMTI0 LjMxNDgxOV0gIFs8ZmZmZmZmZmY4MTRlMDIyYz5dID8gY3N1bV9wYXJ0aWFsX2NvcHlfZ2VuZXJp YysweDE2Yy8weDE2YwpbICAxMjQuMzE0ODE5XSAgWzxmZmZmZmZmZjgxZDUzYjlmPl0gPyBzdGFy dF9rZXJuZWwrMHgzZGQvMHgzZWEKWyAgMTI0LjMxNDgxOV0gIFs8ZmZmZmZmZmY4MWQ1MzJjND5d ID8geDg2XzY0X3N0YXJ0X3Jlc2VydmF0aW9ucysweGFmLzB4YjMKWyAgMTI0LjMxNDgxOV0gIFs8 ZmZmZmZmZmY4MWQ1NWYxOD5dID8geGVuX3N0YXJ0X2tlcm5lbCsweDU4OC8weDU4ZgpbICAxMjQu MzE0ODE5XSAtLS1bIGVuZCB0cmFjZSA5M2E5ZTVlMmZiOGM2ZGQ3IF0tLS0KCkVSUk9SOiBNb2R1 bGUgYnVpbGQgZmFpbGVkIQpQbGVhc2UgZXhhbWluZSB0aGUgbG9nIGZpbGUgIi9ldGMvaHNmbW9k ZW0vbG9nL2J1aWxkbG9nLTIwMTEwOTEzMTkwNzAyLnR4dCIgdG8gZGV0ZXJtaW5lIHdoeS4KU3Rh cnRlZCBMU0I6IENvbmV4YW50IEhTRiBzb2Z0bW9kZW0uClN0YXJ0aW5nIFNZU1Y6IFRoaXMgc3Rh cnRzIHRoZSBMaW51eCBBdWRpdGluZyBTeXN0ZW0gRGFlbW9uLCB3aGljaCBjb2xsZWN0cyBzZWN1 cml0eSByZWxhdGVkIGV2ZW50cyBpbiBhIGRlZGljYXRlZCBhdWRpdCBsb2cuIElmIHRoaXMgZGFl bW9uIGlzIHR1cm5lZCBvZmYsIGF1ZGl0IGV2ZW50cyB3aWxsIGJlIHNlbnQgdG8gc3lzbG9nLi4u LgpTdGFydGluZyBhdWRpdGQ6IFsgIE9LICBdClN0YXJ0ZWQgU1lTVjogVGhpcyBzdGFydHMgdGhl IExpbnV4IEF1ZGl0aW5nIFN5c3RlbSBEYWVtb24sIHdoaWNoIGNvbGxlY3RzIHNlY3VyaXR5IHJl bGF0ZWQgZXZlbnRzIGluIGEgZGVkaWNhdGVkIGF1ZGl0IGxvZy4gSWYgdGhpcyBkYWVtb24gaXMg dHVybmVkIG9mZiwgYXVkaXQgZXZlbnRzIHdpbGwgYmUgc2VudCB0byBzeXNsb2cuLgpTdGFydGlu ZyBMU0I6IFN0YXJ0cyBhbmQgc3RvcHMgbG9naW4gYW5kIHNjYW5uaW5nIG9mIGlTQ1NJIGRldmlj ZXMuLi4uClN0YXJ0aW5nIFNZU1Y6IFRoZSBycGNiaW5kIHV0aWxpdHkgaXMgYSBzZXJ2ZXIgdGhh dCBjb252ZXJ0cyBSUEMgcHJvZ3JhbSBudW1iZXJzIGludG8gdW5pdmVyc2FsIGFkZHJlc3Nlcy4g SXQgbXVzdCBiZSBydW5uaW5nIG9uIHRoZSBob3N0IHRvIGJlIGFibGUgdG8gbWFrZSBSUEMgY2Fs bHMgb24gYSBzZXJ2ZXIgb24gdGhhdCBtYWNoaW5lLi4uLgpTdGFydGluZyBpc2NzaTogWyAgMTM3 LjY2ODY4Ml0gc2NzaTIgOiBpU0NTSSBJbml0aWF0b3Igb3ZlciBUQ1AvSVAKU3RhcnRpbmcgcnBj YmluZDogWyAgT0sgIF0KU3RhcnRlZCBTWVNWOiBUaGUgcnBjYmluZCB1dGlsaXR5IGlzIGEgc2Vy dmVyIHRoYXQgY29udmVydHMgUlBDIHByb2dyYW0gbnVtYmVycyBpbnRvIHVuaXZlcnNhbCBhZGRy ZXNzZXMuIEl0IG11c3QgYmUgcnVubmluZyBvbiB0aGUgaG9zdCB0byBiZSBhYmxlIHRvIG1ha2Ug UlBDIFsgIDEzOC4yMzgxNTJdIHNjc2kgMjowOjA6MDogUkFJRCAgICAgICAgICAgICAgSUVUICAg ICAgQ29udHJvbGxlciAgICAgICAwMDAxIFBROiAwIEFOU0k6IDUKWyAgMTM4LjI1NDU0OF0gc2Nz aSAyOjA6MDowOiBBdHRhY2hlZCBzY3NpIGdlbmVyaWMgc2cyIHR5cGUgMTIKWyAgMTM4LjI4Njc2 MV0gc2NzaSAyOjA6MDoxOiBEaXJlY3QtQWNjZXNzICAgICBJRVQgICAgICBWSVJUVUFMLURJU0sg ICAgIDAwMDEgUFE6IDAgQU5TSTogNQpbICAxMzguMjkxMTQ5XSBzZCAyOjA6MDoxOiBBdHRhY2hl ZCBzY3NpIGdlbmVyaWMgc2czIHR5cGUgMApbICAxMzguMjk1ODU4XSBzZCAyOjA6MDoxOiBbc2Ri XSAzMTI1ODE4MDggNTEyLWJ5dGUgbG9naWNhbCBibG9ja3M6ICgxNjAgR0IvMTQ5IEdpQikKWyAg MTM4LjMwNDA0OV0gc2QgMjowOjA6MTogW3NkYl0gV3JpdGUgUHJvdGVjdCBpcyBvZmYKWyAgMTM4 LjMwNDA4N10gc2QgMjowOjA6MTogW3NkYl0gTW9kZSBTZW5zZTogNzkgMDAgMDAgMDgKWyAgMTM4 LjMwNjMyMF0gc2QgMjowOjA6MTogW3NkYl0gV3JpdGUgY2FjaGU6IGVuYWJsZWQsIHJlYWQgY2Fj aGU6IGVuYWJsZWQsIGRvZXNuJ3Qgc3VwcG9ydCBEUE8gb3IgRlVBClN0YXJ0aW5nIExTQjogTW91 bnQgYW5kIHVubW91bnQgbmV0d29yayBmaWxlc3lzdGVtcy4uLi4KWyAgMTM4LjMzMjYyMl0gIHNk Yjogc2RiMSBzZGIyIHNkYjMKClsgIDEzOC4zNTA5MDJdIHNkIDI6MDowOjE6IFtzZGJdIEF0dGFj aGVkIFNDU0kgZGlzawpTdGFydGluZyBMU0I6IFN0YXJ0cyB0aGUgUlBDU0VDIEdTUyBjbGllbnQg ZGFlbW9uLi4uClN0YXJ0aW5nIExTQjogR3VhcmQuLi4KU3RhcnRpbmcgTFNCOiBTdGFydCBhbmQg c3RvcCB0aGUgTUQgc29mdHdhcmUgUkFJRCBtb25pdG9yLi4uClN0YXJ0aW5nIExTQjogU3RhcnQg dXAgdGhlIE5GUyBmaWxlIGxvY2tpbmcgc2V2aWNlLi4uClN0YXJ0aW5nIExTQjogc3RhcnQgYW5k IHN0b3Agd3BhX3N1cHBsaWNhbnQuLi4KU3RhcnRpbmcgTFNCOiBTdGFydCB1cCB0aGUgTkZTIHNl cnZlciBzZXZpY2UuLi4KU3RhcnRpbmcgTFNCOiBUaGUgQ1VQUyBzY2hlZHVsZXIuLi4KU3RhcnRp bmcgTFNCOiBTdGFydHMgdGhlIFJQQ1NFQyBHU1Mgc2VydmVyIGRhZW1vbi4uLgpTdGFydGluZyBM U0I6IFN0YXJ0cyB0aGUgTkZTdjQgaWQgbWFwcGluZyBkYWVtb24uLi4KU3RhcnRlZCBMU0I6IFN0 YXJ0cyBhbmQgc3RvcHMgbG9naW4gYW5kIHNjYW5uaW5nIG9mIGlTQ1NJIGRldmljZXMuLgpTdGFy dGVkIExTQjogU3RhcnQgYW5kIHN0b3AgdGhlIE1EIHNvZnR3YXJlIFJBSUQgbW9uaXRvci4KU3Rh cnRpbmcgd3BhX3N1cHBsaWNhbnQ6IC9ldGMvd3BhX3N1cHBsaWNhbnQvd3BhX3N1cHBsaWNhbnQu Y29uZiwgLWl3bGFuMCwgLUR3ZXh0U3RhcnRpbmcgY3VwczogTW91bnRpbmcgQ0lGUyBmaWxlc3lz dGVtczogIFN0YXJ0ZWQgTFNCOiBTdGFydHMgdGhlIFJQQ1NFQyBHU1Mgc2VydmVyIGRhZW1vbi4K WyAgT0sgIF0KCk1vdW50aW5nIG90aGVyIGZpbGVzeXN0ZW1zOiAgU3RhcnRlZCBMU0I6IFN0YXJ0 cyB0aGUgUlBDU0VDIEdTUyBjbGllbnQgZGFlbW9uLgptb3VudDogc3lzZnMgYWxyZWFkeSBtb3Vu dGVkIG9yIC9zeXMgYnVzeQptb3VudDogYWNjb3JkaW5nIHRvIG10YWIsIC9zeXMgaXMgYWxyZWFk eSBtb3VudGVkIG9uIC9zeXMKW0ZBSUxFRF0KU3RhcnRlZCBMU0I6IE1vdW50IGFuZCB1bm1vdW50 IG5ldHdvcmsgZmlsZXN5c3RlbXMuLgpTdGFydGluZyBMU0I6IERhZW1vbiB0byBhY2Nlc3MgYSBz bWFydCBjYXJkIHVzaW5nIFBDL1NDLi4uClN0YXJ0aW5nIFBlcm1pdCBVc2VyIFNlc3Npb25zLi4u ClN0YXJ0aW5nIEFWSVJBIEFudGlWaXIgV29ya3N0YXRpb24gUGVyc29uYWwgLi4uClN0YXJ0aW5n IE5GUyBzdGF0ZDogU3RhcnRlZCBQZXJtaXQgVXNlciBTZXNzaW9ucy4KWyAgT0sgIF0KU3RhcnRp bmcgUEMvU0Mgc21hcnQgY2FyZCBkYWVtb24gKHBjc2NkKTogWyAgMTQyLjQ3MTY1OF0gaXdsMzk0 NSAwMDAwOjBiOjAwLjA6IGxvYWRlZCBmaXJtd2FyZSB2ZXJzaW9uIDE1LjMyLjIuOQpTdGFydGlu ZyBycGNzdmNnc3NkICh2aWEgc3lzdGVtY3RsKTogIFN0YXJ0ZWQgTFNCOiBTdGFydHMgdGhlIFJQ Q1NFQyBHU1Mgc2VydmVyIGRhZW1vbi4KWyAgT0sgIF0KWyAgMTQyLjkxMjAzMl0gY2FsbGluZyAg aW5pdF9zdW5ycGMrMHgwLzB4NzAgW3N1bnJwY10gQCAyOTA3ClsgIDE0Mi45MjA5NzRdIFJQQzog UmVnaXN0ZXJlZCBuYW1lZCBVTklYIHNvY2tldCB0cmFuc3BvcnQgbW9kdWxlLgpbICAxNDIuOTIx MDU1XSBSUEM6IFJlZ2lzdGVyZWQgdWRwIHRyYW5zcG9ydCBtb2R1bGUuClsgIDE0Mi45MjEwNjJd IFJQQzogUmVnaXN0ZXJlZCB0Y3AgdHJhbnNwb3J0IG1vZHVsZS4KWyAgMTQyLjkyMTA2Ml0gUlBD OiBSZWdpc3RlcmVkIHRjcCBORlN2NC4xIGJhY2tjaGFubmVsIHRyYW5zcG9ydCBtb2R1bGUuClsg IDE0Mi45MjEwNjJdIGluaXRjYWxsIGluaXRfc3VucnBjKzB4MC8weDcwIFtzdW5ycGNdIHJldHVy bmVkIDAgYWZ0ZXIgODgwNCB1c2VjcwpbICAxNDMuMTEyNzQyXSBTRUxpbnV4OiBpbml0aWFsaXpl ZCAoZGV2IHJwY19waXBlZnMsIHR5cGUgcnBjX3BpcGVmcyksIHVzZXMgZ2VuZnNfY29udGV4dHMK WyAgMTQzLjEzMTcwMF0gQUREUkNPTkYoTkVUREVWX1VQKTogd2xhbjA6IGxpbmsgaXMgbm90IHJl YWR5ClsgIDE0My4yNzk1NzFdIGNhbGxpbmcgIGluaXRfcnBjc2VjX2dzcysweDAvMHgxMDAwIFth dXRoX3JwY2dzc10gQCAyOTA0ClsgIDE0My4yNzk4MzZdIGluaXRjYWxsIGluaXRfcnBjc2VjX2dz cysweDAvMHgxMDAwIFthdXRoX3JwY2dzc10gcmV0dXJuZWQgMCBhZnRlciAyMDAgdXNlY3MKWyAg MTQzLjM0NjE5OV0gaW5pdGNhbGwgaW5pdF9ubG0rMHgwLzB4MTAwMCBbbG9ja2RdIHJldHVybmVk IDAgYWZ0ZXIgNDI1IHVzZWNzCiAgT0sgIF0KWyAgT0sgIF0KU3RhcnRlZCBMU0I6IFN0YXJ0IHVw IHRoZSBORlMgZmlsZSBsb2NraW5nIHNldmljZS4KU3RhcnRlZCBMU0I6IFRoZSBDVVBTIHNjaGVk dWxlci4KWyAgT0sgIF0KWyAgMTQzLjczNDU1OF0gY2FsbGluZyAgaW5pdF9uZnNkKzB4MC8weDEw MDAgW25mc2RdIEAgMjkyNQpbICAxNDMuNzM0NjMyXSBJbnN0YWxsaW5nIGtuZnNkIChjb3B5cmln aHQgKEMpIDE5OTYgb2tpckBtb25hZC5zd2IuZGUpLgpbICAxNDMuNzk3OTkzXSBpbml0Y2FsbCBp bml0X25mc2QrMHgwLzB4MTAwMCBbbmZzZF0gcmV0dXJuZWQgMCBhZnRlciA2MTgzMSB1c2VjcwpT dGFydGVkIExTQjogc3RhcnQgYW5kIHN0b3Agd3BhX3N1cHBsaWNhbnQuClN0YXJ0ZWQgTFNCOiBE YWVtb24gdG8gYWNjZXNzIGEgc21hcnQgY2FyZCB1c2luZyBQQy9TQy4KWyAgMTQ0LjA3NjcwNF0g U0VMaW51eDogaW5pdGlhbGl6ZWQgKGRldiBuZnNkLCB0eXBlIG5mc2QpLCB1c2VzIGdlbmZzX2Nv bnRleHRzClN0YXJ0aW5nIFJQQyBpZG1hcGQ6IFN0YXJ0aW5nIE5GUyBzZXJ2aWNlczogIGV4cG9y dGZzOiBzY2FuZGlyIC9ldGMvZXhwb3J0cy5kOiBObyBzdWNoIGZpbGUgb3IgZGlyZWN0b3J5Cgpb ICBPSyAgXQpTdGFydGluZyBORlMgcXVvdGFzOiBbICBPSyAgXQpbICBPSyAgXQpTdGFydGluZyBO RlMgZGFlbW9uOiBTdGFydGVkIExTQjogU3RhcnRzIHRoZSBORlN2NCBpZCBtYXBwaW5nIGRhZW1v bi4KU3RhcnRpbmc6IGF2Z3VhcmQuYmluClsgIDE0NS4yMjM3MTZdIE5GU0Q6IFVzaW5nIC92YXIv bGliL25mcy92NHJlY292ZXJ5IGFzIHRoZSBORlN2NCBzdGF0ZSByZWNvdmVyeSBkaXJlY3RvcnkK WyAgMTQ1LjI0Nzc4M10gTkZTRDogc3RhcnRpbmcgOTAtc2Vjb25kIGdyYWNlIHBlcmlvZApbICBP SyAgXQpTdGFydGluZyBORlMgbW91bnRkOiBbICBPSyAgXQpTdGFydGVkIExTQjogU3RhcnQgdXAg dGhlIE5GUyBzZXJ2ZXIgc2V2aWNlLgpbICAxNDYuNTA1OTIxXSB3bGFuMDogYXV0aGVudGljYXRl IHdpdGggNjg6N2Y6NzQ6YTc6NWI6Y2UgKHRyeSAxKQpbICAxNDYuNTA3OTQ2XSB3bGFuMDogYXV0 aGVudGljYXRlZApbICAxNDYuNTA4MjI0XSB3bGFuMDogYXNzb2NpYXRlIHdpdGggNjg6N2Y6NzQ6 YTc6NWI6Y2UgKHRyeSAxKQpbICAxNDYuNTExMDAxXSB3bGFuMDogUlggQXNzb2NSZXNwIGZyb20g Njg6N2Y6NzQ6YTc6NWI6Y2UgKGNhcGFiPTB4NDExIHN0YXR1cz0wIGFpZD0xKQpbICAxNDYuNTEx MDM3XSB3bGFuMDogYXNzb2NpYXRlZApbICAxNDYuNTIzMzAyXSBBRERSQ09ORihORVRERVZfQ0hB TkdFKTogd2xhbjA6IGxpbmsgYmVjb21lcyByZWFkeQpbICAxNTYuODgyMDc2XSB3bGFuMDogbm8g SVB2NiByb3V0ZXJzIHByZXNlbnQKV2FybmluZzogTm8gZGF6dWtvIG1vZHVsZSBhdmFpbGFibGUs IG9uLWFjY2VzcyBwcm90ZWN0aW9uIGRpc2FibGVkLgpTdGFydGVkIExTQjogR3VhcmQuClN0YXJ0 aW5nIFNZU1Y6IEVuYWJsZSBkYWlseSBydW4gb2YgeXVtLCBhIHByb2dyYW0gdXBkYXRlci4uLi4K RW5hYmxpbmcgbmlnaHRseSB5dW0gdXBkYXRlOiBbICBPSyAgXQpTdGFydGVkIFNZU1Y6IEVuYWJs ZSBkYWlseSBydW4gb2YgeXVtLCBhIHByb2dyYW0gdXBkYXRlci4uClN0YXJ0aW5nIExTQjogSW5z dGFsbHMgY29yZWR1bXAgaGFuZGxlciB3aGljaCBzYXZlcyBzZWdmYXVsdCBkYXRhLi4uClN0YXJ0 aW5nIExTQjogU3RhcnQgdXAgdGhlIE9wZW5TU0ggc2VydmVyIGRhZW1vbi4uLgpTdGFydGluZyBM U0I6IHN0YXJ0IGFuZCBzdG9wIHNlbmRtYWlsLi4uClN0YXJ0aW5nIExTQjogc3RhcnQgYW5kIHN0 b3Aga3NtLi4uClN0YXJ0aW5nIExTQjogdHVuZSB0aGUgc3BlZWQgb2Yga3NtLi4uClN0YXJ0aW5n IHNzaGQ6IFN0YXJ0aW5nIGtzbXR1bmVkOiBTdGFydGluZyBrc206IFsgIE9LICBdClN0YXJ0ZWQg TFNCOiBzdGFydCBhbmQgc3RvcCBrc20uClN0YXJ0aW5nIHNlbmRtYWlsOiBTdGFydGVkIExTQjog SW5zdGFsbHMgY29yZWR1bXAgaGFuZGxlciB3aGljaCBzYXZlcyBzZWdmYXVsdCBkYXRhLgpbICBP SyAgXQpTdGFydGVkIExTQjogdHVuZSB0aGUgc3BlZWQgb2Yga3NtLgpbICBPSyAgXQpTdGFydGVk IExTQjogU3RhcnQgdXAgdGhlIE9wZW5TU0ggc2VydmVyIGRhZW1vbi4KWyAgT0sgIF0KU3RhcnRp bmcgc20tY2xpZW50OiBbICBPSyAgXQpTdGFydGVkIExTQjogc3RhcnQgYW5kIHN0b3Agc2VuZG1h aWwuClN0YXJ0aW5nIFNZU1Y6IEVuYWJsZSBtb250aGx5IHVwZGF0ZSBvZiBTbW9sdC4uLgpFbmFi bGluZyBtb250aGx5IFNtb2x0IGNoZWNraW46IFsgIE9LICBdClN0YXJ0ZWQgU1lTVjogRW5hYmxl IG1vbnRobHkgdXBkYXRlIG9mIFNtb2x0LgpTdGFydGluZyBMU0I6IHN0YXJ0fHN0b3B8cmVzdGFy dHx0cnktcmVzdGFydHxzdGF0dXN8Zm9yY2UtcmVsb2FkIHZuY3NlcnZlci4uLgpTTUIgbmV0d29y ayBzZXJ2aWNlcy4uLi4KU3RhcnRpbmcgU1lTVjogU3RhcnRzIGFuZCBzdG9wcyB0aGUgU2FtYmEg c21iZCBkYWVtb24gdXNlZCB0byBwcm92aWRlIFNNQiBuZXR3b3JrIHNlcnZpY2VzLi4uLgpTdGFy dGluZyBWTkMgc2VydmVyOiAxOmppbWIgU3RhcnRpbmcgTk1CIHNlcnZpY2VzOiBTdGFydGluZyBT TUIgc2VydmljZXM6IFsgIE9LICBdClN0YXJ0ZWQgU1lTVjogU3RhcnRzIGFuZCBzdG9wcyB0aGUg U2FtYmEgc21iZCBhbmQgbm1iZCBkYWVtb25zIHVzZWQgdG8gcHJvdmlkZSBTTUIgbmV0d29yayBz ZXJ2aWNlcy4uClsgIE9LICBdClN0YXJ0ZWQgU1lTVjogU3RhcnRzIGFuZCBzdG9wcyB0aGUgU2Ft YmEgc21iZCBkYWVtb24gdXNlZCB0byBwcm92aWRlIFNNQiBuZXR3b3JrIHNlcnZpY2VzLi4KU3Rh cnRpbmcgTFNCOiBTdGFydC9zdG9wIHhlbmNvbnNvbGVkLi4uClN0YXJ0aW5nIExTQjogU3RhcnQv c3RvcCB4ZW5zdG9yZWQuLi4KU3RhcnRpbmcgTFNCOiBTdGFydC9zdG9wIHhlbmQuLi4KU3RhcnRp bmcgTFNCOiBTdGFydC9zdG9wIGJsa3RhcGN0cmwuLi4KU3RhcnRpbmcgeGVuY29uc29sZWQgZGFl bW9uOiBTdGFydGluZyAvZXRjL3JjLmxvY2FsIENvbXBhdGliaWxpdHkuLi4KWyAgT0sgIF0KU3Rh cnRpbmcgeGVuZCBkYWVtb246IFN0YXJ0ZWQgTFNCOiBTdGFydC9zdG9wIHhlbmNvbnNvbGVkLgpT dGFydGluZyB4ZW4gYmxrdGFwY3RybCBkYWVtb246IFN0YXJ0aW5nIHhlbnN0b3JlZCBkYWVtb246 IHJtOiBjYW5ub3QgcmVtb3ZlIGAvdG1wLy5YMTEtdW5peC9YMSc6IE5vIHN1Y2ggZmlsZSBvciBk aXJlY3RvcnkKWyAgMTc3LjU2ODA5Nl0gU0VMaW51eDogaW5pdGlhbGl6ZWQgKGRldiB0bXBmcywg dHlwZSB0bXBmcyksIHVzZXMgdHJhbnNpdGlvbiBTSURzClsgIE9LICBdClN0YXJ0ZWQgTFNCOiBT dGFydC9zdG9wIGJsa3RhcGN0cmwuClsgIDE3OC4yMzc2MDFdIGNhbGxpbmcgIHhlbl9wY2lia19p bml0KzB4MC8weDJmOCBbeGVuX3BjaWJhY2tdIEAgMzE3NwpbICAxNzguMjU0MTk2XSB4ZW4tcGNp YmFjazogYmFja2VuZCBpcyB2cGNpClsgIDE3OC4yNTQ4MDRdIGluaXRjYWxsIHhlbl9wY2lia19p bml0KzB4MC8weDJmOCBbeGVuX3BjaWJhY2tdIHJldHVybmVkIDAgYWZ0ZXIgMTY3MzYgdXNlY3MK WyAgT0sgIF0KU3RhcnRlZCBMU0I6IFN0YXJ0L3N0b3AgeGVuc3RvcmVkLgpbICAxNzguNjA5MjE5 XSB3bGFuMDogZGVhdXRoZW50aWNhdGluZyBmcm9tIDY4OjdmOjc0OmE3OjViOmNlIGJ5IGxvY2Fs IGNob2ljZSAocmVhc29uPTMpClsgIDE3OC42NTE3NDVdIGNmZzgwMjExOiBDYWxsaW5nIENSREEg dG8gdXBkYXRlIHdvcmxkIHJlZ3VsYXRvcnkgZG9tYWluClsgIDE3OC45Mjc1MTNdIEJVRzogc2xl ZXBpbmcgZnVuY3Rpb24gY2FsbGVkIGZyb20gaW52YWxpZCBjb250ZXh0IGF0IGtlcm5lbC9tdXRl eC5jOjI3MQpbICAxNzguOTI3NjYwXSBpbl9hdG9taWMoKTogMSwgaXJxc19kaXNhYmxlZCgpOiAw LCBwaWQ6IDMxODMsIG5hbWU6IHhlbnN0b3JlZApbICAxNzguOTI3NzE4XSBJTkZPOiBsb2NrZGVw IGlzIHR1cm5lZCBvZmYuClsgIDE3OC45Mjc3NjFdIFBpZDogMzE4MywgY29tbTogeGVuc3RvcmVk IFRhaW50ZWQ6IEcgICAgICAgIFcgICAzLjEuMC0wLnJjNi5naXQwLjAuZmMxNy54ODZfNjQgIzEK WyAgMTc4LjkyNzgzNV0gQ2FsbCBUcmFjZToKWyAgMTc4LjkyNzg4N10gIFs8ZmZmZmZmZmY4MTA0 ZjZkNT5dIF9fbWlnaHRfc2xlZXArMHgxMDMvMHgxMDgKWyAgMTc4LjkyNzk0Nl0gIFs8ZmZmZmZm ZmY4MTUwMzVmMj5dIG11dGV4X2xvY2tfbmVzdGVkKzB4MjUvMHg0NQpbICAxNzguOTI4MDExXSAg WzxmZmZmZmZmZjgxNGUxM2NkPl0gX19pcnFfYWxsb2NfZGVzY3MrMHg1MC8weDE4YgpbICAxNzgu OTI4MDg0XSAgWzxmZmZmZmZmZjgxMmQwMjVmPl0gPyBnaGVzX2lycV9mdW5jKzB4MTYvMHgxYgpb ICAxNzguOTI4MjI2XSAgWzxmZmZmZmZmZjgxMmQ5YzBlPl0geGVuX2FsbG9jYXRlX2lycV9keW5h bWljKzB4NDkvMHg1OApbICAxNzguOTI4MjkwXSAgWzxmZmZmZmZmZjgxMmRhMzc2Pl0gYmluZF9l dnRjaG5fdG9faXJxKzB4MzIvMHg4MgpbICAxNzguOTI4MzQ5XSAgWzxmZmZmZmZmZjgxMmRhNDZl Pl0gYmluZF9ldnRjaG5fdG9faXJxaGFuZGxlcisweDI1LzB4NjMKWyAgMTc4LjkyODQzNV0gIFs8 ZmZmZmZmZmZhMDExYzRmOD5dID8gc2V0X3BvcnRfZW5hYmxlZCsweDMxLzB4MzEgW3hlbl9ldnRj aG5dClsgIDE3OC45Mjg1MTVdICBbPGZmZmZmZmZmYTAxMWM2YTI+XSBldnRjaG5fYmluZF90b191 c2VyKzB4NTYvMHg2NCBbeGVuX2V2dGNobl0KWyAgMTc4LjkyODYwMV0gIFs8ZmZmZmZmZmZhMDEx YzgwYT5dIGV2dGNobl9pb2N0bCsweDEyOS8weDJlZiBbeGVuX2V2dGNobl0KWyAgMTc4LjkyODY2 NV0gIFs8ZmZmZmZmZmY4MTE1MWViNT5dIGRvX3Zmc19pb2N0bCsweDQ3Mi8weDRiMwpbICAxNzgu OTI4NzE3XSAgWzxmZmZmZmZmZjgxMTUxZjRjPl0gc3lzX2lvY3RsKzB4NTYvMHg3YQpbICAxNzgu OTI4NzcxXSAgWzxmZmZmZmZmZjgxNTBiYzgyPl0gc3lzdGVtX2NhbGxfZmFzdHBhdGgrMHgxNi8w eDFiClsgIDE3OC45Mjg4MjldIEJVRzogc2NoZWR1bGluZyB3aGlsZSBhdG9taWM6IHhlbnN0b3Jl ZC8zMTgzLzB4MTAwMDAwMDIKWyAgMTc4LjkyODkyMF0gSU5GTzogbG9ja2RlcCBpcyB0dXJuZWQg b2ZmLgpbICAxNzguOTI4OTU2XSBNb2R1bGVzIGxpbmtlZCBpbjogeGVuX3BjaWJhY2sgbmZzZCBs b2NrZCBuZnNfYWNsIGF1dGhfcnBjZ3NzIHN1bnJwYyBkZXNfZ2VuZXJpYyBtZDQgbmxzX3V0Zjgg Y2lmcyBmc2NhY2hlIGJyaWRnZSBzdHAgbGxjIGJvbmRpbmcgYmUyaXNjc2kgaXNjc2lfYm9vdF9z eXNmcyBibngyaSBjbmljIHVpbyBjeGdiM2kgbGliY3hnYmkgaXdfY3hnYjMgY3hnYjMgbWRpbyBp Yl9pc2VyIHJkbWFfY20gaWJfY20gaXdfY20gaWJfc2EgaWJfbWFkIGliX2NvcmUgaWJfYWRkciBp c2NzaV90Y3AgbGliaXNjc2lfdGNwIGxpYmlzY3NpIGlwNnRfUkVKRUNUIG5mX2Nvbm50cmFja19p cHY2IG5mX2RlZnJhZ19pcHY2IHNjc2lfdHJhbnNwb3J0X2lzY3NpIGlwNnRhYmxlX2ZpbHRlciBp cDZfdGFiX3BoeXNkZXYgZGVsbF93bWkgc3BhcnNlX2tleW1hcCBzbmRfaGRhX2NvZGVjX2lkdCBk ZWxsX2xhcHRvcCBtaWNyb2NvZGUgZGNkYmFzIHNuZF9oZGFfaW50ZWwgc25kX2hkYV9jb2RlYyBz bmRfaHdkZXAgcjg1MiBzbV9jb21tb24gbmFuZCBuYW5kX2lkcyBzbmRfc2VxIHNuZF9zZXFfZGV2 aWNlIGI0NCBuYW5kX2VjYyBhcmM0IHNuZF9wY20gc3NiIGlUQ09fd2R0IGpveWRldiByNTkyIG10 ZCBtZW1zdGljayBtaWkgaTJjX2k4MDEgaVRDT192ZW5kb3Jfc3VwcG9ydCBpd2wzOTQ1IGl3bF9s ZWdhY3kgbWFjODAyMTEgc25kX3RpbWVyIGNmZzgwMjExIHNuZCByZmtpbGwgc291bmRjb3JlIHNu ZF9wYWdlX2FsbG9jIHR1biB4ZW5fZ250YWxsb2MgeGVuX25ldGJhY2sgeGVuX2Jsa2JhY2sgeGVu X2dudGRldiB4ZW5fZXZ0Y2huIHhlbmZzIGJpbmZtdF9taXNjIHNkaGNpX3BjaSBzZGhjaSBtbWNf Y29yZSBmaXJld2lyZV9vaGNpIGZpcmV3aXJlX2NvcmUgY3JjX2l0dV90IHdtaSBpOTE1IGRybV9r bXNfaGVscGVyIGRybSBpMmNfYWxnb19iaXQgaTJjX2NvcmUgdmlkZW8gW2xhc3QgdW5sb2FkZWQ6 IHNjc2lfd2FpdF9zY2FuXQpbICAxNzguOTI5MTgwXSBQaWQ6IDMxODMsIGNvbW06IHhlbnN0b3Jl ZCBUYWludGVkOiBHICAgICAgICBXICAgMy4xLjAtMC5yYzYuZ2l0MC4wLmZjMTcueDg2XzY0ICMx ClsgIDE3OC45MjkxODBdIENhbGwgVHJhY2U6ClsgIDE3OC45MjkxODBdICBbPGZmZmZmZmZmODE0 ZjllNDQ+XSBfX3NjaGVkdWxlX2J1ZysweDc1LzB4N2EKWyAgMTc4LjkzMTQ2MF0gIFs8ZmZmZmZm ZmY4MTUwMjEwZD5dIF9fc2NoZWR1bGUrMHg5NS8weDc2MQpbICAxNzguOTMxNTI3XSAgWzxmZmZm ZmZmZjgxMDExZTE3Pl0gPyBzaG93X3RyYWNlX2xvZ19sdmwrMHg1NC8weDVkClsgIDE3OC45MzE1 OTBdICBbPGZmZmZmZmZmODEwMTFlMzU+XSA/IHNob3dfdHJhY2UrMHgxNS8weDE3ClsgIDE3OC45 MzE2MzldICBbPGZmZmZmZmZmODEwNTZjMjg+XSBfX2NvbmRfcmVzY2hlZCsweDI4LzB4MzQKWyAg MTc4LjkzMTY4OF0gIFs8ZmZmZmZmZmY4MTUwMjgzNT5dIF9jb25kX3Jlc2NoZWQrMHgxOS8weDIy ClsgIDE3OC45MzE3ODFdICBbPGZmZmZmZmZmODE1MDM1Zjc+XSBtdXRleF9sb2NrX25lc3RlZCsw eDJhLzB4NDUKWyAgMTc4LjkzMTg0MV0gIFs8ZmZmZmZmZmY4MTRlMTNjZD5dIF9faXJxX2FsbG9j X2Rlc2NzKzB4NTAvMHgxOGIKWyAgMTc4LjkzMTkwM10gIFs8ZmZmZmZmZmY4MTJkMDI1Zj5dID8g Z2hlc19pcnFfZnVuYysweDE2LzB4MWIKWyAgMTc4LjkzMTk1Ml0gIFs8ZmZmZmZmZmY4MTJkOWMw ZT5dIHhlbl9hbGxvY2F0ZV9pcnFfZHluYW1pYysweDQ5LzB4NTgKWyAgMTc4LjkzMjAxMF0gIFs8 ZmZmZmZmZmY4MTJkYTM3Nj5dIGJpbmRfZXZ0Y2huX3RvX2lycSsweDMyLzB4ODIKWyAgMTc4Ljkz MjA2OF0gIFs8ZmZmZmZmZmY4MTJkYTQ2ZT5dIGJpbmRfZXZ0Y2huX3RvX2lycWhhbmRsZXIrMHgy NS8weDYzClsgIDE3OC45MzIxOThdICBbPGZmZmZmZmZmYTAxMWM0Zjg+XSA/IHNldF9wb3J0X2Vu YWJsZWQrMHgzMS8weDMxIFt4ZW5fZXZ0Y2huXQpbICAxNzguOTMyMjc0XSAgWzxmZmZmZmZmZmEw MTFjNmEyPl0gZXZ0Y2huX2JpbmRfdG9fdXNlcisweDU2LzB4NjQgW3hlbl9ldnRjaG5dClsgIDE3 OC45MzIzNTJdICBbPGZmZmZmZmZmYTAxMWM4MGE+XSBldnRjaG5faW9jdGwrMHgxMjkvMHgyZWYg W3hlbl9ldnRjaG5dClsgIDE3OC45MzI0MTJdICBbPGZmZmZmZmZmODExNTFlYjU+XSBkb192ZnNf aW9jdGwrMHg0NzIvMHg0YjMKWyAgMTc4LjkzMjQ2NF0gIFs8ZmZmZmZmZmY4MTE1MWY0Yz5dIHN5 c19pb2N0bCsweDU2LzB4N2EKWyAgMTc4LjkzMjUxN10gIFs8ZmZmZmZmZmY4MTUwYmM4Mj5dIHN5 c3RlbV9jYWxsX2Zhc3RwYXRoKzB4MTYvMHgxYgpbICAxNzguOTkxNjgxXSBpd2wzOTQ1IDAwMDA6 MGI6MDAuMDogUENJIElOVCBBIGRpc2FibGVkClsgIDE3OC45OTU5NzZdIHBjaWJhY2sgMDAwMDow YjowMC4wOiBzZWl6aW5nIGRldmljZQpbICAxNzguOTk2MjY4XSB4ZW46IHJlZ2lzdGVyaW5nIGdz aSAxNiB0cmlnZ2VyaW5nIDAgcG9sYXJpdHkgMQpbICAxNzguOTk2NTM2XSB4ZW5fbWFwX3BpcnFf Z3NpOiByZXR1cm5pbmcgaXJxIDE2IGZvciBnc2kgMTYKWyAgMTc4Ljk5NjU2MF0geGVuOiAtLT4g cGlycT0xNiAtPiBpcnE9MTYgKGdzaT0xNikKWyAgMTc4Ljk5NjU4Ml0gQWxyZWFkeSBzZXR1cCB0 aGUgR1NJIDoxNgpbICAxNzguOTk2NjAxXSBwY2liYWNrIDAwMDA6MGI6MDAuMDogUENJIElOVCBB IC0+IEdTSSAxNiAobGV2ZWwsIGxvdykgLT4gSVJRIDE2ClsgIDE3OC45OTY2NDJdIHBjaWJhY2sg MDAwMDowYjowMC4wOiBQQ0kgSU5UIEEgZGlzYWJsZWQKWyAgMTc5LjA3MzkyMl0gWEVOQlVTOiBV bmFibGUgdG8gcmVhZCBjcHUgc3RhdGUKWyAgMTc5LjA4NTAwOF0gWEVOQlVTOiBVbmFibGUgdG8g cmVhZCBjcHUgc3RhdGUKWyAgMTc5LjEzMTE1MF0gQlVHOiBzY2hlZHVsaW5nIHdoaWxlIGF0b21p YzogeGVuY29uc29sZWQvMzE1OC8weDEwMDAwMDAyClsgIDE3OS4xMzEyMzFdIElORk86IGxvY2tk ZXAgaXMgdHVybmVkIG9mZi4KWyAgMTc5LjEzMTI2N10gTW9kdWxlcyBsaW5rZWQgaW46IHhlbl9w Y2liYWNrIG5mc2QgbG9ja2QgbmZzX2FjbCBhdXRoX3JwY2dzcyBzdW5ycGMgZGVzX2dlbmVyaWMg bWQ0IG5sc191dGY4IGNpZnMgZnNjYWNoZSBicmlkZ2Ugc3RwIGxsYyBib25kaW5nIGJlMmlzY3Np IGlzY3NpX2Jvb3Rfc3lzZnMgYm54MmkgY25pYyB1aW8gY3hnYjNpIGxpYmN4Z2JpIGl3X2N4Z2Iz IGN4Z2IzIG1kaW8gaWJfaXNlciByZG1hX2NtIGliX2NtIGl3X2NtIGliX3NhIGliX21hZCBpYl9j b3JlIGliX2FkZHIgaXNjc2lfdGNwIGxpYmlzY3NpX3RjcCBsaWJpc2NzaSBpcDZ0X1JFSkVDVCBu Zl9jb25udHJhY2tfaXB2NiBuZl9kZWZyYWdfaXB2NiBzY3NpX3RyYW5zcG9ydF9pc2NzaSBpcDZ0 YWJsZV9maWx0ZXIgaXA2X3RhYmxlcyB4dF9jb21tZW50IG5mX2Nvbm50cmFja19pcHY0IG5mX2Rl ZnJhZ19pcHY0IHh0X3N0YXRlIG5mX2Nvbm50cmFjayBpcHRfTE9HIHh0X3BoeXNkZXYgZGVsbF93 bWkgc3BhcnNlX2tleW1hcCBzbmRfaGRhX2NvZGVjX2lkdCBkZWxsX2xhcHRvcCBtaWNyb2NvZGUg ZGNkYmFzIHNuZF9oZGFfaW50ZWwgc25kX2hkYV9jb2RlYyBzbmRfaHdkZXAgcjg1MiBzbV9jb21t b24gbmFuZCBuYW5kX2lkcyBzbmRfc2VxIHNuZF9zZXFfZGV2aWNlIGI0NCBuYW5kX2VjYyBhcmM0 IHNuZF9wY20gc3NiIGlUQ09fd2R0IGpveWRldiByNTkyIG10ZCBtZW1zdGljayBtaWkgaTJjX2k4 MDEgaVRDT192ZW5kb3Jfc3VwcG9ydCBpd2wzOTQ1IGl3bF9sZWdhY3kgbWFjODAyMTEgc25kX3Rp bWVyIGNmZzgwMjExIHNuZCByZmtpbGwgc291bmRjb3JlIHNuZF9wYWdlX2FsbG9jIHR1biB4ZW5f Z250YWxsb2MgeGVuX25ldGJhY2sgeGVuX2Jsa2JhY2sgeGVuX2dudGRldiB4ZW5fZXZ0Y2huIHhl bmZzIGJpbmZtdF9taXNjIHNkaGNpX3BjaSBzZGhjaSBtbWNfY29yZSBmaXJld2lyZV9vaGNpIGZp cmV3aXJlX2NvcmUgY3JjX2l0dV90IHdtaSBpOTE1IGRybV9rbXNfaGVscGVyIGRybSBpMmNfYWxn b19iaXQgaTJjX2NvcmUgdmlkZW8gW2xhc3QgdW5sb2FkZWQ6IHNjc2lfd2FpdF9zY2FuXQpbICAx NzkuMTMzNjIwXSBQaWQ6IDMxNTgsIGNvbW06IHhlbmNvbnNvbGVkIFRhaW50ZWQ6IEcgICAgICAg IFcgICAzLjEuMC0wLnJjNi5naXQwLjAuZmMxNy54ODZfNjQgIzEKWyAgMTc5LjEzMzczNV0gQ2Fs bCBUcmFjZToKWyAgMTc5LjEzMzc4Nl0gIFs8ZmZmZmZmZmY4MTRmOWU0ND5dIF9fc2NoZWR1bGVf YnVnKzB4NzUvMHg3YQpbICAxNzkuMTMzODk4XSAgWzxmZmZmZmZmZjgxMDA3NzQ2Pl0gPyB4ZW5f Zm9yY2VfZXZ0Y2huX2NhbGxiYWNrKzB4ZC8weGYKWyAgMTc5LjEzMzk2Ml0gIFs8ZmZmZmZmZmY4 MTA1NmMyOD5dIF9fY29uZF9yZXNjaGVkKzB4MjgvMHgzNApbICAxNzkuMTM0MDE0XSAgWzxmZmZm ZmZmZjgxNTAyODM1Pl0gX2NvbmRfcmVzY2hlZCsweDE5LzB4MjIKWyAgMTc5LjEzNDA2OF0gIFs8 ZmZmZmZmZmY4MTUwMzVmNz5dIG11dGV4X2xvY2tfbmVzdGVkKzB4MmEvMHg0NQpbICAxNzkuMTM0 MTM1XSAgWzxmZmZmZmZmZjgxMGMyNDJjPl0gaXJxX3Jlc2VydmVfaXJxcysweDNjLzB4ODcKWyAg MTc5LjEzNDE2MF0gIFs8ZmZmZmZmZmY4MTBjNGI1OT5dIGlycV9zZXRfY2hpcCsweDU4LzB4NjMK WyAgMTc5LjEzNDE2MF0gIFs8ZmZmZmZmZmY4MTBjNGYxNj5dID8gaGFuZGxlX2Zhc3Rlb2lfaXJx KzB4YjAvMHhiMApbICAxNzkuMTM0MTYwXSAgWzxmZmZmZmZmZjgxMGM1MDZiPl0gaXJxX3NldF9j aGlwX2FuZF9oYW5kbGVyX25hbWUrMHgxZS8weDM1ClsgIDE3OS4xMzQxNjBdICBbPGZmZmZmZmZm ODEyZGEzOTk+XSBiaW5kX2V2dGNobl90b19pcnErMHg1NS8weDgyClsgIDE3OS4xMzQxNjBdICBb PGZmZmZmZmZmODEyZGE0NmU+XSBiaW5kX2V2dGNobl90b19pcnFoYW5kbGVyKzB4MjUvMHg2Mwpb ICAxNzkuMTM0NTYzXSAgWzxmZmZmZmZmZmEwMTFjNGY4Pl0gPyBzZXRfcG9ydF9lbmFibGVkKzB4 MzEvMHgzMSBbeGVuX2V2dGNobl0KWyAgMTc5LjEzNDY0MF0gIFs8ZmZmZmZmZmZhMDExYzZhMj5d IGV2dGNobl9iaW5kX3RvX3VzZXIrMHg1Ni8weDY0IFt4ZW5fZXZ0Y2huXQpbICAxNzkuMTM0NzE5 XSAgWzxmZmZmZmZmZmEwMTFjN2E4Pl0gZXZ0Y2huX2lvY3RsKzB4YzcvMHgyZWYgW3hlbl9ldnRj aG5dClsgIDE3OS4xMzQ3ODVdICBbPGZmZmZmZmZmODExNTFlYjU+XSBkb192ZnNfaW9jdGwrMHg0 NzIvMHg0YjMKWyAgMTc5LjEzNDgzOF0gIFs8ZmZmZmZmZmY4MTE1MWY0Yz5dIHN5c19pb2N0bCsw eDU2LzB4N2EKWyAgMTc5LjEzNDg5MV0gIFs8ZmZmZmZmZmY4MTUwYmM4Mj5dIHN5c3RlbV9jYWxs X2Zhc3RwYXRoKzB4MTYvMHgxYgpbICAxODAuMDA0NTQyXSBjZmc4MDIxMTogV29ybGQgcmVndWxh dG9yeSBkb21haW4gdXBkYXRlZDoKWyAgMTgwLjAwNDYxOV0gY2ZnODAyMTE6ICAgICAoc3RhcnRf ZnJlcSAtIGVuZF9mcmVxIEAgYmFuZHdpZHRoKSwgKG1heF9hbnRlbm5hX2dhaW4sIG1heF9laXJw KQpbICAxODAuMDA0NjUwXSBjZmc4MDIxMTogICAgICgyNDAyMDAwIEtIeiAtIDI0NzIwMDAgS0h6 IEAgNDAwMDAgS0h6KSwgKDMwMCBtQmksIDIwMDAgbUJtKQpbICAxODAuMDA0NjgzXSBjZmc4MDIx MTogICAgICgyNDU3MDAwIEtIeiAtIDI0ODIwMDAgS0h6IEAgMjAwMDAgS0h6KSwgKDMwMCBtQmks IDIwMDAgbUJtKQpbICAxODAuMDA0NzEzXSBjZmc4MDIxMTogICAgICgyNDc0MDAwIEtIeiAtIDI0 OTQwMDAgS0h6IEAgMjAwMDAgS0h6KSwgKDMwMCBtQmksIDIwMDAgbUJtKQpbICAxODAuMDA0NzQz XSBjZmc4MDIxMTogICAgICg1MTcwMDAwIEtIeiAtIDUyNTAwMDAgS0h6IEAgNDAwMDAgS0h6KSwg KDMwMCBtQmksIDIwMDAgbUJtKQpbICAxODAuMDA0Nzc0XSBjZmc4MDIxMTogICAgICg1NzM1MDAw IEtIeiAtIDU4MzUwMDAgS0h6IEAgNDAwMDAgS0h6KSwgKDMwMCBtQmksIDIwMDAgbUJtKQpbICAx ODAuMDA4MTU2XSBjZmc4MDIxMTogQ2FsbGluZyBDUkRBIGZvciBjb3VudHJ5OiBVUwpTSU9DU0lG TVRVOiBObyBzdWNoIGRldmljZQpTdGFydGluZyAvZXRjL3JjLmxvY2FsIENvbXBhdGliaWxpdHkg ZmFpbGVkLCBzZWUgJ3N5c3RlbWN0bCBzdGF0dXMgcmMtbG9jYWwuc2VydmljZScgZm9yIGRldGFp bHMuClN0YXJ0aW5nIFdhaXQgZm9yIFBseW1vdXRoIEJvb3QgU2NyZWVuIHRvIFF1aXQuLi4KWyAg MTgwLjI4NzgxN10gY2ZnODAyMTE6IFJlZ3VsYXRvcnkgZG9tYWluIGNoYW5nZWQgdG8gY291bnRy eTogVVMKWyAgMTgwLjI4Nzg5N10gY2ZnODAyMTE6ICAgICAoc3RhcnRfZnJlcSAtIGVuZF9mcmVx IEAgYmFuZHdpZHRoKSwgKG1heF9hbnRlbm5hX2dhaW4sIG1heF9laXJwKQpbICAxODAuMjg3OTMw XSBjZmc4MDIxMTogICAgICgyNDAyMDAwIEtIeiAtIDI0NzIwMDAgS0h6IEAgNDAwMDAgS0h6KSwg KDMwMCBtQmksIDI3MDAgbUJtKQpbICAxODAuMjg3OTYxXSBjZmc4MDIxMTogICAgICg1MTcwMDAw IEtIeiAtIDUyNTAwMDAgS0h6IEAgNDAwMDAgS0h6KSwgKDMwMCBtQmksIDE3MDAgbUJtKQpbICAx ODAuMjg3OTkyXSBjZmc4MDIxMTogICAgICg1MjUwMDAwIEtIeiAtIDUzMzAwMDAgS0h6IEAgNDAw MDAgS0h6KSwgKDMwMCBtQmksIDIwMDAgbUJtKQpbICAxODAuMjg4MDIyXSBjZmc4MDIxMTogICAg ICg1NDkwMDAwIEtIeiAtIDU2MDAwMDAgS0h6IEAgNDAwMDAgS0h6KSwgKDMwMCBtQmksIDIwMDAg bUJtKQpbICAxODAuMjg4MDU0XSBjZmc4MDIxMTogICAgICg1NjUwMDAwIEtIeiAtIDU3MTAwMDAg S0h6IEAgNDAwMDAgS0h6KSwgKDMwMCBtQmksIDIwMDAgbUJtKQpbICAxODAuMjg4MDg1XSBjZmc4 MDIxMTogICAgICg1NzM1MDAwIEtIeiAtIDU4MzUwMDAgS0h6IEAgNDAwMDAgS0h6KSwgKDMwMCBt QmksIDMwMDAgbUJtKQpTdGFydGluZyBEaXNwbGF5IE1hbmFnZXIuLi4KU3RhcnRlZCBEaXNwbGF5 IE1hbmFnZXIuCgpXZWxjb21lIHRvIEZlZG9yYSByZWxlYXNlIDE1IChMb3ZlbG9jaykhCgpTdGFy dGluZyBCb290dXAgaGFjay4uLgpTdGFydGluZyBMb2FkIGxlZ2FjeSBtb2R1bGUgY29uZmlndXJh dGlvbi4uLgpTdGFydGluZyBTeXNsb2cgS2VybmVsIExvZyBCdWZmZXIgQnJpZGdlLi4uClN0YXJ0 ZWQgU3lzbG9nIEtlcm5lbCBMb2cgQnVmZmVyIEJyaWRnZS4KU3RhcnRpbmcgU2V0IFVwIEFkZGl0 aW9uYWwgQmluYXJ5IEZvcm1hdHMuLi4KU3RhcnRpbmcgQXBwbHkgS2VybmVsIFZhcmlhYmxlcy4u LgpTdGFydGluZyB1ZGV2IEtlcm5lbCBEZXZpY2UgTWFuYWdlci4uLgpTdGFydGluZyBSZW1vdW50 IEFQSSBWRlMuLi4KU3RhcnRpbmcgTWVkaWEgRGlyZWN0b3J5Li4uClN0YXJ0aW5nIFJ1bnRpbWUg RGlyZWN0b3J5Li4uClN0YXJ0ZWQgRmlsZSBTeXN0ZW0gQ2hlY2sgb24gUm9vdCBEZXZpY2UuClN0 YXJ0aW5nIFJlbW91bnQgUm9vdCBGUy4uLgpTdGFydGluZyBMb2NrIERpcmVjdG9yeS4uLgpTdGFy dGluZyBTZXR1cCBWaXJ0dWFsIENvbnNvbGUuLi4KU3RhcnRlZCBCb290dXAgaGFjay4KU3RhcnRl ZCBBcHBseSBLZXJuZWwgVmFyaWFibGVzLgpTdGFydGVkIFJ1bnRpbWUgRGlyZWN0b3J5LgpTdGFy dGVkIE1lZGlhIERpcmVjdG9yeS4KU3RhcnRpbmcgQXJiaXRyYXJ5IEV4ZWN1dGFibGUgRmlsZSBG b3JtYXRzIEZpbGUgU3lzdGVtLi4uClN0YXJ0aW5nIFN0ZGlvIFN5c2xvZyBCcmlkZ2UuLi4KU3Rh cnRlZCBTdGRpbyBTeXNsb2cgQnJpZGdlLgpTdGFydGVkIFJlbW91bnQgUm9vdCBGUy4KU3RhcnRl ZCBMb2NrIERpcmVjdG9yeS4KU3RhcnRpbmcgQ29uZmlndXJlIHJlYWQtb25seSByb290IHN1cHBv cnQuLi4KU3RhcnRlZCBSZW1vdW50IEFQSSBWRlMuClN0YXJ0ZWQgQXJiaXRyYXJ5IEV4ZWN1dGFi bGUgRmlsZSBGb3JtYXRzIEZpbGUgU3lzdGVtLgpTdGFydGVkIFNldCBVcCBBZGRpdGlvbmFsIEJp bmFyeSBGb3JtYXRzLgpTdGFydGVkIENvbmZpZ3VyZSByZWFkLW9ubHkgcm9vdCBzdXBwb3J0LgpT dGFydGVkIFNldHVwIFZpcnR1YWwgQ29uc29sZS4KU3RhcnRlZCB1ZGV2IEtlcm5lbCBEZXZpY2Ug TWFuYWdlci4KU3RhcnRpbmcgdWRldiBDb2xkcGx1ZyBhbGwgRGV2aWNlcy4uLgpTdGFydGluZyBM b2FkIGxlZ2FjeSBtb2R1bGUgY29uZmlndXJhdGlvbiBmYWlsZWQsIHNlZSAnc3lzdGVtY3RsIHN0 YXR1cyBmZWRvcmEtbG9hZG1vZHVsZXMuc2VydmljZScgZm9yIGRldGFpbHMuClN0YXJ0ZWQgdWRl diBDb2xkcGx1ZyBhbGwgRGV2aWNlcy4KU3RhcnRpbmcgdWRldiBXYWl0IGZvciBDb21wbGV0ZSBE ZXZpY2UgSW5pdGlhbGl6YXRpb24uLi4KU3RhcnRlZCB1ZGV2IEtlcm5lbCBEZXZpY2UgTWFuYWdl ci4KU3RhcnRpbmcgL2Rldi9tYXBwZXIvdmdfaW5zcDY0MDAtbHZfc3dhcC4uLgpTdGFydGVkIC9k ZXYvbWFwcGVyL3ZnX2luc3A2NDAwLWx2X3N3YXAuClN0YXJ0aW5nIEZpbGUgU3lzdGVtIENoZWNr IG9uIC9kZXYvZGlzay9ieS11dWlkLzcxMTVmMzhlLTI4MjUtNGEzZS1iZjRiLTA0OWY0YTRkN2Uw MS4uLgpTdGFydGluZyBIdWdlIFBhZ2VzIEZpbGUgU3lzdGVtLi4uClN0YXJ0ZWQgSHVnZSBQYWdl cyBGaWxlIFN5c3RlbS4KU3RhcnRpbmcgUE9TSVggTWVzc2FnZSBRdWV1ZSBGaWxlIFN5c3RlbS4u LgpTdGFydGVkIHVkZXYgV2FpdCBmb3IgQ29tcGxldGUgRGV2aWNlIEluaXRpYWxpemF0aW9uLgpT dGFydGVkIFBPU0lYIE1lc3NhZ2UgUXVldWUgRmlsZSBTeXN0ZW0uClN0YXJ0aW5nIFdhaXQgZm9y IHN0b3JhZ2Ugc2Nhbi4uLgpzeXN0ZW1kLWZzY2tbNjM3XTogL2Rldi9zZGEyOiByZWNvdmVyaW5n IGpvdXJuYWwKU3RhcnRlZCBTaG93IFBseW1vdXRoIEJvb3QgU2NyZWVuLgpzeXN0ZW1kLWZzY2tb NjM3XTogL2Rldi9zZGEyOiBjbGVhbiwgNjAvNTEyMDAgZmlsZXMsIDEzMDcwNS8yMDQ4MDAgYmxv Y2tzClN0YXJ0ZWQgRmlsZSBTeXN0ZW0gQ2hlY2sgb24gL2Rldi9kaXNrL2J5LXV1aWQvNzExNWYz OGUtMjgyNS00YTNlLWJmNGItMDQ5ZjRhNGQ3ZTAxLgpTdGFydGVkIFdhaXQgZm9yIHN0b3JhZ2Ug c2Nhbi4KU3RhcnRpbmcgSW5pdGlhbGl6ZSBzdG9yYWdlIHN1YnN5c3RlbXMgKFJBSUQsIExWTSwg ZXRjLikuLi4KU3RhcnRpbmcgL2Jvb3QuLi4KU3RhcnRlZCAvYm9vdC4KU3RhcnRlZCBJbml0aWFs aXplIHN0b3JhZ2Ugc3Vic3lzdGVtcyAoUkFJRCwgTFZNLCBldGMuKS4KU3RhcnRpbmcgSW5pdGlh bGl6ZSBzdG9yYWdlIHN1YnN5c3RlbXMgKFJBSUQsIExWTSwgZXRjLikuLi4KU3RhcnRlZCBJbml0 aWFsaXplIHN0b3JhZ2Ugc3Vic3lzdGVtcyAoUkFJRCwgTFZNLCBldGMuKS4KU3RhcnRlZCBSZWNv bmZpZ3VyZSB0aGUgc3lzdGVtIG9uIGFkbWluaXN0cmF0b3IgcmVxdWVzdC4KU3RhcnRpbmcgRW5h YmxlIGFsbCBkZXRlY3RlZCBzd2FwIHBhcnRpdGlvbnMuLi4KU3RhcnRlZCBNYXJrIHRoZSBuZWVk IHRvIHJlbGFiZWwgYWZ0ZXIgcmVib290LgpTdGFydGVkIFJlbGFiZWwgYWxsIGZpbGVzeXN0ZW1z LCBpZiBuZWNlc3NhcnkuClN0YXJ0aW5nIFJlY3JlYXRlIFZvbGF0aWxlIEZpbGVzIGFuZCBEaXJl Y3Rvcmllcy4uLgpTdGFydGluZyBMb2FkIFJhbmRvbSBTZWVkLi4uClN0YXJ0ZWQgRW5hYmxlIGFs bCBkZXRlY3RlZCBzd2FwIHBhcnRpdGlvbnMuClN0YXJ0ZWQgTG9hZCBSYW5kb20gU2VlZC4KU3Rh cnRlZCBUZWxsIFBseW1vdXRoIFRvIFdyaXRlIE91dCBSdW50aW1lIERhdGEuClN0YXJ0ZWQgUmVj cmVhdGUgVm9sYXRpbGUgRmlsZXMgYW5kIERpcmVjdG9yaWVzLgpTdGFydGluZyBDb25zb2xlIFN5 c3RlbSBTdGFydHVwIExvZ2dpbmcuLi4KU3RhcnRpbmcgUmVzdG9yZSBTb3VuZCBDYXJkIFN0YXRl Li4uClN0YXJ0aW5nIEJvb3R1cCB1bmhhY2suLi4KU3RhcnRpbmcgSm9iIHNwb29saW5nIHRvb2xz Li4uClN0YXJ0ZWQgSm9iIHNwb29saW5nIHRvb2xzLgpTdGFydGluZyBMU0I6IHN0YXJ0IGFuZCBz dG9wIGlwdGFibGVzIGZpcmV3YWxsLi4uClN0YXJ0aW5nIEFCUlQgQXV0b21hdGVkIEJ1ZyBSZXBv cnRpbmcgVG9vbC4uLgpTdGFydGluZyBMU0I6IFN0YXJ0cyBhbmQgc3RvcHMgbG9naW4gaVNDU0kg ZGFlbW9uLi4uLgpTdGFydGluZyBMU0I6IENvbmV4YW50IEhTRiBzb2Z0bW9kZW0uLi4KU3RhcnRp bmcgTFNCOiBzdGFydCBhbmQgc3RvcCBpcDZ0YWJsZXMgZmlyZXdhbGwuLi4KU3RhcnRpbmcgQ29u ZXhhbnQgSFNGIHNvZnRtb2RlbQppcHRhYmxlczogQXBwbHlpbmcgZmlyZXdhbGwgcnVsZXM6IFN0 YXJ0aW5nIENvbnNvbGUgTW91c2UgbWFuYWdlci4uLgpTdGFydGluZyBMU0I6IE1vbml0b3Jpbmcg b2YgTFZNMiBtaXJyb3JzLCBzbmFwc2hvdHMgZXRjLiB1c2luZyBkbWV2ZW50ZCBvciBwcm9ncmVz cyBwb2xsaW5nLi4uClN0YXJ0aW5nIEF2YWhpIG1ETlMvRE5TLVNEIFN0YWNrLi4uClN0YXJ0aW5n IFN5c3RlbSBMb2dnaW5nIFNlcnZpY2UuLi4KU3RhcnRpbmcgaXJxYmFsYW5jZSBkYWVtb24uLi4K U3RhcnRpbmcgQ29tbWFuZCBTY2hlZHVsZXIuLi4KU3RhcnRlZCBDb21tYW5kIFNjaGVkdWxlci4K U3RhcnRpbmcgTWFjaGluZSBDaGVjayBFeGNlcHRpb24gTG9nZ2luZyBEYWVtb24uLi4KU3RhcnRp bmcgRC1CdXMgU3lzdGVtIE1lc3NhZ2UgQnVzLi4uClN0YXJ0ZWQgQ29uc29sZSBTeXN0ZW0gU3Rh cnR1cCBMb2dnaW5nLgpbICBPSyAgXQpTdGFydGVkIFJlc3RvcmUgU291bmQgQ2FyZCBTdGF0ZS4K U3RhcnRlZCBCb290dXAgdW5oYWNrLgpTdGFydGVkIENvbnNvbGUgTW91c2UgbWFuYWdlci4KU3Rv cHBpbmcgU3lzbG9nIEtlcm5lbCBMb2cgQnVmZmVyIEJyaWRnZS4uLgpTdG9wcGVkIFN5c2xvZyBL ZXJuZWwgTG9nIEJ1ZmZlciBCcmlkZ2UuClN0YXJ0ZWQgU3lzdGVtIExvZ2dpbmcgU2VydmljZS4K U3RhcnRlZCBMU0I6IHN0YXJ0IGFuZCBzdG9wIGlwdGFibGVzIGZpcmV3YWxsLgpTdGFydGVkIGly cWJhbGFuY2UgZGFlbW9uLgppcDZ0YWJsZXM6IEFwcGx5aW5nIGZpcmV3YWxsIHJ1bGVzOiBTdGFy dGVkIEQtQnVzIFN5c3RlbSBNZXNzYWdlIEJ1cy4KU3RhcnRpbmcgaXNjc2lkOiBbICBPSyAgXQpT dGFydGluZyBtb25pdG9yaW5nIGZvciBWRyB2Z19pbnNwNjQwMDoKTm8gcHJlLWJ1aWx0IG1vZHVs ZXMgZm9yOiBGZWRvcmEtMTUgbGludXgtMy4xLjAtMC5yYzYuZ2l0MC4wLmZjMTcueDg2XzY0IHg4 Nl82NC1TTVAKClRyeWluZyB0byBhdXRvbWF0aWNhbGx5IGJ1aWxkIHRoZSBkcml2ZXIgbW9kdWxl cy4uLgoodGhpcyByZXF1aXJlcyBhIEMgY29tcGlsZXIgYW5kIHByb3BlciBrZXJuZWwgc291cmNl cyB0byBiZSBpbnN0YWxsZWQpCiAgMiBsb2dpY2FsIHZvbHVtZShzKSBpbiB2b2x1bWUgZ3JvdXAg InZnX2luc3A2NDAwIiBtb25pdG9yZWQKU3RhcnRlZCBMU0I6IHN0YXJ0IGFuZCBzdG9wIGlwNnRh YmxlcyBmaXJld2FsbC4KU3RhcnRlZCBNYWNoaW5lIENoZWNrIEV4Y2VwdGlvbiBMb2dnaW5nIERh ZW1vbi4KU3RhcnRlZCBBdmFoaSBtRE5TL0ROUy1TRCBTdGFjay4KU3RhcnRlZCBBQlJUIEF1dG9t YXRlZCBCdWcgUmVwb3J0aW5nIFRvb2wuClsgIE9LICBdClN0YXJ0ZWQgTFNCOiBNb25pdG9yaW5n IG9mIExWTTIgbWlycm9ycywgc25hcHNob3RzIGV0Yy4gdXNpbmcgZG1ldmVudGQgb3IgcHJvZ3Jl c3MgcG9sbGluZy4KCkJ1aWxkaW5nIG1vZHVsZXMgZm9yIGtlcm5lbCAzLjEuMC0wLnJjNi5naXQw LjAuZmMxNy54ODZfNjQsIHVzaW5nIHNvdXJjZSBkaXJlY3RvcnkKL2xpYi9tb2R1bGVzLzMuMS4w LTAucmM2LmdpdDAuMC5mYzE3Lng4Nl82NC9idWlsZC4gUGxlYXNlIHdhaXQuLi4KWyAgT0sgIF0K U3RhcnRlZCBMU0I6IFN0YXJ0cyBhbmQgc3RvcHMgbG9naW4gaVNDU0kgZGFlbW9uLi4KU3RhcnRp bmcgU1lTVjogc3RhcnQgYW5kIHN0b3AgSVNETiBzZXJ2aWNlcy4uLgpTdGFydGVkIFNZU1Y6IHN0 YXJ0IGFuZCBzdG9wIElTRE4gc2VydmljZXMuClN0YXJ0aW5nIExTQjogUG9ydCByZXNlcnZhdGlv biB1dGlsaXR5Li4uClN0YXJ0aW5nIHBvcnRyZXNlcnZlOiBbICBPSyAgXQpTdGFydGVkIExTQjog UG9ydCByZXNlcnZhdGlvbiB1dGlsaXR5LgpCcmluZ2luZyB1cCBsb29wYmFjayBpbnRlcmZhY2U6 ICBbICBPSyAgXQpCcmluZ2luZyB1cCBpbnRlcmZhY2UgYm9uZDA6ICBFUlJPUiAgICA6IFsvZXRj L3N5c2NvbmZpZy9uZXR3b3JrLXNjcmlwdHMvaWZ1cC1ldGhdIERldmljZSBldGgxIGRvZXMgbm90 IHNlZW0gdG8gYmUgcHJlc2VudCwgZGVsYXlpbmcgaW5pdGlhbGl6YXRpb24uClsgIE9LICBdCkJy aW5naW5nIHVwIGludGVyZmFjZSB4ZW5icjA6CkRldGVybWluaW5nIElQIGluZm9ybWF0aW9uIGZv ciB4ZW5icjAuLi4gZG9uZS4KWyAgT0sgIF0KU3RhcnRlZCBMU0I6IEJyaW5nIHVwL2Rvd24gbmV0 d29ya2luZy4KU3RhcnRpbmcgL3dpbmRvd3MvQy4uLgpTdGFydGluZyAvd2luZG93cy9EaWdpLi4u ClN0YXJ0aW5nIFNldCB0aW1lIHZpYSBOVFAuLi4KU3RhcnRlZCAvd2luZG93cy9EaWdpLgpTdGFy dGVkIC93aW5kb3dzL0MuClN0YXJ0ZWQgU2V0IHRpbWUgdmlhIE5UUC4KU3RhcnRpbmcgTmV0d29y ayBUaW1lIFNlcnZpY2UuLi4KU3RhcnRlZCBOZXR3b3JrIFRpbWUgU2VydmljZS4KCkVSUk9SOiBN b2R1bGUgYnVpbGQgZmFpbGVkIQpQbGVhc2UgZXhhbWluZSB0aGUgbG9nIGZpbGUgIi9ldGMvaHNm bW9kZW0vbG9nL2J1aWxkbG9nLTIwMTEwOTEzMTkwNzAyLnR4dCIgdG8gZGV0ZXJtaW5lIHdoeS4K U3RhcnRlZCBMU0I6IENvbmV4YW50IEhTRiBzb2Z0bW9kZW0uClN0YXJ0aW5nIFNZU1Y6IFRoaXMg c3RhcnRzIHRoZSBMaW51eCBBdWRpdGluZyBTeXN0ZW0gRGFlbW9uLCB3aGljaCBjb2xsZWN0cyBz ZWN1cml0eSByZWxhdGVkIGV2ZW50cyBpbiBhIGRlZGljYXRlZCBhdWRpdCBsb2cuIElmIHRoaXMg ZGFlbW9uIGlzIHR1cm5lZCBvZmYsIGF1ZGl0IGV2ZW50cyB3aWxsIGJlIHNlbnQgdG8gc3lzbG9n Li4uLgpTdGFydGluZyBhdWRpdGQ6IFsgIE9LICBdClN0YXJ0ZWQgU1lTVjogVGhpcyBzdGFydHMg dGhlIExpbnV4IEF1ZGl0aW5nIFN5c3RlbSBEYWVtb24sIHdoaWNoIGNvbGxlY3RzIHNlY3VyaXR5 IHJlbGF0ZWQgZXZlbnRzIGluIGEgZGVkaWNhdGVkIGF1ZGl0IGxvZy4gSWYgdGhpcyBkYWVtb24g aXMgdHVybmVkIG9mZiwgYXVkaXQgZXZlbnRzIHdpbGwgYmUgc2VudCB0byBzeXNsb2cuLgpTdGFy dGluZyBMU0I6IFN0YXJ0cyBhbmQgc3RvcHMgbG9naW4gYW5kIHNjYW5uaW5nIG9mIGlTQ1NJIGRl dmljZXMuLi4uClN0YXJ0aW5nIFNZU1Y6IFRoZSBycGNiaW5kIHV0aWxpdHkgaXMgYSBzZXJ2ZXIg dGhhdCBjb252ZXJ0cyBSUEMgcHJvZ3JhbSBudW1iZXJzIGludG8gdW5pdmVyc2FsIGFkZHJlc3Nl cy4gSXQgbXVzdCBiZSBydW5uaW5nIG9uIHRoZSBob3N0IHRvIGJlIGFibGUgdG8gbWFrZSBSUEMg Y2FsbHMgb24gYSBzZXJ2ZXIgb24gdGhhdCBtYWNoaW5lLi4uLgpTdGFydGluZyBpc2NzaTogU3Rh cnRpbmcgcnBjYmluZDogWyAgT0sgIF0KU3RhcnRlZCBTWVNWOiBUaGUgcnBjYmluZCB1dGlsaXR5 IGlzIGEgc2VydmVyIHRoYXQgY29udmVydHMgUlBDIHByb2dyYW0gbnVtYmVycyBpbnRvIHVuaXZl cnNhbCBhZGRyZXNzZXMuIEl0IG11c3QgYmUgcnVubmluZyBvbiB0aGUgaG9zdCB0byBiZSBhYmxl IHRvIG1ha2UgUlBDIGNhbGxzIG9uIGEgc2VydmVyIG9uIHRoYXQgbWFjaGluZS4uClN0YXJ0aW5n IExTQjogTW91bnQgYW5kIHVubW91bnQgbmV0d29yayBmaWxlc3lzdGVtcy4uLi4KWyAgT0sgIF0K U3RhcnRpbmcgTFNCOiBTdGFydHMgdGhlIFJQQ1NFQyBHU1MgY2xpZW50IGRhZW1vbi4uLgpTdGFy dGluZyBMU0I6IEd1YXJkLi4uClN0YXJ0aW5nIExTQjogU3RhcnQgYW5kIHN0b3AgdGhlIE1EIHNv ZnR3YXJlIFJBSUQgbW9uaXRvci4uLgpTdGFydGluZyBMU0I6IFN0YXJ0IHVwIHRoZSBORlMgZmls ZSBsb2NraW5nIHNldmljZS4uLgpTdGFydGluZyBMU0I6IHN0YXJ0IGFuZCBzdG9wIHdwYV9zdXBw bGljYW50Li4uClN0YXJ0aW5nIExTQjogU3RhcnQgdXAgdGhlIE5GUyBzZXJ2ZXIgc2V2aWNlLi4u ClN0YXJ0aW5nIExTQjogVGhlIENVUFMgc2NoZWR1bGVyLi4uClN0YXJ0aW5nIExTQjogU3RhcnRz IHRoZSBSUENTRUMgR1NTIHNlcnZlciBkYWVtb24uLi4KU3RhcnRpbmcgTFNCOiBTdGFydHMgdGhl IE5GU3Y0IGlkIG1hcHBpbmcgZGFlbW9uLi4uClN0YXJ0ZWQgTFNCOiBTdGFydHMgYW5kIHN0b3Bz IGxvZ2luIGFuZCBzY2FubmluZyBvZiBpU0NTSSBkZXZpY2VzLi4KU3RhcnRlZCBMU0I6IFN0YXJ0 IGFuZCBzdG9wIHRoZSBNRCBzb2Z0d2FyZSBSQUlEIG1vbml0b3IuClN0YXJ0aW5nIHdwYV9zdXBw bGljYW50OiAvZXRjL3dwYV9zdXBwbGljYW50L3dwYV9zdXBwbGljYW50LmNvbmYsIC1pd2xhbjAs IC1Ed2V4dFN0YXJ0aW5nIGN1cHM6IE1vdW50aW5nIENJRlMgZmlsZXN5c3RlbXM6ICBTdGFydGVk IExTQjogU3RhcnRzIHRoZSBSUENTRUMgR1NTIHNlcnZlciBkYWVtb24uClsgIE9LICBdCk1vdW50 aW5nIG90aGVyIGZpbGVzeXN0ZW1zOiAgU3RhcnRlZCBMU0I6IFN0YXJ0cyB0aGUgUlBDU0VDIEdT UyBjbGllbnQgZGFlbW9uLgptb3VudDogc3lzZnMgYWxyZWFkeSBtb3VudGVkIG9yIC9zeXMgYnVz eQptb3VudDogYWNjb3JkaW5nIHRvIG10YWIsIC9zeXMgaXMgYWxyZWFkeSBtb3VudGVkIG9uIC9z eXMKU3RhcnRlZCBMU0I6IE1vdW50IGFuZCB1bm1vdW50IG5ldHdvcmsgZmlsZXN5c3RlbXMuLgpT dGFydGluZyBMU0I6IERhZW1vbiB0byBhY2Nlc3MgYSBzbWFydCBjYXJkIHVzaW5nIFBDL1NDLi4u ClN0YXJ0aW5nIFBlcm1pdCBVc2VyIFNlc3Npb25zLi4uClN0YXJ0aW5nIEFWSVJBIEFudGlWaXIg V29ya3N0YXRpb24gUGVyc29uYWwgLi4uClN0YXJ0aW5nIE5GUyBzdGF0ZDogU3RhcnRlZCBQZXJt aXQgVXNlciBTZXNzaW9ucy4KWyAgT0sgIF0KU3RhcnRpbmcgUEMvU0Mgc21hcnQgY2FyZCBkYWVt b24gKHBjc2NkKTogU3RhcnRpbmcgcnBjc3ZjZ3NzZCAodmlhIHN5c3RlbWN0bCk6ICBTdGFydGVk IExTQjogU3RhcnRzIHRoZSBSUENTRUMgR1NTIHNlcnZlciBkYWVtb24uClsgIE9LICBdClsgIE9L ICBdClsgIE9LICBdClN0YXJ0ZWQgTFNCOiBTdGFydCB1cCB0aGUgTkZTIGZpbGUgbG9ja2luZyBz ZXZpY2UuClN0YXJ0ZWQgTFNCOiBUaGUgQ1VQUyBzY2hlZHVsZXIuClsgIE9LICBdClN0YXJ0ZWQg TFNCOiBzdGFydCBhbmQgc3RvcCB3cGFfc3VwcGxpY2FudC4KU3RhcnRlZCBMU0I6IERhZW1vbiB0 byBhY2Nlc3MgYSBzbWFydCBjYXJkIHVzaW5nIFBDL1NDLgpTdGFydGluZyBSUEMgaWRtYXBkOiBT dGFydGluZyBORlMgc2VydmljZXM6ICBleHBvcnRmczogc2NhbmRpciAvZXRjL2V4cG9ydHMuZDog Tm8gc3VjaCBmaWxlIG9yIGRpcmVjdG9yeQoKWyAgT0sgIF0KU3RhcnRpbmcgTkZTIHF1b3Rhczog WyAgT0sgIF0KWyAgT0sgIF0KU3RhcnRpbmcgTkZTIGRhZW1vbjogU3RhcnRlZCBMU0I6IFN0YXJ0 cyB0aGUgTkZTdjQgaWQgbWFwcGluZyBkYWVtb24uClN0YXJ0aW5nOiBhdmd1YXJkLmJpbgpbICBP SyAgXQpTdGFydGluZyBORlMgbW91bnRkOiBbICBPSyAgXQpTdGFydGVkIExTQjogU3RhcnQgdXAg dGhlIE5GUyBzZXJ2ZXIgc2V2aWNlLgpXYXJuaW5nOiBObyBkYXp1a28gbW9kdWxlIGF2YWlsYWJs ZSwgb24tYWNjZXNzIHByb3RlY3Rpb24gZGlzYWJsZWQuClN0YXJ0ZWQgTFNCOiBHdWFyZC4KU3Rh cnRpbmcgU1lTVjogRW5hYmxlIGRhaWx5IHJ1biBvZiB5dW0sIGEgcHJvZ3JhbSB1cGRhdGVyLi4u LgpFbmFibGluZyBuaWdodGx5IHl1bSB1cGRhdGU6IFsgIE9LICBdClN0YXJ0ZWQgU1lTVjogRW5h YmxlIGRhaWx5IHJ1biBvZiB5dW0sIGEgcHJvZ3JhbSB1cGRhdGVyLi4KU3RhcnRpbmcgTFNCOiBJ bnN0YWxscyBjb3JlZHVtcCBoYW5kbGVyIHdoaWNoIHNhdmVzIHNlZ2ZhdWx0IGRhdGEuLi4KU3Rh cnRpbmcgTFNCOiBTdGFydCB1cCB0aGUgT3BlblNTSCBzZXJ2ZXIgZGFlbW9uLi4uClN0YXJ0aW5n IExTQjogc3RhcnQgYW5kIHN0b3Agc2VuZG1haWwuLi4KU3RhcnRpbmcgTFNCOiBzdGFydCBhbmQg c3RvcCBrc20uLi4KU3RhcnRpbmcgTFNCOiB0dW5lIHRoZSBzcGVlZCBvZiBrc20uLi4KU3RhcnRp bmcgc3NoZDogU3RhcnRpbmcga3NtdHVuZWQ6IFN0YXJ0aW5nIGtzbTogWyAgT0sgIF0KU3RhcnRl ZCBMU0I6IHN0YXJ0IGFuZCBzdG9wIGtzbS4KU3RhcnRpbmcgc2VuZG1haWw6IFN0YXJ0ZWQgTFNC OiBJbnN0YWxscyBjb3JlZHVtcCBoYW5kbGVyIHdoaWNoIHNhdmVzIHNlZ2ZhdWx0IGRhdGEuClsg IE9LICBdClN0YXJ0ZWQgTFNCOiB0dW5lIHRoZSBzcGVlZCBvZiBrc20uClsgIE9LICBdClN0YXJ0 ZWQgTFNCOiBTdGFydCB1cCB0aGUgT3BlblNTSCBzZXJ2ZXIgZGFlbW9uLgpbICBPSyAgXQpTdGFy dGluZyBzbS1jbGllbnQ6IFsgIE9LICBdClN0YXJ0ZWQgTFNCOiBzdGFydCBhbmQgc3RvcCBzZW5k bWFpbC4KU3RhcnRpbmcgU1lTVjogRW5hYmxlIG1vbnRobHkgdXBkYXRlIG9mIFNtb2x0Li4uCkVu YWJsaW5nIG1vbnRobHkgU21vbHQgY2hlY2tpbjogWyAgT0sgIF0KU3RhcnRlZCBTWVNWOiBFbmFi bGUgbW9udGhseSB1cGRhdGUgb2YgU21vbHQuClN0YXJ0aW5nIExTQjogc3RhcnR8c3RvcHxyZXN0 YXJ0fHRyeS1yZXN0YXJ0fHN0YXR1c3xmb3JjZS1yZWxvYWQgdm5jc2VydmVyLi4uClN0YXJ0aW5n IFNZU1Y6IFN0YXJ0cyBhbmQgc3RvcHMgdGhlIFNhbWJhIHNtYmQgYW5kIG5tYmQgZGFlbW9ucyB1 c2VkIHRvIHByb3ZpZGUgU01CIG5ldHdvcmsgc2VydmljZXMuLi4uClN0YXJ0aW5nIFNZU1Y6IFN0 YXJ0cyBhbmQgc3RvcHMgdGhlIFNhbWJhIHNtYmQgZGFlbW9uIHVzZWQgdG8gcHJvdmlkZSBTTUIg bmV0d29yayBzZXJ2aWNlcy4uLi4KU3RhcnRpbmcgVk5DIHNlcnZlcjogMTpqaW1iIFN0YXJ0aW5n IE5NQiBzZXJ2aWNlczogU3RhcnRpbmcgU01CIHNlcnZpY2VzOiBbICBPSyAgXQpTdGFydGVkIFNZ U1Y6IFN0YXJ0cyBhbmQgc3RvcHMgdGhlIFNhbWJhIHNtYmQgYW5kIG5tYmQgZGFlbW9ucyB1c2Vk IHRvIHByb3ZpZGUgUwpTdGFydGluZyBXYWl0IGZvciBQbHltb3V0aCBCb290IFNjcmVlbiB0byBR dWl0Li4uClN0YXJ0aW5nIERpc3BsYXkgTWFuYWdlci4uLgpTdGFydGVkIERpc3BsYXkgTWFuYWdl ci4KWyAgT0sgIF0KCkZlZG9yYSByZWxlYXNlIDE1IChMb3ZlbG9jaykKS2VybmVsIDMuMS4wLTAu cmM2LmdpdDAuMC5mYzE3Lng4Nl82NCBvbiBhbiB4ODZfNjQgKGh2YzApCgppbnNwNjQwMCBsb2dp bjogWyAgT0sgIF0KU3RhcnRpbmcgbGlidmlydGQgZGFlbW9uOiBbICBPSyAgXQpbICAyMDQuNzM4 ODY5XSBjYWxsaW5nICBpcHRhYmxlX21hbmdsZV9pbml0KzB4MC8weDEwMDAgW2lwdGFibGVfbWFu Z2xlXSBAIDM2MDYKWyAgMjA0LjczOTE1M10gaW5pdGNhbGwgaXB0YWJsZV9tYW5nbGVfaW5pdCsw eDAvMHgxMDAwIFtpcHRhYmxlX21hbmdsZV0gcmV0dXJuZWQgMCBhZnRlciAxOTYgdXNlY3MKWyAg MjA0Ljk3NTc1N10gY2FsbGluZyAgY2hlY2tzdW1fdGdfaW5pdCsweDAvMHgxMDAwIFt4dF9DSEVD S1NVTV0gQCAzNjEzClsgIDIwNC45NzU5NDJdIGluaXRjYWxsIGNoZWNrc3VtX3RnX2luaXQrMHgw LzB4MTAwMCBbeHRfQ0hFQ0tTVU1dIHJldHVybmVkIDAgYWZ0ZXIgNTIgdXNlY3MKWyAgMjA1Ljc3 NzY5Nl0gY2FsbGluZyAgbmZfbmF0X2luaXQrMHgwLzB4MTAwMCBbbmZfbmF0XSBAIDM2MjYKWyAg MjA1Ljc3NzgzMV0gaW5pdGNhbGwgbmZfbmF0X2luaXQrMHgwLzB4MTAwMCBbbmZfbmF0XSByZXR1 cm5lZCAwIGFmdGVyIDU2IHVzZWNzClsgIDIwNS43OTc1NTddIGNhbGxpbmcgIG5mX25hdF9zdGFu ZGFsb25lX2luaXQrMHgwLzB4ZmEyIFtpcHRhYmxlX25hdF0gQCAzNjI2ClsgIDIwNS43OTkxMjRd IGluaXRjYWxsIG5mX25hdF9zdGFuZGFsb25lX2luaXQrMHgwLzB4ZmEyIFtpcHRhYmxlX25hdF0g cmV0dXJuZWQgMCBhZnRlciAxNDQ3IHVzZWNzClsgIDIwNS45MzA3MjVdIGNhbGxpbmcgIG1hc3F1 ZXJhZGVfdGdfaW5pdCsweDAvMHgxMDAwIFtpcHRfTUFTUVVFUkFERV0gQCAzNjI4ClsgIDIwNS45 MzA4MjBdIGluaXRjYWxsIG1hc3F1ZXJhZGVfdGdfaW5pdCsweDAvMHgxMDAwIFtpcHRfTUFTUVVF UkFERV0gcmV0dXJuZWQgMCBhZnRlciAxMCB1c2VjcwpbICAyMDYuMDc2ODQwXSBBRERSQ09ORihO RVRERVZfVVApOiB2aXJicjA6IGxpbmsgaXMgbm90IHJlYWR5ClsgIDIwOC40OTAyNDRdIGNhbGxp bmcgIGVidGFibGVzX2luaXQrMHgwLzB4MTAwMCBbZWJ0YWJsZXNdIEAgMzY0MQpbICAyMDguNDkw MzYwXSBFYnRhYmxlcyB2Mi4wIHJlZ2lzdGVyZWQKWyAgMjA4LjQ5MDM4M10gaW5pdGNhbGwgZWJ0 YWJsZXNfaW5pdCsweDAvMHgxMDAwIFtlYnRhYmxlc10gcmV0dXJuZWQgMCBhZnRlciA1MSB1c2Vj cwpbICAyMDguNTQzODAxXSBjYWxsaW5nICBlYnRhYmxlX25hdF9pbml0KzB4MC8weDEwMDAgW2Vi dGFibGVfbmF0XSBAIDM2NDMKWyAgMjA4LjU0Mzk5OF0gaW5pdGNhbGwgZWJ0YWJsZV9uYXRfaW5p dCsweDAvMHgxMDAwIFtlYnRhYmxlX25hdF0gcmV0dXJuZWQgMCBhZnRlciAxMTMgdXNlY3MKWyAg MjE0Ljc0MzQ3Ml0gU0VMaW51eDogaW5pdGlhbGl6ZWQgKGRldiBtcXVldWUsIHR5cGUgbXF1ZXVl KSwgdXNlcyB0cmFuc2l0aW9uIFNJRHMKWyAgMjE0Ljc0ODQzMl0gU0VMaW51eDogaW5pdGlhbGl6 ZWQgKGRldiBwcm9jLCB0eXBlIHByb2MpLCB1c2VzIGdlbmZzX2NvbnRleHRzClsgIDIxNC45MDA5 NjVdIFNFTGludXg6IGluaXRpYWxpemVkIChkZXYgbXF1ZXVlLCB0eXBlIG1xdWV1ZSksIHVzZXMg dHJhbnNpdGlvbiBTSURzClsgIDIxNC45MDIzNjFdIFNFTGludXg6IGluaXRpYWxpemVkIChkZXYg cHJvYywgdHlwZSBwcm9jKSwgdXNlcyBnZW5mc19jb250ZXh0cwpbICAyMzEuMTIwODU2XSBhdGEy LjAwOiBleGNlcHRpb24gRW1hc2sgMHgwIFNBY3QgMHgwIFNFcnIgMHgwIGFjdGlvbiAweDYgZnJv emVuClsgIDIzMS4xMjA5OTZdIGF0YTIuMDA6IFNUX0ZJUlNUOiAhKERSUXxFUlJ8REYpClsgIDIz MS4xMjEyMTZdIHNyIDE6MDowOjA6IENEQjogR2V0IGV2ZW50IHN0YXR1cyBub3RpZmljYXRpb246 IDRhIDAxIDAwIDAwIDEwIDAwIDAwIDAwIDA4IDAwClsgIDIzMS4xMjE0NDVdIGF0YTIuMDA6IGNt ZCBhMC8wMDowMDowMDowODowMC8wMDowMDowMDowMDowMC9hMCB0YWcgMCBwaW8gMTYzOTIgaW4K WyAgMjMxLjEyMTQ1MF0gICAgICAgICAgcmVzIDUwLzAwOjAxOjAwOjA4OjAwLzAwOjAwOjAwOjAw OjAwL2EwIEVtYXNrIDB4MiAoSFNNIHZpb2xhdGlvbikKWyAgMjMxLjEyMTU3Ml0gYXRhMi4wMDog c3RhdHVzOiB7IERSRFkgfQpbICAyMzEuMTIxNzkxXSBhdGEyOiBzb2Z0IHJlc2V0dGluZyBsaW5r ClsgIDIzMS4zODc4NzRdIGF0YTIuMDA6IGNvbmZpZ3VyZWQgZm9yIFVETUEvMzMKWyAgMjMxLjQy MjQ4NF0gYXRhMjogRUggY29tcGxldGUKWyAgMjU3Ljc2NzMyNl0gY2FsbGluZyAgZnVzZV9pbml0 KzB4MC8weDEzZCBbZnVzZV0gQCAzOTI1ClsgIDI1Ny43Njc0MDJdIGZ1c2UgaW5pdCAoQVBJIHZl cnNpb24gNy4xNykKWyAgMjU3Ljc3MjU1OV0gaW5pdGNhbGwgZnVzZV9pbml0KzB4MC8weDEzZCBb ZnVzZV0gcmV0dXJuZWQgMCBhZnRlciA1MDI2IHVzZWNzClsgIDI1Ny45NjA0ODJdIFNFTGludXg6 IGluaXRpYWxpemVkIChkZXYgZnVzZSwgdHlwZSBmdXNlKSwgdXNlcyBnZW5mc19jb250ZXh0cwpb ICAyNTkuNjI1NzM0XSBTRUxpbnV4OiBpbml0aWFsaXplZCAoZGV2IGZ1c2VjdGwsIHR5cGUgZnVz ZWN0bCksIHVzZXMgZ2VuZnNfY29udGV4dHMKWyAgMjYwLjA5MjY5NV0gaGRhLWludGVsOiBJbnZh bGlkIHBvc2l0aW9uIGJ1ZmZlciwgdXNpbmcgTFBJQiByZWFkIG1ldGhvZCBpbnN0ZWFkLgpbICA5 MzQuODM1NDc0XSB3YyB1c2VkIGdyZWF0ZXN0IHN0YWNrIGRlcHRoOiAyNzUyIGJ5dGVzIGxlZnQK Cgo= --nextPart1926288.ImhURyU77f Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel --nextPart1926288.ImhURyU77f-- From xen-devel-bounces@lists.xensource.com Tue Sep 13 17:33:45 2011 Return-path: Envelope-to: www-data@lists.xensource.com Delivery-date: Tue, 13 Sep 2011 17:33:45 -0700 Received: from localhost ([127.0.0.1] helo=lists.colo.xensource.com) by lists.xensource.com with esmtp (Exim 4.43) id 1R3dQ9-0004rM-9i; Tue, 13 Sep 2011 17:33:45 -0700 Received: from mail182.messagelabs.com ([85.158.139.83]) by lists.xensource.com with smtp (Exim 4.43) id 1R3dPH-0004eY-Be for Xen-devel@lists.xensource.com; Tue, 13 Sep 2011 17:32:52 -0700 X-Env-Sender: sfr@canb.auug.org.au X-Msg-Ref: server-4.tower-182.messagelabs.com!1315960366!18216494!1 X-Originating-IP: [203.10.76.15] X-StarScan-Version: 6.3.6; banners=-,-,- X-VirusChecked: Checked Received: (qmail 26371 invoked from network); 14 Sep 2011 00:32:46 -0000 Received: from calzone.tip.net.au (HELO calzone.tip.net.au) (203.10.76.15) by server-4.tower-182.messagelabs.com with SMTP; 14 Sep 2011 00:32:46 -0000 Received: from canb.auug.org.au (ibmaus65.lnk.telstra.net [165.228.126.9]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by calzone.tip.net.au (Postfix) with ESMTPSA id 44DA5128436; Wed, 14 Sep 2011 10:32:40 +1000 (EST) Date: Wed, 14 Sep 2011 10:32:34 +1000 From: Stephen Rothwell To: Jeremy Fitzhardinge Message-Id: <20110914103234.4f2f6a2dd65734de6622e79f@canb.auug.org.au> In-Reply-To: <4E6FC2D3.2060408@goop.org> References: <20110825142450.c84e02d8763cfd1a93411844@canb.auug.org.au> <4E5690C3.2050706@goop.org> <4E5693DD.2010307@zytor.com> <20110826090619.7588d424798f53a6f3621eb2@canb.auug.org.au> <4E56D6E1.6030405@zytor.com> <20110826125441.709aa423cdf072ce085fb91c@canb.auug.org.au> <20110913211154.fe53ca8c1d608def77a69022@canb.auug.org.au> <4E6FC2D3.2060408@goop.org> X-Mailer: Sylpheed 3.2.0beta3 (GTK+ 2.24.6; i486-pc-linux-gnu) Mime-Version: 1.0 Cc: Xen Devel , Peter Zijlstra , linux-kernel@vger.kernel.org, linux-next@vger.kernel.org, "H. Peter Anvin" , Thomas Gleixner , Ingo Molnar Subject: [Xen-devel] Re: linux-next: manual merge of the xen tree with the tip tree X-BeenThere: xen-devel@lists.xensource.com X-Mailman-Version: 2.1.5 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0224172941==" Sender: xen-devel-bounces@lists.xensource.com Errors-To: xen-devel-bounces@lists.xensource.com --===============0224172941== Content-Type: multipart/signed; protocol="application/pgp-signature"; micalg="PGP-SHA1"; boundary="Signature=_Wed__14_Sep_2011_10_32_34_+1000_XZM3NiBv=JSQE3KM" --Signature=_Wed__14_Sep_2011_10_32_34_+1000_XZM3NiBv=JSQE3KM Content-Type: text/plain; charset=US-ASCII Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Hi Jeremy, On Tue, 13 Sep 2011 13:53:39 -0700 Jeremy Fitzhardinge wr= ote: > > On 09/13/2011 08:07 AM, Thomas Gleixner wrote: > > On Tue, 13 Sep 2011, Stephen Rothwell wrote: > >> > >> On Fri, 26 Aug 2011 12:54:41 +1000 Stephen Rothwell wrote: > >>> On Thu, 25 Aug 2011 16:12:33 -0700 "H. Peter Anvin" w= rote: > >>>> On 08/25/2011 04:06 PM, Stephen Rothwell wrote: > >>>>>> Stephen: the x86/spinlocks branch in the -tip tree is obsolete and > >>>>>> should be dropped. > >>>>> That's a bit tricky as I get a rolled up tip tree. The best I coul= d do > >>>>> is revert the commit that merges the x86/spinlocks branch into > >>>>> auto-latest ... I'll do that for today (unless something happens t= o the > >>>>> tip tree in the next hour). > >>>>> > >>>> OK, let me bother Ingo about it. > >>> For today, I have done "git revert -m 1 6f8fa39c81f1" after merging t= he > >>> tip tree. > >> I am still doing this in each linux-next, and it doesn't appear to have > >> been fixed up the the tree on tesla.tglx.de, yet, I think. > > We'll take it out.=20 >=20 > Actually, the tip x86/spinlocks was the most up-to-date version of those > patches (since hpa had rebased them to a more recent version of mainline). >=20 > But never mind. Stephen, could you use >=20 > git://github.com/jsgf/linux-xen.git upstream/xen >=20 > for linux-next instead of the kernel.org xen.git, and I've re-added the > up-to-date spinlock changes there. OK, I have switched to this from today. My understanding is this: I do *not* need to revert the spinlock changes from tip anymore, correct? --=20 Cheers, Stephen Rothwell sfr@canb.auug.org.au http://www.canb.auug.org.au/~sfr/ --Signature=_Wed__14_Sep_2011_10_32_34_+1000_XZM3NiBv=JSQE3KM Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.11 (GNU/Linux) iQEcBAEBAgAGBQJOb/YiAAoJEDMEi1NhKgbs6zUH/AxDWuN4AXeNYpsajyioPglF +1NSWctPiCt15Kub2zeiBcKyYIhFO8KDlyqT3TAMGDS+lK9XsT490OXfdnMLVAAN A34AZ1xTtkOqrsv9LdQpqnyr3jcq42CUkpMtdacRRmP7qUnaqBGc1PI4iwsAFhbm aF47Ud77I7fmXJDyi73zka6tlP7HxH/G78JUoBo/NKBb4Lyuv40UL3+CVBdxPZxu KaCG3w1Yvs+psAoW0ts29wCt0QqchIaaQfXXeVH+ARxvSwqOJezGs9Nlp9gxFhRa HGtU3U6RsW5JBEgWxu7Tj4OdjMjddNc9kycjAdgND129Wn/Pjaq84G/z/qYBmGw= =OFgd -----END PGP SIGNATURE----- --Signature=_Wed__14_Sep_2011_10_32_34_+1000_XZM3NiBv=JSQE3KM-- --===============0224172941== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel --===============0224172941==-- From xen-devel-bounces@lists.xensource.com Tue Sep 13 17:41:44 2011 Return-path: Envelope-to: www-data@lists.xensource.com Delivery-date: Tue, 13 Sep 2011 17:41:44 -0700 Received: from localhost ([127.0.0.1] helo=lists.colo.xensource.com) by lists.xensource.com with esmtp (Exim 4.43) id 1R3dXs-0005Nj-2y; Tue, 13 Sep 2011 17:41:44 -0700 Received: from mail174.messagelabs.com ([85.158.138.51]) by lists.xensource.com with esmtp (Exim 4.43) id 1R3dXJ-0005Be-PJ for Xen-devel@lists.xensource.com; Tue, 13 Sep 2011 17:41:10 -0700 X-Env-Sender: jeremy@goop.org X-Msg-Ref: server-8.tower-174.messagelabs.com!1315960864!17635947!1 X-Originating-IP: [74.207.240.146] X-StarScan-Version: 6.3.6; banners=-,-,- X-VirusChecked: Checked Received: (qmail 8252 invoked from network); 14 Sep 2011 00:41:06 -0000 Received: from claw.goop.org (HELO claw.goop.org) (74.207.240.146) by server-8.tower-174.messagelabs.com with DHE-RSA-AES256-SHA encrypted SMTP; 14 Sep 2011 00:41:06 -0000 Received: from saboo.goop.org (unknown [IPv6:2001:470:1f05:899:f2de:f1ff:fe5c:34ed]) (Authenticated sender: smtp-saboo) by claw.goop.org (Postfix) with ESMTPSA id B20CF8EED; Tue, 13 Sep 2011 17:41:03 -0700 (PDT) Received: from saboo.goop.org (localhost [IPv6:::1]) by saboo.goop.org (Postfix) with ESMTP id 0E68320B26; Tue, 13 Sep 2011 17:41:03 -0700 (PDT) Message-ID: <4E6FF81E.30106@goop.org> Date: Tue, 13 Sep 2011 17:41:02 -0700 From: Jeremy Fitzhardinge User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:6.0.2) Gecko/20110906 Thunderbird/6.0.2 MIME-Version: 1.0 To: Stephen Rothwell References: <20110825142450.c84e02d8763cfd1a93411844@canb.auug.org.au> <4E5690C3.2050706@goop.org> <4E5693DD.2010307@zytor.com> <20110826090619.7588d424798f53a6f3621eb2@canb.auug.org.au> <4E56D6E1.6030405@zytor.com> <20110826125441.709aa423cdf072ce085fb91c@canb.auug.org.au> <20110913211154.fe53ca8c1d608def77a69022@canb.auug.org.au> <4E6FC2D3.2060408@goop.org> <20110914103234.4f2f6a2dd65734de6622e79f@canb.auug.org.au> In-Reply-To: <20110914103234.4f2f6a2dd65734de6622e79f@canb.auug.org.au> X-Enigmail-Version: 1.3.1 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: Xen Devel , Peter Zijlstra , linux-kernel@vger.kernel.org, linux-next@vger.kernel.org, "H. Peter Anvin" , Thomas Gleixner , Ingo Molnar Subject: [Xen-devel] Re: linux-next: manual merge of the xen tree with the tip tree X-BeenThere: xen-devel@lists.xensource.com X-Mailman-Version: 2.1.5 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xensource.com Errors-To: xen-devel-bounces@lists.xensource.com On 09/13/2011 05:32 PM, Stephen Rothwell wrote: > Hi Jeremy, > > On Tue, 13 Sep 2011 13:53:39 -0700 Jeremy Fitzhardinge wrote: >> >> On 09/13/2011 08:07 AM, Thomas Gleixner wrote: >>> On Tue, 13 Sep 2011, Stephen Rothwell wrote: >>>> >>>> On Fri, 26 Aug 2011 12:54:41 +1000 Stephen Rothwell wrote: >>>>> On Thu, 25 Aug 2011 16:12:33 -0700 "H. Peter Anvin" wrote: >>>>>> On 08/25/2011 04:06 PM, Stephen Rothwell wrote: >>>>>>>> Stephen: the x86/spinlocks branch in the -tip tree is obsolete and >>>>>>>> should be dropped. >>>>>>> That's a bit tricky as I get a rolled up tip tree. The best I could do >>>>>>> is revert the commit that merges the x86/spinlocks branch into >>>>>>> auto-latest ... I'll do that for today (unless something happens to the >>>>>>> tip tree in the next hour). >>>>>>> >>>>>> OK, let me bother Ingo about it. >>>>> For today, I have done "git revert -m 1 6f8fa39c81f1" after merging the >>>>> tip tree. >>>> I am still doing this in each linux-next, and it doesn't appear to have >>>> been fixed up the the tree on tesla.tglx.de, yet, I think. >>> We'll take it out. >> >> Actually, the tip x86/spinlocks was the most up-to-date version of those >> patches (since hpa had rebased them to a more recent version of mainline). >> >> But never mind. Stephen, could you use >> >> git://github.com/jsgf/linux-xen.git upstream/xen >> >> for linux-next instead of the kernel.org xen.git, and I've re-added the >> up-to-date spinlock changes there. > > OK, I have switched to this from today. > > My understanding is this: I do *not* need to revert the spinlock changes > from tip anymore, correct? Right. tglx has removed these changes from tip.git (even though they were OK), and I've reinstated the proper versions in my tree. The xen.git on git.kernel.org still has old versions, but I'll sort that out once it's back online. I expect it will ultimately go upstream via tip.git, but we can work that out later too. Thanks, J _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel From xen-devel-bounces@lists.xensource.com Tue Sep 13 17:49:12 2011 Return-path: Envelope-to: www-data@lists.xensource.com Delivery-date: Tue, 13 Sep 2011 17:49:12 -0700 Received: from localhost ([127.0.0.1] helo=lists.colo.xensource.com) by lists.xensource.com with esmtp (Exim 4.43) id 1R3df6-0005rE-Jl; Tue, 13 Sep 2011 17:49:12 -0700 Received: from mail174.messagelabs.com ([85.158.138.51]) by lists.xensource.com with smtp (Exim 4.43) id 1R3deV-0005eY-Ng for Xen-devel@lists.xensource.com; Tue, 13 Sep 2011 17:48:36 -0700 X-Env-Sender: sfr@canb.auug.org.au X-Msg-Ref: server-8.tower-174.messagelabs.com!1315961311!17636283!1 X-Originating-IP: [203.10.76.15] X-StarScan-Version: 6.3.6; banners=-,-,- X-VirusChecked: Checked Received: (qmail 13635 invoked from network); 14 Sep 2011 00:48:31 -0000 Received: from calzone.tip.net.au (HELO calzone.tip.net.au) (203.10.76.15) by server-8.tower-174.messagelabs.com with SMTP; 14 Sep 2011 00:48:31 -0000 Received: from canb.auug.org.au (ibmaus65.lnk.telstra.net [165.228.126.9]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by calzone.tip.net.au (Postfix) with ESMTPSA id 60811128436; Wed, 14 Sep 2011 10:48:29 +1000 (EST) Date: Wed, 14 Sep 2011 10:48:24 +1000 From: Stephen Rothwell To: Jeremy Fitzhardinge Message-Id: <20110914104824.16160f72661c1c9aed23ee88@canb.auug.org.au> In-Reply-To: <20110914103234.4f2f6a2dd65734de6622e79f@canb.auug.org.au> References: <20110825142450.c84e02d8763cfd1a93411844@canb.auug.org.au> <4E5690C3.2050706@goop.org> <4E5693DD.2010307@zytor.com> <20110826090619.7588d424798f53a6f3621eb2@canb.auug.org.au> <4E56D6E1.6030405@zytor.com> <20110826125441.709aa423cdf072ce085fb91c@canb.auug.org.au> <20110913211154.fe53ca8c1d608def77a69022@canb.auug.org.au> <4E6FC2D3.2060408@goop.org> <20110914103234.4f2f6a2dd65734de6622e79f@canb.auug.org.au> X-Mailer: Sylpheed 3.2.0beta3 (GTK+ 2.24.6; i486-pc-linux-gnu) Mime-Version: 1.0 Cc: Xen Devel , Peter Zijlstra , linux-kernel@vger.kernel.org, linux-next@vger.kernel.org, "H. Peter Anvin" , Thomas Gleixner , Ingo Molnar Subject: [Xen-devel] Re: linux-next: manual merge of the xen tree with the tip tree X-BeenThere: xen-devel@lists.xensource.com X-Mailman-Version: 2.1.5 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1273605901==" Sender: xen-devel-bounces@lists.xensource.com Errors-To: xen-devel-bounces@lists.xensource.com --===============1273605901== Content-Type: multipart/signed; protocol="application/pgp-signature"; micalg="PGP-SHA1"; boundary="Signature=_Wed__14_Sep_2011_10_48_24_+1000_0ctT/sgN9k55.IZK" --Signature=_Wed__14_Sep_2011_10_48_24_+1000_0ctT/sgN9k55.IZK Content-Type: text/plain; charset=US-ASCII Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Hi all, On Wed, 14 Sep 2011 10:32:34 +1000 Stephen Rothwell = wrote: > > My understanding is this: I do *not* need to revert the spinlock changes > from tip anymore, correct? Right, having looked at the tip tree, they are not in there any more. --=20 Cheers, Stephen Rothwell sfr@canb.auug.org.au http://www.canb.auug.org.au/~sfr/ --Signature=_Wed__14_Sep_2011_10_48_24_+1000_0ctT/sgN9k55.IZK Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.11 (GNU/Linux) iQEcBAEBAgAGBQJOb/nYAAoJEDMEi1NhKgbsXEsIAIDmUD2cfdqjI/TfpSpST6Rs AhZXGrApARWTWVaT93/pNmnAWPXEpBYUPGgSVDSK2Ru9jatXzvHOtnm/r7U7pP0V Yvp7dCfnX+DVWTFDNnLVguIwq5uz9isl2MLHuxJeXeB5Ch6d8yaX5/WERhZ5VB6p iqQQQ7/M9ueV/xa0bQQWkpPyUVA+M+PzT7Tv2hSMLrHf1ptEufVErpWw4qNaXx1t nhf4wgK3EN+oBRWp6MHlXMWxrMTv5sncLPj/H2ZaP4uLaDACyAjQtREn/2H9TSAG 1Lia2IXEXRrzTV3FLZg/pFc70RQwy4mSfCpw7YAF/9wzHBOTWCT182cvb67OP6s= =g6tw -----END PGP SIGNATURE----- --Signature=_Wed__14_Sep_2011_10_48_24_+1000_0ctT/sgN9k55.IZK-- --===============1273605901== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel --===============1273605901==-- From xen-devel-bounces@lists.xensource.com Tue Sep 13 18:42:18 2011 Return-path: Envelope-to: www-data@lists.xensource.com Delivery-date: Tue, 13 Sep 2011 18:42:18 -0700 Received: from localhost ([127.0.0.1] helo=lists.colo.xensource.com) by lists.xensource.com with esmtp (Exim 4.43) id 1R3eUU-0007Ak-Mm; Tue, 13 Sep 2011 18:42:18 -0700 Received: from mail21.messagelabs.com ([85.158.143.35]) by lists.xensource.com with esmtp (Exim 4.43) id 1R3eTa-0006xz-7d for xen-devel@lists.xensource.com; Tue, 13 Sep 2011 18:41:22 -0700 X-Env-Sender: Ian.Jackson@eu.citrix.com X-Msg-Ref: server-8.tower-21.messagelabs.com!1315964463!58858965!1 X-Originating-IP: [62.200.22.115] X-StarScan-Version: 6.4.1; banners=-,-,- X-VirusChecked: Checked Received: (qmail 15609 invoked from network); 14 Sep 2011 01:41:03 -0000 Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115) by server-8.tower-21.messagelabs.com with RC4-SHA encrypted SMTP; 14 Sep 2011 01:41:03 -0000 X-IronPort-AV: E=Sophos;i="4.68,377,1312156800"; d="scan'208";a="7784748" Received: from lonpmailmx01.citrite.net ([10.30.203.162]) by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5; 14 Sep 2011 01:41:18 +0000 Received: from woking.xci-test.com (10.80.248.135) by smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id 8.3.137.0; Wed, 14 Sep 2011 02:41:18 +0100 Received: from osstest by woking.xci-test.com with local (Exim 4.69) (envelope-from ) id 1R3eTW-0008UW-BR; Wed, 14 Sep 2011 02:41:18 +0100 To: xen-devel@lists.xensource.com Message-ID: From: xen.org Date: Wed, 14 Sep 2011 02:41:18 +0100 MIME-Version: 1.0 Content-Type: text/plain Cc: ian.jackson@eu.citrix.com Subject: [Xen-devel] [xen-unstable test] 8923: regressions - trouble: blocked/fail X-BeenThere: xen-devel@lists.xensource.com X-Mailman-Version: 2.1.5 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xensource.com Errors-To: xen-devel-bounces@lists.xensource.com flight 8923 xen-unstable real [real] http://www.chiark.greenend.org.uk/~xensrcts/logs/8923/ Regressions :-( Tests which did not succeed and are blocking: build-i386-oldkern 4 xen-build fail REGR. vs. 8873 build-amd64 4 xen-build fail REGR. vs. 8873 build-i386 4 xen-build fail REGR. vs. 8873 build-amd64-oldkern 4 xen-build fail REGR. vs. 8873 Tests which did not succeed, but are not blocking, including regressions (tests previously passed) regarded as allowable: test-amd64-amd64-xl-pcipt-intel 1 xen-build-check(1) blocked n/a test-amd64-i386-rhel6hvm-intel 1 xen-build-check(1) blocked n/a test-i386-i386-pv 1 xen-build-check(1) blocked n/a test-amd64-i386-pv 1 xen-build-check(1) blocked n/a test-amd64-amd64-pv 1 xen-build-check(1) blocked n/a test-i386-i386-xl 1 xen-build-check(1) blocked n/a test-amd64-i386-xl 1 xen-build-check(1) blocked n/a test-amd64-i386-xl-credit2 1 xen-build-check(1) blocked n/a test-amd64-i386-rhel6hvm-amd 1 xen-build-check(1) blocked n/a test-amd64-amd64-pair 1 xen-build-check(1) blocked n/a test-amd64-i386-pair 1 xen-build-check(1) blocked n/a test-i386-i386-pair 1 xen-build-check(1) blocked n/a build-amd64-pvops 4 kernel-build fail like 8873 build-i386-pvops 4 kernel-build fail like 8873 test-amd64-i386-xl-multivcpu 1 xen-build-check(1) blocked n/a test-amd64-amd64-xl-sedf 1 xen-build-check(1) blocked n/a test-amd64-i386-win-vcpus1 1 xen-build-check(1) blocked n/a test-amd64-i386-xl-win-vcpus1 1 xen-build-check(1) blocked n/a test-amd64-amd64-win 1 xen-build-check(1) blocked n/a test-amd64-i386-win 1 xen-build-check(1) blocked n/a test-amd64-amd64-xl-win 1 xen-build-check(1) blocked n/a test-amd64-amd64-xl 1 xen-build-check(1) blocked n/a test-i386-i386-xl-win 1 xen-build-check(1) blocked n/a test-i386-i386-win 1 xen-build-check(1) blocked n/a version targeted for testing: xen 51913fe3d25a baseline version: xen 0312575dc35e ------------------------------------------------------------ People who touched revisions under test: Andrew Cooper Benjamin Schweikert Christoph Egger George Dunlap Ian Campbell Ian Jackson Keir Fraser Olaf Hering Stefano Stabellini Tim Deegan ------------------------------------------------------------ jobs: build-amd64 fail build-i386 fail build-amd64-oldkern fail build-i386-oldkern fail build-amd64-pvops fail build-i386-pvops fail test-amd64-amd64-xl blocked test-amd64-i386-xl blocked test-i386-i386-xl blocked test-amd64-i386-rhel6hvm-amd blocked test-amd64-i386-xl-credit2 blocked test-amd64-amd64-xl-pcipt-intel blocked test-amd64-i386-rhel6hvm-intel blocked test-amd64-i386-xl-multivcpu blocked test-amd64-amd64-pair blocked test-amd64-i386-pair blocked test-i386-i386-pair blocked test-amd64-amd64-pv blocked test-amd64-i386-pv blocked test-i386-i386-pv blocked test-amd64-amd64-xl-sedf blocked test-amd64-i386-win-vcpus1 blocked test-amd64-i386-xl-win-vcpus1 blocked test-amd64-amd64-win blocked test-amd64-i386-win blocked test-i386-i386-win blocked test-amd64-amd64-xl-win blocked test-i386-i386-xl-win blocked ------------------------------------------------------------ sg-report-flight on woking.cam.xci-test.com logs: /home/xc_osstest/logs images: /home/xc_osstest/images Logs, config files, etc. are available at http://www.chiark.greenend.org.uk/~xensrcts/logs Test harness code can be found at http://xenbits.xensource.com/gitweb?p=osstest.git;a=summary Not pushing. ------------------------------------------------------------ changeset: 23837:51913fe3d25a tag: tip user: Stefano Stabellini date: Tue Sep 13 15:46:47 2011 +0100 fix the build when CONFIG_QEMU is specified by the user Signed-off-by: Stefano Stabellini Committed-by: Stefano Stabellini changeset: 23836:e564f2f1b737 user: Ian Jackson date: Tue Sep 13 14:52:22 2011 +0100 tools: fix permissions of git-checkout.sh 23828:0d21b68f528b introduced a new scripts/git-checkout.sh, but it had the wrong permissions. chmod +x it, and add a blank line at the end to make sure it actually gets updated. Signed-off-by: Ian Jackson changeset: 23835:64aab9a077ea user: Keir Fraser date: Tue Sep 13 11:20:57 2011 +0100 scripts/git-checkout.sh: Is not bash specific. Invoke with /bin/sh. Signed-off-by: Keir Fraser changeset: 23834:1d40b2793723 user: George Dunlap date: Tue Sep 13 10:43:43 2011 +0100 xen,credit1: Add variable timeslice Add a xen command-line parameter, sched_credit_tslice_ms, to set the timeslice of the credit1 scheduler. Signed-off-by: George Dunlap changeset: 23833:ffe8e65f6687 user: Andrew Cooper date: Tue Sep 13 10:33:10 2011 +0100 IRQ: IO-APIC support End Of Interrupt for older IO-APICs The old io_apic_eoi() function using the EOI register only works for IO-APICs with a version of 0x20. Older IO-APICs do not have an EOI register so line level interrupts have to be EOI'd by flipping the mode to edge and back, which clears the IRR and Delivery Status bits. This patch replaces the current io_apic_eoi() function with one which takes into account the version of the IO-APIC and EOI's appropriately. v2: make recursive call to __io_apic_eoi() to reduce code size. Signed-off-by: Andrew Cooper changeset: 23832:ad3b4bb097cb user: Stefano Stabellini date: Tue Sep 13 10:32:24 2011 +0100 xen: if mapping GSIs we run out of pirq < nr_irqs_gsi, use the others PV on HVM guests can have more GSIs than the host, in that case we could run out of pirq < nr_irqs_gsi. When that happens use pirq >= nr_irqs_gsi rather than returning an error. Signed-off-by: Stefano Stabellini Tested-by: Benjamin Schweikert changeset: 23831:53416e7c0529 user: Stefano Stabellini date: Tue Sep 13 10:30:09 2011 +0100 Clone and build Seabios by default Signed-off-by: Stefano Stabellini changeset: 23830:1b80eaeeba7b user: Stefano Stabellini date: Tue Sep 13 10:29:14 2011 +0100 Clone and build upstream Qemu by default Signed-off-by: Stefano Stabellini changeset: 23829:9a541243aeaf user: Stefano Stabellini date: Tue Sep 13 10:27:53 2011 +0100 Rename ioemu-dir as qemu-xen-traditional-dir Signed-off-by: Stefano Stabellini changeset: 23828:0d21b68f528b user: Stefano Stabellini date: Tue Sep 13 10:27:20 2011 +0100 Move the ioemu-dir-find shell script to an external file Add support for configuring upstream qemu and rename ioemu-remote ioemu-dir-remote. Signed-off-by: Stefano Stabellini changeset: 23827:d1d6abc1db20 user: Olaf Hering date: Tue Sep 13 10:25:32 2011 +0100 xenpaging: use batch of pages during final page-in Map up to RING_SIZE pages in exit path to fill the ring instead of populating one page at a time. Signed-off-by: Olaf Hering changeset: 23826:ad958e87db79 user: Ian Campbell date: Tue Sep 13 10:22:03 2011 +0100 hvmloader: don't clear acpi_info after filling in some fields In particular the madt_lapic0_addr and madt_csum_addr fields are filled in while building the tables. This fixes a bluescreen on shutdown with certain versions of Windows. Signed-off-by: Ian Campbell Reported-by: Christoph Egger Tested-and-acked-by: Christoph Egger changeset: 23825:0312575dc35e user: Tim Deegan date: Thu Sep 08 15:13:06 2011 +0100 x86/mm: use new page-order interfaces in nested HAP code to make 2M and 1G mappings in the nested p2m tables. Signed-off-by: Christoph Egger Signed-off-by: Tim Deegan Committed-by: Tim Deegan ======================================== commit cd776ee9408ff127f934a707c1a339ee600bc127 Author: Ian Jackson Date: Tue Jun 28 13:50:53 2011 +0100 qemu-char.c: fix incorrect CONFIG_STUBDOM handling qemu-char.c:1123:7: warning: "CONFIG_STUBDOM" is not defined [-Wundef] Signed-off-by: Olaf Hering Acked-by: Ian Jackson _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel From xen-devel-bounces@lists.xensource.com Tue Sep 13 18:45:17 2011 Return-path: Envelope-to: www-data@lists.xensource.com Delivery-date: Tue, 13 Sep 2011 18:45:17 -0700 Received: from localhost ([127.0.0.1] helo=lists.colo.xensource.com) by lists.xensource.com with esmtp (Exim 4.43) id 1R3eXM-0007ZZ-Uj; Tue, 13 Sep 2011 18:45:16 -0700 Received: from mail27.messagelabs.com ([193.109.254.147]) by lists.xensource.com with smtp (Exim 4.43) id 1R3eWn-0007Mn-NJ for xen-devel@lists.xensource.com; Tue, 13 Sep 2011 18:44:42 -0700 X-Env-Sender: jim_burn@bellsouth.net X-Msg-Ref: server-7.tower-27.messagelabs.com!1315964656!48530317!1 X-Originating-IP: [98.139.44.147] X-StarScan-Version: 6.3.6; banners=-,-,- X-VirusChecked: Checked Received: (qmail 4407 invoked from network); 14 Sep 2011 01:44:16 -0000 Received: from nm20.access.bullet.mail.sp2.yahoo.com (HELO nm20.access.bullet.mail.sp2.yahoo.com) (98.139.44.147) by server-7.tower-27.messagelabs.com with SMTP; 14 Sep 2011 01:44:16 -0000 Received: from [98.139.44.106] by nm20.access.bullet.mail.sp2.yahoo.com with NNFMP; 14 Sep 2011 01:44:37 -0000 Received: from [98.139.44.90] by tm11.access.bullet.mail.sp2.yahoo.com with NNFMP; 14 Sep 2011 01:44:37 -0000 Received: from [127.0.0.1] by omp1027.access.mail.sp2.yahoo.com with NNFMP; 14 Sep 2011 01:44:37 -0000 X-Yahoo-Newman-Id: 518125.90320.bm@omp1027.access.mail.sp2.yahoo.com Received: (qmail 30295 invoked from network); 14 Sep 2011 01:44:37 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=bellsouth.net; s=s1024; t=1315964677; bh=BbD7UsRz40xLFsJLtgetHwRzD3AvsQ99k6HhqAm1Elc=; h=X-Yahoo-Newman-Property:X-YMail-OSG:X-Yahoo-SMTP:Received:From:To:Cc:Subject:Date:Message-ID:User-Agent:In-Reply-To:References:MIME-Version:Content-Transfer-Encoding:Content-Type; b=TfE1XQIbOie3d+/4824V+/knpbNlxy9SbDRN1O6hfyzPh0ORMza4A4R4DIUbbfBlGkIq3K5kqiHCjIJl1YRghE6av4phVXDDmr65mpXwYmp+KRJU0hMXVZYvHtayCGChoScTk33zJxSiAYG+7bNv1qL8ITKL9RfWS0+1TGLWFro= X-Yahoo-Newman-Property: ymail-3 X-YMail-OSG: o5OFRBcVM1lYCavTeRohU4fQnQoLmrwX0EXScklSK79bXw2 97nfbrSgY_KB_8O317i7ehGRHHxMvA5lbIMCpbf5ZjsErLGyYlg7Fkye.JcW kGCL99RvMwWB7TTbGa11Uc6tOYcqAuoeMb5EGt7WK0tZvhZatp_SbFN05K7W 90nq4jg75hnzwrLKdJlgqT9Osb60lIzSLXRI18uBlhledCHRI2O__GFaJ3jH MgohzAYmcjZZs7ExfTHOPiXQnbEqw07MkWhWWByxA0M_9qEOpaISXjBnzuI0 7V.WrS7qJFJYAdGHiRdVYZUgUccnsU9jDig_k5XpeTxVGfABbJL5.WNukAqO I7X9CQRt7N97QqmS..tQaR_uoD4s6Qc6vpaRynM3W7npLnubbZgBJjdk1x7G deQ-- X-Yahoo-SMTP: g0AhWW2swBA2djJKuhuwxPlPqLrHlDrycdPnfR9kZNrpKCA- Received: from dell4550.localnet (jim_burn@74.232.119.247 with plain) by smtp110.sbc.mail.ne1.yahoo.com with SMTP; 13 Sep 2011 18:44:36 -0700 PDT From: jim burns To: Pasi =?ISO-8859-1?Q?K=E4rkk=E4inen?= , xen-devel@lists.xensource.com, xen-users@lists.xensource.com Date: Tue, 13 Sep 2011 21:44:29 -0400 Message-ID: <1665465.xulIAphhZn@dell4550> User-Agent: KMail/4.7.1 (Linux/2.6.37.6-0.7-default; KDE/4.7.1; i686; ; ) In-Reply-To: <1856036.eYCcuDQrZC@dell4550> References: <201107231426.56811.jim_burn@bellsouth.net> <20110913085559.GG12984@reaktio.net> <1856036.eYCcuDQrZC@dell4550> MIME-Version: 1.0 Content-Transfer-Encoding: 7Bit Content-Type: text/plain; charset="us-ascii" Cc: Todd Deshane , Fedora Xen List Subject: [Xen-devel] Re: [Xen-users] Continuing BUG:-iness booting Fedora Rawhide 3.1.0-rc's (was Summary: Experiences setting up a debug serial port) X-BeenThere: xen-devel@lists.xensource.com X-Mailman-Version: 2.1.5 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xensource.com Errors-To: xen-devel-bounces@lists.xensource.com On Tue September 13 2011, 7:50:55 PM, jim burns wrote: > where vmlinuz and initramfs are soft links, and x,y,z is rc5.git0.0 for the > attached file with 'initcall_debug', and rc6.git0.0 for the (unimportant) > crash shown below (with the 64k buffer). Sorry - both the attached file, and the (unimportant) crash file were for rc6. _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel From xen-devel-bounces@lists.xensource.com Tue Sep 13 18:48:25 2011 Return-path: Envelope-to: www-data@lists.xensource.com Delivery-date: Tue, 13 Sep 2011 18:48:25 -0700 Received: from localhost ([127.0.0.1] helo=lists.colo.xensource.com) by lists.xensource.com with esmtp (Exim 4.43) id 1R3eaP-0000GO-MO; Tue, 13 Sep 2011 18:48:25 -0700 Received: from mail216.messagelabs.com ([85.158.143.99]) by lists.xensource.com with esmtp (Exim 4.43) id 1R3eYc-00082C-D8; Tue, 13 Sep 2011 18:46:35 -0700 X-Env-Sender: jeremy@goop.org X-Msg-Ref: server-10.tower-216.messagelabs.com!1315964789!10079887!1 X-Originating-IP: [74.207.240.146] X-StarScan-Version: 6.3.6; banners=-,-,- X-VirusChecked: Checked Received: (qmail 12377 invoked from network); 14 Sep 2011 01:46:31 -0000 Received: from claw.goop.org (HELO claw.goop.org) (74.207.240.146) by server-10.tower-216.messagelabs.com with DHE-RSA-AES256-SHA encrypted SMTP; 14 Sep 2011 01:46:31 -0000 Received: from saboo.goop.org (unknown [IPv6:2001:470:1f05:899:f2de:f1ff:fe5c:34ed]) (Authenticated sender: smtp-saboo) by claw.goop.org (Postfix) with ESMTPSA id F0B3E8EE9; Tue, 13 Sep 2011 18:46:28 -0700 (PDT) Received: from saboo.goop.org (localhost [IPv6:::1]) by saboo.goop.org (Postfix) with ESMTP id 8A1E420499; Tue, 13 Sep 2011 18:46:24 -0700 (PDT) Message-ID: <4E700770.90204@goop.org> Date: Tue, 13 Sep 2011 18:46:24 -0700 From: Jeremy Fitzhardinge User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:6.0.2) Gecko/20110906 Thunderbird/6.0.2 MIME-Version: 1.0 To: jinho hwang Subject: Re: [Xen-devel] [Xen-users] current xen linux kernel branch? References: In-Reply-To: X-Enigmail-Version: 1.3.1 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: xen-devel@lists.xensource.com, xen-users@lists.xensource.com X-BeenThere: xen-devel@lists.xensource.com X-Mailman-Version: 2.1.5 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xensource.com Errors-To: xen-devel-bounces@lists.xensource.com On 09/13/2011 02:15 PM, jinho hwang wrote: > > Hi, > > Where can I find the current xen linux kernel branch? The > git.kernel.org has been down for maintenance > reason, so I can't find any kernel source except xenbits.xensource.com > . However, this repository does not have > current linux dom0 kernel such as 2.6.32.*. Can anyone share with me > the kernel source because I have to install xen environment in my > intel 32/64bits machine. You can use upstream Linux for dom0, but it isn't quite as featureful as the 2.6.32-based kernel. The 2.6.32 kernel is available at git://github.com/jsgf/linux-xen.git xen/next-2.6.32 while kernel.org is down. J _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel From xen-devel-bounces@lists.xensource.com Tue Sep 13 19:32:33 2011 Return-path: Envelope-to: www-data@lists.xensource.com Delivery-date: Tue, 13 Sep 2011 19:32:33 -0700 Received: from localhost ([127.0.0.1] helo=lists.colo.xensource.com) by lists.xensource.com with esmtp (Exim 4.43) id 1R3fH6-0001vw-Cv; Tue, 13 Sep 2011 19:32:32 -0700 Received: from mail216.messagelabs.com ([85.158.143.99]) by lists.xensource.com with smtp (Exim 4.43) id 1R3fFu-0001hl-HY for xen-devel@lists.xensource.com; Tue, 13 Sep 2011 19:31:19 -0700 X-Env-Sender: mike@flyn.org X-Msg-Ref: server-15.tower-216.messagelabs.com!1315967474!17709799!1 X-Originating-IP: [66.94.237.205] X-StarScan-Version: 6.3.6; banners=-,-,- X-VirusChecked: Checked Received: (qmail 31867 invoked from network); 14 Sep 2011 02:31:15 -0000 Received: from nm4.access.bullet.mail.mud.yahoo.com (HELO nm4.access.bullet.mail.mud.yahoo.com) (66.94.237.205) by server-15.tower-216.messagelabs.com with SMTP; 14 Sep 2011 02:31:15 -0000 Received: from [66.94.237.201] by nm4.access.bullet.mail.mud.yahoo.com with NNFMP; 14 Sep 2011 02:31:14 -0000 Received: from [66.94.237.100] by tm12.access.bullet.mail.mud.yahoo.com with NNFMP; 14 Sep 2011 02:31:14 -0000 Received: from [127.0.0.1] by omp1005.access.mail.mud.yahoo.com with NNFMP; 14 Sep 2011 02:31:14 -0000 X-Yahoo-Newman-Id: 398575.82385.bm@omp1005.access.mail.mud.yahoo.com Received: (qmail 88830 invoked from network); 14 Sep 2011 02:31:13 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s1024; t=1315967473; bh=SOhwRSDGgycQs8yCv+drldUkGcrRWEYW9drpcXsJbQA=; h=X-Yahoo-Newman-Property:X-YMail-OSG:X-Yahoo-SMTP:Received:Received:Date:From:To:Subject:Message-ID:MIME-Version:Content-Type:Content-Disposition:User-Agent; b=sL41vSyKYzveo6iBBqN6/pGJkrUCZY00I1OzAqE1+v3k10MsnZFl3e9IRUKZVO4IQbpr1Roq/a/T5cl9GPTpRPUUdgVm07LBx3S6GnxHf2OmeJHXzSoNQCKWqrwstYr6oYV3K3IXfhTtCu1qiqqqaL7fbEo0Rl09SwUbkyvC1+o= X-Yahoo-Newman-Property: ymail-3 X-YMail-OSG: 1pHfNG4VM1m_dpOFE2JARZS7rN2VayhVxnRs5qb1NJD0Uja HVU8iCCVnSsSadfbSv1pboMZnptFbd0vi2Yc_Fabp86aMl5K66qjo_fYYA0u dqYKmf48gGyIUob5uq.EhktTzHm2yNta3XxJ.dInhaUhVyxay2sSXDH6Xxmt 1gz5652R0XXgDh0BBp60VDdN8gXBUKmvzEM9ota6rrO_pfvhPMsPSCcCW6xU klFAX3DUZ58211IWIxuXFY9CkzRuFhC5X56UtVWYV9rVkduF5Y8TuxA5NR6U 4Jxn6afNPZBgRPq1jhsCof8W2AgEjS_4197y0AI7nqhnFK_UYl4gMlv2J4tz y9aolHALyTEpHQ31xia82oQIocbxzf0VM3BYBXM8R4XuJN.EFsCO.wtcuhsU VREXbQgGOAztEhl1gdWVdsx2ZMqWPA57njKJ.WhfrX.o_fjiefAvNAhiE1au X4FN9e3v2floousfnzc4FCGGYizvAAoAMpi8YsgaBBipGO5b7klWXqZaO8nI htVUokTU.sGanLfPvldfTSnsWwm3LdAaOSMdfRI1rDOje6nCKh1B_0J_ZAmM EQ.hhfdBOFWY9_vso__TzDRDIZHfen76gq7o1KbF5M2KXG7LEOCOuHlfvgrH .GuHEUS6ZNaqb.hjPlg-- X-Yahoo-SMTP: 1x8krq.swBD2B21Axr3MHc8r8V8YnFYfUGhbsFMV7v4p Received: from imp.local (mike@99.31.122.188 with login) by smtp106.sbc.mail.ne1.yahoo.com with SMTP; 13 Sep 2011 19:31:12 -0700 PDT Received: by imp.local (Postfix, from userid 1101) id D30135000BD; Tue, 13 Sep 2011 21:30:52 -0500 (CDT) Date: Tue, 13 Sep 2011 21:30:52 -0500 From: "W. Michael Petullo" To: xen-devel@lists.xensource.com Message-ID: <20110914023052.GA9816@imp.local> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.5.21 (2010-09-15) Subject: [Xen-devel] OProfile patch for Linux 3.0 X-BeenThere: xen-devel@lists.xensource.com X-Mailman-Version: 2.1.5 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xensource.com Errors-To: xen-devel-bounces@lists.xensource.com I have ported Anil's passive profile-capable OProfile patch to Linux 3.0. Please see: http://www.flyn.org/patches/linux-xen-passive-oprofile/linux-3.0-xen-passive-oprofile.patch.gz With this patch applied to Linux 3.0, I can perform passive profiling of an unprivileged Xen domain. -- Mike :wq _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel From xen-devel-bounces@lists.xensource.com Tue Sep 13 20:49:28 2011 Return-path: Envelope-to: www-data@lists.xensource.com Delivery-date: Tue, 13 Sep 2011 20:49:28 -0700 Received: from localhost ([127.0.0.1] helo=lists.colo.xensource.com) by lists.xensource.com with esmtp (Exim 4.43) id 1R3gTY-0003X6-87; Tue, 13 Sep 2011 20:49:28 -0700 Received: from mail216.messagelabs.com ([85.158.143.99]) by lists.xensource.com with esmtp (Exim 4.43) id 1R3gSe-0003K9-Qt; Tue, 13 Sep 2011 20:48:33 -0700 X-Env-Sender: hwang.jinho@gmail.com X-Msg-Ref: server-2.tower-216.messagelabs.com!1315972108!18160757!1 X-Originating-IP: [209.85.213.43] X-StarScan-Version: 6.3.6; banners=-,-,- X-VirusChecked: Checked Received: (qmail 27508 invoked from network); 14 Sep 2011 03:48:29 -0000 Received: from mail-yw0-f43.google.com (HELO mail-yw0-f43.google.com) (209.85.213.43) by server-2.tower-216.messagelabs.com with RC4-SHA encrypted SMTP; 14 Sep 2011 03:48:29 -0000 Received: by ywm21 with SMTP id 21so1316083ywm.30 for ; Tue, 13 Sep 2011 20:48:28 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=DZohC1OZ889BrS8kDFrMrz8MhXbULOoz/6nwNajW4Cg=; b=oShokc2P9CdOoJjSKBSRIKgw4/RsEEjc3BZBRMVzaUKCv5XDj+EOyrPf6gnYPku8jd ZB8t6d2xsK7g1n8qHrAhmmRZwt9C9iIq1UCOtByFIw7veF7Q4EJBjATHlJCQR9/MTDI9 OJALnJsl8VoiiQkPbYOigencprLHUXZJKKQhA= Received: by 10.150.63.2 with SMTP id l2mr3643910yba.63.1315972108092; Tue, 13 Sep 2011 20:48:28 -0700 (PDT) MIME-Version: 1.0 Received: by 10.151.154.16 with HTTP; Tue, 13 Sep 2011 20:48:08 -0700 (PDT) In-Reply-To: <4E700770.90204@goop.org> References: <4E700770.90204@goop.org> From: jinho hwang Date: Tue, 13 Sep 2011 23:48:08 -0400 Message-ID: Subject: Re: [Xen-devel] [Xen-users] current xen linux kernel branch? To: Jeremy Fitzhardinge Cc: xen-devel@lists.xensource.com, xen-users@lists.xensource.com X-BeenThere: xen-devel@lists.xensource.com X-Mailman-Version: 2.1.5 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1088039711==" Sender: xen-devel-bounces@lists.xensource.com Errors-To: xen-devel-bounces@lists.xensource.com --===============1088039711== Content-Type: multipart/alternative; boundary=000e0cd3b27c09852b04acdea227 --000e0cd3b27c09852b04acdea227 Content-Type: text/plain; charset=ISO-8859-1 I have successfully installed dom0 now, and try to run domUs on it. Thank you so much for your help. I will catch up soon, and try to find any contribution I can make. On Tue, Sep 13, 2011 at 9:46 PM, Jeremy Fitzhardinge wrote: > On 09/13/2011 02:15 PM, jinho hwang wrote: > > > > Hi, > > > > Where can I find the current xen linux kernel branch? The > > git.kernel.org has been down for maintenance > > reason, so I can't find any kernel source except xenbits.xensource.com > > . However, this repository does not have > > current linux dom0 kernel such as 2.6.32.*. Can anyone share with me > > the kernel source because I have to install xen environment in my > > intel 32/64bits machine. > > You can use upstream Linux for dom0, but it isn't quite as featureful as > the 2.6.32-based kernel. > > The 2.6.32 kernel is available at > git://github.com/jsgf/linux-xen.git xen/next-2.6.32 > > while kernel.org is down. > > J > -- Jinho Hwang PhD Student Department of Computer Science The George Washington University Washington, DC 20052 hwang.jinho@gmail.com (email) 276.336.0971 (Cell) 202.994.4875 (fax) 070.8285.6546 (myLg070) --000e0cd3b27c09852b04acdea227 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable

I have successfully installed dom0 now, and try to run domUs= on it.=A0
Thank you so much for your help. I will catch up soon, and t= ry to find any contribution I can make.=A0

On Tue, Sep 13, 2011 at 9:46 PM, Jeremy Fitzhardinge <= jeremy@goop.org>= ; wrote:
On 09/13/2011 02:15 PM, jinho hwang wrote:
>
> Hi,
>
> Where can I find the current xen linux kernel branch? The
> git.kernel.o= rg <http://git.k= ernel.org> has been down for maintenance
> reason, so I can't find any kernel source except xenbits.xensource.com
> <h= ttp://xenbits.xensource.com>. However, this repository does not have=
> current linux dom0 kernel such as 2.6.32.*. Can anyone share with= me
> the kernel source because I have to install xen environment in my
> intel 32/64bits machine.

You can use upstream Linux for dom0, but it isn't quite as featur= eful as
the 2.6.32-based kernel.

The 2.6.32 kernel is available at
=A0 =A0git://github.com/jsgf/linux-xen.git xen/next-2.6.32

while kernel.org is dow= n.

=A0 =A0J



--
Jinho= Hwang
PhD Student
Department of Computer Science
The George Washi= ngton University
Washington, DC 20052
hwang.jinho@gmail.com (email)
276.3= 36.0971 (Cell)
202.994.4875 (fax)
070.8285.6546 (myLg070)
--000e0cd3b27c09852b04acdea227-- --===============1088039711== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel --===============1088039711==-- From xen-devel-bounces@lists.xensource.com Tue Sep 13 22:16:32 2011 Return-path: Envelope-to: www-data@lists.xensource.com Delivery-date: Tue, 13 Sep 2011 22:16:32 -0700 Received: from localhost ([127.0.0.1] helo=lists.colo.xensource.com) by lists.xensource.com with esmtp (Exim 4.43) id 1R3hpo-0000A3-JP; Tue, 13 Sep 2011 22:16:32 -0700 Received: from mail174.messagelabs.com ([85.158.138.51]) by lists.xensource.com with esmtp (Exim 4.43) id 1R3hpA-0008P4-Qo for xen-devel@lists.xensource.com; Tue, 13 Sep 2011 22:15:53 -0700 X-Env-Sender: burns.me.uk@gmail.com X-Msg-Ref: server-9.tower-174.messagelabs.com!1315977348!25292040!1 X-Originating-IP: [209.85.212.41] X-StarScan-Version: 6.3.6; banners=-,-,- X-VirusChecked: Checked Received: (qmail 3902 invoked from network); 14 Sep 2011 05:15:49 -0000 Received: from mail-vw0-f41.google.com (HELO mail-vw0-f41.google.com) (209.85.212.41) by server-9.tower-174.messagelabs.com with RC4-SHA encrypted SMTP; 14 Sep 2011 05:15:49 -0000 Received: by vwm42 with SMTP id 42so1775144vwm.28 for ; Tue, 13 Sep 2011 22:15:48 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type; bh=1lU+/jWPg2v0LhESfXOD5ef1rIgFGz+skZrVkqcgjqU=; b=VsgunVEcIin53FCgdrXz0tP6Ziy09UwWsyn24UW/7WK9NjSw2UkXNKUhw6VtsXotWb aU96hq3LWxwLtrCfoG0CQPu5R1ubtc3fDJ2G+JBTJpZCb8xzUV2Jwy1WSG/phi5o8U5d GQm92TmY2DeSeGUrT+pIR2DAcnFN7EgYvCcg4= MIME-Version: 1.0 Received: by 10.52.66.70 with SMTP id d6mr2960573vdt.351.1315977347935; Tue, 13 Sep 2011 22:15:47 -0700 (PDT) Received: by 10.52.35.231 with HTTP; Tue, 13 Sep 2011 22:15:47 -0700 (PDT) In-Reply-To: <20110829201554.GA18533@imp.local> References: <20110829190056.GA10763@dumpdata.com> <20110829201554.GA18533@imp.local> Date: Wed, 14 Sep 2011 06:15:47 +0100 X-Google-Sender-Auth: L48iNPmUeMTdjlCx_Q-Vcnldf8E Message-ID: Subject: Re: [Xen-devel] Fedora Core 16 + Xen From: Andy Burns To: "W. Michael Petullo" Cc: xen-devel@lists.xensource.com, m.a.young@durham.ac.uk, Konrad Rzeszutek Wilk X-BeenThere: xen-devel@lists.xensource.com X-Mailman-Version: 2.1.5 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1483890677==" Sender: xen-devel-bounces@lists.xensource.com Errors-To: xen-devel-bounces@lists.xensource.com --===============1483890677== Content-Type: multipart/alternative; boundary=20cf3079bbf85b2d6204acdfda41 --20cf3079bbf85b2d6204acdfda41 Content-Type: text/plain; charset=ISO-8859-1 On 29 August 2011 21:15, W. Michael Petullo wrote: > > I was quite excited to see that with Fedora Core 16 I can just do: > > 'yum install xen' and the hypervisor is installed. > > See also in Red Hat Bugzilla: > > grub2 --class xen: initramfs missing, booting under XEN fails (found on > Fedora 16) > https://bugzilla.redhat.com/show_bug.cgi?id=728775 > > Yes I also encountered the "no initramfs" issue, I submitted a bug with a patch, before realising that BZ#728775 already existed, anyway I've DUPEd mine, who can get the relevant one-liner patch pushed? --20cf3079bbf85b2d6204acdfda41 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable On 29 August 2011 21:15, W. Michael Petullo <mike@flyn.org> wrote:
=A0
> I was quite excited to see that with Fedora Core 16 = I can just do:
> 'yum install xen' and the hypervisor is installed.

See also in Red Hat Bugzilla:

grub2 --class xen: initramfs missing, booting under XEN fails (found on Fed= ora 16)
https://bugzilla.redhat.com/show_bug.cgi?id=3D728775


Yes I also encountered the "no initramfs" issu= e, I submitted a bug with a patch, before realising that BZ#728775 already = existed, anyway I've DUPEd mine, who can get the relevant one-liner pat= ch pushed?

--20cf3079bbf85b2d6204acdfda41-- --===============1483890677== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel --===============1483890677==-- From xen-devel-bounces@lists.xensource.com Tue Sep 13 22:18:18 2011 Return-path: Envelope-to: www-data@lists.xensource.com Delivery-date: Tue, 13 Sep 2011 22:18:18 -0700 Received: from localhost ([127.0.0.1] helo=lists.colo.xensource.com) by lists.xensource.com with esmtp (Exim 4.43) id 1R3hrW-0000YL-Jl; Tue, 13 Sep 2011 22:18:18 -0700 Received: from mail27.messagelabs.com ([193.109.254.147]) by lists.xensource.com with esmtp (Exim 4.43) id 1R3hr4-0000LH-W4 for xen-devel@lists.xensource.com; Tue, 13 Sep 2011 22:17:51 -0700 X-Env-Sender: jeremy@goop.org X-Msg-Ref: server-13.tower-27.messagelabs.com!1315977455!39923245!1 X-Originating-IP: [74.207.240.146] X-StarScan-Version: 6.3.6; banners=-,-,- X-VirusChecked: Checked Received: (qmail 19667 invoked from network); 14 Sep 2011 05:17:36 -0000 Received: from claw.goop.org (HELO claw.goop.org) (74.207.240.146) by server-13.tower-27.messagelabs.com with DHE-RSA-AES256-SHA encrypted SMTP; 14 Sep 2011 05:17:36 -0000 Received: from saboo.goop.org (unknown [IPv6:2001:470:1f05:899:f2de:f1ff:fe5c:34ed]) (Authenticated sender: smtp-saboo) by claw.goop.org (Postfix) with ESMTPSA id 774BA908E; Tue, 13 Sep 2011 22:17:45 -0700 (PDT) Received: from saboo.goop.org (localhost [IPv6:::1]) by saboo.goop.org (Postfix) with ESMTP id 28A7720499; Tue, 13 Sep 2011 22:17:44 -0700 (PDT) Message-ID: <4E7038F8.309@goop.org> Date: Tue, 13 Sep 2011 22:17:44 -0700 From: Jeremy Fitzhardinge User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:6.0.2) Gecko/20110906 Thunderbird/6.0.2 MIME-Version: 1.0 To: "W. Michael Petullo" Subject: Re: [Xen-devel] OProfile patch for Linux 3.0 References: <20110914023052.GA9816@imp.local> In-Reply-To: <20110914023052.GA9816@imp.local> X-Enigmail-Version: 1.3.1 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: xen-devel@lists.xensource.com X-BeenThere: xen-devel@lists.xensource.com X-Mailman-Version: 2.1.5 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xensource.com Errors-To: xen-devel-bounces@lists.xensource.com On 09/13/2011 07:30 PM, W. Michael Petullo wrote: > I have ported Anil's passive profile-capable OProfile patch to Linux > 3.0. Please see: > > http://www.flyn.org/patches/linux-xen-passive-oprofile/linux-3.0-xen-passive-oprofile.patch.gz > > With this patch applied to Linux 3.0, I can perform passive > profiling of an unprivileged Xen domain. > Unfortunately this patch is unusable in the current form, so every now and again someone reports it to a current kernel, but its ends up being as useful as kicking a dead whale down the beach. I don't suppose you have any inclination to actually pick it apart and turn it into a useful series of functionally distinct patches so we can consider upstreaming it? (I guess you could consider that to be dynamiting the whale, but at that point the analogy completely comes apart in gory chunks.) Thanks, J _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel From xen-devel-bounces@lists.xensource.com Tue Sep 13 23:05:26 2011 Return-path: Envelope-to: www-data@lists.xensource.com Delivery-date: Tue, 13 Sep 2011 23:05:26 -0700 Received: from localhost ([127.0.0.1] helo=lists.colo.xensource.com) by lists.xensource.com with esmtp (Exim 4.43) id 1R3ib8-0002Mh-PM; Tue, 13 Sep 2011 23:05:26 -0700 Received: from mail174.messagelabs.com ([85.158.138.51]) by lists.xensource.com with esmtp (Exim 4.43) id 1R3iYu-00028j-IL for xen-devel@lists.xensource.com; Tue, 13 Sep 2011 23:03:22 -0700 X-Env-Sender: lidongyang@novell.com X-Msg-Ref: server-4.tower-174.messagelabs.com!1315980183!31344601!1 X-Originating-IP: [137.65.250.26] X-StarScan-Version: 6.4.1; banners=-,-,- X-VirusChecked: Checked Received: (qmail 25918 invoked from network); 14 Sep 2011 06:03:05 -0000 Received: from victor.provo.novell.com (HELO victor.provo.novell.com) (137.65.250.26) by server-4.tower-174.messagelabs.com with DHE-RSA-AES256-SHA encrypted SMTP; 14 Sep 2011 06:03:05 -0000 Received: from localhost.localdomain (prv-ext-foundry1int.gns.novell.com [137.65.251.240]) by victor.provo.novell.com with ESMTP (TLS encrypted); Wed, 14 Sep 2011 00:02:47 -0600 From: Li Dongyang To: xen-devel@lists.xensource.com Date: Wed, 14 Sep 2011 14:02:40 +0800 Message-Id: <1315980160-16935-1-git-send-email-lidongyang@novell.com> X-Mailer: git-send-email 1.7.6.1 Cc: JBeulich@novell.com, konrad.wilk@oracle.com Subject: [Xen-devel] [PATCH] xen-blkfront: fix a deadlock while handling discard response X-BeenThere: xen-devel@lists.xensource.com X-Mailman-Version: 2.1.5 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xensource.com Errors-To: xen-devel-bounces@lists.xensource.com When we get EOPNOTSUPP response for a discard request, we will clear the discard flag on the request queue so we won't attempt to send discard requests to backend again, and this should be protected under rq->queue_lock. However, when we setup the request queue, we pass blkif_io_lock to blk_init_queue so rq->queue_lock is blkif_io_lock indeed, and this lock is already taken when we are in blkif_interrpt, so remove the spin_lock/spin_unlock when we clear the discard flag or we will end up with deadlock here, Thanks Sorry for the stupid mistake. Signed-off-by: Li Dongyang --- drivers/block/xen-blkfront.c | 7 +++++-- 1 files changed, 5 insertions(+), 2 deletions(-) diff --git a/drivers/block/xen-blkfront.c b/drivers/block/xen-blkfront.c index 86e2c63..d9789f18 100644 --- a/drivers/block/xen-blkfront.c +++ b/drivers/block/xen-blkfront.c @@ -747,9 +747,12 @@ static irqreturn_t blkif_interrupt(int irq, void *dev_id) info->gd->disk_name); error = -EOPNOTSUPP; info->feature_discard = 0; - spin_lock(rq->queue_lock); + /* + * rq->queue_lock should be acquired before this call, + * it is actually blkif_io_lock, and already been taken + * once we are in blkif_interrupt + */ queue_flag_clear(QUEUE_FLAG_DISCARD, rq); - spin_unlock(rq->queue_lock); } __blk_end_request_all(req, error); break; -- 1.7.6.1 _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel From xen-devel-bounces@lists.xensource.com Wed Sep 14 00:04:50 2011 Return-path: Envelope-to: www-data@lists.xensource.com Delivery-date: Wed, 14 Sep 2011 00:04:50 -0700 Received: from localhost ([127.0.0.1] helo=lists.colo.xensource.com) by lists.xensource.com with esmtp (Exim 4.43) id 1R3jWb-0003ro-QC; Wed, 14 Sep 2011 00:04:49 -0700 Received: from mail216.messagelabs.com ([85.158.143.99]) by lists.xensource.com with smtp (Exim 4.43) id 1R3jT7-0003cr-6W for xen-devel@lists.xensource.com; Wed, 14 Sep 2011 00:01:47 -0700 X-Env-Sender: avi@redhat.com X-Msg-Ref: server-8.tower-216.messagelabs.com!1315983654!16653617!1 X-Originating-IP: [209.132.183.28] X-StarScan-Version: 6.3.6; banners=-,-,- X-VirusChecked: Checked Received: (qmail 27225 invoked from network); 14 Sep 2011 07:00:54 -0000 Received: from mx1.redhat.com (HELO mx1.redhat.com) (209.132.183.28) by server-8.tower-216.messagelabs.com with SMTP; 14 Sep 2011 07:00:54 -0000 Received: from int-mx10.intmail.prod.int.phx2.redhat.com (int-mx10.intmail.prod.int.phx2.redhat.com [10.5.11.23]) by mx1.redhat.com (8.14.4/8.14.4) with ESMTP id p8E70L5d012376 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Wed, 14 Sep 2011 03:00:21 -0400 Received: from mermaid.qumranet.com (vpn-200-151.tlv.redhat.com [10.35.200.151]) by int-mx10.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP id p8E709Rf008844; Wed, 14 Sep 2011 03:00:11 -0400 Message-ID: <4E7050F7.3000208@redhat.com> Date: Wed, 14 Sep 2011 10:00:07 +0300 From: Avi Kivity User-Agent: Mozilla/5.0 (X11; Linux i686 on x86_64; rv:6.0.2) Gecko/20110906 Thunderbird/6.0.2 MIME-Version: 1.0 To: Don Zickus References: <20110906182758.GR5795@redhat.com> <4E66EF86.9070200@redhat.com> <20110907134411.GV5795@redhat.com> <4E678992.5050709@redhat.com> <20110907155657.GX5795@redhat.com> <4E679AF4.50209@redhat.com> <20110907165203.GQ6838@redhat.com> <4E67A551.4000502@redhat.com> <20110913184044.GN5795@redhat.com> <20110913190320.GR7761@one.firstfloor.org> <20110913192152.GO5795@redhat.com> In-Reply-To: <20110913192152.GO5795@redhat.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Scanned-By: MIMEDefang 2.68 on 10.5.11.23 Cc: Jeremy Fitzhardinge , Marcelo Tosatti , Nick Piggin , KVM , Stefano Stabellini , Peter Zijlstra , the arch/x86 maintainers , Linux Kernel Mailing List , Andi Kleen , Jeremy Fitzhardinge , "H. Peter Anvin" , Ingo Molnar , Linus Torvalds , Xen Devel Subject: [Xen-devel] Re: [PATCH 08/13] xen/pvticketlock: disable interrupts while blocking X-BeenThere: xen-devel@lists.xensource.com X-Mailman-Version: 2.1.5 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xensource.com Errors-To: xen-devel-bounces@lists.xensource.com On 09/13/2011 10:21 PM, Don Zickus wrote: > Or are you saying an NMI in an idle system will have the same %rip thus > falsely detecting a back-to-back NMI? > > That's easy to avoid - insert an instruction zeroing the last nmi_rip somewhere before or after hlt. It's always okay to execute such an instruction (outside the nmi handler itself), since nmi_rip is meant to detect a "no instructions executed" condition. -- I have a truly marvellous patch that fixes the bug which this signature is too narrow to contain. _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel From xen-devel-bounces@lists.xensource.com Wed Sep 14 01:15:36 2011 Return-path: Envelope-to: www-data@lists.xensource.com Delivery-date: Wed, 14 Sep 2011 01:15:36 -0700 Received: from localhost ([127.0.0.1] helo=lists.colo.xensource.com) by lists.xensource.com with esmtp (Exim 4.43) id 1R3kd6-0007Sw-QH; Wed, 14 Sep 2011 01:15:36 -0700 Received: from mail182.messagelabs.com ([85.158.139.83]) by lists.xensource.com with esmtp (Exim 4.43) id 1R3kZg-0006ZI-9r for xen-devel@lists.xensource.com; Wed, 14 Sep 2011 01:12:05 -0700 X-Env-Sender: adi@cg.tuwien.ac.at X-Msg-Ref: server-6.tower-182.messagelabs.com!1315987920!18243935!1 X-Originating-IP: [213.129.229.198] X-StarScan-Version: 6.3.6; banners=-,-,- X-VirusChecked: Checked Received: (qmail 8562 invoked from network); 14 Sep 2011 08:12:01 -0000 Received: from vrvis-198.vrvis.at (HELO iris.vrvis.at) (213.129.229.198) by server-6.tower-182.messagelabs.com with AES256-SHA encrypted SMTP; 14 Sep 2011 08:12:01 -0000 Received: from actoris.vrvis.lan ([10.42.1.75] helo=vrvis.at) by iris.vrvis.at with esmtpsa (TLS1.0:DHE_RSA_AES_128_CBC_SHA1:16) (Exim 4.72) (envelope-from ) id 1R3kZY-0000HH-Q4; Wed, 14 Sep 2011 10:11:56 +0200 Date: Wed, 14 Sep 2011 10:11:56 +0200 From: Adi Kriegisch To: Konrad Rzeszutek Wilk Message-ID: <20110914081156.GB3079@vrvis.at> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline User-Agent: Mutt/1.5.20 (2009-06-14) X-SA-Exim-Connect-IP: 10.42.1.75 X-SA-Exim-Mail-From: adi@cg.tuwien.ac.at X-SA-Exim-Scanned: No (on iris.vrvis.at); SAEximRunCond expanded to false Cc: xen-devel@lists.xensource.com Subject: [Xen-devel] Dom0 ACPI S3 patches X-BeenThere: xen-devel@lists.xensource.com X-Mailman-Version: 2.1.5 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xensource.com Errors-To: xen-devel-bounces@lists.xensource.com Dear Konrad, just to let you know: I am using your patches[1] on my notebook (Thinkpad T61p) and they are working perfectly fine for me. I encountered three issues which I could solve: * Machine crashes some time after wakeup with "BUG: unable to handle kernel NULL pointer dereferenced at (null)". The crashing process was sshd as I am forwarding my window manager from a DomU to X with nouveau running on Dom0 with sdm. I fixed that by setting all interrupts in the BIOS to "auto-select" instead of the fixed default of "IRQ11". Since then I had no more crashes. * The DomUs do not resync their clock after Dom0 waking up. They're basically continue to count the time as if the sleep never happened. I have to run 'ntpdate' on resume on all the DomUs. I am not sure if there are any side effects of this; probably there is a more simple way to tell a DomU to reread clock from Dom0? * vbetool hangs at 100% CPU on resume (i/o waiting, I guess, because neither strace nor ltrace do show any activity). Simply killing vbetool (no -9) kind of "fixes" the issue. Probably I do not even need to run vbetool on resume. Anyways, thank you very much for your efforts in bringing decent Dom0 support to upstream kernel! Your patches applied cleanly to the Debian/testing package linux-image-3.0.0-1-amd64 (3.0.0-3) and work just fine! best regards, Adi Kriegisch [1] http://lists.xensource.com/archives/html/xen-devel/2011-08/msg01358.html _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel From xen-devel-bounces@lists.xensource.com Wed Sep 14 01:42:41 2011 Return-path: Envelope-to: www-data@lists.xensource.com Delivery-date: Wed, 14 Sep 2011 01:42:41 -0700 Received: from localhost ([127.0.0.1] helo=lists.colo.xensource.com) by lists.xensource.com with esmtp (Exim 4.43) id 1R3l3J-0000au-Cr; Wed, 14 Sep 2011 01:42:41 -0700 Received: from mail21.messagelabs.com ([85.158.143.35]) by lists.xensource.com with esmtp (Exim 4.43) id 1R3l1v-0000Do-4u for xen-devel@lists.xensource.com; Wed, 14 Sep 2011 01:41:16 -0700 X-Env-Sender: JBeulich@suse.com X-Msg-Ref: server-14.tower-21.messagelabs.com!1315989663!59507038!1 X-Originating-IP: [130.57.49.28] X-StarScan-Version: 6.4.1; banners=-,-,- X-VirusChecked: Checked Received: (qmail 29175 invoked from network); 14 Sep 2011 08:41:04 -0000 Received: from nat28.tlf.novell.com (HELO nat28.tlf.novell.com) (130.57.49.28) by server-14.tower-21.messagelabs.com with DHE-RSA-AES256-SHA encrypted SMTP; 14 Sep 2011 08:41:04 -0000 Received: from EMEA1-MTA by nat28.tlf.novell.com with Novell_GroupWise; Wed, 14 Sep 2011 09:42:08 +0100 Message-Id: <4E7084C30200007800055FBE@nat28.tlf.novell.com> X-Mailer: Novell GroupWise Internet Agent 8.0.1 Date: Wed, 14 Sep 2011 09:41:07 +0100 From: "Jan Beulich" To: "Adi Kriegisch" , "Konrad Rzeszutek Wilk" Subject: Re: [Xen-devel] Dom0 ACPI S3 patches References: <20110914081156.GB3079@vrvis.at> In-Reply-To: <20110914081156.GB3079@vrvis.at> Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: quoted-printable Content-Disposition: inline Cc: xen-devel@lists.xensource.com X-BeenThere: xen-devel@lists.xensource.com X-Mailman-Version: 2.1.5 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xensource.com Errors-To: xen-devel-bounces@lists.xensource.com >>> On 14.09.11 at 10:11, Adi Kriegisch wrote: > * The DomUs do not resync their clock after Dom0 waking up. They're > basically continue to count the time as if the sleep never happened. > I have to run 'ntpdate' on resume on all the DomUs. I am not sure if > there are any side effects of this; probably there is a more simple = way > to tell a DomU to reread clock from Dom0? This is a more fundamental problem - upstream pv-ops doesn't make use of XENFP_settime (or its bogus alias DOM_SETTIME) at all; only Jeremy's 2.6.32.x tree has this so far. Jan _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel From xen-devel-bounces@lists.xensource.com Wed Sep 14 01:49:38 2011 Return-path: Envelope-to: www-data@lists.xensource.com Delivery-date: Wed, 14 Sep 2011 01:49:38 -0700 Received: from localhost ([127.0.0.1] helo=lists.colo.xensource.com) by lists.xensource.com with esmtp (Exim 4.43) id 1R3lA1-00015S-GP; Wed, 14 Sep 2011 01:49:37 -0700 Received: from mail182.messagelabs.com ([85.158.139.83]) by lists.xensource.com with esmtp (Exim 4.43) id 1R3l9Q-0000sx-MF for xen-devel@lists.xensource.com; Wed, 14 Sep 2011 01:49:01 -0700 X-Env-Sender: dunlapg@gmail.com X-Msg-Ref: server-12.tower-182.messagelabs.com!1315990137!18100427!1 X-Originating-IP: [74.125.82.175] X-StarScan-Version: 6.3.6; banners=-,-,- X-VirusChecked: Checked Received: (qmail 31828 invoked from network); 14 Sep 2011 08:48:57 -0000 Received: from mail-wy0-f175.google.com (HELO mail-wy0-f175.google.com) (74.125.82.175) by server-12.tower-182.messagelabs.com with RC4-SHA encrypted SMTP; 14 Sep 2011 08:48:57 -0000 Received: by wyf19 with SMTP id 19so1362789wyf.6 for ; Wed, 14 Sep 2011 01:48:57 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=XpPGWHgpgKvxIQYrnaM4lWIM4f0xVJQ1cs5kMgV5Z84=; b=jJgSCkPhydrgvbZKN49dJXkOc7tQqd3sPq41UWvdxSQnyRSGSOqLq43bBWp2a2mm7z 3nPD6jeIGBRwZ2dnRzpzWQuljfrhlC5Klhcb6Iq11QOcRkgrVmNNC3LPjF7FGAPU9m2O LZ+IT1noAAbpsvkfZSoelSnp5Sa44B3L93PO0= MIME-Version: 1.0 Received: by 10.216.134.76 with SMTP id r54mr2266131wei.9.1315990137411; Wed, 14 Sep 2011 01:48:57 -0700 (PDT) Received: by 10.216.176.81 with HTTP; Wed, 14 Sep 2011 01:48:57 -0700 (PDT) In-Reply-To: <4E6F52430200007800055D18@nat28.tlf.novell.com> References: <4E6F52430200007800055D18@nat28.tlf.novell.com> Date: Wed, 14 Sep 2011 09:48:57 +0100 X-Google-Sender-Auth: s_EaHrt0YMgldcvWt_Jr-ZhbEN8 Message-ID: Subject: Re: [Xen-devel] [PATCH] xen, vtd: Fix device check for devices behind PCIe-to-PCI bridges From: George Dunlap To: Jan Beulich Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: xen-devel@lists.xensource.com, Keir Fraser X-BeenThere: xen-devel@lists.xensource.com X-Mailman-Version: 2.1.5 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xensource.com Errors-To: xen-devel-bounces@lists.xensource.com Ah yes, so it is. Sorry. -George On Tue, Sep 13, 2011 at 11:53 AM, Jan Beulich wrote: >>>> On 13.09.11 at 11:12, George Dunlap wrot= e: >> So what was the verdict on this one? =A0Is someone going to commit to >> doing a "fake pdev" thing? =A0If that's not going to happen before the >> 4.2 release, I suggest we take this patch in the mean time. > > Isn't this -unstable c/s 23813:5535d7ce2673? > > Jan > >> On Thu, Sep 1, 2011 at 3:20 PM, George Dunlap >> wrote: >>> On some systems, requests devices behind a PCIe-to-PCI bridge all >>> appear to the IOMMU as though they come from from slot 0, function >>> 0 on that device; so the mapping code much punch a hole for X:0.0 >>> in the IOMMU for such devices. =A0When punching the hole, if that devic= e >>> has already been mapped once, we simply need to check ownership to >>> make sure it's legal. =A0To do so, domain_context_mapping_one() will lo= ok >>> up the device for the mapping with pci_get_pdev() and look for the owne= r. >>> >>> However, if there is no device in X:0.0, this look up will fail. >>> >>> Rather than returning -ENODEV in this situation (causing a failure in >>> mapping the device), try to get the domain ownership from the iommu con= text >>> mapping itself. >>> >>> Signed-off-by: George Dunlap >>> >>> diff -r 4a4882df5649 -r ede81b0552be xen/drivers/passthrough/vtd/iommu.= c >>> --- a/xen/drivers/passthrough/vtd/iommu.c =A0 =A0 =A0 Wed Aug 31 15:23:= 49 2011 +0100 >>> +++ b/xen/drivers/passthrough/vtd/iommu.c =A0 =A0 =A0 Thu Sep 01 15:18:= 18 2011 >> +0100 >>> @@ -113,6 +113,27 @@ static int context_set_domain_id(struct >>> =A0 =A0 return 0; >>> =A0} >>> >>> +static int context_get_domain_id(struct context_entry *context, >>> + =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 struc= t iommu *iommu) >>> +{ >>> + =A0 =A0unsigned long dom_index, nr_dom; >>> + =A0 =A0int domid =3D -1; >>> + >>> + =A0 =A0if (iommu && context) >>> + =A0 =A0{ >>> + =A0 =A0 =A0 =A0nr_dom =3D cap_ndoms(iommu->cap); >>> + >>> + =A0 =A0 =A0 =A0dom_index =3D context_domain_id(*context); >>> + >>> + =A0 =A0 =A0 =A0if ( dom_index < nr_dom && iommu->domid_map) >>> + =A0 =A0 =A0 =A0 =A0 =A0domid =3D iommu->domid_map[dom_index]; >>> + =A0 =A0 =A0 =A0else >>> + =A0 =A0 =A0 =A0 =A0 =A0dprintk(XENLOG_DEBUG VTDPREFIX, "%s: dom_index= %lu exceeds >> nr_dom %lu or iommu has no domid_map\n", >>> + =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0__func__, dom_index, nr_dom); >>> + =A0 =A0} >>> + =A0 =A0return domid; >>> +} >>> + >>> =A0static struct intel_iommu *__init alloc_intel_iommu(void) >>> =A0{ >>> =A0 =A0 struct intel_iommu *intel; >>> @@ -1237,7 +1258,6 @@ int domain_context_mapping_one( >>> =A0 =A0 struct hvm_iommu *hd =3D domain_hvm_iommu(domain); >>> =A0 =A0 struct context_entry *context, *context_entries; >>> =A0 =A0 u64 maddr, pgd_maddr; >>> - =A0 =A0struct pci_dev *pdev =3D NULL; >>> =A0 =A0 int agaw; >>> >>> =A0 =A0 ASSERT(spin_is_locked(&pcidevs_lock)); >>> @@ -1249,12 +1269,45 @@ int domain_context_mapping_one( >>> =A0 =A0 if ( context_present(*context) ) >>> =A0 =A0 { >>> =A0 =A0 =A0 =A0 int res =3D 0; >>> + =A0 =A0 =A0 =A0struct pci_dev *pdev =3D NULL; >>> >>> + =A0 =A0 =A0 =A0/* First try to get domain ownership from device struc= ture. =A0If >> that's >>> + =A0 =A0 =A0 =A0 * not available, try to read it from the context itse= lf. */ >>> =A0 =A0 =A0 =A0 pdev =3D pci_get_pdev(bus, devfn); >>> - =A0 =A0 =A0 =A0if (!pdev) >>> - =A0 =A0 =A0 =A0 =A0 =A0res =3D -ENODEV; >>> - =A0 =A0 =A0 =A0else if (pdev->domain !=3D domain) >>> - =A0 =A0 =A0 =A0 =A0 =A0res =3D -EINVAL; >>> + =A0 =A0 =A0 =A0if ( pdev ) >>> + =A0 =A0 =A0 =A0{ >>> + =A0 =A0 =A0 =A0 =A0 =A0if ( pdev->domain !=3D domain ) >>> + =A0 =A0 =A0 =A0 =A0 =A0{ >>> + =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0dprintk(XENLOG_INFO VTDPREFIX, "d%d: b= df =3D %x:%x.%x owned >> by d%d!", >>> + =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0domain->domain_id, >>> + =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0bus, PCI_SLOT(devfn), = PCI_FUNC(devfn), >>> + =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0(pdev->domain) >>> + =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0? pdev->domain->domain= _id : -1); >>> + =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0res =3D -EINVAL; >>> + =A0 =A0 =A0 =A0 =A0 =A0} >>> + =A0 =A0 =A0 =A0} >>> + =A0 =A0 =A0 =A0else >>> + =A0 =A0 =A0 =A0{ >>> + =A0 =A0 =A0 =A0 =A0 =A0int cdomain; >>> + =A0 =A0 =A0 =A0 =A0 =A0cdomain =3D context_get_domain_id(context, iom= mu); >>> + >>> + =A0 =A0 =A0 =A0 =A0 =A0if ( cdomain < 0 ) >>> + =A0 =A0 =A0 =A0 =A0 =A0{ >>> + =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0dprintk(VTDPREFIX, "d%d: bdf =3D %x:%x= .%x mapped, but can't >> find owner!\n", >>> + =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0domain->domain_id, >>> + =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0bus, PCI_SLOT(devfn), = PCI_FUNC(devfn)); >>> + =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0res =3D -EINVAL; >>> + =A0 =A0 =A0 =A0 =A0 =A0} >>> + =A0 =A0 =A0 =A0 =A0 =A0else if ( cdomain !=3D domain->domain_id ) >>> + =A0 =A0 =A0 =A0 =A0 =A0{ >>> + =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0dprintk(XENLOG_INFO VTDPREFIX, "d%d: b= df =3D %x:%x.%x already >> mapped to d%d!", >>> + =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0domain->domain_id, >>> + =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0bus, PCI_SLOT(devfn), = PCI_FUNC(devfn), >>> + =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0cdomain); >>> + =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0res =3D -EINVAL; >>> + =A0 =A0 =A0 =A0 =A0 =A0} >>> + =A0 =A0 =A0 =A0} >>> + >>> =A0 =A0 =A0 =A0 unmap_vtd_domain_page(context_entries); >>> =A0 =A0 =A0 =A0 spin_unlock(&iommu->lock); >>> =A0 =A0 =A0 =A0 return res; >>> >>> _______________________________________________ >>> Xen-devel mailing list >>> Xen-devel@lists.xensource.com >>> http://lists.xensource.com/xen-devel >>> > > > > _______________________________________________ > Xen-devel mailing list > Xen-devel@lists.xensource.com > http://lists.xensource.com/xen-devel > _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel From xen-devel-bounces@lists.xensource.com Wed Sep 14 01:51:53 2011 Return-path: Envelope-to: www-data@lists.xensource.com Delivery-date: Wed, 14 Sep 2011 01:51:53 -0700 Received: from localhost ([127.0.0.1] helo=lists.colo.xensource.com) by lists.xensource.com with esmtp (Exim 4.43) id 1R3lCD-0001TQ-DB; Wed, 14 Sep 2011 01:51:53 -0700 Received: from mail174.messagelabs.com ([85.158.138.51]) by lists.xensource.com with esmtp (Exim 4.43) id 1R3lBk-0001HO-BA for xen-devel@lists.xensource.com; Wed, 14 Sep 2011 01:51:24 -0700 X-Env-Sender: dunlapg@gmail.com X-Msg-Ref: server-11.tower-174.messagelabs.com!1315990280!31348626!1 X-Originating-IP: [74.125.82.43] X-StarScan-Version: 6.4.1; banners=-,-,- X-VirusChecked: Checked Received: (qmail 9736 invoked from network); 14 Sep 2011 08:51:21 -0000 Received: from mail-ww0-f43.google.com (HELO mail-ww0-f43.google.com) (74.125.82.43) by server-11.tower-174.messagelabs.com with RC4-SHA encrypted SMTP; 14 Sep 2011 08:51:21 -0000 Received: by wwf27 with SMTP id 27so1513471wwf.24 for ; Wed, 14 Sep 2011 01:51:20 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=GLbZ8MfSqKrNmpdM/j237xos8IZIkOJE50WzSLi5OEk=; b=BtSZrlhpuJJKlzYOBtx7DSwbEMikyauYvPmxKysbGJKRAwR6TwFfi6EP8QlbxrQbXD cv2Hq6GulDmpPLENiFAbjRdXWOu1LpzurEeYOa5Nii4RxZQld/DZPVB8bDXiM4EcS4R5 ojjAQPjYfyVyrCOXu0AN0jMa2jItJTWpXNajw= MIME-Version: 1.0 Received: by 10.216.131.39 with SMTP id l39mr4180725wei.39.1315990279873; Wed, 14 Sep 2011 01:51:19 -0700 (PDT) Received: by 10.216.176.81 with HTTP; Wed, 14 Sep 2011 01:51:19 -0700 (PDT) In-Reply-To: <86f2a3a45ecbcc49aba8.1315910179@nehalem1> References: <86f2a3a45ecbcc49aba8.1315910179@nehalem1> Date: Wed, 14 Sep 2011 09:51:19 +0100 X-Google-Sender-Auth: M7plZ7nrBFNy5uLQWjwXw1CfxYI Message-ID: Subject: Re: [Xen-devel] [PATCH] Avoid race in schedule() when switching schedulers From: George Dunlap To: Juergen Gross Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: xen-devel@lists.xensource.com X-BeenThere: xen-devel@lists.xensource.com X-Mailman-Version: 2.1.5 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xensource.com Errors-To: xen-devel-bounces@lists.xensource.com Acked-by: George Dunlap On Tue, Sep 13, 2011 at 11:36 AM, Juergen Gross wrote: > Selecting the scheduler to call must be done under lock. Otherwise a race > might occur when switching schedulers in a cpupool > > Signed-off-by: juergen.gross@ts.fujitsu.com > > > 1 file changed, 2 insertions(+), 1 deletion(-) > xen/common/schedule.c | =A0 =A03 ++- > > > > _______________________________________________ > Xen-devel mailing list > Xen-devel@lists.xensource.com > http://lists.xensource.com/xen-devel > > _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel From xen-devel-bounces@lists.xensource.com Wed Sep 14 02:04:13 2011 Return-path: Envelope-to: www-data@lists.xensource.com Delivery-date: Wed, 14 Sep 2011 02:04:13 -0700 Received: from localhost ([127.0.0.1] helo=lists.colo.xensource.com) by lists.xensource.com with esmtp (Exim 4.43) id 1R3lO8-00022v-VR; Wed, 14 Sep 2011 02:04:13 -0700 Received: from mail174.messagelabs.com ([85.158.138.51]) by lists.xensource.com with esmtp (Exim 4.43) id 1R3lKl-0001np-L5 for xen-devel@lists.xensource.com; Wed, 14 Sep 2011 02:01:07 -0700 X-Env-Sender: konrad@oracle.com X-Msg-Ref: server-2.tower-174.messagelabs.com!1315990837!31357342!1 X-Originating-IP: [141.146.126.227] X-StarScan-Version: 6.4.1; banners=-,-,- X-VirusChecked: Checked Received: (qmail 22414 invoked from network); 14 Sep 2011 09:00:40 -0000 Received: from acsinet15.oracle.com (HELO acsinet15.oracle.com) (141.146.126.227) by server-2.tower-174.messagelabs.com with DHE-RSA-AES256-SHA encrypted SMTP; 14 Sep 2011 09:00:40 -0000 Received: from acsinet21.oracle.com (acsinet21.oracle.com [141.146.126.237]) by acsinet15.oracle.com (Switch-3.4.4/Switch-3.4.4) with ESMTP id p8E90WKO022648 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Wed, 14 Sep 2011 09:00:34 GMT Received: from acsmt357.oracle.com (acsmt357.oracle.com [141.146.40.157]) by acsinet21.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id p8E90Wqd017378 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 14 Sep 2011 09:00:32 GMT Received: from abhmt103.oracle.com (abhmt103.oracle.com [141.146.116.55]) by acsmt357.oracle.com (8.12.11.20060308/8.12.11) with ESMTP id p8E90QbB002415; Wed, 14 Sep 2011 04:00:26 -0500 Received: from oracle.com (/209.6.55.207) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Wed, 14 Sep 2011 02:00:26 -0700 Received: by oracle.com (Postfix, from userid 1000) id E65721211; Wed, 14 Sep 2011 05:00:26 -0400 (EDT) Date: Wed, 14 Sep 2011 05:00:26 -0400 From: Konrad Rzeszutek Wilk To: "W. Michael Petullo" Subject: Re: [Xen-devel] OProfile patch for Linux 3.0 Message-ID: <20110914090026.GC25628@phenom.oracle.com> References: <20110914023052.GA9816@imp.local> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20110914023052.GA9816@imp.local> User-Agent: Mutt/1.5.21 (2010-09-15) X-Source-IP: acsinet21.oracle.com [141.146.126.237] X-Auth-Type: Internal IP X-CT-RefId: str=0001.0A020204.4E706D33.0076:SCFMA922111,ss=1,re=-4.000,fgs=0 Cc: xen-devel@lists.xensource.com X-BeenThere: xen-devel@lists.xensource.com X-Mailman-Version: 2.1.5 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xensource.com Errors-To: xen-devel-bounces@lists.xensource.com On Tue, Sep 13, 2011 at 09:30:52PM -0500, W. Michael Petullo wrote: > I have ported Anil's passive profile-capable OProfile patch to Linux > 3.0. Please see: > > http://www.flyn.org/patches/linux-xen-passive-oprofile/linux-3.0-xen-passive-oprofile.patch.gz > > With this patch applied to Linux 3.0, I can perform passive > profiling of an unprivileged Xen domain. Nice! Any chance you would have this patchset in a git tree that I could pull! Thanks for doing this. _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel From xen-devel-bounces@lists.xensource.com Wed Sep 14 02:10:05 2011 Return-path: Envelope-to: www-data@lists.xensource.com Delivery-date: Wed, 14 Sep 2011 02:10:05 -0700 Received: from localhost ([127.0.0.1] helo=lists.colo.xensource.com) by lists.xensource.com with esmtp (Exim 4.43) id 1R3lTo-0002To-Tg; Wed, 14 Sep 2011 02:10:04 -0700 Received: from mail174.messagelabs.com ([85.158.138.51]) by lists.xensource.com with esmtp (Exim 4.43) id 1R3lSq-0002GX-FQ; Wed, 14 Sep 2011 02:09:09 -0700 X-Env-Sender: konrad@oracle.com X-Msg-Ref: server-7.tower-174.messagelabs.com!1315991333!31334426!1 X-Originating-IP: [141.146.126.227] X-StarScan-Version: 6.4.1; banners=-,-,- X-VirusChecked: Checked Received: (qmail 27400 invoked from network); 14 Sep 2011 09:09:00 -0000 Received: from acsinet15.oracle.com (HELO acsinet15.oracle.com) (141.146.126.227) by server-7.tower-174.messagelabs.com with DHE-RSA-AES256-SHA encrypted SMTP; 14 Sep 2011 09:09:00 -0000 Received: from rtcsinet21.oracle.com (rtcsinet21.oracle.com [66.248.204.29]) by acsinet15.oracle.com (Switch-3.4.4/Switch-3.4.4) with ESMTP id p8E98EC4006873 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Wed, 14 Sep 2011 09:08:16 GMT Received: from acsmt356.oracle.com (acsmt356.oracle.com [141.146.40.156]) by rtcsinet21.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id p8E98C6p029301 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 14 Sep 2011 09:08:12 GMT Received: from abhmt104.oracle.com (abhmt104.oracle.com [141.146.116.56]) by acsmt356.oracle.com (8.12.11.20060308/8.12.11) with ESMTP id p8E986aW003186; Wed, 14 Sep 2011 04:08:06 -0500 Received: from oracle.com (/209.6.55.207) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Wed, 14 Sep 2011 02:08:06 -0700 Received: by oracle.com (Postfix, from userid 1000) id 7F0AF1211; Wed, 14 Sep 2011 05:08:06 -0400 (EDT) Date: Wed, 14 Sep 2011 05:08:06 -0400 From: Konrad Rzeszutek Wilk To: jim burns , Ian Campbell Subject: Re: [Xen-devel] Re: [Xen-users] Continuing BUG:-iness booting Fedora Rawhide 3.1.0-rc's (was Summary: Experiences setting up a debug serial port) Message-ID: <20110914090806.GD25628@phenom.oracle.com> References: <201107231426.56811.jim_burn@bellsouth.net> <1342436.B0x3ddQn4U@dell4550> <20110913085559.GG12984@reaktio.net> <1856036.eYCcuDQrZC@dell4550> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <1856036.eYCcuDQrZC@dell4550> User-Agent: Mutt/1.5.21 (2010-09-15) X-Source-IP: rtcsinet21.oracle.com [66.248.204.29] X-CT-RefId: str=0001.0A02020B.4E706F01.0118,ss=1,re=0.000,fgs=0 Cc: Todd Deshane , xen-devel@lists.xensource.com, xen-users@lists.xensource.com, Fedora Xen List X-BeenThere: xen-devel@lists.xensource.com X-Mailman-Version: 2.1.5 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xensource.com Errors-To: xen-devel-bounces@lists.xensource.com > Rawhide just came out with 3.1.0-0.rc6.git0.0.fc17.x86_64 , and the BUG:s are > still the same as in the last log I sent. However, as promised I have attached > the initcall_debug log, but for rc6. Hey Jim, We are quite sure we know the cause of this. I was wondering if you would be up for beta-testing a patch for this? _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel From xen-devel-bounces@lists.xensource.com Wed Sep 14 02:37:08 2011 Return-path: Envelope-to: www-data@lists.xensource.com Delivery-date: Wed, 14 Sep 2011 02:37:08 -0700 Received: from localhost ([127.0.0.1] helo=lists.colo.xensource.com) by lists.xensource.com with esmtp (Exim 4.43) id 1R3lu0-0004fk-Ll; Wed, 14 Sep 2011 02:37:08 -0700 Received: from mail21.messagelabs.com ([85.158.143.35]) by lists.xensource.com with esmtp (Exim 4.43) id 1R3lt7-0004R1-ST for xen-devel@lists.xensource.com; Wed, 14 Sep 2011 02:36:14 -0700 X-Env-Sender: Ian.Jackson@eu.citrix.com X-Msg-Ref: server-12.tower-21.messagelabs.com!1315992955!49872330!1 X-Originating-IP: [62.200.22.115] X-StarScan-Version: 6.4.1; banners=-,-,- X-VirusChecked: Checked Received: (qmail 14113 invoked from network); 14 Sep 2011 09:35:56 -0000 Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115) by server-12.tower-21.messagelabs.com with RC4-SHA encrypted SMTP; 14 Sep 2011 09:35:56 -0000 X-IronPort-AV: E=Sophos;i="4.68,379,1312156800"; d="scan'208";a="7799066" Received: from lonpmailmx01.citrite.net ([10.30.203.162]) by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5; 14 Sep 2011 09:36:10 +0000 Received: from norwich.cam.xci-test.com (10.80.248.129) by smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id 8.3.137.0; Wed, 14 Sep 2011 10:36:10 +0100 Received: from mariner.cam.xci-test.com ([10.80.2.22] helo=mariner.uk.xensource.com ident=Debian-exim) by norwich.cam.xci-test.com with esmtp (Exim 4.72) (envelope-from ) id 1R3lt4-0000Uy-Av for xen-devel@lists.xensource.com; Wed, 14 Sep 2011 09:36:10 +0000 Received: from iwj by mariner.uk.xensource.com with local (Exim 4.69) (envelope-from ) id 1R3lt4-0004Oe-99 for xen-devel@lists.xensource.com; Wed, 14 Sep 2011 10:36:10 +0100 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Message-ID: <20080.30090.236544.113147@mariner.uk.xensource.com> Date: Wed, 14 Sep 2011 10:36:10 +0100 To: xen-devel@lists.xensource.com X-Mailer: VM 7.19 under Emacs 21.4.1 From: Ian Jackson Subject: [Xen-devel] [PATCH] libxl: document memory parameters and behaviour X-BeenThere: xen-devel@lists.xensource.com X-Mailman-Version: 2.1.5 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xensource.com Errors-To: xen-devel-bounces@lists.xensource.com commit a6b0f1e47447b7da2e838f9f68caf2019b177c36 Author: Ian Jackson Date: Wed Sep 14 10:34:54 2011 +0100 libxl: document memory parameters and behaviour Introduce a new comment in libxl.h, describing the various guest memory usage parameters. Signed-off-by: Ian Jackson diff --git a/tools/libxl/libxl.h b/tools/libxl/libxl.h index d146575..6999d54 100644 --- a/tools/libxl/libxl.h +++ b/tools/libxl/libxl.h @@ -349,8 +349,62 @@ int libxl_domain_unpause(libxl_ctx *ctx, uint32_t domid); int libxl_domain_core_dump(libxl_ctx *ctx, uint32_t domid, const char *filename); +/* + * Domains have three memory parameters: + * + * * Target ("target"). This is the request from the toolstack to + * the guest's balloon system. With a cooperative guest, the + * guest will adjust its memory usage towards this target (by + * requesting more memory from Xen, or returning memory to Xen, as + * applicable). + * + * * Limit ("maxmem" while the domain is running; set to the same as + * "target_memkb" on creation). Xen will not allow the guest to + * increase its allocation (by requesting more memory from Xen) if + * the guest would then be using more memory than this. However, + * getting memory back from the guest requires the cooperation of + * the guest, so if the limit has previously been reduced below + * the guest's current usage, the guest's actual usage may remain + * above the limit. + * + * * Boot-time memory maximum (the "max_memkb" domain creation + * parameter). This is the absolute maximum amount of memory the + * domain will ever be able to allocate. (In theory a balloon + * driver capable of memory hotplug might be able to surpass this + * limit but currently the toolstack does not support this.) + * + * Domains actually use a bit more memory than they see directly; all + * of these parameters in the libxl API are specified in terms of + * guest-visible memory. The actual guest memory usage will be + * somewhat higher because some is needed for infrastructure purposes + * related to the domain (Xen heap entries, video memory offered to + * hvm guests, memory for a device model stub domain, etc.). The + * amount of memory which would actually be necessary for a particular + * guest can be discovered with the libxl_domain_need_memory call. + * + * Note that when a guest's target is changed, while in principle the + * guest's actual memory usage is supposed to eventually reach the new + * target, this may not ever happen. The guest may not have a + * suitable balloon driver, or it may not be sufficiently cooperative + * (eg, the guest admin may have arranged for it not to honour + * requests to use less memory), or it may be under severe memory + * pressure and not able to comply. Even requests to increase memory + * usage may not be honoured, for example because the increase would + * take the guest beyond a compiled-in or boot-time limit. + * + * It is not proper for the limit to be less than the target. + * + * When creating an HVM guest, if target is less than max_memkb, + * populate-on-demand is used. In this situation the guest must have + * a balloon driver which must reclaim enough p-o-d guest memory + * quickly enough, or the guest will crash during boot. + */ + int libxl_domain_setmaxmem(libxl_ctx *ctx, uint32_t domid, uint32_t target_memkb); int libxl_set_memory_target(libxl_ctx *ctx, uint32_t domid, int32_t target_memkb, int relative, int enforce); + /* if enforce is set, sets the target too. NB that there is a bug here, + * in that if you reduce the target with enforce=1 and then increase it + * again with enforce=0, the limit will now be less than the target. */ int libxl_get_memory_target(libxl_ctx *ctx, uint32_t domid, uint32_t *out_target); /* how much free memory in the system a domain needs to be built */ int libxl_domain_need_memory(libxl_ctx *ctx, libxl_domain_build_info *b_info, _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel From xen-devel-bounces@lists.xensource.com Wed Sep 14 03:22:22 2011 Return-path: Envelope-to: www-data@lists.xensource.com Delivery-date: Wed, 14 Sep 2011 03:22:22 -0700 Received: from localhost ([127.0.0.1] helo=lists.colo.xensource.com) by lists.xensource.com with esmtp (Exim 4.43) id 1R3mbm-0006VM-0z; Wed, 14 Sep 2011 03:22:22 -0700 Received: from mail216.messagelabs.com ([85.158.143.99]) by lists.xensource.com with esmtp (Exim 4.43) id 1R3mav-0006IL-Ec for xen-devel@lists.xensource.com; Wed, 14 Sep 2011 03:21:29 -0700 X-Env-Sender: konrad@oracle.com X-Msg-Ref: server-10.tower-216.messagelabs.com!1315995685!10130694!1 X-Originating-IP: [141.146.126.227] X-StarScan-Version: 6.4.1; banners=-,-,- X-VirusChecked: Checked Received: (qmail 20520 invoked from network); 14 Sep 2011 10:21:26 -0000 Received: from acsinet15.oracle.com (HELO acsinet15.oracle.com) (141.146.126.227) by server-10.tower-216.messagelabs.com with DHE-RSA-AES256-SHA encrypted SMTP; 14 Sep 2011 10:21:26 -0000 Received: from rtcsinet21.oracle.com (rtcsinet21.oracle.com [66.248.204.29]) by acsinet15.oracle.com (Switch-3.4.4/Switch-3.4.4) with ESMTP id p8EALJjB030612 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Wed, 14 Sep 2011 10:21:21 GMT Received: from acsmt358.oracle.com (acsmt358.oracle.com [141.146.40.158]) by rtcsinet21.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id p8EALHOp025352 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 14 Sep 2011 10:21:18 GMT Received: from abhmt118.oracle.com (abhmt118.oracle.com [141.146.116.70]) by acsmt358.oracle.com (8.12.11.20060308/8.12.11) with ESMTP id p8EALCot005629; Wed, 14 Sep 2011 05:21:12 -0500 Received: from oracle.com (/209.6.55.207) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Wed, 14 Sep 2011 03:21:12 -0700 Received: by oracle.com (Postfix, from userid 1000) id 5CB561211; Wed, 14 Sep 2011 06:21:12 -0400 (EDT) Date: Wed, 14 Sep 2011 06:21:12 -0400 From: Konrad Rzeszutek Wilk To: Adi Kriegisch Message-ID: <20110914102112.GB15866@phenom.oracle.com> References: <20110914081156.GB3079@vrvis.at> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20110914081156.GB3079@vrvis.at> User-Agent: Mutt/1.5.21 (2010-09-15) X-Source-IP: rtcsinet21.oracle.com [66.248.204.29] X-CT-RefId: str=0001.0A090208.4E708021.0089,ss=1,re=0.000,fgs=0 Cc: xen-devel@lists.xensource.com Subject: [Xen-devel] Re: Dom0 ACPI S3 patches X-BeenThere: xen-devel@lists.xensource.com X-Mailman-Version: 2.1.5 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xensource.com Errors-To: xen-devel-bounces@lists.xensource.com On Wed, Sep 14, 2011 at 10:11:56AM +0200, Adi Kriegisch wrote: > Dear Konrad, > > just to let you know: I am using your patches[1] on my notebook (Thinkpad Excellent. Is it OK if I put 'Tested-by: Adi Kriegish" on them? > T61p) and they are working perfectly fine for me. I encountered three issues Wait, T61p.. Can you actually do 64-bit on that laptop?Or are you using a 32-bit hypervisor? > which I could solve: > * Machine crashes some time after wakeup with "BUG: unable to handle kernel > NULL pointer dereferenced at (null)". The crashing process was sshd as I > am forwarding my window manager from a DomU to X with nouveau running on > Dom0 with sdm. > I fixed that by setting all interrupts in the BIOS to "auto-select" > instead of the fixed default of "IRQ11". Since then I had no more crashes. Ok, any other data? Stack trace? > * The DomUs do not resync their clock after Dom0 waking up. They're > basically continue to count the time as if the sleep never happened. > I have to run 'ntpdate' on resume on all the DomUs. I am not sure if > there are any side effects of this; probably there is a more simple way > to tell a DomU to reread clock from Dom0? You know, I don't know. I just never thought about that - um. I wonder if it is related to the RTC update patch that I've been meaning to take a look at: http://lists.xensource.com/archives/html/xen-devel/2010-02/msg00469.html > * vbetool hangs at 100% CPU on resume (i/o waiting, I guess, because > neither strace nor ltrace do show any activity). Simply killing vbetool > (no -9) kind of "fixes" the issue. Probably I do not even need to run > vbetool on resume. Why do you run it? Anyhow there is a patch for vbetool to work correctly with Nvidia drivers .. somewhere. ah, here. diff --git a/drivers/char/mem.c b/drivers/char/mem.c index 1256454..3d91e46 100644 --- a/drivers/char/mem.c +++ b/drivers/char/mem.c @@ -316,9 +316,14 @@ static int mmap_mem(struct file *file, struct vm_area_struct *vma) &vma->vm_page_prot)) return -EINVAL; - vma->vm_page_prot = phys_mem_access_prot(file, vma->vm_pgoff, - size, - vma->vm_page_prot); + vma->vm_flags |= VM_RESERVED | VM_IO | VM_PFNMAP | VM_DONTEXPAND; + vma->vm_page_prot = __pgprot( + pgprot_val(vm_get_page_prot(vma->vm_flags)) | + _PAGE_IOMAP | + pgprot_val(phys_mem_access_prot(file, + vma->vm_pgoff, + size, + vma->vm_page_prot))); vma->vm_ops = &mmap_mem_ops; > > Anyways, thank you very much for your efforts in bringing decent Dom0 > support to upstream kernel! Your patches applied cleanly to the > Debian/testing package linux-image-3.0.0-1-amd64 (3.0.0-3) and work just > fine! Woot! > > best regards, > Adi Kriegisch > > [1] http://lists.xensource.com/archives/html/xen-devel/2011-08/msg01358.html _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel From xen-devel-bounces@lists.xensource.com Wed Sep 14 03:38:12 2011 Return-path: Envelope-to: www-data@lists.xensource.com Delivery-date: Wed, 14 Sep 2011 03:38:12 -0700 Received: from localhost ([127.0.0.1] helo=lists.colo.xensource.com) by lists.xensource.com with esmtp (Exim 4.43) id 1R3mr6-0007CR-FI; Wed, 14 Sep 2011 03:38:12 -0700 Received: from mail174.messagelabs.com ([85.158.138.51]) by lists.xensource.com with esmtp (Exim 4.43) id 1R3mqV-0006zs-8V for xen-devel@lists.xensource.com; Wed, 14 Sep 2011 03:37:35 -0700 X-Env-Sender: olaf@aepfle.de X-Msg-Ref: server-15.tower-174.messagelabs.com!1315996436!25021658!1 X-Originating-IP: [81.169.146.160] X-StarScan-Version: 6.4.1; banners=-,-,- X-VirusChecked: Checked Received: (qmail 21691 invoked from network); 14 Sep 2011 10:37:21 -0000 Received: from mo-p00-ob.rzone.de (HELO mo-p00-ob.rzone.de) (81.169.146.160) by server-15.tower-174.messagelabs.com with EDH-RSA-DES-CBC3-SHA encrypted SMTP; 14 Sep 2011 10:37:21 -0000 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; t=1315996431; l=668; s=domk; d=aepfle.de; h=In-Reply-To:Content-Type:MIME-Version:References:Subject:Cc:To:From: Date:X-RZG-CLASS-ID:X-RZG-AUTH; bh=1CWmJCSJAnxDj6bF2L70+VXjyWc=; b=khLCIYLQs3/dGBvQgomvB/uRnFucif9ZP3VFCh3Riv26BmSyrAD4etXn2iVEYyfx0jm 8FmZXA5DihxDyTfZB0jw68H/reDDHqVEF3SbYvCxzyvNNpnbNUpUA9XL1Kdxhmfqdf8Bk oyWB3Pe/M6ogsmzeLdzKaPllMJPppv+V6os= X-RZG-AUTH: :P2EQZWCpfu+qG7CngxMFH1J+zrwiavkK6tmQaLfmxtMZ80VwmRNV71Y= X-RZG-CLASS-ID: mo00 Received: from probook.site (ip-80-226-24-5.vodafone-net.de [80.226.24.5]) by smtp.strato.de (klopstock mo5) (RZmta 26.7) with (EDH-RSA-DES-CBC3-SHA encrypted) ESMTPA id Y03c13n8E98s1F ; Wed, 14 Sep 2011 12:33:44 +0200 (MEST) Received: by probook.site (Postfix, from userid 1000) id EAE9E18B66; Wed, 14 Sep 2011 12:33:41 +0200 (CEST) Date: Wed, 14 Sep 2011 12:33:41 +0200 From: Olaf Hering To: Ian Jackson Subject: Re: [Xen-devel] [PATCH] libxl: document memory parameters and behaviour Message-ID: <20110914103341.GA21508@aepfle.de> References: <20080.30090.236544.113147@mariner.uk.xensource.com> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline In-Reply-To: <20080.30090.236544.113147@mariner.uk.xensource.com> User-Agent: Mutt/1.5.21.rev5535 (2011-07-01) Cc: xen-devel@lists.xensource.com X-BeenThere: xen-devel@lists.xensource.com X-Mailman-Version: 2.1.5 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xensource.com Errors-To: xen-devel-bounces@lists.xensource.com On Wed, Sep 14, Ian Jackson wrote: > commit a6b0f1e47447b7da2e838f9f68caf2019b177c36 > Author: Ian Jackson > Date: Wed Sep 14 10:34:54 2011 +0100 > > libxl: document memory parameters and behaviour > > Introduce a new comment in libxl.h, describing the various guest > memory usage parameters. Thanks for documenting this. How do the three describe values relate to xc_dominfo_t->nr_pages? The comment there suggests that nr_pages could be even higher at some point. Is the max number of pages a domain can allocate (xc_dominfo_t->max_memkb / 1024)? If so, then xenpaging should not use nr_pages but max_memkb. Olaf _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel From xen-devel-bounces@lists.xensource.com Wed Sep 14 03:46:57 2011 Return-path: Envelope-to: www-data@lists.xensource.com Delivery-date: Wed, 14 Sep 2011 03:46:57 -0700 Received: from localhost ([127.0.0.1] helo=lists.colo.xensource.com) by lists.xensource.com with esmtp (Exim 4.43) id 1R3mzY-0007oL-S6; Wed, 14 Sep 2011 03:46:57 -0700 Received: from mail182.messagelabs.com ([85.158.139.83]) by lists.xensource.com with esmtp (Exim 4.43) id 1R3myu-0007cD-7b for xen-devel@lists.xensource.com; Wed, 14 Sep 2011 03:46:17 -0700 X-Env-Sender: Ian.Jackson@eu.citrix.com X-Msg-Ref: server-5.tower-182.messagelabs.com!1315997172!13291654!1 X-Originating-IP: [62.200.22.115] X-StarScan-Version: 6.4.1; banners=-,-,- X-VirusChecked: Checked Received: (qmail 19827 invoked from network); 14 Sep 2011 10:46:13 -0000 Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115) by server-5.tower-182.messagelabs.com with RC4-SHA encrypted SMTP; 14 Sep 2011 10:46:13 -0000 X-IronPort-AV: E=Sophos;i="4.68,379,1312156800"; d="scan'208";a="7802456" Received: from lonpmailmx01.citrite.net ([10.30.203.162]) by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5; 14 Sep 2011 10:46:12 +0000 Received: from norwich.cam.xci-test.com (10.80.248.129) by smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id 8.3.137.0; Wed, 14 Sep 2011 11:46:12 +0100 Received: from mariner.cam.xci-test.com ([10.80.2.22] helo=mariner.uk.xensource.com ident=Debian-exim) by norwich.cam.xci-test.com with esmtp (Exim 4.72) (envelope-from ) id 1R3myq-0000ta-7N; Wed, 14 Sep 2011 10:46:12 +0000 Received: from iwj by mariner.uk.xensource.com with local (Exim 4.69) (envelope-from ) id 1R3myq-0007w0-6J; Wed, 14 Sep 2011 11:46:12 +0100 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Message-ID: <20080.34292.184645.829955@mariner.uk.xensource.com> Date: Wed, 14 Sep 2011 11:46:12 +0100 To: "xen-devel@lists.xensource.com" , "keir@xen.org" , Stefano Stabellini In-Reply-To: References: X-Mailer: VM 8.0.9 under Emacs 21.4.1 (i486-pc-linux-gnu) From: Ian Jackson Cc: Subject: [Xen-devel] tools: Revert seabios and upstream qemu build changes X-BeenThere: xen-devel@lists.xensource.com X-Mailman-Version: 2.1.5 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xensource.com Errors-To: xen-devel-bounces@lists.xensource.com xen.org writes ("[xen-unstable bisection] complete build-i386-oldkern"): > branch xen-unstable > xen branch xen-unstable > job build-i386-oldkern > test xen-build > > Tree: linux http://hg.uk.xensource.com/linux-2.6.18-xen.hg > Tree: xen http://hg.uk.xensource.com/xen-unstable.hg > > *** Found and reproduced problem changeset *** > > Bug is in tree: xen http://hg.uk.xensource.com/xen-unstable.hg > Bug introduced: 0d21b68f528b > Bug not present: d1d6abc1db20 > > > changeset: 23828:0d21b68f528b > user: Stefano Stabellini > date: Tue Sep 13 10:27:20 2011 +0100 > > Move the ioemu-dir-find shell script to an external file > > Add support for configuring upstream qemu and rename ioemu-remote > ioemu-dir-remote. > > Signed-off-by: Stefano Stabellini # Date 1315996693 -3600 # Node ID e90438f6e6d1585a71b18784a99c162b5d95f390 # Parent 51913fe3d25a3756edf9af02843abdb36873618d tools: Revert seabios and upstream qemu build changes These have broken the build and it seems to be difficult to fix. So we will revert the whole lot for now, and await corrected patch(es). Revert "fix the build when CONFIG_QEMU is specified by the user" Revert "tools: fix permissions of git-checkout.sh" Revert "scripts/git-checkout.sh: Is not bash specific. Invoke with /bin/sh." Revert "Clone and build Seabios by default" Revert "Clone and build upstream Qemu by default" Revert "Rename ioemu-dir as qemu-xen-traditional-dir" Revert "Move the ioemu-dir-find shell script to an external file" Signed-off-by: Ian Jackson diff -r 51913fe3d25a -r e90438f6e6d1 .hgignore --- a/.hgignore Tue Sep 13 15:46:47 2011 +0100 +++ b/.hgignore Wed Sep 14 11:38:13 2011 +0100 @@ -291,12 +291,8 @@ ^tools/xm-test/lib/XmTestLib/config.py$ ^tools/xm-test/lib/XmTestReport/xmtest.py$ ^tools/xm-test/tests/.*\.test$ -^tools/qemu-xen-traditional-dir-remote -^tools/qemu-xen-traditional-dir$ -^tools/qemu-xen-dir-remote -^tools/qemu-xen-dir$ -^tools/tools/firmware/seabios-dir-remote -^tools/tools/firmware/seabios-dir$ +^tools/ioemu-remote +^tools/ioemu-dir$ ^tools/ocaml/.*/.*\.annot$ ^tools/ocaml/.*/.*\.cmx?a$ ^tools/ocaml/.*/META$ diff -r 51913fe3d25a -r e90438f6e6d1 Config.mk --- a/Config.mk Tue Sep 13 15:46:47 2011 +0100 +++ b/Config.mk Wed Sep 14 11:38:13 2011 +0100 @@ -192,12 +192,6 @@ QEMU_REMOTE=git://xenbits.xensource.com/ QEMU_REMOTE=git://xenbits.xensource.com/qemu-xen-unstable.git endif -# Only available through the git protocol at the moment -QEMU_UPSTREAM_URL ?= git://xenbits.xen.org/people/sstabellini/qemu-dm.git -QEMU_UPSTREAM_TAG ?= origin/xen-stable-0.15 -SEABIOS_UPSTREAM_URL=git://git.qemu.org/seabios.git -SEABIOS_UPSTREAM_TAG ?= 7fc039e9c262b4199fab497f3e12f4e425c37560 - # Specify which qemu-dm to use. This may be `ioemu' to use the old # Mercurial in-tree version, or a local directory, or a git URL. # CONFIG_QEMU ?= `pwd`/$(XEN_ROOT)/../qemu-xen.git @@ -209,6 +203,15 @@ QEMU_TAG ?= cd776ee9408ff127f934a707c1a3 # Short answer -- do not enable this unless you know what you are # doing and are prepared for some pain. + +# SeaBIOS integration is a work in progress. Before enabling this +# option you must clone git://git.qemu.org/seabios.git/, possibly add +# some development patches and then build it yourself before pointing +# this variable to it (using an absolute path). +# +# Note that using SeaBIOS requires the use the upstream qemu as the +# device model. +SEABIOS_DIR ?= # Optional components XENSTAT_XENTOP ?= y diff -r 51913fe3d25a -r e90438f6e6d1 Makefile --- a/Makefile Tue Sep 13 15:46:47 2011 +0100 +++ b/Makefile Wed Sep 14 11:38:13 2011 +0100 @@ -70,7 +70,7 @@ install-tools: $(MAKE) -C tools install ifeq ($(CONFIG_IOEMU),y) -install-tools: tools/qemu-xen-traditional-dir tools/qemu-xen-dir +install-tools: tools/ioemu-dir endif .PHONY: install-kernels @@ -78,21 +78,18 @@ install-kernels: for i in $(XKERNELS) ; do $(MAKE) $$i-install || exit 1; done .PHONY: install-stubdom -install-stubdom: tools/qemu-xen-traditional-dir install-tools +install-stubdom: tools/ioemu-dir install-tools $(MAKE) -C stubdom install ifeq (x86_64,$(XEN_TARGET_ARCH)) XEN_TARGET_ARCH=x86_32 $(MAKE) -C stubdom install-grub endif -tools/qemu-xen-traditional-dir: - $(MAKE) -C tools qemu-xen-traditional-dir-find +tools/ioemu-dir: + $(MAKE) -C tools ioemu-dir-find -.PHONY: tools/qemu-xen-traditional-dir-force-update -tools/qemu-xen-traditional-dir-force-update: - $(MAKE) -C tools qemu-xen-traditional-dir-force-update - -tools/qemu-xen-dir: - $(MAKE) -C tools qemu-xen-dir-find +.PHONY: tools/ioemu-dir-force-update +tools/ioemu-dir-force-update: + $(MAKE) -C tools ioemu-dir-force-update .PHONY: install-docs install-docs: diff -r 51913fe3d25a -r e90438f6e6d1 scripts/git-checkout.sh --- a/scripts/git-checkout.sh Tue Sep 13 15:46:47 2011 +0100 +++ /dev/null Thu Jan 01 00:00:00 1970 +0000 @@ -1,47 +0,0 @@ -#!/bin/sh - -TREE=$1 -TAG=$2 -DIR=$3 - - -if test -d $TREE; then - mkdir -p $DIR - ROOT=$TREE -else - if test \! -d $DIR-remote; then - rm -rf $DIR-remote $DIR-remote.tmp; - mkdir $DIR-remote.tmp; rmdir $DIR-remote.tmp; - git clone $TREE $DIR-remote.tmp; - if test "$TAG" ; then - cd $DIR-remote.tmp - git branch -D dummy >/dev/null 2>&1 ||: - git checkout -b dummy $TAG - cd .. - fi - mv $DIR-remote.tmp $DIR-remote - fi - rm -f $DIR - ln -sf $DIR-remote $DIR - ROOT=. -fi - -set -e -cd $DIR -# is this qemu-xen-traditional? -if test -f $ROOT/xen-setup; then - QEMU_ROOT=$ROOT $ROOT/xen-setup $IOEMU_CONFIGURE_CROSS -# is this qemu-xen? -elif test -f $ROOT/configure; then - cd $ROOT - ./configure --enable-xen --target-list=i386-softmmu \ - --extra-cflags="-I$XEN_ROOT/tools/include \ - -I$XEN_ROOT/tools/libxc \ - -I$XEN_ROOT/tools/xenstore" \ - --extra-ldflags="-L$XEN_ROOT/tools/libxc \ - -L$XEN_ROOT/tools/libxenstore" \ - --bindir=/usr/lib/xen/bin \ - --disable-kvm \ - $IOEMU_CONFIGURE_CROSS -fi - diff -r 51913fe3d25a -r e90438f6e6d1 tools/Makefile --- a/tools/Makefile Tue Sep 13 15:46:47 2011 +0100 +++ b/tools/Makefile Wed Sep 14 11:38:13 2011 +0100 @@ -30,8 +30,7 @@ SUBDIRS-$(LIBXENAPI_BINDINGS) += libxen # do not recurse in to a dir we are about to delete ifneq "$(MAKECMDGOALS)" "distclean" -SUBDIRS-$(CONFIG_IOEMU) += qemu-xen-traditional-dir -SUBDIRS-$(CONFIG_IOEMU) += qemu-xen-dir +SUBDIRS-$(CONFIG_IOEMU) += ioemu-dir endif SUBDIRS-y += xenpmd @@ -71,8 +70,7 @@ clean: subdirs-clean .PHONY: distclean distclean: subdirs-distclean - rm -rf qemu-xen-traditional-dir qemu-xen-traditional-dir-remote - rm -rf qemu-xen-dir qemu-xen-dir-remote + rm -rf ioemu-dir ioemu-remote ifneq ($(XEN_COMPILE_ARCH),$(XEN_TARGET_ARCH)) IOEMU_CONFIGURE_CROSS ?= --cpu=$(XEN_TARGET_ARCH) \ @@ -80,35 +78,51 @@ IOEMU_CONFIGURE_CROSS ?= --cpu=$(XEN_TAR --interp-prefix=$(CROSS_SYS_ROOT) endif -qemu-xen-traditional-dir-find: - $(XEN_ROOT)/scripts/git-checkout.sh $(CONFIG_QEMU) $(QEMU_TAG) qemu-xen-traditional-dir - -qemu-xen-dir-find: - $(XEN_ROOT)/scripts/git-checkout.sh $(QEMU_UPSTREAM_URL) $(QEMU_UPSTREAM_TAG) qemu-xen-dir - -.PHONY: qemu-xen-traditional-dir-force-update -qemu-xen-traditional-dir-force-update: +QEMU_ROOT := $(shell if [ -d "$(CONFIG_QEMU)" ]; then echo "$(CONFIG_QEMU)"; else echo .; fi) +ifneq ($(QEMU_ROOT),.) +export QEMU_ROOT +endif + +ioemu-dir-find: + set -ex; \ + if test -d $(CONFIG_QEMU); then \ + mkdir -p ioemu-dir; \ + else \ + if [ ! -d ioemu-remote ]; then \ + rm -rf ioemu-remote ioemu-remote.tmp; \ + mkdir ioemu-remote.tmp; rmdir ioemu-remote.tmp; \ + $(GIT) clone $(CONFIG_QEMU) ioemu-remote.tmp; \ + if [ "$(QEMU_TAG)" ]; then \ + cd ioemu-remote.tmp; \ + $(GIT) branch -D dummy >/dev/null 2>&1 ||:; \ + $(GIT) checkout -b dummy $(QEMU_TAG); \ + cd ..; \ + fi; \ + mv ioemu-remote.tmp ioemu-remote; \ + fi; \ + rm -f ioemu-dir; \ + ln -sf ioemu-remote ioemu-dir; \ + fi + set -e; \ + $(buildmakevars2shellvars); \ + cd ioemu-dir; \ + $(QEMU_ROOT)/xen-setup $(IOEMU_CONFIGURE_CROSS) + +.PHONY: ioemu-dir-force-update +ioemu-dir-force-update: set -ex; \ if [ "$(QEMU_TAG)" ]; then \ - cd qemu-xen-traditional-dir-remote; \ + cd ioemu-remote; \ $(GIT) fetch origin; \ $(GIT) reset --hard $(QEMU_TAG); \ fi -subdir-all-qemu-xen-traditional-dir subdir-install-qemu-xen-traditional-dir: qemu-xen-traditional-dir-find +subdir-all-ioemu-dir subdir-install-ioemu-dir: ioemu-dir-find -subdir-clean-qemu-xen-traditional-dir: - set -e; if test -d qemu-xen-traditional-dir/.; then \ +subdir-clean-ioemu-dir: + set -e; if test -d ioemu-dir/.; then \ $(buildmakevars2shellvars); \ - $(MAKE) -C qemu-xen-traditional-dir clean; \ - fi - -subdir-all-qemu-xen-dir subdir-install-qemu-xen-dir: qemu-xen-dir-find - -subdir-clean-qemu-xen-dir: - set -e; if test -d qemu-xen-dir/.; then \ - $(buildmakevars2shellvars); \ - $(MAKE) -C qemu-xen-dir clean; \ + $(MAKE) -C ioemu-dir clean; \ fi subdir-clean-debugger/gdbsx subdir-distclean-debugger/gdbsx: .phony diff -r 51913fe3d25a -r e90438f6e6d1 tools/firmware/Makefile --- a/tools/firmware/Makefile Tue Sep 13 15:46:47 2011 +0100 +++ b/tools/firmware/Makefile Wed Sep 14 11:38:13 2011 +0100 @@ -6,18 +6,13 @@ INST_DIR := $(DESTDIR)$(XENFIRMWAREDIR) INST_DIR := $(DESTDIR)$(XENFIRMWAREDIR) SUBDIRS := -SUBDIRS += seabios-dir SUBDIRS += rombios SUBDIRS += vgabios SUBDIRS += etherboot SUBDIRS += hvmloader -seabios-dir: - $(XEN_ROOT)/scripts/git-checkout.sh $(SEABIOS_UPSTREAM_URL) $(SEABIOS_UPSTREAM_TAG) seabios-dir - cp seabios-config seabios-dir/.config; - .PHONY: all -all: seabios-dir +all: @set -e; if [ $$((`( bcc -v 2>&1 | grep version || echo 0.0.0 ) | cut -d' ' -f 3 | awk -F. '{ printf "0x%02x%02x%02x", $$1, $$2, $$3}'`)) -lt $$((0x00100e)) ] ; then \ echo "==========================================================================="; \ echo "Require dev86 rpm or bin86 & bcc debs version >= 0.16.14 to build firmware!"; \ @@ -40,7 +35,4 @@ distclean: subdirs-distclean distclean: subdirs-distclean subdir-distclean-etherboot: .phony - $(MAKE) -C etherboot distclean - -subdir-distclean-seabios-dir: .phony - rm -rf seabios-dir seabios-dir-remote + $(MAKE) -C etherboot distclean \ No newline at end of file diff -r 51913fe3d25a -r e90438f6e6d1 tools/firmware/hvmloader/Makefile --- a/tools/firmware/hvmloader/Makefile Tue Sep 13 15:46:47 2011 +0100 +++ b/tools/firmware/hvmloader/Makefile Wed Sep 14 11:38:13 2011 +0100 @@ -44,7 +44,6 @@ ROMBIOS_ROM := $(ROMBIOS_DIR)/BIOS-bochs ROMBIOS_ROM := $(ROMBIOS_DIR)/BIOS-bochs-latest endif -SEABIOS_DIR := ../seabios-dir ifneq ($(SEABIOS_DIR),) OBJS += seabios.o CFLAGS += -DENABLE_SEABIOS diff -r 51913fe3d25a -r e90438f6e6d1 tools/firmware/seabios-config --- a/tools/firmware/seabios-config Tue Sep 13 15:46:47 2011 +0100 +++ /dev/null Thu Jan 01 00:00:00 1970 +0000 @@ -1,73 +0,0 @@ -# -# Automatically generated make config: don't edit -# SeaBIOS Configuration -# Wed Sep 7 13:03:21 2011 -# - -# -# General Features -# -# CONFIG_COREBOOT is not set -CONFIG_XEN=y -CONFIG_THREADS=y -# CONFIG_THREAD_OPTIONROMS is not set -CONFIG_RELOCATE_INIT=y -CONFIG_BOOTMENU=y -# CONFIG_BOOTSPLASH is not set -CONFIG_BOOTORDER=y - -# -# Hardware support -# -CONFIG_ATA=y -CONFIG_ATA_DMA=y -CONFIG_ATA_PIO32=y -CONFIG_AHCI=y -CONFIG_VIRTIO_BLK=y -CONFIG_FLOPPY=y -CONFIG_PS2PORT=y -CONFIG_USB=y -CONFIG_USB_UHCI=y -CONFIG_USB_OHCI=y -CONFIG_USB_EHCI=y -CONFIG_USB_MSC=y -CONFIG_USB_HUB=y -CONFIG_USB_KEYBOARD=y -CONFIG_USB_MOUSE=y -CONFIG_SERIAL=y -CONFIG_LPT=y -# CONFIG_USE_SMM is not set -CONFIG_MTRR_INIT=y - -# -# BIOS interfaces -# -CONFIG_DRIVES=y -CONFIG_CDROM_BOOT=y -CONFIG_CDROM_EMU=y -CONFIG_PCIBIOS=y -CONFIG_APMBIOS=y -CONFIG_PNPBIOS=y -CONFIG_OPTIONROMS=y -# CONFIG_OPTIONROMS_DEPLOYED is not set -CONFIG_PMM=y -CONFIG_BOOT=y -CONFIG_KEYBOARD=y -CONFIG_KBD_CALL_INT15_4F=y -CONFIG_MOUSE=y -CONFIG_S3_RESUME=y -# CONFIG_DISABLE_A20 is not set - -# -# BIOS Tables -# -CONFIG_PIRTABLE=y -CONFIG_MPTABLE=y -CONFIG_SMBIOS=y -CONFIG_ACPI=y - -# -# Debugging -# -CONFIG_DEBUG_LEVEL=1 -# CONFIG_DEBUG_SERIAL is not set _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel From xen-devel-bounces@lists.xensource.com Wed Sep 14 03:52:59 2011 Return-path: Envelope-to: www-data@lists.xensource.com Delivery-date: Wed, 14 Sep 2011 03:52:59 -0700 Received: from localhost ([127.0.0.1] helo=lists.colo.xensource.com) by lists.xensource.com with esmtp (Exim 4.43) id 1R3n5P-0008Mh-0Y; Wed, 14 Sep 2011 03:52:59 -0700 Received: from mail182.messagelabs.com ([85.158.139.83]) by lists.xensource.com with esmtp (Exim 4.43) id 1R3n4l-0008AQ-7K for xen-devel@lists.xensource.com; Wed, 14 Sep 2011 03:52:19 -0700 X-Env-Sender: olaf@aepfle.de X-Msg-Ref: server-3.tower-182.messagelabs.com!1315997534!15481370!1 X-Originating-IP: [81.169.146.161] X-StarScan-Version: 6.4.1; banners=-,-,- X-VirusChecked: Checked Received: (qmail 815 invoked from network); 14 Sep 2011 10:52:16 -0000 Received: from mo-p00-ob.rzone.de (HELO mo-p00-ob.rzone.de) (81.169.146.161) by server-3.tower-182.messagelabs.com with EDH-RSA-DES-CBC3-SHA encrypted SMTP; 14 Sep 2011 10:52:16 -0000 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; t=1315997534; l=642; s=domk; d=aepfle.de; h=In-Reply-To:Content-Type:MIME-Version:References:Subject:Cc:To:From: Date:X-RZG-CLASS-ID:X-RZG-AUTH; bh=kPZBU2NJMero6h7vCdGndTljjHk=; b=lKJeKXqb+UTR4pnh16KfeXG+XPQLYOwglFDoS6geYmnXZDbsUXbGShC5d8AXSrbZSAy 6efGZIHCZPL6U1PHY+rGJSvF0/RrWJNJd5Ox9N0eqDCQ5v5DtSaZlpwR0BlK2PBB7omee xA34A9PeYFVcCSpF2j/b6WGjzXUd0ytCw44= X-RZG-AUTH: :P2EQZWCpfu+qG7CngxMFH1J+zrwiavkK6tmQaLfmxtMZ80VwmRNV71Y= X-RZG-CLASS-ID: mo00 Received: from probook.site (ip-80-226-24-5.vodafone-net.de [80.226.24.5]) by smtp.strato.de (klopstock mo64) (RZmta 26.7) with (EDH-RSA-DES-CBC3-SHA encrypted) ESMTPA id t04493n8EAoGpU ; Wed, 14 Sep 2011 12:52:08 +0200 (MEST) Received: by probook.site (Postfix, from userid 1000) id CE8A818B66; Wed, 14 Sep 2011 12:52:06 +0200 (CEST) Date: Wed, 14 Sep 2011 12:52:06 +0200 From: Olaf Hering To: Ian Jackson Subject: Re: [Xen-devel] [PATCH] libxl: document memory parameters and behaviour Message-ID: <20110914105206.GA21644@aepfle.de> References: <20080.30090.236544.113147@mariner.uk.xensource.com> <20110914103341.GA21508@aepfle.de> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline In-Reply-To: <20110914103341.GA21508@aepfle.de> User-Agent: Mutt/1.5.21.rev5535 (2011-07-01) Cc: xen-devel@lists.xensource.com X-BeenThere: xen-devel@lists.xensource.com X-Mailman-Version: 2.1.5 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xensource.com Errors-To: xen-devel-bounces@lists.xensource.com On Wed, Sep 14, Olaf Hering wrote: > On Wed, Sep 14, Ian Jackson wrote: > > > commit a6b0f1e47447b7da2e838f9f68caf2019b177c36 > > Author: Ian Jackson > > Date: Wed Sep 14 10:34:54 2011 +0100 > > > > libxl: document memory parameters and behaviour > > > > Introduce a new comment in libxl.h, describing the various guest > > memory usage parameters. > > Thanks for documenting this. > > How do the three describe values relate to xc_dominfo_t->nr_pages? Sorry. I did not notice that xc_domaininfo_t is actually xen_domctl_getdomaininfo_t, not xc_dominfo_t from tools/libxc/xenctrl.h. Olaf _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel From xen-devel-bounces@lists.xensource.com Wed Sep 14 03:59:51 2011 Return-path: Envelope-to: www-data@lists.xensource.com Delivery-date: Wed, 14 Sep 2011 03:59:51 -0700 Received: from localhost ([127.0.0.1] helo=lists.colo.xensource.com) by lists.xensource.com with esmtp (Exim 4.43) id 1R3nC0-0000PH-He; Wed, 14 Sep 2011 03:59:49 -0700 Received: from mail182.messagelabs.com ([85.158.139.83]) by lists.xensource.com with esmtp (Exim 4.43) id 1R3n9m-0000B7-2M; Wed, 14 Sep 2011 03:57:31 -0700 X-Env-Sender: konrad@oracle.com X-Msg-Ref: server-3.tower-182.messagelabs.com!1315997845!15482186!1 X-Originating-IP: [141.146.126.227] X-StarScan-Version: 6.4.1; banners=-,-,- X-VirusChecked: Checked Received: (qmail 20239 invoked from network); 14 Sep 2011 10:57:26 -0000 Received: from acsinet15.oracle.com (HELO acsinet15.oracle.com) (141.146.126.227) by server-3.tower-182.messagelabs.com with DHE-RSA-AES256-SHA encrypted SMTP; 14 Sep 2011 10:57:26 -0000 Received: from rtcsinet21.oracle.com (rtcsinet21.oracle.com [66.248.204.29]) by acsinet15.oracle.com (Switch-3.4.4/Switch-3.4.4) with ESMTP id p8EAvIiQ009304 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Wed, 14 Sep 2011 10:57:20 GMT Received: from acsmt358.oracle.com (acsmt358.oracle.com [141.146.40.158]) by rtcsinet21.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id p8EAvHVs020207 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 14 Sep 2011 10:57:18 GMT Received: from abhmt108.oracle.com (abhmt108.oracle.com [141.146.116.60]) by acsmt358.oracle.com (8.12.11.20060308/8.12.11) with ESMTP id p8EAvB67031665; Wed, 14 Sep 2011 05:57:11 -0500 Received: from oracle.com (/209.6.55.207) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Wed, 14 Sep 2011 03:57:11 -0700 Received: by oracle.com (Postfix, from userid 1000) id 55A621211; Wed, 14 Sep 2011 06:57:11 -0400 (EDT) Date: Wed, 14 Sep 2011 06:57:11 -0400 From: Konrad Rzeszutek Wilk To: jim burns , Ian Campbell Subject: Re: [Xen-devel] Re: [Xen-users] Continuing BUG:-iness booting Fedora Rawhide 3.1.0-rc's (was Summary: Experiences setting up a debug serial port) Message-ID: <20110914105711.GA16284@phenom.oracle.com> References: <201107231426.56811.jim_burn@bellsouth.net> <1342436.B0x3ddQn4U@dell4550> <20110913085559.GG12984@reaktio.net> <1856036.eYCcuDQrZC@dell4550> <20110914090806.GD25628@phenom.oracle.com> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="HcAYCG3uE/tztfnV" Content-Disposition: inline In-Reply-To: <20110914090806.GD25628@phenom.oracle.com> User-Agent: Mutt/1.5.21 (2010-09-15) X-Source-IP: rtcsinet21.oracle.com [66.248.204.29] X-CT-RefId: str=0001.0A020205.4E708891.012E,ss=1,re=-2.300,fgs=0 Cc: Todd Deshane , xen-devel@lists.xensource.com, xen-users@lists.xensource.com, Fedora Xen List X-BeenThere: xen-devel@lists.xensource.com X-Mailman-Version: 2.1.5 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xensource.com Errors-To: xen-devel-bounces@lists.xensource.com --HcAYCG3uE/tztfnV Content-Type: text/plain; charset=us-ascii Content-Disposition: inline On Wed, Sep 14, 2011 at 05:08:06AM -0400, Konrad Rzeszutek Wilk wrote: > > Rawhide just came out with 3.1.0-0.rc6.git0.0.fc17.x86_64 , and the BUG:s are > > still the same as in the last log I sent. However, as promised I have attached > > the initcall_debug log, but for rc6. > > Hey Jim, > > We are quite sure we know the cause of this. I was wondering if you would be > up for beta-testing a patch for this? Specifically this patch seems to fix it for me: commit 690dc11498b192db25762de77988224753517c96 Author: Konrad Rzeszutek Wilk Date: Wed Sep 14 05:10:00 2011 -0400 xen/irq: Alter the locking to be a mutex. When we allocate/change the IRQ informations, we do not need to use a psinlock. We can use a mutex (which is what the generic IRQ code does for allocations/changes. Suggested-by: Ian Campbell Signed-off-by: Konrad Rzeszutek Wilk diff --git a/drivers/xen/events.c b/drivers/xen/events.c index da70f5c..7523719 100644 --- a/drivers/xen/events.c +++ b/drivers/xen/events.c @@ -54,7 +54,7 @@ * This lock protects updates to the following mapping and reference-count * arrays. The lock does not need to be acquired to read the mapping tables. */ -static DEFINE_SPINLOCK(irq_mapping_update_lock); +static DEFINE_MUTEX(irq_mapping_update_lock); static LIST_HEAD(xen_irq_list_head); @@ -631,7 +631,7 @@ int xen_bind_pirq_gsi_to_irq(unsigned gsi, int irq = -1; struct physdev_irq irq_op; - spin_lock(&irq_mapping_update_lock); + mutex_lock(&irq_mapping_update_lock); irq = find_irq_by_gsi(gsi); if (irq != -1) { @@ -684,7 +684,7 @@ int xen_bind_pirq_gsi_to_irq(unsigned gsi, handle_edge_irq, name); out: - spin_unlock(&irq_mapping_update_lock); + mutex_unlock(&irq_mapping_update_lock); return irq; } @@ -710,7 +710,7 @@ int xen_bind_pirq_msi_to_irq(struct pci_dev *dev, struct msi_desc *msidesc, { int irq, ret; - spin_lock(&irq_mapping_update_lock); + mutex_lock(&irq_mapping_update_lock); irq = xen_allocate_irq_dynamic(); if (irq == -1) @@ -724,10 +724,10 @@ int xen_bind_pirq_msi_to_irq(struct pci_dev *dev, struct msi_desc *msidesc, if (ret < 0) goto error_irq; out: - spin_unlock(&irq_mapping_update_lock); + mutex_unlock(&irq_mapping_update_lock); return irq; error_irq: - spin_unlock(&irq_mapping_update_lock); + mutex_unlock(&irq_mapping_update_lock); xen_free_irq(irq); return -1; } @@ -740,7 +740,7 @@ int xen_destroy_irq(int irq) struct irq_info *info = info_for_irq(irq); int rc = -ENOENT; - spin_lock(&irq_mapping_update_lock); + mutex_lock(&irq_mapping_update_lock); desc = irq_to_desc(irq); if (!desc) @@ -766,7 +766,7 @@ int xen_destroy_irq(int irq) xen_free_irq(irq); out: - spin_unlock(&irq_mapping_update_lock); + mutex_unlock(&irq_mapping_update_lock); return rc; } @@ -776,7 +776,7 @@ int xen_irq_from_pirq(unsigned pirq) struct irq_info *info; - spin_lock(&irq_mapping_update_lock); + mutex_lock(&irq_mapping_update_lock); list_for_each_entry(info, &xen_irq_list_head, list) { if (info == NULL || info->type != IRQT_PIRQ) @@ -787,7 +787,7 @@ int xen_irq_from_pirq(unsigned pirq) } irq = -1; out: - spin_unlock(&irq_mapping_update_lock); + mutex_unlock(&irq_mapping_update_lock); return irq; } @@ -802,7 +802,7 @@ int bind_evtchn_to_irq(unsigned int evtchn) { int irq; - spin_lock(&irq_mapping_update_lock); + mutex_lock(&irq_mapping_update_lock); irq = evtchn_to_irq[evtchn]; @@ -818,7 +818,7 @@ int bind_evtchn_to_irq(unsigned int evtchn) } out: - spin_unlock(&irq_mapping_update_lock); + mutex_unlock(&irq_mapping_update_lock); return irq; } @@ -829,7 +829,7 @@ static int bind_ipi_to_irq(unsigned int ipi, unsigned int cpu) struct evtchn_bind_ipi bind_ipi; int evtchn, irq; - spin_lock(&irq_mapping_update_lock); + mutex_lock(&irq_mapping_update_lock); irq = per_cpu(ipi_to_irq, cpu)[ipi]; @@ -853,7 +853,7 @@ static int bind_ipi_to_irq(unsigned int ipi, unsigned int cpu) } out: - spin_unlock(&irq_mapping_update_lock); + mutex_unlock(&irq_mapping_update_lock); return irq; } @@ -878,7 +878,7 @@ int bind_virq_to_irq(unsigned int virq, unsigned int cpu) struct evtchn_bind_virq bind_virq; int evtchn, irq; - spin_lock(&irq_mapping_update_lock); + mutex_lock(&irq_mapping_update_lock); irq = per_cpu(virq_to_irq, cpu)[virq]; @@ -903,7 +903,7 @@ int bind_virq_to_irq(unsigned int virq, unsigned int cpu) } out: - spin_unlock(&irq_mapping_update_lock); + mutex_unlock(&irq_mapping_update_lock); return irq; } @@ -913,7 +913,7 @@ static void unbind_from_irq(unsigned int irq) struct evtchn_close close; int evtchn = evtchn_from_irq(irq); - spin_lock(&irq_mapping_update_lock); + mutex_lock(&irq_mapping_update_lock); if (VALID_EVTCHN(evtchn)) { close.port = evtchn; @@ -943,7 +943,7 @@ static void unbind_from_irq(unsigned int irq) xen_free_irq(irq); - spin_unlock(&irq_mapping_update_lock); + mutex_unlock(&irq_mapping_update_lock); } int bind_evtchn_to_irqhandler(unsigned int evtchn, @@ -1279,7 +1279,7 @@ void rebind_evtchn_irq(int evtchn, int irq) will also be masked. */ disable_irq(irq); - spin_lock(&irq_mapping_update_lock); + mutex_lock(&irq_mapping_update_lock); /* After resume the irq<->evtchn mappings are all cleared out */ BUG_ON(evtchn_to_irq[evtchn] != -1); @@ -1289,7 +1289,7 @@ void rebind_evtchn_irq(int evtchn, int irq) xen_irq_info_evtchn_init(irq, evtchn); - spin_unlock(&irq_mapping_update_lock); + mutex_unlock(&irq_mapping_update_lock); /* new event channels are always bound to cpu 0 */ irq_set_affinity(irq, cpumask_of(0)); --HcAYCG3uE/tztfnV Content-Type: text/x-diff; charset=us-ascii Content-Disposition: attachment; filename="mutex_instead_of_spinlock.patch" commit 690dc11498b192db25762de77988224753517c96 Author: Konrad Rzeszutek Wilk Date: Wed Sep 14 05:10:00 2011 -0400 xen/irq: Alter the locking to be a mutex. When we allocate/change the IRQ informations, we do not need to use a psinlock. We can use a mutex (which is what the generic IRQ code does for allocations/changes. Suggested-by: Ian Campbell Signed-off-by: Konrad Rzeszutek Wilk diff --git a/drivers/xen/events.c b/drivers/xen/events.c index da70f5c..7523719 100644 --- a/drivers/xen/events.c +++ b/drivers/xen/events.c @@ -54,7 +54,7 @@ * This lock protects updates to the following mapping and reference-count * arrays. The lock does not need to be acquired to read the mapping tables. */ -static DEFINE_SPINLOCK(irq_mapping_update_lock); +static DEFINE_MUTEX(irq_mapping_update_lock); static LIST_HEAD(xen_irq_list_head); @@ -631,7 +631,7 @@ int xen_bind_pirq_gsi_to_irq(unsigned gsi, int irq = -1; struct physdev_irq irq_op; - spin_lock(&irq_mapping_update_lock); + mutex_lock(&irq_mapping_update_lock); irq = find_irq_by_gsi(gsi); if (irq != -1) { @@ -684,7 +684,7 @@ int xen_bind_pirq_gsi_to_irq(unsigned gsi, handle_edge_irq, name); out: - spin_unlock(&irq_mapping_update_lock); + mutex_unlock(&irq_mapping_update_lock); return irq; } @@ -710,7 +710,7 @@ int xen_bind_pirq_msi_to_irq(struct pci_dev *dev, struct msi_desc *msidesc, { int irq, ret; - spin_lock(&irq_mapping_update_lock); + mutex_lock(&irq_mapping_update_lock); irq = xen_allocate_irq_dynamic(); if (irq == -1) @@ -724,10 +724,10 @@ int xen_bind_pirq_msi_to_irq(struct pci_dev *dev, struct msi_desc *msidesc, if (ret < 0) goto error_irq; out: - spin_unlock(&irq_mapping_update_lock); + mutex_unlock(&irq_mapping_update_lock); return irq; error_irq: - spin_unlock(&irq_mapping_update_lock); + mutex_unlock(&irq_mapping_update_lock); xen_free_irq(irq); return -1; } @@ -740,7 +740,7 @@ int xen_destroy_irq(int irq) struct irq_info *info = info_for_irq(irq); int rc = -ENOENT; - spin_lock(&irq_mapping_update_lock); + mutex_lock(&irq_mapping_update_lock); desc = irq_to_desc(irq); if (!desc) @@ -766,7 +766,7 @@ int xen_destroy_irq(int irq) xen_free_irq(irq); out: - spin_unlock(&irq_mapping_update_lock); + mutex_unlock(&irq_mapping_update_lock); return rc; } @@ -776,7 +776,7 @@ int xen_irq_from_pirq(unsigned pirq) struct irq_info *info; - spin_lock(&irq_mapping_update_lock); + mutex_lock(&irq_mapping_update_lock); list_for_each_entry(info, &xen_irq_list_head, list) { if (info == NULL || info->type != IRQT_PIRQ) @@ -787,7 +787,7 @@ int xen_irq_from_pirq(unsigned pirq) } irq = -1; out: - spin_unlock(&irq_mapping_update_lock); + mutex_unlock(&irq_mapping_update_lock); return irq; } @@ -802,7 +802,7 @@ int bind_evtchn_to_irq(unsigned int evtchn) { int irq; - spin_lock(&irq_mapping_update_lock); + mutex_lock(&irq_mapping_update_lock); irq = evtchn_to_irq[evtchn]; @@ -818,7 +818,7 @@ int bind_evtchn_to_irq(unsigned int evtchn) } out: - spin_unlock(&irq_mapping_update_lock); + mutex_unlock(&irq_mapping_update_lock); return irq; } @@ -829,7 +829,7 @@ static int bind_ipi_to_irq(unsigned int ipi, unsigned int cpu) struct evtchn_bind_ipi bind_ipi; int evtchn, irq; - spin_lock(&irq_mapping_update_lock); + mutex_lock(&irq_mapping_update_lock); irq = per_cpu(ipi_to_irq, cpu)[ipi]; @@ -853,7 +853,7 @@ static int bind_ipi_to_irq(unsigned int ipi, unsigned int cpu) } out: - spin_unlock(&irq_mapping_update_lock); + mutex_unlock(&irq_mapping_update_lock); return irq; } @@ -878,7 +878,7 @@ int bind_virq_to_irq(unsigned int virq, unsigned int cpu) struct evtchn_bind_virq bind_virq; int evtchn, irq; - spin_lock(&irq_mapping_update_lock); + mutex_lock(&irq_mapping_update_lock); irq = per_cpu(virq_to_irq, cpu)[virq]; @@ -903,7 +903,7 @@ int bind_virq_to_irq(unsigned int virq, unsigned int cpu) } out: - spin_unlock(&irq_mapping_update_lock); + mutex_unlock(&irq_mapping_update_lock); return irq; } @@ -913,7 +913,7 @@ static void unbind_from_irq(unsigned int irq) struct evtchn_close close; int evtchn = evtchn_from_irq(irq); - spin_lock(&irq_mapping_update_lock); + mutex_lock(&irq_mapping_update_lock); if (VALID_EVTCHN(evtchn)) { close.port = evtchn; @@ -943,7 +943,7 @@ static void unbind_from_irq(unsigned int irq) xen_free_irq(irq); - spin_unlock(&irq_mapping_update_lock); + mutex_unlock(&irq_mapping_update_lock); } int bind_evtchn_to_irqhandler(unsigned int evtchn, @@ -1279,7 +1279,7 @@ void rebind_evtchn_irq(int evtchn, int irq) will also be masked. */ disable_irq(irq); - spin_lock(&irq_mapping_update_lock); + mutex_lock(&irq_mapping_update_lock); /* After resume the irq<->evtchn mappings are all cleared out */ BUG_ON(evtchn_to_irq[evtchn] != -1); @@ -1289,7 +1289,7 @@ void rebind_evtchn_irq(int evtchn, int irq) xen_irq_info_evtchn_init(irq, evtchn); - spin_unlock(&irq_mapping_update_lock); + mutex_unlock(&irq_mapping_update_lock); /* new event channels are always bound to cpu 0 */ irq_set_affinity(irq, cpumask_of(0)); --HcAYCG3uE/tztfnV Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel --HcAYCG3uE/tztfnV-- From xen-devel-bounces@lists.xensource.com Wed Sep 14 04:24:18 2011 Return-path: Envelope-to: www-data@lists.xensource.com Delivery-date: Wed, 14 Sep 2011 04:24:18 -0700 Received: from localhost ([127.0.0.1] helo=lists.colo.xensource.com) by lists.xensource.com with esmtp (Exim 4.43) id 1R3nZi-0002hV-QQ; Wed, 14 Sep 2011 04:24:18 -0700 Received: from mail27.messagelabs.com ([193.109.254.147]) by lists.xensource.com with esmtp (Exim 4.43) id 1R3nZA-0002V1-0A for xen-devel@lists.xensource.com; Wed, 14 Sep 2011 04:23:44 -0700 X-Env-Sender: Ian.Jackson@eu.citrix.com X-Msg-Ref: server-9.tower-27.messagelabs.com!1315999405!44473437!1 X-Originating-IP: [62.200.22.115] X-StarScan-Version: 6.4.1; banners=-,-,- X-VirusChecked: Checked Received: (qmail 29259 invoked from network); 14 Sep 2011 11:23:25 -0000 Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115) by server-9.tower-27.messagelabs.com with RC4-SHA encrypted SMTP; 14 Sep 2011 11:23:25 -0000 X-IronPort-AV: E=Sophos;i="4.68,380,1312156800"; d="scan'208";a="7803746" Received: from lonpmailmx01.citrite.net ([10.30.203.162]) by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5; 14 Sep 2011 11:23:40 +0000 Received: from woking.xci-test.com (10.80.248.135) by smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id 8.3.137.0; Wed, 14 Sep 2011 12:23:41 +0100 Received: from osstest by woking.xci-test.com with local (Exim 4.69) (envelope-from ) id 1R3nZ6-0005wh-Ia; Wed, 14 Sep 2011 12:23:40 +0100 To: Message-ID: From: xen.org Date: Wed, 14 Sep 2011 12:23:40 +0100 MIME-Version: 1.0 Content-Type: text/plain Cc: ian.jackson@eu.citrix.com Subject: [Xen-devel] [xen-unstable test] 8933: regressions - FAIL X-BeenThere: xen-devel@lists.xensource.com X-Mailman-Version: 2.1.5 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xensource.com Errors-To: xen-devel-bounces@lists.xensource.com flight 8933 xen-unstable real [real] http://www.chiark.greenend.org.uk/~xensrcts/logs/8933/ Regressions :-( Tests which did not succeed and are blocking: build-amd64 4 xen-build fail REGR. vs. 8873 build-amd64-oldkern 4 xen-build fail REGR. vs. 8873 Tests which did not succeed, but are not blocking, including regressions (tests previously passed) regarded as allowable: test-amd64-amd64-xl-pcipt-intel 1 xen-build-check(1) blocked n/a test-amd64-i386-rhel6hvm-intel 1 xen-build-check(1) blocked n/a test-i386-i386-pv 1 xen-build-check(1) blocked n/a test-amd64-i386-pv 1 xen-build-check(1) blocked n/a test-amd64-amd64-pv 1 xen-build-check(1) blocked n/a test-i386-i386-xl 1 xen-build-check(1) blocked n/a test-amd64-i386-xl 1 xen-build-check(1) blocked n/a test-amd64-i386-xl-credit2 1 xen-build-check(1) blocked n/a test-amd64-i386-rhel6hvm-amd 1 xen-build-check(1) blocked n/a test-amd64-amd64-pair 1 xen-build-check(1) blocked n/a test-amd64-i386-pair 1 xen-build-check(1) blocked n/a test-i386-i386-pair 1 xen-build-check(1) blocked n/a build-amd64-pvops 4 kernel-build fail like 8873 build-i386-pvops 4 kernel-build fail like 8873 test-amd64-i386-xl-multivcpu 1 xen-build-check(1) blocked n/a test-amd64-amd64-xl-sedf 1 xen-build-check(1) blocked n/a test-amd64-i386-win-vcpus1 1 xen-build-check(1) blocked n/a test-amd64-i386-xl-win-vcpus1 1 xen-build-check(1) blocked n/a test-amd64-amd64-win 1 xen-build-check(1) blocked n/a test-amd64-i386-win 1 xen-build-check(1) blocked n/a test-amd64-amd64-xl-win 1 xen-build-check(1) blocked n/a test-amd64-amd64-xl 1 xen-build-check(1) blocked n/a test-i386-i386-xl-win 1 xen-build-check(1) blocked n/a test-i386-i386-win 1 xen-build-check(1) blocked n/a version targeted for testing: xen e90438f6e6d1 baseline version: xen 0312575dc35e ------------------------------------------------------------ People who touched revisions under test: Andrew Cooper Benjamin Schweikert Christoph Egger George Dunlap Ian Campbell Ian Jackson Keir Fraser Olaf Hering Stefano Stabellini Tim Deegan ------------------------------------------------------------ jobs: build-amd64 fail build-i386 pass build-amd64-oldkern fail build-i386-oldkern pass build-amd64-pvops fail build-i386-pvops fail test-amd64-amd64-xl blocked test-amd64-i386-xl blocked test-i386-i386-xl blocked test-amd64-i386-rhel6hvm-amd blocked test-amd64-i386-xl-credit2 blocked test-amd64-amd64-xl-pcipt-intel blocked test-amd64-i386-rhel6hvm-intel blocked test-amd64-i386-xl-multivcpu blocked test-amd64-amd64-pair blocked test-amd64-i386-pair blocked test-i386-i386-pair blocked test-amd64-amd64-pv blocked test-amd64-i386-pv blocked test-i386-i386-pv blocked test-amd64-amd64-xl-sedf blocked test-amd64-i386-win-vcpus1 blocked test-amd64-i386-xl-win-vcpus1 blocked test-amd64-amd64-win blocked test-amd64-i386-win blocked test-i386-i386-win blocked test-amd64-amd64-xl-win blocked test-i386-i386-xl-win blocked ------------------------------------------------------------ sg-report-flight on woking.cam.xci-test.com logs: /home/xc_osstest/logs images: /home/xc_osstest/images Logs, config files, etc. are available at http://www.chiark.greenend.org.uk/~xensrcts/logs Test harness code can be found at http://xenbits.xensource.com/gitweb?p=osstest.git;a=summary Not pushing. ------------------------------------------------------------ changeset: 23838:e90438f6e6d1 tag: tip user: Ian Jackson date: Wed Sep 14 11:38:13 2011 +0100 tools: Revert seabios and upstream qemu build changes These have broken the build and it seems to be difficult to fix. So we will revert the whole lot for now, and await corrected patch(es). Revert "fix the build when CONFIG_QEMU is specified by the user" Revert "tools: fix permissions of git-checkout.sh" Revert "scripts/git-checkout.sh: Is not bash specific. Invoke with /bin/sh." Revert "Clone and build Seabios by default" Revert "Clone and build upstream Qemu by default" Revert "Rename ioemu-dir as qemu-xen-traditional-dir" Revert "Move the ioemu-dir-find shell script to an external file" Signed-off-by: Ian Jackson changeset: 23837:51913fe3d25a user: Stefano Stabellini date: Tue Sep 13 15:46:47 2011 +0100 fix the build when CONFIG_QEMU is specified by the user Signed-off-by: Stefano Stabellini Committed-by: Stefano Stabellini changeset: 23836:e564f2f1b737 user: Ian Jackson date: Tue Sep 13 14:52:22 2011 +0100 tools: fix permissions of git-checkout.sh 23828:0d21b68f528b introduced a new scripts/git-checkout.sh, but it had the wrong permissions. chmod +x it, and add a blank line at the end to make sure it actually gets updated. Signed-off-by: Ian Jackson changeset: 23835:64aab9a077ea user: Keir Fraser date: Tue Sep 13 11:20:57 2011 +0100 scripts/git-checkout.sh: Is not bash specific. Invoke with /bin/sh. Signed-off-by: Keir Fraser changeset: 23834:1d40b2793723 user: George Dunlap date: Tue Sep 13 10:43:43 2011 +0100 xen,credit1: Add variable timeslice Add a xen command-line parameter, sched_credit_tslice_ms, to set the timeslice of the credit1 scheduler. Signed-off-by: George Dunlap changeset: 23833:ffe8e65f6687 user: Andrew Cooper date: Tue Sep 13 10:33:10 2011 +0100 IRQ: IO-APIC support End Of Interrupt for older IO-APICs The old io_apic_eoi() function using the EOI register only works for IO-APICs with a version of 0x20. Older IO-APICs do not have an EOI register so line level interrupts have to be EOI'd by flipping the mode to edge and back, which clears the IRR and Delivery Status bits. This patch replaces the current io_apic_eoi() function with one which takes into account the version of the IO-APIC and EOI's appropriately. v2: make recursive call to __io_apic_eoi() to reduce code size. Signed-off-by: Andrew Cooper changeset: 23832:ad3b4bb097cb user: Stefano Stabellini date: Tue Sep 13 10:32:24 2011 +0100 xen: if mapping GSIs we run out of pirq < nr_irqs_gsi, use the others PV on HVM guests can have more GSIs than the host, in that case we could run out of pirq < nr_irqs_gsi. When that happens use pirq >= nr_irqs_gsi rather than returning an error. Signed-off-by: Stefano Stabellini Tested-by: Benjamin Schweikert changeset: 23831:53416e7c0529 user: Stefano Stabellini date: Tue Sep 13 10:30:09 2011 +0100 Clone and build Seabios by default Signed-off-by: Stefano Stabellini changeset: 23830:1b80eaeeba7b user: Stefano Stabellini date: Tue Sep 13 10:29:14 2011 +0100 Clone and build upstream Qemu by default Signed-off-by: Stefano Stabellini changeset: 23829:9a541243aeaf user: Stefano Stabellini date: Tue Sep 13 10:27:53 2011 +0100 Rename ioemu-dir as qemu-xen-traditional-dir Signed-off-by: Stefano Stabellini changeset: 23828:0d21b68f528b user: Stefano Stabellini date: Tue Sep 13 10:27:20 2011 +0100 Move the ioemu-dir-find shell script to an external file Add support for configuring upstream qemu and rename ioemu-remote ioemu-dir-remote. Signed-off-by: Stefano Stabellini changeset: 23827:d1d6abc1db20 user: Olaf Hering date: Tue Sep 13 10:25:32 2011 +0100 xenpaging: use batch of pages during final page-in Map up to RING_SIZE pages in exit path to fill the ring instead of populating one page at a time. Signed-off-by: Olaf Hering changeset: 23826:ad958e87db79 user: Ian Campbell date: Tue Sep 13 10:22:03 2011 +0100 hvmloader: don't clear acpi_info after filling in some fields In particular the madt_lapic0_addr and madt_csum_addr fields are filled in while building the tables. This fixes a bluescreen on shutdown with certain versions of Windows. Signed-off-by: Ian Campbell Reported-by: Christoph Egger Tested-and-acked-by: Christoph Egger changeset: 23825:0312575dc35e user: Tim Deegan date: Thu Sep 08 15:13:06 2011 +0100 x86/mm: use new page-order interfaces in nested HAP code to make 2M and 1G mappings in the nested p2m tables. Signed-off-by: Christoph Egger Signed-off-by: Tim Deegan Committed-by: Tim Deegan ======================================== commit cd776ee9408ff127f934a707c1a339ee600bc127 Author: Ian Jackson Date: Tue Jun 28 13:50:53 2011 +0100 qemu-char.c: fix incorrect CONFIG_STUBDOM handling qemu-char.c:1123:7: warning: "CONFIG_STUBDOM" is not defined [-Wundef] Signed-off-by: Olaf Hering Acked-by: Ian Jackson _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel From xen-devel-bounces@lists.xensource.com Wed Sep 14 04:26:31 2011 Return-path: Envelope-to: www-data@lists.xensource.com Delivery-date: Wed, 14 Sep 2011 04:26:31 -0700 Received: from localhost ([127.0.0.1] helo=lists.colo.xensource.com) by lists.xensource.com with esmtp (Exim 4.43) id 1R3nbr-000369-P7; Wed, 14 Sep 2011 04:26:31 -0700 Received: from mail182.messagelabs.com ([85.158.139.83]) by lists.xensource.com with esmtp (Exim 4.43) id 1R3nbK-0002tM-MQ; Wed, 14 Sep 2011 04:25:59 -0700 X-Env-Sender: pasik@iki.fi X-Msg-Ref: server-7.tower-182.messagelabs.com!1315999555!13277736!1 X-Originating-IP: [192.89.123.25] X-StarScan-Version: 6.4.1; banners=-,-,- X-VirusChecked: Checked Received: (qmail 13342 invoked from network); 14 Sep 2011 11:25:55 -0000 Received: from smtp.tele.fi (HELO smtp.tele.fi) (192.89.123.25) by server-7.tower-182.messagelabs.com with DHE-RSA-AES256-SHA encrypted SMTP; 14 Sep 2011 11:25:55 -0000 X-Originating-Ip: [194.89.68.22] Received: from ydin.reaktio.net (reaktio.net [194.89.68.22]) by smtp.tele.fi (Postfix) with ESMTP id 406ED24EE; Wed, 14 Sep 2011 14:25:53 +0300 (EEST) Received: by ydin.reaktio.net (Postfix, from userid 1001) id EBC9F200A3; Wed, 14 Sep 2011 14:25:52 +0300 (EEST) Date: Wed, 14 Sep 2011 14:25:52 +0300 From: Pasi =?iso-8859-1?Q?K=E4rkk=E4inen?= To: Development discussions related to Fedora Message-ID: <20110914112552.GP12984@reaktio.net> References: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.18 (2008-05-17) Cc: xen@lists.fedoraproject.org, virt@lists.fedoraproject.org, xen-devel@lists.xensource.com, xen-users@lists.xensource.com, lars.kurth@xen.org Subject: [Xen-devel] Re: Virtualization Test Day for F16 and Xen X-BeenThere: xen-devel@lists.xensource.com X-Mailman-Version: 2.1.5 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xensource.com Errors-To: xen-devel-bounces@lists.xensource.com On Sat, Sep 10, 2011 at 01:33:54AM +0300, Myroslav Opyr wrote: > Hi, Hello, > Virtualization Test day is expected to be on September 15th this year > ([1]https://fedorahosted.org/fedora-qa/ticket/232). > So that's tomorrow! Luckily Xen Hackathon (@Munich) event is just happening, so hopefully we can get some more testing from people in that event. > We are willing to help test > [2]http://fedoraproject.org/wiki/Features/XenPvopsDom0 but find too little > information about test methods > ([3]https://fedorahosted.org/fedora-qa/ticket/219). It takes time for us > to setup test environment, and would be good to have some info in advance. > Regards, > I just added some Xen related mailinglists to the CC list, so we can get more feedback. Thanks, -- Pasi _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel From xen-devel-bounces@lists.xensource.com Wed Sep 14 04:59:26 2011 Return-path: Envelope-to: www-data@lists.xensource.com Delivery-date: Wed, 14 Sep 2011 04:59:26 -0700 Received: from localhost ([127.0.0.1] helo=lists.colo.xensource.com) by lists.xensource.com with esmtp (Exim 4.43) id 1R3o7i-0004k0-FA; Wed, 14 Sep 2011 04:59:26 -0700 Received: from mail216.messagelabs.com ([85.158.143.99]) by lists.xensource.com with esmtp (Exim 4.43) id 1R3o5h-0004Vx-5Z for xen-devel@lists.xensource.com; Wed, 14 Sep 2011 04:57:21 -0700 X-Env-Sender: Ian.Campbell@eu.citrix.com X-Msg-Ref: server-4.tower-216.messagelabs.com!1316001436!18209666!1 X-Originating-IP: [66.165.176.89] X-StarScan-Version: 6.4.1; banners=-,-,- X-VirusChecked: Checked Received: (qmail 17126 invoked from network); 14 Sep 2011 11:57:18 -0000 Received: from smtp.citrix.com (HELO SMTP.CITRIX.COM) (66.165.176.89) by server-4.tower-216.messagelabs.com with RC4-SHA encrypted SMTP; 14 Sep 2011 11:57:18 -0000 X-IronPort-AV: E=Sophos;i="4.68,380,1312171200"; d="scan'208";a="16984307" Received: from ftlpmailmx01.citrite.net ([10.13.107.65]) by FTLPIPO01.CITRIX.COM with ESMTP/TLS/RC4-MD5; 14 Sep 2011 07:57:16 -0400 Received: from [127.0.0.1] (10.80.16.67) by smtprelay.citrix.com (10.13.107.65) with Microsoft SMTP Server id 8.3.137.0; Wed, 14 Sep 2011 07:57:15 -0400 Subject: Re: [Xen-devel] Help with the migration to XEN-4.1 please From: Ian Campbell To: Flavio Date: Wed, 14 Sep 2011 13:57:14 +0200 In-Reply-To: References: <1315907178.2892.7.camel@cthulhu.hellion.org.uk> Organization: Citrix Systems, Inc. Content-Type: text/plain; charset="UTF-8" X-Mailer: Evolution 3.0.3- Content-Transfer-Encoding: 7bit Message-ID: <1316001435.2892.24.camel@cthulhu.hellion.org.uk> MIME-Version: 1.0 Cc: "xen-devel@lists.xensource.com" X-BeenThere: xen-devel@lists.xensource.com X-Mailman-Version: 2.1.5 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xensource.com Errors-To: xen-devel-bounces@lists.xensource.com On Tue, 2011-09-13 at 06:07 -0400, Flavio wrote: > > > > Did you start xenstored and xenconsoled? > Of course yes. I added xendomains in the default runlevel, which > strictly depends on xenstored and xenconsoled as you know. > And it has been the first check I've done once I encountered that problem. xenstored and xenconsoled are provided by the xencommons script, which you state below you don't have. > > i.e. did you add the > > "xencommons" initscript to your startup? > I don't know if it is a bug or something missing in the gentoo package > of xen-tools > but I don't have any inistscript called xencommons in my /etc/init.d directory. > I only have the file /etc/xen/xencommons configuration file on my system. You should have /etc/init.d/xencommons or Gentoo must provide you with some equivalent (I don't know enough about Gentoo to know) > > Do you have > > the /dev/xen nodes, especially evtchn loaded and available? > I only have evtchn under /dev/xen. I think that is sufficient. > > With pvops > > many kernels are more standard distro kernels rather than xen-specific > > and therefore stuff which was historically statically built in to the > > kernel are now modular. > So do you mean I have to check my kernel configuration or add/remove something, > or make it as module? You need to make sure you have the relevant backend drivers available (especially netback and blkback). It's up to you if you want to make them =y or if you want to use =m and arrange for them to be loaded on boot using whatever mechanism Gentoo provides for this. I think it would be useful if you posted your actual kernel configuration. Ian. > > Thank you very much, > _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel From xen-devel-bounces@lists.xensource.com Wed Sep 14 05:01:31 2011 Return-path: Envelope-to: www-data@lists.xensource.com Delivery-date: Wed, 14 Sep 2011 05:01:31 -0700 Received: from localhost ([127.0.0.1] helo=lists.colo.xensource.com) by lists.xensource.com with esmtp (Exim 4.43) id 1R3o9h-00057g-9D; Wed, 14 Sep 2011 05:01:30 -0700 Received: from mail216.messagelabs.com ([85.158.143.99]) by lists.xensource.com with esmtp (Exim 4.43) id 1R3o5i-0004Vy-PF for xen-devel@lists.xensource.com; Wed, 14 Sep 2011 04:57:23 -0700 X-Env-Sender: Ian.Campbell@eu.citrix.com X-Msg-Ref: server-4.tower-216.messagelabs.com!1316001436!18209666!2 X-Originating-IP: [66.165.176.89] X-StarScan-Version: 6.4.1; banners=-,-,- X-VirusChecked: Checked Received: (qmail 17194 invoked from network); 14 Sep 2011 11:57:19 -0000 Received: from smtp.citrix.com (HELO SMTP.CITRIX.COM) (66.165.176.89) by server-4.tower-216.messagelabs.com with RC4-SHA encrypted SMTP; 14 Sep 2011 11:57:19 -0000 X-IronPort-AV: E=Sophos;i="4.68,380,1312171200"; d="scan'208";a="16984314" Received: from ftlpmailmx01.citrite.net ([10.13.107.65]) by FTLPIPO01.CITRIX.COM with ESMTP/TLS/RC4-MD5; 14 Sep 2011 07:57:19 -0400 Received: from [127.0.0.1] (10.80.16.67) by smtprelay.citrix.com (10.13.107.65) with Microsoft SMTP Server id 8.3.137.0; Wed, 14 Sep 2011 07:57:18 -0400 Subject: Re: [Xen-devel] Re: Help with the migration to XEN-4.1 please From: Ian Campbell To: Flavio Date: Wed, 14 Sep 2011 13:57:17 +0200 In-Reply-To: References: Organization: Citrix Systems, Inc. Content-Type: text/plain; charset="UTF-8" X-Mailer: Evolution 3.0.3- Content-Transfer-Encoding: 7bit Message-ID: <1316001438.2892.25.camel@cthulhu.hellion.org.uk> MIME-Version: 1.0 Cc: xen-devel X-BeenThere: xen-devel@lists.xensource.com X-Mailman-Version: 2.1.5 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xensource.com Errors-To: xen-devel-bounces@lists.xensource.com On Tue, 2011-09-13 at 12:09 -0400, Flavio wrote: > I have recently upgraded to xen-tools-4.1.1-r4 but no luck with it. > > On 13 September 2011 10:58, Flavio wrote: > > 2) If I try to run a gentoo linux guest (for instance) running > > 'xl create vm_config_file.cfg -c' I get the following error: > > xenconsole: Could not read tty from store: No such file or directory > I would like to know what "file or directory" that message refers to. > What XEN is expecting to find as a "file or directory" and where? "No such file or directory" comes from strerror() in response to, IIRC, ENOENT. The ENOENT comes from xenstore and likely refers to a missing entry in there. What is the content of your vm_config_file.cfg? In particular I am thinking that if you have "file:" or "tap:" style disks you will need qemu-xen installed and if this was missing you might get errors like the above. Ian. _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel From xen-devel-bounces@lists.xensource.com Wed Sep 14 05:20:44 2011 Return-path: Envelope-to: www-data@lists.xensource.com Delivery-date: Wed, 14 Sep 2011 05:20:44 -0700 Received: from localhost ([127.0.0.1] helo=lists.colo.xensource.com) by lists.xensource.com with esmtp (Exim 4.43) id 1R3oSK-0005oX-0R; Wed, 14 Sep 2011 05:20:44 -0700 Received: from mail27.messagelabs.com ([193.109.254.147]) by lists.xensource.com with esmtp (Exim 4.43) id 1R3oRY-0005br-3J for xen-devel@lists.xensource.com; Wed, 14 Sep 2011 05:19:57 -0700 X-Env-Sender: royger@gmail.com X-Msg-Ref: server-2.tower-27.messagelabs.com!1316002769!54911053!1 X-Originating-IP: [74.125.82.171] X-StarScan-Version: 6.4.1; banners=-,-,- X-VirusChecked: Checked Received: (qmail 31559 invoked from network); 14 Sep 2011 12:19:29 -0000 Received: from mail-wy0-f171.google.com (HELO mail-wy0-f171.google.com) (74.125.82.171) by server-2.tower-27.messagelabs.com with RC4-SHA encrypted SMTP; 14 Sep 2011 12:19:29 -0000 Received: by wyh13 with SMTP id 13so1774046wyh.30 for ; Wed, 14 Sep 2011 05:19:52 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=sender:content-type:mime-version:content-transfer-encoding:subject :x-mercurial-node:message-id:user-agent:date:from:to; bh=FOfom0QpbYlwQeiiVdQP3APktlMMfH7SVqp55e00OQ8=; b=AQJ/AkyeMX7bZpBvvFpAY2g+pb1tJW58/zUiCAiy+dqdOH36l5V1zyuf+th/viqke3 /DjPj8SfarafZDmCPXYPBBF1nJH+0FIuGFwRAHNjFekf7+uPwLT0tB5rKWKmjDuv7wRm aGxLuzVx59YNuIz8gnS+Kl/NoijQz2V0mLjJw= Received: by 10.216.135.164 with SMTP id u36mr2203275wei.84.1316002792711; Wed, 14 Sep 2011 05:19:52 -0700 (PDT) Received: from [127.0.0.1] (monk.upc.es. [147.83.39.235]) by mx.google.com with ESMTPS id m2sm3899399wbp.5.2011.09.14.05.19.48 (version=TLSv1/SSLv3 cipher=OTHER); Wed, 14 Sep 2011 05:19:49 -0700 (PDT) Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Mercurial-Node: 63e254468d6e8d81baeafaed68f05791dc21eb4e Message-Id: <63e254468d6e8d81baea.1316002763@loki> User-Agent: Mercurial-patchbomb/1.8.4 Date: Wed, 14 Sep 2011 14:19:23 +0200 From: Roger Pau Monne To: xen-devel@lists.xensource.com Subject: [Xen-devel] [PATCH] libxl: create pci backend only when there are pci devices X-BeenThere: xen-devel@lists.xensource.com X-Mailman-Version: 2.1.5 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xensource.com Errors-To: xen-devel-bounces@lists.xensource.com # HG changeset patch # User Roger Pau Monne # Date 1316002720 -7200 # Node ID 63e254468d6e8d81baeafaed68f05791dc21eb4e # Parent ac33d68e89767d49113824e5661c49a5465a18e7 libxl: create pci backend only when there are pci devices. Signed-off-by: Roger Pau Monne diff -r ac33d68e8976 -r 63e254468d6e tools/libxl/libxl_create.c --- a/tools/libxl/libxl_create.c Thu Sep 08 15:13:06 2011 +0100 +++ b/tools/libxl/libxl_create.c Wed Sep 14 14:18:40 2011 +0200 @@ -584,12 +584,14 @@ static int do_domain_create(libxl__gc *g for (i = 0; i < d_config->num_pcidevs; i++) libxl__device_pci_add(gc, domid, &d_config->pcidevs[i], 1); - ret = libxl__create_pci_backend(gc, domid, d_config->pcidevs, - d_config->num_pcidevs); - if (ret < 0) { - LIBXL__LOG(ctx, LIBXL__LOG_ERROR, - "libxl_create_pci_backend failed: %d", ret); - goto error_out; + if (d_config->num_pcidevs > 0) { + ret = libxl__create_pci_backend(gc, domid, d_config->pcidevs, + d_config->num_pcidevs); + if (ret < 0) { + LIBXL__LOG(ctx, LIBXL__LOG_ERROR, + "libxl_create_pci_backend failed: %d", ret); + goto error_out; + } } if (d_config->c_info.type == LIBXL_DOMAIN_TYPE_PV && _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel From xen-api-bounces@lists.xensource.com Wed Sep 14 05:30:38 2011 Return-path: Envelope-to: www-data@lists.xensource.com Delivery-date: Wed, 14 Sep 2011 05:30:38 -0700 Received: from localhost ([127.0.0.1] helo=lists.colo.xensource.com) by lists.xensource.com with esmtp (Exim 4.43) id 1R3obt-0006px-TN; Wed, 14 Sep 2011 05:30:37 -0700 Received: from mail27.messagelabs.com ([193.109.254.147]) by lists.xensource.com with esmtp (Exim 4.43) id 1R3oaA-0006DF-5u; Wed, 14 Sep 2011 05:28:51 -0700 X-Env-Sender: lars.kurth.xen@gmail.com X-Msg-Ref: server-4.tower-27.messagelabs.com!1316003309!40212744!1 X-Originating-IP: [209.85.214.43] X-StarScan-Version: 6.4.1; banners=-,-,- X-VirusChecked: Checked Received: (qmail 1360 invoked from network); 14 Sep 2011 12:28:29 -0000 Received: from mail-bw0-f43.google.com (HELO mail-bw0-f43.google.com) (209.85.214.43) by server-4.tower-27.messagelabs.com with RC4-SHA encrypted SMTP; 14 Sep 2011 12:28:29 -0000 Received: by bkas6 with SMTP id s6so1923000bka.30 for ; Wed, 14 Sep 2011 05:28:46 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=sender:message-id:date:from:user-agent:mime-version:to:subject :content-type; bh=Y32/hLu9FZDX8ecG7GznG3P8hOMT1zQR5fn2rVmLMpc=; b=LJv44i08spH8Vgb3unRLfYFaysSTsmxg9+4ohKlK1AtOH9Fj/PaSbyNE4y2UubHZhh a2bs789c/XNVzVceO+pvV3aFrSlNyGKF7NAhAPCmxSDKdNa0Ga96wm7kkGk+Z9x2spN7 1QMHC9derBuwbFFpMuSfvzrrz3ekI1NIdwK8s= Received: by 10.204.130.3 with SMTP id q3mr2310328bks.17.1316003326341; Wed, 14 Sep 2011 05:28:46 -0700 (PDT) Received: from [172.16.26.10] (port-87-193-203-186.static.qsc.de [87.193.203.186]) by mx.google.com with ESMTPS id p9sm9941721fah.1.2011.09.14.05.28.44 (version=SSLv3 cipher=OTHER); Wed, 14 Sep 2011 05:28:45 -0700 (PDT) Message-ID: <4E709DF8.6060702@xen.org> Date: Wed, 14 Sep 2011 14:28:40 +0200 From: Lars Kurth User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:6.0.2) Gecko/20110902 Thunderbird/6.0.2 MIME-Version: 1.0 To: xen-users@lists.xensource.com, "xen-devel@lists.xensource.com" , "xen-api@lists.xensource.com" Cc: Subject: [Xen-API] Fedora 16 Virtualization Test Day! X-BeenThere: xen-api@lists.xensource.com X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussion of API issues surrounding Xen List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0775647862==" Sender: xen-api-bounces@lists.xensource.com Errors-To: xen-api-bounces@lists.xensource.com This is a multi-part message in MIME format. --===============0775647862== Content-Type: multipart/alternative; boundary="------------060907080800070403020404" This is a multi-part message in MIME format. --------------060907080800070403020404 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Hi, as you may know, Fedora 16 will have full Xen support for Dom0 and DomU in it. Fedora is planning a number of test days as part of their release cycle, including a *Virtualization Test on September 15th this year*, which is tomorrow. We are calling our community member to participate in the test day tomorrow: certainly many of us here at the Xen Hackathon in Munich are planning to do so. As always every extra volunteer who wants to help is very welcome. Information about the virtualization test day can be found here . We will have some people hanging out on IRC at #fedora-test-day and you can also get in touch with us via the usual channels. We should also have a test plan ready by later today, which should help you with the testing. Have fun! Lars --------------060907080800070403020404 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Hi,

as you may know, Fedora 16 will have full Xen support for Dom0 and DomU in it. Fedora is planning a number of test days as part of their release cycle, including a Virtualization Test on September 15th this year, which is tomorrow.

We are calling our community member to participate in the test day tomorrow: certainly many of us here at the Xen Hackathon in Munich are planning to do so. As always every extra volunteer who wants to help is very welcome.

Information about the virtualization test day can be found here. We will have some people hanging out on IRC at #fedora-test-day and you can also get in touch with us via the usual channels. We should also have a test plan ready by later today, which should help you with the testing.

Have fun!

Lars

--------------060907080800070403020404-- --===============0775647862== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ xen-api mailing list xen-api@lists.xensource.com http://lists.xensource.com/mailman/listinfo/xen-api --===============0775647862==-- From xen-devel-bounces@lists.xensource.com Wed Sep 14 05:34:23 2011 Return-path: Envelope-to: www-data@lists.xensource.com Delivery-date: Wed, 14 Sep 2011 05:34:23 -0700 Received: from localhost ([127.0.0.1] helo=lists.colo.xensource.com) by lists.xensource.com with esmtp (Exim 4.43) id 1R3ofW-0008FH-VV; Wed, 14 Sep 2011 05:34:23 -0700 Received: from mail27.messagelabs.com ([193.109.254.147]) by lists.xensource.com with smtp (Exim 4.43) id 1R3NEO-00008d-89 for xen-devel@lists.xensource.com; Tue, 13 Sep 2011 00:16:32 -0700 X-Env-Sender: philippe.simonet@bluewin.ch X-Msg-Ref: server-6.tower-27.messagelabs.com!1315898171!48708506!1 X-Originating-IP: [195.186.19.63] X-StarScan-Version: 6.3.6; banners=-,-,- X-VirusChecked: Checked Received: (qmail 4915 invoked from network); 13 Sep 2011 07:16:11 -0000 Received: from mail16.bluewin.ch (HELO mail16.bluewin.ch) (195.186.19.63) by server-6.tower-27.messagelabs.com with SMTP; 13 Sep 2011 07:16:11 -0000 X-FXIT-IP: IPv4[188.63.105.42] Epoch[1315898189] Received: from [188.63.105.42] ([188.63.105.42:49752] helo=[192.168.1.80]) by mail16.bluewin.ch (envelope-from ) (ecelerity 2.2.2.41 r(31179/31189)) with ESMTP id 59/03-11751-D430F6E4; Tue, 13 Sep 2011 07:16:29 +0000 Message-ID: <4E6F034B.5040102@bluewin.ch> Date: Tue, 13 Sep 2011 09:16:27 +0200 From: Philippe Simonet User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.2.22) Gecko/20110902 Lightning/1.0b2 Thunderbird/3.1.14 MIME-Version: 1.0 To: xen-devel@lists.xensource.com Subject: Re: [Xen-devel] Xen 4 TSC problems References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Mailman-Approved-At: Wed, 14 Sep 2011 05:32:42 -0700 X-BeenThere: xen-devel@lists.xensource.com X-Mailman-Version: 2.1.5 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xensource.com Errors-To: xen-devel-bounces@lists.xensource.com Hi Xen developers i just would like to inform you that I have exactly the same problem with Debian squeeze and xen, with 50 seconds time jump on my dom0 and domu. NTP is running on all dom0/domuU, clocksource is 'xen' everywhere. some messages : syslog : Sep 11 13:56:50 dnsit22 kernel: [571603.359863] Clocksource tsc unstable (delta = -2999662111513 ns) xm dmesg : ... (XEN) Platform timer is 14.318MHz HPET ... (XEN) Platform timer appears to have unexpectedly wrapped 10 or more times. (XEN) TSC marked as reliable, warp = 0 (count=2) ... I had some contact with Olivier Hanesse and it indicates that he doesn't have any solution for this problem, and all what was proposed in February didn't solved this problem. all suggestions are welcomed. Best regards Philippe config : -------------------------------------- Linux dnsit22.swissptt.ch 2.6.32-5-xen-amd64 #1 SMP Tue Jun 14 12:46:30 UTC 2011 x86_64 GNU/Linux -------------------------------------- HP DL385 -------------------------------------- vendor_id : AuthenticAMD cpu family : 16 model : 9 model name : AMD Opteron(tm) Processor 6174 stepping : 1 cpu MHz : 3058776.574 cache size : 512 KB fpu : yes fpu_exception : yes cpuid level : 5 wp : yes flags : fpu de tsc msr pae mce cx8 apic mtrr mca cmov pat clflush mmx fxsr sse sse2 ht syscall nx mmxext fxsr_opt lm 3dnowext 3dnow constant_tsc rep_good nonstop_tsc extd_apicid amd_dcm pni cx16 popcnt hypervisor lahf_lm cmp_legacy extapic cr8_legacy abm sse4a misalignsse 3dnowprefetch nodeid_msr bogomips : 4409.03 TLB size : 1024 4K pages clflush size : 64 cache_alignment : 64 address sizes : 48 bits physical, 48 bits virtual power management: ts ttp tm stc 100mhzsteps hwpstate -------------------------------------- -------------------------------------- PCI : 00:00.0 Host bridge: ATI Technologies Inc RD890 Northbridge only dual slot (2x16) PCI-e GFX Hydra part (rev 02) 00:04.0 PCI bridge: ATI Technologies Inc RD890 PCI to PCI bridge (PCI express gpp port D) 00:06.0 PCI bridge: ATI Technologies Inc RD890 PCI to PCI bridge (PCI express gpp port F) 00:0a.0 PCI bridge: ATI Technologies Inc RD890 PCI to PCI bridge (external gfx1 port A) 00:0b.0 PCI bridge: ATI Technologies Inc RD890 PCI to PCI bridge (NB-SB link) 00:0d.0 PCI bridge: ATI Technologies Inc RD890 PCI to PCI bridge (external gfx1 port B) 00:11.0 SATA controller: ATI Technologies Inc SB700/SB800 SATA Controller [IDE mode] 00:12.0 USB Controller: ATI Technologies Inc SB700/SB800 USB OHCI0 Controller 00:12.1 USB Controller: ATI Technologies Inc SB700 USB OHCI1 Controller 00:12.2 USB Controller: ATI Technologies Inc SB700/SB800 USB EHCI Controller 00:13.0 USB Controller: ATI Technologies Inc SB700/SB800 USB OHCI0 Controller 00:13.1 USB Controller: ATI Technologies Inc SB700 USB OHCI1 Controller 00:13.2 USB Controller: ATI Technologies Inc SB700/SB800 USB EHCI Controller 00:14.0 SMBus: ATI Technologies Inc SBx00 SMBus Controller (rev 3d) 00:14.1 IDE interface: ATI Technologies Inc SB700/SB800 IDE Controller 00:14.3 ISA bridge: ATI Technologies Inc SB700/SB800 LPC host controller 00:14.4 PCI bridge: ATI Technologies Inc SBx00 PCI to PCI Bridge 00:18.0 Host bridge: Advanced Micro Devices [AMD] Family 10h Processor HyperTransport Configuration 00:18.1 Host bridge: Advanced Micro Devices [AMD] Family 10h Processor Address Map 00:18.2 Host bridge: Advanced Micro Devices [AMD] Family 10h Processor DRAM Controller 00:18.3 Host bridge: Advanced Micro Devices [AMD] Family 10h Processor Miscellaneous Control 00:18.4 Host bridge: Advanced Micro Devices [AMD] Family 10h Processor Link Control 00:19.0 Host bridge: Advanced Micro Devices [AMD] Family 10h Processor HyperTransport Configuration 00:19.1 Host bridge: Advanced Micro Devices [AMD] Family 10h Processor Address Map 00:19.2 Host bridge: Advanced Micro Devices [AMD] Family 10h Processor DRAM Controller 00:19.3 Host bridge: Advanced Micro Devices [AMD] Family 10h Processor Miscellaneous Control 00:19.4 Host bridge: Advanced Micro Devices [AMD] Family 10h Processor Link Control 00:1a.0 Host bridge: Advanced Micro Devices [AMD] Family 10h Processor HyperTransport Configuration 00:1a.1 Host bridge: Advanced Micro Devices [AMD] Family 10h Processor Address Map 00:1a.2 Host bridge: Advanced Micro Devices [AMD] Family 10h Processor DRAM Controller 00:1a.3 Host bridge: Advanced Micro Devices [AMD] Family 10h Processor Miscellaneous Control 00:1a.4 Host bridge: Advanced Micro Devices [AMD] Family 10h Processor Link Control 00:1b.0 Host bridge: Advanced Micro Devices [AMD] Family 10h Processor HyperTransport Configuration 00:1b.1 Host bridge: Advanced Micro Devices [AMD] Family 10h Processor Address Map 00:1b.2 Host bridge: Advanced Micro Devices [AMD] Family 10h Processor DRAM Controller 00:1b.3 Host bridge: Advanced Micro Devices [AMD] Family 10h Processor Miscellaneous Control 00:1b.4 Host bridge: Advanced Micro Devices [AMD] Family 10h Processor Link Control 01:03.0 VGA compatible controller: ATI Technologies Inc ES1000 (rev 02) 02:00.0 System peripheral: Hewlett-Packard Company iLO3 Slave instrumentation & System support (rev 04) 02:00.2 System peripheral: Hewlett-Packard Company iLO3 Management Processor Support and Messaging (rev 04) 02:00.4 USB Controller: Hewlett-Packard Company Proliant iLO2/iLO3 virtual USB controller (rev 01) 03:00.0 RAID bus controller: Hewlett-Packard Company Smart Array G6 controllers (rev 01) 04:00.0 Ethernet controller: Broadcom Corporation NetXtreme II BCM5709 Gigabit Ethernet (rev 20) 04:00.1 Ethernet controller: Broadcom Corporation NetXtreme II BCM5709 Gigabit Ethernet (rev 20) 05:00.0 Ethernet controller: Broadcom Corporation NetXtreme II BCM5709 Gigabit Ethernet (rev 20) 05:00.1 Ethernet controller: Broadcom Corporation NetXtreme II BCM5709 Gigabit Ethernet (rev 20) 09:00.0 PCI bridge: PLX Technology, Inc. PEX 8616 16-lane, 4-Port PCI Express Gen 2 (5.0 GT/s) Switch (rev bb) 0a:04.0 PCI bridge: PLX Technology, Inc. PEX 8616 16-lane, 4-Port PCI Express Gen 2 (5.0 GT/s) Switch (rev bb) 0a:05.0 PCI bridge: PLX Technology, Inc. PEX 8616 16-lane, 4-Port PCI Express Gen 2 (5.0 GT/s) Switch (rev bb) 0a:06.0 PCI bridge: PLX Technology, Inc. PEX 8616 16-lane, 4-Port PCI Express Gen 2 (5.0 GT/s) Switch (rev bb) 0c:00.0 Ethernet controller: Intel Corporation 82580 Gigabit Network Connection (rev 01) 0c:00.1 Ethernet controller: Intel Corporation 82580 Gigabit Network Connection (rev 01) 0c:00.2 Ethernet controller: Intel Corporation 82580 Gigabit Network Connection (rev 01) 0c:00.3 Ethernet controller: Intel Corporation 82580 Gigabit Network Connection (rev 01) 0f:00.0 Ethernet controller: Intel Corporation 82580 Gigabit Network Connection (rev 01) 0f:00.1 Ethernet controller: Intel Corporation 82580 Gigabit Network Connection (rev 01) 0f:00.2 Ethernet controller: Intel Corporation 82580 Gigabit Network Connection (rev 01) 0f:00.3 Ethernet controller: Intel Corporation 82580 Gigabit Network Connection (rev 01) -------------------------------------- On 8:59 PM, Olivier Hanesse wrote: > Hello > > I've got an issue about time keeping with Xen 4.0 (Debian squeeze release). > > My problem is here (hopefully I amn't the only one, so there might be a bug > somewhere) : http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=599161#50 > After some times, I got this error : Clocksource tsc unstable (delta = > -2999660334211 ns). It has happened on several servers. > > Looking at the output of "xm debug-key s;" > > (XEN) TSC has constant rate, deep Cstates possible, so not reliable, > warp=2850 (count=3) > > I am using a "Intel(R) Xeon(R) CPU L5420 @ 2.50GHz", which has the > "constant_tsc", but not the "nonstop_tsc" one. > On other systems with a newer cpu with "nonstop_tsc", I don't have this > issue (systems are running the same distros with same config). > > I tried to boot with "max_cstate=0", but nothing changed, my TSC isn't > reliable and after some times, I will got the "50min" issue again. > > I don't understand how a system can do a jump of "50min" in the future. Why > 50min ? it is not 40min, not 1 hour, it is always 50min. > I don't know how to make my TSC "reliable" (I already disable everything > about Powerstate in BIOS Settings). > > Any ideas ? > > Regards > _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel From xen-devel-bounces@lists.xensource.com Wed Sep 14 05:35:30 2011 Return-path: Envelope-to: www-data@lists.xensource.com Delivery-date: Wed, 14 Sep 2011 05:35:30 -0700 Received: from localhost ([127.0.0.1] helo=lists.colo.xensource.com) by lists.xensource.com with esmtp (Exim 4.43) id 1R3ogc-0000I2-Po; Wed, 14 Sep 2011 05:35:30 -0700 Received: from mail216.messagelabs.com ([85.158.143.99]) by lists.xensource.com with esmtp (Exim 4.43) id 1R3ocb-00075H-Cx for xen-devel@lists.xensource.com; Wed, 14 Sep 2011 05:31:21 -0700 X-Env-Sender: Ian.Campbell@eu.citrix.com X-Msg-Ref: server-12.tower-216.messagelabs.com!1316003476!12493529!1 X-Originating-IP: [66.165.176.63] X-StarScan-Version: 6.4.1; banners=-,-,- X-VirusChecked: Checked Received: (qmail 25876 invoked from network); 14 Sep 2011 12:31:18 -0000 Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63) by server-12.tower-216.messagelabs.com with RC4-SHA encrypted SMTP; 14 Sep 2011 12:31:18 -0000 X-IronPort-AV: E=Sophos;i="4.68,380,1312171200"; d="scan'208";a="162928754" Received: from ftlpmailmx01.citrite.net ([10.13.107.65]) by FTLPIPO02.CITRIX.COM with ESMTP/TLS/RC4-MD5; 14 Sep 2011 08:31:16 -0400 Received: from [127.0.0.1] (10.80.16.67) by smtprelay.citrix.com (10.13.107.65) with Microsoft SMTP Server id 8.3.137.0; Wed, 14 Sep 2011 08:31:15 -0400 Subject: Re: [Xen-devel] [PATCH] libxl: create pci backend only when there are pci devices From: Ian Campbell To: Roger Pau Monne Date: Wed, 14 Sep 2011 14:31:14 +0200 In-Reply-To: <63e254468d6e8d81baea.1316002763@loki> References: <63e254468d6e8d81baea.1316002763@loki> Organization: Citrix Systems, Inc. Content-Type: text/plain; charset="UTF-8" X-Mailer: Evolution 3.0.3- Content-Transfer-Encoding: 7bit Message-ID: <1316003476.2892.27.camel@cthulhu.hellion.org.uk> MIME-Version: 1.0 Cc: "xen-devel@lists.xensource.com" X-BeenThere: xen-devel@lists.xensource.com X-Mailman-Version: 2.1.5 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xensource.com Errors-To: xen-devel-bounces@lists.xensource.com On Wed, 2011-09-14 at 08:19 -0400, Roger Pau Monne wrote: > # HG changeset patch > # User Roger Pau Monne > # Date 1316002720 -7200 > # Node ID 63e254468d6e8d81baeafaed68f05791dc21eb4e > # Parent ac33d68e89767d49113824e5661c49a5465a18e7 > libxl: create pci backend only when there are pci devices. I think I recall discussing this a way back but I don't recall the specific rationale, can you add something to the commit message please? Also does this continue to allow a subsequent pci hotplug to work? I expect it does but it would be useful to check. Ian. > > Signed-off-by: Roger Pau Monne > > diff -r ac33d68e8976 -r 63e254468d6e tools/libxl/libxl_create.c > --- a/tools/libxl/libxl_create.c Thu Sep 08 15:13:06 2011 +0100 > +++ b/tools/libxl/libxl_create.c Wed Sep 14 14:18:40 2011 +0200 > @@ -584,12 +584,14 @@ static int do_domain_create(libxl__gc *g > for (i = 0; i < d_config->num_pcidevs; i++) > libxl__device_pci_add(gc, domid, &d_config->pcidevs[i], 1); > > - ret = libxl__create_pci_backend(gc, domid, d_config->pcidevs, > - d_config->num_pcidevs); > - if (ret < 0) { > - LIBXL__LOG(ctx, LIBXL__LOG_ERROR, > - "libxl_create_pci_backend failed: %d", ret); > - goto error_out; > + if (d_config->num_pcidevs > 0) { > + ret = libxl__create_pci_backend(gc, domid, d_config->pcidevs, > + d_config->num_pcidevs); > + if (ret < 0) { > + LIBXL__LOG(ctx, LIBXL__LOG_ERROR, > + "libxl_create_pci_backend failed: %d", ret); > + goto error_out; > + } > } > > if (d_config->c_info.type == LIBXL_DOMAIN_TYPE_PV && > > _______________________________________________ > Xen-devel mailing list > Xen-devel@lists.xensource.com > http://lists.xensource.com/xen-devel _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel From xen-devel-bounces@lists.xensource.com Wed Sep 14 05:36:20 2011 Return-path: Envelope-to: www-data@lists.xensource.com Delivery-date: Wed, 14 Sep 2011 05:36:20 -0700 Received: from localhost ([127.0.0.1] helo=lists.colo.xensource.com) by lists.xensource.com with esmtp (Exim 4.43) id 1R3ohQ-0000gi-16; Wed, 14 Sep 2011 05:36:20 -0700 Received: from mail216.messagelabs.com ([85.158.143.99]) by lists.xensource.com with esmtp (Exim 4.43) id 1R3odA-0007JH-8y for xen-devel@lists.xensource.com; Wed, 14 Sep 2011 05:31:56 -0700 X-Env-Sender: fbcyborg@gmail.com X-Msg-Ref: server-15.tower-216.messagelabs.com!1316003476!17774401!1 X-Originating-IP: [209.85.212.41] X-StarScan-Version: 6.4.1; banners=-,-,- X-VirusChecked: Checked Received: (qmail 4947 invoked from network); 14 Sep 2011 12:31:17 -0000 Received: from mail-vw0-f41.google.com (HELO mail-vw0-f41.google.com) (209.85.212.41) by server-15.tower-216.messagelabs.com with RC4-SHA encrypted SMTP; 14 Sep 2011 12:31:17 -0000 Received: by vwm42 with SMTP id 42so2421114vwm.28 for ; Wed, 14 Sep 2011 05:31:16 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=0MqivcJtORNl4QLStCvBYJWnuDHaha6zVAAVOBnCo9c=; b=dHluv4FFaIFCVJxokgyh7WBAzCdz460nwkuDFK/QVMzBNPAsKGctnR4Z0RdIqocUJP +EogH9DDNVy1WMpWUKoYRHS2e/J8/8c9sVJPbMr+xoURrdrhq8aJBF6PevYcDkmEM7Gb G1PdSXVYXSISPvjHvimfbMhq3Ye+iwg+Ny0S8= Received: by 10.220.181.13 with SMTP id bw13mr276875vcb.187.1316003476327; Wed, 14 Sep 2011 05:31:16 -0700 (PDT) MIME-Version: 1.0 Received: by 10.220.166.67 with HTTP; Wed, 14 Sep 2011 05:30:55 -0700 (PDT) In-Reply-To: <1316001435.2892.24.camel@cthulhu.hellion.org.uk> References: <1315907178.2892.7.camel@cthulhu.hellion.org.uk> <1316001435.2892.24.camel@cthulhu.hellion.org.uk> From: Flavio Date: Wed, 14 Sep 2011 14:30:55 +0200 Message-ID: Subject: Re: [Xen-devel] Help with the migration to XEN-4.1 please To: Ian Campbell Content-Type: text/plain; charset=ISO-8859-1 Cc: "xen-devel@lists.xensource.com" X-BeenThere: xen-devel@lists.xensource.com X-Mailman-Version: 2.1.5 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xensource.com Errors-To: xen-devel-bounces@lists.xensource.com On 14 September 2011 13:57, Ian Campbell wrote: > xenstored and xenconsoled are provided by the xencommons script, which > you state below you don't have. I don't know why. I think this is a bug or an ebuild problem, because it is actually strange not having that initscript. These are the related files which are installed: /etc/conf.d/xenconsoled /etc/conf.d/xendomains /etc/conf.d/xenstored /etc/default/xencommons /etc/default/xendomains /etc/init.d/xenconsoled /etc/init.d/xendomains /etc/init.d/xenstored Could I insert the xencommons initscript by hand? Do you think it could be something safe to do? > You should have /etc/init.d/xencommons or Gentoo must provide you with > some equivalent (I don't know enough about Gentoo to know) I don't think there is something equivalent; maybe it's the case to open a bug report on bugs.gentoo.org. > You need to make sure you have the relevant backend drivers available > (especially netback and blkback). It's up to you if you want to make > them =y or if you want to use =m and arrange for them to be loaded on > boot using whatever mechanism Gentoo provides for this. I have both as y, so no problem for that. > > I think it would be useful if you posted your actual kernel > configuration. Sure. Here we go: http://pastebin.com/HC9Lsfjw Maybe it is not really optimized but I tried to do it as much as possible for my ability. On 14 September 2011 13:57, Ian Campbell wrote: > > What is the content of your vm_config_file.cfg? For instance, this is the config file I use to start the Gentoo VM (which was working very well with the XM toolstack: kernel = "/mnt/data/xen/kernel/vmlinuz-xen-3.0.4-domU" memory = "512" name = "gentoo-10.0-x86_64" vif = ['bridge=xenbr0'] dhcp = "dhcp" disk = ['file:/mnt/data/xen/vmstore/gentoo-10.0/gentoo-10.0.x86-64.img,xvda1,w', 'file:/mnt/data/xen/vmstore/gentoo-10.0/swap.img,xvda2,w'] root = "/dev/xvda1 ro" vcpus = 2 extra = 'console=hvc0 xencons=tty' ip = "off" > > In particular I am thinking that if you have "file:" or "tap:" style > disks you will need qemu-xen installed and if this was missing you might > get errors like the above. I have /usr/bin/qemu-img-xen /usr/bin/qemu-nbd-xen /usr/lib64/xen/bin/qemu-dm /usr/share/xen/qemu but not qemu-xen (I don't know what package to install for that) and there is no package named qemu-xen in portage. Maybe that qemu-xen is called qemu-dm on Gentoo. -- Flavio _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel From xen-devel-bounces@lists.xensource.com Wed Sep 14 05:50:30 2011 Return-path: Envelope-to: www-data@lists.xensource.com Delivery-date: Wed, 14 Sep 2011 05:50:30 -0700 Received: from localhost ([127.0.0.1] helo=lists.colo.xensource.com) by lists.xensource.com with esmtp (Exim 4.43) id 1R3ov7-0001Nh-NL; Wed, 14 Sep 2011 05:50:29 -0700 Received: from mail27.messagelabs.com ([193.109.254.147]) by lists.xensource.com with smtp (Exim 4.43) id 1R3oug-0001B7-Hs for xen-devel@lists.xensource.com; Wed, 14 Sep 2011 05:50:02 -0700 X-Env-Sender: dzickus@redhat.com X-Msg-Ref: server-4.tower-27.messagelabs.com!1316004581!40216688!1 X-Originating-IP: [209.132.183.28] X-StarScan-Version: 6.4.1; banners=-,-,- X-VirusChecked: Checked Received: (qmail 9256 invoked from network); 14 Sep 2011 12:49:42 -0000 Received: from mx1.redhat.com (HELO mx1.redhat.com) (209.132.183.28) by server-4.tower-27.messagelabs.com with SMTP; 14 Sep 2011 12:49:42 -0000 Received: from int-mx10.intmail.prod.int.phx2.redhat.com (int-mx10.intmail.prod.int.phx2.redhat.com [10.5.11.23]) by mx1.redhat.com (8.14.4/8.14.4) with ESMTP id p8ECnKrv004684 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Wed, 14 Sep 2011 08:49:20 -0400 Received: from redhat.com (dhcp-100-19-141.bos.redhat.com [10.16.19.141]) by int-mx10.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with SMTP id p8ECnHXx026410; Wed, 14 Sep 2011 08:49:17 -0400 Date: Wed, 14 Sep 2011 08:49:17 -0400 From: Don Zickus To: Avi Kivity Message-ID: <20110914124917.GS5795@redhat.com> References: <20110907134411.GV5795@redhat.com> <4E678992.5050709@redhat.com> <20110907155657.GX5795@redhat.com> <4E679AF4.50209@redhat.com> <20110907165203.GQ6838@redhat.com> <4E67A551.4000502@redhat.com> <20110913184044.GN5795@redhat.com> <20110913190320.GR7761@one.firstfloor.org> <20110913192152.GO5795@redhat.com> <4E7050F7.3000208@redhat.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <4E7050F7.3000208@redhat.com> User-Agent: Mutt/1.5.21 (2010-09-15) X-Scanned-By: MIMEDefang 2.68 on 10.5.11.23 Cc: Jeremy Fitzhardinge , Marcelo Tosatti , Nick Piggin , KVM , Stefano Stabellini , Peter Zijlstra , the arch/x86 maintainers , Linux Kernel Mailing List , Andi Kleen , Jeremy Fitzhardinge , "H. Peter Anvin" , Ingo Molnar , Linus Torvalds , Xen Devel Subject: [Xen-devel] Re: [PATCH 08/13] xen/pvticketlock: disable interrupts while blocking X-BeenThere: xen-devel@lists.xensource.com X-Mailman-Version: 2.1.5 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xensource.com Errors-To: xen-devel-bounces@lists.xensource.com On Wed, Sep 14, 2011 at 10:00:07AM +0300, Avi Kivity wrote: > On 09/13/2011 10:21 PM, Don Zickus wrote: > >Or are you saying an NMI in an idle system will have the same %rip thus > >falsely detecting a back-to-back NMI? > > > > > > That's easy to avoid - insert an instruction zeroing the last > nmi_rip somewhere before or after hlt. It's always okay to execute > such an instruction (outside the nmi handler itself), since nmi_rip > is meant to detect a "no instructions executed" condition. Ah. Like a touch_nmi_watchdog() type of thing. Interesting. I'll poke around the idle code. Need to instrument a reproducer first. Thanks, Don _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel From xen-devel-bounces@lists.xensource.com Wed Sep 14 06:19:23 2011 Return-path: Envelope-to: www-data@lists.xensource.com Delivery-date: Wed, 14 Sep 2011 06:19:23 -0700 Received: from localhost ([127.0.0.1] helo=lists.colo.xensource.com) by lists.xensource.com with esmtp (Exim 4.43) id 1R3pN4-0002pU-J6; Wed, 14 Sep 2011 06:19:22 -0700 Received: from mail182.messagelabs.com ([85.158.139.83]) by lists.xensource.com with esmtp (Exim 4.43) id 1R3pLd-0002bu-0V for xen-devel@lists.xensource.com; Wed, 14 Sep 2011 06:18:02 -0700 X-Env-Sender: adi@cg.tuwien.ac.at X-Msg-Ref: server-15.tower-182.messagelabs.com!1316006268!17304189!1 X-Originating-IP: [213.129.229.198] X-StarScan-Version: 6.4.1; banners=-,-,- X-VirusChecked: Checked Received: (qmail 25239 invoked from network); 14 Sep 2011 13:17:49 -0000 Received: from vrvis-198.vrvis.at (HELO iris.vrvis.at) (213.129.229.198) by server-15.tower-182.messagelabs.com with AES256-SHA encrypted SMTP; 14 Sep 2011 13:17:49 -0000 Received: from actoris.vrvis.lan ([10.42.1.75] helo=vrvis.at) by iris.vrvis.at with esmtpsa (TLS1.0:DHE_RSA_AES_128_CBC_SHA1:16) (Exim 4.72) (envelope-from ) id 1R3pLN-0002D3-6f; Wed, 14 Sep 2011 15:17:38 +0200 Date: Wed, 14 Sep 2011 15:17:37 +0200 From: Adi Kriegisch To: Konrad Rzeszutek Wilk Message-ID: <20110914131737.GI3079@vrvis.at> References: <20110914081156.GB3079@vrvis.at> <20110914102112.GB15866@phenom.oracle.com> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="sm4nu43k4a2Rpi4c" Content-Disposition: inline In-Reply-To: <20110914102112.GB15866@phenom.oracle.com> User-Agent: Mutt/1.5.20 (2009-06-14) X-SA-Exim-Connect-IP: 10.42.1.75 X-SA-Exim-Mail-From: adi@cg.tuwien.ac.at X-SA-Exim-Scanned: No (on iris.vrvis.at); SAEximRunCond expanded to false Cc: xen-devel@lists.xensource.com, Adi Kriegisch Subject: [Xen-devel] Re: Dom0 ACPI S3 patches X-BeenThere: xen-devel@lists.xensource.com X-Mailman-Version: 2.1.5 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xensource.com Errors-To: xen-devel-bounces@lists.xensource.com --sm4nu43k4a2Rpi4c Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Dear Konrad, first off, I am really sorry to first post that everything is just fine and then -- while responding to your mail -- getting the same crash again. :-( > > which I could solve: > > * Machine crashes some time after wakeup with "BUG: unable to handle kernel > > NULL pointer dereferenced at (null)". The crashing process was sshd as I > > am forwarding my window manager from a DomU to X with nouveau running on > > Dom0 with sdm. > > I fixed that by setting all interrupts in the BIOS to "auto-select" > > instead of the fixed default of "IRQ11". Since then I had no more crashes. > > Ok, any other data? Stack trace? Find that stuff attached: the archive contains the kernel trace (I took a photo, typed the stuff and checked twice... In case you want to have the photo, just tell me) and two relevant parts of the syslog (9.6G uncompressed): First part is last two messages of the suspend process from yesterday and the wakeup messages from today morning. The other part is me plugging in my phone (which I used to take pictures of the kernel trace), mounting it as usb mass storage device and finally copying images dom0 to the domU that runs my desktop. Right after copying finished I was looking at the images for some minutes. I noticed these WARNINGs on all other crashes too. From the first appearance of these warnings it took 2 to 10 minutes to crash. Apps that triggered the warnings were: apt-get, bash, cp, dpkg, gzip, swapd, evtchn, xenfs, xm_wm, Xorg, vi, "rs:main", "kworker/u:30" and several more... I hope this helps. I'd be more than happy to help out with testing! -- Adi --sm4nu43k4a2Rpi4c Content-Type: application/octet-stream Content-Disposition: attachment; filename="2011-09-14_-_Dom0_Crash_Backtraces.tar.gz" Content-Transfer-Encoding: base64 H4sICMykcE4CAzIwMTEtMDktMTRfLV9Eb20wX0NyYXNoX0JhY2t0cmFjZXMudGFyAOxdbXPb OJKez/MrcLUfNq6zZAAkQVJ12SvFLxnXJk4mtjN753KxQBKyOKZILknZVn79dYPUi2PRJi1Z t1d1mkrE0PTzNBrdjW4AxHDKWI+6PWZ6Pe8onVDvMJfF2Psgg9syl4EqDn7Z9EPhY1uW/obP z9/6mjFhmIxzLuA5ZjFT/EKsX3bwmRalzAn5JU/T8rnnXvr5/9EPf7n/i1kRpzcb9r8w6br+ NwXjVNh8pf859L8wufkLof/f/2/+OVcZYQZh1sCkA5OTKMvShNyqPFHxgFzZnFus75rgkPya HP/jwuyNCvIunPTo3oDkqjdJp0mpwj75kpXFgKg8T/Pifa70/V6e7gfpZBKV7+mvj5mMdUy8 bwATF9fk6+cBOZ8lQZTckFEUK7DBUk0K0u/3SZgmqt8WzuZmDfc1V5nMEbACI6M0JxP4LmKl sgrPJNQdcDGw6Ho80xSWAYo4yZX6gVDTQuWkyMBPSJan4C2FqoR8p2KZFSoktE8ZKVSQJmGx tyr7i1wCouYqFyhVRonWCN6SfqxIKYvbrRHagtqsUtYxdKrWVVcF2YIZgHE+LTKVhIgAghRp rN6BMO9AXSRJvfqWV1RPkTIlofKnN3vtSITBKRpJAY0dVP+RqyKU19pkxnmaRFph54fnpySQ wVi1xhXMWotbplmGkGFU3LYDs7nDhXFNrsJ8cg2Nnt4pOSUY9waUDSj00oAcRQX0ou5RH3RC ZBCoWOWyjNIE+rQDkfU80WUC0temIyeg6tFI5dAjXUgMbj5PcnwXBSVyVPBFe3CANp1rIkvp ZVH0UOPSARv1GTju4Sk5Pbsgh6h9tPqwPaztXhM1DiJvHIRL2LBvL2GPXgHrQsdO18DyjaS1 qLUedkUJH14By5z1sHQJO+wOKyywh9+OhuQUYkW8xPVXcV8hru1Y6/pMrvbZK5Rru+46LcgN leswvh52E+UKZtv28852Guq4EYxlAr/awdcEpxign8NeCd4fv16S1P9TBWV7CldAtgC2oRig qqVOXK2Tz8d/ISrpoA2Es6wGuHt5q3rTDKJ8Jv0ojsrZHJz4MzI8/HrahsToOwxHv+fVMoSR 6l79NVfkBgbVf+sGvB7ydRZiQEJGGWVNqFl6j1lJKUulDeRmqQ0cao+M9iRWnTzNR+p0BCM1 xHnIciCxy2IFFHIEuQLACaMPEYxMIPcoWjJYkHE4jRF6W+2wICcRjQF7eyzcMBsD7bZYbE5t 2hgft8XiAovdGC63x8JNq7KvGLFeNjIIB9TpZmKuQW3ofBRutQYAORXmuPNiQOe4dZvOWzXA 7DObM0brYkXeIWwGDYG6YkLOvp9j7pzms5ZYLtTIMJQsU8IkTXo+FJ3k8OulTvHbAXHoO2vR 4E/pfS9WdzA+56qYTtRCod3AsIXfVFGm+UaNnMMdJ9tpY5RAh8Ua6R8qIWU0gQ7Fsg7gCOuG dfb5FEaTMhiH6c0iGpN3QTZlUOmOZR7eSwj9oMukLEDwsssotqQByRiJCjLNXtOdf8hbXXVm kMenk01sF3Gxujy/j6DNStdgZ19++0EmaagIPI8q/EtLHQqcuIF4kQWRytK8XMQLyjD25QvL gSJnFN3UBbMswdNHhYLHHxh5dy8LvKAwstn75D6PdC2h71jU3mstiWlYjRlZF0m4g79rrYpS 3WJtZYEy1XZeHUVpexbH2AELs5pZdq1XZvNdtNi2dsCiZwkaxvNOenXRdcQjvepbvL1euWu8 Ordo32IDU9c3ZzGZ0Vyfdg5J4qeQ1EmtlsXWBEcW7Do4QhWMldQ6SdiuJXGbJOE7lsRglrte EmPXkhiiwU7MXUtiCvvVpQxtz4LTzW/OYhnNLDseuAzLdHfRYovvgEVwu3G6ctd6FebrC/wO LbboDlhs1tyWXevVbprS2G6LDXsHLI5hNE417TjRMhzhvnraq0OLcRLnzVlcqyr9lgTqFYnN T5aq77QfsEyGS2ANC0gbOw3es9rLwnGGTo5XNTLq7Ly+VsAjOeCW2UUnlstXO4bX08MtxBit dMzjXvHb0wvqvpI+WNCvktMO1Ib9SmqxltroEjRNUaf73dnNOfsjrYcjPhoFtEv7xWslMNZK wLpw2+YruR+HA/qk4upg+u5j2zNeJ8RGZZ/pUGGtCmHVQnxTo2lRzbhVgXc1Fu+TYJrnKinj GYmSlnPpmo1xt5qoVTKHX67ne5vn0g3Rp9xuP5euSThj7VfiFrOoHZbiKhZOn1s+7LJWpvEM nIZ7UAkawE1U1FtbboqIcErKPLq5qe5Q6IlY5ig7aw/uMA3uTWQGo0/+Tw+Akamc5nrLBdxC HpyXrig7QBu13L3e3whivwcguKyv3gEefO91AMSp5DhXMpwRsHfor3KsyMfzUzLoJJfbYtEb 5ERglFMvQeyTOL3fw9un337vogaTmo100AjtnbiAlASzeg0AXEuY7fFNnNksfPyDNT8uSIyn PohblLVvQt9hVACnUmVr3Ib9HFudP0QWdxcszGxyIbaxC1lY8bzoQmzpQl2gnScuxBYuxGoX Yu1dyOKs2YU6yMWNFttR5i7E1rtQBzqjmW4bLmTpCfnKhcxtupDjvvlUMbC4Ygcsgja6EN/Y hQRt40J86UK8A/RTF+ILF+K1C3XIiwQumje5UAe5mNFio9jchfh6F+pAx5vptuFCwjUazIPZ m5uHa71sHsAzNw9md4C2fzYPAKrNA660eTC7g3ngTr0G8+ggl015m/2JtX2goGvsowsfe4Zv GwbiUvHms7rAwuhOWKwmYxcbG7vL7BbGLpbGLjpAu0+MXSyMXdTGLtobu8t5s7F3kIubLfb4 zm1drLf1DnTP7HTbiqnrhaEqnbC2mE64jv12MdZ13LeKsa7LthtjXdfcRox1XdFix/q2Qixu kWuk24LZudRcZrFie2bn6h1cb7y+ASyC7oSlMXI7m7oQgLeJ3M7ShZwO0E8jt7NwIad2IWev PaD9TOTuIJdttniXZO5CznoX6kDnNNNtw4UYTt3VLmRv0YWY8fZLWcCi31t4cxZcnl/vQu7G LsQss4ULuUsXcjtAiycu5C5cyK1dyN3rAOg0u1AHuQRr8ZbX3IXc9S7Ugc5uptuGC3FurltP 3Qq0Yb9Z2g3g7hul3ZDdsq2m3QBobiHtdvXLxS++trittNvl6NsNdFsxD1xvWLNwvQ1sg73w Rtsf+tUqXwa3+9XWev2+rV67av1iAPLgTOfr3otqH8ENk+6AxNoJidgBiTDeLuwYwnqrsGMI e7thx7DpNsKOgannS28Ubi3qGE6jHW4lMDgvvLz+9cv5xStjgeO8AC3zAqG/fzj9ck6iJCpJ qc9VoI/2BBwdf/jQktRyhcPXHyEg87LLEQIAZnM9rf+qFrBHLTjmtG2N4Nou5qevIuWPSQ8t qz3pi2bQRGo8Jj0y204ouFAN0VeSmo9JT+xhB9LXqvcx5dFJO0qbOeAJz1MuX+7r/sa32Xds l+Mq9PMM2JBIxpFum0puokR1o7BaNwJfYmsN7XLmONXuQQtHvbxc7DDpk+gm0ZCtsKw+5ZTi mRNYARu9as8fdNdoGsekyBSMoJfnH+pIRpLpxIdwyeFp/VZfXVK0ZHJMgRsvQWqzT/H1dByX g0lI1OiAGgOTD+p38OhAUvLu/PiCnBwPLy6/HZ/v4Zk6MAqDOOm0bM+HE0xNfDTYNp8QjljL ZxzozPQx3+nRp+M9UkyDALSs2irRpYw5zSSUb4GEccfi5gpJtfdsiurApOTy6PPwwGi10Uv0 OatezQYwSPrPhxdDAonyLb4SyvoW+ehnBegeBptyWhDGDHJ+mCZlnsbEaLmBUPQF5SatHII9 7eoVlazt6k7aqcncdWQj62CVaUF2ePnt9OK/yMm34+P/Piafvhz+vbt9Vby4Yre2kazeM7g1 ewY+bhnc3pVSgcyg/wtKRV5zl0q19aTUgm+da7G2vmU7jos7kcoxeFQmQ08GWVS3AevSOLoZ l0ih/SlUsZx12osIDC6jZr1N88UNmpyZvO84RvstmpqA404tJDiBAbcY48iCezOnWb8DBGgB R9M6ZV2eMtb6ODHEMU18gfYuClVKPp394/vp0fEXHK1XBuqlWnWd+RMyq5ETVWbx9Ca8YriB cUBUOcbiQ1emp2fDw4vT78dkFMsbvXEZ33Ch1CCXX/c/fPsyPDocnl/sf778dHGKV1gA6YcY dMVPD327PDs7Pfu4fHhf70R+SSpXGBZIdaDK4KC+Of/WouJGXl0/hgQfbYB7pD67zymz7MWx N1WbydnpIfmE4T4qyCWAwI/IZwz5J5hgHE3BfB72yQkUeqQO+6Dsh4OLh7ac3MSD1YZHR98O v5ydvDs7vjg6/u4d/jY8+3i8N1e8HnB8BeaqcBofatl28HrqVGzjGMEnTOipIbh/HKmkJMym 5hUEmWsylgW6KPhsAhntEzdtENR2qOHuQtCFXNV5Dgu5n/9lNv/1fApFQZxKHBd+vUIh7gAq yOFR+HEeqWKfhOP6YYkH7Y0VJJtTCcloOR2Nrn+dEzE+sJwBe+LKDk429A2rOnUGs1rWMwZg +vdkDG7bmNOadU6rfsppn+cxHcuyVnnOgGcFfARKDvdJFH5XSZjm76nJGf7za56G0wCUzgK7 A5PRzFSUGJ6ggz+P8vfAMWfg++Rc5VDFnOl2vjc60IkVuhoPeF2K4yCEQ3mjyGeoW/Y6QLor kJ9lMh3JoITBLwfc9DaS7ZEEW0FabeGAPDzMZj9+SOn7QdAWUAhcbS2CInLIAIF7Rd1CJICh +icgtg7IASDTxtEMgYgzn085inLwmd4wwOM2CX50Y/UFavPRhxqMfP19QCgZnp2fDghvy2zp Mn2Fme2G2eKWi2u0Rbhs8bAspT6kRYtzoxLooIAUN5yUs0wR2hbZtnG+Y4HMmpGNrsgOdx7L fFWE/vUSX5/FqSOUnslYnQR7AdugFlbUq1IDdtAF27TXYNtm3zDwhLl1cltCGIy7gliM9/xZ iWH2JgogcPpxGtxCYHjHnb5LPn444Hafko/Rh722nIbe5fCU8488wpl2bNNgfrjQvh5fn9wM U1Ukf4WkaZrp+Yqjr19wWf3kcthSCNN0cKAHKfxBu18xTRgZQe6T4YUeEuE3YUScliMHkxE8 D0mCrDj6QWyGTjn9gosGuZ79QNGGF6sH+e6v/IPcR5C8+Nj0AiKvSoqojO6WB+y9LBda9erT 7oD9/HQSeoX6Jyngu5qkLqo7Xh3w89EtSlHgIFlOyAxGTOkV0NUgfxZMgkh6eZEHJMwn3u2k 8MYqzgAF/kkiHniRg4fuAmQGQc6TMRiJvi/jm9TzI+gpHLqCNFf6tr7ICkgadIvzKPVyeQ9E RXabk8nDxLufRHNe/bAMSHKXywkpswm0oMBvfe1HaQFpdAkVw6xasvHQKuIZQYgq+a6PJoZu 8KdlidnBQ2mSia/NivzphxyShoAJEk68SQrB4IYUeXUV6q8gxPQEnvFKRsNopBch59FisSCp Vw7jyF98l1LHFQ0BqUc+Af+pvz3o++U+lMVqev3SF4wYutVXsSxKMk2qHGdAovvYdIV1/UJn X0H0pmDlVFA8+O+rTpoYN4x9rLEmUDoEGbmQEWZyA/JxHrH/wL+MPu3THuvJSSjMlROw2lEd QteTCzw3fdDtF8nVf4zqjwOFibA4+9s1+U8o3fLEKyChz2Q59lD6NPl3+mA7B/TBCTbhgOpH Us1RLZ7dKi8rFWBzG7HZZthMuhrbQ8P2IHDGSnmFvFPeT2yMARtTm7DxUBhCs2WjZA4bIuxo M1gpVN2Iav2z9u6yBB9TpRfEOTIZHKjEyN2Ey7V8amgumQdjD8IHuAiuZVZvrGKLdK9swhEG wmJ1e7JpDi25wyVTCSOMF8sfM2yLZaDaHL4ZD8QVzXM38aaJ5ogjiO0FMgjd3zbdqGcUc6Vm eK5fhAVMhulvwhT4rmvWOoMo5v1Ik5pNzz4AjREAi2lt5C3CUrxujgpuveqMQWwCWhbfUFWG rIwYNYOSF9DjuZx59z76ukKrkv+S0kvKLWFaI40Ng3ItfTYtARzlNg1yBfevN2OwpP+IwcvS NPbwiH0dndDtmOFvg0lQtWRCksnEK8ZQaN6iHY0wisgNedBkuS+qFlXYMHpI7GqlXdvayFID 01ehxg5Tr8xnXplqTVVdg/ryUV8G25BlFFaBah2FL4BhJDYh8APfng9POlerTSuB8nsiC+wO U2FDbGujIVZZso6Eqyz1C/5AIjFC+RsNUr4yQqtuCvSJNmCd1nlYOMgx/AVELuqMBc5mTMKv RtmJfIChPHlMwV3s+HAzBrsecHPIvaf+JEIlMQyw3NgI2KZhNV7UOauH1YcnMe2upZfY3dbj 6aPukZBa5iKjgqonUBANy2Cc6AQI57qxL4BI/qsOFyPfqc0JjKmYJcFcQT4O20puhq1GlXru RsUc18WwN+Kb4Y6cysugppjjmuhaYpOx3zB8ZfE5LtSpuhO9EVQkmIvrDAO9qiNHr9e7Ivp/ eoJVAnFgiBPmyA5xvZtRm1zDA50RF58rEkxLAiWW0kCLTzfEP4bfcB1kgBtODnAL/wEYdK96 +CCOkulDj/dFT5dKB6HyI5kc+NMoDg+gzEWr18UThNNEHWA+e/DgCIQ4mEym/WAAJXtDzfFu r5ugv82PZU7kRA2I4zju8NPHbhif03Aaq0KvaqiQRMkACt1ZVoZEQrAGyT2oA/FyXu/6Jc6U +vFUlaCaMUniwtPzIHgRZKZhg4GD5vAPPOnNpz6nsiAPpVcG2TTM8Cobz4pQ3YF4enuPV61/ atX48S2GC32dqHJxXYUTvBxB+RwlkAwRPE0GMbzPw/PfL4+/DY+OF5AJyJCM5l+43IBmd+tF 2Z356A7+I1QjELT6WZR5GgFEnl/4eRTe4NR4hvMHBs4bkDhNM/JnOsNm4PTHOMT5ilAFnkzk /7D3b72R5Fii5/tV4nEGPV1pvJOFQB30w6BngOkNzD7nYD8UCgGX5KqKqYzLjkt1Vn/6IV1S pEJGc3cz46L88i90Z0ZGhLhMLneztX5cJH/99NdSzthHyCjV+7tft3/d3P7zx999v1sr+9TO 89MI+TFzGwet1M/zsQ9/6T/vyo7XxVtuP7y5vf/rw1/c/uPpOrAerAfrwXqwHqwH68F6sB6s B+vBerAerOdUrCdiPVgP1oP1YD1YD9aD9WA9WA/Wg/VgPVgP1oP1YD0XYz0J68F6sB6sB+vB erAerAfrwXqwHqwH68F6sB6sB+u5GOvZYD1YD9aD9WA9WA/Wg/VgPVgP1oP1YD1YD9aD9WA9 F2M9N1gP1oP1YD1YD9aD9WA9WA/Wg/VgPVgP1oP1YD1Yz8VYzy3Wg/VgPVgP1oP1YD1YD9aD 9WA9WA/Wg/VgPVgP1nMx1nOH9WA9WA/Wg/VgPVgP1oP1YD1YD9aD9WA9WA/Wg/VcjPVssR6s B+vBerAerAfrwXqwHqwH68F6sB6sB+vBerCei7Gee6wH68F6sB6sB+vBerAerAfrwXqwHqwH 68F6sB6s51KsRw1YD9aD9WA9WA/Wg/VgPVgP1oP1YD1YD9aD9WA9WM/FWI/CerAerAfrwXqw HqwH68F6sB6sB+vBerAerAfrwXouxno01oP1YD1YD9aD9WA9WA/Wg/VgPVgP1oP1YD1YD9Zz MdZjsB6sB+vBerAerAfrwXqwHqwH68F6sB6sB+vBerCei7Eei/VgPVgP1oP1YD1YD9aD9WA9 WA/Wg/VgPVgP1oP1XIz1OKwH68F6sB6sB+vBerAerAfrwXqwHqwH68F6sB6s52Ksx2M9WA/W g/VgPVgP1oP1YD1YD9aD9WA9WA/Wg/VgPRdjPQHrwXqwHqwH68F6sB6sB+vBerAerAfrwXqw HqwH67kY64lYD9aD9WA9WA/Wg/VgPVgP1oP1YD1YD9aD9WA9WM/FWE/CerAerAfrwXqwHqwH 68F6sB6sB+vBerAerAfrwXouxno2WA/Wg/VgPVgP1oP1YD1YD9aD9WA9WA/Wg/VgPVjPxVjP DdaD9WA9WA/Wg/VgPVgP1oP1YD1YD9aD9WA9WA/WczHWc4v1YD1YD9aD9WA9WA/Wg/VgPVgP 1oP1YD1YD9aD9VyM9dxhPVgP1oP1YD1YD9aD9WA9WA/Wg/VgPVgP1oP1YD0XYz1brAfrwXqw HqwH68F6sB6sB+vBerAerAfrwXqwHqznYqznHuvBerAerAfrwXqwHqwH68F6sB6sB+vBerAe rAfruRTr0QPWg/VgPVgP1oP1YD1YD9aD9WA9WA/Wg/VgPVgP1nMx1qOwHqwH68F6sB6sB+vB erAerAfrwXqwHqwH68F6sJ6LsR6N9WA9WA/Wg/VgPVgP1oP1YD1YD9aD9WA9WA/Wg/VcjPUY rAfrwXqwHqwH68F6sB6sB+vBerAerAfrwXqwHqznYqzHYj1YD9aD9WA9WA/Wg/VgPVgP1oP1 YD1YD9aD9WA9F2M9DuvBerAerAfrwXqwHqwH68F6sB6sB+vBerAerAfruRjr8VgP1oP1YD1Y D9aD9WA9WA/Wg/VgPVgP1oP1YD1Yz8VYT8B6sB6sB+vBerAerAfrwXqwHqwH68F6sB6sB+vB ei7GeiLWg/VgPVgP1oP1YD1YD9aD9WA9WA/Wg/VgPVgP1nMx1pOwHqwH68F6sB6sB+vBerAe rAfrwXqwHqwH68F6sJ6LsZ4N1oP1YD1YD9aD9WA9WA/Wg/VgPVgP1oP1YD1YD9ZzMdZzc4z1 rPperR1CFP5en2Ls/V6jmeFaz0Zs5FpPI568az1d6BrXehoD18K1cK1zd62nT3MH13oKNdu1 qo+Zxq5Vj9HGtabGlnGterTVrjU1rIRr1WPd3bqg95tTsHPIaSpMO3KaeNEEyGniPdYkvZ/6 LtppUOerb6xBUxHaa9BUpNYaVP95tNGgibEba9BUlGYaVA/QXoPqcZpq0MS3IqBBU5HaadBU hNUaNDFwaw2qh2lDKVNjr6WUqXHXUsrp8IKFF+AFeAFegBfgBXgBXoAX4AV4AV6AF+AFeAFe WMcLDl6AF+AFeAFegBfgBXgBXoAX4AV4AV6AF+AFeGEdL3h4AV6AF+AFeAFegBfgBXgBXoAX 4AV4AV6AF+CFdbwQ4AV4AV6AF+AFeAFegBfgBXgBXoAX4AV4AV6AF9bxQoQX4AV4AV6AF+AF eAFegBfgBXgBXoAX4AV4AV5YxwsJXoAX4AV4AV6AF+AFeAFegBfgBXgBXoAX4AV4YR0vbOAF eAFegBfgBXgBXoAX4AV4AV6AF+AFeAFegBfW8cINvAAvwAvwArwAL8AL8AK8AC/AC/ACvAAv wAvwwjpeuIUX4AV4AV6AF+AFeAFegBfgBXgBXoAX4AV4AV5Yxwt38AK8AC/AC/ACvAAvwAvw ArwAL8AL8AK8AC/AC+t4YQsvwAvwArwAL8AL8AK8AC/AC/ACvAAvwAvwArywjhfu4QV4AV6A F+AFeAFegBfgBXgBXoAX4AV4AV6AF1bxQhrgBXgBXoAX4AV4AV6AF+AFeAFegBfgBXgBXoAX 1vGCghfgBXgBXoAX4AV4AV6AF+AFeAFegBfgBXgBXljHCxpegBfgBXgBXoAX4AV4AV6AF+AF eAFegBfgBXhhHS8YeAFegBfgBXgBXoAX4AV4AV6AF+AFeAFegBfghXW8YOEFeAFegBfgBXgB XoAX4AV4AV6AF+AFeAFegBfW8YKDF+AFeAFegBfgBXgBXoAX4AV4AV6AF+AFeAFeWMcLHl6A F+AFeAFegBfgBXgBXoAX4AV4AV6AF+AFeGEdLwR4AV6AF+AFeAFegBfgBXgBXoAX4AV4AV6A F+CFdbwQ4QV4AV6AF+AFeAFegBfgBXgBXoAX4AV4AV6AF9bxQoIX4AV4AV6AF+AFeAFegBfg BXgBXoAX4AV4AV5YxwsbeAFegBfgBXgBXoAX4AV4AV6AF+AFeAFegBfghXW8cAMvwAvwArwA L8AL8AK8AC/AC/ACvAAvwAvwArywjhdu4QV4AV6AF+AFeAFegBfgBXgBXoAX4AV4AV6AF9bx wh28AC/AC/ACvAAvwAvwArwAL8AL8AK8AC/AC/DCOl7YwgvwArwAL8AL8AK8AC/AC/ACvAAv wAvwArwAL6zjhXt4AV6AF+AFeAFegBfgBXgBXoAX4AV4AV6AF+CFVbywGeAFeAFegBfgBXgB XoAX4AV4AV6AF+AFeAFegBfW8YKCF+AFeAFegBfgBXgBXoAX4AV4AV6AF+AFeAFeWMcLGl6A F+AFeAFegBfgBXgBXoAX4AV4AV6AF+AFeGEdLxh4AV6AF+AFeAFegBfgBXgBXoAX4AV4AV6A F+CFdbxg4QV4AV6AF+AFeAFegBfgBXgBXoAX4AV4AV6AF9bxgoMX4AV4AV6AF+AFeAFegBfg BXgBXoAX4AV4AV5YxwseXoAX4AV4AV6AF+AFeAFegBfgBXgBXoAX4AV4YR0vBHgBXoAX4AV4 AV6AF+AFeAFegBfgBXgBXoAX4IV1vBDhBXgBXoAX4AV4AV6AF+AFeAFegBfgBXgBXoAX1vFC ghfgBXgBXoAX4AV4AV6AF+AFeAFegBfgBXgBXljHCxt4AV6AF+AFeAFegBfgBXgBXoAX4AV4 AV6AF+CFdbxwcwwvzMmFY0p+ML/nwlOZ7LK88+10MlnLBmupWy3POiY/OibP+dOzF8G4p5/v cPwrZ9Lui97a5yNZ/WOkeQnC7ovjwxc/zwRGT9Rn4ZY/Bd8+v2YfpJ+DJUpQgs/BXQB3zHPw xxPwqKffw8D5By333CsRounx3NtFCpLPvRIhKYHn3m5gO/Xce3zqPXvm3X8qkPngbbvbUDG4 8oLlmJujQ4ZByVQDu7GdzPN1N3Zq/3wt4yrd/vm6G/en5+vzx+juT+PoyVi38ppyL2Lqfz/+ 0nW+uAlHnibhfco7SbYTFFuj1XlaehyKHmmdsxVzWi33IuTRtph/SHHQz2xxZoa0++LjtfCt nUp7qknPMTnPkSJ0LO786cX3tvvgDfNej/w1tjrOgrQnDvvynSbpTvVKBZOdapSWyU4twHSu c3SqUxm2da5TCSGU61QjNc11qhFa5Dq1gVvX+PUwgx+c/THX0CaNqoZplEZVxm6WRlXHbpBG VcdtkEaNxzXm5ieTePpLP2VTE30HlWRqSS717/Muv55K7Zlcn0ylpqe+p+a0O2VS3ROp/ZO5 55dIbYUzqfNNpPRJZFI/vxGF3n2yb74/x14WetJVwem8m/e8makL9ieOtcnA+Qq6G5nKgMqA yuBCKoMfE5iHSoTjCwRpbW1cIty/m10krK8RmvamHt2AOr+5dKHLnm5GN9WouTCjW1ueVOa2 O5QnCzK6qZRuWU73F7BXKqnbLszqSOtI60jrLi6t++dS+n2lxG5uXndaaV1D+m2XqwnNoAvL 7+u2IR7VhbgI39rVWa9XZrVuapnzgfx4RpMxny5sNmYaxM/vY3kiBdRJdsr86QqqpyZdwXj4 qRdO1E3UTXPrphetx6OK6eiC6bzqpds2zTIfz6dkurj0zA1teZv0rG16dvkNC/J9zLg26Rnp 2VWzdrME7fVE+80/OvUqNGho/jovRzvmnvbyx8vdjLvZda/K8MfPBTQrNV2TO9krNl1J1Jq5 GLmQtRlMBlBtXnQjFc3xVJvLuqjIz8jPjqw2lxWb59I/JV9rzsrRXncXkoX9Gic8H/DKKVrD hveVaxgbtryf5JzA2z/R8c7MAB3vF5esPX2uk8opiRP/NnZhkkzOWca2QjnnbmyBDWV346b2 OWcZ15ljcs7d33SLt2sRTTrLteXsp0vT/v8j54JfzzLtPB4G84/JlrfQorxz98WhSd7ZfJHl v5zIKsvts7u0TcNMGNx9kfl544zd7z27n82/1brj+oSTWm2DJZhW0innLoqTs8Hd+FHCBsvI xryY7myab+4idNk2v0Syg2S+uYtgBfLN3cDhwPbBa7PNEsSpHmmac1YsTXMuiqVpzmuRNM15 J5KmOR+PTNNc2d28Yx+KOz5Lc3F41aWVd6+4QXGH7Gq3r/3S7MoHc5q7kp3ctGt+sZ7vmH78 /SwM8QXpld9UC+ddd18bjjufoU16FYzvkF6F8YO9oejtAthZpzPYY/Krh4GjqOeVEE53yq+C 88L5VXBJJr8KXt7zdmF8jwwrhEEswwrBiGVYIQSRDCvEQSTDCtFWM6yf+uN2f88fbo97fodP P0Zcv56gDKeGv8jeZHYRutxkqpGa3mSqEVrcZGoDC9xkKmEkbjLVMI1uMpWxm91kqmM3uMlU x21wkxmPO1XG7f7maZZx+dJmNuGe1CEzTftvT6674+mts2yHnKevPpvtqVv2dgwLKsFnH+j5 d8SfCsHnI62+x7440PeYxo81NeLbP+29dQpUidUoLavEWgDSN9I30jfSt/ouh4cSuBPZ4vDx 0uYuo5LfsuMStlQ70xzuFS2/Rvlb6SNGpBO4xRncMceMkKgdfJK3aNAlV5PJ1VoWPR17i/i0 8Gk598qGwobCZl5h83Ly62VRc1Io/Zod4N33t2ld0dxJH34+KmrOy6WbH7HTtDnpFAsaaXS+ 2txsXmoWyc1QZ5KzS1TnZdlZ7z2ie4LzeXjzh06bdi3Ozc6KmwXW5X0R2g1ibXrWsl9Ampqh s5l0NpGfPbxjl3a19H2HTrxBV9Lu1b09gV2KB4oHioduxUP/fuPTg90TXDN6FtvJ9XbdUy8e mqZl25PtVPnz26uefBdM0eYtPCVDI0MjQ7v0ufdXWBA2L0N70+MIQLqJzwB3T21jkJ77gpxS inbc9Pv59hI/+3BcxzyHxBY5JzrPcVY9wifdUy9XpyxzZIoUihSKlMta+XioDWVi5ePlUvKb 19264px3iD4JSv7Qeovo5VtXfOlQq7xqfnbd6ZlwJ8rXtq0opGmkaaRp17S/2EltTtFlvr9P jtZ7c7HLWsLVJT17xUPjnn+QmyVnP26sV99B0utttb2OCYpTTPovX2TbbUZHsn9eezaQ6pPq N28beSWNrbeNtO0akevsPc2ukfNcEzh5SvTJZGUnuN6qZU7280T5n9hdge7bxknUohxqsivq pzwJESVNmpMmLdurt9XGCU5254QtWyf8tLPVJWVJ19ZS2DpPan60wofnadNv2zy2NW/+nH// L+siuM3NTxEeeKxkQOUFVOXHq8xNi0h+2I5ODnxAtxzJlNu436yMU5I5feNv2E1iwRz+u4+f fl8Sti3fyDG7fu2JQ3bKfD7Z6/kfOJHH/bb9sPsh/tSCuftUzYzxU/K7fRPzI87b+3A3RO/1 4HYp8OwRf/yvKo6zR/wf//bf/9v/+d/+/Y85fXvzy5dPn779kt/QFbb8w/CH4Ze77c37zcdf br6///Xul6+fvpd3/eZDTs/y7fTj9pfNl9u//fJb9GWIXz58+P6H2z9aqyeyqGNS+ucX+n9s vtzlDG375uPmw/aPb2KM6d/+r5kw+h+f7r6XLD1/X3/f3r15//GPOYH95+dvd282+Wadr/xd zjTLLx/vHW9uvn3/evPm5tfv22+fJiqGf9znV678f/6b775++/Ql35bffN98ffPbt3ffbj9/ v/tcfvX5b//8mrP7HwXEZJnx7cevH24n5Zf3OZF+/zEnQ2/uv3/dljHe/ce//X//7////76v Jvn08WN52/393fvP/7A//U75j7vtfb7Qhz97//mpepnen/fm7s2vnz59fvP/fPpn+TZ2Zctd qSjutrni+Lj59dNf3+Qf/0S5s/u77z9+2/765uOn7//Ybr7/PEJ+zNzGQSuVi4f8o6lVR6XO uc31xv1fH/7i9h9P15ELp92/v73/kF/Rx9+ZtUnwl9s3d18+vPv7h6/v/rb99XMeJf/nrpY6 6lC7u11dVX5794vPXz98Kj+mr/kdlB86m//Mgb5+/vuXN8dWY7tf37z/lH8MOV3ffvnnm8+f /nOb64Lvnz//+s83ZYh/vF9Ssn3965uvXx5+dTddwz2998uvP79//9ubTa7d8kfm5se/v23e fL39+n43xGO1t6dTefeL/CgbtuUjsvuu//xrvrO++f7x10+bu22u8fK7xaYVJ7n8b29Kg/Ef 81V9fvP/25Q3Wv6Tf3/z+L//Uf6xu4H9q/rX3e1K1tynH1/Wu8n26E8f870xxHJvXJWIDtZs hh+Zyezq9cDYavOUTOc39nShW6qp8sDcron2c538OOxdGfZ+3bAb/3QYTmVzkG/vbn/9UiKZ kmL5+7Qm1t2tC7rWgb7dvPt181//LD9yW76jqNeFOXQK428qrEoW9+6n8uMl8yUTM/bmVFNe vTWbhx99ueiHEm3z5cvmn+/+s5TNukhDPM2EHSFBSBAShAQhQUiuRUg8QoKQICQICUKCkCAk CAlCgpAgJAgJQoKQICQIydULSUBIEBKEBCFBSBAShAQhQUgQEoQEIUFIEBKEBCG5eiGJCAlC gpAgJAgJQoKQICQICUKCkCAkCAlCgpAgJFcvJAkhQUgQEoQEIUFIEBKEBCFBSBAShAQhQUgQ EoTk6oVkg5AgJAgJQoKQICQICUKCkCAkCAlCgpAgJAgJQnL1QnKDkCAkCAlCgpAgJAgJQoKQ ICQICUKCkCAkCAlCcvVCcouQICQICUKCkCAkCAlCgpAgJAgJQoKQICQICUJy9UJyh5AgJAgJ QoKQICQICUKCkCAkCAlCgpAgJAgJQnL1QrJFSBAShAQhQUgQEoQEIUFIEBKEBCFBSBAShAQh uXohuUdIEBKEBCFBSBAShAQhQUgQEoQEIUFIEBKEpBIm2uilbrjRJjEhyWNbCSHJ4wYJIcn/ VtJCkv9tDwiJGmYJSf63bysk0Z2JkOQL1WuFJI9hERKEBCG5BCGJXqlOQpJDmUVCkr/QSwtJ 9FpMSPLYpp+Q5GhBQEiiN92EJMeyHYQkh4myQhK9VX2EJEdyYimvt1FWSGL+NMtdvQuyQpJz UNNHSHKk2ENIog9GSkjy2F5eSKKPskKSA9geQpLjRGEhiT7pPkKSI3lZIckRkoiQxDCYDkKS w/geQhLkSDqPbcSEJKggIiRBi/SQ5HGtuJAE7Q8JiZonJEHHxkISjDoPIQkl9VwpJMF4hAQh QUguQkhiqaf7CEnUaZmQRKPFhSQaLyYk0XbsIcnRjISQROu7CUn+RQ8hic4KC0l0oZOQRK/E Ut7orbCQRB/lrj4YYSGJIXUSkviiLJcSkjguy5sJSRzX4wJCEpOXFZI0dOkhyXGstJCkIXYS kqS0sJAk5WSEJP9fDyFJWvcQkqTlekiSTmJCkowREZI0Tv+aCEmy4qtscgx9SEj0PCFJ1jYW kmTDeQhJcqtX2eQxNEKCkCAklyAkOf/SnYQkh7KLhCR/YZQWkjRUZrEbCUke2/UTkhwtCghJ GrzuJSQ5lusgJDlMkhWSNIzn4mWEJEcSS3lzASW8yiZHMIJXn2SFJA3J9hGSpIYuq2xyHCsl JHnsKC8kSSktKiQ5gOshJElp6VU2OYTtIyQ5UpAVkqSMEhGSPLDtICQ5TOwgJElZMVDPYzsp IcljJwkhSWqc/rUQkjyukxaSHCMeEhIzS0iS8o33IckjmrMQknyhfq2Q5DECQoKQICQXISS6 3F77CIn2y/YhyV9oxYVE+yAmJDqojkKig5UQEh1CNyHRUfUQEh2dsJDoGDsJiU5i61Ty2E5Y SPS4N77Z1ZvBCguJ6bUPSY7kugiJ0WL7kOSxTQchMeNavK2QmEopLiEkxjhpITEmdRISM+5v bCwkxnoZITGuxz4kOYzpISRm3NzY7oY7bmdsJiTGi+xDkscV2YckmSC+D0mOYQ4JiZ0nJCY0 3ockj5jOQ0hMST1XCokp8z0ICUKCkFyAkNhST/cRElvuu0uExIYkLiS2MovdSkhq26LJCUll o7QWQmKT6SYklX3TJITEDcI7tSY32E5C4gaxdSrJKSUsJLu9zaSuXgvv1JojuE5C4l6U5VJC 4sZleTMhceN6XEBInDWyQuJs6CIkzilpIXHOdRIS56KwkDivZYTEjfsaJYTE+dRDSPLDVO6G G7yYkLgocpZNHteICIkbpX7thcSVJsn9QuLmCYlLqrGQuNJmeQ5C4krquVJIXIoICUKCkFyE kIShm5CEISwTkjCu0JoLSVBOTEiC7rgPSRpvDtZESHa7d3USkjBebSwhJMEEYSEJvXZqzZHk VtkEJ73KJjgnd/VeCQtJ8KGTkITQZR+SHCeJCUkYb3EqICShspNKUyEJYzEWEZKQpHdqTbGy CamMkMRBepVNVEJCEsfbxUsISdQ9zrLJYeRuuFFuH5IUjUwPSRwvbmoiJNFqcSGJZVXTfiHx 84Qk2sY7taZYVjGdg5DEkomsFJLd7nMICUKCkFyAkKSy0qCPkKS4UEhSkheSlKR2atX5B9ZP SEo0ASEpw/YSkhxLdRCSEkZWSHKE8b57IkJSIkkJSR7byPaQlAhO7uqtrJCUCLGLkORIroeQ lDhSQpLH9vKrbEoUUSHJAUIPISlxhIUkh4h9zrIpkWSFJEdIIvuQlIE7CIke1NBBSEoYuRuu GqSEJI+tJHZqLeNKrLLJ42ppISkxDgpJmCMkZcS2QpJHPI+zbMqFrhWSMgZCgpAgJJcgJHrY 7fHRQ0hKqEVCkr8wSAtJieHEhESPZ2QFhURHLSEklU07xIREx9RDSHQywkKix2m1kJCYYRBL ec1ghYXEDEHu6pURFhKjegnJyz08pITE6CgmJMboDkJS2b6jrZDUNu+QEBJjrbSQmMqCIRkh MU4JC4lxTkZIjIs9hMR43UNIjJcTEuPlhMQEGSExwYsIiRmlfu2FxMSDZ9nEeUJiom0sJCaG 8xASk4bVQmKK0iIkCAlCcgFC4pTuJSSuLGRZIiROJXEhcdqICYkb1xuCQuKMiJA447sJibOq h5A464SFxNXWp4gIiXNWLOWt7B7QWEicN3JX75OwkLjgOgmJi6qLkLjxXH8zIXHjWX4BIXGy p/3qXLaqLkLiBy8tJF6pTkLia2fxNhUSP16l0kZIvLY9hMTr2ENIvNFiN1xvgpiQeKtEhMTX zt9pICTeDeJC4t3BnVrTPCHxzjcWEu/PpIfElxnjlULiy3k4CAlCgpBcgJDsllP3EZKQ/DIh ieP58eZCEsfz5M2EJA49e0iiMhJCElXoJiRxvDhFQkjieGVKYyGJRnUSkii4TiWOp8sbC0m0 cr4T3SAsJNH5TkISX8wwSwlJ9HI9JDH06CGJIcgKSYx9hCRGcSGJqZeQxMpSlbZCkgYhIUlD FyFJQ+ohJEnJkXRSUUxIktYiQpK0TA9JMkpcSJKxh4RkM09IUjGupkKS7HAeQpLKDt8rhSRZ hAQhQUguQkjUULL7LkKidovbFwiJGsadp62FJMcQ24ckj91RSFRlgXwDIcnDdushUUMcOghJ DiO8ykZV1t3LCImqrL9vlfLmsYVX2eQIUezq1SC8yiZH6LTKRinVZR+SHEdsHxI1XpovICQ5 imwPiVJm6CEkOY70KpscIvYRkvz21bJCkiPIrLLJA6cOQqKU67HKJofxcjdcP0gJSR5bZJVN HldESPJ9XryHJMc42ENyM0tI8oiNe0iUiuchJPlCVwtJHsMhJAgJQnIRQrJbpd9HSMzCVTb5 C8VX2eQqXqyHRJmeq2yUEVllk4ftJySmyyqbHEZ4lY0yvVbZ5EhiXRh5bOEeEmXkVtkoI73K Rr1cxC4nJCZ26SFRRm6VjTKph5AY4VU2yvZZZZPjSPeQKNtrlU2OJLzKRlmhVTZ54B49JDlM j1U2yhq5G66VW2WjrMwqmzyuyCobZeVX2eQYB4Xkdp6Q2NarbPKI6TyExPr1QmI9QoKQICSX ISQu9dqHJIdaKCQuyQuJH8T2Icljh45C4pWIkHjVT0jyM72HkHgtLSRep05C4o2ckHgjvA+J 8lYuYfdWWki867QPifK+yz4kOY6ckPjQYR+SHEVYSHyfVTY5jriQ+DR0EhKfpIXEj3OFNkIS KkciCwhJGLoISVByj4ugxHZqVUHL9JAELXKWjQpG/CybHOPgWTZ384QktF5lo4I9j31I8oWu 3ockj8FZNggJQnIZQrI7+ryPkOw2BFgiJHE8P95cSHZnmAsJSfSqo5BEL3Har6psTSAmJJWt CiSEJAZpIYmhl5DEKGcMla0QGgtJjEnu6pMTFpKXex/ICUkafBchSWoQE5I0Ls4EhKSyGUJb IansiCAiJJUdEloLSTK9hCSNHbexkCQTZIQkjbsXJIQkWddDSJKVu+EmZ8SEJLkoIiTJaxEh SaPVO+2FJJUmyf1Csp0nJCnoxkKSClifg5CkkrGtFJIUOcsGIUFILkJI9G4NfRchKavbFwlJ WTUrLSS6svK+lZBoVVvBIyUkWukoICRlrVAvIdFqnOYKCElp+pYVktJw2UdItHJip/3msYX3 ISltYnJX74WFpMya9hGSHCn2EBKtxt7WSkgKh8kLSZEFUSEpuXQPIdF60MJCkkN0Ou23PGZl haR83EWEpLxKHYQk/6+HkOT/yd1wtRETkjy2iJBobUWEJI8rLiQ5xkEhuZ8lJPk92FhI8ojn IST5QlcLidYeIUFIEJLLEBITuwnJ7qjxJUJikryQmCQnJLa2gkdMSOwgIiRW9RMSq7oIidXS QmJ1LyGxRk5IrJEWEmvkEvaXS8zbC4l1vYTEuj5CYr2ckNjKCp72QmKDsJDY8TIeESGpxGkt JLVvRUZIqpGaCkk1QgshqQ0sICSVMBJCUg3T6oYbvJiQVMduICTVcRsIyXjc9kJiH/dVnRYS PcwTEtt6p9aHEc9BSHYXulJIdmMgJAgJQnIBQrL7NPcRkl2oJUJSeXw1F5JaytBMSGpjywlJ 7dCZBkLS7yybWiwRIQleWkhCNyHpm/K2FpKOVy8gJL12aq1HkhCSyi4ezYSktkOIgJB4hAQh QUgQEoREK4QEIUFIEBKEBCFBSBAShAQhQUgQEoQEIUFIEJKrFxKNkCAkCAlCgpAgJAgJQoKQ ICQICUKCkCAkCAlCcvVCYhAShAQhQUgQEoQEIUFIEBKEBCFBSBAShAQhQUiuXkgsQoKQICQI CUKCkCAkCAlCgpAgJAgJQoKQICQIydULiUNIEBKEBCFBSBAShAQhQUgQEoQEIUFIEBKEBCG5 eiHxCAlCgpAgJAgJQoKQICQICUKCkCAkCAlCgpAgJFcvJAEhQUgQEoQEIUFIEBKEBCFBSBAS hAQhQUgQEoTk6oUkIiQICUKCkCAkCAlCgpAgJAgJQoKQICQICUKCkFy9kCSEBCFBSBAShAQh QUgQEoQEIUFIEBKEBCFBSBCSqxeSDUKCkCAkCAlCgpAgJAgJQoKQICQICUKCkCAkCMnVC8lN TUjixIgmWT0sEpJ9I8ZTEpI9F2r0kUKybwyLkCAkCMkZCcn0p9mZ0FZI9oSywz4h2feFrpGQ 7IuRVgrJnrGdaS4k+6KF5UKyZ1g/NBaSfbFcOyHZFyY1EZI9EYJpKiT7IoWVKe+esaNqIiT7 Ili5q0+6iZDsixCbCsl0JD+YhkKyL05aKSR7xlammZDsi9JESPYE0KqhkOyL00hI9oQwQ1Mh 2Rdp9Dm3g7ePhej21+1tTvXzK/Xuy//MNeP7cis0cfcOVjczgsSXQUxUtw9vsC/br/m7uNtF KaPflMHN8WNbPRr75s6GZzeqz/ld9SEXFv+ZH+HfP++ef7uPSJrxM7dtIGlPBDesgaR9A9t2 kLQvTFypMHvG9pWf8bB5eBjdv//4/uvfHt6kX//zfS4sc4RYMo/NjA/cOL+Z4Tz7xk0rnGfP uKM0Zqnz7Itx0Hlu5zmPD7Gx8/ioz8N5fMmnVjqPj3TC4Dw4z2U4Tyg3wz7OE+JC5wnRiDtP iEHMeUIaOjpPSFbCeUIK3Zwn3yt6OE8cnLDzxCF2cp6otJiUROWEnSeqJHf12gk7T3xRJ8s5 TzS+i/NEO4g5T7S2g/NEG2WdJzrdxXlyrSPtPNH3cp7oOzhP9EHMeWIYOjhPDFbYeWKIMs4T x3MCEs4ToxNznlwQCztPTFrEeWJyIs4TUxJ3nlRyvv3OczfPeVKZFGnqPGnw5+E8qczTrHSe pBTOg/PgPBfgPDYPpvs4TwlllzhP+cIo7Dw5hlJCzlPGdt2cp0SL7Z0nDzuevxZynhKrQz9P CSPbz5MjmD79PCWSVD9PHntc9Td1nhLBCl59EnWeHMH5Ls4zEam584zjtHOe+titnWciSjvn qQYQcJ5qnLbOU/9WJJynGqm181SDNHKe+titnWfiB9LQeSYirHee+sDNnacappHzTPyMGzrP xNWvdp6JcVc7T23c1s7zGGO/82znOM/vI7ZynscRT995Hi90lfM8joHz4Dw4zyU4j/PdnMf5 hc7jvLzzOC/nPM73dB7nRZzH+X7O43wX53Fe2nmc7+U8zstJifPSztPx6nEenAfnwXlwHpwH 5zkn57nHeXAenAfnwXlwHpwH58F5cB6cB+fBeXAenAfnwXkuwXnMgPPgPDgPzoPz4Dw4D86D 8+A8OA/Og/PgPDgPzoPzXITzKJwH58F5cB6cB+fBeXAenAfnwXlwHpwH58F5cB6c5yKcR+M8 OA/Og/PgPDgPzoPz4Dw4D86D8+A8OA/Og/PgPBfhPAbn2X+huAKucBKukIvzcuJbD1d4DDXf FR6/UNQVqjEaucLE2EKuUI223hUmhhVxhWqs9q4wEaahK9RfNAlXqL/H2lTmE99FQ1foe/Wt XWEigoArTERq7grVn0cjV6iP3doVJqK0c4VqAAFXqMZp6wr1b0XCFepP8sauUA3SyBXqY7d2 hYkfSENXmIiw3hXqAzd3hWqYRq4w8TNu6AoTV7/aFSbGXe0KtXFbu8JjjL2uEMMcV/h9xFau 8Dji6fePPF7oqv6RxzHoH6F/BOfBeXAenAfnwXlwHpwH58F5cB6cB+fBeUScJ+I8OA/Og/Pg PDgPzoPz4Dw4D86D8+A8OA/Og/PgPBfhPAnnwXlwHpwH58F5cB6cB+fBeXAenAfnwXlwHpwH 57kI59ngPDgPzoPz4Dw4D86D8+A8OA/Og/PgPDgPzoPz4DwX4Tw3OA/Og/PgPDgPzoPz4Dw4 D86D8+A8OA/Og/PgPDjPRTjPLc6D8+A8OA/Og/PgPDgPzoPz4Dw4D86D8+A8OA/OcxHOc4fz 4Dw4D86D8+A8OA/Og/PgPDgPzoPz4Dw4D86D81yE82xxHpwH58F5cB6cB+fBeXAenAfnwXlw HpwH58F5cJ6LcJ57nAfnwXlwHpwH58F5cB6cB+fBeXAenAfnwXlwHpznEpwnDTgPzoPz4Dw4 D86D8+A8OA/Og/PgPDgPzoPz4Dw4z0U4j8J5cB6cB+fBeXAenAfnwXlwHpwH58F5cB6cB+fB eS7CeTTOg/PgPDgPzoPz4Dw4D86D8+A8OA/Og/PgPDgPznMRzmNwHpwH58F5cB6cB+fBeXAe nAfnwXlwHpwH58F5cJ6LcB6L8+A8OA/Og/PgPDgPzoPz4Dw4D86D8+A8OA/Og/NchPM4nAfn wXlwHpwH58F5cB6cB+fBeXAenAfnwXlwHpznIpzH4zw4D86D8+A8OA/Og/PgPDgPzoPz4Dw4 D86D8+A8F+E8AefBeXAenAfnwXlwHpwH58F5cB6cB+fBeXAenAfnuQjniTgPzoPz4Dw4D86D 8+A8OA/Og/PgPDgPzoPz4Dw4z0U4T8J5cB6cB+fBeXAenAfnwXlwHpwH58F5cB6cB+fBeS7C eTY4D86D8+A8OA/Og/PgPDgPzoPz4Dw4D86D8+A8OM9FOM8NzoPz4Dw4D86D8+A8OA/Og/Pg PDgPzoPz4Dw4D85zEc5zi/PgPDgPzoPz4Dw4D86D8+A8OA/Og/PgPDgPzoPzXITz3OE8OA/O g/PgPDgPzoPz4Dw4D86D8+A8OA/Og/PgPBfhPFucB+fBeXAenAfnwXlwHpwH58F5cB6cB+fB eXAenOcinOce58F5cB6cB+fBeXAenAfnwXlwHpwH58F5cB6cB+e5BOfZDDgPzoPz4Dw4D86D 8+A8OA/Og/PgPDgPzoPz4Dw4z0U4j8J5cB6cB+fBeXAenAfnwXlwHpwH58F5cB6cB+fBeS7C eTTOg/PgPDgPzoPz4Dw4D86D8+A8OA/Og/PgPDgPznMRzmNwHpwH58F5cB6cB+fBeXAenAfn wXlwHpwH58F5cJ6LcB6L8+A8OA/Og/PgPDgPzoPz4Dw4D86D8+A8OA/Og/NchPM4nAfnwXlw HpwH58F5cB6cB+fBeXAenAfnwXlwHpznIpzH4zw4D86D8+A8OA/Og/PgPDgPzoPz4Dw4D86D 8+A8F+E8AefBeXAenAfnwXlwHpwH58F5cB6cB+fBeXAenAfnuQjniTgPzoPz4Dw4D86D8+A8 OA/Og/PgPDgPzoPz4Dw4z0U4T8J5cB6cB+fBeXAenAfnwXlwHpwH58F5cB6cB+fBeS7CeTY4 D86D8+A8OA/Og/PgPDgPzoPz4Dw4D86D8+A8OM9FOM/NMc7j7I+U/f5TYZWH6n93fUUEysta flrHXJj7Q36+DsE1zk3e2hXv0iVvjvJ9HP/9puGn7/et/dPzP9S//5SS3edos/xrJW7tru14 x9r9dTXsFak9xLQEj+ZQ0X4eOuA/+1XnOLx5YTU1LHnhImdKIA9vhGQ6EMhjKDebQB6/UJRA djH0oCUI5HFs34dAHqO1JpCHYZXpQSCPsYIwgTyE0UqOQB4jWHkCeYwUJRDhYWyj5AjkMYKT u3qr5AjkMYKXJ5CHSE5JE8hjHC9BIA9j+0GWQB6jGDECeQwQpAnkIU7QlY/G7f2PB1Mu6r/l VODd/a/v7t5/KYjwZZtjl2DlzTwj0OgzuL0dbh+egH//kKucv26/Pb1artyf7md8CMMYcm5j eLgR3j9WJw8v2u4jnna2cvQjNjyO862kq7+WKa5tuY3GW7XLAtSbP+c/m/H2j/lnu71Tjx+s 3Tf/AEBPVxjMjO//y+bufU50d++28rP5HS3CjPdb2j1KnmvUryWH3ZW0m5k/jfTsYfFgaXd3 5RPxfPAv33epzgO77P6g1F4/Pi6FRpQ99BN6e8zPZb+zKb17rq+wmd33bFTYKzDHlc57nknL y1rxqtaYF5++n8paUx6Qz/DB2v0dIvN6O1YXtzMrW1MekaVDY099+3rl7d7qdkVxu6+0fdl8 cOEVrbW6V0Vry0dlSUVrbRSvaK2Tq2itcx0rWutEKlrr9aGH3y/rnn45VpO8pMsD0vkDMxRH 2vJ5PiJdDHseka6w8HOff5TgqWfk7PbHVyBgl9KaB+Wt7JNSjoF5VP54C/ikej0qfXHmJY9K n7z4ozIMg9ijMgy246MyDEHiURnU0A1/g7I98DeoKIy/QetO+Bu0F+PToJMw/gZj5K7eRGH8 DdZ2wt9gUxf8Dc6K4W9woQP+Bq9k8Td41wV/g0998DcEI4e/IfhVzNtYd0O0J2a7oZQTb5rQ bkg/vzPlK9yhwQ+nS4EblWsgwEIFrnxrUzR+T4Ubzc8daI8m3KjAfYXyNtpdedurum0KwYfq 283iAvfLlVW4yQ69KtxU3HlJhZusfIWb7JErvFalRiuznnWpzKpkZV920jb98EMpd9olIEOL DMQPuyaZFhlIHurn8uFQAjKszUAa/HTe2qMykNuVKYgfvL1iZPdD9JPd1fkP4wtjH5p1WDfJ QPyQ5uUg5QtWEPtJd1o3TEE+HZGD3J1xEuJVTJ2SEK+K6C9IQrxKTjoJyTGiFLP7av+2FLPn aE6A2fOwsReze610B2bPYbwss3uthz7M7ivd3K2gOo8dZJndazPIXb3xsszutdV9mD1HCj2Y 3etxf04rZs9jO3lmz1GSKLP7ShO3BLP7Si+3CLN7HZQYs+fB7ckgu9fxtIzd693KziYVrk7m 7CrcY+rbtdWtUaZJdXuexa0xL7ODn8pbY8JP5a1JLbusm9S3M6tbU9yyWwNZV2B/3Qayn3Ol fdnNulzkrd2TdKzKEd6uefSvf6ivelivehq/XfEEbvr8tdGc2AM4X1GrB/DDUD9utdJT3P2A ee0TePfCSE9y/9b9Ibz0jfHzHPfDnz57BD/+Zxtg3r7CE3j3DZ3sWqfXAuZjnsFfL2eO++Fd 0IeXd6GW8PLogynAy5UYzXi5OrYYL1eiteDl6rBCvFyJJcHL1TBNebn2osnwcu091gpoq99F U17uefXtebkaQYSXq5EEeLny82jGy7Wx2/NyNUpLXq4EEOHl+kdDgJcrgdrx8vPBT8eZy1Wd WjPV7pWSKHTp5n7+0lxxM3fTQvcMqPmx0D3DPT1elLmvhLm/rXokn21P8KtRbvuH3Cli7us8 4obzecbdNvDc033KdX/I7X3GbVpqbotHnD3pZ9zprFdau1zpkjqFoVwoF8qFcqFcKPdVKHei TlxYAb7dV/xNV3YTZVu1HmtXaTWosN7a9cVVy6JqspbaW0IdekH3lT6LC55qmXOwvKnclCbq mbnFyvwPUL06qVclR1Yja8qQedVHreqoVRtHlhlHFhcTRcVENTFVRBxdP7wsHp5VDlddNPwY 6veC4Md7+YTy/XKDboJXbd1K4h67V5eWo1Ldkg7dZcVusrL32L8dSz797rK+8W32zbFzFfUb 7cz77LupO+3zm+yLeyy32N0tdt8dFlKBVCCVayGV6sXWyaOGFdOkUFGBxsW8XVbND69TzrsT qeeHE8g27auU9MNAUX+C+eZ9JeE8Nt9cV9hPzRJOJZwL8k1q+rkTgc8mAU+x6CcjJSMlIxWf 5Ktd8bKJuLVJ69+nWhVfcw7qqOejyMOx5bPxCw/HxQ9Hno08G3k2Xt2z8ZSeiz05x83uznD1 dvnTAp0W04en7zk9Zw9fbfKwFeacSYOGt0fOHbamnBvS1XNOV3+8/0lXSVdJV6+hX3tGzlrJ ShvMMPadYJwzvZiYXxTJR+lna5iSzmxnmxf02ePnx8OHZw/PnnnPnrdLe1r+IjY/0LmrZXJr gdpz5wKfOifAIKeDIP+ypKfla/2hI/7MucCWllNbqTK7o2XzzEH2dLTcwiD77mv0tAAhJKNA yNvz6Gg55Ym7k1pWfTZI8mVdF/b9/k2l1mwmtWTu7vicdTjHpHXVHk+vurr6NLqwN0e2YZO0 0mpWSVlbQMaJPRiuAc8rknEOz4RTXAxuT4kyBNbmLF2aw24bIAVIAVJcb7fGL0LtGic+d3b6 G7xdR//w/vXg9Guc6yZv/hwcgsXgJ9pATE5KTkpOSgfxyrmzJoveBNaCP6Srp8UvM3c8ZbPT Y56FPOx42PGwu8KH3eKV3fM6QP58djvx0bO87MAyoTaQU9qM77Jn+157J774alvxbU+rCwR/ YUqQjJSM9Pr45XBS+ssVdC2f2llQpKycVtJgtnDOjkMlZ236ROKBdGIPpLlH7n7be+bugSN3 9524u/2y98ys2zd3Xz68+/uHI87e3b44fPd8Zdl4E4Y+WX4JpZecvVu+0AuXAjlGHIRKgTJ2 v1KgRAvtS4E8bBo6lQIllpW/85YwUfTOa7wdVJc7b4nkhEqBMnYSnYnNEZSWu3oVRc/ezRG0 7XL2bo5khg5n75Y4Tujs3Ty2Hd1Ibu3N9u5PjwnrxEbo5fOg5kSx4yj3dw/PjFqI4wq65wFG H4qb25vwdFPfVU3T61WPfzBZZysfjdv7Hw+mL9s9cx+/2RmBRt/Q9nZy8sTNqcXy4N6MB4+h vl1ZeUPdtpyK2V1BMH9pUN8+DtigyM2XFMtdr0GtW4b6OUWaLnm/PyQwBxZnHQzc4Gfz1u5f +au0fSrDly4ALi+NU/l+U6+q8zib8nk8uPwrV8v5r232PJEmqu3ftgcfgnML8qdv7PgXwLxM n58V6PmPy/14V5BvS4/NF6urhfo2Vxt/yf957JKyu1++fvr+5XbVeuPHK5w16ZS/IZffM//x qT73tPvFba3h6eO7m1//nn/aR59Cep+rjY8f59a3e8vbTyvq2+NPhJ6oar9eUFnrQ+xV1vqo lpW1PjrxstbHJFbW+nGVJljW+nGx1qKsDYPuVtaGIRxZ1rZICeKLivAsUoKjMoLbuDYniHpv QnDZ+UB0P78xfsoGoos/ZQMbr/alAzOzge0rpAOxCGe/dKBrPrBZnBDcLnDuu3POCFIKnTKC kC98UUaQv9BKZwQ5RpTKCMKgOkJ3jiYB3TkhUL0yghzLd4DuMBglC905gusD3WEY82ErKs5j W1nozhGC3NU7IwvdOULsA91h8LYHdOc4UQq6c7av5aE7R/Gi0B2G8cyoBHTnOH2gOweKYtAd htTPtHOw1NC0B9NCtYMa8huyRQUblHrxzjuHEvaYCnZl+RqUkS5ff1tcvy4sX4//3vdUr/kP X1avw4lVr0H5MK+AzV+Rlhew88rXmcWrWO06y7I/VUrXC6pcgza2V+W6C7Wkct19oWDlOpHF rEw91uQTq/KFt/uShANf2ziHyD+505oWf3wvNckgXr4tDyYQw9XMi+fXpkUScZYEPr5d/ZRF 7P70WRbx+J+NZsSbZBEzU4jdd/Qfn+4W5RCiKcQB//6rHIBfZb83ycR0jGYMXh1bjMEr0Vow eHVYIQavxJJg8GqYpgxee9FkGLz2HmsFydXvoimD97z69gxejSDC4NVIAgxe+Xk0Y/Da2O0Z vBqlJYNXAogweP2jIcDglUDtGPxxcMrcVylz5aHcnYmU51fmdKn8z9JWPq/M3Zxenbu0zD3V Zq+9i5tfs/f7yAp3eea0Ly9al8W8tfvSlVXpxdt1WcMr6vSf4wX59F9O8sn95zMVajcM3ZC6 weP7L9fbqT16c6x4fPdfthW0wNO72cO77bYkHfu0P114ozZCjVAj1Ag1Qo1QI9QItbBQ58E7 NmyfajH7OqXsOVWy6xcdH2q4arALyaWUsvsh+jX6rbTp2XF1s3mVVcdd87Xxby8N89aeIkuf Jkq/Jkm/mkif7kTycPYN01ey4kp+Hrn3gisTVty9O7ZLv2a39NJp5FdtmV5D0dvVC6/olUai kWgkGolGopFoJBqJPn5wkaar0yxW//xKfc/ns76X1qmzXeF7bgt8J7l5+tm26kl0lYDJLOOb s51mPBukPFWjPLX7/aGlLudzx1/YK/v3193W+K+91rpAlBAlRAlRQpQQJUQJUUKUc4iyb81K yUrJ+nPJemzFeiCciGDG0yppT08wtQBhfm7YMtt1AajI5g2w4Yp7MAek9luXMLBFzmVsBTv3 Lnsmanj7hl1gYUPYEDaEDWFD2BA2hA3bdDYiiOcqiC1+NsctrD+DPV7PqfHlOhbndVpX/+U8 jvM+pnz9egX160k2u1/xFNKxe6ucyiOAiaSreEK03AL8VJ4Ps3YRPWYP0Q8AJ8AJcAKcACfA CXACnADn4cFPaJeyv1AMX+my7zeXd+TV9Rzt3J5D9zRNvmqx+1exavfNHesAj6132Y664clK nbru1WVvDhJPbNKs8WLxEz0Ysd1y8fMwUVo+EVFEFBFFRBFRRBQRRUTbiei5tn2e/haX59D3 eTHnKV1QDXv1W1zenuuZDHOKWGrYtTUsD4DhnJ4AdP43OR3+jBauX1lbJ7d/CBPChDAhTAgT woQwIcwehIlfCq1bjxdUv7Lv2qn0aZ5RA8514eXqBpyvlK+vWr6ePIdezoQYGHoq23iyxP0M Z8Ju39x9+fDu7x8WrHTnoYKJYqKYKCaKiWKimCgmOjW4yAnll7Tb5/Uubz+Njd5+e9XV7edU 5bLT55oi99tnseOAtu2PqrjkCnfi5zDxA5h84X9+0R9uDBN5ZS0l3JO4VZKvqRxpYVLzdk+q sie3mEoNag/5dk/vBk/tt7bBA7vtk3rqCb33wXzoJd33SF3xIK09QA8+NsfPy4mn5Nxn4PzX uvrQm3jWHfuUW/N4m/dYqz3OKo+xIx9fRz626jfJmffIycfSsyfSy4fRswfRVSvrj6F+F9TR uxghRUgR0isS0sp1N0k5j884lyacdlHGOZFwVlHppBLOFj7UMt8USTf3Ak7jdPPuUL5Z+VzX 803xdHNOtrk9Mt3sl22G10g3yTZPfE7/bSUdvf3xPicdJR0lHX2ddHT+c7HNYzG2eS7+eR3D nJrCHD2HcBIO83xigCdjuycjD0YejDwYr9FpahcsNSnYek5wH9GE2UbjTh9pTnBWcJnT2NeB mnpfTTOomTsx2Ghe8Gwy0qDbUo2E1bxbk5K+IyclJyUnJSclJ22ck85ISYfJnLS6RqDfrGFw 83PSM+hUW5+S9ulT+3Jw5vBdg6frsQ/XH3nc2mcrbTc8Onl08uh8O09zKk/OU+22CSf32HR0 eL9yy82ijpuT7/C+Wsk5dmnSvJUwk5azb/nRlOc85oHPk8DHHPAp++ue+tFyTe5H7nedud/P 48+YxTsw9py08M+vDSoX2Id9Pmnh5Uzw/YvYDN+CpjOJtX+rVraLdGMf23Ym0nUmNsd3KzfJ t7sxv+oS7EU34jPutTibFTFfzmUF9l3DG/FvQiW6ddqZx6zq2Z24/LZ/qNFdOo9l2La+q8gr FekzG4CX3Yq/XES/hXV2iH12vLSuIgc5vnLCcJBj6EEIDsrYrhsclGipPRzkYY3pBAclVpSH gxzGGlE4KBFiFzjIkZwWgoMydhCdNMoR/POrX9kEPJzhzBFbA61NTK3Lz6k1TcBnlJnKAcHx L3YyLxelld8MP++Hd7tNaWpHvOO3w1u3E976LLW2590r7hb07sgt1Wrbte9bsfalDx3I56vB qF75ajDPF3RvnyWtwQTxpDVYJZa0Bms7Jq2hkig1SFrDOCsSS1pDqcjlk9bgB+GkNXjbKWkN Ps5NWh+etK1WznTXnDTY8WMzDY+PTTXUHpan1m5Re0ZWt4Vtu26m0UPyehdzWz+42KbDw9ac xg/eSz/y/BDEnCaP3dFpcjQJp/FD7NXgUWKlDo88PyRhp8kROjmNV4ORcpo8trDT+HzbeIog hzR//nZ8I0ff7fSG850/bIA0toXSeJWG5Rvq2VPaUu/wwQev3eBrvbZjpsm/+Th3aM957nBN ytlz86BDKHMNU4jeBN2JZKqZqQlRPDM1UYtlpib6jpmpSYNEZmpStxnEHKvHDKK3gxbOTG0t pxPJTK1SYpmpVV44M302fy+2h9CM/mKJg0WaLdi+vBbjJpmpTWlPh/GPt6/svTfoIHHvDaYG 4T9uvQ3vvJV5D4k7b2Xqo/GdN1jf6c4bnNydNzgnuOgjj/9jOkJy0ce/XHpLx6U1Gze5Icff 28C6d3QMJ9xsLKYFManRoo/yu4/LgR+7O16FC+Zoga+2Gi/vND6RZR/vvuzZiP9CoCAM6hWh YBdfXArCoMWkII8d+klBGGpp5epsNQ/re0lBGGqJZPN8NYfxsvlqGMZZpEy+miM5qXw1DOP2 lrZSkCO8mCBdtb/bzGmsxqnpGR0K5U5iEqtFXhrU07qBy89KXz8pDSr50RRW/s2Hqas/F4A9 h3Ohjm2aOsEJrHdXvNmwDcYNnTYbnshIjdvTSNx/N4TfWt+CFu2H8LXvITw2ODOeSM+/+TiR XqBicePmr3evvAj31CrjuTPp+25DF7KmIXj3unWx3+XlomWx906sLPY+dSyLfbASZbEPsVtZ 7KPpURb7GIXLYl/pOpApi32KYmVxGDcaNC6Lw/NGA6GS+DV3hTm1A3hOZE+YJgVxiG7tZuen ckzyv5xBRfw0L/ZTLhqtfmzqdGexaas9hwMh361JRacz0b2J6Gnnoak8Tl+tHLYxfzfS8zM5 hlgimsfumIjmd6NEIhork2RSiWj+/PVIRHMY4UQ01ubKRBLRHClIJaJxsMKJaPx9pmx8tfKb yJ7d2QLVLDV1aCfKN/8ft/7fb/p7joR5dkO/fXZHN4P47l45RhK7oxtlOt7RTaWTusEd3WjV 7Y5udI+NEqIxwhsl5Aiu0x3d2EHsjm6sFb6jG5ume0QvYl/wDsfFaM6Lqb+77FPH0/mvKD2L HWljTtFG/JB/0zzwQ/QXtqa06Yx8N31Y3B960vwQfbejf+v84MflT/Nk1Vsvlqz6ylITuWTV VxafNEhWvUvdklXvbY9ktTI/2ThZrc1JyiSrfryxTbNktTIt2ThZ/WlG8nXy1W/y82RvWx6f QLo6I10NPrxS8+gVTpXFqCu5atQPuap257GeqXHT1sqZssObzL77+4ev7/62/TW/O8t/vnmv b9/93KS1+/Dufn/z618/vbt5/+3N10/fP97tksTy27tffP764VP5jr7m996nkpvkQF8///3L mw+/fXhXctvHuLu/vLl98/EfXzYf3nz7/OHdt/dfy793v755/+nrm5y75pfon28+f/rP7Zfy wXmZHn+63X79+unLm5vv377ln8H2t2/2zYeb3UfoR/+Y8m/uPuyS369/ffP1y8Ov7nb/Ote+ sphM6tRXFlPJnX/fK/ePM75QfF/BHENOiJPrKcTJSewgEFNlYY5U0p36JN3JS8/5pdBrzi8F L5Z0pyi8JitHsHJX/2I3o82gnbfuIf96yssXpPTPI4RxBLe5+SnC870P82e63EKUuZkXKQ0v do/cRfKPyfEu0nRRMS/O6G44AvSvv27Kj3pb8m/l3PFjj3sSbu3N9u5Pj7nhRKFTPg9qTpTx d2Dv7x6eGbUQx9VNzwLo0bdxc3sTnm7quwxneief2xlxatX07f2PB9OX7Z49KH6zxwcaHw+7 vZ3cxMLNqnry4HE8eAybxyJxPIFd3lS36vjxX0xibQZ7d3d/37AIfYgy/i7W16bPxh8lCmoT 7h4/di128MwRRsnBjc/PzKlidGGVmwavx3G0nW4Q/f6UV825k/iX34zSdrvdHJjwOX78F09v oTfVuKv/Zmu9ebyRTC/Eyt/s7lMSjw811rObbXjM4RbSwOPA47dVGO4efhJ1PMjjb3Y/79tw fJhUOeRqOLwP62/lU7KZEUasfyqpYQTw9zfxzv1pahpvu5kxth+Pvb1/eHn+cT97cdyPcdUw Hvc+PuTJuUx9GteWh4K/mTHuy+kBY262Tj+N+213Q80fsftc5JbybpcZl/f8nBjx5ZFEb2LO /7y9D3dD9N4MN2/+kv/C8SOWVpn6kUa7gX78b8aI+XX4H//23//b//nf/v2Pbzbf3vzy5dOn 449H+vrpe3nX7+rxnGt83P6y+XL7t19+i74M8cuHD9//cPtHu+4QpacLzS/m/7H5cpeL7u2b j5sP2z++mTnrmlQ5nOc/Pt19L8SUv6/8fHnz/uMf39x++efnb3dvNjlfylf+ztvdL58I5eZb /fjQ3S9uP1sT8hs8v3Ll//PffFdSonzXfPN98/XNb9/efbv9/P3uc/nV57/98+tddevgdze/ /r3cLna//rj99uPXD7eT8sv7r2++v/+YK4Wju9Lv391++vjQm/7gbM9/55jTS7+8v8vfRn77 F5IyhaLe/FqHue3tu83Hza+f/vom//jto40VEHr36/avm9t//vi79bnm3QhvPmxuH+acv/0t /2g+b+7ebW4/v3/4S/95l3/EO8K7/fDm9n5yufi39x/yK/r4O/kb/Mf7/Jn7cv/3/LDcv70R fHhufJi078WHSYdlfJi/UJwPk45iJ3HlsTseS5K0yObPedhux5LkWD2OJUlmsLJ8mCN0OpYk 1ZqYW6W8prJapCkfJqO13NW/8JfmfJjMi93O5PjQWN2FD83YSZrxoRlPpgjwYWXTlbZ8aCpA IsGHxoc+fGjGUx3t+NCEIMqHL89ukJEeM1aSpnxoRjzSmg9N8l340I6VpD0f2tHCo7Z8+PJA BZk3VeVoBSk+tOPHbBs+tOMVQRJ8aI3qwYfWiG2PmawdxPjQWifCh3bcWtGED62z4nxoXTjE h7fz+ND6oTEf5g/7efChLbnISj60BRzgQ/gQPrwAPnShGx+6InRL+NBF8fXpOYZY92FyqWP3 YY4m0X2Y/NCt+zDH6tF9mMMIdx8mrzp1H+ZIYt2HyWvh7sMcwQhevTQf+m586DvxoRfkQ9+F D72LsnzovenCh97HPnzog5HjQy/Mhy9XJcpIjxfmQy/Ohz716T4MPfgwjLqt2vJh6MKHQYVe fBik+DD04cPQhw+DkculKqdmNuPDIMSHQYgPQwc+DIf58G4eH4bmfBjKYqtz4MPQgA9DGOBD +BA+vAg+TIVQ+vBhUgv5MCn57sM0JpJmfJh0z+7DpJMEHybTr/twt6Jeng+TNcJ8mGyv7sPa AvlWKW9tOXxbPkxervsweWk+zDlqJz5MsQ8fprGTNOPDNF6BJsCHKYl2H+Z/Dj26D0ucLt2H +Z9KrPuwDC7Jh/mfWr77sESR5MP8TyPLhyVCj+7D/M9xk1VrPixBJLsPyz9VjzeV69R9mP/p lQQfloGdPB/mf4ZBng9LGKnuw/zPKNV9WMa2AnxYxpXgw/zPUVtFaz4sMfwhPtzO4cMyYmrK h25Qw1l0H5YLXcuHZQy6D+FD+PAS+NDld0Cn7sMcSi9avFy+ULr7sMSQ6j7MY5t+3YclmkD3 YR7W9uo+LLGcPB+WMLIbjucIrk/3YYnkxVJe7WW7D0sEK3f1QXbvwxKhT/dhjhR77H1Y4kh1 H+axk3z3YYkSZfnQDKYLH1b2P5Dhw8r2B+340AjzodGmg/QYYT404nxoTOjCh8YqeT401ovy oXE9TLqyzYIUH9Y2XGjCh8b7HnxogurBhybI5VImKjE+NNGJ8KFJgwgfmmTF+dCkg3sf3s/j QzsMjfnQDvY8+NAOcTUfWkX3IXwIH14GHzobe/Ghc2oZHzonz4fOD2J86LzryIfOJwk+dMF2 40MXUg8+dNEI86GLsRMf1hbIt0p5a8vh2/KhH7TY1b9cot6eD71ynfjQa92FD70OYnzoje7A h94Idx9WDtEV4UNvO3UfeifYfejHsxtN+dD7HtLjx0rSlA/9iEda86EfN1aJ8KGPHboPfZTt PvSjQ7dE3lSpW/dhbUl5Ez4MQ5fuw6C6dB8GJdd9GFQS48OgZboPg44ifBiMfPfhbiH6Xj5U wzw+DKZ192GwZ9J9GMp8zUo+DAUc4EP4ED68AD6Mhc368GH0C7sPo/fifBiDHB/G0LP7MAaR 7sM4njYV48MYu3QfxijdfRjHqCfEh1HstEA3pEG6+zANct2HSUl3H77cXEGOD1MnPkxarvsw mR7dh0maD1MnPqzsfyDDh0mSDyv7HzTlw+R7dB8mL9t9mIJ092EKfRYvp9ih+zBF2e7DlHos Xk7d+FDVNlxowYflltSBD9WgenQf5jBifJgzJ7HFy3lske7DPK7I4mU1GPHuwxzj0N6HSs3i Q7Xbl6ElH+YRz4MP84WuXrycx2DxMnwIH14EHypVdrnqwodKlcncBXyYv1C8+zDHEFu8rHQF R8T4MEeT6D5Uery2TYoPc6zYgQ+VHu8k3pYPc4TQhw/zZ1esfy+P7WX5MBdCSu7qrXD3odIv tgAX40OlverBhzmOWPeh0uMVaO35UOmxkzTlQ6UrQCLAhzmO78KHSiclxod5cCfJh8oMHaQn RxHtPlRGCXcf5ghdug9znCTOhzmvsJJ8mMdPPd5U43N+pfjQVHakbMKHxtoefGjGu81I8KFx YpOZeWyx7kNlxqd5NeFD40W6D5UZzZa058PdQvT9fKjn8aEJsTEfmrKj9TnwoYmruw/zGHQf wofw4WXwoRt6dR/mUMu6D/MXincfKqfEug/z2D350I3trQUf5te7Gx863aP7MIcR7j5UznTq PsyRxLoPlRvjXmM+dFZuvt854e7DHKFT96FyvsvehzmOWPehcqFD92GOIrv3oarsfCDCh5X9 D2T4sLL9QTs+rOx/0JQP/dCh+zBHEe0+zM8X4e7DHKHL3ofKa/nuwxxEtPtQedPDpCvbLEjx YW3DhSZ86G2X7kPvunQferl9pJX3YnsfqsreCk340AeRvQ/VeCeF9nzow6G9D5WZx4e+zBs2 5cPdJgznwIc+rt77UO12hIAP4UP48AL4MOpeR6eoaJbtfZi/UJ4PY6X/qRUfRttx70MV3SDB h9F12/swx+qx96GK4wM7GvNh9J32PlS1BfKtUt4YojAfxijXO/lyiXp7Poyp096HKg1dFi/n OHJ8mFSHvQ9zFNnFyyrpLouXc5w+ex+qZOQWL6vKWvKmfJhsDz5MVpYPx+vHW/NhZRG5CB8m 34EPk5flwxR68GEK3fgwRSE+HC8jF+HDlLrwYWU5eatsRA+DGB/msUUWL+dxRRYv60GJL17O MQ4uXraz+FDvlp+35MM84nkcnZIvdPXiZT0Y+BA+hA8vgg/14EwnPnwItYAPH75Qlg9rMVrx YX1sKT6sRWvAh/VhZfiwFkuAD+thWvJh9UUT4cPqe6xZylv7LlryYderb86H9QgSfFiP1J4P az+PVnxYHbs5H9ajNOTDWgAJPpz4aLTnw1qgZnxYH7wdH1Y+GALSU/0uGvJhZfzGfFh91wrw YT1OYz6svVwt+fD13lRCfFgP1YAPqwO358P6vbA5H/bOpdrxoTMyfFgbtwUfOiPPhyXGfj50 M/nwccSGfOjMmfBhudC1fFjGgA/hQ/gQPoQP4UP4ED6ED+FD+BA+hA/hQ/gQPoQP4cNz4UMP H8KH8CF8CB/Ch/AhfAgfwofwIXwIH8KH8CF8CB/Ch/AhfFjnwwAfwofwIXwIH8KH8CF8CB/C h/AhfAgfwofwIXwIH8KH8CF8WOfDCB/Ch/AhfAgfwofwIXwIH8KH8CF8CB/Ch/AhfAgfwofw IXxY58MEH8KH8CF8CB/Ch/AhfAgfwofwIXwIH8KH8CF8CB/Ch/AhfFjnww18CB/Ch/AhfAgf wofwIXwIH8KH8CF8CB/Ch/AhfAgfwofwYZ0Pb+BD+BA+hA/hQ/gQPoQP4UP4ED6ED+FD+BA+ hA/hQ/gQPoQP63x4Cx/Ch/AhfAgfwofwIXwIH8KH8CF8CB/Ch/AhfAgfwofwIXxY58M7+BA+ hA/hQ/gQPoQP4UP4ED6ED+FD+BA+hA/hQ/gQPoQP4cM6H27hQ/gQPoQP4UP4ED6ED+FD+BA+ hA/hQ/gQPoQP4UP4ED6ED+t8eA8fwofwIXwIH8KH8CF8CB/Ch/AhfAgfwofwIXwIH8KH8CF8 WOVDPcCH8CF8CB/Ch/AhfAgfwofwIXwIH8KH8CF8CB/Ch/AhfAgf1vlQwYfwIXwIH8KH8CF8 CB/Ch/AhfAgfwofwIXwIH8KH8CF8CB/W+VDDh/AhfAgfwofwIXwIH8KH8CF8CB/Ch/AhfAgf wofwIXwIH9b50MCH8CF8CB/Ch/AhfAgfwofwIXwIH8KH8CF8CB/Ch/AhfAgf1vnQwofwIXwI H8KH8CF8CB/Ch/AhfAgfwofwIXwIH8KH8CF8CB/W+dDBh/AhfAgfwofwIXwIH8KH8CF8CB/C h/AhfAgfwofwIXwIH9b50MOH8CF8CB/Ch/AhfAgfwofwIXwIH8KH8CF8CB/Ch/AhfAgf1vkw wIfwIXwIH8KH8CF8CB/Ch/AhfAgfwofwIXwIH8KH8CF8CB/W+TDCh/AhfAgfwofwIXwIH8KH 8CF8CB/Ch/AhfAgfwofwIXwIH9b5MMGH8CF8CB/Ch/AhfAgfwofwIXwIH8KH8CF8CB/Ch/Ah fAgf1vlwAx/Ch/AhfAgfwofwIXwIH8KH8CF8CB/Ch/AhfAgfwofwIXxY58ObY/gQ4jhP4jAq 3/HtM+KwP4jj69/aEsdTqNnE8fSFksRRj9GGOKbGliGOerTVxDE1rARx1GM1J46pMO2IY+JF EyCOifdYk8fy1HfRjjg6X31j4piK0J44piK1Jo76z6MNcUyM3Zg4pqI0I456gPbEMfnRaE0c 9UAmmvuHu+HH7fauRMqfxV11tZlRAtXH3rrN4532+Ut1+/3Ll/w5zyE25Q54s+b5pG+UsQ8P 8G+3n/Pd9ePdh69/LZ+JUD4Uway6fru5e5SBx2t+l2uIMjlYXp5yG9FrXnrtbzfx8Qb7qeBP ToD/88v73ZP7roy+vVtz8fc3YXvzU1X1NPissqo6eH52mW16fDbk1+b9t38+VLe5HPjw/uvX 97v8TJX8bN1PIJdvyv0o3358A6WcXZdr5Prt0TFK/fY08KwCrjpw4wLuKcbeAi66Gf0fz0Zs 1P/xNOLJ9388Xeia/o+nMej/oP+D/g9wBBwBR8ARcAQcAUfAEXAEHAFHwJFTwhEPjoAj4Ag4 Ao6AI+AIOAKOgCPgCDgCjoAj4Ag4cs04EsARcAQcAUfAEXAEHAFHwBFwBBwBR8ARcAQcAUeu GUciOAKOgCPgCDgCjoAj4Ag4Ao6AI+AIOAKOgCPgyDXjSAJHwBFwBBwBR8ARcAQcAUfAEXAE HAFHwBFwBBy5ZhzZgCPgCDgCjoAj4Ag4Ao6AI+AIOAKOgCPgCDgCjlwzjtyAI+AIOAKOgCPg CDgCjoAj4Ag4Ao6AI+AIOAKOXDOO3IIj4Ag4Ao6AI+AIOAKOgCPgCDgCjoAj4Ag4Ao5cM47c gSPgCDgCjoAj4Ag4Ao6AI+AIOAKOgCPgCDgCjlwzjmzBEXAEHAFHwBFwBBwBR8ARcAQcAUfA EXAEHAFHrhlH7sERcAQcAUfAEXAEHAFHwBFwBBwBR8ARcAQcAUeuGEfSAI6AI+AIOAKOgCPg CDgCjoAj4Ag4Ao6AI+AIOHLNOKLAEXAEHAFHwBFwBBwBR8ARcAQcAUfAEXAEHAFHrhlHNDgC joAj4Ag4Ao6AI+AIOAKOgCPgCDgCjoAj4Mg144gBR8ARcAQcAUfAEXAEHAFHwBFwBBwBR8AR cAQcuWYcseAIOAKOgCPgCDgCjoAj4Ag4Ao6AI+AIOAKOgCPXjCMOHAFHwBFwBBwBR8ARcAQc AUfAEXAEHAFHwBFw5JpxxIMj4Ag4Ao6AI+AIOAKOgCPgCDgCjoAj4Ag4Ao5cM44EcAQcAUfA EXAEHAFHwBFwBBwBR8ARcAQcAUfAkWvGkQiOgCPgCDgCjoAj4Ag4Ao6AI+AIOAKOgCPgCDhy zTiSwBFwBBwBR8ARcAQcAUfAEXAEHAFHwBFwBBwBR64ZRzbgCDgCjoAj4Ag4Ao6AI+AIOAKO gCPgCDgCjoAj14wjN+AIOAKOgCPgCDgCjoAj4Ag4Ao6AI+AIOAKOgCPXjCO34Ag4Ao6AI+AI OAKOgCPgCDgCjoAj4Ag4Ao6AI9eMI3fgCDgCjoAj4Ag4Ao6AI+AIOAKOgCPgCDgCjoAj14wj W3AEHAFHwBFwBBwBR8ARcAQcAUfAEXAEHAFHwJFrxpF7cAQcAUfAEXAEHAFHwBFwBBwBR8AR cAQcAUfAkSvGkc0AjoAj4Ag4Ao6AI+AIOAKOgCPgCDgCjoAj4Ag4cs04osARcAQcAUfAEXAE HAFHwBFwBBwBR8ARcAQcAUeuGUc0OAKOgCPgCDgCjoAj4Ag4Ao6AI+AIOAKOgCPgyDXjiAFH wBFwBBwBR8ARcAQcAUfAEXAEHAFHwBFwBBy5Zhyx4Ag4Ao6AI+AIOAKOgCPgCDgCjoAj4Ag4 Ao6AI9eMIw4cAUfAEXAEHAFHwBFwBBwBR8ARcAQcAUfAEXDkmnHEgyPgCDgCjoAj4Ag4Ao6A I+AIOAKOgCPgCDgCjlwzjgRwBBwBR8ARcAQcAUfAEXAEHAFHwBFwBBwBR8CRa8aRCI6AI+AI OAKOgCPgCDgCjoAj4Ag4Ao6AI+AIOHLNOJLAEXAEHAFHwBFwBBwBR8ARcAQcAUfAEXAEHAFH rhlHNuAIOAKOgCPgCDgCjoAj4Ag4Ao4sxhHjkh+EcKSM7cRxJEcJgySOlACuA47kOHHogSMl kBPCkTx2GmRxpIRwUjhSBk9yOGJ8TgfEcKSMHqVwJA+uTAccKXGCBI7kgbWSwJEysBPGkRIj HsKRm2NwhHKecp5y/tzLeafsYJ6X8+ZHOX/7uW05/xRqdjn/9IWS5Xw9RptyfmpsmXK+Hm11 OT81rEQ5X4/VvJyfCtOunJ940QTK+Yn3WJOCeOq7aFfOd776xuX8VIT25fxUpNblfP3n0aac nxi7cTk/FaVZOV8P0L6cn/xotC7n64Galtz1EMZuH38oZQrzXY6SU5/3X/7nu+3HkkCX23q5 laz6sWzNnXv8seT31+7DuEvs8gu1udv8Lf8jh0m7Sup2VSRzczukx6zk79vvn999zu+wD7nI yC9Xrmr/cPvrp4/bP0S/e0eXu9i6t9vW3zw81T9sfsupw8efvyFd6lpzty5CeHzAf8m5/veb D+/LT13dzrCciYHDkB4GfsyRHwr+ghZfHq/elxfI3YY1YYK6H25qb67Hz0yLd5e5H5J+flcp P/p33z/vyGJ3l0+rEp/7m/j47n2Sl8dXaBa8TI29vbc/QORx3FSeGPd63bj38faHhzyOO4tD quM25pCnGPs4xA5zdhl5NmKjXpGnEU++V+TpQtf0ijyNAS6BS+ASuAQugUvgErgELoFL4BK4 BC6BS+ASuHQ5uJTAJXAJXAKXwCVwCVwCl8AlcAlcApfAJXAJXAKXwCVwaSkubcAlcAlcApfA JXAJXAKXwCVwCVwCl8AlcAlcApfAJXBpKS7dgEvgErgELoFL4BK4BC6BS+ASuAQugUvgErgE LoFL4NJSXLoFl8AlcAlcApfAJXAJXAKXwCVwCVwCl8AlcAlcApfApaW4dAcugUvgErgELoFL 4BK4BC6BS+ASuAQugUvgErgELoFLS3FpCy6BS+ASuAQugUvgErgELoFL4BK4BC6BS+ASuAQu gUtLcekeXAKXwCVwCVwCl8AlcAlcApfAJXAJXAKXwCVwCVwClxbikhrAJXAJXAKXwCVwCVwC l8AlcAlcApfAJXAJXAKXwCVwaSkuKXAJXAKXwCVwCVwCl8AlcAlcApfAJXAJXAKXwCVwCVxa iksaXAKXwCVwCVwCl8AlcAlcApfAJXAJXAKXwCVwCVwCl5bikgGXwCVwCVwCl8AlcAlcApfA JXAJXAKXwCVwCVwCl8ClpbhkwSVwCVwCl8AlcAlcApfAJXAJXAKXwCVwCVwCl8AlcGkpLjlw CVwCl8AlcAlcApfAJXAJXAKXwCVwCVwCl8AlcAlcWopLHlwCl8AlcAlcApfAJXAJXAKXwCVw CVwCl8AlcAlcApeW4lIAl8AlcAlcApfAJXAJXAKXwCVwCVwCl8AlcAlcApfApaW4FMElcAlc ApfAJXAJXAKXwCVwCVwCl8AlcAlcApfAJXBpKS4lcAlcApfAJXAJXAKXwCVwCVwCl8AlcAlc ApfAJXAJXFqKSxtwCVwCl8AlcAlcApfAJXAJXAKXwCVwCVwCl8AlcAlcWopLN+ASuAQugUvg ErgELoFL4BK4BC6BS+ASuAQugUvgEri0FJduwSVwCVwCl8AlcAlcApfAJXAJXAKXwCVwCVwC l8AlcGkpLt2BS+ASuAQugUvgErgELoFL4BK4BC6BS+ASuAQugUvg0lJc2oJL4BK4BC6BS+AS uAQugUvgErgELoFL4BK4BC6BS+DSUly6B5fAJXAJXAKXwCVwCVwCl8AlcAlcApfAJXAJXAKX wKWFuKQHcAlcApfAJXAJXAKXwCVwCVwCl8AlcAlcApfAJXAJXFqKSwpcApfAJXAJXAKXwCVw CVwCl8AlcAlcApfAJXAJXAKXluKSBpfAJXAJXAKXwCVwCVwCl8AlcAlcApfAJXAJXAKXwKWl uGTAJXAJXAKXwCVwCVwCl8AlcAlcApfAJXAJXAKXwCVwaSkuWXAJXAKXwCVwCVwCl8AlcAlc ApfAJXAJXAKXwCVwCVxaiksOXAKXwCVwCVwCl8AlcAlcApfAJXAJXAKXwCVwCVwCl5bikgeX wCVwCVwCl8AlcAlcApfAJXAJXAKXwCVwCVwCl8ClpbgUwCVwCVwCl8AlcAlcApfAJXAJXAKX wCVwCVwCl8AlcGkpLkVwCVwCl8AlcAlcApfAJXAJXAKXwCVwCVwCl8AlcAlcWopLCVwCl8Al cAlcApfAJXAJXAKXwCVwCVwCl8AlcAlcApeW4tIGXAKXwCVwCVwCl8AlcAlcApfAJXAJXAKX wCVwCVwCl5bi0s0MXPI2KJVa4lIZUcczwKVyoUavw6XdGOASuAQuXQAu5U+zdqkLLpVQXi/A pd0XJllcKjGCkcGl3dihFy6VaFE3x6XdsK4PLpVYSYnj0i6Ml8SlXYTUA5dyJDMI8cxu7CiJ SyWC0nJXr5UkLu0ihB64VCIZI49LJY4dZHBpN7Y4Lu2iREFcKgFcB1zaxYkdcKkE8kYUl3Yh gigulRBB98ClXSTfC5dKtDhI4tIuggQu7QaO4rhUwiQji0u7GEEOl/L4dtAyuLQb27fHpTKu Gtrj0m5cJ4tLuxjxEC7dzsMlW7KNprhktT0PXLIlDVqJS1YncAlcApcuApdcp86lXSi/DJfc uNRpjkvOWjFccuNCRxCXnBPBJef64ZJzqQcuuXE51RiX3LiaEsIlF5QYz7jghHHJhSh39dEK 45JLQydcci84VAqX/KDEcMkPPXDJD0kWl7wyXXDJq9AHl7xW0rjktZPGJa9TJ1zyxnTEJW+C MC55q2RwyVvbA5f8OMtqjkt+nFs1xSXvvBgu5eeECC75cRbVBJf8KHdqj0s+DIdw6W4eLvmC 201xyZfs6xxwyZckbiUu+WLo4BK4BC5dAC6FaHrhUii9L0twKUT5zqWQ5DqXQurZuRTHhWEL XIqD7YZLcdwqI4FLcdwv0xiXovKdcCnqQYxnorbCuBS1HC7FWrdPU1yKJnXCpWhdF1zKvxDD peh64FJ0wp1L0ffBpeg74VIM4rgUgzguxdALl2LsiUsxSuNSTIMMLsXUBZdikselNM6tmuJS GpwYLqUxtzfBpaRkcCkpeVxKj4vY9uDSdh4uJd0al5I+E1xKej0uJTqXwCVw6TJwKQ7dOpdy qGWdS3GQ71zKMcRwKY/dEZfiINK5lIft1rmUY/XoXIqDdOdSjtAJl+IQxHApjy2MSzlCkLv6 KIxLOULsg0txSLYHLuU4UQqXyptHHpfyoF4Ul/J4qQcuRaVsF1zKgaIwLkU1bo5qjEs5hOuD S1GNQVwOl+JuQxNJXMoRvAgu5YFTB1yKyoovi8sxvCQuReUGKVzKY1sJXMrjRglcijnbksal HOPgnkv3s3Apj+jb4lIeMZ0FLkUVVu+5lMdgzyVwCVy6DFzS+S93wiVd5mCX4JIO8rikg9iy uNh1z6Woo0TnUh62W+dSjtWjcynqJNy5lCO4TrhU2d2pGc+YwQjjkhlTQLurf9Gf1h6XjOq0 51I0usueS/HlLlItcckY1QGXjHGyuGRMH1wylVkPEVwy4ymQ1rhkxrVza1yqbYUlg0vGhY64 ZLwSxiXjnQwuGd9jz6VY2W2rOS6ZSutdS1wyIYnhkolGBJdM9CK4ZEaddO1xySR9AJfMMA+X TLKNcWm3z9c54JIdhtW4tNt0DFwCl8ClC8Alm3oti8uhli2Ly18YxXHJjefTm+GSq5TOcrjk xlPqLXDJKd0Nl5zyPXDJjZeSNcYlp00nXHJarvfHjTmgMS45Y+Wu3g7CuORqi9VEcMk51QWX KhusNcOlyoZqArhU2U+tLS5VtlMTwaX6ZmoCuFTZWa01LlW2VmuNSy522tA7R3IdccnFJIxL brwxQBtccuNzMyRwyQ+DOC758TRLU1zyQxDDJa+UCC55ZUVwycsvi4teH9pzyah5uORbL4uL /kyWxeULXb0sLnrDnkvgErh0GbgUSqd6H1wKpdJegktBe3FcCmYQw6VgTEdcCuOtP1vgUhiv TRTDpTDeAlQCl4KNwrgUnOqES2HMAc14JrgkjEvBa7mr91EYl0IwnXAphNQFl8J4lrsZLoXx 7jECuBTGO8i0xaWQupwWl+OkPrgUB+nT4nIIL41LUQ2dcCmqjnsu5WjCey7FqGU29I6VLfsk cKmyb19zXIpGdM+lPL7YnksxGpE9l2K0WgSXXu4vKIFL0R46Lc7oebi0262wKS5FZ84Dl2LZ jX4lLu22SgSXwCVw6QJwKZXbax9cSqXSXoJLadzq3hyXUuXE51a4lMYt7YK4lLyTwKU0bm4X w6UUdA9cSsEL41IKqRMupWjEeCbFIIxLKcntGJVqJ6y1xKU0DKoPLuVIoQcupUGJnRaXx3by uJSjyJ4WlwbdZUPvHKfPht5pMNIbeqdh3KDYGJdyiNgHl9IwLqrlcClHc7K4lCMkEVxKlU0g BXAph/HSuJQqm0G2xKU01E5ea4NLeewggUupsttjC1xK450em+NSjuEP4ZKZhUt5xNQWl9JQ ejHPAJfyhbq1uJTH8OASuAQuXQIuJVX2A+qCSzlUWoRLSY0L59a4lGMEKVxKqlI6i+FSjmYF cCkPG3rhUtLjQ1kEcCmHsbK4lCPEPriUtBLr/cljO1lcyhGS3NUHaVzSUXfCJV3bOlwAl0xl 0+1WuGRqW203xyWjZDuXcoAunUs5Tp/OpWS0dOdSDiHduZQqO3oJ4ZKpSJkcLpkamjXFJWO1 DC4Z22NZXKps6NUclyo7ejXFJVPbHLsRLhmvRXCpsldXE1wyPonj0m6frv24ZOfhkgmN91zK I57HnkvJxNV7LuUx2HMJXAKXLgOXbOp1WlwOtWxD7+TG1tAcl9z4ENhmuFTZBUkQl5wSwSWn unUuJad7dC6lyj5FjXGpuluRCC45I7YldnKVFZFtcclZK3f1TnjPpRyh04be6eVOQlK45LzY aXHJBdMBl1wIsrhU29xHApdc7NS55JJ455Ibn2/QGpcqO+8I4ZIfeuKSH4T3XEpeyey5lHxl RZ8ALnktvqF3jiF6WlzyRuy0uDy2E8ElX1tu1wCX/Ogkg/a45O3BziU3D5e8bd255M9kWVy+ 0NXL4vIYr7cs7oFUfkjK74zyA1HWE8oPPvmdTn6oCWhyLmiy2zWiD5qE0sq3BE0q+0I0R5PK 1hDN0CSkuAJNnkZ52Ouhgh8ThXeNGSYxYFzOT5Ste4rkZdXtokp1qgSt1Y3NCr7j6rr1NVmj aivuOlGmyqu9BdH+YuaYEmSqeqil/PUcfSKfria+y3LVSiI6L2l8a//0+8udyhnYcxK2VJLY UcL24w/jgdwrJavGydRElvT7uPZZS/Z0cvJT/vFibun5DNLFzxTtS3KYGjqTLCf/03fqOy6h FvUd538G6b7jEsMLZTn5n3FV3/Hvw3RNc/66rSc6Z5fntHPtY/KcBvLcJM1xgyruMYnIJ5Tm fKjmOVNsWMtzlqU5b21N3Gby2LNUJ7/kZUv741Od8gV+KtUpf7ifmQY96LmJjstf9JPgTKY6 +zKdN89SnSvoiTmhXKeMW/kefnwLMzM1EjWpRO3ALaBxHqcH1UmrSqhFx6qVL0zSeZyu7DXR Ko/LYy/Xqh9j5GK41qZTz+FmpXC/DJUkbmYOd+EZ3FlBVf5k7GafJVK4TZ8c7p18Erfaqn7K 4LQqG5DNyODyF9jJDC7/od+PVVqVLSFmpnD5i8yzFO44rLrqDA6sksmBulqV1mWarE+Os1vg uSTH0UmL5zg6iVlVHjs1sCptpqbkmiQ66/OcoWOi408101md5zRKc4z3553mnMGM3M9ZjtV6 XpZjdWVK7sef7Z+R09aM5uMOZTjWuKMynIdeoSZU9fp5zpw05yKdZ+VT2+Sn16Kn9sMXyj61 azFaPbXrY798av/0l4+eRqquybmUR/PUkxmEePHeerWHc+o7kbTw8fy27fP54TWf8Xx++IJx j/OLP51kiIe/MZMhHr7oiJmkfQ7BRNLjIxqEOI+OmYd3fReFIJ9ZpBCH8pwrJIhXEIheWY7r kuZ8ea08R2iu5SQYYvear89yjk1ymmQ5R7XL/JzjMNNCswk5DjlOyxznN36yF/iTXZi5/rY2 dZ3aiKVxm9Cfl+Sup0t05yB0+3f3WN/mnfza9WyTu0O05Dkr4XPrgW4Vz7XSOXDu9Lq8LyB3 JXUlwXmZ4PTJb4azsjnaoI98uy2bgvwm2CC0vag1+1eR4dAFTYJz3l3QJDizE5y/3fJjuKY8 8/mXn/D878LtEt7ay+pCb5Bonnqn24oJ4NUp5r+cvKN1mwF+pfnf//18OtBFd4UiwyTDJLVp Mvv78ygX18t/YROFyrU4jqBhkiPS5nbBm1/eqMXbX56GpLVr5f99c272h2LmUHbmcDLrIeeR zHlI8jomeV0yuaMTuW+sypRt+TqBGVGxLG79UgXhFZk3q7O4P69N43pmcYeTOPaHOjwzSvpG 4xcJzXq1Wrb7RK31a1bn1ykf1nK6Z7XQ+vU6rV+/tNzIfDVa9ZqYa0JWmyUzc1fmVO+ZnmuW 6DA3R5azy3Le/viqH19zJt/w1MDN+qfmZGqnvAaRvcpPnaTSVRyrJ5Cjnc60Imka5wfDUSRq B/OWt/bgpFmLFu8WJ+Jx8O/ZbGV6UhuZvtqsGQ3eUznKFe4xTnbCDl+kJyewi6nQmb8rG7x/ v8H8uL00Wz6y5ebCzYWbi8jNpd05EOvvLNe6O/IVHQLx7SR09+uM4qndupHX34GlY+X08ZjS 6WXl9P7I0on9V8huFmQ3JDdXVzktXFHx21ocPr8t5i6h0bDL7PUrTV5XF1Rszvfwh1dcFjtn f7nbllvontHU9ZWd/fAjW5HMUxAYkhThJKUB735jA4/r3qHsVY/JPuUdyk79bKnjAeUUeuMQ FBYwkJmc9TJNmeb/89yPQpJPzvD4TJEzwm9OsLful1fLTQR66zru0L9kfuiK9k5lHzHaX+RT nOU3jJ610LqzPKiDuFFwo6AWElfaX856LnnhSRK0y73edHL7pUYf1s8nX85q6Oj8yiznW5s0 59k+y7tfPj3Nbr7lh8+bn9Yivfv+7T7ufnH72Zrw5h/3+VLK/+e/+a78iPKb5M33Tc6Dvr37 dvv5+93n8qvPf/vn15Js5ByqJEflp5yf0bu36s2vf7/JidTu1x+33378evuPb7d/+1h+eZ8f ju8/fs6vx31JEV6K9OOQH/M1fLx/+tftp4/Parmffqf8x932Pl/ow59d+i48+SH8+0KHjzk/ +ZHE7TIqMrmVmdyBWwCJHone6EQNpcpDa7smmr7ztRQx/+N+3bCbx8fyu3cPq9CrKacyJefz 92lNrOq20jldzc/nd79u/uuf5Uduy3cU9bowt4/5z9QMwW8qDKtetBcL9+svmXclbbQ3q95j 1V2Lju+U2P9dmM3Dj356u8q4Ocmr3wzaeeseEuBdZbC7+pwzLDu9biKC29z8FGGiNGkQyQ/b 3yO9mPT5zZSk1W9WxmlWLU2MbW+OPK5mXZT7x+Jl9Yk39QA3tzfh6ab+vHxqULC9/GhMHpOz vf2WfyfHLsHKm3lNoL2Lp3KATblL3ax6huydYfv1YVIr30pW/ViOaiJK5eevbldFMpObsn78 9v7bP/9w+2suuf4Q/e4dXe5i695uz1qvf8upw8efvyGdykfmbl2E5+vUvt98eF9+6uq2XLpZ NXAY0sPA9Vq+vDTlBXK3YU2YoO6Hm9qb6/mU6cp3l7kfkn5+V5nvDXvHv7+Jj+/e0S66efDt Zt3Y23v7kO3cf30adwZzTI97Hx/uG7mIeRrXlpuFX5PRGHOzdfpp3G/bD7u0+d19LoFK8r/L m8oLvlparLf34W6I3tsYd6gye8RpnXn837wRR5jzS771/+vDX/7l1/cfv//2r/oP/l93tdkv d9ub95uPv9x8fz+1juBvv/wWfRnilw8fvv/h9o/W6oki53/5X+dd6LNtjz9s//gmxpj+7f/6 93ljYE/YE/bELCK4BC6BS+ASuAQugUvgErgELoFL4NLl4FICl8AlcAlcApfAJXAJXAKXwCVw CVwCl8AlcAlcApfApaW4tAGXwCVwCVwCl8AlcAlcApfAJXAJXAKXwCVwCVwCl8Clpbh0Ay6B S+ASuAQugUvgErgELoFL4BK4BC6BS+ASuAQugUtLcekWXAKXwCVwCVwCl8AlcAlcApfAJXAJ XAKXwCVwCVwCl5bi0h24BC6BS+ASuAQugUvgErgELoFL4BK4BC6BS+ASuAQuLcWlLbgELoFL 4BK4BC6BS+ASuAQugUvgErgELoFL4BK4BC4txaV7cAlcApfAJXAJXAKXwCVwCVwCl8AlcAlc ApfAJXAJXFqIS2kAl8AlcAlcApfAJXAJXAKXwCVwCVwCl8AlcAlcApfApaW4pMAlcAlcApfA JXAJXAKXwCVwCVwCl8AlcAlcApfAJXBpKS5pcAlcApfAJXAJXAKXwCVwCVwCl8AlcAlcApfA JXAJXFqKSwZcApfAJXAJXAKXwCVwCVwCl8AlcAlcApfAJXAJXAKXluKSBZfAJXAJXAKXwCVw CVwCl8AlcAlcApfAJXAJXAKXwKWluOTAJXAJXAKXwCVwCVwCl8AlcAlcApfAJXAJXAKXwCVw aSkueXAJXAKXwCVwCVwCl8AlcAlcApfAJXAJXAKXwCVwCVxaiksBXAKXwCVwCVwCl8AlcAlc ApfAJXAJXAKXwCVwCVwCl5biUgSXwCVwCVwCl8AlcAlcApfAJXAJXAKXwCVwCVwCl8ClpbiU wCVwCVwCl8AlcAlcApfAJXAJXAKXwCVwCVwCl8AlcGkpLm3AJXAJXAKXwCVwCVwCl8AlcAlc ApfAJXAJXAKXwCVwaSku3YBL4BK4BC6BS+ASuAQugUvgErgELoFL4BK4BC6BS+DSUly6BZfA JXAJXAKXwCVwCVwCl8AlcAlcApfAJXAJXAKXwKWluHQHLoFL4BK4BC6BS+ASuAQugUvgErgE LoFL4BK4BC6BS0txaQsugUvgErgELoFL4BK4BC6BS+ASuAQugUvgErgELoFLS3HpHlwCl8Al cAlcApfAJXAJXAKXwCVwCVwCl8AlcAlcApcW4tJmAJfAJXAJXAKXwCVwCVwCl8AlcAlcApfA JXAJXAKXwKWluKTAJXAJXAKXwCVwCVwCl8AlcAlcApfAJXAJXAKXwCVwaSkuaXAJXAKXwCVw CVwCl8AlcAlcApfAJXAJXAKXwCVwCVxaiksGXAKXwCVwCVwCl8AlcAlcApfAJXAJXAKXwCVw CVwCl5bikgWXwCVwCVwCl8AlcAlcApfAJXAJXAKXwCVwCVwCl8ClpbjkwCVwCVwCl8AlcAlc ApfAJXAJXAKXwCVwCVwCl8AlcGkpLnlwCVwCl8AlcAlcApfAJXAJXAKXwCVwCVwCl8AlcAlc WopLAVwCl8AlcAlcApfAJXAJXAKXwCVwCVwCl8AlcAlcApeW4lIEl8AlcAlcApfAJXAJXAKX wCVwCVwCl8AlcAlcApfApaW4lMAlcAlcApfAJXAJXAKXwCVwCVwCl8AlcAlcApfAJXBpKS5t wCVwCVwCl8AlcAlcApfAJXAJXAKXwCVwCVwCl8AlcGkpLt3UcCm9GHHvLSTVwyerrLVNPtQz Ixz/oZ43cBjuNvs/1JtQ/VDPCjPzAzFz7KM/EDPHPfoDMWfcpR+IAzH2fSDcYI/5QIxHnKut B0Y8HW09cKFHaeuBMdBWtBVtPRttPfBpbqmtB0JNa+usx9dCbZ0VY6a2zhx7pbbOina8ts4c dpW2zoq1XFtnhlmgrfNetDXaOivS7U1K9vElyzeYd/+VM4uHaF+/bXbvAVNSbOtWvZHnoejM l2oB6Z7G1S8l3ZkRVpDuzEiLSXfeW3Ye6c4beynpzowyn3Tn1bTLSXdWnGXSOrPuX8GgGAaG cUGG4TAMDAPDwDAwDAwDw8AwMAwMA8PAMDAMDAPDwDDOwDA8hoFhYBgYBoaBYWAYGAaGgWFg GBgGhoFhYBgYxhkYRsAwMAwMA8PAMDAMDAPDwDAwDAwDw8AwMAwMA8M4A8OIGAaGgWFgGBgG hoFhYBgYBoaBYWAYGAaGgWFgGGdgGAnDwDAwDAwDw8AwMAwMA8PAMDAMDAPDwDAwDAzjDAxj g2FgGBgGhoFhYBgYBoaBYWAYGAaGgWFgGBgGhnEGhnGDYWAYGAaGgWFgGBgGhoFhYBgYBoaB YWAYGAaGcQaGcYthYBgYBoaBYWAYGAaGgWFgGBgGhoFhYBgYBoZxBoZxh2FgGBgGhoFhYBgY BoaBYWAYGAaGgWFgGBgGhnEGhrHFMDAMDAPDwDAwDAwDw8AwMAwMA8PAMDAMDAPDOAPDuMcw MAwMA8PAMDAMDAPDwDAwDAwDw8AwMAwMA8M4fcNQA4aBYWAYGAaGgWFgGBgGhoFhYBgYBoaB YWAYGMYZGIbCMDAMDAPDwDAwDAwDw8AwMAwMA8PAMDAMDAPDOAPD0BgGhoFhYBgYBoaBYWAY GAaGgWFgGBgGhoFhYBhnYBgGw8AwMAwMA8PAMDAMDAPDwDAwDAwDw8AwMAwM4wwMw2IYGAaG gWFgGBgGhoFhYBgYBoaBYWAYGAaGgWGcgWE4DAPDwDAwDAwDw8AwMAwMA8PAMDAMDAPDwDAw jDMwDI9hYBgYBoaBYWAYGAaGgWFgGBgGhoFhYBgYBoZxBoYRMAwMA8PAMDAMDAPDwDAwDAwD w8AwMAwMA8PAMM7AMCKGgWFgGBgGhoFhYBgYBoaBYWAYGAaGgWFgGBjGGRhGwjAwDAwDw8Aw MAwMA8PAMDAMDAPDwDAwDAwDwzgDw9hgGBgGhoFhYBgYBoaBYWAYGAaGgWFgGBgGhoFhnIFh 3GAYGAaGgWFgGBgGhoFhYBgYBoaBYWAYGAaGgWGcgWHcYhgYBoaBYWAYGAaGgWFgGBgGhoFh YBgYBoaBYZyBYdxhGBgGhoFhYBgYBoaBYWAYGAaGgWFgGBgGhoFhnIFhbDEMDAPDwDAwDAwD w8AwMAwMA8PAMDAMDAPDwDDOwDDuMQwMA8PAMDAMDAPDwDAwDAwDw8AwMAwMA8PAME7fMPSA YWAYGAaGgWFgGBgGhoFhYBgYBoaBYWAYGAaGcQaGoTAMDAPDwDAwDAwDw8AwMAwMA8PAMDAM DAPDwDDOwDA0hoFhYBgYBoaBYWAYGAaGgWFgGBgGhoFhYBgYxhkYhsEwMAwMA8PAMDAMDAPD wDAwDAwDw8AwMAwMA8M4A8OwGAaGgWFgGBgGhoFhYBgYBoaBYWAYGAaGgWFgGGdgGA7DwDAw DAwDw8AwMAwMA8PAMDAMDAPDwDAwDAzjDAzDYxgYBoaBYWAYGAaGgWFgGBgGhoFhYBgYBoaB YZyBYQQMA8PAMDAMDAPDwDAwDAwDw8AwMAwMA8PAMDCMMzCMiGFgGBgGhoFhYBgYBoaBYWAY GAaGgWFgGBgGhnEGhpEwDAwDw8AwMAwMA8PAMDAMDAPDwDAwDAwDw8AwzsAwNhgGhoFhYBgY BoaBYWAYGAaGgWFgGBgGhoFhYBhnYBg3xxjGiZGC/0P+znxaRQq/jwEpQArXQArPROFM4aB8 Zncf2VVu8GOo31HA/unxNx9vCXI1/++3nfY1//TYEjX/VLSVNf/0sO1r/qlYjWv+6TCtav7J F615zT/5HmtQ0E5/Fy3K8ReDT11pvVyuFLrT1eiooKxVfQtLtLdThVdJMnIG8eu7u/dftrff claa/2b5o9uH28rfP+R88q/bb0/h/j85Pfn115JXPDzBdi9A2P3VnLeUVOTX8mzZlndIvFW7 G5x68+f8Z0feqrd36rF034V+qK+eQoVSV98fele8tV82d+9z/rF7ncp39HvVFI4pZp+Xdr+W 5/suUd8cE3v0jnwglc3dXfnJPR/3obzb/U4pBX78PEsJpva8nvuqzxX1XL1ac/bHw+X+U8nQ HxLJ3bOgvAnGn96JkmxmHTX7c//2x7P46TdL/ZKqM6dHliVrqo2ZBUWtMKgl+Mfm7Mem5vUs fCK9nkqWJ5Lhn7Ldl8nmZSSV67PKUVI5ehuTU552TklKSUr5U0r5/EurF7E+VXyRKdZnB/Lv TDvF85vznnvz7TVX/PsKfu7OVPzcni+y4v957Mp1Hn3//pc9M8/V2eP6LO/Ckn/fVOvcqt9J l/2nUPXnt1XLwv9t88q/vKQy1X+1+J9f+39rU/z/ef5LXSn/67X/346dk+xX/VdnBcfV/0nW /jTXXkhzbRvOmJl9zmyuJe0m7SbtvtSJtle5+qZ9r9MRWve9Tkdq2/c69fNo0fc6OXbTvtfp KI36XqcCtO573fPRuL3/8WD6sp0s7cqbeU2g7e0wVR26hQXS88Fj2DyWk6M6M+0aatWKD4a9 u7u/bzlLPfFdrK9i942vNuHu8WO3vtSdeNf6/MycqltXF8TP42g7WR9/+f6UV626kyhtt9vN 3mLbnsGb6mZrvTnYdZ6/2ePbzqdDrWwKnxy4bVP49L1wOIQWBSFyoM2p5lIt+tqnx17X1z49 7rq+9olxm/a1/9wXMtnXHm+OXpv/04hN1ub/PuKJr82nkZ5Gehrp4UP4ED6ED+FD+BA+hA/h Q/gQPoQP4UP4ED68Tj68hQ/hQ/gQPoQP4UP4ED6ED+FD+BA+hA/hQ/gQPoQP4UP4ED6s8+Ed fAgfwofwIXwIH8KH8CF8CB/Ch/AhfAgfwofwIXwIH8KH8GGdD7fwIXwIH8KH8CF8CB/Ch/Ah fAgfwofwIXwIH8KH8CF8CB/Ch3U+vIcP4UP4ED6ED+FD+BA+hA/hQ/gQPoQP4UP4ED6ED+FD +BA+rPJhGuBD+BA+hA/hQ/gQPoQP4UP4ED6ED+FD+BA+hA/hQ/gQPoQP63yo4EP4ED6ED+FD +BA+hA/hQ/gQPoQP4UP4ED6ED+FD+BA+hA/rfKjhQ/gQPoQP4UP4ED6ED+FD+BA+hA/hQ/gQ PoQP4UP4ED6ED+t8aOBD+BA+hA/hQ/gQPoQP4UP4ED6ED+FD+BA+hA/hQ/gQPoQP63xo4UP4 ED6ED+FD+BA+hA/hQ/gQPoQP4UP4ED6ED+FD+BA+hA/rfOjgQ/gQPoQP4UP4ED6ED+FD+BA+ hA/hQ/gQPoQP4UP4ED6ED+t86OFD+BA+hA/hQ/gQPoQP4UP4ED6ED+FD+BA+hA/hQ/gQPoQP 63wY4EP4ED6ED+FD+BA+hA/hQ/gQPoQP4UP4ED6ED+FD+BA+hA/rfBjhQ/gQPoQP4UP4ED6E D+FD+BA+hA/hQ/gQPoQP4UP4ED6ED+t8mOBD+BA+hA/hQ/gQPoQP4UP4ED6ED+FD+BA+hA/h Q/gQPoQP63y4gQ/hQ/gQPoQP4UP4ED6ED+FD+BA+hA/hQ/gQPoQP4UP4ED6s8+ENfAgfwofw IXwIH8KH8CF8CB/Ch/AhfAgfwofwIXwIH8KH8GGdD2/hQ/gQPoQP4UP4ED6ED+FD+BA+hA/h Q/gQPoQP4UP4ED6ED+t8eAcfwofwIXwIH8KH8CF8CB/Ch/AhfAgfwofwIXwIH8KH8CF8WOfD LXwIH8KH8CF8CB/Ch/AhfAgfwofwIXwIH8KH8CF8CB/Ch/BhnQ/v4UP4ED6ED+FD+BA+hA/h Q/gQPoQP4UP4ED6ED+FD+BA+hA+rfLgZ4EP4ED6ED+FD+BA+hA/hQ/gQPoQP4UP4ED6ED+FD +BA+hA/rfKjgQ/gQPoQP4UP4ED6ED+FD+BA+hA/hQ/gQPoQP4UP4ED6ED+t8qOFD+BA+hA/h Q/gQPoQP4UP4ED6ED+FD+BA+hA/hQ/gQPoQP63xo4EP4ED6ED+FD+BA+hA/hQ/gQPoQP4UP4 ED6ED+FD+BA+hA/rfGjhQ/gQPoQP4UP4ED6ED+FD+BA+hA/hQ/gQPoQP4UP4ED6ED+t86OBD +BA+hA/hQ/gQPoQP4UP4ED6ED+FD+BA+hA/hQ/gQPoQP63zo4UP4ED6ED+FD+BA+hA/hQ/gQ PoQP4UP4ED6ED+FD+BA+hA/rfBjgQ/gQPoQP4UP4ED6ED+FD+BA+hA/hQ/gQPoQPT5gPg9VB 9+HDEipI8GEeOCp5PixhvDwf5jBpEMpGythOiA+DNcMgwIdlXAk+LOMmYT7MMZQ+xIdxDh+W EV1TPswj6uEc+LBc6Fo+LGN4+BA+hA8vgA+Dtc704cMSyi/hw/yFXgnzYYnhhPiwjJ268WGO FgT4sAwbO/FhjhW1PB+WMEGUD3OEpLrwYYnkxVJeN05Lm/JhiWDlrl4pUT4sEWIXPsyRdA8+ LHGSEB/msY08H5YoUZIPcwBrOvBhiRN78GEO5LQUH5bBgyAf5vG97iA9+bMmyId5/KBE+bBE cB34sMRJ0nyYg0RJPizjpx5vql7dhyVUkuFDP5gefOiH0IMPvdJi2YhXXowPvVYifOi1E+FD r+X50JuDfJjm8aE3rfnQm3QefOitXs2H3tJ9CB/Ch5fBh6HMffbhw1BS1yV8GMa5aHM+DNGI 8WGIsSMfhqQl+DCMfUqMD/O9ogcfxsEJ82Ecza9K8WEUTHnjOOVtzIdRJbmrf5H8tufDaIZO fBiN78KH0Q5ifBhtDz6MVpgP41jbRPgwOt+HD6Mf5PgweiPKh9HHDtITR7zXlg/jCPda82Ec TwKK8GEcTwC258MYnSgfxjT0eFP148OYogwfpqFL92EaJ2wSfJgGuWwkjfO0ZnyYajTZgA/T ODtrwodJG3E+TNod4sPNPD5MOjbmw1SI8xz4MBU5XcmHyQT4ED6EDy+BD91Quu668GEOFRfx oRvGyzta82GO4aX40A3jpR1yfJijOQE+zMOmXnzohh6Ll0uYKMuHTo1n5WX4MEcKUimvU+OU ty0f5ghe7uq1luXDHCH14UOnjOvBhy4X2VJ8mMd28nzolBtE+TAH6LF4ucRJXfjQKS+2eLkM HiX50Klg5KUnR4mSfOjUCN0a82GO4HvwoVPjtvvmfJiDiPKh00MHPsxRXCc+zCnzIMKHeeAO ex+WMKkDHzqtjVg2onWU4kOnjZbgwzyul+BDp0dZRnM+zDEO7n14cwwfti7UjB8G175QmxpW olCrx0ruZni4dxXELE+Qza/v3n/5n095Snkslvvkmhh3t96p/cWgcmZONTgVp101OPGTEagG 65Ha3MGmvot21WDnq29cDU5FaF8NTkVqXQ3Wfx5tqsGJsRtXg1NRmlWD9QDtq8F6nK3bPN6k nke5/f7lS/6I5CCbcvO4WfX8uNmaxwxlXz6a/Jx0dCqSv3l4AH7Y/Jafsh9/DrErd8zdugir E96JgVsnvFN3wsYJb//HRZuEd2rstQnv1LhrE97quI0T3qcY+xJeP8w5K/DZiI3my59GPPn5 8qcLXTNf/jQG8+XMlzNffu7z5U+f5g7z5U+hZs+X1x9fbefLJ1KGJvPlU2PLzJfDMDAMDAPD wDAwDAwDw8AwMEwvhgkwDAwDw8AwMAwMA8PAMDAMDAPDwDAwDAwDw8AwMEwPhokwDAwDw8Aw MAwMA8PAMDAMDAPDwDAwDAwDw8AwMEwPhkkwDAwDw8AwMAwMA8PAMDAMDAPDwDAwDAwDw8Aw MEwPhtnAMDAMDAPDwDAwDAwDw8AwMAwMA8PAMDAMDAPDwDA9GOYGhoFhYBgYBoaBYWAYGAaG gWFgGBgGhoFhYBgYBobpwTC3MAwMA8PAMDAMDAPDwDAwDAwDw8AwMAwMA8PAMDBMD4a5g2Fg GBgGhoFhYBgYBoaBYWAYGAaGgWFgGBgGhoFhejDMFoaBYWAYGAaGgWFgGBgGhoFhYBgYBoaB YWAYGAaG6cEw9zAMDAPDwDAwDAwDw8AwMAwMA8PAMDAMDAPDwDAwTAeGUQMMA8PAMDAMDAPD wDAwDAwDw8AwMAwMA8PAMDAMDNODYRQMA8PAMDAMDAPDwDAwDAwDw8AwMAwMA8PAMDAMDNOD YTQMA8PAMDAMDAPDwDAwDAwDw8AwMAwMA8PAMDAMDNODYQwMA8PAMDAMDAPDwDAwDAwDw8Aw MAwMA8PAMDAMDNODYSwMA8PAMDAMDAPDwDAwDAwDw8AwMAwMA8PAMDAMDNODYRwMA8PAMDAM DAPDwDAwDAwDw8AwMAwMA8PAMDAMDNODYTwMA8PAMDAMDAPDwDAwDAwDw8AwMAwMA8PAMDAM DNODYQIMA8PAMDAMDAPDwDAwDAwDw8AwMAwMA8PAMDAMDNODYSIMA8PAMDAMDAPDwDAwDAwD w8AwMAwMA8PAMDAMDNODYRIMA8PAMDAMDAPDwDAwDAwDw8AwMAwMA8PAMDAMDNODYTYwDAwD w8AwMAwMA8PAMDAMDAPDwDAwDAwDw8AwMEwPhrmBYWAYGAaGgWFgGBgGhoFhYBgYBoaBYWAY GAaGgWF6MMwtDAPDwDAwDAwDw8AwMAwMA8PAMDAMDAPDwDAwDAzTg2HuYBgYBoaBYWAYGAaG gWFgGBgGhoFhYBgYBoaBYWCYHgyzhWFgGBgGhoFhYBgYBoaBYWAYGAaGgWFgGBgGhoFhejDM PQwDw8AwMAwMA8PAMDAMDAPDwDAwDAwDw8AwMAwM04Fh9ADDwDAwDAwDw8AwMAwMA8PAMDAM DAPDwDAwDAwDw/RgGAXDwDAwDAwDw8AwMAwMA8PAMDAMDAPDwDAwDAwDw/RgGA3DwDAwDAwD w8AwMAwMA8PAMDAMDAPDwDAwDAwDw/RgGAPDwDAwDAwDw8AwMAwMA8PAMDAMDAPDwDAwDAwD w/RgGAvDwDAwDAwDw8AwMAwMA8PAMDAMDAPDwDAwDAwDw/RgGAfDwDAwDAwDw8AwMAwMA8PA MDAMDAPDwDAwDAwDw/RgGA/DwDAwDAwDw8AwMAwMA8PAMDAMDAPDwDAwDAwDw/RgmADDwDAw DAwDw8AwMAwMA8PAMDAMDAPDwDAwDAwDw/RgmAjDwDAwDAwDw8AwMAwMA8PAMDAMDAPDwDAw DAwDw/RgmATDwDAwDAwDw8AwMAwMA8PAMDAMDAPDwDAwDAwDw/RgmA0MA8PAMDAMDAPDwDAw DAwDw8AwMAwMA8PAMDAMDNODYW6OYZifvuZPj+N7a38mlEkUmeMd3tZsYmwMx6HBkTJQN4Bq cT9VqB+sxH+quUcV7++V7b4C9gKq16d3Ta16fV65PlatPwrWt/bl+252Ufr0hZJFaT1Gm6J0 amyZorQebUVRundUiZq0HqttTVqP0b4mnYrTriad+MkI1KQ5Uk65b1J6eDbn0cqLbkrWZQ+m 8TMSjqfvaGbZOfFi5ILq+EKpfP2Hv8x94WeMP/0jG90nf//Tyt+f/MFv39YHmpXX569ckKvX L+jojLz+5Tdh1U02J9rrvv5ZBr1koIlxnzLcyfS0UUL5c9IYStI4mQZu6nmgRBL45rWywPeb NxOJ4Iw8cGkW+NcLSgQreeAoC5w5aUF+eJ75YSRBJEF8Fml5jhjd/CxxbpK4PkecnR/OShBt /WfWIjtskxk2SwwvKDPM6ciisfZkh4fk8rgE8UX+dzujd+vY/LCJE/62FAo/H91DNCtLnJ0k jpRw9XurebWx/x0lU3DcneobTvr91uLddjfj7fZ7OfJ7MYJIV0WaaoRqhGrkSqqRFcXI69Ui 7lsbU95TNMwy5YnC4dUqh5uVpcPqwsH+6ZRLh0Op3kYm19uuyfUapXq1XK+2zuGoZO/Y0qKa 67UqLJ6vB/gp63up0GeE0DQjkN6N0juSO5K7udRcInXl5lYtCSfUkWBbpY/5Jz3xDmiUP54O PV+0PO/tS2iXP77IHu9FssdfpLsXWjUdOdnPuL26GvHVP+L2tT/jr14h/vwJj8OJzgUsbU9a VR5+aV8fNqkOL7s4pDaE/qkO6VR/7bLwDBrVO6SMJ9eqfkNduCZpvJPIGpVI1jhzVmE4mWmF uS0k71atb3y+cc+1dLbTUEJWSVZJVrkn0vPcktSy04xD2+1eJhLAttu9PLxPpLuO3lzipFS7 WSnp8uN0qo/TWhCxPccG9rf2RfnhTmFa6ji17tDA3rd/fX/NwaYqVBVUFVQVF1JVnPaq2VdK GRuVFa32Vrm0PvjhqhNGGa/259nHtH4XlllevaoNnm3xr0XdG2+LT7JMskyyfBlt/z+58O+Z c7mLvfuv/Nh8iPb128xUeka6smgz5amXqt3e+52vvvHe+1MR2u+9PxWp9d77E2/ZJnvvT02T tN17/zImY6bnAVruvT/xrQjsvT8Vqd3e+1MRVu+9PzV90Xjv/X3rtxvuvd//cdFm7/39K4CW 770/Ne7avfer4zbee/8pxt6992NYUOO3OwJx3OV2okcgPl3omiMQn8bgCESOQMR6sB6sB+vB erAerAfrwXqwHqwH68F6sB4x64lYD9aD9WA9WA/Wg/VgPVgP1oP1YD1YD9aD9WA9WM/FWE/C erAerAfrwXqwHqwH68F6sB6sB+vBerAerAfrwXouxno2WA/Wg/VgPVgP1oP1YD1YD9aD9WA9 WA/Wg/VgPVjPxVjPDdaD9WA9WA/Wg/VgPVgP1oP1YD1YD9aD9WA9WA/WczHWc4v1YD1YD9aD 9WA9WA/Wg/VgPVgP1oP1YD1YD9aD9VyM9dxhPVgP1oP1YD1YD9aD9WA9WA/Wg/VgPVgP1oP1 YD0XYz1brAfrwXqwHqwH68F6sB6sB+vBerAerAfrwXqwHqznYqznHuvBerAerAfrwXqwHqwH 68F6sB6sB+vBerAerAfruRTrSQPWg/VgPVgP1oP1YD1YD9aD9WA9WA/Wg/VgPVgP1nMx1qOw HqwH68F6sB6sB+vBerAerAfrwXqwHqwH68F6sJ6LsR6N9WA9WA/Wg/VgPVgP1oP1YD1YD9aD 9WA9WA/Wg/VcjPUYrAfrwXqwHqwH68F6sB6sB+vBerAerAfrwXqwHqznYqzHYj1YD9aD9WA9 WA/Wg/VgPVgP1oP1YD1YD9aD9WA9F2M9DuvBerAerAfrwXqwHqwH68F6sB6sB+vBerAerAfr uRjr8VgP1oP1YD1YD9aD9WA9WA/Wg/VgPVgP1oP1YD1Yz8VYT8B6sB6sB+vBerAerAfrwXqw HqwH68F6sB6sB+vBei7GeiLWg/VgPVgP1oP1YD1YD9aD9WA9WA/Wg/VgPVgP1nMx1pOwHqwH 68F6sB6sB+vBerAerAfrwXqwHqwH68F6sJ6LsZ4N1oP1YD1YD9aD9WA9WA/Wg/VgPVgP1oP1 YD1YD9ZzMdZzg/VgPVgP1oP1YD1YD9aD9WA9WA/Wg/VgPVgP1oP1XIz13GI9WA/Wg/VgPVgP 1oP1YD1YD9aD9WA9WA/Wg/VgPRdjPXdYD9aD9WA9WA/Wg/VgPVgP1oP1YD1YD9aD9WA9WM/F WM92jvV4H1Vqaj15RK3PwXrKha61njJGwHqwHqznAqwn3zzt0Md6SiizxHrKFwZh68kxnBKy njK27WY9JVpsbz15WK87WU+JJW09JUbqYD05TjCi1lMihC7WU048VdLWU4JIJe9l7ChqPeWg EC139SmKWo8P+b7UxXpKpNTBenIcZYWsp4wdxa0nR9Fa0npKAN/BenIcM8haTwnRx3pyJDuI Wk+JYCWspwwc5a0nh3FG3npKmCB1ww3DOOdpZD1lbC9gPXncMAhYTxlX2npKjHjIeu5nWU8Y SsbS0nryiGfR11MuNK61njCkAevBerCeS7CeoEu+2sV6gtbDIuvJX2ilrSfHSFLWE/Lr2s96 crQgYD1BW9XLenIscesJ2g09rCfHsbLWkyOkPtYTtDfi1pODRLHkXQctaz05gpe7+qiFrUfH 1Ml6dHJdrMcMg5j1mMF1sB4zJFnrMWMOE7Eeo5K09RhtO1mPGecLja3HjLOGNtZjxgmChPUY q3tYj7FyN1wzngBsZj1GpK+njJtErMd4K249pvjXXuvZDPOsx/jGfT3BlLm7c7AeUzKRldZj Cr5hPVgP1nMB1uMG18t63BCWWY9TWtx6nPJi1uP00NF6nHYS1uPGya2Y9bhxmtvcetw44xWx HjdOeRtbjxtnu0LW45x8X08OItbXk8dOwtbjvJW7+hdTtu2tx72QKjnrcTW3ErAeN+7kamY9 LukO1uNSkLUeP+gu1uOHIG09fpwpCFmPH+cLja3HayVjPV67HtbjK7NnAtbjjdwN15soZj3e GhHr8daLWI8fPfvbW48v82L7rUfNsx5fur6aWk9+SJ2H9fgyMbfSerxnvx6sB+u5DOvJxUkv 6wllcdES68mJlbj1BO/ErCdUOhXkrCdUehcaWE8Irpv1hBDFrSdE3cV6QvTC1hNir76ekDr0 9YQk15Qfx10eja0nDkbw6pOw9UTVaw1X1EMX64naiVlP1KmD9cRxMdvWeuK4ohWxnjiubltb T6wsT5KxnuiMsPXE8eKkNtYTx+mUhPVE73tYTxyvWWp3ww1OzHpiSCLWE6MRsZ44QvP21hML nu+3Hj3PemKyja0nloXU52A9aVCrrSeVbAbrwXqwnvO3nrhbRN/FenKoZfv15C8U368nDpWO 40bWk8f2/awnDk4JWE/stzdziSVuPbGyFl/CenKcIGs9cQiqj/XE8Zr99tYThyiWvOexraz1 xCFGuatPsnsz+3yxqo/15Eixh/VEpYyU9eSxg7z1RCW8X08OEHpYTykOha0nhwh9rCcqq2Wt J0eQsZ6oXA/ryWE67M2cw3i5x4UaN2m2sp48toj1RBW0hPXkcYO09URVHv37rcfMsp48omlr PXnEcBbWE1XZa2ed9eQxNNaD9WA9F2E9u0X0fazHlKR1ifWY8eaRza3HGLG9mfPYrqP1GJMk rMeMZ2XFrMeM09zm1mNcH+sxTrivJxrfy3qM72A9Rm6iNo8tbT0myFmPidLWY1Iv6zEvurek rMcOctZjhx7WY5Ww9VjVx3rsGK1aW4+tbDMtYz3WKGHrscbJWI8dJwgS1mOt7WE91srdcK0z YtZjncjezHlckf16oh3t1dfeeuzh/XrsPOuxPja2Hltm1s7BemzJdVZajy1rurEerAfruQDr cb7XGq4catkaruiC+H490QWx/Xry2Kmj9bhoJKzHxdDNeiobYTS3Hpd8F+vxgxK2Hj+4Ttbj 1SBvPV6JbcCQxxY+hyt6beSuXguv4YreuE7W463qYj1+zMbNrMdXtq9qbz1+XBS2tR5fWdMj YT1+vKintfX4MHSyHh+csPX4kGSsx4+bGyWsx9c6HNtbj5c7+DCPHcSsJwxKxHrC4ESsJ4ye /e2tJyhzyHrcPOsJyje2nlAmx8/BeoJevV9PHoP9erAerOcyrCeW9oY+1hNLU+8S64njqYrm 1hMre6q2sp7Yc7+eGEX268nD+m7WE8dneze3njg+2lvEemIahK1ntya9i/XEFOWtJ8nteJPH DsLWk5Rc6ZGU8JnrMelO+/XEZLrs15PjeDHrSeNztwWsJ1knaz1pfCKhiPWk8aKe1taTXOpk PclbYetJPspYTxonCBLWk0LoYT1pnCu0u+FGL2Y9KQ0i1pOSFbGelJK09aRhOLhfj59lPXlE 19Z68ojnsV9PGkomss568hgW68F6sJ5LsJ60W3fexXpyKLvIevIXRmnrScoZKevJY4d+1pOU l9ivJw/bbb+epMbTs62tJ8ewPawnx0my1pO0Cn2sJ2ktfw5XDiJ2iG4eW/gcrqSNkbt6I9zX k7Tt1NeTtOvS15PjiO3NnMfusDdz0t6IWk8O0GUNV9JBeg1XDtFpDVfScZC1nhzBilhPHjh2 sJ6kU48z13MYJ3fDTUnKepIZRM7hyuMGCetJRomfw5VjHOzrCfOsx7Tu60nmTPp60m7LjJXW YzTWg/VgPZdhPbvF+n2sx5a75BLrseN1Ec2tx+ogZj3WdDxzPUezEtZjTbc1XMlaeeupbCcg Yj2V/QQaW491nfbryZHk9+vJQcQ2YEh2vCF3Y+uxXq70sEEJW4/tdeZ6sn3OXM9xxPp6kk0d +npyFNlzuHKALudwJTeIW48belmPU9LW45SRsR5X2Z9JwHqcHnpYj9NiS37z2GJnridnRNZw 5XFF+nryuOLncCVXFvbut544z3qcbbw3cx7Rn4f1OJtWW48rLZ9YD9aD9VyA9ez2TehjPd4u O4crVfZcaG49lb0XmlmPd7aj9fhxrdzCenytXUjIevy4Qb659Xgfu1iPD1rYeipbRwhZT2UL ifbW46PYKqg8the2Hh+T3NVLn8OVwjB0sp4w+C7WEypbTLWynqBsB+sJ4z2m2lpP0F3268lx pPfrScF02q8nRxJew5UjyJzDlYLtcQ5XDtNjb+YcRm5qIDgtZj3BORHrCS6KWE8YTZO0t57g 3SHrSfOsJ5SexabWE0rP+TlYTwir9+vJY7BfD9aD9VyG9cRye+1jPbHcd5dYT5TfmzlFub2Z U4w9+3oqG9G0sJ4YUzfricmIW09l7xkR60mDtPWkwXeynqQ6rOFKSq4zJo3nmhtbTxKcZq7u cdPUepIJnawnvTjWT8p60rgUbGY9yZkO1pNckLWeNG52E7GeNF4r1tp6alvRyFhPqq0Wa2o9 lY1o2lhPGicIEtZT2ZBGwnoq+9O0u+Emqb6ekLN4iTVcZVyJNVx5XPE1XCWGPWQ9mznWU0Zs az15RH0W53CVC117DlcZg3O4sB6s5xKsJwyq9Jz0sJ4Syi+xnvyF45aSxtZTYjgh6ylj9zuH K0cLAmu4yrCxk/XkWFH6HK4So8c5XDlOkj2Hq0To09cTBj2In8NVgkgl72Vs2XO4cgRl5K5e ye7XkyPoPvv15EimxxquEkfqHK48ttXi1lOiiJ7DlQO4Hn09JY5wX08OUTlSTMJ6SiTZc7hy hCBiPWXgDtZTwiR568lhouDjIspZj04y1qOTjPWYQd56zHDQem6OsZ7WWXVUfhCYQZ0aViKr rse6u3VB7894g52T8E6FaZfwTrxoAglvPVLjhLcepM0dbOqlapfwdr76xgnvVIT2Ce9UpNYJ 78RbtknCOzF244R3KkqzhLceoH3CW4/TNOGd+FYEEt6pSO0S3qkIqxPeiYFbJ7xTd8LGCW// x0WbhHdq7LUJ79S4axPe6riNE96nGPsS3jDMOYzk2YiNJjefRjz5yc2nC10zufk0BpObTG4y uXnuk5tPn+YOk5tPoWZPbtYfX20nNydShiaTm1Njy0xuwjAwDAwDw8AwMAwMA8PAMDBML4YJ MAwMA8PAMDAMDAPDwDAwDAwDw8AwMAwMA8PAMDBMD4aJMAwMA8PAMDAMDAPDwDAwDAwDw8Aw MAwMA8PAMDBMD4ZJMAwMA8PAMDAMDAPDwDAwDAwDw8AwMAwMA8PAMDBMD4bZwDAwDAwDw8Aw MAwMA8PAMDAMDAPDwDAwDAwDw8AwPRjmBoaBYWAYGAaGgWFgGBgGhoFhYBgYBoaBYWAYGAaG 6cEwtzAMDAPDwDAwDAwDw8AwMAwMA8PAMDAMDAPDwDAwTA+GuYNhYBgYBoaBYWAYGAaGgWFg GBgGhoFhYBgYBoaBYXowzBaGgWFgGBgGhoFhYBgYBoaBYWAYGAaGgWFgGBgGhunBMPcwDAwD w8AwMAwMA8PAMDAMDAPDwDAwDAwDw8AwMEwHhlEDDAPDwDAwDAwDw8AwMAwMA8PAMDAMDAPD wDAwDAzTg2EUDAPDwDAwDAwDw8AwMAwMA8PAMDAMDAPDwDAwDAzTg2E0DAPDwDAwDAwDw8Aw MAwMA8PAMDAMDAPDwDAwDAzTg2EMDAPDwDAwDAwDw8AwMAwMA8PAMDAMDAPDwDAwDAzTg2Es DAPDwDAwDAwDw8AwMAwMA8PAMDAMDAPDwDAwDAzTg2EcDAPDwDAwDAwDw8AwMAwMA8PAMDAM DAPDwDAwDAzTg2E8DAPDwDAwDAwDw8AwMAwMA8PAMDAMDAPDwDAwDAzTg2ECDAPDwDAwDAwD w8AwMAwMA8PAMDAMDAPDwDAwDAzTg2EiDAPDwDAwDAwDw8AwMAwMA8PAMDAMDAPDwDAwDAzT g2ESDAPDwDAwDAwDw8AwMAwMA8PAMDAMDAPDwDAwDAzTg2E2MAwMA8PAMDAMDAPDwDAwDAwD w8AwMAwMA8PAMDBMD4a5gWFgGBgGhoFhYBgYBoaBYWAYGAaGgWFgGBgGhoFhejDMLQwDw8Aw MAwMA8PAMDAMDAPDwDAwDAwDw8AwMAwM04Nh7mAYGAaGgWFgGBgGhoFhYBgYBoaBYWAYGAaG gWFgmB4Ms4VhYBgYBoaBYWAYGAaGgWFgGBgGhoFhYBgYBoaBYXowzD0MA8PAMDAMDAPDwDAw DAwDw8AwMAwMA8PAMDAMDNOBYfQAw8AwMAwMA8PAMDAMDAPDwDAwDAwDw8AwMAwMA8P0YBgF w8AwMAwMA8PAMDAMDAPDwDAwDAwDw8AwMAwMA8P0YBgNw8AwMAwMA8PAMDAMDAPDwDAwDAwD w8AwMAwMA8P0YBgDw8AwMAwMA8PAMDAMDAPDwDAwDAwDw8AwMAwMA8P0YBgLw8AwMAwMA8PA MDAMDAPDwDAwDAwDw8AwMAwMA8P0YBgHw8AwMAwMA8PAMDAMDAPDwDAwDAwDw8AwMAwMA8P0 YBgPw8AwMAwMA8PAMDAMDAPDwDAwDAwDw8AwMAwMA8P0YJgAw8AwMAwMA8PAMDAMDAPDwDAw DAwDw8AwMAwMA8P0YJgIw8AwMAwMA8PAMDAMDAPDwDAwDAwDw8AwMAwMA8P0YJgEw8AwMAwM A8PAMDAMDAPDwDAwDAwDw8AwMAwMA8P0YJgNDAPDwDAwDAwDw8AwMAwMA8PAMDAMDAPDwDAw DAzTg2FuKgyjhxcjDgf+fBcx/GFw+f3Y5JE6N8LyR+rcSEsfqTPizH6kzhx74SN1bpTZj9R5 AZY/UufFWfRInfmtrHikzo00/5E6N8LRj9SZAy99pM4LM+95NHfsY59Hc8c99nk0a9yFz6ND MfY+j/z9Mc+j8YgzpwUOjXgy0wKHLvSYaYFDYzAtwLQA0wLnMi1w6NPccFrgUKjJaYF5j69l 0wLzYsybFpg79rppgXnRjp4WmDvsmmmBebEWTwvMDTN/WmDmi/b7tMC+GYDxoHsBZd417IX1 I4ZqUNvPrs2X1OKLK+tlFXOr+nd+kbss6rKvml1dNqgTG5SD9cpvom5bUGqtrqWelU4zKpDn hQYFxWRB8aOceFZKnEcZcfRb/+2EbbR6iy97g79d/bbmXX1Mmfz7+/rH25rimOL46ovjiWp2 ZiG6qJKcVyfOr/QmM8mFtdaiwmlBRTSz7ontCp+1dc/9+sJn/pzkgsKnc92z+x5+O/KrFlUd r1BzNJmBmpWSdSs63lqSMrmk7MfExY+UjPkKUrKrS8lq2djZJGODm5+OTT4ElqVjyxh7fjpG Niat0IsZek021oail7RbLQp7PUmhsEOvV7qvc/pfSAnF2llm3t1OurBcfid7vRsZ97H9r+2c G9nrlLZfqW1b3sgqle1vlLaUttdU2laq2iZF7ZKa9hrmF85peuEE6tk/nXZB+4Y88Krr2X5p IFlghxkO0kDSwGtuOjk+GeyQDYq3m0w/W5ngqGZcr54OdiHBK8sGmd440KbfqMZUSxcMXXwX 2+sv3ulzX3mVJrYm95WLKjLfMmvauMqkyFy4YoeVDRSZrGzovuz/EtZKnGlzHt15p5tnMpdx cXMZJ7lEXHhdOI15TGaQZ15xnjlj2WyPTPD1ls0q1s2eZy7I5/7H5/755/usV2C1/Fx3nKBc skHYq+0DRol38IpfvcjL3/0Jbwc2fzbBnvB0wtRWSeoV9koSWYV1xbUe0wmUedc+nSC1eMEN p7h84ST61eTb1dx1r184l9aS19sbdmHLWp908Cr2hmXnzBNdyEouSC5ILth27cJcHJyd7zx+ acPt8H8/fnZ1CvQ0aLvT75YfYrfm9Lr1Z9I1OHSu8XlyK86OW3XS1qqTGpYd5db0aLaWZ7Et Pn9tzQFrb+3So9NWbOr/8iS0maeKvThAjFSOs8LI7MjsOCuMs8I4K+wKzwr7+SU7naLpSism 1hiiwH0UmA0NuxUPtIBTNZxD1XAZx7ZHw7HtUAw3VW6qUAwUA8VAMWdJMT+9ZLNBpvYe826r HyNt8+NrKzLTXS66fAtf88/iSzPEEbz6l8rzePU5KciDl+u2ZtV89RE8lD/T5RayZl79WSQ/ bH+PVIJ8+PDu69++5Md/jmQazMA/aJG+8Q/f0cPY+Z67KT/qrWkwQW9vtndPOrKbYv+0e6Ue fjTl9bopr1fbWfwXIW5KXbJiZr/MTN/ehKeb+i7DeXxrfcyZ2YfN1/LjsNvyjQS36sG0dZvH m9TzKLffv3zJH5EcZFNuHjf366brzaNXvXuXfya7N/AuGdqViotaCSYj+ZuHZ9OHzW/5Afjx 5xCNWg8ePiFfcsb6/ebD+28tOxHKwI+Z3rvFXQl7+z5u4pqmhQNjb+/tw/NuaWvDxLj38fZC eMHCC/ACvAAvwAvwArwAL8AL8AK8AC/AC/ACvAAvrOMFBy/AC/ACvAAvwAvwArwAL8AL8AK8 AC/AC/ACvLCOFzy8AC/AC/ACvAAvwAvwArwAL8AL8AK8AC/AC/DCOl4I8AK8AC/AC/ACvAAv wAvwArwAL8AL8AK8AC/AC+t4IcIL8AK8AC/AC/ACvAAvwAvwArwAL8AL8AK8AC+s44UEL8AL 8AK8AC/AC/ACvAAvwAvwArwAL8AL8AK8sI4XNvACvAAvwAvwArwAL8AL8AK8AC/AC/ACvAAv wAvreOEGXoAX4AV4AV6AF+AFeAFegBfgBXgBXoAX4AV4YR0v3MIL8AK8AC/AC/ACvAAvwAvw ArwAL8AL8AK8AC+s44U7eAFegBfgBXgBXoAX4AV4AV6AF+AFeAFegBfghXW8sIUX4AV4AV6A F+AFeAFegBfgBXgBXoAX4AV4AV5Yxwv38AK8AC/AC/ACvAAvwAvwArwAL8AL8AK8AC/AC6t4 IQ3wArwAL8AL8AK8AC/AC/ACvAAvwAvwArwAL8AL63hBwQvwArwAL8AL8AK8AC/AC/ACvAAv wAvwArwAL6zjBQ0vwAvwArwAL8AL8AK8AC/AC/ACvAAvwAvwArywjhcMvAAvwAvwArwAL8AL 8AK8AC/AC/ACvAAvwAvwwjpesPACvAAvwAvwArwAL8AL8AK8AC/AC/ACvAAvwAvreMHBC/AC vAAvwAvwArwAL8AL8AK8AC/AC/ACvAAvrOMFDy/AC/ACvAAvwAvwArwAL8ALF8gLwWnrO/BC juO0EC+UsYM4L+QoXkvyQgkQOvBCjhO0LC+UEKELL+RIUYnyQongJXghD5yUPC+UMFK8EJwZ BgFeKONaAV4o4yZhXsgxlD7EC2EOL5QR2/JCGTGdAy/kC9V6JS+UMeAFeAFeuAReCM4624cX SqiwhBfyF3olzAslhhfihTx2GLrxQolm2/NCGTZ24oUcKxp5Xihhgigv5AhJd+GFEskLFejB uXFa2pQXSgQnd/VKifJCiRA78YLTtgsv5CpHjBecsR14wZkkywvOmi68kD/Z0ryQX6xOvOBc FOYF540ML7gKJwnwggtKjBdc8CK84OIgwgsuWnFecCUH2M8LcR4vuDQ05gWX7HnwgktxNS/4 kmzAC/ACvHABvBCKEPfhhVDy/CW8EJQV54WgohgvBK068kLQToIXgu7HC8HoHrwQjBfmhTAu coR4IYyrnWYFerBBmBeCG+Su3nlhXghedeKF4Pt0L4RxkdOMF0JwHXghjDW0LS+EqLvwQhgb aGteCJWJeRleCMkK80JIUYYXcv7agxfiINe9EEfdAG14IZf9IrwQRzlZe16IJTfbzwtpHi/E QsBNeSHqcB68EI1azQvRGHgBXoAXLoIXUkmN+/BCKhMLS3gh+SjOC2ncg9qMF1LwHXkhjRtQ W/BCiq4bL6SYevBCGie7jXkhjZNdGV7wwyDGC3lsYV7wg9JyV1/rLWjJC36o9RRI8IIfjOrB CzmOl+IFP9hBnhdyFNG9F3IAp3rwgvzeCyVE6sMLfvDCvJAjyPCCH8YJggAv5DBBihf8EJUE L+RxJfZeyOOmQZoXcgxziBc2s3ghj9h4cUQe8TwWR/icF6zlhTyGhRfgBXjhEnjB6zJR3IUX cqhFey+UL0zSvOC1tVK8kMeO/XjBV9ZNN+AFX1kyLcULXo9XwwjwQg4j3L3gdRg68YIOYssL 8thJmBd0tHJX/yJJbc8LOvlOvGBeIJIUL5ghivGCGc91CvCCUUGWF3brjDvwgtHS3QvejJvF hHjBmCDMC8YqGV4w1vXgBeMGMV4wzorwghkveWnCC2a00KU9L5iSA+znhZt5vGB8aswLpsjW OfCCKfNoK3nBlLYzeAFegBcugBd2y9z78IKNC3nBRvHuBV9ZJd+MF2xyHXnBpiTBC27Q3XjB Db4HLzg1CPOCG5dSQrzgxuVUswLdjRf3NOaFl3sKNL16I80LznTa2tE726d7wY2XwzTjBTee 9hfgBee8LC8436d7wY0NtDUvuDGCCvGCC06YFyr7ALThhfFGACK84GIU4wWXjAgvuBREeMGP 1qO05wU/2EO8cDuPF/wQGvOCL6uKz4EXfFnFvJIXvPLwArwAL1wELwTba2tHv1vCvYQXghPf 2jHHcGK8EHzHrR1zNImtHfOw3fZe8CH02NoxhxHe2tFXFmgL8UKIYls75gxLeGvHcri42NW/ XDTdnhfi0GlrRx9Vl60dcxyxrR191B22dsxRZLd29Ls1wh14IZoozQvRdtraMUcS3trRR6dl eCGOvUqCF6IX29oxjy2ytaOPQWRrxzyu+NaOOcbBrR3v5vFCjI23dswjmvPghVj2iVnJC7Es jIUX4AV44fx5IQxl1rMLL4RBD4t4IQxafGvHHENsa8cwjDNROV7I0YIAL4TBql68kGP16F4I gxPuXgi9DqbMkbzY5oihsmK6LS+EyorpdlcfrCwvhJdrmsV4IUcKPXghDEnsYMo8doeDKYMa ZA+mzAF8D14ISkkfTJlD+D68EJQWPpgyR5A5mDIoM3TghRzGSvFCHltka8egrJbghTyul+aF HCMe4oXtLF4IyjXmhTzieZwckS909eKIPAaLI+AFeOEyeGG3Ur8PL+hyl1zCC9qJL44IleX+ zXhB+46LI3K0KMELOvTjBR268ELlFPbGvKBjL17QSY4XdJLmBT1e0NPs6s3ghHnBqF688HJH ASleMNqI8UJlMwEBXqjsJ9CWF2rbCEjwgrHivGBsL14wTpoXjBPiBeO78ILxcryw2xVAgBdM EDk5IpggfnJEMPHgyRH383jBRNOYF0w8j5MjgilJyEpeMEW24QV4AV64AF7Yravuwwu7BdZL eMFpeV5wRmzvhTx26MgLzkqcHJGH7XZyRHC1toL2vODGvQWNecG5TgdTBufFdi/IY0dhXnBB y139i40p2/OCi532XgjuRVeBFC9UVlM34wVf6ytozgt+kN17IXjVZe+F4JX03gvB604HU5bd dIV5wRuZvRfK3o49eMHXOgwa8YK3Insv5HFF9l4oW/KI84J37gAvbIZ5vOBd470Xyn4E58EL 3q/eeyGPEeAFeAFeuAhe2K167sMLIS3beyFUjpxuzgtx8GK8EFXHvRfCy/XZjXhhfAi1HC9E 3WPvhRwmCvNCNJ32XsiRxLZ2DNEKb+2YIzi5q3damBei67T3QojedeGFymrqZrwwXlEtwQsx yJ4cEWLswwsxivNCjJ0OpgwxGWFeiCnI8EIaunQvpEGueyENUYQXklIivJCUE+eFpA7tvbBR 83ghqcYnR4Skz+PkiHyhbjUvJA0vwAvwwkXwQhyK9nfhhbjbgmABL8TKbgKteSEOVqx7IVa2 EpDjhVjZUaABL+RhbS9eiJWD2AV4IVb2FGjLC3GozftL8EIcxg2qrQr0WDmLvS0vxMqJ7O2u PkZZXohDsn14obwsPXghVjYWaMULUY2xtT0v5ChOlBei0kMPXshxnDAvxNq2AiK8ECs7C7Tl hVjZX6AJL0RV2f+yPS9EZcVOjojKaQleiMp5CV6IyoufHJFjHDo5YqNn8UIe0bflhagK9p4B L+QLNWt5IY/ByRHwArxwGbywO0m9Dy+YkrMu4QUzTkib84JRYidH5LFTR16orJtuwQuVJdNi vFBZOC3BC8Z4YV4wtXl/EV4wcvP/eewkzAuVE9nbXb0XPpgymhc7ssvxwstVzlK8MF713I4X dmuTxXnBRNnuhWjGu1+K8IIZT8e35gU76E68YIcgzAu2smalCS/YcYIgwQtWD2K8YMdS1YQX rI4ivGBHW2K35wVr/CFeMPN4wZrG3QvR2vPoXsgXunprxzwGWzvCC/DCZfCCC71Ojoi7I6mX 8ELlyOnmvOBiEuOFynnTgrxQWTfdghf8MHTjBT/YHrzgB+HFEdGrTosjciQ5XvBKmhe81nJX r6W7F7wxnXjh5cpsKV6orNJuxguVldoCvODHmwi25QU/3rhFhBf8uJOrNS943+lgyrhbWC3K Cz4I8YIPPfZeyGHkuhd8VCK84KMV4QUfxbd2jD4d2tpxY+fxgk+Nt3bMI/rz4AWf4mpeCCXP hBfgBXjhAnghlMbePrwQ0sLuhTDeV745L8TBiPFCdV8HMV6o7PTQghfys70bL0QVevBC1MIn R+QIthMvVPaRaFagRyO890KOIIcjL3eOaM8L0fbqXohOdeGF6OQWR8RxvSzAC9EbWV6IvsvJ ETEG6ZMjcgjXiRdiSMK8EKOR4YXKHhgSvBCTXPdCTFaEFyr7XTThhfF2F+15IQ3mEC+4ebyQ BteYF3Z7ZpwDL+w24VjJC0lxcgS8AC9cBC/kO7jvxAs5VFzEC2kYzwG35oUcQ2xrxzx2x8UR aRBZHJGH9b14IQ2mx8kRaTBGlhdSZdcQGV5IgxXbvSCPLXwwZY4Q5a7eGVleSC+3ChHjhfRy txAhXshxkhQvpCF0ODkiR5E9OSKn/F32XshxrDAvpGE0SyzEC2morChpygs5gszBlHng1IEX khqMFC+kyo4qLXghVXZTacELeVzxxRE5xsHFEX4WL+QRY1teyAX3eZwckS909ckRabfXDLwA L8ALF8ALKvXa2vEh1BJeUEl874VajGa8UB1bjBcq0VrwQnVYIV6oxJLghWqYprxQe9FkeKH2 HmtVoFe/i6a80PPq2/NCNYIIL1QjCfBC5efRjBdqY7fnhWqUlrxQCSDCC5U4rXmh9q3I8EI1 UlNeqEZowQu1gSV4Qa57oT52C15IQryQBnleKDH280KYyQuPIzbkhTScCS+UC13LC4nFEfAC vAAvwAvwArwAL8AL8AK8AC/AC/DCBfJCnMcLrnRnNeUFF85j74V8oav3Xki7HdrgBXgBXrgA XvCx2+IIX3ZPXMILfrw1YnNe8OP1g814IQw9eSEMVoIXwngfRDFeCKrHyRE5jPDJETlC6sQL QYsdTJnHFj6YMgWj5a7eCG/tmMKLUzvkeCG8OFpOiheCC2K8EHyPxRHBy54ckULocnJEjiN9 ckQKsdPJETmS8NaOKSSZrR1TSD32Xkg5TRbjhTiInByRotDiiKisOC/Ex6UMe3ghzeOF3Y5O TXlht4PTOfDCbgOolbwQDbwAL8ALl8ELqayy7cMLqSRkS3ghjdfRNueFNN5VuRkvpOg68kKS 6V5IyXbjhTRe59qeF2L+IFlRXigRYhdeyJGUFC+UsaMoL+QIYidHlLGTKC/kCKYPL+RItgcv lDhSvJDHdvIHU5YooryQA3jVgRdKHC/LCzlE7bQFAV4okbwoL+QIUYQXysAdDqYsYZIQL+Sx RbZ2LONKHEyZC4bRgamteaHEcId4YTOHF8qIbfdeyCOqsziYslyoW8kLZYwAL8AL8MIF8EJ+ B5QjyHrwQgm16OSI8oXSJ0fkGE7q5Igydr+TI3I0L8ALZdheJ0eUWKEHL+ighHlBB9uJF3SI YgW6jlqYF3R0cleflDAv6OQ78YIZ+vCCGbwYLxg1dOAFM5r5bMwLZmxuIrxgtJbmBaN9J14w ZhDmBWOsDC+Y8S69ErxgrBLjBWNleMHYIMILZnS4bHteMM4e4oWbY3jhH4sefSZfwU8H3A4L v67yWNv/N/c8nmY+ln6PMPtJ8/Li5jxJKt9Yft8d/4yof/3LZ8SxD4TKaGsuY7vmqxfenxfc b+sXn++3c++vEwOV++viW+qae+Zbu/BuuOqWl1+Flze4mRb59Doeb5G9EfLpCtcg5NMYwgj5 gyB/58cf8gg8Ao/A4wQVzlW+o53u6YM/T+DMXEQzE8+k4w3r+dfqBY/AWc60+8q5brRIU+rp xtrEd3XOOz/TXZTiLk1vV2S1DdLZBQnsoohLvmh2pro+R22QmdYz0ol0c3YeuSyDfPs8cZyT ND5LDi8yFVyfCJIGkgZefRpYy//q2d/M5G927re7Ec9LAGfnf8P0M3VZDjg7CTyXBHC9ejYQ z9n535L0b1n2d3zut1aOxtlfYyx/irEPy+NgZvTiPRuxUS/efP96pV68M2IwevHIhciFxHvx nj7NHXrxnkLN7sWrI0PbXrx6jDa9eFNjy/Ti1aOt7sWbGlaiF68eq3kv3lSYdr14Ey+aQC/e xHusSTfb1HfRrhev89U37sVb0OywsBdvKlLrXrwJ1m3SizdFxm178Y7rs1jRizfRO9C8F2+i U6NlL95UP0X7XrypSO168SZ7Q9b24u3pFWnZi1cP06YXb2rstb14U+Ou7cU7HV6w8AK8AC/A C/ACvAAvwAvwArwAL8AL8AK8AC/AC+t4wcEL8AK8AC/AC/ACvAAvwAvwArwAL8AL8AK8AC+s 4wUPL8AL8AK8AC/AC/ACvAAvwAvwArwAL8AL8AK8sI4XArwAL8AL8AK8AC/AC/ACvAAvwAvw ArwAL8AL8MI6XojwArwAL8AL8AK8AC/AC/ACvAAvwAvwArwAL8AL63ghwQvwArwAL8AL8AK8 AC/AC/ACvAAvwAvwArwAL6zjhQ28AC/AC/ACvAAvwAvwArwAL8AL8AK8AC/AC/DCOl64gRfg BXgBXoAX4AV4AV6AF+AFeAFegBfgBXgBXljHC7fwArwAL8AL8AK8AC/ACyfCC9qrQXXhhRJJ qkAvYydRXsgRlJa7epVEeSFH0H14IUcyugMvlDhRiBfy2FaL80KJEiR5IQdwugMvlDhRlhdy CK+78EKJFER5IUcIWoIXysBBnhdymKiFeKGM7QV4IY+bBgFeKONK80KJEQ/xwt0cXtBeD7op L5QRz4IX8oWqYSUvlDE0vAAvwAsXwAvaGzv04YUSyizhhfKFQZgXcgynhHihjO278UKO5of2 vFCGtZ14ocRK8ryQwwQrzAsmxE68YKIRK9BNDMK8YJKSu/oUhXnBDrYTL1g1dOEFq7wYL1it OvCC1U6WF6wZuvCCNU6aF6wdOvGCtU6YF6xNMrxgnenBC3asSc14wXotwgvWexFesEGJ84It OcB+XtjO4wVbHKopL9g4nAcv2GhX84ItBgYvwAvwwgXwglemFy/4krMu4QWvB3Fe8NqK8YLX qSMveGMkeCGXyt14wY8nOCV4IScRwrzgXa/uBe/kuhe8k+5eyO8uuasPgzAv+OA78YJ/gUhS vOCjXPeCT6YDL/gk3L0Qhj7dC2Hw0rwQVC9eCMoK80JQUYYXwljFJHghaCfGC2GchzThhWC0 CC8E48V5IZiD3Qv383ghFKxryguhzMudAy+EklCt5IVgI7wAL8ALF8ELsVRyfXghWruMF6KN 4rwQBbsXYsfFESValOCFOJ76EOOF6H0PXoi1JommvBCD6cQLcdy726xAj3EQ5oUYreDVSy+O iKnX4og09OleSIMT44U0xA68kJSW5YU0bvAQ4YU0Lmtb80LSrhMvJB2FeSEZocURybgevJBM EuOFZI0ILyQr072Q3CDOC8npA7yghnm8kBrvvVBGjOfBC8mvXxyRPIsj4AV44SJ4IQylcb8L L+RQaREvhGFc2bbmhRzDS/FCHrtj90IYgkT3Qh7W9+KFMIzrWQFeyGGEF0fkCKEPL4RBbnlB HtvK8kKOEMWuXg1GlhfCy70pxHghKGV78EJ4uV9FQ14ISnfYeyFH8aK8EFSfxRE5jhXmhVDZ aUOGF0Jl3422vJAjeBFeyAOnDrwQlDNSvJDHDhK8EJQX2Xshj2uleSHH8Id4Qc3ihTxibMsL QZVFImfAC/lCVy+OyGOwOAJegBcugxd0uXX14QUdlnUv5C8U33sh6CjWvZDHth15QUeJ7oWg x/WrGC/o5Hrwgk7C3QvBjDuohXjBjHuomxXoRnprx2CUkbt6Jbz3QjC6094LOVLqwgtmXNM2 4wVjQgdeMFbJ8oKxrgsvmHFZ25oXTGVbARleME54a8dgvJLhhcreQxK8YLzY3gvBBJG9F/K4 ToQXxjsXtecFU/K+/byg5/HCbhekprxgynYE58ALpjQKruSF3TZM8AK8AC9cAC/sdmPpwwu7 TVuW8IJN4nsv5Bhiey/ksUNHXnCV0woa8IIbum3tmGPFHrzglBLmBadcJ15w4/nmZgW601qY F5yWwxFnlDAvuBcFsxwvONvl5IgcJ4jxghu1PEvwgnNWlhfceA2aCC+48bYkrXnBed+JF1wY hHnBBSvDC67LyRHBjac5mvGCi06EF1yMIrzgkhbnBZcObe2ozDxecMk35gU/nMfWjvlC9Wpe 8CXPhBfgBXjhAnjBl7bkPrwQyl1yCS+EwYjzQhiCGC9Uts4S5IXK9lkteCGobls7hso2WhK8 UNlGqzEvBN3p5IhQ2V6rWYEejBPmhWDkcCRYJ8wLwQ2deCE414UXwrjduRkvBG878ELwsls7 hhBUF14IQXprxxBip60dcyQjzAshBhleCOM5DgleCONpjma8EFIU4YU4KBFeiIP4wZQ5RjjE C3YeL0TVeGvHPOJ5bO2YL9St5oVY8kx4AV6AFy6AF5LqtjgiqWUHU+YvlF8ckfQgxgtJ91wc kXSQ4IVkhm68kIztwQvJRGFeSLbTyRE5ktjJEXls6cURuw22pK7eSS+OSN504oXk+yyOSOP9 W5rxQgo9FkekKLw4Io1XvInwQoriiyNS6rU4IiUvywtxGAYRXsgD9ziYMocJUryQM3AlwQt5 XCvBC3lc8cURuQQaDvGCm8ULecTGiyPyiOexOCJfaFzLC3EoeSa8AC/AC+fPC1GVGdwuvJBD hUW8kJ8qSpoXYmUHrVa8ECtbZ8nxQlRWYnFEHrbb4ogcq8fiiJw4aFleyBF8H17IkcTm/6Py RpYXovJe7uqDluWFHKHT4oio+hxMmeOILY6IKil5XshRnCgv5ABdFkdEPUgvjsghQh9eiFop YV7QSmZxRB64x+KIqLXY4og8tsjiiDyuyOKIqI344ogc4+DiCD+PF7QJjXlB2/NYHJEvdPXi iDwGiyPgBXjhMnjBlFtXH14wdln3Qv5CL84Lxol1L8TK1lmCvFDZPqsFLxjfrXshVrbRkuCF yjZajXnBhE7dC7GyvVazAn28xVZrXjBRy119DMK8YFKn7oUcKXbhBTuIdS/ksTt0L0SrBlle sKpL90KOI929EK3WnXjBaunuBWuEuhes6dK9YI1c94K1Mt0L1sp0L1gr371g3cHuhTCPF+zj UZfteMGWJXHnwAvWre9esJ7uBXgBXrgMXnCl9O3DC67cJZfwghvPzDbnhcoOWs14wdUOvRTj hcr2WS14wdXOuxTihco2WhK84GrnXzblBRdtJ16obK/VrEB3lUND2vKCS3I44odBmBf8i1M7 5HjBK9WFF7zyYrzgK4detucFr40sL/jxGjQRXvDj1r3WvODHe6sI8YIf77HSmBe8NTK84Csn XgrwgneDGC94Z0V4wdcOvGzAC350Ckh7XvDeHOKFOI8XfE6/2/KCL9Mg58ALvsymrOQFX5oN 4QV4AV64AF7YbYHVhxdCWTi8hBfC+ECl5rxQ2UGrGS+EkDryQmX7rBa8EKLvxguVbbQkeKGy jVZjXgjjM0OEeKGyvVazAj1WDg1pywtxkMORqKwwL0SVOvFCrB2BKcALUScxXojGdOCFaLws L0Q7dOGFON5UpTUvRJs68UJ0wls75ghehhei77G1Yw5jxHgh+iDCCzEMIrwQR6eAtOeFGPwh XkjzeCGWbK8pL8TS23cOvBDLbMpKXoglz4QX4AV44QJ4IcVuiyNSuUsu4YUU5RdHVHbQasYL la2zBHmhsn1WC15IKfXihVTZRkuAF1JlG622vJAqm2nJ8EKqbK/VqkBP4y22GvNCGrSSu3ot vDgiDUb34YUcqcviiDRYLcULeWwvzwtpcLKLI3KALosjcpwozAtp8J0WR+RIwosjcoQkwgtp CD0WR+QwXooX0hAHCV7I4xoJXsjjBmleyDHSIV7YzOKFNKTGiyPyiOexOCJfaFjLC3mMBC/A C/DCJfBCUqnX4oi0221rAS/kLxRfHJH0oKV4IY/dcXFEjpYEeCFp1W1xRI7le/CC1sKLI3KE TosjUmV7rWYFujbCiyOSNnI4oq3w4ogcwXXiBe26LI7IcZwYL2jXYXFE0l52cUQO0GVxRNJB enFEDtFpcUSOJLw4IumoZXhBxx6LI5JOYosj8thGhBd08iK8YEangLTnBTMcXBxxM48XzNB4 cUQe8TwWRySjVi+OyGOwOAJegBcugxdsuXX14YXdbltLeKGyi1ZzXrDjjaGb8YKtzM3K8YKt lLQNeMHWzrsU4gU7rmcleMGO1xw35gVrUidesFZsc8Q8thfmBWuT3NU7J8wL1g+deMF634UX 7LjduRkv2FHLswQv2PF2pG15wVbqWAlesOOytjUv2DR04gWbrDAv2BRkeMGNV59J8IIbrBgv uCGK8IKrHXjZgBeccuK84FQ4xAu383jBPR512Y4XXNlH5hx4wZWdW1fygit5JrwAL8ALF8AL vpS+fXhht9vWEl6o7KLVnBe8ETs5Io9tO/KCNxInRyRfO+9SiBe87XFyRA4jfHJE/iTqTrzg ndjmiHnsJMwL3svhiPdRmBd86HRyRI6UuvCCj2InR+SxO5wckXzt+MuWvODHu5GK8IJP0idH pDCYTrwQakdgNuWFUDv6sgUvhMpJIQK8EFQU44WgRU6OyOM6EV4IWvzkiBTKTMZ+XribxwvB mMa8EMo+MufAC6HMpqzkhWA5OQJegBcugxdiKX378MJut60lvFDZRas5L0RrxXgh2tCRF6JT ErwQne3GC9HFHrwQvRLmhehdJ16IXm7+PwYtzAuxsrFqs6uPSpgXYu3oSxFeiEl34YU4ngNu xgtpGDrwQhqsLC+k8VSwCC8kpaV5ISnfiReSHoR5IWkrwwupclKIAC8ko8R4IRknwgvJRBFe SKOOvPa8kEret58XtvN4IVnfmBdS6e07B15IZTZlJS+kkmfCC/ACvHD2vGByndtpcUQO5RYt jihfaIR5ocSQWhyRx/ZDN14o0QQWR5Rhey2OyLFCh8URE2Ea8kI1gggvVCM1KtAnvouGvND3 6lvzwkQEAV6YiNScF6o/j0a8UB+7NS9MRGnHC9UAArxQjdOWF+rfigQvTERqyAsTEdbzQn3g 5rxQDdOIFybGXs0LE+Ou5oXauK154THGfl64n8MLv4/YihceRzx9Xni80FW88DgGvAAvwAuX wAtBdeOFEmoRL4wfX+15oVLgNOOFoHryQlAivBAUvAAvwAvwArwAL8AL8MJ18EL+YngBXoAX 4AV4AV6AF+AFeAFegBfgBXgBXoAX4IVVvKDgBXgBXoAX4AV4AV6AF+AFeAFegBfgBXgBXoAX 1vGChhfgBXgBXoAX4AV4AV6AF+AFeAFegBfgBXgBXljHCwZegBfgBXgBXoAX4AV4AV6AF+AF eAFegBfgBXhhHS9YeAFegBfgBXgBXoAX4AV4AV6AF+AFeAFegBfghXW84OAFeAFegBfgBXgB XoAX4AV4AV6AF+AFeAFegBfW8YKHF+AFeAFegBfgBXgBXoAX4AV4AV6AF+AFeAFeWMcLAV6A F+AFeAFegBfgBXgBXoAX4AV4AV6AF+AFeGEdL0R4AV6AF+AFeAFegBfgBXgBXoAX4AV4AV6A F+CFdbyQ4AV4AV6AF+AFeAFegBfgBXgBXoAX4AV4AV6AF9bxwgZegBfgBXgBXoAX4AV4AV6A F+AFeAFegBfgBXhhHS/cHMMLrRM5Z3RQunkiNzWsRCJXj9U8kZsK0y6Rm3jRBBK5eqTbm5Ts 40uWK8V3//Xp42O0r982u/eAKTcz69YEaZNvTb1U7bLFzlffOFucitA+W5yK1DpbnHjLNskW J8ZunC1ORWmWLdYDtM8W63GaZosT34pAtjgVqV22OBVhdbY4MXDrbHHqTjg4+0Ot7j+VmYUH AN/lJgXFy88iB9qc6uOiTcI7NfbahHdq3LUJb3XcxgnvU4y9CW+cs5f5sxEbzac9jXjy82lP F7pmPu1pDObTmE9jPu3c59OePs0d5tOeQs2eT6s/vtrOp02kDE3m06bGlplPg2FgGBgGhoFh YBgYBoaBYWCYXgwTYBgYBoaBYWAYGAaGgWFgGBgGhoFhYBgYBoaBYWCYHgwTYRgYBoaBYWAY GAaGgWFgGBgGhoFhYBgYBoaBYWCYHgyTYBgYBoaBYWAYGAaGgWFgGBgGhoFhYBgYBoaBYWCY HgyzgWFgGBgGhoFhYBgYBoaBYWAYGAaGgWFgGBgGhoFhejDMDQwDw8AwMAwMA8PAMDAMDAPD wDAwDAwDw8AwMAwM04NhbmEYGAaGgWFgGBgGhoFhYBgYBoaBYWAYGAaGgWFgmB4McwfDwDAw DAwDw8AwMAwMA8PAMDAMDAPDwDAwDAwDw/RgmC0MA8PAMDAMDAPDwDAwDAwDw8AwMAwMA8PA MDAMDNODYe5hGBgGhoFhYBgYBoaBYWAYGAaGgWFgGBgGhoFhYJgODJMGGAaGgWFgGBgGhoFh YBgYBoaBYWAYGAaGgWFgGBimB8MoGAaGgWFgGBgGhoFhYBgYBoaBYWAYGAaGgWFgGBimB8No GAaGgWFgGBgGhoFhYBgYBoaBYWAYGAaGgWFgGBimB8MYGAaGgWFgGBgGhoFhYBgYBoaBYWAY GAaGgWFgGBimB8NYGAaGgWFgGBgGhoFhYBgYBoaBYWAYGAaGgWFgGBimB8M4GAaGgWFgGBgG hoFhYBgYBoaBYWAYGAaGgWFgGBimB8N4GAaGgWFgGBgGhoFhYBgYBoaBYWAYGAaGgWFgGBim B8MEGAaGgWFgGBgGhoFhYBgYBoaBYWAYGAaGgWFgGBimB8NEGAaGgWFgGBgGhoFhYBgYBoaB YWAYGAaGgWFgGBimB8MkGAaGgWFgGBgGhoFhYBgYBoaBYWAYGAaGgWFgGBimB8NsYBgYBoaB YWAYGAaGgWFgGBgGhoFhYBgYBoaBYWCYHgxzA8PAMDAMDAPDwDAwDAwDw8AwMAwMA8PAMDAM DAPD9GCYWxgGhoFhYBgYBoaBYWAYGAaGgWFgGBgGhoFhYBgYpgfD3MEwMAwMA8PAMDAMDAPD wDAwDAwDw8AwMAwMA8PAMD0YZgvDwDAwDAwDw8AwMAwMA8PAMDAMDAPDwDAwDAwDw/RgmHsY BoaBYWAYGAaGgWFgGBgGhoFhYBgYBoaBYWAYGKYDw2wGGAaGgWFgGBgGhoFhYBgYBoaBYWAY GAaGgWFgGBimB8MoGAaGgWFgGBgGhoFhYBgYBoaBYWAYGAaGgWFgGBimB8NoGAaGgWFgGBgG hoFhYBgYBoaBYWAYGAaGgWFgGBimB8MYGAaGgWFgGBgGhoFhYBgYBoaBYWAYGAaGgWFgGBim B8NYGAaGgWFgGBgGhoFhYBgYBoaBYWAYGAaGgWFgGBimB8M4GAaGgWFgGBgGhoFhYBgYBoaB YWAYGAaGgWFgGBimB8N4GAaGgWFgGBgGhoFhYBgYBoaBYWAYGAaGgWFgGBimB8MEGAaGgWFg GBgGhoFhYBgYBoaBYWAYGAaGgWFgGBimB8NEGAaGgWFgGBgGhoFhYBgYBoaBYWAYGAaGgWFg GBimB8MkGAaGgWFgGBgGhoFhYBgYBoaBYWAYGAaGgWFgGBimB8NsYBgYBoaBYWAYGAaGgWFg GBgGhoFhYBgYBoaBYWCYHgxzcwzDzPxJxyEFHSQfrVMR2j9apyK1frRW4jR7tE6M3fjROhWl 2aO1HqD9o7Uep+mjdeJbEXi0TkVq92idirD60ToxcOtHaz1M80frVJgWj9b62G0erVNjr320 To279tFaHbfxo/Upxr5HaxrmHEL4bMRGMxxPI578DMfTha6Z4XgagxkOZjiY4Tj3GY6nT3OH GY6nULNnOOqPr7YzHBMpQ5MZjqmxZWY46tFWz3BMDSsxw1GP1XyGYypMuxmOiRdNYIajf8rb cvKh89UjJAgJQoKQICQIybUIiUdIEBKEBCFBSBAShAQhQUgQEoQEIUFIEBKEBCG5eiEJCAlC gpAgJAgJQoKQICQICUKCkCAkCAlCgpAgJFcvJBEhQUgQEoQEIUFIEBKEBCFBSBAShAQhQUgQ EoTk6oUkISQICUKCkCAkCAlCgpAgJAgJQoKQICQICUKCkFy9kGwQEoQEIUFIEBKEBCFBSBAS hAQhQUgQEoQEIUFIrl5IbhAShAQhQUgQEoQEIUFIEBKEBCFBSBAShAQhQUiuXkhuERKEBCFB SBAShAQhQUgQEoQEIUFIEBKEBCFBSK5eSO4QEoQEIUFIEBKEBCFBSBAShAQhQUgQEoQEIUFI rl5ItggJQoKQICQICUKCkCAkCAlCgpAgJAgJQoKQICRXLyT3CAlCgpAgJAgJQoKQICQICUKC kCAkCAlCgpAgJNcuJGpASBAShAQhQUgQEoQEIUFIEBKEBCFBSBAShAQhuXohUQgJQoKQICQI CUKCkCAkCAlCgpAgJAgJQoKQICRXLyQaIUFIEBKEBCFBSBAShAQhQUgQEoQEIUFIEBKE5OqF xCAkCAlCgpAgJAgJQoKQICQICUKCkCAkCAlCgpBcvZBYhAQhQUgQEoQEIUFIEBKEBCFBSBAS hAQhQUgQkqsXEoeQICQICUKCkCAkCAlCgpAgJAgJQoKQICQICUJy9ULiERKEBCFBSBAShAQh QUgQEoQEIUFIEBKEBCFBSK5eSAJCgpAgJAgJQoKQICQICUKCkCAkCAlCgpAgJAjJ1QtJREgQ EoQEIUFIEBKEBCFBSBAShAQhQUgQEoQEIbl6IUkICUKCkCAkCAlCgpAgJAgJQoKQICQICUKC kCAkVy8kG4QEIUFIEBKEBCFBSBAShAQhQUgQEoQEIUFIEJKrF5IbhAQhQUgQEoQEIUFIEBKE BCFBSBAShAQhQUgQkqsXkluEBCFBSBAShAQhQUgQEoQEIUFIEBKEBCFBSBCSqxeSO4QEIUFI EBKEBCFBSBAShAQhQUgQEoQEIUFIEJKrF5ItQoKQICQICUKCkCAkCAlCgpAgJAgJQoKQICQI ydULyT1CgpAgJAgJQoKQICQICUKCkCAkCAlCgpAgJAjJtQtJ/mKEBCFBSBAShAQhQUgQEoQE IUFIEBKEBCFBSBCSaxcShZAgJAgJQoKQICQICUKCkCAkCAlCgpAgJAgJQnL1QqIREoQEIUFI EBKEBCFBSBAShAQhQUgQEoQEIUFIrl5IDEKCkCAkCAlCgpAgJAgJQoKQICQICUKCkCAkCMnV C4lFSBAShAQhQUgQEoQEIUFIEBKEBCFBSBAShAQhuXohcQgJQoKQICQICUKCkCAkCAlCgpAg JAgJQoKQICRXLyQeIUFIEBKEBCFBSBAShAQhQUgQEoQEIUFIEBKE5OqFJCAkCAlCgpAgJAgJ QoKQICQICUKCkCAkCAlCgpBcvZBEhAQhQUgQEoQEIUFIEBKEBCFBSBAShAQhQUgQkqsXkoSQ ICQICUKCkCAkCAlCgpAgJAgJQoKQICQICUJy9UKyQUgQEoQEIUFIEBKEBCFBSBAShAQhQUgQ EoQEIbl6IbmpCYl6MSI1PTU9Nf3Z1PSqdkOIfxh80LZxTX8g1HRNf+ALm9T0s2LMrOlnjr2y pp8V7fiafuawq2r6WbGW1/Qzwyyo6ee9aGtq+nnvsXlJ2szvYkFNfxpXv7SmnxlhRU0/M9Li mn7Wz2NmTT9v7KU1/cwo82v6WQFW1PRzPxq39z8eTF+2JVfOifCv7+7ef9nefsu/k2OXYOXN vCbQMjyYFcLY7eMPpcxjvstRcurz/sv/fLf9WBLoclsvt5JVP5Y1PjHvm7m5HdJjVvL37ffP 7z7nd9iHXGTkl+v9t3/+4fbXTx+3f4h+944ud7F1b7clGjIzwvEaMm/gMKTtfg3xN1UNmRUm qPvhpvbmevzMtHh3mfsh6ed3lfKjf/f9c3mh4u4un1YlPjM5ZObYR3PIzHGP5pA54y7lkAMx 9nJIjMdwyHjEuQ0jB0Y8nYaRAxd6VMPIgTHAJXAJXAKXwCVwCVwCl8AlcAlcApfAJXAJXAKX LgeXErgELoFL4BK4BC6BS+ASuAQugUvgErgELoFL4BK4BC4txaUNuAQugUvgErgELoFL4BK4 BC6BS+ASuAQugUvgErgELi3FpRtwCVwCl8AlcAlcApfAJXAJXAKXwCVwCVwCl8AlcAlcWopL t+ASuAQugUvgErgELoFL4BK4BC6BS+ASuAQugUvgEri0FJfuwCVwCVwCl8AlcAlcApfAJXAJ XAKXwCVwCVwCl8AlcGkpLm3BJXAJXAKXwCVwCVwCl8AlcAlcApfAJXAJXAKXwCVwaSku3YNL 4BK4BC6BS+ASuAQugUvgErgELoFL4BK4BC6BS+DSQlxKA7gELoFL4BK4BC6BS+ASuAQugUvg ErgELoFL4BK4BC4txSUFLoFL4BK4BC6BS+ASuAQugUvgErgELoFL4BK4BC6BS0txSYNL4BK4 BC6BS+ASuAQugUvgErgELoFL4BK4BC6BS+DSUlwy4BK4BC6BS+ASuAQugUvgErgELoFL4BK4 BC6BS+ASuLQUlyy4BC6BS+ASuAQugUvgErgELoFL4BK4BC6BS+ASuAQuLcUlBy6BS+ASuAQu gUvgErgELoFL4BK4BC6BS+ASuAQugUtLccmDS+ASuAQugUvgErgELoFL4BK4BC6BS+ASuAQu gUvg0lJcCuASuAQugUvgErgELoFL4BK4BC6BS+ASuAQugUvgEri0FJciuAQugUvgErgELoFL 4BK4BC6BS+ASuAQugUvgErgELi3FpQQugUvgErgELoFL4BK4BC6BS+ASuAQugUvgErgELoFL S3FpAy6BS+ASuAQugUvgErgELoFL4BK4BC6BS+ASuAQugUtLcekGXAKXwCVwCVwCl8AlcAlc ApfAJXAJXAKXwCVwCVwCl5bi0i24BC6BS+ASuAQugUvgErgELoFL4BK4BC6BS+ASuAQuLcWl O3AJXAKXwCVwCVwCl8AlcAlcApfAJXAJXAKXwCVwCVxaiktbcAlcApfAJXAJXAKXwCVwCVwC l8AlcAlcApfAJXAJXFqKS/fgErgELoFL4BK4BC6BS+ASuAQugUvgErgELoFL4BK4tBCXNgO4 BC6BS+ASuAQugUvgErgELoFL4BK4BC6BS+ASuAQuLcUlBS6BS+ASuAQugUvgErgELoFL4BK4 BC6BS+ASuAQugUtLcUmDS+ASuAQugUvgErgELoFL4BK4BC6BS+ASuAQugUvg0lJcMuASuAQu gUvgErgELoFL4BK4BC6BS+ASuAQugUvgEri0FJcsuAQugUvgErgELoFL4BK4BC6BS+ASuAQu gUvgErgELi3FJQcugUvgErgELoFL4BK4BC6BS+ASuAQugUvgErgELoFLS3HJg0vgErgELoFL 4BK4BC6BS+ASuAQugUvgErgELoFL4NJSXArgErgELoFL4BK4BC6BS+ASuAQugUvgErgELoFL 4BK4tBSXIrgELoFL4BK4BC6BS+ASuAQugUvgErgELoFL4BK4BC4txaUELoFL4BK4BC6BS+AS uAQugUvgErgELoFL4BK4BC6BS0txaQMugUvgErgELoFL4BK4BC6BS+ASuAQugUvgErgELoFL S3Hp5hhcWpT3GOOH4/+mc6Mn/94/fJmAzEw2dqPOTh2evurofODniz/+CV/5ph+e8Mc+wX8f YFHAJV80+1mz4D7+4jLn3q0rL+voxrwpN7WJW9L8u8iyu8TzO8EMrn2usnv1tT2+Pr2ya/D1 aQxRfP0Br7+j66O3gq1g60Vg60/GWiXVuoHO08uj9fH5TXeeLc7VQbPn2Xk80P34er3goTJL 0B6+ciaJLXKi2muyOKkrA63L7IpPzcrudrw0P8VbluC5vyxO8RpkeIUL5md5b3ulebOzvLcn kebJZnnutdK83nPsJ5jmVbK86RzvG0nezCSPHO+kcrznuV0ttZuY3Z45Mb0otzuv5C5//ZL8 rkOCF08jwysD9c3y+hFevpTXTPE6ZXcL0rtXMDyp7G4iubvZjB/wix/rlYf6jwf6wuf5oqf5 UQ/zdU9ynuNtreZyHuSm4ZP8oh7kjZ7ja5/iqx/iPaRm6E41rbDmdK1mPtXYK5iSW081/xSw muudkduDNRu0him5M5+SOzQZ1yTPw2sapnlnOR/XX2tKpnceYnNus3JdpuUuf1ZuWaL31j5L 9ZiUI9Mj05PI9FZ1Txun1eBlu6efYuzrnt4MZsbS/GcjNlqa/zTiyS/Nf7rQVXeoxzFYms8N i9L03JfmP32aOyzNfwo1e2l+9THTeGl+PUabpflTY8ssza9HW700f2pYiaX59VjNl+ZPhWm3 NH/iRRNYmj/xHmuyuH3qu2i3NL/z1Tdemj8Vof3S/KlIrZfm138ebZbmT4zdeGn+VJRmS/Pr Adovza/HabpifuJbEVjOPhWp3QLzqQirF5hPDByGu83+BeY7Szt6gXk9TJvF2VNjr12cPTXu 2sXZp8MLFl6AF+AFeAFegBfgBXgBXoAX4AV4AV6AF+AFeGEdLzh4AV6AF+AFeAFegBfgBXgB XoAX4AV4AV6AF+CFdbzg4QV4AV6AF+AFeAFegBfgBXgBXljOC0YFJcULeWwnzws5ShLlBaOi 7cELOU4U5gWjku7DCzmSMC8YPQwivJAHNh14IYcJUrxgcrYvwQt5XCvBC3ncIM0LRuvhEC+E WbyQR9RteSGPGM6CF/KFprW8YLRR8AK8AC9cAi+Y/HHuxAs5lFvEC/kLkzQvmBxEihfy2B15 IUdLArxgjNW9eCHH6sELxrhBlhdyBNOHF3KkIFWglx3hZHkhR7CCV59kecGY4PrwgjFx6MIL JjoxXjDjelmAF8y4ZG7LCyZ16V4wdlwvt+YFO9hOvGCHKMwLdlxCt+EFq1wPXrAqivGC1VqE F6x2IrxgR3lfe16wpZrdzwtxHi9YYxrzQi6Oz4MXrFnPC9bCC/ACvHAZvOBKWd2HF/KtYxkv OBPEecFZJcYLzrqOvOBslOAF51Q3XnDjjf0leMG5JMwLzutOvJCrTLEC3fkkzAsuGLmrD1GY F9yLiWw5XnAxdeEFl6wYL7gUOvCCH5QsL/jBdeEFPyRpXvDKdOIFP5qPbs0LXgt1L3hte/CC 13LdC97IdC94I9O94E0U5wVvD3YvpHm84G3r7gVf8sdz4AVfUs+VvODLnA+8AC/ACxfAC6Hc XvvwQij33SW8EKz44ggTxjPZzXghjOewBXkhOInFESZUprCleCF404MXgg/CvBDGTeZCvBCC 3Px/CFGYF0JUclcfgzAvhBcz5XK8EFLswgs5MxDjhdhj7wWTR5XlhVipySV4ISrxxRFR91oc Ecfz3I15IY47HdvwQjRdFkdEI7b3gol2EOGFaI0IL0Qrvzgi2nSIFzbzeCG61rwQ3ZnwQiwt lCt5IZY5H3gBXoAXLoAXkuvGC8kt5IU0nsxuzgtpPJPdjBeS1x15IXkRXkiVKWwpXkihCy+k ILz3gklx6MQLKcrxQopBmBdSGuSuPgnvvWCHFzPlYryQI4UevGAHJbb3Qh67w94LOYrs3gt2 qNTkAryQ4wRhXrCDGfrwQo5kZXkhR4givGCHcXujAC/kME6KF/LYSYIX7OC0BC/kcZ00L+QY 8RAv3MziBTv4oS0v5BHNWfBCvtDVWzvmMQK8AC/AC5fAC1aV22sXXrCq3HcX8EL+QivNCzlG kOIFW9koTY4XcjQrwAt52NiLF6waT2YL8EIO42R5IUdIfXjBVrZna1Wg28qGbG15IUdIYlev ByfMC1oNnXhBK9eFF/S4xbwZL2htOvCC1kGWF/S401yEF7Rx0rygTerEC9oaYV7QNsjwgh63 N0rwgnZWjBe0CyK8oP0gwgt6lPe15wXtD54ccTuPF7RPjXlBB30evKBL6rmSF3RicQS8AC9c Bi+YUsn14QUTzTJeMFF87wVrktjiiDy27cgLZry2uQUv2KHb3gu2steYBC9UNhprzAtWddp7 wVZ2HmtWoFslvPeCrWw61u7qtfDeC9aaTnsvWGu7bO2Y44gdTGmtGzrwgnVOlhfsuKYS4YX8 pJPmBet78YIN0t0LNsgsjrA29lgckcOI7b1gbRLZ2jGPK3IwZb5RDOK84AZziBfu5vGCa30w pXWFr8+BF1xZMLaSF1xJZOAFeAFeuABe2G1E04cXdjvULOEFb8VPjsjjGTFe8C525AVf2U6w AS943+1gSutDl+4FL704wvpeiyNyJLHFEXlsaV7wychdfRI+OcKGXgdT2qB0F14I4wX/zXgh aN2BF4J090Lo1L0QxovxW/NCqPT9y/BCZRelxrxQ2UOpDS8E12NrxxwmifFCZUujJrxQ2cOo CS+EoMV5IZRTf/bzwnYeL4QQGvPCbmeic+CFENd3L+y2SoIX4AV44QJ4IZUzi/vwQlJ+GS+k catuc15I2onxQtKpIy+k8R5ULXghmdCNF9L4EEwJXkhWeGtHm1ynrR1zJLGTI/INRfhgyhxB DkdSUMK8kELoxAvpxRSqFC+kMSg144WUeiyOSCmK8kL+V5etHcu/hHnBDarT1o45kvDJEa62 JUYLXsgD+w684Cr7YLTihTy2k+CFPG6S4AU3jJbSNOeFHOPg4oj7WbyQR4xtecEN7jx4IV/o al5wuw034AV4AV44f15wqtxeu/BCDhUX8YJT462DWvNCjuGleCGP3ZEXnBLpXsjDduteyLFS B15wqraDZEteyBFCH15wKoptjpjHtrK8kCMEuatPRpYXcoTYhxecHmwPXshxxLoX8n27Q/eC 00p2cUQOkLrwgh4fiNiaFyr7VAjxgvbSvKCDkuEFHVwPXtBBrHvB6SjSvZDHFVkc4XQSXxyR YxxaHKGGebygk2vMC7o8X86BF0xZQLuSF0xhW3gBXoAXLoAXduvP+/CCVcu2dsxfKL61Y9mF T4wXaivL5XjBjvswWvCC1d1OjnDW9Dg5IocR7l4o2xZ04gVrxfZeKAuChXnBOi139U547wVn vfl/2fu33siVNE3Q/SsC9s0MenItng+JRG8U9jRqGugqTPdMoy4KhYBLclVGZ6yI6Dhk5upf v0kPxdFJyUkzY7jkTxYq1yFD9tHl7uT3PmY0bsQLP94ln4oXJu6Rj8YLVdttwAtVV6Tlheo4 UyXhhep4U6DYvFD11Ua8UPVdYl6os0SrF+psk9ULdZ5u9UKdV0l4oc6T3BwxEl5yXqhHvXuY F/JlvFAXkfdeGH3hafBCXRbBvFCPGxnhBbyAF54BLzRjxNqGF5pxDd0aXmiO95uOzgtNlezJ EUPU2PDJEUO1FE+OqCc2kEjGCxPbR6TghYntJCLzQtNutPfCUCnZ7QXD2IkfTFk3x48KiXf0 XZuYF5q+2IgXmql1Egl4oT1e+R+NF9qs3YAX2olHa0blhfZ4eUQSXmiPV0nE5oW22IoX2iI1 L0xtiRGFF9pyk9ULbZlu9UJbpVm9MLGjRhReON5HIz4vtPWjqxeKZbzQ1rFXL7T1E1m90Dbh qxcOG4TgBbyAF54BL3TNZjdHdM3KmyO6Nv3NEV2b7uaIrt3y5oiuS7H3wjDsdjdHdP0WWzsO ZarEvND13Ua80Gfp5v/7LPGDKes+T3drR58nfjBl3Rf5RrzQF+0mvNCXRTJe6Mt6A17oj2Na XF7oq2oTXuir5Hsv9PVWey9M7BATmRcm9omJwwsT28Ok4IW+6ZLxQt8meXLEMG6dhBf6o74p Pi/04yqnh3mhXMYLfVdF5oV+BPKnwAv9uNIqkBf60erxAl7AC0+fF5psPCNswgtDqWIVLww/ 2KTmhSbPkj2Ychi73I4XhmopHkzZ5McJMBUvDLW2eDDlUCbxzRFNXmx0c8RQKdnNEcPYiW+O aPIyT3f0ZeLVC01ebbR6ocmrTVYvNBO73cTihWZil5v4vNDkTZaUF4YCm/DCUCc1LzR5uxEv DJUS88JQIc2DKZt8kwdTDmWaVLzQ5H2WgheavC9T8MIwbpuaF4Ya/WO8UC3ihaYYNyCIyQvD iPWT4IXhQNtQXhjG6PECXsALz4IXymwzXiizlbxQZul5ocz6ZLxQ5lvyQpk3KXihzDfbe6Ep iy32XhjKpOaFstzo5oihUrKbI4axE98c0ZRVOl4oqyYxL5T1VrxQ1pusXhjOFul4oWw2WL0w VEm7eqEp202eHDHUaVPzQtlt9GDKoVKdmBfKLhEvlH2xBS+UfTpeKPs+CS9UWRpeqI76vvi8 UGWP8kK9jBeqPDYvHPYeewq8UOXhvHDYBA0v4AW88Ax44bCV0Da8UOcreaE+vs01Oi/UeTpe qLfc2rGpiyS8UG+3tWNTb7K141AmNS/U1Va8UFfpeKGuUvNCXafjhbpOzQt1sxUv1M02vFC3 6XihbrfghbpNzAt1tw0v1F1yXqj7rXih7lPzQt0n4oUm24QXmiwdLzRZGl5o8jS80OTpeaHJ H+WFZhkvNEVsXmiKJ8ILTRHOC02BF/ACXngevHDYOWobXmiLlbzQFul5oS3S8UJbbskLbZmE Fyb2nErGCxN7UKXghYktqSLzwvHmVKl4oa3T8UJbp+aFtsnSHX2TmhfadqO9F4ZK2/BCezyf HY0X2m4LXmi7xLzQ9tvwQtsn54Uu24oXuiw1L3RZl4YXunwTXujyOhkvdHkaXuiKIgkvdEV6 XujGNPswL7TLeKEbVyxG5YVunG15CrzQja1nIC90JV7AC3jhefBCX2zGC/14g/UaXujL5A+m HGokezBl01cbPjliqJbiwZTNxBZjyXhhYq+xFLwwsdFYZF7o634jXuibMllA75vEWzs2fZuO F/o2NS/03Va80HfNJrzQ9+l4oe+34IW+75LyQptNzGYn4IWhTmpeaLM824YXhkpVWl4YKqTh hTY73kYnAS8MZZLxwjB2El5oszIJLwzj1ql5YajxKC90i3ihzarIvDCM+DR4YTjQYF4Yxmjx Al7AC8+BF9p8PL1uwgttXq3jheEHk/PCVI1YvDA9dipemKoWgRemh03DC1O1EvDCdJmYvDD5 S0vCC5OfsUgBffpVxOSFTY8+Oi9MV0jBC9OV4vPC1PsRixcmx47OC9NVYvJCvs2TI6bqxOaF qZeShhcmK0XlhckKMXhhauAEvDBRJhovTI4dgRcmx43AC8fjxueFQ42HeaFfxgufR4zHC4cR nwIvHA40kBcOY+AFvIAXngMvjN/mrXihwgt4AS/gBbyAF/ACXsALeOHseWGHF/ACXsALeAEv 4AW8gBfwAl7AC3gBL+AFvBDGC9d4AS/gBbyAF/ACXsALeAEv4AW8gBfwAl7AC2G8cIMX8AJe wAt4AS/gBbyAF/ACXsALeAEv4AW8EMYLt3gBL+AFvIAX8AJewAt4AS/gBbyAF/ACXsALYbyw xwt4AS/gBbyAF/ACXsALeAEv4AW8gBfwAl4I44U7vIAX8AJewAt4AS/gBbyAF/ACXsALeAEv 4IUgXigyvIAX8AJewAt4AS/gBbyAF/ACXsALeAEv4IUwXsjxAl7AC3gBL+AFvIAX8AJewAt4 AS/gBbyAF8J4ocALeAEv4AW8gBfwAl7AC3gBL+AFvIAX8AJeCOOFEi/gBbyAF/ACXsALeAEv 4AW8gBfwAl7AC3ghjBcqvIAX8AJewAt4AS/gBbyAF/ACXsALeAEv4IUwXqjxAl7AC3gBL+AF vIAX8AJewAt4AS/gBbyAF8J4ocELeAEv4AW8gBfwAl7AC3gBL+AFvIAX8AJeCOOFFi/gBbyA F/ACXsALeAEv4AW8gBfwAl7AC3ghjBc6vIAX8AJewAt4AS/gBbyAF/ACXsALeAEv4IUwXujx Al7AC3gBL+AFvIAX8AJewAt4AS/gBbyAF8J4YYcX8AJewAt4AS/gBbyAF/ACXsALeAEv4AW8 EMYL16fwQlO2WZclPOVMF4h/ypmuM1yNb+6+9MLv9mM8H7L3qxe3L9/tbz4M/2aoPRYbr58h haKe26ZLlNX+/k0ZmeXFUGVIWy/f/c8X+9djZh87ybF7CXpbEpw+Z17M9U3W3wehv+w/vn3x dviE/fb2w/BiPrz88PsvN6/evN7/0jWHi+h4xgv7uEU8Wc9VCD5ZzwzcZv3+4ZN1c73kZD1d ps3vsuupD9f9dybGp6u8y/ri27PK+Na/+Ph2/EV1h8ay70PGj3PBmRs79IIzN27oBWdy3MgX nM81HrzgdEvuxvtmxEie/XnEs/fszwca4tmfx+DZPJtnP3XP/vxt3sCzP5da7NnTl6+4nj3T w0fx7Lmx03j2dLVgz54bNoVnT9eK7tlzZeJ59swvLYFnT1bKs93dvdreHoa+ffFmbHl344vY 5YHpNoI1z/1+4kn5xkcfWcrnKsSX8rlKsaV8Bn2iSPkcKMWVcmyFrbAVtsJW2CqUrXpsha2w FbbCVtgKW2ErbIWtsBW2wlbYClthK2yFrc6PrXbYClthK2yFrbAVtsJW2ApbYStsha2wFbbC VtgKW50fW11jK2yFrbAVtsJW2ApbYStsha2wFbbCVtgKW2ErbHV+bHWDrbAVtsJW2ApbYSts ha2wFbbCVtgKW2ErbIWtsNX5sdUttsJW2ApbYStsha2wFbbCVtgKW2ErbIWtsBW2wlbnx1Z7 bIWtsBW2wlbYClthK2yFrbAVtsJW2ApbYStsha3Oj63usBW2wlbYClthK2yFrbAVtsJW2Apb YStsha2wFbY6O7bqM2yFrbAVtsJW2ApbYStsha2wFbbCVtgKW2ErbIWtzo+tcmyFrbAVtsJW 2ApbYStsha2wFbbCVtgKW2ErbIWtzo+tCmyFrbAVtsJW2ApbYStsha2wFbbCVtgKW2ErbIWt zo+tSmyFrbAVtsJW2ApbYStsha2wFbbCVtgKW2ErbIWtzo+tKmyFrbAVtsJW2ApbYStsha2w FbbCVtgKW2ErbIWtzo+tamyFrbAVtsJW2ApbYStsha2wFbbCVtgKW2ErbIWtzo+tGmyFrbAV tsJW2ApbYStsha2wFbbCVtgKW2ErbIWtzo+tWmyFrbAVtsJW2ApbYStsha2wFbbCVtgKW2Er bIWtzo+tOmyFrbAVtsJW2ApbYStsha2wFbbCVtgKW2ErbIWtzo+temyFrbAVtsJW2ApbYSts ha2wFbbCVtgKW2ErbIWtzo+tdtgKW2ErbIWtsBW2wlbYClthK2yFrbAVtsJW2ApbnR9bXWMr bIWtsBW2wlbYClthK2yFrbAVtsJW2ApbYStsdX5sdYOtsBW2wlbYClthK2yFrbAVtsJW2Apb YStsha2w1fmx1S22wlbYClthK2yFrbAVtsJW2ApbYStsha2wFbbCVufHVntsha2wFbbCVtgK W2ErbIWtsBW2wlbYClthK2yFrc6Pre6wFbbCVtgKW2ErbIWtsBW2wlbYClthK2yFrbAVtjo7 ttpl2ApbYStsha2wFbbCVtgKW2ErbIWtsBW2wlbYCludH1vl2ApbYStsha2wFbbCVtgKW2Er bIWtsBW2wlbYCludH1sV2ApbYStsha2wFbbCVtgKW2ErbIWtsBW2wlbYCludH1uV2ApbYSts ha2wFbbCVtgKW2ErbIWtsBW2wlbYCludH1tV2ApbYStsha2wFbbCVtgKW2ErbIWtsBW2wlbY CludH1vV2ApbYStsha2wFbbCVtgKW2ErbIWtsBW2wlbYCludH1s12ApbYStsha2wFbbCVtgK W2ErbIWtsBW2wlbYCludH1u12ApbYStsha2wFbbCVtgKW2ErbIWtsBW2wlbYCludH1t12Apb YStsha2wFbbCVtgKW2ErbIWtsBW2wlbYCludH1v12ApbYStsha2wFbbCVtgKW2ErbIWtsBW2 wlbYCludH1vtsBW2wlbYClthK2yFrbAVtsJW2ApbYStsha2wFbY6P7a6PoWtgl5rnxdZk6d9 rZ9rPPRar7NyAdF9M2Ikovs84tkT3ecDDSG6z2MgOkSH6J460X3+Nm9AdJ9LLSa6yctMZKKb rhGH6ObGTkN009WCiW5u2BREN10rOtHNlYlHdDO/tAREN/MZi0JRc68iHqRtfPSRIW2uQnxI m6sUG9Km3484kDYzdmRIm6sSDdKmC8SHtOk6UX1r5qUkwKe5SvE4aK5CMAfNDNxmt7uHOWjX LuGg6TILKaVYNvbJlLJw3JMppdiAF4oQXqimeKGIzgvFU+GFIgIvFHgBL+CFZ8ILxXa8UKzl hWIDXigS8kKxKS8UaXih2JAXim14oUjOC8VmvFAkDOhFcl44j6NfywvFZrxQbMQLRUJeKDbh hSI1LxQb8UKRnheKzXihSM4LRSpeKLbhhQIvPB1eqPECXsALeAEv4AW8gBfwAl7AC3gBL+AF vIAXwnihwQt4AS/gBbyAF/ACXsALeAEv4AW8gBfwAl4I44UWL+AFvIAX8AJewAt4AS/gBbyA F/ACXsALeCGMFzq8gBfwAl7AC3gBL+AFvIAX8AJewAt4AS/ghTBe6PECXsALeAEv4AW8gBfw Al7AC3gBL+AFvIAXwnhhhxfwAl7AC3gBL+AFvIAX8AJewAt4AS/gBbwQxgvXeAEv4AW8gBfw Al7AC3gBL+AFvIAX8AJewAthvHCDF/ACXsALeAEv4AW8gBfwAl7AC3gBL+AFvBDGC7d4AS/g BbyAF/ACXsALeAEv4AW8gBfwAl7AC2G8sMcLeAEv4AW8gBfwAl7AC3gBL+AFvIAX8AJeCOOF O7yAF/ACXsALeAEv4AW8gBfwAl7AC3gBL+CFIF7IM7yAF/ACXsALeAEv4AW8gBfwAl7AC3gB L+CFMF7I8QJewAt4AS/gBbyAF/ACXsALeAEv4AW8gBfCeKHAC3gBL+AFvIAX8AJewAt4AS/g BbyAF/ACXgjjhRIv4AW8gBfwAl7AC3gBL+AFvIAX8AJewAt4IYwXKryAF/ACXsALeAEv4AW8 gBfwAl7AC3gBL+CFMF6o8QJewAt4AS/gBbyAF/ACXsALeAEv4AW8gBfCeKHBC3gBL+AFvIAX 8AJewAt4AS/gBbyAF/ACXgjjhRYv4AW8gBfwAl7AC3gBL+AFvIAX8AJewAt4IYwXOryAF/AC XsALeAEv4AW8gBfwAl7AC3gBL+CFMF7o8QJewAt4AS/gBbyAF/ACXsALeAEv4AW8gBfCeGGH F/ACXsALeAEv4AW8gBfwAl7AC3gBL+AFvBDGC9d4AS/gBbyAF/ACXsALeAEv4AW8gBfwAl7A C2G8cIMX8AJewAt4AS/gBbyAF/ACXsALeAEv4AW8EMYLt3gBL+AFvIAX8AJewAt4AS/gBbyA F/ACXsALYbywxwt4AS/gBbyAF/ACXsALeAEv4AW8gBfwAl4I44U7vIAX8AJewAt4AS/gBbyA F/ACXsALeAEv4IUgXigyvIAX8AJewAt4AS/gBbyAF/ACXsALeAEv4IUwXsjxAl7AC3gBL+AF vIAX8AJewAt4AS/gBbyAF8J4ocALeAEv4AW8gBfwAl7AC3gBL+AFvIAX8AJeCOOFEi/gBbyA F/ACXsALeAEv4AW8gBfwAl7AC3ghjBcqvIAX8AJewAt4AS/gBbyAF/ACXsALeAEv4IUwXqjx Al7AC3gBL+AFvIAX8AJewAt4AS/gBbyAF8J4ocELeAEv4AW8gBfwAl7AC3gBL+AFvIAX8AJe COOFFi/gBbyAF/ACXsALeAEv4AW8gBfwAl7AC3ghjBc6vIAX8AJewAt4AS/gBbyAF/ACXsAL eAEv4IUwXujxAl7AC3gBL+AFvIAX8AJewAt4AS/gBbyAF8J4YYcX8AJewAt4AS/gBbyAF/AC XsALeAEv4AW8EMYL1yfxwqnn1/6Xsi36vkpxfp0dO+r5db5KpPPrXIHY59e5OhHPr7MvJfr5 db5SrPPrfIXA8+vswHHPr3NlYpxf58cOO7/Ojxt2fp0ZN+r59WuNB8+v3ekP/v1uxCh8+3XE M+fbrwe6nm+/joFv8S2+fdp8+/XbnJxvv5ZayLdzl6+YfDtXIwbfzo+dgm/nqgXy7fyw8fl2 rlZkvp0vE4tvZ39p0fl2plKe7e7ukfL2MPTtizdvx/Axvohd2Kc3Aq3O/35iwfDmRx8Vhucr xIbh+UpxYRhcgAtwAS7AxWe4qMEFuAAX4AJcgAtwAS7ABbgAF+ACXIALcAEuzhUuGnABLsAF uAAX4AJcgAtwAS7ABbgAF+ACXICLc4WLFlyAC3ABLsAFuAAX4AJcgAtwAS7ABbgAF+DiXOGi AxfgAlyAC3ABLsAFuAAX4AJcgAtwAS7ABbg4V7jowQW4ABfgAlyAC3ABLsAFuAAX4AJcgAtw AS7OFS524AJcgAtwAS7ABbgAF+ACXIALcAEuwAW4ABfnChfX4AJcgAtwAS7ABbgAF+ACXIAL cAEuwAW4ABfnChc34AJcgAtwAS7ABbgAF+ACXIALcAEuwAW4ABfnChe34AJcgAtwAS7ABbgA F+ACXIALcAEuwAW4ABfnChd7cAEuwAW4ABfgAlyAC3ABLsAFuAAX4AJcgItzhYs7cAEuwAW4 ABfgAlyAC3ABLsAFuAAX4AJcgIszhYs+AxfgAlyAC3ABLsAFuAAX4AJcgAtwAS7ABbg4V7jI wQW4ABfgAlyAC3ABLsAFuAAX4AJcgAtwAS7OFS4KcAEuwAW4ABfgAlyAC3ABLsAFuAAX4AJc gItzhYsSXIALcAEuwAW4ABfgAlyAC3ABLsAFuAAX4OJc4aICF+ACXIALcAEuwAW4ABfgAlyA C3ABLsAFuDhXuKjBBbgAF+ACXIALcAEuwAW4ABfgAlyAC3ABLs4VLhpwAS7ABbgAF+ACXIAL cAEuwAW4ABfgAlyAi3OFixZcgAtwAS7ABbgAF+ACXIALcAEuwAW4ABfg4lzhogMX4AJcgAtw AS7ABbgAF+ACXIALcAEuwAW4OFe46MEFuAAX4AJcgAtwAS7ABbgAF+ACXIALcAEuzhUuduAC XIALcAEuwAW4ABfgAlyAC3ABLsAFuAAX5woX1+ACXIALcAEuwAW4ABfgAlyAC3ABLsAFuAAX 5woXN+ACXIALcAEuwAW4ABfgAlyAC3ABLsAFuAAX5woXt+ACXIALcAEuwAW4ABfgAlyAC3AB LsAFuAAX5woXe3ABLsAFuAAX4AJcgAtwAS7ABbgAF+ACXICLc4WLO3ABLsAFuAAX4AJcgAtw AS7ABbgAF+ACXICLM4WLXQYuwAW4ABfgAlyAC3ABLsAFuAAX4AJcgAtwca5wkYMLcAEuwAW4 ABfgAlyAC3ABLsAFuAAX4AJcnCtcFOACXIALcAEuwAW4ABfgAlyAC3ABLsAFuAAX5woXJbgA F+ACXIALcAEuwAW4ABfgAlyAC3ABLsDFucJFBS7ABbgAF+ACXIALcAEuwAW4ABfgAlyAC3Bx rnBRgwtwAS7ABbgAF+ACXIALcAEuwAW4ABfgAlycK1w04AJcgAtwAS7ABbgAF+ACXIALcAEu wAW4ABfnChctuAAX4AJcgAtwAS7ABbgAF+ACXIALcAEuwMW5wkUHLsAFuAAX4AJcgAtwAS7A BbgAF+ACXIALcHGucNGDC3ABLsAFuAAX4AJcgAtwAS7ABbgAF+ACXJwrXOzABbgAF+ACXIAL cAEuwAW4ABfgAlyAC3ABLs4VLq5PgQvh6mmGq6Yuu7b+JlxVX8LV+z/HDVeHUu2KcDX+YJen DVeHGonC1WHsbqtwNVbri+jh6jBsvU24OtTqk4eroUyfFSnD1aFCs0W4GivlWZoQcRi7TBmB DhXadEdfFCkj0KFCt0UEGiuVZfoIdKjTpYlA49hVkToCHao0CSPQWKDO0kegQ50pHbi5+3Jh ercfJyL2L+5evbh9+W5/82H4N0Ptsdj4YV5Q6Og7WHbl3aez4ev9/nasNHwXx2Y23y3ID+PY TZ40xx1K/Hh9Kq7zsvp0Af9w83Y4u76+/e39v4/fiXb8UrTlkuM/+j5Uu9vu/vz06ZhfDBli nJYYfz3jaaRY8Ktvf/xKFM3Nrrs/wb4Zzn5jrPrbu5eHK/ftOPr+dsHozXFCaffX36Wqz4Mv ilXj4N2PX4Ph2lXu+/trw/C7efnh90/RcIgDv718//7loT/Lx/5syTvQlRPxLa+/xLcvL2DM zAt6jb6b+O3c3bVf8tvngRcFuHHgPksb4A41ikcC3HW1YOb5MGIdc+b5MGL3BGaem7rKsjxs 5vkwRmHm2cyzmefngCNVlucb4cinUitw5NMPpsWRqRqxcGR67FQ4MlUtAo5MD5sGR6ZqJcCR 6TIxcWTyl5YERyY/Y5F4YfpVxMSRTY8+Oo5MV0iBI9OV4uPI1PsRC0cmx46OI9NVIuLIVIEU ODLz1YiPI1OFYuHI1NiRcWSiRDwcmexA4uHI1LHHw5Gpg4+GIxODJ8GR6RcRAUemB46AIxMD R8eRTzUexpF6EY58GTEajnwa8UngSB4BR8Yx4Mh3OLJSQJaJx1LQCDCLR7XiNIM40RhO0oPH UeDRaB8SzFfm7hh5Ojw1x4nGIcH34Wz7WEB9KFwGJMglYetP1dJQ9kMAk7VkLVlL1tosa50K /HGuvo+7uqtvIEz/tOvvA5fftVfflJdeF14XXhdeF17ICTmfD3K2kBNyPkXkrBau6zon5nx3 knOevpTqhKgVwTlDotbPS1oRFgedu3P+rwDoXO+cS7LWQuQUtUQtUUvUErXiRK2ZS/uFXs9/ /uX8T1UqON3HWPmadALzxwWkLu4u7i7uLu4u7hz1CTtqz1E5agxHfRhNj9HzRNdcwZnzjPmw Xj7Clg9j5ZxTzuvkihSzOL38KSC4PBJYwtLIbAqZDhgzwWIuUKwKE9+khwXR4NtYIBLEjgRf hv723f/cmAgCgoAgIAgc6kw1/9PN+kSbfd8L7xb1wgs73elm9YHe8oGmcLbBm2vcJpuzpRPY p81bf+rrPrw47ZTywOnkm7PJl3OJU4lTSeJTyZ+qiVPJTOyfSuz355Lr7c8lu3dzZ5OH8uXS c8nmp5LHl76sWfIyFxIfzIghEXF2IctsQtwiID7rfDg737QmH66Kh9+kQ+EwbjiciIaSoWSo nbuwdu704PdQu3bzE9q1B7Lfmn7t7c9v2K7SdWyJUP9h1V+M+mtWJj37ni0G6Qd2bMXWoq9n O7Fnw/maNk3bI03bd+flRcl44cTpbrvzrInTjSdOraB0pnWmNduxerbjPxzn5/v0vE+ZnuvF M6crJk7f/nlBev65sx37zZbEpZju+LnROdl6uHNYDXf107Oz6Y6fMt2hodPQaeg0dF/qBPV0 X+ZE7p78cri3f/79OU+KPM+ubnlTV63v6p7uTQ5P7R6H82nr9h8ifPtP+/InXMG2dkI04Ot/ nkvY/pTs2//ISOc7W7rO8b8ZK3zq1MxpXNE3dSr/yX/y32PvQMhtUPfB7yZPGPyWroVLvhRu aej7+Zo/3/kF5b64nd/Z397+bxd2f/vKlq5n+qmaOqSvpdPSaekeXaMRhfNviqfe1S25uf2n LtE4m7sb5jo655jnfY7Z/uRSLttGLvH97lvcQfUmySkmXWz8CbuizT+7IeLGzhe7J9qL8w2N MuMm2yTLjXKj3HhRuTH6ne831fO98/3qDPcq2m8XDjdd6XHuuxX921WEB2oNg6WEfR2amy81 aBo0Ddr5NWjfVYi67/j3TyS02u7sT+HO4M7gzuCmZr/UiRPEmwVB/Dxvtno6MfzsZ2i3utui 8kiZ026iD98aKbPq7hwfNKnB0+Bp8DR4j9WJ0+S1P2GdTOzZlj8/6ydDaPQu4dEQyR4dWHh2 YECXd/j6P69NxBcvgls3l+r7fWKOC7wzPmtovSVx4pw4J86d35K4eDc7PJDh+s1vpNpK6s9t X6SI8e0n3OXg0e9TNdwZz+hXbXekodPQaej4/I91wnq6V/dN3S4lzC+/DeJpPsPgZzyw+f0Z bXoU1tc5dfww+Pa3sV8/lQeZnPVjQJ/V7NzyfHfJy7DObVdbWH/Oq6+svZLtZLtLyXbbt3M3 T34j22f9WLozWmp1C+u3X4zhfnfLL3R0Ojod3aVofZy27naZ1WfLGrvTr0pNU9TZxLd5f/9B +vN+eKv3f91/dxdYyNjFvtzdf4qGq/Gnr9ju3bvd7y/+Np6yi/GT1O3O8ugPV7Rv1jvfH/3b j+PJYTzuqlx0LZupkODqPFMp+tV58v2IdHWeHru63ke9TM9UiXeZniyQ4DI999WIfpmeLBTp Mj05dtzL9FSJaJfpyeOPd5mePPZol+nJg491mZ4aPMVNbzMvYp/Xhzp/vXv/9QX04/e4Dxv4 uAkYvknjB7IJuSJPzvoP14Qh+7/dffjz+FsZT0L5whpDP/GvV8OH+2pEmP1VN1zdmuquPbQo N1m9pEX5OuKX//zr8Pn+cPXn/bv9YaA/LJxqvB/xX/7hv/3zf/7nf/zj1e7D1a/v3rz58Otw 6vrDpz/866uXrz/+/Q/FL80fyl+yX7Jfb/fXL3evf73+OLfb9s2ff/1714xD/Prbbx9/uflj VRVXP6DDvV/8b//7sgP9Yd6z67r+H/7LPy4b45/e3H58tX9/Nbyuv+xvr16+fnD+9OXN1fWH j++vr65ffdx/GH41f756/er9i48f7rrD39y8rcp2+IgPv7nx/4c/+eKhxwy/H2Xs5dsPu+vh Kzd878alB+Ov5vrVX7743eu5/TE+vnw99EFXdx/f78cxXvzTP/w///W//6f/9g//53/6MuTr 4Rhe333+y9R25Pf/ZvyH2/3dcKCf/reXb18cRhgO+fPfXC+Fwldv/v1qePure+G7evm3Vy9e 7f/95Ocf724++eGHPw9vzdvd7YvdzduXn/7Q326Ht/gAgqdD4/8cXuBfXw7fuXd3f3n56tX4 b8cu7Or34XKwezGeuPcf1qwwGa6Hh3+/e/Xvbx6wyTfj2/R++AS9efFu97eh0Pu3f3l39dvf f3vxt99efq57+MO7m6vXf323e0Qz37752/7di/cf37599fvVOMRfX97u31y9fffmZv/+/Zt3 V9cfP3wYPvaPqOf7f796/+7T390e/nJz++7Nb+OfefEhz25f3h1c9PNn/6EJ76v3N+9fHob4 MJyAftu9+vzX4Zo1fFiHP/jiz0MG23/5m3lVHQl1+LRUfVMvbIP/75fDj+Z5Me+yn/7zL+N/ HU5gf8j/cDhdXf1/8mWllgPvdGvS1MWnRnc4k70eGvU3fxuvL0sp+OEetCp32Zce9Pi8GzZ2 vvvcRw8f7MNVMsqWqdNR9jYMpmeH3TX7+xdx8+fd63/fv5gl7L83YQ3LzLb8w2Vs9+LV7n/9 Pr7lYxjIuyKszGdF/+tvLz6+PpR49XL3/lNEaw5vRRvICt+ssZj9lTVjJwZH4AgcgSNwBI7A ETiyCkcaOAJH4AgcgSNwBI7AETgCR+AIHIEjcASOwJFLxpEWjsAROAJH4AgcgSNwBI7AETgC R+AIHIEjcOSScaSDI3AEjsAROAJH4AgcgSNwBI7AETgCR+AIHLlkHOnhCByBI3AEjsAROAJH 4AgcgSNwBI7AETgCRy4ZR3ZwBI7AETgCR+AIHIEjcASOwBE4AkfgCByBI5eMI9dwBI7AETgC R+AIHIEjcASOwBE4AkfgCByBI5eMIzdwBI7AETgCR+AIHIEjcASOwBE4AkfgCByBI5eMI7dw BI7AETgCR+AIHIEjcASOwBE4AkfgCByBI5eMI3s4AkfgCByBI3AEjsAROAJH4AgcgSNwBI7A kUvGkTs4AkfgCByBI3AEjsAROAJH4AgcgSNwBI7AkQvGkTyDI3AEjsAROAJH4AgcgSNwBI7A ETgCR+AIHLlkHMnhCByBI3AEjsAROAJH4AgcgSNwBI7AETgCRy4ZRwo4AkfgCByBI3AEjsAR OAJH4AgcgSNwBI7AkUvGkRKOwBE4AkfgCByBI3AEjsAROAJH4AgcgSNw5JJxpIIjcASOwBE4 AkfgCByBI3AEjsAROAJH4AgcuWQcqeEIHIEjcASOwBE4AkfgCByBI3AEjsAROAJHLhlHGjgC R+AIHIEjcASOwBE4AkfgCByBI3AEjsCRS8aRFo7AETgCR+AIHIEjcASOwBE4AkfgCByBI3Dk knGkgyNwBI7AETgCR+AIHIEjcASOwBE4AkfgCBy5ZBzp4QgcgSNwBI7AETgCR+AIHIEjcASO wBE4AkcuGUd2cASOwBE4AkfgCByBI3AEjsAROAJH4AgcgSOXjCPXcASOwBE4AkfgCByBI3AE jsAROAJH4AgcgSOXjCM3cASOwBE4AkfgCByBI3AEjsAROAJH4AgcgSOXjCO3cASOwBE4Akfg CByBI3AEjsAROAJH4AgcgSOXjCN7OAJH4AgcgSNwBI7AETgCR+AIHIEjcASOwJFLxpE7OAJH 4AgcgSNwBI7AETgCR+AIHIEjcASOwJELxpEigyNwBI7AETgCR+AIHIEjcASOwBE4AkfgCBy5 ZBzJ4QgcgSNwBI7AETgCR+AIHIEjcASOwBE4AkcuGUcKOAJH4AgcgSNwBI7AETgCR+AIHIEj cASOwJFLxpESjsAROAJH4AgcgSNwBI7AETgCR+AIHIEjcOSScaSCI3AEjsAROAJH4AgcgSNw BI7AETgCR+AIHLlkHKnhCByBI3AEjsAROAJH4AgcgSNwBI7AETgCRy4ZRxo4AkfgCByBI3AE jsAROAJH4AgcgSNwBI7AkUvGkRaOwBE4AkfgCByBI3AEjsAROAJH4AgcgSNw5JJxpIMjcASO wBE4AkfgCByBI3AEjsAROAJH4AgcuWQc6eEIHIEjcASOwBE4AkfgCByBI3AEjsAROAJHLhlH dnAEjsAROAJH4AgcgSNwBI7AETgCR+AIHIEjl4wj11M4Uv4w4txVtZyu3Bd1XjZRrqoLKwRc VRdWWn1VPb3O8qvqsrHXXlUXVll+VV1UIOCquqjOugvSspeyL2/r+5cyvCeHD/CBGIZL6+52 9+fhv4ZC/eEkcNOFVWquPyW+33Z/H2Ll6+9LFONJsrwNq9Deh793uxfvP17/9nL8JeU3U43B soHb7PZTQLr3k09Xj/EK+O7+6Hfj213ftCFlsiarqy9N1N2bUWA/QeHhrDzi4fheDIV2YWUW xZhFY99dd/cfp89X8ftf0PRFfOHY+7vqy8X1ftx+PO3dFWHj3nU3X66t9+NOX1qXjLv20vpI jQcvrV19yqX1eMSl8w6PjHg+8w6PHOhJ8w6PjGHewbyDeYcnM+/wyLf5y7xD+WXe4ebtynmH R0rNzzssunytnHdY1jIsm3dYOHbgvMOiaqfPOywcNmjeYVGt9fMOC8usmHdY9ksLmXc4m5Z3 1bzDeRw9ISEkhISQEBJCcilC0hASQkJICAkhISSEhJAQEkJCSAgJISEkhISQXLyQtISEkBAS QkJICAkhISSEhJAQEkJCSAgJISEkFy8kHSEhJISEkBASQkJICAkhISSEhJAQEkJCSAjJxQtJ T0gICSEhJISEkBASQkJICAkhISSEhJAQEkJy8UKyIySEhJAQEkJCSAgJISEkhISQEBJCQkgI CSG5eCG5JiSEhJAQEkJCSAgJISEkhISQEBJCQkgICSG5eCG5ISSEhJAQEkJCSAgJISEkhISQ EBJCQkgICSG5eCG5JSSEhJAQEkJCSAgJISEkhISQEBJCQkgICSG5eCHZExJCQkgICSEhJISE kBASQkJICAkhISSEhJBcvJDcERJCQkgICSEhJISEkBASQkJICAkhISSEhJBcupD0GSEhJISE kBASQkJICAkhISSEhJAQEkJCSAjJxQtJTkgICSEhJISEkBASQkJICAkhISSEhJAQEkJy8UJS EBJCQkgICSEhJISEkBASQkJICAkhISSEhJBcvJCUhISQEBJCQkgICSEhJISEkBASQkJICAkh ISQXLyQVISEkhISQEBJCQkgICSEhJISEkBASQkJICMnFC0lNSAgJISEkhISQEBJCQkgICSEh JISEkBASQnLxQtIQEkJCSAgJISEkhISQEBJCQkgICSEhJISEkFy8kLSEhJAQEkJCSAgJISEk hISQEBJCQkgICSEhJBcvJB0hISSEhJAQEkJCSAgJISEkhISQEBJCQkgIycULSU9ICAkhISSE hJAQEkJCSAgJISEkhISQEBJCcvFCsiMkhISQEBJCQkgICSEhJISEkBASQkJICAkhuXghuSYk hISQEBJCQkgICSEhJISEkBASQkJICAkhuXghuSEkhISQEBJCQkgICSEhJISEkBASQkJICAkh uXghuSUkhISQEBJCQkgICSEhJISEkBASQkJICAkhuXgh2RMSQkJICAkhISSEhJAQEkJCSAgJ ISEkhISQXLyQ3BESQkJICAkhISSEhJAQEkJCSAgJISEkhISQXLqQ7DJCQkgICSEhJISEkBAS QkJICAkhISSEhJAQkosXkpyQEBJCQkgICSEhJISEkBASQkJICAkhISSE5OKFpCAkhISQEBJC QkgICSEhJISEkBASQkJICAkhuXghKQkJISEkhISQEBJCQkgICSEhJISEkBASQkJILl5IKkJC SAgJISEkhISQEBJCQkgICSEhJISEkBCSixeSmpAQEkJCSAgJISEkhISQEBJCQkgICSEhJITk 4oWkISSEhJAQEkJCSAgJISEkhISQEBJCQkgICSG5eCFpCQkhISSEhJAQEkJCSAgJISEkhISQ EBJCQkguXkg6QkJICAkhISSEhJAQEkJCSAgJISEkhISQEJKLF5KekBASQkJICAkhISSEhJAQ EkJCSAgJISEkhOTihWRHSAgJISEkhISQEBJCQkgICSEhJISEkBASQnLxQnJ9ipAseafz7Jei qcou3aX1gQqRL60PVIp6aZ2uE+fSOj92zEvrA1XiXFpnC0S+tM7WiXdpnX8psS+tD1SKdGl9 oELYpXV+4KiX1tkycS+tD5QJvrTOjh3h0vrA2EGX1gfGDbq0zo0b89L6TY2HLq232cmPift+ xBiTD9+MeN6TD98c6OrJh2/GMPlg8sHkw5OefPjm25x68uGbUssmH2YvXxEnH+ZbhvDJhwfG TjD5MFstbPLhgWGjTz7M1oo7+fBAmUiTD/O/tNiTDz+l5Y02+bD90RMSQkJICAkhISSXIiQN ISEkhISQEBJCQkgICSEhJISEkBASQkJICMnFC0lLSAgJISEkhISQEBJCQkgICSEhJISEkBAS QnLxQtIREkJCSAgJISEkhISQEBJCQkgICSEhJISEkFy8kPSEhJAQEkJCSAgJISEkhISQEBJC QkgICSEhJBcvJDtCQkgICSEhJISEkBASQkJICAkhISSEhJAQkosXkmtCQkgICSEhJISEkBAS QkJICAkhISSEhJAQkosXkhtCQkgICSEhJISEkBASQkJICAkhISSEhJAQkosXkltCQkgICSEh JISEkBASQkJICAkhISSEhJAQkosXkj0hISSEhJAQEkJCSAgJISEkhISQEBJCQkgIycULyR0h ISSEhJAQEkJCSAgJISEkhISQEBJCQkgIyaULSZ4REkJCSAgJISEkhISQEBJCQkgICSEhJISE kFy8kOSEhJAQEkJCSAgJISEkhISQEBJCQkgICSEhJBcvJAUhISSEhJAQEkJCSAgJISEkhISQ EBJCQkgIycULSUlICAkhISSEhJAQEkJCSAgJISEkhISQEBJCcvFCUhESQkJICAkhISSEhJAQ EkJCSAgJISEkhISQXLyQ1ISEkBASQkJICAkhISSEhJAQEkJCSAgJISEkFy8kDSEhJISEkBAS QkJICAkhISSEhJAQEkJCSAjJxQtJS0gICSEhJISEkBASQkJICAkhISSEhJAQEkJy8ULSERJC QkgICSEhJISEkBASQkJICAkhISSEhJBcvJD0hISQEBJCQkgICSEhJISEkBASQkJICAkhISQX LyQ7QkJICAkhISSEhJAQEkJCSAgJISEkhISQEJKLF5JrQkJICAkhISSEhJAQEkJCSAgJISEk hISQEJKLF5IbQkJICAkhISSEhJAQEkJCSAgJISEkhISQEJKLF5JbQkJICAkhISSEhJAQEkJC SAgJISEkhISQEJKLF5I9ISEkhISQEBJCQkgICSEhJISEkBASQkJICMnFC8kdISEkhISQEBJC QkgICSEhJISEkBASQkJICMmlC0mRERJCQkgICSEhJISEkBASQkJICAkhISSEhJBcvJDkhISQ EBJCQkgICSEhJISEkBASQkJICAkhISQXLyQFISEkhISQEBJCQkgICSEhJISEkBASQkJICMnF C0lJSAgJISEkhISQEBJCQkgICSEhJISEkBASQnLxQlIREkJCSAgJISEkhISQEBJCQkgICSEh JISEkFy8kNSEhJAQEkJCSAgJISEkhISQEBJCQkgICSEhJBcvJA0hISSEhJAQEkJCSAgJISEk hISQEBJCQkgIycULSUtICAkhISSEhJAQEkJCSAgJISEkhISQEBJCcvFC0hESQkJICAkhISSE hJAQEkJCSAgJISEkhISQXLyQ9ISEkBASQkJICAkhISSEhJAQEkJCSAgJISEkFy8kO0JCSAgJ ISEkhISQEBJCQkgICSEhJISEkBCSixeS61OEJOi11l2X1XXa1/q5xoOvtSsXaNA3I0bSoM8j nr0GfT7QEA36PAYNokE06Klr0Odv8wYa9LnUYg2avMxE1qDpGnE0aG7sNBo0XS1Yg+aGTaFB 07Wia9BcmXgaNPNLS6BBM5+xKO393KuIp0EbH31kDZqrEF+D5irF1qDp9yOOBs2MHVmD5qpE 06DpAvE1aLpOVA2aeSkJNGiuUjwNmqsQrEEzA8fWoOkycShlbuxQSpkbN5RSzocXKryAF/AC XsALeAEv4AW8gBfwAl7AC3gBL+CFMF6o8QJewAt4AS/gBbyAF/ACXsALeAEv4AW8gBfCeKHB C3gBL+AFvIAX8AJewAt4AS/gBbyAF/ACXgjjhRYv4AW8gBfwAl7AC3gBL+AFvIAX8AJewAt4 IYwXOryAF/ACXsALeAEv4AW8gBfwAl7AC3gBL+CFMF7o8QJewAt4AS/gBbyAF/ACXsALeAEv 4AW8gBfCeGGHF/ACXsALeAEv4AW8gBfwAl7AC3gBL+AFvBDGC9d4AS/gBbyAF/ACXsALeAEv 4AW8gBfwAl7AC2G8cIMX8AJewAt4AS/gBbyAF/ACXsALeAEv4AW8EMYLt3gBL+AFvIAX8AJe wAt4AS/gBbyAF/ACXsALYbywxwt4AS/gBbyAF/ACXsALeAEv4AW8gBfwAl4I44U7vIAX8AJe wAt4AS/gBbyAF/ACXsALeAEv4IUgXugzvIAX8AJewAt4AS/gBbyAF/ACXsALeAEv4IUwXsjx Al7AC3gBL+AFvIAX8AJewAt4AS/gBbyAF8J4ocALeAEv4AW8gBfwAl7AC3gBL+AFvIAX8AJe COOFEi/gBbyAF/ACXsALeAEv4AW8gBfwAl7AC3ghjBcqvIAX8AJewAt4AS/gBbyAF/ACXsAL eAEv4IUwXqjxAl7AC3gBL+AFvIAX8AJewAt4AS/gBbyAF8J4ocELeAEv4AW8gBfwAl7AC3gB L+AFvIAX8AJeCOOFFi/gBbyAF/ACXsALeAEv4AW8gBfwAl7AC3ghjBc6vIAX8AJewAt4AS/g BbyAF/ACXsALeAEv4IUwXujxAl7AC3gBL+AFvIAX8AJewAt4AS/gBbyAF8J4YYcX8AJewAt4 AS/gBbyAF/ACXsALeAEv4AW8EMYL13gBL+AFvIAX8AJewAt4AS/gBbyAF/ACXsALYbxwgxfw Al7AC3gBL+AFvIAX8AJewAt4AS/gBbwQxgu3eAEv4AW8gBfwAl7AC3gBL+AFvIAX8AJewAth vLDHC3gBL+AFvIAX8AJewAt4AS/gBbyAF/ACXgjjhTu8gBfwAl7AC3gBL+AFvIAX8AJewAt4 AS/ghSBe2GV4AS/gBbyAF/ACXsALeAEv4AW8gBfwAl7AC2G8kOMFvIAX8AJewAt4AS/gBbyA F/ACXsALeAEvhPFCgRfwAl7AC3gBL+AFvIAX8AJewAt4AS/gBbwQxgslXsALeAEv4AW8gBfw Al7AC3gBL+AFvIAX8EIYL1R4AS/gBbyAF/ACXsALeAEv4AW8gBfwAl7AC2G8UOMFvIAX8AJe wAt4AS/gBbyAF/ACXsALeAEvhPFCgxfwAl7AC3gBL+AFvIAX8AJewAt4AS/gBbwQxgstXsAL eAEv4AW8gBfwAl7AC3gBL+AFvIAX8EIYL3R4AS/gBbyAF/ACXsALeAEv4AW8gBfwAl7AC2G8 0OMFvIAX8AJewAt4AS/gBbyAF/ACXsALeAEvhPHCDi/gBbyAF/ACXsALeAEv4AW8gBfwAl7A C3ghjBeuF/BCn3VlV8TkhXHEvngCvHA40CaMFw5jdHgBL+CFp88Lw7e5LotNeOFQag0vjD9Y lWl54VCjTcML49h1vhUvHKrF54XDsP02vDDWatLzwqFMn5IXxgptuQUvHCq1aQL6OHaXp+SF Q4Uq3dH3VUpeGCo0WbYFLxwqNel5YayTF2l44TB2m5oXxipFnpAXDgWa9Lww1inzpLxwKHH0 Usquynb37/abj69uh4T4fvgejiFxHLyoTh+8+vGjNJw9ds2nwd++fLt/8bd3Lz9dVovy8O3L F4zdHOfadn/9XRb/PPyiMD4OXh8deFOX+/7+rDf8ul9++P0TKAyN7m8v379/eeg88rHzKMsF daZCf1Z8Cf2fX8Du8AntFwzcT6T+u/ZL6v888KLYPw7cVGlj/6FG+1jsv1kW+5s2ixz7m/Hq /hRif9OGx/6mFfvFfrH/ecT+dmzpt4n97djbr4n9bdclj/1tnyeL/W1fbxj7275PEfuHk8Vm sb/L2i1i/zBs4tjf5dVGsb/Lu2TBuSuKxLG/O85Q8Y7+h9wUP/Z3ZbtR7O9+ANBUsb+rumSx v6uLDWL/EBHSxv6uyTaJ/d1Rxooe+7umSxf7uzZd7O/ahLF/uAptEvu7Y/KME/uHX0+a2N8d 9UrxY383Yu3Dsf92WezvxinvqLG/GzutpxD7+7F3C4z9fVaJ/WK/2P8cYn+fZd1Gsb/PxpS1 IvYPP1iljv1DjWSz/cNJd8PZ/qFaitn+Ydhuq9jfZ2W5QewfyrRpY/9wqcy2if1DpWTz5cPY XdrY32fHUTDe0ddd2tjfZ025TewfKvVbxP4+a6tUsX8Yu0sf+4c+tUga+8f5ry1i//h/iWP/ 8H9Vstg//F+XKvb3+TFFR4v9w+DNFrG/z4/xOUrsHwYuk8T+YeA2dezv8yJ7LPbvF8X+YcTI i/yHEesnEfuHA+1CY3+fl5nYL/aL/c8i9hdjwtom9hcrF/kPP9gnj/3F8Y0E0WJ/MXUDQbLY X9RZithf1NVmsb+ouy1if9EUiWN/0TQbxf6izZIF52LqVoWosb9Id4tCX3Rl4thfdP1Gsb8Y A1rEeF/M5/kHM/hj+TlK7p1KtjOB9JEseUIanAly0zFsJkPNxp759PJtCvmx0f/8JpV19cPV aP5yMXHGnz7LzJ9HHzj/zZ+wZr6wk+eIeBuEBH+H/1SFfzsjfh3rua/jwyD2yLfxrL6MP/mr OPtNPOWLWHfZn6r/+O3bVXyXhJ9HEP6Sgr8mYOH3+YffR04Bl5iNm252f73vc/GyHDwdWycC 5wOp8Gdd5/MFF/p4Tfyzu9C3s333U2q7z/hCf9J1/mruQt9lzXcX+sPdB8/sQu8yf6nG/cgp 4NKu8n0+fb/bd5f4GFf4ZZf4M0vyH5Je4Z/dBb5fleSDr+9O10tP12Ykz+t8nGf5uOXID+fj 1efiYbinfDKeiVuXwKr/Gu90nK9j1ezh0/E5ha1f16etN4mnOB6H1eF11e03eWv85+6i8pa4 9Wzj1iOngAu8vpdNEV9V8+z0y/xfFrnqzMV51YW+ObMJ1OcGq3mWxFXPilV/uFxvN/+ZZ1VX fHeZrrrneAMwGLX4d82l+JFTwKNX6gjn4idxKg44Ez+x+a3HptR/wjKXprk95UzfZt13Z/o2 65/zmX4nkznTJwpdj5wEziOTdXkZdw5sLo8ti2MR2PXvySfBzglez6sB+DlzYCf0AFuuLF9y mY+0xqU55RLfl+V3l/i+rJ7fYlZZ7kKv8I+cAi5OXcezWwJ1nbnMP421rE+WXM9rcjV/Djet BM+unmPW/2Gt6/Ad/HxmtRjlxM920RyC0foclEeZl5q8kTviSTLOxJTlgDHXn5wVhQbe1Jdy 7clJ57+ZFJSX3XcpaPjn+vlB50QKeiMGiUEXGIOqrnscOs/lCs8601pn1BRU1ym4M84GkhPX +UT37keMQS8T3PE31wbUbfZdG1C32WVhqCbAbGe0q/wjJ4Gf3gQcvt2TFhrSBtSnUuhf9j+/ DYgwK/VhzeKT6913W6yuPiFbauiUvNkp+ZFTgHv+Ep6Rv5udinFCTpbL3v286Sk3BMx/CFbu cPjrU9pr5Wff/heSvYqszb+91A//XD7DXdX+T+nLrmp2VRu+3/m41+/MjuOrL/Zzm4Fvvt50 /lJv89SkV/rifLdUO9e9U18mWWkyd50v+u/uKSnKLHvOu6emuqdk4mQ9c3pev2ilqE4/m+7P cU4rdzt1lHNqdfErV37mlNbpS/umz7h1UX13xq2L5tLu4qOoJrZiZKencBdf0RT9KfNay1qB s1nd8oQWt5xJI/Cn6ufnq181A6mbgQfC1+f3rq2/m04d/jl/ls9w1AvoBdzS/+l0XdeRb+kv ughPrjiZWN/9h+cwn5o/s119ir57vf96Ij4+DVvS4gR8GRNZZdZl84/OXX+aLTedyZpdtbLm HPtUnx1wTmfYcmXO2mK36okbCS73dupJcy2L7LvVLMM/l88xaQlarvPQdfyCl1lzWhewrAmI 0gVk4W2Axas/867Cskyxucp5PZ078qqWLde0lFXx3YMrhn/ubaLmUn+el/qFZ+vH7uK7hBm0 LR5CdI7zZ2fwvNdNFid+Pm839XfbwAz/fGlPNnAe98TXS4Hbtp7YBCY62KaaF5tNak9nf7dn t1C27J5BTnv2aDuX4rr2uzsThjcze96rYwS5n9cAPLA7xvAVOOyOcepZp8nq5t+u/vDdvMTN 8M4PF9P9d9tsLBzxX/7hv/3zf/7nfxwy3oerX98NH+Zfhw/WHz794V+H78PHv/+h+KX5Q/lL 9kv26+3++uXu9a/XH1++uv11eLXvbobfw2+3TTWcr17vfx3e8z//OnxbxiF+/P59Ycq/F+Pp rMv/t/992YH+X7t3t8N1d3/1evfb/o9XXdf1//Bf/nHZGM/we/6frr5Ozxy+5l92fbz/gvvK m6Z5bl39p2/z3ETM+EH7dmunfxn/63AC+0P+h8PpakHD/6nU/29466/+3/Es/sdlP3j1r3+6 u//P0ONUTT138/Jvb14P58a2G8+NNyE1Jm7a++68GzZ2vusPY78YP9gPTEYN3fnYnO9Dqn23 AfbnYW/HYe/Cht01+/sXcfPAbYXlmHKauz6k1u1N3Rb3tWbueWyr8RV1RViZm4cC4eGtaLOg X9o+73f3WXD+V9bUQ6Wyug76jEVajDn9KspJyv79xd+ux2/ImEm73Vke/S4rhvYxPEs/UqHe XX9XIcTTH67UZPuvlaIE86n3Y2Y7oL/vy/GV1HXQ2NX1/vZzRp5dqvX3Mg+s8ti2BX+/a0IK XN9ct59P6hGWjc3W2de73RRQvHs3fEXGm7/Hk8d10Kl9ckb6z/vbYfRx8KIKGPzBR4MN376g C2sotzx44E1d7vv7s97ktlCvD3fRjx/VMuxF/DCrc3gBu8MntA8b+MftKMeBq/EtbUKuNWV5 va+LOWf68+GKNp4mrheH9Adifyn2i/1iv9gv9ov9Yr/Y/2xjf5UwOFfJY/95HP3a2F9tFvur jWJ/lTD2V5vE/ip17K82iv1V+thfpYz9VcLYX6WM/dVGsb9KFfurVLG/2iD2VyGxv5qK/VX0 2F89ldhfRYj9ldgv9ov9zyT2V9vF/mpt7K82iP1VwthfbRr7qzSxv9ow9lfbxP4qeeyvxH6x X+wX+8V+sV/s3yr212K/2C/2i/1iv9gv9ov9Yr/YL/aL/WK/2C/2P9fY34j9Yr/YL/aL/WK/ 2C/2i/1iv9gv9ov9Yr/Y/1xjfyv2i/1iv9gv9ov9Yr/YL/aL/WK/2C/2i/1i/3ON/Z3YL/aL /WK/2C/2i/1iv9gv9ov9Yr/YL/aL/c819vdiv9gv9ov9Yr/YL/aL/WK/2C/2i/1iv9gv9j/X 2L8T+8V+sV/sF/vFfrFf7Bf7xX6xX+wX+8V+sf+5xv5rsV/sF/vFfrFf7Bf7xX6xX+wX+8V+ sV/sF/ufa+y/EfvFfrFf7Bf7xX6xX+wX+8V+sV/sF/vFfrH/ucb+W7Ff7Bf7xX6xX+wX+8V+ sV/sF/vFfrFf7Bf7n2vs34v9Yr/YL/aL/WK/2C/2i/1iv9gv9ov9Yr/Y/1xj/53YL/aL/WK/ 2C/2i/1iv9gv9ov9Yr/YL/aL/c809ueZ2C/2i/1iv9gv9ov9Yr/YL/aL/WK/2C/2i/3PNfbn Yr/YL/aL/WK/2C/2i/1iv9gv9ov9Yr/YL/Y/19hfiP1iv9gv9ov9Yr/YL/aL/WK/2C/2i/1i v9j/XGN/KfaL/WK/2C/2i/1iv9gv9ov9Yr/YL/aL/WL/c439ldgv9ov9Yr/YL/aL/WK/2C/2 i/1iv9gv9ov9zzX212K/2C/2i/1iv9gv9ov9Yr/YL/aL/WK/2C/2P9fY34j9Yr/YL/aL/WK/ 2C/2i/1iv9gv9ov9Yr/Y/1xjfyv2i/1iv9gv9ov9Yr/YL/aL/WK/2C/2i/1i/3ON/Z3YL/aL /WK/2C/2i/1iv9gv9ov9Yr/YL/aL/c819vdiv9gv9ov9Yr/YL/aL/WK/2C/2i/1iv9gv9j/X 2L8T+8V+sV/sF/vFfrFf7Bf7xX6xX+wX+8V+sf+5xv5rsV/sF/vFfrFf7Bf7xX6xX+wX+8V+ sV/sF/ufa+y/EfvFfrFf7Bf7xX6xX+wX+8V+sV/sF/vFfrH/ucb+W7Ff7Bf7xX6xX+wX+8V+ sV/sF/vFfrFf7Bf7n2vs34v9Yr/YL/aL/WK/2C/2i/1iv9gv9ov9Yr/Y/1xj/53YL/aL/WK/ 2C/2i/1iv9gv9ov9Yr/YL/aL/c809heZ2C/2i/1iv9gv9ov9Yr/YL/aL/WK/2C/2i/3PNfbn Yr/YL/aL/WK/2C/2i/1iv9gv9ov9Yr/YL/Y/19hfiP1iv9gv9ov9Yr/YL/aL/WK/2C/2i/1i v9j/XGN/KfaL/WK/2C/2i/1iv9gv9ov9Yr/YL/aL/WL/c439ldgv9ov9Yr/YL/aL/WK/2C/2 i/1iv9gv9ov9zzX212K/2C/2i/1iv9gv9ov9Yr/YL/aL/WK/2C/2P9fY34j9Yr/YL/aL/WK/ 2C/2i/1iv9gv9ov9Yr/Y/1xjfyv2i/1iv9gv9ov9Yr/YL/aL/WK/2C/2i/1i/3ON/Z3YL/aL /WK/2C/2i/1iv9gv9ov9Yr/YL/aL/c819vdiv9gv9ov9Yr/YL/aL/WK/2C/2i/1iv9gv9j/X 2L8T+8V+sV/sF/vFfrFf7Bf7xX6xX+wX+8V+sf+5xv7rU2L/lxc7NAq3y15r/ktRD6ecMuVr /VrjwdfalScTx3cjRiGOryOeOXF8PdD1xPF1DMSBOBDH0yaOr9/m5MTxtdRC4pi5zEQljrka MYhjfuwUxDFXLZA45oeNTxxztSITx3yZWMQx+0uLThyzn7EISDD/KmIRx+ZHH5U45ivEJo75 SnGJY+79iEEcs2NHJY75KpGIY65AbOKYqxOROGZfyr68re9fyvCeHD7Ah2boEBV3f/6UF/tD lrvpwio115+uTb/t/j5cAF9/X6Loxzf+NqxCe3+Zejd0rB+vf3s5/pLym/E0UgYN3Ga3n07l 953eJ/DYjc3q/dHvxre7vmlDytxdd/fvxWe1uR99AdrMj72/q75gyv24/XjOuCvCxr3rbp4J L1R4AS/gBbyAF/ACXsALeAEv4AW8gBfwAl7AC2G8UOMFvIAX8AJewAt4AS/gBbyAF/ACXsAL eAEvhPFCgxfwAl7AC3gBL+AFvIAX8AJewAt4AS/gBbwQxgstXsALeAEv4AW8gBfwAl7AC3gB L+AFvIAX8EIYL3R4AS/gBbyAF/ACXsALeAEv4AW8gBfwAl7AC2G80OMFvIAX8AJewAt4AS/g BbyAF/ACXsALeAEvhPHCDi/gBbyAF/ACXsALeAEv4AW8gBfwAl7AC3ghjBeu8QJewAt4AS/g BbyAF/ACXsALeAEv4AW8gBfCeOEGL+AFvIAX8AJewAt4AS/gBbyAF/ACXsALeCGMF27xAl7A C3gBL+AFvIAX8AJewAt4AS/gBbyAF8J4YY8X8AJewAt4AS/gBbyAF/ACXsALeAEv4AW8EMYL d3gBL+AFvIAX8AJewAt4AS/gBbyAF/ACXsALQbzQZ3gBL+AFvIAX8AJewAt4AS/gBbyAF/AC XsALYbyQ4wW8gBfwAl7AC3gBL+AFvIAX8AJewAt4AS+E8UKBF/ACXsALeAEv4AW8gBfwAl7A C3gBL+AFvBDGCyVewAt4AS/gBbyAF/ACXsALeAEv4AW8gBfwQhgvVHgBL+AFvIAX8AJewAt4 AS/gBbyAF/ACXsALYbxQ4wW8gBfwAl7AC3gBL+AFvIAX8AJewAt4AS+E8UKDF/ACXsALeAEv 4AW8gBfwAl7AC3gBL+AFvBDGCy1ewAt4AS/gBbyAF/ACXsALeAEv4AW8gBfwQhgvdHgBL+AF vIAX8AJewAt4AS/gBbyAF/ACXsALYbzQ4wW8gBfwAl7AC3gBL+AFvIAX8AJewAt4AS+E8cIO L+AFvIAX8AJewAt4AS/gBbyAF/ACXsALeCGMF67xAl7AC3gBL+AFvIAX8AJewAt4AS/gBbyA F8J44QYv4AW8gBfwAl7AC3gBL+AFvIAX8AJewAt4IYwXbvECXsALeAEv4AW8gBfwAl7AC3gB L+AFvIAXwnhhjxfwAl7AC3gBL+AFvIAX8AJewAt4AS/gBbwQxgt3eAEv4AW8gBfwAl7AC3gB L+AFvIAX8AJewAtBvLDL8AJewAt4AS/gBbyAF/ACXsALeAEv4AW8gBfCeCHHC3gBL+AFvIAX 8AJewAt4AS/gBbyAF/ACXgjjhQIv4AW8gBfwAl7AC3gBL+AFvIAX8AJewAt4IYwXSryAF/AC XsALeAEv4AW8gBfwAl7AC3gBL+CFMF6o8AJewAt4AS/gBbyAF/ACXsALeAEv4AW8gBfCeKHG C3gBL+AFvIAX8AJewAt4AS/gBbyAF/ACXgjjhQYv4AW8gBfwAl7AC3gBL+AFvIAX8AJewAt4 IYwXWryAF/ACXsALeAEv4AW8gBfwAl7AC3gBL+CFMF7o8AJewAt4AS/gBbyAF/ACXsALeAEv 4AW8gBfCeKHHC3gBL+AFvIAX8AJewAt4AS/gBbyAF/ACXgjjhR1ewAt4AS/gBbyAF/ACXsAL eAEv4AW8gBfwQhgvXJ/CC0GvtSm6Ku/TvtbPNR56rXdZuYBSvhkxEqV8HvHsKeXzgYZQyucx UApKQSlPnVI+f5s3oJTPpRZTyuRlJjKlTNeIQylzY6ehlOlqwZQyN2wKSpmuFZ1S5srEo5SZ X1oCSpn5jEXBiLlXEY9SNj76yJQyVyE+pcxVik0p0+9HHEqZGTsypcxViUYp0wXiU8p0naiU MvNSElDKXKV4lDJXIZhSZgaOTSnTZeJQytzYoZQyN24opZwPL1R4AS/gBbyAF/ACXsALeAEv 4AW8gBfwAl7AC2G8UOMFvIAX8AJewAt4AS/gBbyAF/ACXsALeAEvhPFCgxfwAl7AC3gBL+AF vIAX8AJewAt4AS/gBbwQxgstXsALeAEv4AW8gBfwAl7AC3gBL+AFvIAX8EIYL3R4AS/gBbyA F/ACXsALeAEv4AW8gBfwAl7AC2G80OMFvIAX8AJewAt4AS/gBbyAF/ACXsALeAEvhPHCDi/g BbyAF/ACXsALeAEv4AW8gBfwAl7AC3ghjBeu8QJewAt4AS/gBbyAF/ACXsALeAEv4AW8gBfC eOEGL+AFvIAX8AJewAt4AS/gBbyAF/ACXsALeCGMF27xAl7AC3gBL+AFvIAX8AJewAt4AS/g BbyAF8J4YY8X8AJewAt4AS/gBbyAF/ACXsALeAEv4AW8EMYLd3gBL+AFvIAX8AJewAt4AS/g BbyAF/ACXsALQbyQZ3gBL+AFvIAX8AJewAt4AS/gBbyAF/ACXsALYbyQ4wW8gBfwAl7AC3gB L+AFvIAX8AJewAt4AS+E8UKBF/ACXsALeAEv4AW8gBfwAl7AC3gBL+AFvBDGCyVewAt4AS/g BbyAF/ACXsALeAEv4AW8gBfwQhgvVHgBL+AFvIAX8AJewAt4AS/gBbyAF/ACXsALYbxQ4wW8 gBfwAl7AC3gBL+AFvIAX8AJewAt4AS+E8UKDF/ACXsALeAEv4AW8gBfwAl7AC3gBL+AFvBDG Cy1ewAt4AS/gBbyAF/ACXsALeAEv4AW8gBfwQhgvdHgBL+AFvIAX8AJewAt4AS/gBbyAF/AC XsALYbzQ4wW8gBfwAl7AC3gBL+AFvIAX8AJewAt4AS+E8cIOL+AFvIAX8AJewAt4AS/gBbyA F/ACXsALeCGMF67xAl7AC3gBL+AFvIAX8AJewAt4AS/gBbyAF8J44QYv4AW8gBfwAl7AC3gB L+AFvIAX8AJewAt4IYwXbvECXsALeAEv4AW8gBfwAl7AC3gBL+AFvIAXwnhhjxfwAl7AC3gB L+AFvIAX8AJewAt4AS/gBbwQxgt3eAEv4AW8gBfwAl7AC3gBL+AFvIAX8AJewAtBvFBkeAEv 4AW8gBfwAl7AC3gBL+AFvIAX8AJewAthvJDjBbyAF/ACXsALeAEv4AW8gBfwAl7AC3gBL4Tx QoEX8AJewAt4AS/gBbyAF/ACXsALeAEv4AW8EMYLJV7AC3gBL+AFvIAX8AJewAt4AS/gBbyA F/BCGC9UeAEv4AW8gBfwAl7AC3gBL+AFvIAX8AJewAthvFDjBbyAF/ACXsALeAEv4AW8gBfw Al7AC3gBL4TxQoMX8AJewAt4AS/gBbyAF/ACXsALeAEv4AW8EMYLLV7AC3gBL+AFvIAX8AJe wAt4AS/gBbyAF/BCGC90eAEv4AW8gBfwAl7AC3gBL+AFvIAX8AJewAthvNDjBbyAF/ACXsAL eAEv4AW8gBfwAl7AC3gBL4Txwg4v4AW8gBfwAl7AC3gBL+AFvIAX8AJewAt4IYwXrqd4of5h RIFYIBaIn0wgrqdOCMUvWdZldRM3ED9Saj4QP/KDUQLxohoLA/HCsQMD8aJqpwfihcMGBeJF tdYH4oVlVgTiZb+0kEC87DO2LFIufBUrAvF5HP3aQLywQkAgXlhpdSBe9H4sDMTLxl4biBdW WR6IFxUICMRLvxo3d18uTO/2Y688NMKvXty+fLe/+TD8m6H2WGz8MIcUWpe8F5Uoq/39mzJO Ar4Yqgytz8t3//PF/vXYQI+n9fFUEvS2hIT7ZS/m+ibr77uSv+w/vn3xdviE/TaEjOHX9fLD 77/cvHrzev9L1xw+0eNZLOzjtoYSFlY4nRKWDdxm/f5hSmiuJylhUZk2v8uupz5c99+ZGJ+u 8i7ri2/PKuNb/+Lj2/EX1R3O8n1Q47OQQxaOfTKHLBz3ZA5ZMu5aDnmkxoMc0nWncMjxiEtX Wzwy4vmstnjkQE9abfHIGHAJLsEluASX4BJcgktwCS7BJbgEl+ASXIJLzweXergEl+ASXIJL cAkuwSW4BJfgElyCS3AJLsEluASX1uLSDi7BJbgEl+ASXIJLcAkuwSW4BJfgElyCS3AJLsGl tbh0DZfgElyCS3AJLsEluASX4BJcgktwCS7BJbgEl+DSWly6gUtwCS7BJbgEl+ASXIJLcAku wSW4BJfgElyCS3BpLS7dwiW4BJfgElyCS3AJLsEluASX4BJcgktwCS7BJbi0Fpf2cAkuwSW4 BJfgElyCS3AJLsEluASX4BJcgktwCS6txaU7uASX4BJcgktwCS7BJbgEl+ASXIJLcAkuwSW4 BJdW4lKfwSW4BJfgElyCS3AJLsEluASX4BJcgktwCS7BJbi0FpdyuASX4BJcgktwCS7BJbgE l+ASXIJLcAkuwSW4BJfW4lIBl+ASXIJLcAkuwSW4BJfgElyCS3AJLsEluASX4NJaXCrhElyC S3AJLsEluASX4BJcgktwCS7BJbgEl+ASXFqLSxVcgktwCS7BJbgEl+ASXIJLcAkuwSW4BJfg ElyCS2txqYZLcAkuwSW4BJfgElyCS3AJLsEluASX4BJcgktwaS0uNXAJLsEluASX4BJcgktw CS7BJbgEl+ASXIJLcAkurcWlFi7BJbgEl+ASXIJLcAkuwSW4BJfgElyCS3AJLsGltbjUwSW4 BJfgElyCS3AJLsEluASX4BJcgktwCS7BJbi0Fpd6uASX4BJcgktwCS7BJbgEl+ASXIJLcAku wSW4BJfW4tIOLsEluASX4BJcgktwCS7BJbgEl+ASXIJLcAkuwaW1uHQNl+ASXIJLcAkuwSW4 BJfgElyCS3AJLsEluASX4NJaXLqBS3AJLsEluASX4BJcgktwCS7BJbgEl+ASXIJLcGktLt3C JbgEl+ASXIJLcAkuwSW4BJfgElyCS3AJLsEluLQWl/ZwCS7BJbgEl+ASXIJLcAkuwSW4BJfg ElyCS3AJLq3FpTu4BJfgElyCS3AJLsEluASX4BJcgktwCS7BJbgEl1bi0i6DS3AJLsEluASX 4BJcgktwCS7BJbgEl+ASXIJLcGktLuVwCS7BJbgEl+ASXIJLcAkuwSW4BJfgElyCS3AJLq3F pQIuwSW4BJfgElyCS3AJLsEluASX4BJcgktwCS7BpbW4VMIluASX4BJcgktwCS7BJbgEl+AS XIJLcAkuwSW4tBaXKrgEl+ASXIJLcAkuwSW4BJfgElyCS3AJLsEluASX1uJSDZfgElyCS3AJ LsEluASX4BJcgktwCS7BJbgEl+DSWlxq4BJcgktwCS7BJbgEl+ASXIJLcAkuwSW4BJfgElxa i0stXIJLcAkuwSW4BJfgElyCS3AJLsEluASX4BJcgktrcamDS3AJLsEluASX4BJcgktwCS7B JbgEl+ASXIJLcGktLvVwCS7BJbgEl+ASXIJLcAkuwSW4BJfgElyCS3AJLq3FpR1cgktwCS7B JbgEl+ASXIJLcAkuwSW4BJfgElyCS2tx6XoBLpV9UXV1TFwaR+yfAi4NB1pnWRguHcYo4BJc gktPH5eGb3NTbINLh1LdClwaf7Cs0+LSoUafBpfGsatyK1w6VGuj49I4bJ1vg0uHWm1yXBrL NHlKXDpUqLfApbFSm6XhmcPYZUpcOlRo0x19lxSXxgp9sQUuHSp16XFpqNNmdRpcOozdp8al sUpeJsSlQ4EuPS6NdYpyA1w6FOqS4tJYoiyS4tKhxCa4NFaqsq1w6VCtSolLhwpdAlwaB66L 5Lh0KNOlxaWxxnHHEA+XDuMnwqVx7OMOIRyXDuOW8XHpMG6fFpfGGl3xGC7dLMOlNjoutV33 NHCp7fNgXGp7uASX4NLzwKWu3wyXun4lLvVZkRyX+qxJhkt91m+IS/1xrIqBS33eboZLfZFv gUt9USfGpeH/NsKlviyT8UxfNolxqa/S0Vhfpcalvt4Kl/p6G1zqmyIZLvVNswEu9cdRKi4u 9W21CS71bb8NLvVdmRqX+q5NjUt9n2+ES31fbYhLfd+lxaUyO+6youDSMHCzAS6VWZ6lxqWh RpkSl4bx21S4VGbHTVUMXBrGrVPg0jBuclwqszJ/DJduF+HSMGIVF5eGEdsngUtlVgWvXBrG gEtwCS49C1wq86reCJeGUu0qXBoyRZ4al4YadSpcGsbeEJfK/DgYRsClYdhmK1wq8+NkmACX hjJVWlwaKnTb4FKZd0UqnhnGrtPi0lChT3f0fZ0Wl8oiy7fBpaFSswUulUNfkAqXhrHr9Lg0 VOmT4lJZHK8oSoFLQ51uE1wqi+NlRZFxaSjRJMalsjhm6jS4NFQqt8OloVqbGJeKOk+DS8Vx a5UCl4rjLis6LhXHvVVUXCrSrVwqizQrl4Zxk6xcGsZtk+NS0WWP4dJ+GS4VI9FHxaWiexq3 xQ0H2gfjUjHODcAluASXngEuleP82za4VPbNOlyqsiw5LlVZlQyXqqzdEJeqPE+BS9VxJkyG S9VxMkyBS9VxPoyMS1XRbIRLVZkn45mqrBLjUlV26Y7+hxtK4uNSVWcb4VJV15vgUtVkyXBp 6Nw3wKWq6dLiUtUWm+BSNXnHaAJcqro8NS5VXZUal6qu2wiXqr7YEJcOO68kxaU6y9LgUn3c WqXApTpLfltcWedJb4sbxq+T4VJ93FRFwaW6KJLgUl00yXGpHldHPYxLd8twqb5fCxUPl+px U5CngEv1uMQqEJfqcXcSuASX4NIzwKVmXIe4DS41Y8pbg0vN8W4A0XGpOd4YIBouNdtt6D1W Ow6GMXCpacrNcKlptthzqWzaxHsuDRU22nNpqJRu7U/TJd5zqfxxX6SoRz+1I1JUXJrcCSkJ LrVZtQkuTe2LFAuX2rzYAJfavEmLS+3xXSZJcKk9vuskDS61x7fwxsal9vje3di41JbtRrjU VvmGuNRWdWJcaqs+DS5ts+fSUKZJjkvtcW8VFZfaY3iPhkvtMbdHwaW2zZPgUnvUO8XHpXZc Wf4gLl1ny3CpvV8LFQ+X2rH7egq41HZNMC4dNpiCS3AJLj0DXOrGdYjb4FLXl+twqevb5LjU Z3kyXOqnVkUlw6X+eAYvBi71ebEZLvV5swUu9UWWGJf6otwIl/oi3dqf/nhVVGRc6ss63dFX eWJcmtzVKQkuTe7ulACX+uMd9aPhUn+8KW4CXOqbOi0u9U2/CS5N7O2UBpf6NvWG3mV/vDgq Ni71Xb0RLvXHt/ImxKW+LxPjUt+3SXCpyo5bqwS4NJSpUuPSUKNLiUtVlhepcGkYu0mBS8O4 fQpcqrKj3ik6Lg01Hnta3HW+CJeGEbu4uFQd9oV6ArhUHbabCsOlYYwGLsEluPQccKnKx3WI m+BSlY8pbwUuVXmV/GlxQ41kT4ur8nrDp8UN1VI8La7KpxZEpcGloVa1AS4NZbq0uFTlx/fO pMGloVKytT9V3mVpcWmoUCU8+j4tLlWTuzqlwKVqcnen+LhUFcd78MbCpWHsDZ4WVxWJnxY3 FNjkaXFVURSb4NJQqEmMS1VRZolxaShRbYNLQ6VuO1yqiqpIi0tDhSYNLhUTS6IS4FJx3GVF x6XieHVUVFwqmiwZLhVTq6Ii4FIxtSIqAi4VR71TfFwq2uoxXCqW4dJhp6iouHTYF+op4NJh u6lAXCrGuQG4BJfg0jPApXJch7gNLpV9tg6XyuPnskTHpfL4aSzRcKmaWhWVDJeqrE6BS9Vx JkyGS1VeboFLVd4mxqWqyDfCpapItvZnGLtLjEtVWaQ7+rJLjEuTuzolwaWq6jfBpaqukuFS VXcb4FI18by7qLhUHe+9mwSXqjbfBpeq41t4Y+NSdbw4KjYuVV2xES5Vx7fyJsSlqs8S41LV V2lwqZp40F0CXKqPu6zouFQf91ZRcanO+mS4VOdlElyqp1ZERcCl+mhdeXxcqovyMVwql+FS PfZhUXGpHruvp4BLh+2mAnGpHm+chktwCS49A1xqxnWI2+BSMy6SWoNLzfGsXXRcaqomGS41 dbYhLjXHwTAGLjVTC6IS4VLT5FvgUnN860xkXGqO751JhEvN8TNbovFMc7yncGRcaro83dH/ 8Pzz+Lg0uatTElya3N0pAS61WZkMl9rjxxskwKV24nl3UXGpPd57Nwkutcf37qbBpbaoUuNS W7Spcakt841wqT2+lTchLrVlnxiX2qpMg0vtxJKoBLjUHndZ0XGpPe6touJSW3fJcKltiiS4 1DZ1Elxqj3qn+LjUjqujHsalahkutfdroeLhUjt2X08Blw7bTQXiUjvODcAluASXngEudeM6 xG1wqRtT3hpcOuwLlRiXur5Ohktd32+IS31WpMCl/vhOmWS41OfZFrjU51ViXOrzbiNc6ot0 a3/6ok6MS33Rpzv6sk6MS5O7OiXBpcndnRLgUn/8WPJouNTX9Qa41Nd9Wlzqjx9wkASX+qbb Bpf641t4Y+NSf7w4KjYu9W2/ES71x485SIhLfdcmxqW+z9PgUn/cWqXApf64y4qNS3V23FvF xKVh/CYVLg1/yVLg0vCXMgUuDX9pU+NSnRXZY7hUL8KlYcQiLi4NIz6Np8XVh+2mwnCpzsYb p+ESXIJLTx+X6nxch7gJLg2l6lW4VOfHs3axcanOqzIVLg1jt9vhUp0fB8MIuDQMW22FS0Ot bgNcqvPjuby4uDRUaLbBpXo4qlQ8M4xdpcWloUKb7uh/CIHRcame3NUpBS7Vk7s7xcelujh+ LHksXBrGLtPj0lClS4pLw+Wn2AKXhjrNJrhUF8dLpCLj0lCiSoxLQ4luG1yqi+NbedPh0lCt SYtLdVFlSXBpGLjcAJeGMm1yXCqOe6uouFTUdTJcKuo+CS4VUyuiIuBScdQ7xcelw35RD+NS swyXivEu5qi4dNgX6ing0mG7qUBcKsa5AbgEl+DSM8ClclyHuA0uleOuvWtw6bAvVGJcKvsi GS6VU6uikuFS2fcpcKk6zoTJcKnK2i1wqcrzxLhU5fVGuFTlydb+1FVRJMalqmjSHX1ZJMal yV2dkuBSVZWb4FJVdclwqaqLDXCpOt56Ny4uVcd77ybBpaqpt8Gl6vgW3ti4VB3fuxsbl6q2 3QiXquPHHCTEpaqrEuNS1XVpcKk6bq1S4NLQ9ybHpeq4t4qKS3VWJsOl+ripioJL9dSKqAi4 VB+tK4+PS3XePoZL7TJcqsc+LCouHfaFegq4VI9NXCAu1eON03AJLsGlZ4BLzbgOcRtcasZF UmtwqTmetYuOS02VJcOlpqo2xKXmOBjGwKVmakFUIlxq6noLXGqO5/Ii41JzfO9MIlxqmnRr f5o2T4xLTVunO/ofQmB8XGq6ZiNcmtzdKQEuNcePJY+GS22Wb4BLbVanxaX2eO/dJLjU5uU2 uNQeP94gNi61x883iI1L7fEtvIlwqT2+lTchLrVlmRiX2rJNg0vtxJKoBLjUHndZ0XGpPe6t ouJSWxfJcKmtmyS41E6tiIqAS+1R7xQfl9pxddTDuNQtw6X2fi1UPFxqx+7rKeDSYbupQFxq x4cewyW4BJeeAS5141a62+BS163Epe54v4HouDSxr1M0XOo2XbnU9UlwaXIrp0S4NLG/0wO4 5FrkWuRa9NSvRdUw1vjMgA2uRZ9LLb4Wff7BlNei6RpxrkVzY6e5Fk1XC74WzQ2b4lo0XSv6 RMdcmXgTHTO/tAQTHTOfsShTBXOvIt5Ex8ZHH3miY65C/ImOuUqxJzqm3484Ex0zY0ee6Jir Em2iY7pA/ImO2a9G7ImO6UJRJzqmS0Sd6Jh5WxJMdMy8mEQTHXOvK95Ex1yF4ImOmYFjT3RM l4k70THznkeb6JgeP85Ex9zYoRMdc+OGTnRMjht5ouNzjQcmOtosWzLR8c2IkSY6Po949hMd nw80ZKLj8xhwCS7BJbgEl+ASXIJLcAkuwSW4BJfgElyCS88Hl3q4BJfgElyCS3AJLsEluASX 4BJcgktwCS7BJbgEl9bi0g4uwSW4BJfgElyCS3AJLsEluASX4BJcgktwCS7BpbW4dA2X4BJc gktwCS7BJbgEl+ASXIJLcAkuwSW4BJfg0lpcuoFLcAkuwSW4BJfgElyCS3AJLsEluASX4BJc gktwaS0u3cIluASX4BJcgktwCS7BJbgEl+ASXIJLcAkuwSW4tBaX9nAJLsEluASX4BJcgktw CS7BJbgEl+ASXIJLcAkurcWlO7gEl+ASXIJLcAkuwSW4BJfgElyCS3AJLsEluASXVuJSnsEl uASX4BJcgktwCS7BJbgEl+ASXIJLcAkuwSW4tBaXcrgEl+ASXIJLcAkuwSW4BJfgElyCS3AJ LsEluASX1uJSAZfgElyCS3AJLsEluASX4BJcgktwCS7BJbgEl+DSWlwq4RJcgktwCS7BJbgE l+ASXIJLcAkuwSW4BJfgElxai0sVXIJLcAkuwSW4BJfgElyCS3AJLsEluASX4BJcgktrcamG S3AJLsEluASX4BJcgktwCS7BJbgEl+ASXIJLcGktLjVwCS7BJbgEl+ASXIJLcAkuwSW4BJfg ElyCS3AJLq3FpRYuwSW4BJfgElyCS3AJLsEluASX4BJcgktwCS7BpbW41MEluASX4BJcgktw CS7BJbgEl+ASXIJLcAkuwSW4tBaXergEl+ASXIJLcAkuwSW4BJfgElyCS3AJLsEluASX1uLS Di7BJbgEl+ASXIJLcAkuwSW4BJfgElyCS3AJLsGltbh0DZfgElyCS3AJLsEluASX4BJcgktw CS7BJbgEl+DSWly6gUtwCS7BJbgEl+ASXIJLcAkuwSW4BJfgElyCS3BpLS7dwiW4BJfgElyC S3AJLsEluASX4BJcgktwCS7BJbi0Fpf2cAkuwSW4BJfgElyCS3AJLsEluASX4BJcgktwCS6t xaU7uASX4BJcgktwCS7BJbgEl+ASXIJLcAkuwSW4BJdW4lKRwSW4BJfgElyCS3AJLsEluASX 4BJcgktwCS7BJbi0FpdyuASX4BJcgktwCS7BJbgEl+ASXIJLcAkuwSW4BJfW4lIBl+ASXIJL cAkuwSW4BJfgElyCS3AJLsEluASX4NJaXCrhElyCS3AJLsEluASX4BJcgktwCS7BJbgEl+AS XFqLSxVcgktwCS7BJbgEl+ASXIJLcAkuwSW4BJfgElyCS2txqYZLcAkuwSW4BJfgElyCS3AJ LsEluASX4BJcgktwaS0uNXAJLsEluASX4BJcgktwCS7BJbgEl+ASXIJLcAkurcWlFi7BJbgE l+ASXIJLcAkuwSW4BJfgElyCS3AJLsGltbjUwSW4BJfgElyCS3AJLsEluASX4BJcgktwCS7B Jbi0Fpd6uASX4BJcgktwCS7BJbgEl+ASXIJLcAkuwSW4BJfW4tIOLsEluASX4BJcgktwCS7B JbgEl+ASXIJLcAkuwaW1uHR9Ci4t7Erars27JmVXMlchflcyVyl2VzJRJ1pXMjN25K5krkq0 rmS6QPyuZLpO1GZh5qUkuJLPVYp3bZ2rEHxtnRm4zW53D19bd+2Sa+t0mazJ6upLE3r3ZhTs T9B6OCuP+Dq+F0OhXViZGDFweuw4l9a5sUMvrXPjhl5aJ8eNfGn9XOPBS2u35EGs34wYad7m 84hnP2/z+UBD5m0+j2HexryNeZunPm/z+du8wbzN51KL522mL19x521mWoYo8zZzY6eZt5mu FjxvMzdsinmb6VrR523mysSbt5n5pSWYt9m+5Y05b7Px0RMSQkJICAkhISSXIiQNISEkhISQ EBJCQkgICSEhJISEkBASQkJICMnFC0lLSAgJISEkhISQEBJCQkgICSEhJISEkBASQnLxQtIR EkJCSAgJISEkhISQEBJCQkgICSEhJISEkFy8kPSEhJAQEkJCSAgJISEkhISQEBJCQkgICSEh JBcvJDtCQkgICSEhJISEkBASQkJICAkhISSEhJAQkosXkmtCQkgICSEhJISEkBASQkJICAkh ISSEhJAQkosXkhtCQkgICSEhJISEkBASQkJICAkhISSEhJAQkosXkltCQkgICSEhJISEkBAS QkJICAkhISSEhJAQkosXkj0hISSEhJAQEkJCSAgJISEkhISQEBJCQkgIycULyR0hISSEhJAQ EkJCSAgJISEkhISQEBJCQkgIyaULSZ8REkJCSAgJISEkhISQEBJCQkgICSEhJISEkFy8kOSE hJAQEkJCSAgJISEkhISQEBJCQkgICSEhJBcvJAUhISSEhJAQEkJCSAgJISEkhISQEBJCQkgI ycULSUlICAkhISSEhJAQEkJCSAgJISEkhISQEBJCcvFCUhESQkJICAkhISSEhJAQEkJCSAgJ ISEkhISQXLyQ1ISEkBASQkJICAkhISSEhJAQEkJCSAgJISEkFy8kDSEhJISEkBASQkJICAkh ISSEhJAQEkJCSAjJxQtJS0gICSEhJISEkBASQkJICAkhISSEhJAQEkJy8ULSERJCQkgICSEh JISEkBASQkJICAkhISSEhJBcvJD0hISQEBJCQkgICSEhJISEkBASQkJICAkhISQXLyQ7QkJI CAkhISSEhJAQEkJCSAgJISEkhISQEJKLF5JrQkJICAkhISSEhJAQEkJCSAgJISEkhISQEJKL F5IbQkJICAkhISSEhJAQEkJCSAgJISEkhISQEJKLF5JbQkJICAkhISSEhJAQEkJCSAgJISEk hISQEJKLF5I9ISEkhISQEBJCQkgICSEhJISEkBASQkJICMnFC8kdISEkhISQEBJCQkgICSEh JISEkBASQkJICMmlC8kuIySEhJAQEkJCSAgJISEkhISQEBJCQkgICSG5eCHJCQkhISSEhJAQ EkJCSAgJISEkhISQEBJCQkguXkgKQkJICAkhISSEhJAQEkJCSAgJISEkhISQEJKLF5KSkBAS QkJICAkhISSEhJAQEkJCSAgJISEkhOTihaQiJISEkBASQkJICAkhISSEhJAQEkJCSAgJIbl4 IakJCSEhJISEkBASQkJICAkhISSEhJAQEkJCSC5eSBpCQkgICSEhJISEkBASQkJICAkhISSE hJAQkosXkpaQEBJCQkgICSEhJISEkBASQkJICAkhISSE5OKFpCMkhISQEBJCQkgICSEhJISE kBASQkJICAkhuXgh6QkJISEkhISQEBJCQkgICSEhJISEkBASQkJILl5IdoSEkBASQkJICAkh ISSEhJAQEkJCSAgJISEkFy8k11NC0kyNWP6St3VV5quE5IERq/ychOShA61PFJKHxmgJCSEh JE9ISOa/zUPujCskD5WqHxKSB36wKyIJyUM1QoXkgbH7LLqQPFStXi8kDw3bRRaS+VpNVsUT kofKdFGE5IEKeRFVSB6qFNryPjB2kUURkocqVOmOviyjCMlDFfqoQvJApaqOKCQP1KmLQCF5 aOx4QvJAlSaLISQPFYgpJA/UafM4QvJQibhC8kClLosiJA9VqEKE5KGBu3hC8kCZvognJA+V SXe5aLM8UEgeGrsOEJKHxu0ChOSBcfMqkpA8VONRIblZJiRt3kcWkrYonoaQtEW4kLQFISEk hOR5CElXbiYkXVmtE5Ku7JILSVcVyYSkq5oNhWT4mxRC0tXlZkLS1e0WQtI1eWIh6Zp6IyHp mj5Zy9u1ZWIh6do23dH/4KvxhaT7ITylE5KurzYRkq7vkwlJn5UbCEmftWmFpM/zTYSkz+vU QtIX2UZC0hdVYiHpiy6NkPRlvoWQ9GW9hZD0ZbrLRV+VyYSkr9okQtIfN01RhKSv0wtJP3ZL DwvJ7TIh6evYQtI3T0RIxvAUKiR9Q0gICSF5FkLSZGOy2kRImmycDVshJMMP1qmFZKjRpRKS JuuK7YRkqJZiDckwbL+VkDRZX24gJEOZJq2QNMMbvY2QDJWSrcIYxm7TCkmTH8fNeEefN2mF pMmLYhshGSq1WwhJk5fJ1pAMY2+whmSo0icVkiY/zoEphGSo0yUWkiY/XjGURkiGSk1aIRkq 9EmEpMmbcgMhGco0GwhJM1zE0p1w2yqVkAxjJxGSJu/yFEIyjJtcSIYajwrJfpGQDCNGFpIm 75+GkAwHGiwkwxiEhJAQkuchJMU4/7mNkBTjzSZrhKQ4DszRhaTo22RCUh4vO00oJOVxVo4h JOVETE4lJGWebyEk5fH0bGQhKfN+IyEpiyJZy1sWTWIhKYs+3dGXdWIhKat8IyEpq2YTISnr PJmQlEfTqimEpKy7tEJSHme1JEJSHvN6bCEpu43usmnKPvFdNkOFNHfZDAO3WwhJNdErJBCS KquTnXCrPEsmJFVeJRGSKk9yl01TFWVyIamKR++yuVsmJFURW0iq8VbXpyAkVdkGC0k16jwh ISSE5BkIyXAm3UpI6nHx2RohqY9vxY4uJPXxOpVoQlK3/YZCUndJhKTuNtuHpKm3WUNS921i IWmO+91EQtJkyW4sb5o88T4kQ4V0DXtT5ImFpJla2ZFESJpyk7tsmqZMdpdN01Qb3GUzVEks JE29zRqSpk6+hqRptlpD0jRtYiGZ2LYljpA0xw1CCiGZ2KklhZBMbNcS74R7vNo0mpA0fZlE SJq+TSIkbVYkF5LD3iwPCsl1tkxIDruyRBWSNn8aO7UOBxq+hqTNrSEhJITkeQjJYf+NbYSk q9btQzL8YJ9cSCa22YgmJBPbaiQUkondNWIIydSWGqmEpDteA5xCSLq2SiwkXbvVGpKuK5O1 vF2X+i6brk+3Aqbru8RC0mfVRkLy4+YXqYSkz5tkQjKx60UCIemLOq2Q9MfLnpIIycTGFLGF ZGJTikRC0leJ9yEZKqTZh6TpJ25FSiAk/USvkEBI+ibdbY190yQTkr7NkghJP3VnUAQh6Y9u 3o4vJH2XPyYk+TIh6Uc/iyok/Ti/9hSEpO/zYCHpR8YjJISEkDx9IWmzcd3rJkIylCpWCcnw g8n3IRlq9KmEpM2zcjshGao1CYRkGHazfUjaPN9iDclQJvEakjYvNlpDMlRKtgpjGLtLKyRt Xubpjr5s0wpJ++OWFMmEpP1xU4pEQtLmx14cS0jafItn2bR54mfZDAWqLYRkqNMnFpI2P96J OY2QDJUS70PS5lNPy4kgJG0+8ZCc+ELS5t0WQtLmfcITbl+nEpJh7D6FkLTF0VqPKEIyjNuk FpKhRveYkBSLhKQtxkWjMYVkGPFp3GUzHGgTKiTDGB0hISSE5FkISZlvJiRlvlJIJvaLiC4k EztGRBOSqT0i0gnJ1K4REYRkYquIZEJSlpsISVmmFpKy2min1qFSsmXTw9iphWRi34t4R1+n FpKy2Win1qHSNkJStsl2ah3G3kJIyi6xkJTdNkJSdqnvsmnLfqO7bIZKqYWkyhIJSZVtsVPr UGYTIanSbY3dTu4VEklIJvcLiSAkVZFkp9Zh3Dq5kFTFo0JSLhOSqowtJE9lH5LhQMOF5LCX CSEhJITkGQhJPc7ebiMk9XiWXCMk9XGSjS4kdZUnE5J6Ir2mE5J6Is9GEJK6zjcTkrqutxCS +vi5B5GFpD6+wz+RkNRNsn1I2rpNvA/JUKFMePR9YiH5ceefdEJS/7DTZSohqY/3u4wmJHXf bSAkzfGkcFwhmdj4J4mQTGwCFFtImrzaSEiavEssJE2RZh+SYeAt9iEZt4zfQkiaMtltjcPY ye6yGbeYTSIkzdQTiiMISXP0dOL4QtJU/WNCUi0TkqbOIwtJM27P/RSEpKmDd2odN7gjJISE kDwLIWnrzdaQtPXKNSTt8brs6ELS1unWkLTNlnfZtE2SNSRts90akrbdZA1J26ZeQ9J2W91l 06bbem8YO/Uakjbhou+2T72GpMu2WkPSZdusIenydGtIunyLNSRdkXgNSVdss4akK5KvIenK rdaQdGXqNSRdlWgNSVdtsoakqzZZQ9LVyZ72O4ydbg1JV6dZQzKxeVsUIema5E/7HWo89rTf 63qZkHRN5GfZtF37NJ72Oxxo8E6twxgNISEkhORZCEnfbPW03/awy9YaIenb5E/7HWoke9pv 20/sT59OSPokz7IZht3sab9t32/xtN+hTOKn/Q4Vum2EpMuyZJOCw9iJn/Y7VOjTHX2e+Gm/ w2U020ZIhkqbPO23y8oslZAMY2/wtN+hStpn2XRZVWwhJEOdJrGQdFmdbSMkQ6XEO7UOFdok QtJlxxk6gZAMZeoNhGQo06U74bZFKiEZxm5SCMkwbp9CSLqsS/4sm6HGo8+yaRYJyTBiG1dI usN2h09ASIYDLUOFpDvsm0hICAkhefpC0uVds5GQDKW6VULSTWwrFltIuontxWIJyTB2t52Q dBObjkUQkmHYzZ5lM9TqNxCSrpjaEDamkHRF3mwkJEWRbFJwGLtKLCRF0aY7+rJMLCRF2W0k JEW1ydN+hzpdMiEp6mIDISmm9oONKSTF8VawSYSkON4RNraQFE23kZAUbZFYSIqJh/JGEZLi OEOnEJJi6plk8YWk6Jp0J9w+SyYkRV8lEZIizdN+uzLLkwtJOe6Q87CQtMuEpLx/fnA8ISmz p/Esm67Mg59lM4zhWTaEhJA8DyGpxidVbiMk1TgVvUZIqiz50367Kk/2tN9h7GZDIamOs3IM IamKcjMhqYp2CyGpyjyxkFRltZGQVGW6ScGqKhILSVXV6Y6+zhMLSVU3GwlJNbUnbAIhqZpk T/vtqnaDp/0OVaq0QlK13SZCUh3NQkcXkqprNhKSqs8SC0nVV2mEpDrO0CmEpM7yLYSkzpLd lDn8tUsmJHVeJBGSOq9PFJJv/9j4p0JL993ndYFzIvOdnow/MN4U962ITAvGpD2s0YN/PP2l jI3CdLqfz+kPRO/5GD2Xj6cC77IMe1JUPTGALo6Wc1HywVy4IO71/Thd9DXuLUtw/eHJ80sS 3FxGW5eo/jQfk6ZyzkQmmQoQ3zb+M7//R2L56W/AOJn27a4Wi37/4w8v3slz5h1Y+QZUDwTV 096Cx96B2eh1aob6j19/XdXXp69kJ/+OP+fcP1XfjvQ1kC69Hg4/XH4bMX5s1b8pE95dD8Um nkIZu7seq7Qnd9fLm+th/IkFuxPN9Ze2+pSW+k/Vp5GHq23Cbnqo0D6+Ivv+f4rV/X4u3KVo fcfp8vyHrudT5/ul7Q3sescKG6ycHsukulVlGLtPdW/5OHaKe8u7ok7yBMdx3Ind975vY4c/ dP/AxM9t7Mw83HEbu2oG7B9PP/ii+LelPeyHVU3s/5juYicnbRI0sR9TdbGz8yGR2tghMY17 Yq3toppm6W5fs1MNZ9THnubXJ3ZR37Q+7dcn1Jx+MmzvTwDfNVHtl+y+/OzaftnAdsNeqq2K DXqptkq6lmtcM5SfKJWL+ql//TR26naqnWgFU+DkWCntFkBDhTZP06G17QabJA9lJm6GT9Cm pdsxbhy7T9amtUmWb43jdknatC6bvcHtx2aty+oTmrVo5LigXevydqZdu4rdr82gY3i/FrNd i2aOL6J1a329Hh3Hn37a6Hjcq6Vq1fqvs2unnxD7+5PWd63a170vvpxhJ85soSe2qmnaB6c+ fjgLffrzayLjH1LOe3w6rsXnoJiR8fVZzXssD4zrzkEvFpyEPn12Pp+Elp2CPv1slMQY+xyU OC8uR/ev3+kFJ6EvP/TtSei7kZb2eVXz3bKeJEHxT9PHmi4qTleJGBWnCsSKip/GThkVJ48+ SVScrhQzKk5XiBAVJweOHxWnyiSIitNl4kTFqbFjRcXpscOj4vS44VFxYtzpqHjcoy1YnZI2 KUbv0m7Otk37uPX6lCfbp8VdHxHYpm2WFMOatJkebU2T1jyg+RfQoyVs0fRnz7k/055pz05q z9YJ2pMAtHWd2erG7MV2c+599eWxRid/Hfrqfhupby/P/beLkhZ/w/p6u7n2vs779Bfnvi7K pIAyFDgRUBZfn/t6vFsx5fV5qFBvc30eKqV9HvFQYWKL3xjX52HgOtn1+ZtudaizwQOJhzJ1 qifAj2OneiDxMHaT4oHE47gpHkg8jjt1hf5+Y5TDH/vumcKnT3CVSS/Qfd32/xbxxp6bOHf2 vH4Gt/ZEm2bvm7ZcvShy+OH6TG8tmbSTn3pjSd9+vVvw9LNhe+hwvmvP2q/tyPKza3vY5/+b Fi1xh9ZusLPdWCXtasi+TXBryb9+GjjxZv9DiXajtZD91ILCuA3axFrCOA3axOrBBBNc/cSj Z1P0Z22frj9r+2SC0ndZnqQ/67IqSX/WHd20/nUru6MurTvp1pXtp7j68dmyc7urxYWUn3wD drp7V9JPcfX9uAvf2katz5fdAxx3JVL8xZAndmn5ijat/xLVTz8n9vd7A3/Xp/XftD7LT7On OlqMJq1vmw2atG8fivftWS7p2a0v6jpqCF16bjuvdd6bndpOP7P1RVOv3t1g/OEiUgT9Lf72 BpE2mAhNof/xm19XtziEjj90dHob/uXXJ1AsPbuNP9yednrr15/fvjnWNk9/ghuqFFnKFDoW qNLME4xDd2lz6FCiLDbJoWOltPfkDRWqJDl0HLhMn0PHMu0PmzPEj6FDlTrVAzjGsVPtnDCO nWIiv5+6KzVCDB3HrU67JW/8o2tvhkk6VzAc2NiD/sxdwNwM89hb1K1eZDn+bL94G+efOFXw Nl4KXRxB+6L/wmCnnw/7+2dRfdej9V99avkZts+Tt2jfFCvLDTq0vmzTdmh9lafq0A4ukbRB 648XDyRq0Prj9QORG7S+btI0aP3EM47uG7R47VnfbPDEm7FMm6w/69ssWX/Wt1WS/qxv2yT9 Wd9NPvHmx96s78oN97aqT+/N+r68jDuVI+6W8FRXhPRlXmSrN164/+knfNfz2ttpfl1scZ9+ VcvavC8/822b9+1AS8/Tw8+edDdNjCbvm+NM2ORNV4nY5E0WCF8Lcj9uyg5v6sjTdHjTlWJ2 eNMVInR4kwP/0OGFNnhTNRI0eNNl4jR4U2PHavCmxw5v8KbHDW/wJsb9BHDfdXj3f+zxu5xj 3Ulz+iTp4ci2ucs51TTpiQ+LOy9+W92WPe+m7GfuXfoU2rJn35dF6squ47Vl+rKz7cviuZu2 7DLasv/4b+sas3Pqy9ZtU3rztKdFo3FZtEnRH7QseV+Wnf/DkR7uy8LPaLEfxTlTIcGjOGcq RX8U53SvFedRnM9Z8RI8ilP7+ARY7/+rhdRCLm0hP437Yf/b4U38/m6v8Vu1sMa33efQWHXD Ja6p7trbrGvaPKsPTejiEb/8Z5IZF4/4L//w3/75P//zP/5xaKCufn335s2HX4cP9NTu/dkv 2a+3++uXu9e/Xn98+er21/dvPo6f+t1vQ4M0nE5f73/dvbv5869/75pxiF9/++3jLzd/rKpi pos5ZTr72wP9v3bvbocOaX/1evfb/o9XXdf1//BflnXdV//05vbj2CcPr+sv+9url6//OLSQ v7/9cHu1G07Ww5G/GHq98W/vzx1X1x8+vr++un71cf/hzdztdHfDb278/+FPvnj/4c274bR8 9XH3/urvH158uHn78fbt+Hdv//z7+6G//tLCz3f6X/7+0+lk/Nu7oZl9+Xpohq7uPr7fj2O8 +Kd/+H/+63//Tw+lgjevX48fu7+8ePn2r9V3/2b8h9v93XCgn/63l28/54f5Ofzr26tXb968 vfofb34fX8YhONyOPf3tfuj5X+9evfn3q+Htn7kX8PBnX77+sH919frNx7/udx+/H2G4zNx0 QxucDw388NZMwvGQNG6Gjv/u3z/9wf1fPx/HEF0Of/3w8rfhN3r/b5aEmffvbq5u3/324i+/ vX/x5/2rt8Mowz8e0sxJ/nx7SDbjvz78zdv3v70Z36b3wydouOjs/jYUev/2L++uTsxDn/7+ +uWb4W0Y+vH9u9+v3r75237oyz++ffvq96txiL++XPMsrvf/fvX+3ae/u33g4Vz3n/3x79++ fPn3q92Qn4avzPWXv37YXb2/ef/yMMR94nroqajj3wyXsmw/fkUOr/pfXw1n1quPr1+92d3u h5g1fFqqPmA9w/9xNT6D64/DUb29+n934wdt+F/+8er+P/8y/tfhBPaH/A+H01XiPDd7+aqa +SeIvXk9nBvbbjw3BjWiWVXusi+dyeL0+MjY+e5zMz18sB94BuyQpsYL5j6k2g/Ldz8NezsO exc27O6+9ZzKvvsPL25evRsrlWOL1dz1IbVub+q2mFpkvN+9eLX7X7+Pb3k1vqKuCCvzyEKW 4b/boGbxoVXOX39lzdiJldX1uba8xb7cfXrrx4P+FNF2797tfn/xtzE2F6M0dOfZsBMSQkJI CAkhISSXIiQNISEkhISQEBJCQkgICSEhJISEkBASQkJICMnFC0lLSAgJISEkhISQEBJCQkgI CSEhJISEkBASQnLxQtIREkJCSAgJISEkhISQEBJCQkgICSEhJISEkFy8kPSEhJAQEkJCSAgJ ISEkhISQEBJCQkgICSEhJBcvJDtCQkgICSEhJISEkBASQkJICAkhISSEhJAQkosXkmtCQkgI CSEhJISEkBASQkJICAkhISSEhJAQkosXkhtCQkgICSEhJISEkBASQkJICAkhISSEhJAQkosX kltCQkgICSEhJISEkBASQkJICAkhISSEhJAQkosXkj0hISSEhJAQEkJCSAgJISEkhISQEBJC QkgIycULyR0hISSEhJAQEkJCSAgJISEkhISQEBJCQkgIyaULSZ4REkJCSAgJISEkhISQEBJC QkgICSEhJISEkFy8kOSEhJAQEkJCSAgJISEkhISQEBJCQkgICSEhJBcvJAUhISSEhJAQEkJC SAgJISEkhISQEBJCQkgIycULSUlICAkhISSEhJAQEkJCSAgJISEkhISQEBJCcvFCUhESQkJI CAkhISSEhJAQEkJCSAgJISEkhISQXLyQ1ISEkBASQkJICAkhISSEhJAQEkJCSAgJISEkFy8k DSEhJISEkBASQkJICAkhISSEhJAQEkJCSAjJxQtJS0gICSEhJISEkBASQkJICAkhISSEhJAQ EkJy8ULSERJCQkgICSEhJISEkBASQkJICAkhISSEhJBcvJD0hISQEBJCQkgICSEhJISEkBAS QkJICAkhISQXLyQ7QkJICAkhISSEhJAQEkJCSAgJISEkhISQEJKLF5JrQkJICAkhISSEhJAQ EkJCSAgJISEkhISQEJKLF5IbQkJICAkhISSEhJAQEkJCSAgJISEkhISQEJKLF5JbQkJICAkh ISSEhJAQEkJCSAgJISEkhISQEJKLF5I9ISEkhISQEBJCQkgICSEhJISEkBASQkJICMnFC8kd ISEkhISQEBJCQkgICSEhJISEkBASQkJICMmlC0mRERJCQkgICSEhJISEkBASQkJICAkhISSE hJBcvJDkhISQEBJCQkgICSEhJISEkBASQkJICAkhISQXLyQFISEkhISQEBJCQkgICSEhJISE kBASQkJICMnFC0lJSAgJISEkhISQEBJCQkgICSEhJISEkBASQnLxQlIREkJCSAgJISEkhISQ EBJCQkgICSEhJISEkFy8kNSEhJAQEkJCSAgJISEkhISQEBJCQkgICSEhJBcvJA0hISSEhJAQ EkJCSAgJISEkhISQEBJCQkgIycULSUtICAkhISSEhJAQEkJCSAgJISEkhISQEBJCcvFC0hES QkJICAkhISSEhJAQEkJCSAgJISEkhISQXLyQ9ISEkBASQkJICAkhISSEhJAQEkJCSAgJISEk Fy8kO0JCSAgJISEkhISQEBJCQkgICSEhJISEkBCSixeS61OE5EKy1OMZ6rEEtCLF1FXVnRxH xj+clz98bpaljnppcKirmdKnN+7f/Wyx5qUuaq8//ejCfnnVOW3y/Rha4FXd7neDrT+AL13s w39isgtd2Hcexl7cRX46oiW94Q+v4fR2b/r9uTm1mfv2x1cVXPNDi5uoP63oh74vubTpmfi1 Tvc3M5f25VfjoKvttxfWJYT/HdVvbfKff8chJv95jHmTDyb5rxr/heIhPITfFOE/9Y2zTeJ3 zd50jzfX1y3s51b1ccnbt5n+bcv2bUX/9tPat+DeLbh1W9a4bdazre/YNGyRG7YYHVuXJ+7Z 6qCmbfKIIxPJ5xoPEklXLlhE8s2IkRaRfB7x7BeRbNOwWkSif7WI5GksIvn8bd5gEcnnUqv4 9bjhiLuIZLpGnEUkc2OnWUQy452hi0jmhk2xiGS6VvRFJHNl4i0imbPn+ItIZj5jUWYF515F vEUkGx995EUki/g+aBHJXKXYi0hmIl6URSQzY0deRDJXJdoikukC8ReRTNeJuohk5qUkWEQy VyneIpK5CsGLSGYGjr2IZLpMnBUYc2OHrsCYGzd0Bcb58EKFF/ACXsALeAEv4AW8gBfwAl7A C3gBL+AFvBDGCzVewAt4AS/gBbyAF/ACXsALeAEv4AW8gBfwQhgvNHgBL+AFvIAX8AJewAt4 AS/gBbyAF/ACXsALYbzQ4gW8gBfwAl7AC3gBL+AFvIAX8AJewAt4AS+E8UKHF/ACXsALeAEv 4AW8gBfwAl7AC3gBL+AFvBDGCz1ewAt4AS/gBbyAF/ACXsALeAEv4AW8gBfwQhgv7PACXsAL eAEv4AW8gBfwAl7AC3gBL+AFvIAXwnjhGi/gBbyAF/ACXsALeAEv4AW8gBfwAl7AC3ghjBdu 8AJewAt4AS/gBbyAF/ACXsALeAEv4AW8gBfCeOEWL+AFvIAX8AJewAt4AS/gBbyAF/ACXsAL eCGMF/Z4AS/gBbyAF/ACXsALeAEv4AW8gBfwAl7AC2G8cIcX8AJewAt4AS/gBbyAF/ACXsAL eAEv4AW8EMQLfYYX8AJewAt4AS/gBbyAF/ACXsALeAEv4AW8EMYLOV7AC3gBL+AFvIAX8AJe wAt4AS/gBbyAF/BCGC8UeAEv4AW8gBfwAl7AC3gBL+AFvIAX8AJewAthvFDiBbyAF/ACXsAL eAEv4AW8gBfwAl7AC3gBL4TxQoUX8AJewAt4AS/gBbyAF/ACXsALeAEv4AW8EMYLNV7AC3gB L+AFvIAX8AJewAt4AS/gBbyAF/BCGC80eAEv4AW8gBfwAl7AC3gBL+AFvIAX8AJewAthvNDi BbyAF/ACXsALeAEv4AW8gBfwAl7AC3gBL4TxQocX8AJewAt4AS/gBbyAF/ACXsALeAEv4AW8 EMYLPV7AC3gBL+AFvIAX8AJewAt4AS/gBbyAF/BCGC/s8AJewAt4AS/gBbyAF/ACXsALeAEv 4AW8gBfCeOEaL+AFvIAX8AJewAt4AS/gBbyAF/ACXsALeCGMF27wAl7AC3gBL+AFvIAX8AJe wAt4AS/gBbyAF8J44RYv4AW8gBfwAl7AC3gBL+AFvIAX8AJewAt4IYwX9ngBL+AFvIAX8AJe wAt4AS/gBbyAF/ACXsALYbxwhxfwAl7AC3gBL+AFvIAX8AJewAt4AS/gBbwQxAu7DC/gBbyA F/ACXsALeAEv4AW8gBfwAl7AC3ghjBdyvIAX8AJewAt4AS/gBbyAF/ACXsALeAEv4IUwXijw Al7AC3gBL+AFvIAX8AJewAt4AS/gBbyAF8J4ocQLeAEv4AW8gBfwAl7AC3gBL+AFvIAX8AJe COOFCi/gBbyAF/ACXsALeAEv4AW8gBfwAl7AC3ghjBdqvIAX8AJewAt4AS/gBbyAF/ACXsAL eAEv4IUwXmjwAl7AC3gBL+AFvIAX8AJewAt4AS/gBbyAF8J4ocULeAEv4AW8gBfwAl7AC3gB L+AFvIAX8AJeCOOFDi/gBbyAF/ACXsALeAEv4AW8gBfwAl7AC3ghjBd6vIAX8AJewAsLeaFp 267bhheGUn22hhfGH2wS80LTdlmWiBfGsevNeGGolufxeWEctt6IF4ZaRZaeF8YyVVJeGCv0 m/DCUKlMFdDHsdukvDBUqIp0R191SXlhqFDXm/DCUKnJN+CFsU6biBeGsds8OS+MVZqUvDAU 6PINeGGs06TlhaFEn23CC2OlOikvNEOPkaXghXHgKj0vjGX6RLwwjJ2EF8Zx2wS8MIxbFIl5 YaxRP8YLuyW8MI7YReWFYcSyeAq8MB5oHcgL4xgtXsALeOE58EKXNRutXhhLNat4ocvaLDUv DDXqVLwwjN1vxwtd1iVYvTAO227FC13WFxvwwlCmTcsLw4D5NrwwDNykCuhdnmdpeWGoUKU7 +iJPywtDhXYbXhj662oLXhjq9Kl4ocur9KsXxipdUl7o8nqL1QtjnS4xL3R5s83qhbFSm5YX urwtkvDCMHCzAS90+bFaxeKFYew6BS8M4/YpeKHL+yo1Lww12sd44XqKF9ofRhSIBWKB+MkE 4nb6hNDfN7sxA/EjpeYD8SM/GCUQL6qxMBAvHDswEC+qdnogXjhsUCBeVGt9IF5YZkUgXvZL CwnEyz5jyyLlwlexIhCfx9GvDcQLKwQE4oWVVgfiRe/HwkC8bOy1gXhhleWBeFGBgEC89Ktx c/flwvRuP/bKQyP86sXty3f7mw/Dvxlqj8XGD3NIoXXJe1GJstrfvynjJOCLocrQ+rx89z9f 7F+PDfR4Wh9PJUFvS0i4X/Zirm+y/r4r+cv+49sXb4dP2G9DyBh+XS8//P7Lzas3r/e/dM3h Ez2excI+bmsoYWGF0ylh2cBt1u8fpoTmepISFpVp87vseurDdf+difHpKu+yvvj2rDK+9S8+ vh1/Ud3hLN8HNT4LOWTh2CdzyMJxT+aQJeOu5ZBHajzEIUXWncIhxyMuXW3xyIjns9rikQM9 abXFI2PAJbgEl+ASXIJLcAkuwSW4BJfgElyCS3AJLj0fXOrhElyCS3AJLsEluASX4BJcgktw CS7BJbgEl+ASXFqLSzu4BJfgElyCS3AJLsEluASX4BJcgktwCS7BJbgEl9bi0jVcgktwCS7B JbgEl+ASXIJLcAkuwSW4BJfgElyCS2tx6QYuwSW4BJfgElyCS3AJLsEluASX4BJcgktwCS7B pbW4dAuX4BJcgktwCS7BJbgEl+ASXIJLcAkuwSW4BJfg0lpc2sMluASX4BJcgktwCS7BJbgE l+ASXIJLcAkuwSW4tBaX7uASXIJLcAkuwSW4BJfgElyCS3AJLsEluASX4BJcWolLeQaX4BJc gktwCS7BJbgEl+ASXIJLcAkuwSW4BJfg0lpcyuESXIJLcAkuwSW4BJfgElyCS3AJLsEluASX 4BJcWotLBVyCS3AJLsEluASX4BJcgktwCS7BJbgEl+ASXIJLa3GphEtwCS7BJbgEl+ASXIJL cAkuwSW4BJfgElyCS3BpLS5VcAkuwSW4BJfgElyCS3AJLsEluASX4BJcgktwCS6txaUaLsEl uASX4BJcgktwCS7BJbgEl+ASXIJLcAkuwaW1uNTAJbgEl+ASXIJLcAkuwSW4BJfgElyCS3AJ LsEluLQWl1q4BJfgElyCS3AJLsEluASX4BJcgktwCS7BJbgEl9biUgeX4BJcgktwCS7BJbgE l+ASXIJLcAkuwSW4BJfg0lpc6uESXIJLcAkuwSW4BJfgElyCS3AJLsEluASX4BJcWotLO7gE l+ASXIJLcAkuwSW4BJfgElyCS3AJLsEluASX1uLSNVyCS3AJLsEluASX4BJcgktwCS7BJbgE l+ASXIJLa3HpBi7BJbgEl+ASXIJLcAkuwSW4BJfgElyCS3AJLsGltbh0C5fgElyCS3AJLsEl uASX4BJcgktwCS7BJbgEl+DSWlzawyW4BJfgElyCS3AJLsEluASX4BJcgktwCS7BJbi0Fpfu 4BJcgktwCS7BJbgEl+ASXIJLcAkuwSW4BJfgElxaiUtFBpfgElyCS3AJLsEluASX4BJcgktw CS7BJbgEl+DSWlzK4RJcgktwCS7BJbgEl+ASXIJLcAkuwSW4BJfgElxai0sFXIJLcAkuwSW4 BJfgElyCS3AJLsEluASX4BJcgktrcamES3AJLsEluASX4BJcgktwCS7BJbgEl+ASXIJLcGkt LlVwCS7BJbgEl+ASXIJLcAkuwSW4BJfgElyCS3AJLq3FpRouwSW4BJfgElyCS3AJLsEluASX 4BJcgktwCS7BpbW41MAluASX4BJcgktwCS7BJbgEl+ASXIJLcAkuwSW4tBaXWrgEl+ASXIJL cAkuwSW4BJfgElyCS3AJLsEluASX1uJSB5fgElyCS3AJLsEluASX4BJcgktwCS7BJbgEl+DS Wlzq4RJcgktwCS7BJbgEl+ASXIJLcAkuwSW4BJfgElxai0s7uASX4BJcgktwCS7BJbgEl+AS XIJLcAkuwSW4BJfW4tL1ybhU/VJ2VVlFxKVPI9b52ePS/YHWIbh0P0YLl+ASXHrquHT4Nldd vgEu3ZeqFuPSpx/s85S4dF+jToFL92P32+DSoVqdVZFx6X7Ydgtc+lQrLxPj0n2ZNh0ufapQ 5Olx6b5Sk4Jn7sfu0+HSpwplme7oqyIdLt1X6NLj0qdKdZUalz7VafIUuHQ/dp0Wl+6r9Mlw 6VOBtkqNS5/qdCnN575ElR5k7it16YjkU4W+iE4k9wM3E0Ryu3uYSHbt6URyKNNkeQpeuB+7 js0L9+P2sXnh07h5lZIX7mu0j/HCzTJeaIrYvNAU1dPghaZog3mhKTq8gBfwwrPghbYstuKF tlzJC23ZJeeFtiqS8UJb1RvyQlv1KXihrcvNeKGt2y14oT0OUZF5oW2qjXihPY5T0QJ62xaJ eaFt0+FI26XmhbZrN+KFti834YW275LxwtB1bMALXdak5YUu/dqV+zp1al7o8n4jXuiKMjEv dEWbhhe6MtuCF7qySsYL3XEfFYUXuuPeKQovDFkzOS90Iw0/zAu3y3ihG9caROWFrn4ivNDV 4bzQ1T1ewAt44VnwQt9sxgt9s5IX+iY9L/RtOl7o2y15oW+T8ELfbccLfbcJL/R9al7oj9fE JOKFvk/GC3WWJeaFoUKT7ujzxLww/GUjXqizYhNeGOok44U6KzfghaFKWl6os2oTXhjqpOaF ocRGvFBndWJeGCqk4YU6a7bghaFMnYoXhrGT8EKdtUl4YRg3OS8MNR7lhf0iXqizLjIvDCM+ DV4YDjSYF4Yx8AJewAvPghfqvN+KF4ZS63hh+MHkvFAXWTJeGMZutuOF4feSJeCFYdjNeGGo tQUv1EWRmBeGChvxwlApHS8Ux7cuROaFokzHC0XqmyOGChvdHFEXdb0JLxRNlowXiuMVPQl4 oTiOUnF5oTjOVEl4oWjb1LxQdPlGvFB0dWJeKLo+DS8UE3ddJOCF4vgejGi8UGZZEl4osyoJ L5RZl5wXysf3Xrhbxgvl2ChF5YUyb54GL5TjMqhAXigLG3viBbzwPHihGufDtuGFarw9fA0v VMfRKTovVBN3f8fiheHktiEvVFWegheqqtqMF6qq24IXqrpIzAtV3WzEC1WTJQvo1dQtHlF5 oWradEfflol5ofphvVA6Xqi6bXih6tPxQtVvwQtVn5gX6mwbXqiPbTo2L9RbbIZ5Xyk1L9R5 l4YX6mITXpjYQycaL9RlGl6oyzS8UJfpeaGuHuOFMlvGC0O7F5kX6uqJ8EJdhfNCPd5bghfw Al54BrzQjPd1bcMLTb2SF5omS84LzXGEisYLTbMlLzRtEl5oju/wSMYLzfH9HSl4oenKxLzQ HN/lkYgXmuMbPaIF9KZPzQvNcRiMdvRtViXmhXaL54bcV9qGF9oiHS+0xRa80BaJeaEtt+GF tky+eqGttlq9MLELUWReaKtEqxcm9h5KwQsT2w5F44WJvYai8MLEDkNReKFt0vNC2+aP8UK+ jBfaNjYvHHYmegq80LbhvNB2eAEv4IXnwQtdtxkvdN1KXuj69LzQ9el4oeu35IV+4k75CLzQ H8+iJeOFPvljSe/LVIl5oT+eS0vEC/3x5Fq0gN5P3eIRlRf6hLd29GWdmBf6aite6H/Y7CwV L/R1sidHDGNv8OSIoUraJ0fUfVNuwgsTGw/F5oWJfYcS8UJ/vIVrZF7ouywNL0zsPZSCFya2 HYrGCxN7DUXhhb5Pwwt9n5wXmix7lBeKRbwwjFjF5YVhxPZJ8EKTjX1bGC8MY+AFvIAXngUv NPk4H7YJLwyl2lW80ORF8gdTDjWS8cIwdrcdLzR5mYIXhmFTr14IakaG4FVmiZuR+xoPNiNd uaQZ+TpirGbkfsTzb0buDzSoGbkfQzOiGdGMPPlm5P7bvEUzcl9qeTMydZmJ3YxM1ojUjMyM nagZmawW3ozMDJtkrmOyVvy5jpkyEec6pn9pKeY6pj9jcWYLZl5FxLmObY8+9lzHTIUEcx0z laLPdUy+H5HmOqbHjj3XMVMl3lzHZIEEcx2TdeLOdUy/lBRzHTOVIs51zFQIn+uYHjj6XMdk mUhzHTNjB891zIwbPNdxNrxQ4QW8gBfwAl7AC3gBL+AFvIAX8AJewAt4AS+E8UKNF/ACXsAL eAEv4AW8gBfwAl7AC3gBL+AFvBDGCw1ewAt4AS/gBbyAF/ACXsALeAEv4AW8gBfwQhgvtHgB L+AFvIAX8AJewAt4AS/gBbyAF/ACXsALYbzQ4QW8gBfwAl7AC3gBL+AFvIAX8AJewAt4AS+E 8UKPF/ACXsALeAEv4AW8gBfwAl7AC3gBL+AFvBDGCzu8gBfwAl7AC3gBL+AFvIAX8AJewAt4 AS/ghTBeuMYLeAEv4AW8gBfwAl7AC3gBL+AFvIAX8AJeCOOFG7yAF/ACXsALeAEv4AW8gBfw Al7AC3gBL+CFMF64xQt4AS/gBbyAF/ACXsALeAEv4AW8gBfwAl4I44U9XsALeAEv4AW8gBfw Al7AC3gBL+AFvIAX8EIYL9zhBbyAF/ACXsALeAEv4AW8gBfwAl7AC3gBLwTxQp/hBbyAF/AC XsALeAEv4AW8gBfwAl7AC3gBL4TxQo4X8AJewAt4AS/gBbyAF/ACXsALeAEv4AW8EMYLBV7A C3gBL+AFvIAX8AJewAt4AS/gBbyAF/BCGC+UeAEv4AW8gBfwAl7AC3gBL+AFvIAX8AJewAth vFDhBbyAF/ACXsALeAEv4AW8gBfwAl7AC3gBL4TxQo0X8AJewAt4AS/gBbyAF/ACXsALeAEv 4AW8EMYLDV7AC3gBL+AFvIAX8AJewAt4AS/gBbyAF/BCGC+0eAEv4AW8gBfwAl7AC3gBL+AF vIAX8AJewAthvNDhBbyAF/ACXsALeAEv4AW8gBfwAl7AC3gBL4TxQo8X8AJewAt4AS/gBbyA F/ACXsALeAEv4AW8EMYLO7yAF/ACXsALeAEv4AW8gBfwAl7AC3gBL+CFMF64xgt4AS/gBbyA F/ACXsALeAEv4AW8gBfwAl4I44UbvIAX8AJewAt4AS/gBbyAF/ACXsALeAEv4IUwXrjFC3gB L+AFvIAX8AJewAt4AS/gBbyAF/ACXgjjhT1ewAt4AS/gBbyAF/ACXsALeAEv4AW8gBfwQhgv 3OEFvIAX8AJewAt4AS/gBbyAF/ACXsALeAEvBPHCLsMLeAEv4AW8gBfwAl7AC3gBL+AFvIAX 8AJeCOOFHC/gBbyAF/ACXsALeAEv4AW8gBfwAl7AC3ghjBcKvIAX8AJewAt4AS/gBbyAF/AC XsALeAEv4IUwXijxAl7AC3gBL+AFvIAX8AJewAt4AS/gBbyAF8J4ocILeAEv4AW8gBfwAl7A C3gBL+AFvIAX8AJeCOOFGi/gBbyAF/ACXsALeAEv4AW8gBfwAl7AC3ghjBcavIAX8AJewAt4 AS/gBbyAF/ACXsALeAEv4IUwXmjxAl7AC3gBL+AFvIAX8AJewAt4AS/gBbyAF8J4ocMLeAEv 4AW8gBfwAl7AC3gBL+AFvIAX8AJeCOOFHi/gBbyAF/ACXsALeAEv4AW8gBfwAl7AC3ghjBd2 eAEv4AW8gBfwAl7AC3gBL+AFvIAX8AJewAthvHC9gBf6vBgOMiYvjCNW1RPghcOBdmG8MI5R 4wW8gBeeAS8M3+aiLTfhhUOpegUvjD/YlWl54VCjTcML49h9vhUvHKo10XnhMGy/DS8Mtcqs Ts4LhzJ9Sl4YK+TlFrxwqNSmCejj2EWekhcOFep0R19WKXlhrFBtwguHSk16Xhjr1GUaXjiM 3abmhbFKkyfkhUOBJj0vjHXaIikvHEo0W/DCWKlLyguHClUCXjgM3CfnhbFMXx6fCbO6+tKH 3L0Zs+KnSHNoG8aYM74XQ6EFJ9zjJiHaCbfK8jRCchi7ji8kh3H7+EIyjptXaYXkUKN9TEhu lglJVWSRhaQqnoiQVEUTLCRV0RESQkJInoWQ1GWxlZDUY1RZIyR12SUXkrrKkwlJXdUbCkld 9SmEpK6LzYSkPg5RKYSkbrLEQjL0KRsJSd10yVre+jikRRaSuk3XsNddkVhI6h90NZ2Q1D/k p1RCUvddMiFpsmIDIWmyJq2QNHm2iZA0eZ1aSJq830hImqJMLCRN0aYRkqbMtxCSpqy3EJKm THe5aKoimZA0VZNESJo6SyIkTZ1eSJq6eUxIbpcJSVP3kYWkaYqnISTNEJ5ChaRpWkJCSAjJ sxCSts22EpJ2XK6yRkja4/wUXUjaLksmJO3xvFZCIWm7LoWQtMcLYZIJSdtvsoak7VOvIemy rdaQdFm6NSRdnnoNSZenW0PSFVliIemKZiMh6cpiEyHpyjaZkHRVtoGQdMcqHVdIumOITiIk 3fFynthC0tXtRkLSNUViIemaOo2QdM0ma0i6dpM1JF2b8HLRpVtD0nVp1pB0x01TFCHp+iK5 kHRjt/SwkOyXCUnXt5GFpM+ypyEk/dixBQpJPy50IiSEhJA8fSEps6zbSEjKLM9WCcnwg1Vq IRlq9KmEpMyOZ87SCclQrU0gJGW21SYeh1rVBkIylOnSCkmZVcU2QjJUSrYKo8zqLK2QDBXK hEffpxWSMvshlSUTkjJr8y2EZKjTpBKSYew+vZCU2fGdmVGFZCjQbSEkZdanvstmKLHRXTZl niW+y2aokOYum2HgbgMhKYcubAMhGcqku1zkRZZKSIaxyxRCMozbphCSMj9aeRRdSMrPu4Y8 ICR3i4RkGLGJKyTDiP2TEJIyHzu2MCEpD5uuEBJCQkiegZAUVbuVkBTjrNsaISnq5PuQDDWS 7UNSFs2G+5AM1aoUQlI03WZCUhzf1pFCSIrjHBhZSIou20hIiol1SrFa3mJiVVJcIZnaqSfa 0fdtYiEps3IjIflx55xUQjKxf040IZnYMSeBkEzsnRNXSCa2zkkiJGXibU4PJaqNhKQ8NunI QlJWRRohKY8JOoWQlHW2hZCUdbrLxcRGQ9GEZGJ7oShCUjZ1EiEpj1YexReScmTzB4XkOlsm JGVbRRaSclyz9BSE5LBTUqCQlON9vYSEkBCSZyAk1bhscRshqcbb9dcISXWcn6ILSdXXyYSk 6vsNhaTOihRCUmfNZkJS59kWQlLnVWIhqfNuIyGpiyJZy1sXTWIhqYs+3dGXdWIh+XEPo3RC UlftJkJS13kyIanregMhqes+rZDUTbmJkExsMBRbSCb2GUokJPXUnrBRhaTusjRCUk9sAZtA SOqu20JI6j7h5aJvkglJk2VJhKTJyiRC0hzd/BpfSA47Ij0sJPkyIWnGhUxRheSwm9JTEJIm D36WTdkUnmVDSAjJ8xCSttjqWTZDqXXPshl+sE8uJG1ZJhOStmw3FJK2ylMISVtVmwlJW3Vb CElbF1GEpHugQhNVSB6o1IQ+bPahsasoQvJQhS7d0bdlFCF5qEIfVUgeqNTVEYXkgTp96KNy Hxq7jCYkD1VpYwjJfIHuGKIDhOShOk0cIXmgRB73UbkPVaqiCMlDFboQIXlg4GOCXi8kD5Vp 4gnJA2XKdJeL7nhJ0kIheWjsLkBIHhi3ygOE5KFx60hC8lCN7jEhKaaE5IER63XPsnloxPKc hOShAz31WTYPjeFZNmcvJEvPa0WW1W3SRnKmQoJGcqZS9EbyuE68RnJ67NiN5EyVeI3kZIEE jeRknbiN5PRLSdFIzlSK2EjOVAhvJKcHjt5ITpaJ30jOlInSSE6OHamRnBk7uJGcGTe4kZwa N3YjeV/joUayzOoljeTXEWM1kvcjnn8jeX+gQY3k/RgaSVNtptqezFTbI9/mmFNtj5San2pb dPlaOdW2rGVYNtW2cOzAqbZF1U6fals4bNBU26Ja66faFpaJONU2/UtLMdW2ecsbdapt26Mn JISEkBASQkJILkVIGkJCSAgJISEkhISQEBJCQkgICSEhJISEkBCSixeSlpAQEkJCSAgJISEk hISQEBJCQkgICSEhJITk4oWkIySEhJAQEkJCSAgJISEkhISQEBJCQkgICSG5eCHpCQkhISSE hJAQEkJCSAgJISEkhISQEBJCQkguXkh2hISQEBJCQkgICSEhJISEkBASQkJICAkhISQXLyTX hISQEBJCQkgICSEhJISEkBASQkJICAkhISQXLyQ3hISQEBJCQkgICSEhJISEkBASQkJICAkh ISQXLyS3hISQEBJCQkgICSEhJISEkBASQkJICAkhISQXLyR7QkJICAkhISSEhJAQEkJCSAgJ ISEkhISQEJKLF5I7QkJICAkhISSEhJAQEkJCSAgJISEkhISQEJJLF5I8IySEhJAQEkJCSAgJ ISEkhISQEBJCQkgICSG5eCHJCQkhISSEhJAQEkJCSAgJISEkhISQEBJCQkguXkgKQkJICAkh ISSEhJAQEkJCSAgJISEkhISQEJKLF5KSkBASQkJICAkhISSEhJAQEkJCSAgJISEkhOTihaQi JISEkBASQkJICAkhISSEhJAQEkJCSAgJIbl4IakJCSEhJISEkBASQkJICAkhISSEhJAQEkJC SC5eSBpCQkgICSEhJISEkBASQkJICAkhISSEhJAQkosXkpaQEBJCQkgICSEhJISEkBASQkJI CAkhISSE5OKFpCMkhISQEBJCQkgICSEhJISEkBASQkJICAkhuXgh6QkJISEkhISQEBJCQkgI CSEhJISEkBASQkJILl5IdoSEkBASQkJICAkhISSEhJAQEkJCSAgJISEkFy8k14SEkBASQkJI CAkhISSEhJAQEkJCSAgJISEkFy8kN4SEkBASQkJICAkhISSEhJAQEkJCSAgJISEkFy8kt4SE kBASQkJICAkhISSEhJAQEkJCSAgJISEkFy8ke0JCSAgJISEkhISQEBJCQkgICSEhJISEkBCS ixeSO0JCSAgJISEkhISQEBJCQkgICSEhJISEkBCSSxeSIiMkhISQEBJCQkgICSEhJISEkBAS QkJICAkhuXghyQkJISEkhISQEBJCQkgICSEhJISEkBASQkJILl5ICkJCSAgJISEkhISQEBJC QkgICSEhJISEkBCSixeSkpAQEkJCSAgJISEkhISQEBJCQkgICSEhJITk4oWkIiSEhJAQEkJC SAgJISEkhISQEBJCQkgICSG5eCGpCQkhISSEhJAQEkJCSAgJISEkhISQEBJCQkguXkgaQkJI CAkhISSEhJAQEkJCSAgJISEkhISQEJKLF5KWkBASQkJICAkhISSEhJAQEkJCSAgJISEkhOTi haQjJISEkBASQkJICAkhISSEhJAQEkJCSAgJIbl4IekJCSEhJISEkBASQkJICAkhISSEhJAQ EkJCSC5eSHaEhJAQEkJCSAgJISEkhISQEBJCQkgICSEhJBcvJNenCEnAa61/qYq87uuUr/Vr jQdfa1eerEHfjRhFg76OeOYa9PVA12vQ1zFoEA2iQU9bg75+m5Nr0NdSCzVo5jITVYPmasTQ oPmxU2jQXLVADZofNr4GzdWKrEHzZWJp0OwvLboGzX7GIrT3868ilgZtfvRRNWi+QmwNmq8U V4Pm3o8YGjQ7dlQNmq8SSYPmCsTWoLk6ETVo9qVE16D5SrE0aL5CoAbNDhxXg+bKxKCU+bHD KGV+3DBKOSdeqPACXsALeAEv4AW8gBfwAl7AC3gBL+AFvIAXwnihxgt4AS/gBbyAF/ACXsAL eAEv4AW8gBfwAl4I44UGL+AFvIAX8AJewAt4AS/gBbyAF/ACXsALeCGMF1q8gBfwAl7AC3gB L+AFvIAX8AJewAt4AS/ghTBe6PACXsALeAEv4AW8gBfwAl7AC3gBL+AFvIAXwnihxwt4AS/g BbyAF/ACXsALeAEv4AW8gBfwAl4I44UdXsALeAEv4AW8gBfwAl7AC3gBL+AFvIAX8EIYL1zj BbyAF/ACXsALeAEv4AW8gBfwAl7AC3gBL4Txwg1ewAt4AS/gBbyAF/ACXsALeAEv4AW8gBfw Qhgv3OIFvIAX8AJewAt4AS/gBbyAF/ACXsALeAEvhPHCHi/gBbyAF/ACXsALeAEv4AW8gBfw Al7AC3ghjBfu8AJewAt4AS/gBbyAF/ACXsALeAEv4AW8gBeCeKHP8AJewAt4AS/gBbyAF/AC XsALeAEv4AW8gBfCeCHHC3gBL+AFvIAX8AJewAt4AS/gBbyAF/ACXgjjhQIv4AW8gBfwAl7A C3gBL+AFvIAX8AJewAt4IYwXSryAF/ACXsALeAEv4AW8gBfwAl7AC3gBL+CFMF6o8AJewAt4 AS/gBbyAF/ACXsALeAEv4AW8gBfCeKHGC3gBL+AFvIAX8AJewAt4AS/gBbyAF/ACXgjjhQYv 4AW8gBfwAl7AC3gBL+AFvIAX8AJewAt4IYwXWryAF/ACXsALeAEv4AW8gBfwAl7AC3gBL+CF MF7o8AJewAt4AS/gBbyAF/ACXsALeAEv4AW8gBfCeKHHC3gBL+AFvIAX8AJewAt4AS/gBbyA F/ACXgjjhR1ewAt4AS/gBbyAF/ACXsALeAEv4AW8gBfwQhgvXOMFvIAX8AJewAt4AS/gBbyA F/ACXsALeAEvhPHCDV7AC3gBL+AFvIAX8AJewAt4AS/gBbyAF/BCGC/c4gW8gBfwAl7AC3gB L+AFvIAX8AJewAt4AS+E8cIeL+AFvIAX8AJewAt4AS/gBbyAF/ACXsALeCGMF+7wAl7AC3gB L+AFvIAX8AJewAt4AS/gBbyAF4J4YZfhBbyAF/ACXsALeAEv4AW8gBfwAl7AC3gBL4TxQo4X 8AJewAt4AS/gBbyAF/ACXsALeAEv4AW8EMYLBV7AC3gBL+AFvIAX8AJewAt4AS/gBbyAF/BC GC+UeAEv4AW8gBfwAl7AC3gBL+AFvIAX8AJewAthvFDhBbyAF/ACXsALeAEv4AW8gBfwAl7A C3gBL4TxQo0X8AJewAt4AS/gBbyAF/ACXsALeAEv4AW8EMYLDV7AC3gBL+AFvIAX8AJewAt4 AS/gBbyAF/BCGC+0eAEv4AW8gBfwAl7AC3gBL+AFvIAX8AJewAthvNDhBbyAF/ACXsALeAEv 4AW8gBfwAl7AC3gBL4TxQo8X8AJewAt4AS/gBbyAF/ACXsALeAEv4AW8EMYLO7yAF/ACXsAL eAEv4AW8gBfwAl7AC3gBL+CFMF64nuKF/ocRT3ut/fRx9MXQe7eRXusjNR56rVVWnvJaj0dc SimPjHg+lPLIgZ5EKY+MgVJQCkp5MpTyyLc5JqU8UmqeUpZcZtZSyqIaCyll4diBlLKo2umU snDYIEpZVGs9pSwss4JSlv3SQihl2WdsGUYsfBUrKOU8jn4tpSysEEApCyutppRF78dCSlk2 9lpKWVhlOaUsKhBAKYvqrKOUZS8lhFIWVlpBKQsrnE4pywZeTSmLyiyklIVjn0wpC8c9mVLO nhcqvIAX8AJewAt4AS/gBbyAF/ACXsALeAEv4IUwXqjxAl7AC3gBL+AFvIAX8AJewAt4AS/g BbyAF8J4ocELeAEv4AW8gBfwAl7AC3gBL+AFvIAX8AJeCOOFFi/gBbyAF/ACXsALeAEv4AW8 gBfwAl7AC3ghjBc6vIAX8AJewAt4AS/gBbyAF/ACXsALeAEv4IUwXujxAl7AC3gBL+AFvIAX 8AJewAt4AS/gBbyAF8J4YYcX8AJewAt4AS/gBbyAF/ACXsALeAEv4AW8EMYL13gBL+AFvIAX 8AJewAt4AS/gBbyAF/ACXsALYbxwgxfwAl7AC3gBL+AFvIAX8AJewAt4AS/gBbwQxgu3eAEv 4AW8gBfwAl7AC3gBL+AFvIAX8AJewAthvLDHC3gBL+AFvIAX8AJewAt4AS/gBbyAF/ACXgjj hTu8gBfwAl7AC3gBL+AFvIAX8AJewAt4AS/ghSBeyDO8gBfwAl7AC3gBL+AFvIAX8AJewAt4 AS/ghTBeyPECXsALeAEv4AW8gBfwAl7AC3gBL+AFvIAXwnihwAt4AS/gBbyAF/ACXsALeAEv 4AW8gBfwAl4I44USL+AFvIAX8AJewAt4AS/gBbyAF/ACXsALeCGMFyq8gBfwAl7AC3gBL+AF vIAX8AJewAt4AS/ghTBeqPECXsALeAEv4AW8gBfwAl7AC3gBL+AFvIAXwnihwQt4AS/gBbyA F/ACXsALeAEv4AW8gBfwAl4I44UWL+AFvIAX8AJewAt4AS/gBbyAF/ACXsALeCGMFzq8gBfw Al7AC3gBL+AFvIAX8AJewAt4AS/ghTBe6PECXsALeAEv4AW8gBfwAl7AC3gBL+AFvIAXwnhh hxfwAl7AC3gBL+AFvIAX8AJewAt4AS/gBbwQxgvXeAEv4AW8gBfwAl7AC3gBL+AFvIAX8AJe wAthvHCDF/ACXsALeAEv4AW8gBfwAl7AC3gBL+AFvBDGC7d4AS/gBbyAF/ACXsALeAEv4AW8 gBfwAl7AC2G8sMcLeAEv4AW8gBfwAl7AC3gBL+AFvIAX8AJeCOOFO7yAF/ACXsALeAEv4AW8 gBfwAl7AC3gBL+CFIF4oMryAF/ACXsALeAEv4AW8gBfwAl7AC3gBL+CFMF7I8QJewAt4AS/g BbyAF/ACXsALeAEv4AW8gBfCeKHAC3gBL+AFvIAX8AJewAt4AS/gBbyAF/ACXgjjhRIv4AW8 gBfwAl7AC3gBL+AFvIAX8AJewAt4IYwXKryAF/ACXsALeAEv4AW8gBfwAl7AC3gBL+CFMF6o 8QJewAt4AS/gBbyAF/ACXsALeAEv4AW8gBfCeKHBC3gBL+AFvIAX8AJewAt4AS/gBbyAF/AC XgjjhRYv4AW8gBfwAl7AC3gBL+AFvIAX8AJewAt4IYwXOryAF/ACXsALeAEv4AW8gBfwAl7A C3gBL+CFMF7o8QJewAt4AS/gBbyAF/ACXsALeAEv4AW8gBfCeGGHF/ACXsALeAEv4AW8gBfw Al7AC3gBL+AFvBDGC9en8IJALBALxE87EDe/VE2bd80GgfhrqYWB+OsPpgvEczViBOL5sVME 4rlqgYF4ftj4gXiuVuRAPF8mViCe/aVFD8Szn7EIkXL+VcQKxJsffdRAPF8hdiCerxQ3EM+9 HzEC8ezYUQPxfJVIgXiuQOxA/MBX4+buy4Xp3X7slYdG+NWL25fv9jcfhn8z1B6LjR/mkEIR k/dcibLa378p4yTgi6HK0Pq8fPc/X+xfjw30eFofTyVBb0v0cD/7Yq5vsv6+K/nL/uPbF2+H T9hvQ8gYfl0vP/z+y82rN6/3v3TN4RM9nsXCPm7RKGG+QiAlzA7cZv3+YUpork+nhLkybX6X XU99uO6/MzE+XeVd1hffnlXGt/7Fx7fjL6o7nOX7oMYnBofMjx3GIfPjhnHIzLhROeRrjQc5 pDt9r4jvRoyy2uLriGe+2uLrga5fbfF1DLgEl+ASXIJLcAkuwSW4BJfgElyCS3AJLsGl54NL PVyCS3AJLsEluASX4BJcgktwCS7BJbgEl+ASXIJLa3FpB5fgElyCS3AJLsEluASX4BJcgktw CS7BJbgEl+DSWly6hktwCS7BJbgEl+ASXIJLcAkuwSW4BJfgElyCS3BpLS7dwCW4BJfgElyC S3AJLsEluASX4BJcgktwCS7BJbi0Fpdu4RJcgktwCS7BJbgEl+ASXIJLcAkuwSW4BJfgElxa i0t7uASX4BJcgktwCS7BJbgEl+ASXIJLcAkuwSW4BJfW4tIdXIJLcAkuwSW4BJfgElyCS3AJ LsEluASX4BJcgksrcanP4BJcgktwCS7BJbgEl+ASXIJLcAkuwSW4BJfgElxai0s5XIJLcAku wSW4BJfgElyCS3AJLsEluASX4BJcgktrcamAS3AJLsEluASX4BJcgktwCS7BJbgEl+ASXIJL cGktLpVwCS7BJbgEl+ASXIJLcAkuwSW4BJfgElyCS3AJLq3FpQouwSW4BJfgElyCS3AJLsEl uASX4BJcgktwCS7BpbW4VMMluASX4BJcgktwCS7BJbgEl+ASXIJLcAkuwSW4tBaXGrgEl+AS XIJLcAkuwSW4BJfgElyCS3AJLsEluASX1uJSC5fgElyCS3AJLsEluASX4BJcgktwCS7BJbgE l+DSWlzq4BJcgktwCS7BJbgEl+ASXIJLcAkuwSW4BJfgElxai0s9XIJLcAkuwSW4BJfgElyC S3AJLsEluASX4BJcgktrcWkHl+ASXIJLcAkuwSW4BJfgElyCS3AJLsEluASX4NJaXLqGS3AJ LsEluASX4BJcgktwCS7BJbgEl+ASXIJLcGktLt3AJbgEl+ASXIJLcAkuwSW4BJfgElyCS3AJ LsEluLQWl27hElyCS3AJLsEluASX4BJcgktwCS7BJbgEl+ASXFqLS3u4BJfgElyCS3AJLsEl uASX4BJcgktwCS7BJbgEl9bi0h1cgktwCS7BJbgEl+ASXIJLcAkuwSW4BJfgElyCSytxaZfB JbgEl+ASXIJLcAkuwSW4BJfgElyCS3AJLsEluLQWl3K4BJfgElyCS3AJLsEluASX4BJcgktw CS7BJbgEl9biUgGX4BJcgktwCS7BJbgEl+ASXIJLcAkuwSW4BJfg0lpcKuESXIJLcAkuwSW4 BJfgElyCS3AJLsEluASX4BJcWotLFVyCS3AJLsEluASX4BJcgktwCS7BJbgEl+ASXIJLa3Gp hktwCS7BJbgEl+ASXIJLcAkuwSW4BJfgElyCS3BpLS41cAkuwSW4BJfgElyCS3AJLsEluASX 4BJcgktwCS6txaUWLsEluASX4BJcgktwCS7BJbgEl+ASXIJLcAkuwaW1uNTBJbgEl+ASXIJL cAkuwSW4BJfgElyCS3AJLsEluLQWl3q4BJfgElyCS3AJLsEluASX4BJcgktwCS7BJbgEl9bi 0g4uwSW4BJfgElyCS3AJLsEluASX4BJcgktwCS7BpbW4dD2BS2X2w4gPfTOO/vChfPtLXlRZ XU98M253D38zdu3UN2NZmazJ6urLJeTuzehPn5jk8Dsd6WT8KAyFdmFlljRxy8Ze9sVYOvap X4yl4576xVg07sovxmM1Hvxi3Nyc8sU4HnGhuj424tmo62MHeoq6PjYGdf2irg8I64ydTlro Ot88kTNPZMrlADkrjg/64RELPvZx+8KCU9D32A/PQt/xD85J3knudjTcn6pZTZvSsAm5mmCm u+WXqj9V/3HmnB10+fuOK45y/zc1T87qyy5ha7P60iqLs/rCPmsqq3+J6RMR/Xj4mZFXheaF Bx+QaJdWWp4xl1Y4OWPqpHXSZ9JJT7TI0x3tRC+6spdc1itOd3szfdtDfdhPabROa7BO6K9O 663mZ3AfnpBd21El7qe6ubnRdQ3Vonbq7YkN1bvT5ttOnTmbbrVWnBXnurY1J9pvW7UfOzWN WkijNk6qrGzW9GrxerWYX5ZTvy3V+q/Ln/7jJX9hfF9kG9lGtkk6S3ByCCp/WRWDEoagEa8f CELzOSihN0fLQauceetYVJRl8mSU5bPrRrfh5uN49PTTUeiZ+qHWLw5pX3Trp/PT+en8dH5p 14fMrOiY6v3WtH4Ll0rEbP1uFvd+t1PNXwoCf317ZosMXpztKoOHer+Vrd/8bTvrVxrEbf1i dX4xG79LZ/EnMG02nDGcMGan0c5qYdLzn0ZLf8IwMSAeiofioXgYHg9PXhl1mckwvMv7uXMC b1ZOCpx1LGyjrpd6oM/7DydOCTyDTi/2iikLpn7KJIA2T5unzdPmnXyXaOJmr6t/Yrv3M+YB TlsDcuqOaNv0eyeeBefvkPv+LOck5yQX+yQ3cfKauyU92qnr5y1ei3QXz8+bjYi4eO3pTl/+ 3NnLiCl165Caavby72Yj4t/X881maaKqqKqL08VteKtCvDu2Y3R7V3/9mUH19W2Chs96teCG b5PlJ5Fv5P71Cfd8ZiXO7zZuzZ5m7yk2e6cs89sfn2Y3iNVnNfn79/nzbOVE60TrROtEK1X/ pFS9YPLkZ037zsTp+TT9JCdPzJ08lVu/nvSmaFG7vO9OSnZI22gmZX9K06fn0/Pp+fR80zWW TKJEmkM5y6V+/+Np3L8bcQYl0Y0dT+7+3Z94W8ev53G/f6JtcJ/89/wnfs1/i5buHnn48OXc p59iW4+nNUt6pvtd28WN38tyspwsF5Tl/lSdLvhndfNDdL9ftBruWWS5J0v4W/V4z+4O/bh6 T+zPSeztxqTL0+Xp8uZrbL8d0+I79P/pDPfqfbjZi/0khW/PFZ/PFE4UThRb3+r+k8LeT96j 48Vmae/15qafale2p3bvUwLSf1ppL/aCfM9liZv3oL64p4vTxYXEvfPPenHvco+0++6tbY3O cZXW812YH+3+y40Wab0A+z/95kttnjZPm/d17IdPyFufiD0e65km7k7kdi52Lha5J7PGT5ha Obc9hH/2A1AtoDu7uyTO5maos5xU+fLD3/R52jwPvNfh6fB0eOc2qfJktzpadafET3iaoTbv 7B9neP7PidinbfSeyXzKhT3o5elOiGZn9tz5J79TmZvZn82MqIwmo8loMtqpjyPt6qZqqrv2 NuuattoXh8C2eMQ/nNcNEz97Gd1mjzVNeMfEm+e3km6ztnEi+J34HIMnlfviL+CI8xgDN01o HbWOWketY4zW8SfcNfHzFnEs3+7y3B5hv77R+1knN2c2Z7aQM9t357Ww59b/vJv5n2E4Pe2E 5eEr9c98jOn53N/1c+8qGH7WjQUJU6lMKpPq3HRuP/8+/l+2aPL+KeKqs5tIodTCs+f1jL0n e4PB2T9vxXOUI+3RO76QU+4ifaCOpk/Td4ZNX9pt8Z7rrnhidNDZ9euZdeHN+c6ozqhitBj9 xGK0BxmK0Cfeu7XFswxPXMN3YobOTl7F9+E8J0zk6PPeEk+vp9fT6+n1HrwD5PTFMU/tQRc3 53u3/utbPd/lPbz6+T+7eunAZd8V7XcnvV1W1E1V330t8Q0m7oexq/LqX4d//29hFerd9XcV Pr2SsbUb36p8/CTl5XWMSk22P9re4FMvPFQqx0tPswusM3apxXVzHd5nT48du8+eqRKvz54s kGC+arJO3I57+qWk6LhnKkXsuGcqhHfc0wNH77gny8TvuGfKROm4J8eO1HHPjB3ccc+MG9xx T40bu+O+r/HQPdd1Vi+55/rriF/+M93ALx3xX/7hv/3zf/7nf/zj0Cxe/fruzZsPvw4f6Cn3 zX7Jfr3dX7/cvf71+uPLV7e/Dg3t+Knf/Ta0gsPp9PX+1927mz//+veuGYf49bffPv5y88eq KmYatlN2/Pr2QP+v3bvboRncX73e/bb/41XXdf0//Jd/XDbGP725/TgGg+F1/WV/e/Xy9R+H dvn3tx9ur3bDyXo48hdDVzv+7f254+r6w8f311fXrz7uP7yZW8B/N/zmxv8f/uSL9x/evBtO y1cfd++v/v7hxYebtx9v345/9/bPv78f8sSXzDIfbb78/afTyfi3d0Pb/vL10Axd3X18vx/H ePFP//D//Nf//p8eikFvXr8eP3Z/efHy7V+r7/7N+A+3+7vhQD/9by/ffg5M81Z+fXv16s2b t1f/483v48s4JKXbMcDc7oeM83r36s2/Xw1v/9yjBMc/+/L1h/2rq9dvPv51v/v4/QjDZeam y4o8H6LK8NZMP47mxTD01c3dv3/6g/u/fj6O9/v/efjrh5e/Db/R+3+z6LaGdzdXt+9+e/GX 396/+PP+1dthlOEfD+nttFR3iHHjvz78zdv3v70Z36b3wydouOjs/jYUev/2L++uTr1n//D3 1y/fDG/DkAz2736/evvmb/shIXx8+/bV71fjEH99uTwi3l69//er9+8+/d3ti/lHI95/9se/ f/vy5d+vdkNSHL4y11/++mF39f7m/cvDEPfZ8oGMefib4VKW7cevyOFV/+ur4cx69fH1qze7 2/0QKIdPS9WfnkXvv81fdxD4P66GYPjbH4ejenv1/+7GD9rwv/zj1f1//mX8r8MJ7A/5Hw6n q9OT632ppbMVM5evqpmNtb+9eT2cG9tuPDcGNaJZVe6yL53J4qD8yNj57nMzPXyw5zP1mKbG C+Y+pNr3kfx+2Ntx2LuwYXfN5+mbqVmXFzev3o2VyrHFau76kFq3N3VbTN1Ys9+9eLX7X7+P b3k1vqKuCCvz2KTT3/M2qFl8eKLq86+sGTuxsro+15a32Je7T2/9eNCfItru3bvd7y/+Nsbm YpSG7jwbdkJCSAgJISEkhORShKQhJISEkBASQkJICAkhISSEhJAQEkJCSAgJIbl4IWkJCSEh JISEkBASQkJICAkhISSEhJAQEkJCSC5eSDpCQkgICSEhJISEkBASQkJICAkhISSEhJAQkosX kp6QEBJCQkgICSEhJISEkBASQkJICAkhISSE5OKFZEdICAkhISSEhJAQEkJCSAgJISEkhISQ EBJCcvFCck1ICAkhISSEhJAQEkJCSAgJISEkhISQEBJCcvFCckNICAkhISSEhJAQEkJCSAgJ ISEkhISQEBJCcvFCcktICAkhISSEhJAQEkJCSAgJISEkhISQEBJCcvFCsickhISQEBJCQkgI CSEhJISEkBASQkJICAkhuXghuSMkhISQEBJCQkgICSEhJISEkBASQkJICAkhuXQhyTNCQkgI CSEhJISEkBASQkJICAkhISSEhJAQkosXkpyQEBJCQkgICSEhJISEkBASQkJICAkhISSE5OKF pCAkhISQEBJCQkgICSEhJISEkBASQkJICAkhuXghKQkJISEkhISQEBJCQkgICSEhJISEkBAS QkJILl5IKkJCSAgJISEkhISQEBJCQkgICSEhJISEkBCSixeSmpAQEkJCSAgJISEkhISQEBJC QkgICSEhJITk4oWkISSEhJAQEkJCSAgJISEkhISQEBJCQkgICSG5eCFpCQkhISSEhJAQEkJC SAgJISEkhISQEBJCQkguXkg6QkJICAkhISSEhJAQEkJCSAgJISEkhISQEJKLF5KekBASQkJI CAkhISSEhJAQEkJCSAgJISEkhOTihWRHSAgJISEkhISQEBJCQkgICSEhJISEkBASQnLxQnJN SAgJISEkhISQEBJCQkgICSEhJISEkBASQnLxQnJDSAgJISEkhISQEBJCQkgICSEhJISEkBAS QnLxQnJLSAgJISEkhISQEBJCQkgICSEhJISEkBASQnLxQrInJISEkBASQkJICAkhISSEhJAQ EkJCSAgJIbl4IbkjJISEkBASQkJICAkhISSEhJAQEkJCSAgJIbl0ISkyQkJICAkhISSEhJAQ EkJCSAgJISEkhISQEJKLF5KckBASQkJICAkhISSEhJAQEkJCSAgJISEkhOTihaQgJISEkBAS QkJICAkhISSEhJAQEkJCSAgJIbl4ISkJCSEhJISEkBASQkJICAkhISSEhJAQEkJCSC5eSCpC QkgICSEhJISEkBASQkJICAkhISSEhJAQkosXkpqQEBJCQkgICSEhJISEkBASQkJICAkhISSE 5OKFpCEkhISQEBJCQkgICSEhJISEkBASQkJICAkhuXghaQkJISEkhISQEBJCQkgICSEhJISE kBASQkJILl5IOkJCSAgJISEkhISQEBJCQkgICSEhJISEkBCSixeSnpAQEkJCSAgJISEkhISQ EBJCQkgICSEhJITk4oVkR0gICSEhJISEkBASQkJICAkhISSEhJAQEkJy8UJyfYqQBL3Wtuqy uk77Wj/XePC1duUCDfpmxEga9HnEs9egzwcaokGfx6BBNIgGPXUN+vxt3kCDPpdarEGTl5nI GjRdI44GzY2dRoOmqwVr0NywKTRoulZ0DZorE0+DZn5pCTRo5jMWpb2fexXxNGjjo4+sQXMV 4mvQXKXYGjT9fsTRoJmxI2vQXJVoGjRdIL4GTdeJqkEzLyWBBs1ViqdBcxWCNWhm4NgaNF0m DqXMjR1KKXPjhlLK+fBChRfwAl7AC3gBL+AFvIAX8AJewAt4AS/gBbwQxgs1XsALeAEv4AW8 gBfwAl7AC3gBL+AFvIAX8EIYLzR4AS/gBbyAF/ACXsALeAEv4AW8gBfwAl7AC2G80OIFvIAX 8AJewAt4AS/gBbyAF/ACXsALeAEvhPFChxfwAl7AC3gBL+AFvIAX8AJewAt4AS/gBbwQxgs9 XsALeAEv4AW8gBfwAl7AC3gBL+AFvIAX8EIYL+zwAl7AC3gBL+AFvIAX8AJewAt4AS/gBbyA F8J44Rov4AW8gBfwAl7AC3gBL+AFvIAX8AJewAt4IYwXbvACXsALeAEv4AW8gBfwAl7AC3gB L+AFvIAXwnjhFi/gBbyAF/ACXsALeAEv4AW8gBfwAl7AC3ghjBf2eAEv4AW8gBfwAl7AC3gB L+AFvIAX8AJewAthvHCHF/ACXsALeAEv4AW8gBfwAl7AC3gBL+AFvBDEC32GF/ACXsALeAEv 4AW8gBfwAl7AC3gBL+AFvBDGCzlewAt4AS/gBbyAF/ACXsALeAEv4AW8gBfwQhgvFHgBL+AF vIAX8AJewAt4AS/gBbyAF/ACXsALYbxQ4gW8gBfwAl7AC3gBL+AFvIAX8AJewAt4AS+E8UKF F/ACXsALeAEv4AW8gBfwAl7AC3gBL+AFvBDGCzVewAt4AS/gBbyAF/ACXsALeAEv4AW8gBfw QhgvNHgBL+AFvIAX8AJewAt4AS/gBbyAF/ACXsALYbzQ4gW8gBfwAl7AC3gBL+AFvIAX8AJe wAt4AS+E8UKHF/ACXsALeAEv4AW8gBfwAl7AC3gBL+AFvBDGCz1ewAt4AS/gBbyAF/ACXsAL eAEv4AW8gBfwQhgv7PACXsALeAEv4AW8gBfwAl7AC3gBL+AFvIAXwnjhGi/gBbyAF/ACXsAL eAEv4AW8gBfwAl7AC3ghjBdu8AJewAt4AS/gBbyAF/ACXsALeAEv4AW8gBfCeOEWL+AFvIAX 8AJewAt4AS/gBbyAF/ACXsALeCGMF/Z4AS/gBbyAF/ACXsALeAEv4AW8gBfwAl7AC2G8cIcX 8AJewAt4AS/gBbyAF/ACXsALeAEv4AW8EMQLuwwv4AW8gBfwAl7AC3gBL+AFvIAX8AJewAt4 IYwXcryAF/ACXsALeAEv4AW8gBfwAl7AC3gBL+CFMF4o8AJewAt4AS/gBbyAF/ACXsALeAEv 4AW8gBfCeKHEC3gBL+AFvIAX8AJewAt4AS/gBbyAF/ACXgjjhQov4AW8gBfwAl7AC3gBL+AF vIAX8AJewAt4IYwXaryAF/ACXsALeAEv4AW8gBfwAl7AC3gBL+CFMF5o8AJewAt4AS/gBbyA F/ACXsALeAEv4AW8gBfCeKHFC3gBL+AFvIAX8AJewAt4AS/gBbyAF/ACXgjjhQ4v4AW8gBfw Al7AC3gBL+AFvIAX8AJewAt4IYwXeryAF/ACXsALeAEv4AW8gBfwAl7AC3gBL+CFMF7Y4QW8 gBfwAl7AC3gBL+AFvIAX8AJewAt4AS+E8cL1FC/kP4x42mvNp46j+6Uqm6FipNf6SI2HXmuT lae81uMRl1LKIyOeD6U8cqAnUcojY6AUlIJSngylPPJtjkkpj5Sap5Qll5m1lLKoxkJKWTh2 IKUsqnY6pSwcNohSFtVaTykLy6yglGW/tBBKWfYZW4YRC1/FCko5j6NfSykLKwRQysJKqyll 0fuxkFKWjb2WUhZWWU4piwoEUMqiOusoZdlLCaGUhZVWUMrCCqdTyrKBV1PKojILKWXh2CdT ysJxT6aUs+eFCi/gBbyAF/ACXsALeAEv4AW8gBfwAl7AC3ghjBdqvIAX8AJewAt4AS/gBbyA F/ACXsALeAEv4IUwXmjwAl7AC3gBL+AFvIAX8AJewAt4AS/gBbyAF8J4ocULeAEv4AW8gBfw Al7AC3gBL+AFvIAX8AJeCOOFDi/gBbyAF/ACXsALeAEv4AW8gBfwAl7AC3ghjBd6vIAX8AJe wAt4AS/gBbyAF/ACXsALeAEv4IUwXtjhBbyAF/ACXsALeAEv4AW8gBfwAl7AC3gBL4TxwjVe wAt4AS/gBbyAF/ACXsALeAEv4AW8gBfwQhgv3OAFvIAX8AJewAt4AS/gBbyAF/ACXsALeAEv hPHCLV7AC3gBL+AFvIAX8AJewAt4AS/gBbyAF/BCGC/s8QJewAt4AS/gBbyAF/ACXsALeAEv 4AW8gBfCeOEOL+AFvIAX8AJewAt4AS/gBbyAF/ACXsALeCGIF/IML+AFvIAX8AJewAt4AS/g BbyAF/ACXsALeCGMF3K8gBfwAl7AC3gBL+AFvIAX8AJewAt4AS/ghTBeKPACXsALeAEv4AW8 gBfwAl7AC3gBL+AFvIAXwnihxAt4AS/gBbyAF/ACXsALeAEv4AW8gBfwAl4I44UKL+AFvIAX 8AJewAt4AS/gBbyAF/ACXsALeCGMF2q8gBfwAl7AC3gBL+AFvIAX8AJewAt4AS/ghTBeaPAC XsALeAEv4AW8gBfwAl7AC3gBL+AFvIAXwnihxQt4AS/gBbyAF/ACXsALeAEv4AW8gBfwAl4I 44UOL+AFvIAX8AJewAt4AS/gBbyAF/ACXsALeCGMF3q8gBfwAl7AC3gBL+AFvIAX8AJewAt4 AS/ghTBe2OEFvIAX8AJewAt4AS/gBbyAF/ACXsALeAEvhPHCNV7AC3gBL+AFvIAX8AJewAt4 AS/gBbyAF/BCGC/c4AW8gBfwAl7AC3gBL+AFvIAX8AJewAt4AS+E8cItXsALeAEv4AW8gBfw Al7AC3gBL+AFvIAX8EIYL+zxAl7AC3gBL+AFvIAX8AJewAt4AS/gBbyAF8J44Q4v4AW8gBfw Al7AC3gBL+AFvIAX8AJewAt4IYgXigwv4AW8gBfwAl7AC3gBL+AFvIAX8AJewAt4IYwXcryA F/ACXsALeAEv4AW8gBfwAl7AC3gBL+CFMF4o8AJewAt4AS/gBbyAF/ACXsALeAEv4AW8gBfC eKHEC3gBL+AFvIAX8AJewAt4AS/gBbyAF/ACXgjjhQov4AW8gBfwAl7AC3gBL+AFvIAX8AJe wAt4IYwXaryAF/ACXsALeAEv4AW8gBfwAl7AC3gBL+CFMF5o8AJewAt4AS/gBbyAF/ACXsAL eAEv4AW8gBfCeKHFC3gBL+AFvIAX8AJewAt4AS/gBbyAF/ACXgjjhQ4v4AW8gBfwAl7AC3gB L+AFvIAX8AJewAt4IYwXeryAF/ACXsALeAEv4AW8gBfwAl7AC3gBL+CFMF7Y4QW8gBfwAl7A C3gBL+AFvIAX8AJewAt4AS+E8cL1FC8UP4x42mstpo6j/yWvuqyuI73WR2o8+Fq78pTXejzi Ukp5ZMTzoZRHDvQkSnlkDJSCUlDKk6GUR77NMSnlkVLzlLLkMrOWUhbVWEgpC8cOpJRF1U6n lIXDBlHKolrrKWVhmRWUsuyXFkIpyz5jyzBi4atYQSnncfRrKWVhhQBKWVhpNaUsej8WUsqy sddSysIqyyllUYEASllUZx2lLHspIZSysNIKSllY4XRKWTbwakpZVGYhpSwc+2RKWTjuyZRy 9rxQ4QW8gBfwAl7AC3gBL+AFvIAX8AJewAt4AS+E8UKNF/ACXsALeAEv4AW8gBfwAl7AC3gB L+AFvBDGCw1ewAt4AS/gBbyAF/ACXsALeAEv4AW8gBfwQhgvtHgBL+AFvIAX8AJewAt4AS/g BbyAF/ACXsALYbzQ4QW8gBfwAl7AC3gBL+AFvIAX8AJewAt4AS+E8UKPF/ACXsALeAEv4AW8 gBfwAl7AC3gBL+AFvBDGCzu8gBfwAl7AC3gBL+AFvIAX8AJewAt4AS/ghTBeuMYLeAEv4AW8 gBfwAl7AC3gBL+AFvIAX8AJeCOOFG7yAF/ACXsALeAEv4AW8gBfwAl7AC3gBL+CFMF64xQt4 AS/gBbyAF/ACXsALeAEv4AW8gBfwAl4I44U9XsALeAEv4AW8gBfwAl7AC3gBL+AFvIAX8EIY L9zhBbyAF/ACXsALeAEv4AW8gBfwAl7AC3gBLwTxQp/hBbyAF/ACXsALeAEv4AW8gBfwAl7A C3gBL4TxQo4X8AJewAt4AS/gBbyAF/ACXsALeAEv4AW8EMYLBV7AC3gBL+AFvIAX8AJewAt4 AS/gBbyAF/BCGC+UeAEv4AW8gBfwAl7AC3gBL+AFvIAX8AJewAthvFDhBbyAF/ACXsALeAEv 4AW8gBfwAl7AC3gBL4TxQo0X8AJewAt4AS/gBbyAF/ACXsALeAEv4AW8EMYLDV7AC3gBL+AF vIAX8AJewAt4AS/gBbyAF/BCGC+0eAEv4AW8gBfwAl7AC3gBL+AFvIAX8AJewAthvNDhBbyA F/ACXsALeAEv4AW8gBfwAl7AC3gBL4TxQo8X8AJewAt4AS/gBbyAF/ACXsALeAEv4AW8EMYL O7yAF/ACXsALeAEv4AW8gBfwAl7AC3gBL+CFMF64xgt4AS/gBbyAF/ACXsALeAEv4AW8gBfw Al4I44UbvIAX8AJewAt4AS/gBbyAF/ACXsALeAEv4IUwXrjFC3gBL+AFvIAX8AJewAt4AS/g BbyAF/ACXgjjhT1ewAt4AS/gBbyAF/ACXsALeAEv4AW8gBfwQhgv3OEFvIAX8AJewAt4AS/g BbyAF/ACXsALeAEvBPHCLsMLeAEv4AW8gBfwAl7AC3gBL+AFvIAX8AJeCOOFHC/gBbyAF/AC XsALeAEv4AW8gBfwAl7AC3ghjBcKvIAX8AJewAt4AS/gBbyAF/ACXsALeAEv4IUwXijxAl7A C3gBL+AFvIAX8AJewAt4AS/gBbyAF8J4ocILeAEv4AW8gBfwAl7AC3gBL+AFvIAX8AJeCOOF Gi/gBbyAF/ACXsALeAEv4AW8gBfwAl7AC3ghjBcavIAX8AJewAt4AS/gBbyAF/ACXsALeAEv 4IUwXmjxAl7AC3gBL+AFvIAX8AJewAt4AS/gBbyAF8J4ocMLeAEv4AW8gBfwAl7AC3gBL+AF vIAX8AJeCOOFHi/gBbyAF/ACXsALeAEv4AW8gBfwAl7AC3ghjBd2eAEv4AW8gBfwAl7AC3gB L+AFvIAX8AJewAthvHA9xQvlDyOe9lrLieMosl+KusjqNtJrfaTGQ6+1zcpTXuvxiEsp5ZER z4dSHjnQkyjlkTFQCkpBKU+GUh75NseklEdKzVPKksvMWkpZVGMhpSwcO5BSFlU7nVIWDhtE KYtqraeUhWVWUMqyX1oIpSz7jC3DiIWvYgWlnMfRr6WUhRUCKGVhpdWUsuj9WEgpy8ZeSykL qyynlEUFAihlUZ11lLLspYRQysJKKyhlYYXTKWXZwKspZVGZhZSycOyTKWXhuCdTytnzQoUX 8AJewAt4AS/gBbyAF/ACXsALeAEv4AW8EMYLNV7AC3gBL+AFvIAX8AJewAt4AS/gBbyAF/BC GC80eAEv4AW8gBfwAl7AC3gBL+AFvIAX8AJewAthvNDiBbyAF/ACXsALeAEv4AW8gBfwAl7A C3gBL4TxQocX8AJewAt4AS/gBbyAF/ACXsALeAEv4AW8EMYLPV7AC3gBL+AFvIAX8AJewAt4 AS/gBbyAF/BCGC/s8AJewAt4AS/gBbyAF/ACXsALeAEv4AW8gBfCeOEaL+AFvIAX8AJewAt4 AS/gBbyAF/ACXsALeCGMF27wAl7AC3gBL+AFvIAX8AJewAt4AS/gBbyAF8J44RYv4AW8gBfw Al7AC3gBL+AFvIAX8AJewAt4IYwX9ngBL+AFvIAX8AJewAt4AS/gBbyAF/ACXsALYbxwhxfw Al7AC3gBL+AFvIAX8AJewAt4AS/gBbwQxAt5hhfwAl7AC3gBL+AFvIAX8AJewAt4AS/gBbwQ xgs5XsALeAEv4AW8gBfwAl7AC3gBL+AFvIAX8EIYLxR4AS/gBbyAF/ACXsALeAEv4AW8gBfw Al7AC2G8UOIFvIAX8AJewAt4AS/gBbyAF/ACXsALeAEvhPFChRfwAl7AC3gBL+AFvIAX8AJe wAt4AS/gBbwQxgs1XsALeAEv4AW8gBfwAl7AC3gBL+AFvIAX8EIYLzR4AS/gBbyAF/ACXsAL eAEv4AW8gBfwAl7AC2G80OIFvIAX8AJewAt4AS/gBbyAF/ACXsALeAEvhPFChxfwAl7AC3gB L+AFvIAX8AJewAt4AS/gBbwQxgs9XsALeAEv4AW8gBfwAl7AC3gBL+AFvIAX8EIYL+zwAl7A C3gBL+AFvIAX8AJewAt4AS/gBbyAF8J44Rov4AW8gBfwAl7AC3gBL+AFvIAX8AJewAt4IYwX bvACXsALeAEv4AW8gBfwAl7AC3gBL+AFvIAXwnjhFi/gBbyAF/ACXsALeAEv4AW8gBfwAl7A C3ghjBf2eAEv4AW8gBfwAl7AC3gBL+AFvIAX8AJewAthvHCHF/ACXsALeAEv4AW8gBfwAl7A C3gBL+AFvBDEC0WGF/ACXsALeAEv4AW8gBfwAl7AC3gBL+AFvBDGCzlewAt4AS/gBbyAF/AC XsALeAEv4AW8gBfwQhgvFHgBL+AFvIAX8AJewAt4AS/gBbyAF/ACXsALYbxQ4gW8gBfwAl7A C3gBL+AFvIAX8AJewAt4AS+E8UKFF/ACXsALeAEv4AW8gBfwAl7AC3gBL+AFvBDGCzVewAt4 AS/gBbyAF/ACXsALeAEv4AW8gBfwQhgvNHgBL+AFvIAX8AJewAt4AS/gBbyAF/ACXsALYbzQ 4gW8gBfwAl7AC3gBL+AFvIAX8AJewAt4AS+E8UKHF/ACXsALeAEv4AW8gBfwAl7AC3gBL+AF vBDGCz1ewAt4AS/gBbyAF/ACXsALeAEv4AW8gBfwQhgv7PACXsALeAEv4AW8gBfwAl7AC3gB L+AFvIAXwnjheooXqh9GPO21VlPHkf+SVVlWV5Fe6yM1HnytXXnKaz0ecSmlPDLi+VDKIwd6 EqU8MgZKQSko5clQyiPf5piU8kipeUpZcplZSymLaiyklIVjB1LKomqnU8rCYYMoZVGt9ZSy sMwKSln2SwuhlGWfsWUYsfBVrKCU8zj6tZSysEIApSystJpSFr0fCyll2dhrKWVhleWUsqhA AKUsqrOOUpa9lBBKWVhpBaUsrHA6pSwbeDWlLCqzkFIWjn0ypSwc92RKOXteqPACXsALeAEv 4AW8gBfwAl7AC3gBL+AFvIAXwnihxgt4AS/gBbyAF/ACXsALeAEv4AW8gBfwAl4I44UGL+AF vIAX8AJewAt4AS/gBbyAF/ACXsALeCGMF1q8gBfwAl7AC3gBL+AFvIAX8AJewAt4AS/ghTBe 6PACXsALeAEv4AW8gBfwAl7AC3gBL+AFvIAXwnihxwt4AS/gBbyAF/ACXsALeAEv4AW8gBfw Al4I44UdXsALeAEv4AW8gBfwAl7AC3gBL+AFvIAX8EIYL1zjBbyAF/ACXsALeAEv4AW8gBfw Al7AC3gBL4Txwg1ewAt4AS/gBbyAF/ACXsALeAEv4AW8gBfwQhgv3OIFvIAX8AJewAt4AS/g BbyAF/ACXsAL///27rW3jiQ50PB81q8gsF9sLNzO+6UxMGB3z3qNnbV7NTuLBRaGwKtHmL5Z rYY9/36zDilKzUoWWVUZ0To87xlMS6BYEXXukU9mRsEL8MI+XriGF+AFeAFegBfgBXgBXoAX 4AV4AV6AF+AFeAFe2McLN/ACvAAvwAvwArwAL8AL8AK8AC/AC/ACvAAvwAu7eKEaeAFegBfg BXgBXoAX4AV4AV6AF+AFeAFegBfghX28YOEFeAFegBfgBXgBXoAX4AV4AV6AF+AFeAFegBf2 8YKDF+AFeAFegBfgBXgBXoAX4AV4AV6AF+AFeAFe2McLHl6AF+AFeAFegBfgBXgBXoAX4AV4 AV6AF+AFeGEfLwR4AV6AF+AFeAFegBfgBXgBXoAX4AV4AV6AF+CFfbwQ4QV4AV6AF+AFeAFe gBfgBXgBXoAX4AV4AV6AF/bxQoIX4AV4AV6AF+AFeAFegBfgBXgBXoAX4AV4AV7YxwsZXoAX 4AV4AV6AF+AFeAFegBfgBXgBXoAX4AV4YR8vFHgBXoAX4AV4AV6AF+AFeAFegBfgBXgBXoAX 4IV9vFDhBXgBXoAX4AV4AV6AF+AFeAFegBfgBXgBXoAX9vHCObwAL8AL8AK8AC/AC/ACvAAv wAvwArwAL8AL8MI+XriAF+AFeAFegBfgBXgBXoAX4AV4AV6AF+AFeAFe2McLl/ACvAAvwAvw ArwAL8AL8AK8AC/AC/ACvAAvwAv7eOEKXoAX4AV4AV6AF+AFeAFegBfgBXgBXoAX4AV4YR8v XMML8AK8AC/AC/ACvAAvwAvwArwAL8AL8AK8AC/s44UbeAFegBfgBXgBXoAX4AV4AV6AF+AF eAFegBfghV28cG7gBXgBXoAX4AV4AV6AF+AFeAFegBfgBXgBXoAX9vGChRfgBXgBXoAX4AV4 AV6AF+AFeAFegBfgBXgBXtjHCw5egBfgBXgBXoAX4AV4AV6AF+AFeAFegBfgBXhhHy94eAFe gBfgBXgBXoAX4AV4AV6AF+AFeAFegBfghX28EOAFeAFegBfgBXgBXoAX4AV4AV6AF+AFeAFe gBf28UKEF+AFeAFegBfgBXgBXoAX4AV4AV6AF+AFeAFe2McLCV6AF+AFeAFegBfgBXgBXoAX 4AV4AV6AF+AFeGEfL2R4AV6AF+AFeAFegBfgBXgBXoAX4AV4AV6AF+CFfbxQ4AV4AV6AF+AF eAFegBfgBXgBXoAX4AV4AV6AF/bxQoUX4AV4AV6AF+AFeAFegBfgBXgBXoAX4AV4AV7Yxwvn 8AK8AC/AC/ACvAAvwAvwArwAL8AL8AK8AC/AC/t44WIFL+TqjCkjeWGKaMsR8MJ0os7t44VD DHgBXoAXXgAvtHezLV6FFw6p0gZemA6sUZYXDjmqDC+02M54LV44ZMvDeWEKa60OLxxyZXFe mNI4K8kLhwxRgxemTN7IDNAPsUV54ZChyp19qJK8MGWISYMXpkzJy/PClCcbGV44xI7SvDBl KUaQFw4JkjwvTHmq7bw1Lm/uv5jeXU+1ciuEv31z9fbd9eX79pOWe0o2vZhXJMqijtFSeOMe pvDh+u5JmcY8b1qWVvq8fffvb66/nwro6WN9+ihZkSJrUMmUyc7vzMWlqXdVyZ+vf/7xzY/t FfZdG2S0h+vt+798cfltG9x9UdLhFT19iqUV2bIkzEwZ5t+GA2DmEDh1YKZeL8NMulgDM1Ma P3s+sr0xF70X1917Zv2ry8+eBX9jqvv0U2V66t/8/OP0QJXDp3x9fuHjg5PBpUPsPB6XprjR jselQ9wsi0tTjmSewqXLdbjkp2/oobjkUz4OXPLZ7sYlnz24BC6BSy8Cl+JkBjq4FK3fhktx snthXIrOieFSdFkRl6K3ErgUfVTDpRiMBi7FEIVxKYaqhEtRavXHIXYRxqWYvNzZJ2lcilkL l2JxKrgUSxHDpVi9Ai7FWmRxKc2hRASXkik6uJSsl8alNBeS0biU5t/jQriU5mYiiEvJW2Fc SvMv+DG4lObf5hK4lEIQx6U0/z4fikspejFcSvNv8SG4lJITwaWU5HEp5Sdx6WodLqU8GpfS VF0cAy6laT5nJy6lqcABl8AlcOkF4FKeVgXp4FKepka34FJ76YjjUjFRDJeKqYq4VOaDhBG4 VGxSw6XiVHCpuCCMS8UVJVwqXo5nyny+djAulWDlzj4UYVwqOhujpkzJquBSSUkMl0q2CrhU euujRuJSmS+NEsGlMl8hJYNLpRppXCrzJcijcakao4RL1QRFXKrzGmIwLtV53TAGl+p8blAC l6qTX7lUnezKpeqtGC5Vn0Rwqc7tcAgu1dnU33hcqqE8hUvX63CpTuu4huJSPYquO4cTLbtx qU5LycAlcAlcOn5c8maa4VXBJW8nI9qAS+1A8W1x3lojhUstdtDDpZatCuCSb68OLVxquYoC Lnk7X0g/FpdahqyDS97OF9SP4pkWO8nikrfRyp39g+X1w3HJ26SES94+2K4mhEstjxguedvb sDYal1oWWVzydr5dTQKXWh4dXPJuPoUzGJdaCmlc8s4q4VLLpIhLLZswLnnngggutcAauOTd fHplNC61HKK45J3ctrgWWwSXvIsiuNTiiuNSy/EkLt2swiXv0mBcahHjUeBSO9HduOTdNPME LoFL4NILwCVf1HDJT1OjW3DJ1yCOS36+jWIYLoV52S6IS8FECVwKpqrhUphPokrgUui1dhqK S2Hex0IIl8K8u9MwngmuCuNSkFt35UMwwrgUgtK2OB+iyra4lkdsW5wPSWFbXMsiuy3Oh+xV cClknW1xPhTpbXEthfS2OB+q0ra4lklxW5yPRnhbXMuQZHApWo1tcS1NFMelaEW3xfnoghgu xfm3+BBcit6L4FL04tvi/KH/wiIuXZh1uBTD4G1xLeJx9FzyMe7eFtdi0HMJXAKXXgYupUl8 dHApTXXfFlxK81ajw3Ep9wBoEC7ledkmiEt5XsuNwKVsgxou5XkNJ4FLWXpbXMugtC3OZ0Ge ydLb4nwWXHeVpRt6+/xgjlUOl7LOtriWJ4vhUs5OAZdyZ+3VUFzKRWflUp6DjAwu5TnLjMal 3PGYwbhUeggjgkudjfSCuFR6K7KG4lKxMj2XWuCqgUvFya9c6mxzH4pLxYv1XPKdze1DcKmz pX0ILpXZSqvxuFSm2mAZl+w6XCrT9M9QXCrxSFYulVh349Jh3z+4BC6BSy8Al2pWW7lUy8aV S7XIr1yqRW7lUq1OEZdqFVm5VKvayqVgjMbKpZZGeOVSMFZp5VLLJLZyqcUWXrkUjPNyZ++E cSkYr4RLwQSVlUstjxguBRMVcKllkcWlYJIKLrU8OtvigsnS2+JaCultccEUpW1xLZMiLgVT hXGpZZDZFtcCa+BSsEYcl1oOUVwK1opti2uxRXApWCeCSy2uOC61HE/ikluFS+HQamEkLrWI x9HQu53oblwKNoBL4BK49CJwKbhclXApuLJt5VLoXPV5NC6F3hWfB+FSix31cKllk+i5FLxR 67nUcmn0XAq+t/tuKC55q7RyKXgntvanxRZeuRS8t3Jn74UbegcflHouBR9Vei61PGI9l4JP Cg29WxbZnkutYFVp6N3yKOGSL+K45Is4LvmqhUudzfqCuOSrcM+lEIwQLgWj0XMpBCve0Dt0 NtIPxaXgxBp6t9giPZdCq9ZEcCl48Z5LLcdTPZcu/DpcCmFwz6UW8ThWLrUT3d1zqd1XGnqD S+DSy8ClmLRWLoWYt61cageKr1xqOcRWLoWHFxCXxaVYkgQuxaK3cqlztXIJXIpVeuVSMlor l5KRW7mUjPTKpWTlaCxZ6ZVLyWmtXEpeZ+VS8nIrl1LQWLmUgvDKpRR1Vi6lqLMtLqQkjksp SW+LCylr4VLKmiuXUpFeuZSKEC6lorJyKVX5lUupyq5cykZu5VI2MiuXspVZuZStPC4d+i8s 41JYh0vZjV65lN2R4FJ2+1cuZc/KJXAJXHoZuFT0cOlwDeotuNS5rPRwXOpcWXoYLpWieLW4 lk1k5VKpeiuXSlVZuVSN9MqlapSuFheqIM9UK3y1uFCd3Mqlh5ePHo9L1WutXKpBZ+VSDXIr l2pUuFpcyyK8culw0WQFXKop6uBSnbPMaFyq81mi0bhUc1XCpc5mfUFc6mzbH4xLdf4FPwaX 6nwORwCXojHiK5dajiSJS9FYsZVLsbNxfgQutT9EVi61P4I0LrU/8lO4FFfhUjTejMWlFjEc BS61E817canFqOASuAQuvQRcijZq4VK0advKpfjwUt8CuNRyiK1cijYrXi2uZZPoudTCqq1c irZorFxqaYRXLsXO9cplcKllElu51GIXWVyKzojRWIstvC0uPrwouRguRedUGnq3PGK4FJ1X 2BbXssiuXIouqOBS7FxBXASXYueS4oNxKc6vLj4al1oKJVyKLiniUssmvC0uuiyDSy2wxra4 6Io8Lrkiui0udpozDMMlV0W2xUVvZHDJG/GVS/HQf2EZl9I6XPJ2NC55eyS4dOgBsROXvGNb HLgELr0MXArTqnsdXApbcSkk8ZVLLUcVw6WQFVcuxc61q0fgUpjXbmK4FHrqMx6XOpetHoxL nctVC+FS51LVw3gmzrfcDcalztWqx529FV65FOODduRyuBR7zckFcCn6KIZLMSisXGpZZFcu tQRVBZdi1Fm5FGMSx6WYpFcutRRauBTnGCOIS51t+4NxKRYhXIpFZeVSnMPMcFyKVXblUmcb /TBc6mycH4JLnU3zQ3ApWfmVS8k+uXIpr8Ol5EbjUnJHgkvJ7V+5lBwrl8AlcOll4NLhQt06 uJTjtm1xMUd5XMpRDpdyUuy51LJJ9FyKeb5rQgyX8lzjJHAp5yKMS7kjcjK4lEsS45lchHsu xVy93NlX4Z5LsTzYLCGHS8Wq9FxqeVb3XKIipCKkIjz+ijAZtbXst6k2VIS3B8pWhL0coyrC fmypirCXbUBF2A8rUxH2cglUhP00IyvC7oMmUhF2X2ODaqr+vRhZEaqe/fCKsJ9BoiLsZxpf Efaej1HTjd3Yw6cb+1kGTjf2EkhMNz7y1hg/3dhLNHi6sZdi8HRj92kRmW7s3hmx6cb+/Ro5 3djPMGC6sRt4/HRjL83o6cbucz5wurEXf9R0Yz/2/unGftz9042duMOnG29zLE03FlNWTTfe Rxw23Xgb8QimG29PdN90420McAlcApfAJXAJXAKXwCVwCVwCl8AlcAlcApfApZeDSxVcApfA JXAJXAKXwCVwCVwCl8AlcAlcApfAJXAJXAKXtuLSObgELoFL4BK4BC6BS+ASuAQugUvgErgE LoFL4BK4BC5txaULcAlcApfAJXAJXAKXwCVwCVwCl8AlcAlcApfAJXAJXNqKS5fgErgELoFL 4BK4BC6BS+ASuAQugUvgErgELoFL4BK4tBWXrsAlcAlcApfAJXAJXAKXwCVwCVwCl8AlcAlc ApfAJXBpKy5dg0vgErgELoFL4BK4BC6BS+ASuAQugUvgErgELoFL4NJWXLoBl8AlcAlcApfA JXAJXAKXwCVwCVwCl8AlcAlcApfApY24ZA24BC6BS+ASuAQugUvgErgELoFL4BK4BC6BS+AS uAQubcUlCy6BS+ASuAQugUvgErgELoFL4BK4BC6BS+ASuAQugUtbccmBS+ASuAQugUvgErgE LoFL4BK4BC6BS+ASuAQugUvg0lZc8uASuAQugUvgErgELoFL4BK4BC6BS+ASuAQugUvgEri0 FZcCuAQugUvgErgELoFL4BK4BC6BS+ASuAQugUvgErgELm3FpQgugUvgErgELoFL4BK4BC6B S+ASuAQugUvgErgELoFLW3EpgUvgErgELoFL4BK4BC6BS+ASuAQugUvgErgELoFL4NJWXMrg ErgELoFL4BK4BC6BS+ASuAQugUvgErgELoFL4BK4tBWXCrgELoFL4BK4BC6BS+ASuAQugUvg ErgELoFL4BK4BC5txaUKLoFL4BK4BC6BS+ASuAQugUvgErgELoFL4BK4BC6BS1tx6RxcApfA JXAJXAKXwCVwCVwCl8AlcAlcApfAJXAJXAKXtuLSBbgELoFL4BK4BC6BS+ASuAQugUvgErgE LoFL4BK4BC5txaVLcAlcApfAJXAJXAKXwCVwCVwCl8AlcAlcApfAJXAJXNqKS1fgErgELoFL 4BK4BC6BS+ASuAQugUvgErgELoFL4BK4tBWXrsElcAlcApfAJXAJXAKXwCVwCVwCl8AlcAlc ApfAJXBpKy7dgEvgErgELoFL4BK4BC6BS+ASuAQugUvgErgELoFL4NJGXHIGXAKXwCVwCVwC l8AlcAlcApfAJXAJXAKXwCVwCVwCl7bikgWXwCVwCVwCl8AlcAlcApfAJXAJXAKXwCVwCVwC l8ClrbjkwCVwCVwCl8AlcAlcApfAJXAJXAKXwCVwCVwCl8AlcGkrLnlwCVwCl8AlcAlcApfA JXAJXAKXwCVwCVwCl8AlcAlc2opLAVwCl8AlcAlcApfAJXAJXAKXwCVwCVwCl8AlcAlcApe2 4lIEl8AlcAlcApfAJXAJXAKXwCVwCVwCl8AlcAlcApfApa24lMAlcAlcApfAJXAJXAKXwCVw CVwCl8AlcAlcApfAJXBpKy5lcAlcApfAJXAJXAKXwCVwCVwCl8AlcAlcApfAJXAJXNqKSwVc ApfAJXAJXAKXwCVwCVwCl8AlcAlcApfAJXAJXAKXtuJSBZfAJXAJXAKXwCVwCVwCl8AlcAlc ApfAJXAJXAKXwKWtuHQOLoFL4BK4BC6BS+ASuAQugUvgErgELoFL4BK4BC6BS1tx6aKHS/FB xA8P4X+8e3sori+m996s4I2983BfZOtMdg/uqzXn7vrm/jH86frb9sk+PTtThXLhd0Senp2b fB/5wyn3n541gbc+PU/kWHx6SnrO0zOPuNb+noj4+djfEyf6LPt7Igb2h/1hf0djf0+8m+/t L9zb309/2mh/T6R63P5WfX9ttL9VOVba38rYO+1vVbbn29/KsLvsb1Wu7fa3Ms0G+1v3oO2x v3WvsXV6tvJebLC/z+Pst9rfygw77G9lps32t+r5WGl/62Jvtb+VWdbb36oEO+xv7Vtjs/2t SuSLv7n9NPz++vpqytTei9M43p73+GdV7G2uuCaFu7A+3H6Bt+FD+3T9/uq7n/5tek/k6U2R /a7zD+dX5e7z6fac37Sx/1Q5Tw/P9DHi9jz0Ll2el7sP2FZjH1Tswyj9aop+fbULFmo6v7r/ +L6ZCv3pMffT95sv+2AhX1/8gqruPaRrVatOO0V/Xe9Ouz3qb9//5dYM20Dju7c//fT2UPnZ qfLzO3Xk2sa/A3R+LdDJgA6gA+gAOoAOoAPoADqADqAD6AA6gA6gA+gAOoDOcYFOAXQAHUAH 0AF0AB1AB9ABdAAdQAfQAXQAHUAH0AF0jgt0KqAD6AA6gA6gA+gAOoAOoAPoADqADqAD6AA6 gA6gc1ygcw7oADqADqAD6AA6gA6gA+gAOoAOoAPoADqADqAD6BwX6FwAOoAOoAPoADqADqAD 6AA6gA6gA+gAOoAOoAPoADrHBTqXgA6gA+gAOoAOoAPoADqADqAD6AA6gA6gA+gAOoDOcYHO FaAD6AA6gA6gA+gAOoAOoAPoADqADqAD6AA6gA6gc1ygcw3oADqADqAD6AA6gA6gA+gAOoAO oAPoADqADqAD6BwX6NwAOoAOoAPoADqADqAD6AA6gA6gA+gAOoAOoAPoADpHBTrVADqADqAD 6AA6gA6gA+gAOoAOoAPoADqADqAD6AA6xwU6FtABdAAdQAfQAXQAHUAH0AF0AB1AB9ABdAAd QAfQOS7QcYAOoAPoADqADqAD6AA6gA6gA+gAOoAOoAPoADqAznGBjgd0AB1AB9ABdAAdQAfQ AXQAHUAH0AF0AB1AB9ABdI4LdAKgA+gAOoAOoAPoADqADqAD6AA6gA6gA+gAOoAOoHNcoBMB HUAH0AF0AB1AB9ABdAAdQAfQAXQAHUAH0AF0AJ3jAp0E6AA6gA6gA+gAOoAOoAPoADqADqAD 6AA6gA6gA+gcF+hkQAfQAXQAHUAH0AF0AB1AB9ABdAAdQAfQAXQAHUDnuECnADqADqAD6AA6 gA6gA+gAOoAOoAPoADqADqAD6AA6xwU6FdABdAAdQAfQAXQAHUAH0AF0AB1AB9ABdAAdQAfQ OS7QOQd0AB1AB9ABdAAdQAfQAXQAHUAH0AF0AB1AB9ABdI4LdC4AHUAH0AF0AB1AB9ABdAAd QAfQAXQAHUAH0AF0AJ3jAp1LQAfQAXQAHUAH0AF0AB1AB9ABdAAdQAfQAXQAHUDnuEDnCtAB dAAdQAfQAXQAHUAH0AF0AB1AB9ABdAAdQAfQOS7QuQZ0AB1AB9ABdAAdQAfQAXQAHUAH0AF0 AB1AB9ABdI4LdG4AHUAH0AF0AB1AB9ABdAAdQAfQAXQAHUAH0AF0AJ2jAp1zA+gAOoAOoAPo ADqADqAD6AA6gA6gA+gAOoAOoAPoHBfoWEAH0AF0AB1AB9ABdAAdQAfQAXQAHUAH0AF0AB1A 57hAxwE6gA6gA+gAOoAOoAPoADqADqAD6AA6gA6gA+gAOscFOh7QAXQAHUAH0AF0AB1AB9AB dAAdQAfQAXQAHUAH0Dku0AmADqAD6AA6gA6gA+gAOoAOoAPoADqADqAD6AA6gM5xgU4EdAAd QAfQAXQAHUAH0AF0AB1AB9ABdAAdQAfQAXSOC3QSoAPoADqADqAD6AA6gA6gA+gAOoAOoAPo ADqADqBzXKCTAR1AB9ABdAAdQAfQAXQAHUAH0AF0AB1AB9ABdACd4wKdAugAOoAOoAPoADqA DqAD6AA6gA6gA+gAOoAOoAPoHBfoVEAH0AF0AB1AB9ABdAAdQAfQAXQAHUAH0AF0AB1A57hA 5xzQAXQAHUAH0AF0AB1AB9ABdAAdQAfQAXQAHUAH0Dku0LnogU56EHFnWZh6J+i/SK5mk4aU hasy7CoLV2VaWVitvBcbysLP4+y3loUrM+woC1dm2lwWrno+VpaF62JvLQtXZllfFq5KsKMs XPvW2FwWrkq0sixcFXtbWbgmxeqycFXw1XXbmujr6rZVj/vaum3Vae+o21beiefXbSsDP7+6 WhN4a3X1RI6l6qqa+Jzqah5x7XTZExE/n+myJ070WdNlT8RguozpMqbLjma67Il388jpsidS PT5dtur7a+N02bryc9102crYO6fL1o1inz1dtjLsrumylWCBi+AiuAgugovgIrgILoKLPOUi CRfBRXARXAQXwUVwEVwEF8FFcBFcBBfBRXARXOREXSTjIrgILoKL4CK4CC6Ci+AiuAgugovg IrgILoKLnKiLFFwEF8FFcBFcBBfBRXARXAQXwUVwEVwEF8FFcJETdZGKi+AiuAgugovgIrgI LoKL4CK4CC6Ci+AiuAgucqIuco6L4CK4CC6Ci+AiuAgugovgIrgILoKL4CK4CC5yoi5ygYvg IrgILoKL4CK4CC6Ci+AiuAgugovgIrgILnKiLnKJi+AiuAgugovgIrgILoKL4CK4CC6Ci+Ai uAgucqIucoWL4CK4CC6Ci+AiuAgugovgIrgILoKL4CK4CC5yoi5yjYvgIrgILoKL4CK4CC6C i+AiuAgugovgIrgILnKiLnKDi+AiuAgugovgIrgILoKL4CK4CC6Ci+AiuAgucpouYg0ugovg IrgILoKL4CK4CC6Ci+AiuAgugovgIrjIibqIxUVwEVwEF8FFcBFcBBfBRXARXAQXwUVwEVwE FzlRF3G4CC6Ci+AiuAgugovgIrgILoKL4CK4CC6Ci+AiJ+oiHhfBRXARXAQXwUVwEVwEF8FF cBFcBBfBRXARXOREXSTgIrgILoKL4CK4CC6Ci+AiuAgugovgIrgILoKLnKiLRFwEF8FFcBFc BBfBRXARXAQXwUVwEVwEF8FFcJETdZGEi+AiuAgugovgIrgILoKL4CK4CC6Ci+AiuAgucqIu knERXAQXwUVwEVwEF8FFcBFcBBfBRXARXAQXwUVO1EUKLoKL4CK4CC6Ci+AiuAgugovgIrgI LoKL4CK4yIm6SMVFcBFcBBfBRXARXAQXwUVwEVwEF8FFcBFcBBc5URc5x0VwEVwEF8FFcBFc BBfBRXARXAQXwUVwEVwEFzlRF7nARXARXAQXwUVwEVwEF8FFcBFcBBfBRXARXAQXOVEXucRF cBFcBBfBRXARXAQXwUVwEVwEF8FFcBFcBBc5URe5wkVwEVwEF8FFcBFcBBfBRXARXAQXwUVw EVwEFzlRF7nGRXARXAQXwUVwEVwEF8FFcBFcBBfBRXARXAQXOVEXucFFcBFcBBfBRXARXAQX wUVwEVwEF8FFcBFcBBc5TRdxBhfBRXARXAQXwUVwEVwEF8FFcBFcBBfBRXARXOREXcTiIrgI LoKL4CK4CC6Ci+AiuAgugovgIrgILoKLnKiLOFwEF8FFcBFcBBfBRXARXAQXwUVwEVwEF8FF cJETdRGPi+AiuAgugovgIrgILoKL4CK4CC6Ci+AiuAgucqIuEnARXAQXwUVwEVwEF8FFcBFc BBfBRXARXAQXwUVO1EUiLoKL4CK4CC6Ci+AiuAgugovgIrgILoKL4CK4yIm6SMJFcBFcBBfB RXARXAQXwUVwEVwEF8FFcBFcBBc5URfJuAgugovgIrgILoKL4CK4CC6Ci+AiuAgugovgIifq IgUXwUVwEVwEF8FFcBFcBBfBRXARXAQXwUVwEVzkRF2k4iK4CC6Ci+AiuAgugovgIrgILoKL 4CK4CC6Ci5yoi5zjIrgILoKL4CK4CC6Ci+AiuAgugovgIrgILoKLnKiLXPRcJPcihi9Kqbnm TS7yeMRiyufkIgsnau0zXWQphsdFcBFc5Ihc5PF3c/X1Exfx9y5y+eNGF1lIFeySiywdWAe5 yEKO6He6yFLsPNxFFrIlu91FlsLGwS6ykCvbcS6ylCYOcZGlDHWoiyxkKmGnLCzFzkNcZCFD tUJnX9vHpRniIksZxrrIQibrBrrIUp6600UWYjs/zEWWsuQRLrKQwLuBLrKUJ48hhYUUYX5X rv1VvLsr7Tk5vIAPxdCb9oF7df6n9p+WqB7GcpdlRaY5Jl2ni9vvpu/O/7N9AX7/yxRuGuv6 q+dniGaeId99Tb1rFevPF9+9nR4ke9mjnaXAsw/Yi2yubj/K7yq9WwSYiOTd3dmfT093vMwr 0pT5J2HLfV+H3PwwjRVvhzSHsmEa5kzPRUt0/vw0ycl94KY854Zy93L6gDF3D1DfYhZizyuD m4vrm3BvJHdx6/Sxd+NWxA0dIimX90RyF7cvJEtx6yAhWchR3FNCcrlGSKaIcaiQTBGPQkja ida9QjLFQEgQEoTkJQhJbaVw0hGSKVXdIiTVOOOEhWTKkYSEpMW2Rk1IpmxhvJBMYbOSkLRc TkFIpjSyQjJl0BGSlsl7sZLXeVkhaRmCnJC4kIWFxEWnJCTuwfhJSkhc8mJC4lJWEBI3H0qN FRI351URIXHFSAuJm+uqkJC4UoSFxFUnIySuRg0hcbVqCIk3cl8X3sgJibcyQtI+WkSExFt5 IfFTtbQsJFfrhMS7MFhI/ATWxyAk3pvdQuK9RUgQEoTkRQhJ8EFLSMI00NoiJCEYcSEJIYgJ SQhFUUhCdBJCEmJUE5IQq4aQhPk4cLCQhJSVhCRkOWMI88HgYCEJucqdfYnCQhKqURKSUJOK kERjxYQkmqggJNFUWSGJ1qsISbRFWkii01pDEp30GpLohdaQxDlBSwhJnGu0hJBEQZKOIYoJ SZwvJx4iJHFeNA0RkhiTuJDEqVpaFpLrdUISkx0sJO10jkNI4lSx7RSSmCpCgpAgJC9CSFJ2 WkKSppWMW4Qk5SIuJKk4MSFJJSkKSapWQkhSDWpCkmrREJI8X5s0WEhGdx9ZyNRZpzSq5M2d VUljhSTbLHf2D3Z1jBeS/GClkJyQZB9VhCTPTXqYkOSgscsmB+FdNjnq7LLJMUkLSU5GSUhy CsJCklOREZKcnYaQ5Jw0hCQXwa+LEsSEJM8XIQ0RklytiJDk2cqj8UKSp2ppWUhu1glJmTam DhWSYo5ESMqz+7MuxSgICUKCkLwIIanTskUdIal2o5DU+fhpuJDU+caOYUJS57s5BIWkdnZ2 DBCS6p2akFSfNISkzseBg4WkhqAkJLWzTmlUyVs7q5LGCkmNSe7sH/TlGS8kNWUlIanZqwhJ nZv0MCGpc4sWEJJakqyQ1GpUhKTOZXq0kNRadISkvau9rJC0DFlESKyZE7SAkLQ0QUFIWhqx r4v25eCkhKTFThJC0uJWCSGxZrbyaLiQtBxPdWr1ZpWQTI2ZxwpJK9jtUQhJO9GwV0jsodsS QoKQICTHLyTWBqVOrS1V3NSpdTowSgtJy1GlhMTa5PWEpGVLAkLSxnRGS0harqAgJC1NkRUS a4vTEZKWScwYrJ0PBscKScvgBc++ygqJdSbqCIl11moIScsTpYSkxa7yQmJdrx/sQCFpCYqG kLQvZScsJC1FUhISF4ywkLgQZITEzQlaQkhcdBpC4uYl1bAPXBermJB0GiQNERLX6y47QEjm 7ZDGC4mb2HxZSOw6IXE5DRYSN22jPQYhcVPFtlNIXKFTK0KCkLwMIfHTdSp0hMSXbZ1arZ+P n4YLia9inVptMIqdWls2iU6tLaxap1YbrNMQkmCTsJAEq9Sp1QYXxEre4IQ7tdrgrdzZe+FO rTYEpU6t9mFHIykhCVGsU2uLrdCp1YYk26m1JVDp1GpDlu7U2lIodWptmYQ7tdpQZDq12oft jISEJBSNTq02CJJ0qGKdWm2nQdIQIek0RxoiJPN2SOOFJNqnOrV6t05IDj2WhgpJtMfRqbWd aN0tJNHRqfWzF5LVn2vJ9Nrkjywk+xkkCsl+pvGFZOpcmm1UIdmNPbyQ7GcZWEj2EkgUkr08 gwvJ7l0RKST7mUYWkv0MAwrJbuDxhWTSuShiP82YQrIXe1Qh2Y+9v5Dsx91fSHbiDi8kb3Ms FpIlriok7yMOKyRvIx5BIXl7ovsKydsYFJJMtTHVdvxTbbfvZpWptttUG6bael9fo6fauiXD oKm2fmypqbZetgFTbf2wMlNtvVwCU239NCOn2roPmshUm3bJO3aqTfXsERKEBCFBSBAShORU hCQhJAgJQoKQICQICUKCkCAkCAlCgpAgJAgJQoKQnLyQZIQEIUFIEBKEBCFBSBAShAQhQUgQ EoQEIUFIEJKTF5KCkCAkCAlCgpAgJAgJQoKQICQICUKCkCAkCAlCcvJCUhEShAQhQUgQEoQE IUFIEBKEBCFBSBAShAQhQUhOXkjOERKEBCFBSBAShAQhQUgQEoQEIUFIEBKEBCFBSE5eSC4Q EoQEIUFIEBKEBCFBSBAShAQhQUgQEoQEIUFITl5ILhEShAQhQUgQEoQEIUFIEBKEBCFBSBAS hAQhQUhOXkiuEBKEBCFBSBAShAQhQUgQEoQEIUFIEBKEBCFBSE5eSK4REoQEIUFIEBKEBCFB SBAShAQhQUgQEoQEIUFITl5IbhAShAQhQUgQEoQEIUFIEBKEBCFBSBAShAQhQUhOXUiqQUgQ EoQEIUFIEBKEBCFBSBAShAQhQUgQEoQEITl5IbEICUKCkCAkCAlCgpAgJAgJQoKQICQICUKC kCAkJy8kDiFBSBAShAQhQUgQEoQEIUFIEBKEBCFBSBAShOTkhcQjJAgJQoKQICQICUKCkCAk CAlCgpAgJAgJQoKQnLyQBIQEIUFIEBKEBCFBSBAShAQhQUgQEoQEIUFIEJKTF5KIkCAkCAlC gpAgJAgJQoKQICQICUKCkCAkCAlCcvJCkhAShAQhQUgQEoQEIUFIEBKEBCFBSBAShAQhQUhO XkgyQoKQICQICUKCkCAkCAlCgpAgJAgJQoKQICQIyckLSUFIEBKEBCFBSBAShAQhQUgQEoQE IUFIEBKEBCE5eSGpCAlCgpAgJAgJQoKQICQICUKCkCAkCAlCgpAgJCcvJOcICUKCkCAkCAlC gpAgJAgJQoKQICQICUKCkCAkJy8kFwgJQoKQICQICUKCkCAkCAlCgpAgJAgJQoKQICQnLySX CAlCgpAgJAgJQoKQICQICUKCkCAkCAlCgpAgJCcvJFcICUKCkCAkCAlCgpAgJAgJQoKQICQI CUKCkCAkJy8k1wgJQoKQICQICUKCkCAkCAlCgpAgJAgJQoKQICQnLyQ3CAlCgpAgJAgJQoKQ ICQICUKCkCAkCAlCgpAgJKcuJOcGIUFIEBKEBCFBSBAShAQhQUgQEoQEIUFIEBKE5OSFxCIk CAlCgpAgJAgJQoKQICQICUKCkCAkCAlCgpCcvJA4hAQhQUgQEoQEIUFIEBKEBCFBSBAShAQh QUgQkpMXEo+QICQICUKCkCAkCAlCgpAgJAgJQoKQICQICUJy8kISEBKEBCFBSBAShAQhQUgQ EoQEIUFIEBKEBCFBSE5eSCJCgpAgJAgJQoKQICQICUKCkCAkCAlCgpAgJAjJyQtJQkgQEoQE IUFIEBKEBCFBSBAShAQhQUgQEoQEITl5IckICUKCkCAkCAlCgpAgJAgJQoKQICQICUKCkCAk Jy8kBSFBSBAShAQhQUgQEoQEIUFIEBKEBCFBSBAShOTkhaQiJAgJQoKQICQICUKCkCAkCAlC gpAgJAgJQoKQnLyQnCMkCAlCgpAgJAgJQoKQICQICUKCkCAkCAlCgpCcvJBc9ISk9iKmL1yq NedNQrIQsXxWQrJwotU+U0iWYniEBCFBSI5ISB57N2fTavWxQrKQypklIVk6MA8SkoUc3u4U kqXYabiQLGQLZruQLIUNg4VkIVc044RkKU0YIiRLGcYKyUKm5HaWvEux0xAhWcpQ5c4+jxGS hQwlDBWShUzVDBSSpTx5p5A8HtsZO0xIlrLEEUKykMCagUKylCeNEZKFFM4MFZKlTGGIkCxl 2CUkC4G9GyckS2nSOCFZSDMvEoZ94LoQdwrJUuy6Q0gW4ka3Q0iW4o4SkoUcyT4lJJdrhGSK 6IcKyRQxH4OQtBPNZqeQTDEsQoKQICQvQkh8jlpC4ieZ3iIkvlhxIfEligmJL0VRSHx1EkLi a1ITkmBUhCQYaSEJJisJSbByQhJsFBaSYOWEJLgoLCTBGyUhCQ/GT1JCEoIVE5IQooKQhPlQ aqyQhOhVhCSMWkOykGKuq0JCEubWOlhIQjYyQhKy1xCSkLOGkIR5STXuA7fICUkoMkISqoyQ hFnVNF5IQq1PCcnVOiGJxg4WkjiVWscgJHGq2HYKSTQVIUFIEJIXISRpGlnpCEmyYZuQJFvE hSQ5JyYkyWmuIUmuSghJ8l5NSJLPGkKS5uPAwUKSQlQSkhTkjCHNJ9gGC0mKSe7sH4z/xgtJ SkVJSNKDYZqUkKRcxIQkFacgJKkkWSFJVWcNSapRWkhSrUpCko0XFpI8N+kxQpI7a4YEhCTb oCEk2RaxD9zsnJiQ5HkpNURIsqsiQpJnVdN4IckTmy8LyfU6Icm+DhaSHNxxCEmeKradQpJD QkgQEoTkRQhJiVZLSMo067ZFSEqU32VTktwum5KiopCUVCSEpGSnJiQlJw0hKcUIC0kpQUlI SpEreUuVFpIyHwYOO/v6YFfHeCGpD0ZlckJSrY6QVCu3y6Y6jV021QnvsqnzMZWIkFQfpIWk +qIkJDU4YSGpIckISY0qQlKjipDUKPd1UZOckNQkIyQ1yQhJzfJCUvOTQnKzTkhqLoOFpE5r lo5BSOpUse0UkloQEoQEIXkRQmLNtGxRRUismZogbRCSdmCUFpKWo0oJibXzmTM5IWnZkoCQ WGuNlpC0XEFBSFqaIisk7S3ldISkZRJbhdFiV1khsXa+QGnc2fsqKyTt1Rp1hMTaaDWEpOWJ UkLSYld5IbE2eVEhaQmyhpC0V4oTFpKWIukISfvANbJCYm0JIkLSAhcFIbG2OgUhaWkEvy5q lRIS6+al1AghaXGzhJDYNsCSFpKWwz8hJBdmlZDYQ++jkULSItajEJJWsLm9QmIP3ZYQEoQE IXkBQuKdVqfWlqpuExI/Hz8NFxI/39gxTEh8py2anJD4XkvV/ULiQ1ETEj/f1iEhJD4mYSHx ySgJiU9BrOT1KQsLic9W7uxzFhYSX7ySkDzsaCQlJL56MSHxnS6w44Uk9PrBjhSSMG8FKyIk YS7To4Uk2KAkJMEWYSEJzskISZgvSpIQkuCqhpAEQZIOPosJSadB0hAhCb3usgOEZN4OabyQ hPhUp9YLu05IDj2WhgpJiMfRqbWdaN0tJCHRqRUhQUhehpDEaWSlIyQxbevUauO8+9pwIYk5 iAlJzIqdWm0sEp1aW9ioJiSxanRqbWm8sJDEqtSp1SYjZwzJCHdqbRmq3NnbICwkySl1arUP OxpJCUnyYp1aW2yFTq0ti2ynVpuCSqfWlke6U6vt9BkSEpJOv6HBQpKSTKfWFlijU2tLo9Gp 1SZBkk5ZrFNriy3SqdV2miMNEZJ5O6TxQpLKU51aL9w6IUl1cKfWFvE4OrW2E93dqdUe+joh JAgJQvIChKS9BrSEpJhtnVrbgeKdWm2xYp1aW2zFPiQtm0SnVlucWqfWlkujU6stXrhTa8ug 1Km1ZZIzhhKE+5C0DHKLvksU7tRqH/ZJkhOSklT6kNhOL6NhQtJpaCQgJJ1WRmOFpNPESERI SpHu1NpSKHVqtaUKd2ptGWQ6tdpqNPqQtDQafUhaGrE+JLZasT4kLbZIHxJb5xe8HiIkdXZ5 6/FCUt1TfUgu/DohOfRYGiok1R9Hp9Z2ors7tbYY9CFBSBCSFyEkzkw7QFSEpKVym4SkHZik haTlEOtD4kyn+5qYkLRsWUBInJm3spUSkpYrKghJSyPch8SZrNSHpGUSM4YWW7gPiTPFy519 b2fKSCFxpgYdIXEPuyUJCYmz83HaKCFpsRV22bTCRnaXTUugssvGWSe9y6al8DpC0jJlWSFx dq7eQ4SkBQ4KQtLSFAUhcTaIXRze2WSlhKTFjhJC0uIWCSFxVr5Ta8sRnxKSsEpIWsTBnVqd LcchJO1EdwtJi5EREoQEIXkRQqLXh6RFN9uExM+Lk+FC4r2ckPig2KnVdRuG7BeSTm8QMSHx UWMNifPJCQtJt4OHiJD4LFfy+rm+DBYSX6zc2RfhPiTOqwlJMEZFSMK82/MwIQlW4Vo2LYvs tWxccCprSFqeJC0koacKIkISvPAuGxeCzC4b1+lUISEkIWj0IXEhirWtciGKdWp1Yd5ua4iQ BCEhCbOv5fFCEp4WkrhOSMJwIQnHIiRhgJCEaU4GIUFIEJIXICRJT0jSxk6tLikISRIUkqQq JCmIrCFJUe1aNi2XxrVsWhrpNSQpaa0h6e5fH1TypmyEhSRluYI9FSMsJA83m8sJyWGDuIKQ pConJHm+XUFASHJnFcxQIcnzfQoiQpKtlxaSbLOSkGQnfLXf6bUrIyS5c3VnASHJvRaq44Uk e7mvixzk1pDkILOGJAeRq/26HOXXkOT4pJCkdUKS42ghyek4rvbbTnT31X5bjIiQICQIyYsQ ksP2Wh0hqdOV2rYISZ2vyx4uJFWuD4nrbJ4VFJLqrISQVKfWqdVVr9Gp1VUfhYWk+qokJDXI GUMN0rtsapTbZVOTtJDUpCUkNav0IWl5qpiQ1OIVhKTOL846VkhqVenU2vJId2r1xijtsmmZ hK9l4431IkLSAmcFIfHGaVztt6UR25TpjRcTkhZbpA+JN0GkD0mLG6WFpOUoTwlJXiUk3sTB nVr9YaP5EQhJO9GyV0i8mSoOhAQhQUiOX0i8nQowFSHxbrrcxgYhaQdGaSHxzhopIWmxFfuQ eCfSqdU7vU6tLVdREBLvvPC1bFoGpV023sltLG+xhXfZeDdfoDTu7GOSFRLvktURkpYpawiJ d51uqoOEpMVO8kLiXTGiQtISBA0haXmqtJC4qiUkrgr3IfHeyPQhaYE1dtm0NBq7bLy3YiTd Yotd7dd7J3K13xY3iAiJn1Uy44XE+yev9lvWCYn3g6/22wIex9V+vZ+obKeQ+KkWQ0gQEoTk BQhJKFprSFqqbWtI2oHia0h8qGJrSFpsxTUkPhqJNSQtrNoaEh+txhqSlkZ4DYmPzigJSZwv 8RlW8kYnvIbERy9XsMcgvIakZVC6lo2PUWUNScsjtobExxQUhCQm2av9+phV1pC0POJCEjvY IyMksUivIYlVaA1JnK/lkRCSZFTWkCQjtsvGJ7lr2bTYMmtIUk9eBghJcvJrSJJ7cg1JXSck yY9eQ3K4xPsxCEny+9eQpGmbGUKCkCAkL0BI8lSA6QhJLtuuZdMOfPpaNqu/yJOVvgpoP4PE yKmfafzIaZZn4MipG3v4yKmfZeDIqZdAYuTUyzN45NS9KyIjp36mkSOnfoYBI6du4PEjp14a gZFTP82YkVMv9qiRUz/2/pFTP+7+kVMn7vCR022OpZHTuVnXwfE+4rCR023EIxg53Z7ovpHT bQxGToycGDkd/8jp9t2sMnK6TbVh5NT7+ho9t9wtGQbNLfdjS80t97INmFvuh5WZW+7lEphb 7qcZObfcfdBE5pa1S96xc8uqZ4+QICQICUKCkCAkpyIkCSFBSBAShAQhQUgQEoQEIUFIEBKE BCFBSBAShOTkhSQjJAgJQoKQICQICUKCkCAkCAlCgpAgJAgJQoKQnLyQFIQEIUFIEBKEBCFB SBAShAQhQUgQEoQEIUFIEJKTF5KKkCAkCAlCgpAgJAgJQoKQICQICUKCkCAkCAlCcvJCco6Q ICQICUKCkCAkCAlCgpAgJAgJQoKQICQICUJy8kJygZAgJAgJQoKQICQICUKCkCAkCAlCgpAg JAgJQnLyQnKJkCAkCAlCgpAgJAgJQoKQICQICUKCkCAkCAlCcvJCcoWQICQICUKCkCAkCAlC gpAgJAgJQoKQICQICUJy8kJyjZAgJAgJQoKQICQICUKCkCAkCAlCgpAgJAgJQnLyQnKDkCAk CAlCgpAgJAgJQoKQICQICUKCkCAkCAlCcupCYg1CgpAgJAgJQoKQICQICUKCkCAkCAlCgpAg JAjJyQuJRUgQEoQEIUFIEBKEBCFBSBAShAQhQUgQEoQEITl5IXEICUKCkCAkCAlCgpAgJAgJ QoKQICQICUKCkCAkJy8kHiFBSBAShAQhQUgQEoQEIUFIEBKEBCFBSBAShOTkhSQgJAgJQoKQ ICQICUKCkCAkCAlCgpAgJAgJQoKQnLyQRIQEIUFIEBKEBCFBSBAShAQhQUgQEoQEIUFIEJKT F5KEkCAkCAlCgpAgJAgJQoKQICQICUKCkCAkCAlCcvJCkhEShAQhQUgQEoQEIUFIEBKEBCFB SBAShAQhQUhOXkgKQoKQICQICUKCkCAkCAlCgpAgJAgJQoKQICQIyckLSUVIEBKEBCFBSBAS hAQhQUgQEoQEIUFIEBKEBCE5eSE5R0gQEoQEIUFIEBKEBCFBSBAShAQhQUgQEoQEITl5IblA SBAShAQhQUgQEoQEIUFIEBKEBCFBSBAShAQhOXkhuURIEBKEBCFBSBAShAQhQUgQEoQEIUFI EBKEBCE5eSG5QkgQEoQEIUFIEBKEBCFBSBAShAQhQUgQEoQEITl5IblGSBAShAQhQUgQEoQE IUFIEBKEBCFBSBAShAQhOXkhuUFIEBKEBCFBSBAShAQhQUgQEoQEIUFIEBKEBCE5dSFxBiFB SBAShAQhQUgQEoQEIUFIEBKEBCFBSBAShOTkhcQiJAgJQoKQICQICUKCkCAkCAlCgpAgJAgJ QoKQnLyQOIQEIUFIEBKEBCFBSBAShAQhQUgQEoQEIUFIEJKTFxKPkCAkCAlCgpAgJAgJQoKQ ICQICUKCkCAkCAlCcvJCEhAShAQhQUgQEoQEIUFIEBKEBCFBSBAShAQhQUhOXkgiQoKQICQI CUKCkCAkCAlCgpAgJAgJQoKQICQIyckLSUJIEBKEBCFBSBAShAQhQUgQEoQEIUFIEBKEBCE5 eSHJCAlCgpAgJAgJQoKQICQICUKCkCAkCAlCgpAgJCcvJAUhQUgQEoQEIUFIEBKEBCFBSBAS hAQhQUgQEoTk5IWkIiQICUKCkCAkCAlCgpAgJAgJQoKQICQICUKCkJy8kJwjJAgJQoKQICQI CUKCkCAkCAlCgpAgJAgJQoKQnLyQXHSEJNhexPJFKsH5tEVIliKG9BkJydKJRvM8IVmMgZAg JAjJEQnJwrvZ5zhUSBZTlQUhWTqwxDFCspij7hOSpdjVjxaSxWxls5AshA3GjhWSxVx5mJAs pbF2hJAsZogjhWQpkzP7St7F2H6EkCxmyHJnP5V7+4VkKUMYKiSLmco4IVnKE+M+IVmMXUcJ yVKW5AcIyWKCMk5IlvLkMERIFlOUkUKylKn4EUKymCHtEJKlwNUOE5LFNGkfLyzEjsZs54XF uH47LyzGrWN4YSnHVAMs88LlOl6I03f+UF6IthwHL7SafDcvxKnYgBfgBXjhBfBCckmLF5Kr 23gheSfOC8knMV5IwSjyQgpBghdSyGq8kKLV4IU0H0QN5oU0H0oJ8UKaD6eGDdBTysK8kLKV O/uchXkhFS1eSEWHF9IcRIfxQqpZgRfyXEPH8kI2UYUX8myMNZwXsg1KvJBtEeaF7JwML2QX NXghuyrGC9l7EV7IPovwQg5WnBdy8E/xwtU6Xshh9OqFHOpx8EJ+7v6OxRgBXoAX4IUXwQsl Zi1eKHEjL5T50Gk4L5T5EGoYL5TO4EmOF0oW4YWSixovlOI0eKHMZ7oG80KpRokXSg1iA/RS pXmhGjleqEaaF6r1SrxQrQ4vVCfHC9Vp8EL1wrxQvQ4v1LlNj+aFGrR4oQZpXqhRiBdqTBq8 UJMR44Wagggv1CTDCzXL80KdqqVlXrhexws1j+aFmo+EF2rZzwu1wAvwArzwInghmqLFCy3V Nl6IporzQsshxgvRGkVeaNkkeKGFVeOF2F6KCrzQ0gjzQrROiRdaJjFeaLGFeSFa7+TO3hdZ Xoj2wfBMjBeijUaDF1oesc0RLbbC5ohohTdHtARZgxeindv0YF5oKaIOL7RMVZYXou1tvxjA Cy1wVuCFaOd7MEbxQosdJXihxS0SvBCdcdK80HLEp3jhZhUvtIhlLC+0StceBS+0Ew17eaHF iPACvAAvvAhe8LZq8YKfdmZt4QXvxHsvtBxFjBe8d4q84OfbPEbwgvdVjRd88Bq84EMW5gU/ 3+UhxAt+PiAcNkD3vS0eQ3nBJzle8EmaF3zW4gVfdHih0+1mGC90utwI8EKn381YXvBVhxc6 PW9G80IwWrwQrBHmhWCFeCFYFV4ITo4XgpPhhdDb0DGAF8JsM8d4Xgj+KV7wZh0vBD+aF0I4 El4IYT8vhGlvCbwAL8ALL4AXYlDjhRg38kKM8rwQo1hrxxiTYmvHli1L8ELMRo0X4nx/hwQv xPl+j8G8EItT4oU43+gxbIAee1s8hvJCrF7w7KswL6QHwzM5XkgPmpFK8UKycryQrAYvJCfM C8np8EKn8dBoXuj0HRLihU4XosG8kHobPUbwQurs6xDghbT3yhGLsZMIL3Q6DA3hhXk/ofG8 kFJ6ihfsOl5IqQ7mhZTdcfBCmpZB7eSFQ6skeAFegBdeAC/kaT5Mhxdycdt4Ic+HTsN5IVcj xgtZ88oRLZsILxS9K0e0XFGDF8q8a9pgXijWK/FCsWLXXojFSfNCEdzaUbwR5oXSuzaFCC+U oMMLJSQxXijRKPBCiUGWF9r/VHih03hoNC90+g4J8UKnC9FgXii9jR4jeKF09nUI8EIpXowX SskivNDpMDSEF+b9hMbzwqGv0DIvuHW8UOpoXqjmSHihmv28cGiVBC/AC/DC8fNCMlaLF1qq bbzQDhTnhWScGC+02EGPF1o2iQtTJuPVeKHl0uCFlkaYF5IJSrzQMonxQjK9LR4jeWG6Nr3c 2SdhXmgZlHghmew0eKHlEeOFZIoCL7QssryQzHyPhwQvpE7jocG8kDp9h2R4IXW6EI3lhZZB hhdaYA1eSNaK8UKLLcILqdNhaAQvpHk/oeG8kA59hZZ5wa/ihWQnzh7JCy2iPwpeaCea9vJC iwEvwAvwwsvgBRfUeMFNY60tvODmQ6fhvOCiHC+4qMkLLorwgkt6vOCSCi+4JM0LLmvxgsty vOCKNC+4IscLrkrzgqtavOCNDi94k8V4wVsNXvBWmBe81eEF78R5wTstXvBemhe8F+KFTu8h CV7otB0axgudXkNDeMFHGV7wUZ4XfHySF8I6Xjh0KhrKC4fORMfACz7tXr3QYsAL8AK88DJ4 IWQ1Xgh54+qFkOVXL4QixwuhaPJCKBKbI1KoerwQqgovhCrNC9Fo8UI0crwQrfDmiJZBjhei k+aF6LR4IXqVzREtj9zqhRg0eCEGYV6IQWVzRIpRnBdi1OKFmKR5ISYhXohJhRdiluOFmGV4 IRYZXohFnhdieZIX4jpeiGU0Lxw6Ex0DL8S6nxdihRfgBXjhZfBCNmq8kM1GXshGnheyleOF bDV5IVuR1QvZ6fFCdiq8kJ00L2SvxQvZy/FCDtKrF3KQ44UcpXkhRy1eyEln9UJOcryQswYv 5CzMCznrrF7IRZwXctHihVyleSFXIV7IVYUXipHjhWJkeKFYGV4oVp4XDj2LlnkhreOFQ6ei obxQ3JHwQnH7N0cUBy/AC/DCy+CFOs2H6fBC9Rs3R1QvvzmiBjleqEGTF2oQ4YU6b2ktxgt1 3uJaghdqMsK8UJMWL9RUxAboNUvzQs1R7uyLFeaFWrR4oVYdXqhVbHNENvP99+N5oWWJorzQ EqjwQjZzmx7MCy1F0eGFbJyT5YWWIYnwQguswQvZeDFeaLFFeCGbYCV4ocWN0ryQDz2Llnkh r+KFbOJgXmgRj4MX2onu5oUWo8AL8AK88BJ4IdukxQst1TZeaAeK80K28yHUKF5osaMeL7Rs VYAXsi1qvNByafBCtlWYF1qGoMMLLZMYL2RnnCwvtAxJ7uytMC+0DFmHF7J7sBFfiBdaniLG C85r8ILzwrzgOtdYlOAFF8R5wQUtXnBRmhdcFOIFN7doCV5wKYjxgpsT9BBecFmGF1yW5wU3 XZx6mRfKOl44dCoayguHzkTHwAtuWga1kxdcgRfgBXjhZfCCn+bDdHjBT2OtLbzg50On4bwQ jBwvBKPJC8GI8EKwerwQ5i2uJXghOGleCE6LF4KT44XgpXkheDleaIWTMC+EoMULIerwQohy vBCSU+CF0NneMZQXQtbhhZDFeSF09nnI8EKY7/QYzAuhCPFCqCq8EKocL4QqwwvRyPBCNPK8 EM2TvFDX8cKhU9FQXjh0JjoGXoh2Py9ECy/AC/DCy+CF5NRWLyS3kReSk1+9kLwcLySvyQvJ i/BCCnq80L7dNXghRWleSFGLF1KU44WUpHkhpSh39ll69ULKWryQig4vpCK3OSJVjdULqQqv XkhVZ3NENuK8kI3W6oVspVcvZCvEC9mp8EJ2cryQnQwvZC/DC9nL80L2T/LC+TpeyGE0Lxw6 Ew3hhV9hWHw/JP4sR8T3w2FGw5/BaPgXg9/uWPeRwemqceWKYWFJ92vW1o36Vo/b7hPOVoKt GTlNfcAOh7sVR3yoY1YObkoqawcrG0v4kma0v3GgMbUOuI30/OSH7pS98cMnv/G8zdGr6/2S D4/U2vJ92u/xr+uq8vJJebOmzi6deuVDnf38YrrcdUF8/u/7T7KuOOpD/bO6hN1UjE6TXfen ub7kLPnBWt9ecflIZbi+mNtVrH1alz27vvmkiNGfCimHnnb7pkJajLg0FbJvJuR+BuTj7Mf9 xAfzHsx7vIB5jyfrvW65t3ISYU25V+9GnErFXqeP0apqr35YbeRWHHIve2vrvZrcyoJva703 68aztdy7b7qzInfprkb75N/r87B3fbVX64Zir07NZtYVe/WTzjFrir1qehf9PRR7z6/1WpDb 5M8/4GNpuuKY+Fipt6mUq+aTinN9KdcOr0+Wcv8Zu8WccimXyifF3Aqr+lWruWqmxX77qrkW w8subFmq6FjKolPSPf1AdR6lo2PNK1zz02r3iY+AX78W3lYIi7lndeZuOYFKIfwx3Sb1/ORw t/6QtXXw4VAd+Jw/Ltvq4I9xdmR+oJ6P/MaIQnhDFXx7Nquq4F/egRVlcO/VelcGP7sK/hhj W9INR83Jc0sh/PDOry6FO49evxgeBptxXzl8d8K/mHl+fln86UStell8d+q7yuK7GA/K4vuq mJoY5oQ51zDnWae8G1HdrYHOrfVdWl3g1YXvzM+6xFORztnDsre+u9ld4K0t71YXdy3w1vru 7GxzhXdc9d2Wg1ZPaf92f/03oPqTLf52lH6bprQ/ZdAXVO6N3d5HyfeMkm/l8sXjKfemZ//+ iWdBg6LvPvERwChAbhTw6QhAinc1BgDHCLzyvDtKd7cuax3ou6t1V7P+3+67L7/811nSqlH+ 92t/fffdtAziuasgKP9Z1bqfe9Hez6nO01jNuqXEu5FG3s/CeE+pzNNn3g2z+A7m1WDez6KM k53B19+a9OsuZz06yD2fgx6Q+9nO3U+v0PsX5+rXZj10A9r32mwxvNyaEuYXWFLyopeUPDXQ UNfkmu8uAq+jyTVnv0OT2+F55Tij5k+usL5ypNGO1Rlo1Pzg0ukbt81NgeI6Tq7F9JusffIL Mj0SWmS7YaDRjlrZIqEdcr8Pbc0wox0W9m6am4LkFQ0S2u9/ckWAFQelzatJNg1Dagl+xzCk HZ6OainxtrHIrzoUqWXai7uz3CvSO+valx/dEqj5TrtbQr/sE6z6alap+mq9T/jw6hSryr56 39T0+XVfvW9Wurbqq1Vlk1huLwIzouw7BFrXLWE6xC7VfYdfSALLiKfA6335cFQ7nTV133SM 39Aa63Cc3+fLhxgr6r7p9z/t0r3iqKjYGGtKGLd3UzgcnjcvIlbk5730rF3tTY9s2Yl7hxjh V1xB/GKLvY/1zMdyRrmYeaSO+dz2N2XjXNUoTfLDdFtA6peHuw0HrSpNbo/UEKnu47KxNrmP tD33w9Kk/wv7SWqKvKE0uT2ddaXJJ3dhTWXSeVpuK5PnFyb3ITbl3HKQTmXyi9NcX5nMHtnP cXvTbz/WJQIT4hJlye3Duq8suY3x6yEUM48o1AtQKJVORRq1Xv6vmiXa6hrtVyrQ9pZnN79C faZZoG2uz8YUaH+nVKGdToH2Oa5c/O3uecJ3+nR0JDUaJRolGiXar1Wi3ayt0X5tkNtU620A uV/L4z7We7uWtnQf8cEXa/uQY/FibcWvuFjbJxEHXaztQ8TP/lrwR2QqXAueL2+uBS9+LfgP 72aFa8F/SLX6WvD9kfHYa8H3c4y5FvxjsWWuBd/Ptvta8I+FlbgWfD/X8GvBP5Zm3LXgH3nQ BK4F/8hrbMjV1B+7F+OuBa989oOvBb8GLfddC/6xTKOvBf+IRQ65Fvxjzjn2WvBLmjrkWvD9 BOOvBd/PM/Ra8I/cFYFrwT+Wady14B/LsPta8I8EHn0t+H6aMdeCfyz23mvBPxZ377XgPx9e CPACvAAvwAvwArwAL8AL8AK8AC/AC/ACvAAvwAv7eCHCC/ACvAAvwAvwArwAL8AL8AK8AC/A C/ACvAAv7OOFBC/AC/ACvAAvwAvwArwAL8AL8AK8AC/AC/ACvLCPFzK8AC/AC/ACvAAvwAvw ArwAL8AL8AK8AC/AC/DCPl4o8AK8AC/AC/ACvAAvwAvwArwAL8AL8AK8AC/AC/t4ocIL8AK8 AC/AC/ACvAAvwAvwArwAL8AL8AK8AC/s44VzeAFegBfgBXgBXoAX4AV4AV6AF+AFeAFegBfg hX28cAEvwAvwArwAL8AL8AK8AC/AC/ACvAAvwAvwArywjxcu4QV4AV6AF+AFeAFegBfgBXgB XoAX4AV4AV6AF/bxwhW8AC/AC/ACvAAvwAvwArwAL8AL8AK8AC/AC/DCPl64hhfgBXgBXoAX 4AV4AV6AF+AFeAFegBfgBXgBXtjHCzfwArwAL8AL8AK8AC/AC/ACvAAvwAvwArwAL8ALu3ih GngBXoAX4AV4AV6AF+AFeAFegBfgBXgBXoAX4IV9vGDhBXgBXoAX4AV4AV6AF+AFeAFegBfg BXgBXoAX9vGCgxfgBXgBXoAX4AV4AV6AF+AFeAFegBfgBXgBXtjHCx5egBfgBXgBXoAX4AV4 AV6AF+AFeAFegBfgBXhhHy8EeAFegBfgBXgBXoAX4AV4AV6AF+AFeAFegBfghX28EOEFeAFe gBfgBXgBXoAX4AV4AV6AF+AFeAFegBf28UKCF+AFeAFegBfgBXgBXoAX4AV4AV6AF+AFeAFe 2McLGV6AF+AFeAFegBfgBXgBXoAX4AV4AV6AF+AFeGEfLxR4AV6AF+AFeAFegBfgBXgBXoAX 4AV4AV6AF+CFfbxQ4QV4AV6AF+AFeAFegBfgBXgBXoAX4AV4AV6AF/bxwjm8AC/AC/ACvAAv wAvwArwAL8AL8AK8AC/AC/DCPl64gBfgBXgBXoAX4AV4AV6AF+AFeAFegBfgBXgBXtjHC5fw ArwAL8AL8AK8AC/AC/ACvAAvwAvwArwAL8AL+3jhCl6AF+AFeAFegBfgBXgBXoAX4AV4AV6A F+AFeGEfL1zDC/ACvAAvwAvwArwAL8AL8AK8AC/AC/ACvAAv7OOFG3gBXoAX4AV4AV6AF+AF eAFegBfgBXgBXoAX4IVdvHBu4AV4AV6AF+AFeAFegBfgBXgBXoAX4AV4AV6AF/bxgoUX4AV4 AV6AF+AFeAFegBfgBXgBXoAX4AV4AV7YxwsOXoAX4AV4AV6AF+AFeAFegBfgBXgBXoAX4AV4 YR8veHgBXoAX4AV4AV6AF+AFeAFegBfgBXgBXoAX4IV9vBDgBXgBXoAX4AV4AV6AF+AFeAFe gBfgBXgBXoAX9vFChBfgBXgBXoAX4AV4AV6AF+AFeAFegBfgBXgBXtjHCwlegBfgBXgBXoAX 4AV4AV6AF+AFeAFegBfgBXhhHy9keAFegBfgBXgBXoAX4AV4AV6AF+AFeAFegBfghX28UOAF eAFegBfgBXgBXoAX4AV4AV6AF+AFeAFegBf28UKFF+AFeAFegBfgBXgBXoAX4AV4AV6AF+AF eAFe2McL5/ACvAAvwAvwArwAL8AL8AK8AC/AC/ACvAAvwAv7eOGixwvhQUQGxAyIGRAfzYA4 dD4QvP2imGhNHTsgfiLV4wPiJw4cMiBelWPlgHhl7J0D4lXZnj8gXhl214B4Va7tA+KVaTYM iNc9aHsGxOteY+uGlCvvxYYB8edx9lsHxCsz7BgQr8y0eUC86vlYOSBeF3vrgHhllvUD4lUJ dgyI1741Lm/uv5jeXU+1ciuEv31z9fbd9eX79pOWe0o2vZj3JNo28l6VwofruydlmgR807K0 0uftu39/c/39VEBPH+vTR8mup2XP4H7dnbm4NPWuKvnz9c8/vvmxvcK+a4OM9nC9ff+XLy6/ /eH76y9KOryip0+xfS+3LZSwMsPzKWFd4Gzq9TIlpIsuJaxKk+2Nuei9uO7eMyNeXf7GVPfp p8r01L/5+cfpgSqHT/m6q/BZySErYz+bQ1bGfTaHrIm7lUOeyLHEIRemPIdD5hHXrrZ4IuLn s9riiRN91mqLJ2KAS+ASuAQugUvgErgELoFL4BK4BC6BS+ASuAQuvRxcquASuAQugUvgErgE LoFL4BK4BC6BS+ASuAQugUvgEri0FZfOwSVwCVwCl8AlcAlcApfAJXAJXAKXwCVwCVwCl8Al cGkrLl2AS+ASuAQugUvgErgELoFL4BK4BC6BS+ASuAQugUvg0lZcugSXwCVwCVwCl8AlcAlc ApfAJXAJXAKXwCVwCVwCl8Clrbh0BS6BS+ASuAQugUvgErgELoFL4BK4BC6BS+ASuAQugUtb cekaXAKXwCVwCVwCl8AlcAlcApfAJXAJXAKXwCVwCVwCl7bi0g24BC6BS+ASuAQugUvgErgE LoFL4BK4BC6BS+ASuAQubcQla8AlcAlcApfAJXAJXAKXwCVwCVwCl8AlcAlcApfAJXBpKy5Z cAlcApfAJXAJXAKXwCVwCVwCl8AlcAlcApfAJXAJXNqKSw5cApfAJXAJXAKXwCVwCVwCl8Al cAlcApfAJXAJXAKXtuKSB5fAJXAJXAKXwCVwCVwCl8AlcAlcApfAJXAJXAKXwKWtuBTAJXAJ XAKXwCVwCVwCl8AlcAlcApfAJXAJXAKXwCVwaSsuRXAJXAKXwCVwCVwCl8AlcAlcApfAJXAJ XAKXwCVwCVzaiksJXAKXwCVwCVwCl8AlcAlcApfAJXAJXAKXwCVwCVwCl7biUgaXwCVwCVwC l8AlcAlcApfAJXAJXAKXwCVwCVwCl8ClrbhUwCVwCVwCl8AlcAlcApfAJXAJXAKXwCVwCVwC l8AlcGkrLlVwCVwCl8AlcAlcApfAJXAJXAKXwCVwCVwCl8AlcAlc2opL5+ASuAQugUvgErgE LoFL4BK4BC6BS+ASuAQugUvgEri0FZcuwCVwCVwCl8AlcAlcApfAJXAJXAKXwCVwCVwCl8Al cGkrLl2CS+ASuAQugUvgErgELoFL4BK4BC6BS+ASuAQugUvg0lZcugKXwCVwCVwCl8AlcAlc ApfAJXAJXAKXwCVwCVwCl8Clrbh0DS6BS+ASuAQugUvgErgELoFL4BK4BC6BS+ASuAQugUtb cekGXAKXwCVwCVwCl8AlcAlcApfAJXAJXAKXwCVwCVwClzbikjPgErgELoFL4BK4BC6BS+AS uAQugUvgErgELoFL4BK4tBWXLLgELoFL4BK4BC6BS+ASuAQugUvgErgELoFL4BK4BC5txSUH LoFL4BK4BC6BS+ASuAQugUvgErgELoFL4BK4BC6BS1txyYNL4BK4BC6BS+ASuAQugUvgErgE LoFL4BK4BC6BS+DSVlwK4BK4BC6BS+ASuAQugUvgErgELoFL4BK4BC6BS+ASuLQVlyK4BC6B S+ASuAQugUvgErgELoFL4BK4BC6BS+ASuAQubcWlBC6BS+ASuAQugUvgErgELoFL4BK4BC6B S+ASuAQugUtbcSmDS+ASuAQugUvgErgELoFL4BK4BC6BS+ASuAQugUvg0lZcKuASuAQugUvg ErgELoFL4BK4BC6BS+ASuAQugUvgEri0FZcquAQugUvgErgELoFL4BK4BC6BS+ASuAQugUvg ErgELm3FpXNwCVwCl8AlcAlcApfAJXAJXAKXwCVwCVwCl8AlcAlc2opLF7/EJf+lcV+6dBfx 6k+X375tb+4vz77+71998/p3/+uPv/vD/z6bxo/v/2TO3v9wZr9wX/gv2mD+h3fvz1J+Vpi/ /+p/nN1Mw8m7g5886GIaOn/MFts9Omuf0Nf/0UaTb78/m0aMrUy7/OH7q5++ePWbITdnrP0b U//Ghjd/8+brH74zb756d/7Tn978w/nlnw8P409/e/Hhr1tztNM2KYTDn+328M+Yg/mNtckH 65wN9jemVeYm/+bM/Ebh9vNP78/fnZ39ZoK+pd976t+P9PYPf/zHL89+PnxFTy+8NpK5an+7 fYOd/fMff//79oqf9ODd2dX1u+ub9v/v21vr/P0ECH/1/c/ffvvXr/7pmy8ffJLGkqdPozcf PkI/jubjVMrk8uqbf/z6zLz6lx9+/OnLs+k1cPb//ov917M//M9vXn31zR/bv7xklvzpMZdE IXcp5A//4SQV8rsfP0uBlJPHVwdNrMXle0z86U9Xz9XEs9//7p//5f/8y4dZib/9MDvxevq4 uDbefNn9zHj2J8mhCmmfJK//cIjnLr48HFPMxH1XsX3pn5397r/9/u//8Q+HT5hJ6tKr13// f28/bz652bPX/9D96Vedn756/fX8p+bs9R/+6cuz+/z+0rds5ez1152fvnr9D9/0spky+2lo P63zbK9eWzP7actm7YOfhlZivG6l09nNL27X7RxaCdK5FzZ0fxo/3gtnbs5zTeXVf2sP6+F3 c3ueyqU7t/nS/NX0g78+mx7y+wNurm7O20/v/unP33/b/nV2j76aorUXhT/7+g93Xwi/+/CX r15/cm9bxNgeyotXX712nXP96vWn9yu3qvj2pw/ul0vJvPr6telE+Pq17f60k61F8N3fTR9/ Oj0M7T/TT/PDZ6dF+Ob2w+L2jfVXP358v73/01Rsv/3+5oezT1/W7RjT/vH8pz9//HG7l5ft 1f3Xr/7wvn2HfPnq7BfAYGKYv6wePJvm1dkvzqvVhPO7dftc39zYi6vz0t6+r+av4U/fuPXq 5mqW+NWnkwYPKaSd6T2F3PwwzaPefq8exgbTd+00pGnv+fMHRx5S3anAxyGbnz4e2jv+F7/r XLr2t+Dy4/u/vPn5+/Yw//D+/UEnrJlGHOcPDwj2/OoO5R4c4KeTCfnhAf4y3Krw92+mQ+7G TOmAnXl62B4OOs/DI4POWu8Gnb/MYK9vLi7uT+kufplmSS4f/OrysPCXvxp9Pr8bkf349vs3 09fBNFH67t8nHZpw6OHvp+pvR7M/vf236TvvzsXidNLJvFoxjtw4NPyqFSjtk//izMezNjIs F2eunIXLs1LPLu3dX9rPXXv9l8Mv1LMbN/33+vqsfThPv5bbS/YsmjawaoPFs0tzOOri41G5 /ff8LNizYs6u41l7iU8/md4/Z5cX099tnH4/Hn7ffsh+fRvn6iy5s+tyyHV1yHL4Bd9O4/ws t3Ru+i48W106ty+bb85++/DL7u/6n4ivfsONGzdu3Lhx48aNGzdu3Lhx48aNGzdu3Lhx48aN G7eTuf1/W+jYHQDQmAA= --sm4nu43k4a2Rpi4c Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel --sm4nu43k4a2Rpi4c-- From xen-devel-bounces@lists.xensource.com Wed Sep 14 06:38:59 2011 Return-path: Envelope-to: www-data@lists.xensource.com Delivery-date: Wed, 14 Sep 2011 06:38:59 -0700 Received: from localhost ([127.0.0.1] helo=lists.colo.xensource.com) by lists.xensource.com with esmtp (Exim 4.43) id 1R3pg3-0003aO-E8; Wed, 14 Sep 2011 06:38:59 -0700 Received: from mail174.messagelabs.com ([85.158.138.51]) by lists.xensource.com with esmtp (Exim 4.43) id 1R3pfF-0003OM-9f for xen-devel@lists.xensource.com; Wed, 14 Sep 2011 06:38:09 -0700 X-Env-Sender: yujiageng734@gmail.com X-Msg-Ref: server-8.tower-174.messagelabs.com!1316007482!17721925!1 X-Originating-IP: [209.85.210.171] X-StarScan-Version: 6.4.1; banners=-,-,- X-VirusChecked: Checked Received: (qmail 11213 invoked from network); 14 Sep 2011 13:38:05 -0000 Received: from mail-iy0-f171.google.com (HELO mail-iy0-f171.google.com) (209.85.210.171) by server-8.tower-174.messagelabs.com with RC4-SHA encrypted SMTP; 14 Sep 2011 13:38:05 -0000 Received: by iagv1 with SMTP id v1so187217iag.30 for ; Wed, 14 Sep 2011 06:38:01 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; bh=UGP/pnfblWJ3+qm5ni7orlJQVOAmwg5cz9eQkwP8k18=; b=RbBw91tJ7lj/vWta8E0qhGc8rbQpAcLKqMTqzSFVb0B+n7SFFjHrtnVBzg48O2ovcV qnajtyH7NcjuzK31saRWFI1GU55q6SVGl2dZr/wGCyUtuZAm8KPX7J9BQmgZ6Mxyczs7 ukk3BGsxk2+qS5jn9g3cF96eixm594+EPK4h8= MIME-Version: 1.0 Received: by 10.42.157.5 with SMTP id b5mr157183icx.442.1316007481537; Wed, 14 Sep 2011 06:38:01 -0700 (PDT) Received: by 10.43.51.67 with HTTP; Wed, 14 Sep 2011 06:38:01 -0700 (PDT) In-Reply-To: References: Date: Wed, 14 Sep 2011 21:38:01 +0800 Message-ID: Subject: Re: [Xen-devel] Re: Linux Stubdom Problem From: Jiageng Yu To: Keir Fraser Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Cc: Jeremy Fitzhardinge , "xen-devel@lists.xensource.com" , Konrad Rzeszutek Wilk , Stefano Stabellini , Tim Deegan , Ian Campbell , Anthony PERARD , Samuel Thibault X-BeenThere: xen-devel@lists.xensource.com X-Mailman-Version: 2.1.5 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xensource.com Errors-To: xen-devel-bounces@lists.xensource.com 2011/9/2 Keir Fraser : > On 02/09/2011 14:09, "Stefano Stabellini" > wrote: > >>> Why? =C2=A0HVMloader is already tightly coupled to the hypervisor and t= he >>> toostack - special cases for stubdoms should be fine. >> >> I think think that leaking the implementation details of the device >> model into hvmloader should be avoided, but obviously if there are no >> alternatives, it can be done. > > This is a fair and more general point, that we don't want fragile > dependencies on qemu now that we are using upstream. But as I say that's = a > more general point on our policy regarding qemu, rather than something > specifically concerning hvmloader. > > =C2=A0-- Keir > > > Hi Stefano, I just have a prototype of vram mapping and test it now. The implementation of linux-stubdom kernel part is as follows. xen_remap_domain_mfn_range2 function maps foreign dom's physical address into linux kernel space. It is similar to xen_remap_domain_mfn_range. But xen_remap_domain_mfn_range is used to map foreign pages into linux user space. But the page info seems wrong after executing xen_remap_domain_mfn_rang= e2. struct page *page=3Dpfn_to_page(vmalloc_to_pfn(info->fb)); The page->_count =3D 0xc2c2c2c2. It is very strange. Did I do the right thing? Greeting. Jiageng Yu. diff --git a/arch/x86/xen/mmu.c b/arch/x86/xen/mmu.c index 204e3ba..72a7808 100644 --- a/arch/x86/xen/mmu.c +++ b/arch/x86/xen/mmu.c @@ -2693,6 +2693,73 @@ out: } EXPORT_SYMBOL_GPL(xen_remap_domain_mfn_range); +int xen_remap_domain_mfn_range2(unsigned long addr,unsigned long gpfn, + int nr, unsigned domid) +{ + struct remap_data rmd; + struct mmu_update mmu_update[REMAP_BATCH_SIZE]; + int level,i,batch,nr_page =3D nr; + unsigned long range; + int err =3D 0; + unsigned long vaddr,base_addr =3D addr; + pte_t pte,*ptep; + + rmd.mfn =3D gpfn; + rmd.prot =3D __pgprot(_PAGE_PRESENT | _PAGE_RW | _PAGE_ACCESSED | _PAGE_IOMAP); + + while(nr_page) { + batch =3D min(REMAP_BATCH_SIZE, nr); + range =3D (unsigned long)batch << PAGE_SHIFT; + + rmd.mmu_update =3D mmu_update; + + for(i=3D0; i < batch; i++){ + pte =3D pte_mkspecial(pfn_pte(rmd.mfn++, rmd.prot)); + vaddr =3D base_addr + i*PAGE_SIZE; + ptep =3D lookup_address(vaddr, &level); + + rmd.mmu_update->ptr =3D arbitrary_virt_to_machine(ptep).maddr = | + MMU_NORMAL_PT_UPDATE; + rmd.mmu_update->val =3D pte_val_ma(pte); + rmd.mmu_update++; + } + + err =3D -EFAULT; + if(HYPERVISOR_mmu_update(mmu_update, batch, NULL, domid) < 0) + goto out; + + nr_page -=3D batch; + base_addr +=3D range; + } + + err =3D 0; + + base_addr =3D addr; + for(i=3D0; i < nr; i++){ + vaddr =3D base_addr + i*PAGE_SIZE; + set_phys_to_machine(vmalloc_to_pfn(vaddr), + arbitrary_virt_to_machine(vaddr).maddr >> PAGE_SHIFT); + } + +out: + flush_tlb_all(); + return err; +} +EXPORT_SYMBOL_GPL(xen_remap_domain_mfn_range2); #ifdef CONFIG_XEN_PVHVM static void xen_hvm_exit_mmap(struct mm_struct *mm) { diff --git a/drivers/video/xen-fbfront.c b/drivers/video/xen-fbfront.c index dc72563..82da2ee 100644 --- a/drivers/video/xen-fbfront.c +++ b/drivers/video/xen-fbfront.c @@ -25,8 +25,12 @@ #include #include #include +#include +#include +#include #include +#include #include #include @@ -34,6 +38,7 @@ #include #include #include +#include struct xenfb_info { unsigned char *fb; @@ -62,6 +67,12 @@ module_param_array(video, int, NULL, 0); MODULE_PARM_DESC(video, "Video memory size in MB, width, height in pixels (default 2,800,600)"); +static unsigned long foreign_vaddr =3D 0; +module_param(foreign_vaddr, ulong, S_IRUGO); + +static unsigned long foreign_domid =3D 0; +module_param(foreign_domid, ulong, S_IRUGO); + static void xenfb_make_preferred_console(void); static int xenfb_remove(struct xenbus_device *); static void xenfb_init_shared_page(struct xenfb_info *, struct fb_info *); @@ -398,7 +408,17 @@ static int __devinit xenfb_probe(struct xenbus_device = *dev, if (info->fb =3D=3D NULL) goto error_nomem; memset(info->fb, 0, fb_size); - + if((foreign_vaddr !=3D 0) && (foreign_domid !=3D 0)){ + ret =3D xen_remap_domain_mfn_range2((unsigned long)(info->fb), + foreign_vaddr >> PAGE_SHIFT, + fb_size >> PAGE_SHIFT, foreign_domid); + if(ret < 0){ + printk("Can not remap vram of hvm guest.\n"); + goto error; + } + } info->nr_pages =3D (fb_size + PAGE_SIZE - 1) >> PAGE_SHIFT; info->mfns =3D vmalloc(sizeof(unsigned long) * info->nr_pages); diff --git a/include/xen/xen-ops.h b/include/xen/xen-ops.h index 4349e89..1554531 100644 --- a/include/xen/xen-ops.h +++ b/include/xen/xen-ops.h @@ -20,6 +20,10 @@ int xen_remap_domain_mfn_range(struct vm_area_struct *vm= a, unsigned long mfn, int nr, pgprot_t prot, unsigned domid); +int xen_remap_domain_mfn_range2(unsigned long addr,unsigned long mfn, + int nr, unsigned domid); extern unsigned long *xen_contiguous_bitmap; int xen_create_contiguous_region(unsigned long vstart, unsigned int order, unsigned int address_bits); _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel From xen-devel-bounces@lists.xensource.com Wed Sep 14 06:46:14 2011 Return-path: Envelope-to: www-data@lists.xensource.com Delivery-date: Wed, 14 Sep 2011 06:46:14 -0700 Received: from localhost ([127.0.0.1] helo=lists.colo.xensource.com) by lists.xensource.com with esmtp (Exim 4.43) id 1R3pn4-00045j-8p; Wed, 14 Sep 2011 06:46:14 -0700 Received: from mail174.messagelabs.com ([85.158.138.51]) by lists.xensource.com with esmtp (Exim 4.43) id 1R3pmZ-0003tC-Cx for xen-devel@lists.xensource.com; Wed, 14 Sep 2011 06:45:43 -0700 X-Env-Sender: Ian.Campbell@eu.citrix.com X-Msg-Ref: server-5.tower-174.messagelabs.com!1316007937!27707079!1 X-Originating-IP: [66.165.176.89] X-StarScan-Version: 6.4.1; banners=-,-,- X-VirusChecked: Checked Received: (qmail 31879 invoked from network); 14 Sep 2011 13:45:40 -0000 Received: from smtp.citrix.com (HELO SMTP.CITRIX.COM) (66.165.176.89) by server-5.tower-174.messagelabs.com with RC4-SHA encrypted SMTP; 14 Sep 2011 13:45:40 -0000 X-IronPort-AV: E=Sophos;i="4.68,380,1312171200"; d="scan'208";a="16989833" Received: from ftlpmailmx01.citrite.net ([10.13.107.65]) by FTLPIPO01.CITRIX.COM with ESMTP/TLS/RC4-MD5; 14 Sep 2011 09:45:36 -0400 Received: from [127.0.0.1] (10.80.16.67) by smtprelay.citrix.com (10.13.107.65) with Microsoft SMTP Server id 8.3.137.0; Wed, 14 Sep 2011 09:45:36 -0400 Subject: Re: [Xen-devel] Help with the migration to XEN-4.1 please From: Ian Campbell To: Flavio Date: Wed, 14 Sep 2011 15:45:35 +0200 In-Reply-To: References: <1315907178.2892.7.camel@cthulhu.hellion.org.uk> <1316001435.2892.24.camel@cthulhu.hellion.org.uk> Organization: Citrix Systems, Inc. Content-Type: text/plain; charset="UTF-8" X-Mailer: Evolution 3.0.3- Content-Transfer-Encoding: 7bit Message-ID: <1316007936.2892.35.camel@cthulhu.hellion.org.uk> MIME-Version: 1.0 Cc: "xen-devel@lists.xensource.com" X-BeenThere: xen-devel@lists.xensource.com X-Mailman-Version: 2.1.5 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xensource.com Errors-To: xen-devel-bounces@lists.xensource.com On Wed, 2011-09-14 at 08:30 -0400, Flavio wrote: > On 14 September 2011 13:57, Ian Campbell wrote: [...] > /etc/init.d/xenconsoled > /etc/init.d/xendomains > /etc/init.d/xenstored [...] > > You should have /etc/init.d/xencommons or Gentoo must provide you with > > some equivalent (I don't know enough about Gentoo to know) > I don't think there is something equivalent; maybe it's the case to > open a bug report > on bugs.gentoo.org. >From the above it looks like Gentoo has gone for separate xenconsoled and xenstored initscripts so you are probably ok. > On 14 September 2011 13:57, Ian Campbell wrote: > > > > What is the content of your vm_config_file.cfg? > For instance, this is the config file I use to start the Gentoo VM > (which was working > very well with the XM toolstack: > > kernel = "/mnt/data/xen/kernel/vmlinuz-xen-3.0.4-domU" > memory = "512" > name = "gentoo-10.0-x86_64" > vif = ['bridge=xenbr0'] > dhcp = "dhcp" > disk = ['file:/mnt/data/xen/vmstore/gentoo-10.0/gentoo-10.0.x86-64.img,xvda1,w', > 'file:/mnt/data/xen/vmstore/gentoo-10.0/swap.img,xvda2,w'] > root = "/dev/xvda1 ro" > vcpus = 2 > extra = 'console=hvc0 xencons=tty' > ip = "off" > > > > > In particular I am thinking that if you have "file:" or "tap:" style > > disks you will need qemu-xen installed and if this was missing you might > > get errors like the above. > I have > /usr/bin/qemu-img-xen > /usr/bin/qemu-nbd-xen > /usr/lib64/xen/bin/qemu-dm > /usr/share/xen/qemu > > but not qemu-xen (I don't know what package to install for that) I think it is the thing you have as /usr/lib64/xen/bin/qemu-dm is qemu-xen. Are you seeing anything under /var/log/xen? Sepcifically the xl-* and qemu-* logs with the name of your VM in. Do you see any evidence of qemu-dm actually getting started? (does it appear in "ps" output etc) Running "xl -vvv create ..." might also print extra debugging which might be useful. Please can you post all the logs. The file:/mnt/data/xen/vmstore/gentoo-10.0/gentoo-10.0.x86-64.img (and the other one) is interesting. A modern kernel does not have the blktap driver (for various reasons this cannot go upstream) and so xl falls back to a qemu provided block backend if this is not present and block back. This is different to how xm/xend worked, it would setup a loop device for file:// devices and use blkback. Can you try manually setting up a loop device (losetup) and passing phy:/dev/loopN instead of the file://....*.img? This isn't a real solution but it will be a useful datapoint. Ian. _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel From xen-devel-bounces@lists.xensource.com Wed Sep 14 06:51:04 2011 Return-path: Envelope-to: www-data@lists.xensource.com Delivery-date: Wed, 14 Sep 2011 06:51:04 -0700 Received: from localhost ([127.0.0.1] helo=lists.colo.xensource.com) by lists.xensource.com with esmtp (Exim 4.43) id 1R3prk-0004Xc-9j; Wed, 14 Sep 2011 06:51:04 -0700 Received: from mail174.messagelabs.com ([85.158.138.51]) by lists.xensource.com with esmtp (Exim 4.43) id 1R3prC-0004Kw-0N for xen-devel@lists.xensource.com; Wed, 14 Sep 2011 06:50:30 -0700 X-Env-Sender: Christoph.Egger@amd.com X-Msg-Ref: server-9.tower-174.messagelabs.com!1316008171!25370528!1 X-Originating-IP: [65.55.88.14] X-StarScan-Version: 6.4.1; banners=-,-,- X-VirusChecked: Checked Received: (qmail 19876 invoked from network); 14 Sep 2011 13:50:26 -0000 Received: from tx2ehsobe004.messaging.microsoft.com (HELO TX2EHSOBE007.bigfish.com) (65.55.88.14) by server-9.tower-174.messagelabs.com with AES128-SHA encrypted SMTP; 14 Sep 2011 13:50:26 -0000 Received: from mail194-tx2-R.bigfish.com (10.9.14.251) by TX2EHSOBE007.bigfish.com (10.9.40.27) with Microsoft SMTP Server id 14.1.225.22; Wed, 14 Sep 2011 13:49:20 +0000 Received: from mail194-tx2 (localhost.localdomain [127.0.0.1]) by mail194-tx2-R.bigfish.com (Postfix) with ESMTP id 7C1961780321; Wed, 14 Sep 2011 13:49:20 +0000 (UTC) X-SpamScore: 4 X-BigFish: VPS4(zzbb2dK1432N98dKzz1202hzzz32i668h839haaw61h) X-Spam-TCS-SCL: 0:0 X-Forefront-Antispam-Report: CIP:163.181.249.109; KIP:(null); UIP:(null); IPVD:NLI; H:ausb3twp02.amd.com; RD:none; EFVD:NLI Received: from mail194-tx2 (localhost.localdomain [127.0.0.1]) by mail194-tx2 (MessageSwitch) id 1316008158426663_1475; Wed, 14 Sep 2011 13:49:18 +0000 (UTC) Received: from TX2EHSMHS019.bigfish.com (unknown [10.9.14.248]) by mail194-tx2.bigfish.com (Postfix) with ESMTP id 578611C1804E; Wed, 14 Sep 2011 13:49:18 +0000 (UTC) Received: from ausb3twp02.amd.com (163.181.249.109) by TX2EHSMHS019.bigfish.com (10.9.99.119) with Microsoft SMTP Server id 14.1.225.22; Wed, 14 Sep 2011 13:49:17 +0000 X-WSS-ID: 0LRIMDZ-02-D1H-02 X-M-MSG: Received: from sausexedgep01.amd.com (sausexedgep01-ext.amd.com [163.181.249.72]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by ausb3twp02.amd.com (Axway MailGate 3.8.1) with ESMTP id 2FDADC8185; Wed, 14 Sep 2011 08:49:10 -0500 (CDT) Received: from SAUSEXDAG04.amd.com (163.181.55.4) by sausexedgep01.amd.com (163.181.36.54) with Microsoft SMTP Server (TLS) id 8.3.106.1; Wed, 14 Sep 2011 08:49:38 -0500 Received: from storexhtp02.amd.com (172.24.4.4) by sausexdag04.amd.com (163.181.55.4) with Microsoft SMTP Server (TLS) id 14.1.289.1; Wed, 14 Sep 2011 08:49:15 -0500 Received: from [10.224.148.198] (10.224.148.198) by storexhtp02.amd.com (172.24.4.4) with Microsoft SMTP Server id 8.3.83.0; Wed, 14 Sep 2011 09:49:13 -0400 Message-ID: <4E70B0D7.5040906@amd.com> Date: Wed, 14 Sep 2011 15:49:11 +0200 From: Christoph Egger User-Agent: Mozilla/5.0 (X11; U; NetBSD amd64; en-US; rv:1.9.2.17) Gecko/20110523 Lightning/1.0b3pre Thunderbird/3.1.10 MIME-Version: 1.0 To: Roger Pau Monne Subject: Re: [Xen-devel] [PATCH] libxl: create pci backend only when there are pci devices References: <63e254468d6e8d81baea.1316002763@loki> In-Reply-To: <63e254468d6e8d81baea.1316002763@loki> Content-Type: text/plain; charset="ISO-8859-1"; format=flowed Content-Transfer-Encoding: 7bit X-OriginatorOrg: amd.com Cc: "xen-devel@lists.xensource.com" X-BeenThere: xen-devel@lists.xensource.com X-Mailman-Version: 2.1.5 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xensource.com Errors-To: xen-devel-bounces@lists.xensource.com If you want to have this patch applied to xen-4.1 then please mention this explicitely. Christoph On 09/14/11 14:19, Roger Pau Monne wrote: > # HG changeset patch > # User Roger Pau Monne > # Date 1316002720 -7200 > # Node ID 63e254468d6e8d81baeafaed68f05791dc21eb4e > # Parent ac33d68e89767d49113824e5661c49a5465a18e7 > libxl: create pci backend only when there are pci devices. > > Signed-off-by: Roger Pau Monne > > diff -r ac33d68e8976 -r 63e254468d6e tools/libxl/libxl_create.c > --- a/tools/libxl/libxl_create.c Thu Sep 08 15:13:06 2011 +0100 > +++ b/tools/libxl/libxl_create.c Wed Sep 14 14:18:40 2011 +0200 > @@ -584,12 +584,14 @@ static int do_domain_create(libxl__gc *g > for (i = 0; i< d_config->num_pcidevs; i++) > libxl__device_pci_add(gc, domid,&d_config->pcidevs[i], 1); > > - ret = libxl__create_pci_backend(gc, domid, d_config->pcidevs, > - d_config->num_pcidevs); > - if (ret< 0) { > - LIBXL__LOG(ctx, LIBXL__LOG_ERROR, > - "libxl_create_pci_backend failed: %d", ret); > - goto error_out; > + if (d_config->num_pcidevs> 0) { > + ret = libxl__create_pci_backend(gc, domid, d_config->pcidevs, > + d_config->num_pcidevs); > + if (ret< 0) { > + LIBXL__LOG(ctx, LIBXL__LOG_ERROR, > + "libxl_create_pci_backend failed: %d", ret); > + goto error_out; > + } > } > > if (d_config->c_info.type == LIBXL_DOMAIN_TYPE_PV&& -- ---to satisfy European Law for business letters: Advanced Micro Devices GmbH Einsteinring 24, 85689 Dornach b. Muenchen Geschaeftsfuehrer: Alberto Bozzo, Andrew Bowd Sitz: Dornach, Gemeinde Aschheim, Landkreis Muenchen Registergericht Muenchen, HRB Nr. 43632 _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel From xen-devel-bounces@lists.xensource.com Wed Sep 14 07:06:48 2011 Return-path: Envelope-to: www-data@lists.xensource.com Delivery-date: Wed, 14 Sep 2011 07:06:48 -0700 Received: from localhost ([127.0.0.1] helo=lists.colo.xensource.com) by lists.xensource.com with esmtp (Exim 4.43) id 1R3q6y-00057i-6v; Wed, 14 Sep 2011 07:06:48 -0700 Received: from mail182.messagelabs.com ([85.158.139.83]) by lists.xensource.com with esmtp (Exim 4.43) id 1R3q64-0004uw-SB for xen-devel@lists.xensource.com; Wed, 14 Sep 2011 07:05:53 -0700 X-Env-Sender: fbcyborg@gmail.com X-Msg-Ref: server-10.tower-182.messagelabs.com!1316009148!18300974!1 X-Originating-IP: [209.85.212.41] X-StarScan-Version: 6.4.1; banners=-,-,- X-VirusChecked: Checked Received: (qmail 23915 invoked from network); 14 Sep 2011 14:05:49 -0000 Received: from mail-vw0-f41.google.com (HELO mail-vw0-f41.google.com) (209.85.212.41) by server-10.tower-182.messagelabs.com with RC4-SHA encrypted SMTP; 14 Sep 2011 14:05:49 -0000 Received: by vwm42 with SMTP id 42so2550604vwm.28 for ; Wed, 14 Sep 2011 07:05:48 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=zaXxx8u2cgh4btjKWhLn5wwhmUKFO0Yze/12XTLQwBk=; b=WQQN01HEqtiHXB9snBL6VSMjTCsKiv1rQkXBGj4qhvN6t0BdI5tw0DhPLK4QLp9l0d xtBwmmbNFymRfT9r8mFq5KziIz9PSe1XecLsbL2A9MDFfX7gXmQA5HKmg7Lg7jYV8xLa P1H7CQWNF/IenTWTUxHmJzHSwH0VWRFo9slsw= Received: by 10.220.187.5 with SMTP id cu5mr547662vcb.222.1316009148127; Wed, 14 Sep 2011 07:05:48 -0700 (PDT) MIME-Version: 1.0 Received: by 10.220.166.67 with HTTP; Wed, 14 Sep 2011 07:05:27 -0700 (PDT) In-Reply-To: <1316007936.2892.35.camel@cthulhu.hellion.org.uk> References: <1315907178.2892.7.camel@cthulhu.hellion.org.uk> <1316001435.2892.24.camel@cthulhu.hellion.org.uk> <1316007936.2892.35.camel@cthulhu.hellion.org.uk> From: Flavio Date: Wed, 14 Sep 2011 16:05:27 +0200 Message-ID: Subject: Re: [Xen-devel] Help with the migration to XEN-4.1 please To: Ian Campbell Content-Type: text/plain; charset=ISO-8859-1 Cc: "xen-devel@lists.xensource.com" X-BeenThere: xen-devel@lists.xensource.com X-Mailman-Version: 2.1.5 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xensource.com Errors-To: xen-devel-bounces@lists.xensource.com On 14 September 2011 15:45, Ian Campbell wrote: > From the above it looks like Gentoo has gone for separate xenconsoled > and xenstored initscripts so you are probably ok. OK. > Are you seeing anything under /var/log/xen? Yes, of course. > Sepcifically the xl-* and For instance, if I look for the file related to my gentoo guest I see xl-gentoo-10.0-x86_64.log and the content is: Waiting for domain gentoo-10.0-x86_64 (domid 1) to die [pid 6250] Domain 1 is dead Unable to get domain death info, quitting It says it is dead because I issued the command xl destroy xl shutdown doesn't work, as for the xl reboot. > qemu-* logs with the name of your VM in. qemu-dm-gentoo-10.0-x86_64.log and this is the content: domid: 1 Warning: vlan 0 is not connected to host network -videoram option does not work with cirrus vga device model. Videoram set to 4M. /var/tmp/portage/app-emulation/xen-tools-4.1.1-r4/work/xen-4.1.1/tools/ioemu-qemu-xen/hw/xen_blktap.c:628: Init blktap pipes Could not open /var/run/tap/qemu-read-1 xen be core: xen be core: can't open gnttab device can't open gnttab device xen be core: xen be core: can't open gnttab device can't open gnttab device xen be core: xen be core: can't open gnttab device can't open gnttab device xs_read(): target get error. /local/domain/1/target. (qemu) (qemu) > Do you see any evidence of > qemu-dm actually getting started? (does it appear in "ps" output etc) If no virtual machines are running no. But when the VM starts yes: root 6412 0.1 0.7 118280 16512 ? Ssl 15:53 0:00 qemu-dm -d 1 -domain-name gentoo-10.0-x86_64 -nographic -M xenpv > > Running "xl -vvv create ..." might also print extra debugging which > might be useful. Please can you post all the logs. Here it is: http://pastebin.com/t6ekJWJ7 > > The file:/mnt/data/xen/vmstore/gentoo-10.0/gentoo-10.0.x86-64.img (and > the other one) is interesting. As you see I use loop files for the root filesystems. In what sense do you say it is interesting? I have only these files in that directory: gentoo-10.0.x86-64.cfg gentoo-10.0.x86-64.img swap.img > A modern kernel does not have the blktap > driver (for various reasons this cannot go upstream) and so xl falls > back to a qemu provided block backend if this is not present and block > back. This is different to how xm/xend worked, it would setup a loop > device for file:// devices and use blkback. > > Can you try manually setting up a loop device (losetup) and passing > phy:/dev/loopN instead of the file://....*.img? This isn't a real > solution but it will be a useful datapoint. I've tried to do that but it seems to be the same thing of using the file:/ syntax. Thank you so much for your support. -- Flavio _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel From xen-devel-bounces@lists.xensource.com Wed Sep 14 07:09:46 2011 Return-path: Envelope-to: www-data@lists.xensource.com Delivery-date: Wed, 14 Sep 2011 07:09:46 -0700 Received: from localhost ([127.0.0.1] helo=lists.colo.xensource.com) by lists.xensource.com with esmtp (Exim 4.43) id 1R3q9p-0006Ac-Ui; Wed, 14 Sep 2011 07:09:45 -0700 Received: from mail216.messagelabs.com ([85.158.143.99]) by lists.xensource.com with esmtp (Exim 4.43) id 1R3q9F-0005tZ-I3 for xen-devel@lists.xensource.com; Wed, 14 Sep 2011 07:09:10 -0700 X-Env-Sender: Ian.Campbell@eu.citrix.com X-Msg-Ref: server-10.tower-216.messagelabs.com!1316009345!10174132!1 X-Originating-IP: [66.165.176.63] X-StarScan-Version: 6.4.1; banners=-,-,- X-VirusChecked: Checked Received: (qmail 30223 invoked from network); 14 Sep 2011 14:09:06 -0000 Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63) by server-10.tower-216.messagelabs.com with RC4-SHA encrypted SMTP; 14 Sep 2011 14:09:06 -0000 X-IronPort-AV: E=Sophos;i="4.68,380,1312171200"; d="scan'208";a="162945602" Received: from ftlpmailmx01.citrite.net ([10.13.107.65]) by FTLPIPO02.CITRIX.COM with ESMTP/TLS/RC4-MD5; 14 Sep 2011 10:09:04 -0400 Received: from [127.0.0.1] (10.80.16.67) by smtprelay.citrix.com (10.13.107.65) with Microsoft SMTP Server id 8.3.137.0; Wed, 14 Sep 2011 10:09:04 -0400 Subject: Re: [Xen-devel] Help with the migration to XEN-4.1 please From: Ian Campbell To: Flavio Date: Wed, 14 Sep 2011 16:09:03 +0200 In-Reply-To: References: <1315907178.2892.7.camel@cthulhu.hellion.org.uk> <1316001435.2892.24.camel@cthulhu.hellion.org.uk> <1316007936.2892.35.camel@cthulhu.hellion.org.uk> Organization: Citrix Systems, Inc. Content-Type: text/plain; charset="UTF-8" X-Mailer: Evolution 3.0.3- Content-Transfer-Encoding: 7bit Message-ID: <1316009344.2892.38.camel@cthulhu.hellion.org.uk> MIME-Version: 1.0 Cc: "xen-devel@lists.xensource.com" X-BeenThere: xen-devel@lists.xensource.com X-Mailman-Version: 2.1.5 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xensource.com Errors-To: xen-devel-bounces@lists.xensource.com On Wed, 2011-09-14 at 10:05 -0400, Flavio wrote: > xen be core: xen be core: can't open gnttab device > can't open gnttab device This is probably the issue. You need /dev/xen/gntdev, I think you need to enable CONFIG_XEN_GNTDEV. > > The file:/mnt/data/xen/vmstore/gentoo-10.0/gentoo-10.0.x86-64.img (and > > the other one) is interesting. > As you see I use loop files for the root filesystems. That's the thing -- you aren't, you are using img files. Under xend these would be setup as loop devices for you but under xl you insteasd get a userspace block backend (tap if it is available, qdisk from qemu-d, if not). Ian. _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel From xen-devel-bounces@lists.xensource.com Wed Sep 14 07:17:34 2011 Return-path: Envelope-to: www-data@lists.xensource.com Delivery-date: Wed, 14 Sep 2011 07:17:34 -0700 Received: from localhost ([127.0.0.1] helo=lists.colo.xensource.com) by lists.xensource.com with esmtp (Exim 4.43) id 1R3qHN-0006hH-Vu; Wed, 14 Sep 2011 07:17:34 -0700 Received: from mail182.messagelabs.com ([85.158.139.83]) by lists.xensource.com with esmtp (Exim 4.43) id 1R3qGp-0006Uh-O2 for xen-devel@lists.xensource.com; Wed, 14 Sep 2011 07:17:00 -0700 X-Env-Sender: fbcyborg@gmail.com X-Msg-Ref: server-4.tower-182.messagelabs.com!1316009815!18324486!1 X-Originating-IP: [209.85.212.41] X-StarScan-Version: 6.4.1; banners=-,-,- X-VirusChecked: Checked Received: (qmail 24782 invoked from network); 14 Sep 2011 14:16:56 -0000 Received: from mail-vw0-f41.google.com (HELO mail-vw0-f41.google.com) (209.85.212.41) by server-4.tower-182.messagelabs.com with RC4-SHA encrypted SMTP; 14 Sep 2011 14:16:56 -0000 Received: by vwm42 with SMTP id 42so2565574vwm.28 for ; Wed, 14 Sep 2011 07:16:55 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=6q/UE+yvvqVXlT7MxCb1Lal1CfJ1cZU5Va4bs4axYHY=; b=VC9lkAVHEc96S5UQSXB2dnZ4FCkCVHOtWriMxggMmDTojjDJdMFC0WUI+CINyqqBzm KZbVxyIbWwSOyCgCz5PrBGIJvT+SlUMXa53J+PgqUZd6Myhe3ktqE4DHvZKygtAb2Mh4 K4GnHzGvIR0RzHZk3wDg36gjI/84nRmO2hzF4= Received: by 10.52.107.164 with SMTP id hd4mr2444435vdb.312.1316009815270; Wed, 14 Sep 2011 07:16:55 -0700 (PDT) MIME-Version: 1.0 Received: by 10.220.166.67 with HTTP; Wed, 14 Sep 2011 07:16:35 -0700 (PDT) In-Reply-To: <1316009344.2892.38.camel@cthulhu.hellion.org.uk> References: <1315907178.2892.7.camel@cthulhu.hellion.org.uk> <1316001435.2892.24.camel@cthulhu.hellion.org.uk> <1316007936.2892.35.camel@cthulhu.hellion.org.uk> <1316009344.2892.38.camel@cthulhu.hellion.org.uk> From: Flavio Date: Wed, 14 Sep 2011 16:16:35 +0200 Message-ID: Subject: Re: [Xen-devel] Help with the migration to XEN-4.1 please To: Ian Campbell Content-Type: text/plain; charset=ISO-8859-1 Cc: "xen-devel@lists.xensource.com" X-BeenThere: xen-devel@lists.xensource.com X-Mailman-Version: 2.1.5 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xensource.com Errors-To: xen-devel-bounces@lists.xensource.com On 14 September 2011 16:09, Ian Campbell wrote: > On Wed, 2011-09-14 at 10:05 -0400, Flavio wrote: > >> xen be core: xen be core: can't open gnttab device >> can't open gnttab device > > This is probably the issue. You need /dev/xen/gntdev, I think you need > to enable CONFIG_XEN_GNTDEV. YESSSSSSSSSSSSS! Actually it was compiled as module but it wasn't running. Also the xen-gntalloc module is present but it is not running. Now, simply modprobing the xen-gntdev module, the vm has started, and the console is available! Only one problem now: the guest machine doesn't get any IP when dhcp runs. > >> > The file:/mnt/data/xen/vmstore/gentoo-10.0/gentoo-10.0.x86-64.img (and >> > the other one) is interesting. >> As you see I use loop files for the root filesystems. > > That's the thing -- you aren't, you are using img files. It was my mistake! I thought they were loop files too. > Under xend > these would be setup as loop devices for you but under xl you insteasd > get a userspace block backend (tap if it is available, qdisk from > qemu-d, if not). OK, now I understand. THANK YOU SO MUCH Ian. -- Flavio _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel From xen-devel-bounces@lists.xensource.com Wed Sep 14 07:26:17 2011 Return-path: Envelope-to: www-data@lists.xensource.com Delivery-date: Wed, 14 Sep 2011 07:26:17 -0700 Received: from localhost ([127.0.0.1] helo=lists.colo.xensource.com) by lists.xensource.com with esmtp (Exim 4.43) id 1R3qPo-0007H3-TO; Wed, 14 Sep 2011 07:26:16 -0700 Received: from mail21.messagelabs.com ([85.158.143.35]) by lists.xensource.com with esmtp (Exim 4.43) id 1R3qPL-00074V-JZ; Wed, 14 Sep 2011 07:25:47 -0700 X-Env-Sender: konrad@oracle.com X-Msg-Ref: server-11.tower-21.messagelabs.com!1316010326!42576317!1 X-Originating-IP: [148.87.113.117] X-StarScan-Version: 6.4.1; banners=-,-,- X-VirusChecked: Checked Received: (qmail 22477 invoked from network); 14 Sep 2011 14:25:27 -0000 Received: from rcsinet15.oracle.com (HELO rcsinet15.oracle.com) (148.87.113.117) by server-11.tower-21.messagelabs.com with DHE-RSA-AES256-SHA encrypted SMTP; 14 Sep 2011 14:25:27 -0000 Received: from acsinet22.oracle.com (acsinet22.oracle.com [141.146.126.238]) by rcsinet15.oracle.com (Switch-3.4.4/Switch-3.4.4) with ESMTP id p8EEPTdT028216 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Wed, 14 Sep 2011 14:25:31 GMT Received: from acsmt357.oracle.com (acsmt357.oracle.com [141.146.40.157]) by acsinet22.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id p8EEPSgG011651 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 14 Sep 2011 14:25:29 GMT Received: from abhmt113.oracle.com (abhmt113.oracle.com [141.146.116.65]) by acsmt357.oracle.com (8.12.11.20060308/8.12.11) with ESMTP id p8EEPNxi020168; Wed, 14 Sep 2011 09:25:23 -0500 Received: from oracle.com (/209.6.55.207) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Wed, 14 Sep 2011 07:25:23 -0700 Received: by oracle.com (Postfix, from userid 1000) id 2551F1362; Wed, 14 Sep 2011 10:25:23 -0400 (EDT) Date: Wed, 14 Sep 2011 10:25:23 -0400 From: Konrad Rzeszutek Wilk To: Pasi =?iso-8859-1?Q?K=E4rkk=E4inen?= Subject: Re: [Xen-devel] Re: Virtualization Test Day for F16 and Xen Message-ID: <20110914142522.GA16956@phenom.oracle.com> References: <20110914112552.GP12984@reaktio.net> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline In-Reply-To: <20110914112552.GP12984@reaktio.net> User-Agent: Mutt/1.5.21 (2010-09-15) Content-Transfer-Encoding: quoted-printable X-Source-IP: acsinet22.oracle.com [141.146.126.238] X-Auth-Type: Internal IP X-CT-RefId: str=0001.0A090209.4E70B95C.009C:SCFMA922111,ss=1,re=-4.000,fgs=0 Cc: Development discussions related to Fedora , xen@lists.fedoraproject.org, xen-devel@lists.xensource.com, lars.kurth@xen.org, virt@lists.fedoraproject.org, xen-users@lists.xensource.com X-BeenThere: xen-devel@lists.xensource.com X-Mailman-Version: 2.1.5 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xensource.com Errors-To: xen-devel-bounces@lists.xensource.com On Wed, Sep 14, 2011 at 02:25:52PM +0300, Pasi K=E4rkk=E4inen wrote: > On Sat, Sep 10, 2011 at 01:33:54AM +0300, Myroslav Opyr wrote: > > Hi, >=20 > Hello, >=20 > > Virtualization Test day is expected to be on September 15th this y= ear > > ([1]https://fedorahosted.org/fedora-qa/ticket/232). Cool. > > >=20 > So that's tomorrow! >=20 > Luckily Xen Hackathon (@Munich) event is just happening, > so hopefully we can get some more testing from people in that event. >=20 > > We are willing to help test > > [2]http://fedoraproject.org/wiki/Features/XenPvopsDom0 but find to= o little > > information about test methods It really ought to be parallel to what you would do with KVM/QEMU. Basica= lly the same steps - but I am not sure how well does libvirt work with xm/xl = nowadays. Or the virt-manager - but it suppose to interact with magically. Is there a KVM/QEMU/libvirt help test Wiki? I saw this: https://fedoraproject.org/wiki/Getting_started_with_virtualization and it kind of parallels it, albeit I didn't see anything about setting t= he network which sometimes is the biggest pain point: http://www.fedoraforum.org/forum/showthread.php?t=3D268427 > > ([3]https://fedorahosted.org/fedora-qa/ticket/219). It takes time = for us > > to setup test environment, and would be good to have some info in = advance. There are known bugs in FC15/FC16 that have been filled some time ago tha= t folks will sadly run into: 728775, 658387 and 668063 Fortunatly the bugs have patches attached and the files to be modified ar= e shell scripts. > > Regards, > > >=20 > I just added some Xen related mailinglists to the CC list, > so we can get more feedback. >=20 > Thanks, >=20 > -- Pasi >=20 >=20 > _______________________________________________ > Xen-devel mailing list > Xen-devel@lists.xensource.com > http://lists.xensource.com/xen-devel _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel From xen-devel-bounces@lists.xensource.com Wed Sep 14 07:30:00 2011 Return-path: Envelope-to: www-data@lists.xensource.com Delivery-date: Wed, 14 Sep 2011 07:30:00 -0700 Received: from localhost ([127.0.0.1] helo=lists.colo.xensource.com) by lists.xensource.com with esmtp (Exim 4.43) id 1R3qTQ-0008L2-Ng; Wed, 14 Sep 2011 07:30:00 -0700 Received: from mail174.messagelabs.com ([85.158.138.51]) by lists.xensource.com with esmtp (Exim 4.43) id 1R3qSv-00088z-R6 for xen-devel@lists.xensource.com; Wed, 14 Sep 2011 07:29:30 -0700 X-Env-Sender: konrad@oracle.com X-Msg-Ref: server-10.tower-174.messagelabs.com!1316010563!31402092!1 X-Originating-IP: [141.146.126.227] X-StarScan-Version: 6.4.1; banners=-,-,- X-VirusChecked: Checked Received: (qmail 7534 invoked from network); 14 Sep 2011 14:29:26 -0000 Received: from acsinet15.oracle.com (HELO acsinet15.oracle.com) (141.146.126.227) by server-10.tower-174.messagelabs.com with DHE-RSA-AES256-SHA encrypted SMTP; 14 Sep 2011 14:29:26 -0000 Received: from acsinet22.oracle.com (acsinet22.oracle.com [141.146.126.238]) by acsinet15.oracle.com (Switch-3.4.4/Switch-3.4.4) with ESMTP id p8EET2dR003338 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Wed, 14 Sep 2011 14:29:04 GMT Received: from acsmt358.oracle.com (acsmt358.oracle.com [141.146.40.158]) by acsinet22.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id p8EET1K3020985 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 14 Sep 2011 14:29:01 GMT Received: from abhmt106.oracle.com (abhmt106.oracle.com [141.146.116.58]) by acsmt358.oracle.com (8.12.11.20060308/8.12.11) with ESMTP id p8EEStrW032139; Wed, 14 Sep 2011 09:28:55 -0500 Received: from oracle.com (/209.6.55.207) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Wed, 14 Sep 2011 07:28:55 -0700 Received: by oracle.com (Postfix, from userid 1000) id A12E81362; Wed, 14 Sep 2011 10:28:54 -0400 (EDT) Date: Wed, 14 Sep 2011 10:28:54 -0400 From: Konrad Rzeszutek Wilk To: Adi Kriegisch Message-ID: <20110914142854.GB16956@phenom.oracle.com> References: <20110914081156.GB3079@vrvis.at> <20110914102112.GB15866@phenom.oracle.com> <20110914112718.GG3079@vrvis.at> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20110914112718.GG3079@vrvis.at> User-Agent: Mutt/1.5.21 (2010-09-15) X-Source-IP: acsinet22.oracle.com [141.146.126.238] X-Auth-Type: Internal IP X-CT-RefId: str=0001.0A090205.4E70BA30.014F:SCFMA922111,ss=1,re=-4.000,fgs=0 Cc: xen-devel@lists.xensource.com, Adi Kriegisch Subject: [Xen-devel] Re: Dom0 ACPI S3 patches X-BeenThere: xen-devel@lists.xensource.com X-Mailman-Version: 2.1.5 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xensource.com Errors-To: xen-devel-bounces@lists.xensource.com > > Excellent. Is it OK if I put 'Tested-by: Adi Kriegish" on them? > Sure, go ahead! ;-) > Update: No, the system just crashed while writing this mail after about 4 days > of uptime with many suspend-resume cycles in between... *sigh* :-( Hmmm.. I wonder if you are hitting the writecombine issue I've seen sometimes. Just to eliminate it, can you try 'nopat' on the Linux command line? .. > > Ok, any other data? Stack trace? > Yes. I will send them in a second mail... I hope I can find all relevant > information. > > You know, I don't know. I just never thought about that - um. I wonder > > if it is related to the RTC update patch that I've been meaning > > to take a look at: > > > > http://lists.xensource.com/archives/html/xen-devel/2010-02/msg00469.html > Sounds like it could be related. Shall I apply that patch? If so, which > hook takes care that the function is called? It kind of automatically hooks up. If you can apply it cleanly - sure. But it might not apply cleanly :-( _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel From xen-devel-bounces@lists.xensource.com Wed Sep 14 07:33:48 2011 Return-path: Envelope-to: www-data@lists.xensource.com Delivery-date: Wed, 14 Sep 2011 07:33:48 -0700 Received: from localhost ([127.0.0.1] helo=lists.colo.xensource.com) by lists.xensource.com with esmtp (Exim 4.43) id 1R3qX5-0000Qu-Tx; Wed, 14 Sep 2011 07:33:47 -0700 Received: from mail216.messagelabs.com ([85.158.143.99]) by lists.xensource.com with esmtp (Exim 4.43) id 1R3qWQ-0000EI-7n for xen-devel@lists.xensource.com; Wed, 14 Sep 2011 07:33:06 -0700 X-Env-Sender: JBeulich@suse.com X-Msg-Ref: server-10.tower-216.messagelabs.com!1316010783!10178583!1 X-Originating-IP: [130.57.49.28] X-StarScan-Version: 6.4.1; banners=-,-,- X-VirusChecked: Checked Received: (qmail 12617 invoked from network); 14 Sep 2011 14:33:03 -0000 Received: from nat28.tlf.novell.com (HELO nat28.tlf.novell.com) (130.57.49.28) by server-10.tower-216.messagelabs.com with DHE-RSA-AES256-SHA encrypted SMTP; 14 Sep 2011 14:33:03 -0000 Received: from EMEA1-MTA by nat28.tlf.novell.com with Novell_GroupWise; Wed, 14 Sep 2011 15:33:02 +0100 Message-Id: <4E70D73B0200007800056143@nat28.tlf.novell.com> X-Mailer: Novell GroupWise Internet Agent 8.0.1 Date: Wed, 14 Sep 2011 15:32:59 +0100 From: "Jan Beulich" To: "Ian Jackson" Subject: Re: [Xen-devel] [PATCH, RFC 0/7] PCI multi-segment support References: <4E64EF860200007800054B03@nat28.tlf.novell.com> In-Reply-To: Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: quoted-printable Content-Disposition: inline Cc: "xen-devel@lists.xensource.com" , Keir Fraser X-BeenThere: xen-devel@lists.xensource.com X-Mailman-Version: 2.1.5 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xensource.com Errors-To: xen-devel-bounces@lists.xensource.com >>> On 05.09.11 at 16:05, Keir Fraser wrote: > On 05/09/2011 14:49, "Jan Beulich" wrote: >=20 >>>>> On 05.09.11 at 15:33, Keir Fraser wrote: >>> On 05/09/2011 14:18, "Jan Beulich" wrote: >>>=20 >>>>>>> On 25.08.11 at 16:54, "Jan Beulich" wrote: >>>>> In order for Xen to be able to boot on systems with multiple PCI = segments >>>>> (also called domains), a number of changes are necessary to the >>>>> hypervisor, the hypercall interface, the tools, and the Dom0 kernel, = as >>>>> in most code paths and definitions there were not even provisions = for >>>>> passing a segment number. >>>>>=20 >>>>> The hypercall interface changes may need some discussion before >>>>> applying the patches, in particular >>>>>=20 >>>>> - whether the way PHYSDEVOP_map_pirq gets re-used is acceptable, >>>>> or whether alternatively we should define a replacement one sub- >>>>> hypercall >>>>> - whether PHYSDEVOP_manage_pci_* should be deprecated >>>>> - whether the bit assignments for the four uses of machine_bdf in >>>>> the domctl interface can be re-defined >>>>=20 >>>> No comment from either of you on the proposed changes? >>>=20 >>> I'm personally fine with folding segment into the bus field. Otherwise = we >>> just end up with more compat cruft. >>>=20 >>> I don't have an opinion on the PHYSDEVOP_manage_pci_* hypercalls. In = fact I >>> don't know much about them at all. >>>=20 >>> I've always considered the domctl interface subject to change, but you = don't >>> seem to redefine anything that already exists? You just give meaning = to bits >>> 24-31 of an existing 32-bit parameter? >>=20 >> I'm trying to avoid incompatible changes when possible (due to >> out-of-tree consumers like libvirt, >=20 > I think the intention is to maintain API compatibility for libxenlight, = and > have out-of-tree tool stacks/librariues build on top of that. >=20 > I think there are libvirt bindings to libxenlight now, for example? >=20 > My conclusion would be you can do the cleaner change to domctl. = Interested > in Ian Jackson's view however. Ian? >> and due to the hacks required to >> use domctl interfaces from the kernel). Now here we need 16 bits, but >> have two sets of 8 (at bottom and top), hence I'd favor doing an >> incompatible change here (moving the bdf bits down to 0...15, and >> using 16...31 for the segment), perhaps renaming the field to >> machine_sbdf (to force compile-time noticing of the change at least >> for those that actually use our headers). But as the odd bit assignment >> could have other (hidden) reasons I coded things first to not do any >> re-assignments. >>=20 >> Jan >>=20 _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel From xen-devel-bounces@lists.xensource.com Wed Sep 14 07:43:01 2011 Return-path: Envelope-to: www-data@lists.xensource.com Delivery-date: Wed, 14 Sep 2011 07:43:01 -0700 Received: from localhost ([127.0.0.1] helo=lists.colo.xensource.com) by lists.xensource.com with esmtp (Exim 4.43) id 1R3qg1-0001Cs-7f; Wed, 14 Sep 2011 07:43:01 -0700 Received: from mail216.messagelabs.com ([85.158.143.99]) by lists.xensource.com with esmtp (Exim 4.43) id 1R3qfL-00010o-1j for xen-devel@lists.xensource.com; Wed, 14 Sep 2011 07:42:21 -0700 X-Env-Sender: david.vrabel@citrix.com X-Msg-Ref: server-15.tower-216.messagelabs.com!1316011330!17801457!1 X-Originating-IP: [66.165.176.89] X-StarScan-Version: 6.4.1; banners=-,-,- X-VirusChecked: Checked Received: (qmail 7053 invoked from network); 14 Sep 2011 14:42:12 -0000 Received: from smtp.citrix.com (HELO SMTP.CITRIX.COM) (66.165.176.89) by server-15.tower-216.messagelabs.com with RC4-SHA encrypted SMTP; 14 Sep 2011 14:42:12 -0000 X-IronPort-AV: E=Sophos;i="4.68,380,1312171200"; d="scan'208";a="16992552" Received: from ftlpmailmx01.citrite.net ([10.13.107.65]) by FTLPIPO01.CITRIX.COM with ESMTP/TLS/RC4-MD5; 14 Sep 2011 10:42:10 -0400 Received: from smtp01.ad.xensource.com (10.219.128.104) by smtprelay.citrix.com (10.13.107.65) with Microsoft SMTP Server id 8.3.137.0; Wed, 14 Sep 2011 10:42:09 -0400 Received: from [192.168.0.1] ([10.31.3.234]) by smtp01.ad.xensource.com (8.13.1/8.13.1) with ESMTP id p8EEg80E024648 for ; Wed, 14 Sep 2011 07:42:09 -0700 Message-ID: <4E70BD31.1090105@citrix.com> Date: Wed, 14 Sep 2011 15:41:53 +0100 From: David Vrabel User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.1.16) Gecko/20110818 Icedove/3.0.11 MIME-Version: 1.0 To: xen-devel@lists.xensource.com Subject: Re: [Xen-devel] Use xenbus API for mapping foreign pages References: <1315911922-4855-1-git-send-email-david.vrabel@citrix.com> In-Reply-To: <1315911922-4855-1-git-send-email-david.vrabel@citrix.com> Content-Type: text/plain; charset="ISO-8859-1"; format=flowed Content-Transfer-Encoding: 7bit X-BeenThere: xen-devel@lists.xensource.com X-Mailman-Version: 2.1.5 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xensource.com Errors-To: xen-devel-bounces@lists.xensource.com On 13/09/11 12:05, David Vrabel wrote: > Xenbus provides an API for mapping foreign pages. Make use of it in > the netback and blkback drivers so when the method for mapping foreign > pages is changed it only need to be updated in one place.ak Don't apply these. I've taken a different approach that obsoletes xenbus_map_ring_valloc() and xenbus_map_ring_vfree(). David _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel From xen-devel-bounces@lists.xensource.com Wed Sep 14 07:46:04 2011 Return-path: Envelope-to: www-data@lists.xensource.com Delivery-date: Wed, 14 Sep 2011 07:46:04 -0700 Received: from localhost ([127.0.0.1] helo=lists.colo.xensource.com) by lists.xensource.com with esmtp (Exim 4.43) id 1R3qiy-0002Hn-2l; Wed, 14 Sep 2011 07:46:04 -0700 Received: from mail27.messagelabs.com ([193.109.254.147]) by lists.xensource.com with esmtp (Exim 4.43) id 1R3qhH-0001dP-53 for xen-devel@lists.xensource.com; Wed, 14 Sep 2011 07:44:19 -0700 X-Env-Sender: fantonifabio@tiscali.it X-Msg-Ref: server-10.tower-27.messagelabs.com!1316011435!35727396!1 X-Originating-IP: [216.139.236.26] X-StarScan-Version: 6.4.1; banners=-,-,- X-VirusChecked: Checked Received: (qmail 519 invoked from network); 14 Sep 2011 14:43:56 -0000 Received: from sam.nabble.com (HELO sam.nabble.com) (216.139.236.26) by server-10.tower-27.messagelabs.com with AES256-SHA encrypted SMTP; 14 Sep 2011 14:43:56 -0000 Received: from [192.168.236.26] (helo=sam.nabble.com) by sam.nabble.com with esmtp (Exim 4.72) (envelope-from ) id 1R3qhC-0001ka-5G for xen-devel@lists.xensource.com; Wed, 14 Sep 2011 07:44:14 -0700 Date: Wed, 14 Sep 2011 07:44:14 -0700 (PDT) From: Fantu To: xen-devel@lists.xensource.com Message-ID: <1316011454156-4803078.post@n5.nabble.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Subject: [Xen-devel] Out sw-iommu space problem X-BeenThere: xen-devel@lists.xensource.com X-Mailman-Version: 2.1.5 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xensource.com Errors-To: xen-devel-bounces@lists.xensource.com We have dom0 Squeeze with official kernel (2.6.32-35squeeze2) and xen 4.0.2-rc3 from git testing on DELL poweredge T310 with raid controller H200 (all with latest firmware). Some domus linux pv and some windows with gplpv. We randomly running into this error during xendomains stop command (with save of all domus): Sep 14 16:18:40 heliMN02WV kernel: [ 912.336945] mpt2sas 0000:03:00.0: DMA: Out of SW-IOMMU space for 65536 bytes. Sep 14 16:18:40 heliMN02WV kernel: [ 912.336951] sd 0:1:0:0: pci_map_sg failed: request for 524288 bytes! Sep 14 16:18:41 heliMN02WV kernel: [ 912.400331] mpt2sas 0000:03:00.0: DMA: Out of SW-IOMMU space for 65536 bytes. Sep 14 16:18:41 heliMN02WV kernel: [ 912.400336] sd 0:1:0:0: pci_map_sg failed: request for 524288 bytes! Sep 14 16:18:45 heliMN02WV kernel: [ 917.187524] mpt2sas 0000:03:00.0: DMA: Out of SW-IOMMU space for 65536 bytes. Sep 14 16:18:45 heliMN02WV kernel: [ 917.187533] sd 0:1:0:0: pci_map_sg failed: request for 524288 bytes! Sep 14 16:18:51 heliMN02WV kernel: [ 922.454599] mpt2sas 0000:03:00.0: DMA: Out of SW-IOMMU space for 65536 bytes. Sep 14 16:18:51 heliMN02WV kernel: [ 922.454608] sd 0:1:0:0: pci_map_sg failed: request for 524288 bytes! Sep 14 16:18:51 heliMN02WV kernel: [ 922.454694] mpt2sas 0000:03:00.0: DMA: Out of SW-IOMMU space for 65536 bytes. Sep 14 16:18:51 heliMN02WV kernel: [ 922.454697] sd 0:1:0:0: pci_map_sg failed: request for 524288 bytes! Sep 14 16:19:11 heliMN02WV kernel: [ 942.850048] frontend_changed: backend/vbd/4/768: prepare for reconnect Sep 14 16:19:11 heliMN02WV kernel: [ 942.869244] eth0: port 5(vif4.0) entering disabled state Sep 14 16:19:11 heliMN02WV kernel: [ 942.889192] eth0: port 5(vif4.0) entering disabled state Sep 14 16:19:11 heliMN02WV kernel: [ 943.188048] frontend_changed: backend/vif/4/0: prepare for reconnect Sep 14 16:19:22 heliMN02WV kernel: [ 954.246090] mpt2sas 0000:03:00.0: DMA: Out of SW-IOMMU space for 65536 bytes. Sep 14 16:19:22 heliMN02WV kernel: [ 954.246095] sd 0:1:0:0: pci_map_sg failed: request for 524288 bytes! Sep 14 16:19:22 heliMN02WV kernel: [ 954.305068] mpt2sas 0000:03:00.0: DMA: Out of SW-IOMMU space for 65536 bytes. Sep 14 16:19:22 heliMN02WV kernel: [ 954.305074] sd 0:1:0:0: pci_map_sg failed: request for 524288 bytes! Sep 14 16:19:34 heliMN02WV kernel: [ 966.112058] mpt2sas 0000:03:00.0: DMA: Out of SW-IOMMU space for 65536 bytes. Sep 14 16:19:34 heliMN02WV kernel: [ 966.112064] sd 0:1:0:0: pci_map_sg failed: request for 524288 bytes! Sep 14 16:19:34 heliMN02WV kernel: [ 966.112251] mpt2sas 0000:03:00.0: DMA: Out of SW-IOMMU space for 65536 bytes. Sep 14 16:19:34 heliMN02WV kernel: [ 966.112255] sd 0:1:0:0: pci_map_sg failed: request for 524288 bytes! Sep 14 16:19:34 heliMN02WV kernel: [ 966.112440] mpt2sas 0000:03:00.0: DMA: Out of SW-IOMMU space for 65536 bytes. Sep 14 16:19:34 heliMN02WV kernel: [ 966.112443] sd 0:1:0:0: pci_map_sg failed: request for 524288 bytes! Sep 14 16:19:34 heliMN02WV kernel: [ 966.205690] mpt2sas 0000:03:00.0: DMA: Out of SW-IOMMU space for 65536 bytes. Sep 14 16:19:34 heliMN02WV kernel: [ 966.205693] sd 0:1:0:0: pci_map_sg failed: request for 524288 bytes! Sep 14 16:19:40 heliMN02WV kernel: [ 971.728913] eth0: port 6(vif5.0) entering disabled state Sep 14 16:19:40 heliMN02WV kernel: [ 971.752683] eth0: port 6(vif5.0) entering disabled state Sep 14 16:19:45 heliMN02WV kernel: [ 976.984329] mpt2sas 0000:03:00.0: DMA: Out of SW-IOMMU space for 65536 bytes. Sep 14 16:19:45 heliMN02WV kernel: [ 976.984333] sd 0:1:0:0: pci_map_sg failed: request for 524288 bytes! Sep 14 16:19:49 heliMN02WV kernel: [ 981.288632] eth0: port 7(vif6.0) entering disabled state Sep 14 16:19:49 heliMN02WV kernel: [ 981.304521] eth0: port 7(vif6.0) entering disabled state Sep 14 16:19:50 heliMN02WV kernel: [ 982.329740] frontend_changed: backend/vbd/7/768: prepare for reconnect Sep 14 16:19:50 heliMN02WV kernel: [ 982.372593] eth0: port 8(vif7.0) entering disabled state Sep 14 16:19:51 heliMN02WV kernel: [ 982.416506] eth0: port 8(vif7.0) entering disabled state Sep 14 16:19:51 heliMN02WV kernel: [ 982.744206] frontend_changed: backend/vif/7/0: prepare for reconnect Sep 14 16:20:00 heliMN02WV kernel: [ 991.520780] mpt2sas 0000:03:00.0: DMA: Out of SW-IOMMU space for 65536 bytes. Sep 14 16:20:00 heliMN02WV kernel: [ 991.520787] sd 0:1:0:0: pci_map_sg failed: request for 524288 bytes! Sep 14 16:20:00 heliMN02WV kernel: [ 991.524695] mpt2sas 0000:03:00.0: DMA: Out of SW-IOMMU space for 65536 bytes. Sep 14 16:20:00 heliMN02WV kernel: [ 991.524698] sd 0:1:0:0: pci_map_sg failed: request for 524288 bytes! Sep 14 16:20:00 heliMN02WV kernel: [ 991.525040] mpt2sas 0000:03:00.0: DMA: Out of SW-IOMMU space for 65536 bytes. Sep 14 16:20:00 heliMN02WV kernel: [ 991.525042] sd 0:1:0:0: pci_map_sg failed: request for 524288 bytes! Sep 14 16:20:00 heliMN02WV kernel: [ 991.525371] mpt2sas 0000:03:00.0: DMA: Out of SW-IOMMU space for 65536 bytes. Sep 14 16:20:00 heliMN02WV kernel: [ 991.525374] sd 0:1:0:0: pci_map_sg failed: request for 524288 bytes! Sep 14 16:20:00 heliMN02WV kernel: [ 991.527766] mpt2sas 0000:03:00.0: DMA: Out of SW-IOMMU space for 65536 bytes. Sep 14 16:20:00 heliMN02WV kernel: [ 991.527769] sd 0:1:0:0: pci_map_sg failed: request for 524288 bytes! Sep 14 16:20:01 heliMN02WV kernel: [ 992.493163] mpt2sas 0000:03:00.0: DMA: Out of SW-IOMMU space for 65536 bytes. Sep 14 16:20:01 heliMN02WV kernel: [ 992.493167] sd 0:1:0:0: pci_map_sg failed: request for 524288 bytes! Sep 14 16:20:13 heliMN02WV kernel: [ 1004.938378] tapdisk2[7617]: segfault at 7fff92fb6ff8 ip 0000000000408296 sp 00007fff92fb7000 error 6 in tapdisk2[400000+39000] Sep 14 16:20:13 heliMN02WV kernel: [ 1004.959533] BUG: unable to handle kernel NULL pointer dereference at 0000000000000048 Sep 14 16:20:13 heliMN02WV kernel: [ 1004.959681] IP: [] apply_to_page_range+0x47/0x2f3 Sep 14 16:20:13 heliMN02WV kernel: [ 1004.959773] PGD 3dc5f067 PUD 3db57067 PMD 0 Sep 14 16:20:13 heliMN02WV kernel: [ 1004.959914] Oops: 0000 [#1] SMP Sep 14 16:20:13 heliMN02WV kernel: [ 1004.960026] last sysfs file: /sys/devices/virtual/blktap2/blktap11/remove Sep 14 16:20:13 heliMN02WV kernel: [ 1004.960084] CPU 5 Sep 14 16:20:13 heliMN02WV kernel: [ 1004.960161] Modules linked in: xt_tcpudp tun xt_physdev iptable_filter ip_tables x_tables bridge stp ib_iser rdma_cm ib_cm iw_cm ib_sa ib_mad ib_core ib_addr iscsi_tcp libiscsi_tcp libiscsi scsi_transport_iscsi ext2 sha256_generic aes_x86_64 aes_generic cbc blktap xen_evtchn xenfs loop dm_crypt dcdbas snd_pcm snd_timer snd joydev evdev soundcore snd_page_alloc pcspkr power_meter button processor acpi_processor ext4 mbcache jbd2 crc16 dm_mod sd_mod crc_t10dif sg usbhid hid sr_mod cdrom usb_storage ata_generic ehci_hcd ata_piix mpt2sas bnx2 scsi_transport_sas libata usbcore nls_base scsi_mod thermal thermal_sys [last unloaded: scsi_wait_scan] Sep 14 16:20:13 heliMN02WV kernel: [ 1004.962493] Pid: 7617, comm: tapdisk2 Not tainted 2.6.32-5-xen-amd64 #1 PowerEdge T310 Sep 14 16:20:13 heliMN02WV kernel: [ 1004.962566] RIP: e030:[] [] apply_to_page_range+0x47/0x2f3 Sep 14 16:20:13 heliMN02WV kernel: [ 1004.962671] RSP: e02b:ffff88003dfc9b58 EFLAGS: 00010202 Sep 14 16:20:13 heliMN02WV kernel: [ 1004.962726] RAX: 0000000000000880 RBX: ffff88003d8ad000 RCX: ffff88003d8ae000 Sep 14 16:20:13 heliMN02WV kernel: [ 1004.962783] RDX: 0000000000000000 RSI: ffff88003d8ad000 RDI: 0000000000000000 Sep 14 16:20:13 heliMN02WV kernel: [ 1004.962840] RBP: ffff88003eff2dd0 R08: 0000000000000000 R09: ffff88003f96c180 Sep 14 16:20:13 heliMN02WV kernel: [ 1004.962898] R10: 0000000000000002 R11: 0000000000000000 R12: 0000000000000000 Sep 14 16:20:13 heliMN02WV kernel: [ 1004.962955] R13: ffff88003eff2dd0 R14: ffff88003e149000 R15: 0000000000000000 Sep 14 16:20:13 heliMN02WV kernel: [ 1004.963014] FS: 00007f6d3c738740(0000) GS:ffff880003782000(0000) knlGS:0000000000000000 Sep 14 16:20:13 heliMN02WV kernel: [ 1004.963088] CS: e033 DS: 0000 ES: 0000 CR0: 000000008005003b Sep 14 16:20:13 heliMN02WV kernel: [ 1004.963143] CR2: 0000000000000048 CR3: 000000003f0dc000 CR4: 0000000000002660 Sep 14 16:20:13 heliMN02WV kernel: [ 1004.963201] DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 Sep 14 16:20:13 heliMN02WV kernel: [ 1004.963258] DR3: 0000000000000000 DR6: 00000000ffff0ff0 DR7: 0000000000000400 Sep 14 16:20:13 heliMN02WV kernel: [ 1004.963316] Process tapdisk2 (pid: 7617, threadinfo ffff88003dfc8000, task ffff880036a88e20) Sep 14 16:20:13 heliMN02WV kernel: [ 1004.963389] Stack: Sep 14 16:20:13 heliMN02WV kernel: [ 1004.963437] 0000000000000000 ffff88003ea87b40 0000000000000000 0000000000000000 Sep 14 16:20:13 heliMN02WV kernel: [ 1004.963583] <0> ffffffffa02f1ee8 0000000000000000 ffffffff8100ece2 ffff880002155480 Sep 14 16:20:13 heliMN02WV kernel: [ 1004.963802] <0> ffff88003d8ae000 0000000000000000 0000000000000000 ffff880002155480 Sep 14 16:20:13 heliMN02WV kernel: [ 1004.964066] Call Trace: Sep 14 16:20:13 heliMN02WV kernel: [ 1004.964119] [] ? blktap_umap_uaddr_fn+0x0/0x59 [blktap] Sep 14 16:20:13 heliMN02WV kernel: [ 1004.964179] [] ? check_events+0x12/0x20 Sep 14 16:20:13 heliMN02WV kernel: [ 1004.964236] [] ? blktap_device_end_request+0xbd/0x145 [blktap] Sep 14 16:20:13 heliMN02WV kernel: [ 1004.964310] [] ? blktap_ring_vm_close+0x60/0xd1 [blktap] Sep 14 16:20:13 heliMN02WV kernel: [ 1004.964368] [] ? remove_vma+0x2c/0x72 Sep 14 16:20:13 heliMN02WV kernel: [ 1004.964423] [] ? exit_mmap+0x129/0x148 Sep 14 16:20:13 heliMN02WV kernel: [ 1004.964479] [] ? mmput+0x3c/0xdf Sep 14 16:20:13 heliMN02WV kernel: [ 1004.964534] [] ? exit_mm+0x102/0x10d Sep 14 16:20:13 heliMN02WV kernel: [ 1004.964592] [] ? _spin_lock_irq+0x7/0x22 Sep 14 16:20:13 heliMN02WV kernel: [ 1004.964648] [] ? do_exit+0x1f8/0x6c6 Sep 14 16:20:13 heliMN02WV kernel: [ 1004.964703] [] ? __dequeue_signal+0xfb/0x124 Sep 14 16:20:13 heliMN02WV kernel: [ 1004.964760] [] ? xen_restore_fl_direct_end+0x0/0x1 Sep 14 16:20:13 heliMN02WV kernel: [ 1004.964817] [] ? kmem_cache_free+0x72/0xa3 Sep 14 16:20:13 heliMN02WV kernel: [ 1004.964874] [] ? do_group_exit+0x76/0x9d Sep 14 16:20:13 heliMN02WV kernel: [ 1004.964930] [] ? get_signal_to_deliver+0x310/0x339 Sep 14 16:20:13 heliMN02WV kernel: [ 1004.964987] [] ? do_notify_resume+0x87/0x73f Sep 14 16:20:13 heliMN02WV kernel: [ 1004.965044] [] ? expand_downwards+0x5b/0x169 Sep 14 16:20:13 heliMN02WV kernel: [ 1004.965101] [] ? do_page_fault+0x1f3/0x2f2 Sep 14 16:20:13 heliMN02WV kernel: [ 1004.965157] [] ? retint_signal+0x48/0x8c Sep 14 16:20:13 heliMN02WV kernel: [ 1004.965211] Code: 48 89 4c 24 20 4c 89 44 24 18 48 89 54 24 40 72 04 0f 0b eb fe 48 8b 54 24 28 48 89 f0 48 8b 4c 24 40 48 c1 e8 24 25 f8 0f 00 00 <48> 8b 52 48 48 ff c9 48 89 0c 24 48 01 d0 48 89 44 24 30 48 b8 Sep 14 16:20:13 heliMN02WV kernel: [ 1004.967243] RIP [] apply_to_page_range+0x47/0x2f3 Sep 14 16:20:13 heliMN02WV kernel: [ 1004.967336] RSP Sep 14 16:20:13 heliMN02WV kernel: [ 1004.967388] CR2: 0000000000000048 Sep 14 16:20:13 heliMN02WV kernel: [ 1004.967440] ---[ end trace 78b5f16c10850a91 ]--- Sep 14 16:20:13 heliMN02WV kernel: [ 1004.967495] Fixing recursive fault but reboot is needed! Rebooting the systems doesn't resolve this problem. We have also try to add swiotlb=128 on vmlinuz line but the systems always loops with "out sw-iommu space" message (probably also bug in swiotlb switch on kernel). Can someone help us to solve this problem please? -- View this message in context: http://xen.1045712.n5.nabble.com/Out-sw-iommu-space-problem-tp4803078p4803078.html Sent from the Xen - Dev mailing list archive at Nabble.com. _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel From xen-devel-bounces@lists.xensource.com Wed Sep 14 07:47:20 2011 Return-path: Envelope-to: www-data@lists.xensource.com Delivery-date: Wed, 14 Sep 2011 07:47:20 -0700 Received: from localhost ([127.0.0.1] helo=lists.colo.xensource.com) by lists.xensource.com with esmtp (Exim 4.43) id 1R3qkC-0002ec-Bn; Wed, 14 Sep 2011 07:47:20 -0700 Received: from mail27.messagelabs.com ([193.109.254.147]) by lists.xensource.com with esmtp (Exim 4.43) id 1R3qie-0002AS-G5; Wed, 14 Sep 2011 07:45:45 -0700 X-Env-Sender: pasik@iki.fi X-Msg-Ref: server-2.tower-27.messagelabs.com!1316011517!54947681!1 X-Originating-IP: [192.89.123.25] X-StarScan-Version: 6.4.1; banners=-,-,- X-VirusChecked: Checked Received: (qmail 28126 invoked from network); 14 Sep 2011 14:45:18 -0000 Received: from smtp.tele.fi (HELO smtp.tele.fi) (192.89.123.25) by server-2.tower-27.messagelabs.com with DHE-RSA-AES256-SHA encrypted SMTP; 14 Sep 2011 14:45:18 -0000 X-Originating-Ip: [194.89.68.22] Received: from ydin.reaktio.net (reaktio.net [194.89.68.22]) by smtp.tele.fi (Postfix) with ESMTP id C6E022CD9; Wed, 14 Sep 2011 17:45:39 +0300 (EEST) Received: by ydin.reaktio.net (Postfix, from userid 1001) id B3215200DB; Wed, 14 Sep 2011 17:45:39 +0300 (EEST) Date: Wed, 14 Sep 2011 17:45:39 +0300 From: Pasi =?iso-8859-1?Q?K=E4rkk=E4inen?= To: Konrad Rzeszutek Wilk Subject: Re: [Xen-devel] Re: Virtualization Test Day for F16 and Xen Message-ID: <20110914144539.GR12984@reaktio.net> References: <20110914112552.GP12984@reaktio.net> <20110914142522.GA16956@phenom.oracle.com> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <20110914142522.GA16956@phenom.oracle.com> User-Agent: Mutt/1.5.18 (2008-05-17) Cc: Development discussions related to Fedora , xen@lists.fedoraproject.org, xen-devel@lists.xensource.com, lars.kurth@xen.org, virt@lists.fedoraproject.org, xen-users@lists.xensource.com X-BeenThere: xen-devel@lists.xensource.com X-Mailman-Version: 2.1.5 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xensource.com Errors-To: xen-devel-bounces@lists.xensource.com On Wed, Sep 14, 2011 at 10:25:23AM -0400, Konrad Rzeszutek Wilk wrote: > On Wed, Sep 14, 2011 at 02:25:52PM +0300, Pasi Kärkkäinen wrote: > > On Sat, Sep 10, 2011 at 01:33:54AM +0300, Myroslav Opyr wrote: > > > Hi, > > > > Hello, > > > > > Virtualization Test day is expected to be on September 15th this year > > > ([1]https://fedorahosted.org/fedora-qa/ticket/232). > > Cool. > > > > > > > So that's tomorrow! > > > > Luckily Xen Hackathon (@Munich) event is just happening, > > so hopefully we can get some more testing from people in that event. > > > > > We are willing to help test > > > [2]http://fedoraproject.org/wiki/Features/XenPvopsDom0 but find too little > > > information about test methods > > It really ought to be parallel to what you would do with KVM/QEMU. Basically > the same steps - but I am not sure how well does libvirt work with xm/xl nowadays. > Or the virt-manager - but it suppose to interact with magically. > libvirt support for xm/xend *should* work, and there's also the libvirt libxl driver written by Jim Fehlig from Novell/SUSE. > Is there a KVM/QEMU/libvirt help test Wiki? I saw this: > https://fedoraproject.org/wiki/Getting_started_with_virtualization > and it kind of parallels it, albeit I didn't see anything about setting the network > which sometimes is the biggest pain point: > > http://www.fedoraforum.org/forum/showthread.php?t=268427 > When you install libvirt it'll automatically create/start a bridge called "virbr0", which is an host-internal bridge with "dnsmasq" running and configured to provide dhcp server with private ip range, dns relay and NAT on that bridge. So that's good enough for trying some VMs or running VM netboot installs. > > > > ([3]https://fedorahosted.org/fedora-qa/ticket/219). It takes time for us > > > to setup test environment, and would be good to have some info in advance. > > > There are known bugs in FC15/FC16 that have been filled some time ago that > folks will sadly run into: 728775, 658387 and 668063 > > Fortunatly the bugs have patches attached and the files to be modified are shell scripts. > Yep, links here: https://bugzilla.redhat.com/show_bug.cgi?id=728775 https://bugzilla.redhat.com/show_bug.cgi?id=658387 https://bugzilla.redhat.com/show_bug.cgi?id=668063 -- Pasi > > > Regards, > > > > > > > I just added some Xen related mailinglists to the CC list, > > so we can get more feedback. > > > > Thanks, > > > > -- Pasi > > > > > > _______________________________________________ > > Xen-devel mailing list > > Xen-devel@lists.xensource.com > > http://lists.xensource.com/xen-devel _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel From xen-devel-bounces@lists.xensource.com Wed Sep 14 07:50:54 2011 Return-path: Envelope-to: www-data@lists.xensource.com Delivery-date: Wed, 14 Sep 2011 07:50:54 -0700 Received: from localhost ([127.0.0.1] helo=lists.colo.xensource.com) by lists.xensource.com with esmtp (Exim 4.43) id 1R3qne-0003nj-Eh; Wed, 14 Sep 2011 07:50:54 -0700 Received: from mail27.messagelabs.com ([193.109.254.147]) by lists.xensource.com with esmtp (Exim 4.43) id 1R3qmJ-0003Jy-8S for xen-devel@lists.xensource.com; Wed, 14 Sep 2011 07:49:32 -0700 X-Env-Sender: andi@firstfloor.org X-Msg-Ref: server-2.tower-27.messagelabs.com!1316011744!54948486!1 X-Originating-IP: [213.235.205.2] X-StarScan-Version: 6.4.1; banners=-,-,- X-VirusChecked: Checked Received: (qmail 7901 invoked from network); 14 Sep 2011 14:49:04 -0000 Received: from one.firstfloor.org (HELO one.firstfloor.org) (213.235.205.2) by server-2.tower-27.messagelabs.com with DHE-RSA-AES256-SHA encrypted SMTP; 14 Sep 2011 14:49:04 -0000 Received: by one.firstfloor.org (Postfix, from userid 503) id 99FC31ED80B5; Wed, 14 Sep 2011 16:49:26 +0200 (CEST) Date: Wed, 14 Sep 2011 16:49:26 +0200 From: Andi Kleen To: Avi Kivity Message-ID: <20110914144926.GU7761@one.firstfloor.org> References: <20110907134411.GV5795@redhat.com> <4E678992.5050709@redhat.com> <20110907155657.GX5795@redhat.com> <4E679AF4.50209@redhat.com> <20110907165203.GQ6838@redhat.com> <4E67A551.4000502@redhat.com> <20110913184044.GN5795@redhat.com> <20110913190320.GR7761@one.firstfloor.org> <20110913192152.GO5795@redhat.com> <4E7050F7.3000208@redhat.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <4E7050F7.3000208@redhat.com> User-Agent: Mutt/1.4.2.2i Cc: Don Zickus , Jeremy Fitzhardinge , Marcelo Tosatti , Nick Piggin , KVM , Stefano Stabellini , Peter Zijlstra , the arch/x86 maintainers , Linux Kernel Mailing List , Andi Kleen , Jeremy Fitzhardinge , "H. Peter Anvin" , Ingo Molnar , Linus Torvalds , Xen Devel Subject: [Xen-devel] Re: [PATCH 08/13] xen/pvticketlock: disable interrupts while blocking X-BeenThere: xen-devel@lists.xensource.com X-Mailman-Version: 2.1.5 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xensource.com Errors-To: xen-devel-bounces@lists.xensource.com On Wed, Sep 14, 2011 at 10:00:07AM +0300, Avi Kivity wrote: > On 09/13/2011 10:21 PM, Don Zickus wrote: > >Or are you saying an NMI in an idle system will have the same %rip thus > >falsely detecting a back-to-back NMI? > > > > > > That's easy to avoid - insert an instruction zeroing the last nmi_rip > somewhere before or after hlt. It's always okay to execute such an > instruction (outside the nmi handler itself), since nmi_rip is meant to > detect a "no instructions executed" condition. At least for classic hlt there is no simple "after hlt" because it's all interrupt handlers and exceptions and everything else that can interrupt combined. It may work with newer MWAIT. -Andi -- ak@linux.intel.com -- Speaking for myself only. _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel From xen-devel-bounces@lists.xensource.com Wed Sep 14 07:51:45 2011 Return-path: Envelope-to: www-data@lists.xensource.com Delivery-date: Wed, 14 Sep 2011 07:51:45 -0700 Received: from localhost ([127.0.0.1] helo=lists.colo.xensource.com) by lists.xensource.com with esmtp (Exim 4.43) id 1R3qoT-0004Aq-09; Wed, 14 Sep 2011 07:51:45 -0700 Received: from mail174.messagelabs.com ([85.158.138.51]) by lists.xensource.com with esmtp (Exim 4.43) id 1R3qnP-0003f6-Vd for xen-devel@lists.xensource.com; Wed, 14 Sep 2011 07:50:40 -0700 X-Env-Sender: Ian.Jackson@eu.citrix.com X-Msg-Ref: server-2.tower-174.messagelabs.com!1316011834!31417976!1 X-Originating-IP: [62.200.22.115] X-StarScan-Version: 6.4.1; banners=-,-,- X-VirusChecked: Checked Received: (qmail 29560 invoked from network); 14 Sep 2011 14:50:36 -0000 Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115) by server-2.tower-174.messagelabs.com with RC4-SHA encrypted SMTP; 14 Sep 2011 14:50:36 -0000 X-IronPort-AV: E=Sophos;i="4.68,380,1312156800"; d="scan'208";a="7813105" Received: from lonpmailmx01.citrite.net ([10.30.203.162]) by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5; 14 Sep 2011 14:50:34 +0000 Received: from woking.xci-test.com (10.80.248.135) by smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id 8.3.137.0; Wed, 14 Sep 2011 15:50:34 +0100 Received: from osstest by woking.xci-test.com with local (Exim 4.69) (envelope-from ) id 1R3qnK-0004mK-9H; Wed, 14 Sep 2011 15:50:34 +0100 To: xen-devel@lists.xensource.com Message-ID: From: xen.org Date: Wed, 14 Sep 2011 15:50:34 +0100 MIME-Version: 1.0 Content-Type: text/plain Cc: ian.jackson@eu.citrix.com Subject: [Xen-devel] [xen-unstable test] 8935: regressions - FAIL X-BeenThere: xen-devel@lists.xensource.com X-Mailman-Version: 2.1.5 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xensource.com Errors-To: xen-devel-bounces@lists.xensource.com flight 8935 xen-unstable real [real] http://www.chiark.greenend.org.uk/~xensrcts/logs/8935/ Regressions :-( Tests which did not succeed and are blocking: build-amd64 4 xen-build fail REGR. vs. 8873 build-amd64-oldkern 4 xen-build fail REGR. vs. 8873 Tests which did not succeed, but are not blocking, including regressions (tests previously passed) regarded as allowable: test-amd64-amd64-xl-pcipt-intel 1 xen-build-check(1) blocked n/a test-amd64-i386-rhel6hvm-intel 1 xen-build-check(1) blocked n/a test-i386-i386-pv 1 xen-build-check(1) blocked n/a test-amd64-i386-pv 1 xen-build-check(1) blocked n/a test-amd64-amd64-pv 1 xen-build-check(1) blocked n/a test-i386-i386-xl 1 xen-build-check(1) blocked n/a test-amd64-i386-xl 1 xen-build-check(1) blocked n/a test-amd64-i386-xl-credit2 1 xen-build-check(1) blocked n/a test-amd64-i386-rhel6hvm-amd 1 xen-build-check(1) blocked n/a test-amd64-amd64-pair 1 xen-build-check(1) blocked n/a test-amd64-i386-pair 1 xen-build-check(1) blocked n/a test-i386-i386-pair 1 xen-build-check(1) blocked n/a build-amd64-pvops 4 kernel-build fail like 8873 build-i386-pvops 4 kernel-build fail like 8873 test-amd64-i386-xl-multivcpu 1 xen-build-check(1) blocked n/a test-amd64-amd64-xl-sedf 1 xen-build-check(1) blocked n/a test-amd64-i386-win-vcpus1 1 xen-build-check(1) blocked n/a test-amd64-i386-xl-win-vcpus1 1 xen-build-check(1) blocked n/a test-amd64-amd64-win 1 xen-build-check(1) blocked n/a test-amd64-i386-win 1 xen-build-check(1) blocked n/a test-amd64-amd64-xl-win 1 xen-build-check(1) blocked n/a test-amd64-amd64-xl 1 xen-build-check(1) blocked n/a test-i386-i386-xl-win 1 xen-build-check(1) blocked n/a test-i386-i386-win 1 xen-build-check(1) blocked n/a version targeted for testing: xen e90438f6e6d1 baseline version: xen 0312575dc35e ------------------------------------------------------------ People who touched revisions under test: Andrew Cooper Benjamin Schweikert Christoph Egger George Dunlap Ian Campbell Ian Jackson Keir Fraser Olaf Hering Stefano Stabellini Tim Deegan ------------------------------------------------------------ jobs: build-amd64 fail build-i386 pass build-amd64-oldkern fail build-i386-oldkern pass build-amd64-pvops fail build-i386-pvops fail test-amd64-amd64-xl blocked test-amd64-i386-xl blocked test-i386-i386-xl blocked test-amd64-i386-rhel6hvm-amd blocked test-amd64-i386-xl-credit2 blocked test-amd64-amd64-xl-pcipt-intel blocked test-amd64-i386-rhel6hvm-intel blocked test-amd64-i386-xl-multivcpu blocked test-amd64-amd64-pair blocked test-amd64-i386-pair blocked test-i386-i386-pair blocked test-amd64-amd64-pv blocked test-amd64-i386-pv blocked test-i386-i386-pv blocked test-amd64-amd64-xl-sedf blocked test-amd64-i386-win-vcpus1 blocked test-amd64-i386-xl-win-vcpus1 blocked test-amd64-amd64-win blocked test-amd64-i386-win blocked test-i386-i386-win blocked test-amd64-amd64-xl-win blocked test-i386-i386-xl-win blocked ------------------------------------------------------------ sg-report-flight on woking.cam.xci-test.com logs: /home/xc_osstest/logs images: /home/xc_osstest/images Logs, config files, etc. are available at http://www.chiark.greenend.org.uk/~xensrcts/logs Test harness code can be found at http://xenbits.xensource.com/gitweb?p=osstest.git;a=summary Not pushing. ------------------------------------------------------------ changeset: 23838:e90438f6e6d1 tag: tip user: Ian Jackson date: Wed Sep 14 11:38:13 2011 +0100 tools: Revert seabios and upstream qemu build changes These have broken the build and it seems to be difficult to fix. So we will revert the whole lot for now, and await corrected patch(es). Revert "fix the build when CONFIG_QEMU is specified by the user" Revert "tools: fix permissions of git-checkout.sh" Revert "scripts/git-checkout.sh: Is not bash specific. Invoke with /bin/sh." Revert "Clone and build Seabios by default" Revert "Clone and build upstream Qemu by default" Revert "Rename ioemu-dir as qemu-xen-traditional-dir" Revert "Move the ioemu-dir-find shell script to an external file" Signed-off-by: Ian Jackson changeset: 23837:51913fe3d25a user: Stefano Stabellini date: Tue Sep 13 15:46:47 2011 +0100 fix the build when CONFIG_QEMU is specified by the user Signed-off-by: Stefano Stabellini Committed-by: Stefano Stabellini changeset: 23836:e564f2f1b737 user: Ian Jackson date: Tue Sep 13 14:52:22 2011 +0100 tools: fix permissions of git-checkout.sh 23828:0d21b68f528b introduced a new scripts/git-checkout.sh, but it had the wrong permissions. chmod +x it, and add a blank line at the end to make sure it actually gets updated. Signed-off-by: Ian Jackson changeset: 23835:64aab9a077ea user: Keir Fraser date: Tue Sep 13 11:20:57 2011 +0100 scripts/git-checkout.sh: Is not bash specific. Invoke with /bin/sh. Signed-off-by: Keir Fraser changeset: 23834:1d40b2793723 user: George Dunlap date: Tue Sep 13 10:43:43 2011 +0100 xen,credit1: Add variable timeslice Add a xen command-line parameter, sched_credit_tslice_ms, to set the timeslice of the credit1 scheduler. Signed-off-by: George Dunlap changeset: 23833:ffe8e65f6687 user: Andrew Cooper date: Tue Sep 13 10:33:10 2011 +0100 IRQ: IO-APIC support End Of Interrupt for older IO-APICs The old io_apic_eoi() function using the EOI register only works for IO-APICs with a version of 0x20. Older IO-APICs do not have an EOI register so line level interrupts have to be EOI'd by flipping the mode to edge and back, which clears the IRR and Delivery Status bits. This patch replaces the current io_apic_eoi() function with one which takes into account the version of the IO-APIC and EOI's appropriately. v2: make recursive call to __io_apic_eoi() to reduce code size. Signed-off-by: Andrew Cooper changeset: 23832:ad3b4bb097cb user: Stefano Stabellini date: Tue Sep 13 10:32:24 2011 +0100 xen: if mapping GSIs we run out of pirq < nr_irqs_gsi, use the others PV on HVM guests can have more GSIs than the host, in that case we could run out of pirq < nr_irqs_gsi. When that happens use pirq >= nr_irqs_gsi rather than returning an error. Signed-off-by: Stefano Stabellini Tested-by: Benjamin Schweikert changeset: 23831:53416e7c0529 user: Stefano Stabellini date: Tue Sep 13 10:30:09 2011 +0100 Clone and build Seabios by default Signed-off-by: Stefano Stabellini changeset: 23830:1b80eaeeba7b user: Stefano Stabellini date: Tue Sep 13 10:29:14 2011 +0100 Clone and build upstream Qemu by default Signed-off-by: Stefano Stabellini changeset: 23829:9a541243aeaf user: Stefano Stabellini date: Tue Sep 13 10:27:53 2011 +0100 Rename ioemu-dir as qemu-xen-traditional-dir Signed-off-by: Stefano Stabellini changeset: 23828:0d21b68f528b user: Stefano Stabellini date: Tue Sep 13 10:27:20 2011 +0100 Move the ioemu-dir-find shell script to an external file Add support for configuring upstream qemu and rename ioemu-remote ioemu-dir-remote. Signed-off-by: Stefano Stabellini changeset: 23827:d1d6abc1db20 user: Olaf Hering date: Tue Sep 13 10:25:32 2011 +0100 xenpaging: use batch of pages during final page-in Map up to RING_SIZE pages in exit path to fill the ring instead of populating one page at a time. Signed-off-by: Olaf Hering changeset: 23826:ad958e87db79 user: Ian Campbell date: Tue Sep 13 10:22:03 2011 +0100 hvmloader: don't clear acpi_info after filling in some fields In particular the madt_lapic0_addr and madt_csum_addr fields are filled in while building the tables. This fixes a bluescreen on shutdown with certain versions of Windows. Signed-off-by: Ian Campbell Reported-by: Christoph Egger Tested-and-acked-by: Christoph Egger changeset: 23825:0312575dc35e user: Tim Deegan date: Thu Sep 08 15:13:06 2011 +0100 x86/mm: use new page-order interfaces in nested HAP code to make 2M and 1G mappings in the nested p2m tables. Signed-off-by: Christoph Egger Signed-off-by: Tim Deegan Committed-by: Tim Deegan ======================================== commit cd776ee9408ff127f934a707c1a339ee600bc127 Author: Ian Jackson Date: Tue Jun 28 13:50:53 2011 +0100 qemu-char.c: fix incorrect CONFIG_STUBDOM handling qemu-char.c:1123:7: warning: "CONFIG_STUBDOM" is not defined [-Wundef] Signed-off-by: Olaf Hering Acked-by: Ian Jackson _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel From xen-devel-bounces@lists.xensource.com Wed Sep 14 07:54:45 2011 Return-path: Envelope-to: www-data@lists.xensource.com Delivery-date: Wed, 14 Sep 2011 07:54:45 -0700 Received: from localhost ([127.0.0.1] helo=lists.colo.xensource.com) by lists.xensource.com with esmtp (Exim 4.43) id 1R3qrN-0004aJ-JB; Wed, 14 Sep 2011 07:54:45 -0700 Received: from mail21.messagelabs.com ([85.158.143.35]) by lists.xensource.com with esmtp (Exim 4.43) id 1R3qqv-0004OO-LC for xen-devel@lists.xensource.com; Wed, 14 Sep 2011 07:54:18 -0700 X-Env-Sender: konrad@oracle.com X-Msg-Ref: server-2.tower-21.messagelabs.com!1316012052!34090828!1 X-Originating-IP: [148.87.113.117] X-StarScan-Version: 6.4.1; banners=-,-,- X-VirusChecked: Checked Received: (qmail 12114 invoked from network); 14 Sep 2011 14:54:13 -0000 Received: from rcsinet15.oracle.com (HELO rcsinet15.oracle.com) (148.87.113.117) by server-2.tower-21.messagelabs.com with DHE-RSA-AES256-SHA encrypted SMTP; 14 Sep 2011 14:54:13 -0000 Received: from rtcsinet21.oracle.com (rtcsinet21.oracle.com [66.248.204.29]) by rcsinet15.oracle.com (Switch-3.4.4/Switch-3.4.4) with ESMTP id p8EEsAoo023065 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Wed, 14 Sep 2011 14:54:12 GMT Received: from acsmt357.oracle.com (acsmt357.oracle.com [141.146.40.157]) by rtcsinet21.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id p8EEs9nC028432 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 14 Sep 2011 14:54:09 GMT Received: from abhmt104.oracle.com (abhmt104.oracle.com [141.146.116.56]) by acsmt357.oracle.com (8.12.11.20060308/8.12.11) with ESMTP id p8EEs3fJ013649; Wed, 14 Sep 2011 09:54:03 -0500 Received: from oracle.com (/209.6.55.207) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Wed, 14 Sep 2011 07:54:03 -0700 Received: by oracle.com (Postfix, from userid 1000) id 1F08A1362; Wed, 14 Sep 2011 10:54:04 -0400 (EDT) Date: Wed, 14 Sep 2011 10:54:04 -0400 From: Konrad Rzeszutek Wilk To: Fantu Subject: Re: [Xen-devel] Out sw-iommu space problem Message-ID: <20110914145403.GA17899@phenom.oracle.com> References: <1316011454156-4803078.post@n5.nabble.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <1316011454156-4803078.post@n5.nabble.com> User-Agent: Mutt/1.5.21 (2010-09-15) X-Source-IP: rtcsinet21.oracle.com [66.248.204.29] X-CT-RefId: str=0001.0A090206.4E70C014.01B7,ss=1,re=-2.300,fgs=0 Cc: xen-devel@lists.xensource.com X-BeenThere: xen-devel@lists.xensource.com X-Mailman-Version: 2.1.5 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xensource.com Errors-To: xen-devel-bounces@lists.xensource.com On Wed, Sep 14, 2011 at 07:44:14AM -0700, Fantu wrote: > We have dom0 Squeeze with official kernel (2.6.32-35squeeze2) and xen > 4.0.2-rc3 from git testing on DELL poweredge T310 with raid controller H200 > (all with latest firmware). > Some domus linux pv and some windows with gplpv. > We randomly running into this error during xendomains stop command (with > save of all domus): Whoa. that is impressive. Try booting your dom0 with swiotlb=128768 or some other large number. > > Sep 14 16:18:40 heliMN02WV kernel: [ 912.336945] mpt2sas 0000:03:00.0: DMA: > Out of SW-IOMMU space for 65536 bytes. > Sep 14 16:18:40 heliMN02WV kernel: [ 912.336951] sd 0:1:0:0: pci_map_sg > failed: request for 524288 bytes! > Sep 14 16:18:41 heliMN02WV kernel: [ 912.400331] mpt2sas 0000:03:00.0: DMA: > Out of SW-IOMMU space for 65536 bytes. > Sep 14 16:18:41 heliMN02WV kernel: [ 912.400336] sd 0:1:0:0: pci_map_sg > failed: request for 524288 bytes! > Sep 14 16:18:45 heliMN02WV kernel: [ 917.187524] mpt2sas 0000:03:00.0: DMA: > Out of SW-IOMMU space for 65536 bytes. > Sep 14 16:18:45 heliMN02WV kernel: [ 917.187533] sd 0:1:0:0: pci_map_sg > failed: request for 524288 bytes! > Sep 14 16:18:51 heliMN02WV kernel: [ 922.454599] mpt2sas 0000:03:00.0: DMA: > Out of SW-IOMMU space for 65536 bytes. > Sep 14 16:18:51 heliMN02WV kernel: [ 922.454608] sd 0:1:0:0: pci_map_sg > failed: request for 524288 bytes! > Sep 14 16:18:51 heliMN02WV kernel: [ 922.454694] mpt2sas 0000:03:00.0: DMA: > Out of SW-IOMMU space for 65536 bytes. > Sep 14 16:18:51 heliMN02WV kernel: [ 922.454697] sd 0:1:0:0: pci_map_sg > failed: request for 524288 bytes! > Sep 14 16:19:11 heliMN02WV kernel: [ 942.850048] frontend_changed: > backend/vbd/4/768: prepare for reconnect > Sep 14 16:19:11 heliMN02WV kernel: [ 942.869244] eth0: port 5(vif4.0) > entering disabled state > Sep 14 16:19:11 heliMN02WV kernel: [ 942.889192] eth0: port 5(vif4.0) > entering disabled state > Sep 14 16:19:11 heliMN02WV kernel: [ 943.188048] frontend_changed: > backend/vif/4/0: prepare for reconnect > Sep 14 16:19:22 heliMN02WV kernel: [ 954.246090] mpt2sas 0000:03:00.0: DMA: > Out of SW-IOMMU space for 65536 bytes. > Sep 14 16:19:22 heliMN02WV kernel: [ 954.246095] sd 0:1:0:0: pci_map_sg > failed: request for 524288 bytes! > Sep 14 16:19:22 heliMN02WV kernel: [ 954.305068] mpt2sas 0000:03:00.0: DMA: > Out of SW-IOMMU space for 65536 bytes. > Sep 14 16:19:22 heliMN02WV kernel: [ 954.305074] sd 0:1:0:0: pci_map_sg > failed: request for 524288 bytes! > Sep 14 16:19:34 heliMN02WV kernel: [ 966.112058] mpt2sas 0000:03:00.0: DMA: > Out of SW-IOMMU space for 65536 bytes. > Sep 14 16:19:34 heliMN02WV kernel: [ 966.112064] sd 0:1:0:0: pci_map_sg > failed: request for 524288 bytes! > Sep 14 16:19:34 heliMN02WV kernel: [ 966.112251] mpt2sas 0000:03:00.0: DMA: > Out of SW-IOMMU space for 65536 bytes. > Sep 14 16:19:34 heliMN02WV kernel: [ 966.112255] sd 0:1:0:0: pci_map_sg > failed: request for 524288 bytes! > Sep 14 16:19:34 heliMN02WV kernel: [ 966.112440] mpt2sas 0000:03:00.0: DMA: > Out of SW-IOMMU space for 65536 bytes. > Sep 14 16:19:34 heliMN02WV kernel: [ 966.112443] sd 0:1:0:0: pci_map_sg > failed: request for 524288 bytes! > Sep 14 16:19:34 heliMN02WV kernel: [ 966.205690] mpt2sas 0000:03:00.0: DMA: > Out of SW-IOMMU space for 65536 bytes. > Sep 14 16:19:34 heliMN02WV kernel: [ 966.205693] sd 0:1:0:0: pci_map_sg > failed: request for 524288 bytes! > Sep 14 16:19:40 heliMN02WV kernel: [ 971.728913] eth0: port 6(vif5.0) > entering disabled state > Sep 14 16:19:40 heliMN02WV kernel: [ 971.752683] eth0: port 6(vif5.0) > entering disabled state > Sep 14 16:19:45 heliMN02WV kernel: [ 976.984329] mpt2sas 0000:03:00.0: DMA: > Out of SW-IOMMU space for 65536 bytes. > Sep 14 16:19:45 heliMN02WV kernel: [ 976.984333] sd 0:1:0:0: pci_map_sg > failed: request for 524288 bytes! > Sep 14 16:19:49 heliMN02WV kernel: [ 981.288632] eth0: port 7(vif6.0) > entering disabled state > Sep 14 16:19:49 heliMN02WV kernel: [ 981.304521] eth0: port 7(vif6.0) > entering disabled state > Sep 14 16:19:50 heliMN02WV kernel: [ 982.329740] frontend_changed: > backend/vbd/7/768: prepare for reconnect > Sep 14 16:19:50 heliMN02WV kernel: [ 982.372593] eth0: port 8(vif7.0) > entering disabled state > Sep 14 16:19:51 heliMN02WV kernel: [ 982.416506] eth0: port 8(vif7.0) > entering disabled state > Sep 14 16:19:51 heliMN02WV kernel: [ 982.744206] frontend_changed: > backend/vif/7/0: prepare for reconnect > Sep 14 16:20:00 heliMN02WV kernel: [ 991.520780] mpt2sas 0000:03:00.0: DMA: > Out of SW-IOMMU space for 65536 bytes. > Sep 14 16:20:00 heliMN02WV kernel: [ 991.520787] sd 0:1:0:0: pci_map_sg > failed: request for 524288 bytes! > Sep 14 16:20:00 heliMN02WV kernel: [ 991.524695] mpt2sas 0000:03:00.0: DMA: > Out of SW-IOMMU space for 65536 bytes. > Sep 14 16:20:00 heliMN02WV kernel: [ 991.524698] sd 0:1:0:0: pci_map_sg > failed: request for 524288 bytes! > Sep 14 16:20:00 heliMN02WV kernel: [ 991.525040] mpt2sas 0000:03:00.0: DMA: > Out of SW-IOMMU space for 65536 bytes. > Sep 14 16:20:00 heliMN02WV kernel: [ 991.525042] sd 0:1:0:0: pci_map_sg > failed: request for 524288 bytes! > Sep 14 16:20:00 heliMN02WV kernel: [ 991.525371] mpt2sas 0000:03:00.0: DMA: > Out of SW-IOMMU space for 65536 bytes. > Sep 14 16:20:00 heliMN02WV kernel: [ 991.525374] sd 0:1:0:0: pci_map_sg > failed: request for 524288 bytes! > Sep 14 16:20:00 heliMN02WV kernel: [ 991.527766] mpt2sas 0000:03:00.0: DMA: > Out of SW-IOMMU space for 65536 bytes. > Sep 14 16:20:00 heliMN02WV kernel: [ 991.527769] sd 0:1:0:0: pci_map_sg > failed: request for 524288 bytes! > Sep 14 16:20:01 heliMN02WV kernel: [ 992.493163] mpt2sas 0000:03:00.0: DMA: > Out of SW-IOMMU space for 65536 bytes. > Sep 14 16:20:01 heliMN02WV kernel: [ 992.493167] sd 0:1:0:0: pci_map_sg > failed: request for 524288 bytes! > Sep 14 16:20:13 heliMN02WV kernel: [ 1004.938378] tapdisk2[7617]: segfault > at 7fff92fb6ff8 ip 0000000000408296 sp 00007fff92fb7000 error 6 in > tapdisk2[400000+39000] > Sep 14 16:20:13 heliMN02WV kernel: [ 1004.959533] BUG: unable to handle > kernel NULL pointer dereference at 0000000000000048 > Sep 14 16:20:13 heliMN02WV kernel: [ 1004.959681] IP: [] > apply_to_page_range+0x47/0x2f3 > Sep 14 16:20:13 heliMN02WV kernel: [ 1004.959773] PGD 3dc5f067 PUD 3db57067 > PMD 0 > Sep 14 16:20:13 heliMN02WV kernel: [ 1004.959914] Oops: 0000 [#1] SMP > Sep 14 16:20:13 heliMN02WV kernel: [ 1004.960026] last sysfs file: > /sys/devices/virtual/blktap2/blktap11/remove > Sep 14 16:20:13 heliMN02WV kernel: [ 1004.960084] CPU 5 > Sep 14 16:20:13 heliMN02WV kernel: [ 1004.960161] Modules linked in: > xt_tcpudp tun xt_physdev iptable_filter ip_tables x_tables bridge stp > ib_iser rdma_cm ib_cm iw_cm ib_sa ib_mad ib_core ib_addr iscsi_tcp > libiscsi_tcp libiscsi scsi_transport_iscsi ext2 sha256_generic aes_x86_64 > aes_generic cbc blktap xen_evtchn xenfs loop dm_crypt dcdbas snd_pcm > snd_timer snd joydev evdev soundcore snd_page_alloc pcspkr power_meter > button processor acpi_processor ext4 mbcache jbd2 crc16 dm_mod sd_mod > crc_t10dif sg usbhid hid sr_mod cdrom usb_storage ata_generic ehci_hcd > ata_piix mpt2sas bnx2 scsi_transport_sas libata usbcore nls_base scsi_mod > thermal thermal_sys [last unloaded: scsi_wait_scan] > Sep 14 16:20:13 heliMN02WV kernel: [ 1004.962493] Pid: 7617, comm: tapdisk2 > Not tainted 2.6.32-5-xen-amd64 #1 PowerEdge T310 > Sep 14 16:20:13 heliMN02WV kernel: [ 1004.962566] RIP: > e030:[] [] > apply_to_page_range+0x47/0x2f3 > Sep 14 16:20:13 heliMN02WV kernel: [ 1004.962671] RSP: e02b:ffff88003dfc9b58 > EFLAGS: 00010202 > Sep 14 16:20:13 heliMN02WV kernel: [ 1004.962726] RAX: 0000000000000880 RBX: > ffff88003d8ad000 RCX: ffff88003d8ae000 > Sep 14 16:20:13 heliMN02WV kernel: [ 1004.962783] RDX: 0000000000000000 RSI: > ffff88003d8ad000 RDI: 0000000000000000 > Sep 14 16:20:13 heliMN02WV kernel: [ 1004.962840] RBP: ffff88003eff2dd0 R08: > 0000000000000000 R09: ffff88003f96c180 > Sep 14 16:20:13 heliMN02WV kernel: [ 1004.962898] R10: 0000000000000002 R11: > 0000000000000000 R12: 0000000000000000 > Sep 14 16:20:13 heliMN02WV kernel: [ 1004.962955] R13: ffff88003eff2dd0 R14: > ffff88003e149000 R15: 0000000000000000 > Sep 14 16:20:13 heliMN02WV kernel: [ 1004.963014] FS: > 00007f6d3c738740(0000) GS:ffff880003782000(0000) knlGS:0000000000000000 > Sep 14 16:20:13 heliMN02WV kernel: [ 1004.963088] CS: e033 DS: 0000 ES: > 0000 CR0: 000000008005003b > Sep 14 16:20:13 heliMN02WV kernel: [ 1004.963143] CR2: 0000000000000048 CR3: > 000000003f0dc000 CR4: 0000000000002660 > Sep 14 16:20:13 heliMN02WV kernel: [ 1004.963201] DR0: 0000000000000000 DR1: > 0000000000000000 DR2: 0000000000000000 > Sep 14 16:20:13 heliMN02WV kernel: [ 1004.963258] DR3: 0000000000000000 DR6: > 00000000ffff0ff0 DR7: 0000000000000400 > Sep 14 16:20:13 heliMN02WV kernel: [ 1004.963316] Process tapdisk2 (pid: > 7617, threadinfo ffff88003dfc8000, task ffff880036a88e20) > Sep 14 16:20:13 heliMN02WV kernel: [ 1004.963389] Stack: > Sep 14 16:20:13 heliMN02WV kernel: [ 1004.963437] 0000000000000000 > ffff88003ea87b40 0000000000000000 0000000000000000 > Sep 14 16:20:13 heliMN02WV kernel: [ 1004.963583] <0> ffffffffa02f1ee8 > 0000000000000000 ffffffff8100ece2 ffff880002155480 > Sep 14 16:20:13 heliMN02WV kernel: [ 1004.963802] <0> ffff88003d8ae000 > 0000000000000000 0000000000000000 ffff880002155480 > Sep 14 16:20:13 heliMN02WV kernel: [ 1004.964066] Call Trace: > Sep 14 16:20:13 heliMN02WV kernel: [ 1004.964119] [] ? > blktap_umap_uaddr_fn+0x0/0x59 [blktap] > Sep 14 16:20:13 heliMN02WV kernel: [ 1004.964179] [] ? > check_events+0x12/0x20 > Sep 14 16:20:13 heliMN02WV kernel: [ 1004.964236] [] ? > blktap_device_end_request+0xbd/0x145 [blktap] > Sep 14 16:20:13 heliMN02WV kernel: [ 1004.964310] [] ? > blktap_ring_vm_close+0x60/0xd1 [blktap] > Sep 14 16:20:13 heliMN02WV kernel: [ 1004.964368] [] ? > remove_vma+0x2c/0x72 > Sep 14 16:20:13 heliMN02WV kernel: [ 1004.964423] [] ? > exit_mmap+0x129/0x148 > Sep 14 16:20:13 heliMN02WV kernel: [ 1004.964479] [] ? > mmput+0x3c/0xdf > Sep 14 16:20:13 heliMN02WV kernel: [ 1004.964534] [] ? > exit_mm+0x102/0x10d > Sep 14 16:20:13 heliMN02WV kernel: [ 1004.964592] [] ? > _spin_lock_irq+0x7/0x22 > Sep 14 16:20:13 heliMN02WV kernel: [ 1004.964648] [] ? > do_exit+0x1f8/0x6c6 > Sep 14 16:20:13 heliMN02WV kernel: [ 1004.964703] [] ? > __dequeue_signal+0xfb/0x124 > Sep 14 16:20:13 heliMN02WV kernel: [ 1004.964760] [] ? > xen_restore_fl_direct_end+0x0/0x1 > Sep 14 16:20:13 heliMN02WV kernel: [ 1004.964817] [] ? > kmem_cache_free+0x72/0xa3 > Sep 14 16:20:13 heliMN02WV kernel: [ 1004.964874] [] ? > do_group_exit+0x76/0x9d > Sep 14 16:20:13 heliMN02WV kernel: [ 1004.964930] [] ? > get_signal_to_deliver+0x310/0x339 > Sep 14 16:20:13 heliMN02WV kernel: [ 1004.964987] [] ? > do_notify_resume+0x87/0x73f > Sep 14 16:20:13 heliMN02WV kernel: [ 1004.965044] [] ? > expand_downwards+0x5b/0x169 > Sep 14 16:20:13 heliMN02WV kernel: [ 1004.965101] [] ? > do_page_fault+0x1f3/0x2f2 > Sep 14 16:20:13 heliMN02WV kernel: [ 1004.965157] [] ? > retint_signal+0x48/0x8c > Sep 14 16:20:13 heliMN02WV kernel: [ 1004.965211] Code: 48 89 4c 24 20 4c 89 > 44 24 18 48 89 54 24 40 72 04 0f 0b eb fe 48 8b 54 24 28 48 89 f0 48 8b 4c > 24 40 48 c1 e8 24 25 f8 0f 00 00 <48> 8b 52 48 48 ff c9 48 89 0c 24 48 01 d0 > 48 89 44 24 30 48 b8 > Sep 14 16:20:13 heliMN02WV kernel: [ 1004.967243] RIP [] > apply_to_page_range+0x47/0x2f3 > Sep 14 16:20:13 heliMN02WV kernel: [ 1004.967336] RSP > Sep 14 16:20:13 heliMN02WV kernel: [ 1004.967388] CR2: 0000000000000048 > Sep 14 16:20:13 heliMN02WV kernel: [ 1004.967440] ---[ end trace > 78b5f16c10850a91 ]--- > Sep 14 16:20:13 heliMN02WV kernel: [ 1004.967495] Fixing recursive fault but > reboot is needed! > > > Rebooting the systems doesn't resolve this problem. > We have also try to add swiotlb=128 on vmlinuz line but the systems always > loops with "out sw-iommu space" message (probably also bug in swiotlb switch > on kernel). > Can someone help us to solve this problem please? > > > -- > View this message in context: http://xen.1045712.n5.nabble.com/Out-sw-iommu-space-problem-tp4803078p4803078.html > Sent from the Xen - Dev mailing list archive at Nabble.com. > > _______________________________________________ > Xen-devel mailing list > Xen-devel@lists.xensource.com > http://lists.xensource.com/xen-devel _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel From xen-devel-bounces@lists.xensource.com Wed Sep 14 08:04:16 2011 Return-path: Envelope-to: www-data@lists.xensource.com Delivery-date: Wed, 14 Sep 2011 08:04:16 -0700 Received: from localhost ([127.0.0.1] helo=lists.colo.xensource.com) by lists.xensource.com with esmtp (Exim 4.43) id 1R3r0Z-0005M7-Sn; Wed, 14 Sep 2011 08:04:16 -0700 Received: from mail21.messagelabs.com ([85.158.143.35]) by lists.xensource.com with smtp (Exim 4.43) id 1R3qyY-00056N-90 for xen-devel@lists.xensource.com; Wed, 14 Sep 2011 08:02:11 -0700 X-Env-Sender: avi@redhat.com X-Msg-Ref: server-14.tower-21.messagelabs.com!1316012518!59578339!1 X-Originating-IP: [209.132.183.28] X-StarScan-Version: 6.4.1; banners=-,-,- X-VirusChecked: Checked Received: (qmail 14287 invoked from network); 14 Sep 2011 15:01:58 -0000 Received: from mx1.redhat.com (HELO mx1.redhat.com) (209.132.183.28) by server-14.tower-21.messagelabs.com with SMTP; 14 Sep 2011 15:01:58 -0000 Received: from int-mx01.intmail.prod.int.phx2.redhat.com (int-mx01.intmail.prod.int.phx2.redhat.com [10.5.11.11]) by mx1.redhat.com (8.14.4/8.14.4) with ESMTP id p8EF1N2r028741 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Wed, 14 Sep 2011 11:01:23 -0400 Received: from balrog.usersys.redhat.com (dhcp-1-24.tlv.redhat.com [10.35.1.24]) by int-mx01.intmail.prod.int.phx2.redhat.com (8.13.8/8.13.8) with ESMTP id p8EF1If8032285; Wed, 14 Sep 2011 11:01:19 -0400 Message-ID: <4E70C1BE.7060209@redhat.com> Date: Wed, 14 Sep 2011 18:01:18 +0300 From: Avi Kivity User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:6.0) Gecko/20110816 Thunderbird/6.0 MIME-Version: 1.0 To: Andi Kleen References: <20110907134411.GV5795@redhat.com> <4E678992.5050709@redhat.com> <20110907155657.GX5795@redhat.com> <4E679AF4.50209@redhat.com> <20110907165203.GQ6838@redhat.com> <4E67A551.4000502@redhat.com> <20110913184044.GN5795@redhat.com> <20110913190320.GR7761@one.firstfloor.org> <20110913192152.GO5795@redhat.com> <4E7050F7.3000208@redhat.com> <20110914144926.GU7761@one.firstfloor.org> In-Reply-To: <20110914144926.GU7761@one.firstfloor.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Scanned-By: MIMEDefang 2.67 on 10.5.11.11 Cc: Don Zickus , Jeremy Fitzhardinge , Marcelo Tosatti , Nick Piggin , KVM , Stefano Stabellini , Peter Zijlstra , the arch/x86 maintainers , Linux Kernel Mailing List , Xen Devel , Jeremy Fitzhardinge , "H. Peter Anvin" , Ingo Molnar , Linus Torvalds Subject: [Xen-devel] Re: [PATCH 08/13] xen/pvticketlock: disable interrupts while blocking X-BeenThere: xen-devel@lists.xensource.com X-Mailman-Version: 2.1.5 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xensource.com Errors-To: xen-devel-bounces@lists.xensource.com On 09/14/2011 05:49 PM, Andi Kleen wrote: > On Wed, Sep 14, 2011 at 10:00:07AM +0300, Avi Kivity wrote: > > On 09/13/2011 10:21 PM, Don Zickus wrote: > > >Or are you saying an NMI in an idle system will have the same %rip thus > > >falsely detecting a back-to-back NMI? > > > > > > > > > > That's easy to avoid - insert an instruction zeroing the last nmi_rip > > somewhere before or after hlt. It's always okay to execute such an > > instruction (outside the nmi handler itself), since nmi_rip is meant to > > detect a "no instructions executed" condition. > > At least for classic hlt there is no simple "after hlt" because it's all > interrupt handlers and exceptions and everything else that can interrupt > combined. If an NMI hits in an interrupt handler, or in the "after hlt" section before the write-to-last-nmi-rip, then we'll see that %rip has changed. If it hits after the write-to-last-nmi-rip instruction (or in the hlt itself), then we'll also see that %rip has changed, due to the effect of that instruction. -- error compiling committee.c: too many arguments to function _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel From xen-devel-bounces@lists.xensource.com Wed Sep 14 08:06:33 2011 Return-path: Envelope-to: www-data@lists.xensource.com Delivery-date: Wed, 14 Sep 2011 08:06:33 -0700 Received: from localhost ([127.0.0.1] helo=lists.colo.xensource.com) by lists.xensource.com with esmtp (Exim 4.43) id 1R3r2n-0005kK-Dh; Wed, 14 Sep 2011 08:06:33 -0700 Received: from mail174.messagelabs.com ([85.158.138.51]) by lists.xensource.com with esmtp (Exim 4.43) id 1R3qyc-00056Z-1L for xen-devel@lists.xensource.com; Wed, 14 Sep 2011 08:02:15 -0700 X-Env-Sender: royger@gmail.com X-Msg-Ref: server-4.tower-174.messagelabs.com!1316012526!31433650!1 X-Originating-IP: [74.125.83.43] X-StarScan-Version: 6.4.1; banners=-,-,- X-VirusChecked: Checked Received: (qmail 4347 invoked from network); 14 Sep 2011 15:02:08 -0000 Received: from mail-gw0-f43.google.com (HELO mail-gw0-f43.google.com) (74.125.83.43) by server-4.tower-174.messagelabs.com with RC4-SHA encrypted SMTP; 14 Sep 2011 15:02:08 -0000 Received: by gwm11 with SMTP id 11so1882152gwm.30 for ; Wed, 14 Sep 2011 08:02:05 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type; bh=yCAP40dO5e8PVr7S78NJ2XBkkKvUQXT54ywFT43+C5o=; b=GRLkvDk/EGMe0aGrEOcEODunc7vK8eefNC6ytKxuByLaod5TPNNACQxq+38+6Xv76T 5+TMZ/vkDJTOpA6JVHYb1dBZ+0fGwNqrOLV/yzl3cETS3aHOqibk3DKpsGSlpFwu43ur w/vY/X+8+iqj8uzV90c71JUdwypTnCDwUofK0= MIME-Version: 1.0 Received: by 10.68.60.3 with SMTP id d3mr140120pbr.80.1316012525602; Wed, 14 Sep 2011 08:02:05 -0700 (PDT) Received: by 10.142.211.4 with HTTP; Wed, 14 Sep 2011 08:02:05 -0700 (PDT) In-Reply-To: <4E70B0D7.5040906@amd.com> References: <63e254468d6e8d81baea.1316002763@loki> <4E70B0D7.5040906@amd.com> Date: Wed, 14 Sep 2011 17:02:05 +0200 X-Google-Sender-Auth: CfZ-hswmbdB6_Y7ju965nVIWkAA Message-ID: Subject: Re: [Xen-devel] [PATCH] libxl: create pci backend only when there are pci devices From: =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= To: Christoph Egger Content-Type: text/plain; charset=UTF-8 Cc: "xen-devel@lists.xensource.com" X-BeenThere: xen-devel@lists.xensource.com X-Mailman-Version: 2.1.5 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xensource.com Errors-To: xen-devel-bounces@lists.xensource.com This was commited as a part of another patch, and I've decided to submit it alone. This solves a problem with NetBSD Dom0 and at least Linux DomU, the DomU kernel waited a very long time at XENBUS init, because it was unable to attach the PCI devices (although there were no PCI devices, only an empty pci entry in xenstore). This prevents libxl from adding the pci entries to xenstore if there are no PCI devices and solves the problem. I don't have any Linux boxes, but I think this should not break anything. If the patch is correct, please add it to xen-4.1 too. Regards, Roger. _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel From xen-devel-bounces@lists.xensource.com Wed Sep 14 08:07:58 2011 Return-path: Envelope-to: www-data@lists.xensource.com Delivery-date: Wed, 14 Sep 2011 08:07:58 -0700 Received: from localhost ([127.0.0.1] helo=lists.colo.xensource.com) by lists.xensource.com with esmtp (Exim 4.43) id 1R3r4A-00068x-PL; Wed, 14 Sep 2011 08:07:58 -0700 Received: from mail27.messagelabs.com ([193.109.254.147]) by lists.xensource.com with esmtp (Exim 4.43) id 1R3r34-0005pc-CL for xen-devel@lists.xensource.com; Wed, 14 Sep 2011 08:06:51 -0700 X-Env-Sender: konrad@oracle.com X-Msg-Ref: server-6.tower-27.messagelabs.com!1316012787!48961289!1 X-Originating-IP: [141.146.126.227] X-StarScan-Version: 6.4.1; banners=-,-,- X-VirusChecked: Checked Received: (qmail 30442 invoked from network); 14 Sep 2011 15:06:28 -0000 Received: from acsinet15.oracle.com (HELO acsinet15.oracle.com) (141.146.126.227) by server-6.tower-27.messagelabs.com with DHE-RSA-AES256-SHA encrypted SMTP; 14 Sep 2011 15:06:28 -0000 Received: from acsinet22.oracle.com (acsinet22.oracle.com [141.146.126.238]) by acsinet15.oracle.com (Switch-3.4.4/Switch-3.4.4) with ESMTP id p8EF6gO9019491 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Wed, 14 Sep 2011 15:06:44 GMT Received: from acsmt356.oracle.com (acsmt356.oracle.com [141.146.40.156]) by acsinet22.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id p8EF6fGR009601 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 14 Sep 2011 15:06:42 GMT Received: from abhmt104.oracle.com (abhmt104.oracle.com [141.146.116.56]) by acsmt356.oracle.com (8.12.11.20060308/8.12.11) with ESMTP id p8EF6ZOF020524; Wed, 14 Sep 2011 10:06:36 -0500 Received: from oracle.com (/209.6.55.207) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Wed, 14 Sep 2011 08:06:35 -0700 Received: by oracle.com (Postfix, from userid 1000) id 14D231362; Wed, 14 Sep 2011 11:06:36 -0400 (EDT) Date: Wed, 14 Sep 2011 11:06:36 -0400 From: Konrad Rzeszutek Wilk To: Nathan March Subject: Re: [Xen-devel] Several issues with Xen 4.1.1 regarding Windows guests (and more...) Message-ID: <20110914150635.GA18147@phenom.oracle.com> References: <1315951748.7224.5.camel@kali.ninth-art.net> <4E6FE3CB.30209@gt.net> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <4E6FE3CB.30209@gt.net> User-Agent: Mutt/1.5.21 (2010-09-15) X-Source-IP: acsinet22.oracle.com [141.146.126.238] X-Auth-Type: Internal IP X-CT-RefId: str=0001.0A090203.4E70C304.0155:SCFMA922111,ss=1,re=-4.000,fgs=0 Cc: xen-devel@lists.xensource.com, therion@ninth-art.de X-BeenThere: xen-devel@lists.xensource.com X-Mailman-Version: 2.1.5 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xensource.com Errors-To: xen-devel-bounces@lists.xensource.com On Tue, Sep 13, 2011 at 04:14:19PM -0700, Nathan March wrote: > > > On 9/13/2011 3:09 PM, Georg Bege wrote: > >Hello > > > >Im experiencing serveral issues right now, Im not well Xen experienced - > >I tried it first in '06 and staid off from it since last week. > > > >b) I managed to install Windows XP fine, however the performance (I/O in > >general) is quite poor compared to VirtualBox. > Can't comment on the rest, but have you installed the gplpv drivers? > > http://www.meadowcourt.org/downloads/ > > The wiki has some details but is quite out of date: > http://wiki.xensource.com/xenwiki/XenWindowsGplPv > > On win2008 I install the OS, do a "bcedit /set testsigning on", > reboot, then install the gplpv. Or you can installed the signed versions: http://marc.info/?i=201109090950.05043.muehlenhoff@univention.de _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel From xen-devel-bounces@lists.xensource.com Wed Sep 14 08:09:22 2011 Return-path: Envelope-to: www-data@lists.xensource.com Delivery-date: Wed, 14 Sep 2011 08:09:22 -0700 Received: from localhost ([127.0.0.1] helo=lists.colo.xensource.com) by lists.xensource.com with esmtp (Exim 4.43) id 1R3r5W-0006Wt-RP; Wed, 14 Sep 2011 08:09:22 -0700 Received: from mail27.messagelabs.com ([193.109.254.147]) by lists.xensource.com with esmtp (Exim 4.43) id 1R3r3o-0005zn-7W for xen-devel@lists.xensource.com; Wed, 14 Sep 2011 08:07:36 -0700 X-Env-Sender: konrad@oracle.com X-Msg-Ref: server-2.tower-27.messagelabs.com!1316012828!54951267!1 X-Originating-IP: [148.87.113.117] X-StarScan-Version: 6.4.1; banners=-,-,- X-VirusChecked: Checked Received: (qmail 28481 invoked from network); 14 Sep 2011 15:07:09 -0000 Received: from rcsinet15.oracle.com (HELO rcsinet15.oracle.com) (148.87.113.117) by server-2.tower-27.messagelabs.com with DHE-RSA-AES256-SHA encrypted SMTP; 14 Sep 2011 15:07:09 -0000 Received: from rtcsinet22.oracle.com (rtcsinet22.oracle.com [66.248.204.30]) by rcsinet15.oracle.com (Switch-3.4.4/Switch-3.4.4) with ESMTP id p8EF7RhJ021795 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Wed, 14 Sep 2011 15:07:29 GMT Received: from acsmt358.oracle.com (acsmt358.oracle.com [141.146.40.158]) by rtcsinet22.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id p8EF7QYX001404 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 14 Sep 2011 15:07:27 GMT Received: from abhmt116.oracle.com (abhmt116.oracle.com [141.146.116.68]) by acsmt358.oracle.com (8.12.11.20060308/8.12.11) with ESMTP id p8EF7K8A002715; Wed, 14 Sep 2011 10:07:21 -0500 Received: from oracle.com (/209.6.55.207) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Wed, 14 Sep 2011 08:07:20 -0700 Received: by oracle.com (Postfix, from userid 1000) id 3D4D51362; Wed, 14 Sep 2011 11:07:21 -0400 (EDT) Date: Wed, 14 Sep 2011 11:07:21 -0400 From: Konrad Rzeszutek Wilk To: David Vrabel Subject: Re: [Xen-devel] Use xenbus API for mapping foreign pages Message-ID: <20110914150721.GA18248@phenom.oracle.com> References: <1315911922-4855-1-git-send-email-david.vrabel@citrix.com> <4E70BD31.1090105@citrix.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <4E70BD31.1090105@citrix.com> User-Agent: Mutt/1.5.21 (2010-09-15) X-Source-IP: rtcsinet22.oracle.com [66.248.204.30] X-CT-RefId: str=0001.0A090206.4E70C332.0057,ss=1,re=0.000,fgs=0 Cc: xen-devel@lists.xensource.com X-BeenThere: xen-devel@lists.xensource.com X-Mailman-Version: 2.1.5 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xensource.com Errors-To: xen-devel-bounces@lists.xensource.com On Wed, Sep 14, 2011 at 03:41:53PM +0100, David Vrabel wrote: > On 13/09/11 12:05, David Vrabel wrote: > >Xenbus provides an API for mapping foreign pages. Make use of it in > >the netback and blkback drivers so when the method for mapping foreign > >pages is changed it only need to be updated in one place.ak > > Don't apply these. I've taken a different approach that obsoletes > xenbus_map_ring_valloc() and xenbus_map_ring_vfree(). Ok. _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel From xen-devel-bounces@lists.xensource.com Wed Sep 14 08:10:19 2011 Return-path: Envelope-to: www-data@lists.xensource.com Delivery-date: Wed, 14 Sep 2011 08:10:19 -0700 Received: from localhost ([127.0.0.1] helo=lists.colo.xensource.com) by lists.xensource.com with esmtp (Exim 4.43) id 1R3r6R-0006tl-ET; Wed, 14 Sep 2011 08:10:19 -0700 Received: from mail174.messagelabs.com ([85.158.138.51]) by lists.xensource.com with esmtp (Exim 4.43) id 1R3r5x-0006ge-Gy for xen-devel@lists.xensource.com; Wed, 14 Sep 2011 08:09:50 -0700 X-Env-Sender: adi@cg.tuwien.ac.at X-Msg-Ref: server-8.tower-174.messagelabs.com!1316012982!17738407!1 X-Originating-IP: [213.129.229.198] X-StarScan-Version: 6.4.1; banners=-,-,- X-VirusChecked: Checked Received: (qmail 29331 invoked from network); 14 Sep 2011 15:09:44 -0000 Received: from vrvis-198.vrvis.at (HELO iris.vrvis.at) (213.129.229.198) by server-8.tower-174.messagelabs.com with AES256-SHA encrypted SMTP; 14 Sep 2011 15:09:44 -0000 Received: from actoris.vrvis.lan ([10.42.1.75] helo=vrvis.at) by iris.vrvis.at with esmtpsa (TLS1.0:DHE_RSA_AES_128_CBC_SHA1:16) (Exim 4.72) (envelope-from ) id 1R3r5i-0002oJ-AR; Wed, 14 Sep 2011 17:09:34 +0200 Date: Wed, 14 Sep 2011 17:09:34 +0200 From: Adi Kriegisch To: Konrad Rzeszutek Wilk Message-ID: <20110914150934.GK3079@vrvis.at> References: <20110914081156.GB3079@vrvis.at> <20110914102112.GB15866@phenom.oracle.com> <20110914112718.GG3079@vrvis.at> <20110914142854.GB16956@phenom.oracle.com> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline In-Reply-To: <20110914142854.GB16956@phenom.oracle.com> User-Agent: Mutt/1.5.20 (2009-06-14) X-SA-Exim-Connect-IP: 10.42.1.75 X-SA-Exim-Mail-From: adi@cg.tuwien.ac.at X-SA-Exim-Scanned: No (on iris.vrvis.at); SAEximRunCond expanded to false Cc: xen-devel@lists.xensource.com, Adi Kriegisch Subject: [Xen-devel] Re: Dom0 ACPI S3 patches X-BeenThere: xen-devel@lists.xensource.com X-Mailman-Version: 2.1.5 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xensource.com Errors-To: xen-devel-bounces@lists.xensource.com On Wed, Sep 14, 2011 at 10:28:54AM -0400, Konrad Rzeszutek Wilk wrote: > > > Excellent. Is it OK if I put 'Tested-by: Adi Kriegish" on them? > > Sure, go ahead! ;-) > > Update: No, the system just crashed while writing this mail after about 4 days > > of uptime with many suspend-resume cycles in between... *sigh* :-( > > Hmmm.. I wonder if you are hitting the writecombine issue I've seen sometimes. > Just to eliminate it, can you try 'nopat' on the Linux command line? Sure. Do you know any way to make sure I am hitting the writecombine issue fast, so that I can make (kind of) sure everything is working? > > > You know, I don't know. I just never thought about that - um. I wonder > > > if it is related to the RTC update patch that I've been meaning > > > to take a look at: > > > > > > http://lists.xensource.com/archives/html/xen-devel/2010-02/msg00469.html > > Sounds like it could be related. Shall I apply that patch? If so, which > > hook takes care that the function is called? > > It kind of automatically hooks up. If you can apply it cleanly - sure. But it > might not apply cleanly :-( It does not apply at all: first hunk fails because there have been some other includes added. second hunk fails because there is no more "#endif /* CONFIG_PARAVIRT_CLOCK_VSYSCALL */"... and this is the point where I can't fix a bug because I do not know enough of the kernel/xen internals to know what to touch... -- Adi _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel From xen-devel-bounces@lists.xensource.com Wed Sep 14 08:17:04 2011 Return-path: Envelope-to: www-data@lists.xensource.com Delivery-date: Wed, 14 Sep 2011 08:17:04 -0700 Received: from localhost ([127.0.0.1] helo=lists.colo.xensource.com) by lists.xensource.com with esmtp (Exim 4.43) id 1R3rCy-0007LL-Jk; Wed, 14 Sep 2011 08:17:04 -0700 Received: from mail21.messagelabs.com ([85.158.143.35]) by lists.xensource.com with smtp (Exim 4.43) id 1R3rCY-00078j-9Y for xen-devel@lists.xensource.com; Wed, 14 Sep 2011 08:16:38 -0700 X-Env-Sender: jwcart2@tycho.nsa.gov X-Msg-Ref: server-2.tower-21.messagelabs.com!1316013393!34094099!1 X-Originating-IP: [63.239.65.39] X-StarScan-Version: 6.4.1; banners=-,-,- X-VirusChecked: Checked Received: (qmail 15238 invoked from network); 14 Sep 2011 15:16:34 -0000 Received: from msux-gh1-uea01.nsa.gov (HELO msux-gh1-uea01.nsa.gov) (63.239.65.39) by server-2.tower-21.messagelabs.com with SMTP; 14 Sep 2011 15:16:34 -0000 Received: from tarius.tycho.ncsc.mil (localhost [127.0.0.1]) by msux-gh1-uea01.nsa.gov (8.12.10/8.12.10) with ESMTP id p8EFGYNx002795; Wed, 14 Sep 2011 15:16:34 GMT Received: from [144.51.25.4] (moss-lions [144.51.25.4]) by tarius.tycho.ncsc.mil (8.13.1/8.13.1) with ESMTP id p8EFGXOO020171; Wed, 14 Sep 2011 11:16:33 -0400 Subject: [Xen-devel][PATCH] xen/xsm: Compile error due to naming clash between XSM and EFI runtime From: James Carter To: Jan Beulich Date: Wed, 14 Sep 2011 11:15:09 -0400 Organization: National Security Agency Content-Type: text/plain; charset="UTF-8" X-Mailer: Evolution 3.0.3 (3.0.3-1.fc15) Content-Transfer-Encoding: 8bit Message-ID: <1316013309.30974.8.camel@moss-lions.epoch.ncsc.mil> Mime-Version: 1.0 Cc: xen-devel@lists.xensource.com X-BeenThere: xen-devel@lists.xensource.com X-Mailman-Version: 2.1.5 Precedence: list Reply-To: jwcart2@tycho.nsa.gov List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xensource.com Errors-To: xen-devel-bounces@lists.xensource.com While compiling XEN with XSM_ENABLE=y and FLASK_ENABLE=y, I received the following error. gcc -O1 -fno-omit-frame-pointer -m64 -g -fno-strict-aliasing -std=gnu99 -Wall -Wstrict-prototypes -Wno-unused-value -Wdeclaration-after-statement -Wno-unused-but-set-variable -fno-builtin -fno-common -Wredundant-decls -iwithprefix include -Werror -Wno-pointer-arith -pipe -I/home/jwcart2/src/xen/my-xen-unstable/xen/include -I/home/jwcart2/src/xen/my-xen-unstable/xen/include/asm-x86/mach-generic -I/home/jwcart2/src/xen/my-xen-unstable/xen/include/asm-x86/mach-default -msoft-float -fno-stack-protector -fno-exceptions -Wnested-externs -mno-red-zone -fpic -fno-asynchronous-unwind-tables -DGCC_HAS_VISIBILITY_ATTRIBUTE -fno-optimize-sibling-calls -nostdinc -g -D__XEN__ -DXSM_ENABLE -DFLASK_ENABLE -DXSM_MAGIC=0xf97cff8c -DFLASK_DEVELOP -DFLASK_BOOTPARAM -DFLASK_AVC_STATS -DVERBOSE -fno-omit-frame-pointer -DCONFIG_FRAME_POINTER -MMD -MF .platform_hypercall.o.d -c platform_hypercall.c -o platform_hypercall.o In file included from ../platform_hypercall.c:33:0, from platform_hypercall.c:38: /home/jwcart2/src/xen/my-xen-unstable/xen/include/xsm/xsm.h: In function ‘xsm_efi_runtime_call’: /home/jwcart2/src/xen/my-xen-unstable/xen/include/xsm/xsm.h:559:19: error: ‘struct xsm_operations’ has no member named ‘efi_compat_runtime_call’ cc1: warnings being treated as errors /home/jwcart2/src/xen/my-xen-unstable/xen/include/xsm/xsm.h:560:1: error: control reaches end of non-void function make[5]: *** [platform_hypercall.o] Error 1 make[5]: Leaving directory `/home/jwcart2/src/xen/my-xen-unstable/xen/arch/x86/x86_64' make[4]: *** [x86_64/built_in.o] Error 2 The problem is that efi_runtime_call is the name of both a function in xen/arch/x86/efi/runtime.c and a member of the xsm_operations struct in xen/include/xsm/xsm.h. This causes the macro "#define efi_runtime_call(x) efi_compat_runtime_call(x)" on line 15 of xen/arch/x86/x86_64/platform_hypercall.c to cause the above compile error. (At least, that is what I think is happening.) Renaming the XSM struct member fixes the problem. Signed-off-by: James Carter --- arch/x86/platform_hypercall.c | 2 +- include/xsm/xsm.h | 6 +++--- 2 files changed, 4 insertions(+), 4 deletions(-) diff -r 0312575dc35e xen/arch/x86/platform_hypercall.c --- a/xen/arch/x86/platform_hypercall.c Thu Sep 08 15:13:06 2011 +0100 +++ b/xen/arch/x86/platform_hypercall.c Wed Sep 14 09:48:25 2011 -0400 @@ -306,7 +306,7 @@ break; case XENPF_efi_runtime_call: - ret = xsm_efi_runtime_call(); + ret = xsm_efi_call(); if ( ret ) break; diff -r 0312575dc35e xen/include/xsm/xsm.h --- a/xen/include/xsm/xsm.h Thu Sep 08 15:13:06 2011 +0100 +++ b/xen/include/xsm/xsm.h Wed Sep 14 09:48:25 2011 -0400 @@ -132,7 +132,7 @@ int (*physinfo) (void); int (*platform_quirk) (uint32_t); int (*firmware_info) (void); - int (*efi_runtime_call) (void); + int (*efi_call) (void); int (*acpi_sleep) (void); int (*change_freq) (void); int (*getidletime) (void); @@ -554,9 +554,9 @@ return xsm_call(firmware_info()); } -static inline int xsm_efi_runtime_call (void) +static inline int xsm_efi_call (void) { - return xsm_call(efi_runtime_call()); + return xsm_call(efi_call()); } static inline int xsm_acpi_sleep (void) -- James Carter National Security Agency _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel From xen-devel-bounces@lists.xensource.com Wed Sep 14 08:33:07 2011 Return-path: Envelope-to: www-data@lists.xensource.com Delivery-date: Wed, 14 Sep 2011 08:33:07 -0700 Received: from localhost ([127.0.0.1] helo=lists.colo.xensource.com) by lists.xensource.com with esmtp (Exim 4.43) id 1R3rSV-0000tE-4F; Wed, 14 Sep 2011 08:33:07 -0700 Received: from mail216.messagelabs.com ([85.158.143.99]) by lists.xensource.com with esmtp (Exim 4.43) id 1R3rRx-0000fi-L8 for xen-devel@lists.xensource.com; Wed, 14 Sep 2011 08:32:33 -0700 X-Env-Sender: JBeulich@suse.com X-Msg-Ref: server-12.tower-216.messagelabs.com!1316014350!12530101!1 X-Originating-IP: [130.57.49.28] X-StarScan-Version: 6.4.1; banners=-,-,- X-VirusChecked: Checked Received: (qmail 21471 invoked from network); 14 Sep 2011 15:32:30 -0000 Received: from nat28.tlf.novell.com (HELO nat28.tlf.novell.com) (130.57.49.28) by server-12.tower-216.messagelabs.com with DHE-RSA-AES256-SHA encrypted SMTP; 14 Sep 2011 15:32:30 -0000 Received: from EMEA1-MTA by nat28.tlf.novell.com with Novell_GroupWise; Wed, 14 Sep 2011 16:32:30 +0100 Message-Id: <4E70E52C0200007800056193@nat28.tlf.novell.com> X-Mailer: Novell GroupWise Internet Agent 8.0.1 Date: Wed, 14 Sep 2011 16:32:28 +0100 From: "Jan Beulich" To: ,"Keir Fraser" Subject: Re: [Xen-devel][PATCH] xen/xsm: Compile error due to naming clash between XSM and EFI runtime References: <1316013309.30974.8.camel@moss-lions.epoch.ncsc.mil> In-Reply-To: <1316013309.30974.8.camel@moss-lions.epoch.ncsc.mil> Mime-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit Content-Disposition: inline Cc: xen-devel@lists.xensource.com X-BeenThere: xen-devel@lists.xensource.com X-Mailman-Version: 2.1.5 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xensource.com Errors-To: xen-devel-bounces@lists.xensource.com >>> On 14.09.11 at 17:15, James Carter wrote: > While compiling XEN with XSM_ENABLE=y and FLASK_ENABLE=y, I received the > following error. > > gcc -O1 -fno-omit-frame-pointer -m64 -g -fno-strict-aliasing -std=gnu99 > -Wall -Wstrict-prototypes -Wno-unused-value -Wdeclaration-after-statement > -Wno-unused-but-set-variable -fno-builtin -fno-common -Wredundant-decls > -iwithprefix include -Werror -Wno-pointer-arith -pipe > -I/home/jwcart2/src/xen/my-xen-unstable/xen/include > -I/home/jwcart2/src/xen/my-xen-unstable/xen/include/asm-x86/mach-generic > -I/home/jwcart2/src/xen/my-xen-unstable/xen/include/asm-x86/mach-default > -msoft-float -fno-stack-protector -fno-exceptions -Wnested-externs > -mno-red-zone -fpic -fno-asynchronous-unwind-tables > -DGCC_HAS_VISIBILITY_ATTRIBUTE -fno-optimize-sibling-calls -nostdinc -g > -D__XEN__ -DXSM_ENABLE -DFLASK_ENABLE -DXSM_MAGIC=0xf97cff8c -DFLASK_DEVELOP > -DFLASK_BOOTPARAM -DFLASK_AVC_STATS -DVERBOSE -fno-omit-frame-pointer > -DCONFIG_FRAME_POINTER -MMD -MF .platform_hypercall.o.d -c > platform_hypercall.c -o platform_hypercall.o > In file included from ../platform_hypercall.c:33:0, > from platform_hypercall.c:38: > /home/jwcart2/src/xen/my-xen-unstable/xen/include/xsm/xsm.h: In function > ‘xsm_efi_runtime_call’: > /home/jwcart2/src/xen/my-xen-unstable/xen/include/xsm/xsm.h:559:19: error: > ‘struct xsm_operations’ has no member named ‘efi_compat_runtime_call’ > cc1: warnings being treated as errors > /home/jwcart2/src/xen/my-xen-unstable/xen/include/xsm/xsm.h:560:1: error: > control reaches end of non-void function > make[5]: *** [platform_hypercall.o] Error 1 > make[5]: Leaving directory > `/home/jwcart2/src/xen/my-xen-unstable/xen/arch/x86/x86_64' > make[4]: *** [x86_64/built_in.o] Error 2 > > > The problem is that efi_runtime_call is the name of both a function in > xen/arch/x86/efi/runtime.c and a member of the xsm_operations struct in > xen/include/xsm/xsm.h. This causes the macro "#define > efi_runtime_call(x) efi_compat_runtime_call(x)" on line 15 of > xen/arch/x86/x86_64/platform_hypercall.c to cause the above compile > error. (At least, that is what I think is happening.) > > Renaming the XSM struct member fixes the problem. > > Signed-off-by: James Carter Acked-by: Jan Beulich > --- > > arch/x86/platform_hypercall.c | 2 +- > include/xsm/xsm.h | 6 +++--- > 2 files changed, 4 insertions(+), 4 deletions(-) > > diff -r 0312575dc35e xen/arch/x86/platform_hypercall.c > --- a/xen/arch/x86/platform_hypercall.c Thu Sep 08 15:13:06 2011 +0100 > +++ b/xen/arch/x86/platform_hypercall.c Wed Sep 14 09:48:25 2011 -0400 > @@ -306,7 +306,7 @@ > break; > > case XENPF_efi_runtime_call: > - ret = xsm_efi_runtime_call(); > + ret = xsm_efi_call(); > if ( ret ) > break; > > diff -r 0312575dc35e xen/include/xsm/xsm.h > --- a/xen/include/xsm/xsm.h Thu Sep 08 15:13:06 2011 +0100 > +++ b/xen/include/xsm/xsm.h Wed Sep 14 09:48:25 2011 -0400 > @@ -132,7 +132,7 @@ > int (*physinfo) (void); > int (*platform_quirk) (uint32_t); > int (*firmware_info) (void); > - int (*efi_runtime_call) (void); > + int (*efi_call) (void); > int (*acpi_sleep) (void); > int (*change_freq) (void); > int (*getidletime) (void); > @@ -554,9 +554,9 @@ > return xsm_call(firmware_info()); > } > > -static inline int xsm_efi_runtime_call (void) > +static inline int xsm_efi_call (void) > { > - return xsm_call(efi_runtime_call()); > + return xsm_call(efi_call()); > } > > static inline int xsm_acpi_sleep (void) > > > -- > James Carter > National Security Agency _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel From xen-devel-bounces@lists.xensource.com Wed Sep 14 08:48:29 2011 Return-path: Envelope-to: www-data@lists.xensource.com Delivery-date: Wed, 14 Sep 2011 08:48:29 -0700 Received: from localhost ([127.0.0.1] helo=lists.colo.xensource.com) by lists.xensource.com with esmtp (Exim 4.43) id 1R3rhN-0002Rv-GL; Wed, 14 Sep 2011 08:48:29 -0700 Received: from mail174.messagelabs.com ([85.158.138.51]) by lists.xensource.com with esmtp (Exim 4.43) id 1R3rgk-0002Dr-0p for xen-devel@lists.xensource.com; Wed, 14 Sep 2011 08:47:50 -0700 X-Env-Sender: konrad@oracle.com X-Msg-Ref: server-12.tower-174.messagelabs.com!1316015262!31411659!1 X-Originating-IP: [141.146.126.227] X-StarScan-Version: 6.4.1; banners=-,-,- X-VirusChecked: Checked Received: (qmail 27492 invoked from network); 14 Sep 2011 15:47:46 -0000 Received: from acsinet15.oracle.com (HELO acsinet15.oracle.com) (141.146.126.227) by server-12.tower-174.messagelabs.com with DHE-RSA-AES256-SHA encrypted SMTP; 14 Sep 2011 15:47:46 -0000 Received: from acsinet21.oracle.com (acsinet21.oracle.com [141.146.126.237]) by acsinet15.oracle.com (Switch-3.4.4/Switch-3.4.4) with ESMTP id p8EFlWgi008952 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Wed, 14 Sep 2011 15:47:34 GMT Received: from acsmt356.oracle.com (acsmt356.oracle.com [141.146.40.156]) by acsinet21.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id p8EFlV9E029798 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 14 Sep 2011 15:47:32 GMT Received: from abhmt105.oracle.com (abhmt105.oracle.com [141.146.116.57]) by acsmt356.oracle.com (8.12.11.20060308/8.12.11) with ESMTP id p8EFlQNq025540; Wed, 14 Sep 2011 10:47:26 -0500 Received: from oracle.com (/209.6.55.207) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Wed, 14 Sep 2011 08:47:25 -0700 Received: by oracle.com (Postfix, from userid 1000) id 6CFE91362; Wed, 14 Sep 2011 11:47:26 -0400 (EDT) Date: Wed, 14 Sep 2011 11:47:26 -0400 From: Konrad Rzeszutek Wilk To: Adi Kriegisch Subject: Re: [Xen-devel] Re: Dom0 ACPI S3 patches Message-ID: <20110914154726.GA18810@phenom.oracle.com> References: <20110914081156.GB3079@vrvis.at> <20110914102112.GB15866@phenom.oracle.com> <20110914112718.GG3079@vrvis.at> <20110914142854.GB16956@phenom.oracle.com> <20110914150934.GK3079@vrvis.at> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20110914150934.GK3079@vrvis.at> User-Agent: Mutt/1.5.21 (2010-09-15) X-Source-IP: acsinet21.oracle.com [141.146.126.237] X-Auth-Type: Internal IP X-CT-RefId: str=0001.0A090204.4E70CC96.00BC:SCFMA922111,ss=1,re=-4.000,fgs=0 Cc: xen-devel@lists.xensource.com X-BeenThere: xen-devel@lists.xensource.com X-Mailman-Version: 2.1.5 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xensource.com Errors-To: xen-devel-bounces@lists.xensource.com On Wed, Sep 14, 2011 at 05:09:34PM +0200, Adi Kriegisch wrote: > On Wed, Sep 14, 2011 at 10:28:54AM -0400, Konrad Rzeszutek Wilk wrote: > > > > Excellent. Is it OK if I put 'Tested-by: Adi Kriegish" on them? > > > Sure, go ahead! ;-) > > > Update: No, the system just crashed while writing this mail after about 4 days > > > of uptime with many suspend-resume cycles in between... *sigh* :-( > > > > Hmmm.. I wonder if you are hitting the writecombine issue I've seen sometimes. > > Just to eliminate it, can you try 'nopat' on the Linux command line? > Sure. Do you know any way to make sure I am hitting the writecombine issue > fast, so that I can make (kind of) sure everything is working? Mysterious applications crashing left and right. Under my box bash stopped working right and such. Pretty obvious that something went wrong. > > > > > You know, I don't know. I just never thought about that - um. I wonder > > > > if it is related to the RTC update patch that I've been meaning > > > > to take a look at: > > > > > > > > http://lists.xensource.com/archives/html/xen-devel/2010-02/msg00469.html > > > Sounds like it could be related. Shall I apply that patch? If so, which > > > hook takes care that the function is called? > > > > It kind of automatically hooks up. If you can apply it cleanly - sure. But it > > might not apply cleanly :-( > It does not apply at all: Pfff.. well, I will try to rebase it in a couple of days. Can you ping in a week if I haven't sent anything to you yet? > first hunk fails because there have been some other includes added. > second hunk fails because there is no more > "#endif /* CONFIG_PARAVIRT_CLOCK_VSYSCALL */"... and this is the point > where I can't fix a bug because I do not know enough of the kernel/xen > internals to know what to touch... > > -- Adi > > _______________________________________________ > Xen-devel mailing list > Xen-devel@lists.xensource.com > http://lists.xensource.com/xen-devel _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel From xen-devel-bounces@lists.xensource.com Wed Sep 14 09:05:11 2011 Return-path: Envelope-to: www-data@lists.xensource.com Delivery-date: Wed, 14 Sep 2011 09:05:11 -0700 Received: from localhost ([127.0.0.1] helo=lists.colo.xensource.com) by lists.xensource.com with esmtp (Exim 4.43) id 1R3rxW-0003DF-UX; Wed, 14 Sep 2011 09:05:10 -0700 Received: from mail21.messagelabs.com ([85.158.143.35]) by lists.xensource.com with smtp (Exim 4.43) id 1R3rvm-0002zS-H5 for xen-devel@lists.xensource.com; Wed, 14 Sep 2011 09:03:27 -0700 X-Env-Sender: tobias.geiger@vido.info X-Msg-Ref: server-9.tower-21.messagelabs.com!1316016155!48417727!1 X-Originating-IP: [78.47.43.171] X-StarScan-Version: 6.4.1; banners=-,-,- X-VirusChecked: Checked Received: (qmail 6996 invoked from network); 14 Sep 2011 16:02:35 -0000 Received: from www.vido.info (HELO mail.vido.info) (78.47.43.171) by server-9.tower-21.messagelabs.com with SMTP; 14 Sep 2011 16:02:35 -0000 Received: from localhost (ip6-localhost [127.0.0.1]) by mail.vido.info (Postfix) with ESMTP id 1689DD348A7 for ; Wed, 14 Sep 2011 18:03:19 +0200 (CEST) X-Virus-Scanned: by amavis at mail.vido.info Received: from mail.vido.info ([127.0.0.1]) by localhost (mail.vido.info [127.0.0.1]) (amavisd-new, port 10024) with LMTP id muW8lhLnoCGK for ; Wed, 14 Sep 2011 18:03:07 +0200 (CEST) Received: from lxgeigert.localnet (et-1-10.gw-nat.bs.kae.de.oneandone.net [212.227.35.74]) by mail.vido.info (Postfix) with ESMTPSA id 38FECD34107 for ; Wed, 14 Sep 2011 18:03:07 +0200 (CEST) From: Tobias Geiger Organization: VIDO IT-Service To: xen-devel@lists.xensource.com Subject: Re: [Xen-devel] Signed GPLPV drivers available for download Date: Wed, 14 Sep 2011 18:03:04 +0200 User-Agent: KMail/1.13.7 (Linux/2.6.39-2-amd64; KDE/4.6.5; x86_64; ; ) References: <201109090950.05043.muehlenhoff@univention.de> In-Reply-To: <201109090950.05043.muehlenhoff@univention.de> MIME-Version: 1.0 Content-Type: Text/Plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Message-Id: <201109141803.04514.tobias.geiger@vido.info> X-BeenThere: xen-devel@lists.xensource.com X-Mailman-Version: 2.1.5 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xensource.com Errors-To: xen-devel-bounces@lists.xensource.com i have very strange effects as soon as i install the GPLPV drivers under=20 windows7 (64bit): =2D no network connection as soon as anything which accesses the graphiccar= d in=20 3d mode is started; thats what buffles me most... i can't really tell you m= ore=20 than that, its really that strange (first i thought of a virus or something= =20 like that, but i was able to circle it down to the gplpv drivers,..) this also happens with non-signed gplpv drivers, and also with a version pr= ior=20 to 308 (was it 238?) =2D really better read-performance WITH gplpv, but much worse write-perform= ance: here is the performance without gplpv: http://img238.imagevenue.com/img.php?image=3D15846_HDTune_File_Benchmark_QE= MU_HARDDISK_VOR_signedGPLPV_122_354lo.jpg here WITH gplpv: http://img278.imagevenue.com/img.php?image=3D15846_HDTune_File_Benchmark_XE= N____PV_DISK________NACH_gplpv_SIGNED_122_530lo.jpg Greetings Tobias Am Freitag, 9. September 2011, 09:50:04 schrieb Moritz M=FChlenhoff: > Hi, > for inclusion in Univention Corporate Server - a Linux distribution based > on Debian targeted towards enterprise environments, which also includes > Xen for virtualisation - we're now building/signing the excellent GPLPV > drivers written by James Harper with a Software Publishers Certificate > obtained from GlobalSign. [1] >=20 > This allows installation of the GPLPV drivers on 64 bit Windows without t= he > need to enable the test mode. >=20 > The drivers are available from > http://apt.univention.de/download/addons/gplpv- drivers/ and should be > compatible with any Xen installation. >=20 > The installation is detailed in > http://wiki.univention.de/index.php?title=3DInstalling-signed-GPLPV-drive= rs >=20 > So far only new installation of the GPLPV drivers have been tested. We > welcome general feedback and experiences with upgrades from test-signed > versions of GPLPV. >=20 > Cheers, > Moritz >=20 > Footnotes: > [1] We're well aware of the recent claims of a potential compromise of th= at > CA, but as of today this is still under investigation: > http://www.globalsign.com/company/press/090611-security-response.html _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel From xen-devel-bounces@lists.xensource.com Wed Sep 14 09:11:02 2011 Return-path: Envelope-to: www-data@lists.xensource.com Delivery-date: Wed, 14 Sep 2011 09:11:02 -0700 Received: from localhost ([127.0.0.1] helo=lists.colo.xensource.com) by lists.xensource.com with esmtp (Exim 4.43) id 1R3s3C-0003ef-KQ; Wed, 14 Sep 2011 09:11:02 -0700 Received: from mail21.messagelabs.com ([85.158.143.35]) by lists.xensource.com with smtp (Exim 4.43) id 1R3s2W-0003S2-Jv for xen-devel@lists.xensource.com; Wed, 14 Sep 2011 09:10:21 -0700 X-Env-Sender: tobias.geiger@vido.info X-Msg-Ref: server-8.tower-21.messagelabs.com!1316016602!58977261!1 X-Originating-IP: [78.47.43.171] X-StarScan-Version: 6.4.1; banners=-,-,- X-VirusChecked: Checked Received: (qmail 9831 invoked from network); 14 Sep 2011 16:10:02 -0000 Received: from www.vido.info (HELO mail.vido.info) (78.47.43.171) by server-8.tower-21.messagelabs.com with SMTP; 14 Sep 2011 16:10:02 -0000 Received: from localhost (ip6-localhost [127.0.0.1]) by mail.vido.info (Postfix) with ESMTP id 653DED348A6; Wed, 14 Sep 2011 18:10:17 +0200 (CEST) X-Virus-Scanned: by amavis at mail.vido.info Received: from mail.vido.info ([127.0.0.1]) by localhost (mail.vido.info [127.0.0.1]) (amavisd-new, port 10024) with LMTP id X7RBubOVICsc; Wed, 14 Sep 2011 18:10:07 +0200 (CEST) Received: from lxgeigert.localnet (et-1-10.gw-nat.bs.kae.de.oneandone.net [212.227.35.74]) by mail.vido.info (Postfix) with ESMTPSA id E47D4D34107; Wed, 14 Sep 2011 18:10:06 +0200 (CEST) From: Tobias Geiger Organization: VIDO IT-Service To: xen-devel@lists.xensource.com Subject: Re: [Xen-devel] Re: Patches for VGA-Passthrough XEN 4.2 unstable Date: Wed, 14 Sep 2011 18:10:05 +0200 User-Agent: KMail/1.13.7 (Linux/2.6.39-2-amd64; KDE/4.6.5; x86_64; ; ) References: <201109121450.39331.tobias.geiger@vido.info> In-Reply-To: MIME-Version: 1.0 Content-Type: Text/Plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Message-Id: <201109141810.05762.tobias.geiger@vido.info> Cc: Liwei X-BeenThere: xen-devel@lists.xensource.com X-Mailman-Version: 2.1.5 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xensource.com Errors-To: xen-devel-bounces@lists.xensource.com Am Montag, 12. September 2011, 14:59:46 schrieb Liwei: > Actually I'm living with it currently. Disabled automatic reboots and > manually reboot the system at a convenient time. It'll be sweet to fix > it, but I just don't have the time now. yep, same here. this helps, but sometimes it' be really helpful to be able to reboot domu without having to reboot dom0 also... > > I do know that reboots with VGA/PCI passthrough worked at one point in > the past with older kernel and xen versions, but something in the new > versions have broken that. So if you really need to and have the time, > try testing older (I think it was sometime in March or April) > versions. that depends on what you mean with "reboot worked": the best i had (with earlier xen patchset, thats correct) was that the rebooted windows domu was worked perfect except for the passed-through 3d card: after the reboot the performance was lousy, whyever but it never raised its memory clock, and so was stuck in the lowest performance mode. with current patchset of xen it the rebooted domu crashes as soon as the gfx card is accessed, i.e. when the login-screen of windows appears... so a permanent yes-rebooting-domu-is-fine fix is really appreciated here ;) Greetings Tobias _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel From xen-devel-bounces@lists.xensource.com Wed Sep 14 09:15:10 2011 Return-path: Envelope-to: www-data@lists.xensource.com Delivery-date: Wed, 14 Sep 2011 09:15:10 -0700 Received: from localhost ([127.0.0.1] helo=lists.colo.xensource.com) by lists.xensource.com with esmtp (Exim 4.43) id 1R3s7C-00043q-Na; Wed, 14 Sep 2011 09:15:10 -0700 Received: from mail27.messagelabs.com ([193.109.254.147]) by lists.xensource.com with smtp (Exim 4.43) id 1R3s6k-0003rJ-4e for xen-devel@lists.xensource.com; Wed, 14 Sep 2011 09:14:42 -0700 X-Env-Sender: tobias.geiger@vido.info X-Msg-Ref: server-7.tower-27.messagelabs.com!1316016857!48658061!1 X-Originating-IP: [78.47.43.171] X-StarScan-Version: 6.4.1; banners=-,-,- X-VirusChecked: Checked Received: (qmail 20295 invoked from network); 14 Sep 2011 16:14:17 -0000 Received: from www.vido.info (HELO mail.vido.info) (78.47.43.171) by server-7.tower-27.messagelabs.com with SMTP; 14 Sep 2011 16:14:17 -0000 Received: from localhost (ip6-localhost [127.0.0.1]) by mail.vido.info (Postfix) with ESMTP id B9B3FD348A6 for ; Wed, 14 Sep 2011 18:14:38 +0200 (CEST) X-Virus-Scanned: by amavis at mail.vido.info Received: from mail.vido.info ([127.0.0.1]) by localhost (mail.vido.info [127.0.0.1]) (amavisd-new, port 10024) with LMTP id eZSrL4Gq+whF for ; Wed, 14 Sep 2011 18:14:30 +0200 (CEST) Received: from lxgeigert.localnet (et-1-10.gw-nat.bs.kae.de.oneandone.net [212.227.35.74]) by mail.vido.info (Postfix) with ESMTPSA id 559B6D34107 for ; Wed, 14 Sep 2011 18:14:30 +0200 (CEST) From: Tobias Geiger Organization: VIDO IT-Service To: xen-devel@lists.xensource.com Subject: Re: [Xen-devel] Signed GPLPV drivers available for download Date: Wed, 14 Sep 2011 18:14:28 +0200 User-Agent: KMail/1.13.7 (Linux/2.6.39-2-amd64; KDE/4.6.5; x86_64; ; ) References: <201109090950.05043.muehlenhoff@univention.de> <201109141803.04514.tobias.geiger@vido.info> In-Reply-To: <201109141803.04514.tobias.geiger@vido.info> MIME-Version: 1.0 Content-Type: Text/Plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Message-Id: <201109141814.29461.tobias.geiger@vido.info> X-BeenThere: xen-devel@lists.xensource.com X-Mailman-Version: 2.1.5 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xensource.com Errors-To: xen-devel-bounces@lists.xensource.com Am Mittwoch, 14. September 2011, 18:03:04 schrieb Tobias Geiger: > - really better read-performance WITH gplpv, but much worse > write-performance: here is the performance without gplpv: well, after reviewing my own screenshots i declare even the readperformance gets worse after installing GPLPV drivers, not only the writeperformance... Any hints on that ?! i remember this not being the case with windows xp iirc... Greetings Tobias _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel From xen-devel-bounces@lists.xensource.com Wed Sep 14 10:29:35 2011 Return-path: Envelope-to: www-data@lists.xensource.com Delivery-date: Wed, 14 Sep 2011 10:29:35 -0700 Received: from localhost ([127.0.0.1] helo=lists.colo.xensource.com) by lists.xensource.com with esmtp (Exim 4.43) id 1R3tHB-000702-Ct; Wed, 14 Sep 2011 10:29:34 -0700 Received: from mail27.messagelabs.com ([193.109.254.147]) by lists.xensource.com with esmtp (Exim 4.43) id 1R3tGM-0006nF-Gt for xen-devel@lists.xensource.com; Wed, 14 Sep 2011 10:28:42 -0700 X-Env-Sender: andi@firstfloor.org X-Msg-Ref: server-8.tower-27.messagelabs.com!1316021303!46610674!1 X-Originating-IP: [213.235.205.2] X-StarScan-Version: 6.4.1; banners=-,-,- X-VirusChecked: Checked Received: (qmail 9923 invoked from network); 14 Sep 2011 17:28:24 -0000 Received: from one.firstfloor.org (HELO one.firstfloor.org) (213.235.205.2) by server-8.tower-27.messagelabs.com with DHE-RSA-AES256-SHA encrypted SMTP; 14 Sep 2011 17:28:24 -0000 Received: by one.firstfloor.org (Postfix, from userid 503) id AC8901ED80B6; Wed, 14 Sep 2011 19:28:38 +0200 (CEST) Date: Wed, 14 Sep 2011 19:28:38 +0200 From: Andi Kleen To: Avi Kivity Message-ID: <20110914172838.GV7761@one.firstfloor.org> References: <20110907155657.GX5795@redhat.com> <4E679AF4.50209@redhat.com> <20110907165203.GQ6838@redhat.com> <4E67A551.4000502@redhat.com> <20110913184044.GN5795@redhat.com> <20110913190320.GR7761@one.firstfloor.org> <20110913192152.GO5795@redhat.com> <4E7050F7.3000208@redhat.com> <20110914144926.GU7761@one.firstfloor.org> <4E70C1BE.7060209@redhat.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <4E70C1BE.7060209@redhat.com> User-Agent: Mutt/1.4.2.2i Cc: Don Zickus , Jeremy Fitzhardinge , Marcelo Tosatti , Nick Piggin , KVM , Stefano Stabellini , Peter Zijlstra , the arch/x86 maintainers , Linux Kernel Mailing List , Andi Kleen , Jeremy Fitzhardinge , "H. Peter Anvin" , Ingo Molnar , Linus Torvalds , Xen Devel Subject: [Xen-devel] Re: [PATCH 08/13] xen/pvticketlock: disable interrupts while blocking X-BeenThere: xen-devel@lists.xensource.com X-Mailman-Version: 2.1.5 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xensource.com Errors-To: xen-devel-bounces@lists.xensource.com > If an NMI hits in an interrupt handler, or in the "after hlt" section > before the write-to-last-nmi-rip, then we'll see that %rip has changed. > If it hits after the write-to-last-nmi-rip instruction (or in the hlt > itself), then we'll also see that %rip has changed, due to the effect of > that instruction. It won't handle multiple NMIs in halt. I assume that's reasonable common. -Andi _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel From xen-devel-bounces@lists.xensource.com Wed Sep 14 10:50:35 2011 Return-path: Envelope-to: www-data@lists.xensource.com Delivery-date: Wed, 14 Sep 2011 10:50:35 -0700 Received: from localhost ([127.0.0.1] helo=lists.colo.xensource.com) by lists.xensource.com with esmtp (Exim 4.43) id 1R3tbX-0008P3-Cf; Wed, 14 Sep 2011 10:50:35 -0700 Received: from mail182.messagelabs.com ([85.158.139.83]) by lists.xensource.com with esmtp (Exim 4.43) id 1R3tam-0008C9-26 for xen-devel@lists.xensource.com; Wed, 14 Sep 2011 10:49:48 -0700 X-Env-Sender: Ian.Jackson@eu.citrix.com X-Msg-Ref: server-11.tower-182.messagelabs.com!1316022584!18357270!1 X-Originating-IP: [62.200.22.115] X-StarScan-Version: 6.4.1; banners=-,-,- X-VirusChecked: Checked Received: (qmail 21993 invoked from network); 14 Sep 2011 17:49:44 -0000 Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115) by server-11.tower-182.messagelabs.com with RC4-SHA encrypted SMTP; 14 Sep 2011 17:49:44 -0000 X-IronPort-AV: E=Sophos;i="4.68,381,1312156800"; d="scan'208";a="7819762" Received: from lonpmailmx01.citrite.net ([10.30.203.162]) by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5; 14 Sep 2011 17:49:35 +0000 Received: from woking.xci-test.com (10.80.248.135) by smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id 8.3.137.0; Wed, 14 Sep 2011 18:49:35 +0100 Received: from osstest by woking.xci-test.com with local (Exim 4.69) (envelope-from ) id 1R3taZ-0003jT-9n; Wed, 14 Sep 2011 18:49:35 +0100 To: Message-ID: From: xen.org Date: Wed, 14 Sep 2011 18:49:35 +0100 MIME-Version: 1.0 Content-Type: text/plain Cc: ian.jackson@eu.citrix.com Subject: [Xen-devel] [xen-unstable test] 8937: tolerable FAIL - PUSHED X-BeenThere: xen-devel@lists.xensource.com X-Mailman-Version: 2.1.5 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xensource.com Errors-To: xen-devel-bounces@lists.xensource.com flight 8937 xen-unstable real [real] http://www.chiark.greenend.org.uk/~xensrcts/logs/8937/ Failures :-/ but no regressions. Tests which did not succeed, but are not blocking, including regressions (tests previously passed) regarded as allowable: test-amd64-amd64-xl-pcipt-intel 1 xen-build-check(1) blocked n/a test-amd64-i386-rhel6hvm-intel 1 xen-build-check(1) blocked n/a test-i386-i386-pv 1 xen-build-check(1) blocked n/a test-amd64-i386-pv 1 xen-build-check(1) blocked n/a test-amd64-amd64-pv 1 xen-build-check(1) blocked n/a test-i386-i386-xl 1 xen-build-check(1) blocked n/a build-amd64-pvops 4 kernel-build fail like 8873 test-amd64-i386-xl 1 xen-build-check(1) blocked n/a test-amd64-i386-xl-credit2 1 xen-build-check(1) blocked n/a test-amd64-i386-rhel6hvm-amd 1 xen-build-check(1) blocked n/a test-amd64-amd64-pair 1 xen-build-check(1) blocked n/a test-amd64-i386-pair 1 xen-build-check(1) blocked n/a test-i386-i386-pair 1 xen-build-check(1) blocked n/a build-i386-pvops 4 kernel-build fail like 8873 test-amd64-i386-xl-multivcpu 1 xen-build-check(1) blocked n/a test-amd64-amd64-xl-sedf 1 xen-build-check(1) blocked n/a test-amd64-i386-win-vcpus1 1 xen-build-check(1) blocked n/a test-amd64-i386-xl-win-vcpus1 1 xen-build-check(1) blocked n/a test-amd64-amd64-win 1 xen-build-check(1) blocked n/a test-amd64-i386-win 1 xen-build-check(1) blocked n/a test-amd64-amd64-xl-win 1 xen-build-check(1) blocked n/a test-amd64-amd64-xl 1 xen-build-check(1) blocked n/a test-i386-i386-xl-win 1 xen-build-check(1) blocked n/a test-i386-i386-win 1 xen-build-check(1) blocked n/a version targeted for testing: xen e90438f6e6d1 baseline version: xen 0312575dc35e ------------------------------------------------------------ People who touched revisions under test: Andrew Cooper Benjamin Schweikert Christoph Egger George Dunlap Ian Campbell Ian Jackson Keir Fraser Olaf Hering Stefano Stabellini Tim Deegan ------------------------------------------------------------ jobs: build-amd64 pass build-i386 pass build-amd64-oldkern pass build-i386-oldkern pass build-amd64-pvops fail build-i386-pvops fail test-amd64-amd64-xl blocked test-amd64-i386-xl blocked test-i386-i386-xl blocked test-amd64-i386-rhel6hvm-amd blocked test-amd64-i386-xl-credit2 blocked test-amd64-amd64-xl-pcipt-intel blocked test-amd64-i386-rhel6hvm-intel blocked test-amd64-i386-xl-multivcpu blocked test-amd64-amd64-pair blocked test-amd64-i386-pair blocked test-i386-i386-pair blocked test-amd64-amd64-pv blocked test-amd64-i386-pv blocked test-i386-i386-pv blocked test-amd64-amd64-xl-sedf blocked test-amd64-i386-win-vcpus1 blocked test-amd64-i386-xl-win-vcpus1 blocked test-amd64-amd64-win blocked test-amd64-i386-win blocked test-i386-i386-win blocked test-amd64-amd64-xl-win blocked test-i386-i386-xl-win blocked ------------------------------------------------------------ sg-report-flight on woking.cam.xci-test.com logs: /home/xc_osstest/logs images: /home/xc_osstest/images Logs, config files, etc. are available at http://www.chiark.greenend.org.uk/~xensrcts/logs Test harness code can be found at http://xenbits.xensource.com/gitweb?p=osstest.git;a=summary Pushing revision : + branch=xen-unstable + revision=e90438f6e6d1 + . cri-lock-repos ++ . cri-common +++ umask 002 +++ getconfig Repos +++ perl -e ' use Osstest; readconfigonly(); print $c{Repos} or die $!; ' ++ repos=/export/home/osstest/repos ++ repos_lock=/export/home/osstest/repos/lock ++ '[' x '!=' x/export/home/osstest/repos/lock ']' ++ OSSTEST_REPOS_LOCK_LOCKED=/export/home/osstest/repos/lock ++ exec with-lock-ex -w /export/home/osstest/repos/lock ./ap-push xen-unstable e90438f6e6d1 + branch=xen-unstable + revision=e90438f6e6d1 + . cri-lock-repos ++ . cri-common +++ umask 002 +++ getconfig Repos +++ perl -e ' use Osstest; readconfigonly(); print $c{Repos} or die $!; ' ++ repos=/export/home/osstest/repos ++ repos_lock=/export/home/osstest/repos/lock ++ '[' x/export/home/osstest/repos/lock '!=' x/export/home/osstest/repos/lock ']' + : xen@xenbits.xensource.com + : xen@xenbits.xensource.com:git/linux-pvops + : master + : tested/2.6.39.x + case "$branch" in + cd /export/home/osstest/repos/xen-unstable.hg + hg push -r e90438f6e6d1 ssh://xen@xenbits.xensource.com/HG/xen-unstable.hg pushing to ssh://xen@xenbits.xensource.com/HG/xen-unstable.hg searching for changes remote: adding changesets remote: adding manifests remote: adding file changes remote: added 13 changesets with 32 changes to 16 files _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel From xen-devel-bounces@lists.xensource.com Wed Sep 14 10:54:28 2011 Return-path: Envelope-to: www-data@lists.xensource.com Delivery-date: Wed, 14 Sep 2011 10:54:28 -0700 Received: from localhost ([127.0.0.1] helo=lists.colo.xensource.com) by lists.xensource.com with esmtp (Exim 4.43) id 1R3tfI-0000OW-Ky; Wed, 14 Sep 2011 10:54:28 -0700 Received: from mail182.messagelabs.com ([85.158.139.83]) by lists.xensource.com with esmtp (Exim 4.43) id 1R3tej-0000BS-GT for xen-devel@lists.xensource.com; Wed, 14 Sep 2011 10:53:53 -0700 X-Env-Sender: rshriram@cs.ubc.ca X-Msg-Ref: server-8.tower-182.messagelabs.com!1316022828!18362221!1 X-Originating-IP: [142.103.6.52] X-StarScan-Version: 6.4.1; banners=-,-,- X-VirusChecked: Checked Received: (qmail 18108 invoked from network); 14 Sep 2011 17:53:50 -0000 Received: from smtp.cs.ubc.ca (HELO smtp.cs.ubc.ca) (142.103.6.52) by server-8.tower-182.messagelabs.com with DHE-RSA-AES256-SHA encrypted SMTP; 14 Sep 2011 17:53:50 -0000 Received: from mail-bw0-f43.google.com (mail-bw0-f43.google.com [209.85.214.43]) (authenticated bits=0) by smtp.cs.ubc.ca (8.14.3/8.13.6) with ESMTP id p8EHrj7w026532 (version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=FAIL) for ; Wed, 14 Sep 2011 10:53:47 -0700 Received: by bkas6 with SMTP id s6so2268064bka.30 for ; Wed, 14 Sep 2011 10:53:44 -0700 (PDT) Received: by 10.204.142.204 with SMTP id r12mr56447bku.388.1316022824129; Wed, 14 Sep 2011 10:53:44 -0700 (PDT) MIME-Version: 1.0 Received: by 10.204.123.19 with HTTP; Wed, 14 Sep 2011 10:53:04 -0700 (PDT) In-Reply-To: <4E6FC4A6.5040304@gt.net> References: <4E6FC4A6.5040304@gt.net> From: Shriram Rajagopalan Date: Wed, 14 Sep 2011 10:53:04 -0700 Message-ID: Subject: Re: [Xen-devel] Internal error during live migration saving To: Nathan March Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: xen-devel@lists.xensource.com X-BeenThere: xen-devel@lists.xensource.com X-Mailman-Version: 2.1.5 Precedence: list Reply-To: rshriram@cs.ubc.ca List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xensource.com Errors-To: xen-devel-bounces@lists.xensource.com On Tue, Sep 13, 2011 at 2:01 PM, Nathan March wrote: > Just wondering if this is a known bug? > > Trying to migrate the VM off to a diff dom0 results in the below error. > Other VMs migrated off fine (started at around the same time as this vm) = and > I've tried a few different target servers, all resulting in the same thin= g. > Were other domains linux 3.0.3 as well ? > [2011-09-13 13:48:24 3996] DEBUG (XendCheckpoint:124) [xc_save]: > /usr/lib/xen/bin/xc_save 29 77 0 0 1 > [2011-09-13 13:48:24 3996] INFO (XendCheckpoint:423) xc_save: failed to g= et > the suspend evtchn port > [2011-09-13 13:48:24 3996] INFO (XendCheckpoint:423) > [2011-09-13 13:49:03 3996] DEBUG (XendCheckpoint:394) suspend > [2011-09-13 13:49:03 3996] DEBUG (XendCheckpoint:127) In saveInputHandler > suspend > [2011-09-13 13:49:03 3996] DEBUG (XendCheckpoint:129) Suspending 77 ... > [2011-09-13 13:49:03 3996] DEBUG (XendDomainInfo:524) > XendDomainInfo.shutdown(suspend) > [2011-09-13 13:49:03 3996] DEBUG (XendDomainInfo:1881) > XendDomainInfo.handleShutdownWatch > [2011-09-13 13:50:06 3996] DEBUG (XendDomainInfo:1881) > XendDomainInfo.handleShutdownWatch > [2011-09-13 13:50:06 3996] INFO (XendCheckpoint:423) xc: error: Suspend > request failed: Internal error > [2011-09-13 13:50:06 3996] INFO (XendCheckpoint:423) xc: error: Domain > appears not to have suspended: Internal error > [2011-09-13 13:50:06 3996] ERROR (XendCheckpoint:185) Save failed on doma= in > globish (77) - resuming. > Traceback (most recent call last): > =A0File "/usr/lib64/python2.6/site-packages/xen/xend/XendCheckpoint.py", = line > 146, in save > =A0 =A0forkHelper(cmd, fd, saveInputHandler, False) > =A0File "/usr/lib64/python2.6/site-packages/xen/xend/XendCheckpoint.py", = line > 395, in forkHelper > =A0 =A0inputHandler(line, child.tochild) > =A0File "/usr/lib64/python2.6/site-packages/xen/xend/XendCheckpoint.py", = line > 131, in saveInputHandler > =A0 =A0dominfo.waitForSuspend() > =A0File "/usr/lib64/python2.6/site-packages/xen/xend/XendDomainInfo.py", = line > 2998, in waitForSuspend > =A0 =A0raise XendError(msg) > XendError: Timeout waiting for domain 77 to suspend > [2011-09-13 13:50:06 3996] DEBUG (XendDomainInfo:3135) > XendDomainInfo.resumeDomain(77) > > xend-debug.log and the target dom0 logs don't show anything of value. > > This is xen 4.1.1 on linux 3.0.3 > Did you try xm save -c (or the xl equivalent) ? This should be activating the same code path where this error seems to appear. Also, make sure you have CONFIG_XEN_SAVE_RESTORE enabled. > - Nathan > > -- > Nathan March > Gossamer Threads Inc. http://www.gossamer-threads.com/ > Tel: (604) 687-5804 Fax: (604) 687-5806 > > > _______________________________________________ > Xen-devel mailing list > Xen-devel@lists.xensource.com > http://lists.xensource.com/xen-devel > _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel From xen-devel-bounces@lists.xensource.com Wed Sep 14 10:55:52 2011 Return-path: Envelope-to: www-data@lists.xensource.com Delivery-date: Wed, 14 Sep 2011 10:55:52 -0700 Received: from localhost ([127.0.0.1] helo=lists.colo.xensource.com) by lists.xensource.com with esmtp (Exim 4.43) id 1R3tge-0000oo-DI; Wed, 14 Sep 2011 10:55:52 -0700 Received: from mail27.messagelabs.com ([193.109.254.147]) by lists.xensource.com with esmtp (Exim 4.43) id 1R3tfo-0000Y4-40 for xen-devel@lists.xensource.com; Wed, 14 Sep 2011 10:55:00 -0700 X-Env-Sender: jeremy@goop.org X-Msg-Ref: server-4.tower-27.messagelabs.com!1316022878!40274921!1 X-Originating-IP: [74.207.240.146] X-StarScan-Version: 6.4.1; banners=-,-,- X-VirusChecked: Checked Received: (qmail 23052 invoked from network); 14 Sep 2011 17:54:39 -0000 Received: from claw.goop.org (HELO claw.goop.org) (74.207.240.146) by server-4.tower-27.messagelabs.com with DHE-RSA-AES256-SHA encrypted SMTP; 14 Sep 2011 17:54:39 -0000 Received: from saboo.goop.org (unknown [IPv6:2001:470:1f05:899:7c1f:dff:fef3:fe46]) (Authenticated sender: smtp-saboo) by claw.goop.org (Postfix) with ESMTPSA id 6B8203A1; Wed, 14 Sep 2011 10:54:54 -0700 (PDT) Received: from saboo.goop.org (localhost [IPv6:::1]) by saboo.goop.org (Postfix) with ESMTP id 2139920499; Wed, 14 Sep 2011 10:44:12 -0700 (PDT) Message-ID: <4E70E7EC.4030809@goop.org> Date: Wed, 14 Sep 2011 10:44:12 -0700 From: Jeremy Fitzhardinge User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:6.0.2) Gecko/20110906 Thunderbird/6.0.2 MIME-Version: 1.0 To: Jan Beulich Subject: Re: [Xen-devel] Dom0 ACPI S3 patches References: <20110914081156.GB3079@vrvis.at> <4E7084C30200007800055FBE@nat28.tlf.novell.com> In-Reply-To: <4E7084C30200007800055FBE@nat28.tlf.novell.com> X-Enigmail-Version: 1.3.1 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: xen-devel@lists.xensource.com, Adi Kriegisch , Konrad Rzeszutek Wilk X-BeenThere: xen-devel@lists.xensource.com X-Mailman-Version: 2.1.5 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xensource.com Errors-To: xen-devel-bounces@lists.xensource.com On 09/14/2011 01:41 AM, Jan Beulich wrote: >>>> On 14.09.11 at 10:11, Adi Kriegisch wrote: >> * The DomUs do not resync their clock after Dom0 waking up. They're >> basically continue to count the time as if the sleep never happened. >> I have to run 'ntpdate' on resume on all the DomUs. I am not sure if >> there are any side effects of this; probably there is a more simple way >> to tell a DomU to reread clock from Dom0? > This is a more fundamental problem - upstream pv-ops doesn't make > use of XENFP_settime (or its bogus alias DOM_SETTIME) at all; only > Jeremy's 2.6.32.x tree has this so far. I was confused grepping for those: XEN*PF*_settime, or DOM*0*_SETTIME. Yeah, thanks for the reminder. I've queued that up for the next merge window. J _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel From xen-devel-bounces@lists.xensource.com Wed Sep 14 11:03:21 2011 Return-path: Envelope-to: www-data@lists.xensource.com Delivery-date: Wed, 14 Sep 2011 11:03:21 -0700 Received: from localhost ([127.0.0.1] helo=lists.colo.xensource.com) by lists.xensource.com with esmtp (Exim 4.43) id 1R3tns-00027f-KD; Wed, 14 Sep 2011 11:03:20 -0700 Received: from mail216.messagelabs.com ([85.158.143.99]) by lists.xensource.com with esmtp (Exim 4.43) id 1R3tjp-0001di-Ac for xen-devel@lists.xensource.com; Wed, 14 Sep 2011 10:59:26 -0700 X-Env-Sender: nathan@gt.net X-Msg-Ref: server-6.tower-216.messagelabs.com!1316023131!17018022!1 X-Originating-IP: [208.70.244.21] X-StarScan-Version: 6.4.1; banners=-,-,- X-VirusChecked: Checked Received: (qmail 24339 invoked from network); 14 Sep 2011 17:58:53 -0000 Received: from gossamer.nmsrv.com (HELO gossamer.nmsrv.com) (208.70.244.21) by server-6.tower-216.messagelabs.com with DHE-RSA-AES256-SHA encrypted SMTP; 14 Sep 2011 17:58:53 -0000 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=gt.net; h=message-id:date :from:mime-version:to:cc:subject:references:in-reply-to :content-type:content-transfer-encoding; s=mail; bh=tKDkIZ2sLzek POy+vi+0zN0wx+k=; b=LTukEO81gmmwja8f6w60XdShskwup/ioUr5r589tdzYs dyuQEHshK4jj/fMAfBEX0JTo3T6sTqVMJIv0JpAd22YhIX7mroittmxt/+bY8x+p njMxv7SHtkovEZ8H49GUmKSJdKRfwLZWmot9hI7+Wfu70eLzJ1oN8wWAvEC9UMc= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gt.net; h=message-id:date :from:mime-version:to:cc:subject:references:in-reply-to :content-type:content-transfer-encoding; q=dns; s=mail; b=B3gQTV iozqy5vMNVnhw7AIvrgmOMBCvkvzkO3pnNq2Bcnr3iWU/XN+iTd4nD4meXqXWRcZ eDf1FdkOKm+VkHLsFhq32apSBbc5imS9dTX/aUY4IQEY8KJ+lkb024kZViQWTUv5 PF3cgo10Ar/+2hmnaSfFT1oCZGPVistpYGvy0= Received: (qmail 22659 invoked from network); 14 Sep 2011 17:58:50 -0000 X-AntiVirus: Clean Received: from gateway.gossamer-threads.com (HELO ?192.168.1.152?) (nathan@gossamer-threads.com@208.70.247.145) by gossamer.nmsrv.com with ESMTPSA (DHE-RSA-CAMELLIA256-SHA encrypted); 14 Sep 2011 17:58:50 -0000 Message-ID: <4E70EB59.1080708@gt.net> Date: Wed, 14 Sep 2011 10:58:49 -0700 From: Nathan March User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:7.0) Gecko/20110905 Thunderbird/7.0 MIME-Version: 1.0 To: rshriram@cs.ubc.ca Subject: Re: [Xen-devel] Internal error during live migration saving References: <4E6FC4A6.5040304@gt.net> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: xen-devel@lists.xensource.com X-BeenThere: xen-devel@lists.xensource.com X-Mailman-Version: 2.1.5 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xensource.com Errors-To: xen-devel-bounces@lists.xensource.com On 9/14/2011 10:53 AM, Shriram Rajagopalan wrote: > On Tue, Sep 13, 2011 at 2:01 PM, Nathan March wrote: >> Just wondering if this is a known bug? >> >> Trying to migrate the VM off to a diff dom0 results in the below error. >> Other VMs migrated off fine (started at around the same time as this vm) and >> I've tried a few different target servers, all resulting in the same thing. >> > Were other domains linux 3.0.3 as well ? All the dom0's are 3.0.3 and all the domU's are 2.6.32.27 (w/ grsec). I did a cold reboot of the VM and now it migrates properly. >> [2011-09-13 13:48:24 3996] DEBUG (XendCheckpoint:124) [xc_save]: >> /usr/lib/xen/bin/xc_save 29 77 0 0 1 >> [2011-09-13 13:48:24 3996] INFO (XendCheckpoint:423) xc_save: failed to get >> the suspend evtchn port >> [2011-09-13 13:48:24 3996] INFO (XendCheckpoint:423) >> [2011-09-13 13:49:03 3996] DEBUG (XendCheckpoint:394) suspend >> [2011-09-13 13:49:03 3996] DEBUG (XendCheckpoint:127) In saveInputHandler >> suspend >> [2011-09-13 13:49:03 3996] DEBUG (XendCheckpoint:129) Suspending 77 ... >> [2011-09-13 13:49:03 3996] DEBUG (XendDomainInfo:524) >> XendDomainInfo.shutdown(suspend) >> [2011-09-13 13:49:03 3996] DEBUG (XendDomainInfo:1881) >> XendDomainInfo.handleShutdownWatch >> [2011-09-13 13:50:06 3996] DEBUG (XendDomainInfo:1881) >> XendDomainInfo.handleShutdownWatch >> [2011-09-13 13:50:06 3996] INFO (XendCheckpoint:423) xc: error: Suspend >> request failed: Internal error >> [2011-09-13 13:50:06 3996] INFO (XendCheckpoint:423) xc: error: Domain >> appears not to have suspended: Internal error >> [2011-09-13 13:50:06 3996] ERROR (XendCheckpoint:185) Save failed on domain >> globish (77) - resuming. >> Traceback (most recent call last): >> File "/usr/lib64/python2.6/site-packages/xen/xend/XendCheckpoint.py", line >> 146, in save >> forkHelper(cmd, fd, saveInputHandler, False) >> File "/usr/lib64/python2.6/site-packages/xen/xend/XendCheckpoint.py", line >> 395, in forkHelper >> inputHandler(line, child.tochild) >> File "/usr/lib64/python2.6/site-packages/xen/xend/XendCheckpoint.py", line >> 131, in saveInputHandler >> dominfo.waitForSuspend() >> File "/usr/lib64/python2.6/site-packages/xen/xend/XendDomainInfo.py", line >> 2998, in waitForSuspend >> raise XendError(msg) >> XendError: Timeout waiting for domain 77 to suspend >> [2011-09-13 13:50:06 3996] DEBUG (XendDomainInfo:3135) >> XendDomainInfo.resumeDomain(77) >> >> xend-debug.log and the target dom0 logs don't show anything of value. >> >> This is xen 4.1.1 on linux 3.0.3 >> > Did you try xm save -c (or the xl equivalent) ? This should be > activating the same > code path where this error seems to appear. > > Also, make sure you have CONFIG_XEN_SAVE_RESTORE enabled. Unfortunately I didn't think to try it. I do have that set on both dom0 and domu. - Nathan _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel From xen-devel-bounces@lists.xensource.com Wed Sep 14 11:11:38 2011 Return-path: Envelope-to: www-data@lists.xensource.com Delivery-date: Wed, 14 Sep 2011 11:11:38 -0700 Received: from localhost ([127.0.0.1] helo=lists.colo.xensource.com) by lists.xensource.com with esmtp (Exim 4.43) id 1R3tvt-0003Ga-5Z; Wed, 14 Sep 2011 11:11:37 -0700 Received: from mail21.messagelabs.com ([85.158.143.35]) by lists.xensource.com with esmtp (Exim 4.43) id 1R3tuF-00032w-6R for xen-devel@lists.xensource.com; Wed, 14 Sep 2011 11:09:57 -0700 X-Env-Sender: rshriram@cs.ubc.ca X-Msg-Ref: server-13.tower-21.messagelabs.com!1316023784!48936429!1 X-Originating-IP: [142.103.6.52] X-StarScan-Version: 6.4.1; banners=-,-,- X-VirusChecked: Checked Received: (qmail 13793 invoked from network); 14 Sep 2011 18:09:46 -0000 Received: from smtp.cs.ubc.ca (HELO smtp.cs.ubc.ca) (142.103.6.52) by server-13.tower-21.messagelabs.com with DHE-RSA-AES256-SHA encrypted SMTP; 14 Sep 2011 18:09:46 -0000 Received: from mail-bw0-f43.google.com (mail-bw0-f43.google.com [209.85.214.43]) (authenticated bits=0) by smtp.cs.ubc.ca (8.14.3/8.13.6) with ESMTP id p8EI9ldY001251 (version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=FAIL) for ; Wed, 14 Sep 2011 11:09:48 -0700 Received: by bkas6 with SMTP id s6so2283863bka.30 for ; Wed, 14 Sep 2011 11:09:46 -0700 (PDT) Received: by 10.204.142.204 with SMTP id r12mr65393bku.388.1316023786406; Wed, 14 Sep 2011 11:09:46 -0700 (PDT) MIME-Version: 1.0 Received: by 10.204.123.19 with HTTP; Wed, 14 Sep 2011 11:09:06 -0700 (PDT) In-Reply-To: <4E70EB59.1080708@gt.net> References: <4E6FC4A6.5040304@gt.net> <4E70EB59.1080708@gt.net> From: Shriram Rajagopalan Date: Wed, 14 Sep 2011 11:09:06 -0700 Message-ID: Subject: Re: [Xen-devel] Internal error during live migration saving To: Nathan March Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: xen-devel@lists.xensource.com X-BeenThere: xen-devel@lists.xensource.com X-Mailman-Version: 2.1.5 Precedence: list Reply-To: rshriram@cs.ubc.ca List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xensource.com Errors-To: xen-devel-bounces@lists.xensource.com On Wed, Sep 14, 2011 at 10:58 AM, Nathan March wrote: > > On 9/14/2011 10:53 AM, Shriram Rajagopalan wrote: >> >> On Tue, Sep 13, 2011 at 2:01 PM, Nathan March =A0wrote: >>> >>> Just wondering if this is a known bug? >>> >>> Trying to migrate the VM off to a diff dom0 results in the below error. >>> Other VMs migrated off fine (started at around the same time as this vm= ) >>> and >>> I've tried a few different target servers, all resulting in the same >>> thing. >>> >> Were other domains linux 3.0.3 as well ? > > All the dom0's are 3.0.3 and all the domU's are 2.6.32.27 (w/ grsec). > > I did a cold reboot of the VM and now it migrates properly. > >>> [2011-09-13 13:48:24 3996] DEBUG (XendCheckpoint:124) [xc_save]: >>> /usr/lib/xen/bin/xc_save 29 77 0 0 1 >>> [2011-09-13 13:48:24 3996] INFO (XendCheckpoint:423) xc_save: failed to >>> get >>> the suspend evtchn port >>> [2011-09-13 13:48:24 3996] INFO (XendCheckpoint:423) >>> [2011-09-13 13:49:03 3996] DEBUG (XendCheckpoint:394) suspend >>> [2011-09-13 13:49:03 3996] DEBUG (XendCheckpoint:127) In saveInputHandl= er >>> suspend >>> [2011-09-13 13:49:03 3996] DEBUG (XendCheckpoint:129) Suspending 77 ... >>> [2011-09-13 13:49:03 3996] DEBUG (XendDomainInfo:524) >>> XendDomainInfo.shutdown(suspend) >>> [2011-09-13 13:49:03 3996] DEBUG (XendDomainInfo:1881) >>> XendDomainInfo.handleShutdownWatch >>> [2011-09-13 13:50:06 3996] DEBUG (XendDomainInfo:1881) >>> XendDomainInfo.handleShutdownWatch >>> [2011-09-13 13:50:06 3996] INFO (XendCheckpoint:423) xc: error: Suspend >>> request failed: Internal error >>> [2011-09-13 13:50:06 3996] INFO (XendCheckpoint:423) xc: error: Domain >>> appears not to have suspended: Internal error >>> [2011-09-13 13:50:06 3996] ERROR (XendCheckpoint:185) Save failed on >>> domain >>> globish (77) - resuming. >>> Traceback (most recent call last): >>> =A0File "/usr/lib64/python2.6/site-packages/xen/xend/XendCheckpoint.py"= , >>> line >>> 146, in save >>> =A0 =A0forkHelper(cmd, fd, saveInputHandler, False) >>> =A0File "/usr/lib64/python2.6/site-packages/xen/xend/XendCheckpoint.py"= , >>> line >>> 395, in forkHelper >>> =A0 =A0inputHandler(line, child.tochild) >>> =A0File "/usr/lib64/python2.6/site-packages/xen/xend/XendCheckpoint.py"= , >>> line >>> 131, in saveInputHandler >>> =A0 =A0dominfo.waitForSuspend() >>> =A0File "/usr/lib64/python2.6/site-packages/xen/xend/XendDomainInfo.py"= , >>> line >>> 2998, in waitForSuspend >>> =A0 =A0raise XendError(msg) >>> XendError: Timeout waiting for domain 77 to suspend >>> [2011-09-13 13:50:06 3996] DEBUG (XendDomainInfo:3135) >>> XendDomainInfo.resumeDomain(77) >>> >>> xend-debug.log and the target dom0 logs don't show anything of value. >>> >>> This is xen 4.1.1 on linux 3.0.3 >>> >> Did you try xm save -c (or the xl equivalent) ? This should be >> activating the same >> code path where this error seems to appear. >> >> Also, make sure you have CONFIG_XEN_SAVE_RESTORE enabled. > > Unfortunately I didn't think to try it. I do have that set on both dom0 a= nd > domu. > > - Nathan > > Oh, I assumed that the domU's were linux 3.0.3. That config has no meaning for dom0s. _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel From xen-devel-bounces@lists.xensource.com Wed Sep 14 12:28:21 2011 Return-path: Envelope-to: www-data@lists.xensource.com Delivery-date: Wed, 14 Sep 2011 12:28:21 -0700 Received: from localhost ([127.0.0.1] helo=lists.colo.xensource.com) by lists.xensource.com with esmtp (Exim 4.43) id 1R3v88-0005Fh-VU; Wed, 14 Sep 2011 12:28:21 -0700 Received: from mail216.messagelabs.com ([85.158.143.99]) by lists.xensource.com with smtp (Exim 4.43) id 1R3v6v-00052h-1s for xen-devel@lists.xensource.com; Wed, 14 Sep 2011 12:27:05 -0700 X-Env-Sender: avi@redhat.com X-Msg-Ref: server-9.tower-216.messagelabs.com!1316028421!18296988!1 X-Originating-IP: [209.132.183.28] X-StarScan-Version: 6.4.1; banners=-,-,- X-VirusChecked: Checked Received: (qmail 4175 invoked from network); 14 Sep 2011 19:27:01 -0000 Received: from mx1.redhat.com (HELO mx1.redhat.com) (209.132.183.28) by server-9.tower-216.messagelabs.com with SMTP; 14 Sep 2011 19:27:01 -0000 Received: from int-mx02.intmail.prod.int.phx2.redhat.com (int-mx02.intmail.prod.int.phx2.redhat.com [10.5.11.12]) by mx1.redhat.com (8.14.4/8.14.4) with ESMTP id p8EJQWVO029117 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Wed, 14 Sep 2011 15:26:32 -0400 Received: from mermaid.qumranet.com (vpn-200-147.tlv.redhat.com [10.35.200.147]) by int-mx02.intmail.prod.int.phx2.redhat.com (8.13.8/8.13.8) with ESMTP id p8EJQL0h027922; Wed, 14 Sep 2011 15:26:23 -0400 Message-ID: <4E70FFDD.80405@redhat.com> Date: Wed, 14 Sep 2011 22:26:21 +0300 From: Avi Kivity User-Agent: Mozilla/5.0 (X11; Linux i686 on x86_64; rv:6.0.2) Gecko/20110906 Thunderbird/6.0.2 MIME-Version: 1.0 To: Andi Kleen References: <20110907155657.GX5795@redhat.com> <4E679AF4.50209@redhat.com> <20110907165203.GQ6838@redhat.com> <4E67A551.4000502@redhat.com> <20110913184044.GN5795@redhat.com> <20110913190320.GR7761@one.firstfloor.org> <20110913192152.GO5795@redhat.com> <4E7050F7.3000208@redhat.com> <20110914144926.GU7761@one.firstfloor.org> <4E70C1BE.7060209@redhat.com> <20110914172838.GV7761@one.firstfloor.org> In-Reply-To: <20110914172838.GV7761@one.firstfloor.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Scanned-By: MIMEDefang 2.67 on 10.5.11.12 Cc: Don Zickus , Jeremy Fitzhardinge , Marcelo Tosatti , Nick Piggin , KVM , Stefano Stabellini , Peter Zijlstra , the arch/x86 maintainers , Linux Kernel Mailing List , Xen Devel , Jeremy Fitzhardinge , "H. Peter Anvin" , Ingo Molnar , Linus Torvalds Subject: [Xen-devel] Re: [PATCH 08/13] xen/pvticketlock: disable interrupts while blocking X-BeenThere: xen-devel@lists.xensource.com X-Mailman-Version: 2.1.5 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xensource.com Errors-To: xen-devel-bounces@lists.xensource.com On 09/14/2011 08:28 PM, Andi Kleen wrote: > > If an NMI hits in an interrupt handler, or in the "after hlt" section > > before the write-to-last-nmi-rip, then we'll see that %rip has changed. > > If it hits after the write-to-last-nmi-rip instruction (or in the hlt > > itself), then we'll also see that %rip has changed, due to the effect of > > that instruction. > > It won't handle multiple NMIs in halt. I assume that's reasonable common. > Why not? -- I have a truly marvellous patch that fixes the bug which this signature is too narrow to contain. _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel From xen-devel-bounces@lists.xensource.com Wed Sep 14 12:35:17 2011 Return-path: Envelope-to: www-data@lists.xensource.com Delivery-date: Wed, 14 Sep 2011 12:35:17 -0700 Received: from localhost ([127.0.0.1] helo=lists.colo.xensource.com) by lists.xensource.com with esmtp (Exim 4.43) id 1R3vEr-0005mv-O2; Wed, 14 Sep 2011 12:35:17 -0700 Received: from mail174.messagelabs.com ([85.158.138.51]) by lists.xensource.com with esmtp (Exim 4.43) id 1R3vEH-0005aF-5o for xen-devel@lists.xensource.com; Wed, 14 Sep 2011 12:34:41 -0700 X-Env-Sender: andi@firstfloor.org X-Msg-Ref: server-6.tower-174.messagelabs.com!1316028877!29303251!1 X-Originating-IP: [213.235.205.2] X-StarScan-Version: 6.4.1; banners=-,-,- X-VirusChecked: Checked Received: (qmail 21280 invoked from network); 14 Sep 2011 19:34:38 -0000 Received: from one.firstfloor.org (HELO one.firstfloor.org) (213.235.205.2) by server-6.tower-174.messagelabs.com with DHE-RSA-AES256-SHA encrypted SMTP; 14 Sep 2011 19:34:38 -0000 Received: by one.firstfloor.org (Postfix, from userid 503) id 33DC11ED80B7; Wed, 14 Sep 2011 21:34:37 +0200 (CEST) Date: Wed, 14 Sep 2011 21:34:37 +0200 From: Andi Kleen To: Avi Kivity Message-ID: <20110914193437.GX7761@one.firstfloor.org> References: <20110907165203.GQ6838@redhat.com> <4E67A551.4000502@redhat.com> <20110913184044.GN5795@redhat.com> <20110913190320.GR7761@one.firstfloor.org> <20110913192152.GO5795@redhat.com> <4E7050F7.3000208@redhat.com> <20110914144926.GU7761@one.firstfloor.org> <4E70C1BE.7060209@redhat.com> <20110914172838.GV7761@one.firstfloor.org> <4E70FFDD.80405@redhat.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <4E70FFDD.80405@redhat.com> User-Agent: Mutt/1.4.2.2i Cc: Don Zickus , Jeremy Fitzhardinge , Marcelo Tosatti , Nick Piggin , KVM , Stefano Stabellini , Peter Zijlstra , the arch/x86 maintainers , Linux Kernel Mailing List , Andi Kleen , Jeremy Fitzhardinge , "H. Peter Anvin" , Ingo Molnar , Linus Torvalds , Xen Devel Subject: [Xen-devel] Re: [PATCH 08/13] xen/pvticketlock: disable interrupts while blocking X-BeenThere: xen-devel@lists.xensource.com X-Mailman-Version: 2.1.5 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xensource.com Errors-To: xen-devel-bounces@lists.xensource.com On Wed, Sep 14, 2011 at 10:26:21PM +0300, Avi Kivity wrote: > On 09/14/2011 08:28 PM, Andi Kleen wrote: > >> If an NMI hits in an interrupt handler, or in the "after hlt" section > >> before the write-to-last-nmi-rip, then we'll see that %rip has changed. > >> If it hits after the write-to-last-nmi-rip instruction (or in the hlt > >> itself), then we'll also see that %rip has changed, due to the effect of > >> that instruction. > > > >It won't handle multiple NMIs in halt. I assume that's reasonable common. > > > > Why not? They all have the same original RIPs and there is no way to distingush them. -Andi -- ak@linux.intel.com -- Speaking for myself only. _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel From xen-devel-bounces@lists.xensource.com Wed Sep 14 13:00:11 2011 Return-path: Envelope-to: www-data@lists.xensource.com Delivery-date: Wed, 14 Sep 2011 13:00:11 -0700 Received: from localhost ([127.0.0.1] helo=lists.colo.xensource.com) by lists.xensource.com with esmtp (Exim 4.43) id 1R3vcv-0006bt-3C; Wed, 14 Sep 2011 13:00:09 -0700 Received: from mail21.messagelabs.com ([85.158.143.35]) by lists.xensource.com with smtp (Exim 4.43) id 1R3vaL-0006NG-KD for xen-devel@lists.xensource.com; Wed, 14 Sep 2011 12:57:30 -0700 X-Env-Sender: avi@redhat.com X-Msg-Ref: server-14.tower-21.messagelabs.com!1316030237!59606191!1 X-Originating-IP: [209.132.183.28] X-StarScan-Version: 6.4.1; banners=-,-,- X-VirusChecked: Checked Received: (qmail 1980 invoked from network); 14 Sep 2011 19:57:18 -0000 Received: from mx1.redhat.com (HELO mx1.redhat.com) (209.132.183.28) by server-14.tower-21.messagelabs.com with SMTP; 14 Sep 2011 19:57:18 -0000 Received: from int-mx02.intmail.prod.int.phx2.redhat.com (int-mx02.intmail.prod.int.phx2.redhat.com [10.5.11.12]) by mx1.redhat.com (8.14.4/8.14.4) with ESMTP id p8EJuupQ008450 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Wed, 14 Sep 2011 15:56:57 -0400 Received: from mermaid.qumranet.com (vpn-200-147.tlv.redhat.com [10.35.200.147]) by int-mx02.intmail.prod.int.phx2.redhat.com (8.13.8/8.13.8) with ESMTP id p8EJupPq006358; Wed, 14 Sep 2011 15:56:52 -0400 Message-ID: <4E710703.1010604@redhat.com> Date: Wed, 14 Sep 2011 22:56:51 +0300 From: Avi Kivity User-Agent: Mozilla/5.0 (X11; Linux i686 on x86_64; rv:6.0.2) Gecko/20110906 Thunderbird/6.0.2 MIME-Version: 1.0 To: Andi Kleen References: <20110907165203.GQ6838@redhat.com> <4E67A551.4000502@redhat.com> <20110913184044.GN5795@redhat.com> <20110913190320.GR7761@one.firstfloor.org> <20110913192152.GO5795@redhat.com> <4E7050F7.3000208@redhat.com> <20110914144926.GU7761@one.firstfloor.org> <4E70C1BE.7060209@redhat.com> <20110914172838.GV7761@one.firstfloor.org> <4E70FFDD.80405@redhat.com> <20110914193437.GX7761@one.firstfloor.org> In-Reply-To: <20110914193437.GX7761@one.firstfloor.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Scanned-By: MIMEDefang 2.67 on 10.5.11.12 Cc: Don Zickus , Jeremy Fitzhardinge , Marcelo Tosatti , Nick Piggin , KVM , Stefano Stabellini , Peter Zijlstra , the arch/x86 maintainers , Linux Kernel Mailing List , Xen Devel , Jeremy Fitzhardinge , "H. Peter Anvin" , Ingo Molnar , Linus Torvalds Subject: [Xen-devel] Re: [PATCH 08/13] xen/pvticketlock: disable interrupts while blocking X-BeenThere: xen-devel@lists.xensource.com X-Mailman-Version: 2.1.5 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xensource.com Errors-To: xen-devel-bounces@lists.xensource.com On 09/14/2011 10:34 PM, Andi Kleen wrote: > On Wed, Sep 14, 2011 at 10:26:21PM +0300, Avi Kivity wrote: > > On 09/14/2011 08:28 PM, Andi Kleen wrote: > > >> If an NMI hits in an interrupt handler, or in the "after hlt" section > > >> before the write-to-last-nmi-rip, then we'll see that %rip has changed. > > >> If it hits after the write-to-last-nmi-rip instruction (or in the hlt > > >> itself), then we'll also see that %rip has changed, due to the effect of > > >> that instruction. > > > > > >It won't handle multiple NMIs in halt. I assume that's reasonable common. > > > > > > > Why not? > > They all have the same original RIPs and there is no way to distingush > them. > That's how we detect multiple NMIs. 1. First NMI is posted 2. NMI handler starts 3. 2nd NMI posted, queued 4. First NMI source handled 5. IRET 6. Queued NMI hits the core 7. back-to-back NMI detected (same rip) 8. Second (and third...) NMI source handled 9. Execution continues. -- I have a truly marvellous patch that fixes the bug which this signature is too narrow to contain. _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel From xen-devel-bounces@lists.xensource.com Wed Sep 14 13:19:51 2011 Return-path: Envelope-to: www-data@lists.xensource.com Delivery-date: Wed, 14 Sep 2011 13:19:51 -0700 Received: from localhost ([127.0.0.1] helo=lists.colo.xensource.com) by lists.xensource.com with esmtp (Exim 4.43) id 1R3vvz-0007Eb-Ci; Wed, 14 Sep 2011 13:19:51 -0700 Received: from mail21.messagelabs.com ([85.158.143.35]) by lists.xensource.com with esmtp (Exim 4.43) id 1R3vug-00071g-UA for xen-devel@lists.xensource.com; Wed, 14 Sep 2011 13:18:32 -0700 X-Env-Sender: burns.me.uk@gmail.com X-Msg-Ref: server-13.tower-21.messagelabs.com!1316031501!48944164!1 X-Originating-IP: [74.125.83.47] X-StarScan-Version: 6.4.1; banners=-,-,- X-VirusChecked: Checked Received: (qmail 6141 invoked from network); 14 Sep 2011 20:18:22 -0000 Received: from mail-gw0-f47.google.com (HELO mail-gw0-f47.google.com) (74.125.83.47) by server-13.tower-21.messagelabs.com with RC4-SHA encrypted SMTP; 14 Sep 2011 20:18:22 -0000 Received: by gwb11 with SMTP id 11so2275165gwb.6 for ; Wed, 14 Sep 2011 13:18:26 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type; bh=brJjIwEyBM+Qq0Zj3Ap4XTnY1rvxiFxl+L5R/SO51ao=; b=EyGEyTPss6bvMHohJMAQEhYw4wf+sAULGeOrr2kQxnmVtED919iM8bcZOrXGG3UAeM ZSS4JQG5jfWBr6ikxIx3ATsAzdHdkjLORFKmBMb2llLWgwi4KKvU8wtYfTzHBsa0EQdp o8K6DJP4+9HUPRRc5dBSuSGTau3Oyyq4dpbuE= MIME-Version: 1.0 Received: by 10.52.69.177 with SMTP id f17mr303740vdu.150.1316031506602; Wed, 14 Sep 2011 13:18:26 -0700 (PDT) Received: by 10.52.35.231 with HTTP; Wed, 14 Sep 2011 13:18:26 -0700 (PDT) In-Reply-To: <20110914105711.GA16284@phenom.oracle.com> References: <201107231426.56811.jim_burn@bellsouth.net> <1342436.B0x3ddQn4U@dell4550> <20110913085559.GG12984@reaktio.net> <1856036.eYCcuDQrZC@dell4550> <20110914090806.GD25628@phenom.oracle.com> <20110914105711.GA16284@phenom.oracle.com> Date: Wed, 14 Sep 2011 21:18:26 +0100 X-Google-Sender-Auth: wPMWdIGZjKhx9VNc7rxdGLLffDI Message-ID: Subject: Re: [Xen-devel] Re: [Xen-users] Continuing BUG:-iness booting Fedora Rawhide 3.1.0-rc's (was Summary: Experiences setting up a debug serial port) From: Andy Burns To: xen-devel@lists.xensource.com Cc: Fedora Xen List X-BeenThere: xen-devel@lists.xensource.com X-Mailman-Version: 2.1.5 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0329391451==" Sender: xen-devel-bounces@lists.xensource.com Errors-To: xen-devel-bounces@lists.xensource.com --===============0329391451== Content-Type: multipart/alternative; boundary=20cf307d00d076dadb04acec76ea --20cf307d00d076dadb04acec76ea Content-Type: text/plain; charset=ISO-8859-1 On 14 September 2011 11:57, Konrad Rzeszutek Wilk wrote: > > We are quite sure we know the cause of this. I was wondering if you would > be > > up for beta-testing a patch for this? > > Specifically this patch seems to fix it for me: > > commit 690dc11498b192db25762de77988224753517c96 > Author: Konrad Rzeszutek Wilk > Date: Wed Sep 14 05:10:00 2011 -0400 > > I'll try to give that a go tomorrow night, I'm bumping into the same sort of BUGs (scheduling while atomic, sleeping function called from invalid context) with FC16 dom0, they don't seem to bring the system to its knees though they do stop it shutting down cleanly, havent fired up any domU yet. --20cf307d00d076dadb04acec76ea Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable On 14 September 2011 11:57, Konrad Rzeszutek Wilk <konrad.wilk@oracle.com> wrote:
=A0
> We are quite sure we know the cause of this. I was w= ondering if you would be
> up for beta-testing a patch for this?

Specifically this patch seems to fix it for me:

commit 690dc11498b192db25762de77988224753517c96
Author: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
Date: =A0 Wed Sep 14 05:10:00 2011 -0400


I'= ;ll try to give that a go tomorrow night, I'm bumping into the same sor= t of BUGs (scheduling while atomic, sleeping function called from invalid c= ontext) with FC16 dom0, they don't seem to bring the system to its knee= s though they do stop it shutting down cleanly, havent fired up any domU ye= t.

--20cf307d00d076dadb04acec76ea-- --===============0329391451== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel --===============0329391451==-- From xen-devel-bounces@lists.xensource.com Wed Sep 14 14:08:44 2011 Return-path: Envelope-to: www-data@lists.xensource.com Delivery-date: Wed, 14 Sep 2011 14:08:44 -0700 Received: from localhost ([127.0.0.1] helo=lists.colo.xensource.com) by lists.xensource.com with esmtp (Exim 4.43) id 1R3whI-0008TC-Eo; Wed, 14 Sep 2011 14:08:44 -0700 Received: from mail174.messagelabs.com ([85.158.138.51]) by lists.xensource.com with smtp (Exim 4.43) id 1R3wgJ-0008Gk-JQ for xen-devel@lists.xensource.com; Wed, 14 Sep 2011 14:07:44 -0700 X-Env-Sender: jim_burn@bellsouth.net X-Msg-Ref: server-12.tower-174.messagelabs.com!1316034459!31435707!1 X-Originating-IP: [98.139.44.152] X-StarScan-Version: 6.4.1; banners=-,-,- X-VirusChecked: Checked Received: (qmail 27061 invoked from network); 14 Sep 2011 21:07:40 -0000 Received: from nm25.access.bullet.mail.sp2.yahoo.com (HELO nm25.access.bullet.mail.sp2.yahoo.com) (98.139.44.152) by server-12.tower-174.messagelabs.com with SMTP; 14 Sep 2011 21:07:40 -0000 Received: from [98.139.44.107] by nm25.access.bullet.mail.sp2.yahoo.com with NNFMP; 14 Sep 2011 21:07:39 -0000 Received: from [98.139.44.91] by tm12.access.bullet.mail.sp2.yahoo.com with NNFMP; 14 Sep 2011 21:07:39 -0000 Received: from [127.0.0.1] by omp1028.access.mail.sp2.yahoo.com with NNFMP; 14 Sep 2011 21:07:39 -0000 X-Yahoo-Newman-Id: 329336.59218.bm@omp1028.access.mail.sp2.yahoo.com Received: (qmail 73407 invoked from network); 14 Sep 2011 21:07:39 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=bellsouth.net; s=s1024; t=1316034458; bh=Sad5UX7Kw4EyYeJozvf/60UAkdBssRwv4mFrf6bLI0o=; h=X-Yahoo-Newman-Property:X-YMail-OSG:X-Yahoo-SMTP:Received:From:To:Cc:Subject:Date:Message-ID:User-Agent:In-Reply-To:References:MIME-Version:Content-Transfer-Encoding:Content-Type; b=CaeAmuMzfadfj+yqFw/+lFKrD03Xvn+J82x383+6XtD7DEGfqL1YkwE61g1bqUcGh2YOtmcoiBqR1HiiWH5MlOlCOkx6rcJTw12ulkRFiB/TzP878kUlIdBPh9Hp1/5UNs0eX70MhGG2ZljxFyYUQbKsPWwQ/jtzoNvVa5s2M3A= X-Yahoo-Newman-Property: ymail-3 X-YMail-OSG: WJtAJ74VM1m0_iWttf_RXLzryr3Euir71W4gJhVrYHafp4c NWbE- X-Yahoo-SMTP: g0AhWW2swBA2djJKuhuwxPlPqLrHlDrycdPnfR9kZNrpKCA- Received: from dell4550.localnet (jim_burn@72.145.181.92 with plain) by smtp103.sbc.mail.ne1.yahoo.com with SMTP; 14 Sep 2011 14:07:38 -0700 PDT From: jim burns To: Konrad Rzeszutek Wilk , Ian Campbell , Pasi =?ISO-8859-1?Q?K=E4rkk=E4inen?= Subject: Re: [Xen-devel] Re: [Xen-users] Continuing BUG:-iness booting Fedora Rawhide 3.1.0-rc's (was Summary: Experiences setting up a debug serial port) Date: Wed, 14 Sep 2011 17:07:28 -0400 Message-ID: <1551334.UG67O7dPfn@dell4550> User-Agent: KMail/4.7.1 (Linux/2.6.37.6-0.7-default; KDE/4.7.1; i686; ; ) In-Reply-To: <20110914105711.GA16284@phenom.oracle.com> References: <201107231426.56811.jim_burn@bellsouth.net> <20110914090806.GD25628@phenom.oracle.com> <20110914105711.GA16284@phenom.oracle.com> MIME-Version: 1.0 Content-Transfer-Encoding: 7Bit Content-Type: text/plain; charset="us-ascii" Cc: Todd Deshane , xen-devel@lists.xensource.com, xen-users@lists.xensource.com, Fedora Xen List X-BeenThere: xen-devel@lists.xensource.com X-Mailman-Version: 2.1.5 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xensource.com Errors-To: xen-devel-bounces@lists.xensource.com On Wed September 14 2011, 6:57:11 AM, Konrad Rzeszutek Wilk wrote: > On Wed, Sep 14, 2011 at 05:08:06AM -0400, Konrad Rzeszutek Wilk wrote: > > > Rawhide just came out with 3.1.0-0.rc6.git0.0.fc17.x86_64 , and the > > > BUG:s are still the same as in the last log I sent. However, as > > > promised I have attached the initcall_debug log, but for rc6. > > > > > > > > Hey Jim, > > > > > > > > We are quite sure we know the cause of this. I was wondering if you > > would be up for beta-testing a patch for this? > > Specifically this patch seems to fix it for me: > > > commit 690dc11498b192db25762de77988224753517c96 > Author: Konrad Rzeszutek Wilk > Date: Wed Sep 14 05:10:00 2011 -0400 > xen/irq: Alter the locking to be a mutex. I'll try to apply this to fedora's xen src rpm over the weekend. In case it doesn't apply, would you remind me of the git commands for the code you applied this patch to? Thanx. _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel From xen-devel-bounces@lists.xensource.com Wed Sep 14 15:14:32 2011 Return-path: Envelope-to: www-data@lists.xensource.com Delivery-date: Wed, 14 Sep 2011 15:14:32 -0700 Received: from localhost ([127.0.0.1] helo=lists.colo.xensource.com) by lists.xensource.com with esmtp (Exim 4.43) id 1R3xiy-0002Gj-BV; Wed, 14 Sep 2011 15:14:32 -0700 Received: from mail216.messagelabs.com ([85.158.143.99]) by lists.xensource.com with esmtp (Exim 4.43) id 1R3xhq-000248-Fy; Wed, 14 Sep 2011 15:13:23 -0700 X-Env-Sender: konrad@oracle.com X-Msg-Ref: server-12.tower-216.messagelabs.com!1316038398!12558563!1 X-Originating-IP: [141.146.126.227] X-StarScan-Version: 6.4.1; banners=-,-,- X-VirusChecked: Checked Received: (qmail 30372 invoked from network); 14 Sep 2011 22:13:19 -0000 Received: from acsinet15.oracle.com (HELO acsinet15.oracle.com) (141.146.126.227) by server-12.tower-216.messagelabs.com with DHE-RSA-AES256-SHA encrypted SMTP; 14 Sep 2011 22:13:19 -0000 Received: from rtcsinet21.oracle.com (rtcsinet21.oracle.com [66.248.204.29]) by acsinet15.oracle.com (Switch-3.4.4/Switch-3.4.4) with ESMTP id p8EMD28O000953 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Wed, 14 Sep 2011 22:13:04 GMT Received: from acsmt356.oracle.com (acsmt356.oracle.com [141.146.40.156]) by rtcsinet21.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id p8EMD02B018477 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 14 Sep 2011 22:13:01 GMT Received: from abhmt104.oracle.com (abhmt104.oracle.com [141.146.116.56]) by acsmt356.oracle.com (8.12.11.20060308/8.12.11) with ESMTP id p8EMCsCq032724; Wed, 14 Sep 2011 17:12:54 -0500 Received: from oracle.com (/209.6.55.207) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Wed, 14 Sep 2011 15:12:54 -0700 Received: by oracle.com (Postfix, from userid 1000) id A5B9D1362; Wed, 14 Sep 2011 18:12:54 -0400 (EDT) Date: Wed, 14 Sep 2011 18:12:54 -0400 From: Konrad Rzeszutek Wilk To: jim burns Subject: Re: [Xen-devel] Re: [Xen-users] Continuing BUG:-iness booting Fedora Rawhide 3.1.0-rc's (was Summary: Experiences setting up a debug serial port) Message-ID: <20110914221254.GB3742@phenom.oracle.com> References: <201107231426.56811.jim_burn@bellsouth.net> <20110914090806.GD25628@phenom.oracle.com> <20110914105711.GA16284@phenom.oracle.com> <1551334.UG67O7dPfn@dell4550> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <1551334.UG67O7dPfn@dell4550> User-Agent: Mutt/1.5.21 (2010-09-15) X-Source-IP: rtcsinet21.oracle.com [66.248.204.29] X-CT-RefId: str=0001.0A02020B.4E7126F1.0013,ss=1,re=0.000,fgs=0 Cc: xen-devel@lists.xensource.com, Fedora Xen List , Ian Campbell , Todd Deshane , xen-users@lists.xensource.com X-BeenThere: xen-devel@lists.xensource.com X-Mailman-Version: 2.1.5 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xensource.com Errors-To: xen-devel-bounces@lists.xensource.com On Wed, Sep 14, 2011 at 05:07:28PM -0400, jim burns wrote: > On Wed September 14 2011, 6:57:11 AM, Konrad Rzeszutek Wilk wrote: > > On Wed, Sep 14, 2011 at 05:08:06AM -0400, Konrad Rzeszutek Wilk wrote: > > > > Rawhide just came out with 3.1.0-0.rc6.git0.0.fc17.x86_64 , and the > > > > BUG:s are still the same as in the last log I sent. However, as > > > > promised I have attached the initcall_debug log, but for rc6. > > > > > > > > > > > > Hey Jim, > > > > > > > > > > > > We are quite sure we know the cause of this. I was wondering if you > > > would be up for beta-testing a patch for this? > > > > Specifically this patch seems to fix it for me: > > > > > > commit 690dc11498b192db25762de77988224753517c96 > > Author: Konrad Rzeszutek Wilk > > Date: Wed Sep 14 05:10:00 2011 -0400 > > xen/irq: Alter the locking to be a mutex. > > I'll try to apply this to fedora's xen src rpm over the weekend. In case it > doesn't apply, would you remind me of the git commands for the code you > applied this patch to? Thanx. I just save the email in some mbox file and then do git am < and it should automatically add it. Or you can just do patch -p1 and it will apply it too. _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel From xen-devel-bounces@lists.xensource.com Wed Sep 14 15:27:37 2011 Return-path: Envelope-to: www-data@lists.xensource.com Delivery-date: Wed, 14 Sep 2011 15:27:37 -0700 Received: from localhost ([127.0.0.1] helo=lists.colo.xensource.com) by lists.xensource.com with esmtp (Exim 4.43) id 1R3xvd-0003Tb-0C; Wed, 14 Sep 2011 15:27:37 -0700 Received: from mail21.messagelabs.com ([85.158.143.35]) by lists.xensource.com with esmtp (Exim 4.43) id 1R3xuo-0003H5-E2 for xen-devel@lists.xensource.com; Wed, 14 Sep 2011 15:26:47 -0700 X-Env-Sender: pasik@iki.fi X-Msg-Ref: server-10.tower-21.messagelabs.com!1316039188!54143042!1 X-Originating-IP: [192.89.123.25] X-StarScan-Version: 6.4.1; banners=-,-,- X-VirusChecked: Checked Received: (qmail 19522 invoked from network); 14 Sep 2011 22:26:29 -0000 Received: from smtp.tele.fi (HELO smtp.tele.fi) (192.89.123.25) by server-10.tower-21.messagelabs.com with DHE-RSA-AES256-SHA encrypted SMTP; 14 Sep 2011 22:26:29 -0000 X-Originating-Ip: [194.89.68.22] Received: from ydin.reaktio.net (reaktio.net [194.89.68.22]) by smtp.tele.fi (Postfix) with ESMTP id BE14D1B53; Thu, 15 Sep 2011 01:26:41 +0300 (EEST) Received: by ydin.reaktio.net (Postfix, from userid 1001) id 914BF200DB; Thu, 15 Sep 2011 01:26:41 +0300 (EEST) Date: Thu, 15 Sep 2011 01:26:41 +0300 From: Pasi =?iso-8859-1?Q?K=E4rkk=E4inen?= To: Tobias Geiger Subject: Re: [Xen-devel] Signed GPLPV drivers available for download Message-ID: <20110914222641.GU12984@reaktio.net> References: <201109090950.05043.muehlenhoff@univention.de> <201109141803.04514.tobias.geiger@vido.info> <201109141814.29461.tobias.geiger@vido.info> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <201109141814.29461.tobias.geiger@vido.info> User-Agent: Mutt/1.5.18 (2008-05-17) Cc: xen-devel@lists.xensource.com X-BeenThere: xen-devel@lists.xensource.com X-Mailman-Version: 2.1.5 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xensource.com Errors-To: xen-devel-bounces@lists.xensource.com On Wed, Sep 14, 2011 at 06:14:28PM +0200, Tobias Geiger wrote: > Am Mittwoch, 14. September 2011, 18:03:04 schrieb Tobias Geiger: > > - really better read-performance WITH gplpv, but much worse > > write-performance: here is the performance without gplpv: > > well, after reviewing my own screenshots i declare even the readperformance > gets worse after installing GPLPV drivers, not only the writeperformance... > > Any hints on that ?! i remember this not being the case with windows xp > iirc... > Are your partitions aligned properly? if not, that'll cause a big performance hit. -- Pasi _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel From xen-devel-bounces@lists.xensource.com Wed Sep 14 15:29:52 2011 Return-path: Envelope-to: www-data@lists.xensource.com Delivery-date: Wed, 14 Sep 2011 15:29:52 -0700 Received: from localhost ([127.0.0.1] helo=lists.colo.xensource.com) by lists.xensource.com with esmtp (Exim 4.43) id 1R3xxn-0003ra-N1; Wed, 14 Sep 2011 15:29:52 -0700 Received: from mail27.messagelabs.com ([193.109.254.147]) by lists.xensource.com with esmtp (Exim 4.43) id 1R3xx3-0003fm-JQ for xen-devel@lists.xensource.com; Wed, 14 Sep 2011 15:29:06 -0700 X-Env-Sender: konrad@oracle.com X-Msg-Ref: server-11.tower-27.messagelabs.com!1316039333!37447134!1 X-Originating-IP: [141.146.126.227] X-StarScan-Version: 6.4.1; banners=-,-,- X-VirusChecked: Checked Received: (qmail 16385 invoked from network); 14 Sep 2011 22:28:55 -0000 Received: from acsinet15.oracle.com (HELO acsinet15.oracle.com) (141.146.126.227) by server-11.tower-27.messagelabs.com with DHE-RSA-AES256-SHA encrypted SMTP; 14 Sep 2011 22:28:55 -0000 Received: from rtcsinet21.oracle.com (rtcsinet21.oracle.com [66.248.204.29]) by acsinet15.oracle.com (Switch-3.4.4/Switch-3.4.4) with ESMTP id p8EMSvrk019178 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Wed, 14 Sep 2011 22:28:59 GMT Received: from acsmt357.oracle.com (acsmt357.oracle.com [141.146.40.157]) by rtcsinet21.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id p8EMSucx009452 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 14 Sep 2011 22:28:57 GMT Received: from abhmt119.oracle.com (abhmt119.oracle.com [141.146.116.71]) by acsmt357.oracle.com (8.12.11.20060308/8.12.11) with ESMTP id p8EMSpkR014067; Wed, 14 Sep 2011 17:28:51 -0500 Received: from oracle.com (/209.6.55.207) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Wed, 14 Sep 2011 15:28:51 -0700 Received: by oracle.com (Postfix, from userid 1000) id AF2D91362; Wed, 14 Sep 2011 18:28:50 -0400 (EDT) Date: Wed, 14 Sep 2011 18:28:50 -0400 From: Konrad Rzeszutek Wilk To: Anthony Wright Subject: Re: [Xen-devel] VM hangs during boot on 3.0.4 dom0 kernel, works on alternative hardware Message-ID: <20110914222850.GA4486@phenom.oracle.com> References: <4E6BCDA9.3030700@overnetdata.com> <8813601.2.1315907560404.JavaMail.root@zimbra.overnetdata.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <8813601.2.1315907560404.JavaMail.root@zimbra.overnetdata.com> User-Agent: Mutt/1.5.21 (2010-09-15) X-Source-IP: rtcsinet21.oracle.com [66.248.204.29] X-CT-RefId: str=0001.0A090203.4E712AAC.0033,ss=1,re=0.000,fgs=0 Cc: xen-devel@lists.xensource.com X-BeenThere: xen-devel@lists.xensource.com X-Mailman-Version: 2.1.5 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xensource.com Errors-To: xen-devel-bounces@lists.xensource.com On Tue, Sep 13, 2011 at 10:52:40AM +0100, Anthony Wright wrote: > > > ----- Original Message ----- > > On 06/09/2011 17:16, Konrad Rzeszutek Wilk wrote: > > > On Mon, Sep 05, 2011 at 11:31:16AM +0100, Anthony Wright wrote: > > >> I have two machines with identical Dom0's and DomUs, but different > > >> hardware. The Dom0 has a patch which I produced myself based on the > > >> "Re: > > >> [Xen-devel] Kernel bug from 3.0 (was phy disks and vifs timing out > > >> in > > >> DomU)" thread. The patch calls vmalloc_sync_all after every > > >> alloc_vm_area, and I realise this isn't the best solution, but it > > >> allowed me to move forward. > > > > > >> The patch fixes the problem I had on one machine, so that now the > > >> VMs > > >> boot correctly, but I have another system with an identical setup > > >> (identical Dom0 & DomU kernels, identical startup for DomU) and the > > >> VM > > >> fails to start. I have attached a copy of the console log from the > > >> good > > >> VM and the bad VM. > > > And what does the dom0 and xen hypervisor log give you? > > > > > > It looks to be hanging at identifying the CPU - is the hardware > > > quite different from one setup to another? Have you toyed with > > > using the cpuid flag in the guest to mimic the lowest CPU type? > > I've found a solution to my problem. The PV DomU was running a 32 bit > > linux kernel version 2.6.30.1. I hoped that a new kernel would be able > > to handle to CPU more effectively, and so I upgraded my DomU kernel to > > 3.0.4, and now the DomU boots. > > > > This solves the problem for me, but I'm slightly concerned that my > > original kernel wouldn't work with this CPU (the CPU type for the > > kernel > > builds is set to Pentium Pro). I'll try the 2.6.30.1 kernel on bare > > metal on monday to try to see if this is a xen/Dom0 kernel issue or a > > CPU/DomU issue. > > > > Anthony > I've tried the 2.6.30.1 kernel on bare metal and it boots correctly, so it looks like some xen/Dom0 interaction is causing it to fail when run as a DomU. I have a work around (upgrading to 3.0.4 kernel), so it's not affecting me but I'm happy to do any diagnostics to help identify the cause of the problem. > That is OK. I don't we would have the time to actually figure out such and old kernel, or to backport the patch. _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel From xen-users-bounces@lists.xensource.com Wed Sep 14 16:08:02 2011 Return-path: Envelope-to: www-data@lists.xensource.com Delivery-date: Wed, 14 Sep 2011 16:08:02 -0700 Received: from localhost ([127.0.0.1] helo=lists.colo.xensource.com) by lists.xensource.com with esmtp (Exim 4.43) id 1R3yYk-0005Au-SN; Wed, 14 Sep 2011 16:08:02 -0700 Received: from mail182.messagelabs.com ([85.158.139.83]) by lists.xensource.com with smtp (Exim 4.43) id 1R3yWf-0004pY-Eq for xen-users@lists.xensource.com; Wed, 14 Sep 2011 16:05:57 -0700 X-Env-Sender: jim_burn@bellsouth.net X-Msg-Ref: server-11.tower-182.messagelabs.com!1316041549!18374022!1 X-Originating-IP: [98.139.44.150] X-StarScan-Version: 6.4.1; banners=-,-,- X-VirusChecked: Checked Received: (qmail 27758 invoked from network); 14 Sep 2011 23:05:50 -0000 Received: from nm23.access.bullet.mail.sp2.yahoo.com (HELO nm23.access.bullet.mail.sp2.yahoo.com) (98.139.44.150) by server-11.tower-182.messagelabs.com with SMTP; 14 Sep 2011 23:05:50 -0000 Received: from [98.139.44.99] by nm23.access.bullet.mail.sp2.yahoo.com with NNFMP; 14 Sep 2011 23:05:49 -0000 Received: from [98.139.44.71] by tm4.access.bullet.mail.sp2.yahoo.com with NNFMP; 14 Sep 2011 23:05:49 -0000 Received: from [127.0.0.1] by omp1008.access.mail.sp2.yahoo.com with NNFMP; 14 Sep 2011 23:05:49 -0000 X-Yahoo-Newman-Id: 97295.24527.bm@omp1008.access.mail.sp2.yahoo.com Received: (qmail 55768 invoked from network); 14 Sep 2011 23:05:48 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=bellsouth.net; s=s1024; t=1316041548; bh=yhRzz3Eaaq6GZIMsjTCDHlsjREwvRUAtmoe6Kv7xTN4=; h=X-Yahoo-Newman-Property:X-YMail-OSG:X-Yahoo-SMTP:Received:From:To:Cc:Subject:Date:Message-ID:User-Agent:In-Reply-To:References:MIME-Version:Content-Transfer-Encoding:Content-Type; b=V7SfmvZ3ziEOhNiMWW8qQkgrnfHUYjPIdCMpbFVGmklY8SNPb9jAtbra5PdQr+xZra3cWstwfU6ezTmeny18aTffg0PM8N9SSpVUsH7vrl6KU3DL28zNfl9nAPSy2oDLASE9vJ4RWIVO/KcbMMs7x0rH8da+zlroI2aGZCKA9F0= X-Yahoo-Newman-Property: ymail-3 X-YMail-OSG: g438fJYVM1mZydx9xEPM.AFNQOqgTuytpGGfGDDDaMHgqQ6 NJoKcnn9e4XRy2npmhExWY6NSLBNIAi_1g73AxhLmWlLhU8MXuqAqQE0ddLn CmO223qmEvxgAW9XvAXGNK.S6rGx1V9Lxnk6JfSYcayUduDGzs7MZnZHn6o6 9lJTjNu5JJRL.ozqxqfkoTwXihdE1OTsnjokK02153eJF9xbDovYpeqEsqOk Ogcg7VIE17VDDvcLIJl21PDSJjnEV41lQBvLQ.QHlsfcGcRmv3lZLoq_4Tqm 4vjuXeViB_hnVm0uGezSUnSH3e0VHx8g8fOYWQM2aTHa7jRoflpFp9eDflrW VQX4PrpNIKRHwhFsc.1Hv8vIsv8813D4XlczJ2TLGWdm_50Fj0tX2i6VwLju SXEjKE4XiUpDkQ_C5JDgjFT18jel0ylVrp4MRYLrOZRN32xxcT.i26gnrkc4 PCg9YcfQfs7K3lB82UZBuAEHESjwM5jY3NFUz2jqUPX80s6fc9c2e_3rwUj6 HYhWZgg-- X-Yahoo-SMTP: g0AhWW2swBA2djJKuhuwxPlPqLrHlDrycdPnfR9kZNrpKCA- Received: from dell4550.localnet (jim_burn@184.36.206.170 with plain) by smtp108.sbc.mail.ne1.yahoo.com with SMTP; 14 Sep 2011 16:05:47 -0700 PDT From: jim burns To: Konrad Rzeszutek Wilk Subject: Re: [Xen-devel] Re: [Xen-users] Continuing BUG:-iness booting Fedora Rawhide 3.1.0-rc's (was Summary: Experiences setting up a debug serial port) Date: Wed, 14 Sep 2011 19:05:39 -0400 Message-ID: <9358239.Ay1gI4NGlT@dell4550> User-Agent: KMail/4.7.1 (Linux/2.6.37.6-0.7-default; KDE/4.7.1; i686; ; ) In-Reply-To: <20110914221254.GB3742@phenom.oracle.com> References: <201107231426.56811.jim_burn@bellsouth.net> <1551334.UG67O7dPfn@dell4550> <20110914221254.GB3742@phenom.oracle.com> MIME-Version: 1.0 Content-Transfer-Encoding: 7Bit Content-Type: text/plain; charset="us-ascii" Cc: xen-devel@lists.xensource.com, Fedora Xen List , Pasi =?ISO-8859-1?Q?K=E4rkk=E4inen?= , Ian Campbell , Todd Deshane , xen-users@lists.xensource.com X-BeenThere: xen-users@lists.xensource.com X-Mailman-Version: 2.1.5 Precedence: list List-Id: Xen user discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-users-bounces@lists.xensource.com Errors-To: xen-users-bounces@lists.xensource.com On Wed September 14 2011, 6:12:54 PM, Konrad Rzeszutek Wilk wrote: > > I'll try to apply this to fedora's xen src rpm over the weekend. In case > > it doesn't apply, would you remind me of the git commands for the code > > you applied this patch to? Thanx. > > I just save the email in some mbox file and then do > git am < and it should automatically add it. > > Or you can just do patch -p1 and it will apply it too. No - I understand patching. I meant what version of the xen code did you patch? Something like: $ cd /usr/src $ hg clone http://bits.xensource.com/xen-unstable.hg xen-unstable.hg $ cd xen-unstable.hg $ sudo make xen $ sudo make tools $ sudo make install-xen $ sudo make install-tools or some other version? (Again, if I can't get it to apply to the fedora src rpm cleanly.) Thanx. _______________________________________________ Xen-users mailing list Xen-users@lists.xensource.com http://lists.xensource.com/xen-users From xen-devel-bounces@lists.xensource.com Wed Sep 14 16:11:17 2011 Return-path: Envelope-to: www-data@lists.xensource.com Delivery-date: Wed, 14 Sep 2011 16:11:17 -0700 Received: from localhost ([127.0.0.1] helo=lists.colo.xensource.com) by lists.xensource.com with esmtp (Exim 4.43) id 1R3ybt-00066t-8E; Wed, 14 Sep 2011 16:11:17 -0700 Received: from mail174.messagelabs.com ([85.158.138.51]) by lists.xensource.com with smtp (Exim 4.43) id 1R3ybQ-0005uC-4p for xen-devel@lists.xensource.com; Wed, 14 Sep 2011 16:10:49 -0700 X-Env-Sender: tobias.geiger@vido.info X-Msg-Ref: server-3.tower-174.messagelabs.com!1316041845!25396881!1 X-Originating-IP: [78.47.43.171] X-StarScan-Version: 6.4.1; banners=-,-,- X-VirusChecked: Checked Received: (qmail 10591 invoked from network); 14 Sep 2011 23:10:45 -0000 Received: from www.vido.info (HELO mail.vido.info) (78.47.43.171) by server-3.tower-174.messagelabs.com with SMTP; 14 Sep 2011 23:10:45 -0000 Received: from localhost (ip6-localhost [127.0.0.1]) by mail.vido.info (Postfix) with ESMTP id EAA6DD34811; Thu, 15 Sep 2011 01:10:44 +0200 (CEST) X-Virus-Scanned: by amavis at mail.vido.info Received: from mail.vido.info ([127.0.0.1]) by localhost (mail.vido.info [127.0.0.1]) (amavisd-new, port 10024) with LMTP id jmVrmw3BrMLc; Thu, 15 Sep 2011 01:10:37 +0200 (CEST) Received: from pc.localnet (HSI-KBW-085-216-123-237.hsi.kabelbw.de [85.216.123.237]) by mail.vido.info (Postfix) with ESMTPSA id 41252D34107; Thu, 15 Sep 2011 01:10:37 +0200 (CEST) From: Tobias Geiger Organization: VIDO IT Service To: Pasi =?iso-8859-1?q?K=E4rkk=E4inen?= Subject: Re: [Xen-devel] Signed GPLPV drivers available for download Date: Thu, 15 Sep 2011 01:10:36 +0200 User-Agent: KMail/1.13.7 (Linux/3.1.0-rc2; KDE/4.6.5; x86_64; ; ) References: <201109090950.05043.muehlenhoff@univention.de> <201109141814.29461.tobias.geiger@vido.info> <20110914222641.GU12984@reaktio.net> In-Reply-To: <20110914222641.GU12984@reaktio.net> X-Face: xgskrgi{ =?iso-8859-1?q?H=0A=09F4fZpv=7C5DziL=5FT=27Mwu=5Bq=60AwB=7Ejd?=(QE]|akb9=VF%p5d_iR(ZNP[`l`EMmF*nohYL|:=< =?iso-8859-1?q?nd=0A=09?=kM`7<4"> MIME-Version: 1.0 Content-Type: Text/Plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Message-Id: <201109150110.36522.tobias.geiger@vido.info> Cc: xen-devel@lists.xensource.com X-BeenThere: xen-devel@lists.xensource.com X-Mailman-Version: 2.1.5 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xensource.com Errors-To: xen-devel-bounces@lists.xensource.com Disk /dev/nbd0: 193.3 GB, 193273528320 bytes 255 heads, 63 sectors/track, 23497 cylinders, total 377487360 sectors Units =3D sectors of 1 * 512 =3D 512 bytes Sector size (logical/physical): 512 bytes / 512 bytes I/O size (minimum/optimal): 512 bytes / 512 bytes Disk identifier: 0x047328a3 Device Boot Start End Blocks Id System /dev/nbd0p1 * 2048 206847 102400 7 HPFS/NTFS/exFAT /dev/nbd0p2 206848 377485311 188639232 7 HPFS/NTFS/exFAT seems to be proper aligned... Am Donnerstag 15 September 2011, 00:26:41 schrieb Pasi K=E4rkk=E4inen: > On Wed, Sep 14, 2011 at 06:14:28PM +0200, Tobias Geiger wrote: > > Am Mittwoch, 14. September 2011, 18:03:04 schrieb Tobias Geiger: > > > - really better read-performance WITH gplpv, but much worse > >=20 > > > write-performance: here is the performance without gplpv: > > well, after reviewing my own screenshots i declare even the > > readperformance gets worse after installing GPLPV drivers, not only the > > writeperformance... > >=20 > > Any hints on that ?! i remember this not being the case with windows xp > > iirc... >=20 > Are your partitions aligned properly? if not, that'll cause a big > performance hit. >=20 > -- Pasi _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel From xen-devel-bounces@lists.xensource.com Wed Sep 14 16:40:17 2011 Return-path: Envelope-to: www-data@lists.xensource.com Delivery-date: Wed, 14 Sep 2011 16:40:17 -0700 Received: from localhost ([127.0.0.1] helo=lists.colo.xensource.com) by lists.xensource.com with esmtp (Exim 4.43) id 1R3z3w-00070d-KG; Wed, 14 Sep 2011 16:40:17 -0700 Received: from mail21.messagelabs.com ([85.158.143.35]) by lists.xensource.com with esmtp (Exim 4.43) id 1R3z2z-0006o8-98; Wed, 14 Sep 2011 16:39:17 -0700 X-Env-Sender: m.a.young@durham.ac.uk X-Msg-Ref: server-4.tower-21.messagelabs.com!1316043519!60245691!1 X-Originating-IP: [129.234.248.2] X-StarScan-Version: 6.4.1; banners=-,-,- X-VirusChecked: Checked Received: (qmail 25414 invoked from network); 14 Sep 2011 23:38:39 -0000 Received: from hermes2.dur.ac.uk (HELO hermes2.dur.ac.uk) (129.234.248.2) by server-4.tower-21.messagelabs.com with DHE-RSA-AES256-SHA encrypted SMTP; 14 Sep 2011 23:38:39 -0000 Received: from smtphost1.dur.ac.uk (smtphost1.dur.ac.uk [129.234.252.1]) by hermes2.dur.ac.uk (8.13.8/8.13.7) with ESMTP id p8ENcrD7012448; Thu, 15 Sep 2011 00:38:57 +0100 Received: from vega4.dur.ac.uk (vega4.dur.ac.uk [129.234.250.132]) by smtphost1.dur.ac.uk (8.13.8/8.13.7) with ESMTP id p8ENcaeA007786 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 15 Sep 2011 00:38:36 +0100 Received: from vega4.dur.ac.uk (localhost [127.0.0.1]) by vega4.dur.ac.uk (8.14.4/8.11.1) with ESMTP id p8ENcZjQ027563; Thu, 15 Sep 2011 00:38:36 +0100 Received: from localhost (dcl0may@localhost) by vega4.dur.ac.uk (8.14.4/8.14.4/Submit) with ESMTP id p8ENcYbd027559; Thu, 15 Sep 2011 00:38:34 +0100 Date: Thu, 15 Sep 2011 00:38:26 +0100 (BST) From: M A Young To: Konrad Rzeszutek Wilk Subject: Re: [Fedora-xen] [Xen-devel] Re: [Xen-users] Continuing BUG:-iness booting Fedora Rawhide 3.1.0-rc's (was Summary: Experiences setting up a debug serial port) In-Reply-To: <20110914221254.GB3742@phenom.oracle.com> Message-ID: References: <201107231426.56811.jim_burn@bellsouth.net> <20110914090806.GD25628@phenom.oracle.com> <20110914105711.GA16284@phenom.oracle.com> <1551334.UG67O7dPfn@dell4550> <20110914221254.GB3742@phenom.oracle.com> User-Agent: Alpine 2.02 (LFD 1266 2009-07-14) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; format=flowed; charset=US-ASCII X-DurhamAcUk-MailScanner: Found to be clean, Found to be clean X-DurhamAcUk-MailScanner-ID: p8ENcrD7012448 Cc: Ian Campbell , xen-devel@lists.xensource.com, xen-users@lists.xensource.com, Fedora Xen List , jim burns X-BeenThere: xen-devel@lists.xensource.com X-Mailman-Version: 2.1.5 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xensource.com Errors-To: xen-devel-bounces@lists.xensource.com On Wed, 14 Sep 2011, Konrad Rzeszutek Wilk wrote: > On Wed, Sep 14, 2011 at 05:07:28PM -0400, jim burns wrote: >> On Wed September 14 2011, 6:57:11 AM, Konrad Rzeszutek Wilk wrote: >>> On Wed, Sep 14, 2011 at 05:08:06AM -0400, Konrad Rzeszutek Wilk wrote: >>> >>> commit 690dc11498b192db25762de77988224753517c96 >>> Author: Konrad Rzeszutek Wilk >>> Date: Wed Sep 14 05:10:00 2011 -0400 >>> xen/irq: Alter the locking to be a mutex. >> >> I'll try to apply this to fedora's xen src rpm over the weekend. In case it >> doesn't apply, would you remind me of the git commands for the code you >> applied this patch to? Thanx. > > I just save the email in some mbox file and then do > git am < and it should automatically add it. > > Or you can just do patch -p1 and it will apply it too. I have a (temporary) F17 kernel with the patch from http://oss.oracle.com/git/kwilk/xen.git/?p=kwilk/xen.git;a=commit;h=a7079a6404ed2106315327fff6be3464d10814e7 (which I assume is the same patch) applied building at http://koji.fedoraproject.org/koji/taskinfo?taskID=3352367 if you want to test it. Michael Young _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel From xen-devel-bounces@lists.xensource.com Wed Sep 14 17:43:45 2011 Return-path: Envelope-to: www-data@lists.xensource.com Delivery-date: Wed, 14 Sep 2011 17:43:45 -0700 Received: from localhost ([127.0.0.1] helo=lists.colo.xensource.com) by lists.xensource.com with esmtp (Exim 4.43) id 1R403M-0001q6-V4; Wed, 14 Sep 2011 17:43:44 -0700 Received: from mail216.messagelabs.com ([85.158.143.99]) by lists.xensource.com with esmtp (Exim 4.43) id 1R402V-0001cK-I3 for xen-devel@lists.xensource.com; Wed, 14 Sep 2011 17:42:51 -0700 X-Env-Sender: jeremy@goop.org X-Msg-Ref: server-3.tower-216.messagelabs.com!1316047366!17273467!1 X-Originating-IP: [74.207.240.146] X-StarScan-Version: 6.4.1; banners=-,-,- X-VirusChecked: Checked Received: (qmail 16700 invoked from network); 15 Sep 2011 00:42:48 -0000 Received: from claw.goop.org (HELO claw.goop.org) (74.207.240.146) by server-3.tower-216.messagelabs.com with DHE-RSA-AES256-SHA encrypted SMTP; 15 Sep 2011 00:42:48 -0000 Received: from saboo.goop.org (unknown [IPv6:2001:470:1f05:899:f0ec:7fff:fed1:2097]) (Authenticated sender: smtp-saboo) by claw.goop.org (Postfix) with ESMTPSA id A2C5B911A; Wed, 14 Sep 2011 17:42:44 -0700 (PDT) Received: by saboo.goop.org (Postfix, from userid 500) id 386DD20CBA; Wed, 14 Sep 2011 17:31:44 -0700 (PDT) From: Jeremy Fitzhardinge To: "H. Peter Anvin" Date: Wed, 14 Sep 2011 17:31:39 -0700 Message-Id: <49abff7b6fdc629c601387610beaa834af2c3085.1315878463.git.jeremy.fitzhardinge@citrix.com> X-Mailer: git-send-email 1.7.6 In-Reply-To: References: In-Reply-To: References: Cc: Marcelo Tosatti , Nick Piggin , KVM , Peter Zijlstra , the arch/x86 maintainers , Linux Kernel Mailing List , Andi Kleen , Avi Kivity , Jeremy Fitzhardinge , Ingo Molnar , Linus Torvalds , Xen Devel Subject: [Xen-devel] [PATCH 07/10] x86/ticketlocks: when paravirtualizing ticket locks, increment by 2 X-BeenThere: xen-devel@lists.xensource.com X-Mailman-Version: 2.1.5 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xensource.com Errors-To: xen-devel-bounces@lists.xensource.com From: Jeremy Fitzhardinge Increment ticket head/tails by 2 rather than 1 to leave the LSB free to store a "is in slowpath state" bit. This halves the number of possible CPUs for a given ticket size, but this shouldn't matter in practice - kernels built for 32k+ CPU systems are probably specially built for the hardware rather than a generic distro kernel. Signed-off-by: Jeremy Fitzhardinge --- arch/x86/include/asm/spinlock.h | 16 ++++++++-------- arch/x86/include/asm/spinlock_types.h | 10 +++++++++- 2 files changed, 17 insertions(+), 9 deletions(-) diff --git a/arch/x86/include/asm/spinlock.h b/arch/x86/include/asm/spinlock.h index 98fe202..40c90aa 100644 --- a/arch/x86/include/asm/spinlock.h +++ b/arch/x86/include/asm/spinlock.h @@ -78,7 +78,7 @@ static __always_inline void __ticket_unlock_kick(struct arch_spinlock *lock, __t */ static __always_inline void arch_spin_lock(struct arch_spinlock *lock) { - register struct __raw_tickets inc = { .tail = 1 }; + register struct __raw_tickets inc = { .tail = TICKET_LOCK_INC }; inc = xadd(&lock->tickets, inc); @@ -104,7 +104,7 @@ static __always_inline int arch_spin_trylock(arch_spinlock_t *lock) if (old.tickets.head != old.tickets.tail) return 0; - new.head_tail = old.head_tail + (1 << TICKET_SHIFT); + new.head_tail = old.head_tail + (TICKET_LOCK_INC << TICKET_SHIFT); /* cmpxchg is a full barrier, so nothing can move before it */ return cmpxchg(&lock->head_tail, old.head_tail, new.head_tail) == old.head_tail; @@ -113,24 +113,24 @@ static __always_inline int arch_spin_trylock(arch_spinlock_t *lock) #if (NR_CPUS < 256) static __always_inline void __ticket_unlock_release(arch_spinlock_t *lock) { - asm volatile(UNLOCK_LOCK_PREFIX "incb %0" + asm volatile(UNLOCK_LOCK_PREFIX "addb %1, %0" : "+m" (lock->head_tail) - : + : "i" (TICKET_LOCK_INC) : "memory", "cc"); } #else static __always_inline void __ticket_unlock_release(arch_spinlock_t *lock) { - asm volatile(UNLOCK_LOCK_PREFIX "incw %0" + asm volatile(UNLOCK_LOCK_PREFIX "addw %1, %0" : "+m" (lock->head_tail) - : + : "i" (TICKET_LOCK_INC) : "memory", "cc"); } #endif static __always_inline void arch_spin_unlock(arch_spinlock_t *lock) { - __ticket_t next = lock->tickets.head + 1; + __ticket_t next = lock->tickets.head + TICKET_LOCK_INC; __ticket_unlock_release(lock); __ticket_unlock_kick(lock, next); @@ -147,7 +147,7 @@ static inline int arch_spin_is_contended(arch_spinlock_t *lock) { struct __raw_tickets tmp = ACCESS_ONCE(lock->tickets); - return ((tmp.tail - tmp.head) & TICKET_MASK) > 1; + return ((tmp.tail - tmp.head) & TICKET_MASK) > TICKET_LOCK_INC; } #define arch_spin_is_contended arch_spin_is_contended diff --git a/arch/x86/include/asm/spinlock_types.h b/arch/x86/include/asm/spinlock_types.h index dbe223d..aa9a205 100644 --- a/arch/x86/include/asm/spinlock_types.h +++ b/arch/x86/include/asm/spinlock_types.h @@ -3,7 +3,13 @@ #include -#if (CONFIG_NR_CPUS < 256) +#ifdef CONFIG_PARAVIRT_SPINLOCKS +#define __TICKET_LOCK_INC 2 +#else +#define __TICKET_LOCK_INC 1 +#endif + +#if (CONFIG_NR_CPUS < (256 / __TICKET_LOCK_INC)) typedef u8 __ticket_t; typedef u16 __ticketpair_t; #else @@ -11,6 +17,8 @@ typedef u16 __ticket_t; typedef u32 __ticketpair_t; #endif +#define TICKET_LOCK_INC ((__ticket_t)__TICKET_LOCK_INC) + #define TICKET_SHIFT (sizeof(__ticket_t) * 8) #define TICKET_MASK ((__ticket_t)((1 << TICKET_SHIFT) - 1)) -- 1.7.6 _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel From xen-devel-bounces@lists.xensource.com Wed Sep 14 17:44:48 2011 Return-path: Envelope-to: www-data@lists.xensource.com Delivery-date: Wed, 14 Sep 2011 17:44:48 -0700 Received: from localhost ([127.0.0.1] helo=lists.colo.xensource.com) by lists.xensource.com with esmtp (Exim 4.43) id 1R404O-0002DB-9Y; Wed, 14 Sep 2011 17:44:48 -0700 Received: from mail216.messagelabs.com ([85.158.143.99]) by lists.xensource.com with esmtp (Exim 4.43) id 1R402W-0001cL-Hg for xen-devel@lists.xensource.com; Wed, 14 Sep 2011 17:42:52 -0700 X-Env-Sender: jeremy@goop.org X-Msg-Ref: server-15.tower-216.messagelabs.com!1316047366!17842810!1 X-Originating-IP: [74.207.240.146] X-StarScan-Version: 6.4.1; banners=-,-,- X-VirusChecked: Checked Received: (qmail 5929 invoked from network); 15 Sep 2011 00:42:48 -0000 Received: from claw.goop.org (HELO claw.goop.org) (74.207.240.146) by server-15.tower-216.messagelabs.com with DHE-RSA-AES256-SHA encrypted SMTP; 15 Sep 2011 00:42:48 -0000 Received: from saboo.goop.org (unknown [IPv6:2001:470:1f05:899:f0ec:7fff:fed1:2097]) (Authenticated sender: smtp-saboo) by claw.goop.org (Postfix) with ESMTPSA id B6F5F911C; Wed, 14 Sep 2011 17:42:44 -0700 (PDT) Received: by saboo.goop.org (Postfix, from userid 500) id 2959A20CA9; Wed, 14 Sep 2011 17:31:44 -0700 (PDT) From: Jeremy Fitzhardinge To: "H. Peter Anvin" Date: Wed, 14 Sep 2011 17:31:36 -0700 Message-Id: <19f816e61e8ca8a0589f0a255112dd72d7e17f9f.1315878463.git.jeremy.fitzhardinge@citrix.com> X-Mailer: git-send-email 1.7.6 In-Reply-To: References: In-Reply-To: References: Cc: Marcelo Tosatti , Nick Piggin , KVM , Peter Zijlstra , the arch/x86 maintainers , Linux Kernel Mailing List , Andi Kleen , Avi Kivity , Jeremy Fitzhardinge , Ingo Molnar , Linus Torvalds , Xen Devel Subject: [Xen-devel] [PATCH 04/10] x86/ticketlock: collapse a layer of functions X-BeenThere: xen-devel@lists.xensource.com X-Mailman-Version: 2.1.5 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xensource.com Errors-To: xen-devel-bounces@lists.xensource.com From: Jeremy Fitzhardinge Now that the paravirtualization layer doesn't exist at the spinlock level any more, we can collapse the __ticket_ functions into the arch_ functions. Signed-off-by: Jeremy Fitzhardinge --- arch/x86/include/asm/spinlock.h | 35 +++++------------------------------ 1 files changed, 5 insertions(+), 30 deletions(-) diff --git a/arch/x86/include/asm/spinlock.h b/arch/x86/include/asm/spinlock.h index 860fc4b..98fe202 100644 --- a/arch/x86/include/asm/spinlock.h +++ b/arch/x86/include/asm/spinlock.h @@ -76,7 +76,7 @@ static __always_inline void __ticket_unlock_kick(struct arch_spinlock *lock, __t * in the high part, because a wide xadd increment of the low part would carry * up and contaminate the high part. */ -static __always_inline void __ticket_spin_lock(struct arch_spinlock *lock) +static __always_inline void arch_spin_lock(struct arch_spinlock *lock) { register struct __raw_tickets inc = { .tail = 1 }; @@ -96,7 +96,7 @@ static __always_inline void __ticket_spin_lock(struct arch_spinlock *lock) out: barrier(); /* make sure nothing creeps before the lock is taken */ } -static __always_inline int __ticket_spin_trylock(arch_spinlock_t *lock) +static __always_inline int arch_spin_trylock(arch_spinlock_t *lock) { arch_spinlock_t old, new; @@ -128,7 +128,7 @@ static __always_inline void __ticket_unlock_release(arch_spinlock_t *lock) } #endif -static __always_inline void __ticket_spin_unlock(arch_spinlock_t *lock) +static __always_inline void arch_spin_unlock(arch_spinlock_t *lock) { __ticket_t next = lock->tickets.head + 1; @@ -136,46 +136,21 @@ static __always_inline void __ticket_spin_unlock(arch_spinlock_t *lock) __ticket_unlock_kick(lock, next); } -static inline int __ticket_spin_is_locked(arch_spinlock_t *lock) +static inline int arch_spin_is_locked(arch_spinlock_t *lock) { struct __raw_tickets tmp = ACCESS_ONCE(lock->tickets); return !!(tmp.tail ^ tmp.head); } -static inline int __ticket_spin_is_contended(arch_spinlock_t *lock) +static inline int arch_spin_is_contended(arch_spinlock_t *lock) { struct __raw_tickets tmp = ACCESS_ONCE(lock->tickets); return ((tmp.tail - tmp.head) & TICKET_MASK) > 1; } - -static inline int arch_spin_is_locked(arch_spinlock_t *lock) -{ - return __ticket_spin_is_locked(lock); -} - -static inline int arch_spin_is_contended(arch_spinlock_t *lock) -{ - return __ticket_spin_is_contended(lock); -} #define arch_spin_is_contended arch_spin_is_contended -static __always_inline void arch_spin_lock(arch_spinlock_t *lock) -{ - __ticket_spin_lock(lock); -} - -static __always_inline int arch_spin_trylock(arch_spinlock_t *lock) -{ - return __ticket_spin_trylock(lock); -} - -static __always_inline void arch_spin_unlock(arch_spinlock_t *lock) -{ - __ticket_spin_unlock(lock); -} - static __always_inline void arch_spin_lock_flags(arch_spinlock_t *lock, unsigned long flags) { -- 1.7.6 _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel From xen-devel-bounces@lists.xensource.com Wed Sep 14 17:45:34 2011 Return-path: Envelope-to: www-data@lists.xensource.com Delivery-date: Wed, 14 Sep 2011 17:45:34 -0700 Received: from localhost ([127.0.0.1] helo=lists.colo.xensource.com) by lists.xensource.com with esmtp (Exim 4.43) id 1R4058-0002Zu-Mv; Wed, 14 Sep 2011 17:45:34 -0700 Received: from mail174.messagelabs.com ([85.158.138.51]) by lists.xensource.com with esmtp (Exim 4.43) id 1R402Y-0001cR-K2 for xen-devel@lists.xensource.com; Wed, 14 Sep 2011 17:42:54 -0700 X-Env-Sender: jeremy@goop.org X-Msg-Ref: server-7.tower-174.messagelabs.com!1316047369!31433934!1 X-Originating-IP: [74.207.240.146] X-StarScan-Version: 6.4.1; banners=-,-,- X-VirusChecked: Checked Received: (qmail 11963 invoked from network); 15 Sep 2011 00:42:51 -0000 Received: from claw.goop.org (HELO claw.goop.org) (74.207.240.146) by server-7.tower-174.messagelabs.com with DHE-RSA-AES256-SHA encrypted SMTP; 15 Sep 2011 00:42:51 -0000 Received: from saboo.goop.org (unknown [IPv6:2001:470:1f05:899:f0ec:7fff:fed1:2097]) (Authenticated sender: smtp-saboo) by claw.goop.org (Postfix) with ESMTPSA id 04A6C911E; Wed, 14 Sep 2011 17:42:45 -0700 (PDT) Received: by saboo.goop.org (Postfix, from userid 500) id 25E3C20CA3; Wed, 14 Sep 2011 17:31:44 -0700 (PDT) From: Jeremy Fitzhardinge To: "H. Peter Anvin" Date: Wed, 14 Sep 2011 17:31:35 -0700 Message-Id: <0764ae5eb0d920547fc43bdf5ac2efc7a79a4e98.1315878463.git.jeremy.fitzhardinge@citrix.com> X-Mailer: git-send-email 1.7.6 In-Reply-To: References: In-Reply-To: References: Cc: Marcelo Tosatti , Nick Piggin , KVM , Peter Zijlstra , the arch/x86 maintainers , Linux Kernel Mailing List , Andi Kleen , Avi Kivity , Jeremy Fitzhardinge , Ingo Molnar , Linus Torvalds , Xen Devel Subject: [Xen-devel] [PATCH 03/10] x86/ticketlock: don't inline _spin_unlock when using paravirt spinlocks X-BeenThere: xen-devel@lists.xensource.com X-Mailman-Version: 2.1.5 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xensource.com Errors-To: xen-devel-bounces@lists.xensource.com From: Jeremy Fitzhardinge The code size expands somewhat, and its probably better to just call a function rather than inline it. Signed-off-by: Jeremy Fitzhardinge --- arch/x86/Kconfig | 3 +++ kernel/Kconfig.locks | 2 +- 2 files changed, 4 insertions(+), 1 deletions(-) diff --git a/arch/x86/Kconfig b/arch/x86/Kconfig index 6a47bb2..1f03f82 100644 --- a/arch/x86/Kconfig +++ b/arch/x86/Kconfig @@ -585,6 +585,9 @@ config PARAVIRT_SPINLOCKS If you are unsure how to answer this question, answer N. +config ARCH_NOINLINE_SPIN_UNLOCK + def_bool PARAVIRT_SPINLOCKS + config PARAVIRT_CLOCK bool diff --git a/kernel/Kconfig.locks b/kernel/Kconfig.locks index 5068e2a..584637b 100644 --- a/kernel/Kconfig.locks +++ b/kernel/Kconfig.locks @@ -125,7 +125,7 @@ config INLINE_SPIN_LOCK_IRQSAVE ARCH_INLINE_SPIN_LOCK_IRQSAVE config INLINE_SPIN_UNLOCK - def_bool !DEBUG_SPINLOCK && (!PREEMPT || ARCH_INLINE_SPIN_UNLOCK) + def_bool !DEBUG_SPINLOCK && (!PREEMPT || ARCH_INLINE_SPIN_UNLOCK) && !ARCH_NOINLINE_SPIN_UNLOCK config INLINE_SPIN_UNLOCK_BH def_bool !DEBUG_SPINLOCK && ARCH_INLINE_SPIN_UNLOCK_BH -- 1.7.6 _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel From xen-devel-bounces@lists.xensource.com Wed Sep 14 17:46:36 2011 Return-path: Envelope-to: www-data@lists.xensource.com Delivery-date: Wed, 14 Sep 2011 17:46:36 -0700 Received: from localhost ([127.0.0.1] helo=lists.colo.xensource.com) by lists.xensource.com with esmtp (Exim 4.43) id 1R4068-0002z9-3i; Wed, 14 Sep 2011 17:46:36 -0700 Received: from mail216.messagelabs.com ([85.158.143.99]) by lists.xensource.com with esmtp (Exim 4.43) id 1R402Z-0001cc-NS for xen-devel@lists.xensource.com; Wed, 14 Sep 2011 17:42:57 -0700 X-Env-Sender: jeremy@goop.org X-Msg-Ref: server-7.tower-216.messagelabs.com!1316047370!18308891!1 X-Originating-IP: [74.207.240.146] X-StarScan-Version: 6.4.1; banners=-,-,- X-VirusChecked: Checked Received: (qmail 32496 invoked from network); 15 Sep 2011 00:42:52 -0000 Received: from claw.goop.org (HELO claw.goop.org) (74.207.240.146) by server-7.tower-216.messagelabs.com with DHE-RSA-AES256-SHA encrypted SMTP; 15 Sep 2011 00:42:52 -0000 Received: from saboo.goop.org (unknown [IPv6:2001:470:1f05:899:f0ec:7fff:fed1:2097]) (Authenticated sender: smtp-saboo) by claw.goop.org (Postfix) with ESMTPSA id 7BB409121; Wed, 14 Sep 2011 17:42:46 -0700 (PDT) Received: by saboo.goop.org (Postfix, from userid 500) id 2107020CA2; Wed, 14 Sep 2011 17:31:44 -0700 (PDT) From: Jeremy Fitzhardinge To: "H. Peter Anvin" Date: Wed, 14 Sep 2011 17:31:34 -0700 Message-Id: <987c9c9edd4e56d29caf55a357ea3a3f94cf4b78.1315878463.git.jeremy.fitzhardinge@citrix.com> X-Mailer: git-send-email 1.7.6 In-Reply-To: References: In-Reply-To: References: Cc: Marcelo Tosatti , Nick Piggin , KVM , Peter Zijlstra , the arch/x86 maintainers , Linux Kernel Mailing List , Andi Kleen , Avi Kivity , Jeremy Fitzhardinge , Ingo Molnar , Linus Torvalds , Xen Devel Subject: [Xen-devel] [PATCH 02/10] x86/spinlocks: replace pv spinlocks with pv ticketlocks X-BeenThere: xen-devel@lists.xensource.com X-Mailman-Version: 2.1.5 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xensource.com Errors-To: xen-devel-bounces@lists.xensource.com From: Jeremy Fitzhardinge Rather than outright replacing the entire spinlock implementation in order to paravirtualize it, keep the ticket lock implementation but add a couple of pvops hooks on the slow patch (long spin on lock, unlocking a contended lock). Ticket locks have a number of nice properties, but they also have some surprising behaviours in virtual environments. They enforce a strict FIFO ordering on cpus trying to take a lock; however, if the hypervisor scheduler does not schedule the cpus in the correct order, the system can waste a huge amount of time spinning until the next cpu can take the lock. (See Thomas Friebel's talk "Prevent Guests from Spinning Around" http://www.xen.org/files/xensummitboston08/LHP.pdf for more details.) To address this, we add two hooks: - __ticket_spin_lock which is called after the cpu has been spinning on the lock for a significant number of iterations but has failed to take the lock (presumably because the cpu holding the lock has been descheduled). The lock_spinning pvop is expected to block the cpu until it has been kicked by the current lock holder. - __ticket_spin_unlock, which on releasing a contended lock (there are more cpus with tail tickets), it looks to see if the next cpu is blocked and wakes it if so. When compiled with CONFIG_PARAVIRT_SPINLOCKS disabled, a set of stub functions causes all the extra code to go away. Signed-off-by: Jeremy Fitzhardinge --- arch/x86/include/asm/paravirt.h | 30 ++-------------- arch/x86/include/asm/paravirt_types.h | 10 ++--- arch/x86/include/asm/spinlock.h | 59 ++++++++++++++++++++++++++------- arch/x86/include/asm/spinlock_types.h | 4 -- arch/x86/kernel/paravirt-spinlocks.c | 15 +------- arch/x86/xen/spinlock.c | 7 +++- 6 files changed, 63 insertions(+), 62 deletions(-) diff --git a/arch/x86/include/asm/paravirt.h b/arch/x86/include/asm/paravirt.h index a7d2db9..76cae7a 100644 --- a/arch/x86/include/asm/paravirt.h +++ b/arch/x86/include/asm/paravirt.h @@ -750,36 +750,14 @@ static inline void __set_fixmap(unsigned /* enum fixed_addresses */ idx, #if defined(CONFIG_SMP) && defined(CONFIG_PARAVIRT_SPINLOCKS) -static inline int arch_spin_is_locked(struct arch_spinlock *lock) +static __always_inline void __ticket_lock_spinning(struct arch_spinlock *lock, __ticket_t ticket) { - return PVOP_CALL1(int, pv_lock_ops.spin_is_locked, lock); + PVOP_VCALL2(pv_lock_ops.lock_spinning, lock, ticket); } -static inline int arch_spin_is_contended(struct arch_spinlock *lock) +static __always_inline void ____ticket_unlock_kick(struct arch_spinlock *lock, __ticket_t ticket) { - return PVOP_CALL1(int, pv_lock_ops.spin_is_contended, lock); -} -#define arch_spin_is_contended arch_spin_is_contended - -static __always_inline void arch_spin_lock(struct arch_spinlock *lock) -{ - PVOP_VCALL1(pv_lock_ops.spin_lock, lock); -} - -static __always_inline void arch_spin_lock_flags(struct arch_spinlock *lock, - unsigned long flags) -{ - PVOP_VCALL2(pv_lock_ops.spin_lock_flags, lock, flags); -} - -static __always_inline int arch_spin_trylock(struct arch_spinlock *lock) -{ - return PVOP_CALL1(int, pv_lock_ops.spin_trylock, lock); -} - -static __always_inline void arch_spin_unlock(struct arch_spinlock *lock) -{ - PVOP_VCALL1(pv_lock_ops.spin_unlock, lock); + PVOP_VCALL2(pv_lock_ops.unlock_kick, lock, ticket); } #endif diff --git a/arch/x86/include/asm/paravirt_types.h b/arch/x86/include/asm/paravirt_types.h index 8e8b9a4..005e24d 100644 --- a/arch/x86/include/asm/paravirt_types.h +++ b/arch/x86/include/asm/paravirt_types.h @@ -327,13 +327,11 @@ struct pv_mmu_ops { }; struct arch_spinlock; +#include + struct pv_lock_ops { - int (*spin_is_locked)(struct arch_spinlock *lock); - int (*spin_is_contended)(struct arch_spinlock *lock); - void (*spin_lock)(struct arch_spinlock *lock); - void (*spin_lock_flags)(struct arch_spinlock *lock, unsigned long flags); - int (*spin_trylock)(struct arch_spinlock *lock); - void (*spin_unlock)(struct arch_spinlock *lock); + void (*lock_spinning)(struct arch_spinlock *lock, __ticket_t ticket); + void (*unlock_kick)(struct arch_spinlock *lock, __ticket_t ticket); }; /* This contains all the paravirt structures: we get a convenient diff --git a/arch/x86/include/asm/spinlock.h b/arch/x86/include/asm/spinlock.h index 972c260..860fc4b 100644 --- a/arch/x86/include/asm/spinlock.h +++ b/arch/x86/include/asm/spinlock.h @@ -37,6 +37,32 @@ # define UNLOCK_LOCK_PREFIX #endif +/* How long a lock should spin before we consider blocking */ +#define SPIN_THRESHOLD (1 << 11) + +#ifndef CONFIG_PARAVIRT_SPINLOCKS + +static __always_inline void __ticket_lock_spinning(struct arch_spinlock *lock, __ticket_t ticket) +{ +} + +static __always_inline void ____ticket_unlock_kick(struct arch_spinlock *lock, __ticket_t ticket) +{ +} + +#endif /* CONFIG_PARAVIRT_SPINLOCKS */ + + +/* + * If a spinlock has someone waiting on it, then kick the appropriate + * waiting cpu. + */ +static __always_inline void __ticket_unlock_kick(struct arch_spinlock *lock, __ticket_t next) +{ + if (unlikely(lock->tickets.tail != next)) + ____ticket_unlock_kick(lock, next); +} + /* * Ticket locks are conceptually two parts, one indicating the current head of * the queue, and the other indicating the current tail. The lock is acquired @@ -50,19 +76,24 @@ * in the high part, because a wide xadd increment of the low part would carry * up and contaminate the high part. */ -static __always_inline void __ticket_spin_lock(arch_spinlock_t *lock) +static __always_inline void __ticket_spin_lock(struct arch_spinlock *lock) { register struct __raw_tickets inc = { .tail = 1 }; inc = xadd(&lock->tickets, inc); for (;;) { - if (inc.head == inc.tail) - break; - cpu_relax(); - inc.head = ACCESS_ONCE(lock->tickets.head); + unsigned count = SPIN_THRESHOLD; + + do { + if (inc.head == inc.tail) + goto out; + cpu_relax(); + inc.head = ACCESS_ONCE(lock->tickets.head); + } while (--count); + __ticket_lock_spinning(lock, inc.tail); } - barrier(); /* make sure nothing creeps before the lock is taken */ +out: barrier(); /* make sure nothing creeps before the lock is taken */ } static __always_inline int __ticket_spin_trylock(arch_spinlock_t *lock) @@ -80,7 +111,7 @@ static __always_inline int __ticket_spin_trylock(arch_spinlock_t *lock) } #if (NR_CPUS < 256) -static __always_inline void __ticket_spin_unlock(arch_spinlock_t *lock) +static __always_inline void __ticket_unlock_release(arch_spinlock_t *lock) { asm volatile(UNLOCK_LOCK_PREFIX "incb %0" : "+m" (lock->head_tail) @@ -88,7 +119,7 @@ static __always_inline void __ticket_spin_unlock(arch_spinlock_t *lock) : "memory", "cc"); } #else -static __always_inline void __ticket_spin_unlock(arch_spinlock_t *lock) +static __always_inline void __ticket_unlock_release(arch_spinlock_t *lock) { asm volatile(UNLOCK_LOCK_PREFIX "incw %0" : "+m" (lock->head_tail) @@ -97,6 +128,14 @@ static __always_inline void __ticket_spin_unlock(arch_spinlock_t *lock) } #endif +static __always_inline void __ticket_spin_unlock(arch_spinlock_t *lock) +{ + __ticket_t next = lock->tickets.head + 1; + + __ticket_unlock_release(lock); + __ticket_unlock_kick(lock, next); +} + static inline int __ticket_spin_is_locked(arch_spinlock_t *lock) { struct __raw_tickets tmp = ACCESS_ONCE(lock->tickets); @@ -111,8 +150,6 @@ static inline int __ticket_spin_is_contended(arch_spinlock_t *lock) return ((tmp.tail - tmp.head) & TICKET_MASK) > 1; } -#ifndef CONFIG_PARAVIRT_SPINLOCKS - static inline int arch_spin_is_locked(arch_spinlock_t *lock) { return __ticket_spin_is_locked(lock); @@ -145,8 +182,6 @@ static __always_inline void arch_spin_lock_flags(arch_spinlock_t *lock, arch_spin_lock(lock); } -#endif /* CONFIG_PARAVIRT_SPINLOCKS */ - static inline void arch_spin_unlock_wait(arch_spinlock_t *lock) { while (arch_spin_is_locked(lock)) diff --git a/arch/x86/include/asm/spinlock_types.h b/arch/x86/include/asm/spinlock_types.h index 8ebd5df..dbe223d 100644 --- a/arch/x86/include/asm/spinlock_types.h +++ b/arch/x86/include/asm/spinlock_types.h @@ -1,10 +1,6 @@ #ifndef _ASM_X86_SPINLOCK_TYPES_H #define _ASM_X86_SPINLOCK_TYPES_H -#ifndef __LINUX_SPINLOCK_TYPES_H -# error "please don't include this file directly" -#endif - #include #if (CONFIG_NR_CPUS < 256) diff --git a/arch/x86/kernel/paravirt-spinlocks.c b/arch/x86/kernel/paravirt-spinlocks.c index 676b8c7..c2e010e 100644 --- a/arch/x86/kernel/paravirt-spinlocks.c +++ b/arch/x86/kernel/paravirt-spinlocks.c @@ -7,21 +7,10 @@ #include -static inline void -default_spin_lock_flags(arch_spinlock_t *lock, unsigned long flags) -{ - arch_spin_lock(lock); -} - struct pv_lock_ops pv_lock_ops = { #ifdef CONFIG_SMP - .spin_is_locked = __ticket_spin_is_locked, - .spin_is_contended = __ticket_spin_is_contended, - - .spin_lock = __ticket_spin_lock, - .spin_lock_flags = default_spin_lock_flags, - .spin_trylock = __ticket_spin_trylock, - .spin_unlock = __ticket_spin_unlock, + .lock_spinning = paravirt_nop, + .unlock_kick = paravirt_nop, #endif }; EXPORT_SYMBOL(pv_lock_ops); diff --git a/arch/x86/xen/spinlock.c b/arch/x86/xen/spinlock.c index cc9b1e1..23af06a 100644 --- a/arch/x86/xen/spinlock.c +++ b/arch/x86/xen/spinlock.c @@ -121,6 +121,9 @@ struct xen_spinlock { unsigned short spinners; /* count of waiting cpus */ }; +static DEFINE_PER_CPU(int, lock_kicker_irq) = -1; + +#if 0 static int xen_spin_is_locked(struct arch_spinlock *lock) { struct xen_spinlock *xl = (struct xen_spinlock *)lock; @@ -148,7 +151,6 @@ static int xen_spin_trylock(struct arch_spinlock *lock) return old == 0; } -static DEFINE_PER_CPU(int, lock_kicker_irq) = -1; static DEFINE_PER_CPU(struct xen_spinlock *, lock_spinners); /* @@ -338,6 +340,7 @@ static void xen_spin_unlock(struct arch_spinlock *lock) if (unlikely(xl->spinners)) xen_spin_unlock_slow(xl); } +#endif static irqreturn_t dummy_handler(int irq, void *dev_id) { @@ -373,12 +376,14 @@ void xen_uninit_lock_cpu(int cpu) void __init xen_init_spinlocks(void) { +#if 0 pv_lock_ops.spin_is_locked = xen_spin_is_locked; pv_lock_ops.spin_is_contended = xen_spin_is_contended; pv_lock_ops.spin_lock = xen_spin_lock; pv_lock_ops.spin_lock_flags = xen_spin_lock_flags; pv_lock_ops.spin_trylock = xen_spin_trylock; pv_lock_ops.spin_unlock = xen_spin_unlock; +#endif } #ifdef CONFIG_XEN_DEBUG_FS -- 1.7.6 _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel From xen-devel-bounces@lists.xensource.com Wed Sep 14 17:47:41 2011 Return-path: Envelope-to: www-data@lists.xensource.com Delivery-date: Wed, 14 Sep 2011 17:47:41 -0700 Received: from localhost ([127.0.0.1] helo=lists.colo.xensource.com) by lists.xensource.com with esmtp (Exim 4.43) id 1R407B-0003TS-LL; Wed, 14 Sep 2011 17:47:41 -0700 Received: from mail21.messagelabs.com ([85.158.143.35]) by lists.xensource.com with esmtp (Exim 4.43) id 1R402b-0001d7-P3 for xen-devel@lists.xensource.com; Wed, 14 Sep 2011 17:42:58 -0700 X-Env-Sender: jeremy@goop.org X-Msg-Ref: server-9.tower-21.messagelabs.com!1316047328!48449182!1 X-Originating-IP: [74.207.240.146] X-StarScan-Version: 6.4.1; banners=-,-,- X-VirusChecked: Checked Received: (qmail 18780 invoked from network); 15 Sep 2011 00:42:10 -0000 Received: from claw.goop.org (HELO claw.goop.org) (74.207.240.146) by server-9.tower-21.messagelabs.com with DHE-RSA-AES256-SHA encrypted SMTP; 15 Sep 2011 00:42:10 -0000 Received: from saboo.goop.org (unknown [IPv6:2001:470:1f05:899:f0ec:7fff:fed1:2097]) (Authenticated sender: smtp-saboo) by claw.goop.org (Postfix) with ESMTPSA id 97CF89125; Wed, 14 Sep 2011 17:42:46 -0700 (PDT) Received: by saboo.goop.org (Postfix, from userid 500) id 3213920CB0; Wed, 14 Sep 2011 17:31:44 -0700 (PDT) From: Jeremy Fitzhardinge To: "H. Peter Anvin" Date: Wed, 14 Sep 2011 17:31:38 -0700 Message-Id: <97e72b7cf84f9077156be388da702aa3183c9911.1315878463.git.jeremy.fitzhardinge@citrix.com> X-Mailer: git-send-email 1.7.6 In-Reply-To: References: In-Reply-To: References: Cc: Marcelo Tosatti , Nick Piggin , KVM , Peter Zijlstra , the arch/x86 maintainers , Linux Kernel Mailing List , Andi Kleen , Avi Kivity , Jeremy Fitzhardinge , Ingo Molnar , Linus Torvalds , Xen Devel Subject: [Xen-devel] [PATCH 06/10] x86/pvticketlock: use callee-save for lock_spinning X-BeenThere: xen-devel@lists.xensource.com X-Mailman-Version: 2.1.5 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xensource.com Errors-To: xen-devel-bounces@lists.xensource.com From: Jeremy Fitzhardinge Although the lock_spinning calls in the spinlock code are on the uncommon path, their presence can cause the compiler to generate many more register save/restores in the function pre/postamble, which is in the fast path. To avoid this, convert it to using the pvops callee-save calling convention, which defers all the save/restores until the actual function is called, keeping the fastpath clean. Signed-off-by: Jeremy Fitzhardinge --- arch/x86/include/asm/paravirt.h | 2 +- arch/x86/include/asm/paravirt_types.h | 2 +- arch/x86/kernel/paravirt-spinlocks.c | 2 +- arch/x86/xen/spinlock.c | 3 ++- 4 files changed, 5 insertions(+), 4 deletions(-) diff --git a/arch/x86/include/asm/paravirt.h b/arch/x86/include/asm/paravirt.h index 76cae7a..50281c7 100644 --- a/arch/x86/include/asm/paravirt.h +++ b/arch/x86/include/asm/paravirt.h @@ -752,7 +752,7 @@ static inline void __set_fixmap(unsigned /* enum fixed_addresses */ idx, static __always_inline void __ticket_lock_spinning(struct arch_spinlock *lock, __ticket_t ticket) { - PVOP_VCALL2(pv_lock_ops.lock_spinning, lock, ticket); + PVOP_VCALLEE2(pv_lock_ops.lock_spinning, lock, ticket); } static __always_inline void ____ticket_unlock_kick(struct arch_spinlock *lock, __ticket_t ticket) diff --git a/arch/x86/include/asm/paravirt_types.h b/arch/x86/include/asm/paravirt_types.h index 005e24d..5e0c138 100644 --- a/arch/x86/include/asm/paravirt_types.h +++ b/arch/x86/include/asm/paravirt_types.h @@ -330,7 +330,7 @@ struct arch_spinlock; #include struct pv_lock_ops { - void (*lock_spinning)(struct arch_spinlock *lock, __ticket_t ticket); + struct paravirt_callee_save lock_spinning; void (*unlock_kick)(struct arch_spinlock *lock, __ticket_t ticket); }; diff --git a/arch/x86/kernel/paravirt-spinlocks.c b/arch/x86/kernel/paravirt-spinlocks.c index c2e010e..4251c1d 100644 --- a/arch/x86/kernel/paravirt-spinlocks.c +++ b/arch/x86/kernel/paravirt-spinlocks.c @@ -9,7 +9,7 @@ struct pv_lock_ops pv_lock_ops = { #ifdef CONFIG_SMP - .lock_spinning = paravirt_nop, + .lock_spinning = __PV_IS_CALLEE_SAVE(paravirt_nop), .unlock_kick = paravirt_nop, #endif }; diff --git a/arch/x86/xen/spinlock.c b/arch/x86/xen/spinlock.c index f6133c5..7a04950 100644 --- a/arch/x86/xen/spinlock.c +++ b/arch/x86/xen/spinlock.c @@ -145,6 +145,7 @@ out: spin_time_accum_blocked(start); } +PV_CALLEE_SAVE_REGS_THUNK(xen_lock_spinning); static void xen_unlock_kick(struct arch_spinlock *lock, __ticket_t next) { @@ -197,7 +198,7 @@ void xen_uninit_lock_cpu(int cpu) void __init xen_init_spinlocks(void) { - pv_lock_ops.lock_spinning = xen_lock_spinning; + pv_lock_ops.lock_spinning = PV_CALLEE_SAVE(xen_lock_spinning); pv_lock_ops.unlock_kick = xen_unlock_kick; } -- 1.7.6 _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel From xen-devel-bounces@lists.xensource.com Wed Sep 14 17:48:32 2011 Return-path: Envelope-to: www-data@lists.xensource.com Delivery-date: Wed, 14 Sep 2011 17:48:32 -0700 Received: from localhost ([127.0.0.1] helo=lists.colo.xensource.com) by lists.xensource.com with esmtp (Exim 4.43) id 1R4080-0003rm-5u; Wed, 14 Sep 2011 17:48:32 -0700 Received: from mail182.messagelabs.com ([85.158.139.83]) by lists.xensource.com with esmtp (Exim 4.43) id 1R402c-0001dD-TE for xen-devel@lists.xensource.com; Wed, 14 Sep 2011 17:42:59 -0700 X-Env-Sender: jeremy@goop.org X-Msg-Ref: server-6.tower-182.messagelabs.com!1316047374!18365549!1 X-Originating-IP: [74.207.240.146] X-StarScan-Version: 6.4.1; banners=-,-,- X-VirusChecked: Checked Received: (qmail 14672 invoked from network); 15 Sep 2011 00:42:55 -0000 Received: from claw.goop.org (HELO claw.goop.org) (74.207.240.146) by server-6.tower-182.messagelabs.com with DHE-RSA-AES256-SHA encrypted SMTP; 15 Sep 2011 00:42:55 -0000 Received: from saboo.goop.org (unknown [IPv6:2001:470:1f05:899:f0ec:7fff:fed1:2097]) (Authenticated sender: smtp-saboo) by claw.goop.org (Postfix) with ESMTPSA id 57307912C; Wed, 14 Sep 2011 17:42:48 -0700 (PDT) Received: by saboo.goop.org (Postfix, from userid 500) id 4372520CD9; Wed, 14 Sep 2011 17:31:44 -0700 (PDT) From: Jeremy Fitzhardinge To: "H. Peter Anvin" Date: Wed, 14 Sep 2011 17:31:41 -0700 Message-Id: <7b683cc7bef16e7ef5abf3b117e45ef48627874e.1315878463.git.jeremy.fitzhardinge@citrix.com> X-Mailer: git-send-email 1.7.6 In-Reply-To: References: In-Reply-To: References: Cc: Marcelo Tosatti , Nick Piggin , KVM , Peter Zijlstra , the arch/x86 maintainers , Linux Kernel Mailing List , Andi Kleen , Avi Kivity , Jeremy Fitzhardinge , Ingo Molnar , Linus Torvalds , Xen Devel Subject: [Xen-devel] [PATCH 09/10] xen/pvticketlock: allow interrupts to be enabled while blocking X-BeenThere: xen-devel@lists.xensource.com X-Mailman-Version: 2.1.5 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xensource.com Errors-To: xen-devel-bounces@lists.xensource.com From: Jeremy Fitzhardinge If interrupts were enabled when taking the spinlock, we can leave them enabled while blocking to get the lock. If we can enable interrupts while waiting for the lock to become available, and we take an interrupt before entering the poll, and the handler takes a spinlock which ends up going into the slow state (invalidating the per-cpu "lock" and "want" values), then when the interrupt handler returns the event channel will remain pending so the poll will return immediately, causing it to return out to the main spinlock loop. Signed-off-by: Jeremy Fitzhardinge --- arch/x86/xen/spinlock.c | 48 ++++++++++++++++++++++++++++++++++++++++------ 1 files changed, 41 insertions(+), 7 deletions(-) diff --git a/arch/x86/xen/spinlock.c b/arch/x86/xen/spinlock.c index c939723..7366b39 100644 --- a/arch/x86/xen/spinlock.c +++ b/arch/x86/xen/spinlock.c @@ -106,11 +106,28 @@ static void xen_lock_spinning(struct arch_spinlock *lock, __ticket_t want) start = spin_time_start(); - /* Make sure interrupts are disabled to ensure that these - per-cpu values are not overwritten. */ + /* + * Make sure an interrupt handler can't upset things in a + * partially setup state. + */ local_irq_save(flags); + /* + * We don't really care if we're overwriting some other + * (lock,want) pair, as that would mean that we're currently + * in an interrupt context, and the outer context had + * interrupts enabled. That has already kicked the VCPU out + * of xen_poll_irq(), so it will just return spuriously and + * retry with newly setup (lock,want). + * + * The ordering protocol on this is that the "lock" pointer + * may only be set non-NULL if the "want" ticket is correct. + * If we're updating "want", we must first clear "lock". + */ + w->lock = NULL; + smp_wmb(); w->want = want; + smp_wmb(); w->lock = lock; /* This uses set_bit, which atomic and therefore a barrier */ @@ -124,21 +141,36 @@ static void xen_lock_spinning(struct arch_spinlock *lock, __ticket_t want) /* Only check lock once pending cleared */ barrier(); - /* Mark entry to slowpath before doing the pickup test to make - sure we don't deadlock with an unlocker. */ + /* + * Mark entry to slowpath before doing the pickup test to make + * sure we don't deadlock with an unlocker. + */ __ticket_enter_slowpath(lock); - /* check again make sure it didn't become free while - we weren't looking */ + /* + * check again make sure it didn't become free while + * we weren't looking + */ if (ACCESS_ONCE(lock->tickets.head) == want) { ADD_STATS(taken_slow_pickup, 1); goto out; } + /* Allow interrupts while blocked */ + local_irq_restore(flags); + + /* + * If an interrupt happens here, it will leave the wakeup irq + * pending, which will cause xen_poll_irq() to return + * immediately. + */ + /* Block until irq becomes pending (or perhaps a spurious wakeup) */ xen_poll_irq(irq); ADD_STATS(taken_slow_spurious, !xen_test_irq_pending(irq)); + local_irq_save(flags); + kstat_incr_irqs_this_cpu(irq, irq_to_desc(irq)); out: @@ -160,7 +192,9 @@ static void xen_unlock_kick(struct arch_spinlock *lock, __ticket_t next) for_each_cpu(cpu, &waiting_cpus) { const struct xen_lock_waiting *w = &per_cpu(lock_waiting, cpu); - if (w->lock == lock && w->want == next) { + /* Make sure we read lock before want */ + if (ACCESS_ONCE(w->lock) == lock && + ACCESS_ONCE(w->want) == next) { ADD_STATS(released_slow_kicked, 1); xen_send_IPI_one(cpu, XEN_SPIN_UNLOCK_VECTOR); break; -- 1.7.6 _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel From xen-devel-bounces@lists.xensource.com Wed Sep 14 17:49:16 2011 Return-path: Envelope-to: www-data@lists.xensource.com Delivery-date: Wed, 14 Sep 2011 17:49:16 -0700 Received: from localhost ([127.0.0.1] helo=lists.colo.xensource.com) by lists.xensource.com with esmtp (Exim 4.43) id 1R408i-0004Fn-H3; Wed, 14 Sep 2011 17:49:16 -0700 Received: from mail27.messagelabs.com ([193.109.254.147]) by lists.xensource.com with esmtp (Exim 4.43) id 1R402e-0001da-CY for xen-devel@lists.xensource.com; Wed, 14 Sep 2011 17:43:00 -0700 X-Env-Sender: jeremy@goop.org X-Msg-Ref: server-13.tower-27.messagelabs.com!1316047364!40072654!1 X-Originating-IP: [74.207.240.146] X-StarScan-Version: 6.4.1; banners=-,-,- X-VirusChecked: Checked Received: (qmail 13181 invoked from network); 15 Sep 2011 00:42:45 -0000 Received: from claw.goop.org (HELO claw.goop.org) (74.207.240.146) by server-13.tower-27.messagelabs.com with DHE-RSA-AES256-SHA encrypted SMTP; 15 Sep 2011 00:42:45 -0000 Received: from saboo.goop.org (unknown [IPv6:2001:470:1f05:899:f0ec:7fff:fed1:2097]) (Authenticated sender: smtp-saboo) by claw.goop.org (Postfix) with ESMTPSA id 572699127; Wed, 14 Sep 2011 17:42:49 -0700 (PDT) Received: by saboo.goop.org (Postfix, from userid 500) id 481E320CDF; Wed, 14 Sep 2011 17:31:44 -0700 (PDT) From: Jeremy Fitzhardinge To: "H. Peter Anvin" Date: Wed, 14 Sep 2011 17:31:42 -0700 Message-Id: <57f242ff87e90ee2ae52e73aa569d2dccd975e6a.1315878463.git.jeremy.fitzhardinge@citrix.com> X-Mailer: git-send-email 1.7.6 In-Reply-To: References: In-Reply-To: References: Cc: Marcelo Tosatti , Nick Piggin , KVM , Stefano Stabellini , Peter Zijlstra , the arch/x86 maintainers , Linux Kernel Mailing List , Andi Kleen , Avi Kivity , Jeremy Fitzhardinge , Ingo Molnar , Linus Torvalds , Xen Devel Subject: [Xen-devel] [PATCH 10/10] xen: enable PV ticketlocks on HVM Xen X-BeenThere: xen-devel@lists.xensource.com X-Mailman-Version: 2.1.5 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xensource.com Errors-To: xen-devel-bounces@lists.xensource.com From: Stefano Stabellini Signed-off-by: Jeremy Fitzhardinge --- arch/x86/xen/smp.c | 1 + 1 files changed, 1 insertions(+), 0 deletions(-) diff --git a/arch/x86/xen/smp.c b/arch/x86/xen/smp.c index e79dbb9..bf958ce 100644 --- a/arch/x86/xen/smp.c +++ b/arch/x86/xen/smp.c @@ -552,4 +552,5 @@ void __init xen_hvm_smp_init(void) smp_ops.cpu_die = xen_hvm_cpu_die; smp_ops.send_call_func_ipi = xen_smp_send_call_function_ipi; smp_ops.send_call_func_single_ipi = xen_smp_send_call_function_single_ipi; + xen_init_spinlocks(); } -- 1.7.6 _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel From xen-devel-bounces@lists.xensource.com Wed Sep 14 17:50:02 2011 Return-path: Envelope-to: www-data@lists.xensource.com Delivery-date: Wed, 14 Sep 2011 17:50:02 -0700 Received: from localhost ([127.0.0.1] helo=lists.colo.xensource.com) by lists.xensource.com with esmtp (Exim 4.43) id 1R409S-0004cc-0R; Wed, 14 Sep 2011 17:50:02 -0700 Received: from mail21.messagelabs.com ([85.158.143.35]) by lists.xensource.com with esmtp (Exim 4.43) id 1R402f-0001dm-6E for xen-devel@lists.xensource.com; Wed, 14 Sep 2011 17:43:02 -0700 X-Env-Sender: jeremy@goop.org X-Msg-Ref: server-14.tower-21.messagelabs.com!1316047368!59618744!1 X-Originating-IP: [74.207.240.146] X-StarScan-Version: 6.4.1; banners=-,-,- X-VirusChecked: Checked Received: (qmail 6684 invoked from network); 15 Sep 2011 00:42:49 -0000 Received: from claw.goop.org (HELO claw.goop.org) (74.207.240.146) by server-14.tower-21.messagelabs.com with DHE-RSA-AES256-SHA encrypted SMTP; 15 Sep 2011 00:42:49 -0000 Received: from saboo.goop.org (unknown [IPv6:2001:470:1f05:899:f0ec:7fff:fed1:2097]) (Authenticated sender: smtp-saboo) by claw.goop.org (Postfix) with ESMTPSA id 5738A912A; Wed, 14 Sep 2011 17:42:49 -0700 (PDT) Received: by saboo.goop.org (Postfix, from userid 500) id 16E2B20C21; Wed, 14 Sep 2011 17:31:44 -0700 (PDT) From: Jeremy Fitzhardinge To: "H. Peter Anvin" Date: Wed, 14 Sep 2011 17:31:32 -0700 Message-Id: X-Mailer: git-send-email 1.7.6 Cc: Marcelo Tosatti , Nick Piggin , KVM , Peter Zijlstra , the arch/x86 maintainers , Linux Kernel Mailing List , Andi Kleen , Avi Kivity , Jeremy Fitzhardinge , Ingo Molnar , Linus Torvalds , Xen Devel Subject: [Xen-devel] [PATCH 00/10] [PATCH RFC V2] Paravirtualized ticketlocks X-BeenThere: xen-devel@lists.xensource.com X-Mailman-Version: 2.1.5 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xensource.com Errors-To: xen-devel-bounces@lists.xensource.com From: Jeremy Fitzhardinge [ Changes since last posting: - fix bugs exposed by the cold light of testing - make the "slow flag" read in unlock cover the whole lock to force ordering WRT the unlock write - when kicking on unlock, only look for the CPU *we* released (ie, head value the unlock resulted in), rather than re-reading the new head and kicking on that basis - enable PV ticketlocks in Xen HVM guests ] NOTE: this series is available in: git://github.com/jsgf/linux-xen.git upstream/pvticketlock-slowflag and is based on the previously posted ticketlock cleanup series in git://github.com/jsgf/linux-xen.git upstream/ticketlock-cleanup This series replaces the existing paravirtualized spinlock mechanism with a paravirtualized ticketlock mechanism. Ticket locks have an inherent problem in a virtualized case, because the vCPUs are scheduled rather than running concurrently (ignoring gang scheduled vCPUs). This can result in catastrophic performance collapses when the vCPU scheduler doesn't schedule the correct "next" vCPU, and ends up scheduling a vCPU which burns its entire timeslice spinning. (Note that this is not the same problem as lock-holder preemption, which this series also addresses; that's also a problem, but not catastrophic). (See Thomas Friebel's talk "Prevent Guests from Spinning Around" http://www.xen.org/files/xensummitboston08/LHP.pdf for more details.) Currently we deal with this by having PV spinlocks, which adds a layer of indirection in front of all the spinlock functions, and defining a completely new implementation for Xen (and for other pvops users, but there are none at present). PV ticketlocks keeps the existing ticketlock implemenentation (fastpath) as-is, but adds a couple of pvops for the slow paths: - If a CPU has been waiting for a spinlock for SPIN_THRESHOLD iterations, then call out to the __ticket_lock_spinning() pvop, which allows a backend to block the vCPU rather than spinning. This pvop can set the lock into "slowpath state". - When releasing a lock, if it is in "slowpath state", the call __ticket_unlock_kick() to kick the next vCPU in line awake. If the lock is no longer in contention, it also clears the slowpath flag. The "slowpath state" is stored in the LSB of the within the lock ticket. This has the effect of reducing the max number of CPUs by half (so, a "small ticket" can deal with 128 CPUs, and "large ticket" 32768). This series provides a Xen implementation, but it should be straightforward to add a KVM implementation as well. Overall, it results in a large reduction in code, it makes the native and virtualized cases closer, and it removes a layer of indirection around all the spinlock functions. The fast path (taking an uncontended lock which isn't in "slowpath" state) is optimal, identical to the non-paravirtualized case. The inner part of ticket lock code becomes: inc = xadd(&lock->tickets, inc); inc.tail &= ~TICKET_SLOWPATH_FLAG; if (likely(inc.head == inc.tail)) goto out; for (;;) { unsigned count = SPIN_THRESHOLD; do { if (ACCESS_ONCE(lock->tickets.head) == inc.tail) goto out; cpu_relax(); } while (--count); __ticket_lock_spinning(lock, inc.tail); } out: barrier(); which results in: push %rbp mov %rsp,%rbp mov $0x200,%eax lock xadd %ax,(%rdi) movzbl %ah,%edx cmp %al,%dl jne 1f pop %rbp retq ### SLOWPATH START 1: and $-2,%edx movzbl %dl,%esi 2: mov $0x800,%eax jmp 4f 3: pause sub $0x1,%eax je 5f 4: movzbl (%rdi),%ecx cmp %cl,%dl jne 3b pop %rbp retq 5: callq *__ticket_lock_spinning jmp 2b ### SLOWPATH END with CONFIG_PARAVIRT_SPINLOCKS=n, the code has changed slightly, where the fastpath case is straight through (taking the lock without contention), and the spin loop is out of line: push %rbp mov %rsp,%rbp mov $0x100,%eax lock xadd %ax,(%rdi) movzbl %ah,%edx cmp %al,%dl jne 1f pop %rbp retq ### SLOWPATH START 1: pause movzbl (%rdi),%eax cmp %dl,%al jne 1b pop %rbp retq ### SLOWPATH END The unlock code is very straightforward: prev = *lock; __ticket_unlock_release(lock); if (unlikely(__ticket_in_slowpath(lock))) __ticket_unlock_slowpath(lock, prev); which generates: push %rbp mov %rsp,%rbp movzwl (%rdi),%esi addb $0x2,(%rdi) movzwl (%rdi),%eax testb $0x1,%ah jne 1f pop %rbp retq ### SLOWPATH START 1: movzwl (%rdi),%edx movzbl %dh,%ecx mov %edx,%eax and $-2,%ecx # clear TICKET_SLOWPATH_FLAG mov %cl,%dh cmp %dl,%cl # test to see if lock is uncontended je 3f 2: movzbl %dl,%esi callq *__ticket_unlock_kick # kick anyone waiting pop %rbp retq 3: lock cmpxchg %dx,(%rdi) # use cmpxchg to safely write back flag jmp 2b ### SLOWPATH END The fastpath is pretty straightforward, but it is definitely more complex than a simple "addb $1,(%rdi)" - which is still generated (and inlined) when PARAVIRT_SPINLOCKS is disabled. Thoughts? Comments? Suggestions? Thanks, J Jeremy Fitzhardinge (9): x86/spinlocks: replace pv spinlocks with pv ticketlocks x86/ticketlock: don't inline _spin_unlock when using paravirt spinlocks x86/ticketlock: collapse a layer of functions xen/pvticketlock: Xen implementation for PV ticket locks x86/pvticketlock: use callee-save for lock_spinning x86/ticketlocks: when paravirtualizing ticket locks, increment by 2 x86/ticketlock: add slowpath logic xen/pvticketlock: allow interrupts to be enabled while blocking Stefano Stabellini (1): xen: enable PV ticketlocks on HVM Xen arch/x86/Kconfig | 3 + arch/x86/include/asm/paravirt.h | 30 +--- arch/x86/include/asm/paravirt_types.h | 10 +- arch/x86/include/asm/spinlock.h | 160 ++++++++++++----- arch/x86/include/asm/spinlock_types.h | 16 ++- arch/x86/kernel/paravirt-spinlocks.c | 16 +-- arch/x86/xen/smp.c | 1 + arch/x86/xen/spinlock.c | 315 ++++++++------------------------ kernel/Kconfig.locks | 2 +- 9 files changed, 217 insertions(+), 336 deletions(-) -- 1.7.6 _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel From xen-devel-bounces@lists.xensource.com Wed Sep 14 17:50:46 2011 Return-path: Envelope-to: www-data@lists.xensource.com Delivery-date: Wed, 14 Sep 2011 17:50:46 -0700 Received: from localhost ([127.0.0.1] helo=lists.colo.xensource.com) by lists.xensource.com with esmtp (Exim 4.43) id 1R40A9-0004yk-SJ; Wed, 14 Sep 2011 17:50:45 -0700 Received: from mail216.messagelabs.com ([85.158.143.99]) by lists.xensource.com with esmtp (Exim 4.43) id 1R402g-0001dv-4j for xen-devel@lists.xensource.com; Wed, 14 Sep 2011 17:43:03 -0700 X-Env-Sender: jeremy@goop.org X-Msg-Ref: server-2.tower-216.messagelabs.com!1316047377!18299326!1 X-Originating-IP: [74.207.240.146] X-StarScan-Version: 6.4.1; banners=-,-,- X-VirusChecked: Checked Received: (qmail 12561 invoked from network); 15 Sep 2011 00:42:58 -0000 Received: from claw.goop.org (HELO claw.goop.org) (74.207.240.146) by server-2.tower-216.messagelabs.com with DHE-RSA-AES256-SHA encrypted SMTP; 15 Sep 2011 00:42:58 -0000 Received: from saboo.goop.org (unknown [IPv6:2001:470:1f05:899:f0ec:7fff:fed1:2097]) (Authenticated sender: smtp-saboo) by claw.goop.org (Postfix) with ESMTPSA id C10689130; Wed, 14 Sep 2011 17:42:50 -0700 (PDT) Received: by saboo.goop.org (Postfix, from userid 500) id 3D2BC20CD8; Wed, 14 Sep 2011 17:31:44 -0700 (PDT) From: Jeremy Fitzhardinge To: "H. Peter Anvin" Date: Wed, 14 Sep 2011 17:31:40 -0700 Message-Id: <618bff1804602d2f67b8a248cb86dd580fa37a79.1315878463.git.jeremy.fitzhardinge@citrix.com> X-Mailer: git-send-email 1.7.6 In-Reply-To: References: In-Reply-To: References: Cc: Marcelo Tosatti , Nick Piggin , KVM , Peter Zijlstra , the arch/x86 maintainers , Linux Kernel Mailing List , Srivatsa Vaddagiri , Andi Kleen , Avi Kivity , Jeremy Fitzhardinge , Ingo Molnar , Linus Torvalds , Xen Devel Subject: [Xen-devel] [PATCH 08/10] x86/ticketlock: add slowpath logic X-BeenThere: xen-devel@lists.xensource.com X-Mailman-Version: 2.1.5 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xensource.com Errors-To: xen-devel-bounces@lists.xensource.com From: Jeremy Fitzhardinge Maintain a flag in the LSB of the ticket lock tail which indicates whether anyone is in the lock slowpath and may need kicking when the current holder unlocks. The flags are set when the first locker enters the slowpath, and cleared when unlocking to an empty queue (ie, no contention). In the specific implementation of lock_spinning(), make sure to set the slowpath flags on the lock just before blocking. We must do this before the last-chance pickup test to prevent a deadlock with the unlocker: Unlocker Locker test for lock pickup -> fail unlock test slowpath -> false set slowpath flags block Whereas this works in any ordering: Unlocker Locker set slowpath flags test for lock pickup -> fail block unlock test slowpath -> true, kick If the unlocker finds that the lock has the slowpath flag set but it is actually uncontended (ie, head == tail, so nobody is waiting), then it clear the slowpath flag. Note on memory access ordering: When unlocking a ticketlock with PV callbacks enabled, unlock first "add"s to the lock head, then checks to see if the slowpath flag is set in the lock tail. However, because reads are not ordered with respect to writes in different memory locations, the CPU could perform the read before updating head to release the lock. This would deadlock with another CPU in the lock slowpath, as it will set the slowpath flag before checking to see if the lock has been released in the interim. A heavyweight fix would be to stick a full mfence between the two. However, a lighterweight fix is to simply make sure the flag tests loads both head and tail of the lock in a single operation, thereby making sure that it overlaps with the memory written by the unlock, forcing the CPU to maintain ordering. Note: this code relies on gcc making sure that unlikely() code is out of line of the fastpath, which only happens when OPTIMIZE_SIZE=n. If it doesn't the generated code isn't too bad, but its definitely suboptimal. (Thanks to Srivatsa Vaddagiri for providing a bugfix to the original version of this change, which has been folded in.) Signed-off-by: Jeremy Fitzhardinge Signed-off-by: Srivatsa Vaddagiri --- arch/x86/include/asm/paravirt.h | 2 +- arch/x86/include/asm/spinlock.h | 92 ++++++++++++++++++++++++++------ arch/x86/include/asm/spinlock_types.h | 2 + arch/x86/kernel/paravirt-spinlocks.c | 1 + arch/x86/xen/spinlock.c | 4 ++ 5 files changed, 82 insertions(+), 19 deletions(-) diff --git a/arch/x86/include/asm/paravirt.h b/arch/x86/include/asm/paravirt.h index 50281c7..13b3d8b 100644 --- a/arch/x86/include/asm/paravirt.h +++ b/arch/x86/include/asm/paravirt.h @@ -755,7 +755,7 @@ static __always_inline void __ticket_lock_spinning(struct arch_spinlock *lock, _ PVOP_VCALLEE2(pv_lock_ops.lock_spinning, lock, ticket); } -static __always_inline void ____ticket_unlock_kick(struct arch_spinlock *lock, __ticket_t ticket) +static __always_inline void __ticket_unlock_kick(struct arch_spinlock *lock, __ticket_t ticket) { PVOP_VCALL2(pv_lock_ops.unlock_kick, lock, ticket); } diff --git a/arch/x86/include/asm/spinlock.h b/arch/x86/include/asm/spinlock.h index 40c90aa..c1f6981 100644 --- a/arch/x86/include/asm/spinlock.h +++ b/arch/x86/include/asm/spinlock.h @@ -40,29 +40,56 @@ /* How long a lock should spin before we consider blocking */ #define SPIN_THRESHOLD (1 << 11) -#ifndef CONFIG_PARAVIRT_SPINLOCKS +#ifdef CONFIG_PARAVIRT_SPINLOCKS -static __always_inline void __ticket_lock_spinning(struct arch_spinlock *lock, __ticket_t ticket) +/* + * Return true if someone is in the slowpath on this lock. This + * should only be used by the current lock-holder. + */ +static inline bool __ticket_in_slowpath(arch_spinlock_t *lock) { + /* + * This deliberately reads both head and tail as a single + * memory operation, and then tests the flag in tail. This is + * to guarantee that this read is ordered after the "add" to + * head which does the unlock. If we were to only read "tail" + * to test the flag, then the CPU would be free to reorder the + * read to before the write to "head" (since it is a different + * memory location), which could cause a deadlock with someone + * setting the flag before re-checking the lock availability. + */ + return ACCESS_ONCE(lock->head_tail) & (TICKET_SLOWPATH_FLAG << TICKET_SHIFT); } -static __always_inline void ____ticket_unlock_kick(struct arch_spinlock *lock, __ticket_t ticket) +static inline void __ticket_enter_slowpath(arch_spinlock_t *lock) { + if (sizeof(lock->tickets.tail) == sizeof(u8)) + asm (LOCK_PREFIX "orb %1, %0" + : "+m" (lock->tickets.tail) + : "i" (TICKET_SLOWPATH_FLAG) : "memory"); + else + asm (LOCK_PREFIX "orw %1, %0" + : "+m" (lock->tickets.tail) + : "i" (TICKET_SLOWPATH_FLAG) : "memory"); } -#endif /* CONFIG_PARAVIRT_SPINLOCKS */ +#else /* !CONFIG_PARAVIRT_SPINLOCKS */ +static inline bool __ticket_in_slowpath(arch_spinlock_t *lock) +{ + return false; +} +static __always_inline void __ticket_lock_spinning(arch_spinlock_t *lock, __ticket_t ticket) +{ +} -/* - * If a spinlock has someone waiting on it, then kick the appropriate - * waiting cpu. - */ -static __always_inline void __ticket_unlock_kick(struct arch_spinlock *lock, __ticket_t next) +static inline void __ticket_unlock_kick(arch_spinlock_t *lock, __ticket_t ticket) { - if (unlikely(lock->tickets.tail != next)) - ____ticket_unlock_kick(lock, next); } +#endif /* CONFIG_PARAVIRT_SPINLOCKS */ + + /* * Ticket locks are conceptually two parts, one indicating the current head of * the queue, and the other indicating the current tail. The lock is acquired @@ -76,20 +103,22 @@ static __always_inline void __ticket_unlock_kick(struct arch_spinlock *lock, __t * in the high part, because a wide xadd increment of the low part would carry * up and contaminate the high part. */ -static __always_inline void arch_spin_lock(struct arch_spinlock *lock) +static __always_inline void arch_spin_lock(arch_spinlock_t *lock) { register struct __raw_tickets inc = { .tail = TICKET_LOCK_INC }; inc = xadd(&lock->tickets, inc); + if (likely(inc.head == inc.tail)) + goto out; + inc.tail &= ~TICKET_SLOWPATH_FLAG; for (;;) { unsigned count = SPIN_THRESHOLD; do { - if (inc.head == inc.tail) + if (ACCESS_ONCE(lock->tickets.head) == inc.tail) goto out; cpu_relax(); - inc.head = ACCESS_ONCE(lock->tickets.head); } while (--count); __ticket_lock_spinning(lock, inc.tail); } @@ -101,7 +130,7 @@ static __always_inline int arch_spin_trylock(arch_spinlock_t *lock) arch_spinlock_t old, new; old.tickets = ACCESS_ONCE(lock->tickets); - if (old.tickets.head != old.tickets.tail) + if (old.tickets.head != (old.tickets.tail & ~TICKET_SLOWPATH_FLAG)) return 0; new.head_tail = old.head_tail + (TICKET_LOCK_INC << TICKET_SHIFT); @@ -128,12 +157,39 @@ static __always_inline void __ticket_unlock_release(arch_spinlock_t *lock) } #endif -static __always_inline void arch_spin_unlock(arch_spinlock_t *lock) +static inline void __ticket_unlock_slowpath(arch_spinlock_t *lock, + arch_spinlock_t old) { - __ticket_t next = lock->tickets.head + TICKET_LOCK_INC; + arch_spinlock_t new; + + BUILD_BUG_ON(((__ticket_t)NR_CPUS) != NR_CPUS); + + /* Perform the unlock on the "before" copy */ + old.tickets.head += TICKET_LOCK_INC; + + /* Clear the slowpath flag */ + new.head_tail = old.head_tail & ~(TICKET_SLOWPATH_FLAG << TICKET_SHIFT); + + /* + * If the lock is uncontended, clear the flag - use cmpxchg in + * case it changes behind our back though. + */ + if (new.tickets.head != new.tickets.tail || + cmpxchg(&lock->head_tail, old.head_tail, new.head_tail) != old.head_tail) { + /* + * Lock still has someone queued for it, so wake up an + * appropriate waiter. + */ + __ticket_unlock_kick(lock, old.tickets.head); + } +} +static __always_inline void arch_spin_unlock(arch_spinlock_t *lock) +{ + arch_spinlock_t prev = *lock; __ticket_unlock_release(lock); - __ticket_unlock_kick(lock, next); + if (unlikely(__ticket_in_slowpath(lock))) + __ticket_unlock_slowpath(lock, prev); } static inline int arch_spin_is_locked(arch_spinlock_t *lock) diff --git a/arch/x86/include/asm/spinlock_types.h b/arch/x86/include/asm/spinlock_types.h index aa9a205..407f7f7 100644 --- a/arch/x86/include/asm/spinlock_types.h +++ b/arch/x86/include/asm/spinlock_types.h @@ -5,8 +5,10 @@ #ifdef CONFIG_PARAVIRT_SPINLOCKS #define __TICKET_LOCK_INC 2 +#define TICKET_SLOWPATH_FLAG ((__ticket_t)1) #else #define __TICKET_LOCK_INC 1 +#define TICKET_SLOWPATH_FLAG ((__ticket_t)0) #endif #if (CONFIG_NR_CPUS < (256 / __TICKET_LOCK_INC)) diff --git a/arch/x86/kernel/paravirt-spinlocks.c b/arch/x86/kernel/paravirt-spinlocks.c index 4251c1d..0883c48 100644 --- a/arch/x86/kernel/paravirt-spinlocks.c +++ b/arch/x86/kernel/paravirt-spinlocks.c @@ -15,3 +15,4 @@ struct pv_lock_ops pv_lock_ops = { }; EXPORT_SYMBOL(pv_lock_ops); + diff --git a/arch/x86/xen/spinlock.c b/arch/x86/xen/spinlock.c index 7a04950..c939723 100644 --- a/arch/x86/xen/spinlock.c +++ b/arch/x86/xen/spinlock.c @@ -124,6 +124,10 @@ static void xen_lock_spinning(struct arch_spinlock *lock, __ticket_t want) /* Only check lock once pending cleared */ barrier(); + /* Mark entry to slowpath before doing the pickup test to make + sure we don't deadlock with an unlocker. */ + __ticket_enter_slowpath(lock); + /* check again make sure it didn't become free while we weren't looking */ if (ACCESS_ONCE(lock->tickets.head) == want) { -- 1.7.6 _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel From xen-devel-bounces@lists.xensource.com Wed Sep 14 17:51:30 2011 Return-path: Envelope-to: www-data@lists.xensource.com Delivery-date: Wed, 14 Sep 2011 17:51:30 -0700 Received: from localhost ([127.0.0.1] helo=lists.colo.xensource.com) by lists.xensource.com with esmtp (Exim 4.43) id 1R40As-0005LT-6x; Wed, 14 Sep 2011 17:51:30 -0700 Received: from mail216.messagelabs.com ([85.158.143.99]) by lists.xensource.com with esmtp (Exim 4.43) id 1R402h-0001eE-0g for xen-devel@lists.xensource.com; Wed, 14 Sep 2011 17:43:04 -0700 X-Env-Sender: jeremy@goop.org X-Msg-Ref: server-6.tower-216.messagelabs.com!1316047378!17038476!1 X-Originating-IP: [74.207.240.146] X-StarScan-Version: 6.4.1; banners=-,-,- X-VirusChecked: Checked Received: (qmail 9643 invoked from network); 15 Sep 2011 00:42:59 -0000 Received: from claw.goop.org (HELO claw.goop.org) (74.207.240.146) by server-6.tower-216.messagelabs.com with DHE-RSA-AES256-SHA encrypted SMTP; 15 Sep 2011 00:42:59 -0000 Received: from saboo.goop.org (unknown [IPv6:2001:470:1f05:899:f0ec:7fff:fed1:2097]) (Authenticated sender: smtp-saboo) by claw.goop.org (Postfix) with ESMTPSA id C112A9132; Wed, 14 Sep 2011 17:42:50 -0700 (PDT) Received: by saboo.goop.org (Postfix, from userid 500) id 2E18720CAD; Wed, 14 Sep 2011 17:31:44 -0700 (PDT) From: Jeremy Fitzhardinge To: "H. Peter Anvin" Date: Wed, 14 Sep 2011 17:31:37 -0700 Message-Id: <539fe5e84c50bad0d1018f9478c1ff91c564d378.1315878463.git.jeremy.fitzhardinge@citrix.com> X-Mailer: git-send-email 1.7.6 In-Reply-To: References: In-Reply-To: References: Cc: Marcelo Tosatti , Nick Piggin , KVM , Peter Zijlstra , the arch/x86 maintainers , Linux Kernel Mailing List , Andi Kleen , Avi Kivity , Jeremy Fitzhardinge , Ingo Molnar , Linus Torvalds , Xen Devel Subject: [Xen-devel] [PATCH 05/10] xen/pvticketlock: Xen implementation for PV ticket locks X-BeenThere: xen-devel@lists.xensource.com X-Mailman-Version: 2.1.5 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xensource.com Errors-To: xen-devel-bounces@lists.xensource.com From: Jeremy Fitzhardinge Replace the old Xen implementation of PV spinlocks with and implementation of xen_lock_spinning and xen_unlock_kick. xen_lock_spinning simply registers the cpu in its entry in lock_waiting, adds itself to the waiting_cpus set, and blocks on an event channel until the channel becomes pending. xen_unlock_kick searches the cpus in waiting_cpus looking for the one which next wants this lock with the next ticket, if any. If found, it kicks it by making its event channel pending, which wakes it up. We need to make sure interrupts are disabled while we're relying on the contents of the per-cpu lock_waiting values, otherwise an interrupt handler could come in, try to take some other lock, block, and overwrite our values. Signed-off-by: Jeremy Fitzhardinge --- arch/x86/xen/spinlock.c | 287 +++++++---------------------------------------- 1 files changed, 43 insertions(+), 244 deletions(-) diff --git a/arch/x86/xen/spinlock.c b/arch/x86/xen/spinlock.c index 23af06a..f6133c5 100644 --- a/arch/x86/xen/spinlock.c +++ b/arch/x86/xen/spinlock.c @@ -19,32 +19,21 @@ #ifdef CONFIG_XEN_DEBUG_FS static struct xen_spinlock_stats { - u64 taken; u32 taken_slow; - u32 taken_slow_nested; u32 taken_slow_pickup; u32 taken_slow_spurious; - u32 taken_slow_irqenable; - u64 released; u32 released_slow; u32 released_slow_kicked; #define HISTO_BUCKETS 30 - u32 histo_spin_total[HISTO_BUCKETS+1]; - u32 histo_spin_spinning[HISTO_BUCKETS+1]; u32 histo_spin_blocked[HISTO_BUCKETS+1]; - u64 time_total; - u64 time_spinning; u64 time_blocked; } spinlock_stats; static u8 zero_stats; -static unsigned lock_timeout = 1 << 10; -#define TIMEOUT lock_timeout - static inline void check_zero(void) { if (unlikely(zero_stats)) { @@ -73,22 +62,6 @@ static void __spin_time_accum(u64 delta, u32 *array) array[HISTO_BUCKETS]++; } -static inline void spin_time_accum_spinning(u64 start) -{ - u32 delta = xen_clocksource_read() - start; - - __spin_time_accum(delta, spinlock_stats.histo_spin_spinning); - spinlock_stats.time_spinning += delta; -} - -static inline void spin_time_accum_total(u64 start) -{ - u32 delta = xen_clocksource_read() - start; - - __spin_time_accum(delta, spinlock_stats.histo_spin_total); - spinlock_stats.time_total += delta; -} - static inline void spin_time_accum_blocked(u64 start) { u32 delta = xen_clocksource_read() - start; @@ -105,214 +78,84 @@ static inline u64 spin_time_start(void) return 0; } -static inline void spin_time_accum_total(u64 start) -{ -} -static inline void spin_time_accum_spinning(u64 start) -{ -} static inline void spin_time_accum_blocked(u64 start) { } #endif /* CONFIG_XEN_DEBUG_FS */ -struct xen_spinlock { - unsigned char lock; /* 0 -> free; 1 -> locked */ - unsigned short spinners; /* count of waiting cpus */ +struct xen_lock_waiting { + struct arch_spinlock *lock; + __ticket_t want; }; static DEFINE_PER_CPU(int, lock_kicker_irq) = -1; +static DEFINE_PER_CPU(struct xen_lock_waiting, lock_waiting); +static cpumask_t waiting_cpus; -#if 0 -static int xen_spin_is_locked(struct arch_spinlock *lock) -{ - struct xen_spinlock *xl = (struct xen_spinlock *)lock; - - return xl->lock != 0; -} - -static int xen_spin_is_contended(struct arch_spinlock *lock) +static void xen_lock_spinning(struct arch_spinlock *lock, __ticket_t want) { - struct xen_spinlock *xl = (struct xen_spinlock *)lock; - - /* Not strictly true; this is only the count of contended - lock-takers entering the slow path. */ - return xl->spinners != 0; -} - -static int xen_spin_trylock(struct arch_spinlock *lock) -{ - struct xen_spinlock *xl = (struct xen_spinlock *)lock; - u8 old = 1; - - asm("xchgb %b0,%1" - : "+q" (old), "+m" (xl->lock) : : "memory"); - - return old == 0; -} - -static DEFINE_PER_CPU(struct xen_spinlock *, lock_spinners); - -/* - * Mark a cpu as interested in a lock. Returns the CPU's previous - * lock of interest, in case we got preempted by an interrupt. - */ -static inline struct xen_spinlock *spinning_lock(struct xen_spinlock *xl) -{ - struct xen_spinlock *prev; - - prev = __this_cpu_read(lock_spinners); - __this_cpu_write(lock_spinners, xl); - - wmb(); /* set lock of interest before count */ - - asm(LOCK_PREFIX " incw %0" - : "+m" (xl->spinners) : : "memory"); - - return prev; -} - -/* - * Mark a cpu as no longer interested in a lock. Restores previous - * lock of interest (NULL for none). - */ -static inline void unspinning_lock(struct xen_spinlock *xl, struct xen_spinlock *prev) -{ - asm(LOCK_PREFIX " decw %0" - : "+m" (xl->spinners) : : "memory"); - wmb(); /* decrement count before restoring lock */ - __this_cpu_write(lock_spinners, prev); -} - -static noinline int xen_spin_lock_slow(struct arch_spinlock *lock, bool irq_enable) -{ - struct xen_spinlock *xl = (struct xen_spinlock *)lock; - struct xen_spinlock *prev; int irq = __this_cpu_read(lock_kicker_irq); - int ret; + struct xen_lock_waiting *w = &__get_cpu_var(lock_waiting); + int cpu = smp_processor_id(); u64 start; + unsigned long flags; /* If kicker interrupts not initialized yet, just spin */ if (irq == -1) - return 0; + return; start = spin_time_start(); - /* announce we're spinning */ - prev = spinning_lock(xl); + /* Make sure interrupts are disabled to ensure that these + per-cpu values are not overwritten. */ + local_irq_save(flags); + + w->want = want; + w->lock = lock; + + /* This uses set_bit, which atomic and therefore a barrier */ + cpumask_set_cpu(cpu, &waiting_cpus); ADD_STATS(taken_slow, 1); - ADD_STATS(taken_slow_nested, prev != NULL); - - do { - unsigned long flags; - - /* clear pending */ - xen_clear_irq_pending(irq); - - /* check again make sure it didn't become free while - we weren't looking */ - ret = xen_spin_trylock(lock); - if (ret) { - ADD_STATS(taken_slow_pickup, 1); - - /* - * If we interrupted another spinlock while it - * was blocking, make sure it doesn't block - * without rechecking the lock. - */ - if (prev != NULL) - xen_set_irq_pending(irq); - goto out; - } - flags = arch_local_save_flags(); - if (irq_enable) { - ADD_STATS(taken_slow_irqenable, 1); - raw_local_irq_enable(); - } + /* clear pending */ + xen_clear_irq_pending(irq); - /* - * Block until irq becomes pending. If we're - * interrupted at this point (after the trylock but - * before entering the block), then the nested lock - * handler guarantees that the irq will be left - * pending if there's any chance the lock became free; - * xen_poll_irq() returns immediately if the irq is - * pending. - */ - xen_poll_irq(irq); + /* Only check lock once pending cleared */ + barrier(); - raw_local_irq_restore(flags); + /* check again make sure it didn't become free while + we weren't looking */ + if (ACCESS_ONCE(lock->tickets.head) == want) { + ADD_STATS(taken_slow_pickup, 1); + goto out; + } - ADD_STATS(taken_slow_spurious, !xen_test_irq_pending(irq)); - } while (!xen_test_irq_pending(irq)); /* check for spurious wakeups */ + /* Block until irq becomes pending (or perhaps a spurious wakeup) */ + xen_poll_irq(irq); + ADD_STATS(taken_slow_spurious, !xen_test_irq_pending(irq)); kstat_incr_irqs_this_cpu(irq, irq_to_desc(irq)); out: - unspinning_lock(xl, prev); - spin_time_accum_blocked(start); - - return ret; -} - -static inline void __xen_spin_lock(struct arch_spinlock *lock, bool irq_enable) -{ - struct xen_spinlock *xl = (struct xen_spinlock *)lock; - unsigned timeout; - u8 oldval; - u64 start_spin; - - ADD_STATS(taken, 1); - - start_spin = spin_time_start(); - - do { - u64 start_spin_fast = spin_time_start(); - - timeout = TIMEOUT; + cpumask_clear_cpu(cpu, &waiting_cpus); + w->lock = NULL; - asm("1: xchgb %1,%0\n" - " testb %1,%1\n" - " jz 3f\n" - "2: rep;nop\n" - " cmpb $0,%0\n" - " je 1b\n" - " dec %2\n" - " jnz 2b\n" - "3:\n" - : "+m" (xl->lock), "=q" (oldval), "+r" (timeout) - : "1" (1) - : "memory"); + local_irq_restore(flags); - spin_time_accum_spinning(start_spin_fast); - - } while (unlikely(oldval != 0 && - (TIMEOUT == ~0 || !xen_spin_lock_slow(lock, irq_enable)))); - - spin_time_accum_total(start_spin); -} - -static void xen_spin_lock(struct arch_spinlock *lock) -{ - __xen_spin_lock(lock, false); -} - -static void xen_spin_lock_flags(struct arch_spinlock *lock, unsigned long flags) -{ - __xen_spin_lock(lock, !raw_irqs_disabled_flags(flags)); + spin_time_accum_blocked(start); } -static noinline void xen_spin_unlock_slow(struct xen_spinlock *xl) +static void xen_unlock_kick(struct arch_spinlock *lock, __ticket_t next) { int cpu; ADD_STATS(released_slow, 1); - for_each_online_cpu(cpu) { - /* XXX should mix up next cpu selection */ - if (per_cpu(lock_spinners, cpu) == xl) { + for_each_cpu(cpu, &waiting_cpus) { + const struct xen_lock_waiting *w = &per_cpu(lock_waiting, cpu); + + if (w->lock == lock && w->want == next) { ADD_STATS(released_slow_kicked, 1); xen_send_IPI_one(cpu, XEN_SPIN_UNLOCK_VECTOR); break; @@ -320,28 +163,6 @@ static noinline void xen_spin_unlock_slow(struct xen_spinlock *xl) } } -static void xen_spin_unlock(struct arch_spinlock *lock) -{ - struct xen_spinlock *xl = (struct xen_spinlock *)lock; - - ADD_STATS(released, 1); - - smp_wmb(); /* make sure no writes get moved after unlock */ - xl->lock = 0; /* release lock */ - - /* - * Make sure unlock happens before checking for waiting - * spinners. We need a strong barrier to enforce the - * write-read ordering to different memory locations, as the - * CPU makes no implied guarantees about their ordering. - */ - mb(); - - if (unlikely(xl->spinners)) - xen_spin_unlock_slow(xl); -} -#endif - static irqreturn_t dummy_handler(int irq, void *dev_id) { BUG(); @@ -376,14 +197,8 @@ void xen_uninit_lock_cpu(int cpu) void __init xen_init_spinlocks(void) { -#if 0 - pv_lock_ops.spin_is_locked = xen_spin_is_locked; - pv_lock_ops.spin_is_contended = xen_spin_is_contended; - pv_lock_ops.spin_lock = xen_spin_lock; - pv_lock_ops.spin_lock_flags = xen_spin_lock_flags; - pv_lock_ops.spin_trylock = xen_spin_trylock; - pv_lock_ops.spin_unlock = xen_spin_unlock; -#endif + pv_lock_ops.lock_spinning = xen_lock_spinning; + pv_lock_ops.unlock_kick = xen_unlock_kick; } #ifdef CONFIG_XEN_DEBUG_FS @@ -401,37 +216,21 @@ static int __init xen_spinlock_debugfs(void) debugfs_create_u8("zero_stats", 0644, d_spin_debug, &zero_stats); - debugfs_create_u32("timeout", 0644, d_spin_debug, &lock_timeout); - - debugfs_create_u64("taken", 0444, d_spin_debug, &spinlock_stats.taken); debugfs_create_u32("taken_slow", 0444, d_spin_debug, &spinlock_stats.taken_slow); - debugfs_create_u32("taken_slow_nested", 0444, d_spin_debug, - &spinlock_stats.taken_slow_nested); debugfs_create_u32("taken_slow_pickup", 0444, d_spin_debug, &spinlock_stats.taken_slow_pickup); debugfs_create_u32("taken_slow_spurious", 0444, d_spin_debug, &spinlock_stats.taken_slow_spurious); - debugfs_create_u32("taken_slow_irqenable", 0444, d_spin_debug, - &spinlock_stats.taken_slow_irqenable); - debugfs_create_u64("released", 0444, d_spin_debug, &spinlock_stats.released); debugfs_create_u32("released_slow", 0444, d_spin_debug, &spinlock_stats.released_slow); debugfs_create_u32("released_slow_kicked", 0444, d_spin_debug, &spinlock_stats.released_slow_kicked); - debugfs_create_u64("time_spinning", 0444, d_spin_debug, - &spinlock_stats.time_spinning); debugfs_create_u64("time_blocked", 0444, d_spin_debug, &spinlock_stats.time_blocked); - debugfs_create_u64("time_total", 0444, d_spin_debug, - &spinlock_stats.time_total); - xen_debugfs_create_u32_array("histo_total", 0444, d_spin_debug, - spinlock_stats.histo_spin_total, HISTO_BUCKETS + 1); - xen_debugfs_create_u32_array("histo_spinning", 0444, d_spin_debug, - spinlock_stats.histo_spin_spinning, HISTO_BUCKETS + 1); xen_debugfs_create_u32_array("histo_blocked", 0444, d_spin_debug, spinlock_stats.histo_spin_blocked, HISTO_BUCKETS + 1); -- 1.7.6 _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel From xen-devel-bounces@lists.xensource.com Wed Sep 14 17:52:22 2011 Return-path: Envelope-to: www-data@lists.xensource.com Delivery-date: Wed, 14 Sep 2011 17:52:22 -0700 Received: from localhost ([127.0.0.1] helo=lists.colo.xensource.com) by lists.xensource.com with esmtp (Exim 4.43) id 1R40Bi-0005nA-R2; Wed, 14 Sep 2011 17:52:22 -0700 Received: from mail182.messagelabs.com ([85.158.139.83]) by lists.xensource.com with esmtp (Exim 4.43) id 1R402h-0001eW-WA for xen-devel@lists.xensource.com; Wed, 14 Sep 2011 17:43:04 -0700 X-Env-Sender: jeremy@goop.org X-Msg-Ref: server-8.tower-182.messagelabs.com!1316047379!18382504!1 X-Originating-IP: [74.207.240.146] X-StarScan-Version: 6.4.1; banners=-,-,- X-VirusChecked: Checked Received: (qmail 3904 invoked from network); 15 Sep 2011 00:43:00 -0000 Received: from claw.goop.org (HELO claw.goop.org) (74.207.240.146) by server-8.tower-182.messagelabs.com with DHE-RSA-AES256-SHA encrypted SMTP; 15 Sep 2011 00:43:00 -0000 Received: from saboo.goop.org (unknown [IPv6:2001:470:1f05:899:f0ec:7fff:fed1:2097]) (Authenticated sender: smtp-saboo) by claw.goop.org (Postfix) with ESMTPSA id C11679134; Wed, 14 Sep 2011 17:42:50 -0700 (PDT) Received: by saboo.goop.org (Postfix, from userid 500) id 1B17D20C43; Wed, 14 Sep 2011 17:31:44 -0700 (PDT) From: Jeremy Fitzhardinge To: "H. Peter Anvin" Date: Wed, 14 Sep 2011 17:31:33 -0700 Message-Id: X-Mailer: git-send-email 1.7.6 In-Reply-To: References: In-Reply-To: References: Cc: Marcelo Tosatti , Nick Piggin , KVM , Peter Zijlstra , the arch/x86 maintainers , Linux Kernel Mailing List , Andi Kleen , Avi Kivity , Jeremy Fitzhardinge , Ingo Molnar , Linus Torvalds , Xen Devel Subject: [Xen-devel] [PATCH 01/10] x86/ticketlocks: remove obsolete comment X-BeenThere: xen-devel@lists.xensource.com X-Mailman-Version: 2.1.5 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xensource.com Errors-To: xen-devel-bounces@lists.xensource.com From: Jeremy Fitzhardinge The note about partial registers is not really relevent now that we rely on gcc to generate all the assembler. Signed-off-by: Jeremy Fitzhardinge --- arch/x86/include/asm/spinlock.h | 4 ---- 1 files changed, 0 insertions(+), 4 deletions(-) diff --git a/arch/x86/include/asm/spinlock.h b/arch/x86/include/asm/spinlock.h index f5695ee..972c260 100644 --- a/arch/x86/include/asm/spinlock.h +++ b/arch/x86/include/asm/spinlock.h @@ -49,10 +49,6 @@ * issues and should be optimal for the uncontended case. Note the tail must be * in the high part, because a wide xadd increment of the low part would carry * up and contaminate the high part. - * - * With fewer than 2^8 possible CPUs, we can use x86's partial registers to - * save some instructions and make the code more elegant. There really isn't - * much between them in performance though, especially as locks are out of line. */ static __always_inline void __ticket_spin_lock(arch_spinlock_t *lock) { -- 1.7.6 _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel From xen-devel-bounces@lists.xensource.com Wed Sep 14 18:19:46 2011 Return-path: Envelope-to: www-data@lists.xensource.com Delivery-date: Wed, 14 Sep 2011 18:19:46 -0700 Received: from localhost ([127.0.0.1] helo=lists.colo.xensource.com) by lists.xensource.com with esmtp (Exim 4.43) id 1R40cE-0006ZH-MP; Wed, 14 Sep 2011 18:19:46 -0700 Received: from mail174.messagelabs.com ([85.158.138.51]) by lists.xensource.com with smtp (Exim 4.43) id 1R40bC-0006M9-Vr for xen-devel@lists.xensource.com; Wed, 14 Sep 2011 18:18:43 -0700 X-Env-Sender: jim_burn@bellsouth.net X-Msg-Ref: server-7.tower-174.messagelabs.com!1316049519!31435613!1 X-Originating-IP: [98.139.44.180] X-StarScan-Version: 6.4.1; banners=-,-,- X-VirusChecked: Checked Received: (qmail 11059 invoked from network); 15 Sep 2011 01:18:39 -0000 Received: from nm23-vm0.access.bullet.mail.sp2.yahoo.com (HELO nm23-vm0.access.bullet.mail.sp2.yahoo.com) (98.139.44.180) by server-7.tower-174.messagelabs.com with SMTP; 15 Sep 2011 01:18:39 -0000 Received: from [98.139.44.101] by nm23.access.bullet.mail.sp2.yahoo.com with NNFMP; 15 Sep 2011 01:18:38 -0000 Received: from [98.139.44.88] by tm6.access.bullet.mail.sp2.yahoo.com with NNFMP; 15 Sep 2011 01:18:38 -0000 Received: from [127.0.0.1] by omp1025.access.mail.sp2.yahoo.com with NNFMP; 15 Sep 2011 01:18:38 -0000 X-Yahoo-Newman-Id: 709483.84835.bm@omp1025.access.mail.sp2.yahoo.com Received: (qmail 14443 invoked from network); 15 Sep 2011 01:18:38 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=bellsouth.net; s=s1024; t=1316049518; bh=E+7BZnkUQXoUQhaIDIJbqqTQ40lBoSqTG0Vpl5iQJgI=; h=X-Yahoo-Newman-Property:X-YMail-OSG:X-Yahoo-SMTP:Received:From:To:Cc:Subject:Date:Message-ID:User-Agent:In-Reply-To:References:MIME-Version:Content-Transfer-Encoding:Content-Type; b=o/eyEnSh7M7PwQrei54wfZrUpRnQmoqCXTmLisCn9sxauuxDm4a+AAHva2WOQGktIsku62BgIKHSfsPW4c/CSvRvMbQ/FhZQjHrVAFDkjLP+VfjLYp0MaN73lK1X455f96PvESRm/t8n6Om2LbuFG74XrAy0EbWMaCjY8h1dtuY= X-Yahoo-Newman-Property: ymail-3 X-YMail-OSG: MH.3j.IVM1nFtdrdVlePdConBE4I7SDQg2fUYxYfiNbDNAj xvojl7PFVjQc1BAiEn880xo9gXnG2d.nsRfXTQNF1.Xm5rLXnyMRc8J9hBbS wfIhtrp3SKuY2nXxwkiViZbwxs3x6y7Y5.pRF8gmn3Rs4Gku_0.2GGyPwHJU vc4p1i0Qm.wNEtDVP9KpQnwqW9a60GIGo9dRU8FE51XBVlexm5BUmSwvvdxv aoihwHxSDhGjDDaBMOENjPZQbk39UwZKZp3o7TZ2u3GsImYMVxVMXSqnezev Ik0bIM3HNzYiBsNI9lZAzLGTW3B0zjavRB5tYPTvsWA0r8O9_hDxIPuRMIgw .SXgXqTBDnnCwvMdIZMw.R5z64nYR4ZPtGlh._XlRKLEkw6mLotTtadNu17f 6u8jMuFKCmcn_55R_ijO9PV1ZQjjeQ1Di7TpExOaXcWsgx1caBs2G2.BJAro 8pV3Ga_mUBrp8L6XWbkSt5i3ebgcf9pwD8vuwLsxouDMQfp0ca77GWIgbYhw PqjTvPIQVhJy2CCyd2Myyo4_AkaFojy7OtHhO3U5zUchBiIkXTf._7COqQA_ QiLc92vkyeQZhEP1mRvBHKAlwPcchxp1ua498yoAyYGKvCUSKwJ7At_M4 X-Yahoo-SMTP: g0AhWW2swBA2djJKuhuwxPlPqLrHlDrycdPnfR9kZNrpKCA- Received: from dell4550.localnet (jim_burn@98.92.71.91 with plain) by smtp102.sbc.mail.gq1.yahoo.com with SMTP; 14 Sep 2011 18:18:37 -0700 PDT From: jim burns To: M A Young , Pasi =?ISO-8859-1?Q?K=E4rkk=E4inen?= Subject: Re: [Fedora-xen] [Xen-devel] Re: [Xen-users] Continuing BUG:-iness booting Fedora Rawhide 3.1.0-rc's (was Summary: Experiences setting up a debug serial port) Date: Wed, 14 Sep 2011 21:18:25 -0400 Message-ID: <1673553.kg3ZcTGbSX@dell4550> User-Agent: KMail/4.7.1 (Linux/2.6.37.6-0.7-default; KDE/4.7.1; i686; ; ) In-Reply-To: References: <201107231426.56811.jim_burn@bellsouth.net> <20110914221254.GB3742@phenom.oracle.com> MIME-Version: 1.0 Content-Transfer-Encoding: 7Bit Content-Type: text/plain; charset="us-ascii" Cc: xen-devel@lists.xensource.com, Fedora Xen List , Konrad Rzeszutek Wilk , Ian Campbell , todd.deshane@xen.org, xen-users@lists.xensource.com X-BeenThere: xen-devel@lists.xensource.com X-Mailman-Version: 2.1.5 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xensource.com Errors-To: xen-devel-bounces@lists.xensource.com On Thu September 15 2011, 12:38:26 AM, M A Young wrote: > I have a (temporary) F17 kernel with the patch from > http://oss.oracle.com/git/kwilk/xen.git/?p=kwilk/xen.git;a=commit;h=a7079a64 > 04ed2106315327fff6be3464d10814e7 (which I assume is the same patch) applied > building at > http://koji.fedoraproject.org/koji/taskinfo?taskID=3352367 > if you want to test it. Oh - the patch is to the kernel, not to xen. I misread it. Ok - I downloaded http://koji.fedoraproject.org/koji/getfile?taskID=3352368&name=kernel-3.1.0-0.rc6.git0.0.xendom0.fc17.x86_64.rpm I hope that's right. I'll try it tomorrow. Thanx. _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel From xen-devel-bounces@lists.xensource.com Wed Sep 14 18:33:16 2011 Return-path: Envelope-to: www-data@lists.xensource.com Delivery-date: Wed, 14 Sep 2011 18:33:16 -0700 Received: from localhost ([127.0.0.1] helo=lists.colo.xensource.com) by lists.xensource.com with esmtp (Exim 4.43) id 1R40pH-0007to-S4; Wed, 14 Sep 2011 18:33:15 -0700 Received: from mail174.messagelabs.com ([85.158.138.51]) by lists.xensource.com with esmtp (Exim 4.43) id 1R40oY-0007f6-Ry for xen-devel@lists.xensource.com; Wed, 14 Sep 2011 18:32:31 -0700 X-Env-Sender: lulei.wm@gmail.com X-Msg-Ref: server-7.tower-174.messagelabs.com!1316050179!31436077!1 X-Originating-IP: [209.85.160.171] X-StarScan-Version: 6.4.1; banners=-,-,- X-VirusChecked: Checked Received: (qmail 22346 invoked from network); 15 Sep 2011 01:29:40 -0000 Received: from mail-gy0-f171.google.com (HELO mail-gy0-f171.google.com) (209.85.160.171) by server-7.tower-174.messagelabs.com with RC4-SHA encrypted SMTP; 15 Sep 2011 01:29:40 -0000 Received: by gyh3 with SMTP id 3so2694204gyh.30 for ; Wed, 14 Sep 2011 18:29:39 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:date:message-id:subject:from:to:content-type; bh=YZ3G5X05ORYduqXjrVboKr5x4mdX9xhYUAIT5H7KP6I=; b=WRzQ5ecxcND8E7TSLJU0MnfOVyhjQc7OPtcudggAqacszYaY3Iz+OxKUojwFvR151+ X81UkxICXZglwiStNkp2sMkf+Qeug2Jy/0MJHXnnSi/cD8zu4+pfnNC4Bavx9a6/3gWN Tk6nI2ZN+xaqUCoXlAg46WDeoGk/DnXNn/nRo= MIME-Version: 1.0 Received: by 10.150.61.4 with SMTP id j4mr597244yba.354.1316050179043; Wed, 14 Sep 2011 18:29:39 -0700 (PDT) Received: by 10.150.198.7 with HTTP; Wed, 14 Sep 2011 18:29:38 -0700 (PDT) Date: Wed, 14 Sep 2011 21:29:38 -0400 Message-ID: From: Lei Lu To: xen-devel@lists.xensource.com Content-Type: text/plain; charset=ISO-8859-1 Subject: [Xen-devel] xm sched-credit problem X-BeenThere: xen-devel@lists.xensource.com X-Mailman-Version: 2.1.5 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xensource.com Errors-To: xen-devel-bounces@lists.xensource.com Hi all, I have met a very strange problem regarding CPU Cap setting. The thing is I am trying to dynamically change the CPU cap for one guest domain, so I try the xm sched-credit command as following [root@llu]# xm sched-credit Name ID Weight Cap Domain-0 0 256 0 vm8 13 256 40 ----------------------------------------------------------- Okay, I want to change its CPU cap to 90%, so, I run the command ----------------------------------------------------------- [root@llu]# xm sched-credit -d 13 -c 90 ----------------------------------------------------------- It works at first ----------------------------------------------------------- [root@llu]# xm sched-credit Name ID Weight Cap vm8 13 256 90 ----------------------------------------------------------- But after about 10 seconds, it automatically set back to 40 again. [root@llu]# xm sched-credit Name ID Weight Cap vm8 13 256 40 ------------------------------------------------------------- During those 10 seconds, it did set the CPU cap to 90 percent, which I have confirmed by running a compute intensive inside the guest VM. I can observer the 90% CPU through xentop in Dom-0. I am wondering why it is set back to 40? Is it a common issue or just for me. The version of xen is 3.3.1. The vm configuration file is here: kernel = "/boot/vmlinuz-2.6.18.8-xen" ramdisk = "/boot/initrd-2.6.18.8-xen.img" extra = "3" extra = "xencons=tty" memory = 1024 vcpus = 1 name = "vm8" vif = [ 'ip=172.16.2.108,bridge=xenbr0' ] disk = ['tap:aio:/root/local_VMs/vm8.img,sda1,w'] root = "/dev/sda1" Best, Lei _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel From xen-devel-bounces@lists.xensource.com Wed Sep 14 18:55:14 2011 Return-path: Envelope-to: www-data@lists.xensource.com Delivery-date: Wed, 14 Sep 2011 18:55:14 -0700 Received: from localhost ([127.0.0.1] helo=lists.colo.xensource.com) by lists.xensource.com with esmtp (Exim 4.43) id 1R41AY-00008p-N0; Wed, 14 Sep 2011 18:55:14 -0700 Received: from mail174.messagelabs.com ([85.158.138.51]) by lists.xensource.com with esmtp (Exim 4.43) id 1R419z-0008Ny-Hl for xen-devel@lists.xensource.com; Wed, 14 Sep 2011 18:54:39 -0700 X-Env-Sender: Ian.Jackson@eu.citrix.com X-Msg-Ref: server-2.tower-174.messagelabs.com!1316051676!31461461!1 X-Originating-IP: [62.200.22.115] X-StarScan-Version: 6.4.1; banners=-,-,- X-VirusChecked: Checked Received: (qmail 4578 invoked from network); 15 Sep 2011 01:54:36 -0000 Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115) by server-2.tower-174.messagelabs.com with RC4-SHA encrypted SMTP; 15 Sep 2011 01:54:36 -0000 X-IronPort-AV: E=Sophos;i="4.68,384,1312156800"; d="scan'208";a="7830295" Received: from lonpmailmx01.citrite.net ([10.30.203.162]) by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5; 15 Sep 2011 01:54:35 +0000 Received: from woking.xci-test.com (10.80.248.135) by smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id 8.3.137.0; Thu, 15 Sep 2011 02:54:35 +0100 Received: from osstest by woking.xci-test.com with local (Exim 4.69) (envelope-from ) id 1R419v-0008T6-7n; Thu, 15 Sep 2011 02:54:35 +0100 To: Message-ID: From: xen.org Date: Thu, 15 Sep 2011 02:54:35 +0100 MIME-Version: 1.0 Content-Type: text/plain Cc: ian.jackson@eu.citrix.com Subject: [Xen-devel] [xen-unstable test] 8940: tolerable FAIL X-BeenThere: xen-devel@lists.xensource.com X-Mailman-Version: 2.1.5 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xensource.com Errors-To: xen-devel-bounces@lists.xensource.com flight 8940 xen-unstable real [real] http://www.chiark.greenend.org.uk/~xensrcts/logs/8940/ Failures :-/ but no regressions. Tests which did not succeed, but are not blocking, including regressions (tests previously passed) regarded as allowable: test-amd64-amd64-xl-pcipt-intel 1 xen-build-check(1) blocked n/a test-amd64-i386-rhel6hvm-intel 1 xen-build-check(1) blocked n/a test-i386-i386-pv 1 xen-build-check(1) blocked n/a test-amd64-i386-pv 1 xen-build-check(1) blocked n/a test-amd64-amd64-pv 1 xen-build-check(1) blocked n/a test-i386-i386-xl 1 xen-build-check(1) blocked n/a build-amd64-pvops 4 kernel-build fail like 8937 test-amd64-i386-xl 1 xen-build-check(1) blocked n/a test-amd64-i386-xl-credit2 1 xen-build-check(1) blocked n/a test-amd64-i386-rhel6hvm-amd 1 xen-build-check(1) blocked n/a test-amd64-amd64-pair 1 xen-build-check(1) blocked n/a test-amd64-i386-pair 1 xen-build-check(1) blocked n/a test-i386-i386-pair 1 xen-build-check(1) blocked n/a build-i386-pvops 4 kernel-build fail like 8937 test-amd64-i386-xl-multivcpu 1 xen-build-check(1) blocked n/a test-amd64-amd64-xl-sedf 1 xen-build-check(1) blocked n/a test-amd64-i386-win-vcpus1 1 xen-build-check(1) blocked n/a test-amd64-i386-xl-win-vcpus1 1 xen-build-check(1) blocked n/a test-amd64-amd64-win 1 xen-build-check(1) blocked n/a test-amd64-i386-win 1 xen-build-check(1) blocked n/a test-amd64-amd64-xl-win 1 xen-build-check(1) blocked n/a test-amd64-amd64-xl 1 xen-build-check(1) blocked n/a test-i386-i386-xl-win 1 xen-build-check(1) blocked n/a test-i386-i386-win 1 xen-build-check(1) blocked n/a version targeted for testing: xen e90438f6e6d1 baseline version: xen e90438f6e6d1 jobs: build-amd64 pass build-i386 pass build-amd64-oldkern pass build-i386-oldkern pass build-amd64-pvops fail build-i386-pvops fail test-amd64-amd64-xl blocked test-amd64-i386-xl blocked test-i386-i386-xl blocked test-amd64-i386-rhel6hvm-amd blocked test-amd64-i386-xl-credit2 blocked test-amd64-amd64-xl-pcipt-intel blocked test-amd64-i386-rhel6hvm-intel blocked test-amd64-i386-xl-multivcpu blocked test-amd64-amd64-pair blocked test-amd64-i386-pair blocked test-i386-i386-pair blocked test-amd64-amd64-pv blocked test-amd64-i386-pv blocked test-i386-i386-pv blocked test-amd64-amd64-xl-sedf blocked test-amd64-i386-win-vcpus1 blocked test-amd64-i386-xl-win-vcpus1 blocked test-amd64-amd64-win blocked test-amd64-i386-win blocked test-i386-i386-win blocked test-amd64-amd64-xl-win blocked test-i386-i386-xl-win blocked ------------------------------------------------------------ sg-report-flight on woking.cam.xci-test.com logs: /home/xc_osstest/logs images: /home/xc_osstest/images Logs, config files, etc. are available at http://www.chiark.greenend.org.uk/~xensrcts/logs Test harness code can be found at http://xenbits.xensource.com/gitweb?p=osstest.git;a=summary Published tested tree is already up to date. _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel From xen-devel-bounces@lists.xensource.com Wed Sep 14 19:40:48 2011 Return-path: Envelope-to: www-data@lists.xensource.com Delivery-date: Wed, 14 Sep 2011 19:40:48 -0700 Received: from localhost ([127.0.0.1] helo=lists.colo.xensource.com) by lists.xensource.com with esmtp (Exim 4.43) id 1R41se-0001Ob-MO; Wed, 14 Sep 2011 19:40:48 -0700 Received: from mail182.messagelabs.com ([85.158.139.83]) by lists.xensource.com with esmtp (Exim 4.43) id 1R41rr-0001C5-7V for xen-devel@lists.xensource.com; Wed, 14 Sep 2011 19:40:00 -0700 X-Env-Sender: lulei.wm@gmail.com X-Msg-Ref: server-11.tower-182.messagelabs.com!1316054394!18383081!1 X-Originating-IP: [74.125.83.41] X-StarScan-Version: 6.4.1; banners=-,-,- X-VirusChecked: Checked Received: (qmail 10618 invoked from network); 15 Sep 2011 02:39:56 -0000 Received: from mail-gw0-f41.google.com (HELO mail-gw0-f41.google.com) (74.125.83.41) by server-11.tower-182.messagelabs.com with RC4-SHA encrypted SMTP; 15 Sep 2011 02:39:56 -0000 Received: by gwaa12 with SMTP id a12so2228253gwa.28 for ; Wed, 14 Sep 2011 19:39:54 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :content-type:content-transfer-encoding; bh=cpNDm/d1fv+msTMw2DfbVGZsoVpa3++RdgFj4AKG4Wk=; b=x9RDt0lLZzpWzEKX2/ZikfS8ikLKvXz6mrIDwINlL+Evn4HZozvkET+kMArhM4jVBM Puai2ilmYZg4k0h3JVy3z92AdtBtd/Wt50FK7w0Pr4BQo95Lg6lvhaPJuyoqRwtejiWL gpOyNEZ6VJazKwVuA8H+x8O2G1pPS2w6OG93c= MIME-Version: 1.0 Received: by 10.150.51.19 with SMTP id y19mr677970yby.12.1316054394723; Wed, 14 Sep 2011 19:39:54 -0700 (PDT) Received: by 10.150.198.7 with HTTP; Wed, 14 Sep 2011 19:39:54 -0700 (PDT) In-Reply-To: References: Date: Wed, 14 Sep 2011 22:39:54 -0400 Message-ID: From: Lei Lu To: xen-devel@lists.xensource.com Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Subject: [Xen-devel] Re: xm sched-credit problem X-BeenThere: xen-devel@lists.xensource.com X-Mailman-Version: 2.1.5 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xensource.com Errors-To: xen-devel-bounces@lists.xensource.com Not a problem any more. Lei On Wed, Sep 14, 2011 at 9:29 PM, Lei Lu wrote: > Hi all, > > I have met a very strange problem regarding CPU Cap setting. The thing > is I am trying to dynamically change the CPU cap for one guest domain, > so I try the xm sched-credit command as following > > [root@llu]# xm sched-credit > Name =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0ID We= ight =A0Cap > Domain-0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 0 =A0 = =A0256 =A0 =A00 > vm8 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 = =A013 =A0 =A0256 =A0 40 > ----------------------------------------------------------- > Okay, I want to change its CPU cap to 90%, so, I run the command > ----------------------------------------------------------- > [root@llu]# xm sched-credit -d 13 -c 90 > ----------------------------------------------------------- > It works at first > ----------------------------------------------------------- > [root@llu]# xm sched-credit > Name =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0ID We= ight =A0Cap > vm8 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 = =A013 =A0 =A0256 =A0 90 > ----------------------------------------------------------- > But after about 10 seconds, it automatically set back to 40 again. > [root@llu]# xm sched-credit > Name =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0ID We= ight =A0Cap > vm8 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 = =A013 =A0 =A0256 =A0 40 > ------------------------------------------------------------- > During those 10 seconds, it did set the CPU cap to 90 percent, which I > have confirmed by running a compute intensive inside the guest VM. I > can observer the 90% CPU through xentop in Dom-0. > > I am wondering why it is set back to 40? Is it a common issue or just > for me. The version of xen is 3.3.1. The vm configuration file is > here: > > kernel =3D "/boot/vmlinuz-2.6.18.8-xen" > ramdisk =3D "/boot/initrd-2.6.18.8-xen.img" > extra =3D "3" > extra =3D "xencons=3Dtty" > memory =3D 1024 > vcpus =3D 1 > name =3D "vm8" > vif =3D [ 'ip=3D172.16.2.108,bridge=3Dxenbr0' ] > disk =3D ['tap:aio:/root/local_VMs/vm8.img,sda1,w'] > root =3D "/dev/sda1" > > Best, > Lei > _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel From xen-devel-bounces@lists.xensource.com Wed Sep 14 22:14:18 2011 Return-path: Envelope-to: www-data@lists.xensource.com Delivery-date: Wed, 14 Sep 2011 22:14:18 -0700 Received: from localhost ([127.0.0.1] helo=lists.colo.xensource.com) by lists.xensource.com with esmtp (Exim 4.43) id 1R44HB-0005iX-VR; Wed, 14 Sep 2011 22:14:18 -0700 Received: from mail174.messagelabs.com ([85.158.138.51]) by lists.xensource.com with esmtp (Exim 4.43) id 1R44GP-0005WF-Al for xen-devel@lists.xensource.com; Wed, 14 Sep 2011 22:13:30 -0700 X-Env-Sender: Paul.Durrant@citrix.com X-Msg-Ref: server-11.tower-174.messagelabs.com!1316063604!31464234!1 X-Originating-IP: [66.165.176.89] X-StarScan-Version: 6.4.1; banners=-,-,- X-VirusChecked: Checked Received: (qmail 27698 invoked from network); 15 Sep 2011 05:13:25 -0000 Received: from smtp.citrix.com (HELO SMTP.CITRIX.COM) (66.165.176.89) by server-11.tower-174.messagelabs.com with RC4-SHA encrypted SMTP; 15 Sep 2011 05:13:25 -0000 X-IronPort-AV: E=Sophos;i="4.68,385,1312171200"; d="scan'208";a="17031678" Received: from ftlpmailmx01.citrite.net ([10.13.107.65]) by FTLPIPO01.CITRIX.COM with ESMTP/TLS/RC4-MD5; 15 Sep 2011 01:13:24 -0400 Received: from localhost.localdomain (10.80.16.52) by smtprelay.citrix.com (10.13.107.65) with Microsoft SMTP Server id 8.3.137.0; Thu, 15 Sep 2011 01:13:23 -0400 Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Mercurial-Node: a08073c5cf28ab76893102cc7a8d20bf3e5e15ae Message-ID: User-Agent: Mercurial-patchbomb/1.6.4 Date: Thu, 15 Sep 2011 06:13:06 +0100 From: Paul Durrant To: xen-devel@lists.xensource.com Subject: [Xen-devel] [PATCH] Tidy up the viridian code a little and flesh out the APIC assist MSR X-BeenThere: xen-devel@lists.xensource.com X-Mailman-Version: 2.1.5 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xensource.com Errors-To: xen-devel-bounces@lists.xensource.com # HG changeset patch # User Paul Durrant # Date 1316063461 -3600 # Node ID a08073c5cf28ab76893102cc7a8d20bf3e5e15ae # Parent e90438f6e6d1585a71b18784a99c162b5d95f390 Tidy up the viridian code a little and flesh out the APIC assist MSR handling code. We don't say we that handle that MSR but Windows assumes it. In Windows 7 it just wrote to the MSR and we used to handle that ok. Windows 8 also reads from the MSR so we need to keep a record of the contents. Signed-off-by: Paul Durrant diff -r e90438f6e6d1 -r a08073c5cf28 xen/arch/x86/hvm/viridian.c --- a/xen/arch/x86/hvm/viridian.c Wed Sep 14 11:38:13 2011 +0100 +++ b/xen/arch/x86/hvm/viridian.c Thu Sep 15 06:11:01 2011 +0100 @@ -96,9 +96,43 @@ int cpuid_viridian_leaves(unsigned int l return 1; } -static void enable_hypercall_page(void) +void dump_guest_os_id(struct domain *d) { - struct domain *d = current->domain; + gdprintk(XENLOG_INFO, "GUEST_OS_ID:\n"); + gdprintk(XENLOG_INFO, "\tvendor: %x\n", + d->arch.hvm_domain.viridian.guest_os_id.fields.vendor); + gdprintk(XENLOG_INFO, "\tos: %x\n", + d->arch.hvm_domain.viridian.guest_os_id.fields.os); + gdprintk(XENLOG_INFO, "\tmajor: %x\n", + d->arch.hvm_domain.viridian.guest_os_id.fields.major); + gdprintk(XENLOG_INFO, "\tminor: %x\n", + d->arch.hvm_domain.viridian.guest_os_id.fields.minor); + gdprintk(XENLOG_INFO, "\tsp: %x\n", + d->arch.hvm_domain.viridian.guest_os_id.fields.service_pack); + gdprintk(XENLOG_INFO, "\tbuild: %x\n", + d->arch.hvm_domain.viridian.guest_os_id.fields.build_number); +} + +void dump_hypercall(struct domain *d) +{ + gdprintk(XENLOG_INFO, "HYPERCALL:\n"); + gdprintk(XENLOG_INFO, "\tenabled: %x\n", + d->arch.hvm_domain.viridian.hypercall_gpa.fields.enabled); + gdprintk(XENLOG_INFO, "\tpfn: %lx\n", + (unsigned long)d->arch.hvm_domain.viridian.hypercall_gpa.fields.pfn); +} + +void dump_apic_assist(struct vcpu *v) +{ + gdprintk(XENLOG_INFO, "APIC_ASSIST[%d]:\n", v->vcpu_id); + gdprintk(XENLOG_INFO, "\tenabled: %x\n", + v->arch.hvm_vcpu.viridian.apic_assist.fields.enabled); + gdprintk(XENLOG_INFO, "\tpfn: %lx\n", + (unsigned long)v->arch.hvm_vcpu.viridian.apic_assist.fields.pfn); +} + +static void enable_hypercall_page(struct domain *d) +{ unsigned long gmfn = d->arch.hvm_domain.viridian.hypercall_gpa.fields.pfn; unsigned long mfn = gmfn_to_mfn(d, gmfn); uint8_t *p; @@ -130,9 +164,43 @@ static void enable_hypercall_page(void) put_page_and_type(mfn_to_page(mfn)); } +void initialize_apic_assist(struct vcpu *v) +{ + struct domain *d = v->domain; + unsigned long gmfn = v->arch.hvm_vcpu.viridian.apic_assist.fields.pfn; + unsigned long mfn = gmfn_to_mfn(d, gmfn); + uint8_t *p; + + /* + * We don't support the APIC assist page, and that fact is reflected in + * our CPUID flags. However, Newer versions of Windows have a bug which + * means that they don't recognise that, and tries to use the page + * anyway. We therefore have to fake up just enough to keep windows happy. + * + * See http://msdn.microsoft.com/en-us/library/ff538657%28VS.85%29.aspx for + * details of how Windows uses the page. + */ + + if ( !mfn_valid(mfn) || + !get_page_and_type(mfn_to_page(mfn), d, PGT_writable_page) ) + { + gdprintk(XENLOG_WARNING, "Bad GMFN %lx (MFN %lx)\n", gmfn, mfn); + return; + } + + p = map_domain_page(mfn); + + *(u32 *)p = 0; + + unmap_domain_page(p); + + put_page_and_type(mfn_to_page(mfn)); +} + int wrmsr_viridian_regs(uint32_t idx, uint64_t val) { - struct domain *d = current->domain; + struct vcpu *v = current; + struct domain *d = v->domain; if ( !is_viridian_domain(d) ) return 0; @@ -142,44 +210,29 @@ int wrmsr_viridian_regs(uint32_t idx, ui case VIRIDIAN_MSR_GUEST_OS_ID: perfc_incr(mshv_wrmsr_osid); d->arch.hvm_domain.viridian.guest_os_id.raw = val; - gdprintk(XENLOG_INFO, "Guest os:\n"); - gdprintk(XENLOG_INFO, "\tvendor: %x\n", - d->arch.hvm_domain.viridian.guest_os_id.fields.vendor); - gdprintk(XENLOG_INFO, "\tos: %x\n", - d->arch.hvm_domain.viridian.guest_os_id.fields.os); - gdprintk(XENLOG_INFO, "\tmajor: %x\n", - d->arch.hvm_domain.viridian.guest_os_id.fields.major); - gdprintk(XENLOG_INFO, "\tminor: %x\n", - d->arch.hvm_domain.viridian.guest_os_id.fields.minor); - gdprintk(XENLOG_INFO, "\tsp: %x\n", - d->arch.hvm_domain.viridian.guest_os_id.fields.service_pack); - gdprintk(XENLOG_INFO, "\tbuild: %x\n", - d->arch.hvm_domain.viridian.guest_os_id.fields.build_number); + dump_guest_os_id(d); break; case VIRIDIAN_MSR_HYPERCALL: perfc_incr(mshv_wrmsr_hc_page); - gdprintk(XENLOG_INFO, "Set hypercall page %"PRIx64".\n", val); - if ( d->arch.hvm_domain.viridian.guest_os_id.raw == 0 ) - break; d->arch.hvm_domain.viridian.hypercall_gpa.raw = val; + dump_hypercall(d); if ( d->arch.hvm_domain.viridian.hypercall_gpa.fields.enabled ) - enable_hypercall_page(); + enable_hypercall_page(d); break; case VIRIDIAN_MSR_VP_INDEX: perfc_incr(mshv_wrmsr_vp_index); - gdprintk(XENLOG_INFO, "Set VP index %"PRIu64".\n", val); break; case VIRIDIAN_MSR_EOI: perfc_incr(mshv_wrmsr_eoi); - vlapic_EOI_set(vcpu_vlapic(current)); + vlapic_EOI_set(vcpu_vlapic(v)); break; case VIRIDIAN_MSR_ICR: { u32 eax = (u32)val, edx = (u32)(val >> 32); - struct vlapic *vlapic = vcpu_vlapic(current); + struct vlapic *vlapic = vcpu_vlapic(v); perfc_incr(mshv_wrmsr_icr); eax &= ~(1 << 12); edx &= 0xff000000; @@ -191,31 +244,15 @@ int wrmsr_viridian_regs(uint32_t idx, ui case VIRIDIAN_MSR_TPR: perfc_incr(mshv_wrmsr_tpr); - vlapic_set_reg(vcpu_vlapic(current), APIC_TASKPRI, (uint8_t)val); + vlapic_set_reg(vcpu_vlapic(v), APIC_TASKPRI, (uint8_t)val); break; case VIRIDIAN_MSR_APIC_ASSIST: - /* - * We don't support the APIC assist page, and that fact is reflected in - * our CPUID flags. However, Windows 7 build 7000 has a bug which means - * that it doesn't recognise that, and tries to use the page anyway. We - * therefore have to fake up just enough to keep win7 happy. - * Fortunately, that's really easy: just setting the first four bytes - * in the page to zero effectively disables the page again, so that's - * what we do. Semantically, the first four bytes are supposed to be a - * flag saying whether the guest really needs to issue an EOI. Setting - * that flag to zero means that it must always issue one, which is what - * we want. Once a page has been repurposed as an APIC assist page the - * guest isn't allowed to set anything in it, so the flag remains zero - * and all is fine. The guest is allowed to clear flags in the page, - * but that doesn't cause us any problems. - */ - if ( val & 1 ) /* APIC assist page enabled? */ - { - uint32_t word = 0; - paddr_t page_start = val & ~1ul; - (void)hvm_copy_to_guest_phys(page_start, &word, sizeof(word)); - } + perfc_incr(mshv_wrmsr_apic_msr); + v->arch.hvm_vcpu.viridian.apic_assist.raw = val; + dump_apic_assist(v); + if (v->arch.hvm_vcpu.viridian.apic_assist.fields.enabled) + initialize_apic_assist(v); break; default: @@ -228,20 +265,21 @@ int wrmsr_viridian_regs(uint32_t idx, ui int rdmsr_viridian_regs(uint32_t idx, uint64_t *val) { struct vcpu *v = current; + struct domain *d = v->domain; - if ( !is_viridian_domain(v->domain) ) + if ( !is_viridian_domain(d) ) return 0; switch ( idx ) { case VIRIDIAN_MSR_GUEST_OS_ID: perfc_incr(mshv_rdmsr_osid); - *val = v->domain->arch.hvm_domain.viridian.guest_os_id.raw; + *val = d->arch.hvm_domain.viridian.guest_os_id.raw; break; case VIRIDIAN_MSR_HYPERCALL: perfc_incr(mshv_rdmsr_hc_page); - *val = v->domain->arch.hvm_domain.viridian.hypercall_gpa.raw; + *val = d->arch.hvm_domain.viridian.hypercall_gpa.raw; break; case VIRIDIAN_MSR_VP_INDEX: @@ -260,6 +298,11 @@ int rdmsr_viridian_regs(uint32_t idx, ui *val = vlapic_get_reg(vcpu_vlapic(v), APIC_TASKPRI); break; + case VIRIDIAN_MSR_APIC_ASSIST: + perfc_incr(mshv_rdmsr_apic_msr); + *val = v->arch.hvm_vcpu.viridian.apic_assist.raw; + break; + default: return 0; } diff -r e90438f6e6d1 -r a08073c5cf28 xen/include/asm-x86/hvm/vcpu.h --- a/xen/include/asm-x86/hvm/vcpu.h Wed Sep 14 11:38:13 2011 +0100 +++ b/xen/include/asm-x86/hvm/vcpu.h Thu Sep 15 06:11:01 2011 +0100 @@ -23,6 +23,7 @@ #include #include #include +#include #include #include #include @@ -163,6 +164,8 @@ struct hvm_vcpu { int inject_trap; /* -1 for nothing to inject */ int inject_error_code; unsigned long inject_cr2; + + struct viridian_vcpu viridian; }; #endif /* __ASM_X86_HVM_VCPU_H__ */ diff -r e90438f6e6d1 -r a08073c5cf28 xen/include/asm-x86/hvm/viridian.h --- a/xen/include/asm-x86/hvm/viridian.h Wed Sep 14 11:38:13 2011 +0100 +++ b/xen/include/asm-x86/hvm/viridian.h Thu Sep 15 06:11:01 2011 +0100 @@ -9,6 +9,21 @@ #ifndef __ASM_X86_HVM_VIRIDIAN_H__ #define __ASM_X86_HVM_VIRIDIAN_H__ +union viridian_apic_assist +{ uint64_t raw; + struct + { + uint64_t enabled:1; + uint64_t reserved_preserved:11; + uint64_t pfn:48; + } fields; +}; + +struct viridian_vcpu +{ + union viridian_apic_assist apic_assist; +}; + union viridian_guest_os_id { uint64_t raw; diff -r e90438f6e6d1 -r a08073c5cf28 xen/include/asm-x86/perfc_defn.h --- a/xen/include/asm-x86/perfc_defn.h Wed Sep 14 11:38:13 2011 +0100 +++ b/xen/include/asm-x86/perfc_defn.h Thu Sep 15 06:11:01 2011 +0100 @@ -120,12 +120,14 @@ PERFCOUNTER(mshv_rdmsr_hc_page, PERFCOUNTER(mshv_rdmsr_vp_index, "MS Hv rdmsr vp index") PERFCOUNTER(mshv_rdmsr_icr, "MS Hv rdmsr icr") PERFCOUNTER(mshv_rdmsr_tpr, "MS Hv rdmsr tpr") +PERFCOUNTER(mshv_rdmsr_apic_assist, "MS Hv rdmsr APIC assist") PERFCOUNTER(mshv_wrmsr_osid, "MS Hv wrmsr Guest OS ID") PERFCOUNTER(mshv_wrmsr_hc_page, "MS Hv wrmsr hypercall page") PERFCOUNTER(mshv_wrmsr_vp_index, "MS Hv wrmsr vp index") PERFCOUNTER(mshv_wrmsr_icr, "MS Hv wrmsr icr") PERFCOUNTER(mshv_wrmsr_tpr, "MS Hv wrmsr tpr") PERFCOUNTER(mshv_wrmsr_eoi, "MS Hv wrmsr eoi") +PERFCOUNTER(mshv_wrmsr_apic_assist, "MS Hv wrmsr APIC assist") PERFCOUNTER(realmode_emulations, "realmode instructions emulated") PERFCOUNTER(realmode_exits, "vmexits from realmode") _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel From xen-devel-bounces@lists.xensource.com Wed Sep 14 22:28:31 2011 Return-path: Envelope-to: www-data@lists.xensource.com Delivery-date: Wed, 14 Sep 2011 22:28:31 -0700 Received: from localhost ([127.0.0.1] helo=lists.colo.xensource.com) by lists.xensource.com with esmtp (Exim 4.43) id 1R44Ux-0006Iv-GH; Wed, 14 Sep 2011 22:28:31 -0700 Received: from mail21.messagelabs.com ([85.158.143.35]) by lists.xensource.com with smtp (Exim 4.43) id 1R44U6-00066C-71 for Xen-devel@lists.xensource.com; Wed, 14 Sep 2011 22:27:38 -0700 X-Env-Sender: sfr@canb.auug.org.au X-Msg-Ref: server-11.tower-21.messagelabs.com!1316064437!42636031!1 X-Originating-IP: [203.10.76.15] X-StarScan-Version: 6.4.1; banners=-,-,- X-VirusChecked: Checked Received: (qmail 10540 invoked from network); 15 Sep 2011 05:27:17 -0000 Received: from calzone.tip.net.au (HELO calzone.tip.net.au) (203.10.76.15) by server-11.tower-21.messagelabs.com with SMTP; 15 Sep 2011 05:27:17 -0000 Received: from canb.auug.org.au (ibmaus65.lnk.telstra.net [165.228.126.9]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by calzone.tip.net.au (Postfix) with ESMTPSA id 087D5128436; Thu, 15 Sep 2011 15:27:28 +1000 (EST) Date: Thu, 15 Sep 2011 15:27:23 +1000 From: Stephen Rothwell To: Jeremy Fitzhardinge , Xen Devel Message-Id: <20110915152723.b3bdd6a5478c810245fabca1@canb.auug.org.au> X-Mailer: Sylpheed 3.2.0beta3 (GTK+ 2.24.6; i486-pc-linux-gnu) Mime-Version: 1.0 Cc: linux-next@vger.kernel.org, linux-kernel@vger.kernel.org Subject: [Xen-devel] linux-next: build failure after merge of the xen tree X-BeenThere: xen-devel@lists.xensource.com X-Mailman-Version: 2.1.5 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0510431316==" Sender: xen-devel-bounces@lists.xensource.com Errors-To: xen-devel-bounces@lists.xensource.com --===============0510431316== Content-Type: multipart/signed; protocol="application/pgp-signature"; micalg="PGP-SHA1"; boundary="Signature=_Thu__15_Sep_2011_15_27_23_+1000_iNbQJWP5V6Zjpvq_" --Signature=_Thu__15_Sep_2011_15_27_23_+1000_iNbQJWP5V6Zjpvq_ Content-Type: text/plain; charset=US-ASCII Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Hi all, After merging the xen tree, today's linux-next build (x86_64 allmodconfig) failed like this: arch/x86/xen/time.c: In function 'xen_set_wallclock': arch/x86/xen/time.c:204:25: error: storage size of 'op' isn't known arch/x86/xen/time.c:211:11: error: 'XENPF_settime' undeclared (first use in= this function) arch/x86/xen/time.c:211:11: note: each undeclared identifier is reported on= ly once for each function it appears in arch/x86/xen/time.c:216:2: error: implicit declaration of function 'HYPERVI= SOR_dom0_op' arch/x86/xen/time.c:204:25: warning: unused variable 'op' Caused by commit 7b11a83f592a ("xen/dom0: set wallclock time in Xen"). I have used teh xen tree from next-20110914 for today. --=20 Cheers, Stephen Rothwell sfr@canb.auug.org.au http://www.canb.auug.org.au/~sfr/ --Signature=_Thu__15_Sep_2011_15_27_23_+1000_iNbQJWP5V6Zjpvq_ Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.11 (GNU/Linux) iQEcBAEBAgAGBQJOcYy7AAoJEDMEi1NhKgbsF5QH/R0nZNn+WOYh0T78XaKtBknj MElO5dSIxGgvblK0Cfq1OoTMNqVc246M5dMvTf+cA/FPaw7MYHXQHleENdcof3iE sMSEORCI2upM2tu+ZWFfr475+AId9ZDQ0OMQ1pLqDsluBoy6dAqKFdkc8KYT+fWS cJ9rrstjLOStuHledAtwYMJWzleIEQM6b/aeYv0lDu4cKyHdugm+JMuOPmzNGC0T kjWx5FObAg+ijLnGRZsitLwlMspoAG5JQlqZKpM379IrV5A4yC3si6rJyNMTZtI9 Gvske2RIDJhjKVtHCybTuqHI5Qaox+ieB506ZKWyW/QeaLMFxbh39HuWRQb7cyk= =/yH1 -----END PGP SIGNATURE----- --Signature=_Thu__15_Sep_2011_15_27_23_+1000_iNbQJWP5V6Zjpvq_-- --===============0510431316== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel --===============0510431316==-- From xen-devel-bounces@lists.xensource.com Wed Sep 14 23:05:10 2011 Return-path: Envelope-to: www-data@lists.xensource.com Delivery-date: Wed, 14 Sep 2011 23:05:10 -0700 Received: from localhost ([127.0.0.1] helo=lists.colo.xensource.com) by lists.xensource.com with esmtp (Exim 4.43) id 1R454P-0007Ll-Ku; Wed, 14 Sep 2011 23:05:09 -0700 Received: from mail216.messagelabs.com ([85.158.143.99]) by lists.xensource.com with esmtp (Exim 4.43) id 1R452A-00077P-K3; Wed, 14 Sep 2011 23:03:11 -0700 X-Env-Sender: hwang.jinho@gmail.com X-Msg-Ref: server-7.tower-216.messagelabs.com!1316066565!18323920!1 X-Originating-IP: [209.85.218.43] X-StarScan-Version: 6.4.1; banners=-,-,- X-VirusChecked: Checked Received: (qmail 14286 invoked from network); 15 Sep 2011 06:02:46 -0000 Received: from mail-yi0-f43.google.com (HELO mail-yi0-f43.google.com) (209.85.218.43) by server-7.tower-216.messagelabs.com with RC4-SHA encrypted SMTP; 15 Sep 2011 06:02:46 -0000 Received: by yic24 with SMTP id 24so1712313yic.30 for ; Wed, 14 Sep 2011 23:02:45 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:from:date:message-id:subject:to:content-type; bh=ODuZpDbNnLASL8L0CxhMp8NToK00vROyCQ7bxLrH4sc=; b=fhNkfZwwH9+jyriCtEkouknGJ40LFIWIcnJV8/yQ2MovEr3XfR/IvppMB//YnYDBWZ fFVEX99onJ2la1/eq8fonJD7Au4BPp/w2CAD/A2rzrSgxNKSfGERBXIESalYduuFgLyR 3vdQL5AP5PCNbZama7ElF4/sLRp1c3pZTGzhc= Received: by 10.150.215.17 with SMTP id n17mr801866ybg.6.1316066565267; Wed, 14 Sep 2011 23:02:45 -0700 (PDT) MIME-Version: 1.0 Received: by 10.151.154.16 with HTTP; Wed, 14 Sep 2011 23:02:25 -0700 (PDT) From: jinho hwang Date: Thu, 15 Sep 2011 02:02:25 -0400 Message-ID: To: xen-users@lists.xensource.com, xen-devel@lists.xensource.com Cc: Subject: [Xen-devel] [Xen-users] XENBUS waiting timeout X-BeenThere: xen-devel@lists.xensource.com X-Mailman-Version: 2.1.5 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0527783456==" Sender: xen-devel-bounces@lists.xensource.com Errors-To: xen-devel-bounces@lists.xensource.com --===============0527783456== Content-Type: multipart/alternative; boundary=000e0cd2e6ac1fa2d904acf4a062 --000e0cd2e6ac1fa2d904acf4a062 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Hi, I have used disk image to copy host fs to image file and boot a guest system. But, the system is dropped to shell and it also says that it can't find /dev/xvda1 which is the root fs. I have defined it in the configuratio= n file as follows: disk =3D [ 'tap:aio:/xen/XenGuest1.img,xvda1,w', 'tap:aio:/xen/XenGuest1.swap,xvda2,w' ] root =3D "/dev/xvda1 ro" Also, modified the fstab as follows: /dev/xvda1 / ext3 defaults 1 1 /dev/xvda2 none swap sw 0 0 none /dev/pts devpts gid=3D5,mode=3D620 0 0 none /dev/shm tmpfs defaults 0 0 none /proc proc defaults 0 0 none /sys sysfs defaults 0 0 The following is the error shown in the console. Using IPI No-Shortcut mode registered taskstats version 1 XENBUS: Waiting for devices to initialise: 295s...290s...285s...280s...275s...270s...265s...260s...255s...250s...245s.= ..240s...235s...230s...225s...220s...215s...210s...205s...200s...195s...190= s...185s...180s...175s...170s...165s...160s...155s...150s...145s...140s...1= 35s...130s...125s...120s...115s...110s...105s...100s...95s...90s...85s...80= s...75s...70s...65s...60s...55s...50s...45s...40s...35s...30s...25s...20s..= .15s...10s...5s...0s... XENBUS: Timeout connecting to device: device/vbd/51713 (local state 3, remote state 1) XENBUS: Timeout connecting to device: device/vbd/51714 (local state 3, remote state 1) XENBUS: Device with no driver: device/console/0 Magic number: 1:252:3141 Freeing unused kernel memory: 432k freed Write protecting the kernel text: 2984k Write protecting the kernel read-only data: 1452k Loading, please wait... mount: mounting none on /dev failed: No such device W: devtmpfs not available, falling back to tmpfs for /dev Begin: Loading essential drivers ... done. Begin: Running /scripts/init-premount ... done. Begin: Mounting root file system ... Begin: Running /scripts/local-top ... done. Gave up waiting for root device. Common problems: - Boot args (cat /proc/cmdline) - Check rootdelay=3D (did the system wait long enough?) - Check root=3D (did the system wait for the right device?) - Missing modules (cat /proc/modules; ls /dev) ALERT! /dev/xvda1 does not exist. Dropping to a shell! If anybody has any idea, please let me know. Thank you, Jinho --=20 Jinho Hwang PhD Student Department of Computer Science The George Washington University Washington, DC 20052 hwang.jinho@gmail.com (email) 276.336.0971 (Cell) 202.994.4875 (fax) 070.8285.6546 (myLg070) --000e0cd2e6ac1fa2d904acf4a062 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable

Hi,=A0

I have used disk image to copy hos= t fs to image file and boot a guest system. But, the system is dropped to s= hell and it also says that it can't find /dev/xvda1 which is the root f= s. I have defined it in the configuration file as follows:

disk =3D [ 'tap:aio:/xen/XenGuest1.img,xvda1,w= ', 'tap:aio:/xen/XenGuest1.swap,xvda2,w' ]
root =3D "/dev/xvda1 ro"

Also, mo= dified the fstab as follows:

/dev/xvda1 =A0 =A0 =A0 / =A0 =A0 =A0 =A0 =A0 =A0 = =A0 ext3 =A0 =A0defaults =A0 =A0 =A0 =A0 =A01 =A0 =A0 =A0 1
/dev/= xvda2 =A0 =A0 =A0 none =A0 =A0 =A0 =A0 =A0 =A0swap =A0 =A0sw =A0 =A0 =A0 = =A0 =A0 =A0 =A0 =A00 =A0 =A0 =A0 0
none =A0 =A0 =A0 =A0 =A0 =A0 /= dev/pts =A0 =A0 =A0 =A0devpts =A0gid=3D5,mode=3D620 =A0 =A00 =A0 =A0 =A0 0<= /div>
none =A0 =A0 =A0 =A0 =A0 =A0 /dev/shm =A0 =A0 =A0 =A0tmpfs =A0 default= s =A0 =A0 =A0 =A0 =A00 =A0 =A0 =A0 0
none =A0 =A0 =A0 =A0 =A0 =A0= /proc =A0 =A0 =A0 =A0 =A0 proc =A0 =A0defaults =A0 =A0 =A0 =A0 =A00 =A0 = =A0 =A0 0
none =A0 =A0 =A0 =A0 =A0 =A0 /sys =A0 =A0 =A0 =A0 =A0 = =A0sysfs =A0 defaults =A0 =A0 =A0 =A0 =A00 =A0 =A0 =A0 0

The following is the error shown in the console.= =A0

Using IPI No-Shortcut mode
regi= stered taskstats version 1
XENBUS: Waiting for devices to initial= ise: 295s...290s...285s...280s...275s...270s...265s...260s...255s...250s...= 245s...240s...235s...230s...225s...220s...215s...210s...205s...200s...195s.= ..190s...185s...180s...175s...170s...165s...160s...155s...150s...145s...140= s...135s...130s...125s...120s...115s...110s...105s...100s...95s...90s...85s= ...80s...75s...70s...65s...60s...55s...50s...45s...40s...35s...30s...25s...= 20s...15s...10s...5s...0s...
XENBUS: Timeout connecting to device: device/vbd/51713 (local state 3,= remote state 1)
XENBUS: Timeout connecting to device: device/vbd= /51714 (local state 3, remote state 1)
XENBUS: Device with no dri= ver: device/console/0
=A0 Magic number: 1:252:3141
Freeing unused kernel memory: 4= 32k freed
Write protecting the kernel text: 2984k
Write= protecting the kernel read-only data: 1452k
Loading, please wait= ...
mount: mounting none on /dev failed: No such device
W: devtm= pfs not available, falling back to tmpfs for /dev
Begin: Loading = essential drivers ... done.
Begin: Running /scripts/init-premount= ... done.
Begin: Mounting root file system ... Begin: Running /scripts/local-top= ... done.
Gave up waiting for root device. =A0Common problems:
=A0- Boot args (cat /proc/cmdline)
=A0 =A0- Check rootde= lay=3D (did the system wait long enough?)
=A0 =A0- Check root=3D (did the system wait for the right device?)
=A0- Missing modules (cat /proc/modules; ls /dev)
ALERT! = =A0/dev/xvda1 does not exist. =A0Dropping to a shell!

<= /div>
If anybody has any idea, please let me know.=A0

Th= ank you,

Jinho

--
Jin= ho Hwang
PhD Student
Department of Computer Science
The George Was= hington University
Washington, DC 20052
hwang.jinh= o@gmail.com (email)
276.336.0971 (Cell)
202.994.4875 (fax)
070= .8285.6546 (myLg070)
--000e0cd2e6ac1fa2d904acf4a062-- --===============0527783456== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel --===============0527783456==-- From xen-devel-bounces@lists.xensource.com Wed Sep 14 23:17:15 2011 Return-path: Envelope-to: www-data@lists.xensource.com Delivery-date: Wed, 14 Sep 2011 23:17:15 -0700 Received: from localhost ([127.0.0.1] helo=lists.colo.xensource.com) by lists.xensource.com with esmtp (Exim 4.43) id 1R45G7-0000HT-GY; Wed, 14 Sep 2011 23:17:15 -0700 Received: from mail182.messagelabs.com ([85.158.139.83]) by lists.xensource.com with esmtp (Exim 4.43) id 1R45Fb-0008Vk-FD for xen-devel@lists.xensource.com; Wed, 14 Sep 2011 23:16:43 -0700 X-Env-Sender: olaf@aepfle.de X-Msg-Ref: server-14.tower-182.messagelabs.com!1316067400!18228114!1 X-Originating-IP: [81.169.146.162] X-StarScan-Version: 6.4.1; banners=-,-,- X-VirusChecked: Checked Received: (qmail 2004 invoked from network); 15 Sep 2011 06:16:40 -0000 Received: from mo-p00-ob.rzone.de (HELO mo-p00-ob.rzone.de) (81.169.146.162) by server-14.tower-182.messagelabs.com with EDH-RSA-DES-CBC3-SHA encrypted SMTP; 15 Sep 2011 06:16:40 -0000 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; t=1316067399; l=3984; s=domk; d=aepfle.de; h=To:From:Date:References:In-Reply-To:Subject: Content-Transfer-Encoding:MIME-Version:Content-Type:X-RZG-CLASS-ID: X-RZG-AUTH; bh=jv1VF0tpb207XBkPj8zcrMqFI84=; b=moiABXcwmJBsRBwr7kIPUBwd3CkId+qZ+4OJl9zSXssKPSrG8XxIHirGN/PiX6EmAdO 5R74xjxkZbDnu3Pq2cIeX+mUCTC4FM9okXOlaQkyXj3w5qdKBTr8ccIQk2mH2PElZgPSm kmVwGDPObE9PKuaAmM1erwycRLPxdCcsjeY= X-RZG-AUTH: :P2EQZWCpfu+qG7CngxMFH1J+zrwiavkK6tmQaLfmxtMZ80VwmRNV69z6 X-RZG-CLASS-ID: mo00 Received: from probook.site (ip-80-226-24-14.vodafone-net.de [80.226.24.14]) by post.strato.de (mrclete mo43) (RZmta 26.7) with (EDH-RSA-DES-CBC3-SHA encrypted) ESMTPA id Q0588cn8F2m5pu for ; Thu, 15 Sep 2011 08:16:36 +0200 (MEST) Received: from probook.site (localhost [IPv6:::1]) by probook.site (Postfix) with ESMTP id AB50B18B6A for ; Thu, 15 Sep 2011 08:16:31 +0200 (CEST) Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Mercurial-Node: 2ff9871c02a1712d55addc2b30e4f7694e5b7ebe Message-Id: <2ff9871c02a1712d55ad.1316067392@probook.site> In-Reply-To: References: User-Agent: Mercurial-patchbomb/1.7.5 Date: Thu, 15 Sep 2011 08:16:32 +0200 From: Olaf Hering To: xen-devel@lists.xensource.com Subject: [Xen-devel] [PATCH 4 of 9] xenpaging: remove xc_dominfo_t from paging_t X-BeenThere: xen-devel@lists.xensource.com X-Mailman-Version: 2.1.5 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xensource.com Errors-To: xen-devel-bounces@lists.xensource.com # HG changeset patch # User Olaf Hering # Date 1316067227 -7200 # Node ID 2ff9871c02a1712d55addc2b30e4f7694e5b7ebe # Parent 1e5697849aa62c08651a613901dcf054ee652ea4 xenpaging: remove xc_dominfo_t from paging_t Remove xc_dominfo_t from paging_t, record only max_pages. This value is used to setup internal data structures. Signed-off-by: Olaf Hering diff -r 1e5697849aa6 -r 2ff9871c02a1 tools/xenpaging/policy_default.c --- a/tools/xenpaging/policy_default.c +++ b/tools/xenpaging/policy_default.c @@ -41,17 +41,17 @@ int policy_init(xenpaging_t *paging) int i; int rc = -ENOMEM; + max_pages = paging->max_pages; + /* Allocate bitmap for pages not to page out */ - bitmap = bitmap_alloc(paging->domain_info->max_pages); + bitmap = bitmap_alloc(max_pages); if ( !bitmap ) goto out; /* Allocate bitmap to track unusable pages */ - unconsumed = bitmap_alloc(paging->domain_info->max_pages); + unconsumed = bitmap_alloc(max_pages); if ( !unconsumed ) goto out; - max_pages = paging->domain_info->max_pages; - /* Initialise MRU list of paged in pages */ if ( paging->policy_mru_size > 0 ) mru_size = paging->policy_mru_size; diff -r 1e5697849aa6 -r 2ff9871c02a1 tools/xenpaging/xenpaging.c --- a/tools/xenpaging/xenpaging.c +++ b/tools/xenpaging/xenpaging.c @@ -164,6 +164,7 @@ static void *init_page(void) static xenpaging_t *xenpaging_init(domid_t domain_id, int num_pages) { xenpaging_t *paging; + xc_domaininfo_t domain_info; xc_interface *xch; xentoollog_logger *dbg = NULL; char *p; @@ -273,33 +274,29 @@ static xenpaging_t *xenpaging_init(domid paging->mem_event.port = rc; /* Get domaininfo */ - paging->domain_info = malloc(sizeof(xc_domaininfo_t)); - if ( paging->domain_info == NULL ) - { - ERROR("Error allocating memory for domain info"); - goto err; - } - rc = xc_domain_getinfolist(xch, paging->mem_event.domain_id, 1, - paging->domain_info); + &domain_info); if ( rc != 1 ) { ERROR("Error getting domain info"); goto err; } + /* Record number of max_pages */ + paging->max_pages = domain_info.max_pages; + /* Allocate bitmap for tracking pages that have been paged out */ - paging->bitmap = bitmap_alloc(paging->domain_info->max_pages); + paging->bitmap = bitmap_alloc(paging->max_pages); if ( !paging->bitmap ) { ERROR("Error allocating bitmap"); goto err; } - DPRINTF("max_pages = %"PRIx64"\n", paging->domain_info->max_pages); + DPRINTF("max_pages = %d\n", paging->max_pages); - if ( num_pages < 0 || num_pages > paging->domain_info->max_pages ) + if ( num_pages < 0 || num_pages > paging->max_pages ) { - num_pages = paging->domain_info->max_pages; + num_pages = paging->max_pages; DPRINTF("setting num_pages to %d\n", num_pages); } paging->num_pages = num_pages; @@ -334,7 +331,6 @@ static xenpaging_t *xenpaging_init(domid } free(paging->bitmap); - free(paging->domain_info); free(paging); } @@ -764,7 +760,7 @@ int main(int argc, char *argv[]) if ( interrupted == SIGTERM || interrupted == SIGINT ) { int num = 0; - for ( i = 0; i < paging->domain_info->max_pages; i++ ) + for ( i = 0; i < paging->max_pages; i++ ) { if ( test_bit(i, paging->bitmap) ) { @@ -780,7 +776,7 @@ int main(int argc, char *argv[]) */ if ( num ) page_in_trigger(); - else if ( i == paging->domain_info->max_pages ) + else if ( i == paging->max_pages ) break; } else diff -r 1e5697849aa6 -r 2ff9871c02a1 tools/xenpaging/xenpaging.h --- a/tools/xenpaging/xenpaging.h +++ b/tools/xenpaging/xenpaging.h @@ -44,11 +44,11 @@ typedef struct xenpaging { xc_interface *xc_handle; struct xs_handle *xs_handle; - xc_domaininfo_t *domain_info; - unsigned long *bitmap; mem_event_t mem_event; + /* number of pages for which data structures were allocated */ + int max_pages; int num_pages; int policy_mru_size; unsigned long pagein_queue[XENPAGING_PAGEIN_QUEUE_SIZE]; _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel From xen-devel-bounces@lists.xensource.com Wed Sep 14 23:18:13 2011 Return-path: Envelope-to: www-data@lists.xensource.com Delivery-date: Wed, 14 Sep 2011 23:18:13 -0700 Received: from localhost ([127.0.0.1] helo=lists.colo.xensource.com) by lists.xensource.com with esmtp (Exim 4.43) id 1R45H3-0000eo-KR; Wed, 14 Sep 2011 23:18:13 -0700 Received: from mail27.messagelabs.com ([193.109.254.147]) by lists.xensource.com with esmtp (Exim 4.43) id 1R45Fb-0008Vl-NU for xen-devel@lists.xensource.com; Wed, 14 Sep 2011 23:16:44 -0700 X-Env-Sender: olaf@aepfle.de X-Msg-Ref: server-13.tower-27.messagelabs.com!1316067388!40089725!1 X-Originating-IP: [81.169.146.161] X-StarScan-Version: 6.4.1; banners=-,-,- X-VirusChecked: Checked Received: (qmail 30818 invoked from network); 15 Sep 2011 06:16:29 -0000 Received: from mo-p00-ob.rzone.de (HELO mo-p00-ob.rzone.de) (81.169.146.161) by server-13.tower-27.messagelabs.com with EDH-RSA-DES-CBC3-SHA encrypted SMTP; 15 Sep 2011 06:16:29 -0000 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; t=1316067400; l=2938; s=domk; d=aepfle.de; h=To:From:Date:References:In-Reply-To:Subject: Content-Transfer-Encoding:MIME-Version:Content-Type:X-RZG-CLASS-ID: X-RZG-AUTH; bh=kRwscqs3OawxrMdznvz5bnI/VcU=; b=cuyPCDdimf8zew93UC3m+ztHiwisWttZqMEJhQ92oQnyfNzA27fp6pDg5XnN1BJslRF ZK/yguA+fDWGnB/DGttkWioXfI02D0auyDxU0PFYuQ3qCkeRy/nrByDyjN2cSbZCjg+uE nLpA3rFyZA89uPeKbXlZaIyd3pi3UMUFq3E= X-RZG-AUTH: :P2EQZWCpfu+qG7CngxMFH1J+zrwiavkK6tmQaLfmxtMZ80VwmRNV69z6 X-RZG-CLASS-ID: mo00 Received: from probook.site (ip-80-226-24-14.vodafone-net.de [80.226.24.14]) by smtp.strato.de (fruni mo38) (RZmta 26.7) with (EDH-RSA-DES-CBC3-SHA encrypted) ESMTPA id j03ab4n8F5tEqJ for ; Thu, 15 Sep 2011 08:16:38 +0200 (MEST) Received: from probook.site (localhost [IPv6:::1]) by probook.site (Postfix) with ESMTP id 470BA18B6C for ; Thu, 15 Sep 2011 08:16:33 +0200 (CEST) Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Mercurial-Node: 3a3a5979b799d948802183d10d65894ee84a872f Message-Id: <3a3a5979b799d9488021.1316067394@probook.site> In-Reply-To: References: User-Agent: Mercurial-patchbomb/1.7.5 Date: Thu, 15 Sep 2011 08:16:34 +0200 From: Olaf Hering To: xen-devel@lists.xensource.com Subject: [Xen-devel] [PATCH 6 of 9] xenpaging: add evict_pages function X-BeenThere: xen-devel@lists.xensource.com X-Mailman-Version: 2.1.5 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xensource.com Errors-To: xen-devel-bounces@lists.xensource.com # HG changeset patch # User Olaf Hering # Date 1316067230 -7200 # Node ID 3a3a5979b799d948802183d10d65894ee84a872f # Parent 6beca8cbc2c92900859712f8738db17084bcebdb xenpaging: add evict_pages function Add new function to evict a couple of pages. Allocate all possible slots in a paging file to allow growing and shrinking of the number of paged-out pages. Adjust other places to iterate over all slots. This change is required by subsequent patches. Signed-off-by: Olaf Hering diff -r 6beca8cbc2c9 -r 3a3a5979b799 tools/xenpaging/xenpaging.c --- a/tools/xenpaging/xenpaging.c +++ b/tools/xenpaging/xenpaging.c @@ -597,6 +597,30 @@ static int evict_victim(xenpaging_t *pag return ret; } +/* Evict a couple of pages and write them to a free slot in the paging file */ +static int evict_pages(xenpaging_t *paging, int fd, xenpaging_victim_t *victims, int num_pages) +{ + xc_interface *xch = paging->xc_handle; + int rc, slot, num = 0; + + for ( slot = 0; slot < paging->max_pages && num < num_pages; slot++ ) + { + /* Slot is allocated */ + if ( victims[slot].gfn != INVALID_MFN ) + continue; + + rc = evict_victim(paging, &victims[slot], fd, slot); + if ( rc == -ENOSPC ) + break; + if ( rc == -EINTR ) + break; + if ( num && num % 100 == 0 ) + DPRINTF("%d pages evicted\n", num); + num++; + } + return num; +} + int main(int argc, char *argv[]) { struct sigaction act; @@ -639,7 +663,12 @@ int main(int argc, char *argv[]) return 2; } - victims = calloc(paging->num_pages, sizeof(xenpaging_victim_t)); + /* Allocate upper limit of pages to allow growing and shrinking */ + victims = calloc(paging->max_pages, sizeof(xenpaging_victim_t)); + + /* Mark all slots as unallocated */ + for ( i = 0; i < paging->max_pages; i++ ) + victims[i].gfn = INVALID_MFN; /* ensure that if we get a signal, we'll do cleanup, then exit */ act.sa_handler = close_handler; @@ -653,18 +682,7 @@ int main(int argc, char *argv[]) /* listen for page-in events to stop pager */ create_page_in_thread(paging); - /* Evict pages */ - for ( i = 0; i < paging->num_pages; i++ ) - { - rc = evict_victim(paging, &victims[i], fd, i); - if ( rc == -ENOSPC ) - break; - if ( rc == -EINTR ) - break; - if ( i % 100 == 0 ) - DPRINTF("%d pages evicted\n", i); - } - + i = evict_pages(paging, fd, victims, paging->num_pages); DPRINTF("%d pages evicted. Done.\n", i); /* Swap pages in and out */ @@ -690,13 +708,13 @@ int main(int argc, char *argv[]) if ( test_and_clear_bit(req.gfn, paging->bitmap) ) { /* Find where in the paging file to read from */ - for ( i = 0; i < paging->num_pages; i++ ) + for ( i = 0; i < paging->max_pages; i++ ) { if ( victims[i].gfn == req.gfn ) break; } - if ( i >= paging->num_pages ) + if ( i >= paging->max_pages ) { DPRINTF("Couldn't find page %"PRIx64"\n", req.gfn); goto out; _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel From xen-devel-bounces@lists.xensource.com Wed Sep 14 23:19:07 2011 Return-path: Envelope-to: www-data@lists.xensource.com Delivery-date: Wed, 14 Sep 2011 23:19:07 -0700 Received: from localhost ([127.0.0.1] helo=lists.colo.xensource.com) by lists.xensource.com with esmtp (Exim 4.43) id 1R45Hu-00012F-TB; Wed, 14 Sep 2011 23:19:06 -0700 Received: from mail174.messagelabs.com ([85.158.138.51]) by lists.xensource.com with esmtp (Exim 4.43) id 1R45Fi-00005M-Dw for xen-devel@lists.xensource.com; Wed, 14 Sep 2011 23:16:50 -0700 X-Env-Sender: olaf@aepfle.de X-Msg-Ref: server-11.tower-174.messagelabs.com!1316067406!31468859!1 X-Originating-IP: [81.169.146.161] X-StarScan-Version: 6.4.1; banners=-,-,- X-VirusChecked: Checked Received: (qmail 19862 invoked from network); 15 Sep 2011 06:16:46 -0000 Received: from mo-p00-ob.rzone.de (HELO mo-p00-ob.rzone.de) (81.169.146.161) by server-11.tower-174.messagelabs.com with DHE-RSA-AES256-SHA encrypted SMTP; 15 Sep 2011 06:16:46 -0000 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; t=1316067406; l=1499; s=domk; d=aepfle.de; h=To:From:Date:References:In-Reply-To:Subject: Content-Transfer-Encoding:MIME-Version:Content-Type:X-RZG-CLASS-ID: X-RZG-AUTH; bh=DuSq8/mlO8yJlMe37LQjjqHXklo=; b=n9W19NIiDxFLI8iMSIDEzMge3+7vj2myh+3t5YCwkh/b2/UV3tBwOSWw1ReW2aVyzRW fetsLSklLJXd7OZCi3/A9tj4Mcm29qdvQF3dt6ph8+Ev2e04x8Yq3WGJAf3pJJ0tw2jXv 9k4CMpXBb2SkIVfwODJVGoGNv6mKAqxaoCA= X-RZG-AUTH: :P2EQZWCpfu+qG7CngxMFH1J+zrwiavkK6tmQaLfmxtMZ80VwmRNV69z6 X-RZG-CLASS-ID: mo00 Received: from probook.site (ip-80-226-24-14.vodafone-net.de [80.226.24.14]) by smtp.strato.de (cohen mo55) (RZmta 26.7) with (DHE-RSA-AES256-SHA encrypted) ESMTPA id y00de1n8F5qhrn for ; Thu, 15 Sep 2011 08:16:37 +0200 (MEST) Received: from probook.site (localhost [IPv6:::1]) by probook.site (Postfix) with ESMTP id 8B78B18B6B for ; Thu, 15 Sep 2011 08:16:32 +0200 (CEST) Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Mercurial-Node: 6beca8cbc2c92900859712f8738db17084bcebdb Message-Id: <6beca8cbc2c929008597.1316067393@probook.site> In-Reply-To: References: User-Agent: Mercurial-patchbomb/1.7.5 Date: Thu, 15 Sep 2011 08:16:33 +0200 From: Olaf Hering To: xen-devel@lists.xensource.com Subject: [Xen-devel] [PATCH 5 of 9] xenpaging: track the number of paged-out pages X-BeenThere: xen-devel@lists.xensource.com X-Mailman-Version: 2.1.5 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xensource.com Errors-To: xen-devel-bounces@lists.xensource.com # HG changeset patch # User Olaf Hering # Date 1316067229 -7200 # Node ID 6beca8cbc2c92900859712f8738db17084bcebdb # Parent 2ff9871c02a1712d55addc2b30e4f7694e5b7ebe xenpaging: track the number of paged-out pages This change is required by subsequent changes. Signed-off-by: Olaf Hering diff -r 2ff9871c02a1 -r 6beca8cbc2c9 tools/xenpaging/xenpaging.c --- a/tools/xenpaging/xenpaging.c +++ b/tools/xenpaging/xenpaging.c @@ -468,6 +468,9 @@ static int xenpaging_evict_page(xenpagin /* Notify policy of page being paged out */ policy_notify_paged_out(victim->gfn); + /* Record number of evicted pages */ + paging->num_paged_out++; + out: return ret; } @@ -481,8 +484,13 @@ static int xenpaging_resume_page(xenpagi /* Notify policy of page being paged in */ if ( notify_policy ) + { policy_notify_paged_in(rsp->gfn); + /* Record number of resumed pages */ + paging->num_paged_out--; + } + /* Tell Xen page is ready */ ret = xc_mem_paging_resume(paging->xc_handle, paging->mem_event.domain_id, rsp->gfn); diff -r 2ff9871c02a1 -r 6beca8cbc2c9 tools/xenpaging/xenpaging.h --- a/tools/xenpaging/xenpaging.h +++ b/tools/xenpaging/xenpaging.h @@ -49,6 +49,7 @@ typedef struct xenpaging { mem_event_t mem_event; /* number of pages for which data structures were allocated */ int max_pages; + int num_paged_out; int num_pages; int policy_mru_size; unsigned long pagein_queue[XENPAGING_PAGEIN_QUEUE_SIZE]; _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel From xen-devel-bounces@lists.xensource.com Wed Sep 14 23:20:02 2011 Return-path: Envelope-to: www-data@lists.xensource.com Delivery-date: Wed, 14 Sep 2011 23:20:02 -0700 Received: from localhost ([127.0.0.1] helo=lists.colo.xensource.com) by lists.xensource.com with esmtp (Exim 4.43) id 1R45Io-0001P9-79; Wed, 14 Sep 2011 23:20:02 -0700 Received: from mail27.messagelabs.com ([193.109.254.147]) by lists.xensource.com with esmtp (Exim 4.43) id 1R45Fi-00005Z-Aw for xen-devel@lists.xensource.com; Wed, 14 Sep 2011 23:16:50 -0700 X-Env-Sender: olaf@aepfle.de X-Msg-Ref: server-2.tower-27.messagelabs.com!1316067383!55012727!1 X-Originating-IP: [81.169.146.160] X-StarScan-Version: 6.4.1; banners=-,-,- X-VirusChecked: Checked Received: (qmail 24978 invoked from network); 15 Sep 2011 06:16:23 -0000 Received: from mo-p00-ob.rzone.de (HELO mo-p00-ob.rzone.de) (81.169.146.160) by server-2.tower-27.messagelabs.com with EDH-RSA-DES-CBC3-SHA encrypted SMTP; 15 Sep 2011 06:16:23 -0000 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; t=1316067406; l=1256; s=domk; d=aepfle.de; h=To:From:Date:References:In-Reply-To:Subject: Content-Transfer-Encoding:MIME-Version:Content-Type:X-RZG-CLASS-ID: X-RZG-AUTH; bh=ZT8VMZkGIuSrATpMT4kL9os2P7c=; b=NQIC1Kp+gcaOQN3XRaOI3s5TS502mFct15/i53pihwLDu41Zbrz/qFGBMuBWSrt9oTe RhuxEaJm5ChooZBEiDA9urW1Pr2c9pmC4OTVACS5lasdkVCIfl7K52YAoXYhI+hS0+bGs vJRhSlc5fIhEx6lYRBBLhwRhSQfrIOfuU78= X-RZG-AUTH: :P2EQZWCpfu+qG7CngxMFH1J+zrwiavkK6tmQaLfmxtMZ80VwmRNV69z6 X-RZG-CLASS-ID: mo00 Received: from probook.site (ip-80-226-24-14.vodafone-net.de [80.226.24.14]) by post.strato.de (mrclete mo8) (RZmta 26.7) with (EDH-RSA-DES-CBC3-SHA encrypted) ESMTPA id f066aan8F5i6cs for ; Thu, 15 Sep 2011 08:16:35 +0200 (MEST) Received: from probook.site (localhost [IPv6:::1]) by probook.site (Postfix) with ESMTP id 97CCE18B68 for ; Thu, 15 Sep 2011 08:16:30 +0200 (CEST) Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Mercurial-Node: eb968e957ee4789a7a06c5f5683eb4b0e49324cd Message-Id: In-Reply-To: References: User-Agent: Mercurial-patchbomb/1.7.5 Date: Thu, 15 Sep 2011 08:16:30 +0200 From: Olaf Hering To: xen-devel@lists.xensource.com Subject: [Xen-devel] [PATCH 2 of 9] xenpaging: remove filename from comment X-BeenThere: xen-devel@lists.xensource.com X-Mailman-Version: 2.1.5 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xensource.com Errors-To: xen-devel-bounces@lists.xensource.com # HG changeset patch # User Olaf Hering # Date 1316067223 -7200 # Node ID eb968e957ee4789a7a06c5f5683eb4b0e49324cd # Parent cd07fbf47c11055a30ba21e904bf5537c50b044b xenpaging: remove filename from comment Signed-off-by: Olaf Hering diff -r cd07fbf47c11 -r eb968e957ee4 tools/xenpaging/file_ops.c --- a/tools/xenpaging/file_ops.c +++ b/tools/xenpaging/file_ops.c @@ -1,5 +1,4 @@ /****************************************************************************** - * tools/xenpaging/file_ops.c * * Common file operations. * diff -r cd07fbf47c11 -r eb968e957ee4 tools/xenpaging/policy_default.c --- a/tools/xenpaging/policy_default.c +++ b/tools/xenpaging/policy_default.c @@ -1,5 +1,4 @@ /****************************************************************************** - * tools/xenpaging/policy.c * * Xen domain paging default policy. * diff -r cd07fbf47c11 -r eb968e957ee4 tools/xenpaging/xenpaging.c --- a/tools/xenpaging/xenpaging.c +++ b/tools/xenpaging/xenpaging.c @@ -1,5 +1,4 @@ /****************************************************************************** - * tools/xenpaging/xenpaging.c * * Domain paging. * Copyright (c) 2009 by Citrix Systems, Inc. (Patrick Colp) _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel From xen-devel-bounces@lists.xensource.com Wed Sep 14 23:20:55 2011 Return-path: Envelope-to: www-data@lists.xensource.com Delivery-date: Wed, 14 Sep 2011 23:20:55 -0700 Received: from localhost ([127.0.0.1] helo=lists.colo.xensource.com) by lists.xensource.com with esmtp (Exim 4.43) id 1R45Je-0001lg-Ro; Wed, 14 Sep 2011 23:20:54 -0700 Received: from mail27.messagelabs.com ([193.109.254.147]) by lists.xensource.com with esmtp (Exim 4.43) id 1R45Fi-00005h-J8 for xen-devel@lists.xensource.com; Wed, 14 Sep 2011 23:16:51 -0700 X-Env-Sender: olaf@aepfle.de X-Msg-Ref: server-2.tower-27.messagelabs.com!1316067383!55012729!1 X-Originating-IP: [81.169.146.162] X-StarScan-Version: 6.4.1; banners=-,-,- X-VirusChecked: Checked Received: (qmail 24985 invoked from network); 15 Sep 2011 06:16:24 -0000 Received: from mo-p00-ob.rzone.de (HELO mo-p00-ob.rzone.de) (81.169.146.162) by server-2.tower-27.messagelabs.com with DHE-RSA-AES256-SHA encrypted SMTP; 15 Sep 2011 06:16:24 -0000 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; t=1316067407; l=629; s=domk; d=aepfle.de; h=To:From:Date:Subject:Content-Transfer-Encoding:MIME-Version: Content-Type:X-RZG-CLASS-ID:X-RZG-AUTH; bh=LsmVRKgKCCq8JG3s5y3lf4k1yYc=; b=AsfKvGtUMAEX6+bfbFugVEvxawC1NTbF4rLXwRNjhvEE9asphZN7zmUgIlbr5nhAc6a D97wVunbwMS+6knK8ff2KfeJUr/CU+9fuvalAb282vzlUzDEVWZ0W3pYmkbpfEt7Z8XEh SBt807ONssGbZOMEXoaTLTvip/jbN6qoWY4= X-RZG-AUTH: :P2EQZWCpfu+qG7CngxMFH1J+zrwiavkK6tmQaLfmxtMZ80VwmRNV69z6 X-RZG-CLASS-ID: mo00 Received: from probook.site (ip-80-226-24-14.vodafone-net.de [80.226.24.14]) by smtp.strato.de (cohen mo26) (RZmta 26.7) with (DHE-RSA-AES256-SHA encrypted) ESMTPA id t06d94n8F63DtF for ; Thu, 15 Sep 2011 08:16:33 +0200 (MEST) Received: from probook.site (localhost [IPv6:::1]) by probook.site (Postfix) with ESMTP id CE81918B66 for ; Thu, 15 Sep 2011 08:16:29 +0200 (CEST) Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Message-Id: User-Agent: Mercurial-patchbomb/1.7.5 Date: Thu, 15 Sep 2011 08:16:28 +0200 From: Olaf Hering To: xen-devel@lists.xensource.com Subject: [Xen-devel] [PATCH 0 of 9] xenpaging fixes for xen-unstable X-BeenThere: xen-devel@lists.xensource.com X-Mailman-Version: 2.1.5 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xensource.com Errors-To: xen-devel-bounces@lists.xensource.com The following series implements growing and shrinking of the paging file. A xenstore watch is used the retreive the new number of pages to page-out. This number is compared to the current amount of paged-out pages and, depending on the difference, new pages are written to disk or written back into the guest. Please review and apply. Olaf tools/xenpaging/Makefile | 4 tools/xenpaging/file_ops.c | 1 tools/xenpaging/policy_default.c | 11 - tools/xenpaging/xenpaging.c | 231 +++++++++++++++++++++++++++------------ tools/xenpaging/xenpaging.h | 8 - 5 files changed, 175 insertions(+), 80 deletions(-) _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel From xen-devel-bounces@lists.xensource.com Wed Sep 14 23:21:49 2011 Return-path: Envelope-to: www-data@lists.xensource.com Delivery-date: Wed, 14 Sep 2011 23:21:49 -0700 Received: from localhost ([127.0.0.1] helo=lists.colo.xensource.com) by lists.xensource.com with esmtp (Exim 4.43) id 1R45KX-00028e-Fr; Wed, 14 Sep 2011 23:21:49 -0700 Received: from mail21.messagelabs.com ([85.158.143.35]) by lists.xensource.com with esmtp (Exim 4.43) id 1R45Fi-00005d-BW for xen-devel@lists.xensource.com; Wed, 14 Sep 2011 23:16:50 -0700 X-Env-Sender: olaf@aepfle.de X-Msg-Ref: server-11.tower-21.messagelabs.com!1316067390!42639997!1 X-Originating-IP: [81.169.146.162] X-StarScan-Version: 6.4.1; banners=-,-,- X-VirusChecked: Checked Received: (qmail 26152 invoked from network); 15 Sep 2011 06:16:30 -0000 Received: from mo-p00-ob.rzone.de (HELO mo-p00-ob.rzone.de) (81.169.146.162) by server-11.tower-21.messagelabs.com with EDH-RSA-DES-CBC3-SHA encrypted SMTP; 15 Sep 2011 06:16:30 -0000 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; t=1316067406; l=849; s=domk; d=aepfle.de; h=To:From:Date:References:In-Reply-To:Subject: Content-Transfer-Encoding:MIME-Version:Content-Type:X-RZG-CLASS-ID: X-RZG-AUTH; bh=CgQkRGiGjNpFuwLYtTjpsITN9EI=; b=szPqSG3b7mbO8Bq+grMWclhGO410RiEP0HAaRzTBF/Dv2f0Qn8TTCxJk1sUiYnrtW06 4bE5bWSJfRaT8KSD6gZGKfOx69Tg+cbujox1U3UBZoE3XAbWQ7Kd/P9B/+l9XsV+vP6MP JLcfYUSF9fJMDwptK84rS0OVaby+TIq/5PU= X-RZG-AUTH: :P2EQZWCpfu+qG7CngxMFH1J+zrwiavkK6tmQaLfmxtMZ80VwmRNV69z6 X-RZG-CLASS-ID: mo00 Received: from probook.site (ip-80-226-24-14.vodafone-net.de [80.226.24.14]) by post.strato.de (mrclete mo8) (RZmta 26.7) with (EDH-RSA-DES-CBC3-SHA encrypted) ESMTPA id f066aan8F5i6cq for ; Thu, 15 Sep 2011 08:16:34 +0200 (MEST) Received: from probook.site (localhost [IPv6:::1]) by probook.site (Postfix) with ESMTP id 3D59118B67 for ; Thu, 15 Sep 2011 08:16:30 +0200 (CEST) Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Mercurial-Node: cd07fbf47c11055a30ba21e904bf5537c50b044b Message-Id: In-Reply-To: References: User-Agent: Mercurial-patchbomb/1.7.5 Date: Thu, 15 Sep 2011 08:16:29 +0200 From: Olaf Hering To: xen-devel@lists.xensource.com Subject: [Xen-devel] [PATCH 1 of 9] xenpaging: install into LIBEXEC dir X-BeenThere: xen-devel@lists.xensource.com X-Mailman-Version: 2.1.5 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xensource.com Errors-To: xen-devel-bounces@lists.xensource.com # HG changeset patch # User Olaf Hering # Date 1316067221 -7200 # Node ID cd07fbf47c11055a30ba21e904bf5537c50b044b # Parent e90438f6e6d1585a71b18784a99c162b5d95f390 xenpaging: install into LIBEXEC dir In preparation of upcoming libxl integration, move xenpaging binary from /usr/sbin/ to /usr/lib/xen/bin/ Signed-off-by: Olaf Hering diff -r e90438f6e6d1 -r cd07fbf47c11 tools/xenpaging/Makefile --- a/tools/xenpaging/Makefile +++ b/tools/xenpaging/Makefile @@ -24,8 +24,8 @@ xenpaging: $(OBJS) install: all $(INSTALL_DIR) $(DESTDIR)/var/lib/xen/xenpaging - $(INSTALL_DIR) $(DESTDIR)$(SBINDIR) - $(INSTALL_PROG) $(IBINS) $(DESTDIR)$(SBINDIR) + $(INSTALL_DIR) $(DESTDIR)$(LIBEXEC) + $(INSTALL_PROG) $(IBINS) $(DESTDIR)$(LIBEXEC) clean: rm -f *.o *~ $(DEPS) xen TAGS $(IBINS) $(LIB) _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel From xen-devel-bounces@lists.xensource.com Wed Sep 14 23:22:36 2011 Return-path: Envelope-to: www-data@lists.xensource.com Delivery-date: Wed, 14 Sep 2011 23:22:36 -0700 Received: from localhost ([127.0.0.1] helo=lists.colo.xensource.com) by lists.xensource.com with esmtp (Exim 4.43) id 1R45LI-0002Vr-P3; Wed, 14 Sep 2011 23:22:36 -0700 Received: from mail27.messagelabs.com ([193.109.254.147]) by lists.xensource.com with esmtp (Exim 4.43) id 1R45Fj-00006D-FN for xen-devel@lists.xensource.com; Wed, 14 Sep 2011 23:16:52 -0700 X-Env-Sender: olaf@aepfle.de X-Msg-Ref: server-9.tower-27.messagelabs.com!1316067392!44580917!1 X-Originating-IP: [81.169.146.160] X-StarScan-Version: 6.4.1; banners=-,-,- X-VirusChecked: Checked Received: (qmail 30846 invoked from network); 15 Sep 2011 06:16:32 -0000 Received: from mo-p00-ob.rzone.de (HELO mo-p00-ob.rzone.de) (81.169.146.160) by server-9.tower-27.messagelabs.com with DHE-RSA-AES256-SHA encrypted SMTP; 15 Sep 2011 06:16:32 -0000 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; t=1316067407; l=1144; s=domk; d=aepfle.de; h=To:From:Date:References:In-Reply-To:Subject: Content-Transfer-Encoding:MIME-Version:Content-Type:X-RZG-CLASS-ID: X-RZG-AUTH; bh=zQlDhl3ndU1reI0vox3mZmyvcMs=; b=cBmpVSbFohI1KLaaRSeBDhKbiICbvDwd38tdrb2Heq0dhGV90Yq1ZtIGLllRD3E+NZN MwuSYXUB1aK9G7K39iQkS5NPw//U3DdNdLooN03vJoavlRvxj360lds/1OAoySJd+nsT/ edW6Ssb9wDxny9sNdHSOfcTjRFjacZ4+faM= X-RZG-AUTH: :P2EQZWCpfu+qG7CngxMFH1J+zrwiavkK6tmQaLfmxtMZ80VwmRNV69z6 X-RZG-CLASS-ID: mo00 Received: from probook.site (ip-80-226-24-14.vodafone-net.de [80.226.24.14]) by smtp.strato.de (cohen mo54) (RZmta 26.7) with (DHE-RSA-AES256-SHA encrypted) ESMTPA id N00da2n8F56R8C for ; Thu, 15 Sep 2011 08:16:38 +0200 (MEST) Received: from probook.site (localhost [IPv6:::1]) by probook.site (Postfix) with ESMTP id 893B318B6D for ; Thu, 15 Sep 2011 08:16:34 +0200 (CEST) Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Mercurial-Node: 1addb9e81178ea164ef516f340df2607fddcb930 Message-Id: <1addb9e81178ea164ef5.1316067396@probook.site> In-Reply-To: References: User-Agent: Mercurial-patchbomb/1.7.5 Date: Thu, 15 Sep 2011 08:16:36 +0200 From: Olaf Hering To: xen-devel@lists.xensource.com Subject: [Xen-devel] [PATCH 8 of 9] xenpaging: compare both token and path when checking for @releaseDomain event X-BeenThere: xen-devel@lists.xensource.com X-Mailman-Version: 2.1.5 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xensource.com Errors-To: xen-devel-bounces@lists.xensource.com # HG changeset patch # User Olaf Hering # Date 1316067234 -7200 # Node ID 1addb9e81178ea164ef516f340df2607fddcb930 # Parent 6987aa2dde4e93481f1599735ed1a26defb6d6b9 xenpaging: compare both token and path when checking for @releaseDomain event Subsequent patches will use xenstored to store the numbers of pages xenpaging is suppose to page-out. A domain_id value could be misinterpreted as number of pages. Compare both path and token to recognize the @releaseDomain event. Signed-off-by: Olaf Hering diff -r 6987aa2dde4e -r 1addb9e81178 tools/xenpaging/xenpaging.c --- a/tools/xenpaging/xenpaging.c +++ b/tools/xenpaging/xenpaging.c @@ -101,7 +101,7 @@ static int xenpaging_wait_for_event_or_t vec = xs_read_watch(paging->xs_handle, &num); if ( vec ) { - if ( strcmp(vec[XS_WATCH_TOKEN], watch_token) == 0 ) + if ( strcmp(vec[XS_WATCH_PATH], "@releaseDomain") == 0 && strcmp(vec[XS_WATCH_TOKEN], watch_token) == 0 ) { /* If our guest disappeared, set interrupt flag and fall through */ if ( xs_is_domain_introduced(paging->xs_handle, paging->mem_event.domain_id) == false ) _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel From xen-devel-bounces@lists.xensource.com Wed Sep 14 23:23:29 2011 Return-path: Envelope-to: www-data@lists.xensource.com Delivery-date: Wed, 14 Sep 2011 23:23:29 -0700 Received: from localhost ([127.0.0.1] helo=lists.colo.xensource.com) by lists.xensource.com with esmtp (Exim 4.43) id 1R45M9-0002sd-Mb; Wed, 14 Sep 2011 23:23:29 -0700 Received: from mail216.messagelabs.com ([85.158.143.99]) by lists.xensource.com with esmtp (Exim 4.43) id 1R45Fj-000061-2w for xen-devel@lists.xensource.com; Wed, 14 Sep 2011 23:16:52 -0700 X-Env-Sender: olaf@aepfle.de X-Msg-Ref: server-12.tower-216.messagelabs.com!1316067407!12580321!1 X-Originating-IP: [81.169.146.160] X-StarScan-Version: 6.4.1; banners=-,-,- X-VirusChecked: Checked Received: (qmail 20156 invoked from network); 15 Sep 2011 06:16:48 -0000 Received: from mo-p00-ob.rzone.de (HELO mo-p00-ob.rzone.de) (81.169.146.160) by server-12.tower-216.messagelabs.com with EDH-RSA-DES-CBC3-SHA encrypted SMTP; 15 Sep 2011 06:16:48 -0000 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; t=1316067407; l=6782; s=domk; d=aepfle.de; h=To:From:Date:References:In-Reply-To:Subject: Content-Transfer-Encoding:MIME-Version:Content-Type:X-RZG-CLASS-ID: X-RZG-AUTH; bh=qLVl3wCPS02SuKIsuRLj/j1HtdE=; b=QyaoNCzqfYWxTAieXEv5yuS6Z30c4f9zey3Fy/SskGJhMYR4nTZI2etxvtJXrDPjq1q 3znbxYZvdDWkK6703/LIZRC80J0Jy59nTfssNdiF+u/kF5pXHMgStJx9TtQMsa8KDm40j 4KQ/0h6ImRcfPEV5ZvkdyY8X2hKhyUHSY4A= X-RZG-AUTH: :P2EQZWCpfu+qG7CngxMFH1J+zrwiavkK6tmQaLfmxtMZ80VwmRNV69z6 X-RZG-CLASS-ID: mo00 Received: from probook.site (ip-80-226-24-14.vodafone-net.de [80.226.24.14]) by smtp.strato.de (klopstock mo51) (RZmta 26.7) with (EDH-RSA-DES-CBC3-SHA encrypted) ESMTPA id a03d0bn8F4jRXu for ; Thu, 15 Sep 2011 08:16:39 +0200 (MEST) Received: from probook.site (localhost [IPv6:::1]) by probook.site (Postfix) with ESMTP id 2C39A18B67 for ; Thu, 15 Sep 2011 08:16:35 +0200 (CEST) Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Mercurial-Node: ad903b34e0997e864539e36b92dde234f9ffbd55 Message-Id: In-Reply-To: References: User-Agent: Mercurial-patchbomb/1.7.5 Date: Thu, 15 Sep 2011 08:16:37 +0200 From: Olaf Hering To: xen-devel@lists.xensource.com Subject: [Xen-devel] [PATCH 9 of 9] xenpaging: watch the domains /xenpaging/num_pages xenstore value X-BeenThere: xen-devel@lists.xensource.com X-Mailman-Version: 2.1.5 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xensource.com Errors-To: xen-devel-bounces@lists.xensource.com # HG changeset patch # User Olaf Hering # Date 1316067236 -7200 # Node ID ad903b34e0997e864539e36b92dde234f9ffbd55 # Parent 1addb9e81178ea164ef516f340df2607fddcb930 xenpaging: watch the domains /xenpaging/num_pages xenstore value Subsequent patches will use xenstored to store the numbers of pages xenpaging is suppose to page-out. Remove num_pages and use target_pages instead. Signed-off-by: Olaf Hering diff -r 1addb9e81178 -r ad903b34e099 tools/xenpaging/policy_default.c --- a/tools/xenpaging/policy_default.c +++ b/tools/xenpaging/policy_default.c @@ -70,7 +70,7 @@ int policy_init(xenpaging_t *paging) /* Start in the middle to avoid paging during BIOS startup */ current_gfn = max_pages / 2; - current_gfn -= paging->num_pages / 2; + current_gfn -= paging->target_pages / 2; rc = 0; out: diff -r 1addb9e81178 -r ad903b34e099 tools/xenpaging/xenpaging.c --- a/tools/xenpaging/xenpaging.c +++ b/tools/xenpaging/xenpaging.c @@ -35,6 +35,9 @@ #include "policy.h" #include "xenpaging.h" +/* Defines number of pages to page-out */ +#define WATCH_TARGETPAGES "/xenpaging/num_pages" +static char *watch_targetpages; static char watch_token[16]; static char filename[80]; static int interrupted; @@ -72,7 +75,7 @@ static int xenpaging_wait_for_event_or_t { xc_interface *xch = paging->xc_handle; xc_evtchn *xce = paging->mem_event.xce_handle; - char **vec; + char **vec, *val; unsigned int num; struct pollfd fd[2]; int port; @@ -101,6 +104,7 @@ static int xenpaging_wait_for_event_or_t vec = xs_read_watch(paging->xs_handle, &num); if ( vec ) { + DPRINTF("path '%s' token '%s'\n", vec[XS_WATCH_PATH], vec[XS_WATCH_TOKEN]); if ( strcmp(vec[XS_WATCH_PATH], "@releaseDomain") == 0 && strcmp(vec[XS_WATCH_TOKEN], watch_token) == 0 ) { /* If our guest disappeared, set interrupt flag and fall through */ @@ -111,6 +115,22 @@ static int xenpaging_wait_for_event_or_t rc = 0; } } + else if ( strcmp(vec[XS_WATCH_PATH], watch_targetpages) == 0 ) + { + int ret, target_pages; + val = xs_read(paging->xs_handle, XBT_NULL, vec[XS_WATCH_PATH], NULL); + if (val) + { + ret = sscanf(val, "%d", &target_pages); + if ( ret > 0 ) + { + if ( target_pages < 0 || target_pages > paging->max_pages ) + target_pages = paging->max_pages; + paging->target_pages = target_pages; + DPRINTF("new target_pages %d\n", target_pages); + } + } + } free(vec); } } @@ -167,8 +187,8 @@ static xenpaging_t *xenpaging_init(domid xc_domaininfo_t domain_info; xc_interface *xch; xentoollog_logger *dbg = NULL; - char *p; - int rc; + char *p, *dom_path = NULL, *watchdir = WATCH_TARGETPAGES; + int rc, len; /* Allocate memory */ paging = calloc(1, sizeof(xenpaging_t)); @@ -201,6 +221,28 @@ static xenpaging_t *xenpaging_init(domid goto err; } + /* watch guests xenpaging directory */ + dom_path = xs_get_domain_path(paging->xs_handle, domain_id); + if ( !dom_path ) + { + ERROR("Could not find domain path\n"); + goto err; + } + len = strlen(dom_path) + strlen(watchdir) + 1; + watch_targetpages = malloc(len); + if ( !watch_targetpages ) + { + ERROR("Could not alloc domain path\n"); + goto err; + } + snprintf(watch_targetpages, len, "%s%s", dom_path, watchdir); + DPRINTF("watching '%s'\n", watch_targetpages); + if ( xs_watch(paging->xs_handle, watch_targetpages, "") == false ) + { + ERROR("Could not bind to xenpaging watch\n"); + goto err; + } + p = getenv("XENPAGING_POLICY_MRU_SIZE"); if ( p && *p ) { @@ -299,7 +341,7 @@ static xenpaging_t *xenpaging_init(domid num_pages = paging->max_pages; DPRINTF("setting num_pages to %d\n", num_pages); } - paging->num_pages = num_pages; + paging->target_pages = num_pages; /* Initialise policy */ rc = policy_init(paging); @@ -330,6 +372,8 @@ static xenpaging_t *xenpaging_init(domid free(paging->mem_event.ring_page); } + free(dom_path); + free(watch_targetpages); free(paging->bitmap); free(paging); } @@ -345,6 +389,9 @@ static int xenpaging_teardown(xenpaging_ if ( paging == NULL ) return 0; + xs_unwatch(paging->xs_handle, watch_targetpages, ""); + xs_unwatch(paging->xs_handle, "@releaseDomain", watch_token); + xch = paging->xc_handle; paging->xc_handle = NULL; /* Tear down domain paging in Xen */ @@ -649,6 +696,7 @@ int main(int argc, char *argv[]) xenpaging_victim_t *victims; mem_event_request_t req; mem_event_response_t rsp; + int num, prev_num = 0; int i; int rc = -1; int rc1; @@ -673,7 +721,7 @@ int main(int argc, char *argv[]) } xch = paging->xc_handle; - DPRINTF("starting %s %u %d\n", argv[0], paging->mem_event.domain_id, paging->num_pages); + DPRINTF("starting %s %u %d\n", argv[0], paging->mem_event.domain_id, paging->target_pages); /* Open file */ sprintf(filename, "page_cache_%u", paging->mem_event.domain_id); @@ -703,9 +751,6 @@ int main(int argc, char *argv[]) /* listen for page-in events to stop pager */ create_page_in_thread(paging); - i = evict_pages(paging, fd, victims, paging->num_pages); - DPRINTF("%d pages evicted. Done.\n", i); - /* Swap pages in and out */ while ( 1 ) { @@ -774,8 +819,6 @@ int main(int argc, char *argv[]) * or clear this pagefile slot on exit */ if ( interrupted ) victims[i].gfn = INVALID_MFN; - else - evict_victim(paging, &victims[i], fd, i); } else { @@ -819,6 +862,29 @@ int main(int argc, char *argv[]) if ( interrupted ) break; } + if ( paging->num_paged_out < paging->target_pages ) + { + num = paging->target_pages - paging->num_paged_out; + if ( num != prev_num ) + { + DPRINTF("Need to evict %d pages to reach %d target_pages\n", num, paging->target_pages); + prev_num = num; + } + /* Limit the number of evicts to be able to process page-in requests */ + if ( num > 42 ) + num = 42; + evict_pages(paging, fd, victims, num); + } + else if ( paging->num_paged_out > paging->target_pages ) + { + num = paging->num_paged_out - paging->target_pages; + if ( num != prev_num ) + { + DPRINTF("Need to resume %d pages to reach %d target_pages\n", num, paging->target_pages); + prev_num = num; + } + resume_pages(paging, num); + } } DPRINTF("xenpaging got signal %d\n", interrupted); diff -r 1addb9e81178 -r ad903b34e099 tools/xenpaging/xenpaging.h --- a/tools/xenpaging/xenpaging.h +++ b/tools/xenpaging/xenpaging.h @@ -50,7 +50,8 @@ typedef struct xenpaging { /* number of pages for which data structures were allocated */ int max_pages; int num_paged_out; - int num_pages; + /* number of pages xenpaging is supposed to page-out */ + int target_pages; int policy_mru_size; unsigned long pagein_queue[XENPAGING_PAGEIN_QUEUE_SIZE]; } xenpaging_t; _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel From xen-devel-bounces@lists.xensource.com Wed Sep 14 23:24:37 2011 Return-path: Envelope-to: www-data@lists.xensource.com Delivery-date: Wed, 14 Sep 2011 23:24:37 -0700 Received: from localhost ([127.0.0.1] helo=lists.colo.xensource.com) by lists.xensource.com with esmtp (Exim 4.43) id 1R45NE-0003L5-Vx; Wed, 14 Sep 2011 23:24:37 -0700 Received: from mail216.messagelabs.com ([85.158.143.99]) by lists.xensource.com with esmtp (Exim 4.43) id 1R45Fn-000083-NJ for xen-devel@lists.xensource.com; Wed, 14 Sep 2011 23:16:56 -0700 X-Env-Sender: olaf@aepfle.de X-Msg-Ref: server-13.tower-216.messagelabs.com!1316067411!18339036!1 X-Originating-IP: [81.169.146.162] X-StarScan-Version: 6.4.1; banners=-,-,- X-VirusChecked: Checked Received: (qmail 19009 invoked from network); 15 Sep 2011 06:16:52 -0000 Received: from mo-p00-ob.rzone.de (HELO mo-p00-ob.rzone.de) (81.169.146.162) by server-13.tower-216.messagelabs.com with DHE-RSA-AES256-SHA encrypted SMTP; 15 Sep 2011 06:16:52 -0000 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; t=1316067411; l=1979; s=domk; d=aepfle.de; h=To:From:Date:References:In-Reply-To:Subject: Content-Transfer-Encoding:MIME-Version:Content-Type:X-RZG-CLASS-ID: X-RZG-AUTH; bh=r1ENgF1VoceAfK6CZlvm/xvIO+A=; b=oz45Q61qd85GdSNBlWIuCRSfo183XaiibWjL81OWaype1Fy+25MlIw+hPvxlRPuEk9u Z3GVv8/X0BSZTLY6rugxatbV0uEStDAEKC5Fy49BDPWPw8ivh/diEsdvEVH//f545zm14 9sNPVxTuP5wN7nib5q8XkfPyv88Z2ws4F0E= X-RZG-AUTH: :P2EQZWCpfu+qG7CngxMFH1J+zrwiavkK6tmQaLfmxtMZ80VwmRNV69z6 X-RZG-CLASS-ID: mo00 Received: from probook.site (ip-80-226-24-14.vodafone-net.de [80.226.24.14]) by smtp.strato.de (jimi mo11) (RZmta 26.7) with (DHE-RSA-AES256-SHA encrypted) ESMTPA id 000685n8F24sWa for ; Thu, 15 Sep 2011 08:16:38 +0200 (MEST) Received: from probook.site (localhost [IPv6:::1]) by probook.site (Postfix) with ESMTP id 02C4718B66 for ; Thu, 15 Sep 2011 08:16:34 +0200 (CEST) Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Mercurial-Node: 6987aa2dde4e93481f1599735ed1a26defb6d6b9 Message-Id: <6987aa2dde4e93481f15.1316067395@probook.site> In-Reply-To: References: User-Agent: Mercurial-patchbomb/1.7.5 Date: Thu, 15 Sep 2011 08:16:35 +0200 From: Olaf Hering To: xen-devel@lists.xensource.com Subject: [Xen-devel] [PATCH 7 of 9] xenpaging: add resume_pages function X-BeenThere: xen-devel@lists.xensource.com X-Mailman-Version: 2.1.5 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xensource.com Errors-To: xen-devel-bounces@lists.xensource.com # HG changeset patch # User Olaf Hering # Date 1316067232 -7200 # Node ID 6987aa2dde4e93481f1599735ed1a26defb6d6b9 # Parent 3a3a5979b799d948802183d10d65894ee84a872f xenpaging: add resume_pages function Add new function to resume a couple of pages. This change is required by subsequent patches. Signed-off-by: Olaf Hering diff -r 3a3a5979b799 -r 6987aa2dde4e tools/xenpaging/xenpaging.c --- a/tools/xenpaging/xenpaging.c +++ b/tools/xenpaging/xenpaging.c @@ -554,6 +554,27 @@ static int xenpaging_populate_page(xenpa return ret; } +/* Trigger a page-in for a couple of pages */ +static void resume_pages(xenpaging_t *paging, int num_pages) +{ + xc_interface *xch = paging->xc_handle; + int i, num = 0; + + for ( i = 0; i < paging->max_pages && num < num_pages; i++ ) + { + if ( test_bit(i, paging->bitmap) ) + { + paging->pagein_queue[num] = i; + num++; + if ( num == XENPAGING_PAGEIN_QUEUE_SIZE ) + break; + } + } + /* num may be less than num_pages, caller has to try again */ + if ( num ) + page_in_trigger(); +} + static int evict_victim(xenpaging_t *paging, xenpaging_victim_t *victim, int fd, int i) { @@ -785,25 +806,12 @@ int main(int argc, char *argv[]) /* Write all pages back into the guest */ if ( interrupted == SIGTERM || interrupted == SIGINT ) { - int num = 0; - for ( i = 0; i < paging->max_pages; i++ ) - { - if ( test_bit(i, paging->bitmap) ) - { - paging->pagein_queue[num] = i; - num++; - if ( num == XENPAGING_PAGEIN_QUEUE_SIZE ) - break; - } - } - /* - * One more round if there are still pages to process. - * If no more pages to process, exit loop. - */ - if ( num ) - page_in_trigger(); - else if ( i == paging->max_pages ) + /* If no more pages to process, exit loop. */ + if ( !paging->num_paged_out ) break; + + /* One more round if there are still pages to process. */ + resume_pages(paging, paging->num_paged_out); } else { _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel From xen-devel-bounces@lists.xensource.com Wed Sep 14 23:25:25 2011 Return-path: Envelope-to: www-data@lists.xensource.com Delivery-date: Wed, 14 Sep 2011 23:25:25 -0700 Received: from localhost ([127.0.0.1] helo=lists.colo.xensource.com) by lists.xensource.com with esmtp (Exim 4.43) id 1R45O1-0003hm-3l; Wed, 14 Sep 2011 23:25:25 -0700 Received: from mail21.messagelabs.com ([85.158.143.35]) by lists.xensource.com with esmtp (Exim 4.43) id 1R45Fq-00009I-Tv for xen-devel@lists.xensource.com; Wed, 14 Sep 2011 23:16:59 -0700 X-Env-Sender: olaf@aepfle.de X-Msg-Ref: server-11.tower-21.messagelabs.com!1316067399!42640016!1 X-Originating-IP: [81.169.146.161] X-StarScan-Version: 6.4.1; banners=-,-,- X-VirusChecked: Checked Received: (qmail 26409 invoked from network); 15 Sep 2011 06:16:39 -0000 Received: from mo-p00-ob.rzone.de (HELO mo-p00-ob.rzone.de) (81.169.146.161) by server-11.tower-21.messagelabs.com with EDH-RSA-DES-CBC3-SHA encrypted SMTP; 15 Sep 2011 06:16:39 -0000 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; t=1316067415; l=1916; s=domk; d=aepfle.de; h=To:From:Date:References:In-Reply-To:Subject: Content-Transfer-Encoding:MIME-Version:Content-Type:X-RZG-CLASS-ID: X-RZG-AUTH; bh=liiOaaA94jBQBGQhVab0oFzTsHM=; b=x0LyabdiU8BPfDGmjD/dFJmEEMZlKPNLIkzaXJN0kFp3nYXVaFDOXfGij5rrEAq6yO0 1ubBQyWWUgq4WRcszCOZKBV3KH89V/tWvjujGkcNCxhqE9MJJDbVCEY2H1UR0YsVhr8k3 TjPe4XHp5enCABOJMjbHgzZZlnTPIEqmvMA= X-RZG-AUTH: :P2EQZWCpfu+qG7CngxMFH1J+zrwiavkK6tmQaLfmxtMZ80VwmRNV69z6 X-RZG-CLASS-ID: mo00 Received: from probook.site (ip-80-226-24-14.vodafone-net.de [80.226.24.14]) by smtp.strato.de (fruni mo7) (RZmta 26.7) with (EDH-RSA-DES-CBC3-SHA encrypted) ESMTPA id 604eeen8F5fCuS for ; Thu, 15 Sep 2011 08:16:35 +0200 (MEST) Received: from probook.site (localhost [IPv6:::1]) by probook.site (Postfix) with ESMTP id E5BF418B69 for ; Thu, 15 Sep 2011 08:16:30 +0200 (CEST) Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Mercurial-Node: 1e5697849aa62c08651a613901dcf054ee652ea4 Message-Id: <1e5697849aa62c08651a.1316067391@probook.site> In-Reply-To: References: User-Agent: Mercurial-patchbomb/1.7.5 Date: Thu, 15 Sep 2011 08:16:31 +0200 From: Olaf Hering To: xen-devel@lists.xensource.com Subject: [Xen-devel] [PATCH 3 of 9] xenpaging: update xenpaging_init X-BeenThere: xen-devel@lists.xensource.com X-Mailman-Version: 2.1.5 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xensource.com Errors-To: xen-devel-bounces@lists.xensource.com # HG changeset patch # User Olaf Hering # Date 1316067225 -7200 # Node ID 1e5697849aa62c08651a613901dcf054ee652ea4 # Parent eb968e957ee4789a7a06c5f5683eb4b0e49324cd xenpaging: update xenpaging_init Move comment about xc_handle to the right place. Allocate paging early and use calloc. Signed-off-by: Olaf Hering diff -r eb968e957ee4 -r 1e5697849aa6 tools/xenpaging/xenpaging.c --- a/tools/xenpaging/xenpaging.c +++ b/tools/xenpaging/xenpaging.c @@ -169,18 +169,21 @@ static xenpaging_t *xenpaging_init(domid char *p; int rc; + /* Allocate memory */ + paging = calloc(1, sizeof(xenpaging_t)); + if ( !paging ) + goto err; + if ( getenv("XENPAGING_DEBUG") ) dbg = (xentoollog_logger *)xtl_createlogger_stdiostream(stderr, XTL_DEBUG, 0); - xch = xc_interface_open(dbg, NULL, 0); + + /* Open connection to xen */ + paging->xc_handle = xch = xc_interface_open(dbg, NULL, 0); if ( !xch ) - goto err_iface; + goto err; DPRINTF("xenpaging init\n"); - /* Allocate memory */ - paging = malloc(sizeof(xenpaging_t)); - memset(paging, 0, sizeof(xenpaging_t)); - /* Open connection to xenstore */ paging->xs_handle = xs_open(0); if ( paging->xs_handle == NULL ) @@ -204,9 +207,6 @@ static xenpaging_t *xenpaging_init(domid DPRINTF("Setting policy mru_size to %d\n", paging->policy_mru_size); } - /* Open connection to xen */ - paging->xc_handle = xch; - /* Set domain id */ paging->mem_event.domain_id = domain_id; @@ -319,7 +319,8 @@ static xenpaging_t *xenpaging_init(domid { if ( paging->xs_handle ) xs_close(paging->xs_handle); - xc_interface_close(xch); + if ( xch ) + xc_interface_close(xch); if ( paging->mem_event.shared_page ) { munlock(paging->mem_event.shared_page, PAGE_SIZE); @@ -337,7 +338,6 @@ static xenpaging_t *xenpaging_init(domid free(paging); } - err_iface: return NULL; } _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel From xen-devel-bounces@lists.xensource.com Wed Sep 14 23:38:50 2011 Return-path: Envelope-to: www-data@lists.xensource.com Delivery-date: Wed, 14 Sep 2011 23:38:50 -0700 Received: from localhost ([127.0.0.1] helo=lists.colo.xensource.com) by lists.xensource.com with esmtp (Exim 4.43) id 1R45b0-0004Gw-BZ; Wed, 14 Sep 2011 23:38:50 -0700 Received: from mail182.messagelabs.com ([85.158.139.83]) by lists.xensource.com with esmtp (Exim 4.43) id 1R45aO-00044n-K8 for xen-devel@lists.xensource.com; Wed, 14 Sep 2011 23:38:13 -0700 X-Env-Sender: keir.xen@gmail.com X-Msg-Ref: server-4.tower-182.messagelabs.com!1316068689!18395211!1 X-Originating-IP: [74.125.82.43] X-StarScan-Version: 6.4.1; banners=-,-,- X-VirusChecked: Checked Received: (qmail 28791 invoked from network); 15 Sep 2011 06:38:09 -0000 Received: from mail-ww0-f43.google.com (HELO mail-ww0-f43.google.com) (74.125.82.43) by server-4.tower-182.messagelabs.com with RC4-SHA encrypted SMTP; 15 Sep 2011 06:38:09 -0000 Received: by wwf27 with SMTP id 27so2551136wwf.24 for ; Wed, 14 Sep 2011 23:38:09 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=user-agent:date:subject:from:to:message-id:thread-topic :thread-index:in-reply-to:mime-version:content-type :content-transfer-encoding; bh=wnD+n6GKXpwRqgnzqdywJbYRDjksbUrPE4skhCvwUk8=; b=wILVaSMurC9VV9cKz/FnXFUL0xinnroSA22HwR+8HTSJRGFQondSjNmjjkimnwgKYE OLem/J4rUnRTl68oHT69/ijLHjBTJQAlCYf5SutCWj6ieJeru5NyE2CKIKbWslTmSMhc rNsnEvshGNF55KurBkV9K5XSO4nEtJVdOZe6E= Received: by 10.216.170.72 with SMTP id o50mr655564wel.103.1316068689474; Wed, 14 Sep 2011 23:38:09 -0700 (PDT) Received: from [192.168.1.78] (host86-137-116-193.range86-137.btcentralplus.com. [86.137.116.193]) by mx.google.com with ESMTPS id n39sm6842241wbp.7.2011.09.14.23.38.03 (version=SSLv3 cipher=OTHER); Wed, 14 Sep 2011 23:38:08 -0700 (PDT) User-Agent: Microsoft-Entourage/12.30.0.110427 Date: Thu, 15 Sep 2011 07:38:01 +0100 Subject: Re: [Xen-devel] [PATCH] Tidy up the viridian code a little and flesh out the APIC assist MSR From: Keir Fraser To: Paul Durrant , Message-ID: Thread-Topic: [Xen-devel] [PATCH] Tidy up the viridian code a little and flesh out the APIC assist MSR Thread-Index: AcxzcgONtakPWFHMdk29U12pniwCEw== In-Reply-To: Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit Cc: X-BeenThere: xen-devel@lists.xensource.com X-Mailman-Version: 2.1.5 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xensource.com Errors-To: xen-devel-bounces@lists.xensource.com On 15/09/2011 06:13, "Paul Durrant" wrote: > # HG changeset patch > # User Paul Durrant > # Date 1316063461 -3600 > # Node ID a08073c5cf28ab76893102cc7a8d20bf3e5e15ae > # Parent e90438f6e6d1585a71b18784a99c162b5d95f390 > Tidy up the viridian code a little and flesh out the APIC assist MSR > handling code. > > We don't say we that handle that MSR but Windows assumes it. In Windows 7 it > just wrote to the MSR and we used to handle that ok. Windows 8 also reads > from the MSR so we need to keep a record of the contents. Does this work properly across save/restore? -- Keir > Signed-off-by: Paul Durrant > > diff -r e90438f6e6d1 -r a08073c5cf28 xen/arch/x86/hvm/viridian.c > --- a/xen/arch/x86/hvm/viridian.c Wed Sep 14 11:38:13 2011 +0100 > +++ b/xen/arch/x86/hvm/viridian.c Thu Sep 15 06:11:01 2011 +0100 > @@ -96,9 +96,43 @@ int cpuid_viridian_leaves(unsigned int l > return 1; > } > > -static void enable_hypercall_page(void) > +void dump_guest_os_id(struct domain *d) > { > - struct domain *d = current->domain; > + gdprintk(XENLOG_INFO, "GUEST_OS_ID:\n"); > + gdprintk(XENLOG_INFO, "\tvendor: %x\n", > + d->arch.hvm_domain.viridian.guest_os_id.fields.vendor); > + gdprintk(XENLOG_INFO, "\tos: %x\n", > + d->arch.hvm_domain.viridian.guest_os_id.fields.os); > + gdprintk(XENLOG_INFO, "\tmajor: %x\n", > + d->arch.hvm_domain.viridian.guest_os_id.fields.major); > + gdprintk(XENLOG_INFO, "\tminor: %x\n", > + d->arch.hvm_domain.viridian.guest_os_id.fields.minor); > + gdprintk(XENLOG_INFO, "\tsp: %x\n", > + d->arch.hvm_domain.viridian.guest_os_id.fields.service_pack); > + gdprintk(XENLOG_INFO, "\tbuild: %x\n", > + d->arch.hvm_domain.viridian.guest_os_id.fields.build_number); > +} > + > +void dump_hypercall(struct domain *d) > +{ > + gdprintk(XENLOG_INFO, "HYPERCALL:\n"); > + gdprintk(XENLOG_INFO, "\tenabled: %x\n", > + d->arch.hvm_domain.viridian.hypercall_gpa.fields.enabled); > + gdprintk(XENLOG_INFO, "\tpfn: %lx\n", > + (unsigned > long)d->arch.hvm_domain.viridian.hypercall_gpa.fields.pfn); > +} > + > +void dump_apic_assist(struct vcpu *v) > +{ > + gdprintk(XENLOG_INFO, "APIC_ASSIST[%d]:\n", v->vcpu_id); > + gdprintk(XENLOG_INFO, "\tenabled: %x\n", > + v->arch.hvm_vcpu.viridian.apic_assist.fields.enabled); > + gdprintk(XENLOG_INFO, "\tpfn: %lx\n", > + (unsigned long)v->arch.hvm_vcpu.viridian.apic_assist.fields.pfn); > +} > + > +static void enable_hypercall_page(struct domain *d) > +{ > unsigned long gmfn = > d->arch.hvm_domain.viridian.hypercall_gpa.fields.pfn; > unsigned long mfn = gmfn_to_mfn(d, gmfn); > uint8_t *p; > @@ -130,9 +164,43 @@ static void enable_hypercall_page(void) > put_page_and_type(mfn_to_page(mfn)); > } > > +void initialize_apic_assist(struct vcpu *v) > +{ > + struct domain *d = v->domain; > + unsigned long gmfn = v->arch.hvm_vcpu.viridian.apic_assist.fields.pfn; > + unsigned long mfn = gmfn_to_mfn(d, gmfn); > + uint8_t *p; > + > + /* > + * We don't support the APIC assist page, and that fact is reflected in > + * our CPUID flags. However, Newer versions of Windows have a bug which > + * means that they don't recognise that, and tries to use the page > + * anyway. We therefore have to fake up just enough to keep windows > happy. > + * > + * See http://msdn.microsoft.com/en-us/library/ff538657%28VS.85%29.aspx > for > + * details of how Windows uses the page. > + */ > + > + if ( !mfn_valid(mfn) || > + !get_page_and_type(mfn_to_page(mfn), d, PGT_writable_page) ) > + { > + gdprintk(XENLOG_WARNING, "Bad GMFN %lx (MFN %lx)\n", gmfn, mfn); > + return; > + } > + > + p = map_domain_page(mfn); > + > + *(u32 *)p = 0; > + > + unmap_domain_page(p); > + > + put_page_and_type(mfn_to_page(mfn)); > +} > + > int wrmsr_viridian_regs(uint32_t idx, uint64_t val) > { > - struct domain *d = current->domain; > + struct vcpu *v = current; > + struct domain *d = v->domain; > > if ( !is_viridian_domain(d) ) > return 0; > @@ -142,44 +210,29 @@ int wrmsr_viridian_regs(uint32_t idx, ui > case VIRIDIAN_MSR_GUEST_OS_ID: > perfc_incr(mshv_wrmsr_osid); > d->arch.hvm_domain.viridian.guest_os_id.raw = val; > - gdprintk(XENLOG_INFO, "Guest os:\n"); > - gdprintk(XENLOG_INFO, "\tvendor: %x\n", > - d->arch.hvm_domain.viridian.guest_os_id.fields.vendor); > - gdprintk(XENLOG_INFO, "\tos: %x\n", > - d->arch.hvm_domain.viridian.guest_os_id.fields.os); > - gdprintk(XENLOG_INFO, "\tmajor: %x\n", > - d->arch.hvm_domain.viridian.guest_os_id.fields.major); > - gdprintk(XENLOG_INFO, "\tminor: %x\n", > - d->arch.hvm_domain.viridian.guest_os_id.fields.minor); > - gdprintk(XENLOG_INFO, "\tsp: %x\n", > - d->arch.hvm_domain.viridian.guest_os_id.fields.service_pack); > - gdprintk(XENLOG_INFO, "\tbuild: %x\n", > - d->arch.hvm_domain.viridian.guest_os_id.fields.build_number); > + dump_guest_os_id(d); > break; > > case VIRIDIAN_MSR_HYPERCALL: > perfc_incr(mshv_wrmsr_hc_page); > - gdprintk(XENLOG_INFO, "Set hypercall page %"PRIx64".\n", val); > - if ( d->arch.hvm_domain.viridian.guest_os_id.raw == 0 ) > - break; > d->arch.hvm_domain.viridian.hypercall_gpa.raw = val; > + dump_hypercall(d); > if ( d->arch.hvm_domain.viridian.hypercall_gpa.fields.enabled ) > - enable_hypercall_page(); > + enable_hypercall_page(d); > break; > > case VIRIDIAN_MSR_VP_INDEX: > perfc_incr(mshv_wrmsr_vp_index); > - gdprintk(XENLOG_INFO, "Set VP index %"PRIu64".\n", val); > break; > > case VIRIDIAN_MSR_EOI: > perfc_incr(mshv_wrmsr_eoi); > - vlapic_EOI_set(vcpu_vlapic(current)); > + vlapic_EOI_set(vcpu_vlapic(v)); > break; > > case VIRIDIAN_MSR_ICR: { > u32 eax = (u32)val, edx = (u32)(val >> 32); > - struct vlapic *vlapic = vcpu_vlapic(current); > + struct vlapic *vlapic = vcpu_vlapic(v); > perfc_incr(mshv_wrmsr_icr); > eax &= ~(1 << 12); > edx &= 0xff000000; > @@ -191,31 +244,15 @@ int wrmsr_viridian_regs(uint32_t idx, ui > > case VIRIDIAN_MSR_TPR: > perfc_incr(mshv_wrmsr_tpr); > - vlapic_set_reg(vcpu_vlapic(current), APIC_TASKPRI, (uint8_t)val); > + vlapic_set_reg(vcpu_vlapic(v), APIC_TASKPRI, (uint8_t)val); > break; > > case VIRIDIAN_MSR_APIC_ASSIST: > - /* > - * We don't support the APIC assist page, and that fact is reflected > in > - * our CPUID flags. However, Windows 7 build 7000 has a bug which > means > - * that it doesn't recognise that, and tries to use the page anyway. > We > - * therefore have to fake up just enough to keep win7 happy. > - * Fortunately, that's really easy: just setting the first four bytes > - * in the page to zero effectively disables the page again, so that's > - * what we do. Semantically, the first four bytes are supposed to be > a > - * flag saying whether the guest really needs to issue an EOI. > Setting > - * that flag to zero means that it must always issue one, which is > what > - * we want. Once a page has been repurposed as an APIC assist page > the > - * guest isn't allowed to set anything in it, so the flag remains > zero > - * and all is fine. The guest is allowed to clear flags in the page, > - * but that doesn't cause us any problems. > - */ > - if ( val & 1 ) /* APIC assist page enabled? */ > - { > - uint32_t word = 0; > - paddr_t page_start = val & ~1ul; > - (void)hvm_copy_to_guest_phys(page_start, &word, sizeof(word)); > - } > + perfc_incr(mshv_wrmsr_apic_msr); > + v->arch.hvm_vcpu.viridian.apic_assist.raw = val; > + dump_apic_assist(v); > + if (v->arch.hvm_vcpu.viridian.apic_assist.fields.enabled) > + initialize_apic_assist(v); > break; > > default: > @@ -228,20 +265,21 @@ int wrmsr_viridian_regs(uint32_t idx, ui > int rdmsr_viridian_regs(uint32_t idx, uint64_t *val) > { > struct vcpu *v = current; > + struct domain *d = v->domain; > > - if ( !is_viridian_domain(v->domain) ) > + if ( !is_viridian_domain(d) ) > return 0; > > switch ( idx ) > { > case VIRIDIAN_MSR_GUEST_OS_ID: > perfc_incr(mshv_rdmsr_osid); > - *val = v->domain->arch.hvm_domain.viridian.guest_os_id.raw; > + *val = d->arch.hvm_domain.viridian.guest_os_id.raw; > break; > > case VIRIDIAN_MSR_HYPERCALL: > perfc_incr(mshv_rdmsr_hc_page); > - *val = v->domain->arch.hvm_domain.viridian.hypercall_gpa.raw; > + *val = d->arch.hvm_domain.viridian.hypercall_gpa.raw; > break; > > case VIRIDIAN_MSR_VP_INDEX: > @@ -260,6 +298,11 @@ int rdmsr_viridian_regs(uint32_t idx, ui > *val = vlapic_get_reg(vcpu_vlapic(v), APIC_TASKPRI); > break; > > + case VIRIDIAN_MSR_APIC_ASSIST: > + perfc_incr(mshv_rdmsr_apic_msr); > + *val = v->arch.hvm_vcpu.viridian.apic_assist.raw; > + break; > + > default: > return 0; > } > diff -r e90438f6e6d1 -r a08073c5cf28 xen/include/asm-x86/hvm/vcpu.h > --- a/xen/include/asm-x86/hvm/vcpu.h Wed Sep 14 11:38:13 2011 +0100 > +++ b/xen/include/asm-x86/hvm/vcpu.h Thu Sep 15 06:11:01 2011 +0100 > @@ -23,6 +23,7 @@ > #include > #include > #include > +#include > #include > #include > #include > @@ -163,6 +164,8 @@ struct hvm_vcpu { > int inject_trap; /* -1 for nothing to inject */ > int inject_error_code; > unsigned long inject_cr2; > + > + struct viridian_vcpu viridian; > }; > > #endif /* __ASM_X86_HVM_VCPU_H__ */ > diff -r e90438f6e6d1 -r a08073c5cf28 xen/include/asm-x86/hvm/viridian.h > --- a/xen/include/asm-x86/hvm/viridian.h Wed Sep 14 11:38:13 2011 +0100 > +++ b/xen/include/asm-x86/hvm/viridian.h Thu Sep 15 06:11:01 2011 +0100 > @@ -9,6 +9,21 @@ > #ifndef __ASM_X86_HVM_VIRIDIAN_H__ > #define __ASM_X86_HVM_VIRIDIAN_H__ > > +union viridian_apic_assist > +{ uint64_t raw; > + struct > + { > + uint64_t enabled:1; > + uint64_t reserved_preserved:11; > + uint64_t pfn:48; > + } fields; > +}; > + > +struct viridian_vcpu > +{ > + union viridian_apic_assist apic_assist; > +}; > + > union viridian_guest_os_id > { > uint64_t raw; > diff -r e90438f6e6d1 -r a08073c5cf28 xen/include/asm-x86/perfc_defn.h > --- a/xen/include/asm-x86/perfc_defn.h Wed Sep 14 11:38:13 2011 +0100 > +++ b/xen/include/asm-x86/perfc_defn.h Thu Sep 15 06:11:01 2011 +0100 > @@ -120,12 +120,14 @@ PERFCOUNTER(mshv_rdmsr_hc_page, > PERFCOUNTER(mshv_rdmsr_vp_index, "MS Hv rdmsr vp index") > PERFCOUNTER(mshv_rdmsr_icr, "MS Hv rdmsr icr") > PERFCOUNTER(mshv_rdmsr_tpr, "MS Hv rdmsr tpr") > +PERFCOUNTER(mshv_rdmsr_apic_assist, "MS Hv rdmsr APIC assist") > PERFCOUNTER(mshv_wrmsr_osid, "MS Hv wrmsr Guest OS ID") > PERFCOUNTER(mshv_wrmsr_hc_page, "MS Hv wrmsr hypercall page") > PERFCOUNTER(mshv_wrmsr_vp_index, "MS Hv wrmsr vp index") > PERFCOUNTER(mshv_wrmsr_icr, "MS Hv wrmsr icr") > PERFCOUNTER(mshv_wrmsr_tpr, "MS Hv wrmsr tpr") > PERFCOUNTER(mshv_wrmsr_eoi, "MS Hv wrmsr eoi") > +PERFCOUNTER(mshv_wrmsr_apic_assist, "MS Hv wrmsr APIC assist") > > PERFCOUNTER(realmode_emulations, "realmode instructions emulated") > PERFCOUNTER(realmode_exits, "vmexits from realmode") > > _______________________________________________ > Xen-devel mailing list > Xen-devel@lists.xensource.com > http://lists.xensource.com/xen-devel _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel From xen-devel-bounces@lists.xensource.com Thu Sep 15 00:53:36 2011 Return-path: Envelope-to: www-data@lists.xensource.com Delivery-date: Thu, 15 Sep 2011 00:53:36 -0700 Received: from localhost ([127.0.0.1] helo=lists.colo.xensource.com) by lists.xensource.com with esmtp (Exim 4.43) id 1R46lL-0006U8-Vc; Thu, 15 Sep 2011 00:53:36 -0700 Received: from mail174.messagelabs.com ([85.158.138.51]) by lists.xensource.com with esmtp (Exim 4.43) id 1R46kY-0006Hj-71 for xen-devel@lists.xensource.com; Thu, 15 Sep 2011 00:52:46 -0700 X-Env-Sender: JBeulich@suse.com X-Msg-Ref: server-7.tower-174.messagelabs.com!1316073162!31463613!1 X-Originating-IP: [130.57.49.28] X-StarScan-Version: 6.4.1; banners=-,-,- X-VirusChecked: Checked Received: (qmail 3654 invoked from network); 15 Sep 2011 07:52:43 -0000 Received: from nat28.tlf.novell.com (HELO nat28.tlf.novell.com) (130.57.49.28) by server-7.tower-174.messagelabs.com with DHE-RSA-AES256-SHA encrypted SMTP; 15 Sep 2011 07:52:43 -0000 Received: from EMEA1-MTA by nat28.tlf.novell.com with Novell_GroupWise; Thu, 15 Sep 2011 08:52:42 +0100 Message-Id: <4E71CAE8020000780005635C@nat28.tlf.novell.com> X-Mailer: Novell GroupWise Internet Agent 8.0.1 Date: Thu, 15 Sep 2011 08:52:40 +0100 From: "Jan Beulich" To: "Jeremy Fitzhardinge" , "Konrad Rzeszutek Wilk" Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: quoted-printable Content-Disposition: inline Cc: "xen-devel@lists.xensource.com" , linux-kernel@vger.kernel.org Subject: [Xen-devel] [PATCH] xen/i386: follow-up to "replace order-based range checking of M2P table by linear one" X-BeenThere: xen-devel@lists.xensource.com X-Mailman-Version: 2.1.5 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xensource.com Errors-To: xen-devel-bounces@lists.xensource.com The numbers obtained from the hypervisor really can't ever lead to an overflow here, only the original calculation going through the order of the range could have. This avoids the (as Jeremy points outs) somewhat ugly NULL-based calculation here. Signed-off-by: Jan Beulich --- arch/x86/xen/mmu.c | 6 ++---- 1 file changed, 2 insertions(+), 4 deletions(-) --- 3.1-rc6/arch/x86/xen/mmu.c +++ 3.1-rc6-i386-xen-p2m-nr/arch/x86/xen/mmu.c @@ -1721,10 +1721,8 @@ void __init xen_setup_machphys_mapping(v machine_to_phys_nr =3D MACH2PHYS_NR_ENTRIES; } #ifdef CONFIG_X86_32 - if ((machine_to_phys_mapping + machine_to_phys_nr) - < machine_to_phys_mapping) - machine_to_phys_nr =3D (unsigned long *)NULL - - machine_to_phys_mapping; + WARN_ON((machine_to_phys_mapping + (machine_to_phys_nr - 1)) + < machine_to_phys_mapping); #endif } =20 _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel From xen-devel-bounces@lists.xensource.com Thu Sep 15 00:55:09 2011 Return-path: Envelope-to: www-data@lists.xensource.com Delivery-date: Thu, 15 Sep 2011 00:55:09 -0700 Received: from localhost ([127.0.0.1] helo=lists.colo.xensource.com) by lists.xensource.com with esmtp (Exim 4.43) id 1R46mr-0006rb-8g; Thu, 15 Sep 2011 00:55:09 -0700 Received: from mail174.messagelabs.com ([85.158.138.51]) by lists.xensource.com with esmtp (Exim 4.43) id 1R46mI-0006fM-PV; Thu, 15 Sep 2011 00:54:35 -0700 X-Env-Sender: konrad@oracle.com X-Msg-Ref: server-2.tower-174.messagelabs.com!1316073270!31487828!1 X-Originating-IP: [141.146.126.227] X-StarScan-Version: 6.4.1; banners=-,-,- X-VirusChecked: Checked Received: (qmail 6034 invoked from network); 15 Sep 2011 07:54:31 -0000 Received: from acsinet15.oracle.com (HELO acsinet15.oracle.com) (141.146.126.227) by server-2.tower-174.messagelabs.com with DHE-RSA-AES256-SHA encrypted SMTP; 15 Sep 2011 07:54:31 -0000 Received: from rtcsinet22.oracle.com (rtcsinet22.oracle.com [66.248.204.30]) by acsinet15.oracle.com (Switch-3.4.4/Switch-3.4.4) with ESMTP id p8F7s6tG015047 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Thu, 15 Sep 2011 07:54:08 GMT Received: from acsmt356.oracle.com (acsmt356.oracle.com [141.146.40.156]) by rtcsinet22.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id p8F7s4Of007759 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 15 Sep 2011 07:54:05 GMT Received: from abhmt111.oracle.com (abhmt111.oracle.com [141.146.116.63]) by acsmt356.oracle.com (8.12.11.20060308/8.12.11) with ESMTP id p8F7rwW6020997; Thu, 15 Sep 2011 02:53:58 -0500 Received: from oracle.com (/209.6.55.207) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Thu, 15 Sep 2011 00:53:58 -0700 Received: by oracle.com (Postfix, from userid 1000) id 04BEF1362; Thu, 15 Sep 2011 03:53:58 -0400 (EDT) Date: Thu, 15 Sep 2011 03:53:58 -0400 From: Konrad Rzeszutek Wilk To: M A Young Subject: Re: [Fedora-xen] [Xen-devel] Re: [Xen-users] Continuing BUG:-iness booting Fedora Rawhide 3.1.0-rc's (was Summary: Experiences setting up a debug serial port) Message-ID: <20110915075358.GA4396@phenom.oracle.com> References: <201107231426.56811.jim_burn@bellsouth.net> <20110914090806.GD25628@phenom.oracle.com> <20110914105711.GA16284@phenom.oracle.com> <1551334.UG67O7dPfn@dell4550> <20110914221254.GB3742@phenom.oracle.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.21 (2010-09-15) X-Source-IP: rtcsinet22.oracle.com [66.248.204.30] X-CT-RefId: str=0001.0A090201.4E71AF21.00CA,ss=1,re=0.000,fgs=0 Cc: Ian Campbell , xen-devel@lists.xensource.com, xen-users@lists.xensource.com, Fedora Xen List , jim burns X-BeenThere: xen-devel@lists.xensource.com X-Mailman-Version: 2.1.5 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xensource.com Errors-To: xen-devel-bounces@lists.xensource.com On Thu, Sep 15, 2011 at 12:38:26AM +0100, M A Young wrote: > On Wed, 14 Sep 2011, Konrad Rzeszutek Wilk wrote: > > >On Wed, Sep 14, 2011 at 05:07:28PM -0400, jim burns wrote: > >>On Wed September 14 2011, 6:57:11 AM, Konrad Rzeszutek Wilk wrote: > >>>On Wed, Sep 14, 2011 at 05:08:06AM -0400, Konrad Rzeszutek Wilk wrote: > >>> > >>>commit 690dc11498b192db25762de77988224753517c96 > >>>Author: Konrad Rzeszutek Wilk > >>>Date: Wed Sep 14 05:10:00 2011 -0400 > >>> xen/irq: Alter the locking to be a mutex. > >> > >>I'll try to apply this to fedora's xen src rpm over the weekend. In case it > >>doesn't apply, would you remind me of the git commands for the code you > >>applied this patch to? Thanx. > > > >I just save the email in some mbox file and then do > >git am < and it should automatically add it. > > > >Or you can just do patch -p1 and it will apply it too. > > I have a (temporary) F17 kernel with the patch from http://oss.oracle.com/git/kwilk/xen.git/?p=kwilk/xen.git;a=commit;h=a7079a6404ed2106315327fff6be3464d10814e7 > (which I assume is the same patch) applied building at Yup! > http://koji.fedoraproject.org/koji/taskinfo?taskID=3352367 > if you want to test it. Great! Thanks for doing this. > > Michael Young _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel From xen-devel-bounces@lists.xensource.com Thu Sep 15 01:05:52 2011 Return-path: Envelope-to: www-data@lists.xensource.com Delivery-date: Thu, 15 Sep 2011 01:05:52 -0700 Received: from localhost ([127.0.0.1] helo=lists.colo.xensource.com) by lists.xensource.com with esmtp (Exim 4.43) id 1R46xE-00082w-7o; Thu, 15 Sep 2011 01:05:52 -0700 Received: from mail216.messagelabs.com ([85.158.143.99]) by lists.xensource.com with esmtp (Exim 4.43) id 1R46t4-0007nW-Fb; Thu, 15 Sep 2011 01:02:24 -0700 X-Env-Sender: konrad@oracle.com X-Msg-Ref: server-6.tower-216.messagelabs.com!1316073689!17067639!1 X-Originating-IP: [148.87.113.117] X-StarScan-Version: 6.4.1; banners=-,-,- X-VirusChecked: Checked Received: (qmail 7282 invoked from network); 15 Sep 2011 08:01:30 -0000 Received: from rcsinet15.oracle.com (HELO rcsinet15.oracle.com) (148.87.113.117) by server-6.tower-216.messagelabs.com with DHE-RSA-AES256-SHA encrypted SMTP; 15 Sep 2011 08:01:30 -0000 Received: from acsinet22.oracle.com (acsinet22.oracle.com [141.146.126.238]) by rcsinet15.oracle.com (Switch-3.4.4/Switch-3.4.4) with ESMTP id p8F81QeQ030342 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Thu, 15 Sep 2011 08:01:28 GMT Received: from acsmt357.oracle.com (acsmt357.oracle.com [141.146.40.157]) by acsinet22.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id p8F81Qid005988 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 15 Sep 2011 08:01:26 GMT Received: from abhmt119.oracle.com (abhmt119.oracle.com [141.146.116.71]) by acsmt357.oracle.com (8.12.11.20060308/8.12.11) with ESMTP id p8F81Lev028774; Thu, 15 Sep 2011 03:01:21 -0500 Received: from oracle.com (/209.6.55.207) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Thu, 15 Sep 2011 01:01:20 -0700 Received: by oracle.com (Postfix, from userid 1000) id 927C81362; Thu, 15 Sep 2011 04:01:21 -0400 (EDT) Date: Thu, 15 Sep 2011 04:01:21 -0400 From: Konrad Rzeszutek Wilk To: jinho hwang Subject: Re: [Xen-devel] [Xen-users] XENBUS waiting timeout Message-ID: <20110915080121.GB4396@phenom.oracle.com> References: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.21 (2010-09-15) X-Source-IP: acsinet22.oracle.com [141.146.126.238] X-Auth-Type: Internal IP X-CT-RefId: str=0001.0A090209.4E71B0D8.0121:SCFMA922111,ss=1,re=-4.000,fgs=0 Cc: xen-devel@lists.xensource.com, xen-users@lists.xensource.com X-BeenThere: xen-devel@lists.xensource.com X-Mailman-Version: 2.1.5 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xensource.com Errors-To: xen-devel-bounces@lists.xensource.com On Thu, Sep 15, 2011 at 02:02:25AM -0400, jinho hwang wrote: > Hi, > > I have used disk image to copy host fs to image file and boot a guest > system. But, the system is dropped to shell and it also says that it can't You need to give more details. What is the version of your Dom0? Is there anything showing up in the Dom0 kernel when this fails? Can you also include your xenstore-ls when this failure happens? You should see an entry for 51713 and 51714.. > find /dev/xvda1 which is the root fs. I have defined it in the configuration > file as follows: > > disk = [ 'tap:aio:/xen/XenGuest1.img,xvda1,w', > 'tap:aio:/xen/XenGuest1.swap,xvda2,w' ] > root = "/dev/xvda1 ro" > > Also, modified the fstab as follows: > > /dev/xvda1 / ext3 defaults 1 1 > /dev/xvda2 none swap sw 0 0 > none /dev/pts devpts gid=5,mode=620 0 0 > none /dev/shm tmpfs defaults 0 0 > none /proc proc defaults 0 0 > none /sys sysfs defaults 0 0 > > The following is the error shown in the console. > > Using IPI No-Shortcut mode > registered taskstats version 1 > XENBUS: Waiting for devices to initialise: > 295s...290s...285s...280s...275s...270s...265s...260s...255s...250s...245s...240s...235s...230s...225s...220s...215s...210s...205s...200s...195s...190s...185s...180s...175s...170s...165s...160s...155s...150s...145s...140s...135s...130s...125s...120s...115s...110s...105s...100s...95s...90s...85s...80s...75s...70s...65s...60s...55s...50s...45s...40s...35s...30s...25s...20s...15s...10s...5s...0s... > XENBUS: Timeout connecting to device: device/vbd/51713 (local state 3, > remote state 1) > XENBUS: Timeout connecting to device: device/vbd/51714 (local state 3, > remote state 1) > XENBUS: Device with no driver: device/console/0 > Magic number: 1:252:3141 > Freeing unused kernel memory: 432k freed > Write protecting the kernel text: 2984k > Write protecting the kernel read-only data: 1452k > Loading, please wait... > mount: mounting none on /dev failed: No such device > W: devtmpfs not available, falling back to tmpfs for /dev > Begin: Loading essential drivers ... done. > Begin: Running /scripts/init-premount ... done. > Begin: Mounting root file system ... Begin: Running /scripts/local-top ... > done. > Gave up waiting for root device. Common problems: > - Boot args (cat /proc/cmdline) > - Check rootdelay= (did the system wait long enough?) > - Check root= (did the system wait for the right device?) > - Missing modules (cat /proc/modules; ls /dev) > ALERT! /dev/xvda1 does not exist. Dropping to a shell! > > If anybody has any idea, please let me know. > > Thank you, > > Jinho > > -- > Jinho Hwang > PhD Student > Department of Computer Science > The George Washington University > Washington, DC 20052 > hwang.jinho@gmail.com (email) > 276.336.0971 (Cell) > 202.994.4875 (fax) > 070.8285.6546 (myLg070) > _______________________________________________ > Xen-devel mailing list > Xen-devel@lists.xensource.com > http://lists.xensource.com/xen-devel _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel From xen-devel-bounces@lists.xensource.com Thu Sep 15 01:17:23 2011 Return-path: Envelope-to: www-data@lists.xensource.com Delivery-date: Thu, 15 Sep 2011 01:17:23 -0700 Received: from localhost ([127.0.0.1] helo=lists.colo.xensource.com) by lists.xensource.com with esmtp (Exim 4.43) id 1R478N-0000m5-PT; Thu, 15 Sep 2011 01:17:23 -0700 Received: from mail27.messagelabs.com ([193.109.254.147]) by lists.xensource.com with esmtp (Exim 4.43) id 1R477n-0000Zj-4B for xen-devel@lists.xensource.com; Thu, 15 Sep 2011 01:16:48 -0700 X-Env-Sender: Ian.Campbell@eu.citrix.com X-Msg-Ref: server-15.tower-27.messagelabs.com!1316074594!48842373!1 X-Originating-IP: [66.165.176.63] X-StarScan-Version: 6.4.1; banners=-,-,- X-VirusChecked: Checked Received: (qmail 17140 invoked from network); 15 Sep 2011 08:16:35 -0000 Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63) by server-15.tower-27.messagelabs.com with RC4-SHA encrypted SMTP; 15 Sep 2011 08:16:35 -0000 X-IronPort-AV: E=Sophos;i="4.68,385,1312171200"; d="scan'208";a="163193649" Received: from ftlpmailmx02.citrite.net ([10.13.107.66]) by FTLPIPO02.CITRIX.COM with ESMTP/TLS/RC4-MD5; 15 Sep 2011 04:16:42 -0400 Received: from [127.0.0.1] (10.80.16.67) by smtprelay.citrix.com (10.13.107.66) with Microsoft SMTP Server id 8.3.137.0; Thu, 15 Sep 2011 04:16:42 -0400 Subject: Re: [Xen-devel] [PATCH 6 of 9] xenpaging: add evict_pages function From: Ian Campbell To: Olaf Hering Date: Thu, 15 Sep 2011 10:16:41 +0200 In-Reply-To: <3a3a5979b799d9488021.1316067394@probook.site> References: <3a3a5979b799d9488021.1316067394@probook.site> Organization: Citrix Systems, Inc. Content-Type: text/plain; charset="UTF-8" X-Mailer: Evolution 3.0.3- Content-Transfer-Encoding: 7bit Message-ID: <1316074602.25935.4.camel@cthulhu.hellion.org.uk> MIME-Version: 1.0 Cc: "xen-devel@lists.xensource.com" X-BeenThere: xen-devel@lists.xensource.com X-Mailman-Version: 2.1.5 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xensource.com Errors-To: xen-devel-bounces@lists.xensource.com On Thu, 2011-09-15 at 02:16 -0400, Olaf Hering wrote: > # HG changeset patch > # User Olaf Hering > # Date 1316067230 -7200 > # Node ID 3a3a5979b799d948802183d10d65894ee84a872f > # Parent 6beca8cbc2c92900859712f8738db17084bcebdb > xenpaging: add evict_pages function > > Add new function to evict a couple of pages. Do you really mean "a couple" here? (that generally means exactly two). >From the implementation I think you mean evict a batch of pages? > Allocate all possible slots in a paging file to allow growing and > shrinking of the number of paged-out pages. Adjust other places to > iterate over all slots. > > This change is required by subsequent patches. > > Signed-off-by: Olaf Hering > > diff -r 6beca8cbc2c9 -r 3a3a5979b799 tools/xenpaging/xenpaging.c > --- a/tools/xenpaging/xenpaging.c > +++ b/tools/xenpaging/xenpaging.c > @@ -597,6 +597,30 @@ static int evict_victim(xenpaging_t *pag > return ret; > } > > +/* Evict a couple of pages and write them to a free slot in the paging file */ > +static int evict_pages(xenpaging_t *paging, int fd, xenpaging_victim_t *victims, int num_pages) > +{ > + xc_interface *xch = paging->xc_handle; > + int rc, slot, num = 0; > + > + for ( slot = 0; slot < paging->max_pages && num < num_pages; slot++ ) > + { > + /* Slot is allocated */ > + if ( victims[slot].gfn != INVALID_MFN ) > + continue; > + > + rc = evict_victim(paging, &victims[slot], fd, slot); > + if ( rc == -ENOSPC ) > + break; > + if ( rc == -EINTR ) > + break; > + if ( num && num % 100 == 0 ) > + DPRINTF("%d pages evicted\n", num); > + num++; > + } > + return num; > +} > + > int main(int argc, char *argv[]) > { > struct sigaction act; > @@ -639,7 +663,12 @@ int main(int argc, char *argv[]) > return 2; > } > > - victims = calloc(paging->num_pages, sizeof(xenpaging_victim_t)); > + /* Allocate upper limit of pages to allow growing and shrinking */ > + victims = calloc(paging->max_pages, sizeof(xenpaging_victim_t)); > + > + /* Mark all slots as unallocated */ > + for ( i = 0; i < paging->max_pages; i++ ) > + victims[i].gfn = INVALID_MFN; > > /* ensure that if we get a signal, we'll do cleanup, then exit */ > act.sa_handler = close_handler; > @@ -653,18 +682,7 @@ int main(int argc, char *argv[]) > /* listen for page-in events to stop pager */ > create_page_in_thread(paging); > > - /* Evict pages */ > - for ( i = 0; i < paging->num_pages; i++ ) > - { > - rc = evict_victim(paging, &victims[i], fd, i); > - if ( rc == -ENOSPC ) > - break; > - if ( rc == -EINTR ) > - break; > - if ( i % 100 == 0 ) > - DPRINTF("%d pages evicted\n", i); > - } > - > + i = evict_pages(paging, fd, victims, paging->num_pages); > DPRINTF("%d pages evicted. Done.\n", i); > > /* Swap pages in and out */ > @@ -690,13 +708,13 @@ int main(int argc, char *argv[]) > if ( test_and_clear_bit(req.gfn, paging->bitmap) ) > { > /* Find where in the paging file to read from */ > - for ( i = 0; i < paging->num_pages; i++ ) > + for ( i = 0; i < paging->max_pages; i++ ) > { > if ( victims[i].gfn == req.gfn ) > break; > } > > - if ( i >= paging->num_pages ) > + if ( i >= paging->max_pages ) > { > DPRINTF("Couldn't find page %"PRIx64"\n", req.gfn); > goto out; > > _______________________________________________ > Xen-devel mailing list > Xen-devel@lists.xensource.com > http://lists.xensource.com/xen-devel _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel From xen-devel-bounces@lists.xensource.com Thu Sep 15 01:19:06 2011 Return-path: Envelope-to: www-data@lists.xensource.com Delivery-date: Thu, 15 Sep 2011 01:19:06 -0700 Received: from localhost ([127.0.0.1] helo=lists.colo.xensource.com) by lists.xensource.com with esmtp (Exim 4.43) id 1R47A2-0001Bc-Lj; Thu, 15 Sep 2011 01:19:06 -0700 Received: from mail182.messagelabs.com ([85.158.139.83]) by lists.xensource.com with esmtp (Exim 4.43) id 1R479B-0000yY-LW for xen-devel@lists.xensource.com; Thu, 15 Sep 2011 01:18:14 -0700 X-Env-Sender: konrad@oracle.com X-Msg-Ref: server-8.tower-182.messagelabs.com!1316074689!18416776!1 X-Originating-IP: [148.87.113.117] X-StarScan-Version: 6.4.1; banners=-,-,- X-VirusChecked: Checked Received: (qmail 14955 invoked from network); 15 Sep 2011 08:18:10 -0000 Received: from rcsinet15.oracle.com (HELO rcsinet15.oracle.com) (148.87.113.117) by server-8.tower-182.messagelabs.com with DHE-RSA-AES256-SHA encrypted SMTP; 15 Sep 2011 08:18:10 -0000 Received: from acsinet21.oracle.com (acsinet21.oracle.com [141.146.126.237]) by rcsinet15.oracle.com (Switch-3.4.4/Switch-3.4.4) with ESMTP id p8F8Hl24026372 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Thu, 15 Sep 2011 08:17:49 GMT Received: from acsmt357.oracle.com (acsmt357.oracle.com [141.146.40.157]) by acsinet21.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id p8F8HkfX026971 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 15 Sep 2011 08:17:47 GMT Received: from abhmt110.oracle.com (abhmt110.oracle.com [141.146.116.62]) by acsmt357.oracle.com (8.12.11.20060308/8.12.11) with ESMTP id p8F8Hf1W008153; Thu, 15 Sep 2011 03:17:41 -0500 Received: from oracle.com (/209.6.55.207) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Thu, 15 Sep 2011 01:17:40 -0700 Received: by oracle.com (Postfix, from userid 1000) id C734D1362; Thu, 15 Sep 2011 04:17:41 -0400 (EDT) Date: Thu, 15 Sep 2011 04:17:41 -0400 From: Konrad Rzeszutek Wilk To: Andy Burns Subject: Re: [Xen-devel] Fedora Core 16 + Xen Message-ID: <20110915081741.GA24888@phenom.oracle.com> References: <20110829190056.GA10763@dumpdata.com> <20110829201554.GA18533@imp.local> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.21 (2010-09-15) X-Source-IP: acsinet21.oracle.com [141.146.126.237] X-Auth-Type: Internal IP X-CT-RefId: str=0001.0A090209.4E71B4AE.0068:SCFMA922111,ss=1,re=-4.000,fgs=0 Cc: xen-devel@lists.xensource.com, "W. Michael Petullo" , m.a.young@durham.ac.uk X-BeenThere: xen-devel@lists.xensource.com X-Mailman-Version: 2.1.5 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xensource.com Errors-To: xen-devel-bounces@lists.xensource.com On Wed, Sep 14, 2011 at 06:15:47AM +0100, Andy Burns wrote: > On 29 August 2011 21:15, W. Michael Petullo wrote: > > > > > I was quite excited to see that with Fedora Core 16 I can just do: > > > 'yum install xen' and the hypervisor is installed. > > > > See also in Red Hat Bugzilla: > > > > grub2 --class xen: initramfs missing, booting under XEN fails (found on > > Fedora 16) > > https://bugzilla.redhat.com/show_bug.cgi?id=728775 > > > > > Yes I also encountered the "no initramfs" issue, I submitted a bug with a > patch, before realising that BZ#728775 already existed, anyway I've DUPEd > mine, who can get the relevant one-liner patch pushed? It should be in now. Can you retest please? _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel From xen-devel-bounces@lists.xensource.com Thu Sep 15 01:24:15 2011 Return-path: Envelope-to: www-data@lists.xensource.com Delivery-date: Thu, 15 Sep 2011 01:24:15 -0700 Received: from localhost ([127.0.0.1] helo=lists.colo.xensource.com) by lists.xensource.com with esmtp (Exim 4.43) id 1R47F1-0001ci-Mk; Thu, 15 Sep 2011 01:24:15 -0700 Received: from mail27.messagelabs.com ([193.109.254.147]) by lists.xensource.com with esmtp (Exim 4.43) id 1R47Ec-0001Q5-R6 for xen-devel@lists.xensource.com; Thu, 15 Sep 2011 01:23:51 -0700 X-Env-Sender: konrad@oracle.com X-Msg-Ref: server-14.tower-27.messagelabs.com!1316075012!36208992!1 X-Originating-IP: [148.87.113.117] X-StarScan-Version: 6.4.1; banners=-,-,- X-VirusChecked: Checked Received: (qmail 4625 invoked from network); 15 Sep 2011 08:23:34 -0000 Received: from rcsinet15.oracle.com (HELO rcsinet15.oracle.com) (148.87.113.117) by server-14.tower-27.messagelabs.com with DHE-RSA-AES256-SHA encrypted SMTP; 15 Sep 2011 08:23:34 -0000 Received: from rtcsinet21.oracle.com (rtcsinet21.oracle.com [66.248.204.29]) by rcsinet15.oracle.com (Switch-3.4.4/Switch-3.4.4) with ESMTP id p8F8NgiL006738 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Thu, 15 Sep 2011 08:23:44 GMT Received: from acsmt358.oracle.com (acsmt358.oracle.com [141.146.40.158]) by rtcsinet21.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id p8F8NfVK024695 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 15 Sep 2011 08:23:41 GMT Received: from abhmt115.oracle.com (abhmt115.oracle.com [141.146.116.67]) by acsmt358.oracle.com (8.12.11.20060308/8.12.11) with ESMTP id p8F8NZvR021677; Thu, 15 Sep 2011 03:23:35 -0500 Received: from oracle.com (/209.6.55.207) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Thu, 15 Sep 2011 01:23:35 -0700 Received: by oracle.com (Postfix, from userid 1000) id E4EB41362; Thu, 15 Sep 2011 04:23:35 -0400 (EDT) Date: Thu, 15 Sep 2011 04:23:35 -0400 From: Konrad Rzeszutek Wilk To: Philippe Simonet Subject: Re: [Xen-devel] Xen 4 TSC problems Message-ID: <20110915082335.GB24888@phenom.oracle.com> References: <4E6F034B.5040102@bluewin.ch> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <4E6F034B.5040102@bluewin.ch> User-Agent: Mutt/1.5.21 (2010-09-15) X-Source-IP: rtcsinet21.oracle.com [66.248.204.29] X-CT-RefId: str=0001.0A090202.4E71B610.00FB,ss=1,re=0.000,fgs=0 Cc: xen-devel@lists.xensource.com X-BeenThere: xen-devel@lists.xensource.com X-Mailman-Version: 2.1.5 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xensource.com Errors-To: xen-devel-bounces@lists.xensource.com On Tue, Sep 13, 2011 at 09:16:27AM +0200, Philippe Simonet wrote: > Hi Xen developers > > i just would like to inform you that I have exactly the same problem > with Debian squeeze and xen, with > 50 seconds time jump on my dom0 and domu. NTP is running on all > dom0/domuU, clocksource is 'xen' > everywhere. > > some messages : > syslog : > Sep 11 13:56:50 dnsit22 kernel: [571603.359863] Clocksource tsc > unstable (delta = -2999662111513 ns) > > xm dmesg : > ... > (XEN) Platform timer is 14.318MHz HPET > ... > (XEN) Platform timer appears to have unexpectedly wrapped 10 or more times. > (XEN) TSC marked as reliable, warp = 0 (count=2) > ... > > I had some contact with Olivier Hanesse and it indicates that he > doesn't have any solution for this problem, > and all what was proposed in February didn't solved this problem. Which was the max_cstate=0 ? .. > config : > -------------------------------------- > Linux dnsit22.swissptt.ch 2.6.32-5-xen-amd64 #1 SMP Tue Jun 14 > 12:46:30 UTC 2011 x86_64 GNU/Linux > -------------------------------------- > HP DL385 > -------------------------------------- > vendor_id : AuthenticAMD > cpu family : 16 > model : 9 > model name : AMD Opteron(tm) Processor 6174 > stepping : 1 > cpu MHz : 3058776.574 OK, that is really messed up. Your house must be on fire for the machine to be running at 3058GHz! Jeremy, this sounds familiar - did we have a patch for this in your 2.6.32 tree? _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel From xen-devel-bounces@lists.xensource.com Thu Sep 15 01:25:14 2011 Return-path: Envelope-to: www-data@lists.xensource.com Delivery-date: Thu, 15 Sep 2011 01:25:14 -0700 Received: from localhost ([127.0.0.1] helo=lists.colo.xensource.com) by lists.xensource.com with esmtp (Exim 4.43) id 1R47Fy-00020C-L4; Thu, 15 Sep 2011 01:25:14 -0700 Received: from mail21.messagelabs.com ([85.158.143.35]) by lists.xensource.com with esmtp (Exim 4.43) id 1R47F4-0001ct-Ir for xen-devel@lists.xensource.com; Thu, 15 Sep 2011 01:24:18 -0700 X-Env-Sender: konrad@oracle.com X-Msg-Ref: server-6.tower-21.messagelabs.com!1316075034!38316796!1 X-Originating-IP: [148.87.113.117] X-StarScan-Version: 6.4.1; banners=-,-,- X-VirusChecked: Checked Received: (qmail 4296 invoked from network); 15 Sep 2011 08:23:55 -0000 Received: from rcsinet15.oracle.com (HELO rcsinet15.oracle.com) (148.87.113.117) by server-6.tower-21.messagelabs.com with DHE-RSA-AES256-SHA encrypted SMTP; 15 Sep 2011 08:23:55 -0000 Received: from rtcsinet21.oracle.com (rtcsinet21.oracle.com [66.248.204.29]) by rcsinet15.oracle.com (Switch-3.4.4/Switch-3.4.4) with ESMTP id p8F8O8hw007559 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Thu, 15 Sep 2011 08:24:10 GMT Received: from acsmt357.oracle.com (acsmt357.oracle.com [141.146.40.157]) by rtcsinet21.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id p8F8O7sj025174 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 15 Sep 2011 08:24:08 GMT Received: from abhmt113.oracle.com (abhmt113.oracle.com [141.146.116.65]) by acsmt357.oracle.com (8.12.11.20060308/8.12.11) with ESMTP id p8F8O2Yx012615; Thu, 15 Sep 2011 03:24:02 -0500 Received: from oracle.com (/209.6.55.207) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Thu, 15 Sep 2011 01:24:02 -0700 Received: by oracle.com (Postfix, from userid 1000) id 000971362; Thu, 15 Sep 2011 04:24:02 -0400 (EDT) Date: Thu, 15 Sep 2011 04:24:02 -0400 From: Konrad Rzeszutek Wilk To: Philippe Simonet , Jeremy Fitzhardinge Subject: Re: [Xen-devel] Xen 4 TSC problems Message-ID: <20110915082402.GC24888@phenom.oracle.com> References: <4E6F034B.5040102@bluewin.ch> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <4E6F034B.5040102@bluewin.ch> User-Agent: Mutt/1.5.21 (2010-09-15) X-Source-IP: rtcsinet21.oracle.com [66.248.204.29] X-CT-RefId: str=0001.0A090202.4E71B62A.01FF,ss=1,re=0.000,fgs=0 Cc: xen-devel@lists.xensource.com X-BeenThere: xen-devel@lists.xensource.com X-Mailman-Version: 2.1.5 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xensource.com Errors-To: xen-devel-bounces@lists.xensource.com On Tue, Sep 13, 2011 at 09:16:27AM +0200, Philippe Simonet wrote: > Hi Xen developers Lets try this again, this time Cc-ing Jeremy. > > i just would like to inform you that I have exactly the same problem > with Debian squeeze and xen, with > 50 seconds time jump on my dom0 and domu. NTP is running on all > dom0/domuU, clocksource is 'xen' > everywhere. > > some messages : > syslog : > Sep 11 13:56:50 dnsit22 kernel: [571603.359863] Clocksource tsc > unstable (delta = -2999662111513 ns) > > xm dmesg : > ... > (XEN) Platform timer is 14.318MHz HPET > ... > (XEN) Platform timer appears to have unexpectedly wrapped 10 or more times. > (XEN) TSC marked as reliable, warp = 0 (count=2) > ... > > I had some contact with Olivier Hanesse and it indicates that he > doesn't have any solution for this problem, > and all what was proposed in February didn't solved this problem. Which was the max_cstate=0 ? .. > config : > -------------------------------------- > Linux dnsit22.swissptt.ch 2.6.32-5-xen-amd64 #1 SMP Tue Jun 14 > 12:46:30 UTC 2011 x86_64 GNU/Linux > -------------------------------------- > HP DL385 > -------------------------------------- > vendor_id : AuthenticAMD > cpu family : 16 > model : 9 > model name : AMD Opteron(tm) Processor 6174 > stepping : 1 > cpu MHz : 3058776.574 OK, that is really messed up. Your house must be on fire for the machine to be running at 3058GHz! Jeremy, this sounds familiar - did we have a patch for this in your 2.6.32 tree? _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel From xen-devel-bounces@lists.xensource.com Thu Sep 15 02:07:59 2011 Return-path: Envelope-to: www-data@lists.xensource.com Delivery-date: Thu, 15 Sep 2011 02:07:59 -0700 Received: from localhost ([127.0.0.1] helo=lists.colo.xensource.com) by lists.xensource.com with esmtp (Exim 4.43) id 1R47vK-0003OP-IJ; Thu, 15 Sep 2011 02:07:58 -0700 Received: from mail182.messagelabs.com ([85.158.139.83]) by lists.xensource.com with esmtp (Exim 4.43) id 1R47tG-0003Ac-I5 for xen-devel@lists.xensource.com; Thu, 15 Sep 2011 02:06:00 -0700 X-Env-Sender: dunlapg@gmail.com X-Msg-Ref: server-9.tower-182.messagelabs.com!1316077547!18400864!1 X-Originating-IP: [74.125.82.43] X-StarScan-Version: 6.4.1; banners=-,-,- X-VirusChecked: Checked Received: (qmail 9541 invoked from network); 15 Sep 2011 09:05:47 -0000 Received: from mail-ww0-f43.google.com (HELO mail-ww0-f43.google.com) (74.125.82.43) by server-9.tower-182.messagelabs.com with RC4-SHA encrypted SMTP; 15 Sep 2011 09:05:47 -0000 Received: by wwf27 with SMTP id 27so2687763wwf.24 for ; Thu, 15 Sep 2011 02:05:47 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=mX7Qy552bYH9YXzV5mWbYw/2gticdk1C/p7T27obnvM=; b=dNRej5gLdxWSoqUZvSn2RL+v7Cc56oeQ706gZfJ3MXiS0+ssIBahRGAKtmFSdJRZ7B eSWb7jL2MAMfFQ5o8PlW9fjbJMJJEgW5ft3vg9PPqGhOMHvbON1duKuACz76kRVvO5+L rbNJxo+rxnkLs4busaPD7FPyw5Au8IDpBNADA= MIME-Version: 1.0 Received: by 10.216.154.145 with SMTP id h17mr992075wek.39.1316077546949; Thu, 15 Sep 2011 02:05:46 -0700 (PDT) Received: by 10.216.176.81 with HTTP; Thu, 15 Sep 2011 02:05:46 -0700 (PDT) In-Reply-To: <1316074602.25935.4.camel@cthulhu.hellion.org.uk> References: <3a3a5979b799d9488021.1316067394@probook.site> <1316074602.25935.4.camel@cthulhu.hellion.org.uk> Date: Thu, 15 Sep 2011 10:05:46 +0100 X-Google-Sender-Auth: 4aeGEpOO4XMMuwez0fV7_q5ouvg Message-ID: Subject: Re: [Xen-devel] [PATCH 6 of 9] xenpaging: add evict_pages function From: George Dunlap To: Ian Campbell Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: Olaf Hering , "xen-devel@lists.xensource.com" X-BeenThere: xen-devel@lists.xensource.com X-Mailman-Version: 2.1.5 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xensource.com Errors-To: xen-devel-bounces@lists.xensource.com On Thu, Sep 15, 2011 at 9:16 AM, Ian Campbell wro= te: > On Thu, 2011-09-15 at 02:16 -0400, Olaf Hering wrote: >> # HG changeset patch >> # User Olaf Hering >> # Date 1316067230 -7200 >> # Node ID 3a3a5979b799d948802183d10d65894ee84a872f >> # Parent =A06beca8cbc2c92900859712f8738db17084bcebdb >> xenpaging: add evict_pages function >> >> Add new function to evict a couple of pages. > > Do you really mean "a couple" here? (that generally means exactly two). LIterally "couple" means two, but at least in US idiom, "a couple of [foo]" means a small indeterminate number, usually 2-4. In any case, a more precise description seems like a better idea -- it looks like it takes an argument for the number of pages to evict; and it's not adding a new function, it's pulling existing code into a function. So, "Pull eviction loop into a function" would probably be a better description. -George > >From the implementation I think you mean evict a batch of pages? > >> Allocate all possible slots in a paging file to allow growing and >> shrinking of the number of paged-out pages. Adjust other places to >> iterate over all slots. >> >> This change is required by subsequent patches. >> >> Signed-off-by: Olaf Hering >> >> diff -r 6beca8cbc2c9 -r 3a3a5979b799 tools/xenpaging/xenpaging.c >> --- a/tools/xenpaging/xenpaging.c >> +++ b/tools/xenpaging/xenpaging.c >> @@ -597,6 +597,30 @@ static int evict_victim(xenpaging_t *pag >> =A0 =A0 =A0return ret; >> =A0} >> >> +/* Evict a couple of pages and write them to a free slot in the paging = file */ >> +static int evict_pages(xenpaging_t *paging, int fd, xenpaging_victim_t = *victims, int num_pages) >> +{ >> + =A0 =A0xc_interface *xch =3D paging->xc_handle; >> + =A0 =A0int rc, slot, num =3D 0; >> + >> + =A0 =A0for ( slot =3D 0; slot < paging->max_pages && num < num_pages; = slot++ ) >> + =A0 =A0{ >> + =A0 =A0 =A0 =A0/* Slot is allocated */ >> + =A0 =A0 =A0 =A0if ( victims[slot].gfn !=3D INVALID_MFN ) >> + =A0 =A0 =A0 =A0 =A0 =A0continue; >> + >> + =A0 =A0 =A0 =A0rc =3D evict_victim(paging, &victims[slot], fd, slot); >> + =A0 =A0 =A0 =A0if ( rc =3D=3D -ENOSPC ) >> + =A0 =A0 =A0 =A0 =A0 =A0break; >> + =A0 =A0 =A0 =A0if ( rc =3D=3D -EINTR ) >> + =A0 =A0 =A0 =A0 =A0 =A0break; >> + =A0 =A0 =A0 =A0if ( num && num % 100 =3D=3D 0 ) >> + =A0 =A0 =A0 =A0 =A0 =A0DPRINTF("%d pages evicted\n", num); >> + =A0 =A0 =A0 =A0num++; >> + =A0 =A0} >> + =A0 =A0return num; >> +} >> + >> =A0int main(int argc, char *argv[]) >> =A0{ >> =A0 =A0 =A0struct sigaction act; >> @@ -639,7 +663,12 @@ int main(int argc, char *argv[]) >> =A0 =A0 =A0 =A0 =A0return 2; >> =A0 =A0 =A0} >> >> - =A0 =A0victims =3D calloc(paging->num_pages, sizeof(xenpaging_victim_t= )); >> + =A0 =A0/* Allocate upper limit of pages to allow growing and shrinking= */ >> + =A0 =A0victims =3D calloc(paging->max_pages, sizeof(xenpaging_victim_t= )); >> + >> + =A0 =A0/* Mark all slots as unallocated */ >> + =A0 =A0for ( i =3D 0; i < paging->max_pages; i++ ) >> + =A0 =A0 =A0 =A0victims[i].gfn =3D INVALID_MFN; >> >> =A0 =A0 =A0/* ensure that if we get a signal, we'll do cleanup, then exi= t */ >> =A0 =A0 =A0act.sa_handler =3D close_handler; >> @@ -653,18 +682,7 @@ int main(int argc, char *argv[]) >> =A0 =A0 =A0/* listen for page-in events to stop pager */ >> =A0 =A0 =A0create_page_in_thread(paging); >> >> - =A0 =A0/* Evict pages */ >> - =A0 =A0for ( i =3D 0; i < paging->num_pages; i++ ) >> - =A0 =A0{ >> - =A0 =A0 =A0 =A0rc =3D evict_victim(paging, &victims[i], fd, i); >> - =A0 =A0 =A0 =A0if ( rc =3D=3D -ENOSPC ) >> - =A0 =A0 =A0 =A0 =A0 =A0break; >> - =A0 =A0 =A0 =A0if ( rc =3D=3D -EINTR ) >> - =A0 =A0 =A0 =A0 =A0 =A0break; >> - =A0 =A0 =A0 =A0if ( i % 100 =3D=3D 0 ) >> - =A0 =A0 =A0 =A0 =A0 =A0DPRINTF("%d pages evicted\n", i); >> - =A0 =A0} >> - >> + =A0 =A0i =3D evict_pages(paging, fd, victims, paging->num_pages); >> =A0 =A0 =A0DPRINTF("%d pages evicted. Done.\n", i); >> >> =A0 =A0 =A0/* Swap pages in and out */ >> @@ -690,13 +708,13 @@ int main(int argc, char *argv[]) >> =A0 =A0 =A0 =A0 =A0 =A0 =A0if ( test_and_clear_bit(req.gfn, paging->bitm= ap) ) >> =A0 =A0 =A0 =A0 =A0 =A0 =A0{ >> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0/* Find where in the paging file to r= ead from */ >> - =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0for ( i =3D 0; i < paging->num_pages; i= ++ ) >> + =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0for ( i =3D 0; i < paging->max_pages; i= ++ ) >> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0{ >> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0if ( victims[i].gfn =3D=3D re= q.gfn ) >> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0break; >> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0} >> >> - =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0if ( i >=3D paging->num_pages ) >> + =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0if ( i >=3D paging->max_pages ) >> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0{ >> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0DPRINTF("Couldn't find page %= "PRIx64"\n", req.gfn); >> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0goto out; >> >> _______________________________________________ >> Xen-devel mailing list >> Xen-devel@lists.xensource.com >> http://lists.xensource.com/xen-devel > > > > _______________________________________________ > Xen-devel mailing list > Xen-devel@lists.xensource.com > http://lists.xensource.com/xen-devel > _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel From xen-devel-bounces@lists.xensource.com Thu Sep 15 02:11:46 2011 Return-path: Envelope-to: www-data@lists.xensource.com Delivery-date: Thu, 15 Sep 2011 02:11:46 -0700 Received: from localhost ([127.0.0.1] helo=lists.colo.xensource.com) by lists.xensource.com with esmtp (Exim 4.43) id 1R47yz-0003ns-Di; Thu, 15 Sep 2011 02:11:45 -0700 Received: from mail216.messagelabs.com ([85.158.143.99]) by lists.xensource.com with esmtp (Exim 4.43) id 1R47y8-0003b1-2v for Xen-devel@lists.xensource.com; Thu, 15 Sep 2011 02:10:53 -0700 X-Env-Sender: jeremy@goop.org X-Msg-Ref: server-3.tower-216.messagelabs.com!1316077847!17315551!1 X-Originating-IP: [74.207.240.146] X-StarScan-Version: 6.4.1; banners=-,-,- X-VirusChecked: Checked Received: (qmail 2145 invoked from network); 15 Sep 2011 09:10:49 -0000 Received: from claw.goop.org (HELO claw.goop.org) (74.207.240.146) by server-3.tower-216.messagelabs.com with DHE-RSA-AES256-SHA encrypted SMTP; 15 Sep 2011 09:10:49 -0000 Received: from saboo.goop.org (unknown [IPv6:2001:470:1f05:899:f2de:f1ff:fe5c:34ed]) (Authenticated sender: smtp-saboo) by claw.goop.org (Postfix) with ESMTPSA id 101349769; Thu, 15 Sep 2011 02:10:47 -0700 (PDT) Received: from saboo.goop.org (localhost [IPv6:::1]) by saboo.goop.org (Postfix) with ESMTP id 5A91120B96; Thu, 15 Sep 2011 02:10:46 -0700 (PDT) Message-ID: <4E71C116.4080400@goop.org> Date: Thu, 15 Sep 2011 02:10:46 -0700 From: Jeremy Fitzhardinge User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:6.0.2) Gecko/20110906 Thunderbird/6.0.2 MIME-Version: 1.0 To: Stephen Rothwell References: <20110915152723.b3bdd6a5478c810245fabca1@canb.auug.org.au> In-Reply-To: <20110915152723.b3bdd6a5478c810245fabca1@canb.auug.org.au> X-Enigmail-Version: 1.3.1 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: Xen Devel , linux-next@vger.kernel.org, linux-kernel@vger.kernel.org Subject: [Xen-devel] Re: linux-next: build failure after merge of the xen tree X-BeenThere: xen-devel@lists.xensource.com X-Mailman-Version: 2.1.5 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xensource.com Errors-To: xen-devel-bounces@lists.xensource.com On 09/14/2011 10:27 PM, Stephen Rothwell wrote: > Hi all, > > After merging the xen tree, today's linux-next build (x86_64 allmodconfig) > failed like this: > > arch/x86/xen/time.c: In function 'xen_set_wallclock': > arch/x86/xen/time.c:204:25: error: storage size of 'op' isn't known > arch/x86/xen/time.c:211:11: error: 'XENPF_settime' undeclared (first use in this function) > arch/x86/xen/time.c:211:11: note: each undeclared identifier is reported only once for each function it appears in > arch/x86/xen/time.c:216:2: error: implicit declaration of function 'HYPERVISOR_dom0_op' > arch/x86/xen/time.c:204:25: warning: unused variable 'op' > > Caused by commit 7b11a83f592a ("xen/dom0: set wallclock time in Xen"). > > I have used teh xen tree from next-20110914 for today. Thanks, I'll drop that for now. J _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel From xen-devel-bounces@lists.xensource.com Thu Sep 15 02:16:20 2011 Return-path: Envelope-to: www-data@lists.xensource.com Delivery-date: Thu, 15 Sep 2011 02:16:20 -0700 Received: from localhost ([127.0.0.1] helo=lists.colo.xensource.com) by lists.xensource.com with esmtp (Exim 4.43) id 1R483Q-0004Dx-2H; Thu, 15 Sep 2011 02:16:20 -0700 Received: from mail174.messagelabs.com ([85.158.138.51]) by lists.xensource.com with esmtp (Exim 4.43) id 1R482v-00041r-OV for xen-devel@lists.xensource.com; Thu, 15 Sep 2011 02:15:50 -0700 X-Env-Sender: dunlapg@gmail.com X-Msg-Ref: server-15.tower-174.messagelabs.com!1316078145!25149863!1 X-Originating-IP: [74.125.82.171] X-StarScan-Version: 6.4.1; banners=-,-,- X-VirusChecked: Checked Received: (qmail 13775 invoked from network); 15 Sep 2011 09:15:46 -0000 Received: from mail-wy0-f171.google.com (HELO mail-wy0-f171.google.com) (74.125.82.171) by server-15.tower-174.messagelabs.com with RC4-SHA encrypted SMTP; 15 Sep 2011 09:15:46 -0000 Received: by wyh13 with SMTP id 13so2797086wyh.30 for ; Thu, 15 Sep 2011 02:15:45 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=kkRpsuBjUS3s/sI3K9m1aHrt9XdOHqzuZCXGEwLPYPs=; b=DBIfX6Cla4tlfZoxIgbIYmKvuqy2nLfueA/Hk5Nkedol3tUl7vI0u9XewESQy+S3TJ Splv6B32K/YoCSCT1AUpNQoe6Pnu90BVNAiC7JSgkhiOoQuUYdAfZahN5yv+GMEeU3Lo maYQfrKxmnBZLT+aw90GVt4r2k1o8+jYAhy2o= MIME-Version: 1.0 Received: by 10.216.131.199 with SMTP id m49mr1071595wei.9.1316078144906; Thu, 15 Sep 2011 02:15:44 -0700 (PDT) Received: by 10.216.176.81 with HTTP; Thu, 15 Sep 2011 02:15:44 -0700 (PDT) In-Reply-To: <6987aa2dde4e93481f15.1316067395@probook.site> References: <6987aa2dde4e93481f15.1316067395@probook.site> Date: Thu, 15 Sep 2011 10:15:44 +0100 X-Google-Sender-Auth: Y4u7287OwsL_dWAP06SUkKs6E1o Message-ID: Subject: Re: [Xen-devel] [PATCH 7 of 9] xenpaging: add resume_pages function From: George Dunlap To: Olaf Hering Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: xen-devel@lists.xensource.com X-BeenThere: xen-devel@lists.xensource.com X-Mailman-Version: 2.1.5 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xensource.com Errors-To: xen-devel-bounces@lists.xensource.com On Thu, Sep 15, 2011 at 7:16 AM, Olaf Hering wrote: > # HG changeset patch > # User Olaf Hering > # Date 1316067232 -7200 > # Node ID 6987aa2dde4e93481f1599735ed1a26defb6d6b9 > # Parent =A03a3a5979b799d948802183d10d65894ee84a872f > xenpaging: add resume_pages function > > Add new function to resume a couple of pages. > This change is required by subsequent patches. Olaf, if you end up re-submitting this patch series for any reason, I would combine this patch and the previous patch, and make the description something like this: "Pull page eviction and resume loops into their own functions." That gives a better idea what's going on. Since neither really makes any functional changes, there's no need to have separate patches, IMHO. (I don't think that in itself is worth rejecting the series for.) -George > > Signed-off-by: Olaf Hering > > diff -r 3a3a5979b799 -r 6987aa2dde4e tools/xenpaging/xenpaging.c > --- a/tools/xenpaging/xenpaging.c > +++ b/tools/xenpaging/xenpaging.c > @@ -554,6 +554,27 @@ static int xenpaging_populate_page(xenpa > =A0 =A0 return ret; > =A0} > > +/* Trigger a page-in for a couple of pages */ > +static void resume_pages(xenpaging_t *paging, int num_pages) > +{ > + =A0 =A0xc_interface *xch =3D paging->xc_handle; > + =A0 =A0int i, num =3D 0; > + > + =A0 =A0for ( i =3D 0; i < paging->max_pages && num < num_pages; i++ ) > + =A0 =A0{ > + =A0 =A0 =A0 =A0if ( test_bit(i, paging->bitmap) ) > + =A0 =A0 =A0 =A0{ > + =A0 =A0 =A0 =A0 =A0 =A0paging->pagein_queue[num] =3D i; > + =A0 =A0 =A0 =A0 =A0 =A0num++; > + =A0 =A0 =A0 =A0 =A0 =A0if ( num =3D=3D XENPAGING_PAGEIN_QUEUE_SIZE ) > + =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0break; > + =A0 =A0 =A0 =A0} > + =A0 =A0} > + =A0 =A0/* num may be less than num_pages, caller has to try again */ > + =A0 =A0if ( num ) > + =A0 =A0 =A0 =A0page_in_trigger(); > +} > + > =A0static int evict_victim(xenpaging_t *paging, > =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 xenpaging_victim_t *victi= m, int fd, int i) > =A0{ > @@ -785,25 +806,12 @@ int main(int argc, char *argv[]) > =A0 =A0 =A0 =A0 /* Write all pages back into the guest */ > =A0 =A0 =A0 =A0 if ( interrupted =3D=3D SIGTERM || interrupted =3D=3D SIG= INT ) > =A0 =A0 =A0 =A0 { > - =A0 =A0 =A0 =A0 =A0 =A0int num =3D 0; > - =A0 =A0 =A0 =A0 =A0 =A0for ( i =3D 0; i < paging->max_pages; i++ ) > - =A0 =A0 =A0 =A0 =A0 =A0{ > - =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0if ( test_bit(i, paging->bitmap) ) > - =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0{ > - =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0paging->pagein_queue[num] =3D i; > - =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0num++; > - =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0if ( num =3D=3D XENPAGING_PAGEIN= _QUEUE_SIZE ) > - =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0break; > - =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0} > - =A0 =A0 =A0 =A0 =A0 =A0} > - =A0 =A0 =A0 =A0 =A0 =A0/* > - =A0 =A0 =A0 =A0 =A0 =A0 * One more round if there are still pages to pr= ocess. > - =A0 =A0 =A0 =A0 =A0 =A0 * If no more pages to process, exit loop. > - =A0 =A0 =A0 =A0 =A0 =A0 */ > - =A0 =A0 =A0 =A0 =A0 =A0if ( num ) > - =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0page_in_trigger(); > - =A0 =A0 =A0 =A0 =A0 =A0else if ( i =3D=3D paging->max_pages ) > + =A0 =A0 =A0 =A0 =A0 =A0/* If no more pages to process, exit loop. */ > + =A0 =A0 =A0 =A0 =A0 =A0if ( !paging->num_paged_out ) > =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 break; > + > + =A0 =A0 =A0 =A0 =A0 =A0/* One more round if there are still pages to pr= ocess. */ > + =A0 =A0 =A0 =A0 =A0 =A0resume_pages(paging, paging->num_paged_out); > =A0 =A0 =A0 =A0 } > =A0 =A0 =A0 =A0 else > =A0 =A0 =A0 =A0 { > > _______________________________________________ > Xen-devel mailing list > Xen-devel@lists.xensource.com > http://lists.xensource.com/xen-devel > _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel From xen-devel-bounces@lists.xensource.com Thu Sep 15 02:18:30 2011 Return-path: Envelope-to: www-data@lists.xensource.com Delivery-date: Thu, 15 Sep 2011 02:18:30 -0700 Received: from localhost ([127.0.0.1] helo=lists.colo.xensource.com) by lists.xensource.com with esmtp (Exim 4.43) id 1R485W-0004dC-Ju; Thu, 15 Sep 2011 02:18:30 -0700 Received: from mail21.messagelabs.com ([85.158.143.35]) by lists.xensource.com with esmtp (Exim 4.43) id 1R484r-0004QC-9q for xen-devel@lists.xensource.com; Thu, 15 Sep 2011 02:17:50 -0700 X-Env-Sender: olaf@aepfle.de X-Msg-Ref: server-5.tower-21.messagelabs.com!1316078233!48205066!1 X-Originating-IP: [81.169.146.160] X-StarScan-Version: 6.4.1; banners=-,-,- X-VirusChecked: Checked Received: (qmail 12499 invoked from network); 15 Sep 2011 09:17:13 -0000 Received: from mo-p00-ob.rzone.de (HELO mo-p00-ob.rzone.de) (81.169.146.160) by server-5.tower-21.messagelabs.com with DHE-RSA-AES256-SHA encrypted SMTP; 15 Sep 2011 09:17:13 -0000 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; t=1316078265; l=1094; s=domk; d=aepfle.de; h=In-Reply-To:Content-Transfer-Encoding:Content-Type:MIME-Version: References:Subject:Cc:To:From:Date:X-RZG-CLASS-ID:X-RZG-AUTH; bh=hOOK6yUYVvXqbiTY4U6mNdtYMO0=; b=D+Kc8sPSlb0EwqNgSYHQHWE45fxfMq8I+SIoO8KY57tm1vSoFASnDuwMb6TfQGech8L 7zpA2Y0CE3lxvqrIG/m117mj+vep226FGiHRt1ImotYGuzBOt3PWI3KB9it5j69ynomrM 5t4zlQEJBIufM32y+z5rKu80nZSczYjm/OY= X-RZG-AUTH: :P2EQZWCpfu+qG7CngxMFH1J+zrwiavkK6tmQaLfmxtMZ80VwmRNV7HU= X-RZG-CLASS-ID: mo00 Received: from probook.site (ip-80-226-24-6.vodafone-net.de [80.226.24.6]) by smtp.strato.de (jimi mo38) (RZmta 26.7) with (DHE-RSA-AES256-SHA encrypted) ESMTPA id j019can8F8NZlI ; Thu, 15 Sep 2011 11:17:26 +0200 (MEST) Received: by probook.site (Postfix, from userid 1000) id 0933618B67; Thu, 15 Sep 2011 11:17:23 +0200 (CEST) Date: Thu, 15 Sep 2011 11:17:23 +0200 From: Olaf Hering To: George Dunlap Subject: Re: [Xen-devel] [PATCH 6 of 9] xenpaging: add evict_pages function Message-ID: <20110915091723.GA18591@aepfle.de> References: <3a3a5979b799d9488021.1316067394@probook.site> <1316074602.25935.4.camel@cthulhu.hellion.org.uk> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: User-Agent: Mutt/1.5.21.rev5535 (2011-07-01) Cc: "xen-devel@lists.xensource.com" , Ian Campbell X-BeenThere: xen-devel@lists.xensource.com X-Mailman-Version: 2.1.5 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xensource.com Errors-To: xen-devel-bounces@lists.xensource.com On Thu, Sep 15, George Dunlap wrote: > On Thu, Sep 15, 2011 at 9:16 AM, Ian Campbell wrote: > > On Thu, 2011-09-15 at 02:16 -0400, Olaf Hering wrote: > >> # HG changeset patch > >> # User Olaf Hering > >> # Date 1316067230 -7200 > >> # Node ID 3a3a5979b799d948802183d10d65894ee84a872f > >> # Parent  6beca8cbc2c92900859712f8738db17084bcebdb > >> xenpaging: add evict_pages function > >> > >> Add new function to evict a couple of pages. > > > > Do you really mean "a couple" here? (that generally means exactly two). > > LIterally "couple" means two, but at least in US idiom, "a couple of > [foo]" means a small indeterminate number, usually 2-4. > > In any case, a more precise description seems like a better idea -- it > looks like it takes an argument for the number of pages to evict; and > it's not adding a new function, it's pulling existing code into a > function. So, "Pull eviction loop into a function" would probably be > a better description. Thanks to both of you, I will improve the description. Olaf _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel From xen-devel-bounces@lists.xensource.com Thu Sep 15 02:23:31 2011 Return-path: Envelope-to: www-data@lists.xensource.com Delivery-date: Thu, 15 Sep 2011 02:23:31 -0700 Received: from localhost ([127.0.0.1] helo=lists.colo.xensource.com) by lists.xensource.com with esmtp (Exim 4.43) id 1R48AN-00054R-Gw; Thu, 15 Sep 2011 02:23:31 -0700 Received: from mail216.messagelabs.com ([85.158.143.99]) by lists.xensource.com with esmtp (Exim 4.43) id 1R489j-0004ru-Ek for xen-devel@lists.xensource.com; Thu, 15 Sep 2011 02:22:51 -0700 X-Env-Sender: Stefano.Stabellini@eu.citrix.com X-Msg-Ref: server-15.tower-216.messagelabs.com!1316078429!17884411!1 X-Originating-IP: [62.200.22.115] X-StarScan-Version: 6.4.1; banners=-,-,- X-VirusChecked: Checked Received: (qmail 18688 invoked from network); 15 Sep 2011 09:20:29 -0000 Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115) by server-15.tower-216.messagelabs.com with RC4-SHA encrypted SMTP; 15 Sep 2011 09:20:29 -0000 X-IronPort-AV: E=Sophos;i="4.68,386,1312156800"; d="scan'208";a="7844549" Received: from lonpmailmx01.citrite.net ([10.30.203.162]) by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5; 15 Sep 2011 09:20:27 +0000 Received: from kaball.uk.xensource.com (10.80.2.59) by LONPMAILMX01.citrite.net (10.30.203.162) with Microsoft SMTP Server id 8.3.137.0; Thu, 15 Sep 2011 10:20:26 +0100 Date: Thu, 15 Sep 2011 10:28:59 +0100 From: Stefano Stabellini X-X-Sender: sstabellini@kaball-desktop To: Konrad Rzeszutek Wilk Subject: Re: [Xen-devel] Several issues with Xen 4.1.1 regarding Windows guests (and more...) In-Reply-To: <20110914150635.GA18147@phenom.oracle.com> Message-ID: References: <1315951748.7224.5.camel@kali.ninth-art.net> <4E6FE3CB.30209@gt.net> <20110914150635.GA18147@phenom.oracle.com> User-Agent: Alpine 2.00 (DEB 1167 2008-08-23) MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Cc: "xen-devel@lists.xensource.com" , Nathan March , "therion@ninth-art.de" X-BeenThere: xen-devel@lists.xensource.com X-Mailman-Version: 2.1.5 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xensource.com Errors-To: xen-devel-bounces@lists.xensource.com On Wed, 14 Sep 2011, Konrad Rzeszutek Wilk wrote: > On Tue, Sep 13, 2011 at 04:14:19PM -0700, Nathan March wrote: > > > > > > On 9/13/2011 3:09 PM, Georg Bege wrote: > > >Hello > > > > > >Im experiencing serveral issues right now, Im not well Xen experienced - > > >I tried it first in '06 and staid off from it since last week. > > > > > >b) I managed to install Windows XP fine, however the performance (I/O in > > >general) is quite poor compared to VirtualBox. > > Can't comment on the rest, but have you installed the gplpv drivers? > > > > http://www.meadowcourt.org/downloads/ > > > > The wiki has some details but is quite out of date: > > http://wiki.xensource.com/xenwiki/XenWindowsGplPv > > > > On win2008 I install the OS, do a "bcedit /set testsigning on", > > reboot, then install the gplpv. > > Or you can installed the signed versions: > > http://marc.info/?i=201109090950.05043.muehlenhoff@univention.de we should add them to the wiki _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel From xen-devel-bounces@lists.xensource.com Thu Sep 15 02:51:38 2011 Return-path: Envelope-to: www-data@lists.xensource.com Delivery-date: Thu, 15 Sep 2011 02:51:38 -0700 Received: from localhost ([127.0.0.1] helo=lists.colo.xensource.com) by lists.xensource.com with esmtp (Exim 4.43) id 1R48ba-0007HG-Mx; Thu, 15 Sep 2011 02:51:38 -0700 Received: from mail174.messagelabs.com ([85.158.138.51]) by lists.xensource.com with smtp (Exim 4.43) id 1R48b5-00075S-4D for xen-devel@lists.xensource.com; Thu, 15 Sep 2011 02:51:07 -0700 X-Env-Sender: muehlenhoff@univention.de X-Msg-Ref: server-5.tower-174.messagelabs.com!1316080263!27810131!1 X-Originating-IP: [82.198.197.8] X-StarScan-Version: 6.4.1; banners=-,-,- X-VirusChecked: Checked Received: (qmail 7141 invoked from network); 15 Sep 2011 09:51:03 -0000 Received: from mail.univention.de (HELO mail.univention.de) (82.198.197.8) by server-5.tower-174.messagelabs.com with SMTP; 15 Sep 2011 09:51:03 -0000 Received: from localhost (localhost [127.0.0.1]) by slugis.knut.univention.de (Postfix) with ESMTP id D4B60CA380; Thu, 15 Sep 2011 11:51:00 +0200 (CEST) Received: from localhost (localhost [127.0.0.1]) by slugis.knut.univention.de (Postfix) with ESMTP id C594E673001; Thu, 15 Sep 2011 11:51:00 +0200 (CEST) X-Virus-Scanned: by amavisd-new-2.6.1 (20080629) (Debian) at knut.univention.de Received: from mail.univention.de ([127.0.0.1]) by localhost (slugis.knut.univention.de [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ye-o7M6rqjvS; Thu, 15 Sep 2011 11:51:00 +0200 (CEST) Received: from vurm.localnet (vurm.knut.univention.de [192.168.0.132]) by slugis.knut.univention.de (Postfix) with ESMTPSA id 5FDDBCA380; Thu, 15 Sep 2011 11:51:00 +0200 (CEST) From: Moritz =?iso-8859-1?q?M=FChlenhoff?= To: xen-devel@lists.xensource.com Subject: Re: [Xen-devel] Several issues with Xen 4.1.1 regarding Windows guests (and more...) Date: Thu, 15 Sep 2011 11:50:57 +0200 User-Agent: KMail/1.13.5 (Linux/2.6.32-ucs44-amd64; KDE/4.4.5; x86_64; ; ) References: <1315951748.7224.5.camel@kali.ninth-art.net> <20110914150635.GA18147@phenom.oracle.com> In-Reply-To: MIME-Version: 1.0 Content-Type: Text/Plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Message-Id: <201109151150.57836.muehlenhoff@univention.de> Cc: Konrad Rzeszutek Wilk , "therion@ninth-art.de" , Nathan March , Stefano Stabellini X-BeenThere: xen-devel@lists.xensource.com X-Mailman-Version: 2.1.5 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xensource.com Errors-To: xen-devel-bounces@lists.xensource.com Stefano Stabellini wrote: > > > On win2008 I install the OS, do a "bcedit /set testsigning on", > > > reboot, then install the gplpv. > >=20 > > Or you can installed the signed versions: > >=20 > > http://marc.info/?i=3D201109090950.05043.muehlenhoff@univention.de >=20 > we should add them to the wiki It's probably easiest if you just place a link to this web page: http://wiki.univention.de/index.php?title=3DInstalling-signed-GPLPV-drivers We'll keep this page updated for new installation hints, updated driver bui= lds=20 etc. Cheers, Moritz =2D-=20 Moritz M=FChlenhoff muehlenhoff@univention.de Open Source Software Engineer and Consultant Univention GmbH Linux for Your Business fon: +49 421 22 232- 0 Mary-Somerville-Str.1 28359 Bremen fax: +49 421 22 232-99 http://www.univention.de _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel From xen-devel-bounces@lists.xensource.com Thu Sep 15 03:10:29 2011 Return-path: Envelope-to: www-data@lists.xensource.com Delivery-date: Thu, 15 Sep 2011 03:10:29 -0700 Received: from localhost ([127.0.0.1] helo=lists.colo.xensource.com) by lists.xensource.com with esmtp (Exim 4.43) id 1R48to-0007x7-Uw; Thu, 15 Sep 2011 03:10:28 -0700 Received: from mail174.messagelabs.com ([85.158.138.51]) by lists.xensource.com with esmtp (Exim 4.43) id 1R48sm-0007k6-Fr for xen-devel@lists.xensource.com; Thu, 15 Sep 2011 03:09:25 -0700 X-Env-Sender: Ian.Jackson@eu.citrix.com X-Msg-Ref: server-10.tower-174.messagelabs.com!1316081325!31499200!1 X-Originating-IP: [62.200.22.115] X-StarScan-Version: 6.4.1; banners=-,-,- X-VirusChecked: Checked Received: (qmail 27197 invoked from network); 15 Sep 2011 10:09:20 -0000 Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115) by server-10.tower-174.messagelabs.com with RC4-SHA encrypted SMTP; 15 Sep 2011 10:09:20 -0000 X-IronPort-AV: E=Sophos;i="4.68,386,1312156800"; d="scan'208";a="7846870" Received: from lonpmailmx01.citrite.net ([10.30.203.162]) by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5; 15 Sep 2011 10:08:45 +0000 Received: from norwich.cam.xci-test.com (10.80.248.129) by smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id 8.3.137.0; Thu, 15 Sep 2011 11:08:45 +0100 Received: from mariner.cam.xci-test.com ([10.80.2.22] helo=mariner.uk.xensource.com ident=Debian-exim) by norwich.cam.xci-test.com with esmtp (Exim 4.72) (envelope-from ) id 1R48s9-0006vj-0P; Thu, 15 Sep 2011 10:08:45 +0000 Received: from iwj by mariner.uk.xensource.com with local (Exim 4.69) (envelope-from ) id 1R48s8-0000J4-Um; Thu, 15 Sep 2011 11:08:44 +0100 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Message-ID: <20081.52908.908581.962871@mariner.uk.xensource.com> Date: Thu, 15 Sep 2011 11:08:44 +0100 To: Olaf Hering Subject: Re: [Xen-devel] [PATCH] xenstored: allow guests to shutdown all of its watches using XS_RESET_WATCHES Newsgroups: chiark.mail.xen.devel In-Reply-To: <4b483f4fa715566847b5.1313397256@probook.site> References: <4b483f4fa715566847b5.1313397256@probook.site> X-Mailer: VM 8.0.9 under Emacs 21.4.1 (i486-pc-linux-gnu) From: Ian Jackson Cc: xen-devel@lists.xensource.com X-BeenThere: xen-devel@lists.xensource.com X-Mailman-Version: 2.1.5 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xensource.com Errors-To: xen-devel-bounces@lists.xensource.com Olaf Hering writes ("[Xen-devel] [PATCH] xenstored: allow guests to shutdown all of its watches using XS_RESET_WATCHES"): > xenstored: allow guests to shutdown all of its watches using XS_RESET_WATCHES > > During kexec all old watches have to be removed, otherwise the new > kernel will receive unexpected events. Allow a guest to reset itself and > cleanup all of its watches. > > Add a new XS_RESET_WATCHES command to do the reset on behalf of the guest. Applied, thanks, with the two changes we discussed. Thanks, Ian. _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel From xen-devel-bounces@lists.xensource.com Thu Sep 15 03:18:30 2011 Return-path: Envelope-to: www-data@lists.xensource.com Delivery-date: Thu, 15 Sep 2011 03:18:30 -0700 Received: from localhost ([127.0.0.1] helo=lists.colo.xensource.com) by lists.xensource.com with esmtp (Exim 4.43) id 1R491a-0008W1-0y; Thu, 15 Sep 2011 03:18:30 -0700 Received: from mail21.messagelabs.com ([85.158.143.35]) by lists.xensource.com with esmtp (Exim 4.43) id 1R490z-0008JH-Pj for xen-devel@lists.xensource.com; Thu, 15 Sep 2011 03:17:54 -0700 X-Env-Sender: George.Dunlap@eu.citrix.com X-Msg-Ref: server-5.tower-21.messagelabs.com!1316081837!48214649!1 X-Originating-IP: [62.200.22.115] X-StarScan-Version: 6.4.1; banners=-,-,- X-VirusChecked: Checked Received: (qmail 29773 invoked from network); 15 Sep 2011 10:17:17 -0000 Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115) by server-5.tower-21.messagelabs.com with RC4-SHA encrypted SMTP; 15 Sep 2011 10:17:17 -0000 X-IronPort-AV: E=Sophos;i="4.68,386,1312156800"; d="scan'208";a="7847222" Received: from lonpmailmx01.citrite.net ([10.30.203.162]) by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5; 15 Sep 2011 10:17:50 +0000 Received: from localhost6.localdomain6 (10.12.2.1) by LONPMAILMX01.citrite.net (10.30.203.162) with Microsoft SMTP Server id 8.3.137.0; Thu, 15 Sep 2011 11:17:49 +0100 Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Mercurial-Node: 7aa29ccb231f369adb7516ccf0a84bb3930130bc Message-ID: <7aa29ccb231f369adb75.1316081867@localhost6.localdomain6> User-Agent: Mercurial-patchbomb/1.6.3 Date: Thu, 15 Sep 2011 11:17:47 +0100 From: George Dunlap To: Cc: george.dunlap@eu.citrix.com Subject: [Xen-devel] [PATCH] xen: Move tsc reliability check until after CPUs have booted X-BeenThere: xen-devel@lists.xensource.com X-Mailman-Version: 2.1.5 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xensource.com Errors-To: xen-devel-bounces@lists.xensource.com AMD CPUs by default enable X86_FEATURE_TSC_RELIABLE, and depend upon a later check to disable this feature if TSC drift is detected. Unfortunately, this check is done in time.c:init_xen_time(), which is done before any secondary CPUs are brought up, and is thus guaranteed to succed. This patch moves the check into its own function, and calls it after cpus are brought up. Signed-off-by: George Dunlap diff -r 0312575dc35e -r 7aa29ccb231f xen/arch/x86/setup.c --- a/xen/arch/x86/setup.c Thu Sep 08 15:13:06 2011 +0100 +++ b/xen/arch/x86/setup.c Thu Sep 15 11:15:52 2011 +0100 @@ -1292,8 +1292,11 @@ printk("Brought up %ld CPUs\n", (long)num_online_cpus()); smp_cpus_done(); + verify_tsc_reliability(); + do_initcalls(); + if ( opt_watchdog ) watchdog_setup(); diff -r 0312575dc35e -r 7aa29ccb231f xen/arch/x86/time.c --- a/xen/arch/x86/time.c Thu Sep 08 15:13:06 2011 +0100 +++ b/xen/arch/x86/time.c Thu Sep 15 11:15:52 2011 +0100 @@ -1450,8 +1450,8 @@ disable_tsc_sync = 1; } -/* Late init function (after interrupts are enabled). */ -int __init init_xen_time(void) +/* Late init function, after all cpus have booted */ +void __init verify_tsc_reliability(void) { if ( boot_cpu_has(X86_FEATURE_TSC_RELIABLE) ) { @@ -1463,9 +1463,17 @@ */ tsc_check_reliability(); if ( tsc_max_warp ) + { + printk("%s: TSC warp detected, disabling TSC_RELIABLE\n", + __func__); setup_clear_cpu_cap(X86_FEATURE_TSC_RELIABLE); + } } +} +/* Late init function (after interrupts are enabled). */ +int __init init_xen_time(void) +{ tsc_check_writability(); /* If we have constant-rate TSCs then scale factor can be shared. */ diff -r 0312575dc35e -r 7aa29ccb231f xen/include/xen/time.h --- a/xen/include/xen/time.h Thu Sep 08 15:13:06 2011 +0100 +++ b/xen/include/xen/time.h Thu Sep 15 11:15:52 2011 +0100 @@ -11,6 +11,7 @@ #include #include +extern void verify_tsc_reliability(void); extern int init_xen_time(void); extern void cstate_restore_tsc(void); _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel From xen-devel-bounces@lists.xensource.com Thu Sep 15 03:21:56 2011 Return-path: Envelope-to: www-data@lists.xensource.com Delivery-date: Thu, 15 Sep 2011 03:21:56 -0700 Received: from localhost ([127.0.0.1] helo=lists.colo.xensource.com) by lists.xensource.com with esmtp (Exim 4.43) id 1R494u-0000WZ-P3; Thu, 15 Sep 2011 03:21:56 -0700 Received: from mail27.messagelabs.com ([193.109.254.147]) by lists.xensource.com with esmtp (Exim 4.43) id 1R4948-0000K3-QM for xen-devel@lists.xensource.com; Thu, 15 Sep 2011 03:21:09 -0700 X-Env-Sender: Ian.Jackson@eu.citrix.com X-Msg-Ref: server-15.tower-27.messagelabs.com!1316082057!48864585!1 X-Originating-IP: [62.200.22.115] X-StarScan-Version: 6.4.1; banners=-,-,- X-VirusChecked: Checked Received: (qmail 18027 invoked from network); 15 Sep 2011 10:20:57 -0000 Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115) by server-15.tower-27.messagelabs.com with RC4-SHA encrypted SMTP; 15 Sep 2011 10:20:57 -0000 X-IronPort-AV: E=Sophos;i="4.68,386,1312156800"; d="scan'208";a="7847386" Received: from lonpmailmx01.citrite.net ([10.30.203.162]) by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5; 15 Sep 2011 10:21:05 +0000 Received: from norwich.cam.xci-test.com (10.80.248.129) by smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id 8.3.137.0; Thu, 15 Sep 2011 11:21:05 +0100 Received: from mariner.cam.xci-test.com ([10.80.2.22] helo=mariner.uk.xensource.com ident=Debian-exim) by norwich.cam.xci-test.com with esmtp (Exim 4.72) (envelope-from ) id 1R4945-0006yy-9G; Thu, 15 Sep 2011 10:21:05 +0000 Received: from iwj by mariner.uk.xensource.com with local (Exim 4.69) (envelope-from ) id 1R4945-0000Jl-7q; Thu, 15 Sep 2011 11:21:05 +0100 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Message-ID: <20081.53649.196648.92906@mariner.uk.xensource.com> Date: Thu, 15 Sep 2011 11:21:05 +0100 To: Tim Deegan Subject: Re: [Xen-devel] [PATCH 0 of 2] v2: memshare/xenpaging/xen-access fixes for xen-unstable Newsgroups: chiark.mail.xen.devel In-Reply-To: <20110912135717.GC79171@ocelot.phlegethon.org> References: <20110912135717.GC79171@ocelot.phlegethon.org> X-Mailer: VM 8.0.9 under Emacs 21.4.1 (i486-pc-linux-gnu) From: Ian Jackson Cc: Olaf Hering , xen-devel@lists.xensource.com X-BeenThere: xen-devel@lists.xensource.com X-Mailman-Version: 2.1.5 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xensource.com Errors-To: xen-devel-bounces@lists.xensource.com Tim Deegan writes ("Re: [Xen-devel] [PATCH 0 of 2] v2: memshare/xenpaging/xen-access fixes for xen-unstable"): > At 11:57 +0200 on 08 Sep (1315483028), Olaf Hering wrote: > > The following two patches allow the parallel use of memsharing, > > xenpaging and xen-access by using an independent ring buffer for > > each feature. > > > > Please review. > > As I said, the Xen side looks fine but I'd like the opinion of the tools > maintainers about the API changes before I apply anything. Maybe this > is something that can happen at the hackathon. >From the tools point of view: Acked-by: Ian Jackson Tim, I wasn't sure if your message was an ack from the hypervisor point of view, so I haven't actually applied these patches. Ian. _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel From xen-devel-bounces@lists.xensource.com Thu Sep 15 03:36:54 2011 Return-path: Envelope-to: www-data@lists.xensource.com Delivery-date: Thu, 15 Sep 2011 03:36:54 -0700 Received: from localhost ([127.0.0.1] helo=lists.colo.xensource.com) by lists.xensource.com with esmtp (Exim 4.43) id 1R49JO-00018g-7m; Thu, 15 Sep 2011 03:36:54 -0700 Received: from mail27.messagelabs.com ([193.109.254.147]) by lists.xensource.com with esmtp (Exim 4.43) id 1R49Io-0000wS-3J for xen-devel@lists.xensource.com; Thu, 15 Sep 2011 03:36:18 -0700 X-Env-Sender: dunlapg@gmail.com X-Msg-Ref: server-3.tower-27.messagelabs.com!1316082952!39753630!1 X-Originating-IP: [74.125.82.171] X-StarScan-Version: 6.4.1; banners=-,-,- X-VirusChecked: Checked Received: (qmail 31495 invoked from network); 15 Sep 2011 10:35:52 -0000 Received: from mail-wy0-f171.google.com (HELO mail-wy0-f171.google.com) (74.125.82.171) by server-3.tower-27.messagelabs.com with RC4-SHA encrypted SMTP; 15 Sep 2011 10:35:52 -0000 Received: by wyh13 with SMTP id 13so2871019wyh.30 for ; Thu, 15 Sep 2011 03:36:14 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=M65yLkEt62h0irbIOwJr9+3n0LBxJog5rlARqHzcYdE=; b=QvHaUswSLEQuagQ3TsbylDfOC2v4OQkkCRBSmVyN/Y5JG1+pnSfEqS033/Q0sIyE0V fNN8u7K+mLxNIyRbkDZe3acdd5JiSNOlwvwE7z6CRC8RDLsDCrnWpKs4Sdjmlv1eQ+sG vhPx+cfHmaxoGbGE13J233x0ByB8XnLFEGYzw= MIME-Version: 1.0 Received: by 10.216.131.199 with SMTP id m49mr1169153wei.9.1316082973956; Thu, 15 Sep 2011 03:36:13 -0700 (PDT) Received: by 10.216.176.81 with HTTP; Thu, 15 Sep 2011 03:36:13 -0700 (PDT) In-Reply-To: <4E6F034B.5040102@bluewin.ch> References: <4E6F034B.5040102@bluewin.ch> Date: Thu, 15 Sep 2011 11:36:13 +0100 X-Google-Sender-Auth: M63f6bYVkwMLRAPdW2pN51Einlk Message-ID: Subject: Re: [Xen-devel] Xen 4 TSC problems From: George Dunlap To: Philippe Simonet Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: xen-devel@lists.xensource.com X-BeenThere: xen-devel@lists.xensource.com X-Mailman-Version: 2.1.5 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xensource.com Errors-To: xen-devel-bounces@lists.xensource.com On Tue, Sep 13, 2011 at 8:16 AM, Philippe Simonet wrote: > Hi Xen developers > > i just would like to inform you that I have exactly the same problem with > Debian squeeze and xen, with > 50 seconds time jump on my dom0 and domu. NTP is running on all dom0/domu= U, > clocksource is 'xen' > everywhere. > > some messages : > syslog : > Sep 11 13:56:50 dnsit22 kernel: [571603.359863] Clocksource tsc unstable > (delta =3D -2999662111513 ns) > > xm dmesg : > ... > (XEN) Platform timer is 14.318MHz HPET > ... > (XEN) Platform timer appears to have unexpectedly wrapped 10 or more time= s. > (XEN) TSC marked as reliable, warp =3D 0 (count=3D2) > ... I haven't been following this conversation, so I don't know if this is relevant, but I've just discovered this morning that the TSC warp check in Xen is done at the wrong time (before any secondary cpus are brought up), and thus always returns warp=3D0. I've submitted a patch to do the check after secondary CPUs are brought up; that should cause Xen to do periodic synchronization of TSCs when there is drift. -George > > I had some contact with Olivier Hanesse and it indicates that he doesn't > have any solution for this problem, > and all what was proposed in February didn't solved this problem. > > all suggestions are welcomed. > > Best regards > > Philippe > > > config : > -------------------------------------- > Linux dnsit22.swissptt.ch 2.6.32-5-xen-amd64 #1 SMP Tue Jun 14 12:46:30 U= TC > 2011 x86_64 GNU/Linux > -------------------------------------- > HP DL385 > -------------------------------------- > vendor_id =A0 =A0 =A0 : AuthenticAMD > cpu family =A0 =A0 =A0: 16 > model =A0 =A0 =A0 =A0 =A0 : 9 > model name =A0 =A0 =A0: AMD Opteron(tm) Processor 6174 > stepping =A0 =A0 =A0 =A0: 1 > cpu MHz =A0 =A0 =A0 =A0 : 3058776.574 > cache size =A0 =A0 =A0: 512 KB > fpu =A0 =A0 =A0 =A0 =A0 =A0 : yes > fpu_exception =A0 : yes > cpuid level =A0 =A0 : 5 > wp =A0 =A0 =A0 =A0 =A0 =A0 =A0: yes > flags =A0 =A0 =A0 =A0 =A0 : fpu de tsc msr pae mce cx8 apic mtrr mca cmov= pat clflush > mmx fxsr sse sse2 ht syscall nx mmxext fxsr_opt lm 3dnowext 3dnow > constant_tsc rep_good nonstop_tsc extd_apicid amd_dcm pni cx16 popcnt > hypervisor lahf_lm cmp_legacy extapic cr8_legacy abm sse4a misalignsse > 3dnowprefetch nodeid_msr > bogomips =A0 =A0 =A0 =A0: 4409.03 > TLB size =A0 =A0 =A0 =A0: 1024 4K pages > clflush size =A0 =A0: 64 > cache_alignment : 64 > address sizes =A0 : 48 bits physical, 48 bits virtual > power management: ts ttp tm stc 100mhzsteps hwpstate > -------------------------------------- > > -------------------------------------- > PCI : > 00:00.0 Host bridge: ATI Technologies Inc RD890 Northbridge only dual slo= t > (2x16) PCI-e GFX Hydra part (rev 02) > 00:04.0 PCI bridge: ATI Technologies Inc RD890 PCI to PCI bridge (PCI > express gpp port D) > 00:06.0 PCI bridge: ATI Technologies Inc RD890 PCI to PCI bridge (PCI > express gpp port F) > 00:0a.0 PCI bridge: ATI Technologies Inc RD890 PCI to PCI bridge (externa= l > gfx1 port A) > 00:0b.0 PCI bridge: ATI Technologies Inc RD890 PCI to PCI bridge (NB-SB > link) > 00:0d.0 PCI bridge: ATI Technologies Inc RD890 PCI to PCI bridge (externa= l > gfx1 port B) > 00:11.0 SATA controller: ATI Technologies Inc SB700/SB800 SATA Controller > [IDE mode] > 00:12.0 USB Controller: ATI Technologies Inc SB700/SB800 USB OHCI0 > Controller > 00:12.1 USB Controller: ATI Technologies Inc SB700 USB OHCI1 Controller > 00:12.2 USB Controller: ATI Technologies Inc SB700/SB800 USB EHCI Control= ler > 00:13.0 USB Controller: ATI Technologies Inc SB700/SB800 USB OHCI0 > Controller > 00:13.1 USB Controller: ATI Technologies Inc SB700 USB OHCI1 Controller > 00:13.2 USB Controller: ATI Technologies Inc SB700/SB800 USB EHCI Control= ler > 00:14.0 SMBus: ATI Technologies Inc SBx00 SMBus Controller (rev 3d) > 00:14.1 IDE interface: ATI Technologies Inc SB700/SB800 IDE Controller > 00:14.3 ISA bridge: ATI Technologies Inc SB700/SB800 LPC host controller > 00:14.4 PCI bridge: ATI Technologies Inc SBx00 PCI to PCI Bridge > 00:18.0 Host bridge: Advanced Micro Devices [AMD] Family 10h Processor > HyperTransport Configuration > 00:18.1 Host bridge: Advanced Micro Devices [AMD] Family 10h Processor > Address Map > 00:18.2 Host bridge: Advanced Micro Devices [AMD] Family 10h Processor DR= AM > Controller > 00:18.3 Host bridge: Advanced Micro Devices [AMD] Family 10h Processor > Miscellaneous Control > 00:18.4 Host bridge: Advanced Micro Devices [AMD] Family 10h Processor Li= nk > Control > 00:19.0 Host bridge: Advanced Micro Devices [AMD] Family 10h Processor > HyperTransport Configuration > 00:19.1 Host bridge: Advanced Micro Devices [AMD] Family 10h Processor > Address Map > 00:19.2 Host bridge: Advanced Micro Devices [AMD] Family 10h Processor DR= AM > Controller > 00:19.3 Host bridge: Advanced Micro Devices [AMD] Family 10h Processor > Miscellaneous Control > 00:19.4 Host bridge: Advanced Micro Devices [AMD] Family 10h Processor Li= nk > Control > 00:1a.0 Host bridge: Advanced Micro Devices [AMD] Family 10h Processor > HyperTransport Configuration > 00:1a.1 Host bridge: Advanced Micro Devices [AMD] Family 10h Processor > Address Map > 00:1a.2 Host bridge: Advanced Micro Devices [AMD] Family 10h Processor DR= AM > Controller > 00:1a.3 Host bridge: Advanced Micro Devices [AMD] Family 10h Processor > Miscellaneous Control > 00:1a.4 Host bridge: Advanced Micro Devices [AMD] Family 10h Processor Li= nk > Control > 00:1b.0 Host bridge: Advanced Micro Devices [AMD] Family 10h Processor > HyperTransport Configuration > 00:1b.1 Host bridge: Advanced Micro Devices [AMD] Family 10h Processor > Address Map > 00:1b.2 Host bridge: Advanced Micro Devices [AMD] Family 10h Processor DR= AM > Controller > 00:1b.3 Host bridge: Advanced Micro Devices [AMD] Family 10h Processor > Miscellaneous Control > 00:1b.4 Host bridge: Advanced Micro Devices [AMD] Family 10h Processor Li= nk > Control > 01:03.0 VGA compatible controller: ATI Technologies Inc ES1000 (rev 02) > 02:00.0 System peripheral: Hewlett-Packard Company iLO3 Slave > instrumentation & System support (rev 04) > 02:00.2 System peripheral: Hewlett-Packard Company iLO3 Management Proces= sor > Support and Messaging (rev 04) > 02:00.4 USB Controller: Hewlett-Packard Company Proliant iLO2/iLO3 virtua= l > USB controller (rev 01) > 03:00.0 RAID bus controller: Hewlett-Packard Company Smart Array G6 > controllers (rev 01) > 04:00.0 Ethernet controller: Broadcom Corporation NetXtreme II BCM5709 > Gigabit Ethernet (rev 20) > 04:00.1 Ethernet controller: Broadcom Corporation NetXtreme II BCM5709 > Gigabit Ethernet (rev 20) > 05:00.0 Ethernet controller: Broadcom Corporation NetXtreme II BCM5709 > Gigabit Ethernet (rev 20) > 05:00.1 Ethernet controller: Broadcom Corporation NetXtreme II BCM5709 > Gigabit Ethernet (rev 20) > 09:00.0 PCI bridge: PLX Technology, Inc. PEX 8616 16-lane, 4-Port PCI > Express Gen 2 (5.0 GT/s) Switch (rev bb) > 0a:04.0 PCI bridge: PLX Technology, Inc. PEX 8616 16-lane, 4-Port PCI > Express Gen 2 (5.0 GT/s) Switch (rev bb) > 0a:05.0 PCI bridge: PLX Technology, Inc. PEX 8616 16-lane, 4-Port PCI > Express Gen 2 (5.0 GT/s) Switch (rev bb) > 0a:06.0 PCI bridge: PLX Technology, Inc. PEX 8616 16-lane, 4-Port PCI > Express Gen 2 (5.0 GT/s) Switch (rev bb) > 0c:00.0 Ethernet controller: Intel Corporation 82580 Gigabit Network > Connection (rev 01) > 0c:00.1 Ethernet controller: Intel Corporation 82580 Gigabit Network > Connection (rev 01) > 0c:00.2 Ethernet controller: Intel Corporation 82580 Gigabit Network > Connection (rev 01) > 0c:00.3 Ethernet controller: Intel Corporation 82580 Gigabit Network > Connection (rev 01) > 0f:00.0 Ethernet controller: Intel Corporation 82580 Gigabit Network > Connection (rev 01) > 0f:00.1 Ethernet controller: Intel Corporation 82580 Gigabit Network > Connection (rev 01) > 0f:00.2 Ethernet controller: Intel Corporation 82580 Gigabit Network > Connection (rev 01) > 0f:00.3 Ethernet controller: Intel Corporation 82580 Gigabit Network > Connection (rev 01) > -------------------------------------- > > > > > On 8:59 PM, Olivier Hanesse wrote: >> >> Hello >> >> I've got an issue about time keeping with Xen 4.0 (Debian squeeze >> release). >> >> My problem is here (hopefully I amn't the only one, so there might be a >> bug >> somewhere) : http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=3D599161#5= 0 >> After some times, =A0I got this error : Clocksource tsc unstable (delta = =3D >> -2999660334211 ns). It has happened on several servers. >> >> Looking at the output of "xm debug-key s;" >> >> (XEN) TSC has constant rate, deep Cstates possible, so not reliable, >> warp=3D2850 (count=3D3) >> >> I am using a "Intel(R) Xeon(R) CPU L5420 =A0@ 2.50GHz", which has the >> "constant_tsc", but not the "nonstop_tsc" one. >> On other systems with a newer cpu with "nonstop_tsc", I don't have this >> issue (systems are running the same distros with same config). >> >> I tried to boot with "max_cstate=3D0", but nothing changed, my TSC isn't >> reliable and after some times, I will got the "50min" issue again. >> >> I don't understand how a system can do a jump of "50min" in the future. >> Why >> 50min ? it is not 40min, not 1 hour, it is always 50min. >> I don't know how to make my TSC "reliable" (I already disable everything >> about Powerstate in BIOS Settings). >> >> Any ideas ? >> >> Regards >> > > > _______________________________________________ > Xen-devel mailing list > Xen-devel@lists.xensource.com > http://lists.xensource.com/xen-devel > _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel From xen-devel-bounces@lists.xensource.com Thu Sep 15 04:06:32 2011 Return-path: Envelope-to: www-data@lists.xensource.com Delivery-date: Thu, 15 Sep 2011 04:06:32 -0700 Received: from localhost ([127.0.0.1] helo=lists.colo.xensource.com) by lists.xensource.com with esmtp (Exim 4.43) id 1R49m3-00024P-Q0; Thu, 15 Sep 2011 04:06:31 -0700 Received: from mail21.messagelabs.com ([85.158.143.35]) by lists.xensource.com with esmtp (Exim 4.43) id 1R49kb-0001rE-4z for xen-devel@lists.xensource.com; Thu, 15 Sep 2011 04:05:15 -0700 X-Env-Sender: Stefano.Stabellini@eu.citrix.com X-Msg-Ref: server-12.tower-21.messagelabs.com!1316084682!50036469!1 X-Originating-IP: [62.200.22.115] X-StarScan-Version: 6.4.1; banners=-,-,- X-VirusChecked: Checked Received: (qmail 21122 invoked from network); 15 Sep 2011 11:04:42 -0000 Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115) by server-12.tower-21.messagelabs.com with RC4-SHA encrypted SMTP; 15 Sep 2011 11:04:42 -0000 X-IronPort-AV: E=Sophos;i="4.68,386,1312156800"; d="scan'208";a="7849482" Received: from lonpmailmx01.citrite.net ([10.30.203.162]) by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5; 15 Sep 2011 11:04:36 +0000 Received: from kaball.uk.xensource.com (10.80.2.59) by LONPMAILMX01.citrite.net (10.30.203.162) with Microsoft SMTP Server id 8.3.137.0; Thu, 15 Sep 2011 12:04:36 +0100 Date: Thu, 15 Sep 2011 12:13:09 +0100 From: Stefano Stabellini X-X-Sender: sstabellini@kaball-desktop To: Jiageng Yu Subject: Re: [Xen-devel] Re: Linux Stubdom Problem In-Reply-To: Message-ID: References: User-Agent: Alpine 2.00 (DEB 1167 2008-08-23) MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Cc: Jeremy Fitzhardinge , "xen-devel@lists.xensource.com" , Keir Fraser , Rzeszutek Wilk , Stefano Stabellini , Tim Deegan , Ian Campbell , Konrad, Anthony PERARD , Samuel Thibault X-BeenThere: xen-devel@lists.xensource.com X-Mailman-Version: 2.1.5 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xensource.com Errors-To: xen-devel-bounces@lists.xensource.com On Wed, 14 Sep 2011, Jiageng Yu wrote: > Hi Stefano, > > I just have a prototype of vram mapping and test it now. The > implementation of linux-stubdom kernel part is as follows. > xen_remap_domain_mfn_range2 function maps foreign dom's physical > address into linux kernel space. It is similar to > xen_remap_domain_mfn_range. But xen_remap_domain_mfn_range is used to > map foreign pages into linux user space. > > But the page info seems wrong after executing xen_remap_domain_mfn_range2. > > struct page *page=pfn_to_page(vmalloc_to_pfn(info->fb)); > > The page->_count = 0xc2c2c2c2. It is very strange. > > Did I do the right thing? > use page_address instead of pfn_to_page to find the struct page > Greeting. > > Jiageng Yu. > > > diff --git a/arch/x86/xen/mmu.c b/arch/x86/xen/mmu.c > index 204e3ba..72a7808 100644 > --- a/arch/x86/xen/mmu.c > +++ b/arch/x86/xen/mmu.c > @@ -2693,6 +2693,73 @@ out: > } > EXPORT_SYMBOL_GPL(xen_remap_domain_mfn_range); > > +int xen_remap_domain_mfn_range2(unsigned long addr,unsigned long gpfn, > + int nr, unsigned domid) > +{ > + struct remap_data rmd; > + struct mmu_update mmu_update[REMAP_BATCH_SIZE]; > + int level,i,batch,nr_page = nr; > + unsigned long range; > + int err = 0; > + unsigned long vaddr,base_addr = addr; > + pte_t pte,*ptep; > + > + rmd.mfn = gpfn; > + rmd.prot = __pgprot(_PAGE_PRESENT | _PAGE_RW | _PAGE_ACCESSED | > _PAGE_IOMAP); > + > + while(nr_page) { > + batch = min(REMAP_BATCH_SIZE, nr); > + range = (unsigned long)batch << PAGE_SHIFT; > + > + rmd.mmu_update = mmu_update; > + > + for(i=0; i < batch; i++){ > + pte = pte_mkspecial(pfn_pte(rmd.mfn++, rmd.prot)); > + vaddr = base_addr + i*PAGE_SIZE; > + ptep = lookup_address(vaddr, &level); you need to check if ptep is valid here and the level is PG_LEVEL_4K > + rmd.mmu_update->ptr = arbitrary_virt_to_machine(ptep).maddr | > + MMU_NORMAL_PT_UPDATE; you can use pte_mfn(*ptep) instead of arbitrary_virt_to_machine > + rmd.mmu_update->val = pte_val_ma(pte); > + rmd.mmu_update++; > + } > + > + err = -EFAULT; > + if(HYPERVISOR_mmu_update(mmu_update, batch, NULL, domid) < 0) > + goto out; > + > + nr_page -= batch; > + base_addr += range; > + } > + > + err = 0; > + > + base_addr = addr; > + for(i=0; i < nr; i++){ > + vaddr = base_addr + i*PAGE_SIZE; > + set_phys_to_machine(vmalloc_to_pfn(vaddr), > + arbitrary_virt_to_machine(vaddr).maddr >> PAGE_SHIFT); > + } The second argument (mfn) to set_phys_to_machine is wrong: arbitrary_virt_to_machine ends up calling virt_to_machine if virt_addr_valid. You need to manually call pte_mfn: /* the ptep content has been updated by Xen so we can lookup the foreign * mfn from the pte now */ pte = lookup_address(vaddr, &level); BUG_ON(pte == NULL); offset = vaddr & ~PAGE_MASK; mfn = XMADDR(((phys_addr_t)pte_mfn(*pte) << PAGE_SHIFT) + offset); > + > +out: > + flush_tlb_all(); > + return err; > +} > +EXPORT_SYMBOL_GPL(xen_remap_domain_mfn_range2); the name should be changed to xen_remap_foreign_gpfn_range > #ifdef CONFIG_XEN_PVHVM > static void xen_hvm_exit_mmap(struct mm_struct *mm) > { > diff --git a/drivers/video/xen-fbfront.c b/drivers/video/xen-fbfront.c > index dc72563..82da2ee 100644 > --- a/drivers/video/xen-fbfront.c > +++ b/drivers/video/xen-fbfront.c > @@ -25,8 +25,12 @@ > #include > #include > #include > +#include > +#include > +#include > > #include > +#include > > #include > #include > @@ -34,6 +38,7 @@ > #include > #include > #include > +#include > > struct xenfb_info { > unsigned char *fb; > @@ -62,6 +67,12 @@ module_param_array(video, int, NULL, 0); > MODULE_PARM_DESC(video, > "Video memory size in MB, width, height in pixels (default 2,800,600)"); > > +static unsigned long foreign_vaddr = 0; > +module_param(foreign_vaddr, ulong, S_IRUGO); > + > +static unsigned long foreign_domid = 0; > +module_param(foreign_domid, ulong, S_IRUGO); > + > static void xenfb_make_preferred_console(void); > static int xenfb_remove(struct xenbus_device *); > static void xenfb_init_shared_page(struct xenfb_info *, struct fb_info *); > @@ -398,7 +408,17 @@ static int __devinit xenfb_probe(struct xenbus_device *dev, > if (info->fb == NULL) > goto error_nomem; > memset(info->fb, 0, fb_size); > - > + if((foreign_vaddr != 0) && (foreign_domid != 0)){ > + ret = xen_remap_domain_mfn_range2((unsigned long)(info->fb), > + foreign_vaddr >> PAGE_SHIFT, > + fb_size >> PAGE_SHIFT, foreign_domid); you should rename foreign_vaddr to foreign_gpfn and pass the gpfn value that is the ram_addr (page shifted) passed to xen_ram_alloc in qemu. > + if(ret < 0){ > + printk("Can not remap vram of hvm guest.\n"); > + goto error; > + } > + } > info->nr_pages = (fb_size + PAGE_SIZE - 1) >> PAGE_SHIFT; > > info->mfns = vmalloc(sizeof(unsigned long) * info->nr_pages); > diff --git a/include/xen/xen-ops.h b/include/xen/xen-ops.h > index 4349e89..1554531 100644 > --- a/include/xen/xen-ops.h > +++ b/include/xen/xen-ops.h > @@ -20,6 +20,10 @@ int xen_remap_domain_mfn_range(struct vm_area_struct *vma, > unsigned long mfn, int nr, > pgprot_t prot, unsigned domid); > > +int xen_remap_domain_mfn_range2(unsigned long addr,unsigned long mfn, > + int nr, unsigned domid); > extern unsigned long *xen_contiguous_bitmap; > int xen_create_contiguous_region(unsigned long vstart, unsigned int order, > unsigned int address_bits); > _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel From xen-devel-bounces@lists.xensource.com Thu Sep 15 05:04:37 2011 Return-path: Envelope-to: www-data@lists.xensource.com Delivery-date: Thu, 15 Sep 2011 05:04:37 -0700 Received: from localhost ([127.0.0.1] helo=lists.colo.xensource.com) by lists.xensource.com with esmtp (Exim 4.43) id 1R4AgH-00047L-IB; Thu, 15 Sep 2011 05:04:37 -0700 Received: from mail27.messagelabs.com ([193.109.254.147]) by lists.xensource.com with esmtp (Exim 4.43) id 1R4AdS-0003so-KP for xen-devel@lists.xensource.com; Thu, 15 Sep 2011 05:02:05 -0700 X-Env-Sender: Ian.Jackson@eu.citrix.com X-Msg-Ref: server-8.tower-27.messagelabs.com!1316088083!46711231!1 X-Originating-IP: [62.200.22.115] X-StarScan-Version: 6.4.1; banners=-,-,- X-VirusChecked: Checked Received: (qmail 23132 invoked from network); 15 Sep 2011 12:01:23 -0000 Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115) by server-8.tower-27.messagelabs.com with RC4-SHA encrypted SMTP; 15 Sep 2011 12:01:23 -0000 X-IronPort-AV: E=Sophos;i="4.68,386,1312156800"; d="scan'208";a="7852609" Received: from lonpmailmx01.citrite.net ([10.30.203.162]) by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5; 15 Sep 2011 12:01:37 +0000 Received: from woking.xci-test.com (10.80.248.135) by smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id 8.3.137.0; Thu, 15 Sep 2011 13:01:38 +0100 Received: from osstest by woking.xci-test.com with local (Exim 4.69) (envelope-from ) id 1R4AdN-0004aD-Mo; Thu, 15 Sep 2011 13:01:37 +0100 To: Message-ID: From: xen.org Date: Thu, 15 Sep 2011 13:01:37 +0100 MIME-Version: 1.0 Content-Type: text/plain Cc: ian.jackson@eu.citrix.com Subject: [Xen-devel] [xen-unstable test] 8942: tolerable FAIL - PUSHED X-BeenThere: xen-devel@lists.xensource.com X-Mailman-Version: 2.1.5 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xensource.com Errors-To: xen-devel-bounces@lists.xensource.com flight 8942 xen-unstable real [real] http://www.chiark.greenend.org.uk/~xensrcts/logs/8942/ Failures :-/ but no regressions. Tests which did not succeed, but are not blocking, including regressions (tests previously passed) regarded as allowable: test-amd64-amd64-xl-pcipt-intel 1 xen-build-check(1) blocked n/a test-amd64-i386-rhel6hvm-intel 1 xen-build-check(1) blocked n/a test-i386-i386-pv 1 xen-build-check(1) blocked n/a test-amd64-i386-pv 1 xen-build-check(1) blocked n/a build-amd64-pvops 4 kernel-build fail like 8940 test-amd64-amd64-pv 1 xen-build-check(1) blocked n/a test-i386-i386-xl 1 xen-build-check(1) blocked n/a test-amd64-i386-xl-multivcpu 1 xen-build-check(1) blocked n/a test-amd64-i386-xl 1 xen-build-check(1) blocked n/a test-amd64-i386-xl-credit2 1 xen-build-check(1) blocked n/a test-amd64-i386-rhel6hvm-amd 1 xen-build-check(1) blocked n/a test-amd64-amd64-pair 1 xen-build-check(1) blocked n/a test-amd64-i386-pair 1 xen-build-check(1) blocked n/a test-i386-i386-pair 1 xen-build-check(1) blocked n/a build-i386-pvops 4 kernel-build fail like 8940 test-amd64-amd64-xl-sedf 1 xen-build-check(1) blocked n/a test-amd64-i386-win-vcpus1 1 xen-build-check(1) blocked n/a test-amd64-i386-xl-win-vcpus1 1 xen-build-check(1) blocked n/a test-amd64-amd64-win 1 xen-build-check(1) blocked n/a test-amd64-i386-win 1 xen-build-check(1) blocked n/a test-amd64-amd64-xl-win 1 xen-build-check(1) blocked n/a test-amd64-amd64-xl 1 xen-build-check(1) blocked n/a test-i386-i386-xl-win 1 xen-build-check(1) blocked n/a test-i386-i386-win 1 xen-build-check(1) blocked n/a version targeted for testing: xen 42a45baf037d baseline version: xen e90438f6e6d1 ------------------------------------------------------------ People who touched revisions under test: Ian Jackson Olaf Hering ------------------------------------------------------------ jobs: build-amd64 pass build-i386 pass build-amd64-oldkern pass build-i386-oldkern pass build-amd64-pvops fail build-i386-pvops fail test-amd64-amd64-xl blocked test-amd64-i386-xl blocked test-i386-i386-xl blocked test-amd64-i386-rhel6hvm-amd blocked test-amd64-i386-xl-credit2 blocked test-amd64-amd64-xl-pcipt-intel blocked test-amd64-i386-rhel6hvm-intel blocked test-amd64-i386-xl-multivcpu blocked test-amd64-amd64-pair blocked test-amd64-i386-pair blocked test-i386-i386-pair blocked test-amd64-amd64-pv blocked test-amd64-i386-pv blocked test-i386-i386-pv blocked test-amd64-amd64-xl-sedf blocked test-amd64-i386-win-vcpus1 blocked test-amd64-i386-xl-win-vcpus1 blocked test-amd64-amd64-win blocked test-amd64-i386-win blocked test-i386-i386-win blocked test-amd64-amd64-xl-win blocked test-i386-i386-xl-win blocked ------------------------------------------------------------ sg-report-flight on woking.cam.xci-test.com logs: /home/xc_osstest/logs images: /home/xc_osstest/images Logs, config files, etc. are available at http://www.chiark.greenend.org.uk/~xensrcts/logs Test harness code can be found at http://xenbits.xensource.com/gitweb?p=osstest.git;a=summary Pushing revision : + branch=xen-unstable + revision=42a45baf037d + . cri-lock-repos ++ . cri-common +++ umask 002 +++ getconfig Repos +++ perl -e ' use Osstest; readconfigonly(); print $c{Repos} or die $!; ' ++ repos=/export/home/osstest/repos ++ repos_lock=/export/home/osstest/repos/lock ++ '[' x '!=' x/export/home/osstest/repos/lock ']' ++ OSSTEST_REPOS_LOCK_LOCKED=/export/home/osstest/repos/lock ++ exec with-lock-ex -w /export/home/osstest/repos/lock ./ap-push xen-unstable 42a45baf037d + branch=xen-unstable + revision=42a45baf037d + . cri-lock-repos ++ . cri-common +++ umask 002 +++ getconfig Repos +++ perl -e ' use Osstest; readconfigonly(); print $c{Repos} or die $!; ' ++ repos=/export/home/osstest/repos ++ repos_lock=/export/home/osstest/repos/lock ++ '[' x/export/home/osstest/repos/lock '!=' x/export/home/osstest/repos/lock ']' + : xen@xenbits.xensource.com + : xen@xenbits.xensource.com:git/linux-pvops + : master + : tested/2.6.39.x + case "$branch" in + cd /export/home/osstest/repos/xen-unstable.hg + hg push -r 42a45baf037d ssh://xen@xenbits.xensource.com/HG/xen-unstable.hg pushing to ssh://xen@xenbits.xensource.com/HG/xen-unstable.hg searching for changes remote: adding changesets remote: adding manifests remote: adding file changes remote: added 1 changesets with 5 changes to 5 files _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel From xen-devel-bounces@lists.xensource.com Thu Sep 15 05:28:26 2011 Return-path: Envelope-to: www-data@lists.xensource.com Delivery-date: Thu, 15 Sep 2011 05:28:26 -0700 Received: from localhost ([127.0.0.1] helo=lists.colo.xensource.com) by lists.xensource.com with esmtp (Exim 4.43) id 1R4B3K-0006Fw-LR; Thu, 15 Sep 2011 05:28:26 -0700 Received: from mail174.messagelabs.com ([85.158.138.51]) by lists.xensource.com with esmtp (Exim 4.43) id 1R4B1R-0005lk-Fp for xen-devel@lists.xensource.com; Thu, 15 Sep 2011 05:26:30 -0700 X-Env-Sender: olaf@aepfle.de X-Msg-Ref: server-10.tower-174.messagelabs.com!1316089580!31519778!1 X-Originating-IP: [81.169.146.161] X-StarScan-Version: 6.4.1; banners=-,-,- X-VirusChecked: Checked Received: (qmail 8976 invoked from network); 15 Sep 2011 12:26:26 -0000 Received: from mo-p00-ob.rzone.de (HELO mo-p00-ob.rzone.de) (81.169.146.161) by server-10.tower-174.messagelabs.com with EDH-RSA-DES-CBC3-SHA encrypted SMTP; 15 Sep 2011 12:26:26 -0000 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; t=1316089580; l=3867; s=domk; d=aepfle.de; h=To:From:Date:Subject:Content-Transfer-Encoding:MIME-Version: Content-Type:X-RZG-CLASS-ID:X-RZG-AUTH; bh=81DSKnSwEqAZoQ/znY/v3XLop3E=; b=bfhiY/JjIZ+tEx/RRptrztVMc5B6dsPWZZDZbo09loUAL4w8aj2/0zOYnBC3ITMq9A4 Q2+qn6N/qMtKZDGHRryf2xYXBXJ3cdR1osXz5jvQIFpPyE0rO+7h3nu7KopQ60gnYvJrR 8XdkyK8yNzuZwHgDMISYTlmLLzN/gO6uiWY= X-RZG-AUTH: :P2EQZWCpfu+qG7CngxMFH1J+zrwiavkK6tmQaLfmxtMZ80VwmRNV7HU= X-RZG-CLASS-ID: mo00 Received: from probook.site (ip-80-226-24-6.vodafone-net.de [80.226.24.6]) by smtp.strato.de (klopstock mo15) (RZmta 26.7) with (EDH-RSA-DES-CBC3-SHA encrypted) ESMTPA id U0277an8FB9HlT for ; Thu, 15 Sep 2011 14:26:13 +0200 (MEST) Received: from probook.site (localhost [IPv6:::1]) by probook.site (Postfix) with ESMTP id 055E618B66 for ; Thu, 15 Sep 2011 14:26:09 +0200 (CEST) Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Mercurial-Node: 13b4be345ebac016abe26386417824a0c47d762d Message-Id: <13b4be345ebac016abe2.1316089567@probook.site> User-Agent: Mercurial-patchbomb/1.7.5 Date: Thu, 15 Sep 2011 14:26:07 +0200 From: Olaf Hering To: xen-devel@lists.xensource.com Subject: [Xen-devel] [PATCH] xenpaging: track number of paged pages in struct domain X-BeenThere: xen-devel@lists.xensource.com X-Mailman-Version: 2.1.5 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xensource.com Errors-To: xen-devel-bounces@lists.xensource.com # HG changeset patch # User Olaf Hering # Date 1316089500 -7200 # Node ID 13b4be345ebac016abe26386417824a0c47d762d # Parent e90438f6e6d1585a71b18784a99c162b5d95f390 xenpaging: track number of paged pages in struct domain The toolstack should know how many pages are paged-out at a given point in time so it could make smarter decisions about how many pages should be paged or ballooned. Add a new member to xen_domctl_getdomaininfo and bump interface version. Use the new member in xc_dominfo_t. The SONAME of libxc should be changed if this patch gets applied. Signed-off-by: Olaf Hering diff -r e90438f6e6d1 -r 13b4be345eba tools/libxc/xc_domain.c --- a/tools/libxc/xc_domain.c +++ b/tools/libxc/xc_domain.c @@ -235,6 +235,7 @@ int xc_domain_getinfo(xc_interface *xch, info->ssidref = domctl.u.getdomaininfo.ssidref; info->nr_pages = domctl.u.getdomaininfo.tot_pages; info->nr_shared_pages = domctl.u.getdomaininfo.shr_pages; + info->nr_paged_pages = domctl.u.getdomaininfo.paged_pages; info->max_memkb = domctl.u.getdomaininfo.max_pages << (PAGE_SHIFT-10); info->shared_info_frame = domctl.u.getdomaininfo.shared_info_frame; info->cpu_time = domctl.u.getdomaininfo.cpu_time; diff -r e90438f6e6d1 -r 13b4be345eba tools/libxc/xenctrl.h --- a/tools/libxc/xenctrl.h +++ b/tools/libxc/xenctrl.h @@ -351,6 +351,7 @@ typedef struct xc_dominfo { unsigned int shutdown_reason; /* only meaningful if shutdown==1 */ unsigned long nr_pages; /* current number, not maximum */ unsigned long nr_shared_pages; + unsigned long nr_paged_pages; unsigned long shared_info_frame; uint64_t cpu_time; unsigned long max_memkb; diff -r e90438f6e6d1 -r 13b4be345eba xen/arch/x86/mm/p2m.c --- a/xen/arch/x86/mm/p2m.c +++ b/xen/arch/x86/mm/p2m.c @@ -746,6 +746,9 @@ int p2m_mem_paging_evict(struct domain * /* Put the page back so it gets freed */ put_page(page); + /* Track number of paged gfns */ + atomic_inc(&d->paged_pages); + return 0; } @@ -831,6 +834,8 @@ int p2m_mem_paging_prep(struct domain *d audit_p2m(p2m, 1); p2m_unlock(p2m); + atomic_dec(&d->paged_pages); + return 0; } diff -r e90438f6e6d1 -r 13b4be345eba xen/common/domctl.c --- a/xen/common/domctl.c +++ b/xen/common/domctl.c @@ -137,6 +137,7 @@ void getdomaininfo(struct domain *d, str info->tot_pages = d->tot_pages; info->max_pages = d->max_pages; info->shr_pages = atomic_read(&d->shr_pages); + info->paged_pages = atomic_read(&d->paged_pages); info->shared_info_frame = mfn_to_gmfn(d, __pa(d->shared_info)>>PAGE_SHIFT); BUG_ON(SHARED_M2P(info->shared_info_frame)); diff -r e90438f6e6d1 -r 13b4be345eba xen/include/public/domctl.h --- a/xen/include/public/domctl.h +++ b/xen/include/public/domctl.h @@ -35,7 +35,7 @@ #include "xen.h" #include "grant_table.h" -#define XEN_DOMCTL_INTERFACE_VERSION 0x00000007 +#define XEN_DOMCTL_INTERFACE_VERSION 0x00000008 /* * NB. xen_domctl.domain is an IN/OUT parameter for this operation. @@ -95,6 +95,7 @@ struct xen_domctl_getdomaininfo { uint64_aligned_t tot_pages; uint64_aligned_t max_pages; uint64_aligned_t shr_pages; + uint64_aligned_t paged_pages; uint64_aligned_t shared_info_frame; /* GMFN of shared_info struct */ uint64_aligned_t cpu_time; uint32_t nr_online_vcpus; /* Number of VCPUs currently online. */ diff -r e90438f6e6d1 -r 13b4be345eba xen/include/xen/sched.h --- a/xen/include/xen/sched.h +++ b/xen/include/xen/sched.h @@ -208,6 +208,7 @@ struct domain unsigned int tot_pages; /* number of pages currently possesed */ unsigned int max_pages; /* maximum value for tot_pages */ atomic_t shr_pages; /* number of shared pages */ + atomic_t paged_pages; /* number of paged-out pages */ unsigned int xenheap_pages; /* # pages allocated from Xen heap */ unsigned int max_vcpus; _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel From xen-devel-bounces@lists.xensource.com Thu Sep 15 05:30:33 2011 Return-path: Envelope-to: www-data@lists.xensource.com Delivery-date: Thu, 15 Sep 2011 05:30:33 -0700 Received: from localhost ([127.0.0.1] helo=lists.colo.xensource.com) by lists.xensource.com with esmtp (Exim 4.43) id 1R4B5M-0006eY-Ub; Thu, 15 Sep 2011 05:30:32 -0700 Received: from mail216.messagelabs.com ([85.158.143.99]) by lists.xensource.com with esmtp (Exim 4.43) id 1R4B4o-0006Rh-1M for xen-devel@lists.xensource.com; Thu, 15 Sep 2011 05:29:58 -0700 X-Env-Sender: david.vrabel@citrix.com X-Msg-Ref: server-11.tower-216.messagelabs.com!1316089793!10798669!1 X-Originating-IP: [66.165.176.89] X-StarScan-Version: 6.4.1; banners=-,-,- X-VirusChecked: Checked Received: (qmail 21441 invoked from network); 15 Sep 2011 12:29:54 -0000 Received: from smtp.citrix.com (HELO SMTP.CITRIX.COM) (66.165.176.89) by server-11.tower-216.messagelabs.com with RC4-SHA encrypted SMTP; 15 Sep 2011 12:29:54 -0000 X-IronPort-AV: E=Sophos;i="4.68,387,1312171200"; d="scan'208";a="17174140" Received: from ftlpmailmx02.citrite.net ([10.13.107.66]) by FTLPIPO01.CITRIX.COM with ESMTP/TLS/RC4-MD5; 15 Sep 2011 08:29:53 -0400 Received: from smtp01.ad.xensource.com (10.219.128.104) by smtprelay.citrix.com (10.13.107.66) with Microsoft SMTP Server id 8.3.137.0; Thu, 15 Sep 2011 08:29:52 -0400 Received: from minsc.uk.xensource.com ([10.31.1.114]) by smtp01.ad.xensource.com (8.13.1/8.13.1) with ESMTP id p8FCToi9027794; Thu, 15 Sep 2011 05:29:51 -0700 From: David Vrabel To: xen-devel@lists.xensource.com Date: Thu, 15 Sep 2011 13:29:21 +0100 Message-ID: <1316089768-22461-1-git-send-email-david.vrabel@citrix.com> X-Mailer: git-send-email 1.7.2.5 MIME-Version: 1.0 Content-Type: text/plain Cc: Konrad Rzeszutek Wilk Subject: [Xen-devel] xen: memory initialization/balloon fixes (#3) X-BeenThere: xen-devel@lists.xensource.com X-Mailman-Version: 2.1.5 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xensource.com Errors-To: xen-devel-bounces@lists.xensource.com This set of patches fixes some bugs in the memory initialization under Xen and in Xen's memory balloon driver. They can make 100s of MB of additional RAM available (depending on the system/configuration). Patch 1 is already applied. Patch 2 fixes a bug in patch 1 and should be queued for 3.1 (and along with patch 1 considered for 3.0 stable). Patch 3 is a bug fix and should be queued for 3.1 and possibly queued for the 3.0 stable tree. Patches 5 & 6 increase the amount of low memory in 32 bit domains started with < 1 GiB of RAM. Please queue for 3.2 Patch 7 releases all pages in the initial allocation with PFNs that lie within a 1-1 mapping. This seems correct to me as I think that once the 1-1 mapping is set the MFN of the original page is lost so it's no longer accessible by the kernel (and it cannot be used by another domain Changes since #2: - New patch: xen: avoid adding non-existant memory if the reservation is unlimited - Avoid using a hypercall to get the current number of pages in the ballon driver. Apparently the hypercall won't return the right value if paging is used. - Addresses Konrad's review comments. David _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel From xen-devel-bounces@lists.xensource.com Thu Sep 15 05:31:31 2011 Return-path: Envelope-to: www-data@lists.xensource.com Delivery-date: Thu, 15 Sep 2011 05:31:31 -0700 Received: from localhost ([127.0.0.1] helo=lists.colo.xensource.com) by lists.xensource.com with esmtp (Exim 4.43) id 1R4B6I-00071a-3k; Thu, 15 Sep 2011 05:31:30 -0700 Received: from mail216.messagelabs.com ([85.158.143.99]) by lists.xensource.com with esmtp (Exim 4.43) id 1R4B4o-0006Ri-Kf for xen-devel@lists.xensource.com; Thu, 15 Sep 2011 05:29:58 -0700 X-Env-Sender: david.vrabel@citrix.com X-Msg-Ref: server-11.tower-216.messagelabs.com!1316089793!10798669!2 X-Originating-IP: [66.165.176.89] X-StarScan-Version: 6.4.1; banners=-,-,- X-VirusChecked: Checked Received: (qmail 21465 invoked from network); 15 Sep 2011 12:29:55 -0000 Received: from smtp.citrix.com (HELO SMTP.CITRIX.COM) (66.165.176.89) by server-11.tower-216.messagelabs.com with RC4-SHA encrypted SMTP; 15 Sep 2011 12:29:55 -0000 X-IronPort-AV: E=Sophos;i="4.68,387,1312171200"; d="scan'208";a="17174212" Received: from ftlpmailmx02.citrite.net ([10.13.107.66]) by FTLPIPO01.CITRIX.COM with ESMTP/TLS/RC4-MD5; 15 Sep 2011 08:29:54 -0400 Received: from smtp01.ad.xensource.com (10.219.128.104) by smtprelay.citrix.com (10.13.107.66) with Microsoft SMTP Server id 8.3.137.0; Thu, 15 Sep 2011 08:29:53 -0400 Received: from minsc.uk.xensource.com ([10.31.1.114]) by smtp01.ad.xensource.com (8.13.1/8.13.1) with ESMTP id p8FCToiA027794; Thu, 15 Sep 2011 05:29:52 -0700 From: David Vrabel To: xen-devel@lists.xensource.com Date: Thu, 15 Sep 2011 13:29:22 +0100 Message-ID: <1316089768-22461-2-git-send-email-david.vrabel@citrix.com> X-Mailer: git-send-email 1.7.2.5 In-Reply-To: <1316089768-22461-1-git-send-email-david.vrabel@citrix.com> References: <1316089768-22461-1-git-send-email-david.vrabel@citrix.com> MIME-Version: 1.0 Content-Type: text/plain Cc: David Vrabel , Konrad Rzeszutek Wilk Subject: [Xen-devel] [PATCH 1/7] xen: use maximum reservation to limit amount of usable RAM X-BeenThere: xen-devel@lists.xensource.com X-Mailman-Version: 2.1.5 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xensource.com Errors-To: xen-devel-bounces@lists.xensource.com From: David Vrabel Use the domain's maximum reservation to limit the amount of extra RAM for the memory balloon. This reduces the size of the pages tables and the amount of reserved low memory (which defaults to about 1/32 of the total RAM). On a system with 8 GiB of RAM with the domain limited to 1 GiB the kernel reports: Before: Memory: 627792k/4472000k available After: Memory: 549740k/11132224k available A increase of about 76 MiB (~1.5% of the unused 7 GiB). The reserved low memory is also reduced from 253 MiB to 32 MiB. The total additional usable RAM is 329 MiB. For dom0, this requires at patch to Xen ('x86: use 'dom0_mem' to limit the number of pages for dom0')[1]. [1] http://lists.xensource.com/archives/html/xen-devel/2011-08/msg00567.html Signed-off-by: David Vrabel --- arch/x86/xen/setup.c | 19 +++++++++++++++++++ 1 files changed, 19 insertions(+), 0 deletions(-) diff --git a/arch/x86/xen/setup.c b/arch/x86/xen/setup.c index df118a8..c3b8d44 100644 --- a/arch/x86/xen/setup.c +++ b/arch/x86/xen/setup.c @@ -184,6 +184,19 @@ static unsigned long __init xen_set_identity(const struct e820entry *list, PFN_UP(start_pci), PFN_DOWN(last)); return identity; } + +static unsigned long __init xen_get_max_pages(void) +{ + unsigned long max_pages = MAX_DOMAIN_PAGES; + domid_t domid = DOMID_SELF; + int ret; + + ret = HYPERVISOR_memory_op(XENMEM_maximum_reservation, &domid); + if (ret > 0) + max_pages = ret; + return min(max_pages, MAX_DOMAIN_PAGES); +} + /** * machine_specific_memory_setup - Hook for machine specific memory setup. **/ @@ -292,6 +305,12 @@ char * __init xen_memory_setup(void) sanitize_e820_map(e820.map, ARRAY_SIZE(e820.map), &e820.nr_map); + extra_limit = xen_get_max_pages(); + if (extra_limit >= max_pfn) + extra_pages = extra_limit - max_pfn; + else + extra_pages = 0; + extra_pages += xen_return_unused_memory(xen_start_info->nr_pages, &e820); /* -- 1.7.2.5 _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel From xen-devel-bounces@lists.xensource.com Thu Sep 15 05:32:22 2011 Return-path: Envelope-to: www-data@lists.xensource.com Delivery-date: Thu, 15 Sep 2011 05:32:22 -0700 Received: from localhost ([127.0.0.1] helo=lists.colo.xensource.com) by lists.xensource.com with esmtp (Exim 4.43) id 1R4B77-0007Pb-RP; Thu, 15 Sep 2011 05:32:21 -0700 Received: from mail182.messagelabs.com ([85.158.139.83]) by lists.xensource.com with esmtp (Exim 4.43) id 1R4B4q-0006Rm-LF for xen-devel@lists.xensource.com; Thu, 15 Sep 2011 05:30:01 -0700 X-Env-Sender: david.vrabel@citrix.com X-Msg-Ref: server-9.tower-182.messagelabs.com!1316089796!18436031!1 X-Originating-IP: [66.165.176.63] X-StarScan-Version: 6.4.1; banners=-,-,- X-VirusChecked: Checked Received: (qmail 19635 invoked from network); 15 Sep 2011 12:29:57 -0000 Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63) by server-9.tower-182.messagelabs.com with RC4-SHA encrypted SMTP; 15 Sep 2011 12:29:57 -0000 X-IronPort-AV: E=Sophos;i="4.68,387,1312171200"; d="scan'208";a="163255885" Received: from ftlpmailmx02.citrite.net ([10.13.107.66]) by FTLPIPO02.CITRIX.COM with ESMTP/TLS/RC4-MD5; 15 Sep 2011 08:29:55 -0400 Received: from smtp01.ad.xensource.com (10.219.128.104) by smtprelay.citrix.com (10.13.107.66) with Microsoft SMTP Server id 8.3.137.0; Thu, 15 Sep 2011 08:29:54 -0400 Received: from minsc.uk.xensource.com ([10.31.1.114]) by smtp01.ad.xensource.com (8.13.1/8.13.1) with ESMTP id p8FCToiB027794; Thu, 15 Sep 2011 05:29:53 -0700 From: David Vrabel To: xen-devel@lists.xensource.com Date: Thu, 15 Sep 2011 13:29:23 +0100 Message-ID: <1316089768-22461-3-git-send-email-david.vrabel@citrix.com> X-Mailer: git-send-email 1.7.2.5 In-Reply-To: <1316089768-22461-1-git-send-email-david.vrabel@citrix.com> References: <1316089768-22461-1-git-send-email-david.vrabel@citrix.com> MIME-Version: 1.0 Content-Type: text/plain Cc: David Vrabel , Konrad Rzeszutek Wilk Subject: [Xen-devel] [PATCH 2/7] xen: avoid adding non-existant memory if the reservation is unlimited X-BeenThere: xen-devel@lists.xensource.com X-Mailman-Version: 2.1.5 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xensource.com Errors-To: xen-devel-bounces@lists.xensource.com From: David Vrabel If the domain's reservation is unlimited, too many pages are added to the balloon memory region. Correctly check the limit so the number of extra pages is not increased in this case. Signed-off-by: David Vrabel --- arch/x86/xen/setup.c | 10 ++++++---- 1 files changed, 6 insertions(+), 4 deletions(-) diff --git a/arch/x86/xen/setup.c b/arch/x86/xen/setup.c index c3b8d44..46d6d21 100644 --- a/arch/x86/xen/setup.c +++ b/arch/x86/xen/setup.c @@ -306,10 +306,12 @@ char * __init xen_memory_setup(void) sanitize_e820_map(e820.map, ARRAY_SIZE(e820.map), &e820.nr_map); extra_limit = xen_get_max_pages(); - if (extra_limit >= max_pfn) - extra_pages = extra_limit - max_pfn; - else - extra_pages = 0; + if (max_pfn + extra_pages > extra_limit) { + if (extra_limit > max_pfn) + extra_pages = extra_limit - max_pfn; + else + extra_pages = 0; + } extra_pages += xen_return_unused_memory(xen_start_info->nr_pages, &e820); -- 1.7.2.5 _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel From xen-devel-bounces@lists.xensource.com Thu Sep 15 05:33:11 2011 Return-path: Envelope-to: www-data@lists.xensource.com Delivery-date: Thu, 15 Sep 2011 05:33:11 -0700 Received: from localhost ([127.0.0.1] helo=lists.colo.xensource.com) by lists.xensource.com with esmtp (Exim 4.43) id 1R4B7v-0007mU-6X; Thu, 15 Sep 2011 05:33:11 -0700 Received: from mail216.messagelabs.com ([85.158.143.99]) by lists.xensource.com with esmtp (Exim 4.43) id 1R4B4r-0006Rs-49 for xen-devel@lists.xensource.com; Thu, 15 Sep 2011 05:30:01 -0700 X-Env-Sender: david.vrabel@citrix.com X-Msg-Ref: server-11.tower-216.messagelabs.com!1316089793!10798669!3 X-Originating-IP: [66.165.176.89] X-StarScan-Version: 6.4.1; banners=-,-,- X-VirusChecked: Checked Received: (qmail 21589 invoked from network); 15 Sep 2011 12:29:57 -0000 Received: from smtp.citrix.com (HELO SMTP.CITRIX.COM) (66.165.176.89) by server-11.tower-216.messagelabs.com with RC4-SHA encrypted SMTP; 15 Sep 2011 12:29:57 -0000 X-IronPort-AV: E=Sophos;i="4.68,387,1312171200"; d="scan'208";a="17174325" Received: from ftlpmailmx02.citrite.net ([10.13.107.66]) by FTLPIPO01.CITRIX.COM with ESMTP/TLS/RC4-MD5; 15 Sep 2011 08:29:57 -0400 Received: from smtp01.ad.xensource.com (10.219.128.104) by smtprelay.citrix.com (10.13.107.66) with Microsoft SMTP Server id 8.3.137.0; Thu, 15 Sep 2011 08:29:57 -0400 Received: from minsc.uk.xensource.com ([10.31.1.114]) by smtp01.ad.xensource.com (8.13.1/8.13.1) with ESMTP id p8FCToiD027794; Thu, 15 Sep 2011 05:29:56 -0700 From: David Vrabel To: xen-devel@lists.xensource.com Date: Thu, 15 Sep 2011 13:29:25 +0100 Message-ID: <1316089768-22461-5-git-send-email-david.vrabel@citrix.com> X-Mailer: git-send-email 1.7.2.5 In-Reply-To: <1316089768-22461-1-git-send-email-david.vrabel@citrix.com> References: <1316089768-22461-1-git-send-email-david.vrabel@citrix.com> MIME-Version: 1.0 Content-Type: text/plain Cc: David Vrabel , Konrad Rzeszutek Wilk Subject: [Xen-devel] [PATCH 4/7] xen/balloon: simplify test for the end of usable RAM X-BeenThere: xen-devel@lists.xensource.com X-Mailman-Version: 2.1.5 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xensource.com Errors-To: xen-devel-bounces@lists.xensource.com From: David Vrabel When initializing the balloon only max_pfn needs to be checked (max_pfn will always be <= e820_end_of_ram_pfn()) and improve the confusing comment. Signed-off-by: David Vrabel --- drivers/xen/balloon.c | 18 +++++++++--------- 1 files changed, 9 insertions(+), 9 deletions(-) diff --git a/drivers/xen/balloon.c b/drivers/xen/balloon.c index 4f59fb3..9efb993 100644 --- a/drivers/xen/balloon.c +++ b/drivers/xen/balloon.c @@ -586,16 +586,16 @@ static int __init balloon_init(void) #endif /* - * Initialise the balloon with excess memory space. We need - * to make sure we don't add memory which doesn't exist or - * logically exist. The E820 map can be trimmed to be smaller - * than the amount of physical memory due to the mem= command - * line parameter. And if this is a 32-bit non-HIGHMEM kernel - * on a system with memory which requires highmem to access, - * don't try to use it. + * Initialize the balloon with pages from the extra memory + * region (see arch/x86/xen/setup.c). + * + * If the amount of usable memory has been limited (e.g., with + * the 'mem' command line parameter), don't add pages beyond + * this limit. */ - extra_pfn_end = min(min(max_pfn, e820_end_of_ram_pfn()), - (unsigned long)PFN_DOWN(xen_extra_mem_start + xen_extra_mem_size)); + extra_pfn_end = min(max_pfn, + (unsigned long)PFN_DOWN(xen_extra_mem_start + + xen_extra_mem_size)); for (pfn = PFN_UP(xen_extra_mem_start); pfn < extra_pfn_end; pfn++) { -- 1.7.2.5 _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel From xen-devel-bounces@lists.xensource.com Thu Sep 15 05:33:58 2011 Return-path: Envelope-to: www-data@lists.xensource.com Delivery-date: Thu, 15 Sep 2011 05:33:58 -0700 Received: from localhost ([127.0.0.1] helo=lists.colo.xensource.com) by lists.xensource.com with esmtp (Exim 4.43) id 1R4B8g-00088t-0C; Thu, 15 Sep 2011 05:33:58 -0700 Received: from mail27.messagelabs.com ([193.109.254.147]) by lists.xensource.com with esmtp (Exim 4.43) id 1R4B50-0006VA-OF for xen-devel@lists.xensource.com; Thu, 15 Sep 2011 05:30:11 -0700 X-Env-Sender: david.vrabel@citrix.com X-Msg-Ref: server-14.tower-27.messagelabs.com!1316089792!36252638!2 X-Originating-IP: [66.165.176.89] X-StarScan-Version: 6.4.1; banners=-,-,- X-VirusChecked: Checked Received: (qmail 29590 invoked from network); 15 Sep 2011 12:29:54 -0000 Received: from smtp.citrix.com (HELO SMTP.CITRIX.COM) (66.165.176.89) by server-14.tower-27.messagelabs.com with RC4-SHA encrypted SMTP; 15 Sep 2011 12:29:54 -0000 X-IronPort-AV: E=Sophos;i="4.68,387,1312171200"; d="scan'208";a="17174346" Received: from ftlpmailmx02.citrite.net ([10.13.107.66]) by FTLPIPO01.CITRIX.COM with ESMTP/TLS/RC4-MD5; 15 Sep 2011 08:30:05 -0400 Received: from smtp01.ad.xensource.com (10.219.128.104) by smtprelay.citrix.com (10.13.107.66) with Microsoft SMTP Server id 8.3.137.0; Thu, 15 Sep 2011 08:30:01 -0400 Received: from minsc.uk.xensource.com ([10.31.1.114]) by smtp01.ad.xensource.com (8.13.1/8.13.1) with ESMTP id p8FCToiG027794; Thu, 15 Sep 2011 05:29:59 -0700 From: David Vrabel To: xen-devel@lists.xensource.com Date: Thu, 15 Sep 2011 13:29:28 +0100 Message-ID: <1316089768-22461-8-git-send-email-david.vrabel@citrix.com> X-Mailer: git-send-email 1.7.2.5 In-Reply-To: <1316089768-22461-1-git-send-email-david.vrabel@citrix.com> References: <1316089768-22461-1-git-send-email-david.vrabel@citrix.com> MIME-Version: 1.0 Content-Type: text/plain Cc: David Vrabel , Konrad Rzeszutek Wilk Subject: [Xen-devel] [PATCH 7/7] xen: release all pages within 1-1 p2m mappings X-BeenThere: xen-devel@lists.xensource.com X-Mailman-Version: 2.1.5 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xensource.com Errors-To: xen-devel-bounces@lists.xensource.com From: David Vrabel In xen_memory_setup() all reserved regions and gaps are set to an identity (1-1) p2m mapping. If an available page has a PFN within one of these 1-1 mappings it will become inaccessible (as it MFN is lost) so release them before setting up the mapping. This can make an additional 256 MiB or more of RAM available (depending on the size of the reserved regions in the memory map) if the initial pages overlap with reserved regions. Signed-off-by: David Vrabel --- arch/x86/xen/setup.c | 100 ++++++++++++++++--------------------------------- 1 files changed, 33 insertions(+), 67 deletions(-) diff --git a/arch/x86/xen/setup.c b/arch/x86/xen/setup.c index 6433371..986661b 100644 --- a/arch/x86/xen/setup.c +++ b/arch/x86/xen/setup.c @@ -126,72 +126,44 @@ static unsigned long __init xen_release_chunk(phys_addr_t start_addr, return len; } -static unsigned long __init xen_return_unused_memory( - unsigned long max_pfn, const struct e820entry *map, int nr_map) +static unsigned long __init xen_set_identity_and_release( + const struct e820entry *list, size_t map_size, unsigned long nr_pages) { - phys_addr_t max_addr = PFN_PHYS(max_pfn); - phys_addr_t last_end = ISA_END_ADDRESS; + phys_addr_t avail_end = PFN_PHYS(nr_pages); + phys_addr_t last_end = 0; unsigned long released = 0; - int i; - - /* Free any unused memory above the low 1Mbyte. */ - for (i = 0; i < nr_map && last_end < max_addr; i++) { - phys_addr_t end = map[i].addr; - end = min(max_addr, end); - - if (last_end < end) - released += xen_release_chunk(last_end, end); - last_end = max(last_end, map[i].addr + map[i].size); - } - - if (last_end < max_addr) - released += xen_release_chunk(last_end, max_addr); - - printk(KERN_INFO "released %lu pages of unused memory\n", released); - return released; -} - -static unsigned long __init xen_set_identity(const struct e820entry *list, - ssize_t map_size) -{ - phys_addr_t last = xen_initial_domain() ? 0 : ISA_END_ADDRESS; - phys_addr_t start_pci = last; - const struct e820entry *entry; unsigned long identity = 0; + const struct e820entry *entry; int i; + /* + * For each memory region consider whether to release and map + * the region and the preceeding gap (if any). If the region + * is RAM, only the gap is released and mapped. + */ for (i = 0, entry = list; i < map_size; i++, entry++) { - phys_addr_t start = entry->addr; - phys_addr_t end = start + entry->size; + phys_addr_t begin = last_end; + phys_addr_t end = entry->addr + entry->size; - if (start < last) - start = last; + last_end = end; - if (end <= start) - continue; - - /* Skip over the 1MB region. */ - if (last > end) - continue; + if (entry->type == E820_RAM || entry->type == E820_UNUSABLE) + end = entry->addr; - if ((entry->type == E820_RAM) || (entry->type == E820_UNUSABLE)) { - if (start > start_pci) - identity += set_phys_range_identity( - PFN_UP(start_pci), PFN_DOWN(start)); + if (begin < end) { + if (begin < avail_end) + released += xen_release_chunk( + begin, min(end, avail_end)); - /* Without saving 'last' we would gooble RAM too - * at the end of the loop. */ - last = end; - start_pci = end; - continue; + identity += set_phys_range_identity( + PFN_UP(begin), PFN_DOWN(end)); } - start_pci = min(start, start_pci); - last = end; } - if (last > start_pci) - identity += set_phys_range_identity( - PFN_UP(start_pci), PFN_DOWN(last)); - return identity; + + printk(KERN_INFO "Released %lu pages of unused memory\n", released); + printk(KERN_INFO "Set %ld page(s) to 1-1 mapping\n", identity); + + return released; } static unsigned long __init xen_get_max_pages(void) @@ -219,7 +191,6 @@ char * __init xen_memory_setup(void) struct xen_memory_map memmap; unsigned long max_pages; unsigned long extra_pages = 0; - unsigned long identity_pages = 0; int i; int op; @@ -252,8 +223,13 @@ char * __init xen_memory_setup(void) if (max_pages > max_pfn) extra_pages += max_pages - max_pfn; - xen_released_pages = xen_return_unused_memory(max_pfn, map, - memmap.nr_entries); + /* + * Set P2M for all non-RAM pages and E820 gaps to be identity + * type PFNs. Any RAM pages that would be made inaccesible by + * this are first released. + */ + xen_released_pages = xen_set_identity_and_release( + map, memmap.nr_entries, max_pfn); extra_pages += xen_released_pages; /* @@ -303,10 +279,6 @@ char * __init xen_memory_setup(void) * In domU, the ISA region is normal, usable memory, but we * reserve ISA memory anyway because too many things poke * about in there. - * - * In Dom0, the host E820 information can leave gaps in the - * ISA range, which would cause us to release those pages. To - * avoid this, we unconditionally reserve them here. */ e820_add_region(ISA_START_ADDRESS, ISA_END_ADDRESS - ISA_START_ADDRESS, E820_RESERVED); @@ -323,12 +295,6 @@ char * __init xen_memory_setup(void) sanitize_e820_map(e820.map, ARRAY_SIZE(e820.map), &e820.nr_map); - /* - * Set P2M for all non-RAM pages and E820 gaps to be identity - * type PFNs. - */ - identity_pages = xen_set_identity(e820.map, e820.nr_map); - printk(KERN_INFO "Set %ld page(s) to 1-1 mapping.\n", identity_pages); return "Xen"; } -- 1.7.2.5 _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel From xen-devel-bounces@lists.xensource.com Thu Sep 15 05:34:45 2011 Return-path: Envelope-to: www-data@lists.xensource.com Delivery-date: Thu, 15 Sep 2011 05:34:45 -0700 Received: from localhost ([127.0.0.1] helo=lists.colo.xensource.com) by lists.xensource.com with esmtp (Exim 4.43) id 1R4B9Q-0008Vh-UP; Thu, 15 Sep 2011 05:34:45 -0700 Received: from mail27.messagelabs.com ([193.109.254.147]) by lists.xensource.com with esmtp (Exim 4.43) id 1R4B50-0006Us-5Z for xen-devel@lists.xensource.com; Thu, 15 Sep 2011 05:30:11 -0700 X-Env-Sender: david.vrabel@citrix.com X-Msg-Ref: server-14.tower-27.messagelabs.com!1316089792!36252638!1 X-Originating-IP: [66.165.176.89] X-StarScan-Version: 6.4.1; banners=-,-,- X-VirusChecked: Checked Received: (qmail 29526 invoked from network); 15 Sep 2011 12:29:53 -0000 Received: from smtp.citrix.com (HELO SMTP.CITRIX.COM) (66.165.176.89) by server-14.tower-27.messagelabs.com with RC4-SHA encrypted SMTP; 15 Sep 2011 12:29:53 -0000 X-IronPort-AV: E=Sophos;i="4.68,387,1312171200"; d="scan'208";a="17174342" Received: from ftlpmailmx02.citrite.net ([10.13.107.66]) by FTLPIPO01.CITRIX.COM with ESMTP/TLS/RC4-MD5; 15 Sep 2011 08:30:05 -0400 Received: from smtp01.ad.xensource.com (10.219.128.104) by smtprelay.citrix.com (10.13.107.66) with Microsoft SMTP Server id 8.3.137.0; Thu, 15 Sep 2011 08:29:59 -0400 Received: from minsc.uk.xensource.com ([10.31.1.114]) by smtp01.ad.xensource.com (8.13.1/8.13.1) with ESMTP id p8FCToiF027794; Thu, 15 Sep 2011 05:29:58 -0700 From: David Vrabel To: xen-devel@lists.xensource.com Date: Thu, 15 Sep 2011 13:29:27 +0100 Message-ID: <1316089768-22461-7-git-send-email-david.vrabel@citrix.com> X-Mailer: git-send-email 1.7.2.5 In-Reply-To: <1316089768-22461-1-git-send-email-david.vrabel@citrix.com> References: <1316089768-22461-1-git-send-email-david.vrabel@citrix.com> MIME-Version: 1.0 Content-Type: text/plain Cc: David Vrabel , Konrad Rzeszutek Wilk Subject: [Xen-devel] [PATCH 6/7] xen: allow extra memory to be in multiple regions X-BeenThere: xen-devel@lists.xensource.com X-Mailman-Version: 2.1.5 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xensource.com Errors-To: xen-devel-bounces@lists.xensource.com From: David Vrabel Allow the extra memory (used by the balloon driver) to be in multiple regions (typically two regions, one for low memory and one for high memory). This allows the balloon driver to increase the number of available low pages (if the initial number if pages is small). As a side effect, the algorithm for building the e820 memory map is simpler and more obviously correct as the map supplied by the hypervisor is (almost) used as is (in particular, all reserved regions and gaps are preserved). Only RAM regions are altered and RAM regions above max_pfn + extra_pages are marked as unused (the region is split in two if necessary). Signed-off-by: David Vrabel --- arch/x86/xen/setup.c | 173 ++++++++++++++++++++++---------------------------- 1 files changed, 77 insertions(+), 96 deletions(-) diff --git a/arch/x86/xen/setup.c b/arch/x86/xen/setup.c index 0c8e974..6433371 100644 --- a/arch/x86/xen/setup.c +++ b/arch/x86/xen/setup.c @@ -54,26 +54,32 @@ unsigned long xen_released_pages; */ #define EXTRA_MEM_RATIO (10) -static void __init xen_add_extra_mem(unsigned long pages) +static void __init xen_add_extra_mem(u64 start, u64 size) { unsigned long pfn; + int i; - u64 size = (u64)pages * PAGE_SIZE; - u64 extra_start = xen_extra_mem[0].start + xen_extra_mem[0].size; - - if (!pages) - return; - - e820_add_region(extra_start, size, E820_RAM); - sanitize_e820_map(e820.map, ARRAY_SIZE(e820.map), &e820.nr_map); - - memblock_x86_reserve_range(extra_start, extra_start + size, "XEN EXTRA"); + for (i = 0; i < XEN_EXTRA_MEM_MAX_REGIONS; i++) { + /* Add new region. */ + if (xen_extra_mem[i].size == 0) { + xen_extra_mem[i].start = start; + xen_extra_mem[i].size = size; + break; + } + /* Append to existing region. */ + if (xen_extra_mem[i].start + xen_extra_mem[i].size == start) { + xen_extra_mem[i].size += size; + break; + } + } + if (i == XEN_EXTRA_MEM_MAX_REGIONS) + printk(KERN_WARNING "Warning: not enough extra memory regions\n"); - xen_extra_mem[0].size += size; + memblock_x86_reserve_range(start, start + size, "XEN EXTRA"); - xen_max_p2m_pfn = PFN_DOWN(extra_start + size); + xen_max_p2m_pfn = PFN_DOWN(start + size); - for (pfn = PFN_DOWN(extra_start); pfn <= xen_max_p2m_pfn; pfn++) + for (pfn = PFN_DOWN(start); pfn <= xen_max_p2m_pfn; pfn++) __set_phys_to_machine(pfn, INVALID_P2M_ENTRY); } @@ -120,8 +126,8 @@ static unsigned long __init xen_release_chunk(phys_addr_t start_addr, return len; } -static unsigned long __init xen_return_unused_memory(unsigned long max_pfn, - const struct e820map *e820) +static unsigned long __init xen_return_unused_memory( + unsigned long max_pfn, const struct e820entry *map, int nr_map) { phys_addr_t max_addr = PFN_PHYS(max_pfn); phys_addr_t last_end = ISA_END_ADDRESS; @@ -129,13 +135,13 @@ static unsigned long __init xen_return_unused_memory(unsigned long max_pfn, int i; /* Free any unused memory above the low 1Mbyte. */ - for (i = 0; i < e820->nr_map && last_end < max_addr; i++) { - phys_addr_t end = e820->map[i].addr; + for (i = 0; i < nr_map && last_end < max_addr; i++) { + phys_addr_t end = map[i].addr; end = min(max_addr, end); if (last_end < end) released += xen_release_chunk(last_end, end); - last_end = max(last_end, e820->map[i].addr + e820->map[i].size); + last_end = max(last_end, map[i].addr + map[i].size); } if (last_end < max_addr) @@ -206,14 +212,13 @@ static unsigned long __init xen_get_max_pages(void) char * __init xen_memory_setup(void) { static struct e820entry map[E820MAX] __initdata; - static struct e820entry map_raw[E820MAX] __initdata; unsigned long max_pfn = xen_start_info->nr_pages; unsigned long long mem_end; int rc; struct xen_memory_map memmap; + unsigned long max_pages; unsigned long extra_pages = 0; - unsigned long extra_limit; unsigned long identity_pages = 0; int i; int op; @@ -240,49 +245,59 @@ char * __init xen_memory_setup(void) } BUG_ON(rc); - memcpy(map_raw, map, sizeof(map)); - e820.nr_map = 0; - xen_extra_mem[0].start = mem_end; - for (i = 0; i < memmap.nr_entries; i++) { - unsigned long long end; - - /* Guard against non-page aligned E820 entries. */ - if (map[i].type == E820_RAM) - map[i].size -= (map[i].size + map[i].addr) % PAGE_SIZE; - - end = map[i].addr + map[i].size; - if (map[i].type == E820_RAM && end > mem_end) { - /* RAM off the end - may be partially included */ - u64 delta = min(map[i].size, end - mem_end); - - map[i].size -= delta; - end -= delta; - - extra_pages += PFN_DOWN(delta); - /* - * Set RAM below 4GB that is not for us to be unusable. - * This prevents "System RAM" address space from being - * used as potential resource for I/O address (happens - * when 'allocate_resource' is called). - */ - if (delta && - (xen_initial_domain() && end < 0x100000000ULL)) - e820_add_region(end, delta, E820_UNUSABLE); + /* Make sure the Xen-supplied memory map is well-ordered. */ + sanitize_e820_map(map, memmap.nr_entries, &memmap.nr_entries); + + max_pages = xen_get_max_pages(); + if (max_pages > max_pfn) + extra_pages += max_pages - max_pfn; + + xen_released_pages = xen_return_unused_memory(max_pfn, map, + memmap.nr_entries); + extra_pages += xen_released_pages; + + /* + * Clamp the amount of extra memory to a EXTRA_MEM_RATIO + * factor the base size. On non-highmem systems, the base + * size is the full initial memory allocation; on highmem it + * is limited to the max size of lowmem, so that it doesn't + * get completely filled. + * + * In principle there could be a problem in lowmem systems if + * the initial memory is also very large with respect to + * lowmem, but we won't try to deal with that here. + */ + extra_pages = min(EXTRA_MEM_RATIO * min(max_pfn, PFN_DOWN(MAXMEM)), + extra_pages); + + i = 0; + while (i < memmap.nr_entries) { + u64 addr = map[i].addr; + u64 size = map[i].size; + u32 type = map[i].type; + + if (type == E820_RAM) { + /* RAM regions must be page aligned. */ + size -= (addr + size) % PAGE_SIZE; + addr = PAGE_ALIGN(addr); + + if (addr < mem_end) { + size = min(size, mem_end - addr); + } else if (extra_pages) { + size = min(size, (u64)extra_pages * PAGE_SIZE); + extra_pages -= size / PAGE_SIZE; + xen_add_extra_mem(addr, size); + } else + type = E820_UNUSABLE; } - if (map[i].size > 0 && end > xen_extra_mem[0].start) - xen_extra_mem[0].start = end; + e820_add_region(addr, size, type); - /* Add region if any remains */ - if (map[i].size > 0) - e820_add_region(map[i].addr, map[i].size, map[i].type); + map[i].addr += size; + map[i].size -= size; + if (map[i].size == 0) + i++; } - /* Align the balloon area so that max_low_pfn does not get set - * to be at the _end_ of the PCI gap at the far end (fee01000). - * Note that the start of balloon area gets set in the loop above - * to be past the last E820 region. */ - if (xen_initial_domain() && (xen_extra_mem[0].start < (1ULL<<32))) - xen_extra_mem[0].start = (1ULL<<32); /* * In domU, the ISA region is normal, usable memory, but we @@ -308,45 +323,11 @@ char * __init xen_memory_setup(void) sanitize_e820_map(e820.map, ARRAY_SIZE(e820.map), &e820.nr_map); - extra_limit = xen_get_max_pages(); - if (max_pfn + extra_pages > extra_limit) { - if (extra_limit > max_pfn) - extra_pages = extra_limit - max_pfn; - else - extra_pages = 0; - } - - xen_released_pages = xen_return_unused_memory(xen_start_info->nr_pages, - &e820); - extra_pages += xen_released_pages; - - /* - * Clamp the amount of extra memory to a EXTRA_MEM_RATIO - * factor the base size. On non-highmem systems, the base - * size is the full initial memory allocation; on highmem it - * is limited to the max size of lowmem, so that it doesn't - * get completely filled. - * - * In principle there could be a problem in lowmem systems if - * the initial memory is also very large with respect to - * lowmem, but we won't try to deal with that here. - */ - extra_limit = min(EXTRA_MEM_RATIO * min(max_pfn, PFN_DOWN(MAXMEM)), - max_pfn + extra_pages); - - if (extra_limit >= max_pfn) - extra_pages = extra_limit - max_pfn; - else - extra_pages = 0; - - xen_add_extra_mem(extra_pages); - /* * Set P2M for all non-RAM pages and E820 gaps to be identity - * type PFNs. We supply it with the non-sanitized version - * of the E820. + * type PFNs. */ - identity_pages = xen_set_identity(map_raw, memmap.nr_entries); + identity_pages = xen_set_identity(e820.map, e820.nr_map); printk(KERN_INFO "Set %ld page(s) to 1-1 mapping.\n", identity_pages); return "Xen"; } -- 1.7.2.5 _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel From xen-devel-bounces@lists.xensource.com Thu Sep 15 05:35:37 2011 Return-path: Envelope-to: www-data@lists.xensource.com Delivery-date: Thu, 15 Sep 2011 05:35:37 -0700 Received: from localhost ([127.0.0.1] helo=lists.colo.xensource.com) by lists.xensource.com with esmtp (Exim 4.43) id 1R4BAG-0000U8-UH; Thu, 15 Sep 2011 05:35:36 -0700 Received: from mail182.messagelabs.com ([85.158.139.83]) by lists.xensource.com with esmtp (Exim 4.43) id 1R4B51-0006VK-J4 for xen-devel@lists.xensource.com; Thu, 15 Sep 2011 05:30:12 -0700 X-Env-Sender: david.vrabel@citrix.com X-Msg-Ref: server-9.tower-182.messagelabs.com!1316089796!18436031!2 X-Originating-IP: [66.165.176.63] X-StarScan-Version: 6.4.1; banners=-,-,- X-VirusChecked: Checked Received: (qmail 21022 invoked from network); 15 Sep 2011 12:30:08 -0000 Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63) by server-9.tower-182.messagelabs.com with RC4-SHA encrypted SMTP; 15 Sep 2011 12:30:08 -0000 X-IronPort-AV: E=Sophos;i="4.68,387,1312171200"; d="scan'208";a="163255909" Received: from ftlpmailmx02.citrite.net ([10.13.107.66]) by FTLPIPO02.CITRIX.COM with ESMTP/TLS/RC4-MD5; 15 Sep 2011 08:29:56 -0400 Received: from smtp01.ad.xensource.com (10.219.128.104) by smtprelay.citrix.com (10.13.107.66) with Microsoft SMTP Server id 8.3.137.0; Thu, 15 Sep 2011 08:29:56 -0400 Received: from minsc.uk.xensource.com ([10.31.1.114]) by smtp01.ad.xensource.com (8.13.1/8.13.1) with ESMTP id p8FCToiC027794; Thu, 15 Sep 2011 05:29:54 -0700 From: David Vrabel To: xen-devel@lists.xensource.com Date: Thu, 15 Sep 2011 13:29:24 +0100 Message-ID: <1316089768-22461-4-git-send-email-david.vrabel@citrix.com> X-Mailer: git-send-email 1.7.2.5 In-Reply-To: <1316089768-22461-1-git-send-email-david.vrabel@citrix.com> References: <1316089768-22461-1-git-send-email-david.vrabel@citrix.com> MIME-Version: 1.0 Content-Type: text/plain Cc: David Vrabel , Konrad Rzeszutek Wilk Subject: [Xen-devel] [PATCH 3/7] xen/balloon: account for pages released during memory setup X-BeenThere: xen-devel@lists.xensource.com X-Mailman-Version: 2.1.5 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xensource.com Errors-To: xen-devel-bounces@lists.xensource.com From: David Vrabel In xen_memory_setup() pages that occur in gaps in the memory map are released back to Xen. This reduces the domain's current page count in the hypervisor. The Xen balloon driver does not correctly decrease its initial current_pages count to reflect this. If 'delta' pages are released and the target is adjusted the resulting reservation is always 'delta' less than the requested target. This affects dom0 if the initial allocation of pages overlaps the PCI memory region but won't affect most domU guests that have been setup with pseudo-physical memory maps that don't have gaps. Fix this by accouting for the released pages when starting the balloon driver. If the domain's targets are managed by xapi, the domain may eventually run out of memory and die because xapi currently gets its target calculations wrong and whenever it is restarted it always reduces the target by 'delta'. Signed-off-by: David Vrabel --- arch/x86/xen/setup.c | 7 ++++++- drivers/xen/balloon.c | 4 +++- include/xen/page.h | 2 ++ 3 files changed, 11 insertions(+), 2 deletions(-) diff --git a/arch/x86/xen/setup.c b/arch/x86/xen/setup.c index 46d6d21..c983717 100644 --- a/arch/x86/xen/setup.c +++ b/arch/x86/xen/setup.c @@ -39,6 +39,9 @@ extern void xen_syscall32_target(void); /* Amount of extra memory space we add to the e820 ranges */ phys_addr_t xen_extra_mem_start, xen_extra_mem_size; +/* Number of pages released from the initial allocation. */ +unsigned long xen_released_pages; + /* * The maximum amount of extra memory compared to the base size. The * main scaling factor is the size of struct page. At extreme ratios @@ -313,7 +316,9 @@ char * __init xen_memory_setup(void) extra_pages = 0; } - extra_pages += xen_return_unused_memory(xen_start_info->nr_pages, &e820); + xen_released_pages = xen_return_unused_memory(xen_start_info->nr_pages, + &e820); + extra_pages += xen_released_pages; /* * Clamp the amount of extra memory to a EXTRA_MEM_RATIO diff --git a/drivers/xen/balloon.c b/drivers/xen/balloon.c index 5dfd8f8..4f59fb3 100644 --- a/drivers/xen/balloon.c +++ b/drivers/xen/balloon.c @@ -565,7 +565,9 @@ static int __init balloon_init(void) pr_info("xen/balloon: Initialising balloon driver.\n"); - balloon_stats.current_pages = xen_pv_domain() ? min(xen_start_info->nr_pages, max_pfn) : max_pfn; + balloon_stats.current_pages = xen_pv_domain() + ? min(xen_start_info->nr_pages - xen_released_pages, max_pfn) + : max_pfn; balloon_stats.target_pages = balloon_stats.current_pages; balloon_stats.balloon_low = 0; balloon_stats.balloon_high = 0; diff --git a/include/xen/page.h b/include/xen/page.h index 0be36b9..92b61f8 100644 --- a/include/xen/page.h +++ b/include/xen/page.h @@ -5,4 +5,6 @@ extern phys_addr_t xen_extra_mem_start, xen_extra_mem_size; +extern unsigned long xen_released_pages; + #endif /* _XEN_PAGE_H */ -- 1.7.2.5 _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel From xen-devel-bounces@lists.xensource.com Thu Sep 15 05:36:39 2011 Return-path: Envelope-to: www-data@lists.xensource.com Delivery-date: Thu, 15 Sep 2011 05:36:39 -0700 Received: from localhost ([127.0.0.1] helo=lists.colo.xensource.com) by lists.xensource.com with esmtp (Exim 4.43) id 1R4BBH-00011N-1a; Thu, 15 Sep 2011 05:36:39 -0700 Received: from mail182.messagelabs.com ([85.158.139.83]) by lists.xensource.com with esmtp (Exim 4.43) id 1R4B52-0006Ve-AR for xen-devel@lists.xensource.com; Thu, 15 Sep 2011 05:30:12 -0700 X-Env-Sender: david.vrabel@citrix.com X-Msg-Ref: server-9.tower-182.messagelabs.com!1316089796!18436031!3 X-Originating-IP: [66.165.176.63] X-StarScan-Version: 6.4.1; banners=-,-,- X-VirusChecked: Checked Received: (qmail 21102 invoked from network); 15 Sep 2011 12:30:09 -0000 Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63) by server-9.tower-182.messagelabs.com with RC4-SHA encrypted SMTP; 15 Sep 2011 12:30:09 -0000 X-IronPort-AV: E=Sophos;i="4.68,387,1312171200"; d="scan'208";a="163255985" Received: from ftlpmailmx02.citrite.net ([10.13.107.66]) by FTLPIPO02.CITRIX.COM with ESMTP/TLS/RC4-MD5; 15 Sep 2011 08:30:08 -0400 Received: from smtp01.ad.xensource.com (10.219.128.104) by smtprelay.citrix.com (10.13.107.66) with Microsoft SMTP Server id 8.3.137.0; Thu, 15 Sep 2011 08:29:58 -0400 Received: from minsc.uk.xensource.com ([10.31.1.114]) by smtp01.ad.xensource.com (8.13.1/8.13.1) with ESMTP id p8FCToiE027794; Thu, 15 Sep 2011 05:29:57 -0700 From: David Vrabel To: xen-devel@lists.xensource.com Date: Thu, 15 Sep 2011 13:29:26 +0100 Message-ID: <1316089768-22461-6-git-send-email-david.vrabel@citrix.com> X-Mailer: git-send-email 1.7.2.5 In-Reply-To: <1316089768-22461-1-git-send-email-david.vrabel@citrix.com> References: <1316089768-22461-1-git-send-email-david.vrabel@citrix.com> MIME-Version: 1.0 Content-Type: text/plain Cc: David Vrabel , Konrad Rzeszutek Wilk Subject: [Xen-devel] [PATCH 5/7] xen: allow balloon driver to use more than one memory region X-BeenThere: xen-devel@lists.xensource.com X-Mailman-Version: 2.1.5 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xensource.com Errors-To: xen-devel-bounces@lists.xensource.com From: David Vrabel Allow the xen balloon driver to populate its list of extra pages from more than one region of memory. This will allow platforms to provide (for example) a region of low memory and a region of high memory. The maximum possible number of extra regions is 128 (== E820MAX) which is quite large so xen_extra_mem is placed in __initdata. This is safe as both xen_memory_setup() and balloon_init() are in __init. The balloon regions themselves are not altered (i.e., there is still only the one region). Signed-off-by: David Vrabel --- arch/x86/xen/setup.c | 20 ++++++++++---------- drivers/xen/balloon.c | 44 +++++++++++++++++++++++++++----------------- include/xen/page.h | 10 +++++++++- 3 files changed, 46 insertions(+), 28 deletions(-) diff --git a/arch/x86/xen/setup.c b/arch/x86/xen/setup.c index c983717..0c8e974 100644 --- a/arch/x86/xen/setup.c +++ b/arch/x86/xen/setup.c @@ -37,7 +37,7 @@ extern void xen_syscall_target(void); extern void xen_syscall32_target(void); /* Amount of extra memory space we add to the e820 ranges */ -phys_addr_t xen_extra_mem_start, xen_extra_mem_size; +struct xen_memory_region xen_extra_mem[XEN_EXTRA_MEM_MAX_REGIONS] __initdata; /* Number of pages released from the initial allocation. */ unsigned long xen_released_pages; @@ -59,7 +59,7 @@ static void __init xen_add_extra_mem(unsigned long pages) unsigned long pfn; u64 size = (u64)pages * PAGE_SIZE; - u64 extra_start = xen_extra_mem_start + xen_extra_mem_size; + u64 extra_start = xen_extra_mem[0].start + xen_extra_mem[0].size; if (!pages) return; @@ -69,7 +69,7 @@ static void __init xen_add_extra_mem(unsigned long pages) memblock_x86_reserve_range(extra_start, extra_start + size, "XEN EXTRA"); - xen_extra_mem_size += size; + xen_extra_mem[0].size += size; xen_max_p2m_pfn = PFN_DOWN(extra_start + size); @@ -242,7 +242,7 @@ char * __init xen_memory_setup(void) memcpy(map_raw, map, sizeof(map)); e820.nr_map = 0; - xen_extra_mem_start = mem_end; + xen_extra_mem[0].start = mem_end; for (i = 0; i < memmap.nr_entries; i++) { unsigned long long end; @@ -270,8 +270,8 @@ char * __init xen_memory_setup(void) e820_add_region(end, delta, E820_UNUSABLE); } - if (map[i].size > 0 && end > xen_extra_mem_start) - xen_extra_mem_start = end; + if (map[i].size > 0 && end > xen_extra_mem[0].start) + xen_extra_mem[0].start = end; /* Add region if any remains */ if (map[i].size > 0) @@ -279,10 +279,10 @@ char * __init xen_memory_setup(void) } /* Align the balloon area so that max_low_pfn does not get set * to be at the _end_ of the PCI gap at the far end (fee01000). - * Note that xen_extra_mem_start gets set in the loop above to be - * past the last E820 region. */ - if (xen_initial_domain() && (xen_extra_mem_start < (1ULL<<32))) - xen_extra_mem_start = (1ULL<<32); + * Note that the start of balloon area gets set in the loop above + * to be past the last E820 region. */ + if (xen_initial_domain() && (xen_extra_mem[0].start < (1ULL<<32))) + xen_extra_mem[0].start = (1ULL<<32); /* * In domU, the ISA region is normal, usable memory, but we diff --git a/drivers/xen/balloon.c b/drivers/xen/balloon.c index 9efb993..fc43b53 100644 --- a/drivers/xen/balloon.c +++ b/drivers/xen/balloon.c @@ -555,11 +555,32 @@ void free_xenballooned_pages(int nr_pages, struct page** pages) } EXPORT_SYMBOL(free_xenballooned_pages); -static int __init balloon_init(void) +static void __init balloon_add_region(unsigned long start_pfn, + unsigned long pages) { unsigned long pfn, extra_pfn_end; struct page *page; + /* + * If the amount of usable memory has been limited (e.g., with + * the 'mem' command line parameter), don't add pages beyond + * this limit. + */ + extra_pfn_end = min(max_pfn, start_pfn + pages); + + for (pfn = start_pfn; pfn < extra_pfn_end; pfn++) { + page = pfn_to_page(pfn); + /* totalram_pages and totalhigh_pages do not + include the boot-time balloon extension, so + don't subtract from it. */ + __balloon_append(page); + } +} + +static int __init balloon_init(void) +{ + int i; + if (!xen_domain()) return -ENODEV; @@ -587,23 +608,12 @@ static int __init balloon_init(void) /* * Initialize the balloon with pages from the extra memory - * region (see arch/x86/xen/setup.c). - * - * If the amount of usable memory has been limited (e.g., with - * the 'mem' command line parameter), don't add pages beyond - * this limit. + * regions (see arch/x86/xen/setup.c). */ - extra_pfn_end = min(max_pfn, - (unsigned long)PFN_DOWN(xen_extra_mem_start - + xen_extra_mem_size)); - for (pfn = PFN_UP(xen_extra_mem_start); - pfn < extra_pfn_end; - pfn++) { - page = pfn_to_page(pfn); - /* totalram_pages and totalhigh_pages do not include the boot-time - balloon extension, so don't subtract from it. */ - __balloon_append(page); - } + for (i = 0; i < XEN_EXTRA_MEM_MAX_REGIONS; i++) + if (xen_extra_mem[i].size) + balloon_add_region(PFN_UP(xen_extra_mem[i].start), + PFN_DOWN(xen_extra_mem[i].size)); return 0; } diff --git a/include/xen/page.h b/include/xen/page.h index 92b61f8..12765b6 100644 --- a/include/xen/page.h +++ b/include/xen/page.h @@ -3,7 +3,15 @@ #include -extern phys_addr_t xen_extra_mem_start, xen_extra_mem_size; +struct xen_memory_region { + phys_addr_t start; + phys_addr_t size; +}; + +#define XEN_EXTRA_MEM_MAX_REGIONS 128 /* == E820MAX */ + +extern __initdata +struct xen_memory_region xen_extra_mem[XEN_EXTRA_MEM_MAX_REGIONS]; extern unsigned long xen_released_pages; -- 1.7.2.5 _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel From xen-devel-bounces@lists.xensource.com Thu Sep 15 05:41:24 2011 Return-path: Envelope-to: www-data@lists.xensource.com Delivery-date: Thu, 15 Sep 2011 05:41:24 -0700 Received: from localhost ([127.0.0.1] helo=lists.colo.xensource.com) by lists.xensource.com with esmtp (Exim 4.43) id 1R4BFr-0001Th-Sk; Thu, 15 Sep 2011 05:41:23 -0700 Received: from mail21.messagelabs.com ([85.158.143.35]) by lists.xensource.com with esmtp (Exim 4.43) id 1R4BFO-0001Gd-4U for xen-devel@lists.xensource.com; Thu, 15 Sep 2011 05:40:54 -0700 X-Env-Sender: david.vrabel@citrix.com X-Msg-Ref: server-10.tower-21.messagelabs.com!1316090435!54226765!1 X-Originating-IP: [66.165.176.89] X-StarScan-Version: 6.4.1; banners=-,-,- X-VirusChecked: Checked Received: (qmail 3653 invoked from network); 15 Sep 2011 12:40:36 -0000 Received: from smtp.citrix.com (HELO SMTP.CITRIX.COM) (66.165.176.89) by server-10.tower-21.messagelabs.com with RC4-SHA encrypted SMTP; 15 Sep 2011 12:40:36 -0000 X-IronPort-AV: E=Sophos;i="4.68,387,1312171200"; d="scan'208";a="17185364" Received: from ftlpmailmx01.citrite.net ([10.13.107.65]) by FTLPIPO01.CITRIX.COM with ESMTP/TLS/RC4-MD5; 15 Sep 2011 08:40:49 -0400 Received: from smtp01.ad.xensource.com (10.219.128.104) by smtprelay.citrix.com (10.13.107.65) with Microsoft SMTP Server id 8.3.137.0; Thu, 15 Sep 2011 08:40:49 -0400 Received: from minsc.uk.xensource.com ([10.31.1.114]) by smtp01.ad.xensource.com (8.13.1/8.13.1) with ESMTP id p8FCejwU027823; Thu, 15 Sep 2011 05:40:46 -0700 From: David Vrabel To: xen-devel@lists.xensource.com Date: Thu, 15 Sep 2011 13:40:05 +0100 Message-ID: <1316090411-22608-1-git-send-email-david.vrabel@citrix.com> X-Mailer: git-send-email 1.7.2.5 MIME-Version: 1.0 Content-Type: text/plain Cc: Andrew Morton , linux-kernel@vger.kernel.org, Konrad Rzeszutek Wilk Subject: [Xen-devel] [PATCH 0/6] xen: don't call vmalloc_sync_all() when mapping foreign pages X-BeenThere: xen-devel@lists.xensource.com X-Mailman-Version: 2.1.5 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xensource.com Errors-To: xen-devel-bounces@lists.xensource.com This set of pages avoids the need to call vmalloc_sync_all() when mapping foreign pages. Two new functions are adding for mapping foreign pages onto RAM pages instead of vmalloc space. This does waste a page of RAM for each mapped page. In the future a ballooned page could be used instead (once the API for getting a ballooned page with the right GFP flags is available). David _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel From xen-devel-bounces@lists.xensource.com Thu Sep 15 05:42:10 2011 Return-path: Envelope-to: www-data@lists.xensource.com Delivery-date: Thu, 15 Sep 2011 05:42:10 -0700 Received: from localhost ([127.0.0.1] helo=lists.colo.xensource.com) by lists.xensource.com with esmtp (Exim 4.43) id 1R4BGc-0001qs-DK; Thu, 15 Sep 2011 05:42:10 -0700 Received: from mail21.messagelabs.com ([85.158.143.35]) by lists.xensource.com with esmtp (Exim 4.43) id 1R4BFQ-0001Gf-0h for xen-devel@lists.xensource.com; Thu, 15 Sep 2011 05:40:56 -0700 X-Env-Sender: david.vrabel@citrix.com X-Msg-Ref: server-10.tower-21.messagelabs.com!1316090435!54226765!2 X-Originating-IP: [66.165.176.89] X-StarScan-Version: 6.4.1; banners=-,-,- X-VirusChecked: Checked Received: (qmail 3823 invoked from network); 15 Sep 2011 12:40:38 -0000 Received: from smtp.citrix.com (HELO SMTP.CITRIX.COM) (66.165.176.89) by server-10.tower-21.messagelabs.com with RC4-SHA encrypted SMTP; 15 Sep 2011 12:40:38 -0000 X-IronPort-AV: E=Sophos;i="4.68,387,1312171200"; d="scan'208";a="17185367" Received: from ftlpmailmx01.citrite.net ([10.13.107.65]) by FTLPIPO01.CITRIX.COM with ESMTP/TLS/RC4-MD5; 15 Sep 2011 08:40:52 -0400 Received: from smtp01.ad.xensource.com (10.219.128.104) by smtprelay.citrix.com (10.13.107.65) with Microsoft SMTP Server id 8.3.137.0; Thu, 15 Sep 2011 08:40:52 -0400 Received: from minsc.uk.xensource.com ([10.31.1.114]) by smtp01.ad.xensource.com (8.13.1/8.13.1) with ESMTP id p8FCejwW027823; Thu, 15 Sep 2011 05:40:50 -0700 From: David Vrabel To: xen-devel@lists.xensource.com Date: Thu, 15 Sep 2011 13:40:07 +0100 Message-ID: <1316090411-22608-3-git-send-email-david.vrabel@citrix.com> X-Mailer: git-send-email 1.7.2.5 In-Reply-To: <1316090411-22608-1-git-send-email-david.vrabel@citrix.com> References: <1316090411-22608-1-git-send-email-david.vrabel@citrix.com> MIME-Version: 1.0 Content-Type: text/plain Cc: Andrew Morton , David Vrabel , linux-kernel@vger.kernel.org, Konrad Rzeszutek Wilk Subject: [Xen-devel] [PATCH 2/6] block: xen-blkback: use API provided by xenbus module to map rings X-BeenThere: xen-devel@lists.xensource.com X-Mailman-Version: 2.1.5 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xensource.com Errors-To: xen-devel-bounces@lists.xensource.com From: David Vrabel The xenbus module provides xenbus_map_ring_page() and xenbus_map_ring_page(). Use these to map the ring pages granted by the frontend. Signed-off-by: David Vrabel --- drivers/block/xen-blkback/common.h | 5 +-- drivers/block/xen-blkback/xenbus.c | 55 +++++------------------------------ 2 files changed, 9 insertions(+), 51 deletions(-) diff --git a/drivers/block/xen-blkback/common.h b/drivers/block/xen-blkback/common.h index 9e40b28..65ef268 100644 --- a/drivers/block/xen-blkback/common.h +++ b/drivers/block/xen-blkback/common.h @@ -139,7 +139,7 @@ struct xen_blkif { /* Comms information. */ enum blkif_protocol blk_protocol; union blkif_back_rings blk_rings; - struct vm_struct *blk_ring_area; + struct page *blk_ring_page; /* The VBD attached to this interface. */ struct xen_vbd vbd; /* Back pointer to the backend_info. */ @@ -163,9 +163,6 @@ struct xen_blkif { int st_wr_sect; wait_queue_head_t waiting_to_free; - - grant_handle_t shmem_handle; - grant_ref_t shmem_ref; }; diff --git a/drivers/block/xen-blkback/xenbus.c b/drivers/block/xen-blkback/xenbus.c index 3f129b4..7e21ef4 100644 --- a/drivers/block/xen-blkback/xenbus.c +++ b/drivers/block/xen-blkback/xenbus.c @@ -120,38 +120,6 @@ static struct xen_blkif *xen_blkif_alloc(domid_t domid) return blkif; } -static int map_frontend_page(struct xen_blkif *blkif, unsigned long shared_page) -{ - struct gnttab_map_grant_ref op; - - gnttab_set_map_op(&op, (unsigned long)blkif->blk_ring_area->addr, - GNTMAP_host_map, shared_page, blkif->domid); - - if (HYPERVISOR_grant_table_op(GNTTABOP_map_grant_ref, &op, 1)) - BUG(); - - if (op.status) { - DPRINTK("Grant table operation failure !\n"); - return op.status; - } - - blkif->shmem_ref = shared_page; - blkif->shmem_handle = op.handle; - - return 0; -} - -static void unmap_frontend_page(struct xen_blkif *blkif) -{ - struct gnttab_unmap_grant_ref op; - - gnttab_set_unmap_op(&op, (unsigned long)blkif->blk_ring_area->addr, - GNTMAP_host_map, blkif->shmem_handle); - - if (HYPERVISOR_grant_table_op(GNTTABOP_unmap_grant_ref, &op, 1)) - BUG(); -} - static int xen_blkif_map(struct xen_blkif *blkif, unsigned long shared_page, unsigned int evtchn) { @@ -161,35 +129,30 @@ static int xen_blkif_map(struct xen_blkif *blkif, unsigned long shared_page, if (blkif->irq) return 0; - blkif->blk_ring_area = alloc_vm_area(PAGE_SIZE); - if (!blkif->blk_ring_area) - return -ENOMEM; - - err = map_frontend_page(blkif, shared_page); - if (err) { - free_vm_area(blkif->blk_ring_area); + err = xenbus_map_ring_page(blkif->be->dev, shared_page, + &blkif->blk_ring_page); + if (err < 0) return err; - } switch (blkif->blk_protocol) { case BLKIF_PROTOCOL_NATIVE: { struct blkif_sring *sring; - sring = (struct blkif_sring *)blkif->blk_ring_area->addr; + sring = page_address(blkif->blk_ring_page); BACK_RING_INIT(&blkif->blk_rings.native, sring, PAGE_SIZE); break; } case BLKIF_PROTOCOL_X86_32: { struct blkif_x86_32_sring *sring_x86_32; - sring_x86_32 = (struct blkif_x86_32_sring *)blkif->blk_ring_area->addr; + sring_x86_32 = page_address(blkif->blk_ring_page); BACK_RING_INIT(&blkif->blk_rings.x86_32, sring_x86_32, PAGE_SIZE); break; } case BLKIF_PROTOCOL_X86_64: { struct blkif_x86_64_sring *sring_x86_64; - sring_x86_64 = (struct blkif_x86_64_sring *)blkif->blk_ring_area->addr; + sring_x86_64 = page_address(blkif->blk_ring_page); BACK_RING_INIT(&blkif->blk_rings.x86_64, sring_x86_64, PAGE_SIZE); break; } @@ -201,8 +164,7 @@ static int xen_blkif_map(struct xen_blkif *blkif, unsigned long shared_page, xen_blkif_be_int, 0, "blkif-backend", blkif); if (err < 0) { - unmap_frontend_page(blkif); - free_vm_area(blkif->blk_ring_area); + xenbus_unmap_ring_page(blkif->be->dev, blkif->blk_ring_page); blkif->blk_rings.common.sring = NULL; return err; } @@ -228,8 +190,7 @@ static void xen_blkif_disconnect(struct xen_blkif *blkif) } if (blkif->blk_rings.common.sring) { - unmap_frontend_page(blkif); - free_vm_area(blkif->blk_ring_area); + xenbus_unmap_ring_page(blkif->be->dev, blkif->blk_ring_page); blkif->blk_rings.common.sring = NULL; } } -- 1.7.2.5 _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel From xen-devel-bounces@lists.xensource.com Thu Sep 15 05:42:57 2011 Return-path: Envelope-to: www-data@lists.xensource.com Delivery-date: Thu, 15 Sep 2011 05:42:57 -0700 Received: from localhost ([127.0.0.1] helo=lists.colo.xensource.com) by lists.xensource.com with esmtp (Exim 4.43) id 1R4BHN-0002Dm-I6; Thu, 15 Sep 2011 05:42:57 -0700 Received: from mail27.messagelabs.com ([193.109.254.147]) by lists.xensource.com with esmtp (Exim 4.43) id 1R4BFQ-0001Gg-79 for xen-devel@lists.xensource.com; Thu, 15 Sep 2011 05:40:56 -0700 X-Env-Sender: david.vrabel@citrix.com X-Msg-Ref: server-7.tower-27.messagelabs.com!1316090429!48777884!1 X-Originating-IP: [66.165.176.63] X-StarScan-Version: 6.4.1; banners=-,-,- X-VirusChecked: Checked Received: (qmail 32353 invoked from network); 15 Sep 2011 12:40:31 -0000 Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63) by server-7.tower-27.messagelabs.com with RC4-SHA encrypted SMTP; 15 Sep 2011 12:40:31 -0000 X-IronPort-AV: E=Sophos;i="4.68,387,1312171200"; d="scan'208";a="163268193" Received: from ftlpmailmx01.citrite.net ([10.13.107.65]) by FTLPIPO02.CITRIX.COM with ESMTP/TLS/RC4-MD5; 15 Sep 2011 08:40:51 -0400 Received: from smtp01.ad.xensource.com (10.219.128.104) by smtprelay.citrix.com (10.13.107.65) with Microsoft SMTP Server id 8.3.137.0; Thu, 15 Sep 2011 08:40:50 -0400 Received: from minsc.uk.xensource.com ([10.31.1.114]) by smtp01.ad.xensource.com (8.13.1/8.13.1) with ESMTP id p8FCejwV027823; Thu, 15 Sep 2011 05:40:49 -0700 From: David Vrabel To: xen-devel@lists.xensource.com Date: Thu, 15 Sep 2011 13:40:06 +0100 Message-ID: <1316090411-22608-2-git-send-email-david.vrabel@citrix.com> X-Mailer: git-send-email 1.7.2.5 In-Reply-To: <1316090411-22608-1-git-send-email-david.vrabel@citrix.com> References: <1316090411-22608-1-git-send-email-david.vrabel@citrix.com> MIME-Version: 1.0 Content-Type: text/plain Cc: Andrew Morton , David Vrabel , linux-kernel@vger.kernel.org, Konrad Rzeszutek Wilk Subject: [Xen-devel] [PATCH 1/6] xen: add functions for mapping foreign pages over pages X-BeenThere: xen-devel@lists.xensource.com X-Mailman-Version: 2.1.5 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xensource.com Errors-To: xen-devel-bounces@lists.xensource.com From: David Vrabel Add xenbus_map_ring_page() and xenbus_unmap_ring_page() which map and unmap foreign pages over a page instead of mapping them into vmalloc address space. This avoids having to do an expensive vmalloc_sync_all(). Signed-off-by: David Vrabel --- drivers/xen/xenbus/xenbus_client.c | 68 ++++++++++++++++++++++++++++++++++++ include/xen/xenbus.h | 3 ++ 2 files changed, 71 insertions(+), 0 deletions(-) diff --git a/drivers/xen/xenbus/xenbus_client.c b/drivers/xen/xenbus/xenbus_client.c index cdacf92..504325b 100644 --- a/drivers/xen/xenbus/xenbus_client.c +++ b/drivers/xen/xenbus/xenbus_client.c @@ -32,6 +32,7 @@ #include #include +#include #include #include #include @@ -39,6 +40,7 @@ #include #include #include +#include const char *xenbus_strstate(enum xenbus_state state) { @@ -509,6 +511,44 @@ EXPORT_SYMBOL_GPL(xenbus_map_ring); /** + * xenbus_map_ring_page - map a foreign page into a kernel page + * @dev: xenbus device + * @gnt_ref: grant reference + * @page: return the page the foreign page has been mapped to + * + * Map a foreign page from another domain's grant table into a newly + * allocated page in this domain. The page must be unmapped with + * xenbus_unmap_ring_page(). + * + * Returns 0 on success, and -ENOMEM or GNTST_* (see + * include/xen/interface/grant_table.h) on error. + */ +int xenbus_map_ring_page(struct xenbus_device *dev, int gnt_ref, + struct page **page) +{ + struct page *new_page; + grant_ref_t handle; + int ret; + + new_page = alloc_page(GFP_KERNEL); + if (!new_page) + return -ENOMEM; + + ret = xenbus_map_ring(dev, gnt_ref, &handle, page_address(new_page)); + if (ret < 0) + goto err; + + new_page->private = handle; + *page = new_page; + return 0; + +err: + __free_page(new_page); + return ret; +} +EXPORT_SYMBOL_GPL(xenbus_map_ring_page); + +/** * xenbus_unmap_ring_vfree * @dev: xenbus device * @vaddr: addr to unmap @@ -593,6 +633,34 @@ int xenbus_unmap_ring(struct xenbus_device *dev, } EXPORT_SYMBOL_GPL(xenbus_unmap_ring); +/** + * xenbus_unmap_ring_page - unmap an foreign page from a kernel page + * @dev: xenbus device + * @page: page the foreign page was mapped to + * + * Unmap a foreign page previously mapped with xenbus_map_ring_page(). + * The page is freed. + */ +void xenbus_unmap_ring_page(struct xenbus_device *dev, struct page *page) +{ + int ret; + + ret = xenbus_unmap_ring(dev, page->private, page_address(page)); + if (ret < 0) + return; + + /* + * Restore the original PTE of this page before freeing it. + */ + ret = HYPERVISOR_update_va_mapping( + (unsigned long)page_address(page), + mfn_pte(get_phys_to_machine(page_to_pfn(page)), PAGE_KERNEL), + 0); + BUG_ON(ret); + + __free_page(page); +} +EXPORT_SYMBOL_GPL(xenbus_unmap_ring_page); /** * xenbus_read_driver_state diff --git a/include/xen/xenbus.h b/include/xen/xenbus.h index aceeca7..ebde2fd 100644 --- a/include/xen/xenbus.h +++ b/include/xen/xenbus.h @@ -212,10 +212,13 @@ int xenbus_map_ring_valloc(struct xenbus_device *dev, int gnt_ref, void **vaddr); int xenbus_map_ring(struct xenbus_device *dev, int gnt_ref, grant_handle_t *handle, void *vaddr); +int xenbus_map_ring_page(struct xenbus_device *dev, int gnt_ref, + struct page **page); int xenbus_unmap_ring_vfree(struct xenbus_device *dev, void *vaddr); int xenbus_unmap_ring(struct xenbus_device *dev, grant_handle_t handle, void *vaddr); +void xenbus_unmap_ring_page(struct xenbus_device *dev, struct page *page); int xenbus_alloc_evtchn(struct xenbus_device *dev, int *port); int xenbus_bind_evtchn(struct xenbus_device *dev, int remote_port, int *port); -- 1.7.2.5 _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel From xen-devel-bounces@lists.xensource.com Thu Sep 15 05:43:43 2011 Return-path: Envelope-to: www-data@lists.xensource.com Delivery-date: Thu, 15 Sep 2011 05:43:43 -0700 Received: from localhost ([127.0.0.1] helo=lists.colo.xensource.com) by lists.xensource.com with esmtp (Exim 4.43) id 1R4BI7-0002ba-9P; Thu, 15 Sep 2011 05:43:43 -0700 Received: from mail27.messagelabs.com ([193.109.254.147]) by lists.xensource.com with esmtp (Exim 4.43) id 1R4BFR-0001Gm-O4 for xen-devel@lists.xensource.com; Thu, 15 Sep 2011 05:40:58 -0700 X-Env-Sender: david.vrabel@citrix.com X-Msg-Ref: server-7.tower-27.messagelabs.com!1316090429!48777884!2 X-Originating-IP: [66.165.176.63] X-StarScan-Version: 6.4.1; banners=-,-,- X-VirusChecked: Checked Received: (qmail 32424 invoked from network); 15 Sep 2011 12:40:32 -0000 Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63) by server-7.tower-27.messagelabs.com with RC4-SHA encrypted SMTP; 15 Sep 2011 12:40:32 -0000 X-IronPort-AV: E=Sophos;i="4.68,387,1312171200"; d="scan'208";a="163268205" Received: from ftlpmailmx01.citrite.net ([10.13.107.65]) by FTLPIPO02.CITRIX.COM with ESMTP/TLS/RC4-MD5; 15 Sep 2011 08:40:54 -0400 Received: from smtp01.ad.xensource.com (10.219.128.104) by smtprelay.citrix.com (10.13.107.65) with Microsoft SMTP Server id 8.3.137.0; Thu, 15 Sep 2011 08:40:53 -0400 Received: from minsc.uk.xensource.com ([10.31.1.114]) by smtp01.ad.xensource.com (8.13.1/8.13.1) with ESMTP id p8FCejwX027823; Thu, 15 Sep 2011 05:40:52 -0700 From: David Vrabel To: xen-devel@lists.xensource.com Date: Thu, 15 Sep 2011 13:40:08 +0100 Message-ID: <1316090411-22608-4-git-send-email-david.vrabel@citrix.com> X-Mailer: git-send-email 1.7.2.5 In-Reply-To: <1316090411-22608-1-git-send-email-david.vrabel@citrix.com> References: <1316090411-22608-1-git-send-email-david.vrabel@citrix.com> MIME-Version: 1.0 Content-Type: text/plain Cc: Andrew Morton , David Vrabel , linux-kernel@vger.kernel.org, Ian Campbell , Konrad Rzeszutek Wilk Subject: [Xen-devel] [PATCH 3/6] net: xen-netback: use API provided by xenbus module to map rings X-BeenThere: xen-devel@lists.xensource.com X-Mailman-Version: 2.1.5 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xensource.com Errors-To: xen-devel-bounces@lists.xensource.com From: David Vrabel The xenbus module provides xenbus_map_ring_page() and xenbus_map_ring_page(). Use these to map the ring pages granted by the frontend. Signed-off-by: David Vrabel Cc: Ian Campbell --- drivers/net/xen-netback/common.h | 13 +++--- drivers/net/xen-netback/netback.c | 79 +++++++----------------------------- 2 files changed, 23 insertions(+), 69 deletions(-) diff --git a/drivers/net/xen-netback/common.h b/drivers/net/xen-netback/common.h index 161f207..05e0a8e 100644 --- a/drivers/net/xen-netback/common.h +++ b/drivers/net/xen-netback/common.h @@ -58,10 +58,6 @@ struct xenvif { u8 fe_dev_addr[6]; /* Physical parameters of the comms window. */ - grant_handle_t tx_shmem_handle; - grant_ref_t tx_shmem_ref; - grant_handle_t rx_shmem_handle; - grant_ref_t rx_shmem_ref; unsigned int irq; /* List of frontends to notify after a batch of frames sent. */ @@ -70,8 +66,8 @@ struct xenvif { /* The shared rings and indexes. */ struct xen_netif_tx_back_ring tx; struct xen_netif_rx_back_ring rx; - struct vm_struct *tx_comms_area; - struct vm_struct *rx_comms_area; + struct page *tx_ring_page; + struct page *rx_ring_page; /* Frontend feature information. */ u8 can_sg:1; @@ -106,6 +102,11 @@ struct xenvif { wait_queue_head_t waiting_to_free; }; +static inline struct xenbus_device *xenvif_to_xenbus_device(struct xenvif *vif) +{ + return to_xenbus_device(vif->dev->dev.parent); +} + #define XEN_NETIF_TX_RING_SIZE __CONST_RING_SIZE(xen_netif_tx, PAGE_SIZE) #define XEN_NETIF_RX_RING_SIZE __CONST_RING_SIZE(xen_netif_rx, PAGE_SIZE) diff --git a/drivers/net/xen-netback/netback.c b/drivers/net/xen-netback/netback.c index fd00f25..2a017b28 100644 --- a/drivers/net/xen-netback/netback.c +++ b/drivers/net/xen-netback/netback.c @@ -1577,88 +1577,41 @@ static int xen_netbk_kthread(void *data) void xen_netbk_unmap_frontend_rings(struct xenvif *vif) { - struct gnttab_unmap_grant_ref op; - - if (vif->tx.sring) { - gnttab_set_unmap_op(&op, (unsigned long)vif->tx_comms_area->addr, - GNTMAP_host_map, vif->tx_shmem_handle); - - if (HYPERVISOR_grant_table_op(GNTTABOP_unmap_grant_ref, &op, 1)) - BUG(); - } - - if (vif->rx.sring) { - gnttab_set_unmap_op(&op, (unsigned long)vif->rx_comms_area->addr, - GNTMAP_host_map, vif->rx_shmem_handle); - - if (HYPERVISOR_grant_table_op(GNTTABOP_unmap_grant_ref, &op, 1)) - BUG(); - } - if (vif->rx_comms_area) - free_vm_area(vif->rx_comms_area); - if (vif->tx_comms_area) - free_vm_area(vif->tx_comms_area); + if (vif->tx.sring) + xenbus_unmap_ring_page(xenvif_to_xenbus_device(vif), + vif->tx_ring_page); + if (vif->rx.sring) + xenbus_unmap_ring_page(xenvif_to_xenbus_device(vif), + vif->rx_ring_page); } int xen_netbk_map_frontend_rings(struct xenvif *vif, grant_ref_t tx_ring_ref, grant_ref_t rx_ring_ref) { - struct gnttab_map_grant_ref op; struct xen_netif_tx_sring *txs; struct xen_netif_rx_sring *rxs; int err = -ENOMEM; - vif->tx_comms_area = alloc_vm_area(PAGE_SIZE); - if (vif->tx_comms_area == NULL) + err = xenbus_map_ring_page(xenvif_to_xenbus_device(vif), + tx_ring_ref, &vif->tx_ring_page); + if (err) goto err; - vif->rx_comms_area = alloc_vm_area(PAGE_SIZE); - if (vif->rx_comms_area == NULL) - goto err; - - gnttab_set_map_op(&op, (unsigned long)vif->tx_comms_area->addr, - GNTMAP_host_map, tx_ring_ref, vif->domid); - - if (HYPERVISOR_grant_table_op(GNTTABOP_map_grant_ref, &op, 1)) - BUG(); - - if (op.status) { - netdev_warn(vif->dev, - "failed to map tx ring. err=%d status=%d\n", - err, op.status); - err = op.status; - goto err; - } - - vif->tx_shmem_ref = tx_ring_ref; - vif->tx_shmem_handle = op.handle; - - txs = (struct xen_netif_tx_sring *)vif->tx_comms_area->addr; + txs = page_address(vif->tx_ring_page); BACK_RING_INIT(&vif->tx, txs, PAGE_SIZE); - gnttab_set_map_op(&op, (unsigned long)vif->rx_comms_area->addr, - GNTMAP_host_map, rx_ring_ref, vif->domid); - - if (HYPERVISOR_grant_table_op(GNTTABOP_map_grant_ref, &op, 1)) - BUG(); - - if (op.status) { - netdev_warn(vif->dev, - "failed to map rx ring. err=%d status=%d\n", - err, op.status); - err = op.status; + err = xenbus_map_ring_page(xenvif_to_xenbus_device(vif), + rx_ring_ref, &vif->rx_ring_page); + if (err) goto err; - } - - vif->rx_shmem_ref = rx_ring_ref; - vif->rx_shmem_handle = op.handle; - vif->rx_req_cons_peek = 0; - rxs = (struct xen_netif_rx_sring *)vif->rx_comms_area->addr; + rxs = page_address(vif->rx_ring_page); BACK_RING_INIT(&vif->rx, rxs, PAGE_SIZE); + vif->rx_req_cons_peek = 0; + return 0; err: -- 1.7.2.5 _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel From xen-devel-bounces@lists.xensource.com Thu Sep 15 05:44:38 2011 Return-path: Envelope-to: www-data@lists.xensource.com Delivery-date: Thu, 15 Sep 2011 05:44:38 -0700 Received: from localhost ([127.0.0.1] helo=lists.colo.xensource.com) by lists.xensource.com with esmtp (Exim 4.43) id 1R4BJ0-00034A-1d; Thu, 15 Sep 2011 05:44:38 -0700 Received: from mail27.messagelabs.com ([193.109.254.147]) by lists.xensource.com with esmtp (Exim 4.43) id 1R4BFT-0001H9-43 for xen-devel@lists.xensource.com; Thu, 15 Sep 2011 05:40:59 -0700 X-Env-Sender: david.vrabel@citrix.com X-Msg-Ref: server-7.tower-27.messagelabs.com!1316090429!48777884!3 X-Originating-IP: [66.165.176.63] X-StarScan-Version: 6.4.1; banners=-,-,- X-VirusChecked: Checked Received: (qmail 32510 invoked from network); 15 Sep 2011 12:40:34 -0000 Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63) by server-7.tower-27.messagelabs.com with RC4-SHA encrypted SMTP; 15 Sep 2011 12:40:34 -0000 X-IronPort-AV: E=Sophos;i="4.68,387,1312171200"; d="scan'208";a="163268208" Received: from ftlpmailmx01.citrite.net ([10.13.107.65]) by FTLPIPO02.CITRIX.COM with ESMTP/TLS/RC4-MD5; 15 Sep 2011 08:40:55 -0400 Received: from smtp01.ad.xensource.com (10.219.128.104) by smtprelay.citrix.com (10.13.107.65) with Microsoft SMTP Server id 8.3.137.0; Thu, 15 Sep 2011 08:40:55 -0400 Received: from minsc.uk.xensource.com ([10.31.1.114]) by smtp01.ad.xensource.com (8.13.1/8.13.1) with ESMTP id p8FCejwY027823; Thu, 15 Sep 2011 05:40:54 -0700 From: David Vrabel To: xen-devel@lists.xensource.com Date: Thu, 15 Sep 2011 13:40:09 +0100 Message-ID: <1316090411-22608-5-git-send-email-david.vrabel@citrix.com> X-Mailer: git-send-email 1.7.2.5 In-Reply-To: <1316090411-22608-1-git-send-email-david.vrabel@citrix.com> References: <1316090411-22608-1-git-send-email-david.vrabel@citrix.com> MIME-Version: 1.0 Content-Type: text/plain Cc: Andrew Morton , David Vrabel , linux-kernel@vger.kernel.org, Konrad Rzeszutek Wilk Subject: [Xen-devel] [PATCH 4/6] xen: xen-pciback: use xenbus_map_ring_page() to map rings X-BeenThere: xen-devel@lists.xensource.com X-Mailman-Version: 2.1.5 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xensource.com Errors-To: xen-devel-bounces@lists.xensource.com From: David Vrabel xenbus_map_ring_valloc() is deprecated in favour of xenbus_map_ring_page(). Signed-off-by: David Vrabel --- drivers/xen/xen-pciback/pciback.h | 1 + drivers/xen/xen-pciback/xenbus.c | 7 +++---- 2 files changed, 4 insertions(+), 4 deletions(-) diff --git a/drivers/xen/xen-pciback/pciback.h b/drivers/xen/xen-pciback/pciback.h index a0e131a..956aef9 100644 --- a/drivers/xen/xen-pciback/pciback.h +++ b/drivers/xen/xen-pciback/pciback.h @@ -32,6 +32,7 @@ struct xen_pcibk_device { struct xenbus_watch be_watch; u8 be_watching; int evtchn_irq; + struct page *ring_page; struct xen_pci_sharedinfo *sh_info; unsigned long flags; struct work_struct op_work; diff --git a/drivers/xen/xen-pciback/xenbus.c b/drivers/xen/xen-pciback/xenbus.c index 978d2c6..41bfefc 100644 --- a/drivers/xen/xen-pciback/xenbus.c +++ b/drivers/xen/xen-pciback/xenbus.c @@ -79,7 +79,7 @@ static void xen_pcibk_disconnect(struct xen_pcibk_device *pdev) spin_lock(&pdev->dev_lock); if (pdev->sh_info != NULL) { - xenbus_unmap_ring_vfree(pdev->xdev, pdev->sh_info); + xenbus_unmap_ring_page(pdev->xdev, pdev->ring_page); pdev->sh_info = NULL; } spin_unlock(&pdev->dev_lock); @@ -107,13 +107,12 @@ static int xen_pcibk_do_attach(struct xen_pcibk_device *pdev, int gnt_ref, int remote_evtchn) { int err = 0; - void *vaddr; dev_dbg(&pdev->xdev->dev, "Attaching to frontend resources - gnt_ref=%d evtchn=%d\n", gnt_ref, remote_evtchn); - err = xenbus_map_ring_valloc(pdev->xdev, gnt_ref, &vaddr); + err = xenbus_map_ring_page(pdev->xdev, gnt_ref, &pdev->ring_page); if (err < 0) { xenbus_dev_fatal(pdev->xdev, err, "Error mapping other domain page in ours."); @@ -121,7 +120,7 @@ static int xen_pcibk_do_attach(struct xen_pcibk_device *pdev, int gnt_ref, } spin_lock(&pdev->dev_lock); - pdev->sh_info = vaddr; + pdev->sh_info = page_address(pdev->ring_page); spin_unlock(&pdev->dev_lock); err = bind_interdomain_evtchn_to_irqhandler( -- 1.7.2.5 _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel From xen-devel-bounces@lists.xensource.com Thu Sep 15 05:45:21 2011 Return-path: Envelope-to: www-data@lists.xensource.com Delivery-date: Thu, 15 Sep 2011 05:45:21 -0700 Received: from localhost ([127.0.0.1] helo=lists.colo.xensource.com) by lists.xensource.com with esmtp (Exim 4.43) id 1R4BJh-0003RB-My; Thu, 15 Sep 2011 05:45:21 -0700 Received: from mail21.messagelabs.com ([85.158.143.35]) by lists.xensource.com with esmtp (Exim 4.43) id 1R4BFU-0001Ht-SE for xen-devel@lists.xensource.com; Thu, 15 Sep 2011 05:41:02 -0700 X-Env-Sender: david.vrabel@citrix.com X-Msg-Ref: server-10.tower-21.messagelabs.com!1316090435!54226765!3 X-Originating-IP: [66.165.176.89] X-StarScan-Version: 6.4.1; banners=-,-,- X-VirusChecked: Checked Received: (qmail 4276 invoked from network); 15 Sep 2011 12:40:43 -0000 Received: from smtp.citrix.com (HELO SMTP.CITRIX.COM) (66.165.176.89) by server-10.tower-21.messagelabs.com with RC4-SHA encrypted SMTP; 15 Sep 2011 12:40:43 -0000 X-IronPort-AV: E=Sophos;i="4.68,387,1312171200"; d="scan'208";a="17185376" Received: from ftlpmailmx01.citrite.net ([10.13.107.65]) by FTLPIPO01.CITRIX.COM with ESMTP/TLS/RC4-MD5; 15 Sep 2011 08:40:57 -0400 Received: from smtp01.ad.xensource.com (10.219.128.104) by smtprelay.citrix.com (10.13.107.65) with Microsoft SMTP Server id 8.3.137.0; Thu, 15 Sep 2011 08:40:56 -0400 Received: from minsc.uk.xensource.com ([10.31.1.114]) by smtp01.ad.xensource.com (8.13.1/8.13.1) with ESMTP id p8FCejwZ027823; Thu, 15 Sep 2011 05:40:55 -0700 From: David Vrabel To: xen-devel@lists.xensource.com Date: Thu, 15 Sep 2011 13:40:10 +0100 Message-ID: <1316090411-22608-6-git-send-email-david.vrabel@citrix.com> X-Mailer: git-send-email 1.7.2.5 In-Reply-To: <1316090411-22608-1-git-send-email-david.vrabel@citrix.com> References: <1316090411-22608-1-git-send-email-david.vrabel@citrix.com> MIME-Version: 1.0 Content-Type: text/plain Cc: Andrew Morton , David Vrabel , linux-kernel@vger.kernel.org, Konrad Rzeszutek Wilk Subject: [Xen-devel] [PATCH 5/6] xen: xenbus: remove xenbus_map_ring_valloc() and xenbus_map_ring_vfree() X-BeenThere: xen-devel@lists.xensource.com X-Mailman-Version: 2.1.5 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xensource.com Errors-To: xen-devel-bounces@lists.xensource.com From: David Vrabel xenbus_map_ring_valloc() and xenbus_map_ring_vfree() are no longer used. Drivers should use xenbus_map_ring_page() instead. xenbus_map_ring() and xenbus_unmap_ring also have no users outside of the file and are made static. Signed-off-by: David Vrabel --- arch/ia64/xen/grant-table.c | 2 +- drivers/xen/xenbus/xenbus_client.c | 119 ++---------------------------------- include/xen/xenbus.h | 9 +--- 3 files changed, 7 insertions(+), 123 deletions(-) diff --git a/arch/ia64/xen/grant-table.c b/arch/ia64/xen/grant-table.c index 48cca37..4b72424 100644 --- a/arch/ia64/xen/grant-table.c +++ b/arch/ia64/xen/grant-table.c @@ -54,7 +54,7 @@ struct vm_struct *xen_alloc_vm_area(unsigned long size) area->size = size; area->pages = NULL; area->nr_pages = nr_pages; - area->phys_addr = 0; /* xenbus_map_ring_valloc uses this field! */ + area->phys_addr = 0; return area; diff --git a/drivers/xen/xenbus/xenbus_client.c b/drivers/xen/xenbus/xenbus_client.c index 504325b..3c64be8 100644 --- a/drivers/xen/xenbus/xenbus_client.c +++ b/drivers/xen/xenbus/xenbus_client.c @@ -419,58 +419,6 @@ int xenbus_free_evtchn(struct xenbus_device *dev, int port) } EXPORT_SYMBOL_GPL(xenbus_free_evtchn); - -/** - * xenbus_map_ring_valloc - * @dev: xenbus device - * @gnt_ref: grant reference - * @vaddr: pointer to address to be filled out by mapping - * - * Based on Rusty Russell's skeleton driver's map_page. - * Map a page of memory into this domain from another domain's grant table. - * xenbus_map_ring_valloc allocates a page of virtual address space, maps the - * page to that address, and sets *vaddr to that address. - * Returns 0 on success, and GNTST_* (see xen/include/interface/grant_table.h) - * or -ENOMEM on error. If an error is returned, device will switch to - * XenbusStateClosing and the error message will be saved in XenStore. - */ -int xenbus_map_ring_valloc(struct xenbus_device *dev, int gnt_ref, void **vaddr) -{ - struct gnttab_map_grant_ref op = { - .flags = GNTMAP_host_map, - .ref = gnt_ref, - .dom = dev->otherend_id, - }; - struct vm_struct *area; - - *vaddr = NULL; - - area = xen_alloc_vm_area(PAGE_SIZE); - if (!area) - return -ENOMEM; - - op.host_addr = (unsigned long)area->addr; - - if (HYPERVISOR_grant_table_op(GNTTABOP_map_grant_ref, &op, 1)) - BUG(); - - if (op.status != GNTST_okay) { - xen_free_vm_area(area); - xenbus_dev_fatal(dev, op.status, - "mapping in shared page %d from domain %d", - gnt_ref, dev->otherend_id); - return op.status; - } - - /* Stuff the handle in an unused field */ - area->phys_addr = (unsigned long)op.handle; - - *vaddr = area->addr; - return 0; -} -EXPORT_SYMBOL_GPL(xenbus_map_ring_valloc); - - /** * xenbus_map_ring * @dev: xenbus device @@ -485,8 +433,8 @@ EXPORT_SYMBOL_GPL(xenbus_map_ring_valloc); * or -ENOMEM on error. If an error is returned, device will switch to * XenbusStateClosing and the error message will be saved in XenStore. */ -int xenbus_map_ring(struct xenbus_device *dev, int gnt_ref, - grant_handle_t *handle, void *vaddr) +static int xenbus_map_ring(struct xenbus_device *dev, int gnt_ref, + grant_handle_t *handle, void *vaddr) { struct gnttab_map_grant_ref op = { .host_addr = (unsigned long)vaddr, @@ -502,13 +450,12 @@ int xenbus_map_ring(struct xenbus_device *dev, int gnt_ref, xenbus_dev_fatal(dev, op.status, "mapping in shared page %d from domain %d", gnt_ref, dev->otherend_id); + *handle = 0; } else *handle = op.handle; return op.status; } -EXPORT_SYMBOL_GPL(xenbus_map_ring); - /** * xenbus_map_ring_page - map a foreign page into a kernel page @@ -549,61 +496,6 @@ err: EXPORT_SYMBOL_GPL(xenbus_map_ring_page); /** - * xenbus_unmap_ring_vfree - * @dev: xenbus device - * @vaddr: addr to unmap - * - * Based on Rusty Russell's skeleton driver's unmap_page. - * Unmap a page of memory in this domain that was imported from another domain. - * Use xenbus_unmap_ring_vfree if you mapped in your memory with - * xenbus_map_ring_valloc (it will free the virtual address space). - * Returns 0 on success and returns GNTST_* on error - * (see xen/include/interface/grant_table.h). - */ -int xenbus_unmap_ring_vfree(struct xenbus_device *dev, void *vaddr) -{ - struct vm_struct *area; - struct gnttab_unmap_grant_ref op = { - .host_addr = (unsigned long)vaddr, - }; - - /* It'd be nice if linux/vmalloc.h provided a find_vm_area(void *addr) - * method so that we don't have to muck with vmalloc internals here. - * We could force the user to hang on to their struct vm_struct from - * xenbus_map_ring_valloc, but these 6 lines considerably simplify - * this API. - */ - read_lock(&vmlist_lock); - for (area = vmlist; area != NULL; area = area->next) { - if (area->addr == vaddr) - break; - } - read_unlock(&vmlist_lock); - - if (!area) { - xenbus_dev_error(dev, -ENOENT, - "can't find mapped virtual address %p", vaddr); - return GNTST_bad_virt_addr; - } - - op.handle = (grant_handle_t)area->phys_addr; - - if (HYPERVISOR_grant_table_op(GNTTABOP_unmap_grant_ref, &op, 1)) - BUG(); - - if (op.status == GNTST_okay) - xen_free_vm_area(area); - else - xenbus_dev_error(dev, op.status, - "unmapping page at handle %d error %d", - (int16_t)area->phys_addr, op.status); - - return op.status; -} -EXPORT_SYMBOL_GPL(xenbus_unmap_ring_vfree); - - -/** * xenbus_unmap_ring * @dev: xenbus device * @handle: grant handle @@ -613,8 +505,8 @@ EXPORT_SYMBOL_GPL(xenbus_unmap_ring_vfree); * Returns 0 on success and returns GNTST_* on error * (see xen/include/interface/grant_table.h). */ -int xenbus_unmap_ring(struct xenbus_device *dev, - grant_handle_t handle, void *vaddr) +static int xenbus_unmap_ring(struct xenbus_device *dev, + grant_handle_t handle, void *vaddr) { struct gnttab_unmap_grant_ref op = { .host_addr = (unsigned long)vaddr, @@ -631,7 +523,6 @@ int xenbus_unmap_ring(struct xenbus_device *dev, return op.status; } -EXPORT_SYMBOL_GPL(xenbus_unmap_ring); /** * xenbus_unmap_ring_page - unmap an foreign page from a kernel page diff --git a/include/xen/xenbus.h b/include/xen/xenbus.h index ebde2fd..d73d320 100644 --- a/include/xen/xenbus.h +++ b/include/xen/xenbus.h @@ -208,16 +208,9 @@ int xenbus_watch_pathfmt(struct xenbus_device *dev, struct xenbus_watch *watch, int xenbus_switch_state(struct xenbus_device *dev, enum xenbus_state new_state); int xenbus_grant_ring(struct xenbus_device *dev, unsigned long ring_mfn); -int xenbus_map_ring_valloc(struct xenbus_device *dev, - int gnt_ref, void **vaddr); -int xenbus_map_ring(struct xenbus_device *dev, int gnt_ref, - grant_handle_t *handle, void *vaddr); + int xenbus_map_ring_page(struct xenbus_device *dev, int gnt_ref, struct page **page); - -int xenbus_unmap_ring_vfree(struct xenbus_device *dev, void *vaddr); -int xenbus_unmap_ring(struct xenbus_device *dev, - grant_handle_t handle, void *vaddr); void xenbus_unmap_ring_page(struct xenbus_device *dev, struct page *page); int xenbus_alloc_evtchn(struct xenbus_device *dev, int *port); -- 1.7.2.5 _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel From xen-devel-bounces@lists.xensource.com Thu Sep 15 05:46:18 2011 Return-path: Envelope-to: www-data@lists.xensource.com Delivery-date: Thu, 15 Sep 2011 05:46:18 -0700 Received: from localhost ([127.0.0.1] helo=lists.colo.xensource.com) by lists.xensource.com with esmtp (Exim 4.43) id 1R4BKc-0003o9-PA; Thu, 15 Sep 2011 05:46:18 -0700 Received: from mail27.messagelabs.com ([193.109.254.147]) by lists.xensource.com with esmtp (Exim 4.43) id 1R4BFW-0001IC-8s for xen-devel@lists.xensource.com; Thu, 15 Sep 2011 05:41:02 -0700 X-Env-Sender: david.vrabel@citrix.com X-Msg-Ref: server-7.tower-27.messagelabs.com!1316090429!48777884!4 X-Originating-IP: [66.165.176.63] X-StarScan-Version: 6.4.1; banners=-,-,- X-VirusChecked: Checked Received: (qmail 32625 invoked from network); 15 Sep 2011 12:40:37 -0000 Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63) by server-7.tower-27.messagelabs.com with RC4-SHA encrypted SMTP; 15 Sep 2011 12:40:37 -0000 X-IronPort-AV: E=Sophos;i="4.68,387,1312171200"; d="scan'208";a="163268221" Received: from ftlpmailmx01.citrite.net ([10.13.107.65]) by FTLPIPO02.CITRIX.COM with ESMTP/TLS/RC4-MD5; 15 Sep 2011 08:40:58 -0400 Received: from smtp01.ad.xensource.com (10.219.128.104) by smtprelay.citrix.com (10.13.107.65) with Microsoft SMTP Server id 8.3.137.0; Thu, 15 Sep 2011 08:40:58 -0400 Received: from minsc.uk.xensource.com ([10.31.1.114]) by smtp01.ad.xensource.com (8.13.1/8.13.1) with ESMTP id p8FCejwa027823; Thu, 15 Sep 2011 05:40:57 -0700 From: David Vrabel To: xen-devel@lists.xensource.com Date: Thu, 15 Sep 2011 13:40:11 +0100 Message-ID: <1316090411-22608-7-git-send-email-david.vrabel@citrix.com> X-Mailer: git-send-email 1.7.2.5 In-Reply-To: <1316090411-22608-1-git-send-email-david.vrabel@citrix.com> References: <1316090411-22608-1-git-send-email-david.vrabel@citrix.com> MIME-Version: 1.0 Content-Type: text/plain Cc: Andrew Morton , David Vrabel , linux-kernel@vger.kernel.org, Konrad Rzeszutek Wilk Subject: [Xen-devel] [PATCH 6/6] mm: remove vmalloc_sync_all() from alloc_vm_area() X-BeenThere: xen-devel@lists.xensource.com X-Mailman-Version: 2.1.5 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xensource.com Errors-To: xen-devel-bounces@lists.xensource.com From: David Vrabel The address space allocated by the remaining user of alloc_vm_area() is not accessed during a hypercall. Therefore, the normal mechanism of populating the vmalloc page tables during a fault works so the vmalloc_sync_all() is not required and it can be removed. Signed-off-by: David Vrabel Cc: Andrew Morton --- mm/vmalloc.c | 12 +----------- 1 files changed, 1 insertions(+), 11 deletions(-) diff --git a/mm/vmalloc.c b/mm/vmalloc.c index 5016f19..b0b4550 100644 --- a/mm/vmalloc.c +++ b/mm/vmalloc.c @@ -2117,9 +2117,7 @@ static int f(pte_t *pte, pgtable_t table, unsigned long addr, void *data) * * This function reserves a range of kernel address space, and * allocates pagetables to map that range. No actual mappings - * are created. If the kernel address space is not shared - * between processes, it syncs the pagetable across all - * processes. + * are created. */ struct vm_struct *alloc_vm_area(size_t size) { @@ -2140,14 +2138,6 @@ struct vm_struct *alloc_vm_area(size_t size) return NULL; } - /* - * If the allocated address space is passed to a hypercall - * before being used then we cannot rely on a page fault to - * trigger an update of the page tables. So sync all the page - * tables here. - */ - vmalloc_sync_all(); - return area; } EXPORT_SYMBOL_GPL(alloc_vm_area); -- 1.7.2.5 _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel From xen-devel-bounces@lists.xensource.com Thu Sep 15 06:06:39 2011 Return-path: Envelope-to: www-data@lists.xensource.com Delivery-date: Thu, 15 Sep 2011 06:06:39 -0700 Received: from localhost ([127.0.0.1] helo=lists.colo.xensource.com) by lists.xensource.com with esmtp (Exim 4.43) id 1R4BeI-0004W0-NW; Thu, 15 Sep 2011 06:06:38 -0700 Received: from mail174.messagelabs.com ([85.158.138.51]) by lists.xensource.com with esmtp (Exim 4.43) id 1R4Bbo-0004Gi-8q for xen-devel@lists.xensource.com; Thu, 15 Sep 2011 06:04:45 -0700 X-Env-Sender: royger@gmail.com X-Msg-Ref: server-8.tower-174.messagelabs.com!1316091835!17853827!1 X-Originating-IP: [209.85.215.42] X-StarScan-Version: 6.4.1; banners=-,-,- X-VirusChecked: Checked Received: (qmail 21004 invoked from network); 15 Sep 2011 13:04:00 -0000 Received: from mail-ew0-f42.google.com (HELO mail-ew0-f42.google.com) (209.85.215.42) by server-8.tower-174.messagelabs.com with RC4-SHA encrypted SMTP; 15 Sep 2011 13:04:00 -0000 Received: by ewy2 with SMTP id 2so1827262ewy.29 for ; Thu, 15 Sep 2011 06:03:54 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=sender:content-type:mime-version:content-transfer-encoding:subject :x-mercurial-node:message-id:user-agent:date:from:to; bh=rOWxgpar6VFGj05NWLiIgkTUC04PkA75VPbC4JxjPU4=; b=WqTtIkeJyNDwPk8pIs+ZBKobELIt35/WpNnKHNNEUPfioOcRJ3dSlJO1G/W3YqTFqK tiJLNpIyTaCjFBfjWe7dolbnG8EcNqVcSC6+L43idCTFzYAwwXFGE1UOdm6/uBKsoA9V JRFw6KUDC+3mm6fsxkdhZVe0qeuVX6p2BQ0UQ= Received: by 10.216.184.132 with SMTP id s4mr20951wem.41.1316091834303; Thu, 15 Sep 2011 06:03:54 -0700 (PDT) Received: from [127.0.0.1] (monk.upc.es. [147.83.39.235]) by mx.google.com with ESMTPS id fq9sm7782702wbb.15.2011.09.15.06.03.52 (version=TLSv1/SSLv3 cipher=OTHER); Thu, 15 Sep 2011 06:03:53 -0700 (PDT) Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Mercurial-Node: 015617579cd36fc58318aaf350bec5f7cc07ef2f Message-Id: <015617579cd36fc58318.1316091805@loki> User-Agent: Mercurial-patchbomb/1.8.4 Date: Thu, 15 Sep 2011 15:03:25 +0200 From: Roger Pau Monne To: xen-devel@lists.xensource.com Subject: [Xen-devel] [PATCH] libxl: add support for booting PV domains from NetBSD using raw files as disks. Fixed the shutdown race problem by checking "hotplug-status" instead of "state" xenstore variable in NetBSD X-BeenThere: xen-devel@lists.xensource.com X-Mailman-Version: 2.1.5 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xensource.com Errors-To: xen-devel-bounces@lists.xensource.com # HG changeset patch # User Roger Pau Monne # Date 1316091721 -7200 # Node ID 015617579cd36fc58318aaf350bec5f7cc07ef2f # Parent 63e254468d6e8d81baeafaed68f05791dc21eb4e libxl: add support for booting PV domains from NetBSD using raw files as disks. Fixed the shutdown race problem by checking "hotplug-status" instead of "state" xenstore variable in NetBSD. Signed-off-by: Roger Pau Monne diff -r 63e254468d6e -r 015617579cd3 tools/hotplug/NetBSD/block --- a/tools/hotplug/NetBSD/block Wed Sep 14 14:18:40 2011 +0200 +++ b/tools/hotplug/NetBSD/block Thu Sep 15 15:02:01 2011 +0200 @@ -19,7 +19,7 @@ error() { xpath=$1 xstatus=$2 -xtype=$(xenstore-read "$xpath/type") +xtype=$3 xparams=$(xenstore-read "$xpath/params") case $xstatus in @@ -38,6 +38,8 @@ 6) echo "unknown type $xtype" >&2 ;; esac + echo xenstore-write $xpath/hotplug-status disconnected + xenstore-write $xpath/hotplug-status disconnected xenstore-rm $xpath exit 0 ;; diff -r 63e254468d6e -r 015617579cd3 tools/libxl/libxl_device.c --- a/tools/libxl/libxl_device.c Wed Sep 14 14:18:40 2011 +0200 +++ b/tools/libxl/libxl_device.c Thu Sep 15 15:02:01 2011 +0200 @@ -136,15 +136,20 @@ static int disk_try_backend(disk_try_bac a->disk->format == LIBXL_DISK_FORMAT_EMPTY)) { goto bad_format; } - if (a->disk->format != LIBXL_DISK_FORMAT_EMPTY && - !S_ISBLK(a->stab.st_mode)) { - LIBXL__LOG(ctx, LIBXL__LOG_DEBUG, "Disk vdev=%s, backend phy" - " unsuitable as phys path not a block device", - a->disk->vdev); - return 0; - } - - return backend; + if (S_ISBLK(a->stab.st_mode)) + return backend; +#ifdef HAVE_PHY_BACKEND_FILE_SUPPORT + if (S_ISREG(a->stab.st_mode)) + return backend; + LIBXL__LOG(ctx, LIBXL__LOG_DEBUG, "Disk vdev=%s, backend phy" + " unsuitable as phys path not a block device or" + " raw image", a->disk->vdev); +#else + LIBXL__LOG(ctx, LIBXL__LOG_DEBUG, "Disk vdev=%s, backend phy" + " unsuitable as phys path not a block device", + a->disk->vdev); +#endif + return 0; case LIBXL_DISK_BACKEND_TAP: if (!libxl__blktap_enabled(a->gc)) { @@ -366,16 +371,35 @@ int libxl__device_destroy(libxl__gc *gc, libxl_ctx *ctx = libxl__gc_owner(gc); xs_transaction_t t; char *state_path = libxl__sprintf(gc, "%s/state", be_path); + char *hotplug_path = libxl__sprintf(gc, "%s/hotplug-status", be_path); char *state = libxl__xs_read(gc, XBT_NULL, state_path); + char *hotplug = libxl__xs_read(gc, XBT_NULL, hotplug_path); int rc = 0; if (!state) goto out; + +#ifdef HAVE_PHY_BACKEND_FILE_SUPPORT + if (!strstr(be_path, "vbd")) { + if (atoi(state) != 4) { + xs_rm(ctx->xsh, XBT_NULL, be_path); + goto out; + } + } else { + if (!hotplug) + goto out; + if (!strcmp(hotplug, "disconnected")) { + xs_rm(ctx->xsh, XBT_NULL, be_path); + goto out; + } + } +#else if (atoi(state) != 4) { xs_rm(ctx->xsh, XBT_NULL, be_path); goto out; } - +#endif + retry_transaction: t = xs_transaction_start(ctx->xsh); xs_write(ctx->xsh, t, libxl__sprintf(gc, "%s/online", be_path), "0", strlen("0")); @@ -389,6 +413,13 @@ retry_transaction: } } if (!force) { +#ifdef HAVE_PHY_BACKEND_FILE_SUPPORT + if (strstr(be_path, "vbd")) { + xs_watch(ctx->xsh, hotplug_path, be_path); + rc = 1; + goto out; + } +#endif xs_watch(ctx->xsh, state_path, be_path); rc = 1; } else { @@ -405,6 +436,7 @@ static int wait_for_dev_destroy(libxl__g unsigned int n; fd_set rfds; char **l1 = NULL; + char *state, *hotplug; rc = 1; nfds = xs_fileno(ctx->xsh) + 1; @@ -413,7 +445,21 @@ static int wait_for_dev_destroy(libxl__g if (select(nfds, &rfds, NULL, NULL, tv) > 0) { l1 = xs_read_watch(ctx->xsh, &n); if (l1 != NULL) { - char *state = libxl__xs_read(gc, XBT_NULL, l1[XS_WATCH_PATH]); +#ifdef HAVE_PHY_BACKEND_FILE_SUPPORT + if (strstr(l1[XS_WATCH_PATH], "hotplug-status")) { + hotplug = libxl__xs_read(gc, XBT_NULL, l1[XS_WATCH_PATH]); + if (!hotplug || strcmp(hotplug, "disconnected") == 0) { + xs_unwatch(ctx->xsh, l1[0], l1[1]); + xs_rm(ctx->xsh, XBT_NULL, l1[XS_WATCH_TOKEN]); + LIBXL__LOG(ctx, LIBXL__LOG_DEBUG, "Destroyed device backend at %s hotplug-status: %s", + l1[XS_WATCH_TOKEN], hotplug); + rc = 0; + } + free(l1); + return rc; + } +#endif + state = libxl__xs_read(gc, XBT_NULL, l1[XS_WATCH_PATH]); if (!state || atoi(state) == 6) { xs_unwatch(ctx->xsh, l1[0], l1[1]); xs_rm(ctx->xsh, XBT_NULL, l1[XS_WATCH_TOKEN]); @@ -422,6 +468,9 @@ static int wait_for_dev_destroy(libxl__g } free(l1); } + } else { + /* timeout reached */ + rc = 0; } return rc; } @@ -482,7 +531,7 @@ int libxl__devices_destroy(libxl__gc *gc tv.tv_usec = 0; while (n_watches > 0) { if (wait_for_dev_destroy(gc, &tv)) { - break; + continue; } else { n_watches--; } diff -r 63e254468d6e -r 015617579cd3 tools/libxl/libxl_osdeps.h --- a/tools/libxl/libxl_osdeps.h Wed Sep 14 14:18:40 2011 +0200 +++ b/tools/libxl/libxl_osdeps.h Thu Sep 15 15:02:01 2011 +0200 @@ -25,6 +25,7 @@ #if defined(__NetBSD__) || defined(__OpenBSD__) #include +#define HAVE_PHY_BACKEND_FILE_SUPPORT #elif defined(__linux__) #include #elif defined(__sun__) diff -r 63e254468d6e -r 015617579cd3 tools/xenbackendd/xenbackendd.c --- a/tools/xenbackendd/xenbackendd.c Wed Sep 14 14:18:40 2011 +0200 +++ b/tools/xenbackendd/xenbackendd.c Thu Sep 15 15:02:01 2011 +0200 @@ -89,15 +89,15 @@ dodebug(const char *fmt, ...) } static void -doexec(const char *cmd, const char *arg1, const char *arg2) +doexec(const char *cmd, const char *arg1, const char *arg2, const char *arg3) { - dodebug("exec %s %s %s", cmd, arg1, arg2); + dodebug("exec %s %s %s %s", cmd, arg1, arg2, arg3); switch(vfork()) { case -1: dolog(LOG_ERR, "can't vfork: %s", strerror(errno)); break; case 0: - execl(cmd, cmd, arg1, arg2, NULL); + execl(cmd, cmd, arg1, arg2, arg3, NULL); dolog(LOG_ERR, "can't exec %s: %s", cmd, strerror(errno)); exit(EXIT_FAILURE); /* NOTREACHED */ @@ -145,11 +145,14 @@ xen_setup(void) int main(int argc, char * const argv[]) { + struct stat stab; char **vec; unsigned int num; char *s; int state; char *sstate; + char *stype; + char *params; char *p; char buf[80]; int type; @@ -169,7 +172,7 @@ main(int argc, char * const argv[]) log_file = optarg; break; case 'p': - pidfile = pidfile; + pidfile = optarg; case 's': vbd_script = optarg; break; @@ -297,11 +300,38 @@ main(int argc, char * const argv[]) strerror(errno)); goto next2; } - doexec(s, vec[XS_WATCH_PATH], sstate); + doexec(s, vec[XS_WATCH_PATH], sstate, NULL); break; case DEVTYPE_VBD: - doexec(vbd_script, vec[XS_WATCH_PATH], sstate); + /* check if given file is a block device or a raw image */ + snprintf(buf, sizeof(buf), "%s/params", vec[XS_WATCH_PATH]); + params = xs_read(xs, XBT_NULL, buf, 0); + if(params == NULL) { + dolog(LOG_ERR, + "Failed to read %s (%s)", buf, strerror(errno)); + goto next2; + } + if (stat(params, &stab) < 0) { + dolog(LOG_ERR, + "Failed to get info about %s (%s)", params, + strerror(errno)); + goto next3; + } + stype = NULL; + if (S_ISBLK(stab.st_mode)) + stype = "phy"; + if (S_ISREG(stab.st_mode)) + stype = "file"; + if (stype == NULL) { + dolog(LOG_ERR, + "Failed to attach %s (not a block device or raw image)", + params, strerror(errno)); + goto next3; + } + doexec(vbd_script, vec[XS_WATCH_PATH], sstate, stype); +next3: + free(params); break; default: _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel From xen-devel-bounces@lists.xensource.com Thu Sep 15 06:19:49 2011 Return-path: Envelope-to: www-data@lists.xensource.com Delivery-date: Thu, 15 Sep 2011 06:19:49 -0700 Received: from localhost ([127.0.0.1] helo=lists.colo.xensource.com) by lists.xensource.com with esmtp (Exim 4.43) id 1R4Br3-00059L-Ru; Thu, 15 Sep 2011 06:19:49 -0700 Received: from mail27.messagelabs.com ([193.109.254.147]) by lists.xensource.com with esmtp (Exim 4.43) id 1R4Bq7-0004vP-Kg for xen-devel@lists.xensource.com; Thu, 15 Sep 2011 06:18:53 -0700 X-Env-Sender: adi@cg.tuwien.ac.at X-Msg-Ref: server-15.tower-27.messagelabs.com!1316092719!48898961!1 X-Originating-IP: [213.129.229.198] X-StarScan-Version: 6.4.1; banners=-,-,- X-VirusChecked: Checked Received: (qmail 24760 invoked from network); 15 Sep 2011 13:18:40 -0000 Received: from vrvis-198.vrvis.at (HELO iris.vrvis.at) (213.129.229.198) by server-15.tower-27.messagelabs.com with AES256-SHA encrypted SMTP; 15 Sep 2011 13:18:40 -0000 Received: from actoris.vrvis.lan ([10.42.1.75] helo=vrvis.at) by iris.vrvis.at with esmtpsa (TLS1.0:DHE_RSA_AES_128_CBC_SHA1:16) (Exim 4.72) (envelope-from ) id 1R4Bpr-0000jy-Fe; Thu, 15 Sep 2011 15:18:35 +0200 Date: Thu, 15 Sep 2011 15:18:31 +0200 From: Adi Kriegisch To: Konrad Rzeszutek Wilk Subject: Re: [Xen-devel] Re: Dom0 ACPI S3 patches Message-ID: <20110915131831.GA7204@vrvis.at> References: <20110914081156.GB3079@vrvis.at> <20110914102112.GB15866@phenom.oracle.com> <20110914112718.GG3079@vrvis.at> <20110914142854.GB16956@phenom.oracle.com> <20110914150934.GK3079@vrvis.at> <20110914154726.GA18810@phenom.oracle.com> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline In-Reply-To: <20110914154726.GA18810@phenom.oracle.com> User-Agent: Mutt/1.5.20 (2009-06-14) X-SA-Exim-Connect-IP: 10.42.1.75 X-SA-Exim-Mail-From: adi@cg.tuwien.ac.at X-SA-Exim-Scanned: No (on iris.vrvis.at); SAEximRunCond expanded to false Cc: xen-devel@lists.xensource.com, Adi Kriegisch X-BeenThere: xen-devel@lists.xensource.com X-Mailman-Version: 2.1.5 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xensource.com Errors-To: xen-devel-bounces@lists.xensource.com On Wed, Sep 14, 2011 at 11:47:26AM -0400, Konrad Rzeszutek Wilk wrote: > On Wed, Sep 14, 2011 at 05:09:34PM +0200, Adi Kriegisch wrote: > > On Wed, Sep 14, 2011 at 10:28:54AM -0400, Konrad Rzeszutek Wilk wrote: > > > > > Excellent. Is it OK if I put 'Tested-by: Adi Kriegish" on them? > > > > Sure, go ahead! ;-) Now, I think, you may really go ahead! ;-) 'nopat' did the trick for me. > > > Hmmm.. I wonder if you are hitting the writecombine issue I've seen sometimes. > > > Just to eliminate it, can you try 'nopat' on the Linux command line? > > Sure. Do you know any way to make sure I am hitting the writecombine issue > > fast, so that I can make (kind of) sure everything is working? > Mysterious applications crashing left and right. Under my box bash stopped > working right and such. Pretty obvious that something went wrong. Hmmm... I rethought the workloads I had and found a way to reproduce the crashes -- more or less reliably: As I did a complete reinstallation of my notebook, I had a lot of data to copy. The first bunch of sutff was copied on Dom0 -- this was where I experienced the crashes; not immediately while copying but a little later (The warnings in the syslog always happened during copying, btw). Then -- after I basic setup was done -- I used xm block-attach and copied tons of stuff within a DomU. I did not experience a single crash while doing so. Do you want me to do something to further debug the issue? Just tell me what I could/should try to do! ;-) > > > > > http://lists.xensource.com/archives/html/xen-devel/2010-02/msg00469.html > > > > Sounds like it could be related. Shall I apply that patch? If so, which > > > > hook takes care that the function is called? [SNIP] > > It does not apply at all: > > Pfff.. well, I will try to rebase it in a couple of days. Can you ping in a week > if I haven't sent anything to you yet? Yes, I will! ;-) -- Adi _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel From xen-devel-bounces@lists.xensource.com Thu Sep 15 06:33:55 2011 Return-path: Envelope-to: www-data@lists.xensource.com Delivery-date: Thu, 15 Sep 2011 06:33:55 -0700 Received: from localhost ([127.0.0.1] helo=lists.colo.xensource.com) by lists.xensource.com with esmtp (Exim 4.43) id 1R4C4h-0005pT-Jd; Thu, 15 Sep 2011 06:33:55 -0700 Received: from mail216.messagelabs.com ([85.158.143.99]) by lists.xensource.com with esmtp (Exim 4.43) id 1R4C42-0005ce-U0 for xen-devel@lists.xensource.com; Thu, 15 Sep 2011 06:33:15 -0700 X-Env-Sender: pasik@iki.fi X-Msg-Ref: server-11.tower-216.messagelabs.com!1316093591!10810547!1 X-Originating-IP: [192.89.123.25] X-StarScan-Version: 6.4.1; banners=-,-,- X-VirusChecked: Checked Received: (qmail 10058 invoked from network); 15 Sep 2011 13:33:11 -0000 Received: from smtp.tele.fi (HELO smtp.tele.fi) (192.89.123.25) by server-11.tower-216.messagelabs.com with DHE-RSA-AES256-SHA encrypted SMTP; 15 Sep 2011 13:33:11 -0000 X-Originating-Ip: [194.89.68.22] Received: from ydin.reaktio.net (reaktio.net [194.89.68.22]) by smtp.tele.fi (Postfix) with ESMTP id F38621CFA; Thu, 15 Sep 2011 16:33:09 +0300 (EEST) Received: by ydin.reaktio.net (Postfix, from userid 1001) id B7A3E200E5; Thu, 15 Sep 2011 16:33:09 +0300 (EEST) Date: Thu, 15 Sep 2011 16:33:09 +0300 From: Pasi =?iso-8859-1?Q?K=E4rkk=E4inen?= To: Moritz =?iso-8859-1?Q?M=FChlenhoff?= Subject: Re: [Xen-devel] Several issues with Xen 4.1.1 regarding Windows guests (and more...) Message-ID: <20110915133309.GV12984@reaktio.net> References: <1315951748.7224.5.camel@kali.ninth-art.net> <20110914150635.GA18147@phenom.oracle.com> <201109151150.57836.muehlenhoff@univention.de> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <201109151150.57836.muehlenhoff@univention.de> User-Agent: Mutt/1.5.18 (2008-05-17) Cc: Stefano Stabellini , xen-devel@lists.xensource.com, "therion@ninth-art.de" , Nathan March , Konrad Rzeszutek Wilk X-BeenThere: xen-devel@lists.xensource.com X-Mailman-Version: 2.1.5 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xensource.com Errors-To: xen-devel-bounces@lists.xensource.com On Thu, Sep 15, 2011 at 11:50:57AM +0200, Moritz Mühlenhoff wrote: > Stefano Stabellini wrote: > > > > > On win2008 I install the OS, do a "bcedit /set testsigning on", > > > > reboot, then install the gplpv. > > > > > > Or you can installed the signed versions: > > > > > > http://marc.info/?i=201109090950.05043.muehlenhoff@univention.de > > > > we should add them to the wiki > > It's probably easiest if you just place a link to this web page: > http://wiki.univention.de/index.php?title=Installing-signed-GPLPV-drivers > > We'll keep this page updated for new installation hints, updated driver builds > etc. > Ok, will do.. I have some other stuff to fix first, so I'll try to clean up the gplpv stuff next week or so. -- Pasi _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel From xen-devel-bounces@lists.xensource.com Thu Sep 15 06:42:33 2011 Return-path: Envelope-to: www-data@lists.xensource.com Delivery-date: Thu, 15 Sep 2011 06:42:33 -0700 Received: from localhost ([127.0.0.1] helo=lists.colo.xensource.com) by lists.xensource.com with esmtp (Exim 4.43) id 1R4CD3-0006KH-Qh; Thu, 15 Sep 2011 06:42:33 -0700 Received: from mail174.messagelabs.com ([85.158.138.51]) by lists.xensource.com with esmtp (Exim 4.43) id 1R4CCc-000684-Gv for xen-devel@lists.xensource.com; Thu, 15 Sep 2011 06:42:06 -0700 X-Env-Sender: Ian.Campbell@eu.citrix.com X-Msg-Ref: server-4.tower-174.messagelabs.com!1316094119!31559128!1 X-Originating-IP: [66.165.176.89] X-StarScan-Version: 6.4.1; banners=-,-,- X-VirusChecked: Checked Received: (qmail 30306 invoked from network); 15 Sep 2011 13:42:02 -0000 Received: from smtp.citrix.com (HELO SMTP.CITRIX.COM) (66.165.176.89) by server-4.tower-174.messagelabs.com with RC4-SHA encrypted SMTP; 15 Sep 2011 13:42:02 -0000 X-IronPort-AV: E=Sophos;i="4.68,387,1312171200"; d="scan'208";a="17251617" Received: from ftlpmailmx02.citrite.net ([10.13.107.66]) by FTLPIPO01.CITRIX.COM with ESMTP/TLS/RC4-MD5; 15 Sep 2011 09:41:58 -0400 Received: from [127.0.0.1] (10.80.16.67) by smtprelay.citrix.com (10.13.107.66) with Microsoft SMTP Server id 8.3.137.0; Thu, 15 Sep 2011 09:41:57 -0400 Subject: Re: [Xen-devel] [PATCH] libxl: add support for booting PV domains from NetBSD using raw files as disks. Fixed the shutdown race problem by checking "hotplug-status" instead of "state" xenstore variable in NetBSD From: Ian Campbell To: Roger Pau Monne Date: Thu, 15 Sep 2011 15:41:56 +0200 In-Reply-To: <015617579cd36fc58318.1316091805@loki> References: <015617579cd36fc58318.1316091805@loki> Organization: Citrix Systems, Inc. Content-Type: text/plain; charset="UTF-8" X-Mailer: Evolution 3.0.3- Content-Transfer-Encoding: 7bit Message-ID: <1316094117.26990.8.camel@cthulhu.hellion.org.uk> MIME-Version: 1.0 Cc: "xen-devel@lists.xensource.com" X-BeenThere: xen-devel@lists.xensource.com X-Mailman-Version: 2.1.5 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xensource.com Errors-To: xen-devel-bounces@lists.xensource.com On Thu, 2011-09-15 at 09:03 -0400, Roger Pau Monne wrote: > # HG changeset patch > # User Roger Pau Monne > # Date 1316091721 -7200 > # Node ID 015617579cd36fc58318aaf350bec5f7cc07ef2f > # Parent 63e254468d6e8d81baeafaed68f05791dc21eb4e > libxl: add support for booting PV domains from NetBSD using raw files > as disks. Fixed the shutdown race problem by checking "hotplug-status" > instead of "state" xenstore variable in NetBSD. This was one long line which mercurial will use as a summary, it's a good idea to make sure that the first line stands somewhat alone as a summary so the e.g. "hg log" is useful. Also this sounds on the face of it like two bugfixes, if that's the case they should be submitted separately. > > Signed-off-by: Roger Pau Monne > > diff -r 63e254468d6e -r 015617579cd3 tools/hotplug/NetBSD/block > --- a/tools/hotplug/NetBSD/block Wed Sep 14 14:18:40 2011 +0200 > +++ b/tools/hotplug/NetBSD/block Thu Sep 15 15:02:01 2011 +0200 > @@ -19,7 +19,7 @@ error() { > > xpath=$1 > xstatus=$2 > -xtype=$(xenstore-read "$xpath/type") > +xtype=$3 > xparams=$(xenstore-read "$xpath/params") > > case $xstatus in > @@ -38,6 +38,8 @@ 6) > echo "unknown type $xtype" >&2 > ;; > esac > + echo xenstore-write $xpath/hotplug-status disconnected leftover debugging? > + xenstore-write $xpath/hotplug-status disconnected > xenstore-rm $xpath > exit 0 > ;; > libxl_ctx *ctx = libxl__gc_owner(gc); > xs_transaction_t t; > char *state_path = libxl__sprintf(gc, "%s/state", be_path); > + char *hotplug_path = libxl__sprintf(gc, "%s/hotplug-status", be_path); > char *state = libxl__xs_read(gc, XBT_NULL, state_path); > + char *hotplug = libxl__xs_read(gc, XBT_NULL, hotplug_path); > int rc = 0; > > if (!state) > goto out; > + > +#ifdef HAVE_PHY_BACKEND_FILE_SUPPORT > + if (!strstr(be_path, "vbd")) { > + if (atoi(state) != 4) { > + xs_rm(ctx->xsh, XBT_NULL, be_path); > + goto out; > + } > + } else { > + if (!hotplug) > + goto out; > + if (!strcmp(hotplug, "disconnected")) { > + xs_rm(ctx->xsh, XBT_NULL, be_path); > + goto out; > + } > + } Do the other backend types also write this node? It looks like Linux does, at least in some circumstances (tap and vbd AFAICT), in which case perhaps this is suitable as the only test here (i.e. drop the #ifdef and the #else case). That would remove a lot of the conditional code in this patch. Ian. _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel From xen-devel-bounces@lists.xensource.com Thu Sep 15 07:21:19 2011 Return-path: Envelope-to: www-data@lists.xensource.com Delivery-date: Thu, 15 Sep 2011 07:21:19 -0700 Received: from localhost ([127.0.0.1] helo=lists.colo.xensource.com) by lists.xensource.com with esmtp (Exim 4.43) id 1R4CoY-0007Km-B5; Thu, 15 Sep 2011 07:21:18 -0700 Received: from mail174.messagelabs.com ([85.158.138.51]) by lists.xensource.com with esmtp (Exim 4.43) id 1R4CnS-000782-Ut for xen-devel@lists.xensource.com; Thu, 15 Sep 2011 07:20:16 -0700 X-Env-Sender: Paul.Durrant@citrix.com X-Msg-Ref: server-14.tower-174.messagelabs.com!1316096401!31548176!1 X-Originating-IP: [62.200.22.115] X-StarScan-Version: 6.4.1; banners=-,-,- X-VirusChecked: Checked Received: (qmail 8191 invoked from network); 15 Sep 2011 14:20:06 -0000 Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115) by server-14.tower-174.messagelabs.com with RC4-SHA encrypted SMTP; 15 Sep 2011 14:20:06 -0000 X-IronPort-AV: E=Sophos;i="4.68,387,1312156800"; d="scan'208";a="7859915" Received: from lonpmailmx01.citrite.net ([10.30.203.162]) by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5; 15 Sep 2011 14:19:26 +0000 Received: from LONPMAILBOX01.citrite.net ([10.30.224.160]) by LONPMAILMX01.citrite.net ([10.30.203.162]) with mapi; Thu, 15 Sep 2011 15:19:26 +0100 From: Paul Durrant To: Keir Fraser , "xen-devel@lists.xensource.com" Date: Thu, 15 Sep 2011 15:19:30 +0100 Subject: RE: [Xen-devel] [PATCH] Tidy up the viridian code a little and flesh out the APIC assist MSR Thread-Topic: [Xen-devel] [PATCH] Tidy up the viridian code a little and flesh out the APIC assist MSR Thread-Index: AcxzcgONtakPWFHMdk29U12pniwCEwAQBjXQ Message-ID: <291EDFCB1E9E224A99088639C4762022B44F04717B@LONPMAILBOX01.citrite.net> References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: X-BeenThere: xen-devel@lists.xensource.com X-Mailman-Version: 2.1.5 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xensource.com Errors-To: xen-devel-bounces@lists.xensource.com Good point. I guess I may need to explicitly save/restore the apic assist p= fn. I'll check. Paul > -----Original Message----- > From: Keir Fraser [mailto:keir.xen@gmail.com] > Sent: 14 September 2011 23:38 > To: Paul Durrant; xen-devel@lists.xensource.com > Subject: Re: [Xen-devel] [PATCH] Tidy up the viridian code a little > and flesh out the APIC assist MSR >=20 > On 15/09/2011 06:13, "Paul Durrant" wrote: >=20 > > # HG changeset patch > > # User Paul Durrant # Date 1316063461 - > 3600 > > # Node ID a08073c5cf28ab76893102cc7a8d20bf3e5e15ae > > # Parent e90438f6e6d1585a71b18784a99c162b5d95f390 > > Tidy up the viridian code a little and flesh out the APIC assist > MSR > > handling code. > > > > We don't say we that handle that MSR but Windows assumes it. In > > Windows 7 it just wrote to the MSR and we used to handle that ok. > > Windows 8 also reads from the MSR so we need to keep a record of > the contents. >=20 > Does this work properly across save/restore? >=20 > -- Keir >=20 > > Signed-off-by: Paul Durrant > > > > diff -r e90438f6e6d1 -r a08073c5cf28 xen/arch/x86/hvm/viridian.c > > --- a/xen/arch/x86/hvm/viridian.c Wed Sep 14 11:38:13 2011 +0100 > > +++ b/xen/arch/x86/hvm/viridian.c Thu Sep 15 06:11:01 2011 +0100 > > @@ -96,9 +96,43 @@ int cpuid_viridian_leaves(unsigned int l > > return 1; > > } > > > > -static void enable_hypercall_page(void) > > +void dump_guest_os_id(struct domain *d) > > { > > - struct domain *d =3D current->domain; > > + gdprintk(XENLOG_INFO, "GUEST_OS_ID:\n"); > > + gdprintk(XENLOG_INFO, "\tvendor: %x\n", > > + d- > >arch.hvm_domain.viridian.guest_os_id.fields.vendor); > > + gdprintk(XENLOG_INFO, "\tos: %x\n", > > + d->arch.hvm_domain.viridian.guest_os_id.fields.os); > > + gdprintk(XENLOG_INFO, "\tmajor: %x\n", > > + d- > >arch.hvm_domain.viridian.guest_os_id.fields.major); > > + gdprintk(XENLOG_INFO, "\tminor: %x\n", > > + d- > >arch.hvm_domain.viridian.guest_os_id.fields.minor); > > + gdprintk(XENLOG_INFO, "\tsp: %x\n", > > + d- > >arch.hvm_domain.viridian.guest_os_id.fields.service_pack); > > + gdprintk(XENLOG_INFO, "\tbuild: %x\n", > > + > > +d->arch.hvm_domain.viridian.guest_os_id.fields.build_number); > > +} > > + > > +void dump_hypercall(struct domain *d) { > > + gdprintk(XENLOG_INFO, "HYPERCALL:\n"); > > + gdprintk(XENLOG_INFO, "\tenabled: %x\n", > > + d- > >arch.hvm_domain.viridian.hypercall_gpa.fields.enabled); > > + gdprintk(XENLOG_INFO, "\tpfn: %lx\n", > > + (unsigned > > long)d->arch.hvm_domain.viridian.hypercall_gpa.fields.pfn); > > +} > > + > > +void dump_apic_assist(struct vcpu *v) { > > + gdprintk(XENLOG_INFO, "APIC_ASSIST[%d]:\n", v->vcpu_id); > > + gdprintk(XENLOG_INFO, "\tenabled: %x\n", > > + v- > >arch.hvm_vcpu.viridian.apic_assist.fields.enabled); > > + gdprintk(XENLOG_INFO, "\tpfn: %lx\n", > > + (unsigned > > +long)v->arch.hvm_vcpu.viridian.apic_assist.fields.pfn); > > +} > > + > > +static void enable_hypercall_page(struct domain *d) { > > unsigned long gmfn =3D > > d->arch.hvm_domain.viridian.hypercall_gpa.fields.pfn; > > unsigned long mfn =3D gmfn_to_mfn(d, gmfn); > > uint8_t *p; > > @@ -130,9 +164,43 @@ static void enable_hypercall_page(void) > > put_page_and_type(mfn_to_page(mfn)); > > } > > > > +void initialize_apic_assist(struct vcpu *v) { > > + struct domain *d =3D v->domain; > > + unsigned long gmfn =3D v- > >arch.hvm_vcpu.viridian.apic_assist.fields.pfn; > > + unsigned long mfn =3D gmfn_to_mfn(d, gmfn); > > + uint8_t *p; > > + > > + /* > > + * We don't support the APIC assist page, and that fact is > reflected in > > + * our CPUID flags. However, Newer versions of Windows have a > bug which > > + * means that they don't recognise that, and tries to use the > page > > + * anyway. We therefore have to fake up just enough to keep > > + windows > > happy. > > + * > > + * See > > + http://msdn.microsoft.com/en-us/library/ff538657%28VS.85%29.aspx > > for > > + * details of how Windows uses the page. > > + */ > > + > > + if ( !mfn_valid(mfn) || > > + !get_page_and_type(mfn_to_page(mfn), d, > PGT_writable_page) ) > > + { > > + gdprintk(XENLOG_WARNING, "Bad GMFN %lx (MFN %lx)\n", > gmfn, mfn); > > + return; > > + } > > + > > + p =3D map_domain_page(mfn); > > + > > + *(u32 *)p =3D 0; > > + > > + unmap_domain_page(p); > > + > > + put_page_and_type(mfn_to_page(mfn)); > > +} > > + > > int wrmsr_viridian_regs(uint32_t idx, uint64_t val) { > > - struct domain *d =3D current->domain; > > + struct vcpu *v =3D current; > > + struct domain *d =3D v->domain; > > > > if ( !is_viridian_domain(d) ) > > return 0; > > @@ -142,44 +210,29 @@ int wrmsr_viridian_regs(uint32_t idx, ui > > case VIRIDIAN_MSR_GUEST_OS_ID: > > perfc_incr(mshv_wrmsr_osid); > > d->arch.hvm_domain.viridian.guest_os_id.raw =3D val; > > - gdprintk(XENLOG_INFO, "Guest os:\n"); > > - gdprintk(XENLOG_INFO, "\tvendor: %x\n", > > - d- > >arch.hvm_domain.viridian.guest_os_id.fields.vendor); > > - gdprintk(XENLOG_INFO, "\tos: %x\n", > > - d- > >arch.hvm_domain.viridian.guest_os_id.fields.os); > > - gdprintk(XENLOG_INFO, "\tmajor: %x\n", > > - d- > >arch.hvm_domain.viridian.guest_os_id.fields.major); > > - gdprintk(XENLOG_INFO, "\tminor: %x\n", > > - d- > >arch.hvm_domain.viridian.guest_os_id.fields.minor); > > - gdprintk(XENLOG_INFO, "\tsp: %x\n", > > - d- > >arch.hvm_domain.viridian.guest_os_id.fields.service_pack); > > - gdprintk(XENLOG_INFO, "\tbuild: %x\n", > > - d- > >arch.hvm_domain.viridian.guest_os_id.fields.build_number); > > + dump_guest_os_id(d); > > break; > > > > case VIRIDIAN_MSR_HYPERCALL: > > perfc_incr(mshv_wrmsr_hc_page); > > - gdprintk(XENLOG_INFO, "Set hypercall page %"PRIx64".\n", > val); > > - if ( d->arch.hvm_domain.viridian.guest_os_id.raw =3D=3D 0 ) > > - break; > > d->arch.hvm_domain.viridian.hypercall_gpa.raw =3D val; > > + dump_hypercall(d); > > if ( d- > >arch.hvm_domain.viridian.hypercall_gpa.fields.enabled ) > > - enable_hypercall_page(); > > + enable_hypercall_page(d); > > break; > > > > case VIRIDIAN_MSR_VP_INDEX: > > perfc_incr(mshv_wrmsr_vp_index); > > - gdprintk(XENLOG_INFO, "Set VP index %"PRIu64".\n", val); > > break; > > > > case VIRIDIAN_MSR_EOI: > > perfc_incr(mshv_wrmsr_eoi); > > - vlapic_EOI_set(vcpu_vlapic(current)); > > + vlapic_EOI_set(vcpu_vlapic(v)); > > break; > > > > case VIRIDIAN_MSR_ICR: { > > u32 eax =3D (u32)val, edx =3D (u32)(val >> 32); > > - struct vlapic *vlapic =3D vcpu_vlapic(current); > > + struct vlapic *vlapic =3D vcpu_vlapic(v); > > perfc_incr(mshv_wrmsr_icr); > > eax &=3D ~(1 << 12); > > edx &=3D 0xff000000; > > @@ -191,31 +244,15 @@ int wrmsr_viridian_regs(uint32_t idx, ui > > > > case VIRIDIAN_MSR_TPR: > > perfc_incr(mshv_wrmsr_tpr); > > - vlapic_set_reg(vcpu_vlapic(current), APIC_TASKPRI, > (uint8_t)val); > > + vlapic_set_reg(vcpu_vlapic(v), APIC_TASKPRI, > (uint8_t)val); > > break; > > > > case VIRIDIAN_MSR_APIC_ASSIST: > > - /* > > - * We don't support the APIC assist page, and that fact > is reflected > > in > > - * our CPUID flags. However, Windows 7 build 7000 has a > bug which > > means > > - * that it doesn't recognise that, and tries to use the > page anyway. > > We > > - * therefore have to fake up just enough to keep win7 > happy. > > - * Fortunately, that's really easy: just setting the > first four bytes > > - * in the page to zero effectively disables the page > again, so that's > > - * what we do. Semantically, the first four bytes are > supposed to be > > a > > - * flag saying whether the guest really needs to issue an > EOI. > > Setting > > - * that flag to zero means that it must always issue one, > which is > > what > > - * we want. Once a page has been repurposed as an APIC > assist page > > the > > - * guest isn't allowed to set anything in it, so the flag > remains > > zero > > - * and all is fine. The guest is allowed to clear flags > in the page, > > - * but that doesn't cause us any problems. > > - */ > > - if ( val & 1 ) /* APIC assist page enabled? */ > > - { > > - uint32_t word =3D 0; > > - paddr_t page_start =3D val & ~1ul; > > - (void)hvm_copy_to_guest_phys(page_start, &word, > sizeof(word)); > > - } > > + perfc_incr(mshv_wrmsr_apic_msr); > > + v->arch.hvm_vcpu.viridian.apic_assist.raw =3D val; > > + dump_apic_assist(v); > > + if (v->arch.hvm_vcpu.viridian.apic_assist.fields.enabled) > > + initialize_apic_assist(v); > > break; > > > > default: > > @@ -228,20 +265,21 @@ int wrmsr_viridian_regs(uint32_t idx, ui > int > > rdmsr_viridian_regs(uint32_t idx, uint64_t *val) { > > struct vcpu *v =3D current; > > + struct domain *d =3D v->domain; > > > > - if ( !is_viridian_domain(v->domain) ) > > + if ( !is_viridian_domain(d) ) > > return 0; > > > > switch ( idx ) > > { > > case VIRIDIAN_MSR_GUEST_OS_ID: > > perfc_incr(mshv_rdmsr_osid); > > - *val =3D v->domain- > >arch.hvm_domain.viridian.guest_os_id.raw; > > + *val =3D d->arch.hvm_domain.viridian.guest_os_id.raw; > > break; > > > > case VIRIDIAN_MSR_HYPERCALL: > > perfc_incr(mshv_rdmsr_hc_page); > > - *val =3D v->domain- > >arch.hvm_domain.viridian.hypercall_gpa.raw; > > + *val =3D d->arch.hvm_domain.viridian.hypercall_gpa.raw; > > break; > > > > case VIRIDIAN_MSR_VP_INDEX: > > @@ -260,6 +298,11 @@ int rdmsr_viridian_regs(uint32_t idx, ui > > *val =3D vlapic_get_reg(vcpu_vlapic(v), APIC_TASKPRI); > > break; > > > > + case VIRIDIAN_MSR_APIC_ASSIST: > > + perfc_incr(mshv_rdmsr_apic_msr); > > + *val =3D v->arch.hvm_vcpu.viridian.apic_assist.raw; > > + break; > > + > > default: > > return 0; > > } > > diff -r e90438f6e6d1 -r a08073c5cf28 xen/include/asm- > x86/hvm/vcpu.h > > --- a/xen/include/asm-x86/hvm/vcpu.h Wed Sep 14 11:38:13 2011 > +0100 > > +++ b/xen/include/asm-x86/hvm/vcpu.h Thu Sep 15 06:11:01 2011 > +0100 > > @@ -23,6 +23,7 @@ > > #include > > #include > > #include > > +#include > > #include > > #include > > #include > > @@ -163,6 +164,8 @@ struct hvm_vcpu { > > int inject_trap; /* -1 for nothing to inject > */ > > int inject_error_code; > > unsigned long inject_cr2; > > + > > + struct viridian_vcpu viridian; > > }; > > > > #endif /* __ASM_X86_HVM_VCPU_H__ */ > > diff -r e90438f6e6d1 -r a08073c5cf28 > > xen/include/asm-x86/hvm/viridian.h > > --- a/xen/include/asm-x86/hvm/viridian.h Wed Sep 14 11:38:13 2011 > > +0100 > > +++ b/xen/include/asm-x86/hvm/viridian.h Thu Sep 15 06:11:01 2011 > > +++ +0100 > > @@ -9,6 +9,21 @@ > > #ifndef __ASM_X86_HVM_VIRIDIAN_H__ > > #define __ASM_X86_HVM_VIRIDIAN_H__ > > > > +union viridian_apic_assist > > +{ uint64_t raw; > > + struct > > + { > > + uint64_t enabled:1; > > + uint64_t reserved_preserved:11; > > + uint64_t pfn:48; > > + } fields; > > +}; > > + > > +struct viridian_vcpu > > +{ > > + union viridian_apic_assist apic_assist; }; > > + > > union viridian_guest_os_id > > { > > uint64_t raw; > > diff -r e90438f6e6d1 -r a08073c5cf28 xen/include/asm- > x86/perfc_defn.h > > --- a/xen/include/asm-x86/perfc_defn.h Wed Sep 14 11:38:13 2011 > +0100 > > +++ b/xen/include/asm-x86/perfc_defn.h Thu Sep 15 06:11:01 2011 > +0100 > > @@ -120,12 +120,14 @@ PERFCOUNTER(mshv_rdmsr_hc_page, > > PERFCOUNTER(mshv_rdmsr_vp_index, "MS Hv rdmsr vp index") > > PERFCOUNTER(mshv_rdmsr_icr, "MS Hv rdmsr icr") > > PERFCOUNTER(mshv_rdmsr_tpr, "MS Hv rdmsr tpr") > > +PERFCOUNTER(mshv_rdmsr_apic_assist, "MS Hv rdmsr APIC > assist") > > PERFCOUNTER(mshv_wrmsr_osid, "MS Hv wrmsr Guest OS > ID") > > PERFCOUNTER(mshv_wrmsr_hc_page, "MS Hv wrmsr hypercall > page") > > PERFCOUNTER(mshv_wrmsr_vp_index, "MS Hv wrmsr vp index") > > PERFCOUNTER(mshv_wrmsr_icr, "MS Hv wrmsr icr") > > PERFCOUNTER(mshv_wrmsr_tpr, "MS Hv wrmsr tpr") > > PERFCOUNTER(mshv_wrmsr_eoi, "MS Hv wrmsr eoi") > > +PERFCOUNTER(mshv_wrmsr_apic_assist, "MS Hv wrmsr APIC > assist") > > > > PERFCOUNTER(realmode_emulations, "realmode instructions > emulated") > > PERFCOUNTER(realmode_exits, "vmexits from realmode") > > > > _______________________________________________ > > Xen-devel mailing list > > Xen-devel@lists.xensource.com > > http://lists.xensource.com/xen-devel >=20 _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel From xen-devel-bounces@lists.xensource.com Thu Sep 15 07:27:30 2011 Return-path: Envelope-to: www-data@lists.xensource.com Delivery-date: Thu, 15 Sep 2011 07:27:30 -0700 Received: from localhost ([127.0.0.1] helo=lists.colo.xensource.com) by lists.xensource.com with esmtp (Exim 4.43) id 1R4CuY-0007ls-8Z; Thu, 15 Sep 2011 07:27:30 -0700 Received: from mail174.messagelabs.com ([85.158.138.51]) by lists.xensource.com with esmtp (Exim 4.43) id 1R4Cu3-0007Z6-AE for xen-devel@lists.xensource.com; Thu, 15 Sep 2011 07:27:00 -0700 X-Env-Sender: Ian.Jackson@eu.citrix.com X-Msg-Ref: server-8.tower-174.messagelabs.com!1316096813!17867476!1 X-Originating-IP: [62.200.22.115] X-StarScan-Version: 6.4.1; banners=-,-,- X-VirusChecked: Checked Received: (qmail 8440 invoked from network); 15 Sep 2011 14:26:56 -0000 Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115) by server-8.tower-174.messagelabs.com with RC4-SHA encrypted SMTP; 15 Sep 2011 14:26:56 -0000 X-IronPort-AV: E=Sophos;i="4.68,387,1312156800"; d="scan'208";a="7860141" Received: from lonpmailmx01.citrite.net ([10.30.203.162]) by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5; 15 Sep 2011 14:26:53 +0000 Received: from norwich.cam.xci-test.com (10.80.248.129) by smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id 8.3.137.0; Thu, 15 Sep 2011 15:26:53 +0100 Received: from mariner.cam.xci-test.com ([10.80.2.22] helo=mariner.uk.xensource.com ident=Debian-exim) by norwich.cam.xci-test.com with esmtp (Exim 4.72) (envelope-from ) id 1R4Ctx-00088H-1V; Thu, 15 Sep 2011 14:26:53 +0000 Received: from iwj by mariner.uk.xensource.com with local (Exim 4.69) (envelope-from ) id 1R4Ctx-0000T0-0b; Thu, 15 Sep 2011 15:26:53 +0100 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Message-ID: <20082.2861.8629.101863@mariner.uk.xensource.com> Date: Thu, 15 Sep 2011 15:26:53 +0100 To: Juergen Gross Subject: Re: [Xen-devel] [PATCH] Enable cpuid performance counter leaf for HVM Newsgroups: chiark.mail.xen.devel In-Reply-To: <8244f714acf1cc2bc085.1315488574@nehalem1> References: <8244f714acf1cc2bc085.1315488574@nehalem1> X-Mailer: VM 8.0.9 under Emacs 21.4.1 (i486-pc-linux-gnu) From: Ian Jackson Cc: xen-devel@lists.xensource.com X-BeenThere: xen-devel@lists.xensource.com X-Mailman-Version: 2.1.5 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xensource.com Errors-To: xen-devel-bounces@lists.xensource.com Juergen Gross writes ("[Xen-devel] [PATCH] Enable cpuid performance counter leaf for HVM"): > In HVM domains the usable performance counters can be checked automatically > only, if cpuid leaf 0x0000000a is accessible. > > Signed-off-by: juergen.gross@ts.fujitsu.com Committed-by: Ian Jackson Ian. _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel From xen-devel-bounces@lists.xensource.com Thu Sep 15 07:32:27 2011 Return-path: Envelope-to: www-data@lists.xensource.com Delivery-date: Thu, 15 Sep 2011 07:32:27 -0700 Received: from localhost ([127.0.0.1] helo=lists.colo.xensource.com) by lists.xensource.com with esmtp (Exim 4.43) id 1R4CzL-0008E5-3S; Thu, 15 Sep 2011 07:32:27 -0700 Received: from mail174.messagelabs.com ([85.158.138.51]) by lists.xensource.com with esmtp (Exim 4.43) id 1R4Cym-000814-6G for xen-devel@lists.xensource.com; Thu, 15 Sep 2011 07:31:53 -0700 X-Env-Sender: keir.xen@gmail.com X-Msg-Ref: server-7.tower-174.messagelabs.com!1316097106!31525868!1 X-Originating-IP: [209.85.215.42] X-StarScan-Version: 6.4.1; banners=-,-,- X-VirusChecked: Checked Received: (qmail 8445 invoked from network); 15 Sep 2011 14:31:48 -0000 Received: from mail-ew0-f42.google.com (HELO mail-ew0-f42.google.com) (209.85.215.42) by server-7.tower-174.messagelabs.com with RC4-SHA encrypted SMTP; 15 Sep 2011 14:31:48 -0000 Received: by ewy2 with SMTP id 2so1928391ewy.29 for ; Thu, 15 Sep 2011 07:31:46 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=user-agent:date:subject:from:to:message-id:thread-topic :thread-index:in-reply-to:mime-version:content-type :content-transfer-encoding; bh=qCoZfi4TCBsrgNzJHn9HYoQXH/uNzNVOJ4iRLhDE7aU=; b=Zc0xeYMmsjofGDhXC3LmFo19H/KtkCAIC+EOyWko0S2QFWXf5EwX+8wTx9ln3wxnA6 UwR9AIyhVaMnndT5VFZiM0ds8+DccYTfzyIs5iM2OTPmXIZVF5zX73qCHQ8mmQDl1vB8 0EV6iArrrxLjfqN+DlYYzD6ZZNL0SsoktCQQs= Received: by 10.216.186.137 with SMTP id w9mr51465wem.25.1316097106367; Thu, 15 Sep 2011 07:31:46 -0700 (PDT) Received: from [192.168.1.78] (host86-137-116-193.range86-137.btcentralplus.com. [86.137.116.193]) by mx.google.com with ESMTPS id m2sm8115787wbp.5.2011.09.15.07.31.43 (version=SSLv3 cipher=OTHER); Thu, 15 Sep 2011 07:31:45 -0700 (PDT) User-Agent: Microsoft-Entourage/12.30.0.110427 Date: Thu, 15 Sep 2011 15:31:39 +0100 Subject: Re: [Xen-devel] [PATCH] Tidy up the viridian code a little and flesh out the APIC assist MSR From: Keir Fraser To: Paul Durrant , "xen-devel@lists.xensource.com" Message-ID: Thread-Topic: [Xen-devel] [PATCH] Tidy up the viridian code a little and flesh out the APIC assist MSR Thread-Index: AcxzcgONtakPWFHMdk29U12pniwCEwAQBjXQAACEZ70= In-Reply-To: <291EDFCB1E9E224A99088639C4762022B44F04717B@LONPMAILBOX01.citrite.net> Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit Cc: X-BeenThere: xen-devel@lists.xensource.com X-Mailman-Version: 2.1.5 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xensource.com Errors-To: xen-devel-bounces@lists.xensource.com Might need a shiny new Viridian struct type for our save format, which can then be extended with more Viridian-y stuff as required. -- Keir On 15/09/2011 15:19, "Paul Durrant" wrote: > Good point. I guess I may need to explicitly save/restore the apic assist pfn. > I'll check. > > Paul > >> -----Original Message----- >> From: Keir Fraser [mailto:keir.xen@gmail.com] >> Sent: 14 September 2011 23:38 >> To: Paul Durrant; xen-devel@lists.xensource.com >> Subject: Re: [Xen-devel] [PATCH] Tidy up the viridian code a little >> and flesh out the APIC assist MSR >> >> On 15/09/2011 06:13, "Paul Durrant" wrote: >> >>> # HG changeset patch >>> # User Paul Durrant # Date 1316063461 - >> 3600 >>> # Node ID a08073c5cf28ab76893102cc7a8d20bf3e5e15ae >>> # Parent e90438f6e6d1585a71b18784a99c162b5d95f390 >>> Tidy up the viridian code a little and flesh out the APIC assist >> MSR >>> handling code. >>> >>> We don't say we that handle that MSR but Windows assumes it. In >>> Windows 7 it just wrote to the MSR and we used to handle that ok. >>> Windows 8 also reads from the MSR so we need to keep a record of >> the contents. >> >> Does this work properly across save/restore? >> >> -- Keir >> >>> Signed-off-by: Paul Durrant >>> >>> diff -r e90438f6e6d1 -r a08073c5cf28 xen/arch/x86/hvm/viridian.c >>> --- a/xen/arch/x86/hvm/viridian.c Wed Sep 14 11:38:13 2011 +0100 >>> +++ b/xen/arch/x86/hvm/viridian.c Thu Sep 15 06:11:01 2011 +0100 >>> @@ -96,9 +96,43 @@ int cpuid_viridian_leaves(unsigned int l >>> return 1; >>> } >>> >>> -static void enable_hypercall_page(void) >>> +void dump_guest_os_id(struct domain *d) >>> { >>> - struct domain *d = current->domain; >>> + gdprintk(XENLOG_INFO, "GUEST_OS_ID:\n"); >>> + gdprintk(XENLOG_INFO, "\tvendor: %x\n", >>> + d- >>> arch.hvm_domain.viridian.guest_os_id.fields.vendor); >>> + gdprintk(XENLOG_INFO, "\tos: %x\n", >>> + d->arch.hvm_domain.viridian.guest_os_id.fields.os); >>> + gdprintk(XENLOG_INFO, "\tmajor: %x\n", >>> + d- >>> arch.hvm_domain.viridian.guest_os_id.fields.major); >>> + gdprintk(XENLOG_INFO, "\tminor: %x\n", >>> + d- >>> arch.hvm_domain.viridian.guest_os_id.fields.minor); >>> + gdprintk(XENLOG_INFO, "\tsp: %x\n", >>> + d- >>> arch.hvm_domain.viridian.guest_os_id.fields.service_pack); >>> + gdprintk(XENLOG_INFO, "\tbuild: %x\n", >>> + >>> +d->arch.hvm_domain.viridian.guest_os_id.fields.build_number); >>> +} >>> + >>> +void dump_hypercall(struct domain *d) { >>> + gdprintk(XENLOG_INFO, "HYPERCALL:\n"); >>> + gdprintk(XENLOG_INFO, "\tenabled: %x\n", >>> + d- >>> arch.hvm_domain.viridian.hypercall_gpa.fields.enabled); >>> + gdprintk(XENLOG_INFO, "\tpfn: %lx\n", >>> + (unsigned >>> long)d->arch.hvm_domain.viridian.hypercall_gpa.fields.pfn); >>> +} >>> + >>> +void dump_apic_assist(struct vcpu *v) { >>> + gdprintk(XENLOG_INFO, "APIC_ASSIST[%d]:\n", v->vcpu_id); >>> + gdprintk(XENLOG_INFO, "\tenabled: %x\n", >>> + v- >>> arch.hvm_vcpu.viridian.apic_assist.fields.enabled); >>> + gdprintk(XENLOG_INFO, "\tpfn: %lx\n", >>> + (unsigned >>> +long)v->arch.hvm_vcpu.viridian.apic_assist.fields.pfn); >>> +} >>> + >>> +static void enable_hypercall_page(struct domain *d) { >>> unsigned long gmfn = >>> d->arch.hvm_domain.viridian.hypercall_gpa.fields.pfn; >>> unsigned long mfn = gmfn_to_mfn(d, gmfn); >>> uint8_t *p; >>> @@ -130,9 +164,43 @@ static void enable_hypercall_page(void) >>> put_page_and_type(mfn_to_page(mfn)); >>> } >>> >>> +void initialize_apic_assist(struct vcpu *v) { >>> + struct domain *d = v->domain; >>> + unsigned long gmfn = v- >>> arch.hvm_vcpu.viridian.apic_assist.fields.pfn; >>> + unsigned long mfn = gmfn_to_mfn(d, gmfn); >>> + uint8_t *p; >>> + >>> + /* >>> + * We don't support the APIC assist page, and that fact is >> reflected in >>> + * our CPUID flags. However, Newer versions of Windows have a >> bug which >>> + * means that they don't recognise that, and tries to use the >> page >>> + * anyway. We therefore have to fake up just enough to keep >>> + windows >>> happy. >>> + * >>> + * See >>> + http://msdn.microsoft.com/en-us/library/ff538657%28VS.85%29.aspx >>> for >>> + * details of how Windows uses the page. >>> + */ >>> + >>> + if ( !mfn_valid(mfn) || >>> + !get_page_and_type(mfn_to_page(mfn), d, >> PGT_writable_page) ) >>> + { >>> + gdprintk(XENLOG_WARNING, "Bad GMFN %lx (MFN %lx)\n", >> gmfn, mfn); >>> + return; >>> + } >>> + >>> + p = map_domain_page(mfn); >>> + >>> + *(u32 *)p = 0; >>> + >>> + unmap_domain_page(p); >>> + >>> + put_page_and_type(mfn_to_page(mfn)); >>> +} >>> + >>> int wrmsr_viridian_regs(uint32_t idx, uint64_t val) { >>> - struct domain *d = current->domain; >>> + struct vcpu *v = current; >>> + struct domain *d = v->domain; >>> >>> if ( !is_viridian_domain(d) ) >>> return 0; >>> @@ -142,44 +210,29 @@ int wrmsr_viridian_regs(uint32_t idx, ui >>> case VIRIDIAN_MSR_GUEST_OS_ID: >>> perfc_incr(mshv_wrmsr_osid); >>> d->arch.hvm_domain.viridian.guest_os_id.raw = val; >>> - gdprintk(XENLOG_INFO, "Guest os:\n"); >>> - gdprintk(XENLOG_INFO, "\tvendor: %x\n", >>> - d- >>> arch.hvm_domain.viridian.guest_os_id.fields.vendor); >>> - gdprintk(XENLOG_INFO, "\tos: %x\n", >>> - d- >>> arch.hvm_domain.viridian.guest_os_id.fields.os); >>> - gdprintk(XENLOG_INFO, "\tmajor: %x\n", >>> - d- >>> arch.hvm_domain.viridian.guest_os_id.fields.major); >>> - gdprintk(XENLOG_INFO, "\tminor: %x\n", >>> - d- >>> arch.hvm_domain.viridian.guest_os_id.fields.minor); >>> - gdprintk(XENLOG_INFO, "\tsp: %x\n", >>> - d- >>> arch.hvm_domain.viridian.guest_os_id.fields.service_pack); >>> - gdprintk(XENLOG_INFO, "\tbuild: %x\n", >>> - d- >>> arch.hvm_domain.viridian.guest_os_id.fields.build_number); >>> + dump_guest_os_id(d); >>> break; >>> >>> case VIRIDIAN_MSR_HYPERCALL: >>> perfc_incr(mshv_wrmsr_hc_page); >>> - gdprintk(XENLOG_INFO, "Set hypercall page %"PRIx64".\n", >> val); >>> - if ( d->arch.hvm_domain.viridian.guest_os_id.raw == 0 ) >>> - break; >>> d->arch.hvm_domain.viridian.hypercall_gpa.raw = val; >>> + dump_hypercall(d); >>> if ( d- >>> arch.hvm_domain.viridian.hypercall_gpa.fields.enabled ) >>> - enable_hypercall_page(); >>> + enable_hypercall_page(d); >>> break; >>> >>> case VIRIDIAN_MSR_VP_INDEX: >>> perfc_incr(mshv_wrmsr_vp_index); >>> - gdprintk(XENLOG_INFO, "Set VP index %"PRIu64".\n", val); >>> break; >>> >>> case VIRIDIAN_MSR_EOI: >>> perfc_incr(mshv_wrmsr_eoi); >>> - vlapic_EOI_set(vcpu_vlapic(current)); >>> + vlapic_EOI_set(vcpu_vlapic(v)); >>> break; >>> >>> case VIRIDIAN_MSR_ICR: { >>> u32 eax = (u32)val, edx = (u32)(val >> 32); >>> - struct vlapic *vlapic = vcpu_vlapic(current); >>> + struct vlapic *vlapic = vcpu_vlapic(v); >>> perfc_incr(mshv_wrmsr_icr); >>> eax &= ~(1 << 12); >>> edx &= 0xff000000; >>> @@ -191,31 +244,15 @@ int wrmsr_viridian_regs(uint32_t idx, ui >>> >>> case VIRIDIAN_MSR_TPR: >>> perfc_incr(mshv_wrmsr_tpr); >>> - vlapic_set_reg(vcpu_vlapic(current), APIC_TASKPRI, >> (uint8_t)val); >>> + vlapic_set_reg(vcpu_vlapic(v), APIC_TASKPRI, >> (uint8_t)val); >>> break; >>> >>> case VIRIDIAN_MSR_APIC_ASSIST: >>> - /* >>> - * We don't support the APIC assist page, and that fact >> is reflected >>> in >>> - * our CPUID flags. However, Windows 7 build 7000 has a >> bug which >>> means >>> - * that it doesn't recognise that, and tries to use the >> page anyway. >>> We >>> - * therefore have to fake up just enough to keep win7 >> happy. >>> - * Fortunately, that's really easy: just setting the >> first four bytes >>> - * in the page to zero effectively disables the page >> again, so that's >>> - * what we do. Semantically, the first four bytes are >> supposed to be >>> a >>> - * flag saying whether the guest really needs to issue an >> EOI. >>> Setting >>> - * that flag to zero means that it must always issue one, >> which is >>> what >>> - * we want. Once a page has been repurposed as an APIC >> assist page >>> the >>> - * guest isn't allowed to set anything in it, so the flag >> remains >>> zero >>> - * and all is fine. The guest is allowed to clear flags >> in the page, >>> - * but that doesn't cause us any problems. >>> - */ >>> - if ( val & 1 ) /* APIC assist page enabled? */ >>> - { >>> - uint32_t word = 0; >>> - paddr_t page_start = val & ~1ul; >>> - (void)hvm_copy_to_guest_phys(page_start, &word, >> sizeof(word)); >>> - } >>> + perfc_incr(mshv_wrmsr_apic_msr); >>> + v->arch.hvm_vcpu.viridian.apic_assist.raw = val; >>> + dump_apic_assist(v); >>> + if (v->arch.hvm_vcpu.viridian.apic_assist.fields.enabled) >>> + initialize_apic_assist(v); >>> break; >>> >>> default: >>> @@ -228,20 +265,21 @@ int wrmsr_viridian_regs(uint32_t idx, ui >> int >>> rdmsr_viridian_regs(uint32_t idx, uint64_t *val) { >>> struct vcpu *v = current; >>> + struct domain *d = v->domain; >>> >>> - if ( !is_viridian_domain(v->domain) ) >>> + if ( !is_viridian_domain(d) ) >>> return 0; >>> >>> switch ( idx ) >>> { >>> case VIRIDIAN_MSR_GUEST_OS_ID: >>> perfc_incr(mshv_rdmsr_osid); >>> - *val = v->domain- >>> arch.hvm_domain.viridian.guest_os_id.raw; >>> + *val = d->arch.hvm_domain.viridian.guest_os_id.raw; >>> break; >>> >>> case VIRIDIAN_MSR_HYPERCALL: >>> perfc_incr(mshv_rdmsr_hc_page); >>> - *val = v->domain- >>> arch.hvm_domain.viridian.hypercall_gpa.raw; >>> + *val = d->arch.hvm_domain.viridian.hypercall_gpa.raw; >>> break; >>> >>> case VIRIDIAN_MSR_VP_INDEX: >>> @@ -260,6 +298,11 @@ int rdmsr_viridian_regs(uint32_t idx, ui >>> *val = vlapic_get_reg(vcpu_vlapic(v), APIC_TASKPRI); >>> break; >>> >>> + case VIRIDIAN_MSR_APIC_ASSIST: >>> + perfc_incr(mshv_rdmsr_apic_msr); >>> + *val = v->arch.hvm_vcpu.viridian.apic_assist.raw; >>> + break; >>> + >>> default: >>> return 0; >>> } >>> diff -r e90438f6e6d1 -r a08073c5cf28 xen/include/asm- >> x86/hvm/vcpu.h >>> --- a/xen/include/asm-x86/hvm/vcpu.h Wed Sep 14 11:38:13 2011 >> +0100 >>> +++ b/xen/include/asm-x86/hvm/vcpu.h Thu Sep 15 06:11:01 2011 >> +0100 >>> @@ -23,6 +23,7 @@ >>> #include >>> #include >>> #include >>> +#include >>> #include >>> #include >>> #include >>> @@ -163,6 +164,8 @@ struct hvm_vcpu { >>> int inject_trap; /* -1 for nothing to inject >> */ >>> int inject_error_code; >>> unsigned long inject_cr2; >>> + >>> + struct viridian_vcpu viridian; >>> }; >>> >>> #endif /* __ASM_X86_HVM_VCPU_H__ */ >>> diff -r e90438f6e6d1 -r a08073c5cf28 >>> xen/include/asm-x86/hvm/viridian.h >>> --- a/xen/include/asm-x86/hvm/viridian.h Wed Sep 14 11:38:13 2011 >>> +0100 >>> +++ b/xen/include/asm-x86/hvm/viridian.h Thu Sep 15 06:11:01 2011 >>> +++ +0100 >>> @@ -9,6 +9,21 @@ >>> #ifndef __ASM_X86_HVM_VIRIDIAN_H__ >>> #define __ASM_X86_HVM_VIRIDIAN_H__ >>> >>> +union viridian_apic_assist >>> +{ uint64_t raw; >>> + struct >>> + { >>> + uint64_t enabled:1; >>> + uint64_t reserved_preserved:11; >>> + uint64_t pfn:48; >>> + } fields; >>> +}; >>> + >>> +struct viridian_vcpu >>> +{ >>> + union viridian_apic_assist apic_assist; }; >>> + >>> union viridian_guest_os_id >>> { >>> uint64_t raw; >>> diff -r e90438f6e6d1 -r a08073c5cf28 xen/include/asm- >> x86/perfc_defn.h >>> --- a/xen/include/asm-x86/perfc_defn.h Wed Sep 14 11:38:13 2011 >> +0100 >>> +++ b/xen/include/asm-x86/perfc_defn.h Thu Sep 15 06:11:01 2011 >> +0100 >>> @@ -120,12 +120,14 @@ PERFCOUNTER(mshv_rdmsr_hc_page, >>> PERFCOUNTER(mshv_rdmsr_vp_index, "MS Hv rdmsr vp index") >>> PERFCOUNTER(mshv_rdmsr_icr, "MS Hv rdmsr icr") >>> PERFCOUNTER(mshv_rdmsr_tpr, "MS Hv rdmsr tpr") >>> +PERFCOUNTER(mshv_rdmsr_apic_assist, "MS Hv rdmsr APIC >> assist") >>> PERFCOUNTER(mshv_wrmsr_osid, "MS Hv wrmsr Guest OS >> ID") >>> PERFCOUNTER(mshv_wrmsr_hc_page, "MS Hv wrmsr hypercall >> page") >>> PERFCOUNTER(mshv_wrmsr_vp_index, "MS Hv wrmsr vp index") >>> PERFCOUNTER(mshv_wrmsr_icr, "MS Hv wrmsr icr") >>> PERFCOUNTER(mshv_wrmsr_tpr, "MS Hv wrmsr tpr") >>> PERFCOUNTER(mshv_wrmsr_eoi, "MS Hv wrmsr eoi") >>> +PERFCOUNTER(mshv_wrmsr_apic_assist, "MS Hv wrmsr APIC >> assist") >>> >>> PERFCOUNTER(realmode_emulations, "realmode instructions >> emulated") >>> PERFCOUNTER(realmode_exits, "vmexits from realmode") >>> >>> _______________________________________________ >>> Xen-devel mailing list >>> Xen-devel@lists.xensource.com >>> http://lists.xensource.com/xen-devel >> > _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel From xen-devel-bounces@lists.xensource.com Thu Sep 15 07:37:59 2011 Return-path: Envelope-to: www-data@lists.xensource.com Delivery-date: Thu, 15 Sep 2011 07:37:59 -0700 Received: from localhost ([127.0.0.1] helo=lists.colo.xensource.com) by lists.xensource.com with esmtp (Exim 4.43) id 1R4D4h-0000Qo-Mo; Thu, 15 Sep 2011 07:37:59 -0700 Received: from mail174.messagelabs.com ([85.158.138.51]) by lists.xensource.com with esmtp (Exim 4.43) id 1R4D42-0000Ed-GX for xen-devel@lists.xensource.com; Thu, 15 Sep 2011 07:37:19 -0700 X-Env-Sender: fantonifabio@tiscali.it X-Msg-Ref: server-2.tower-174.messagelabs.com!1316097410!31552417!1 X-Originating-IP: [216.139.236.26] X-StarScan-Version: 6.4.1; banners=-,-,- X-VirusChecked: Checked Received: (qmail 31642 invoked from network); 15 Sep 2011 14:37:14 -0000 Received: from sam.nabble.com (HELO sam.nabble.com) (216.139.236.26) by server-2.tower-174.messagelabs.com with AES256-SHA encrypted SMTP; 15 Sep 2011 14:37:14 -0000 Received: from [192.168.236.26] (helo=sam.nabble.com) by sam.nabble.com with esmtp (Exim 4.72) (envelope-from ) id 1R4D3Z-0007AB-MS for xen-devel@lists.xensource.com; Thu, 15 Sep 2011 07:36:49 -0700 Date: Thu, 15 Sep 2011 07:36:49 -0700 (PDT) From: Fantu To: xen-devel@lists.xensource.com Message-ID: <1316097409687-4807062.post@n5.nabble.com> In-Reply-To: <20110914145403.GA17899@phenom.oracle.com> References: <1316011454156-4803078.post@n5.nabble.com> <20110914145403.GA17899@phenom.oracle.com> MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Subject: [Xen-devel] Re: Out sw-iommu space problem X-BeenThere: xen-devel@lists.xensource.com X-Mailman-Version: 2.1.5 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xensource.com Errors-To: xen-devel-bounces@lists.xensource.com With swiotlb=3D128768 from kern.log: Sep 15 14:27:45 heliMN02WV kernel: [ 3.595733] PCI-DMA: Using software bounce buffering for IO (SWIOTLB) Sep 15 14:27:45 heliMN02WV kernel: [ 3.595738] DMA: Placing 251MB software IO TLB between ffff8800048c0000 - ffff880014440000 Sep 15 14:27:45 heliMN02WV kernel: [ 3.595740] DMA: software IO TLB at phys 0x48c0000 =E2=80=93 0x14440000 It seems swiotlb was assigned 251 mb Without swiotlb=3D from kern.log: Sep 15 08:16:44 heliMN02WV kernel: [ 3.400528] PCI-DMA: Using software bounce buffering for IO (SWIOTLB) Sep 15 08:16:44 heliMN02WV kernel: [ 3.400533] DMA: Placing 64MB softwar= e IO TLB between ffff8800048c0000 - ffff8800088c0000 Sep 15 08:16:44 heliMN02WV kernel: [ 3.400535] DMA: software IO TLB at phys 0x48c0000 =E2=80=93 0x88c0000 I have set swiotlb=3D65762, i have do reboot of dom0 but after always probl= em on save of service xendomains shutdown, not sm iommu out of memory but: Sep 15 15:29:15 heliMN02WV kernel: [ 641.006286] tapdisk2[6891]: segfault at 7fff58bb7fe8 ip 00000000004082ac sp 00007fff58bb7ff0 error 6 in tapdisk2[400000+39000] Sep 15 15:29:15 heliMN02WV kernel: [ 641.026060] BUG: unable to handle kernel NULL pointer dereference at 0000000000000048 Sep 15 15:29:15 heliMN02WV kernel: [ 641.026200] IP: [] apply_to_page_range+0x47/0x2f3 Sep 15 15:29:15 heliMN02WV kernel: [ 641.026291] PGD 0=20 Sep 15 15:29:15 heliMN02WV kernel: [ 641.026371] Oops: 0000 [#1] SMP=20 Sep 15 15:29:15 heliMN02WV kernel: [ 641.026483] last sysfs file: /sys/devices/virtual/blktap2/blktap6/remove Sep 15 15:29:15 heliMN02WV kernel: [ 641.026541] CPU 2=20 Sep 15 15:29:15 heliMN02WV kernel: [ 641.026619] Modules linked in: xt_tcpudp tun xt_physdev iptable_filter ip_tables x_tables bridge stp ib_iser rdma_cm ib_cm iw_cm ib_sa ib_mad ib_core ib_addr iscsi_tcp libiscsi_tcp libiscsi scsi_transport_iscsi ext2 sha256_generic aes_x86_64 aes_generic cbc blktap xen_evtchn xenfs loop dm_crypt snd_pcm snd_timer snd soundcore snd_page_alloc evdev joydev dcdbas pcspkr power_meter button processor acpi_processor ext4 mbcache jbd2 crc16 dm_mod sd_mod crc_t10dif s= g sr_mod cdrom usbhid hid ata_generic ehci_hcd ata_piix usbcore libata nls_base bnx2 mpt2sas scsi_transport_sas scsi_mod thermal thermal_sys [last unloaded: scsi_wait_scan] Sep 15 15:29:15 heliMN02WV kernel: [ 641.029000] Pid: 6891, comm: tapdisk2 Not tainted 2.6.32-5-xen-amd64 #1 PowerEdge T310 Sep 15 15:29:15 heliMN02WV kernel: [ 641.029082] RIP: e030:[] [] apply_to_page_range+0x47/0x2f3 Sep 15 15:29:15 heliMN02WV kernel: [ 641.029191] RSP: e02b:ffff88003dda3b5= 8=20 EFLAGS: 00010202 Sep 15 15:29:15 heliMN02WV kernel: [ 641.029246] RAX: 0000000000000880 RBX= : ffff88003ebc1000 RCX: ffff88003ebc2000 Sep 15 15:29:15 heliMN02WV kernel: [ 641.029313] RDX: 0000000000000000 RSI= : ffff88003ebc1000 RDI: 0000000000000000 Sep 15 15:29:15 heliMN02WV kernel: [ 641.029372] RBP: ffff88003e7383d0 R08= : 0000000000000000 R09: ffff88003c4d4780 Sep 15 15:29:15 heliMN02WV kernel: [ 641.029431] R10: 0000000000000002 R11= : 0000000000000000 R12: 0000000000000000 Sep 15 15:29:15 heliMN02WV kernel: [ 641.029491] R13: ffff88003e7383d0 R14= : ffff88003deb7800 R15: 0000000000000000 Sep 15 15:29:15 heliMN02WV kernel: [ 641.029555] FS:=20 00007f185cd15740(0000) GS:ffff880003728000(0000) knlGS:0000000000000000 Sep 15 15:29:15 heliMN02WV kernel: [ 641.029630] CS: e033 DS: 0000 ES: 0000 CR0: 000000008005003b Sep 15 15:29:15 heliMN02WV kernel: [ 641.029686] CR2: 0000000000000048 CR3= : 0000000001001000 CR4: 0000000000002660 Sep 15 15:29:15 heliMN02WV kernel: [ 641.029744] DR0: 0000000000000000 DR1= : 0000000000000000 DR2: 0000000000000000 Sep 15 15:29:15 heliMN02WV kernel: [ 641.029802] DR3: 0000000000000000 DR6= : 00000000ffff0ff0 DR7: 0000000000000400 Sep 15 15:29:15 heliMN02WV kernel: [ 641.029861] Process tapdisk2 (pid: 6891, threadinfo ffff88003dda2000, task ffff8800027ae9f0) Sep 15 15:29:15 heliMN02WV kernel: [ 641.029936] Stack: Sep 15 15:29:15 heliMN02WV kernel: [ 641.029984] 0000000000000000 ffff880001d03b40 0000000000000000 0000000000000000 Sep 15 15:29:15 heliMN02WV kernel: [ 641.030134] <0> ffffffffa02dcee8 0000000000000000 ffffffff8100ece2 ffff8800023c9cc0 Sep 15 15:29:15 heliMN02WV kernel: [ 641.030359] <0> ffff88003ebc2000 0000000000000000 0000000000000000 ffff8800023c9cc0 Sep 15 15:29:15 heliMN02WV kernel: [ 641.030635] Call Trace: Sep 15 15:29:15 heliMN02WV kernel: [ 641.030699] [] ? blktap_umap_uaddr_fn+0x0/0x59 [blktap] Sep 15 15:29:15 heliMN02WV kernel: [ 641.030764] [] ? check_events+0x12/0x20 Sep 15 15:29:15 heliMN02WV kernel: [ 641.030831] [] ? blktap_device_end_request+0xbd/0x145 [blktap] Sep 15 15:29:15 heliMN02WV kernel: [ 641.030917] [] ? blktap_ring_vm_close+0x60/0xd1 [blktap] Sep 15 15:29:15 heliMN02WV kernel: [ 641.030977] [] ? remove_vma+0x2c/0x72 Sep 15 15:29:15 heliMN02WV kernel: [ 641.031040] [] ? exit_mmap+0x129/0x148 Sep 15 15:29:15 heliMN02WV kernel: [ 641.031097] [] ? mmput+0x3c/0xdf Sep 15 15:29:15 heliMN02WV kernel: [ 641.031153] [] ? exit_mm+0x102/0x10d Sep 15 15:29:15 heliMN02WV kernel: [ 641.031212] [] ? _spin_lock_irq+0x7/0x22 Sep 15 15:29:15 heliMN02WV kernel: [ 641.031274] [] ? do_exit+0x1f8/0x6c6 Sep 15 15:29:15 heliMN02WV kernel: [ 641.031340] [] ? __dequeue_signal+0xfb/0x124 Sep 15 15:29:15 heliMN02WV kernel: [ 641.031399] [] ? xen_restore_fl_direct_end+0x0/0x1 Sep 15 15:29:15 heliMN02WV kernel: [ 641.031458] [] ? kmem_cache_free+0x72/0xa3 Sep 15 15:29:15 heliMN02WV kernel: [ 641.031514] [] ? do_group_exit+0x76/0x9d Sep 15 15:29:15 heliMN02WV kernel: [ 641.031570] [] ? get_signal_to_deliver+0x310/0x339 Sep 15 15:29:15 heliMN02WV kernel: [ 641.031627] [] ? do_notify_resume+0x87/0x73f Sep 15 15:29:15 heliMN02WV kernel: [ 641.031684] [] ? expand_downwards+0x5b/0x169 Sep 15 15:29:15 heliMN02WV kernel: [ 641.031742] [] ? do_page_fault+0x1f3/0x2f2 Sep 15 15:29:15 heliMN02WV kernel: [ 641.031798] [] ? retint_signal+0x48/0x8c Sep 15 15:29:15 heliMN02WV kernel: [ 641.031853] Code: 48 89 4c 24 20 4c 8= 9 44 24 18 48 89 54 24 40 72 04 0f 0b eb fe 48 8b 54 24 28 48 89 f0 48 8b 4c 24 40 48 c1 e8 24 25 f8 0f 00 00 <48> 8b 52 48 48 ff c9 48 89 0c 24 48 01 d= 0 48 89 44 24 30 48 b8=20 Sep 15 15:29:15 heliMN02WV kernel: [ 641.033878] RIP [] apply_to_page_range+0x47/0x2f3 Sep 15 15:29:15 heliMN02WV kernel: [ 641.033965] RSP Sep 15 15:29:15 heliMN02WV kernel: [ 641.034015] CR2: 0000000000000048 Sep 15 15:29:15 heliMN02WV kernel: [ 641.034067] ---[ end trace 162efc545a37e94b ]--- Sep 15 15:29:15 heliMN02WV kernel: [ 641.034120] Fixing recursive fault bu= t reboot is needed! I have do other reboot of dom0, shutdown of domu how have give error, reboo= t of dom0 and other service xendomains stop but same error: Sep 15 15:55:32 heliMN02WV kernel: [ 441.038016] tapdisk2[4787]: segfault at 7ffff3d44ff8 ip 0000000000408296 sp 00007ffff3d45000 error 6 in tapdisk2[400000+39000] Sep 15 15:55:32 heliMN02WV kernel: [ 441.057462] BUG: unable to handle kernel NULL pointer dereference at 0000000000000048 Sep 15 15:55:32 heliMN02WV kernel: [ 441.057601] IP: [] apply_to_page_range+0x47/0x2f3 Sep 15 15:55:32 heliMN02WV kernel: [ 441.057691] PGD 0=20 Sep 15 15:55:32 heliMN02WV kernel: [ 441.057770] Oops: 0000 [#1] SMP=20 Sep 15 15:55:32 heliMN02WV kernel: [ 441.057880] last sysfs file: /sys/devices/virtual/blktap2/blktap1/remove Sep 15 15:55:32 heliMN02WV kernel: [ 441.057938] CPU 2=20 Sep 15 15:55:32 heliMN02WV kernel: [ 441.058015] Modules linked in: xt_tcpudp xt_physdev iptable_filter ip_tables x_tables tun bridge stp ib_iser rdma_cm ib_cm iw_cm ib_sa ib_mad ib_core ib_addr iscsi_tcp libiscsi_tcp libiscsi scsi_transport_iscsi ext2 sha256_generic aes_x86_64 aes_generic cbc blktap xen_evtchn xenfs loop dm_crypt snd_pcm snd_timer snd soundcore snd_page_alloc joydev pcspkr evdev dcdbas button power_meter processor acpi_processor ext4 mbcache jbd2 crc16 dm_mod sd_mod crc_t10dif s= g sr_mod cdrom usbhid hid ata_generic ata_piix ehci_hcd mpt2sas usbcore libat= a nls_base bnx2 scsi_transport_sas scsi_mod thermal thermal_sys [last unloaded: scsi_wait_scan] Sep 15 15:55:32 heliMN02WV kernel: [ 441.060309] Pid: 4787, comm: tapdisk2 Not tainted 2.6.32-5-xen-amd64 #1 PowerEdge T310 Sep 15 15:55:32 heliMN02WV kernel: [ 441.060382] RIP: e030:[] [] apply_to_page_range+0x47/0x2f3 Sep 15 15:55:32 heliMN02WV kernel: [ 441.060487] RSP: e02b:ffff88003dd15b5= 8=20 EFLAGS: 00010202 Sep 15 15:55:32 heliMN02WV kernel: [ 441.060542] RAX: 0000000000000880 RBX= : ffff880003337000 RCX: ffff880003338000 Sep 15 15:55:32 heliMN02WV kernel: [ 441.060599] RDX: 0000000000000000 RSI= : ffff880003337000 RDI: 0000000000000000 Sep 15 15:55:32 heliMN02WV kernel: [ 441.060657] RBP: ffff880001ef50f0 R08= : 0000000000000000 R09: ffff88003d161900 Sep 15 15:55:32 heliMN02WV kernel: [ 441.060714] R10: 0000000000000002 R11= : 0000000000000000 R12: 0000000000000000 Sep 15 15:55:32 heliMN02WV kernel: [ 441.060771] R13: ffff880001ef50f0 R14= : ffff88003981e000 R15: 0000000000000000 Sep 15 15:55:32 heliMN02WV kernel: [ 441.060831] FS:=20 00007f7e8720a740(0000) GS:ffff880003728000(0000) knlGS:0000000000000000 Sep 15 15:55:32 heliMN02WV kernel: [ 441.060905] CS: e033 DS: 0000 ES: 0000 CR0: 000000008005003b Sep 15 15:55:32 heliMN02WV kernel: [ 441.060960] CR2: 0000000000000048 CR3= : 0000000001001000 CR4: 0000000000002660 Sep 15 15:55:32 heliMN02WV kernel: [ 441.061018] DR0: 0000000000000000 DR1= : 0000000000000000 DR2: 0000000000000000 Sep 15 15:55:32 heliMN02WV kernel: [ 441.061076] DR3: 0000000000000000 DR6= : 00000000ffff0ff0 DR7: 0000000000000400 Sep 15 15:55:32 heliMN02WV kernel: [ 441.061133] Process tapdisk2 (pid: 4787, threadinfo ffff88003dd14000, task ffff880035dbf810) Sep 15 15:55:32 heliMN02WV kernel: [ 441.061207] Stack: Sep 15 15:55:32 heliMN02WV kernel: [ 441.061255] 0000000000000000 ffff880035dc59c0 0000000000000000 0000000000000000 Sep 15 15:55:32 heliMN02WV kernel: [ 441.061403] <0> ffffffffa02dcee8 0000000000000000 ffffffff8100ece2 ffff88003d499540 Sep 15 15:55:32 heliMN02WV kernel: [ 441.061623] <0> ffff880003338000 0000000000000000 0000000000000000 ffff88003d499540 Sep 15 15:55:32 heliMN02WV kernel: [ 441.061886] Call Trace: Sep 15 15:55:32 heliMN02WV kernel: [ 441.061939] [] ? blktap_umap_uaddr_fn+0x0/0x59 [blktap] Sep 15 15:55:32 heliMN02WV kernel: [ 441.062000] [] ? check_events+0x12/0x20 Sep 15 15:55:32 heliMN02WV kernel: [ 441.062056] [] ? blktap_device_end_request+0xbd/0x145 [blktap] Sep 15 15:55:32 heliMN02WV kernel: [ 441.062130] [] ? blktap_ring_vm_close+0x60/0xd1 [blktap] Sep 15 15:55:32 heliMN02WV kernel: [ 441.062189] [] ? remove_vma+0x2c/0x72 Sep 15 15:55:32 heliMN02WV kernel: [ 441.062244] [] ? exit_mmap+0x129/0x148 Sep 15 15:55:32 heliMN02WV kernel: [ 441.062300] [] ? mmput+0x3c/0xdf Sep 15 15:55:32 heliMN02WV kernel: [ 441.062355] [] ? exit_mm+0x102/0x10d Sep 15 15:55:32 heliMN02WV kernel: [ 441.062412] [] ? _spin_lock_irq+0x7/0x22 Sep 15 15:55:32 heliMN02WV kernel: [ 441.062468] [] ? do_exit+0x1f8/0x6c6 Sep 15 15:55:32 heliMN02WV kernel: [ 441.062529] [] ? __dequeue_signal+0xfb/0x124 Sep 15 15:55:32 heliMN02WV kernel: [ 441.062590] [] ? xen_restore_fl_direct_end+0x0/0x1 Sep 15 15:55:32 heliMN02WV kernel: [ 441.062647] [] ? kmem_cache_free+0x72/0xa3 Sep 15 15:55:32 heliMN02WV kernel: [ 441.062703] [] ? do_group_exit+0x76/0x9d Sep 15 15:55:32 heliMN02WV kernel: [ 441.062759] [] ? get_signal_to_deliver+0x310/0x339 Sep 15 15:55:32 heliMN02WV kernel: [ 441.062816] [] ? do_notify_resume+0x87/0x73f Sep 15 15:55:32 heliMN02WV kernel: [ 441.062874] [] ? expand_downwards+0x5b/0x169 Sep 15 15:55:32 heliMN02WV kernel: [ 441.062930] [] ? do_page_fault+0x1f3/0x2f2 Sep 15 15:55:32 heliMN02WV kernel: [ 441.062986] [] ? retint_signal+0x48/0x8c Sep 15 15:55:32 heliMN02WV kernel: [ 441.063041] Code: 48 89 4c 24 20 4c 8= 9 44 24 18 48 89 54 24 40 72 04 0f 0b eb fe 48 8b 54 24 28 48 89 f0 48 8b 4c 24 40 48 c1 e8 24 25 f8 0f 00 00 <48> 8b 52 48 48 ff c9 48 89 0c 24 48 01 d= 0 48 89 44 24 30 48 b8=20 Sep 15 15:55:32 heliMN02WV kernel: [ 441.065075] RIP [] apply_to_page_range+0x47/0x2f3 Sep 15 15:55:32 heliMN02WV kernel: [ 441.065164] RSP Sep 15 15:55:32 heliMN02WV kernel: [ 441.065216] CR2: 0000000000000048 Sep 15 15:55:32 heliMN02WV kernel: [ 441.065270] ---[ end trace f19d313c82859143 ]--- Sep 15 15:55:32 heliMN02WV kernel: [ 441.065324] Fixing recursive fault bu= t reboot is needed! Can you help me to solve this problem please? I try search on xen-unstable.hg "tapdisk2" revs and i found http://xenbits.xen.org/hg/staging/xen-unstable.hg/rev/a5a0817d9210 with som= e strange characters "=C3=82", there isn't on 4.0 testing and isn't this prob= lem but can be a bug on unstable. -- View this message in context: http://xen.1045712.n5.nabble.com/Out-sw-iommu= -space-problem-tp4803078p4807062.html Sent from the Xen - Dev mailing list archive at Nabble.com. _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel From xen-devel-bounces@lists.xensource.com Thu Sep 15 07:47:52 2011 Return-path: Envelope-to: www-data@lists.xensource.com Delivery-date: Thu, 15 Sep 2011 07:47:52 -0700 Received: from localhost ([127.0.0.1] helo=lists.colo.xensource.com) by lists.xensource.com with esmtp (Exim 4.43) id 1R4DEF-0000wI-T0; Thu, 15 Sep 2011 07:47:51 -0700 Received: from mail27.messagelabs.com ([193.109.254.147]) by lists.xensource.com with esmtp (Exim 4.43) id 1R4DDd-0000kZ-Pj for xen-devel@lists.xensource.com; Thu, 15 Sep 2011 07:47:14 -0700 X-Env-Sender: Stefano.Stabellini@eu.citrix.com X-Msg-Ref: server-11.tower-27.messagelabs.com!1316098023!37562814!1 X-Originating-IP: [62.200.22.115] X-StarScan-Version: 6.4.1; banners=-,-,- X-VirusChecked: Checked Received: (qmail 6977 invoked from network); 15 Sep 2011 14:47:03 -0000 Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115) by server-11.tower-27.messagelabs.com with RC4-SHA encrypted SMTP; 15 Sep 2011 14:47:03 -0000 X-IronPort-AV: E=Sophos;i="4.68,387,1312156800"; d="scan'208";a="7861000" Received: from lonpmailmx01.citrite.net ([10.30.203.162]) by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5; 15 Sep 2011 14:47:10 +0000 Received: from kaball.uk.xensource.com (10.80.2.59) by LONPMAILMX01.citrite.net (10.30.203.162) with Microsoft SMTP Server id 8.3.137.0; Thu, 15 Sep 2011 15:47:10 +0100 Date: Thu, 15 Sep 2011 15:55:44 +0100 From: Stefano Stabellini X-X-Sender: sstabellini@kaball-desktop To: Message-ID: User-Agent: Alpine 2.00 (DEB 1167 2008-08-23) MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Cc: Keir Fraser , Ian Campbell , Stefano Stabellini Subject: [Xen-devel] [PATCH v4] build upstream qemu and seabios by default X-BeenThere: xen-devel@lists.xensource.com X-Mailman-Version: 2.1.5 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xensource.com Errors-To: xen-devel-bounces@lists.xensource.com Hi all, this is the fourth version of the patch series to introduce upstream qemu and seabios in the xen-unstable build system. Changes to v3: - reduce the scope of git-checkout.sh, now it only does what the name says; calling "configure" is responsibility of the caller. As a result of this change, the build still works when the user specifies a local directory in the CONFIG_QEMU environmental variable; - use a more official qemu repository hosted on xenbits; - use a changeset as QEMU_UPSTREAM_TAG rather than a branch name. Changes to v2: - move tools/git-checkout.sh to scripts/git-checkout.sh; - use git-checkout.sh for seabios; - improve seabios integration with tools/firmware make system; - add qemu-xen-traditional, qemu-xen and seabios dir entries to .hgignore. Changes to v1: - always build upstream qemu and seabios, rather than introducing them as an option. Cheers, Stefano _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel From xen-devel-bounces@lists.xensource.com Thu Sep 15 07:49:01 2011 Return-path: Envelope-to: www-data@lists.xensource.com Delivery-date: Thu, 15 Sep 2011 07:49:01 -0700 Received: from localhost ([127.0.0.1] helo=lists.colo.xensource.com) by lists.xensource.com with esmtp (Exim 4.43) id 1R4DFN-0001JV-I5; Thu, 15 Sep 2011 07:49:01 -0700 Received: from mail27.messagelabs.com ([193.109.254.147]) by lists.xensource.com with esmtp (Exim 4.43) id 1R4DDf-0000ka-Ej for xen-devel@lists.xensource.com; Thu, 15 Sep 2011 07:47:16 -0700 X-Env-Sender: Paul.Durrant@citrix.com X-Msg-Ref: server-11.tower-27.messagelabs.com!1316098023!37562814!2 X-Originating-IP: [62.200.22.115] X-StarScan-Version: 6.4.1; banners=-,-,- X-VirusChecked: Checked Received: (qmail 7144 invoked from network); 15 Sep 2011 14:47:04 -0000 Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115) by server-11.tower-27.messagelabs.com with RC4-SHA encrypted SMTP; 15 Sep 2011 14:47:04 -0000 X-IronPort-AV: E=Sophos;i="4.68,387,1312156800"; d="scan'208";a="7861003" Received: from lonpmailmx02.citrite.net ([10.30.203.163]) by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5; 15 Sep 2011 14:47:12 +0000 Received: from LONPMAILBOX01.citrite.net ([10.30.224.160]) by LONPMAILMX02.citrite.net ([10.30.203.163]) with mapi; Thu, 15 Sep 2011 15:47:12 +0100 From: Paul Durrant To: Keir Fraser , "xen-devel@lists.xensource.com" Date: Thu, 15 Sep 2011 15:47:22 +0100 Subject: RE: [Xen-devel] [PATCH] Tidy up the viridian code a little and flesh out the APIC assist MSR Thread-Topic: [Xen-devel] [PATCH] Tidy up the viridian code a little and flesh out the APIC assist MSR Thread-Index: AcxzcgONtakPWFHMdk29U12pniwCEwAQBjXQAACEZ70AAGXvAA== Message-ID: <291EDFCB1E9E224A99088639C4762022B44F047181@LONPMAILBOX01.citrite.net> References: <291EDFCB1E9E224A99088639C4762022B44F04717B@LONPMAILBOX01.citrite.net> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: X-BeenThere: xen-devel@lists.xensource.com X-Mailman-Version: 2.1.5 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xensource.com Errors-To: xen-devel-bounces@lists.xensource.com Yep. I'm hoping to start making use of apic assist once I've got specific e= vtchn -> hvm irq mappings working. I can get windows to give me edge trigge= red interrupts so hopefully I can persuade it to skip the eoi by setting th= e apic assist bit prior to injection. Keeping track of the pfn will, of cou= rse, become quite important at this point :-) For now, I don't think window= s reads the msr again after boot so losing the value across a save/restore = probably doesn't matter much. Paul > -----Original Message----- > From: Keir Fraser [mailto:keir.xen@gmail.com] > Sent: 15 September 2011 07:32 > To: Paul Durrant; xen-devel@lists.xensource.com > Subject: Re: [Xen-devel] [PATCH] Tidy up the viridian code a little > and flesh out the APIC assist MSR > > Might need a shiny new Viridian struct type for our save format, > which can then be extended with more Viridian-y stuff as required. > > -- Keir > > On 15/09/2011 15:19, "Paul Durrant" wrote: > > > Good point. I guess I may need to explicitly save/restore the apic > assist pfn. > > I'll check. > > > > Paul > > > >> -----Original Message----- > >> From: Keir Fraser [mailto:keir.xen@gmail.com] > >> Sent: 14 September 2011 23:38 > >> To: Paul Durrant; xen-devel@lists.xensource.com > >> Subject: Re: [Xen-devel] [PATCH] Tidy up the viridian code a > little > >> and flesh out the APIC assist MSR > >> > >> On 15/09/2011 06:13, "Paul Durrant" > wrote: > >> > >>> # HG changeset patch > >>> # User Paul Durrant # Date 1316063461 > - > >> 3600 > >>> # Node ID a08073c5cf28ab76893102cc7a8d20bf3e5e15ae > >>> # Parent e90438f6e6d1585a71b18784a99c162b5d95f390 > >>> Tidy up the viridian code a little and flesh out the APIC assist > >> MSR > >>> handling code. > >>> > >>> We don't say we that handle that MSR but Windows assumes it. In > >>> Windows 7 it just wrote to the MSR and we used to handle that > ok. > >>> Windows 8 also reads from the MSR so we need to keep a record of > >> the contents. > >> > >> Does this work properly across save/restore? > >> > >> -- Keir > >> > >>> Signed-off-by: Paul Durrant > >>> > >>> diff -r e90438f6e6d1 -r a08073c5cf28 xen/arch/x86/hvm/viridian.c > >>> --- a/xen/arch/x86/hvm/viridian.c Wed Sep 14 11:38:13 2011 +0100 > >>> +++ b/xen/arch/x86/hvm/viridian.c Thu Sep 15 06:11:01 2011 +0100 > >>> @@ -96,9 +96,43 @@ int cpuid_viridian_leaves(unsigned int l > >>> return 1; > >>> } > >>> > >>> -static void enable_hypercall_page(void) > >>> +void dump_guest_os_id(struct domain *d) > >>> { > >>> - struct domain *d =3D current->domain; > >>> + gdprintk(XENLOG_INFO, "GUEST_OS_ID:\n"); > >>> + gdprintk(XENLOG_INFO, "\tvendor: %x\n", > >>> + d- > >>> arch.hvm_domain.viridian.guest_os_id.fields.vendor); > >>> + gdprintk(XENLOG_INFO, "\tos: %x\n", > >>> + d->arch.hvm_domain.viridian.guest_os_id.fields.os); > >>> + gdprintk(XENLOG_INFO, "\tmajor: %x\n", > >>> + d- > >>> arch.hvm_domain.viridian.guest_os_id.fields.major); > >>> + gdprintk(XENLOG_INFO, "\tminor: %x\n", > >>> + d- > >>> arch.hvm_domain.viridian.guest_os_id.fields.minor); > >>> + gdprintk(XENLOG_INFO, "\tsp: %x\n", > >>> + d- > >>> arch.hvm_domain.viridian.guest_os_id.fields.service_pack); > >>> + gdprintk(XENLOG_INFO, "\tbuild: %x\n", > >>> + > >>> +d->arch.hvm_domain.viridian.guest_os_id.fields.build_number); > >>> +} > >>> + > >>> +void dump_hypercall(struct domain *d) { > >>> + gdprintk(XENLOG_INFO, "HYPERCALL:\n"); > >>> + gdprintk(XENLOG_INFO, "\tenabled: %x\n", > >>> + d- > >>> arch.hvm_domain.viridian.hypercall_gpa.fields.enabled); > >>> + gdprintk(XENLOG_INFO, "\tpfn: %lx\n", > >>> + (unsigned > >>> long)d->arch.hvm_domain.viridian.hypercall_gpa.fields.pfn); > >>> +} > >>> + > >>> +void dump_apic_assist(struct vcpu *v) { > >>> + gdprintk(XENLOG_INFO, "APIC_ASSIST[%d]:\n", v->vcpu_id); > >>> + gdprintk(XENLOG_INFO, "\tenabled: %x\n", > >>> + v- > >>> arch.hvm_vcpu.viridian.apic_assist.fields.enabled); > >>> + gdprintk(XENLOG_INFO, "\tpfn: %lx\n", > >>> + (unsigned > >>> +long)v->arch.hvm_vcpu.viridian.apic_assist.fields.pfn); > >>> +} > >>> + > >>> +static void enable_hypercall_page(struct domain *d) { > >>> unsigned long gmfn =3D > >>> d->arch.hvm_domain.viridian.hypercall_gpa.fields.pfn; > >>> unsigned long mfn =3D gmfn_to_mfn(d, gmfn); > >>> uint8_t *p; > >>> @@ -130,9 +164,43 @@ static void enable_hypercall_page(void) > >>> put_page_and_type(mfn_to_page(mfn)); > >>> } > >>> > >>> +void initialize_apic_assist(struct vcpu *v) { > >>> + struct domain *d =3D v->domain; > >>> + unsigned long gmfn =3D v- > >>> arch.hvm_vcpu.viridian.apic_assist.fields.pfn; > >>> + unsigned long mfn =3D gmfn_to_mfn(d, gmfn); > >>> + uint8_t *p; > >>> + > >>> + /* > >>> + * We don't support the APIC assist page, and that fact is > >> reflected in > >>> + * our CPUID flags. However, Newer versions of Windows have > a > >> bug which > >>> + * means that they don't recognise that, and tries to use > the > >> page > >>> + * anyway. We therefore have to fake up just enough to keep > >>> + windows > >>> happy. > >>> + * > >>> + * See > >>> + http://msdn.microsoft.com/en- > us/library/ff538657%28VS.85%29.aspx > >>> for > >>> + * details of how Windows uses the page. > >>> + */ > >>> + > >>> + if ( !mfn_valid(mfn) || > >>> + !get_page_and_type(mfn_to_page(mfn), d, > >> PGT_writable_page) ) > >>> + { > >>> + gdprintk(XENLOG_WARNING, "Bad GMFN %lx (MFN %lx)\n", > >> gmfn, mfn); > >>> + return; > >>> + } > >>> + > >>> + p =3D map_domain_page(mfn); > >>> + > >>> + *(u32 *)p =3D 0; > >>> + > >>> + unmap_domain_page(p); > >>> + > >>> + put_page_and_type(mfn_to_page(mfn)); > >>> +} > >>> + > >>> int wrmsr_viridian_regs(uint32_t idx, uint64_t val) { > >>> - struct domain *d =3D current->domain; > >>> + struct vcpu *v =3D current; > >>> + struct domain *d =3D v->domain; > >>> > >>> if ( !is_viridian_domain(d) ) > >>> return 0; > >>> @@ -142,44 +210,29 @@ int wrmsr_viridian_regs(uint32_t idx, ui > >>> case VIRIDIAN_MSR_GUEST_OS_ID: > >>> perfc_incr(mshv_wrmsr_osid); > >>> d->arch.hvm_domain.viridian.guest_os_id.raw =3D val; > >>> - gdprintk(XENLOG_INFO, "Guest os:\n"); > >>> - gdprintk(XENLOG_INFO, "\tvendor: %x\n", > >>> - d- > >>> arch.hvm_domain.viridian.guest_os_id.fields.vendor); > >>> - gdprintk(XENLOG_INFO, "\tos: %x\n", > >>> - d- > >>> arch.hvm_domain.viridian.guest_os_id.fields.os); > >>> - gdprintk(XENLOG_INFO, "\tmajor: %x\n", > >>> - d- > >>> arch.hvm_domain.viridian.guest_os_id.fields.major); > >>> - gdprintk(XENLOG_INFO, "\tminor: %x\n", > >>> - d- > >>> arch.hvm_domain.viridian.guest_os_id.fields.minor); > >>> - gdprintk(XENLOG_INFO, "\tsp: %x\n", > >>> - d- > >>> arch.hvm_domain.viridian.guest_os_id.fields.service_pack); > >>> - gdprintk(XENLOG_INFO, "\tbuild: %x\n", > >>> - d- > >>> arch.hvm_domain.viridian.guest_os_id.fields.build_number); > >>> + dump_guest_os_id(d); > >>> break; > >>> > >>> case VIRIDIAN_MSR_HYPERCALL: > >>> perfc_incr(mshv_wrmsr_hc_page); > >>> - gdprintk(XENLOG_INFO, "Set hypercall page > %"PRIx64".\n", > >> val); > >>> - if ( d->arch.hvm_domain.viridian.guest_os_id.raw =3D=3D 0 ) > >>> - break; > >>> d->arch.hvm_domain.viridian.hypercall_gpa.raw =3D val; > >>> + dump_hypercall(d); > >>> if ( d- > >>> arch.hvm_domain.viridian.hypercall_gpa.fields.enabled ) > >>> - enable_hypercall_page(); > >>> + enable_hypercall_page(d); > >>> break; > >>> > >>> case VIRIDIAN_MSR_VP_INDEX: > >>> perfc_incr(mshv_wrmsr_vp_index); > >>> - gdprintk(XENLOG_INFO, "Set VP index %"PRIu64".\n", > val); > >>> break; > >>> > >>> case VIRIDIAN_MSR_EOI: > >>> perfc_incr(mshv_wrmsr_eoi); > >>> - vlapic_EOI_set(vcpu_vlapic(current)); > >>> + vlapic_EOI_set(vcpu_vlapic(v)); > >>> break; > >>> > >>> case VIRIDIAN_MSR_ICR: { > >>> u32 eax =3D (u32)val, edx =3D (u32)(val >> 32); > >>> - struct vlapic *vlapic =3D vcpu_vlapic(current); > >>> + struct vlapic *vlapic =3D vcpu_vlapic(v); > >>> perfc_incr(mshv_wrmsr_icr); > >>> eax &=3D ~(1 << 12); > >>> edx &=3D 0xff000000; > >>> @@ -191,31 +244,15 @@ int wrmsr_viridian_regs(uint32_t idx, ui > >>> > >>> case VIRIDIAN_MSR_TPR: > >>> perfc_incr(mshv_wrmsr_tpr); > >>> - vlapic_set_reg(vcpu_vlapic(current), APIC_TASKPRI, > >> (uint8_t)val); > >>> + vlapic_set_reg(vcpu_vlapic(v), APIC_TASKPRI, > >> (uint8_t)val); > >>> break; > >>> > >>> case VIRIDIAN_MSR_APIC_ASSIST: > >>> - /* > >>> - * We don't support the APIC assist page, and that fact > >> is reflected > >>> in > >>> - * our CPUID flags. However, Windows 7 build 7000 has a > >> bug which > >>> means > >>> - * that it doesn't recognise that, and tries to use the > >> page anyway. > >>> We > >>> - * therefore have to fake up just enough to keep win7 > >> happy. > >>> - * Fortunately, that's really easy: just setting the > >> first four bytes > >>> - * in the page to zero effectively disables the page > >> again, so that's > >>> - * what we do. Semantically, the first four bytes are > >> supposed to be > >>> a > >>> - * flag saying whether the guest really needs to issue > an > >> EOI. > >>> Setting > >>> - * that flag to zero means that it must always issue > one, > >> which is > >>> what > >>> - * we want. Once a page has been repurposed as an APIC > >> assist page > >>> the > >>> - * guest isn't allowed to set anything in it, so the > flag > >> remains > >>> zero > >>> - * and all is fine. The guest is allowed to clear flags > >> in the page, > >>> - * but that doesn't cause us any problems. > >>> - */ > >>> - if ( val & 1 ) /* APIC assist page enabled? */ > >>> - { > >>> - uint32_t word =3D 0; > >>> - paddr_t page_start =3D val & ~1ul; > >>> - (void)hvm_copy_to_guest_phys(page_start, &word, > >> sizeof(word)); > >>> - } > >>> + perfc_incr(mshv_wrmsr_apic_msr); > >>> + v->arch.hvm_vcpu.viridian.apic_assist.raw =3D val; > >>> + dump_apic_assist(v); > >>> + if (v- > >arch.hvm_vcpu.viridian.apic_assist.fields.enabled) > >>> + initialize_apic_assist(v); > >>> break; > >>> > >>> default: > >>> @@ -228,20 +265,21 @@ int wrmsr_viridian_regs(uint32_t idx, ui > >> int > >>> rdmsr_viridian_regs(uint32_t idx, uint64_t *val) { > >>> struct vcpu *v =3D current; > >>> + struct domain *d =3D v->domain; > >>> > >>> - if ( !is_viridian_domain(v->domain) ) > >>> + if ( !is_viridian_domain(d) ) > >>> return 0; > >>> > >>> switch ( idx ) > >>> { > >>> case VIRIDIAN_MSR_GUEST_OS_ID: > >>> perfc_incr(mshv_rdmsr_osid); > >>> - *val =3D v->domain- > >>> arch.hvm_domain.viridian.guest_os_id.raw; > >>> + *val =3D d->arch.hvm_domain.viridian.guest_os_id.raw; > >>> break; > >>> > >>> case VIRIDIAN_MSR_HYPERCALL: > >>> perfc_incr(mshv_rdmsr_hc_page); > >>> - *val =3D v->domain- > >>> arch.hvm_domain.viridian.hypercall_gpa.raw; > >>> + *val =3D d->arch.hvm_domain.viridian.hypercall_gpa.raw; > >>> break; > >>> > >>> case VIRIDIAN_MSR_VP_INDEX: > >>> @@ -260,6 +298,11 @@ int rdmsr_viridian_regs(uint32_t idx, ui > >>> *val =3D vlapic_get_reg(vcpu_vlapic(v), APIC_TASKPRI); > >>> break; > >>> > >>> + case VIRIDIAN_MSR_APIC_ASSIST: > >>> + perfc_incr(mshv_rdmsr_apic_msr); > >>> + *val =3D v->arch.hvm_vcpu.viridian.apic_assist.raw; > >>> + break; > >>> + > >>> default: > >>> return 0; > >>> } > >>> diff -r e90438f6e6d1 -r a08073c5cf28 xen/include/asm- > >> x86/hvm/vcpu.h > >>> --- a/xen/include/asm-x86/hvm/vcpu.h Wed Sep 14 11:38:13 2011 > >> +0100 > >>> +++ b/xen/include/asm-x86/hvm/vcpu.h Thu Sep 15 06:11:01 2011 > >> +0100 > >>> @@ -23,6 +23,7 @@ > >>> #include > >>> #include > >>> #include > >>> +#include > >>> #include > >>> #include > >>> #include > >>> @@ -163,6 +164,8 @@ struct hvm_vcpu { > >>> int inject_trap; /* -1 for nothing to > inject > >> */ > >>> int inject_error_code; > >>> unsigned long inject_cr2; > >>> + > >>> + struct viridian_vcpu viridian; > >>> }; > >>> > >>> #endif /* __ASM_X86_HVM_VCPU_H__ */ diff -r e90438f6e6d1 -r > >>> a08073c5cf28 xen/include/asm-x86/hvm/viridian.h > >>> --- a/xen/include/asm-x86/hvm/viridian.h Wed Sep 14 11:38:13 > 2011 > >>> +0100 > >>> +++ b/xen/include/asm-x86/hvm/viridian.h Thu Sep 15 06:11:01 > 2011 > >>> +++ +0100 > >>> @@ -9,6 +9,21 @@ > >>> #ifndef __ASM_X86_HVM_VIRIDIAN_H__ > >>> #define __ASM_X86_HVM_VIRIDIAN_H__ > >>> > >>> +union viridian_apic_assist > >>> +{ uint64_t raw; > >>> + struct > >>> + { > >>> + uint64_t enabled:1; > >>> + uint64_t reserved_preserved:11; > >>> + uint64_t pfn:48; > >>> + } fields; > >>> +}; > >>> + > >>> +struct viridian_vcpu > >>> +{ > >>> + union viridian_apic_assist apic_assist; }; > >>> + > >>> union viridian_guest_os_id > >>> { > >>> uint64_t raw; > >>> diff -r e90438f6e6d1 -r a08073c5cf28 xen/include/asm- > >> x86/perfc_defn.h > >>> --- a/xen/include/asm-x86/perfc_defn.h Wed Sep 14 11:38:13 2011 > >> +0100 > >>> +++ b/xen/include/asm-x86/perfc_defn.h Thu Sep 15 06:11:01 2011 > >> +0100 > >>> @@ -120,12 +120,14 @@ PERFCOUNTER(mshv_rdmsr_hc_page, > >>> PERFCOUNTER(mshv_rdmsr_vp_index, "MS Hv rdmsr vp index") > >>> PERFCOUNTER(mshv_rdmsr_icr, "MS Hv rdmsr icr") > >>> PERFCOUNTER(mshv_rdmsr_tpr, "MS Hv rdmsr tpr") > >>> +PERFCOUNTER(mshv_rdmsr_apic_assist, "MS Hv rdmsr APIC > >> assist") > >>> PERFCOUNTER(mshv_wrmsr_osid, "MS Hv wrmsr Guest OS > >> ID") > >>> PERFCOUNTER(mshv_wrmsr_hc_page, "MS Hv wrmsr hypercall > >> page") > >>> PERFCOUNTER(mshv_wrmsr_vp_index, "MS Hv wrmsr vp index") > >>> PERFCOUNTER(mshv_wrmsr_icr, "MS Hv wrmsr icr") > >>> PERFCOUNTER(mshv_wrmsr_tpr, "MS Hv wrmsr tpr") > >>> PERFCOUNTER(mshv_wrmsr_eoi, "MS Hv wrmsr eoi") > >>> +PERFCOUNTER(mshv_wrmsr_apic_assist, "MS Hv wrmsr APIC > >> assist") > >>> > >>> PERFCOUNTER(realmode_emulations, "realmode instructions > >> emulated") > >>> PERFCOUNTER(realmode_exits, "vmexits from realmode") > >>> > >>> _______________________________________________ > >>> Xen-devel mailing list > >>> Xen-devel@lists.xensource.com > >>> http://lists.xensource.com/xen-devel > >> > > > _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel From xen-devel-bounces@lists.xensource.com Thu Sep 15 07:50:29 2011 Return-path: Envelope-to: www-data@lists.xensource.com Delivery-date: Thu, 15 Sep 2011 07:50:29 -0700 Received: from localhost ([127.0.0.1] helo=lists.colo.xensource.com) by lists.xensource.com with esmtp (Exim 4.43) id 1R4DGn-0001mD-Sx; Thu, 15 Sep 2011 07:50:29 -0700 Received: from mail27.messagelabs.com ([193.109.254.147]) by lists.xensource.com with esmtp (Exim 4.43) id 1R4DEa-00012w-8I for xen-devel@lists.xensource.com; Thu, 15 Sep 2011 07:48:13 -0700 X-Env-Sender: Stefano.Stabellini@eu.citrix.com X-Msg-Ref: server-12.tower-27.messagelabs.com!1316098072!42578603!1 X-Originating-IP: [66.165.176.63] X-StarScan-Version: 6.4.1; banners=-,-,- X-VirusChecked: Checked Received: (qmail 29788 invoked from network); 15 Sep 2011 14:47:54 -0000 Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63) by server-12.tower-27.messagelabs.com with RC4-SHA encrypted SMTP; 15 Sep 2011 14:47:54 -0000 X-IronPort-AV: E=Sophos;i="4.68,387,1312171200"; d="scan'208";a="163397315" Received: from ftlpmailmx01.citrite.net ([10.13.107.65]) by FTLPIPO02.CITRIX.COM with ESMTP/TLS/RC4-MD5; 15 Sep 2011 10:48:01 -0400 Received: from smtp01.ad.xensource.com (10.219.128.104) by smtprelay.citrix.com (10.13.107.65) with Microsoft SMTP Server id 8.3.137.0; Thu, 15 Sep 2011 10:48:00 -0400 Received: from localhost.localdomain (kaball.uk.xensource.com [10.80.2.59]) by smtp01.ad.xensource.com (8.13.1/8.13.1) with ESMTP id p8FElrIo028104; Thu, 15 Sep 2011 07:47:54 -0700 From: To: xen-devel@lists.xensource.com Date: Thu, 15 Sep 2011 15:56:37 +0100 Message-ID: <1316098600-19694-1-git-send-email-stefano.stabellini@eu.citrix.com> X-Mailer: git-send-email 1.7.0.4 In-Reply-To: References: MIME-Version: 1.0 Content-Type: text/plain Cc: Ian.Jackson@eu.citrix.com, Stefano Stabellini , keir@xen.org, Ian.Campbell@citrix.com, Stefano.Stabellini@eu.citrix.com Subject: [Xen-devel] # Parent 0312575dc35e4294eb50e365b2c10078914daca8 X-BeenThere: xen-devel@lists.xensource.com X-Mailman-Version: 2.1.5 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xensource.com Errors-To: xen-devel-bounces@lists.xensource.com Subject: [PATCH v3 1/4] Introduce git-checkout.sh Introduce a script to perform git checkout on an external git tree; use git-checkout.sh in ioemu-dir-find. Signed-off-by: Stefano Stabellini diff --git a/.hgignore b/.hgignore --- a/.hgignore +++ b/.hgignore @@ -291,7 +291,7 @@ ^tools/xm-test/lib/XmTestLib/config.py$ ^tools/xm-test/lib/XmTestReport/xmtest.py$ ^tools/xm-test/tests/.*\.test$ -^tools/ioemu-remote +^tools/ioemu-dir-remote ^tools/ioemu-dir$ ^tools/ocaml/.*/.*\.annot$ ^tools/ocaml/.*/.*\.cmx?a$ diff --git a/scripts/git-checkout.sh b/scripts/git-checkout.sh new file mode 100755 --- /dev/null +++ b/scripts/git-checkout.sh @@ -0,0 +1,21 @@ +#!/bin/bash + +TREE=$1 +TAG=$2 +DIR=$3 + + +if test \! -d $DIR-remote; then + rm -rf $DIR-remote $DIR-remote.tmp; + mkdir $DIR-remote.tmp; rmdir $DIR-remote.tmp; + git clone $TREE $DIR-remote.tmp; + if test "$TAG" ; then + cd $DIR-remote.tmp + git branch -D dummy >/dev/null 2>&1 ||: + git checkout -b dummy $TAG + cd .. + fi + mv $DIR-remote.tmp $DIR-remote +fi +rm -f $DIR +ln -sf $DIR-remote $DIR diff --git a/tools/Makefile b/tools/Makefile --- a/tools/Makefile +++ b/tools/Makefile @@ -70,7 +70,7 @@ clean: subdirs-clean .PHONY: distclean distclean: subdirs-distclean - rm -rf ioemu-dir ioemu-remote + rm -rf ioemu-dir ioemu-dir-remote ifneq ($(XEN_COMPILE_ARCH),$(XEN_TARGET_ARCH)) IOEMU_CONFIGURE_CROSS ?= --cpu=$(XEN_TARGET_ARCH) \ @@ -88,20 +88,7 @@ ioemu-dir-find: if test -d $(CONFIG_QEMU); then \ mkdir -p ioemu-dir; \ else \ - if [ ! -d ioemu-remote ]; then \ - rm -rf ioemu-remote ioemu-remote.tmp; \ - mkdir ioemu-remote.tmp; rmdir ioemu-remote.tmp; \ - $(GIT) clone $(CONFIG_QEMU) ioemu-remote.tmp; \ - if [ "$(QEMU_TAG)" ]; then \ - cd ioemu-remote.tmp; \ - $(GIT) branch -D dummy >/dev/null 2>&1 ||:; \ - $(GIT) checkout -b dummy $(QEMU_TAG); \ - cd ..; \ - fi; \ - mv ioemu-remote.tmp ioemu-remote; \ - fi; \ - rm -f ioemu-dir; \ - ln -sf ioemu-remote ioemu-dir; \ + $(XEN_ROOT)/scripts/git-checkout.sh $(CONFIG_QEMU) $(QEMU_TAG) ioemu-dir; \ fi set -e; \ $(buildmakevars2shellvars); \ @@ -112,7 +99,7 @@ ioemu-dir-find: ioemu-dir-force-update: set -ex; \ if [ "$(QEMU_TAG)" ]; then \ - cd ioemu-remote; \ + cd ioemu-dir-remote; \ $(GIT) fetch origin; \ $(GIT) reset --hard $(QEMU_TAG); \ fi _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel From xen-devel-bounces@lists.xensource.com Thu Sep 15 07:51:42 2011 Return-path: Envelope-to: www-data@lists.xensource.com Delivery-date: Thu, 15 Sep 2011 07:51:42 -0700 Received: from localhost ([127.0.0.1] helo=lists.colo.xensource.com) by lists.xensource.com with esmtp (Exim 4.43) id 1R4DHy-000298-OT; Thu, 15 Sep 2011 07:51:42 -0700 Received: from mail27.messagelabs.com ([193.109.254.147]) by lists.xensource.com with esmtp (Exim 4.43) id 1R4DEb-00013E-Fd for xen-devel@lists.xensource.com; Thu, 15 Sep 2011 07:48:13 -0700 X-Env-Sender: Stefano.Stabellini@eu.citrix.com X-Msg-Ref: server-12.tower-27.messagelabs.com!1316098072!42578603!2 X-Originating-IP: [66.165.176.63] X-StarScan-Version: 6.4.1; banners=-,-,- X-VirusChecked: Checked Received: (qmail 29867 invoked from network); 15 Sep 2011 14:47:55 -0000 Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63) by server-12.tower-27.messagelabs.com with RC4-SHA encrypted SMTP; 15 Sep 2011 14:47:55 -0000 X-IronPort-AV: E=Sophos;i="4.68,387,1312171200"; d="scan'208";a="163397344" Received: from ftlpmailmx01.citrite.net ([10.13.107.65]) by FTLPIPO02.CITRIX.COM with ESMTP/TLS/RC4-MD5; 15 Sep 2011 10:48:07 -0400 Received: from smtp01.ad.xensource.com (10.219.128.104) by smtprelay.citrix.com (10.13.107.65) with Microsoft SMTP Server id 8.3.137.0; Thu, 15 Sep 2011 10:48:07 -0400 Received: from localhost.localdomain (kaball.uk.xensource.com [10.80.2.59]) by smtp01.ad.xensource.com (8.13.1/8.13.1) with ESMTP id p8FElrIp028104; Thu, 15 Sep 2011 07:47:55 -0700 From: To: xen-devel@lists.xensource.com Date: Thu, 15 Sep 2011 15:56:38 +0100 Message-ID: <1316098600-19694-2-git-send-email-stefano.stabellini@eu.citrix.com> X-Mailer: git-send-email 1.7.0.4 In-Reply-To: References: MIME-Version: 1.0 Content-Type: text/plain Cc: Ian.Jackson@eu.citrix.com, Stefano Stabellini , keir@xen.org, Ian.Campbell@citrix.com, Stefano.Stabellini@eu.citrix.com Subject: [Xen-devel] # Parent 0312575dc35e4294eb50e365b2c10078914daca8 X-BeenThere: xen-devel@lists.xensource.com X-Mailman-Version: 2.1.5 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xensource.com Errors-To: xen-devel-bounces@lists.xensource.com Subject: [PATCH v3 2/4] Rename ioemu-dir as qemu-xen-traditional-dir Signed-off-by: Stefano Stabellini diff -r 1993c6e145b5 .hgignore --- a/.hgignore Thu Sep 15 09:38:49 2011 +0000 +++ b/.hgignore Thu Sep 15 11:08:51 2011 +0000 @@ -291,8 +291,8 @@ ^tools/xm-test/lib/XmTestLib/config.py$ ^tools/xm-test/lib/XmTestReport/xmtest.py$ ^tools/xm-test/tests/.*\.test$ -^tools/ioemu-dir-remote -^tools/ioemu-dir$ +^tools/qemu-xen-traditional-dir-remote +^tools/qemu-xen-traditional-dir$ ^tools/ocaml/.*/.*\.annot$ ^tools/ocaml/.*/.*\.cmx?a$ ^tools/ocaml/.*/META$ diff -r 1993c6e145b5 Makefile --- a/Makefile Thu Sep 15 09:38:49 2011 +0000 +++ b/Makefile Thu Sep 15 11:08:51 2011 +0000 @@ -70,7 +70,7 @@ install-tools: $(MAKE) -C tools install ifeq ($(CONFIG_IOEMU),y) -install-tools: tools/ioemu-dir +install-tools: tools/qemu-xen-traditional-dir endif .PHONY: install-kernels @@ -78,18 +78,18 @@ install-kernels: for i in $(XKERNELS) ; do $(MAKE) $$i-install || exit 1; done .PHONY: install-stubdom -install-stubdom: tools/ioemu-dir install-tools +install-stubdom: tools/qemu-xen-traditional-dir install-tools $(MAKE) -C stubdom install ifeq (x86_64,$(XEN_TARGET_ARCH)) XEN_TARGET_ARCH=x86_32 $(MAKE) -C stubdom install-grub endif -tools/ioemu-dir: - $(MAKE) -C tools ioemu-dir-find +tools/qemu-xen-traditional-dir: + $(MAKE) -C tools qemu-xen-traditional-dir-find -.PHONY: tools/ioemu-dir-force-update -tools/ioemu-dir-force-update: - $(MAKE) -C tools ioemu-dir-force-update +.PHONY: tools/qemu-xen-traditional-dir-force-update +tools/qemu-xen-traditional-dir-force-update: + $(MAKE) -C tools qemu-xen-traditional-dir-force-update .PHONY: install-docs install-docs: diff -r 1993c6e145b5 stubdom/Makefile --- a/stubdom/Makefile Thu Sep 15 09:38:49 2011 +0000 +++ b/stubdom/Makefile Thu Sep 15 11:08:51 2011 +0000 @@ -218,15 +218,15 @@ cross-ocaml: $(OCAML_STAMPFILE) QEMU_ROOT := $(shell if [ -d "$(CONFIG_QEMU)" ]; then echo "$(CONFIG_QEMU)"; else echo .; fi) ifeq ($(QEMU_ROOT),.) -$(XEN_ROOT)/tools/ioemu-dir: - $(CROSS_MAKE) -C $(XEN_ROOT)/tools ioemu-dir-find +$(XEN_ROOT)/tools/qemu-xen-traditional-dir: + $(CROSS_MAKE) -C $(XEN_ROOT)/tools qemu-xen-traditional-dir-find -ioemu/linkfarm.stamp: $(XEN_ROOT)/tools/ioemu-dir +ioemu/linkfarm.stamp: $(XEN_ROOT)/tools/qemu-xen-traditional-dir mkdir -p ioemu set -e; \ $(buildmakevars2shellvars); \ cd ioemu; \ - src="$$XEN_ROOT/tools/ioemu-dir"; export src; \ + src="$$XEN_ROOT/tools/qemu-xen-traditional-dir"; export src; \ (cd $$src && find * -type d -print) | xargs mkdir -p; \ (cd $$src && find * ! -type l -type f $(addprefix ! -name , \ '*.[oda1]' 'config-*' config.mak qemu-dm qemu-img-xen \ diff -r 1993c6e145b5 tools/Makefile --- a/tools/Makefile Thu Sep 15 09:38:49 2011 +0000 +++ b/tools/Makefile Thu Sep 15 11:08:51 2011 +0000 @@ -30,7 +30,7 @@ SUBDIRS-$(LIBXENAPI_BINDINGS) += libxen # do not recurse in to a dir we are about to delete ifneq "$(MAKECMDGOALS)" "distclean" -SUBDIRS-$(CONFIG_IOEMU) += ioemu-dir +SUBDIRS-$(CONFIG_IOEMU) += qemu-xen-traditional-dir endif SUBDIRS-y += xenpmd @@ -70,7 +70,7 @@ clean: subdirs-clean .PHONY: distclean distclean: subdirs-distclean - rm -rf ioemu-dir ioemu-dir-remote + rm -rf qemu-xen-traditional-dir qemu-xen-traditional-dir-remote ifneq ($(XEN_COMPILE_ARCH),$(XEN_TARGET_ARCH)) IOEMU_CONFIGURE_CROSS ?= --cpu=$(XEN_TARGET_ARCH) \ @@ -83,33 +83,33 @@ ifneq ($(QEMU_ROOT),.) export QEMU_ROOT endif -ioemu-dir-find: +qemu-xen-traditional-dir-find: set -ex; \ if test -d $(CONFIG_QEMU); then \ - mkdir -p ioemu-dir; \ + mkdir -p qemu-xen-traditional-dir; \ else \ - $(XEN_ROOT)/scripts/git-checkout.sh $(CONFIG_QEMU) $(QEMU_TAG) ioemu-dir; \ + $(XEN_ROOT)/scripts/git-checkout.sh $(CONFIG_QEMU) $(QEMU_TAG) qemu-xen-traditional-dir; \ fi set -e; \ $(buildmakevars2shellvars); \ - cd ioemu-dir; \ + cd qemu-xen-traditional-dir; \ $(QEMU_ROOT)/xen-setup $(IOEMU_CONFIGURE_CROSS) -.PHONY: ioemu-dir-force-update -ioemu-dir-force-update: +.PHONY: qemu-xen-traditional-dir-force-update +qemu-xen-traditional-dir-force-update: set -ex; \ if [ "$(QEMU_TAG)" ]; then \ - cd ioemu-dir-remote; \ + cd qemu-xen-traditional-dir-remote; \ $(GIT) fetch origin; \ $(GIT) reset --hard $(QEMU_TAG); \ fi -subdir-all-ioemu-dir subdir-install-ioemu-dir: ioemu-dir-find +subdir-all-qemu-xen-traditional-dir subdir-install-qemu-xen-traditional-dir: qemu-xen-traditional-dir-find -subdir-clean-ioemu-dir: - set -e; if test -d ioemu-dir/.; then \ +subdir-clean-qemu-xen-traditional-dir: + set -e; if test -d qemu-xen-traditional-dir/.; then \ $(buildmakevars2shellvars); \ - $(MAKE) -C ioemu-dir clean; \ + $(MAKE) -C qemu-xen-traditional-dir clean; \ fi subdir-clean-debugger/gdbsx subdir-distclean-debugger/gdbsx: .phony _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel From xen-devel-bounces@lists.xensource.com Thu Sep 15 07:52:37 2011 Return-path: Envelope-to: www-data@lists.xensource.com Delivery-date: Thu, 15 Sep 2011 07:52:37 -0700 Received: from localhost ([127.0.0.1] helo=lists.colo.xensource.com) by lists.xensource.com with esmtp (Exim 4.43) id 1R4DIr-0002Wb-Fi; Thu, 15 Sep 2011 07:52:37 -0700 Received: from mail27.messagelabs.com ([193.109.254.147]) by lists.xensource.com with esmtp (Exim 4.43) id 1R4DEb-00013F-G4 for xen-devel@lists.xensource.com; Thu, 15 Sep 2011 07:48:13 -0700 X-Env-Sender: Stefano.Stabellini@eu.citrix.com X-Msg-Ref: server-4.tower-27.messagelabs.com!1316098072!40406386!1 X-Originating-IP: [66.165.176.89] X-StarScan-Version: 6.4.1; banners=-,-,- X-VirusChecked: Checked Received: (qmail 10090 invoked from network); 15 Sep 2011 14:47:53 -0000 Received: from smtp.citrix.com (HELO SMTP.CITRIX.COM) (66.165.176.89) by server-4.tower-27.messagelabs.com with RC4-SHA encrypted SMTP; 15 Sep 2011 14:47:53 -0000 X-IronPort-AV: E=Sophos;i="4.68,387,1312171200"; d="scan'208";a="17328681" Received: from ftlpmailmx01.citrite.net ([10.13.107.65]) by FTLPIPO01.CITRIX.COM with ESMTP/TLS/RC4-MD5; 15 Sep 2011 10:48:08 -0400 Received: from smtp01.ad.xensource.com (10.219.128.104) by smtprelay.citrix.com (10.13.107.65) with Microsoft SMTP Server id 8.3.137.0; Thu, 15 Sep 2011 10:48:08 -0400 Received: from localhost.localdomain (kaball.uk.xensource.com [10.80.2.59]) by smtp01.ad.xensource.com (8.13.1/8.13.1) with ESMTP id p8FElrIq028104; Thu, 15 Sep 2011 07:47:57 -0700 From: To: xen-devel@lists.xensource.com Date: Thu, 15 Sep 2011 15:56:39 +0100 Message-ID: <1316098600-19694-3-git-send-email-stefano.stabellini@eu.citrix.com> X-Mailer: git-send-email 1.7.0.4 In-Reply-To: References: MIME-Version: 1.0 Content-Type: text/plain Cc: Ian.Jackson@eu.citrix.com, Stefano Stabellini , keir@xen.org, Ian.Campbell@citrix.com, Stefano.Stabellini@eu.citrix.com Subject: [Xen-devel] # Parent 0312575dc35e4294eb50e365b2c10078914daca8 X-BeenThere: xen-devel@lists.xensource.com X-Mailman-Version: 2.1.5 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xensource.com Errors-To: xen-devel-bounces@lists.xensource.com Subject: [PATCH v3 2/4] Clone and build upstream Qemu by default Signed-off-by: Stefano Stabellini diff -r b17ff49b17d1 .hgignore --- a/.hgignore Thu Sep 15 11:38:01 2011 +0000 +++ b/.hgignore Thu Sep 15 14:24:05 2011 +0000 @@ -293,6 +293,8 @@ ^tools/xm-test/tests/.*\.test$ ^tools/qemu-xen-traditional-dir-remote ^tools/qemu-xen-traditional-dir$ +^tools/qemu-xen-dir-remote +^tools/qemu-xen-dir$ ^tools/ocaml/.*/.*\.annot$ ^tools/ocaml/.*/.*\.cmx?a$ ^tools/ocaml/.*/META$ diff -r b17ff49b17d1 Config.mk --- a/Config.mk Thu Sep 15 11:38:01 2011 +0000 +++ b/Config.mk Thu Sep 15 14:24:05 2011 +0000 @@ -192,6 +192,14 @@ else QEMU_REMOTE=git://xenbits.xensource.com/qemu-xen-unstable.git endif +# Only available through the git protocol at the moment +ifeq ($(GIT_HTTP),y) +QEMU_UPSTREAM_URL ?= http://xenbits.xensource.com/git-http/qemu-upstream-unstable.git +else +QEMU_UPSTREAM_URL ?= git://xenbits.xensource.com/qemu-upstream-unstable.git +endif +QEMU_UPSTREAM_TAG ?= 6dd84c71dff047f9e492d67e7c99928d09202760 + # Specify which qemu-dm to use. This may be `ioemu' to use the old # Mercurial in-tree version, or a local directory, or a git URL. # CONFIG_QEMU ?= `pwd`/$(XEN_ROOT)/../qemu-xen.git diff -r b17ff49b17d1 Makefile --- a/Makefile Thu Sep 15 11:38:01 2011 +0000 +++ b/Makefile Thu Sep 15 14:24:05 2011 +0000 @@ -70,7 +70,7 @@ install-tools: $(MAKE) -C tools install ifeq ($(CONFIG_IOEMU),y) -install-tools: tools/qemu-xen-traditional-dir +install-tools: tools/qemu-xen-traditional-dir tools/qemu-xen-dir endif .PHONY: install-kernels @@ -91,6 +91,9 @@ tools/qemu-xen-traditional-dir: tools/qemu-xen-traditional-dir-force-update: $(MAKE) -C tools qemu-xen-traditional-dir-force-update +tools/qemu-xen-dir: + $(MAKE) -C tools qemu-xen-dir-find + .PHONY: install-docs install-docs: sh ./docs/check_pkgs && $(MAKE) -C docs install || true diff -r b17ff49b17d1 tools/Makefile --- a/tools/Makefile Thu Sep 15 11:38:01 2011 +0000 +++ b/tools/Makefile Thu Sep 15 14:24:05 2011 +0000 @@ -31,6 +31,7 @@ SUBDIRS-$(LIBXENAPI_BINDINGS) += libxen # do not recurse in to a dir we are about to delete ifneq "$(MAKECMDGOALS)" "distclean" SUBDIRS-$(CONFIG_IOEMU) += qemu-xen-traditional-dir +SUBDIRS-$(CONFIG_IOEMU) += qemu-xen-dir endif SUBDIRS-y += xenpmd @@ -71,6 +72,7 @@ clean: subdirs-clean .PHONY: distclean distclean: subdirs-distclean rm -rf qemu-xen-traditional-dir qemu-xen-traditional-dir-remote + rm -rf qemu-xen-dir qemu-xen-dir-remote ifneq ($(XEN_COMPILE_ARCH),$(XEN_TARGET_ARCH)) IOEMU_CONFIGURE_CROSS ?= --cpu=$(XEN_TARGET_ARCH) \ @@ -95,6 +97,24 @@ qemu-xen-traditional-dir-find: cd qemu-xen-traditional-dir; \ $(QEMU_ROOT)/xen-setup $(IOEMU_CONFIGURE_CROSS) +qemu-xen-dir-find: + if test -d $(QEMU_UPSTREAM_URL) ; then \ + ln -sf $(QEMU_UPSTREAM_URL) qemu-xen-dir; \ + else \ + $(XEN_ROOT)/scripts/git-checkout.sh $(QEMU_UPSTREAM_URL) $(QEMU_UPSTREAM_TAG) qemu-xen-dir ; \ + fi + cd qemu-xen-dir; \ + ./configure --enable-xen --target-list=i386-softmmu \ + --source-path=$$ROOT \ + --extra-cflags="-I$(XEN_ROOT)/tools/include \ + -I$(XEN_ROOT)/tools/libxc \ + -I$(XEN_ROOT)/tools/xenstore" \ + --extra-ldflags="-L$(XEN_ROOT)/tools/libxc \ + -L$(XEN_ROOT)/tools/libxenstore" \ + --bindir=/usr/lib/xen/bin \ + --disable-kvm \ + $(IOEMU_CONFIGURE_CROSS) + .PHONY: qemu-xen-traditional-dir-force-update qemu-xen-traditional-dir-force-update: set -ex; \ @@ -112,6 +132,14 @@ subdir-clean-qemu-xen-traditional-dir: $(MAKE) -C qemu-xen-traditional-dir clean; \ fi +subdir-all-qemu-xen-dir subdir-install-qemu-xen-dir: qemu-xen-dir-find + +subdir-clean-qemu-xen-dir: + set -e; if test -d qemu-xen-dir/.; then \ + $(buildmakevars2shellvars); \ + $(MAKE) -C qemu-xen-dir clean; \ + fi + subdir-clean-debugger/gdbsx subdir-distclean-debugger/gdbsx: .phony $(MAKE) -C debugger/gdbsx clean _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel From xen-devel-bounces@lists.xensource.com Thu Sep 15 07:53:27 2011 Return-path: Envelope-to: www-data@lists.xensource.com Delivery-date: Thu, 15 Sep 2011 07:53:27 -0700 Received: from localhost ([127.0.0.1] helo=lists.colo.xensource.com) by lists.xensource.com with esmtp (Exim 4.43) id 1R4DJf-0002tM-KD; Thu, 15 Sep 2011 07:53:27 -0700 Received: from mail27.messagelabs.com ([193.109.254.147]) by lists.xensource.com with esmtp (Exim 4.43) id 1R4DEc-00013N-32 for xen-devel@lists.xensource.com; Thu, 15 Sep 2011 07:48:14 -0700 X-Env-Sender: Stefano.Stabellini@eu.citrix.com X-Msg-Ref: server-4.tower-27.messagelabs.com!1316098072!40406386!2 X-Originating-IP: [66.165.176.89] X-StarScan-Version: 6.4.1; banners=-,-,- X-VirusChecked: Checked Received: (qmail 10106 invoked from network); 15 Sep 2011 14:47:53 -0000 Received: from smtp.citrix.com (HELO SMTP.CITRIX.COM) (66.165.176.89) by server-4.tower-27.messagelabs.com with RC4-SHA encrypted SMTP; 15 Sep 2011 14:47:53 -0000 X-IronPort-AV: E=Sophos;i="4.68,387,1312171200"; d="scan'208";a="17328685" Received: from ftlpmailmx01.citrite.net ([10.13.107.65]) by FTLPIPO01.CITRIX.COM with ESMTP/TLS/RC4-MD5; 15 Sep 2011 10:48:10 -0400 Received: from smtp01.ad.xensource.com (10.219.128.104) by smtprelay.citrix.com (10.13.107.65) with Microsoft SMTP Server id 8.3.137.0; Thu, 15 Sep 2011 10:48:10 -0400 Received: from localhost.localdomain (kaball.uk.xensource.com [10.80.2.59]) by smtp01.ad.xensource.com (8.13.1/8.13.1) with ESMTP id p8FElrIr028104; Thu, 15 Sep 2011 07:47:58 -0700 From: To: xen-devel@lists.xensource.com Date: Thu, 15 Sep 2011 15:56:40 +0100 Message-ID: <1316098600-19694-4-git-send-email-stefano.stabellini@eu.citrix.com> X-Mailer: git-send-email 1.7.0.4 In-Reply-To: References: MIME-Version: 1.0 Content-Type: text/plain Cc: Ian.Jackson@eu.citrix.com, Stefano Stabellini , keir@xen.org, Ian.Campbell@citrix.com, Stefano.Stabellini@eu.citrix.com Subject: [Xen-devel] # Parent 0312575dc35e4294eb50e365b2c10078914daca8 X-BeenThere: xen-devel@lists.xensource.com X-Mailman-Version: 2.1.5 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xensource.com Errors-To: xen-devel-bounces@lists.xensource.com Subject: [PATCH v3 2/4] Clone and build Seabios by default Signed-off-by: Stefano Stabellini diff -r 9832a4edea7f .hgignore --- a/.hgignore Thu Sep 15 14:25:11 2011 +0000 +++ b/.hgignore Thu Sep 15 14:37:33 2011 +0000 @@ -295,6 +295,8 @@ ^tools/qemu-xen-traditional-dir$ ^tools/qemu-xen-dir-remote ^tools/qemu-xen-dir$ +^tools/tools/firmware/seabios-dir-remote +^tools/tools/firmware/seabios-dir$ ^tools/ocaml/.*/.*\.annot$ ^tools/ocaml/.*/.*\.cmx?a$ ^tools/ocaml/.*/META$ diff -r 9832a4edea7f Config.mk --- a/Config.mk Thu Sep 15 14:25:11 2011 +0000 +++ b/Config.mk Thu Sep 15 14:37:33 2011 +0000 @@ -199,6 +199,8 @@ else QEMU_UPSTREAM_URL ?= git://xenbits.xensource.com/qemu-upstream-unstable.git endif QEMU_UPSTREAM_TAG ?= 6dd84c71dff047f9e492d67e7c99928d09202760 +SEABIOS_UPSTREAM_URL ?= git://git.qemu.org/seabios.git +SEABIOS_UPSTREAM_TAG ?= 7fc039e9c262b4199fab497f3e12f4e425c37560 # Specify which qemu-dm to use. This may be `ioemu' to use the old # Mercurial in-tree version, or a local directory, or a git URL. @@ -212,15 +214,6 @@ QEMU_TAG ?= cd776ee9408ff127f934a707c1a3 # Short answer -- do not enable this unless you know what you are # doing and are prepared for some pain. -# SeaBIOS integration is a work in progress. Before enabling this -# option you must clone git://git.qemu.org/seabios.git/, possibly add -# some development patches and then build it yourself before pointing -# this variable to it (using an absolute path). -# -# Note that using SeaBIOS requires the use the upstream qemu as the -# device model. -SEABIOS_DIR ?= - # Optional components XENSTAT_XENTOP ?= y VTPM_TOOLS ?= n diff -r 9832a4edea7f tools/firmware/Makefile --- a/tools/firmware/Makefile Thu Sep 15 14:25:11 2011 +0000 +++ b/tools/firmware/Makefile Thu Sep 15 14:37:33 2011 +0000 @@ -6,13 +6,18 @@ TARGET := hvmloader/hvmloader INST_DIR := $(DESTDIR)$(XENFIRMWAREDIR) SUBDIRS := +SUBDIRS += seabios-dir SUBDIRS += rombios SUBDIRS += vgabios SUBDIRS += etherboot SUBDIRS += hvmloader +seabios-dir: + $(XEN_ROOT)/scripts/git-checkout.sh $(SEABIOS_UPSTREAM_URL) $(SEABIOS_UPSTREAM_TAG) seabios-dir + cp seabios-config seabios-dir/.config; + .PHONY: all -all: +all: seabios-dir @set -e; if [ $$((`( bcc -v 2>&1 | grep version || echo 0.0.0 ) | cut -d' ' -f 3 | awk -F. '{ printf "0x%02x%02x%02x", $$1, $$2, $$3}'`)) -lt $$((0x00100e)) ] ; then \ echo "==========================================================================="; \ echo "Require dev86 rpm or bin86 & bcc debs version >= 0.16.14 to build firmware!"; \ @@ -35,4 +40,7 @@ clean: subdirs-clean distclean: subdirs-distclean subdir-distclean-etherboot: .phony - $(MAKE) -C etherboot distclean \ No newline at end of file + $(MAKE) -C etherboot distclean + +subdir-distclean-seabios-dir: .phony + rm -rf seabios-dir seabios-dir-remote diff -r 9832a4edea7f tools/firmware/hvmloader/Makefile --- a/tools/firmware/hvmloader/Makefile Thu Sep 15 14:25:11 2011 +0000 +++ b/tools/firmware/hvmloader/Makefile Thu Sep 15 14:37:33 2011 +0000 @@ -44,6 +44,7 @@ CFLAGS += -DENABLE_ROMBIOS ROMBIOS_ROM := $(ROMBIOS_DIR)/BIOS-bochs-latest endif +SEABIOS_DIR := ../seabios-dir ifneq ($(SEABIOS_DIR),) OBJS += seabios.o CFLAGS += -DENABLE_SEABIOS diff -r 9832a4edea7f tools/firmware/seabios-config --- /dev/null Thu Jan 01 00:00:00 1970 +0000 +++ b/tools/firmware/seabios-config Thu Sep 15 14:37:33 2011 +0000 @@ -0,0 +1,73 @@ +# +# Automatically generated make config: don't edit +# SeaBIOS Configuration +# Wed Sep 7 13:03:21 2011 +# + +# +# General Features +# +# CONFIG_COREBOOT is not set +CONFIG_XEN=y +CONFIG_THREADS=y +# CONFIG_THREAD_OPTIONROMS is not set +CONFIG_RELOCATE_INIT=y +CONFIG_BOOTMENU=y +# CONFIG_BOOTSPLASH is not set +CONFIG_BOOTORDER=y + +# +# Hardware support +# +CONFIG_ATA=y +CONFIG_ATA_DMA=y +CONFIG_ATA_PIO32=y +CONFIG_AHCI=y +CONFIG_VIRTIO_BLK=y +CONFIG_FLOPPY=y +CONFIG_PS2PORT=y +CONFIG_USB=y +CONFIG_USB_UHCI=y +CONFIG_USB_OHCI=y +CONFIG_USB_EHCI=y +CONFIG_USB_MSC=y +CONFIG_USB_HUB=y +CONFIG_USB_KEYBOARD=y +CONFIG_USB_MOUSE=y +CONFIG_SERIAL=y +CONFIG_LPT=y +# CONFIG_USE_SMM is not set +CONFIG_MTRR_INIT=y + +# +# BIOS interfaces +# +CONFIG_DRIVES=y +CONFIG_CDROM_BOOT=y +CONFIG_CDROM_EMU=y +CONFIG_PCIBIOS=y +CONFIG_APMBIOS=y +CONFIG_PNPBIOS=y +CONFIG_OPTIONROMS=y +# CONFIG_OPTIONROMS_DEPLOYED is not set +CONFIG_PMM=y +CONFIG_BOOT=y +CONFIG_KEYBOARD=y +CONFIG_KBD_CALL_INT15_4F=y +CONFIG_MOUSE=y +CONFIG_S3_RESUME=y +# CONFIG_DISABLE_A20 is not set + +# +# BIOS Tables +# +CONFIG_PIRTABLE=y +CONFIG_MPTABLE=y +CONFIG_SMBIOS=y +CONFIG_ACPI=y + +# +# Debugging +# +CONFIG_DEBUG_LEVEL=1 +# CONFIG_DEBUG_SERIAL is not set _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel From xen-devel-bounces@lists.xensource.com Thu Sep 15 07:54:24 2011 Return-path: Envelope-to: www-data@lists.xensource.com Delivery-date: Thu, 15 Sep 2011 07:54:24 -0700 Received: from localhost ([127.0.0.1] helo=lists.colo.xensource.com) by lists.xensource.com with esmtp (Exim 4.43) id 1R4DKa-0003GS-7n; Thu, 15 Sep 2011 07:54:24 -0700 Received: from mail27.messagelabs.com ([193.109.254.147]) by lists.xensource.com with esmtp (Exim 4.43) id 1R4DIN-0002Iz-LE for xen-devel@lists.xensource.com; Thu, 15 Sep 2011 07:52:08 -0700 X-Env-Sender: Stefano.Stabellini@eu.citrix.com X-Msg-Ref: server-10.tower-27.messagelabs.com!1316098304!35888648!1 X-Originating-IP: [66.165.176.63] X-StarScan-Version: 6.4.1; banners=-,-,- X-VirusChecked: Checked Received: (qmail 20705 invoked from network); 15 Sep 2011 14:51:45 -0000 Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63) by server-10.tower-27.messagelabs.com with RC4-SHA encrypted SMTP; 15 Sep 2011 14:51:45 -0000 X-IronPort-AV: E=Sophos;i="4.68,387,1312171200"; d="scan'208";a="163398093" Received: from ftlpmailmx02.citrite.net ([10.13.107.66]) by FTLPIPO02.CITRIX.COM with ESMTP/TLS/RC4-MD5; 15 Sep 2011 10:52:03 -0400 Received: from smtp01.ad.xensource.com (10.219.128.104) by smtprelay.citrix.com (10.13.107.66) with Microsoft SMTP Server id 8.3.137.0; Thu, 15 Sep 2011 10:52:02 -0400 Received: from localhost.localdomain (kaball.uk.xensource.com [10.80.2.59]) by smtp01.ad.xensource.com (8.13.1/8.13.1) with ESMTP id p8FEptXV028113; Thu, 15 Sep 2011 07:51:56 -0700 From: To: xen-devel@lists.xensource.com Date: Thu, 15 Sep 2011 16:00:40 +0100 Message-ID: <1316098843-19974-1-git-send-email-stefano.stabellini@eu.citrix.com> X-Mailer: git-send-email 1.7.0.4 In-Reply-To: References: MIME-Version: 1.0 Content-Type: text/plain Cc: Ian.Jackson@eu.citrix.com, Stefano Stabellini , keir@xen.org, Ian.Campbell@citrix.com, Stefano.Stabellini@eu.citrix.com Subject: [Xen-devel] [PATCH v4 1/4] Introduce git-checkout.sh X-BeenThere: xen-devel@lists.xensource.com X-Mailman-Version: 2.1.5 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xensource.com Errors-To: xen-devel-bounces@lists.xensource.com Introduce a script to perform git checkout on an external git tree; use git-checkout.sh in ioemu-dir-find. Signed-off-by: Stefano Stabellini diff --git a/.hgignore b/.hgignore --- a/.hgignore +++ b/.hgignore @@ -291,7 +291,7 @@ ^tools/xm-test/lib/XmTestLib/config.py$ ^tools/xm-test/lib/XmTestReport/xmtest.py$ ^tools/xm-test/tests/.*\.test$ -^tools/ioemu-remote +^tools/ioemu-dir-remote ^tools/ioemu-dir$ ^tools/ocaml/.*/.*\.annot$ ^tools/ocaml/.*/.*\.cmx?a$ diff --git a/scripts/git-checkout.sh b/scripts/git-checkout.sh new file mode 100755 --- /dev/null +++ b/scripts/git-checkout.sh @@ -0,0 +1,21 @@ +#!/bin/bash + +TREE=$1 +TAG=$2 +DIR=$3 + + +if test \! -d $DIR-remote; then + rm -rf $DIR-remote $DIR-remote.tmp; + mkdir $DIR-remote.tmp; rmdir $DIR-remote.tmp; + git clone $TREE $DIR-remote.tmp; + if test "$TAG" ; then + cd $DIR-remote.tmp + git branch -D dummy >/dev/null 2>&1 ||: + git checkout -b dummy $TAG + cd .. + fi + mv $DIR-remote.tmp $DIR-remote +fi +rm -f $DIR +ln -sf $DIR-remote $DIR diff --git a/tools/Makefile b/tools/Makefile --- a/tools/Makefile +++ b/tools/Makefile @@ -70,7 +70,7 @@ clean: subdirs-clean .PHONY: distclean distclean: subdirs-distclean - rm -rf ioemu-dir ioemu-remote + rm -rf ioemu-dir ioemu-dir-remote ifneq ($(XEN_COMPILE_ARCH),$(XEN_TARGET_ARCH)) IOEMU_CONFIGURE_CROSS ?= --cpu=$(XEN_TARGET_ARCH) \ @@ -88,20 +88,7 @@ ioemu-dir-find: if test -d $(CONFIG_QEMU); then \ mkdir -p ioemu-dir; \ else \ - if [ ! -d ioemu-remote ]; then \ - rm -rf ioemu-remote ioemu-remote.tmp; \ - mkdir ioemu-remote.tmp; rmdir ioemu-remote.tmp; \ - $(GIT) clone $(CONFIG_QEMU) ioemu-remote.tmp; \ - if [ "$(QEMU_TAG)" ]; then \ - cd ioemu-remote.tmp; \ - $(GIT) branch -D dummy >/dev/null 2>&1 ||:; \ - $(GIT) checkout -b dummy $(QEMU_TAG); \ - cd ..; \ - fi; \ - mv ioemu-remote.tmp ioemu-remote; \ - fi; \ - rm -f ioemu-dir; \ - ln -sf ioemu-remote ioemu-dir; \ + $(XEN_ROOT)/scripts/git-checkout.sh $(CONFIG_QEMU) $(QEMU_TAG) ioemu-dir; \ fi set -e; \ $(buildmakevars2shellvars); \ @@ -112,7 +99,7 @@ ioemu-dir-find: ioemu-dir-force-update: set -ex; \ if [ "$(QEMU_TAG)" ]; then \ - cd ioemu-remote; \ + cd ioemu-dir-remote; \ $(GIT) fetch origin; \ $(GIT) reset --hard $(QEMU_TAG); \ fi _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel From xen-devel-bounces@lists.xensource.com Thu Sep 15 07:55:16 2011 Return-path: Envelope-to: www-data@lists.xensource.com Delivery-date: Thu, 15 Sep 2011 07:55:16 -0700 Received: from localhost ([127.0.0.1] helo=lists.colo.xensource.com) by lists.xensource.com with esmtp (Exim 4.43) id 1R4DLQ-0003dI-AE; Thu, 15 Sep 2011 07:55:16 -0700 Received: from mail27.messagelabs.com ([193.109.254.147]) by lists.xensource.com with esmtp (Exim 4.43) id 1R4DIS-0002LF-UG for xen-devel@lists.xensource.com; Thu, 15 Sep 2011 07:52:13 -0700 X-Env-Sender: Stefano.Stabellini@eu.citrix.com X-Msg-Ref: server-10.tower-27.messagelabs.com!1316098304!35888648!2 X-Originating-IP: [66.165.176.63] X-StarScan-Version: 6.4.1; banners=-,-,- X-VirusChecked: Checked Received: (qmail 20898 invoked from network); 15 Sep 2011 14:51:50 -0000 Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63) by server-10.tower-27.messagelabs.com with RC4-SHA encrypted SMTP; 15 Sep 2011 14:51:50 -0000 X-IronPort-AV: E=Sophos;i="4.68,387,1312171200"; d="scan'208";a="163398113" Received: from ftlpmailmx02.citrite.net ([10.13.107.66]) by FTLPIPO02.CITRIX.COM with ESMTP/TLS/RC4-MD5; 15 Sep 2011 10:52:09 -0400 Received: from smtp01.ad.xensource.com (10.219.128.104) by smtprelay.citrix.com (10.13.107.66) with Microsoft SMTP Server id 8.3.137.0; Thu, 15 Sep 2011 10:52:09 -0400 Received: from localhost.localdomain (kaball.uk.xensource.com [10.80.2.59]) by smtp01.ad.xensource.com (8.13.1/8.13.1) with ESMTP id p8FEptXW028113; Thu, 15 Sep 2011 07:51:57 -0700 From: To: xen-devel@lists.xensource.com Date: Thu, 15 Sep 2011 16:00:41 +0100 Message-ID: <1316098843-19974-2-git-send-email-stefano.stabellini@eu.citrix.com> X-Mailer: git-send-email 1.7.0.4 In-Reply-To: References: MIME-Version: 1.0 Content-Type: text/plain Cc: Ian.Jackson@eu.citrix.com, Stefano Stabellini , keir@xen.org, Ian.Campbell@citrix.com, Stefano.Stabellini@eu.citrix.com Subject: [Xen-devel] [PATCH v4 2/4] Rename ioemu-dir as qemu-xen-traditional-dir X-BeenThere: xen-devel@lists.xensource.com X-Mailman-Version: 2.1.5 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xensource.com Errors-To: xen-devel-bounces@lists.xensource.com Signed-off-by: Stefano Stabellini diff -r 1993c6e145b5 .hgignore --- a/.hgignore Thu Sep 15 09:38:49 2011 +0000 +++ b/.hgignore Thu Sep 15 11:08:51 2011 +0000 @@ -291,8 +291,8 @@ ^tools/xm-test/lib/XmTestLib/config.py$ ^tools/xm-test/lib/XmTestReport/xmtest.py$ ^tools/xm-test/tests/.*\.test$ -^tools/ioemu-dir-remote -^tools/ioemu-dir$ +^tools/qemu-xen-traditional-dir-remote +^tools/qemu-xen-traditional-dir$ ^tools/ocaml/.*/.*\.annot$ ^tools/ocaml/.*/.*\.cmx?a$ ^tools/ocaml/.*/META$ diff -r 1993c6e145b5 Makefile --- a/Makefile Thu Sep 15 09:38:49 2011 +0000 +++ b/Makefile Thu Sep 15 11:08:51 2011 +0000 @@ -70,7 +70,7 @@ install-tools: $(MAKE) -C tools install ifeq ($(CONFIG_IOEMU),y) -install-tools: tools/ioemu-dir +install-tools: tools/qemu-xen-traditional-dir endif .PHONY: install-kernels @@ -78,18 +78,18 @@ install-kernels: for i in $(XKERNELS) ; do $(MAKE) $$i-install || exit 1; done .PHONY: install-stubdom -install-stubdom: tools/ioemu-dir install-tools +install-stubdom: tools/qemu-xen-traditional-dir install-tools $(MAKE) -C stubdom install ifeq (x86_64,$(XEN_TARGET_ARCH)) XEN_TARGET_ARCH=x86_32 $(MAKE) -C stubdom install-grub endif -tools/ioemu-dir: - $(MAKE) -C tools ioemu-dir-find +tools/qemu-xen-traditional-dir: + $(MAKE) -C tools qemu-xen-traditional-dir-find -.PHONY: tools/ioemu-dir-force-update -tools/ioemu-dir-force-update: - $(MAKE) -C tools ioemu-dir-force-update +.PHONY: tools/qemu-xen-traditional-dir-force-update +tools/qemu-xen-traditional-dir-force-update: + $(MAKE) -C tools qemu-xen-traditional-dir-force-update .PHONY: install-docs install-docs: diff -r 1993c6e145b5 stubdom/Makefile --- a/stubdom/Makefile Thu Sep 15 09:38:49 2011 +0000 +++ b/stubdom/Makefile Thu Sep 15 11:08:51 2011 +0000 @@ -218,15 +218,15 @@ cross-ocaml: $(OCAML_STAMPFILE) QEMU_ROOT := $(shell if [ -d "$(CONFIG_QEMU)" ]; then echo "$(CONFIG_QEMU)"; else echo .; fi) ifeq ($(QEMU_ROOT),.) -$(XEN_ROOT)/tools/ioemu-dir: - $(CROSS_MAKE) -C $(XEN_ROOT)/tools ioemu-dir-find +$(XEN_ROOT)/tools/qemu-xen-traditional-dir: + $(CROSS_MAKE) -C $(XEN_ROOT)/tools qemu-xen-traditional-dir-find -ioemu/linkfarm.stamp: $(XEN_ROOT)/tools/ioemu-dir +ioemu/linkfarm.stamp: $(XEN_ROOT)/tools/qemu-xen-traditional-dir mkdir -p ioemu set -e; \ $(buildmakevars2shellvars); \ cd ioemu; \ - src="$$XEN_ROOT/tools/ioemu-dir"; export src; \ + src="$$XEN_ROOT/tools/qemu-xen-traditional-dir"; export src; \ (cd $$src && find * -type d -print) | xargs mkdir -p; \ (cd $$src && find * ! -type l -type f $(addprefix ! -name , \ '*.[oda1]' 'config-*' config.mak qemu-dm qemu-img-xen \ diff -r 1993c6e145b5 tools/Makefile --- a/tools/Makefile Thu Sep 15 09:38:49 2011 +0000 +++ b/tools/Makefile Thu Sep 15 11:08:51 2011 +0000 @@ -30,7 +30,7 @@ SUBDIRS-$(LIBXENAPI_BINDINGS) += libxen # do not recurse in to a dir we are about to delete ifneq "$(MAKECMDGOALS)" "distclean" -SUBDIRS-$(CONFIG_IOEMU) += ioemu-dir +SUBDIRS-$(CONFIG_IOEMU) += qemu-xen-traditional-dir endif SUBDIRS-y += xenpmd @@ -70,7 +70,7 @@ clean: subdirs-clean .PHONY: distclean distclean: subdirs-distclean - rm -rf ioemu-dir ioemu-dir-remote + rm -rf qemu-xen-traditional-dir qemu-xen-traditional-dir-remote ifneq ($(XEN_COMPILE_ARCH),$(XEN_TARGET_ARCH)) IOEMU_CONFIGURE_CROSS ?= --cpu=$(XEN_TARGET_ARCH) \ @@ -83,33 +83,33 @@ ifneq ($(QEMU_ROOT),.) export QEMU_ROOT endif -ioemu-dir-find: +qemu-xen-traditional-dir-find: set -ex; \ if test -d $(CONFIG_QEMU); then \ - mkdir -p ioemu-dir; \ + mkdir -p qemu-xen-traditional-dir; \ else \ - $(XEN_ROOT)/scripts/git-checkout.sh $(CONFIG_QEMU) $(QEMU_TAG) ioemu-dir; \ + $(XEN_ROOT)/scripts/git-checkout.sh $(CONFIG_QEMU) $(QEMU_TAG) qemu-xen-traditional-dir; \ fi set -e; \ $(buildmakevars2shellvars); \ - cd ioemu-dir; \ + cd qemu-xen-traditional-dir; \ $(QEMU_ROOT)/xen-setup $(IOEMU_CONFIGURE_CROSS) -.PHONY: ioemu-dir-force-update -ioemu-dir-force-update: +.PHONY: qemu-xen-traditional-dir-force-update +qemu-xen-traditional-dir-force-update: set -ex; \ if [ "$(QEMU_TAG)" ]; then \ - cd ioemu-dir-remote; \ + cd qemu-xen-traditional-dir-remote; \ $(GIT) fetch origin; \ $(GIT) reset --hard $(QEMU_TAG); \ fi -subdir-all-ioemu-dir subdir-install-ioemu-dir: ioemu-dir-find +subdir-all-qemu-xen-traditional-dir subdir-install-qemu-xen-traditional-dir: qemu-xen-traditional-dir-find -subdir-clean-ioemu-dir: - set -e; if test -d ioemu-dir/.; then \ +subdir-clean-qemu-xen-traditional-dir: + set -e; if test -d qemu-xen-traditional-dir/.; then \ $(buildmakevars2shellvars); \ - $(MAKE) -C ioemu-dir clean; \ + $(MAKE) -C qemu-xen-traditional-dir clean; \ fi subdir-clean-debugger/gdbsx subdir-distclean-debugger/gdbsx: .phony _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel From xen-devel-bounces@lists.xensource.com Thu Sep 15 07:56:31 2011 Return-path: Envelope-to: www-data@lists.xensource.com Delivery-date: Thu, 15 Sep 2011 07:56:31 -0700 Received: from localhost ([127.0.0.1] helo=lists.colo.xensource.com) by lists.xensource.com with esmtp (Exim 4.43) id 1R4DMd-00045a-9u; Thu, 15 Sep 2011 07:56:31 -0700 Received: from mail21.messagelabs.com ([85.158.143.35]) by lists.xensource.com with esmtp (Exim 4.43) id 1R4DIV-0002MB-ER for xen-devel@lists.xensource.com; Thu, 15 Sep 2011 07:52:15 -0700 X-Env-Sender: Stefano.Stabellini@eu.citrix.com X-Msg-Ref: server-10.tower-21.messagelabs.com!1316098316!54248461!1 X-Originating-IP: [66.165.176.89] X-StarScan-Version: 6.4.1; banners=-,-,- X-VirusChecked: Checked Received: (qmail 7264 invoked from network); 15 Sep 2011 14:51:57 -0000 Received: from smtp.citrix.com (HELO SMTP.CITRIX.COM) (66.165.176.89) by server-10.tower-21.messagelabs.com with RC4-SHA encrypted SMTP; 15 Sep 2011 14:51:57 -0000 X-IronPort-AV: E=Sophos;i="4.68,387,1312171200"; d="scan'208";a="17328964" Received: from ftlpmailmx02.citrite.net ([10.13.107.66]) by FTLPIPO01.CITRIX.COM with ESMTP/TLS/RC4-MD5; 15 Sep 2011 10:52:10 -0400 Received: from smtp01.ad.xensource.com (10.219.128.104) by smtprelay.citrix.com (10.13.107.66) with Microsoft SMTP Server id 8.3.137.0; Thu, 15 Sep 2011 10:52:10 -0400 Received: from localhost.localdomain (kaball.uk.xensource.com [10.80.2.59]) by smtp01.ad.xensource.com (8.13.1/8.13.1) with ESMTP id p8FEptXX028113; Thu, 15 Sep 2011 07:51:59 -0700 From: To: xen-devel@lists.xensource.com Date: Thu, 15 Sep 2011 16:00:42 +0100 Message-ID: <1316098843-19974-3-git-send-email-stefano.stabellini@eu.citrix.com> X-Mailer: git-send-email 1.7.0.4 In-Reply-To: References: MIME-Version: 1.0 Content-Type: text/plain Cc: Ian.Jackson@eu.citrix.com, Stefano Stabellini , keir@xen.org, Ian.Campbell@citrix.com, Stefano.Stabellini@eu.citrix.com Subject: [Xen-devel] [PATCH v4 3/4] Clone and build upstream Qemu by default X-BeenThere: xen-devel@lists.xensource.com X-Mailman-Version: 2.1.5 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xensource.com Errors-To: xen-devel-bounces@lists.xensource.com Signed-off-by: Stefano Stabellini diff -r b17ff49b17d1 .hgignore --- a/.hgignore Thu Sep 15 11:38:01 2011 +0000 +++ b/.hgignore Thu Sep 15 14:24:05 2011 +0000 @@ -293,6 +293,8 @@ ^tools/xm-test/tests/.*\.test$ ^tools/qemu-xen-traditional-dir-remote ^tools/qemu-xen-traditional-dir$ +^tools/qemu-xen-dir-remote +^tools/qemu-xen-dir$ ^tools/ocaml/.*/.*\.annot$ ^tools/ocaml/.*/.*\.cmx?a$ ^tools/ocaml/.*/META$ diff -r b17ff49b17d1 Config.mk --- a/Config.mk Thu Sep 15 11:38:01 2011 +0000 +++ b/Config.mk Thu Sep 15 14:24:05 2011 +0000 @@ -192,6 +192,14 @@ else QEMU_REMOTE=git://xenbits.xensource.com/qemu-xen-unstable.git endif +# Only available through the git protocol at the moment +ifeq ($(GIT_HTTP),y) +QEMU_UPSTREAM_URL ?= http://xenbits.xensource.com/git-http/qemu-upstream-unstable.git +else +QEMU_UPSTREAM_URL ?= git://xenbits.xensource.com/qemu-upstream-unstable.git +endif +QEMU_UPSTREAM_TAG ?= 6dd84c71dff047f9e492d67e7c99928d09202760 + # Specify which qemu-dm to use. This may be `ioemu' to use the old # Mercurial in-tree version, or a local directory, or a git URL. # CONFIG_QEMU ?= `pwd`/$(XEN_ROOT)/../qemu-xen.git diff -r b17ff49b17d1 Makefile --- a/Makefile Thu Sep 15 11:38:01 2011 +0000 +++ b/Makefile Thu Sep 15 14:24:05 2011 +0000 @@ -70,7 +70,7 @@ install-tools: $(MAKE) -C tools install ifeq ($(CONFIG_IOEMU),y) -install-tools: tools/qemu-xen-traditional-dir +install-tools: tools/qemu-xen-traditional-dir tools/qemu-xen-dir endif .PHONY: install-kernels @@ -91,6 +91,9 @@ tools/qemu-xen-traditional-dir: tools/qemu-xen-traditional-dir-force-update: $(MAKE) -C tools qemu-xen-traditional-dir-force-update +tools/qemu-xen-dir: + $(MAKE) -C tools qemu-xen-dir-find + .PHONY: install-docs install-docs: sh ./docs/check_pkgs && $(MAKE) -C docs install || true diff -r b17ff49b17d1 tools/Makefile --- a/tools/Makefile Thu Sep 15 11:38:01 2011 +0000 +++ b/tools/Makefile Thu Sep 15 14:24:05 2011 +0000 @@ -31,6 +31,7 @@ SUBDIRS-$(LIBXENAPI_BINDINGS) += libxen # do not recurse in to a dir we are about to delete ifneq "$(MAKECMDGOALS)" "distclean" SUBDIRS-$(CONFIG_IOEMU) += qemu-xen-traditional-dir +SUBDIRS-$(CONFIG_IOEMU) += qemu-xen-dir endif SUBDIRS-y += xenpmd @@ -71,6 +72,7 @@ clean: subdirs-clean .PHONY: distclean distclean: subdirs-distclean rm -rf qemu-xen-traditional-dir qemu-xen-traditional-dir-remote + rm -rf qemu-xen-dir qemu-xen-dir-remote ifneq ($(XEN_COMPILE_ARCH),$(XEN_TARGET_ARCH)) IOEMU_CONFIGURE_CROSS ?= --cpu=$(XEN_TARGET_ARCH) \ @@ -95,6 +97,24 @@ qemu-xen-traditional-dir-find: cd qemu-xen-traditional-dir; \ $(QEMU_ROOT)/xen-setup $(IOEMU_CONFIGURE_CROSS) +qemu-xen-dir-find: + if test -d $(QEMU_UPSTREAM_URL) ; then \ + ln -sf $(QEMU_UPSTREAM_URL) qemu-xen-dir; \ + else \ + $(XEN_ROOT)/scripts/git-checkout.sh $(QEMU_UPSTREAM_URL) $(QEMU_UPSTREAM_TAG) qemu-xen-dir ; \ + fi + cd qemu-xen-dir; \ + ./configure --enable-xen --target-list=i386-softmmu \ + --source-path=$$ROOT \ + --extra-cflags="-I$(XEN_ROOT)/tools/include \ + -I$(XEN_ROOT)/tools/libxc \ + -I$(XEN_ROOT)/tools/xenstore" \ + --extra-ldflags="-L$(XEN_ROOT)/tools/libxc \ + -L$(XEN_ROOT)/tools/libxenstore" \ + --bindir=/usr/lib/xen/bin \ + --disable-kvm \ + $(IOEMU_CONFIGURE_CROSS) + .PHONY: qemu-xen-traditional-dir-force-update qemu-xen-traditional-dir-force-update: set -ex; \ @@ -112,6 +132,14 @@ subdir-clean-qemu-xen-traditional-dir: $(MAKE) -C qemu-xen-traditional-dir clean; \ fi +subdir-all-qemu-xen-dir subdir-install-qemu-xen-dir: qemu-xen-dir-find + +subdir-clean-qemu-xen-dir: + set -e; if test -d qemu-xen-dir/.; then \ + $(buildmakevars2shellvars); \ + $(MAKE) -C qemu-xen-dir clean; \ + fi + subdir-clean-debugger/gdbsx subdir-distclean-debugger/gdbsx: .phony $(MAKE) -C debugger/gdbsx clean _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel From xen-devel-bounces@lists.xensource.com Thu Sep 15 07:57:58 2011 Return-path: Envelope-to: www-data@lists.xensource.com Delivery-date: Thu, 15 Sep 2011 07:57:58 -0700 Received: from localhost ([127.0.0.1] helo=lists.colo.xensource.com) by lists.xensource.com with esmtp (Exim 4.43) id 1R4DO2-0004UV-1V; Thu, 15 Sep 2011 07:57:58 -0700 Received: from mail27.messagelabs.com ([193.109.254.147]) by lists.xensource.com with esmtp (Exim 4.43) id 1R4DIW-0002MR-CI for xen-devel@lists.xensource.com; Thu, 15 Sep 2011 07:52:16 -0700 X-Env-Sender: Stefano.Stabellini@eu.citrix.com X-Msg-Ref: server-10.tower-27.messagelabs.com!1316098304!35888648!3 X-Originating-IP: [66.165.176.63] X-StarScan-Version: 6.4.1; banners=-,-,- X-VirusChecked: Checked Received: (qmail 21019 invoked from network); 15 Sep 2011 14:51:53 -0000 Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63) by server-10.tower-27.messagelabs.com with RC4-SHA encrypted SMTP; 15 Sep 2011 14:51:53 -0000 X-IronPort-AV: E=Sophos;i="4.68,387,1312171200"; d="scan'208";a="163398132" Received: from ftlpmailmx02.citrite.net ([10.13.107.66]) by FTLPIPO02.CITRIX.COM with ESMTP/TLS/RC4-MD5; 15 Sep 2011 10:52:12 -0400 Received: from smtp01.ad.xensource.com (10.219.128.104) by smtprelay.citrix.com (10.13.107.66) with Microsoft SMTP Server id 8.3.137.0; Thu, 15 Sep 2011 10:52:12 -0400 Received: from localhost.localdomain (kaball.uk.xensource.com [10.80.2.59]) by smtp01.ad.xensource.com (8.13.1/8.13.1) with ESMTP id p8FEptXY028113; Thu, 15 Sep 2011 07:52:00 -0700 From: To: xen-devel@lists.xensource.com Date: Thu, 15 Sep 2011 16:00:43 +0100 Message-ID: <1316098843-19974-4-git-send-email-stefano.stabellini@eu.citrix.com> X-Mailer: git-send-email 1.7.0.4 In-Reply-To: References: MIME-Version: 1.0 Content-Type: text/plain Cc: Ian.Jackson@eu.citrix.com, Stefano Stabellini , keir@xen.org, Ian.Campbell@citrix.com, Stefano.Stabellini@eu.citrix.com Subject: [Xen-devel] [PATCH v4 4/4] Clone and build Seabios by default X-BeenThere: xen-devel@lists.xensource.com X-Mailman-Version: 2.1.5 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xensource.com Errors-To: xen-devel-bounces@lists.xensource.com Signed-off-by: Stefano Stabellini diff -r 9832a4edea7f .hgignore --- a/.hgignore Thu Sep 15 14:25:11 2011 +0000 +++ b/.hgignore Thu Sep 15 14:37:33 2011 +0000 @@ -295,6 +295,8 @@ ^tools/qemu-xen-traditional-dir$ ^tools/qemu-xen-dir-remote ^tools/qemu-xen-dir$ +^tools/tools/firmware/seabios-dir-remote +^tools/tools/firmware/seabios-dir$ ^tools/ocaml/.*/.*\.annot$ ^tools/ocaml/.*/.*\.cmx?a$ ^tools/ocaml/.*/META$ diff -r 9832a4edea7f Config.mk --- a/Config.mk Thu Sep 15 14:25:11 2011 +0000 +++ b/Config.mk Thu Sep 15 14:37:33 2011 +0000 @@ -199,6 +199,8 @@ else QEMU_UPSTREAM_URL ?= git://xenbits.xensource.com/qemu-upstream-unstable.git endif QEMU_UPSTREAM_TAG ?= 6dd84c71dff047f9e492d67e7c99928d09202760 +SEABIOS_UPSTREAM_URL ?= git://git.qemu.org/seabios.git +SEABIOS_UPSTREAM_TAG ?= 7fc039e9c262b4199fab497f3e12f4e425c37560 # Specify which qemu-dm to use. This may be `ioemu' to use the old # Mercurial in-tree version, or a local directory, or a git URL. @@ -212,15 +214,6 @@ QEMU_TAG ?= cd776ee9408ff127f934a707c1a3 # Short answer -- do not enable this unless you know what you are # doing and are prepared for some pain. -# SeaBIOS integration is a work in progress. Before enabling this -# option you must clone git://git.qemu.org/seabios.git/, possibly add -# some development patches and then build it yourself before pointing -# this variable to it (using an absolute path). -# -# Note that using SeaBIOS requires the use the upstream qemu as the -# device model. -SEABIOS_DIR ?= - # Optional components XENSTAT_XENTOP ?= y VTPM_TOOLS ?= n diff -r 9832a4edea7f tools/firmware/Makefile --- a/tools/firmware/Makefile Thu Sep 15 14:25:11 2011 +0000 +++ b/tools/firmware/Makefile Thu Sep 15 14:37:33 2011 +0000 @@ -6,13 +6,18 @@ TARGET := hvmloader/hvmloader INST_DIR := $(DESTDIR)$(XENFIRMWAREDIR) SUBDIRS := +SUBDIRS += seabios-dir SUBDIRS += rombios SUBDIRS += vgabios SUBDIRS += etherboot SUBDIRS += hvmloader +seabios-dir: + $(XEN_ROOT)/scripts/git-checkout.sh $(SEABIOS_UPSTREAM_URL) $(SEABIOS_UPSTREAM_TAG) seabios-dir + cp seabios-config seabios-dir/.config; + .PHONY: all -all: +all: seabios-dir @set -e; if [ $$((`( bcc -v 2>&1 | grep version || echo 0.0.0 ) | cut -d' ' -f 3 | awk -F. '{ printf "0x%02x%02x%02x", $$1, $$2, $$3}'`)) -lt $$((0x00100e)) ] ; then \ echo "==========================================================================="; \ echo "Require dev86 rpm or bin86 & bcc debs version >= 0.16.14 to build firmware!"; \ @@ -35,4 +40,7 @@ clean: subdirs-clean distclean: subdirs-distclean subdir-distclean-etherboot: .phony - $(MAKE) -C etherboot distclean \ No newline at end of file + $(MAKE) -C etherboot distclean + +subdir-distclean-seabios-dir: .phony + rm -rf seabios-dir seabios-dir-remote diff -r 9832a4edea7f tools/firmware/hvmloader/Makefile --- a/tools/firmware/hvmloader/Makefile Thu Sep 15 14:25:11 2011 +0000 +++ b/tools/firmware/hvmloader/Makefile Thu Sep 15 14:37:33 2011 +0000 @@ -44,6 +44,7 @@ CFLAGS += -DENABLE_ROMBIOS ROMBIOS_ROM := $(ROMBIOS_DIR)/BIOS-bochs-latest endif +SEABIOS_DIR := ../seabios-dir ifneq ($(SEABIOS_DIR),) OBJS += seabios.o CFLAGS += -DENABLE_SEABIOS diff -r 9832a4edea7f tools/firmware/seabios-config --- /dev/null Thu Jan 01 00:00:00 1970 +0000 +++ b/tools/firmware/seabios-config Thu Sep 15 14:37:33 2011 +0000 @@ -0,0 +1,73 @@ +# +# Automatically generated make config: don't edit +# SeaBIOS Configuration +# Wed Sep 7 13:03:21 2011 +# + +# +# General Features +# +# CONFIG_COREBOOT is not set +CONFIG_XEN=y +CONFIG_THREADS=y +# CONFIG_THREAD_OPTIONROMS is not set +CONFIG_RELOCATE_INIT=y +CONFIG_BOOTMENU=y +# CONFIG_BOOTSPLASH is not set +CONFIG_BOOTORDER=y + +# +# Hardware support +# +CONFIG_ATA=y +CONFIG_ATA_DMA=y +CONFIG_ATA_PIO32=y +CONFIG_AHCI=y +CONFIG_VIRTIO_BLK=y +CONFIG_FLOPPY=y +CONFIG_PS2PORT=y +CONFIG_USB=y +CONFIG_USB_UHCI=y +CONFIG_USB_OHCI=y +CONFIG_USB_EHCI=y +CONFIG_USB_MSC=y +CONFIG_USB_HUB=y +CONFIG_USB_KEYBOARD=y +CONFIG_USB_MOUSE=y +CONFIG_SERIAL=y +CONFIG_LPT=y +# CONFIG_USE_SMM is not set +CONFIG_MTRR_INIT=y + +# +# BIOS interfaces +# +CONFIG_DRIVES=y +CONFIG_CDROM_BOOT=y +CONFIG_CDROM_EMU=y +CONFIG_PCIBIOS=y +CONFIG_APMBIOS=y +CONFIG_PNPBIOS=y +CONFIG_OPTIONROMS=y +# CONFIG_OPTIONROMS_DEPLOYED is not set +CONFIG_PMM=y +CONFIG_BOOT=y +CONFIG_KEYBOARD=y +CONFIG_KBD_CALL_INT15_4F=y +CONFIG_MOUSE=y +CONFIG_S3_RESUME=y +# CONFIG_DISABLE_A20 is not set + +# +# BIOS Tables +# +CONFIG_PIRTABLE=y +CONFIG_MPTABLE=y +CONFIG_SMBIOS=y +CONFIG_ACPI=y + +# +# Debugging +# +CONFIG_DEBUG_LEVEL=1 +# CONFIG_DEBUG_SERIAL is not set _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel From xen-devel-bounces@lists.xensource.com Thu Sep 15 08:02:09 2011 Return-path: Envelope-to: www-data@lists.xensource.com Delivery-date: Thu, 15 Sep 2011 08:02:09 -0700 Received: from localhost ([127.0.0.1] helo=lists.colo.xensource.com) by lists.xensource.com with esmtp (Exim 4.43) id 1R4DS3-0004v4-Mk; Thu, 15 Sep 2011 08:02:07 -0700 Received: from mail182.messagelabs.com ([85.158.139.83]) by lists.xensource.com with esmtp (Exim 4.43) id 1R4DOx-0004ak-3X for xen-devel@lists.xensource.com; Thu, 15 Sep 2011 07:59:00 -0700 X-Env-Sender: konrad@oracle.com X-Msg-Ref: server-2.tower-182.messagelabs.com!1316098729!17486238!1 X-Originating-IP: [141.146.126.227] X-StarScan-Version: 6.4.1; banners=-,-,- X-VirusChecked: Checked Received: (qmail 388 invoked from network); 15 Sep 2011 14:58:50 -0000 Received: from acsinet15.oracle.com (HELO acsinet15.oracle.com) (141.146.126.227) by server-2.tower-182.messagelabs.com with DHE-RSA-AES256-SHA encrypted SMTP; 15 Sep 2011 14:58:50 -0000 Received: from rtcsinet22.oracle.com (rtcsinet22.oracle.com [66.248.204.30]) by acsinet15.oracle.com (Switch-3.4.4/Switch-3.4.4) with ESMTP id p8FEwk20021228 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Thu, 15 Sep 2011 14:58:48 GMT Received: from acsmt358.oracle.com (acsmt358.oracle.com [141.146.40.158]) by rtcsinet22.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id p8FEwj4c005412 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 15 Sep 2011 14:58:46 GMT Received: from abhmt104.oracle.com (abhmt104.oracle.com [141.146.116.56]) by acsmt358.oracle.com (8.12.11.20060308/8.12.11) with ESMTP id p8FEwdhV018990; Thu, 15 Sep 2011 09:58:39 -0500 Received: from oracle.com (/209.6.55.207) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Thu, 15 Sep 2011 07:58:39 -0700 Received: by oracle.com (Postfix, from userid 1000) id 87D691361; Thu, 15 Sep 2011 10:58:40 -0400 (EDT) Date: Thu, 15 Sep 2011 10:58:40 -0400 From: Konrad Rzeszutek Wilk To: Fantu Subject: Re: [Xen-devel] Re: Out sw-iommu space problem Message-ID: <20110915145840.GA20726@phenom.oracle.com> References: <1316011454156-4803078.post@n5.nabble.com> <20110914145403.GA17899@phenom.oracle.com> <1316097409687-4807062.post@n5.nabble.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <1316097409687-4807062.post@n5.nabble.com> User-Agent: Mutt/1.5.21 (2010-09-15) X-Source-IP: rtcsinet22.oracle.com [66.248.204.30] X-CT-RefId: str=0001.0A090208.4E7212A8.01FD,ss=1,re=0.000,fgs=0 Cc: xen-devel@lists.xensource.com X-BeenThere: xen-devel@lists.xensource.com X-Mailman-Version: 2.1.5 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xensource.com Errors-To: xen-devel-bounces@lists.xensource.com > > Sep 15 15:29:15 heliMN02WV kernel: [ 641.006286] tapdisk2[6891]: segfault > at 7fff58bb7fe8 ip 00000000004082ac sp 00007fff58bb7ff0 error 6 in > tapdisk2[400000+39000] > Sep 15 15:29:15 heliMN02WV kernel: [ 641.026060] BUG: unable to handle > kernel NULL pointer dereference at 0000000000000048 > Sep 15 15:29:15 heliMN02WV kernel: [ 641.026200] IP: [] > apply_to_page_range+0x47/0x2f3 > Sep 15 15:29:15 heliMN02WV kernel: [ 641.026291] PGD 0 > Sep 15 15:29:15 heliMN02WV kernel: [ 641.026371] Oops: 0000 [#1] SMP > Sep 15 15:29:15 heliMN02WV kernel: [ 641.026483] last sysfs file: > /sys/devices/virtual/blktap2/blktap6/remove > Sep 15 15:29:15 heliMN02WV kernel: [ 641.026541] CPU 2 > Sep 15 15:29:15 heliMN02WV kernel: [ 641.026619] Modules linked in: > xt_tcpudp tun xt_physdev iptable_filter ip_tables x_tables bridge stp > ib_iser rdma_cm ib_cm iw_cm ib_sa ib_mad ib_core ib_addr iscsi_tcp > libiscsi_tcp libiscsi scsi_transport_iscsi ext2 sha256_generic aes_x86_64 > aes_generic cbc blktap xen_evtchn xenfs loop dm_crypt snd_pcm snd_timer snd > soundcore snd_page_alloc evdev joydev dcdbas pcspkr power_meter button > processor acpi_processor ext4 mbcache jbd2 crc16 dm_mod sd_mod crc_t10dif sg > sr_mod cdrom usbhid hid ata_generic ehci_hcd ata_piix usbcore libata > nls_base bnx2 mpt2sas scsi_transport_sas scsi_mod thermal thermal_sys [last > unloaded: scsi_wait_scan] > Sep 15 15:29:15 heliMN02WV kernel: [ 641.029000] Pid: 6891, comm: tapdisk2 > Not tainted 2.6.32-5-xen-amd64 #1 PowerEdge T310 > Sep 15 15:29:15 heliMN02WV kernel: [ 641.029082] RIP: > e030:[] [] > apply_to_page_range+0x47/0x2f3 > Sep 15 15:29:15 heliMN02WV kernel: [ 641.029191] RSP: e02b:ffff88003dda3b58 > EFLAGS: 00010202 > Sep 15 15:29:15 heliMN02WV kernel: [ 641.029246] RAX: 0000000000000880 RBX: > ffff88003ebc1000 RCX: ffff88003ebc2000 > Sep 15 15:29:15 heliMN02WV kernel: [ 641.029313] RDX: 0000000000000000 RSI: > ffff88003ebc1000 RDI: 0000000000000000 > Sep 15 15:29:15 heliMN02WV kernel: [ 641.029372] RBP: ffff88003e7383d0 R08: > 0000000000000000 R09: ffff88003c4d4780 > Sep 15 15:29:15 heliMN02WV kernel: [ 641.029431] R10: 0000000000000002 R11: > 0000000000000000 R12: 0000000000000000 > Sep 15 15:29:15 heliMN02WV kernel: [ 641.029491] R13: ffff88003e7383d0 R14: > ffff88003deb7800 R15: 0000000000000000 > Sep 15 15:29:15 heliMN02WV kernel: [ 641.029555] FS: > 00007f185cd15740(0000) GS:ffff880003728000(0000) knlGS:0000000000000000 > Sep 15 15:29:15 heliMN02WV kernel: [ 641.029630] CS: e033 DS: 0000 ES: > 0000 CR0: 000000008005003b > Sep 15 15:29:15 heliMN02WV kernel: [ 641.029686] CR2: 0000000000000048 CR3: > 0000000001001000 CR4: 0000000000002660 > Sep 15 15:29:15 heliMN02WV kernel: [ 641.029744] DR0: 0000000000000000 DR1: > 0000000000000000 DR2: 0000000000000000 > Sep 15 15:29:15 heliMN02WV kernel: [ 641.029802] DR3: 0000000000000000 DR6: > 00000000ffff0ff0 DR7: 0000000000000400 > Sep 15 15:29:15 heliMN02WV kernel: [ 641.029861] Process tapdisk2 (pid: > 6891, threadinfo ffff88003dda2000, task ffff8800027ae9f0) > Sep 15 15:29:15 heliMN02WV kernel: [ 641.029936] Stack: > Sep 15 15:29:15 heliMN02WV kernel: [ 641.029984] 0000000000000000 > ffff880001d03b40 0000000000000000 0000000000000000 > Sep 15 15:29:15 heliMN02WV kernel: [ 641.030134] <0> ffffffffa02dcee8 > 0000000000000000 ffffffff8100ece2 ffff8800023c9cc0 > Sep 15 15:29:15 heliMN02WV kernel: [ 641.030359] <0> ffff88003ebc2000 > 0000000000000000 0000000000000000 ffff8800023c9cc0 > Sep 15 15:29:15 heliMN02WV kernel: [ 641.030635] Call Trace: > Sep 15 15:29:15 heliMN02WV kernel: [ 641.030699] [] ? > blktap_umap_uaddr_fn+0x0/0x59 [blktap] > Sep 15 15:29:15 heliMN02WV kernel: [ 641.030764] [] ? > check_events+0x12/0x20 > Sep 15 15:29:15 heliMN02WV kernel: [ 641.030831] [] ? > blktap_device_end_request+0xbd/0x145 [blktap] > Sep 15 15:29:15 heliMN02WV kernel: [ 641.030917] [] ? > blktap_ring_vm_close+0x60/0xd1 [blktap] > Sep 15 15:29:15 heliMN02WV kernel: [ 641.030977] [] ? > remove_vma+0x2c/0x72 > Sep 15 15:29:15 heliMN02WV kernel: [ 641.031040] [] ? > exit_mmap+0x129/0x148 > Sep 15 15:29:15 heliMN02WV kernel: [ 641.031097] [] ? > mmput+0x3c/0xdf > Sep 15 15:29:15 heliMN02WV kernel: [ 641.031153] [] ? > exit_mm+0x102/0x10d > Sep 15 15:29:15 heliMN02WV kernel: [ 641.031212] [] ? > _spin_lock_irq+0x7/0x22 > Sep 15 15:29:15 heliMN02WV kernel: [ 641.031274] [] ? > do_exit+0x1f8/0x6c6 > Sep 15 15:29:15 heliMN02WV kernel: [ 641.031340] [] ? > __dequeue_signal+0xfb/0x124 > Sep 15 15:29:15 heliMN02WV kernel: [ 641.031399] [] ? > xen_restore_fl_direct_end+0x0/0x1 > Sep 15 15:29:15 heliMN02WV kernel: [ 641.031458] [] ? > kmem_cache_free+0x72/0xa3 > Sep 15 15:29:15 heliMN02WV kernel: [ 641.031514] [] ? > do_group_exit+0x76/0x9d > Sep 15 15:29:15 heliMN02WV kernel: [ 641.031570] [] ? > get_signal_to_deliver+0x310/0x339 > Sep 15 15:29:15 heliMN02WV kernel: [ 641.031627] [] ? > do_notify_resume+0x87/0x73f > Sep 15 15:29:15 heliMN02WV kernel: [ 641.031684] [] ? > expand_downwards+0x5b/0x169 > Sep 15 15:29:15 heliMN02WV kernel: [ 641.031742] [] ? > do_page_fault+0x1f3/0x2f2 > Sep 15 15:29:15 heliMN02WV kernel: [ 641.031798] [] ? > retint_signal+0x48/0x8c > Sep 15 15:29:15 heliMN02WV kernel: [ 641.031853] Code: 48 89 4c 24 20 4c 89 > 44 24 18 48 89 54 24 40 72 04 0f 0b eb fe 48 8b 54 24 28 48 89 f0 48 8b 4c > 24 40 48 c1 e8 24 25 f8 0f 00 00 <48> 8b 52 48 48 ff c9 48 89 0c 24 48 01 d0 > 48 89 44 24 30 48 b8 > Sep 15 15:29:15 heliMN02WV kernel: [ 641.033878] RIP [] > apply_to_page_range+0x47/0x2f3 > Sep 15 15:29:15 heliMN02WV kernel: [ 641.033965] RSP > Sep 15 15:29:15 heliMN02WV kernel: [ 641.034015] CR2: 0000000000000048 > Sep 15 15:29:15 heliMN02WV kernel: [ 641.034067] ---[ end trace > 162efc545a37e94b ]--- > Sep 15 15:29:15 heliMN02WV kernel: [ 641.034120] Fixing recursive fault but > reboot is needed! > > Hm, there was another thread aobut it, and the analysis looks like it is: xen: x86_32: do not enable iterrupts when returning from which is getting backported in 2.6.32. _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel From xen-devel-bounces@lists.xensource.com Thu Sep 15 08:04:39 2011 Return-path: Envelope-to: www-data@lists.xensource.com Delivery-date: Thu, 15 Sep 2011 08:04:40 -0700 Received: from localhost ([127.0.0.1] helo=lists.colo.xensource.com) by lists.xensource.com with esmtp (Exim 4.43) id 1R4DUU-0005J5-Pz; Thu, 15 Sep 2011 08:04:38 -0700 Received: from mail174.messagelabs.com ([85.158.138.51]) by lists.xensource.com with esmtp (Exim 4.43) id 1R4DQH-0004hV-Lh for xen-devel@lists.xensource.com; Thu, 15 Sep 2011 08:00:31 -0700 X-Env-Sender: Ian.Campbell@eu.citrix.com X-Msg-Ref: server-3.tower-174.messagelabs.com!1316098810!25496419!1 X-Originating-IP: [66.165.176.89] X-StarScan-Version: 6.4.1; banners=-,-,- X-VirusChecked: Checked Received: (qmail 5250 invoked from network); 15 Sep 2011 15:00:12 -0000 Received: from smtp.citrix.com (HELO SMTP.CITRIX.COM) (66.165.176.89) by server-3.tower-174.messagelabs.com with RC4-SHA encrypted SMTP; 15 Sep 2011 15:00:12 -0000 X-IronPort-AV: E=Sophos;i="4.68,387,1312171200"; d="scan'208";a="17329579" Received: from ftlpmailmx01.citrite.net ([10.13.107.65]) by FTLPIPO01.CITRIX.COM with ESMTP/TLS/RC4-MD5; 15 Sep 2011 11:00:09 -0400 Received: from [127.0.0.1] (10.80.16.67) by smtprelay.citrix.com (10.13.107.65) with Microsoft SMTP Server id 8.3.137.0; Thu, 15 Sep 2011 11:00:09 -0400 From: Ian Campbell To: "stefano.stabellini@eu.citrix.com" Date: Thu, 15 Sep 2011 17:00:07 +0200 In-Reply-To: <1316098843-19974-3-git-send-email-stefano.stabellini@eu.citrix.com> References: <1316098843-19974-3-git-send-email-stefano.stabellini@eu.citrix.com> Organization: Citrix Systems, Inc. Content-Type: text/plain; charset="UTF-8" X-Mailer: Evolution 3.0.3- Content-Transfer-Encoding: 7bit Message-ID: <1316098809.26990.19.camel@cthulhu.hellion.org.uk> MIME-Version: 1.0 Cc: Ian Jackson , "xen-devel@lists.xensource.com" , "keir@xen.org" Subject: [Xen-devel] Re: [PATCH v4 3/4] Clone and build upstream Qemu by default X-BeenThere: xen-devel@lists.xensource.com X-Mailman-Version: 2.1.5 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xensource.com Errors-To: xen-devel-bounces@lists.xensource.com On Thu, 2011-09-15 at 11:00 -0400, stefano.stabellini@eu.citrix.com wrote: > > +# Only available through the git protocol at the moment This comment is now out of date... > +ifeq ($(GIT_HTTP),y) > +QEMU_UPSTREAM_URL ?= http://xenbits.xensource.com/git-http/qemu-upstream-unstable.git > +else > +QEMU_UPSTREAM_URL ?= git://xenbits.xensource.com/qemu-upstream-unstable.git > +endif > +QEMU_UPSTREAM_TAG ?= 6dd84c71dff047f9e492d67e7c99928d09202760 > + _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel From xen-devel-bounces@lists.xensource.com Thu Sep 15 08:11:42 2011 Return-path: Envelope-to: www-data@lists.xensource.com Delivery-date: Thu, 15 Sep 2011 08:11:42 -0700 Received: from localhost ([127.0.0.1] helo=lists.colo.xensource.com) by lists.xensource.com with esmtp (Exim 4.43) id 1R4DbJ-0005oX-SZ; Thu, 15 Sep 2011 08:11:41 -0700 Received: from mail182.messagelabs.com ([85.158.139.83]) by lists.xensource.com with smtp (Exim 4.43) id 1R4DaS-0005c5-P5 for xen-devel@lists.xensource.com; Thu, 15 Sep 2011 08:10:50 -0700 X-Env-Sender: mike@flyn.org X-Msg-Ref: server-6.tower-182.messagelabs.com!1316099444!18471799!1 X-Originating-IP: [98.139.44.194] X-StarScan-Version: 6.4.1; banners=-,-,- X-VirusChecked: Checked Received: (qmail 20436 invoked from network); 15 Sep 2011 15:10:45 -0000 Received: from nm30-vm0.access.bullet.mail.sp2.yahoo.com (HELO nm30-vm0.access.bullet.mail.sp2.yahoo.com) (98.139.44.194) by server-6.tower-182.messagelabs.com with SMTP; 15 Sep 2011 15:10:45 -0000 Received: from [98.139.44.100] by nm30.access.bullet.mail.sp2.yahoo.com with NNFMP; 15 Sep 2011 15:10:44 -0000 Received: from [98.139.44.87] by tm5.access.bullet.mail.sp2.yahoo.com with NNFMP; 15 Sep 2011 15:10:44 -0000 Received: from [127.0.0.1] by omp1024.access.mail.sp2.yahoo.com with NNFMP; 15 Sep 2011 15:10:44 -0000 X-Yahoo-Newman-Id: 475953.31571.bm@omp1024.access.mail.sp2.yahoo.com Received: (qmail 91931 invoked from network); 15 Sep 2011 15:10:44 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s1024; t=1316099444; bh=SNbI0aAVtjxkI8cbt5Xdd/l+95DsauVxvkH3h5WGrME=; h=X-Yahoo-Newman-Property:X-YMail-OSG:X-Yahoo-SMTP:Received:Received:Date:From:To:Cc:Subject:Message-ID:References:MIME-Version:Content-Type:Content-Disposition:In-Reply-To:User-Agent; b=pMOHiKvZMIHxmQ+8W92FHOR+VzYpK/V6NTPxocevfq6j0earkndP+iTuKI7+3kaWQ+Hg5OfY2aheKzXeRRW6q8WhC5bq9FbgTsqs8a9D87aF96w6ohDH/w2VyWXp7ynA3VzL8wQE+5ot5CtFa/Z3qC83z/y7ksvq1Qf3mYruoIM= X-Yahoo-Newman-Property: ymail-3 X-YMail-OSG: DngMoDQVM1nD5RK174brVKTAsZEEx0aMz4UzjNV3IM3YOWk s9oqJ1e_8VlmWNxX_PGr6MszPgaG5senmUUbndqJuBV6JoC.x0I__J3KPPTQ _wvPBynuiA4RPYtBPa_5mf9KGa9mBSa9n12opw59F4AlUhe7RnusKFrtfkQL uQkuPdZf_ybiFPNMAwbQ9BiqGY0eSIRQ8YHJ3WQ04uu78206Ghjaiof8Y9ma yfKk4zmoThxIFM22hJ2dB9fqOu6Of8MBLV88SI1a9iKXvxlEbVWHfOChHCbv vyOlDafqZYZ8GZjAEaW9QYWV2PPRi2d7p1QDlrIXFW1gJFXJ5cVpLlzzdojq emY0equzCS10NUSc_BItUbliolEbb.cF3pLIC42w9lRjhIy_cGJ_3axJxBeJ aD.zcGg99jnJEgHlnYJWrIWK_bnCrUIJNIad50TNq99YWyP40hLH_0SiXqfD STb9Z.igMCWzxaXcDXpWv_BI2vv6uzA-- X-Yahoo-SMTP: 1x8krq.swBD2B21Axr3MHc8r8V8YnFYfUGhbsFMV7v4p Received: from imp.local (mike@99.31.122.188 with login) by smtp104.sbc.mail.gq1.yahoo.com with SMTP; 15 Sep 2011 08:10:43 -0700 PDT Received: by imp.local (Postfix, from userid 1101) id 950315000BD; Thu, 15 Sep 2011 10:10:41 -0500 (CDT) Date: Thu, 15 Sep 2011 10:10:41 -0500 From: "W. Michael Petullo" To: Pasi =?iso-8859-1?Q?K=E4rkk=E4inen?= Message-ID: <20110915151041.GA4453@imp.local> References: <20110914112552.GP12984@reaktio.net> <20110914142522.GA16956@phenom.oracle.com> <20110914144539.GR12984@reaktio.net> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20110914144539.GR12984@reaktio.net> User-Agent: Mutt/1.5.21 (2010-09-15) Cc: Development discussions related to Fedora , xen@lists.fedoraproject.org, xen-devel@lists.xensource.com, Konrad Rzeszutek Wilk , lars.kurth@xen.org, virt@lists.fedoraproject.org, xen-users@lists.xensource.com Subject: [Xen-devel] Re: Virtualization Test Day for F16 and Xen X-BeenThere: xen-devel@lists.xensource.com X-Mailman-Version: 2.1.5 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xensource.com Errors-To: xen-devel-bounces@lists.xensource.com >> There are known bugs in FC15/FC16 that have been filled some time ago that >> folks will sadly run into: 728775, 658387 and 668063 >> >> Fortunatly the bugs have patches attached and the files to be modified are shell scripts. > Yep, links here: > > https://bugzilla.redhat.com/show_bug.cgi?id=728775 The Fedora update system reports this is fixed in grub2-1.99-6.fc16. > https://bugzilla.redhat.com/show_bug.cgi?id=658387 Peter Jones submitted a new grubby package yesterday. This seems to fix bug #658387 (i.e., new-kernel-pkg creates a Dom0-style grub.cfg entry if /etc/sysconfig/kernel contains "HYPERVISOR=/boot/xen.gz"). I have not yet tested this on Fedora 16. However, I did test on Fedora 15. In this case, bug #668063 is still in effect. That is, grubby creates most of a GRUB record, but the "module initramfs-..." entry is missing. Has anyone yet tested this new grubby package on Fedora 16 yet? Does using GRUB 2 makes #668063 irrelevant? > https://bugzilla.redhat.com/show_bug.cgi?id=668063 I just added some more description to this bug. -- Mike :wq _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel From xen-devel-bounces@lists.xensource.com Thu Sep 15 08:13:23 2011 Return-path: Envelope-to: www-data@lists.xensource.com Delivery-date: Thu, 15 Sep 2011 08:13:23 -0700 Received: from localhost ([127.0.0.1] helo=lists.colo.xensource.com) by lists.xensource.com with esmtp (Exim 4.43) id 1R4Dcx-0006Hm-KW; Thu, 15 Sep 2011 08:13:23 -0700 Received: from mail216.messagelabs.com ([85.158.143.99]) by lists.xensource.com with esmtp (Exim 4.43) id 1R4DcS-00065Q-Gm; Thu, 15 Sep 2011 08:12:52 -0700 X-Env-Sender: pasik@iki.fi X-Msg-Ref: server-14.tower-216.messagelabs.com!1316099568!18408504!1 X-Originating-IP: [192.89.123.25] X-StarScan-Version: 6.4.1; banners=-,-,- X-VirusChecked: Checked Received: (qmail 30259 invoked from network); 15 Sep 2011 15:12:49 -0000 Received: from smtp.tele.fi (HELO smtp.tele.fi) (192.89.123.25) by server-14.tower-216.messagelabs.com with DHE-RSA-AES256-SHA encrypted SMTP; 15 Sep 2011 15:12:49 -0000 X-Originating-Ip: [194.89.68.22] Received: from ydin.reaktio.net (reaktio.net [194.89.68.22]) by smtp.tele.fi (Postfix) with ESMTP id C47E31F29; Thu, 15 Sep 2011 18:12:47 +0300 (EEST) Received: by ydin.reaktio.net (Postfix, from userid 1001) id AA2C8200DB; Thu, 15 Sep 2011 18:12:47 +0300 (EEST) Date: Thu, 15 Sep 2011 18:12:47 +0300 From: Pasi =?iso-8859-1?Q?K=E4rkk=E4inen?= To: Konrad Rzeszutek Wilk Subject: Re: [Xen-devel] Re: Virtualization Test Day for F16 and Xen / dom0 testing instructions Message-ID: <20110915151247.GW12984@reaktio.net> References: <20110914112552.GP12984@reaktio.net> <20110914142522.GA16956@phenom.oracle.com> <20110914144539.GR12984@reaktio.net> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <20110914144539.GR12984@reaktio.net> User-Agent: Mutt/1.5.18 (2008-05-17) Cc: Development discussions related to Fedora , xen@lists.fedoraproject.org, xen-devel@lists.xensource.com, lars.kurth@xen.org, virt@lists.fedoraproject.org, xen-users@lists.xensource.com X-BeenThere: xen-devel@lists.xensource.com X-Mailman-Version: 2.1.5 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xensource.com Errors-To: xen-devel-bounces@lists.xensource.com On Wed, Sep 14, 2011 at 05:45:39PM +0300, Pasi Kärkkäinen wrote: > > > > > > ([3]https://fedorahosted.org/fedora-qa/ticket/219). It takes time for us > > > > to setup test environment, and would be good to have some info in advance. > > Ok, so some basic steps to test Xen dom0 functionality in Fedora 16: - Install Fedora 16 Beta TC2 host, to become Xen dom0. Installable ISO images available here: http://alt.fedoraproject.org/pub/alt/stage/16-Beta.TC2/Fedora/ (and LIVE ISO's here: http://alt.fedoraproject.org/pub/alt/stage/16-Beta.TC2/Live/). - Disk partitioning on the host: First partition should be /boot as ext3, for the rest of the disk use LVM volume group, and remember to leave free space in the volume group so you can later after installation create LVM volumes for the VMs. See these tutorials for an example about disk partitioning: http://wiki.xen.org/xenwiki/Fedora13Xen4Tutorial http://wiki.xen.org/xenwiki/RHEL6Xen4Tutorial - After Fedora 16 is installed and everything works properly on baremetal, including Internet access, proceed to installing Xen and virtualization related packages: yum install xen xen-hypervisor xen-runtime libvirt virt-manager virt-viewer xorg-x11-xauth - Enable automatic start of xend and libvirtd chkconfig xend on chkconfig libvirtd on chkconfig --list xend chkconfig --list libvirtd - Add a suitable grub entry for Xen. This grub entry is just an example, keep your own root device uuids/names etc and modify to suit your setup: menuentry 'Xen dom0, Fedora Linux 3.1.0-rc6' --class fedora --class gnu-linux --class gnu --class os { load_video insmod part_gpt insmod ext2 set root='(hd0,gpt2)' search --no-floppy --fs-uuid --set=root 6b84e53a-8a3a-4465-ac5a-c1c98758e448 multiboot /xen-4.1.gz placeholder dom0_mem=1024M loglvl=all guest_loglvl=all console_to_ring cpuidle=xen echo 'Loading Linux 3.1.0-rc6 ...' module /vmlinuz-3.1.0-rc6 root=/dev/mapper/VolGroup00-lv_root ro rd.md=0 rd.dm=0 KEYTABLE=us debug loglvel=8 rd.lvm.lv=VolGroup00/lv_swap SYSFONT=latarcyrheb-sun16 rd.luks=0 rd.lvm.lv=VolGroup00/lv_root LANG=en_US.UTF-8 echo 'Loading initial ramdisk ...' module /initramfs-3.1.0-rc6.img } grub entries will be automatically generated later, but currently grub/grubby does not have all required patches to do it automatically. - Reboot to Xen dom0! - Verify Xen and xend works: xm info xm list - Verify you have a bridge called "virbr0" (use: "brctl show"). It should get created by libvirtd. There should be a "dnsmasq" process running for virbr0 providing that bridge a DHCP server with private IPs, dns relay and NAT to internet, so you can use it for VM network installations. - Install a Fedora 15 Xen PV domU: First create a new LVM volume for the VM: lvcreate -L30G -nf15_disk1 /dev/VolGroup00 (Replace VolGroup00 with your VG name.. use "vgdisplay" to check.) Start actual installation: virt-install -d -n f15 -r 1024 --vcpus=1 -f /dev/VolGroup00/f15_disk1 --vnc -p -l "ftp://ftp.funet.fi/pub/mirrors/fedora.redhat.com/pub/fedora/linux/releases/15/Fedora/x86_64/os/" (replace the URL with your local Fedora mirror site). virt-install will open a virt-viewer (VNC) graphical window of the guest console (pvfb) where you can do the Fedora installation as usual. - Install and test various other types of VMs, both PV and HVM. - Try using file: disk backend (image files) aswell. - Try using graphical "virt-manager" GUI to install Xen VMs. - Disable automatic start of xend, reboot, and test xl / libxl, also with virt-manager/virt-install. That should get you started with testing. Btw. I noticed some issues installing F16 Alpha Xen PV domU, so F16 needs some more investigation/debugging before F16 final. -- Pasi _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel From xen-devel-bounces@lists.xensource.com Thu Sep 15 08:18:25 2011 Return-path: Envelope-to: www-data@lists.xensource.com Delivery-date: Thu, 15 Sep 2011 08:18:25 -0700 Received: from localhost ([127.0.0.1] helo=lists.colo.xensource.com) by lists.xensource.com with esmtp (Exim 4.43) id 1R4Dhp-0007Me-6a; Thu, 15 Sep 2011 08:18:25 -0700 Received: from mail174.messagelabs.com ([85.158.138.51]) by lists.xensource.com with esmtp (Exim 4.43) id 1R4DhP-0007AW-Sw for xen-devel@lists.xensource.com; Thu, 15 Sep 2011 08:18:00 -0700 X-Env-Sender: Christoph.Egger@amd.com X-Msg-Ref: server-2.tower-174.messagelabs.com!1316099872!31557967!1 X-Originating-IP: [65.55.88.14] X-StarScan-Version: 6.4.1; banners=-,-,- X-VirusChecked: Checked Received: (qmail 21537 invoked from network); 15 Sep 2011 15:17:56 -0000 Received: from tx2ehsobe004.messaging.microsoft.com (HELO TX2EHSOBE007.bigfish.com) (65.55.88.14) by server-2.tower-174.messagelabs.com with AES128-SHA encrypted SMTP; 15 Sep 2011 15:17:56 -0000 Received: from mail35-tx2-R.bigfish.com (10.9.14.246) by TX2EHSOBE007.bigfish.com (10.9.40.27) with Microsoft SMTP Server id 14.1.225.22; Thu, 15 Sep 2011 15:17:48 +0000 Received: from mail35-tx2 (localhost.localdomain [127.0.0.1]) by mail35-tx2-R.bigfish.com (Postfix) with ESMTP id 25BFDC50316; Thu, 15 Sep 2011 15:17:48 +0000 (UTC) X-SpamScore: -11 X-BigFish: VPS-11(zzbb2dK1432N98dKzz1202hzz8275bhz32i668h839h) X-Forefront-Antispam-Report: CIP:163.181.249.109; KIP:(null); UIP:(null); IPVD:NLI; H:ausb3twp02.amd.com; RD:none; EFVD:NLI Received: from mail35-tx2 (localhost.localdomain [127.0.0.1]) by mail35-tx2 (MessageSwitch) id 1316099865974613_22108; Thu, 15 Sep 2011 15:17:45 +0000 (UTC) Received: from TX2EHSMHS006.bigfish.com (unknown [10.9.14.238]) by mail35-tx2.bigfish.com (Postfix) with ESMTP id E30F7B0050; Thu, 15 Sep 2011 15:17:45 +0000 (UTC) Received: from ausb3twp02.amd.com (163.181.249.109) by TX2EHSMHS006.bigfish.com (10.9.99.106) with Microsoft SMTP Server id 14.1.225.22; Thu, 15 Sep 2011 15:16:43 +0000 X-WSS-ID: 0LRKL3O-02-Q7A-02 X-M-MSG: Received: from sausexedgep02.amd.com (sausexedgep02-ext.amd.com [163.181.249.73]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by ausb3twp02.amd.com (Axway MailGate 3.8.1) with ESMTP id 2692DFCC05C; Thu, 15 Sep 2011 10:16:36 -0500 (CDT) Received: from SAUSEXDAG04.amd.com (163.181.55.4) by sausexedgep02.amd.com (163.181.36.59) with Microsoft SMTP Server (TLS) id 8.3.106.1; Thu, 15 Sep 2011 10:17:08 -0500 Received: from storexhtp01.amd.com (172.24.4.3) by sausexdag04.amd.com (163.181.55.4) with Microsoft SMTP Server (TLS) id 14.1.289.1; Thu, 15 Sep 2011 10:16:41 -0500 Received: from [10.224.148.197] (10.224.148.197) by storexhtp01.amd.com (172.24.4.3) with Microsoft SMTP Server id 8.3.83.0; Thu, 15 Sep 2011 11:16:37 -0400 Message-ID: <4E7216D1.4030603@amd.com> Date: Thu, 15 Sep 2011 17:16:33 +0200 From: Christoph Egger User-Agent: Mozilla/5.0 (X11; U; NetBSD amd64; en-US; rv:1.9.2.17) Gecko/20110523 Lightning/1.0b3pre Thunderbird/3.1.10 MIME-Version: 1.0 To: "stefano.stabellini@eu.citrix.com" Subject: Re: [Xen-devel] [PATCH v4 1/4] Introduce git-checkout.sh References: <1316098843-19974-1-git-send-email-stefano.stabellini@eu.citrix.com> In-Reply-To: <1316098843-19974-1-git-send-email-stefano.stabellini@eu.citrix.com> Content-Type: text/plain; charset="ISO-8859-1"; format=flowed Content-Transfer-Encoding: 7bit X-OriginatorOrg: amd.com Cc: "keir@xen.org" , "xen-devel@lists.xensource.com" , "Ian.Jackson@eu.citrix.com" , "Ian.Campbell@citrix.com" X-BeenThere: xen-devel@lists.xensource.com X-Mailman-Version: 2.1.5 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xensource.com Errors-To: xen-devel-bounces@lists.xensource.com On 09/15/11 17:00, stefano.stabellini@eu.citrix.com wrote: > Introduce a script to perform git checkout on an external git tree; use > git-checkout.sh in ioemu-dir-find. > > Signed-off-by: Stefano Stabellini > > diff --git a/.hgignore b/.hgignore > --- a/.hgignore > +++ b/.hgignore > @@ -291,7 +291,7 @@ > ^tools/xm-test/lib/XmTestLib/config.py$ > ^tools/xm-test/lib/XmTestReport/xmtest.py$ > ^tools/xm-test/tests/.*\.test$ > -^tools/ioemu-remote > +^tools/ioemu-dir-remote > ^tools/ioemu-dir$ > ^tools/ocaml/.*/.*\.annot$ > ^tools/ocaml/.*/.*\.cmx?a$ > diff --git a/scripts/git-checkout.sh b/scripts/git-checkout.sh > new file mode 100755 > --- /dev/null > +++ b/scripts/git-checkout.sh > @@ -0,0 +1,21 @@ > +#!/bin/bash This should be #!/bin/sh . Christoph > + > +TREE=$1 > +TAG=$2 > +DIR=$3 > + > + > +if test \! -d $DIR-remote; then > + rm -rf $DIR-remote $DIR-remote.tmp; > + mkdir $DIR-remote.tmp; rmdir $DIR-remote.tmp; > + git clone $TREE $DIR-remote.tmp; > + if test "$TAG" ; then > + cd $DIR-remote.tmp > + git branch -D dummy>/dev/null 2>&1 ||: > + git checkout -b dummy $TAG > + cd .. > + fi > + mv $DIR-remote.tmp $DIR-remote > +fi > +rm -f $DIR > +ln -sf $DIR-remote $DIR > diff --git a/tools/Makefile b/tools/Makefile > --- a/tools/Makefile > +++ b/tools/Makefile > @@ -70,7 +70,7 @@ clean: subdirs-clean > > .PHONY: distclean > distclean: subdirs-distclean > - rm -rf ioemu-dir ioemu-remote > + rm -rf ioemu-dir ioemu-dir-remote > > ifneq ($(XEN_COMPILE_ARCH),$(XEN_TARGET_ARCH)) > IOEMU_CONFIGURE_CROSS ?= --cpu=$(XEN_TARGET_ARCH) \ > @@ -88,20 +88,7 @@ ioemu-dir-find: > if test -d $(CONFIG_QEMU); then \ > mkdir -p ioemu-dir; \ > else \ > - if [ ! -d ioemu-remote ]; then \ > - rm -rf ioemu-remote ioemu-remote.tmp; \ > - mkdir ioemu-remote.tmp; rmdir ioemu-remote.tmp; \ > - $(GIT) clone $(CONFIG_QEMU) ioemu-remote.tmp; \ > - if [ "$(QEMU_TAG)" ]; then \ > - cd ioemu-remote.tmp; \ > - $(GIT) branch -D dummy>/dev/null 2>&1 ||:; \ > - $(GIT) checkout -b dummy $(QEMU_TAG); \ > - cd ..; \ > - fi; \ > - mv ioemu-remote.tmp ioemu-remote; \ > - fi; \ > - rm -f ioemu-dir; \ > - ln -sf ioemu-remote ioemu-dir; \ > + $(XEN_ROOT)/scripts/git-checkout.sh $(CONFIG_QEMU) $(QEMU_TAG) ioemu-dir; \ > fi > set -e; \ > $(buildmakevars2shellvars); \ > @@ -112,7 +99,7 @@ ioemu-dir-find: > ioemu-dir-force-update: > set -ex; \ > if [ "$(QEMU_TAG)" ]; then \ > - cd ioemu-remote; \ > + cd ioemu-dir-remote; \ > $(GIT) fetch origin; \ > $(GIT) reset --hard $(QEMU_TAG); \ > fi > > _______________________________________________ > Xen-devel mailing list > Xen-devel@lists.xensource.com > http://lists.xensource.com/xen-devel > -- ---to satisfy European Law for business letters: Advanced Micro Devices GmbH Einsteinring 24, 85689 Dornach b. Muenchen Geschaeftsfuehrer: Alberto Bozzo, Andrew Bowd Sitz: Dornach, Gemeinde Aschheim, Landkreis Muenchen Registergericht Muenchen, HRB Nr. 43632 _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel From xen-devel-bounces@lists.xensource.com Thu Sep 15 08:19:42 2011 Return-path: Envelope-to: www-data@lists.xensource.com Delivery-date: Thu, 15 Sep 2011 08:19:42 -0700 Received: from localhost ([127.0.0.1] helo=lists.colo.xensource.com) by lists.xensource.com with esmtp (Exim 4.43) id 1R4Dj4-0007l7-Eg; Thu, 15 Sep 2011 08:19:42 -0700 Received: from mail182.messagelabs.com ([85.158.139.83]) by lists.xensource.com with esmtp (Exim 4.43) id 1R4Dig-0007ZQ-Ef for xen-devel@lists.xensource.com; Thu, 15 Sep 2011 08:19:18 -0700 X-Env-Sender: royger@gmail.com X-Msg-Ref: server-5.tower-182.messagelabs.com!1316099954!13496432!1 X-Originating-IP: [209.85.216.171] X-StarScan-Version: 6.4.1; banners=-,-,- X-VirusChecked: Checked Received: (qmail 23132 invoked from network); 15 Sep 2011 15:19:15 -0000 Received: from mail-qy0-f171.google.com (HELO mail-qy0-f171.google.com) (209.85.216.171) by server-5.tower-182.messagelabs.com with RC4-SHA encrypted SMTP; 15 Sep 2011 15:19:15 -0000 Received: by qyk29 with SMTP id 29so4765259qyk.9 for ; Thu, 15 Sep 2011 08:19:14 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=mKj3Vd2MoMU4TlClRMCDiNZRasEyCVfb0O/sUvC6+9c=; b=Ga1Cy6JWTBmYHHgTh0bwgj2skuE9f07WkG6P6ADqwpaqt/CKureNG5h/HGfTBcJIp6 o1KSKwlnRv6Uw0wPH1CAQmiki7ND9MR193DiV9brn2M3SyHBCV7s9PzBH/CAQEJULDGx OnksI+wtKmhJ1UfS2t/W/ERziA5+720qJgYbo= MIME-Version: 1.0 Received: by 10.224.71.7 with SMTP id f7mr1148960qaj.153.1316099954062; Thu, 15 Sep 2011 08:19:14 -0700 (PDT) Received: by 10.229.213.1 with HTTP; Thu, 15 Sep 2011 08:19:14 -0700 (PDT) In-Reply-To: <1316094117.26990.8.camel@cthulhu.hellion.org.uk> References: <015617579cd36fc58318.1316091805@loki> <1316094117.26990.8.camel@cthulhu.hellion.org.uk> Date: Thu, 15 Sep 2011 17:19:14 +0200 X-Google-Sender-Auth: 4yaQxIp1Xsp809kcbu2L8VtBPgU Message-ID: Subject: Re: [Xen-devel] [PATCH] libxl: add support for booting PV domains from NetBSD using raw files as disks. Fixed the shutdown race problem by checking "hotplug-status" instead of "state" xenstore variable in NetBSD From: =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= To: Ian Campbell Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Cc: "xen-devel@lists.xensource.com" X-BeenThere: xen-devel@lists.xensource.com X-Mailman-Version: 2.1.5 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xensource.com Errors-To: xen-devel-bounces@lists.xensource.com 2011/9/15 Ian Campbell : > On Thu, 2011-09-15 at 09:03 -0400, Roger Pau Monne wrote: >> # HG changeset patch >> # User Roger Pau Monne >> # Date 1316091721 -7200 >> # Node ID 015617579cd36fc58318aaf350bec5f7cc07ef2f >> # Parent =C2=A063e254468d6e8d81baeafaed68f05791dc21eb4e >> libxl: add support for booting PV domains from NetBSD using raw files >> as disks. Fixed the shutdown race problem by checking "hotplug-status" >> instead of "state" xenstore variable in NetBSD. > > This was one long line which mercurial will use as a summary, it's a > good idea to make sure that the first line stands somewhat alone as a > summary so the e.g. "hg log" is useful. > Also this sounds on the face of it like two bugfixes, if that's the case > they should be submitted separately. Well, it's not a bugfix, because NetBSD was not supported by libxl, so I think it's just part of the patch to add support for NetBSD to libxl. I will split the line, and the patch if it's necessary, but one doesn't make sense without the other, and I don't really know what would be in each patch. >> >> Signed-off-by: Roger Pau Monne >> >> diff -r 63e254468d6e -r 015617579cd3 tools/hotplug/NetBSD/block >> --- a/tools/hotplug/NetBSD/block =C2=A0 =C2=A0 =C2=A0Wed Sep 14 14:18:40= 2011 +0200 >> +++ b/tools/hotplug/NetBSD/block =C2=A0 =C2=A0 =C2=A0Thu Sep 15 15:02:01= 2011 +0200 >> @@ -19,7 +19,7 @@ error() { >> >> =C2=A0xpath=3D$1 >> =C2=A0xstatus=3D$2 >> -xtype=3D$(xenstore-read "$xpath/type") >> +xtype=3D$3 >> =C2=A0xparams=3D$(xenstore-read "$xpath/params") >> >> =C2=A0case $xstatus in >> @@ -38,6 +38,8 @@ 6) >> =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 echo "unknown type $xty= pe" >&2 >> =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 ;; >> =C2=A0 =C2=A0 =C2=A0 esac >> + =C2=A0 =C2=A0 echo xenstore-write $xpath/hotplug-status disconnected > > leftover debugging? The block NetBSD script contains some echos, so I feel it would be interesting to add this one too. >> + =C2=A0 =C2=A0 xenstore-write $xpath/hotplug-status disconnected >> =C2=A0 =C2=A0 =C2=A0 xenstore-rm $xpath >> =C2=A0 =C2=A0 =C2=A0 exit 0 >> =C2=A0 =C2=A0 =C2=A0 ;; >> =C2=A0 =C2=A0 =C2=A0libxl_ctx *ctx =3D libxl__gc_owner(gc); >> =C2=A0 =C2=A0 =C2=A0xs_transaction_t t; >> =C2=A0 =C2=A0 =C2=A0char *state_path =3D libxl__sprintf(gc, "%s/state", = be_path); >> + =C2=A0 =C2=A0char *hotplug_path =3D libxl__sprintf(gc, "%s/hotplug-sta= tus", be_path); >> =C2=A0 =C2=A0 =C2=A0char *state =3D libxl__xs_read(gc, XBT_NULL, state_p= ath); >> + =C2=A0 =C2=A0char *hotplug =3D libxl__xs_read(gc, XBT_NULL, hotplug_pa= th); >> =C2=A0 =C2=A0 =C2=A0int rc =3D 0; >> >> =C2=A0 =C2=A0 =C2=A0if (!state) >> =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0goto out; >> + >> +#ifdef HAVE_PHY_BACKEND_FILE_SUPPORT >> + =C2=A0 =C2=A0if (!strstr(be_path, "vbd")) { >> + =C2=A0 =C2=A0 =C2=A0 =C2=A0if (atoi(state) !=3D 4) { >> + =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0xs_rm(ctx->xsh, XBT_NULL, be_= path); >> + =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0goto out; >> + =C2=A0 =C2=A0 =C2=A0 =C2=A0} >> + =C2=A0 =C2=A0} else { >> + =C2=A0 =C2=A0 =C2=A0 =C2=A0if (!hotplug) >> + =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0goto out; >> + =C2=A0 =C2=A0 =C2=A0 =C2=A0if (!strcmp(hotplug, "disconnected")) { >> + =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0xs_rm(ctx->xsh, XBT_NULL, be_= path); >> + =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0goto out; >> + =C2=A0 =C2=A0 =C2=A0 =C2=A0} >> + =C2=A0 =C2=A0} > > Do the other backend types also write this node? It looks like Linux > does, at least in some circumstances (tap and vbd AFAICT), in which case > perhaps this is suitable as the only test here (i.e. drop the #ifdef and > the #else case). That would remove a lot of the conditional code in this > patch. If Linux also uses this, I will have to modify the Linux block script, so that it sets hotplug-status to "disconnected" also. This will be nice, I don't like code with #ifdefs as it tends to get messy and it's not easy to understand. Regards, Roger. _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel From xen-devel-bounces@lists.xensource.com Thu Sep 15 08:20:55 2011 Return-path: Envelope-to: www-data@lists.xensource.com Delivery-date: Thu, 15 Sep 2011 08:20:55 -0700 Received: from localhost ([127.0.0.1] helo=lists.colo.xensource.com) by lists.xensource.com with esmtp (Exim 4.43) id 1R4DkF-00088U-8j; Thu, 15 Sep 2011 08:20:55 -0700 Received: from mail21.messagelabs.com ([85.158.143.35]) by lists.xensource.com with esmtp (Exim 4.43) id 1R4Djk-0007wY-Aw for xen-devel@lists.xensource.com; Thu, 15 Sep 2011 08:20:24 -0700 X-Env-Sender: olaf@aepfle.de X-Msg-Ref: server-6.tower-21.messagelabs.com!1316100001!38386178!1 X-Originating-IP: [81.169.146.160] X-StarScan-Version: 6.4.1; banners=-,-,- X-VirusChecked: Checked Received: (qmail 28821 invoked from network); 15 Sep 2011 15:20:01 -0000 Received: from mo-p00-ob.rzone.de (HELO mo-p00-ob.rzone.de) (81.169.146.160) by server-6.tower-21.messagelabs.com with EDH-RSA-DES-CBC3-SHA encrypted SMTP; 15 Sep 2011 15:20:01 -0000 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; t=1316100020; l=9234; s=domk; d=aepfle.de; h=To:From:Date:Subject:Content-Transfer-Encoding:MIME-Version: Content-Type:X-RZG-CLASS-ID:X-RZG-AUTH; bh=6fyXYzqT9/v9GkYNf79HN+5qFwM=; b=E1mU64jrSZYCO/PozBRJnRJ0t4RKkvjHhU7c+vzBSXay/Uavq0ZYYLAW1xv/OiZzI6l mqi9do6AyD4CwUqEd7gNAqPRhp6e2YL0jebINgbmM/Wk8Ut1jM8aEnRgFgvjTpMK6+2zK N+QhuhbpK/oa3PqGIMaKqXrmPd60avUhu30= X-RZG-AUTH: :P2EQZWCpfu+qG7CngxMFH1J+zrwiavkK6tmQaLfmxtMZ80VwmRNV7HU= X-RZG-CLASS-ID: mo00 Received: from probook.site (ip-80-226-24-6.vodafone-net.de [80.226.24.6]) by smtp.strato.de (fruni mo21) (RZmta 26.7) with (EDH-RSA-DES-CBC3-SHA encrypted) ESMTPA id 602e17n8FFGcVT for ; Thu, 15 Sep 2011 17:20:15 +0200 (MEST) Received: from probook.site (localhost [IPv6:::1]) by probook.site (Postfix) with ESMTP id 36ADF18B66 for ; Thu, 15 Sep 2011 17:20:13 +0200 (CEST) Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Mercurial-Node: c9a9779fd9581666c3276f95020ad12e8ceff930 Message-Id: User-Agent: Mercurial-patchbomb/1.7.5 Date: Thu, 15 Sep 2011 17:20:11 +0200 From: Olaf Hering To: xen-devel@lists.xensource.com Subject: [Xen-devel] [PATCH] xenpaging: libxl support X-BeenThere: xen-devel@lists.xensource.com X-Mailman-Version: 2.1.5 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xensource.com Errors-To: xen-devel-bounces@lists.xensource.com # HG changeset patch # User Olaf Hering # Date 1316099907 -7200 # Node ID c9a9779fd9581666c3276f95020ad12e8ceff930 # Parent 7fb21fac6d7d0a20a7af9aa2caa6fb4145ee3e23 xenpaging: libxl support Add support to libxl for starting xenpaging, I send it out for review. It mimics what the code to start qemu-dm does. The patch adds four new config options: xenpaging= , the number of pages to page-out xenpaging_dir=, the working directory where the pagefile is stored xenpaging_debug=, enable or disable debug output xenpaging_policy_mru_size=, tweak the number of most-recently-used pages There are still a few pieces missing like 'xl list -l'. Signed-off-by: Olaf Hering diff -r 7fb21fac6d7d -r c9a9779fd958 tools/libxl/libxl.h --- a/tools/libxl/libxl.h +++ b/tools/libxl/libxl.h @@ -229,6 +229,7 @@ typedef struct { libxl_domain_create_info c_info; libxl_domain_build_info b_info; libxl_device_model_info dm_info; + libxl_xenpaging_info xp_info; int num_disks, num_vifs, num_pcidevs, num_vfbs, num_vkbs; diff -r 7fb21fac6d7d -r c9a9779fd958 tools/libxl/libxl.idl --- a/tools/libxl/libxl.idl +++ b/tools/libxl/libxl.idl @@ -190,6 +190,17 @@ by libxl_domain_build/restore. If either then the user is responsible for calling libxl_file_reference_unmap.""") +libxl_xenpaging_info = Struct("xenpaging_info",[ + ("xenpaging", integer, False, "number of pages"), + ("xenpaging_workdir", string, False, "directory to store guest page file"), + ("xenpaging_debug", bool, False, "enable debug output in pager"), + ("xenpaging_policy_mru_size", integer, False, "number of paged-in pages to keep in memory"), + ], + comment= +"""xenpaging information. + +Something review is missing""") + libxl_device_model_info = Struct("device_model_info",[ ("domid", libxl_domid), ("uuid", libxl_uuid, False, "this is use only with stubdom, and must be different from the domain uuid"), diff -r 7fb21fac6d7d -r c9a9779fd958 tools/libxl/libxl_create.c --- a/tools/libxl/libxl_create.c +++ b/tools/libxl/libxl_create.c @@ -429,6 +429,109 @@ retry_transaction: return rc; } +static void xp_xenstore_record_pid(void *for_spawn, pid_t innerchild) +{ + libxl__device_model_starting *starting = for_spawn; + struct xs_handle *xsh; + char *path = NULL, *pid = NULL; + int len; + + if (asprintf(&path, "%s/%s", starting->dom_path, "xenpaging/xenpaging-pid") < 0) + goto out; + + len = asprintf(&pid, "%d", innerchild); + if (len < 0) + goto out; + + /* we mustn't use the parent's handle in the child */ + xsh = xs_daemon_open(); + + xs_write(xsh, XBT_NULL, path, pid, len); + + xs_daemon_close(xsh); +out: + free(path); + free(pid); +} + +static int libxl__create_xenpaging(libxl__gc *gc, char *dom_name, uint32_t domid, libxl_xenpaging_info *xp_info) +{ + libxl__xenpaging_starting buf_starting; + int rc; + char *logfile; + int logfile_w, null; + char **args; + char *xp; + flexarray_t *xp_args; + libxl_ctx *ctx = libxl__gc_owner(gc); + + /* Check if paging is enabled */ + if (!xp_info->xenpaging) + return 0; + + /* Check if xenpaging is present */ + xp = libxl__abs_path(gc, "xenpaging", libxl_libexec_path()); + if (access(xp, X_OK) < 0) { + LIBXL__LOG_ERRNO(ctx, LIBXL__LOG_ERROR, "%s is not executable", xp); + rc = ERROR_FAIL; + goto out; + } + + /* Initialise settings for child */ + buf_starting.domid = domid; + buf_starting.dom_path = libxl__xs_get_dompath(gc, domid); + if (!buf_starting.dom_path) { + rc = ERROR_FAIL; + goto out; + } + + /* Set working directory if not specified in config file */ + if (!xp_info->xenpaging_workdir) + xp_info->xenpaging_workdir = "/var/lib/xen/xenpaging"; + + /* Assemble arguments for xenpaging */ + xp_args = flexarray_make(16, 1); + if (!xp_args) + { + rc = ERROR_NOMEM; + goto out; + } + flexarray_vappend(xp_args, xp, libxl__sprintf(gc, "%u", domid), libxl__sprintf(gc, "%d", xp_info->xenpaging), NULL); + flexarray_append(xp_args, NULL); + args = (char **) flexarray_contents(xp_args); + + /* Initialise logfile */ + libxl_create_logfile(ctx, libxl__sprintf(gc, "xenpaging-%s-%u", dom_name, domid), &logfile); + logfile_w = open(logfile, O_WRONLY|O_CREAT, 0644); + free(logfile); + null = open("/dev/null", O_RDONLY); + + /* Spawn the child */ + rc = libxl__spawn_spawn(gc, NULL, "xenpaging", xp_xenstore_record_pid, &buf_starting); + if (rc < 0) + goto out_close; + if (!rc) { /* inner child */ + setsid(); + /* Enable debug output in the child */ + if (xp_info->xenpaging_debug) + setenv("XENPAGING_DEBUG", "1", 1); + /* Adjust most-recently-used value in the child */ + if (xp_info->xenpaging_policy_mru_size) + setenv("XENPAGING_POLICY_MRU_SIZE", libxl__sprintf(gc, "%d", xp_info->xenpaging_policy_mru_size), 1); + /* Change working directory */ + if (chdir(xp_info->xenpaging_workdir)) + LIBXL__LOG_ERRNO(ctx, LIBXL__LOG_ERROR, "%s", xp_info->xenpaging_workdir); + /* Finally run xenpaging */ + libxl__exec(null, logfile_w, logfile_w, xp, args); + } +out_close: + close(null); + close(logfile_w); + free(args); +out: + return rc; +} + static int do_domain_create(libxl__gc *gc, libxl_domain_config *d_config, libxl_console_ready cb, void *priv, uint32_t *domid_out, int restore_fd) @@ -436,6 +539,7 @@ static int do_domain_create(libxl__gc *g libxl_ctx *ctx = libxl__gc_owner(gc); libxl__device_model_starting *dm_starting = 0; libxl_device_model_info *dm_info = &d_config->dm_info; + libxl_xenpaging_info *xp_info = &d_config->xp_info; libxl__domain_build_state state; uint32_t domid; int i, ret; @@ -524,6 +628,12 @@ static int do_domain_create(libxl__gc *g "failed to create device model: %d", ret); goto error_out; } + ret = libxl__create_xenpaging(gc, dm_info->dom_name, domid, xp_info); + if (ret < 0) { + LIBXL__LOG(ctx, LIBXL__LOG_ERROR, + "failed to create xenpaging: %d", ret); + goto error_out; + } break; } case LIBXL_DOMAIN_TYPE_PV: diff -r 7fb21fac6d7d -r c9a9779fd958 tools/libxl/libxl_internal.h --- a/tools/libxl/libxl_internal.h +++ b/tools/libxl/libxl_internal.h @@ -251,6 +251,11 @@ typedef struct { libxl__spawn_starting *for_spawn; } libxl__device_model_starting; +typedef struct { + char *dom_path; /* from libxl_malloc, only for xp_xenstore_record_pid */ + int domid; +} libxl__xenpaging_starting; + /* from xl_create */ _hidden int libxl__domain_make(libxl__gc *gc, libxl_domain_create_info *info, uint32_t *domid); _hidden int libxl__domain_build(libxl__gc *gc, diff -r 7fb21fac6d7d -r c9a9779fd958 tools/libxl/xl_cmdimpl.c --- a/tools/libxl/xl_cmdimpl.c +++ b/tools/libxl/xl_cmdimpl.c @@ -290,6 +290,7 @@ static void dolog(const char *file, int static void printf_info(int domid, libxl_domain_config *d_config, + libxl_xenpaging_info *xp_info, libxl_device_model_info *dm_info) { int i; @@ -519,6 +520,7 @@ static void parse_config_data(const char const char *configfile_data, int configfile_len, libxl_domain_config *d_config, + libxl_xenpaging_info *xp_info, libxl_device_model_info *dm_info) { const char *buf; @@ -695,6 +697,15 @@ static void parse_config_data(const char b_info->u.hvm.timer_mode = l; if (!xlu_cfg_get_long (config, "nestedhvm", &l)) b_info->u.hvm.nested_hvm = l; + + if (!xlu_cfg_get_long (config, "xenpaging", &l)) + xp_info->xenpaging = l; + if (!xlu_cfg_get_long (config, "xenpaging_debug", &l)) + xp_info->xenpaging_debug = l; + if (!xlu_cfg_get_long (config, "xenpaging_policy_mru_size", &l)) + xp_info->xenpaging_policy_mru_size = l; + xlu_cfg_replace_string (config, "xenpaging_workdir", &xp_info->xenpaging_workdir); + break; case LIBXL_DOMAIN_TYPE_PV: { @@ -1465,7 +1476,7 @@ static int create_domain(struct domain_c if (!dom_info->quiet) printf("Parsing config file %s\n", config_file); - parse_config_data(config_file, config_data, config_len, &d_config, &d_config.dm_info); + parse_config_data(config_file, config_data, config_len, &d_config, &d_config.xp_info, &d_config.dm_info); if (migrate_fd >= 0) { if (d_config.c_info.name) { @@ -1486,7 +1497,7 @@ static int create_domain(struct domain_c } if (debug || dom_info->dryrun) - printf_info(-1, &d_config, &d_config.dm_info); + printf_info(-1, &d_config, &d_config.xp_info, &d_config.dm_info); ret = 0; if (dom_info->dryrun) @@ -2211,6 +2222,7 @@ static void list_domains_details(const l uint8_t *data; int i, len, rc; libxl_device_model_info dm_info; + libxl_xenpaging_info xp_info; for (i = 0; i < nb_domain; i++) { /* no detailed info available on dom0 */ @@ -2221,8 +2233,8 @@ static void list_domains_details(const l continue; CHK_ERRNO(asprintf(&config_file, "", info[i].domid)); memset(&d_config, 0x00, sizeof(d_config)); - parse_config_data(config_file, (char *)data, len, &d_config, &dm_info); - printf_info(info[i].domid, &d_config, &dm_info); + parse_config_data(config_file, (char *)data, len, &d_config, &xp_info, &dm_info); + printf_info(info[i].domid, &d_config, &xp_info, &dm_info); libxl_domain_config_destroy(&d_config); free(data); free(config_file); _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel From xen-devel-bounces@lists.xensource.com Thu Sep 15 08:23:02 2011 Return-path: Envelope-to: www-data@lists.xensource.com Delivery-date: Thu, 15 Sep 2011 08:23:02 -0700 Received: from localhost ([127.0.0.1] helo=lists.colo.xensource.com) by lists.xensource.com with esmtp (Exim 4.43) id 1R4DmH-0000C1-Sn; Thu, 15 Sep 2011 08:23:01 -0700 Received: from mail27.messagelabs.com ([193.109.254.147]) by lists.xensource.com with esmtp (Exim 4.43) id 1R4DkA-00086b-Rj; Thu, 15 Sep 2011 08:20:51 -0700 X-Env-Sender: konrad@oracle.com X-Msg-Ref: server-9.tower-27.messagelabs.com!1316100030!44676553!1 X-Originating-IP: [148.87.113.117] X-StarScan-Version: 6.4.1; banners=-,-,- X-VirusChecked: Checked Received: (qmail 2856 invoked from network); 15 Sep 2011 15:20:31 -0000 Received: from rcsinet15.oracle.com (HELO rcsinet15.oracle.com) (148.87.113.117) by server-9.tower-27.messagelabs.com with DHE-RSA-AES256-SHA encrypted SMTP; 15 Sep 2011 15:20:31 -0000 Received: from rtcsinet22.oracle.com (rtcsinet22.oracle.com [66.248.204.30]) by rcsinet15.oracle.com (Switch-3.4.4/Switch-3.4.4) with ESMTP id p8FFKEba014012 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Thu, 15 Sep 2011 15:20:16 GMT Received: from acsmt358.oracle.com (acsmt358.oracle.com [141.146.40.158]) by rtcsinet22.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id p8FFKCwE022550 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 15 Sep 2011 15:20:13 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 p8FFK6Em006453; Thu, 15 Sep 2011 10:20:07 -0500 Received: from oracle.com (/209.6.55.207) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Thu, 15 Sep 2011 08:20:06 -0700 Received: by oracle.com (Postfix, from userid 1000) id 0FA1D1361; Thu, 15 Sep 2011 11:20:07 -0400 (EDT) Date: Thu, 15 Sep 2011 11:20:06 -0400 From: Konrad Rzeszutek Wilk To: jim burns Subject: Re: [Fedora-xen] [Xen-devel] Re: [Xen-users] Continuing BUG:-iness booting Fedora Rawhide 3.1.0-rc's (was Summary: Experiences setting up a debug serial port) Message-ID: <20110915152006.GB21135@phenom.oracle.com> References: <201107231426.56811.jim_burn@bellsouth.net> <20110914221254.GB3742@phenom.oracle.com> <1673553.kg3ZcTGbSX@dell4550> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <1673553.kg3ZcTGbSX@dell4550> User-Agent: Mutt/1.5.21 (2010-09-15) X-Source-IP: rtcsinet22.oracle.com [66.248.204.30] X-CT-RefId: str=0001.0A090206.4E7217B1.0130,ss=1,re=0.000,fgs=0 Cc: xen-devel@lists.xensource.com, Fedora Xen List , Ian Campbell , M A Young , todd.deshane@xen.org, xen-users@lists.xensource.com X-BeenThere: xen-devel@lists.xensource.com X-Mailman-Version: 2.1.5 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xensource.com Errors-To: xen-devel-bounces@lists.xensource.com On Wed, Sep 14, 2011 at 09:18:25PM -0400, jim burns wrote: > On Thu September 15 2011, 12:38:26 AM, M A Young wrote: > > I have a (temporary) F17 kernel with the patch from > > http://oss.oracle.com/git/kwilk/xen.git/?p=kwilk/xen.git;a=commit;h=a7079a64 > > 04ed2106315327fff6be3464d10814e7 (which I assume is the same patch) applied > > building at > > http://koji.fedoraproject.org/koji/taskinfo?taskID=3352367 > > if you want to test it. > > Oh - the patch is to the kernel, not to xen. I misread it. > > Ok - I downloaded > http://koji.fedoraproject.org/koji/getfile?taskID=3352368&name=kernel-3.1.0-0.rc6.git0.0.xendom0.fc17.x86_64.rpm > > I hope that's right. I'll try it tomorrow. Thanx. ping? _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel From xen-devel-bounces@lists.xensource.com Thu Sep 15 08:41:43 2011 Return-path: Envelope-to: www-data@lists.xensource.com Delivery-date: Thu, 15 Sep 2011 08:41:43 -0700 Received: from localhost ([127.0.0.1] helo=lists.colo.xensource.com) by lists.xensource.com with esmtp (Exim 4.43) id 1R4E4N-0002Rt-1h; Thu, 15 Sep 2011 08:41:43 -0700 Received: from mail174.messagelabs.com ([85.158.138.51]) by lists.xensource.com with esmtp (Exim 4.43) id 1R4E3l-0002Et-5K for xen-devel@lists.xensource.com; Thu, 15 Sep 2011 08:41:05 -0700 X-Env-Sender: Ian.Campbell@eu.citrix.com X-Msg-Ref: server-7.tower-174.messagelabs.com!1316101259!31534590!1 X-Originating-IP: [66.165.176.63] X-StarScan-Version: 6.4.1; banners=-,-,- X-VirusChecked: Checked Received: (qmail 8735 invoked from network); 15 Sep 2011 15:41:01 -0000 Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63) by server-7.tower-174.messagelabs.com with RC4-SHA encrypted SMTP; 15 Sep 2011 15:41:01 -0000 X-IronPort-AV: E=Sophos;i="4.68,387,1312171200"; d="scan'208";a="163408920" Received: from ftlpmailmx02.citrite.net ([10.13.107.66]) by FTLPIPO02.CITRIX.COM with ESMTP/TLS/RC4-MD5; 15 Sep 2011 11:40:58 -0400 Received: from [127.0.0.1] (10.80.16.67) by smtprelay.citrix.com (10.13.107.66) with Microsoft SMTP Server id 8.3.137.0; Thu, 15 Sep 2011 11:40:58 -0400 Subject: Re: [Xen-devel] [PATCH] libxl: add support for booting PV domains from NetBSD using raw files as disks. Fixed the shutdown race problem by checking "hotplug-status" instead of "state" xenstore variable in NetBSD From: Ian Campbell To: Roger Pau =?ISO-8859-1?Q?Monn=E9?= Date: Thu, 15 Sep 2011 17:40:56 +0200 In-Reply-To: References: <015617579cd36fc58318.1316091805@loki> <1316094117.26990.8.camel@cthulhu.hellion.org.uk> Organization: Citrix Systems, Inc. Content-Type: text/plain; charset="UTF-8" X-Mailer: Evolution 3.0.3- Content-Transfer-Encoding: 8bit Message-ID: <1316101258.26990.20.camel@cthulhu.hellion.org.uk> MIME-Version: 1.0 Cc: "xen-devel@lists.xensource.com" X-BeenThere: xen-devel@lists.xensource.com X-Mailman-Version: 2.1.5 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xensource.com Errors-To: xen-devel-bounces@lists.xensource.com On Thu, 2011-09-15 at 11:19 -0400, Roger Pau Monné wrote: > 2011/9/15 Ian Campbell : > > On Thu, 2011-09-15 at 09:03 -0400, Roger Pau Monne wrote: > >> # HG changeset patch > >> # User Roger Pau Monne > >> # Date 1316091721 -7200 > >> # Node ID 015617579cd36fc58318aaf350bec5f7cc07ef2f > >> # Parent 63e254468d6e8d81baeafaed68f05791dc21eb4e > >> libxl: add support for booting PV domains from NetBSD using raw files > >> as disks. Fixed the shutdown race problem by checking "hotplug-status" > >> instead of "state" xenstore variable in NetBSD. > > > > This was one long line which mercurial will use as a summary, it's a > > good idea to make sure that the first line stands somewhat alone as a > > summary so the e.g. "hg log" is useful. > > Also this sounds on the face of it like two bugfixes, if that's the case > > they should be submitted separately. > > Well, it's not a bugfix, because NetBSD was not supported by libxl, so > I think it's just part of the patch to add support for NetBSD to > libxl. I will split the line, and the patch if it's necessary, but one > doesn't make sense without the other, and I don't really know what > would be in each patch. I guess I saw "add support" and "fix race" and assumed they were separate (albeit related) changes. Ian. _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel From xen-devel-bounces@lists.xensource.com Thu Sep 15 08:47:30 2011 Return-path: Envelope-to: www-data@lists.xensource.com Delivery-date: Thu, 15 Sep 2011 08:47:30 -0700 Received: from localhost ([127.0.0.1] helo=lists.colo.xensource.com) by lists.xensource.com with esmtp (Exim 4.43) id 1R4E9y-0002v0-Q6; Thu, 15 Sep 2011 08:47:30 -0700 Received: from mail174.messagelabs.com ([85.158.138.51]) by lists.xensource.com with esmtp (Exim 4.43) id 1R4E9J-0002ia-Tb for xen-devel@lists.xensource.com; Thu, 15 Sep 2011 08:46:50 -0700 X-Env-Sender: konrad@oracle.com X-Msg-Ref: server-10.tower-174.messagelabs.com!1316101604!31550542!1 X-Originating-IP: [141.146.126.227] X-StarScan-Version: 6.4.1; banners=-,-,- X-VirusChecked: Checked Received: (qmail 23925 invoked from network); 15 Sep 2011 15:46:46 -0000 Received: from acsinet15.oracle.com (HELO acsinet15.oracle.com) (141.146.126.227) by server-10.tower-174.messagelabs.com with DHE-RSA-AES256-SHA encrypted SMTP; 15 Sep 2011 15:46:46 -0000 Received: from acsinet22.oracle.com (acsinet22.oracle.com [141.146.126.238]) by acsinet15.oracle.com (Switch-3.4.4/Switch-3.4.4) with ESMTP id p8FFkQqJ011476 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Thu, 15 Sep 2011 15:46:28 GMT Received: from acsmt357.oracle.com (acsmt357.oracle.com [141.146.40.157]) by acsinet22.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id p8FFkPjw023052 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 15 Sep 2011 15:46:26 GMT Received: from abhmt106.oracle.com (abhmt106.oracle.com [141.146.116.58]) by acsmt357.oracle.com (8.12.11.20060308/8.12.11) with ESMTP id p8FFkKoI021461; Thu, 15 Sep 2011 10:46:20 -0500 Received: from oracle.com (/209.6.55.207) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Thu, 15 Sep 2011 08:46:20 -0700 Received: by oracle.com (Postfix, from userid 1000) id 82A2D1361; Thu, 15 Sep 2011 11:46:21 -0400 (EDT) Date: Thu, 15 Sep 2011 11:46:21 -0400 From: Konrad Rzeszutek Wilk To: m.a.young@durham.ac.uk, xen-devel@lists.xensource.com Message-ID: <20110915154621.GA21580@phenom.oracle.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.5.21 (2010-09-15) X-Source-IP: acsinet22.oracle.com [141.146.126.238] X-Auth-Type: Internal IP X-CT-RefId: str=0001.0A090208.4E721DD4.00DE:SCFMA922111,ss=1,re=-4.000,fgs=0 Cc: Subject: [Xen-devel] F16, yum install xen, run grub2 or grubby as needed? X-BeenThere: xen-devel@lists.xensource.com X-Mailman-Version: 2.1.5 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xensource.com Errors-To: xen-devel-bounces@lists.xensource.com Hey Michael, I was playing today with https://admin.fedoraproject.org/updates/grubby-8.2-1.fc16?_csrf_token=014c2b18c3b6e843699e9ef1e56cf9726c5c4fc2 and https://admin.fedoraproject.org/updates/grub2-1.99-6.fc16 which make the grub.cfg have the correct entries of Xen and Linux. And realized that I had to manually do: grub2-mkconfig > /boot/grub2/grub.cfg which ends up doing the new stanza.. but in some sense I think it makes senee for the Xen script to actually call this. Thoughts? _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel From xen-devel-bounces@lists.xensource.com Thu Sep 15 09:25:44 2011 Return-path: Envelope-to: www-data@lists.xensource.com Delivery-date: Thu, 15 Sep 2011 09:25:44 -0700 Received: from localhost ([127.0.0.1] helo=lists.colo.xensource.com) by lists.xensource.com with esmtp (Exim 4.43) id 1R4Eky-0003zf-7G; Thu, 15 Sep 2011 09:25:44 -0700 Received: from mail27.messagelabs.com ([193.109.254.147]) by lists.xensource.com with esmtp (Exim 4.43) id 1R4Ek7-0003l4-H5 for xen-devel@lists.xensource.com; Thu, 15 Sep 2011 09:24:52 -0700 X-Env-Sender: jeremy@goop.org X-Msg-Ref: server-11.tower-27.messagelabs.com!1316103879!37579154!1 X-Originating-IP: [74.207.240.146] X-StarScan-Version: 6.4.1; banners=-,-,- X-VirusChecked: Checked Received: (qmail 13657 invoked from network); 15 Sep 2011 16:24:40 -0000 Received: from claw.goop.org (HELO claw.goop.org) (74.207.240.146) by server-11.tower-27.messagelabs.com with DHE-RSA-AES256-SHA encrypted SMTP; 15 Sep 2011 16:24:40 -0000 Received: from saboo.goop.org (unknown [IPv6:2001:470:1f05:899:f2de:f1ff:fe5c:34ed]) (Authenticated sender: smtp-saboo) by claw.goop.org (Postfix) with ESMTPSA id BA0959B49; Thu, 15 Sep 2011 09:24:44 -0700 (PDT) Received: from saboo.goop.org (localhost [IPv6:::1]) by saboo.goop.org (Postfix) with ESMTP id F0B7E202E4; Thu, 15 Sep 2011 09:24:43 -0700 (PDT) Message-ID: <4E7226CB.2020706@goop.org> Date: Thu, 15 Sep 2011 09:24:43 -0700 From: Jeremy Fitzhardinge User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:6.0.2) Gecko/20110906 Thunderbird/6.0.2 MIME-Version: 1.0 To: Konrad Rzeszutek Wilk Subject: Re: [Xen-devel] Xen 4 TSC problems References: <4E6F034B.5040102@bluewin.ch> <20110915082402.GC24888@phenom.oracle.com> In-Reply-To: <20110915082402.GC24888@phenom.oracle.com> X-Enigmail-Version: 1.3.1 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: xen-devel@lists.xensource.com, Philippe Simonet X-BeenThere: xen-devel@lists.xensource.com X-Mailman-Version: 2.1.5 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xensource.com Errors-To: xen-devel-bounces@lists.xensource.com On 09/15/2011 01:24 AM, Konrad Rzeszutek Wilk wrote: > On Tue, Sep 13, 2011 at 09:16:27AM +0200, Philippe Simonet wrote: >> Hi Xen developers > Lets try this again, this time Cc-ing Jeremy. >> i just would like to inform you that I have exactly the same problem >> with Debian squeeze and xen, with >> 50 seconds time jump on my dom0 and domu. NTP is running on all >> dom0/domuU, clocksource is 'xen' >> everywhere. >> >> some messages : >> syslog : >> Sep 11 13:56:50 dnsit22 kernel: [571603.359863] Clocksource tsc >> unstable (delta = -2999662111513 ns) >> >> xm dmesg : >> ... >> (XEN) Platform timer is 14.318MHz HPET >> ... >> (XEN) Platform timer appears to have unexpectedly wrapped 10 or more times. >> (XEN) TSC marked as reliable, warp = 0 (count=2) >> ... >> >> I had some contact with Olivier Hanesse and it indicates that he >> doesn't have any solution for this problem, >> and all what was proposed in February didn't solved this problem. That looks like Xen itself is having problems keeping track of time. If it can't manage it, then there's not much the guest kernels can do about it. > > Which was the max_cstate=0 ? > .. >> config : >> -------------------------------------- >> Linux dnsit22.swissptt.ch 2.6.32-5-xen-amd64 #1 SMP Tue Jun 14 >> 12:46:30 UTC 2011 x86_64 GNU/Linux >> -------------------------------------- >> HP DL385 >> -------------------------------------- >> vendor_id : AuthenticAMD >> cpu family : 16 >> model : 9 >> model name : AMD Opteron(tm) Processor 6174 >> stepping : 1 >> cpu MHz : 3058776.574 > OK, that is really messed up. Your house must be on fire for the machine > to be running at 3058GHz! > > Jeremy, this sounds familiar - did we have a patch for this in > your 2.6.32 tree? Not that I can think of. All I can suggest from the kernel side is that perhaps some of the ACPI power stuff isn't being set up properly, and that makes the CPU do very strange things with its TSC/power states in general. J _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel From xen-devel-bounces@lists.xensource.com Thu Sep 15 09:57:45 2011 Return-path: Envelope-to: www-data@lists.xensource.com Delivery-date: Thu, 15 Sep 2011 09:57:45 -0700 Received: from localhost ([127.0.0.1] helo=lists.colo.xensource.com) by lists.xensource.com with esmtp (Exim 4.43) id 1R4FFw-00050u-FB; Thu, 15 Sep 2011 09:57:45 -0700 Received: from mail182.messagelabs.com ([85.158.139.83]) by lists.xensource.com with esmtp (Exim 4.43) id 1R4FEt-0004nT-74 for xen-devel@lists.xensource.com; Thu, 15 Sep 2011 09:56:39 -0700 X-Env-Sender: fantonifabio@tiscali.it X-Msg-Ref: server-12.tower-182.messagelabs.com!1316105794!18342827!1 X-Originating-IP: [216.139.236.26] X-StarScan-Version: 6.4.1; banners=-,-,- X-VirusChecked: Checked Received: (qmail 3776 invoked from network); 15 Sep 2011 16:56:36 -0000 Received: from sam.nabble.com (HELO sam.nabble.com) (216.139.236.26) by server-12.tower-182.messagelabs.com with AES256-SHA encrypted SMTP; 15 Sep 2011 16:56:36 -0000 Received: from [192.168.236.26] (helo=sam.nabble.com) by sam.nabble.com with esmtp (Exim 4.72) (envelope-from ) id 1R4FEo-0005p4-0Y for xen-devel@lists.xensource.com; Thu, 15 Sep 2011 09:56:34 -0700 Date: Thu, 15 Sep 2011 09:56:34 -0700 (PDT) From: Fantu To: xen-devel@lists.xensource.com Message-ID: <1316105794010-4807540.post@n5.nabble.com> In-Reply-To: <20110915145840.GA20726@phenom.oracle.com> References: <1316011454156-4803078.post@n5.nabble.com> <20110914145403.GA17899@phenom.oracle.com> <1316097409687-4807062.post@n5.nabble.com> <20110915145840.GA20726@phenom.oracle.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Subject: [Xen-devel] Re: Out sw-iommu space problem X-BeenThere: xen-devel@lists.xensource.com X-Mailman-Version: 2.1.5 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xensource.com Errors-To: xen-devel-bounces@lists.xensource.com Thanks, someone know if this fix is included in next debian kernel build? ( http://packages.qa.debian.org/l/linux-2.6/news/20110913T200325Z.html ) kernel.org is down and i can't see the changelog, for example http://www.kernel.org/pub/linux/kernel/v2.6/longterm/v2.6.32/ChangeLog-2.6.32.46 -- View this message in context: http://xen.1045712.n5.nabble.com/Out-sw-iommu-space-problem-tp4803078p4807540.html Sent from the Xen - Dev mailing list archive at Nabble.com. _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel From xen-devel-bounces@lists.xensource.com Thu Sep 15 10:19:17 2011 Return-path: Envelope-to: www-data@lists.xensource.com Delivery-date: Thu, 15 Sep 2011 10:19:17 -0700 Received: from localhost ([127.0.0.1] helo=lists.colo.xensource.com) by lists.xensource.com with esmtp (Exim 4.43) id 1R4Fan-0006VR-E6; Thu, 15 Sep 2011 10:19:17 -0700 Received: from mail216.messagelabs.com ([85.158.143.99]) by lists.xensource.com with esmtp (Exim 4.43) id 1R4FZp-0006Ie-JE; Thu, 15 Sep 2011 10:18:18 -0700 X-Env-Sender: hwang.jinho@gmail.com X-Msg-Ref: server-2.tower-216.messagelabs.com!1316107090!18414682!1 X-Originating-IP: [209.85.160.171] X-StarScan-Version: 6.4.1; banners=-,-,- X-VirusChecked: Checked Received: (qmail 22445 invoked from network); 15 Sep 2011 17:18:11 -0000 Received: from mail-gy0-f171.google.com (HELO mail-gy0-f171.google.com) (209.85.160.171) by server-2.tower-216.messagelabs.com with RC4-SHA encrypted SMTP; 15 Sep 2011 17:18:11 -0000 Received: by gyh3 with SMTP id 3so3328801gyh.30 for ; Thu, 15 Sep 2011 10:18:10 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=tzjRBH8ZT5i66xYiDiCxVXKhyBQT8Ps2IttSql5Z9i8=; b=U7McR8EGbPXSqhPAK4fFbII7ps19oTcHNuL8tQG/Hug9SgJyz0WUFl4SgDKushPbap kQWoeZplXPpCNXQPZZP8P3OaTPZfPQ2pEnoG7Wnt4VEcjcVILejzAYoBhr4KUZfsRPA5 P77QDrWpdtOL+dCzchIwgHop+gqgWzxhByxHA= Received: by 10.151.100.21 with SMTP id c21mr1553552ybm.348.1316107090225; Thu, 15 Sep 2011 10:18:10 -0700 (PDT) MIME-Version: 1.0 Received: by 10.151.154.16 with HTTP; Thu, 15 Sep 2011 10:17:50 -0700 (PDT) In-Reply-To: <20110915080121.GB4396@phenom.oracle.com> References: <20110915080121.GB4396@phenom.oracle.com> From: jinho hwang Date: Thu, 15 Sep 2011 13:17:50 -0400 Message-ID: Subject: Re: [Xen-devel] [Xen-users] XENBUS waiting timeout To: Konrad Rzeszutek Wilk Cc: xen-devel@lists.xensource.com, xen-users@lists.xensource.com X-BeenThere: xen-devel@lists.xensource.com X-Mailman-Version: 2.1.5 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0219853376==" Sender: xen-devel-bounces@lists.xensource.com Errors-To: xen-devel-bounces@lists.xensource.com --===============0219853376== Content-Type: multipart/alternative; boundary=000e0cd6cece996d1904acfe0f97 --000e0cd6cece996d1904acfe0f97 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable I'm using Xen 4.0.3 and linux 2.6.32.46 for dom0 and domU as well. From xenstore-ls, I could see the numbers you mentioned 51713 and 51714 for my guest, but the log says that the devices for the numbers are not detected a= s follows: *This is from console after I execute "sudo xm create -c ":* Using config file "./XenGuest1.cfg". Started domain XenGuest1 (id=3D1) Reserving virtual address space above 0xf5800000 Initializing cgroup subsys cpuset Initializing cgroup subsys cpu Linux version 2.6.32.46 (root@jinho-Dell-DXP061) (gcc version 4.5.2 (Ubuntu/Linaro 4.5.2-8ubuntu4) ) #4 SMP Wed Sep 14 18:30:41 EDT 2011 KERNEL supported cpus: Intel GenuineIntel AMD AuthenticAMD NSC Geode by NSC Cyrix CyrixInstead Centaur CentaurHauls Transmeta GenuineTMx86 Transmeta TransmetaCPU UMC UMC UMC UMC ACPI in unprivileged domain disabled released 0 pages of unused memory BIOS-provided physical RAM map: Xen: 0000000000000000 - 00000000000a0000 (usable) Xen: 00000000000a0000 - 0000000000100000 (reserved) Xen: 0000000000100000 - 0000000020800000 (usable) DMI not present or invalid. last_pfn =3D 0x20800 max_arch_pfn =3D 0x1000000 init_memory_mapping: 0000000000000000-0000000020800000 NX (Execute Disable) protection: active RAMDISK: 00b00000 - 0bab5000 0MB HIGHMEM available. 520MB LOWMEM available. mapped low ram: 0 - 20800000 low ram: 0 - 20800000 node 0 low ram: 00000000 - 20800000 node 0 bootmap 00007000 - 0000b100 (11 early reservations) =3D=3D> bootmem [0000000000 - 0020800000] #0 [0000000000 - 0000001000] BIOS data page =3D=3D> [0000000000 - 0000001000] #1 [000bb38000 - 000bb9a000] XEN PAGETABLES =3D=3D> [000bb38000 - 000bb9a000] #2 [0000001000 - 0000002000] EX TRAMPOLINE =3D=3D> [0000001000 - 0000002000] #3 [0000006000 - 0000007000] TRAMPOLINE =3D=3D> [0000006000 - 0000007000] #4 [0000400000 - 000098f1b4] TEXT DATA BSS =3D=3D> [0000400000 - 000098f1b4] #5 [0000b00000 - 000bab5000] RAMDISK =3D=3D> [0000b00000 - 000bab5000] #6 [000bab5000 - 000bb38000] XEN START INFO =3D=3D> [000bab5000 - 000bb38000] #7 [0020000000 - 0020800000] XEN EXTRA =3D=3D> [0020000000 - 0020800000] #8 [0000990000 - 000099d000] BRK =3D=3D> [0000990000 - 000099d000] #9 [0000100000 - 00001a1000] PGTABLE =3D=3D> [0000100000 - 00001a1000] #10 [0000007000 - 000000c000] BOOTMAP =3D=3D> [0000007000 - 000000c000] Zone PFN ranges: DMA 0x00000000 -> 0x00001000 Normal 0x00001000 -> 0x00020800 HighMem 0x00020800 -> 0x00020800 Movable zone start PFN for each node early_node_map[2] active PFN ranges 0: 0x00000000 -> 0x000000a0 0: 0x00000100 -> 0x00020800 Using APIC driver default SMP: Allowing 1 CPUs, 0 hotplug CPUs Local APIC disabled by BIOS -- you can enable it with "lapic" APIC: disable apic facility Allocating PCI resources starting at 20800000 (gap: 20800000:df800000) Booting paravirtualized kernel on Xen Xen version: 4.0.3-rc3-pre (preserve-AD) NR_CPUS:8 nr_cpumask_bits:8 nr_cpu_ids:1 nr_node_ids:1 PERCPU: Embedded 16 pages/cpu @cbfaf000 s42264 r0 d23272 u65536 pcpu-alloc: s42264 r0 d23272 u65536 alloc=3D16*4096 pcpu-alloc: [0] 0 Built 1 zonelists in Zone order, mobility grouping on. Total pages: 131984 Kernel command line: root=3D/dev/xvda1 ro ip=3D:127.0.255.255::::eth0:dhcp = 4 PID hash table entries: 4096 (order: 2, 16384 bytes) Dentry cache hash table entries: 131072 (order: 7, 524288 bytes) Inode-cache hash table entries: 65536 (order: 6, 262144 bytes) Enabling fast FPU save and restore... done. Enabling unmasked SIMD FPU exception support... done. Initializing CPU#0 Initializing HighMem for node 0 (00000000:00000000) Memory: 331500k/532480k available (2980k kernel code, 200480k reserved, 1684k data, 432k init, 0k highmem) virtual kernel memory layout: fixmap : 0xf567e000 - 0xf57ff000 (1540 kB) pkmap : 0xf5200000 - 0xf5400000 (2048 kB) vmalloc : 0xe1000000 - 0xf51fe000 ( 321 MB) lowmem : 0xc0000000 - 0xe0800000 ( 520 MB) .init : 0xc088f000 - 0xc08fb000 ( 432 kB) .data : 0xc06e90b5 - 0xc088e140 (1684 kB) .text : 0xc0400000 - 0xc06e90b5 (2980 kB) SLUB: Genslabs=3D13, HWalign=3D64, Order=3D0-3, MinObjects=3D0, CPUs=3D1, N= odes=3D1 Hierarchical RCU implementation. NR_IRQS:2304 nr_irqs:512 Console: colour dummy device 80x25 console [tty0] enabled console [hvc0] enabled installing Xen timer for CPU 0 Detected 2660.066 MHz processor. Calibrating delay loop (skipped), value calculated using timer frequency.. 5320.13 BogoMIPS (lpj=3D2660066) Security Framework initialized SELinux: Initializing. Mount-cache hash table entries: 512 Initializing cgroup subsys ns Initializing cgroup subsys cpuacct Initializing cgroup subsys devices CPU: L1 I cache: 32K, L1 D cache: 32K CPU: L2 cache: 4096K CPU: Unsupported number of siblings 2 Performance Events: unsupported p6 CPU model 15 no PMU driver, software events only. SMP alternatives: switching to UP code Freeing SMP alternatives: 7k freed cpu 0 spinlock event irq 510 Brought up 1 CPUs Grant table initialized Time: 165:165:165 Date: 165/165/65 NET: Registered protocol family 16 PCI: setting up Xen PCI frontend stub bio: create slab at 0 ACPI: Interpreter disabled. xen_balloon: Initialising balloon driver with page order 0. last_pfn =3D 0x20800 max_arch_pfn =3D 0x1000000 vgaarb: loaded SCSI subsystem initialized usbcore: registered new interface driver usbfs usbcore: registered new interface driver hub usbcore: registered new device driver usb PCI: System does not support PCI PCI: System does not support PCI NetLabel: Initializing NetLabel: domain hash size =3D 128 NetLabel: protocols =3D UNLABELED CIPSOv4 NetLabel: unlabeled traffic allowed by default Switching to clocksource xen pnp: PnP ACPI: disabled NET: Registered protocol family 2 IP route cache hash table entries: 8192 (order: 3, 32768 bytes) TCP established hash table entries: 32768 (order: 6, 262144 bytes) TCP bind hash table entries: 32768 (order: 6, 262144 bytes) TCP: Hash tables configured (established 32768 bind 32768) TCP reno registered NET: Registered protocol family 1 Trying to unpack rootfs image as initramfs... Freeing initrd memory: 179924k freed platform rtc_cmos: registered platform RTC device (no PNP device found) apm: BIOS not found. audit: initializing netlink socket (disabled) type=3D2000 audit(1316106566.034:1): initialized HugeTLB registered 2 MB page size, pre-allocated 0 pages VFS: Disk quotas dquot_6.5.2 Dquot-cache hash table entries: 1024 (order 0, 4096 bytes) msgmni has been set to 999 alg: No test for stdrng (krng) Block layer SCSI generic (bsg) driver version 0.4 loaded (major 252) io scheduler noop registered io scheduler anticipatory registered io scheduler deadline registered io scheduler cfq registered (default) pci_hotplug: PCI Hot Plug PCI Core version: 0.5 acpiphp: ACPI Hot Plug PCI Controller Driver version: 0.5 isapnp: ISA Plug & Play support disabled Event-channel device installed. registering netback Non-volatile memory driver v1.3 Linux agpgart interface v0.103 Serial: 8250/16550 driver, 4 ports, IRQ sharing enabled brd: module loaded loop: module loaded Initialising Xen virtual ethernet driver. ehci_hcd: USB 2.0 'Enhanced' Host Controller (EHCI) Driver ohci_hcd: USB 1.1 'Open' Host Controller (OHCI) Driver uhci_hcd: USB Universal Host Controller Interface driver PNP: No PS/2 controller found. Probing ports directly. i8042.c: No controller found. mice: PS/2 mouse device common for all mice rtc_cmos rtc_cmos: rtc core: registered rtc_cmos as rtc0 device-mapper: uevent: version 1.0.3 device-mapper: ioctl: 4.15.0-ioctl (2009-04-01) initialised: dm-devel@redhat.com cpuidle: using governor ladder cpuidle: using governor menu usbcore: registered new interface driver hiddev usbcore: registered new interface driver usbhid usbhid: v2.6:USB HID core driver nf_conntrack version 0.5.0 (8192 buckets, 32768 max) CONFIG_NF_CT_ACCT is deprecated and will be removed soon. Please use nf_conntrack.acct=3D1 kernel parameter, acct=3D1 nf_conntrack module option= or sysctl net.netfilter.nf_conntrack_acct=3D1 to enable it. ip_tables: (C) 2000-2006 Netfilter Core Team TCP cubic registered Initializing XFRM netlink socket NET: Registered protocol family 17 Using IPI No-Shortcut mode registered taskstats version 1 XENBUS: Waiting for devices to initialise: 295s...290s...285s...280s...275s...270s...265s...260s...255s...250s...245s.= ..240s...235s...230s...225s...220s...215s...210s...205s...200s...195s...190= s...185s...180s...175s...170s...165s...160s...155s...150s...145s...140s...1= 35s...130s...125s...120s...115s...110s...105s...100s...95s...90s...85s...80= s...75s...70s...65s...60s...55s...50s...45s...40s...35s...30s...25s...20s..= .15s...10s...5s...0s... XENBUS: Timeout connecting to device: device/vbd/51713 (local state 3, remote state 1) XENBUS: Timeout connecting to device: device/vbd/51714 (local state 3, remote state 1) XENBUS: Device with no driver: device/console/0 Magic number: 1:252:3141 Freeing unused kernel memory: 432k freed Write protecting the kernel text: 2984k Write protecting the kernel read-only data: 1452k Loading, please wait... mount: mounting none on /dev failed: No such device W: devtmpfs not available, falling back to tmpfs for /dev hrtimer: interrupt took 6765654 ns Begin: Loading essential drivers ... done. Begin: Running /scripts/init-premount ... done. Begin: Mounting root file system ... Begin: Running /scripts/local-top ... done. Gave up waiting for root device. Common problems: - Boot args (cat /proc/cmdline) - Check rootdelay=3D (did the system wait long enough?) - Check root=3D (did the system wait for the right device?) - Missing modules (cat /proc/modules; ls /dev) ALERT! /dev/xvda1 does not exist. Dropping to a shell! *Here is my xenstore-ls:* tool =3D "" xenstored =3D "" vm =3D "" 00000000-0000-0000-0000-000000000000 =3D "" on_xend_stop =3D "ignore" shadow_memory =3D "0" uuid =3D "00000000-0000-0000-0000-000000000000" on_reboot =3D "restart" image =3D "(linux (kernel ) (superpages 0) (nomigrate 0) (tsc_mode 0))" ostype =3D "linux" kernel =3D "" cmdline =3D "" ramdisk =3D "" on_poweroff =3D "destroy" bootloader_args =3D "" on_xend_start =3D "ignore" on_crash =3D "restart" xend =3D "" restart_count =3D "0" vcpus =3D "2" vcpu_avail =3D "3" bootloader =3D "" name =3D "Domain-0" 0c879418-b8df-eed2-53a2-05dd9d768284 =3D "" image =3D "(linux (kernel /boot/vmlinuz-2.6.32.46) (ramdisk /boot/initrd.img-2.6.32.46) (args 'root=3D/dev/xvda1 ro ip=3D:127.0.255.255= : :::eth0:dhcp\..." ostype =3D "linux" kernel =3D "/boot/vmlinuz-2.6.32.46" cmdline =3D "root=3D/dev/xvda1 ro ip=3D:127.0.255.255::::eth0:dhcp 4" ramdisk =3D "/boot/initrd.img-2.6.32.46" device =3D "" tap =3D "" 51713 =3D "" frontend =3D "/local/domain/1/device/vbd/51713" frontend-id =3D "1" backend-id =3D "0" backend =3D "/local/domain/0/backend/tap/1/51713" 51714 =3D "" frontend =3D "/local/domain/1/device/vbd/51714" frontend-id =3D "1" backend-id =3D "0" backend =3D "/local/domain/0/backend/tap/1/51714" vif =3D "" 0 =3D "" frontend =3D "/local/domain/1/device/vif/0" frontend-id =3D "1" backend-id =3D "0" backend =3D "/local/domain/0/backend/vif/1/0" console =3D "" 0 =3D "" frontend =3D "/local/domain/1/device/console/0" frontend-id =3D "1" backend-id =3D "0" backend =3D "/local/domain/0/backend/console/1/0" on_xend_stop =3D "ignore" shadow_memory =3D "0" uuid =3D "0c879418-b8df-eed2-53a2-05dd9d768284" on_reboot =3D "restart" start_time =3D "1316106563.89" on_poweroff =3D "destroy" bootloader_args =3D "" on_xend_start =3D "ignore" on_crash =3D "restart" xend =3D "" restart_count =3D "0" vcpus =3D "1" vcpu_avail =3D "1" bootloader =3D "" name =3D "XenGuest1" local =3D "" domain =3D "" 0 =3D "" vm =3D "/vm/00000000-0000-0000-0000-000000000000" device =3D "" control =3D "" platform-feature-multiprocessor-suspend =3D "1" error =3D "" memory =3D "" target =3D "3407872" guest =3D "" hvmpv =3D "" data =3D "" cpu =3D "" 1 =3D "" availability =3D "online" 0 =3D "" availability =3D "online" description =3D "" console =3D "" limit =3D "1048576" type =3D "xenconsoled" domid =3D "0" name =3D "Domain-0" backend =3D "" tap =3D "" 1 =3D "" 51713 =3D "" domain =3D "XenGuest1" frontend =3D "/local/domain/1/device/vbd/51713" uuid =3D "88476a24-fe5c-cc91-bc87-cbe07b5bd2a3" bootable =3D "1" dev =3D "xvda1" state =3D "1" params =3D "aio:/xen/XenGuest1.img" mode =3D "w" online =3D "1" frontend-id =3D "1" type =3D "tap" hotplug-status =3D "connected" 51714 =3D "" domain =3D "XenGuest1" frontend =3D "/local/domain/1/device/vbd/51714" uuid =3D "e574dca6-2710-f8ed-4cb6-983421c415d6" bootable =3D "0" dev =3D "xvda2" state =3D "1" params =3D "aio:/xen/XenGuest1.swap" mode =3D "w" online =3D "1" frontend-id =3D "1" type =3D "tap" hotplug-status =3D "connected" vif =3D "" 1 =3D "" 0 =3D "" domain =3D "XenGuest1" handle =3D "0" uuid =3D "a916031e-38be-f70a-89f3-47d2cb9a16f8" script =3D "/etc/xen/scripts/vif-bridge" state =3D "4" frontend =3D "/local/domain/1/device/vif/0" mac =3D "00:16:3e:41:3f:05" online =3D "1" frontend-id =3D "1" feature-sg =3D "1" feature-gso-tcpv4 =3D "1" feature-rx-copy =3D "1" feature-rx-flip =3D "0" feature-smart-poll =3D "1" hotplug-status =3D "connected" console =3D "" 1 =3D "" 0 =3D "" domain =3D "XenGuest1" protocol =3D "vt100" uuid =3D "6358d1af-79ef-8334-fc5e-8861cb582a66" frontend =3D "/local/domain/1/device/console/0" state =3D "1" location =3D "2" online =3D "1" frontend-id =3D "1" 1 =3D "" vm =3D "/vm/0c879418-b8df-eed2-53a2-05dd9d768284" device =3D "" vbd =3D "" 51713 =3D "" virtual-device =3D "51713" device-type =3D "disk" protocol =3D "x86_32-abi" backend-id =3D "0" state =3D "3" backend =3D "/local/domain/0/backend/tap/1/51713" ring-ref =3D "8" event-channel =3D "9" 51714 =3D "" virtual-device =3D "51714" device-type =3D "disk" protocol =3D "x86_32-abi" backend-id =3D "0" state =3D "3" backend =3D "/local/domain/0/backend/tap/1/51714" ring-ref =3D "9" event-channel =3D "10" vif =3D "" 0 =3D "" mac =3D "00:16:3e:41:3f:05" handle =3D "0" protocol =3D "x86_32-abi" backend-id =3D "0" state =3D "4" backend =3D "/local/domain/0/backend/vif/1/0" tx-ring-ref =3D "768" rx-ring-ref =3D "769" event-channel =3D "11" request-rx-copy =3D "1" feature-rx-notify =3D "1" feature-sg =3D "1" feature-gso-tcpv4 =3D "1" feature-smart-poll =3D "0" console =3D "" 0 =3D "" protocol =3D "x86_32-abi" state =3D "1" backend-id =3D "0" backend =3D "/local/domain/0/backend/console/1/0" control =3D "" platform-feature-multiprocessor-suspend =3D "1" error =3D "" memory =3D "" target =3D "524288" guest =3D "" hvmpv =3D "" data =3D "" device-misc =3D "" vif =3D "" nextDeviceID =3D "1" console =3D "" nextDeviceID =3D "1" console =3D "" ring-ref =3D "475120" port =3D "2" limit =3D "1048576" type =3D "xenconsoled" tty =3D "/dev/pts/1" image =3D "" entry =3D "3230199808" loader =3D "generic" hv-start-low =3D "4118806528" guest-os =3D "linux" hypercall-page =3D "3225427968" guest-version =3D "2.6" pae-mode =3D "yes" paddr-offset =3D "0" virt-base =3D "3221225472" suspend-cancel =3D "1" features =3D "" pae-pgdir-above-4gb =3D "1" writable-page-tables =3D "0" xen-version =3D "xen-3.0" store =3D "" ring-ref =3D "475121" port =3D "1" description =3D "" cpu =3D "" 0 =3D "" availability =3D "online" name =3D "XenGuest1" domid =3D "1" serial =3D "" 0 =3D "" tty =3D "/dev/pts/1" On Thu, Sep 15, 2011 at 4:01 AM, Konrad Rzeszutek Wilk < konrad.wilk@oracle.com> wrote: > On Thu, Sep 15, 2011 at 02:02:25AM -0400, jinho hwang wrote: > > Hi, > > > > I have used disk image to copy host fs to image file and boot a guest > > system. But, the system is dropped to shell and it also says that it > can't > > You need to give more details. What is the version of your Dom0? > Is there anything showing up in the Dom0 kernel when this fails? > > Can you also include your xenstore-ls when this failure happens? You shou= ld > see an entry for 51713 and 51714.. > > > find /dev/xvda1 which is the root fs. I have defined it in the > configuration > > file as follows: > > > > disk =3D [ 'tap:aio:/xen/XenGuest1.img,xvda1,w', > > 'tap:aio:/xen/XenGuest1.swap,xvda2,w' ] > > root =3D "/dev/xvda1 ro" > > > > Also, modified the fstab as follows: > > > > /dev/xvda1 / ext3 defaults 1 1 > > /dev/xvda2 none swap sw 0 0 > > none /dev/pts devpts gid=3D5,mode=3D620 0 = 0 > > none /dev/shm tmpfs defaults 0 0 > > none /proc proc defaults 0 0 > > none /sys sysfs defaults 0 0 > > > > The following is the error shown in the console. > > > > Using IPI No-Shortcut mode > > registered taskstats version 1 > > XENBUS: Waiting for devices to initialise: > > > 295s...290s...285s...280s...275s...270s...265s...260s...255s...250s...245= s...240s...235s...230s...225s...220s...215s...210s...205s...200s...195s...1= 90s...185s...180s...175s...170s...165s...160s...155s...150s...145s...140s..= .135s...130s...125s...120s...115s...110s...105s...100s...95s...90s...85s...= 80s...75s...70s...65s...60s...55s...50s...45s...40s...35s...30s...25s...20s= ...15s...10s...5s...0s... > > XENBUS: Timeout connecting to device: device/vbd/51713 (local state 3, > > remote state 1) > > XENBUS: Timeout connecting to device: device/vbd/51714 (local state 3, > > remote state 1) > > XENBUS: Device with no driver: device/console/0 > > Magic number: 1:252:3141 > > Freeing unused kernel memory: 432k freed > > Write protecting the kernel text: 2984k > > Write protecting the kernel read-only data: 1452k > > Loading, please wait... > > mount: mounting none on /dev failed: No such device > > W: devtmpfs not available, falling back to tmpfs for /dev > > Begin: Loading essential drivers ... done. > > Begin: Running /scripts/init-premount ... done. > > Begin: Mounting root file system ... Begin: Running /scripts/local-top > ... > > done. > > Gave up waiting for root device. Common problems: > > - Boot args (cat /proc/cmdline) > > - Check rootdelay=3D (did the system wait long enough?) > > - Check root=3D (did the system wait for the right device?) > > - Missing modules (cat /proc/modules; ls /dev) > > ALERT! /dev/xvda1 does not exist. Dropping to a shell! > > > > If anybody has any idea, please let me know. > > > > Thank you, > > > > Jinho > > > > -- > > Jinho Hwang > > PhD Student > > Department of Computer Science > > The George Washington University > > Washington, DC 20052 > > hwang.jinho@gmail.com (email) > > 276.336.0971 (Cell) > > 202.994.4875 (fax) > > 070.8285.6546 (myLg070) > > > _______________________________________________ > > Xen-devel mailing list > > Xen-devel@lists.xensource.com > > http://lists.xensource.com/xen-devel > > --=20 Jinho Hwang PhD Student Department of Computer Science The George Washington University Washington, DC 20052 hwang.jinho@gmail.com (email) 276.336.0971 (Cell) 202.994.4875 (fax) 070.8285.6546 (myLg070) --000e0cd6cece996d1904acfe0f97 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable

I'm using Xen 4.0.3 and linux 2.6.32.46 for dom0 and dom= U as well. From xenstore-ls, I could see the numbers you mentioned 51713 an= d 51714 for my guest, but the log says that the devices for the numbers are= not detected as follows:


This is from console after I execute "sudo xm create -c <config&g= t;":
Using config file "./XenGuest1.cfg"= ;.
Started domain XenGuest1 (id=3D1)
=A0 =A0 =A0 =A0 =A0 = =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0Reserving virtual address space = above 0xf5800000
Initializing cgroup subsys cpuset
Init= ializing cgroup subsys cpu
Linux version 2.6.32.46 (root@jinho-Dell-DXP061) (gcc version 4.5.2 (U= buntu/Linaro 4.5.2-8ubuntu4) ) #4 SMP Wed Sep 14 18:30:41 EDT 2011
KERNEL supported cpus:
=A0 Intel GenuineIntel
=A0 AMD= AuthenticAMD
=A0 NSC Geode by NSC
=A0 Cyrix CyrixInstead
=A0 Ce= ntaur CentaurHauls
=A0 Transmeta GenuineTMx86
=A0 Trans= meta TransmetaCPU
=A0 UMC UMC UMC UMC
ACPI in unprivile= ged domain disabled
released 0 pages of unused memory
BIOS-provided physical RAM= map:
=A0Xen: 0000000000000000 - 00000000000a0000 (usable)
<= div>=A0Xen: 00000000000a0000 - 0000000000100000 (reserved)
=A0Xen= : 0000000000100000 - 0000000020800000 (usable)
DMI not present or invalid.
last_pfn =3D 0x20800 max_arch_pf= n =3D 0x1000000
init_memory_mapping: 0000000000000000-00000000208= 00000
NX (Execute Disable) protection: active
RAMDISK: = 00b00000 - 0bab5000
0MB HIGHMEM available.
520MB LOWMEM available.
=A0= mapped low ram: 0 - 20800000
=A0 low ram: 0 - 20800000
=A0 node 0 low ram: 00000000 - 20800000
=A0 node 0 bootmap 00007= 000 - 0000b100
(11 early reservations) =3D=3D> bootmem [0000000000 - 0020800000]
=A0 #0 [0000000000 - 0000001000] =A0 BIOS data page =3D=3D> [00= 00000000 - 0000001000]
=A0 #1 [000bb38000 - 000bb9a000] =A0 XEN P= AGETABLES =3D=3D> [000bb38000 - 000bb9a000]
=A0 #2 [0000001000 - 0000002000] =A0 =A0EX TRAMPOLINE =3D=3D> [0000= 001000 - 0000002000]
=A0 #3 [0000006000 - 0000007000] =A0 =A0 =A0= TRAMPOLINE =3D=3D> [0000006000 - 0000007000]
=A0 #4 [00004000= 00 - 000098f1b4] =A0 =A0TEXT DATA BSS =3D=3D> [0000400000 - 000098f1b4]<= /div>
=A0 #5 [0000b00000 - 000bab5000] =A0 =A0 =A0 =A0 =A0RAMDISK =3D=3D>= [0000b00000 - 000bab5000]
=A0 #6 [000bab5000 - 000bb38000] =A0 X= EN START INFO =3D=3D> [000bab5000 - 000bb38000]
=A0 #7 [002000= 0000 - 0020800000] =A0 =A0 =A0 =A0XEN EXTRA =3D=3D> [0020000000 - 002080= 0000]
=A0 #8 [0000990000 - 000099d000] =A0 =A0 =A0 =A0 =A0 =A0 =A0BRK =3D=3D= > [0000990000 - 000099d000]
=A0 #9 [0000100000 - 00001a1000] = =A0 =A0 =A0 =A0 =A0PGTABLE =3D=3D> [0000100000 - 00001a1000]
= =A0 #10 [0000007000 - 000000c000] =A0 =A0 =A0 =A0 =A0BOOTMAP =3D=3D> [00= 00007000 - 000000c000]
Zone PFN ranges:
=A0 DMA =A0 =A0 =A00x00000000 -> 0x00001= 000
=A0 Normal =A0 0x00001000 -> 0x00020800
=A0 High= Mem =A00x00020800 -> 0x00020800
Movable zone start PFN for eac= h node
early_node_map[2] active PFN ranges
=A0 =A0 0: 0x00000000 -&= gt; 0x000000a0
=A0 =A0 0: 0x00000100 -> 0x00020800
U= sing APIC driver default
SMP: Allowing 1 CPUs, 0 hotplug CPUs
Local APIC disabled by BIOS -- you can enable it with "lapic"
APIC: disable apic facility
Allocating PCI resources start= ing at 20800000 (gap: 20800000:df800000)
Booting paravirtualized = kernel on Xen
Xen version: 4.0.3-rc3-pre (preserve-AD)
NR_CPUS:8 nr_cpumas= k_bits:8 nr_cpu_ids:1 nr_node_ids:1
PERCPU: Embedded 16 pages/cpu= @cbfaf000 s42264 r0 d23272 u65536
pcpu-alloc: s42264 r0 d23272 u= 65536 alloc=3D16*4096
pcpu-alloc: [0] 0=A0
Built 1 zonelists in Zone order, mobili= ty grouping on. =A0Total pages: 131984
Kernel command line: root= =3D/dev/xvda1 ro ip=3D:127.0.255.255::::eth0:dhcp 4
PID hash tabl= e entries: 4096 (order: 2, 16384 bytes)
Dentry cache hash table entries: 131072 (order: 7, 524288 bytes)
=
Inode-cache hash table entries: 65536 (order: 6, 262144 bytes)
Enabling fast FPU save and restore... done.
Enabling unmasked = SIMD FPU exception support... done.
Initializing CPU#0
Initializing HighMem for node 0 (00000000= :00000000)
Memory: 331500k/532480k available (2980k kernel code, = 200480k reserved, 1684k data, 432k init, 0k highmem)
virtual kern= el memory layout:
=A0 =A0 fixmap =A0: 0xf567e000 - 0xf57ff000 =A0 (1540 kB)
= =A0 =A0 pkmap =A0 : 0xf5200000 - 0xf5400000 =A0 (2048 kB)
=A0 =A0= vmalloc : 0xe1000000 - 0xf51fe000 =A0 ( 321 MB)
=A0 =A0 lowmem = =A0: 0xc0000000 - 0xe0800000 =A0 ( 520 MB)
=A0 =A0 =A0 .init : 0xc088f000 - 0xc08fb000 =A0 ( 432 kB)
= =A0 =A0 =A0 .data : 0xc06e90b5 - 0xc088e140 =A0 (1684 kB)
=A0 =A0= =A0 .text : 0xc0400000 - 0xc06e90b5 =A0 (2980 kB)
SLUB: Genslabs= =3D13, HWalign=3D64, Order=3D0-3, MinObjects=3D0, CPUs=3D1, Nodes=3D1
Hierarchical RCU implementation.
NR_IRQS:2304 nr_irqs:512
Console: colour dummy device 80x25
console [tty0] enabled=
console [hvc0] enabled
installing Xen timer for CPU 0<= /div>
Detected 2660.066 MHz processor.
Calibrating delay loop (ski= pped), value calculated using timer frequency.. 5320.13 BogoMIPS (lpj=3D266= 0066)
Security Framework initialized
SELinux: =A0Initia= lizing.
Mount-cache hash table entries: 512
Initializing cgroup subs= ys ns
Initializing cgroup subsys cpuacct
Initializing c= group subsys devices
CPU: L1 I cache: 32K, L1 D cache: 32K
CPU: L2 cache: 4096K
CPU: Unsupported number of siblings 2
Performance Events: unsupported p6 CPU model 15 no PMU driver, sof= tware events only.
SMP alternatives: switching to UP code
Freeing SMP alternatives: 7k freed
cpu 0 spinlock event irq = 510
Brought up 1 CPUs
Grant table initialized
Time: 165:165:165 =A0Date: 165/165/65
NET: Registered protocol f= amily 16
PCI: setting up Xen PCI frontend stub
bio: create slab <b= io-0> at 0
ACPI: Interpreter disabled.
xen_balloon: = Initialising balloon driver with page order 0.
last_pfn =3D 0x208= 00 max_arch_pfn =3D 0x1000000
vgaarb: loaded
SCSI subsystem initialized
usbcore:= registered new interface driver usbfs
usbcore: registered new in= terface driver hub
usbcore: registered new device driver usb
PCI: System does not support PCI
PCI: System does not suppor= t PCI
NetLabel: Initializing
NetLabel: =A0domain hash s= ize =3D 128
NetLabel: =A0protocols =3D UNLABELED CIPSOv4
NetLabel: =A0unlabeled traffic allowed by default
Switching to clocksource xen
pnp: PnP ACPI: disabled
NET: Registered protocol family 2
IP route cache hash table en= tries: 8192 (order: 3, 32768 bytes)
TCP established hash table en= tries: 32768 (order: 6, 262144 bytes)
TCP bind hash table entries: 32768 (order: 6, 262144 bytes)
= TCP: Hash tables configured (established 32768 bind 32768)
TCP re= no registered
NET: Registered protocol family 1
Trying = to unpack rootfs image as initramfs...
Freeing initrd memory: 179924k freed
platform rtc_cmos: regi= stered platform RTC device (no PNP device found)
apm: BIOS not fo= und.
audit: initializing netlink socket (disabled)
type=3D2000 audit(1316106566.034:1): initialized
HugeTLB register= ed 2 MB page size, pre-allocated 0 pages
VFS: Disk quotas dquot_6= .5.2
Dquot-cache hash table entries: 1024 (order 0, 4096 bytes)
msgmni has been set to 999
alg: No test for stdrng (krng)
Block layer SCSI generic (bsg) driver version 0.4 loaded (major 252= )
io scheduler noop registered
io scheduler anticipator= y registered
io scheduler deadline registered
io scheduler cfq registered= (default)
pci_hotplug: PCI Hot Plug PCI Core version: 0.5
<= div>acpiphp: ACPI Hot Plug PCI Controller Driver version: 0.5
isapnp: ISA Plug & Play support disabled
Event-channel device= installed.
registering netback
Non-volatile memory dri= ver v1.3
Linux agpgart interface v0.103
Serial: 8250/16= 550 driver, 4 ports, IRQ sharing enabled
brd: module loaded
loop: module loaded
Initialisin= g Xen virtual ethernet driver.
ehci_hcd: USB 2.0 'Enhanced= 9; Host Controller (EHCI) Driver
ohci_hcd: USB 1.1 'Open'= Host Controller (OHCI) Driver
uhci_hcd: USB Universal Host Controller Interface driver
PNP= : No PS/2 controller found. Probing ports directly.
i8042.c: No c= ontroller found.
mice: PS/2 mouse device common for all mice
rtc_cmos rtc_cmos: rtc core: registered rtc_cmos as rtc0
dev= ice-mapper: uevent: version 1.0.3
device-mapper: ioctl: 4.15.0-io= ctl (2009-04-01) initialised: dm-dev= el@redhat.com
cpuidle: using governor ladder
cpuidle: using governor menu<= /div>
usbcore: registered new interface driver hiddev
usbcore= : registered new interface driver usbhid
usbhid: v2.6:USB HID cor= e driver
nf_conntrack version 0.5.0 (8192 buckets, 32768 max)
CONFIG_= NF_CT_ACCT is deprecated and will be removed soon. Please use
nf_= conntrack.acct=3D1 kernel parameter, acct=3D1 nf_conntrack module option or=
sysctl net.netfilter.nf_conntrack_acct=3D1 to enable it.
ip_= tables: (C) 2000-2006 Netfilter Core Team
TCP cubic registered
Initializing XFRM netlink socket
NET: Registered protocol= family 17
Using IPI No-Shortcut mode
registered taskstats version 1
XENBUS: Waiting for devices to initialise: 295s...290s...285s...280= s...275s...270s...265s...260s...255s...250s...245s...240s...235s...230s...2= 25s...220s...215s...210s...205s...200s...195s...190s...185s...180s...175s..= .170s...165s...160s...155s...150s...145s...140s...135s...130s...125s...120s= ...115s...110s...105s...100s...95s...90s...85s...80s...75s...70s...65s...60= s...55s...50s...45s...40s...35s...30s...25s...20s...15s...10s...5s...0s...<= /div>
XENBUS: Timeout connecting to device: device/vbd/51713 (local state 3,= remote state 1)
XENBUS: Timeout connecting to device: device/vbd= /51714 (local state 3, remote state 1)
XENBUS: Device with no dri= ver: device/console/0
=A0 Magic number: 1:252:3141
Freeing unused kernel memory: 4= 32k freed
Write protecting the kernel text: 2984k
Write= protecting the kernel read-only data: 1452k
Loading, please wait= ...
mount: mounting none on /dev failed: No such device
W: devtm= pfs not available, falling back to tmpfs for /dev
hrtimer: interr= upt took 6765654 ns
Begin: Loading essential drivers ... done.
Begin: Running /scripts/init-premount ... done.
Begin: Mount= ing root file system ... Begin: Running /scripts/local-top ... done.
<= div>Gave up waiting for root device. =A0Common problems:
=A0- Boo= t args (cat /proc/cmdline)
=A0 =A0- Check rootdelay=3D (did the system wait long enough?)
=A0 =A0- Check root=3D (did the system wait for the right device?)
=
=A0- Missing modules (cat /proc/modules; ls /dev)
ALERT! =A0= /dev/xvda1 does not exist. =A0Dropping to a shell!


Here is my xenstore-ls:
tool =3D ""
=A0xenstored =3D ""
vm =3D ""
=A000000000-0000-0000-0000-000000000000 =3D ""
=A0 on_x= end_stop =3D "ignore"
=A0 shadow_memory =3D "0&quo= t;
=A0 uuid =3D "00000000-0000-0000-0000-000000000000"<= /div>
=A0 on_reboot =3D "restart"
=A0 image =3D "(linux (kernel ) (superpages 0) (nomigrate 0) (tsc= _mode 0))"
=A0 =A0ostype =3D "linux"
=A0= =A0kernel =3D ""
=A0 =A0cmdline =3D ""
=
=A0 =A0ramdisk =3D ""
=A0 on_poweroff =3D "destroy"
=A0 bootloader_args = =3D ""
=A0 on_xend_start =3D "ignore"
=A0 on_crash =3D "restart"
=A0 xend =3D ""=
=A0 =A0restart_count =3D "0"
=A0 vcpus =3D "2"
=A0 vcpu_avail =3D "3"=
=A0 bootloader =3D ""
=A0 name =3D "Dom= ain-0"
=A00c879418-b8df-eed2-53a2-05dd9d768284 =3D "&qu= ot;
=A0 image =3D "(linux (kernel /boot/vmlinuz-2.6.32.46) (= ramdisk /boot/initrd.img-2.6.32.46) (args 'root=3D/dev/xvda1 ro ip=3D:1= 27.0.255.255::::eth0:dhcp\..."
=A0 =A0ostype =3D "linux"
=A0 =A0kernel =3D "= /boot/vmlinuz-2.6.32.46"
=A0 =A0cmdline =3D "root=3D/de= v/xvda1 ro ip=3D:127.0.255.255::::eth0:dhcp 4"
=A0 =A0ramdis= k =3D "/boot/initrd.img-2.6.32.46"
=A0 device =3D ""
=A0 =A0tap =3D ""
=A0 =A0 51713 =3D ""
=A0 =A0 =A0frontend =3D &quo= t;/local/domain/1/device/vbd/51713"
=A0 =A0 =A0frontend-id = =3D "1"
=A0 =A0 =A0backend-id =3D "0"
=A0 =A0 =A0backend =3D "/local/domain/0/backend/tap/1/51713"=
=A0 =A0 51714 =3D ""
=A0 =A0 =A0frontend =3D= "/local/domain/1/device/vbd/51714"
=A0 =A0 =A0frontend= -id =3D "1"
=A0 =A0 =A0backend-id =3D "0"
=A0 =A0 =A0backend = =3D "/local/domain/0/backend/tap/1/51714"
=A0 =A0vif = =3D ""
=A0 =A0 0 =3D ""
=A0 =A0 =A0= frontend =3D "/local/domain/1/device/vif/0"
=A0 =A0 =A0frontend-id =3D "1"
=A0 =A0 =A0backend-= id =3D "0"
=A0 =A0 =A0backend =3D "/local/domain/0= /backend/vif/1/0"
=A0 =A0console =3D ""
= =A0 =A0 0 =3D ""
=A0 =A0 =A0frontend =3D "/local/domain/1/device/console/0"
=A0 =A0 =A0frontend-id =3D "1"
=A0 =A0 =A0back= end-id =3D "0"
=A0 =A0 =A0backend =3D "/local/doma= in/0/backend/console/1/0"
=A0 on_xend_stop =3D "ignore"
=A0 shadow_memory = =3D "0"
=A0 uuid =3D "0c879418-b8df-eed2-53a2-05dd= 9d768284"
=A0 on_reboot =3D "restart"
= =A0 start_time =3D "1316106563.89"
=A0 on_poweroff =3D "destroy"
=A0 bootloader_args = =3D ""
=A0 on_xend_start =3D "ignore"
=A0 on_crash =3D "restart"
=A0 xend =3D ""=
=A0 =A0restart_count =3D "0"
=A0 vcpus =3D "1"
=A0 vcpu_avail =3D "1"=
=A0 bootloader =3D ""
=A0 name =3D "Xen= Guest1"
local =3D ""
=A0domain =3D "= ;"
=A0 0 =3D ""
=A0 =A0vm =3D "/vm/00000000-0000-0000= -0000-000000000000"
=A0 =A0device =3D ""
=A0 =A0control =3D ""
=A0 =A0 platform-feature-multipr= ocessor-suspend =3D "1"
=A0 =A0error =3D ""
=A0 =A0memory =3D ""=
=A0 =A0 target =3D "3407872"
=A0 =A0guest = =3D ""
=A0 =A0hvmpv =3D ""
=A0 =A0d= ata =3D ""
=A0 =A0cpu =3D ""
=A0 =A0 1 =3D ""
=A0 =A0 =A0availability =3D "= ;online"
=A0 =A0 0 =3D ""
=A0 =A0 =A0ava= ilability =3D "online"
=A0 =A0description =3D "&qu= ot;
=A0 =A0console =3D ""
=A0 =A0 limit =3D "1048576"
=A0 =A0 type =3D "= ;xenconsoled"
=A0 =A0domid =3D "0"
=A0 = =A0name =3D "Domain-0"
=A0 =A0backend =3D ""<= /div>
=A0 =A0 tap =3D ""
=A0 =A0 =A01 =3D ""
=A0 =A0 =A0 51713 =3D "&q= uot;
=A0 =A0 =A0 =A0domain =3D "XenGuest1"
= =A0 =A0 =A0 =A0frontend =3D "/local/domain/1/device/vbd/51713"
=A0 =A0 =A0 =A0uuid =3D "88476a24-fe5c-cc91-bc87-cbe07b5bd2a3&= quot;
=A0 =A0 =A0 =A0bootable =3D "1"
=A0 =A0 =A0 =A0dev= =3D "xvda1"
=A0 =A0 =A0 =A0state =3D "1"
=A0 =A0 =A0 =A0params =3D "aio:/xen/XenGuest1.img"
=A0 =A0 =A0 =A0mode =3D "w"
=A0 =A0 =A0 =A0online =3D "1"
=A0 =A0 =A0 =A0front= end-id =3D "1"
=A0 =A0 =A0 =A0type =3D "tap"<= /div>
=A0 =A0 =A0 =A0hotplug-status =3D "connected"
=A0 =A0 =A0 51714 =3D ""
=A0 =A0 =A0 =A0domain =3D "XenGuest1"
=A0 =A0 =A0 =A0fr= ontend =3D "/local/domain/1/device/vbd/51714"
=A0 =A0 = =A0 =A0uuid =3D "e574dca6-2710-f8ed-4cb6-983421c415d6"
= =A0 =A0 =A0 =A0bootable =3D "0"
=A0 =A0 =A0 =A0dev =3D "xvda2"
=A0 =A0 =A0 =A0stat= e =3D "1"
=A0 =A0 =A0 =A0params =3D "aio:/xen/XenG= uest1.swap"
=A0 =A0 =A0 =A0mode =3D "w"
= =A0 =A0 =A0 =A0online =3D "1"
=A0 =A0 =A0 =A0frontend-id =3D "1"
=A0 =A0 =A0 =A0type = =3D "tap"
=A0 =A0 =A0 =A0hotplug-status =3D "conne= cted"
=A0 =A0 vif =3D ""
=A0 =A0 =A01 = =3D ""
=A0 =A0 =A0 0 =3D ""
=A0 =A0 =A0 =A0domain =3D "XenGuest1"
=A0 =A0 =A0 = =A0handle =3D "0"
=A0 =A0 =A0 =A0uuid =3D "a916031= e-38be-f70a-89f3-47d2cb9a16f8"
=A0 =A0 =A0 =A0script =3D &qu= ot;/etc/xen/scripts/vif-bridge"
=A0 =A0 =A0 =A0state =3D "4"
=A0 =A0 =A0 =A0fronte= nd =3D "/local/domain/1/device/vif/0"
=A0 =A0 =A0 =A0ma= c =3D "00:16:3e:41:3f:05"
=A0 =A0 =A0 =A0online =3D &qu= ot;1"
=A0 =A0 =A0 =A0frontend-id =3D "1"
=A0 =A0 =A0 =A0feature-sg =3D "1"
=A0 =A0 =A0 =A0f= eature-gso-tcpv4 =3D "1"
=A0 =A0 =A0 =A0feature-rx-copy= =3D "1"
=A0 =A0 =A0 =A0feature-rx-flip =3D "0&quo= t;
=A0 =A0 =A0 =A0feature-smart-poll =3D "1"
=A0 =A0 =A0 =A0hotplug-status =3D "connected"
=A0 = =A0 console =3D ""
=A0 =A0 =A01 =3D ""
<= div>=A0 =A0 =A0 0 =3D ""
=A0 =A0 =A0 =A0domain =3D &quo= t;XenGuest1"
=A0 =A0 =A0 =A0protocol =3D "vt100"
=A0 =A0 =A0 =A0uuid =3D "6358d1af-79ef-8334-fc5e-8861cb582a66&quo= t;
=A0 =A0 =A0 =A0frontend =3D "/local/domain/1/device/conso= le/0"
=A0 =A0 =A0 =A0state =3D "1"
=A0 = =A0 =A0 =A0location =3D "2"
=A0 =A0 =A0 =A0online =3D "1"
=A0 =A0 =A0 =A0front= end-id =3D "1"
=A0 1 =3D ""
=A0 =A0= vm =3D "/vm/0c879418-b8df-eed2-53a2-05dd9d768284"
=A0 = =A0device =3D ""
=A0 =A0 vbd =3D ""
=A0 =A0 =A051713 =3D ""
=A0 =A0 =A0 virtual-device =3D "51713"
=A0 =A0 = =A0 device-type =3D "disk"
=A0 =A0 =A0 protocol =3D &qu= ot;x86_32-abi"
=A0 =A0 =A0 backend-id =3D "0"
=A0 =A0 =A0 state =3D "3"
=A0 =A0 =A0 backend =3D = "/local/domain/0/backend/tap/1/51713"
=A0 =A0 =A0 ring-= ref =3D "8"
=A0 =A0 =A0 event-channel =3D "9"=
=A0 =A0 =A051714 =3D ""
=A0 =A0 =A0 virtual-device =3D "51714"
=A0 =A0 =A0= device-type =3D "disk"
=A0 =A0 =A0 protocol =3D "= x86_32-abi"
=A0 =A0 =A0 backend-id =3D "0"
=A0 =A0 =A0 state =3D "3"
=A0 =A0 =A0 backend =3D "/local/domain/0/backend/tap/1/51714"= ;
=A0 =A0 =A0 ring-ref =3D "9"
=A0 =A0 =A0 ev= ent-channel =3D "10"
=A0 =A0 vif =3D ""
=
=A0 =A0 =A00 =3D ""
=A0 =A0 =A0 mac =3D "00:16:3e:41:3f:05"
=A0 =A0 = =A0 handle =3D "0"
=A0 =A0 =A0 protocol =3D "x86_3= 2-abi"
=A0 =A0 =A0 backend-id =3D "0"
= =A0 =A0 =A0 state =3D "4"
=A0 =A0 =A0 backend =3D "/local/domain/0/backend/vif/1/0"
=A0 =A0 =A0 tx-ring-ref =3D "768"
=A0 =A0 =A0 r= x-ring-ref =3D "769"
=A0 =A0 =A0 event-channel =3D &quo= t;11"
=A0 =A0 =A0 request-rx-copy =3D "1"
=A0 =A0 =A0 feature-rx-notify =3D "1"
=A0 =A0 =A0 = feature-sg =3D "1"
=A0 =A0 =A0 feature-gso-tcpv4 =3D &q= uot;1"
=A0 =A0 =A0 feature-smart-poll =3D "0"
=A0 =A0 console =3D ""
=A0 =A0 =A00 =3D ""
=A0 =A0 =A0 protocol =3D "= ;x86_32-abi"
=A0 =A0 =A0 state =3D "1"
= =A0 =A0 =A0 backend-id =3D "0"
=A0 =A0 =A0 backend =3D = "/local/domain/0/backend/console/1/0"
=A0 =A0control =3D ""
=A0 =A0 platform-feature-mul= tiprocessor-suspend =3D "1"
=A0 =A0error =3D "&quo= t;
=A0 =A0memory =3D ""
=A0 =A0 target =3D &q= uot;524288"
=A0 =A0guest =3D ""
=A0 =A0hvmpv =3D ""
=
=A0 =A0data =3D ""
=A0 =A0device-misc =3D "&q= uot;
=A0 =A0 vif =3D ""
=A0 =A0 =A0nextDevice= ID =3D "1"
=A0 =A0 console =3D ""
=A0 =A0 =A0nextDeviceID =3D "1"
=A0 =A0console =3D= ""
=A0 =A0 ring-ref =3D "475120"
= =A0 =A0 port =3D "2"
=A0 =A0 limit =3D "1048576&qu= ot;
=A0 =A0 type =3D "xenconsoled"
=A0 =A0 tty =3D "/dev/pts/1"
=A0 =A0image =3D &quo= t;"
=A0 =A0 entry =3D "3230199808"
=A0 = =A0 loader =3D "generic"
=A0 =A0 hv-start-low =3D "= ;4118806528"
=A0 =A0 guest-os =3D "linux"
=A0 =A0 hypercall-page =3D= "3225427968"
=A0 =A0 guest-version =3D "2.6"=
=A0 =A0 pae-mode =3D "yes"
=A0 =A0 paddr-off= set =3D "0"
=A0 =A0 virt-base =3D "3221225472"
=A0 =A0 suspend= -cancel =3D "1"
=A0 =A0 features =3D ""
=
=A0 =A0 =A0pae-pgdir-above-4gb =3D "1"
=A0 =A0 =A0= writable-page-tables =3D "0"
=A0 =A0 xen-version =3D "xen-3.0"
=A0 =A0store =3D= ""
=A0 =A0 ring-ref =3D "475121"
= =A0 =A0 port =3D "1"
=A0 =A0description =3D ""= ;
=A0 =A0cpu =3D ""
=A0 =A0 0 =3D ""
=A0 =A0 =A0availability =3D "= ;online"
=A0 =A0name =3D "XenGuest1"
=A0= =A0domid =3D "1"
=A0 =A0serial =3D ""
<= div>=A0 =A0 0 =3D ""
=A0 =A0 =A0tty =3D "/dev/pts/1"

On Thu, Sep 15, 2011 at 4:01 AM, Konrad Rzeszut= ek Wilk <kon= rad.wilk@oracle.com> wrote:
On Thu, Sep 15, 2011 at 0= 2:02:25AM -0400, jinho hwang wrote:
> Hi,
>
> I have used disk image to copy host fs to image file and boot a guest<= br> > system. But, the system is dropped to shell and it also says that it c= an't

You need to give more details. What is the version of your Dom0?
Is there anything showing up in the Dom0 kernel when this fails?

Can you also include your xenstore-ls when this failure happens? You should=
see an entry for 51713 and 51714..

> find /dev/xvda1 which is the root fs. I have defined it in the configu= ration
> file as follows:
>
> disk =3D [ 'tap:aio:/xen/XenGuest1.img,xvda1,w',
> 'tap:aio:/xen/XenGuest1.swap,xvda2,w' ]
> root =3D "/dev/xvda1 ro"
>
> Also, modified the fstab as follows:
>
> /dev/xvda1 =A0 =A0 =A0 / =A0 =A0 =A0 =A0 =A0 =A0 =A0 ext3 =A0 =A0defau= lts =A0 =A0 =A0 =A0 =A01 =A0 =A0 =A0 1
> /dev/xvda2 =A0 =A0 =A0 none =A0 =A0 =A0 =A0 =A0 =A0swap =A0 =A0sw =A0 = =A0 =A0 =A0 =A0 =A0 =A0 =A00 =A0 =A0 =A0 0
> none =A0 =A0 =A0 =A0 =A0 =A0 /dev/pts =A0 =A0 =A0 =A0devpts =A0gid=3D5= ,mode=3D620 =A0 =A00 =A0 =A0 =A0 0
> none =A0 =A0 =A0 =A0 =A0 =A0 /dev/shm =A0 =A0 =A0 =A0tmpfs =A0 default= s =A0 =A0 =A0 =A0 =A00 =A0 =A0 =A0 0
> none =A0 =A0 =A0 =A0 =A0 =A0 /proc =A0 =A0 =A0 =A0 =A0 proc =A0 =A0def= aults =A0 =A0 =A0 =A0 =A00 =A0 =A0 =A0 0
> none =A0 =A0 =A0 =A0 =A0 =A0 /sys =A0 =A0 =A0 =A0 =A0 =A0sysfs =A0 def= aults =A0 =A0 =A0 =A0 =A00 =A0 =A0 =A0 0
>
> The following is the error shown in the console.
>
> Using IPI No-Shortcut mode
> registered taskstats version 1
> XENBUS: Waiting for devices to initialise:
> 295s...290s...285s...280s...275s...270s...265s...260s...255s...250s...= 245s...240s...235s...230s...225s...220s...215s...210s...205s...200s...195s.= ..190s...185s...180s...175s...170s...165s...160s...155s...150s...145s...140= s...135s...130s...125s...120s...115s...110s...105s...100s...95s...90s...85s= ...80s...75s...70s...65s...60s...55s...50s...45s...40s...35s...30s...25s...= 20s...15s...10s...5s...0s...
> XENBUS: Timeout connecting to device: device/vbd/51713 (local state 3,=
> remote state 1)
> XENBUS: Timeout connecting to device: device/vbd/51714 (local state 3,=
> remote state 1)
> XENBUS: Device with no driver: device/console/0
> =A0 Magic number: 1:252:3141
> Freeing unused kernel memory: 432k freed
> Write protecting the kernel text: 2984k
> Write protecting the kernel read-only data: 1452k
> Loading, please wait...
> mount: mounting none on /dev failed: No such device
> W: devtmpfs not available, falling back to tmpfs for /dev
> Begin: Loading essential drivers ... done.
> Begin: Running /scripts/init-premount ... done.
> Begin: Mounting root file system ... Begin: Running /scripts/local-top= ...
> done.
> Gave up waiting for root device. =A0Common problems:
> =A0- Boot args (cat /proc/cmdline)
> =A0 =A0- Check rootdelay=3D (did the system wait long enough?)
> =A0 =A0- Check root=3D (did the system wait for the right device?)
> =A0- Missing modules (cat /proc/modules; ls /dev)
> ALERT! =A0/dev/xvda1 does not exist. =A0Dropping to a shell!
>
> If anybody has any idea, please let me know.
>
> Thank you,
>
> Jinho
>
> --
> Jinho Hwang
> PhD Student
> Department of Computer Science
> The George Washington University
> Washington, DC 20052
> hwang.jinho@gmail.com (em= ail)
> 276.336.0971 (= Cell)
> 202.994.4875 (= fax)
> 070.8285.6546 (myLg070)

> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xenso= urce.com
> htt= p://lists.xensource.com/xen-devel




--
Jinho Hwang<= br>PhD Student
Department of Computer Science
The George Washington U= niversity
Washington, DC 20052
hwang.jinho@gmail.com (email)
276.336.0971 (Cell)
202.994.4875 (fax)
070.8285.6546 (myLg070)
--000e0cd6cece996d1904acfe0f97-- --===============0219853376== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel --===============0219853376==-- From xen-devel-bounces@lists.xensource.com Thu Sep 15 10:47:22 2011 Return-path: Envelope-to: www-data@lists.xensource.com Delivery-date: Thu, 15 Sep 2011 10:47:22 -0700 Received: from localhost ([127.0.0.1] helo=lists.colo.xensource.com) by lists.xensource.com with esmtp (Exim 4.43) id 1R4G1x-0000bA-T2; Thu, 15 Sep 2011 10:47:21 -0700 Received: from mail182.messagelabs.com ([85.158.139.83]) by lists.xensource.com with esmtp (Exim 4.43) id 1R4G1P-0000OW-5e for xen-devel@lists.xensource.com; Thu, 15 Sep 2011 10:46:47 -0700 X-Env-Sender: Ian.Jackson@eu.citrix.com X-Msg-Ref: server-4.tower-182.messagelabs.com!1316108803!18502319!1 X-Originating-IP: [62.200.22.115] X-StarScan-Version: 6.4.1; banners=-,-,- X-VirusChecked: Checked Received: (qmail 14308 invoked from network); 15 Sep 2011 17:46:44 -0000 Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115) by server-4.tower-182.messagelabs.com with RC4-SHA encrypted SMTP; 15 Sep 2011 17:46:44 -0000 X-IronPort-AV: E=Sophos;i="4.68,388,1312156800"; d="scan'208";a="7866935" Received: from lonpmailmx01.citrite.net ([10.30.203.162]) by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5; 15 Sep 2011 17:46:43 +0000 Received: from woking.xci-test.com (10.80.248.135) by smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id 8.3.137.0; Thu, 15 Sep 2011 18:46:43 +0100 Received: from osstest by woking.xci-test.com with local (Exim 4.69) (envelope-from ) id 1R4G1L-000305-76; Thu, 15 Sep 2011 18:46:43 +0100 To: xen-devel@lists.xensource.com Message-ID: From: xen.org Date: Thu, 15 Sep 2011 18:46:43 +0100 MIME-Version: 1.0 Content-Type: text/plain Cc: ian.jackson@eu.citrix.com Subject: [Xen-devel] [xen-unstable test] 8945: tolerable FAIL - PUSHED X-BeenThere: xen-devel@lists.xensource.com X-Mailman-Version: 2.1.5 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xensource.com Errors-To: xen-devel-bounces@lists.xensource.com flight 8945 xen-unstable real [real] http://www.chiark.greenend.org.uk/~xensrcts/logs/8945/ Failures :-/ but no regressions. Tests which did not succeed, but are not blocking, including regressions (tests previously passed) regarded as allowable: test-amd64-amd64-xl-pcipt-intel 1 xen-build-check(1) blocked n/a test-amd64-i386-rhel6hvm-intel 1 xen-build-check(1) blocked n/a test-i386-i386-pv 1 xen-build-check(1) blocked n/a test-amd64-i386-pv 1 xen-build-check(1) blocked n/a build-amd64-pvops 4 kernel-build fail like 8942 test-amd64-amd64-pv 1 xen-build-check(1) blocked n/a test-i386-i386-xl 1 xen-build-check(1) blocked n/a test-amd64-i386-xl-multivcpu 1 xen-build-check(1) blocked n/a test-amd64-i386-xl 1 xen-build-check(1) blocked n/a test-amd64-i386-xl-credit2 1 xen-build-check(1) blocked n/a test-amd64-i386-rhel6hvm-amd 1 xen-build-check(1) blocked n/a test-amd64-amd64-pair 1 xen-build-check(1) blocked n/a test-amd64-i386-pair 1 xen-build-check(1) blocked n/a test-i386-i386-pair 1 xen-build-check(1) blocked n/a build-i386-pvops 4 kernel-build fail like 8942 test-amd64-amd64-xl-sedf 1 xen-build-check(1) blocked n/a test-amd64-i386-win-vcpus1 1 xen-build-check(1) blocked n/a test-amd64-i386-xl-win-vcpus1 1 xen-build-check(1) blocked n/a test-amd64-amd64-win 1 xen-build-check(1) blocked n/a test-amd64-i386-win 1 xen-build-check(1) blocked n/a test-amd64-amd64-xl-win 1 xen-build-check(1) blocked n/a test-amd64-amd64-xl 1 xen-build-check(1) blocked n/a test-i386-i386-xl-win 1 xen-build-check(1) blocked n/a test-i386-i386-win 1 xen-build-check(1) blocked n/a version targeted for testing: xen 4815be3af73c baseline version: xen 42a45baf037d ------------------------------------------------------------ People who touched revisions under test: Ian Jackson Juergen Gross Olaf Hering ------------------------------------------------------------ jobs: build-amd64 pass build-i386 pass build-amd64-oldkern pass build-i386-oldkern pass build-amd64-pvops fail build-i386-pvops fail test-amd64-amd64-xl blocked test-amd64-i386-xl blocked test-i386-i386-xl blocked test-amd64-i386-rhel6hvm-amd blocked test-amd64-i386-xl-credit2 blocked test-amd64-amd64-xl-pcipt-intel blocked test-amd64-i386-rhel6hvm-intel blocked test-amd64-i386-xl-multivcpu blocked test-amd64-amd64-pair blocked test-amd64-i386-pair blocked test-i386-i386-pair blocked test-amd64-amd64-pv blocked test-amd64-i386-pv blocked test-i386-i386-pv blocked test-amd64-amd64-xl-sedf blocked test-amd64-i386-win-vcpus1 blocked test-amd64-i386-xl-win-vcpus1 blocked test-amd64-amd64-win blocked test-amd64-i386-win blocked test-i386-i386-win blocked test-amd64-amd64-xl-win blocked test-i386-i386-xl-win blocked ------------------------------------------------------------ sg-report-flight on woking.cam.xci-test.com logs: /home/xc_osstest/logs images: /home/xc_osstest/images Logs, config files, etc. are available at http://www.chiark.greenend.org.uk/~xensrcts/logs Test harness code can be found at http://xenbits.xensource.com/gitweb?p=osstest.git;a=summary Pushing revision : + branch=xen-unstable + revision=4815be3af73c + . cri-lock-repos ++ . cri-common +++ umask 002 +++ getconfig Repos +++ perl -e ' use Osstest; readconfigonly(); print $c{Repos} or die $!; ' ++ repos=/export/home/osstest/repos ++ repos_lock=/export/home/osstest/repos/lock ++ '[' x '!=' x/export/home/osstest/repos/lock ']' ++ OSSTEST_REPOS_LOCK_LOCKED=/export/home/osstest/repos/lock ++ exec with-lock-ex -w /export/home/osstest/repos/lock ./ap-push xen-unstable 4815be3af73c + branch=xen-unstable + revision=4815be3af73c + . cri-lock-repos ++ . cri-common +++ umask 002 +++ getconfig Repos +++ perl -e ' use Osstest; readconfigonly(); print $c{Repos} or die $!; ' ++ repos=/export/home/osstest/repos ++ repos_lock=/export/home/osstest/repos/lock ++ '[' x/export/home/osstest/repos/lock '!=' x/export/home/osstest/repos/lock ']' + : xen@xenbits.xensource.com + : xen@xenbits.xensource.com:git/linux-pvops + : master + : tested/2.6.39.x + case "$branch" in + cd /export/home/osstest/repos/xen-unstable.hg + hg push -r 4815be3af73c ssh://xen@xenbits.xensource.com/HG/xen-unstable.hg pushing to ssh://xen@xenbits.xensource.com/HG/xen-unstable.hg searching for changes remote: adding changesets remote: adding manifests remote: adding file changes remote: added 1 changesets with 1 changes to 1 files _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel From xen-devel-bounces@lists.xensource.com Thu Sep 15 11:40:13 2011 Return-path: Envelope-to: www-data@lists.xensource.com Delivery-date: Thu, 15 Sep 2011 11:40:13 -0700 Received: from localhost ([127.0.0.1] helo=lists.colo.xensource.com) by lists.xensource.com with esmtp (Exim 4.43) id 1R4Gr7-0003aE-B7; Thu, 15 Sep 2011 11:40:13 -0700 Received: from mail216.messagelabs.com ([85.158.143.99]) by lists.xensource.com with esmtp (Exim 4.43) id 1R4GqF-0003Ll-1J for xen-devel@lists.xensource.com; Thu, 15 Sep 2011 11:39:19 -0700 X-Env-Sender: dan.magenheimer@oracle.com X-Msg-Ref: server-2.tower-216.messagelabs.com!1316111954!18420397!1 X-Originating-IP: [148.87.113.117] X-StarScan-Version: 6.4.1; banners=-,-,- X-VirusChecked: Checked Received: (qmail 6887 invoked from network); 15 Sep 2011 18:39:15 -0000 Received: from rcsinet15.oracle.com (HELO rcsinet15.oracle.com) (148.87.113.117) by server-2.tower-216.messagelabs.com with DHE-RSA-AES256-SHA encrypted SMTP; 15 Sep 2011 18:39:15 -0000 Received: from rtcsinet21.oracle.com (rtcsinet21.oracle.com [66.248.204.29]) by rcsinet15.oracle.com (Switch-3.4.4/Switch-3.4.4) with ESMTP id p8FId4Le010368 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Thu, 15 Sep 2011 18:39:06 GMT Received: from acsmt357.oracle.com (acsmt357.oracle.com [141.146.40.157]) by rtcsinet21.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id p8FId1c4027409 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 15 Sep 2011 18:39:02 GMT Received: from abhmt118.oracle.com (abhmt118.oracle.com [141.146.116.70]) by acsmt357.oracle.com (8.12.11.20060308/8.12.11) with ESMTP id p8FIcsSt030775; Thu, 15 Sep 2011 13:38:54 -0500 MIME-Version: 1.0 Message-ID: <5224b434-5371-404d-8fed-2665e73dacce@default> Date: Thu, 15 Sep 2011 11:38:41 -0700 (PDT) From: Dan Magenheimer To: George Dunlap , Philippe Simonet Subject: RE: [Xen-devel] Xen 4 TSC problems References: <4E6F034B.5040102@bluewin.ch CAFLBxZZiGxef5CkH9r+VZeB4h7LPA0nJddumwDRovZaL4zOuvA@mail.gmail.com> In-Reply-To: X-Priority: 3 X-Mailer: Oracle Beehive Extensions for Outlook 2.0.1.4.1.0 (410211) [OL 12.0.6557.5001] Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable X-Source-IP: rtcsinet21.oracle.com [66.248.204.29] X-CT-RefId: str=0001.0A090208.4E72464B.01D8,ss=1,re=0.000,fgs=0 Cc: jeremy@goop.org, xen-devel@lists.xensource.com, Keir Fraser , Konrad Wilk X-BeenThere: xen-devel@lists.xensource.com X-Mailman-Version: 2.1.5 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xensource.com Errors-To: xen-devel-bounces@lists.xensource.com > From: George Dunlap [mailto:George.Dunlap@eu.citrix.com] > Sent: Thursday, September 15, 2011 4:36 AM > To: Philippe Simonet > Cc: xen-devel@lists.xensource.com > Subject: Re: [Xen-devel] Xen 4 TSC problems >=20 > On Tue, Sep 13, 2011 at 8:16 AM, Philippe Simonet > wrote: > > Hi Xen developers > > > > i just would like to inform you that I have exactly the same problem wi= th > > Debian squeeze and xen, with > > 50 seconds time jump on my dom0 and domu. NTP is running on all dom0/do= muU, > > clocksource is 'xen' > > everywhere. > > > > some messages : > > syslog : > > Sep 11 13:56:50 dnsit22 kernel: [571603.359863] Clocksource tsc unstabl= e > > (delta =3D -2999662111513 ns) > > > > xm dmesg : > > ... > > (XEN) Platform timer is 14.318MHz HPET > > ... > > (XEN) Platform timer appears to have unexpectedly wrapped 10 or more ti= mes. > > (XEN) TSC marked as reliable, warp =3D 0 (count=3D2) > > ... >=20 > I haven't been following this conversation, so I don't know if this is > relevant, but I've just discovered this morning that the TSC warp > check in Xen is done at the wrong time (before any secondary cpus are > brought up), and thus always returns warp=3D0. I've submitted a patch > to do the check after secondary CPUs are brought up; that should cause > Xen to do periodic synchronization of TSCs when there is drift. Wow, nice catch, George! I wonder if this is the underlying bug for many of the mysterious time problems that have been reported for a year or two now... at least on certain AMD boxes. Any idea when this was introduced? Or has it always been wrong? Dan _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel From xen-devel-bounces@lists.xensource.com Thu Sep 15 11:59:08 2011 Return-path: Envelope-to: www-data@lists.xensource.com Delivery-date: Thu, 15 Sep 2011 11:59:08 -0700 Received: from localhost ([127.0.0.1] helo=lists.colo.xensource.com) by lists.xensource.com with esmtp (Exim 4.43) id 1R4H9P-0004KA-BF; Thu, 15 Sep 2011 11:59:08 -0700 Received: from mail27.messagelabs.com ([193.109.254.147]) by lists.xensource.com with smtp (Exim 4.43) id 1R4H7R-000453-7Q for xen-devel@lists.xensource.com; Thu, 15 Sep 2011 11:57:06 -0700 X-Env-Sender: gcvxd-xen-devel@m.gmane.org X-Msg-Ref: server-5.tower-27.messagelabs.com!1316113003!45048000!1 X-Originating-IP: [80.91.229.12] X-StarScan-Version: 6.4.1; banners=-,-,- X-VirusChecked: Checked Received: (qmail 3648 invoked from network); 15 Sep 2011 18:56:43 -0000 Received: from lo.gmane.org (HELO lo.gmane.org) (80.91.229.12) by server-5.tower-27.messagelabs.com with SMTP; 15 Sep 2011 18:56:43 -0000 Received: from list by lo.gmane.org with local (Exim 4.69) (envelope-from ) id 1R4H7J-0002Z3-Iu for xen-devel@lists.xensource.com; Thu, 15 Sep 2011 20:56:57 +0200 Received: from staff.ndchost.com ([204.10.36.76]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Thu, 15 Sep 2011 20:56:57 +0200 Received: from mailinglists by staff.ndchost.com with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Thu, 15 Sep 2011 20:56:57 +0200 X-Injected-Via-Gmane: http://gmane.org/ To: xen-devel@lists.xensource.com From: Shaun Reitan Date: Thu, 15 Sep 2011 11:56:31 -0700 Organization: Network Data Center Host, Inc. Lines: 188 Message-ID: Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Complaints-To: usenet@dough.gmane.org X-Gmane-NNTP-Posting-Host: staff.ndchost.com User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.2.18) Gecko/20110616 Thunderbird/3.1.11 Subject: [Xen-devel] kernel BUG at mm/swapfile.c:2527! X-BeenThere: xen-devel@lists.xensource.com X-Mailman-Version: 2.1.5 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xensource.com Errors-To: xen-devel-bounces@lists.xensource.com We've been seeing the following bugs hit. This is happening with kernel versions 2.6.39 and 3.0.1. So far we've only see this problem happen on ubuntu servers and it always seams to be the apache process that triggers it. Also this time we were running a PCI compliance scan on the server. We are thinking that may have triggered it. 2.6.39 Dump ------------[ cut here ]------------ kernel BUG at mm/swapfile.c:2527! invalid opcode: 0000 [#1] SMP last sysfs file: /sys/devices/vbd-51712/block/xvda/uevent Modules linked in: Pid: 30706, comm: apache2 Not tainted 2.6.39-2 #3 EIP: 0061:[] EFLAGS: 00210246 CPU: 0 EIP is at swap_count_continued+0x176/0x190 EAX: 00000000 EBX: ebba0800 ECX: 80000001 EDX: f57ba95f ESI: 00000080 EDI: ebbd7d40 EBP: 0000095f ESP: df4dbe38 DS: 007b ES: 007b FS: 00d8 GS: 0000 SS: 0069 Process apache2 (pid: 30706, ti=df4da000 task=e9259bd0 task.ti=df4da000) Stack: ea298d40 0000495f ee11a000 00000000 c01ab157 0000495f 00092be0 ea298d40 b8f33000 c01ac277 00000000 00092be0 e91ed998 c019dba7 6afaa065 80000001 00000000 00000000 c01065b3 c01036cd b9531fff 00000000 e8fdb348 df4dbf0c Call Trace: [] ? swap_entry_free+0x127/0x150 [] ? free_swap_and_cache+0x27/0xd0 [] ? unmap_vmas+0x587/0x7f0 [] ? xen_restore_fl_direct_reloc+0x4/0x4 [] ? xen_mc_flush+0xdd/0x190 [] ? exit_mmap+0x8a/0x140 [] ? mmput+0x41/0xd0 [] ? exit_mm+0xed/0x110 [] ? _raw_spin_lock_irq+0x10/0x20 [] ? do_exit+0x197/0x760 [] ? __xen_evtchn_do_upcall+0x1e7/0x240 [] ? xen_force_evtchn_callback+0x17/0x30 [] ? do_group_exit+0x2f/0x90 [] ? sys_exit_group+0xd/0x10 [] ? syscall_call+0x7/0xb [] ? cpuup_callback+0x100/0x260 Code: d7 fe ff ff 89 d8 e8 7a 9f f7 ff 8d 54 05 00 c6 02 00 eb b0 0f 0b eb fe 0f 0b eb fe 89 f2 31 c0 80 fa 80 0f 94 c0 e9 b2 fe ff ff <0f> 0b eb fe 0f 0b eb fe 0f 0b eb fe 8d b4 26 00 00 00 00 8d bc EIP: [] swap_count_continued+0x176/0x190 SS:ESP 0069:df4dbe38 ---[ end trace 9fa17c616c267728 ]--- Fixing recursive fault but reboot is needed! BUG: scheduling while atomic: apache2/30706/0x00000001 Modules linked in: Pid: 30706, comm: apache2 Tainted: G D 2.6.39-2 #3 Call Trace: [] ? schedule+0x76f/0x840 [] ? vprintk+0x19f/0x3a0 [] ? check_events+0x8/0xc [] ? _raw_spin_unlock_irqrestore+0x11/0x20 [] ? vprintk+0x19f/0x3a0 [] ? do_exit+0x6aa/0x760 [] ? _raw_spin_lock_irqsave+0x27/0x40 [] ? _raw_spin_unlock_irqrestore+0x11/0x20 [] ? kmsg_dump+0x36/0xd0 [] ? do_bounds+0x80/0x80 [] ? printk+0x1b/0x20 [] ? do_bounds+0x80/0x80 [] ? oops_end+0x9f/0xa0 [] ? do_invalid_op+0x7f/0x90 [] ? swap_count_continued+0x176/0x190 [] ? free_pcppages_bulk+0x2c9/0x2f0 [] ? xen_force_evtchn_callback+0x17/0x30 [] ? check_events+0x8/0xc [] ? xen_restore_fl_direct_reloc+0x4/0x4 [] ? free_hot_cold_page+0xd6/0x160 [] ? pte_pfn_to_mfn+0xb5/0xd0 [] ? xen_make_pte+0x41/0x110 [] ? error_code+0x5a/0x60 [] ? do_bounds+0x80/0x80 [] ? swap_count_continued+0x176/0x190 [] ? swap_entry_free+0x127/0x150 [] ? free_swap_and_cache+0x27/0xd0 [] ? unmap_vmas+0x587/0x7f0 [] ? xen_restore_fl_direct_reloc+0x4/0x4 [] ? xen_mc_flush+0xdd/0x190 [] ? exit_mmap+0x8a/0x140 [] ? mmput+0x41/0xd0 [] ? exit_mm+0xed/0x110 [] ? _raw_spin_lock_irq+0x10/0x20 [] ? do_exit+0x197/0x760 [] ? __xen_evtchn_do_upcall+0x1e7/0x240 [] ? xen_force_evtchn_callback+0x17/0x30 [] ? do_group_exit+0x2f/0x90 [] ? sys_exit_group+0xd/0x10 [] ? syscall_call+0x7/0xb [] ? cpuup_callback+0x100/0x260 Here's the 3.0.1 Dump, unfortunately i didn't catch a full dump. BUG: unable to handle kernel paging request at f57ba13c IP: [] swap_count_continued+0x85/0x190 *pdpt = 0000000000959027 *pde = 00000000008f5067 *pte = 0000000000000000 Oops: 0000 [#1] SMP Modules linked in: Pid: 3666, comm: apache2 Not tainted 3.0.1-1 #1 EIP: 0061:[] EFLAGS: 00010246 CPU: 0 EIP is at swap_count_continued+0x85/0x190 EAX: 00000080 EBX: ed302400 ECX: ecb870a0 EDX: f57ba13c ESI: 00000080 EDI: ed3d7760 EBP: 0000013c ESP: ea479dec DS: 007b ES: 007b FS: 00d8 GS: 0000 SS: 0069 Process apache2 (pid: 3666, ti=ea478000 task=ebe91bd0 task.ti=ea478000) Stack: ec6915c0 0001913c ee129000 00000040 c01aea77 0001913c 00322780 ec6915c0 b9275000 c01b0927 00000000 00322780 ea6533a8 c01a2d41 6e484067 80000001 c01059ef 80000000 00000000 ebad13c0 eae13e48 ec6ebb1c ea479ee8 00000000 Call Trace: [] ? swap_entry_free+0x127/0x150 [] ? free_swap_and_cache+0x27/0xd0 [] ? zap_pte_range+0x321/0x420 [] ? xen_make_pte+0x3f/0xc0 [] ? unmap_page_range+0x158/0x1a0 [] ? unmap_vmas+0x78/0xb0 [] ? exit_mmap+0x6e/0xf0 [] ? mmput+0x41/0xd0 [] ? exit_mm+0xed/0x110 [] ? _raw_spin_lock_irq+0x10/0x20 [] ? do_exit+0x197/0x340 [] ? remove_vma_list+0x39/0x50 [] ? do_group_exit+0x2f/0x90 [] ? sys_exit_group+0xd/0x10 [] ? syscall_call+0x7/0xb Code: 2a 90 8d 74 26 00 e9 15 01 00 00 89 d0 e8 c4 7e f7 ff 8b 5b 18 83 eb 18 39 df 0f 84 e5 00 00 00 89 d8 e8 3f 81 f7 ff 8d 54 05 00 <0f> b6 02 3c 80 74 d9 84 c0 0f 84 e2 00 00 00 83 e8 01 84 c0 88 EIP: [] swap_count_continued+0x85/0x190 SS:ESP 0069:ea479dec CR2: 00000000f57ba13c ---[ end trace 36a533bb83dd2812 ]--- Fixing recursive fault but reboot is needed! BUG: scheduling while atomic: apache2/3666/0x00000001 Modules linked in: Pid: 3666, comm: apache2 Tainted: G D 3.0.1-1 #1 Call Trace: [] ? schedule+0x50d/0x520 [] ? xen_restore_fl_direct_reloc+0x4/0x4 [] ? xen_force_evtchn_callback+0x17/0x30 [] ? do_exit+0x2df/0x340 [] ? printk+0x1b/0x20 [] ? oops_end+0x9f/0xa0 [] ? bad_area_nosemaphore+0xf/0x20 [] ? do_page_fault+0x1bb/0x420 [] ? irq_get_irq_data+0x5/0x10 [] ? info_for_irq+0x5/0x20 [] ? evtchn_from_irq+0x10/0x40 [] ? xen_force_evtchn_callback+0x17/0x30 [] ? check_events+0x8/0xc [] ? xen_restore_fl_direct_reloc+0x4/0x4 [] ? xen_batched_set_pte+0xab/0xf0 [] ? vmalloc_fault+0x2c0/0x2c0 [] ? error_code+0x5a/0x60 [] ? vmalloc_fault+0x2c0/0x2c0 [] ? swap_count_continued+0x85/0x190 [] ? swap_entry_free+0x127/0x150 [] ? free_swap_and_cache+0x27/0xd0 [] ? zap_pte_range+0x321/0x420 [] ? xen_make_pte+0x3f/0xc0 [] ? unmap_page_range+0x158/0x1a0 [] ? unmap_vmas+0x78/0xb0 [] ? exit_mmap+0x6e/0xf0 [] ? mmput+0x41/0xd0 [] ? exit_mm+0xed/0x110 [] ? _raw_spin_lock_irq+0x10/0x20 [] ? do_exit+0x197/0x340 [] ? remove_vma_list+0x39/0x50 [] ? do_group_exit+0x2f/0x90 [] ? sys_exit_group+0xd/0x10 [] ? syscall_call+0x7/0xb -- Shaun Retian Chief Technical Officer Network Data Center Host, Inc. http://www.ndchost.com _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel From xen-devel-bounces@lists.xensource.com Thu Sep 15 12:02:18 2011 Return-path: Envelope-to: www-data@lists.xensource.com Delivery-date: Thu, 15 Sep 2011 12:02:18 -0700 Received: from localhost ([127.0.0.1] helo=lists.colo.xensource.com) by lists.xensource.com with esmtp (Exim 4.43) id 1R4HCS-0004ip-9Q; Thu, 15 Sep 2011 12:02:16 -0700 Received: from mail21.messagelabs.com ([85.158.143.35]) by lists.xensource.com with smtp (Exim 4.43) id 1R4H91-0004I5-Pq for xen-devel@lists.xensource.com; Thu, 15 Sep 2011 11:59:05 -0700 X-Env-Sender: caker@theshore.net X-Msg-Ref: server-15.tower-21.messagelabs.com!1316113119!50741061!1 X-Originating-IP: [67.18.92.50] X-StarScan-Version: 6.4.1; banners=-,-,- X-VirusChecked: Checked Received: (qmail 21958 invoked from network); 15 Sep 2011 18:58:39 -0000 Received: from ns.theshore.net (HELO www.theshore.net) (67.18.92.50) by server-15.tower-21.messagelabs.com with SMTP; 15 Sep 2011 18:58:39 -0000 Received: from beefcake.linlan (173-161-199-49-Philadelphia.hfc.comcastbusiness.net [173.161.199.49]) by www.theshore.net (8.13.6/8.9.1) with ESMTP id p8FIwMMR014214; Thu, 15 Sep 2011 14:58:23 -0400 Message-ID: <4E724ACD.1050207@theshore.net> Date: Thu, 15 Sep 2011 14:58:21 -0400 From: "Christopher S. Aker" User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.6; en-US; rv:1.9.2.22) Gecko/20110902 Lightning/1.0b2 Thunderbird/3.1.14 MIME-Version: 1.0 To: Konrad Rzeszutek Wilk Subject: Re: [Xen-devel] Re: kernel BUG at mm/swapfile.c:2527! [was 3.0.0 Xen pv guest - BUG: Unable to handle] References: <9CAEB881-07FE-437C-8A6B-DB7B690CEABE@linode.com> <4E5BA49D.5060800@theshore.net> <20110829150734.GB24825@dumpdata.com> <1314704744.28989.2.camel@zakaz.uk.xensource.com> <4E5E9CDB.3070706@theshore.net> <20110906171319.GB29839@dumpdata.com> <4E6E2E11.1030602@theshore.net> <20110912161127.GB16100@oracle.com> In-Reply-To: <20110912161127.GB16100@oracle.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: Jeremy Fitzhardinge , "xen-devel@lists.xensource.com" , Ian Campbell , LKML X-BeenThere: xen-devel@lists.xensource.com X-Mailman-Version: 2.1.5 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xensource.com Errors-To: xen-devel-bounces@lists.xensource.com On 9/12/11 12:11 PM, Konrad Rzeszutek Wilk wrote: > On Mon, Sep 12, 2011 at 12:06:41PM -0400, Christopher S. Aker wrote: >>> It would really neat if the issue you have been hitting was exactly this >>> and just having you revert the ef691947d8a3d479e67652312783aedcf629320a >>> would fix it. >> >> Reverted, built, deployed, and set as default. We shall see! > > No joy. Still getting reports even with the patched kernel. I was so confident that this was the problem -- I've tripled checked that the patch was applied and that this is indeed the correct kernel. It was built with DEBUG_HIGHMEM too, without any difference in the dump. BUG: unable to handle kernel paging request at f5768598 IP: [] swap_count_continued+0x84/0x180 *pdpt = 0000000000939027 *pde = 00000000017ef067 *pte = 0000000000000000 Oops: 0000 [#1] SMP Modules linked in: Pid: 1619, comm: apache2 Not tainted 3.0.4-linode37 #1 EIP: 0061:[] EFLAGS: 00010246 CPU: 2 EIP is at swap_count_continued+0x84/0x180 EAX: f5768598 EBX: ed13af80 ECX: ec9cf0a0 EDX: 00000080 ESI: ed1d35a0 EDI: 00000080 EBP: 00000598 ESP: e73d3dd4 DS: 007b ES: 007b FS: 00d8 GS: 0000 SS: 0069 Process apache2 (pid: 1619, ti=e73d2000 task=ebd0e410 task.ti=e73d2000) Stack: ebd3f240 0000e598 00000040 00000000 c01abdc1 ec540e30 ebd3f240 0000e598 00000000 c01ae027 ec540e30 b8fc6000 e73d3e68 c01a00e3 44846045 80000008 00000000 00000020 c0105c27 2bbca063 001cb300 eb424200 ecf7780c eaaade38 Call Trace: [] ? swap_entry_free+0xf1/0x120 [] ? free_swap_and_cache+0x27/0xd0 [] ? zap_pte_range+0x173/0x460 [] ? xen_force_evtchn_callback+0x17/0x30 [] ? unmap_page_range+0x100/0x180 [] ? unmap_vmas+0x8a/0xc0 [] ? exit_mmap+0x73/0x100 [] ? mmput+0x2b/0xc0 [] ? exit_mm+0xef/0x120 [] ? _raw_spin_lock_irq+0x10/0x20 [] ? do_exit+0x125/0x350 [] ? remove_vma+0x37/0x50 [] ? do_group_exit+0x3c/0xa0 [] ? sys_exit_group+0x11/0x20 [] ? syscall_call+0x7/0xb [] ? sctp_err_lookup+0xb0/0x110 Code: 00 00 89 fa 80 fa 80 74 22 e9 0b 01 00 00 90 e8 63 7a f7 ff 8b 5b 18 83 eb 18 39 de 0f 84 f3 00 00 00 89 d8 e8 de 7c f7 ff 01 e8 <0f> b6 10 80 fa 80 74 dc 84 d2 0f 84 e2 00 00 00 83 ea 01 80 fa EIP: [] swap_count_continued+0x84/0x180 SS:ESP 0069:e73d3dd4 CR2: 00000000f5768598 ---[ end trace 06805b7648b253a0 ]--- So today I built a new stack and enabled loglvl=warning and guest_loglvl=warning/info, however it's probably going to take a while before we have enough of these running and hit this problem. I'm going to play around with it some more and see if I can find a recipe that can reproduce. -Chris _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel From xen-devel-bounces@lists.xensource.com Thu Sep 15 12:19:11 2011 Return-path: Envelope-to: www-data@lists.xensource.com Delivery-date: Thu, 15 Sep 2011 12:19:11 -0700 Received: from localhost ([127.0.0.1] helo=lists.colo.xensource.com) by lists.xensource.com with esmtp (Exim 4.43) id 1R4HSo-0005bN-SW; Thu, 15 Sep 2011 12:19:10 -0700 Received: from mail21.messagelabs.com ([85.158.143.35]) by lists.xensource.com with smtp (Exim 4.43) id 1R4HRi-0005No-A5 for xen-devel@lists.xensource.com; Thu, 15 Sep 2011 12:18:03 -0700 X-Env-Sender: caker@theshore.net X-Msg-Ref: server-2.tower-21.messagelabs.com!1316114277!34261386!1 X-Originating-IP: [67.18.92.50] X-StarScan-Version: 6.4.1; banners=-,-,- X-VirusChecked: Checked Received: (qmail 8326 invoked from network); 15 Sep 2011 19:17:58 -0000 Received: from ns.theshore.net (HELO www.theshore.net) (67.18.92.50) by server-2.tower-21.messagelabs.com with SMTP; 15 Sep 2011 19:17:58 -0000 Received: from beefcake.linlan (173-161-199-49-Philadelphia.hfc.comcastbusiness.net [173.161.199.49]) by www.theshore.net (8.13.6/8.9.1) with ESMTP id p8FJHvPC019841; Thu, 15 Sep 2011 15:17:57 -0400 Message-ID: <4E724F64.5080103@theshore.net> Date: Thu, 15 Sep 2011 15:17:56 -0400 From: "Christopher S. Aker" User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.6; en-US; rv:1.9.2.22) Gecko/20110902 Lightning/1.0b2 Thunderbird/3.1.14 MIME-Version: 1.0 To: Konrad Rzeszutek Wilk Subject: Re: [Xen-devel] Re: kernel BUG at mm/swapfile.c:2527! [was 3.0.0 Xen pv guest - BUG: Unable to handle] References: <9CAEB881-07FE-437C-8A6B-DB7B690CEABE@linode.com> <4E5BA49D.5060800@theshore.net> <20110829150734.GB24825@dumpdata.com> <1314704744.28989.2.camel@zakaz.uk.xensource.com> <4E5E9CDB.3070706@theshore.net> <20110906171319.GB29839@dumpdata.com> <4E6E2E11.1030602@theshore.net> <20110912161127.GB16100@oracle.com> <4E724ACD.1050207@theshore.net> In-Reply-To: <4E724ACD.1050207@theshore.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: Jeremy Fitzhardinge , "xen-devel@lists.xensource.com" , Ian Campbell , LKML X-BeenThere: xen-devel@lists.xensource.com X-Mailman-Version: 2.1.5 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xensource.com Errors-To: xen-devel-bounces@lists.xensource.com Another report, different user, and slightly different: BUG: unable to handle kernel paging request at f573fc8c IP: [] swap_count_continued+0x104/0x180 *pdpt = 000000002a3b9027 *pde = 0000000001bed067 *pte = 0000000000000000 Oops: 0000 [#1] SMP Modules linked in: Pid: 1638, comm: apache2 Not tainted 3.0.4-linode37 #1 EIP: 0061:[] EFLAGS: 00210246 CPU: 3 EIP is at swap_count_continued+0x104/0x180 EAX: f573fc8c EBX: ed1d4840 ECX: 00000000 EDX: 000000be ESI: ed1d4a20 EDI: 000000be EBP: 00000c8c ESP: e9e5fdb0 DS: 007b ES: 007b FS: 00d8 GS: 0033 SS: 0069 Process apache2 (pid: 1638, ti=e9e5e000 task=ead37410 task.ti=e9e5e000) Stack: ea746dc0 0000fc8c 000000be ffffffea c01ac222 358a1067 c01040f7 0002a75e 405d54c0 0000fc8c ea75e5e8 001f9180 b74bd000 c01ac2e4 00000000 c01a0a6b a9fdf045 80000002 00000000 00000000 0000fc8c 00000000 dc5d55e8 08100073 Call Trace: [] ? __swap_duplicate+0xc2/0x160 [] ? pte_mfn_to_pfn+0x87/0xe0 [] ? swap_duplicate+0x14/0x40 [] ? copy_pte_range+0x45b/0x500 [] ? copy_page_range+0x195/0x200 [] ? dup_mmap+0x1c6/0x2c0 [] ? dup_mm+0xa8/0x130 [] ? copy_process+0x98a/0xb30 [] ? do_fork+0x4f/0x280 [] ? getnstimeofday+0x43/0x100 [] ? sys_clone+0x30/0x40 [] ? ptregs_clone+0x15/0x48 [] ? syscall_call+0x7/0xb [] ? sctp_err_lookup+0xb0/0x110 Code: de 75 dc b8 01 00 00 00 5b 5e 5f 5d c3 66 90 e8 e3 79 f7 ff 8b 5b 18 83 eb 18 39 de 0f 84 7f 00 00 00 89 d8 e8 5e 7c f7 ff 01 e8 <0f> b6 10 80 fa ff 74 dc 80 fa 7f 74 28 83 c2 01 88 10 eb 0c 89 EIP: [] swap_count_continued+0x104/0x180 SS:ESP 0069:e9e5fdb0 CR2: 00000000f573fc8c ---[ end trace 18843f6443e730a1 ]--- _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel From xen-devel-bounces@lists.xensource.com Thu Sep 15 12:53:38 2011 Return-path: Envelope-to: www-data@lists.xensource.com Delivery-date: Thu, 15 Sep 2011 12:53:38 -0700 Received: from localhost ([127.0.0.1] helo=lists.colo.xensource.com) by lists.xensource.com with esmtp (Exim 4.43) id 1R4I0A-0007vm-KU; Thu, 15 Sep 2011 12:53:38 -0700 Received: from mail216.messagelabs.com ([85.158.143.99]) by lists.xensource.com with smtp (Exim 4.43) id 1R4Hzi-0007k4-7R for xen-devel@lists.xensource.com; Thu, 15 Sep 2011 12:53:10 -0700 X-Env-Sender: gcvxd-xen-devel@m.gmane.org X-Msg-Ref: server-10.tower-216.messagelabs.com!1316116387!10347322!1 X-Originating-IP: [80.91.229.12] X-StarScan-Version: 6.4.1; banners=-,-,- X-VirusChecked: Checked Received: (qmail 17462 invoked from network); 15 Sep 2011 19:53:07 -0000 Received: from lo.gmane.org (HELO lo.gmane.org) (80.91.229.12) by server-10.tower-216.messagelabs.com with SMTP; 15 Sep 2011 19:53:07 -0000 Received: from list by lo.gmane.org with local (Exim 4.69) (envelope-from ) id 1R4Hzd-0004bM-Ns for xen-devel@lists.xensource.com; Thu, 15 Sep 2011 21:53:05 +0200 Received: from staff.ndchost.com ([204.10.36.76]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Thu, 15 Sep 2011 21:53:05 +0200 Received: from mailinglists by staff.ndchost.com with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Thu, 15 Sep 2011 21:53:05 +0200 X-Injected-Via-Gmane: http://gmane.org/ To: xen-devel@lists.xensource.com From: Shaun Reitan Date: Thu, 15 Sep 2011 12:52:42 -0700 Organization: Network Data Center Host, Inc. Lines: 4 Message-ID: References: Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Complaints-To: usenet@dough.gmane.org X-Gmane-NNTP-Posting-Host: staff.ndchost.com User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.2.18) Gecko/20110616 Thunderbird/3.1.11 In-Reply-To: Subject: [Xen-devel] Re: kernel BUG at mm/swapfile.c:2527! X-BeenThere: xen-devel@lists.xensource.com X-Mailman-Version: 2.1.5 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xensource.com Errors-To: xen-devel-bounces@lists.xensource.com I can just about reproduce this bug on the fly, a PCI compliance scan seams to be triggering it every time. Let me know what you guys need! ~Shaun _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel From xen-users-bounces@lists.xensource.com Thu Sep 15 14:18:16 2011 Return-path: Envelope-to: www-data@lists.xensource.com Delivery-date: Thu, 15 Sep 2011 14:18:16 -0700 Received: from localhost ([127.0.0.1] helo=lists.colo.xensource.com) by lists.xensource.com with esmtp (Exim 4.43) id 1R4JK4-0001zu-0x; Thu, 15 Sep 2011 14:18:16 -0700 Received: from mail27.messagelabs.com ([193.109.254.147]) by lists.xensource.com with smtp (Exim 4.43) id 1R4CKy-0006io-4x; Thu, 15 Sep 2011 06:50:44 -0700 X-Env-Sender: anande@redhat.com X-Msg-Ref: server-11.tower-27.messagelabs.com!1316094632!37553177!1 X-Originating-IP: [209.132.183.28] X-StarScan-Version: 6.4.1; banners=-,-,- X-VirusChecked: Checked Received: (qmail 589 invoked from network); 15 Sep 2011 13:50:32 -0000 Received: from mx1.redhat.com (HELO mx1.redhat.com) (209.132.183.28) by server-11.tower-27.messagelabs.com with SMTP; 15 Sep 2011 13:50:32 -0000 Received: from int-mx12.intmail.prod.int.phx2.redhat.com (int-mx12.intmail.prod.int.phx2.redhat.com [10.5.11.25]) by mx1.redhat.com (8.14.4/8.14.4) with ESMTP id p8FDobGt003110 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Thu, 15 Sep 2011 09:50:37 -0400 Received: from anande.csb (vpn1-5-180.sin2.redhat.com [10.67.5.180]) by int-mx12.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP id p8FDoXRI005933; Thu, 15 Sep 2011 09:50:34 -0400 Message-ID: <4E7202A8.5060600@redhat.com> Date: Thu, 15 Sep 2011 19:20:32 +0530 From: Anand Nande Organization: Red Hat User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.2.17) Gecko/20110419 Red Hat/3.1.10-1.el6_0 Lightning/1.0b2pre Thunderbird/3.1.10 MIME-Version: 1.0 To: Development discussions related to Fedora , fedora-virt@redhat.com References: <20110914112552.GP12984@reaktio.net> In-Reply-To: <20110914112552.GP12984@reaktio.net> X-Scanned-By: MIMEDefang 2.68 on 10.5.11.25 X-Mailman-Approved-At: Thu, 15 Sep 2011 14:16:38 -0700 Cc: xen@lists.fedoraproject.org, virt@lists.fedoraproject.org, xen-devel@lists.xensource.com, xen-users@lists.xensource.com Subject: [Xen-users] [fedora-virt] KFT feature proposal review for F17 X-BeenThere: xen-users@lists.xensource.com X-Mailman-Version: 2.1.5 Precedence: list Reply-To: anande@redhat.com List-Id: Xen user discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1218477499==" Sender: xen-users-bounces@lists.xensource.com Errors-To: xen-users-bounces@lists.xensource.com This is a multi-part message in MIME format. --===============1218477499== Content-Type: multipart/alternative; boundary="------------000505070909080701090108" This is a multi-part message in MIME format. --------------000505070909080701090108 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit KFT (KVM Faul Tolernace): ======================== How it works: ------------- * Provide Continuous availability to Mission Critical Applications with a 'Always Available' environment preventing any downtime or Data-loss in the event of server-failures. * RFT when enabled for a Virtual Machine creates a secondary copy of it on another physical server running KVM. * The two copies are continuously synchronized by replaying the contents of the Memory from the primary VM to the Secondary (copy) VM. The Primary and the Secondary VM access the same storage device (shared storage) between the 2 servers. * For example: If a user is playing a Youtube video on VM1, and the KVM Guest VM-1 crashes (due to some reason), The Secondary-slave copy becomes Active and promotes itself as Primary immediately when the vdsm-agent (communicating between the KVM-Host and the KVM-GuestVM-1) detects the server crash. This leads to creation of another secondary copy on the Next available physical server (obviously sharing the same storage with the now-active Primary-VM). * Thus the GuestVM-2 (which was the secondary copy before the crash) ---> is now known as VM-1 (and the new secondary copy on the newly available server is now known as VM-2). * This can be achieved over qemu+ssh connections being managed by a single virt-manager as well. Advantages: ----------- * Zero Downtime: Fault Tolerance provides absolutely no downtime as that comapred to HA wherein the VM restarts completely on a different server. * Immunity from Server crashes/panic/OOM situations. * Extremely Fast Disaster Recover Mechanism. Disadvantages: -------------- * If a panic/crash takes place on the GuestVM being hosted on the KVM, This will be replicated on its Secondary-Copy, which is being hosted on other KVM's. [ This can easily be avoided by having periodic snapshots of the Primary-VM ] Currently Available Technologies: --------------------------------- * Kemari: Fault Tolerance Xen source: http://www.xen.org/files/xensummitboston08/tamura_xen_summit_presentation_final.pdf KVM source: http://www.linux-kvm.org/wiki/images/0/0d/0.5.kemari-kvm-forum-2010.pdf Kemari Project: http://www.osrg.net/kemari/ Please leave your valuable feedback for this. Sincerely, Anand Nande --------------000505070909080701090108 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit KFT (KVM Faul Tolernace):
========================

How it works:
-------------
* Provide Continuous availability to Mission Critical Applications with a 'Always Available' environment preventing any downtime or Data-loss in the event of server-failures.
* RFT when enabled for a Virtual Machine creates a secondary copy of it on another physical server running KVM.
* The two copies are continuously synchronized by replaying the contents of the Memory from the primary VM to the Secondary (copy) VM. The Primary and the Secondary VM access the same storage device (shared storage) between the 2 servers.
* For example: If a user is playing a Youtube video on VM1, and the KVM Guest VM-1 crashes (due to some reason), The Secondary-slave copy becomes Active and promotes itself as Primary immediately when the vdsm-agent (communicating between the KVM-Host and the KVM-GuestVM-1) detects the server crash. This leads to creation of another secondary copy on the Next available physical server (obviously sharing the same storage with the now-active Primary-VM).
* Thus the GuestVM-2 (which was the secondary copy before the crash) ---> is now known as VM-1 (and the new secondary copy on the newly available server is now known as VM-2).
* This can be achieved over qemu+ssh connections being managed by a single virt-manager as well.

Advantages:
-----------
* Zero Downtime: Fault Tolerance provides absolutely no downtime as that comapred to HA wherein the VM restarts completely on a different server.
* Immunity from Server crashes/panic/OOM situations.
* Extremely Fast Disaster Recover Mechanism.

Disadvantages:
--------------
* If a panic/crash takes place on the GuestVM being hosted on the KVM, This will be replicated on its Secondary-Copy, which is being hosted on other KVM's.
  [ This can easily be avoided by having periodic snapshots of the Primary-VM ]

Currently Available Technologies:
---------------------------------
* Kemari: Fault Tolerance

Xen source: http://www.xen.org/files/xensummitboston08/tamura_xen_summit_presentation_final.pdf
KVM source: http://www.linux-kvm.org/wiki/images/0/0d/0.5.kemari-kvm-forum-2010.pdf
Kemari Project: http://www.osrg.net/kemari/

Please leave your valuable feedback for this.
   
Sincerely,
Anand Nande
             
--------------000505070909080701090108-- --===============1218477499== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Xen-users mailing list Xen-users@lists.xensource.com http://lists.xensource.com/xen-users --===============1218477499==-- From xen-devel-bounces@lists.xensource.com Thu Sep 15 14:24:48 2011 Return-path: Envelope-to: www-data@lists.xensource.com Delivery-date: Thu, 15 Sep 2011 14:24:48 -0700 Received: from localhost ([127.0.0.1] helo=lists.colo.xensource.com) by lists.xensource.com with esmtp (Exim 4.43) id 1R4JQN-0004gz-W4; Thu, 15 Sep 2011 14:24:48 -0700 Received: from mail174.messagelabs.com ([85.158.138.51]) by lists.xensource.com with esmtp (Exim 4.43) id 1R4Ats-0004ba-39 for xen-devel@lists.xensource.com; Thu, 15 Sep 2011 05:18:40 -0700 X-Env-Sender: amscanne@gridcentric.ca X-Msg-Ref: server-8.tower-174.messagelabs.com!1316089115!17846116!1 X-Originating-IP: [209.85.161.43] X-StarScan-Version: 6.4.1; banners=-,-,- X-VirusChecked: Checked Received: (qmail 320 invoked from network); 15 Sep 2011 12:18:36 -0000 Received: from mail-fx0-f43.google.com (HELO mail-fx0-f43.google.com) (209.85.161.43) by server-8.tower-174.messagelabs.com with RC4-SHA encrypted SMTP; 15 Sep 2011 12:18:36 -0000 Received: by fxh19 with SMTP id 19so705427fxh.30 for ; Thu, 15 Sep 2011 05:18:35 -0700 (PDT) Received: by 10.223.22.150 with SMTP id n22mr97311fab.110.1316089083114; Thu, 15 Sep 2011 05:18:03 -0700 (PDT) MIME-Version: 1.0 Received: by 10.223.95.198 with HTTP; Thu, 15 Sep 2011 05:17:43 -0700 (PDT) From: Adin Scannell Date: Thu, 15 Sep 2011 12:17:43 +0000 X-Google-Sender-Auth: HezEVLFOkT5RYXnqZVGOTaMAeto Message-ID: To: xen-devel@lists.xensource.com Content-Type: multipart/mixed; boundary=00151747b4184ab5d004acf9de3e X-Mailman-Approved-At: Thu, 15 Sep 2011 14:18:42 -0700 Subject: [Xen-devel] [PATCH] expose shared page count through xenlight X-BeenThere: xen-devel@lists.xensource.com X-Mailman-Version: 2.1.5 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xensource.com Errors-To: xen-devel-bounces@lists.xensource.com --00151747b4184ab5d004acf9de3e Content-Type: text/plain; charset=ISO-8859-1 Attached is a simple patch to expose the shared page information through libxl and xl. Cheers, -Adin --00151747b4184ab5d004acf9de3e Content-Type: application/octet-stream; name="libxl-shared-pages.patch" Content-Disposition: attachment; filename="libxl-shared-pages.patch" Content-Transfer-Encoding: base64 X-Attachment-Id: f_gslop9lx0 IyBIRyBjaGFuZ2VzZXQgcGF0Y2gKIyBVc2VyIEFkaW4gU2Nhbm5lbGwgPGFkaW5Ac2Nhbm5lbGwu Y2E+CiMgRGF0ZSAxMzE2MDg2MTY3IDE0NDAwCiMgTm9kZSBJRCAyYTVlNTdlMmEzZDIxMmU3Y2M4 ODhiODczMDFlNWI4ODhmOTUxNGQxCiMgUGFyZW50ICAyOGUxYThiNmM5MzQzMmQ4MGMxMTY2ZmFm MmM1NDI5NDg5YmYxNmYyCkV4cG9zaW5nIG51bWJlciBvZiBzaGFyZWQgcGFnZXMgdGhyb3VnaCBs aWJ4bCBhbmQgeGwgbGlzdC4KCmRpZmYgLXIgMjhlMWE4YjZjOTM0IC1yIDJhNWU1N2UyYTNkMiB0 b29scy9saWJ4bC9saWJ4bC5jCi0tLSBhL3Rvb2xzL2xpYnhsL2xpYnhsLmMKKysrIGIvdG9vbHMv bGlieGwvbGlieGwuYwpAQCAtMzM3LDYgKzMzNyw3IEBAIHN0YXRpYyB2b2lkIHhjaW5mbzJ4bGlu Zm8oY29uc3QgeGNfZG9tYWkKICAgICAgICAgeGxpbmZvLT5zaHV0ZG93bl9yZWFzb24gID0gfjA7 CiAKICAgICB4bGluZm8tPmN1cnJlbnRfbWVta2IgPSBQQUdFX1RPX01FTUtCKHhjaW5mby0+dG90 X3BhZ2VzKTsKKyAgICB4bGluZm8tPnNoYXJlZF9tZW1rYiA9IFBBR0VfVE9fTUVNS0IoeGNpbmZv LT5zaHJfcGFnZXMpOwogICAgIHhsaW5mby0+bWF4X21lbWtiID0gUEFHRV9UT19NRU1LQih4Y2lu Zm8tPm1heF9wYWdlcyk7CiAgICAgeGxpbmZvLT5jcHVfdGltZSA9IHhjaW5mby0+Y3B1X3RpbWU7 CiAgICAgeGxpbmZvLT52Y3B1X21heF9pZCA9IHhjaW5mby0+bWF4X3ZjcHVfaWQ7CmRpZmYgLXIg MjhlMWE4YjZjOTM0IC1yIDJhNWU1N2UyYTNkMiB0b29scy9saWJ4bC9saWJ4bC5pZGwKLS0tIGEv dG9vbHMvbGlieGwvbGlieGwuaWRsCisrKyBiL3Rvb2xzL2xpYnhsL2xpYnhsLmlkbApAQCAtNDAs NiArNDAsNyBAQCBsaWJ4bF9kb21pbmZvID0gU3RydWN0KCJkb21pbmZvIixbCiBPdGhlcndpc2Ug c2V0IHRvIGEgdmFsdWUgZ3VhcmFudGVlZCBub3QgdG8gY2xhc2ggd2l0aCBhbnkgdmFsaWQKIFNI VVRET1dOXyogY29uc3RhbnQuIiIiKSwKICAgICAoImN1cnJlbnRfbWVta2IiLCAgIHVpbnQ2NCks CisgICAgKCJzaGFyZWRfbWVta2IiLCB1aW50NjQpLAogICAgICgibWF4X21lbWtiIiwgICB1aW50 NjQpLAogICAgICgiY3B1X3RpbWUiLCAgICB1aW50NjQpLAogICAgICgidmNwdV9tYXhfaWQiLCB1 aW50MzIpLApkaWZmIC1yIDI4ZTFhOGI2YzkzNCAtciAyYTVlNTdlMmEzZDIgdG9vbHMvbGlieGwv eGxfY21kaW1wbC5jCi0tLSBhL3Rvb2xzL2xpYnhsL3hsX2NtZGltcGwuYworKysgYi90b29scy9s aWJ4bC94bF9jbWRpbXBsLmMKQEAgLTIzMDksNyArMjMwOSw3IEBAIHN0YXRpYyB2b2lkIGxpc3Rf ZG9tYWlucyhpbnQgdmVyYm9zZSwgY28KICAgICBpbnQgaTsKICAgICBzdGF0aWMgY29uc3QgY2hh ciBzaHV0ZG93bl9yZWFzb25fbGV0dGVyc1tdPSAiLXJzY3ciOwogCi0gICAgcHJpbnRmKCJOYW1l ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIElEICAgTWVtIFZDUFVzXHRT dGF0ZVx0VGltZShzKSIpOworICAgIHByaW50ZigiTmFtZSAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICBJRCAgIE1lbSAgIFNociBWQ1BVcyAgICAgU3RhdGUgICAgIFRpbWUo cykiKTsKICAgICBpZiAodmVyYm9zZSkgcHJpbnRmKCIgICBVVUlEICAgICAgICAgICAgICAgICAg ICAgICAgICAgIFJlYXNvbi1Db2RlIik7CiAgICAgcHJpbnRmKCJcbiIpOwogICAgIGZvciAoaSA9 IDA7IGkgPCBuYl9kb21haW47IGkrKykgewpAQCAtMjMxNywxMCArMjMxNywxMSBAQCBzdGF0aWMg dm9pZCBsaXN0X2RvbWFpbnMoaW50IHZlcmJvc2UsIGNvCiAgICAgICAgIHVuc2lnbmVkIHNodXRk b3duX3JlYXNvbjsKICAgICAgICAgZG9tbmFtZSA9IGxpYnhsX2RvbWlkX3RvX25hbWUoJmN0eCwg aW5mb1tpXS5kb21pZCk7CiAgICAgICAgIHNodXRkb3duX3JlYXNvbiA9IGluZm9baV0uc2h1dGRv d24gPyBpbmZvW2ldLnNodXRkb3duX3JlYXNvbiA6IDA7Ci0gICAgICAgIHByaW50ZigiJS00MHMg JTVkICU1bHUgJTVkICAgICAlYyVjJWMlYyVjJWMgICU4LjFmIiwKKyAgICAgICAgcHJpbnRmKCIl LTQwcyAlNWQgJTVsdSAlNWx1ICU1ZCAgICAgJWMlYyVjJWMlYyVjICAlOC4xZiIsCiAgICAgICAg ICAgICAgICAgZG9tbmFtZSwKICAgICAgICAgICAgICAgICBpbmZvW2ldLmRvbWlkLAogICAgICAg ICAgICAgICAgICh1bnNpZ25lZCBsb25nKSAoaW5mb1tpXS5jdXJyZW50X21lbWtiIC8gMTAyNCks CisgICAgICAgICAgICAgICAgKHVuc2lnbmVkIGxvbmcpIChpbmZvW2ldLnNoYXJlZF9tZW1rYiAv IDEwMjQpLAogICAgICAgICAgICAgICAgIGluZm9baV0udmNwdV9vbmxpbmUsCiAgICAgICAgICAg ICAgICAgaW5mb1tpXS5ydW5uaW5nID8gJ3InIDogJy0nLAogICAgICAgICAgICAgICAgIGluZm9b aV0uYmxvY2tlZCA/ICdiJyA6ICctJywK --00151747b4184ab5d004acf9de3e Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel --00151747b4184ab5d004acf9de3e-- From xen-devel-bounces@lists.xensource.com Thu Sep 15 14:30:54 2011 Return-path: Envelope-to: www-data@lists.xensource.com Delivery-date: Thu, 15 Sep 2011 14:30:54 -0700 Received: from localhost ([127.0.0.1] helo=lists.colo.xensource.com) by lists.xensource.com with esmtp (Exim 4.43) id 1R4JWI-00068R-PP; Thu, 15 Sep 2011 14:30:54 -0700 Received: from mail216.messagelabs.com ([85.158.143.99]) by lists.xensource.com with esmtp (Exim 4.43) id 1R4JVu-0005ws-Vl for xen-devel@lists.xensource.com; Thu, 15 Sep 2011 14:30:31 -0700 X-Env-Sender: m.a.young@durham.ac.uk X-Msg-Ref: server-9.tower-216.messagelabs.com!1316122227!18443415!1 X-Originating-IP: [129.234.248.2] X-StarScan-Version: 6.4.1; banners=-,-,- X-VirusChecked: Checked Received: (qmail 6291 invoked from network); 15 Sep 2011 21:30:28 -0000 Received: from hermes2.dur.ac.uk (HELO hermes2.dur.ac.uk) (129.234.248.2) by server-9.tower-216.messagelabs.com with DHE-RSA-AES256-SHA encrypted SMTP; 15 Sep 2011 21:30:28 -0000 Received: from smtphost2.dur.ac.uk (smtphost2.dur.ac.uk [129.234.252.2]) by hermes2.dur.ac.uk (8.13.8/8.13.7) with ESMTP id p8FLU8NU005228; Thu, 15 Sep 2011 22:30:12 +0100 Received: from vega2.dur.ac.uk (vega2.dur.ac.uk [129.234.250.130]) by smtphost2.dur.ac.uk (8.13.8/8.13.7) with ESMTP id p8FLTpFK010520 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 15 Sep 2011 22:29:51 +0100 Received: from vega2.dur.ac.uk (localhost [127.0.0.1]) by vega2.dur.ac.uk (8.14.4/8.11.1) with ESMTP id p8FLTpRf003306; Thu, 15 Sep 2011 22:29:51 +0100 Received: from localhost (dcl0may@localhost) by vega2.dur.ac.uk (8.14.4/8.14.4/Submit) with ESMTP id p8FLToL4003301; Thu, 15 Sep 2011 22:29:50 +0100 Date: Thu, 15 Sep 2011 22:29:50 +0100 (BST) From: M A Young To: Konrad Rzeszutek Wilk In-Reply-To: <20110915154621.GA21580@phenom.oracle.com> Message-ID: References: <20110915154621.GA21580@phenom.oracle.com> User-Agent: Alpine 2.02 (LFD 1266 2009-07-14) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-DurhamAcUk-MailScanner: Found to be clean, Found to be clean X-DurhamAcUk-MailScanner-ID: p8FLU8NU005228 Cc: xen-devel@lists.xensource.com Subject: [Xen-devel] Re: F16, yum install xen, run grub2 or grubby as needed? X-BeenThere: xen-devel@lists.xensource.com X-Mailman-Version: 2.1.5 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xensource.com Errors-To: xen-devel-bounces@lists.xensource.com On Thu, 15 Sep 2011, Konrad Rzeszutek Wilk wrote: > Hey Michael, > > I was playing today with https://admin.fedoraproject.org/updates/grubby-8.2-1.fc16?_csrf_token=014c2b18c3b6e843699e9ef1e56cf9726c5c4fc2 > and https://admin.fedoraproject.org/updates/grub2-1.99-6.fc16 which make the grub.cfg have the > correct entries of Xen and Linux. > > And realized that I had to manually do: > > grub2-mkconfig > /boot/grub2/grub.cfg > > which ends up doing the new stanza.. but in some sense I think > it makes senee for the Xen script to actually call this. > > Thoughts? It probably makes sense to have a post-install/post-uninstall script in the xen-hypervisor RPM to run this. The updated grub2 creates a set of entries for each of xen-4.1.1.gz and its two symbolic links xen-4.1.gz and xen.gz which is a bit untidy, so perhaps it makes sense to remove the symbolic links. Michael Young _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel From xen-devel-bounces@lists.xensource.com Thu Sep 15 14:38:05 2011 Return-path: Envelope-to: www-data@lists.xensource.com Delivery-date: Thu, 15 Sep 2011 14:38:05 -0700 Received: from localhost ([127.0.0.1] helo=lists.colo.xensource.com) by lists.xensource.com with esmtp (Exim 4.43) id 1R4JdF-0007RG-Qf; Thu, 15 Sep 2011 14:38:05 -0700 Received: from mail216.messagelabs.com ([85.158.143.99]) by lists.xensource.com with esmtp (Exim 4.43) id 1R4Jcp-0007Ea-M8 for xen-devel@lists.xensource.com; Thu, 15 Sep 2011 14:37:40 -0700 X-Env-Sender: jeremy@goop.org X-Msg-Ref: server-11.tower-216.messagelabs.com!1316122655!10857967!1 X-Originating-IP: [74.207.240.146] X-StarScan-Version: 6.4.1; banners=-,-,- X-VirusChecked: Checked Received: (qmail 20629 invoked from network); 15 Sep 2011 21:37:36 -0000 Received: from claw.goop.org (HELO claw.goop.org) (74.207.240.146) by server-11.tower-216.messagelabs.com with DHE-RSA-AES256-SHA encrypted SMTP; 15 Sep 2011 21:37:36 -0000 Received: from saboo.goop.org (unknown [IPv6:2001:470:1f05:899:28a7:d1ff:fe66:463]) (Authenticated sender: smtp-saboo) by claw.goop.org (Postfix) with ESMTPSA id 471A98905; Thu, 15 Sep 2011 14:37:34 -0700 (PDT) Received: from saboo.goop.org (localhost [IPv6:::1]) by saboo.goop.org (Postfix) with ESMTP id 0F6712098C; Thu, 15 Sep 2011 14:37:28 -0700 (PDT) Message-ID: <4E727017.4030001@goop.org> Date: Thu, 15 Sep 2011 14:37:27 -0700 From: Jeremy Fitzhardinge User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:6.0.2) Gecko/20110906 Thunderbird/6.0.2 MIME-Version: 1.0 To: David Vrabel References: <1316090411-22608-1-git-send-email-david.vrabel@citrix.com> In-Reply-To: <1316090411-22608-1-git-send-email-david.vrabel@citrix.com> X-Enigmail-Version: 1.3.1 Content-Type: text/plain; charset=ISO-8859-15 Content-Transfer-Encoding: 7bit Cc: Andrew Morton , xen-devel@lists.xensource.com, linux-kernel@vger.kernel.org, Konrad Rzeszutek Wilk Subject: [Xen-devel] Re: [PATCH 0/6] xen: don't call vmalloc_sync_all() when mapping foreign pages X-BeenThere: xen-devel@lists.xensource.com X-Mailman-Version: 2.1.5 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xensource.com Errors-To: xen-devel-bounces@lists.xensource.com On 09/15/2011 05:40 AM, David Vrabel wrote: > This set of pages avoids the need to call vmalloc_sync_all() when > mapping foreign pages. Two new functions are adding for mapping > foreign pages onto RAM pages instead of vmalloc space. > > This does waste a page of RAM for each mapped page. In the future a > ballooned page could be used instead (once the API for getting a > ballooned page with the right GFP flags is available). You can allocate a pfn, free ("balloon out") the underlying mfn, and replace it with a granted page; it doesn't need any particular new infrastructure. But that said, if you want to allocate virtual addresses for mapping granted pages, then alloc_vm_area() is the right thing to use. You need to make sure you touch the pages from within the kernel before passing those addresses to a hypercall to make sure the mappings are established within the current task (possibly within a no-preempt region to guarantee that nothing odd happens). Or alternatively, you could switch the current pagetable to init_mm for the hypercall (if it isn't already) - since that's the reference pagetable - assuming you're not passing usermode virtual addresses to the hypercall. This series is relying on regular ram mappings are already synced to all tasks, but I'm not sure that's necessarily guaranteed (for example, if you hotplug new memory into the domain, the new pages won't be mapped into every mm unless they're synced). J _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel From xen-devel-bounces@lists.xensource.com Thu Sep 15 17:34:49 2011 Return-path: Envelope-to: www-data@lists.xensource.com Delivery-date: Thu, 15 Sep 2011 17:34:49 -0700 Received: from localhost ([127.0.0.1] helo=lists.colo.xensource.com) by lists.xensource.com with esmtp (Exim 4.43) id 1R4MOH-0003Ga-LG; Thu, 15 Sep 2011 17:34:49 -0700 Received: from mail21.messagelabs.com ([85.158.143.35]) by lists.xensource.com with esmtp (Exim 4.43) id 1R4MNE-00033h-RO for xen-devel@lists.xensource.com; Thu, 15 Sep 2011 17:33:45 -0700 X-Env-Sender: jeremy@goop.org X-Msg-Ref: server-6.tower-21.messagelabs.com!1316133200!38426022!1 X-Originating-IP: [74.207.240.146] X-StarScan-Version: 6.4.1; banners=-,-,- X-VirusChecked: Checked Received: (qmail 29004 invoked from network); 16 Sep 2011 00:33:22 -0000 Received: from claw.goop.org (HELO claw.goop.org) (74.207.240.146) by server-6.tower-21.messagelabs.com with DHE-RSA-AES256-SHA encrypted SMTP; 16 Sep 2011 00:33:22 -0000 Received: from saboo.goop.org (unknown [IPv6:2001:470:1f05:899:28a7:d1ff:fe66:463]) (Authenticated sender: smtp-saboo) by claw.goop.org (Postfix) with ESMTPSA id 1322F8F67; Thu, 15 Sep 2011 17:33:39 -0700 (PDT) Received: from saboo.goop.org (localhost [IPv6:::1]) by saboo.goop.org (Postfix) with ESMTP id A9A42201D1; Thu, 15 Sep 2011 17:33:36 -0700 (PDT) Message-ID: <4E729960.2080101@goop.org> Date: Thu, 15 Sep 2011 17:33:36 -0700 From: Jeremy Fitzhardinge User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:6.0.2) Gecko/20110906 Thunderbird/6.0.2 MIME-Version: 1.0 To: Ian Campbell X-Enigmail-Version: 1.3.1 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Cc: "xen-devel@lists.xensource.com" , Ian Jackson , Stefano Stabellini Subject: [Xen-devel] xl create crash when using stub domains X-BeenThere: xen-devel@lists.xensource.com X-Mailman-Version: 2.1.5 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xensource.com Errors-To: xen-devel-bounces@lists.xensource.com When I create an HVM domain with stubdom enabled, it crashes at: (gdb) run create -c /etc/xen/f14hv64 vcpus=4 xen_platform_pci=0 'boot="d"' Starting program: /usr/sbin/xl create -c /etc/xen/f14hv64 vcpus=4 xen_platform_pci=0 'boot="d"' [Thread debugging using libthread_db enabled] Parsing config file /etc/xen/f14hv64 xc: info: VIRTUAL MEMORY ARRANGEMENT: Loader: 0000000000100000->000000000017b9ec TOTAL: 0000000000000000->000000003f800000 ENTRY ADDRESS: 0000000000100000 xc: info: PHYSICAL MEMORY ALLOCATION: 4KB PAGES: 0x0000000000000200 2MB PAGES: 0x00000000000001fb 1GB PAGES: 0x0000000000000000 xc: error: panic: xc_dom_bzimageloader.c:588: xc_dom_probe_bzimage_kernel: kernel is not a bzImage: Invalid kernel Detaching after fork from child process 26888. [New Thread 0x7ffff7342700 (LWP 26889)] [Thread 0x7ffff7342700 (LWP 26889) exited] [New Thread 0x7ffff7342700 (LWP 26921)] Program received signal SIGSEGV, Segmentation fault. 0x00007ffff7bbbec5 in libxl__wait_for_device_model (gc=0x7fffffffdbb0, domid=22, state=0x7ffff7bc1b8c "running", starting=0x623760, check_callback=0, check_callback_userdata=0x0) at libxl_device.c:555 555 if (starting && starting->for_spawn->fd > xs_fileno(xsh)) (gdb) bt #0 0x00007ffff7bbbec5 in libxl__wait_for_device_model (gc=0x7fffffffdbb0, domid=22, state=0x7ffff7bc1b8c "running", starting=0x623760, check_callback=0, check_callback_userdata=0x0) at libxl_device.c:555 #1 0x00007ffff7bb37b5 in libxl__confirm_device_model_startup ( gc=0x7fffffffdbb0, starting=0x623760) at libxl_dm.c:922 #2 0x00007ffff7bb229b in do_domain_create (gc=0x7fffffffdbb0, d_config=0x7fffffffde30, cb=0x40a053 , priv=0x7fffffffde14, domid_out=0x619ed8, restore_fd=-1) at libxl_create.c:576 #3 0x00007ffff7bb2481 in libxl_domain_create_new (ctx=, d_config=, cb=, priv=, domid=) at libxl_create.c:626 #4 0x0000000000409424 in create_domain (dom_info=0x7fffffffe0c0) at xl_cmdimpl.c:1520 #5 0x000000000040ceef in main_create (argc=6, argv=0x7fffffffe6b0) at xl_cmdimpl.c:3188 #6 0x000000000040501b in main (argc=6, argv=0x7fffffffe6b0) at xl.c:151 The stubdom seems fine, and when I unpause the main domain it seems to work fine. J _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel From xen-devel-bounces@lists.xensource.com Thu Sep 15 17:47:41 2011 Return-path: Envelope-to: www-data@lists.xensource.com Delivery-date: Thu, 15 Sep 2011 17:47:41 -0700 Received: from localhost ([127.0.0.1] helo=lists.colo.xensource.com) by lists.xensource.com with esmtp (Exim 4.43) id 1R4Maj-0003zv-NH; Thu, 15 Sep 2011 17:47:41 -0700 Received: from mail182.messagelabs.com ([85.158.139.83]) by lists.xensource.com with esmtp (Exim 4.43) id 1R4MZz-0003nC-VV for xen-devel@lists.xensource.com; Thu, 15 Sep 2011 17:46:56 -0700 X-Env-Sender: maillists.shan@gmail.com X-Msg-Ref: server-11.tower-182.messagelabs.com!1316134012!18525132!1 X-Originating-IP: [74.125.82.176] X-StarScan-Version: 6.4.1; banners=-,-,- X-VirusChecked: Checked Received: (qmail 23249 invoked from network); 16 Sep 2011 00:46:52 -0000 Received: from mail-wy0-f176.google.com (HELO mail-wy0-f176.google.com) (74.125.82.176) by server-11.tower-182.messagelabs.com with RC4-SHA encrypted SMTP; 16 Sep 2011 00:46:52 -0000 Received: by wyg10 with SMTP id 10so1980569wyg.7 for ; Thu, 15 Sep 2011 17:46:52 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:date:message-id:subject:from:to:content-type; bh=WPtrzp3EiqZ+A90P9YT/NMCKdQgnV92m2HsYsdrwdDs=; b=Jc7PBWAz+66wdOdJUv9xr8pA3dCj+ou7orleA4lbrDc65AhbWeOUG8B3q07Qg/0oMo HN+jALaoFB0PBRy+ilPfdP21TFYraSQ5DfCdBk1uUkF6NZ76JJmUmQCeekJnvn9CO3mS J9TIyWnN/RZSxsUn6Pf7FzGjBJZiTXI7n20aI= MIME-Version: 1.0 Received: by 10.227.127.138 with SMTP id g10mr711906wbs.31.1316134012467; Thu, 15 Sep 2011 17:46:52 -0700 (PDT) Received: by 10.227.143.204 with HTTP; Thu, 15 Sep 2011 17:46:52 -0700 (PDT) Date: Fri, 16 Sep 2011 08:46:52 +0800 Message-ID: From: Haitao Shan To: Keir Fraser , xen-devel@lists.xensource.com Content-Type: multipart/mixed; boundary=0014853941084a3a8c04ad0454ee Cc: Subject: [Xen-devel] [PATCH] Fix PV CPUID virtualization of XSave X-BeenThere: xen-devel@lists.xensource.com X-Mailman-Version: 2.1.5 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xensource.com Errors-To: xen-devel-bounces@lists.xensource.com --0014853941084a3a8c04ad0454ee Content-Type: text/plain; charset=ISO-8859-1 Hi, Keir, The patch will fix XSave CPUID virtualization for PV guests. The XSave area size returned by CPUID leaf D is changed dynamically depending on the XCR0. Tools/libxc only assigns a static value. The fix will adjust xsave area size during runtime. Note: This fix is already in HVM cpuid virtualization. And Dom0 is not affected, either. Signed-off-by: Shan Haitao Shan Haitao diff -r 5fe770c8a8a3 xen/arch/x86/traps.c --- a/xen/arch/x86/traps.c Tue Sep 06 15:49:40 2011 +0100 +++ b/xen/arch/x86/traps.c Wed Sep 07 02:09:12 2011 +0800 @@ -770,6 +770,30 @@ static void pv_cpuid(struct cpu_user_reg { if ( !cpuid_hypervisor_leaves(a, c, &a, &b, &c, &d) ) domain_cpuid(current->domain, a, c, &a, &b, &c, &d); + + switch ( a ) + { + case 0xd: + { + unsigned int sub_leaf, _eax, _ebx, _ecx, _edx; + /* EBX value of main leaf 0 depends on enabled xsave features */ + if ( c == 0 && current->arch.xcr0 ) + { + /* reset EBX to default value first */ + b = XSTATE_AREA_MIN_SIZE; + for ( sub_leaf = 2; sub_leaf < 64; sub_leaf++ ) + { + if ( !(current->arch.xcr0 & (1ULL << sub_leaf)) ) + continue; + domain_cpuid(current->domain, a, c, &_eax, &_ebx, &_ecx, + &_edx); + if ( (_eax + _ebx) > b ) + b = _eax + _ebx; + } + } + break; + } + } goto out; } --0014853941084a3a8c04ad0454ee Content-Type: application/octet-stream; name="pv_xsave_cpuid_fix.patch" Content-Disposition: attachment; filename="pv_xsave_cpuid_fix.patch" Content-Transfer-Encoding: base64 X-Attachment-Id: f_gsmfznd40 ZGlmZiAtciA1ZmU3NzBjOGE4YTMgeGVuL2FyY2gveDg2L3RyYXBzLmMKLS0tIGEveGVuL2FyY2gv eDg2L3RyYXBzLmMJVHVlIFNlcCAwNiAxNTo0OTo0MCAyMDExICswMTAwCisrKyBiL3hlbi9hcmNo L3g4Ni90cmFwcy5jCVdlZCBTZXAgMDcgMDI6MDk6MTIgMjAxMSArMDgwMApAQCAtNzcwLDYgKzc3 MCwzMCBAQCBzdGF0aWMgdm9pZCBwdl9jcHVpZChzdHJ1Y3QgY3B1X3VzZXJfcmVnCiAgICAgewog ICAgICAgICBpZiAoICFjcHVpZF9oeXBlcnZpc29yX2xlYXZlcyhhLCBjLCAmYSwgJmIsICZjLCAm ZCkgKQogICAgICAgICAgICAgZG9tYWluX2NwdWlkKGN1cnJlbnQtPmRvbWFpbiwgYSwgYywgJmEs ICZiLCAmYywgJmQpOworCisgICAgICAgIHN3aXRjaCAoIGEgKQorICAgICAgICB7CisgICAgICAg IGNhc2UgMHhkOgorICAgICAgICB7CisgICAgICAgICAgICB1bnNpZ25lZCBpbnQgc3ViX2xlYWYs IF9lYXgsIF9lYngsIF9lY3gsIF9lZHg7CisgICAgICAgICAgICAvKiBFQlggdmFsdWUgb2YgbWFp biBsZWFmIDAgZGVwZW5kcyBvbiBlbmFibGVkIHhzYXZlIGZlYXR1cmVzICovCisgICAgICAgICAg ICBpZiAoIGMgPT0gMCAmJiBjdXJyZW50LT5hcmNoLnhjcjAgKQorICAgICAgICAgICAgeworICAg ICAgICAgICAgICAgIC8qIHJlc2V0IEVCWCB0byBkZWZhdWx0IHZhbHVlIGZpcnN0ICovCisgICAg ICAgICAgICAgICAgYiA9IFhTVEFURV9BUkVBX01JTl9TSVpFOworICAgICAgICAgICAgICAgIGZv ciAoIHN1Yl9sZWFmID0gMjsgc3ViX2xlYWYgPCA2NDsgc3ViX2xlYWYrKyApCisgICAgICAgICAg ICAgICAgeworICAgICAgICAgICAgICAgICAgICBpZiAoICEoY3VycmVudC0+YXJjaC54Y3IwICYg KDFVTEwgPDwgc3ViX2xlYWYpKSApCisgICAgICAgICAgICAgICAgICAgICAgICBjb250aW51ZTsK KyAgICAgICAgICAgICAgICAgICAgZG9tYWluX2NwdWlkKGN1cnJlbnQtPmRvbWFpbiwgYSwgYywg Jl9lYXgsICZfZWJ4LCAmX2VjeCwKKyAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICZf ZWR4KTsKKyAgICAgICAgICAgICAgICAgICAgaWYgKCAoX2VheCArIF9lYngpID4gYiApCisgICAg ICAgICAgICAgICAgICAgICAgICBiID0gX2VheCArIF9lYng7CisgICAgICAgICAgICAgICAgfQor ICAgICAgICAgICAgfQorICAgICAgICBicmVhazsKKyAgICAgICAgfQorICAgICAgICB9CiAgICAg ICAgIGdvdG8gb3V0OwogICAgIH0KIAo= --0014853941084a3a8c04ad0454ee Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel --0014853941084a3a8c04ad0454ee-- From xen-devel-bounces@lists.xensource.com Thu Sep 15 18:51:52 2011 Return-path: Envelope-to: www-data@lists.xensource.com Delivery-date: Thu, 15 Sep 2011 18:51:52 -0700 Received: from localhost ([127.0.0.1] helo=lists.colo.xensource.com) by lists.xensource.com with esmtp (Exim 4.43) id 1R4Naq-0005Qs-48; Thu, 15 Sep 2011 18:51:52 -0700 Received: from mail21.messagelabs.com ([85.158.143.35]) by lists.xensource.com with esmtp (Exim 4.43) id 1R4NZp-0005Ec-36 for xen-devel@lists.xensource.com; Thu, 15 Sep 2011 18:50:49 -0700 X-Env-Sender: Ian.Jackson@eu.citrix.com X-Msg-Ref: server-6.tower-21.messagelabs.com!1316137826!38429330!1 X-Originating-IP: [62.200.22.115] X-StarScan-Version: 6.4.1; banners=-,-,- X-VirusChecked: Checked Received: (qmail 30174 invoked from network); 16 Sep 2011 01:50:26 -0000 Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115) by server-6.tower-21.messagelabs.com with RC4-SHA encrypted SMTP; 16 Sep 2011 01:50:26 -0000 X-IronPort-AV: E=Sophos;i="4.68,391,1312156800"; d="scan'208";a="7873780" Received: from lonpmailmx01.citrite.net ([10.30.203.162]) by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5; 16 Sep 2011 01:50:45 +0000 Received: from woking.xci-test.com (10.80.248.135) by smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id 8.3.137.0; Fri, 16 Sep 2011 02:50:45 +0100 Received: from osstest by woking.xci-test.com with local (Exim 4.69) (envelope-from ) id 1R4NZl-0006f2-2B; Fri, 16 Sep 2011 02:50:45 +0100 To: Message-ID: From: xen.org Date: Fri, 16 Sep 2011 02:50:45 +0100 MIME-Version: 1.0 Content-Type: text/plain Cc: ian.jackson@eu.citrix.com Subject: [Xen-devel] [xen-unstable test] 8948: tolerable FAIL X-BeenThere: xen-devel@lists.xensource.com X-Mailman-Version: 2.1.5 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xensource.com Errors-To: xen-devel-bounces@lists.xensource.com flight 8948 xen-unstable real [real] http://www.chiark.greenend.org.uk/~xensrcts/logs/8948/ Failures :-/ but no regressions. Tests which did not succeed, but are not blocking, including regressions (tests previously passed) regarded as allowable: test-amd64-amd64-xl-pcipt-intel 1 xen-build-check(1) blocked n/a test-amd64-i386-pair 1 xen-build-check(1) blocked n/a build-amd64-pvops 4 kernel-build fail like 8945 test-amd64-i386-rhel6hvm-intel 1 xen-build-check(1) blocked n/a test-i386-i386-pv 1 xen-build-check(1) blocked n/a test-amd64-i386-pv 1 xen-build-check(1) blocked n/a test-amd64-i386-xl-multivcpu 1 xen-build-check(1) blocked n/a test-amd64-amd64-pv 1 xen-build-check(1) blocked n/a test-i386-i386-xl 1 xen-build-check(1) blocked n/a test-amd64-i386-xl 1 xen-build-check(1) blocked n/a test-amd64-i386-xl-credit2 1 xen-build-check(1) blocked n/a test-amd64-i386-rhel6hvm-amd 1 xen-build-check(1) blocked n/a test-amd64-amd64-pair 1 xen-build-check(1) blocked n/a test-i386-i386-pair 1 xen-build-check(1) blocked n/a build-i386-pvops 4 kernel-build fail like 8945 test-amd64-amd64-win 1 xen-build-check(1) blocked n/a test-amd64-i386-win 1 xen-build-check(1) blocked n/a test-amd64-amd64-xl-sedf 1 xen-build-check(1) blocked n/a test-amd64-i386-win-vcpus1 1 xen-build-check(1) blocked n/a test-amd64-i386-xl-win-vcpus1 1 xen-build-check(1) blocked n/a test-amd64-amd64-xl-win 1 xen-build-check(1) blocked n/a test-amd64-amd64-xl 1 xen-build-check(1) blocked n/a test-i386-i386-xl-win 1 xen-build-check(1) blocked n/a test-i386-i386-win 1 xen-build-check(1) blocked n/a version targeted for testing: xen 4815be3af73c baseline version: xen 4815be3af73c jobs: build-amd64 pass build-i386 pass build-amd64-oldkern pass build-i386-oldkern pass build-amd64-pvops fail build-i386-pvops fail test-amd64-amd64-xl blocked test-amd64-i386-xl blocked test-i386-i386-xl blocked test-amd64-i386-rhel6hvm-amd blocked test-amd64-i386-xl-credit2 blocked test-amd64-amd64-xl-pcipt-intel blocked test-amd64-i386-rhel6hvm-intel blocked test-amd64-i386-xl-multivcpu blocked test-amd64-amd64-pair blocked test-amd64-i386-pair blocked test-i386-i386-pair blocked test-amd64-amd64-pv blocked test-amd64-i386-pv blocked test-i386-i386-pv blocked test-amd64-amd64-xl-sedf blocked test-amd64-i386-win-vcpus1 blocked test-amd64-i386-xl-win-vcpus1 blocked test-amd64-amd64-win blocked test-amd64-i386-win blocked test-i386-i386-win blocked test-amd64-amd64-xl-win blocked test-i386-i386-xl-win blocked ------------------------------------------------------------ sg-report-flight on woking.cam.xci-test.com logs: /home/xc_osstest/logs images: /home/xc_osstest/images Logs, config files, etc. are available at http://www.chiark.greenend.org.uk/~xensrcts/logs Test harness code can be found at http://xenbits.xensource.com/gitweb?p=osstest.git;a=summary Published tested tree is already up to date. _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel From xen-devel-bounces@lists.xensource.com Thu Sep 15 19:52:22 2011 Return-path: Envelope-to: www-data@lists.xensource.com Delivery-date: Thu, 15 Sep 2011 19:52:22 -0700 Received: from localhost ([127.0.0.1] helo=lists.colo.xensource.com) by lists.xensource.com with esmtp (Exim 4.43) id 1R4OXO-0006yh-8X; Thu, 15 Sep 2011 19:52:22 -0700 Received: from mail174.messagelabs.com ([85.158.138.51]) by lists.xensource.com with esmtp (Exim 4.43) id 1R4OWW-0006lr-2c; Thu, 15 Sep 2011 19:51:30 -0700 X-Env-Sender: hwang.jinho@gmail.com X-Msg-Ref: server-8.tower-174.messagelabs.com!1316141483!17918622!1 X-Originating-IP: [74.125.83.41] X-StarScan-Version: 6.4.1; banners=-,-,- X-VirusChecked: Checked Received: (qmail 22480 invoked from network); 16 Sep 2011 02:51:24 -0000 Received: from mail-gw0-f41.google.com (HELO mail-gw0-f41.google.com) (74.125.83.41) by server-8.tower-174.messagelabs.com with RC4-SHA encrypted SMTP; 16 Sep 2011 02:51:24 -0000 Received: by gwaa12 with SMTP id a12so3310199gwa.28 for ; Thu, 15 Sep 2011 19:51:23 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:from:date:message-id:subject:to:content-type; bh=9B6l4DrjOKRXyep0eR+/2Q+hbd4EzsV29+WmopWnOeA=; b=ENfuG0ZHCEL9SXz9tTiQ0PCS8YYTJMOWFOEwjtgBvbzNJZ/8p0LNtbzPV+/s7qBF2o DangKrlmm8zi/0aY1bmskt1K2/6P3kenyOhnpH7nyTjRJJgoLJ8Equza0oAP6NnRQYNh tCzH9bKiF8iqgBBd6s3J37eEu+jZ+Hy4pCdJg= Received: by 10.150.63.2 with SMTP id l2mr2084841yba.63.1316141483133; Thu, 15 Sep 2011 19:51:23 -0700 (PDT) MIME-Version: 1.0 Received: by 10.151.154.16 with HTTP; Thu, 15 Sep 2011 19:51:03 -0700 (PDT) From: jinho hwang Date: Thu, 15 Sep 2011 22:51:03 -0400 Message-ID: To: xen-users@lists.xensource.com, xen-devel@lists.xensource.com Cc: Subject: [Xen-devel] [Xen-users] XENBUS: unable to read cpu state X-BeenThere: xen-devel@lists.xensource.com X-Mailman-Version: 2.1.5 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============2131212897==" Sender: xen-devel-bounces@lists.xensource.com Errors-To: xen-devel-bounces@lists.xensource.com --===============2131212897== Content-Type: multipart/alternative; boundary=000e0cd3b27c938a7d04ad061178 --000e0cd3b27c938a7d04ad061178 Content-Type: text/plain; charset=ISO-8859-1 Hi All, Currently, I'm sending too many e-mails because I'm intensively trying to catch up with current xen system. I got new machine, i7 x64 8 processors, but when I install xen hypervisor 4.x.x (tried all) with xen linux 2.32.xx, on booting it shows 8 messages of "XENBUS: unable to read cpu state" and then stop, and doing nothing. I tracked down to the code a little bit before getting in here. It turned out that linux/drivers/xen/xenbus/xenbus_xs.c -> xenbus_scanf -> xenbus_read has problem in my machine. I don't know where to see next. I carefully checked the kernel configuration, but it didn't have problems. Also, I tried with many combinations: xen and kernel. I think it is time to learn how to debug xen from now on. Can anyone help with this? Thank you, Jinho -- Jinho Hwang PhD Student Department of Computer Science The George Washington University Washington, DC 20052 hwang.jinho@gmail.com (email) 276.336.0971 (Cell) 202.994.4875 (fax) 070.8285.6546 (myLg070) --000e0cd3b27c938a7d04ad061178 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable

Hi All,=A0

Currently, I'm sending too= many e-mails because I'm intensively trying to catch up with current x= en system.=A0
I got new machine, i7 x64 8 processors, but when I = install xen hypervisor 4.x.x (tried all) with xen linux 2.32.xx, on booting= it shows 8 messages of "XENBUS: unable to read cpu state" and th= en stop, and doing nothing.=A0
I tracked down to the code a little bit before getting in here. It tur= ned out that linux/drivers/xen/xenbus/xenbus_xs.c -> xenbus_scanf -> = xenbus_read has problem in my machine.=A0
I don't know where = to see next. I carefully checked the kernel configuration, but it didn'= t have problems. Also, I tried with many combinations: xen and kernel. I th= ink it is time to learn how to debug xen from now on.=A0

Can anyone help with this?

Tha= nk you,

Jinho

-- <= br>Jinho Hwang
PhD Student
Department of Computer Science
The Geor= ge Washington University
Washington, DC 20052
hwang.jinh= o@gmail.com (email)
276.336.0971 (Cell)
202.994.4875 (fax)
070= .8285.6546 (myLg070)
--000e0cd3b27c938a7d04ad061178-- --===============2131212897== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel --===============2131212897==-- From xen-devel-bounces@lists.xensource.com Thu Sep 15 23:04:17 2011 Return-path: Envelope-to: www-data@lists.xensource.com Delivery-date: Thu, 15 Sep 2011 23:04:17 -0700 Received: from localhost ([127.0.0.1] helo=lists.colo.xensource.com) by lists.xensource.com with esmtp (Exim 4.43) id 1R4RX6-0003hi-Ua; Thu, 15 Sep 2011 23:04:16 -0700 Received: from mail182.messagelabs.com ([85.158.139.83]) by lists.xensource.com with esmtp (Exim 4.43) id 1R4RWL-0003V6-Ia for xen-devel@lists.xensource.com; Thu, 15 Sep 2011 23:03:29 -0700 X-Env-Sender: Philippe.Simonet@swisscom.com X-Msg-Ref: server-4.tower-182.messagelabs.com!1316153006!18539121!1 X-Originating-IP: [193.222.81.110] X-StarScan-Version: 6.4.1; banners=-,-,- X-VirusChecked: Checked Received: (qmail 1191 invoked from network); 16 Sep 2011 06:03:26 -0000 Received: from outmail110.swisscom.com (HELO mail.swisscom.com) (193.222.81.110) by server-4.tower-182.messagelabs.com with DHE-RSA-AES256-SHA encrypted SMTP; 16 Sep 2011 06:03:26 -0000 Received: by mail.swisscom.com; Fri, 16 Sep 2011 08:03:22 +0200 From: To: , Subject: RE: [Xen-devel] Xen 4 TSC problems Thread-Topic: [Xen-devel] Xen 4 TSC problems Thread-Index: AQHMctqprSt5ec8j8ES+2DGqMTKTYJVN+mkAgACGTYCAAQVDEA== Date: Fri, 16 Sep 2011 06:03:22 +0000 Message-ID: References: <4E6F034B.5040102@bluewin.ch> <20110915082402.GC24888@phenom.oracle.com> <4E7226CB.2020706@goop.org> In-Reply-To: <4E7226CB.2020706@goop.org> Accept-Language: en-US, de-CH Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.65.122.32] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: xen-devel@lists.xensource.com, philippe.simonet@bluewin.ch X-BeenThere: xen-devel@lists.xensource.com X-Mailman-Version: 2.1.5 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xensource.com Errors-To: xen-devel-bounces@lists.xensource.com > -----Original Message----- > From: xen-devel-bounces@lists.xensource.com [mailto:xen-devel- > bounces@lists.xensource.com] On Behalf Of Jeremy Fitzhardinge > Sent: Thursday, September 15, 2011 6:25 PM > To: Konrad Rzeszutek Wilk > Cc: xen-devel@lists.xensource.com; Philippe Simonet > Subject: Re: [Xen-devel] Xen 4 TSC problems >=20 > On 09/15/2011 01:24 AM, Konrad Rzeszutek Wilk wrote: > > On Tue, Sep 13, 2011 at 09:16:27AM +0200, Philippe Simonet wrote: > >> Hi Xen developers > > Lets try this again, this time Cc-ing Jeremy. > >> i just would like to inform you that I have exactly the same problem > >> with Debian squeeze and xen, with > >> 50 seconds time jump on my dom0 and domu. NTP is running on all > >> dom0/domuU, clocksource is 'xen' > >> everywhere. > >> > >> some messages : > >> syslog : > >> Sep 11 13:56:50 dnsit22 kernel: [571603.359863] Clocksource tsc > >> unstable (delta =3D -2999662111513 ns) > >> > >> xm dmesg : > >> ... > >> (XEN) Platform timer is 14.318MHz HPET ... > >> (XEN) Platform timer appears to have unexpectedly wrapped 10 or more > times. > >> (XEN) TSC marked as reliable, warp =3D 0 (count=3D2) ... > >> > >> I had some contact with Olivier Hanesse and it indicates that he > >> doesn't have any solution for this problem, and all what was proposed > >> in February didn't solved this problem. >=20 > That looks like Xen itself is having problems keeping track of time. If = it can't > manage it, then there's not much the guest kernels can do about it. >=20 > > > > Which was the max_cstate=3D0 ? > > .. > >> config : > >> -------------------------------------- > >> Linux dnsit22.swissptt.ch 2.6.32-5-xen-amd64 #1 SMP Tue Jun 14 > >> 12:46:30 UTC 2011 x86_64 GNU/Linux > >> -------------------------------------- > >> HP DL385 > >> -------------------------------------- > >> vendor_id : AuthenticAMD > >> cpu family : 16 > >> model : 9 > >> model name : AMD Opteron(tm) Processor 6174 > >> stepping : 1 > >> cpu MHz : 3058776.574 > > OK, that is really messed up. Your house must be on fire for the > > machine to be running at 3058GHz! > > > > Jeremy, this sounds familiar - did we have a patch for this in your > > 2.6.32 tree? >=20 > Not that I can think of. All I can suggest from the kernel side is that = perhaps > some of the ACPI power stuff isn't being set up properly, and that makes = the > CPU do very strange things with its TSC/power states in general. >=20 how can i detect that ?=20 the /proc/acpi/processor path is empty,=20 find /proc/acpi /proc/acpi /proc/acpi/processor /proc/acpi/button /proc/acpi/button/power /proc/acpi/button/power/PWRF /proc/acpi/button/power/PWRF/info /proc/acpi/thermal_zone /proc/acpi/wakeup /proc/acpi/sleep /proc/acpi/fadt /proc/acpi/dsdt /proc/acpi/info /proc/acpi/power_resource /proc/acpi/embedded_controller dmesg | grep -I acpi [ 1.205647] hpet_acpi_add: no address or irqs in _CRS lsmod | grep -i acpi acpi_processor 5087 1 processor,[permanent] > J >=20 >=20 > _______________________________________________ > Xen-devel mailing list > Xen-devel@lists.xensource.com > http://lists.xensource.com/xen-devel _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel From xen-devel-bounces@lists.xensource.com Thu Sep 15 23:08:58 2011 Return-path: Envelope-to: www-data@lists.xensource.com Delivery-date: Thu, 15 Sep 2011 23:08:58 -0700 Received: from localhost ([127.0.0.1] helo=lists.colo.xensource.com) by lists.xensource.com with esmtp (Exim 4.43) id 1R4Rbe-00047O-G4; Thu, 15 Sep 2011 23:08:58 -0700 Received: from mail21.messagelabs.com ([85.158.143.35]) by lists.xensource.com with smtp (Exim 4.43) id 1R4Raz-0003vQ-V9 for xen-devel@lists.xensource.com; Thu, 15 Sep 2011 23:08:19 -0700 X-Env-Sender: tinnycloud@hotmail.com X-Msg-Ref: server-10.tower-21.messagelabs.com!1316153279!54307120!1 X-Originating-IP: [65.55.116.26] X-StarScan-Version: 6.4.1; banners=-,-,- X-VirusChecked: Checked Received: (qmail 9871 invoked from network); 16 Sep 2011 06:07:59 -0000 Received: from blu0-omc1-s15.blu0.hotmail.com (HELO blu0-omc1-s15.blu0.hotmail.com) (65.55.116.26) by server-10.tower-21.messagelabs.com with SMTP; 16 Sep 2011 06:07:59 -0000 Received: from BLU157-W7 ([65.55.116.7]) by blu0-omc1-s15.blu0.hotmail.com with Microsoft SMTPSVC(6.0.3790.4675); Thu, 15 Sep 2011 23:08:13 -0700 Message-ID: Content-Type: multipart/mixed; boundary="_8ed9fe05-1fc2-4309-8777-22b0c1c100d9_" X-Originating-IP: [121.0.29.75] From: MaoXiaoyun To: Subject: RE: [Xen-devel] RE: ext4 BUG in dom0 Kernel 2.6.32.36 Date: Fri, 16 Sep 2011 14:08:13 +0800 Importance: Normal In-Reply-To: References: , , <20110906145347.GA4133@dumpdata.com>, , <4E666C86.5090707@goop.org>, MIME-Version: 1.0 X-OriginalArrivalTime: 16 Sep 2011 06:08:13.0659 (UTC) FILETIME=[04A112B0:01CC7437] Cc: linux-ext4@vger.kernel.org, xen devel , konrad.wilk@oracle.com X-BeenThere: xen-devel@lists.xensource.com X-Mailman-Version: 2.1.5 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xensource.com Errors-To: xen-devel-bounces@lists.xensource.com --_8ed9fe05-1fc2-4309-8777-22b0c1c100d9_ Content-Type: text/plain; charset="gb2312" Content-Transfer-Encoding: 8bit Hi: I finally captured extents overlaped in the ext4. But still wondering how it happen. I checked overlap for the last extent in the tree at the very beginning of ext4_ext_convert_to_initialized. Messages.12 attached show the overlap found. Line 8-10: 3467:[1]15:57921642 3468:[0]14:57921643 has overlaped. 8 Sep 15 08:27:39 xmao kernel: 3331:[0]7:53750025 3338:[0]8:53750033 3346:[0]1:53848953 3347:[0]7:53848955 3354:[0]1:53848969 3355:[0]7:53848971 3362:[0]1:53848985 3363:[0]7:56996848 3370:[0]1:57606144 3371:[0]7:57795290 3378:[0]1:57814407 3379:[0]7:57858606 3386:[0]8:57858620 3394:[0]1:57858629 3395:[0]8:57858637 3403:[0]7:57858646 3410:[0]1:57858661 3411:[0]8:57858669 3419:[0]7:57858678 3426:[0]8:57858692 3434:[0]1:57858701 3435:[0]7:57858709 3442:[0]1:57858717 3443:[0]7:57858725 3450:[0]1:57858733 3451:[0]7:57858741 3458:[0]1:57858749 3459:[0]7:57858757 3466:[0]1:57921634 3467:[1]15:57921642 9 Sep 15 08:27:39 xmao kernel: Displaying leaf extents for inode 12339004 10 Sep 15 08:27:39 xmao kernel: 3468:[0]14:57921643 3482:[0]1:57921664 3483:[0]7:57921666 3490:[0]1:57921680 3491:[0]8:57921682 3499:[0]7:57921691 3506:[0]8:57921705 3514:[0]1:57921714 3515:[0]7:57921722 3522:[0]41:57916683 3563:[0]7:58159767 3570:[0]1:58159781 3571:[0]7:58238992 3578:[0]1:58288144 3579:[0]7:58327750 3586:[0]1:58579969 3587:[0]7:58954838 3594:[0]1:59006641 3595:[0]7:59006643 3602:[0]1:59006657 3603:[0]7:59006659 3610:[0]8:59006673 3618:[0]8:59006688 3626:[0]470:58982658 4096:[0]3:58987732 4099:[0]1:58992655 4100:[0]7:59143253 4107:[0]1:59171840 4108:[0]7:59183878 4115:[0]1:59192886 4116:[0]8:59593463 4124:[0]8:59669484 4132:[0]7:73086538 4139:[0]1:73352801 4140:[0]7:73339273 4147:[0]1:73526280 4148:[0]8:78229012 4156:[0]1:78229021 4157:[0]7:78818388 4164:[0]1:79069383 4165:[0]7:79428616 4172:[0]1:80490925 4173:[0]7:81439488 4180:[0]1:82854062 4181:[0]7:83462272 4188:[0]1:83656904 4189:[0]7:89127381 4196:[0]1:89584313 4197:[0]8:91592930 4205:[0]7:91592945 4212:[0]1:91592953 4213:[0]7:91592961 422 I also dumped file in disk use filefrag which show no overlap, no extent 3468:[0]14:57921643. ext logical physical expected length flags .... 337 3459 57858757 57858749 7 338 3466 57921634 57858763 1 unwritten 339 3467 57921642 57921634 15 unwritten 340 3482 57921664 57921656 1 341 3483 57921666 57921664 7 ..... There is one assumption, After 3468:[0]14:57921643 successfully inserted, there is something err happen. At the bottom of ext4_ext_convert_to_initialized, fix_extent_len will fix the origin ex ee_len.(Later I will do the err check) 3403 fix_extent_len: 3404 ex->ee_block = orig_ex.ee_block; 3405 ex->ee_len = orig_ex.ee_len; 3406 ext4_ext_store_pblock(ex, ext_pblock(&orig_ex)); 3407 ext4_ext_mark_uninitialized(ex); 3408 ext4_ext_dirty(handle, inode, path + depth); Any comments? Well, but something strange messages.12. message.12 is from another machine, it log is printf right before BUG_ON(newext->ee_block == nearex->ee_block); strange is 14412:[1]16:9927's pblock is much different from 14411:[0]1:222332613. 1993 if(newext->ee_block == nearex->ee_block){ 1994 len = (EXT_MAX_EXTENT(eh) - nearex) * sizeof(struct ext4_extent); 1995 len = len < 0 ? 0 : len; 1996 printk("old_depth %d depth %d old_path %p path %p next_has_free %d next %llu\n", 1997 old_depth, depth, old_path, path, next_has_free, (unsigned long long)next); 2004 2005 printk("insert %d:%llu:[%d]%d before: nearest 0x%p, " 2006 "move %d from 0x%p to 0x%p\n", 2007 le32_to_cpu(newext->ee_block), 2008 ext_pblock(newext), 2009 ext4_ext_is_uninitialized(newext), 2010 ext4_ext_get_actual_len(newext), 2011 nearex, len, nearex + 1, nearex + 2); 2012 ext4_ext_show_leaf_xmao(inode, old_path); 2013 ext4_ext_show_leaf_xmao(inode, path); 2014 }; 2015 BUG_ON(newext->ee_block == nearex->ee_block); Sep 13 16:16:35 xmao kernel: 57:[0]31:157254721 12288:[0]54:157503830 12342:[0]10:157503884 12352:[0]5:157534763 12357:[0]1:157534768 12358:[0]58:157534769 12416:[0]64:157567168 12480:[0]13:158051261 12493:[0]73:172263095 12566:[0]24:172265399 12590:[0]71:172521859 12661:[0]71:172627897 12732:[0]71:172733735 12803:[0]69:172722619 12872:[0]9:172764859 12881:[0]42:110500028 12923:[0]86:143030061 13009:[0]86:143119859 13095:[0]48:143173376 13143:[0]16:195333586 13159:[0]32:197526105 13191:[0]40:198875861 13231:[0]39:198872300 13270:[0]5:199663576 13275:[0]26:200964192 13301:[0]36:202015708 13337:[0]47:202221682 13384:[0]9:202221729 13393:[0]58:202624966 13451:[0]12:202606535 13463:[0]35:212117725 13498:[0]35:212135811 13533:[0]34:212115513 13567:[0]32:212108608 13599:[0]29:212144185 13628:[0]50:231280420 13678:[0]38:231645389 13716:[0]13:231645427 13729:[0]51:231650765 13780:[0]50:231647658 13830:[0]54:231985340 13884:[0]24:231981259 13908:[0]64:105098731 13972:[0]87:136696745 14059:[0]45:136700237 14104:[0]61:2 Sep 13 16:16:35 xmao kernel: 3651 14165:[0]69:222042299 14234:[0]68:222044092 14302:[0]34:222091761 14336:[0]68:222172860 14404:[0]7:222332606 14411:[0]1:222332613 Sep 13 16:16:35 xmao kernel: Displaying leaf extents for inode 30685060 Sep 13 16:16:35 xmao kernel: 14412:[1]16:9927 14428:[1]41:13213 14469:[1]1:13254 14470:[0]67:222673085 Also, filefrag show extents is ok. 336 14302 222091761 222044159 34 337 14336 222172860 222091794 68 338 14404 222332606 222172927 7 339 14411 222332613 59 unwritten 340 14470 222673085 222332671 67 341 14537 222848155 222673151 43 342 14580 165617358 222848197 56 343 14636 165777353 165617413 55 344 14691 165961927 165777407 57 seems 14412:[1]16:9927 14428:[1]41:13213 14469:[1]1:13254 is unexpected. Many thanks. ---------------------------------------- > From: tinnycloud@hotmail.com > To: jeremy@goop.org > CC: konrad.wilk@oracle.com; linux-ext4@vger.kernel.org; xen-devel@lists.xensource.com > Subject: RE: [Xen-devel] RE: ext4 BUG in dom0 Kernel 2.6.32.36 > Date: Wed, 7 Sep 2011 10:35:21 +0800 > > > > > ---------------------------------------- > > Date: Tue, 6 Sep 2011 11:55:02 -0700 > > From: jeremy@goop.org > > To: tinnycloud@hotmail.com > > CC: konrad.wilk@oracle.com; linux-ext4@vger.kernel.org; xen-devel@lists.xensource.com > > Subject: Re: [Xen-devel] RE: ext4 BUG in dom0 Kernel 2.6.32.36 > > > > On 09/06/2011 08:11 AM, MaoXiaoyun wrote: > > > > > > > Date: Tue, 6 Sep 2011 10:53:47 -0400 > > > > From: konrad.wilk@oracle.com > > > > To: tinnycloud@hotmail.com > > > > CC: linux-ext4@vger.kernel.org; xen-devel@lists.xensource.com; > > > jeremy@goop.org > > > > Subject: Re: ext4 BUG in dom0 Kernel 2.6.32.36 > > > > > > > > On Tue, Sep 06, 2011 at 03:24:14PM +0800, MaoXiaoyun wrote: > > > > > > > > > > > > > > > Hi: > > > > > > > > > > I've met an ext4 Bug in dom0 kernel 2.6.32.36. (See kernel stack > > > below) > > > > > > > > Did you try the 3.0 kernel? > > > No, I am afried the change would be to much for our current env. > > > May result in other stable issue. > > > So, I want to dig out what really happen. Hopes. > > > > Another question is whether this is a regression compared to earlier > > versions of 2.6.32? Do you know if this problem exists in a non-Xen > > environment? > > > > There are some others reports this issue in non-xen env. > http://markmail.org/message/ywr4nfgiuvgdcr7y > http://www.spinics.net/lists/linux-ext4/msg21066.html > > The difficulty is I haven't find a efficient way to reproduce it. > (Currently it only show in our cluster, redeploy our cluster may cost 3days more. ) > > > > Thanks, > > J > > -- > > To unsubscribe from this list: send the line "unsubscribe linux-ext4" in > > the body of a message to majordomo@vger.kernel.org > > More majordomo info at http://vger.kernel.org/majordomo-info.html --_8ed9fe05-1fc2-4309-8777-22b0c1c100d9_ Content-Type: application/octet-stream Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="messages.12" U2VwIDE1IDA4OjI3OjM5IHhtYW8ga2VybmVsOiBEaXNwbGF5aW5nIGxlYWYgZXh0ZW50cyBmb3Ig aW5vZGUgMTIzMzkwMDQKU2VwIDE1IDA4OjI3OjM5IHhtYW8ga2VybmVsOiAwOlswXTI1NjoyNDI2 NDg4MzIgMjU2OlswXTI1NjoyNDI2NTE2NDggNTEyOlswXTQ1OjIxNzQ0MTI4IDU1NzpbMF0xNjoy MTg3MDU5MyA1NzM6WzBdMToyMTg3MDYxMCA1NzQ6WzBdODoyMTg3MDYxOCA1ODI6WzBdODoyMTg3 MDYzNCA1OTA6WzBdODoyMTg3MDY0MyA1OTg6WzBdNzoyMTg3MDY1OCA2MDU6WzBdMToyMTg3MDY2 NiA2MDY6WzBdMjM6MjE4NzA2NzQgNjI5OlswXTg6MjcwNjczOTIgNjM3OlswXTE6MjcwNjc0MDcg NjM4OlswXTg6MjcwNjc0MDkgNjQ2OlswXTM3ODoyNzIzNTg0MCAxMDI0OlswXTU6MjczMTg4NDkg MTAyOTpbMF0xOjM4OTIzODUwIDEwMzA6WzBdMjo0MDA0MzAyNiAxMDMyOlswXTU6NDAxOTI3Njgg MTAzNzpbMF0xOjQwNDYwMDMyIDEwMzg6WzBdNzo0MDY2NTA4OCAxMDQ1OlswXTE6NDA3MzY1MTIg MTA0NjpbMF03OjQxNzkyNTU2IDEwNTM6WzBdNjU6MjE1MDExNjgxIDExMTg6WzBdMToyMTUzMTg1 MjggMTExOTpbMF03OjIxNTgxMjMwNCAxMTI2OlswXTg6MjE1ODI4NjEzIDExMzQ6WzBdMToyMTU4 Mjg2MjggMTEzNTpbMF03OjIxNTgyODYzMCAxMTQyOlswXTk6MjE1ODI4NjQ0IDExNTE6WzBdODoy MTU4Mjg2NTQgMTE1OTpbMF03OjIxNTgyODY2OSAxMTY2OlswXTg6MjE1ODI4Njc3IDExNzQ6WzBd MToyMTU4Mjg2OTIgMTE3NTpbMF03OjIxNTgyODY5NCAxMTgyOlswXTE6MjE1ODI4NzA4IDExODM6 WzBdODoyMTU4Mjg3MTAgMTE5MTpbMF03OjIxNTgxMjMxOCAxMTk4OlswXTE6MjE1ODI4NzE5IDEx OTk6WzBdNzoyMTU4MTIzMjUgMTIwNjpbMF0xOjIxNTgyODcyNyAxMjA3OlswXTc6MjE1ODI4NzI5 IDEyMTQ6WzBdODoyMTU4MTIzMzIgMTIyMjpbMF04OjIxNTgyODczNiAxMjMwOlswXTg6MjE1ODEy MzQxIDEyMzg6WzBdODoyMTU4Mjg3NDQgMTI0NjpbMF04OjIxNTgxMTUzNCAxMjU0OlswXTE6MjE1 ODI4NzUyIDEyNTU6WzBdNzoyMTU4Mjg3NTQgMTI2MjpbMF04OjIxNTgxMjM1NyAxMjcwOlswXTg6 MjE1ODI4NzYyIDEyNwpTZXAgMTUgMDg6Mjc6MzkgeG1hbyBrZXJuZWw6IDpbMF0xOjIxNTgxMjM2 NSAxMjc5OlswXTc6MjE1ODEyMzY3IDEyODY6WzBdMToyMTYzNjg1MzUgMTI4NzpbMF00ODoyMTY0 Mzc3NjAgMTMzNTpbMF03OjIxNjQzNzgwOSAxMzQyOlswXTE6MjIwMzc0OTQ4IDEzNDM6WzBdODoy MjA0MTQxOTMgMTM1MTpbMF03OjIyMDQxNDIwOCAxMzU4OlswXTg6MjIwNDE0MjE2IDEzNjY6WzBd MToyMjA0MTQyMzEgMTM2NzpbMF03OjIyMDQwNDk5NCAxMzc0OlswXTE6MjIwNDE0MjQxIDEzNzU6 WzBdNzoyMjA0MDUwMDEgMTM4MjpbMF0xOjIyMjYxODk5OSAxMzgzOlswXTc6MjIzODM4Mzk3IDEz OTA6WzBdMToyMjQwOTc3OTIgMTM5MTpbMF03OjIyNDEwNzc4MyAxMzk4OlswXTg6MjI0MTA3Nzk4 IDE0MDY6WzBdODoyMjQxMjIwNDkgMTQxNDpbMF0xOjIyNDEwNzgxNSAxNDE1OlswXTc6MjI0MTIy MDU3IDE0MjI6WzBdOToyMjQxMDc4MjQgMTQzMTpbMF03OjIyNDEyMjA3MSAxNDM4OlswXTE6MjI0 MTA3ODM0IDE0Mzk6WzBdNzoyMjQxMjIwNzggMTQ0NjpbMF0xOjIyNDEwNzg0MiAxNDQ3OlswXTg6 MjI0MTA3ODQ0IDE0NTU6WzBdNzoyMjQyODQ4MjQgMTQ2MjpbMF0xOjIyNDU2NzI5NiAxNDYzOlsw XTY0OjIyNDY3NDgxNiAxNTI3OlswXTc6MjI0NzMzMTg0IDE1MzQ6WzBdMzI6MjI1MTA2NDIyIDE1 NjY6WzBdMTQ1OjIyNTEyMTIwMCAxNzExOlswXTMzNzoyMjU2OTQyMDggMjA0ODpbMF03OjIyNTc3 Njc3NyAyMDU1OlswXTg6MjI1ODAzNjM0IDIwNjM6WzBdMToyMjU4MDM2NDkgMjA2NDpbMF03OjIy NTgwMzY1MSAyMDcxOlswXTE6MjI1ODAzNjY1IDIwNzI6WzBdNzoyMjU4MDM2NjcgMjA3OTpbMF0x OjIyNTgwMzY4MSAyMDgwOlswXTc6MjI1ODAzNjgzIDIwODc6WzBdODoyMjU3NzY3ODQgMjA5NTpb MF0xOjIyNTgwMzY5MCAyMDk2OlswXTg6MjI1ODAzNjkyIDIxMDQ6WzBdMToyMjU3NzY0MzAgMjEw NTpbMF03OjIyNTc3NjQzMiAyMTEyOlswXTE6MjI1NzgwNjgwIDIxMTM6WzBdNzoyMjU4MDM3MDAg MjEyMDpbMF04OjIyClNlcCAxNSAwODoyNzozOSB4bWFvIGtlcm5lbDogNjgyIDIxMjg6WzBdODoy MjU3NzY3OTkgMjEzNjpbMF0xOjIyNTkzNDIwMyAyMTM3OlswXTg6MjI1OTM0MjExIDIxNDU6WzBd MTU6MjI1OTM0MjIwIDIxNjA6WzBdMToyMjU5MDc0NjYgMjE2MTpbMF03OjIyNTkzNDIzNSAyMTY4 OlswXTE6MjI1OTMzMzEzIDIxNjk6WzBdNzoyMjc2MjQ1MzYgMjE3NjpbMF0xOjIyNzk5OTc1MiAy MTc3OlswXTc6MjI5MjcxNDcyIDIxODQ6WzBdODoyMjkyNzE0ODcgMjE5MjpbMF0xOjIyOTI3MTUw MyAyMTkzOlswXTc6MjI5MjcxNTA1IDIyMDA6WzBdMToyMjkyNzE1MTkgMjIwMTpbMF03OjIyOTI3 MTUyMSAyMjA4OlswXTE6MjI5MjY4ODY0IDIyMDk6WzBdNzoyMjkyNzE1MjggMjIxNjpbMF04OjIy OTI2ODg3MyAyMjI0OlswXTE6MjMzNzE1NzEyIDIyMjU6WzBdNzoyMzM3MTU3MjAgMjIzMjpbMF04 OjIzNTIwNjY1NiAyMjQwOlswXTg6MjM1MjA2NjcyIDIyNDg6WzBdMToyMzUyMDY2ODEgMjI0OTpb MF03OjIzNTIwNjY4OSAyMjU2OlswXTE6MjM1MjA2Njk3IDIyNTc6WzBdODoyMzUyMDY3MDUgMjI2 NTpbMF03OjIzNTIwNjcxNCAyMjcyOlswXTE6MjM1MjA2NzI4IDIyNzM6WzBdNzoyMzUyMDY3MzAg MjI4MDpbMF04OjIzNTIwNjc0NSAyMjg4OlswXTE6MjM1MjA2NzYwIDIyODk6WzBdODoyMzUzNzIw MzIgMjI5NzpbMF03OjIzNTU2MDE0OCAyMzA0OlswXTg6MjM1NTYwMTU2IDIzMTI6WzBdMToyMzU1 NjAxNzEgMjMxMzpbMF04OjIzNTU2MDE3MyAyMzIxOlswXTc6MjM1NzEyMDgwIDIzMjg6WzBdMToy MzU3NTcyNDEgMjMyOTpbMF03OjIzNTg1ODMwNiAyMzM2OlswXTE6MjM3OTQxNzQwIDIzMzc6WzBd Nzo3MDczNzkyIDIzNDQ6WzBdMTo3MTQ3MDQyIDIzNDU6WzBdNzo3NTkwODk3IDIzNTI6WzBdODo3 NTkwOTA1IDIzNjA6WzBdODo3NTk3OTIxIDIzNjg6WzBdODo3Njk1NDczIDIzNzY6WzBdODo3Njc3 OTU5IDIzODQ6WzBdMTo3Njk1NDg5IDIzODU6WzBdNzo3Njk1OTA1IDIzOTI6WzBdMTo3Njk1NDkw IDIzOTM6WzBdNzoKU2VwIDE1IDA4OjI3OjM5IHhtYW8ga2VybmVsOiA0OTIgMjQwMDpbMF0xOjc2 Nzc5NzUgMjQwMTpbMF03Ojc2OTgxNzYgMjQwODpbMF0xOjc2Nzc5NzcgMjQwOTpbMF03Ojc2OTU0 OTkgMjQxNjpbMF04Ojc3MTA3ODIgMjQyNDpbMF04OjgwMTY2NDAgMjQzMjpbMF0xOjgyODY1MTQg MjQzMzpbMF03OjkyOTk5NjggMjQ0MDpbMF0xOjk2NTA2ODggMjQ0MTpbMF03Ojk4MzUwMTIgMjQ0 ODpbMF0xOjk4MzA1NTIgMjQ0OTpbMF03Ojk4MzUwMjcgMjQ1NjpbMF0xOjk4MzUwNDEgMjQ1Nzpb MF03Ojk4MzUwNDMgMjQ2NDpbMF0xOjEwMjg1MDAwIDI0NjU6WzBdNzoyNTc2MTc5MiAyNDcyOlsw XTE6MjY5ODc3NjIgMjQ3MzpbMF04OjI2OTg3NzcwIDI0ODE6WzBdNzoyNjk4Nzc3OSAyNDg4Olsw XTI0OjI3MDE3ODQ4IDI1MTI6WzBdODoyNzA2NzQyNCAyNTIwOlswXTg6MjcwMTk2MjggMjUyODpb MF04OjI3MDE3ODcyIDI1MzY6WzBdODoyNzA2NzQzMiAyNTQ0OlswXTE6MjcwMTk2MzYgMjU0NTpb MF03OjI3MTE5MDM2IDI1NTI6WzBdMToyNzAxOTYzNyAyNTUzOlswXTc6MjcwMTc4ODAgMjU2MDpb MF0xOjI3MDE5NjM4IDI1NjE6WzBdNzoyNzExOTA0MyAyNTY4OlswXTg6MjcwMTk2MzkgMjU3Njpb MF04OjI3MDY3NDQwIDI1ODQ6WzBdMToyNzAxNzg4NyAyNTg1OlswXTc6MjcxMTkwNTAgMjU5Mjpb MF04OjI3MDE3ODg4IDI2MDA6WzBdODoyNzAxOTY0NyAyNjA4OlswXTk6MjcwNjc0NDggMjYxNzpb MF0xOjI3MDE3ODk2IDI2MTg6WzBdNzoyNzExOTA1NyAyNjI1OlswXTE6MjcwMTc4OTcgMjYyNjpb MF03OjI3MDE5NjU1IDI2MzM6WzBdODoyNzAxNzg5OCAyNjQxOlswXTE6MjgwOTQ2NTIgMjY0Mjpb MF0xNjoyNzAxOTY2MiAyNjU4OlswXTc6MjgwOTU2NjggMjY2NTpbMF0xOjI4ODg3MTc5IDI2NjY6 WzBdMzI6MjcwMTk2NzggMjY5ODpbMF03OjI3MTQ4MTE4IDI3MDU6WzBdODoyNzAxODM3OSAyNzEz OlswXTg6MjcwODE5NTggMjcyMTpbMF0xOjYwMDc1MjM3IDI3MjI6WzBdNzoyNzAyNDAyMyAyNzI5 OlswXTg6MjcwMQpTZXAgMTUgMDg6Mjc6MzkgeG1hbyBrZXJuZWw6ICAyNzM3OlswXTE6MjcwODE5 NjYgMjczODpbMF03OjI5MDE3NjQ2IDI3NDU6WzBdMzI6MjcwMTgzOTUgMjc3NzpbMF0xOjI3MDA2 MTI0IDI3Nzg6WzBdNzo0OTE4NTU4OSAyNzg1OlswXTE6MjcwMDYxMjUgMjc4NjpbMF03OjUxMjMy NzY4IDI3OTM6WzBdODoyNzAwNjEyNiAyODAxOlswXTE6MjcwMTg0MjcgMjgwMjpbMF03OjI3MDY4 ODU5IDI4MDk6WzBdODoyNzAxODQyOCAyODE3OlswXTg6MjcwMDYxMzQgMjgyNTpbMF04OjI3MDU0 NDE4IDI4MzM6WzBdODoyNzAxODQzNiAyODQxOlswXTE6MjcwMDYxNDIgMjg0MjpbMF03OjI3MDY4 ODY2IDI4NDk6WzBdMToyNzAwNjE0MyAyODUwOlswXTc6MjcwNTQ0MjYgMjg1NzpbMF0xOjI3MDA2 MTQ0IDI4NTg6WzBdNzo1MTM5MzI1MSAyODY1OlswXTE6MjcwMDYxNDUgMjg2NjpbMF03OjI3MDE4 NDQ0IDI4NzM6WzBdODoyNzA4MDgyMiAyODgxOlswXTg6MjcwNTQ0MzMgMjg4OTpbMF04OjI3MDE4 NDUxIDI4OTc6WzBdODoyNzA1NDQ0MSAyOTA1OlswXTg6MjcwMTg0NTkgMjkxMzpbMF04OjI3MDU0 NDQ5IDI5MjE6WzBdODoyNzAxODQ2NyAyOTI5OlswXTg6MjcwNTQ0NTcgMjkzNzpbMF04OjI3MDE4 NDc1IDI5NDU6WzBdODoyNzA4MDgzMCAyOTUzOlswXTg6MjcwNTQ0NjUgMjk2MTpbMF04OjI3MDE4 NDgzIDI5Njk6WzBdODoyNzA4MDgzOCAyOTc3OlswXTg6MjcwNTQ0NzMgMjk4NTpbMF04OjI3MDE4 NDkxIDI5OTM6WzBdMToyNzA2NjQwOCAyOTk0OlswXTc6MjcwODA4NDYgMzAwMTpbMF04OjI3MDY2 NDA5IDMwMDk6WzBdODoyNzA1NDQ4MSAzMDE3OlswXTE6MjcwNjY0MTcgMzAxODpbMF0xNToyNzA2 NjQxOSAzMDMzOlswXTE6MjcxNjU1NDcgMzAzNDpbMF03OjI3MTY1NTU2IDMwNDE6WzBdMToyNzE2 NTU3MCAzMDQyOlswXTc6MjcxNjU1NzIgMzA0OTpbMF0xOjI3Nzc1MDExIDMwNTA6WzBdNzoyODAw NDM1MiAzMDU3OlswXTE6MjgxODkxODQgMzA1ODpbMF03OjI4MjI1MTQ3IDMwNjU6WzBdMToyODIy NTE1NSAzMDY2ClNlcCAxNSAwODoyNzozOSB4bWFvIGtlcm5lbDogNzoyODIyNTE2MyAzMDczOlsw XTE6MjgyMjUxNzggMzA3NDpbMF03OjUwODIxMDk2IDMwODE6WzBdMTo1MTc3MDQ5OSAzMDgyOlsw XTc6NTE3NzA1MDEgMzA4OTpbMF04OjUxNzcwNTE1IDMwOTc6WzBdMTo1MTc3MDUyNCAzMDk4Olsw XTc6NTE3NzA1MzIgMzEwNTpbMF0xOjUxNzQyNjUyIDMxMDY6WzBdNzo1MTc3MDU0OCAzMTEzOlsw XTE6NTIwODcwNTYgMzExNDpbMF03OjUyMjUyMjczIDMxMjE6WzBdMTo1MjIzOTEzNSAzMTIyOlsw XTg6NTIyNTIyODAgMzEzMDpbMF0xOjUyMjM5MTQ0IDMxMzE6WzBdODo1MjIzOTE0NiAzMTM5Olsw XTc6NTIyMzkxNTUgMzE0NjpbMF0xOjUyMjM2NzQ2IDMxNDc6WzBdNzo1MjIzNjc0OCAzMTU0Olsw XTE6NTIyNTIzMDIgMzE1NTpbMF03OjUyMjUyMzA0IDMxNjI6WzBdODo1MjIzOTE2OSAzMTcwOlsw XTE6NTIyNTIzMTIgMzE3MTpbMF03OjUyMjM2NzYyIDMxNzg6WzBdMTo1MjIzOTQxNiAzMTc5Olsw XTc6NTIyMzg4NTcgMzE4NjpbMF0xOjUyMjM5NDE3IDMxODc6WzBdNzo1MjI1MjMyMCAzMTk0Olsw XTE6NTIyMzkxODMgMzE5NTpbMF03OjUyMjM1MTExIDMyMDI6WzBdMTo1Mjc1ODAxNCAzMjAzOlsw XTMyOjUzMTg2ODMyIDMyMzU6WzBdODo1MzIxODI4MSAzMjQzOlswXTc6NTMyMTgyOTcgMzI1MDpb MF0xOjUzMjE4MzExIDMyNTE6WzBdNzo1MzIxODMxMyAzMjU4OlswXTE6NTMyMTgzMjcgMzI1OTpb MF03OjUzMjE4MzI5IDMyNjY6WzBdMTo1MzIxODM1OSAzMjY3OlswXTc6NTMyMTgzNjEgMzI3NDpb MF0xOjUzMjE4Mzc1IDMyNzU6WzBdNzo1MzIxODM3NyAzMjgyOlswXTE6NTMyMTgzOTEgMzI4Mzpb MF04OjUzMjE4MzkzIDMyOTE6WzBdNzo1MzIxODQwOCAzMjk4OlswXTE6NTMyMTg0MTYgMzI5OTpb MF03OjUzMjE4NDI0IDMzMDY6WzBdMTo1MzIxODQzOSAzMzA3OlswXTg6NTMyMTg0NDEgMzMxNTpb MF03OjUzMjI4NTQ0IDMzMjI6WzBdMTo1MzI2NjEzOCAzMzIzOlswXTc6NTM1MDM5NzkgMzMzMDpb MF0xOjUzNzUKU2VwIDE1IDA4OjI3OjM5IHhtYW8ga2VybmVsOiAgMzMzMTpbMF03OjUzNzUwMDI1 IDMzMzg6WzBdODo1Mzc1MDAzMyAzMzQ2OlswXTE6NTM4NDg5NTMgMzM0NzpbMF03OjUzODQ4OTU1 IDMzNTQ6WzBdMTo1Mzg0ODk2OSAzMzU1OlswXTc6NTM4NDg5NzEgMzM2MjpbMF0xOjUzODQ4OTg1 IDMzNjM6WzBdNzo1Njk5Njg0OCAzMzcwOlswXTE6NTc2MDYxNDQgMzM3MTpbMF03OjU3Nzk1Mjkw IDMzNzg6WzBdMTo1NzgxNDQwNyAzMzc5OlswXTc6NTc4NTg2MDYgMzM4NjpbMF04OjU3ODU4NjIw IDMzOTQ6WzBdMTo1Nzg1ODYyOSAzMzk1OlswXTg6NTc4NTg2MzcgMzQwMzpbMF03OjU3ODU4NjQ2 IDM0MTA6WzBdMTo1Nzg1ODY2MSAzNDExOlswXTg6NTc4NTg2NjkgMzQxOTpbMF03OjU3ODU4Njc4 IDM0MjY6WzBdODo1Nzg1ODY5MiAzNDM0OlswXTE6NTc4NTg3MDEgMzQzNTpbMF03OjU3ODU4NzA5 IDM0NDI6WzBdMTo1Nzg1ODcxNyAzNDQzOlswXTc6NTc4NTg3MjUgMzQ1MDpbMF0xOjU3ODU4NzMz IDM0NTE6WzBdNzo1Nzg1ODc0MSAzNDU4OlswXTE6NTc4NTg3NDkgMzQ1OTpbMF03OjU3ODU4NzU3 IDM0NjY6WzBdMTo1NzkyMTYzNCAzNDY3OlsxXTE1OjU3OTIxNjQyIApTZXAgMTUgMDg6Mjc6Mzkg eG1hbyBrZXJuZWw6IERpc3BsYXlpbmcgbGVhZiBleHRlbnRzIGZvciBpbm9kZSAxMjMzOTAwNApT ZXAgMTUgMDg6Mjc6MzkgeG1hbyBrZXJuZWw6IDM0Njg6WzBdMTQ6NTc5MjE2NDMgMzQ4MjpbMF0x OjU3OTIxNjY0IDM0ODM6WzBdNzo1NzkyMTY2NiAzNDkwOlswXTE6NTc5MjE2ODAgMzQ5MTpbMF04 OjU3OTIxNjgyIDM0OTk6WzBdNzo1NzkyMTY5MSAzNTA2OlswXTg6NTc5MjE3MDUgMzUxNDpbMF0x OjU3OTIxNzE0IDM1MTU6WzBdNzo1NzkyMTcyMiAzNTIyOlswXTQxOjU3OTE2NjgzIDM1NjM6WzBd Nzo1ODE1OTc2NyAzNTcwOlswXTE6NTgxNTk3ODEgMzU3MTpbMF03OjU4MjM4OTkyIDM1Nzg6WzBd MTo1ODI4ODE0NCAzNTc5OlswXTc6NTgzMjc3NTAgMzU4NjpbMF0xOjU4NTc5OTY5IDM1ODc6WzBd Nzo1ODk1NDgzOCAzNTk0OlswXTE6NTkwMDY2NDEgMzU5NTpbMF03OjU5MDA2NjQzIDM2MDI6WzBd MTo1OTAwNjY1NyAzNjAzOlswXTc6NTkwMDY2NTkgMzYxMDpbMF04OjU5MDA2NjczIDM2MTg6WzBd ODo1OTAwNjY4OCAzNjI2OlswXTQ3MDo1ODk4MjY1OCA0MDk2OlswXTM6NTg5ODc3MzIgNDA5OTpb MF0xOjU4OTkyNjU1IDQxMDA6WzBdNzo1OTE0MzI1MyA0MTA3OlswXTE6NTkxNzE4NDAgNDEwODpb MF03OjU5MTgzODc4IDQxMTU6WzBdMTo1OTE5Mjg4NiA0MTE2OlswXTg6NTk1OTM0NjMgNDEyNDpb MF04OjU5NjY5NDg0IDQxMzI6WzBdNzo3MzA4NjUzOCA0MTM5OlswXTE6NzMzNTI4MDEgNDE0MDpb MF03OjczMzM5MjczIDQxNDc6WzBdMTo3MzUyNjI4MCA0MTQ4OlswXTg6NzgyMjkwMTIgNDE1Njpb MF0xOjc4MjI5MDIxIDQxNTc6WzBdNzo3ODgxODM4OCA0MTY0OlswXTE6NzkwNjkzODMgNDE2NTpb MF03Ojc5NDI4NjE2IDQxNzI6WzBdMTo4MDQ5MDkyNSA0MTczOlswXTc6ODE0Mzk0ODggNDE4MDpb MF0xOjgyODU0MDYyIDQxODE6WzBdNzo4MzQ2MjI3MiA0MTg4OlswXTE6ODM2NTY5MDQgNDE4OTpb MF03Ojg5MTI3MzgxIDQxOTY6WzBdMTo4OTU4NDMxMyA0MTk3OlswXTg6OTE1OTI5MzAgNDIwNTpb MF03OjkxNTkyOTQ1IDQyMTI6WzBdMTo5MTU5Mjk1MyA0MjEzOlswXTc6OTE1OTI5NjEgNDIyClNl cCAxNSAwODoyNzozOSB4bWFvIGtlcm5lbDogOlswXTg6OTE1OTI5NjkgNDIyODpbMF0xOjkxNTky OTg1IDQyMjk6WzBdODo5MTU5Mjk5MyA0MjM3OlswXTc6OTE1OTMwMDIgNDI0NDpbMF0xOjkxNTkz MDE3IDQyNDU6WzBdNzo5MTU5MzAyNSA0MjUyOlswXTE6OTE1OTMwMzMgNDI1MzpbMF04OjkxNTkz MDQxIDQyNjE6WzBdODo5MTU5MzA1NyA0MjY5OlswXTc6OTE1OTMwNjYgNDI3NjpbMF0xOjkxNjUw MTI1IDQyNzc6WzBdNzo5MTY1MDEzMyA0Mjg0OlswXTE6OTE2NTAxNDEgNDI4NTpbMF04OjkxNjUw MTQ5IDQyOTM6WzBdNzo5MTY1MDE1OCA0MzAwOlswXTg6OTE2NTAxNzIgNDMwODpbMF0xOjkxNjQ0 MzA0IDQzMDk6WzBdNzo5MTYzODA1NiA0MzE2OlswXTE6OTE2NDQzMDUgNDMxNzpbMF03OjkxNjUw MTgwIDQzMjQ6WzBdMTo5MTYzMDQ0OCA0MzI1OlswXTc6OTE2NDQyNTcgNDMzMjpbMF0xOjkxNjQ0 MzA2IDQzMzM6WzBdNzo5MTY0NDk3OCA0MzQwOlswXTE6OTE2NDUyNTEgNDM0MTpbMF03OjkxNjMx Njk2IDQzNDg6WzBdMTo5MTY0NDMwNyA0MzQ5OlswXTc6OTE2NDUyNTIgNDM1NjpbMF04OjkxNjQ0 MzA4IDQzNjQ6WzBdMTo5MTc2NDM5MyA0MzY1OlswXTE6OTIyNDQzMDkgNDM2NjpbMF02OjkyMjY3 NzE5IDQzNzI6WzBdMTo5Mjg5OTIxNiA0MzczOlswXTc6OTMxOTE2ODEgNDM4MDpbMF0xOjkzMjIw ODY0IDQzODE6WzBdNzo5MzIwNDUyMSA0Mzg4OlswXTE6OTMyMDQ1MzUgNDM4OTpbMF0xNTo5MzIw NDUzNyA0NDA0OlswXTE6OTc5NjA0NzEgNDQwNTpbMF04Ojk3OTYwNDc5IDQ0MTM6WzBdNzo5Nzk2 MDQ4OCA0NDIwOlswXTg6OTc5NjA1MDIgNDQyODpbMF0xOjk3OTYwNTExIDQ0Mjk6WzBdODo5Nzk2 MDUxOSA0NDM3OlswXTg6OTc5NjA1MjggNDQ0NTpbMF04Ojk3OTYwNTQzIDQ0NTM6WzBdNzo5Nzk2 MDU1MiA0NDYwOlswXTg6OTc5NjA1NjYgNDQ2ODpbMF0xOjk3OTYwNTc1IDQ0Njk6WzBdODo5Nzk2 MDU4MyA0NDc3OlswXTg6OTc5NjA1OTIgNDQ4NTpbMF03Ojk3OTYwNjA3IDQ0OTI6WzBdODoKU2Vw IDE1IDA4OjI3OjM5IHhtYW8ga2VybmVsOiAwNjE1IDQ1MDA6WzBdMTo5Nzk2MDYzMCA0NTAxOlsw XTc6OTgwNTAwODEgNDUwODpbMF0xOjk5NjI4MjM5IDQ1MDk6WzBdNzo5OTYyODI0NyA0NTE2Olsw XTE6OTk2MjgyNTUgNDUxNzpbMF03Ojk5OTY5NzcwIDQ1MjQ6WzBdODo5OTk2OTc3OCA0NTMyOlsw XTE6MTMyNTUyOTYwIDQ1MzM6WzBdNzoxMzYzMzMxNTMgNDU0MDpbMF0xOjE0MjYyOTA0NyA0NTQx OlswXTc6MTQyNzYwMDk2IDQ1NDg6WzBdODoxNDI3NTE5OTkgNDU1NjpbMF04OjE0Mjc0MTc2MSA0 NTY0OlswXTg6MTQyNzU2MDY2IDQ1NzI6WzBdMToxNDI3NTIwMDggNDU3MzpbMF03OjE0Mjc2MDEx OCA0NTgwOlswXTg6MTQyNzUyMDA5IDQ1ODg6WzBdODoxNDI3NTYwNzUgNDU5NjpbMF0xOjE0Mjcz OTEyNCA0NTk3OlswXTc6MTQyNzQ3NzI4IDQ2MDQ6WzBdMToxNDI3NjIyODggNDYwNTpbMF03OjE0 Mjc0MTc3NyA0NjEyOlswXTE6MTQyNzUyMDE3IDQ2MTM6WzBdNzoxNDI3Mzc5NDggNDYyMDpbMF04 OjE0Mjc1MjAxOCA0NjI4OlswXTg6MTQyNzU2MDgzIDQ2MzY6WzBdMToxNDI3NTc4MDAgNDYzNzpb MF03OjE0Mjc1MjgzMiA0NjQ0OlswXTE6MTQyNzU3ODAxIDQ2NDU6WzBdNzoxNDI3NTQ5OTMgNDY1 MjpbMF0xOjE0Mjc1MjI0MiA0NjUzOlswXTc6MTQzNTg5Mzc4IDQ2NjA6WzBdMToxNDM3NzYwMDAg NDY2MTpbMF04OjE0Mzc3NjAwOCA0NjY5OlswXTg6MTQzNzc2MDE3IDQ2Nzc6WzBdMToxNDM3NzYw MzIgNDY3ODpbMF03OjE0Mzc3NjAzNCA0Njg1OlswXTE6MTQzNzgwNjUxIDQ2ODY6WzBdNzoxNDM3 ODA2NTMgNDY5MzpbMF0xOjE0Mzc5MjExOSA0Njk0OlswXTc6MTQ1NDU5MDU5IDQ3MDE6WzBdMTox NDYwMDYwMTYgNDcwMjpbMF03OjE0NjA0OTAzMSA0NzA5OlswXTE6MTQ2MDUzNzI3IDQ3MTA6WzBd NzoxNDYwNTM3MjkgNDcxNzpbMF04OjE0NjA1Mzc0MyA0NzI1OlswXTg6MTQ2MDUzNzUyIDQ3MzM6 WzBdMToxNDYwNTM3NjggNDczNDpbMF03OjE0NjEwNjYwMyA0NzQxOlswXTE6MTQ2MDc5OQpTZXAg MTUgMDg6Mjc6MzkgeG1hbyBrZXJuZWw6IDc0MjpbMF04OjE0NjA4OTM5NyA0NzUwOlswXTg6MTQ2 MDg5NDA2IDQ3NTg6WzBdNzoxNDYxMDY2MjQgNDc2NTpbMF0xOjE0NjIyMDI4OCA0NzY2OlswXTc6 MTQ2NDUwNDMyIDQ3NzM6WzBdMToxNDgwMTc3NzYgNDc3NDpbMF03OjE0ODE2MjE5NiA0NzgxOlsw XTE2OjE0ODg4ODA3MSA0Nzk3OlswXTE6MTQ4OTQwNDgzIDQ3OTg6WzBdNzoxNDg5NDA0ODUgNDgw NTpbMF0xOjE0ODk1NTA3NyA0ODA2OlswXTc6MTQ4OTU1MDc5IDQ4MTM6WzBdODoxNDg5MzE0MzQg NDgyMTpbMF04OjE0OTU1NjI4MSA0ODI5OlswXTg6MTQ5NjI2ODgwIDQ4Mzc6WzBdMToxNDk2MjY4 ODkgNDgzODpbMF04OjE0OTYyNjg5NyA0ODQ2OlswXTc6MTQ5Nzk0MjgwIDQ4NTM6WzBdODoxNDk4 OTM2MzkgNDg2MTpbMF0xOjE0OTk5MTU1NCA0ODYyOlswXTg6MTQ5OTkxNTYyIDQ4NzA6WzBdODox NDk5OTE1ODcgNDg3ODpbMF03OjE0OTk5MTYwMiA0ODg1OlswXTE6MTUwMDU2MzU4IDQ4ODY6WzBd NzoxNTE1NDE3NjAgNDg5MzpbMF0xOjE1MzA4NDE3NSA0ODk0OlswXTc6MTUzMzMwODU1IDQ5MDE6 WzBdMToxNTMzMzIyNzcgNDkwMjpbMF03OjE1MzY4NjA4MCA0OTA5OlswXTE6MTYwMDIyNzE3IDQ5 MTA6WzBdMTU6MTYwMzYwNDA2IDQ5MjU6WzBdMToxNjAzNjA0MjIgNDkyNjpbMF04OjE2MDM2MDQz MCA0OTM0OlswXTc6MTYwNTEyMzg0IDQ5NDE6WzBdMToxNjA1MTIzOTggNDk0MjpbMF04OjE2MDUx MjQwMCA0OTUwOlswXTE2OjE2MDUxMjQxNSA0OTY2OlswXTc6MTYwNzgxMjg4IDQ5NzM6WzBdMTox NjA3OTc0NDAgNDk3NDpbMF03OjE2MDgxNTEyMSA0OTgxOlswXTE6MTYwODE1MTI5IDQ5ODI6WzBd MTAzOjE2MDgxNTEzNyA1MDg1OlswXTE6MTYxNDUwMjQwIDUwODY6WzBdMzI6MTYxNTAxMjQ5IDUx MTg6WzBdODE6MTYxNDcwNTAxIDUxOTk6WzBdNDA6MTYxNzQ4NDgwIDUyMzk6WzBdNzoxNjE3MzAw ODggNTI0NjpbMF0xNzoxNjE3NDg1MjAgNTI2MzpbMF04OjE2MjA0ODAwNyA1MjcxOlswClNlcCAx NSAwODoyNzozOSB4bWFvIGtlcm5lbDogNjIwNDgwMTYgNTI3ODpbMF04OjE2MjA0ODAzMCA1Mjg2 OlswXTg6MTYyMDQ4MDQ2IDUyOTQ6WzBdMToxNjIwODE5NzkgNTI5NTpbMF03OjE2MjEyMzI0MiA1 MzAyOlswXTk6MTYyMDgxOTgwIDUzMTE6WzBdNzoyMDE2ODc0MzUgNTMxODpbMF0xOjE2MjA4MTk4 OSA1MzE5OlswXTc6MjA1MjQ3MDUxIDUzMjY6WzBdODoxNjIwODE5OTAgNTMzNDpbMF0xOjE2MjM4 Mzg3MiA1MzM1OlswXTc6MTYyMDgxOTk4IDUzNDI6WzBdMToxNjI3ODUzMDMgNTM0MzpbMF03OjE2 MzA3NzQxOCA1MzUwOlswXTE6MTYyMDgyMDA1IDUzNTE6WzBdNzoxNjIxNDQ4NjMgNTM1ODpbMF04 OjE2MjA4MjAwNiA1MzY2OlswXTE6MTYyMTQ0ODcwIDUzNjc6WzBdNzoxNjIwODIwMTQgNTM3NDpb MF0xOjE2MjE0NDg3MSA1Mzc1OlswXTc6MTYyMDgyMDIxIDUzODI6WzBdMToxNjIzNDExMjAgNTM4 MzpbMF03OjE2MjA0ODExOCA1MzkwOlswXTg4OjE2MzkwNjgxNiA1NDc4OlswXTE6MTY0OTIwMDY1 IDU0Nzk6WzBdODoxNjMzNjAxOTQgNTQ4NzpbMF03OjE2NDM5ODA4MCA1NDk0OlswXTMyOjE2NTE4 NDc2OCA1NTI2OlswXTg6MTY1MTg1NTY1IDU1MzQ6WzBdODoxNjUxODQ4MDAgNTU0MjpbMF04OjE2 NTE4NTU3MyA1NTUwOlswXTI0MToxNjU2ODkwNDAgNTc5MTpbMF0zNTM6MTY4OTEwODQ4IDYxNDQ6 WzBdNzoxNjg5MDI2OTUgNjE1MTpbMF0xOjE2ODg5NTQ4OCA2MTUyOlswXTc6MTY4ODk1NDg5IDYx NTk6WzBdODoxNjg5MDI3MDIgNjE2NzpbMF04OjE2ODg5NTQ5NiA2MTc1OlswXTk6MTY4OTAyNzEx IDYxODQ6WzBdMTU6MTY4OTAyNzIxIDYxOTk6WzBdMToxNjg4OTU1MjAgNjIwMDpbMF04OjE2ODkw MjczNiA2MjA4OlswXTg6MTY5MjQzNjcxIDYyMTY6WzBdMToxNzU2NTI2NDcgNjIxNzpbMF03OjE3 NjEwMzQyNCA2MjI0OlswXTE6MTc2MDk2NzY4IDYyMjU6WzBdNzoxNzYxMDM0MzEgNjIzMjpbMF04 OjE3NjExODY1OSA2MjQwOlswXTE6MTc2MTAzNDM5IDYyNDE6WzBdNzoyMDU2MjE1NDAKU2VwIDE1 IDA4OjI3OjM5IHhtYW8ga2VybmVsOiA4OlswXTg6MjA1ODMzNzQ3IDYyNTY6WzBdODoyMDU4MzM3 NjMgNjI2NDpbMF0xOjIwNTgzMzc3OCA2MjY1OlswXTc6MjA1ODMzNzgwIDYyNzI6WzBdMToyMDU4 MzM4MDIgNjI3MzpbMF03OjIwNTgzMzgwNCA2MjgwOlswXTE6MjA1ODMzODE4IDYyODE6WzBdNzoy MDU4MzM4MjAgNjI4ODpbMF04OjIwNTgzMzgzNCA2Mjk2OlswXTE6MjA1ODMzODQzIDYyOTc6WzBd NzoyMDU4MzM4NTEgNjMwNDpbMF04OjIwNjcwNDY1MSA2MzEyOlswXTE6MjA2NzA0NjYwIDYzMTM6 WzBdNzoyMDY3MDQ2NjggNjMyMDpbMF04OjIwNjcwNDY3NiA2MzI4OlswXTg6MjA2OTA1MjY0IDYz MzY6WzBdMToyMDY5NzU0NjIgNjMzNzpbMF03OjIwNzAxMDAzMiA2MzQ0OlswXTE6MjA3MDEwMDQw IDYzNDU6WzBdNzoyMDcwMTEyNTggNjM1MjpbMF0xOjIwNzAxMDA0OCA2MzUzOlswXTg6MjA3MDEx MjY1IDYzNjE6WzBdNzoyMDg5NjQ4NjQgNjM2ODpbMF0xOjIwOTIzNDcwMyA2MzY5OlswXTc6MjA5 MjM0NzExIDYzNzY6WzBdMToyMDkyNTQ0MDAgNjM3NzpbMF03OjIwOTI1NDQwMiA2Mzg0OlswXTE6 MjA5MzQ2NTYwIDYzODU6WzBdODoyMDk0NzI3MzcgNjM5MzpbMF03OjIwOTU1OTA1OSA2NDAwOlsw XTE6MjA5NTU0OTc0IDY0MDE6WzBdNzo4MTIzNDY5NyA2NDA4OlswXTU2OjgxMzk1NzEyIDY0NjQ6 WzBdODo4MTM5Nzc1MyA2NDcyOlswXTg6ODE0MjE4MjQgNjQ4MDpbMF04OjgxMzk1NzY4IDY0ODg6 WzBdODo4MTM5Nzc2MSA2NDk2OlswXTg6ODE0MjE4MzIgNjUwNDpbMF04OjgxMzk1Nzc2IDY1MTI6 WzBdODo4MTM5Nzc2OSA2NTIwOlswXTE6ODE2NTkyMjEgNjUyMTpbMF03OjgyNDE2MzUzIDY1Mjg6 WzBdMToxMDM4NTAwNDggNjUyOTpbMF03OjExNTI3NjkgNjUzNjpbMF0xOjE3ODYzNTIgNjUzNzpb MF04OjIzNjM2NDggNjU0NTpbMF03OjI5MDgxMzIgNjU1MjpbMF0xOjUwNjY4NTYwIDY1NTM6WzBd Nzo1MTAzNzkzMSA2NTYwOlswXTE6NTExNjEzMjYgNjU2MTpbMF03OjUxMjkzNDM5IApTZXAgMTUg MDg6Mjc6MzkgeG1hbyBrZXJuZWw6IDpbMF04OjUxNDA5MDY4IDY1NzY6WzBdODo1MTM5MzAwNyA2 NTg0OlswXTg6NTE0MDkwNzYgNjU5MjpbMF0xOjUxMzkzMDE2IDY1OTM6WzBdNzo1MTM5MDE5NiA2 NjAwOlswXTE6NTEzOTI3NjEgNjYwMTpbMF03OjUxMzkwNTczIDY2MDg6WzBdODo1MTQwOTA4NSA2 NjE2OlswXTg6NTEzOTMwMjQgNjYyNDpbMF0xOjUxMzkyNzY5IDY2MjU6WzBdNzo1MTM4OTY3NiA2 NjMyOlswXTE6NTE0MDkwOTMgNjYzMzpbMF03OjUxNDMwMTc3IDY2NDA6WzBdODo1MTQ3MDQ4MiA2 NjQ4OlswXTE6NTE0NzA0OTcgNjY0OTpbMF03OjUxNDcwNDk5IDY2NTY6WzBdODo1MTUzNjEzNSA2 NjY0OlswXTg6NTE1MzYxNDQgNjY3MjpbMF0xOjUxNTM2MTU5IDY2NzM6WzBdNzo1MTUzNjE2MSA2 NjgwOlswXTE6NTE1MzYxNzUgNjY4MTpbMF03OjUxNTM2MTc3IDY2ODg6WzBdMTo1MTUzNjE5MSA2 Njg5OlswXTc6NTE2MjAzODkgNjY5NjpbMF0xOjUxNzM2ODMyIDY2OTc6WzBdNzo1MTczNjg0MCA2 NzA0OlswXTE6NTE3MzY4NDggNjcwNTpbMF03OjUxNzM2ODU2IDY3MTI6WzBdMTo1MTczNjg2NCA2 NzEzOlswXTk6NTE3MzY4NzIgNjcyMjpbMF04OjUxNzM2ODgyIDY3MzA6WzBdNzo1MTczNjg5NyA2 NzM3OlswXTE6NTE3MzY5MDUgNjczODpbMF03OjUxNzM2OTEzIDY3NDU6WzBdMToxNjIzNDAxNjQg ClNlcCAxNSAwODoyNzozOSB4bWFvIGtlcm5lbDogbmV4dCAzNDY4IG5leHRleDogMzQ2ODo1Nzky MTY0MzpbMF0gMTQKU2VwIDE1IDA4OjI3OjM5IHhtYW8ga2VybmVsOiBvcmlnX2V4OiAzNDY3OjU3 OTIxNjQyOlswXSAxNQpTZXAgMTUgMDg6Mjc6MzkgeG1hbyBrZXJuZWw6ID09PT09PT09PT09PWV4 dGVudHMgb3ZlcmxhcGVkClNlcCAxNSAwODoyNzozOSB4bWFvIGtlcm5lbDogb2xkX2RlcHRoIDIg ZGVwdGggMiBvbGRfcGF0aCBmZmZmODgwMTg4NjdjY2MwIHBhdGggZmZmZjg4MDE4ODY3Y2NjMCBu ZXh0X2hhc19mcmVlIDIgbmV4dCAzNDY4ClNlcCAxNSAwODoyNzozOSB4bWFvIGtlcm5lbDogYmFj a19leDogMTUwMzc6MzU5NjM1ODE6WzBdIDEzNDcKU2VwIDE1IDA4OjI3OjM5IHhtYW8ga2VybmVs OiBpbnNlcnQgMzQ2ODo1NzkyMTY0MzpbMV0xNCBiZWZvcmU6IG5lYXJlc3QgMHhmZmZmODgwMTJk MWFhMDBjLCBtb3ZlIDQwNjggZnJvbSAweGZmZmY4ODAxMmQxYWEwMTggdG8gMHhmZmZmODgwMTJk MWFhMDI0ClNlcCAxNSAwODoyNzozOSB4bWFvIGtlcm5lbDogd3liLCBpbnNlcnQgZXh0ZW50IDog MzQ2ODpbMV0xNDo1NzkyMTY0Mywgb3JpZyBleHRlbnQgOiAzNDY3OlswXTE1OjU3OTIxNjQyLCBv bGQgZXh0ZW50IDogMzQ2NzpbMV0xNTo1NzkyMTY0MiwgbW9kZSA6IDEsIGlibG9jayA6IDM0Njcs IG1heF9ibG9ja3MgOiAxClNlcCAxNSAwODoyNzozOSB4bWFvIGtlcm5lbDogRGlzcGxheWluZyBs ZWFmIGV4dGVudHMgZm9yIGlub2RlIDEyMzM5MDA0ClNlcCAxNSAwODoyNzozOSB4bWFvIGtlcm5l bDogMzQ2ODpbMF0xNDo1NzkyMTY0MyAzNDgyOlswXTE6NTc5MjE2NjQgMzQ4MzpbMF03OjU3OTIx NjY2IDM0OTA6WzBdMTo1NzkyMTY4MCAzNDkxOlswXTg6NTc5MjE2ODIgMzQ5OTpbMF03OjU3OTIx NjkxIDM1MDY6WzBdODo1NzkyMTcwNSAzNTE0OlswXTE6NTc5MjE3MTQgMzUxNTpbMF03OjU3OTIx NzIyIDM1MjI6WzBdNDE6NTc5MTY2ODMgMzU2MzpbMF03OjU4MTU5NzY3IDM1NzA6WzBdMTo1ODE1 OTc4MSAzNTcxOlswXTc6NTgyMzg5OTIgMzU3ODpbMF0xOjU4Mjg4MTQ0IDM1Nzk6WzBdNzo1ODMy Nzc1MCAzNTg2OlswXTE6NTg1Nzk5NjkgMzU4NzpbMF03OjU4OTU0ODM4IDM1OTQ6WzBdMTo1OTAw NjY0MSAzNTk1OlswXTc6NTkwMDY2NDMgMzYwMjpbMF0xOjU5MDA2NjU3IDM2MDM6WzBdNzo1OTAw NjY1OSAzNjEwOlswXTg6NTkwMDY2NzMgMzYxODpbMF04OjU5MDA2Njg4IDM2MjY6WzBdNDcwOjU4 OTgyNjU4IDQwOTY6WzBdMzo1ODk4NzczMiA0MDk5OlswXTE6NTg5OTI2NTUgNDEwMDpbMF03OjU5 MTQzMjUzIDQxMDc6WzBdMTo1OTE3MTg0MCA0MTA4OlswXTc6NTkxODM4NzggNDExNTpbMF0xOjU5 MTkyODg2IDQxMTY6WzBdODo1OTU5MzQ2MyA0MTI0OlswXTg6NTk2Njk0ODQgNDEzMjpbMF03Ojcz MDg2NTM4IDQxMzk6WzBdMTo3MzM1MjgwMSA0MTQwOlswXTc6NzMzMzkyNzMgNDE0NzpbMF0xOjcz NTI2MjgwIDQxNDg6WzBdODo3ODIyOTAxMiA0MTU2OlswXTE6NzgyMjkwMjEgNDE1NzpbMF03Ojc4 ODE4Mzg4IDQxNjQ6WzBdMTo3OTA2OTM4MyA0MTY1OlswXTc6Nzk0Mjg2MTYgNDE3MjpbMF0xOjgw NDkwOTI1IDQxNzM6WzBdNzo4MTQzOTQ4OCA0MTgwOlswXTE6ODI4NTQwNjIgNDE4MTpbMF03Ojgz NDYyMjcyIDQxODg6WzBdMTo4MzY1NjkwNCA0MTg5OlswXTc6ODkxMjczODEgNDE5NjpbMF0xOjg5 NTg0MzEzIDQxOTc6WzBdODo5MTU5MjkzMCA0MjA1OlswXTc6OTE1OTI5NDUgNDIxMjpbMF0xOjkx NTkyOTUzIDQyMTM6WzBdNzo5MTU5Mjk2MSA0MjIKU2VwIDE1IDA4OjI3OjM5IHhtYW8ga2VybmVs OiA6WzBdODo5MTU5Mjk2OSA0MjI4OlswXTE6OTE1OTI5ODUgNDIyOTpbMF04OjkxNTkyOTkzIDQy Mzc6WzBdNzo5MTU5MzAwMiA0MjQ0OlswXTE6OTE1OTMwMTcgNDI0NTpbMF03OjkxNTkzMDI1IDQy NTI6WzBdMTo5MTU5MzAzMyA0MjUzOlswXTg6OTE1OTMwNDEgNDI2MTpbMF04OjkxNTkzMDU3IDQy Njk6WzBdNzo5MTU5MzA2NiA0Mjc2OlswXTE6OTE2NTAxMjUgNDI3NzpbMF03OjkxNjUwMTMzIDQy ODQ6WzBdMTo5MTY1MDE0MSA0Mjg1OlswXTg6OTE2NTAxNDkgNDI5MzpbMF03OjkxNjUwMTU4IDQz MDA6WzBdODo5MTY1MDE3MiA0MzA4OlswXTE6OTE2NDQzMDQgNDMwOTpbMF03OjkxNjM4MDU2IDQz MTY6WzBdMTo5MTY0NDMwNSA0MzE3OlswXTc6OTE2NTAxODAgNDMyNDpbMF0xOjkxNjMwNDQ4IDQz MjU6WzBdNzo5MTY0NDI1NyA0MzMyOlswXTE6OTE2NDQzMDYgNDMzMzpbMF03OjkxNjQ0OTc4IDQz NDA6WzBdMTo5MTY0NTI1MSA0MzQxOlswXTc6OTE2MzE2OTYgNDM0ODpbMF0xOjkxNjQ0MzA3IDQz NDk6WzBdNzo5MTY0NTI1MiA0MzU2OlswXTg6OTE2NDQzMDggNDM2NDpbMF0xOjkxNzY0MzkzIDQz NjU6WzBdMTo5MjI0NDMwOSA0MzY2OlswXTY6OTIyNjc3MTkgNDM3MjpbMF0xOjkyODk5MjE2IDQz NzM6WzBdNzo5MzE5MTY4MSA0MzgwOlswXTE6OTMyMjA4NjQgNDM4MTpbMF03OjkzMjA0NTIxIDQz ODg6WzBdMTo5MzIwNDUzNSA0Mzg5OlswXTE1OjkzMjA0NTM3IDQ0MDQ6WzBdMTo5Nzk2MDQ3MSA0 NDA1OlswXTg6OTc5NjA0NzkgNDQxMzpbMF03Ojk3OTYwNDg4IDQ0MjA6WzBdODo5Nzk2MDUwMiA0 NDI4OlswXTE6OTc5NjA1MTEgNDQyOTpbMF04Ojk3OTYwNTE5IDQ0Mzc6WzBdODo5Nzk2MDUyOCA0 NDQ1OlswXTg6OTc5NjA1NDMgNDQ1MzpbMF03Ojk3OTYwNTUyIDQ0NjA6WzBdODo5Nzk2MDU2NiA0 NDY4OlswXTE6OTc5NjA1NzUgNDQ2OTpbMF04Ojk3OTYwNTgzIDQ0Nzc6WzBdODo5Nzk2MDU5MiA0 NDg1OlswXTc6OTc5NjA2MDcgNDQ5MjpbMF04OgpTZXAgMTUgMDg6Mjc6NDAgeG1hbyBrZXJuZWw6 IDA2MTUgNDUwMDpbMF0xOjk3OTYwNjMwIDQ1MDE6WzBdNzo5ODA1MDA4MSA0NTA4OlswXTE6OTk2 MjgyMzkgNDUwOTpbMF03Ojk5NjI4MjQ3IDQ1MTY6WzBdMTo5OTYyODI1NSA0NTE3OlswXTc6OTk5 Njk3NzAgNDUyNDpbMF04Ojk5OTY5Nzc4IDQ1MzI6WzBdMToxMzI1NTI5NjAgNDUzMzpbMF03OjEz NjMzMzE1MyA0NTQwOlswXTE6MTQyNjI5MDQ3IDQ1NDE6WzBdNzoxNDI3NjAwOTYgNDU0ODpbMF04 OjE0Mjc1MTk5OSA0NTU2OlswXTg6MTQyNzQxNzYxIDQ1NjQ6WzBdODoxNDI3NTYwNjYgNDU3Mjpb MF0xOjE0Mjc1MjAwOCA0NTczOlswXTc6MTQyNzYwMTE4IDQ1ODA6WzBdODoxNDI3NTIwMDkgNDU4 ODpbMF04OjE0Mjc1NjA3NSA0NTk2OlswXTE6MTQyNzM5MTI0IDQ1OTc6WzBdNzoxNDI3NDc3Mjgg NDYwNDpbMF0xOjE0Mjc2MjI4OCA0NjA1OlswXTc6MTQyNzQxNzc3IDQ2MTI6WzBdMToxNDI3NTIw MTcgNDYxMzpbMF03OjE0MjczNzk0OCA0NjIwOlswXTg6MTQyNzUyMDE4IDQ2Mjg6WzBdODoxNDI3 NTYwODMgNDYzNjpbMF0xOjE0Mjc1NzgwMCA0NjM3OlswXTc6MTQyNzUyODMyIDQ2NDQ6WzBdMTox NDI3NTc4MDEgNDY0NTpbMF03OjE0Mjc1NDk5MyA0NjUyOlswXTE6MTQyNzUyMjQyIDQ2NTM6WzBd NzoxNDM1ODkzNzggNDY2MDpbMF0xOjE0Mzc3NjAwMCA0NjYxOlswXTg6MTQzNzc2MDA4IDQ2Njk6 WzBdODoxNDM3NzYwMTcgNDY3NzpbMF0xOjE0Mzc3NjAzMiA0Njc4OlswXTc6MTQzNzc2MDM0IDQ2 ODU6WzBdMToxNDM3ODA2NTEgNDY4NjpbMF03OjE0Mzc4MDY1MyA0NjkzOlswXTE6MTQzNzkyMTE5 IDQ2OTQ6WzBdNzoxNDU0NTkwNTkgNDcwMTpbMF0xOjE0NjAwNjAxNiA0NzAyOlswXTc6MTQ2MDQ5 MDMxIDQ3MDk6WzBdMToxNDYwNTM3MjcgNDcxMDpbMF03OjE0NjA1MzcyOSA0NzE3OlswXTg6MTQ2 MDUzNzQzIDQ3MjU6WzBdODoxNDYwNTM3NTIgNDczMzpbMF0xOjE0NjA1Mzc2OCA0NzM0OlswXTc6 MTQ2MTA2NjAzIDQ3NDE6WzBdMToxNDYwNzk5ClNlcCAxNSAwODoyNzo0MCB4bWFvIGtlcm5lbDog NzQyOlswXTg6MTQ2MDg5Mzk3IDQ3NTA6WzBdODoxNDYwODk0MDYgNDc1ODpbMF03OjE0NjEwNjYy NCA0NzY1OlswXTE6MTQ2MjIwMjg4IDQ3NjY6WzBdNzoxNDY0NTA0MzIgNDc3MzpbMF0xOjE0ODAx Nzc3NiA0Nzc0OlswXTc6MTQ4MTYyMTk2IDQ3ODE6WzBdMTY6MTQ4ODg4MDcxIDQ3OTc6WzBdMTox NDg5NDA0ODMgNDc5ODpbMF03OjE0ODk0MDQ4NSA0ODA1OlswXTE6MTQ4OTU1MDc3IDQ4MDY6WzBd NzoxNDg5NTUwNzkgNDgxMzpbMF04OjE0ODkzMTQzNCA0ODIxOlswXTg6MTQ5NTU2MjgxIDQ4Mjk6 WzBdODoxNDk2MjY4ODAgNDgzNzpbMF0xOjE0OTYyNjg4OSA0ODM4OlswXTg6MTQ5NjI2ODk3IDQ4 NDY6WzBdNzoxNDk3OTQyODAgNDg1MzpbMF04OjE0OTg5MzYzOSA0ODYxOlswXTE6MTQ5OTkxNTU0 IDQ4NjI6WzBdODoxNDk5OTE1NjIgNDg3MDpbMF04OjE0OTk5MTU4NyA0ODc4OlswXTc6MTQ5OTkx NjAyIDQ4ODU6WzBdMToxNTAwNTYzNTggNDg4NjpbMF03OjE1MTU0MTc2MCA0ODkzOlswXTE6MTUz MDg0MTc1IDQ4OTQ6WzBdNzoxNTMzMzA4NTUgNDkwMTpbMF0xOjE1MzMzMjI3NyA0OTAyOlswXTc6 MTUzNjg2MDgwIDQ5MDk6WzBdMToxNjAwMjI3MTcgNDkxMDpbMF0xNToxNjAzNjA0MDYgNDkyNTpb MF0xOjE2MDM2MDQyMiA0OTI2OlswXTg6MTYwMzYwNDMwIDQ5MzQ6WzBdNzoxNjA1MTIzODQgNDk0 MTpbMF0xOjE2MDUxMjM5OCA0OTQyOlswXTg6MTYwNTEyNDAwIDQ5NTA6WzBdMTY6MTYwNTEyNDE1 IDQ5NjY6WzBdNzoxNjA3ODEyODggNDk3MzpbMF0xOjE2MDc5NzQ0MCA0OTc0OlswXTc6MTYwODE1 MTIxIDQ5ODE6WzBdMToxNjA4MTUxMjkgNDk4MjpbMF0xMDM6MTYwODE1MTM3IDUwODU6WzBdMTox NjE0NTAyNDAgNTA4NjpbMF0zMjoxNjE1MDEyNDkgNTExODpbMF04MToxNjE0NzA1MDEgNTE5OTpb MF00MDoxNjE3NDg0ODAgNTIzOTpbMF03OjE2MTczMDA4OCA1MjQ2OlswXTE3OjE2MTc0ODUyMCA1 MjYzOlswXTg6MTYyMDQ4MDA3IDUyNzE6WzAKU2VwIDE1IDA4OjI3OjQwIHhtYW8ga2VybmVsOiA2 MjA0ODAxNiA1Mjc4OlswXTg6MTYyMDQ4MDMwIDUyODY6WzBdODoxNjIwNDgwNDYgNTI5NDpbMF0x OjE2MjA4MTk3OSA1Mjk1OlswXTc6MTYyMTIzMjQyIDUzMDI6WzBdOToxNjIwODE5ODAgNTMxMTpb MF03OjIwMTY4NzQzNSA1MzE4OlswXTE6MTYyMDgxOTg5IDUzMTk6WzBdNzoyMDUyNDcwNTEgNTMy NjpbMF04OjE2MjA4MTk5MCA1MzM0OlswXTE6MTYyMzgzODcyIDUzMzU6WzBdNzoxNjIwODE5OTgg NTM0MjpbMF0xOjE2Mjc4NTMwMyA1MzQzOlswXTc6MTYzMDc3NDE4IDUzNTA6WzBdMToxNjIwODIw MDUgNTM1MTpbMF03OjE2MjE0NDg2MyA1MzU4OlswXTg6MTYyMDgyMDA2IDUzNjY6WzBdMToxNjIx NDQ4NzAgNTM2NzpbMF03OjE2MjA4MjAxNCA1Mzc0OlswXTE6MTYyMTQ0ODcxIDUzNzU6WzBdNzox NjIwODIwMjEgNTM4MjpbMF0xOjE2MjM0MTEyMCA1MzgzOlswXTc6MTYyMDQ4MTE4IDUzOTA6WzBd ODg6MTYzOTA2ODE2IDU0Nzg6WzBdMToxNjQ5MjAwNjUgNTQ3OTpbMF04OjE2MzM2MDE5NCA1NDg3 OlswXTc6MTY0Mzk4MDgwIDU0OTQ6WzBdMzI6MTY1MTg0NzY4IDU1MjY6WzBdODoxNjUxODU1NjUg NTUzNDpbMF04OjE2NTE4NDgwMCA1NTQyOlswXTg6MTY1MTg1NTczIDU1NTA6WzBdMjQxOjE2NTY4 OTA0MCA1NzkxOlswXTM1MzoxNjg5MTA4NDggNjE0NDpbMF03OjE2ODkwMjY5NSA2MTUxOlswXTE6 MTY4ODk1NDg4IDYxNTI6WzBdNzoxNjg4OTU0ODkgNjE1OTpbMF04OjE2ODkwMjcwMiA2MTY3Olsw XTg6MTY4ODk1NDk2IDYxNzU6WzBdOToxNjg5MDI3MTEgNjE4NDpbMF0xNToxNjg5MDI3MjEgNjE5 OTpbMF0xOjE2ODg5NTUyMCA2MjAwOlswXTg6MTY4OTAyNzM2IDYyMDg6WzBdODoxNjkyNDM2NzEg NjIxNjpbMF0xOjE3NTY1MjY0NyA2MjE3OlswXTc6MTc2MTAzNDI0IDYyMjQ6WzBdMToxNzYwOTY3 NjggNjIyNTpbMF03OjE3NjEwMzQzMSA2MjMyOlswXTg6MTc2MTE4NjU5IDYyNDA6WzBdMToxNzYx MDM0MzkgNjI0MTpbMF03OjIwNTYyMTU0MApTZXAgMTUgMDg6Mjc6NDAgeG1hbyBrZXJuZWw6IDg6 WzBdODoyMDU4MzM3NDcgNjI1NjpbMF04OjIwNTgzMzc2MyA2MjY0OlswXTE6MjA1ODMzNzc4IDYy NjU6WzBdNzoyMDU4MzM3ODAgNjI3MjpbMF0xOjIwNTgzMzgwMiA2MjczOlswXTc6MjA1ODMzODA0 IDYyODA6WzBdMToyMDU4MzM4MTggNjI4MTpbMF03OjIwNTgzMzgyMCA2Mjg4OlswXTg6MjA1ODMz ODM0IDYyOTY6WzBdMToyMDU4MzM4NDMgNjI5NzpbMF03OjIwNTgzMzg1MSA2MzA0OlswXTg6MjA2 NzA0NjUxIDYzMTI6WzBdMToyMDY3MDQ2NjAgNjMxMzpbMF03OjIwNjcwNDY2OCA2MzIwOlswXTg6 MjA2NzA0Njc2IDYzMjg6WzBdODoyMDY5MDUyNjQgNjMzNjpbMF0xOjIwNjk3NTQ2MiA2MzM3Olsw XTc6MjA3MDEwMDMyIDYzNDQ6WzBdMToyMDcwMTAwNDAgNjM0NTpbMF03OjIwNzAxMTI1OCA2MzUy OlswXTE6MjA3MDEwMDQ4IDYzNTM6WzBdODoyMDcwMTEyNjUgNjM2MTpbMF03OjIwODk2NDg2NCA2 MzY4OlswXTE6MjA5MjM0NzAzIDYzNjk6WzBdNzoyMDkyMzQ3MTEgNjM3NjpbMF0xOjIwOTI1NDQw MCA2Mzc3OlswXTc6MjA5MjU0NDAyIDYzODQ6WzBdMToyMDkzNDY1NjAgNjM4NTpbMF04OjIwOTQ3 MjczNyA2MzkzOlswXTc6MjA5NTU5MDU5IDY0MDA6WzBdMToyMDk1NTQ5NzQgNjQwMTpbMF03Ojgx MjM0Njk3IDY0MDg6WzBdNTY6ODEzOTU3MTIgNjQ2NDpbMF04OjgxMzk3NzUzIDY0NzI6WzBdODo4 MTQyMTgyNCA2NDgwOlswXTg6ODEzOTU3NjggNjQ4ODpbMF04OjgxMzk3NzYxIDY0OTY6WzBdODo4 MTQyMTgzMiA2NTA0OlswXTg6ODEzOTU3NzYgNjUxMjpbMF04OjgxMzk3NzY5IDY1MjA6WzBdMTo4 MTY1OTIyMSA2NTIxOlswXTc6ODI0MTYzNTMgNjUyODpbMF0xOjEwMzg1MDA0OCA2NTI5OlswXTc6 MTE1Mjc2OSA2NTM2OlswXTE6MTc4NjM1MiA2NTM3OlswXTg6MjM2MzY0OCA2NTQ1OlswXTc6Mjkw ODEzMiA2NTUyOlswXTE6NTA2Njg1NjAgNjU1MzpbMF03OjUxMDM3OTMxIDY1NjA6WzBdMTo1MTE2 MTMyNiA2NTYxOlswXTc6NTEyOTM0MzkgClNlcCAxNSAwODoyNzo0MCB4bWFvIGtlcm5lbDogOlsw XTg6NTE0MDkwNjggNjU3NjpbMF04OjUxMzkzMDA3IDY1ODQ6WzBdODo1MTQwOTA3NiA2NTkyOlsw XTE6NTEzOTMwMTYgNjU5MzpbMF03OjUxMzkwMTk2IDY2MDA6WzBdMTo1MTM5Mjc2MSA2NjAxOlsw XTc6NTEzOTA1NzMgNjYwODpbMF04OjUxNDA5MDg1IDY2MTY6WzBdODo1MTM5MzAyNCA2NjI0Olsw XTE6NTEzOTI3NjkgNjYyNTpbMF03OjUxMzg5Njc2IDY2MzI6WzBdMTo1MTQwOTA5MyA2NjMzOlsw XTc6NTE0MzAxNzcgNjY0MDpbMF04OjUxNDcwNDgyIDY2NDg6WzBdMTo1MTQ3MDQ5NyA2NjQ5Olsw XTc6NTE0NzA0OTkgNjY1NjpbMF04OjUxNTM2MTM1IDY2NjQ6WzBdODo1MTUzNjE0NCA2NjcyOlsw XTE6NTE1MzYxNTkgNjY3MzpbMF03OjUxNTM2MTYxIDY2ODA6WzBdMTo1MTUzNjE3NSA2NjgxOlsw XTc6NTE1MzYxNzcgNjY4ODpbMF0xOjUxNTM2MTkxIDY2ODk6WzBdNzo1MTYyMDM4OSA2Njk2Olsw XTE6NTE3MzY4MzIgNjY5NzpbMF03OjUxNzM2ODQwIDY3MDQ6WzBdMTo1MTczNjg0OCA2NzA1Olsw XTc6NTE3MzY4NTYgNjcxMjpbMF0xOjUxNzM2ODY0IDY3MTM6WzBdOTo1MTczNjg3MiA2NzIyOlsw XTg6NTE3MzY4ODIgNjczMDpbMF03OjUxNzM2ODk3IDY3Mzc6WzBdMTo1MTczNjkwNSA2NzM4Olsw XTc6NTE3MzY5MTMgNjc0NTpbMF0xOjE2MjM0MDE2NCAKU2VwIDE1IDA4OjI3OjQwIHhtYW8ga2Vy bmVsOiBEaXNwbGF5aW5nIGxlYWYgZXh0ZW50cyBmb3IgaW5vZGUgMTIzMzkwMDQKU2VwIDE1IDA4 OjI3OjQwIHhtYW8ga2VybmVsOiAzNDY4OlswXTE0OjU3OTIxNjQzIDM0ODI6WzBdMTo1NzkyMTY2 NCAzNDgzOlswXTc6NTc5MjE2NjYgMzQ5MDpbMF0xOjU3OTIxNjgwIDM0OTE6WzBdODo1NzkyMTY4 MiAzNDk5OlswXTc6NTc5MjE2OTEgMzUwNjpbMF04OjU3OTIxNzA1IDM1MTQ6WzBdMTo1NzkyMTcx NCAzNTE1OlswXTc6NTc5MjE3MjIgMzUyMjpbMF00MTo1NzkxNjY4MyAzNTYzOlswXTc6NTgxNTk3 NjcgMzU3MDpbMF0xOjU4MTU5NzgxIDM1NzE6WzBdNzo1ODIzODk5MiAzNTc4OlswXTE6NTgyODgx NDQgMzU3OTpbMF03OjU4MzI3NzUwIDM1ODY6WzBdMTo1ODU3OTk2OSAzNTg3OlswXTc6NTg5NTQ4 MzggMzU5NDpbMF0xOjU5MDA2NjQxIDM1OTU6WzBdNzo1OTAwNjY0MyAzNjAyOlswXTE6NTkwMDY2 NTcgMzYwMzpbMF03OjU5MDA2NjU5IDM2MTA6WzBdODo1OTAwNjY3MyAzNjE4OlswXTg6NTkwMDY2 ODggMzYyNjpbMF00NzA6NTg5ODI2NTggNDA5NjpbMF0zOjU4OTg3NzMyIDQwOTk6WzBdMTo1ODk5 MjY1NSA0MTAwOlswXTc6NTkxNDMyNTMgNDEwNzpbMF0xOjU5MTcxODQwIDQxMDg6WzBdNzo1OTE4 Mzg3OCA0MTE1OlswXTE6NTkxOTI4ODYgNDExNjpbMF04OjU5NTkzNDYzIDQxMjQ6WzBdODo1OTY2 OTQ4NCA0MTMyOlswXTc6NzMwODY1MzggNDEzOTpbMF0xOjczMzUyODAxIDQxNDA6WzBdNzo3MzMz OTI3MyA0MTQ3OlswXTE6NzM1MjYyODAgNDE0ODpbMF04Ojc4MjI5MDEyIDQxNTY6WzBdMTo3ODIy OTAyMSA0MTU3OlswXTc6Nzg4MTgzODggNDE2NDpbMF0xOjc5MDY5MzgzIDQxNjU6WzBdNzo3OTQy ODYxNiA0MTcyOlswXTE6ODA0OTA5MjUgNDE3MzpbMF03OjgxNDM5NDg4IDQxODA6WzBdMTo4Mjg1 NDA2MiA0MTgxOlswXTc6ODM0NjIyNzIgNDE4ODpbMF0xOjgzNjU2OTA0IDQxODk6WzBdNzo4OTEy NzM4MSA0MTk2OlswXTE6ODk1ODQzMTMgNDE5NzpbMF04OjkxNTkyOTMwIDQyMDU6WzBdNzo5MTU5 Mjk0NSA0MjEyOlswXTE6OTE1OTI5NTMgNDIxMzpbMF03OjkxNTkyOTYxIDQyMgpTZXAgMTUgMDg6 Mjc6NDAgeG1hbyBrZXJuZWw6IDpbMF04OjkxNTkyOTY5IDQyMjg6WzBdMTo5MTU5Mjk4NSA0MjI5 OlswXTg6OTE1OTI5OTMgNDIzNzpbMF03OjkxNTkzMDAyIDQyNDQ6WzBdMTo5MTU5MzAxNyA0MjQ1 OlswXTc6OTE1OTMwMjUgNDI1MjpbMF0xOjkxNTkzMDMzIDQyNTM6WzBdODo5MTU5MzA0MSA0MjYx OlswXTg6OTE1OTMwNTcgNDI2OTpbMF03OjkxNTkzMDY2IDQyNzY6WzBdMTo5MTY1MDEyNSA0Mjc3 OlswXTc6OTE2NTAxMzMgNDI4NDpbMF0xOjkxNjUwMTQxIDQyODU6WzBdODo5MTY1MDE0OSA0Mjkz OlswXTc6OTE2NTAxNTggNDMwMDpbMF04OjkxNjUwMTcyIDQzMDg6WzBdMTo5MTY0NDMwNCA0MzA5 OlswXTc6OTE2MzgwNTYgNDMxNjpbMF0xOjkxNjQ0MzA1IDQzMTc6WzBdNzo5MTY1MDE4MCA0MzI0 OlswXTE6OTE2MzA0NDggNDMyNTpbMF03OjkxNjQ0MjU3IDQzMzI6WzBdMTo5MTY0NDMwNiA0MzMz OlswXTc6OTE2NDQ5NzggNDM0MDpbMF0xOjkxNjQ1MjUxIDQzNDE6WzBdNzo5MTYzMTY5NiA0MzQ4 OlswXTE6OTE2NDQzMDcgNDM0OTpbMF03OjkxNjQ1MjUyIDQzNTY6WzBdODo5MTY0NDMwOCA0MzY0 OlswXTE6OTE3NjQzOTMgNDM2NTpbMF0xOjkyMjQ0MzA5IDQzNjY6WzBdNjo5MjI2NzcxOSA0Mzcy OlswXTE6OTI4OTkyMTYgNDM3MzpbMF03OjkzMTkxNjgxIDQzODA6WzBdMTo5MzIyMDg2NCA0Mzgx OlswXTc6OTMyMDQ1MjEgNDM4ODpbMF0xOjkzMjA0NTM1IDQzODk6WzBdMTU6OTMyMDQ1MzcgNDQw NDpbMF0xOjk3OTYwNDcxIDQ0MDU6WzBdODo5Nzk2MDQ3OSA0NDEzOlswXTc6OTc5NjA0ODggNDQy MDpbMF04Ojk3OTYwNTAyIDQ0Mjg6WzBdMTo5Nzk2MDUxMSA0NDI5OlswXTg6OTc5NjA1MTkgNDQz NzpbMF04Ojk3OTYwNTI4IDQ0NDU6WzBdODo5Nzk2MDU0MyA0NDUzOlswXTc6OTc5NjA1NTIgNDQ2 MDpbMF04Ojk3OTYwNTY2IDQ0Njg6WzBdMTo5Nzk2MDU3NSA0NDY5OlswXTg6OTc5NjA1ODMgNDQ3 NzpbMF04Ojk3OTYwNTkyIDQ0ODU6WzBdNzo5Nzk2MDYwNyA0NDkyOlswXTg6ClNlcCAxNSAwODoy Nzo0MCB4bWFvIGtlcm5lbDogMDYxNSA0NTAwOlswXTE6OTc5NjA2MzAgNDUwMTpbMF03Ojk4MDUw MDgxIDQ1MDg6WzBdMTo5OTYyODIzOSA0NTA5OlswXTc6OTk2MjgyNDcgNDUxNjpbMF0xOjk5NjI4 MjU1IDQ1MTc6WzBdNzo5OTk2OTc3MCA0NTI0OlswXTg6OTk5Njk3NzggNDUzMjpbMF0xOjEzMjU1 Mjk2MCA0NTMzOlswXTc6MTM2MzMzMTUzIDQ1NDA6WzBdMToxNDI2MjkwNDcgNDU0MTpbMF03OjE0 Mjc2MDA5NiA0NTQ4OlswXTg6MTQyNzUxOTk5IDQ1NTY6WzBdODoxNDI3NDE3NjEgNDU2NDpbMF04 OjE0Mjc1NjA2NiA0NTcyOlswXTE6MTQyNzUyMDA4IDQ1NzM6WzBdNzoxNDI3NjAxMTggNDU4MDpb MF04OjE0Mjc1MjAwOSA0NTg4OlswXTg6MTQyNzU2MDc1IDQ1OTY6WzBdMToxNDI3MzkxMjQgNDU5 NzpbMF03OjE0Mjc0NzcyOCA0NjA0OlswXTE6MTQyNzYyMjg4IDQ2MDU6WzBdNzoxNDI3NDE3Nzcg NDYxMjpbMF0xOjE0Mjc1MjAxNyA0NjEzOlswXTc6MTQyNzM3OTQ4IDQ2MjA6WzBdODoxNDI3NTIw MTggNDYyODpbMF04OjE0Mjc1NjA4MyA0NjM2OlswXTE6MTQyNzU3ODAwIDQ2Mzc6WzBdNzoxNDI3 NTI4MzIgNDY0NDpbMF0xOjE0Mjc1NzgwMSA0NjQ1OlswXTc6MTQyNzU0OTkzIDQ2NTI6WzBdMTox NDI3NTIyNDIgNDY1MzpbMF03OjE0MzU4OTM3OCA0NjYwOlswXTE6MTQzNzc2MDAwIDQ2NjE6WzBd ODoxNDM3NzYwMDggNDY2OTpbMF04OjE0Mzc3NjAxNyA0Njc3OlswXTE6MTQzNzc2MDMyIDQ2Nzg6 WzBdNzoxNDM3NzYwMzQgNDY4NTpbMF0xOjE0Mzc4MDY1MSA0Njg2OlswXTc6MTQzNzgwNjUzIDQ2 OTM6WzBdMToxNDM3OTIxMTkgNDY5NDpbMF03OjE0NTQ1OTA1OSA0NzAxOlswXTE6MTQ2MDA2MDE2 IDQ3MDI6WzBdNzoxNDYwNDkwMzEgNDcwOTpbMF0xOjE0NjA1MzcyNyA0NzEwOlswXTc6MTQ2MDUz NzI5IDQ3MTc6WzBdODoxNDYwNTM3NDMgNDcyNTpbMF04OjE0NjA1Mzc1MiA0NzMzOlswXTE6MTQ2 MDUzNzY4IDQ3MzQ6WzBdNzoxNDYxMDY2MDMgNDc0MTpbMF0xOjE0NjA3OTkKU2VwIDE1IDA4OjI3 OjQwIHhtYW8ga2VybmVsOiA3NDI6WzBdODoxNDYwODkzOTcgNDc1MDpbMF04OjE0NjA4OTQwNiA0 NzU4OlswXTc6MTQ2MTA2NjI0IDQ3NjU6WzBdMToxNDYyMjAyODggNDc2NjpbMF03OjE0NjQ1MDQz MiA0NzczOlswXTE6MTQ4MDE3Nzc2IDQ3NzQ6WzBdNzoxNDgxNjIxOTYgNDc4MTpbMF0xNjoxNDg4 ODgwNzEgNDc5NzpbMF0xOjE0ODk0MDQ4MyA0Nzk4OlswXTc6MTQ4OTQwNDg1IDQ4MDU6WzBdMTox NDg5NTUwNzcgNDgwNjpbMF03OjE0ODk1NTA3OSA0ODEzOlswXTg6MTQ4OTMxNDM0IDQ4MjE6WzBd ODoxNDk1NTYyODEgNDgyOTpbMF04OjE0OTYyNjg4MCA0ODM3OlswXTE6MTQ5NjI2ODg5IDQ4Mzg6 WzBdODoxNDk2MjY4OTcgNDg0NjpbMF03OjE0OTc5NDI4MCA0ODUzOlswXTg6MTQ5ODkzNjM5IDQ4 NjE6WzBdMToxNDk5OTE1NTQgNDg2MjpbMF04OjE0OTk5MTU2MiA0ODcwOlswXTg6MTQ5OTkxNTg3 IDQ4Nzg6WzBdNzoxNDk5OTE2MDIgNDg4NTpbMF0xOjE1MDA1NjM1OCA0ODg2OlswXTc6MTUxNTQx NzYwIDQ4OTM6WzBdMToxNTMwODQxNzUgNDg5NDpbMF03OjE1MzMzMDg1NSA0OTAxOlswXTE6MTUz MzMyMjc3IDQ5MDI6WzBdNzoxNTM2ODYwODAgNDkwOTpbMF0xOjE2MDAyMjcxNyA0OTEwOlswXTE1 OjE2MDM2MDQwNiA0OTI1OlswXTE6MTYwMzYwNDIyIDQ5MjY6WzBdODoxNjAzNjA0MzAgNDkzNDpb MF03OjE2MDUxMjM4NCA0OTQxOlswXTE6MTYwNTEyMzk4IDQ5NDI6WzBdODoxNjA1MTI0MDAgNDk1 MDpbMF0xNjoxNjA1MTI0MTUgNDk2NjpbMF03OjE2MDc4MTI4OCA0OTczOlswXTE6MTYwNzk3NDQw IDQ5NzQ6WzBdNzoxNjA4MTUxMjEgNDk4MTpbMF0xOjE2MDgxNTEyOSA0OTgyOlswXTEwMzoxNjA4 MTUxMzcgNTA4NTpbMF0xOjE2MTQ1MDI0MCA1MDg2OlswXTMyOjE2MTUwMTI0OSA1MTE4OlswXTgx OjE2MTQ3MDUwMSA1MTk5OlswXTQwOjE2MTc0ODQ4MCA1MjM5OlswXTc6MTYxNzMwMDg4IDUyNDY6 WzBdMTc6MTYxNzQ4NTIwIDUyNjM6WzBdODoxNjIwNDgwMDcgNTI3MTpbMApTZXAgMTUgMDg6Mjc6 NDAgeG1hbyBrZXJuZWw6IDYyMDQ4MDE2IDUyNzg6WzBdODoxNjIwNDgwMzAgNTI4NjpbMF04OjE2 MjA0ODA0NiA1Mjk0OlswXTE6MTYyMDgxOTc5IDUyOTU6WzBdNzoxNjIxMjMyNDIgNTMwMjpbMF05 OjE2MjA4MTk4MCA1MzExOlswXTc6MjAxNjg3NDM1IDUzMTg6WzBdMToxNjIwODE5ODkgNTMxOTpb MF03OjIwNTI0NzA1MSA1MzI2OlswXTg6MTYyMDgxOTkwIDUzMzQ6WzBdMToxNjIzODM4NzIgNTMz NTpbMF03OjE2MjA4MTk5OCA1MzQyOlswXTE6MTYyNzg1MzAzIDUzNDM6WzBdNzoxNjMwNzc0MTgg NTM1MDpbMF0xOjE2MjA4MjAwNSA1MzUxOlswXTc6MTYyMTQ0ODYzIDUzNTg6WzBdODoxNjIwODIw MDYgNTM2NjpbMF0xOjE2MjE0NDg3MCA1MzY3OlswXTc6MTYyMDgyMDE0IDUzNzQ6WzBdMToxNjIx NDQ4NzEgNTM3NTpbMF03OjE2MjA4MjAyMSA1MzgyOlswXTE6MTYyMzQxMTIwIDUzODM6WzBdNzox NjIwNDgxMTggNTM5MDpbMF04ODoxNjM5MDY4MTYgNTQ3ODpbMF0xOjE2NDkyMDA2NSA1NDc5Olsw XTg6MTYzMzYwMTk0IDU0ODc6WzBdNzoxNjQzOTgwODAgNTQ5NDpbMF0zMjoxNjUxODQ3NjggNTUy NjpbMF04OjE2NTE4NTU2NSA1NTM0OlswXTg6MTY1MTg0ODAwIDU1NDI6WzBdODoxNjUxODU1NzMg NTU1MDpbMF0yNDE6MTY1Njg5MDQwIDU3OTE6WzBdMzUzOjE2ODkxMDg0OCA2MTQ0OlswXTc6MTY4 OTAyNjk1IDYxNTE6WzBdMToxNjg4OTU0ODggNjE1MjpbMF03OjE2ODg5NTQ4OSA2MTU5OlswXTg6 MTY4OTAyNzAyIDYxNjc6WzBdODoxNjg4OTU0OTYgNjE3NTpbMF05OjE2ODkwMjcxMSA2MTg0Olsw XTE1OjE2ODkwMjcyMSA2MTk5OlswXTE6MTY4ODk1NTIwIDYyMDA6WzBdODoxNjg5MDI3MzYgNjIw ODpbMF04OjE2OTI0MzY3MSA2MjE2OlswXTE6MTc1NjUyNjQ3IDYyMTc6WzBdNzoxNzYxMDM0MjQg NjIyNDpbMF0xOjE3NjA5Njc2OCA2MjI1OlswXTc6MTc2MTAzNDMxIDYyMzI6WzBdODoxNzYxMTg2 NTkgNjI0MDpbMF0xOjE3NjEwMzQzOSA2MjQxOlswXTc6MjA1NjIxNTQwClNlcCAxNSAwODoyNzo0 MCB4bWFvIGtlcm5lbDogODpbMF04OjIwNTgzMzc0NyA2MjU2OlswXTg6MjA1ODMzNzYzIDYyNjQ6 WzBdMToyMDU4MzM3NzggNjI2NTpbMF03OjIwNTgzMzc4MCA2MjcyOlswXTE6MjA1ODMzODAyIDYy NzM6WzBdNzoyMDU4MzM4MDQgNjI4MDpbMF0xOjIwNTgzMzgxOCA2MjgxOlswXTc6MjA1ODMzODIw IDYyODg6WzBdODoyMDU4MzM4MzQgNjI5NjpbMF0xOjIwNTgzMzg0MyA2Mjk3OlswXTc6MjA1ODMz ODUxIDYzMDQ6WzBdODoyMDY3MDQ2NTEgNjMxMjpbMF0xOjIwNjcwNDY2MCA2MzEzOlswXTc6MjA2 NzA0NjY4IDYzMjA6WzBdODoyMDY3MDQ2NzYgNjMyODpbMF04OjIwNjkwNTI2NCA2MzM2OlswXTE6 MjA2OTc1NDYyIDYzMzc6WzBdNzoyMDcwMTAwMzIgNjM0NDpbMF0xOjIwNzAxMDA0MCA2MzQ1Olsw XTc6MjA3MDExMjU4IDYzNTI6WzBdMToyMDcwMTAwNDggNjM1MzpbMF04OjIwNzAxMTI2NSA2MzYx OlswXTc6MjA4OTY0ODY0IDYzNjg6WzBdMToyMDkyMzQ3MDMgNjM2OTpbMF03OjIwOTIzNDcxMSA2 Mzc2OlswXTE6MjA5MjU0NDAwIDYzNzc6WzBdNzoyMDkyNTQ0MDIgNjM4NDpbMF0xOjIwOTM0NjU2 MCA2Mzg1OlswXTg6MjA5NDcyNzM3IDYzOTM6WzBdNzoyMDk1NTkwNTkgNjQwMDpbMF0xOjIwOTU1 NDk3NCA2NDAxOlswXTc6ODEyMzQ2OTcgNjQwODpbMF01Njo4MTM5NTcxMiA2NDY0OlswXTg6ODEz OTc3NTMgNjQ3MjpbMF04OjgxNDIxODI0IDY0ODA6WzBdODo4MTM5NTc2OCA2NDg4OlswXTg6ODEz OTc3NjEgNjQ5NjpbMF04OjgxNDIxODMyIDY1MDQ6WzBdODo4MTM5NTc3NiA2NTEyOlswXTg6ODEz OTc3NjkgNjUyMDpbMF0xOjgxNjU5MjIxIDY1MjE6WzBdNzo4MjQxNjM1MyA2NTI4OlswXTE6MTAz ODUwMDQ4IDY1Mjk6WzBdNzoxMTUyNzY5IDY1MzY6WzBdMToxNzg2MzUyIDY1Mzc6WzBdODoyMzYz NjQ4IDY1NDU6WzBdNzoyOTA4MTMyIDY1NTI6WzBdMTo1MDY2ODU2MCA2NTUzOlswXTc6NTEwMzc5 MzEgNjU2MDpbMF0xOjUxMTYxMzI2IDY1NjE6WzBdNzo1MTI5MzQzOSAKU2VwIDE1IDA4OjI3OjQw IHhtYW8ga2VybmVsOiA6WzBdODo1MTQwOTA2OCA2NTc2OlswXTg6NTEzOTMwMDcgNjU4NDpbMF04 OjUxNDA5MDc2IDY1OTI6WzBdMTo1MTM5MzAxNiA2NTkzOlswXTc6NTEzOTAxOTYgNjYwMDpbMF0x OjUxMzkyNzYxIDY2MDE6WzBdNzo1MTM5MDU3MyA2NjA4OlswXTg6NTE0MDkwODUgNjYxNjpbMF04 OjUxMzkzMDI0IDY2MjQ6WzBdMTo1MTM5Mjc2OSA2NjI1OlswXTc6NTEzODk2NzYgNjYzMjpbMF0x OjUxNDA5MDkzIDY2MzM6WzBdNzo1MTQzMDE3NyA2NjQwOlswXTg6NTE0NzA0ODIgNjY0ODpbMF0x OjUxNDcwNDk3IDY2NDk6WzBdNzo1MTQ3MDQ5OSA2NjU2OlswXTg6NTE1MzYxMzUgNjY2NDpbMF04 OjUxNTM2MTQ0IDY2NzI6WzBdMTo1MTUzNjE1OSA2NjczOlswXTc6NTE1MzYxNjEgNjY4MDpbMF0x OjUxNTM2MTc1IDY2ODE6WzBdNzo1MTUzNjE3NyA2Njg4OlswXTE6NTE1MzYxOTEgNjY4OTpbMF03 OjUxNjIwMzg5IDY2OTY6WzBdMTo1MTczNjgzMiA2Njk3OlswXTc6NTE3MzY4NDAgNjcwNDpbMF0x OjUxNzM2ODQ4IDY3MDU6WzBdNzo1MTczNjg1NiA2NzEyOlswXTE6NTE3MzY4NjQgNjcxMzpbMF05 OjUxNzM2ODcyIDY3MjI6WzBdODo1MTczNjg4MiA2NzMwOlswXTc6NTE3MzY4OTcgNjczNzpbMF0x OjUxNzM2OTA1IDY3Mzg6WzBdNzo1MTczNjkxMyA2NzQ1OlswXTE6MTYyMzQwMTY0IApTZXAgMTUg MDg6Mjc6NDAgeG1hbyBrZXJuZWw6IC0tLS0tLS0tLS0tLVsgY3V0IGhlcmUgXS0tLS0tLS0tLS0t LQpTZXAgMTUgMDg6Mjc6NDAgeG1hbyBrZXJuZWw6IGtlcm5lbCBCVUcgYXQgZnMvZXh0NC9leHRl bnRzLmM6MjIxNCEKU2VwIDE1IDA4OjI3OjQwIHhtYW8ga2VybmVsOiBpbnZhbGlkIG9wY29kZTog MDAwMCBbIzFdIFNNUCAKU2VwIDE1IDA4OjI3OjQwIHhtYW8ga2VybmVsOiBsYXN0IHN5c2ZzIGZp bGU6IC9zeXMvaHlwZXJ2aXNvci9wcm9wZXJ0aWVzL2NhcGFiaWxpdGllcwpTZXAgMTUgMDg6Mjc6 NDAgeG1hbyBrZXJuZWw6IENQVSAzIApTZXAgMTUgMDg6Mjc6NDAgeG1hbyBrZXJuZWw6IE1vZHVs ZXMgbGlua2VkIGluOiB4dF9pcHJhbmdlIHh0X21hYyBhcnB0YWJsZV9maWx0ZXIgYXJwX3RhYmxl cyB4dF9waHlzZGV2IG5mX2Nvbm50cmFja19pcHY0IG5mX2RlZnJhZ19pcHY0IHh0X3N0YXRlIG5m X2Nvbm50cmFjayBpcHRhYmxlX2ZpbHRlciBpcF90YWJsZXMgYnJpZGdlIGF1dG9mczQgaXBtaV9k ZXZpbnRmIGlwbWlfc2kgaXBtaV9tc2doYW5kbGVyIGxvY2tkIHN1bnJwYyBib25kaW5nIGlwdjYg ODAyMXEgZ2FycCBzdHAgbGxjIHhlbmZzIGRtX211bHRpcGF0aCBmdXNlIHhlbl9uZXRiYWNrIHhl bl9ibGtiYWNrIGJsa3RhcCBibGtiYWNrX3BhZ2VtYXAgbG9vcCBuYmQgdmlkZW8gb3V0cHV0IHNi cyBzYnNoYyBwYXJwb3J0X3BjIGxwIHBhcnBvcnQgam95ZGV2IGJueDIgc2VzIGVuY2xvc3VyZSBy YWRlb24gdHRtIGRybV9rbXNfaGVscGVyIGRybSBpMmNfYWxnb19iaXQgaTJjX2NvcmUgc25kX3Nl cV9kdW1teSBzbmRfc2VxX29zcyBzbmRfc2VxX21pZGlfZXZlbnQgc25kX3NlcSBzbmRfc2VxX2Rl dmljZSBzbmRfcGNtX29zcyBzbmRfbWl4ZXJfb3NzIHNlcmlvX3JhdyBkY2RiYXMgc25kX3BjbSBp NWtfYW1iIGh3bW9uIHNuZF90aW1lciBzbmQgaVRDT193ZHQgaTUwMDBfZWRhYyBlZGFjX2NvcmUg aVRDT192ZW5kb3Jfc3VwcG9ydCBzb3VuZGNvcmUgc25kX3BhZ2VfYWxsb2MgcGNzcGtyIHNocGNo cCBbbGFzdCB1bmxvYWRlZDogZnJlcV90YWJsZV0KU2VwIDE1IDA4OjI3OjQwIHhtYW8ga2VybmVs OiBQaWQ6IDE5MTMsIGNvbW06IGZsdXNoLTg6NjQgTm90IHRhaW50ZWQgMi42LjMyLjM2eGVuICM3 IFBvd2VyRWRnZSAyOTUwClNlcCAxNSAwODoyNzo0MCB4bWFvIGtlcm5lbDogUklQOiBlMDMwOls8 ZmZmZmZmZmY4MTFhNzBiYT5dICBbPGZmZmZmZmZmODExYTcwYmE+XSBleHQ0X2V4dF93eWJfaW5z ZXJ0X2V4dGVudCsweDUyMS8weDY2OQpTZXAgMTUgMDg6Mjc6NDAgeG1hbyBrZXJuZWw6IFJTUDog ZTAyYjpmZmZmODgwMWQxMWViNTIwICBFRkxBR1M6IDAwMDEwMjQ2ClNlcCAxNSAwODoyNzo0MCB4 bWFvIGtlcm5lbDogUkFYOiAwMDAwMDAwMDAwMDAwZDhjIFJCWDogMDAwMDAwMDAwMDAwMDAwZSBS Q1g6IGZmZmY4ODAxZDExZWI3NzAKU2VwIDE1IDA4OjI3OjQwIHhtYW8ga2VybmVsOiBSRFg6IGZm ZmY4ODAwMjgwOGYwMDAgUlNJOiBmZmZmZmZmZjgxNDMwMDNhIFJESTogMDAwMDAwMDAwMDAwMDIw NApTZXAgMTUgMDg6Mjc6NDAgeG1hbyBrZXJuZWw6IFJCUDogZmZmZjg4MDFkMTFlYjYxMCBSMDg6 IDAwMDAwMDAwMDAwMDAwMDEgUjA5OiBmZmZmZmZmZjgxN2ViNGNiClNlcCAxNSAwODoyNzo0MCB4 bWFvIGtlcm5lbDogUjEwOiBmZmZmZmZmZjgxNWRhMGY1IFIxMTogMDAwMDAwMDAwMDAwODAwZiBS MTI6IGZmZmY4ODAxMmQxYWEwMGMKU2VwIDE1IDA4OjI3OjQwIHhtYW8ga2VybmVsOiBSMTM6IGZm ZmY4ODAxZDExZWI3NzAgUjE0OiBmZmZmODgwMTJkMWFhMDAwIFIxNTogZmZmZjg4MDE2NjlkYTUw OApTZXAgMTUgMDg6Mjc6NDAgeG1hbyBrZXJuZWw6IEZTOiAgMDAwMDdmNGU5MDNjOTc0MCgwMDAw KSBHUzpmZmZmODgwMDI4MDhmMDAwKDAwMDApIGtubEdTOjAwMDAwMDAwMDAwMDAwMDAKU2VwIDE1 IDA4OjI3OjQwIHhtYW8ga2VybmVsOiBDUzogIGUwMzMgRFM6IDAwMDAgRVM6IDAwMDAgQ1IwOiAw MDAwMDAwMDgwMDUwMDNiClNlcCAxNSAwODoyNzo0MCB4bWFvIGtlcm5lbDogQ1IyOiAwMDAwN2Yy YTA0OGM0MWMwIENSMzogMDAwMDAwMDE4YmIwMjAwMCBDUjQ6IDAwMDAwMDAwMDAwMDI2NjAKU2Vw IDE1IDA4OjI3OjQwIHhtYW8ga2VybmVsOiBEUjA6IDAwMDAwMDAwMDAwMDAwMDAgRFIxOiAwMDAw MDAwMDAwMDAwMDAwIERSMjogMDAwMDAwMDAwMDAwMDAwMApTZXAgMTUgMDg6Mjc6NDAgeG1hbyBr ZXJuZWw6IERSMzogMDAwMDAwMDAwMDAwMDAwMCBEUjY6IDAwMDAwMDAwZmZmZjBmZjAgRFI3OiAw MDAwMDAwMDAwMDAwNDAwClNlcCAxNSAwODoyNzo0MCB4bWFvIGtlcm5lbDogUHJvY2VzcyBmbHVz aC04OjY0IChwaWQ6IDE5MTMsIHRocmVhZGluZm8gZmZmZjg4MDFkMTFlYTAwMCwgdGFzayBmZmZm ODgwMWNkOGJkYjQwKQpTZXAgMTUgMDg6Mjc6NDAgeG1hbyBrZXJuZWw6IFN0YWNrOgpTZXAgMTUg MDg6Mjc6NDAgeG1hbyBrZXJuZWw6ICAwMDAwMDAwMDAwMDAwMDAwIGZmZmY4ODAxMDAwMDAwMGYg MDAwMDAwMDAwMzczZDA2YSAwMDAwMDAwMDAwMDAwZDhiClNlcCAxNSAwODoyNzo0MCB4bWFvIGtl cm5lbDogPDA+IDAwMDAwMDMwMDAwMDAwMDEgZmZmZjg4MDEwMDAwMDAwZiAwMDAwMDAwMDAzNzNk MDZhIGZmZmZmZmZmMDAwMDAwMDEKU2VwIDE1IDA4OjI3OjQwIHhtYW8ga2VybmVsOiA8MD4gMDAw MDAwMDAwMDAwMGQ4YiBmZmZmZmZmZjAwMDAwMDAxIGZmZmY4ODAwMjgwNzIwMDAgZmZmZjg4MDFk MTFlYjc2MApTZXAgMTUgMDg6Mjc6NDAgeG1hbyBrZXJuZWw6IENhbGwgVHJhY2U6ClNlcCAxNSAw ODoyNzo0MCB4bWFvIGtlcm5lbDogIFs8ZmZmZmZmZmY4MTFhODM2NT5dIGV4dDRfZXh0X2hhbmRs ZV91bmluaXRpYWxpemVkX2V4dGVudHMrMHhjNmUvMHgxMTliClNlcCAxNSAwODoyNzo0MCB4bWFv IGtlcm5lbDogIFs8ZmZmZmZmZmY4MTEzMzVlMT5dID8gX19maW5kX2dldF9ibG9jaysweDE3MC8w eDE4MgpTZXAgMTUgMDg6Mjc6NDAgeG1hbyBrZXJuZWw6ICBbPGZmZmZmZmZmODEwMGYxNzU+XSA/ IHhlbl9mb3JjZV9ldnRjaG5fY2FsbGJhY2srMHhkLzB4ZgpTZXAgMTUgMDg6Mjc6NDAgeG1hbyBr ZXJuZWw6ICBbPGZmZmZmZmZmODEwMGY4ZDI+XSA/IGNoZWNrX2V2ZW50cysweDEyLzB4MjAKU2Vw IDE1IDA4OjI3OjQwIHhtYW8ga2VybmVsOiAgWzxmZmZmZmZmZjgxMTM0MTk5Pl0gPyBiaF91cHRv ZGF0ZV9vcl9sb2NrKzB4MTYvMHg0OQpTZXAgMTUgMDg6Mjc6NDAgeG1hbyBrZXJuZWw6ICBbPGZm ZmZmZmZmODExYTk5ODY+XSBleHQ0X2V4dF9nZXRfYmxvY2tzKzB4MjQzLzB4NjFjClNlcCAxNSAw ODoyNzo0MCB4bWFvIGtlcm5lbDogIFs8ZmZmZmZmZmY4MTIwNzc0ND5dID8gZ2VuZXJpY19tYWtl X3JlcXVlc3QrMHgxZTgvMHgyODQKU2VwIDE1IDA4OjI3OjQwIHhtYW8ga2VybmVsOiAgWzxmZmZm ZmZmZjgxMjA4YzljPl0gPyBzdWJtaXRfYmlvKzB4YmYvMHhjOApTZXAgMTUgMDg6Mjc6NDAgeG1h byBrZXJuZWw6ICBbPGZmZmZmZmZmODEwNDJmY2Y+XSA/IG5lZWRfcmVzY2hlZCsweDIzLzB4MmQK U2VwIDE1IDA4OjI3OjQwIHhtYW8ga2VybmVsOiAgWzxmZmZmZmZmZjgxMTg4YWUwPl0gZXh0NF9n ZXRfYmxvY2tzKzB4MTQwLzB4MjA0ClNlcCAxNSAwODoyNzo0MCB4bWFvIGtlcm5lbDogIFs8ZmZm ZmZmZmY4MTAwZjhkMj5dID8gY2hlY2tfZXZlbnRzKzB4MTIvMHgyMApTZXAgMTUgMDg6Mjc6NDAg eG1hbyBrZXJuZWw6ICBbPGZmZmZmZmZmODExODhjYmE+XSBtcGFnZV9kYV9tYXBfYmxvY2tzKzB4 YjcvMHg2OGUKU2VwIDE1IDA4OjI3OjQwIHhtYW8ga2VybmVsOiAgWzxmZmZmZmZmZjgxMTJkYzMy Pl0gPyBfX21hcmtfaW5vZGVfZGlydHkrMHg2YS8weDEzMApTZXAgMTUgMDg6Mjc6NDAgeG1hbyBr ZXJuZWw6ICBbPGZmZmZmZmZmODEwMGYxNzU+XSA/IHhlbl9mb3JjZV9ldnRjaG5fY2FsbGJhY2sr MHhkLzB4ZgpTZXAgMTUgMDg6Mjc6NDAgeG1hbyBrZXJuZWw6ICBbPGZmZmZmZmZmODEyMWY2ODA+ XSA/IF9fbG9va3VwX3RhZysweDYwLzB4MTFlClNlcCAxNSAwODoyNzo0MCB4bWFvIGtlcm5lbDog IFs8ZmZmZmZmZmY4MTBmNGEwMD5dID8gcGFnZV9ta2NsZWFuKzB4MjEvMHgxZGMKU2VwIDE1IDA4 OjI3OjQwIHhtYW8ga2VybmVsOiAgWzxmZmZmZmZmZjgxMjFmYzVhPl0gPyByYWRpeF90cmVlX2dh bmdfbG9va3VwX3RhZ19zbG90KzB4ODUvMHhhYQpTZXAgMTUgMDg6Mjc6NDAgeG1hbyBrZXJuZWw6 ICBbPGZmZmZmZmZmODEwMGYxNzU+XSA/IHhlbl9mb3JjZV9ldnRjaG5fY2FsbGJhY2srMHhkLzB4 ZgpTZXAgMTUgMDg6Mjc6NDAgeG1hbyBrZXJuZWw6ICBbPGZmZmZmZmZmODEwMGYxNzU+XSA/IHhl bl9mb3JjZV9ldnRjaG5fY2FsbGJhY2srMHhkLzB4ZgpTZXAgMTUgMDg6Mjc6NDAgeG1hbyBrZXJu ZWw6ICBbPGZmZmZmZmZmODExOGJiM2U+XSBleHQ0X2RhX3dyaXRlcGFnZXMrMHg1YWIvMHg5N2QK U2VwIDE1IDA4OjI3OjQwIHhtYW8ga2VybmVsOiAgWzxmZmZmZmZmZjgxMTM5NTUxPl0gPyBibGtk ZXZfZ2V0X2Jsb2NrKzB4MC8weDU1ClNlcCAxNSAwODoyNzo0MCB4bWFvIGtlcm5lbDogIFs8ZmZm ZmZmZmY4MTBkOGEwMD5dIGRvX3dyaXRlcGFnZXMrMHgyMS8weDJhClNlcCAxNSAwODoyNzo0MCB4 bWFvIGtlcm5lbDogIFs8ZmZmZmZmZmY4MTEyY2RiND5dIHdyaXRlYmFja19zaW5nbGVfaW5vZGUr MHhjOC8weDFlMwpTZXAgMTUgMDg6Mjc6NDAgeG1hbyBrZXJuZWw6ICBbPGZmZmZmZmZmODExMmQ1 ZTA+XSB3cml0ZWJhY2tfaW5vZGVzX3diKzB4MzBiLzB4MzdlClNlcCAxNSAwODoyNzo0MCB4bWFv IGtlcm5lbDogIFs8ZmZmZmZmZmY4MTBlNzhkMT5dID8gYmRpX3N0YXJ0X2ZuKzB4MC8weGQwClNl cCAxNSAwODoyNzo0MCB4bWFvIGtlcm5lbDogIFs8ZmZmZmZmZmY4MTEyZDc4ND5dIHdiX3dyaXRl YmFjaysweDEzMS8weDFiYgpTZXAgMTUgMDg6Mjc6NDAgeG1hbyBrZXJuZWw6ICBbPGZmZmZmZmZm ODExMmQ5ZWI+XSB3Yl9kb193cml0ZWJhY2srMHgxM2MvMHgxNTMKU2VwIDE1IDA4OjI3OjQwIHht YW8ga2VybmVsOiAgWzxmZmZmZmZmZjgxMDY0MjViPl0gPyBwcm9jZXNzX3RpbWVvdXQrMHgwLzB4 MTAKU2VwIDE1IDA4OjI3OjQwIHhtYW8ga2VybmVsOiAgWzxmZmZmZmZmZjgxMGU3OGQxPl0gPyBi ZGlfc3RhcnRfZm4rMHgwLzB4ZDAKU2VwIDE1IDA4OjI3OjQwIHhtYW8ga2VybmVsOiAgWzxmZmZm ZmZmZjgxMTJkYTJlPl0gYmRpX3dyaXRlYmFja190YXNrKzB4MmMvMHhiMwpTZXAgMTUgMDg6Mjc6 NDAgeG1hbyBrZXJuZWw6ICBbPGZmZmZmZmZmODEwZTc5M2I+XSBiZGlfc3RhcnRfZm4rMHg2YS8w eGQwClNlcCAxNSAwODoyNzo0MCB4bWFvIGtlcm5lbDogIFs8ZmZmZmZmZmY4MTA3NTRiNz5dIGt0 aHJlYWQrMHg2ZS8weDc2ClNlcCAxNSAwODoyNzo0MCB4bWFvIGtlcm5lbDogIFs8ZmZmZmZmZmY4 MTAxM2RhYT5dIGNoaWxkX3JpcCsweGEvMHgyMApTZXAgMTUgMDg6Mjc6NDAgeG1hbyBrZXJuZWw6 ICBbPGZmZmZmZmZmODEwMTJmOTE+XSA/IGludF9yZXRfZnJvbV9zeXNfY2FsbCsweDcvMHgxYgpT ZXAgMTUgMDg6Mjc6NDAgeG1hbyBrZXJuZWw6ICBbPGZmZmZmZmZmODEwMTM3MWQ+XSA/IHJldGlu dF9yZXN0b3JlX2FyZ3MrMHg1LzB4NgpTZXAgMTUgMDg6Mjc6NDAgeG1hbyBrZXJuZWw6ICBbPGZm ZmZmZmZmODEwMTNkYTA+XSA/IGNoaWxkX3JpcCsweDAvMHgyMApTZXAgMTUgMDg6Mjc6NDAgeG1h byBrZXJuZWw6IENvZGU6IGMwIGU4IDA0IDA1IGViIGZmIDQ4IDhiIGI1IDcwIGZmIGZmIGZmIDRj IDg5IGZmIGU4IGU2IGQ4IGZmIGZmIDQ4IDhiIDc1IGM4IDRjIDg5IGZmIGU4IGRhIGQ4IGZmIGZm IDQxIDhiIDQ1IDAwIDQxIDNiIDA0IDI0IDc1IDA0IDwwZj4gMGIgZWIgZmUgNDEgMGYgYjcgNDYg MDQgMzEgZDIgNDggNmIgYzAgMGMgNDkgOGQgN2MgMjQgMGMgNDkgClNlcCAxNSAwODoyNzo0MCB4 bWFvIGtlcm5lbDogUklQICBbPGZmZmZmZmZmODExYTcwYmE+XSBleHQ0X2V4dF93eWJfaW5zZXJ0 X2V4dGVudCsweDUyMS8weDY2OQpTZXAgMTUgMDg6Mjc6NDAgeG1hbyBrZXJuZWw6ICBSU1AgPGZm ZmY4ODAxZDExZWI1MjA+ClNlcCAxNSAwODoyNzo0MCB4bWFvIGtlcm5lbDogLS0tWyBlbmQgdHJh Y2UgMjFiZmUzYzE5MjIxZTU3ZSBdLS0tClNlcCAxNSAwODoyODowNCB4bWFvIHNzaGRbMTczNThd OiBEaWQgbm90IHJlY2VpdmUgaWRlbnRpZmljYXRpb24gc3RyaW5nIGZyb20gVU5LTk9XTgpTZXAg MTUgMDg6Mjg6MzEgeG1hbyBrZXJuZWw6IEJVRzogdW5hYmxlIHRvIGhhbmRsZSBrZXJuZWwgcGFn aW5nIHJlcXVlc3QgYXQgMDAwMDAwMDVmM2VlZWUxMApTZXAgMTUgMDg6Mjg6MzEgeG1hbyBrZXJu ZWw6IElQOiBbPGZmZmZmZmZmODEwNDQ3ODQ+XSB0YXNrX3JxX2xvY2srMHg0MC8weDgyClNlcCAx NSAwODoyODozMSB4bWFvIGtlcm5lbDogUEdEIDE4Y2MwMzA2NyBQVUQgMCAKU2VwIDE1IDA4OjI4 OjMxIHhtYW8ga2VybmVsOiBPb3BzOiAwMDAwIFsjMl0gU01QIApTZXAgMTUgMDg6Mjg6MzEgeG1h byBrZXJuZWw6IGxhc3Qgc3lzZnMgZmlsZTogL3N5cy9ibG9jay90YXBkZXZoL3N0YXQKU2VwIDE1 IDA4OjI4OjMxIHhtYW8ga2VybmVsOiBDUFUgMSAKU2VwIDE1IDA4OjI4OjMxIHhtYW8ga2VybmVs OiBNb2R1bGVzIGxpbmtlZCBpbjogeHRfaXByYW5nZSB4dF9tYWMgYXJwdGFibGVfZmlsdGVyIGFy cF90YWJsZXMgeHRfcGh5c2RldiBuZl9jb25udHJhY2tfaXB2NCBuZl9kZWZyYWdfaXB2NCB4dF9z dGF0ZSBuZl9jb25udHJhY2sgaXB0YWJsZV9maWx0ZXIgaXBfdGFibGVzIGJyaWRnZSBhdXRvZnM0 IGlwbWlfZGV2aW50ZiBpcG1pX3NpIGlwbWlfbXNnaGFuZGxlciBsb2NrZCBzdW5ycGMgYm9uZGlu ZyBpcHY2IDgwMjFxIGdhcnAgc3RwIGxsYyB4ZW5mcyBkbV9tdWx0aXBhdGggZnVzZSB4ZW5fbmV0 YmFjayB4ZW5fYmxrYmFjayBibGt0YXAgYmxrYmFja19wYWdlbWFwIGxvb3AgbmJkIHZpZGVvIG91 dHB1dCBzYnMgc2JzaGMgcGFycG9ydF9wYyBscCBwYXJwb3J0IGpveWRldiBibngyIHNlcyBlbmNs b3N1cmUgcmFkZW9uIHR0bSBkcm1fa21zX2hlbHBlciBkcm0gaTJjX2FsZ29fYml0IGkyY19jb3Jl IHNuZF9zZXFfZHVtbXkgc25kX3NlcV9vc3Mgc25kX3NlcV9taWRpX2V2ZW50IHNuZF9zZXEgc25k X3NlcV9kZXZpY2Ugc25kX3BjbV9vc3Mgc25kX21peGVyX29zcyBzZXJpb19yYXcgZGNkYmFzIHNu ZF9wY20gaTVrX2FtYiBod21vbiBzbmRfdGltZXIgc25kIGlUQ09fd2R0IGk1MDAwX2VkYWMgZWRh Y19jb3JlIGlUQ09fdmVuZG9yX3N1cHBvcnQgc291bmRjb3JlIHNuZF9wYWdlX2FsbG9jIHBjc3Br ciBzaHBjaHAgW2xhc3QgdW5sb2FkZWQ6IGZyZXFfdGFibGVdClNlcCAxNSAwODoyODozMSB4bWFv IGtlcm5lbDogUGlkOiA4MDM0LCBjb21tOiBwYW5ndV9jaHVua3NlcnYgVGFpbnRlZDogRyAgICAg IEQgICAgMi42LjMyLjM2eGVuICM3IFBvd2VyRWRnZSAyOTUwClNlcCAxNSAwODoyODozMSB4bWFv IGtlcm5lbDogUklQOiBlMDMwOls8ZmZmZmZmZmY4MTA0NDc4ND5dICBbPGZmZmZmZmZmODEwNDQ3 ODQ+XSB0YXNrX3JxX2xvY2srMHg0MC8weDgyClNlcCAxNSAwODoyODozMSB4bWFvIGtlcm5lbDog UlNQOiBlMDJiOmZmZmY4ODAxMTEzYTdiMzggIEVGTEFHUzogMDAwMTAwMDIKU2VwIDE1IDA4OjI4 OjMxIHhtYW8ga2VybmVsOiBSQVg6IDAwMDAwMDAwY2U0ZmRjMGUgUkJYOiAwMDAwMDAwMDAwMDE1 NjAwIFJDWDogMDAwMDAwMDAwMDAwMDAwMApTZXAgMTUgMDg6Mjg6MzEgeG1hbyBrZXJuZWw6IFJE WDogMDAwMDAwMDAwMDAwMDIwMSBSU0k6IGZmZmY4ODAxMTEzYTdiODggUkRJOiBmZmZmODgwMWNk OGJkYjQwClNlcCAxNSAwODoyODozMSB4bWFvIGtlcm5lbDogUkJQOiBmZmZmODgwMTExM2E3YjY4 IFIwODogMDAwMDAwMDAwMDAwMDAyMCBSMDk6IGZmZmY4ODAxMzM4Mjk2ZDAKU2VwIDE1IDA4OjI4 OjMxIHhtYW8ga2VybmVsOiBSMTA6IGZmZmY4ODAxY2YwODJkZTggUjExOiBmZmZmODgwMTExM2E3 YWY4IFIxMjogMDAwMDAwMDAwMDAxNTYwMApTZXAgMTUgMDg6Mjg6MzEgeG1hbyBrZXJuZWw6IFIx MzogZmZmZjg4MDExMTNhN2I4OCBSMTQ6IGZmZmY4ODAxY2Q4YmRiNDAgUjE1OiAwMDAwMDAwMDAw MDAwMDAwClNlcCAxNSAwODoyODozMSB4bWFvIGtlcm5lbDogRlM6ICAwMDAwN2ZkZDkwNzFkNmUw KDAwNjMpIEdTOmZmZmY4ODAwMjgwNTUwMDAoMDAwMCkga25sR1M6MDAwMDAwMDAwMDAwMDAwMApT ZXAgMTUgMDg6Mjg6MzEgeG1hbyBrZXJuZWw6IENTOiAgZTAzMyBEUzogMDAwMCBFUzogMDAwMCBD UjA6IDAwMDAwMDAwODAwNTAwM2IKU2VwIDE1IDA4OjI4OjMxIHhtYW8ga2VybmVsOiBDUjI6IDAw MDAwMDA1ZjNlZWVlMTAgQ1IzOiAwMDAwMDAwMThjYzI1MDAwIENSNDogMDAwMDAwMDAwMDAwMjY2 MApTZXAgMTUgMDg6Mjg6MzEgeG1hbyBrZXJuZWw6IERSMDogMDAwMDAwMDAwMDAwMDAwMCBEUjE6 IDAwMDAwMDAwMDAwMDAwMDAgRFIyOiAwMDAwMDAwMDAwMDAwMDAwClNlcCAxNSAwODoyODozMSB4 bWFvIGtlcm5lbDogRFIzOiAwMDAwMDAwMDAwMDAwMDAwIERSNjogMDAwMDAwMDBmZmZmMGZmMCBE Ujc6IDAwMDAwMDAwMDAwMDA0MDAKU2VwIDE1IDA4OjI4OjMyIHhtYW8ga2VybmVsOiBQcm9jZXNz IHBhbmd1X2NodW5rc2VydiAocGlkOiA4MDM0LCB0aHJlYWRpbmZvIGZmZmY4ODAxMTEzYTYwMDAs IHRhc2sgZmZmZjg4MDExMTNhYWRhMCkKU2VwIDE1IDA4OjI4OjMyIHhtYW8ga2VybmVsOiBTdGFj azoKU2VwIDE1IDA4OjI4OjMyIHhtYW8ga2VybmVsOiAgZmZmZjg4MDExMTNhN2FmOCAwMDAwMDAw MDAwMDI4MGRhIDAwMDAwMDAwMDAwMDAwMGYgZmZmZjg4MDFjZDhiZGI0MApTZXAgMTUgMDg6Mjg6 MzIgeG1hbyBrZXJuZWw6IDwwPiBmZmZmODgwMTExM2E3YzI4IDAwMDAwMDAwMDAwMDAwMGMgZmZm Zjg4MDExMTNhN2JiOCBmZmZmZmZmZjgxMDRhZTZjClNlcCAxNSAwODoyODozMiB4bWFvIGtlcm5l bDogPDA+IDAwMDAwMDAxMDAwMDAwMDAgMDAwMDAwMDAwMDAwMDIwMSAwMDAwMDAwMDAwMDAwMjAx IGZmZmY4ODAxZDBmMTJjMDAKU2VwIDE1IDA4OjI4OjMyIHhtYW8ga2VybmVsOiBDYWxsIFRyYWNl OgpTZXAgMTUgMDg6Mjg6MzIgeG1hbyBrZXJuZWw6ICBbPGZmZmZmZmZmODEwNGFlNmM+XSB0cnlf dG9fd2FrZV91cCsweDQ0LzB4MzFkClNlcCAxNSAwODoyODozMiB4bWFvIGtlcm5lbDogIFs8ZmZm ZmZmZmY4MTA0YjE4MD5dIHdha2VfdXBfcHJvY2VzcysweDE1LzB4MTcKU2VwIDE1IDA4OjI4OjMy IHhtYW8ga2VybmVsOiAgWzxmZmZmZmZmZjgxMTJjZmFiPl0gYmRpX3F1ZXVlX3dvcmsrMHg5Yy8w eGExClNlcCAxNSAwODoyODozMiB4bWFvIGtlcm5lbDogIFs8ZmZmZmZmZmY4MTEyZDE2MT5dIGJk aV9hbGxvY19xdWV1ZV93b3JrKzB4NjgvMHg4NApTZXAgMTUgMDg6Mjg6MzIgeG1hbyBrZXJuZWw6 ICBbPGZmZmZmZmZmODExMmQxZTg+XSB3YWtldXBfZmx1c2hlcl90aHJlYWRzKzB4NmIvMHg4NApT ZXAgMTUgMDg6Mjg6MzIgeG1hbyBrZXJuZWw6ICBbPGZmZmZmZmZmODEwZGRhODI+XSBkb190cnlf dG9fZnJlZV9wYWdlcysweDIyYy8weDMxMApTZXAgMTUgMDg6Mjg6MzIgeG1hbyBrZXJuZWw6ICBb PGZmZmZmZmZmODEwZGRjOGE+XSB0cnlfdG9fZnJlZV9wYWdlcysweDg5LzB4OTgKU2VwIDE1IDA4 OjI4OjMyIHhtYW8ga2VybmVsOiAgWzxmZmZmZmZmZjgxMGRjMDJmPl0gPyBpc29sYXRlX3BhZ2Vz X2dsb2JhbCsweDAvMHgxZjgKU2VwIDE1IDA4OjI4OjMyIHhtYW8ga2VybmVsOiAgWzxmZmZmZmZm ZjgxMGQ3NDcxPl0gX19hbGxvY19wYWdlc19ub2RlbWFzaysweDM3MS8weDViMApTZXAgMTUgMDg6 Mjg6MzIgeG1hbyBrZXJuZWw6ICBbPGZmZmZmZmZmODEwMGNlMzY+XSA/IGdldF9waHlzX3RvX21h Y2hpbmUrMHgzMi8weDRlClNlcCAxNSAwODoyODozMiB4bWFvIGtlcm5lbDogIFs8ZmZmZmZmZmY4 MTAwZDI4ZT5dID8geGVuX3B0ZV92YWwrMHg2OS8weDczClNlcCAxNSAwODoyODozMiB4bWFvIGtl cm5lbDogIFs8ZmZmZmZmZmY4MTBlOTkyYj5dIGFsbG9jX3BhZ2VzX25vZGUrMHgxYi8weDFkClNl cCAxNSAwODoyODozMiB4bWFvIGtlcm5lbDogIFs8ZmZmZmZmZmY4MTBlOTk0ND5dIGFsbG9jX3pl cm9lZF91c2VyX2hpZ2hwYWdlX21vdmFibGUrMHgxNy8weDE5ClNlcCAxNSAwODoyODozMiB4bWFv IGtlcm5lbDogIFs8ZmZmZmZmZmY4MTBlYjlhMz5dIGhhbmRsZV9tbV9mYXVsdCsweDIzYy8weDc3 MQpTZXAgMTUgMDg6Mjg6MzIgeG1hbyBrZXJuZWw6ICBbPGZmZmZmZmZmODEwMmZkZmM+XSA/IHB2 Y2xvY2tfY2xvY2tzb3VyY2VfcmVhZCsweDQyLzB4OTkKU2VwIDE1IDA4OjI4OjMyIHhtYW8ga2Vy bmVsOiAgWzxmZmZmZmZmZjgxMDBmNmYyPl0gPyB4ZW5fY2xvY2tzb3VyY2VfcmVhZCsweDIxLzB4 MjMKU2VwIDE1IDA4OjI4OjMyIHhtYW8ga2VybmVsOiAgWzxmZmZmZmZmZjgxMDBmODU5Pl0gPyB4 ZW5fY2xvY2tzb3VyY2VfZ2V0X2N5Y2xlcysweDkvMHgxMApTZXAgMTUgMDg6Mjg6MzIgeG1hbyBr ZXJuZWw6ICBbPGZmZmZmZmZmODE0NDBkYjE+XSBkb19wYWdlX2ZhdWx0KzB4MjFjLzB4Mjg4ClNl cCAxNSAwODoyODozMiB4bWFvIGtlcm5lbDogIFs8ZmZmZmZmZmY4MTQzZWQ0NT5dIHBhZ2VfZmF1 bHQrMHgyNS8weDMwClNlcCAxNSAwODoyODozMiB4bWFvIGtlcm5lbDogQ29kZTogODkgZmUgNDkg ODkgZjUgZmYgMTQgMjUgYzAgZGIgNjYgODEgNDggODkgYzIgZmYgMTQgMjUgZDAgZGIgNjYgODEg NDggYzcgYzMgMDAgNTYgMDEgMDAgNDkgODkgNTUgMDAgNDkgOGIgNDYgMDggOGIgNDAgMTggNDkg ODkgZGMgPDRjPiAwMyAyNCBjNSBhMCAwZCA3MCA4MSA0YyA4OSBlNyBlOCA4MSBhMSAzZiAwMCA0 OSA4YiA0NiAwOCA4YiAKU2VwIDE1IDA4OjI4OjMyIHhtYW8ga2VybmVsOiBSSVAgIFs8ZmZmZmZm ZmY4MTA0NDc4ND5dIHRhc2tfcnFfbG9jaysweDQwLzB4ODIKU2VwIDE1IDA4OjI4OjMyIHhtYW8g a2VybmVsOiAgUlNQIDxmZmZmODgwMTExM2E3YjM4PgpTZXAgMTUgMDg6Mjg6MzIgeG1hbyBrZXJu ZWw6IENSMjogMDAwMDAwMDVmM2VlZWUxMApTZXAgMTUgMDg6Mjg6MzIgeG1hbyBrZXJuZWw6IC0t LVsgZW5kIHRyYWNlIDIxYmZlM2MxOTIyMWU1N2YgXS0tLQpTZXAgMTUgMDg6Mjg6MzIgeG1hbyBr ZXJuZWw6IEJVRzogdW5hYmxlIHRvIGhhbmRsZSBrZXJuZWwgcGFnaW5nIHJlcXVlc3QgYXQgMDAw MDAwMDVmM2VlZWUxMApTZXAgMTUgMDg6Mjg6MzIgeG1hbyBrZXJuZWw6IElQOiBbPGZmZmZmZmZm ODEwNDQ3ODQ+XSB0YXNrX3JxX2xvY2srMHg0MC8weDgyClNlcCAxNSAwODoyODozMiB4bWFvIGtl cm5lbDogUEdEIDE4Y2MwMzA2NyBQVUQgMCAKU2VwIDE1IDA4OjI4OjMyIHhtYW8ga2VybmVsOiBP b3BzOiAwMDAwIFsjM10gU01QIApTZXAgMTUgMDg6Mjg6MzIgeG1hbyBrZXJuZWw6IGxhc3Qgc3lz ZnMgZmlsZTogL3N5cy9ibG9jay90YXBkZXZoL3N0YXQKU2VwIDE1IDA4OjI4OjMyIHhtYW8ga2Vy bmVsOiBDUFUgMyAKU2VwIDE1IDA4OjI4OjMyIHhtYW8ga2VybmVsOiBNb2R1bGVzIGxpbmtlZCBp bjogeHRfaXByYW5nZSB4dF9tYWMgYXJwdGFibGVfZmlsdGVyIGFycF90YWJsZXMgeHRfcGh5c2Rl diBuZl9jb25udHJhY2tfaXB2NCBuZl9kZWZyYWdfaXB2NCB4dF9zdGF0ZSBuZl9jb25udHJhY2sg aXB0YWJsZV9maWx0ZXIgaXBfdGFibGVzIGJyaWRnZSBhdXRvZnM0IGlwbWlfZGV2aW50ZiBpcG1p X3NpIGlwbWlfbXNnaGFuZGxlciBsb2NrZCBzdW5ycGMgYm9uZGluZyBpcHY2IDgwMjFxIGdhcnAg c3RwIGxsYyB4ZW5mcyBkbV9tdWx0aXBhdGggZnVzZSB4ZW5fbmV0YmFjayB4ZW5fYmxrYmFjayBi bGt0YXAgYmxrYmFja19wYWdlbWFwIGxvb3AgbmJkIHZpZGVvIG91dHB1dCBzYnMgc2JzaGMgcGFy cG9ydF9wYyBscCBwYXJwb3J0IGpveWRldiBibngyIHNlcyBlbmNsb3N1cmUgcmFkZW9uIHR0bSBk cm1fa21zX2hlbHBlciBkcm0gaTJjX2FsZ29fYml0IGkyY19jb3JlIHNuZF9zZXFfZHVtbXkgc25k X3NlcV9vc3Mgc25kX3NlcV9taWRpX2V2ZW50IHNuZF9zZXEgc25kX3NlcV9kZXZpY2Ugc25kX3Bj bV9vc3Mgc25kX21peGVyX29zcyBzZXJpb19yYXcgZGNkYmFzIHNuZF9wY20gaTVrX2FtYiBod21v biBzbmRfdGltZXIgc25kIGlUQ09fd2R0IGk1MDAwX2VkYWMgZWRhY19jb3JlIGlUQ09fdmVuZG9y X3N1cHBvcnQgc291bmRjb3JlIHNuZF9wYWdlX2FsbG9jIHBjc3BrciBzaHBjaHAgW2xhc3QgdW5s b2FkZWQ6IGZyZXFfdGFibGVdClNlcCAxNSAwODoyODozMiB4bWFvIGtlcm5lbDogUGlkOiA3OTM0 LCBjb21tOiBwYW5ndV9jaHVua3NlcnYgVGFpbnRlZDogRyAgICAgIEQgICAgMi42LjMyLjM2eGVu ICM3IFBvd2VyRWRnZSAyOTUwClNlcCAxNSAwODoyODozMiB4bWFvIGtlcm5lbDogUklQOiBlMDMw Ols8ZmZmZmZmZmY4MTA0NDc4ND5dICBbPGZmZmZmZmZmODEwNDQ3ODQ+XSB0YXNrX3JxX2xvY2sr MHg0MC8weDgyClNlcCAxNSAwODoyODozMiB4bWFvIGtlcm5lbDogUlNQOiBlMDJiOmZmZmY4ODAx NTA3MzNiMzggIEVGTEFHUzogMDAwMTAwMDIKU2VwIDE1IDA4OjI4OjMyIHhtYW8ga2VybmVsOiBS QVg6IDAwMDAwMDAwY2U0ZmRjMGUgUkJYOiAwMDAwMDAwMDAwMDE1NjAwIFJDWDogMDAwMDAwMDAw MDAwMDAwMApTZXAgMTUgMDg6Mjg6MzIgeG1hbyBrZXJuZWw6IFJEWDogMDAwMDAwMDAwMDAwMDIw MyBSU0k6IGZmZmY4ODAxNTA3MzNiODggUkRJOiBmZmZmODgwMWNkOGJkYjQwClNlcCAxNSAwODoy ODozMiB4bWFvIGtlcm5lbDogUkJQOiBmZmZmODgwMTUwNzMzYjY4IFIwODogMDAwMDAwMDAwMDAw MDAyMCBSMDk6IGZmZmY4ODAxY2YwODJkZDgKU2VwIDE1IDA4OjI4OjMyIHhtYW8ga2VybmVsOiBS MTA6IDAwMDAwMDAwMDAwMDAwMDAgUjExOiBmZmZmODgwMTUwNzMzYWY4IFIxMjogMDAwMDAwMDAw MDAxNTYwMApTZXAgMTUgMDg6Mjg6MzIgeG1hbyBrZXJuZWw6IFIxMzogZmZmZjg4MDE1MDczM2I4 OCBSMTQ6IGZmZmY4ODAxY2Q4YmRiNDAgUjE1OiAwMDAwMDAwMDAwMDAwMDAwClNlcCAxNSAwODoy ODozMiB4bWFvIGtlcm5lbDogRlM6ICAwMDAwN2Y5YjA0ZTYxNzQwKDAwNjMpIEdTOmZmZmY4ODAw MjgwOGYwMDAoMDAwMCkga25sR1M6MDAwMDAwMDAwMDAwMDAwMApTZXAgMTUgMDg6Mjg6MzIgeG1h byBrZXJuZWw6IENTOiAgZTAzMyBEUzogMDAwMCBFUzogMDAwMCBDUjA6IDAwMDAwMDAwODAwNTAw M2IKU2VwIDE1IDA4OjI4OjMyIHhtYW8ga2VybmVsOiBDUjI6IDAwMDAwMDA1ZjNlZWVlMTAgQ1Iz OiAwMDAwMDAwMThjYzI1MDAwIENSNDogMDAwMDAwMDAwMDAwMjY2MApTZXAgMTUgMDg6Mjg6MzIg eG1hbyBrZXJuZWw6IERSMDogMDAwMDAwMDAwMDAwMDAwMCBEUjE6IDAwMDAwMDAwMDAwMDAwMDAg RFIyOiAwMDAwMDAwMDAwMDAwMDAwClNlcCAxNSAwODoyODozMiB4bWFvIGtlcm5lbDogRFIzOiAw MDAwMDAwMDAwMDAwMDAwIERSNjogMDAwMDAwMDBmZmZmMGZmMCBEUjc6IDAwMDAwMDAwMDAwMDA0 MDAKU2VwIDE1IDA4OjI4OjMyIHhtYW8ga2VybmVsOiBQcm9jZXNzIHBhbmd1X2NodW5rc2VydiAo cGlkOiA3OTM0LCB0aHJlYWRpbmZvIGZmZmY4ODAxNTA3MzIwMDAsIHRhc2sgZmZmZjg4MDEzMzgy OTZkMCkKU2VwIDE1IDA4OjI4OjMyIHhtYW8ga2VybmVsOiBTdGFjazoKU2VwIDE1IDA4OjI4OjMy IHhtYW8ga2VybmVsOiAgZmZmZjg4MDE1MDczM2FmOCAwMDAwMDAwMDAwMDI4MGRhIDAwMDAwMDAw MDAwMDAwMGYgZmZmZjg4MDFjZDhiZGI0MApTZXAgMTUgMDg6Mjg6MzIgeG1hbyBrZXJuZWw6IDww PiBmZmZmODgwMTUwNzMzYzI4IDAwMDAwMDAwMDAwMDAwMGIgZmZmZjg4MDE1MDczM2JiOCBmZmZm ZmZmZjgxMDRhZTZjClNlcCAxNSAwODoyODozMiB4bWFvIGtlcm5lbDogPDA+IDAwMDAwMDAzMDAw MDAwMDAgMDAwMDAwMDAwMDAwMDIwMSAwMDAwMDAwMDAwMDAwMjAzIGZmZmY4ODAxZDBmMTJjMDAK U2VwIDE1IDA4OjI4OjMyIHhtYW8ga2VybmVsOiBDYWxsIFRyYWNlOgpTZXAgMTUgMDg6Mjg6MzIg eG1hbyBrZXJuZWw6ICBbPGZmZmZmZmZmODEwNGFlNmM+XSB0cnlfdG9fd2FrZV91cCsweDQ0LzB4 MzFkClNlcCAxNSAwODoyODozMiB4bWFvIGtlcm5lbDogIFs8ZmZmZmZmZmY4MTA0YjE4MD5dIHdh a2VfdXBfcHJvY2VzcysweDE1LzB4MTcKU2VwIDE1IDA4OjI4OjMyIHhtYW8ga2VybmVsOiAgWzxm ZmZmZmZmZjgxMTJjZmFiPl0gYmRpX3F1ZXVlX3dvcmsrMHg5Yy8weGExClNlcCAxNSAwODoyODoz MiB4bWFvIGtlcm5lbDogIFs8ZmZmZmZmZmY4MTEyZDE2MT5dIGJkaV9hbGxvY19xdWV1ZV93b3Jr KzB4NjgvMHg4NApTZXAgMTUgMDg6Mjg6MzIgeG1hbyBrZXJuZWw6ICBbPGZmZmZmZmZmODExMmQx ZTg+XSB3YWtldXBfZmx1c2hlcl90aHJlYWRzKzB4NmIvMHg4NApTZXAgMTUgMDg6Mjg6MzIgeG1h byBrZXJuZWw6ICBbPGZmZmZmZmZmODEwZGRhODI+XSBkb190cnlfdG9fZnJlZV9wYWdlcysweDIy Yy8weDMxMApTZXAgMTUgMDg6Mjg6MzIgeG1hbyBrZXJuZWw6ICBbPGZmZmZmZmZmODEwZGRjOGE+ XSB0cnlfdG9fZnJlZV9wYWdlcysweDg5LzB4OTgKU2VwIDE1IDA4OjI4OjMyIHhtYW8ga2VybmVs OiAgWzxmZmZmZmZmZjgxMGRjMDJmPl0gPyBpc29sYXRlX3BhZ2VzX2dsb2JhbCsweDAvMHgxZjgK U2VwIDE1IDA4OjI4OjMyIHhtYW8ga2VybmVsOiAgWzxmZmZmZmZmZjgxMGQ3NDcxPl0gX19hbGxv Y19wYWdlc19ub2RlbWFzaysweDM3MS8weDViMApTZXAgMTUgMDg6Mjg6MzIgeG1hbyBrZXJuZWw6 ICBbPGZmZmZmZmZmODEwMGNlMzY+XSA/IGdldF9waHlzX3RvX21hY2hpbmUrMHgzMi8weDRlClNl cCAxNSAwODoyODozMiB4bWFvIGtlcm5lbDogIFs8ZmZmZmZmZmY4MTAwZDI4ZT5dID8geGVuX3B0 ZV92YWwrMHg2OS8weDczClNlcCAxNSAwODoyODozMiB4bWFvIGtlcm5lbDogIFs8ZmZmZmZmZmY4 MTBlOTkyYj5dIGFsbG9jX3BhZ2VzX25vZGUrMHgxYi8weDFkClNlcCAxNSAwODoyODozMiB4bWFv IGtlcm5lbDogIFs8ZmZmZmZmZmY4MTBlOTk0ND5dIGFsbG9jX3plcm9lZF91c2VyX2hpZ2hwYWdl X21vdmFibGUrMHgxNy8weDE5ClNlcCAxNSAwODoyODozMiB4bWFvIGtlcm5lbDogIFs8ZmZmZmZm ZmY4MTBlYjlhMz5dIGhhbmRsZV9tbV9mYXVsdCsweDIzYy8weDc3MQpTZXAgMTUgMDg6Mjg6MzIg eG1hbyBrZXJuZWw6ICBbPGZmZmZmZmZmODEwMGI0NTk+XSA/IHhlbl9lbmRfY29udGV4dF9zd2l0 Y2grMHgxZS8weDIyClNlcCAxNSAwODoyODozMiB4bWFvIGtlcm5lbDogIFs8ZmZmZmZmZmY4MTA0 OWE1Yj5dID8gZmluaXNoX3Rhc2tfc3dpdGNoKzB4NTEvMHhhOQpTZXAgMTUgMDg6Mjg6MzIgeG1h byBrZXJuZWw6ICBbPGZmZmZmZmZmODE0NDBkYjE+XSBkb19wYWdlX2ZhdWx0KzB4MjFjLzB4Mjg4 ClNlcCAxNSAwODoyODozMiB4bWFvIGtlcm5lbDogIFs8ZmZmZmZmZmY4MTQzZWQ0NT5dIHBhZ2Vf ZmF1bHQrMHgyNS8weDMwClNlcCAxNSAwODoyODozMiB4bWFvIGtlcm5lbDogQ29kZTogODkgZmUg NDkgODkgZjUgZmYgMTQgMjUgYzAgZGIgNjYgODEgNDggODkgYzIgZmYgMTQgMjUgZDAgZGIgNjYg ODEgNDggYzcgYzMgMDAgNTYgMDEgMDAgNDkgODkgNTUgMDAgNDkgOGIgNDYgMDggOGIgNDAgMTgg NDkgODkgZGMgPDRjPiAwMyAyNCBjNSBhMCAwZCA3MCA4MSA0YyA4OSBlNyBlOCA4MSBhMSAzZiAw MCA0OSA4YiA0NiAwOCA4YiAKU2VwIDE1IDA4OjI4OjMyIHhtYW8ga2VybmVsOiBSSVAgIFs8ZmZm ZmZmZmY4MTA0NDc4ND5dIHRhc2tfcnFfbG9jaysweDQwLzB4ODIKU2VwIDE1IDA4OjI4OjMyIHht YW8ga2VybmVsOiAgUlNQIDxmZmZmODgwMTUwNzMzYjM4PgpTZXAgMTUgMDg6Mjg6MzIgeG1hbyBr ZXJuZWw6IENSMjogMDAwMDAwMDVmM2VlZWUxMApTZXAgMTUgMDg6Mjg6MzIgeG1hbyBrZXJuZWw6 IC0tLVsgZW5kIHRyYWNlIDIxYmZlM2MxOTIyMWU1ODAgXS0tLQpTZXAgMTUgMDg6Mjg6MzIgeG1h byBrZXJuZWw6IEJVRzogdW5hYmxlIHRvIGhhbmRsZSBrZXJuZWwgcGFnaW5nIHJlcXVlc3QgYXQg MDAwMDAwMDVmM2VlZWUxMApTZXAgMTUgMDg6Mjg6MzIgeG1hbyBrZXJuZWw6IElQOiBbPGZmZmZm ZmZmODEwNDQ3ODQ+XSB0YXNrX3JxX2xvY2srMHg0MC8weDgyClNlcCAxNSAwODoyODozMiB4bWFv IGtlcm5lbDogUEdEIDE5MmYxNTA2NyBQVUQgMCAKU2VwIDE1IDA4OjI4OjMyIHhtYW8ga2VybmVs OiBPb3BzOiAwMDAwIFsjNF0gU01QIApTZXAgMTUgMDg6Mjg6MzIgeG1hbyBrZXJuZWw6IGxhc3Qg c3lzZnMgZmlsZTogL3N5cy9ibG9jay90YXBkZXZoL3N0YXQKU2VwIDE1IDA4OjI4OjMyIHhtYW8g a2VybmVsOiBDUFUgMiAKU2VwIDE1IDA4OjI4OjMyIHhtYW8ga2VybmVsOiBNb2R1bGVzIGxpbmtl ZCBpbjogeHRfaXByYW5nZSB4dF9tYWMgYXJwdGFibGVfZmlsdGVyIGFycF90YWJsZXMgeHRfcGh5 c2RldiBuZl9jb25udHJhY2tfaXB2NCBuZl9kZWZyYWdfaXB2NCB4dF9zdGF0ZSBuZl9jb25udHJh Y2sgaXB0YWJsZV9maWx0ZXIgaXBfdGFibGVzIGJyaWRnZSBhdXRvZnM0IGlwbWlfZGV2aW50ZiBp cG1pX3NpIGlwbWlfbXNnaGFuZGxlciBsb2NrZCBzdW5ycGMgYm9uZGluZyBpcHY2IDgwMjFxIGdh cnAgc3RwIGxsYyB4ZW5mcyBkbV9tdWx0aXBhdGggZnVzZSB4ZW5fbmV0YmFjayB4ZW5fYmxrYmFj ayBibGt0YXAgYmxrYmFja19wYWdlbWFwIGxvb3AgbmJkIHZpZGVvIG91dHB1dCBzYnMgc2JzaGMg cGFycG9ydF9wYyBscCBwYXJwb3J0IGpveWRldiBibngyIHNlcyBlbmNsb3N1cmUgcmFkZW9uIHR0 bSBkcm1fa21zX2hlbHBlciBkcm0gaTJjX2FsZ29fYml0IGkyY19jb3JlIHNuZF9zZXFfZHVtbXkg c25kX3NlcV9vc3Mgc25kX3NlcV9taWRpX2V2ZW50IHNuZF9zZXEgc25kX3NlcV9kZXZpY2Ugc25k X3BjbV9vc3Mgc25kX21peGVyX29zcyBzZXJpb19yYXcgZGNkYmFzIHNuZF9wY20gaTVrX2FtYiBo d21vbiBzbmRfdGltZXIgc25kIGlUQ09fd2R0IGk1MDAwX2VkYWMgZWRhY19jb3JlIGlUQ09fdmVu ZG9yX3N1cHBvcnQgc291bmRjb3JlIHNuZF9wYWdlX2FsbG9jIHBjc3BrciBzaHBjaHAgW2xhc3Qg dW5sb2FkZWQ6IGZyZXFfdGFibGVdClNlcCAxNSAwODoyODozMiB4bWFvIGtlcm5lbDogUGlkOiA2 NjAxLCBjb21tOiBudXdhX2FnZW50IFRhaW50ZWQ6IEcgICAgICBEICAgIDIuNi4zMi4zNnhlbiAj NyBQb3dlckVkZ2UgMjk1MApTZXAgMTUgMDg6Mjg6MzIgeG1hbyBrZXJuZWw6IFJJUDogZTAzMDpb PGZmZmZmZmZmODEwNDQ3ODQ+XSAgWzxmZmZmZmZmZjgxMDQ0Nzg0Pl0gdGFza19ycV9sb2NrKzB4 NDAvMHg4MgpTZXAgMTUgMDg6Mjg6MzIgeG1hbyBrZXJuZWw6IFJTUDogZTAyYjpmZmZmODgwMThj Y2UzYmI4ICBFRkxBR1M6IDAwMDEwMDAyClNlcCAxNSAwODoyODozMiB4bWFvIGtlcm5lbDogUkFY OiAwMDAwMDAwMGNlNGZkYzBlIFJCWDogMDAwMDAwMDAwMDAxNTYwMCBSQ1g6IDAwMDAwMDAwMDAw MDAwMDAKU2VwIDE1IDA4OjI4OjMyIHhtYW8ga2VybmVsOiBSRFg6IDAwMDAwMDAwMDAwMDAyMDIg UlNJOiBmZmZmODgwMThjY2UzYzA4IFJESTogZmZmZjg4MDFjZDhiZGI0MApTZXAgMTUgMDg6Mjg6 MzIgeG1hbyBrZXJuZWw6IFJCUDogZmZmZjg4MDE4Y2NlM2JlOCBSMDg6IDAwMDAwMDAwMDAwMDAw MjAgUjA5OiBmZmZmODgwMWNmMDgyZGQ4ClNlcCAxNSAwODoyODozMiB4bWFvIGtlcm5lbDogUjEw OiAwMDAwMDAwMDAwMDAwMDAwIFIxMTogZmZmZjg4MDE4Y2NlM2IyOCBSMTI6IDAwMDAwMDAwMDAw MTU2MDAKU2VwIDE1IDA4OjI4OjMyIHhtYW8ga2VybmVsOiBSMTM6IGZmZmY4ODAxOGNjZTNjMDgg UjE0OiBmZmZmODgwMWNkOGJkYjQwIFIxNTogMDAwMDAwMDAwMDAwMDAwMApTZXAgMTUgMDg6Mjg6 MzIgeG1hbyBrZXJuZWw6IEZTOiAgMDAwMDdmMjNkOThmZTczMCgwMDYzKSBHUzpmZmZmODgwMDI4 MDcyMDAwKDAwMDApIGtubEdTOjAwMDAwMDAwMDAwMDAwMDAKU2VwIDE1IDA4OjI4OjMyIHhtYW8g a2VybmVsOiBDUzogIGUwMzMgRFM6IDAwMDAgRVM6IDAwMDAgQ1IwOiAwMDAwMDAwMDgwMDUwMDNi ClNlcCAxNSAwODoyODozMiB4bWFvIGtlcm5lbDogQ1IyOiAwMDAwMDAwNWYzZWVlZTEwIENSMzog MDAwMDAwMDFjNzNkMTAwMCBDUjQ6IDAwMDAwMDAwMDAwMDI2NjAKU2VwIDE1IDA4OjI4OjMyIHht YW8ga2VybmVsOiBEUjA6IDAwMDAwMDAwMDAwMDAwMDAgRFIxOiAwMDAwMDAwMDAwMDAwMDAwIERS MjogMDAwMDAwMDAwMDAwMDAwMApTZXAgMTUgMDg6Mjg6MzIgeG1hbyBrZXJuZWw6IERSMzogMDAw MDAwMDAwMDAwMDAwMCBEUjY6IDAwMDAwMDAwZmZmZjBmZjAgRFI3OiAwMDAwMDAwMDAwMDAwNDAw ClNlcCAxNSAwODoyODozMiB4bWFvIGtlcm5lbDogUHJvY2VzcyBudXdhX2FnZW50IChwaWQ6IDY2 MDEsIHRocmVhZGluZm8gZmZmZjg4MDE4Y2NlMjAwMCwgdGFzayBmZmZmODgwMThjY2M5NmQwKQpT ZXAgMTUgMDg6Mjg6MzIgeG1hbyBrZXJuZWw6IFN0YWNrOgpTZXAgMTUgMDg6Mjg6MzIgeG1hbyBr ZXJuZWw6ICBmZmZmODgwMThjY2UzYjI4IDAwMDAwMDAwMDAwODAwZDAgMDAwMDAwMDAwMDAwMDAw ZiBmZmZmODgwMWNkOGJkYjQwClNlcCAxNSAwODoyODozMiB4bWFvIGtlcm5lbDogPDA+IGZmZmY4 ODAxOGNjZTNjYTggMDAwMDAwMDAwMDAwMDAwYiBmZmZmODgwMThjY2UzYzM4IGZmZmZmZmZmODEw NGFlNmMKU2VwIDE1IDA4OjI4OjMyIHhtYW8ga2VybmVsOiA8MD4gMDAwMDAwMDIwMDAwMDAwMCAw MDAwMDAwMDAwMDAwMjAxIDAwMDAwMDAwMDAwMDAyMDIgZmZmZjg4MDFkMGYxMmMwMApTZXAgMTUg MDg6Mjg6MzIgeG1hbyBrZXJuZWw6IENhbGwgVHJhY2U6ClNlcCAxNSAwODoyODozMiB4bWFvIGtl cm5lbDogIFs8ZmZmZmZmZmY4MTA0YWU2Yz5dIHRyeV90b193YWtlX3VwKzB4NDQvMHgzMWQKU2Vw IDE1IDA4OjI4OjMyIHhtYW8ga2VybmVsOiAgWzxmZmZmZmZmZjgxMDRiMTgwPl0gd2FrZV91cF9w cm9jZXNzKzB4MTUvMHgxNwpTZXAgMTUgMDg6Mjg6MzIgeG1hbyBrZXJuZWw6ICBbPGZmZmZmZmZm ODExMmNmYWI+XSBiZGlfcXVldWVfd29yaysweDljLzB4YTEKU2VwIDE1IDA4OjI4OjMyIHhtYW8g a2VybmVsOiAgWzxmZmZmZmZmZjgxMTJkMTYxPl0gYmRpX2FsbG9jX3F1ZXVlX3dvcmsrMHg2OC8w eDg0ClNlcCAxNSAwODoyODozMiB4bWFvIGtlcm5lbDogIFs8ZmZmZmZmZmY4MTEyZDFlOD5dIHdh a2V1cF9mbHVzaGVyX3RocmVhZHMrMHg2Yi8weDg0ClNlcCAxNSAwODoyODozMiB4bWFvIGtlcm5l bDogIFs8ZmZmZmZmZmY4MTBkZGE4Mj5dIGRvX3RyeV90b19mcmVlX3BhZ2VzKzB4MjJjLzB4MzEw ClNlcCAxNSAwODoyODozMiB4bWFvIGtlcm5lbDogIFs8ZmZmZmZmZmY4MTBkZGM4YT5dIHRyeV90 b19mcmVlX3BhZ2VzKzB4ODkvMHg5OApTZXAgMTUgMDg6Mjg6MzIgeG1hbyBrZXJuZWw6ICBbPGZm ZmZmZmZmODEwZGMwMmY+XSA/IGlzb2xhdGVfcGFnZXNfZ2xvYmFsKzB4MC8weDFmOApTZXAgMTUg MDg6Mjg6MzIgeG1hbyBrZXJuZWw6ICBbPGZmZmZmZmZmODEwZDc0NzE+XSBfX2FsbG9jX3BhZ2Vz X25vZGVtYXNrKzB4MzcxLzB4NWIwClNlcCAxNSAwODoyODozMiB4bWFvIGtlcm5lbDogIFs8ZmZm ZmZmZmY4MTA0MmZlNz5dID8gc2hvdWxkX3Jlc2NoZWQrMHhlLzB4MmYKU2VwIDE1IDA4OjI4OjMy IHhtYW8ga2VybmVsOiAgWzxmZmZmZmZmZjgxMGQ3NmNjPl0gX19nZXRfZnJlZV9wYWdlcysweDFj LzB4NjQKU2VwIDE1IDA4OjI4OjMyIHhtYW8ga2VybmVsOiAgWzxmZmZmZmZmZjgxMTYwOTNiPl0g cHJvY19waWRfcmVhZGxpbmsrMHg1ZC8weGQyClNlcCAxNSAwODoyODozMiB4bWFvIGtlcm5lbDog IFs8ZmZmZmZmZmY4MTExMWIyYz5dIHN5c19yZWFkbGlua2F0KzB4N2YvMHg5OApTZXAgMTUgMDg6 Mjg6MzIgeG1hbyBrZXJuZWw6ICBbPGZmZmZmZmZmODExMTFiNjA+XSBzeXNfcmVhZGxpbmsrMHgx Yi8weDFkClNlcCAxNSAwODoyODozMiB4bWFvIGtlcm5lbDogIFs8ZmZmZmZmZmY4MTAxMmQ3Mj5d IHN5c3RlbV9jYWxsX2Zhc3RwYXRoKzB4MTYvMHgxYgpTZXAgMTUgMDg6Mjg6MzIgeG1hbyBrZXJu ZWw6IENvZGU6IDg5IGZlIDQ5IDg5IGY1IGZmIDE0IDI1IGMwIGRiIDY2IDgxIDQ4IDg5IGMyIGZm IDE0IDI1IGQwIGRiIDY2IDgxIDQ4IGM3IGMzIDAwIDU2IDAxIDAwIDQ5IDg5IDU1IDAwIDQ5IDhi IDQ2IDA4IDhiIDQwIDE4IDQ5IDg5IGRjIDw0Yz4gMDMgMjQgYzUgYTAgMGQgNzAgODEgNGMgODkg ZTcgZTggODEgYTEgM2YgMDAgNDkgOGIgNDYgMDggOGIgClNlcCAxNSAwODoyODozMiB4bWFvIGtl cm5lbDogUklQICBbPGZmZmZmZmZmODEwNDQ3ODQ+XSB0YXNrX3JxX2xvY2srMHg0MC8weDgyClNl cCAxNSAwODoyODozMiB4bWFvIGtlcm5lbDogIFJTUCA8ZmZmZjg4MDE4Y2NlM2JiOD4KU2VwIDE1 IDA4OjI4OjMyIHhtYW8ga2VybmVsOiBDUjI6IDAwMDAwMDA1ZjNlZWVlMTAKU2VwIDE1IDA4OjI4 OjMyIHhtYW8ga2VybmVsOiAtLS1bIGVuZCB0cmFjZSAyMWJmZTNjMTkyMjFlNTgxIF0tLS0KU2Vw IDE1IDA4OjI4OjMyIHhtYW8ga2VybmVsOiBCVUc6IHVuYWJsZSB0byBoYW5kbGUga2VybmVsIHBh Z2luZyByZXF1ZXN0IGF0IDAwMDAwMDA1ZjNlZWVlMTAKU2VwIDE1IDA4OjI4OjMyIHhtYW8ga2Vy bmVsOiBJUDogWzxmZmZmZmZmZjgxMDQ0Nzg0Pl0gdGFza19ycV9sb2NrKzB4NDAvMHg4MgpTZXAg MTUgMDg6Mjg6MzIgeG1hbyBrZXJuZWw6IFBHRCAxYzZiMWEwNjcgUFVEIDAgClNlcCAxNSAwODoy ODozMiB4bWFvIGtlcm5lbDogT29wczogMDAwMCBbIzVdIFNNUCAKU2VwIDE1IDA4OjI4OjMyIHht YW8ga2VybmVsOiBsYXN0IHN5c2ZzIGZpbGU6IC9zeXMvYmxvY2svdGFwZGV2aC9zdGF0ClNlcCAx NSAwODoyODozMiB4bWFvIGtlcm5lbDogQ1BVIDAgClNlcCAxNSAwODoyODozMiB4bWFvIGtlcm5l bDogTW9kdWxlcyBsaW5rZWQgaW46IHh0X2lwcmFuZ2UgeHRfbWFjIGFycHRhYmxlX2ZpbHRlciBh cnBfdGFibGVzIHh0X3BoeXNkZXYgbmZfY29ubnRyYWNrX2lwdjQgbmZfZGVmcmFnX2lwdjQgeHRf c3RhdGUgbmZfY29ubnRyYWNrIGlwdGFibGVfZmlsdGVyIGlwX3RhYmxlcyBicmlkZ2UgYXV0b2Zz NCBpcG1pX2RldmludGYgaXBtaV9zaSBpcG1pX21zZ2hhbmRsZXIgbG9ja2Qgc3VucnBjIGJvbmRp bmcgaXB2NiA4MDIxcSBnYXJwIHN0cCBsbGMgeGVuZnMgZG1fbXVsdGlwYXRoIGZ1c2UgeGVuX25l dGJhY2sgeGVuX2Jsa2JhY2sgYmxrdGFwIGJsa2JhY2tfcGFnZW1hcCBsb29wIG5iZCB2aWRlbyBv dXRwdXQgc2JzIHNic2hjIHBhcnBvcnRfcGMgbHAgcGFycG9ydCBqb3lkZXYgYm54MiBzZXMgZW5j bG9zdXJlIHJhZGVvbiB0dG0gZHJtX2ttc19oZWxwZXIgZHJtIGkyY19hbGdvX2JpdCBpMmNfY29y ZSBzbmRfc2VxX2R1bW15IHNuZF9zZXFfb3NzIHNuZF9zZXFfbWlkaV9ldmVudCBzbmRfc2VxIHNu ZF9zZXFfZGV2aWNlIHNuZF9wY21fb3NzIHNuZF9taXhlcl9vc3Mgc2VyaW9fcmF3IGRjZGJhcyBz bmRfcGNtIGk1a19hbWIgaHdtb24gc25kX3RpbWVyIHNuZCBpVENPX3dkdCBpNTAwMF9lZGFjIGVk YWNfY29yZSBpVENPX3ZlbmRvcl9zdXBwb3J0IHNvdW5kY29yZSBzbmRfcGFnZV9hbGxvYyBwY3Nw a3Igc2hwY2hwIFtsYXN0IHVubG9hZGVkOiBmcmVxX3RhYmxlXQpTZXAgMTUgMDg6Mjg6MzIgeG1h byBrZXJuZWw6IFBpZDogNjI4MiwgY29tbToga2ZjIFRhaW50ZWQ6IEcgICAgICBEICAgIDIuNi4z Mi4zNnhlbiAjNyBQb3dlckVkZ2UgMjk1MApTZXAgMTUgMDg6Mjg6MzIgeG1hbyBrZXJuZWw6IFJJ UDogZTAzMDpbPGZmZmZmZmZmODEwNDQ3ODQ+XSAgWzxmZmZmZmZmZjgxMDQ0Nzg0Pl0gdGFza19y cV9sb2NrKzB4NDAvMHg4MgpTZXAgMTUgMDg6Mjg6MzIgeG1hbyBrZXJuZWw6IFJTUDogZTAyYjpm ZmZmODgwMTkxMjA1NzI4ICBFRkxBR1M6IDAwMDEwMDAyClNlcCAxNSAwODoyODozMiB4bWFvIGtl cm5lbDogUkFYOiAwMDAwMDAwMGNlNGZkYzBlIFJCWDogMDAwMDAwMDAwMDAxNTYwMCBSQ1g6IDAw MDAwMDAwMDAwMDAwMDAKU2VwIDE1IDA4OjI4OjMyIHhtYW8ga2VybmVsOiBSRFg6IDAwMDAwMDAw MDAwMDAyMDAgUlNJOiBmZmZmODgwMTkxMjA1Nzc4IFJESTogZmZmZjg4MDFjZDhiZGI0MApTZXAg MTUgMDg6Mjg6MzIgeG1hbyBrZXJuZWw6IFJCUDogZmZmZjg4MDE5MTIwNTc1OCBSMDg6IDAwMDAw MDAwMDAwMDAwMjAgUjA5OiBmZmZmODgwMWQyM2Q0NjQwClNlcCAxNSAwODoyODozMiB4bWFvIGtl cm5lbDogUjEwOiBmZmZmZmZmZjgxMDBmMTc1IFIxMTogZmZmZjg4MDFkYmQzOGU0MCBSMTI6IDAw MDAwMDAwMDAwMTU2MDAKU2VwIDE1IDA4OjI4OjMyIHhtYW8ga2VybmVsOiBSMTM6IGZmZmY4ODAx OTEyMDU3NzggUjE0OiBmZmZmODgwMWNkOGJkYjQwIFIxNTogMDAwMDAwMDAwMDAwMDAwMApTZXAg MTUgMDg6Mjg6MzIgeG1hbyBrZXJuZWw6IEZTOiAgMDAwMDdmNDBkODFhYjZlMCgwMDYzKSBHUzpm ZmZmODgwMDI4MDM4MDAwKDAwMDApIGtubEdTOjAwMDAwMDAwMDAwMDAwMDAKU2VwIDE1IDA4OjI4 OjMyIHhtYW8ga2VybmVsOiBDUzogIGUwMzMgRFM6IDAwMDAgRVM6IDAwMDAgQ1IwOiAwMDAwMDAw MDgwMDUwMDNiClNlcCAxNSAwODoyODozMiB4bWFvIGtlcm5lbDogQ1IyOiAwMDAwMDAwNWYzZWVl ZTEwIENSMzogMDAwMDAwMDFjNmEyZDAwMCBDUjQ6IDAwMDAwMDAwMDAwMDI2NjAKU2VwIDE1IDA4 OjI4OjMyIHhtYW8ga2VybmVsOiBEUjA6IDAwMDAwMDAwMDAwMDAwMDAgRFIxOiAwMDAwMDAwMDAw MDAwMDAwIERSMjogMDAwMDAwMDAwMDAwMDAwMApTZXAgMTUgMDg6Mjg6MzIgeG1hbyBrZXJuZWw6 IERSMzogMDAwMDAwMDAwMDAwMDAwMCBEUjY6IDAwMDAwMDAwZmZmZjBmZjAgRFI3OiAwMDAwMDAw MDAwMDAwNDAwClNlcCAxNSAwODoyODozMiB4bWFvIGtlcm5lbDogUHJvY2VzcyBrZmMgKHBpZDog NjI4MiwgdGhyZWFkaW5mbyBmZmZmODgwMTkxMjA0MDAwLCB0YXNrIGZmZmY4ODAxOTEyMDgwMDAp ClNlcCAxNSAwODoyODozMiB4bWFvIGtlcm5lbDogU3RhY2s6ClNlcCAxNSAwODoyODozMiB4bWFv IGtlcm5lbDogIGZmZmY4ODAxZGJkMzhlNDAgMDAwMDAwMDAwMDAwNTZkMCAwMDAwMDAwMDAwMDAw MDBmIGZmZmY4ODAxY2Q4YmRiNDAKU2VwIDE1IDA4OjI4OjMyIHhtYW8ga2VybmVsOiA8MD4gZmZm Zjg4MDE5MTIwNTgxOCAwMDAwMDAwMDAwMDAwMDBiIGZmZmY4ODAxOTEyMDU3YTggZmZmZmZmZmY4 MTA0YWU2YwpTZXAgMTUgMDg6Mjg6MzIgeG1hbyBrZXJuZWw6IDwwPiAwMDAwMDAwMDAwMDAwMDAw IDAwMDAwMDAwMDAwMDAyMDEgMDAwMDAwMDAwMDAwMDIwMCBmZmZmODgwMWQwZjEyYzAwClNlcCAx NSAwODoyODozMiB4bWFvIGtlcm5lbDogQ2FsbCBUcmFjZToKU2VwIDE1IDA4OjI4OjMyIHhtYW8g a2VybmVsOiAgWzxmZmZmZmZmZjgxMDRhZTZjPl0gdHJ5X3RvX3dha2VfdXArMHg0NC8weDMxZApT ZXAgMTUgMDg6Mjg6MzIgeG1hbyBrZXJuZWw6ICBbPGZmZmZmZmZmODEwNGIxODA+XSB3YWtlX3Vw X3Byb2Nlc3MrMHgxNS8weDE3ClNlcCAxNSAwODoyODozMiB4bWFvIGtlcm5lbDogIFs8ZmZmZmZm ZmY4MTEyY2ZhYj5dIGJkaV9xdWV1ZV93b3JrKzB4OWMvMHhhMQpTZXAgMTUgMDg6Mjg6MzIgeG1h byBrZXJuZWw6ICBbPGZmZmZmZmZmODExMmQxNjE+XSBiZGlfYWxsb2NfcXVldWVfd29yaysweDY4 LzB4ODQKU2VwIDE1IDA4OjI4OjMyIHhtYW8ga2VybmVsOiAgWzxmZmZmZmZmZjgxMTJkMWU4Pl0g d2FrZXVwX2ZsdXNoZXJfdGhyZWFkcysweDZiLzB4ODQKU2VwIDE1IDA4OjI4OjMyIHhtYW8ga2Vy bmVsOiAgWzxmZmZmZmZmZjgxMGRkYTgyPl0gZG9fdHJ5X3RvX2ZyZWVfcGFnZXMrMHgyMmMvMHgz MTAKU2VwIDE1IDA4OjI4OjMyIHhtYW8ga2VybmVsOiAgWzxmZmZmZmZmZjgxMGRkYzhhPl0gdHJ5 X3RvX2ZyZWVfcGFnZXMrMHg4OS8weDk4ClNlcCAxNSAwODoyODozMiB4bWFvIGtlcm5lbDogIFs8 ZmZmZmZmZmY4MTBkYzAyZj5dID8gaXNvbGF0ZV9wYWdlc19nbG9iYWwrMHgwLzB4MWY4ClNlcCAx NSAwODoyODozMiB4bWFvIGtlcm5lbDogIFs8ZmZmZmZmZmY4MTBkNzQ3MT5dIF9fYWxsb2NfcGFn ZXNfbm9kZW1hc2srMHgzNzEvMHg1YjAKU2VwIDE1IDA4OjI4OjMyIHhtYW8ga2VybmVsOiAgWzxm ZmZmZmZmZjgxMTAxZjYwPl0gYWxsb2NfcGFnZXNfbm9kZSsweDFiLzB4MWQKU2VwIDE1IDA4OjI4 OjMyIHhtYW8ga2VybmVsOiAgWzxmZmZmZmZmZjgxMTAxZjgzPl0gYWxsb2Nfc2xhYl9wYWdlKzB4 MjEvMHgyMwpTZXAgMTUgMDg6Mjg6MzIgeG1hbyBrZXJuZWw6ICBbPGZmZmZmZmZmODExMDI4MWY+ XSBfX3NsYWJfYWxsb2MrMHgxM2YvMHg0NzQKU2VwIDE1IDA4OjI4OjMyIHhtYW8ga2VybmVsOiAg WzxmZmZmZmZmZjgxMzlhYzY0Pl0gPyBhbGxvY19za2IrMHgxMy8weDE1ClNlcCAxNSAwODoyODoz MiB4bWFvIGtlcm5lbDogIFs8ZmZmZmZmZmY4MTEwM2RmNz5dIF9fa21hbGxvY190cmFja19jYWxs ZXIrMHhkNS8weDEyYwpTZXAgMTUgMDg6Mjg6MzIgeG1hbyBrZXJuZWw6ICBbPGZmZmZmZmZmODEw MGY4YmY+XSA/IHhlbl9yZXN0b3JlX2ZsX2RpcmVjdF9lbmQrMHgwLzB4MQpTZXAgMTUgMDg6Mjg6 MzIgeG1hbyBrZXJuZWw6ICBbPGZmZmZmZmZmODEzOWFjNjQ+XSA/IGFsbG9jX3NrYisweDEzLzB4 MTUKU2VwIDE1IDA4OjI4OjMyIHhtYW8ga2VybmVsOiAgWzxmZmZmZmZmZjgxMzlmOWY1Pl0gX19h bGxvY19za2IrMHg2Ny8weDE3MQpTZXAgMTUgMDg6Mjg6MzIgeG1hbyBrZXJuZWw6ICBbPGZmZmZm ZmZmODEzOWFjNjQ+XSBhbGxvY19za2IrMHgxMy8weDE1ClNlcCAxNSAwODoyODozMiB4bWFvIGtl cm5lbDogIFs8ZmZmZmZmZmY4MTM5YWQwND5dIHNvY2tfYWxsb2Nfc2VuZF9wc2tiKzB4OWUvMHgy Y2EKU2VwIDE1IDA4OjI4OjMyIHhtYW8ga2VybmVsOiAgWzxmZmZmZmZmZjgxMDBmOGJmPl0gPyB4 ZW5fcmVzdG9yZV9mbF9kaXJlY3RfZW5kKzB4MC8weDEKU2VwIDE1IDA4OjI4OjMyIHhtYW8ga2Vy bmVsOiAgWzxmZmZmZmZmZjgxNDNlOTYyPl0gPyBfc3Bpbl91bmxvY2tfaXJxcmVzdG9yZSsweDE1 LzB4MTcKU2VwIDE1IDA4OjI4OjMyIHhtYW8ga2VybmVsOiAgWzxmZmZmZmZmZjgxMDQ0MGFlPl0g PyBfX3dha2VfdXBfc3luY19rZXkrMHg1My8weDYwClNlcCAxNSAwODoyODozMiB4bWFvIGtlcm5l bDogIFs8ZmZmZmZmZmY4MTA3MjhkZD5dID8gcGlkX3ZucisweDIyLzB4MjQKU2VwIDE1IDA4OjI4 OjMyIHhtYW8ga2VybmVsOiAgWzxmZmZmZmZmZjgxMzlhZjQ1Pl0gc29ja19hbGxvY19zZW5kX3Nr YisweDE1LzB4MTcKU2VwIDE1IDA4OjI4OjMyIHhtYW8ga2VybmVsOiAgWzxmZmZmZmZmZjgxNDE2 ZWQ1Pl0gdW5peF9zdHJlYW1fc2VuZG1zZysweDExYi8weDJiYgpTZXAgMTUgMDg6Mjg6MzIgeG1h byBrZXJuZWw6ICBbPGZmZmZmZmZmODEzOTZkZjY+XSBfX3NvY2tfc2VuZG1zZysweDVlLzB4NjcK U2VwIDE1IDA4OjI4OjMyIHhtYW8ga2VybmVsOiAgWzxmZmZmZmZmZjgxMzk3NmRhPl0gc29ja19z ZW5kbXNnKzB4Y2MvMHhlNQpTZXAgMTUgMDg6Mjg6MzIgeG1hbyBrZXJuZWw6ICBbPGZmZmZmZmZm ODEwNzU4OTY+XSA/IGF1dG9yZW1vdmVfd2FrZV9mdW5jdGlvbisweDAvMHgzZApTZXAgMTUgMDg6 Mjg6MzIgeG1hbyBrZXJuZWw6ICBbPGZmZmZmZmZmODE0M2VmN2E+XSA/IGVycm9yX2V4aXQrMHgy YS8weDYwClNlcCAxNSAwODoyODozMiB4bWFvIGtlcm5lbDogIFs8ZmZmZmZmZmY4MTAxMzcxZD5d ID8gcmV0aW50X3Jlc3RvcmVfYXJncysweDUvMHg2ClNlcCAxNSAwODoyODozMiB4bWFvIGtlcm5l bDogIFs8ZmZmZmZmZmY4MTAwY2UzNj5dID8gZ2V0X3BoeXNfdG9fbWFjaGluZSsweDMyLzB4NGUK U2VwIDE1IDA4OjI4OjMyIHhtYW8ga2VybmVsOiAgWzxmZmZmZmZmZjgxMDBmMTc1Pl0gPyB4ZW5f Zm9yY2VfZXZ0Y2huX2NhbGxiYWNrKzB4ZC8weGYKU2VwIDE1IDA4OjI4OjMyIHhtYW8ga2VybmVs OiAgWzxmZmZmZmZmZjgxMTBmNTc2Pl0gPyBmZ2V0X2xpZ2h0KzB4NTgvMHg3MgpTZXAgMTUgMDg6 Mjg6MzIgeG1hbyBrZXJuZWw6ICBbPGZmZmZmZmZmODEzOTcwNjE+XSA/IHNvY2tmZF9sb29rdXBf bGlnaHQrMHgyMC8weDU4ClNlcCAxNSAwODoyODozMiB4bWFvIGtlcm5lbDogIFs8ZmZmZmZmZmY4 MTM5ODJkNj5dIHN5c19zZW5kdG8rMHhmZi8weDEyNApTZXAgMTUgMDg6Mjg6MzIgeG1hbyBrZXJu ZWw6ICBbPGZmZmZmZmZmODEwMmZkZmM+XSA/IHB2Y2xvY2tfY2xvY2tzb3VyY2VfcmVhZCsweDQy LzB4OTkKU2VwIDE1IDA4OjI4OjMyIHhtYW8ga2VybmVsOiAgWzxmZmZmZmZmZjgxMDBmNmYyPl0g PyB4ZW5fY2xvY2tzb3VyY2VfcmVhZCsweDIxLzB4MjMKU2VwIDE1IDA4OjI4OjMyIHhtYW8ga2Vy bmVsOiAgWzxmZmZmZmZmZjgxMDBmODU5Pl0gPyB4ZW5fY2xvY2tzb3VyY2VfZ2V0X2N5Y2xlcysw eDkvMHgxMApTZXAgMTUgMDg6Mjg6MzIgeG1hbyBrZXJuZWw6ICBbPGZmZmZmZmZmODEwN2QzZGM+ XSA/IHRpbWVrZWVwaW5nX2dldF9ucysweDFiLzB4M2QKU2VwIDE1IDA4OjI4OjMyIHhtYW8ga2Vy bmVsOiAgWzxmZmZmZmZmZjgxMDEyZDcyPl0gc3lzdGVtX2NhbGxfZmFzdHBhdGgrMHgxNi8weDFi ClNlcCAxNSAwODoyODozMiB4bWFvIGtlcm5lbDogQ29kZTogODkgZmUgNDkgODkgZjUgZmYgMTQg MjUgYzAgZGIgNjYgODEgNDggODkgYzIgZmYgMTQgMjUgZDAgZGIgNjYgODEgNDggYzcgYzMgMDAg NTYgMDEgMDAgNDkgODkgNTUgMDAgNDkgOGIgNDYgMDggOGIgNDAgMTggNDkgODkgZGMgPDRjPiAw MyAyNCBjNSBhMCAwZCA3MCA4MSA0YyA4OSBlNyBlOCA4MSBhMSAzZiAwMCA0OSA4YiA0NiAwOCA4 YiAKU2VwIDE1IDA4OjI4OjMyIHhtYW8ga2VybmVsOiBSSVAgIFs8ZmZmZmZmZmY4MTA0NDc4ND5d IHRhc2tfcnFfbG9jaysweDQwLzB4ODIKU2VwIDE1IDA4OjI4OjMyIHhtYW8ga2VybmVsOiAgUlNQ IDxmZmZmODgwMTkxMjA1NzI4PgpTZXAgMTUgMDg6Mjg6MzIgeG1hbyBrZXJuZWw6IENSMjogMDAw MDAwMDVmM2VlZWUxMApTZXAgMTUgMDg6Mjg6MzIgeG1hbyBrZXJuZWw6IC0tLVsgZW5kIHRyYWNl IDIxYmZlM2MxOTIyMWU1ODIgXS0tLQpTZXAgMTUgMDg6Mjg6MzIgeG1hbyBrZXJuZWw6IEJVRzog dW5hYmxlIHRvIGhhbmRsZSBrZXJuZWwgcGFnaW5nIHJlcXVlc3QgYXQgMDAwMDAwMDVmM2VlZWUx MApTZXAgMTUgMDg6Mjg6MzIgeG1hbyBrZXJuZWw6IElQOiBbPGZmZmZmZmZmODEwNDQ3ODQ+XSB0 YXNrX3JxX2xvY2srMHg0MC8weDgyClNlcCAxNSAwODoyODozMiB4bWFvIGtlcm5lbDogUEdEIDFj NzM5NDA2NyBQVUQgMCAKU2VwIDE1IDA4OjI4OjMyIHhtYW8ga2VybmVsOiBPb3BzOiAwMDAwIFsj Nl0gU01QIApTZXAgMTUgMDg6Mjg6MzIgeG1hbyBrZXJuZWw6IGxhc3Qgc3lzZnMgZmlsZTogL3N5 cy9ibG9jay90YXBkZXZoL3N0YXQKU2VwIDE1IDA4OjI4OjMyIHhtYW8ga2VybmVsOiBDUFUgMiAK U2VwIDE1IDA4OjI4OjMyIHhtYW8ga2VybmVsOiBNb2R1bGVzIGxpbmtlZCBpbjogeHRfaXByYW5n ZSB4dF9tYWMgYXJwdGFibGVfZmlsdGVyIGFycF90YWJsZXMgeHRfcGh5c2RldiBuZl9jb25udHJh Y2tfaXB2NCBuZl9kZWZyYWdfaXB2NCB4dF9zdGF0ZSBuZl9jb25udHJhY2sgaXB0YWJsZV9maWx0 ZXIgaXBfdGFibGVzIGJyaWRnZSBhdXRvZnM0IGlwbWlfZGV2aW50ZiBpcG1pX3NpIGlwbWlfbXNn aGFuZGxlciBsb2NrZCBzdW5ycGMgYm9uZGluZyBpcHY2IDgwMjFxIGdhcnAgc3RwIGxsYyB4ZW5m cyBkbV9tdWx0aXBhdGggZnVzZSB4ZW5fbmV0YmFjayB4ZW5fYmxrYmFjayBibGt0YXAgYmxrYmFj a19wYWdlbWFwIGxvb3AgbmJkIHZpZGVvIG91dHB1dCBzYnMgc2JzaGMgcGFycG9ydF9wYyBscCBw YXJwb3J0IGpveWRldiBibngyIHNlcyBlbmNsb3N1cmUgcmFkZW9uIHR0bSBkcm1fa21zX2hlbHBl ciBkcm0gaTJjX2FsZ29fYml0IGkyY19jb3JlIHNuZF9zZXFfZHVtbXkgc25kX3NlcV9vc3Mgc25k X3NlcV9taWRpX2V2ZW50IHNuZF9zZXEgc25kX3NlcV9kZXZpY2Ugc25kX3BjbV9vc3Mgc25kX21p eGVyX29zcyBzZXJpb19yYXcgZGNkYmFzIHNuZF9wY20gaTVrX2FtYiBod21vbiBzbmRfdGltZXIg c25kIGlUQ09fd2R0IGk1MDAwX2VkYWMgZWRhY19jb3JlIGlUQ09fdmVuZG9yX3N1cHBvcnQgc291 bmRjb3JlIHNuZF9wYWdlX2FsbG9jIHBjc3BrciBzaHBjaHAgW2xhc3QgdW5sb2FkZWQ6IGZyZXFf dGFibGVdClNlcCAxNSAwODoyODozMiB4bWFvIGtlcm5lbDogUGlkOiA0OTkxLCBjb21tOiB4ZW5z dG9yZWQgVGFpbnRlZDogRyAgICAgIEQgICAgMi42LjMyLjM2eGVuICM3IFBvd2VyRWRnZSAyOTUw ClNlcCAxNSAwODoyODozMiB4bWFvIGtlcm5lbDogUklQOiBlMDMwOls8ZmZmZmZmZmY4MTA0NDc4 ND5dICBbPGZmZmZmZmZmODEwNDQ3ODQ+XSB0YXNrX3JxX2xvY2srMHg0MC8weDgyClNlcCAxNSAw ODoyODozMiB4bWFvIGtlcm5lbDogUlNQOiBlMDJiOmZmZmY4ODAxYzY4ZmQ2OTggIEVGTEFHUzog MDAwMTAwMDIKU2VwIDE1IDA4OjI4OjMyIHhtYW8ga2VybmVsOiBSQVg6IDAwMDAwMDAwY2U0ZmRj MGUgUkJYOiAwMDAwMDAwMDAwMDE1NjAwIFJDWDogMDAwMDAwMDAwMDAwMDAwMApTZXAgMTUgMDg6 Mjg6MzIgeG1hbyBrZXJuZWw6IFJEWDogMDAwMDAwMDAwMDAwMDIwMiBSU0k6IGZmZmY4ODAxYzY4 ZmQ2ZTggUkRJOiBmZmZmODgwMWNkOGJkYjQwClNlcCAxNSAwODoyODozMiB4bWFvIGtlcm5lbDog UkJQOiBmZmZmODgwMWM2OGZkNmM4IFIwODogMDAwMDAwMDAwMDAwMDAyMCBSMDk6IGZmZmY4ODAx ZGJjZTViNDAKU2VwIDE1IDA4OjI4OjMyIHhtYW8ga2VybmVsOiBSMTA6IDAwMDAwMDAwMDAwMDAw MDAgUjExOiBmZmZmODgwMWM2OGZkNjU4IFIxMjogMDAwMDAwMDAwMDAxNTYwMApTZXAgMTUgMDg6 Mjg6MzIgeG1hbyBrZXJuZWw6IFIxMzogZmZmZjg4MDFjNjhmZDZlOCBSMTQ6IGZmZmY4ODAxY2Q4 YmRiNDAgUjE1OiAwMDAwMDAwMDAwMDAwMDAwClNlcCAxNSAwODoyODozMiB4bWFvIGtlcm5lbDog RlM6ICAwMDAwN2YwZDQyZmE1NmUwKDAwMDApIEdTOmZmZmY4ODAwMjgwNzIwMDAoMDAwMCkga25s R1M6MDAwMDAwMDAwMDAwMDAwMApTZXAgMTUgMDg6Mjg6MzIgeG1hbyBrZXJuZWw6IENTOiAgZTAz MyBEUzogMDAwMCBFUzogMDAwMCBDUjA6IDAwMDAwMDAwODAwNTAwM2IKU2VwIDE1IDA4OjI4OjMy IHhtYW8ga2VybmVsOiBDUjI6IDAwMDAwMDA1ZjNlZWVlMTAgQ1IzOiAwMDAwMDAwMWM3M2NmMDAw IENSNDogMDAwMDAwMDAwMDAwMjY2MApTZXAgMTUgMDg6Mjg6MzIgeG1hbyBrZXJuZWw6IERSMDog MDAwMDAwMDAwMDAwMDAwMCBEUjE6IDAwMDAwMDAwMDAwMDAwMDAgRFIyOiAwMDAwMDAwMDAwMDAw MDAwClNlcCAxNSAwODoyODozMiB4bWFvIGtlcm5lbDogRFIzOiAwMDAwMDAwMDAwMDAwMDAwIERS NjogMDAwMDAwMDBmZmZmMGZmMCBEUjc6IDAwMDAwMDAwMDAwMDA0MDAKU2VwIDE1IDA4OjI4OjMy IHhtYW8ga2VybmVsOiBQcm9jZXNzIHhlbnN0b3JlZCAocGlkOiA0OTkxLCB0aHJlYWRpbmZvIGZm ZmY4ODAxYzY4ZmMwMDAsIHRhc2sgZmZmZjg4MDFjNjg0MDAwMCkKU2VwIDE1IDA4OjI4OjMyIHht YW8ga2VybmVsOiBTdGFjazoKU2VwIDE1IDA4OjI4OjMyIHhtYW8ga2VybmVsOiAgZmZmZjg4MDFj NjhmZDY1OCAwMDAwMDAwMDAwMDAwMGQwIDAwMDAwMDAwMDAwMDAwMGYgZmZmZjg4MDFjZDhiZGI0 MApTZXAgMTUgMDg6Mjg6MzIgeG1hbyBrZXJuZWw6IDwwPiBmZmZmODgwMWM2OGZkNzg4IDAwMDAw MDAwMDAwMDAwMGIgZmZmZjg4MDFjNjhmZDcxOCBmZmZmZmZmZjgxMDRhZTZjClNlcCAxNSAwODoy ODozMiB4bWFvIGtlcm5lbDogPDA+IDAwMDAwMDAyMDAwMDAwMDAgMDAwMDAwMDAwMDAwMDIwMSAw MDAwMDAwMDAwMDAwMjAyIGZmZmY4ODAxZDBmMTJjMDAKU2VwIDE1IDA4OjI4OjMyIHhtYW8ga2Vy bmVsOiBDYWxsIFRyYWNlOgpTZXAgMTUgMDg6Mjg6MzIgeG1hbyBrZXJuZWw6ICBbPGZmZmZmZmZm ODEwNGFlNmM+XSB0cnlfdG9fd2FrZV91cCsweDQ0LzB4MzFkClNlcCAxNSAwODoyODozMiB4bWFv IGtlcm5lbDogIFs8ZmZmZmZmZmY4MTA0YjE4MD5dIHdha2VfdXBfcHJvY2VzcysweDE1LzB4MTcK U2VwIDE1IDA4OjI4OjMyIHhtYW8ga2VybmVsOiAgWzxmZmZmZmZmZjgxMTJjZmFiPl0gYmRpX3F1 ZXVlX3dvcmsrMHg5Yy8weGExClNlcCAxNSAwODoyODozMiB4bWFvIGtlcm5lbDogIFs8ZmZmZmZm ZmY4MTEyZDE2MT5dIGJkaV9hbGxvY19xdWV1ZV93b3JrKzB4NjgvMHg4NApTZXAgMTUgMDg6Mjg6 MzIgeG1hbyBrZXJuZWw6ICBbPGZmZmZmZmZmODExMmQxZTg+XSB3YWtldXBfZmx1c2hlcl90aHJl YWRzKzB4NmIvMHg4NApTZXAgMTUgMDg6Mjg6MzIgeG1hbyBrZXJuZWw6ICBbPGZmZmZmZmZmODEw ZGRhODI+XSBkb190cnlfdG9fZnJlZV9wYWdlcysweDIyYy8weDMxMApTZXAgMTUgMDg6Mjg6MzIg eG1hbyBrZXJuZWw6ICBbPGZmZmZmZmZmODEwMGY4ZDI+XSA/IGNoZWNrX2V2ZW50cysweDEyLzB4 MjAKU2VwIDE1IDA4OjI4OjMyIHhtYW8ga2VybmVsOiAgWzxmZmZmZmZmZjgxMGRkYzhhPl0gdHJ5 X3RvX2ZyZWVfcGFnZXMrMHg4OS8weDk4ClNlcCAxNSAwODoyODozMiB4bWFvIGtlcm5lbDogIFs8 ZmZmZmZmZmY4MTBkYzAyZj5dID8gaXNvbGF0ZV9wYWdlc19nbG9iYWwrMHgwLzB4MWY4ClNlcCAx NSAwODoyODozMiB4bWFvIGtlcm5lbDogIFs8ZmZmZmZmZmY4MTBkNzQ3MT5dIF9fYWxsb2NfcGFn ZXNfbm9kZW1hc2srMHgzNzEvMHg1YjAKU2VwIDE1IDA4OjI4OjMyIHhtYW8ga2VybmVsOiAgWzxm ZmZmZmZmZjgxMGQ3NmNjPl0gX19nZXRfZnJlZV9wYWdlcysweDFjLzB4NjQKU2VwIDE1IDA4OjI4 OjMyIHhtYW8ga2VybmVsOiAgWzxmZmZmZmZmZjgxMTFmNTRhPl0gX19wb2xsd2FpdCsweDYwLzB4 ZGMKU2VwIDE1IDA4OjI4OjMyIHhtYW8ga2VybmVsOiAgWzxmZmZmZmZmZjgxNDE1NmExPl0gc29j a19wb2xsX3dhaXQrMHgxOC8weDFkClNlcCAxNSAwODoyODozMiB4bWFvIGtlcm5lbDogIFs8ZmZm ZmZmZmY4MTQxN2U1Mj5dIHVuaXhfcG9sbCsweDFiLzB4OWMKU2VwIDE1IDA4OjI4OjMyIHhtYW8g a2VybmVsOiAgWzxmZmZmZmZmZjgxMzk1ZGIzPl0gc29ja19wb2xsKzB4MWQvMHgxZgpTZXAgMTUg MDg6Mjg6MzIgeG1hbyBrZXJuZWw6ICBbPGZmZmZmZmZmODExMWVmYzk+XSBkb19zZWxlY3QrMHgz MDQvMHg1NGYKU2VwIDE1IDA4OjI4OjMyIHhtYW8ga2VybmVsOiAgWzxmZmZmZmZmZjgxMTFmNGVh Pl0gPyBfX3BvbGx3YWl0KzB4MC8weGRjClNlcCAxNSAwODoyODozMiB4bWFvIGtlcm5lbDogIFs8 ZmZmZmZmZmY4MTExZjVjNj5dID8gcG9sbHdha2UrMHgwLzB4NjAKU2VwIDE1IDA4OjI4OjMyIHht YW8gbGFzdCBtZXNzYWdlIHJlcGVhdGVkIDggdGltZXMKU2VwIDE1IDA4OjI4OjMyIHhtYW8ga2Vy bmVsOiAgWzxmZmZmZmZmZjgxMTFmMzhiPl0gY29yZV9zeXNfc2VsZWN0KzB4MTc3LzB4MjEyClNl cCAxNSAwODoyODozMiB4bWFvIGtlcm5lbDogIFs8ZmZmZmZmZmY4MTEwZDc1Zj5dID8gZG9fc3lu Y193cml0ZSsweGU3LzB4MTJiClNlcCAxNSAwODoyODozMiB4bWFvIGtlcm5lbDogIFs8ZmZmZmZm ZmY4MTAwZjhkMj5dID8gY2hlY2tfZXZlbnRzKzB4MTIvMHgyMApTZXAgMTUgMDg6Mjg6MzIgeG1h byBrZXJuZWw6ICBbPGZmZmZmZmZmODExMDIwZTU+XSA/IGttZW1fY2FjaGVfZnJlZSsweDg4LzB4 YmIKU2VwIDE1IDA4OjI4OjMyIHhtYW8ga2VybmVsOiAgWzxmZmZmZmZmZjgxMDc1ODk2Pl0gPyBh dXRvcmVtb3ZlX3dha2VfZnVuY3Rpb24rMHgwLzB4M2QKU2VwIDE1IDA4OjI4OjMyIHhtYW8ga2Vy bmVsOiAgWzxmZmZmZmZmZjgxMTFmNGMyPl0gc3lzX3NlbGVjdCsweDljLzB4YzQKU2VwIDE1IDA4 OjI4OjMyIHhtYW8ga2VybmVsOiAgWzxmZmZmZmZmZjgxMTBlYzEzPl0gPyBzeXNfd3JpdGUrMHg2 Mi8weDcyClNlcCAxNSAwODoyODozMiB4bWFvIGtlcm5lbDogIFs8ZmZmZmZmZmY4MTAxMmQ3Mj5d IHN5c3RlbV9jYWxsX2Zhc3RwYXRoKzB4MTYvMHgxYgpTZXAgMTUgMDg6Mjg6MzIgeG1hbyBrZXJu ZWw6IENvZGU6IDg5IGZlIDQ5IDg5IGY1IGZmIDE0IDI1IGMwIGRiIDY2IDgxIDQ4IDg5IGMyIGZm IDE0IDI1IGQwIGRiIDY2IDgxIDQ4IGM3IGMzIDAwIDU2IDAxIDAwIDQ5IDg5IDU1IDAwIDQ5IDhi IDQ2IDA4IDhiIDQwIDE4IDQ5IDg5IGRjIDw0Yz4gMDMgMjQgYzUgYTAgMGQgNzAgODEgNGMgODkg ZTcgZTggODEgYTEgM2YgMDAgNDkgOGIgNDYgMDggOGIgClNlcCAxNSAwODoyODozMiB4bWFvIGtl cm5lbDogUklQICBbPGZmZmZmZmZmODEwNDQ3ODQ+XSB0YXNrX3JxX2xvY2srMHg0MC8weDgyClNl cCAxNSAwODoyODozMiB4bWFvIGtlcm5lbDogIFJTUCA8ZmZmZjg4MDFjNjhmZDY5OD4KU2VwIDE1 IDA4OjI4OjMyIHhtYW8ga2VybmVsOiBDUjI6IDAwMDAwMDA1ZjNlZWVlMTAKU2VwIDE1IDA4OjI4 OjMyIHhtYW8ga2VybmVsOiAtLS1bIGVuZCB0cmFjZSAyMWJmZTNjMTkyMjFlNTgzIF0tLS0K --_8ed9fe05-1fc2-4309-8777-22b0c1c100d9_ Content-Type: application/octet-stream Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="messages.15" U2VwIDEzIDE2OjE2OjM1IHhtYW8ga2VybmVsOiBvbGRfZGVwdGggMSBkZXB0aCAxIG9sZF9wYXRo IGZmZmY4ODAxNmNkM2RhODAgcGF0aCBmZmZmODgwMTZjZDNkZTQwIG5leHRfaGFzX2ZyZWUgMApT ZXAgMTMgMTY6MTY6MzUgeG1hbyBrZXJuZWw6IGluc2VydCAxNDQxMjoyMjIzMzI2MTQ6WzFdNTgg YmVmb3JlOiBuZWFyZXN0IDB4ZmZmZjg4MDEzZWRmNjAwYywgbW92ZSA0MDY4IGZyb20gMHhmZmZm ODgwMTNlZGY2MDE4IHRvIDB4ZmZmZjg4MDEzZWRmNjAyNApTZXAgMTMgMTY6MTY6MzUgeG1hbyBr ZXJuZWw6IERpc3BsYXlpbmcgbGVhZiBleHRlbnRzIGZvciBpbm9kZSAzMDY4NTA2MApTZXAgMTMg MTY6MTY6MzUgeG1hbyBrZXJuZWw6IDA6WzBdNjE6MjM2NzAwMTMxIDYxOlswXTYzOjIzNjk2MzAw OSAxMjQ6WzBdNjQ6MjM3MDEwNDY4IDE4ODpbMF02ODo1NzM2MDY3MCAyNTY6WzBdNjQ6MTk3Nzkx ODgwIDMyMDpbMF02NDoxOTc3OTIzOTIgMzg0OlswXTY0OjE5Nzg3MzE3MiA0NDg6WzBdNjQ6MTk4 NjUyODY0IDUxMjpbMF02MToxOTg3OTkyOTkgNTczOlswXTU5OjE5ODc3NjUxNyA2MzI6WzBdNTg6 MTk4NzcxOTEwIDY5MDpbMF01ODoxOTg3NzQyMTQgNzQ4OlswXTMwOjE5ODc5NjIzMCA3Nzg6WzBd NTI6MjE4NTQ5MTYwIDgzMDpbMF00NjoyNDMzNjg0MDIgODc2OlswXTQ2OjI0MzUwMTYyNiA5MjI6 WzBdNDY6MjQzNTA2MjMxIDk2ODpbMF01Njo5NDA0MzUyIDEwMjQ6WzBdMzY6MTQxODE5NDAgMTA2 MDpbMF0xOjE0MTgxOTc2IDEwNjE6WzBdMTQ6MTQxODE5NzcgMTA3NTpbMF00NDoxOTAwNjY5MyAx MTE5OlswXTYwOjE4NjYyNjE5MyAxMTc5OlswXTM3OjE4Njg0ODQ1MCAxMjE2OlswXTYzOjE5ODU4 NzE2NyAxMjc5OlswXTYwOjE5ODYzMzQwOSAxMzM5OlswXTI0OjI0MjQ4MDc1MyAxMzYzOlswXTI0 OjI0MjQ4MDkyMSAxMzg3OlswXTIzOjI0MjQ1NDY2NiAxNDEwOlswXTIzOjI0MjQ1NTMyMiAxNDMz OlswXTIzOjI0MjQ3NzgwMSAxNDU2OlswXTIzOjI0MjQ4MDY1OCAxNDc5OlswXTIzOjI0MjQ4MDg1 MCAxNTAyOlswXTIyOjI0MjQ1MzUzMSAxNTI0OlswXTIyOjI0MjQ1NDU1NSAxNTQ2OlswXTIyOjI0 MjQ1NDY5OSAxNTY4OlswXTIyOjI0MjQ4MTAxOSAxNTkwOlswXTIwOjI0MjQ1NTE4MSAxNjEwOlsw XTI0OjI0MjUyMTEyOCAxNjM0OlswXTMyOjI0MjY2NTI0OCAxNjY2OlswXTQ1OjI0Mjc2NzI3MiAx NzExOlswXTQ2OjI0Mjc5MzQyNiAxNzU3OlswXTQ1OjI0Mjc4NjAyMiAxODAyOlswXTE0OjI0MzA5 MzQ1OSAxODE2OlswXTI2OjM4NTA0NDIyIDE4NDI6WzBdNDozODU5MjI5MCAxODQ2OlswXTgzOjQ2 MjA0ODQ1IDE5Mjk6WzBdODM6NDYyMjEyMjkgMjAxMjpbMF0zNjo0NjIwNDc2MSAyClNlcCAxMyAx NjoxNjozNSB4bWFvIGtlcm5lbDogNDg6WzBdMzk6NDYyNjAxNDEgMjA4NzpbMF0xOjQ2MjYwMTgw IDIwODg6WzBdNDM6NDYyNjAxODEgMjEzMTpbMF0zNzo0NjU5MTkxNyAyMTY4OlswXTc1OjE2Nzgz MTQ3NyAyMjQzOlswXTExOjE2Nzg1NDc3MyAyMjU0OlswXTU5OjE5NDAyOTc2NSAyMzEzOlswXTUz OjE5NDE2MjkxNyAyMzY2OlswXTcyOjg4ODU1MjggMjQzODpbMF03ODo5NDU2MDQ2IDI1MTY6WzBd Nzk6MTAwMzAyNTcgMjU5NTpbMF03OToxMDAzNTEyMSAyNjc0OlswXTc5OjEwMDM5MjE3IDI3NTM6 WzBdNzk6MTAxNTE4NTcgMjgzMjpbMF0xMToxMDEzNTQ5NyAyODQzOlswXTQxOjExODYyMDM0OCAy ODg0OlswXTE2OjI0MjU5NDI4OCAyOTAwOlswXTI0OjI0MjY5MjI5NiAyOTI0OlswXTM0OjI0MzE2 MzEwMiAyOTU4OlswXTM0OjI0MzE2OTI0NiAyOTkyOlswXTMzOjI0MzE0NTA2MyAzMDI1OlswXTMz OjI0MzE0Njk2NiAzMDU4OlswXTMzOjI0MzE1NzA3MyAzMDkxOlswXTIzOjI0MzgyMDk0MSAzMTE0 OlswXTEwOjI0MzgyMDk2NCAzMTI0OlswXTQ2OjEyNjkzMCAzMTcwOlswXTE5OjEzNjUxODYgMzE4 OTpbMF02OjEzNjUyMDUgMzE5NTpbMF03OToxMzc1NDA3OTQgMzI3NDpbMF0xODoxMzc2OTUwMzIg MzI5MjpbMF01OToxNjM2ODk5MjUgMzM1MTpbMF0yOToxNjM3MjczODQgMzM4MDpbMF0yOjE2Mzcy NzQxMyAzMzgyOlswXTQzOjE4Mjg5MDQ1MyAzNDI1OlswXTQyOjE4Mjg5NDU1MCAzNDY3OlswXTQy OjE4MjkwMTcxOCAzNTA5OlswXTQxOjE4Mjg5NjcxMSAzNTUwOlswXTQxOjE4MjkwMzE3NCAzNTkx OlswXTQxOjE4Mjk2NTcyMSAzNjMyOlswXTQ6MTgzMDA3NTEyIDM2MzY6WzBdNjA6MjAxOTgzODg1 IDM2OTY6WzBdNjA6MjAyNDQ0MjI4IDM3NTY6WzBdNjA6MjAyNTc0MDIwIDM4MTY6WzBdNjA6MjAy NjAyNDM2IDM4NzY6WzBdNjA6MjAyNzIwNTU2IDM5MzY6WzBdMjI6MjAyNzgwNjcyIDM5NTg6WzBd NDQ6MjEyMzE0MDY4IDQwMDI6WzBdNDE6MjEyMzE2NzM3IDQwNDM6WzBdNTM6MjEKU2VwIDEzIDE2 OjE2OjM1IHhtYW8ga2VybmVsOiA0MTYgNDA5NjpbMF00NToyMTc0ODUyNDggNDE0MTpbMF0xOjIx NzQ4NTI5MyA0MTQyOlswXTE4OjIxNzQ4NTI5NCA0MTYwOlswXTY0OjIxNzUxMDg2NCA0MjI0Olsw XTIwOjIxNzUxMTUyMiA0MjQ0OlswXTcwOjEwNzAxNzE0NiA0MzE0OlswXTI3OjEwNzAyMDIyMCA0 MzQxOlswXTQyOjExMTA4NDA4NCA0MzgzOlswXTcwOjExMTA5ODU1NCA0NDUzOlswXTcwOjExMTE4 NTg1NyA0NTIzOlswXTcwOjExMTY1MzU2MiA0NTkzOlswXTI6MTExNjQ5MDIyIDQ1OTU6WzBdNjg6 MTExNjY5MTgwIDQ2NjM6WzBdMjoxMTE5MTg1MjQgNDY2NTpbMF03MToxMTkyMzE0MTcgNDczNjpb MF03MDoxMTk0MTg5MDQgNDgwNjpbMF03MDoxMTk0MjIyMTEgNDg3NjpbMF01NDoxMTk3NzcyMDkg NDkzMDpbMF04OjEyMzEyNTY5MCA0OTM4OlswXTM5OjIxNjk0MTUyOSA0OTc3OlswXTM5OjIxNjk1 MTc2OSA1MDE2OlswXTQ4OjIxNzcyMTIxNiA1MDY0OlswXTQ4OjIxNzcyMTI4OCA1MTEyOlswXTQ5 OjIxNzc1OTY5NSA1MTYxOlswXTc6MjE3NzQ1NTU1IDUxNjg6WzBdMToyMTc3NDU1NjIgNTE2OTpb MF00MDoyMTc3NDU1NjMgNTIwOTpbMF01OToyMTc4OTA3NTcgNTI2ODpbMF0xNDoyMTc4ODY4NjAg NTI4MjpbMF01NDoyMTkwOTIwOTggNTMzNjpbMF00MzoyMTkxMDExMzAgNTM3OTpbMF00MjoyMjEx MzY4NTQgNTQyMTpbMF02ODoyMjE2MzAzOTYgNTQ4OTpbMF03MDoyMjIwODcwOTggNTU1OTpbMF02 ODoyMjIwNzUwNjggNTYyNzpbMF01MzoyMjIxMTE2NzYgNTY4MDpbMF00MToyMjU0NzE1OTAgNTcy MTpbMF0yOjIyNTQ4MjQ1NiA1NzIzOlswXTM4OjIyNjAwNDk1NCA1NzYxOlswXTM5OjIyNjExNDY4 MyA1ODAwOlswXTU4OjIyNjI4NzYyNCA1ODU4OlswXTU5OjIyNjYwNDc0MSA1OTE3OlswXTQ4OjIy Njk4MTgzMCA1OTY1OlswXTU2OjIyNzU5NTM0OSA2MDIxOlswXTUzOjIyNzc4MDU1NSA2MDc0Olsw XTUzOjIyODAxMjgzNiA2MTI3OlswXTE3OjIyODAxMzkwNiA2MTQ0OlswXTUxOgpTZXAgMTMgMTY6 MTY6MzUgeG1hbyBrZXJuZWw6IDMwNjIwIDYxOTU6WzBdMjoyMjgwMzA2NzEgNjE5NzpbMF01Mzoy MjgxMTM4MDAgNjI1MDpbMF01NDoyMjgzNjQ1NTUgNjMwNDpbMF0yNzoyMjg1Mzg1NjAgNjMzMTpb MF03OToxMzk5NDY3MyA2NDEwOlswXTc5OjE0MzMwMDMzIDY0ODk6WzBdNzk6MTQ1MjYzODUgNjU2 ODpbMF03OToxNDYyMTYxNyA2NjQ3OlswXTI2OjE0ODI3NDQyIDY2NzM6WzBdMzM6MTk0NDYxNjQ2 IDY3MDY6WzBdNTU6MjAyNzcwMzczIDY3NjE6WzBdNDk6MjE2NzIzNzUzIDY4MTA6WzBdNDc6MjE2 NzgzNjYyIDY4NTc6WzBdMToyMTY3ODM3MDkgNjg1ODpbMF00ODoyMTY3ODM4MjkgNjkwNjpbMF00 ODoyMTY3ODc3NTcgNjk1NDpbMF0zODoyMTY3ODc5MTkgNjk5MjpbMF0zMDoyMjE2NDkzODkgNzAy MjpbMF0zMToyMzcxNDY0ODYgNzA1MzpbMF0zMDoyMzcxNTA2OTAgNzA4MzpbMF0yOToyMzcxNjU4 NDYgNzExMjpbMF0zNjoyMzgxMDcyODcgNzE0ODpbMF0zMzoyMzgwOTQzNjkgNzE4MTpbMF00MToy MzgxMjkwOTQgNzIyMjpbMF02OjIzODEyOTEzNSA3MjI4OlswXTQ3OjIzODEyOTQ2NSA3Mjc1Olsw XTQ3OjIzODEzNDIwNSA3MzIyOlswXTQ3OjIzODY4NTg1MyA3MzY5OlswXTc5Ojk2NTg1NzUxIDc0 NDg6WzBdNjo5NjU4NTgzMCA3NDU0OlswXTE6OTY3MTc5MjEgNzQ1NTpbMF04OTo5ODg3ODQ5MSA3 NTQ0OlswXTg2Ojk4ODY5NDY3IDc2MzA6WzBdODY6OTg4NzQ3OTQgNzcxNjpbMF0zMDo5OTIyMTky NyA3NzQ2OlswXTUzOjEwNDM4NzA1MCA3Nzk5OlswXTQ4OjEwODk1ODIyNCA3ODQ3OlswXTQ3OjEw ODk1NTE4NSA3ODk0OlswXTM3OjEwODk3Mjk0NyA3OTMxOlswXTQ0OjEwOTM0MDYyOCA3OTc1Olsw XTQyOjEwOTMyNDUwMiA4MDE3OlswXTQzOjEwOTQwMTA0NSA4MDYwOlswXTQyOjEwOTM4NzczNCA4 MTAyOlswXTQyOjEwOTQwODIxNCA4MTQ0OlswXTQ4OjExMTM2ODMzNCA4MTkyOlswXTU3OjExMTUz NDk2MiA4MjQ5OlswXTExOjExMTUzNTAxOSA4MjYwOlswXTY3OjExMTYwNjk3ClNlcCAxMyAxNjox NjozNSB4bWFvIGtlcm5lbDogMjc6WzBdNjc6MTExODI1NzU3IDgzOTQ6WzBdMjoxMTE5MTg1MjYg ODM5NjpbMF02NDoxMTgxNjgwNDEgODQ2MDpbMF0zMzoxMDMwMjQ3NzYgODQ5MzpbMF0yNDoxMTA4 NTIwMjQgODUxNzpbMF00NToxMDQ5MjkxODMgODU2MjpbMF01NToxMTEwODk1OTYgODYxNzpbMF0x MToxMTEyMzkxMDAgODYyODpbMF0yMjoxMTEzNjYwNzggODY1MDpbMF02MDoxMTI5NTk0MjggODcx MDpbMF02MDoxMTI5ODYwNTIgODc3MDpbMF01NzoxMTMyNzg5MDMgODgyNzpbMF0yMjoxMTYyNzg0 NjIgODg0OTpbMF01OToxOTA4NzE1OTEgODkwODpbMF02MDoxOTExODI2MjkgODk2ODpbMF0zNTox OTEyNzkwNDQgOTAwMzpbMF0xNjoxOTUzNjQ4NDggOTAxOTpbMF02MzoxOTU1MjczNjEgOTA4Mjpb MF01NzoxOTgzMDE4NzAgOTEzOTpbMF0yOToxOTgyOTE1MDQgOTE2ODpbMF0xNjo5NDY1OTc3MCA5 MTg0OlswXTE2Ojk0NjYwNjk4IDkyMDA6WzBdNDE6OTQ3NzU4OTggOTI0MTpbMF0zNTo5NTY5NjA3 OSA5Mjc2OlswXTE0Ojk1Njk2MTE0IDkyOTA6WzBdNDQ6OTYwNDQ1MzAgOTMzNDpbMF02ODoxMDU1 NzQ0MjQgOTQwMjpbMF01MzoxMDU2ODU2MDggOTQ1NTpbMF00NDoxMDU5MzQ0ODUgOTQ5OTpbMF0z MzoxMTAxMjc3NzQgOTUzMjpbMF01NDoyMDkyMzM4NDcgOTU4NjpbMF0yOjIwOTIzMzkwMSA5NTg4 OlswXTU2OjIwOTIzNTkxMiA5NjQ0OlswXTIxOjIwOTI1MjQ4MCA5NjY1OlswXTQzOjI0MzI5NDc1 MCA5NzA4OlswXTQ1OjI0MzcyMDE0NyA5NzUzOlswXTQ1OjI0Mzg3MTgyNCA5Nzk4OlswXTQ0OjMx OTU3IDk4NDI6WzBdMzM6MTg3MDcwMjggOTg3NTpbMF03MjoxMjQwOTY0NDAgOTk0NzpbMF02MDox MjQ1NTgxMDEgMTAwMDc6WzBdNzI6MTMwMzAzOTI4IDEwMDc5OlswXTc0OjEzMDYxNzAxNCAxMDE1 MzpbMF0zMDoxMzEwNDI5MzUgMTAxODM6WzBdNTc6MTQxMTU2ODA0IDEwMjQwOlswXTYzOjE0MTY1 OTc0NiAxMDMwMzpbMF0xOjE0MTY1OTgwOSAxMDMwNDpbMF0xOToxNDE2NTkKU2VwIDEzIDE2OjE2 OjM1IHhtYW8ga2VybmVsOiAxMDMyMzpbMF0yNjoxNDE3NjA1NzIgMTAzNDk6WzBdNDQ6MTQ0MDE4 MzQyIDEwMzkzOlswXTY2OjE1NzMyNzU1MCAxMDQ1OTpbMF02NjoxNTczNTgyNzAgMTA1MjU6WzBd MzQ6MTU4NDU0OTc1IDEwNTU5OlswXTY0OjE2MjA2MzA0MCAxMDYyMzpbMF02MzoxNjIxMjM3MTMg MTA2ODY6WzBdNjoxNjIxMzM5NTMgMTA2OTI6WzBdNjE6MTY0NDQ0NjExIDEwNzUzOlswXTYwOjE2 NDUzNjI2MCAxMDgxMzpbMF00NToxNjQ1OTU5MDggMTA4NTg6WzBdNDQ6MTY1Mjk5MDA2IDEwOTAy OlswXTU3OjE2NTQ5OTAwNyAxMDk1OTpbMF01NzoxNjU1MjgxNjMgMTEwMTY6WzBdMTg6MTY1NjUw Mzc1IDExMDM0OlswXTc2OjE3MTk5MDM5NyAxMTExMDpbMF04OjE4NTAxMDUwOCAxMTExODpbMF04 OjE4NTAxMDUzMiAxMTEyNjpbMF01OjE4Njc0Njc3MSAxMTEzMTpbMF0xMToxODY3NDY3NzYgMTEx NDI6WzBdNTc6MTg3MDkzMTcwIDExMTk5OlswXTExOjE4NzExMzE2MCAxMTIxMDpbMF0zODoxNzg1 NzUzOTIgMTEyNDg6WzBdMzk6MTc5NDczMTEzIDExMjg3OlswXTM5OjE3OTQ3NDM5MyAxMTMyNjpb MF00OjE3OTk2NTkxMyAxMTMzMDpbMF0xOjE3OTk2NTkxNyAxMTMzMTpbMF0zNDoxNzk5NjU5MTgg MTEzNjU6WzBdMjI6MTgwMDQ0OTMwIDExMzg3OlswXTM0OjE4MDg1ODg0NiAxMTQyMTpbMF0zNTox ODA5NTEwMjEgMTE0NTY6WzBdNDQ6MTgxMDczNjIwIDExNTAwOlswXTg6MTgxMDYxMDkxIDExNTA4 OlswXTU1OjYxNzQyOTc0IDExNTYzOlswXTIzOjYwMzE4MDA5IDExNTg2OlswXTEwMjo4MzgxNDAw MiAxMTY4ODpbMF0zMTo4MzgzMzQ5OCAxMTcxOTpbMF03OTo5MTc2NDUwMiAxMTc5ODpbMF03ODo5 MTgzMTAyOCAxMTg3NjpbMF0yMDo5MjAyMDkxNCAxMTg5NjpbMF01ODo5NDEzOTMxMSAxMTk1NDpb MF01Nzo5NDE3NzE2OCAxMjAxMTpbMF01MDo5NDE3NTY4OSAxMjA2MTpbMF03MjoxNTY0MDMzODQg MTIxMzM6WzBdNjA6MTU2NjQ5NDAxIDEyMTkzOlswXTY0OjE1NzI0MTU2MApTZXAgMTMgMTY6MTY6 MzUgeG1hbyBrZXJuZWw6IDU3OlswXTMxOjE1NzI1NDcyMSAxMjI4ODpbMF01NDoxNTc1MDM4MzAg MTIzNDI6WzBdMTA6MTU3NTAzODg0IDEyMzUyOlswXTU6MTU3NTM0NzYzIDEyMzU3OlswXTE6MTU3 NTM0NzY4IDEyMzU4OlswXTU4OjE1NzUzNDc2OSAxMjQxNjpbMF02NDoxNTc1NjcxNjggMTI0ODA6 WzBdMTM6MTU4MDUxMjYxIDEyNDkzOlswXTczOjE3MjI2MzA5NSAxMjU2NjpbMF0yNDoxNzIyNjUz OTkgMTI1OTA6WzBdNzE6MTcyNTIxODU5IDEyNjYxOlswXTcxOjE3MjYyNzg5NyAxMjczMjpbMF03 MToxNzI3MzM3MzUgMTI4MDM6WzBdNjk6MTcyNzIyNjE5IDEyODcyOlswXTk6MTcyNzY0ODU5IDEy ODgxOlswXTQyOjExMDUwMDAyOCAxMjkyMzpbMF04NjoxNDMwMzAwNjEgMTMwMDk6WzBdODY6MTQz MTE5ODU5IDEzMDk1OlswXTQ4OjE0MzE3MzM3NiAxMzE0MzpbMF0xNjoxOTUzMzM1ODYgMTMxNTk6 WzBdMzI6MTk3NTI2MTA1IDEzMTkxOlswXTQwOjE5ODg3NTg2MSAxMzIzMTpbMF0zOToxOTg4NzIz MDAgMTMyNzA6WzBdNToxOTk2NjM1NzYgMTMyNzU6WzBdMjY6MjAwOTY0MTkyIDEzMzAxOlswXTM2 OjIwMjAxNTcwOCAxMzMzNzpbMF00NzoyMDIyMjE2ODIgMTMzODQ6WzBdOToyMDIyMjE3MjkgMTMz OTM6WzBdNTg6MjAyNjI0OTY2IDEzNDUxOlswXTEyOjIwMjYwNjUzNSAxMzQ2MzpbMF0zNToyMTIx MTc3MjUgMTM0OTg6WzBdMzU6MjEyMTM1ODExIDEzNTMzOlswXTM0OjIxMjExNTUxMyAxMzU2Nzpb MF0zMjoyMTIxMDg2MDggMTM1OTk6WzBdMjk6MjEyMTQ0MTg1IDEzNjI4OlswXTUwOjIzMTI4MDQy MCAxMzY3ODpbMF0zODoyMzE2NDUzODkgMTM3MTY6WzBdMTM6MjMxNjQ1NDI3IDEzNzI5OlswXTUx OjIzMTY1MDc2NSAxMzc4MDpbMF01MDoyMzE2NDc2NTggMTM4MzA6WzBdNTQ6MjMxOTg1MzQwIDEz ODg0OlswXTI0OjIzMTk4MTI1OSAxMzkwODpbMF02NDoxMDUwOTg3MzEgMTM5NzI6WzBdODc6MTM2 Njk2NzQ1IDE0MDU5OlswXTQ1OjEzNjcwMDIzNyAxNDEwNDpbMF02MToyClNlcCAxMyAxNjoxNjoz NSB4bWFvIGtlcm5lbDogMzY1MSAxNDE2NTpbMF02OToyMjIwNDIyOTkgMTQyMzQ6WzBdNjg6MjIy MDQ0MDkyIDE0MzAyOlswXTM0OjIyMjA5MTc2MSAxNDMzNjpbMF02ODoyMjIxNzI4NjAgMTQ0MDQ6 WzBdNzoyMjIzMzI2MDYgMTQ0MTE6WzBdMToyMjIzMzI2MTMgClNlcCAxMyAxNjoxNjozNSB4bWFv IGtlcm5lbDogRGlzcGxheWluZyBsZWFmIGV4dGVudHMgZm9yIGlub2RlIDMwNjg1MDYwClNlcCAx MyAxNjoxNjozNSB4bWFvIGtlcm5lbDogMTQ0MTI6WzFdMTY6OTkyNyAxNDQyODpbMV00MToxMzIx MyAxNDQ2OTpbMV0xOjEzMjU0IDE0NDcwOlswXTY3OjIyMjY3MzA4NSAKU2VwIDEzIDE2OjE2OjM1 IHhtYW8ga2VybmVsOiAtLS0tLS0tLS0tLS1bIGN1dCBoZXJlIF0tLS0tLS0tLS0tLS0KU2VwIDEz IDE2OjE2OjM1IHhtYW8ga2VybmVsOiBrZXJuZWwgQlVHIGF0IGZzL2V4dDQvZXh0ZW50cy5jOjE3 NjIhClNlcCAxMyAxNjoxNjozNSB4bWFvIGtlcm5lbDogaW52YWxpZCBvcGNvZGU6IDAwMDAgWyMx XSBTTVAgClNlcCAxMyAxNjoxNjozNSB4bWFvIGtlcm5lbDogbGFzdCBzeXNmcyBmaWxlOiAvc3lz L2Jsb2NrL3RhcGRldmwvc3RhdApTZXAgMTMgMTY6MTY6MzUgeG1hbyBrZXJuZWw6IENQVSAxIApT ZXAgMTMgMTY6MTY6MzUgeG1hbyBrZXJuZWw6IE1vZHVsZXMgbGlua2VkIGluOiB4dF9pcHJhbmdl IHh0X21hYyBhcnB0YWJsZV9maWx0ZXIgYXJwX3RhYmxlcyB4dF9waHlzZGV2IG5mX2Nvbm50cmFj a19pcHY0IG5mX2RlZnJhZ19pcHY0IHh0X3N0YXRlIG5mX2Nvbm50cmFjayBpcHRhYmxlX2ZpbHRl ciBpcF90YWJsZXMgYnJpZGdlIGF1dG9mczQgaXBtaV9kZXZpbnRmIGlwbWlfc2kgaXBtaV9tc2do YW5kbGVyIGxvY2tkIHN1bnJwYyBib25kaW5nIGlwdjYgODAyMXEgZ2FycCBzdHAgbGxjIHhlbmZz IGRtX211bHRpcGF0aCBmdXNlIHhlbl9uZXRiYWNrIHhlbl9ibGtiYWNrIGJsa3RhcCBibGtiYWNr X3BhZ2VtYXAgbG9vcCBuYmQgdmlkZW8gb3V0cHV0IHNicyBzYnNoYyBwYXJwb3J0X3BjIGxwIHBh cnBvcnQgam95ZGV2IHNuZF9zZXFfZHVtbXkgZGNkYmFzIHNuZF9zZXFfb3NzIHNuZF9zZXFfbWlk aV9ldmVudCBzbmRfc2VxIHNuZF9zZXFfZGV2aWNlIGJueDIgc25kX3BjbV9vc3Mgc2VyaW9fcmF3 IHNuZF9taXhlcl9vc3Mgc25kX3BjbSBzbmRfdGltZXIgc25kIGlUQ09fd2R0IGlUQ09fdmVuZG9y X3N1cHBvcnQgc291bmRjb3JlIHNuZF9wYWdlX2FsbG9jIHBjc3BrciBzaHBjaHAgbXB0c2FzIG1w dHNjc2loIG1wdGJhc2UgW2xhc3QgdW5sb2FkZWQ6IGZyZXFfdGFibGVdClNlcCAxMyAxNjoxNjoz NSB4bWFvIGtlcm5lbDogUGlkOiA3NTIsIGNvbW06IGZsdXNoLTg6ODAgTm90IHRhaW50ZWQgMi42 LjMyLjM2eGVuICM0IFBvd2VyRWRnZSBSNzEwClNlcCAxMyAxNjoxNjozNSB4bWFvIGtlcm5lbDog UklQOiBlMDMwOls8ZmZmZmZmZmY4MTFhNjczMT5dICBbPGZmZmZmZmZmODExYTY3MzE+XSBleHQ0 X2V4dF9pbnNlcnRfZXh0ZW50KzB4YmQ0LzB4ZDA2ClNlcCAxMyAxNjoxNjozNSB4bWFvIGtlcm5l bDogUlNQOiBlMDJiOmZmZmY4ODAxY2UxMTk1MjAgIEVGTEFHUzogMDAwMTAyNDYKU2VwIDEzIDE2 OjE2OjM1IHhtYW8ga2VybmVsOiBSQVg6IDAwMDAwMDAwMDAwMDM4NGMgUkJYOiBmZmZmODgwMWNl MTE5NzcwIFJDWDogZmZmZjg4MDEzZWRmNjAwMApTZXAgMTMgMTY6MTY6MzUgeG1hbyBrZXJuZWw6 IFJEWDogZmZmZjg4MDFjZTExOTc3MCBSU0k6IGZmZmZmZmZmODE0MzAwYWEgUkRJOiAwMDAwMDAw MDAwMDAwMjA0ClNlcCAxMyAxNjoxNjozNSB4bWFvIGtlcm5lbDogUkJQOiBmZmZmODgwMWNlMTE5 NjIwIFIwODogMDAwMDAwMDAwMDAwMDAwMSBSMDk6IGZmZmZmZmZmODE3ZTg5MzMKU2VwIDEzIDE2 OjE2OjM1IHhtYW8ga2VybmVsOiBSMTA6IGZmZmZmZmZmODE1ZDhmNTMgUjExOiBkZWFkMDAwMDAw MjAwMjAwIFIxMjogZmZmZjg4MDEzZWRmNjAwYwpTZXAgMTMgMTY6MTY6MzUgeG1hbyBrZXJuZWw6 IFIxMzogZmZmZjg4MDEzZWRmNjAwMCBSMTQ6IGZmZmY4ODAxMmY3ZDY1ODggUjE1OiBmZmZmODgw MTZjZDNkZTcwClNlcCAxMyAxNjoxNjozNSB4bWFvIGtlcm5lbDogRlM6ICAwMDAwN2YxYzVkNGM1 NzQwKDAwMDApIEdTOmZmZmY4ODAwMjgwNTUwMDAoMDAwMCkga25sR1M6MDAwMDAwMDAwMDAwMDAw MApTZXAgMTMgMTY6MTY6MzUgeG1hbyBrZXJuZWw6IENTOiAgZTAzMyBEUzogMDAwMCBFUzogMDAw MCBDUjA6IDAwMDAwMDAwODAwNTAwM2IKU2VwIDEzIDE2OjE2OjM1IHhtYW8ga2VybmVsOiBDUjI6 IDAwMDA3ZjFjNTAyNjUwMDAgQ1IzOiAwMDAwMDAwMTc5OWE2MDAwIENSNDogMDAwMDAwMDAwMDAw MjY2MApTZXAgMTMgMTY6MTY6MzUgeG1hbyBrZXJuZWw6IERSMDogMDAwMDAwMDAwMDAwMDAwMCBE UjE6IDAwMDAwMDAwMDAwMDAwMDAgRFIyOiAwMDAwMDAwMDAwMDAwMDAwClNlcCAxMyAxNjoxNjoz NSB4bWFvIGtlcm5lbDogRFIzOiAwMDAwMDAwMDAwMDAwMDAwIERSNjogMDAwMDAwMDBmZmZmMGZm MCBEUjc6IDAwMDAwMDAwMDAwMDA0MDAKU2VwIDEzIDE2OjE2OjM1IHhtYW8ga2VybmVsOiBQcm9j ZXNzIGZsdXNoLTg6ODAgKHBpZDogNzUyLCB0aHJlYWRpbmZvIGZmZmY4ODAxY2UxMTgwMDAsIHRh c2sgZmZmZjg4MDFjZTlhZGI0MCkKU2VwIDEzIDE2OjE2OjM1IHhtYW8ga2VybmVsOiBTdGFjazoK U2VwIDEzIDE2OjE2OjM1IHhtYW8ga2VybmVsOiAgZmZmZjg4MDEwMDAwMGZlNCBmZmZmODgwMTNl ZGY2MDE4IGZmZmY4ODAxM2VkZjYwMjQgMDAwMDAwMDAwMDAwMDAwMApTZXAgMTMgMTY6MTY6MzUg eG1hbyBrZXJuZWw6IDwwPiBmZmZmODgwMWNlMTE5NzcwIGZmZmY4ODAxNmNkM2RhODAgZmZmZjg4 MDFjZDkzOTM5MCAwMWZmODgwMWRiZDM1ZTgwClNlcCAxMyAxNjoxNjozNSB4bWFvIGtlcm5lbDog PDA+IGZmZmY4ODAxNmNkM2RlNDAgMDAwMDAwMDAwMDAwMDAwMSBmZmZmODgwMTJmN2Q2NGM4IGZm ZmY4ODAxZDIyMzAyMDAKU2VwIDEzIDE2OjE2OjM1IHhtYW8ga2VybmVsOiBDYWxsIFRyYWNlOgpT ZXAgMTMgMTY6MTY6MzUgeG1hbyBrZXJuZWw6ICBbPGZmZmZmZmZmODExYTc3ZTk+XSA/IGV4dDRf ZXh0X2hhbmRsZV91bmluaXRpYWxpemVkX2V4dGVudHMrMHhmODYvMHhmYTMKU2VwIDEzIDE2OjE2 OjM1IHhtYW8ga2VybmVsOiAgWzxmZmZmZmZmZjgxMWMxODgyPl0gPyBqYmRfdW5sb2NrX2JoX2pv dXJuYWxfaGVhZCsweDE2LzB4MTgKU2VwIDEzIDE2OjE2OjM1IHhtYW8ga2VybmVsOiAgWzxmZmZm ZmZmZjgxMWMxYzgyPl0gPyBqYmQyX2pvdXJuYWxfcHV0X2pvdXJuYWxfaGVhZCsweDRkLzB4NTIK U2VwIDEzIDE2OjE2OjM1IHhtYW8ga2VybmVsOiAgWzxmZmZmZmZmZjgxMWJiZDZlPl0gPyBqYmQy X2pvdXJuYWxfZ2V0X3dyaXRlX2FjY2VzcysweDMxLzB4MzgKU2VwIDEzIDE2OjE2OjM1IHhtYW8g a2VybmVsOiAgWzxmZmZmZmZmZjgxMWE4ZGExPl0gPyBfX2V4dDRfam91cm5hbF9nZXRfd3JpdGVf YWNjZXNzKzB4NGMvMHg1ZgpTZXAgMTMgMTY6MTY6MzUgeG1hbyBrZXJuZWw6ICBbPGZmZmZmZmZm ODExYTczMWI+XSBleHQ0X2V4dF9oYW5kbGVfdW5pbml0aWFsaXplZF9leHRlbnRzKzB4YWI4LzB4 ZmEzClNlcCAxMyAxNjoxNjozNSB4bWFvIGtlcm5lbDogIFs8ZmZmZmZmZmY4MTIwNzRiOT5dID8g YmxrX3JxX2luaXQrMHgyMS8weGI1ClNlcCAxMyAxNjoxNjozNSB4bWFvIGtlcm5lbDogIFs8ZmZm ZmZmZmY4MTAwZjE3NT5dID8geGVuX2ZvcmNlX2V2dGNobl9jYWxsYmFjaysweGQvMHhmClNlcCAx MyAxNjoxNjozNSB4bWFvIGtlcm5lbDogIFs8ZmZmZmZmZmY4MTAwZjhkMj5dID8gY2hlY2tfZXZl bnRzKzB4MTIvMHgyMApTZXAgMTMgMTY6MTY6MzUgeG1hbyBrZXJuZWw6ICBbPGZmZmZmZmZmODEw NDJmY2Y+XSA/IG5lZWRfcmVzY2hlZCsweDIzLzB4MmQKU2VwIDEzIDE2OjE2OjM1IHhtYW8ga2Vy bmVsOiAgWzxmZmZmZmZmZjgxMWE4OGZhPl0gZXh0NF9leHRfZ2V0X2Jsb2NrcysweDI0My8weDYx YwpTZXAgMTMgMTY6MTY6MzUgeG1hbyBrZXJuZWw6ICBbPGZmZmZmZmZmODEyMDY2Yjg+XSA/IGdl bmVyaWNfbWFrZV9yZXF1ZXN0KzB4MWU4LzB4Mjg0ClNlcCAxMyAxNjoxNjozNSB4bWFvIGtlcm5l bDogIFs8ZmZmZmZmZmY4MTIwN2MxMD5dID8gc3VibWl0X2JpbysweGJmLzB4YzgKU2VwIDEzIDE2 OjE2OjM1IHhtYW8ga2VybmVsOiAgWzxmZmZmZmZmZjgxMDQyZmNmPl0gPyBuZWVkX3Jlc2NoZWQr MHgyMy8weDJkClNlcCAxMyAxNjoxNjozNSB4bWFvIGtlcm5lbDogIFs8ZmZmZmZmZmY4MTE4OGFl MD5dIGV4dDRfZ2V0X2Jsb2NrcysweDE0MC8weDIwNApTZXAgMTMgMTY6MTY6MzUgeG1hbyBrZXJu ZWw6ICBbPGZmZmZmZmZmODExODhjYmE+XSBtcGFnZV9kYV9tYXBfYmxvY2tzKzB4YjcvMHg2OGUK U2VwIDEzIDE2OjE2OjM1IHhtYW8ga2VybmVsOiAgWzxmZmZmZmZmZjgxMTg4YmE0Pl0gPyBub2Fs bG9jX2dldF9ibG9ja193cml0ZSsweDAvMHg1ZgpTZXAgMTMgMTY6MTY6MzUgeG1hbyBrZXJuZWw6 ICBbPGZmZmZmZmZmODEwMGYxNzU+XSA/IHhlbl9mb3JjZV9ldnRjaG5fY2FsbGJhY2srMHhkLzB4 ZgpTZXAgMTMgMTY6MTY6MzUgeG1hbyBrZXJuZWw6ICBbPGZmZmZmZmZmODEyMWU1ZjQ+XSA/IF9f bG9va3VwX3RhZysweDYwLzB4MTFlClNlcCAxMyAxNjoxNjozNiB4bWFvIGtlcm5lbDogIFs8ZmZm ZmZmZmY4MTBmNGEwMD5dID8gcGFnZV9ta2NsZWFuKzB4MjEvMHgxZGMKU2VwIDEzIDE2OjE2OjM2 IHhtYW8ga2VybmVsOiAgWzxmZmZmZmZmZjgxMjFlYmNlPl0gPyByYWRpeF90cmVlX2dhbmdfbG9v a3VwX3RhZ19zbG90KzB4ODUvMHhhYQpTZXAgMTMgMTY6MTY6MzYgeG1hbyBrZXJuZWw6ICBbPGZm ZmZmZmZmODEwMGYxNzU+XSA/IHhlbl9mb3JjZV9ldnRjaG5fY2FsbGJhY2srMHhkLzB4ZgpTZXAg MTMgMTY6MTY6MzYgeG1hbyBrZXJuZWw6ICBbPGZmZmZmZmZmODEwMGYxNzU+XSA/IHhlbl9mb3Jj ZV9ldnRjaG5fY2FsbGJhY2srMHhkLzB4ZgpTZXAgMTMgMTY6MTY6MzYgeG1hbyBrZXJuZWw6ICBb PGZmZmZmZmZmODExOGJiM2U+XSBleHQ0X2RhX3dyaXRlcGFnZXMrMHg1YWIvMHg5N2QKU2VwIDEz IDE2OjE2OjM2IHhtYW8ga2VybmVsOiAgWzxmZmZmZmZmZjgxMTM5NTUxPl0gPyBibGtkZXZfZ2V0 X2Jsb2NrKzB4MC8weDU1ClNlcCAxMyAxNjoxNjozNiB4bWFvIGtlcm5lbDogIFs8ZmZmZmZmZmY4 MTBkOGEwMD5dIGRvX3dyaXRlcGFnZXMrMHgyMS8weDJhClNlcCAxMyAxNjoxNjozNiB4bWFvIGtl cm5lbDogIFs8ZmZmZmZmZmY4MTEyY2RiND5dIHdyaXRlYmFja19zaW5nbGVfaW5vZGUrMHhjOC8w eDFlMwpTZXAgMTMgMTY6MTY6MzYgeG1hbyBrZXJuZWw6ICBbPGZmZmZmZmZmODExMmQ1ZTA+XSB3 cml0ZWJhY2tfaW5vZGVzX3diKzB4MzBiLzB4MzdlClNlcCAxMyAxNjoxNjozNiB4bWFvIGtlcm5l bDogIFs8ZmZmZmZmZmY4MTEyZDc4ND5dIHdiX3dyaXRlYmFjaysweDEzMS8weDFiYgpTZXAgMTMg MTY6MTY6MzYgeG1hbyBrZXJuZWw6ICBbPGZmZmZmZmZmODEwNjQwMjk+XSA/IHRyeV90b19kZWxf dGltZXJfc3luYysweDczLzB4ODEKU2VwIDEzIDE2OjE2OjM2IHhtYW8ga2VybmVsOiAgWzxmZmZm ZmZmZjgxMTJkOWViPl0gd2JfZG9fd3JpdGViYWNrKzB4MTNjLzB4MTUzClNlcCAxMyAxNjoxNjoz NiB4bWFvIGtlcm5lbDogIFs8ZmZmZmZmZmY4MTA2NDI1Yj5dID8gcHJvY2Vzc190aW1lb3V0KzB4 MC8weDEwClNlcCAxMyAxNjoxNjozNiB4bWFvIGtlcm5lbDogIFs8ZmZmZmZmZmY4MTBlNzhkMT5d ID8gYmRpX3N0YXJ0X2ZuKzB4MC8weGQwClNlcCAxMyAxNjoxNjozNiB4bWFvIGtlcm5lbDogIFs8 ZmZmZmZmZmY4MTEyZGEyZT5dIGJkaV93cml0ZWJhY2tfdGFzaysweDJjLzB4YjMKU2VwIDEzIDE2 OjE2OjM2IHhtYW8ga2VybmVsOiAgWzxmZmZmZmZmZjgxMGU3OTNiPl0gYmRpX3N0YXJ0X2ZuKzB4 NmEvMHhkMApTZXAgMTMgMTY6MTY6MzYgeG1hbyBrZXJuZWw6ICBbPGZmZmZmZmZmODEwNzU0Yjc+ XSBrdGhyZWFkKzB4NmUvMHg3NgpTZXAgMTMgMTY6MTY6MzYgeG1hbyBrZXJuZWw6ICBbPGZmZmZm ZmZmODEwMTNkYWE+XSBjaGlsZF9yaXArMHhhLzB4MjAKU2VwIDEzIDE2OjE2OjM2IHhtYW8ga2Vy bmVsOiAgWzxmZmZmZmZmZjgxMDEyZjkxPl0gPyBpbnRfcmV0X2Zyb21fc3lzX2NhbGwrMHg3LzB4 MWIKU2VwIDEzIDE2OjE2OjM2IHhtYW8ga2VybmVsOiAgWzxmZmZmZmZmZjgxMDEzNzFkPl0gPyBy ZXRpbnRfcmVzdG9yZV9hcmdzKzB4NS8weDYKU2VwIDEzIDE2OjE2OjM2IHhtYW8ga2VybmVsOiAg WzxmZmZmZmZmZjgxMDEzZGEwPl0gPyBjaGlsZF9yaXArMHgwLzB4MjAKU2VwIDEzIDE2OjE2OjM2 IHhtYW8ga2VybmVsOiBDb2RlOiBmZiA0OCA4YiBiNSAyOCBmZiBmZiBmZiA0YyA4OSBmNyBlOCA1 MSBlMCBmZiBmZiA0OCA4YiA3NSA5OCA0YyA4OSBmNyBlOCA0NSBlMCBmZiBmZiA0OCA4YiA5NSAy MCBmZiBmZiBmZiA4YiAwMiA0MSAzYiAwNCAyNCA3NSAwNCA8MGY+IDBiIGViIGZlIDQxIDBmIGI3 IDQ1IDA0IDMxIGQyIDQ4IDZiIGMwIDBjIDQ5IDhkIDdjIDI0IDBjIDQ5IApTZXAgMTMgMTY6MTY6 MzYgeG1hbyBrZXJuZWw6IFJJUCAgWzxmZmZmZmZmZjgxMWE2NzMxPl0gZXh0NF9leHRfaW5zZXJ0 X2V4dGVudCsweGJkNC8weGQwNgpTZXAgMTMgMTY6MTY6MzYgeG1hbyBrZXJuZWw6ICBSU1AgPGZm ZmY4ODAxY2UxMTk1MjA+ClNlcCAxMyAxNjoxNjozNiB4bWFvIGtlcm5lbDogLS0tWyBlbmQgdHJh Y2UgMmI1YjdjODFmYWVhNDNmOCBdLS0tCg== --_8ed9fe05-1fc2-4309-8777-22b0c1c100d9_ Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel --_8ed9fe05-1fc2-4309-8777-22b0c1c100d9_-- From xen-devel-bounces@lists.xensource.com Fri Sep 16 00:14:53 2011 Return-path: Envelope-to: www-data@lists.xensource.com Delivery-date: Fri, 16 Sep 2011 00:14:53 -0700 Received: from localhost ([127.0.0.1] helo=lists.colo.xensource.com) by lists.xensource.com with esmtp (Exim 4.43) id 1R4SdR-0007FH-7p; Fri, 16 Sep 2011 00:14:53 -0700 Received: from mail216.messagelabs.com ([85.158.143.99]) by lists.xensource.com with esmtp (Exim 4.43) id 1R4ScX-00072s-QF for xen-devel@lists.xensource.com; Fri, 16 Sep 2011 00:13:58 -0700 X-Env-Sender: JBeulich@suse.com X-Msg-Ref: server-9.tower-216.messagelabs.com!1316157234!18473174!1 X-Originating-IP: [130.57.49.28] X-StarScan-Version: 6.4.1; banners=-,-,- X-VirusChecked: Checked Received: (qmail 26485 invoked from network); 16 Sep 2011 07:13:54 -0000 Received: from nat28.tlf.novell.com (HELO nat28.tlf.novell.com) (130.57.49.28) by server-9.tower-216.messagelabs.com with DHE-RSA-AES256-SHA encrypted SMTP; 16 Sep 2011 07:13:54 -0000 Received: from EMEA1-MTA by nat28.tlf.novell.com with Novell_GroupWise; Fri, 16 Sep 2011 08:13:53 +0100 Message-Id: <4E7313510200007800056713@nat28.tlf.novell.com> X-Mailer: Novell GroupWise Internet Agent 8.0.1 Date: Fri, 16 Sep 2011 08:13:53 +0100 From: "Jan Beulich" To: "Haitao Shan" Subject: Re: [Xen-devel] [PATCH] Fix PV CPUID virtualization of XSave References: In-Reply-To: Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: quoted-printable Content-Disposition: inline Cc: xen-devel@lists.xensource.com, Keir Fraser X-BeenThere: xen-devel@lists.xensource.com X-Mailman-Version: 2.1.5 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xensource.com Errors-To: xen-devel-bounces@lists.xensource.com >>> On 16.09.11 at 02:46, Haitao Shan wrote: > Hi, Keir, >=20 > The patch will fix XSave CPUID virtualization for PV guests. The XSave > area size returned by CPUID leaf D is changed dynamically depending on > the XCR0. Tools/libxc only assigns a static value. The fix will adjust > xsave area size during runtime. >=20 > Note: This fix is already in HVM cpuid virtualization. And Dom0 is not > affected, either. >=20 > Signed-off-by: Shan Haitao >=20 > Shan Haitao >=20 > diff -r 5fe770c8a8a3 xen/arch/x86/traps.c > --- a/xen/arch/x86/traps.c Tue Sep 06 15:49:40 2011 +0100 > +++ b/xen/arch/x86/traps.c Wed Sep 07 02:09:12 2011 +0800 > @@ -770,6 +770,30 @@ static void pv_cpuid(struct cpu_user_reg > { > if ( !cpuid_hypervisor_leaves(a, c, &a, &b, &c, &d) ) > domain_cpuid(current->domain, a, c, &a, &b, &c, &d); > + > + switch ( a ) > + { > + case 0xd: > + { > + unsigned int sub_leaf, _eax, _ebx, _ecx, _edx; > + /* EBX value of main leaf 0 depends on enabled xsave = features=20 > */ > + if ( c =3D=3D 0 && current->arch.xcr0 ) > + { > + /* reset EBX to default value first */ > + b =3D XSTATE_AREA_MIN_SIZE; > + for ( sub_leaf =3D 2; sub_leaf < 64; sub_leaf++ ) Shouldn't the upper bound be 63 here (as bit 63 serves a different purpose, and if that bit was set code changes would be required in various other places)? Jan > + { > + if ( !(current->arch.xcr0 & (1ULL << sub_leaf)) ) > + continue; > + domain_cpuid(current->domain, a, c, &_eax, &_ebx, = &_ecx, > + &_edx); > + if ( (_eax + _ebx) > b ) > + b =3D _eax + _ebx; > + } > + } > + break; > + } > + } > goto out; > } _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel From xen-devel-bounces@lists.xensource.com Fri Sep 16 00:42:26 2011 Return-path: Envelope-to: www-data@lists.xensource.com Delivery-date: Fri, 16 Sep 2011 00:42:26 -0700 Received: from localhost ([127.0.0.1] helo=lists.colo.xensource.com) by lists.xensource.com with esmtp (Exim 4.43) id 1R4T46-00084C-2C; Fri, 16 Sep 2011 00:42:26 -0700 Received: from mail174.messagelabs.com ([85.158.138.51]) by lists.xensource.com with esmtp (Exim 4.43) id 1R4T39-0007rK-Kl for xen-devel@lists.xensource.com; Fri, 16 Sep 2011 00:41:28 -0700 X-Env-Sender: JBeulich@suse.com X-Msg-Ref: server-2.tower-174.messagelabs.com!1316158883!31621452!1 X-Originating-IP: [130.57.49.28] X-StarScan-Version: 6.4.1; banners=-,-,- X-VirusChecked: Checked Received: (qmail 9785 invoked from network); 16 Sep 2011 07:41:24 -0000 Received: from nat28.tlf.novell.com (HELO nat28.tlf.novell.com) (130.57.49.28) by server-2.tower-174.messagelabs.com with DHE-RSA-AES256-SHA encrypted SMTP; 16 Sep 2011 07:41:24 -0000 Received: from EMEA1-MTA by nat28.tlf.novell.com with Novell_GroupWise; Fri, 16 Sep 2011 08:41:23 +0100 Message-Id: <4E7319C3020000780005672B@nat28.tlf.novell.com> X-Mailer: Novell GroupWise Internet Agent 8.0.1 Date: Fri, 16 Sep 2011 08:41:23 +0100 From: "Jan Beulich" To: "xen-devel@lists.xensource.com" Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="=__Part1A352BB3.0__=" Subject: [Xen-devel] [PATCH] linux-2.6.18/backends: use kzalloc() in favor of kmalloc()+memset() X-BeenThere: xen-devel@lists.xensource.com X-Mailman-Version: 2.1.5 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xensource.com Errors-To: xen-devel-bounces@lists.xensource.com This is a MIME message. If you are reading this text, you may want to consider changing to a mail reader or gateway that understands how to properly handle MIME multipart messages. --=__Part1A352BB3.0__= Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: quoted-printable Content-Disposition: inline This fixes the problem of three of those four memset()-s having improper size arguments passed: Sizeof a pointer-typed expression returns the size of the pointer, not that of the pointed to data. Reported-by: Julia Lawall Signed-off-by: Jan Beulich --- a/drivers/xen/blkback/blkback.c +++ b/drivers/xen/blkback/blkback.c @@ -633,7 +633,7 @@ static int __init blkif_init(void) =20 mmap_pages =3D blkif_reqs * BLKIF_MAX_SEGMENTS_PER_REQUEST; =20 - pending_reqs =3D kmalloc(sizeof(pending_reqs[0]) * + pending_reqs =3D kzalloc(sizeof(pending_reqs[0]) * blkif_reqs, GFP_KERNEL); pending_grant_handles =3D kmalloc(sizeof(pending_grant_handles[0]) = * mmap_pages, GFP_KERNEL); @@ -650,7 +650,6 @@ static int __init blkif_init(void) =20 blkif_interface_init(); =20 - memset(pending_reqs, 0, sizeof(pending_reqs)); INIT_LIST_HEAD(&pending_free); =20 for (i =3D 0; i < blkif_reqs; i++) --- a/drivers/xen/scsiback/emulate.c +++ b/drivers/xen/scsiback/emulate.c @@ -246,13 +246,11 @@ static void __report_luns(pending_req_t=20 alloc_len =3D sizeof(struct scsi_lun) * alloc_luns + VSCSI_REPORT_LUNS_HEADER; retry: - if ((buff =3D kmalloc(alloc_len, GFP_KERNEL)) =3D=3D NULL) { + if ((buff =3D kzalloc(alloc_len, GFP_KERNEL)) =3D=3D NULL) { printk(KERN_ERR "scsiback:%s kmalloc err\n", __FUNCTION__);= goto fail; } =20 - memset(buff, 0, alloc_len); - one_lun =3D (struct scsi_lun *) &buff[8]; spin_lock_irqsave(&info->v2p_lock, flags); list_for_each_entry(entry, head, l) { --- a/drivers/xen/scsiback/scsiback.c +++ b/drivers/xen/scsiback/scsiback.c @@ -687,7 +687,7 @@ static int __init scsiback_init(void) =20 mmap_pages =3D vscsiif_reqs * VSCSIIF_SG_TABLESIZE; =20 - pending_reqs =3D kmalloc(sizeof(pending_reqs[0]) * + pending_reqs =3D kzalloc(sizeof(pending_reqs[0]) * vscsiif_reqs, GFP_KERNEL); pending_grant_handles =3D kmalloc(sizeof(pending_grant_handles[0]) = * mmap_pages, GFP_KERNEL); @@ -702,7 +702,6 @@ static int __init scsiback_init(void) if (scsiback_interface_init() < 0) goto out_of_kmem; =20 - memset(pending_reqs, 0, sizeof(pending_reqs)); INIT_LIST_HEAD(&pending_free); =20 for (i =3D 0; i < vscsiif_reqs; i++) --- a/drivers/xen/usbback/usbback.c +++ b/drivers/xen/usbback/usbback.c @@ -1105,7 +1105,7 @@ static int __init usbback_init(void) return -ENODEV; =20 mmap_pages =3D usbif_reqs * USBIF_MAX_SEGMENTS_PER_REQUEST; - pending_reqs =3D kmalloc(sizeof(pending_reqs[0]) * + pending_reqs =3D kzalloc(sizeof(pending_reqs[0]) * usbif_reqs, GFP_KERNEL); pending_grant_handles =3D kmalloc(sizeof(pending_grant_handles[0]) = * mmap_pages, GFP_KERNEL); @@ -1119,7 +1119,6 @@ static int __init usbback_init(void) for (i =3D 0; i < mmap_pages; i++) pending_grant_handles[i] =3D USBBACK_INVALID_HANDLE; =20 - memset(pending_reqs, 0, sizeof(pending_reqs)); INIT_LIST_HEAD(&pending_free); =20 for (i =3D 0; i < usbif_reqs; i++) --=__Part1A352BB3.0__= Content-Type: text/plain; name="xen-backends-kzalloc.patch" Content-Transfer-Encoding: quoted-printable Content-Disposition: attachment; filename="xen-backends-kzalloc.patch" Subject: backends: use kzalloc() in favor of kmalloc()+memset()=0A=0AThis = fixes the problem of three of those four memset()-s having=0Aimproper size = arguments passed: Sizeof a pointer-typed expression=0Areturns the size of = the pointer, not that of the pointed to data.=0A=0AReported-by: Julia = Lawall =0ASigned-off-by: Jan Beulich = =0A=0A--- a/drivers/xen/blkback/blkback.c=0A+++ b/drivers/xen/blkback/blkba= ck.c=0A@@ -633,7 +633,7 @@ static int __init blkif_init(void)=0A =0A = mmap_pages =3D blkif_reqs * BLKIF_MAX_SEGMENTS_PER_REQUEST;=0A =0A- = pending_reqs =3D kmalloc(sizeof(pending_reqs[0]) *=0A+ pending_req= s =3D kzalloc(sizeof(pending_reqs[0]) *=0A = blkif_reqs, GFP_KERNEL);=0A pending_grant_handles =3D = kmalloc(sizeof(pending_grant_handles[0]) *=0A = mmap_pages, GFP_KERNEL);=0A@@ -650,7 +650,6 @@ static int __init blkif_init= (void)=0A =0A blkif_interface_init();=0A =0A- memset(pending_reqs, 0, = sizeof(pending_reqs));=0A INIT_LIST_HEAD(&pending_free);=0A =0A = for (i =3D 0; i < blkif_reqs; i++)=0A--- a/drivers/xen/scsiback/emulate.c= =0A+++ b/drivers/xen/scsiback/emulate.c=0A@@ -246,13 +246,11 @@ static = void __report_luns(pending_req_t =0A alloc_len =3D sizeof(struct = scsi_lun) * alloc_luns=0A + VSCSI_REPORT_LUNS= _HEADER;=0A retry:=0A- if ((buff =3D kmalloc(alloc_len, GFP_KERNEL)) = =3D=3D NULL) {=0A+ if ((buff =3D kzalloc(alloc_len, GFP_KERNEL)) = =3D=3D NULL) {=0A printk(KERN_ERR "scsiback:%s kmalloc = err\n", __FUNCTION__);=0A goto fail;=0A }=0A =0A- = memset(buff, 0, alloc_len);=0A-=0A one_lun =3D (struct scsi_lun *) = &buff[8];=0A spin_lock_irqsave(&info->v2p_lock, flags);=0A list_for_ea= ch_entry(entry, head, l) {=0A--- a/drivers/xen/scsiback/scsiback.c=0A+++ = b/drivers/xen/scsiback/scsiback.c=0A@@ -687,7 +687,7 @@ static int __init = scsiback_init(void)=0A =0A mmap_pages =3D vscsiif_reqs * VSCSIIF_SG_TA= BLESIZE;=0A =0A- pending_reqs =3D kmalloc(sizeof(pending_re= qs[0]) *=0A+ pending_reqs =3D kzalloc(sizeof(pending_reqs[0]) = *=0A vscsiif_reqs, GFP_KERNEL);=0A = pending_grant_handles =3D kmalloc(sizeof(pending_grant_handles[0]) *=0A = mmap_pages, GFP_KERNEL);=0A@@ -702,7 = +702,6 @@ static int __init scsiback_init(void)=0A if (scsiback_interf= ace_init() < 0)=0A goto out_of_kmem;=0A =0A- memset(pend= ing_reqs, 0, sizeof(pending_reqs));=0A INIT_LIST_HEAD(&pending_free);=0A = =0A for (i =3D 0; i < vscsiif_reqs; i++)=0A--- a/drivers/xen/usbback/us= bback.c=0A+++ b/drivers/xen/usbback/usbback.c=0A@@ -1105,7 +1105,7 @@ = static int __init usbback_init(void)=0A return -ENODEV;=0A = =0A mmap_pages =3D usbif_reqs * USBIF_MAX_SEGMENTS_PER_REQUEST;=0A- = pending_reqs =3D kmalloc(sizeof(pending_reqs[0]) *=0A+ pending_reqs =3D = kzalloc(sizeof(pending_reqs[0]) *=0A usbif_reqs, = GFP_KERNEL);=0A pending_grant_handles =3D kmalloc(sizeof(pending_gr= ant_handles[0]) *=0A mmap_pages, GFP_KERNEL);=0A@@ = -1119,7 +1119,6 @@ static int __init usbback_init(void)=0A for (i =3D = 0; i < mmap_pages; i++)=0A pending_grant_handles[i] =3D = USBBACK_INVALID_HANDLE;=0A =0A- memset(pending_reqs, 0, sizeof(pending_reqs= ));=0A INIT_LIST_HEAD(&pending_free);=0A =0A for (i =3D 0; i < = usbif_reqs; i++)=0A --=__Part1A352BB3.0__= Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel --=__Part1A352BB3.0__=-- From xen-devel-bounces@lists.xensource.com Fri Sep 16 01:26:10 2011 Return-path: Envelope-to: www-data@lists.xensource.com Delivery-date: Fri, 16 Sep 2011 01:26:10 -0700 Received: from localhost ([127.0.0.1] helo=lists.colo.xensource.com) by lists.xensource.com with esmtp (Exim 4.43) id 1R4TkQ-0000pg-55; Fri, 16 Sep 2011 01:26:10 -0700 Received: from mail21.messagelabs.com ([85.158.143.35]) by lists.xensource.com with esmtp (Exim 4.43) id 1R4TjR-0000dB-Pa for xen-devel@lists.xensource.com; Fri, 16 Sep 2011 01:25:10 -0700 X-Env-Sender: konrad@oracle.com X-Msg-Ref: server-10.tower-21.messagelabs.com!1316161490!54324496!1 X-Originating-IP: [148.87.113.117] X-StarScan-Version: 6.4.1; banners=-,-,- X-VirusChecked: Checked Received: (qmail 9155 invoked from network); 16 Sep 2011 08:24:52 -0000 Received: from rcsinet15.oracle.com (HELO rcsinet15.oracle.com) (148.87.113.117) by server-10.tower-21.messagelabs.com with DHE-RSA-AES256-SHA encrypted SMTP; 16 Sep 2011 08:24:52 -0000 Received: from rtcsinet21.oracle.com (rtcsinet21.oracle.com [66.248.204.29]) by rcsinet15.oracle.com (Switch-3.4.4/Switch-3.4.4) with ESMTP id p8G8P2he015106 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Fri, 16 Sep 2011 08:25:04 GMT Received: from acsmt356.oracle.com (acsmt356.oracle.com [141.146.40.156]) by rtcsinet21.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id p8G8P0G6016451 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 16 Sep 2011 08:25:01 GMT Received: from abhmt117.oracle.com (abhmt117.oracle.com [141.146.116.69]) by acsmt356.oracle.com (8.12.11.20060308/8.12.11) with ESMTP id p8G8Oslq027891; Fri, 16 Sep 2011 03:24:54 -0500 Received: from oracle.com (/209.6.55.207) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Fri, 16 Sep 2011 01:24:54 -0700 Received: by oracle.com (Postfix, from userid 1000) id 7021D1361; Fri, 16 Sep 2011 04:24:56 -0400 (EDT) Date: Fri, 16 Sep 2011 04:24:56 -0400 From: Konrad Rzeszutek Wilk To: Shaun Reitan Subject: Re: [Xen-devel] Re: kernel BUG at mm/swapfile.c:2527! Message-ID: <20110916082456.GA884@phenom.oracle.com> References: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.21 (2010-09-15) X-Source-IP: rtcsinet21.oracle.com [66.248.204.29] X-CT-RefId: str=0001.0A090207.4E7307E0.0121,ss=1,re=0.000,fgs=0 Cc: xen-devel@lists.xensource.com X-BeenThere: xen-devel@lists.xensource.com X-Mailman-Version: 2.1.5 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xensource.com Errors-To: xen-devel-bounces@lists.xensource.com On Thu, Sep 15, 2011 at 12:52:42PM -0700, Shaun Reitan wrote: > I can just about reproduce this bug on the fly, a PCI compliance > scan seams to be triggering it every time. Let me know what you > guys need! How do I reproduce it? Is the PCI compliance easily available? Is there any chance we can get access to the physical box to figure out what is happening? > > ~Shaun > > > _______________________________________________ > Xen-devel mailing list > Xen-devel@lists.xensource.com > http://lists.xensource.com/xen-devel _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel From xen-devel-bounces@lists.xensource.com Fri Sep 16 01:36:38 2011 Return-path: Envelope-to: www-data@lists.xensource.com Delivery-date: Fri, 16 Sep 2011 01:36:38 -0700 Received: from localhost ([127.0.0.1] helo=lists.colo.xensource.com) by lists.xensource.com with esmtp (Exim 4.43) id 1R4TuX-0001QN-Li; Fri, 16 Sep 2011 01:36:37 -0700 Received: from mail27.messagelabs.com ([193.109.254.147]) by lists.xensource.com with esmtp (Exim 4.43) id 1R4Ttz-0001E3-45 for xen-devel@lists.xensource.com; Fri, 16 Sep 2011 01:36:03 -0700 X-Env-Sender: konrad@oracle.com X-Msg-Ref: server-4.tower-27.messagelabs.com!1316162141!40490718!1 X-Originating-IP: [148.87.113.117] X-StarScan-Version: 6.4.1; banners=-,-,- X-VirusChecked: Checked Received: (qmail 24485 invoked from network); 16 Sep 2011 08:35:42 -0000 Received: from rcsinet15.oracle.com (HELO rcsinet15.oracle.com) (148.87.113.117) by server-4.tower-27.messagelabs.com with DHE-RSA-AES256-SHA encrypted SMTP; 16 Sep 2011 08:35:42 -0000 Received: from acsinet22.oracle.com (acsinet22.oracle.com [141.146.126.238]) by rcsinet15.oracle.com (Switch-3.4.4/Switch-3.4.4) with ESMTP id p8G8Zc4E002728 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Fri, 16 Sep 2011 08:35:40 GMT Received: from acsmt358.oracle.com (acsmt358.oracle.com [141.146.40.158]) by acsinet22.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id p8G8ZbFP021797 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 16 Sep 2011 08:35:38 GMT Received: from abhmt113.oracle.com (abhmt113.oracle.com [141.146.116.65]) by acsmt358.oracle.com (8.12.11.20060308/8.12.11) with ESMTP id p8G8ZWmW012221; Fri, 16 Sep 2011 03:35:32 -0500 Received: from oracle.com (/209.6.55.207) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Fri, 16 Sep 2011 01:35:31 -0700 Received: by oracle.com (Postfix, from userid 1000) id 74C631361; Fri, 16 Sep 2011 04:35:33 -0400 (EDT) Date: Fri, 16 Sep 2011 04:35:33 -0400 From: Konrad Rzeszutek Wilk To: M A Young Subject: Re: [Xen-devel] Re: F16, yum install xen, run grub2 or grubby as needed? Message-ID: <20110916083533.GC884@phenom.oracle.com> References: <20110915154621.GA21580@phenom.oracle.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.21 (2010-09-15) X-Source-IP: acsinet22.oracle.com [141.146.126.238] X-Auth-Type: Internal IP X-CT-RefId: str=0001.0A090209.4E730A5D.0040:SCFMA922111,ss=1,re=-4.000,fgs=0 Cc: xen-devel@lists.xensource.com X-BeenThere: xen-devel@lists.xensource.com X-Mailman-Version: 2.1.5 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xensource.com Errors-To: xen-devel-bounces@lists.xensource.com On Thu, Sep 15, 2011 at 10:29:50PM +0100, M A Young wrote: > On Thu, 15 Sep 2011, Konrad Rzeszutek Wilk wrote: > > >Hey Michael, > > > >I was playing today with https://admin.fedoraproject.org/updates/grubby-8.2-1.fc16?_csrf_token=014c2b18c3b6e843699e9ef1e56cf9726c5c4fc2 > >and https://admin.fedoraproject.org/updates/grub2-1.99-6.fc16 which make the grub.cfg have the > >correct entries of Xen and Linux. > > > >And realized that I had to manually do: > > > >grub2-mkconfig > /boot/grub2/grub.cfg > > > >which ends up doing the new stanza.. but in some sense I think > >it makes senee for the Xen script to actually call this. > > > >Thoughts? > > It probably makes sense to have a post-install/post-uninstall script > in the xen-hypervisor RPM to run this. The updated grub2 creates a > set of entries for each of xen-4.1.1.gz and its two symbolic links > xen-4.1.gz and xen.gz which is a bit untidy, so perhaps it makes > sense to remove the symbolic links. Taking this a step further.. what about re-ordering the boot order? Say 'yum install xen-hypervisor' (which implies that the user has a good idea of what Xen is), would make sure that the Xen 4.1.1 stanze is called before the baremetal? Not sure what it would entail (modifying /etc/default/grub?) and whether that is actually OK? _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel From xen-devel-bounces@lists.xensource.com Fri Sep 16 01:44:24 2011 Return-path: Envelope-to: www-data@lists.xensource.com Delivery-date: Fri, 16 Sep 2011 01:44:24 -0700 Received: from localhost ([127.0.0.1] helo=lists.colo.xensource.com) by lists.xensource.com with esmtp (Exim 4.43) id 1R4U24-0001xI-OY; Fri, 16 Sep 2011 01:44:24 -0700 Received: from mail216.messagelabs.com ([85.158.143.99]) by lists.xensource.com with esmtp (Exim 4.43) id 1R4U1F-0001kw-OR; Fri, 16 Sep 2011 01:43:34 -0700 X-Env-Sender: konrad@oracle.com X-Msg-Ref: server-13.tower-216.messagelabs.com!1316162609!18500034!1 X-Originating-IP: [148.87.113.117] X-StarScan-Version: 6.4.1; banners=-,-,- X-VirusChecked: Checked Received: (qmail 17376 invoked from network); 16 Sep 2011 08:43:30 -0000 Received: from rcsinet15.oracle.com (HELO rcsinet15.oracle.com) (148.87.113.117) by server-13.tower-216.messagelabs.com with DHE-RSA-AES256-SHA encrypted SMTP; 16 Sep 2011 08:43:30 -0000 Received: from rtcsinet21.oracle.com (rtcsinet21.oracle.com [66.248.204.29]) by rcsinet15.oracle.com (Switch-3.4.4/Switch-3.4.4) with ESMTP id p8G8hFBn018065 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Fri, 16 Sep 2011 08:43:17 GMT Received: from acsmt357.oracle.com (acsmt357.oracle.com [141.146.40.157]) by rtcsinet21.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id p8G8hDAQ015370 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 16 Sep 2011 08:43:14 GMT Received: from abhmt116.oracle.com (abhmt116.oracle.com [141.146.116.68]) by acsmt357.oracle.com (8.12.11.20060308/8.12.11) with ESMTP id p8G8h8vG007436; Fri, 16 Sep 2011 03:43:08 -0500 Received: from oracle.com (/209.6.55.207) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Fri, 16 Sep 2011 01:43:07 -0700 Received: by oracle.com (Postfix, from userid 1000) id 0062B1361; Fri, 16 Sep 2011 04:43:08 -0400 (EDT) Date: Fri, 16 Sep 2011 04:43:08 -0400 From: Konrad Rzeszutek Wilk To: Adam Williamson Message-ID: <20110916084308.GD884@phenom.oracle.com> References: <20110914112552.GP12984@reaktio.net> <20110914142522.GA16956@phenom.oracle.com> <20110914144539.GR12984@reaktio.net> <20110915151041.GA4453@imp.local> <1316126290.5689.3.camel@adam> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <1316126290.5689.3.camel@adam> User-Agent: Mutt/1.5.21 (2010-09-15) X-Source-IP: rtcsinet21.oracle.com [66.248.204.29] X-CT-RefId: str=0001.0A090207.4E730C26.0012,ss=1,re=0.000,fgs=0 Cc: Development discussions related to Fedora , xen@lists.fedoraproject.org, xen-devel@lists.xensource.com, lars.kurth@xen.org, virt@lists.fedoraproject.org, xen-users@lists.xensource.com Subject: [Xen-devel] Re: Virtualization Test Day for F16 and Xen X-BeenThere: xen-devel@lists.xensource.com X-Mailman-Version: 2.1.5 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xensource.com Errors-To: xen-devel-bounces@lists.xensource.com On Thu, Sep 15, 2011 at 03:38:09PM -0700, Adam Williamson wrote: > On Thu, 2011-09-15 at 10:10 -0500, W. Michael Petullo wrote: > > >> There are known bugs in FC15/FC16 that have been filled some time ago that > > >> folks will sadly run into: 728775, 658387 and 668063 > > >> > > >> Fortunatly the bugs have patches attached and the files to be modified are shell scripts. > > > > > Yep, links here: > > > > > > https://bugzilla.redhat.com/show_bug.cgi?id=728775 > > > > The Fedora update system reports this is fixed in grub2-1.99-6.fc16. > > > > > https://bugzilla.redhat.com/show_bug.cgi?id=658387 > > > > Peter Jones submitted a new grubby package yesterday. This seems to fix > > bug #658387 (i.e., new-kernel-pkg creates a Dom0-style grub.cfg entry > > if /etc/sysconfig/kernel contains "HYPERVISOR=/boot/xen.gz"). > > > > I have not yet tested this on Fedora 16. However, I did test on Fedora > > 15. In this case, bug #668063 is still in effect. That is, grubby creates > > most of a GRUB record, but the "module initramfs-..." entry is missing. > > > > Has anyone yet tested this new grubby package on Fedora 16 yet? Does > > using GRUB 2 makes #668063 irrelevant? I believe so (the irrelevant part). But the functionality part of grubby picking up /etc/sysconfig/kernel and making that kernel the default is not in Grub2 - so not sure how that can be addressed. > > > > > https://bugzilla.redhat.com/show_bug.cgi?id=668063 > > > > I just added some more description to this bug. > > So, there's a meta-point here: we currently 'require' Beta releases to > boot as guests on Xen hosts: > > "The release must boot successfully as a virtual guest in a situation > where the virtual host is running a supported Xen implementation" > > I really don't have much knowledge of Xen and haven't followed this > discussion closely, but do any currently-known bugs prevent this? If so, > please flag them up so they can be considered as Beta blockers...thanks! Somehow the xen-kbdfront driver is not included in the initrd image (I think) - and we end with anaconda but can't type anything. I've been trying to figure out how to inject said module in the install initrd to see if that is really the problem but running in roadblocks (like xz 5.1.1alpha or 5.0.3 complains about corrupt image, or I've no idea how to make driver disks). Any ideas? _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel From xen-devel-bounces@lists.xensource.com Fri Sep 16 02:14:40 2011 Return-path: Envelope-to: www-data@lists.xensource.com Delivery-date: Fri, 16 Sep 2011 02:14:40 -0700 Received: from localhost ([127.0.0.1] helo=lists.colo.xensource.com) by lists.xensource.com with esmtp (Exim 4.43) id 1R4UVM-0003id-6C; Fri, 16 Sep 2011 02:14:40 -0700 Received: from mail216.messagelabs.com ([85.158.143.99]) by lists.xensource.com with smtp (Exim 4.43) id 1R4UTx-0003VX-Ey for xen-devel@lists.xensource.com; Fri, 16 Sep 2011 02:13:17 -0700 X-Env-Sender: imammedo@redhat.com X-Msg-Ref: server-7.tower-216.messagelabs.com!1316164389!18491294!1 X-Originating-IP: [209.132.183.28] X-StarScan-Version: 6.4.1; banners=-,-,- X-VirusChecked: Checked Received: (qmail 2601 invoked from network); 16 Sep 2011 09:13:10 -0000 Received: from mx1.redhat.com (HELO mx1.redhat.com) (209.132.183.28) by server-7.tower-216.messagelabs.com with SMTP; 16 Sep 2011 09:13:10 -0000 Received: from int-mx01.intmail.prod.int.phx2.redhat.com (int-mx01.intmail.prod.int.phx2.redhat.com [10.5.11.11]) by mx1.redhat.com (8.14.4/8.14.4) with ESMTP id p8G9D8bK020430 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK) for ; Fri, 16 Sep 2011 05:13:08 -0400 Received: from ns3.rdu.redhat.com (ns3.rdu.redhat.com [10.11.255.199]) by int-mx01.intmail.prod.int.phx2.redhat.com (8.13.8/8.13.8) with ESMTP id p8G9D8Zi001683 for ; Fri, 16 Sep 2011 05:13:08 -0400 Received: from nial.usersys.redhat.com (dhcp-1-247.brq.redhat.com [10.34.1.247]) by ns3.rdu.redhat.com (8.13.8/8.13.8) with ESMTP id p8G9D7kj008322 for ; Fri, 16 Sep 2011 05:13:07 -0400 Message-ID: <4E731322.7080909@redhat.com> Date: Fri, 16 Sep 2011 11:13:06 +0200 From: Igor Mammedov User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.2.22) Gecko/20110904 Red Hat/3.1.14-1.el6_1 Lightning/1.0b2 Thunderbird/3.1.14 MIME-Version: 1.0 To: xen-devel@lists.xensource.com Subject: Re: [Xen-devel] [PATCH 0/2] Prevent host crash after executing in dom0 'rmmod isci; modprobe isci' References: <1315921459-17059-1-git-send-email-imammedo@redhat.com> In-Reply-To: <1315921459-17059-1-git-send-email-imammedo@redhat.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Scanned-By: MIMEDefang 2.67 on 10.5.11.11 X-BeenThere: xen-devel@lists.xensource.com X-Mailman-Version: 2.1.5 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xensource.com Errors-To: xen-devel-bounces@lists.xensource.com On 09/13/2011 03:44 PM, Igor Mammedov wrote: > [PATCH 1/2] xen: Clear IRQ_GUEST bit from irq_desc status if its action is NULL > [PATCH 2/2] xen: remove duplicate code and keep IRQ_GUEST flag reset at one place > > Changes since first patch "xen: Clear IRQ_GUEST bit from irq_desc status if its action is NULL" > > - split patch in 2, fix (1) and cleanup (2) > - move 'unbind' label after 'bound = 1;' > Self-NACK this one. I'll post version 3 that might be better. -- Thanks, Igor _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel From xen-devel-bounces@lists.xensource.com Fri Sep 16 02:25:35 2011 Return-path: Envelope-to: www-data@lists.xensource.com Delivery-date: Fri, 16 Sep 2011 02:25:35 -0700 Received: from localhost ([127.0.0.1] helo=lists.colo.xensource.com) by lists.xensource.com with esmtp (Exim 4.43) id 1R4Ufv-0004Gi-RR; Fri, 16 Sep 2011 02:25:35 -0700 Received: from mail182.messagelabs.com ([85.158.139.83]) by lists.xensource.com with smtp (Exim 4.43) id 1R4UfK-00043t-H5 for xen-devel@lists.xensource.com; Fri, 16 Sep 2011 02:24:58 -0700 X-Env-Sender: imammedo@redhat.com X-Msg-Ref: server-9.tower-182.messagelabs.com!1316165094!18550478!1 X-Originating-IP: [209.132.183.28] X-StarScan-Version: 6.4.1; banners=-,-,- X-VirusChecked: Checked Received: (qmail 8681 invoked from network); 16 Sep 2011 09:24:55 -0000 Received: from mx1.redhat.com (HELO mx1.redhat.com) (209.132.183.28) by server-9.tower-182.messagelabs.com with SMTP; 16 Sep 2011 09:24:55 -0000 Received: from int-mx01.intmail.prod.int.phx2.redhat.com (int-mx01.intmail.prod.int.phx2.redhat.com [10.5.11.11]) by mx1.redhat.com (8.14.4/8.14.4) with ESMTP id p8G9OqZs019990 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Fri, 16 Sep 2011 05:24:52 -0400 Received: from nial.brq.redhat.com (dhcp-1-247.brq.redhat.com [10.34.1.247]) by int-mx01.intmail.prod.int.phx2.redhat.com (8.13.8/8.13.8) with ESMTP id p8G9OoSO005091; Fri, 16 Sep 2011 05:24:51 -0400 From: Igor Mammedov To: xen-devel@lists.xensource.com Date: Fri, 16 Sep 2011 11:24:47 +0200 Message-Id: <1316165087-9540-1-git-send-email-imammedo@redhat.com> X-Scanned-By: MIMEDefang 2.67 on 10.5.11.11 Cc: andrew.cooper3@citrix.com, JBeulich@suse.com, konrad.wilk@oracle.com Subject: [Xen-devel] [PATCH v3] Clear IRQ_GUEST in irq_desc->status when setting action to NULL. X-BeenThere: xen-devel@lists.xensource.com X-Mailman-Version: 2.1.5 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xensource.com Errors-To: xen-devel-bounces@lists.xensource.com Looking more closely at usage of action field with relation to IRQ_GUEST flag. It appears that set IRQ_GUEST implies that action is not NULL. As result it is not safe to set action to NULL and leave IRQ_GUEST set. Hence IRQ_GUEST should be cleared in dynamic_irq_cleanup where action is set to NULL. An addition remove BUGON at __pirq_guest_unbind that appears to be bogus and not needed anymore. Thanks Paolo Bonzini for NACKing previous patch, and pointing at the correct solution. Please review. Signed-off-by: Igor Mammedov diff --git a/xen/arch/x86/irq.c b/xen/arch/x86/irq.c --- a/xen/arch/x86/irq.c +++ b/xen/arch/x86/irq.c @@ -192,6 +192,7 @@ static void dynamic_irq_cleanup(unsigned spin_lock_irqsave(&desc->lock, flags); desc->status |= IRQ_DISABLED; + desc->status &= ~IRQ_GUEST; desc->handler->shutdown(irq); action = desc->action; desc->action = NULL; @@ -1465,8 +1466,6 @@ static irq_guest_action_t *__pirq_guest_ cpumask_t cpu_eoi_map; int i; - BUG_ON(!(desc->status & IRQ_GUEST)); - action = (irq_guest_action_t *)desc->action; irq = desc - irq_desc; _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel From xen-devel-bounces@lists.xensource.com Fri Sep 16 03:20:16 2011 Return-path: Envelope-to: www-data@lists.xensource.com Delivery-date: Fri, 16 Sep 2011 03:20:16 -0700 Received: from localhost ([127.0.0.1] helo=lists.colo.xensource.com) by lists.xensource.com with esmtp (Exim 4.43) id 1R4VWp-0005vD-UO; Fri, 16 Sep 2011 03:20:16 -0700 Received: from mail21.messagelabs.com ([85.158.143.35]) by lists.xensource.com with esmtp (Exim 4.43) id 1R4VW0-0005ij-7S for xen-devel@lists.xensource.com; Fri, 16 Sep 2011 03:19:24 -0700 X-Env-Sender: JBeulich@suse.com X-Msg-Ref: server-13.tower-21.messagelabs.com!1316168355!49152842!1 X-Originating-IP: [130.57.49.28] X-StarScan-Version: 6.4.1; banners=-,-,- X-VirusChecked: Checked Received: (qmail 23820 invoked from network); 16 Sep 2011 10:19:15 -0000 Received: from nat28.tlf.novell.com (HELO nat28.tlf.novell.com) (130.57.49.28) by server-13.tower-21.messagelabs.com with DHE-RSA-AES256-SHA encrypted SMTP; 16 Sep 2011 10:19:15 -0000 Received: from EMEA1-MTA by nat28.tlf.novell.com with Novell_GroupWise; Fri, 16 Sep 2011 11:19:20 +0100 Message-Id: <4E733EC8020000780005678D@nat28.tlf.novell.com> X-Mailer: Novell GroupWise Internet Agent 8.0.1 Date: Fri, 16 Sep 2011 11:19:20 +0100 From: "Jan Beulich" To: "xen-devel@lists.xensource.com" Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="=__PartCFE0FFB8.1__=" Cc: Joseph Cihula Subject: [Xen-devel] [PATCH] x86/tboot: make resume error messages visible X-BeenThere: xen-devel@lists.xensource.com X-Mailman-Version: 2.1.5 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xensource.com Errors-To: xen-devel-bounces@lists.xensource.com This is a MIME message. If you are reading this text, you may want to consider changing to a mail reader or gateway that understands how to properly handle MIME multipart messages. --=__PartCFE0FFB8.1__= Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: quoted-printable Content-Disposition: inline With tboot_s3_resume() running before console_resume(), the error messages so far printed by it are mostly guaranteed to go into nirwana. Latch MACs into a static variable instead, and issue the messages right before calling panic(). Signed-off-by: Jan Beulich --- a/xen/arch/x86/acpi/power.c +++ b/xen/arch/x86/acpi/power.c @@ -193,7 +193,7 @@ static int enter_state(u32 state) printk(XENLOG_INFO "Finishing wakeup from ACPI S%d state.\n", state); =20 if ( (state =3D=3D ACPI_STATE_S3) && error ) - panic("Memory integrity was lost on resume (%d)\n", error); + tboot_s3_error(error); =20 done: spin_debug_enable(); --- a/xen/arch/x86/tboot.c +++ b/xen/arch/x86/tboot.c @@ -481,35 +481,50 @@ int __init tboot_parse_dmar_table(acpi_t return rc; } =20 +static vmac_t orig_mac, resume_mac; + int tboot_s3_resume(void) { - vmac_t mac; - if ( !tboot_in_measured_env() ) return 0; =20 /* need to do these in reverse order of shutdown */ - tboot_gen_xenheap_integrity(g_tboot_shared->s3_key, &mac); - printk("MAC for xenheap before S3 is: 0x%08"PRIx64"\n", xenheap_mac); - printk("MAC for xenheap after S3 is: 0x%08"PRIx64"\n", mac); - if ( mac !=3D xenheap_mac ) + tboot_gen_xenheap_integrity(g_tboot_shared->s3_key, &resume_mac); + orig_mac =3D xenheap_mac; + if ( resume_mac !=3D xenheap_mac ) return -1; =20 - tboot_gen_frametable_integrity(g_tboot_shared->s3_key, &mac); - printk("MAC for frametable before S3 is: 0x%08"PRIx64"\n", frametable_= mac); - printk("MAC for frametable after S3 is: 0x%08"PRIx64"\n", mac); - if ( mac !=3D frametable_mac ) + tboot_gen_frametable_integrity(g_tboot_shared->s3_key, &resume_mac); + orig_mac =3D frametable_mac; + if ( resume_mac !=3D frametable_mac ) return -2; =20 - tboot_gen_domain_integrity(g_tboot_shared->s3_key, &mac); - printk("MAC for domains before S3 is: 0x%08"PRIx64"\n", domain_mac); - printk("MAC for domains after S3 is: 0x%08"PRIx64"\n", mac); - if ( mac !=3D domain_mac ) + tboot_gen_domain_integrity(g_tboot_shared->s3_key, &resume_mac); + orig_mac =3D domain_mac; + if ( resume_mac !=3D domain_mac ) return -3; =20 return 0; } =20 +void tboot_s3_error(int error) +{ + const char *what =3D "???"; + + BUG_ON(!error || !tboot_in_measured_env()); + + switch ( error ) + { + case -1: what =3D "Xen heap"; break; + case -2: what =3D "frame table"; break; + case -3: what =3D "domains"; break; + } + + printk("MAC for %s before S3 is: 0x%08"PRIx64"\n", what, orig_mac); + printk("MAC for %s after S3 is: 0x%08"PRIx64"\n", what, resume_mac); + panic("Memory integrity was lost on resume (%d)\n", error); +} + /* * Local variables: * mode: C --- a/xen/include/asm-x86/tboot.h +++ b/xen/include/asm-x86/tboot.h @@ -119,6 +119,7 @@ int tboot_in_measured_env(void); int tboot_protect_mem_regions(void); int tboot_parse_dmar_table(acpi_table_handler dmar_handler); int tboot_s3_resume(void); +void tboot_s3_error(int error); =20 #endif /* __TBOOT_H__ */ =20 --=__PartCFE0FFB8.1__= Content-Type: text/plain; name="tboot-resume-failure.patch" Content-Transfer-Encoding: quoted-printable Content-Disposition: attachment; filename="tboot-resume-failure.patch" With tboot_s3_resume() running before console_resume(), the error=0Amessage= s so far printed by it are mostly guaranteed to go into nirwana.=0ALatch = MACs into a static variable instead, and issue the messages=0Aright before = calling panic().=0A=0ASigned-off-by: Jan Beulich =0A=0A-= -- a/xen/arch/x86/acpi/power.c=0A+++ b/xen/arch/x86/acpi/power.c=0A@@ = -193,7 +193,7 @@ static int enter_state(u32 state)=0A printk(XENLOG_INF= O "Finishing wakeup from ACPI S%d state.\n", state);=0A =0A if ( = (state =3D=3D ACPI_STATE_S3) && error )=0A- panic("Memory integrity = was lost on resume (%d)\n", error);=0A+ tboot_s3_error(error);=0A = =0A done:=0A spin_debug_enable();=0A--- a/xen/arch/x86/tboot.c=0A+++ = b/xen/arch/x86/tboot.c=0A@@ -481,35 +481,50 @@ int __init tboot_parse_dmar_= table(acpi_t=0A return rc;=0A }=0A =0A+static vmac_t orig_mac, = resume_mac;=0A+=0A int tboot_s3_resume(void)=0A {=0A- vmac_t mac;=0A-=0A= if ( !tboot_in_measured_env() )=0A return 0;=0A =0A /* = need to do these in reverse order of shutdown */=0A- tboot_gen_xenheap_i= ntegrity(g_tboot_shared->s3_key, &mac);=0A- printk("MAC for xenheap = before S3 is: 0x%08"PRIx64"\n", xenheap_mac);=0A- printk("MAC for = xenheap after S3 is: 0x%08"PRIx64"\n", mac);=0A- if ( mac !=3D = xenheap_mac )=0A+ tboot_gen_xenheap_integrity(g_tboot_shared->s3_key, = &resume_mac);=0A+ orig_mac =3D xenheap_mac;=0A+ if ( resume_mac !=3D = xenheap_mac )=0A return -1;=0A =0A- tboot_gen_frametable_integri= ty(g_tboot_shared->s3_key, &mac);=0A- printk("MAC for frametable before = S3 is: 0x%08"PRIx64"\n", frametable_mac);=0A- printk("MAC for frametable= after S3 is: 0x%08"PRIx64"\n", mac);=0A- if ( mac !=3D frametable_mac = )=0A+ tboot_gen_frametable_integrity(g_tboot_shared->s3_key, &resume_mac= );=0A+ orig_mac =3D frametable_mac;=0A+ if ( resume_mac !=3D = frametable_mac )=0A return -2;=0A =0A- tboot_gen_domain_integrit= y(g_tboot_shared->s3_key, &mac);=0A- printk("MAC for domains before S3 = is: 0x%08"PRIx64"\n", domain_mac);=0A- printk("MAC for domains after S3 = is: 0x%08"PRIx64"\n", mac);=0A- if ( mac !=3D domain_mac )=0A+ = tboot_gen_domain_integrity(g_tboot_shared->s3_key, &resume_mac);=0A+ = orig_mac =3D domain_mac;=0A+ if ( resume_mac !=3D domain_mac )=0A = return -3;=0A =0A return 0;=0A }=0A =0A+void tboot_s3_error(int = error)=0A+{=0A+ const char *what =3D "???";=0A+=0A+ BUG_ON(!error || = !tboot_in_measured_env());=0A+=0A+ switch ( error )=0A+ {=0A+ = case -1: what =3D "Xen heap"; break;=0A+ case -2: what =3D "frame = table"; break;=0A+ case -3: what =3D "domains"; break;=0A+ }=0A+=0A+ = printk("MAC for %s before S3 is: 0x%08"PRIx64"\n", what, orig_mac);=0A+ = printk("MAC for %s after S3 is: 0x%08"PRIx64"\n", what, resume_mac);=0A+= panic("Memory integrity was lost on resume (%d)\n", error);=0A+}=0A+=0A= /*=0A * Local variables:=0A * mode: C=0A--- a/xen/include/asm-x86/tboot.= h=0A+++ b/xen/include/asm-x86/tboot.h=0A@@ -119,6 +119,7 @@ int tboot_in_me= asured_env(void);=0A int tboot_protect_mem_regions(void);=0A int tboot_pars= e_dmar_table(acpi_table_handler dmar_handler);=0A int tboot_s3_resume(void)= ;=0A+void tboot_s3_error(int error);=0A =0A #endif /* __TBOOT_H__ */=0A =0A --=__PartCFE0FFB8.1__= Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel --=__PartCFE0FFB8.1__=-- From xen-devel-bounces@lists.xensource.com Fri Sep 16 03:21:11 2011 Return-path: Envelope-to: www-data@lists.xensource.com Delivery-date: Fri, 16 Sep 2011 03:21:11 -0700 Received: from localhost ([127.0.0.1] helo=lists.colo.xensource.com) by lists.xensource.com with esmtp (Exim 4.43) id 1R4VXi-0006I5-G1; Fri, 16 Sep 2011 03:21:10 -0700 Received: from mail27.messagelabs.com ([193.109.254.147]) by lists.xensource.com with smtp (Exim 4.43) id 1R4VWi-0005u0-TA for xen-devel@lists.xensource.com; Fri, 16 Sep 2011 03:20:09 -0700 X-Env-Sender: jinsong.liu@intel.com X-Msg-Ref: server-6.tower-27.messagelabs.com!1316168386!49218703!1 X-Originating-IP: [143.182.124.37] X-StarScan-Version: 6.4.1; banners=-,-,- X-VirusChecked: Checked Received: (qmail 21557 invoked from network); 16 Sep 2011 10:19:47 -0000 Received: from mga14.intel.com (HELO mga14.intel.com) (143.182.124.37) by server-6.tower-27.messagelabs.com with SMTP; 16 Sep 2011 10:19:47 -0000 Received: from azsmga001.ch.intel.com ([10.2.17.19]) by azsmga102.ch.intel.com with ESMTP; 16 Sep 2011 03:20:04 -0700 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="4.68,392,1312182000"; d="scan'208";a="49496177" Received: from pgsmsx602.gar.corp.intel.com ([10.221.43.81]) by azsmga001.ch.intel.com with ESMTP; 16 Sep 2011 03:20:04 -0700 Received: from pgsmsx103.gar.corp.intel.com (10.221.44.82) by pgsmsx602.gar.corp.intel.com (10.221.43.81) with Microsoft SMTP Server (TLS) id 8.2.255.0; Fri, 16 Sep 2011 18:19:37 +0800 Received: from shsmsx602.ccr.corp.intel.com (10.239.4.104) by PGSMSX103.gar.corp.intel.com (10.221.44.82) with Microsoft SMTP Server (TLS) id 14.1.323.3; Fri, 16 Sep 2011 18:19:36 +0800 Received: from shsmsx502.ccr.corp.intel.com ([10.239.4.96]) by SHSMSX602.ccr.corp.intel.com ([10.239.4.104]) with mapi; Fri, 16 Sep 2011 18:19:36 +0800 From: "Liu, Jinsong" To: Keir Fraser , "xen-devel@lists.xensource.com" Date: Fri, 16 Sep 2011 18:19:33 +0800 Thread-Topic: Backporting cpuid faulting to Xen-4.1.0 Thread-Index: Acx0WiEbENBnkoS7T5OXYJSbSkwJNQ== Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "Shan, Haitao" , "Li, Xin" Subject: [Xen-devel] Backporting cpuid faulting to Xen-4.1.0 X-BeenThere: xen-devel@lists.xensource.com X-Mailman-Version: 2.1.5 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xensource.com Errors-To: xen-devel-bounces@lists.xensource.com Keir, In July we implemented cpuid faulting feature, and checked in xen-unstable = tree as c/s 23653/23654/23655. Today we patched them to xen-4.1.0, test result shows it's OK to work with = xen-4.1.0. So how about backporting this feature to xen-4.1.0? Thanks, Jinsong= _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel From xen-devel-bounces@lists.xensource.com Fri Sep 16 03:23:23 2011 Return-path: Envelope-to: www-data@lists.xensource.com Delivery-date: Fri, 16 Sep 2011 03:23:23 -0700 Received: from localhost ([127.0.0.1] helo=lists.colo.xensource.com) by lists.xensource.com with esmtp (Exim 4.43) id 1R4VZq-0006hJ-P3; Fri, 16 Sep 2011 03:23:22 -0700 Received: from mail21.messagelabs.com ([85.158.143.35]) by lists.xensource.com with esmtp (Exim 4.43) id 1R4VZO-0006V4-VA for xen-devel@lists.xensource.com; Fri, 16 Sep 2011 03:22:55 -0700 X-Env-Sender: JBeulich@suse.com X-Msg-Ref: server-2.tower-21.messagelabs.com!1316168570!34331006!1 X-Originating-IP: [130.57.49.28] X-StarScan-Version: 6.4.1; banners=-,-,- X-VirusChecked: Checked Received: (qmail 664 invoked from network); 16 Sep 2011 10:22:50 -0000 Received: from nat28.tlf.novell.com (HELO nat28.tlf.novell.com) (130.57.49.28) by server-2.tower-21.messagelabs.com with DHE-RSA-AES256-SHA encrypted SMTP; 16 Sep 2011 10:22:50 -0000 Received: from EMEA1-MTA by nat28.tlf.novell.com with Novell_GroupWise; Fri, 16 Sep 2011 11:22:51 +0100 Message-Id: <4E733F9B020000780005679C@nat28.tlf.novell.com> X-Mailer: Novell GroupWise Internet Agent 8.0.1 Date: Fri, 16 Sep 2011 11:22:51 +0100 From: "Jan Beulich" To: "xen-devel@lists.xensource.com" Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="=__Part1D322D6B.0__=" Subject: [Xen-devel] [PATCH] x86/vmx: don't call __vmxoff() blindly X-BeenThere: xen-devel@lists.xensource.com X-Mailman-Version: 2.1.5 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xensource.com Errors-To: xen-devel-bounces@lists.xensource.com This is a MIME message. If you are reading this text, you may want to consider changing to a mail reader or gateway that understands how to properly handle MIME multipart messages. --=__Part1D322D6B.0__= Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: quoted-printable Content-Disposition: inline If vmx_vcpu_up() failed, __vmxon() would generally not have got (successfully) executed, and in that case __vmxoff() will #UD. Additionally, any panic() during early resume (namely the tboot related one) would cause vmx_cpu_down() to get executed without vmx_cpu_up() having run before. Signed-off-by: Jan Beulich --- a/xen/arch/x86/hvm/vmx/vmcs.c +++ b/xen/arch/x86/hvm/vmx/vmcs.c @@ -71,6 +71,7 @@ bool_t cpu_has_vmx_ins_outs_instr_info _ static DEFINE_PER_CPU_READ_MOSTLY(struct vmcs_struct *, vmxon_region); static DEFINE_PER_CPU(struct vmcs_struct *, current_vmcs); static DEFINE_PER_CPU(struct list_head, active_vmcs_list); +static DEFINE_PER_CPU(bool_t, vmxon); =20 static u32 vmcs_revision_id __read_mostly; =20 @@ -519,6 +520,7 @@ int vmx_cpu_up(void) printk("CPU%d: unexpected VMXON failure\n", cpu); return -EINVAL; case 0: /* success */ + this_cpu(vmxon) =3D 1; break; default: BUG(); @@ -540,6 +542,9 @@ void vmx_cpu_down(void) struct list_head *active_vmcs_list =3D &this_cpu(active_vmcs_list); unsigned long flags; =20 + if ( !this_cpu(vmxon) ) + return; + local_irq_save(flags); =20 while ( !list_empty(active_vmcs_list) ) @@ -547,6 +552,7 @@ void vmx_cpu_down(void) struct vcpu, arch.hvm_vmx.active_list)= ); =20 BUG_ON(!(read_cr4() & X86_CR4_VMXE)); + this_cpu(vmxon) =3D 0; __vmxoff(); =20 local_irq_restore(flags); --=__Part1D322D6B.0__= Content-Type: text/plain; name="vmx-conditional-vmxoff.patch" Content-Transfer-Encoding: quoted-printable Content-Disposition: attachment; filename="vmx-conditional-vmxoff.patch" If vmx_vcpu_up() failed, __vmxon() would generally not have got=0A(successf= ully) executed, and in that case __vmxoff() will #UD.=0A=0AAdditionally, = any panic() during early resume (namely the tboot related=0Aone) would = cause vmx_cpu_down() to get executed without vmx_cpu_up()=0Ahaving run = before.=0A=0ASigned-off-by: Jan Beulich =0A=0A--- = a/xen/arch/x86/hvm/vmx/vmcs.c=0A+++ b/xen/arch/x86/hvm/vmx/vmcs.c=0A@@ = -71,6 +71,7 @@ bool_t cpu_has_vmx_ins_outs_instr_info _=0A static = DEFINE_PER_CPU_READ_MOSTLY(struct vmcs_struct *, vmxon_region);=0A static = DEFINE_PER_CPU(struct vmcs_struct *, current_vmcs);=0A static DEFINE_PER_CP= U(struct list_head, active_vmcs_list);=0A+static DEFINE_PER_CPU(bool_t, = vmxon);=0A =0A static u32 vmcs_revision_id __read_mostly;=0A =0A@@ -519,6 = +520,7 @@ int vmx_cpu_up(void)=0A printk("CPU%d: unexpected VMXON = failure\n", cpu);=0A return -EINVAL;=0A case 0: /* success = */=0A+ this_cpu(vmxon) =3D 1;=0A break;=0A default:=0A = BUG();=0A@@ -540,6 +542,9 @@ void vmx_cpu_down(void)=0A struct = list_head *active_vmcs_list =3D &this_cpu(active_vmcs_list);=0A = unsigned long flags;=0A =0A+ if ( !this_cpu(vmxon) )=0A+ = return;=0A+=0A local_irq_save(flags);=0A =0A while ( !list_empty(ac= tive_vmcs_list) )=0A@@ -547,6 +552,7 @@ void vmx_cpu_down(void)=0A = struct vcpu, arch.hvm_vmx.active_list));=0A = =0A BUG_ON(!(read_cr4() & X86_CR4_VMXE));=0A+ this_cpu(vmxon) =3D = 0;=0A __vmxoff();=0A =0A local_irq_restore(flags);=0A --=__Part1D322D6B.0__= Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel --=__Part1D322D6B.0__=-- From xen-devel-bounces@lists.xensource.com Fri Sep 16 03:29:07 2011 Return-path: Envelope-to: www-data@lists.xensource.com Delivery-date: Fri, 16 Sep 2011 03:29:07 -0700 Received: from localhost ([127.0.0.1] helo=lists.colo.xensource.com) by lists.xensource.com with esmtp (Exim 4.43) id 1R4VfP-00078t-BY; Fri, 16 Sep 2011 03:29:07 -0700 Received: from mail21.messagelabs.com ([85.158.143.35]) by lists.xensource.com with esmtp (Exim 4.43) id 1R4Vf1-0006wd-R9 for xen-devel@lists.xensource.com; Fri, 16 Sep 2011 03:28:44 -0700 X-Env-Sender: JBeulich@suse.com X-Msg-Ref: server-13.tower-21.messagelabs.com!1316168914!49154222!1 X-Originating-IP: [130.57.49.28] X-StarScan-Version: 6.4.1; banners=-,-,- X-VirusChecked: Checked Received: (qmail 19818 invoked from network); 16 Sep 2011 10:28:35 -0000 Received: from nat28.tlf.novell.com (HELO nat28.tlf.novell.com) (130.57.49.28) by server-13.tower-21.messagelabs.com with DHE-RSA-AES256-SHA encrypted SMTP; 16 Sep 2011 10:28:35 -0000 Received: from EMEA1-MTA by nat28.tlf.novell.com with Novell_GroupWise; Fri, 16 Sep 2011 11:28:40 +0100 Message-Id: <4E7340F702000078000567B2@nat28.tlf.novell.com> X-Mailer: Novell GroupWise Internet Agent 8.0.1 Date: Fri, 16 Sep 2011 11:28:39 +0100 From: "Jan Beulich" To: "xen-devel@lists.xensource.com" Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: quoted-printable Content-Disposition: inline Subject: [Xen-devel] [PATCH 0/2] x86-64/EFI: EFI 2.0 additions X-BeenThere: xen-devel@lists.xensource.com X-Mailman-Version: 2.1.5 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xensource.com Errors-To: xen-devel-bounces@lists.xensource.com EFI 2.0 added a few new runtime calls, for which Linux 3.1 gets accessors added, so flesh out the interface for them in Xen and implement what can reasonably be without actually having active call paths getting there = (i.e. without actual debugging possible). 1: header extensions 2: hypercall extensions Signed-off-by: Jan Beulich _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel From xen-devel-bounces@lists.xensource.com Fri Sep 16 03:30:31 2011 Return-path: Envelope-to: www-data@lists.xensource.com Delivery-date: Fri, 16 Sep 2011 03:30:31 -0700 Received: from localhost ([127.0.0.1] helo=lists.colo.xensource.com) by lists.xensource.com with esmtp (Exim 4.43) id 1R4Vgl-0007WE-A1; Fri, 16 Sep 2011 03:30:31 -0700 Received: from mail21.messagelabs.com ([85.158.143.35]) by lists.xensource.com with esmtp (Exim 4.43) id 1R4VfZ-0007AU-Ma for xen-devel@lists.xensource.com; Fri, 16 Sep 2011 03:29:19 -0700 X-Env-Sender: JBeulich@suse.com X-Msg-Ref: server-9.tower-21.messagelabs.com!1316168910!48648702!1 X-Originating-IP: [130.57.49.28] X-StarScan-Version: 6.4.1; banners=-,-,- X-VirusChecked: Checked Received: (qmail 17715 invoked from network); 16 Sep 2011 10:28:30 -0000 Received: from nat28.tlf.novell.com (HELO nat28.tlf.novell.com) (130.57.49.28) by server-9.tower-21.messagelabs.com with DHE-RSA-AES256-SHA encrypted SMTP; 16 Sep 2011 10:28:30 -0000 Received: from EMEA1-MTA by nat28.tlf.novell.com with Novell_GroupWise; Fri, 16 Sep 2011 11:29:13 +0100 Message-Id: <4E73411902000078000567B5@nat28.tlf.novell.com> X-Mailer: Novell GroupWise Internet Agent 8.0.1 Date: Fri, 16 Sep 2011 11:29:13 +0100 From: "Jan Beulich" To: "xen-devel@lists.xensource.com" Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: quoted-printable Content-Disposition: inline Subject: [Xen-devel] [PATCH 1/2] x86-64/EFI: 2.0 header extensions X-BeenThere: xen-devel@lists.xensource.com X-Mailman-Version: 2.1.5 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xensource.com Errors-To: xen-devel-bounces@lists.xensource.com Updates from gnu-efi 3.0m. UEFI 2.0 runtime services additions taken from EDK 1.06. Signed-off-by: Jan Beulich --- a/xen/arch/x86/efi/efi.h +++ b/xen/arch/x86/efi/efi.h @@ -3,6 +3,7 @@ #include #include #include +#include #include #include #include --- a/xen/include/asm-x86/x86_64/efibind.h +++ b/xen/include/asm-x86/x86_64/efibind.h @@ -236,7 +236,22 @@ typedef uint64_t UINTN; // one big module. // =20 - #define EFI_DRIVER_ENTRY_POINT(InitFunction) + #define EFI_DRIVER_ENTRY_POINT(InitFunction) \ + UINTN \ + InitializeDriver ( \ + VOID *ImageHandle, \ + VOID *SystemTable \ + ) \ + { \ + return InitFunction(ImageHandle, \ + SystemTable); \ + } \ + \ + EFI_STATUS efi_main( \ + EFI_HANDLE image, \ + EFI_SYSTEM_TABLE *systab \ + ) __attribute__((weak, \ + alias ("InitializeDriver"))); =20 #define LOAD_INTERNAL_DRIVER(_if, type, name, entry) \ (_if)->LoadInternal(type, name, entry) --- a/xen/include/efi/efiapi.h +++ b/xen/include/efi/efiapi.h @@ -246,6 +246,15 @@ EFI_STATUS IN VOID *Data ); =20 +typedef +EFI_STATUS +(EFIAPI *EFI_QUERY_VARIABLE_INFO) ( + IN UINT32 Attributes, + OUT UINT64 *MaximumVariableStorageSize, + OUT UINT64 *RemainingVariableStorageSize, + OUT UINT64 *MaximumVariableSize + ); + =20 // // EFI Time @@ -412,6 +421,147 @@ EFI_STATUS IN CHAR16 *WatchdogData OPTIONAL ); =20 +typedef +EFI_STATUS +(EFIAPI *EFI_CONNECT_CONTROLLER) ( + IN EFI_HANDLE ControllerHandle, + IN EFI_HANDLE *DriverImageHandle OPTIONAL, + IN EFI_DEVICE_PATH *RemainingDevicePath OPTIONAL, + IN BOOLEAN Recursive + ); + +typedef +EFI_STATUS +(EFIAPI *EFI_DISCONNECT_CONTROLLER) ( + IN EFI_HANDLE ControllerHandle, + IN EFI_HANDLE DriverImageHandle OPTIONAL, + IN EFI_HANDLE ChildHandle OPTIONAL + ); + +#define EFI_OPEN_PROTOCOL_BY_HANDLE_PROTOCOL 0x00000001 +#define EFI_OPEN_PROTOCOL_GET_PROTOCOL 0x00000002 +#define EFI_OPEN_PROTOCOL_TEST_PROTOCOL 0x00000004 +#define EFI_OPEN_PROTOCOL_BY_CHILD_CONTROLLER 0x00000008 +#define EFI_OPEN_PROTOCOL_BY_DRIVER 0x00000010 +#define EFI_OPEN_PROTOCOL_EXCLUSIVE 0x00000020 + +typedef +EFI_STATUS +(EFIAPI *EFI_OPEN_PROTOCOL) ( + IN EFI_HANDLE Handle, + IN EFI_GUID *Protocol, + OUT VOID **Interface OPTIONAL, + IN EFI_HANDLE AgentHandle, + IN EFI_HANDLE ControllerHandle, + IN UINT32 Attributes + ); + +typedef +EFI_STATUS +(EFIAPI *EFI_CLOSE_PROTOCOL) ( + IN EFI_HANDLE Handle, + IN EFI_GUID *Protocol, + IN EFI_HANDLE AgentHandle, + IN EFI_HANDLE ControllerHandle + ); + +typedef struct { + EFI_HANDLE AgentHandle; + EFI_HANDLE ControllerHandle; + UINT32 Attributes; + UINT32 OpenCount; +} EFI_OPEN_PROTOCOL_INFORMATION_ENTRY; + +typedef +EFI_STATUS +(EFIAPI *EFI_OPEN_PROTOCOL_INFORMATION) ( + IN EFI_HANDLE Handle, + IN EFI_GUID *Protocol, + OUT EFI_OPEN_PROTOCOL_INFORMATION_ENTRY **EntryBuffer, + OUT UINTN *EntryCount + ); + +typedef +EFI_STATUS +(EFIAPI *EFI_PROTOCOLS_PER_HANDLE) ( + IN EFI_HANDLE Handle, + OUT EFI_GUID ***ProtocolBuffer, + OUT UINTN *ProtocolBufferCount + ); + +typedef enum { + AllHandles, + ByRegisterNotify, + ByProtocol +} EFI_LOCATE_SEARCH_TYPE; + +typedef +EFI_STATUS +(EFIAPI *EFI_LOCATE_HANDLE_BUFFER) ( + IN EFI_LOCATE_SEARCH_TYPE SearchType, + IN EFI_GUID *Protocol OPTIONAL, + IN VOID *SearchKey OPTIONAL, + IN OUT UINTN *NoHandles, + OUT EFI_HANDLE **Buffer + ); + +typedef +EFI_STATUS +(EFIAPI *EFI_LOCATE_PROTOCOL) ( + IN EFI_GUID *Protocol, + IN VOID *Registration OPTIONAL, + OUT VOID **Interface + ); + +typedef +EFI_STATUS +(EFIAPI *EFI_INSTALL_MULTIPLE_PROTOCOL_INTERFACES) ( + IN OUT EFI_HANDLE *Handle, + ... + ); + +typedef +EFI_STATUS +(EFIAPI *EFI_UNINSTALL_MULTIPLE_PROTOCOL_INTERFACES) ( + IN OUT EFI_HANDLE Handle, + ... + ); + +typedef +EFI_STATUS +(EFIAPI *EFI_CALCULATE_CRC32) ( + IN VOID *Data, + IN UINTN DataSize, + OUT UINT32 *Crc32 + ); + +typedef +VOID +(EFIAPI *EFI_COPY_MEM) ( + IN VOID *Destination, + IN VOID *Source, + IN UINTN Length + ); + +typedef +VOID +(EFIAPI *EFI_SET_MEM) ( + IN VOID *Buffer, + IN UINTN Size, + IN UINT8 Value + ); + + +typedef +EFI_STATUS +(EFIAPI *EFI_CREATE_EVENT_EX) ( + IN UINT32 Type, + IN EFI_TPL NotifyTpl, + IN EFI_EVENT_NOTIFY NotifyFunction OPTIONAL, + IN const VOID *NotifyContext OPTIONAL, + IN const EFI_GUID EventGroup OPTIONAL, + OUT EFI_EVENT *Event + ); =20 typedef enum { EfiResetCold, @@ -440,6 +590,24 @@ EFI_STATUS OUT UINT32 *HighCount ); =20 +typedef +EFI_STATUS +(EFIAPI *EFI_UPDATE_CAPSULE) ( + IN EFI_CAPSULE_HEADER **CapsuleHeaderArray, + IN UINTN CapsuleCount, + IN EFI_PHYSICAL_ADDRESS ScatterGatherList OPTIONAL + ); + + +typedef +EFI_STATUS +(EFIAPI *EFI_QUERY_CAPSULE_CAPABILITIES) ( + IN EFI_CAPSULE_HEADER **CapsuleHeaderArray, + IN UINTN CapsuleCount, + OUT UINT64 *MaxiumCapsuleSize, + OUT EFI_RESET_TYPE *ResetType +); + // // Protocol handler functions // @@ -491,12 +659,6 @@ EFI_STATUS OUT VOID **Registration ); =20 -typedef enum { - AllHandles, - ByRegisterNotify, - ByProtocol -} EFI_LOCATE_SEARCH_TYPE; - typedef EFI_STATUS (EFIAPI *EFI_LOCATE_HANDLE) ( @@ -578,6 +740,14 @@ typedef struct { EFI_GET_NEXT_HIGH_MONO_COUNT GetNextHighMonotonicCount; EFI_RESET_SYSTEM ResetSystem; =20 + // + // New Boot Service added by UEFI 2.0 + // + + EFI_UPDATE_CAPSULE UpdateCapsule; + EFI_QUERY_CAPSULE_CAPABILITIES QueryCapsuleCapabilities; + EFI_QUERY_VARIABLE_INFO QueryVariableInfo; + } EFI_RUNTIME_SERVICES; =20 =20 @@ -652,6 +822,40 @@ typedef struct _EFI_BOOT_SERVICES { EFI_STALL Stall; EFI_SET_WATCHDOG_TIMER SetWatchdogTimer; =20 + // + // DriverSupport Services + // + + EFI_CONNECT_CONTROLLER ConnectController; + EFI_DISCONNECT_CONTROLLER DisconnectController; + + // + // Open and Close Protocol Services + // + EFI_OPEN_PROTOCOL OpenProtocol; + EFI_CLOSE_PROTOCOL CloseProtocol; + EFI_OPEN_PROTOCOL_INFORMATION OpenProtocolInformation; + + // + // Library Services + // + EFI_PROTOCOLS_PER_HANDLE ProtocolsPerHandle; + EFI_LOCATE_HANDLE_BUFFER LocateHandleBuffer; + EFI_LOCATE_PROTOCOL LocateProtocol; + EFI_INSTALL_MULTIPLE_PROTOCOL_INTERFACES InstallMultipleProtocolInterf= aces; + EFI_UNINSTALL_MULTIPLE_PROTOCOL_INTERFACES UninstallMultipleProtocolIn= terfaces; + + // + // 32-bit CRC Services + // + EFI_CALCULATE_CRC32 CalculateCrc32; + + // + // Misc Services + // + EFI_COPY_MEM CopyMem; + EFI_SET_MEM SetMem; + EFI_CREATE_EVENT_EX CreateEventEx; } EFI_BOOT_SERVICES; =20 =20 --- /dev/null 1970-01-01 00:00:00.000000000 +0000 +++ b/xen/include/efi/eficapsule.h @@ -0,0 +1,89 @@ +/*++ + +Copyright (c) 2004 - 2007, Intel Corporation +All rights reserved. This program and the accompanying materials +are licensed and made available under the terms and conditions of the BSD = License +which accompanies this distribution. The full text of the license may be = found at +http://opensource.org/licenses/bsd-license.php + +THE PROGRAM IS DISTRIBUTED UNDER THE BSD LICENSE ON AN "AS IS" BASIS, +WITHOUT WARRANTIES OR REPRESENTATIONS OF ANY KIND, EITHER EXPRESS OR = IMPLIED. + +Module Name: + + EfiCapsule.h + +Abstract: + + Defines for the EFI Capsule functionality + +--*/ + +#ifndef _EFI_CAPSULE_H +#define _EFI_CAPSULE_H + + +#define CAPSULE_BLOCK_DESCRIPTOR_SIGNATURE EFI_SIGNATURE_32 ('C', 'B', = 'D', 'S') + +typedef struct { + EFI_GUID OemGuid; + UINT32 HeaderSize; + // + // UINT8 OemHdrData[]; + // +} EFI_CAPSULE_OEM_HEADER; + +#define MAX_SUPPORT_CAPSULE_NUM 50 +#define CAPSULE_FLAGS_PERSIST_ACROSS_RESET 0x00010000 +#define CAPSULE_FLAGS_POPULATE_SYSTEM_TABLE 0x00020000 + +typedef struct { + UINT64 Length; + union { + EFI_PHYSICAL_ADDRESS DataBlock; + EFI_PHYSICAL_ADDRESS ContinuationPointer; + } Union; +} EFI_CAPSULE_BLOCK_DESCRIPTOR; + +typedef struct { + EFI_GUID CapsuleGuid; + UINT32 HeaderSize; + UINT32 Flags; + UINT32 CapsuleImageSize; +} EFI_CAPSULE_HEADER; + +typedef struct { + UINT32 CapsuleArrayNumber; + VOID* CapsulePtr[1]; +} EFI_CAPSULE_TABLE; + +// +// Bits in the flags field of the capsule header +// +#define EFI_CAPSULE_HEADER_FLAG_SETUP 0x00000001 // supports setup = changes +// +// This is the GUID of the capsule header of the image on disk. +// +#define EFI_CAPSULE_GUID \ + { \ + 0x3B6686BD, 0x0D76, 0x4030, 0xB7, 0x0E, 0xB5, 0x51, 0x9E, 0x2F, 0xC5, = 0xA0 \ + } + +// +// This is the GUID of the file created by the capsule application that = contains +// the path to the device(s) to update. +// +#define EFI_PATH_FILE_NAME_GUID \ + { \ + 0x7644C181, 0xFA6E, 0x46DA, 0x80, 0xCB, 0x04, 0xB9, 0x90, 0x40, 0x62, = 0xE8 \ + } +// +// This is the GUID of the configuration results file created by the = capsule +// application. +// +#define EFI_CONFIG_FILE_NAME_GUID \ + { \ + 0x98B8D59B, 0xE8BA, 0x48EE, 0x98, 0xDD, 0xC2, 0x95, 0x39, 0x2F, 0x1E, = 0xDB \ + } + +#endif _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel From xen-devel-bounces@lists.xensource.com Fri Sep 16 03:31:41 2011 Return-path: Envelope-to: www-data@lists.xensource.com Delivery-date: Fri, 16 Sep 2011 03:31:41 -0700 Received: from localhost ([127.0.0.1] helo=lists.colo.xensource.com) by lists.xensource.com with esmtp (Exim 4.43) id 1R4Vht-0007yj-Nr; Fri, 16 Sep 2011 03:31:41 -0700 Received: from mail182.messagelabs.com ([85.158.139.83]) by lists.xensource.com with esmtp (Exim 4.43) id 1R4Vg5-0007CJ-6U for xen-devel@lists.xensource.com; Fri, 16 Sep 2011 03:29:49 -0700 X-Env-Sender: JBeulich@suse.com X-Msg-Ref: server-3.tower-182.messagelabs.com!1316168985!15783166!1 X-Originating-IP: [130.57.49.28] X-StarScan-Version: 6.4.1; banners=-,-,- X-VirusChecked: Checked Received: (qmail 10210 invoked from network); 16 Sep 2011 10:29:45 -0000 Received: from nat28.tlf.novell.com (HELO nat28.tlf.novell.com) (130.57.49.28) by server-3.tower-182.messagelabs.com with DHE-RSA-AES256-SHA encrypted SMTP; 16 Sep 2011 10:29:45 -0000 Received: from EMEA1-MTA by nat28.tlf.novell.com with Novell_GroupWise; Fri, 16 Sep 2011 11:29:45 +0100 Message-Id: <4E73413702000078000567C4@nat28.tlf.novell.com> X-Mailer: Novell GroupWise Internet Agent 8.0.1 Date: Fri, 16 Sep 2011 11:29:43 +0100 From: "Jan Beulich" To: "xen-devel@lists.xensource.com" Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="=__Part77584707.0__=" Subject: [Xen-devel] [PATCH 2/2] x86-64/EFI: 2.0 hypercall extensions X-BeenThere: xen-devel@lists.xensource.com X-Mailman-Version: 2.1.5 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xensource.com Errors-To: xen-devel-bounces@lists.xensource.com This is a MIME message. If you are reading this text, you may want to consider changing to a mail reader or gateway that understands how to properly handle MIME multipart messages. --=__Part77584707.0__= Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: quoted-printable Content-Disposition: inline Flesh out the interface to EFI 2.0 runtime calls and implement what can reasonably be without actually having active call paths getting there (i.e. without actual debugging possible: The capsule interfaces certainly require an environment where an initial implementation can actually be tested). Signed-off-by: Jan Beulich --- a/xen/arch/x86/efi/runtime.c +++ b/xen/arch/x86/efi/runtime.c @@ -130,6 +130,14 @@ int efi_get_info(uint32_t idx, union xen case XEN_FW_EFI_VERSION: info->version =3D efi_version; break; + case XEN_FW_EFI_RT_VERSION: + { + unsigned long cr3 =3D efi_rs_enter(); + + info->version =3D efi_rs->Hdr.Revision; + efi_rs_leave(cr3); + break; + } case XEN_FW_EFI_CONFIG_TABLE: info->cfg.addr =3D __pa(efi_ct); info->cfg.nent =3D efi_num_ct; @@ -418,7 +426,12 @@ int efi_runtime_call(struct xenpf_efi_ru name.raw =3D xmalloc_bytes(size); if ( !name.raw ) return -ENOMEM; - copy_from_guest(name.raw, op->u.get_next_variable_name.name, = size); + if ( copy_from_guest(name.raw, op->u.get_next_variable_name.name, + size) ) + { + xfree(name.raw); + return -EFAULT; + } =20 cr3 =3D efi_rs_enter(); status =3D efi_rs->GetNextVariableName( @@ -435,6 +448,31 @@ int efi_runtime_call(struct xenpf_efi_ru } break; =20 + case XEN_EFI_query_variable_info: + cr3 =3D efi_rs_enter(); + if ( (efi_rs->Hdr.Revision >> 16) < 2 ) + { + efi_rs_leave(cr3); + return -EOPNOTSUPP; + } + status =3D efi_rs->QueryVariableInfo( + op->u.query_variable_info.attr, + &op->u.query_variable_info.max_store_size, + &op->u.query_variable_info.remain_store_size, + &op->u.query_variable_info.max_size); + efi_rs_leave(cr3); + break; + + case XEN_EFI_query_capsule_capabilities: + case XEN_EFI_update_capsule: + cr3 =3D efi_rs_enter(); + if ( (efi_rs->Hdr.Revision >> 16) < 2 ) + { + efi_rs_leave(cr3); + return -EOPNOTSUPP; + } + efi_rs_leave(cr3); + /* XXX fall through for now */ default: return -ENOSYS; } --- a/xen/include/public/platform.h +++ b/xen/include/public/platform.h @@ -123,6 +123,9 @@ DEFINE_XEN_GUEST_HANDLE(xenpf_platform_q #define XEN_EFI_get_variable 6 #define XEN_EFI_set_variable 7 #define XEN_EFI_get_next_variable_name 8 +#define XEN_EFI_query_variable_info 9 +#define XEN_EFI_query_capsule_capabilities 10 +#define XEN_EFI_update_capsule 11 struct xenpf_efi_runtime_call { uint32_t function; /* @@ -180,6 +183,26 @@ struct xenpf_efi_runtime_call { XEN_GUEST_HANDLE(void) name; /* UCS-2/UTF-16 string */ struct xenpf_efi_guid vendor_guid; } get_next_variable_name; + + struct { + uint32_t attr; + uint64_t max_store_size; + uint64_t remain_store_size; + uint64_t max_size; + } query_variable_info; + + struct { + XEN_GUEST_HANDLE(void) capsule_header_array; + unsigned long capsule_count; + uint64_t max_capsule_size; + unsigned int reset_type; + } query_capsule_capabilities; + + struct { + XEN_GUEST_HANDLE(void) capsule_header_array; + unsigned long capsule_count; + uint64_t sg_list; /* machine address */ + } update_capsule; } u; }; typedef struct xenpf_efi_runtime_call xenpf_efi_runtime_call_t; @@ -194,6 +217,7 @@ DEFINE_XEN_GUEST_HANDLE(xenpf_efi_runtim #define XEN_FW_EFI_CONFIG_TABLE 1 #define XEN_FW_EFI_VENDOR 2 #define XEN_FW_EFI_MEM_INFO 3 +#define XEN_FW_EFI_RT_VERSION 4 struct xenpf_firmware_info { /* IN variables. */ uint32_t type; --=__Part77584707.0__= Content-Type: text/plain; name="x86-EFI-runtime-2.0.patch" Content-Transfer-Encoding: quoted-printable Content-Disposition: attachment; filename="x86-EFI-runtime-2.0.patch" Flesh out the interface to EFI 2.0 runtime calls and implement what = can=0Areasonably be without actually having active call paths getting = there=0A(i.e. without actual debugging possible: The capsule interfaces=0Ac= ertainly require an environment where an initial implementation can=0Aactua= lly be tested).=0A=0ASigned-off-by: Jan Beulich =0A=0A--= - a/xen/arch/x86/efi/runtime.c=0A+++ b/xen/arch/x86/efi/runtime.c=0A@@ = -130,6 +130,14 @@ int efi_get_info(uint32_t idx, union xen=0A case = XEN_FW_EFI_VERSION:=0A info->version =3D efi_version;=0A = break;=0A+ case XEN_FW_EFI_RT_VERSION:=0A+ {=0A+ unsigned = long cr3 =3D efi_rs_enter();=0A+=0A+ info->version =3D efi_rs->Hdr.R= evision;=0A+ efi_rs_leave(cr3);=0A+ break;=0A+ }=0A = case XEN_FW_EFI_CONFIG_TABLE:=0A info->cfg.addr =3D __pa(efi_ct);= =0A info->cfg.nent =3D efi_num_ct;=0A@@ -418,7 +426,12 @@ int = efi_runtime_call(struct xenpf_efi_ru=0A name.raw =3D xmalloc_bytes(= size);=0A if ( !name.raw )=0A return -ENOMEM;=0A- = copy_from_guest(name.raw, op->u.get_next_variable_name.name, size);=0A+ = if ( copy_from_guest(name.raw, op->u.get_next_variable_name.name,=0A+= size) )=0A+ {=0A+ xfree(name= .raw);=0A+ return -EFAULT;=0A+ }=0A =0A cr3 =3D = efi_rs_enter();=0A status =3D efi_rs->GetNextVariableName(=0A@@ = -435,6 +448,31 @@ int efi_runtime_call(struct xenpf_efi_ru=0A }=0A = break;=0A =0A+ case XEN_EFI_query_variable_info:=0A+ cr3 =3D = efi_rs_enter();=0A+ if ( (efi_rs->Hdr.Revision >> 16) < 2 )=0A+ = {=0A+ efi_rs_leave(cr3);=0A+ return -EOPNOTSUPP;= =0A+ }=0A+ status =3D efi_rs->QueryVariableInfo(=0A+ = op->u.query_variable_info.attr,=0A+ &op->u.query_variable_inf= o.max_store_size,=0A+ &op->u.query_variable_info.remain_store_si= ze,=0A+ &op->u.query_variable_info.max_size);=0A+ = efi_rs_leave(cr3);=0A+ break;=0A+=0A+ case XEN_EFI_query_capsule_= capabilities:=0A+ case XEN_EFI_update_capsule:=0A+ cr3 =3D = efi_rs_enter();=0A+ if ( (efi_rs->Hdr.Revision >> 16) < 2 )=0A+ = {=0A+ efi_rs_leave(cr3);=0A+ return -EOPNOTSUPP;= =0A+ }=0A+ efi_rs_leave(cr3);=0A+ /* XXX fall through = for now */=0A default:=0A return -ENOSYS;=0A }=0A--- = a/xen/include/public/platform.h=0A+++ b/xen/include/public/platform.h=0A@@ = -123,6 +123,9 @@ DEFINE_XEN_GUEST_HANDLE(xenpf_platform_q=0A #define = XEN_EFI_get_variable 6=0A #define XEN_EFI_set_variable = 7=0A #define XEN_EFI_get_next_variable_name 8=0A+#defi= ne XEN_EFI_query_variable_info 9=0A+#define XEN_EFI_query_capsule= _capabilities 10=0A+#define XEN_EFI_update_capsule 11=0A = struct xenpf_efi_runtime_call {=0A uint32_t function;=0A /*=0A@@ = -180,6 +183,26 @@ struct xenpf_efi_runtime_call {=0A XEN_GUEST_= HANDLE(void) name; /* UCS-2/UTF-16 string */=0A struct = xenpf_efi_guid vendor_guid;=0A } get_next_variable_name;=0A+=0A+ = struct {=0A+ uint32_t attr;=0A+ uint64_t = max_store_size;=0A+ uint64_t remain_store_size;=0A+ = uint64_t max_size;=0A+ } query_variable_info;=0A+=0A+ struct = {=0A+ XEN_GUEST_HANDLE(void) capsule_header_array;=0A+ = unsigned long capsule_count;=0A+ uint64_t max_capsule_size;=0A= + unsigned int reset_type;=0A+ } query_capsule_capabiliti= es;=0A+=0A+ struct {=0A+ XEN_GUEST_HANDLE(void) = capsule_header_array;=0A+ unsigned long capsule_count;=0A+ = uint64_t sg_list; /* machine address */=0A+ } update_capsule;= =0A } u;=0A };=0A typedef struct xenpf_efi_runtime_call xenpf_efi_runti= me_call_t;=0A@@ -194,6 +217,7 @@ DEFINE_XEN_GUEST_HANDLE(xenpf_efi_runtim= =0A #define XEN_FW_EFI_CONFIG_TABLE 1=0A #define XEN_FW_EFI_VENDOR = 2=0A #define XEN_FW_EFI_MEM_INFO 3=0A+#define XEN_FW_EFI_RT_VER= SION 4=0A struct xenpf_firmware_info {=0A /* IN variables. */=0A = uint32_t type;=0A --=__Part77584707.0__= Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel --=__Part77584707.0__=-- From xen-devel-bounces@lists.xensource.com Fri Sep 16 04:12:07 2011 Return-path: Envelope-to: www-data@lists.xensource.com Delivery-date: Fri, 16 Sep 2011 04:12:07 -0700 Received: from localhost ([127.0.0.1] helo=lists.colo.xensource.com) by lists.xensource.com with esmtp (Exim 4.43) id 1R4WKy-0000pF-Ak; Fri, 16 Sep 2011 04:12:04 -0700 Received: from mail27.messagelabs.com ([193.109.254.147]) by lists.xensource.com with smtp (Exim 4.43) id 1R4WHo-0000aF-Gz; Fri, 16 Sep 2011 04:10:14 -0700 X-Env-Sender: rjones@redhat.com X-Msg-Ref: server-14.tower-27.messagelabs.com!1316171310!36392509!1 X-Originating-IP: [209.132.183.28] X-StarScan-Version: 6.4.1; banners=-,-,- X-VirusChecked: Checked Received: (qmail 29873 invoked from network); 16 Sep 2011 11:08:30 -0000 Received: from mx1.redhat.com (HELO mx1.redhat.com) (209.132.183.28) by server-14.tower-27.messagelabs.com with SMTP; 16 Sep 2011 11:08:30 -0000 Received: from int-mx02.intmail.prod.int.phx2.redhat.com (int-mx02.intmail.prod.int.phx2.redhat.com [10.5.11.12]) by mx1.redhat.com (8.14.4/8.14.4) with ESMTP id p8GB8gnx007715 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Fri, 16 Sep 2011 07:08:43 -0400 Received: from localhost (vpn1-6-5.ams2.redhat.com [10.36.6.5]) by int-mx02.intmail.prod.int.phx2.redhat.com (8.13.8/8.13.8) with ESMTP id p8GB8em0028760; Fri, 16 Sep 2011 07:08:41 -0400 Date: Fri, 16 Sep 2011 12:08:40 +0100 From: "Richard W.M. Jones" To: Development discussions related to Fedora Message-ID: <20110916110840.GA14613@amd.home.annexia.org> References: <20110914112552.GP12984@reaktio.net> <20110914142522.GA16956@phenom.oracle.com> <20110914144539.GR12984@reaktio.net> <20110915151041.GA4453@imp.local> <1316126290.5689.3.camel@adam> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.21 (2010-09-15) X-Scanned-By: MIMEDefang 2.67 on 10.5.11.12 Cc: xen@lists.fedoraproject.org, xen-devel@lists.xensource.com, Konrad Rzeszutek Wilk , lars.kurth@xen.org, virt@lists.fedoraproject.org, xen-users@lists.xensource.com Subject: [Xen-devel] Re: Virtualization Test Day for F16 and Xen X-BeenThere: xen-devel@lists.xensource.com X-Mailman-Version: 2.1.5 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xensource.com Errors-To: xen-devel-bounces@lists.xensource.com On Fri, Sep 16, 2011 at 12:14:23PM +0300, Myroslav Opyr wrote: > Hi, > > What Xen implementation is considered "supported" for FC16 DomU? Any commonly available upstream Xen releases. Fedora itself (ie. https://fedoraproject.org/wiki/Features/XenPvopsDom0). Also Xen in RHEL 5, although that's more of a thing for Red Hat to worry about. > I'm asking because on "Xen implementation" we were testing yesterday > FC16 DomU installation failed compared to FC15 DomU success on the > very same Dom0. Are failures like we've encountered candidates for > bugreports? Yes. > Is there a place (wikipage, bugzilla keyword, etc.) to collect > Fedora 16 Xen issues? https://bugzilla.redhat.com/ Product: Fedora. Component: depends on what is failing but common ones would be "kernel", "anaconda", "grubby", "grub2", "xen", and "libvirt". There is also a Fedora Xen mailing list where you can get more detailed help: https://lists.fedoraproject.org/mailman/listinfo/xen Rich. -- Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones Read my programming blog: http://rwmj.wordpress.com Fedora now supports 80 OCaml packages (the OPEN alternative to F#) http://cocan.org/getting_started_with_ocaml_on_red_hat_and_fedora _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel From xen-devel-bounces@lists.xensource.com Fri Sep 16 04:21:45 2011 Return-path: Envelope-to: www-data@lists.xensource.com Delivery-date: Fri, 16 Sep 2011 04:21:45 -0700 Received: from localhost ([127.0.0.1] helo=lists.colo.xensource.com) by lists.xensource.com with esmtp (Exim 4.43) id 1R4WUL-0001ya-Fq; Fri, 16 Sep 2011 04:21:45 -0700 Received: from mail182.messagelabs.com ([85.158.139.83]) by lists.xensource.com with esmtp (Exim 4.43) id 1R4WTV-0001lt-IO for xen-devel@lists.xensource.com; Fri, 16 Sep 2011 04:20:53 -0700 X-Env-Sender: tim@xen.org X-Msg-Ref: server-2.tower-182.messagelabs.com!1316172050!17594009!1 X-Originating-IP: [81.29.64.94] X-StarScan-Version: 6.4.1; banners=-,-,- X-VirusChecked: Checked Received: (qmail 28777 invoked from network); 16 Sep 2011 11:20:50 -0000 Received: from ocelot.phlegethon.org (HELO mail.phlegethon.org) (81.29.64.94) by server-2.tower-182.messagelabs.com with DHE-RSA-AES256-SHA encrypted SMTP; 16 Sep 2011 11:20:50 -0000 Received: from tjd by mail.phlegethon.org with local (Exim 4.67 (FreeBSD)) (envelope-from ) id 1R4WTP-000PSL-Th; Fri, 16 Sep 2011 11:20:47 +0000 Date: Fri, 16 Sep 2011 12:20:47 +0100 From: Tim Deegan To: Ian Jackson Subject: Re: [Xen-devel] [PATCH 0 of 2] v2: memshare/xenpaging/xen-access fixes for xen-unstable Message-ID: <20110916112047.GA95880@ocelot.phlegethon.org> References: <20110912135717.GC79171@ocelot.phlegethon.org> <20081.53649.196648.92906@mariner.uk.xensource.com> Mime-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline In-Reply-To: <20081.53649.196648.92906@mariner.uk.xensource.com> User-Agent: Mutt/1.4.2.1i Cc: Olaf Hering , xen-devel@lists.xensource.com X-BeenThere: xen-devel@lists.xensource.com X-Mailman-Version: 2.1.5 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xensource.com Errors-To: xen-devel-bounces@lists.xensource.com At 11:21 +0100 on 15 Sep (1316085665), Ian Jackson wrote: > Tim Deegan writes ("Re: [Xen-devel] [PATCH 0 of 2] v2: memshare/xenpaging/xen-access fixes for xen-unstable"): > > At 11:57 +0200 on 08 Sep (1315483028), Olaf Hering wrote: > > > The following two patches allow the parallel use of memsharing, > > > xenpaging and xen-access by using an independent ring buffer for > > > each feature. > > > > > > Please review. > > > > As I said, the Xen side looks fine but I'd like the opinion of the tools > > maintainers about the API changes before I apply anything. Maybe this > > is something that can happen at the hackathon. > > >From the tools point of view: > > Acked-by: Ian Jackson > > Tim, I wasn't sure if your message was an ack from the hypervisor > point of view, so I haven't actually applied these patches. OK, I've applied them now. Cheers, Tim. _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel From xen-devel-bounces@lists.xensource.com Fri Sep 16 04:24:35 2011 Return-path: Envelope-to: www-data@lists.xensource.com Delivery-date: Fri, 16 Sep 2011 04:24:35 -0700 Received: from localhost ([127.0.0.1] helo=lists.colo.xensource.com) by lists.xensource.com with esmtp (Exim 4.43) id 1R4WX5-0002NB-HQ; Fri, 16 Sep 2011 04:24:35 -0700 Received: from mail21.messagelabs.com ([85.158.143.35]) by lists.xensource.com with esmtp (Exim 4.43) id 1R4WWc-0002BV-FH for xen-devel@lists.xensource.com; Fri, 16 Sep 2011 04:24:06 -0700 X-Env-Sender: tim@xen.org X-Msg-Ref: server-14.tower-21.messagelabs.com!1316172235!59824276!1 X-Originating-IP: [81.29.64.94] X-StarScan-Version: 6.4.1; banners=-,-,- X-VirusChecked: Checked Received: (qmail 16089 invoked from network); 16 Sep 2011 11:23:55 -0000 Received: from ocelot.phlegethon.org (HELO mail.phlegethon.org) (81.29.64.94) by server-14.tower-21.messagelabs.com with DHE-RSA-AES256-SHA encrypted SMTP; 16 Sep 2011 11:23:55 -0000 Received: from tjd by mail.phlegethon.org with local (Exim 4.67 (FreeBSD)) (envelope-from ) id 1R4WWZ-000PTD-5U; Fri, 16 Sep 2011 11:24:03 +0000 Date: Fri, 16 Sep 2011 12:24:03 +0100 From: Tim Deegan To: Olaf Hering Subject: Re: [Xen-devel] [PATCH] xenpaging: track number of paged pages in struct domain Message-ID: <20110916112403.GB95880@ocelot.phlegethon.org> References: <13b4be345ebac016abe2.1316089567@probook.site> Mime-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline In-Reply-To: <13b4be345ebac016abe2.1316089567@probook.site> User-Agent: Mutt/1.4.2.1i Cc: xen-devel@lists.xensource.com X-BeenThere: xen-devel@lists.xensource.com X-Mailman-Version: 2.1.5 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xensource.com Errors-To: xen-devel-bounces@lists.xensource.com At 14:26 +0200 on 15 Sep (1316096767), Olaf Hering wrote: > # HG changeset patch > # User Olaf Hering > # Date 1316089500 -7200 > # Node ID 13b4be345ebac016abe26386417824a0c47d762d > # Parent e90438f6e6d1585a71b18784a99c162b5d95f390 > xenpaging: track number of paged pages in struct domain > > The toolstack should know how many pages are paged-out at a given point > in time so it could make smarter decisions about how many pages should > be paged or ballooned. > > Add a new member to xen_domctl_getdomaininfo and bump interface version. > Use the new member in xc_dominfo_t. > The SONAME of libxc should be changed if this patch gets applied. > > Signed-off-by: Olaf Hering For the xen parts, Acked-by: Tim Deegan Again, I'd like the tools maintainers to ack/nack the change to the domctl interface and associated libxc plumbing. Cheers, Tim. _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel From xen-devel-bounces@lists.xensource.com Fri Sep 16 04:33:50 2011 Return-path: Envelope-to: www-data@lists.xensource.com Delivery-date: Fri, 16 Sep 2011 04:33:50 -0700 Received: from localhost ([127.0.0.1] helo=lists.colo.xensource.com) by lists.xensource.com with esmtp (Exim 4.43) id 1R4Wg2-0002s4-4P; Fri, 16 Sep 2011 04:33:50 -0700 Received: from mail182.messagelabs.com ([85.158.139.83]) by lists.xensource.com with esmtp (Exim 4.43) id 1R4WfP-0002fd-22 for xen-devel@lists.xensource.com; Fri, 16 Sep 2011 04:33:11 -0700 X-Env-Sender: olaf@aepfle.de X-Msg-Ref: server-8.tower-182.messagelabs.com!1316172787!18597693!1 X-Originating-IP: [81.169.146.161] X-StarScan-Version: 6.4.1; banners=-,-,- X-VirusChecked: Checked Received: (qmail 13216 invoked from network); 16 Sep 2011 11:33:07 -0000 Received: from mo-p00-ob.rzone.de (HELO mo-p00-ob.rzone.de) (81.169.146.161) by server-8.tower-182.messagelabs.com with DHE-RSA-AES256-SHA encrypted SMTP; 16 Sep 2011 11:33:07 -0000 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; t=1316172787; l=1225; s=domk; d=aepfle.de; h=In-Reply-To:Content-Type:MIME-Version:References:Subject:Cc:To:From: Date:X-RZG-CLASS-ID:X-RZG-AUTH; bh=SgYhQhFXq0QNRYsd2UYt4Zu5rRs=; b=g1lVXitiKTkJ5TNN0TuLFwgGTL/LZ/d12Ni93fl30YbPSJRuAgvVK/IimFRlRobSLi5 SWNBGQbhh8YaoG8ls0d4gmfpUpsDnVmc5huvmHBc/FaY057JzEVZqNzsWQO2bGVQZdgsf OvcEE7yy2KRBnJRbIx7lzRkm/iTbv/oE4sc= X-RZG-AUTH: :P2EQZWCpfu+qG7CngxMFH1J+zrwiavkK6tmQaLfmztM8TOFPjzcQEc7tfA== X-RZG-CLASS-ID: mo00 Received: from probook.site (dslb-088-065-114-224.pools.arcor-ip.net [88.65.114.224]) by smtp.strato.de (jimi mo34) (RZmta 26.7) with (DHE-RSA-AES256-SHA encrypted) ESMTPA id j0172bn8GAweT5 ; Fri, 16 Sep 2011 13:32:55 +0200 (MEST) Received: by probook.site (Postfix, from userid 1000) id 73FA418B65; Fri, 16 Sep 2011 13:32:54 +0200 (CEST) Date: Fri, 16 Sep 2011 13:32:54 +0200 From: Olaf Hering To: Tim Deegan Subject: Re: [Xen-devel] [PATCH] xenpaging: track number of paged pages in struct domain Message-ID: <20110916113254.GA7332@aepfle.de> References: <13b4be345ebac016abe2.1316089567@probook.site> <20110916112403.GB95880@ocelot.phlegethon.org> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline In-Reply-To: <20110916112403.GB95880@ocelot.phlegethon.org> User-Agent: Mutt/1.5.21.rev5535 (2011-07-01) Cc: xen-devel@lists.xensource.com X-BeenThere: xen-devel@lists.xensource.com X-Mailman-Version: 2.1.5 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xensource.com Errors-To: xen-devel-bounces@lists.xensource.com On Fri, Sep 16, Tim Deegan wrote: > At 14:26 +0200 on 15 Sep (1316096767), Olaf Hering wrote: > > # HG changeset patch > > # User Olaf Hering > > # Date 1316089500 -7200 > > # Node ID 13b4be345ebac016abe26386417824a0c47d762d > > # Parent e90438f6e6d1585a71b18784a99c162b5d95f390 > > xenpaging: track number of paged pages in struct domain > > > > The toolstack should know how many pages are paged-out at a given point > > in time so it could make smarter decisions about how many pages should > > be paged or ballooned. > > > > Add a new member to xen_domctl_getdomaininfo and bump interface version. > > Use the new member in xc_dominfo_t. > > The SONAME of libxc should be changed if this patch gets applied. > > > > Signed-off-by: Olaf Hering > > For the xen parts, Acked-by: Tim Deegan > > Again, I'd like the tools maintainers to ack/nack the change to the domctl > interface and associated libxc plumbing. Thanks, but please wait a bit before applying it. Eventually a new XENMEM op is required as well to export that value for a guests balloon driver. I'm not finished yet with browsing the codepaths which make use of tot_pages. Olaf _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel From xen-devel-bounces@lists.xensource.com Fri Sep 16 05:40:15 2011 Return-path: Envelope-to: www-data@lists.xensource.com Delivery-date: Fri, 16 Sep 2011 05:40:15 -0700 Received: from localhost ([127.0.0.1] helo=lists.colo.xensource.com) by lists.xensource.com with esmtp (Exim 4.43) id 1R4XiJ-00059N-Ly; Fri, 16 Sep 2011 05:40:15 -0700 Received: from mail27.messagelabs.com ([193.109.254.147]) by lists.xensource.com with esmtp (Exim 4.43) id 1R4Xhh-0004wX-QB; Fri, 16 Sep 2011 05:39:38 -0700 X-Env-Sender: lars.kurth.xen@gmail.com X-Msg-Ref: server-15.tower-27.messagelabs.com!1316176766!49043885!1 X-Originating-IP: [209.85.161.43] X-StarScan-Version: 6.4.1; banners=-,-,- X-VirusChecked: Checked Received: (qmail 7779 invoked from network); 16 Sep 2011 12:39:26 -0000 Received: from mail-fx0-f43.google.com (HELO mail-fx0-f43.google.com) (209.85.161.43) by server-15.tower-27.messagelabs.com with RC4-SHA encrypted SMTP; 16 Sep 2011 12:39:26 -0000 Received: by fxh19 with SMTP id 19so2094967fxh.30 for ; Fri, 16 Sep 2011 05:39:34 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=sender:message-id:date:from:user-agent:mime-version:to:subject :content-type; bh=Oh1L7Lf1wG/TtOel0qNtz5ScsX5ANjAFD/kqsQiq+cM=; b=XcFxWqmXoRJn+Tl4GhFPJl9pJMiXLqIMtqlDTP7MmXucG6CDvWRdPiS+yB0gXDVTQ/ BT2Hs/qg+VRmukKlcjUQjSJ60DiumqSqkoZEk/tVeMr/fWA3P52SC0Kz6BpW1FOFcaVA aPD+/bCVa8QU0GIITYAGWKfzk3/plHKRZPXmw= Received: by 10.223.55.209 with SMTP id v17mr1265037fag.77.1316176774282; Fri, 16 Sep 2011 05:39:34 -0700 (PDT) Received: from [172.16.26.10] (p5498B189.dip.t-dialin.net. [84.152.177.137]) by mx.google.com with ESMTPS id f1sm2355902fab.19.2011.09.16.05.39.32 (version=SSLv3 cipher=OTHER); Fri, 16 Sep 2011 05:39:33 -0700 (PDT) Message-ID: <4E73437C.8000704@xen.org> Date: Fri, 16 Sep 2011 14:39:24 +0200 From: Lars Kurth User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:6.0.2) Gecko/20110902 Thunderbird/6.0.2 MIME-Version: 1.0 To: "xen-devel@lists.xensource.com" , xen-users@lists.xensource.com Cc: Subject: [Xen-devel] Scale x10 CFP open until Dec 3rd X-BeenThere: xen-devel@lists.xensource.com X-Mailman-Version: 2.1.5 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0163359455==" Sender: xen-devel-bounces@lists.xensource.com Errors-To: xen-devel-bounces@lists.xensource.com This is a multi-part message in MIME format. --===============0163359455== Content-Type: multipart/alternative; boundary="------------080509060505070901040709" This is a multi-part message in MIME format. --------------080509060505070901040709 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Hi everybody, I am planning to have a Xen booth at Scale x10 next year. Scale has a CFP open and it would be great if we have some paper submissions from the community there. See www.socallinuxexpo.org/cfp/cfp-information Regards Lars --------------080509060505070901040709 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Hi everybody,
I am planning to have a Xen booth at Scale x10 next year. Scale has a CFP open and it would be great if we have some paper submissions from the community there. See  www.socallinuxexpo.org/cfp/cfp-information
Regards
Lars
--------------080509060505070901040709-- --===============0163359455== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel --===============0163359455==-- From xen-devel-bounces@lists.xensource.com Fri Sep 16 07:08:45 2011 Return-path: Envelope-to: www-data@lists.xensource.com Delivery-date: Fri, 16 Sep 2011 07:08:45 -0700 Received: from localhost ([127.0.0.1] helo=lists.colo.xensource.com) by lists.xensource.com with esmtp (Exim 4.43) id 1R4Z5x-0000eh-F2; Fri, 16 Sep 2011 07:08:45 -0700 Received: from mail27.messagelabs.com ([193.109.254.147]) by lists.xensource.com with esmtp (Exim 4.43) id 1R4Z5R-0000Se-PW for xen-devel@lists.xensource.com; Fri, 16 Sep 2011 07:08:14 -0700 X-Env-Sender: JBeulich@suse.com X-Msg-Ref: server-10.tower-27.messagelabs.com!1316182071!36039172!1 X-Originating-IP: [130.57.49.28] X-StarScan-Version: 6.4.1; banners=-,-,- X-VirusChecked: Checked Received: (qmail 23716 invoked from network); 16 Sep 2011 14:07:51 -0000 Received: from nat28.tlf.novell.com (HELO nat28.tlf.novell.com) (130.57.49.28) by server-10.tower-27.messagelabs.com with DHE-RSA-AES256-SHA encrypted SMTP; 16 Sep 2011 14:07:51 -0000 Received: from EMEA1-MTA by nat28.tlf.novell.com with Novell_GroupWise; Fri, 16 Sep 2011 15:08:10 +0100 Message-Id: <4E73746702000078000568A0@nat28.tlf.novell.com> X-Mailer: Novell GroupWise Internet Agent 8.0.1 Date: Fri, 16 Sep 2011 15:08:07 +0100 From: "Jan Beulich" To: "Konrad Rzeszutek Wilk" Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: quoted-printable Content-Disposition: inline Cc: "xen-devel@lists.xensource.com" Subject: [Xen-devel] locking in drivers/xen/xen-pciback/passthrough.c:__xen_pcibk_publish_pci_roots() X-BeenThere: xen-devel@lists.xensource.com X-Mailman-Version: 2.1.5 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xensource.com Errors-To: xen-devel-bounces@lists.xensource.com Konrad, this function, before calling the passed in callback, drops the lock it acquired at the beginning of the function, and re-acquires it after the callback returned. It also uses list_for_each_entry_safe() in an apparent attempt to deal with races here. However, I'm getting the impression that this wouldn't really work (as the construct really isn't meant for this case): If in the meantime the successor element got removed from the list, the loop continuation would access data that may already have got freed. I see two possible solutions: Either after re-acquiring the lock the function checks whether the current object is sill on the list, starting over if not found (xen_pcibk_publish_pci_root() makes sure a device doesn't get published twice), or (if so possible) the lock gets converted to a mutex (which should be safe to be held across the callback invocation). What are your thoughts here? Jan _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel From xen-devel-bounces@lists.xensource.com Fri Sep 16 07:15:26 2011 Return-path: Envelope-to: www-data@lists.xensource.com Delivery-date: Fri, 16 Sep 2011 07:15:26 -0700 Received: from localhost ([127.0.0.1] helo=lists.colo.xensource.com) by lists.xensource.com with esmtp (Exim 4.43) id 1R4ZCP-00016e-U8; Fri, 16 Sep 2011 07:15:25 -0700 Received: from mail21.messagelabs.com ([85.158.143.35]) by lists.xensource.com with esmtp (Exim 4.43) id 1R4ZBu-0000uI-F5 for xen-devel@lists.xensource.com; Fri, 16 Sep 2011 07:14:54 -0700 X-Env-Sender: fantonifabio@tiscali.it X-Msg-Ref: server-14.tower-21.messagelabs.com!1316182481!59858446!1 X-Originating-IP: [216.139.236.26] X-StarScan-Version: 6.4.1; banners=-,-,- X-VirusChecked: Checked Received: (qmail 27297 invoked from network); 16 Sep 2011 14:14:43 -0000 Received: from sam.nabble.com (HELO sam.nabble.com) (216.139.236.26) by server-14.tower-21.messagelabs.com with AES256-SHA encrypted SMTP; 16 Sep 2011 14:14:43 -0000 Received: from [192.168.236.26] (helo=sam.nabble.com) by sam.nabble.com with esmtp (Exim 4.72) (envelope-from ) id 1R4ZBm-0001oU-CS for xen-devel@lists.xensource.com; Fri, 16 Sep 2011 07:14:46 -0700 Date: Fri, 16 Sep 2011 07:14:46 -0700 (PDT) From: Fantu To: xen-devel@lists.xensource.com Message-ID: <1316182486379-4810847.post@n5.nabble.com> In-Reply-To: <1316105794010-4807540.post@n5.nabble.com> References: <1316011454156-4803078.post@n5.nabble.com> <20110914145403.GA17899@phenom.oracle.com> <1316097409687-4807062.post@n5.nabble.com> <20110915145840.GA20726@phenom.oracle.com> <1316105794010-4807540.post@n5.nabble.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Subject: [Xen-devel] Re: Out sw-iommu space problem X-BeenThere: xen-devel@lists.xensource.com X-Mailman-Version: 2.1.5 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xensource.com Errors-To: xen-devel-bounces@lists.xensource.com I have rebuild last debian kernel linux-image-2.6.32-5-xen-amd64_2.6.32-36_amd64 with patch take here: http://www.gossamer-threads.com/lists/xen/devel/216753 Installed, reboot the dom0, retry service xendomains stop (with save of all domus) but problem persist: Sep 16 15:58:42 heliMN02WV kernel: [ 1091.311783] tapdisk2[7567]: segfault at 7fffcb57cff8 ip 000000000040844f sp 00007fffcb57d000 error 6 in tapdisk2[400000+39000] Sep 16 15:58:42 heliMN02WV kernel: [ 1091.331392] BUG: unable to handle kernel NULL pointer dereference at 0000000000000048 Sep 16 15:58:42 heliMN02WV kernel: [ 1091.331532] IP: [] apply_to_page_range+0x47/0x2f3 Sep 16 15:58:42 heliMN02WV kernel: [ 1091.331623] PGD 2d158067 PUD 2c03e067 PMD 0 Sep 16 15:58:42 heliMN02WV kernel: [ 1091.331766] Oops: 0000 [#1] SMP Sep 16 15:58:42 heliMN02WV kernel: [ 1091.331878] last sysfs file: /sys/devices/virtual/blktap2/blktap6/remove Sep 16 15:58:42 heliMN02WV kernel: [ 1091.331936] CPU 0 Sep 16 15:58:42 heliMN02WV kernel: [ 1091.332016] Modules linked in: xt_tcpudp tun xt_physdev iptable_filter ip_tables x_tables bridge stp ib_iser rdma_cm ib_cm iw_cm ib_sa ib_mad ib_core ib_addr iscsi_tcp libiscsi_tcp libiscsi scsi_transport_iscsi ext2 sha256_generic aes_x86_64 aes_generic cbc blktap xen_evtchn xenfs loop dm_crypt snd_pcm snd_timer snd soundcore snd_page_alloc joydev pcspkr evdev processor dcdbas button power_meter acpi_processor ext4 mbcache jbd2 crc16 dm_mod sd_mod crc_t10dif sg sr_mod cdrom usbhid hid ata_generic ata_piix libata mpt2sas ehci_hcd scsi_transport_sas bnx2 usbcore nls_base scsi_mod thermal thermal_sys [last unloaded: scsi_wait_scan] Sep 16 15:58:42 heliMN02WV kernel: [ 1091.334357] Pid: 7567, comm: tapdisk2 Not tainted 2.6.32-5-xen-amd64 #1 PowerEdge T310 Sep 16 15:58:42 heliMN02WV kernel: [ 1091.334431] RIP: e030:[] [] apply_to_page_range+0x47/0x2f3 Sep 16 15:58:42 heliMN02WV kernel: [ 1091.334539] RSP: e02b:ffff88002c777b58 EFLAGS: 00010202 Sep 16 15:58:42 heliMN02WV kernel: [ 1091.334594] RAX: 0000000000000880 RBX: ffff88003e7ac000 RCX: ffff88003e7ad000 Sep 16 15:58:42 heliMN02WV kernel: [ 1091.334652] RDX: 0000000000000000 RSI: ffff88003e7ac000 RDI: 0000000000000000 Sep 16 15:58:42 heliMN02WV kernel: [ 1091.334710] RBP: ffff88003f100c90 R08: 0000000000000000 R09: ffff88003c635000 Sep 16 15:58:42 heliMN02WV kernel: [ 1091.334768] R10: 0000000000000002 R11: 0000000000000000 R12: 0000000000000000 Sep 16 15:58:42 heliMN02WV kernel: [ 1091.334826] R13: ffff88003f100c90 R14: ffff880003355000 R15: 0000000000000000 Sep 16 15:58:42 heliMN02WV kernel: [ 1091.334887] FS: 00007fde823cc740(0000) GS:ffff8800036f1000(0000) knlGS:0000000000000000 Sep 16 15:58:42 heliMN02WV kernel: [ 1091.334961] CS: e033 DS: 0000 ES: 0000 CR0: 000000008005003b Sep 16 15:58:42 heliMN02WV kernel: [ 1091.335017] CR2: 0000000000000048 CR3: 000000002ca26000 CR4: 0000000000002660 Sep 16 15:58:42 heliMN02WV kernel: [ 1091.335075] DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 Sep 16 15:58:42 heliMN02WV kernel: [ 1091.335133] DR3: 0000000000000000 DR6: 00000000ffff0ff0 DR7: 0000000000000400 Sep 16 15:58:42 heliMN02WV kernel: [ 1091.335191] Process tapdisk2 (pid: 7567, threadinfo ffff88002c776000, task ffff8800031cc6a0) Sep 16 15:58:42 heliMN02WV kernel: [ 1091.335266] Stack: Sep 16 15:58:42 heliMN02WV kernel: [ 1091.335314] 0000000000000000 ffff88003e8add80 0000000000000000 0000000000000000 Sep 16 15:58:42 heliMN02WV kernel: [ 1091.335464] <0> ffffffffa02dcee8 0000000000000000 ffffffff8100ecf2 ffff8800370616c0 Sep 16 15:58:42 heliMN02WV kernel: [ 1091.335689] <0> ffff88003e7ad000 0000000000000000 0000000000000000 ffff8800370616c0 Sep 16 15:58:42 heliMN02WV kernel: [ 1091.335970] Call Trace: Sep 16 15:58:42 heliMN02WV kernel: [ 1091.336026] [] ? blktap_umap_uaddr_fn+0x0/0x59 [blktap] Sep 16 15:58:42 heliMN02WV kernel: [ 1091.336089] [] ? check_events+0x12/0x20 Sep 16 15:58:42 heliMN02WV kernel: [ 1091.336147] [] ? blktap_device_end_request+0xbd/0x145 [blktap] Sep 16 15:58:42 heliMN02WV kernel: [ 1091.336229] [] ? blktap_ring_vm_close+0x60/0xd1 [blktap] Sep 16 15:58:42 heliMN02WV kernel: [ 1091.336292] [] ? remove_vma+0x2c/0x72 Sep 16 15:58:42 heliMN02WV kernel: [ 1091.336355] [] ? exit_mmap+0x129/0x148 Sep 16 15:58:42 heliMN02WV kernel: [ 1091.336419] [] ? mmput+0x3c/0xdf Sep 16 15:58:42 heliMN02WV kernel: [ 1091.336476] [] ? exit_mm+0x102/0x10d Sep 16 15:58:42 heliMN02WV kernel: [ 1091.336536] [] ? _spin_lock_irq+0x7/0x22 Sep 16 15:58:42 heliMN02WV kernel: [ 1091.336595] [] ? do_exit+0x1f8/0x6c6 Sep 16 15:58:42 heliMN02WV kernel: [ 1091.336652] [] ? __dequeue_signal+0xfb/0x124 Sep 16 15:58:42 heliMN02WV kernel: [ 1091.336713] [] ? xen_restore_fl_direct_end+0x0/0x1 Sep 16 15:58:42 heliMN02WV kernel: [ 1091.336776] [] ? kmem_cache_free+0x72/0xa3 Sep 16 15:58:42 heliMN02WV kernel: [ 1091.336839] [] ? do_group_exit+0x76/0x9d Sep 16 15:58:42 heliMN02WV kernel: [ 1091.336901] [] ? get_signal_to_deliver+0x310/0x339 Sep 16 15:58:42 heliMN02WV kernel: [ 1091.336965] [] ? do_notify_resume+0x87/0x73f Sep 16 15:58:42 heliMN02WV kernel: [ 1091.337030] [] ? expand_downwards+0x5b/0x169 Sep 16 15:58:42 heliMN02WV kernel: [ 1091.337087] [] ? do_page_fault+0x1f5/0x2fc Sep 16 15:58:42 heliMN02WV kernel: [ 1091.337144] [] ? retint_signal+0x48/0x8c Sep 16 15:58:42 heliMN02WV kernel: [ 1091.337200] Code: 48 89 4c 24 20 4c 89 44 24 18 48 89 54 24 40 72 04 0f 0b eb fe 48 8b 54 24 28 48 89 f0 48 8b 4c 24 40 48 c1 e8 24 25 f8 0f 00 00 <48> 8b 52 48 48 ff c9 48 89 0c 24 48 01 d0 48 89 44 24 30 48 b8 Sep 16 15:58:42 heliMN02WV kernel: [ 1091.339270] RIP [] apply_to_page_range+0x47/0x2f3 Sep 16 15:58:42 heliMN02WV kernel: [ 1091.339358] RSP Sep 16 15:58:42 heliMN02WV kernel: [ 1091.339409] CR2: 0000000000000048 Sep 16 15:58:42 heliMN02WV kernel: [ 1091.339461] ---[ end trace d3d83b6017665ae2 ]--- Sep 16 15:58:42 heliMN02WV kernel: [ 1091.339514] Fixing recursive fault but reboot is needed! -- View this message in context: http://xen.1045712.n5.nabble.com/Out-sw-iommu-space-problem-tp4803078p4810847.html Sent from the Xen - Dev mailing list archive at Nabble.com. _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel From xen-devel-bounces@lists.xensource.com Fri Sep 16 07:52:50 2011 Return-path: Envelope-to: www-data@lists.xensource.com Delivery-date: Fri, 16 Sep 2011 07:52:50 -0700 Received: from localhost ([127.0.0.1] helo=lists.colo.xensource.com) by lists.xensource.com with esmtp (Exim 4.43) id 1R4Zmc-0002Ca-5T; Fri, 16 Sep 2011 07:52:50 -0700 Received: from mail27.messagelabs.com ([193.109.254.147]) by lists.xensource.com with esmtp (Exim 4.43) id 1R4Zlt-00020S-HQ; Fri, 16 Sep 2011 07:52:05 -0700 X-Env-Sender: pasik@iki.fi X-Msg-Ref: server-3.tower-27.messagelabs.com!1316184699!39961589!1 X-Originating-IP: [192.89.123.25] X-StarScan-Version: 6.4.1; banners=-,-,- X-VirusChecked: Checked Received: (qmail 14732 invoked from network); 16 Sep 2011 14:51:40 -0000 Received: from smtp.tele.fi (HELO smtp.tele.fi) (192.89.123.25) by server-3.tower-27.messagelabs.com with DHE-RSA-AES256-SHA encrypted SMTP; 16 Sep 2011 14:51:40 -0000 X-Originating-Ip: [194.89.68.22] Received: from ydin.reaktio.net (reaktio.net [194.89.68.22]) by smtp.tele.fi (Postfix) with ESMTP id 07AE8272D; Fri, 16 Sep 2011 17:52:00 +0300 (EEST) Received: by ydin.reaktio.net (Postfix, from userid 1001) id E04E9200E8; Fri, 16 Sep 2011 17:51:59 +0300 (EEST) Date: Fri, 16 Sep 2011 17:51:59 +0300 From: Pasi =?iso-8859-1?Q?K=E4rkk=E4inen?= To: "Richard W.M. Jones" Subject: Re: [Xen-devel] Re: Virtualization Test Day for F16 and Xen Message-ID: <20110916145159.GY12984@reaktio.net> References: <20110914112552.GP12984@reaktio.net> <20110914142522.GA16956@phenom.oracle.com> <20110914144539.GR12984@reaktio.net> <20110915151041.GA4453@imp.local> <1316126290.5689.3.camel@adam> <20110916110840.GA14613@amd.home.annexia.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20110916110840.GA14613@amd.home.annexia.org> User-Agent: Mutt/1.5.18 (2008-05-17) Cc: Development discussions related to Fedora , xen@lists.fedoraproject.org, xen-devel@lists.xensource.com, Konrad Rzeszutek Wilk , lars.kurth@xen.org, virt@lists.fedoraproject.org, xen-users@lists.xensource.com X-BeenThere: xen-devel@lists.xensource.com X-Mailman-Version: 2.1.5 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xensource.com Errors-To: xen-devel-bounces@lists.xensource.com On Fri, Sep 16, 2011 at 12:08:40PM +0100, Richard W.M. Jones wrote: > On Fri, Sep 16, 2011 at 12:14:23PM +0300, Myroslav Opyr wrote: > > Hi, > > > > What Xen implementation is considered "supported" for FC16 DomU? > > Any commonly available upstream Xen releases. > > Fedora itself > (ie. https://fedoraproject.org/wiki/Features/XenPvopsDom0). > I think Fedora itself currently has Xen 4.1.1 in F15 and F16. > Also Xen in RHEL 5, although that's more of a thing for Red Hat to > worry about. > Actually F16 PV domU fails to start with vfb (graphical console) on RHEL5 dom0, the vfb never gets to fully initialized state.. so vncviewer won't work for the console. F15 and earlier versions do work OK with pvfb on the same RHEL5 dom0. I'll report to redhat bugzilla soon.. > > I'm asking because on "Xen implementation" we were testing yesterday > > FC16 DomU installation failed compared to FC15 DomU success on the > > very same Dom0. Are failures like we've encountered candidates for > > bugreports? > > Yes. > Yeah.. it could be the xen-kbdfront issue.. (it's missing from the F16 installer kernel/initrd). > > Is there a place (wikipage, bugzilla keyword, etc.) to collect > > Fedora 16 Xen issues? > > https://bugzilla.redhat.com/ > > Product: Fedora. Component: depends on what is failing but common > ones would be "kernel", "anaconda", "grubby", "grub2", "xen", and > "libvirt". > > There is also a Fedora Xen mailing list where you can get more > detailed help: > > https://lists.fedoraproject.org/mailman/listinfo/xen > -- Pasi > Rich. > > -- > Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones > Read my programming blog: http://rwmj.wordpress.com > Fedora now supports 80 OCaml packages (the OPEN alternative to F#) > http://cocan.org/getting_started_with_ocaml_on_red_hat_and_fedora > > _______________________________________________ > Xen-devel mailing list > Xen-devel@lists.xensource.com > http://lists.xensource.com/xen-devel _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel From xen-users-bounces@lists.xensource.com Fri Sep 16 07:57:29 2011 Return-path: Envelope-to: www-data@lists.xensource.com Delivery-date: Fri, 16 Sep 2011 07:57:29 -0700 Received: from localhost ([127.0.0.1] helo=lists.colo.xensource.com) by lists.xensource.com with esmtp (Exim 4.43) id 1R4Zr7-0003QL-DT; Fri, 16 Sep 2011 07:57:29 -0700 Received: from mail27.messagelabs.com ([193.109.254.147]) by lists.xensource.com with smtp (Exim 4.43) id 1R4Zpd-000347-F6 for xen-users@lists.xensource.com; Fri, 16 Sep 2011 07:56:01 -0700 X-Env-Sender: jim_burn@bellsouth.net X-Msg-Ref: server-14.tower-27.messagelabs.com!1316184939!36441776!1 X-Originating-IP: [98.139.44.186] X-StarScan-Version: 6.4.1; banners=-,-,- X-VirusChecked: Checked Received: (qmail 16285 invoked from network); 16 Sep 2011 14:55:39 -0000 Received: from nm26-vm0.access.bullet.mail.sp2.yahoo.com (HELO nm26-vm0.access.bullet.mail.sp2.yahoo.com) (98.139.44.186) by server-14.tower-27.messagelabs.com with SMTP; 16 Sep 2011 14:55:39 -0000 Received: from [98.139.44.96] by nm26.access.bullet.mail.sp2.yahoo.com with NNFMP; 16 Sep 2011 14:55:52 -0000 Received: from [98.139.44.85] by tm1.access.bullet.mail.sp2.yahoo.com with NNFMP; 16 Sep 2011 14:55:52 -0000 Received: from [127.0.0.1] by omp1022.access.mail.sp2.yahoo.com with NNFMP; 16 Sep 2011 14:55:52 -0000 X-Yahoo-Newman-Id: 563351.85770.bm@omp1022.access.mail.sp2.yahoo.com Received: (qmail 73628 invoked from network); 16 Sep 2011 14:55:52 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=bellsouth.net; s=s1024; t=1316184951; bh=QgfeQD/O4INuAHPPudPlWxSgA8N13kk7dfx55REuP0w=; h=X-Yahoo-Newman-Property:X-YMail-OSG:X-Yahoo-SMTP:Received:From:To:Cc:Subject:Date:Message-ID:User-Agent:In-Reply-To:References:MIME-Version:Content-Transfer-Encoding:Content-Type; b=O+9T1vLM+SLSfrDhNtnaIwOmNHc7Tbjw1G6SPOnisO5fbuESpfWs5iEHF5VHMTdncT61wyc/9fad6s3oP4MX3pgGW5ckbp1bMN3q+VBRvsLBkWwnjvepSymEseLCyACpottoyw0J5ulHF5F8aWKGRGTe6ljjWL9Cl4q9wsRXEaU= X-Yahoo-Newman-Property: ymail-3 X-YMail-OSG: hi6llUwVM1kXEF4L_SRBSXcPRE8_BrSB3CaB7dukAXoWwZU XyjQIuwPR1ZBEGaWoB9yKGDh3pZlZvObbArqF7n5Pt1qP8eNvu3VbuSxVPeu Zx.3EZ_6xwRqpbnoAQVKgY8tnozCRk8SVcjw7hf1IglZahOeh03PBwlTS6UR cG.rav0B7g_VvsyRXEZIJMxi.LvfbwhuypGCf5wT13J6VhnOosuxo_At6RMc 1Bx0wckP0OL9HMv5UQ5I67FqoT14z7NzjmneUTE9eX7YgyKovnwt2gdSPNDU m71UR1BBk5wyQU7GmfuUqEwhME.Kqf7eSiPy_sjN8cRns0n4DbhsZOJo6JkB fIRYRJkWEGPQ1LLEBxmcG8NPaNVdsexC8zeCrS6xCMJQAn6ofBiSNVxSm0_. RJJOxa018Ll.gh_f_tV_1gEX3Qbdsn2n1QObzqYgoML3vP18J65q1zFW4q.. nE0rp.NMvzQMgb3.ZH3ukY0c_sV3rRyg4xmsSUK6Z6hm5P9CnIUBdngAevZb ukrhqlsABYGtHt94g2uvDl.R8DIW1YBMWeW8_k6t255QeEvueqmVRUylHixN UNCCpAJWWCztzU9OVbU307gFqYLvl9jgcnPVGC.YS8FlyZsM8Qiu9rDd_Dql lZYMEhUSUS1q7_1bcllpi5CRiGEQ3eMI0r60e X-Yahoo-SMTP: g0AhWW2swBA2djJKuhuwxPlPqLrHlDrycdPnfR9kZNrpKCA- Received: from dell4550.localnet (jim_burn@74.190.198.215 with plain) by smtp110.sbc.mail.gq1.yahoo.com with SMTP; 16 Sep 2011 07:55:49 -0700 PDT From: jim burns To: Konrad Rzeszutek Wilk Subject: Re: [Fedora-xen] [Xen-devel] Re: [Xen-users] Continuing BUG:-iness booting Fedora Rawhide 3.1.0-rc's (was Summary: Experiences setting up a debug serial port) Date: Fri, 16 Sep 2011 10:55:38 -0400 Message-ID: <2531823.kDgpVeQNv3@dell4550> User-Agent: KMail/4.7.1 (Linux/2.6.37.6-0.7-default; KDE/4.7.1; i686; ; ) In-Reply-To: <20110915075358.GA4396@phenom.oracle.com> References: <201107231426.56811.jim_burn@bellsouth.net> <20110915075358.GA4396@phenom.oracle.com> MIME-Version: 1.0 Content-Transfer-Encoding: 7Bit Content-Type: text/plain; charset="us-ascii" Cc: xen-devel@lists.xensource.com, Fedora Xen List , pasik@iki.fi, Ian Campbell , M A Young , xen-users@lists.xensource.com X-BeenThere: xen-users@lists.xensource.com X-Mailman-Version: 2.1.5 Precedence: list List-Id: Xen user discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-users-bounces@lists.xensource.com Errors-To: xen-users-bounces@lists.xensource.com On Thu September 15 2011, 3:53:58 AM, Konrad Rzeszutek Wilk wrote: > On Wed, Sep 14, 2011 at 09:18:25PM -0400, jim burns wrote: > > On Thu September 15 2011, 12:38:26 AM, M A Young wrote: > > > I have a (temporary) F17 kernel with the patch from > > > http://oss.oracle.com/git/kwilk/xen.git/?p=kwilk/xen.git;a=commit;h=a7079a64 > > > 04ed2106315327fff6be3464d10814e7 (which I assume is the same patch) > > > applied building at > > > http://koji.fedoraproject.org/koji/taskinfo?taskID=3352367 > > > if you want to test it. > > > > Oh - the patch is to the kernel, not to xen. I misread it. > > > > Ok - I downloaded > > http://koji.fedoraproject.org/koji/getfile?taskID=3352368&name=kernel-3.1.0-0.rc6.git0.0.xendom0.fc17.x86_64.rpm > > > > I hope that's right. I'll try it tomorrow. Thanx. > > ping? Echo reply - router congestion. Testing out myoung's 3.1.0 was not as straight forward as I had hoped. It did boot up without any BUG:s, but I did get the occasional Lock Order message. Log snippet at the end of the post. It doesn't seem to be directly related to starting guests. The real problem comes in starting up guests. Performance is very bad. I knew from working with rawhide 3.0.0 (long since replaced) that performance would suffer - rawhide kernels are debug kernels: jimb@insp6400 09/16/11 10:16AM:~ [511] > grep DEBUG /boot/config-3.1.0-0.rc6.git0.0.xendom0.fc17.x86_64|grep -v 'is not set'|wc -l 91 jimb@insp6400 09/16/11 10:16AM:~ [512] > grep DEBUG /boot/config-2.6.40.4-5.fc15.x86_64|grep -v 'is not set'|wc -l 54 jimb@insp6400 09/16/11 10:18AM:~ [513] > grep DEBUG /boot/config-3.0.1-3.fc16.x86_64|grep -v 'is not set'|wc -l 90 Starting guests is much slower under myoung's 3.1.0 than under rawhide's 3.1.0 or 3.0.{0,1}. A cifs backed pv domu took 6 min. for 'xm create' to exit, during most of which, dom0 was totally unresponsive, and another 2 min. to get to the login screen. The 2nd attempt took 4 min. to get to the login screen - presumably the cifs file backed domu was still partially cached. (When I say unresponsive, I mean userland. I have a client computer with an iscsi target, and cifs/nfs connections to the dom0, and I was still getting slow traffic (presumably interrupt based, keep alive signals), and the dom0 hard disk light was constantly blinking.) Starting a winxp domu was much worse. 'xm create' totally locked up my dom0, so that I had to reboot. One time, I took a nap after starting the domu, and got up 4 hrs. later, and dom0 was still locked up. 'xm create' did not provide any diagnostic information. 'xl create' was a little more chatty: root@insp6400 09/16/11 12:09AM:~ [544] > xl create Documents/winxp; brctl show; ps -A|grep qemu; netstat -tlp| grep 59; renice -11 `pidof qemu-dm`; ps -A|grep vncv; ifconfig vif1.0 mtu 9000 Parsing config file Documents/winxp xc: info: VIRTUAL MEMORY ARRANGEMENT: Loader: 0000000000100000->000000000017b270 TOTAL: 0000000000000000->000000003fc00000 ENTRY ADDRESS: 00000000001015a0 xc: error: Could not allocate memory for HVM guest. (16 = Device or resource busy): Internal error libxl: error: libxl_dom.c:284:libxl__build_hvm hvm building failed and my serial debug log had several: (XEN) memory.c:133:d0 Could not allocate order=9 extent: id=1 memflags=0 (1 of 4) (XEN) memory.c:133:d0 Could not allocate order=9 extent: id=1 memflags=0 (0 of 4) (XEN) memory.c:133:d0 Could not allocate order=9 extent: id=1 memflags=0 (0 of 4) (XEN) memory.c:133:d0 Could not allocate order=9 extent: id=1 memflags=0 (0 of 4) (XEN) memory.c:133:d0 Could not allocate order=9 extent: id=1 memflags=0 (0 of 4) (XEN) memory.c:133:d0 Could not allocate order=9 extent: id=1 memflags=0 (0 of 4) (XEN) memory.c:133:d0 Could not allocate order=9 extent: id=1 memflags=0 (0 of 4) (XEN) memory.c:133:d0 Could not allocate order=9 extent: id=1 memflags=0 (0 of 4) (XEN) memory.c:133:d0 Could not allocate order=9 extent: id=1 memflags=0 (0 of 4) (XEN) memory.c:133:d0 Could not allocate order=9 extent: id=1 memflags=0 (0 of 4) (XEN) memory.c:133:d0 Could not allocate order=9 extent: id=1 memflags=0 (0 of 4) (XEN) memory.c:133:d0 Could not allocate order=9 extent: id=1 memflags=0 (0 of 4) (XEN) memory.c:133:d0 Could not allocate order=9 extent: id=1 memflags=0 (0 of 4) (XEN) memory.c:133:d0 Could not allocate order=9 extent: id=1 memflags=0 (0 of 4) (XEN) memory.c:133:d0 Could not allocate order=9 extent: id=1 memflags=0 (0 of 4) (XEN) memory.c:133:d0 Could not allocate order=9 extent: id=1 memflags=0 (0 of 4) (XEN) memory.c:133:d0 Could not allocate order=9 extent: id=1 memflags=0 (0 of 4) (XEN) memory.c:133:d0 Could not allocate order=9 extent: id=1 memflags=0 (0 of 4) (XEN) memory.c:133:d0 Could not allocate order=9 extent: id=1 memflags=0 (0 of 4) (XEN) memory.c:133:d0 Could not allocate order=9 extent: id=1 memflags=0 (0 of 4) (XEN) memory.c:133:d0 Could not allocate order=9 extent: id=1 memflags=0 (0 of 4) (XEN) memory.c:133:d0 Could not allocate order=9 extent: id=1 memflags=0 (0 of 4) (XEN) memory.c:133:d0 Could not allocate order=9 extent: id=1 memflags=0 (0 of 4) (XEN) memory.c:133:d0 Could not allocate order=9 extent: id=1 memflags=0 (0 of 4) (XEN) memory.c:133:d0 Could not allocate order=0 extent: id=1 memflags=0 (439 of 2048) Then I remembered that I recently upped the memory allocation for my winxp domu, from 512 to 768. This works fine under 2.6.40, the f15 non-debug production kernel. None the less, I knocked the allocation back down to 512, and my winxp domu did start up, getting to the qemu splash screen in about 2 - 3 min., during part of which dom0 was unresponsive. However, I'm still getting the '(XEN) memory.c' errors, and some frequent GPF errors (a few a min.) in my serial debug log: (XEN) traps.c:2956: GPF (0060): ffff82c48015354a -> ffff82c480200131 Then, rawhide and gplpv don't get along. Specifically, the xennet receive side driver stops working, and I have to fall back to qemu emulation. It takes about an hour for the winxp desktop to finish initializing, with dom0 cpu load on one cpu core at 72% - yum! But I'll just have to live with it - it's not your problem. I'll leave it up for at least a day to see if any other messages pop up. Hope this was of some help. Lock Order /var/log/messages snippet: Sep 16 01:10:19 Insp6400 kernel: [ 473.537933] ====================================================== Sep 16 01:10:19 Insp6400 kernel: [ 473.537933] [ INFO: HARDIRQ-safe -> HARDIRQ-unsafe lock order detected ] Sep 16 01:10:19 Insp6400 kernel: [ 473.537933] 3.1.0-0.rc6.git0.0.xendom0.fc17.x86_64 #1 Sep 16 01:10:19 Insp6400 kernel: [ 473.537933] ------------------------------------------------------ Sep 16 01:10:19 Insp6400 kernel: [ 473.537933] swapper/0 [HC0[0]:SC1[3]:HE0:SE0] is trying to acquire: Sep 16 01:10:19 Insp6400 kernel: [ 473.537933] (nf_conntrack_lock){+.-...}, at: [] destroy_conntrack+0x70/0xec [nf_conntrack] Sep 16 01:10:19 Insp6400 kernel: [ 473.537933] Sep 16 01:10:19 Insp6400 kernel: [ 473.537933] and this task is already holding: Sep 16 01:10:19 Insp6400 kernel: [ 473.537933] (&(&bp->lock)->rlock) {-.-.-.}, at: [] b44_poll+0x28/0x3ec [b44] Sep 16 01:10:19 Insp6400 kernel: [ 473.541175] which would create a new lock dependency: Sep 16 01:10:19 Insp6400 kernel: [ 473.541175] (&(&bp->lock)->rlock){-.-.-.} -> (nf_conntrack_lock){+.-...} Sep 16 01:10:19 Insp6400 kernel: [ 473.541175] Sep 16 01:10:19 Insp6400 kernel: [ 473.541175] but this new dependency connects a HARDIRQ-irq-safe lock: Sep 16 01:10:19 Insp6400 kernel: [ 473.541175] (&(&bp->lock)->rlock){-.-.-.} Sep 16 01:10:19 Insp6400 kernel: [ 473.541175] ... which became HARDIRQ-irq- safe at: Sep 16 01:10:19 Insp6400 kernel: [ 473.541175] [] __lock_acquire+0x2ce/0xd0c Sep 16 01:10:19 Insp6400 kernel: [ 473.541175] [] lock_acquire+0xf3/0x13e Sep 16 01:10:19 Insp6400 kernel: [ 473.541175] [] _raw_spin_lock+0x45/0x79 Sep 16 01:10:19 Insp6400 kernel: [ 473.541175] [] b44_interrupt+0x25/0xd9 [b44] Sep 16 01:10:19 Insp6400 kernel: [ 473.541175] [] handle_irq_event_percpu+0xb4/0x271 Sep 16 01:10:19 Insp6400 kernel: [ 473.541175] [] handle_irq_event+0x47/0x67 Sep 16 01:10:19 Insp6400 kernel: [ 473.541175] [] handle_fasteoi_irq+0x8a/0xb0 Sep 16 01:10:19 Insp6400 kernel: [ 473.541175] [] __xen_evtchn_do_upcall+0x15e/0x203 Sep 16 01:10:19 Insp6400 kernel: [ 473.541175] [] xen_evtchn_do_upcall+0x2c/0x3e Sep 16 01:10:19 Insp6400 kernel: [ 473.541175] [] xen_do_hypervisor_callback+0x1e/0x30 Sep 16 01:10:19 Insp6400 kernel: [ 473.541175] Sep 16 01:10:19 Insp6400 kernel: [ 473.541175] to a HARDIRQ-irq-unsafe lock: Sep 16 01:10:19 Insp6400 kernel: [ 473.541175] (nf_conntrack_lock){+.-...} Sep 16 01:10:19 Insp6400 kernel: [ 473.541175] ... which became HARDIRQ-irq- unsafe at: Sep 16 01:10:19 Insp6400 kernel: [ 473.541175] ... [] __lock_acquire+0x345/0xd0c Sep 16 01:10:19 Insp6400 kernel: [ 473.541175] [] lock_acquire+0xf3/0x13e Sep 16 01:10:19 Insp6400 kernel: [ 473.541175] [] _raw_spin_lock_bh+0x4a/0x7e Sep 16 01:10:19 Insp6400 kernel: [ 473.541175] [] nf_conntrack_in+0x461/0x7dc [nf_conntrack] Sep 16 01:10:19 Insp6400 kernel: [ 473.541175] [] ipv4_conntrack_in+0x21/0x23 [nf_conntrack_ipv4] Sep 16 01:10:19 Insp6400 kernel: [ 473.541175] [] nf_iterate+0x4c/0x8c Sep 16 01:10:19 Insp6400 kernel: [ 473.541175] [] nf_hook_slow+0x7c/0x123 Sep 16 01:10:19 Insp6400 kernel: [ 473.541175] [] NF_HOOK.constprop.4+0x46/0x5a Sep 16 01:10:19 Insp6400 kernel: [ 473.541175] [] ip_rcv+0x239/0x264 Sep 16 01:10:19 Insp6400 kernel: [ 473.541175] [] __netif_receive_skb+0x4af/0x508 Sep 16 01:10:19 Insp6400 kernel: [ 473.541175] [] process_backlog+0x8a/0x151 Sep 16 01:10:19 Insp6400 kernel: [ 473.541175] [] net_rx_action+0xae/0x21c Sep 16 01:10:19 Insp6400 kernel: [ 473.541175] [] __do_softirq+0x112/0x25a Sep 16 01:10:19 Insp6400 kernel: [ 473.541175] [] call_softirq+0x1c/0x30 Sep 16 01:10:19 Insp6400 kernel: [ 473.541175] [] do_softirq+0x4b/0xa2 Sep 16 01:10:19 Insp6400 kernel: [ 473.541175] [] irq_exit+0x5d/0xcf Sep 16 01:10:19 Insp6400 kernel: [ 473.541175] [] xen_evtchn_do_upcall+0x31/0x3e Sep 16 01:10:19 Insp6400 kernel: [ 473.541175] [] xen_do_hypervisor_callback+0x1e/0x30 Sep 16 01:10:19 Insp6400 kernel: [ 473.541175] Sep 16 01:10:19 Insp6400 kernel: [ 473.541175] other info that might help us debug this: Sep 16 01:10:19 Insp6400 kernel: [ 473.541175] Sep 16 01:10:19 Insp6400 kernel: [ 473.541175] Possible interrupt unsafe locking scenario: Sep 16 01:10:19 Insp6400 kernel: [ 473.541175] Sep 16 01:10:19 Insp6400 kernel: [ 473.541175] CPU0 CPU1 Sep 16 01:10:19 Insp6400 kernel: [ 473.541175] ---- ---- Sep 16 01:10:19 Insp6400 kernel: [ 473.541175] lock(nf_conntrack_lock); Sep 16 01:10:19 Insp6400 kernel: [ 473.541175] local_irq_disable(); Sep 16 01:10:19 Insp6400 kernel: [ 473.541175] lock(&(&bp->lock)->rlock); Sep 16 01:10:19 Insp6400 kernel: [ 473.541175] lock(nf_conntrack_lock); Sep 16 01:10:19 Insp6400 kernel: [ 473.541175] Sep 16 01:10:19 Insp6400 kernel: [ 473.541175] lock(&(&bp->lock)->rlock); Sep 16 01:10:19 Insp6400 kernel: [ 473.537933] Sep 16 01:10:19 Insp6400 kernel: [ 473.537933] ====================================================== Sep 16 01:10:19 Insp6400 kernel: [ 473.537933] [ INFO: HARDIRQ-safe -> HARDIRQ-unsafe lock order detected ] Sep 16 01:10:19 Insp6400 kernel: [ 473.537933] 3.1.0-0.rc6.git0.0.xendom0.fc17.x86_64 #1 Sep 16 01:10:19 Insp6400 kernel: [ 473.537933] ------------------------------------------------------ Sep 16 01:10:19 Insp6400 kernel: [ 473.537933] swapper/0 [HC0[0]:SC1[3]:HE0:SE0] is trying to acquire: Sep 16 01:10:19 Insp6400 kernel: [ 473.537933] (nf_conntrack_lock){+.-...}, at: [] destroy_conntrack+0x70/0xec [nf_conntrack] Sep 16 01:10:19 Insp6400 kernel: [ 473.537933] Sep 16 01:10:19 Insp6400 kernel: [ 473.537933] and this task is already holding: Sep 16 01:10:19 Insp6400 kernel: [ 473.537933] (&(&bp->lock)->rlock) {-.-.-.}, at: [] b44_poll+0x28/0x3ec [b44] Sep 16 01:10:19 Insp6400 kernel: [ 473.541175] which would create a new lock dependency: Sep 16 01:10:19 Insp6400 kernel: [ 473.541175] (&(&bp->lock)->rlock){-.-.-.} -> (nf_conntrack_lock){+.-...} Sep 16 01:10:19 Insp6400 kernel: [ 473.541175] Sep 16 01:10:19 Insp6400 kernel: [ 473.541175] but this new dependency connects a HARDIRQ-irq-safe lock: Sep 16 01:10:19 Insp6400 kernel: [ 473.541175] (&(&bp->lock)->rlock){-.-.-.} Sep 16 01:10:19 Insp6400 kernel: [ 473.541175] ... which became HARDIRQ-irq- safe at: Sep 16 01:10:19 Insp6400 kernel: [ 473.541175] [] __lock_acquire+0x2ce/0xd0c Sep 16 01:10:19 Insp6400 kernel: [ 473.541175] [] lock_acquire+0xf3/0x13e Sep 16 01:10:19 Insp6400 kernel: [ 473.541175] [] _raw_spin_lock+0x45/0x79 Sep 16 01:10:19 Insp6400 kernel: [ 473.541175] [] b44_interrupt+0x25/0xd9 [b44] Sep 16 01:10:19 Insp6400 kernel: [ 473.541175] [] handle_irq_event_percpu+0xb4/0x271 Sep 16 01:10:19 Insp6400 kernel: [ 473.541175] [] handle_irq_event+0x47/0x67 Sep 16 01:10:19 Insp6400 kernel: [ 473.541175] [] handle_fasteoi_irq+0x8a/0xb0 Sep 16 01:10:19 Insp6400 kernel: [ 473.541175] [] __xen_evtchn_do_upcall+0x15e/0x203 Sep 16 01:10:19 Insp6400 kernel: [ 473.541175] [] xen_evtchn_do_upcall+0x2c/0x3e Sep 16 01:10:19 Insp6400 kernel: [ 473.541175] [] xen_do_hypervisor_callback+0x1e/0x30 Sep 16 01:10:19 Insp6400 kernel: [ 473.541175] Sep 16 01:10:19 Insp6400 kernel: [ 473.541175] to a HARDIRQ-irq-unsafe lock: Sep 16 01:10:19 Insp6400 kernel: [ 473.541175] (nf_conntrack_lock){+.-...} Sep 16 01:10:19 Insp6400 kernel: [ 473.541175] ... which became HARDIRQ-irq- unsafe at: Sep 16 01:10:19 Insp6400 kernel: [ 473.541175] ... [] __lock_acquire+0x345/0xd0c Sep 16 01:10:19 Insp6400 kernel: [ 473.541175] [] lock_acquire+0xf3/0x13e Sep 16 01:10:19 Insp6400 kernel: [ 473.541175] [] _raw_spin_lock_bh+0x4a/0x7e Sep 16 01:10:19 Insp6400 kernel: [ 473.541175] [] nf_conntrack_in+0x461/0x7dc [nf_conntrack] Sep 16 01:10:19 Insp6400 kernel: [ 473.541175] [] ipv4_conntrack_in+0x21/0x23 [nf_conntrack_ipv4] Sep 16 01:10:19 Insp6400 kernel: [ 473.541175] [] nf_iterate+0x4c/0x8c Sep 16 01:10:19 Insp6400 kernel: [ 473.541175] [] nf_hook_slow+0x7c/0x123 Sep 16 01:10:19 Insp6400 kernel: [ 473.541175] [] NF_HOOK.constprop.4+0x46/0x5a Sep 16 01:10:19 Insp6400 kernel: [ 473.541175] [] ip_rcv+0x239/0x264 Sep 16 01:10:19 Insp6400 kernel: [ 473.541175] [] __netif_receive_skb+0x4af/0x508 Sep 16 01:10:19 Insp6400 kernel: [ 473.541175] [] process_backlog+0x8a/0x151 Sep 16 01:10:19 Insp6400 kernel: [ 473.541175] [] net_rx_action+0xae/0x21c Sep 16 01:10:19 Insp6400 kernel: [ 473.541175] [] __do_softirq+0x112/0x25a Sep 16 01:10:19 Insp6400 kernel: [ 473.541175] [] call_softirq+0x1c/0x30 Sep 16 01:10:19 Insp6400 kernel: [ 473.541175] [] do_softirq+0x4b/0xa2 Sep 16 01:10:19 Insp6400 kernel: [ 473.541175] [] irq_exit+0x5d/0xcf Sep 16 01:10:19 Insp6400 kernel: [ 473.541175] [] xen_evtchn_do_upcall+0x31/0x3e Sep 16 01:10:19 Insp6400 kernel: [ 473.541175] [] xen_do_hypervisor_callback+0x1e/0x30 Sep 16 01:10:19 Insp6400 kernel: [ 473.541175] Sep 16 01:10:19 Insp6400 kernel: [ 473.541175] other info that might help us debug this: Sep 16 01:10:19 Insp6400 kernel: [ 473.541175] Sep 16 01:10:19 Insp6400 kernel: [ 473.541175] Possible interrupt unsafe locking scenario: Sep 16 01:10:19 Insp6400 kernel: [ 473.541175] Sep 16 01:10:19 Insp6400 kernel: [ 473.541175] CPU0 CPU1 Sep 16 01:10:19 Insp6400 kernel: [ 473.541175] ---- ---- Sep 16 01:10:19 Insp6400 kernel: [ 473.541175] lock(nf_conntrack_lock); Sep 16 01:10:19 Insp6400 kernel: [ 473.541175] local_irq_disable(); Sep 16 01:10:19 Insp6400 kernel: [ 473.541175] lock(&(&bp->lock)->rlock); Sep 16 01:10:19 Insp6400 kernel: [ 473.541175] lock(nf_conntrack_lock); Sep 16 01:10:19 Insp6400 kernel: [ 473.541175] Sep 16 01:10:19 Insp6400 kernel: [ 473.541175] lock(&(&bp->lock)->rlock); Sep 16 01:10:19 Insp6400 kernel: [ 473.541175] Sep 16 01:10:19 Insp6400 kernel: [ 473.541175] *** DEADLOCK *** Sep 16 01:10:19 Insp6400 kernel: [ 473.541175] Sep 16 01:10:19 Insp6400 kernel: [ 473.541175] 2 locks held by swapper/0: Sep 16 01:10:19 Insp6400 kernel: [ 473.541175] #0: (&(&bp->lock)->rlock) {-.-.-.}, at: [] b44_poll+0x28/0x3ec [b44] Sep 16 01:10:19 Insp6400 kernel: [ 473.541175] #1: (rcu_read_lock){.+.+..}, at: [] rcu_read_lock+0x0/0x44 Sep 16 01:10:19 Insp6400 kernel: [ 473.541175] Sep 16 01:10:19 Insp6400 kernel: [ 473.541175] the dependencies between HARDIRQ-irq-safe lock and the holding lock: Sep 16 01:10:19 Insp6400 kernel: [ 473.541175] -> (&(&bp->lock)->rlock) {-.-.-.} ops: 27161 { Sep 16 01:10:19 Insp6400 kernel: [ 473.541175] IN-HARDIRQ-W at: Sep 16 01:10:19 Insp6400 kernel: [ 473.541175] [] __lock_acquire+0x2ce/0xd0c Sep 16 01:10:19 Insp6400 kernel: [ 473.541175] [] lock_acquire+0xf3/0x13e Sep 16 01:10:19 Insp6400 kernel: [ 473.541175] [] _raw_spin_lock+0x45/0x79 Sep 16 01:10:19 Insp6400 kernel: [ 473.541175] [] b44_interrupt+0x25/0xd9 [b44] Sep 16 01:10:19 Insp6400 kernel: [ 473.541175] [] handle_irq_event_percpu+0xb4/0x271 Sep 16 01:10:19 Insp6400 kernel: [ 473.541175] [] handle_irq_event+0x47/0x67 Sep 16 01:10:19 Insp6400 kernel: [ 473.541175] [] handle_fasteoi_irq+0x8a/0xb0 Sep 16 01:10:19 Insp6400 kernel: [ 473.541175] [] __xen_evtchn_do_upcall+0x15e/0x203 Sep 16 01:10:19 Insp6400 kernel: [ 473.541175] [] xen_evtchn_do_upcall+0x2c/0x3e Sep 16 01:10:19 Insp6400 kernel: [ 473.541175] [] xen_do_hypervisor_callback+0x1e/0x30 Sep 16 01:10:19 Insp6400 kernel: [ 473.541175] IN-SOFTIRQ-W at: Sep 16 01:10:19 Insp6400 kernel: [ 473.541175] [] __lock_acquire+0x2f5/0xd0c Sep 16 01:10:19 Insp6400 kernel: [ 473.541175] [] lock_acquire+0xf3/0x13e Sep 16 01:10:19 Insp6400 kernel: [ 473.541175] [] _raw_spin_lock_irq+0x4f/0x82 Sep 16 01:10:19 Insp6400 kernel: [ 473.541175] [] b44_timer+0x13/0x51 [b44] Sep 16 01:10:19 Insp6400 kernel: [ 473.541175] [] run_timer_softirq+0x218/0x372 Sep 16 01:10:19 Insp6400 kernel: [ 473.541175] [] __do_softirq+0x112/0x25a Sep 16 01:10:19 Insp6400 kernel: [ 473.541175] [] call_softirq+0x1c/0x30 Sep 16 01:10:19 Insp6400 kernel: [ 473.541175] [] do_softirq+0x4b/0xa2 Sep 16 01:10:19 Insp6400 kernel: [ 473.541175] [] irq_exit+0x5d/0xcf Sep 16 01:10:19 Insp6400 kernel: [ 473.541175] [] xen_evtchn_do_upcall+0x31/0x3e Sep 16 01:10:19 Insp6400 kernel: [ 473.541175] [] xen_do_hypervisor_callback+0x1e/0x30 Sep 16 01:10:19 Insp6400 kernel: [ 473.541175] IN-RECLAIM_FS-W at: Sep 16 01:10:19 Insp6400 kernel: [ 473.541175] [] __lock_acquire+0x3a2/0xd0c Sep 16 01:10:19 Insp6400 kernel: [ 473.541175] [] lock_acquire+0xf3/0x13e Sep 16 01:10:19 Insp6400 kernel: [ 473.541175] [] _raw_spin_lock+0x45/0x79 Sep 16 01:10:19 Insp6400 kernel: [ 473.541175] [] b44_interrupt+0x25/0xd9 [b44] Sep 16 01:10:19 Insp6400 kernel: [ 473.541175] [] handle_irq_event_percpu+0xb4/0x271 Sep 16 01:10:19 Insp6400 kernel: [ 473.541175] [] handle_irq_event+0x47/0x67 Sep 16 01:10:19 Insp6400 kernel: [ 473.541175] [] handle_fasteoi_irq+0x8a/0xb0 Sep 16 01:10:19 Insp6400 kernel: [ 473.541175] [] __xen_evtchn_do_upcall+0x15e/0x203 Sep 16 01:10:19 Insp6400 kernel: [ 473.541175] [] xen_evtchn_do_upcall+0x2c/0x3e Sep 16 01:10:19 Insp6400 kernel: [ 473.541175] [] xen_do_hypervisor_callback+0x1e/0x30 Sep 16 01:10:19 Insp6400 kernel: [ 473.541175] INITIAL USE at: Sep 16 01:10:19 Insp6400 kernel: [ 473.541175] [] __lock_acquire+0x3ba/0xd0c Sep 16 01:10:19 Insp6400 kernel: [ 473.541175] [] lock_acquire+0xf3/0x13e Sep 16 01:10:19 Insp6400 kernel: [ 473.541175] [] _raw_spin_lock_irq+0x4f/0x82 Sep 16 01:10:19 Insp6400 kernel: [ 473.541175] [] b44_set_mac_addr+0x5a/0x82 [b44] Sep 16 01:10:19 Insp6400 kernel: [ 473.541175] [] dev_set_mac_address+0x3e/0x58 Sep 16 01:10:19 Insp6400 kernel: [ 473.541175] [] bond_enslave+0x3e6/0xa48 [bonding] Sep 16 01:10:19 Insp6400 kernel: [ 473.541175] [] bonding_store_slaves+0x106/0x174 [bonding] Sep 16 01:10:19 Insp6400 kernel: [ 473.541175] [] dev_attr_store+0x20/0x22 Sep 16 01:10:19 Insp6400 kernel: [ 473.541175] [] sysfs_write_file+0x108/0x144 Sep 16 01:10:19 Insp6400 kernel: [ 473.541175] [] vfs_write+0xaf/0xf6 Sep 16 01:10:19 Insp6400 kernel: [ 473.541175] [] sys_write+0x4d/0x74 Sep 16 01:10:19 Insp6400 kernel: [ 473.541175] [] system_call_fastpath+0x16/0x1b Sep 16 01:10:19 Insp6400 kernel: [ 473.541175] } Sep 16 01:10:19 Insp6400 kernel: [ 473.541175] ... key at: [] __key.37034+0x0/0xffffffffffffdbb8 [b44] Sep 16 01:10:19 Insp6400 kernel: [ 473.541175] ... acquired at: Sep 16 01:10:19 Insp6400 kernel: [ 473.541175] [] check_irq_usage+0x42/0x88 Sep 16 01:10:19 Insp6400 kernel: [ 473.541175] [] __lock_acquire+0xa52/0xd0c Sep 16 01:10:19 Insp6400 kernel: [ 473.541175] [] lock_acquire+0xf3/0x13e Sep 16 01:10:19 Insp6400 kernel: [ 473.541175] [] _raw_spin_lock_bh+0x4a/0x7e Sep 16 01:10:19 Insp6400 kernel: [ 473.541175] [] destroy_conntrack+0x70/0xec [nf_conntrack] Sep 16 01:10:19 Insp6400 kernel: [ 473.541175] [] nf_conntrack_destroy+0x5a/0x64 Sep 16 01:10:19 Insp6400 kernel: [ 473.541175] [] skb_release_head_state+0xa7/0xef Sep 16 01:10:19 Insp6400 kernel: [ 473.541175] [] __kfree_skb+0x13/0x83 Sep 16 01:10:19 Insp6400 kernel: [ 473.541175] [] consume_skb+0xa5/0xd1 Sep 16 01:10:19 Insp6400 kernel: [ 473.541175] [] b44_poll+0xaf/0x3ec [b44] Sep 16 01:10:19 Insp6400 kernel: [ 473.541175] [] net_rx_action+0xae/0x21c Sep 16 01:10:19 Insp6400 kernel: [ 473.541175] [] __do_softirq+0x112/0x25a Sep 16 01:10:19 Insp6400 kernel: [ 473.541175] [] call_softirq+0x1c/0x30 Sep 16 01:10:19 Insp6400 kernel: [ 473.541175] [] do_softirq+0x4b/0xa2 Sep 16 01:10:19 Insp6400 kernel: [ 473.541175] [] irq_exit+0x5d/0xcf Sep 16 01:10:19 Insp6400 kernel: [ 473.541175] [] xen_evtchn_do_upcall+0x31/0x3e Sep 16 01:10:19 Insp6400 kernel: [ 473.541175] [] xen_do_hypervisor_callback+0x1e/0x30 Sep 16 01:10:19 Insp6400 kernel: [ 473.541175] Sep 16 01:10:19 Insp6400 kernel: [ 473.541175] Sep 16 01:10:19 Insp6400 kernel: [ 473.541175] the dependencies between the lock to be acquired and HARDIRQ-irq-unsafe lock: Sep 16 01:10:19 Insp6400 kernel: [ 473.541175] -> (nf_conntrack_lock){+.-...} ops: 255 { Sep 16 01:10:19 Insp6400 kernel: [ 473.541175] HARDIRQ-ON-W at: Sep 16 01:10:19 Insp6400 kernel: [ 473.541175] [] __lock_acquire+0x345/0xd0c Sep 16 01:10:19 Insp6400 kernel: [ 473.541175] [] lock_acquire+0xf3/0x13e Sep 16 01:10:19 Insp6400 kernel: [ 473.541175] [] _raw_spin_lock_bh+0x4a/0x7e Sep 16 01:10:19 Insp6400 kernel: [ 473.541175] [] nf_conntrack_in+0x461/0x7dc [nf_conntrack] Sep 16 01:10:19 Insp6400 kernel: [ 473.541175] [] ipv4_conntrack_in+0x21/0x23 [nf_conntrack_ipv4] Sep 16 01:10:19 Insp6400 kernel: [ 473.541175] [] nf_iterate+0x4c/0x8c Sep 16 01:10:19 Insp6400 kernel: [ 473.541175] [] nf_hook_slow+0x7c/0x123 Sep 16 01:10:19 Insp6400 kernel: [ 473.541175] [] NF_HOOK.constprop.4+0x46/0x5a Sep 16 01:10:19 Insp6400 kernel: [ 473.541175] [] ip_rcv+0x239/0x264 Sep 16 01:10:19 Insp6400 kernel: [ 473.541175] [] __netif_receive_skb+0x4af/0x508 Sep 16 01:10:19 Insp6400 kernel: [ 473.541175] [] process_backlog+0x8a/0x151 Sep 16 01:10:19 Insp6400 kernel: [ 473.541175] [] net_rx_action+0xae/0x21c Sep 16 01:10:19 Insp6400 kernel: [ 473.541175] [] __do_softirq+0x112/0x25a Sep 16 01:10:19 Insp6400 kernel: [ 473.541175] [] call_softirq+0x1c/0x30 Sep 16 01:10:19 Insp6400 kernel: [ 473.541175] [] do_softirq+0x4b/0xa2 Sep 16 01:10:19 Insp6400 kernel: [ 473.541175] [] irq_exit+0x5d/0xcf Sep 16 01:10:19 Insp6400 kernel: [ 473.541175] [] xen_evtchn_do_upcall+0x31/0x3e Sep 16 01:10:19 Insp6400 kernel: [ 473.541175] [] xen_do_hypervisor_callback+0x1e/0x30 Sep 16 01:10:19 Insp6400 kernel: [ 473.541175] IN-SOFTIRQ-W at: Sep 16 01:10:19 Insp6400 kernel: [ 473.541175] [] __lock_acquire+0x2f5/0xd0c Sep 16 01:10:19 Insp6400 kernel: [ 473.541175] [] lock_acquire+0xf3/0x13e Sep 16 01:10:19 Insp6400 kernel: [ 473.541175] [] _raw_spin_lock_bh+0x4a/0x7e Sep 16 01:10:19 Insp6400 kernel: [ 473.541175] [] nf_conntrack_in+0x461/0x7dc [nf_conntrack] Sep 16 01:10:19 Insp6400 kernel: [ 473.541175] [] ipv4_conntrack_in+0x21/0x23 [nf_conntrack_ipv4] Sep 16 01:10:19 Insp6400 kernel: [ 473.541175] [] nf_iterate+0x4c/0x8c Sep 16 01:10:19 Insp6400 kernel: [ 473.541175] [] nf_hook_slow+0x7c/0x123 Sep 16 01:10:19 Insp6400 kernel: [ 473.541175] [] NF_HOOK.constprop.4+0x46/0x5a Sep 16 01:10:19 Insp6400 kernel: [ 473.541175] [] ip_rcv+0x239/0x264 Sep 16 01:10:19 Insp6400 kernel: [ 473.541175] [] __netif_receive_skb+0x4af/0x508 Sep 16 01:10:19 Insp6400 kernel: [ 473.541175] [] process_backlog+0x8a/0x151 Sep 16 01:10:19 Insp6400 kernel: [ 473.541175] [] net_rx_action+0xae/0x21c Sep 16 01:10:19 Insp6400 kernel: [ 473.541175] [] __do_softirq+0x112/0x25a Sep 16 01:10:19 Insp6400 kernel: [ 473.541175] [] call_softirq+0x1c/0x30 Sep 16 01:10:19 Insp6400 kernel: [ 473.541175] [] do_softirq+0x4b/0xa2 Sep 16 01:10:19 Insp6400 kernel: [ 473.541175] [] irq_exit+0x5d/0xcf Sep 16 01:10:19 Insp6400 kernel: [ 473.541175] [] xen_evtchn_do_upcall+0x31/0x3e Sep 16 01:10:19 Insp6400 kernel: [ 473.541175] [] xen_do_hypervisor_callback+0x1e/0x30 Sep 16 01:10:19 Insp6400 kernel: [ 473.541175] INITIAL USE at: Sep 16 01:10:19 Insp6400 kernel: [ 473.541175] [] __lock_acquire+0x3ba/0xd0c Sep 16 01:10:19 Insp6400 kernel: [ 473.541175] [] lock_acquire+0xf3/0x13e Sep 16 01:10:19 Insp6400 kernel: [ 473.541175] [] _raw_spin_lock_bh+0x4a/0x7e Sep 16 01:10:19 Insp6400 kernel: [ 473.541175] [] nf_conntrack_in+0x461/0x7dc [nf_conntrack] Sep 16 01:10:19 Insp6400 kernel: [ 473.541175] [] ipv4_conntrack_in+0x21/0x23 [nf_conntrack_ipv4] Sep 16 01:10:19 Insp6400 kernel: [ 473.541175] [] nf_iterate+0x4c/0x8c Sep 16 01:10:19 Insp6400 kernel: [ 473.541175] [] nf_hook_slow+0x7c/0x123 Sep 16 01:10:19 Insp6400 kernel: [ 473.541175] [] NF_HOOK.constprop.4+0x46/0x5a Sep 16 01:10:19 Insp6400 kernel: [ 473.541175] [] ip_rcv+0x239/0x264 Sep 16 01:10:19 Insp6400 kernel: [ 473.541175] [] __netif_receive_skb+0x4af/0x508 Sep 16 01:10:19 Insp6400 kernel: [ 473.541175] [] process_backlog+0x8a/0x151 Sep 16 01:10:19 Insp6400 kernel: [ 473.541175] [] net_rx_action+0xae/0x21c Sep 16 01:10:19 Insp6400 kernel: [ 473.541175] [] __do_softirq+0x112/0x25a Sep 16 01:10:19 Insp6400 kernel: [ 473.541175] [] call_softirq+0x1c/0x30 Sep 16 01:10:19 Insp6400 kernel: [ 473.541175] [] do_softirq+0x4b/0xa2 Sep 16 01:10:19 Insp6400 kernel: [ 473.541175] [] irq_exit+0x5d/0xcf Sep 16 01:10:19 Insp6400 kernel: [ 473.541175] [] xen_evtchn_do_upcall+0x31/0x3e Sep 16 01:10:19 Insp6400 kernel: [ 473.541175] [] xen_do_hypervisor_callback+0x1e/0x30 Sep 16 01:10:19 Insp6400 kernel: [ 473.541175] } Sep 16 01:10:19 Insp6400 kernel: [ 473.541175] ... key at: [] nf_conntrack_lock+0x18/0xffffffffffffd000 [nf_conntrack] Sep 16 01:10:19 Insp6400 kernel: [ 473.541175] ... acquired at: Sep 16 01:10:19 Insp6400 kernel: [ 473.541175] [] check_irq_usage+0x42/0x88 Sep 16 01:10:19 Insp6400 kernel: [ 473.541175] [] __lock_acquire+0xa52/0xd0c Sep 16 01:10:19 Insp6400 kernel: [ 473.541175] [] lock_acquire+0xf3/0x13e Sep 16 01:10:19 Insp6400 kernel: [ 473.541175] [] _raw_spin_lock_bh+0x4a/0x7e Sep 16 01:10:19 Insp6400 kernel: [ 473.541175] [] destroy_conntrack+0x70/0xec [nf_conntrack] Sep 16 01:10:19 Insp6400 kernel: [ 473.541175] [] nf_conntrack_destroy+0x5a/0x64 Sep 16 01:10:19 Insp6400 kernel: [ 473.541175] [] skb_release_head_state+0xa7/0xef Sep 16 01:10:19 Insp6400 kernel: [ 473.541175] [] __kfree_skb+0x13/0x83 Sep 16 01:10:19 Insp6400 kernel: [ 473.541175] [] consume_skb+0xa5/0xd1 Sep 16 01:10:19 Insp6400 kernel: [ 473.541175] [] b44_poll+0xaf/0x3ec [b44] Sep 16 01:10:19 Insp6400 kernel: [ 473.541175] [] net_rx_action+0xae/0x21c Sep 16 01:10:19 Insp6400 kernel: [ 473.541175] [] __do_softirq+0x112/0x25a Sep 16 01:10:19 Insp6400 kernel: [ 473.541175] [] call_softirq+0x1c/0x30 Sep 16 01:10:19 Insp6400 kernel: [ 473.541175] [] do_softirq+0x4b/0xa2 Sep 16 01:10:19 Insp6400 kernel: [ 473.541175] [] irq_exit+0x5d/0xcf Sep 16 01:10:19 Insp6400 kernel: [ 473.541175] [] xen_evtchn_do_upcall+0x31/0x3e Sep 16 01:10:19 Insp6400 kernel: [ 473.541175] [] xen_do_hypervisor_callback+0x1e/0x30 Sep 16 01:10:19 Insp6400 kernel: [ 473.541175] Sep 16 01:10:19 Insp6400 kernel: [ 473.541175] Sep 16 01:10:19 Insp6400 kernel: [ 473.541175] stack backtrace: Sep 16 01:10:19 Insp6400 kernel: [ 473.541175] Pid: 0, comm: swapper Not tainted 3.1.0-0.rc6.git0.0.xendom0.fc17.x86_64 #1 Sep 16 01:10:19 Insp6400 kernel: [ 473.541175] Call Trace: Sep 16 01:10:19 Insp6400 kernel: [ 473.541175] [] check_usage+0x37f/0x394 Sep 16 01:10:19 Insp6400 kernel: [ 473.541175] [] ? check_events+0x12/0x20 Sep 16 01:10:19 Insp6400 kernel: [ 473.541175] [] check_irq_usage+0x42/0x88 Sep 16 01:10:19 Insp6400 kernel: [ 473.541175] [] __lock_acquire+0xa52/0xd0c Sep 16 01:10:19 Insp6400 kernel: [ 473.541175] [] ? rcu_read_lock+0x44/0x44 [nf_conntrack] Sep 16 01:10:19 Insp6400 kernel: [ 473.541175] [] ? xen_force_evtchn_callback+0xd/0xf Sep 16 01:10:19 Insp6400 kernel: [ 473.541175] [] ? check_events+0x12/0x20 Sep 16 01:10:19 Insp6400 kernel: [ 473.541175] [] ? xen_force_evtchn_callback+0xd/0xf Sep 16 01:10:19 Insp6400 kernel: [ 473.541175] [] ? destroy_conntrack+0x70/0xec [nf_conntrack] Sep 16 01:10:19 Insp6400 kernel: [ 473.541175] [] lock_acquire+0xf3/0x13e Sep 16 01:10:19 Insp6400 kernel: [ 473.541175] [] ? destroy_conntrack+0x70/0xec [nf_conntrack] Sep 16 01:10:19 Insp6400 kernel: [ 473.541175] [] ? xen_restore_fl_direct_reloc+0x4/0x4 Sep 16 01:10:19 Insp6400 kernel: [ 473.541175] [] _raw_spin_lock_bh+0x4a/0x7e Sep 16 01:10:19 Insp6400 kernel: [ 473.541175] [] xen_evtchn_do_upcall+0x31/0x3e Sep 16 01:10:19 Insp6400 kernel: [ 473.541175] [] xen_do_hypervisor_callback+0x1e/0x30 Sep 16 01:10:19 Insp6400 kernel: [ 473.541175] INITIAL USE at: Sep 16 01:10:19 Insp6400 kernel: [ 473.541175] [] __lock_acquire+0x3ba/0xd0c Sep 16 01:10:19 Insp6400 kernel: [ 473.541175] [] lock_acquire+0xf3/0x13e Sep 16 01:10:19 Insp6400 kernel: [ 473.541175] [] _raw_spin_lock_bh+0x4a/0x7e Sep 16 01:10:19 Insp6400 kernel: [ 473.541175] [] nf_conntrack_in+0x461/0x7dc [nf_conntrack] Sep 16 01:10:19 Insp6400 kernel: [ 473.541175] [] ipv4_conntrack_in+0x21/0x23 [nf_conntrack_ipv4] Sep 16 01:10:19 Insp6400 kernel: [ 473.541175] [] nf_iterate+0x4c/0x8c Sep 16 01:10:19 Insp6400 kernel: [ 473.541175] [] nf_hook_slow+0x7c/0x123 Sep 16 01:10:19 Insp6400 kernel: [ 473.541175] [] NF_HOOK.constprop.4+0x46/0x5a Sep 16 01:10:19 Insp6400 kernel: [ 473.541175] [] ip_rcv+0x239/0x264 Sep 16 01:10:19 Insp6400 kernel: [ 473.541175] [] __netif_receive_skb+0x4af/0x508 Sep 16 01:10:19 Insp6400 kernel: [ 473.541175] [] process_backlog+0x8a/0x151 Sep 16 01:10:19 Insp6400 kernel: [ 473.541175] [] net_rx_action+0xae/0x21c Sep 16 01:10:19 Insp6400 kernel: [ 473.541175] [] __do_softirq+0x112/0x25a Sep 16 01:10:19 Insp6400 kernel: [ 473.541175] [] call_softirq+0x1c/0x30 Sep 16 01:10:19 Insp6400 kernel: [ 473.541175] [] do_softirq+0x4b/0xa2 Sep 16 01:10:19 Insp6400 kernel: [ 473.541175] [] irq_exit+0x5d/0xcf Sep 16 01:10:19 Insp6400 kernel: [ 473.541175] [] xen_evtchn_do_upcall+0x31/0x3e Sep 16 01:10:19 Insp6400 kernel: [ 473.541175] [] xen_do_hypervisor_callback+0x1e/0x30 Sep 16 01:10:19 Insp6400 kernel: [ 473.541175] } Sep 16 01:10:19 Insp6400 kernel: [ 473.541175] ... key at: [] nf_conntrack_lock+0x18/0xffffffffffffd000 [nf_conntrack] Sep 16 01:10:19 Insp6400 kernel: [ 473.541175] ... acquired at: Sep 16 01:10:19 Insp6400 kernel: [ 473.541175] [] check_irq_usage+0x42/0x88 Sep 16 01:10:19 Insp6400 kernel: [ 473.541175] [] __lock_acquire+0xa52/0xd0c Sep 16 01:10:19 Insp6400 kernel: [ 473.541175] [] lock_acquire+0xf3/0x13e Sep 16 01:10:19 Insp6400 kernel: [ 473.541175] [] _raw_spin_lock_bh+0x4a/0x7e Sep 16 01:10:19 Insp6400 kernel: [ 473.541175] [] destroy_conntrack+0x70/0xec [nf_conntrack] Sep 16 01:10:19 Insp6400 kernel: [ 473.541175] [] nf_conntrack_destroy+0x5a/0x64 Sep 16 01:10:19 Insp6400 kernel: [ 473.541175] [] skb_release_head_state+0xa7/0xef Sep 16 01:10:19 Insp6400 kernel: [ 473.541175] [] __kfree_skb+0x13/0x83 Sep 16 01:10:19 Insp6400 kernel: [ 473.541175] [] consume_skb+0xa5/0xd1 Sep 16 01:10:19 Insp6400 kernel: [ 473.541175] [] b44_poll+0xaf/0x3ec [b44] Sep 16 01:10:19 Insp6400 kernel: [ 473.541175] [] net_rx_action+0xae/0x21c Sep 16 01:10:19 Insp6400 kernel: [ 473.541175] [] __do_softirq+0x112/0x25a Sep 16 01:10:19 Insp6400 kernel: [ 473.541175] [] call_softirq+0x1c/0x30 Sep 16 01:10:19 Insp6400 kernel: [ 473.541175] [] do_softirq+0x4b/0xa2 Sep 16 01:10:19 Insp6400 kernel: [ 473.541175] [] irq_exit+0x5d/0xcf Sep 16 01:10:19 Insp6400 kernel: [ 473.541175] [] xen_evtchn_do_upcall+0x31/0x3e Sep 16 01:10:19 Insp6400 kernel: [ 473.541175] [] xen_do_hypervisor_callback+0x1e/0x30 Sep 16 01:10:19 Insp6400 kernel: [ 473.541175] Sep 16 01:10:19 Insp6400 kernel: [ 473.541175] Sep 16 01:10:19 Insp6400 kernel: [ 473.541175] stack backtrace: Sep 16 01:10:19 Insp6400 kernel: [ 473.541175] Pid: 0, comm: swapper Not tainted 3.1.0-0.rc6.git0.0.xendom0.fc17.x86_64 #1 Sep 16 01:10:19 Insp6400 kernel: [ 473.541175] Call Trace: Sep 16 01:10:19 Insp6400 kernel: [ 473.541175] [] check_usage+0x37f/0x394 Sep 16 01:10:19 Insp6400 kernel: [ 473.541175] [] ? check_events+0x12/0x20 Sep 16 01:10:19 Insp6400 kernel: [ 473.541175] [] check_irq_usage+0x42/0x88 Sep 16 01:10:19 Insp6400 kernel: [ 473.541175] [] __lock_acquire+0xa52/0xd0c Sep 16 01:10:19 Insp6400 kernel: [ 473.541175] [] ? rcu_read_lock+0x44/0x44 [nf_conntrack] Sep 16 01:10:19 Insp6400 kernel: [ 473.541175] [] ? xen_force_evtchn_callback+0xd/0xf Sep 16 01:10:19 Insp6400 kernel: [ 473.541175] [] ? check_events+0x12/0x20 Sep 16 01:10:19 Insp6400 kernel: [ 473.541175] [] ? xen_force_evtchn_callback+0xd/0xf Sep 16 01:10:19 Insp6400 kernel: [ 473.541175] [] ? destroy_conntrack+0x70/0xec [nf_conntrack] Sep 16 01:10:19 Insp6400 kernel: [ 473.541175] [] lock_acquire+0xf3/0x13e Sep 16 01:10:19 Insp6400 kernel: [ 473.541175] [] ? destroy_conntrack+0x70/0xec [nf_conntrack] Sep 16 01:10:19 Insp6400 kernel: [ 473.541175] [] ? xen_restore_fl_direct_reloc+0x4/0x4 Sep 16 01:10:19 Insp6400 kernel: [ 473.541175] [] _raw_spin_lock_bh+0x4a/0x7e Sep 16 01:10:19 Insp6400 kernel: [ 473.541175] [] ? destroy_conntrack+0x70/0xec [nf_conntrack] Sep 16 01:10:19 Insp6400 kernel: [ 473.541175] [] destroy_conntrack+0x70/0xec [nf_conntrack] Sep 16 01:10:19 Insp6400 kernel: [ 473.541175] [] ? nf_conntrack_free+0x58/0x58 [nf_conntrack] Sep 16 01:10:19 Insp6400 kernel: [ 473.541175] [] nf_conntrack_destroy+0x5a/0x64 Sep 16 01:10:19 Insp6400 kernel: [ 473.541175] [] skb_release_head_state+0xa7/0xef Sep 16 01:10:19 Insp6400 kernel: [ 473.541175] [] __kfree_skb+0x13/0x83 Sep 16 01:10:19 Insp6400 kernel: [ 473.541175] [] consume_skb+0xa5/0xd1 Sep 16 01:10:19 Insp6400 kernel: [ 473.541175] [] b44_poll+0xaf/0x3ec [b44] Sep 16 01:10:19 Insp6400 kernel: [ 473.541175] [] net_rx_action+0xae/0x21c Sep 16 01:10:19 Insp6400 kernel: [ 473.541175] [] ? __do_softirq+0x7e/0x25a Sep 16 01:10:19 Insp6400 kernel: [ 473.541175] [] __do_softirq+0x112/0x25a Sep 16 01:10:19 Insp6400 kernel: [ 473.541175] [] call_softirq+0x1c/0x30 Sep 16 01:10:19 Insp6400 kernel: [ 473.541175] [] do_softirq+0x4b/0xa2 Sep 16 01:10:19 Insp6400 kernel: [ 473.541175] [] irq_exit+0x5d/0xcf Sep 16 01:10:19 Insp6400 kernel: [ 473.541175] [] xen_evtchn_do_upcall+0x31/0x3e Sep 16 01:10:19 Insp6400 kernel: [ 473.541175] [] xen_do_hypervisor_callback+0x1e/0x30 Sep 16 01:10:19 Insp6400 kernel: [ 473.541175] [] ? hypercall_page+0x3aa/0x1000 Sep 16 01:10:19 Insp6400 kernel: [ 473.541175] [] ? hypercall_page+0x3aa/0x1000 Sep 16 01:10:19 Insp6400 kernel: [ 473.541175] [] ? xen_safe_halt+0x10/0x18 Sep 16 01:10:19 Insp6400 kernel: [ 473.541175] [] ? default_idle+0x53/0x90 Sep 16 01:10:19 Insp6400 kernel: [ 473.541175] [] ? cpu_idle+0xb5/0x101 Sep 16 01:10:19 Insp6400 kernel: [ 473.541175] [] ? rest_init+0xdc/0xe3 Sep 16 01:10:19 Insp6400 kernel: [ 473.541175] [] ? csum_partial_copy_generic+0x16c/0x16c Sep 16 01:10:19 Insp6400 kernel: [ 473.541175] [] ? start_kernel+0x3dd/0x3ea Sep 16 01:10:19 Insp6400 kernel: [ 473.541175] [] ? x86_64_start_reservations+0xaf/0xb3 Sep 16 01:10:19 Insp6400 kernel: [ 473.541175] [] ? xen_start_kernel+0x588/0x58f Sep 16 01:10:19 Insp6400 kernel: [ 473.541175] ------------[ cut here ]------------ Sep 16 01:10:19 Insp6400 kernel: [ 473.541175] WARNING: at kernel/softirq.c:159 _local_bh_enable_ip+0x49/0xce() Sep 16 01:10:19 Insp6400 kernel: [ 473.541175] Hardware name: MM061 Sep 16 01:10:19 Insp6400 kernel: [ 473.541175] Modules linked in: fuse ebtable_nat ebtables ipt_MASQUERADE iptable_nat nf_nat xt_CHECKSUM iptable_mangle xen_pciback nfsd lockd nfs_acl auth_rpcgss sunrpc des_generic md4 nls_utf8 cifs fscache bridge stp llc bonding be2iscsi iscsi_boot_sysfs bnx2i cnic uio cxgb3i libcxgbi iw_cxgb3 cxgb3 mdio ib_iser rdma_cm ib_cm iw_cm xt_comment ib_sa ib_mad ib_core ip6t_REJECT ib_addr nf_conntrack_ipv4 nf_defrag_ipv4 nf_conntrack_ipv6 nf_defrag_ipv6 iscsi_tcp xt_state libiscsi_tcp nf_conntrack libiscsi ip6table_filter ipt_LOG scsi_transport_iscsi ip6_tables xt_physdev dell_wmi sparse_keymap snd_hda_codec_idt snd_hda_intel snd_hda_codec snd_hwdep snd_seq snd_seq_device arc4 r852 sm_common nand snd_pcm dell_laptop microcode dcdbas b44 nand_ids r592 nand_ecc iwl3945 ssb memstick mtd mii iwl_legacy iTCO_wdt mac80211 iTCO_vendor_support i2c_i801 joydev cfg80211 snd_timer rfkill snd soundcore snd_page_alloc tun xen_gntalloc xen_netback xen_blkback xen_gntdev xen_evtchn xenfs binfmt_misc Sep 16 01:10:19 Insp6400 kernel: sdhci_pci sdhci mmc_core firewire_ohci firewire_core crc_itu_t wmi i915 drm_kms_helper drm i2c_algo_bit i2c_core video [last unloaded: scsi_wait_scan] Sep 16 01:10:19 Insp6400 kernel: [ 473.541175] Pid: 0, comm: swapper Not tainted 3.1.0-0.rc6.git0.0.xendom0.fc17.x86_64 #1 Sep 16 01:10:19 Insp6400 kernel: [ 473.541175] Call Trace: Sep 16 01:10:19 Insp6400 kernel: [ 473.541175] [] warn_slowpath_common+0x83/0x9b Sep 16 01:10:19 Insp6400 kernel: [ 473.541175] [] ? destroy_conntrack+0xad/0xec [nf_conntrack] Sep 16 01:10:19 Insp6400 kernel: [ 473.541175] [] warn_slowpath_null+0x1a/0x1c Sep 16 01:10:19 Insp6400 kernel: [ 473.541175] [] _local_bh_enable_ip+0x49/0xce Sep 16 01:10:19 Insp6400 kernel: [ 473.541175] [] local_bh_enable_ip+0xe/0x10 Sep 16 01:10:19 Insp6400 kernel: [ 473.541175] [] _raw_spin_unlock_bh+0x40/0x44 Sep 16 01:10:19 Insp6400 kernel: [ 473.541175] [] destroy_conntrack+0xad/0xec [nf_conntrack] Sep 16 01:10:19 Insp6400 kernel: [ 473.541175] [] ? nf_conntrack_free+0x58/0x58 [nf_conntrack] Sep 16 01:10:19 Insp6400 kernel: [ 473.541175] [] nf_conntrack_destroy+0x5a/0x64 Sep 16 01:10:19 Insp6400 kernel: [ 473.541175] [] skb_release_head_state+0xa7/0xef Sep 16 01:10:19 Insp6400 kernel: [ 473.541175] [] __kfree_skb+0x13/0x83 Sep 16 01:10:19 Insp6400 kernel: [ 473.541175] [] consume_skb+0xa5/0xd1 Sep 16 01:10:19 Insp6400 kernel: [ 473.541175] [] b44_poll+0xaf/0x3ec [b44] Sep 16 01:10:19 Insp6400 kernel: [ 473.541175] [] net_rx_action+0xae/0x21c Sep 16 01:10:19 Insp6400 kernel: [ 473.541175] [] ? __do_softirq+0x7e/0x25a Sep 16 01:10:19 Insp6400 kernel: [ 473.541175] [] __do_softirq+0x112/0x25a Sep 16 01:10:19 Insp6400 kernel: [ 473.541175] [] call_softirq+0x1c/0x30 Sep 16 01:10:19 Insp6400 kernel: [ 473.541175] [] do_softirq+0x4b/0xa2 Sep 16 01:10:19 Insp6400 kernel: [ 473.541175] [] irq_exit+0x5d/0xcf Sep 16 01:10:19 Insp6400 kernel: [ 473.541175] [] xen_evtchn_do_upcall+0x31/0x3e Sep 16 01:10:19 Insp6400 kernel: [ 473.537933] Sep 16 01:10:19 Insp6400 kernel: [ 473.537933] ====================================================== Sep 16 01:10:19 Insp6400 kernel: [ 473.537933] [ INFO: HARDIRQ-safe -> HARDIRQ-unsafe lock order detected ] Sep 16 01:10:19 Insp6400 kernel: [ 473.537933] 3.1.0-0.rc6.git0.0.xendom0.fc17.x86_64 #1 Sep 16 01:10:19 Insp6400 kernel: [ 473.537933] ------------------------------------------------------ Sep 16 01:10:19 Insp6400 kernel: [ 473.537933] swapper/0 [HC0[0]:SC1[3]:HE0:SE0] is trying to acquire: Sep 16 01:10:19 Insp6400 kernel: [ 473.537933] (nf_conntrack_lock){+.-...}, at: [] destroy_conntrack+0x70/0xec [nf_conntrack] Sep 16 01:10:19 Insp6400 kernel: [ 473.537933] Sep 16 01:10:19 Insp6400 kernel: [ 473.537933] and this task is already holding: Sep 16 01:10:19 Insp6400 kernel: [ 473.537933] (&(&bp->lock)->rlock) {-.-.-.}, at: [] b44_poll+0x28/0x3ec [b44] Sep 16 01:10:19 Insp6400 kernel: [ 473.541175] which would create a new lock dependency: Sep 16 01:10:19 Insp6400 kernel: [ 473.541175] (&(&bp->lock)->rlock){-.-.-.} -> (nf_conntrack_lock){+.-...} Sep 16 01:10:19 Insp6400 kernel: [ 473.541175] Sep 16 01:10:19 Insp6400 kernel: [ 473.541175] but this new dependency connects a HARDIRQ-irq-safe lock: Sep 16 01:10:19 Insp6400 kernel: [ 473.541175] (&(&bp->lock)->rlock){-.-.-.} Sep 16 01:10:19 Insp6400 kernel: [ 473.541175] ... which became HARDIRQ-irq- safe at: Sep 16 01:10:19 Insp6400 kernel: [ 473.541175] [] __lock_acquire+0x2ce/0xd0c Sep 16 01:10:19 Insp6400 kernel: [ 473.541175] [] lock_acquire+0xf3/0x13e Sep 16 01:10:19 Insp6400 kernel: [ 473.541175] [] _raw_spin_lock+0x45/0x79 Sep 16 01:10:19 Insp6400 kernel: [ 473.541175] [] b44_interrupt+0x25/0xd9 [b44] Sep 16 01:10:19 Insp6400 kernel: [ 473.541175] [] handle_irq_event_percpu+0xb4/0x271 Sep 16 01:10:19 Insp6400 kernel: [ 473.541175] [] handle_irq_event+0x47/0x67 Sep 16 01:10:19 Insp6400 kernel: [ 473.541175] [] handle_fasteoi_irq+0x8a/0xb0 Sep 16 01:10:19 Insp6400 kernel: [ 473.541175] [] __xen_evtchn_do_upcall+0x15e/0x203 Sep 16 01:10:19 Insp6400 kernel: [ 473.541175] [] xen_evtchn_do_upcall+0x2c/0x3e Sep 16 01:10:19 Insp6400 kernel: [ 473.541175] [] xen_do_hypervisor_callback+0x1e/0x30 Sep 16 01:10:19 Insp6400 kernel: [ 473.541175] Sep 16 01:10:19 Insp6400 kernel: [ 473.541175] to a HARDIRQ-irq-unsafe lock: Sep 16 01:10:19 Insp6400 kernel: [ 473.541175] (nf_conntrack_lock){+.-...} Sep 16 01:10:19 Insp6400 kernel: [ 473.541175] ... which became HARDIRQ-irq- unsafe at: Sep 16 01:10:19 Insp6400 kernel: [ 473.541175] ... [] __lock_acquire+0x345/0xd0c Sep 16 01:10:19 Insp6400 kernel: [ 473.541175] [] lock_acquire+0xf3/0x13e Sep 16 01:10:19 Insp6400 kernel: [ 473.541175] [] _raw_spin_lock_bh+0x4a/0x7e Sep 16 01:10:19 Insp6400 kernel: [ 473.541175] [] nf_conntrack_in+0x461/0x7dc [nf_conntrack] Sep 16 01:10:19 Insp6400 kernel: [ 473.541175] [] ipv4_conntrack_in+0x21/0x23 [nf_conntrack_ipv4] Sep 16 01:10:19 Insp6400 kernel: [ 473.541175] [] nf_iterate+0x4c/0x8c Sep 16 01:10:19 Insp6400 kernel: [ 473.541175] [] nf_hook_slow+0x7c/0x123 Sep 16 01:10:19 Insp6400 kernel: [ 473.541175] [] NF_HOOK.constprop.4+0x46/0x5a Sep 16 01:10:19 Insp6400 kernel: [ 473.541175] [] ip_rcv+0x239/0x264 Sep 16 01:10:19 Insp6400 kernel: [ 473.541175] [] __netif_receive_skb+0x4af/0x508 Sep 16 01:10:19 Insp6400 kernel: [ 473.541175] [] process_backlog+0x8a/0x151 Sep 16 01:10:19 Insp6400 kernel: [ 473.541175] [] net_rx_action+0xae/0x21c Sep 16 01:10:19 Insp6400 kernel: [ 473.541175] [] __do_softirq+0x112/0x25a Sep 16 01:10:19 Insp6400 kernel: [ 473.541175] [] call_softirq+0x1c/0x30 Sep 16 01:10:19 Insp6400 kernel: [ 473.541175] [] do_softirq+0x4b/0xa2 Sep 16 01:10:19 Insp6400 kernel: [ 473.541175] [] irq_exit+0x5d/0xcf Sep 16 01:10:19 Insp6400 kernel: [ 473.541175] [] xen_evtchn_do_upcall+0x31/0x3e Sep 16 01:10:19 Insp6400 kernel: [ 473.541175] [] xen_do_hypervisor_callback+0x1e/0x30 Sep 16 01:10:19 Insp6400 kernel: [ 473.541175] Sep 16 01:10:19 Insp6400 kernel: [ 473.541175] other info that might help us debug this: Sep 16 01:10:19 Insp6400 kernel: [ 473.541175] Sep 16 01:10:19 Insp6400 kernel: [ 473.541175] Possible interrupt unsafe locking scenario: Sep 16 01:10:19 Insp6400 kernel: [ 473.541175] Sep 16 01:10:19 Insp6400 kernel: [ 473.541175] CPU0 CPU1 Sep 16 01:10:19 Insp6400 kernel: [ 473.541175] ---- ---- Sep 16 01:10:19 Insp6400 kernel: [ 473.541175] lock(nf_conntrack_lock); Sep 16 01:10:19 Insp6400 kernel: [ 473.541175] local_irq_disable(); Sep 16 01:10:19 Insp6400 kernel: [ 473.541175] lock(&(&bp->lock)->rlock); Sep 16 01:10:19 Insp6400 kernel: [ 473.541175] lock(nf_conntrack_lock); Sep 16 01:10:19 Insp6400 kernel: [ 473.541175] Sep 16 01:10:19 Insp6400 kernel: [ 473.541175] lock(&(&bp->lock)->rlock); Sep 16 01:10:19 Insp6400 kernel: [ 473.541175] Sep 16 01:10:19 Insp6400 kernel: [ 473.541175] *** DEADLOCK *** Sep 16 01:10:19 Insp6400 kernel: [ 473.541175] Sep 16 01:10:19 Insp6400 kernel: [ 473.541175] 2 locks held by swapper/0: Sep 16 01:10:19 Insp6400 kernel: [ 473.541175] #0: (&(&bp->lock)->rlock) {-.-.-.}, at: [] b44_poll+0x28/0x3ec [b44] Sep 16 01:10:19 Insp6400 kernel: [ 473.541175] #1: (rcu_read_lock){.+.+..}, at: [] rcu_read_lock+0x0/0x44 Sep 16 01:10:19 Insp6400 kernel: [ 473.541175] Sep 16 01:10:19 Insp6400 kernel: [ 473.541175] the dependencies between HARDIRQ-irq-safe lock and the holding lock: Sep 16 01:10:19 Insp6400 kernel: [ 473.541175] -> (&(&bp->lock)->rlock) {-.-.-.} ops: 27161 { Sep 16 01:10:19 Insp6400 kernel: [ 473.541175] IN-HARDIRQ-W at: Sep 16 01:10:19 Insp6400 kernel: [ 473.541175] [] __lock_acquire+0x2ce/0xd0c Sep 16 01:10:19 Insp6400 kernel: [ 473.541175] [] lock_acquire+0xf3/0x13e Sep 16 01:10:19 Insp6400 kernel: [ 473.541175] [] _raw_spin_lock+0x45/0x79 Sep 16 01:10:19 Insp6400 kernel: [ 473.541175] [] b44_interrupt+0x25/0xd9 [b44] Sep 16 01:10:19 Insp6400 kernel: [ 473.541175] [] handle_irq_event_percpu+0xb4/0x271 Sep 16 01:10:19 Insp6400 kernel: [ 473.541175] [] handle_irq_event+0x47/0x67 Sep 16 01:10:19 Insp6400 kernel: [ 473.541175] [] handle_fasteoi_irq+0x8a/0xb0 Sep 16 01:10:19 Insp6400 kernel: [ 473.541175] [] __xen_evtchn_do_upcall+0x15e/0x203 Sep 16 01:10:19 Insp6400 kernel: [ 473.541175] [] xen_evtchn_do_upcall+0x2c/0x3e Sep 16 01:10:19 Insp6400 kernel: [ 473.541175] [] xen_do_hypervisor_callback+0x1e/0x30 Sep 16 01:10:19 Insp6400 kernel: [ 473.541175] IN-SOFTIRQ-W at: Sep 16 01:10:19 Insp6400 kernel: [ 473.541175] [] __lock_acquire+0x2f5/0xd0c Sep 16 01:10:19 Insp6400 kernel: [ 473.541175] [] lock_acquire+0xf3/0x13e Sep 16 01:10:19 Insp6400 kernel: [ 473.541175] [] _raw_spin_lock_irq+0x4f/0x82 Sep 16 01:10:19 Insp6400 kernel: [ 473.541175] [] b44_timer+0x13/0x51 [b44] Sep 16 01:10:19 Insp6400 kernel: [ 473.541175] [] run_timer_softirq+0x218/0x372 Sep 16 01:10:19 Insp6400 kernel: [ 473.541175] [] __do_softirq+0x112/0x25a Sep 16 01:10:19 Insp6400 kernel: [ 473.541175] [] call_softirq+0x1c/0x30 Sep 16 01:10:19 Insp6400 kernel: [ 473.541175] [] do_softirq+0x4b/0xa2 Sep 16 01:10:19 Insp6400 kernel: [ 473.541175] [] irq_exit+0x5d/0xcf Sep 16 01:10:19 Insp6400 kernel: [ 473.541175] [] xen_evtchn_do_upcall+0x31/0x3e Sep 16 01:10:19 Insp6400 kernel: [ 473.541175] [] xen_do_hypervisor_callback+0x1e/0x30 Sep 16 01:10:19 Insp6400 kernel: [ 473.541175] IN-RECLAIM_FS-W at: Sep 16 01:10:19 Insp6400 kernel: [ 473.541175] [] __lock_acquire+0x3a2/0xd0c Sep 16 01:10:19 Insp6400 kernel: [ 473.541175] [] lock_acquire+0xf3/0x13e Sep 16 01:10:19 Insp6400 kernel: [ 473.541175] [] _raw_spin_lock+0x45/0x79 Sep 16 01:10:19 Insp6400 kernel: [ 473.541175] [] b44_interrupt+0x25/0xd9 [b44] Sep 16 01:10:19 Insp6400 kernel: [ 473.541175] [] handle_irq_event_percpu+0xb4/0x271 Sep 16 01:10:19 Insp6400 kernel: [ 473.541175] [] handle_irq_event+0x47/0x67 Sep 16 01:10:19 Insp6400 kernel: [ 473.541175] [] handle_fasteoi_irq+0x8a/0xb0 Sep 16 01:10:19 Insp6400 kernel: [ 473.541175] [] __xen_evtchn_do_upcall+0x15e/0x203 Sep 16 01:10:19 Insp6400 kernel: [ 473.541175] [] xen_evtchn_do_upcall+0x2c/0x3e Sep 16 01:10:19 Insp6400 kernel: [ 473.541175] [] xen_do_hypervisor_callback+0x1e/0x30 Sep 16 01:10:19 Insp6400 kernel: [ 473.541175] INITIAL USE at: Sep 16 01:10:19 Insp6400 kernel: [ 473.541175] [] __lock_acquire+0x3ba/0xd0c Sep 16 01:10:19 Insp6400 kernel: [ 473.541175] [] lock_acquire+0xf3/0x13e Sep 16 01:10:19 Insp6400 kernel: [ 473.541175] [] _raw_spin_lock_irq+0x4f/0x82 Sep 16 01:10:19 Insp6400 kernel: [ 473.541175] [] b44_set_mac_addr+0x5a/0x82 [b44] Sep 16 01:10:19 Insp6400 kernel: [ 473.541175] [] dev_set_mac_address+0x3e/0x58 Sep 16 01:10:19 Insp6400 kernel: [ 473.541175] [] bond_enslave+0x3e6/0xa48 [bonding] Sep 16 01:10:19 Insp6400 kernel: [ 473.541175] [] bonding_store_slaves+0x106/0x174 [bonding] Sep 16 01:10:19 Insp6400 kernel: [ 473.541175] [] dev_attr_store+0x20/0x22 Sep 16 01:10:19 Insp6400 kernel: [ 473.541175] [] sysfs_write_file+0x108/0x144 Sep 16 01:10:19 Insp6400 kernel: [ 473.541175] [] vfs_write+0xaf/0xf6 Sep 16 01:10:19 Insp6400 kernel: [ 473.541175] [] sys_write+0x4d/0x74 Sep 16 01:10:19 Insp6400 kernel: [ 473.541175] [] system_call_fastpath+0x16/0x1b Sep 16 01:10:19 Insp6400 kernel: [ 473.541175] } Sep 16 01:10:19 Insp6400 kernel: [ 473.541175] ... key at: [] __key.37034+0x0/0xffffffffffffdbb8 [b44] Sep 16 01:10:19 Insp6400 kernel: [ 473.541175] ... acquired at: Sep 16 01:10:19 Insp6400 kernel: [ 473.541175] [] check_irq_usage+0x42/0x88 Sep 16 01:10:19 Insp6400 kernel: [ 473.541175] [] __lock_acquire+0xa52/0xd0c Sep 16 01:10:19 Insp6400 kernel: [ 473.541175] [] lock_acquire+0xf3/0x13e Sep 16 01:10:19 Insp6400 kernel: [ 473.541175] [] _raw_spin_lock_bh+0x4a/0x7e Sep 16 01:10:19 Insp6400 kernel: [ 473.541175] [] destroy_conntrack+0x70/0xec [nf_conntrack] Sep 16 01:10:19 Insp6400 kernel: [ 473.541175] [] nf_conntrack_destroy+0x5a/0x64 Sep 16 01:10:19 Insp6400 kernel: [ 473.541175] [] skb_release_head_state+0xa7/0xef Sep 16 01:10:19 Insp6400 kernel: [ 473.541175] [] __kfree_skb+0x13/0x83 Sep 16 01:10:19 Insp6400 kernel: [ 473.541175] [] consume_skb+0xa5/0xd1 Sep 16 01:10:19 Insp6400 kernel: [ 473.541175] [] b44_poll+0xaf/0x3ec [b44] Sep 16 01:10:19 Insp6400 kernel: [ 473.541175] [] net_rx_action+0xae/0x21c Sep 16 01:10:19 Insp6400 kernel: [ 473.541175] [] __do_softirq+0x112/0x25a Sep 16 01:10:19 Insp6400 kernel: [ 473.541175] [] call_softirq+0x1c/0x30 Sep 16 01:10:19 Insp6400 kernel: [ 473.541175] [] do_softirq+0x4b/0xa2 Sep 16 01:10:19 Insp6400 kernel: [ 473.541175] [] irq_exit+0x5d/0xcf Sep 16 01:10:19 Insp6400 kernel: [ 473.541175] [] xen_evtchn_do_upcall+0x31/0x3e Sep 16 01:10:19 Insp6400 kernel: [ 473.541175] [] xen_do_hypervisor_callback+0x1e/0x30 Sep 16 01:10:19 Insp6400 kernel: [ 473.541175] Sep 16 01:10:19 Insp6400 kernel: [ 473.541175] Sep 16 01:10:19 Insp6400 kernel: [ 473.541175] the dependencies between the lock to be acquired and HARDIRQ-irq-unsafe lock: Sep 16 01:10:19 Insp6400 kernel: [ 473.541175] -> (nf_conntrack_lock){+.-...} ops: 255 { Sep 16 01:10:19 Insp6400 kernel: [ 473.541175] HARDIRQ-ON-W at: Sep 16 01:10:19 Insp6400 kernel: [ 473.541175] [] __lock_acquire+0x345/0xd0c Sep 16 01:10:19 Insp6400 kernel: [ 473.541175] [] lock_acquire+0xf3/0x13e Sep 16 01:10:19 Insp6400 kernel: [ 473.541175] [] _raw_spin_lock_bh+0x4a/0x7e Sep 16 01:10:19 Insp6400 kernel: [ 473.541175] [] nf_conntrack_in+0x461/0x7dc [nf_conntrack] Sep 16 01:10:19 Insp6400 kernel: [ 473.541175] [] ipv4_conntrack_in+0x21/0x23 [nf_conntrack_ipv4] Sep 16 01:10:19 Insp6400 kernel: [ 473.541175] [] nf_iterate+0x4c/0x8c Sep 16 01:10:19 Insp6400 kernel: [ 473.541175] [] nf_hook_slow+0x7c/0x123 Sep 16 01:10:19 Insp6400 kernel: [ 473.541175] [] NF_HOOK.constprop.4+0x46/0x5a Sep 16 01:10:19 Insp6400 kernel: [ 473.541175] [] ip_rcv+0x239/0x264 Sep 16 01:10:19 Insp6400 kernel: [ 473.541175] [] __netif_receive_skb+0x4af/0x508 Sep 16 01:10:19 Insp6400 kernel: [ 473.541175] [] process_backlog+0x8a/0x151 Sep 16 01:10:19 Insp6400 kernel: [ 473.541175] [] net_rx_action+0xae/0x21c Sep 16 01:10:19 Insp6400 kernel: [ 473.541175] [] __do_softirq+0x112/0x25a Sep 16 01:10:19 Insp6400 kernel: [ 473.541175] [] call_softirq+0x1c/0x30 Sep 16 01:10:19 Insp6400 kernel: [ 473.541175] [] do_softirq+0x4b/0xa2 Sep 16 01:10:19 Insp6400 kernel: [ 473.541175] [] irq_exit+0x5d/0xcf Sep 16 01:10:19 Insp6400 kernel: [ 473.541175] [] xen_evtchn_do_upcall+0x31/0x3e Sep 16 01:10:19 Insp6400 kernel: [ 473.541175] [] xen_do_hypervisor_callback+0x1e/0x30 Sep 16 01:10:19 Insp6400 kernel: [ 473.541175] IN-SOFTIRQ-W at: Sep 16 01:10:19 Insp6400 kernel: [ 473.541175] [] __lock_acquire+0x2f5/0xd0c Sep 16 01:10:19 Insp6400 kernel: [ 473.541175] [] lock_acquire+0xf3/0x13e Sep 16 01:10:19 Insp6400 kernel: [ 473.541175] [] _raw_spin_lock_bh+0x4a/0x7e Sep 16 01:10:19 Insp6400 kernel: [ 473.541175] [] nf_conntrack_in+0x461/0x7dc [nf_conntrack] Sep 16 01:10:19 Insp6400 kernel: [ 473.541175] [] ipv4_conntrack_in+0x21/0x23 [nf_conntrack_ipv4] Sep 16 01:10:19 Insp6400 kernel: [ 473.541175] [] nf_iterate+0x4c/0x8c Sep 16 01:10:19 Insp6400 kernel: [ 473.541175] [] nf_hook_slow+0x7c/0x123 Sep 16 01:10:19 Insp6400 kernel: [ 473.541175] [] NF_HOOK.constprop.4+0x46/0x5a Sep 16 01:10:19 Insp6400 kernel: [ 473.541175] [] ip_rcv+0x239/0x264 Sep 16 01:10:19 Insp6400 kernel: [ 473.541175] [] __netif_receive_skb+0x4af/0x508 Sep 16 01:10:19 Insp6400 kernel: [ 473.541175] [] process_backlog+0x8a/0x151 Sep 16 01:10:19 Insp6400 kernel: [ 473.541175] [] net_rx_action+0xae/0x21c Sep 16 01:10:19 Insp6400 kernel: [ 473.541175] [] __do_softirq+0x112/0x25a Sep 16 01:10:19 Insp6400 kernel: [ 473.541175] [] call_softirq+0x1c/0x30 Sep 16 01:10:19 Insp6400 kernel: [ 473.541175] [] do_softirq+0x4b/0xa2 Sep 16 01:10:19 Insp6400 kernel: [ 473.541175] [] irq_exit+0x5d/0xcf Sep 16 01:10:19 Insp6400 kernel: [ 473.541175] [] xen_evtchn_do_upcall+0x31/0x3e Sep 16 01:10:19 Insp6400 kernel: [ 473.541175] [] xen_do_hypervisor_callback+0x1e/0x30 Sep 16 01:10:19 Insp6400 kernel: [ 473.541175] INITIAL USE at: Sep 16 01:10:19 Insp6400 kernel: [ 473.541175] [] __lock_acquire+0x3ba/0xd0c Sep 16 01:10:19 Insp6400 kernel: [ 473.541175] [] lock_acquire+0xf3/0x13e Sep 16 01:10:19 Insp6400 kernel: [ 473.541175] [] _raw_spin_lock_bh+0x4a/0x7e Sep 16 01:10:19 Insp6400 kernel: [ 473.541175] [] nf_conntrack_in+0x461/0x7dc [nf_conntrack] Sep 16 01:10:19 Insp6400 kernel: [ 473.541175] [] ipv4_conntrack_in+0x21/0x23 [nf_conntrack_ipv4] Sep 16 01:10:19 Insp6400 kernel: [ 473.541175] [] nf_iterate+0x4c/0x8c Sep 16 01:10:19 Insp6400 kernel: [ 473.541175] [] nf_hook_slow+0x7c/0x123 Sep 16 01:10:19 Insp6400 kernel: [ 473.541175] [] NF_HOOK.constprop.4+0x46/0x5a Sep 16 01:10:19 Insp6400 kernel: [ 473.541175] [] ip_rcv+0x239/0x264 Sep 16 01:10:19 Insp6400 kernel: [ 473.541175] [] __netif_receive_skb+0x4af/0x508 Sep 16 01:10:19 Insp6400 kernel: [ 473.541175] [] process_backlog+0x8a/0x151 Sep 16 01:10:19 Insp6400 kernel: [ 473.541175] [] net_rx_action+0xae/0x21c Sep 16 01:10:19 Insp6400 kernel: [ 473.541175] [] __do_softirq+0x112/0x25a Sep 16 01:10:19 Insp6400 kernel: [ 473.541175] [] call_softirq+0x1c/0x30 Sep 16 01:10:19 Insp6400 kernel: [ 473.541175] [] do_softirq+0x4b/0xa2 Sep 16 01:10:19 Insp6400 kernel: [ 473.541175] [] irq_exit+0x5d/0xcf Sep 16 01:10:19 Insp6400 kernel: [ 473.541175] [] xen_evtchn_do_upcall+0x31/0x3e Sep 16 01:10:19 Insp6400 kernel: [ 473.541175] [] xen_do_hypervisor_callback+0x1e/0x30 Sep 16 01:10:19 Insp6400 kernel: [ 473.541175] } Sep 16 01:10:19 Insp6400 kernel: [ 473.541175] ... key at: [] nf_conntrack_lock+0x18/0xffffffffffffd000 [nf_conntrack] Sep 16 01:10:19 Insp6400 kernel: [ 473.541175] ... acquired at: Sep 16 01:10:19 Insp6400 kernel: [ 473.541175] [] check_irq_usage+0x42/0x88 Sep 16 01:10:19 Insp6400 kernel: [ 473.541175] [] __lock_acquire+0xa52/0xd0c Sep 16 01:10:19 Insp6400 kernel: [ 473.541175] [] lock_acquire+0xf3/0x13e Sep 16 01:10:19 Insp6400 kernel: [ 473.541175] [] _raw_spin_lock_bh+0x4a/0x7e Sep 16 01:10:19 Insp6400 kernel: [ 473.541175] [] destroy_conntrack+0x70/0xec [nf_conntrack] Sep 16 01:10:19 Insp6400 kernel: [ 473.541175] [] nf_conntrack_destroy+0x5a/0x64 Sep 16 01:10:19 Insp6400 kernel: [ 473.541175] [] skb_release_head_state+0xa7/0xef Sep 16 01:10:19 Insp6400 kernel: [ 473.541175] [] __kfree_skb+0x13/0x83 Sep 16 01:10:19 Insp6400 kernel: [ 473.541175] [] consume_skb+0xa5/0xd1 Sep 16 01:10:19 Insp6400 kernel: [ 473.541175] [] b44_poll+0xaf/0x3ec [b44] Sep 16 01:10:19 Insp6400 kernel: [ 473.541175] [] net_rx_action+0xae/0x21c Sep 16 01:10:19 Insp6400 kernel: [ 473.541175] [] __do_softirq+0x112/0x25a Sep 16 01:10:19 Insp6400 kernel: [ 473.541175] [] call_softirq+0x1c/0x30 Sep 16 01:10:19 Insp6400 kernel: [ 473.541175] [] do_softirq+0x4b/0xa2 Sep 16 01:10:19 Insp6400 kernel: [ 473.541175] [] irq_exit+0x5d/0xcf Sep 16 01:10:19 Insp6400 kernel: [ 473.541175] [] xen_evtchn_do_upcall+0x31/0x3e Sep 16 01:10:19 Insp6400 kernel: [ 473.541175] [] xen_do_hypervisor_callback+0x1e/0x30 Sep 16 01:10:19 Insp6400 kernel: [ 473.541175] Sep 16 01:10:19 Insp6400 kernel: [ 473.541175] Sep 16 01:10:19 Insp6400 kernel: [ 473.541175] stack backtrace: Sep 16 01:10:19 Insp6400 kernel: [ 473.541175] Pid: 0, comm: swapper Not tainted 3.1.0-0.rc6.git0.0.xendom0.fc17.x86_64 #1 Sep 16 01:10:19 Insp6400 kernel: [ 473.541175] Call Trace: Sep 16 01:10:19 Insp6400 kernel: [ 473.541175] [] check_usage+0x37f/0x394 Sep 16 01:10:19 Insp6400 kernel: [ 473.541175] [] ? check_events+0x12/0x20 Sep 16 01:10:19 Insp6400 kernel: [ 473.541175] [] check_irq_usage+0x42/0x88 Sep 16 01:10:19 Insp6400 kernel: [ 473.541175] [] __lock_acquire+0xa52/0xd0c Sep 16 01:10:19 Insp6400 kernel: [ 473.541175] [] ? rcu_read_lock+0x44/0x44 [nf_conntrack] Sep 16 01:10:19 Insp6400 kernel: [ 473.541175] [] ? xen_force_evtchn_callback+0xd/0xf Sep 16 01:10:19 Insp6400 kernel: [ 473.541175] [] ? check_events+0x12/0x20 Sep 16 01:10:19 Insp6400 kernel: [ 473.541175] [] ? xen_force_evtchn_callback+0xd/0xf Sep 16 01:10:19 Insp6400 kernel: [ 473.541175] [] ? destroy_conntrack+0x70/0xec [nf_conntrack] Sep 16 01:10:19 Insp6400 kernel: [ 473.541175] [] lock_acquire+0xf3/0x13e Sep 16 01:10:19 Insp6400 kernel: [ 473.541175] [] ? destroy_conntrack+0x70/0xec [nf_conntrack] Sep 16 01:10:19 Insp6400 kernel: [ 473.541175] [] ? xen_restore_fl_direct_reloc+0x4/0x4 Sep 16 01:10:19 Insp6400 kernel: [ 473.541175] [] _raw_spin_lock_bh+0x4a/0x7e Sep 16 01:10:19 Insp6400 kernel: [ 473.541175] [] ? destroy_conntrack+0x70/0xec [nf_conntrack] Sep 16 01:10:19 Insp6400 kernel: [ 473.541175] [] destroy_conntrack+0x70/0xec [nf_conntrack] Sep 16 01:10:19 Insp6400 kernel: [ 473.541175] [] ? nf_conntrack_free+0x58/0x58 [nf_conntrack] Sep 16 01:10:19 Insp6400 kernel: [ 473.541175] [] nf_conntrack_destroy+0x5a/0x64 Sep 16 01:10:19 Insp6400 kernel: [ 473.541175] [] skb_release_head_state+0xa7/0xef Sep 16 01:10:19 Insp6400 kernel: [ 473.541175] [] __kfree_skb+0x13/0x83 Sep 16 01:10:19 Insp6400 kernel: [ 473.541175] [] consume_skb+0xa5/0xd1 Sep 16 01:10:19 Insp6400 kernel: [ 473.541175] [] b44_poll+0xaf/0x3ec [b44] Sep 16 01:10:19 Insp6400 kernel: [ 473.541175] [] net_rx_action+0xae/0x21c Sep 16 01:10:19 Insp6400 kernel: [ 473.541175] [] ? __do_softirq+0x7e/0x25a Sep 16 01:10:19 Insp6400 kernel: [ 473.541175] [] __do_softirq+0x112/0x25a Sep 16 01:10:19 Insp6400 kernel: [ 473.541175] [] call_softirq+0x1c/0x30 Sep 16 01:10:19 Insp6400 kernel: [ 473.541175] [] do_softirq+0x4b/0xa2 Sep 16 01:10:19 Insp6400 kernel: [ 473.541175] [] irq_exit+0x5d/0xcf Sep 16 01:10:19 Insp6400 kernel: [ 473.541175] [] xen_evtchn_do_upcall+0x31/0x3e Sep 16 01:10:19 Insp6400 kernel: [ 473.541175] [] xen_do_hypervisor_callback+0x1e/0x30 Sep 16 01:10:19 Insp6400 kernel: [ 473.541175] [] ? hypercall_page+0x3aa/0x1000 Sep 16 01:10:19 Insp6400 kernel: [ 473.541175] [] ? hypercall_page+0x3aa/0x1000 Sep 16 01:10:19 Insp6400 kernel: [ 473.541175] [] ? xen_safe_halt+0x10/0x18 Sep 16 01:10:19 Insp6400 kernel: [ 473.541175] [] ? default_idle+0x53/0x90 Sep 16 01:10:19 Insp6400 kernel: [ 473.541175] [] ? cpu_idle+0xb5/0x101 Sep 16 01:10:19 Insp6400 kernel: [ 473.541175] [] ? rest_init+0xdc/0xe3 Sep 16 01:10:19 Insp6400 kernel: [ 473.541175] [] ? csum_partial_copy_generic+0x16c/0x16c Sep 16 01:10:19 Insp6400 kernel: [ 473.541175] [] ? start_kernel+0x3dd/0x3ea Sep 16 01:10:19 Insp6400 kernel: [ 473.541175] [] ? x86_64_start_reservations+0xaf/0xb3 Sep 16 01:10:19 Insp6400 kernel: [ 473.541175] [] ? xen_start_kernel+0x588/0x58f Sep 16 01:10:19 Insp6400 kernel: [ 473.541175] ------------[ cut here ]------------ Sep 16 01:10:19 Insp6400 kernel: [ 473.541175] WARNING: at kernel/softirq.c:159 _local_bh_enable_ip+0x49/0xce() Sep 16 01:10:19 Insp6400 kernel: [ 473.541175] Hardware name: MM061 Sep 16 01:10:19 Insp6400 kernel: [ 473.541175] Modules linked in: fuse ebtable_nat ebtables ipt_MASQUERADE iptable_nat nf_nat xt_CHECKSUM iptable_mangle xen_pciback nfsd lockd nfs_acl auth_rpcgss sunrpc des_generic md4 nls_utf8 cifs fscache bridge stp llc bonding be2iscsi iscsi_boot_sysfs bnx2i cnic uio cxgb3i libcxgbi iw_cxgb3 cxgb3 mdio ib_iser rdma_cm ib_cm iw_cm xt_comment ib_sa ib_mad ib_core ip6t_REJECT ib_addr nf_conntrack_ipv4 nf_defrag_ipv4 nf_conntrack_ipv6 nf_defrag_ipv6 iscsi_tcp xt_state libiscsi_tcp nf_conntrack libiscsi ip6table_filter ipt_LOG scsi_transport_iscsi ip6_tables xt_physdev dell_wmi sparse_keymap snd_hda_codec_idt snd_hda_intel snd_hda_codec snd_hwdep snd_seq snd_seq_device arc4 r852 sm_common nand snd_pcm dell_laptop microcode dcdbas b44 nand_ids r592 nand_ecc iwl3945 ssb memstick mtd mii iwl_legacy iTCO_wdt mac80211 iTCO_vendor_support i2c_i801 joydev cfg80211 snd_timer rfkill snd soundcore snd_page_alloc tun xen_gntalloc xen_netback xen_blkback xen_gntdev xen_evtchn xenfs binfmt_misc Sep 16 01:10:19 Insp6400 kernel: sdhci_pci sdhci mmc_core firewire_ohci firewire_core crc_itu_t wmi i915 drm_kms_helper drm i2c_algo_bit i2c_core video [last unloaded: scsi_wait_scan] Sep 16 01:10:19 Insp6400 kernel: [ 473.541175] Pid: 0, comm: swapper Not tainted 3.1.0-0.rc6.git0.0.xendom0.fc17.x86_64 #1 Sep 16 01:10:19 Insp6400 kernel: [ 473.541175] Call Trace: Sep 16 01:10:19 Insp6400 kernel: [ 473.541175] [] warn_slowpath_common+0x83/0x9b Sep 16 01:10:19 Insp6400 kernel: [ 473.541175] [] ? destroy_conntrack+0xad/0xec [nf_conntrack] Sep 16 01:10:19 Insp6400 kernel: [ 473.541175] [] warn_slowpath_null+0x1a/0x1c Sep 16 01:10:19 Insp6400 kernel: [ 473.541175] [] _local_bh_enable_ip+0x49/0xce Sep 16 01:10:19 Insp6400 kernel: [ 473.541175] [] local_bh_enable_ip+0xe/0x10 Sep 16 01:10:19 Insp6400 kernel: [ 473.541175] [] _raw_spin_unlock_bh+0x40/0x44 Sep 16 01:10:19 Insp6400 kernel: [ 473.541175] [] destroy_conntrack+0xad/0xec [nf_conntrack] Sep 16 01:10:19 Insp6400 kernel: [ 473.541175] [] ? nf_conntrack_free+0x58/0x58 [nf_conntrack] Sep 16 01:10:19 Insp6400 kernel: [ 473.541175] [] nf_conntrack_destroy+0x5a/0x64 Sep 16 01:10:19 Insp6400 kernel: [ 473.541175] [] skb_release_head_state+0xa7/0xef Sep 16 01:10:19 Insp6400 kernel: [ 473.541175] [] __kfree_skb+0x13/0x83 Sep 16 01:10:19 Insp6400 kernel: [ 473.541175] [] consume_skb+0xa5/0xd1 Sep 16 01:10:19 Insp6400 kernel: [ 473.541175] [] b44_poll+0xaf/0x3ec [b44] Sep 16 01:10:19 Insp6400 kernel: [ 473.541175] [] net_rx_action+0xae/0x21c Sep 16 01:10:19 Insp6400 kernel: [ 473.541175] [] ? __do_softirq+0x7e/0x25a Sep 16 01:10:19 Insp6400 kernel: [ 473.541175] [] __do_softirq+0x112/0x25a Sep 16 01:10:19 Insp6400 kernel: [ 473.541175] [] call_softirq+0x1c/0x30 Sep 16 01:10:19 Insp6400 kernel: [ 473.541175] [] do_softirq+0x4b/0xa2 Sep 16 01:10:19 Insp6400 kernel: [ 473.541175] [] irq_exit+0x5d/0xcf Sep 16 01:10:19 Insp6400 kernel: [ 473.541175] [] xen_evtchn_do_upcall+0x31/0x3e Sep 16 01:10:19 Insp6400 kernel: [ 473.541175] [] xen_do_hypervisor_callback+0x1e/0x30 Sep 16 01:10:19 Insp6400 kernel: [ 473.541175] [] ? hypercall_page+0x3aa/0x1000 Sep 16 01:10:19 Insp6400 kernel: [ 473.541175] [] ? hypercall_page+0x3aa/0x1000 Sep 16 01:10:19 Insp6400 kernel: [ 473.541175] [] ? xen_safe_halt+0x10/0x18 Sep 16 01:10:19 Insp6400 kernel: [ 473.541175] [] ? default_idle+0x53/0x90 Sep 16 01:10:19 Insp6400 kernel: [ 473.541175] [] ? cpu_idle+0xb5/0x101 Sep 16 01:10:19 Insp6400 kernel: [ 473.541175] [] ? rest_init+0xdc/0xe3 Sep 16 01:10:19 Insp6400 kernel: [ 473.541175] [] ? csum_partial_copy_generic+0x16c/0x16c Sep 16 01:10:19 Insp6400 kernel: [ 473.541175] [] ? start_kernel+0x3dd/0x3ea Sep 16 01:10:19 Insp6400 kernel: [ 473.541175] [] ? x86_64_start_reservations+0xaf/0xb3 Sep 16 01:10:19 Insp6400 kernel: [ 473.541175] [] ? xen_start_kernel+0x588/0x58f Sep 16 01:10:19 Insp6400 kernel: [ 473.541175] ---[ end trace dfe23b483fd11a0c ]--- _______________________________________________ Xen-users mailing list Xen-users@lists.xensource.com http://lists.xensource.com/xen-users From xen-devel-bounces@lists.xensource.com Fri Sep 16 08:10:52 2011 Return-path: Envelope-to: www-data@lists.xensource.com Delivery-date: Fri, 16 Sep 2011 08:10:52 -0700 Received: from localhost ([127.0.0.1] helo=lists.colo.xensource.com) by lists.xensource.com with esmtp (Exim 4.43) id 1R4a43-0004kh-Lm; Fri, 16 Sep 2011 08:10:51 -0700 Received: from mail216.messagelabs.com ([85.158.143.99]) by lists.xensource.com with esmtp (Exim 4.43) id 1R4Zpy-00037u-KM for xen-devel@lists.xensource.com; Fri, 16 Sep 2011 07:56:19 -0700 X-Env-Sender: Ian.Jackson@eu.citrix.com X-Msg-Ref: server-3.tower-216.messagelabs.com!1316184975!17517999!1 X-Originating-IP: [62.200.22.115] X-StarScan-Version: 6.4.1; banners=-,-,- X-VirusChecked: Checked Received: (qmail 2242 invoked from network); 16 Sep 2011 14:56:15 -0000 Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115) by server-3.tower-216.messagelabs.com with RC4-SHA encrypted SMTP; 16 Sep 2011 14:56:15 -0000 X-IronPort-AV: E=Sophos;i="4.68,393,1312156800"; d="scan'208";a="7894456" Received: from lonpmailmx01.citrite.net ([10.30.203.162]) by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5; 16 Sep 2011 14:56:15 +0000 Received: from woking.xci-test.com (10.80.248.135) by smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id 8.3.137.0; Fri, 16 Sep 2011 15:56:15 +0100 Received: from osstest by woking.xci-test.com with local (Exim 4.69) (envelope-from ) id 1R4Zpv-0004mF-AY; Fri, 16 Sep 2011 15:56:15 +0100 To: xen-devel@lists.xensource.com Message-ID: From: xen.org Date: Fri, 16 Sep 2011 15:56:15 +0100 MIME-Version: 1.0 Content-Type: text/plain Cc: ian.jackson@eu.citrix.com Subject: [Xen-devel] [xen-unstable test] 8951: tolerable FAIL - PUSHED X-BeenThere: xen-devel@lists.xensource.com X-Mailman-Version: 2.1.5 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xensource.com Errors-To: xen-devel-bounces@lists.xensource.com flight 8951 xen-unstable real [real] http://www.chiark.greenend.org.uk/~xensrcts/logs/8951/ Failures :-/ but no regressions. Tests which did not succeed, but are not blocking, including regressions (tests previously passed) regarded as allowable: test-amd64-amd64-xl-pcipt-intel 1 xen-build-check(1) blocked n/a test-amd64-i386-pair 1 xen-build-check(1) blocked n/a test-amd64-i386-rhel6hvm-intel 1 xen-build-check(1) blocked n/a test-i386-i386-pv 1 xen-build-check(1) blocked n/a build-i386-pvops 4 kernel-build fail like 8948 test-amd64-i386-pv 1 xen-build-check(1) blocked n/a test-amd64-amd64-pv 1 xen-build-check(1) blocked n/a test-i386-i386-xl 1 xen-build-check(1) blocked n/a test-amd64-i386-xl-multivcpu 1 xen-build-check(1) blocked n/a build-amd64-pvops 4 kernel-build fail like 8948 test-amd64-i386-xl 1 xen-build-check(1) blocked n/a test-amd64-i386-xl-credit2 1 xen-build-check(1) blocked n/a test-amd64-i386-rhel6hvm-amd 1 xen-build-check(1) blocked n/a test-amd64-amd64-pair 1 xen-build-check(1) blocked n/a test-i386-i386-pair 1 xen-build-check(1) blocked n/a test-amd64-amd64-win 1 xen-build-check(1) blocked n/a test-amd64-amd64-xl-win 1 xen-build-check(1) blocked n/a test-amd64-i386-win 1 xen-build-check(1) blocked n/a test-amd64-amd64-xl-sedf 1 xen-build-check(1) blocked n/a test-amd64-i386-win-vcpus1 1 xen-build-check(1) blocked n/a test-amd64-i386-xl-win-vcpus1 1 xen-build-check(1) blocked n/a test-amd64-amd64-xl 1 xen-build-check(1) blocked n/a test-i386-i386-xl-win 1 xen-build-check(1) blocked n/a test-i386-i386-win 1 xen-build-check(1) blocked n/a version targeted for testing: xen 483c5f8319ad baseline version: xen 4815be3af73c ------------------------------------------------------------ People who touched revisions under test: Ian Jackson Juergen Gross Olaf Hering Tim Deegan ------------------------------------------------------------ jobs: build-amd64 pass build-i386 pass build-amd64-oldkern pass build-i386-oldkern pass build-amd64-pvops fail build-i386-pvops fail test-amd64-amd64-xl blocked test-amd64-i386-xl blocked test-i386-i386-xl blocked test-amd64-i386-rhel6hvm-amd blocked test-amd64-i386-xl-credit2 blocked test-amd64-amd64-xl-pcipt-intel blocked test-amd64-i386-rhel6hvm-intel blocked test-amd64-i386-xl-multivcpu blocked test-amd64-amd64-pair blocked test-amd64-i386-pair blocked test-i386-i386-pair blocked test-amd64-amd64-pv blocked test-amd64-i386-pv blocked test-i386-i386-pv blocked test-amd64-amd64-xl-sedf blocked test-amd64-i386-win-vcpus1 blocked test-amd64-i386-xl-win-vcpus1 blocked test-amd64-amd64-win blocked test-amd64-i386-win blocked test-i386-i386-win blocked test-amd64-amd64-xl-win blocked test-i386-i386-xl-win blocked ------------------------------------------------------------ sg-report-flight on woking.cam.xci-test.com logs: /home/xc_osstest/logs images: /home/xc_osstest/images Logs, config files, etc. are available at http://www.chiark.greenend.org.uk/~xensrcts/logs Test harness code can be found at http://xenbits.xensource.com/gitweb?p=osstest.git;a=summary Pushing revision : + branch=xen-unstable + revision=483c5f8319ad + . cri-lock-repos ++ . cri-common +++ umask 002 +++ getconfig Repos +++ perl -e ' use Osstest; readconfigonly(); print $c{Repos} or die $!; ' ++ repos=/export/home/osstest/repos ++ repos_lock=/export/home/osstest/repos/lock ++ '[' x '!=' x/export/home/osstest/repos/lock ']' ++ OSSTEST_REPOS_LOCK_LOCKED=/export/home/osstest/repos/lock ++ exec with-lock-ex -w /export/home/osstest/repos/lock ./ap-push xen-unstable 483c5f8319ad + branch=xen-unstable + revision=483c5f8319ad + . cri-lock-repos ++ . cri-common +++ umask 002 +++ getconfig Repos +++ perl -e ' use Osstest; readconfigonly(); print $c{Repos} or die $!; ' ++ repos=/export/home/osstest/repos ++ repos_lock=/export/home/osstest/repos/lock ++ '[' x/export/home/osstest/repos/lock '!=' x/export/home/osstest/repos/lock ']' + : xen@xenbits.xensource.com + : xen@xenbits.xensource.com:git/linux-pvops + : master + : tested/2.6.39.x + case "$branch" in + cd /export/home/osstest/repos/xen-unstable.hg + hg push -r 483c5f8319ad ssh://xen@xenbits.xensource.com/HG/xen-unstable.hg pushing to ssh://xen@xenbits.xensource.com/HG/xen-unstable.hg searching for changes remote: adding changesets remote: adding manifests remote: adding file changes remote: added 2 changesets with 21 changes to 17 files _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel From xen-devel-bounces@lists.xensource.com Fri Sep 16 08:41:20 2011 Return-path: Envelope-to: www-data@lists.xensource.com Delivery-date: Fri, 16 Sep 2011 08:41:20 -0700 Received: from localhost ([127.0.0.1] helo=lists.colo.xensource.com) by lists.xensource.com with esmtp (Exim 4.43) id 1R4aXX-0005rA-T1; Fri, 16 Sep 2011 08:41:20 -0700 Received: from mail216.messagelabs.com ([85.158.143.99]) by lists.xensource.com with esmtp (Exim 4.43) id 1R4aWn-0005dq-Kk for xen-devel@lists.xensource.com; Fri, 16 Sep 2011 08:40:33 -0700 X-Env-Sender: royger@gmail.com X-Msg-Ref: server-12.tower-216.messagelabs.com!1316187630!12810912!1 X-Originating-IP: [74.125.82.43] X-StarScan-Version: 6.4.1; banners=-,-,- X-VirusChecked: Checked Received: (qmail 14677 invoked from network); 16 Sep 2011 15:40:30 -0000 Received: from mail-ww0-f43.google.com (HELO mail-ww0-f43.google.com) (74.125.82.43) by server-12.tower-216.messagelabs.com with RC4-SHA encrypted SMTP; 16 Sep 2011 15:40:30 -0000 Received: by wwf27 with SMTP id 27so4209688wwf.24 for ; Fri, 16 Sep 2011 08:40:30 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=sender:content-type:mime-version:content-transfer-encoding:subject :message-id:user-agent:date:from:to; bh=sVfHdzcu15f/XmdC0mEPDqphAfREXkyxECwEA/o8ccY=; b=GphiDBO4HuIXbg/L9+EX0uGlPzauZ1jAyJ+owc7y5KnJuNh+/Bog0nR9HuKXKyvxpu wftsnorxtk/xSOOa/GNBFq5rIbedruoA4XLCHlZbgtpGXM1lwNR/l3DmViNJWy//etnh Anw1UDGvo8VBxECYjVdZBo76J+rG/GANqyyvA= Received: by 10.216.203.168 with SMTP id f40mr904303weo.6.1316187630399; Fri, 16 Sep 2011 08:40:30 -0700 (PDT) Received: from [127.0.0.1] (monk.upc.es. [147.83.39.235]) by mx.google.com with ESMTPS id fa3sm13033927wbb.3.2011.09.16.08.40.27 (version=TLSv1/SSLv3 cipher=OTHER); Fri, 16 Sep 2011 08:40:28 -0700 (PDT) Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Message-Id: User-Agent: Mercurial-patchbomb/1.8.4 Date: Fri, 16 Sep 2011 17:36:57 +0200 From: Roger Pau Monne To: xen-devel@lists.xensource.com Subject: [Xen-devel] [PATCH 0 of 2] Add NetBSD support for libxl PV DomU X-BeenThere: xen-devel@lists.xensource.com X-Mailman-Version: 2.1.5 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xensource.com Errors-To: xen-devel-bounces@lists.xensource.com This series of patches adds NetBSD support to libxl, using hotplug-status to synchronize the unplugging of vbd devices. _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel From xen-devel-bounces@lists.xensource.com Fri Sep 16 08:42:30 2011 Return-path: Envelope-to: www-data@lists.xensource.com Delivery-date: Fri, 16 Sep 2011 08:42:30 -0700 Received: from localhost ([127.0.0.1] helo=lists.colo.xensource.com) by lists.xensource.com with esmtp (Exim 4.43) id 1R4aYg-0006FO-OC; Fri, 16 Sep 2011 08:42:30 -0700 Received: from mail174.messagelabs.com ([85.158.138.51]) by lists.xensource.com with esmtp (Exim 4.43) id 1R4aWs-0005dy-1S for xen-devel@lists.xensource.com; Fri, 16 Sep 2011 08:40:38 -0700 X-Env-Sender: royger@gmail.com X-Msg-Ref: server-9.tower-174.messagelabs.com!1316187633!25669209!1 X-Originating-IP: [74.125.82.176] X-StarScan-Version: 6.4.1; banners=-,-,- X-VirusChecked: Checked Received: (qmail 16451 invoked from network); 16 Sep 2011 15:40:33 -0000 Received: from mail-wy0-f176.google.com (HELO mail-wy0-f176.google.com) (74.125.82.176) by server-9.tower-174.messagelabs.com with RC4-SHA encrypted SMTP; 16 Sep 2011 15:40:33 -0000 Received: by wyg10 with SMTP id 10so3025371wyg.7 for ; Fri, 16 Sep 2011 08:40:33 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=sender:content-type:mime-version:content-transfer-encoding:subject :x-mercurial-node:message-id:in-reply-to:references:user-agent:date :from:to; bh=AkVoZKr0qu4IJY9mG9zBgMvhNm39PgGvx9+N7jUyI90=; b=xzCDxB1/mRkP0eMrKk6CignOtOt1X/9Ps4GLm1MvnLVteE8viz4Y2Xfpt/GKIuZUWG LHeiNXiT79/JFzpCryXsFSoOva95nV15yFquejjbRPvBaeuZ/Gg4bNUpKpBxdxjJ5VWs Hl5roiH3Ip2nm04SMoNyFIszpUyBNY+f6sKhU= Received: by 10.216.131.16 with SMTP id l16mr1586242wei.74.1316187632586; Fri, 16 Sep 2011 08:40:32 -0700 (PDT) Received: from [127.0.0.1] (monk.upc.es. [147.83.39.235]) by mx.google.com with ESMTPS id fa3sm13033927wbb.3.2011.09.16.08.40.30 (version=TLSv1/SSLv3 cipher=OTHER); Fri, 16 Sep 2011 08:40:31 -0700 (PDT) Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Mercurial-Node: 00949e363f6f2c70001da548403475628df93b97 Message-Id: <00949e363f6f2c70001d.1316187418@loki> In-Reply-To: References: User-Agent: Mercurial-patchbomb/1.8.4 Date: Fri, 16 Sep 2011 17:36:58 +0200 From: Roger Pau Monne To: xen-devel@lists.xensource.com Subject: [Xen-devel] [PATCH 1 of 2] hotplug: add hotplug-status disconnected X-BeenThere: xen-devel@lists.xensource.com X-Mailman-Version: 2.1.5 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xensource.com Errors-To: xen-devel-bounces@lists.xensource.com # HG changeset patch # User Roger Pau Monne # Date 1316186985 -7200 # Node ID 00949e363f6f2c70001da548403475628df93b97 # Parent 63e254468d6e8d81baeafaed68f05791dc21eb4e hotplug: add hotplug-status disconnected Added hotplug-status disconnected when vbd are removed. Signed-off-by: Roger Pau Monne diff -r 63e254468d6e -r 00949e363f6f tools/hotplug/Linux/block --- a/tools/hotplug/Linux/block Wed Sep 14 14:18:40 2011 +0200 +++ b/tools/hotplug/Linux/block Fri Sep 16 17:29:45 2011 +0200 @@ -321,6 +321,7 @@ mount it read-write in a guest domain." remove) case $t in phy) + xenstore_write "$XENBUS_PATH/hotplug-status" "disconnected" exit 0 ;; @@ -329,6 +330,7 @@ mount it read-write in a guest domain." node=$(xenstore_read "$XENBUS_PATH/node") losetup -d "$node" release_lock "block" + xenstore_write "$XENBUS_PATH/hotplug-status" "disconnected" exit 0 ;; diff -r 63e254468d6e -r 00949e363f6f tools/hotplug/NetBSD/block --- a/tools/hotplug/NetBSD/block Wed Sep 14 14:18:40 2011 +0200 +++ b/tools/hotplug/NetBSD/block Fri Sep 16 17:29:45 2011 +0200 @@ -19,7 +19,7 @@ error() { xpath=$1 xstatus=$2 -xtype=$(xenstore-read "$xpath/type") +xtype=$3 xparams=$(xenstore-read "$xpath/params") case $xstatus in @@ -38,6 +38,8 @@ 6) echo "unknown type $xtype" >&2 ;; esac + echo xenstore-write $xpath/hotplug-status disconnected + xenstore-write $xpath/hotplug-status disconnected xenstore-rm $xpath exit 0 ;; diff -r 63e254468d6e -r 00949e363f6f tools/xenbackendd/xenbackendd.c --- a/tools/xenbackendd/xenbackendd.c Wed Sep 14 14:18:40 2011 +0200 +++ b/tools/xenbackendd/xenbackendd.c Fri Sep 16 17:29:45 2011 +0200 @@ -89,15 +89,15 @@ dodebug(const char *fmt, ...) } static void -doexec(const char *cmd, const char *arg1, const char *arg2) +doexec(const char *cmd, const char *arg1, const char *arg2, const char *arg3) { - dodebug("exec %s %s %s", cmd, arg1, arg2); + dodebug("exec %s %s %s %s", cmd, arg1, arg2, arg3); switch(vfork()) { case -1: dolog(LOG_ERR, "can't vfork: %s", strerror(errno)); break; case 0: - execl(cmd, cmd, arg1, arg2, NULL); + execl(cmd, cmd, arg1, arg2, arg3, NULL); dolog(LOG_ERR, "can't exec %s: %s", cmd, strerror(errno)); exit(EXIT_FAILURE); /* NOTREACHED */ @@ -145,11 +145,14 @@ xen_setup(void) int main(int argc, char * const argv[]) { + struct stat stab; char **vec; unsigned int num; char *s; int state; char *sstate; + char *stype; + char *params; char *p; char buf[80]; int type; @@ -169,7 +172,7 @@ main(int argc, char * const argv[]) log_file = optarg; break; case 'p': - pidfile = pidfile; + pidfile = optarg; case 's': vbd_script = optarg; break; @@ -297,11 +300,38 @@ main(int argc, char * const argv[]) strerror(errno)); goto next2; } - doexec(s, vec[XS_WATCH_PATH], sstate); + doexec(s, vec[XS_WATCH_PATH], sstate, NULL); break; case DEVTYPE_VBD: - doexec(vbd_script, vec[XS_WATCH_PATH], sstate); + /* check if given file is a block device or a raw image */ + snprintf(buf, sizeof(buf), "%s/params", vec[XS_WATCH_PATH]); + params = xs_read(xs, XBT_NULL, buf, 0); + if(params == NULL) { + dolog(LOG_ERR, + "Failed to read %s (%s)", buf, strerror(errno)); + goto next2; + } + if (stat(params, &stab) < 0) { + dolog(LOG_ERR, + "Failed to get info about %s (%s)", params, + strerror(errno)); + goto next3; + } + stype = NULL; + if (S_ISBLK(stab.st_mode)) + stype = "phy"; + if (S_ISREG(stab.st_mode)) + stype = "file"; + if (stype == NULL) { + dolog(LOG_ERR, + "Failed to attach %s (not a block device or raw image)", + params, strerror(errno)); + goto next3; + } + doexec(vbd_script, vec[XS_WATCH_PATH], sstate, stype); +next3: + free(params); break; default: _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel From xen-devel-bounces@lists.xensource.com Fri Sep 16 08:43:22 2011 Return-path: Envelope-to: www-data@lists.xensource.com Delivery-date: Fri, 16 Sep 2011 08:43:22 -0700 Received: from localhost ([127.0.0.1] helo=lists.colo.xensource.com) by lists.xensource.com with esmtp (Exim 4.43) id 1R4aZW-0006dB-IQ; Fri, 16 Sep 2011 08:43:22 -0700 Received: from mail174.messagelabs.com ([85.158.138.51]) by lists.xensource.com with esmtp (Exim 4.43) id 1R4aWs-0005dz-36 for xen-devel@lists.xensource.com; Fri, 16 Sep 2011 08:40:38 -0700 X-Env-Sender: royger@gmail.com X-Msg-Ref: server-15.tower-174.messagelabs.com!1316187634!25355700!1 X-Originating-IP: [74.125.82.41] X-StarScan-Version: 6.4.1; banners=-,-,- X-VirusChecked: Checked Received: (qmail 4097 invoked from network); 16 Sep 2011 15:40:35 -0000 Received: from mail-ww0-f41.google.com (HELO mail-ww0-f41.google.com) (74.125.82.41) by server-15.tower-174.messagelabs.com with RC4-SHA encrypted SMTP; 16 Sep 2011 15:40:35 -0000 Received: by wwf10 with SMTP id 10so760350wwf.0 for ; Fri, 16 Sep 2011 08:40:34 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=sender:content-type:mime-version:content-transfer-encoding:subject :x-mercurial-node:message-id:in-reply-to:references:user-agent:date :from:to; bh=qczwEnbx93uxw7ZjO/WbcmnwJmUHcOdAo5sMgOaAZ90=; b=MMnR4KxrQrVhH4XLSFT0aDlDynKaiBimELN6K3Kbmw1h8SmagviRr1J5AzS+N3WS+d L87fNa+pen4EudMuwqQ0QE0pqCrtZWa7RkW1sY3CknpF/l0J5B6PaFZX7f8g282vLPMc nx28HDaVvSgNw1rqpgDdxGysM987Y96FxtE54= Received: by 10.216.15.76 with SMTP id e54mr1674835wee.54.1316187634546; Fri, 16 Sep 2011 08:40:34 -0700 (PDT) Received: from [127.0.0.1] (monk.upc.es. [147.83.39.235]) by mx.google.com with ESMTPS id fa3sm13033927wbb.3.2011.09.16.08.40.32 (version=TLSv1/SSLv3 cipher=OTHER); Fri, 16 Sep 2011 08:40:33 -0700 (PDT) Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Mercurial-Node: aff3960421768180410c8d553acf8881435bc3b4 Message-Id: In-Reply-To: References: User-Agent: Mercurial-patchbomb/1.8.4 Date: Fri, 16 Sep 2011 17:36:59 +0200 From: Roger Pau Monne To: xen-devel@lists.xensource.com Subject: [Xen-devel] [PATCH 2 of 2] libxl: add support for booting PV domains from NetBSD using raw files as disks X-BeenThere: xen-devel@lists.xensource.com X-Mailman-Version: 2.1.5 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xensource.com Errors-To: xen-devel-bounces@lists.xensource.com # HG changeset patch # User Roger Pau Monne # Date 1316187362 -7200 # Node ID aff3960421768180410c8d553acf8881435bc3b4 # Parent 00949e363f6f2c70001da548403475628df93b97 libxl: add support for booting PV domains from NetBSD using raw files as disks. Used the hotplug-status attribute in xenstore for vbd to check when the device is offline. Signed-off-by: Roger Pau Monne diff -r 00949e363f6f -r aff396042176 tools/libxl/libxl_device.c --- a/tools/libxl/libxl_device.c Fri Sep 16 17:29:45 2011 +0200 +++ b/tools/libxl/libxl_device.c Fri Sep 16 17:36:02 2011 +0200 @@ -136,15 +136,20 @@ static int disk_try_backend(disk_try_bac a->disk->format == LIBXL_DISK_FORMAT_EMPTY)) { goto bad_format; } - if (a->disk->format != LIBXL_DISK_FORMAT_EMPTY && - !S_ISBLK(a->stab.st_mode)) { - LIBXL__LOG(ctx, LIBXL__LOG_DEBUG, "Disk vdev=%s, backend phy" - " unsuitable as phys path not a block device", - a->disk->vdev); - return 0; - } - - return backend; + if (S_ISBLK(a->stab.st_mode)) + return backend; +#ifdef HAVE_PHY_BACKEND_FILE_SUPPORT + if (S_ISREG(a->stab.st_mode)) + return backend; + LIBXL__LOG(ctx, LIBXL__LOG_DEBUG, "Disk vdev=%s, backend phy" + " unsuitable as phys path not a block device or" + " raw image", a->disk->vdev); +#else + LIBXL__LOG(ctx, LIBXL__LOG_DEBUG, "Disk vdev=%s, backend phy" + " unsuitable as phys path not a block device", + a->disk->vdev); +#endif + return 0; case LIBXL_DISK_BACKEND_TAP: if (!libxl__blktap_enabled(a->gc)) { @@ -366,14 +371,26 @@ int libxl__device_destroy(libxl__gc *gc, libxl_ctx *ctx = libxl__gc_owner(gc); xs_transaction_t t; char *state_path = libxl__sprintf(gc, "%s/state", be_path); + char *hotplug_path = libxl__sprintf(gc, "%s/hotplug-status", be_path); char *state = libxl__xs_read(gc, XBT_NULL, state_path); + char *hotplug = libxl__xs_read(gc, XBT_NULL, hotplug_path); int rc = 0; if (!state) goto out; - if (atoi(state) != 4) { - xs_rm(ctx->xsh, XBT_NULL, be_path); - goto out; + + if (!strstr(be_path, "vbd")) { + if (atoi(state) != 4) { + xs_rm(ctx->xsh, XBT_NULL, be_path); + goto out; + } + } else { + if (!hotplug) + goto out; + if (!strcmp(hotplug, "disconnected")) { + xs_rm(ctx->xsh, XBT_NULL, be_path); + goto out; + } } retry_transaction: @@ -389,8 +406,13 @@ retry_transaction: } } if (!force) { - xs_watch(ctx->xsh, state_path, be_path); - rc = 1; + if (strstr(be_path, "vbd")) { + xs_watch(ctx->xsh, hotplug_path, be_path); + rc = 1; + } else { + xs_watch(ctx->xsh, state_path, be_path); + rc = 1; + } } else { xs_rm(ctx->xsh, XBT_NULL, be_path); } @@ -405,6 +427,7 @@ static int wait_for_dev_destroy(libxl__g unsigned int n; fd_set rfds; char **l1 = NULL; + char *state, *hotplug; rc = 1; nfds = xs_fileno(ctx->xsh) + 1; @@ -413,15 +436,29 @@ static int wait_for_dev_destroy(libxl__g if (select(nfds, &rfds, NULL, NULL, tv) > 0) { l1 = xs_read_watch(ctx->xsh, &n); if (l1 != NULL) { - char *state = libxl__xs_read(gc, XBT_NULL, l1[XS_WATCH_PATH]); - if (!state || atoi(state) == 6) { - xs_unwatch(ctx->xsh, l1[0], l1[1]); - xs_rm(ctx->xsh, XBT_NULL, l1[XS_WATCH_TOKEN]); - LIBXL__LOG(ctx, LIBXL__LOG_DEBUG, "Destroyed device backend at %s", l1[XS_WATCH_TOKEN]); - rc = 0; + if (strstr(l1[XS_WATCH_PATH], "hotplug-status")) { + hotplug = libxl__xs_read(gc, XBT_NULL, l1[XS_WATCH_PATH]); + if (!hotplug || !strcmp(hotplug, "disconnected")) { + xs_unwatch(ctx->xsh, l1[0], l1[1]); + xs_rm(ctx->xsh, XBT_NULL, l1[XS_WATCH_TOKEN]); + LIBXL__LOG(ctx, LIBXL__LOG_DEBUG, "Destroyed device backend at %s hotplug-status: %s", + l1[XS_WATCH_TOKEN], hotplug); + rc = 0; + } + } else { + state = libxl__xs_read(gc, XBT_NULL, l1[XS_WATCH_PATH]); + if (!state || atoi(state) == 6) { + xs_unwatch(ctx->xsh, l1[0], l1[1]); + xs_rm(ctx->xsh, XBT_NULL, l1[XS_WATCH_TOKEN]); + LIBXL__LOG(ctx, LIBXL__LOG_DEBUG, "Destroyed device backend at %s", l1[XS_WATCH_TOKEN]); + rc = 0; + } } free(l1); } + } else { + /* timeout reached */ + rc = 0; } return rc; } @@ -482,7 +519,7 @@ int libxl__devices_destroy(libxl__gc *gc tv.tv_usec = 0; while (n_watches > 0) { if (wait_for_dev_destroy(gc, &tv)) { - break; + continue; } else { n_watches--; } diff -r 00949e363f6f -r aff396042176 tools/libxl/libxl_osdeps.h --- a/tools/libxl/libxl_osdeps.h Fri Sep 16 17:29:45 2011 +0200 +++ b/tools/libxl/libxl_osdeps.h Fri Sep 16 17:36:02 2011 +0200 @@ -25,6 +25,7 @@ #if defined(__NetBSD__) || defined(__OpenBSD__) #include +#define HAVE_PHY_BACKEND_FILE_SUPPORT #elif defined(__linux__) #include #elif defined(__sun__) _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel From xen-devel-bounces@lists.xensource.com Fri Sep 16 09:53:43 2011 Return-path: Envelope-to: www-data@lists.xensource.com Delivery-date: Fri, 16 Sep 2011 09:53:43 -0700 Received: from localhost ([127.0.0.1] helo=lists.colo.xensource.com) by lists.xensource.com with esmtp (Exim 4.43) id 1R4bfb-00022V-2L; Fri, 16 Sep 2011 09:53:43 -0700 Received: from mail182.messagelabs.com ([85.158.139.83]) by lists.xensource.com with smtp (Exim 4.43) id 1R4bey-0001qK-3Y for xen-devel@lists.xensource.com; Fri, 16 Sep 2011 09:53:04 -0700 X-Env-Sender: gcvxd-xen-devel@m.gmane.org X-Msg-Ref: server-9.tower-182.messagelabs.com!1316191981!18628318!1 X-Originating-IP: [80.91.229.12] X-StarScan-Version: 6.4.1; banners=-,-,- X-VirusChecked: Checked Received: (qmail 10501 invoked from network); 16 Sep 2011 16:53:01 -0000 Received: from lo.gmane.org (HELO lo.gmane.org) (80.91.229.12) by server-9.tower-182.messagelabs.com with SMTP; 16 Sep 2011 16:53:01 -0000 Received: from list by lo.gmane.org with local (Exim 4.69) (envelope-from ) id 1R4beu-00088N-5C for xen-devel@lists.xensource.com; Fri, 16 Sep 2011 18:53:00 +0200 Received: from staff.ndchost.com ([204.10.36.76]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Fri, 16 Sep 2011 18:53:00 +0200 Received: from mailinglists by staff.ndchost.com with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Fri, 16 Sep 2011 18:53:00 +0200 X-Injected-Via-Gmane: http://gmane.org/ To: xen-devel@lists.xensource.com From: Shaun Reitan Date: Fri, 16 Sep 2011 09:52:39 -0700 Organization: Network Data Center Host, Inc. Lines: 17 Message-ID: <4E737ED7.2000907@unix-scripts.com> References: <20110916082456.GA884@phenom.oracle.com> Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Complaints-To: usenet@dough.gmane.org Cc: xen-devel@lists.xensource.com X-Gmane-NNTP-Posting-Host: staff.ndchost.com User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.2.22) Gecko/20110902 Thunderbird/3.1.14 In-Reply-To: <20110916082456.GA884@phenom.oracle.com> Subject: [Xen-devel] Re: kernel BUG at mm/swapfile.c:2527! X-BeenThere: xen-devel@lists.xensource.com X-Mailman-Version: 2.1.5 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xensource.com Errors-To: xen-devel-bounces@lists.xensource.com > How do I reproduce it? Is the PCI compliance easily available? Is > there any chance we can get access to the physical box to figure > out what is happening? At this point I'm not able to reproduce the problem on the fly. We had thought it was a PCI compliance scan that was triggering the error but now this customer is seeing the error constantly and the scans are not running. I'm thrashing a test server that i attempted to setup exactly like this customers server and so far no crash. The customers server is crashing like crazy, I'm attempting to figure out the trigger but it's proving difficult. What do you need to see to figure out why it's crashing? I'm willing to do whatever it takes but I cannot give you access to the host, but customer is willing to give you access to there virtual instance as a last resort. ~Shaun _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel From xen-devel-bounces@lists.xensource.com Fri Sep 16 10:28:18 2011 Return-path: Envelope-to: www-data@lists.xensource.com Delivery-date: Fri, 16 Sep 2011 10:28:18 -0700 Received: from localhost ([127.0.0.1] helo=lists.colo.xensource.com) by lists.xensource.com with esmtp (Exim 4.43) id 1R4cD4-0002ui-N1; Fri, 16 Sep 2011 10:28:18 -0700 Received: from mail27.messagelabs.com ([193.109.254.147]) by lists.xensource.com with esmtp (Exim 4.43) id 1R4cC7-0002hu-RR for xen-devel@lists.xensource.com; Fri, 16 Sep 2011 10:27:20 -0700 X-Env-Sender: konrad@oracle.com X-Msg-Ref: server-9.tower-27.messagelabs.com!1316194019!44856361!1 X-Originating-IP: [148.87.113.117] X-StarScan-Version: 6.4.1; banners=-,-,- X-VirusChecked: Checked Received: (qmail 23180 invoked from network); 16 Sep 2011 17:27:00 -0000 Received: from rcsinet15.oracle.com (HELO rcsinet15.oracle.com) (148.87.113.117) by server-9.tower-27.messagelabs.com with DHE-RSA-AES256-SHA encrypted SMTP; 16 Sep 2011 17:27:00 -0000 Received: from acsinet21.oracle.com (acsinet21.oracle.com [141.146.126.237]) by rcsinet15.oracle.com (Switch-3.4.4/Switch-3.4.4) with ESMTP id p8GHRCKX006800 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Fri, 16 Sep 2011 17:27:14 GMT Received: from acsmt358.oracle.com (acsmt358.oracle.com [141.146.40.158]) by acsinet21.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id p8GHRBYD012895 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 16 Sep 2011 17:27:12 GMT Received: from abhmt112.oracle.com (abhmt112.oracle.com [141.146.116.64]) by acsmt358.oracle.com (8.12.11.20060308/8.12.11) with ESMTP id p8GHR6bg028040; Fri, 16 Sep 2011 12:27:06 -0500 Received: from oracle.com (/209.6.55.207) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Fri, 16 Sep 2011 10:27:06 -0700 Received: by oracle.com (Postfix, from userid 1000) id 12E851364; Fri, 16 Sep 2011 13:27:08 -0400 (EDT) Date: Fri, 16 Sep 2011 13:27:08 -0400 From: Konrad Rzeszutek Wilk To: Jan Beulich Subject: Re: [Xen-devel] locking in drivers/xen/xen-pciback/passthrough.c:__xen_pcibk_publish_pci_roots() Message-ID: <20110916172707.GA29389@phenom.oracle.com> References: <4E73746702000078000568A0@nat28.tlf.novell.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <4E73746702000078000568A0@nat28.tlf.novell.com> User-Agent: Mutt/1.5.21 (2010-09-15) X-Source-IP: acsinet21.oracle.com [141.146.126.237] X-Auth-Type: Internal IP X-CT-RefId: str=0001.0A090208.4E7386F2.0167:SCFMA922111,ss=1,re=-4.000,fgs=0 Cc: "xen-devel@lists.xensource.com" X-BeenThere: xen-devel@lists.xensource.com X-Mailman-Version: 2.1.5 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xensource.com Errors-To: xen-devel-bounces@lists.xensource.com On Fri, Sep 16, 2011 at 03:08:07PM +0100, Jan Beulich wrote: > Konrad, > > this function, before calling the passed in callback, drops the lock it > acquired at the beginning of the function, and re-acquires it after the > callback returned. It also uses list_for_each_entry_safe() in an > apparent attempt to deal with races here. However, I'm getting the > impression that this wouldn't really work (as the construct really isn't > meant for this case): If in the meantime the successor element got > removed from the list, the loop continuation would access data that > may already have got freed. > > I see two possible solutions: Either after re-acquiring the lock the > function checks whether the current object is sill on the list, starting > over if not found (xen_pcibk_publish_pci_root() makes sure a > device doesn't get published twice), or (if so possible) the lock gets > converted to a mutex (which should be safe to be held across the > callback invocation). > > What are your thoughts here? I think mutexs would work here best. We don't any of these operations in an IRQ interrupt context, so we are OK to be put to sleep. I think there is some room in improvement in some of the other Xen code in this regard - where we use spinlocks and could use a mechanism that is OK to go to sleep. _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel From xen-devel-bounces@lists.xensource.com Fri Sep 16 10:39:15 2011 Return-path: Envelope-to: www-data@lists.xensource.com Delivery-date: Fri, 16 Sep 2011 10:39:15 -0700 Received: from localhost ([127.0.0.1] helo=lists.colo.xensource.com) by lists.xensource.com with esmtp (Exim 4.43) id 1R4cNf-0003Xr-NS; Fri, 16 Sep 2011 10:39:15 -0700 Received: from mail27.messagelabs.com ([193.109.254.147]) by lists.xensource.com with esmtp (Exim 4.43) id 1R4cND-0003LL-4d; Fri, 16 Sep 2011 10:38:47 -0700 X-Env-Sender: konrad@oracle.com X-Msg-Ref: server-12.tower-27.messagelabs.com!1316194708!42760975!1 X-Originating-IP: [141.146.126.227] X-StarScan-Version: 6.4.1; banners=-,-,- X-VirusChecked: Checked Received: (qmail 9701 invoked from network); 16 Sep 2011 17:38:29 -0000 Received: from acsinet15.oracle.com (HELO acsinet15.oracle.com) (141.146.126.227) by server-12.tower-27.messagelabs.com with DHE-RSA-AES256-SHA encrypted SMTP; 16 Sep 2011 17:38:29 -0000 Received: from acsinet22.oracle.com (acsinet22.oracle.com [141.146.126.238]) by acsinet15.oracle.com (Switch-3.4.4/Switch-3.4.4) with ESMTP id p8GHcLM0013796 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Fri, 16 Sep 2011 17:38:23 GMT Received: from acsmt358.oracle.com (acsmt358.oracle.com [141.146.40.158]) by acsinet22.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id p8GHcJCR016006 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 16 Sep 2011 17:38:20 GMT Received: from abhmt119.oracle.com (abhmt119.oracle.com [141.146.116.71]) by acsmt358.oracle.com (8.12.11.20060308/8.12.11) with ESMTP id p8GHcDiT003768; Fri, 16 Sep 2011 12:38:14 -0500 Received: from oracle.com (/209.6.55.207) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Fri, 16 Sep 2011 10:38:13 -0700 Received: by oracle.com (Postfix, from userid 1000) id 9FCF41364; Fri, 16 Sep 2011 13:38:14 -0400 (EDT) Date: Fri, 16 Sep 2011 13:38:14 -0400 From: Konrad Rzeszutek Wilk To: jim burns Subject: Re: [Fedora-xen] [Xen-devel] Re: [Xen-users] Continuing BUG:-iness booting Fedora Rawhide 3.1.0-rc's (was Summary: Experiences setting up a debug serial port) Message-ID: <20110916173814.GB29389@phenom.oracle.com> References: <201107231426.56811.jim_burn@bellsouth.net> <20110915075358.GA4396@phenom.oracle.com> <2531823.kDgpVeQNv3@dell4550> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <2531823.kDgpVeQNv3@dell4550> User-Agent: Mutt/1.5.21 (2010-09-15) X-Source-IP: acsinet22.oracle.com [141.146.126.238] X-Auth-Type: Internal IP X-CT-RefId: str=0001.0A090206.4E73898F.0083:SCFMA922111,ss=1,re=-4.000,fgs=0 Cc: Ian Campbell , xen-devel@lists.xensource.com, M A Young , xen-users@lists.xensource.com, Fedora Xen List X-BeenThere: xen-devel@lists.xensource.com X-Mailman-Version: 2.1.5 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xensource.com Errors-To: xen-devel-bounces@lists.xensource.com > Testing out myoung's 3.1.0 was not as straight forward as I had hoped. It did > boot up without any BUG:s, but I did get the occasional Lock Order message. > Log snippet at the end of the post. It doesn't seem to be directly related to > starting guests. Yeah, those look like the network card (b44 driver) is at fault. > > The real problem comes in starting up guests. Performance is very bad. I knew > from working with rawhide 3.0.0 (long since replaced) that performance would > suffer - rawhide kernels are debug kernels: Right. They are horrendously slow. > > jimb@insp6400 09/16/11 10:16AM:~ > [511] > grep DEBUG /boot/config-3.1.0-0.rc6.git0.0.xendom0.fc17.x86_64|grep -v > 'is not set'|wc -l > 91 > jimb@insp6400 09/16/11 10:16AM:~ > [512] > grep DEBUG /boot/config-2.6.40.4-5.fc15.x86_64|grep -v 'is not set'|wc > -l > 54 > jimb@insp6400 09/16/11 10:18AM:~ > [513] > grep DEBUG /boot/config-3.0.1-3.fc16.x86_64|grep -v 'is not set'|wc -l > 90 > > Starting guests is much slower under myoung's 3.1.0 than under rawhide's 3.1.0 > or 3.0.{0,1}. A cifs backed pv domu took 6 min. for 'xm create' to exit, a debug kernel which will indeed be quite slow. > root@insp6400 09/16/11 12:09AM:~ > [544] > xl create Documents/winxp; brctl show; ps -A|grep qemu; netstat -tlp| > grep 59; renice -11 `pidof qemu-dm`; ps -A|grep vncv; ifconfig vif1.0 mtu > 9000 > Parsing config file Documents/winxp > xc: info: VIRTUAL MEMORY ARRANGEMENT: > Loader: 0000000000100000->000000000017b270 > TOTAL: 0000000000000000->000000003fc00000 > ENTRY ADDRESS: 00000000001015a0 > xc: error: Could not allocate memory for HVM guest. (16 = Device or resource > busy): Internal error > libxl: error: libxl_dom.c:284:libxl__build_hvm hvm building failed How much memory do you have used for your dom0/domU? > > and my serial debug log had several: > > (XEN) memory.c:133:d0 Could not allocate order=9 extent: id=1 memflags=0 (1 of > 4) > (XEN) memory.c:133:d0 Could not allocate order=9 extent: id=1 memflags=0 (0 of > 4) > (XEN) memory.c:133:d0 Could not allocate order=9 extent: id=1 memflags=0 (0 of > 4) > (XEN) memory.c:133:d0 Could not allocate order=9 extent: id=1 memflags=0 (0 of > 4) > (XEN) memory.c:133:d0 Could not allocate order=9 extent: id=1 memflags=0 (0 of > 4) > (XEN) memory.c:133:d0 Could not allocate order=9 extent: id=1 memflags=0 (0 of > 4) > (XEN) memory.c:133:d0 Could not allocate order=9 extent: id=1 memflags=0 (0 of > 4) > (XEN) memory.c:133:d0 Could not allocate order=9 extent: id=1 memflags=0 (0 of > 4) > (XEN) memory.c:133:d0 Could not allocate order=9 extent: id=1 memflags=0 (0 of > 4) > (XEN) memory.c:133:d0 Could not allocate order=9 extent: id=1 memflags=0 (0 of > 4) > (XEN) memory.c:133:d0 Could not allocate order=9 extent: id=1 memflags=0 (0 of > 4) > (XEN) memory.c:133:d0 Could not allocate order=9 extent: id=1 memflags=0 (0 of > 4) > (XEN) memory.c:133:d0 Could not allocate order=9 extent: id=1 memflags=0 (0 of > 4) > (XEN) memory.c:133:d0 Could not allocate order=9 extent: id=1 memflags=0 (0 of > 4) > (XEN) memory.c:133:d0 Could not allocate order=9 extent: id=1 memflags=0 (0 of > 4) > (XEN) memory.c:133:d0 Could not allocate order=9 extent: id=1 memflags=0 (0 of > 4) > (XEN) memory.c:133:d0 Could not allocate order=9 extent: id=1 memflags=0 (0 of > 4) > (XEN) memory.c:133:d0 Could not allocate order=9 extent: id=1 memflags=0 (0 of > 4) > (XEN) memory.c:133:d0 Could not allocate order=9 extent: id=1 memflags=0 (0 of > 4) > (XEN) memory.c:133:d0 Could not allocate order=9 extent: id=1 memflags=0 (0 of > 4) > (XEN) memory.c:133:d0 Could not allocate order=9 extent: id=1 memflags=0 (0 of > 4) > (XEN) memory.c:133:d0 Could not allocate order=9 extent: id=1 memflags=0 (0 of > 4) > (XEN) memory.c:133:d0 Could not allocate order=9 extent: id=1 memflags=0 (0 of > 4) > (XEN) memory.c:133:d0 Could not allocate order=9 extent: id=1 memflags=0 (0 of > 4) > (XEN) memory.c:133:d0 Could not allocate order=0 extent: id=1 memflags=0 (439 > of 2048) > > Then I remembered that I recently upped the memory allocation for my winxp > domu, from 512 to 768. This works fine under 2.6.40, the f15 non-debug > production kernel. None the less, I knocked the allocation back down to 512, > and my winxp domu did start up, getting to the qemu splash screen in about 2 - > 3 min., during part of which dom0 was unresponsive. However, I'm still getting > the '(XEN) memory.c' errors, and some frequent GPF errors (a few a min.) in my > serial debug log: > > (XEN) traps.c:2956: GPF (0060): ffff82c48015354a -> ffff82c480200131 > > Then, rawhide and gplpv don't get along. Specifically, the xennet receive side > driver stops working, and I have to fall back to qemu emulation. It takes > about an hour for the winxp desktop to finish initializing, with dom0 cpu load > on one cpu core at 72% - yum! But I'll just have to live with it - it's not > your problem. I'll leave it up for at least a day to see if any other messages > pop up. Keep in mind that the patch for the is going in 3.1, so it will show up in FC16 at some point. You can also rebuild your kernel without the debug options.. _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel From xen-devel-bounces@lists.xensource.com Fri Sep 16 12:06:52 2011 Return-path: <xen-devel-bounces@lists.xensource.com> Envelope-to: www-data@lists.xensource.com Delivery-date: Fri, 16 Sep 2011 12:06:52 -0700 Received: from localhost ([127.0.0.1] helo=lists.colo.xensource.com) by lists.xensource.com with esmtp (Exim 4.43) id 1R4dkS-00078A-OB; Fri, 16 Sep 2011 12:06:52 -0700 Received: from mail182.messagelabs.com ([85.158.139.83]) by lists.xensource.com with esmtp (Exim 4.43) id 1R4djq-0006vy-Lh for xen-devel@lists.xensource.com; Fri, 16 Sep 2011 12:06:15 -0700 X-Env-Sender: konrad@oracle.com X-Msg-Ref: server-12.tower-182.messagelabs.com!1316199970!18505208!1 X-Originating-IP: [141.146.126.227] X-StarScan-Version: 6.4.1; banners=-,-,- X-VirusChecked: Checked Received: (qmail 7567 invoked from network); 16 Sep 2011 19:06:11 -0000 Received: from acsinet15.oracle.com (HELO acsinet15.oracle.com) (141.146.126.227) by server-12.tower-182.messagelabs.com with DHE-RSA-AES256-SHA encrypted SMTP; 16 Sep 2011 19:06:11 -0000 Received: from acsinet22.oracle.com (acsinet22.oracle.com [141.146.126.238]) by acsinet15.oracle.com (Switch-3.4.4/Switch-3.4.4) with ESMTP id p8GJ66Zh020301 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Fri, 16 Sep 2011 19:06:07 GMT Received: from acsmt358.oracle.com (acsmt358.oracle.com [141.146.40.158]) by acsinet22.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id p8GJ65lG002745 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 16 Sep 2011 19:06:05 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 p8GJ5xsW001919; Fri, 16 Sep 2011 14:06:00 -0500 Received: from oracle.com (/209.6.55.207) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Fri, 16 Sep 2011 12:05:59 -0700 Received: by oracle.com (Postfix, from userid 1000) id 577A71364; Fri, 16 Sep 2011 15:06:01 -0400 (EDT) Date: Fri, 16 Sep 2011 15:06:01 -0400 From: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com> To: xen-devel@lists.xensource.com, JBeulich@suse.com Message-ID: <20110916190601.GA31796@phenom.oracle.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.5.21 (2010-09-15) X-Source-IP: acsinet22.oracle.com [141.146.126.238] X-Auth-Type: Internal IP X-CT-RefId: str=0001.0A090205.4E739E20.00BA:SCFMA922111,ss=1,re=-4.000,fgs=0 Cc: linux-kernel@vger.kernel.org Subject: [Xen-devel] [PATCH] xen/pciback: Use mutexes when working with Xenbus state transitions. X-BeenThere: xen-devel@lists.xensource.com X-Mailman-Version: 2.1.5 Precedence: list List-Id: Xen developer discussion <xen-devel.lists.xensource.com> List-Unsubscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe> List-Post: <mailto:xen-devel@lists.xensource.com> List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help> List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=subscribe> Sender: xen-devel-bounces@lists.xensource.com Errors-To: xen-devel-bounces@lists.xensource.com The caller that orchestrates the state changes is xenwatch_thread and it takes a mutex. In our processing of Xenbus states we can take the luxery of going to sleep on a mutex, so lets do that and also fix this bug: BUG: sleeping function called from invalid context at /linux/kernel/mutex.c:271 in_atomic(): 1, irqs_disabled(): 0, pid: 32, name: xenwatch 2 locks held by xenwatch/32: #0: (xenwatch_mutex){......}, at: [<ffffffff813856ab>] xenwatch_thread+0x4b/0x180 #1: (&(&pdev->dev_lock)->rlock){......}, at: [<ffffffff8138f05b>] xen_pcibk_disconnect+0x1b/0x80 Pid: 32, comm: xenwatch Not tainted 3.1.0-rc6-00015-g3ce340d #2 Call Trace: [<ffffffff810892b2>] __might_sleep+0x102/0x130 [<ffffffff8163b90f>] mutex_lock_nested+0x2f/0x50 [<ffffffff81382c1c>] unbind_from_irq+0x2c/0x1b0 [<ffffffff8110da66>] ? free_irq+0x56/0xb0 [<ffffffff81382dbc>] unbind_from_irqhandler+0x1c/0x30 [<ffffffff8138f06b>] xen_pcibk_disconnect+0x2b/0x80 [<ffffffff81390348>] xen_pcibk_frontend_changed+0xe8/0x140 [<ffffffff81387ac2>] xenbus_otherend_changed+0xd2/0x150 [<ffffffff810895c1>] ? get_parent_ip+0x11/0x50 [<ffffffff81387de0>] frontend_changed+0x10/0x20 [<ffffffff81385712>] xenwatch_thread+0xb2/0x180 Signed-off-by: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com> --- drivers/xen/xen-pciback/pciback.h | 2 +- drivers/xen/xen-pciback/xenbus.c | 16 +++++----------- 2 files changed, 6 insertions(+), 12 deletions(-) diff --git a/drivers/xen/xen-pciback/pciback.h b/drivers/xen/xen-pciback/pciback.h index a0e131a..c3af628 100644 --- a/drivers/xen/xen-pciback/pciback.h +++ b/drivers/xen/xen-pciback/pciback.h @@ -27,7 +27,7 @@ struct pci_dev_entry { struct xen_pcibk_device { void *pci_dev_data; - spinlock_t dev_lock; + struct mutex dev_lock; struct xenbus_device *xdev; struct xenbus_watch be_watch; u8 be_watching; diff --git a/drivers/xen/xen-pciback/xenbus.c b/drivers/xen/xen-pciback/xenbus.c index 978d2c6..c057d67 100644 --- a/drivers/xen/xen-pciback/xenbus.c +++ b/drivers/xen/xen-pciback/xenbus.c @@ -44,7 +44,7 @@ static struct xen_pcibk_device *alloc_pdev(struct xenbus_device *xdev) pdev->xdev = xdev; dev_set_drvdata(&xdev->dev, pdev); - spin_lock_init(&pdev->dev_lock); + mutex_init(&pdev->dev_lock); pdev->sh_info = NULL; pdev->evtchn_irq = INVALID_EVTCHN_IRQ; @@ -62,14 +62,13 @@ out: static void xen_pcibk_disconnect(struct xen_pcibk_device *pdev) { - spin_lock(&pdev->dev_lock); + mutex_lock(&pdev->dev_lock); /* Ensure the guest can't trigger our handler before removing devices */ if (pdev->evtchn_irq != INVALID_EVTCHN_IRQ) { unbind_from_irqhandler(pdev->evtchn_irq, pdev); pdev->evtchn_irq = INVALID_EVTCHN_IRQ; } - spin_unlock(&pdev->dev_lock); /* If the driver domain started an op, make sure we complete it * before releasing the shared memory */ @@ -77,13 +76,11 @@ static void xen_pcibk_disconnect(struct xen_pcibk_device *pdev) /* Note, the workqueue does not use spinlocks at all.*/ flush_workqueue(xen_pcibk_wq); - spin_lock(&pdev->dev_lock); if (pdev->sh_info != NULL) { xenbus_unmap_ring_vfree(pdev->xdev, pdev->sh_info); pdev->sh_info = NULL; } - spin_unlock(&pdev->dev_lock); - + mutex_unlock(&pdev->dev_lock); } static void free_pdev(struct xen_pcibk_device *pdev) @@ -120,9 +117,8 @@ static int xen_pcibk_do_attach(struct xen_pcibk_device *pdev, int gnt_ref, goto out; } - spin_lock(&pdev->dev_lock); + mutex_lock(&pdev->dev_lock); pdev->sh_info = vaddr; - spin_unlock(&pdev->dev_lock); err = bind_interdomain_evtchn_to_irqhandler( pdev->xdev->otherend_id, remote_evtchn, xen_pcibk_handle_event, @@ -132,14 +128,12 @@ static int xen_pcibk_do_attach(struct xen_pcibk_device *pdev, int gnt_ref, "Error binding event channel to IRQ"); goto out; } - - spin_lock(&pdev->dev_lock); pdev->evtchn_irq = err; - spin_unlock(&pdev->dev_lock); err = 0; dev_dbg(&pdev->xdev->dev, "Attached!\n"); out: + mutex_unlock(&pdev->dev_lock); return err; } -- 1.7.4.1 _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel From xen-devel-bounces@lists.xensource.com Fri Sep 16 12:07:52 2011 Return-path: <xen-devel-bounces@lists.xensource.com> Envelope-to: www-data@lists.xensource.com Delivery-date: Fri, 16 Sep 2011 12:07:52 -0700 Received: from localhost ([127.0.0.1] helo=lists.colo.xensource.com) by lists.xensource.com with esmtp (Exim 4.43) id 1R4dlQ-0007VN-Iv; Fri, 16 Sep 2011 12:07:52 -0700 Received: from mail174.messagelabs.com ([85.158.138.51]) by lists.xensource.com with esmtp (Exim 4.43) id 1R4dk3-0006xu-1b for xen-devel@lists.xensource.com; Fri, 16 Sep 2011 12:06:27 -0700 X-Env-Sender: fujita.tomonori@lab.ntt.co.jp X-Msg-Ref: server-14.tower-174.messagelabs.com!1316199980!31722228!1 X-Originating-IP: [192.16.179.4] X-StarScan-Version: 6.4.1; banners=-,-,- X-VirusChecked: Checked Received: (qmail 12368 invoked from network); 16 Sep 2011 19:06:23 -0000 Received: from sh.osrg.net (HELO sh.osrg.net) (192.16.179.4) by server-14.tower-174.messagelabs.com with DHE-RSA-AES256-SHA encrypted SMTP; 16 Sep 2011 19:06:23 -0000 Received: from localhost (rose.osrg.net [10.76.0.1]) by sh.osrg.net (8.14.3/8.14.3/OSRG-NET) with ESMTP id p8GJ5w5F002870; Sat, 17 Sep 2011 04:05:58 +0900 Date: Sat, 17 Sep 2011 04:05:58 +0900 To: konrad.wilk@oracle.com From: FUJITA Tomonori <fujita.tomonori@lab.ntt.co.jp> In-Reply-To: <1315923170-25568-5-git-send-email-konrad.wilk@oracle.com> References: <1315923170-25568-1-git-send-email-konrad.wilk@oracle.com> <1315923170-25568-5-git-send-email-konrad.wilk@oracle.com> Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-Id: <20110917035611F.fujita.tomonori@lab.ntt.co.jp> Lines: 21 X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-3.0 (sh.osrg.net [192.16.179.4]); Sat, 17 Sep 2011 04:06:00 +0900 (JST) X-Virus-Scanned: clamav-milter 0.97.2 at sh X-Virus-Status: Clean Cc: thellstrom@vmware.com, xen-devel@lists.xensource.com, thomas@shipmail.org, airlied@linux.ie, pq@iki.fi, linux-kernel@vger.kernel.org, dri-devel@lists.freedesktop.org, fujita.tomonori@lab.ntt.co.jp, bskeggs@redhat.com, alexdeucher@gmail.com, airlied@redhat.com, j.glisse@redhat.com Subject: [Xen-devel] Re: [PATCH 4/7] swiotlb: Expose swiotlb_nr_tlb function to modules as swiotlb_enabled X-BeenThere: xen-devel@lists.xensource.com X-Mailman-Version: 2.1.5 Precedence: list List-Id: Xen developer discussion <xen-devel.lists.xensource.com> List-Unsubscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe> List-Post: <mailto:xen-devel@lists.xensource.com> List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help> List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=subscribe> Sender: xen-devel-bounces@lists.xensource.com Errors-To: xen-devel-bounces@lists.xensource.com On Tue, 13 Sep 2011 10:12:47 -0400 Konrad Rzeszutek Wilk <konrad.wilk@oracle.com> wrote: > As a mechanism to detect whether SWIOTLB is enabled or not. > And as such, we might as well wrap it within an 'swiotlb_enabled()' > function that will call the swiotlb_nr_tlb. > > We also fix the spelling - it was swioltb instead of > swiotlb. > > CC: FUJITA Tomonori <fujita.tomonori@lab.ntt.co.jp> > Signed-off-by: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com> > --- > drivers/xen/swiotlb-xen.c | 2 +- > include/linux/swiotlb.h | 7 ++++++- > lib/swiotlb.c | 5 +++-- > 3 files changed, 10 insertions(+), 4 deletions(-) Can we just use swiotlb_nr_tbl() rather than inventing a new function that only wraps swiotlb_nr_tbl()? _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel From xen-devel-bounces@lists.xensource.com Fri Sep 16 12:16:38 2011 Return-path: <xen-devel-bounces@lists.xensource.com> Envelope-to: www-data@lists.xensource.com Delivery-date: Fri, 16 Sep 2011 12:16:38 -0700 Received: from localhost ([127.0.0.1] helo=lists.colo.xensource.com) by lists.xensource.com with esmtp (Exim 4.43) id 1R4dtu-0007yj-6P; Fri, 16 Sep 2011 12:16:38 -0700 Received: from mail174.messagelabs.com ([85.158.138.51]) by lists.xensource.com with esmtp (Exim 4.43) id 1R4dtI-0007mC-VC for xen-devel@lists.xensource.com; Fri, 16 Sep 2011 12:16:01 -0700 X-Env-Sender: konrad@oracle.com X-Msg-Ref: server-9.tower-174.messagelabs.com!1316200556!25686885!1 X-Originating-IP: [141.146.126.227] X-StarScan-Version: 6.4.1; banners=-,-,- X-VirusChecked: Checked Received: (qmail 14864 invoked from network); 16 Sep 2011 19:15:57 -0000 Received: from acsinet15.oracle.com (HELO acsinet15.oracle.com) (141.146.126.227) by server-9.tower-174.messagelabs.com with DHE-RSA-AES256-SHA encrypted SMTP; 16 Sep 2011 19:15:57 -0000 Received: from acsinet21.oracle.com (acsinet21.oracle.com [141.146.126.237]) by acsinet15.oracle.com (Switch-3.4.4/Switch-3.4.4) with ESMTP id p8GJFKKq002846 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Fri, 16 Sep 2011 19:15:22 GMT Received: from acsmt357.oracle.com (acsmt357.oracle.com [141.146.40.157]) by acsinet21.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id p8GJFJxl006552 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 16 Sep 2011 19:15:19 GMT Received: from abhmt111.oracle.com (abhmt111.oracle.com [141.146.116.63]) by acsmt357.oracle.com (8.12.11.20060308/8.12.11) with ESMTP id p8GJFDNf030118; Fri, 16 Sep 2011 14:15:13 -0500 Received: from oracle.com (/209.6.55.207) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Fri, 16 Sep 2011 12:15:13 -0700 Received: by oracle.com (Postfix, from userid 1000) id 2008C1364; Fri, 16 Sep 2011 15:15:15 -0400 (EDT) Date: Fri, 16 Sep 2011 15:15:15 -0400 From: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com> To: Jan Beulich <JBeulich@suse.com> Subject: Re: [Xen-devel] Re: [PATCH 3/3] xen-blkfront: If no barrier or flush is supported, use invalid operation. Message-ID: <20110916191514.GA31818@phenom.oracle.com> References: <1315593060-20031-1-git-send-email-konrad.wilk@oracle.com> <1315593060-20031-3-git-send-email-konrad.wilk@oracle.com> <4E6DD8750200007800055ADA@nat28.tlf.novell.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <4E6DD8750200007800055ADA@nat28.tlf.novell.com> User-Agent: Mutt/1.5.21 (2010-09-15) X-Source-IP: acsinet21.oracle.com [141.146.126.237] X-Auth-Type: Internal IP X-CT-RefId: str=0001.0A090207.4E73A04A.00D3:SCFMA922111,ss=1,re=-4.000,fgs=0 Cc: axboe@kernel.dk, linux-kernel@vger.kernel.org, xen-devel@lists.xensource.com, jeremy.fitzhardinge@citrix.com, stable@kernel.org X-BeenThere: xen-devel@lists.xensource.com X-Mailman-Version: 2.1.5 Precedence: list List-Id: Xen developer discussion <xen-devel.lists.xensource.com> List-Unsubscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe> List-Post: <mailto:xen-devel@lists.xensource.com> List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help> List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=subscribe> Sender: xen-devel-bounces@lists.xensource.com Errors-To: xen-devel-bounces@lists.xensource.com On Mon, Sep 12, 2011 at 09:01:25AM +0100, Jan Beulich wrote: > >>> On 09.09.11 at 20:31, Konrad Rzeszutek Wilk <konrad.wilk@oracle.com> wrote: > > By default we would set the info->flush_op=0, and zero maps > > to BLKIF_OP_READ request code. So if the backend did not support > > either barrier ('feature-barrier') or flush ('feature-flush-cache') > > we would end up using that opcode for the flush/barrier request, meaning > > we actually do a READ request. Fortunatly for us, __generic_make_request > > checks q->flush_flags and realizes that we don't do FLUSH and removes > > the REQ_FLUSH | REQ_FUA so we never end up issuing a READ request > > for a flush request. However, other third party implementations of > > __make_request might not be so smart, so lets fix this up. > > Wouldn't it be better to simply have blkif_queue_request() fail in that > case (and then it doesn't matter whether flush_op is set to 0 or -1)? > Not the least because older (forward-port) backends stall the incoming > queue and are possibly verbose for invalid requests seen. So like this: diff --git a/drivers/block/xen-blkfront.c b/drivers/block/xen-blkfront.c index 468bfec..e9d301c 100644 --- a/drivers/block/xen-blkfront.c +++ b/drivers/block/xen-blkfront.c @@ -380,7 +380,9 @@ static void do_blkif_request(struct request_queue *rq) blk_start_request(req); - if (req->cmd_type != REQ_TYPE_FS) { + if ((req->cmd_type != REQ_TYPE_FS) || + ((req->cmd_flags & (REQ_FLUSH | REQ_FUA)) && + !info->flush_op)) { __blk_end_request_all(req, -EIO); continue; } _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel From xen-users-bounces@lists.xensource.com Fri Sep 16 13:09:06 2011 Return-path: <xen-users-bounces@lists.xensource.com> Envelope-to: www-data@lists.xensource.com Delivery-date: Fri, 16 Sep 2011 13:09:06 -0700 Received: from localhost ([127.0.0.1] helo=lists.colo.xensource.com) by lists.xensource.com with esmtp (Exim 4.43) id 1R4eif-0002dT-8c; Fri, 16 Sep 2011 13:09:05 -0700 Received: from mail27.messagelabs.com ([193.109.254.147]) by lists.xensource.com with smtp (Exim 4.43) id 1R4egL-0002Hy-Cq for xen-users@lists.xensource.com; Fri, 16 Sep 2011 13:06:49 -0700 X-Env-Sender: jim_burn@bellsouth.net X-Msg-Ref: server-14.tower-27.messagelabs.com!1316203583!36472421!1 X-Originating-IP: [66.94.237.93] X-StarScan-Version: 6.4.1; banners=-,-,- X-VirusChecked: Checked Received: (qmail 20984 invoked from network); 16 Sep 2011 20:06:24 -0000 Received: from nm28.access.bullet.mail.mud.yahoo.com (HELO nm28.access.bullet.mail.mud.yahoo.com) (66.94.237.93) by server-14.tower-27.messagelabs.com with SMTP; 16 Sep 2011 20:06:24 -0000 Received: from [66.94.237.196] by nm28.access.bullet.mail.mud.yahoo.com with NNFMP; 16 Sep 2011 20:06:37 -0000 Received: from [66.94.237.121] by tm7.access.bullet.mail.mud.yahoo.com with NNFMP; 16 Sep 2011 20:06:37 -0000 Received: from [127.0.0.1] by omp1026.access.mail.mud.yahoo.com with NNFMP; 16 Sep 2011 20:06:37 -0000 X-Yahoo-Newman-Id: 117312.89202.bm@omp1026.access.mail.mud.yahoo.com Received: (qmail 2579 invoked from network); 16 Sep 2011 20:06:36 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=bellsouth.net; s=s1024; t=1316203596; bh=fShsyYbiAuO/Ia/kqilrTKqyZWmD/3hcPRd1ZJowQzw=; h=X-Yahoo-Newman-Property:X-YMail-OSG:X-Yahoo-SMTP:Received:From:To:Cc:Subject:Date:Message-ID:User-Agent:In-Reply-To:References:MIME-Version:Content-Transfer-Encoding:Content-Type; b=tc051WazMiWxhays6PUKgF+sCqu57h2H65L/0tmKWdcOkwvKLBrFHvN2esjuZRXJ7BSEgBJx3M5JDW1xXiDjNp/nPQP54apwPi1eiYsMVivn118W6XiZhsKv6n5WL6lUmWUOWBeRiuPxqrW6nS4CRw+8buggG/nhyij75zj/a70= X-Yahoo-Newman-Property: ymail-3 X-YMail-OSG: pbTpgjkVM1lrHf8H.qWiSraBzWLILU_LlolSMCeMPhWyWxa loY67KZdMCmtW3js4gCkta4bA9J8fec.KGQvAIbXWykHNGVoQ6D97ThzfKUr yUWhgfjQJxv6hePdyM2M0G4xMA4FMFQqiUiMcEoDKopt8XVFJtDDjQ4G8Ohi ApxvKeXS5r.DtGp8qad5RlHfU2MXz9qnCwzBrCJXkfA5cwdgBvdAXWWXpYTV 9gbfpkrcuzV598DxuBOuywdgiQ96OyfafPPCtwX.E62RY4ddCWt.Y5n31W.X PEIr1iObT76e7yxsmCN2fOTv5CKnuyDfEnmQ6nQhdU2Af_sjJLkOsMpZpK90 EcddkfRh9rsjzuMDcG2I01UaEnaYjmwj.yythAzT_2OHrn594NHJCAG0s5Z7 xM.ElYTOqrIS_mUaA.t1t5.v2opJixs5ENoCp2M4JCfXxJb.GeQ-- X-Yahoo-SMTP: g0AhWW2swBA2djJKuhuwxPlPqLrHlDrycdPnfR9kZNrpKCA- Received: from dell4550.localnet (jim_burn@74.190.198.215 with plain) by smtp110.sbc.mail.bf1.yahoo.com with SMTP; 16 Sep 2011 13:06:36 -0700 PDT From: jim burns <jim_burn@bellsouth.net> To: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com> Subject: Re: [Fedora-xen] [Xen-devel] Re: [Xen-users] Continuing BUG:-iness booting Fedora Rawhide 3.1.0-rc's (was Summary: Experiences setting up a debug serial port) Date: Fri, 16 Sep 2011 16:06:30 -0400 Message-ID: <1777265.Pkue3yJNHT@dell4550> User-Agent: KMail/4.7.1 (Linux/2.6.37.6-0.7-default; KDE/4.7.1; i686; ; ) In-Reply-To: <20110916173814.GB29389@phenom.oracle.com> References: <201107231426.56811.jim_burn@bellsouth.net> <2531823.kDgpVeQNv3@dell4550> <20110916173814.GB29389@phenom.oracle.com> MIME-Version: 1.0 Content-Transfer-Encoding: 7Bit Content-Type: text/plain; charset="us-ascii" Cc: xen-devel@lists.xensource.com, Fedora Xen List <fedora-xen@redhat.com>, Pasi =?ISO-8859-1?Q?K=E4rkk=E4inen?= <pasik@iki.fi>, Ian Campbell <Ian.Campbell@eu.citrix.com>, M A Young <m.a.young@durham.ac.uk>, xen-users@lists.xensource.com X-BeenThere: xen-users@lists.xensource.com X-Mailman-Version: 2.1.5 Precedence: list List-Id: Xen user discussion <xen-users.lists.xensource.com> List-Unsubscribe: <http://lists.xensource.com/mailman/listinfo/xen-users>, <mailto:xen-users-request@lists.xensource.com?subject=unsubscribe> List-Post: <mailto:xen-users@lists.xensource.com> List-Help: <mailto:xen-users-request@lists.xensource.com?subject=help> List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-users>, <mailto:xen-users-request@lists.xensource.com?subject=subscribe> Sender: xen-users-bounces@lists.xensource.com Errors-To: xen-users-bounces@lists.xensource.com On Fri September 16 2011, 1:38:14 PM, Konrad Rzeszutek Wilk wrote: > > Testing out myoung's 3.1.0 was not as straight forward as I had hoped. > > It did boot up without any BUG:s, but I did get the occasional Lock > > Order message. Log snippet at the end of the post. It doesn't seem to > > be directly related to starting guests. > > Yeah, those look like the network card (b44 driver) is at fault. Yeah, I see that now, plus references to nf_conntrack and bonding. These components don't present problems under 2.6.40, so I'll just assume that this is a timing problem introduced by the debug kernel. > > The real problem comes in starting up guests. Performance is very bad. I > > knew from working with rawhide 3.0.0 (long since replaced) that > > performance would suffer - rawhide kernels are debug kernels: > > Right. They are horrendously slow. > > > jimb@insp6400 09/16/11 10:16AM:~ > > [511] > grep DEBUG > > /boot/config-3.1.0-0.rc6.git0.0.xendom0.fc17.x86_64|grep -v 'is not > > set'|wc -l > > 91 > > jimb@insp6400 09/16/11 10:16AM:~ > > [512] > grep DEBUG /boot/config-2.6.40.4-5.fc15.x86_64|grep -v 'is not > > set'|wc -l > > 54 > > jimb@insp6400 09/16/11 10:18AM:~ > > [513] > grep DEBUG /boot/config-3.0.1-3.fc16.x86_64|grep -v 'is not > > set'|wc -l 90 > > > > Starting guests is much slower under myoung's 3.1.0 than under rawhide's > > 3.1.0 or 3.0.{0,1}. A cifs backed pv domu took 6 min. for 'xm create' > > to exit, > > a debug kernel which will indeed be quite slow. But the point I was emphasizing was that myoung's 3.1.0 is slower than even rawhide's 3.1.0. The '(XEN) memory.c' errors have stopped, but I'm still getting a few '(XEN) traps.c:2956: GPF' errors a min. with a winxp domu up, also something that did not happen under previous rawhide kernels. (I assume GPF=General Protection Fault, which would really slow things down to trap.) > > root@insp6400 09/16/11 12:09AM:~ > > [544] > xl create Documents/winxp; brctl show; ps -A|grep qemu; netstat > > -tlp| grep 59; renice -11 `pidof qemu-dm`; ps -A|grep vncv; ifconfig > > vif1.0 mtu 9000 > > Parsing config file Documents/winxp > > > > xc: info: VIRTUAL MEMORY ARRANGEMENT: > > Loader: 0000000000100000->000000000017b270 > > TOTAL: 0000000000000000->000000003fc00000 > > ENTRY ADDRESS: 00000000001015a0 > > > > xc: error: Could not allocate memory for HVM guest. (16 = Device or > > resource busy): Internal error > > libxl: error: libxl_dom.c:284:libxl__build_hvm hvm building failed > > How much memory do you have used for your dom0/domU? Dom0 has 2 GB, which is enough to run one domu at a time (which usually has 512 MB). (One of these days I'll spring for a multi GB, IOMMU machine.) > > and my serial debug log had several: > > > > (XEN) memory.c:133:d0 Could not allocate order=9 extent: id=1 memflags=0 > > (1 of 4) > > [snip] > > Then I remembered that I recently upped the memory allocation for my > > winxp domu, from 512 to 768. This works fine under 2.6.40, the f15 > > non-debug production kernel. None the less, I knocked the allocation > > back down to 512, and my winxp domu did start up, getting to the qemu > > splash screen in about 2 - 3 min., during part of which dom0 was > > unresponsive. However, I'm still getting the '(XEN) memory.c' errors, > > and some frequent GPF errors (a few a min.) in my serial debug log: > > > > (XEN) traps.c:2956: GPF (0060): ffff82c48015354a -> ffff82c480200131 > > > > Then, rawhide and gplpv don't get along. Specifically, the xennet > > receive side driver stops working, and I have to fall back to qemu > > emulation. It takes about an hour for the winxp desktop to finish > > initializing, with dom0 cpu load on one cpu core at 72% - yum! But I'll > > just have to live with it - it's not your problem. I'll leave it up for > > at least a day to see if any other messages pop up. > > Keep in mind that the patch for the <title> is going in 3.1, so it will show > up in FC16 at some point. The patch for who? What's <title>? Plus I have no interest in updating to an alpha release. I'll wait till the final release. (And I REALLY have no interest in upgrading to grub2 :-) ) > You can also rebuild your kernel without the debug options.. Yeah - what's the fastest way to do that? 2.6.40 has 54 active DEBUG options, 3.1.0 has 91. Short of deactivating 37 DEBUG options, is there a master DEBUG option that will do the trick? Not that it's important. 2.6.40 has what I need for now. I can do without pci passthrough for awhile. Just curious about the fastest way to turn off the extra 37 DEBUG options, or at least the most time consuming culprits. OK, if your confident that these problems will go away in a production kernel, especially the GPF error, I can wait. If you don't need anything else, I'll bring down the system, and retreat to 2.6.40 in a couple of hours. Thanx for you attention. _______________________________________________ Xen-users mailing list Xen-users@lists.xensource.com http://lists.xensource.com/xen-users From xen-users-bounces@lists.xensource.com Fri Sep 16 13:33:01 2011 Return-path: <xen-users-bounces@lists.xensource.com> Envelope-to: www-data@lists.xensource.com Delivery-date: Fri, 16 Sep 2011 13:33:01 -0700 Received: from localhost ([127.0.0.1] helo=lists.colo.xensource.com) by lists.xensource.com with esmtp (Exim 4.43) id 1R4f5p-00041q-JX; Fri, 16 Sep 2011 13:33:01 -0700 Received: from mail174.messagelabs.com ([85.158.138.51]) by lists.xensource.com with smtp (Exim 4.43) id 1R4KZc-00010B-St; Thu, 15 Sep 2011 15:38:25 -0700 X-Env-Sender: awilliam@redhat.com X-Msg-Ref: server-3.tower-174.messagelabs.com!1316126300!25533077!1 X-Originating-IP: [209.132.183.28] X-StarScan-Version: 6.4.1; banners=-,-,- X-VirusChecked: Checked Received: (qmail 16938 invoked from network); 15 Sep 2011 22:38:21 -0000 Received: from mx1.redhat.com (HELO mx1.redhat.com) (209.132.183.28) by server-3.tower-174.messagelabs.com with SMTP; 15 Sep 2011 22:38:21 -0000 Received: from int-mx09.intmail.prod.int.phx2.redhat.com (int-mx09.intmail.prod.int.phx2.redhat.com [10.5.11.22]) by mx1.redhat.com (8.14.4/8.14.4) with ESMTP id p8FMcBQm018726 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Thu, 15 Sep 2011 18:38:11 -0400 Received: from mail.happyassassin.net (ovpn-113-59.phx2.redhat.com [10.3.113.59]) by int-mx09.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP id p8FMcAQX010371 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 15 Sep 2011 18:38:10 -0400 From: Adam Williamson <awilliam@redhat.com> To: Development discussions related to Fedora <devel@lists.fedoraproject.org> Date: Thu, 15 Sep 2011 15:38:09 -0700 In-Reply-To: <20110915151041.GA4453@imp.local> References: <CAN0j7xqm5BatDtXaurYZWvb-6ibG2V10aQ5Qck+9P7DjciWLwQ@mail.gmail.com> <20110914112552.GP12984@reaktio.net> <20110914142522.GA16956@phenom.oracle.com> <20110914144539.GR12984@reaktio.net> <20110915151041.GA4453@imp.local> Organization: Red Hat Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: 7bit Message-ID: <1316126290.5689.3.camel@adam> Mime-Version: 1.0 X-Scanned-By: MIMEDefang 2.68 on 10.5.11.22 X-Mailman-Approved-At: Fri, 16 Sep 2011 13:31:29 -0700 Cc: xen@lists.fedoraproject.org, xen-devel@lists.xensource.com, Rzeszutek Wilk <konrad.wilk@oracle.com>, Pasi =?ISO-8859-1?Q?K=E4rkk=E4inen?= <pasik@iki.fi>, lars.kurth@xen.org, Konrad, virt@lists.fedoraproject.org, xen-users@lists.xensource.com Subject: [Xen-users] Re: Virtualization Test Day for F16 and Xen X-BeenThere: xen-users@lists.xensource.com X-Mailman-Version: 2.1.5 Precedence: list List-Id: Xen user discussion <xen-users.lists.xensource.com> List-Unsubscribe: <http://lists.xensource.com/mailman/listinfo/xen-users>, <mailto:xen-users-request@lists.xensource.com?subject=unsubscribe> List-Post: <mailto:xen-users@lists.xensource.com> List-Help: <mailto:xen-users-request@lists.xensource.com?subject=help> List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-users>, <mailto:xen-users-request@lists.xensource.com?subject=subscribe> Sender: xen-users-bounces@lists.xensource.com Errors-To: xen-users-bounces@lists.xensource.com On Thu, 2011-09-15 at 10:10 -0500, W. Michael Petullo wrote: > >> There are known bugs in FC15/FC16 that have been filled some time ago that > >> folks will sadly run into: 728775, 658387 and 668063 > >> > >> Fortunatly the bugs have patches attached and the files to be modified are shell scripts. > > > Yep, links here: > > > > https://bugzilla.redhat.com/show_bug.cgi?id=728775 > > The Fedora update system reports this is fixed in grub2-1.99-6.fc16. > > > https://bugzilla.redhat.com/show_bug.cgi?id=658387 > > Peter Jones submitted a new grubby package yesterday. This seems to fix > bug #658387 (i.e., new-kernel-pkg creates a Dom0-style grub.cfg entry > if /etc/sysconfig/kernel contains "HYPERVISOR=/boot/xen.gz"). > > I have not yet tested this on Fedora 16. However, I did test on Fedora > 15. In this case, bug #668063 is still in effect. That is, grubby creates > most of a GRUB record, but the "module initramfs-..." entry is missing. > > Has anyone yet tested this new grubby package on Fedora 16 yet? Does > using GRUB 2 makes #668063 irrelevant? > > > https://bugzilla.redhat.com/show_bug.cgi?id=668063 > > I just added some more description to this bug. So, there's a meta-point here: we currently 'require' Beta releases to boot as guests on Xen hosts: "The release must boot successfully as a virtual guest in a situation where the virtual host is running a supported Xen implementation" I really don't have much knowledge of Xen and haven't followed this discussion closely, but do any currently-known bugs prevent this? If so, please flag them up so they can be considered as Beta blockers...thanks! -- Adam Williamson Fedora QA Community Monkey IRC: adamw | Twitter: AdamW_Fedora | identi.ca: adamwfedora http://www.happyassassin.net _______________________________________________ Xen-users mailing list Xen-users@lists.xensource.com http://lists.xensource.com/xen-users From xen-users-bounces@lists.xensource.com Fri Sep 16 13:35:16 2011 Return-path: <xen-users-bounces@lists.xensource.com> Envelope-to: www-data@lists.xensource.com Delivery-date: Fri, 16 Sep 2011 13:35:16 -0700 Received: from localhost ([127.0.0.1] helo=lists.colo.xensource.com) by lists.xensource.com with esmtp (Exim 4.43) id 1R4f80-0004jb-9L; Fri, 16 Sep 2011 13:35:16 -0700 Received: from mail182.messagelabs.com ([85.158.139.83]) by lists.xensource.com with esmtp (Exim 4.43) id 1R4UVo-0003oR-6z; Fri, 16 Sep 2011 02:15:12 -0700 X-Env-Sender: myroslav@quintagroup.com X-Msg-Ref: server-3.tower-182.messagelabs.com!1316164503!15771276!1 X-Originating-IP: [209.85.218.43] X-StarScan-Version: 6.4.1; banners=-,-,- X-VirusChecked: Checked Received: (qmail 10453 invoked from network); 16 Sep 2011 09:15:04 -0000 Received: from mail-yi0-f43.google.com (HELO mail-yi0-f43.google.com) (209.85.218.43) by server-3.tower-182.messagelabs.com with RC4-SHA encrypted SMTP; 16 Sep 2011 09:15:04 -0000 Received: by yic24 with SMTP id 24so2956263yic.30 for <multiple recipients>; Fri, 16 Sep 2011 02:15:03 -0700 (PDT) Received: by 10.236.177.73 with SMTP id c49mr12900721yhm.89.1316164503161; Fri, 16 Sep 2011 02:15:03 -0700 (PDT) MIME-Version: 1.0 Received: by 10.236.208.169 with HTTP; Fri, 16 Sep 2011 02:14:23 -0700 (PDT) In-Reply-To: <1316126290.5689.3.camel@adam> References: <CAN0j7xqm5BatDtXaurYZWvb-6ibG2V10aQ5Qck+9P7DjciWLwQ@mail.gmail.com> <20110914112552.GP12984@reaktio.net> <20110914142522.GA16956@phenom.oracle.com> <20110914144539.GR12984@reaktio.net> <20110915151041.GA4453@imp.local> <1316126290.5689.3.camel@adam> From: Myroslav Opyr <myroslav@quintagroup.com> Date: Fri, 16 Sep 2011 12:14:23 +0300 Message-ID: <CAN0j7xouJewZVdLwo5oadiSUghxFwErKeZbknzSRKKoNbg419A@mail.gmail.com> To: Development discussions related to Fedora <devel@lists.fedoraproject.org> X-Mailman-Approved-At: Fri, 16 Sep 2011 13:31:29 -0700 Cc: xen@lists.fedoraproject.org, xen-devel@lists.xensource.com, Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>, lars.kurth@xen.org, virt@lists.fedoraproject.org, xen-users@lists.xensource.com Subject: [Xen-users] Re: Virtualization Test Day for F16 and Xen X-BeenThere: xen-users@lists.xensource.com X-Mailman-Version: 2.1.5 Precedence: list List-Id: Xen user discussion <xen-users.lists.xensource.com> List-Unsubscribe: <http://lists.xensource.com/mailman/listinfo/xen-users>, <mailto:xen-users-request@lists.xensource.com?subject=unsubscribe> List-Post: <mailto:xen-users@lists.xensource.com> List-Help: <mailto:xen-users-request@lists.xensource.com?subject=help> List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-users>, <mailto:xen-users-request@lists.xensource.com?subject=subscribe> Content-Type: multipart/mixed; boundary="===============1067142483==" Sender: xen-users-bounces@lists.xensource.com Errors-To: xen-users-bounces@lists.xensource.com --===============1067142483== Content-Type: multipart/alternative; boundary=20cf3040e36ead4c2804ad0b6d1d --20cf3040e36ead4c2804ad0b6d1d Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Hi, What Xen implementation is considered "supported" for FC16 DomU? I'm asking because on "Xen implementation" we were testing yesterday FC16 DomU installation failed compared to FC15 DomU success on the very same Dom0. Ar= e failures like we've encountered candidates for bugreports? Is there a place (wikipage, bugzilla keyword, etc.) to collect Fedora 16 Xe= n issues? Regards, m. On Fri, Sep 16, 2011 at 01:38, Adam Williamson <awilliam@redhat.com> wrote: > On Thu, 2011-09-15 at 10:10 -0500, W. Michael Petullo wrote: > > >> There are known bugs in FC15/FC16 that have been filled some time ag= o > that > > >> folks will sadly run into: 728775, 658387 and 668063 > > >> > > >> Fortunatly the bugs have patches attached and the files to be modifi= ed > are shell scripts. > > > > > Yep, links here: > > > > > > https://bugzilla.redhat.com/show_bug.cgi?id=3D728775 > > > > The Fedora update system reports this is fixed in grub2-1.99-6.fc16. > > > > > https://bugzilla.redhat.com/show_bug.cgi?id=3D658387 > > > > Peter Jones submitted a new grubby package yesterday. This seems to fix > > bug #658387 (i.e., new-kernel-pkg creates a Dom0-style grub.cfg entry > > if /etc/sysconfig/kernel contains "HYPERVISOR=3D/boot/xen.gz"). > > > > I have not yet tested this on Fedora 16. However, I did test on Fedora > > 15. In this case, bug #668063 is still in effect. That is, grubby creat= es > > most of a GRUB record, but the "module initramfs-..." entry is missing. > > > > Has anyone yet tested this new grubby package on Fedora 16 yet? Does > > using GRUB 2 makes #668063 irrelevant? > > > > > https://bugzilla.redhat.com/show_bug.cgi?id=3D668063 > > > > I just added some more description to this bug. > > So, there's a meta-point here: we currently 'require' Beta releases to > boot as guests on Xen hosts: > > "The release must boot successfully as a virtual guest in a situation > where the virtual host is running a supported Xen implementation" > > I really don't have much knowledge of Xen and haven't followed this > discussion closely, but do any currently-known bugs prevent this? If so, > please flag them up so they can be considered as Beta blockers...thanks! > -- > Adam Williamson > Fedora QA Community Monkey > IRC: adamw | Twitter: AdamW_Fedora | identi.ca: adamwfedora > http://www.happyassassin.net > > -- > devel mailing list > devel@lists.fedoraproject.org > https://admin.fedoraproject.org/mailman/listinfo/devel > --=20 ...........................................................................= .......................... Myroslav Opyr =E2=96=AA CTO =E2=96=AA Quintagroup =E2=96=AA ht= tp://quintagroup.com =CB=99=CB=99=CB=99=CB=99=CB=99=CB=99=CB=99=CB=99=CB=99=CB=99=CB=99=CB=99=CB= =99=CB=99=CB=99=CB=99=CB=99=CB=99=CB=99=CB=99=CB=99=CB=99=CB=99=CB=99=CB=99= =CB=99=CB=99=CB=99=CB=99=CB=99=CB=99=CB=99=CB=99=CB=99=CB=99=CB=99=CB=99=CB= =99=CB=99=CB=99=CB=99=CB=99=CB=99=CB=99=CB=99=CB=99=CB=99=CB=99=CB=99=CB=99= =CB=99=CB=99=CB=99=CB=99=CB=99=CB=99=CB=99=CB=99=CB=99=CB=99=CB=99=CB=99=CB= =99=CB=99=CB=99=CB=99=CB=99=CB=99=CB=99=CB=99=CB=99=CB=99=CB=99=CB=99=CB=99= =CB=99=CB=99=CB=99=CB=99=CB=99=CB=99=CB=99=CB=99=CB=99=CB=99=CB=99=CB=99=CB= =99=CB=99=CB=99=CB=99=CB=99=CB=99=CB=99=CB=99=CB=99=CB=99=CB=99=CB=99=CB=99= =CB=99 --20cf3040e36ead4c2804ad0b6d1d Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Hi,<div><br></div><div>What Xen implementation is considered "supporte= d" for FC16 DomU? I'm asking because on "Xen implementation&q= uot; we were testing yesterday FC16 DomU installation failed compared to FC= 15 DomU success on the very same Dom0. Are failures like we've encounte= red candidates for bugreports?</div> <div><br></div><div>Is there a place (wikipage, bugzilla keyword, etc.) to = collect Fedora 16 Xen issues?<br><br>Regards,</div><div><br></div><div>m.<b= r><br><div class=3D"gmail_quote">On Fri, Sep 16, 2011 at 01:38, Adam Willia= mson <span dir=3D"ltr"><<a href=3D"mailto:awilliam@redhat.com" target=3D= "_blank">awilliam@redhat.com</a>></span> wrote:<br> <blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1p= x #ccc solid;padding-left:1ex"><div>On Thu, 2011-09-15 at 10:10 -0500, W. M= ichael Petullo wrote:<br> > >> There are known bugs in FC15/FC16 that have been filled some = time ago that<br> > >> folks will sadly run into: 728775, 658387 =C2=A0and 668063<br= > > >><br> > >> Fortunatly the bugs have patches attached and the files to be= modified are shell scripts.<br> ><br> > > Yep, links here:<br> > ><br> > > <a href=3D"https://bugzilla.redhat.com/show_bug.cgi?id=3D728775" = target=3D"_blank">https://bugzilla.redhat.com/show_bug.cgi?id=3D728775</a><= br> ><br> > The Fedora update system reports this is fixed in grub2-1.99-6.fc16.<b= r> ><br> > > <a href=3D"https://bugzilla.redhat.com/show_bug.cgi?id=3D658387" = target=3D"_blank">https://bugzilla.redhat.com/show_bug.cgi?id=3D658387</a><= br> ><br> > Peter Jones submitted a new grubby package yesterday. This seems to fi= x<br> > bug #658387 (i.e., new-kernel-pkg creates a Dom0-style grub.cfg entry<= br> > if /etc/sysconfig/kernel contains "HYPERVISOR=3D/boot/xen.gz"= ;).<br> ><br> > I have not yet tested this on Fedora 16. However, I did test on Fedora= <br> > 15. In this case, bug #668063 is still in effect. That is, grubby crea= tes<br> > most of a GRUB record, but the "module initramfs-..." entry = is missing.<br> ><br> > Has anyone yet tested this new grubby package on Fedora 16 yet? Does<b= r> > using GRUB 2 makes #668063 irrelevant?<br> ><br> > > <a href=3D"https://bugzilla.redhat.com/show_bug.cgi?id=3D668063" = target=3D"_blank">https://bugzilla.redhat.com/show_bug.cgi?id=3D668063</a><= br> ><br> > I just added some more description to this bug.<br> <br> </div>So, there's a meta-point here: we currently 'require' Bet= a releases to<br> boot as guests on Xen hosts:<br> <br> "The release must boot successfully as a virtual guest in a situation<= br> where the virtual host is running a supported Xen implementation"<br> <br> I really don't have much knowledge of Xen and haven't followed this= <br> discussion closely, but do any currently-known bugs prevent this? If so,<br= > please flag them up so they can be considered as Beta blockers...thanks!<br= > <font color=3D"#888888">--<br> Adam Williamson<br> Fedora QA Community Monkey<br> IRC: adamw | Twitter: AdamW_Fedora | <a href=3D"http://identi.ca" target=3D= "_blank">identi.ca</a>: adamwfedora<br> <a href=3D"http://www.happyassassin.net" target=3D"_blank">http://www.happy= assassin.net</a><br> </font><div><div></div><div><br> --<br> devel mailing list<br> <a href=3D"mailto:devel@lists.fedoraproject.org" target=3D"_blank">devel@li= sts.fedoraproject.org</a><br> <a href=3D"https://admin.fedoraproject.org/mailman/listinfo/devel" target= =3D"_blank">https://admin.fedoraproject.org/mailman/listinfo/devel</a><br> </div></div></blockquote></div><br><br clear=3D"all"><div><br></div>-- <br>= ...........................................................................= ..........................<br>Myroslav Opyr=C2=A0=C2=A0 =E2=96=AA=C2=A0=C2= =A0 CTO=C2=A0=C2=A0 =E2=96=AA=C2=A0 =C2=A0 Quintagroup=C2=A0=C2=A0 =E2=96= =AA=C2=A0=C2=A0 <a href=3D"http://quintagroup.com" target=3D"_blank">http:/= /quintagroup.com</a><br> =CB=99=CB=99=CB=99=CB=99=CB=99=CB=99=CB=99=CB=99=CB=99=CB=99=CB=99=CB=99=CB= =99=CB=99=CB=99=CB=99=CB=99=CB=99=CB=99=CB=99=CB=99=CB=99=CB=99=CB=99=CB=99= =CB=99=CB=99=CB=99=CB=99=CB=99=CB=99=CB=99=CB=99=CB=99=CB=99=CB=99=CB=99=CB= =99=CB=99=CB=99=CB=99=CB=99=CB=99=CB=99=CB=99=CB=99=CB=99=CB=99=CB=99=CB=99= =CB=99=CB=99=CB=99=CB=99=CB=99=CB=99=CB=99=CB=99=CB=99=CB=99=CB=99=CB=99=CB= =99=CB=99=CB=99=CB=99=CB=99=CB=99=CB=99=CB=99=CB=99=CB=99=CB=99=CB=99=CB=99= =CB=99=CB=99=CB=99=CB=99=CB=99=CB=99=CB=99=CB=99=CB=99=CB=99=CB=99=CB=99=CB= =99=CB=99=CB=99=CB=99=CB=99=CB=99=CB=99=CB=99=CB=99=CB=99=CB=99=CB=99=CB=99= =CB=99<br> </div> --20cf3040e36ead4c2804ad0b6d1d-- --===============1067142483== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Xen-users mailing list Xen-users@lists.xensource.com http://lists.xensource.com/xen-users --===============1067142483==-- From xen-devel-bounces@lists.xensource.com Fri Sep 16 13:37:26 2011 Return-path: <xen-devel-bounces@lists.xensource.com> Envelope-to: www-data@lists.xensource.com Delivery-date: Fri, 16 Sep 2011 13:37:26 -0700 Received: from localhost ([127.0.0.1] helo=lists.colo.xensource.com) by lists.xensource.com with esmtp (Exim 4.43) id 1R4fA5-0005j2-TC; Fri, 16 Sep 2011 13:37:25 -0700 Received: from mail27.messagelabs.com ([193.109.254.147]) by lists.xensource.com with esmtp (Exim 4.43) id 1R4Py0-0001hJ-FU for xen-devel@lists.xensource.com; Thu, 15 Sep 2011 21:23:56 -0700 X-Env-Sender: wnlo.zwt@gmail.com X-Msg-Ref: server-2.tower-27.messagelabs.com!1316147008!55158239!1 X-Originating-IP: [209.85.212.50] X-StarScan-Version: 6.4.1; banners=-,-,- X-VirusChecked: Checked Received: (qmail 5031 invoked from network); 16 Sep 2011 04:23:29 -0000 Received: from mail-vw0-f50.google.com (HELO mail-vw0-f50.google.com) (209.85.212.50) by server-2.tower-27.messagelabs.com with RC4-SHA encrypted SMTP; 16 Sep 2011 04:23:29 -0000 Received: by vws14 with SMTP id 14so5974265vws.23 for <xen-devel@lists.xensource.com>; Thu, 15 Sep 2011 21:23:52 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:date:message-id:subject:from:to:content-type; bh=JVeTEeC+aFZ80tdIWxyMlu5HDtHxhCTZJW2DbddlFx0=; b=aiGqb/JMoZ9IeSVWE9Gu7Kn7P34WLGPX1GjetRf+MPKC7rtF/HcL6y/49xjtbgNdgB ffP0oDZ5+aP/KT8vkRmmr+duho15AoYIF3/JksC4ddOpRl8yAsiF0Wo6vL98ILnSre/9 /fl2UfaZ8fB9gZV2bkHIq/jPg9UznSvuL5D2A= MIME-Version: 1.0 Received: by 10.52.94.207 with SMTP id de15mr683617vdb.293.1316147032051; Thu, 15 Sep 2011 21:23:52 -0700 (PDT) Received: by 10.52.181.195 with HTTP; Thu, 15 Sep 2011 21:23:52 -0700 (PDT) Date: Fri, 16 Sep 2011 12:23:52 +0800 Message-ID: <CAJZuLffYkppqbrnypW-FeABSneA4Nw2Ot7CXH64HFzJH_Q9oxQ@mail.gmail.com> From: wentao zhang <wnlo.zwt@gmail.com> To: xen-devel@lists.xensource.com X-Mailman-Approved-At: Fri, 16 Sep 2011 13:32:27 -0700 Subject: [Xen-devel] about Centos 5.4 + xen 3.4.2 X-BeenThere: xen-devel@lists.xensource.com X-Mailman-Version: 2.1.5 Precedence: list List-Id: Xen developer discussion <xen-devel.lists.xensource.com> List-Unsubscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe> List-Post: <mailto:xen-devel@lists.xensource.com> List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help> List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=subscribe> Content-Type: multipart/mixed; boundary="===============0794270737==" Sender: xen-devel-bounces@lists.xensource.com Errors-To: xen-devel-bounces@lists.xensource.com --===============0794270737== Content-Type: multipart/alternative; boundary=20cf3071cd7c5150ca04ad075c3c --20cf3071cd7c5150ca04ad075c3c Content-Type: text/plain; charset=ISO-8859-1 Hi, *I could use xm list* Name ID Mem VCPUs State Time(s) Domain-0 0 7868 8 r----- 30.1 dom1-1 1 200 1 -b---- 15.2 *but when I used xm vcpu-list* [root@localhost ~]# xm vcpu-list Name ID VCPU CPU State Time(s) CPU Affinity Unexpected error: xml.parsers.expat.ExpatError Please report to xen-devel@lists.xensource.com Traceback (most recent call last): File "/usr/sbin/xm", line 7, in ? main.main(sys.argv) File "usr/lib64/python2.4/site-packages/xen/xm/main.py", line 2997, in main File "usr/lib64/python2.4/site-packages/xen/xm/main.py", line 3021, in _run_cmd File "usr/lib64/python2.4/site-packages/xen/xm/main.py", line 1152, in xm_vcpu_list File "usr/lib64/python2.4/site-packages/xen/xm/main.py", line 1127, in format_cpumap File "/usr/lib64/python2.4/xmlrpclib.py", line 1096, in __call__ return self.__send(self.__name, args) File "usr/lib64/python2.4/site-packages/xen/util/xmlrpcclient.py", line 118, in __request File "/usr/lib64/python2.4/xmlrpclib.py", line 1383, in __request verbose=self.__verbose File "usr/lib64/python2.4/site-packages/xen/util/xmlrpcclient.py", line 55, in request File "/usr/lib64/python2.4/xmlrpclib.py", line 1147, in request return self._parse_response(h.getfile(), sock) File "/usr/lib64/python2.4/xmlrpclib.py", line 1281, in _parse_response p.feed(response) File "/usr/lib64/python2.4/xmlrpclib.py", line 527, in feed self._parser.Parse(data, 0) xml.parsers.expat.ExpatError: not well-formed (invalid token): line 104, column 19 *This was all right before I recompility xen with make xen && make install-xen* *What should I do ?* --20cf3071cd7c5150ca04ad075c3c Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable <span class=3D"Apple-style-span" style=3D"font-family: arial, sans-serif; f= ont-size: 13px; background-color: rgb(255, 255, 255); ">Hi,=A0<div><b>I cou= ld use=A0=A0xm list</b><div>Name =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 = =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0ID =A0 Mem VCPUs =A0 =A0 =A0State = =A0 Time(s)</div> <div>Domain-0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 = =A0 =A0 =A0 0 =A07868 =A0 =A0 8 =A0 =A0 r----- =A0 =A0 30.1</div><div>dom1-= 1 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 = =A0 1 =A0 200 =A0 =A0 1 =A0 =A0 -b---- =A0 =A0 15.2</div><div><br></div><di= v><b>but when I used xm vcpu-list</b></div> <div><br></div><div><div>[root@localhost ~]# xm vcpu-list</div><div>Name = =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0ID =A0VCPU = =A0 CPU State =A0 Time(s) CPU Affinity</div><div>Unexpected error: xml.pars= ers.expat.ExpatError</div><div><br></div> <div>Please report to=A0<a href=3D"mailto:xen-devel@lists.xensource.com" ta= rget=3D"_blank" style=3D"color: rgb(0, 0, 204); ">xen-devel@lists.xensource= .com</a></div><div>Traceback (most recent call last):</div><div>=A0 File &q= uot;/usr/sbin/xm", line 7, in ?</div> <div>=A0 =A0 main.main(sys.argv)</div><div>=A0 File "usr/lib64/python2= .4/site-packages/xen/xm/main.py", line 2997, in main</div><div>=A0 Fil= e "usr/lib64/python2.4/site-packages/xen/xm/main.py", line 3021, = in _run_cmd</div> <div>=A0 File "usr/lib64/python2.4/site-packages/xen/xm/main.py",= line 1152, in xm_vcpu_list</div><div>=A0 File "usr/lib64/python2.4/si= te-packages/xen/xm/main.py", line 1127, in format_cpumap</div><div>=A0= File "/usr/lib64/python2.4/xmlrpclib.py", line 1096, in __call__= </div> <div>=A0 =A0 return self.__send(self.__name, args)</div><div>=A0 File "= ;usr/lib64/python2.4/site-packages/xen/util/xmlrpcclient.py", line 118= , in __request</div><div>=A0 File "/usr/lib64/python2.4/xmlrpclib.py&q= uot;, line 1383, in __request</div> <div>=A0 =A0 verbose=3Dself.__verbose</div><div>=A0 File "usr/lib64/py= thon2.4/site-packages/xen/util/xmlrpcclient.py", line 55, in request</= div><div>=A0 File "/usr/lib64/python2.4/xmlrpclib.py", line 1147,= in request</div> <div>=A0 =A0 return self._parse_response(h.getfile(), sock)</div><div>=A0 F= ile "/usr/lib64/python2.4/xmlrpclib.py", line 1281, in _parse_res= ponse</div><div>=A0 =A0 p.feed(response)</div><div>=A0 File "/usr/lib6= 4/python2.4/xmlrpclib.py", line 527, in feed</div> <div>=A0 =A0 self._parser.Parse(data, 0)</div><div>xml.parsers.expat.ExpatE= rror: not well-formed (invalid token): line 104, column 19</div></div><div>= <br></div><div><b>This was all right before I recompility xen with make xen= && make install-xen</b></div> <div><b>What should I do ?</b></div></div></span> --20cf3071cd7c5150ca04ad075c3c-- --===============0794270737== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel --===============0794270737==-- From xen-devel-bounces@lists.xensource.com Fri Sep 16 13:55:12 2011 Return-path: <xen-devel-bounces@lists.xensource.com> Envelope-to: www-data@lists.xensource.com Delivery-date: Fri, 16 Sep 2011 13:55:12 -0700 Received: from localhost ([127.0.0.1] helo=lists.colo.xensource.com) by lists.xensource.com with esmtp (Exim 4.43) id 1R4fRH-0007F1-To; Fri, 16 Sep 2011 13:55:11 -0700 Received: from mail216.messagelabs.com ([85.158.143.99]) by lists.xensource.com with esmtp (Exim 4.43) id 1R4fQt-00072b-1R for xen-devel@lists.xensource.com; Fri, 16 Sep 2011 13:54:47 -0700 X-Env-Sender: konrad@oracle.com X-Msg-Ref: server-13.tower-216.messagelabs.com!1316206482!18598617!1 X-Originating-IP: [141.146.126.227] X-StarScan-Version: 6.4.1; banners=-,-,- X-VirusChecked: Checked Received: (qmail 8678 invoked from network); 16 Sep 2011 20:54:43 -0000 Received: from acsinet15.oracle.com (HELO acsinet15.oracle.com) (141.146.126.227) by server-13.tower-216.messagelabs.com with DHE-RSA-AES256-SHA encrypted SMTP; 16 Sep 2011 20:54:43 -0000 Received: from acsinet21.oracle.com (acsinet21.oracle.com [141.146.126.237]) by acsinet15.oracle.com (Switch-3.4.4/Switch-3.4.4) with ESMTP id p8GKsHim007792 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Fri, 16 Sep 2011 20:54:19 GMT Received: from acsmt358.oracle.com (acsmt358.oracle.com [141.146.40.158]) by acsinet21.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id p8GKsGcm020393 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 16 Sep 2011 20:54:16 GMT Received: from abhmt120.oracle.com (abhmt120.oracle.com [141.146.116.72]) by acsmt358.oracle.com (8.12.11.20060308/8.12.11) with ESMTP id p8GKs98n009164; Fri, 16 Sep 2011 15:54:10 -0500 Received: from oracle.com (/209.6.55.207) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Fri, 16 Sep 2011 13:54:09 -0700 Received: by oracle.com (Postfix, from userid 1000) id E1CBE1364; Fri, 16 Sep 2011 16:54:10 -0400 (EDT) Date: Fri, 16 Sep 2011 16:54:10 -0400 From: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com> To: FUJITA Tomonori <fujita.tomonori@lab.ntt.co.jp> Subject: Re: [Xen-devel] Re: [PATCH 4/7] swiotlb: Expose swiotlb_nr_tlb function to modules as swiotlb_enabled Message-ID: <20110916205410.GA16370@phenom.oracle.com> References: <1315923170-25568-1-git-send-email-konrad.wilk@oracle.com> <1315923170-25568-5-git-send-email-konrad.wilk@oracle.com> <20110917035611F.fujita.tomonori@lab.ntt.co.jp> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20110917035611F.fujita.tomonori@lab.ntt.co.jp> User-Agent: Mutt/1.5.21 (2010-09-15) X-Source-IP: acsinet21.oracle.com [141.146.126.237] X-Auth-Type: Internal IP X-CT-RefId: str=0001.0A02020A.4E73B77B.0156:SCFMA922111,ss=1,re=-4.000,fgs=0 Cc: thellstrom@vmware.com, xen-devel@lists.xensource.com, thomas@shipmail.org, airlied@linux.ie, pq@iki.fi, linux-kernel@vger.kernel.org, dri-devel@lists.freedesktop.org, bskeggs@redhat.com, alexdeucher@gmail.com, airlied@redhat.com, j.glisse@redhat.com X-BeenThere: xen-devel@lists.xensource.com X-Mailman-Version: 2.1.5 Precedence: list List-Id: Xen developer discussion <xen-devel.lists.xensource.com> List-Unsubscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe> List-Post: <mailto:xen-devel@lists.xensource.com> List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help> List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=subscribe> Sender: xen-devel-bounces@lists.xensource.com Errors-To: xen-devel-bounces@lists.xensource.com On Sat, Sep 17, 2011 at 04:05:58AM +0900, FUJITA Tomonori wrote: > On Tue, 13 Sep 2011 10:12:47 -0400 > Konrad Rzeszutek Wilk <konrad.wilk@oracle.com> wrote: > > > As a mechanism to detect whether SWIOTLB is enabled or not. > > And as such, we might as well wrap it within an 'swiotlb_enabled()' > > function that will call the swiotlb_nr_tlb. > > > > We also fix the spelling - it was swioltb instead of > > swiotlb. > > > > CC: FUJITA Tomonori <fujita.tomonori@lab.ntt.co.jp> > > Signed-off-by: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com> > > --- > > drivers/xen/swiotlb-xen.c | 2 +- > > include/linux/swiotlb.h | 7 ++++++- > > lib/swiotlb.c | 5 +++-- > > 3 files changed, 10 insertions(+), 4 deletions(-) > > Can we just use swiotlb_nr_tbl() rather than inventing a new function > that only wraps swiotlb_nr_tbl()? Absolutly. Will do that. _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel From xen-devel-bounces@lists.xensource.com Fri Sep 16 14:16:39 2011 Return-path: <xen-devel-bounces@lists.xensource.com> Envelope-to: www-data@lists.xensource.com Delivery-date: Fri, 16 Sep 2011 14:16:39 -0700 Received: from localhost ([127.0.0.1] helo=lists.colo.xensource.com) by lists.xensource.com with esmtp (Exim 4.43) id 1R4fm2-0000F0-15; Fri, 16 Sep 2011 14:16:38 -0700 Received: from mail216.messagelabs.com ([85.158.143.99]) by lists.xensource.com with smtp (Exim 4.43) id 1R4fkQ-0008TJ-3r for xen-devel@lists.xensource.com; Fri, 16 Sep 2011 14:15:00 -0700 X-Env-Sender: dgdegra@tycho.nsa.gov X-Msg-Ref: server-15.tower-216.messagelabs.com!1316207694!18103881!1 X-Originating-IP: [63.239.65.40] X-StarScan-Version: 6.4.1; banners=-,-,- X-VirusChecked: Checked Received: (qmail 25132 invoked from network); 16 Sep 2011 21:14:54 -0000 Received: from msux-gh1-uea02.nsa.gov (HELO msux-gh1-uea02.nsa.gov) (63.239.65.40) by server-15.tower-216.messagelabs.com with SMTP; 16 Sep 2011 21:14:54 -0000 Received: from tarius.tycho.ncsc.mil (localhost [127.0.0.1]) by msux-gh1-uea02.nsa.gov (8.12.10/8.12.10) with ESMTP id p8GLEpj3019389; Fri, 16 Sep 2011 21:14:51 GMT Received: from moss-nexus.epoch.ncsc.mil (moss-nexus [144.51.25.48]) by tarius.tycho.ncsc.mil (8.13.1/8.13.1) with ESMTP id p8GLEojf015927; Fri, 16 Sep 2011 17:14:51 -0400 From: Daniel De Graaf <dgdegra@tycho.nsa.gov> To: konrad.wilk@oracle.com Date: Fri, 16 Sep 2011 17:14:42 -0400 Message-Id: <1316207684-19860-1-git-send-email-dgdegra@tycho.nsa.gov> X-Mailer: git-send-email 1.7.6 Cc: xen-devel@lists.xensource.com, Ian.Jackson@eu.citrix.com Subject: [Xen-devel] [PATCH 0/2] Add reference counting to grant notify ioctls X-BeenThere: xen-devel@lists.xensource.com X-Mailman-Version: 2.1.5 Precedence: list List-Id: Xen developer discussion <xen-devel.lists.xensource.com> List-Unsubscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe> List-Post: <mailto:xen-devel@lists.xensource.com> List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help> List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=subscribe> Sender: xen-devel-bounces@lists.xensource.com Errors-To: xen-devel-bounces@lists.xensource.com The current notify ioctls assume that an event channel will not be closed prior to the page being unmapped. If the mappings are associated with an open file descriptor and the application crashes, the notification behavior depends on the close ordering of the file descriptors. To avoid this, event channels now have a reference count that is used by the grant notify ioctls to postpone the close operation until the notification is fired. [PATCH 1/2] xen/event: Add reference counting to event channel [PATCH 2/2] xen/gnt{dev,alloc}: reserve event channels for notify _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel From xen-devel-bounces@lists.xensource.com Fri Sep 16 14:17:46 2011 Return-path: <xen-devel-bounces@lists.xensource.com> Envelope-to: www-data@lists.xensource.com Delivery-date: Fri, 16 Sep 2011 14:17:46 -0700 Received: from localhost ([127.0.0.1] helo=lists.colo.xensource.com) by lists.xensource.com with esmtp (Exim 4.43) id 1R4fn7-0000cj-Ua; Fri, 16 Sep 2011 14:17:46 -0700 Received: from mail174.messagelabs.com ([85.158.138.51]) by lists.xensource.com with smtp (Exim 4.43) id 1R4fkQ-0008TI-4Q for xen-devel@lists.xensource.com; Fri, 16 Sep 2011 14:15:00 -0700 X-Env-Sender: dgdegra@tycho.nsa.gov X-Msg-Ref: server-7.tower-174.messagelabs.com!1316207694!31701131!1 X-Originating-IP: [63.239.65.39] X-StarScan-Version: 6.4.1; banners=-,-,- X-VirusChecked: Checked Received: (qmail 19876 invoked from network); 16 Sep 2011 21:14:54 -0000 Received: from msux-gh1-uea01.nsa.gov (HELO msux-gh1-uea01.nsa.gov) (63.239.65.39) by server-7.tower-174.messagelabs.com with SMTP; 16 Sep 2011 21:14:54 -0000 Received: from tarius.tycho.ncsc.mil (localhost [127.0.0.1]) by msux-gh1-uea01.nsa.gov (8.12.10/8.12.10) with ESMTP id p8GLEpbC015960; Fri, 16 Sep 2011 21:14:51 GMT Received: from moss-nexus.epoch.ncsc.mil (moss-nexus [144.51.25.48]) by tarius.tycho.ncsc.mil (8.13.1/8.13.1) with ESMTP id p8GLEojh015927; Fri, 16 Sep 2011 17:14:51 -0400 From: Daniel De Graaf <dgdegra@tycho.nsa.gov> To: konrad.wilk@oracle.com Date: Fri, 16 Sep 2011 17:14:44 -0400 Message-Id: <1316207684-19860-3-git-send-email-dgdegra@tycho.nsa.gov> X-Mailer: git-send-email 1.7.6 In-Reply-To: <1316207684-19860-1-git-send-email-dgdegra@tycho.nsa.gov> References: <1316207684-19860-1-git-send-email-dgdegra@tycho.nsa.gov> Cc: Daniel De Graaf <dgdegra@tycho.nsa.gov>, xen-devel@lists.xensource.com, Ian.Jackson@eu.citrix.com Subject: [Xen-devel] [PATCH 2/2] xen/gnt{dev, alloc}: reserve event channels for notify X-BeenThere: xen-devel@lists.xensource.com X-Mailman-Version: 2.1.5 Precedence: list List-Id: Xen developer discussion <xen-devel.lists.xensource.com> List-Unsubscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe> List-Post: <mailto:xen-devel@lists.xensource.com> List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help> List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=subscribe> Sender: xen-devel-bounces@lists.xensource.com Errors-To: xen-devel-bounces@lists.xensource.com When using the unmap notify ioctl, the event channel used for notification needs to be reserved to avoid it being deallocated prior to sending the notification. Signed-off-by: Daniel De Graaf <dgdegra@tycho.nsa.gov> --- drivers/xen/gntalloc.c | 14 +++++++++++++- drivers/xen/gntdev.c | 11 +++++++++++ 2 files changed, 24 insertions(+), 1 deletions(-) diff --git a/drivers/xen/gntalloc.c b/drivers/xen/gntalloc.c index f6832f4..cff862b 100644 --- a/drivers/xen/gntalloc.c +++ b/drivers/xen/gntalloc.c @@ -178,8 +178,10 @@ static void __del_gref(struct gntalloc_gref *gref) tmp[gref->notify.pgoff] = 0; kunmap(gref->page); } - if (gref->notify.flags & UNMAP_NOTIFY_SEND_EVENT) + if (gref->notify.flags & UNMAP_NOTIFY_SEND_EVENT) { notify_remote_via_evtchn(gref->notify.event); + put_evtchn_reservation(gref->notify.event); + } gref->notify.flags = 0; @@ -396,6 +398,16 @@ static long gntalloc_ioctl_unmap_notify(struct gntalloc_file_private_data *priv, goto unlock_out; } + if (op.action & UNMAP_NOTIFY_SEND_EVENT) { + if (get_evtchn_reservation(op.event_channel_port)) { + rc = -EINVAL; + goto unlock_out; + } + } + + if (gref->notify.flags & UNMAP_NOTIFY_SEND_EVENT) + put_evtchn_reservation(gref->notify.event); + gref->notify.flags = op.action; gref->notify.pgoff = pgoff; gref->notify.event = op.event_channel_port; diff --git a/drivers/xen/gntdev.c b/drivers/xen/gntdev.c index f914b26..8de393c 100644 --- a/drivers/xen/gntdev.c +++ b/drivers/xen/gntdev.c @@ -190,6 +190,7 @@ static void gntdev_put_map(struct grant_map *map) if (map->notify.flags & UNMAP_NOTIFY_SEND_EVENT) { notify_remote_via_evtchn(map->notify.event); + put_evtchn_reservation(map->notify.event); } if (map->pages) { @@ -596,6 +597,16 @@ static long gntdev_ioctl_notify(struct gntdev_priv *priv, void __user *u) goto unlock_out; } + if (op.action & UNMAP_NOTIFY_SEND_EVENT) { + if (get_evtchn_reservation(op.event_channel_port)) { + rc = -EINVAL; + goto unlock_out; + } + } + + if (map->notify.flags & UNMAP_NOTIFY_SEND_EVENT) + put_evtchn_reservation(map->notify.event); + map->notify.flags = op.action; map->notify.addr = op.index - (map->index << PAGE_SHIFT); map->notify.event = op.event_channel_port; -- 1.7.6 _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel From xen-devel-bounces@lists.xensource.com Fri Sep 16 14:18:34 2011 Return-path: <xen-devel-bounces@lists.xensource.com> Envelope-to: www-data@lists.xensource.com Delivery-date: Fri, 16 Sep 2011 14:18:34 -0700 Received: from localhost ([127.0.0.1] helo=lists.colo.xensource.com) by lists.xensource.com with esmtp (Exim 4.43) id 1R4fnu-0000zb-JX; Fri, 16 Sep 2011 14:18:34 -0700 Received: from mail21.messagelabs.com ([85.158.143.35]) by lists.xensource.com with smtp (Exim 4.43) id 1R4fkP-0008TH-Pn for xen-devel@lists.xensource.com; Fri, 16 Sep 2011 14:15:01 -0700 X-Env-Sender: dgdegra@tycho.nsa.gov X-Msg-Ref: server-7.tower-21.messagelabs.com!1316207664!55166819!1 X-Originating-IP: [63.239.65.39] X-StarScan-Version: 6.4.1; banners=-,-,- X-VirusChecked: Checked Received: (qmail 29185 invoked from network); 16 Sep 2011 21:14:24 -0000 Received: from msux-gh1-uea01.nsa.gov (HELO msux-gh1-uea01.nsa.gov) (63.239.65.39) by server-7.tower-21.messagelabs.com with SMTP; 16 Sep 2011 21:14:24 -0000 Received: from tarius.tycho.ncsc.mil (localhost [127.0.0.1]) by msux-gh1-uea01.nsa.gov (8.12.10/8.12.10) with ESMTP id p8GLEpbC015959; Fri, 16 Sep 2011 21:14:51 GMT Received: from moss-nexus.epoch.ncsc.mil (moss-nexus [144.51.25.48]) by tarius.tycho.ncsc.mil (8.13.1/8.13.1) with ESMTP id p8GLEojg015927; Fri, 16 Sep 2011 17:14:51 -0400 From: Daniel De Graaf <dgdegra@tycho.nsa.gov> To: konrad.wilk@oracle.com Date: Fri, 16 Sep 2011 17:14:43 -0400 Message-Id: <1316207684-19860-2-git-send-email-dgdegra@tycho.nsa.gov> X-Mailer: git-send-email 1.7.6 In-Reply-To: <1316207684-19860-1-git-send-email-dgdegra@tycho.nsa.gov> References: <1316207684-19860-1-git-send-email-dgdegra@tycho.nsa.gov> Cc: Daniel De Graaf <dgdegra@tycho.nsa.gov>, xen-devel@lists.xensource.com, Ian.Jackson@eu.citrix.com Subject: [Xen-devel] [PATCH 1/2] xen/event: Add reference counting to event channel X-BeenThere: xen-devel@lists.xensource.com X-Mailman-Version: 2.1.5 Precedence: list List-Id: Xen developer discussion <xen-devel.lists.xensource.com> List-Unsubscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe> List-Post: <mailto:xen-devel@lists.xensource.com> List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help> List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=subscribe> Sender: xen-devel-bounces@lists.xensource.com Errors-To: xen-devel-bounces@lists.xensource.com Event channels exposed to userspace by the evtchn module may be used by other modules in an asynchronous manner, which requires that reference counting be used to prevent the event channel from being closed before the signals are delivered. Signed-off-by: Daniel De Graaf <dgdegra@tycho.nsa.gov> --- drivers/xen/events.c | 38 ++++++++++++++++++++++++++++++++++++++ include/xen/events.h | 6 ++++++ 2 files changed, 44 insertions(+), 0 deletions(-) diff --git a/drivers/xen/events.c b/drivers/xen/events.c index da70f5c..c9343b9 100644 --- a/drivers/xen/events.c +++ b/drivers/xen/events.c @@ -89,6 +89,7 @@ struct irq_info { struct list_head list; enum xen_irq_type type; /* type */ + unsigned short refcount; unsigned irq; unsigned short evtchn; /* event channel */ unsigned short cpu; /* cpu bound */ @@ -407,6 +408,7 @@ static void xen_irq_init(unsigned irq) panic("Unable to allocate metadata for IRQ%d\n", irq); info->type = IRQT_UNBOUND; + info->refcount = 1; irq_set_handler_data(irq, info); @@ -469,6 +471,8 @@ static void xen_free_irq(unsigned irq) irq_set_handler_data(irq, NULL); + BUG_ON(info->refcount > 1); + kfree(info); /* Legacy IRQ descriptors are managed by the arch. */ @@ -912,9 +916,14 @@ static void unbind_from_irq(unsigned int irq) { struct evtchn_close close; int evtchn = evtchn_from_irq(irq); + struct irq_info *info = irq_get_handler_data(irq); spin_lock(&irq_mapping_update_lock); + info->refcount--; + if (info->refcount > 0) + goto out_unlock; + if (VALID_EVTCHN(evtchn)) { close.port = evtchn; if (HYPERVISOR_event_channel_op(EVTCHNOP_close, &close) != 0) @@ -943,6 +952,7 @@ static void unbind_from_irq(unsigned int irq) xen_free_irq(irq); + out_unlock: spin_unlock(&irq_mapping_update_lock); } @@ -1038,6 +1048,34 @@ void unbind_from_irqhandler(unsigned int irq, void *dev_id) } EXPORT_SYMBOL_GPL(unbind_from_irqhandler); +int get_evtchn_reservation(unsigned int evtchn) +{ + int irq = evtchn_to_irq[evtchn]; + struct irq_info *info; + + if (irq == -1) + return -ENOENT; + + info = irq_get_handler_data(irq); + + if (!info) + return -ENOENT; + + spin_lock(&irq_mapping_update_lock); + info->refcount++; + spin_unlock(&irq_mapping_update_lock); + + return 0; +} +EXPORT_SYMBOL_GPL(get_evtchn_reservation); + +void put_evtchn_reservation(unsigned int evtchn) +{ + int irq = evtchn_to_irq[evtchn]; + unbind_from_irq(irq); +} +EXPORT_SYMBOL_GPL(put_evtchn_reservation); + void xen_send_IPI_one(unsigned int cpu, enum ipi_vector vector) { int irq = per_cpu(ipi_to_irq, cpu)[vector]; diff --git a/include/xen/events.h b/include/xen/events.h index d287997..23bd5fd 100644 --- a/include/xen/events.h +++ b/include/xen/events.h @@ -37,6 +37,12 @@ int bind_interdomain_evtchn_to_irqhandler(unsigned int remote_domain, */ void unbind_from_irqhandler(unsigned int irq, void *dev_id); +/* + * Allow extra references to event channels exposed to userspace by evtchn + */ +int get_evtchn_reservation(unsigned int evtchn); +void put_evtchn_reservation(unsigned int evtchn); + void xen_send_IPI_one(unsigned int cpu, enum ipi_vector vector); int resend_irq_on_evtchn(unsigned int irq); void rebind_evtchn_irq(int evtchn, int irq); -- 1.7.6 _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel From xen-devel-bounces@lists.xensource.com Fri Sep 16 15:04:22 2011 Return-path: <xen-devel-bounces@lists.xensource.com> Envelope-to: www-data@lists.xensource.com Delivery-date: Fri, 16 Sep 2011 15:04:22 -0700 Received: from localhost ([127.0.0.1] helo=lists.colo.xensource.com) by lists.xensource.com with esmtp (Exim 4.43) id 1R4gWB-00031i-Cc; Fri, 16 Sep 2011 15:04:19 -0700 Received: from mail182.messagelabs.com ([85.158.139.83]) by lists.xensource.com with esmtp (Exim 4.43) id 1R4gUX-0002ne-VO for xen-devel@lists.xensource.com; Fri, 16 Sep 2011 15:02:43 -0700 X-Env-Sender: Ian.Campbell@eu.citrix.com X-Msg-Ref: server-13.tower-182.messagelabs.com!1316210553!18502458!1 X-Originating-IP: [66.165.176.89] X-StarScan-Version: 6.4.1; banners=-,-,- X-VirusChecked: Checked Received: (qmail 2129 invoked from network); 16 Sep 2011 22:02:34 -0000 Received: from smtp.citrix.com (HELO SMTP.CITRIX.COM) (66.165.176.89) by server-13.tower-182.messagelabs.com with RC4-SHA encrypted SMTP; 16 Sep 2011 22:02:34 -0000 X-IronPort-AV: E=Sophos;i="4.68,395,1312171200"; d="scan'208";a="17394294" Received: from ftlpmailmx01.citrite.net ([10.13.107.65]) by FTLPIPO01.CITRIX.COM with ESMTP/TLS/RC4-MD5; 16 Sep 2011 18:02:33 -0400 Received: from [127.0.0.1] (10.80.16.67) by smtprelay.citrix.com (10.13.107.65) with Microsoft SMTP Server id 8.3.137.0; Fri, 16 Sep 2011 18:02:32 -0400 Subject: Re: [Xen-devel] Re: Out sw-iommu space problem From: Ian Campbell <Ian.Campbell@citrix.com> To: Fantu <fantonifabio@tiscali.it> Date: Sat, 17 Sep 2011 00:02:31 +0200 In-Reply-To: <1316105794010-4807540.post@n5.nabble.com> References: <1316011454156-4803078.post@n5.nabble.com> <20110914145403.GA17899@phenom.oracle.com> <1316097409687-4807062.post@n5.nabble.com> <20110915145840.GA20726@phenom.oracle.com> <1316105794010-4807540.post@n5.nabble.com> Organization: Citrix Systems, Inc. Content-Type: text/plain; charset="UTF-8" X-Mailer: Evolution 3.0.3- Content-Transfer-Encoding: 7bit Message-ID: <1316210553.26990.24.camel@cthulhu.hellion.org.uk> MIME-Version: 1.0 Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com> X-BeenThere: xen-devel@lists.xensource.com X-Mailman-Version: 2.1.5 Precedence: list List-Id: Xen developer discussion <xen-devel.lists.xensource.com> List-Unsubscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe> List-Post: <mailto:xen-devel@lists.xensource.com> List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help> List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=subscribe> Sender: xen-devel-bounces@lists.xensource.com Errors-To: xen-devel-bounces@lists.xensource.com On Thu, 2011-09-15 at 12:56 -0400, Fantu wrote: > Thanks, someone know if this fix is included in next debian kernel build? ( > http://packages.qa.debian.org/l/linux-2.6/news/20110913T200325Z.html ) It will most likely get into the next Debian Squeeze kernel by virtue of being in the next upstream longterm release but I'll keep and eye on things and try to make sure it gets in regardless.. Ian. > kernel.org is down and i can't see the changelog, for example > http://www.kernel.org/pub/linux/kernel/v2.6/longterm/v2.6.32/ChangeLog-2.6.32.46 > > -- > View this message in context: http://xen.1045712.n5.nabble.com/Out-sw-iommu-space-problem-tp4803078p4807540.html > Sent from the Xen - Dev mailing list archive at Nabble.com. > > _______________________________________________ > Xen-devel mailing list > Xen-devel@lists.xensource.com > http://lists.xensource.com/xen-devel _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel From xen-devel-bounces@lists.xensource.com Fri Sep 16 15:41:13 2011 Return-path: <xen-devel-bounces@lists.xensource.com> Envelope-to: www-data@lists.xensource.com Delivery-date: Fri, 16 Sep 2011 15:41:13 -0700 Received: from localhost ([127.0.0.1] helo=lists.colo.xensource.com) by lists.xensource.com with esmtp (Exim 4.43) id 1R4h5t-00043Y-Ad; Fri, 16 Sep 2011 15:41:13 -0700 Received: from mail216.messagelabs.com ([85.158.143.99]) by lists.xensource.com with esmtp (Exim 4.43) id 1R4h57-0003rC-3I for xen-devel@lists.xensource.com; Fri, 16 Sep 2011 15:40:25 -0700 X-Env-Sender: jeremy@goop.org X-Msg-Ref: server-4.tower-216.messagelabs.com!1316212820!18565890!1 X-Originating-IP: [74.207.240.146] X-StarScan-Version: 6.4.1; banners=-,-,- X-VirusChecked: Checked Received: (qmail 3517 invoked from network); 16 Sep 2011 22:40:21 -0000 Received: from claw.goop.org (HELO claw.goop.org) (74.207.240.146) by server-4.tower-216.messagelabs.com with DHE-RSA-AES256-SHA encrypted SMTP; 16 Sep 2011 22:40:21 -0000 Received: from saboo.goop.org (unknown [IPv6:2001:470:1f05:899:44d8:3aff:fe12:864b]) (Authenticated sender: smtp-saboo) by claw.goop.org (Postfix) with ESMTPSA id 7D9379168; Fri, 16 Sep 2011 15:40:19 -0700 (PDT) Received: from saboo.goop.org (localhost [IPv6:::1]) by saboo.goop.org (Postfix) with ESMTP id 73E8D20C64; Fri, 16 Sep 2011 15:40:18 -0700 (PDT) Message-ID: <4E73D052.3020901@goop.org> Date: Fri, 16 Sep 2011 15:40:18 -0700 From: Jeremy Fitzhardinge <jeremy@goop.org> User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:6.0.2) Gecko/20110906 Thunderbird/6.0.2 MIME-Version: 1.0 To: Philippe.Simonet@swisscom.com Subject: Re: [Xen-devel] Xen 4 TSC problems References: <AANLkTik3Ng6TpQANfPNJ2M=86WYLHVt7_MuBuVfJ1CG_@mail.gmail.com> <4E6F034B.5040102@bluewin.ch> <20110915082402.GC24888@phenom.oracle.com> <4E7226CB.2020706@goop.org> <FF93AF260AC2BB499A119CC65B092CF73112A3CA@sg000713.corproot.net> In-Reply-To: <FF93AF260AC2BB499A119CC65B092CF73112A3CA@sg000713.corproot.net> X-Enigmail-Version: 1.3.1 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: xen-devel@lists.xensource.com, philippe.simonet@bluewin.ch, konrad.wilk@oracle.com X-BeenThere: xen-devel@lists.xensource.com X-Mailman-Version: 2.1.5 Precedence: list List-Id: Xen developer discussion <xen-devel.lists.xensource.com> List-Unsubscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe> List-Post: <mailto:xen-devel@lists.xensource.com> List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help> List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=subscribe> Sender: xen-devel-bounces@lists.xensource.com Errors-To: xen-devel-bounces@lists.xensource.com On 09/15/2011 11:03 PM, Philippe.Simonet@swisscom.com wrote: >> -----Original Message----- >> From: xen-devel-bounces@lists.xensource.com [mailto:xen-devel- >> bounces@lists.xensource.com] On Behalf Of Jeremy Fitzhardinge >> Sent: Thursday, September 15, 2011 6:25 PM >> To: Konrad Rzeszutek Wilk >> Cc: xen-devel@lists.xensource.com; Philippe Simonet >> Subject: Re: [Xen-devel] Xen 4 TSC problems >> >> On 09/15/2011 01:24 AM, Konrad Rzeszutek Wilk wrote: >>> On Tue, Sep 13, 2011 at 09:16:27AM +0200, Philippe Simonet wrote: >>>> Hi Xen developers >>> Lets try this again, this time Cc-ing Jeremy. >>>> i just would like to inform you that I have exactly the same problem >>>> with Debian squeeze and xen, with >>>> 50 seconds time jump on my dom0 and domu. NTP is running on all >>>> dom0/domuU, clocksource is 'xen' >>>> everywhere. >>>> >>>> some messages : >>>> syslog : >>>> Sep 11 13:56:50 dnsit22 kernel: [571603.359863] Clocksource tsc >>>> unstable (delta = -2999662111513 ns) >>>> >>>> xm dmesg : >>>> ... >>>> (XEN) Platform timer is 14.318MHz HPET ... >>>> (XEN) Platform timer appears to have unexpectedly wrapped 10 or more >> times. >>>> (XEN) TSC marked as reliable, warp = 0 (count=2) ... >>>> >>>> I had some contact with Olivier Hanesse and it indicates that he >>>> doesn't have any solution for this problem, and all what was proposed >>>> in February didn't solved this problem. >> That looks like Xen itself is having problems keeping track of time. If it can't >> manage it, then there's not much the guest kernels can do about it. >> >>> Which was the max_cstate=0 ? >>> .. >>>> config : >>>> -------------------------------------- >>>> Linux dnsit22.swissptt.ch 2.6.32-5-xen-amd64 #1 SMP Tue Jun 14 >>>> 12:46:30 UTC 2011 x86_64 GNU/Linux >>>> -------------------------------------- >>>> HP DL385 >>>> -------------------------------------- >>>> vendor_id : AuthenticAMD >>>> cpu family : 16 >>>> model : 9 >>>> model name : AMD Opteron(tm) Processor 6174 >>>> stepping : 1 >>>> cpu MHz : 3058776.574 >>> OK, that is really messed up. Your house must be on fire for the >>> machine to be running at 3058GHz! >>> >>> Jeremy, this sounds familiar - did we have a patch for this in your >>> 2.6.32 tree? >> Not that I can think of. All I can suggest from the kernel side is that perhaps >> some of the ACPI power stuff isn't being set up properly, and that makes the >> CPU do very strange things with its TSC/power states in general. >> > how can i detect that ? > > the /proc/acpi/processor path is empty, > > find /proc/acpi > /proc/acpi > /proc/acpi/processor > /proc/acpi/button > /proc/acpi/button/power > /proc/acpi/button/power/PWRF > /proc/acpi/button/power/PWRF/info > /proc/acpi/thermal_zone > /proc/acpi/wakeup > /proc/acpi/sleep > /proc/acpi/fadt > /proc/acpi/dsdt > /proc/acpi/info > /proc/acpi/power_resource > /proc/acpi/embedded_controller > > dmesg | grep -I acpi > [ 1.205647] hpet_acpi_add: no address or irqs in _CRS > > lsmod | grep -i acpi > acpi_processor 5087 1 processor,[permanent] What does "xenpm start 5" say? J _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel From xen-devel-bounces@lists.xensource.com Fri Sep 16 15:43:20 2011 Return-path: <xen-devel-bounces@lists.xensource.com> Envelope-to: www-data@lists.xensource.com Delivery-date: Fri, 16 Sep 2011 15:43:20 -0700 Received: from localhost ([127.0.0.1] helo=lists.colo.xensource.com) by lists.xensource.com with esmtp (Exim 4.43) id 1R4h7w-0004Rr-6F; Fri, 16 Sep 2011 15:43:20 -0700 Received: from mail182.messagelabs.com ([85.158.139.83]) by lists.xensource.com with smtp (Exim 4.43) id 1R4h7M-0004FG-Cd for xen-devel@lists.xensource.com; Fri, 16 Sep 2011 15:42:46 -0700 X-Env-Sender: jim_burn@bellsouth.net X-Msg-Ref: server-12.tower-182.messagelabs.com!1316212960!18514942!1 X-Originating-IP: [66.94.237.209] X-StarScan-Version: 6.4.1; banners=-,-,- X-VirusChecked: Checked Received: (qmail 21580 invoked from network); 16 Sep 2011 22:42:40 -0000 Received: from nm8.access.bullet.mail.mud.yahoo.com (HELO nm8.access.bullet.mail.mud.yahoo.com) (66.94.237.209) by server-12.tower-182.messagelabs.com with SMTP; 16 Sep 2011 22:42:40 -0000 Received: from [66.94.237.196] by nm8.access.bullet.mail.mud.yahoo.com with NNFMP; 16 Sep 2011 22:42:39 -0000 Received: from [66.94.237.106] by tm7.access.bullet.mail.mud.yahoo.com with NNFMP; 16 Sep 2011 22:42:39 -0000 Received: from [127.0.0.1] by omp1011.access.mail.mud.yahoo.com with NNFMP; 16 Sep 2011 22:42:39 -0000 X-Yahoo-Newman-Id: 848749.84524.bm@omp1011.access.mail.mud.yahoo.com Received: (qmail 71271 invoked from network); 16 Sep 2011 22:42:39 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=bellsouth.net; s=s1024; t=1316212959; bh=/eOfTqbRTv2eMQks9BqIdkrAAbgIU/neOewSR19iSTQ=; h=X-Yahoo-Newman-Property:X-YMail-OSG:X-Yahoo-SMTP:Received:From:To:Cc:Subject:Date:Message-ID:User-Agent:In-Reply-To:References:MIME-Version:Content-Transfer-Encoding:Content-Type; b=3aRieP6mVUWVIKSQipWg5DjNaKhHFYGLIYXE/+mpTgHWkZQ4b5i9BHa1xDR4IZ8RszhsJp2wXNoZj+VM0mRIshRzGCt/qeHTKIThnI3uZcnX+ve2MJRWl+XMDVPDzWTyyGVmgtu9YBjQRWE1h3IPYLhxhd+SzhkEqm281uV+YWk= X-Yahoo-Newman-Property: ymail-3 X-YMail-OSG: w_dxdSUVM1m67j1VvdUSc_r697T9PTlJoj1kgmCqjbKMBeP ozU9X3CKtBFcn_irBBl42J_2CtWgkCF7VQCLjqOja1.6TH0qoo.FmxK96QFg AfU6o26sFXwBxEcOFa1KOljlO.aZ8wUrtbKTcJjEnyx._bDRRy.iU0cMhWS_ vjJT.KDckbNrNjaDLwOPYqWfwfJ_TPUykh2KbdR4bj.VV846p0f117.5HEky bsVXi7eAuJvzil5888iWa.xtE6LjMBZf8kltBJIYF7Pjn0ggkTskpjsN86ii xsdDRF.BiKfYdWB9znoDguPutIHNxuAXqHqGxw0RY7JMiZtm7.dQ1SgKxDwG Am46keYlgGdgcH_q44FfJIsFZ3_8z5e16doTz8LFzTFWvPULzod4Xb6LnOTI d7_BoYlUFT2SmV7VIWLT9ChskSMHgtp_DuxM3Fw-- X-Yahoo-SMTP: g0AhWW2swBA2djJKuhuwxPlPqLrHlDrycdPnfR9kZNrpKCA- Received: from dell4550.localnet (jim_burn@74.190.198.215 with plain) by smtp103.sbc.mail.bf1.yahoo.com with SMTP; 16 Sep 2011 15:42:39 -0700 PDT From: jim burns <jim_burn@bellsouth.net> To: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com> Subject: Re: [Fedora-xen] [Xen-devel] Re: [Xen-users] Continuing BUG:-iness booting Fedora Rawhide 3.1.0-rc's (was Summary: Experiences setting up a debug serial port) Date: Fri, 16 Sep 2011 18:42:32 -0400 Message-ID: <2321907.7IxSxmjte4@dell4550> User-Agent: KMail/4.7.1 (Linux/2.6.37.6-0.7-default; KDE/4.7.1; i686; ; ) In-Reply-To: <1777265.Pkue3yJNHT@dell4550> References: <201107231426.56811.jim_burn@bellsouth.net> <20110916173814.GB29389@phenom.oracle.com> <1777265.Pkue3yJNHT@dell4550> MIME-Version: 1.0 Content-Transfer-Encoding: 7Bit Content-Type: text/plain; charset="us-ascii" Cc: xen-devel@lists.xensource.com, Fedora Xen List <fedora-xen@redhat.com>, Ian Campbell <Ian.Campbell@eu.citrix.com>, M A Young <m.a.young@durham.ac.uk>, xen-users@lists.xensource.com X-BeenThere: xen-devel@lists.xensource.com X-Mailman-Version: 2.1.5 Precedence: list List-Id: Xen developer discussion <xen-devel.lists.xensource.com> List-Unsubscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe> List-Post: <mailto:xen-devel@lists.xensource.com> List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help> List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=subscribe> Sender: xen-devel-bounces@lists.xensource.com Errors-To: xen-devel-bounces@lists.xensource.com On Fri September 16 2011, 4:06:30 PM, jim burns wrote: > OK, if your confident that these problems will go away in a production > kernel, especially the GPF error, I can wait. If you don't need anything > else, I'll bring down the system, and retreat to 2.6.40 in a couple of > hours. Thanx for you attention. Sorry, I take it back. Just rebooted back into 2.6.40, and I'm still getting GPF errors - just not very frequently. _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel From xen-devel-bounces@lists.xensource.com Fri Sep 16 18:17:15 2011 Return-path: <xen-devel-bounces@lists.xensource.com> Envelope-to: www-data@lists.xensource.com Delivery-date: Fri, 16 Sep 2011 18:17:15 -0700 Received: from localhost ([127.0.0.1] helo=lists.colo.xensource.com) by lists.xensource.com with esmtp (Exim 4.43) id 1R4jWs-0000Y5-QS; Fri, 16 Sep 2011 18:17:14 -0700 Received: from mail27.messagelabs.com ([193.109.254.147]) by lists.xensource.com with esmtp (Exim 4.43) id 1R4jW5-0000Kj-KS for xen-devel@lists.xensource.com; Fri, 16 Sep 2011 18:16:26 -0700 X-Env-Sender: apxeng@gmail.com X-Msg-Ref: server-14.tower-27.messagelabs.com!1316222167!36485240!1 X-Originating-IP: [209.85.216.178] X-StarScan-Version: 6.4.1; banners=-,-,- X-VirusChecked: Checked Received: (qmail 28899 invoked from network); 17 Sep 2011 01:16:08 -0000 Received: from mail-qy0-f178.google.com (HELO mail-qy0-f178.google.com) (209.85.216.178) by server-14.tower-27.messagelabs.com with RC4-SHA encrypted SMTP; 17 Sep 2011 01:16:08 -0000 Received: by qyg14 with SMTP id 14so4739533qyg.9 for <xen-devel@lists.xensource.com>; Fri, 16 Sep 2011 18:16:21 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:date:message-id:subject:from:to:content-type; bh=hUa1mioatbj0S9yexG3L13y52SNvvv86gSYKvhYJbpQ=; b=TdUdZiFIch3ejQLHcdls/IqlYZHQDMM6K7epb/Yq0xGVbtGE7QcDMwrP2TIS5tlgQy mmyjlojYQRPNSQfDirSRsbT0K/aCCMclJmQFV7Tjq/VMcodxDLJnYM7ZFq1V3BX0tsQJ 4Ksf121jD6ZscX5cQ+Hkb351esvbzYpE32tKc= MIME-Version: 1.0 Received: by 10.229.71.210 with SMTP id i18mr45135qcj.10.1316222180820; Fri, 16 Sep 2011 18:16:20 -0700 (PDT) Received: by 10.229.21.1 with HTTP; Fri, 16 Sep 2011 18:16:20 -0700 (PDT) Date: Fri, 16 Sep 2011 18:16:20 -0700 Message-ID: <CAGU+autjPnjevraC5vhX4RAMC2XrqkfKUN_ZuJz1r0r3078=0Q@mail.gmail.com> From: AP <apxeng@gmail.com> To: xen-devel@lists.xensource.com Content-Type: text/plain; charset=ISO-8859-1 Subject: [Xen-devel] Testing nested virtualization on Intel CPUs X-BeenThere: xen-devel@lists.xensource.com X-Mailman-Version: 2.1.5 Precedence: list List-Id: Xen developer discussion <xen-devel.lists.xensource.com> List-Unsubscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe> List-Post: <mailto:xen-devel@lists.xensource.com> List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help> List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=subscribe> Sender: xen-devel-bounces@lists.xensource.com Errors-To: xen-devel-bounces@lists.xensource.com I am testing out nested virtualization on a Lenovo x220 (Intel i7-2620M). I am running xen-unstable (23842:483c5f8319ad) and Linux 3.0 (Ubuntu 10.10). I brought up a Centos 5.6 VM and installed Xen that is packaged with it. I think it is a variant of 3.0. The CentOS Xen VM boots very slowly but it does finally come up in to the nested Dom0. Now when I do an "xm create" of an HVM domain I just get a blank sdl screen. I don't even see the bios screen. Are there any more patches that I need to be adding to get this to work? I have also included some log output. Please let me know if you need any other info. Thanks, AP Config of nested hypervisor VM ======================= kernel = "hvmloader" builder='hvm' memory = 1024 name = 'centos' vcpus = 1 pae = 1 acpi = 1 apic = 1 vif = [ 'bridge=br0' ] disk = ['phy:/dev/vollumvg/centos,hda,w', 'phy:/dev/vollumvg/centosfi,hdb,w'] device_model = 'qemu-dm' vnc = 0 sdl = 1 stdvga = 1 serial = 'pty' monitor=1 usb=1 videoram = 16 nestedhvm = 1 Host Xen messages during nested hypervisor Xen VM boot --------------------------------------------------------------------------------------- (XEN) HVM2: HVM Loader (XEN) HVM2: Detected Xen v4.2-unstable (XEN) HVM2: Xenbus rings @0xfeffc000, event channel 2 (XEN) HVM2: System requested ROMBIOS (XEN) HVM2: CPU speed is 2691 MHz (XEN) irq.c:269: Dom2 PCI link 0 changed 0 -> 5 (XEN) HVM2: PCI-ISA link 0 routed to IRQ5 (XEN) irq.c:269: Dom2 PCI link 1 changed 0 -> 10 (XEN) HVM2: PCI-ISA link 1 routed to IRQ10 (XEN) irq.c:269: Dom2 PCI link 2 changed 0 -> 11 (XEN) HVM2: PCI-ISA link 2 routed to IRQ11 (XEN) irq.c:269: Dom2 PCI link 3 changed 0 -> 5 (XEN) HVM2: PCI-ISA link 3 routed to IRQ5 (XEN) HVM2: pci dev 01:2 INTD->IRQ5 (XEN) HVM2: pci dev 01:3 INTA->IRQ10 (XEN) HVM2: pci dev 03:0 INTA->IRQ5 (XEN) HVM2: pci dev 04:0 INTA->IRQ5 (XEN) HVM2: pci dev 02:0 bar 10 size 01000000: f0000008 (XEN) HVM2: pci dev 03:0 bar 14 size 01000000: f1000008 (XEN) HVM2: pci dev 03:0 bar 10 size 00000100: 0000c001 (XEN) HVM2: pci dev 04:0 bar 10 size 00000100: 0000c101 (XEN) HVM2: pci dev 04:0 bar 14 size 00000100: f2000000 (XEN) HVM2: pci dev 01:2 bar 20 size 00000020: 0000c201 (XEN) HVM2: pci dev 01:1 bar 20 size 00000010: 0000c221 (XEN) HVM2: Multiprocessor initialisation: (XEN) HVM2: - CPU0 ... 36-bit phys ... fixed MTRRs ... var MTRRs [2/8] ... done. (XEN) HVM2: Testing HVM environment: (XEN) HVM2: - REP INSB across page boundaries ... passed (XEN) HVM2: - GS base MSRs and SWAPGS ... passed (XEN) HVM2: Passed 2 of 2 tests (XEN) HVM2: Writing SMBIOS tables ... (XEN) HVM2: Loading ROMBIOS ... (XEN) HVM2: 9724 bytes of ROMBIOS high-memory extensions: (XEN) HVM2: Relocating to 0xfc000000-0xfc0025fc ... done (XEN) HVM2: Creating MP tables ... (XEN) HVM2: Loading Standard VGABIOS ... (XEN) HVM2: Loading PCI Option ROM ... (XEN) HVM2: - Manufacturer: http://etherboot.org (XEN) HVM2: - Product name: gPXE (XEN) HVM2: Loading ACPI ... (XEN) HVM2: vm86 TSS at fc012800 (XEN) HVM2: BIOS map: (XEN) HVM2: c0000-c9fff: VGA BIOS (XEN) HVM2: ca000-d7fff: Etherboot ROM (XEN) HVM2: f0000-fffff: Main BIOS (XEN) HVM2: E820 table: (XEN) HVM2: [00]: 00000000:00000000 - 00000000:0009e000: RAM (XEN) HVM2: [01]: 00000000:0009e000 - 00000000:000a0000: RESERVED (XEN) HVM2: HOLE: 00000000:000a0000 - 00000000:000e0000 (XEN) HVM2: [02]: 00000000:000e0000 - 00000000:00100000: RESERVED (XEN) HVM2: [03]: 00000000:00100000 - 00000000:3f000000: RAM (XEN) HVM2: HOLE: 00000000:3f000000 - 00000000:fc000000 (XEN) HVM2: [04]: 00000000:fc000000 - 00000001:00000000: RESERVED (XEN) HVM2: Invoking ROMBIOS ... (XEN) HVM2: $Revision: 1.221 $ $Date: 2008/12/07 17:32:29 $ (XEN) stdvga.c:147:d2 entering stdvga and caching modes (XEN) HVM2: VGABios $Id: vgabios.c,v 1.67 2008/01/27 09:44:12 vruppert Exp $ (XEN) HVM2: VBE Bios $Id: vbe.c,v 1.60 2008/03/02 07:47:21 vruppert Exp $ (XEN) HVM2: Bochs BIOS - build: 06/23/99 (XEN) HVM2: $Revision: 1.221 $ $Date: 2008/12/07 17:32:29 $ (XEN) HVM2: Options: apmbios pcibios eltorito PMM (XEN) HVM2: (XEN) HVM2: ata0-0: PCHS=16383/16/63 translation=lba LCHS=1024/255/63 (XEN) HVM2: ata0 master: QEMU HARDDISK ATA-7 Hard-Disk (10240 MBytes) (XEN) HVM2: ata0-1: PCHS=10402/16/63 translation=lba LCHS=652/255/63 (XEN) HVM2: ata0 slave: QEMU HARDDISK ATA-7 Hard-Disk (5120 MBytes) (XEN) HVM2: (XEN) HVM2: (XEN) HVM2: (XEN) HVM2: Press F12 for boot menu. (XEN) HVM2: (XEN) HVM2: Booting from Hard Disk... (XEN) HVM2: Booting from 0000:7c00 (XEN) HVM2: int13_harddisk: function 41, unmapped device for ELDL=82 (XEN) HVM2: int13_harddisk: function 08, unmapped device for ELDL=82 (XEN) HVM2: *** int 15h function AX=00c0, BX=0000 not yet supported! (XEN) HVM2: int13_harddisk: function 02, unmapped device for ELDL=82 (XEN) HVM2: int13_harddisk: function 41, unmapped device for ELDL=82 (XEN) irq.c:269: Dom2 PCI link 0 changed 5 -> 0 (XEN) irq.c:269: Dom2 PCI link 1 changed 10 -> 0 (XEN) irq.c:269: Dom2 PCI link 2 changed 11 -> 0 (XEN) irq.c:269: Dom2 PCI link 3 changed 5 -> 0 Nested Xen Messages during nested VM boot ------------------------------------------------------------------- (XEN) sysctl.c:51: Allowing physinfo call with newer ABI version (XEN) sysctl.c:51: Allowing physinfo call with newer ABI version (XEN) sysctl.c:51: Allowing physinfo call with newer ABI version (XEN) sysctl.c:51: Allowing physinfo call with newer ABI version (XEN) sysctl.c:51: Allowing physinfo call with newer ABI version (XEN) sysctl.c:51: Allowing physinfo call with newer ABI version (XEN) memory.c:124:d0 Could not allocate order=9 extent: id=1 memflags=0 (0 of 1) (XEN) memory.c:124:d0 Could not allocate order=9 extent: id=1 memflags=0 (0 of 1) (XEN) memory.c:124:d0 Could not allocate order=9 extent: id=1 memflags=0 (0 of 1) (XEN) memory.c:124:d0 Could not allocate order=9 extent: id=1 memflags=0 (0 of 1) _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel From xen-devel-bounces@lists.xensource.com Fri Sep 16 18:34:46 2011 Return-path: <xen-devel-bounces@lists.xensource.com> Envelope-to: www-data@lists.xensource.com Delivery-date: Fri, 16 Sep 2011 18:34:46 -0700 Received: from localhost ([127.0.0.1] helo=lists.colo.xensource.com) by lists.xensource.com with esmtp (Exim 4.43) id 1R4jnq-0001Af-Ky; Fri, 16 Sep 2011 18:34:46 -0700 Received: from mail21.messagelabs.com ([85.158.143.35]) by lists.xensource.com with esmtp (Exim 4.43) id 1R4jn8-0000xv-7i for xen-devel@lists.xensource.com; Fri, 16 Sep 2011 18:34:02 -0700 X-Env-Sender: Ian.Jackson@eu.citrix.com X-Msg-Ref: server-3.tower-21.messagelabs.com!1316223250!51898260!1 X-Originating-IP: [62.200.22.115] X-StarScan-Version: 6.4.1; banners=-,-,- X-VirusChecked: Checked Received: (qmail 30001 invoked from network); 17 Sep 2011 01:34:10 -0000 Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115) by server-3.tower-21.messagelabs.com with RC4-SHA encrypted SMTP; 17 Sep 2011 01:34:10 -0000 X-IronPort-AV: E=Sophos;i="4.68,396,1312156800"; d="scan'208";a="7903398" Received: from lonpmailmx01.citrite.net ([10.30.203.162]) by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5; 17 Sep 2011 01:33:58 +0000 Received: from woking.xci-test.com (10.80.248.135) by smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id 8.3.137.0; Sat, 17 Sep 2011 02:33:58 +0100 Received: from osstest by woking.xci-test.com with local (Exim 4.69) (envelope-from <ian.jackson@eu.citrix.com>) id 1R4jn4-0001uE-Hx; Sat, 17 Sep 2011 02:33:58 +0100 To: xen-devel@lists.xensource.com Message-ID: <osstest-8955-mainreport@xen.org> From: xen.org <ian.jackson@eu.citrix.com> Date: Sat, 17 Sep 2011 02:33:58 +0100 MIME-Version: 1.0 Content-Type: text/plain Cc: ian.jackson@eu.citrix.com Subject: [Xen-devel] [xen-unstable test] 8955: tolerable FAIL X-BeenThere: xen-devel@lists.xensource.com X-Mailman-Version: 2.1.5 Precedence: list List-Id: Xen developer discussion <xen-devel.lists.xensource.com> List-Unsubscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe> List-Post: <mailto:xen-devel@lists.xensource.com> List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help> List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=subscribe> Sender: xen-devel-bounces@lists.xensource.com Errors-To: xen-devel-bounces@lists.xensource.com flight 8955 xen-unstable real [real] http://www.chiark.greenend.org.uk/~xensrcts/logs/8955/ Failures :-/ but no regressions. Tests which did not succeed, but are not blocking, including regressions (tests previously passed) regarded as allowable: test-amd64-amd64-xl-pcipt-intel 1 xen-build-check(1) blocked n/a test-amd64-amd64-xl 1 xen-build-check(1) blocked n/a test-amd64-i386-pair 1 xen-build-check(1) blocked n/a test-amd64-i386-xl-multivcpu 1 xen-build-check(1) blocked n/a test-amd64-i386-rhel6hvm-intel 1 xen-build-check(1) blocked n/a test-i386-i386-pv 1 xen-build-check(1) blocked n/a build-i386-pvops 4 kernel-build fail like 8951 test-amd64-i386-pv 1 xen-build-check(1) blocked n/a test-amd64-amd64-pv 1 xen-build-check(1) blocked n/a test-i386-i386-xl 1 xen-build-check(1) blocked n/a build-amd64-pvops 4 kernel-build fail like 8951 test-amd64-i386-xl 1 xen-build-check(1) blocked n/a test-amd64-i386-xl-credit2 1 xen-build-check(1) blocked n/a test-amd64-i386-rhel6hvm-amd 1 xen-build-check(1) blocked n/a test-amd64-amd64-pair 1 xen-build-check(1) blocked n/a test-i386-i386-pair 1 xen-build-check(1) blocked n/a test-amd64-amd64-win 1 xen-build-check(1) blocked n/a test-amd64-amd64-xl-win 1 xen-build-check(1) blocked n/a test-amd64-i386-win 1 xen-build-check(1) blocked n/a test-i386-i386-win 1 xen-build-check(1) blocked n/a test-amd64-amd64-xl-sedf 1 xen-build-check(1) blocked n/a test-amd64-i386-win-vcpus1 1 xen-build-check(1) blocked n/a test-amd64-i386-xl-win-vcpus1 1 xen-build-check(1) blocked n/a test-i386-i386-xl-win 1 xen-build-check(1) blocked n/a version targeted for testing: xen 483c5f8319ad baseline version: xen 483c5f8319ad jobs: build-amd64 pass build-i386 pass build-amd64-oldkern pass build-i386-oldkern pass build-amd64-pvops fail build-i386-pvops fail test-amd64-amd64-xl blocked test-amd64-i386-xl blocked test-i386-i386-xl blocked test-amd64-i386-rhel6hvm-amd blocked test-amd64-i386-xl-credit2 blocked test-amd64-amd64-xl-pcipt-intel blocked test-amd64-i386-rhel6hvm-intel blocked test-amd64-i386-xl-multivcpu blocked test-amd64-amd64-pair blocked test-amd64-i386-pair blocked test-i386-i386-pair blocked test-amd64-amd64-pv blocked test-amd64-i386-pv blocked test-i386-i386-pv blocked test-amd64-amd64-xl-sedf blocked test-amd64-i386-win-vcpus1 blocked test-amd64-i386-xl-win-vcpus1 blocked test-amd64-amd64-win blocked test-amd64-i386-win blocked test-i386-i386-win blocked test-amd64-amd64-xl-win blocked test-i386-i386-xl-win blocked ------------------------------------------------------------ sg-report-flight on woking.cam.xci-test.com logs: /home/xc_osstest/logs images: /home/xc_osstest/images Logs, config files, etc. are available at http://www.chiark.greenend.org.uk/~xensrcts/logs Test harness code can be found at http://xenbits.xensource.com/gitweb?p=osstest.git;a=summary Published tested tree is already up to date. _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel From xen-devel-bounces@lists.xensource.com Fri Sep 16 18:45:49 2011 Return-path: <xen-devel-bounces@lists.xensource.com> Envelope-to: www-data@lists.xensource.com Delivery-date: Fri, 16 Sep 2011 18:45:49 -0700 Received: from localhost ([127.0.0.1] helo=lists.colo.xensource.com) by lists.xensource.com with esmtp (Exim 4.43) id 1R4jyW-0001sn-GC; Fri, 16 Sep 2011 18:45:49 -0700 Received: from mail27.messagelabs.com ([193.109.254.147]) by lists.xensource.com with esmtp (Exim 4.43) id 1R4jxr-0001gY-MP for xen-devel@lists.xensource.com; Fri, 16 Sep 2011 18:45:08 -0700 X-Env-Sender: haibinfeier@gmail.com X-Msg-Ref: server-15.tower-27.messagelabs.com!1316223895!49124078!1 X-Originating-IP: [209.85.160.171] X-StarScan-Version: 6.4.1; banners=-,-,- X-VirusChecked: Checked Received: (qmail 12577 invoked from network); 17 Sep 2011 01:44:56 -0000 Received: from mail-gy0-f171.google.com (HELO mail-gy0-f171.google.com) (209.85.160.171) by server-15.tower-27.messagelabs.com with RC4-SHA encrypted SMTP; 17 Sep 2011 01:44:56 -0000 Received: by gyh3 with SMTP id 3so4933230gyh.30 for <xen-devel@lists.xensource.com>; Fri, 16 Sep 2011 18:45:03 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:date:message-id:subject:from:to:content-type; bh=M0197/q4Bkz091IRG5HQat0ehgfBKepu7msIWDK7zzg=; b=QUy4nBZNWqcj0U/2NPfjIbuJBHHEu64hdh0+EoiyDL92s3PoQXwZZGzSb+PuMu38bn FPM8auEienVq0aZhacV09lcEoH9QUdCYVh/zWvlt4y6KwEVQfRypA2m2FZMSebtMeyc0 YcAN7gXo//wa2O6gV5F40xJlwi08h3/0URuK4= MIME-Version: 1.0 Received: by 10.68.63.132 with SMTP id g4mr117768pbs.419.1316223903050; Fri, 16 Sep 2011 18:45:03 -0700 (PDT) Received: by 10.143.98.16 with HTTP; Fri, 16 Sep 2011 18:45:03 -0700 (PDT) Date: Sat, 17 Sep 2011 09:45:03 +0800 Message-ID: <CABFOHEvsk8e48j3tvrwaJ8oReeeeuoJ3Xhyd9nFBJr54zWOvsg@mail.gmail.com> From: =?GB2312?B?1dSx8g==?= <haibinfeier@gmail.com> To: xen-devel@lists.xensource.com Subject: [Xen-devel] something about time synchronization X-BeenThere: xen-devel@lists.xensource.com X-Mailman-Version: 2.1.5 Precedence: list List-Id: Xen developer discussion <xen-devel.lists.xensource.com> List-Unsubscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe> List-Post: <mailto:xen-devel@lists.xensource.com> List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help> List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=subscribe> Content-Type: multipart/mixed; boundary="===============1374348880==" Sender: xen-devel-bounces@lists.xensource.com Errors-To: xen-devel-bounces@lists.xensource.com --===============1374348880== Content-Type: multipart/alternative; boundary=bcaec54306322fb2a504ad194241 --bcaec54306322fb2a504ad194241 Content-Type: text/plain; charset=ISO-8859-1 In PV Xen,dom0 can make time synchronization with dom U,but how about in HVM dom ?Can dom0 make time synronization with HVM dom? Thanks! --bcaec54306322fb2a504ad194241 Content-Type: text/html; charset=ISO-8859-1 In PV Xen,dom0 can make time synchronization with dom U,but how about in HVM dom ?Can dom0 make time synronization with HVM dom?<br>Thanks!<br> --bcaec54306322fb2a504ad194241-- --===============1374348880== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel --===============1374348880==-- From xen-devel-bounces@lists.xensource.com Fri Sep 16 21:51:25 2011 Return-path: <xen-devel-bounces@lists.xensource.com> Envelope-to: www-data@lists.xensource.com Delivery-date: Fri, 16 Sep 2011 21:51:25 -0700 Received: from localhost ([127.0.0.1] helo=lists.colo.xensource.com) by lists.xensource.com with esmtp (Exim 4.43) id 1R4ms8-0005Wl-41; Fri, 16 Sep 2011 21:51:24 -0700 Received: from mail21.messagelabs.com ([85.158.143.35]) by lists.xensource.com with esmtp (Exim 4.43) id 1R4mr5-0005K2-50 for xen-devel@lists.xensource.com; Fri, 16 Sep 2011 21:50:22 -0700 X-Env-Sender: jeremy@goop.org X-Msg-Ref: server-5.tower-21.messagelabs.com!1316234981!48461462!1 X-Originating-IP: [74.207.240.146] X-StarScan-Version: 6.4.1; banners=-,-,- X-VirusChecked: Checked Received: (qmail 25476 invoked from network); 17 Sep 2011 04:49:42 -0000 Received: from claw.goop.org (HELO claw.goop.org) (74.207.240.146) by server-5.tower-21.messagelabs.com with DHE-RSA-AES256-SHA encrypted SMTP; 17 Sep 2011 04:49:42 -0000 Received: from saboo.goop.org (unknown [IPv6:2001:470:1f05:899:f2de:f1ff:fe5c:34ed]) (Authenticated sender: smtp-saboo) by claw.goop.org (Postfix) with ESMTPSA id 0569586AC; Fri, 16 Sep 2011 21:50:13 -0700 (PDT) Received: from saboo.goop.org (localhost [IPv6:::1]) by saboo.goop.org (Postfix) with ESMTP id 5162620C64; Fri, 16 Sep 2011 21:50:11 -0700 (PDT) Message-ID: <4E742703.7050005@goop.org> Date: Fri, 16 Sep 2011 21:50:11 -0700 From: Jeremy Fitzhardinge <jeremy@goop.org> User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:6.0.2) Gecko/20110906 Thunderbird/6.0.2 MIME-Version: 1.0 To: Daniel De Graaf <dgdegra@tycho.nsa.gov> Subject: Re: [Xen-devel] [PATCH 1/2] xen/event: Add reference counting to event channel References: <1316207684-19860-1-git-send-email-dgdegra@tycho.nsa.gov> <1316207684-19860-2-git-send-email-dgdegra@tycho.nsa.gov> In-Reply-To: <1316207684-19860-2-git-send-email-dgdegra@tycho.nsa.gov> X-Enigmail-Version: 1.3.1 Content-Type: text/plain; charset=ISO-8859-15 Content-Transfer-Encoding: 7bit Cc: xen-devel@lists.xensource.com, Ian.Jackson@eu.citrix.com, konrad.wilk@oracle.com X-BeenThere: xen-devel@lists.xensource.com X-Mailman-Version: 2.1.5 Precedence: list List-Id: Xen developer discussion <xen-devel.lists.xensource.com> List-Unsubscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe> List-Post: <mailto:xen-devel@lists.xensource.com> List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help> List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=subscribe> Sender: xen-devel-bounces@lists.xensource.com Errors-To: xen-devel-bounces@lists.xensource.com On 09/16/2011 02:14 PM, Daniel De Graaf wrote: > Event channels exposed to userspace by the evtchn module may be used by > other modules in an asynchronous manner, which requires that reference > counting be used to prevent the event channel from being closed before > the signals are delivered. Could you use the refcounting at the irq level? I was quite pleased to have removed the event channel refcounting (and the use of naked event channels). Oh, is it that userspace allocates an event channel with /dev/evtchn, then passes that event channel to the gntalloc/gntdev drivers so they can use it to pass events between the two. That's a bit unfortunate; it might have been better to expose those event channels as file descriptors so you could use fd refcounting to manage the lifetimes. What's the downside of sending the event after the event channel has closed? That said: > > Signed-off-by: Daniel De Graaf <dgdegra@tycho.nsa.gov> > --- > drivers/xen/events.c | 38 ++++++++++++++++++++++++++++++++++++++ > include/xen/events.h | 6 ++++++ > 2 files changed, 44 insertions(+), 0 deletions(-) > > diff --git a/drivers/xen/events.c b/drivers/xen/events.c > index da70f5c..c9343b9 100644 > --- a/drivers/xen/events.c > +++ b/drivers/xen/events.c > @@ -89,6 +89,7 @@ struct irq_info > { > struct list_head list; > enum xen_irq_type type; /* type */ > + unsigned short refcount; Is short large enough? Is this something that untrusted userspace could end up wrapping? If short is sufficient, you should pack it next to the other short fields to avoid a gap. > unsigned irq; > unsigned short evtchn; /* event channel */ > unsigned short cpu; /* cpu bound */ > @@ -407,6 +408,7 @@ static void xen_irq_init(unsigned irq) > panic("Unable to allocate metadata for IRQ%d\n", irq); > > info->type = IRQT_UNBOUND; > + info->refcount = 1; > > irq_set_handler_data(irq, info); > > @@ -469,6 +471,8 @@ static void xen_free_irq(unsigned irq) > > irq_set_handler_data(irq, NULL); > > + BUG_ON(info->refcount > 1); > + > kfree(info); > > /* Legacy IRQ descriptors are managed by the arch. */ > @@ -912,9 +916,14 @@ static void unbind_from_irq(unsigned int irq) > { > struct evtchn_close close; > int evtchn = evtchn_from_irq(irq); > + struct irq_info *info = irq_get_handler_data(irq); > > spin_lock(&irq_mapping_update_lock); > > + info->refcount--; > + if (info->refcount > 0) > + goto out_unlock; > + > if (VALID_EVTCHN(evtchn)) { > close.port = evtchn; > if (HYPERVISOR_event_channel_op(EVTCHNOP_close, &close) != 0) > @@ -943,6 +952,7 @@ static void unbind_from_irq(unsigned int irq) > > xen_free_irq(irq); > > + out_unlock: > spin_unlock(&irq_mapping_update_lock); > } > > @@ -1038,6 +1048,34 @@ void unbind_from_irqhandler(unsigned int irq, void *dev_id) > } > EXPORT_SYMBOL_GPL(unbind_from_irqhandler); > > +int get_evtchn_reservation(unsigned int evtchn) "reservation"? I think just evtchn_get/put would be more consistent with kernel naming conventions. > +{ > + int irq = evtchn_to_irq[evtchn]; > + struct irq_info *info; > + > + if (irq == -1) > + return -ENOENT; > + > + info = irq_get_handler_data(irq); > + > + if (!info) > + return -ENOENT; > + > + spin_lock(&irq_mapping_update_lock); > + info->refcount++; > + spin_unlock(&irq_mapping_update_lock); What is this spinlock protecting against? The non-atomicity of ++, or something larger scale? If its just an atomicity thing, should it be an atomic_t? > + > + return 0; > +} > +EXPORT_SYMBOL_GPL(get_evtchn_reservation); > + > +void put_evtchn_reservation(unsigned int evtchn) > +{ > + int irq = evtchn_to_irq[evtchn]; > + unbind_from_irq(irq); Hm. > +} > +EXPORT_SYMBOL_GPL(put_evtchn_reservation); > + > void xen_send_IPI_one(unsigned int cpu, enum ipi_vector vector) > { > int irq = per_cpu(ipi_to_irq, cpu)[vector]; > diff --git a/include/xen/events.h b/include/xen/events.h > index d287997..23bd5fd 100644 > --- a/include/xen/events.h > +++ b/include/xen/events.h > @@ -37,6 +37,12 @@ int bind_interdomain_evtchn_to_irqhandler(unsigned int remote_domain, > */ > void unbind_from_irqhandler(unsigned int irq, void *dev_id); > > +/* > + * Allow extra references to event channels exposed to userspace by evtchn > + */ > +int get_evtchn_reservation(unsigned int evtchn); > +void put_evtchn_reservation(unsigned int evtchn); > + > void xen_send_IPI_one(unsigned int cpu, enum ipi_vector vector); > int resend_irq_on_evtchn(unsigned int irq); > void rebind_evtchn_irq(int evtchn, int irq); _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel From xen-devel-bounces@lists.xensource.com Fri Sep 16 23:12:31 2011 Return-path: <xen-devel-bounces@lists.xensource.com> Envelope-to: www-data@lists.xensource.com Delivery-date: Fri, 16 Sep 2011 23:12:31 -0700 Received: from localhost ([127.0.0.1] helo=lists.colo.xensource.com) by lists.xensource.com with esmtp (Exim 4.43) id 1R4o8a-0007MS-HR; Fri, 16 Sep 2011 23:12:29 -0700 Received: from mail174.messagelabs.com ([85.158.138.51]) by lists.xensource.com with esmtp (Exim 4.43) id 1R4o7c-00079b-Us for xen-devel@lists.xensource.com; Fri, 16 Sep 2011 23:11:29 -0700 X-Env-Sender: keir.xen@gmail.com X-Msg-Ref: server-8.tower-174.messagelabs.com!1316239885!18067426!1 X-Originating-IP: [74.125.82.43] X-StarScan-Version: 6.4.1; banners=-,-,- X-VirusChecked: Checked Received: (qmail 1887 invoked from network); 17 Sep 2011 06:11:25 -0000 Received: from mail-ww0-f43.google.com (HELO mail-ww0-f43.google.com) (74.125.82.43) by server-8.tower-174.messagelabs.com with RC4-SHA encrypted SMTP; 17 Sep 2011 06:11:25 -0000 Received: by wwf27 with SMTP id 27so4700822wwf.24 for <xen-devel@lists.xensource.com>; Fri, 16 Sep 2011 23:11:25 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=user-agent:date:subject:from:to:cc:message-id:thread-topic :thread-index:in-reply-to:mime-version:content-type :content-transfer-encoding; bh=eo7Oj3vskUuNrmbx+WEsryK9AlWJJvvBo5L4Jdd/71E=; b=mWV0D4b0spDvCv1jexoluPkQz+LjS+jK6ama8egmykZ5sZ7IVcXVVxbMDVIxyTnNwQ /LbaEq4Egp9BmCDygk3EIfR9ff/x/PFarmNlvaGghvF+AgDBIrWVY7S5Ru/po+XGQBBd RBoHl0ADQYvGvyHyLDW5T+241TqJDEPgFmx68= Received: by 10.216.134.150 with SMTP id s22mr278926wei.12.1316239884318; Fri, 16 Sep 2011 23:11:24 -0700 (PDT) Received: from [192.168.1.78] (host86-137-116-193.range86-137.btcentralplus.com. [86.137.116.193]) by mx.google.com with ESMTPS id y28sm15595819wbn.17.2011.09.16.23.11.19 (version=SSLv3 cipher=OTHER); Fri, 16 Sep 2011 23:11:22 -0700 (PDT) User-Agent: Microsoft-Entourage/12.30.0.110427 Date: Sat, 17 Sep 2011 07:11:15 +0100 Subject: Re: [Xen-devel] [PATCH 1/2] xen/event: Add reference counting to event channel From: Keir Fraser <keir.xen@gmail.com> To: Jeremy Fitzhardinge <jeremy@goop.org>, Daniel De Graaf <dgdegra@tycho.nsa.gov> Message-ID: <CA99F893.210B8%keir.xen@gmail.com> Thread-Topic: [Xen-devel] [PATCH 1/2] xen/event: Add reference counting to event channel Thread-Index: Acx1AJsh7/4bxJnPuU2hBlMvxDD6iA== In-Reply-To: <4E742703.7050005@goop.org> Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit Cc: xen-devel@lists.xensource.com, Ian Jackson <Ian.Jackson@eu.citrix.com>, Konrad Rzeszutek Wilk <konrad.wilk@oracle.com> X-BeenThere: xen-devel@lists.xensource.com X-Mailman-Version: 2.1.5 Precedence: list List-Id: Xen developer discussion <xen-devel.lists.xensource.com> List-Unsubscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe> List-Post: <mailto:xen-devel@lists.xensource.com> List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help> List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=subscribe> Sender: xen-devel-bounces@lists.xensource.com Errors-To: xen-devel-bounces@lists.xensource.com On 17/09/2011 05:50, "Jeremy Fitzhardinge" <jeremy@goop.org> wrote: > On 09/16/2011 02:14 PM, Daniel De Graaf wrote: >> Event channels exposed to userspace by the evtchn module may be used by >> other modules in an asynchronous manner, which requires that reference >> counting be used to prevent the event channel from being closed before >> the signals are delivered. > > Could you use the refcounting at the irq level? I was quite pleased to > have removed the event channel refcounting (and the use of naked event > channels). > > Oh, is it that userspace allocates an event channel with /dev/evtchn, > then passes that event channel to the gntalloc/gntdev drivers so they > can use it to pass events between the two. That's a bit unfortunate; it > might have been better to expose those event channels as file > descriptors so you could use fd refcounting to manage the lifetimes. The 'event channels' returned by /dev/evtchn are really 32-bit opaque tokens, and can be whatever you want, as long as all kernel drivers are updated to treat them consistently. -- Keir > What's the downside of sending the event after the event channel has closed? > > That said: > >> >> Signed-off-by: Daniel De Graaf <dgdegra@tycho.nsa.gov> >> --- >> drivers/xen/events.c | 38 ++++++++++++++++++++++++++++++++++++++ >> include/xen/events.h | 6 ++++++ >> 2 files changed, 44 insertions(+), 0 deletions(-) >> >> diff --git a/drivers/xen/events.c b/drivers/xen/events.c >> index da70f5c..c9343b9 100644 >> --- a/drivers/xen/events.c >> +++ b/drivers/xen/events.c >> @@ -89,6 +89,7 @@ struct irq_info >> { >> struct list_head list; >> enum xen_irq_type type; /* type */ >> + unsigned short refcount; > > Is short large enough? Is this something that untrusted userspace could > end up wrapping? If short is sufficient, you should pack it next to the > other short fields to avoid a gap. > >> unsigned irq; >> unsigned short evtchn; /* event channel */ >> unsigned short cpu; /* cpu bound */ >> @@ -407,6 +408,7 @@ static void xen_irq_init(unsigned irq) >> panic("Unable to allocate metadata for IRQ%d\n", irq); >> >> info->type = IRQT_UNBOUND; >> + info->refcount = 1; >> >> irq_set_handler_data(irq, info); >> >> @@ -469,6 +471,8 @@ static void xen_free_irq(unsigned irq) >> >> irq_set_handler_data(irq, NULL); >> >> + BUG_ON(info->refcount > 1); >> + >> kfree(info); >> >> /* Legacy IRQ descriptors are managed by the arch. */ >> @@ -912,9 +916,14 @@ static void unbind_from_irq(unsigned int irq) >> { >> struct evtchn_close close; >> int evtchn = evtchn_from_irq(irq); >> + struct irq_info *info = irq_get_handler_data(irq); >> >> spin_lock(&irq_mapping_update_lock); >> >> + info->refcount--; >> + if (info->refcount > 0) >> + goto out_unlock; >> + >> if (VALID_EVTCHN(evtchn)) { >> close.port = evtchn; >> if (HYPERVISOR_event_channel_op(EVTCHNOP_close, &close) != 0) >> @@ -943,6 +952,7 @@ static void unbind_from_irq(unsigned int irq) >> >> xen_free_irq(irq); >> >> + out_unlock: >> spin_unlock(&irq_mapping_update_lock); >> } >> >> @@ -1038,6 +1048,34 @@ void unbind_from_irqhandler(unsigned int irq, void >> *dev_id) >> } >> EXPORT_SYMBOL_GPL(unbind_from_irqhandler); >> >> +int get_evtchn_reservation(unsigned int evtchn) > "reservation"? I think just evtchn_get/put would be more consistent > with kernel naming conventions. > >> +{ >> + int irq = evtchn_to_irq[evtchn]; >> + struct irq_info *info; >> + >> + if (irq == -1) >> + return -ENOENT; >> + >> + info = irq_get_handler_data(irq); >> + >> + if (!info) >> + return -ENOENT; >> + >> + spin_lock(&irq_mapping_update_lock); >> + info->refcount++; >> + spin_unlock(&irq_mapping_update_lock); > > What is this spinlock protecting against? The non-atomicity of ++, or > something larger scale? If its just an atomicity thing, should it be an > atomic_t? > >> + >> + return 0; >> +} >> +EXPORT_SYMBOL_GPL(get_evtchn_reservation); >> + >> +void put_evtchn_reservation(unsigned int evtchn) >> +{ >> + int irq = evtchn_to_irq[evtchn]; >> + unbind_from_irq(irq); > > Hm. > >> +} >> +EXPORT_SYMBOL_GPL(put_evtchn_reservation); >> + >> void xen_send_IPI_one(unsigned int cpu, enum ipi_vector vector) >> { >> int irq = per_cpu(ipi_to_irq, cpu)[vector]; >> diff --git a/include/xen/events.h b/include/xen/events.h >> index d287997..23bd5fd 100644 >> --- a/include/xen/events.h >> +++ b/include/xen/events.h >> @@ -37,6 +37,12 @@ int bind_interdomain_evtchn_to_irqhandler(unsigned int >> remote_domain, >> */ >> void unbind_from_irqhandler(unsigned int irq, void *dev_id); >> >> +/* >> + * Allow extra references to event channels exposed to userspace by evtchn >> + */ >> +int get_evtchn_reservation(unsigned int evtchn); >> +void put_evtchn_reservation(unsigned int evtchn); >> + >> void xen_send_IPI_one(unsigned int cpu, enum ipi_vector vector); >> int resend_irq_on_evtchn(unsigned int irq); >> void rebind_evtchn_irq(int evtchn, int irq); > > > _______________________________________________ > Xen-devel mailing list > Xen-devel@lists.xensource.com > http://lists.xensource.com/xen-devel _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel From xen-devel-bounces@lists.xensource.com Sat Sep 17 06:43:24 2011 Return-path: <xen-devel-bounces@lists.xensource.com> Envelope-to: www-data@lists.xensource.com Delivery-date: Sat, 17 Sep 2011 06:43:24 -0700 Received: from localhost ([127.0.0.1] helo=lists.colo.xensource.com) by lists.xensource.com with esmtp (Exim 4.43) id 1R4vAy-0000jj-8n; Sat, 17 Sep 2011 06:43:24 -0700 Received: from mail182.messagelabs.com ([85.158.139.83]) by lists.xensource.com with esmtp (Exim 4.43) id 1R4vA2-0000XC-OG for xen-devel@lists.xensource.com; Sat, 17 Sep 2011 06:42:27 -0700 X-Env-Sender: pasik@iki.fi X-Msg-Ref: server-12.tower-182.messagelabs.com!1316266943!18557433!1 X-Originating-IP: [192.89.123.25] X-StarScan-Version: 6.4.1; banners=-,-,- X-VirusChecked: Checked Received: (qmail 14148 invoked from network); 17 Sep 2011 13:42:23 -0000 Received: from smtp.tele.fi (HELO smtp.tele.fi) (192.89.123.25) by server-12.tower-182.messagelabs.com with DHE-RSA-AES256-SHA encrypted SMTP; 17 Sep 2011 13:42:23 -0000 X-Originating-Ip: [194.89.68.22] Received: from ydin.reaktio.net (reaktio.net [194.89.68.22]) by smtp.tele.fi (Postfix) with ESMTP id 47E4F29AB; Sat, 17 Sep 2011 16:42:22 +0300 (EEST) Received: by ydin.reaktio.net (Postfix, from userid 1001) id EF0ED200E8; Sat, 17 Sep 2011 16:42:21 +0300 (EEST) Date: Sat, 17 Sep 2011 16:42:21 +0300 From: Pasi =?iso-8859-1?Q?K=E4rkk=E4inen?= <pasik@iki.fi> To: AP <apxeng@gmail.com> Subject: Re: [Xen-devel] Testing nested virtualization on Intel CPUs Message-ID: <20110917134221.GZ12984@reaktio.net> References: <CAGU+autjPnjevraC5vhX4RAMC2XrqkfKUN_ZuJz1r0r3078=0Q@mail.gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <CAGU+autjPnjevraC5vhX4RAMC2XrqkfKUN_ZuJz1r0r3078=0Q@mail.gmail.com> User-Agent: Mutt/1.5.18 (2008-05-17) Cc: xen-devel@lists.xensource.com X-BeenThere: xen-devel@lists.xensource.com X-Mailman-Version: 2.1.5 Precedence: list List-Id: Xen developer discussion <xen-devel.lists.xensource.com> List-Unsubscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe> List-Post: <mailto:xen-devel@lists.xensource.com> List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help> List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=subscribe> Sender: xen-devel-bounces@lists.xensource.com Errors-To: xen-devel-bounces@lists.xensource.com On Fri, Sep 16, 2011 at 06:16:20PM -0700, AP wrote: > I am testing out nested virtualization on a Lenovo x220 (Intel > i7-2620M). I am running xen-unstable (23842:483c5f8319ad) and Linux > 3.0 (Ubuntu 10.10). > I brought up a Centos 5.6 VM and installed Xen that is packaged with > it. I think it is a variant of 3.0. > Xen hypervisor in RHEL5 / CentOS5 is heavily patched Xen 3.1.2+. (the userland tools are 3.0.3-based though). > The CentOS Xen VM boots very > slowly but it does finally come up in to the nested Dom0. Now when I > do an "xm create" of an HVM domain I just get a blank sdl screen. I > don't even see the bios screen. Are there any more patches that I need > to be adding to get this to work? > Hmm.. I remember AMD guys mentioning nested virt Xen-on-Xen and KVM-on-Xen works OK in xen-unstable. Not sure about the status of Intel nested virt currently. You could also try using Xen 4.x in the CentOS VM, just to see if that makes a difference. rpms in http://gitco.de/repo/ -- Pasi > I have also included some log output. Please let me know if you need > any other info. > > Thanks, > AP > > Config of nested hypervisor VM > ======================= > kernel = "hvmloader" > builder='hvm' > memory = 1024 > name = 'centos' > vcpus = 1 > pae = 1 > acpi = 1 > apic = 1 > vif = [ 'bridge=br0' ] > disk = ['phy:/dev/vollumvg/centos,hda,w', 'phy:/dev/vollumvg/centosfi,hdb,w'] > device_model = 'qemu-dm' > vnc = 0 > sdl = 1 > stdvga = 1 > serial = 'pty' > monitor=1 > usb=1 > videoram = 16 > nestedhvm = 1 > > Host Xen messages during nested hypervisor Xen VM boot > --------------------------------------------------------------------------------------- > (XEN) HVM2: HVM Loader > (XEN) HVM2: Detected Xen v4.2-unstable > (XEN) HVM2: Xenbus rings @0xfeffc000, event channel 2 > (XEN) HVM2: System requested ROMBIOS > (XEN) HVM2: CPU speed is 2691 MHz > (XEN) irq.c:269: Dom2 PCI link 0 changed 0 -> 5 > (XEN) HVM2: PCI-ISA link 0 routed to IRQ5 > (XEN) irq.c:269: Dom2 PCI link 1 changed 0 -> 10 > (XEN) HVM2: PCI-ISA link 1 routed to IRQ10 > (XEN) irq.c:269: Dom2 PCI link 2 changed 0 -> 11 > (XEN) HVM2: PCI-ISA link 2 routed to IRQ11 > (XEN) irq.c:269: Dom2 PCI link 3 changed 0 -> 5 > (XEN) HVM2: PCI-ISA link 3 routed to IRQ5 > (XEN) HVM2: pci dev 01:2 INTD->IRQ5 > (XEN) HVM2: pci dev 01:3 INTA->IRQ10 > (XEN) HVM2: pci dev 03:0 INTA->IRQ5 > (XEN) HVM2: pci dev 04:0 INTA->IRQ5 > (XEN) HVM2: pci dev 02:0 bar 10 size 01000000: f0000008 > (XEN) HVM2: pci dev 03:0 bar 14 size 01000000: f1000008 > (XEN) HVM2: pci dev 03:0 bar 10 size 00000100: 0000c001 > (XEN) HVM2: pci dev 04:0 bar 10 size 00000100: 0000c101 > (XEN) HVM2: pci dev 04:0 bar 14 size 00000100: f2000000 > (XEN) HVM2: pci dev 01:2 bar 20 size 00000020: 0000c201 > (XEN) HVM2: pci dev 01:1 bar 20 size 00000010: 0000c221 > (XEN) HVM2: Multiprocessor initialisation: > (XEN) HVM2: - CPU0 ... 36-bit phys ... fixed MTRRs ... var MTRRs > [2/8] ... done. > (XEN) HVM2: Testing HVM environment: > (XEN) HVM2: - REP INSB across page boundaries ... passed > (XEN) HVM2: - GS base MSRs and SWAPGS ... passed > (XEN) HVM2: Passed 2 of 2 tests > (XEN) HVM2: Writing SMBIOS tables ... > (XEN) HVM2: Loading ROMBIOS ... > (XEN) HVM2: 9724 bytes of ROMBIOS high-memory extensions: > (XEN) HVM2: Relocating to 0xfc000000-0xfc0025fc ... done > (XEN) HVM2: Creating MP tables ... > (XEN) HVM2: Loading Standard VGABIOS ... > (XEN) HVM2: Loading PCI Option ROM ... > (XEN) HVM2: - Manufacturer: http://etherboot.org > (XEN) HVM2: - Product name: gPXE > (XEN) HVM2: Loading ACPI ... > (XEN) HVM2: vm86 TSS at fc012800 > (XEN) HVM2: BIOS map: > (XEN) HVM2: c0000-c9fff: VGA BIOS > (XEN) HVM2: ca000-d7fff: Etherboot ROM > (XEN) HVM2: f0000-fffff: Main BIOS > (XEN) HVM2: E820 table: > (XEN) HVM2: [00]: 00000000:00000000 - 00000000:0009e000: RAM > (XEN) HVM2: [01]: 00000000:0009e000 - 00000000:000a0000: RESERVED > (XEN) HVM2: HOLE: 00000000:000a0000 - 00000000:000e0000 > (XEN) HVM2: [02]: 00000000:000e0000 - 00000000:00100000: RESERVED > (XEN) HVM2: [03]: 00000000:00100000 - 00000000:3f000000: RAM > (XEN) HVM2: HOLE: 00000000:3f000000 - 00000000:fc000000 > (XEN) HVM2: [04]: 00000000:fc000000 - 00000001:00000000: RESERVED > (XEN) HVM2: Invoking ROMBIOS ... > (XEN) HVM2: $Revision: 1.221 $ $Date: 2008/12/07 17:32:29 $ > (XEN) stdvga.c:147:d2 entering stdvga and caching modes > (XEN) HVM2: VGABios $Id: vgabios.c,v 1.67 2008/01/27 09:44:12 vruppert Exp $ > (XEN) HVM2: VBE Bios $Id: vbe.c,v 1.60 2008/03/02 07:47:21 vruppert Exp $ > (XEN) HVM2: Bochs BIOS - build: 06/23/99 > (XEN) HVM2: $Revision: 1.221 $ $Date: 2008/12/07 17:32:29 $ > (XEN) HVM2: Options: apmbios pcibios eltorito PMM > (XEN) HVM2: > (XEN) HVM2: ata0-0: PCHS=16383/16/63 translation=lba LCHS=1024/255/63 > (XEN) HVM2: ata0 master: QEMU HARDDISK ATA-7 Hard-Disk (10240 MBytes) > (XEN) HVM2: ata0-1: PCHS=10402/16/63 translation=lba LCHS=652/255/63 > (XEN) HVM2: ata0 slave: QEMU HARDDISK ATA-7 Hard-Disk (5120 MBytes) > (XEN) HVM2: > (XEN) HVM2: > (XEN) HVM2: > (XEN) HVM2: Press F12 for boot menu. > (XEN) HVM2: > (XEN) HVM2: Booting from Hard Disk... > (XEN) HVM2: Booting from 0000:7c00 > (XEN) HVM2: int13_harddisk: function 41, unmapped device for ELDL=82 > (XEN) HVM2: int13_harddisk: function 08, unmapped device for ELDL=82 > (XEN) HVM2: *** int 15h function AX=00c0, BX=0000 not yet supported! > (XEN) HVM2: int13_harddisk: function 02, unmapped device for ELDL=82 > (XEN) HVM2: int13_harddisk: function 41, unmapped device for ELDL=82 > (XEN) irq.c:269: Dom2 PCI link 0 changed 5 -> 0 > (XEN) irq.c:269: Dom2 PCI link 1 changed 10 -> 0 > (XEN) irq.c:269: Dom2 PCI link 2 changed 11 -> 0 > (XEN) irq.c:269: Dom2 PCI link 3 changed 5 -> 0 > > > Nested Xen Messages during nested VM boot > ------------------------------------------------------------------- > (XEN) sysctl.c:51: Allowing physinfo call with newer ABI version > (XEN) sysctl.c:51: Allowing physinfo call with newer ABI version > (XEN) sysctl.c:51: Allowing physinfo call with newer ABI version > (XEN) sysctl.c:51: Allowing physinfo call with newer ABI version > (XEN) sysctl.c:51: Allowing physinfo call with newer ABI version > (XEN) sysctl.c:51: Allowing physinfo call with newer ABI version > (XEN) memory.c:124:d0 Could not allocate order=9 extent: id=1 > memflags=0 (0 of 1) > (XEN) memory.c:124:d0 Could not allocate order=9 extent: id=1 > memflags=0 (0 of 1) > (XEN) memory.c:124:d0 Could not allocate order=9 extent: id=1 > memflags=0 (0 of 1) > (XEN) memory.c:124:d0 Could not allocate order=9 extent: id=1 > memflags=0 (0 of 1) > > _______________________________________________ > Xen-devel mailing list > Xen-devel@lists.xensource.com > http://lists.xensource.com/xen-devel _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel From xen-devel-bounces@lists.xensource.com Sat Sep 17 08:32:36 2011 Return-path: <xen-devel-bounces@lists.xensource.com> Envelope-to: www-data@lists.xensource.com Delivery-date: Sat, 17 Sep 2011 08:32:36 -0700 Received: from localhost ([127.0.0.1] helo=lists.colo.xensource.com) by lists.xensource.com with esmtp (Exim 4.43) id 1R4wsd-00032X-Cj; Sat, 17 Sep 2011 08:32:35 -0700 Received: from mail174.messagelabs.com ([85.158.138.51]) by lists.xensource.com with esmtp (Exim 4.43) id 1R4wri-0002o0-9P for xen-devel@lists.xensource.com; Sat, 17 Sep 2011 08:31:38 -0700 X-Env-Sender: keir.xen@gmail.com X-Msg-Ref: server-8.tower-174.messagelabs.com!1316273495!18102620!1 X-Originating-IP: [74.125.82.169] X-StarScan-Version: 6.4.1; banners=-,-,- X-VirusChecked: Checked Received: (qmail 32512 invoked from network); 17 Sep 2011 15:31:35 -0000 Received: from mail-wy0-f169.google.com (HELO mail-wy0-f169.google.com) (74.125.82.169) by server-8.tower-174.messagelabs.com with RC4-SHA encrypted SMTP; 17 Sep 2011 15:31:35 -0000 Received: by wyi11 with SMTP id 11so6697392wyi.28 for <xen-devel@lists.xensource.com>; Sat, 17 Sep 2011 08:31:35 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=sender:user-agent:date:subject:from:to:cc:message-id:thread-topic :thread-index:in-reply-to:mime-version:content-type :content-transfer-encoding; bh=/ZhwdwvM1ihg4aeJHLWcbu91z9HjRCN6PiZTKHHRNbA=; b=ktGzYjR7VL8YGwA0M/9t/PR1BBTvMvLiIQYwi10GeWL7Dj0pQiLc5qXdm6UlbykSJ1 yq9lPrtTiRcns1mRjxImLtCemDlciVZS632P7djotnHVZfetc0X/VGUBPq7cW80quA5n rYdl167dDjnozDumQ21c+Rc2+GU0CA0O3WhN8= Received: by 10.216.229.133 with SMTP id h5mr99839weq.0.1316273494818; Sat, 17 Sep 2011 08:31:34 -0700 (PDT) Received: from [192.168.1.3] (host81-135-93-14.range81-135.btcentralplus.com. [81.135.93.14]) by mx.google.com with ESMTPS id e2sm17420052wbh.19.2011.09.17.08.31.32 (version=SSLv3 cipher=OTHER); Sat, 17 Sep 2011 08:31:33 -0700 (PDT) User-Agent: Microsoft-Entourage/12.30.0.110427 Date: Sat, 17 Sep 2011 16:31:24 +0100 From: Keir Fraser <keir@xen.org> To: "Liu, Jinsong" <jinsong.liu@intel.com>, "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com> Message-ID: <CA9A7BDC.319F6%keir@xen.org> Thread-Topic: Backporting cpuid faulting to Xen-4.1.0 Thread-Index: Acx0WiEbENBnkoS7T5OXYJSbSkwJNQA9LqPV In-Reply-To: <BC00F5384FCFC9499AF06F92E8B78A9E25448AA606@shsmsx502.ccr.corp.intel.com> Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit Cc: "Shan, Haitao" <haitao.shan@intel.com>, "Li, Xin" <xin.li@intel.com> Subject: [Xen-devel] Re: Backporting cpuid faulting to Xen-4.1.0 X-BeenThere: xen-devel@lists.xensource.com X-Mailman-Version: 2.1.5 Precedence: list List-Id: Xen developer discussion <xen-devel.lists.xensource.com> List-Unsubscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe> List-Post: <mailto:xen-devel@lists.xensource.com> List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help> List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=subscribe> Sender: xen-devel-bounces@lists.xensource.com Errors-To: xen-devel-bounces@lists.xensource.com On 16/09/2011 11:19, "Liu, Jinsong" <jinsong.liu@intel.com> wrote: > Keir, > > In July we implemented cpuid faulting feature, and checked in xen-unstable > tree as c/s 23653/23654/23655. > > Today we patched them to xen-4.1.0, test result shows it's OK to work with > xen-4.1.0. > So how about backporting this feature to xen-4.1.0? Now done. -- Keir > Thanks, > Jinsong _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel From xen-devel-bounces@lists.xensource.com Sat Sep 17 10:43:41 2011 Return-path: <xen-devel-bounces@lists.xensource.com> Envelope-to: www-data@lists.xensource.com Delivery-date: Sat, 17 Sep 2011 10:43:41 -0700 Received: from localhost ([127.0.0.1] helo=lists.colo.xensource.com) by lists.xensource.com with esmtp (Exim 4.43) id 1R4yvV-0006b7-5L; Sat, 17 Sep 2011 10:43:41 -0700 Received: from mail182.messagelabs.com ([85.158.139.83]) by lists.xensource.com with esmtp (Exim 4.43) id 1R4yuc-0006K0-UN for xen-devel@lists.xensource.com; Sat, 17 Sep 2011 10:42:47 -0700 X-Env-Sender: Ian.Jackson@eu.citrix.com X-Msg-Ref: server-5.tower-182.messagelabs.com!1316281363!13747752!1 X-Originating-IP: [62.200.22.115] X-StarScan-Version: 6.4.1; banners=-,-,- X-VirusChecked: Checked Received: (qmail 9667 invoked from network); 17 Sep 2011 17:42:43 -0000 Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115) by server-5.tower-182.messagelabs.com with RC4-SHA encrypted SMTP; 17 Sep 2011 17:42:43 -0000 X-IronPort-AV: E=Sophos;i="4.68,398,1312156800"; d="scan'208";a="7908388" Received: from lonpmailmx01.citrite.net ([10.30.203.162]) by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5; 17 Sep 2011 17:42:43 +0000 Received: from woking.xci-test.com (10.80.248.135) by smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id 8.3.137.0; Sat, 17 Sep 2011 18:42:43 +0100 Received: from osstest by woking.xci-test.com with local (Exim 4.69) (envelope-from <ian.jackson@eu.citrix.com>) id 1R4yuY-0002aK-U9; Sat, 17 Sep 2011 18:42:42 +0100 To: <xen-devel@lists.xensource.com> Message-ID: <osstest-8959-mainreport@xen.org> From: xen.org <ian.jackson@eu.citrix.com> Date: Sat, 17 Sep 2011 18:42:42 +0100 MIME-Version: 1.0 Content-Type: text/plain Cc: ian.jackson@eu.citrix.com Subject: [Xen-devel] [xen-4.1-testing test] 8959: tolerable FAIL - PUSHED X-BeenThere: xen-devel@lists.xensource.com X-Mailman-Version: 2.1.5 Precedence: list List-Id: Xen developer discussion <xen-devel.lists.xensource.com> List-Unsubscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe> List-Post: <mailto:xen-devel@lists.xensource.com> List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help> List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=subscribe> Sender: xen-devel-bounces@lists.xensource.com Errors-To: xen-devel-bounces@lists.xensource.com flight 8959 xen-4.1-testing real [real] http://www.chiark.greenend.org.uk/~xensrcts/logs/8959/ Failures :-/ but no regressions. Tests which did not succeed, but are not blocking, including regressions (tests previously passed) regarded as allowable: build-i386-pvops 4 kernel-build fail like 8875 test-amd64-i386-pv 1 xen-build-check(1) blocked n/a test-i386-i386-pv 1 xen-build-check(1) blocked n/a test-amd64-amd64-pv 1 xen-build-check(1) blocked n/a test-amd64-amd64-xl-pcipt-intel 1 xen-build-check(1) blocked n/a build-amd64-pvops 4 kernel-build fail like 8875 test-amd64-i386-rhel6hvm-amd 1 xen-build-check(1) blocked n/a test-amd64-amd64-xl-sedf 1 xen-build-check(1) blocked n/a test-amd64-i386-rhel6hvm-intel 1 xen-build-check(1) blocked n/a test-amd64-i386-xl-credit2 1 xen-build-check(1) blocked n/a test-i386-i386-xl 1 xen-build-check(1) blocked n/a test-amd64-i386-pair 1 xen-build-check(1) blocked n/a test-i386-i386-pair 1 xen-build-check(1) blocked n/a test-amd64-amd64-pair 1 xen-build-check(1) blocked n/a test-amd64-i386-xl-multivcpu 1 xen-build-check(1) blocked n/a test-amd64-amd64-xl 1 xen-build-check(1) blocked n/a test-amd64-i386-xl 1 xen-build-check(1) blocked n/a test-amd64-i386-xl-win-vcpus1 1 xen-build-check(1) blocked n/a test-amd64-amd64-win 1 xen-build-check(1) blocked n/a test-amd64-i386-win 1 xen-build-check(1) blocked n/a test-i386-i386-xl-win 1 xen-build-check(1) blocked n/a test-amd64-i386-win-vcpus1 1 xen-build-check(1) blocked n/a test-amd64-amd64-xl-win 1 xen-build-check(1) blocked n/a test-i386-i386-win 1 xen-build-check(1) blocked n/a version targeted for testing: xen 7d13e08b5120 baseline version: xen 829c4fd73b10 ------------------------------------------------------------ People who touched revisions under test: Andrew Cooper <andrew.cooper3@citrix.com> George Dunlap <george.dunlap@eu.citrix.com> Jan Beulich <jbeulich@suse.com> Juergen Gross <juergen.gross@ts.fujitsu.com> Keir Fraser <keir@xen.org> Liu, Jinsong <jinsong.liu@intel.com> ------------------------------------------------------------ jobs: build-amd64 pass build-i386 pass build-amd64-oldkern pass build-i386-oldkern pass build-amd64-pvops fail build-i386-pvops fail test-amd64-amd64-xl blocked test-amd64-i386-xl blocked test-i386-i386-xl blocked test-amd64-i386-rhel6hvm-amd blocked test-amd64-i386-xl-credit2 blocked test-amd64-amd64-xl-pcipt-intel blocked test-amd64-i386-rhel6hvm-intel blocked test-amd64-i386-xl-multivcpu blocked test-amd64-amd64-pair blocked test-amd64-i386-pair blocked test-i386-i386-pair blocked test-amd64-amd64-pv blocked test-amd64-i386-pv blocked test-i386-i386-pv blocked test-amd64-amd64-xl-sedf blocked test-amd64-i386-win-vcpus1 blocked test-amd64-i386-xl-win-vcpus1 blocked test-amd64-amd64-win blocked test-amd64-i386-win blocked test-i386-i386-win blocked test-amd64-amd64-xl-win blocked test-i386-i386-xl-win blocked ------------------------------------------------------------ sg-report-flight on woking.cam.xci-test.com logs: /home/xc_osstest/logs images: /home/xc_osstest/images Logs, config files, etc. are available at http://www.chiark.greenend.org.uk/~xensrcts/logs Test harness code can be found at http://xenbits.xensource.com/gitweb?p=osstest.git;a=summary Pushing revision : + branch=xen-4.1-testing + revision=7d13e08b5120 + . cri-lock-repos ++ . cri-common +++ umask 002 +++ getconfig Repos +++ perl -e ' use Osstest; readconfigonly(); print $c{Repos} or die $!; ' ++ repos=/export/home/osstest/repos ++ repos_lock=/export/home/osstest/repos/lock ++ '[' x '!=' x/export/home/osstest/repos/lock ']' ++ OSSTEST_REPOS_LOCK_LOCKED=/export/home/osstest/repos/lock ++ exec with-lock-ex -w /export/home/osstest/repos/lock ./ap-push xen-4.1-testing 7d13e08b5120 + branch=xen-4.1-testing + revision=7d13e08b5120 + . cri-lock-repos ++ . cri-common +++ umask 002 +++ getconfig Repos +++ perl -e ' use Osstest; readconfigonly(); print $c{Repos} or die $!; ' ++ repos=/export/home/osstest/repos ++ repos_lock=/export/home/osstest/repos/lock ++ '[' x/export/home/osstest/repos/lock '!=' x/export/home/osstest/repos/lock ']' + : xen@xenbits.xensource.com + : xen@xenbits.xensource.com:git/linux-pvops + : master + : tested/2.6.39.x + case "$branch" in + cd /export/home/osstest/repos/xen-4.1-testing.hg + hg push -r 7d13e08b5120 ssh://xen@xenbits.xensource.com/HG/xen-4.1-testing.hg pushing to ssh://xen@xenbits.xensource.com/HG/xen-4.1-testing.hg searching for changes remote: adding changesets remote: adding manifests remote: adding file changes remote: added 4 changesets with 12 changes to 12 files _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel From xen-devel-bounces@lists.xensource.com Sat Sep 17 10:58:56 2011 Return-path: <xen-devel-bounces@lists.xensource.com> Envelope-to: www-data@lists.xensource.com Delivery-date: Sat, 17 Sep 2011 10:58:56 -0700 Received: from localhost ([127.0.0.1] helo=lists.colo.xensource.com) by lists.xensource.com with esmtp (Exim 4.43) id 1R4zAC-0007Pf-Ts; Sat, 17 Sep 2011 10:58:54 -0700 Received: from mail27.messagelabs.com ([193.109.254.147]) by lists.xensource.com with esmtp (Exim 4.43) id 1R4z8h-0007Ce-3f for xen-devel@lists.xensource.com; Sat, 17 Sep 2011 10:57:20 -0700 X-Env-Sender: Ian.Jackson@eu.citrix.com X-Msg-Ref: server-11.tower-27.messagelabs.com!1316282228!37831741!1 X-Originating-IP: [62.200.22.115] X-StarScan-Version: 6.4.1; banners=-,-,- X-VirusChecked: Checked Received: (qmail 22870 invoked from network); 17 Sep 2011 17:57:08 -0000 Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115) by server-11.tower-27.messagelabs.com with RC4-SHA encrypted SMTP; 17 Sep 2011 17:57:08 -0000 X-IronPort-AV: E=Sophos;i="4.68,398,1312156800"; d="scan'208";a="7908559" Received: from lonpmailmx01.citrite.net ([10.30.203.162]) by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5; 17 Sep 2011 17:57:15 +0000 Received: from woking.xci-test.com (10.80.248.135) by smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id 8.3.137.0; Sat, 17 Sep 2011 18:57:15 +0100 Received: from osstest by woking.xci-test.com with local (Exim 4.69) (envelope-from <ian.jackson@eu.citrix.com>) id 1R4z8d-00046q-Jn; Sat, 17 Sep 2011 18:57:15 +0100 To: <xen-devel@lists.xensource.com> Message-ID: <osstest-8960-mainreport@xen.org> From: xen.org <ian.jackson@eu.citrix.com> Date: Sat, 17 Sep 2011 18:57:15 +0100 MIME-Version: 1.0 Content-Type: text/plain Cc: ian.jackson@eu.citrix.com Subject: [Xen-devel] [xen-unstable test] 8960: tolerable FAIL - PUSHED X-BeenThere: xen-devel@lists.xensource.com X-Mailman-Version: 2.1.5 Precedence: list List-Id: Xen developer discussion <xen-devel.lists.xensource.com> List-Unsubscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe> List-Post: <mailto:xen-devel@lists.xensource.com> List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help> List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=subscribe> Sender: xen-devel-bounces@lists.xensource.com Errors-To: xen-devel-bounces@lists.xensource.com flight 8960 xen-unstable real [real] http://www.chiark.greenend.org.uk/~xensrcts/logs/8960/ Failures :-/ but no regressions. Tests which did not succeed, but are not blocking, including regressions (tests previously passed) regarded as allowable: test-amd64-amd64-xl-pcipt-intel 1 xen-build-check(1) blocked n/a test-amd64-amd64-xl 1 xen-build-check(1) blocked n/a test-amd64-i386-pair 1 xen-build-check(1) blocked n/a test-amd64-i386-xl-multivcpu 1 xen-build-check(1) blocked n/a test-amd64-i386-rhel6hvm-intel 1 xen-build-check(1) blocked n/a test-i386-i386-pv 1 xen-build-check(1) blocked n/a build-i386-pvops 4 kernel-build fail like 8955 test-amd64-i386-pv 1 xen-build-check(1) blocked n/a test-amd64-amd64-pv 1 xen-build-check(1) blocked n/a test-i386-i386-xl 1 xen-build-check(1) blocked n/a build-amd64-pvops 4 kernel-build fail like 8955 test-amd64-i386-xl 1 xen-build-check(1) blocked n/a test-amd64-i386-xl-credit2 1 xen-build-check(1) blocked n/a test-amd64-i386-rhel6hvm-amd 1 xen-build-check(1) blocked n/a test-amd64-amd64-pair 1 xen-build-check(1) blocked n/a test-i386-i386-pair 1 xen-build-check(1) blocked n/a test-amd64-amd64-win 1 xen-build-check(1) blocked n/a test-amd64-amd64-xl-win 1 xen-build-check(1) blocked n/a test-amd64-i386-win 1 xen-build-check(1) blocked n/a test-i386-i386-win 1 xen-build-check(1) blocked n/a test-amd64-amd64-xl-sedf 1 xen-build-check(1) blocked n/a test-amd64-i386-win-vcpus1 1 xen-build-check(1) blocked n/a test-amd64-i386-xl-win-vcpus1 1 xen-build-check(1) blocked n/a test-i386-i386-xl-win 1 xen-build-check(1) blocked n/a version targeted for testing: xen 994b5b125c31 baseline version: xen 483c5f8319ad ------------------------------------------------------------ People who touched revisions under test: George Dunlap <george.dunlap@eu.citrix.com> Ian Jackson <ian.jackson@eu.citrix.com> James Carter <jwcart2@tycho.nsa.gov> Jan Beulich <jbeulich@suse.com> Juergen Gross <juergen.gross@ts.fujitsu.com> Keir Fraser <keir@xen.org> Olaf Hering <olaf@aepfle.de> Paul Durrant <paul.durrant@citrix.com> Tim Deegan <tim@xen.org> ------------------------------------------------------------ jobs: build-amd64 pass build-i386 pass build-amd64-oldkern pass build-i386-oldkern pass build-amd64-pvops fail build-i386-pvops fail test-amd64-amd64-xl blocked test-amd64-i386-xl blocked test-i386-i386-xl blocked test-amd64-i386-rhel6hvm-amd blocked test-amd64-i386-xl-credit2 blocked test-amd64-amd64-xl-pcipt-intel blocked test-amd64-i386-rhel6hvm-intel blocked test-amd64-i386-xl-multivcpu blocked test-amd64-amd64-pair blocked test-amd64-i386-pair blocked test-i386-i386-pair blocked test-amd64-amd64-pv blocked test-amd64-i386-pv blocked test-i386-i386-pv blocked test-amd64-amd64-xl-sedf blocked test-amd64-i386-win-vcpus1 blocked test-amd64-i386-xl-win-vcpus1 blocked test-amd64-amd64-win blocked test-amd64-i386-win blocked test-i386-i386-win blocked test-amd64-amd64-xl-win blocked test-i386-i386-xl-win blocked ------------------------------------------------------------ sg-report-flight on woking.cam.xci-test.com logs: /home/xc_osstest/logs images: /home/xc_osstest/images Logs, config files, etc. are available at http://www.chiark.greenend.org.uk/~xensrcts/logs Test harness code can be found at http://xenbits.xensource.com/gitweb?p=osstest.git;a=summary Pushing revision : + branch=xen-unstable + revision=994b5b125c31 + . cri-lock-repos ++ . cri-common +++ umask 002 +++ getconfig Repos +++ perl -e ' use Osstest; readconfigonly(); print $c{Repos} or die $!; ' ++ repos=/export/home/osstest/repos ++ repos_lock=/export/home/osstest/repos/lock ++ '[' x '!=' x/export/home/osstest/repos/lock ']' ++ OSSTEST_REPOS_LOCK_LOCKED=/export/home/osstest/repos/lock ++ exec with-lock-ex -w /export/home/osstest/repos/lock ./ap-push xen-unstable 994b5b125c31 + branch=xen-unstable + revision=994b5b125c31 + . cri-lock-repos ++ . cri-common +++ umask 002 +++ getconfig Repos +++ perl -e ' use Osstest; readconfigonly(); print $c{Repos} or die $!; ' ++ repos=/export/home/osstest/repos ++ repos_lock=/export/home/osstest/repos/lock ++ '[' x/export/home/osstest/repos/lock '!=' x/export/home/osstest/repos/lock ']' + : xen@xenbits.xensource.com + : xen@xenbits.xensource.com:git/linux-pvops + : master + : tested/2.6.39.x + case "$branch" in + cd /export/home/osstest/repos/xen-unstable.hg + hg push -r 994b5b125c31 ssh://xen@xenbits.xensource.com/HG/xen-unstable.hg pushing to ssh://xen@xenbits.xensource.com/HG/xen-unstable.hg searching for changes remote: adding changesets remote: adding manifests remote: adding file changes remote: added 9 changesets with 23 changes to 20 files _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel From xen-devel-bounces@lists.xensource.com Sat Sep 17 22:08:11 2011 Return-path: <xen-devel-bounces@lists.xensource.com> Envelope-to: www-data@lists.xensource.com Delivery-date: Sat, 17 Sep 2011 22:08:11 -0700 Received: from localhost ([127.0.0.1] helo=lists.colo.xensource.com) by lists.xensource.com with esmtp (Exim 4.43) id 1R59bv-0006ar-A0; Sat, 17 Sep 2011 22:08:11 -0700 Received: from mail21.messagelabs.com ([85.158.143.35]) by lists.xensource.com with smtp (Exim 4.43) id 1R59b9-0006OR-Lb for xen-devel@lists.xensource.com; Sat, 17 Sep 2011 22:07:23 -0700 X-Env-Sender: jinsong.liu@intel.com X-Msg-Ref: server-4.tower-21.messagelabs.com!1316322404!60624401!1 X-Originating-IP: [143.182.124.21] X-StarScan-Version: 6.4.1; banners=-,-,- X-VirusChecked: Checked Received: (qmail 5956 invoked from network); 18 Sep 2011 05:06:45 -0000 Received: from mga03.intel.com (HELO mga03.intel.com) (143.182.124.21) by server-4.tower-21.messagelabs.com with SMTP; 18 Sep 2011 05:06:45 -0000 Received: from azsmga001.ch.intel.com ([10.2.17.19]) by azsmga101.ch.intel.com with ESMTP; 17 Sep 2011 22:07:18 -0700 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="4.68,400,1312182000"; d="scan'208";a="50016621" Received: from pgsmsx602.gar.corp.intel.com ([10.221.43.81]) by azsmga001.ch.intel.com with ESMTP; 17 Sep 2011 22:07:18 -0700 Received: from shsmsx602.ccr.corp.intel.com (10.239.4.104) by pgsmsx602.gar.corp.intel.com (10.221.43.81) with Microsoft SMTP Server (TLS) id 8.2.255.0; Sun, 18 Sep 2011 13:07:10 +0800 Received: from shsmsx502.ccr.corp.intel.com ([10.239.4.96]) by SHSMSX602.ccr.corp.intel.com ([10.239.4.104]) with mapi; Sun, 18 Sep 2011 13:07:09 +0800 From: "Liu, Jinsong" <jinsong.liu@intel.com> To: Keir Fraser <keir@xen.org>, "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com> Date: Sun, 18 Sep 2011 13:07:07 +0800 Thread-Topic: Backporting cpuid faulting to Xen-4.1.0 Thread-Index: Acx0WiEbENBnkoS7T5OXYJSbSkwJNQA9LqPVABx1UeA= Message-ID: <BC00F5384FCFC9499AF06F92E8B78A9E261408F1F8@shsmsx502.ccr.corp.intel.com> References: <BC00F5384FCFC9499AF06F92E8B78A9E25448AA606@shsmsx502.ccr.corp.intel.com> <CA9A7BDC.319F6%keir@xen.org> In-Reply-To: <CA9A7BDC.319F6%keir@xen.org> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "Shan, Haitao" <haitao.shan@intel.com>, "Li, Xin" <xin.li@intel.com> Subject: [Xen-devel] RE: Backporting cpuid faulting to Xen-4.1.0 X-BeenThere: xen-devel@lists.xensource.com X-Mailman-Version: 2.1.5 Precedence: list List-Id: Xen developer discussion <xen-devel.lists.xensource.com> List-Unsubscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe> List-Post: <mailto:xen-devel@lists.xensource.com> List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help> List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=subscribe> Sender: xen-devel-bounces@lists.xensource.com Errors-To: xen-devel-bounces@lists.xensource.com Keir Fraser wrote: > On 16/09/2011 11:19, "Liu, Jinsong" <jinsong.liu@intel.com> wrote: >=20 >> Keir, >>=20 >> In July we implemented cpuid faulting feature, and checked in >> xen-unstable tree as c/s 23653/23654/23655. >>=20 >> Today we patched them to xen-4.1.0, test result shows it's OK to >> work with xen-4.1.0. So how about backporting this feature to >> xen-4.1.0?=20 >=20 > Now done. >=20 > -- Keir >=20 Thanks :)= _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel From xen-devel-bounces@lists.xensource.com Sun Sep 18 01:09:20 2011 Return-path: <xen-devel-bounces@lists.xensource.com> Envelope-to: www-data@lists.xensource.com Delivery-date: Sun, 18 Sep 2011 01:09:20 -0700 Received: from localhost ([127.0.0.1] helo=lists.colo.xensource.com) by lists.xensource.com with esmtp (Exim 4.43) id 1R5CRE-0002Vz-BI; Sun, 18 Sep 2011 01:09:20 -0700 Received: from mail27.messagelabs.com ([193.109.254.147]) by lists.xensource.com with esmtp (Exim 4.43) id 1R5CQ8-0002JT-44 for xen-devel@lists.xensource.com; Sun, 18 Sep 2011 01:08:13 -0700 X-Env-Sender: burns.me.uk@gmail.com X-Msg-Ref: server-10.tower-27.messagelabs.com!1316333268!36192972!1 X-Originating-IP: [209.85.212.50] X-StarScan-Version: 6.4.1; banners=-,-,- X-VirusChecked: Checked Received: (qmail 28801 invoked from network); 18 Sep 2011 08:07:49 -0000 Received: from mail-vw0-f50.google.com (HELO mail-vw0-f50.google.com) (209.85.212.50) by server-10.tower-27.messagelabs.com with RC4-SHA encrypted SMTP; 18 Sep 2011 08:07:49 -0000 Received: by vws14 with SMTP id 14so8503075vws.23 for <xen-devel@lists.xensource.com>; Sun, 18 Sep 2011 01:08:07 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:content-type :content-transfer-encoding; bh=4iAshbpRnpqAQxJqA169LGRwbTF0uwvwsHHjL6FPRQk=; b=tg607uvjo0ZZCtLySKUZL9PrcWLFTV4ydu4ApeQnOFdLDDsaVDAyFDHhaBUAFa0nbl aeF84I2TVsVY2XWKIbrCkKwFprWPO9Gtn6UDcNJItM0WQD0FYpMKb3ples0W/lhEX4Ez 0/i8/Z5MznJcoyxtZ7V4Nc1UYQCvAZrMX4+eg= MIME-Version: 1.0 Received: by 10.52.27.201 with SMTP id v9mr1017284vdg.485.1316333287463; Sun, 18 Sep 2011 01:08:07 -0700 (PDT) Received: by 10.52.185.35 with HTTP; Sun, 18 Sep 2011 01:08:07 -0700 (PDT) In-Reply-To: <CAE1-PRfFwJh1WotLL5GD+L=Vn-zwZctqa+Rhzs2tqMavw1j-WQ@mail.gmail.com> References: <201107231426.56811.jim_burn@bellsouth.net> <1342436.B0x3ddQn4U@dell4550> <20110913085559.GG12984@reaktio.net> <1856036.eYCcuDQrZC@dell4550> <20110914090806.GD25628@phenom.oracle.com> <20110914105711.GA16284@phenom.oracle.com> <CAE1-PRfFwJh1WotLL5GD+L=Vn-zwZctqa+Rhzs2tqMavw1j-WQ@mail.gmail.com> Date: Sun, 18 Sep 2011 09:08:07 +0100 X-Google-Sender-Auth: AkTwdRnDEA3Amt9TfrK2-k4EpCQ Message-ID: <CAE1-PRdQ37dg6BX+1JGA2mvviNu8t-iAZHVoDKrvg53H_jyztw@mail.gmail.com> Subject: Re: [Xen-devel] Re: [Xen-users] Continuing BUG:-iness booting Fedora Rawhide 3.1.0-rc's (was Summary: Experiences setting up a debug serial port) From: Andy Burns <xen.lists@burns.me.uk> To: xen-devel@lists.xensource.com Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable X-BeenThere: xen-devel@lists.xensource.com X-Mailman-Version: 2.1.5 Precedence: list List-Id: Xen developer discussion <xen-devel.lists.xensource.com> List-Unsubscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe> List-Post: <mailto:xen-devel@lists.xensource.com> List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help> List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=subscribe> Sender: xen-devel-bounces@lists.xensource.com Errors-To: xen-devel-bounces@lists.xensource.com Andy Burns <xen.lists@burns.me.uk> wrote: > Konrad Rzeszutek Wilk <konrad.wilk@oracle.com> wrote: > >> We are quite sure we know the cause of this. I was wondering if you >> would be up for beta-testing a patch for this? > > I'll try to give that a go tomorrow night, I'm bumping into the same sort= of > BUGs (scheduling while atomic, sleeping function called from invalid > context) with FC16 dom0 OK, sorry it took a bit longer to get round to it .... I upgraded to 3.1.0-rc6, then booted to baremetal (didn't want bugchecks during the build to corrupt the kernel I was building) Instaleld kernel source and development tools, hacked the spec file to tweak the buildid and insert Patch and ApplyPatch lines for your mutex instead of spinlock patch, built the kernel, installed and booted the resulting 3.1.0-rc6.andy kernel as baremetal to make sure it was OK, which it was, then booted it under Xen, unfortunately it crashes ... Log from serial console attached, any further infor required, just let me know ... (XEN) Xen version 4.1.1 (mockbuild@phx2.fedoraproject.org) (gcc version 4.6.1 20110715 (Red Hat 4.6.1-3) (GCC) ) Sun Aug 14 14:29:37 UTC 2011 (XEN) Latest ChangeSet: unavailable (XEN) Bootloader: GRUB 1.99~rc1 (XEN) Command line: com1=3D115200,8n1 console=3Dcom1 loglvl=3Dall guest_log= lvl=3Dall (XEN) Video information: (XEN) VGA is text mode 80x25, font 8x16 (XEN) VBE/DDC methods: V2; EDID transfer time: 2 seconds (XEN) Disc information: (XEN) Found 0 MBR signatures (XEN) Found 6 EDD information structures (XEN) Xen-e820 RAM map: (XEN) 0000000000000000 - 000000000009cc00 (usable) (XEN) 000000000009cc00 - 00000000000a0000 (reserved) (XEN) 00000000000e5000 - 0000000000100000 (reserved) (XEN) 0000000000100000 - 00000000cff80000 (usable) (XEN) 00000000cff80000 - 00000000cff8e000 (ACPI data) (XEN) 00000000cff8e000 - 00000000cffe0000 (ACPI NVS) (XEN) 00000000cffe0000 - 00000000d0000000 (reserved) (XEN) 00000000e0000000 - 00000000f0000000 (reserved) (XEN) 00000000fee00000 - 00000000fee01000 (reserved) (XEN) 00000000ffe00000 - 0000000100000000 (reserved) (XEN) 0000000100000000 - 0000000230000000 (usable) (XEN) ACPI: RSDP 000FAFF0, 0024 (r2 ACPIAM) (XEN) ACPI: XSDT CFF80100, 0054 (r1 A_M_I_ OEMXSDT 2000913 MSFT 97) (XEN) ACPI: FACP CFF80290, 00F4 (r3 A_M_I_ OEMFACP 2000913 MSFT 97) (XEN) ACPI: DSDT CFF80450, 86FF (r1 A0863 A0863001 1 INTL 20060113) (XEN) ACPI: FACS CFF8E000, 0040 (XEN) ACPI: APIC CFF80390, 0078 (r1 A_M_I_ OEMAPIC 2000913 MSFT 97) (XEN) ACPI: MCFG CFF80410, 003C (r1 A_M_I_ OEMMCFG 2000913 MSFT 97) (XEN) ACPI: OEMB CFF8E040, 0081 (r1 A_M_I_ AMI_OEM 2000913 MSFT 97) (XEN) ACPI: HPET CFF88B50, 0038 (r1 A_M_I_ OEMHPET 2000913 MSFT 97) (XEN) ACPI: OSFR CFF88B90, 00B0 (r1 A_M_I_ OEMOSFR 2000913 MSFT 97) (XEN) System RAM: 8191MB (8387696kB) (XEN) No NUMA configuration found (XEN) Faking a node at 0000000000000000-0000000230000000 (XEN) Domain heap initialised (XEN) found SMP MP-table at 000ff780 (XEN) DMI 2.4 present. (XEN) Using APIC driver default (XEN) ACPI: PM-Timer IO Port: 0x808 (XEN) ACPI: ACPI SLEEP INFO: pm1x_cnt[804,0], pm1x_evt[800,0] (XEN) ACPI: wakeup_vec[cff8e00c], vec_size[20] (XEN) ACPI: Local APIC address 0xfee00000 (XEN) ACPI: LAPIC (acpi_id[0x01] lapic_id[0x00] enabled) (XEN) Processor #0 7:7 APIC version 20 (XEN) ACPI: LAPIC (acpi_id[0x02] lapic_id[0x01] enabled) (XEN) Processor #1 7:7 APIC version 20 (XEN) ACPI: LAPIC (acpi_id[0x03] lapic_id[0x02] enabled) (XEN) Processor #2 7:7 APIC version 20 (XEN) ACPI: LAPIC (acpi_id[0x04] lapic_id[0x03] enabled) (XEN) Processor #3 7:7 APIC version 20 (XEN) ACPI: IOAPIC (id[0x04] address[0xfec00000] gsi_base[0]) (XEN) IOAPIC[0]: apic_id 4, version 32, address 0xfec00000, GSI 0-23 (XEN) ACPI: IOAPIC (id[0x05] address[0xfec10000] gsi_base[24]) (XEN) IOAPIC[1]: apic_id 5, version 255, address 0xfec10000, GSI 24-279 (XEN) ACPI: INT_SRC_OVR (bus 0 bus_irq 0 global_irq 2 dfl dfl) (XEN) ACPI: INT_SRC_OVR (bus 0 bus_irq 9 global_irq 9 high level) (XEN) ACPI: IRQ0 used by override. (XEN) ACPI: IRQ2 used by override. (XEN) ACPI: IRQ9 used by override. (XEN) Enabling APIC mode: Flat. Using 2 I/O APICs (XEN) ACPI: HPET id: 0x8086a301 base: 0xfed00000 (XEN) PCI: MCFG configuration 0: base e0000000 segment 0 buses 0 - 255 (XEN) PCI: MCFG area at e0000000 reserved in E820 (XEN) Table is not found! (XEN) Using ACPI (MADT) for SMP configuration information (XEN) IRQ limits: 280 GSI, 1960 MSI/MSI-X (XEN) Using scheduler: SMP Credit Scheduler (credit) (XEN) Detected 2671.658 MHz processor. (XEN) Initing memory sharing. (XEN) mce_intel.c:1162: MCA Capability: BCAST 1 SER 0 CMCI 0 firstbank 1 extended MCE MSR 0 (XEN) Intel machine check reporting enabled (XEN) I/O virtualisation disabled (XEN) ENABLING IO-APIC IRQs (XEN) -> Using new ACK method (XEN) ..TIMER: vector=3D0xF0 apic1=3D0 pin1=3D2 apic2=3D-1 pin2=3D-1 (XEN) Platform timer is 14.318MHz HPET =FF(XEN) Allocated console ring of 32 KiB. (XEN) VMX: Supported advanced features: (XEN) - APIC MMIO access virtualisation (XEN) - APIC TPR shadow (XEN) - Virtual NMI (XEN) - MSR direct-access bitmap (XEN) HVM: ASIDs disabled. (XEN) HVM: VMX enabled (XEN) Brought up 4 CPUs (XEN) HPET: 4 timers in total, 0 timers will be used for broadcast (XEN) ACPI sleep modes: S3 (XEN) mcheck_poll: Machine check polling timer started. (XEN) *** LOADING DOMAIN 0 *** (XEN) Xen kernel: 64-bit, lsb, compat32 (XEN) Dom0 kernel: 64-bit, PAE, lsb, paddr 0x1000000 -> 0x1ee8000 (XEN) PHYSICAL MEMORY ARRANGEMENT: (XEN) Dom0 alloc.: 0000000220000000->0000000224000000 (2012517 pages to be allocated) (XEN) Init. ramdisk: 000000022d5e9000->000000022ffff200 (XEN) VIRTUAL MEMORY ARRANGEMENT: (XEN) Loaded kernel: ffffffff81000000->ffffffff81ee8000 (XEN) Init. ramdisk: ffffffff81ee8000->ffffffff848fe200 (XEN) Phys-Mach map: ffffffff848ff000->ffffffff8588ebe0 (XEN) Start info: ffffffff8588f000->ffffffff8588f4b4 (XEN) Page tables: ffffffff85890000->ffffffff858c1000 (XEN) Boot stack: ffffffff858c1000->ffffffff858c2000 (XEN) TOTAL: ffffffff80000000->ffffffff85c00000 (XEN) ENTRY ADDRESS: ffffffff81b76200 (XEN) Dom0 has maximum 4 VCPUs (XEN) Scrubbing Free RAM: .done. (XEN) Xen trace buffers: disabled (XEN) Std. Loglevel: All (XEN) Guest Loglevel: All (XEN) *** Serial input -> DOM0 (type 'CTRL-a' three times to switch input to Xen) (XEN) Freed 224kB init memory. mapping kernel into physical memory Xen: setup ISA identity maps about to get started... [ 0.000000] Initializing cgroup subsys cpuset [ 0.000000] Initializing cgroup subsys cpu [ 0.000000] Linux version 3.1.0-0.rc6.git0.0.andy.fc16.x86_64 (root@xen.lan) (gcc version 4.6.1 20110908 (Red Hat 4.6.1-9) (GCC) ) #1 SMP Sat Sep 17 20:49:28 BST 2011 [ 0.000000] Command line: placeholder root=3D/dev/mapper/vgr1-fc16_root ro console=3Dhvc0 [ 0.000000] Freeing d0000-e0000 pfn range: 65536 pages freed [ 0.000000] Freeing f0000-fec00 pfn range: 60416 pages freed [ 0.000000] Freeing fec01-fec10 pfn range: 15 pages freed [ 0.000000] Freeing fec11-fee00 pfn range: 495 pages freed [ 0.000000] Freeing fee01-ffe00 pfn range: 4095 pages freed [ 0.000000] released 130557 pages of unused memory [ 0.000000] Set 196835 page(s) to 1-1 mapping. [ 0.000000] BIOS-provided physical RAM map: [ 0.000000] Xen: 0000000000000000 - 000000000009c000 (usable) [ 0.000000] Xen: 000000000009cc00 - 0000000000100000 (reserved) [ 0.000000] Xen: 0000000000100000 - 00000000cff80000 (usable) [ 0.000000] Xen: 00000000cff80000 - 00000000cff8e000 (ACPI data) [ 0.000000] Xen: 00000000cff8e000 - 00000000cffe0000 (ACPI NVS) [ 0.000000] Xen: 00000000cffe0000 - 00000000d0000000 (reserved) [ 0.000000] Xen: 00000000e0000000 - 00000000f0000000 (reserved) [ 0.000000] Xen: 00000000fec00000 - 00000000fec01000 (reserved) [ 0.000000] Xen: 00000000fec10000 - 00000000fec11000 (reserved) [ 0.000000] Xen: 00000000fee00000 - 00000000fee01000 (reserved) [ 0.000000] Xen: 00000000ffe00000 - 0000000100000000 (reserved) [ 0.000000] Xen: 0000000100000000 - 0000001373ad8000 (usable) [ 0.000000] NX (Execute Disable) protection: active [ 0.000000] DMI 2.4 present. [ 0.000000] No AGP bridge found [ 0.000000] last_pfn =3D 0x1373ad8 max_arch_pfn =3D 0x400000000 [ 0.000000] last_pfn =3D 0xcff80 max_arch_pfn =3D 0x400000000 [ 0.000000] found SMP MP-table at [ffff8800000ff780] ff780 [ 0.000000] init_memory_mapping: 0000000000000000-00000000cff80000 [ 0.000000] init_memory_mapping: 0000000100000000-0000001373ad8000 [ 0.000000] RAMDISK: 01ee8000 - 048ff000 [ 0.000000] ACPI: RSDP 00000000000faff0 00024 (v02 ACPIAM) [ 0.000000] ACPI: XSDT 00000000cff80100 00054 (v01 A_M_I_ OEMXSDT 02000913 MSFT 00000097) [ 0.000000] ACPI: FACP 00000000cff80290 000F4 (v03 A_M_I_ OEMFACP 02000913 MSFT 00000097) [ 0.000000] ACPI: DSDT 00000000cff80450 086FF (v01 A0863 A0863001 00000001 INTL 20060113) [ 0.000000] ACPI: FACS 00000000cff8e000 00040 [ 0.000000] ACPI: APIC 00000000cff80390 00078 (v01 A_M_I_ OEMAPIC 02000913 MSFT 00000097) [ 0.000000] ACPI: MCFG 00000000cff80410 0003C (v01 A_M_I_ OEMMCFG 02000913 MSFT 00000097) [ 0.000000] ACPI: OEMB 00000000cff8e040 00081 (v01 A_M_I_ AMI_OEM 02000913 MSFT 00000097) [ 0.000000] ACPI: HPET 00000000cff88b50 00038 (v01 A_M_I_ OEMHPET 02000913 MSFT 00000097) [ 0.000000] ACPI: OSFR 00000000cff88b90 000B0 (v01 A_M_I_ OEMOSFR 02000913 MSFT 00000097) [ 0.000000] No NUMA configuration found [ 0.000000] Faking a node at 0000000000000000-0000001373ad8000 [ 0.000000] Initmem setup node 0 0000000000000000-0000001373ad8000 [ 0.000000] NODE_DATA [00000001f1f68000 - 00000001f1f7bfff] [ 0.000000] Zone PFN ranges: [ 0.000000] DMA 0x00000010 -> 0x00001000 [ 0.000000] DMA32 0x00001000 -> 0x00100000 [ 0.000000] Normal 0x00100000 -> 0x01373ad8 [ 0.000000] Movable zone start PFN for each node [ 0.000000] early_node_map[3] active PFN ranges [ 0.000000] 0: 0x00000010 -> 0x0000009c [ 0.000000] 0: 0x00000100 -> 0x000cff80 [ 0.000000] 0: 0x00100000 -> 0x01373ad8 [ 0.000000] ACPI: PM-Timer IO Port: 0x808 [ 0.000000] ACPI: LAPIC (acpi_id[0x01] lapic_id[0x00] enabled) [ 0.000000] BIOS bug: APIC version is 0 for CPU 0/0x0, fixing up to 0x10 [ 0.000000] ACPI: LAPIC (acpi_id[0x02] lapic_id[0x01] enabled) [ 0.000000] ACPI: LAPIC (acpi_id[0x03] lapic_id[0x02] enabled) [ 0.000000] ACPI: LAPIC (acpi_id[0x04] lapic_id[0x03] enabled) [ 0.000000] ACPI: IOAPIC (id[0x04] address[0xfec00000] gsi_base[0]) [ 0.000000] IOAPIC[0]: apic_id 4, version 255, address 0xfec00000, GSI 0= -255 [ 0.000000] ACPI: IOAPIC (id[0x05] address[0xfec10000] gsi_base[24]) [ 0.000000] IOAPIC[1]: apic_id 5, version 255, address 0xfec10000, GSI 2= 4-279 [ 0.000000] ACPI: INT_SRC_OVR (bus 0 bus_irq 0 global_irq 2 dfl dfl) [ 0.000000] ACPI: INT_SRC_OVR (bus 0 bus_irq 9 global_irq 9 high level) [ 0.000000] Using ACPI (MADT) for SMP configuration information [ 0.000000] ACPI: HPET id: 0x8086a301 base: 0xfed00000 [ 0.000000] SMP: Allowing 4 CPUs, 0 hotplug CPUs [ 0.000000] PM: Registered nosave memory: 000000000009c000 - 00000000000= 9d000 [ 0.000000] PM: Registered nosave memory: 000000000009d000 - 00000000001= 00000 [ 0.000000] PM: Registered nosave memory: 00000000cff80000 - 00000000cff= 8e000 [ 0.000000] PM: Registered nosave memory: 00000000cff8e000 - 00000000cff= e0000 [ 0.000000] PM: Registered nosave memory: 00000000cffe0000 - 00000000d00= 00000 [ 0.000000] PM: Registered nosave memory: 00000000d0000000 - 00000000e00= 00000 [ 0.000000] PM: Registered nosave memory: 00000000e0000000 - 00000000f00= 00000 [ 0.000000] PM: Registered nosave memory: 00000000f0000000 - 00000000fec= 00000 [ 0.000000] PM: Registered nosave memory: 00000000fec00000 - 00000000fec= 01000 [ 0.000000] PM: Registered nosave memory: 00000000fec01000 - 00000000fec= 10000 [ 0.000000] PM: Registered nosave memory: 00000000fec10000 - 00000000fec= 11000 [ 0.000000] PM: Registered nosave memory: 00000000fec11000 - 00000000fee= 00000 [ 0.000000] PM: Registered nosave memory: 00000000fee00000 - 00000000fee= 01000 [ 0.000000] PM: Registered nosave memory: 00000000fee01000 - 00000000ffe= 00000 [ 0.000000] PM: Registered nosave memory: 00000000ffe00000 - 00000001000= 00000 [ 0.000000] Allocating PCI resources starting at d0000000 (gap: d0000000:10000000) [ 0.000000] Booting paravirtualized kernel on Xen [ 0.000000] Xen version: 4.1.1 (preserve-AD) [ 0.000000] setup_percpu: NR_CPUS:256 nr_cpumask_bits:256 nr_cpu_ids:4 nr_node_ids:1 [ 0.000000] PERCPU: Embedded 27 pages/cpu @ffff8801f1ea8000 s81024 r8192 d21376 u110592 [ 0.000000] Built 1 zonelists in Zone order, mobility grouping on. Total pages: 19881203 [ 0.000000] Policy zone: Normal [ 0.000000] Kernel command line: placeholder root=3D/dev/mapper/vgr1-fc16_root ro console=3Dhvc0 [ 0.000000] PID hash table entries: 4096 (order: 3, 32768 bytes) [ 0.000000] Placing 64MB software IO TLB between ffff880196c00000 - ffff88019ac00000 [ 0.000000] software IO TLB at phys 0x196c00000 - 0x19ac00000 [ 0.000000] Memory: 5807024k/81587040k available (4866k kernel code, 787408k absent, 74992608k reserved, 6783k data, 940k init) [ 0.000000] SLUB: Genslabs=3D15, HWalign=3D64, Order=3D0-3, MinObjects= =3D0, CPUs=3D4, Nodes=3D1 [ 0.000000] Hierarchical RCU implementation. [ 0.000000] RCU dyntick-idle grace-period acceleration is enabled. [ 0.000000] NR_IRQS:16640 nr_irqs:1024 16 [ 0.000000] xen: sci override: global_irq=3D9 trigger=3D0 polarity=3D0 [ 0.000000] xen: acpi sci 9 [ 0.000000] xen_map_pirq_gsi: returning irq 9 for gsi 9 [ 0.000000] Console: colour VGA+ 80x25 [ 0.000000] console [hvc0] enabled [ 0.000000] allocated 646971392 bytes of page_cgroup [ 0.000000] please try 'cgroup_disable=3Dmemory' option if you don't want memory cgroups [ 0.000000] installing Xen timer for CPU 0 [ 0.000000] Detected 2671.658 MHz processor. [ 0.000999] Calibrating delay loop (skipped), value calculated using timer frequency.. 5343.31 BogoMIPS (lpj=3D2671658) [ 0.000999] pid_max: default: 32768 minimum: 301 [ 0.000999] Security Framework initialized [ 0.000999] SELinux: Initializing. [ 0.033997] Dentry cache hash table entries: 16777216 (order: 15, 134217728 bytes) [ 0.090663] Inode-cache hash table entries: 8388608 (order: 14, 67108864 bytes) [ 0.111596] Mount-cache hash table entries: 256 [ 0.111823] Initializing cgroup subsys cpuacct [ 0.111832] Initializing cgroup subsys memory [ 0.111869] Initializing cgroup subsys devices [ 0.111874] Initializing cgroup subsys freezer [ 0.111878] Initializing cgroup subsys net_cls [ 0.111883] Initializing cgroup subsys blkio [ 0.111898] Initializing cgroup subsys perf_event [ 0.111962] CPU: Physical Processor ID: 0 [ 0.111966] CPU: Processor Core ID: 0 [ 0.112567] ACPI: Core revision 20110623 [ 0.120005] ftrace: allocating 25203 entries in 99 pages [ 0.121082] Performance Events: unsupported p6 CPU model 23 no PMU driver, software events only. [ 0.121451] NMI watchdog disabled (cpu0): hardware events not enabled [ 0.121555] installing Xen timer for CPU 1 [ 0.121692] NMI watchdog disabled (cpu1): hardware events not enabled [ 0.121820] installing Xen timer for CPU 2 [ 0.121963] NMI watchdog disabled (cpu2): hardware events not enabled [ 0.122018] installing Xen timer for CPU 3 [ 0.122148] NMI watchdog disabled (cpu3): hardware events not enabled [ 0.122184] Brought up 4 CPUs [ 0.122282] devtmpfs: initialized [ 0.134984] PM: Registering ACPI NVS region at cff8e000 (335872 bytes) [ 0.135572] atomic64 test passed for x86-64 platform with CX8 and with S= SE [ 0.135595] Grant table initialized [ 0.135624] RTC time: 7:52:55, date: 09/18/11 [ 0.135663] NET: Registered protocol family 16 [ 0.135751] ACPI: bus type pci registered [ 0.135751] PCI: MMCONFIG for domain 0000 [bus 00-ff] at [mem 0xe0000000-0xefffffff] (base 0xe0000000) [ 0.135751] PCI: MMCONFIG at [mem 0xe0000000-0xefffffff] reserved in E82= 0 [ 0.205629] PCI: Using configuration type 1 for base access [ 0.211294] bio: create slab <bio-0> at 0 [ 0.211294] ACPI: Added _OSI(Module Device) [ 0.211294] ACPI: Added _OSI(Processor Device) [ 0.211294] ACPI: Added _OSI(3.0 _SCP Extensions) [ 0.211294] ACPI: Added _OSI(Processor Aggregator Device) [ 0.216698] ACPI: Executed 1 blocks of module-level executable AML code [ 0.223169] ACPI: SSDT 00000000cff8e0d0 001D2 (v01 AMI CPU1PM 00000001 INTL 20060113) [ 0.223858] ACPI: Dynamic OEM Table Load: [ 0.223865] ACPI: SSDT (null) 001D2 (v01 AMI CPU1PM 00000001 INTL 20060113) [ 0.224041] ACPI: SSDT 00000000cff8e2b0 00143 (v01 AMI CPU2PM 00000001 INTL 20060113) [ 0.224706] ACPI: Dynamic OEM Table Load: [ 0.224712] ACPI: SSDT (null) 00143 (v01 AMI CPU2PM 00000001 INTL 20060113) [ 0.224974] ACPI: SSDT 00000000cff8e400 00143 (v01 AMI CPU3PM 00000001 INTL 20060113) [ 0.225598] ACPI: Dynamic OEM Table Load: [ 0.225604] ACPI: SSDT (null) 00143 (v01 AMI CPU3PM 00000001 INTL 20060113) [ 0.225850] ACPI: SSDT 00000000cff8e550 00143 (v01 AMI CPU4PM 00000001 INTL 20060113) [ 0.226474] ACPI: Dynamic OEM Table Load: [ 0.226480] ACPI: SSDT (null) 00143 (v01 AMI CPU4PM 00000001 INTL 20060113) [ 0.226698] ACPI: Interpreter enabled [ 0.226704] ACPI: (supports S0 S1 S3 S4 S5) [ 0.226730] ACPI: Using IOAPIC for interrupt routing [ 0.234461] ACPI: No dock devices found. [ 0.234465] HEST: Table not found. [ 0.234469] PCI: Using host bridge windows from ACPI; if necessary, use "pci=3Dnocrs" and report a bug [ 0.234567] ACPI: PCI Root Bridge [PCI0] (domain 0000 [bus 00-ff]) [ 0.234734] pci_root PNP0A08:00: host bridge window [io 0x0000-0x0cf7] [ 0.234740] pci_root PNP0A08:00: host bridge window [io 0x0d00-0xffff] [ 0.234744] pci_root PNP0A08:00: host bridge window [mem 0x000a0000-0x000bffff] [ 0.234749] pci_root PNP0A08:00: host bridge window [mem 0x000d0000-0x000dffff] [ 0.234754] pci_root PNP0A08:00: host bridge window [mem 0xd0000000-0xffffffff] [ 0.237146] pci 0000:00:1f.0: ICH7 LPC Generic IO decode 1 PIO at 0294 (mask 0003) [ 0.237972] pci 0000:01:00.0: disabling ASPM on pre-1.1 PCIe device. You can enable it with 'pcie_aspm=3Dforce' [ 0.237972] pci 0000:00:01.0: PCI bridge to [bus 01-01] [ 0.238409] pci 0000:05:00.0: disabling ASPM on pre-1.1 PCIe device. You can enable it with 'pcie_aspm=3Dforce' [ 0.238418] pci 0000:00:1c.0: PCI bridge to [bus 05-07] [ 0.238831] pci 0000:05:00.0: PCI bridge to [bus 07-07] [ 0.238972] pci 0000:05:00.1: PCI bridge to [bus 06-06] [ 0.241006] pci 0000:00:1c.2: PCI bridge to [bus 04-04] [ 0.243005] pci 0000:00:1c.3: PCI bridge to [bus 03-03] [ 0.243411] pci 0000:02:00.0: disabling ASPM on pre-1.1 PCIe device. You can enable it with 'pcie_aspm=3Dforce' [ 0.243419] pci 0000:00:1c.4: PCI bridge to [bus 02-02] [ 0.243972] pci 0000:00:1e.0: PCI bridge to [bus 08-08] (subtractive dec= ode) [ 0.244414] pci0000:00: Requesting ACPI _OSC control (0x1d) [ 0.244419] pci0000:00: ACPI _OSC request failed (AE_NOT_FOUND), returned control mask: 0x1d [ 0.244424] ACPI _OSC control for PCIe not granted, disabling ASPM (XEN) PCI add device 00:00.0 (XEN) PCI add device 00:01.0 (XEN) PCI add device 00:1a.0 (XEN) PCI add device 00:1a.1 (XEN) PCI add device 00:1a.2 (XEN) PCI add device 00:1a.7 (XEN) PCI add device 00:1b.0 (XEN) PCI add device 00:1c.0 (XEN) PCI add device 00:1c.2 (XEN) PCI add device 00:1c.3 (XEN) PCI add device 00:1c.4 (XEN) PCI add device 00:1d.0 (XEN) PCI add device 00:1d.1 (XEN) PCI add device 00:1d.2 (XEN) PCI add device 00:1d.7 (XEN) PCI add device 00:1e.0 (XEN) PCI add device 00:1f.0 (XEN) PCI add device 00:1f.2 (XEN) PCI add device 00:1f.3 (XEN) PCI add device 01:00.0 (XEN) PCI add device 01:00.1 (XEN) PCI add device 05:00.0 (XEN) PCI add device 05:00.1 (XEN) PCI add device 07:01.0 (XEN) PCI add device 04:00.0 (XEN) PCI add device 03:00.0 (XEN) PCI add device 02:00.0 (XEN) PCI add device 08:00.0 (XEN) PCI add device 08:01.0 (XEN) PCI add device 08:03.0 [ 0.254926] ACPI: PCI Interrupt Link [LNKA] (IRQs 3 4 5 6 7 10 *11 12 14= 15) [ 0.254970] ACPI: PCI Interrupt Link [LNKB] (IRQs 3 4 5 6 7 *10 11 12 14= 15) [ 0.254994] ACPI: PCI Interrupt Link [LNKC] (IRQs 3 4 *5 6 7 10 11 12 14= 15) [ 0.255065] ACPI: PCI Interrupt Link [LNKD] (IRQs 3 4 5 6 7 10 11 12 14 = *15) [ 0.255136] ACPI: PCI Interrupt Link [LNKE] (IRQs 3 4 5 6 7 10 11 12 14 15) *0, disabled. [ 0.255208] ACPI: PCI Interrupt Link [LNKF] (IRQs *3 4 5 6 7 10 11 12 14= 15) [ 0.255278] ACPI: PCI Interrupt Link [LNKG] (IRQs 3 4 5 6 *7 10 11 12 14= 15) [ 0.255348] ACPI: PCI Interrupt Link [LNKH] (IRQs 3 4 5 6 7 10 11 12 *14= 15) [ 0.255401] xen/balloon: Initialising balloon driver. [ 0.255406] last_pfn =3D 0x1373ad8 max_arch_pfn =3D 0x400000000 [ 0.615498] xen-balloon: Initialising balloon driver. [ 0.615522] xen/balloon: Xen selfballooning driver disabled for domain0. [ 0.615589] vgaarb: device added: PCI:0000:01:00.0,decodes=3Dio+mem,owns=3Dio+mem,locks=3Dnone [ 0.615589] vgaarb: loaded [ 0.615589] vgaarb: bridge control possible 0000:01:00.0 [ 0.615589] SCSI subsystem initialized [ 0.615589] usbcore: registered new interface driver usbfs [ 0.615589] usbcore: registered new interface driver hub [ 0.615589] usbcore: registered new device driver usb [ 0.615948] PCI: Using ACPI for IRQ routing (XEN) mm.c:4976:d0 Global bit is set to kernel page fffff81b8e (XEN) mm.c:4976:d0 Global bit is set to kernel page fffff81b8e (XEN) mm.c:4976:d0 Global bit is set to kernel page fffff81118 (XEN) mm.c:4976:d0 Global bit is set to kernel page fffff81117 (XEN) domain_crash_sync called from entry.S (XEN) Domain 0 (vcpu#0) crashed on cpu#0: (XEN) ----[ Xen-4.1.1 x86_64 debug=3Dn Not tainted ]---- (XEN) CPU: 0 (XEN) RIP: e033:[<ffffffff81118d96>] (XEN) RFLAGS: 0000000000010282 EM: 0 CONTEXT: pv guest (XEN) rax: 0000000000000080 rbx: ffff880163985480 rcx: 0000000000000040 (XEN) rdx: 0040000000000080 rsi: ffff880163985480 rdi: ffff880163985480 (XEN) rbp: ffff880163dfaff0 rsp: ffff880163dfafd0 r8: 0000001373ffffff (XEN) r9: ffffffff81b8e7fd r10: 0000ffff00066c0a r11: 0000000080000000 (XEN) r12: ffffffff81a1cbd0 r13: ffffffff81b8e7fd r14: 0000001000000000 (XEN) r15: ffffffff81a1cbd0 cr0: 000000008005003b cr4: 00000000000026f0 (XEN) cr3: 0000000221a05000 cr2: 000000137400002f (XEN) ds: 0000 es: 0000 fs: 0000 gs: 0000 ss: e02b cs: e033 (XEN) Guest stack trace from rsp=3Dffff880163dfafd0: (XEN) ffffffff81a1cbd0 0000001373ffffff ffffffff81a1cbd0 ffffffff817a86d= 7 (XEN) ffff880163dfb040 ffffffff81b8e7fd ffff880163dfb010 ffff88016398548= 0 (XEN) ffff880163dfb040 0000001373ffffff ffffffff81a1cbd0 ffffffff817a86d= 7 (XEN) 0000001000000000 ffffffff81a1cbd0 ffff880163dfb090 ffffffff81b8e83= 8 (XEN) ffff880163dfb060 ffff880163985480 ffff880163dfb090 0000001373fffff= f (XEN) ffffffff81a1cbd0 ffffffff817a86d7 0000001000000000 ffffffff81a1cbd= 0 (XEN) ffff880163dfb0e0 ffffffff81b8e838 ffff880163dfb0b0 ffff88016398548= 0 (XEN) ffff880163dfb0e0 0000001373ffffff ffffffff81a1cbd0 ffffffff817a86d= 7 (XEN) 0000001000000000 ffffffff81a1cbd0 ffff880163dfb130 ffffffff81b8e83= 8 (XEN) ffff880163dfb100 ffff880163985480 ffff880163dfb130 0000001373fffff= f (XEN) ffffffff81a1cbd0 ffffffff817a86d7 0000001000000000 ffffffff81a1cbd= 0 (XEN) ffff880163dfb180 ffffffff81b8e838 ffff880163dfb150 ffff88016398548= 0 (XEN) ffff880163dfb180 0000001373ffffff ffffffff81a1cbd0 ffffffff817a86d= 7 (XEN) 0000001000000000 ffffffff81a1cbd0 ffff880163dfb1d0 ffffffff81b8e83= 8 (XEN) ffff880163dfb1a0 ffff880163985480 ffff880163dfb1d0 0000001373fffff= f (XEN) ffffffff81a1cbd0 ffffffff817a86d7 0000001000000000 ffffffff81a1cbd= 0 (XEN) ffff880163dfb220 ffffffff81b8e838 ffff880163dfb1f0 ffff88016398548= 0 (XEN) ffff880163dfb220 0000001373ffffff ffffffff81a1cbd0 ffffffff817a86d= 7 (XEN) 0000001000000000 ffffffff81a1cbd0 ffff880163dfb270 ffffffff81b8e83= 8 (XEN) ffff880163dfb240 ffff880163985480 ffff880163dfb270 0000001373fffff= f (XEN) Domain 0 crashed: rebooting machine in 5 seconds. _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel From xen-devel-bounces@lists.xensource.com Sun Sep 18 02:50:13 2011 Return-path: <xen-devel-bounces@lists.xensource.com> Envelope-to: www-data@lists.xensource.com Delivery-date: Sun, 18 Sep 2011 02:50:13 -0700 Received: from localhost ([127.0.0.1] helo=lists.colo.xensource.com) by lists.xensource.com with esmtp (Exim 4.43) id 1R5E0r-0004n1-6Y; Sun, 18 Sep 2011 02:50:13 -0700 Received: from mail174.messagelabs.com ([85.158.138.51]) by lists.xensource.com with esmtp (Exim 4.43) id 1R5E08-0004am-9F for xen-devel@lists.xensource.com; Sun, 18 Sep 2011 02:49:28 -0700 X-Env-Sender: maillists.shan@gmail.com X-Msg-Ref: server-9.tower-174.messagelabs.com!1316339365!25798033!1 X-Originating-IP: [74.125.82.43] X-StarScan-Version: 6.4.1; banners=-,-,- X-VirusChecked: Checked Received: (qmail 17351 invoked from network); 18 Sep 2011 09:49:25 -0000 Received: from mail-ww0-f43.google.com (HELO mail-ww0-f43.google.com) (74.125.82.43) by server-9.tower-174.messagelabs.com with RC4-SHA encrypted SMTP; 18 Sep 2011 09:49:25 -0000 Received: by wwf27 with SMTP id 27so5340528wwf.24 for <xen-devel@lists.xensource.com>; Sun, 18 Sep 2011 02:49:24 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; bh=HB+EFDWxOAVD+RRN9Yn0tjEnpaNgzbFPgx4Pl2JvL6k=; b=s59+Al6T25cavy42is74sU+Lq29zd7ZZxvVAH99E6djsyVKBEBINgqA5r9Ooxl9fpu bQhs4MdoIl4dSG7NZZw/pVvVI86W/tRkVrRL5nCdO9AHhHHYmPvfm3i54kEhRYR09OU1 8EFTTEULf1499JCAOt9sHz+FmrmmXntclXkng= MIME-Version: 1.0 Received: by 10.227.200.146 with SMTP id ew18mr1458667wbb.16.1316339364729; Sun, 18 Sep 2011 02:49:24 -0700 (PDT) Received: by 10.227.143.204 with HTTP; Sun, 18 Sep 2011 02:49:24 -0700 (PDT) In-Reply-To: <4E7313510200007800056713@nat28.tlf.novell.com> References: <CAFQ2Z+dSjU1dStaKyXry_PfRdJpO5k=35ULGPJ8TTj=5wVuW7w@mail.gmail.com> <4E7313510200007800056713@nat28.tlf.novell.com> Date: Sun, 18 Sep 2011 17:49:24 +0800 Message-ID: <CAFQ2Z+eMXPdxjLhyx3Uo_nDhz1BTaaiBJtsUmFrsppznQ2mTUg@mail.gmail.com> Subject: Re: [Xen-devel] [PATCH] Fix PV CPUID virtualization of XSave From: Haitao Shan <maillists.shan@gmail.com> To: Jan Beulich <JBeulich@suse.com> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: xen-devel@lists.xensource.com, Keir Fraser <keir@xen.org> X-BeenThere: xen-devel@lists.xensource.com X-Mailman-Version: 2.1.5 Precedence: list List-Id: Xen developer discussion <xen-devel.lists.xensource.com> List-Unsubscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe> List-Post: <mailto:xen-devel@lists.xensource.com> List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help> List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=subscribe> Sender: xen-devel-bounces@lists.xensource.com Errors-To: xen-devel-bounces@lists.xensource.com 2011/9/16 Jan Beulich <JBeulich@suse.com>: >>>> On 16.09.11 at 02:46, Haitao Shan <maillists.shan@gmail.com> wrote: >> Hi, Keir, >> >> The patch will fix XSave CPUID virtualization for PV guests. The XSave >> area size returned by CPUID leaf D is changed dynamically depending on >> the XCR0. Tools/libxc only assigns a static value. The fix will adjust >> xsave area size during runtime. >> >> Note: This fix is already in HVM cpuid virtualization. And Dom0 is not >> affected, either. >> >> Signed-off-by: =A0Shan Haitao <haitao.shan@intel.com> >> >> Shan Haitao >> >> diff -r 5fe770c8a8a3 xen/arch/x86/traps.c >> --- a/xen/arch/x86/traps.c =A0 =A0Tue Sep 06 15:49:40 2011 +0100 >> +++ b/xen/arch/x86/traps.c =A0 =A0Wed Sep 07 02:09:12 2011 +0800 >> @@ -770,6 +770,30 @@ static void pv_cpuid(struct cpu_user_reg >> =A0 =A0 =A0{ >> =A0 =A0 =A0 =A0 =A0if ( !cpuid_hypervisor_leaves(a, c, &a, &b, &c, &d) ) >> =A0 =A0 =A0 =A0 =A0 =A0 =A0domain_cpuid(current->domain, a, c, &a, &b, &= c, &d); >> + >> + =A0 =A0 =A0 =A0switch ( a ) >> + =A0 =A0 =A0 =A0{ >> + =A0 =A0 =A0 =A0case 0xd: >> + =A0 =A0 =A0 =A0{ >> + =A0 =A0 =A0 =A0 =A0 =A0unsigned int sub_leaf, _eax, _ebx, _ecx, _edx; >> + =A0 =A0 =A0 =A0 =A0 =A0/* EBX value of main leaf 0 depends on enabled = xsave features >> */ >> + =A0 =A0 =A0 =A0 =A0 =A0if ( c =3D=3D 0 && current->arch.xcr0 ) >> + =A0 =A0 =A0 =A0 =A0 =A0{ >> + =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0/* reset EBX to default value first */ >> + =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0b =3D XSTATE_AREA_MIN_SIZE; >> + =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0for ( sub_leaf =3D 2; sub_leaf < 64; su= b_leaf++ ) > > Shouldn't the upper bound be 63 here (as bit 63 serves a different > purpose, and if that bit was set code changes would be required in > various other places)? > > Jan Nice catch! I will update the patch. The same piece of code is borrowed from hvm_cpuid(), where I can change the value from 64 to 63, too. Shan Haitao > >> + =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0{ >> + =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0if ( !(current->arch.xcr0 & (1U= LL << sub_leaf)) ) >> + =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0continue; >> + =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0domain_cpuid(current->domain, a= , c, &_eax, &_ebx, &_ecx, >> + =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 &_edx)= ; >> + =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0if ( (_eax + _ebx) > b ) >> + =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0b =3D _eax + _ebx; >> + =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0} >> + =A0 =A0 =A0 =A0 =A0 =A0} >> + =A0 =A0 =A0 =A0break; >> + =A0 =A0 =A0 =A0} >> + =A0 =A0 =A0 =A0} >> =A0 =A0 =A0 =A0 =A0goto out; >> =A0 =A0 =A0} > > > > _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel From xen-devel-bounces@lists.xensource.com Sun Sep 18 03:34:13 2011 Return-path: <xen-devel-bounces@lists.xensource.com> Envelope-to: www-data@lists.xensource.com Delivery-date: Sun, 18 Sep 2011 03:34:13 -0700 Received: from localhost ([127.0.0.1] helo=lists.colo.xensource.com) by lists.xensource.com with esmtp (Exim 4.43) id 1R5EhR-0005rU-C5; Sun, 18 Sep 2011 03:34:13 -0700 Received: from mail21.messagelabs.com ([85.158.143.35]) by lists.xensource.com with esmtp (Exim 4.43) id 1R5Egy-0005fA-8L for xen-devel@lists.xensource.com; Sun, 18 Sep 2011 03:33:44 -0700 X-Env-Sender: burns.me.uk@gmail.com X-Msg-Ref: server-4.tower-21.messagelabs.com!1316341984!60642191!1 X-Originating-IP: [209.85.212.50] X-StarScan-Version: 6.4.1; banners=-,-,- X-VirusChecked: Checked Received: (qmail 17656 invoked from network); 18 Sep 2011 10:33:05 -0000 Received: from mail-vw0-f50.google.com (HELO mail-vw0-f50.google.com) (209.85.212.50) by server-4.tower-21.messagelabs.com with RC4-SHA encrypted SMTP; 18 Sep 2011 10:33:05 -0000 Received: by vws14 with SMTP id 14so8589830vws.23 for <xen-devel@lists.xensource.com>; Sun, 18 Sep 2011 03:33:39 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:content-type; bh=CIn7gymahCWbt0cru/ESFXtz4jL+VXmU0GnwZoyZzt0=; b=vOz/CkmkBEDUtSuyCFOMhCpmTEQQc5J23EXMfpjKMYYlGxq3qdAx1UBTBjC72zBVd8 bn0+0VFmBc5uD/NKEzwhb/cI27uyAOj/MvmiR6fSNBFRWGLR0YDzvkyfNqEJ8Ao9/HXW rJ+tgjx2zhvNoL+9skTa2X1pC93SF2BeSPlRY= MIME-Version: 1.0 Received: by 10.52.66.70 with SMTP id d6mr1053903vdt.351.1316342019810; Sun, 18 Sep 2011 03:33:39 -0700 (PDT) Received: by 10.52.185.35 with HTTP; Sun, 18 Sep 2011 03:33:39 -0700 (PDT) In-Reply-To: <CAE1-PRdQ37dg6BX+1JGA2mvviNu8t-iAZHVoDKrvg53H_jyztw@mail.gmail.com> References: <201107231426.56811.jim_burn@bellsouth.net> <1342436.B0x3ddQn4U@dell4550> <20110913085559.GG12984@reaktio.net> <1856036.eYCcuDQrZC@dell4550> <20110914090806.GD25628@phenom.oracle.com> <20110914105711.GA16284@phenom.oracle.com> <CAE1-PRfFwJh1WotLL5GD+L=Vn-zwZctqa+Rhzs2tqMavw1j-WQ@mail.gmail.com> <CAE1-PRdQ37dg6BX+1JGA2mvviNu8t-iAZHVoDKrvg53H_jyztw@mail.gmail.com> Date: Sun, 18 Sep 2011 11:33:39 +0100 X-Google-Sender-Auth: seZ2sOmRHMKL00maYo-zcQkqGyk Message-ID: <CAE1-PRfGqKQ226qXmhV-rxmJdtZ-brH-ozaeJd18ozP-R-NcrA@mail.gmail.com> Subject: Re: [Xen-devel] Re: [Xen-users] Continuing BUG:-iness booting Fedora Rawhide 3.1.0-rc's (was Summary: Experiences setting up a debug serial port) From: Andy Burns <xen.lists@burns.me.uk> To: xen-devel@lists.xensource.com, m.a.young@durham.ac.uk Content-Type: text/plain; charset=ISO-8859-1 Cc: X-BeenThere: xen-devel@lists.xensource.com X-Mailman-Version: 2.1.5 Precedence: list List-Id: Xen developer discussion <xen-devel.lists.xensource.com> List-Unsubscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe> List-Post: <mailto:xen-devel@lists.xensource.com> List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help> List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=subscribe> Sender: xen-devel-bounces@lists.xensource.com Errors-To: xen-devel-bounces@lists.xensource.com On 18 September 2011 09:08, Andy Burns <xen.lists@burns.me.uk> wrote: > I upgraded to 3.1.0-rc6, then booted to baremetal (didn't want > bugchecks during the build to corrupt the kernel I was building) > > Instaleld kernel source and development tools, hacked the spec file to > tweak the buildid and insert Patch and ApplyPatch lines for your mutex > instead of spinlock patch, built the kernel, installed and booted the > resulting 3.1.0-rc6.andy kernel as baremetal to make sure it was OK, > which it was, then booted it under Xen, unfortunately it crashes ... Doh! I realised I hadn't checked the stock FC16 3.1.0-rc6 kernel as dom0, booted it under Xen and it crahes in exactly the same way, so it wan't Konrad's mutex patch that did it at all, I'll revert to rc5 and try your patch on that, meanhile I've logged a bug https://bugzilla.redhat.com/show_bug.cgi?id=739372 _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel From xen-devel-bounces@lists.xensource.com Sun Sep 18 03:47:29 2011 Return-path: <xen-devel-bounces@lists.xensource.com> Envelope-to: www-data@lists.xensource.com Delivery-date: Sun, 18 Sep 2011 03:47:29 -0700 Received: from localhost ([127.0.0.1] helo=lists.colo.xensource.com) by lists.xensource.com with esmtp (Exim 4.43) id 1R5EuG-0006Vj-Un; Sun, 18 Sep 2011 03:47:29 -0700 Received: from mail27.messagelabs.com ([193.109.254.147]) by lists.xensource.com with esmtp (Exim 4.43) id 1R5EtK-0006Ho-VP for xen-devel@lists.xensource.com; Sun, 18 Sep 2011 03:46:31 -0700 X-Env-Sender: burns.me.uk@gmail.com X-Msg-Ref: server-7.tower-27.messagelabs.com!1316342764!49120291!1 X-Originating-IP: [209.85.212.50] X-StarScan-Version: 6.4.1; banners=-,-,- X-VirusChecked: Checked Received: (qmail 11575 invoked from network); 18 Sep 2011 10:46:05 -0000 Received: from mail-vw0-f50.google.com (HELO mail-vw0-f50.google.com) (209.85.212.50) by server-7.tower-27.messagelabs.com with RC4-SHA encrypted SMTP; 18 Sep 2011 10:46:05 -0000 Received: by vws14 with SMTP id 14so8597865vws.23 for <xen-devel@lists.xensource.com>; Sun, 18 Sep 2011 03:46:26 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:content-type; bh=COc3w5Kd0x6VvDTxVxK+Zi5IhsJoVSR2hRW18K2ysCE=; b=RvKHQoLEswzZQnFdAUnfyyL4hpf5HYvSI3bgTb+ao2yA/GBecS5Uz2pwEzdpIvvEVJ UxdJhCHs4Afa42dOIDYtA5Pf7zMisFeLObcNSAH9zEuyUU5CRiEfCeg2DoLb88xLgo7A rdVE+a/cXTS7Jjb0sxeBMhpQ1HOhGouE1ZPHY= MIME-Version: 1.0 Received: by 10.52.66.70 with SMTP id d6mr1060386vdt.351.1316342786800; Sun, 18 Sep 2011 03:46:26 -0700 (PDT) Received: by 10.52.185.35 with HTTP; Sun, 18 Sep 2011 03:46:26 -0700 (PDT) In-Reply-To: <CAE1-PRfGqKQ226qXmhV-rxmJdtZ-brH-ozaeJd18ozP-R-NcrA@mail.gmail.com> References: <201107231426.56811.jim_burn@bellsouth.net> <1342436.B0x3ddQn4U@dell4550> <20110913085559.GG12984@reaktio.net> <1856036.eYCcuDQrZC@dell4550> <20110914090806.GD25628@phenom.oracle.com> <20110914105711.GA16284@phenom.oracle.com> <CAE1-PRfFwJh1WotLL5GD+L=Vn-zwZctqa+Rhzs2tqMavw1j-WQ@mail.gmail.com> <CAE1-PRdQ37dg6BX+1JGA2mvviNu8t-iAZHVoDKrvg53H_jyztw@mail.gmail.com> <CAE1-PRfGqKQ226qXmhV-rxmJdtZ-brH-ozaeJd18ozP-R-NcrA@mail.gmail.com> Date: Sun, 18 Sep 2011 11:46:26 +0100 X-Google-Sender-Auth: gK6gkbSWm0_MjYCY9P-shAfcmxQ Message-ID: <CAE1-PRc7KzqK3fi2RR5+sihSmbfQWGqwW948PiFG2OMv-BAqEg@mail.gmail.com> Subject: Re: [Xen-devel] Re: [Xen-users] Continuing BUG:-iness booting Fedora Rawhide 3.1.0-rc's (was Summary: Experiences setting up a debug serial port) From: Andy Burns <xen.lists@burns.me.uk> To: xen-devel@lists.xensource.com, m.a.young@durham.ac.uk Content-Type: text/plain; charset=ISO-8859-1 Cc: X-BeenThere: xen-devel@lists.xensource.com X-Mailman-Version: 2.1.5 Precedence: list List-Id: Xen developer discussion <xen-devel.lists.xensource.com> List-Unsubscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe> List-Post: <mailto:xen-devel@lists.xensource.com> List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help> List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=subscribe> Sender: xen-devel-bounces@lists.xensource.com Errors-To: xen-devel-bounces@lists.xensource.com On 18 September 2011 11:33, Andy Burns <xen.lists@burns.me.uk> wrote: > I'll revert to rc5 and try your patch on that Oh dear, -rc5 rpm and srpm have been flushed from the mirrors, so I'm stumped for now :-( _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel From xen-devel-bounces@lists.xensource.com Sun Sep 18 07:04:15 2011 Return-path: <xen-devel-bounces@lists.xensource.com> Envelope-to: www-data@lists.xensource.com Delivery-date: Sun, 18 Sep 2011 07:04:15 -0700 Received: from localhost ([127.0.0.1] helo=lists.colo.xensource.com) by lists.xensource.com with esmtp (Exim 4.43) id 1R5Hyg-0003P2-Ck; Sun, 18 Sep 2011 07:04:14 -0700 Received: from mail27.messagelabs.com ([193.109.254.147]) by lists.xensource.com with esmtp (Exim 4.43) id 1R5Hxn-0003Ca-QC for xen-devel@lists.xensource.com; Sun, 18 Sep 2011 07:03:20 -0700 X-Env-Sender: burns.me.uk@gmail.com X-Msg-Ref: server-11.tower-27.messagelabs.com!1316354588!37890881!1 X-Originating-IP: [209.85.212.50] X-StarScan-Version: 6.4.1; banners=-,-,- X-VirusChecked: Checked Received: (qmail 9529 invoked from network); 18 Sep 2011 14:03:08 -0000 Received: from mail-vw0-f50.google.com (HELO mail-vw0-f50.google.com) (209.85.212.50) by server-11.tower-27.messagelabs.com with RC4-SHA encrypted SMTP; 18 Sep 2011 14:03:08 -0000 Received: by vws14 with SMTP id 14so8730512vws.23 for <xen-devel@lists.xensource.com>; Sun, 18 Sep 2011 07:03:15 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:content-type; bh=lbByWsXY69aN4Atgz7xhOrk5vyWmdyez59KDcL5yK5Y=; b=Zc8J+0Mz6e/HFkzEUbvtm1LvIu2BTG2J4Xs9cTwCbSQOctYJPpQH6il7m0n/U0m1HK EC7TpeA8qwdk8XjC7A3u5hdosEFcncBJ2VI41D7S6aatXdd4ms7eNkQpnabn+LwYSUpn G9Y/Zfxx2RL2Uz4CagckzCRymW8iMt897yJGY= MIME-Version: 1.0 Received: by 10.52.23.84 with SMTP id k20mr1222416vdf.83.1316354595592; Sun, 18 Sep 2011 07:03:15 -0700 (PDT) Received: by 10.52.185.35 with HTTP; Sun, 18 Sep 2011 07:03:15 -0700 (PDT) In-Reply-To: <CAE1-PRc7KzqK3fi2RR5+sihSmbfQWGqwW948PiFG2OMv-BAqEg@mail.gmail.com> References: <201107231426.56811.jim_burn@bellsouth.net> <1342436.B0x3ddQn4U@dell4550> <20110913085559.GG12984@reaktio.net> <1856036.eYCcuDQrZC@dell4550> <20110914090806.GD25628@phenom.oracle.com> <20110914105711.GA16284@phenom.oracle.com> <CAE1-PRfFwJh1WotLL5GD+L=Vn-zwZctqa+Rhzs2tqMavw1j-WQ@mail.gmail.com> <CAE1-PRdQ37dg6BX+1JGA2mvviNu8t-iAZHVoDKrvg53H_jyztw@mail.gmail.com> <CAE1-PRfGqKQ226qXmhV-rxmJdtZ-brH-ozaeJd18ozP-R-NcrA@mail.gmail.com> <CAE1-PRc7KzqK3fi2RR5+sihSmbfQWGqwW948PiFG2OMv-BAqEg@mail.gmail.com> Date: Sun, 18 Sep 2011 15:03:15 +0100 X-Google-Sender-Auth: Dw8aN4MMc_Wc5mitEZNzOgjkUXg Message-ID: <CAE1-PRfTnJRaQNU8JfU9fMFRcSfvc5tWsHHpC+ybAmnb9z=YQQ@mail.gmail.com> Subject: Re: [Xen-devel] Re: [Xen-users] Continuing BUG:-iness booting Fedora Rawhide 3.1.0-rc's (was Summary: Experiences setting up a debug serial port) From: Andy Burns <xen.lists@burns.me.uk> To: xen-devel@lists.xensource.com, m.a.young@durham.ac.uk Content-Type: text/plain; charset=ISO-8859-1 Cc: X-BeenThere: xen-devel@lists.xensource.com X-Mailman-Version: 2.1.5 Precedence: list List-Id: Xen developer discussion <xen-devel.lists.xensource.com> List-Unsubscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe> List-Post: <mailto:xen-devel@lists.xensource.com> List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help> List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=subscribe> Sender: xen-devel-bounces@lists.xensource.com Errors-To: xen-devel-bounces@lists.xensource.com On 18 September 2011 11:46, Andy Burns <xen.lists@burns.me.uk> wrote: > rc5 rpm and srpm have been flushed from the mirrors Remembered I could download the SRPM from koji, did that, built a 3.1.0-rc5 kernel including the mutex patch and can confirm it boots cleanly as dom0, no errors from xen or kernel to serial console, I haven't started any domUs yet... _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel From xen-devel-bounces@lists.xensource.com Sun Sep 18 07:41:13 2011 Return-path: <xen-devel-bounces@lists.xensource.com> Envelope-to: www-data@lists.xensource.com Delivery-date: Sun, 18 Sep 2011 07:41:13 -0700 Received: from localhost ([127.0.0.1] helo=lists.colo.xensource.com) by lists.xensource.com with esmtp (Exim 4.43) id 1R5IYT-0004QG-50; Sun, 18 Sep 2011 07:41:13 -0700 Received: from mail27.messagelabs.com ([193.109.254.147]) by lists.xensource.com with esmtp (Exim 4.43) id 1R5IXe-0004CA-Tn for Xen-devel@lists.xensource.com; Sun, 18 Sep 2011 07:40:23 -0700 X-Env-Sender: pracshi@gmail.com X-Msg-Ref: server-11.tower-27.messagelabs.com!1316356811!37894716!1 X-Originating-IP: [209.85.214.43] X-StarScan-Version: 6.4.1; banners=-,-,- X-VirusChecked: Checked Received: (qmail 2303 invoked from network); 18 Sep 2011 14:40:11 -0000 Received: from mail-bw0-f43.google.com (HELO mail-bw0-f43.google.com) (209.85.214.43) by server-11.tower-27.messagelabs.com with RC4-SHA encrypted SMTP; 18 Sep 2011 14:40:11 -0000 Received: by bkas6 with SMTP id s6so6306058bka.30 for <Xen-devel@lists.xensource.com>; Sun, 18 Sep 2011 07:40:19 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:date:message-id:subject:from:to:content-type; bh=zuUzorkYpfawpmRq3uguoAkbYa49A+ZPwsIX6Cd+U3M=; b=kPE4dhECKFQVHyJ872S2z86uIV8O4hMd2AtztKfyvBBlv7rG+Q/+NrfHm4FynjrP7R DTBpRv0joqQ8VRN2KNk3usnIHQGy9wB+qolNYjTso4de7EdEKs5JFG0SD5MpUp6Mi7tJ SJCw4LD9nr2IteV1dnnyXA623YI1IqeCHcCW4= MIME-Version: 1.0 Received: by 10.204.146.9 with SMTP id f9mr926484bkv.385.1316356819366; Sun, 18 Sep 2011 07:40:19 -0700 (PDT) Received: by 10.205.36.2 with HTTP; Sun, 18 Sep 2011 07:40:19 -0700 (PDT) Date: Sun, 18 Sep 2011 07:40:19 -0700 Message-ID: <CAEAezkXkZHOX1bVw355AjOSzq373zBzdN5O7V3Q2SsO-fjUa+Q@mail.gmail.com> From: Pratik shinde <pracshi@gmail.com> To: Xen-devel@lists.xensource.com Cc: Subject: [Xen-devel] proposing an idea for my last year project X-BeenThere: xen-devel@lists.xensource.com X-Mailman-Version: 2.1.5 Precedence: list List-Id: Xen developer discussion <xen-devel.lists.xensource.com> List-Unsubscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe> List-Post: <mailto:xen-devel@lists.xensource.com> List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help> List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=subscribe> Content-Type: multipart/mixed; boundary="===============1462871567==" Sender: xen-devel-bounces@lists.xensource.com Errors-To: xen-devel-bounces@lists.xensource.com --===============1462871567== Content-Type: multipart/alternative; boundary=0015175d03029db22c04ad3834d2 --0015175d03029db22c04ad3834d2 Content-Type: text/plain; charset=ISO-8859-1 Sir, I have an idea for improving memory management of xen.I don't know whether it is implemented or not. There are many operating systems running on a VMM.So it may be the case that two or more OS are of same flavor e.g.(windows or Linux).so some components of these OSes can be shared among various domains. Idea is that if any page i know can be shared between domains and is already present in memory then same page is used rather than bringing it from hard disk.I read memory merging but they are bringing page in memory and then deciding the page duplication. I want to know whether above idea can be implemented or not --0015175d03029db22c04ad3834d2 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Sir,<br>=A0 I have an idea for improving memory management of xen.I don'= ;t know whether it is implemented or not.<br>=A0=A0 There are many operatin= g systems running on a VMM.So it may be the case that two or more OS are of= same flavor e.g.(windows or Linux).so some components of these OSes can be= shared among various domains.<br> =A0 Idea is that if any page i know can be shared between domains and is al= ready present in memory then same page is used rather than bringing it from= hard disk.I read memory merging but they are bringing page in memory and t= hen deciding the page duplication.<br> =A0I want to know whether above idea can be implemented or not<br> --0015175d03029db22c04ad3834d2-- --===============1462871567== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel --===============1462871567==-- From xen-devel-bounces@lists.xensource.com Sun Sep 18 07:54:52 2011 Return-path: <xen-devel-bounces@lists.xensource.com> Envelope-to: www-data@lists.xensource.com Delivery-date: Sun, 18 Sep 2011 07:54:52 -0700 Received: from localhost ([127.0.0.1] helo=lists.colo.xensource.com) by lists.xensource.com with esmtp (Exim 4.43) id 1R5Ilg-00052f-8m; Sun, 18 Sep 2011 07:54:52 -0700 Received: from mail27.messagelabs.com ([193.109.254.147]) by lists.xensource.com with smtp (Exim 4.43) id 1R5Ikl-0004q5-Hq for xen-devel@lists.xensource.com; Sun, 18 Sep 2011 07:53:55 -0700 X-Env-Sender: superymkxen@hotmail.com X-Msg-Ref: server-9.tower-27.messagelabs.com!1316357615!45008846!1 X-Originating-IP: [65.55.111.113] X-StarScan-Version: 6.4.1; banners=-,-,- X-VirusChecked: Checked Received: (qmail 8056 invoked from network); 18 Sep 2011 14:53:36 -0000 Received: from blu0-omc2-s38.blu0.hotmail.com (HELO blu0-omc2-s38.blu0.hotmail.com) (65.55.111.113) by server-9.tower-27.messagelabs.com with SMTP; 18 Sep 2011 14:53:36 -0000 Received: from BLU0-SMTP134 ([65.55.111.71]) by blu0-omc2-s38.blu0.hotmail.com with Microsoft SMTPSVC(6.0.3790.4675); Sun, 18 Sep 2011 07:53:51 -0700 X-Originating-IP: [218.193.189.139] X-Originating-Email: [superymkxen@hotmail.com] Message-ID: <BLU0-SMTP134CD29927F07F377EE2DDBA2080@phx.gbl> Received: from [218.193.189.139] ([218.193.189.139]) by BLU0-SMTP134.phx.gbl over TLS secured channel with Microsoft SMTPSVC(6.0.3790.4675); Sun, 18 Sep 2011 07:53:49 -0700 Date: Sun, 18 Sep 2011 22:53:32 +0800 From: Superymk <superymkxen@hotmail.com> User-Agent: Mozilla/5.0 (Windows NT 5.1; rv:6.0.2) Gecko/20110902 Thunderbird/6.0.2 MIME-Version: 1.0 To: xen-devel@lists.xensource.com Subject: Re: [Xen-devel] proposing an idea for my last year project References: <CAEAezkXkZHOX1bVw355AjOSzq373zBzdN5O7V3Q2SsO-fjUa+Q@mail.gmail.com> In-Reply-To: <CAEAezkXkZHOX1bVw355AjOSzq373zBzdN5O7V3Q2SsO-fjUa+Q@mail.gmail.com> X-OriginalArrivalTime: 18 Sep 2011 14:53:51.0090 (UTC) FILETIME=[C73AA520:01CC7612] X-BeenThere: xen-devel@lists.xensource.com X-Mailman-Version: 2.1.5 Precedence: list List-Id: Xen developer discussion <xen-devel.lists.xensource.com> List-Unsubscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe> List-Post: <mailto:xen-devel@lists.xensource.com> List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help> List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=subscribe> Content-Type: multipart/mixed; boundary="===============0428665733==" Sender: xen-devel-bounces@lists.xensource.com Errors-To: xen-devel-bounces@lists.xensource.com --===============0428665733== Content-Type: multipart/alternative; boundary="------------030102060501050301080607" --------------030102060501050301080607 Content-Type: text/plain; charset="ISO-8859-1"; format=flowed Content-Transfer-Encoding: 7bit google "Difference Engine Harnessing Memory Redundancy in Virtual Machines". hope this help. -Superymk On 9/18/2011 10:40 PM, Pratik shinde wrote: > Sir, > I have an idea for improving memory management of xen.I don't know > whether it is implemented or not. > There are many operating systems running on a VMM.So it may be the > case that two or more OS are of same flavor e.g.(windows or Linux).so > some components of these OSes can be shared among various domains. > Idea is that if any page i know can be shared between domains and is > already present in memory then same page is used rather than bringing > it from hard disk.I read memory merging but they are bringing page in > memory and then deciding the page duplication. > I want to know whether above idea can be implemented or not > > > _______________________________________________ > Xen-devel mailing list > Xen-devel@lists.xensource.com > http://lists.xensource.com/xen-devel --------------030102060501050301080607 Content-Type: text/html; charset="ISO-8859-1" Content-Transfer-Encoding: 7bit <html> <head> <meta content="text/html; charset=ISO-8859-1" http-equiv="Content-Type"> </head> <body bgcolor="#FFFFFF" text="#000000"> google "Difference Engine Harnessing Memory Redundancy in Virtual Machines". <br> <br> hope this help.<br> <br> -Superymk<br> <br> On 9/18/2011 10:40 PM, Pratik shinde wrote: <blockquote cite="mid:CAEAezkXkZHOX1bVw355AjOSzq373zBzdN5O7V3Q2SsO-fjUa+Q@mail.gmail.com" type="cite">Sir,<br>   I have an idea for improving memory management of xen.I don't know whether it is implemented or not.<br>    There are many operating systems running on a VMM.So it may be the case that two or more OS are of same flavor e.g.(windows or Linux).so some components of these OSes can be shared among various domains.<br>   Idea is that if any page i know can be shared between domains and is already present in memory then same page is used rather than bringing it from hard disk.I read memory merging but they are bringing page in memory and then deciding the page duplication.<br>  I want to know whether above idea can be implemented or not<br> <br> <fieldset class="mimeAttachmentHeader"></fieldset> <br> <pre wrap="">_______________________________________________ Xen-devel mailing list <a class="moz-txt-link-abbreviated" href="mailto:Xen-devel@lists.xensource.com">Xen-devel@lists.xensource.com</a> <a class="moz-txt-link-freetext" href="http://lists.xensource.com/xen-devel">http://lists.xensource.com/xen-devel</a> </pre> </blockquote> <br> </body> </html> --------------030102060501050301080607-- --===============0428665733== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel --===============0428665733==-- From xen-devel-bounces@lists.xensource.com Sun Sep 18 07:55:57 2011 Return-path: <xen-devel-bounces@lists.xensource.com> Envelope-to: www-data@lists.xensource.com Delivery-date: Sun, 18 Sep 2011 07:55:57 -0700 Received: from localhost ([127.0.0.1] helo=lists.colo.xensource.com) by lists.xensource.com with esmtp (Exim 4.43) id 1R5Imi-0005Po-UM; Sun, 18 Sep 2011 07:55:57 -0700 Received: from mail21.messagelabs.com ([85.158.143.35]) by lists.xensource.com with esmtp (Exim 4.43) id 1R5Ilp-00054c-7p for xen-devel@lists.xensource.com; Sun, 18 Sep 2011 07:55:02 -0700 X-Env-Sender: burns.me.uk@gmail.com X-Msg-Ref: server-9.tower-21.messagelabs.com!1316357653!48857087!1 X-Originating-IP: [209.85.212.50] X-StarScan-Version: 6.4.1; banners=-,-,- X-VirusChecked: Checked Received: (qmail 14475 invoked from network); 18 Sep 2011 14:54:14 -0000 Received: from mail-vw0-f50.google.com (HELO mail-vw0-f50.google.com) (209.85.212.50) by server-9.tower-21.messagelabs.com with RC4-SHA encrypted SMTP; 18 Sep 2011 14:54:14 -0000 Received: by vws14 with SMTP id 14so8767971vws.23 for <xen-devel@lists.xensource.com>; Sun, 18 Sep 2011 07:54:57 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:content-type; bh=O7MCOOwZji8MEoISxh/nm26pRv/9iq1ixJ1i0Yhd0vU=; b=ET8A0AiEZOC/33/PUuszFQlho/+PsSTOZcSPC3pfRCjD9HF6ajIReMyaUVw6CfJDoO qCyZjZKqI2ivuKYdGkAc/8W4P087VG7rrKacSqqkKgBC3xJOJc3wCeRLtWUIftELRUPX O+pg/MjlinvcfoKf8ib3CyhCYYFAdXOimWtww= MIME-Version: 1.0 Received: by 10.52.66.70 with SMTP id d6mr1203331vdt.351.1316357696934; Sun, 18 Sep 2011 07:54:56 -0700 (PDT) Received: by 10.52.185.35 with HTTP; Sun, 18 Sep 2011 07:54:56 -0700 (PDT) In-Reply-To: <CAE1-PRfTnJRaQNU8JfU9fMFRcSfvc5tWsHHpC+ybAmnb9z=YQQ@mail.gmail.com> References: <201107231426.56811.jim_burn@bellsouth.net> <1342436.B0x3ddQn4U@dell4550> <20110913085559.GG12984@reaktio.net> <1856036.eYCcuDQrZC@dell4550> <20110914090806.GD25628@phenom.oracle.com> <20110914105711.GA16284@phenom.oracle.com> <CAE1-PRfFwJh1WotLL5GD+L=Vn-zwZctqa+Rhzs2tqMavw1j-WQ@mail.gmail.com> <CAE1-PRdQ37dg6BX+1JGA2mvviNu8t-iAZHVoDKrvg53H_jyztw@mail.gmail.com> <CAE1-PRfGqKQ226qXmhV-rxmJdtZ-brH-ozaeJd18ozP-R-NcrA@mail.gmail.com> <CAE1-PRc7KzqK3fi2RR5+sihSmbfQWGqwW948PiFG2OMv-BAqEg@mail.gmail.com> <CAE1-PRfTnJRaQNU8JfU9fMFRcSfvc5tWsHHpC+ybAmnb9z=YQQ@mail.gmail.com> Date: Sun, 18 Sep 2011 15:54:56 +0100 X-Google-Sender-Auth: _JBVWyVQKTGsCuWyCdR-RAuy-lo Message-ID: <CAE1-PRdPGY1H+3wHqGSVXuvrz6ZN7nUvegxNENckBQ4H2zr1JQ@mail.gmail.com> Subject: Re: [Xen-devel] Re: [Xen-users] Continuing BUG:-iness booting Fedora Rawhide 3.1.0-rc's (was Summary: Experiences setting up a debug serial port) From: Andy Burns <xen.lists@burns.me.uk> To: xen-devel@lists.xensource.com Content-Type: text/plain; charset=ISO-8859-1 X-BeenThere: xen-devel@lists.xensource.com X-Mailman-Version: 2.1.5 Precedence: list List-Id: Xen developer discussion <xen-devel.lists.xensource.com> List-Unsubscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe> List-Post: <mailto:xen-devel@lists.xensource.com> List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help> List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=subscribe> Sender: xen-devel-bounces@lists.xensource.com Errors-To: xen-devel-bounces@lists.xensource.com On 18 September 2011 15:03, Andy Burns <xen.lists@burns.me.uk> wrote: > I haven't started any domUs yet... I can confirm I've started a pre-existing FC15 domU with PCI passthrough of two DVB-T tuners (and a Fireweire port which needs to be co-assigned due to sharing a common PCI bridge). It's been a long journey from FC8 to FC16, but it does feel *GOOD* to be running pvops xen, with an alpha fedora dom0 and a current fedora domU, thanks to everyone who worked hard to get to this point ... _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel From xen-devel-bounces@lists.xensource.com Sun Sep 18 08:06:58 2011 Return-path: <xen-devel-bounces@lists.xensource.com> Envelope-to: www-data@lists.xensource.com Delivery-date: Sun, 18 Sep 2011 08:06:58 -0700 Received: from localhost ([127.0.0.1] helo=lists.colo.xensource.com) by lists.xensource.com with esmtp (Exim 4.43) id 1R5IxN-00061J-PT; Sun, 18 Sep 2011 08:06:57 -0700 Received: from mail27.messagelabs.com ([193.109.254.147]) by lists.xensource.com with smtp (Exim 4.43) id 1R5IwF-0005ot-P2 for xen-devel@lists.xensource.com; Sun, 18 Sep 2011 08:05:48 -0700 X-Env-Sender: caker@theshore.net X-Msg-Ref: server-8.tower-27.messagelabs.com!1316358328!47078172!1 X-Originating-IP: [67.18.92.50] X-StarScan-Version: 6.4.1; banners=-,-,- X-VirusChecked: Checked Received: (qmail 1615 invoked from network); 18 Sep 2011 15:05:28 -0000 Received: from ns.theshore.net (HELO www.theshore.net) (67.18.92.50) by server-8.tower-27.messagelabs.com with SMTP; 18 Sep 2011 15:05:28 -0000 Received: from [192.168.200.102] (c-69-248-252-23.hsd1.nj.comcast.net [69.248.252.23]) by www.theshore.net (8.13.6/8.9.1) with ESMTP id p8IF5cfu021196; Sun, 18 Sep 2011 11:05:39 -0400 Subject: Re: [Xen-devel] Re: kernel BUG at mm/swapfile.c:2527! [was 3.0.0 Xen pv guest - BUG: Unable to handle] Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: "Christopher S. Aker" <caker@theshore.net> In-Reply-To: <4E724F64.5080103@theshore.net> Date: Sun, 18 Sep 2011 11:05:33 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: <CEE295A1-B386-4A2A-A16C-9AC29DE174E8@theshore.net> References: <9CAEB881-07FE-437C-8A6B-DB7B690CEABE@linode.com> <4E5BA49D.5060800@theshore.net> <20110829150734.GB24825@dumpdata.com> <1314704744.28989.2.camel@zakaz.uk.xensource.com> <4E5E9CDB.3070706@theshore.net> <20110906171319.GB29839@dumpdata.com> <4E6E2E11.1030602@theshore.net> <20110912161127.GB16100@oracle.com> <4E724ACD.1050207@theshore.net> <4E724F64.5080103@theshore.net> To: "Christopher S. Aker" <caker@theshore.net> X-Mailer: Apple Mail (2.1084) Cc: LKML <linux-kernel@vger.kernel.org>, Jeremy Fitzhardinge <jeremy@goop.org>, "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>, Ian Campbell <Ian.Campbell@citrix.com>, Konrad Rzeszutek Wilk <konrad.wilk@oracle.com> X-BeenThere: xen-devel@lists.xensource.com X-Mailman-Version: 2.1.5 Precedence: list List-Id: Xen developer discussion <xen-devel.lists.xensource.com> List-Unsubscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe> List-Post: <mailto:xen-devel@lists.xensource.com> List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help> List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=subscribe> Sender: xen-devel-bounces@lists.xensource.com Errors-To: xen-devel-bounces@lists.xensource.com We've discovered a way to reproduce this quite easily! Fire up a guest, = run eatmem with 1M and enough threads to not OOM. http://www.theshore.net/~caker/uml/patches/utils/eatmem.c On a 1G guest: ./eatmem 1M 900 -Chris _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel From xen-devel-bounces@lists.xensource.com Sun Sep 18 08:22:44 2011 Return-path: <xen-devel-bounces@lists.xensource.com> Envelope-to: www-data@lists.xensource.com Delivery-date: Sun, 18 Sep 2011 08:22:44 -0700 Received: from localhost ([127.0.0.1] helo=lists.colo.xensource.com) by lists.xensource.com with esmtp (Exim 4.43) id 1R5JCe-0006jC-3P; Sun, 18 Sep 2011 08:22:44 -0700 Received: from mail182.messagelabs.com ([85.158.139.83]) by lists.xensource.com with esmtp (Exim 4.43) id 1R5JBv-0006WS-4r for xen-devel@lists.xensource.com; Sun, 18 Sep 2011 08:21:59 -0700 X-Env-Sender: pracshi@gmail.com X-Msg-Ref: server-4.tower-182.messagelabs.com!1316359315!18790710!1 X-Originating-IP: [209.85.214.43] X-StarScan-Version: 6.4.1; banners=-,-,- X-VirusChecked: Checked Received: (qmail 27646 invoked from network); 18 Sep 2011 15:21:55 -0000 Received: from mail-bw0-f43.google.com (HELO mail-bw0-f43.google.com) (209.85.214.43) by server-4.tower-182.messagelabs.com with RC4-SHA encrypted SMTP; 18 Sep 2011 15:21:55 -0000 Received: by bkas6 with SMTP id s6so6329017bka.30 for <xen-devel@lists.xensource.com>; Sun, 18 Sep 2011 08:21:55 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:date:message-id:subject:from:to:content-type; bh=IOsE8PG6RwhrpTF2GRcmRz0ezSsxAcgzU0Ykzee/HCQ=; b=FC/zMDwk3RARd8IrCO5dRJ/aR92KMW06N/pYsuY04gRTZLSF3tOsT6pbAnniiI4Yoi 5msQ9N7wY74Wt76YexclFYxGTB594INtYfCbUJEgx7goNJKAl/VBBJswYioSYBQJAEU2 +yuZfc0UNsC2cYMEcg5ioAfKid/nIxLjWI3Uk= MIME-Version: 1.0 Received: by 10.204.146.9 with SMTP id f9mr945691bkv.385.1316359315434; Sun, 18 Sep 2011 08:21:55 -0700 (PDT) Received: by 10.205.36.2 with HTTP; Sun, 18 Sep 2011 08:21:55 -0700 (PDT) Date: Sun, 18 Sep 2011 08:21:55 -0700 Message-ID: <CAEAezkXxOy+660fA8sV=pQsZ7vkRO8bFMPGOns1N3zP1QzPTXg@mail.gmail.com> From: Pratik shinde <pracshi@gmail.com> To: xen-devel@lists.xensource.com Subject: [Xen-devel] credit scheduler X-BeenThere: xen-devel@lists.xensource.com X-Mailman-Version: 2.1.5 Precedence: list List-Id: Xen developer discussion <xen-devel.lists.xensource.com> List-Unsubscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe> List-Post: <mailto:xen-devel@lists.xensource.com> List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help> List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=subscribe> Content-Type: multipart/mixed; boundary="===============0167830376==" Sender: xen-devel-bounces@lists.xensource.com Errors-To: xen-devel-bounces@lists.xensource.com --===============0167830376== Content-Type: multipart/alternative; boundary=0015175d030264abfb04ad38c92c --0015175d030264abfb04ad38c92c Content-Type: text/plain; charset=ISO-8859-1 sir, thank you for replaying my mail i am reading xen credit scheduler but i am not getting how credit scheduler distribute the credits among virtual machines.or specifically how it decides the credit to be given.sorry sir,this would be an insane question but i was finding answer to this question since last two days. --0015175d030264abfb04ad38c92c Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable sir,<br>=A0thank you for replaying my mail<br>=A0=A0 i am reading xen credi= t scheduler but i am not getting how credit scheduler distribute the credit= s among virtual machines.or specifically how it decides the credit to be gi= ven.sorry sir,this would be an insane question but i was finding answer to = this question since last two days. <br> --0015175d030264abfb04ad38c92c-- --===============0167830376== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel --===============0167830376==-- From xen-devel-bounces@lists.xensource.com Sun Sep 18 12:25:26 2011 Return-path: <xen-devel-bounces@lists.xensource.com> Envelope-to: www-data@lists.xensource.com Delivery-date: Sun, 18 Sep 2011 12:25:26 -0700 Received: from localhost ([127.0.0.1] helo=lists.colo.xensource.com) by lists.xensource.com with esmtp (Exim 4.43) id 1R5MzV-00056v-Vv; Sun, 18 Sep 2011 12:25:26 -0700 Received: from mail174.messagelabs.com ([85.158.138.51]) by lists.xensource.com with esmtp (Exim 4.43) id 1R5Myq-0004uG-6p for xen-devel@lists.xensource.com; Sun, 18 Sep 2011 12:24:44 -0700 X-Env-Sender: sven.koehler@gmail.com X-Msg-Ref: server-15.tower-174.messagelabs.com!1316373881!25514499!1 X-Originating-IP: [209.85.161.43] X-StarScan-Version: 6.4.1; banners=-,-,- X-VirusChecked: Checked Received: (qmail 28479 invoked from network); 18 Sep 2011 19:24:41 -0000 Received: from mail-fx0-f43.google.com (HELO mail-fx0-f43.google.com) (209.85.161.43) by server-15.tower-174.messagelabs.com with RC4-SHA encrypted SMTP; 18 Sep 2011 19:24:41 -0000 Received: by fxh19 with SMTP id 19so4208591fxh.30 for <xen-devel@lists.xensource.com>; Sun, 18 Sep 2011 12:24:40 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:x-enigmail-version:content-type :content-transfer-encoding; bh=0vO0FsQmnjw2SuD5Hm085jwf4hM6jjUA3BGpt0sbYsE=; b=NYtfRQn+Z45efuVQCQgA9UvhteVRzJITqc0fx4iGY6dxgONlWjWEfmqdudilM6KEFy ZOMMP72nzz7vr9Khuo3zyXOklhIdkbHiepTwUS0COvQsDoK5pVmwD3r6whHry2urAOvU bCEqB9Hv79DAEnV/lTenOUQNar+bh8oXz4H18= Received: by 10.223.43.218 with SMTP id x26mr3634090fae.75.1316373880920; Sun, 18 Sep 2011 12:24:40 -0700 (PDT) Received: from [10.1.2.24] (31-18-61-177-dynip.superkabel.de. [31.18.61.177]) by mx.google.com with ESMTPS id b21sm7487435fab.8.2011.09.18.12.24.39 (version=SSLv3 cipher=OTHER); Sun, 18 Sep 2011 12:24:39 -0700 (PDT) Message-ID: <4E764607.80703@gmail.com> Date: Sun, 18 Sep 2011 21:27:03 +0200 From: =?ISO-8859-1?Q?Sven_K=F6hler?= <sven.koehler@gmail.com> User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:6.0) Gecko/20110918 Thunderbird/6.0 MIME-Version: 1.0 To: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com> References: <j4gp1v$oog$1@dough.gmane.org> <20110911002807.GA9989@oracle.com> <4E6C0473.8090905@gmail.com> <20110912150606.GC15778@oracle.com> In-Reply-To: <20110912150606.GC15778@oracle.com> X-Enigmail-Version: 1.3 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit Cc: xen-devel@lists.xensource.com Subject: [Xen-devel] Re: 3.0.4 and 3.1-rc4 based dom0 won't boot with acpi=off X-BeenThere: xen-devel@lists.xensource.com X-Mailman-Version: 2.1.5 Precedence: list List-Id: Xen developer discussion <xen-devel.lists.xensource.com> List-Unsubscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe> List-Post: <mailto:xen-devel@lists.xensource.com> List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help> List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=subscribe> Sender: xen-devel-bounces@lists.xensource.com Errors-To: xen-devel-bounces@lists.xensource.com Am 12.09.2011 17:06, schrieb Konrad Rzeszutek Wilk: > On Sun, Sep 11, 2011 at 02:44:35AM +0200, Sven Köhler wrote: >> Am 11.09.2011 02:28, schrieb Konrad Rzeszutek Wilk: >>> You might want to try some parameters on the Xen line to alter how >>> it is suppose to reboot. >>> >>> /* >>> * reboot=b[ios] | t[riple] | k[bd] | n[o] [, [w]arm | [c]old] >> >> Thanks for the list. >> I guess, both reboot=bios and reboot=b is accepted? >> BTW: "no" is missing in the list below. acpi is missing in the list >> above. And actually what's the source for list? > > Xen hypervisor source. I just did a quick search for 'reboot=' I checked the sources of Linux 3.1rc4 and he xen hypervisor (4.1.1). The code for reboot is almost the same. One tiny difference is that the code of xen sets the reset flag of the kbd controller 100 times, while Linux does that only 10 times: Xen: > for ( i = 0; i < 100; i++ ) > { > kb_wait(); > udelay(50); > outb(0xfe,0x64); /* pulse reset low */ > udelay(50); > } Linux: > for (i = 0; i < 10; i++) { > kb_wait(); > udelay(50); > outb(0xfe, 0x64); /* pulse reset low */ > udelay(50); > } Summing up, both Linux 3.1 and Xen 4.1 both do the following sequence by default: ACPI, KBD, ACPI, KBD, TRIPLE, KBD, TRIPLE, KBD, ... While each KBD stands for 10 (Linux) or 100 (Xen) times setting the kbd controller reset flag. I wonder why Xen does the kbd controller reset a hundred times. Maybe it's a left over from xen 3.x? Would you mind changing it from 100 to 10? Now taking a look at Xen 3.4.2, the default reboot sequence is a bit different. It's ACPI, KBD, ACPI, KBD, ACPI, KBD, ACPI, KBD, .... No triple fault reset attempts. _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel From xen-devel-bounces@lists.xensource.com Sun Sep 18 12:54:10 2011 Return-path: <xen-devel-bounces@lists.xensource.com> Envelope-to: www-data@lists.xensource.com Delivery-date: Sun, 18 Sep 2011 12:54:10 -0700 Received: from localhost ([127.0.0.1] helo=lists.colo.xensource.com) by lists.xensource.com with esmtp (Exim 4.43) id 1R5NRK-00062X-EY; Sun, 18 Sep 2011 12:54:10 -0700 Received: from mail182.messagelabs.com ([85.158.139.83]) by lists.xensource.com with esmtp (Exim 4.43) id 1R5NQk-0005qE-2Z for xen-devel@lists.xensource.com; Sun, 18 Sep 2011 12:53:34 -0700 X-Env-Sender: burns.me.uk@gmail.com X-Msg-Ref: server-15.tower-182.messagelabs.com!1316375609!17804669!1 X-Originating-IP: [209.85.212.50] X-StarScan-Version: 6.4.1; banners=-,-,- X-VirusChecked: Checked Received: (qmail 31826 invoked from network); 18 Sep 2011 19:53:30 -0000 Received: from mail-vw0-f50.google.com (HELO mail-vw0-f50.google.com) (209.85.212.50) by server-15.tower-182.messagelabs.com with RC4-SHA encrypted SMTP; 18 Sep 2011 19:53:30 -0000 Received: by vws14 with SMTP id 14so8991221vws.23 for <xen-devel@lists.xensource.com>; Sun, 18 Sep 2011 12:53:29 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:content-type; bh=7QNaFOqWJvQ6oIQFIJp6H7tQupPrWu78/RbyzHTYAh4=; b=GSm6UPgaYj6jX/h4JiuyqtBDeKrQW2xbMBNVZj1tmnmDZQaezJeSL0o7JIRB272eCz Yoc4KcokaiJlSEAaZ3UYlaGWbo3FKhQzmvFmpJT486stum19AHwge9oGvYC2oTBHhEle B70Mi2W9BZW9ayXFwr4bnYME98vRlfIkDZtsw= MIME-Version: 1.0 Received: by 10.52.95.145 with SMTP id dk17mr1262651vdb.217.1316375609354; Sun, 18 Sep 2011 12:53:29 -0700 (PDT) Received: by 10.52.185.35 with HTTP; Sun, 18 Sep 2011 12:53:29 -0700 (PDT) In-Reply-To: <20110916083533.GC884@phenom.oracle.com> References: <20110915154621.GA21580@phenom.oracle.com> <alpine.LFD.2.02.1109152224170.2506@vega2.dur.ac.uk> <20110916083533.GC884@phenom.oracle.com> Date: Sun, 18 Sep 2011 20:53:29 +0100 X-Google-Sender-Auth: TEz5kA5I4KzKwIrLgSeI2lqWbbg Message-ID: <CAE1-PRcO=7dBYxwJCq0L0Q6qcT=Nbnf4d2Sg3f=780MRxpKOaw@mail.gmail.com> Subject: Re: [Xen-devel] Re: F16, yum install xen, run grub2 or grubby as needed? From: Andy Burns <xen.lists@burns.me.uk> To: xen-devel@lists.xensource.com Content-Type: text/plain; charset=ISO-8859-1 X-BeenThere: xen-devel@lists.xensource.com X-Mailman-Version: 2.1.5 Precedence: list List-Id: Xen developer discussion <xen-devel.lists.xensource.com> List-Unsubscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe> List-Post: <mailto:xen-devel@lists.xensource.com> List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help> List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=subscribe> Sender: xen-devel-bounces@lists.xensource.com Errors-To: xen-devel-bounces@lists.xensource.com On 16 September 2011 09:35, Konrad Rzeszutek Wilk <konrad.wilk@oracle.com> wrote: > On Thu, Sep 15, 2011 at 10:29:50PM +0100, M A Young wrote: >> On Thu, 15 Sep 2011, Konrad Rzeszutek Wilk wrote: >> >>> realized that I had to manually do: >>> grub2-mkconfig > /boot/grub2/grub.cfg Yes, I've been manually running that too, but the resuling grub.cfg file from when I manually regenerate it is subtly different from the grub.cfg generated after automatically installing a new kernel ... The one generated by manually running grub2-mkconfig creates a Xen submenu with all the various kernels under it, whereas after installing a new kernel, the one generated has all the xen + kernels in the top level menu. >> grub2 creates a >> set of entries for each of xen-4.1.1.gz and its two symbolic links >> xen-4.1.gz and xen.gz which is a bit untidy, so perhaps it makes >> sense to remove the symbolic links. I've submitted a bug with a patch to make the /etc/20_linux_xen helper script ignore the symbol files and symbolic links, if there's no need for the symbolic links the patch could be even simpler. https://bugzilla.redhat.com/show_bug.cgi?id=738085 _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel From xen-devel-bounces@lists.xensource.com Sun Sep 18 15:37:19 2011 Return-path: <xen-devel-bounces@lists.xensource.com> Envelope-to: www-data@lists.xensource.com Delivery-date: Sun, 18 Sep 2011 15:37:19 -0700 Received: from localhost ([127.0.0.1] helo=lists.colo.xensource.com) by lists.xensource.com with esmtp (Exim 4.43) id 1R5PzD-0004Ef-4l; Sun, 18 Sep 2011 15:37:19 -0700 Received: from mail216.messagelabs.com ([85.158.143.99]) by lists.xensource.com with smtp (Exim 4.43) id 1R5PyW-000420-FA for xen-devel@lists.xensource.com; Sun, 18 Sep 2011 15:36:36 -0700 X-Env-Sender: jonnyt@abpni.co.uk X-Msg-Ref: server-3.tower-216.messagelabs.com!1316385393!17688251!1 X-Originating-IP: [92.27.106.173] X-StarScan-Version: 6.4.1; banners=-,-,- X-VirusChecked: Checked Received: (qmail 8784 invoked from network); 18 Sep 2011 22:36:33 -0000 Received: from host-92-27-106-173.static.as13285.net (HELO abpni.co.uk) (92.27.106.173) by server-3.tower-216.messagelabs.com with SMTP; 18 Sep 2011 22:36:33 -0000 Received: from core2.abpni.local ([10.87.0.130]) by abpni.co.uk with Microsoft SMTPSVC(6.0.3790.3959); Sun, 18 Sep 2011 23:36:33 +0100 Message-ID: <4E76726F.8000003@abpni.co.uk> Date: Sun, 18 Sep 2011 23:36:31 +0100 From: Jonathan Tripathy <jonnyt@abpni.co.uk> User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:6.0.2) Gecko/20110902 Thunderbird/6.0.2 MIME-Version: 1.0 To: xen-devel@lists.xensource.com Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 18 Sep 2011 22:36:33.0264 (UTC) FILETIME=[6AC63700:01CC7653] Subject: [Xen-devel] Zero RAM xm destroy X-BeenThere: xen-devel@lists.xensource.com X-Mailman-Version: 2.1.5 Precedence: list List-Id: Xen developer discussion <xen-devel.lists.xensource.com> List-Unsubscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe> List-Post: <mailto:xen-devel@lists.xensource.com> List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help> List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=subscribe> Sender: xen-devel-bounces@lists.xensource.com Errors-To: xen-devel-bounces@lists.xensource.com Hi Everyone, I've just had a "eureka" moment on how to prevent (or make harder) "cold boot attacks". Am I correct in saying that when the admin issues "xm destroy <domID>" into the Dom0 shell, then 100% of the DomU ram is zero'ed immediately? If so, could one use this as a security measure, in case server room intrusion is detected? Thanks _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel From xen-devel-bounces@lists.xensource.com Sun Sep 18 18:56:26 2011 Return-path: <xen-devel-bounces@lists.xensource.com> Envelope-to: www-data@lists.xensource.com Delivery-date: Sun, 18 Sep 2011 18:56:26 -0700 Received: from localhost ([127.0.0.1] helo=lists.colo.xensource.com) by lists.xensource.com with esmtp (Exim 4.43) id 1R5T5u-0000DC-Cz; Sun, 18 Sep 2011 18:56:26 -0700 Received: from mail21.messagelabs.com ([85.158.143.35]) by lists.xensource.com with esmtp (Exim 4.43) id 1R5T4f-0008Rm-Vd; Sun, 18 Sep 2011 18:55:16 -0700 X-Env-Sender: hwang.jinho@gmail.com X-Msg-Ref: server-9.tower-21.messagelabs.com!1316397261!48889056!1 X-Originating-IP: [209.85.161.171] X-StarScan-Version: 6.4.1; banners=-,-,- X-VirusChecked: Checked Received: (qmail 9659 invoked from network); 19 Sep 2011 01:54:22 -0000 Received: from mail-gx0-f171.google.com (HELO mail-gx0-f171.google.com) (209.85.161.171) by server-9.tower-21.messagelabs.com with RC4-SHA encrypted SMTP; 19 Sep 2011 01:54:22 -0000 Received: by gxk22 with SMTP id 22so5950221gxk.30 for <multiple recipients>; Sun, 18 Sep 2011 18:55:05 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:from:date:message-id:subject:to:content-type; bh=8Fd7+aPIDF5Wv1iR2cZAUF0KtTTiwHJD/XS1q7dVaj0=; b=Seb1q7XoBwzAiObi4zbMk+mb9Q7o/S8o5fTV1avmYVNyLuPQNSt7QKpOFKCuPrXZJB pDNamUkj9GuFPEQOPgtSIMWdXRPg4VyQj7C/qjSl7bX43h1cICn3XfIcxt1WqVrz3iq5 tRPpq1xdfY9PWs0BV0ZOzqTKLkD7bs/uT5NI4= Received: by 10.150.239.5 with SMTP id m5mr1713932ybh.177.1316397305121; Sun, 18 Sep 2011 18:55:05 -0700 (PDT) MIME-Version: 1.0 Received: by 10.151.154.16 with HTTP; Sun, 18 Sep 2011 18:54:45 -0700 (PDT) From: jinho hwang <hwang.jinho@gmail.com> Date: Sun, 18 Sep 2011 21:54:45 -0400 Message-ID: <CAPQGAnESzhHjC+UutPk3Qoftx5v==11X1E-p+xjLprGXokj9tg@mail.gmail.com> To: xen-users@lists.xensource.com, xen-devel@lists.xensource.com Cc: Subject: [Xen-devel] DomU kernel panic due to run-init: /sbin/init: No such file or directory X-BeenThere: xen-devel@lists.xensource.com X-Mailman-Version: 2.1.5 Precedence: list List-Id: Xen developer discussion <xen-devel.lists.xensource.com> List-Unsubscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe> List-Post: <mailto:xen-devel@lists.xensource.com> List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help> List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=subscribe> Content-Type: multipart/mixed; boundary="===============1670861896==" Sender: xen-devel-bounces@lists.xensource.com Errors-To: xen-devel-bounces@lists.xensource.com --===============1670861896== Content-Type: multipart/alternative; boundary=000e0cd34c2cc14c1c04ad41a13e --000e0cd34c2cc14c1c04ad41a13e Content-Type: text/plain; charset=ISO-8859-1 Hi All, I'm using xen 4.0.1, kernel 2.6.32.46, and pygrub to boot. It seems that everything is ok until the last part that run-init is executing. The log says that run-init: /sbin/init: No such file or directory... and then kernel panic - not syncing: Attempted to kill init! I'm trying to figure out how to solve this problem. I mounted my image and checked the /sbin directory, init was there, but when I boot up with xm create, /sbin directory shows no init. Weirdly, the directory contains small number of files including modprobe. Please, give me any comment if you have. Thank you, Jinho Here is my log. --- Started domain Jinho (id=18) Reserving virtual address space above 0xf5800000 Initializing cgroup subsys cpuset Initializing cgroup subsys cpu Linux version 2.6.32.46 (root@jinho-Dell-DXP061) (gcc version 4.4.5 (Ubuntu/Linaro 4.4.5-15ubuntu1) ) #4 SMP Sun Sep 18 17:17:08 EDT 2011 KERNEL supported cpus: Intel GenuineIntel AMD AuthenticAMD NSC Geode by NSC Cyrix CyrixInstead Centaur CentaurHauls Transmeta GenuineTMx86 Transmeta TransmetaCPU UMC UMC UMC UMC ACPI in unprivileged domain disabled released 0 pages of unused memory BIOS-provided physical RAM map: Xen: 0000000000000000 - 00000000000a0000 (usable) Xen: 00000000000a0000 - 0000000000100000 (reserved) Xen: 0000000000100000 - 0000000020800000 (usable) DMI not present or invalid. last_pfn = 0x20800 max_arch_pfn = 0x1000000 init_memory_mapping: 0000000000000000-0000000020800000 NX (Execute Disable) protection: active RAMDISK: 00b2b000 - 09b5b000 0MB HIGHMEM available. 520MB LOWMEM available. mapped low ram: 0 - 20800000 low ram: 0 - 20800000 node 0 low ram: 00000000 - 20800000 node 0 bootmap 00007000 - 0000b100 (11 early reservations) ==> bootmem [0000000000 - 0020800000] #0 [0000000000 - 0000001000] BIOS data page ==> [0000000000 - 0000001000] #1 [0009bde000 - 0009c30000] XEN PAGETABLES ==> [0009bde000 - 0009c30000] #2 [0000001000 - 0000002000] EX TRAMPOLINE ==> [0000001000 - 0000002000] #3 [0000006000 - 0000007000] TRAMPOLINE ==> [0000006000 - 0000007000] #4 [0000400000 - 00009ba1c8] TEXT DATA BSS ==> [0000400000 - 00009ba1c8] #5 [0000b2b000 - 0009b5b000] RAMDISK ==> [0000b2b000 - 0009b5b000] #6 [0009b5b000 - 0009bde000] XEN START INFO ==> [0009b5b000 - 0009bde000] #7 [0020000000 - 0020800000] XEN EXTRA ==> [0020000000 - 0020800000] #8 [00009bb000 - 00009c8000] BRK ==> [00009bb000 - 00009c8000] #9 [0000100000 - 00001b1000] PGTABLE ==> [0000100000 - 00001b1000] #10 [0000007000 - 000000c000] BOOTMAP ==> [0000007000 - 000000c000] Zone PFN ranges: DMA 0x00000000 -> 0x00001000 Normal 0x00001000 -> 0x00020800 HighMem 0x00020800 -> 0x00020800 Movable zone start PFN for each node early_node_map[2] active PFN ranges 0: 0x00000000 -> 0x000000a0 0: 0x00000100 -> 0x00020800 Using APIC driver default SMP: Allowing 1 CPUs, 0 hotplug CPUs Local APIC disabled by BIOS -- you can enable it with "lapic" APIC: disable apic facility Allocating PCI resources starting at 20800000 (gap: 20800000:df800000) Booting paravirtualized kernel on Xen Xen version: 4.0.3-rc3-pre (preserve-AD) NR_CPUS:8 nr_cpumask_bits:8 nr_cpu_ids:1 nr_node_ids:1 PERCPU: Embedded 15 pages/cpu @ca045000 s40344 r0 d21096 u65536 pcpu-alloc: s40344 r0 d21096 u65536 alloc=16*4096 pcpu-alloc: [0] 0 Built 1 zonelists in Zone order, mobility grouping on. Total pages: 131984 Kernel command line: root=/dev/xvda2 ro root=/dev/xvda2 ro ip=:127.0.255.255::::eth0:dhcp PID hash table entries: 4096 (order: 2, 16384 bytes) Dentry cache hash table entries: 131072 (order: 7, 524288 bytes) Inode-cache hash table entries: 65536 (order: 6, 262144 bytes) Enabling fast FPU save and restore... done. Enabling unmasked SIMD FPU exception support... done. Initializing CPU#0 Initializing HighMem for node 0 (00000000:00000000) Memory: 363692k/532480k available (3083k kernel code, 168372k reserved, 1707k data, 472k init, 0k highmem) virtual kernel memory layout: fixmap : 0xf567e000 - 0xf57ff000 (1540 kB) pkmap : 0xf5200000 - 0xf5400000 (2048 kB) vmalloc : 0xe1000000 - 0xf51fe000 ( 321 MB) lowmem : 0xc0000000 - 0xe0800000 ( 520 MB) .init : 0xc08ae000 - 0xc0924000 ( 472 kB) .data : 0xc0702f46 - 0xc08add84 (1707 kB) .text : 0xc0400000 - 0xc0702f46 (3083 kB) Hierarchical RCU implementation. NR_IRQS:2304 nr_irqs:512 Console: colour dummy device 80x25 console [tty0] enabled console [hvc0] enabled installing Xen timer for CPU 0 Detected 2660.038 MHz processor. Calibrating delay loop (skipped), value calculated using timer frequency.. 5320.07 BogoMIPS (lpj=2660038) Security Framework initialized SELinux: Initializing. Mount-cache hash table entries: 512 Initializing cgroup subsys ns Initializing cgroup subsys cpuacct Initializing cgroup subsys devices CPU: L1 I cache: 32K, L1 D cache: 32K CPU: L2 cache: 4096K CPU: Unsupported number of siblings 2 Performance Events: unsupported p6 CPU model 15 no PMU driver, software events only. SMP alternatives: switching to UP code Freeing SMP alternatives: 14k freed cpu 0 spinlock event irq 510 Brought up 1 CPUs Grant table initialized Time: 165:165:165 Date: 165/165/65 NET: Registered protocol family 16 PCI: setting up Xen PCI frontend stub bio: create slab <bio-0> at 0 ACPI: Interpreter disabled. xen_balloon: Initialising balloon driver with page order 0. last_pfn = 0x20800 max_arch_pfn = 0x1000000 vgaarb: loaded SCSI subsystem initialized usbcore: registered new interface driver usbfs usbcore: registered new interface driver hub usbcore: registered new device driver usb PCI: System does not support PCI PCI: System does not support PCI NetLabel: Initializing NetLabel: domain hash size = 128 NetLabel: protocols = UNLABELED CIPSOv4 NetLabel: unlabeled traffic allowed by default Switching to clocksource xen pnp: PnP ACPI: disabled NET: Registered protocol family 2 IP route cache hash table entries: 8192 (order: 3, 32768 bytes) TCP established hash table entries: 32768 (order: 6, 262144 bytes) TCP bind hash table entries: 32768 (order: 6, 262144 bytes) TCP: Hash tables configured (established 32768 bind 32768) TCP reno registered NET: Registered protocol family 1 Trying to unpack rootfs image as initramfs... Freeing initrd memory: 147648k freed platform rtc_cmos: registered platform RTC device (no PNP device found) apm: BIOS not found. audit: initializing netlink socket (disabled) type=2000 audit(1316396556.247:1): initialized HugeTLB registered 2 MB page size, pre-allocated 0 pages VFS: Disk quotas dquot_6.5.2 Dquot-cache hash table entries: 1024 (order 0, 4096 bytes) msgmni has been set to 998 alg: No test for stdrng (krng) Block layer SCSI generic (bsg) driver version 0.4 loaded (major 252) io scheduler noop registered io scheduler anticipatory registered io scheduler deadline registered io scheduler cfq registered (default) pci_hotplug: PCI Hot Plug PCI Core version: 0.5 acpiphp: ACPI Hot Plug PCI Controller Driver version: 0.5 isapnp: ISA Plug & Play support disabled Event-channel device installed. registering netback Non-volatile memory driver v1.3 Linux agpgart interface v0.103 Serial: 8250/16550 driver, 4 ports, IRQ sharing enabled brd: module loaded loop: module loaded Initialising Xen virtual ethernet driver. blkfront: xvda2: barriers enabled (tag) ehci_hcd: USB 2.0 'Enhanced' Host Controller (EHCI) Driver ohci_hcd: USB 1.1 'Open' Host Controller (OHCI) Driver uhci_hcd: USB Universal Host Controller Interface driver PNP: No PS/2 controller found. Probing ports directly. i8042.c: No controller found. mice: PS/2 mouse device common for all mice rtc_cmos rtc_cmos: rtc core: registered rtc_cmos as rtc0 device-mapper: uevent: version 1.0.3 device-mapper: ioctl: 4.15.0-ioctl (2009-04-01) initialised: dm-devel@redhat.com cpuidle: using governor ladder cpuidle: using governor menu usbcore: registered new interface driver hiddev usbcore: registered new interface driver usbhid usbhid: v2.6:USB HID core driver nf_conntrack version 0.5.0 (8192 buckets, 32768 max) CONFIG_NF_CT_ACCT is deprecated and will be removed soon. Please use nf_conntrack.acct=1 kernel parameter, acct=1 nf_conntrack module option or sysctl net.netfilter.nf_conntrack_acct=1 to enable it. ip_tables: (C) 2000-2006 Netfilter Core Team TCP cubic registered Initializing XFRM netlink socket NET: Registered protocol family 17 Bridge firewalling registered Using IPI No-Shortcut mode registered taskstats version 1 blkfront: xvda1: barriers enabled (tag) XENBUS: Device with no driver: device/console/0 Magic number: 1:252:3141 Freeing unused kernel memory: 472k freed Write protecting the kernel text: 3084k Write protecting the kernel read-only data: 1480k Loading, please wait... mount: mounting none on /dev failed: No such device W: devtmpfs not available, falling back to tmpfs for /dev Begin: Loading essential drivers ... done. Begin: Running /scripts/init-premount ... done. Begin: Mounting root file system ... Begin: Running /scripts/local-top ... done. Begin: Running /scripts/local-premount ... done. kjournald starting. Commit interval 5 seconds EXT3-fs: mounted filesystem with writeback data mode. Begin: Running /scripts/local-bottom ... done. done. *Begin: Running /scripts/init-bottom ... done. run-init: /sbin/init: No such file or directory Kernel panic - not syncing: Attempted to kill init! Pid: 1, comm: run-init Not tainted 2.6.32.46 #4 Call Trace: [<c06fd11c>] ? printk+0xf/0x13 [<c06fd055>] panic+0x39/0xf1 [<c043ff7d>] do_exit+0x5c/0x5cf [<c04405c5>] complete_and_exit+0x0/0x17 [<c04098a9>] syscall_call+0x7/0xb* -- Jinho Hwang PhD Student Department of Computer Science The George Washington University Washington, DC 20052 hwang.jinho@gmail.com (email) 276.336.0971 (Cell) 202.994.4875 (fax) 070.8285.6546 (myLg070) --000e0cd34c2cc14c1c04ad41a13e Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable <br>Hi All, <br><br>I'm using xen 4.0.1, kernel 2.6.32.46, and pygrub t= o boot. It seems that everything is ok until the last part that run-init is= executing. The log says that run-init: /sbin/init: No such file or directo= ry... and then kernel panic - not syncing: Attempted to kill init! I'm = trying to figure out how to solve this problem. <br> I mounted my image and checked the /sbin directory, init was there, but whe= n I boot up with xm create, /sbin directory shows no init. Weirdly, the dir= ectory contains small number of files including modprobe. <br><br>Please, g= ive me any comment if you have. <br> <br>Thank you, <br><br>Jinho<br><br>Here is my log. <br>---<br>Started doma= in Jinho (id=3D18)<br>=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0= =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 Reserving virtual address space above 0xf580= 0000<br>Initializing cgroup subsys cpuset<br>Initializing cgroup subsys cpu= <br> Linux version 2.6.32.46 (root@jinho-Dell-DXP061) (gcc version 4.4.5 (Ubuntu= /Linaro 4.4.5-15ubuntu1) ) #4 SMP Sun Sep 18 17:17:08 EDT 2011<br>KERNEL su= pported cpus:<br>=A0 Intel GenuineIntel<br>=A0 AMD AuthenticAMD<br>=A0 NSC = Geode by NSC<br> =A0 Cyrix CyrixInstead<br>=A0 Centaur CentaurHauls<br>=A0 Transmeta Genuine= TMx86<br>=A0 Transmeta TransmetaCPU<br>=A0 UMC UMC UMC UMC<br>ACPI in unpri= vileged domain disabled<br>released 0 pages of unused memory<br>BIOS-provid= ed physical RAM map:<br> =A0Xen: 0000000000000000 - 00000000000a0000 (usable)<br>=A0Xen: 00000000000= a0000 - 0000000000100000 (reserved)<br>=A0Xen: 0000000000100000 - 000000002= 0800000 (usable)<br>DMI not present or invalid.<br>last_pfn =3D 0x20800 max= _arch_pfn =3D 0x1000000<br> init_memory_mapping: 0000000000000000-0000000020800000<br>NX (Execute Disab= le) protection: active<br>RAMDISK: 00b2b000 - 09b5b000<br>0MB HIGHMEM avail= able.<br>520MB LOWMEM available.<br>=A0 mapped low ram: 0 - 20800000<br> =A0 low ram: 0 - 20800000<br> =A0 node 0 low ram: 00000000 - 20800000<br>=A0 node 0 bootmap 00007000 - 00= 00b100<br>(11 early reservations) =3D=3D> bootmem [0000000000 - 00208000= 00]<br>=A0 #0 [0000000000 - 0000001000]=A0=A0 BIOS data page =3D=3D> [00= 00000000 - 0000001000]<br> =A0 #1 [0009bde000 - 0009c30000]=A0=A0 XEN PAGETABLES =3D=3D> [0009bde00= 0 - 0009c30000]<br>=A0 #2 [0000001000 - 0000002000]=A0=A0=A0 EX TRAMPOLINE = =3D=3D> [0000001000 - 0000002000]<br>=A0 #3 [0000006000 - 0000007000]=A0= =A0=A0=A0=A0=A0 TRAMPOLINE =3D=3D> [0000006000 - 0000007000]<br> =A0 #4 [0000400000 - 00009ba1c8]=A0=A0=A0 TEXT DATA BSS =3D=3D> [0000400= 000 - 00009ba1c8]<br>=A0 #5 [0000b2b000 - 0009b5b000]=A0=A0=A0=A0=A0=A0=A0= =A0=A0 RAMDISK =3D=3D> [0000b2b000 - 0009b5b000]<br>=A0 #6 [0009b5b000 -= 0009bde000]=A0=A0 XEN START INFO =3D=3D> [0009b5b000 - 0009bde000]<br> =A0 #7 [0020000000 - 0020800000]=A0=A0=A0=A0=A0=A0=A0 XEN EXTRA =3D=3D> = [0020000000 - 0020800000]<br>=A0 #8 [00009bb000 - 00009c8000]=A0=A0=A0=A0= =A0=A0=A0=A0=A0=A0=A0=A0=A0 BRK =3D=3D> [00009bb000 - 00009c8000]<br>=A0= #9 [0000100000 - 00001b1000]=A0=A0=A0=A0=A0=A0=A0=A0=A0 PGTABLE =3D=3D>= [0000100000 - 00001b1000]<br> =A0 #10 [0000007000 - 000000c000]=A0=A0=A0=A0=A0=A0=A0=A0=A0 BOOTMAP =3D=3D= > [0000007000 - 000000c000]<br>Zone PFN ranges:<br>=A0 DMA=A0=A0=A0=A0= =A0 0x00000000 -> 0x00001000<br>=A0 Normal=A0=A0 0x00001000 -> 0x0002= 0800<br>=A0 HighMem=A0 0x00020800 -> 0x00020800<br> Movable zone start PFN for each node<br>early_node_map[2] active PFN ranges= <br>=A0=A0=A0 0: 0x00000000 -> 0x000000a0<br>=A0=A0=A0 0: 0x00000100 -&g= t; 0x00020800<br>Using APIC driver default<br>SMP: Allowing 1 CPUs, 0 hotpl= ug CPUs<br> Local APIC disabled by BIOS -- you can enable it with "lapic"<br>= APIC: disable apic facility<br>Allocating PCI resources starting at 2080000= 0 (gap: 20800000:df800000)<br>Booting paravirtualized kernel on Xen<br> Xen version: 4.0.3-rc3-pre (preserve-AD)<br>NR_CPUS:8 nr_cpumask_bits:8 nr_= cpu_ids:1 nr_node_ids:1<br>PERCPU: Embedded 15 pages/cpu @ca045000 s40344 r= 0 d21096 u65536<br>pcpu-alloc: s40344 r0 d21096 u65536 alloc=3D16*4096<br> pcpu-alloc: [0] 0 <br>Built 1 zonelists in Zone order, mobility grouping on= .=A0 Total pages: 131984<br>Kernel command line: root=3D/dev/xvda2 ro root= =3D/dev/xvda2 ro ip=3D:127.0.255.255::::eth0:dhcp <br>PID hash table entrie= s: 4096 (order: 2, 16384 bytes)<br> Dentry cache hash table entries: 131072 (order: 7, 524288 bytes)<br>Inode-c= ache hash table entries: 65536 (order: 6, 262144 bytes)<br>Enabling fast FP= U save and restore... done.<br>Enabling unmasked SIMD FPU exception support= ... done.<br> Initializing CPU#0<br>Initializing HighMem for node 0 (00000000:00000000)<b= r>Memory: 363692k/532480k available (3083k kernel code, 168372k reserved, 1= 707k data, 472k init, 0k highmem)<br>virtual kernel memory layout:<br> =A0=A0=A0 fixmap=A0 : 0xf567e000 - 0xf57ff000=A0=A0 (1540 kB)<br> =A0=A0=A0 pkmap=A0=A0 : 0xf5200000 - 0xf5400000=A0=A0 (2048 kB)<br>=A0=A0= =A0 vmalloc : 0xe1000000 - 0xf51fe000=A0=A0 ( 321 MB)<br>=A0=A0=A0 lowmem= =A0 : 0xc0000000 - 0xe0800000=A0=A0 ( 520 MB)<br>=A0=A0=A0=A0=A0 .init : 0x= c08ae000 - 0xc0924000=A0=A0 ( 472 kB)<br>=A0=A0=A0=A0=A0 .data : 0xc0702f46= - 0xc08add84=A0=A0 (1707 kB)<br> =A0=A0=A0=A0=A0 .text : 0xc0400000 - 0xc0702f46=A0=A0 (3083 kB)<br>Hierarch= ical RCU implementation.<br>NR_IRQS:2304 nr_irqs:512<br>Console: colour dum= my device 80x25<br>console [tty0] enabled<br>console [hvc0] enabled<br>inst= alling Xen timer for CPU 0<br> Detected 2660.038 MHz processor.<br>Calibrating delay loop (skipped), value= calculated using timer frequency.. 5320.07 BogoMIPS (lpj=3D2660038)<br>Sec= urity Framework initialized<br>SELinux:=A0 Initializing.<br>Mount-cache has= h table entries: 512<br> Initializing cgroup subsys ns<br>Initializing cgroup subsys cpuacct<br>Init= ializing cgroup subsys devices<br>CPU: L1 I cache: 32K, L1 D cache: 32K<br>= CPU: L2 cache: 4096K<br>CPU: Unsupported number of siblings 2<br>Performanc= e Events: unsupported p6 CPU model 15 no PMU driver, software events only.<= br> SMP alternatives: switching to UP code<br>Freeing SMP alternatives: 14k fre= ed<br>cpu 0 spinlock event irq 510<br>Brought up 1 CPUs<br>Grant table init= ialized<br>Time: 165:165:165=A0 Date: 165/165/65<br>NET: Registered protoco= l family 16<br> PCI: setting up Xen PCI frontend stub<br>bio: create slab <bio-0> at = 0<br>ACPI: Interpreter disabled.<br>xen_balloon: Initialising balloon drive= r with page order 0.<br>last_pfn =3D 0x20800 max_arch_pfn =3D 0x1000000<br> vgaarb: loaded<br>SCSI subsystem initialized<br>usbcore: registered new int= erface driver usbfs<br>usbcore: registered new interface driver hub<br>usbc= ore: registered new device driver usb<br>PCI: System does not support PCI<b= r> PCI: System does not support PCI<br>NetLabel: Initializing<br>NetLabel:=A0 = domain hash size =3D 128<br>NetLabel:=A0 protocols =3D UNLABELED CIPSOv4<br= >NetLabel:=A0 unlabeled traffic allowed by default<br>Switching to clocksou= rce xen<br> pnp: PnP ACPI: disabled<br>NET: Registered protocol family 2<br>IP route ca= che hash table entries: 8192 (order: 3, 32768 bytes)<br>TCP established has= h table entries: 32768 (order: 6, 262144 bytes)<br>TCP bind hash table entr= ies: 32768 (order: 6, 262144 bytes)<br> TCP: Hash tables configured (established 32768 bind 32768)<br>TCP reno regi= stered<br>NET: Registered protocol family 1<br>Trying to unpack rootfs imag= e as initramfs...<br>Freeing initrd memory: 147648k freed<br>platform rtc_c= mos: registered platform RTC device (no PNP device found)<br> apm: BIOS not found.<br>audit: initializing netlink socket (disabled)<br>ty= pe=3D2000 audit(1316396556.247:1): initialized<br>HugeTLB registered 2 MB p= age size, pre-allocated 0 pages<br>VFS: Disk quotas dquot_6.5.2<br>Dquot-ca= che hash table entries: 1024 (order 0, 4096 bytes)<br> msgmni has been set to 998<br>alg: No test for stdrng (krng)<br>Block layer= SCSI generic (bsg) driver version 0.4 loaded (major 252)<br>io scheduler n= oop registered<br>io scheduler anticipatory registered<br>io scheduler dead= line registered<br> io scheduler cfq registered (default)<br>pci_hotplug: PCI Hot Plug PCI Core= version: 0.5<br>acpiphp: ACPI Hot Plug PCI Controller Driver version: 0.5<= br>isapnp: ISA Plug & Play support disabled<br>Event-channel device ins= talled.<br> registering netback<br>Non-volatile memory driver v1.3<br>Linux agpgart int= erface v0.103<br>Serial: 8250/16550 driver, 4 ports, IRQ sharing enabled<br= >brd: module loaded<br>loop: module loaded<br>Initialising Xen virtual ethe= rnet driver.<br> blkfront: xvda2: barriers enabled (tag)<br>ehci_hcd: USB 2.0 'Enhanced&= #39; Host Controller (EHCI) Driver<br>ohci_hcd: USB 1.1 'Open' Host= Controller (OHCI) Driver<br>uhci_hcd: USB Universal Host Controller Interf= ace driver<br> PNP: No PS/2 controller found. Probing ports directly.<br>i8042.c: No contr= oller found.<br>mice: PS/2 mouse device common for all mice<br>rtc_cmos rtc= _cmos: rtc core: registered rtc_cmos as rtc0<br>device-mapper: uevent: vers= ion 1.0.3<br> device-mapper: ioctl: 4.15.0-ioctl (2009-04-01) initialised: <a href=3D"mai= lto:dm-devel@redhat.com">dm-devel@redhat.com</a><br>cpuidle: using governor= ladder<br>cpuidle: using governor menu<br>usbcore: registered new interfac= e driver hiddev<br> usbcore: registered new interface driver usbhid<br>usbhid: v2.6:USB HID cor= e driver<br>nf_conntrack version 0.5.0 (8192 buckets, 32768 max)<br>CONFIG_= NF_CT_ACCT is deprecated and will be removed soon. Please use<br>nf_conntra= ck.acct=3D1 kernel parameter, acct=3D1 nf_conntrack module option or<br> sysctl net.netfilter.nf_conntrack_acct=3D1 to enable it.<br>ip_tables: (C) = 2000-2006 Netfilter Core Team<br>TCP cubic registered<br>Initializing XFRM = netlink socket<br>NET: Registered protocol family 17<br>Bridge firewalling = registered<br> Using IPI No-Shortcut mode<br>registered taskstats version 1<br>blkfront: x= vda1: barriers enabled (tag)<br>XENBUS: Device with no driver: device/conso= le/0<br>=A0 Magic number: 1:252:3141<br>Freeing unused kernel memory: 472k = freed<br> Write protecting the kernel text: 3084k<br>Write protecting the kernel read= -only data: 1480k<br>Loading, please wait...<br>mount: mounting none on /de= v failed: No such device<br>W: devtmpfs not available, falling back to tmpf= s for /dev<br> Begin: Loading essential drivers ... done.<br>Begin: Running /scripts/init-= premount ... done.<br>Begin: Mounting root file system ... Begin: Running /= scripts/local-top ... done.<br>Begin: Running /scripts/local-premount ... d= one.<br> kjournald starting.=A0 Commit interval 5 seconds<br>EXT3-fs: mounted filesy= stem with writeback data mode.<br>Begin: Running /scripts/local-bottom ... = done.<br>done.<br><b>Begin: Running /scripts/init-bottom ... done.<br>run-i= nit: /sbin/init: No such file or directory<br> Kernel panic - not syncing: Attempted to kill init!<br>Pid: 1, comm: run-in= it Not tainted 2.6.32.46 #4<br>Call Trace:<br>=A0[<c06fd11c>] ? print= k+0xf/0x13<br>=A0[<c06fd055>] panic+0x39/0xf1<br>=A0[<c043ff7d>= ] do_exit+0x5c/0x5cf<br> =A0[<c04405c5>] complete_and_exit+0x0/0x17<br>=A0[<c04098a9>] s= yscall_call+0x7/0xb</b><br><br clear=3D"all"><br>-- <br>Jinho Hwang<br>PhD = Student<br>Department of Computer Science<br>The George Washington Universi= ty<br> Washington, DC 20052<br><a href=3D"mailto:hwang.jinho@gmail.com">hwang.jinh= o@gmail.com</a> (email)<br>276.336.0971 (Cell)<br>202.994.4875 (fax)<br>070= .8285.6546 (myLg070)<br> --000e0cd34c2cc14c1c04ad41a13e-- --===============1670861896== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel --===============1670861896==-- From xen-devel-bounces@lists.xensource.com Mon Sep 19 00:18:53 2011 Return-path: <xen-devel-bounces@lists.xensource.com> Envelope-to: www-data@lists.xensource.com Delivery-date: Mon, 19 Sep 2011 00:18:53 -0700 Received: from localhost ([127.0.0.1] helo=lists.colo.xensource.com) by lists.xensource.com with esmtp (Exim 4.43) id 1R5Y7x-0008Ry-K1; Mon, 19 Sep 2011 00:18:53 -0700 Received: from mail182.messagelabs.com ([85.158.139.83]) by lists.xensource.com with esmtp (Exim 4.43) id 1R5Y7P-0008FU-3c for xen-devel@lists.xensource.com; Mon, 19 Sep 2011 00:18:19 -0700 X-Env-Sender: dushmanta.mohapatra@gmail.com X-Msg-Ref: server-8.tower-182.messagelabs.com!1316416694!18854379!1 X-Originating-IP: [209.85.216.178] X-StarScan-Version: 6.4.1; banners=-,-,- X-VirusChecked: Checked Received: (qmail 2004 invoked from network); 19 Sep 2011 07:18:15 -0000 Received: from mail-qy0-f178.google.com (HELO mail-qy0-f178.google.com) (209.85.216.178) by server-8.tower-182.messagelabs.com with RC4-SHA encrypted SMTP; 19 Sep 2011 07:18:15 -0000 Received: by qyg14 with SMTP id 14so6109730qyg.9 for <xen-devel@lists.xensource.com>; Mon, 19 Sep 2011 00:18:14 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :content-type; bh=UH3ufmgWnDBpbY+63SYM7P4ToREUlQzJfFKx41pXDbg=; b=mKzwVm5kR54wUKBb7L5FGMvqWdvZvzImMzh5+zGG1pxHxM42O/+LBf/4fZTAwv7Bkk wsfz9zWuYDVH2JA2LS0XEZwhvF2QR4DpSGO6yb1G2SRvAJ9vFMuZFa7DxW3z4K+3N16A kKN05HS7uUalPafShTEf/bLQe8bc7S4FOBCIo= MIME-Version: 1.0 Received: by 10.229.91.16 with SMTP id k16mr1736588qcm.104.1316416693463; Mon, 19 Sep 2011 00:18:13 -0700 (PDT) Received: by 10.229.50.70 with HTTP; Mon, 19 Sep 2011 00:18:13 -0700 (PDT) In-Reply-To: <CA+PhxFdtdKqTWA9rD3M6s8VS=WMaBV3oQuicV8JW5wCir=iHnA@mail.gmail.com> References: <CA+PhxFdtdKqTWA9rD3M6s8VS=WMaBV3oQuicV8JW5wCir=iHnA@mail.gmail.com> Date: Mon, 19 Sep 2011 03:18:13 -0400 Message-ID: <CA+PhxFepcRHQKczKwGeQLWR2QGx+UpqT1Sts3szSnjfQLVieAA@mail.gmail.com> From: Dushmanta Mohapatra <dushmanta.mohapatra@gmail.com> To: xen-devel@lists.xensource.com Subject: [Xen-devel] Re: Graphics passthrough related issue X-BeenThere: xen-devel@lists.xensource.com X-Mailman-Version: 2.1.5 Precedence: list List-Id: Xen developer discussion <xen-devel.lists.xensource.com> List-Unsubscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe> List-Post: <mailto:xen-devel@lists.xensource.com> List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help> List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=subscribe> Content-Type: multipart/mixed; boundary="===============0887059175==" Sender: xen-devel-bounces@lists.xensource.com Errors-To: xen-devel-bounces@lists.xensource.com --===============0887059175== Content-Type: multipart/alternative; boundary=001636aa2c1863e97104ad462563 --001636aa2c1863e97104ad462563 Content-Type: text/plain; charset=ISO-8859-1 I sent the following email a few days back, but did not get any response. I am still facing the issue. Could some one please tell me about what might be going wrong? Any pointers about how could I debug this issue? Thanks, Dushmanta On Tue, Sep 13, 2011 at 12:09 AM, Dushmanta Mohapatra < dushmanta.mohapatra@gmail.com> wrote: > Hi, > > I am facing an issue with enabling my graphics passthrough properly in Xen. > > I am using Xen 4.1.1 and 2.6.32.41 based PVOPS kernel as my Dom0. > Machine: core i5 vPro based Thinkpad T 520 laptop. > I use Windows 7 and XP as my HVM DomUs. > > I have an Intel Integrated Graphics Controller. > I can pass through the graphics device (using boot time passthrough) and > the HVM DomUs boot fine and show me the log in screen. > > But somehow I lose my control over input devices (mouse/keyboard). My > laptop has a PS/2 keypad and I do not know how to pass that through. So > instead, I plugin an external keyboard and mouse to the USB slots that are > available and pass them through to DomU. > > But those are not accessible when I boot my DomU in the graphics pass > through mode. (If I boot without graphics pass-through mode, > then I can pass external keyboard and mouse to the DomUs and they work > fine.) > > I have not applied any patch to the Xen 4.1.1 that I built from source > obtained from xen.org and I am not doing any manual device/memory region > mapping. I am not sure if I need any patch for the integrated graphics > driver that I use. > > Could any one provide me some input about what might be going wrong for me > and how I could solve the issue. I am including the lspci output for > reference. If some more information is needed from my side, please let me > know. > > Thanks > > > > For enabling graphics passthrough, I hide and passthrough the devices > highlighted. > > root@dm-ThinkPad-T520:~# lspci > 00:00.0 Host bridge: Intel Corporation 2nd Generation Core Processor Family > DRAM Controller (rev 09) > 00:02.0 VGA compatible controller: Intel Corporation 2nd Generation Core > Processor Family Integrated Graphics Controller (rev 09) > 00:16.0 Communication controller: Intel Corporation 6 Series Chipset Family > MEI Controller #1 (rev 04) > 00:16.3 Serial controller: Intel Corporation 6 Series Chipset Family KT > Controller (rev 04) > 00:19.0 Ethernet controller: Intel Corporation 82579LM Gigabit Network > Connection (rev 04) > 00:1a.0 USB Controller: Intel Corporation 6 Series Chipset Family USB > Enhanced Host Controller #2 (rev 04) > 00:1b.0 Audio device: Intel Corporation 6 Series Chipset Family High > Definition Audio Controller (rev 04) > 00:1c.0 PCI bridge: Intel Corporation 6 Series Chipset Family PCI Express > Root Port 1 (rev b4) > 00:1c.1 PCI bridge: Intel Corporation 6 Series Chipset Family PCI Express > Root Port 2 (rev b4) > 00:1c.3 PCI bridge: Intel Corporation 6 Series Chipset Family PCI Express > Root Port 4 (rev b4) > 00:1c.4 PCI bridge: Intel Corporation 6 Series Chipset Family PCI Express > Root Port 5 (rev b4) > 00:1d.0 USB Controller: Intel Corporation 6 Series Chipset Family USB > Enhanced Host Controller #1 (rev 04) > 00:1f.0 ISA bridge: Intel Corporation 6 Series Chipset Family LPC > Controller (rev 04) > 00:1f.2 SATA controller: Intel Corporation 6 Series Chipset Family 6 port > SATA AHCI Controller (rev 04) > 00:1f.3 SMBus: Intel Corporation 6 Series Chipset Family SMBus Controller > (rev 04) > 03:00.0 Network controller: Intel Corporation Centrino Advanced-N 6205 (rev > 34) > 0d:00.0 System peripheral: Ricoh Co Ltd Device e823 (rev 05) > 0d:00.3 FireWire (IEEE 1394): Ricoh Co Ltd FireWire Host Controller (rev > 04) > > > --001636aa2c1863e97104ad462563 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable I sent the following email a few days back, but did not get any response.<d= iv><br></div><div>I am still facing the issue. Could some one please tell m= e about what might be going wrong?</div><div><br></div><div>Any pointers ab= out how could I debug this issue?</div> <div><br></div><div>Thanks,</div><div>Dushmanta</div><div><br><div class=3D= "gmail_quote">On Tue, Sep 13, 2011 at 12:09 AM, Dushmanta Mohapatra <span d= ir=3D"ltr"><<a href=3D"mailto:dushmanta.mohapatra@gmail.com">dushmanta.m= ohapatra@gmail.com</a>></span> wrote:<br> <blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1p= x #ccc solid;padding-left:1ex;"><div>Hi,<br></div> <div>=A0</div>I am facing an issue with enabling my graphics passthrough=20 properly in Xen.<br><br><div>I am using =A0Xen 4.1.1 and 2.6.32.41 based PV= OPS kernel as my Dom0.<br>Machine:=A0core i5 vPro based Thinkpad T 520 lapt= op.=A0</div> <div>I use Windows 7 and XP as my HVM DomUs.<br></div><div><br></div><div>I= have an Intel Integrated Graphics Controller.</div> <div>I can pass through the graphics device (using boot time passthrough) a= nd the HVM DomUs boot fine and show me the log in screen.</div><div><br></d= iv> <div>But somehow I=A0 lose my control over input devices (mouse/keyboard). = My laptop has a PS/2 keypad and I do not know how to pass that through. So = instead, I plugin an external keyboard and mouse to the USB slots that are = available and pass them through to DomU.</div> <div><br></div><div>But those are not accessible when I boot my DomU in the graphics pass=20 through mode. (If I boot without graphics pass-through mode,</div> <div>then I can pass external keyboard and mouse to the DomUs and they work= fine.)</div><div><br></div><div>I have not applied any patch to the Xen 4.= 1.1 that I built from source obtained from <a href=3D"http://xen.org/" targ= et=3D"_blank">xen.org</a> and I am not doing any manual device/memory region mapping. I am not=20 sure if I need any patch for the integrated graphics driver that I use.</di= v> <div><br></div><div>Could any one provide me some input about what might be= going wrong for me and how I could solve the issue. I am including the lsp= ci output for reference. If some more information is needed from my side, p= lease let me know.<br> </div><div><br></div><div>Thanks<br><br><br></div><br><span style=3D"backgr= ound-color:rgb(204, 153, 51);color:rgb(0, 0, 0)">For enabling graphics pass= through, I hide and passthrough the devices </span><span style=3D"color:rgb= (0, 0, 0)"><span style=3D"background-color:rgb(204, 153, 51)">highlighted</= span>.</span><br> <span><span style=3D"background-color:rgb(204, 153, 51)"></span></span><br>= root@dm-ThinkPad-T520:~# lspci<br>00:00.0 Host bridge: Intel Corporation 2n= d Generation Core Processor Family DRAM Controller (rev 09)<br> <span style=3D"background-color:rgb(255, 255, 0)">00:02.0 VGA compatible=20 controller: Intel Corporation 2nd Generation Core Processor Family=20 Integrated Graphics Controller (rev 09)</span><br style=3D"background-color= :rgb(255, 255, 0)"> 00:16.0 Communication controller: Intel Corporation 6 Series Chipset Family= MEI Controller #1 (rev 04)<br>00:16.3 Serial controller: Intel Corporation= 6 Series Chipset Family KT Controller (rev 04)<br>00:19.0 Ethernet control= ler: Intel Corporation 82579LM Gigabit Network Connection (rev 04)<br> <span style=3D"background-color:rgb(255, 255, 0)">00:1a.0 USB Controller: I= ntel Corporation 6 Series Chipset Family USB Enhanced Host Controller #2 (r= ev 04)</span><br style=3D"background-color:rgb(255, 255, 0)">00:1b.0 Audio = device: Intel Corporation 6 Series Chipset Family High Definition Audio Con= troller (rev 04)<br> 00:1c.0 PCI bridge: Intel Corporation 6 Series Chipset Family PCI Express R= oot Port 1 (rev b4)<br>00:1c.1 PCI bridge: Intel Corporation 6 Series Chips= et Family PCI Express Root Port 2 (rev b4)<br>00:1c.3 PCI bridge: Intel Cor= poration 6 Series Chipset Family PCI Express Root Port 4 (rev b4)<br> 00:1c.4 PCI bridge: Intel Corporation 6 Series Chipset Family PCI Express R= oot Port 5 (rev b4)<br><span style=3D"background-color:rgb(255, 255, 0)">00= :1d.0 USB Controller: Intel Corporation 6 Series Chipset Family USB Enhance= d Host Controller #1 (rev 04)</span><br style=3D"background-color:rgb(255, = 255, 0)"> 00:1f.0 ISA bridge: Intel Corporation 6 Series Chipset Family LPC Controlle= r (rev 04)<br>00:1f.2 SATA controller: Intel Corporation 6 Series Chipset F= amily 6 port SATA AHCI Controller (rev 04)<br>00:1f.3 SMBus: Intel Corporat= ion 6 Series Chipset Family SMBus Controller (rev 04)<br> 03:00.0 Network controller: Intel Corporation Centrino Advanced-N 6205 (rev= 34)<br>0d:00.0 System peripheral: Ricoh Co Ltd Device e823 (rev 05)<br>0d:= 00.3 FireWire (IEEE 1394): Ricoh Co Ltd FireWire Host Controller (rev 04)<b= r> <br><br> </blockquote></div><br></div> --001636aa2c1863e97104ad462563-- --===============0887059175== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel --===============0887059175==-- From xen-devel-bounces@lists.xensource.com Mon Sep 19 02:29:46 2011 Return-path: <xen-devel-bounces@lists.xensource.com> Envelope-to: www-data@lists.xensource.com Delivery-date: Mon, 19 Sep 2011 02:29:46 -0700 Received: from localhost ([127.0.0.1] helo=lists.colo.xensource.com) by lists.xensource.com with esmtp (Exim 4.43) id 1R5aAa-0002n3-Mq; Mon, 19 Sep 2011 02:29:45 -0700 Received: from mail21.messagelabs.com ([85.158.143.35]) by lists.xensource.com with smtp (Exim 4.43) id 1R5a9e-0002aG-Ko for xen-devel@lists.xensource.com; Mon, 19 Sep 2011 02:28:46 -0700 X-Env-Sender: chao.zhou@intel.com X-Msg-Ref: server-14.tower-21.messagelabs.com!1316424514!60097250!1 X-Originating-IP: [143.182.124.37] X-StarScan-Version: 6.4.1; banners=-,-,- X-VirusChecked: Checked Received: (qmail 7168 invoked from network); 19 Sep 2011 09:28:35 -0000 Received: from mga14.intel.com (HELO mga14.intel.com) (143.182.124.37) by server-14.tower-21.messagelabs.com with SMTP; 19 Sep 2011 09:28:35 -0000 Received: from azsmga001.ch.intel.com ([10.2.17.19]) by azsmga102.ch.intel.com with ESMTP; 19 Sep 2011 02:28:42 -0700 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="4.68,404,1312182000"; d="scan'208";a="50342476" Received: from pgsmsx601.gar.corp.intel.com ([10.221.43.69]) by azsmga001.ch.intel.com with ESMTP; 19 Sep 2011 02:28:41 -0700 Received: from pgsmsx103.gar.corp.intel.com (10.221.44.82) by pgsmsx601.gar.corp.intel.com (10.221.43.69) with Microsoft SMTP Server (TLS) id 8.2.255.0; Mon, 19 Sep 2011 17:26:53 +0800 Received: from shsmsx602.ccr.corp.intel.com (10.239.4.104) by PGSMSX103.gar.corp.intel.com (10.221.44.82) with Microsoft SMTP Server (TLS) id 14.1.323.3; Mon, 19 Sep 2011 17:26:52 +0800 Received: from shsmsx502.ccr.corp.intel.com ([10.239.4.96]) by SHSMSX602.ccr.corp.intel.com ([10.239.4.104]) with mapi; Mon, 19 Sep 2011 17:26:52 +0800 From: "Zhou, Chao" <chao.zhou@intel.com> To: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com> Date: Mon, 19 Sep 2011 17:26:51 +0800 Thread-Topic: VMX status report. Xen:23851 & Dom0:20a27c1e2... Thread-Index: Acx2rkNH3Jbc3K3cR7SqF+AEgXM0CQ== Message-ID: <A24AE1FFE7AEC5489F83450EE98351BF433CE341BA@shsmsx502.ccr.corp.intel.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: [Xen-devel] VMX status report. Xen:23851 & Dom0:20a27c1e2... X-BeenThere: xen-devel@lists.xensource.com X-Mailman-Version: 2.1.5 Precedence: list List-Id: Xen developer discussion <xen-devel.lists.xensource.com> List-Unsubscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe> List-Post: <mailto:xen-devel@lists.xensource.com> List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help> List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=subscribe> Sender: xen-devel-bounces@lists.xensource.com Errors-To: xen-devel-bounces@lists.xensource.com Hi all, This is the test report for xen-unstable tree. We found one bug (#1778) abo= ut the blue screen showed when the guest win2k8 shutdown fixed. Version Info =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D xen-changeset: 23851:994b5b125c31 pvops git: commit 20a27c1e25b8550066902c9d6ca91631e656dfa3 =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D Test Environment =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D Platform Romley-EP(x86_64) Westmere-EP(x86_64) CPU 32 24 Memory 28G 12G =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D Fixed issues(1) =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D 1. Windows2k8 guest shows blue screen when shut down http://bugzilla.xensource.com/bugzilla/show_bug.cgi?id=3D1778 Old issues(7) =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D 1. [ACPI] System cann't resume after do suspend http://bugzilla.xensource.com/bugzilla/show_bug.cgi?id=3D1707 2.[XL]"xl vcpu-set" causes dom0 crash or panic=20 http://bugzilla.xensource.com/bugzilla/show_bug.cgi?id=3D1730 3.[VT-D]fail to detach NIC from guest http://bugzilla.xensource.com/bugzilla/show_bug.cgi?id=3D1736 4.[Save/Restore] guest failed to reboot after L-Migration it http://bugzilla.xensource.com/bugzilla/show_bug.cgi?id=3D1739 5.Dom0 crash on power-off http://bugzilla.xensource.com/bugzilla/show_bug.cgi?id=3D1740 6.Sometimes Xen panic on ia32pae Sandybridge when restore guest http://bugzilla.xensource.com/bugzilla/show_bug.cgi?id=3D1747 7.[VT-D] device reset fail when create/destroy guest http://bugzilla.xensource.com/bugzilla/show_bug.cgi?id=3D1752 Thanks, Zhou,Chao _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel From xen-devel-bounces@lists.xensource.com Mon Sep 19 02:36:26 2011 Return-path: <xen-devel-bounces@lists.xensource.com> Envelope-to: www-data@lists.xensource.com Delivery-date: Mon, 19 Sep 2011 02:36:26 -0700 Received: from localhost ([127.0.0.1] helo=lists.colo.xensource.com) by lists.xensource.com with esmtp (Exim 4.43) id 1R5aH3-0003Ps-MD; Mon, 19 Sep 2011 02:36:25 -0700 Received: from mail27.messagelabs.com ([193.109.254.147]) by lists.xensource.com with esmtp (Exim 4.43) id 1R5aGK-0003DK-SJ for xen-devel@lists.xensource.com; Mon, 19 Sep 2011 02:35:41 -0700 X-Env-Sender: JBeulich@suse.com X-Msg-Ref: server-6.tower-27.messagelabs.com!1316424918!49530652!1 X-Originating-IP: [130.57.49.28] X-StarScan-Version: 6.4.1; banners=-,-,- X-VirusChecked: Checked Received: (qmail 6140 invoked from network); 19 Sep 2011 09:35:18 -0000 Received: from nat28.tlf.novell.com (HELO nat28.tlf.novell.com) (130.57.49.28) by server-6.tower-27.messagelabs.com with DHE-RSA-AES256-SHA encrypted SMTP; 19 Sep 2011 09:35:18 -0000 Received: from EMEA1-MTA by nat28.tlf.novell.com with Novell_GroupWise; Mon, 19 Sep 2011 10:35:40 +0100 Message-Id: <4E7729040200007800056A2F@nat28.tlf.novell.com> X-Mailer: Novell GroupWise Internet Agent 8.0.1 Date: Mon, 19 Sep 2011 10:35:32 +0100 From: "Jan Beulich" <JBeulich@suse.com> To: "Konrad Rzeszutek Wilk" <konrad.wilk@oracle.com> Subject: Re: [Xen-devel] Re: [PATCH 3/3] xen-blkfront: If no barrier or flush is supported, use invalid operation. References: <1315593060-20031-1-git-send-email-konrad.wilk@oracle.com> <1315593060-20031-3-git-send-email-konrad.wilk@oracle.com> <4E6DD8750200007800055ADA@nat28.tlf.novell.com> <20110916191514.GA31818@phenom.oracle.com> In-Reply-To: <20110916191514.GA31818@phenom.oracle.com> Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: quoted-printable Content-Disposition: inline Cc: axboe@kernel.dk, xen-devel@lists.xensource.com, jeremy.fitzhardinge@citrix.com, stable@kernel.org, linux-kernel@vger.kernel.org X-BeenThere: xen-devel@lists.xensource.com X-Mailman-Version: 2.1.5 Precedence: list List-Id: Xen developer discussion <xen-devel.lists.xensource.com> List-Unsubscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe> List-Post: <mailto:xen-devel@lists.xensource.com> List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help> List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=subscribe> Sender: xen-devel-bounces@lists.xensource.com Errors-To: xen-devel-bounces@lists.xensource.com >>> On 16.09.11 at 21:15, Konrad Rzeszutek Wilk <konrad.wilk@oracle.com> = wrote: > On Mon, Sep 12, 2011 at 09:01:25AM +0100, Jan Beulich wrote: >> >>> On 09.09.11 at 20:31, Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>= wrote: >> > By default we would set the info->flush_op=3D0, and zero maps >> > to BLKIF_OP_READ request code. So if the backend did not support >> > either barrier ('feature-barrier') or flush ('feature-flush-cache') >> > we would end up using that opcode for the flush/barrier request, = meaning >> > we actually do a READ request. Fortunatly for us, __generic_make_reque= st >> > checks q->flush_flags and realizes that we don't do FLUSH and removes >> > the REQ_FLUSH | REQ_FUA so we never end up issuing a READ request >> > for a flush request. However, other third party implementations of >> > __make_request might not be so smart, so lets fix this up. >>=20 >> Wouldn't it be better to simply have blkif_queue_request() fail in that >> case (and then it doesn't matter whether flush_op is set to 0 or -1)? >> Not the least because older (forward-port) backends stall the incoming >> queue and are possibly verbose for invalid requests seen. >=20 > So like this: Yes, this looks small and neat. Acked-by: Jan Beulich <jbeulich@suse.com> > diff --git a/drivers/block/xen-blkfront.c b/drivers/block/xen-blkfront.c > index 468bfec..e9d301c 100644 > --- a/drivers/block/xen-blkfront.c > +++ b/drivers/block/xen-blkfront.c > @@ -380,7 +380,9 @@ static void do_blkif_request(struct request_queue = *rq) > =20 > blk_start_request(req); > =20 > - if (req->cmd_type !=3D REQ_TYPE_FS) { > + if ((req->cmd_type !=3D REQ_TYPE_FS) || > + ((req->cmd_flags & (REQ_FLUSH | REQ_FUA)) && > + !info->flush_op)) { > __blk_end_request_all(req, -EIO); > continue; > } _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel From xen-devel-bounces@lists.xensource.com Mon Sep 19 02:40:46 2011 Return-path: <xen-devel-bounces@lists.xensource.com> Envelope-to: www-data@lists.xensource.com Delivery-date: Mon, 19 Sep 2011 02:40:46 -0700 Received: from localhost ([127.0.0.1] helo=lists.colo.xensource.com) by lists.xensource.com with esmtp (Exim 4.43) id 1R5aLG-0003qP-2O; Mon, 19 Sep 2011 02:40:46 -0700 Received: from mail182.messagelabs.com ([85.158.139.83]) by lists.xensource.com with esmtp (Exim 4.43) id 1R5DuC-0004Uk-LQ for xen-devel@lists.xensource.com; Sun, 18 Sep 2011 02:43:21 -0700 X-Env-Sender: duolvxendev@yahoo.cn X-Msg-Ref: server-8.tower-182.messagelabs.com!1316338996!18781784!1 X-Originating-IP: [216.139.236.26] X-StarScan-Version: 6.4.1; banners=-,-,- X-VirusChecked: Checked Received: (qmail 9102 invoked from network); 18 Sep 2011 09:43:17 -0000 Received: from sam.nabble.com (HELO sam.nabble.com) (216.139.236.26) by server-8.tower-182.messagelabs.com with AES256-SHA encrypted SMTP; 18 Sep 2011 09:43:17 -0000 Received: from [192.168.236.26] (helo=sam.nabble.com) by sam.nabble.com with esmtp (Exim 4.72) (envelope-from <duolvxendev@yahoo.cn>) id 1R5Du7-0005Yw-Pb for xen-devel@lists.xensource.com; Sun, 18 Sep 2011 02:43:15 -0700 Date: Sun, 18 Sep 2011 02:43:15 -0700 (PDT) From: duolvxendev <duolvxendev@yahoo.cn> To: xen-devel@lists.xensource.com Message-ID: <1316338995760-4815691.post@n5.nabble.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Mailman-Approved-At: Mon, 19 Sep 2011 02:40:09 -0700 Subject: [Xen-devel] Permission for xenstore operation on HVM X-BeenThere: xen-devel@lists.xensource.com X-Mailman-Version: 2.1.5 Precedence: list List-Id: Xen developer discussion <xen-devel.lists.xensource.com> List-Unsubscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe> List-Post: <mailto:xen-devel@lists.xensource.com> List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help> List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=subscribe> Sender: xen-devel-bounces@lists.xensource.com Errors-To: xen-devel-bounces@lists.xensource.com Hi, I'm trying to write some message using xenbus_printf to xenstore from a debian HVM guest with pv-on-HVM driver. I got a permission denied error return code. How should I do if I want write the message to xenstore in kernel module? PS: the hypervisor is xen-3.4.2; the dom0 is CentOS 5.4 and the guest is Debian 6; the pv-on-HVM driver is built from Alex Bligh's patch and it works well. -- View this message in context: http://xen.1045712.n5.nabble.com/Permission-for-xenstore-operation-on-HVM-tp4815691p4815691.html Sent from the Xen - Dev mailing list archive at Nabble.com. _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel From xen-devel-bounces@lists.xensource.com Mon Sep 19 02:41:44 2011 Return-path: <xen-devel-bounces@lists.xensource.com> Envelope-to: www-data@lists.xensource.com Delivery-date: Mon, 19 Sep 2011 02:41:44 -0700 Received: from localhost ([127.0.0.1] helo=lists.colo.xensource.com) by lists.xensource.com with esmtp (Exim 4.43) id 1R5aMB-0004D6-Q4; Mon, 19 Sep 2011 02:41:44 -0700 Received: from mail216.messagelabs.com ([85.158.143.99]) by lists.xensource.com with smtp (Exim 4.43) id 1R5Wfb-00062o-Fu for xen-devel@lists.xensource.com; Sun, 18 Sep 2011 22:45:31 -0700 X-Env-Sender: philippe.simonet@bluewin.ch X-Msg-Ref: server-12.tower-216.messagelabs.com!1316411128!12992441!1 X-Originating-IP: [195.186.19.61] X-StarScan-Version: 6.4.1; banners=-,-,- X-VirusChecked: Checked Received: (qmail 14004 invoked from network); 19 Sep 2011 05:45:28 -0000 Received: from mail12.bluewin.ch (HELO mail12.bluewin.ch) (195.186.19.61) by server-12.tower-216.messagelabs.com with SMTP; 19 Sep 2011 05:45:28 -0000 X-FXIT-IP: IPv4[188.63.105.42] Epoch[1316411128] Received: from [188.63.105.42] ([188.63.105.42:23426] helo=[192.168.1.80]) by mail12.bluewin.ch (envelope-from <philippe.simonet@bluewin.ch>) (ecelerity 2.2.2.41 r(31179/31189)) with ESMTP id 26/2E-10279-4F6D67E4; Mon, 19 Sep 2011 05:45:28 +0000 Message-ID: <4E76D6F2.5010602@bluewin.ch> Date: Mon, 19 Sep 2011 07:45:22 +0200 From: Philippe Simonet <philippe.simonet@bluewin.ch> User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.2.22) Gecko/20110902 Lightning/1.0b2 Thunderbird/3.1.14 MIME-Version: 1.0 To: Jeremy Fitzhardinge <jeremy@goop.org> Subject: Re: [Xen-devel] Xen 4 TSC problems References: <AANLkTik3Ng6TpQANfPNJ2M=86WYLHVt7_MuBuVfJ1CG_@mail.gmail.com> <4E6F034B.5040102@bluewin.ch> <20110915082402.GC24888@phenom.oracle.com> <4E7226CB.2020706@goop.org> <FF93AF260AC2BB499A119CC65B092CF73112A3CA@sg000713.corproot.net> <4E73D052.3020901@goop.org> In-Reply-To: <4E73D052.3020901@goop.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Mailman-Approved-At: Mon, 19 Sep 2011 02:40:09 -0700 Cc: Philippe.Simonet@swisscom.com, xen-devel@lists.xensource.com, konrad.wilk@oracle.com X-BeenThere: xen-devel@lists.xensource.com X-Mailman-Version: 2.1.5 Precedence: list List-Id: Xen developer discussion <xen-devel.lists.xensource.com> List-Unsubscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe> List-Post: <mailto:xen-devel@lists.xensource.com> List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help> List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=subscribe> Sender: xen-devel-bounces@lists.xensource.com Errors-To: xen-devel-bounces@lists.xensource.com On 9/17/2011 12:40 AM, Jeremy Fitzhardinge wrote: > On 09/15/2011 11:03 PM, Philippe.Simonet@swisscom.com wrote: >>> -----Original Message----- >>> From: xen-devel-bounces@lists.xensource.com [mailto:xen-devel- >>> bounces@lists.xensource.com] On Behalf Of Jeremy Fitzhardinge >>> Sent: Thursday, September 15, 2011 6:25 PM >>> To: Konrad Rzeszutek Wilk >>> Cc: xen-devel@lists.xensource.com; Philippe Simonet >>> Subject: Re: [Xen-devel] Xen 4 TSC problems >>> >>> On 09/15/2011 01:24 AM, Konrad Rzeszutek Wilk wrote: >>>> On Tue, Sep 13, 2011 at 09:16:27AM +0200, Philippe Simonet wrote: >>>>> Hi Xen developers >>>> Lets try this again, this time Cc-ing Jeremy. >>>>> i just would like to inform you that I have exactly the same problem >>>>> with Debian squeeze and xen, with >>>>> 50 seconds time jump on my dom0 and domu. NTP is running on all >>>>> dom0/domuU, clocksource is 'xen' >>>>> everywhere. >>>>> >>>>> some messages : >>>>> syslog : >>>>> Sep 11 13:56:50 dnsit22 kernel: [571603.359863] Clocksource tsc >>>>> unstable (delta = -2999662111513 ns) >>>>> >>>>> xm dmesg : >>>>> ... >>>>> (XEN) Platform timer is 14.318MHz HPET ... >>>>> (XEN) Platform timer appears to have unexpectedly wrapped 10 or more >>> times. >>>>> (XEN) TSC marked as reliable, warp = 0 (count=2) ... >>>>> >>>>> I had some contact with Olivier Hanesse and it indicates that he >>>>> doesn't have any solution for this problem, and all what was proposed >>>>> in February didn't solved this problem. >>> That looks like Xen itself is having problems keeping track of time. If it can't >>> manage it, then there's not much the guest kernels can do about it. >>> >>>> Which was the max_cstate=0 ? >>>> .. >>>>> config : >>>>> -------------------------------------- >>>>> Linux dnsit22.swissptt.ch 2.6.32-5-xen-amd64 #1 SMP Tue Jun 14 >>>>> 12:46:30 UTC 2011 x86_64 GNU/Linux >>>>> -------------------------------------- >>>>> HP DL385 >>>>> -------------------------------------- >>>>> vendor_id : AuthenticAMD >>>>> cpu family : 16 >>>>> model : 9 >>>>> model name : AMD Opteron(tm) Processor 6174 >>>>> stepping : 1 >>>>> cpu MHz : 3058776.574 >>>> OK, that is really messed up. Your house must be on fire for the >>>> machine to be running at 3058GHz! >>>> >>>> Jeremy, this sounds familiar - did we have a patch for this in your >>>> 2.6.32 tree? >>> Not that I can think of. All I can suggest from the kernel side is that perhaps >>> some of the ACPI power stuff isn't being set up properly, and that makes the >>> CPU do very strange things with its TSC/power states in general. >>> >> how can i detect that ? >> >> the /proc/acpi/processor path is empty, >> >> find /proc/acpi >> /proc/acpi >> /proc/acpi/processor >> /proc/acpi/button >> /proc/acpi/button/power >> /proc/acpi/button/power/PWRF >> /proc/acpi/button/power/PWRF/info >> /proc/acpi/thermal_zone >> /proc/acpi/wakeup >> /proc/acpi/sleep >> /proc/acpi/fadt >> /proc/acpi/dsdt >> /proc/acpi/info >> /proc/acpi/power_resource >> /proc/acpi/embedded_controller >> >> dmesg | grep -I acpi >> [ 1.205647] hpet_acpi_add: no address or irqs in _CRS >> >> lsmod | grep -i acpi >> acpi_processor 5087 1 processor,[permanent] > What does "xenpm start 5" say? > > J > here it is : root@dnsit22.swissptt.ch ~# xenpm start 5 Timeout set to 5 seconds Start sampling, waiting for CTRL-C or SIGINT or SIGALARM signal ... Elapsed time (ms): 5028 CPU0: Residency(ms) Avg Res(ms) Avg freq 18 KHz CPU1: Residency(ms) Avg Res(ms) Avg freq 18 KHz CPU2: Residency(ms) Avg Res(ms) Avg freq 18 KHz CPU3: Residency(ms) Avg Res(ms) Avg freq 18 KHz CPU4: Residency(ms) Avg Res(ms) Avg freq 18 KHz CPU5: Residency(ms) Avg Res(ms) Avg freq 18 KHz CPU6: Residency(ms) Avg Res(ms) Avg freq 18 KHz CPU7: Residency(ms) Avg Res(ms) Avg freq 18 KHz CPU8: Residency(ms) Avg Res(ms) Avg freq 18 KHz CPU9: Residency(ms) Avg Res(ms) Avg freq 18 KHz CPU10: Residency(ms) Avg Res(ms) Avg freq 18 KHz CPU11: Residency(ms) Avg Res(ms) Avg freq 18 KHz CPU12: Residency(ms) Avg Res(ms) Avg freq 18 KHz CPU13: Residency(ms) Avg Res(ms) Avg freq 18 KHz CPU14: Residency(ms) Avg Res(ms) Avg freq 18 KHz CPU15: Residency(ms) Avg Res(ms) Avg freq 18 KHz CPU16: Residency(ms) Avg Res(ms) Avg freq 18 KHz CPU17: Residency(ms) Avg Res(ms) Avg freq 18 KHz CPU18: Residency(ms) Avg Res(ms) Avg freq 18 KHz CPU19: Residency(ms) Avg Res(ms) Avg freq 18 KHz CPU20: Residency(ms) Avg Res(ms) Avg freq 18 KHz CPU21: Residency(ms) Avg Res(ms) Avg freq 18 KHz CPU22: Residency(ms) Avg Res(ms) Avg freq 18 KHz CPU23: Residency(ms) Avg Res(ms) Avg freq 18 KHz _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel From xen-devel-bounces@lists.xensource.com Mon Sep 19 03:40:46 2011 Return-path: <xen-devel-bounces@lists.xensource.com> Envelope-to: www-data@lists.xensource.com Delivery-date: Mon, 19 Sep 2011 03:40:46 -0700 Received: from localhost ([127.0.0.1] helo=lists.colo.xensource.com) by lists.xensource.com with esmtp (Exim 4.43) id 1R5bHK-0006IB-Cb; Mon, 19 Sep 2011 03:40:46 -0700 Received: from mail27.messagelabs.com ([193.109.254.147]) by lists.xensource.com with esmtp (Exim 4.43) id 1R5bGS-00065h-Dm for xen-devel@lists.xensource.com; Mon, 19 Sep 2011 03:39:52 -0700 X-Env-Sender: dunlapg@gmail.com X-Msg-Ref: server-6.tower-27.messagelabs.com!1316428770!49542770!1 X-Originating-IP: [74.125.82.169] X-StarScan-Version: 6.4.1; banners=-,-,- X-VirusChecked: Checked Received: (qmail 20407 invoked from network); 19 Sep 2011 10:39:30 -0000 Received: from mail-wy0-f169.google.com (HELO mail-wy0-f169.google.com) (74.125.82.169) by server-6.tower-27.messagelabs.com with RC4-SHA encrypted SMTP; 19 Sep 2011 10:39:30 -0000 Received: by wyi11 with SMTP id 11so8068414wyi.28 for <xen-devel@lists.xensource.com>; Mon, 19 Sep 2011 03:39:49 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=f6W7yAYAwESPBRu+TLyHRvsi2zMrWgF45jF8oh5oYMY=; b=fhmViw7BK4Qs9DQEEOJUliGZP9K5X4eEPT1W/lsRnsHz/Dqbi6wslbXuAdsDvtX4YG MbIxVt8amzqUE5cgLKvei31OGS2BYeAI69i342Uy5mqrW9FJNk9TXvL/+Gd6Bf1RIazk J9KtATqigwsLf1jgLOM3WkN/HKqYoaSstZhJg= MIME-Version: 1.0 Received: by 10.216.137.94 with SMTP id x72mr2873989wei.9.1316428789252; Mon, 19 Sep 2011 03:39:49 -0700 (PDT) Received: by 10.216.176.81 with HTTP; Mon, 19 Sep 2011 03:39:49 -0700 (PDT) In-Reply-To: <5224b434-5371-404d-8fed-2665e73dacce@default> References: <AANLkTik3Ng6TpQANfPNJ2M=86WYLHVt7_MuBuVfJ1CG_@mail.gmail.com> <CAFLBxZZiGxef5CkH9r+VZeB4h7LPA0nJddumwDRovZaL4zOuvA@mail.gmail.com> <5224b434-5371-404d-8fed-2665e73dacce@default> Date: Mon, 19 Sep 2011 11:39:49 +0100 X-Google-Sender-Auth: A9CfoymcXKT6pln_oR8yEyAIq5s Message-ID: <CAFLBxZZ3nP5EbtL=Ne-W4DcSWtKGh1XDOs-EhVua7ujmi9Y2Jw@mail.gmail.com> Subject: Re: [Xen-devel] Xen 4 TSC problems From: George Dunlap <George.Dunlap@eu.citrix.com> To: Dan Magenheimer <dan.magenheimer@oracle.com> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: Keir Fraser <keir@xen.org>, jeremy@goop.org, xen-devel@lists.xensource.com, Philippe Simonet <philippe.simonet@bluewin.ch>, Konrad Wilk <konrad.wilk@oracle.com> X-BeenThere: xen-devel@lists.xensource.com X-Mailman-Version: 2.1.5 Precedence: list List-Id: Xen developer discussion <xen-devel.lists.xensource.com> List-Unsubscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe> List-Post: <mailto:xen-devel@lists.xensource.com> List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help> List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=subscribe> Sender: xen-devel-bounces@lists.xensource.com Errors-To: xen-devel-bounces@lists.xensource.com On Thu, Sep 15, 2011 at 7:38 PM, Dan Magenheimer <dan.magenheimer@oracle.com> wrote: >> I haven't been following this conversation, so I don't know if this is >> relevant, but I've just discovered this morning that the TSC warp >> check in Xen is done at the wrong time (before any secondary cpus are >> brought up), and thus always returns warp=3D0. =A0I've submitted a patch >> to do the check after secondary CPUs are brought up; that should cause >> Xen to do periodic synchronization of TSCs when there is drift. > > Wow, nice catch, George! =A0I wonder if this is the underlying bug > for many of the mysterious time problems that have been reported > for a year or two now... at least on certain AMD boxes. > Any idea when this was introduced? =A0Or has it always been wrong? Well the comment in 20823:89907dab1aef seems to indicate that's where the "assume it's reliable on AMD until proven otherwise" started; that would be January 2010. I looked as far back as 20705:a74aca4b9386, and there the TSC reliability checks were again in init_xen_time(). Figuring out where things were before then is getting into archeology. :-) The comment at the top of init_xen_time() is correct now, but from the time it was first written through 4.1 is was just plain wrong -- it said init_xen_time() happened after all cpus were up, which has never been true. -George _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel From xen-devel-bounces@lists.xensource.com Mon Sep 19 03:44:01 2011 Return-path: <xen-devel-bounces@lists.xensource.com> Envelope-to: www-data@lists.xensource.com Delivery-date: Mon, 19 Sep 2011 03:44:01 -0700 Received: from localhost ([127.0.0.1] helo=lists.colo.xensource.com) by lists.xensource.com with esmtp (Exim 4.43) id 1R5bKT-0006mw-Hb; Mon, 19 Sep 2011 03:44:01 -0700 Received: from mail21.messagelabs.com ([85.158.143.35]) by lists.xensource.com with esmtp (Exim 4.43) id 1R5bJx-0006ao-0f for xen-devel@lists.xensource.com; Mon, 19 Sep 2011 03:43:30 -0700 X-Env-Sender: JBeulich@suse.com X-Msg-Ref: server-10.tower-21.messagelabs.com!1316428991!54648481!1 X-Originating-IP: [130.57.49.28] X-StarScan-Version: 6.4.1; banners=-,-,- X-VirusChecked: Checked Received: (qmail 8467 invoked from network); 19 Sep 2011 10:43:11 -0000 Received: from nat28.tlf.novell.com (HELO nat28.tlf.novell.com) (130.57.49.28) by server-10.tower-21.messagelabs.com with DHE-RSA-AES256-SHA encrypted SMTP; 19 Sep 2011 10:43:11 -0000 Received: from EMEA1-MTA by nat28.tlf.novell.com with Novell_GroupWise; Mon, 19 Sep 2011 11:44:24 +0100 Message-Id: <4E7738E90200007800056A54@nat28.tlf.novell.com> X-Mailer: Novell GroupWise Internet Agent 8.0.1 Date: Mon, 19 Sep 2011 11:43:21 +0100 From: "Jan Beulich" <JBeulich@suse.com> To: "Konrad Rzeszutek Wilk" <konrad.wilk@oracle.com> References: <20110916190601.GA31796@phenom.oracle.com> In-Reply-To: <20110916190601.GA31796@phenom.oracle.com> Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: quoted-printable Content-Disposition: inline Cc: xen-devel@lists.xensource.com, linux-kernel@vger.kernel.org Subject: [Xen-devel] Re: [PATCH] xen/pciback: Use mutexes when working with Xenbus state transitions. X-BeenThere: xen-devel@lists.xensource.com X-Mailman-Version: 2.1.5 Precedence: list List-Id: Xen developer discussion <xen-devel.lists.xensource.com> List-Unsubscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe> List-Post: <mailto:xen-devel@lists.xensource.com> List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help> List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=subscribe> Sender: xen-devel-bounces@lists.xensource.com Errors-To: xen-devel-bounces@lists.xensource.com >>> On 16.09.11 at 21:06, Konrad Rzeszutek Wilk <konrad.wilk@oracle.com> = wrote: > The caller that orchestrates the state changes is xenwatch_thread > and it takes a mutex. In our processing of Xenbus states we can take > the luxery of going to sleep on a mutex, so lets do that and This is only the direct conversion of existing spinlock accesses in xenbus.c. However, in the course of converting from the legacy implementation you stripped a couple more (in xen_pcibk_attach(), xen_pcibk_reconfigure(), and xen_pcibk_setup_backend()), and those should now get re-added imo. Jan > also fix this bug: >=20 > BUG: sleeping function called from invalid context at=20 > /linux/kernel/mutex.c:271 > in_atomic(): 1, irqs_disabled(): 0, pid: 32, name: xenwatch > 2 locks held by xenwatch/32: > #0: (xenwatch_mutex){......}, at: [<ffffffff813856ab>]=20 > xenwatch_thread+0x4b/0x180 > #1: (&(&pdev->dev_lock)->rlock){......}, at: [<ffffffff8138f05b>]=20 > xen_pcibk_disconnect+0x1b/0x80 > Pid: 32, comm: xenwatch Not tainted 3.1.0-rc6-00015-g3ce340d #2 > Call Trace: > [<ffffffff810892b2>] __might_sleep+0x102/0x130 > [<ffffffff8163b90f>] mutex_lock_nested+0x2f/0x50 > [<ffffffff81382c1c>] unbind_from_irq+0x2c/0x1b0 > [<ffffffff8110da66>] ? free_irq+0x56/0xb0 > [<ffffffff81382dbc>] unbind_from_irqhandler+0x1c/0x30 > [<ffffffff8138f06b>] xen_pcibk_disconnect+0x2b/0x80 > [<ffffffff81390348>] xen_pcibk_frontend_changed+0xe8/0x140 > [<ffffffff81387ac2>] xenbus_otherend_changed+0xd2/0x150 > [<ffffffff810895c1>] ? get_parent_ip+0x11/0x50 > [<ffffffff81387de0>] frontend_changed+0x10/0x20 > [<ffffffff81385712>] xenwatch_thread+0xb2/0x180 >=20 > Signed-off-by: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com> > --- > drivers/xen/xen-pciback/pciback.h | 2 +- > drivers/xen/xen-pciback/xenbus.c | 16 +++++----------- > 2 files changed, 6 insertions(+), 12 deletions(-) >=20 > diff --git a/drivers/xen/xen-pciback/pciback.h=20 > b/drivers/xen/xen-pciback/pciback.h > index a0e131a..c3af628 100644 > --- a/drivers/xen/xen-pciback/pciback.h > +++ b/drivers/xen/xen-pciback/pciback.h > @@ -27,7 +27,7 @@ struct pci_dev_entry { > =20 > struct xen_pcibk_device { > void *pci_dev_data; > - spinlock_t dev_lock; > + struct mutex dev_lock; > struct xenbus_device *xdev; > struct xenbus_watch be_watch; > u8 be_watching; > diff --git a/drivers/xen/xen-pciback/xenbus.c b/drivers/xen/xen-pciback/x= enbus.c > index 978d2c6..c057d67 100644 > --- a/drivers/xen/xen-pciback/xenbus.c > +++ b/drivers/xen/xen-pciback/xenbus.c > @@ -44,7 +44,7 @@ static struct xen_pcibk_device *alloc_pdev(struct=20 > xenbus_device *xdev) > pdev->xdev =3D xdev; > dev_set_drvdata(&xdev->dev, pdev); > =20 > - spin_lock_init(&pdev->dev_lock); > + mutex_init(&pdev->dev_lock); > =20 > pdev->sh_info =3D NULL; > pdev->evtchn_irq =3D INVALID_EVTCHN_IRQ; > @@ -62,14 +62,13 @@ out: > =20 > static void xen_pcibk_disconnect(struct xen_pcibk_device *pdev) > { > - spin_lock(&pdev->dev_lock); > + mutex_lock(&pdev->dev_lock); > =20 > /* Ensure the guest can't trigger our handler before removing = devices */ > if (pdev->evtchn_irq !=3D INVALID_EVTCHN_IRQ) { > unbind_from_irqhandler(pdev->evtchn_irq, pdev); > pdev->evtchn_irq =3D INVALID_EVTCHN_IRQ; > } > - spin_unlock(&pdev->dev_lock); > =20 > /* If the driver domain started an op, make sure we complete it > * before releasing the shared memory */ > @@ -77,13 +76,11 @@ static void xen_pcibk_disconnect(struct xen_pcibk_dev= ice=20 > *pdev) > /* Note, the workqueue does not use spinlocks at all.*/ > flush_workqueue(xen_pcibk_wq); > =20 > - spin_lock(&pdev->dev_lock); > if (pdev->sh_info !=3D NULL) { > xenbus_unmap_ring_vfree(pdev->xdev, pdev->sh_info); > pdev->sh_info =3D NULL; > } > - spin_unlock(&pdev->dev_lock); > - > + mutex_unlock(&pdev->dev_lock); > } > =20 > static void free_pdev(struct xen_pcibk_device *pdev) > @@ -120,9 +117,8 @@ static int xen_pcibk_do_attach(struct xen_pcibk_devic= e=20 > *pdev, int gnt_ref, > goto out; > } > =20 > - spin_lock(&pdev->dev_lock); > + mutex_lock(&pdev->dev_lock); > pdev->sh_info =3D vaddr; > - spin_unlock(&pdev->dev_lock); > =20 > err =3D bind_interdomain_evtchn_to_irqhandler( > pdev->xdev->otherend_id, remote_evtchn, xen_pcibk_handle_ev= ent, > @@ -132,14 +128,12 @@ static int xen_pcibk_do_attach(struct xen_pcibk_dev= ice=20 > *pdev, int gnt_ref, > "Error binding event channel to IRQ"); > goto out; > } > - > - spin_lock(&pdev->dev_lock); > pdev->evtchn_irq =3D err; > - spin_unlock(&pdev->dev_lock); > err =3D 0; > =20 > dev_dbg(&pdev->xdev->dev, "Attached!\n"); > out: > + mutex_unlock(&pdev->dev_lock); > return err; > } > =20 _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel From xen-devel-bounces@lists.xensource.com Mon Sep 19 04:05:07 2011 Return-path: <xen-devel-bounces@lists.xensource.com> Envelope-to: www-data@lists.xensource.com Delivery-date: Mon, 19 Sep 2011 04:05:07 -0700 Received: from localhost ([127.0.0.1] helo=lists.colo.xensource.com) by lists.xensource.com with esmtp (Exim 4.43) id 1R5beq-0007XP-Gg; Mon, 19 Sep 2011 04:05:05 -0700 Received: from mail174.messagelabs.com ([85.158.138.51]) by lists.xensource.com with esmtp (Exim 4.43) id 1R5bbw-0007GP-3s for xen-devel@lists.xensource.com; Mon, 19 Sep 2011 04:02:44 -0700 X-Env-Sender: JBeulich@suse.com X-Msg-Ref: server-4.tower-174.messagelabs.com!1316430119!31958895!1 X-Originating-IP: [130.57.49.28] X-StarScan-Version: 6.4.1; banners=-,-,- X-VirusChecked: Checked Received: (qmail 29421 invoked from network); 19 Sep 2011 11:02:00 -0000 Received: from nat28.tlf.novell.com (HELO nat28.tlf.novell.com) (130.57.49.28) by server-4.tower-174.messagelabs.com with DHE-RSA-AES256-SHA encrypted SMTP; 19 Sep 2011 11:02:00 -0000 Received: from EMEA1-MTA by nat28.tlf.novell.com with Novell_GroupWise; Mon, 19 Sep 2011 12:01:58 +0100 Message-Id: <4E773D440200007800056A6D@nat28.tlf.novell.com> X-Mailer: Novell GroupWise Internet Agent 8.0.1 Date: Mon, 19 Sep 2011 12:01:56 +0100 From: "Jan Beulich" <JBeulich@suse.com> To: "Konrad Rzeszutek Wilk" <konrad.wilk@oracle.com> Subject: [Xen-devel] Re: [PATCH] xen/pciback: Use mutexes when working with Xenbus state transitions. References: <20110916190601.GA31796@phenom.oracle.com> <4E7738E90200007800056A54@nat28.tlf.novell.com> In-Reply-To: <4E7738E90200007800056A54@nat28.tlf.novell.com> Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: quoted-printable Content-Disposition: inline Cc: xen-devel@lists.xensource.com, linux-kernel@vger.kernel.org X-BeenThere: xen-devel@lists.xensource.com X-Mailman-Version: 2.1.5 Precedence: list List-Id: Xen developer discussion <xen-devel.lists.xensource.com> List-Unsubscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe> List-Post: <mailto:xen-devel@lists.xensource.com> List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help> List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=subscribe> Sender: xen-devel-bounces@lists.xensource.com Errors-To: xen-devel-bounces@lists.xensource.com >>> On 19.09.11 at 12:43, "Jan Beulich" <JBeulich@suse.com> wrote: >>>> On 16.09.11 at 21:06, Konrad Rzeszutek Wilk <konrad.wilk@oracle.com> = wrote: >=20 >> The caller that orchestrates the state changes is xenwatch_thread >> and it takes a mutex. In our processing of Xenbus states we can take >> the luxery of going to sleep on a mutex, so lets do that and >=20 > This is only the direct conversion of existing spinlock accesses in > xenbus.c. However, in the course of converting from the legacy > implementation you stripped a couple more (in xen_pcibk_attach(), > xen_pcibk_reconfigure(), and xen_pcibk_setup_backend()), and Actually, xen_pcibk_attach() has its lock taken in xen_pcibk_do_attach(), so no change needed there. In xen_pcibk_reconfigure() and xen_pcibk_setup_backend() the locking may be redundant with the one in passthrough.c/vpci.c - is that the basis upon which you removed the locks taken there? Jan > those should now get re-added imo. >=20 > Jan >=20 >> also fix this bug: >>=20 >> BUG: sleeping function called from invalid context at=20 >> /linux/kernel/mutex.c:271 >> in_atomic(): 1, irqs_disabled(): 0, pid: 32, name: xenwatch >> 2 locks held by xenwatch/32: >> #0: (xenwatch_mutex){......}, at: [<ffffffff813856ab>]=20 >> xenwatch_thread+0x4b/0x180 >> #1: (&(&pdev->dev_lock)->rlock){......}, at: [<ffffffff8138f05b>]=20 >> xen_pcibk_disconnect+0x1b/0x80 >> Pid: 32, comm: xenwatch Not tainted 3.1.0-rc6-00015-g3ce340d #2 >> Call Trace: >> [<ffffffff810892b2>] __might_sleep+0x102/0x130 >> [<ffffffff8163b90f>] mutex_lock_nested+0x2f/0x50 >> [<ffffffff81382c1c>] unbind_from_irq+0x2c/0x1b0 >> [<ffffffff8110da66>] ? free_irq+0x56/0xb0 >> [<ffffffff81382dbc>] unbind_from_irqhandler+0x1c/0x30 >> [<ffffffff8138f06b>] xen_pcibk_disconnect+0x2b/0x80 >> [<ffffffff81390348>] xen_pcibk_frontend_changed+0xe8/0x140 >> [<ffffffff81387ac2>] xenbus_otherend_changed+0xd2/0x150 >> [<ffffffff810895c1>] ? get_parent_ip+0x11/0x50 >> [<ffffffff81387de0>] frontend_changed+0x10/0x20 >> [<ffffffff81385712>] xenwatch_thread+0xb2/0x180 >>=20 >> Signed-off-by: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com> >> --- >> drivers/xen/xen-pciback/pciback.h | 2 +- >> drivers/xen/xen-pciback/xenbus.c | 16 +++++----------- >> 2 files changed, 6 insertions(+), 12 deletions(-) >>=20 >> diff --git a/drivers/xen/xen-pciback/pciback.h=20 >> b/drivers/xen/xen-pciback/pciback.h >> index a0e131a..c3af628 100644 >> --- a/drivers/xen/xen-pciback/pciback.h >> +++ b/drivers/xen/xen-pciback/pciback.h >> @@ -27,7 +27,7 @@ struct pci_dev_entry { >> =20 >> struct xen_pcibk_device { >> void *pci_dev_data; >> - spinlock_t dev_lock; >> + struct mutex dev_lock; >> struct xenbus_device *xdev; >> struct xenbus_watch be_watch; >> u8 be_watching; >> diff --git a/drivers/xen/xen-pciback/xenbus.c b/drivers/xen/xen-pciback/= xenbus.c >> index 978d2c6..c057d67 100644 >> --- a/drivers/xen/xen-pciback/xenbus.c >> +++ b/drivers/xen/xen-pciback/xenbus.c >> @@ -44,7 +44,7 @@ static struct xen_pcibk_device *alloc_pdev(struct=20 >> xenbus_device *xdev) >> pdev->xdev =3D xdev; >> dev_set_drvdata(&xdev->dev, pdev); >> =20 >> - spin_lock_init(&pdev->dev_lock); >> + mutex_init(&pdev->dev_lock); >> =20 >> pdev->sh_info =3D NULL; >> pdev->evtchn_irq =3D INVALID_EVTCHN_IRQ; >> @@ -62,14 +62,13 @@ out: >> =20 >> static void xen_pcibk_disconnect(struct xen_pcibk_device *pdev) >> { >> - spin_lock(&pdev->dev_lock); >> + mutex_lock(&pdev->dev_lock); >> =20 >> /* Ensure the guest can't trigger our handler before removing = devices */ >> if (pdev->evtchn_irq !=3D INVALID_EVTCHN_IRQ) { >> unbind_from_irqhandler(pdev->evtchn_irq, pdev); >> pdev->evtchn_irq =3D INVALID_EVTCHN_IRQ; >> } >> - spin_unlock(&pdev->dev_lock); >> =20 >> /* If the driver domain started an op, make sure we complete it >> * before releasing the shared memory */ >> @@ -77,13 +76,11 @@ static void xen_pcibk_disconnect(struct xen_pcibk_de= vice=20 >> *pdev) >> /* Note, the workqueue does not use spinlocks at all.*/ >> flush_workqueue(xen_pcibk_wq); >> =20 >> - spin_lock(&pdev->dev_lock); >> if (pdev->sh_info !=3D NULL) { >> xenbus_unmap_ring_vfree(pdev->xdev, pdev->sh_info); >> pdev->sh_info =3D NULL; >> } >> - spin_unlock(&pdev->dev_lock); >> - >> + mutex_unlock(&pdev->dev_lock); >> } >> =20 >> static void free_pdev(struct xen_pcibk_device *pdev) >> @@ -120,9 +117,8 @@ static int xen_pcibk_do_attach(struct xen_pcibk_devi= ce=20 >> *pdev, int gnt_ref, >> goto out; >> } >> =20 >> - spin_lock(&pdev->dev_lock); >> + mutex_lock(&pdev->dev_lock); >> pdev->sh_info =3D vaddr; >> - spin_unlock(&pdev->dev_lock); >> =20 >> err =3D bind_interdomain_evtchn_to_irqhandler( >> pdev->xdev->otherend_id, remote_evtchn, xen_pcibk_handle_ev= ent, >> @@ -132,14 +128,12 @@ static int xen_pcibk_do_attach(struct xen_pcibk_de= vice=20 >> *pdev, int gnt_ref, >> "Error binding event channel to IRQ"); >> goto out; >> } >> - >> - spin_lock(&pdev->dev_lock); >> pdev->evtchn_irq =3D err; >> - spin_unlock(&pdev->dev_lock); >> err =3D 0; >> =20 >> dev_dbg(&pdev->xdev->dev, "Attached!\n"); >> out: >> + mutex_unlock(&pdev->dev_lock); >> return err; >> } >> =20 >=20 >=20 >=20 >=20 > _______________________________________________ > Xen-devel mailing list > Xen-devel@lists.xensource.com=20 > http://lists.xensource.com/xen-devel=20 _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel From xen-devel-bounces@lists.xensource.com Mon Sep 19 04:36:14 2011 Return-path: <xen-devel-bounces@lists.xensource.com> Envelope-to: www-data@lists.xensource.com Delivery-date: Mon, 19 Sep 2011 04:36:14 -0700 Received: from localhost ([127.0.0.1] helo=lists.colo.xensource.com) by lists.xensource.com with esmtp (Exim 4.43) id 1R5c90-0000nh-Fu; Mon, 19 Sep 2011 04:36:14 -0700 Received: from mail174.messagelabs.com ([85.158.138.51]) by lists.xensource.com with smtp (Exim 4.43) id 1R5c8D-0000bG-DF for xen-devel@lists.xensource.com; Mon, 19 Sep 2011 04:35:25 -0700 X-Env-Sender: ml-xen-devel@hfp.de X-Msg-Ref: server-10.tower-174.messagelabs.com!1316432122!31940822!1 X-Originating-IP: [88.205.101.6] X-StarScan-Version: 6.4.1; banners=-,-,- X-VirusChecked: Checked Received: (qmail 21748 invoked from network); 19 Sep 2011 11:35:22 -0000 Received: from rootsrv.hfp.de (HELO rootsrv.hfp.de) (88.205.101.6) by server-10.tower-174.messagelabs.com with SMTP; 19 Sep 2011 11:35:22 -0000 Received: from localhost (localhost [127.0.0.1]) by rootsrv.hfp.de (Postfix) with ESMTP id 42EF71A8A9C; Mon, 19 Sep 2011 13:35:21 +0200 (CEST) X-Virus-Scanned: amavisd-new/ClamAV at rootsrv.hfp.de Received: from rootsrv.hfp.de ([127.0.0.1]) by localhost (rootsrv.hfp.de [127.0.0.1]) (amavisd-new, port 10026) with ESMTP id GowxAUJKoMKn; Mon, 19 Sep 2011 13:35:21 +0200 (CEST) Received: from [10.0.0.1] (p5794692B.dip.t-dialin.net [87.148.105.43]) by rootsrv.hfp.de (Postfix) with ESMTPA; Mon, 19 Sep 2011 13:35:21 +0200 (CEST) Message-ID: <4E7728F9.9020208@hfp.de> Date: Mon, 19 Sep 2011 13:35:21 +0200 From: Andreas Kinzler <ml-xen-devel@hfp.de> User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:6.0.2) Gecko/20110902 Thunderbird/6.0.2 MIME-Version: 1.0 To: James Harper <james.harper@bendigoit.com.au> Subject: Re: [Xen-devel] RE: Stability report GPLPV 0.11.0.308 References: <4E64A0DF.2070007@hfp.de> <AEC6C66638C05B468B556EA548C1A77D01E5DB8C@trantor> <4E64D569.5030607@hfp.de> <AEC6C66638C05B468B556EA548C1A77D01E5DBBF@trantor> In-Reply-To: <AEC6C66638C05B468B556EA548C1A77D01E5DBBF@trantor> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: xen-devel@lists.xensource.com X-BeenThere: xen-devel@lists.xensource.com X-Mailman-Version: 2.1.5 Precedence: list List-Id: Xen developer discussion <xen-devel.lists.xensource.com> List-Unsubscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe> List-Post: <mailto:xen-devel@lists.xensource.com> List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help> List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=subscribe> Sender: xen-devel-bounces@lists.xensource.com Errors-To: xen-devel-bounces@lists.xensource.com Hello James, the torture test of GPLPV 0.11.0.312 failed (as 0.11.0.308 did). What really puzzles me is that the uptime was 9-10 days for both VMs (as in 0.11.0.308). One could think that there is something about the uptime of 9-10 days. There is no noticeable malfunction in dom0 and while the domUs were running they looked perfectly. Really odd. Regards Andreas _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel From xen-devel-bounces@lists.xensource.com Mon Sep 19 06:38:26 2011 Return-path: <xen-devel-bounces@lists.xensource.com> Envelope-to: www-data@lists.xensource.com Delivery-date: Mon, 19 Sep 2011 06:38:26 -0700 Received: from localhost ([127.0.0.1] helo=lists.colo.xensource.com) by lists.xensource.com with esmtp (Exim 4.43) id 1R5e3G-0003bV-0P; Mon, 19 Sep 2011 06:38:26 -0700 Received: from mail182.messagelabs.com ([85.158.139.83]) by lists.xensource.com with esmtp (Exim 4.43) id 1R5e2S-0003P3-Ns for xen-devel@lists.xensource.com; Mon, 19 Sep 2011 06:37:37 -0700 X-Env-Sender: maillists.shan@gmail.com X-Msg-Ref: server-15.tower-182.messagelabs.com!1316439453!17910357!1 X-Originating-IP: [74.125.82.169] X-StarScan-Version: 6.4.1; banners=-,-,- X-VirusChecked: Checked Received: (qmail 16949 invoked from network); 19 Sep 2011 13:37:33 -0000 Received: from mail-wy0-f169.google.com (HELO mail-wy0-f169.google.com) (74.125.82.169) by server-15.tower-182.messagelabs.com with RC4-SHA encrypted SMTP; 19 Sep 2011 13:37:33 -0000 Received: by wyi11 with SMTP id 11so8299100wyi.28 for <xen-devel@lists.xensource.com>; Mon, 19 Sep 2011 06:37:33 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=3Ar624nQRLNkjiGfQIgbU9t6PW114CVCs9SNxYI+dbw=; b=E70SUcfhkds/Tb/eIOgopUoO2VvmsfKOKv0cxYhJa5vjP/hCQHi2EuLiexQ+uHXzRD MsVFwePYaGHlAmTJTlT/nxvmkzG51veJ6bljyaaq4cd9Nk2ccD+j7tO0iV86EsT1hdd5 vbuo0uY0xhViiYogNEKh49XV/6ly+fg7Dxb3U= MIME-Version: 1.0 Received: by 10.227.28.227 with SMTP id n35mr2761518wbc.1.1316439453021; Mon, 19 Sep 2011 06:37:33 -0700 (PDT) Received: by 10.227.143.204 with HTTP; Mon, 19 Sep 2011 06:37:32 -0700 (PDT) In-Reply-To: <CAFQ2Z+eMXPdxjLhyx3Uo_nDhz1BTaaiBJtsUmFrsppznQ2mTUg@mail.gmail.com> References: <CAFQ2Z+dSjU1dStaKyXry_PfRdJpO5k=35ULGPJ8TTj=5wVuW7w@mail.gmail.com> <4E7313510200007800056713@nat28.tlf.novell.com> <CAFQ2Z+eMXPdxjLhyx3Uo_nDhz1BTaaiBJtsUmFrsppznQ2mTUg@mail.gmail.com> Date: Mon, 19 Sep 2011 21:37:32 +0800 Message-ID: <CAFQ2Z+f_wmi0ZHP-NZG7m=K7ugUiEegcTQk1y5PmQ3YObdy4Rg@mail.gmail.com> Subject: Re: [Xen-devel] [PATCH] Fix PV CPUID virtualization of XSave From: Haitao Shan <maillists.shan@gmail.com> To: Jan Beulich <JBeulich@suse.com> Content-Type: multipart/mixed; boundary=0022158df3bff734b704ad4b71b6 Cc: xen-devel@lists.xensource.com, Keir Fraser <keir@xen.org> X-BeenThere: xen-devel@lists.xensource.com X-Mailman-Version: 2.1.5 Precedence: list List-Id: Xen developer discussion <xen-devel.lists.xensource.com> List-Unsubscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe> List-Post: <mailto:xen-devel@lists.xensource.com> List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help> List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=subscribe> Sender: xen-devel-bounces@lists.xensource.com Errors-To: xen-devel-bounces@lists.xensource.com --0022158df3bff734b704ad4b71b6 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Jan, Keir, Updated patch is attached. The patch will fix XSave CPUID virtualization for PV guests. The XSave area size returned by CPUID leaf D is changed dynamically depending on the XCR0. Tools/libxc only assigns a static value. The fix will adjust xsave area size during runtime. Note: This fix is already in HVM cpuid virtualization. And Dom0 is not affected, either. Signed-off-by: Shan Haitao <haitao.shan@intel.com> diff -r e90438f6e6d1 xen/arch/x86/hvm/hvm.c --- a/xen/arch/x86/hvm/hvm.c Wed Sep 14 11:38:13 2011 +0100 +++ b/xen/arch/x86/hvm/hvm.c Mon Sep 19 14:34:15 2011 +0800 @@ -2426,7 +2426,7 @@ void hvm_cpuid(unsigned int input, unsig { /* reset EBX to default value first */ *ebx =3D XSTATE_AREA_MIN_SIZE; - for ( sub_leaf =3D 2; sub_leaf < 64; sub_leaf++ ) + for ( sub_leaf =3D 2; sub_leaf < 63; sub_leaf++ ) { if ( !(v->arch.xcr0 & (1ULL << sub_leaf)) ) continue; diff -r e90438f6e6d1 xen/arch/x86/traps.c --- a/xen/arch/x86/traps.c Wed Sep 14 11:38:13 2011 +0100 +++ b/xen/arch/x86/traps.c Mon Sep 19 14:34:15 2011 +0800 @@ -770,6 +770,30 @@ static void pv_cpuid(struct cpu_user_reg { if ( !cpuid_hypervisor_leaves(a, c, &a, &b, &c, &d) ) domain_cpuid(current->domain, a, c, &a, &b, &c, &d); + + switch ( a ) + { + case 0xd: + { + unsigned int sub_leaf, _eax, _ebx, _ecx, _edx; + /* EBX value of main leaf 0 depends on enabled xsave features = */ + if ( c =3D=3D 0 && current->arch.xcr0 ) + { + /* reset EBX to default value first */ + b =3D XSTATE_AREA_MIN_SIZE; + for ( sub_leaf =3D 2; sub_leaf < 63; sub_leaf++ ) + { + if ( !(current->arch.xcr0 & (1ULL << sub_leaf)) ) + continue; + domain_cpuid(current->domain, a, c, &_eax, &_ebx, &_ec= x, + &_edx); + if ( (_eax + _ebx) > b ) + b =3D _eax + _ebx; + } + } + break; + } + } goto out; } 2011/9/18 Haitao Shan <maillists.shan@gmail.com>: > 2011/9/16 Jan Beulich <JBeulich@suse.com>: >>>>> On 16.09.11 at 02:46, Haitao Shan <maillists.shan@gmail.com> wrote: >>> Hi, Keir, >>> >>> The patch will fix XSave CPUID virtualization for PV guests. The XSave >>> area size returned by CPUID leaf D is changed dynamically depending on >>> the XCR0. Tools/libxc only assigns a static value. The fix will adjust >>> xsave area size during runtime. >>> >>> Note: This fix is already in HVM cpuid virtualization. And Dom0 is not >>> affected, either. >>> >>> Signed-off-by: =A0Shan Haitao <haitao.shan@intel.com> >>> >>> Shan Haitao >>> >>> diff -r 5fe770c8a8a3 xen/arch/x86/traps.c >>> --- a/xen/arch/x86/traps.c =A0 =A0Tue Sep 06 15:49:40 2011 +0100 >>> +++ b/xen/arch/x86/traps.c =A0 =A0Wed Sep 07 02:09:12 2011 +0800 >>> @@ -770,6 +770,30 @@ static void pv_cpuid(struct cpu_user_reg >>> =A0 =A0 =A0{ >>> =A0 =A0 =A0 =A0 =A0if ( !cpuid_hypervisor_leaves(a, c, &a, &b, &c, &d) = ) >>> =A0 =A0 =A0 =A0 =A0 =A0 =A0domain_cpuid(current->domain, a, c, &a, &b, = &c, &d); >>> + >>> + =A0 =A0 =A0 =A0switch ( a ) >>> + =A0 =A0 =A0 =A0{ >>> + =A0 =A0 =A0 =A0case 0xd: >>> + =A0 =A0 =A0 =A0{ >>> + =A0 =A0 =A0 =A0 =A0 =A0unsigned int sub_leaf, _eax, _ebx, _ecx, _edx; >>> + =A0 =A0 =A0 =A0 =A0 =A0/* EBX value of main leaf 0 depends on enabled= xsave features >>> */ >>> + =A0 =A0 =A0 =A0 =A0 =A0if ( c =3D=3D 0 && current->arch.xcr0 ) >>> + =A0 =A0 =A0 =A0 =A0 =A0{ >>> + =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0/* reset EBX to default value first */ >>> + =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0b =3D XSTATE_AREA_MIN_SIZE; >>> + =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0for ( sub_leaf =3D 2; sub_leaf < 64; s= ub_leaf++ ) >> >> Shouldn't the upper bound be 63 here (as bit 63 serves a different >> purpose, and if that bit was set code changes would be required in >> various other places)? >> >> Jan > Nice catch! I will update the patch. The same piece of code is > borrowed from hvm_cpuid(), where I can change the value from 64 to 63, > too. > > Shan Haitao > >> >>> + =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0{ >>> + =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0if ( !(current->arch.xcr0 & (1= ULL << sub_leaf)) ) >>> + =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0continue; >>> + =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0domain_cpuid(current->domain, = a, c, &_eax, &_ebx, &_ecx, >>> + =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 &_edx= ); >>> + =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0if ( (_eax + _ebx) > b ) >>> + =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0b =3D _eax + _ebx; >>> + =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0} >>> + =A0 =A0 =A0 =A0 =A0 =A0} >>> + =A0 =A0 =A0 =A0break; >>> + =A0 =A0 =A0 =A0} >>> + =A0 =A0 =A0 =A0} >>> =A0 =A0 =A0 =A0 =A0goto out; >>> =A0 =A0 =A0} >> >> >> >> > --0022158df3bff734b704ad4b71b6 Content-Type: application/octet-stream; name="pv_xsave_cpuid_fix.patch" Content-Disposition: attachment; filename="pv_xsave_cpuid_fix.patch" Content-Transfer-Encoding: base64 X-Attachment-Id: f_gsrhzczl0 ZGlmZiAtciBlOTA0MzhmNmU2ZDEgeGVuL2FyY2gveDg2L2h2bS9odm0uYwotLS0gYS94ZW4vYXJj aC94ODYvaHZtL2h2bS5jCVdlZCBTZXAgMTQgMTE6Mzg6MTMgMjAxMSArMDEwMAorKysgYi94ZW4v YXJjaC94ODYvaHZtL2h2bS5jCU1vbiBTZXAgMTkgMTQ6MzQ6MTUgMjAxMSArMDgwMApAQCAtMjQy Niw3ICsyNDI2LDcgQEAgdm9pZCBodm1fY3B1aWQodW5zaWduZWQgaW50IGlucHV0LCB1bnNpZwog ICAgICAgICB7CiAgICAgICAgICAgICAvKiByZXNldCBFQlggdG8gZGVmYXVsdCB2YWx1ZSBmaXJz dCAqLwogICAgICAgICAgICAgKmVieCA9IFhTVEFURV9BUkVBX01JTl9TSVpFOyAKLSAgICAgICAg ICAgIGZvciAoIHN1Yl9sZWFmID0gMjsgc3ViX2xlYWYgPCA2NDsgc3ViX2xlYWYrKyApCisgICAg ICAgICAgICBmb3IgKCBzdWJfbGVhZiA9IDI7IHN1Yl9sZWFmIDwgNjM7IHN1Yl9sZWFmKysgKQog ICAgICAgICAgICAgewogICAgICAgICAgICAgICAgIGlmICggISh2LT5hcmNoLnhjcjAgJiAoMVVM TCA8PCBzdWJfbGVhZikpICkKICAgICAgICAgICAgICAgICAgICAgY29udGludWU7CmRpZmYgLXIg ZTkwNDM4ZjZlNmQxIHhlbi9hcmNoL3g4Ni90cmFwcy5jCi0tLSBhL3hlbi9hcmNoL3g4Ni90cmFw cy5jCVdlZCBTZXAgMTQgMTE6Mzg6MTMgMjAxMSArMDEwMAorKysgYi94ZW4vYXJjaC94ODYvdHJh cHMuYwlNb24gU2VwIDE5IDE0OjM0OjE1IDIwMTEgKzA4MDAKQEAgLTc3MCw2ICs3NzAsMzAgQEAg c3RhdGljIHZvaWQgcHZfY3B1aWQoc3RydWN0IGNwdV91c2VyX3JlZwogICAgIHsKICAgICAgICAg aWYgKCAhY3B1aWRfaHlwZXJ2aXNvcl9sZWF2ZXMoYSwgYywgJmEsICZiLCAmYywgJmQpICkKICAg ICAgICAgICAgIGRvbWFpbl9jcHVpZChjdXJyZW50LT5kb21haW4sIGEsIGMsICZhLCAmYiwgJmMs ICZkKTsKKworICAgICAgICBzd2l0Y2ggKCBhICkKKyAgICAgICAgeworICAgICAgICBjYXNlIDB4 ZDoKKyAgICAgICAgeworICAgICAgICAgICAgdW5zaWduZWQgaW50IHN1Yl9sZWFmLCBfZWF4LCBf ZWJ4LCBfZWN4LCBfZWR4OworICAgICAgICAgICAgLyogRUJYIHZhbHVlIG9mIG1haW4gbGVhZiAw IGRlcGVuZHMgb24gZW5hYmxlZCB4c2F2ZSBmZWF0dXJlcyAqLworICAgICAgICAgICAgaWYgKCBj ID09IDAgJiYgY3VycmVudC0+YXJjaC54Y3IwICkKKyAgICAgICAgICAgIHsKKyAgICAgICAgICAg ICAgICAvKiByZXNldCBFQlggdG8gZGVmYXVsdCB2YWx1ZSBmaXJzdCAqLworICAgICAgICAgICAg ICAgIGIgPSBYU1RBVEVfQVJFQV9NSU5fU0laRTsKKyAgICAgICAgICAgICAgICBmb3IgKCBzdWJf bGVhZiA9IDI7IHN1Yl9sZWFmIDwgNjM7IHN1Yl9sZWFmKysgKQorICAgICAgICAgICAgICAgIHsK KyAgICAgICAgICAgICAgICAgICAgaWYgKCAhKGN1cnJlbnQtPmFyY2gueGNyMCAmICgxVUxMIDw8 IHN1Yl9sZWFmKSkgKQorICAgICAgICAgICAgICAgICAgICAgICAgY29udGludWU7CisgICAgICAg ICAgICAgICAgICAgIGRvbWFpbl9jcHVpZChjdXJyZW50LT5kb21haW4sIGEsIGMsICZfZWF4LCAm X2VieCwgJl9lY3gsCisgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAmX2VkeCk7Cisg ICAgICAgICAgICAgICAgICAgIGlmICggKF9lYXggKyBfZWJ4KSA+IGIgKQorICAgICAgICAgICAg ICAgICAgICAgICAgYiA9IF9lYXggKyBfZWJ4OworICAgICAgICAgICAgICAgIH0KKyAgICAgICAg ICAgIH0KKyAgICAgICAgYnJlYWs7CisgICAgICAgIH0KKyAgICAgICAgfQogICAgICAgICBnb3Rv IG91dDsKICAgICB9CiAK --0022158df3bff734b704ad4b71b6 Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel --0022158df3bff734b704ad4b71b6-- From xen-devel-bounces@lists.xensource.com Mon Sep 19 07:03:31 2011 Return-path: <xen-devel-bounces@lists.xensource.com> Envelope-to: www-data@lists.xensource.com Delivery-date: Mon, 19 Sep 2011 07:03:31 -0700 Received: from localhost ([127.0.0.1] helo=lists.colo.xensource.com) by lists.xensource.com with esmtp (Exim 4.43) id 1R5eRX-0004Vq-0X; Mon, 19 Sep 2011 07:03:31 -0700 Received: from mail27.messagelabs.com ([193.109.254.147]) by lists.xensource.com with smtp (Exim 4.43) id 1R5eNE-00048t-1E for xen-devel@lists.xensource.com; Mon, 19 Sep 2011 06:59:23 -0700 X-Env-Sender: tobias.geiger@vido.info X-Msg-Ref: server-15.tower-27.messagelabs.com!1316440732!49389802!1 X-Originating-IP: [78.47.43.171] X-StarScan-Version: 6.4.1; banners=-,-,- X-VirusChecked: Checked Received: (qmail 26655 invoked from network); 19 Sep 2011 13:58:52 -0000 Received: from www.vido.info (HELO mail.vido.info) (78.47.43.171) by server-15.tower-27.messagelabs.com with SMTP; 19 Sep 2011 13:58:52 -0000 Received: from localhost (ip6-localhost [127.0.0.1]) by mail.vido.info (Postfix) with ESMTP id 9E3A9D3482B; Mon, 19 Sep 2011 15:59:00 +0200 (CEST) X-Virus-Scanned: by amavis at mail.vido.info Received: from mail.vido.info ([127.0.0.1]) by localhost (mail.vido.info [127.0.0.1]) (amavisd-new, port 10024) with LMTP id fd5cadOqyb11; Mon, 19 Sep 2011 15:58:53 +0200 (CEST) Received: from lxgeigert.localnet (et-1-10.gw-nat.bs.kae.de.oneandone.net [212.227.35.74]) by mail.vido.info (Postfix) with ESMTPSA id D144BD348A6; Mon, 19 Sep 2011 15:58:46 +0200 (CEST) From: Tobias Geiger <tobias.geiger@vido.info> Organization: VIDO IT-Service To: xen-devel@lists.xensource.com Subject: Re: [Xen-devel] Re: Graphics passthrough related issue Date: Mon, 19 Sep 2011 15:58:45 +0200 User-Agent: KMail/1.13.7 (Linux/2.6.39-2-amd64; KDE/4.6.5; x86_64; ; ) References: <CA+PhxFdtdKqTWA9rD3M6s8VS=WMaBV3oQuicV8JW5wCir=iHnA@mail.gmail.com> <CA+PhxFepcRHQKczKwGeQLWR2QGx+UpqT1Sts3szSnjfQLVieAA@mail.gmail.com> In-Reply-To: <CA+PhxFepcRHQKczKwGeQLWR2QGx+UpqT1Sts3szSnjfQLVieAA@mail.gmail.com> MIME-Version: 1.0 Content-Type: Text/Plain; charset="iso-8859-15" Content-Transfer-Encoding: 7bit Message-Id: <201109191558.46089.tobias.geiger@vido.info> Cc: Dushmanta Mohapatra <dushmanta.mohapatra@gmail.com> X-BeenThere: xen-devel@lists.xensource.com X-Mailman-Version: 2.1.5 Precedence: list List-Id: Xen developer discussion <xen-devel.lists.xensource.com> List-Unsubscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe> List-Post: <mailto:xen-devel@lists.xensource.com> List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help> List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=subscribe> Sender: xen-devel-bounces@lists.xensource.com Errors-To: xen-devel-bounces@lists.xensource.com Am Montag, 19. September 2011, 09:18:13 schrieb Dushmanta Mohapatra: > > I have an Intel Integrated Graphics Controller. > > I can pass through the graphics device (using boot time passthrough) and > > the HVM DomUs boot fine and show me the log in screen. i.e. gfx passthrough works for you. if i understand you correctly, your problem is "only" the mouse/keyboard passthrough. try to not passthrough any usb-controller (i guess your internal keyboard/mouse is internally attached to one of the pci-id's you'r passing through) for mouse/keyboard inside your guest try: 1st: quick option: vnc to localhost:5900 - qemu does a horrible job, but its better than nothing 2nd: try with synergy - best option, even games work with it (as long as you LOCK the mouse on the guest-machine with SCROLL LOCK) 3rd: ugly but working: http://usbip.sourceforge.net ; tried it successfuly with a mouse and other peripheral usb hardware - as long as its no webcam or dvb-stick it may work good luck! Greetings Tobias _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel From xen-devel-bounces@lists.xensource.com Mon Sep 19 08:51:36 2011 Return-path: <xen-devel-bounces@lists.xensource.com> Envelope-to: www-data@lists.xensource.com Delivery-date: Mon, 19 Sep 2011 08:51:36 -0700 Received: from localhost ([127.0.0.1] helo=lists.colo.xensource.com) by lists.xensource.com with esmtp (Exim 4.43) id 1R5g88-0007C2-6E; Mon, 19 Sep 2011 08:51:36 -0700 Received: from mail216.messagelabs.com ([85.158.143.99]) by lists.xensource.com with smtp (Exim 4.43) id 1R5g7J-0006zf-0r for xen-devel@lists.xensource.com; Mon, 19 Sep 2011 08:50:45 -0700 X-Env-Sender: dgdegra@tycho.nsa.gov X-Msg-Ref: server-12.tower-216.messagelabs.com!1316447441!13097438!1 X-Originating-IP: [63.239.65.40] X-StarScan-Version: 6.4.1; banners=-,-,- X-VirusChecked: Checked Received: (qmail 24415 invoked from network); 19 Sep 2011 15:50:41 -0000 Received: from msux-gh1-uea02.nsa.gov (HELO msux-gh1-uea02.nsa.gov) (63.239.65.40) by server-12.tower-216.messagelabs.com with SMTP; 19 Sep 2011 15:50:41 -0000 Received: from tarius.tycho.ncsc.mil (localhost [127.0.0.1]) by msux-gh1-uea02.nsa.gov (8.12.10/8.12.10) with ESMTP id p8JFoaR7022666; Mon, 19 Sep 2011 15:50:36 GMT Received: from moss-nexus.epoch.ncsc.mil (moss-nexus [144.51.25.48]) by tarius.tycho.ncsc.mil (8.13.1/8.13.1) with ESMTP id p8JFoXBV025975; Mon, 19 Sep 2011 11:50:35 -0400 Message-ID: <4E7764D2.4070803@tycho.nsa.gov> Date: Mon, 19 Sep 2011 11:50:42 -0400 From: Daniel De Graaf <dgdegra@tycho.nsa.gov> Organization: National Security Agency User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:6.0) Gecko/20110816 Thunderbird/6.0 MIME-Version: 1.0 To: Jeremy Fitzhardinge <jeremy@goop.org> Subject: Re: [Xen-devel] [PATCH 1/2] xen/event: Add reference counting to event channel References: <1316207684-19860-1-git-send-email-dgdegra@tycho.nsa.gov> <1316207684-19860-2-git-send-email-dgdegra@tycho.nsa.gov> <4E742703.7050005@goop.org> In-Reply-To: <4E742703.7050005@goop.org> X-Enigmail-Version: 1.3 Content-Type: text/plain; charset=ISO-8859-15 Content-Transfer-Encoding: 7bit Cc: xen-devel@lists.xensource.com, Ian Jackson <Ian.Jackson@eu.citrix.com>, Keir Fraser <keir.fraser@eu.citrix.com>, konrad.wilk@oracle.com X-BeenThere: xen-devel@lists.xensource.com X-Mailman-Version: 2.1.5 Precedence: list List-Id: Xen developer discussion <xen-devel.lists.xensource.com> List-Unsubscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe> List-Post: <mailto:xen-devel@lists.xensource.com> List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help> List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=subscribe> Sender: xen-devel-bounces@lists.xensource.com Errors-To: xen-devel-bounces@lists.xensource.com On 09/17/2011 12:50 AM, Jeremy Fitzhardinge wrote: > On 09/16/2011 02:14 PM, Daniel De Graaf wrote: >> Event channels exposed to userspace by the evtchn module may be used by >> other modules in an asynchronous manner, which requires that reference >> counting be used to prevent the event channel from being closed before >> the signals are delivered. > > Could you use the refcounting at the irq level? I was quite pleased to > have removed the event channel refcounting (and the use of naked event > channels). This looked more complex: unbind_from_irq has cleanup that happens after EVTCHNOP_close but before the irq-refcount-protected close operation. For the IRQ-level refcounting to be useful here, the EVTCHNOP_close would have to be postponed. The evtchn_to_irq mapping is also maintained here. > Oh, is it that userspace allocates an event channel with /dev/evtchn, > then passes that event channel to the gntalloc/gntdev drivers so they > can use it to pass events between the two. That's a bit unfortunate; it > might have been better to expose those event channels as file > descriptors so you could use fd refcounting to manage the lifetimes. This would also make event channels simpler to use from userspace, avoiding the extra read() to determine what event channel has fired (and avoiding almost all userspace knowledge of the local event channel number). However, this would require practically rewriting the /dev/xen/evtchn userspace API. With the current event channel API, you would have to pass both the event channel number and the evtchn file descriptor in order to get an fd reference which seems redundant and might cause confusion since keeping the fd reference would also prevent cleanup of other event channels associated with the shared file descriptor. It would also require changing the notify ioctl parameters since there is currently no need to pass an evtchn fd. > What's the downside of sending the event after the event channel has closed? The event won't get sent at all, since the hypervisor sees that the local end of the event channel is closed. If the local event channel number happens to get reused, the event could also get sent to the wrong event channel, although this is generally harmless. > That said: > >> >> Signed-off-by: Daniel De Graaf <dgdegra@tycho.nsa.gov> >> --- >> drivers/xen/events.c | 38 ++++++++++++++++++++++++++++++++++++++ >> include/xen/events.h | 6 ++++++ >> 2 files changed, 44 insertions(+), 0 deletions(-) >> >> diff --git a/drivers/xen/events.c b/drivers/xen/events.c >> index da70f5c..c9343b9 100644 >> --- a/drivers/xen/events.c >> +++ b/drivers/xen/events.c >> @@ -89,6 +89,7 @@ struct irq_info >> { >> struct list_head list; >> enum xen_irq_type type; /* type */ >> + unsigned short refcount; > > Is short large enough? Is this something that untrusted userspace could > end up wrapping? If short is sufficient, you should pack it next to the > other short fields to avoid a gap. This would be quite difficult: since only gntdev/gntalloc use these counts for now, you would have to map or allocate 64K pages; the gntalloc driver has a default limit of 1024 pages and gntdev is limited by the hypervisor max_nr_grant_frames. Anyway, changing to atomic_t should >> unsigned irq; >> unsigned short evtchn; /* event channel */ >> unsigned short cpu; /* cpu bound */ >> @@ -407,6 +408,7 @@ static void xen_irq_init(unsigned irq) >> panic("Unable to allocate metadata for IRQ%d\n", irq); >> >> info->type = IRQT_UNBOUND; >> + info->refcount = 1; >> >> irq_set_handler_data(irq, info); >> >> @@ -469,6 +471,8 @@ static void xen_free_irq(unsigned irq) >> >> irq_set_handler_data(irq, NULL); >> >> + BUG_ON(info->refcount > 1); >> + >> kfree(info); >> >> /* Legacy IRQ descriptors are managed by the arch. */ >> @@ -912,9 +916,14 @@ static void unbind_from_irq(unsigned int irq) >> { >> struct evtchn_close close; >> int evtchn = evtchn_from_irq(irq); >> + struct irq_info *info = irq_get_handler_data(irq); >> >> spin_lock(&irq_mapping_update_lock); >> >> + info->refcount--; >> + if (info->refcount > 0) >> + goto out_unlock; >> + >> if (VALID_EVTCHN(evtchn)) { >> close.port = evtchn; >> if (HYPERVISOR_event_channel_op(EVTCHNOP_close, &close) != 0) >> @@ -943,6 +952,7 @@ static void unbind_from_irq(unsigned int irq) >> >> xen_free_irq(irq); >> >> + out_unlock: >> spin_unlock(&irq_mapping_update_lock); >> } >> >> @@ -1038,6 +1048,34 @@ void unbind_from_irqhandler(unsigned int irq, void *dev_id) >> } >> EXPORT_SYMBOL_GPL(unbind_from_irqhandler); >> >> +int get_evtchn_reservation(unsigned int evtchn) > "reservation"? I think just evtchn_get/put would be more consistent > with kernel naming conventions. Yes. >> +{ >> + int irq = evtchn_to_irq[evtchn]; >> + struct irq_info *info; >> + >> + if (irq == -1) >> + return -ENOENT; >> + >> + info = irq_get_handler_data(irq); >> + >> + if (!info) >> + return -ENOENT; >> + >> + spin_lock(&irq_mapping_update_lock); >> + info->refcount++; >> + spin_unlock(&irq_mapping_update_lock); > > What is this spinlock protecting against? The non-atomicity of ++, or > something larger scale? If its just an atomicity thing, should it be an > atomic_t? Just atomicity. >> + >> + return 0; >> +} >> +EXPORT_SYMBOL_GPL(get_evtchn_reservation); >> + >> +void put_evtchn_reservation(unsigned int evtchn) >> +{ >> + int irq = evtchn_to_irq[evtchn]; >> + unbind_from_irq(irq); > > Hm. Similar name change here. >> +} >> +EXPORT_SYMBOL_GPL(put_evtchn_reservation); >> + >> void xen_send_IPI_one(unsigned int cpu, enum ipi_vector vector) >> { >> int irq = per_cpu(ipi_to_irq, cpu)[vector]; >> diff --git a/include/xen/events.h b/include/xen/events.h >> index d287997..23bd5fd 100644 >> --- a/include/xen/events.h >> +++ b/include/xen/events.h >> @@ -37,6 +37,12 @@ int bind_interdomain_evtchn_to_irqhandler(unsigned int remote_domain, >> */ >> void unbind_from_irqhandler(unsigned int irq, void *dev_id); >> >> +/* >> + * Allow extra references to event channels exposed to userspace by evtchn >> + */ >> +int get_evtchn_reservation(unsigned int evtchn); >> +void put_evtchn_reservation(unsigned int evtchn); >> + >> void xen_send_IPI_one(unsigned int cpu, enum ipi_vector vector); >> int resend_irq_on_evtchn(unsigned int irq); >> void rebind_evtchn_irq(int evtchn, int irq); > -- Daniel De Graaf National Security Agency _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel From xen-devel-bounces@lists.xensource.com Mon Sep 19 08:54:14 2011 Return-path: <xen-devel-bounces@lists.xensource.com> Envelope-to: www-data@lists.xensource.com Delivery-date: Mon, 19 Sep 2011 08:54:14 -0700 Received: from localhost ([127.0.0.1] helo=lists.colo.xensource.com) by lists.xensource.com with esmtp (Exim 4.43) id 1R5gAg-0007ao-Ii; Mon, 19 Sep 2011 08:54:14 -0700 Received: from mail182.messagelabs.com ([85.158.139.83]) by lists.xensource.com with esmtp (Exim 4.43) id 1R5gAE-0007OU-IA for xen-devel@lists.xensource.com; Mon, 19 Sep 2011 08:53:46 -0700 X-Env-Sender: dunlapg@gmail.com X-Msg-Ref: server-3.tower-182.messagelabs.com!1316447623!16148045!1 X-Originating-IP: [74.125.82.169] X-StarScan-Version: 6.4.1; banners=-,-,- X-VirusChecked: Checked Received: (qmail 28855 invoked from network); 19 Sep 2011 15:53:43 -0000 Received: from mail-wy0-f169.google.com (HELO mail-wy0-f169.google.com) (74.125.82.169) by server-3.tower-182.messagelabs.com with RC4-SHA encrypted SMTP; 19 Sep 2011 15:53:43 -0000 Received: by wyi11 with SMTP id 11so8499571wyi.28 for <xen-devel@lists.xensource.com>; Mon, 19 Sep 2011 08:53:43 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=SVf8u72fgncu1AMY9F9ktgw1pxMbGDWl3eciPiVveZA=; b=NTOyLw1DUofNwJBscC/dvhvBtC9+bUmXfQCSwuP9MsJqnEhGMUnFAGrQVgQOZmJs3K jR02E5kMmeD62L5SpLCamdAyauNtevT9WAZQ5BTXWuRUBT74eGv2i7Y1hPCFAN6CtKvp LJTjgKfBAArVBx6PPC3a14IwOm1b0YF1Od11E= MIME-Version: 1.0 Received: by 10.216.154.145 with SMTP id h17mr3053402wek.39.1316447623294; Mon, 19 Sep 2011 08:53:43 -0700 (PDT) Received: by 10.216.176.81 with HTTP; Mon, 19 Sep 2011 08:53:43 -0700 (PDT) In-Reply-To: <CAEAezkXxOy+660fA8sV=pQsZ7vkRO8bFMPGOns1N3zP1QzPTXg@mail.gmail.com> References: <CAEAezkXxOy+660fA8sV=pQsZ7vkRO8bFMPGOns1N3zP1QzPTXg@mail.gmail.com> Date: Mon, 19 Sep 2011 16:53:43 +0100 X-Google-Sender-Auth: C8529Svu8-8vpLKZn4J6aD2W-bQ Message-ID: <CAFLBxZaNmyJ8JfNtoPPV8tsPRjy-=zDL0ooDRzE1rEqM0NC2ZA@mail.gmail.com> Subject: Re: [Xen-devel] credit scheduler From: George Dunlap <George.Dunlap@eu.citrix.com> To: Pratik shinde <pracshi@gmail.com> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: xen-devel@lists.xensource.com X-BeenThere: xen-devel@lists.xensource.com X-Mailman-Version: 2.1.5 Precedence: list List-Id: Xen developer discussion <xen-devel.lists.xensource.com> List-Unsubscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe> List-Post: <mailto:xen-devel@lists.xensource.com> List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help> List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=subscribe> Sender: xen-devel-bounces@lists.xensource.com Errors-To: xen-devel-bounces@lists.xensource.com It's hard to know what kind of answer you want. The credits are distributed to vcpus in xen/common/sched_credit.c:csched_acct(). Do you have a specific question about the algorithm there? -George On Sun, Sep 18, 2011 at 4:21 PM, Pratik shinde <pracshi@gmail.com> wrote: > sir, > =A0thank you for replaying my mail > =A0=A0 i am reading xen credit scheduler but i am not getting how credit > scheduler distribute the credits among virtual machines.or specifically h= ow > it decides the credit to be given.sorry sir,this would be an insane quest= ion > but i was finding answer to this question since last two days. > > _______________________________________________ > Xen-devel mailing list > Xen-devel@lists.xensource.com > http://lists.xensource.com/xen-devel > > _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel From xen-devel-bounces@lists.xensource.com Mon Sep 19 09:22:59 2011 Return-path: <xen-devel-bounces@lists.xensource.com> Envelope-to: www-data@lists.xensource.com Delivery-date: Mon, 19 Sep 2011 09:22:59 -0700 Received: from localhost ([127.0.0.1] helo=lists.colo.xensource.com) by lists.xensource.com with esmtp (Exim 4.43) id 1R5gcV-00027V-Or; Mon, 19 Sep 2011 09:22:59 -0700 Received: from mail174.messagelabs.com ([85.158.138.51]) by lists.xensource.com with esmtp (Exim 4.43) id 1R5gbl-0001vF-E8 for xen-devel@lists.xensource.com; Mon, 19 Sep 2011 09:22:14 -0700 X-Env-Sender: jeremy@goop.org X-Msg-Ref: server-2.tower-174.messagelabs.com!1316449328!32004523!1 X-Originating-IP: [74.207.240.146] X-StarScan-Version: 6.4.1; banners=-,-,- X-VirusChecked: Checked Received: (qmail 18095 invoked from network); 19 Sep 2011 16:22:10 -0000 Received: from claw.goop.org (HELO claw.goop.org) (74.207.240.146) by server-2.tower-174.messagelabs.com with DHE-RSA-AES256-SHA encrypted SMTP; 19 Sep 2011 16:22:10 -0000 Received: from saboo.goop.org (unknown [IPv6:2001:470:1f05:899:48e3:deff:fe6d:1bda]) (Authenticated sender: smtp-saboo) by claw.goop.org (Postfix) with ESMTPSA id 4AA468A76; Mon, 19 Sep 2011 09:22:07 -0700 (PDT) Received: from saboo.goop.org (localhost [IPv6:::1]) by saboo.goop.org (Postfix) with ESMTP id B620320B0C; Mon, 19 Sep 2011 09:22:03 -0700 (PDT) Message-ID: <4E776C2B.9050405@goop.org> Date: Mon, 19 Sep 2011 09:22:03 -0700 From: Jeremy Fitzhardinge <jeremy@goop.org> User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:6.0.2) Gecko/20110906 Thunderbird/6.0.2 MIME-Version: 1.0 To: Daniel De Graaf <dgdegra@tycho.nsa.gov> Subject: Re: [Xen-devel] [PATCH 1/2] xen/event: Add reference counting to event channel References: <1316207684-19860-1-git-send-email-dgdegra@tycho.nsa.gov> <1316207684-19860-2-git-send-email-dgdegra@tycho.nsa.gov> <4E742703.7050005@goop.org> <4E7764D2.4070803@tycho.nsa.gov> In-Reply-To: <4E7764D2.4070803@tycho.nsa.gov> X-Enigmail-Version: 1.3.1 Content-Type: text/plain; charset=ISO-8859-15 Content-Transfer-Encoding: 7bit Cc: Keir Fraser <keir@xen.org>, xen-devel@lists.xensource.com, Ian Jackson <Ian.Jackson@eu.citrix.com>, konrad.wilk@oracle.com X-BeenThere: xen-devel@lists.xensource.com X-Mailman-Version: 2.1.5 Precedence: list List-Id: Xen developer discussion <xen-devel.lists.xensource.com> List-Unsubscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe> List-Post: <mailto:xen-devel@lists.xensource.com> List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help> List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=subscribe> Sender: xen-devel-bounces@lists.xensource.com Errors-To: xen-devel-bounces@lists.xensource.com On 09/19/2011 08:50 AM, Daniel De Graaf wrote: > On 09/17/2011 12:50 AM, Jeremy Fitzhardinge wrote: >> On 09/16/2011 02:14 PM, Daniel De Graaf wrote: >>> Event channels exposed to userspace by the evtchn module may be used by >>> other modules in an asynchronous manner, which requires that reference >>> counting be used to prevent the event channel from being closed before >>> the signals are delivered. >> Could you use the refcounting at the irq level? I was quite pleased to >> have removed the event channel refcounting (and the use of naked event >> channels). > This looked more complex: unbind_from_irq has cleanup that happens after > EVTCHNOP_close but before the irq-refcount-protected close operation. > For the IRQ-level refcounting to be useful here, the EVTCHNOP_close would > have to be postponed. The evtchn_to_irq mapping is also maintained here. > >> Oh, is it that userspace allocates an event channel with /dev/evtchn, >> then passes that event channel to the gntalloc/gntdev drivers so they >> can use it to pass events between the two. That's a bit unfortunate; it >> might have been better to expose those event channels as file >> descriptors so you could use fd refcounting to manage the lifetimes. > This would also make event channels simpler to use from userspace, avoiding > the extra read() to determine what event channel has fired (and avoiding > almost all userspace knowledge of the local event channel number). However, > this would require practically rewriting the /dev/xen/evtchn userspace API. If you had an app which cared about many events, then having an fd for each would be pretty cumbersome. But perhaps it would be worth considering extending the current API a bit to add a general "set of events fd", where a given event can be the member of multiple sets. > With the current event channel API, you would have to pass both the event > channel number and the evtchn file descriptor in order to get an fd reference > which seems redundant and might cause confusion since keeping the fd > reference would also prevent cleanup of other event channels associated with > the shared file descriptor. It would also require changing the notify ioctl > parameters since there is currently no need to pass an evtchn fd. Yes, though there's no reason even now one couldn't be careful to bind your events to a given fd where they share similar lifetimes/uses (even to the extent of allocating single-event fds). On the other hand, is there really a need to make a connection between the gnt and evtchn devices? Why couldn't the gnt driver just do its own form of event fd and management independent of /dev/evtchn? I know it seems a bit redundant, but coupling the two adds its own complexities. >> What's the downside of sending the event after the event channel has closed? > The event won't get sent at all, since the hypervisor sees that the local > end of the event channel is closed. If the local event channel number > happens to get reused, the event could also get sent to the wrong event > channel, although this is generally harmless. I think /dev/evtchn port numbers are never reused. And it sounds like it is purely a usermode problem if they close the event channel prematurely. J >> That said: >> >>> Signed-off-by: Daniel De Graaf <dgdegra@tycho.nsa.gov> >>> --- >>> drivers/xen/events.c | 38 ++++++++++++++++++++++++++++++++++++++ >>> include/xen/events.h | 6 ++++++ >>> 2 files changed, 44 insertions(+), 0 deletions(-) >>> >>> diff --git a/drivers/xen/events.c b/drivers/xen/events.c >>> index da70f5c..c9343b9 100644 >>> --- a/drivers/xen/events.c >>> +++ b/drivers/xen/events.c >>> @@ -89,6 +89,7 @@ struct irq_info >>> { >>> struct list_head list; >>> enum xen_irq_type type; /* type */ >>> + unsigned short refcount; >> Is short large enough? Is this something that untrusted userspace could >> end up wrapping? If short is sufficient, you should pack it next to the >> other short fields to avoid a gap. > This would be quite difficult: since only gntdev/gntalloc use these counts > for now, you would have to map or allocate 64K pages; the gntalloc driver > has a default limit of 1024 pages and gntdev is limited by the hypervisor > max_nr_grant_frames. > > Anyway, changing to atomic_t should > >>> unsigned irq; >>> unsigned short evtchn; /* event channel */ >>> unsigned short cpu; /* cpu bound */ >>> @@ -407,6 +408,7 @@ static void xen_irq_init(unsigned irq) >>> panic("Unable to allocate metadata for IRQ%d\n", irq); >>> >>> info->type = IRQT_UNBOUND; >>> + info->refcount = 1; >>> >>> irq_set_handler_data(irq, info); >>> >>> @@ -469,6 +471,8 @@ static void xen_free_irq(unsigned irq) >>> >>> irq_set_handler_data(irq, NULL); >>> >>> + BUG_ON(info->refcount > 1); >>> + >>> kfree(info); >>> >>> /* Legacy IRQ descriptors are managed by the arch. */ >>> @@ -912,9 +916,14 @@ static void unbind_from_irq(unsigned int irq) >>> { >>> struct evtchn_close close; >>> int evtchn = evtchn_from_irq(irq); >>> + struct irq_info *info = irq_get_handler_data(irq); >>> >>> spin_lock(&irq_mapping_update_lock); >>> >>> + info->refcount--; >>> + if (info->refcount > 0) >>> + goto out_unlock; >>> + >>> if (VALID_EVTCHN(evtchn)) { >>> close.port = evtchn; >>> if (HYPERVISOR_event_channel_op(EVTCHNOP_close, &close) != 0) >>> @@ -943,6 +952,7 @@ static void unbind_from_irq(unsigned int irq) >>> >>> xen_free_irq(irq); >>> >>> + out_unlock: >>> spin_unlock(&irq_mapping_update_lock); >>> } >>> >>> @@ -1038,6 +1048,34 @@ void unbind_from_irqhandler(unsigned int irq, void *dev_id) >>> } >>> EXPORT_SYMBOL_GPL(unbind_from_irqhandler); >>> >>> +int get_evtchn_reservation(unsigned int evtchn) >> "reservation"? I think just evtchn_get/put would be more consistent >> with kernel naming conventions. > Yes. > >>> +{ >>> + int irq = evtchn_to_irq[evtchn]; >>> + struct irq_info *info; >>> + >>> + if (irq == -1) >>> + return -ENOENT; >>> + >>> + info = irq_get_handler_data(irq); >>> + >>> + if (!info) >>> + return -ENOENT; >>> + >>> + spin_lock(&irq_mapping_update_lock); >>> + info->refcount++; >>> + spin_unlock(&irq_mapping_update_lock); >> What is this spinlock protecting against? The non-atomicity of ++, or >> something larger scale? If its just an atomicity thing, should it be an >> atomic_t? > Just atomicity. > >>> + >>> + return 0; >>> +} >>> +EXPORT_SYMBOL_GPL(get_evtchn_reservation); >>> + >>> +void put_evtchn_reservation(unsigned int evtchn) >>> +{ >>> + int irq = evtchn_to_irq[evtchn]; >>> + unbind_from_irq(irq); >> Hm. > Similar name change here. > >>> +} >>> +EXPORT_SYMBOL_GPL(put_evtchn_reservation); >>> + >>> void xen_send_IPI_one(unsigned int cpu, enum ipi_vector vector) >>> { >>> int irq = per_cpu(ipi_to_irq, cpu)[vector]; >>> diff --git a/include/xen/events.h b/include/xen/events.h >>> index d287997..23bd5fd 100644 >>> --- a/include/xen/events.h >>> +++ b/include/xen/events.h >>> @@ -37,6 +37,12 @@ int bind_interdomain_evtchn_to_irqhandler(unsigned int remote_domain, >>> */ >>> void unbind_from_irqhandler(unsigned int irq, void *dev_id); >>> >>> +/* >>> + * Allow extra references to event channels exposed to userspace by evtchn >>> + */ >>> +int get_evtchn_reservation(unsigned int evtchn); >>> +void put_evtchn_reservation(unsigned int evtchn); >>> + >>> void xen_send_IPI_one(unsigned int cpu, enum ipi_vector vector); >>> int resend_irq_on_evtchn(unsigned int irq); >>> void rebind_evtchn_irq(int evtchn, int irq); > _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel From xen-devel-bounces@lists.xensource.com Mon Sep 19 09:32:26 2011 Return-path: <xen-devel-bounces@lists.xensource.com> Envelope-to: www-data@lists.xensource.com Delivery-date: Mon, 19 Sep 2011 09:32:26 -0700 Received: from localhost ([127.0.0.1] helo=lists.colo.xensource.com) by lists.xensource.com with esmtp (Exim 4.43) id 1R5gle-0002eG-9n; Mon, 19 Sep 2011 09:32:26 -0700 Received: from mail174.messagelabs.com ([85.158.138.51]) by lists.xensource.com with esmtp (Exim 4.43) id 1R5gl8-0002Qt-QP for xen-devel@lists.xensource.com; Mon, 19 Sep 2011 09:31:55 -0700 X-Env-Sender: JBeulich@suse.com X-Msg-Ref: server-14.tower-174.messagelabs.com!1316449911!32004555!1 X-Originating-IP: [130.57.49.28] X-StarScan-Version: 6.4.1; banners=-,-,- X-VirusChecked: Checked Received: (qmail 4451 invoked from network); 19 Sep 2011 16:31:51 -0000 Received: from nat28.tlf.novell.com (HELO nat28.tlf.novell.com) (130.57.49.28) by server-14.tower-174.messagelabs.com with DHE-RSA-AES256-SHA encrypted SMTP; 19 Sep 2011 16:31:51 -0000 Received: from EMEA1-MTA by nat28.tlf.novell.com with Novell_GroupWise; Mon, 19 Sep 2011 17:31:50 +0100 Message-Id: <4E778AAF0200007800056B63@nat28.tlf.novell.com> X-Mailer: Novell GroupWise Internet Agent 8.0.1 Date: Mon, 19 Sep 2011 17:32:15 +0100 From: "Jan Beulich" <JBeulich@suse.com> To: "Konrad Rzeszutek Wilk" <konrad.wilk@oracle.com> Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: quoted-printable Content-Disposition: inline Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com> Subject: [Xen-devel] [PATCH] xen/pciback: use mutex rather than spinlock in passthrough backend X-BeenThere: xen-devel@lists.xensource.com X-Mailman-Version: 2.1.5 Precedence: list List-Id: Xen developer discussion <xen-devel.lists.xensource.com> List-Unsubscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe> List-Post: <mailto:xen-devel@lists.xensource.com> List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help> List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=subscribe> Sender: xen-devel-bounces@lists.xensource.com Errors-To: xen-devel-bounces@lists.xensource.com To accommodate the call to the callback function from __xen_pcibk_publish_pci_roots(), which so far dropped and the re- acquired the lock without checking that the list didn't actually change, convert the code to use a mutex instead (observing that the code taking the lock won't ever get called from non-sleepable context). As a result, drop the bogus use of list_for_each_entry_safe() and remove the inappropriate dropping of the lock. Signed-off-by: Jan Beulich <jbeulich@suse.com> --- drivers/xen/xen-pciback/passthrough.c | 32 +++++++++++++----------------= --- 1 file changed, 13 insertions(+), 19 deletions(-) --- 3.1-rc6/drivers/xen/xen-pciback/passthrough.c +++ 3.1-rc6-xen-pciback-passthr-mutex/drivers/xen/xen-pciback/passthrough.c= @@ -7,13 +7,13 @@ =20 #include <linux/list.h> #include <linux/pci.h> -#include <linux/spinlock.h> +#include <linux/mutex.h> #include "pciback.h" =20 struct passthrough_dev_data { /* Access to dev_list must be protected by lock */ struct list_head dev_list; - spinlock_t lock; + struct mutex lock; }; =20 static struct pci_dev *__xen_pcibk_get_pci_dev(struct xen_pcibk_device = *pdev, @@ -24,9 +24,8 @@ static struct pci_dev *__xen_pcibk_get_p struct passthrough_dev_data *dev_data =3D pdev->pci_dev_data; struct pci_dev_entry *dev_entry; struct pci_dev *dev =3D NULL; - unsigned long flags; =20 - spin_lock_irqsave(&dev_data->lock, flags); + mutex_lock(&dev_data->lock); =20 list_for_each_entry(dev_entry, &dev_data->dev_list, list) { if (domain =3D=3D (unsigned int)pci_domain_nr(dev_entry->de= v->bus) @@ -37,7 +36,7 @@ static struct pci_dev *__xen_pcibk_get_p } } =20 - spin_unlock_irqrestore(&dev_data->lock, flags); + mutex_unlock(&dev_data->lock); =20 return dev; } @@ -48,7 +47,6 @@ static int __xen_pcibk_add_pci_dev(struc { struct passthrough_dev_data *dev_data =3D pdev->pci_dev_data; struct pci_dev_entry *dev_entry; - unsigned long flags; unsigned int domain, bus, devfn; int err; =20 @@ -57,9 +55,9 @@ static int __xen_pcibk_add_pci_dev(struc return -ENOMEM; dev_entry->dev =3D dev; =20 - spin_lock_irqsave(&dev_data->lock, flags); + mutex_lock(&dev_data->lock); list_add_tail(&dev_entry->list, &dev_data->dev_list); - spin_unlock_irqrestore(&dev_data->lock, flags); + mutex_unlock(&dev_data->lock); =20 /* Publish this device. */ domain =3D (unsigned int)pci_domain_nr(dev->bus); @@ -76,9 +74,8 @@ static void __xen_pcibk_release_pci_dev( struct passthrough_dev_data *dev_data =3D pdev->pci_dev_data; struct pci_dev_entry *dev_entry, *t; struct pci_dev *found_dev =3D NULL; - unsigned long flags; =20 - spin_lock_irqsave(&dev_data->lock, flags); + mutex_lock(&dev_data->lock); =20 list_for_each_entry_safe(dev_entry, t, &dev_data->dev_list, list) = { if (dev_entry->dev =3D=3D dev) { @@ -88,7 +85,7 @@ static void __xen_pcibk_release_pci_dev( } } =20 - spin_unlock_irqrestore(&dev_data->lock, flags); + mutex_unlock(&dev_data->lock); =20 if (found_dev) pcistub_put_pci_dev(found_dev); @@ -102,7 +99,7 @@ static int __xen_pcibk_init_devices(stru if (!dev_data) return -ENOMEM; =20 - spin_lock_init(&dev_data->lock); + mutex_init(&dev_data->lock); =20 INIT_LIST_HEAD(&dev_data->dev_list); =20 @@ -116,14 +113,14 @@ static int __xen_pcibk_publish_pci_roots { int err =3D 0; struct passthrough_dev_data *dev_data =3D pdev->pci_dev_data; - struct pci_dev_entry *dev_entry, *e, *tmp; + struct pci_dev_entry *dev_entry, *e; struct pci_dev *dev; int found; unsigned int domain, bus; =20 - spin_lock(&dev_data->lock); + mutex_lock(&dev_data->lock); =20 - list_for_each_entry_safe(dev_entry, tmp, &dev_data->dev_list, = list) { + list_for_each_entry(dev_entry, &dev_data->dev_list, list) { /* Only publish this device as a root if none of its * parent bridges are exported */ @@ -142,16 +139,13 @@ static int __xen_pcibk_publish_pci_roots bus =3D (unsigned int)dev_entry->dev->bus->number; =20 if (!found) { - spin_unlock(&dev_data->lock); err =3D publish_root_cb(pdev, domain, bus); if (err) break; - spin_lock(&dev_data->lock); } } =20 - if (!err) - spin_unlock(&dev_data->lock); + mutex_unlock(&dev_data->lock); =20 return err; } _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel From xen-devel-bounces@lists.xensource.com Mon Sep 19 09:33:42 2011 Return-path: <xen-devel-bounces@lists.xensource.com> Envelope-to: www-data@lists.xensource.com Delivery-date: Mon, 19 Sep 2011 09:33:42 -0700 Received: from localhost ([127.0.0.1] helo=lists.colo.xensource.com) by lists.xensource.com with esmtp (Exim 4.43) id 1R5gms-00031Z-Op; Mon, 19 Sep 2011 09:33:42 -0700 Received: from mail216.messagelabs.com ([85.158.143.99]) by lists.xensource.com with esmtp (Exim 4.43) id 1R5gmJ-0002pH-5U for xen-devel@lists.xensource.com; Mon, 19 Sep 2011 09:33:07 -0700 X-Env-Sender: khoxsey@paradigm-healthcare.com X-Msg-Ref: server-14.tower-216.messagelabs.com!1316449983!18852221!1 X-Originating-IP: [65.55.88.13] X-StarScan-Version: 6.4.1; banners=-,-,- X-VirusChecked: Checked Received: (qmail 13686 invoked from network); 19 Sep 2011 16:33:04 -0000 Received: from tx2ehsobe003.messaging.microsoft.com (HELO TX2EHSOBE005.bigfish.com) (65.55.88.13) by server-14.tower-216.messagelabs.com with AES128-SHA encrypted SMTP; 19 Sep 2011 16:33:04 -0000 Received: from mail2-tx2-R.bigfish.com (10.9.14.245) by TX2EHSOBE005.bigfish.com (10.9.40.25) with Microsoft SMTP Server id 14.1.225.22; Mon, 19 Sep 2011 16:33:02 +0000 Received: from mail2-tx2 (localhost.localdomain [127.0.0.1]) by mail2-tx2-R.bigfish.com (Postfix) with ESMTP id 7DB811630322 for <xen-devel@lists.xensource.com>; Mon, 19 Sep 2011 16:33:02 +0000 (UTC) X-SpamScore: 0 X-BigFish: VPS0(zzzz1202hzz8275bhz2dh2a8h668h839h944h62h) X-Spam-TCS-SCL: 1:0 X-Forefront-Antispam-Report: CIP:173.226.105.130; KIP:(null); UIP:(null); IPVD:NLI; H:SF1EXCH1.PHS; RD:none; EFVD:NLI X-FB-SS: 0, Received: from mail2-tx2 (localhost.localdomain [127.0.0.1]) by mail2-tx2 (MessageSwitch) id 1316449966132766_32584; Mon, 19 Sep 2011 16:32:46 +0000 (UTC) Received: from TX2EHSMHS018.bigfish.com (unknown [10.9.14.243]) by mail2-tx2.bigfish.com (Postfix) with ESMTP id 88E704381D1 for <xen-devel@lists.xensource.com>; Mon, 19 Sep 2011 16:30:30 +0000 (UTC) Received: from SF1EXCH1.PHS (173.226.105.130) by TX2EHSMHS018.bigfish.com (10.9.99.118) with Microsoft SMTP Server (TLS) id 14.1.225.22; Mon, 19 Sep 2011 16:30:23 +0000 Received: from SF1EXCH1.PHS ([::1]) by SF1EXCH1.PHS ([::1]) with mapi; Mon, 19 Sep 2011 09:30:41 -0700 From: Kent Hoxsey <khoxsey@paradigm-healthcare.com> To: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com> Subject: Re: [Xen-devel] Re: kernel BUG at mm/swapfile.c:2527! Thread-Topic: [Xen-devel] Re: kernel BUG at mm/swapfile.c:2527! Thread-Index: Acx26Xh0ghyutAgnQK+iQz4tUlCfxg== Date: Mon, 19 Sep 2011 16:30:40 +0000 Message-ID: <FD11FB67713F5F4CA0569B3F0468ED751A5DE376@SF1EXCH1.PHS> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: paradigm-healthcare.com X-BeenThere: xen-devel@lists.xensource.com X-Mailman-Version: 2.1.5 Precedence: list List-Id: Xen developer discussion <xen-devel.lists.xensource.com> List-Unsubscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe> List-Post: <mailto:xen-devel@lists.xensource.com> List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help> List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=subscribe> Sender: xen-devel-bounces@lists.xensource.com Errors-To: xen-devel-bounces@lists.xensource.com Joining this thread lately as a follow-on from a similar problem that is ha= ppening in Amazon AWS instances. There is a thread on the AWS forums where = an instance owner has figured out how to cause this bug on demand using apa= che and PHP:=0A= =0A= https://forums.aws.amazon.com/thread.jspa?messageID=3D269851=0A= =0A= In case those forums require a login, the php script to hit is:=0A= =0A= <?php=0A= $data =3D array();=0A= for($x =3D 0; $x< 10000; $x++)=0A= {=0A= for($y =3D 0; $y<1000; $y++){=0A= $data[][]=3Drand(1,100000);=0A= }=0A= }=0A= echo count($data);=0A= =0A= =0A= I am not a PHP programmer, so unsure if that php tag needs to be closed or = not, but that is what is posted on the forum. Run apache bench against your= test URL with 200 concurrent connections.=0A= =0A= My Amazon instance isn't running PHP but encounters a similar problem once = a day (1:48pm Pacific). I cannot allow people onto the instance but am will= ing to run diagnostics and post them here.=0A= =0A= Kent= _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel From xen-devel-bounces@lists.xensource.com Mon Sep 19 09:42:40 2011 Return-path: <xen-devel-bounces@lists.xensource.com> Envelope-to: www-data@lists.xensource.com Delivery-date: Mon, 19 Sep 2011 09:42:40 -0700 Received: from localhost ([127.0.0.1] helo=lists.colo.xensource.com) by lists.xensource.com with esmtp (Exim 4.43) id 1R5gvY-0003fu-F7; Mon, 19 Sep 2011 09:42:40 -0700 Received: from mail27.messagelabs.com ([193.109.254.147]) by lists.xensource.com with esmtp (Exim 4.43) id 1R5guw-0003TC-HZ for xen-devel@lists.xensource.com; Mon, 19 Sep 2011 09:42:03 -0700 X-Env-Sender: JBeulich@suse.com X-Msg-Ref: server-15.tower-27.messagelabs.com!1316450510!49417965!1 X-Originating-IP: [130.57.49.28] X-StarScan-Version: 6.4.1; banners=-,-,- X-VirusChecked: Checked Received: (qmail 27874 invoked from network); 19 Sep 2011 16:41:50 -0000 Received: from nat28.tlf.novell.com (HELO nat28.tlf.novell.com) (130.57.49.28) by server-15.tower-27.messagelabs.com with DHE-RSA-AES256-SHA encrypted SMTP; 19 Sep 2011 16:41:50 -0000 Received: from EMEA1-MTA by nat28.tlf.novell.com with Novell_GroupWise; Mon, 19 Sep 2011 17:41:59 +0100 Message-Id: <4E778D100200007800056B76@nat28.tlf.novell.com> X-Mailer: Novell GroupWise Internet Agent 8.0.1 Date: Mon, 19 Sep 2011 17:42:24 +0100 From: "Jan Beulich" <JBeulich@suse.com> To: "Konrad Rzeszutek Wilk" <konrad.wilk@oracle.com> Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: quoted-printable Content-Disposition: inline Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com> Subject: [Xen-devel] [PATCH] xen/pciback: miscellaneous adjustments X-BeenThere: xen-devel@lists.xensource.com X-Mailman-Version: 2.1.5 Precedence: list List-Id: Xen developer discussion <xen-devel.lists.xensource.com> List-Unsubscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe> List-Post: <mailto:xen-devel@lists.xensource.com> List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help> List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=subscribe> Sender: xen-devel-bounces@lists.xensource.com Errors-To: xen-devel-bounces@lists.xensource.com This is a minor bugfix and a set of small cleanups; as it is not clear whether this needs splitting into pieces (and if so, at what granularity), I'm submitting this as a single combined patch as a first try (I'd hope it doesn't need to be one patch per description line below): - add a missing return statement to an error path in kill_domain_by_device() - use pci_is_enabled() rather than raw atomic_read() - use resource_size() rather than open coding it - remove a bogus attempt to zero-terminate an already zero-terminated string - #define DRV_NAME once uniformly in the shared local header - make DRIVER_ATTR() variables static - eliminate a pointless use of list_for_each_entry_safe() - add MODULE_ALIAS() - a little bit of constification - adjust a few messages - remove stray semicolons from inline function definitions Signed-off-by: Jan Beulich <jbeulich@suse.com> --- drivers/xen/xen-pciback/conf_space.c | 1=20 drivers/xen/xen-pciback/conf_space_header.c | 5 +--- drivers/xen/xen-pciback/conf_space_quirks.c | 3 -- drivers/xen/xen-pciback/passthrough.c | 2 - drivers/xen/xen-pciback/pci_stub.c | 31 +++++++++++------------= ----- drivers/xen/xen-pciback/pciback.h | 30 +++++++++++++++++------= ---- drivers/xen/xen-pciback/pciback_ops.c | 1=20 drivers/xen/xen-pciback/vpci.c | 9 +++----- drivers/xen/xen-pciback/xenbus.c | 5 +--- 9 files changed, 42 insertions(+), 45 deletions(-) --- 3.1-rc6/drivers/xen/xen-pciback/conf_space.c +++ 3.1-rc6-xen-pciback-misc/drivers/xen/xen-pciback/conf_space.c @@ -15,7 +15,6 @@ #include "conf_space.h" #include "conf_space_quirks.h" =20 -#define DRV_NAME "xen-pciback" static int permissive; module_param(permissive, bool, 0644); =20 --- 3.1-rc6/drivers/xen/xen-pciback/conf_space_header.c +++ 3.1-rc6-xen-pciback-misc/drivers/xen/xen-pciback/conf_space_header.c @@ -15,7 +15,6 @@ struct pci_bar_info { int which; }; =20 -#define DRV_NAME "xen-pciback" #define is_enable_cmd(value) ((value)&(PCI_COMMAND_MEMORY|PCI_COMMAND_IO))= #define is_master_cmd(value) ((value)&PCI_COMMAND_MASTER) =20 @@ -25,7 +24,7 @@ static int command_read(struct pci_dev * int ret; =20 ret =3D xen_pcibk_read_config_word(dev, offset, value, data); - if (!atomic_read(&dev->enable_cnt)) + if (!pci_is_enabled(dev)) return ret; =20 for (i =3D 0; i < PCI_ROM_RESOURCE; i++) { @@ -187,7 +186,7 @@ static inline void read_dev_bar(struct p =20 bar_info->val =3D res[pos].start | (res[pos].flags & PCI_REGION_FLAG_MASK); - bar_info->len_val =3D res[pos].end - res[pos].start + 1; + bar_info->len_val =3D resource_size(res + pos); } =20 static void *bar_init(struct pci_dev *dev, int offset) --- 3.1-rc6/drivers/xen/xen-pciback/conf_space_quirks.c +++ 3.1-rc6-xen-pciback-misc/drivers/xen/xen-pciback/conf_space_quirks.c @@ -12,7 +12,6 @@ #include "conf_space_quirks.h" =20 LIST_HEAD(xen_pcibk_quirks); -#define DRV_NAME "xen-pciback" static inline const struct pci_device_id * match_one_device(const struct pci_device_id *id, const struct pci_dev = *dev) { @@ -36,7 +35,7 @@ static struct xen_pcibk_config_quirk *xe goto out; tmp_quirk =3D NULL; printk(KERN_DEBUG DRV_NAME - ":quirk didn't match any device xen_pciback knows about\n");= + ": quirk didn't match any device known\n"); out: return tmp_quirk; } --- 3.1-rc6/drivers/xen/xen-pciback/passthrough.c +++ 3.1-rc6-xen-pciback-misc/drivers/xen/xen-pciback/passthrough.c @@ -182,7 +182,7 @@ static int __xen_pcibk_get_pcifront_dev( return 1; } =20 -struct xen_pcibk_backend xen_pcibk_passthrough_backend =3D { +const struct xen_pcibk_backend xen_pcibk_passthrough_backend =3D { .name =3D "passthrough", .init =3D __xen_pcibk_init_devices, .free =3D __xen_pcibk_release_devices, --- 3.1-rc6/drivers/xen/xen-pciback/pci_stub.c +++ 3.1-rc6-xen-pciback-misc/drivers/xen/xen-pciback/pci_stub.c @@ -21,8 +21,6 @@ #include "conf_space.h" #include "conf_space_quirks.h" =20 -#define DRV_NAME "xen-pciback" - static char *pci_devs_to_hide; wait_queue_head_t xen_pcibk_aer_wait_queue; /*Add sem for sync AER handling and xen_pcibk remove/reconfigue ops, @@ -514,12 +512,14 @@ static void kill_domain_by_device(struct int err; char nodename[PCI_NODENAME_MAX]; =20 - if (!psdev) + if (!psdev) { dev_err(&psdev->dev->dev, "device is NULL when do AER recovery/kill_domain\n"= ); + return; + } + snprintf(nodename, PCI_NODENAME_MAX, "/local/domain/0/backend/pci/%= d/0", psdev->pdev->xdev->otherend_id); - nodename[strlen(nodename)] =3D '\0'; =20 again: err =3D xenbus_transaction_start(&xbt); @@ -605,7 +605,7 @@ static pci_ers_result_t common_process(s if (test_bit(_XEN_PCIF_active, (unsigned long *)&psdev->pdev->sh_info->flags)) { dev_dbg(&psdev->dev->dev, - "schedule pci_conf service in xen_pcibk\n"); + "schedule pci_conf service in " DRV_NAME "\n"); xen_pcibk_test_and_schedule_op(psdev->pdev); } =20 @@ -995,8 +995,7 @@ out: err =3D count; return err; } - -DRIVER_ATTR(new_slot, S_IWUSR, NULL, pcistub_slot_add); +static DRIVER_ATTR(new_slot, S_IWUSR, NULL, pcistub_slot_add); =20 static ssize_t pcistub_slot_remove(struct device_driver *drv, const char = *buf, size_t count) @@ -1015,8 +1014,7 @@ out: err =3D count; return err; } - -DRIVER_ATTR(remove_slot, S_IWUSR, NULL, pcistub_slot_remove); +static DRIVER_ATTR(remove_slot, S_IWUSR, NULL, pcistub_slot_remove); =20 static ssize_t pcistub_slot_show(struct device_driver *drv, char *buf) { @@ -1039,8 +1037,7 @@ static ssize_t pcistub_slot_show(struct=20 =20 return count; } - -DRIVER_ATTR(slots, S_IRUSR, pcistub_slot_show, NULL); +static DRIVER_ATTR(slots, S_IRUSR, pcistub_slot_show, NULL); =20 static ssize_t pcistub_irq_handler_show(struct device_driver *drv, char = *buf) { @@ -1069,8 +1066,7 @@ static ssize_t pcistub_irq_handler_show( spin_unlock_irqrestore(&pcistub_devices_lock, flags); return count; } - -DRIVER_ATTR(irq_handlers, S_IRUSR, pcistub_irq_handler_show, NULL); +static DRIVER_ATTR(irq_handlers, S_IRUSR, pcistub_irq_handler_show, = NULL); =20 static ssize_t pcistub_irq_handler_switch(struct device_driver *drv, const char *buf, @@ -1106,7 +1102,7 @@ out: err =3D count; return err; } -DRIVER_ATTR(irq_handler_state, S_IWUSR, NULL, pcistub_irq_handler_switch);= +static DRIVER_ATTR(irq_handler_state, S_IWUSR, NULL, pcistub_irq_handler_s= witch); =20 static ssize_t pcistub_quirk_add(struct device_driver *drv, const char = *buf, size_t count) @@ -1170,8 +1166,7 @@ out: =20 return count; } - -DRIVER_ATTR(quirks, S_IRUSR | S_IWUSR, pcistub_quirk_show, pcistub_quirk_a= dd); +static DRIVER_ATTR(quirks, S_IRUSR | S_IWUSR, pcistub_quirk_show, = pcistub_quirk_add); =20 static ssize_t permissive_add(struct device_driver *drv, const char *buf, size_t count) @@ -1236,8 +1231,7 @@ static ssize_t permissive_show(struct de spin_unlock_irqrestore(&pcistub_devices_lock, flags); return count; } - -DRIVER_ATTR(permissive, S_IRUSR | S_IWUSR, permissive_show, permissive_add= ); +static DRIVER_ATTR(permissive, S_IRUSR | S_IWUSR, permissive_show, = permissive_add); =20 static void pcistub_exit(void) { @@ -1374,3 +1368,4 @@ module_init(xen_pcibk_init); module_exit(xen_pcibk_cleanup); =20 MODULE_LICENSE("Dual BSD/GPL"); +MODULE_ALIAS("xen-backend:pci"); --- 3.1-rc6/drivers/xen/xen-pciback/pciback.h +++ 3.1-rc6-xen-pciback-misc/drivers/xen/xen-pciback/pciback.h @@ -15,6 +15,8 @@ #include <linux/atomic.h> #include <xen/interface/io/pciif.h> =20 +#define DRV_NAME "xen-pciback" + struct pci_dev_entry { struct list_head list; struct pci_dev *dev; @@ -89,7 +91,7 @@ typedef int (*publish_pci_root_cb) (stru * passthrough - BDFs are exactly like in the host. */ struct xen_pcibk_backend { - char *name; + const char *name; int (*init)(struct xen_pcibk_device *pdev); void (*free)(struct xen_pcibk_device *pdev); int (*find)(struct pci_dev *pcidev, struct xen_pcibk_device *pdev, @@ -104,9 +106,9 @@ struct xen_pcibk_backend { unsigned int devfn); }; =20 -extern struct xen_pcibk_backend xen_pcibk_vpci_backend; -extern struct xen_pcibk_backend xen_pcibk_passthrough_backend; -extern struct xen_pcibk_backend *xen_pcibk_backend; +extern const struct xen_pcibk_backend xen_pcibk_vpci_backend; +extern const struct xen_pcibk_backend xen_pcibk_passthrough_backend; +extern const struct xen_pcibk_backend *xen_pcibk_backend; =20 static inline int xen_pcibk_add_pci_dev(struct xen_pcibk_device *pdev, struct pci_dev *dev, @@ -116,13 +118,14 @@ static inline int xen_pcibk_add_pci_dev( if (xen_pcibk_backend && xen_pcibk_backend->add) return xen_pcibk_backend->add(pdev, dev, devid, publish_cb)= ; return -1; -}; +} + static inline void xen_pcibk_release_pci_dev(struct xen_pcibk_device = *pdev, struct pci_dev *dev) { if (xen_pcibk_backend && xen_pcibk_backend->free) return xen_pcibk_backend->release(pdev, dev); -}; +} =20 static inline struct pci_dev * xen_pcibk_get_pci_dev(struct xen_pcibk_device *pdev, unsigned int domain, @@ -131,7 +134,8 @@ xen_pcibk_get_pci_dev(struct xen_pcibk_d if (xen_pcibk_backend && xen_pcibk_backend->get) return xen_pcibk_backend->get(pdev, domain, bus, devfn); return NULL; -}; +} + /** * Add for domain0 PCIE-AER handling. Get guest domain/bus/devfn in = xen_pcibk * before sending aer request to pcifront, so that guest could identify @@ -148,25 +152,29 @@ static inline int xen_pcibk_get_pcifront return xen_pcibk_backend->find(pcidev, pdev, domain, bus, devfn); return -1; -}; +} + static inline int xen_pcibk_init_devices(struct xen_pcibk_device *pdev) { if (xen_pcibk_backend && xen_pcibk_backend->init) return xen_pcibk_backend->init(pdev); return -1; -}; +} + static inline int xen_pcibk_publish_pci_roots(struct xen_pcibk_device = *pdev, publish_pci_root_cb cb) { if (xen_pcibk_backend && xen_pcibk_backend->publish) return xen_pcibk_backend->publish(pdev, cb); return -1; -}; +} + static inline void xen_pcibk_release_devices(struct xen_pcibk_device = *pdev) { if (xen_pcibk_backend && xen_pcibk_backend->free) return xen_pcibk_backend->free(pdev); -}; +} + /* Handles events from front-end */ irqreturn_t xen_pcibk_handle_event(int irq, void *dev_id); void xen_pcibk_do_op(struct work_struct *data); --- 3.1-rc6/drivers/xen/xen-pciback/pciback_ops.c +++ 3.1-rc6-xen-pciback-misc/drivers/xen/xen-pciback/pciback_ops.c @@ -10,7 +10,6 @@ #include <linux/sched.h> #include "pciback.h" =20 -#define DRV_NAME "xen-pciback" int verbose_request; module_param(verbose_request, int, 0644); =20 --- 3.1-rc6/drivers/xen/xen-pciback/vpci.c +++ 3.1-rc6-xen-pciback-misc/drivers/xen/xen-pciback/vpci.c @@ -12,7 +12,6 @@ #include "pciback.h" =20 #define PCI_SLOT_MAX 32 -#define DRV_NAME "xen-pciback" =20 struct vpci_dev_data { /* Access to dev_list must be protected by lock */ @@ -150,9 +149,9 @@ static void __xen_pcibk_release_pci_dev( spin_lock_irqsave(&vpci_dev->lock, flags); =20 for (slot =3D 0; slot < PCI_SLOT_MAX; slot++) { - struct pci_dev_entry *e, *tmp; - list_for_each_entry_safe(e, tmp, &vpci_dev->dev_list[slot],= - list) { + struct pci_dev_entry *e; + + list_for_each_entry(e, &vpci_dev->dev_list[slot], list) { if (e->dev =3D=3D dev) { list_del(&e->list); found_dev =3D e->dev; @@ -247,7 +246,7 @@ static int __xen_pcibk_get_pcifront_dev( return found; } =20 -struct xen_pcibk_backend xen_pcibk_vpci_backend =3D { +const struct xen_pcibk_backend xen_pcibk_vpci_backend =3D { .name =3D "vpci", .init =3D __xen_pcibk_init_devices, .free =3D __xen_pcibk_release_devices, --- 3.1-rc6/drivers/xen/xen-pciback/xenbus.c +++ 3.1-rc6-xen-pciback-misc/drivers/xen/xen-pciback/xenbus.c @@ -13,7 +13,6 @@ #include <asm/xen/pci.h> #include "pciback.h" =20 -#define DRV_NAME "xen-pciback" #define INVALID_EVTCHN_IRQ (-1) struct workqueue_struct *xen_pcibk_wq; =20 @@ -176,7 +175,7 @@ static int xen_pcibk_attach(struct xen_p if (magic =3D=3D NULL || strcmp(magic, XEN_PCI_MAGIC) !=3D 0) { xenbus_dev_fatal(pdev->xdev, -EFAULT, "version mismatch (%s/%s) with pcifront - = " - "halting xen_pcibk", + "halting " DRV_NAME, magic, XEN_PCI_MAGIC); goto out; } @@ -724,7 +723,7 @@ static struct xenbus_driver xenbus_xen_p .otherend_changed =3D xen_pcibk_frontend_changed, }; =20 -struct xen_pcibk_backend *xen_pcibk_backend; +const struct xen_pcibk_backend *__read_mostly xen_pcibk_backend; =20 int __init xen_pcibk_xenbus_register(void) { _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel From xen-devel-bounces@lists.xensource.com Mon Sep 19 10:54:30 2011 Return-path: <xen-devel-bounces@lists.xensource.com> Envelope-to: www-data@lists.xensource.com Delivery-date: Mon, 19 Sep 2011 10:54:30 -0700 Received: from localhost ([127.0.0.1] helo=lists.colo.xensource.com) by lists.xensource.com with esmtp (Exim 4.43) id 1R5i34-0007Ke-11; Mon, 19 Sep 2011 10:54:30 -0700 Received: from mail27.messagelabs.com ([193.109.254.147]) by lists.xensource.com with smtp (Exim 4.43) id 1R5i2L-00077v-K8 for xen-devel@lists.xensource.com; Mon, 19 Sep 2011 10:53:48 -0700 X-Env-Sender: dgdegra@tycho.nsa.gov X-Msg-Ref: server-7.tower-27.messagelabs.com!1316454799!49319681!1 X-Originating-IP: [63.239.65.40] X-StarScan-Version: 6.4.1; banners=-,-,- X-VirusChecked: Checked Received: (qmail 13499 invoked from network); 19 Sep 2011 17:53:19 -0000 Received: from msux-gh1-uea02.nsa.gov (HELO msux-gh1-uea02.nsa.gov) (63.239.65.40) by server-7.tower-27.messagelabs.com with SMTP; 19 Sep 2011 17:53:19 -0000 Received: from tarius.tycho.ncsc.mil (localhost [127.0.0.1]) by msux-gh1-uea02.nsa.gov (8.12.10/8.12.10) with ESMTP id p8JHrcr7028570; Mon, 19 Sep 2011 17:53:38 GMT Received: from moss-nexus.epoch.ncsc.mil (moss-nexus [144.51.25.48]) by tarius.tycho.ncsc.mil (8.13.1/8.13.1) with ESMTP id p8JHrZlK002085; Mon, 19 Sep 2011 13:53:37 -0400 Message-ID: <4E7781A8.8080905@tycho.nsa.gov> Date: Mon, 19 Sep 2011 13:53:44 -0400 From: Daniel De Graaf <dgdegra@tycho.nsa.gov> Organization: National Security Agency User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:6.0) Gecko/20110816 Thunderbird/6.0 MIME-Version: 1.0 To: Jeremy Fitzhardinge <jeremy@goop.org> Subject: Re: [Xen-devel] [PATCH 1/2] xen/event: Add reference counting to event channel References: <1316207684-19860-1-git-send-email-dgdegra@tycho.nsa.gov> <1316207684-19860-2-git-send-email-dgdegra@tycho.nsa.gov> <4E742703.7050005@goop.org> <4E7764D2.4070803@tycho.nsa.gov> <4E776C2B.9050405@goop.org> In-Reply-To: <4E776C2B.9050405@goop.org> X-Enigmail-Version: 1.3 Content-Type: text/plain; charset=ISO-8859-15 Content-Transfer-Encoding: 7bit Cc: Keir Fraser <keir@xen.org>, xen-devel@lists.xensource.com, Ian Jackson <Ian.Jackson@eu.citrix.com>, konrad.wilk@oracle.com X-BeenThere: xen-devel@lists.xensource.com X-Mailman-Version: 2.1.5 Precedence: list List-Id: Xen developer discussion <xen-devel.lists.xensource.com> List-Unsubscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe> List-Post: <mailto:xen-devel@lists.xensource.com> List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help> List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=subscribe> Sender: xen-devel-bounces@lists.xensource.com Errors-To: xen-devel-bounces@lists.xensource.com On 09/19/2011 12:22 PM, Jeremy Fitzhardinge wrote: > On 09/19/2011 08:50 AM, Daniel De Graaf wrote: >> On 09/17/2011 12:50 AM, Jeremy Fitzhardinge wrote: >>> On 09/16/2011 02:14 PM, Daniel De Graaf wrote: >>>> Event channels exposed to userspace by the evtchn module may be used by >>>> other modules in an asynchronous manner, which requires that reference >>>> counting be used to prevent the event channel from being closed before >>>> the signals are delivered. >>> Could you use the refcounting at the irq level? I was quite pleased to >>> have removed the event channel refcounting (and the use of naked event >>> channels). >> This looked more complex: unbind_from_irq has cleanup that happens after >> EVTCHNOP_close but before the irq-refcount-protected close operation. >> For the IRQ-level refcounting to be useful here, the EVTCHNOP_close would >> have to be postponed. The evtchn_to_irq mapping is also maintained here. >> >>> Oh, is it that userspace allocates an event channel with /dev/evtchn, >>> then passes that event channel to the gntalloc/gntdev drivers so they >>> can use it to pass events between the two. That's a bit unfortunate; it >>> might have been better to expose those event channels as file >>> descriptors so you could use fd refcounting to manage the lifetimes. >> This would also make event channels simpler to use from userspace, avoiding >> the extra read() to determine what event channel has fired (and avoiding >> almost all userspace knowledge of the local event channel number). However, >> this would require practically rewriting the /dev/xen/evtchn userspace API. > > If you had an app which cared about many events, then having an fd for > each would be pretty cumbersome. But perhaps it would be worth > considering extending the current API a bit to add a general "set of > events fd", where a given event can be the member of multiple sets. This seems to overlap a lot with epoll, which can already do overlapping file descriptor readiness checks. >> With the current event channel API, you would have to pass both the event >> channel number and the evtchn file descriptor in order to get an fd reference >> which seems redundant and might cause confusion since keeping the fd >> reference would also prevent cleanup of other event channels associated with >> the shared file descriptor. It would also require changing the notify ioctl >> parameters since there is currently no need to pass an evtchn fd. > > Yes, though there's no reason even now one couldn't be careful to bind > your events to a given fd where they share similar lifetimes/uses (even > to the extent of allocating single-event fds). > > On the other hand, is there really a need to make a connection between > the gnt and evtchn devices? Why couldn't the gnt driver just do its own > form of event fd and management independent of /dev/evtchn? I know it > seems a bit redundant, but coupling the two adds its own complexities. I don't think there is a real need to make a connection, and even with this patch there isn't one: only tracking on the event channel, not on the evtchn device or its FDs. Unless you're talking about having /dev/xen/gnt* able to manage event channels independent of /dev/xen/evtchn? To be useful, this would either need to be able to both send and receive events, or to share local/remote ports with evtchn. >>> What's the downside of sending the event after the event channel has closed? >> The event won't get sent at all, since the hypervisor sees that the local >> end of the event channel is closed. If the local event channel number >> happens to get reused, the event could also get sent to the wrong event >> channel, although this is generally harmless. > > I think /dev/evtchn port numbers are never reused. And it sounds like > it is purely a usermode problem if they close the event channel prematurely. The trigger in this case is the kernel closing file descriptors when a process crashes. In particular: 1. open /dev/xen/evtchn (FD 3) and bind_interdomain an event channel 2. open /dev/xen/gntdev (FD 4) map a granted page 3. use unmap_notify on fd-4 to setup a notification on the event channel allocated in step 1 4. segfault, SIGKILL, or some other exit without proper cleanup At this point, the kernel closes file descriptors in numerical order, which will cause the event channel to be closed before the gntdev device is able to send its unmap notification event. In libvchan, I make sure to swap steps 1 and 2 to avoid triggering this bug, but that is clearly a workaround and not a proper solution. I have seen /dev/xen/evtchn ports be reused; the comment in evtchn.c is misleading or incorrect. The port is allocated by the hypervisor in xen/common/event_channel.c:get_free_port. > J > >>> That said: >>> >>>> Signed-off-by: Daniel De Graaf <dgdegra@tycho.nsa.gov> >>>> --- >>>> drivers/xen/events.c | 38 ++++++++++++++++++++++++++++++++++++++ >>>> include/xen/events.h | 6 ++++++ >>>> 2 files changed, 44 insertions(+), 0 deletions(-) >>>> >>>> diff --git a/drivers/xen/events.c b/drivers/xen/events.c >>>> index da70f5c..c9343b9 100644 >>>> --- a/drivers/xen/events.c >>>> +++ b/drivers/xen/events.c >>>> @@ -89,6 +89,7 @@ struct irq_info >>>> { >>>> struct list_head list; >>>> enum xen_irq_type type; /* type */ >>>> + unsigned short refcount; >>> Is short large enough? Is this something that untrusted userspace could >>> end up wrapping? If short is sufficient, you should pack it next to the >>> other short fields to avoid a gap. >> This would be quite difficult: since only gntdev/gntalloc use these counts >> for now, you would have to map or allocate 64K pages; the gntalloc driver >> has a default limit of 1024 pages and gntdev is limited by the hypervisor >> max_nr_grant_frames. >> >> Anyway, changing to atomic_t should >> >>>> unsigned irq; >>>> unsigned short evtchn; /* event channel */ >>>> unsigned short cpu; /* cpu bound */ >>>> @@ -407,6 +408,7 @@ static void xen_irq_init(unsigned irq) >>>> panic("Unable to allocate metadata for IRQ%d\n", irq); >>>> >>>> info->type = IRQT_UNBOUND; >>>> + info->refcount = 1; >>>> >>>> irq_set_handler_data(irq, info); >>>> >>>> @@ -469,6 +471,8 @@ static void xen_free_irq(unsigned irq) >>>> >>>> irq_set_handler_data(irq, NULL); >>>> >>>> + BUG_ON(info->refcount > 1); >>>> + >>>> kfree(info); >>>> >>>> /* Legacy IRQ descriptors are managed by the arch. */ >>>> @@ -912,9 +916,14 @@ static void unbind_from_irq(unsigned int irq) >>>> { >>>> struct evtchn_close close; >>>> int evtchn = evtchn_from_irq(irq); >>>> + struct irq_info *info = irq_get_handler_data(irq); >>>> >>>> spin_lock(&irq_mapping_update_lock); >>>> >>>> + info->refcount--; >>>> + if (info->refcount > 0) >>>> + goto out_unlock; >>>> + >>>> if (VALID_EVTCHN(evtchn)) { >>>> close.port = evtchn; >>>> if (HYPERVISOR_event_channel_op(EVTCHNOP_close, &close) != 0) >>>> @@ -943,6 +952,7 @@ static void unbind_from_irq(unsigned int irq) >>>> >>>> xen_free_irq(irq); >>>> >>>> + out_unlock: >>>> spin_unlock(&irq_mapping_update_lock); >>>> } >>>> >>>> @@ -1038,6 +1048,34 @@ void unbind_from_irqhandler(unsigned int irq, void *dev_id) >>>> } >>>> EXPORT_SYMBOL_GPL(unbind_from_irqhandler); >>>> >>>> +int get_evtchn_reservation(unsigned int evtchn) >>> "reservation"? I think just evtchn_get/put would be more consistent >>> with kernel naming conventions. >> Yes. >> >>>> +{ >>>> + int irq = evtchn_to_irq[evtchn]; >>>> + struct irq_info *info; >>>> + >>>> + if (irq == -1) >>>> + return -ENOENT; >>>> + >>>> + info = irq_get_handler_data(irq); >>>> + >>>> + if (!info) >>>> + return -ENOENT; >>>> + >>>> + spin_lock(&irq_mapping_update_lock); >>>> + info->refcount++; >>>> + spin_unlock(&irq_mapping_update_lock); >>> What is this spinlock protecting against? The non-atomicity of ++, or >>> something larger scale? If its just an atomicity thing, should it be an >>> atomic_t? >> Just atomicity. >> >>>> + >>>> + return 0; >>>> +} >>>> +EXPORT_SYMBOL_GPL(get_evtchn_reservation); >>>> + >>>> +void put_evtchn_reservation(unsigned int evtchn) >>>> +{ >>>> + int irq = evtchn_to_irq[evtchn]; >>>> + unbind_from_irq(irq); >>> Hm. >> Similar name change here. >> >>>> +} >>>> +EXPORT_SYMBOL_GPL(put_evtchn_reservation); >>>> + >>>> void xen_send_IPI_one(unsigned int cpu, enum ipi_vector vector) >>>> { >>>> int irq = per_cpu(ipi_to_irq, cpu)[vector]; >>>> diff --git a/include/xen/events.h b/include/xen/events.h >>>> index d287997..23bd5fd 100644 >>>> --- a/include/xen/events.h >>>> +++ b/include/xen/events.h >>>> @@ -37,6 +37,12 @@ int bind_interdomain_evtchn_to_irqhandler(unsigned int remote_domain, >>>> */ >>>> void unbind_from_irqhandler(unsigned int irq, void *dev_id); >>>> >>>> +/* >>>> + * Allow extra references to event channels exposed to userspace by evtchn >>>> + */ >>>> +int get_evtchn_reservation(unsigned int evtchn); >>>> +void put_evtchn_reservation(unsigned int evtchn); >>>> + >>>> void xen_send_IPI_one(unsigned int cpu, enum ipi_vector vector); >>>> int resend_irq_on_evtchn(unsigned int irq); >>>> void rebind_evtchn_irq(int evtchn, int irq); >> > -- Daniel De Graaf National Security Agency _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel From xen-devel-bounces@lists.xensource.com Mon Sep 19 13:25:17 2011 Return-path: <xen-devel-bounces@lists.xensource.com> Envelope-to: www-data@lists.xensource.com Delivery-date: Mon, 19 Sep 2011 13:25:17 -0700 Received: from localhost ([127.0.0.1] helo=lists.colo.xensource.com) by lists.xensource.com with esmtp (Exim 4.43) id 1R5kOz-0002ns-N1; Mon, 19 Sep 2011 13:25:17 -0700 Received: from mail182.messagelabs.com ([85.158.139.83]) by lists.xensource.com with esmtp (Exim 4.43) id 1R5kO4-0002bO-6y; Mon, 19 Sep 2011 13:24:20 -0700 X-Env-Sender: jeremy@goop.org X-Msg-Ref: server-2.tower-182.messagelabs.com!1316463855!17965419!1 X-Originating-IP: [74.207.240.146] X-StarScan-Version: 6.4.1; banners=-,-,- X-VirusChecked: Checked Received: (qmail 6148 invoked from network); 19 Sep 2011 20:24:16 -0000 Received: from claw.goop.org (HELO claw.goop.org) (74.207.240.146) by server-2.tower-182.messagelabs.com with DHE-RSA-AES256-SHA encrypted SMTP; 19 Sep 2011 20:24:16 -0000 Received: from saboo.goop.org (unknown [IPv6:2001:470:1f05:899:48e3:deff:fe6d:1bda]) (Authenticated sender: smtp-saboo) by claw.goop.org (Postfix) with ESMTPSA id 3F1988F2E; Mon, 19 Sep 2011 13:24:14 -0700 (PDT) Received: from saboo.goop.org (localhost [IPv6:::1]) by saboo.goop.org (Postfix) with ESMTP id 132A6202E4; Mon, 19 Sep 2011 13:24:12 -0700 (PDT) Message-ID: <4E77A4EC.9080600@goop.org> Date: Mon, 19 Sep 2011 13:24:12 -0700 From: Jeremy Fitzhardinge <jeremy@goop.org> User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:6.0.2) Gecko/20110906 Thunderbird/6.0.2 MIME-Version: 1.0 To: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com> Subject: Re: [Xen-devel] Re: Virtualization Test Day for F16 and Xen References: <CAN0j7xqm5BatDtXaurYZWvb-6ibG2V10aQ5Qck+9P7DjciWLwQ@mail.gmail.com> <20110914112552.GP12984@reaktio.net> <20110914142522.GA16956@phenom.oracle.com> <20110914144539.GR12984@reaktio.net> <20110915151041.GA4453@imp.local> <1316126290.5689.3.camel@adam> <20110916084308.GD884@phenom.oracle.com> In-Reply-To: <20110916084308.GD884@phenom.oracle.com> X-Enigmail-Version: 1.3.1 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: Development discussions related to Fedora <devel@lists.fedoraproject.org>, xen@lists.fedoraproject.org, xen-devel@lists.xensource.com, Stefano Stabellini <stefano.stabellini@eu.citrix.com>, lars.kurth@xen.org, virt@lists.fedoraproject.org, xen-users@lists.xensource.com, Adam Williamson <awilliam@redhat.com> X-BeenThere: xen-devel@lists.xensource.com X-Mailman-Version: 2.1.5 Precedence: list List-Id: Xen developer discussion <xen-devel.lists.xensource.com> List-Unsubscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe> List-Post: <mailto:xen-devel@lists.xensource.com> List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help> List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=subscribe> Sender: xen-devel-bounces@lists.xensource.com Errors-To: xen-devel-bounces@lists.xensource.com On 09/16/2011 01:43 AM, Konrad Rzeszutek Wilk wrote: > On Thu, Sep 15, 2011 at 03:38:09PM -0700, Adam Williamson wrote: >> On Thu, 2011-09-15 at 10:10 -0500, W. Michael Petullo wrote: >>>>> There are known bugs in FC15/FC16 that have been filled some time ago that >>>>> folks will sadly run into: 728775, 658387 and 668063 >>>>> >>>>> Fortunatly the bugs have patches attached and the files to be modified are shell scripts. >>> >>>> Yep, links here: >>>> >>>> https://bugzilla.redhat.com/show_bug.cgi?id=728775 >>> The Fedora update system reports this is fixed in grub2-1.99-6.fc16. >>> >>>> https://bugzilla.redhat.com/show_bug.cgi?id=658387 >>> Peter Jones submitted a new grubby package yesterday. This seems to fix >>> bug #658387 (i.e., new-kernel-pkg creates a Dom0-style grub.cfg entry >>> if /etc/sysconfig/kernel contains "HYPERVISOR=/boot/xen.gz"). >>> >>> I have not yet tested this on Fedora 16. However, I did test on Fedora >>> 15. In this case, bug #668063 is still in effect. That is, grubby creates >>> most of a GRUB record, but the "module initramfs-..." entry is missing. >>> >>> Has anyone yet tested this new grubby package on Fedora 16 yet? Does >>> using GRUB 2 makes #668063 irrelevant? > I believe so (the irrelevant part). But the functionality part of grubby picking > up /etc/sysconfig/kernel and making that kernel the default is not in Grub2 - so > not sure how that can be addressed. >>>> https://bugzilla.redhat.com/show_bug.cgi?id=668063 >>> I just added some more description to this bug. >> So, there's a meta-point here: we currently 'require' Beta releases to >> boot as guests on Xen hosts: >> >> "The release must boot successfully as a virtual guest in a situation >> where the virtual host is running a supported Xen implementation" >> >> I really don't have much knowledge of Xen and haven't followed this >> discussion closely, but do any currently-known bugs prevent this? If so, >> please flag them up so they can be considered as Beta blockers...thanks! > Somehow the xen-kbdfront driver is not included in the initrd image > (I think) - and we end with anaconda but can't type anything. I've been trying > to figure out how to inject said module in the install initrd to see if that is > really the problem but running in roadblocks (like xz 5.1.1alpha or 5.0.3 complains > about corrupt image, or I've no idea how to make driver disks). I saw the same thing and worked around it by booting with "vnc lang=en_US.UTF-8 keymap=us" which eliminiates the need to enter anything before it starts X on a vnc server. But it doesn't really address the original problem. I spent last Friday trying to get it to do an HVM install, but that seemed to be very much a Xen problem. It wouldn't accept keyboard input or find its emulated devices properly until I added "acpi=off", or set "acpi=0" in the Xen config. But even then it refused to see my HD image, even though the BIOS could list it. I got stuck at that point, and am now (successfully) doing a PV install (with the above workaround). J _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel From xen-devel-bounces@lists.xensource.com Mon Sep 19 15:44:37 2011 Return-path: <xen-devel-bounces@lists.xensource.com> Envelope-to: www-data@lists.xensource.com Delivery-date: Mon, 19 Sep 2011 15:44:37 -0700 Received: from localhost ([127.0.0.1] helo=lists.colo.xensource.com) by lists.xensource.com with esmtp (Exim 4.43) id 1R5mZp-00076t-C2; Mon, 19 Sep 2011 15:44:37 -0700 Received: from mail27.messagelabs.com ([193.109.254.147]) by lists.xensource.com with smtp (Exim 4.43) id 1R5mZ2-0006uD-Kp for xen-devel@lists.xensource.com; Mon, 19 Sep 2011 15:43:49 -0700 X-Env-Sender: dgdegra@tycho.nsa.gov X-Msg-Ref: server-11.tower-27.messagelabs.com!1316472216!38092392!1 X-Originating-IP: [63.239.65.39] X-StarScan-Version: 6.4.1; banners=-,-,- X-VirusChecked: Checked Received: (qmail 3107 invoked from network); 19 Sep 2011 22:43:37 -0000 Received: from msux-gh1-uea01.nsa.gov (HELO msux-gh1-uea01.nsa.gov) (63.239.65.39) by server-11.tower-27.messagelabs.com with SMTP; 19 Sep 2011 22:43:37 -0000 Received: from tarius.tycho.ncsc.mil (localhost [127.0.0.1]) by msux-gh1-uea01.nsa.gov (8.12.10/8.12.10) with ESMTP id p8JMhgcf023488; Mon, 19 Sep 2011 22:43:42 GMT Received: from moss-nexus.epoch.ncsc.mil (moss-nexus [144.51.25.48]) by tarius.tycho.ncsc.mil (8.13.1/8.13.1) with ESMTP id p8JMhgY5021336; Mon, 19 Sep 2011 18:43:42 -0400 From: Daniel De Graaf <dgdegra@tycho.nsa.gov> To: xen-devel@lists.xensource.com Date: Mon, 19 Sep 2011 18:43:25 -0400 Message-Id: <1316472208-12104-1-git-send-email-dgdegra@tycho.nsa.gov> X-Mailer: git-send-email 1.7.6.2 In-Reply-To: <1313764724-12683-1-git-send-email-dgdegra@tycho.nsa.gov> References: <1313764724-12683-1-git-send-email-dgdegra@tycho.nsa.gov> Cc: Ian.Campbell@eu.citrix.com, Stefano.Stabellini@eu.citrix.com, Ian.Jackson@eu.citrix.com, konrad.wilk@oracle.com Subject: [Xen-devel] [PATCH v5 0/3] X-BeenThere: xen-devel@lists.xensource.com X-Mailman-Version: 2.1.5 Precedence: list List-Id: Xen developer discussion <xen-devel.lists.xensource.com> List-Unsubscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe> List-Post: <mailto:xen-devel@lists.xensource.com> List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help> List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=subscribe> Sender: xen-devel-bounces@lists.xensource.com Errors-To: xen-devel-bounces@lists.xensource.com Changes since v4: - Notify application of failure to setup unmap notification - Add shared library -rpath to fix build on clean systems - Add linux system headers in the patches that use them - Formatting cleanups [PATCH 1/3] libxc: add xc_gnttab_map_grant_ref_notify [PATCH 2/3] libxc: add xc_gntshr_* functions [PATCH 3/3] libvchan: interdomain communications library _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel From xen-devel-bounces@lists.xensource.com Mon Sep 19 15:45:44 2011 Return-path: <xen-devel-bounces@lists.xensource.com> Envelope-to: www-data@lists.xensource.com Delivery-date: Mon, 19 Sep 2011 15:45:44 -0700 Received: from localhost ([127.0.0.1] helo=lists.colo.xensource.com) by lists.xensource.com with esmtp (Exim 4.43) id 1R5mau-0007Tu-KG; Mon, 19 Sep 2011 15:45:44 -0700 Received: from mail216.messagelabs.com ([85.158.143.99]) by lists.xensource.com with smtp (Exim 4.43) id 1R5mZ2-0006uG-Rd for xen-devel@lists.xensource.com; Mon, 19 Sep 2011 15:43:49 -0700 X-Env-Sender: dgdegra@tycho.nsa.gov X-Msg-Ref: server-15.tower-216.messagelabs.com!1316472224!18384159!1 X-Originating-IP: [63.239.65.40] X-StarScan-Version: 6.4.1; banners=-,-,- X-VirusChecked: Checked Received: (qmail 15055 invoked from network); 19 Sep 2011 22:43:45 -0000 Received: from msux-gh1-uea02.nsa.gov (HELO msux-gh1-uea02.nsa.gov) (63.239.65.40) by server-15.tower-216.messagelabs.com with SMTP; 19 Sep 2011 22:43:45 -0000 Received: from tarius.tycho.ncsc.mil (localhost [127.0.0.1]) by msux-gh1-uea02.nsa.gov (8.12.10/8.12.10) with ESMTP id p8JMhgh2002472; Mon, 19 Sep 2011 22:43:42 GMT Received: from moss-nexus.epoch.ncsc.mil (moss-nexus [144.51.25.48]) by tarius.tycho.ncsc.mil (8.13.1/8.13.1) with ESMTP id p8JMhgY6021336; Mon, 19 Sep 2011 18:43:42 -0400 From: Daniel De Graaf <dgdegra@tycho.nsa.gov> To: xen-devel@lists.xensource.com Date: Mon, 19 Sep 2011 18:43:26 -0400 Message-Id: <1316472208-12104-2-git-send-email-dgdegra@tycho.nsa.gov> X-Mailer: git-send-email 1.7.6.2 In-Reply-To: <1316472208-12104-1-git-send-email-dgdegra@tycho.nsa.gov> References: <1313764724-12683-1-git-send-email-dgdegra@tycho.nsa.gov> <1316472208-12104-1-git-send-email-dgdegra@tycho.nsa.gov> Cc: Ian.Campbell@eu.citrix.com, Daniel De Graaf <dgdegra@tycho.nsa.gov>, Stefano.Stabellini@eu.citrix.com, Ian.Jackson@eu.citrix.com, konrad.wilk@oracle.com Subject: [Xen-devel] [PATCH 1/3] libxc: add xc_gnttab_map_grant_ref_notify X-BeenThere: xen-devel@lists.xensource.com X-Mailman-Version: 2.1.5 Precedence: list List-Id: Xen developer discussion <xen-devel.lists.xensource.com> List-Unsubscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe> List-Post: <mailto:xen-devel@lists.xensource.com> List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help> List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=subscribe> Sender: xen-devel-bounces@lists.xensource.com Errors-To: xen-devel-bounces@lists.xensource.com Normally, when a userspace process mapping a grant crashes, the domain providing the reference receives no indication that its peer has crashed, possibly leading to unexpected freezes or timeouts. This function provides a notification of the unmap by signalling an event channel and/or clearing a specific byte in the page. Signed-off-by: Daniel De Graaf <dgdegra@tycho.nsa.gov> --- tools/include/xen-sys/Linux/gntdev.h | 33 +++++++++++++++++++- tools/libxc/xc_gnttab.c | 23 +++++++++++++ tools/libxc/xc_linux_osdep.c | 57 ++++++++++++++++++++++++++++++++++ tools/libxc/xenctrl.h | 24 ++++++++++++++ tools/libxc/xenctrlosdep.h | 6 +++ 5 files changed, 142 insertions(+), 1 deletions(-) diff --git a/tools/include/xen-sys/Linux/gntdev.h b/tools/include/xen-sys/Linux/gntdev.h index 8bd1467..5304bd3 100644 --- a/tools/include/xen-sys/Linux/gntdev.h +++ b/tools/include/xen-sys/Linux/gntdev.h @@ -66,7 +66,7 @@ struct ioctl_gntdev_map_grant_ref { * before this ioctl is called, or an error will result. */ #define IOCTL_GNTDEV_UNMAP_GRANT_REF \ -_IOC(_IOC_NONE, 'G', 1, sizeof(struct ioctl_gntdev_unmap_grant_ref)) +_IOC(_IOC_NONE, 'G', 1, sizeof(struct ioctl_gntdev_unmap_grant_ref)) struct ioctl_gntdev_unmap_grant_ref { /* IN parameters */ /* The offset was returned by the corresponding map operation. */ @@ -116,4 +116,35 @@ struct ioctl_gntdev_set_max_grants { uint32_t count; }; +/* + * Sets up an unmap notification within the page, so that the other side can do + * cleanup if this side crashes. Required to implement cross-domain robust + * mutexes or close notification on communication channels. + * + * Each mapped page only supports one notification; multiple calls referring to + * the same page overwrite the previous notification. You must clear the + * notification prior to the IOCTL_GNTALLOC_DEALLOC_GREF if you do not want it + * to occur. + */ +#define IOCTL_GNTDEV_SET_UNMAP_NOTIFY \ +_IOC(_IOC_NONE, 'G', 7, sizeof(struct ioctl_gntdev_unmap_notify)) +struct ioctl_gntdev_unmap_notify { + /* IN parameters */ + /* Offset in the file descriptor for a byte within the page (same as + * used in mmap). If using UNMAP_NOTIFY_CLEAR_BYTE, this is the byte to + * be cleared. Otherwise, it can be any byte in the page whose + * notification we are adjusting. + */ + uint64_t index; + /* Action(s) to take on unmap */ + uint32_t action; + /* Event channel to notify */ + uint32_t event_channel_port; +}; + +/* Clear (set to zero) the byte specified by index */ +#define UNMAP_NOTIFY_CLEAR_BYTE 0x1 +/* Send an interrupt on the indicated event channel */ +#define UNMAP_NOTIFY_SEND_EVENT 0x2 + #endif /* __LINUX_PUBLIC_GNTDEV_H__ */ diff --git a/tools/libxc/xc_gnttab.c b/tools/libxc/xc_gnttab.c index 4f55fce..3d3c63b 100644 --- a/tools/libxc/xc_gnttab.c +++ b/tools/libxc/xc_gnttab.c @@ -18,6 +18,7 @@ */ #include "xc_private.h" +#include <errno.h> int xc_gnttab_op(xc_interface *xch, int cmd, void * op, int op_size, int count) { @@ -174,6 +175,28 @@ void *xc_gnttab_map_domain_grant_refs(xc_gnttab *xcg, count, domid, refs, prot); } +void *xc_gnttab_map_grant_ref_notify(xc_gnttab *xcg, + uint32_t domid, + uint32_t ref, + uint32_t notify_offset, + evtchn_port_t notify_port, + int *notify_result) +{ + if (xcg->ops->u.gnttab.map_grant_ref_notify) + return xcg->ops->u.gnttab.map_grant_ref_notify(xcg, xcg->ops_handle, + domid, ref, notify_offset, notify_port, notify_result); + else { + void* area = xcg->ops->u.gnttab.map_grant_ref(xcg, xcg->ops_handle, + domid, ref, PROT_READ|PROT_WRITE); + if (area && notify_result) { + *notify_result = -1; + errno = ENOSYS; + } + return area; + } +} + + int xc_gnttab_munmap(xc_gnttab *xcg, void *start_address, uint32_t count) diff --git a/tools/libxc/xc_linux_osdep.c b/tools/libxc/xc_linux_osdep.c index dca6718..3040cb6 100644 --- a/tools/libxc/xc_linux_osdep.c +++ b/tools/libxc/xc_linux_osdep.c @@ -613,6 +613,62 @@ static void *linux_gnttab_map_domain_grant_refs(xc_gnttab *xcg, xc_osdep_handle return do_gnttab_map_grant_refs(xcg, h, count, &domid, 0, refs, prot); } +static void *linux_gnttab_map_grant_ref_notify(xc_gnttab *xch, xc_osdep_handle h, + uint32_t domid, uint32_t ref, + uint32_t notify_offset, + evtchn_port_t notify_port, + int *notify_result) +{ + int fd = (int)h; + int rv = 0; + struct ioctl_gntdev_map_grant_ref map; + struct ioctl_gntdev_unmap_notify notify; + void *addr; + + map.count = 1; + map.refs[0].domid = domid; + map.refs[0].ref = ref; + + if ( ioctl(fd, IOCTL_GNTDEV_MAP_GRANT_REF, &map) ) { + PERROR("xc_gnttab_map_grant_ref: ioctl MAP_GRANT_REF failed"); + return NULL; + } + + addr = mmap(NULL, XC_PAGE_SIZE, PROT_READ|PROT_WRITE, MAP_SHARED, fd, map.index); + if ( addr == MAP_FAILED ) + { + int saved_errno = errno; + struct ioctl_gntdev_unmap_grant_ref unmap_grant; + + PERROR("xc_gnttab_map_grant_ref: mmap failed"); + unmap_grant.index = map.index; + unmap_grant.count = 1; + ioctl(fd, IOCTL_GNTDEV_UNMAP_GRANT_REF, &unmap_grant); + errno = saved_errno; + return NULL; + } + + notify.index = map.index; + notify.action = 0; + if (notify_offset >= 0) { + notify.index += notify_offset; + notify.action |= UNMAP_NOTIFY_CLEAR_BYTE; + } + if (notify_port >= 0) { + notify.event_channel_port = notify_port; + notify.action |= UNMAP_NOTIFY_SEND_EVENT; + } + if (notify.action) + rv = ioctl(fd, IOCTL_GNTDEV_SET_UNMAP_NOTIFY, ¬ify); + if (rv) + PERROR("linux_gnttab_map_grant_ref_notify: ioctl SET_UNMAP_NOTIFY failed"); + if (notify_result) + *notify_result = rv; + + return addr; +} + + static int linux_gnttab_munmap(xc_gnttab *xcg, xc_osdep_handle h, void *start_address, uint32_t count) { @@ -662,6 +718,7 @@ static struct xc_osdep_ops linux_gnttab_ops = { .map_grant_ref = &linux_gnttab_map_grant_ref, .map_grant_refs = &linux_gnttab_map_grant_refs, .map_domain_grant_refs = &linux_gnttab_map_domain_grant_refs, + .map_grant_ref_notify = &linux_gnttab_map_grant_ref_notify, .munmap = &linux_gnttab_munmap, }, }; diff --git a/tools/libxc/xenctrl.h b/tools/libxc/xenctrl.h index 1b82ee0..02c10fa 100644 --- a/tools/libxc/xenctrl.h +++ b/tools/libxc/xenctrl.h @@ -1349,6 +1349,30 @@ void *xc_gnttab_map_domain_grant_refs(xc_gnttab *xcg, int prot); /* + * Memory maps a grant reference from one domain to a local address range. + * Mappings should be unmapped with xc_gnttab_munmap. This version always maps + * writable pages, and will attempt to set up an unmap notification at the given + * offset and event channel. When the page is unmapped, the byte at the given + * offset will be zeroed and a wakeup will be sent to the given event channel. + * Logs errors. + * + * @parm xcg a handle on an open grant table interface + * @parm domid the domain to map memory from + * @parm ref the grant reference ID to map + * @parm notify_offset The byte offset in the page to use for unmap + * notification; -1 for none. + * @parm notify_port The event channel port to use for unmap notify, or -1 + * @parm notify_result If nonnull, set to 0 if the notify setup succeeded + * or an errno value if not. + */ +void *xc_gnttab_map_grant_ref_notify(xc_gnttab *xcg, + uint32_t domid, + uint32_t ref, + uint32_t notify_offset, + evtchn_port_t notify_port, + int *notify_result); + +/* * Unmaps the @count pages starting at @start_address, which were mapped by a * call to xc_gnttab_map_grant_ref or xc_gnttab_map_grant_refs. Never logs. */ diff --git a/tools/libxc/xenctrlosdep.h b/tools/libxc/xenctrlosdep.h index bfe46e0..bf81538 100644 --- a/tools/libxc/xenctrlosdep.h +++ b/tools/libxc/xenctrlosdep.h @@ -119,6 +119,12 @@ struct xc_osdep_ops uint32_t domid, uint32_t *refs, int prot); + void *(*map_grant_ref_notify)(xc_gnttab *xcg, xc_osdep_handle h, + uint32_t domid, + uint32_t ref, + uint32_t notify_offset, + evtchn_port_t notify_port, + int *notify_result); int (*munmap)(xc_gnttab *xcg, xc_osdep_handle h, void *start_address, uint32_t count); -- 1.7.6.2 _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel From xen-devel-bounces@lists.xensource.com Mon Sep 19 15:46:37 2011 Return-path: <xen-devel-bounces@lists.xensource.com> Envelope-to: www-data@lists.xensource.com Delivery-date: Mon, 19 Sep 2011 15:46:37 -0700 Received: from localhost ([127.0.0.1] helo=lists.colo.xensource.com) by lists.xensource.com with esmtp (Exim 4.43) id 1R5mbl-0007qo-8r; Mon, 19 Sep 2011 15:46:37 -0700 Received: from mail182.messagelabs.com ([85.158.139.83]) by lists.xensource.com with smtp (Exim 4.43) id 1R5mZ2-0006uF-Ng for xen-devel@lists.xensource.com; Mon, 19 Sep 2011 15:43:49 -0700 X-Env-Sender: dgdegra@tycho.nsa.gov X-Msg-Ref: server-6.tower-182.messagelabs.com!1316472225!18955648!1 X-Originating-IP: [63.239.65.40] X-StarScan-Version: 6.4.1; banners=-,-,- X-VirusChecked: Checked Received: (qmail 8589 invoked from network); 19 Sep 2011 22:43:45 -0000 Received: from msux-gh1-uea02.nsa.gov (HELO msux-gh1-uea02.nsa.gov) (63.239.65.40) by server-6.tower-182.messagelabs.com with SMTP; 19 Sep 2011 22:43:45 -0000 Received: from tarius.tycho.ncsc.mil (localhost [127.0.0.1]) by msux-gh1-uea02.nsa.gov (8.12.10/8.12.10) with ESMTP id p8JMhgh2002473; Mon, 19 Sep 2011 22:43:42 GMT Received: from moss-nexus.epoch.ncsc.mil (moss-nexus [144.51.25.48]) by tarius.tycho.ncsc.mil (8.13.1/8.13.1) with ESMTP id p8JMhgY7021336; Mon, 19 Sep 2011 18:43:42 -0400 From: Daniel De Graaf <dgdegra@tycho.nsa.gov> To: xen-devel@lists.xensource.com Date: Mon, 19 Sep 2011 18:43:27 -0400 Message-Id: <1316472208-12104-3-git-send-email-dgdegra@tycho.nsa.gov> X-Mailer: git-send-email 1.7.6.2 In-Reply-To: <1316472208-12104-1-git-send-email-dgdegra@tycho.nsa.gov> References: <1313764724-12683-1-git-send-email-dgdegra@tycho.nsa.gov> <1316472208-12104-1-git-send-email-dgdegra@tycho.nsa.gov> Cc: Ian.Campbell@eu.citrix.com, Daniel De Graaf <dgdegra@tycho.nsa.gov>, Stefano.Stabellini@eu.citrix.com, Ian.Jackson@eu.citrix.com, konrad.wilk@oracle.com Subject: [Xen-devel] [PATCH 2/3] libxc: add xc_gntshr_* functions X-BeenThere: xen-devel@lists.xensource.com X-Mailman-Version: 2.1.5 Precedence: list List-Id: Xen developer discussion <xen-devel.lists.xensource.com> List-Unsubscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe> List-Post: <mailto:xen-devel@lists.xensource.com> List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help> List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=subscribe> Sender: xen-devel-bounces@lists.xensource.com Errors-To: xen-devel-bounces@lists.xensource.com These functions and the xc_gntshr device (/dev/xen/gntalloc on linux) allow applications to create pages shared with other domains. Signed-off-by: Daniel De Graaf <dgdegra@tycho.nsa.gov> --- tools/include/xen-sys/Linux/gntalloc.h | 82 ++++++++++++++++++ tools/libxc/xc_gnttab.c | 29 +++++++ tools/libxc/xc_linux_osdep.c | 142 ++++++++++++++++++++++++++++++++ tools/libxc/xc_private.c | 13 +++ tools/libxc/xenctrl.h | 53 ++++++++++++- tools/libxc/xenctrlosdep.h | 14 +++ 6 files changed, 332 insertions(+), 1 deletions(-) create mode 100644 tools/include/xen-sys/Linux/gntalloc.h diff --git a/tools/include/xen-sys/Linux/gntalloc.h b/tools/include/xen-sys/Linux/gntalloc.h new file mode 100644 index 0000000..76bd580 --- /dev/null +++ b/tools/include/xen-sys/Linux/gntalloc.h @@ -0,0 +1,82 @@ +/****************************************************************************** + * gntalloc.h + * + * Interface to /dev/xen/gntalloc. + * + * Author: Daniel De Graaf <dgdegra@tycho.nsa.gov> + * + * This file is in the public domain. + */ + +#ifndef __LINUX_PUBLIC_GNTALLOC_H__ +#define __LINUX_PUBLIC_GNTALLOC_H__ + +/* + * Allocates a new page and creates a new grant reference. + */ +#define IOCTL_GNTALLOC_ALLOC_GREF \ +_IOC(_IOC_NONE, 'G', 5, sizeof(struct ioctl_gntalloc_alloc_gref)) +struct ioctl_gntalloc_alloc_gref { + /* IN parameters */ + /* The ID of the domain to be given access to the grants. */ + uint16_t domid; + /* Flags for this mapping */ + uint16_t flags; + /* Number of pages to map */ + uint32_t count; + /* OUT parameters */ + /* The offset to be used on a subsequent call to mmap(). */ + uint64_t index; + /* The grant references of the newly created grant, one per page */ + /* Variable size, depending on count */ + uint32_t gref_ids[1]; +}; + +#define GNTALLOC_FLAG_WRITABLE 1 + +/* + * Deallocates the grant reference, allowing the associated page to be freed if + * no other domains are using it. + */ +#define IOCTL_GNTALLOC_DEALLOC_GREF \ +_IOC(_IOC_NONE, 'G', 6, sizeof(struct ioctl_gntalloc_dealloc_gref)) +struct ioctl_gntalloc_dealloc_gref { + /* IN parameters */ + /* The offset returned in the map operation */ + uint64_t index; + /* Number of references to unmap */ + uint32_t count; +}; + +/* + * Sets up an unmap notification within the page, so that the other side can do + * cleanup if this side crashes. Required to implement cross-domain robust + * mutexes or close notification on communication channels. + * + * Each mapped page only supports one notification; multiple calls referring to + * the same page overwrite the previous notification. You must clear the + * notification prior to the IOCTL_GNTALLOC_DEALLOC_GREF if you do not want it + * to occur. + */ +#define IOCTL_GNTALLOC_SET_UNMAP_NOTIFY \ +_IOC(_IOC_NONE, 'G', 7, sizeof(struct ioctl_gntalloc_unmap_notify)) +struct ioctl_gntalloc_unmap_notify { + /* IN parameters */ + /* Offset in the file descriptor for a byte within the page (same as + * used in mmap). If using UNMAP_NOTIFY_CLEAR_BYTE, this is the byte to + * be cleared. Otherwise, it can be any byte in the page whose + * notification we are adjusting. + */ + uint64_t index; + /* Action(s) to take on unmap */ + uint32_t action; + /* Event channel to notify */ + uint32_t event_channel_port; +}; + +/* Clear (set to zero) the byte specified by index */ +#define UNMAP_NOTIFY_CLEAR_BYTE 0x1 +/* Send an interrupt on the indicated event channel */ +#define UNMAP_NOTIFY_SEND_EVENT 0x2 + +#endif /* __LINUX_PUBLIC_GNTALLOC_H__ */ diff --git a/tools/libxc/xc_gnttab.c b/tools/libxc/xc_gnttab.c index 3d3c63b..ea8f76f 100644 --- a/tools/libxc/xc_gnttab.c +++ b/tools/libxc/xc_gnttab.c @@ -212,6 +212,35 @@ int xc_gnttab_set_max_grants(xc_gnttab *xcg, uint32_t count) return xcg->ops->u.gnttab.set_max_grants(xcg, xcg->ops_handle, count); } +void *xc_gntshr_share_pages(xc_gntshr *xcg, uint32_t domid, + int count, uint32_t *refs, int writable) +{ + return xcg->ops->u.gntshr.share_pages(xcg, xcg->ops_handle, domid, + count, refs, writable); +} + +void *xc_gntshr_share_page_notify(xc_gntshr *xcg, uint32_t domid, + uint32_t *ref, int writable, + uint32_t notify_offset, + evtchn_port_t notify_port, + int *notify_result) +{ + return xcg->ops->u.gntshr.share_page_notify(xcg, xcg->ops_handle, + domid, ref, writable, notify_offset, notify_port, + notify_result); +} + +/* + * Unmaps the @count pages starting at @start_address, which were mapped by a + * call to xc_gntshr_share_*. Never logs. + */ +int xc_gntshr_munmap(xc_gntshr *xcg, void *start_address, uint32_t count) +{ + return xcg->ops->u.gntshr.munmap(xcg, xcg->ops_handle, + start_address, count); +} + + /* * Local variables: * mode: C diff --git a/tools/libxc/xc_linux_osdep.c b/tools/libxc/xc_linux_osdep.c index 3040cb6..6616357 100644 --- a/tools/libxc/xc_linux_osdep.c +++ b/tools/libxc/xc_linux_osdep.c @@ -34,6 +34,7 @@ #include <xen/memory.h> #include <xen/sys/evtchn.h> #include <xen/sys/gntdev.h> +#include <xen/sys/gntalloc.h> #include "xenctrl.h" #include "xenctrlosdep.h" @@ -723,6 +724,145 @@ static struct xc_osdep_ops linux_gnttab_ops = { }, }; +static xc_osdep_handle linux_gntshr_open(xc_gntshr *xcg) +{ + int fd = open(DEVXEN "gntalloc", O_RDWR); + + if ( fd == -1 ) + return XC_OSDEP_OPEN_ERROR; + + return (xc_osdep_handle)fd; +} + +static int linux_gntshr_close(xc_gntshr *xcg, xc_osdep_handle h) +{ + int fd = (int)h; + return close(fd); +} + +static void *linux_gntshr_share_pages(xc_gntshr *xch, xc_osdep_handle h, + uint32_t domid, int count, + uint32_t *refs, int writable) +{ + struct ioctl_gntalloc_alloc_gref *gref_info = NULL; + struct ioctl_gntalloc_dealloc_gref gref_drop; + int err; + void *area = NULL; + gref_info = malloc(sizeof(*gref_info) + count * sizeof(uint32_t)); + if (!gref_info) + return NULL; + gref_info->domid = domid; + gref_info->flags = writable ? GNTALLOC_FLAG_WRITABLE : 0; + gref_info->count = count; + + err = ioctl((int)h, IOCTL_GNTALLOC_ALLOC_GREF, gref_info); + if (err) { + PERROR("linux_gntshr_share_pages: ioctl failed"); + goto out; + } + + area = mmap(NULL, count * XC_PAGE_SIZE, PROT_READ | PROT_WRITE, + MAP_SHARED, (int)h, gref_info->index); + + if (area == MAP_FAILED) { + area = NULL; + PERROR("linux_gntshr_share_pages: mmap failed"); + goto out_remove_fdmap; + } + + memcpy(refs, gref_info->gref_ids, count * sizeof(uint32_t)); + + out_remove_fdmap: + /* Removing the mapping from the file descriptor does not cause the pages to + * be deallocated until the mapping is removed. + */ + gref_drop.index = gref_info->index; + gref_drop.count = count; + ioctl((int)h, IOCTL_GNTALLOC_DEALLOC_GREF, &gref_drop); + out: + free(gref_info); + return area; +} + +static void *linux_gntshr_share_page_notify(xc_gntshr *xch, xc_osdep_handle h, + uint32_t domid, uint32_t *ref, + int writable, uint32_t notify_offset, + evtchn_port_t notify_port, + int *notify_result) +{ + struct ioctl_gntalloc_alloc_gref gref_info; + struct ioctl_gntalloc_unmap_notify notify; + struct ioctl_gntalloc_dealloc_gref gref_drop; + int err; + int fd = (int)h; + void *area = NULL; + gref_info.domid = domid; + gref_info.flags = writable ? GNTALLOC_FLAG_WRITABLE : 0; + gref_info.count = 1; + + err = ioctl(fd, IOCTL_GNTALLOC_ALLOC_GREF, &gref_info); + if (err) { + PERROR("linux_gntshr_share_page_notify: ioctl failed"); + goto out; + } + + area = mmap(NULL, XC_PAGE_SIZE, PROT_READ | PROT_WRITE, MAP_SHARED, + fd, gref_info.index); + + if (area == MAP_FAILED) { + PERROR("linux_gntshr_share_page_notify: mmap failed"); + area = NULL; + goto out_remove_fdmap; + } + + notify.index = gref_info.index; + notify.action = 0; + if (notify_offset >= 0) { + notify.index += notify_offset; + notify.action |= UNMAP_NOTIFY_CLEAR_BYTE; + } + if (notify_port >= 0) { + notify.event_channel_port = notify_port; + notify.action |= UNMAP_NOTIFY_SEND_EVENT; + } + if (notify.action) + err = ioctl(fd, IOCTL_GNTALLOC_SET_UNMAP_NOTIFY, ¬ify); + if (err) + PERROR("linux_gntshr_share_page_notify: ioctl SET_UNMAP_NOTIFY failed"); + if (notify_result) + *notify_result = err; + + *ref = gref_info.gref_ids[0]; + out_remove_fdmap: + /* Removing the mapping from the file descriptor does not cause the pages to + * be deallocated until the mapping is removed. + */ + gref_drop.index = gref_info.index; + gref_drop.count = 1; + ioctl((int)h, IOCTL_GNTALLOC_DEALLOC_GREF, &gref_drop); + out: + return area; +} + + +static int linux_gntshr_munmap(xc_gntshr *xcg, xc_osdep_handle h, + void *start_address, uint32_t count) +{ + return munmap(start_address, count); +} + +static struct xc_osdep_ops linux_gntshr_ops = { + .open = &linux_gntshr_open, + .close = &linux_gntshr_close, + + .u.gntshr = { + .share_pages = &linux_gntshr_share_pages, + .share_page_notify = &linux_gntshr_share_page_notify, + .munmap = &linux_gntshr_munmap, + }, +}; + + static struct xc_osdep_ops *linux_osdep_init(xc_interface *xch, enum xc_osdep_type type) { switch ( type ) @@ -733,6 +873,8 @@ static struct xc_osdep_ops *linux_osdep_init(xc_interface *xch, enum xc_osdep_ty return &linux_evtchn_ops; case XC_OSDEP_GNTTAB: return &linux_gnttab_ops; + case XC_OSDEP_GNTSHR: + return &linux_gntshr_ops; default: return NULL; } diff --git a/tools/libxc/xc_private.c b/tools/libxc/xc_private.c index 09c8f23..09a91e7 100644 --- a/tools/libxc/xc_private.c +++ b/tools/libxc/xc_private.c @@ -258,6 +258,19 @@ int xc_gnttab_close(xc_gnttab *xcg) return xc_interface_close_common(xcg); } +xc_gntshr *xc_gntshr_open(xentoollog_logger *logger, + unsigned open_flags) +{ + return xc_interface_open_common(logger, NULL, open_flags, + XC_OSDEP_GNTSHR); +} + +int xc_gntshr_close(xc_gntshr *xcg) +{ + return xc_interface_close_common(xcg); +} + + static pthread_key_t errbuf_pkey; static pthread_once_t errbuf_pkey_once = PTHREAD_ONCE_INIT; diff --git a/tools/libxc/xenctrl.h b/tools/libxc/xenctrl.h index 02c10fa..7fefa67 100644 --- a/tools/libxc/xenctrl.h +++ b/tools/libxc/xenctrl.h @@ -115,6 +115,7 @@ typedef struct xc_interface_core xc_interface; typedef struct xc_interface_core xc_evtchn; typedef struct xc_interface_core xc_gnttab; +typedef struct xc_interface_core xc_gntshr; typedef enum xc_error_code xc_error_code; @@ -1363,7 +1364,7 @@ void *xc_gnttab_map_domain_grant_refs(xc_gnttab *xcg, * notification; -1 for none. * @parm notify_port The event channel port to use for unmap notify, or -1 * @parm notify_result If nonnull, set to 0 if the notify setup succeeded - * or an errno value if not. + * or -1 if not. */ void *xc_gnttab_map_grant_ref_notify(xc_gnttab *xcg, uint32_t domid, @@ -1403,6 +1404,56 @@ grant_entry_v1_t *xc_gnttab_map_table_v1(xc_interface *xch, int domid, int *gnt_ grant_entry_v2_t *xc_gnttab_map_table_v2(xc_interface *xch, int domid, int *gnt_num); /* Sometimes these don't set errno [fixme], and sometimes they don't log. */ +/* + * Return an fd onto the grant sharing driver. Logs errors. + */ +xc_gntshr *xc_gntshr_open(xentoollog_logger *logger, + unsigned open_flags); + +/* + * Close a handle previously allocated with xc_gntshr_open(). + * Never logs errors. + */ +int xc_gntshr_close(xc_gntshr *xcg); + +/* + * Creates and shares pages with another domain. + * + * @parm xcg a handle to an open grant sharing instance + * @parm domid the domain to share memory with + * @parm count the number of pages to share + * @parm refs the grant references of the pages (output) + * @parm writable true if the other domain can write to the pages + * @return local mapping of the pages + */ +void *xc_gntshr_share_pages(xc_gntshr *xcg, uint32_t domid, + int count, uint32_t *refs, int writable); + +/* + * Creates and shares a page with another domain, with unmap notification. + * + * @parm xcg a handle to an open grant sharing instance + * @parm domid the domain to share memory with + * @parm refs the grant reference of the pages (output) + * @parm writable true if the other domain can write to the page + * @parm notify_offset The byte offset in the page to use for unmap + * notification; -1 for none. + * @parm notify_port The event channel port to use for unmap notify, or -1 + * @parm notify_result If nonnull, set to 0 if the notify setup succeeded + * or -1 if not. + * @return local mapping of the page + */ +void *xc_gntshr_share_page_notify(xc_gntshr *xcg, uint32_t domid, + uint32_t *ref, int writable, + uint32_t notify_offset, + evtchn_port_t notify_port, + int *notify_result); +/* + * Unmaps the @count pages starting at @start_address, which were mapped by a + * call to xc_gntshr_share_*. Never logs. + */ +int xc_gntshr_munmap(xc_gntshr *xcg, void *start_address, uint32_t count); + int xc_physdev_map_pirq(xc_interface *xch, int domid, int index, diff --git a/tools/libxc/xenctrlosdep.h b/tools/libxc/xenctrlosdep.h index bf81538..17edc39 100644 --- a/tools/libxc/xenctrlosdep.h +++ b/tools/libxc/xenctrlosdep.h @@ -54,6 +54,7 @@ enum xc_osdep_type { XC_OSDEP_PRIVCMD, XC_OSDEP_EVTCHN, XC_OSDEP_GNTTAB, + XC_OSDEP_GNTSHR, }; /* Opaque handle internal to the backend */ @@ -130,6 +131,19 @@ struct xc_osdep_ops uint32_t count); int (*set_max_grants)(xc_gnttab *xcg, xc_osdep_handle h, uint32_t count); } gnttab; + struct { + void *(*share_pages)(xc_gntshr *xcg, xc_osdep_handle h, + uint32_t domid, int count, + uint32_t *refs, int writable); + void *(*share_page_notify)(xc_gntshr *xcg, xc_osdep_handle h, + uint32_t domid, + uint32_t *ref, int writable, + uint32_t notify_offset, + evtchn_port_t notify_port, + int *notify_result); + int (*munmap)(xc_gntshr *xcg, xc_osdep_handle h, + void *start_address, uint32_t count); + } gntshr; } u; }; typedef struct xc_osdep_ops xc_osdep_ops; -- 1.7.6.2 _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel From xen-devel-bounces@lists.xensource.com Mon Sep 19 15:47:53 2011 Return-path: <xen-devel-bounces@lists.xensource.com> Envelope-to: www-data@lists.xensource.com Delivery-date: Mon, 19 Sep 2011 15:47:53 -0700 Received: from localhost ([127.0.0.1] helo=lists.colo.xensource.com) by lists.xensource.com with esmtp (Exim 4.43) id 1R5mcz-0008E1-3n; Mon, 19 Sep 2011 15:47:53 -0700 Received: from mail21.messagelabs.com ([85.158.143.35]) by lists.xensource.com with smtp (Exim 4.43) id 1R5mZ2-0006uE-M8 for xen-devel@lists.xensource.com; Mon, 19 Sep 2011 15:43:50 -0700 X-Env-Sender: dgdegra@tycho.nsa.gov X-Msg-Ref: server-9.tower-21.messagelabs.com!1316472180!49034539!1 X-Originating-IP: [63.239.65.40] X-StarScan-Version: 6.4.1; banners=-,-,- X-VirusChecked: Checked Received: (qmail 30250 invoked from network); 19 Sep 2011 22:43:01 -0000 Received: from msux-gh1-uea02.nsa.gov (HELO msux-gh1-uea02.nsa.gov) (63.239.65.40) by server-9.tower-21.messagelabs.com with SMTP; 19 Sep 2011 22:43:01 -0000 Received: from tarius.tycho.ncsc.mil (localhost [127.0.0.1]) by msux-gh1-uea02.nsa.gov (8.12.10/8.12.10) with ESMTP id p8JMhgh2002474; Mon, 19 Sep 2011 22:43:42 GMT Received: from moss-nexus.epoch.ncsc.mil (moss-nexus [144.51.25.48]) by tarius.tycho.ncsc.mil (8.13.1/8.13.1) with ESMTP id p8JMhgY8021336; Mon, 19 Sep 2011 18:43:42 -0400 From: Daniel De Graaf <dgdegra@tycho.nsa.gov> To: xen-devel@lists.xensource.com Date: Mon, 19 Sep 2011 18:43:28 -0400 Message-Id: <1316472208-12104-4-git-send-email-dgdegra@tycho.nsa.gov> X-Mailer: git-send-email 1.7.6.2 In-Reply-To: <1316472208-12104-1-git-send-email-dgdegra@tycho.nsa.gov> References: <1313764724-12683-1-git-send-email-dgdegra@tycho.nsa.gov> <1316472208-12104-1-git-send-email-dgdegra@tycho.nsa.gov> Cc: Ian.Campbell@eu.citrix.com, Daniel De Graaf <dgdegra@tycho.nsa.gov>, Stefano.Stabellini@eu.citrix.com, Ian.Jackson@eu.citrix.com, konrad.wilk@oracle.com Subject: [Xen-devel] [PATCH 3/3] libvchan: interdomain communications library X-BeenThere: xen-devel@lists.xensource.com X-Mailman-Version: 2.1.5 Precedence: list List-Id: Xen developer discussion <xen-devel.lists.xensource.com> List-Unsubscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe> List-Post: <mailto:xen-devel@lists.xensource.com> List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help> List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=subscribe> Sender: xen-devel-bounces@lists.xensource.com Errors-To: xen-devel-bounces@lists.xensource.com This library implements a bidirectional communication interface between applications in different domains, similar to unix sockets. Data can be sent using the byte-oriented libvchan_read/libvchan_write or the packet-oriented libvchan_recv/libvchan_send. Channel setup is done using a client-server model; domain IDs and a port number must be negotiated prior to initialization. The server allocates memory for the shared pages and determines the sizes of the communication rings (which may span multiple pages, although the default places rings and control within a single page). With properly sized rings, testing has shown that this interface provides speed comparable to pipes within a single Linux domain; it is significantly faster than network-based communication. Signed-off-by: Daniel De Graaf <dgdegra@tycho.nsa.gov> --- tools/Makefile | 1 + tools/Rules.mk | 5 + tools/libvchan/Makefile | 59 ++++++ tools/libvchan/init.c | 397 ++++++++++++++++++++++++++++++++++++++ tools/libvchan/io.c | 375 +++++++++++++++++++++++++++++++++++ tools/libvchan/libxenvchan.h | 173 +++++++++++++++++ tools/libvchan/node-select.c | 162 ++++++++++++++++ tools/libvchan/node.c | 169 ++++++++++++++++ xen/include/public/io/libvchan.h | 97 +++++++++ 9 files changed, 1438 insertions(+), 0 deletions(-) create mode 100644 tools/libvchan/Makefile create mode 100644 tools/libvchan/init.c create mode 100644 tools/libvchan/io.c create mode 100644 tools/libvchan/libxenvchan.h create mode 100644 tools/libvchan/node-select.c create mode 100644 tools/libvchan/node.c create mode 100644 xen/include/public/io/libvchan.h diff --git a/tools/Makefile b/tools/Makefile index df6270c..9389e1f 100644 --- a/tools/Makefile +++ b/tools/Makefile @@ -27,6 +27,7 @@ SUBDIRS-$(CONFIG_NetBSD) += blktap2 SUBDIRS-$(CONFIG_NetBSD) += xenbackendd SUBDIRS-y += libfsimage SUBDIRS-$(LIBXENAPI_BINDINGS) += libxen +SUBDIRS-y += libvchan # do not recurse in to a dir we are about to delete ifneq "$(MAKECMDGOALS)" "distclean" diff --git a/tools/Rules.mk b/tools/Rules.mk index 0d048af..49125f5 100644 --- a/tools/Rules.mk +++ b/tools/Rules.mk @@ -14,6 +14,7 @@ XEN_XENLIGHT = $(XEN_ROOT)/tools/libxl XEN_XENSTORE = $(XEN_ROOT)/tools/xenstore XEN_LIBXENSTAT = $(XEN_ROOT)/tools/xenstat/libxenstat/src XEN_BLKTAP2 = $(XEN_ROOT)/tools/blktap2 +XEN_LIBVCHAN = $(XEN_ROOT)/tools/libvchan CFLAGS_xeninclude = -I$(XEN_INCLUDE) @@ -33,6 +34,10 @@ CFLAGS_libxenstat = -I$(XEN_LIBXENSTAT) LDLIBS_libxenstat = $(SHLIB_libxenctrl) $(SHLIB_libxenstore) -L$(XEN_LIBXENSTAT) -lxenstat SHLIB_libxenstat = -Wl,-rpath-link=$(XEN_LIBXENSTAT) +CFLAGS_libxenvchan = -I$(XEN_LIBVCHAN) +LDLIBS_libxenvchan = $(SHLIB_libxenctrl) $(SHLIB_libxenstore) -L$(XEN_LIBVCHAN) -lxenvchan +SHLIB_libxenvchan = -Wl,-rpath-link=$(XEN_LIBVCHAN) + ifeq ($(CONFIG_Linux),y) LIBXL_BLKTAP = y else diff --git a/tools/libvchan/Makefile b/tools/libvchan/Makefile new file mode 100644 index 0000000..daf3593 --- /dev/null +++ b/tools/libvchan/Makefile @@ -0,0 +1,59 @@ +# +# tools/libvchan/Makefile +# + +XEN_ROOT = $(CURDIR)/../.. +include $(XEN_ROOT)/tools/Rules.mk + +LIBVCHAN_OBJS = init.o io.o +NODE_OBJS = node.o +NODE2_OBJS = node-select.o + +LIBVCHAN_PIC_OBJS = $(patsubst %.o,%.opic,$(LIBVCHAN_OBJS)) +LIBVCHAN_LIBS = $(LDLIBS_libxenstore) $(LDLIBS_libxenctrl) +$(LIBVCHAN_OBJS) $(LIBVCHAN_PIC_OBJS): CFLAGS += $(CFLAGS_libxenstore) $(CFLAGS_libxenctrl) +$(NODE_OBJS) $(NODE2_OBJS): CFLAGS += $(CFLAGS_libxenctrl) + +MAJOR = 1.0 +MINOR = 0 + +CFLAGS += -I../include -I. + +.PHONY: all +all: libxenvchan.so vchan-node1 vchan-node2 libxenvchan.a + +libxenvchan.so: libxenvchan.so.$(MAJOR) + ln -sf $< $@ + +libxenvchan.so.$(MAJOR): libxenvchan.so.$(MAJOR).$(MINOR) + ln -sf $< $@ + +libxenvchan.so.$(MAJOR).$(MINOR): $(LIBVCHAN_PIC_OBJS) + $(CC) $(LDFLAGS) -Wl,$(SONAME_LDFLAG) -Wl,libxenvchan.so.$(MAJOR) $(SHLIB_LDFLAGS) -o $@ $^ $(LIBVCHAN_LIBS) + +libxenvchan.a: $(LIBVCHAN_OBJS) + $(AR) rcs libxenvchan.a $^ + +vchan-node1: $(NODE_OBJS) libxenvchan.so + $(CC) $(LDFLAGS) -o $@ $(NODE_OBJS) $(LDLIBS_libxenvchan) + +vchan-node2: $(NODE2_OBJS) libxenvchan.so + $(CC) $(LDFLAGS) -o $@ $(NODE2_OBJS) $(LDLIBS_libxenvchan) + +.PHONY: install +install: all + $(INSTALL_DIR) $(DESTDIR)$(LIBDIR) + $(INSTALL_DIR) $(DESTDIR)$(INCLUDEDIR) + $(INSTALL_PROG) libxenvchan.so.$(MAJOR).$(MINOR) $(DESTDIR)$(LIBDIR) + ln -sf libxenvchan.so.$(MAJOR).$(MINOR) $(DESTDIR)$(LIBDIR)/libxenvchan.so.$(MAJOR) + ln -sf libxenvchan.so.$(MAJOR) $(DESTDIR)$(LIBDIR)/libxenvchan.so + $(INSTALL_DATA) libxenvchan.h $(DESTDIR)$(INCLUDEDIR) + $(INSTALL_DATA) libxenvchan.a $(DESTDIR)$(LIBDIR) + +.PHONY: clean +clean: + $(RM) -f *.o *.so* *.a vchan-node1 vchan-node2 $(DEPS) + +distclean: clean + +-include $(DEPS) diff --git a/tools/libvchan/init.c b/tools/libvchan/init.c new file mode 100644 index 0000000..c9ad883 --- /dev/null +++ b/tools/libvchan/init.c @@ -0,0 +1,397 @@ +/** + * @file + * @section AUTHORS + * + * Copyright (C) 2010 Rafal Wojtczuk <rafal@invisiblethingslab.com> + * + * Authors: + * Rafal Wojtczuk <rafal@invisiblethingslab.com> + * Daniel De Graaf <dgdegra@tycho.nsa.gov> + * + * @section LICENSE + * + * This library is free software; you can redistribute it and/or + * modify it under the terms of the GNU Lesser General Public + * License as published by the Free Software Foundation; either + * version 2 of the License, or (at your option) any later version. + * + * This library is distributed in the hope that it will be useful, + * but WITHOUT ANY WARRANTY; without even the implied warranty of + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU + * Lesser General Public License for more details. + * + * You should have received a copy of the GNU Lesser General Public + * License along with this library; if not, write to the Free Software + * Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston, MA 02110-1301 USA + * + * @section DESCRIPTION + * + * This file contains the setup code used to establish the ring buffer. + */ + +#include <sys/types.h> +#include <sys/mman.h> +#include <sys/ioctl.h> +#include <sys/user.h> +#include <stdlib.h> +#include <stdio.h> +#include <stdint.h> +#include <string.h> +#include <unistd.h> +#include <fcntl.h> + +#include <xs.h> +#include <xen/sys/evtchn.h> +#include <xen/sys/gntalloc.h> +#include <xen/sys/gntdev.h> +#include <libxenvchan.h> + +#ifndef PAGE_SHIFT +#define PAGE_SHIFT 12 +#endif + +#ifndef PAGE_SIZE +#define PAGE_SIZE 4096 +#endif + +#ifndef offsetof +#define offsetof(TYPE, MEMBER) ((size_t) &((TYPE *)0)->MEMBER) +#endif + +#define max(a,b) ((a > b) ? a : b) + +static int init_gnt_srv(struct libvchan *ctrl) +{ + int pages_left = ctrl->read.order >= PAGE_SHIFT ? 1 << (ctrl->read.order - PAGE_SHIFT) : 0; + int pages_right = ctrl->write.order >= PAGE_SHIFT ? 1 << (ctrl->write.order - PAGE_SHIFT) : 0; + uint32_t ring_ref = -1; + void *ring; + + ring = xc_gntshr_share_page_notify(ctrl->gntshr, ctrl->other_domain_id, + &ring_ref, 1, offsetof(struct vchan_interface, srv_live), + ctrl->event_port, NULL); + + if (!ring) + goto out; + + memset(ring, 0, PAGE_SIZE); + + ctrl->ring = ring; + ctrl->read.shr = &ctrl->ring->left; + ctrl->write.shr = &ctrl->ring->right; + ctrl->ring->left_order = ctrl->read.order; + ctrl->ring->right_order = ctrl->write.order; + ctrl->ring->cli_live = 2; + ctrl->ring->srv_live = 1; + ctrl->ring->cli_notify = VCHAN_NOTIFY_WRITE; + + if (ctrl->read.order == 10) { + ctrl->read.buffer = ((void*)ctrl->ring) + 1024; + } else if (ctrl->read.order == 11) { + ctrl->read.buffer = ((void*)ctrl->ring) + 2048; + } else { + ctrl->read.buffer = xc_gntshr_share_pages(ctrl->gntshr, ctrl->other_domain_id, + pages_left, ctrl->ring->grants, 1); + if (!ctrl->read.buffer) + goto out_ring; + } + + if (ctrl->write.order == 10) { + ctrl->write.buffer = ((void*)ctrl->ring) + 1024; + } else if (ctrl->write.order == 11) { + ctrl->write.buffer = ((void*)ctrl->ring) + 2048; + } else { + ctrl->write.buffer = xc_gntshr_share_pages(ctrl->gntshr, ctrl->other_domain_id, + pages_right, ctrl->ring->grants + pages_left, 1); + if (!ctrl->write.buffer) + goto out_unmap_left; + } + +out: + return ring_ref; +out_unmap_left: + if (ctrl->read.order > 11) + xc_gntshr_munmap(ctrl->gntshr, ctrl->read.buffer, pages_left * PAGE_SIZE); +out_ring: + xc_gntshr_munmap(ctrl->gntshr, ring, PAGE_SIZE); + ring_ref = -1; + ctrl->ring = NULL; + ctrl->write.order = ctrl->read.order = 0; + goto out; +} + +static int init_gnt_cli(struct libvchan *ctrl, uint32_t ring_ref) +{ + int rv = -1; + uint32_t *grants; + + ctrl->ring = xc_gnttab_map_grant_ref_notify(ctrl->gnttab, + ctrl->other_domain_id, ring_ref, + offsetof(struct vchan_interface, cli_live), ctrl->event_port, + NULL); + + if (!ctrl->ring) + goto out; + + ctrl->write.order = ctrl->ring->left_order; + ctrl->read.order = ctrl->ring->right_order; + ctrl->write.shr = &ctrl->ring->left; + ctrl->read.shr = &ctrl->ring->right; + if (ctrl->write.order < 10 || ctrl->write.order > 24) + goto out_unmap_ring; + if (ctrl->read.order < 10 || ctrl->read.order > 24) + goto out_unmap_ring; + if (ctrl->read.order == ctrl->write.order && ctrl->read.order < 12) + goto out_unmap_ring; + + grants = ctrl->ring->grants; + + if (ctrl->write.order == 10) { + ctrl->write.buffer = ((void*)ctrl->ring) + 1024; + } else if (ctrl->write.order == 11) { + ctrl->write.buffer = ((void*)ctrl->ring) + 2048; + } else { + int pages_left = 1 << (ctrl->write.order - PAGE_SHIFT); + ctrl->write.buffer = xc_gnttab_map_domain_grant_refs(ctrl->gnttab, + pages_left, ctrl->other_domain_id, grants, PROT_READ|PROT_WRITE); + if (!ctrl->write.buffer) + goto out_unmap_ring; + grants += pages_left; + } + + if (ctrl->read.order == 10) { + ctrl->read.buffer = ((void*)ctrl->ring) + 1024; + } else if (ctrl->read.order == 11) { + ctrl->read.buffer = ((void*)ctrl->ring) + 2048; + } else { + int pages_right = 1 << (ctrl->read.order - PAGE_SHIFT); + ctrl->read.buffer = xc_gnttab_map_domain_grant_refs(ctrl->gnttab, + pages_right, ctrl->other_domain_id, grants, PROT_READ); + if (!ctrl->read.buffer) + goto out_unmap_left; + } + + rv = 0; + out: + return rv; + out_unmap_left: + if (ctrl->write.order >= PAGE_SHIFT) + xc_gnttab_munmap(ctrl->gnttab, ctrl->write.buffer, + 1 << ctrl->write.order); + out_unmap_ring: + xc_gnttab_munmap(ctrl->gnttab, ctrl->ring, PAGE_SIZE); + ctrl->ring = 0; + ctrl->write.order = ctrl->read.order = 0; + rv = -1; + goto out; +} + +static int init_evt_srv(struct libvchan *ctrl, xentoollog_logger *logger) +{ + ctrl->event = xc_evtchn_open(logger, 0); + if (!ctrl->event) + return -1; + ctrl->event_port = xc_evtchn_bind_unbound_port(ctrl->event, ctrl->other_domain_id); + if (ctrl->event_port < 0) + return -1; + if (xc_evtchn_unmask(ctrl->event, ctrl->event_port)) + return -1; + return 0; +} + +static int init_xs_srv(struct libvchan *ctrl, int ring_ref) +{ + int ret = -1; + struct xs_handle *xs; + struct xs_permissions perms[2]; + char buf[64]; + char ref[16]; + char* domid_str = NULL; + xs = xs_domain_open(); + if (!xs) + goto fail; + domid_str = xs_read(xs, 0, "domid", NULL); + if (!domid_str) + goto fail_xs_open; + + // owner domain is us + perms[0].id = atoi(domid_str); + // permissions for domains not listed = none + perms[0].perms = XS_PERM_NONE; + // other domains + perms[1].id = ctrl->other_domain_id; + perms[1].perms = XS_PERM_READ; + + snprintf(ref, sizeof ref, "%d", ring_ref); + snprintf(buf, sizeof buf, "data/vchan/%d/%d/ring-ref", ctrl->other_domain_id, ctrl->device_number); + if (!xs_write(xs, 0, buf, ref, strlen(ref))) + goto fail_xs_open; + if (!xs_set_permissions(xs, 0, buf, perms, 2)) + goto fail_xs_open; + + snprintf(ref, sizeof ref, "%d", ctrl->event_port); + snprintf(buf, sizeof buf, "data/vchan/%d/%d/event-channel", ctrl->other_domain_id, ctrl->device_number); + if (!xs_write(xs, 0, buf, ref, strlen(ref))) + goto fail_xs_open; + if (!xs_set_permissions(xs, 0, buf, perms, 2)) + goto fail_xs_open; + + ret = 0; + fail_xs_open: + free(domid_str); + xs_daemon_close(xs); + fail: + return ret; +} + +static int min_order(size_t siz) +{ + int rv = PAGE_SHIFT; + while (siz > (1 << rv)) + rv++; + return rv; +} + +struct libvchan *libvchan_server_init(xentoollog_logger *logger, int domain, int devno, size_t left_min, size_t right_min) +{ + // if you go over this size, you'll have too many grants to fit in the shared page. + size_t MAX_RING_SIZE = 256 * PAGE_SIZE; + struct libvchan *ctrl; + int ring_ref; + if (left_min > MAX_RING_SIZE || right_min > MAX_RING_SIZE) + return 0; + + ctrl = malloc(sizeof(*ctrl)); + if (!ctrl) + return 0; + + ctrl->other_domain_id = domain; + ctrl->device_number = devno; + ctrl->ring = NULL; + ctrl->event = NULL; + ctrl->is_server = 1; + ctrl->server_persist = 0; + + ctrl->read.order = min_order(left_min); + ctrl->write.order = min_order(right_min); + + // if we can avoid allocating extra pages by using in-page rings, do so +#define MAX_SMALL_RING 1024 +#define MAX_LARGE_RING 2048 + if (left_min <= MAX_SMALL_RING && right_min <= MAX_LARGE_RING) { + ctrl->read.order = 10; + ctrl->write.order = 11; + } else if (left_min <= MAX_LARGE_RING && right_min <= MAX_SMALL_RING) { + ctrl->read.order = 11; + ctrl->write.order = 10; + } else if (left_min <= MAX_LARGE_RING) { + ctrl->read.order = 11; + } else if (right_min <= MAX_LARGE_RING) { + ctrl->write.order = 11; + } + + ctrl->gntshr = xc_gntshr_open(logger, 0); + if (!ctrl->gntshr) + goto out; + + if (init_evt_srv(ctrl, logger)) + goto out; + ring_ref = init_gnt_srv(ctrl); + if (ring_ref < 0) + goto out; + if (init_xs_srv(ctrl, ring_ref)) + goto out; + return ctrl; +out: + libvchan_close(ctrl); + return 0; +} + +static int init_evt_cli(struct libvchan *ctrl, xentoollog_logger *logger) +{ + ctrl->event = xc_evtchn_open(logger, 0); + if (!ctrl->event) + return -1; + ctrl->event_port = xc_evtchn_bind_interdomain(ctrl->event, + ctrl->other_domain_id, ctrl->event_port); + if (ctrl->event_port < 0) + return -1; + xc_evtchn_unmask(ctrl->event, ctrl->event_port); + return 0; +} + + +struct libvchan *libvchan_client_init(xentoollog_logger *logger, int domain, int devno) +{ + struct libvchan *ctrl = malloc(sizeof(struct libvchan)); + struct xs_handle *xs = NULL; + char buf[64]; + char *ref; + int ring_ref; + unsigned int len; + char* domid_str = NULL; + + if (!ctrl) + return 0; + ctrl->other_domain_id = domain; + ctrl->device_number = devno; + ctrl->ring = NULL; + ctrl->event = NULL; + ctrl->write.order = ctrl->read.order = 0; + ctrl->is_server = 0; + + xs = xs_daemon_open(); + if (!xs) + xs = xs_domain_open(); + if (!xs) + goto fail; + + domid_str = xs_read(xs, 0, "domid", NULL); + if (!domid_str) + goto fail; + +// find xenstore entry + snprintf(buf, sizeof buf, "/local/domain/%d/data/vchan/%s/%d/ring-ref", + ctrl->other_domain_id, domid_str, ctrl->device_number); + ref = xs_read(xs, 0, buf, &len); + if (!ref) + goto fail; + ring_ref = atoi(ref); + free(ref); + if (!ring_ref) + goto fail; + snprintf(buf, sizeof buf, "/local/domain/%d/data/vchan/%s/%d/event-channel", + ctrl->other_domain_id, domid_str, ctrl->device_number); + ref = xs_read(xs, 0, buf, &len); + if (!ref) + goto fail; + ctrl->event_port = atoi(ref); + free(ref); + if (!ctrl->event_port) + goto fail; + + ctrl->gnttab = xc_gnttab_open(logger, 0); + if (!ctrl->gnttab) + goto out; + +// set up event channel + if (init_evt_cli(ctrl, logger)) + goto fail; + +// set up shared page(s) + if (init_gnt_cli(ctrl, ring_ref)) + goto fail; + + ctrl->ring->cli_live = 1; + ctrl->ring->srv_notify = VCHAN_NOTIFY_WRITE; + + out: + free(domid_str); + if (xs) + xs_daemon_close(xs); + return ctrl; + fail: + libvchan_close(ctrl); + ctrl = NULL; + goto out; +} diff --git a/tools/libvchan/io.c b/tools/libvchan/io.c new file mode 100644 index 0000000..08d5dcf --- /dev/null +++ b/tools/libvchan/io.c @@ -0,0 +1,375 @@ +/** + * @file + * @section AUTHORS + * + * Copyright (C) 2010 Rafal Wojtczuk <rafal@invisiblethingslab.com> + * + * Authors: + * Rafal Wojtczuk <rafal@invisiblethingslab.com> + * Daniel De Graaf <dgdegra@tycho.nsa.gov> + * + * @section LICENSE + * + * This library is free software; you can redistribute it and/or + * modify it under the terms of the GNU Lesser General Public + * License as published by the Free Software Foundation; either + * version 2 of the License, or (at your option) any later version. + * + * This library is distributed in the hope that it will be useful, + * but WITHOUT ANY WARRANTY; without even the implied warranty of + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU + * Lesser General Public License for more details. + * + * You should have received a copy of the GNU Lesser General Public + * License along with this library; if not, write to the Free Software + * Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston, MA 02110-1301 USA + * + * @section DESCRIPTION + * + * This file contains the communications interface built on the ring buffer. + */ + +#include <sys/types.h> +#include <sys/mman.h> +#include <sys/ioctl.h> +#include <sys/uio.h> +#include <stdlib.h> +#include <stdint.h> +#include <string.h> +#include <unistd.h> + +#include <xenctrl.h> +#include <libxenvchan.h> + +#ifndef PAGE_SHIFT +#define PAGE_SHIFT 12 +#endif + +#ifndef PAGE_SIZE +#define PAGE_SIZE 4096 +#endif + +// allow vchan data to be easily observed in strace by doing a +// writev() to FD -1 with the data being read/written. +#ifndef VCHAN_DEBUG +#define VCHAN_DEBUG 0 +#endif + +#define barrier() asm volatile("" ::: "memory") + + +static inline uint32_t rd_prod(struct libvchan *ctrl) +{ + return ctrl->read.shr->prod; +} + +static inline uint32_t* _rd_cons(struct libvchan *ctrl) +{ + return &ctrl->read.shr->cons; +} +#define rd_cons(x) (*_rd_cons(x)) + +static inline uint32_t* _wr_prod(struct libvchan *ctrl) +{ + return &ctrl->write.shr->prod; +} +#define wr_prod(x) (*_wr_prod(x)) + +static inline uint32_t wr_cons(struct libvchan *ctrl) +{ + return ctrl->write.shr->cons; +} + +static inline const void* rd_ring(struct libvchan *ctrl) +{ + return ctrl->read.buffer; +} + +static inline void* wr_ring(struct libvchan *ctrl) +{ + return ctrl->write.buffer; +} + +static inline uint32_t wr_ring_size(struct libvchan *ctrl) +{ + return (1 << ctrl->write.order); +} + +static inline uint32_t rd_ring_size(struct libvchan *ctrl) +{ + return (1 << ctrl->read.order); +} + +static inline void request_notify(struct libvchan *ctrl, uint8_t bit) +{ + uint8_t *notify = ctrl->is_server ? &ctrl->ring->cli_notify : &ctrl->ring->srv_notify; + __sync_or_and_fetch(notify, bit); +} + +static inline int send_notify(struct libvchan *ctrl, uint8_t bit) +{ + uint8_t *notify = ctrl->is_server ? &ctrl->ring->srv_notify : &ctrl->ring->cli_notify; + uint8_t prev = __sync_fetch_and_and(notify, ~bit); + if (prev & bit) + return xc_evtchn_notify(ctrl->event, ctrl->event_port); + else + return 0; +} + +/** + * Get the amount of buffer space available and enable notifications if needed. + */ +static inline int fast_get_data_ready(struct libvchan *ctrl, size_t request) +{ + int ready = rd_prod(ctrl) - rd_cons(ctrl); + if (ready >= request) + return ready; + /* We plan to consume all data; please tell us if you send more */ + request_notify(ctrl, VCHAN_NOTIFY_WRITE); + /* + * If the writer moved rd_prod after our read but before request, we + * will not get notified even though the actual amount of data ready is + * above request. Reread rd_prod to cover this case. + */ + return rd_prod(ctrl) - rd_cons(ctrl); +} + +int libvchan_data_ready(struct libvchan *ctrl) +{ + /* Since this value is being used outside libvchan, request notification + * when it changes + */ + request_notify(ctrl, VCHAN_NOTIFY_WRITE); + return rd_prod(ctrl) - rd_cons(ctrl); +} + +/** + * Get the amount of buffer space available and enable notifications if needed. + */ +static inline int fast_get_buffer_space(struct libvchan *ctrl, size_t request) +{ + int ready = wr_ring_size(ctrl) - (wr_prod(ctrl) - wr_cons(ctrl)); + if (ready >= request) + return ready; + /* We plan to fill the buffer; please tell us when you've read it */ + request_notify(ctrl, VCHAN_NOTIFY_READ); + /* + * If the reader moved wr_cons after our read but before request, we + * will not get notified even though the actual amount of buffer space + * is above request. Reread wr_cons to cover this case. + */ + return wr_ring_size(ctrl) - (wr_prod(ctrl) - wr_cons(ctrl)); +} + +int libvchan_buffer_space(struct libvchan *ctrl) +{ + /* Since this value is being used outside libvchan, request notification + * when it changes + */ + request_notify(ctrl, VCHAN_NOTIFY_READ); + return wr_ring_size(ctrl) - (wr_prod(ctrl) - wr_cons(ctrl)); +} + +int libvchan_wait(struct libvchan *ctrl) +{ + int ret = xc_evtchn_pending(ctrl->event); + if (ret < 0) + return -1; + xc_evtchn_unmask(ctrl->event, ret); + return 0; +} + +/** + * returns -1 on error, or size on success + */ +static int do_send(struct libvchan *ctrl, const void *data, size_t size) +{ + int real_idx = wr_prod(ctrl) & (wr_ring_size(ctrl) - 1); + int avail_contig = wr_ring_size(ctrl) - real_idx; + if (VCHAN_DEBUG) { + char metainfo[32]; + struct iovec iov[2]; + iov[0].iov_base = metainfo; + iov[0].iov_len = snprintf(metainfo, 32, "vchan wr %d/%d", ctrl->other_domain_id, ctrl->device_number); + iov[1].iov_base = (void *)data; + iov[1].iov_len = size; + writev(-1, iov, 2); + } + if (avail_contig > size) + avail_contig = size; + memcpy(wr_ring(ctrl) + real_idx, data, avail_contig); + if (avail_contig < size) + { + // we rolled across the end of the ring + memcpy(wr_ring(ctrl), data + avail_contig, size - avail_contig); + } + barrier(); // data must be in the ring prior to increment + wr_prod(ctrl) += size; + barrier(); // increment must happen prior to notify + if (send_notify(ctrl, VCHAN_NOTIFY_WRITE)) + return -1; + return size; +} + +/** + * returns 0 if no buffer space is available, -1 on error, or size on success + */ +int libvchan_send(struct libvchan *ctrl, const void *data, size_t size) +{ + int avail; + while (1) { + if (!libvchan_is_open(ctrl)) + return -1; + avail = fast_get_buffer_space(ctrl, size); + if (size <= avail) + return do_send(ctrl, data, size); + if (!ctrl->blocking) + return 0; + if (size > wr_ring_size(ctrl)) + return -1; + if (libvchan_wait(ctrl)) + return -1; + } +} + +int libvchan_write(struct libvchan *ctrl, const void *data, size_t size) +{ + int avail; + if (!libvchan_is_open(ctrl)) + return -1; + if (ctrl->blocking) { + size_t pos = 0; + while (1) { + avail = fast_get_buffer_space(ctrl, size - pos); + if (pos + avail > size) + avail = size - pos; + if (avail) + pos += do_send(ctrl, data + pos, avail); + if (pos == size) + return pos; + if (libvchan_wait(ctrl)) + return -1; + if (!libvchan_is_open(ctrl)) + return -1; + } + } else { + avail = fast_get_buffer_space(ctrl, size); + if (size > avail) + size = avail; + if (size == 0) + return 0; + return do_send(ctrl, data, size); + } +} + +static int do_recv(struct libvchan *ctrl, void *data, size_t size) +{ + int real_idx = rd_cons(ctrl) & (rd_ring_size(ctrl) - 1); + int avail_contig = rd_ring_size(ctrl) - real_idx; + if (avail_contig > size) + avail_contig = size; + barrier(); // data read must happen after rd_cons read + memcpy(data, rd_ring(ctrl) + real_idx, avail_contig); + if (avail_contig < size) + { + // we rolled across the end of the ring + memcpy(data + avail_contig, rd_ring(ctrl), size - avail_contig); + } + rd_cons(ctrl) += size; + if (VCHAN_DEBUG) { + char metainfo[32]; + struct iovec iov[2]; + iov[0].iov_base = metainfo; + iov[0].iov_len = snprintf(metainfo, 32, "vchan rd %d/%d", ctrl->other_domain_id, ctrl->device_number); + iov[1].iov_base = data; + iov[1].iov_len = size; + writev(-1, iov, 2); + } + barrier(); // consumption must happen prior to notify of newly freed space + if (send_notify(ctrl, VCHAN_NOTIFY_READ)) + return -1; + return size; +} + +/** + * reads exactly size bytes from the vchan. + * returns 0 if insufficient data is available, -1 on error, or size on success + */ +int libvchan_recv(struct libvchan *ctrl, void *data, size_t size) +{ + while (1) { + int avail = fast_get_data_ready(ctrl, size); + if (size <= avail) + return do_recv(ctrl, data, size); + if (!libvchan_is_open(ctrl)) + return -1; + if (!ctrl->blocking) + return 0; + if (size > rd_ring_size(ctrl)) + return -1; + if (libvchan_wait(ctrl)) + return -1; + } +} + +int libvchan_read(struct libvchan *ctrl, void *data, size_t size) +{ + while (1) { + int avail = fast_get_data_ready(ctrl, size); + if (avail && size > avail) + size = avail; + if (avail) + return do_recv(ctrl, data, size); + if (!libvchan_is_open(ctrl)) + return -1; + if (!ctrl->blocking) + return 0; + if (libvchan_wait(ctrl)) + return -1; + } +} + +int libvchan_is_open(struct libvchan* ctrl) +{ + if (ctrl->is_server) + return ctrl->server_persist ? 1 : ctrl->ring->cli_live; + else + return ctrl->ring->srv_live; +} + +int libvchan_fd_for_select(struct libvchan *ctrl) +{ + return xc_evtchn_fd(ctrl->event); +} + +void libvchan_close(struct libvchan *ctrl) +{ + if (!ctrl) + return; + if (ctrl->read.order >= PAGE_SHIFT) + munmap(ctrl->read.buffer, 1 << ctrl->read.order); + if (ctrl->write.order >= PAGE_SHIFT) + munmap(ctrl->write.buffer, 1 << ctrl->write.order); + if (ctrl->ring) { + if (ctrl->is_server) { + ctrl->ring->srv_live = 0; + xc_gntshr_munmap(ctrl->gntshr, ctrl->ring, PAGE_SIZE); + } else { + ctrl->ring->cli_live = 0; + xc_gnttab_munmap(ctrl->gnttab, ctrl->ring, PAGE_SIZE); + } + } + if (ctrl->event) { + if (ctrl->event_port >= 0 && ctrl->ring) + xc_evtchn_notify(ctrl->event, ctrl->event_port); + xc_evtchn_close(ctrl->event); + } + if (ctrl->is_server) { + if (ctrl->gntshr) + xc_gntshr_close(ctrl->gntshr); + } else { + if (ctrl->gnttab) + xc_gnttab_close(ctrl->gnttab); + } + free(ctrl); +} diff --git a/tools/libvchan/libxenvchan.h b/tools/libvchan/libxenvchan.h new file mode 100644 index 0000000..c4a3ab9 --- /dev/null +++ b/tools/libvchan/libxenvchan.h @@ -0,0 +1,173 @@ +/** + * @file + * @section AUTHORS + * + * Copyright (C) 2010 Rafal Wojtczuk <rafal@invisiblethingslab.com> + * + * Authors: + * Rafal Wojtczuk <rafal@invisiblethingslab.com> + * Daniel De Graaf <dgdegra@tycho.nsa.gov> + * + * @section LICENSE + * + * This library is free software; you can redistribute it and/or + * modify it under the terms of the GNU Lesser General Public + * License as published by the Free Software Foundation; either + * version 2 of the License, or (at your option) any later version. + * + * This library is distributed in the hope that it will be useful, + * but WITHOUT ANY WARRANTY; without even the implied warranty of + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU + * Lesser General Public License for more details. + * + * You should have received a copy of the GNU Lesser General Public + * License along with this library; if not, write to the Free Software + * Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston, MA 02110-1301 USA + * + * @section DESCRIPTION + * + * Originally borrowed from the Qubes OS Project, http://www.qubes-os.org, + * this code has been substantially rewritten to use the gntdev and gntalloc + * devices instead of raw MFNs and map_foreign_range. + * + * This is a library for inter-domain communication. A standard Xen ring + * buffer is used, with a datagram-based interface built on top. The grant + * reference and event channels are shared in XenStore under the path + * /local/domain/<srv-id>/data/vchan/<cli-id>/<port>/{ring-ref,event-channel} + * + * The ring.h macros define an asymmetric interface to a shared data structure + * that assumes all rings reside in a single contiguous memory space. This is + * not suitable for vchan because the interface to the ring is symmetric except + * for the setup. Unlike the producer-consumer rings defined in ring.h, the + * size of the rings used in vchan are determined at execution time instead of + * compile time, so the macros in ring.h cannot be used to access the rings. + */ + +#include <xen/io/libvchan.h> +#include <xen/sys/evtchn.h> +#include <xenctrl.h> + +struct libvchan_ring { + /* Pointer into the shared page. Offsets into buffer. */ + struct ring_shared* shr; + /* ring data; may be its own shared page(s) depending on order */ + void* buffer; + /** + * The size of the ring is (1 << order); offsets wrap around when they + * exceed this. This copy is required because we can't trust the order + * in the shared page to remain constant. + */ + int order; +}; + +/** + * struct libvchan: control structure passed to all library calls + */ +struct libvchan { + /* person we communicate with */ + int other_domain_id; + /* "port" we communicate on (allows multiple vchans to exist in xenstore) */ + int device_number; + /* Mapping handle for shared ring page */ + union { + xc_gntshr *gntshr; /* for server */ + xc_gnttab *gnttab; /* for client */ + }; + /* Pointer to shared ring page */ + struct vchan_interface *ring; + /* event channel interface */ + xc_evtchn *event; + uint32_t event_port; + /* informative flags: are we acting as server? */ + int is_server:1; + /* true if server remains active when client closes (allows reconnection) */ + int server_persist:1; + /* true if operations should block instead of returning 0 */ + int blocking:1; + /* communication rings */ + struct libvchan_ring read, write; +}; + +/** + * Set up a vchan, including granting pages + * @param logger Logger for libxc errors + * @param domain The peer domain that will be connecting + * @param devno A device number, used to identify this vchan in xenstore + * @param send_min The minimum size (in bytes) of the send ring (left) + * @param recv_min The minimum size (in bytes) of the receive ring (right) + * @return The structure, or NULL in case of an error + */ +struct libvchan *libvchan_server_init(xentoollog_logger *logger, int domain, int devno, size_t read_min, size_t write_min); +/** + * Connect to an existing vchan. Note: you can reconnect to an existing vchan + * safely, however no locking is performed, so you must prevent multiple clients + * from connecting to a single server. + * + * @param logger Logger for libxc errors + * @param domain The peer domain to connect to + * @param devno A device number, used to identify this vchan in xenstore + * @return The structure, or NULL in case of an error + */ +struct libvchan *libvchan_client_init(xentoollog_logger *logger, int domain, int devno); +/** + * Close a vchan. This deallocates the vchan and attempts to free its + * resources. The other side is notified of the close, but can still read any + * data pending prior to the close. + */ +void libvchan_close(struct libvchan *ctrl); + +/** + * Packet-based receive: always reads exactly $size bytes. + * @param ctrl The vchan control structure + * @param data Buffer for data that was read + * @param size Size of the buffer and amount of data to read + * @return -1 on error, 0 if nonblocking and insufficient data is available, or $size + */ +int libvchan_recv(struct libvchan *ctrl, void *data, size_t size); +/** + * Stream-based receive: reads as much data as possible. + * @param ctrl The vchan control structure + * @param data Buffer for data that was read + * @param size Size of the buffer + * @return -1 on error, otherwise the amount of data read (which may be zero if + * the vchan is nonblocking) + */ +int libvchan_read(struct libvchan *ctrl, void *data, size_t size); +/** + * Packet-based send: send entire buffer if possible + * @param ctrl The vchan control structure + * @param data Buffer for data to send + * @param size Size of the buffer and amount of data to send + * @return -1 on error, 0 if nonblocking and insufficient space is available, or $size + */ +int libvchan_send(struct libvchan *ctrl, const void *data, size_t size); +/** + * Stream-based send: send as much data as possible. + * @param ctrl The vchan control structure + * @param data Buffer for data to send + * @param size Size of the buffer + * @return -1 on error, otherwise the amount of data sent (which may be zero if + * the vchan is nonblocking) + */ +int libvchan_write(struct libvchan *ctrl, const void *data, size_t size); +/** + * Waits for reads or writes to unblock, or for a close + */ +int libvchan_wait(struct libvchan *ctrl); +/** + * Returns the event file descriptor for this vchan. When this FD is readable, + * libvchan_wait() will not block, and the state of the vchan has changed since + * the last invocation of libvchan_wait(). + */ +int libvchan_fd_for_select(struct libvchan *ctrl); +/** + * Query the state of the vchan shared page: + * return 0 when one side has called libvchan_close() or crashed + * return 1 when both sides are open + * return 2 [server only] when no client has yet connected + */ +int libvchan_is_open(struct libvchan* ctrl); +/** Amount of data ready to read, in bytes */ +int libvchan_data_ready(struct libvchan *ctrl); +/** Amount of data it is possible to send without blocking */ +int libvchan_buffer_space(struct libvchan *ctrl); diff --git a/tools/libvchan/node-select.c b/tools/libvchan/node-select.c new file mode 100644 index 0000000..ea1bfc6 --- /dev/null +++ b/tools/libvchan/node-select.c @@ -0,0 +1,162 @@ +/** + * @file + * @section AUTHORS + * + * Copyright (C) 2010 Rafal Wojtczuk <rafal@invisiblethingslab.com> + * + * Authors: + * Rafal Wojtczuk <rafal@invisiblethingslab.com> + * Daniel De Graaf <dgdegra@tycho.nsa.gov> + * + * @section LICENSE + * + * This program is free software; you can redistribute it and/or + * modify it under the terms of the GNU Lesser General Public + * License as published by the Free Software Foundation; either + * version 2 of the License, or (at your option) any later version. + * + * This program is distributed in the hope that it will be useful, + * but WITHOUT ANY WARRANTY; without even the implied warranty of + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU + * Lesser General Public License for more details. + * + * You should have received a copy of the GNU Lesser General Public + * License along with this program; if not, write to the Free Software + * Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston, MA 02110-1301 USA + * + * @section DESCRIPTION + * + * This is a test program for libvchan. Communications are bidirectional, + * with either server (grant offeror) or client able to read and write. + */ + +#include <stdlib.h> +#include <stdio.h> +#include <string.h> +#include <unistd.h> +#include <fcntl.h> +#include <errno.h> + +#include <libxenvchan.h> + +void usage(char** argv) +{ + fprintf(stderr, "usage:\n" + "\t%s [client|server] domainid nodeid [rbufsiz wbufsiz]\n", + argv[0]); + exit(1); +} + +#define BUFSIZE 5000 +char inbuf[BUFSIZE]; +char outbuf[BUFSIZE]; +int insiz = 0; +int outsiz = 0; +struct libvchan *ctrl = 0; + +void vchan_wr() { + if (!insiz) + return; + int ret = libvchan_write(ctrl, inbuf, insiz); + if (ret < 0) { + fprintf(stderr, "vchan write failed\n"); + exit(1); + } + if (ret > 0) { + insiz -= ret; + memmove(inbuf, inbuf + ret, insiz); + } +} + +void stdout_wr() { + if (!outsiz) + return; + int ret = write(1, outbuf, outsiz); + if (ret < 0 && errno != EAGAIN) + exit(1); + if (ret > 0) { + outsiz -= ret; + memmove(outbuf, outbuf + ret, outsiz); + } +} + +/** + Simple libvchan application, both client and server. + Both sides may write and read, both from the libvchan and from + stdin/stdout (just like netcat). +*/ + +int main(int argc, char **argv) +{ + int ret; + int libvchan_fd; + if (argc < 4) + usage(argv); + if (!strcmp(argv[1], "server")) { + int rsiz = argc > 4 ? atoi(argv[4]) : 0; + int wsiz = argc > 5 ? atoi(argv[5]) : 0; + ctrl = libvchan_server_init(NULL, atoi(argv[2]), atoi(argv[3]), rsiz, wsiz); + } else if (!strcmp(argv[1], "client")) + ctrl = libvchan_client_init(NULL, atoi(argv[2]), atoi(argv[3])); + else + usage(argv); + if (!ctrl) { + perror("libvchan_*_init"); + exit(1); + } + + fcntl(0, F_SETFL, O_NONBLOCK); + fcntl(1, F_SETFL, O_NONBLOCK); + + libvchan_fd = libvchan_fd_for_select(ctrl); + for (;;) { + fd_set rfds; + fd_set wfds; + FD_ZERO(&rfds); + FD_ZERO(&wfds); + if (insiz != BUFSIZE) + FD_SET(0, &rfds); + if (outsiz) + FD_SET(1, &wfds); + FD_SET(libvchan_fd, &rfds); + ret = select(libvchan_fd + 1, &rfds, &wfds, NULL, NULL); + if (ret < 0) { + perror("select"); + exit(1); + } + if (FD_ISSET(0, &rfds)) { + ret = read(0, inbuf + insiz, BUFSIZE - insiz); + if (ret < 0 && errno != EAGAIN) + exit(1); + if (ret == 0) { + while (insiz) { + vchan_wr(); + libvchan_wait(ctrl); + } + return 0; + } + if (ret) + insiz += ret; + vchan_wr(); + } + if (FD_ISSET(libvchan_fd, &rfds)) { + libvchan_wait(ctrl); + vchan_wr(); + } + if (FD_ISSET(1, &wfds)) + stdout_wr(); + while (libvchan_data_ready(ctrl) && outsiz < BUFSIZE) { + ret = libvchan_read(ctrl, outbuf + outsiz, BUFSIZE - outsiz); + if (ret < 0) + exit(1); + outsiz += ret; + stdout_wr(); + } + if (!libvchan_is_open(ctrl)) { + fcntl(1, F_SETFL, 0); + while (outsiz) + stdout_wr(); + return 0; + } + } +} diff --git a/tools/libvchan/node.c b/tools/libvchan/node.c new file mode 100644 index 0000000..6a9204c --- /dev/null +++ b/tools/libvchan/node.c @@ -0,0 +1,169 @@ +/** + * @file + * @section AUTHORS + * + * Copyright (C) 2010 Rafal Wojtczuk <rafal@invisiblethingslab.com> + * + * Authors: + * Rafal Wojtczuk <rafal@invisiblethingslab.com> + * Daniel De Graaf <dgdegra@tycho.nsa.gov> + * + * @section LICENSE + * + * This program is free software; you can redistribute it and/or + * modify it under the terms of the GNU Lesser General Public + * License as published by the Free Software Foundation; either + * version 2 of the License, or (at your option) any later version. + * + * This program is distributed in the hope that it will be useful, + * but WITHOUT ANY WARRANTY; without even the implied warranty of + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU + * Lesser General Public License for more details. + * + * You should have received a copy of the GNU Lesser General Public + * License along with this program; if not, write to the Free Software + * Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston, MA 02110-1301 USA + * + * @section DESCRIPTION + * + * This is a test program for libvchan. Communications are in one direction, + * either server (grant offeror) to client or vice versa. + */ + +#include <stdlib.h> +#include <stdio.h> +#include <string.h> +#include <unistd.h> +#include <time.h> + +#include <libxenvchan.h> + +int libvchan_write_all(struct libvchan *ctrl, char *buf, int size) +{ + int written = 0; + int ret; + while (written < size) { + ret = libvchan_write(ctrl, buf + written, size - written); + if (ret <= 0) { + perror("write"); + exit(1); + } + written += ret; + } + return size; +} + +int write_all(int fd, char *buf, int size) +{ + int written = 0; + int ret; + while (written < size) { + ret = write(fd, buf + written, size - written); + if (ret <= 0) { + perror("write"); + exit(1); + } + written += ret; + } + return size; +} + +void usage(char** argv) +{ + fprintf(stderr, "usage:\n" + "%s [client|server] [read|write] domid nodeid\n", argv[0]); + exit(1); +} + +#define BUFSIZE 5000 +char buf[BUFSIZE]; +void reader(struct libvchan *ctrl) +{ + int size; + for (;;) { + size = rand() % (BUFSIZE - 1) + 1; + size = libvchan_read(ctrl, buf, size); + fprintf(stderr, "#"); + if (size < 0) { + perror("read vchan"); + libvchan_close(ctrl); + exit(1); + } + size = write_all(1, buf, size); + if (size < 0) { + perror("stdout write"); + exit(1); + } + if (size == 0) { + perror("write size=0?\n"); + exit(1); + } + } +} + +void writer(struct libvchan *ctrl) +{ + int size; + for (;;) { + size = rand() % (BUFSIZE - 1) + 1; + size = read(0, buf, size); + if (size < 0) { + perror("read stdin"); + libvchan_close(ctrl); + exit(1); + } + if (size == 0) + break; + size = libvchan_write_all(ctrl, buf, size); + fprintf(stderr, "#"); + if (size < 0) { + perror("vchan write"); + exit(1); + } + if (size == 0) { + perror("write size=0?\n"); + exit(1); + } + } +} + + +/** + Simple libvchan application, both client and server. + One side does writing, the other side does reading; both from + standard input/output fds. +*/ +int main(int argc, char **argv) +{ + int seed = time(0); + struct libvchan *ctrl = 0; + int wr = 0; + if (argc < 4) + usage(argv); + if (!strcmp(argv[2], "read")) + wr = 0; + else if (!strcmp(argv[2], "write")) + wr = 1; + else + usage(argv); + if (!strcmp(argv[1], "server")) + ctrl = libvchan_server_init(NULL, atoi(argv[3]), atoi(argv[4]), 0, 0); + else if (!strcmp(argv[1], "client")) + ctrl = libvchan_client_init(NULL, atoi(argv[3]), atoi(argv[4])); + else + usage(argv); + if (!ctrl) { + perror("libvchan_*_init"); + exit(1); + } + ctrl->blocking = 1; + + srand(seed); + fprintf(stderr, "seed=%d\n", seed); + if (wr) + writer(ctrl); + else + reader(ctrl); + libvchan_close(ctrl); + return 0; +} diff --git a/xen/include/public/io/libvchan.h b/xen/include/public/io/libvchan.h new file mode 100644 index 0000000..a3bf7cd --- /dev/null +++ b/xen/include/public/io/libvchan.h @@ -0,0 +1,97 @@ +/** + * @file + * @section AUTHORS + * + * Copyright (C) 2010 Rafal Wojtczuk <rafal@invisiblethingslab.com> + * + * Authors: + * Rafal Wojtczuk <rafal@invisiblethingslab.com> + * Daniel De Graaf <dgdegra@tycho.nsa.gov> + * + * @section LICENSE + * + * This library is free software; you can redistribute it and/or + * modify it under the terms of the GNU Lesser General Public + * License as published by the Free Software Foundation; either + * version 2 of the License, or (at your option) any later version. + * + * This library is distributed in the hope that it will be useful, + * but WITHOUT ANY WARRANTY; without even the implied warranty of + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU + * Lesser General Public License for more details. + * + * You should have received a copy of the GNU Lesser General Public + * License along with this library; if not, write to the Free Software + * Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston, MA 02110-1301 USA + * + * @section DESCRIPTION + * + * Originally borrowed from the Qubes OS Project, http://www.qubes-os.org, + * this code has been substantially rewritten to use the gntdev and gntalloc + * devices instead of raw MFNs and map_foreign_range. + * + * This is a library for inter-domain communication. A standard Xen ring + * buffer is used, with a datagram-based interface built on top. The grant + * reference and event channels are shared in XenStore under the path + * /local/domain/<srv-id>/data/vchan/<cli-id>/<port>/{ring-ref,event-channel} + * + * The ring.h macros define an asymmetric interface to a shared data structure + * that assumes all rings reside in a single contiguous memory space. This is + * not suitable for vchan because the interface to the ring is symmetric except + * for the setup. Unlike the producer-consumer rings defined in ring.h, the + * size of the rings used in vchan are determined at execution time instead of + * compile time, so the macros in ring.h cannot be used to access the rings. + */ + +#include <stdint.h> +#include <sys/types.h> + +struct ring_shared { + uint32_t cons, prod; +}; + +#define VCHAN_NOTIFY_WRITE 0x1 +#define VCHAN_NOTIFY_READ 0x2 + +/** + * vchan_interface: primary shared data structure + */ +struct vchan_interface { + /** + * Standard consumer/producer interface, one pair per buffer + * left is client write, server read + * right is client read, server write + */ + struct ring_shared left, right; + /** + * size of the rings, which determines their location + * 10 - at offset 1024 in ring's page + * 11 - at offset 2048 in ring's page + * 12+ - uses 2^(N-12) grants to describe the multi-page ring + * These should remain constant once the page is shared. + * Only one of the two orders can be 10 (or 11). + */ + uint16_t left_order, right_order; + /** + * Shutdown detection: + * 0: client (or server) has exited + * 1: client (or server) is connected + * 2: client has not yet connected + */ + uint8_t cli_live, srv_live; + /** + * Notification bits: + * VCHAN_NOTIFY_WRITE: send notify when data is written + * VCHAN_NOTIFY_READ: send notify when data is read (consumed) + * cli_notify is used for the client to inform the server of its action + */ + uint8_t cli_notify, srv_notify; + /** + * Grant list: ordering is left, right. Must not extend into actual ring + * or grow beyond the end of the initial shared page. + * These should remain constant once the page is shared, to allow + * for possible remapping by a client that restarts. + */ + uint32_t grants[0]; +}; + -- 1.7.6.2 _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel From xen-devel-bounces@lists.xensource.com Mon Sep 19 17:37:00 2011 Return-path: <xen-devel-bounces@lists.xensource.com> Envelope-to: www-data@lists.xensource.com Delivery-date: Mon, 19 Sep 2011 17:37:00 -0700 Received: from localhost ([127.0.0.1] helo=lists.colo.xensource.com) by lists.xensource.com with esmtp (Exim 4.43) id 1R5oKa-0002D5-Gw; Mon, 19 Sep 2011 17:37:00 -0700 Received: from mail21.messagelabs.com ([85.158.143.35]) by lists.xensource.com with esmtp (Exim 4.43) id 1R5oJZ-00020d-9q for xen-devel@lists.xensource.com; Mon, 19 Sep 2011 17:36:00 -0700 X-Env-Sender: apxeng@gmail.com X-Msg-Ref: server-13.tower-21.messagelabs.com!1316478947!49552588!1 X-Originating-IP: [209.85.216.45] X-StarScan-Version: 6.4.1; banners=-,-,- X-VirusChecked: Checked Received: (qmail 1293 invoked from network); 20 Sep 2011 00:35:48 -0000 Received: from mail-qw0-f45.google.com (HELO mail-qw0-f45.google.com) (209.85.216.45) by server-13.tower-21.messagelabs.com with RC4-SHA encrypted SMTP; 20 Sep 2011 00:35:48 -0000 Received: by qwg2 with SMTP id 2so1637qwg.4 for <xen-devel@lists.xensource.com>; Mon, 19 Sep 2011 17:35:53 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; bh=Xp+7rzXFP3TWx3V3Q3tEKjjfMdIPXStN3zjavAQaZr4=; b=uj6qFovETtTMrulzmL2eg2+AF0f8Jaz4Mts9xt5pq6SvzqNBI5CSPG9rN6LX7BfgiP 0DYFVfdXU/isWrbr1Myqjl9p3qAic9btF0qGas1sAO2axfPLjSr7/2rBs81Lovfc8Unk fmzAwv3YkUSgfet/oMTbLr8deAkVUVkhOWcOs= MIME-Version: 1.0 Received: by 10.229.29.201 with SMTP id r9mr100747qcc.238.1316478952034; Mon, 19 Sep 2011 17:35:52 -0700 (PDT) Received: by 10.229.21.1 with HTTP; Mon, 19 Sep 2011 17:35:51 -0700 (PDT) In-Reply-To: <20110917134221.GZ12984@reaktio.net> References: <CAGU+autjPnjevraC5vhX4RAMC2XrqkfKUN_ZuJz1r0r3078=0Q@mail.gmail.com> <20110917134221.GZ12984@reaktio.net> Date: Mon, 19 Sep 2011 17:35:51 -0700 Message-ID: <CAGU+auuQ8GUbQqesGEBaCpKve2s3sDdxgjO-uVEwNjLPsGfJkQ@mail.gmail.com> Subject: Re: [Xen-devel] Testing nested virtualization on Intel CPUs From: AP <apxeng@gmail.com> To: =?ISO-8859-1?Q?Pasi_K=E4rkk=E4inen?= <pasik@iki.fi> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: xen-devel@lists.xensource.com X-BeenThere: xen-devel@lists.xensource.com X-Mailman-Version: 2.1.5 Precedence: list List-Id: Xen developer discussion <xen-devel.lists.xensource.com> List-Unsubscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe> List-Post: <mailto:xen-devel@lists.xensource.com> List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help> List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=subscribe> Sender: xen-devel-bounces@lists.xensource.com Errors-To: xen-devel-bounces@lists.xensource.com On Sat, Sep 17, 2011 at 6:42 AM, Pasi K=E4rkk=E4inen <pasik@iki.fi> wrote: > On Fri, Sep 16, 2011 at 06:16:20PM -0700, AP wrote: >> I am testing out nested virtualization on a Lenovo x220 (Intel >> i7-2620M). I am running xen-unstable (23842:483c5f8319ad) and Linux >> 3.0 (Ubuntu 10.10). >> I brought up a Centos 5.6 VM and installed Xen that is packaged with >> it. I think it is a variant of 3.0. >> > > Xen hypervisor in RHEL5 / CentOS5 is heavily patched Xen 3.1.2+. > (the userland tools are 3.0.3-based though). > > >> The CentOS Xen VM boots very >> slowly but it does finally come up in to the nested Dom0. Now when I >> do an "xm create" of an HVM domain I just get a blank sdl screen. I >> don't even see the bios screen. Are there any more patches that I need >> to be adding to get this to work? >> > > Hmm.. I remember AMD guys mentioning nested virt Xen-on-Xen and KVM-on-Xe= n works OK in xen-unstable. > Not sure about the status of Intel nested virt currently. > > You could also try using Xen 4.x in the CentOS VM, just to see if that ma= kes a difference. > rpms in http://gitco.de/repo/ With Xen-4.1.0 from gitco the inner Dom0 kernel doesn't come up fully. So I changed tracks and tried running KVM within the guest and installing an inner guest with KVM as the hypervisor. That seemingly worked! I passed -enable-kvm to qemu-kvm. Is there anyway of confirming this from the outer host Xen? AP > -- Pasi > > >> I have also included some log output. Please let me know if you need >> any other info. >> >> Thanks, >> AP >> >> Config of nested hypervisor VM >> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D >> kernel =3D "hvmloader" >> builder=3D'hvm' >> memory =3D 1024 >> name =3D 'centos' >> vcpus =3D 1 >> pae =3D 1 >> acpi =3D 1 >> apic =3D 1 >> vif =3D [ 'bridge=3Dbr0' ] >> disk =3D ['phy:/dev/vollumvg/centos,hda,w', 'phy:/dev/vollumvg/centosfi,= hdb,w'] >> device_model =3D 'qemu-dm' >> vnc =3D 0 >> sdl =3D 1 >> stdvga =3D 1 >> serial =3D 'pty' >> monitor=3D1 >> usb=3D1 >> videoram =3D 16 >> nestedhvm =3D 1 >> >> Host Xen messages during nested hypervisor Xen VM boot >> ------------------------------------------------------------------------= --------------- >> (XEN) HVM2: HVM Loader >> (XEN) HVM2: Detected Xen v4.2-unstable >> (XEN) HVM2: Xenbus rings @0xfeffc000, event channel 2 >> (XEN) HVM2: System requested ROMBIOS >> (XEN) HVM2: CPU speed is 2691 MHz >> (XEN) irq.c:269: Dom2 PCI link 0 changed 0 -> 5 >> (XEN) HVM2: PCI-ISA link 0 routed to IRQ5 >> (XEN) irq.c:269: Dom2 PCI link 1 changed 0 -> 10 >> (XEN) HVM2: PCI-ISA link 1 routed to IRQ10 >> (XEN) irq.c:269: Dom2 PCI link 2 changed 0 -> 11 >> (XEN) HVM2: PCI-ISA link 2 routed to IRQ11 >> (XEN) irq.c:269: Dom2 PCI link 3 changed 0 -> 5 >> (XEN) HVM2: PCI-ISA link 3 routed to IRQ5 >> (XEN) HVM2: pci dev 01:2 INTD->IRQ5 >> (XEN) HVM2: pci dev 01:3 INTA->IRQ10 >> (XEN) HVM2: pci dev 03:0 INTA->IRQ5 >> (XEN) HVM2: pci dev 04:0 INTA->IRQ5 >> (XEN) HVM2: pci dev 02:0 bar 10 size 01000000: f0000008 >> (XEN) HVM2: pci dev 03:0 bar 14 size 01000000: f1000008 >> (XEN) HVM2: pci dev 03:0 bar 10 size 00000100: 0000c001 >> (XEN) HVM2: pci dev 04:0 bar 10 size 00000100: 0000c101 >> (XEN) HVM2: pci dev 04:0 bar 14 size 00000100: f2000000 >> (XEN) HVM2: pci dev 01:2 bar 20 size 00000020: 0000c201 >> (XEN) HVM2: pci dev 01:1 bar 20 size 00000010: 0000c221 >> (XEN) HVM2: Multiprocessor initialisation: >> (XEN) HVM2: =A0- CPU0 ... 36-bit phys ... fixed MTRRs ... var MTRRs >> [2/8] ... done. >> (XEN) HVM2: Testing HVM environment: >> (XEN) HVM2: =A0- REP INSB across page boundaries ... passed >> (XEN) HVM2: =A0- GS base MSRs and SWAPGS ... passed >> (XEN) HVM2: Passed 2 of 2 tests >> (XEN) HVM2: Writing SMBIOS tables ... >> (XEN) HVM2: Loading ROMBIOS ... >> (XEN) HVM2: 9724 bytes of ROMBIOS high-memory extensions: >> (XEN) HVM2: =A0 Relocating to 0xfc000000-0xfc0025fc ... done >> (XEN) HVM2: Creating MP tables ... >> (XEN) HVM2: Loading Standard VGABIOS ... >> (XEN) HVM2: Loading PCI Option ROM ... >> (XEN) HVM2: =A0- Manufacturer: http://etherboot.org >> (XEN) HVM2: =A0- Product name: gPXE >> (XEN) HVM2: Loading ACPI ... >> (XEN) HVM2: vm86 TSS at fc012800 >> (XEN) HVM2: BIOS map: >> (XEN) HVM2: =A0c0000-c9fff: VGA BIOS >> (XEN) HVM2: =A0ca000-d7fff: Etherboot ROM >> (XEN) HVM2: =A0f0000-fffff: Main BIOS >> (XEN) HVM2: E820 table: >> (XEN) HVM2: =A0[00]: 00000000:00000000 - 00000000:0009e000: RAM >> (XEN) HVM2: =A0[01]: 00000000:0009e000 - 00000000:000a0000: RESERVED >> (XEN) HVM2: =A0HOLE: 00000000:000a0000 - 00000000:000e0000 >> (XEN) HVM2: =A0[02]: 00000000:000e0000 - 00000000:00100000: RESERVED >> (XEN) HVM2: =A0[03]: 00000000:00100000 - 00000000:3f000000: RAM >> (XEN) HVM2: =A0HOLE: 00000000:3f000000 - 00000000:fc000000 >> (XEN) HVM2: =A0[04]: 00000000:fc000000 - 00000001:00000000: RESERVED >> (XEN) HVM2: Invoking ROMBIOS ... >> (XEN) HVM2: $Revision: 1.221 $ $Date: 2008/12/07 17:32:29 $ >> (XEN) stdvga.c:147:d2 entering stdvga and caching modes >> (XEN) HVM2: VGABios $Id: vgabios.c,v 1.67 2008/01/27 09:44:12 vruppert E= xp $ >> (XEN) HVM2: VBE Bios $Id: vbe.c,v 1.60 2008/03/02 07:47:21 vruppert Exp = $ >> (XEN) HVM2: Bochs BIOS - build: 06/23/99 >> (XEN) HVM2: $Revision: 1.221 $ $Date: 2008/12/07 17:32:29 $ >> (XEN) HVM2: Options: apmbios pcibios eltorito PMM >> (XEN) HVM2: >> (XEN) HVM2: ata0-0: PCHS=3D16383/16/63 translation=3Dlba LCHS=3D1024/255= /63 >> (XEN) HVM2: ata0 master: QEMU HARDDISK ATA-7 Hard-Disk (10240 MBytes) >> (XEN) HVM2: ata0-1: PCHS=3D10402/16/63 translation=3Dlba LCHS=3D652/255/= 63 >> (XEN) HVM2: ata0 =A0slave: QEMU HARDDISK ATA-7 Hard-Disk (5120 MBytes) >> (XEN) HVM2: >> (XEN) HVM2: >> (XEN) HVM2: >> (XEN) HVM2: Press F12 for boot menu. >> (XEN) HVM2: >> (XEN) HVM2: Booting from Hard Disk... >> (XEN) HVM2: Booting from 0000:7c00 >> (XEN) HVM2: int13_harddisk: function 41, unmapped device for ELDL=3D82 >> (XEN) HVM2: int13_harddisk: function 08, unmapped device for ELDL=3D82 >> (XEN) HVM2: *** int 15h function AX=3D00c0, BX=3D0000 not yet supported! >> (XEN) HVM2: int13_harddisk: function 02, unmapped device for ELDL=3D82 >> (XEN) HVM2: int13_harddisk: function 41, unmapped device for ELDL=3D82 >> (XEN) irq.c:269: Dom2 PCI link 0 changed 5 -> 0 >> (XEN) irq.c:269: Dom2 PCI link 1 changed 10 -> 0 >> (XEN) irq.c:269: Dom2 PCI link 2 changed 11 -> 0 >> (XEN) irq.c:269: Dom2 PCI link 3 changed 5 -> 0 >> >> >> Nested Xen Messages during nested VM boot >> ------------------------------------------------------------------- >> (XEN) sysctl.c:51: Allowing physinfo call with newer ABI version >> (XEN) sysctl.c:51: Allowing physinfo call with newer ABI version >> (XEN) sysctl.c:51: Allowing physinfo call with newer ABI version >> (XEN) sysctl.c:51: Allowing physinfo call with newer ABI version >> (XEN) sysctl.c:51: Allowing physinfo call with newer ABI version >> (XEN) sysctl.c:51: Allowing physinfo call with newer ABI version >> (XEN) memory.c:124:d0 Could not allocate order=3D9 extent: id=3D1 >> memflags=3D0 (0 of 1) >> (XEN) memory.c:124:d0 Could not allocate order=3D9 extent: id=3D1 >> memflags=3D0 (0 of 1) >> (XEN) memory.c:124:d0 Could not allocate order=3D9 extent: id=3D1 >> memflags=3D0 (0 of 1) >> (XEN) memory.c:124:d0 Could not allocate order=3D9 extent: id=3D1 >> memflags=3D0 (0 of 1) >> >> _______________________________________________ >> Xen-devel mailing list >> Xen-devel@lists.xensource.com >> http://lists.xensource.com/xen-devel > _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel From xen-devel-bounces@lists.xensource.com Mon Sep 19 18:39:57 2011 Return-path: <xen-devel-bounces@lists.xensource.com> Envelope-to: www-data@lists.xensource.com Delivery-date: Mon, 19 Sep 2011 18:39:57 -0700 Received: from localhost ([127.0.0.1] helo=lists.colo.xensource.com) by lists.xensource.com with esmtp (Exim 4.43) id 1R5pJU-0003mH-Ft; Mon, 19 Sep 2011 18:39:56 -0700 Received: from mail182.messagelabs.com ([85.158.139.83]) by lists.xensource.com with esmtp (Exim 4.43) id 1R5pIY-0003ZF-Vy for xen-devel@lists.xensource.com; Mon, 19 Sep 2011 18:38:59 -0700 X-Env-Sender: Ian.Jackson@eu.citrix.com X-Msg-Ref: server-2.tower-182.messagelabs.com!1316482735!17979707!1 X-Originating-IP: [62.200.22.115] X-StarScan-Version: 6.4.1; banners=-,-,- X-VirusChecked: Checked Received: (qmail 30171 invoked from network); 20 Sep 2011 01:38:55 -0000 Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115) by server-2.tower-182.messagelabs.com with RC4-SHA encrypted SMTP; 20 Sep 2011 01:38:55 -0000 X-IronPort-AV: E=Sophos;i="4.68,408,1312156800"; d="scan'208";a="7938788" Received: from lonpmailmx01.citrite.net ([10.30.203.162]) by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5; 20 Sep 2011 01:38:55 +0000 Received: from woking.xci-test.com (10.80.248.135) by smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id 8.3.137.0; Tue, 20 Sep 2011 02:38:55 +0100 Received: from osstest by woking.xci-test.com with local (Exim 4.69) (envelope-from <ian.jackson@eu.citrix.com>) id 1R5pIV-0007Ij-8K; Tue, 20 Sep 2011 02:38:55 +0100 To: xen-devel@lists.xensource.com Message-ID: <osstest-8975-mainreport@xen.org> From: xen.org <ian.jackson@eu.citrix.com> Date: Tue, 20 Sep 2011 02:38:55 +0100 MIME-Version: 1.0 Content-Type: text/plain Cc: ian.jackson@eu.citrix.com Subject: [Xen-devel] [xen-unstable test] 8975: tolerable FAIL X-BeenThere: xen-devel@lists.xensource.com X-Mailman-Version: 2.1.5 Precedence: list List-Id: Xen developer discussion <xen-devel.lists.xensource.com> List-Unsubscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe> List-Post: <mailto:xen-devel@lists.xensource.com> List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help> List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=subscribe> Sender: xen-devel-bounces@lists.xensource.com Errors-To: xen-devel-bounces@lists.xensource.com flight 8975 xen-unstable real [real] http://www.chiark.greenend.org.uk/~xensrcts/logs/8975/ Failures :-/ but no regressions. Tests which did not succeed, but are not blocking, including regressions (tests previously passed) regarded as allowable: test-amd64-amd64-xl-pcipt-intel 1 xen-build-check(1) blocked n/a test-amd64-amd64-xl 1 xen-build-check(1) blocked n/a test-amd64-i386-pair 1 xen-build-check(1) blocked n/a test-amd64-i386-xl-multivcpu 1 xen-build-check(1) blocked n/a test-amd64-i386-rhel6hvm-intel 1 xen-build-check(1) blocked n/a test-i386-i386-pv 1 xen-build-check(1) blocked n/a build-i386-pvops 4 kernel-build fail like 8960 test-amd64-i386-pv 1 xen-build-check(1) blocked n/a test-amd64-amd64-pv 1 xen-build-check(1) blocked n/a test-i386-i386-xl 1 xen-build-check(1) blocked n/a build-amd64-pvops 4 kernel-build fail like 8960 test-amd64-i386-xl 1 xen-build-check(1) blocked n/a test-amd64-i386-xl-credit2 1 xen-build-check(1) blocked n/a test-amd64-i386-rhel6hvm-amd 1 xen-build-check(1) blocked n/a test-amd64-amd64-pair 1 xen-build-check(1) blocked n/a test-i386-i386-pair 1 xen-build-check(1) blocked n/a test-amd64-amd64-win 1 xen-build-check(1) blocked n/a test-amd64-amd64-xl-win 1 xen-build-check(1) blocked n/a test-amd64-i386-win 1 xen-build-check(1) blocked n/a test-i386-i386-win 1 xen-build-check(1) blocked n/a test-amd64-amd64-xl-sedf 1 xen-build-check(1) blocked n/a test-amd64-i386-win-vcpus1 1 xen-build-check(1) blocked n/a test-amd64-i386-xl-win-vcpus1 1 xen-build-check(1) blocked n/a test-i386-i386-xl-win 1 xen-build-check(1) blocked n/a version targeted for testing: xen 994b5b125c31 baseline version: xen 994b5b125c31 jobs: build-amd64 pass build-i386 pass build-amd64-oldkern pass build-i386-oldkern pass build-amd64-pvops fail build-i386-pvops fail test-amd64-amd64-xl blocked test-amd64-i386-xl blocked test-i386-i386-xl blocked test-amd64-i386-rhel6hvm-amd blocked test-amd64-i386-xl-credit2 blocked test-amd64-amd64-xl-pcipt-intel blocked test-amd64-i386-rhel6hvm-intel blocked test-amd64-i386-xl-multivcpu blocked test-amd64-amd64-pair blocked test-amd64-i386-pair blocked test-i386-i386-pair blocked test-amd64-amd64-pv blocked test-amd64-i386-pv blocked test-i386-i386-pv blocked test-amd64-amd64-xl-sedf blocked test-amd64-i386-win-vcpus1 blocked test-amd64-i386-xl-win-vcpus1 blocked test-amd64-amd64-win blocked test-amd64-i386-win blocked test-i386-i386-win blocked test-amd64-amd64-xl-win blocked test-i386-i386-xl-win blocked ------------------------------------------------------------ sg-report-flight on woking.cam.xci-test.com logs: /home/xc_osstest/logs images: /home/xc_osstest/images Logs, config files, etc. are available at http://www.chiark.greenend.org.uk/~xensrcts/logs Test harness code can be found at http://xenbits.xensource.com/gitweb?p=osstest.git;a=summary Published tested tree is already up to date. _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel From xen-devel-bounces@lists.xensource.com Mon Sep 19 21:34:47 2011 Return-path: <xen-devel-bounces@lists.xensource.com> Envelope-to: www-data@lists.xensource.com Delivery-date: Mon, 19 Sep 2011 21:34:47 -0700 Received: from localhost ([127.0.0.1] helo=lists.colo.xensource.com) by lists.xensource.com with esmtp (Exim 4.43) id 1R5s2f-0007KT-JY; Mon, 19 Sep 2011 21:34:45 -0700 Received: from mail21.messagelabs.com ([85.158.143.35]) by lists.xensource.com with esmtp (Exim 4.43) id 1R5s1l-00077h-43 for xen-devel@lists.xensource.com; Mon, 19 Sep 2011 21:33:49 -0700 X-Env-Sender: mailinglists@unix-scripts.com X-Msg-Ref: server-7.tower-21.messagelabs.com!1316493194!55490491!1 X-Originating-IP: [208.82.118.137] X-StarScan-Version: 6.4.1; banners=-,-,- X-VirusChecked: Checked Received: (qmail 18203 invoked from network); 20 Sep 2011 04:33:15 -0000 Received: from server1.unix-scripts.com (HELO server1.unix-scripts.com) (208.82.118.137) by server-7.tower-21.messagelabs.com with DHE-RSA-AES256-SHA encrypted SMTP; 20 Sep 2011 04:33:15 -0000 Received: from staff.ndchost.com ([204.10.36.76] helo=[10.100.100.6]) by server1.unix-scripts.com with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.69) (envelope-from <mailinglists@unix-scripts.com>) id 1R5s1c-0001UQ-WF; Mon, 19 Sep 2011 21:33:41 -0700 Message-ID: <4E7817A4.6070908@unix-scripts.com> Date: Mon, 19 Sep 2011 21:33:40 -0700 From: Shaun Reitan <mailinglists@unix-scripts.com> Organization: Network Data Center Host, Inc. User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.2.22) Gecko/20110902 Thunderbird/3.1.14 MIME-Version: 1.0 Newsgroups: gmane.comp.emulators.xen.devel To: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com> References: <j4thp9$j7d$1@dough.gmane.org> <j4tl2j$cm2$1@dough.gmane.org> <20110916082456.GA884@phenom.oracle.com> In-Reply-To: <20110916082456.GA884@phenom.oracle.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - server1.unix-scripts.com X-AntiAbuse: Original Domain - lists.xensource.com X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - unix-scripts.com Cc: xen-devel@lists.xensource.com Subject: [Xen-devel] Re: kernel BUG at mm/swapfile.c:2527! X-BeenThere: xen-devel@lists.xensource.com X-Mailman-Version: 2.1.5 Precedence: list List-Id: Xen developer discussion <xen-devel.lists.xensource.com> List-Unsubscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe> List-Post: <mailto:xen-devel@lists.xensource.com> List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help> List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=subscribe> Sender: xen-devel-bounces@lists.xensource.com Errors-To: xen-devel-bounces@lists.xensource.com On 9/16/2011 1:24 AM, Konrad Rzeszutek Wilk wrote: > How do I reproduce it? Is the PCI compliance easily available? Is > there any chance we can get access to the physical box to figure > out what is happening? Konrad, did you get my email with the server I setup for you and logins? -- Shaun _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel From xen-devel-bounces@lists.xensource.com Mon Sep 19 22:22:17 2011 Return-path: <xen-devel-bounces@lists.xensource.com> Envelope-to: www-data@lists.xensource.com Delivery-date: Mon, 19 Sep 2011 22:22:17 -0700 Received: from localhost ([127.0.0.1] helo=lists.colo.xensource.com) by lists.xensource.com with esmtp (Exim 4.43) id 1R5smf-00012n-Gm; Mon, 19 Sep 2011 22:22:17 -0700 Received: from mail216.messagelabs.com ([85.158.143.99]) by lists.xensource.com with esmtp (Exim 4.43) id 1R5sly-0000po-0y for xen-devel@lists.xensource.com; Mon, 19 Sep 2011 22:21:34 -0700 X-Env-Sender: evil.dani@gmail.com X-Msg-Ref: server-15.tower-216.messagelabs.com!1316496090!18403370!1 X-Originating-IP: [209.85.161.43] X-StarScan-Version: 6.4.1; banners=-,-,- X-VirusChecked: Checked Received: (qmail 9052 invoked from network); 20 Sep 2011 05:21:30 -0000 Received: from mail-fx0-f43.google.com (HELO mail-fx0-f43.google.com) (209.85.161.43) by server-15.tower-216.messagelabs.com with RC4-SHA encrypted SMTP; 20 Sep 2011 05:21:30 -0000 Received: by fxh19 with SMTP id 19so199229fxh.30 for <xen-devel@lists.xensource.com>; Mon, 19 Sep 2011 22:21:30 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:date:message-id:subject:from:to:content-type :content-transfer-encoding; bh=W2xxREJ9bedhXIAJSlvtt3gLsUixp0AXrIRL/f64ZPY=; b=KTW886J/y/yQnjPfOlDAj+jeKEBLKYue0VW3nd20eJklES9QmEqDItlmxYvx2A1hA4 jZCyTs0U2coayk3tyhMAHGL1hkNJfnxiwVsGNTITL7XGpTUIMvReAm8CyE7NZx/wHVKW UqFFc/RkJLVZkwgpA1P5GPVnA0DdpduBulGU8= MIME-Version: 1.0 Received: by 10.223.75.24 with SMTP id w24mr616249faj.132.1316496090452; Mon, 19 Sep 2011 22:21:30 -0700 (PDT) Received: by 10.223.97.9 with HTTP; Mon, 19 Sep 2011 22:21:30 -0700 (PDT) Date: Tue, 20 Sep 2011 14:21:30 +0900 Message-ID: <CAP2B85_rPbB=hZpKJYSPgC59jU=YG6deD4ZkWMmXwtMV4un1mg@mail.gmail.com> From: Daniel Castro <evil.dani@gmail.com> To: xen-devel@lists.xensource.com Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Subject: [Xen-devel] Sched_op hypercall small questions X-BeenThere: xen-devel@lists.xensource.com X-Mailman-Version: 2.1.5 Precedence: list List-Id: Xen developer discussion <xen-devel.lists.xensource.com> List-Unsubscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe> List-Post: <mailto:xen-devel@lists.xensource.com> List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help> List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=subscribe> Sender: xen-devel-bounces@lists.xensource.com Errors-To: xen-devel-bounces@lists.xensource.com Greetings all. Some small question regarding schedule poll operation hypercall. 1. struct sched_poll poll.timeout is measured in what unit of time? Secs, ms? ns? 2. After issuing the hypercall_sched_op(SCHEDOP_poll, &poll); if no timeout is used in poll struct how long will I yield the CPU? 3. If I issue the hypercall and the event never comes is it possible to to yield the CPU for ever? Thanks you very much for answering these questions. Daniel Castro --=20 +-=3D=3D=3D=3D=3D---------------------------+ | +---------------------------------+ | This space intentionally blank for notetaking. | |=A0=A0 | Daniel Castro,=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 | | |=A0=A0 | Consultant/Programmer.| | |=A0=A0 | U Andes=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0=A0 | +-------------------------------------+ _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel From xen-devel-bounces@lists.xensource.com Mon Sep 19 22:42:08 2011 Return-path: <xen-devel-bounces@lists.xensource.com> Envelope-to: www-data@lists.xensource.com Delivery-date: Mon, 19 Sep 2011 22:42:08 -0700 Received: from localhost ([127.0.0.1] helo=lists.colo.xensource.com) by lists.xensource.com with esmtp (Exim 4.43) id 1R5t5r-0001yV-KO; Mon, 19 Sep 2011 22:42:07 -0700 Received: from mail21.messagelabs.com ([85.158.143.35]) by lists.xensource.com with esmtp (Exim 4.43) id 1R5t50-0001lX-5s for xen-devel@lists.xensource.com; Mon, 19 Sep 2011 22:41:14 -0700 X-Env-Sender: keir.xen@gmail.com X-Msg-Ref: server-15.tower-21.messagelabs.com!1316497271!51222306!1 X-Originating-IP: [209.85.160.171] X-StarScan-Version: 6.4.1; banners=-,-,- X-VirusChecked: Checked Received: (qmail 31911 invoked from network); 20 Sep 2011 05:41:12 -0000 Received: from mail-gy0-f171.google.com (HELO mail-gy0-f171.google.com) (209.85.160.171) by server-15.tower-21.messagelabs.com with RC4-SHA encrypted SMTP; 20 Sep 2011 05:41:12 -0000 Received: by gyh3 with SMTP id 3so137588gyh.30 for <xen-devel@lists.xensource.com>; Mon, 19 Sep 2011 22:41:10 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=user-agent:date:subject:from:to:message-id:thread-topic :thread-index:in-reply-to:mime-version:content-type :content-transfer-encoding; bh=aDtmWCEIUgEyd1az5LKoO/pQEDXHHjuRz8p1VRDlf2Q=; b=qNFVFH/Ezrra2FtEmSz81YAgMlDiUg+A7oINxZzHEHGOmvWzx6Qsci4nCTqPNQT1Tj cQNanp+aMIBjIpp2fVW9FZQzA1A3VtGhO9h1ThC+A0y6mV+LBuk11M3UoEokjk57Ccwh gP10B+KgSvGdBeR4sz+99RLbvkUeJiM5zn2Os= Received: by 10.236.80.9 with SMTP id j9mr1686074yhe.94.1316497269942; Mon, 19 Sep 2011 22:41:09 -0700 (PDT) Received: from [10.255.255.36] ([96.49.135.17]) by mx.google.com with ESMTPS id f63sm637967yhj.14.2011.09.19.22.41.03 (version=SSLv3 cipher=OTHER); Mon, 19 Sep 2011 22:41:06 -0700 (PDT) User-Agent: Microsoft-Entourage/12.30.0.110427 Date: Mon, 19 Sep 2011 22:41:00 -0700 Subject: Re: [Xen-devel] Sched_op hypercall small questions From: Keir Fraser <keir.xen@gmail.com> To: Daniel Castro <evil.dani@gmail.com>, <xen-devel@lists.xensource.com> Message-ID: <CA9D757C.2119E%keir.xen@gmail.com> Thread-Topic: [Xen-devel] Sched_op hypercall small questions Thread-Index: Acx3V+CLOt4R8rpaJ0WFmmEk566YKA== In-Reply-To: <CAP2B85_rPbB=hZpKJYSPgC59jU=YG6deD4ZkWMmXwtMV4un1mg@mail.gmail.com> Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit Cc: X-BeenThere: xen-devel@lists.xensource.com X-Mailman-Version: 2.1.5 Precedence: list List-Id: Xen developer discussion <xen-devel.lists.xensource.com> List-Unsubscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe> List-Post: <mailto:xen-devel@lists.xensource.com> List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help> List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=subscribe> Sender: xen-devel-bounces@lists.xensource.com Errors-To: xen-devel-bounces@lists.xensource.com On 19/09/2011 22:21, "Daniel Castro" <evil.dani@gmail.com> wrote: > Greetings all. > > Some small question regarding schedule poll operation hypercall. > > 1. struct sched_poll poll.timeout is measured in what unit of time? > Secs, ms? ns? It is an absolute system time (rather than a duration), in nanoseconds. > 2. After issuing the hypercall_sched_op(SCHEDOP_poll, &poll); if no > timeout is used in poll struct how long will I yield the CPU? Until one of the specified event channel ports is pending. > 3. If I issue the hypercall and the event never comes is it possible > to to yield the CPU for ever? Yes, if you do not specify a timeout. -- Keir > Thanks you very much for answering these questions. > > Daniel Castro _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel From xen-devel-bounces@lists.xensource.com Mon Sep 19 23:18:22 2011 Return-path: <xen-devel-bounces@lists.xensource.com> Envelope-to: www-data@lists.xensource.com Delivery-date: Mon, 19 Sep 2011 23:18:22 -0700 Received: from localhost ([127.0.0.1] helo=lists.colo.xensource.com) by lists.xensource.com with esmtp (Exim 4.43) id 1R5tev-0002uK-HP; Mon, 19 Sep 2011 23:18:21 -0700 Received: from mail174.messagelabs.com ([85.158.138.51]) by lists.xensource.com with esmtp (Exim 4.43) id 1R5tdr-0002hc-Fm for xen-devel@lists.xensource.com; Mon, 19 Sep 2011 23:17:18 -0700 X-Env-Sender: evil.dani@gmail.com X-Msg-Ref: server-12.tower-174.messagelabs.com!1316499432!32042914!1 X-Originating-IP: [209.85.161.43] X-StarScan-Version: 6.4.1; banners=-,-,- X-VirusChecked: Checked Received: (qmail 8879 invoked from network); 20 Sep 2011 06:17:12 -0000 Received: from mail-fx0-f43.google.com (HELO mail-fx0-f43.google.com) (209.85.161.43) by server-12.tower-174.messagelabs.com with RC4-SHA encrypted SMTP; 20 Sep 2011 06:17:12 -0000 Received: by fxh19 with SMTP id 19so239265fxh.30 for <xen-devel@lists.xensource.com>; Mon, 19 Sep 2011 23:17:12 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; bh=VHmrbQzgOWe6DLH+QUFarNe/ZMLf1mkGONy5ex4RG6c=; b=TTCOPRBgM56trRTmS+GqKusEiFSJslLUz5ipv2mUrPHDazwM98FXnpl4EivSqHpced S3xdommD4LG5PFP4P3CXgd17dIoaXVbECrFScdkZI6RwtcsBnyOas8CGSyBaw55ojivE oRxcggg5Z0GShYAh8cFf718FeNjLnvmC/885I= MIME-Version: 1.0 Received: by 10.223.43.218 with SMTP id x26mr723425fae.75.1316499431406; Mon, 19 Sep 2011 23:17:11 -0700 (PDT) Received: by 10.223.97.9 with HTTP; Mon, 19 Sep 2011 23:17:11 -0700 (PDT) In-Reply-To: <CA9D757C.2119E%keir.xen@gmail.com> References: <CAP2B85_rPbB=hZpKJYSPgC59jU=YG6deD4ZkWMmXwtMV4un1mg@mail.gmail.com> <CA9D757C.2119E%keir.xen@gmail.com> Date: Tue, 20 Sep 2011 15:17:11 +0900 Message-ID: <CAP2B85-e64NKts_iC21Bh0OL3X3nUh4jLriYfE2+stHkPfMFWg@mail.gmail.com> Subject: Re: [Xen-devel] Sched_op hypercall small questions From: Daniel Castro <evil.dani@gmail.com> To: Keir Fraser <keir.xen@gmail.com> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: xen-devel@lists.xensource.com X-BeenThere: xen-devel@lists.xensource.com X-Mailman-Version: 2.1.5 Precedence: list List-Id: Xen developer discussion <xen-devel.lists.xensource.com> List-Unsubscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe> List-Post: <mailto:xen-devel@lists.xensource.com> List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help> List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=subscribe> Sender: xen-devel-bounces@lists.xensource.com Errors-To: xen-devel-bounces@lists.xensource.com On Tue, Sep 20, 2011 at 2:41 PM, Keir Fraser <keir.xen@gmail.com> wrote: > On 19/09/2011 22:21, "Daniel Castro" <evil.dani@gmail.com> wrote: > >> Greetings all. >> >> Some small question regarding schedule poll operation hypercall. >> >> 1. struct sched_poll poll.timeout is measured in what unit of time? >> Secs, ms? ns? > > It is an absolute system time (rather than a duration), in nanoseconds. really an absolute system time? When the timeout is set and the timeout is reached, the system behaves like if the event had been received? i.e the bit is changed? > >> 2. After issuing the hypercall_sched_op(SCHEDOP_poll, &poll); if no >> timeout is used in poll struct how long will I yield the CPU? > > Until one of the specified event channel ports is pending. If the channel port never changes (the event never arrives) then I would yield for ever? > >> 3. If I issue the hypercall and the event never comes is it possible >> to to yield the CPU for ever? > > Yes, if you do not specify a timeout. Keir thanks for the answer. I am trying to read from xenstore, so I have the following: I write on my xenstore ring the query I want, then, hypercall_event_channel_op(EVTCHNOP_send ... If I read the ring inmediatly the answer is not ready so I issue a hypercall_sched_op(SCHEDOP_poll, &poll); But while I am entering the yield state the answer comes, so the event is never seen because it has already been delivered. If I use some way to wait (just for very brief instant) after the event_channel_op send then, when I check the ring the answer is there; And I do not need to yield the CPU. Should I issue the wait after the send, rather than when I am about to read the answer? Thanks, Daniel > > =A0-- Keir > >> Thanks you very much for answering these questions. >> >> Daniel Castro > > > --=20 +-=3D=3D=3D=3D=3D---------------------------+ | +---------------------------------+ | This space intentionally blank for notetaking. | |=A0=A0 | Daniel Castro,=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 | | |=A0=A0 | Consultant/Programmer.| | |=A0=A0 | U Andes=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0=A0 | +-------------------------------------+ _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel From xen-devel-bounces@lists.xensource.com Tue Sep 20 00:34:30 2011 Return-path: <xen-devel-bounces@lists.xensource.com> Envelope-to: www-data@lists.xensource.com Delivery-date: Tue, 20 Sep 2011 00:34:30 -0700 Received: from localhost ([127.0.0.1] helo=lists.colo.xensource.com) by lists.xensource.com with esmtp (Exim 4.43) id 1R5uqb-0004f9-PB; Tue, 20 Sep 2011 00:34:29 -0700 Received: from mail174.messagelabs.com ([85.158.138.51]) by lists.xensource.com with esmtp (Exim 4.43) id 1R5upf-0004Sk-Qm for xen-devel@lists.xensource.com; Tue, 20 Sep 2011 00:33:32 -0700 X-Env-Sender: jbeulich@suse.com X-Msg-Ref: server-9.tower-174.messagelabs.com!1316504008!26025152!1 X-Originating-IP: [130.57.49.28] X-StarScan-Version: 6.4.1; banners=-,-,- X-VirusChecked: Checked Received: (qmail 16218 invoked from network); 20 Sep 2011 07:33:28 -0000 Received: from nat28.tlf.novell.com (HELO nat28.tlf.novell.com) (130.57.49.28) by server-9.tower-174.messagelabs.com with DHE-RSA-AES256-SHA encrypted SMTP; 20 Sep 2011 07:33:28 -0000 Received: from EMEA1-MTA by nat28.tlf.novell.com with Novell_GroupWise; Tue, 20 Sep 2011 08:34:22 +0100 Message-Id: <4E784FD502000078000769C5@nat28.tlf.novell.com> X-Mailer: Novell GroupWise Internet Agent 8.0.1 Date: Tue, 20 Sep 2011 08:33:24 +0100 From: "Jan Beulich" <jbeulich@suse.com> To: <evil.dani@gmail.com> Subject: Re: [Xen-devel] Sched_op hypercall small questions Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: quoted-printable Content-Disposition: inline Cc: keir.xen@gmail.com, xen-devel@lists.xensource.com X-BeenThere: xen-devel@lists.xensource.com X-Mailman-Version: 2.1.5 Precedence: list List-Id: Xen developer discussion <xen-devel.lists.xensource.com> List-Unsubscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe> List-Post: <mailto:xen-devel@lists.xensource.com> List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help> List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=subscribe> Sender: xen-devel-bounces@lists.xensource.com Errors-To: xen-devel-bounces@lists.xensource.com >>> Daniel Castro 09/20/11 8:18 AM >>> >On Tue, Sep 20, 2011 at 2:41 PM, Keir Fraser wrote: >> On 19/09/2011 22:21, "Daniel Castro" wrote: >> >>> Greetings all. >>> >>> Some small question regarding schedule poll operation hypercall. >>> >>> 1. struct sched_poll poll.timeout is measured in what unit of time? >>> Secs, ms? ns? >> >> It is an absolute system time (rather than a duration), in nanoseconds. > >really an absolute system time? > >When the timeout is set and the timeout is reached, the system behaves >like if the event had been received? i.e the bit is changed? No, the bit would remain unset - the poll times out then, it doesn't "complete". >>> 2. After issuing the hypercall_sched_op(SCHEDOP_poll, &poll); if no >>> timeout is used in poll struct how long will I yield the CPU? >> >> Until one of the specified event channel ports is pending. >If the channel port never changes (the event never arrives) then I >would yield for ever? Yes. >I am trying to read from xenstore, so I have the following: >I write on my xenstore ring the query I want, then, >hypercall_event_channel_op(EVTCHNOP_send ... >If I read the ring inmediatly the answer is not ready so I issue a That would suggest an ordering problem on either or both sides. >hypercall_sched_op(SCHEDOP_poll, &poll); >But while I am entering the yield state the answer comes, so the event >is never seen because it has already been delivered. > >If I use some way to wait (just for very brief instant) after the >event_channel_op send then, when I check the ring the answer is there; >And I do not need to yield the CPU. > >Should I issue the wait after the send, rather than when I am about to >read the answer? When you start the wait really shouldn't matter. But ordering needs to be in place so that the event only gets signaled when the consuming side can actually see what the producer put into the shared data structure. Since the signaling is done through a hypercall, there shouldn't really be anything the producer needs to do (unless your shared data is not in memory). Jan _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel From xen-devel-bounces@lists.xensource.com Tue Sep 20 01:32:32 2011 Return-path: <xen-devel-bounces@lists.xensource.com> Envelope-to: www-data@lists.xensource.com Delivery-date: Tue, 20 Sep 2011 01:32:32 -0700 Received: from localhost ([127.0.0.1] helo=lists.colo.xensource.com) by lists.xensource.com with esmtp (Exim 4.43) id 1R5vkm-00064B-2W; Tue, 20 Sep 2011 01:32:32 -0700 Received: from mail182.messagelabs.com ([85.158.139.83]) by lists.xensource.com with esmtp (Exim 4.43) id 1R5vjw-0005pl-BP for xen-devel@lists.xensource.com; Tue, 20 Sep 2011 01:31:40 -0700 X-Env-Sender: evil.dani@gmail.com X-Msg-Ref: server-15.tower-182.messagelabs.com!1316507497!18005038!1 X-Originating-IP: [209.85.161.43] X-StarScan-Version: 6.4.1; banners=-,-,- X-VirusChecked: Checked Received: (qmail 32186 invoked from network); 20 Sep 2011 08:31:37 -0000 Received: from mail-fx0-f43.google.com (HELO mail-fx0-f43.google.com) (209.85.161.43) by server-15.tower-182.messagelabs.com with RC4-SHA encrypted SMTP; 20 Sep 2011 08:31:37 -0000 Received: by fxh19 with SMTP id 19so390873fxh.30 for <xen-devel@lists.xensource.com>; Tue, 20 Sep 2011 01:31:37 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; bh=3f8T1BQX8s3jPWLay9aSO0IZMYRwFmkB9U4NpLrdQQA=; b=uCF0GgmYVmRSwTRzUoTfVpk5ZXJvNfrI+leT8WHkzfkYpIcVmNBTik+yGJnQIywYm9 R0LoFunJep7O0Fy2dUkVfbXMddeUbwan8YMV/md244spr+r1HRVKDoEf4d5lZ1h1Vf2C Wct+m/gzi+wQ6j+9vzcoe9vyUUuXS3fHDxzU8= MIME-Version: 1.0 Received: by 10.223.100.71 with SMTP id x7mr935871fan.18.1316507497025; Tue, 20 Sep 2011 01:31:37 -0700 (PDT) Received: by 10.223.97.9 with HTTP; Tue, 20 Sep 2011 01:31:36 -0700 (PDT) In-Reply-To: <4E784FD502000078000769C5@nat28.tlf.novell.com> References: <4E784FD502000078000769C5@nat28.tlf.novell.com> Date: Tue, 20 Sep 2011 17:31:36 +0900 Message-ID: <CAP2B85_YdLJDaNoaimuDOJhQJ_1ogtDWYhUbg-Ycxd0R0dmd8A@mail.gmail.com> Subject: Re: [Xen-devel] Sched_op hypercall small questions From: Daniel Castro <evil.dani@gmail.com> To: Jan Beulich <jbeulich@suse.com> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: keir.xen@gmail.com, xen-devel@lists.xensource.com X-BeenThere: xen-devel@lists.xensource.com X-Mailman-Version: 2.1.5 Precedence: list List-Id: Xen developer discussion <xen-devel.lists.xensource.com> List-Unsubscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe> List-Post: <mailto:xen-devel@lists.xensource.com> List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help> List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=subscribe> Sender: xen-devel-bounces@lists.xensource.com Errors-To: xen-devel-bounces@lists.xensource.com On Tue, Sep 20, 2011 at 4:33 PM, Jan Beulich <jbeulich@suse.com> wrote: >>>> Daniel Castro =A009/20/11 8:18 AM >>> >>On Tue, Sep 20, 2011 at 2:41 PM, Keir Fraser =A0wrote: >>> On 19/09/2011 22:21, "Daniel Castro" =A0wrote: >>> >>>> Greetings all. >>>> >>>> Some small question regarding schedule poll operation hypercall. >>>> >>>> 1. struct sched_poll poll.timeout is measured in what unit of time? >>>> Secs, ms? ns? >>> >>> It is an absolute system time (rather than a duration), in nanoseconds. >> >>really an absolute system time? >> >>When the timeout is set and the timeout is reached, the system behaves >>like if the event had been received? i.e the bit is changed? > > No, the bit would remain unset - the poll times out then, it doesn't > "complete". My Guest VM would get stuck on the hypercall call, like if it was an infinite loop? And once the timeout occurs or the event get delivered, then the hypercall would return, right? Thanks > >>>> 2. After issuing the hypercall_sched_op(SCHEDOP_poll, &poll); if no >>>> timeout is used in poll struct how long will I yield the CPU? >>> >>> Until one of the specified event channel ports is pending. >>If the channel port never changes (the event never arrives) then I >>would yield for ever? > > Yes. > >>I am trying to read from xenstore, so I have the following: >>I write on my xenstore ring the query I want, then, >>hypercall_event_channel_op(EVTCHNOP_send ... >>If I read the ring inmediatly the answer is not ready so I issue a > > That would suggest an ordering problem on either or both sides. > >>hypercall_sched_op(SCHEDOP_poll, &poll); >>But while I am entering the yield state the answer comes, so the event >>is never seen because it has already been delivered. >> >>If I use some way to wait (just for very brief instant) after the >>event_channel_op send then, when I check the ring the answer is there; >>And I do not need to yield the CPU. >> >>Should I issue the wait after the send, rather than when I am about to >>read the answer? > > When you start the wait really shouldn't matter. But ordering needs > to be in place so that the event only gets signaled when the consuming > side can actually see what the producer put into the shared data > structure. Since the signaling is done through a hypercall, there > shouldn't really be anything the producer needs to do (unless your > shared data is not in memory). > > Jan > > > _______________________________________________ > Xen-devel mailing list > Xen-devel@lists.xensource.com > http://lists.xensource.com/xen-devel > --=20 +-=3D=3D=3D=3D=3D---------------------------+ | +---------------------------------+ | This space intentionally blank for notetaking. | |=A0=A0 | Daniel Castro,=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 | | |=A0=A0 | Consultant/Programmer.| | |=A0=A0 | U Andes=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0=A0 | +-------------------------------------+ _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel From xen-devel-bounces@lists.xensource.com Tue Sep 20 02:08:46 2011 Return-path: <xen-devel-bounces@lists.xensource.com> Envelope-to: www-data@lists.xensource.com Delivery-date: Tue, 20 Sep 2011 02:08:46 -0700 Received: from localhost ([127.0.0.1] helo=lists.colo.xensource.com) by lists.xensource.com with esmtp (Exim 4.43) id 1R5wJp-00078P-K9; Tue, 20 Sep 2011 02:08:45 -0700 Received: from mail216.messagelabs.com ([85.158.143.99]) by lists.xensource.com with esmtp (Exim 4.43) id 1R5wIu-0006v3-Bx for xen-devel@lists.xensource.com; Tue, 20 Sep 2011 02:07:48 -0700 X-Env-Sender: JBeulich@suse.com X-Msg-Ref: server-12.tower-216.messagelabs.com!1316509664!13174427!1 X-Originating-IP: [130.57.49.28] X-StarScan-Version: 6.4.1; banners=-,-,- X-VirusChecked: Checked Received: (qmail 17813 invoked from network); 20 Sep 2011 09:07:45 -0000 Received: from nat28.tlf.novell.com (HELO nat28.tlf.novell.com) (130.57.49.28) by server-12.tower-216.messagelabs.com with DHE-RSA-AES256-SHA encrypted SMTP; 20 Sep 2011 09:07:45 -0000 Received: from EMEA1-MTA by nat28.tlf.novell.com with Novell_GroupWise; Tue, 20 Sep 2011 10:07:44 +0100 Message-Id: <4E7874180200007800056BF2@nat28.tlf.novell.com> X-Mailer: Novell GroupWise Internet Agent 8.0.1 Date: Tue, 20 Sep 2011 10:08:08 +0100 From: "Jan Beulich" <JBeulich@suse.com> To: "Daniel Castro" <evil.dani@gmail.com> Subject: Re: [Xen-devel] Sched_op hypercall small questions References: <4E784FD502000078000769C5@nat28.tlf.novell.com> <CAP2B85_YdLJDaNoaimuDOJhQJ_1ogtDWYhUbg-Ycxd0R0dmd8A@mail.gmail.com> In-Reply-To: <CAP2B85_YdLJDaNoaimuDOJhQJ_1ogtDWYhUbg-Ycxd0R0dmd8A@mail.gmail.com> Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: quoted-printable Content-Disposition: inline Cc: keir.xen@gmail.com, xen-devel@lists.xensource.com X-BeenThere: xen-devel@lists.xensource.com X-Mailman-Version: 2.1.5 Precedence: list List-Id: Xen developer discussion <xen-devel.lists.xensource.com> List-Unsubscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe> List-Post: <mailto:xen-devel@lists.xensource.com> List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help> List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=subscribe> Sender: xen-devel-bounces@lists.xensource.com Errors-To: xen-devel-bounces@lists.xensource.com >>> On 20.09.11 at 10:31, Daniel Castro <evil.dani@gmail.com> wrote: > On Tue, Sep 20, 2011 at 4:33 PM, Jan Beulich <jbeulich@suse.com> wrote: >>>>> Daniel Castro 09/20/11 8:18 AM >>> >>>On Tue, Sep 20, 2011 at 2:41 PM, Keir Fraser wrote: >>>> On 19/09/2011 22:21, "Daniel Castro" wrote: >>>> >>>>> Greetings all. >>>>> >>>>> Some small question regarding schedule poll operation hypercall. >>>>> >>>>> 1. struct sched_poll poll.timeout is measured in what unit of time? >>>>> Secs, ms? ns? >>>> >>>> It is an absolute system time (rather than a duration), in nanoseconds= . >>> >>>really an absolute system time? >>> >>>When the timeout is set and the timeout is reached, the system behaves >>>like if the event had been received? i.e the bit is changed? >> >> No, the bit would remain unset - the poll times out then, it doesn't >> "complete". >=20 > My Guest VM would get stuck on the hypercall call, like if it was an > infinite loop? I'm not following. Of course, if you blindly and constantly re-issue the hypercall, then you'd be stuck in a loop. Allowing to prevent that is what the timeout is for. > And once the timeout occurs or the event get delivered, then the > hypercall would return, right? Yes. Jan _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel From xen-devel-bounces@lists.xensource.com Tue Sep 20 02:43:00 2011 Return-path: <xen-devel-bounces@lists.xensource.com> Envelope-to: www-data@lists.xensource.com Delivery-date: Tue, 20 Sep 2011 02:43:00 -0700 Received: from localhost ([127.0.0.1] helo=lists.colo.xensource.com) by lists.xensource.com with esmtp (Exim 4.43) id 1R5wqx-0000Zs-Iz; Tue, 20 Sep 2011 02:42:59 -0700 Received: from mail27.messagelabs.com ([193.109.254.147]) by lists.xensource.com with smtp (Exim 4.43) id 1R5wq2-0000Me-2Q for xen-devel@lists.xensource.com; Tue, 20 Sep 2011 02:42:03 -0700 X-Env-Sender: andreas.olsowski@leuphana.de X-Msg-Ref: server-15.tower-27.messagelabs.com!1316511710!49501947!1 X-Originating-IP: [193.174.46.71] X-StarScan-Version: 6.4.1; banners=-,-,- X-VirusChecked: Checked Received: (qmail 23318 invoked from network); 20 Sep 2011 09:41:50 -0000 Received: from mailhost.leuphana.de (HELO leuphana.de) (193.174.46.71) by server-15.tower-27.messagelabs.com with SMTP; 20 Sep 2011 09:41:50 -0000 Received: from [141.39.215.216] (account aolsowsk@leuphana.de [141.39.215.216] verified) by leuphana.de (CommuniGate Pro SMTP 5.4.1e) with ESMTPSA id 45160520 for xen-devel@lists.xensource.com; Tue, 20 Sep 2011 11:41:58 +0200 Message-ID: <4E785FDD.40209@leuphana.de> Date: Tue, 20 Sep 2011 11:41:49 +0200 From: Andreas Olsowski <andreas.olsowski@leuphana.de> User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.2.21) Gecko/20110831 Icedove/3.1.13 MIME-Version: 1.0 To: xen-devel@lists.xensource.com Subject: [Xen-devel] XL: pv guests dont reboot after migration (xen4.1.2-rc2-pre) X-BeenThere: xen-devel@lists.xensource.com X-Mailman-Version: 2.1.5 Precedence: list List-Id: Xen developer discussion <xen-devel.lists.xensource.com> List-Unsubscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe> List-Post: <mailto:xen-devel@lists.xensource.com> List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help> List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=subscribe> Content-Type: multipart/mixed; boundary="===============0091756324==" Sender: xen-devel-bounces@lists.xensource.com Errors-To: xen-devel-bounces@lists.xensource.com This is a cryptographically signed message in MIME format. --===============0091756324== Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha1; boundary="------------ms000201000202000101060300" This is a cryptographically signed message in MIME format. --------------ms000201000202000101060300 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: quoted-printable A pv guest will not reboot after migration, the guest itself does=20 everything right, including the shutdown, but xl does not recreate the=20 guest, it just shuts it down. This goes for 2.6.39 and 3.0.4 guest kernels, havent tried different=20 ones. I also haven tried different xen versions. Dont know if this would affect hvm, probably not since qemu leaves the=20 guest running and does a "proper" restart. I guess this behavior has always been that way and noone ever bothered=20 to bring it up, well now i do :) --------------ms000201000202000101060300 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIU3TCC BCEwggMJoAMCAQICAgDHMA0GCSqGSIb3DQEBBQUAMHExCzAJBgNVBAYTAkRFMRwwGgYDVQQK ExNEZXV0c2NoZSBUZWxla29tIEFHMR8wHQYDVQQLExZULVRlbGVTZWMgVHJ1c3QgQ2VudGVy MSMwIQYDVQQDExpEZXV0c2NoZSBUZWxla29tIFJvb3QgQ0EgMjAeFw0wNjEyMTkxMDI5MDBa Fw0xOTA2MzAyMzU5MDBaMFoxCzAJBgNVBAYTAkRFMRMwEQYDVQQKEwpERk4tVmVyZWluMRAw DgYDVQQLEwdERk4tUEtJMSQwIgYDVQQDExtERk4tVmVyZWluIFBDQSBHbG9iYWwgLSBHMDEw ggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQDpm8NnhfkNrvWNVMOWUDU9YuluTO2U 1wBblSJ01CDrNI/W7MAxBAuZgeKmFNJSoCgjhIt0iQReW+DieMF4yxbLKDU5ey2QRdDtoAB6 fL9KDhsAw4bpXCsxEXsM84IkQ4wcOItqaACa7txPeKvSxhObdq3u3ibo7wGvdA/BCaL2a869 080UME/15eOkyGKbghoDJzANAmVgTe3RCSMqljVYJ9N2xnG2kB3E7f81hn1vM7PbD8URwoqD oZRdQWvY0hD1TP3KUazZve+Sg7va64sWVlZDz+HVEz2mHycwzUlU28kTNJpxdcVs6qcLmPkh nSevPqM5OUhqjK3JmfvDEvK9AgMBAAGjgdkwgdYwcAYDVR0fBGkwZzBloGOgYYZfaHR0cDov L3BraS50ZWxlc2VjLmRlL2NnaS1iaW4vc2VydmljZS9hZl9Eb3dubG9hZEFSTC5jcmw/LWNy bF9mb3JtYXQ9WF81MDkmLWlzc3Vlcj1EVF9ST09UX0NBXzIwHQYDVR0OBBYEFEm3xs/oPR9/ 6kR7Eyn38QpwPt5kMB8GA1UdIwQYMBaAFDHDeRu69VPXF+CJei0XbAqzK50zMA4GA1UdDwEB /wQEAwIBBjASBgNVHRMBAf8ECDAGAQH/AgECMA0GCSqGSIb3DQEBBQUAA4IBAQA74Vp3wEgX 3KkY7IGvWonwvSiSpspZGBJw7Cjy565/lizn8l0ZMfYTK3S9vYCyufdnyTmieTvhERHua3iR M347XyYndVNljjNj7s9zw7CSI0khUHUjoR8Y4pSFPT8z6XcgjaK95qGFKUD2P3MyWA0Ja6ba hWzAP7uNZmRWJE6uDT8yNQFb6YyC2XJZT7GGhfF0hVblw/hc843uR7NTBXDn5U2KaYMo4RMJ hp5eyOpYHgwf+aTUWgRo/Sg+iwK2WLX2oSw3VwBnqyNojWOl75lrXP1LVvarQIc01BGSbOyH xQoLBzNytG8MHVQs2FHHzL8w00Ny8TK/jM5JY6gA9/IcMIIFXjCCBEagAwIBAgIEC8pR1jAN BgkqhkiG9w0BAQUFADBaMQswCQYDVQQGEwJERTETMBEGA1UEChMKREZOLVZlcmVpbjEQMA4G A1UECxMHREZOLVBLSTEkMCIGA1UEAxMbREZOLVZlcmVpbiBQQ0EgR2xvYmFsIC0gRzAxMB4X DTA4MDIwNzA5NTAwMFoXDTE5MDYzMDAwMDAwMFowgdMxCzAJBgNVBAYTAkRFMRYwFAYDVQQI Ew1OaWVkZXJzYWNoc2VuMRIwEAYDVQQHEwlMdWVuZWJ1cmcxKDAmBgNVBAoTH0xldXBoYW5h IFVuaXZlcnNpdGFldCBMdWVuZWJ1cmcxIjAgBgNVBAsTGVJlY2hlbi0gdW5kIE1lZGllbnpl bnRydW0xKzApBgNVBAMTIkxldXBoYW5hIFVuaXZlcnNpdGFldCBMdWVuZWJ1cmcgQ0ExHTAb BgkqhkiG9w0BCQEWDmNhQGxldXBoYW5hLmRlMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIB CgKCAQEAqJ+JpHih32+icKiQ2IkbhmFLjAcnK0vrnyOKbn7+1xywhvL3zkraqhQlrqEltTDy 711vIEadOVfhIx8xZYYJ/zg1OCwKUxNbIbjcsIFiOKNbWxI3/yMOsaZpXsCLW7GfHLlLADW1 Cv2gUAdnjJUATcUF3a25Bgr9Lbv+GI+3bY9ydMkGnhFYSL96LLqLxAXzGXL/MAM5t/xK8cc8 +6+mWxHAqO+85Jn+UvS1khVTtZfACrYZKFnAsVHOMM/WRugohq4ue6Jfp65exMM7HKWNPrKn UV0hotcInKFBYywcZrIa2r/6m63nOxl1gHrewxiFWEBvpgMkQ+a7PHhXsMkPdQIDAQABo4IB sDCCAawwEgYDVR0TAQH/BAgwBgEB/wIBATALBgNVHQ8EBAMCAQYwHQYDVR0OBBYEFPThaBk7 GUPHATbRNGKW8/UDoQeMMB8GA1UdIwQYMBaAFEm3xs/oPR9/6kR7Eyn38QpwPt5kMBkGA1Ud EQQSMBCBDmNhQGxldXBoYW5hLmRlMIGIBgNVHR8EgYAwfjA9oDugOYY3aHR0cDovL2NkcDEu cGNhLmRmbi5kZS9nbG9iYWwtcm9vdC1jYS9wdWIvY3JsL2NhY3JsLmNybDA9oDugOYY3aHR0 cDovL2NkcDIucGNhLmRmbi5kZS9nbG9iYWwtcm9vdC1jYS9wdWIvY3JsL2NhY3JsLmNybDCB ogYIKwYBBQUHAQEEgZUwgZIwRwYIKwYBBQUHMAKGO2h0dHA6Ly9jZHAxLnBjYS5kZm4uZGUv Z2xvYmFsLXJvb3QtY2EvcHViL2NhY2VydC9jYWNlcnQuY3J0MEcGCCsGAQUFBzAChjtodHRw Oi8vY2RwMi5wY2EuZGZuLmRlL2dsb2JhbC1yb290LWNhL3B1Yi9jYWNlcnQvY2FjZXJ0LmNy dDANBgkqhkiG9w0BAQUFAAOCAQEAmSFLUEnTM1zmNRfF4TTDRB53iHmBY0OYTlaPJvXXy4f7 jc1Dpz00HiVyFohY9gqo+jbIAm5avSCmhbL9glEWubE/BNZz9l9lyTCMMxFES0TCiC6W86Ev o9E4C5IEqxZAOlvRyM3w3u8ItBO9cG190/XMi1Ouk3iBfwRVvFINy9Favq+/8HWFwkFrphpy 6JR90AbbjtE7b7owcMxusgFtPi8A1uyc3cpR21f51K7qgmGbsyXso+U9c/8Fak0IM0qQTN7p GPmI1lfJ0x1r/QusHVYSFojAT2vQamfGeCNVELg/gH4tlTGkDbHW5QhInkASQv4obBYewNfR rLG4wgPz5TCCBacwggSPoAMCAQICBBDuKTAwDQYJKoZIhvcNAQEFBQAwgdMxCzAJBgNVBAYT AkRFMRYwFAYDVQQIEw1OaWVkZXJzYWNoc2VuMRIwEAYDVQQHEwlMdWVuZWJ1cmcxKDAmBgNV BAoTH0xldXBoYW5hIFVuaXZlcnNpdGFldCBMdWVuZWJ1cmcxIjAgBgNVBAsTGVJlY2hlbi0g dW5kIE1lZGllbnplbnRydW0xKzApBgNVBAMTIkxldXBoYW5hIFVuaXZlcnNpdGFldCBMdWVu ZWJ1cmcgQ0ExHTAbBgkqhkiG9w0BCQEWDmNhQGxldXBoYW5hLmRlMB4XDTEwMTEwMTExNTky OVoXDTEzMTAzMTExNTkyOVowajELMAkGA1UEBhMCREUxKDAmBgNVBAoTH0xldXBoYW5hIFVu aXZlcnNpdGFldCBMdWVuZWJ1cmcxFjAUBgNVBAsTDVJlY2hlbnplbnRydW0xGTAXBgNVBAMT EEFuZHJlYXMgT2xzb3dza2kwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQDBzfnZ 7pbsecrmresa6JNTMmgoBFpwyr7k7U5O+j7QlFvMlePF/Tz7TeULaEevf7H68IiA/6oGZQvg NReD/64PYXxbKfsJydY6W1K+jq2karofhW5bk5p210DEQv4qyV6M+aJRKxW0Hp32OeLk5QUH 9T2780PELXGn222r+NCSmBKLP0MHsUa6CFI+jRqztB60v+wc9TD6crMEB37ddckq7mS3QWk1 m2/68bmCsHWRLTpWn9hT4S8eBSL/3YLR9DF8kfWl0wEgy8/tJY1nz5IlSI3S2v1ys7rwXBAp YHRpeHM/WNNNV4kiH09g2vlxFebQN0xTyoO1+PX6iPeAh0NbAgMBAAGjggHpMIIB5TAJBgNV HRMEAjAAMAsGA1UdDwQEAwIF4DApBgNVHSUEIjAgBggrBgEFBQcDAgYIKwYBBQUHAwQGCisG AQQBgjcUAgIwHQYDVR0OBBYEFMrca499fLnPczMLjRm2Nck06YCyMB8GA1UdIwQYMBaAFPTh aBk7GUPHATbRNGKW8/UDoQeMMCcGA1UdEQQgMB6BHGFuZHJlYXMub2xzb3dza2lAbGV1cGhh bmEuZGUwgY0GA1UdHwSBhTCBgjA/oD2gO4Y5aHR0cDovL2NkcDEucGNhLmRmbi5kZS91bmkt bHVlbmVidXJnLWNhL3B1Yi9jcmwvY2FjcmwuY3JsMD+gPaA7hjlodHRwOi8vY2RwMi5wY2Eu ZGZuLmRlL3VuaS1sdWVuZWJ1cmctY2EvcHViL2NybC9jYWNybC5jcmwwgaYGCCsGAQUFBwEB BIGZMIGWMEkGCCsGAQUFBzAChj1odHRwOi8vY2RwMS5wY2EuZGZuLmRlL3VuaS1sdWVuZWJ1 cmctY2EvcHViL2NhY2VydC9jYWNlcnQuY3J0MEkGCCsGAQUFBzAChj1odHRwOi8vY2RwMi5w Y2EuZGZuLmRlL3VuaS1sdWVuZWJ1cmctY2EvcHViL2NhY2VydC9jYWNlcnQuY3J0MA0GCSqG SIb3DQEBBQUAA4IBAQANa3ZG/UAmpRcAXqOFOKXBfzN9vZilIdAUxSaXzN9gmXBNptDEcLfD ccoA228Qc0BSdpvqMdE/21ahqE6oYI1CTfqbuYdoi/cmGoXo6+MdKCKxAD9LokkHdZFhr8re NrsVkqxyY++Cek777HKZWn1Ft9864LA6vDar3K/sUHlBNxO6VhVzt09NQIFrA50lCkNd6iCG 7Hji624SI49aWjzysBOBdcP68tzSYM+nJLod1NZ3S/W3v+IlPlMeu1JZ5hRnzoTC5qHKKdoQ kwSmQmv8/uXD46TXutmLXxH3SyBUIM4ks6RN8+VbJ9+61nOQjtazZzvgz9cnYquQC9Dm2s+q MIIFpzCCBI+gAwIBAgIEEO4pMDANBgkqhkiG9w0BAQUFADCB0zELMAkGA1UEBhMCREUxFjAU BgNVBAgTDU5pZWRlcnNhY2hzZW4xEjAQBgNVBAcTCUx1ZW5lYnVyZzEoMCYGA1UEChMfTGV1 cGhhbmEgVW5pdmVyc2l0YWV0IEx1ZW5lYnVyZzEiMCAGA1UECxMZUmVjaGVuLSB1bmQgTWVk aWVuemVudHJ1bTErMCkGA1UEAxMiTGV1cGhhbmEgVW5pdmVyc2l0YWV0IEx1ZW5lYnVyZyBD QTEdMBsGCSqGSIb3DQEJARYOY2FAbGV1cGhhbmEuZGUwHhcNMTAxMTAxMTE1OTI5WhcNMTMx MDMxMTE1OTI5WjBqMQswCQYDVQQGEwJERTEoMCYGA1UEChMfTGV1cGhhbmEgVW5pdmVyc2l0 YWV0IEx1ZW5lYnVyZzEWMBQGA1UECxMNUmVjaGVuemVudHJ1bTEZMBcGA1UEAxMQQW5kcmVh cyBPbHNvd3NraTCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAMHN+dnulux5yuat 6xrok1MyaCgEWnDKvuTtTk76PtCUW8yV48X9PPtN5QtoR69/sfrwiID/qgZlC+A1F4P/rg9h fFsp+wnJ1jpbUr6OraRquh+FbluTmnbXQMRC/irJXoz5olErFbQenfY54uTlBQf1PbvzQ8Qt cafbbav40JKYEos/QwexRroIUj6NGrO0HrS/7Bz1MPpyswQHft11ySruZLdBaTWbb/rxuYKw dZEtOlaf2FPhLx4FIv/dgtH0MXyR9aXTASDLz+0ljWfPkiVIjdLa/XKzuvBcEClgdGl4cz9Y 001XiSIfT2Da+XEV5tA3TFPKg7X49fqI94CHQ1sCAwEAAaOCAekwggHlMAkGA1UdEwQCMAAw CwYDVR0PBAQDAgXgMCkGA1UdJQQiMCAGCCsGAQUFBwMCBggrBgEFBQcDBAYKKwYBBAGCNxQC AjAdBgNVHQ4EFgQUytxrj318uc9zMwuNGbY1yTTpgLIwHwYDVR0jBBgwFoAU9OFoGTsZQ8cB NtE0Ypbz9QOhB4wwJwYDVR0RBCAwHoEcYW5kcmVhcy5vbHNvd3NraUBsZXVwaGFuYS5kZTCB jQYDVR0fBIGFMIGCMD+gPaA7hjlodHRwOi8vY2RwMS5wY2EuZGZuLmRlL3VuaS1sdWVuZWJ1 cmctY2EvcHViL2NybC9jYWNybC5jcmwwP6A9oDuGOWh0dHA6Ly9jZHAyLnBjYS5kZm4uZGUv dW5pLWx1ZW5lYnVyZy1jYS9wdWIvY3JsL2NhY3JsLmNybDCBpgYIKwYBBQUHAQEEgZkwgZYw SQYIKwYBBQUHMAKGPWh0dHA6Ly9jZHAxLnBjYS5kZm4uZGUvdW5pLWx1ZW5lYnVyZy1jYS9w dWIvY2FjZXJ0L2NhY2VydC5jcnQwSQYIKwYBBQUHMAKGPWh0dHA6Ly9jZHAyLnBjYS5kZm4u ZGUvdW5pLWx1ZW5lYnVyZy1jYS9wdWIvY2FjZXJ0L2NhY2VydC5jcnQwDQYJKoZIhvcNAQEF BQADggEBAA1rdkb9QCalFwBeo4U4pcF/M329mKUh0BTFJpfM32CZcE2m0MRwt8NxygDbbxBz QFJ2m+ox0T/bVqGoTqhgjUJN+pu5h2iL9yYahejr4x0oIrEAP0uiSQd1kWGvyt42uxWSrHJj 74J6TvvscplafUW33zrgsDq8Nqvcr+xQeUE3E7pWFXO3T01AgWsDnSUKQ13qIIbseOLrbhIj j1paPPKwE4F1w/ry3NJgz6ckuh3U1ndL9be/4iU+Ux67UlnmFGfOhMLmocop2hCTBKZCa/z+ 5cPjpNe62YtfEfdLIFQgziSzpE3z5Vsn37rWc5CO1rNnO+DP1ydiq5AL0Obaz6oxggSoMIIE pAIBATCB3DCB0zELMAkGA1UEBhMCREUxFjAUBgNVBAgTDU5pZWRlcnNhY2hzZW4xEjAQBgNV BAcTCUx1ZW5lYnVyZzEoMCYGA1UEChMfTGV1cGhhbmEgVW5pdmVyc2l0YWV0IEx1ZW5lYnVy ZzEiMCAGA1UECxMZUmVjaGVuLSB1bmQgTWVkaWVuemVudHJ1bTErMCkGA1UEAxMiTGV1cGhh bmEgVW5pdmVyc2l0YWV0IEx1ZW5lYnVyZyBDQTEdMBsGCSqGSIb3DQEJARYOY2FAbGV1cGhh bmEuZGUCBBDuKTAwCQYFKw4DAhoFAKCCAqAwGAYJKoZIhvcNAQkDMQsGCSqGSIb3DQEHATAc BgkqhkiG9w0BCQUxDxcNMTEwOTIwMDk0MTQ5WjAjBgkqhkiG9w0BCQQxFgQU138CGnnq192B nnv4nDqT+S5GHjEwXwYJKoZIhvcNAQkPMVIwUDALBglghkgBZQMEAQIwCgYIKoZIhvcNAwcw DgYIKoZIhvcNAwICAgCAMA0GCCqGSIb3DQMCAgFAMAcGBSsOAwIHMA0GCCqGSIb3DQMCAgEo MIHtBgkrBgEEAYI3EAQxgd8wgdwwgdMxCzAJBgNVBAYTAkRFMRYwFAYDVQQIEw1OaWVkZXJz YWNoc2VuMRIwEAYDVQQHEwlMdWVuZWJ1cmcxKDAmBgNVBAoTH0xldXBoYW5hIFVuaXZlcnNp dGFldCBMdWVuZWJ1cmcxIjAgBgNVBAsTGVJlY2hlbi0gdW5kIE1lZGllbnplbnRydW0xKzAp BgNVBAMTIkxldXBoYW5hIFVuaXZlcnNpdGFldCBMdWVuZWJ1cmcgQ0ExHTAbBgkqhkiG9w0B CQEWDmNhQGxldXBoYW5hLmRlAgQQ7ikwMIHvBgsqhkiG9w0BCRACCzGB36CB3DCB0zELMAkG A1UEBhMCREUxFjAUBgNVBAgTDU5pZWRlcnNhY2hzZW4xEjAQBgNVBAcTCUx1ZW5lYnVyZzEo MCYGA1UEChMfTGV1cGhhbmEgVW5pdmVyc2l0YWV0IEx1ZW5lYnVyZzEiMCAGA1UECxMZUmVj aGVuLSB1bmQgTWVkaWVuemVudHJ1bTErMCkGA1UEAxMiTGV1cGhhbmEgVW5pdmVyc2l0YWV0 IEx1ZW5lYnVyZyBDQTEdMBsGCSqGSIb3DQEJARYOY2FAbGV1cGhhbmEuZGUCBBDuKTAwDQYJ KoZIhvcNAQEBBQAEggEAQxPh7/r2yY+1vHxNI/y84VpPZvPIbSuf3nnEIXwVcNpUtnUITtDV mqMgQdALvVV/H7lwt/1JWGOfs96Cos8dogNg8s316emIF6LqYpAQCYPs+sS1/2e85FpNOHEd osYmTndrq7MsrLLZ32YdpBflDz450ftxmiGSdYl9HX9QOT47f8wVhjW0pZUOnnVdB+X4E82S jP8/M8/hO5hq5MmBX+zsU/SCcJqoPoLGJ1UTMbbjqf3SFxmRtE5YeEjl69RTewjwGYMtG90/ AaNPIMaXAwOPQGDX+qlGfRqiG5ZLu2Gtdq6qgFh8y9EkH7xgNXGuGYJHS4GJbB5kIsJFPren GQAAAAAAAA== --------------ms000201000202000101060300-- --===============0091756324== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel --===============0091756324==-- From xen-devel-bounces@lists.xensource.com Tue Sep 20 02:44:18 2011 Return-path: <xen-devel-bounces@lists.xensource.com> Envelope-to: www-data@lists.xensource.com Delivery-date: Tue, 20 Sep 2011 02:44:18 -0700 Received: from localhost ([127.0.0.1] helo=lists.colo.xensource.com) by lists.xensource.com with esmtp (Exim 4.43) id 1R5wsE-00012l-Bb; Tue, 20 Sep 2011 02:44:18 -0700 Received: from mail216.messagelabs.com ([85.158.143.99]) by lists.xensource.com with smtp (Exim 4.43) id 1R5wqv-0000YO-Gy for xen-devel@lists.xensource.com; Tue, 20 Sep 2011 02:42:58 -0700 X-Env-Sender: andreas.olsowski@leuphana.de X-Msg-Ref: server-6.tower-216.messagelabs.com!1316511774!17656548!1 X-Originating-IP: [193.174.46.71] X-StarScan-Version: 6.4.1; banners=-,-,- X-VirusChecked: Checked Received: (qmail 5541 invoked from network); 20 Sep 2011 09:42:54 -0000 Received: from mailhost.leuphana.de (HELO leuphana.de) (193.174.46.71) by server-6.tower-216.messagelabs.com with SMTP; 20 Sep 2011 09:42:54 -0000 Received: from [141.39.215.216] (account aolsowsk@leuphana.de [141.39.215.216] verified) by leuphana.de (CommuniGate Pro SMTP 5.4.1e) with ESMTPSA id 45160563 for xen-devel@lists.xensource.com; Tue, 20 Sep 2011 11:42:53 +0200 Message-ID: <4E786015.80603@leuphana.de> Date: Tue, 20 Sep 2011 11:42:45 +0200 From: Andreas Olsowski <andreas.olsowski@leuphana.de> User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.2.21) Gecko/20110831 Icedove/3.1.13 MIME-Version: 1.0 To: xen-devel@lists.xensource.com Subject: [Xen-devel] pv guests die after failed migration X-BeenThere: xen-devel@lists.xensource.com X-Mailman-Version: 2.1.5 Precedence: list List-Id: Xen developer discussion <xen-devel.lists.xensource.com> List-Unsubscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe> List-Post: <mailto:xen-devel@lists.xensource.com> List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help> List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=subscribe> Content-Type: multipart/mixed; boundary="===============1979482713==" Sender: xen-devel-bounces@lists.xensource.com Errors-To: xen-devel-bounces@lists.xensource.com This is a cryptographically signed message in MIME format. --===============1979482713== Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha1; boundary="------------ms050508050202080007060308" This is a cryptographically signed message in MIME format. --------------ms050508050202080007060308 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: quoted-printable When xm failed to do a live migration the system was resumed on the=20 sending host. Xl does not do that it TRIES to, but just crashes the guest: kernel BUG at drivers/xen/events.c:1466! (In this example the target host didnt have the logical volume activated.= ) Now that cant be right. Imho xl should do some checking if the target is a viable migration=20 target (are the disks and vifs there, is there enough memory available)=20 and preserve a safe state on the sender until the guest has properly=20 started on the receiver. --------------ms050508050202080007060308 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIU3TCC BCEwggMJoAMCAQICAgDHMA0GCSqGSIb3DQEBBQUAMHExCzAJBgNVBAYTAkRFMRwwGgYDVQQK ExNEZXV0c2NoZSBUZWxla29tIEFHMR8wHQYDVQQLExZULVRlbGVTZWMgVHJ1c3QgQ2VudGVy MSMwIQYDVQQDExpEZXV0c2NoZSBUZWxla29tIFJvb3QgQ0EgMjAeFw0wNjEyMTkxMDI5MDBa Fw0xOTA2MzAyMzU5MDBaMFoxCzAJBgNVBAYTAkRFMRMwEQYDVQQKEwpERk4tVmVyZWluMRAw DgYDVQQLEwdERk4tUEtJMSQwIgYDVQQDExtERk4tVmVyZWluIFBDQSBHbG9iYWwgLSBHMDEw ggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQDpm8NnhfkNrvWNVMOWUDU9YuluTO2U 1wBblSJ01CDrNI/W7MAxBAuZgeKmFNJSoCgjhIt0iQReW+DieMF4yxbLKDU5ey2QRdDtoAB6 fL9KDhsAw4bpXCsxEXsM84IkQ4wcOItqaACa7txPeKvSxhObdq3u3ibo7wGvdA/BCaL2a869 080UME/15eOkyGKbghoDJzANAmVgTe3RCSMqljVYJ9N2xnG2kB3E7f81hn1vM7PbD8URwoqD oZRdQWvY0hD1TP3KUazZve+Sg7va64sWVlZDz+HVEz2mHycwzUlU28kTNJpxdcVs6qcLmPkh nSevPqM5OUhqjK3JmfvDEvK9AgMBAAGjgdkwgdYwcAYDVR0fBGkwZzBloGOgYYZfaHR0cDov L3BraS50ZWxlc2VjLmRlL2NnaS1iaW4vc2VydmljZS9hZl9Eb3dubG9hZEFSTC5jcmw/LWNy bF9mb3JtYXQ9WF81MDkmLWlzc3Vlcj1EVF9ST09UX0NBXzIwHQYDVR0OBBYEFEm3xs/oPR9/ 6kR7Eyn38QpwPt5kMB8GA1UdIwQYMBaAFDHDeRu69VPXF+CJei0XbAqzK50zMA4GA1UdDwEB /wQEAwIBBjASBgNVHRMBAf8ECDAGAQH/AgECMA0GCSqGSIb3DQEBBQUAA4IBAQA74Vp3wEgX 3KkY7IGvWonwvSiSpspZGBJw7Cjy565/lizn8l0ZMfYTK3S9vYCyufdnyTmieTvhERHua3iR M347XyYndVNljjNj7s9zw7CSI0khUHUjoR8Y4pSFPT8z6XcgjaK95qGFKUD2P3MyWA0Ja6ba hWzAP7uNZmRWJE6uDT8yNQFb6YyC2XJZT7GGhfF0hVblw/hc843uR7NTBXDn5U2KaYMo4RMJ hp5eyOpYHgwf+aTUWgRo/Sg+iwK2WLX2oSw3VwBnqyNojWOl75lrXP1LVvarQIc01BGSbOyH xQoLBzNytG8MHVQs2FHHzL8w00Ny8TK/jM5JY6gA9/IcMIIFXjCCBEagAwIBAgIEC8pR1jAN BgkqhkiG9w0BAQUFADBaMQswCQYDVQQGEwJERTETMBEGA1UEChMKREZOLVZlcmVpbjEQMA4G A1UECxMHREZOLVBLSTEkMCIGA1UEAxMbREZOLVZlcmVpbiBQQ0EgR2xvYmFsIC0gRzAxMB4X DTA4MDIwNzA5NTAwMFoXDTE5MDYzMDAwMDAwMFowgdMxCzAJBgNVBAYTAkRFMRYwFAYDVQQI Ew1OaWVkZXJzYWNoc2VuMRIwEAYDVQQHEwlMdWVuZWJ1cmcxKDAmBgNVBAoTH0xldXBoYW5h IFVuaXZlcnNpdGFldCBMdWVuZWJ1cmcxIjAgBgNVBAsTGVJlY2hlbi0gdW5kIE1lZGllbnpl bnRydW0xKzApBgNVBAMTIkxldXBoYW5hIFVuaXZlcnNpdGFldCBMdWVuZWJ1cmcgQ0ExHTAb BgkqhkiG9w0BCQEWDmNhQGxldXBoYW5hLmRlMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIB CgKCAQEAqJ+JpHih32+icKiQ2IkbhmFLjAcnK0vrnyOKbn7+1xywhvL3zkraqhQlrqEltTDy 711vIEadOVfhIx8xZYYJ/zg1OCwKUxNbIbjcsIFiOKNbWxI3/yMOsaZpXsCLW7GfHLlLADW1 Cv2gUAdnjJUATcUF3a25Bgr9Lbv+GI+3bY9ydMkGnhFYSL96LLqLxAXzGXL/MAM5t/xK8cc8 +6+mWxHAqO+85Jn+UvS1khVTtZfACrYZKFnAsVHOMM/WRugohq4ue6Jfp65exMM7HKWNPrKn UV0hotcInKFBYywcZrIa2r/6m63nOxl1gHrewxiFWEBvpgMkQ+a7PHhXsMkPdQIDAQABo4IB sDCCAawwEgYDVR0TAQH/BAgwBgEB/wIBATALBgNVHQ8EBAMCAQYwHQYDVR0OBBYEFPThaBk7 GUPHATbRNGKW8/UDoQeMMB8GA1UdIwQYMBaAFEm3xs/oPR9/6kR7Eyn38QpwPt5kMBkGA1Ud EQQSMBCBDmNhQGxldXBoYW5hLmRlMIGIBgNVHR8EgYAwfjA9oDugOYY3aHR0cDovL2NkcDEu cGNhLmRmbi5kZS9nbG9iYWwtcm9vdC1jYS9wdWIvY3JsL2NhY3JsLmNybDA9oDugOYY3aHR0 cDovL2NkcDIucGNhLmRmbi5kZS9nbG9iYWwtcm9vdC1jYS9wdWIvY3JsL2NhY3JsLmNybDCB ogYIKwYBBQUHAQEEgZUwgZIwRwYIKwYBBQUHMAKGO2h0dHA6Ly9jZHAxLnBjYS5kZm4uZGUv Z2xvYmFsLXJvb3QtY2EvcHViL2NhY2VydC9jYWNlcnQuY3J0MEcGCCsGAQUFBzAChjtodHRw Oi8vY2RwMi5wY2EuZGZuLmRlL2dsb2JhbC1yb290LWNhL3B1Yi9jYWNlcnQvY2FjZXJ0LmNy dDANBgkqhkiG9w0BAQUFAAOCAQEAmSFLUEnTM1zmNRfF4TTDRB53iHmBY0OYTlaPJvXXy4f7 jc1Dpz00HiVyFohY9gqo+jbIAm5avSCmhbL9glEWubE/BNZz9l9lyTCMMxFES0TCiC6W86Ev o9E4C5IEqxZAOlvRyM3w3u8ItBO9cG190/XMi1Ouk3iBfwRVvFINy9Favq+/8HWFwkFrphpy 6JR90AbbjtE7b7owcMxusgFtPi8A1uyc3cpR21f51K7qgmGbsyXso+U9c/8Fak0IM0qQTN7p GPmI1lfJ0x1r/QusHVYSFojAT2vQamfGeCNVELg/gH4tlTGkDbHW5QhInkASQv4obBYewNfR rLG4wgPz5TCCBacwggSPoAMCAQICBBDuKTAwDQYJKoZIhvcNAQEFBQAwgdMxCzAJBgNVBAYT AkRFMRYwFAYDVQQIEw1OaWVkZXJzYWNoc2VuMRIwEAYDVQQHEwlMdWVuZWJ1cmcxKDAmBgNV BAoTH0xldXBoYW5hIFVuaXZlcnNpdGFldCBMdWVuZWJ1cmcxIjAgBgNVBAsTGVJlY2hlbi0g dW5kIE1lZGllbnplbnRydW0xKzApBgNVBAMTIkxldXBoYW5hIFVuaXZlcnNpdGFldCBMdWVu ZWJ1cmcgQ0ExHTAbBgkqhkiG9w0BCQEWDmNhQGxldXBoYW5hLmRlMB4XDTEwMTEwMTExNTky OVoXDTEzMTAzMTExNTkyOVowajELMAkGA1UEBhMCREUxKDAmBgNVBAoTH0xldXBoYW5hIFVu aXZlcnNpdGFldCBMdWVuZWJ1cmcxFjAUBgNVBAsTDVJlY2hlbnplbnRydW0xGTAXBgNVBAMT EEFuZHJlYXMgT2xzb3dza2kwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQDBzfnZ 7pbsecrmresa6JNTMmgoBFpwyr7k7U5O+j7QlFvMlePF/Tz7TeULaEevf7H68IiA/6oGZQvg NReD/64PYXxbKfsJydY6W1K+jq2karofhW5bk5p210DEQv4qyV6M+aJRKxW0Hp32OeLk5QUH 9T2780PELXGn222r+NCSmBKLP0MHsUa6CFI+jRqztB60v+wc9TD6crMEB37ddckq7mS3QWk1 m2/68bmCsHWRLTpWn9hT4S8eBSL/3YLR9DF8kfWl0wEgy8/tJY1nz5IlSI3S2v1ys7rwXBAp YHRpeHM/WNNNV4kiH09g2vlxFebQN0xTyoO1+PX6iPeAh0NbAgMBAAGjggHpMIIB5TAJBgNV HRMEAjAAMAsGA1UdDwQEAwIF4DApBgNVHSUEIjAgBggrBgEFBQcDAgYIKwYBBQUHAwQGCisG AQQBgjcUAgIwHQYDVR0OBBYEFMrca499fLnPczMLjRm2Nck06YCyMB8GA1UdIwQYMBaAFPTh aBk7GUPHATbRNGKW8/UDoQeMMCcGA1UdEQQgMB6BHGFuZHJlYXMub2xzb3dza2lAbGV1cGhh bmEuZGUwgY0GA1UdHwSBhTCBgjA/oD2gO4Y5aHR0cDovL2NkcDEucGNhLmRmbi5kZS91bmkt bHVlbmVidXJnLWNhL3B1Yi9jcmwvY2FjcmwuY3JsMD+gPaA7hjlodHRwOi8vY2RwMi5wY2Eu ZGZuLmRlL3VuaS1sdWVuZWJ1cmctY2EvcHViL2NybC9jYWNybC5jcmwwgaYGCCsGAQUFBwEB BIGZMIGWMEkGCCsGAQUFBzAChj1odHRwOi8vY2RwMS5wY2EuZGZuLmRlL3VuaS1sdWVuZWJ1 cmctY2EvcHViL2NhY2VydC9jYWNlcnQuY3J0MEkGCCsGAQUFBzAChj1odHRwOi8vY2RwMi5w Y2EuZGZuLmRlL3VuaS1sdWVuZWJ1cmctY2EvcHViL2NhY2VydC9jYWNlcnQuY3J0MA0GCSqG SIb3DQEBBQUAA4IBAQANa3ZG/UAmpRcAXqOFOKXBfzN9vZilIdAUxSaXzN9gmXBNptDEcLfD ccoA228Qc0BSdpvqMdE/21ahqE6oYI1CTfqbuYdoi/cmGoXo6+MdKCKxAD9LokkHdZFhr8re NrsVkqxyY++Cek777HKZWn1Ft9864LA6vDar3K/sUHlBNxO6VhVzt09NQIFrA50lCkNd6iCG 7Hji624SI49aWjzysBOBdcP68tzSYM+nJLod1NZ3S/W3v+IlPlMeu1JZ5hRnzoTC5qHKKdoQ kwSmQmv8/uXD46TXutmLXxH3SyBUIM4ks6RN8+VbJ9+61nOQjtazZzvgz9cnYquQC9Dm2s+q MIIFpzCCBI+gAwIBAgIEEO4pMDANBgkqhkiG9w0BAQUFADCB0zELMAkGA1UEBhMCREUxFjAU BgNVBAgTDU5pZWRlcnNhY2hzZW4xEjAQBgNVBAcTCUx1ZW5lYnVyZzEoMCYGA1UEChMfTGV1 cGhhbmEgVW5pdmVyc2l0YWV0IEx1ZW5lYnVyZzEiMCAGA1UECxMZUmVjaGVuLSB1bmQgTWVk aWVuemVudHJ1bTErMCkGA1UEAxMiTGV1cGhhbmEgVW5pdmVyc2l0YWV0IEx1ZW5lYnVyZyBD QTEdMBsGCSqGSIb3DQEJARYOY2FAbGV1cGhhbmEuZGUwHhcNMTAxMTAxMTE1OTI5WhcNMTMx MDMxMTE1OTI5WjBqMQswCQYDVQQGEwJERTEoMCYGA1UEChMfTGV1cGhhbmEgVW5pdmVyc2l0 YWV0IEx1ZW5lYnVyZzEWMBQGA1UECxMNUmVjaGVuemVudHJ1bTEZMBcGA1UEAxMQQW5kcmVh cyBPbHNvd3NraTCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAMHN+dnulux5yuat 6xrok1MyaCgEWnDKvuTtTk76PtCUW8yV48X9PPtN5QtoR69/sfrwiID/qgZlC+A1F4P/rg9h fFsp+wnJ1jpbUr6OraRquh+FbluTmnbXQMRC/irJXoz5olErFbQenfY54uTlBQf1PbvzQ8Qt cafbbav40JKYEos/QwexRroIUj6NGrO0HrS/7Bz1MPpyswQHft11ySruZLdBaTWbb/rxuYKw dZEtOlaf2FPhLx4FIv/dgtH0MXyR9aXTASDLz+0ljWfPkiVIjdLa/XKzuvBcEClgdGl4cz9Y 001XiSIfT2Da+XEV5tA3TFPKg7X49fqI94CHQ1sCAwEAAaOCAekwggHlMAkGA1UdEwQCMAAw CwYDVR0PBAQDAgXgMCkGA1UdJQQiMCAGCCsGAQUFBwMCBggrBgEFBQcDBAYKKwYBBAGCNxQC AjAdBgNVHQ4EFgQUytxrj318uc9zMwuNGbY1yTTpgLIwHwYDVR0jBBgwFoAU9OFoGTsZQ8cB NtE0Ypbz9QOhB4wwJwYDVR0RBCAwHoEcYW5kcmVhcy5vbHNvd3NraUBsZXVwaGFuYS5kZTCB jQYDVR0fBIGFMIGCMD+gPaA7hjlodHRwOi8vY2RwMS5wY2EuZGZuLmRlL3VuaS1sdWVuZWJ1 cmctY2EvcHViL2NybC9jYWNybC5jcmwwP6A9oDuGOWh0dHA6Ly9jZHAyLnBjYS5kZm4uZGUv dW5pLWx1ZW5lYnVyZy1jYS9wdWIvY3JsL2NhY3JsLmNybDCBpgYIKwYBBQUHAQEEgZkwgZYw SQYIKwYBBQUHMAKGPWh0dHA6Ly9jZHAxLnBjYS5kZm4uZGUvdW5pLWx1ZW5lYnVyZy1jYS9w dWIvY2FjZXJ0L2NhY2VydC5jcnQwSQYIKwYBBQUHMAKGPWh0dHA6Ly9jZHAyLnBjYS5kZm4u ZGUvdW5pLWx1ZW5lYnVyZy1jYS9wdWIvY2FjZXJ0L2NhY2VydC5jcnQwDQYJKoZIhvcNAQEF BQADggEBAA1rdkb9QCalFwBeo4U4pcF/M329mKUh0BTFJpfM32CZcE2m0MRwt8NxygDbbxBz QFJ2m+ox0T/bVqGoTqhgjUJN+pu5h2iL9yYahejr4x0oIrEAP0uiSQd1kWGvyt42uxWSrHJj 74J6TvvscplafUW33zrgsDq8Nqvcr+xQeUE3E7pWFXO3T01AgWsDnSUKQ13qIIbseOLrbhIj j1paPPKwE4F1w/ry3NJgz6ckuh3U1ndL9be/4iU+Ux67UlnmFGfOhMLmocop2hCTBKZCa/z+ 5cPjpNe62YtfEfdLIFQgziSzpE3z5Vsn37rWc5CO1rNnO+DP1ydiq5AL0Obaz6oxggSoMIIE pAIBATCB3DCB0zELMAkGA1UEBhMCREUxFjAUBgNVBAgTDU5pZWRlcnNhY2hzZW4xEjAQBgNV BAcTCUx1ZW5lYnVyZzEoMCYGA1UEChMfTGV1cGhhbmEgVW5pdmVyc2l0YWV0IEx1ZW5lYnVy ZzEiMCAGA1UECxMZUmVjaGVuLSB1bmQgTWVkaWVuemVudHJ1bTErMCkGA1UEAxMiTGV1cGhh bmEgVW5pdmVyc2l0YWV0IEx1ZW5lYnVyZyBDQTEdMBsGCSqGSIb3DQEJARYOY2FAbGV1cGhh bmEuZGUCBBDuKTAwCQYFKw4DAhoFAKCCAqAwGAYJKoZIhvcNAQkDMQsGCSqGSIb3DQEHATAc BgkqhkiG9w0BCQUxDxcNMTEwOTIwMDk0MjQ1WjAjBgkqhkiG9w0BCQQxFgQU1Kl0VBLwhsUW 43SDRnN6TqiSDCUwXwYJKoZIhvcNAQkPMVIwUDALBglghkgBZQMEAQIwCgYIKoZIhvcNAwcw DgYIKoZIhvcNAwICAgCAMA0GCCqGSIb3DQMCAgFAMAcGBSsOAwIHMA0GCCqGSIb3DQMCAgEo MIHtBgkrBgEEAYI3EAQxgd8wgdwwgdMxCzAJBgNVBAYTAkRFMRYwFAYDVQQIEw1OaWVkZXJz YWNoc2VuMRIwEAYDVQQHEwlMdWVuZWJ1cmcxKDAmBgNVBAoTH0xldXBoYW5hIFVuaXZlcnNp dGFldCBMdWVuZWJ1cmcxIjAgBgNVBAsTGVJlY2hlbi0gdW5kIE1lZGllbnplbnRydW0xKzAp BgNVBAMTIkxldXBoYW5hIFVuaXZlcnNpdGFldCBMdWVuZWJ1cmcgQ0ExHTAbBgkqhkiG9w0B CQEWDmNhQGxldXBoYW5hLmRlAgQQ7ikwMIHvBgsqhkiG9w0BCRACCzGB36CB3DCB0zELMAkG A1UEBhMCREUxFjAUBgNVBAgTDU5pZWRlcnNhY2hzZW4xEjAQBgNVBAcTCUx1ZW5lYnVyZzEo MCYGA1UEChMfTGV1cGhhbmEgVW5pdmVyc2l0YWV0IEx1ZW5lYnVyZzEiMCAGA1UECxMZUmVj aGVuLSB1bmQgTWVkaWVuemVudHJ1bTErMCkGA1UEAxMiTGV1cGhhbmEgVW5pdmVyc2l0YWV0 IEx1ZW5lYnVyZyBDQTEdMBsGCSqGSIb3DQEJARYOY2FAbGV1cGhhbmEuZGUCBBDuKTAwDQYJ KoZIhvcNAQEBBQAEggEAfS7dZPdM5Y0NiNplVCM2arwv0rgwRsBBjHJjP4846+nqNfJGYiQv A1UfkVf18SEDE6+QSr7thzxnEkau/YjEPcUet6jjhRutpBgvyiFKpcpxvVggKui1dNQJGF+I WXfc1H81oq++YuV/bevlSPb078Kg83q+yH6djchpvhXrT1aOXDrcYyuB8EW2cyK2Y1dtlxgP bEDrTQSeTKasgjiw/81ATuh0vFPVJPplFiJOK5IUUXRj9HBlzvzR+o0gLQJRLBASmui02fqz rC7IGeWd0pqC61vi4H0AIqr+CS83gn3HzhRlfP9rjtg85TltYrz7Sf204/veVldmDk3bruIk DQAAAAAAAA== --------------ms050508050202080007060308-- --===============1979482713== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel --===============1979482713==-- From xen-devel-bounces@lists.xensource.com Tue Sep 20 03:56:43 2011 Return-path: <xen-devel-bounces@lists.xensource.com> Envelope-to: www-data@lists.xensource.com Delivery-date: Tue, 20 Sep 2011 03:56:43 -0700 Received: from localhost ([127.0.0.1] helo=lists.colo.xensource.com) by lists.xensource.com with esmtp (Exim 4.43) id 1R5y0I-0003Ox-3y; Tue, 20 Sep 2011 03:56:42 -0700 Received: from mail174.messagelabs.com ([85.158.138.51]) by lists.xensource.com with esmtp (Exim 4.43) id 1R5xzR-0003CH-Mq for xen-devel@lists.xensource.com; Tue, 20 Sep 2011 03:55:50 -0700 X-Env-Sender: evil.dani@gmail.com X-Msg-Ref: server-6.tower-174.messagelabs.com!1316516146!29952775!1 X-Originating-IP: [209.85.161.43] X-StarScan-Version: 6.4.1; banners=-,-,- X-VirusChecked: Checked Received: (qmail 4086 invoked from network); 20 Sep 2011 10:55:46 -0000 Received: from mail-fx0-f43.google.com (HELO mail-fx0-f43.google.com) (209.85.161.43) by server-6.tower-174.messagelabs.com with RC4-SHA encrypted SMTP; 20 Sep 2011 10:55:46 -0000 Received: by fxh19 with SMTP id 19so608689fxh.30 for <xen-devel@lists.xensource.com>; Tue, 20 Sep 2011 03:55:46 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; bh=FGnAGBVQ+XhmkTx9Xz5kE5uk2kGfE4t4MCSau/lCYA4=; b=qAWvUCEcRy2ZjIhAZD4SyEAxHEPAQNsWOiIseYRzqZGMhdh8KqT144nZS77gcAHtbd L3/NjQnhsL+lZQauIfrCVlIMdsVsTAcGkyt9dstCm7i2RzsfzdbwjROMoJORvooUK/I/ Smr/ubOEkpXEWmE5xKvF3YWUHQRXgCppZ7AnA= MIME-Version: 1.0 Received: by 10.223.10.14 with SMTP id n14mr1131449fan.37.1316516146414; Tue, 20 Sep 2011 03:55:46 -0700 (PDT) Received: by 10.223.97.9 with HTTP; Tue, 20 Sep 2011 03:55:46 -0700 (PDT) In-Reply-To: <4E7874180200007800056BF2@nat28.tlf.novell.com> References: <4E784FD502000078000769C5@nat28.tlf.novell.com> <CAP2B85_YdLJDaNoaimuDOJhQJ_1ogtDWYhUbg-Ycxd0R0dmd8A@mail.gmail.com> <4E7874180200007800056BF2@nat28.tlf.novell.com> Date: Tue, 20 Sep 2011 19:55:46 +0900 Message-ID: <CAP2B85-ZUYdbkyEQHkM65gwKO4g-xV=k3O30FByw9DhA7vwmWg@mail.gmail.com> Subject: Re: [Xen-devel] Sched_op hypercall small questions From: Daniel Castro <evil.dani@gmail.com> To: Jan Beulich <JBeulich@suse.com> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: keir.xen@gmail.com, xen-devel@lists.xensource.com X-BeenThere: xen-devel@lists.xensource.com X-Mailman-Version: 2.1.5 Precedence: list List-Id: Xen developer discussion <xen-devel.lists.xensource.com> List-Unsubscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe> List-Post: <mailto:xen-devel@lists.xensource.com> List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help> List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=subscribe> Sender: xen-devel-bounces@lists.xensource.com Errors-To: xen-devel-bounces@lists.xensource.com On Tue, Sep 20, 2011 at 6:08 PM, Jan Beulich <JBeulich@suse.com> wrote: >>>> On 20.09.11 at 10:31, Daniel Castro <evil.dani@gmail.com> wrote: >> On Tue, Sep 20, 2011 at 4:33 PM, Jan Beulich <jbeulich@suse.com> wrote: >>>>>> Daniel Castro =A009/20/11 8:18 AM >>> >>>>On Tue, Sep 20, 2011 at 2:41 PM, Keir Fraser =A0wrote: >>>>> On 19/09/2011 22:21, "Daniel Castro" =A0wrote: >>>>> >>>>>> Greetings all. >>>>>> >>>>>> Some small question regarding schedule poll operation hypercall. >>>>>> >>>>>> 1. struct sched_poll poll.timeout is measured in what unit of time? >>>>>> Secs, ms? ns? >>>>> >>>>> It is an absolute system time (rather than a duration), in nanosecond= s. >>>> >>>>really an absolute system time? >>>> >>>>When the timeout is set and the timeout is reached, the system behaves >>>>like if the event had been received? i.e the bit is changed? >>> >>> No, the bit would remain unset - the poll times out then, it doesn't >>> "complete". >> >> My Guest VM would get stuck on the hypercall call, like if it was an >> infinite loop? > > I'm not following. Of course, if you blindly and constantly re-issue the > hypercall, then you'd be stuck in a loop. Allowing to prevent that is > what the timeout is for. What I am trying is writing to the xenstore ring, issue the send hypercall, then wait (poll hypercall) for event, then read answer from ring. The waiting is not working, but If I wait enough time, the ring will contain the answer, but apparently I have a problem with my event channel port. So to test this theory I am using event channel status hypercall, and I get: Status 2 (meaning interdomain connected) VCPU 0 The Union reports dom 32752 and port 2. Right now, there are two things that jump to my mind, first when I issue the poll hypercall the system continues execution, instead of yielding CPU unitl event arrives. If it were never to arrive it should yield infinitely, right? Second, the bit is never set. Or it is being undone before I can check it. Thanks, Daniel > >> And once the timeout occurs or the event get delivered, then the >> hypercall would return, right? > > Yes. > > Jan > > --=20 +-=3D=3D=3D=3D=3D---------------------------+ | +---------------------------------+ | This space intentionally blank for notetaking. | |=A0=A0 | Daniel Castro,=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 | | |=A0=A0 | Consultant/Programmer.| | |=A0=A0 | U Andes=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0=A0 | +-------------------------------------+ _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel From xen-devel-bounces@lists.xensource.com Tue Sep 20 04:05:59 2011 Return-path: <xen-devel-bounces@lists.xensource.com> Envelope-to: www-data@lists.xensource.com Delivery-date: Tue, 20 Sep 2011 04:05:59 -0700 Received: from localhost ([127.0.0.1] helo=lists.colo.xensource.com) by lists.xensource.com with esmtp (Exim 4.43) id 1R5y9G-0003wh-Bh; Tue, 20 Sep 2011 04:05:58 -0700 Received: from mail27.messagelabs.com ([193.109.254.147]) by lists.xensource.com with esmtp (Exim 4.43) id 1R5y7m-0003k2-Ni for xen-devel@lists.xensource.com; Tue, 20 Sep 2011 04:04:28 -0700 X-Env-Sender: JBeulich@suse.com X-Msg-Ref: server-12.tower-27.messagelabs.com!1316516648!43182189!1 X-Originating-IP: [130.57.49.28] X-StarScan-Version: 6.4.1; banners=-,-,- X-VirusChecked: Checked Received: (qmail 32323 invoked from network); 20 Sep 2011 11:04:08 -0000 Received: from nat28.tlf.novell.com (HELO nat28.tlf.novell.com) (130.57.49.28) by server-12.tower-27.messagelabs.com with DHE-RSA-AES256-SHA encrypted SMTP; 20 Sep 2011 11:04:08 -0000 Received: from EMEA1-MTA by nat28.tlf.novell.com with Novell_GroupWise; Tue, 20 Sep 2011 12:04:23 +0100 Message-Id: <4E788F710200007800056C38@nat28.tlf.novell.com> X-Mailer: Novell GroupWise Internet Agent 8.0.1 Date: Tue, 20 Sep 2011 12:04:49 +0100 From: "Jan Beulich" <JBeulich@suse.com> To: "Ian Campbell" <Ian.Campbell@eu.citrix.com> Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: quoted-printable Content-Disposition: inline Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com> Subject: [Xen-devel] netback commit history X-BeenThere: xen-devel@lists.xensource.com X-Mailman-Version: 2.1.5 Precedence: list List-Id: Xen developer discussion <xen-devel.lists.xensource.com> List-Unsubscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe> List-Post: <mailto:xen-devel@lists.xensource.com> List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help> List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=subscribe> Sender: xen-devel-bounces@lists.xensource.com Errors-To: xen-devel-bounces@lists.xensource.com Hi Ian, with the upstream netback introduction consisting of a single big commit I wonder whether you could point me to where the full history of it is. I'm asking particularly in the context of us being asked to add a safety check similar to the vif->netbk !=3D NULL one at the beginning of xenvif_start_xmit() (also in xenvif_interrupt(), but there we have a similar check in place), which hadn't been in the legacy tree (obviously) nor in the original multiple-tasklets patch that I retained a copy of. = That is, I'd like to understand the reasons for this check as it seems wrong to me to have to do it there - I'd rather think that if an interface got disabled, execution shouldn't even reach that function anymore. One thing I wonder about in this context is whether the netif_stop_queue() call from xenvif_close() shouldn't happen before xenvif_down() (not the least for reasons of symmetry with xenvif_open()). Thanks, Jan _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel From xen-devel-bounces@lists.xensource.com Tue Sep 20 04:27:53 2011 Return-path: <xen-devel-bounces@lists.xensource.com> Envelope-to: www-data@lists.xensource.com Delivery-date: Tue, 20 Sep 2011 04:27:53 -0700 Received: from localhost ([127.0.0.1] helo=lists.colo.xensource.com) by lists.xensource.com with esmtp (Exim 4.43) id 1R5yUS-0005NB-Ir; Tue, 20 Sep 2011 04:27:52 -0700 Received: from mail182.messagelabs.com ([85.158.139.83]) by lists.xensource.com with esmtp (Exim 4.43) id 1R5yTe-0005Al-4i for xen-devel@lists.xensource.com; Tue, 20 Sep 2011 04:27:02 -0700 X-Env-Sender: Ian.Campbell@eu.citrix.com X-Msg-Ref: server-11.tower-182.messagelabs.com!1316518018!19047938!1 X-Originating-IP: [62.200.22.115] X-StarScan-Version: 6.4.1; banners=-,-,- X-VirusChecked: Checked Received: (qmail 15766 invoked from network); 20 Sep 2011 11:26:59 -0000 Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115) by server-11.tower-182.messagelabs.com with RC4-SHA encrypted SMTP; 20 Sep 2011 11:26:59 -0000 X-IronPort-AV: E=Sophos;i="4.68,411,1312156800"; d="scan'208";a="7949710" Received: from lonpmailmx01.citrite.net ([10.30.203.162]) by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5; 20 Sep 2011 11:26:58 +0000 Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net (10.30.203.162) with Microsoft SMTP Server id 8.3.137.0; Tue, 20 Sep 2011 12:26:58 +0100 From: Ian Campbell <Ian.Campbell@eu.citrix.com> To: Jan Beulich <JBeulich@suse.com> Date: Tue, 20 Sep 2011 12:26:58 +0100 In-Reply-To: <4E788F710200007800056C38@nat28.tlf.novell.com> References: <4E788F710200007800056C38@nat28.tlf.novell.com> Organization: Citrix Systems, Inc. Content-Type: text/plain; charset="UTF-8" X-Mailer: Evolution 3.0.3- Content-Transfer-Encoding: 7bit Message-ID: <1316518018.3891.38.camel@zakaz.uk.xensource.com> MIME-Version: 1.0 Cc: Xu <dongxiao.xu@intel.com>, "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>, Dongxiao Subject: [Xen-devel] Re: netback commit history X-BeenThere: xen-devel@lists.xensource.com X-Mailman-Version: 2.1.5 Precedence: list List-Id: Xen developer discussion <xen-devel.lists.xensource.com> List-Unsubscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe> List-Post: <mailto:xen-devel@lists.xensource.com> List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help> List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=subscribe> Sender: xen-devel-bounces@lists.xensource.com Errors-To: xen-devel-bounces@lists.xensource.com On Tue, 2011-09-20 at 12:04 +0100, Jan Beulich wrote: > Hi Ian, > > with the upstream netback introduction consisting of a single big commit > I wonder whether you could point me to where the full history of it is. Yeah, that was a bit annoying, luckily I had the foresight to post where the history was. http://www.gossamer-threads.com/lists/xen/devel/202139 says it is: git://xenbits.xen.org/people/ianc/linux-2.6.git upstream/dom0/backend/netback-history > I'm asking particularly in the context of us being asked to add a safety > check similar to the vif->netbk != NULL one at the beginning of > xenvif_start_xmit() (also in xenvif_interrupt(), but there we have a > similar check in place), which hadn't been in the legacy tree (obviously) > nor in the original multiple-tasklets patch that I retained a copy of. Seems to have come from bc05ada1283eb583c9789c27429af36b034c4a74 in that history tree and was a conversion from a check for group == -1. That commit changes from storing a group index to a group pointer so I think it's roughly equivalent from a validity point of view. The original group == -1 check appears to be in the 2.6.32.x pvops kernels at least, I expect it is also in the multiple tasklet patch which you have as well? > That > is, I'd like to understand the reasons for this check as it seems wrong > to me to have to do it there - I'd rather think that if an interface got > disabled, execution shouldn't even reach that function anymore. Yes, I'd think that too but I don't really know. Maybe Dongxiao remembers why he added it? > One thing I wonder about in this context is whether the > netif_stop_queue() call from xenvif_close() shouldn't happen before > xenvif_down() (not the least for reasons of symmetry with > xenvif_open()). I seem to recall looking at that too, it was the same in the old kernels too and I didn't know why so I avoided touching it (I was doing too much other cleanup at the time to risk it). Ian. _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel From xen-devel-bounces@lists.xensource.com Tue Sep 20 04:46:46 2011 Return-path: <xen-devel-bounces@lists.xensource.com> Envelope-to: www-data@lists.xensource.com Delivery-date: Tue, 20 Sep 2011 04:46:46 -0700 Received: from localhost ([127.0.0.1] helo=lists.colo.xensource.com) by lists.xensource.com with esmtp (Exim 4.43) id 1R5ymj-0006CY-B4; Tue, 20 Sep 2011 04:46:45 -0700 Received: from mail174.messagelabs.com ([85.158.138.51]) by lists.xensource.com with esmtp (Exim 4.43) id 1R5ym0-000605-A7 for xen-devel@lists.xensource.com; Tue, 20 Sep 2011 04:46:00 -0700 X-Env-Sender: JBeulich@suse.com X-Msg-Ref: server-8.tower-174.messagelabs.com!1316519156!18419962!1 X-Originating-IP: [130.57.49.28] X-StarScan-Version: 6.4.1; banners=-,-,- X-VirusChecked: Checked Received: (qmail 15003 invoked from network); 20 Sep 2011 11:45:57 -0000 Received: from nat28.tlf.novell.com (HELO nat28.tlf.novell.com) (130.57.49.28) by server-8.tower-174.messagelabs.com with DHE-RSA-AES256-SHA encrypted SMTP; 20 Sep 2011 11:45:57 -0000 Received: from EMEA1-MTA by nat28.tlf.novell.com with Novell_GroupWise; Tue, 20 Sep 2011 12:45:56 +0100 Message-Id: <4E78992D0200007800056C4F@nat28.tlf.novell.com> X-Mailer: Novell GroupWise Internet Agent 8.0.1 Date: Tue, 20 Sep 2011 12:46:21 +0100 From: "Jan Beulich" <JBeulich@suse.com> To: "Ian Campbell" <Ian.Campbell@eu.citrix.com> References: <4E788F710200007800056C38@nat28.tlf.novell.com> <1316518018.3891.38.camel@zakaz.uk.xensource.com> In-Reply-To: <1316518018.3891.38.camel@zakaz.uk.xensource.com> Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: quoted-printable Content-Disposition: inline Cc: DongxiaoXu <dongxiao.xu@intel.com>, "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com> Subject: [Xen-devel] Re: netback commit history X-BeenThere: xen-devel@lists.xensource.com X-Mailman-Version: 2.1.5 Precedence: list List-Id: Xen developer discussion <xen-devel.lists.xensource.com> List-Unsubscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe> List-Post: <mailto:xen-devel@lists.xensource.com> List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help> List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=subscribe> Sender: xen-devel-bounces@lists.xensource.com Errors-To: xen-devel-bounces@lists.xensource.com >>> On 20.09.11 at 13:26, Ian Campbell <Ian.Campbell@eu.citrix.com> wrote: > On Tue, 2011-09-20 at 12:04 +0100, Jan Beulich wrote: >> with the upstream netback introduction consisting of a single big = commit >> I wonder whether you could point me to where the full history of it is. >=20 > Yeah, that was a bit annoying, luckily I had the foresight to post where > the history was. http://www.gossamer-threads.com/lists/xen/devel/202139= =20 > says it is: > git://xenbits.xen.org/people/ianc/linux-2.6.git=20 > upstream/dom0/backend/netback-history=20 Does this have a http:// representation somewhere (it doesn't show up under http://xenbits.xen.org/people/ianc/)? >> I'm asking particularly in the context of us being asked to add a = safety >> check similar to the vif->netbk !=3D NULL one at the beginning of >> xenvif_start_xmit() (also in xenvif_interrupt(), but there we have a >> similar check in place), which hadn't been in the legacy tree (obviously= ) >> nor in the original multiple-tasklets patch that I retained a copy of. >=20 > Seems to have come from bc05ada1283eb583c9789c27429af36b034c4a74 in that > history tree and was a conversion from a check for group =3D=3D -1. That > commit changes from storing a group index to a group pointer so I think > it's roughly equivalent from a validity point of view. >=20 > The original group =3D=3D -1 check appears to be in the 2.6.32.x pvops > kernels at least, I expect it is also in the multiple tasklet patch > which you have as well? That's the point - we don't. >> One thing I wonder about in this context is whether the >> netif_stop_queue() call from xenvif_close() shouldn't happen before >> xenvif_down() (not the least for reasons of symmetry with >> xenvif_open()). >=20 > I seem to recall looking at that too, it was the same in the old kernels > too and I didn't know why so I avoided touching it (I was doing too much > other cleanup at the time to risk it). Understandable. Thanks for the really quick response, Jan _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel From xen-devel-bounces@lists.xensource.com Tue Sep 20 04:57:54 2011 Return-path: <xen-devel-bounces@lists.xensource.com> Envelope-to: www-data@lists.xensource.com Delivery-date: Tue, 20 Sep 2011 04:57:54 -0700 Received: from localhost ([127.0.0.1] helo=lists.colo.xensource.com) by lists.xensource.com with esmtp (Exim 4.43) id 1R5yxU-0006jb-5N; Tue, 20 Sep 2011 04:57:52 -0700 Received: from mail21.messagelabs.com ([85.158.143.35]) by lists.xensource.com with esmtp (Exim 4.43) id 1R5ywP-0006Vg-4j for xen-devel@lists.xensource.com; Tue, 20 Sep 2011 04:56:45 -0700 X-Env-Sender: JBeulich@suse.com X-Msg-Ref: server-7.tower-21.messagelabs.com!1316519771!55552450!1 X-Originating-IP: [130.57.49.28] X-StarScan-Version: 6.4.1; banners=-,-,- X-VirusChecked: Checked Received: (qmail 8693 invoked from network); 20 Sep 2011 11:56:11 -0000 Received: from nat28.tlf.novell.com (HELO nat28.tlf.novell.com) (130.57.49.28) by server-7.tower-21.messagelabs.com with DHE-RSA-AES256-SHA encrypted SMTP; 20 Sep 2011 11:56:11 -0000 Received: from EMEA1-MTA by nat28.tlf.novell.com with Novell_GroupWise; Tue, 20 Sep 2011 12:56:40 +0100 Message-Id: <4E789BB40200007800056C5A@nat28.tlf.novell.com> X-Mailer: Novell GroupWise Internet Agent 8.0.1 Date: Tue, 20 Sep 2011 12:57:08 +0100 From: "Jan Beulich" <JBeulich@suse.com> To: "Daniel Castro" <evil.dani@gmail.com> Subject: Re: [Xen-devel] Sched_op hypercall small questions References: <4E784FD502000078000769C5@nat28.tlf.novell.com> <CAP2B85_YdLJDaNoaimuDOJhQJ_1ogtDWYhUbg-Ycxd0R0dmd8A@mail.gmail.com> <4E7874180200007800056BF2@nat28.tlf.novell.com> <CAP2B85-ZUYdbkyEQHkM65gwKO4g-xV=k3O30FByw9DhA7vwmWg@mail.gmail.com> In-Reply-To: <CAP2B85-ZUYdbkyEQHkM65gwKO4g-xV=k3O30FByw9DhA7vwmWg@mail.gmail.com> Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: quoted-printable Content-Disposition: inline Cc: keir.xen@gmail.com, xen-devel@lists.xensource.com X-BeenThere: xen-devel@lists.xensource.com X-Mailman-Version: 2.1.5 Precedence: list List-Id: Xen developer discussion <xen-devel.lists.xensource.com> List-Unsubscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe> List-Post: <mailto:xen-devel@lists.xensource.com> List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help> List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=subscribe> Sender: xen-devel-bounces@lists.xensource.com Errors-To: xen-devel-bounces@lists.xensource.com >>> On 20.09.11 at 12:55, Daniel Castro <evil.dani@gmail.com> wrote: > What I am trying is writing to the xenstore ring, issue the send > hypercall, then wait (poll hypercall) for event, then read answer from > ring. That reads as if you do all this from the same thread in the same domain. Which might be your problem, particularly if additionally you use the same event channel for signaling production and consumption. > The waiting is not working, but If I wait enough time, the ring will > contain the answer, but apparently I have a problem with my event > channel port. So to test this theory I am using event channel status > hypercall, and I get: > Status 2 (meaning interdomain connected) > VCPU 0 > The Union reports dom 32752 and port 2. 32752 =3D=3D DOMID_SELF. And I can't see where the hypercall implementation would return DOMID_SELF here. > Right now, there are two things that jump to my mind, first when I > issue the poll hypercall the system continues execution, instead of > yielding CPU unitl event arrives. If it were never to arrive it should > yield infinitely, right? Without a timeout, yes. > Second, the bit is never set. Or it is being undone before I can check = it. That would need to be you to undo it. Jan _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel From xen-devel-bounces@lists.xensource.com Tue Sep 20 05:11:03 2011 Return-path: <xen-devel-bounces@lists.xensource.com> Envelope-to: www-data@lists.xensource.com Delivery-date: Tue, 20 Sep 2011 05:11:03 -0700 Received: from localhost ([127.0.0.1] helo=lists.colo.xensource.com) by lists.xensource.com with esmtp (Exim 4.43) id 1R5zAD-0007GZ-9o; Tue, 20 Sep 2011 05:11:02 -0700 Received: from mail174.messagelabs.com ([85.158.138.51]) by lists.xensource.com with esmtp (Exim 4.43) id 1R5z8r-00073o-QH for xen-devel@lists.xensource.com; Tue, 20 Sep 2011 05:09:47 -0700 X-Env-Sender: JBeulich@suse.com X-Msg-Ref: server-2.tower-174.messagelabs.com!1316520574!32109960!1 X-Originating-IP: [130.57.49.28] X-StarScan-Version: 6.4.1; banners=-,-,- X-VirusChecked: Checked Received: (qmail 2089 invoked from network); 20 Sep 2011 12:09:34 -0000 Received: from nat28.tlf.novell.com (HELO nat28.tlf.novell.com) (130.57.49.28) by server-2.tower-174.messagelabs.com with DHE-RSA-AES256-SHA encrypted SMTP; 20 Sep 2011 12:09:34 -0000 Received: from EMEA1-MTA by nat28.tlf.novell.com with Novell_GroupWise; Tue, 20 Sep 2011 13:09:33 +0100 Message-Id: <4E789EB80200007800056C68@nat28.tlf.novell.com> X-Mailer: Novell GroupWise Internet Agent 8.0.1 Date: Tue, 20 Sep 2011 13:10:00 +0100 From: "Jan Beulich" <JBeulich@suse.com> To: "Ian Campbell" <Ian.Campbell@eu.citrix.com> Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: quoted-printable Content-Disposition: inline Cc: DongxiaoXu <dongxiao.xu@intel.com>, "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com> Subject: [Xen-devel] Re: netback commit history X-BeenThere: xen-devel@lists.xensource.com X-Mailman-Version: 2.1.5 Precedence: list List-Id: Xen developer discussion <xen-devel.lists.xensource.com> List-Unsubscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe> List-Post: <mailto:xen-devel@lists.xensource.com> List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help> List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=subscribe> Sender: xen-devel-bounces@lists.xensource.com Errors-To: xen-devel-bounces@lists.xensource.com >>> On 20.09.11 at 13:26, Ian Campbell <Ian.Campbell@eu.citrix.com> wrote: > On Tue, 2011-09-20 at 12:04 +0100, Jan Beulich wrote: >> One thing I wonder about in this context is whether the >> netif_stop_queue() call from xenvif_close() shouldn't happen before >> xenvif_down() (not the least for reasons of symmetry with >> xenvif_open()). >=20 > I seem to recall looking at that too, it was the same in the old kernels > too and I didn't know why so I avoided touching it (I was doing too much > other cleanup at the time to risk it). After looking further I don't think that would help (though I still think it would be more correct), as netif_stop_queue() basically evaluates to a set_bit() without any other locks taken. So it's completely asynchronous wrt dev_hard_start_xmit() (and its callers, which are the ones looking at the bit with HARD_TX_LOCK() carried out). Jan _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel From xen-devel-bounces@lists.xensource.com Tue Sep 20 05:39:16 2011 Return-path: <xen-devel-bounces@lists.xensource.com> Envelope-to: www-data@lists.xensource.com Delivery-date: Tue, 20 Sep 2011 05:39:16 -0700 Received: from localhost ([127.0.0.1] helo=lists.colo.xensource.com) by lists.xensource.com with esmtp (Exim 4.43) id 1R5zbY-0000TB-59; Tue, 20 Sep 2011 05:39:16 -0700 Received: from mail21.messagelabs.com ([85.158.143.35]) by lists.xensource.com with esmtp (Exim 4.43) id 1R5zas-0000Ga-7l for xen-devel@lists.xensource.com; Tue, 20 Sep 2011 05:38:34 -0700 X-Env-Sender: JBeulich@suse.com X-Msg-Ref: server-8.tower-21.messagelabs.com!1316522295!59682016!1 X-Originating-IP: [130.57.49.28] X-StarScan-Version: 6.4.1; banners=-,-,- X-VirusChecked: Checked Received: (qmail 17541 invoked from network); 20 Sep 2011 12:38:15 -0000 Received: from nat28.tlf.novell.com (HELO nat28.tlf.novell.com) (130.57.49.28) by server-8.tower-21.messagelabs.com with DHE-RSA-AES256-SHA encrypted SMTP; 20 Sep 2011 12:38:15 -0000 Received: from EMEA1-MTA by nat28.tlf.novell.com with Novell_GroupWise; Tue, 20 Sep 2011 13:38:30 +0100 Message-Id: <4E78A5810200007800056C80@nat28.tlf.novell.com> X-Mailer: Novell GroupWise Internet Agent 8.0.1 Date: Tue, 20 Sep 2011 13:38:57 +0100 From: "Jan Beulich" <JBeulich@suse.com> To: "Ian Campbell" <Ian.Campbell@eu.citrix.com> References: <4E789EB80200007800056C68@nat28.tlf.novell.com> In-Reply-To: <4E789EB80200007800056C68@nat28.tlf.novell.com> Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: quoted-printable Content-Disposition: inline Cc: DongxiaoXu <dongxiao.xu@intel.com>, "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com> Subject: [Xen-devel] Re: netback commit history X-BeenThere: xen-devel@lists.xensource.com X-Mailman-Version: 2.1.5 Precedence: list List-Id: Xen developer discussion <xen-devel.lists.xensource.com> List-Unsubscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe> List-Post: <mailto:xen-devel@lists.xensource.com> List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help> List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=subscribe> Sender: xen-devel-bounces@lists.xensource.com Errors-To: xen-devel-bounces@lists.xensource.com >>> On 20.09.11 at 14:10, "Jan Beulich" <JBeulich@suse.com> wrote: >>>> On 20.09.11 at 13:26, Ian Campbell <Ian.Campbell@eu.citrix.com> = wrote: >> On Tue, 2011-09-20 at 12:04 +0100, Jan Beulich wrote: >>> One thing I wonder about in this context is whether the >>> netif_stop_queue() call from xenvif_close() shouldn't happen before >>> xenvif_down() (not the least for reasons of symmetry with >>> xenvif_open()). >>=20 >> I seem to recall looking at that too, it was the same in the old = kernels >> too and I didn't know why so I avoided touching it (I was doing too = much >> other cleanup at the time to risk it). >=20 > After looking further I don't think that would help (though I still = think > it would be more correct), as netif_stop_queue() basically evaluates > to a set_bit() without any other locks taken. So it's completely > asynchronous wrt dev_hard_start_xmit() (and its callers, which are > the ones looking at the bit with HARD_TX_LOCK() carried out). Which in turn suggests that the upstream driver isn't safe either: There's nothing preventing vif->netbk from becoming NULL between the early check in xenvif_start_xmit() and its actual use in xen_netbk_queue_tx_skb(). I think vif->netbk needs to be latched into a local variable, checked against NULL, and passed instead of vif to xen_netbk_queue_tx_skb(). Jan _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel From xen-devel-bounces@lists.xensource.com Tue Sep 20 05:40:56 2011 Return-path: <xen-devel-bounces@lists.xensource.com> Envelope-to: www-data@lists.xensource.com Delivery-date: Tue, 20 Sep 2011 05:40:56 -0700 Received: from localhost ([127.0.0.1] helo=lists.colo.xensource.com) by lists.xensource.com with esmtp (Exim 4.43) id 1R5zdA-0000rD-0z; Tue, 20 Sep 2011 05:40:56 -0700 Received: from mail21.messagelabs.com ([85.158.143.35]) by lists.xensource.com with esmtp (Exim 4.43) id 1R5zcb-0000fM-RS for xen-devel@lists.xensource.com; Tue, 20 Sep 2011 05:40:22 -0700 X-Env-Sender: evil.dani@gmail.com X-Msg-Ref: server-8.tower-21.messagelabs.com!1316522402!59682352!1 X-Originating-IP: [209.85.161.43] X-StarScan-Version: 6.4.1; banners=-,-,- X-VirusChecked: Checked Received: (qmail 29134 invoked from network); 20 Sep 2011 12:40:02 -0000 Received: from mail-fx0-f43.google.com (HELO mail-fx0-f43.google.com) (209.85.161.43) by server-8.tower-21.messagelabs.com with RC4-SHA encrypted SMTP; 20 Sep 2011 12:40:02 -0000 Received: by fxh19 with SMTP id 19so738497fxh.30 for <xen-devel@lists.xensource.com>; Tue, 20 Sep 2011 05:40:18 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; bh=d3XSMhM2CxHKFcjH56w90PlMXdas47+/UeoXK/bENrw=; b=HX3E73w2gG2+l4xIBGaKfckGgH+hcxzR3R9yK+8FBakHeJ/5j+iQFR0NB4Q6uhftFR mLWDPKzSX+W3wv2WqUFtYcE+67UEjug/P2brTtxC+d+ChLwkGYJ1SQZLOJ4vOvC4ZXzI qBNZm6ma+Hi3nwaYEX+RzxsAtedeThsddI86Q= MIME-Version: 1.0 Received: by 10.223.75.24 with SMTP id w24mr1201562faj.132.1316522122701; Tue, 20 Sep 2011 05:35:22 -0700 (PDT) Received: by 10.223.97.9 with HTTP; Tue, 20 Sep 2011 05:35:22 -0700 (PDT) In-Reply-To: <4E789BB40200007800056C5A@nat28.tlf.novell.com> References: <4E784FD502000078000769C5@nat28.tlf.novell.com> <CAP2B85_YdLJDaNoaimuDOJhQJ_1ogtDWYhUbg-Ycxd0R0dmd8A@mail.gmail.com> <4E7874180200007800056BF2@nat28.tlf.novell.com> <CAP2B85-ZUYdbkyEQHkM65gwKO4g-xV=k3O30FByw9DhA7vwmWg@mail.gmail.com> <4E789BB40200007800056C5A@nat28.tlf.novell.com> Date: Tue, 20 Sep 2011 21:35:22 +0900 Message-ID: <CAP2B858pzXrqSxkcNwHAg5ZPNtAmAeMOSucmgiFDZwZKfbJRHQ@mail.gmail.com> Subject: Re: [Xen-devel] Sched_op hypercall small questions From: Daniel Castro <evil.dani@gmail.com> To: Jan Beulich <JBeulich@suse.com> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: keir.xen@gmail.com, xen-devel@lists.xensource.com X-BeenThere: xen-devel@lists.xensource.com X-Mailman-Version: 2.1.5 Precedence: list List-Id: Xen developer discussion <xen-devel.lists.xensource.com> List-Unsubscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe> List-Post: <mailto:xen-devel@lists.xensource.com> List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help> List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=subscribe> Sender: xen-devel-bounces@lists.xensource.com Errors-To: xen-devel-bounces@lists.xensource.com On Tue, Sep 20, 2011 at 8:57 PM, Jan Beulich <JBeulich@suse.com> wrote: >>>> On 20.09.11 at 12:55, Daniel Castro <evil.dani@gmail.com> wrote: >> What I am trying is writing to the xenstore ring, issue the send >> hypercall, then wait (poll hypercall) for event, then read answer from >> ring. > > That reads as if you do all this from the same thread in the same domain. > Which might be your problem, particularly if additionally you use the > same event channel for signaling production and consumption. Yes you are correct, I have all in the same thread. But I have no other choice, since this is run inside hvmloader when the BIOS is being deployed. >> The waiting is not working, but If I wait enough time, the ring will >> contain the answer, but apparently I have a problem with my event >> channel port. So to test this theory I am using event channel status >> hypercall, and I get: >> Status 2 (meaning interdomain connected) >> VCPU 0 >> The Union reports dom 32752 and port 2. > > 32752 =3D=3D DOMID_SELF. And I can't see where the hypercall > implementation would return DOMID_SELF here. Sorry I had a coding error, but it is corrected (I did not call the union correctly, so I ended up calling dom in the main struct). Anyway here is the output corrected: Xenbus rings @0xfeffc000, event channel 2 Event Chn 2 Status 2 VCPU 0. Event is interdomain (2) union dom 983040 union port 42 Thanks, Daniel > >> Right now, there are two things that jump to my mind, first when I >> issue the poll hypercall the system continues execution, instead of >> yielding CPU unitl event arrives. If it were never to arrive it should >> yield infinitely, right? > > Without a timeout, yes. > >> Second, the bit is never set. Or it is being undone before I can check i= t. > > That would need to be you to undo it. > > Jan > > --=20 +-=3D=3D=3D=3D=3D---------------------------+ | +---------------------------------+ | This space intentionally blank for notetaking. | |=A0=A0 | Daniel Castro,=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 | | |=A0=A0 | Consultant/Programmer.| | |=A0=A0 | U Andes=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0=A0 | +-------------------------------------+ _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel From xen-devel-bounces@lists.xensource.com Tue Sep 20 05:42:00 2011 Return-path: <xen-devel-bounces@lists.xensource.com> Envelope-to: www-data@lists.xensource.com Delivery-date: Tue, 20 Sep 2011 05:42:00 -0700 Received: from localhost ([127.0.0.1] helo=lists.colo.xensource.com) by lists.xensource.com with esmtp (Exim 4.43) id 1R5zeC-0001EQ-QT; Tue, 20 Sep 2011 05:42:00 -0700 Received: from mail27.messagelabs.com ([193.109.254.147]) by lists.xensource.com with esmtp (Exim 4.43) id 1R5zd2-0000nt-V1 for xen-devel@lists.xensource.com; Tue, 20 Sep 2011 05:40:49 -0700 X-Env-Sender: Ian.Campbell@eu.citrix.com X-Msg-Ref: server-8.tower-27.messagelabs.com!1316522429!47361548!1 X-Originating-IP: [62.200.22.115] X-StarScan-Version: 6.4.1; banners=-,-,- X-VirusChecked: Checked Received: (qmail 17130 invoked from network); 20 Sep 2011 12:40:30 -0000 Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115) by server-8.tower-27.messagelabs.com with RC4-SHA encrypted SMTP; 20 Sep 2011 12:40:30 -0000 X-IronPort-AV: E=Sophos;i="4.68,411,1312156800"; d="scan'208";a="7952040" Received: from lonpmailmx01.citrite.net ([10.30.203.162]) by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5; 20 Sep 2011 12:40:20 +0000 Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net (10.30.203.162) with Microsoft SMTP Server id 8.3.137.0; Tue, 20 Sep 2011 13:40:21 +0100 From: Ian Campbell <Ian.Campbell@eu.citrix.com> To: Jan Beulich <JBeulich@suse.com> Date: Tue, 20 Sep 2011 13:40:20 +0100 In-Reply-To: <4E78992D0200007800056C4F@nat28.tlf.novell.com> References: <4E788F710200007800056C38@nat28.tlf.novell.com> <1316518018.3891.38.camel@zakaz.uk.xensource.com> <4E78992D0200007800056C4F@nat28.tlf.novell.com> Organization: Citrix Systems, Inc. Content-Type: text/plain; charset="UTF-8" X-Mailer: Evolution 3.0.3- Content-Transfer-Encoding: 7bit Message-ID: <1316522420.3891.43.camel@zakaz.uk.xensource.com> MIME-Version: 1.0 Cc: DongxiaoXu <dongxiao.xu@intel.com>, "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com> Subject: [Xen-devel] Re: netback commit history X-BeenThere: xen-devel@lists.xensource.com X-Mailman-Version: 2.1.5 Precedence: list List-Id: Xen developer discussion <xen-devel.lists.xensource.com> List-Unsubscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe> List-Post: <mailto:xen-devel@lists.xensource.com> List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help> List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=subscribe> Sender: xen-devel-bounces@lists.xensource.com Errors-To: xen-devel-bounces@lists.xensource.com On Tue, 2011-09-20 at 12:46 +0100, Jan Beulich wrote: > >>> On 20.09.11 at 13:26, Ian Campbell <Ian.Campbell@eu.citrix.com> wrote: > > On Tue, 2011-09-20 at 12:04 +0100, Jan Beulich wrote: > >> with the upstream netback introduction consisting of a single big commit > >> I wonder whether you could point me to where the full history of it is. > > > > Yeah, that was a bit annoying, luckily I had the foresight to post where > > the history was. http://www.gossamer-threads.com/lists/xen/devel/202139 > > says it is: > > git://xenbits.xen.org/people/ianc/linux-2.6.git > > upstream/dom0/backend/netback-history > > Does this have a http:// representation somewhere (it doesn't show up > under http://xenbits.xen.org/people/ianc/)? http://xenbits.xen.org/gitweb/?p=people/ianc/linux-2.6.git;a=summary > > >> I'm asking particularly in the context of us being asked to add a safety > >> check similar to the vif->netbk != NULL one at the beginning of > >> xenvif_start_xmit() (also in xenvif_interrupt(), but there we have a > >> similar check in place), which hadn't been in the legacy tree (obviously) > >> nor in the original multiple-tasklets patch that I retained a copy of. > > > > Seems to have come from bc05ada1283eb583c9789c27429af36b034c4a74 in that > > history tree and was a conversion from a check for group == -1. That > > commit changes from storing a group index to a group pointer so I think > > it's roughly equivalent from a validity point of view. > > > > The original group == -1 check appears to be in the 2.6.32.x pvops > > kernels at least, I expect it is also in the multiple tasklet patch > > which you have as well? > > That's the point - we don't. Wierd, it is in 020ba9067e121b720a3335521698ea9cf31f6166 in Jeremy's xen/2.6.32-stable branch which is the original "xen/netback: Multiple tasklets support." commit. Did you pick up an earlier posting? I found the original postings v2: http://lists.xensource.com/archives/html/xen-devel/2010-04/msg01578.html v3: http://www.gossamer-threads.com/lists/xen/devel/170582 v4: http://lists.xensource.com/archives/html/xen-devel/2010-05/msg00140.html >From the looks things the check arrived in v3 but there is no comment on the patch saying why, nor does any review I found of v2 give a hint. I had a bit of a trawl through various list archives of the other postings of the series but didn't spot anything. > >> One thing I wonder about in this context is whether the > >> netif_stop_queue() call from xenvif_close() shouldn't happen before > >> xenvif_down() (not the least for reasons of symmetry with > >> xenvif_open()). > > > > I seem to recall looking at that too, it was the same in the old kernels > > too and I didn't know why so I avoided touching it (I was doing too much > > other cleanup at the time to risk it). > > Understandable. > > Thanks for the really quick response, > Jan > _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel From xen-devel-bounces@lists.xensource.com Tue Sep 20 05:54:12 2011 Return-path: <xen-devel-bounces@lists.xensource.com> Envelope-to: www-data@lists.xensource.com Delivery-date: Tue, 20 Sep 2011 05:54:12 -0700 Received: from localhost ([127.0.0.1] helo=lists.colo.xensource.com) by lists.xensource.com with esmtp (Exim 4.43) id 1R5zq0-0001sN-L9; Tue, 20 Sep 2011 05:54:12 -0700 Received: from mail216.messagelabs.com ([85.158.143.99]) by lists.xensource.com with esmtp (Exim 4.43) id 1R5zpB-0001ff-Fl for xen-devel@lists.xensource.com; Tue, 20 Sep 2011 05:53:21 -0700 X-Env-Sender: Ian.Campbell@eu.citrix.com X-Msg-Ref: server-10.tower-216.messagelabs.com!1316523198!10870781!1 X-Originating-IP: [62.200.22.115] X-StarScan-Version: 6.4.1; banners=-,-,- X-VirusChecked: Checked Received: (qmail 31386 invoked from network); 20 Sep 2011 12:53:18 -0000 Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115) by server-10.tower-216.messagelabs.com with RC4-SHA encrypted SMTP; 20 Sep 2011 12:53:18 -0000 X-IronPort-AV: E=Sophos;i="4.68,411,1312156800"; d="scan'208";a="7952442" Received: from lonpmailmx01.citrite.net ([10.30.203.162]) by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5; 20 Sep 2011 12:53: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.137.0; Tue, 20 Sep 2011 13:53:18 +0100 Subject: Re: [Xen-devel] Sched_op hypercall small questions From: Ian Campbell <Ian.Campbell@citrix.com> To: Jan Beulich <JBeulich@suse.com> Date: Tue, 20 Sep 2011 13:53:18 +0100 In-Reply-To: <4E789BB40200007800056C5A@nat28.tlf.novell.com> References: <4E784FD502000078000769C5@nat28.tlf.novell.com> <CAP2B85_YdLJDaNoaimuDOJhQJ_1ogtDWYhUbg-Ycxd0R0dmd8A@mail.gmail.com> <4E7874180200007800056BF2@nat28.tlf.novell.com> <CAP2B85-ZUYdbkyEQHkM65gwKO4g-xV=k3O30FByw9DhA7vwmWg@mail.gmail.com> <4E789BB40200007800056C5A@nat28.tlf.novell.com> Organization: Citrix Systems, Inc. Content-Type: text/plain; charset="UTF-8" X-Mailer: Evolution 3.0.3- Content-Transfer-Encoding: 7bit Message-ID: <1316523198.3891.51.camel@zakaz.uk.xensource.com> MIME-Version: 1.0 Cc: Daniel Castro <evil.dani@gmail.com>, "keir.xen@gmail.com" <keir.xen@gmail.com>, "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com> X-BeenThere: xen-devel@lists.xensource.com X-Mailman-Version: 2.1.5 Precedence: list List-Id: Xen developer discussion <xen-devel.lists.xensource.com> List-Unsubscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe> List-Post: <mailto:xen-devel@lists.xensource.com> List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help> List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=subscribe> Sender: xen-devel-bounces@lists.xensource.com Errors-To: xen-devel-bounces@lists.xensource.com On Tue, 2011-09-20 at 12:57 +0100, Jan Beulich wrote: > > > The waiting is not working, but If I wait enough time, the ring will > > contain the answer, but apparently I have a problem with my event > > channel port. So to test this theory I am using event channel status > > hypercall, and I get: > > Status 2 (meaning interdomain connected) > > VCPU 0 > > The Union reports dom 32752 and port 2. You can also use lsevtchn in dom0, it lives in the /usr/lib/xen/bin dir. You can give it a domid and therefore check that you can see both ends look sane e.g. if I run it on an hvm domain I see: # lsevtchn 3 1: VCPU 0: Interdomain (Connected) - Remote Domain 0, Port 51 2: VCPU 1: Interdomain (Connected) - Remote Domain 0, Port 52 3: VCPU 0: Interdomain (Connected) - Remote Domain 0, Port 49 4: VCPU 0: Interdomain (Connected) - Remote Domain 0, Port 50 and in dom0 I see: # lsevtchn 0 | grep Domain.3 49: VCPU 0: Interdomain (Connected) - Remote Domain 3, Port 3 50: VCPU 0: Interdomain (Connected) - Remote Domain 3, Port 4 51: VCPU 3: Interdomain (Connected) - Remote Domain 3, Port 1 52: VCPU 3: Interdomain (Connected) - Remote Domain 3, Port 2 i.e. everything matches up. > 32752 == DOMID_SELF. And I can't see where the hypercall > implementation would return DOMID_SELF here. Daniel, are you 100% sure you are printing/looking at evtchn_status_t->u.interdomain.dom and not evtchn_status_t->dom? Oh wait, you discovered that you weren't already. Ian. _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel From xen-devel-bounces@lists.xensource.com Tue Sep 20 05:55:31 2011 Return-path: <xen-devel-bounces@lists.xensource.com> Envelope-to: www-data@lists.xensource.com Delivery-date: Tue, 20 Sep 2011 05:55:31 -0700 Received: from localhost ([127.0.0.1] helo=lists.colo.xensource.com) by lists.xensource.com with esmtp (Exim 4.43) id 1R5zrH-0002G9-0i; Tue, 20 Sep 2011 05:55:31 -0700 Received: from mail174.messagelabs.com ([85.158.138.51]) by lists.xensource.com with esmtp (Exim 4.43) id 1R5zqf-00021t-K8 for xen-devel@lists.xensource.com; Tue, 20 Sep 2011 05:54:53 -0700 X-Env-Sender: Ian.Campbell@eu.citrix.com X-Msg-Ref: server-9.tower-174.messagelabs.com!1316523290!26080119!1 X-Originating-IP: [62.200.22.115] X-StarScan-Version: 6.4.1; banners=-,-,- X-VirusChecked: Checked Received: (qmail 30011 invoked from network); 20 Sep 2011 12:54:50 -0000 Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115) by server-9.tower-174.messagelabs.com with RC4-SHA encrypted SMTP; 20 Sep 2011 12:54:50 -0000 X-IronPort-AV: E=Sophos;i="4.68,411,1312156800"; d="scan'208";a="7952511" Received: from lonpmailmx01.citrite.net ([10.30.203.162]) by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5; 20 Sep 2011 12:54:49 +0000 Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net (10.30.203.162) with Microsoft SMTP Server id 8.3.137.0; Tue, 20 Sep 2011 13:54:49 +0100 Subject: Re: [Xen-devel] Sched_op hypercall small questions From: Ian Campbell <Ian.Campbell@citrix.com> To: Daniel Castro <evil.dani@gmail.com> Date: Tue, 20 Sep 2011 13:54:49 +0100 In-Reply-To: <CAP2B858pzXrqSxkcNwHAg5ZPNtAmAeMOSucmgiFDZwZKfbJRHQ@mail.gmail.com> References: <4E784FD502000078000769C5@nat28.tlf.novell.com> <CAP2B85_YdLJDaNoaimuDOJhQJ_1ogtDWYhUbg-Ycxd0R0dmd8A@mail.gmail.com> <4E7874180200007800056BF2@nat28.tlf.novell.com> <CAP2B85-ZUYdbkyEQHkM65gwKO4g-xV=k3O30FByw9DhA7vwmWg@mail.gmail.com> <4E789BB40200007800056C5A@nat28.tlf.novell.com> <CAP2B858pzXrqSxkcNwHAg5ZPNtAmAeMOSucmgiFDZwZKfbJRHQ@mail.gmail.com> Organization: Citrix Systems, Inc. Content-Type: text/plain; charset="UTF-8" X-Mailer: Evolution 3.0.3- Content-Transfer-Encoding: 7bit Message-ID: <1316523289.3891.53.camel@zakaz.uk.xensource.com> MIME-Version: 1.0 Cc: "keir.xen@gmail.com" <keir.xen@gmail.com>, "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>, Jan Beulich <JBeulich@suse.com> X-BeenThere: xen-devel@lists.xensource.com X-Mailman-Version: 2.1.5 Precedence: list List-Id: Xen developer discussion <xen-devel.lists.xensource.com> List-Unsubscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe> List-Post: <mailto:xen-devel@lists.xensource.com> List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help> List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=subscribe> Sender: xen-devel-bounces@lists.xensource.com Errors-To: xen-devel-bounces@lists.xensource.com On Tue, 2011-09-20 at 13:35 +0100, Daniel Castro wrote: > On Tue, Sep 20, 2011 at 8:57 PM, Jan Beulich <JBeulich@suse.com> wrote: > > 32752 == DOMID_SELF. And I can't see where the hypercall > > implementation would return DOMID_SELF here. > Sorry I had a coding error, but it is corrected (I did not call the > union correctly, so I ended up calling dom in the main struct). > Anyway here is the output corrected: > Xenbus rings @0xfeffc000, event channel 2 > Event Chn 2 Status 2 VCPU 0. > Event is interdomain (2) union dom 983040 union port 42 That's dom 0xf0000 but domid_t is a 16 bit value so there's no way you really have that value -- I think you must have used the wrong printf format specifier. The lower 16 bits are 0 which makes sense. You could confirm using lsevtchn. Ian. _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel From xen-devel-bounces@lists.xensource.com Tue Sep 20 05:56:37 2011 Return-path: <xen-devel-bounces@lists.xensource.com> Envelope-to: www-data@lists.xensource.com Delivery-date: Tue, 20 Sep 2011 05:56:37 -0700 Received: from localhost ([127.0.0.1] helo=lists.colo.xensource.com) by lists.xensource.com with esmtp (Exim 4.43) id 1R5zsK-0002d9-UB; Tue, 20 Sep 2011 05:56:36 -0700 Received: from mail216.messagelabs.com ([85.158.143.99]) by lists.xensource.com with esmtp (Exim 4.43) id 1R5zra-0002Og-NQ for xen-devel@lists.xensource.com; Tue, 20 Sep 2011 05:55:51 -0700 X-Env-Sender: JBeulich@suse.com X-Msg-Ref: server-8.tower-216.messagelabs.com!1316523214!17380886!1 X-Originating-IP: [130.57.49.28] X-StarScan-Version: 6.4.1; banners=-,-,- X-VirusChecked: Checked Received: (qmail 27803 invoked from network); 20 Sep 2011 12:53:34 -0000 Received: from nat28.tlf.novell.com (HELO nat28.tlf.novell.com) (130.57.49.28) by server-8.tower-216.messagelabs.com with DHE-RSA-AES256-SHA encrypted SMTP; 20 Sep 2011 12:53:34 -0000 Received: from EMEA1-MTA by nat28.tlf.novell.com with Novell_GroupWise; Tue, 20 Sep 2011 13:53:33 +0100 Message-Id: <4E78A9080200007800056CA1@nat28.tlf.novell.com> X-Mailer: Novell GroupWise Internet Agent 8.0.1 Date: Tue, 20 Sep 2011 13:54:00 +0100 From: "Jan Beulich" <JBeulich@suse.com> To: "Daniel Castro" <evil.dani@gmail.com> Subject: Re: [Xen-devel] Sched_op hypercall small questions References: <4E784FD502000078000769C5@nat28.tlf.novell.com> <CAP2B85_YdLJDaNoaimuDOJhQJ_1ogtDWYhUbg-Ycxd0R0dmd8A@mail.gmail.com> <4E7874180200007800056BF2@nat28.tlf.novell.com> <CAP2B85-ZUYdbkyEQHkM65gwKO4g-xV=k3O30FByw9DhA7vwmWg@mail.gmail.com> <4E789BB40200007800056C5A@nat28.tlf.novell.com> <CAP2B858pzXrqSxkcNwHAg5ZPNtAmAeMOSucmgiFDZwZKfbJRHQ@mail.gmail.com> In-Reply-To: <CAP2B858pzXrqSxkcNwHAg5ZPNtAmAeMOSucmgiFDZwZKfbJRHQ@mail.gmail.com> Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: quoted-printable Content-Disposition: inline Cc: keir.xen@gmail.com, xen-devel@lists.xensource.com X-BeenThere: xen-devel@lists.xensource.com X-Mailman-Version: 2.1.5 Precedence: list List-Id: Xen developer discussion <xen-devel.lists.xensource.com> List-Unsubscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe> List-Post: <mailto:xen-devel@lists.xensource.com> List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help> List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=subscribe> Sender: xen-devel-bounces@lists.xensource.com Errors-To: xen-devel-bounces@lists.xensource.com >>> On 20.09.11 at 14:35, Daniel Castro <evil.dani@gmail.com> wrote: > On Tue, Sep 20, 2011 at 8:57 PM, Jan Beulich <JBeulich@suse.com> wrote: >>>>> On 20.09.11 at 12:55, Daniel Castro <evil.dani@gmail.com> wrote: >>> What I am trying is writing to the xenstore ring, issue the send >>> hypercall, then wait (poll hypercall) for event, then read answer from >>> ring. >> >> That reads as if you do all this from the same thread in the same = domain. >> Which might be your problem, particularly if additionally you use the >> same event channel for signaling production and consumption. >=20 > Yes you are correct, I have all in the same thread. But I have no > other choice, since this is run inside hvmloader when the BIOS is > being deployed. What do you need the synchronization/signaling/polling for then? Jan _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel From xen-devel-bounces@lists.xensource.com Tue Sep 20 06:04:47 2011 Return-path: <xen-devel-bounces@lists.xensource.com> Envelope-to: www-data@lists.xensource.com Delivery-date: Tue, 20 Sep 2011 06:04:47 -0700 Received: from localhost ([127.0.0.1] helo=lists.colo.xensource.com) by lists.xensource.com with esmtp (Exim 4.43) id 1R600E-00038s-SM; Tue, 20 Sep 2011 06:04:46 -0700 Received: from mail216.messagelabs.com ([85.158.143.99]) by lists.xensource.com with esmtp (Exim 4.43) id 1R5zyj-0002vY-Ku for xen-devel@lists.xensource.com; Tue, 20 Sep 2011 06:03:22 -0700 X-Env-Sender: JBeulich@suse.com X-Msg-Ref: server-10.tower-216.messagelabs.com!1316523790!10872565!1 X-Originating-IP: [130.57.49.28] X-StarScan-Version: 6.4.1; banners=-,-,- X-VirusChecked: Checked Received: (qmail 30648 invoked from network); 20 Sep 2011 13:03:10 -0000 Received: from nat28.tlf.novell.com (HELO nat28.tlf.novell.com) (130.57.49.28) by server-10.tower-216.messagelabs.com with DHE-RSA-AES256-SHA encrypted SMTP; 20 Sep 2011 13:03:10 -0000 Received: from EMEA1-MTA by nat28.tlf.novell.com with Novell_GroupWise; Tue, 20 Sep 2011 14:03:09 +0100 Message-Id: <4E78AB480200007800056CBB@nat28.tlf.novell.com> X-Mailer: Novell GroupWise Internet Agent 8.0.1 Date: Tue, 20 Sep 2011 14:03:36 +0100 From: "Jan Beulich" <JBeulich@suse.com> To: "Ian Campbell" <Ian.Campbell@eu.citrix.com> References: <4E788F710200007800056C38@nat28.tlf.novell.com> <1316518018.3891.38.camel@zakaz.uk.xensource.com> <4E78992D0200007800056C4F@nat28.tlf.novell.com> <1316522420.3891.43.camel@zakaz.uk.xensource.com> In-Reply-To: <1316522420.3891.43.camel@zakaz.uk.xensource.com> Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: quoted-printable Content-Disposition: inline Cc: DongxiaoXu <dongxiao.xu@intel.com>, "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com> Subject: [Xen-devel] Re: netback commit history X-BeenThere: xen-devel@lists.xensource.com X-Mailman-Version: 2.1.5 Precedence: list List-Id: Xen developer discussion <xen-devel.lists.xensource.com> List-Unsubscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe> List-Post: <mailto:xen-devel@lists.xensource.com> List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help> List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=subscribe> Sender: xen-devel-bounces@lists.xensource.com Errors-To: xen-devel-bounces@lists.xensource.com >>> On 20.09.11 at 14:40, Ian Campbell <Ian.Campbell@eu.citrix.com> wrote: > On Tue, 2011-09-20 at 12:46 +0100, Jan Beulich wrote: >> >>> On 20.09.11 at 13:26, Ian Campbell <Ian.Campbell@eu.citrix.com> = wrote: >> > On Tue, 2011-09-20 at 12:04 +0100, Jan Beulich wrote: >> >> with the upstream netback introduction consisting of a single big = commit >> >> I wonder whether you could point me to where the full history of it = is. >> >=20 >> > Yeah, that was a bit annoying, luckily I had the foresight to post = where >> > the history was. http://www.gossamer-threads.com/lists/xen/devel/20213= 9=20 >> > says it is: >> > git://xenbits.xen.org/people/ianc/linux-2.6.git=20 >> > upstream/dom0/backend/netback-history=20 >>=20 >> Does this have a http:// representation somewhere (it doesn't show up >> under http://xenbits.xen.org/people/ianc/)?=20 >=20 > http://xenbits.xen.org/gitweb/?p=3Dpeople/ianc/linux-2.6.git;a=3Dsummary= =20 >=20 >>=20 >> >> I'm asking particularly in the context of us being asked to add a = safety >> >> check similar to the vif->netbk !=3D NULL one at the beginning of >> >> xenvif_start_xmit() (also in xenvif_interrupt(), but there we have a >> >> similar check in place), which hadn't been in the legacy tree = (obviously) >> >> nor in the original multiple-tasklets patch that I retained a copy = of. >> >=20 >> > Seems to have come from bc05ada1283eb583c9789c27429af36b034c4a74 in = that >> > history tree and was a conversion from a check for group =3D=3D -1. = That >> > commit changes from storing a group index to a group pointer so I = think >> > it's roughly equivalent from a validity point of view. >> >=20 >> > The original group =3D=3D -1 check appears to be in the 2.6.32.x = pvops >> > kernels at least, I expect it is also in the multiple tasklet patch >> > which you have as well? >>=20 >> That's the point - we don't. >=20 > Wierd, it is in 020ba9067e121b720a3335521698ea9cf31f6166 in Jeremy's > xen/2.6.32-stable branch which is the original "xen/netback: Multiple > tasklets support." commit. Did you pick up an earlier posting? >=20 > I found the original postings > v2: http://lists.xensource.com/archives/html/xen-devel/2010-04/msg01578.h= tml=20 > v3: http://www.gossamer-threads.com/lists/xen/devel/170582=20 > v4: http://lists.xensource.com/archives/html/xen-devel/2010-05/msg00140.h= tml=20 >=20 > From the looks things the check arrived in v3 but there is no comment on > the patch saying why, nor does any review I found of v2 give a hint. I > had a bit of a trawl through various list archives of the other postings > of the series but didn't spot anything. Seems like my original is actually v1, and I may not have picked up that later change precisely because it wasn't mentioned in the description and I didn't look closely enough at the changes plus I had done quite a bit of other cleanup on v1 already and hence didn't want to start over. v3 is also where the similar check in netif_be_int() appears, and I know for sure we had to add this due to another bug report, not due to the change there. In any case, thanks a lot for helping with this! Jan _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel From xen-devel-bounces@lists.xensource.com Tue Sep 20 06:42:18 2011 Return-path: <xen-devel-bounces@lists.xensource.com> Envelope-to: www-data@lists.xensource.com Delivery-date: Tue, 20 Sep 2011 06:42:18 -0700 Received: from localhost ([127.0.0.1] helo=lists.colo.xensource.com) by lists.xensource.com with esmtp (Exim 4.43) id 1R60aW-000481-Ds; Tue, 20 Sep 2011 06:42:16 -0700 Received: from mail21.messagelabs.com ([85.158.143.35]) by lists.xensource.com with smtp (Exim 4.43) id 1R60ZU-0003vL-GA for xen-devel@lists.xensource.com; Tue, 20 Sep 2011 06:41:17 -0700 X-Env-Sender: ijc@hellion.org.uk X-Msg-Ref: server-7.tower-21.messagelabs.com!1316526039!55570894!1 X-Originating-IP: [80.68.92.230] X-StarScan-Version: 6.4.1; banners=-,-,- X-VirusChecked: Checked Received: (qmail 4267 invoked from network); 20 Sep 2011 13:40:39 -0000 Received: from aaar.vm.bytemark.co.uk (HELO aaar.vm.bytemark.co.uk) (80.68.92.230) by server-7.tower-21.messagelabs.com with SMTP; 20 Sep 2011 13:40:39 -0000 Received: from localhost (unknown [127.0.0.1]) by aaar.vm.bytemark.co.uk (Postfix) with ESMTP id 3F7DE13BE53; Tue, 20 Sep 2011 13:41:06 +0000 (UTC) Received: from aaar.vm.bytemark.co.uk ([127.0.0.1]) by localhost (aaar.vm.bytemark.co.uk [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cJcyZ1RshEkQ; Tue, 20 Sep 2011 14:41:04 +0100 (BST) Received: from hopkins.hellion.org.uk (cpc2-cmbg14-2-0-cust125.5-4.cable.virginmedia.com [86.26.0.126]) (using TLSv1 with cipher AES256-SHA (256/256 bits)) (No client certificate requested) by aaar.vm.bytemark.co.uk (Postfix) with ESMTP id 014EA139F18; Tue, 20 Sep 2011 14:41:04 +0100 (BST) Received: from firewall.ctxuk.citrix.com ([62.200.22.2] helo=[10.80.2.42]) by hopkins.hellion.org.uk with esmtpsa (SSL3.0:RSA_AES_256_CBC_SHA1:32) (Exim 4.72) (envelope-from <ijc@hellion.org.uk>) id 1R60ZG-0006x1-PU; Tue, 20 Sep 2011 14:41:01 +0100 From: Ian Campbell <ijc@hellion.org.uk> To: Ben Hutchings <ben@decadent.org.uk> Date: Tue, 20 Sep 2011 14:40:51 +0100 In-Reply-To: <1316524835.4122.8.camel@deadeye> References: <20110919210045.3256.61939.reportbug@xen-dom0.xen.irush.su> <20110919212211.GB6343@elie> <CA+rvmvK8G5hNq4wOkPdcDMufYS9bD559zvexMqG9gy=m7dkU_A@mail.gmail.com> <1316524835.4122.8.camel@deadeye> Content-Type: text/plain; charset="UTF-8" X-Mailer: Evolution 3.0.3- Content-Transfer-Encoding: 7bit Message-ID: <1316526058.3891.65.camel@zakaz.uk.xensource.com> Mime-Version: 1.0 X-SA-Exim-Connect-IP: 62.200.22.2 X-SA-Exim-Mail-From: ijc@hellion.org.uk X-SA-Exim-Version: 4.2.1 (built Mon, 22 Mar 2010 06:51:10 +0000) X-SA-Exim-Scanned: Yes (on hopkins.hellion.org.uk) Cc: Jonathan Nieder <jrnieder@gmail.com>, 642154@bugs.debian.org, xen-devel <xen-devel@lists.xensource.com>, Konrad Rzeszutek Wilk <konrad.wilk@oracle.com> Subject: [Xen-devel] Re: Bug#642154: BUG: unable to handle kernel paging request at ffff8803bb6ad000 X-BeenThere: xen-devel@lists.xensource.com X-Mailman-Version: 2.1.5 Precedence: list List-Id: Xen developer discussion <xen-devel.lists.xensource.com> List-Unsubscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe> List-Post: <mailto:xen-devel@lists.xensource.com> List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help> List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=subscribe> Sender: xen-devel-bounces@lists.xensource.com Errors-To: xen-devel-bounces@lists.xensource.com On Tue, 2011-09-20 at 14:20 +0100, Ben Hutchings wrote: > On Tue, 2011-09-20 at 10:12 +0400, rush wrote: > > Hi, > > > > There are several Not tainted lines in old messages file. There are all of them: > > > > Sep 10 22:35:33 xen-dom0 kernel: [24183.985513] Pid: 2605, comm: > > debootstrap Not tainted 3.0.0-1-amd64 #1 Intel Corporation > > S1200BTL/S1200BTL > > Sep 10 22:35:33 xen-dom0 kernel: [24183.985621] RIP: > > e030:[<ffffffff810106db>] [<ffffffff810106db>] > > __sanitize_i387_state+0x23/0xe1 > > Source/disassembly: > > void __sanitize_i387_state(struct task_struct *tsk) > { > u64 xstate_bv; > int feature_bit = 0x2; > struct i387_fxsave_struct *fx = &tsk->thread.fpu.state->fxsave; > ffffffff810106b8: 48 8b 97 48 04 00 00 mov 0x448(%rdi),%rdx > > if (!fx) > return; > ffffffff810106bf: 48 85 d2 test %rdx,%rdx > ffffffff810106c2: 0f 84 d0 00 00 00 je 0xffffffff81010798 > > BUG_ON(task_thread_info(tsk)->status & TS_USEDFPU); > ffffffff810106c8: 48 8b 47 08 mov 0x8(%rdi),%rax > ffffffff810106cc: f6 40 14 01 testb $0x1,0x14(%rax) > ffffffff810106d0: 74 02 je 0xffffffff810106d4 > ffffffff810106d2: 0f 0b ud2 > > xstate_bv = tsk->thread.fpu.state->xsave.xsave_hdr.xstate_bv; > ffffffff810106db: 48 8b b2 00 02 00 00 mov 0x200(%rdx),%rsi > > So tsk->thread.fpu.state in RDX seems to be invalid. > > > Sep 10 22:35:33 xen-dom0 kernel: [24183.985716] RSP: > > e02b:ffff8803bd2c5e00 EFLAGS: 00010246 > > Sep 10 22:35:33 xen-dom0 kernel: [24183.985767] RAX: 0000000000000000 > > RBX: 00007fff3d69ecc0 RCX: 0000000000000200 > > Sep 10 22:35:33 xen-dom0 kernel: [24183.985824] RDX: ffff8803be0e8e00 > > RSI: ffff8803bd2c5fd8 RDI: ffff8803bd65aa30 > [...] > > RDX looks like a reasonable kernel memory pointer. Given the hostname, > I assume this kernel is running under Xen. So could this be a > use-after-free where the freed page has been unmapped for reallocation > by the hypervisor? Can that happen to arbitrary pages in the dom0 > kernel? In a modern pvops kernel there is a tendency towards leaving a page of actual dom0 memory behind in these cases, rather than a hole. A page with no backing mfn should never be escaping into the "wild" anyway but it's possible fir a given process to see one if it is doing hypercall activities, mapping foreign pages etc. There's been some similar looking threads on xen-devel recently but I haven't paid attention to the details, list & Konrad CC'd. Full log is at http://bugs.debian.org/642154. > > Ben. > -- Ian Campbell Everybody has something to conceal. -- Humphrey Bogart _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel From xen-devel-bounces@lists.xensource.com Tue Sep 20 06:57:37 2011 Return-path: <xen-devel-bounces@lists.xensource.com> Envelope-to: www-data@lists.xensource.com Delivery-date: Tue, 20 Sep 2011 06:57:37 -0700 Received: from localhost ([127.0.0.1] helo=lists.colo.xensource.com) by lists.xensource.com with esmtp (Exim 4.43) id 1R60pN-0004rv-EG; Tue, 20 Sep 2011 06:57:37 -0700 Received: from mail182.messagelabs.com ([85.158.139.83]) by lists.xensource.com with esmtp (Exim 4.43) id 1R60oO-0004eH-Bf for xen-devel@lists.xensource.com; Tue, 20 Sep 2011 06:56:36 -0700 X-Env-Sender: JBeulich@suse.com X-Msg-Ref: server-9.tower-182.messagelabs.com!1316526993!19054245!1 X-Originating-IP: [130.57.49.28] X-StarScan-Version: 6.4.1; banners=-,-,- X-VirusChecked: Checked Received: (qmail 26253 invoked from network); 20 Sep 2011 13:56:33 -0000 Received: from nat28.tlf.novell.com (HELO nat28.tlf.novell.com) (130.57.49.28) by server-9.tower-182.messagelabs.com with DHE-RSA-AES256-SHA encrypted SMTP; 20 Sep 2011 13:56:33 -0000 Received: from EMEA1-MTA by nat28.tlf.novell.com with Novell_GroupWise; Tue, 20 Sep 2011 14:56:32 +0100 Message-Id: <4E78B7CA0200007800056CCE@nat28.tlf.novell.com> X-Mailer: Novell GroupWise Internet Agent 8.0.1 Date: Tue, 20 Sep 2011 14:56:58 +0100 From: "Jan Beulich" <JBeulich@suse.com> To: "Allen M Kay" <allen.m.kay@intel.com> Subject: [Xen-devel] RE: Resend: RE: enable_ats_device() call site References: <4E4E48360200007800051F65@nat28.tlf.novell.com> <987664A83D2D224EAE907B061CE93D5301EA5B67F0@orsmsx505.amr.corp.intel.com> <4E5380890200007800052B61@nat28.tlf.novell.com> In-Reply-To: <4E5380890200007800052B61@nat28.tlf.novell.com> Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: quoted-printable Content-Disposition: inline Cc: Xen Devel <xen-devel@lists.xensource.com> X-BeenThere: xen-devel@lists.xensource.com X-Mailman-Version: 2.1.5 Precedence: list List-Id: Xen developer discussion <xen-devel.lists.xensource.com> List-Unsubscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe> List-Post: <mailto:xen-devel@lists.xensource.com> List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help> List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=subscribe> Sender: xen-devel-bounces@lists.xensource.com Errors-To: xen-devel-bounces@lists.xensource.com Ping? >>> On 23.08.11 at 10:27, "Jan Beulich" <JBeulich@novell.com> wrote: >>>> On 23.08.11 at 00:01, "Kay, Allen M" <allen.m.kay@intel.com> wrote: >>> And why is it VT-d specific then? The problem to solve is that = enabling >>>may not happen when it is first attempted, in the case where Xen on its >>>own can't be certain that using MMCFG is safe. Hence when the device >>>gets reported by Dom0 (or when MMCFG gets enabled for the respective >>>bus), another attempt needs to be made at enabling it. De-assigning and >>>then re-assigning the device to Dom0 seems to be overkill to me. >>=20 >> The part that is VT-d specific is ATS capability reporting in ACPI DMAR >> table for reporting ATS capability in root ports. I not so clear on = what >> do you mean by making another attempt when initial ATS enabling = attempt=20 >> fails. >=20 > The initial enabling may fail because of the unavailability of MMCFG > accesses (due to the memory range(s) used not being reserved in E820, > which is not required to be the case by the spec). Once MMCFG gets > enabled, this needs to be re-attempted at some point, and the logical > point appears to be when the device gets re-registered by Dom0. >=20 >> Do you have a patch to address this issue? >=20 > Only for the (trivial) ACS part so far (see below). >=20 > There's also a second aspect here: the bus-to-bridge mappings > currently get established just once, during boot. This is already > hot(un)plug incompatible, but will become even more of a problem > when multi-segment support gets in (I should be sending out patches > soon), for the same MMCFG-initially-unavailable reason as outlined > above (as in that case non-zero segments can't be scanned at boot). >=20 > Jan >=20 > --- a/xen/drivers/passthrough/pci.c > +++ b/xen/drivers/passthrough/pci.c > @@ -350,9 +350,10 @@ int pci_add_device(u16 seg, u8 bus, u8 d > } > =20 > list_add(&pdev->domain_list, &dom0->arch.pdev_list); > - pci_enable_acs(pdev); > } > =20 > + pci_enable_acs(pdev); > + > out: > spin_unlock(&pcidevs_lock); > printk(XENLOG_DEBUG "PCI add %s %04x:%02x:%02x.%u\n", pdev_type, >=20 >=20 >=20 > _______________________________________________ > Xen-devel mailing list > Xen-devel@lists.xensource.com=20 > http://lists.xensource.com/xen-devel=20 _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel From xen-devel-bounces@lists.xensource.com Tue Sep 20 07:16:31 2011 Return-path: <xen-devel-bounces@lists.xensource.com> Envelope-to: www-data@lists.xensource.com Delivery-date: Tue, 20 Sep 2011 07:16:31 -0700 Received: from localhost ([127.0.0.1] helo=lists.colo.xensource.com) by lists.xensource.com with esmtp (Exim 4.43) id 1R617d-0005Uf-PO; Tue, 20 Sep 2011 07:16:30 -0700 Received: from mail21.messagelabs.com ([85.158.143.35]) by lists.xensource.com with esmtp (Exim 4.43) id 1R5phS-0004LT-2V for xen-devel@lists.xensource.com; Mon, 19 Sep 2011 19:05:15 -0700 X-Env-Sender: pracshi@gmail.com X-Msg-Ref: server-14.tower-21.messagelabs.com!1316484269!60210047!1 X-Originating-IP: [209.85.214.43] X-StarScan-Version: 6.4.1; banners=-,-,- X-VirusChecked: Checked Received: (qmail 6239 invoked from network); 20 Sep 2011 02:04:29 -0000 Received: from mail-bw0-f43.google.com (HELO mail-bw0-f43.google.com) (209.85.214.43) by server-14.tower-21.messagelabs.com with RC4-SHA encrypted SMTP; 20 Sep 2011 02:04:29 -0000 Received: by bkas6 with SMTP id s6so41102bka.30 for <xen-devel@lists.xensource.com>; Mon, 19 Sep 2011 19:04:37 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :content-type; bh=BpX+psvuPnUbFbaFl9iEy+r+wQQhn0w5yQvIU6VyXEc=; b=KgQITAzaPObCbUhwyKo6/zLrNPx9S0vP3emF8tUgKfTPIhTyHdNU0f0zw/PBBnz7LN XFig+SSyoUy5j7RHRN0sUVqc4FMJIsOZtYjkHavI0OeIbgrxMSD9TJSkQ4fkL9BAW1Fr lns5/G/PkB5+cWabrBW/ycOoF0qsNzv9iJgaQ= MIME-Version: 1.0 Received: by 10.204.145.204 with SMTP id e12mr108338bkv.52.1316484277540; Mon, 19 Sep 2011 19:04:37 -0700 (PDT) Received: by 10.205.36.2 with HTTP; Mon, 19 Sep 2011 19:04:37 -0700 (PDT) In-Reply-To: <CAEAezkW3V_G-q_PP5n45a9gy_ovwJ=sNywvwsa_qYSJn7Cveiw@mail.gmail.com> References: <CAEAezkW3V_G-q_PP5n45a9gy_ovwJ=sNywvwsa_qYSJn7Cveiw@mail.gmail.com> Date: Mon, 19 Sep 2011 19:04:37 -0700 Message-ID: <CAEAezkUtuuyQomUaCtgyb4vMoVTT9KDaG7GYcy3XN4MbSJDpRQ@mail.gmail.com> From: Pratik shinde <pracshi@gmail.com> To: xen-devel@lists.xensource.com Content-Type: multipart/mixed; boundary=0015175ce16ab718e004ad55e1ec X-Mailman-Approved-At: Tue, 20 Sep 2011 07:14:38 -0700 Subject: [Xen-devel] Fwd: [help]: X-BeenThere: xen-devel@lists.xensource.com X-Mailman-Version: 2.1.5 Precedence: list List-Id: Xen developer discussion <xen-devel.lists.xensource.com> List-Unsubscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe> List-Post: <mailto:xen-devel@lists.xensource.com> List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help> List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=subscribe> Sender: xen-devel-bounces@lists.xensource.com Errors-To: xen-devel-bounces@lists.xensource.com --0015175ce16ab718e004ad55e1ec Content-Type: multipart/alternative; boundary=0015175ce16ab718da04ad55e1ea --0015175ce16ab718da04ad55e1ea Content-Type: text/plain; charset=ISO-8859-1 Respected Sir, Thank you for paying attention to my mail. I am an undergraduate student of computer science.I want to do some good project in xen.I read the paper "affinity-aware dynamic pinning scheduling for Virtual machine" (copy is attached).Reading this paper i thought of an following idea.. "In xen,Qemu emulates the hardware to guest O.S.so <http://o.s.so/>guest kernel is unaware of underlying real hardware.So scheduling of processes which guest kernel will do,may not be optimized. In credit scheduler it schedule the VCPUs according to their weights but process scheduling on VCPU may not be optimized. My basic idea is scheduling these processes according to real hardware and the scheduling domains accordingly." Sir,is this idea already implemented in xen? Also,I want to know resource allocation policy used by xen. Sir,can you suggest any improvement to above idea or any good project idea in resource allocation or scheduler or in memory management of xen? Thanking you --0015175ce16ab718da04ad55e1ea Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable <br>Respected Sir,=A0 <br><div class=3D"gmail_quote">Thank you for paying a= ttention to my mail.<br> I am an undergraduate student of computer science.I want to do some good project in xen.I read the paper=A0 "affinity-aware dynamic = pinning scheduling for Virtual machine" (copy is attached).Reading thi= s paper i thought of an following idea..<br> <div style=3D"text-align: left;" class=3D"gmail_quote">=A0=A0=A0 &quo= t;In xen,Qemu emulates the hardware to guest <a href=3D"http://o.s.so/" target=3D"_blank">O.S.so</a> guest= kernel is unaware of underlying real hardware.So scheduling of processes which guest kernel will do,may not be optimized. In credit scheduler it schedule the VCPUs according to their weight= s but process scheduling on VCPU may not be optimized.<br> My basic idea is scheduling these processes according to real hardware and the scheduling domains accordingly."<br> =A0 Sir,is this idea already implemented in xen?<br> Also,I want to know resource allocation policy used by xen.<br> =A0Sir,can you suggest any improvement to above idea or any good project idea in resource allocation or scheduler or in memory = management of xen?<br> =A0 Thanking you<br> </div> =20 </div><br> --0015175ce16ab718da04ad55e1ea-- --0015175ce16ab718e004ad55e1ec Content-Type: application/pdf; name="affinity scheduling.pdf" Content-Disposition: attachment; filename="affinity scheduling.pdf" Content-Transfer-Encoding: base64 X-Attachment-Id: f_gstpbrts0 JVBERi0xLjQNJYCEiIyQlJicoKSorLC0uLzAxMjM0NTY3ODk6Ozw9Pj8DQ0xIDAgb2JqDTw8IC9I ZWlnaHQgNDU0IC9CaXRzUGVyQ29tcG9uZW50IDggL1N1YnR5cGUgL0ltYWdlIC9MZW5ndGggMzU2 NTggL0ludGVudCAvUmVsYXRpdmVDb2xvcmltZXRyaWMgL1dpZHRoIDc1NCAvVHlwZSAvWE9iamVj dCAvRmlsdGVyIC9EQ1REZWNvZGUgL0NvbG9yU3BhY2UgMTI0IDAgUg0+Pg1zdHJlYW0K/9j/7gAO QWRvYmUAZIAAAAAB/9sAhAAMCAgICQgMCQkMEQsKCxEVDwwMDxUYExMVExMYFxIUFBQUEhcXGxwe HBsXJCQnJyQkNTMzMzU7Ozs7Ozs7Ozs7AQ0LCw0ODRAODhAUDg8OFBQQEREQFB0UFBUUFB0lGhcX FxcaJSAjHh4eIyAoKCUlKCgyMjAyMjs7Ozs7Ozs7Ozv/wAARCAHGAvIDASIAAhEBAxEB/8QBPwAA AQUBAQEBAQEAAAAAAAAAAwABAgQFBgcICQoLAQABBQEBAQEBAQAAAAAAAAABAAIDBAUGBwgJCgsQ AAEEAQMCBAIFBwYIBQMMMwEAAhEDBCESMQVBUWETInGBMgYUkaGxQiMkFVLBYjM0coLRQwclklPw 4fFjczUWorKDJkSTVGRFwqN0NhfSVeJl8rOEw9N14/NGJ5SkhbSVxNTk9KW1xdXl9VZmdoaWprbG 1ub2N0dXZ3eHl6e3x9fn9xEAAgIBAgQEAwQFBgcHBgU1AQACEQMhMRIEQVFhcSITBTKBkRShsUIj wVLR8DMkYuFygpJDUxVjczTxJQYWorKDByY1wtJEk1SjF2RFVTZ0ZeLys4TD03Xj80aUpIW0lcTU 5PSltcXV5fVWZnaGlqa2xtbm9ic3R1dnd4eXp7fH/9oADAMBAAIRAxEAPwD1VJJJJSkkkklKSSSS UpJJJJSkkkklKSSSSUpJJJJSkkkklKSSSSUpJJJJSkkkklKSSSSUpJJJJSkkkklKSSSSUpJJJJSk kkklKSSSSUpJJJJSkkkklKSSSSUpJJJJSkkkklKSSSSUpJJJJSkkkklKSSSSUpJJJJSkkkklKSSS SUpJJJJSkkkklKSSSSUpJJJJSkkkklKSSSSUpJJJJSkkkklKSSSSUpJJJJSkkkklKSSSSUpJJJJS kkkklKSSSSUpJJJJSkkkklKSSSSUpJJJJSkkkklKSSSSUpJJJJTV6hiX5dAqozLsB4cHG2gVlxAB G0+vXY2NZ4lYfTP2nX9ZrsT9qZGdg4OOHZnrtoAF9xmpjTRTWZbW0udJ7t8V0OTf9nxrcjY+z0mO f6dbS97tona1rQSSewCzfq1gX0dL9bOZsz+oudl5rTEtst/wf/W2wwfBJTiDM65kfVy/62s6hbUR Tbm4/Tgyr7P9nYHPZXZNZsLnVt9zg/Rx00V63qGX1vqePgdPy34OJ9ir6hkZNArdY8ZBLaK63Wss YG+1znHb4R3WZW7Po+qVv1SdhZL+qfZ7en0vFL/s72ODqa8g5AHpNbsIcQXSONSr5x3/AFe6xRli i27pr+nVYL3Y1TrXVPxXONc11Bz9r22HgaR5pKbv1e6hk2ZnVOkZd/2q/pV1bBe4NbY+q6pt1brG 1honUiQBMLbWD9XMS053V+tW0Oxv2rdUaa7W7bfRoqZSx1jTq3cQ5wadROuq3klKSVZ+BQ95e51w LjJDb7mj5Na8AKt0/CquwMa6yy91llTHvP2i4SXNBJ0sSU6SSq/s3H/fv/8AYi//ANKJfs3H/fv/ APYi/wD9KJKbSSq/s3H/AH7/AP2Iv/8ASiX7Nx/37/8A2Iv/APSiSm0kqv7Nx/37/wD2Iv8A/SiX 7Nx/37//AGIv/wDSiSm0kqv7Nx/37/8A2Iv/APSiX7Nx/wB+/wD9iL//AEokptJKr+zcf9+//wBi L/8A0ol+zcf9+/8A9iL/AP0okptJKr+zcf8Afv8A/Yi//wBKJfs3H/fv/wDYi/8A9KJKbSSq/s3H /fv/APYi/wD9KJfs3H/fv/8AYi//ANKJKbSSq/s3H/fv/wDYi/8A9KJfs3H/AH7/AP2Iv/8ASiSm 0kqv7Nx/37//AGIv/wDSiX7Nx/37/wD2Iv8A/SiSm0kqv7Nx/wB+/wD9iL//AEol+zcf9+//ANiL /wD0okptJKr+zcf9+/8A9iL/AP0ol+zcf9+//wBiL/8A0okptJKr+zcf9+//ANiL/wD0ol+zcf8A fv8A/Yi//wBKJKbSSq/s3H/fv/8AYi//ANKJfs3H/fv/APYi/wD9KJKbSSq/s3H/AH7/AP2Iv/8A SiX7Nx/37/8A2Iv/APSiSm0kqv7Nx/37/wD2Iv8A/SiX7Nx/37//AGIv/wDSiSm0kqv7Nx/37/8A 2Iv/APSiX7Nx/wB+/wD9iL//AEokptJKr+zcf9+//wBiL/8A0ol+zcf9+/8A9iL/AP0okptJKr+z cf8Afv8A/Yi//wBKJfs3H/fv/wDYi/8A9KJKbSSq/s3H/fv/APYi/wD9KJfs3H/fv/8AYi//ANKJ KbSSq/s3H/fv/wDYi/8A9KJfs3H/AH7/AP2Iv/8ASiSm0kqv7Nx/37//AGIv/wDSiX7Nx/37/wD2 Iv8A/SiSm0kqv7Nx/wB+/wD9iL//AEol+zcf9+//ANiL/wD0okptJKr+zcf9+/8A9iL/AP0ol+zc f9+//wBiL/8A0okptJKr+zcf9+//ANiL/wD0ol+zcf8Afv8A/Yi//wBKJKbSSq/s3H/fv/8AYi// ANKJfs3H/fv/APYi/wD9KJKbSSq/s3H/AH7/AP2Iv/8ASiX7Nx/37/8A2Iv/APSiSm0kqv7Nx/37 /wD2Iv8A/SiX7Nx/37//AGIv/wDSiSm0kma0NaGiYAgSSTp4k6p0lKSSSSUpJJJJSkkkklKSSSSU pJJJJSkkkklKSSSSUpJJJJSkkkklKSSSSUpJJJJSkkkklKSSSSUpJJJJSkkkklKSSSSUpJJJJSkk kklKSSSSUpVelf8AJeH/AMRV/wBQFaVXpX/JeH/xFX/UBJTaSSSSUpJJJJSkkkklKSSSSUpJJJJS kkkklKSSSSUpJJJJSkkkklKSSSSUpJJJJSkkkklKSSSSUpJJJJSkkkklKSSSSUpJJJJSkkkklKSS SSUpJJJJSkkkklKSSSSUpJJJJSkkkklKSSSSUpJJJJSkkkklKSSSSUpJJJJSkkkklKSSSSUpJJJJ SkkkklKSSSSUpJJJJSkkkklKSSSSUpJJJJSkkkklKSSSSUpJJJJSkkkklKSSSSUpJJJJSkkznNa0 ucQGgSSdAAFQwPrB0PqV7sfp+fj5dzAXOrpsa920EAuhpOmvKSnQSWfZ1/odWf8As2zPx2Z0hv2Z 1rRZJEgbZmSOyN1DqnTemUi/qOVViVOdta+54YC6J2jcdTokptJIOLl4ubQzJxLmZFFglltbg9p+ BajJKUqvSv8AkvD/AOIq/wCoCtKr0r/kvD/4ir/qAkptJJJJKUkkkkpSSSSSlJJJJKUkkkkpSSSS SlJJJJKUkkkkpSSSSSlJJJJKUkkkkpSSSSSlJJJJKUkkkkpSSSSSlJJJJKUkkkkpSSSSSlJJJJKU kkkkpSSSSSlJJJJKUkkkkpSSSSSlJJJJKUkkkkpSSSSSlJJJJKUkkkkpSSSSSlJJJJKUkkkkpSSS SSlJJJJKUkkkkpSSSSSlJJJJKUkkkkpSSSSSlJJJJKUkkkkpSSSSSlJJJJKUkkkkp5z683uZ0zDx fTfbXn9QxcW6tg0cx9m4seSQAyzbsJ81Zx+sZdPUaumdQwa8Sy+m23CfRb6zHMo2b2OmuosPvboA R5q71fpdfVMP7M55qeyyu+i5oBNdtLxZW8A8w5vCq4XRs39oV9T6tlszMrHrfTjCmo0VsbaWGw7X WWkudsGu75JKcHGoqf8A4rMi9wD7sjp9+bdZ3dkPY+91k/vb9fJW+i2WZ/1jx8jNbF+P0bFtrrcQ 412ZT3+uQe5PpNE+Xmjf808tuHZ0arqAZ0G4v3Yop/TtqscXvx67/UDW167R+jkN0B7q71Dol782 nqXSshmFm00nGPqV+rVZSXB7WPY19bvYR7SHaSfFJTT+rrns+sn1lxGs2YtWRjW1EEbd92Mx1oDe 2oDj4yujWf0jpP7OZfZbccnMzbfXy8gt2Bz9rWAMYCdrWtaGtEn4krQSU1n59DHljm3EtMEtoucP k5rCCqvTeoUM6disLbiW01gxRc4aNHBbWQVpqr0r/kvD/wCIq/6gJKV+0sf9y/8A9h7/AP0ml+0s f9y//wBh7/8A0mrSSSmr+0sf9y//ANh7/wD0ml+0sf8Acv8A/Ye//wBJq0kkpq/tLH/cv/8AYe// ANJpftLH/cv/APYe/wD9Jq0kkpq/tLH/AHL/AP2Hv/8ASaX7Sx/3L/8A2Hv/APSatJJKav7Sx/3L /wD2Hv8A/SaX7Sx/3L//AGHv/wDSafN6hi4NRsvfEcMGrjMxA+Syq/rbius2vpexkxvBBPzGijnm xwNSkAWSGHJMXGJIdT9pY/7l/wD7D3/+k0v2lj/uX/8AsPf/AOk0am6q9gspeHsPBHmJRFIxtX9p Y/7l/wD7D3/+k0v2lj/uX/8AsPf/AOk1aSSU1f2lj/uX/wDsPf8A+k0v2lj/ALl//sPf/wCk1aUL bqqazZa8MY3lzjASut1boP2lj/uX/wDsPf8A+k0v2lj/ALl//sPf/wCk02P1Xp+TZ6dN7XP7N1BP wmJVtCMoyFxIPlqmUZRNSBHno1f2lj/uX/8AsPf/AOk0v2lj/uX/APsPf/6TVpJFDV/aWP8AuX/+ w9//AKTS/aWP+5f/AOw9/wD6TVpJJTV/aWP+5f8A+w9//pNL9pY/7l//ALD3/wDpNYvXevZFeQ7E xHemK9LLByXeA+Co4P1gz8a0G6x19RPva/Ux5FVpc5jjPg10NGXRsx5PJKHFpqLEer1H7Sx/3L// AGHv/wDSaX7Sx/3L/wD2Hv8A/SaNXdVa1rq3hweAWwex1RFZBvZrEVu1f2lj/uX/APsPf/6TS/aW P+5f/wCw9/8A6TVpJJTV/aWP+5f/AOw9/wD6TS/aWP8AuX/+w9//AKTVpUs7q+Dgnbe+bDr6bRLv n4ISlGIuRAHimMZSNRBJ8Gf7Sx/3L/8A2Hv/APSaX7Sx/wBy/wD9h7//AEmoYPWMHOdspeRZz6bx Dvl4q6lGUZC4kEeCpRlE1IEHxav7Sx/3L/8A2Hv/APSaX7Sx/wBy/wD9h7//AEmrSSKGr+0sf9y/ /wBh7/8A0ml+0sf9y/8A9h7/AP0mrSSSmr+0sf8Acv8A/Ye//wBJpftLH/cv/wDYe/8A9Jqjn/WX ExLTTWw3vYYfBhoPhOqsdM61i9RljJrtAk1u8PEHuoxnxmXAJDi7MhwZBHjMTw9037Sx/wBy/wD9 h7//AEml+0sf9y//ANh7/wD0mrSSkY2r+0sf9y//ANh7/wD0ml+0sf8Acv8A/Ye//wBJqySAJJge KG7KxmfTuY34uA/igSBuUgE7BF+0sf8Acv8A/Ye//wBJpftLH/cv/wDYe/8A9JoeV1nAx6H2Nvrt e0HbW14JJ8NCuOys/LyrTbda4mZABgD4DsoM3NQx0B6yexZ8PKzyWT6AO4e1/aWP+5f/AOw9/wD6 TS/aWP8AuX/+w9//AKTWF0HrjmP+zZtv6Iia7Hn6JHYk9lvtz8F/0Mip3we0/wAU/FnhkiJA14Hd ZlwTxy4SL8Rsx/aWP+5f/wCw9/8A6TS/aWP+5f8A+w9//pNWG2Vv+g4O+BBUlKxNX9pY/wC5f/7D 3/8ApNL9pY/7l/8A7D3/APpNWlGyxlVbrLHBrGCXOPYBJTX/AGlj/uX/APsPf/6TS/aWP+5f/wCw 9/8A6TWXb9bcVtm2ul72AxvJDfuGq1cHPx86n1aHSBo5p0c0+BUcM2OZ4YyBLJPDkgOKUSAt+0sf 9y//ANh7/wD0ml+0sf8Acv8A/Ye//wBJq0kpGNZrg5ocJgiRIIOviDqnSSSUpJJJJSkkkklKSSSS UpJJJJSkkkklKSSSSUpJJJJSkkkklKSSSSUpJJJJSkkkklKSSSSUpJJJJSkkkklKSSSSUpJJJJSk kkklKSSSSUpJJJJSlV6V/wAl4f8AxFX/AFAVpVelf8l4f/EVf9QElNpJJZ3WuqjpuO1zW7rbSW1z 9EEfvaoSkIgyOwTGJkQB1dFJcN+3OqG0v+0v3DWNNuv8nhbFP1uo9AetU5140dsgMPzJVeHOY5Xd woX6uxZ58pkFcJE7JHp7jd6FJcnk/XDIOlNVdQ8XEvP/AH1ZWT9Yeo3zvyHkHsz2D/owpI5ZT/ms c8njw8MftLHOEMf87lx4/Di4pf4sbe8uysagTfaysfynAflWdf8AWbpVUhr3XEdmN/i6AuPoxOq5 pnHx7Hh358GP852i0cf6n9Vug5NrKG9xO933N0/FP9vmD8xx4fM8cvsFBi9/B+hDLn8QPbh9pRdb 6xX1G9lgHpNqbtaCZMkyTossZDZPbcefkAunZ9TsNjm1F9lzyJfYfaxo8gOXHtr8fMlX1RwHWZAI sArsAo3n2ub6dbtYDSRuJGhQ+64dTOU8spby0jWvZR5rmTXBGGGMTpHWVmjuf2uV03rOdj0jHxH1 7JJDXlsyefpEFaberfWUtBbih4/eFZIP3FT/AOaHTMhhIF2LYDDmB25sjwLh7gqzvqbmUEuws7ae 0hzD/nMJ/Ih90jtHmMkf72q775l3lyuKfjA1+BT/ALc+sQ1dgaDn9FaP+/Jf84usN1fg6f1XhV/s v10w/wCbuOQ0fymv/wDPuqX/ADj+sOJpmYMtH52x7P8ApatS+55f0eYv7Fff8I+fljD7abH/ADoz m/TwuePpD8oWX1Xq2R1GxvqN9JlY0rmdT37LTo+vGI7+fxrK/wCoQ/8ALsVHrOb0rqDxl42RtugC yqwOGg7tMR8lFn5PmuAjjM/6vCNfqGbBz/J8YPDGH9biOn0LmAkEEGCNQQt+jr/W30sFOJ60CPU2 PdujSfaQsfEwnXvax11VbXOdL3WMIAa4idHfd4rtMN+Bi41ePVexzKxAJe0k955UPL8rmiZWZYxd bb0z5+cwSEaEchri30jfTRxvtv1qs+jj7P7AH/VlL0frdb9J+z51j/qF0ItrJgPaSe0hTU/3Y/pZ ch/wqYfvI/RxYx/g283+xvrHb/OZu0dx6j/yNEJf81syz+fzZnnRzvyuC6RJL7pi68UvORV97y9O GPlEPDdU6Vd024McTZU4Sy2IB8R31VbHx7sm5tNLS57jAA/KV3Zsque7GvrE8tY8BzXtH5wnnzHZ AxrcOrDpyaaG1faWNcyqtoDnFw3BukSopfDwZ2JVDt1ZY/EahRFz79HLP1PrjTKIMfuA6/5wUf8A mncyPTzYj+QR+R66NpcWguEOI1AMwfinUv3PB+5+JYvvmf8Af/APN/8ANzqzR7M74+54/Il+x/rI yS3O3f8AXbP4tXSJJfdMfQyHlIq+95OoifOIeb+xfWtn0cjdHHvB/wCqCwMh1z7nuvJN247y7me6 9DWT1L6u42babmPNFrvpkDcD5lsjVQ5+UkYjglKVfoyl+TLg5uIkeOMY3+lGP5vJUPuruY+gkWhw 2Ecz2XQ7/rh+43/wL+9W+m/V3GwrRc95vtbqwkbWg+O2TqtdLBykxE8U5QvpCX5qz81AyHDCM66z j+Tzu/64fuN/8C/vS3/XD9xv/gX966JJT/dv9bl/xv7GH7x/qsX+L/a87v8Arh+43/wL+9M9/wBb 9jpYAIMkelPygro0kPu3+ty/439ifvP+qxf4r5yjYTcp2VW3EJbeTDCDEf6hdNn/AFYxsm43U2Gh zzLxt3NJPgJEKx0vomN04mwE23ER6hEQPIdlUjyWXjAOkQfmB/Jty53FwEjWRHykfm5v7K+s1n0s zZ3/AJ1w/wCoal/zc6s/+dzp/tPd+WF0iSt/dMfUyl5yLU+95OgjHyiHmx9UHOM2Zc/2J/EvRW/V DFH08h5+AA/vW+kiOUwD9D8Sg83nP6f4Bw3fVLA9NwZZb6hHtc4ggH4BoXNZOJkYtpqvYWOHjwfg e6760WOYRW7Y/wDNcRInzCq3ZrxQCB6d7baa7WHWBZaxhI8QQTB/im5ORxzrg9B8F0Oenjvj9Yq9 fDs8/wBH+r7ssG7LDq6I9gGjnHx17LQd9UcA/RttHxLT/wB9C1arn32b69MZsw7vYfFv8kePf4c2 EY8nijERMRI9Sd1sucyykZRkYjoBs8676n1H6GU4fFgP/fgo/wDNbMZ/NZsfJzdPk4rpEkvumD92 vIlP3vP+9fmA83+w/rAz+bzvOPUsH8Cq3UcPr9WI45VxtxxG8B27v3kTyutTOa1zS1wDmuEEHUEF CXKQIIEpix+9omPNzBBMYmj+7q+dLe+qTbftV7hPpenDvDdI2/hK0bfqv0yywvHqVg67GuG38Wkr RxcXHxKhTjsDGDWB3PiSocHJzhkEpEVHt1Zs/NwnjMYg3Lv0TJJJK+0FJJJJKUkkkkpSSSSSlJJJ JKUkkkkpSSSSSlJJJJKUkkkkpSSSSSlJJJJKUkkkkpSSSSSlJJJJKUkkkkpSSSSSlJLJ+tVXUrug ZbOl7/tcMLRU7ZY5jXtdayt3Zzqw4DzXG59P1h62zP8ArM1nUenvxvRp6D033se57XN32X0iZDnG CTpt54lJT6QkmbO0buY1jxTpKUks7rvU7ul9P+00UtyLnXUUV1Pea2l19rKAXPDXkAb54U+nXdas c/8AaeLj4zQB6Zx733Envu301R+KSm8kuZd9aepOwrutUYFVnQqDY71jeRkPpqJa++uoVFhb7S5v v1br3V7P63k/bMfp3R6K8vLvpOU511hqprona173MZa6XuMNG3WD4JKdhJZvRurP6h9poyKRjZ2B aKcqlr/UaHFjbGuY/a2Wua4ESAtJJSlV6V/yXh/8RV/1AVpVelf8l4f/ABFX/UBJTaWN9Z8G3KxG W1AvNBJc0aktdE/dC2UK+g3AMLoq/wAIwcuHhu8PHxTckBOJiTV9V0JmEhICyOj5rY6wOIZqIAny 17rWwfqt1XMrbbY9uPW7gOndHjtC61vS8MZT8g1VnexjA3Y3QtLyXA+e78Eeij0AWNcTV/g2H83x APh4eCdjAgBUYWAPVw+omt7YskDMkynkqRl6OKoAE3VOFjfUrp9cHItsvPgIY37hJ/Fa2N0fpmLH oY1bSOHEbnf5zpKuJJxnI7kojhxx+WIH5qSSSTWRSSSSSlJJJJKUkkkkpBfg4WR/P0V2+b2gn8Qs nN+rnR7HejRj7ch4mWOcGsb++4THwHf8m6ohrQS4AAu1cQNSYjVOjMjYlZPHGW8QfMPJV/VPFdUb zZa6ttttdjWwXBtdj6w4aa6N1H3eCsN+pOE9ofXlvLHCWkBpBB41XSta1ghoDRJMARqTJPzJSa1r BtYA0amAIEkyU45p92Mcri6xBeYP1FrjTMcD/wAWP/JKP/Md7dWZ3u/4uPyWLq0kveyd/wAFfdcP 7v4l5T/mdns/m8/U86OH5HFL/mt1tmlfUIHf32D8i6tJL3p+H2K+64ugI/wi8dkdC+sVRY37f6jt 00sFtu7d3IEQInmUHFxPrMwY78e7+cqaceXg+wgHa3foIHIXZV0MZY+2S6x/LncgdmjwAUWYdLcS vEgurqa1jCT7hsADTIjXTlO949QD9Fv3UXYlIf4Tzf2r67UfzlPqx/Jrd/56KX/OX6w06ZHT+O/p 2N/KSuqaC1oBJcQILjEnzMQnTfcj1hH6aLvYmNss/wDC1eVZ9eIO27CLT3h/8C0KzX9dumO/nKrm H4NI/wCqW+9jHiHtDh4ESq9nSumW/wA5iUuPj6bZ++EuLGf0CPIq4M42yiXnH+DRr+tfQ383lh/l Md/AFSxuudNFgpOZW+t381a50Ed9r90fI/frzKz6s9Ds5xQD4tc5v5HLPd9VOlX3FuP6jKmEiywO kT+4zcDx3Py54I9o/vBBPMCtIHysNzD6pTkYeNW7KYwiqs5NrntDi4tBc1snn949vjxotzcJ2rci ojye0/xXLYn1Ww7KMe3Itsa3JrY9j27doc9oOx0jTU6H5fG4fqRgx7ci0Hz2n+ARlHHfzEfREJ56 +QH/AAne+14n+mr/AM4f3qQvpcJFjSPEELnf+Y+L/wBybP8ANCZ31Gx/zct4+LAf4hN4cf75/wAV dx5/80P8d6T1qv32/eFJwLmkNO0kaOEGPPVcv/zGq/7mO/zB/wCSUT9RROmbA86v/UiXDj/f/wCa r3M/+Z/54dzKzbqMPJ3wzKppssrP5r9jSQ5s/iO34p7epY/q7fXrpqrP6S17miSPzGbj95+XPHL2 /VTbj5GVXlb6aK3Pa/043lgLob7zpp9JW6PqfiNu9HLvs3O/mnMDWtePKd0OHgncGP8Ae/BYMmcn +brbeTsW/WTolX0sprj4MDnf9SCqdv106UzStltp7Q0Af9J0/gjVfVLolf0qnWn+W93/AH3artXR +lU/zeJUCOCWAn73Sm/qh0kV9cwesI+VlwXfXa2w7cXCLj2lxJ/zWt/im/bP1tyf5jC9Idj6bh+N hhdS1jGDaxoaPACApJccBtAfU2r2ch+bMf8ABAi8n9j+umT/ADt/oA/y2s/89AqrZ9XupXVfaMjM 9RpsrqY8l793qWNr3NLo9oLue67OytlrDXYJY76Q4keBhKyquxgY9stDmuA41Y4Pbx4EIjMRsAPI IPKxO8pS0/Sl1eSp+r3XPcyjqBrtr+lWX2MIngjbMgjgov7N+uVP0Mr1I/4Td/58C6h1VbrG2Ee9 khruDB5HwU0jmPYHzChy0RtKQ8pPKer9eKfpM9QDyqPH9TVL9t/Wun+dwN4HJ9J5482OhdWkh7g6 wj+SfYkNss/qbeU/54dRq/pHT4jnVzPj9JpSf9c8a9gbbi2VkEFr63guafES0Lq0DKZVsk0C97jD WloMk/vEgwPNETh+59kkHHmA/nb84BwKfrTj5l+HX6dgubcZAADXzXZW0D3aS5w548Vv0U2Bxuvd uucIgfRaP3W/xPdZ9nRsdt2NZ6TfVdcXXW1N2bQKrdu3b9EB235rQofeHGm8bnNEttA9rh5+DvL7 vITMdOHTRdiExfuG9dPsTpJJKNmUkkkkpSSSSSlJJJJKUkkkkpSSSSSlJJJJKUkkkkpSSSSSlJJJ JKUkkkkpSSSSSlJJJJKUkkkkpSSSSSlJJJJKeY+vtH1qyOkvo6A2l1dlb25TXF4yDq3Z9nLIE8zK y+odJ/xndXwj03LyOmYePca/VyMY5AvY1jmvlk9/b8/Fbv16fk1/VLqT8XKGFeKhsvc4Mj3tlge4 gNLx7AfErgKKf8SlldfrZNpueB6hs+17tx53FrNvPPZJT64BAA5juU6SSSml1fD6fnYgw+oP2VW2 MLCLDS82VuFzNj2Oa7cCydD2WPhGzE+sp6Rh5l2Xhvwn3ZFd9rsg0W+o1tX6Z+549QOd7XOPGi38 rExMyl2Pl015FL/pVWtD2n4tcCFHC6fgdPp9DAxqsWqZ9Olja2z4w0BJTyGPl47P8V1+M9wZkUYF 3T7KZG8ZIa/G9Lb3cbNB4q50io9L+smPi5bzvu6NjU022u9z34j3i4T3d+laSt93R+kuzh1F2Fjn Ob9HKNTDaO2j43Ked07A6jT6GfjVZdUyK7mNsbI7w4FJTi/Vtgt+sH1k6jVYbMbIyaKaiDNZdjY7 K7Szz3na4+XkujQ6KKMallGPWymmsba6q2hrGgdmtbAARElNZ9fUS8mu+lrJ9odS5xA8yLmz9yq9 Nr6ienYpZfS1no17QaXEgbREn1hP3LTVXpX/ACXh/wDEVf8AUBJSvT6p/wByKP8Ath//AKXS9Pqn /cij/th//pdWkklNX0+qf9yKP+2H/wDpdL0+qf8Acij/ALYf/wCl1aSSU1fT6p/3Io/7Yf8A+l0v T6p/3Io/7Yf/AOl1aSSU1fT6p/3Io/7Yf/6XS9Pqn/cij/th/wD6XVpJJTV9Pqn/AHIo/wC2H/8A pdL0+qf9yKP+2H/+l1aSSU1fT6p/3Io/7Yf/AOl0vT6p/wByKP8Ath//AKXVpJJTV9Pqn/cij/th /wD6XS9Pqn/cij/th/8A6XVpJJTV9Pqn/cij/th//pdL0+qf9yKP+2H/APpdWkklNX0+qf8Acij/ ALYf/wCl0vT6p/3Io/7Yf/6XVpJJTV9Pqn/cij/th/8A6XS9Pqn/AHIo/wC2H/8ApdWkklNX0+qf 9yKP+2H/APpdL0+qf9yKP+2H/wDpdWkklNX0+qf9yKP+2H/+l0vT6p/3Io/7Yf8A+l1aSSU1fT6p /wByKP8Ath//AKXS9Pqn/cij/th//pdWkklNX0+qf9yKP+2H/wDpdL0+qf8Acij/ALYf/wCl1aSS U1fT6p/3Io/7Yf8A+l1FtHUWNDWX47Wt0DRQ4AD/ALfVxJJTS+zZ/p+l6uN6QG3Z9ndt28RHrxCn 6fVP+5FH/bD/AP0urSSSmr6fVP8AuRR/2w//ANLpen1T/uRR/wBsP/8AS6tJJKavp9U/7kUf9sP/ APS6Z1PUnNLXX47muEEGhxBB7H9OraSSmm6jqLmGt12OWEbS00OIIOkR66TqOouADr8dwBBE0OOo 1B/n1cSSU1fT6p/3Io/7Yf8A+l0vT6p/3Io/7Yf/AOl1aSSU1fT6p/3Io/7Yf/6XS9Pqn/cij/th /wD6XVpJJTV9Pqn/AHIo/wC2H/8ApdL0+qf9yKP+2H/+l1aSSU1fT6p/3Io/7Yf/AOl0vT6p/wBy KP8Ath//AKXVpJJTV9Pqn/cij/th/wD6XS9Pqn/cij/th/8A6XVpJJTV9Pqn/cij/th//pdL0+qf 9yKP+2H/APpdWkklNX0+qf8Acij/ALYf/wCl0vT6p/3Io/7Yf/6XVpJJTV9Pqn/cij/th/8A6XS9 Pqn/AHIo/wC2H/8ApdWkklLN3bRuILo1IECfISU6SSSlJJJJKUkkkkpSSp3dW6bTb6NuQ1tg0I1M HzI4VtrmvaHMIc1wkOGoIPggJRJIBBreikxkACQRe1hdJJJFCkkkDEy68uo21te1oe5kWMdWZY4s PteAYkaHukpOkmJABJ4GpWR0/wCtPSupPpZiNyntyADVa7EyGVEEbg71X1BkEd5SU7CSz7evdKp6 xV0W27b1C9gsrqLXQQd8e/bsk+m7SZ0R+o9Rw+mYb83Ns9KiuA5wBcZcQ1rWtYC4kkwAAkpspIOF mY+diU5uK7fj5NbbanwRLHjc0w6CNCjJKUkkkkpSSSSSlJJJJKUkkkkpSSSSSlJJJJKaXWWdQf0y 9vTaqL8wgelXlz6JO4Tv266CT8Vw3VMr68dHoZmZ/TOgMxBayu65rLYrFjgwPed0hu4gSAYXcdbb u6Vkzmu6Y1rd7s1m2a2sIc4+8EcCF5vVlfVb6w5VPSs762Z+bRba2MW1hoqtcDLWOf6beSNJ78ap KfVkkwAAAHA4TpKUkkkkpSSSSSlJJJJKUqvSv+S8P/iKv+oCtKr0r/kvD/4ir/qAkptJJIOTbdSG 2MZ6lYn1Wt1fH7zR3juPu8ClJkkP7RR6H2j1G+jt3epPt2+MqONbbcHWOZ6dZj0g7R5H7zh2nsOf HwCpSZJJJJSkkkklKSVfIfkUuFzB6tIEW1Ae8fy2ePm37tdCrM2htLLWH1fV0pazUvPg3/XTujSm wkgU2Oa0/abGC0mSxpENB4aJgn4lI5uEJnIqEc+9v96FKTpKoerdLaJOZQAOSbWf3qDuu9EaJOfj /K1h/IUaPYqpvJLNd9ZOgt5zqdfB0/kVO/609Hov9WvNbdW+BZSNxI7b6zEfFv3a8kQkeh+xNF3k lh3fW7oxAZjZVZsfpveHBjB+86QJ+A5/FWsbrfRRW1n7RpsI5fZa0OJOvcj7kuCXYqoukkgMz8Gz +byKn9va9p/IUYEOEtMg8EJqF0kkklKSQa8kOufQ9vp2tktB4cz95p/L4fdL5GQyhm50uc47WMbq 5zjw1oSpSVJVr+oYmLWHZl1WO6AS17wNfATErIy/rv0HHkV2PyXDtUwx979oREZHYEqovQJLi7Pr 5n5LzX0zp+9/bdusP+ZWB+VQ9P6/dT+k44dZ820x/m/pE/2j+kRHzKeHvo9ndfRQzffYypn7z3Bo +8rAt+tPRem2+nXkjJx3TFdQLzWf5Lvolh8J07acZ9P1AyLn+p1LPL3n6QYC4n+3Yf4K70/6m9IF gufS91LP5tt5O9/8p7RtAHg2Pj4IgYxvIy8k6d2J+uXRMu3ZdbZj4ojc0scXWHwds3Qzy7/DnUq+ tHQLfo5tY/ryz/qwFVyvqv0dlht+xNtof/OVs3B7P5dewgkeLfu8DG36jfV9/wBGuyr+pYT/ANXu QPt/1grTxderqXTrv5nKpsn9yxrvyFWAQRI1B4K5S3/F504/zOVcz+vtd+QNVc/UDLpM4vUtv9gs /Frylww/f+0Iod3tFF7trS4AuIBO0cmOwlcb/wA3Prnj60dS3gcN9az8j2wlt/xiY+gPrNHnS78s OS9sdJx/JVeIexpurvrFtR3MdweONCCDwR3CjbfXW+usybLTDWN1MD6TvgO5XEt639b8PJL7MDc+ 0EvZ6TiHbY98MdyBpP39ksf63dZqc+2zpvq22k7rNrxo0xsboYDfD+KXtHpR+qeF7tJcX/44V7BN vTYnj9IW/lrKI3/GLjn6eE8fB4P/AH0Je1PsjhL2CS5Rn+MPphjfjXt8Y2H8rgjN+v8A0N3LMhnx Y3+Dyh7c/wB0qo9npUlzr/rn9XL63V2W2Naf5DgfEEFvBCli/XHokOrvyw41iW3em8bx5jZo4d+3 h4Ae3LsfsVR7PQJLm6vrd0F9n2nIyiHNn0aBXYdgOku9kF5+4cDuSV314+rwEi57vIVu/iAl7cux +xVF30lzjvr50Eces74M/vcEN3+MHooMCrJd5hjP42BH25/ulVHs9OoWXV1BpsdtDnBgJ4k8Ce0r mD/jD6XJjGvI7TsH/fkG3/GDgWVuY7Be9rhDmOc2CD2OhS9qf7quE9nsFD1a/V9HdNgbuLfATEnw lcf0767G25mEyksba8Mqutfv9MOMe/Qbg34jz8V12Pj147C1suc47rLHauc795xQlAx3URSVJJJN QpJJJJSlGxzm1ucxu9zQS1vEkDQKSSSnmz1r6xyYwNO36K0/9+Q8jrX1g9F+/E9FhBDrBVY0tB7y 4wF1Ci9jXtLHgOa4EOB4IKrnBko/rpNgZ8dj9TF87Wr0vqnV8eg04dH2itpn6D37Se3sIhaN31Sp daXVZBrrJ+gW7iP7W4LYwsKjBoFFAho1JPJPiVWw8pmjMkn266g3bZzc3hMAAPcvoRVOH+2vrH/3 A/8AAbf/ACSPn5PWb/q7fl1Vux+oY36aupst9T0SLDWQ+YFgBat1NzoVcx4pRNnJKfgWnkyxkKGO MPEOHj9Uf1TruK3Bu/UKMIZl+06Pdle3GafEbWPd9yyndV6q76r15NWS5uW/q/2Ztzhuiv8AaBoD SO7dmi3+hfV/B6FTdThOscy+w2H1Xbi0QGsqZoIYxoho7KA+rWCOns6f6lvo15f24Olu71PtH2vb OyNu/TiY791KxNvCwPsmM+j7Rdkl7nONmQ/1HS7kA6Q2eBwO2iwcd3W/qtgdOxsx+NndOrdj4G6m uym5m8tored1lrbNSJ+iumurFtT6i5zRY0tLmEtcJES1w1B81lM+rbH5FV2fnZXUW49gux6Mg1it ljZ2v201V7y2dN8xzykpxOu4eRlfWDqj8ME5uH0/Cy8MAwTbRfk2NZP/AAgBYfIq3kZ9H1hycP7K 8uw8XE/al0EiXXMfXiscI/rvjsWhbtfTaK+qXdUDn+vfTXjvaSNgZU6x7SBEzNhnVVuk/V3p3SKM ynE37c+6y+4vIJBsG3azQQ1oENCSkf1O/wDEn0f/AMJY/wD57athVum4FPTen43T6C51OJUymtzy C4tY0NBcQAJ08FZSUpJJJJSkkkklKSSSSUpJJJJSkkkklKSSSSU4v1z6Tl9Z+rGf03Cdsyb2N9PW JLHts2Tp9Pbt+a5Tq/Vuq/WPpZ+ruN9WcrCzLTWw35FYbj4+1zd1ldvtnbHtI5/BdZ9cWdWs+rPU G9GLm9QNX6EsJD4Dml+wt13Fk7fNcn1369YPV+lN6R9WrMsdedZS3HYGWNsrcyxm/wBZx5AaCHTP mkp9EaCGgEyQOU6YTA3c944lOkpSSq9T6hV07Cty7QX7AAypsbrLHHbXWyfznuIaPNYP1eb1DG+s HVKc/JsyLDi4uTaxzy6tllrsne2lh0a0BoaI5jXVJT1CS4dtGRk/VG/622ZWS3qzsa3qNJbfaKqw 1rraqBQ14qLQwBpluvPKvNvH1l6pi4z7ba+mt6dT1B9dFllBtsyy4V7n1GuzaxtZ0nUnXhJT1SS5 /wCrWU5nU+s9Ddc+9vSrqfQNrnWWCnIpba1rrHyXQ7cBJmF0CSlKr0r/AJLw/wDiKv8AqArSq9K/ 5Lw/+Iq/6gJKbShbbXTW621waxvJKmhvpqseyx7dzqiSySYBPeOJ80lPK9a6H9Yc26zLwbvs2M4i 1mILHseHCPdtYNu4kbufxVWn6vfW+6sW1dX3MdwftF/zB9mhC7hQZTVW99jG7XWkF8cEjSY4nzUg ykCqH2J4njf+aX1pd7n9V9x5/S3H8SEv+aH1mOh6pp3/AElq7VJL3ZeH2K4i8V/zI61/5Z/jZ/el /wAxeqv0s6nLf7bvwLgu1SS92fh9iuIvC5H1Jy6drR1E2W2aV1NY6XEcn6egHcpW/wCL7KFXqHM9 SwRuY2uTH520ueJP3LuNjN5s2jeRtL41gaxPzUkven3/AAVxF4qj/F/jXVNsZ1Ava7uKo4MRBfII 7hHH+LrD0nMsJ7w1q6xrGNLi1oaXHc4gRJiJP3KSXuz7q4i8qP8AF50udci8jvBYP++Kbf8AF/0U GTbku8i9n8KwunSQ9yf7xVZ7vON+ofQRz6zvi/8AuaEKz6n9DNhxcal77RHqWue4trB8YIlx7D5n z6hJL3Jdyqy8zk/UjpDGtfTU+wMEWV7zucP3mnjd5cHyUW/UXoGRWLabMhrHaiHN+EEPYSIXUJJe 5PuVWXkn/wCLvBP83l2t/rBrtfltQD/i7c07qeolp86o/EWLtEkvdn3VxF4v/mZ1+r+Y6pH9qxnH H0ZS/YP14p+h1H1I1/nrHf8Anxq7RJH3ZdaP0VxF4TJx/r3T6Zst9Qh7RTDqnO3n93cJ458pnRM7 pX1y6ll7MzJ+zWhmgc8M9hOu0UAg9p+U9l2teNF7six3qWGWsMQGM/daPPue/wBwUsjHZewAksew 7q7G/Sa7xH+uqPu+EfOk8Xk8rjf4vKJ352Y+1x1cK2hv/Sdun7lsYn1T6BiwW4jbHD860mz8He38 FqsDg0B5DnQNxAgE94EmFJNOSZ3KLLCuqqpgZUxtbBw1oAH3BTSSTEKSSSSUpJJJJSkkkklKUX7g 07AC6DtBMAntJgqSSSkGNjelussd6mRZHqWRHHDWjs0dh/FM7HezI9fHIbvI9es/RcON4jh4/Hg9 iLCSNqUhvx6HzvrY6eZaDKIkgpqv6Z01878Sh06Ga2n+CE7oPRHc4GPp4VtH5Ar6SNnuVOPkfVv6 t11Gy3DraxupI3A66ADaZM9gq1H1O6JYX3X4np+p9CkWP9g8XEP+ke/YfiehSR45dz9qbLzuN9Ve gU2jGyMQOsM+laX2RYBrxvgPHcfMdwLrfqt9X28YVeviXH8pWqkkZyPU/aqy5rfq50JogYNPzaD+ VEHQ+igQMDG08amH8rVeSQ4j3KLao6X0wRGJQI4itn9ya7Br2gY1VNbyYNhYJaO5aNup+P8AsVtJ KypBRh42PX6dbBBncSJLp5Lj3lNj49mO41tduxomtpncw/ujxb4eHw4sJJWpSSSSClJJJJKUkkkk pSSSSSlJJJJKUkkkkpSSSSSlJJJJKUkkkkpSSSSSlJJJJKUkkkkpSSSSSlJJJJKUkkkkpSSSSSli QBJ0AUHW49drWvexltmjWkgOdHh3KzfrV03J6p0DLwsUtF1gY5rXmGPFb22OqcR+bYGlh+K43P8A q11Xq7M/rPVsRmP9YMn0aeh4QvYTjNqc0+oHtc1p90vPJj4wkp9ISTNkNAJkxqU6SnP6x0dvVWY4 OVkYb8W3167MYsB3BrmDcLa7Gn6XhysrpX1d6hh/WbMzr83KycV+NRWx9zqD6rgb97HtqqYYr3At 4579ulSSU8czp3X6fq7b9UmYRe11VmHT1Q2V+gMZ+5jX2N3C3e2s/RDILu8LQyMDO6T1anqfTsV2 fjnCZg5GNW5jLR6Li6mxnquYw6PcHe7wjuuhSSU4/QOn5dN/Uep51YoyeqXNtOOHB5rrqrZRWx7m y0uhkmDGvJ5WwkkkprP6b06x5fZi0ve4y5zq2kk+JJCq9N6b05/TsV78Wlz3U1lzjW0kktEkmFpq r0r/AJLw/wDiKv8AqAkpX7K6X/3Do/7aZ/cl+yul/wDcOj/tpn9ytIWTk0YtD8jIeK6qxLnHskpF +yul/wDcOj/tpn9yX7K6X/3Do/7aZ/cuVb9fLP2mXOqjpx9oZpvAn+cnx8v9667Hy8XJrbbj2tsY 8S0tMyE+eKUK4hutjOMro7I/2V0v/uHR/wBtM/uS/ZXS/wDuHR/20z+5Wkkxc1f2V0v/ALh0f9tM /uS/ZXS/+4dH/bTP7laSSU1f2V0v/uHR/wBtM/uS/ZXS/wDuHR/20z+5WlXpz8O/Itxabmvvo/na wdR/r3So/Yq2P7K6X/3Do/7aZ/cl+yul/wDcOj/tpn9ytJJKav7K6X/3Do/7aZ/cl+yul/8AcOj/ ALaZ/crSSSmr+yul/wDcOj/tpn9yX7K6X/3Do/7aZ/crSSSmr+yul/8AcOj/ALaZ/cl+yul/9w6P +2mf3ItGVj5G/wBCxtnpuLH7TMOHIKKkpq/srpf/AHDo/wC2mf3Jfsrpf/cOj/tpn9ytJJKav7K6 X/3Do/7aZ/cl+yul/wDcOj/tpn9ytJJKav7K6X/3Do/7aZ/cl+yul/8AcOj/ALaZ/crSSSmr+yul /wDcOj/tpn9yX7K6X/3Do/7aZ/crSSSmr+yul/8AcOj/ALaZ/cl+yul/9w6P+2mf3K0kkpq/srpf /cOj/tpn9yX7K6X/ANw6P+2mf3KeRm4eKJyb66R/wjw38pXKfWX63scw4fSrJDhFuQ3w/dZ/enwx ymaA+vRbOcYiyfo9R+yul/8AcOj/ALaZ/cl+yul/9w6P+2mf3Lkvq79cRjVDE6oXOrYIqvA3OAH5 ru5HgVvM+t/1ef8A9q9p8HMsH/fYRlhnE1wk+ICI5YEXYHm3/wBldL/7h0f9tM/uS/ZXS/8AuHR/ 20z+5V2fWPoT+M2kf1nbef60KwzqvTLP5vMof29tjD+QphjIbg/Yu4h3Cv2V0v8A7h0f9tM/uS/Z XS/+4dH/AG0z+5HZdVZ/Nva+f3SD+RTQS1f2V0v/ALh0f9tM/uS/ZXS/+4dH/bTP7lR6/wDWPG6P WGAC3LfqymeB+87wCt9J6tidVxRkY51GllZ+kx3gf4FO4JcPFXp7reKN8N6s/wBldL/7h0f9tM/u S/ZXS/8AuHR/20z+5Wkk1c1f2V0v/uHR/wBtM/uS/ZXS/wDuHR/20z+5WkklNX9ldL/7h0f9tM/u S/ZXS/8AuHR/20z+5WkklNX9ldL/AO4dH/bTP7kv2V0v/uHR/wBtM/uVpJJTV/ZXS/8AuHR/20z+ 5L9ldL/7h0f9tM/uVpJJTV/ZXS/+4dH/AG0z+5L9ldL/AO4dH/bTP7laSSU1f2V0v/uHR/20z+5L 9ldL/wC4dH/bTP7laSSU1f2V0v8A7h0f9tM/uS/ZXS/+4dH/AG0z+5WkklLNa1rQ1oDWtEADQADs E6SSSlJJKFrDZU+sOLC9pbubyJESElM1C1z2sLmN9Rw12AwT8JXLn6jEkk50k6kmqT/58TO+o7WN LnZ4a1okk1QAB/1xScGP9/8A5pYDkzf5n/nh6Q5tX6As9zb3mueNpax9h3A8RsiFOi8X7nsafS/M sP5/iW+Xge641/1TtHpGu/cL7DXVvZsJArfZujcYnZAVin6lsuZubnEEGHtNMOa791w9ROMMf7/4 LRmzE/zX/OD16i+xlbC+xwYxurnOMADzJXLf8xf+73/gX/qRT6/009N+ovV8U3G+Ma5wcREAt+iB JgaJkowA0lxfSmSE8hNSx8A78QL0LM3DsyH4td9b8moA2Ute0vaDwXMBkcJsnqGBiPrrysmqh9x2 1Nte1hcfBocRPCwOq4WJh9Q+rdmNUyqz7Y6s2NADiyzGvc9rncnc5oJnkqPRm9LyLevu6uyh2U3M uryxftMYrR+rA75/Rmkg+Ek95TGV6Z9tTI3va3dO2SBMDcY+A1UMbLxMus24l1eRWCWl9Tg9u5pg iWk6griMHHdkdO+qVGc02VPzMkVstmXY4pyzjh4dqf0W3R3bnutnHodR9bOr1dPFdFlvT8W0At/R m7fk1tsexhbu0aAdQYHKSnonWVtc1jnBrnyGNJALiNTA7qNlrW7mNc31gwvaxxjQdz3ie657reP1 tnRn5+bZRfm9KtZnYxxKn1yyr+er22W2kl9Ze3nul0q2rquR1fr1ThZjWMGFgvaQ5rqaGl9j2x+9 a9w/shJTuYuUXYlFuW6qq61gc5tb9zJ27nbHkN3ADvCB1HrFGL0LK6zilmZTj49mRWa3gssDGl2l jdwgxyuVx8anK6P9RqL276n7N7DwQMG0wfEGNR3XXZ2H01/TLsHJaynBvY6mxoIqbFvsIBEQXF33 pKQdOyev3Wj9oYeLj45bIfTkPufu0gbHY9Qj5qpjfWd1v1lyOiW4wqprcaqMv1J9S1tVWQ6s17RB 2WEjU/RKqlv7J6/0rD6bm5GQzNdaMvEvvflBtTKnOFwdaXvrh4a36UGVSysS+636yZOG3dndO6hR m4o7ufTi47nV/wDXK9zPmkp2frV9ZHdAwxdTjjMyC2y30DYK4ppbvtsJ2uMD2t45cFttduaHcSAf vXC9UyquufV/6w/WGr3YpwrMPpzj3rY3ffYNJG+32/2Au4q/mmf1R+RJTNJJJJSkkkklKSSSSUpJ JJJTk/WnpuV1XoOXg4hb69oY5jXkhr/TsZYanEdrA3YfiuQzPqp1vrVPUeu9TwfR65b6NPR8VtzX fZG1OafU9Rpa36UvPJj4wj/W/N+q2B1nNxM/H6lmZfWcSn7TThe5opqeQwtl7C2S3UDT7zPLV4v+ LoWNI6H15hBEO2ca8+22fuSU+zNkNAJkxqU6SSSlJJJJKUkkkkpSSSSSlKr0r/kvD/4ir/qArSq9 K/5Lw/8AiKv+oCSm0sv6wdFHWMH0BYa7azvqMnaXRw9vf+C1EkYyMSCNwggEUer5Q3pHUXdQ/Zwp d9qBgs8P5U8R5rph/i8aa27s0tsgborls949wK670q/U9XY31CNu+Bu2zMTzCmppczM1w+lijgiL v1PG/wDMTPr/AJjqUDge1zNPk8pf81/rZVrT1Tzj1rR+EFdkkm/eJ9aPmF3sw6WPq8b+zPr3T9DL 9SP+EDv/AD41Ld/jDq5HqDgfzB/JquySS949YQP+Cr2u0pD6vCdQ679cMbGc3Mq+zss9guDIIPgH AkArncXMycPIbk49hZcwyHD+PjK9ZyMenJpfRewWVWCHsdwQue6f9SsTF6g/Iud69DTOPU4f+fOx hS48+MRlcRHwHVjnimSKkT59GjX9b/rGQ137M3tImW12wQe45Tn66dZBg9Mgjyf/AHLsklF7kP8A Nj7WTgn++fseNH126q2TZ0z2j+uPytKb/n7mf+V3/Td/5Bdmkl7mP/ND/GKuCf7/AODxv/jgXMH6 Xp0Tx+kLfy1lU+p/XnLzMV2PjUfZC/R9gfvdt8G+1sLvlV6j03F6liuxspu5h1a4fSa7s5p8U6OT ECD7df4V/ggwyUfX+D5p0nq+X0rKGRjukHSys/RePA/3rra/8YHSyP0mPe099oY4T83tT9E+plOF kPyM4tySxxGOyPbH77ge/l2W4/pPSrPp4dDvjUw/wTsuTDKXymXiNFuOGQDevA6uUz689Cd9J1rP 6zP/ACJKOz63/V5//avafBzLB/32Ed/1b6E/nCqHb2jb/wBTCrv+p/1ef/2l2nxa+wfhuhR/qO0x 9i/9b/VP2thn1j6E/jNpH9Z23n+tCsM6r0yz+bzKH/1bGH8hWQ/6jdCdwLWf1X/+SBVd/wDi/wCl n+byL2/1ix35GNS4cP70h5hV5f3Qfq6vWPrBg9MxfVL23WvH6GphBLj4mOAs3oP1xx8tjqupvZj3 tkiwnaxw8NeCFjdb+pl/Tsc5WJYcmpmtrS2HtH72nI8fBUegfV7I6xfOteIw/pbv++s8T+RTRxYf bJ4r/rf2MZyZOMCvo9nk/XDoFGgyDc4dqmud+MBv4rLyP8YNE7cTDfYTwbHBv4N3/lWpjfU/oGPB +z+s4fnWuLvwkN/BamPh4mMIxqK6R/wbQ38gUV4RtGUvM1+TJWU7kR8hbyP7d+uefph4XoNP0XCs j/pXHal+wfrjn/0zN9Fp+kw2H/qahtXaJJe9XywjH6WVe1fzSkfq8jj/AOL7Hndl5j7CdSK2hn4u 3ofW/qRVXi+t0re6yoe+lx3F48W/yvLuuySQGfJYPFfh0V7MKqnj/q79TqjT9q6tXudYP0eMZG0H 858Rr5dlrP8Aqf8AV5//AGl2nxa+wf8AfoW0khLNMm+IjyKRjgBVA+bzz/qN0J3AtZ/Vf/5IFAf/ AIv+ln6GRe3+sWH8jAuoSSGbJ+8Ve1D90PHv/wAXlJ/m85zfDdWHfkc1R/5jdRr/AJjqUfJzdBxw 4rskkfvGT96/oEezDt+L5b1rpPUem5O3OJsNmrb5Lg/+07WQj9FxfrHT/lHpVLyzVpd7YcO42uPu C9DzcHEz6Dj5dYtqJBg6QR3BGoRq666q211tDGMAa1rRAAHYKQ816a4QT1valnseq7IHTu8d/wA7 frFif07pug/O2WV/idwVij/GDguj7Ri21+Owtf8Al2Lq1XvwMHJn7Rj1Wz3exrvyhR8eM746/ulf wTG0/tDmUfXHoF0A5BqJ7WMcPxAI/FaFHVemZEehl02E9g9s/dMqlf8AVLoF8k4orJ71uc38AY/B Z1/+L/pr9aMi6o+Dtrx+Rp/FKsJ6yj5i1XlHSMvLR6lZPWfrHg9IdXXbNlryJrZy1h5cf4BYX/Mr rOL/AMn9SiONX1f9QXLmOo0Z1GZZXn7vtIPvLzuJ893dSY8EJH5+IdtisnlnEfLwn7X1XGyaMqhm RjvFlVglrh3RV510Kn62sxXWdHDhjWO1k1bSRpLRd+ULS9L/ABh2fSfsjzoH/UpssABI44fU6ro5 SQPRL6DR7NJcZ9m/xg/6X/pVJfs76+u9xyYJ7eo0fkEJvsj/ADkPtT7h/cl9j2aS4z9mfXs6HLie /qD+5M7oP11c0tdnyDoR6z//ACKXtR/zkVe4f3JOj1X65YeDnsxam/aGNdGTY0/R8meJHdb2PkUZ VLL8d4sqsEteOCF5PmYeThZDsfJYa7WHVp/KD3XdfU3pPUMDGfblPcxl8OZin83+WfAnw+9SZsMI wBB1/wCksx5JykQRp+T0aSSSrM6kkkklKSSSSUpRcxj27XtDm6GCJGhkKSSSmJa1xaXAEtMtJHBg iR8ikGtDi4ABzoBdGpA4/KpJJKUh30UZFL6Mitt1NgLbKrGhzXNPIc12hCIkkpHZj49rq3WVMe6h 2+kuaCWOgt3Mn6JgkaKvl9H6Tm315GZhY+TfT/NW21Me5sa+1zgSFcSSUjfj49j6n2VMe+gl1LnN BLHEFhLCfonaSNEhj0C92QK2C97Qx9oaN5Y0ktaXckAuMBESSUsQCCCJB0IKFRiYuNjtxcamunHY C1tNbQ1gB5AY0Ad0ZJJSBuDhMbQxuPU1uJ/RWhjQKvaWfoxHt9pjTsiW01X1uquY22t4h7HgOaR4 EHRTSSU1MDpPS+mhzen4dGGHmXiittcnz2AI9ePRW+yyutjH3uDrnNaAXuADAXkfSO0AaoiSSmu3 p+A3D+wNxqhhbSz7KGNFWw8t9ONseUI4AAgaAJ0klKSSSSUpJJJJSkkkklKSSSSU4H1n6L9V8kM6 l1mxuDfQNlXUG3HHtYNYa2wOE/SOmq47B+tX1lq6g3D+rF931t6ewltj8mk1mvaGjb9s9geTzucP vW79bfqJnde63V1XGzqaBTQKBRkYzMpkhznl227czXd+6nZ9XP8AGHW0Mr+tFTGN0DW4FAA+ADUl PZJJJJKQZmZRhY7si8u2NgQxjrHkngNZWHOcT4AKt0zrmB1R9tWObK78fabsfIqsotaHztd6dzWu gxyreScgUWHFax+QGn0m2uLWF3YOc1riB8iuc6W/Lr+tGUerVNr6rlYTTjfZ3GzHOPQ90tDntY/e H2jduaBxCSnQs+tnRash9DrLSyqz0bcptFrsZlgMFjshrDWCDofdodCrPU+tYHTDU3INj7sifRoo rffa8NEuLa6WudA7mIXNYYrP+Kexw93qdJvssceXWuqse9xPdxeSSfFWegG6z6xVnNg5VfQ8IwJI DrLLfX2btdXMbPwCSnoendSw+pY/2jEeXMDix7XNcx7Hj6THseGua4eBCtLnfq/6w+tH1nb7fs3r 4hriZ9Q4tfqz2/dXRJKUqvSv+S8P/iKv+oCd+Ve15a3DueAYD2mmD5jdaD+Cq9Nyr29OxWjDueBT WA4GmD7RqN1oKSnTSVX7Zkf9wb/86j/0sl9syP8AuDf/AJ1H/pZJTaSVX7Zkf9wb/wDOo/8ASyX2 zI/7g3/51H/pZJTaSVX7Zkf9wb/86j/0sl9syP8AuDf/AJ1H/pZJTaSVX7Zkf9wb/wDOo/8ASyX2 zI/7g3/51H/pZJTaSVX7Zkf9wb/86j/0sl9syP8AuDf/AJ1H/pZJTaSVX7Zkf9wb/wDOo/8ASyX2 zI/7g3/51H/pZJTaSVX7Zkf9wb/86j/0sl9syP8AuDf/AJ1H/pZJTaSVX7Zkf9wb/wDOo/8ASyX2 zI/7g3/51H/pZJTaSVX7Zkf9wb/86j/0sl9syP8AuDf/AJ1H/pZJTaSVX7Zkf9wb/wDOo/8ASyX2 zI/7g3/51H/pZJTaSVX7Zkf9wb/86j/0sl9syP8AuDf/AJ1H/pZJTaUKaKaKxVQxtVYmGMAaBOp0 CB9syP8AuDf/AJ1H/pZL7Zkf9wb/APOo/wDSySm0kqv2zI/7g3/51H/pZL7Zkf8AcG//ADqP/SyS m0kqv2zI/wC4N/8AnUf+lkvtmR/3Bv8A86j/ANLJKbSSq/bMj/uDf/nUf+lkvtmR/wBwb/8AOo/9 LJKbSSq/bMj/ALg3/wCdR/6WS+2ZH/cG/wDzqP8A0skptJKr9syP+4N/+dR/6WS+2ZH/AHBv/wA6 j/0skptJKr9syP8AuDf/AJ1H/pZL7Zkf9wb/APOo/wDSySm0kqv2zI/7g3/51H/pZL7Zkf8AcG// ADqP/SySm0kqv2zI/wC4N/8AnUf+lkvtmR/3Bv8A86j/ANLJKbSSq/bMj/uDf/nUf+lkvtmR/wBw b/8AOo/9LJKbSo9T6L0/qnp/a69xqILXNMOgGS0nwKJ9syP+4N/+dR/6WS+2ZH/cG/8AzqP/AEsi CQbBooIBFHVsV1srY2utoYxgAa1ogADgAKSq/bMj/uDf/nUf+lkvtmR/3Bv/AM6j/wBLIJbSSq/b Mj/uDf8A51H/AKWS+2ZH/cG//Oo/9LJKbSSq/bMj/uDf/nUf+lkvtmR/3Bv/AM6j/wBLJKXyOnYW TfTkX0tstxzNTzyD/FWVV+2ZH/cG/wDzqP8A0sl9syP+4N/+dR/6WSs/Yqm0kqv2zI/7g3/51H/p ZL7Zkf8AcG//ADqP/SySm0kmaSWgkFpIktMSPIxITpKUkkove1jS95DWtBLnHQADklJTJJYp+uP1 bBIOZqNNK7SPvDFC763/AFcsrcwZzqyeHtrtkEag/wA2ncEv3T9iaPZ3Ulz1X126GKXG6+bWSIZX ZD4GhZubpPg7j8Usb639CAdZkZ02WQSxtduxgHDW/o9fM9/wS9uXY/Yqj2ehSWL/AM8vq3/3M/8A A7f/ACCNk/WHBq6UerUH7TiVvY257Tt2Mc5rXvcHx9AO3HyQMZDcEIouokqV3U66+qYvTGsNluVX bcXA6Mrq2Dcfi57QFk4/X8HA6F+0GU3uoOc/GNZebbN7sp2O5zdxJI3ahvhogp6NJVMG7Nycdzsz GODaXOa1gsbYdn5r9zRAPiOx8Vy9b+nD6x4NP1f6hbk5bb3jq9b8q29voNZYH+oy2xzWv9QNgNAI +CSns0lxfXczNw/rXb1CvIuGJ0zFxLcnFD3Cp1F1uRVkPdX9EljYfMT7Vr/WfIuuZjdKxLX1W52+ y22l+x7MahvqWOa4a+52yvT95JTupLK+ql1t/wBWOk3XPdbbZh0OfY8lznONbSS4nUkrVSUpJJJJ SkkkklKSSSSUpJJJJSkkkklKSSSSU5n1j6s7o3RsjqLKxbZVsZUxx2tL7bG0s3Hs3c8T5LnP+cf1 l6f0nr93U34t2d0V9BHpsc2kiyuq59Ylwdw/aD49uy6br93SqOjZdnWS0dOFZGTukgtd7dumskmB HdeX4rPqpVmHK/Z/1mz8dz22totrD8d5rj0nH3tc8NAAbuPCSn19p3NDh3Ep0kklNXPwfttLaxfd ivY7ey7HfseHQW8ODmuEO4c0jyVbp/QqcPKdn35F2fnur9H7VkFm5tc7tjG1MrY0E6mG691ppJKc J31QwnepQMrJb0y6x1t3Sw5n2dznvNjwT6fqhjnGS0Pj5aK31LodWdfTl1ZF2Dm47HVVZOOWbvTe Wl1bm2sexzSWjlvwWkkkpp9L6Xj9MpfXS59tlzzdkZFp3WW2OgF7yABMACAAANAIVxJJJSlV6V/y Xh/8RV/1AVpVelf8l4f/ABFX/UBJTaSSSSUpJJJJSkkkklKSSSSUpJJJJSkkkklKSSSSUpJJJJSk kkklKSSSSUpJJJJSkkkklKSSSSUpJJJJSkkkklKSSSSUpJJJJSkkkklKSSSSUpJJJJSkkkklKSSS SUpJJJJSkkkklKSSSSUpJJJJSkkkklKSSSSUpRsYyxjq7AHMeC1zTwQdCFJJJTi/8zfq3/3D/wDB Lf8Ayahd9Ufq3VW5/wBhc8jhjLLS4k6AD9It1JO45fvH7U2e7z1f1J6I6l/rUbLbJI2WWEVyNA3c 73R4n/YljfVHoLg6u/A221wC4WXbHA8OYfU/Dt+J6FJL3Jdz9qrLi/8AM36t/wDcP/wS3/yats6J 0yrpt3TKqQzEyGvbbXJdIsG10l5JOivpIGUjuSUWXnPqn0zrFDrsvrjQ3MZVVgUEPa8Poxgf0/t+ ibnvLiPIKs3ofVB9XqcM0frDOrjLczez+Z+3nJ3zuj+b90c/NdYkgpHebm02Ooa2y4NJqY9xY1z4 9oc4NdAJ7wVzvUaerdcvwaXdMf077Fl1ZL8y+yp0NqO5zaPQse4mwe07tuh+S6ZJJTinpNl/1h6h fk0h/T8zp9OKS4tIeQ/I9RhbM/RsHIhUfq30XrGNTmWdW9+RXUOnYEvDi7FoDtlriCYfc50u+AXU JJKc36t4mRg/V7puHlM9PIx8Wmq5kh217GNa4S0kHXwWkkkkpSSSSSlJJJJKUkkkkpSSSSSlJJJJ KUkkkkp4v65YX146szN6Th4nT7Oj5DGtbZe54u0DX79HhoLXjTTso05X+NiplbH4nSXtaGtLi6wO dGnItiT8Fu/XDpmb1b6s9Q6fgP8ATysiuKzxuhzXOZ/baC35rk+udX6x9ZOlj6uYX1fz+n5brKQM m1np04/o2McbGW6cBukduElPoqSYSAATJ7lOkpSSSSSlJJJJKUkkkkpSq9K/5Lw/+Iq/6gK0qvSv +S8P/iKv+oCSm0kkkkpSSSSSlJJJJKUkkkkpSSSSSlJJJJKUkkkkpSSSSSlJJJJKUkkkkpSSSSSl JJJJKUkkkkpSSSSSlJJJJKUkkkkpSSSSSlJJJJKUkkkkpSSSSSlJJJJKUkkkkpSSSSSlJJJJKUkk kkpSSSSSlJJJJKUkkkkpSSSSSlJJJJKUkol7A4NLgHOnaCdTHMKSSlJJJJKUkkkkpSSSSSlJJKL3 NY0vedrWglxPYBJTJJCxsmjKorycaxttFrQ+uxhlrmnggqdlldTHWWODGMBLnuMAAckkpKZJKj07 rnRuqPezp2dRlvq1sbTY15A4khp4Rquo4FuZbg1ZNT8zHAddjte02MBgguYDI5CSmwkq+bn4PT6P tGfkV4tAIb6tzwxsngS4hH51CSl0kkklKSSSSUpJJJJSkkkklOH9duoZ/Tfqr1HN6dIyqax6bhy0 Oc1r3if3WkuXCdbwz0ezNpu+tfVPtGNXRfjUOy3B+Sywne2rXVx2kCJjuu6PVsi/63v6C70hhV4A ybGPE2WvfYa4AOmxoGvmqv18vxuk9GHXW4mNkZPTbKvRF9bXHY+xlb2VuiWGDMjwSU9MDIBiJ7Hl OmadzQeJE6p0lNfNGc7Hc3AdWzIMBr7g5zG+JLWlpd8JCyuk9R6qzrWV0XqllOS+jHry6sqhhpBZ Y59ZY+t1lkEFnO5XOv8AXMToPTLOo5cljCGsYIBc952sbud7Wye50Cy/q1m9EysjJfV1LHz+sZ49 TK9F4fsYwbWV1jkV17vmTPdJSD9u/WG3o931nodjN6XUyzIpwXVPNtmNVPvN/qgNc9rd4Hp6cFX8 zqvUMzqNHS+jPqoe/GGbk5V9brQyp52UsbU19UueQ4/S0DfMLAq6pi0/Ua36tWvA66zEt6a3pw/n n27X47HVs+kWO+lu426q9R9m+rHWsc57243T7OlY+HXk2GK2W4bnfo32O0G5tvtk6wUlOx0PqeXl WZ2DnbDm9MubTbZUC2uwPrZcx7WuLi2Wv1EnVay5z6sVV5HVuuddpBOP1O6hmNaZAsqxqW1eoyfz S8ug9/gujSUpVelf8l4f/EVf9QE78W9zy5uZcwEyGNFMDyG6on8VV6bi3u6diuGZcwGmshoFMD2j QbqiUlOmkqv2PI/7nX/5tH/pFL7Hkf8Ac6//ADaP/SKSm0kqv2PI/wC51/8Am0f+kUvseR/3Ov8A 82j/ANIpKbSSq/Y8j/udf/m0f+kUvseR/wBzr/8ANo/9IpKbSSq/Y8j/ALnX/wCbR/6RS+x5H/c6 /wDzaP8A0ikptJKr9jyP+51/+bR/6RS+x5H/AHOv/wA2j/0ikptJKr9jyP8Audf/AJtH/pFL7Hkf 9zr/APNo/wDSKSm0kqv2PI/7nX/5tH/pFL7Hkf8Ac6//ADaP/SKSm0kqv2PI/wC51/8Am0f+kUvs eR/3Ov8A82j/ANIpKbSSq/Y8j/udf/m0f+kUvseR/wBzr/8ANo/9IpKbSSq/Y8j/ALnX/wCbR/6R S+x5H/c6/wDzaP8A0ikptJKr9jyP+51/+bR/6RS+x5H/AHOv/wA2j/0ikptJKr9jyP8Audf/AJtH /pFL7Hkf9zr/APNo/wDSKSm0kqv2PI/7nX/5tH/pFL7Hkf8Ac6//ADaP/SKSm0kqv2PI/wC51/8A m0f+kUvseR/3Ov8A82j/ANIpKbSSq/Y8j/udf/m0f+kUvseR/wBzr/8ANo/9IpKbSSq/Y8j/ALnX /wCbR/6RS+x5H/c6/wDzaP8A0ikptJKr9jyP+51/+bR/6RS+x5H/AHOv/wA2j/0ikptJKr9jyP8A udf/AJtH/pFL7Hkf9zr/APNo/wDSKSm0kqv2PI/7nX/5tH/pFL7Hkf8Ac6//ADaP/SKSm0kqv2PI /wC51/8Am0f+kUvseR/3Ov8A82j/ANIpKbSSq/Y8j/udf/m0f+kUvseR/wBzr/8ANo/9IpKbSSq/ Y8j/ALnX/wCbR/6RS+x5H/c6/wDzaP8A0ikptJKr9jyP+51/+bR/6RS+x5H/AHOv/wA2j/0ikptJ Kr9jyP8Audf/AJtH/pFL7Hkf9zr/APNo/wDSKSm0kqv2PI/7nX/5tH/pFL7Hkf8Ac6//ADaP/SKS m0kqv2PI/wC51/8Am0f+kUvseR/3Ov8A82j/ANIpKbSSq/Y8j/udf/m0f+kUvseR/wBzr/8ANo/9 IpKbSSZoIaASXECC4xJ8zEBOkpShdYKqX2lpcK2l21okmBMAeKmkkp413+MQBxA6eYB0m6D/AOe0 3/jif+a//wAG/wDUS7NJS8eL/Nf88sfBk/zn/ND5bn9d6hm9QGe6w12VmaWtOjB4D+K3av8AGFa2 trbsIWWAQ57bdoJ8dvpmPvV/qH1JxcrqTMml/oY7zORSPH/g+wn8F0VFFONSyihgrqrEMYOAFJPL hMY+ji8NqWQx5AT6q/G3kP8AxxP/ADX/APg3/qJaOV9Zbrfqjn9axKjj341Vjq22e9u+tu6e24Lo lR63039rdIzOmep6P2yl9Pq7d23eI3bZbP3qKUoEemHCe/FbJGMwdZcX0pzLsvrOB1PpbsnJZfj9 UuOPbiisNFTvStvY6qwe4xs2u3TPIhPRkdY6zbnW4Oa3Ax8PIsxcdoqbabLKJZa6/wBT831NAGbT A+lqtDP6T9su6bb6vp/s3I+0Rtnf+isp28jb/OTOqpnoPUsXKyn9J6g3Exs60330WUesWWPAFj6H CysN3xuO4OG7VRr2hX9ZOqZ2H0OzGFVGR1HJvxMoOaXsa+iu8PczUEjfTLfEcq5g9SzcLqnUen9S yDmU4mPVm15Aqi0Msdc11ZroHv2+l7drZ7anVGZ9WsehvSK8aw11dHtfcA4b3Wmyu2txc6R7nOtL ydZKtVdL9PreR1b1Z+0Y1WN6O3j0n2v3bp1n1OI7JKc7N+sjDj0dQwDYcSnKrpz2249tTvSu/R72 i9lboY9zXEjSJVhvUsq/q3UqKi37H07HY1xgEnJsDrSJ/kV7NP5Sv9RwaOo4GRgZAmnKqfVZHMPG 2QqfRuiP6b0uzDuyTl5WQ59mVmOYGGyyz27yxpPDQ1o14CSnJZ1vq9vSvqy/GdUzI6wGtvLmexu7 FfcXNaP3S2QPkuiox7mYLaMyz7fa1pD7HsYz1DMiWN9gWbj/AFb9DG6FR9o3fsKPdsj1YofjcbvZ 9Pd3WrmU33Y7q8e84tpgsua1ryCCHQWvBBBiD5cQdUlPNVZNuR9bsDI6liWdIsbj30YdVhrsOQ5/ pveDZQ97G7GskNJk89ln3Rg9f6r19ogdP6lTXmOA1OJkYuNXbJ8GO2WHyauho6J1C7qGNn9YzWZT 8Avdi1Y9Jx6w+xvpmx4dba5ztpIGsao1XQaQ/q/2h4vp6y8OsqLYDW+gzHLZk7p2T2SU879d46lj 9Wbo7F6LgWucIBBy8iv268g10z/nrs6v5pn9UfkWDj/VL0fqrldAfmOuyM1loyOoPZLn2WjbvLN3 5rQGgbuAFvsbtaG8wAJ+CSmSSSSSlJJJJKUkkkkpSSSSSnA+sv1So67ZRmU5V3Tep4gIx83HMOAd +a9sjc2dYkLJxv8AF7m5GdRlfWTrmR1mvFe2yjELfSq3tmHPbveDz2A+5dqkkpSSSSSlJJJJKWgT Ma8SkQCIIkeBTpJKUkkkkpSq9K/5Lw/+Iq/6gK0qvSv+S8P/AIir/qAkptJJJJKUkkkkpSSSSSlJ JJJKUkkkkpSSSSSlJJJJKUkkkkpSSSSSlJJJJKUkkkkpSSSSSlJJJJKUkkkkpSSSSSlJJJJKUkkk kpSSSSSlJJJJKUkkkkpSSSSSlJJJJKUkkkkpSSSSSlJJJJKUkkkkpSSSSSlJJJJKUkkkkpSSSSSl JJJJKUkkkkpSSSSSlJJJJKUkkkkpSSSSSlJJJJKUkkkkpSSSSSlJJJJKUkkkkpSSSSSlJJJJKUkk kkpSSSYEHgzGhSUuko+pWHhhcN51DZ1+5Jz2Mbue4NaOSTASUySTAggEGQdQQnSUpVelf8l4f/EV f9QFaVXpX/JeH/xFX/UBJTaSSSSUpJJJJSkkkklKSSSSUpJJJJSkkkklKSSSSUpJJJJSkkkklKSS SSUpJJJJSkkkklKSSSSUpJJJJSkkkklKSSSSUpJJJJSkkkklKSSSSUpJJJJSkkkklKSSSSUpJJJJ SkkkklKSSSSUpJJJJSkkkklKSSSSUpJJRsDixwYdryCGu5g9ikpkksA9J68ST9t5/wCFsH/fUv2R 17/ub/4LZ/5FScEf3wt4j+6XcfY1jq2u5sdtb8Q1z/yNU1zlvS+ttfUH5cue8trPqWGHbHOnjwBC J+yOvf8Ac3/wWz/yKXBH98K4j+6XfSWB+yOvf9zf/BbP/IqfUum9Ts+r2RSLvU6hV+nxHhzv5yoi ytpdoSCWwfIpsogDSQKQSelO4gYl9t9RstofjOD3NFdhaSQ1xaHewuEOiQsPpvUB17reLm4znfYc PBZfGoa6/NEtB8662GR/KWQ63Jf9Uqtt9ldr+tekLmu97WnqTq9CZ4bompe5JAEnQBZfT/rHg9R6 lb0/GZbNVLcht72bK7GOe+oGvdDiNzDrEHtKt9P6bhdNoNGHX6VbnGxwkuJe76TiXEmTyVlVf+Lz J/8ATTj/APtxkJKbGR9ZcPH6/T0Kyq31r2Ne3IAaaQbPV2Mcd24F3oujRWurdUp6VhOzLWWXQ5rG U1AOse95DWtaCQO/crnOs9Ot6j1/q9GPAy2dNwr8Nx4bkU35NtJMdt7RPkiUdRp+s2TRk1tIxumY n2q1hH0czJrcxtTtfpVV79w/lBJT0fTM+rqXTsXqFLXNqy6mXMa+A4NsaHAOgkTqrKx/qd/4k+j/ APhLH/8APbVsJKUkkkkpSSSSSlJJJJKUkkkkpSSSSSlJJJJKUkkkkpSSSSSkGZijLxn47rLKW2QH PpdsfE6gPGrZ4ka+BWH9S2V4/TupV1tiunqee1jfBrb3gDVbma7ObjPOAyqzJ09Nl73V1nUbtzmM sI0/krF+rPTvrB092VV1GvD+z5WRkZZfRdY94fkWGzZtsorG0TzPySU4lfSsHI+oeR9Yr6WP61fh 3dS/aBaPXZdsdczZafc1rIDWtn6IhXsZtH1k6zijqlAvxKOlY+YzDvYCz18tzw59lTtzS5ja4b4S VMfV7r1XSLPqzS/GHSbG2UNzC5/2ivGsLv0Qp2FrnNY7YHGzzI7K/mdIz8bqVPVejCl9jMYYV+Lk PdW19bHb6nCxjLNrmEu/N1nySU1/qu5mN1nr/RqGGvDwL6H4zAIrY3IoZY6uvwAcCY7SukWX0Tpe RhuzMzNex+d1K4X5Aqn02bWNqrrYXAFwaxg9xAk9hwtRJTWf1Lp1byyzKpY9phzXWNBB8CCVV6b1 LpzOnYrH5VLXtprDmmxoIIaJBErTVXpX/JeH/wARV/1ASUr9q9L/AO5lH/brP70v2r0v/uZR/wBu s/vVpJJTV/avS/8AuZR/26z+9L9q9L/7mUf9us/vRxY02uqH0mNa4/BxcB/1JU0lNX9q9L/7mUf9 us/vS/avS/8AuZR/26z+9WkklNX9q9L/AO5lH/brP70v2r0v/uZR/wBus/vVpDdfQz6djW/FwCSk P7V6X/3Mo/7dZ/el+1el/wDcyj/t1n96d3U+ns5yK/k4H8irY/Vun+tkbr2gOsBYTIEenW3v5gpw jLsUWO7Y/avS/wDuZR/26z+9L9q9L/7mUf8AbrP70RmXiWfzd1b/AIOB/ijJtJav7V6X/wBzKP8A t1n96X7V6X/3Mo/7dZ/erSSSmr+1el/9zKP+3Wf3pftXpf8A3Mo/7dZ/erSSSmr+1el/9zKP+3Wf 3pftXpf/AHMo/wC3Wf3qyCDqDI408tE6Smr+1el/9zKP+3Wf3pftXpf/AHMo/wC3Wf3q0kkpq/tX pf8A3Mo/7dZ/el+1el/9zKP+3Wf3q0kkpq/tXpf/AHMo/wC3Wf3pftXpf/cyj/t1n96tIOJY63Ep tfq6ytrnfEgEpKR/tXpf/cyj/t1n96X7V6X/ANzKP+3Wf3q0kkpq/tXpf/cyj/t1n96X7V6X/wBz KP8At1n96tJJKav7V6X/ANzKP+3Wf3pftXpf/cyj/t1n96tJJKav7V6X/wBzKP8At1n96X7V6X/3 Mo/7dZ/erDHtsY2xhlrwHNPiDqFJJTV/avS/+5lH/brP70v2r0v/ALmUf9us/vVpJJTV/avS/wDu ZR/26z+9L9q9L/7mUf8AbrP71aSSU1f2r0v/ALmUf9us/vS/avS/+5lH/brP70e2xtVT7X/RraXO jwAkqaSmr+1el/8Acyj/ALdZ/el+1el/9zKP+3Wf3q0kkpq/tXpf/cyj/t1n96X7V6X/ANzKP+3W f3q0kkpq/tXpf/cyj/t1n96X7V6X/wBzKP8At1n96slzW/SIHxVXLy6WVt23MDjZXw4TtNjQ78EQ CVEr/tXpf/cyj/t1n96X7V6X/wBzKP8At1n96O26l30bGu+BBU0FNX9q9L/7mUf9us/vS/avS/8A uZR/26z+9WkklNX9q9L/AO5lH/brP70v2r0v/uZR/wBus/vVpJJTV/avS/8AuZR/26z+9L9q9L/7 mUf9us/vR32NY6trubHbW/ENc/8AI1TSU1f2r0v/ALmUf9us/vS/avS/+5lH/brP71aSSUs1zXND mkOa4SCNQQe4TpJJKUkkkkpSSSSSmLq2OLHOEms7m+Rgt/ISpJJJKUkkkkppdM6P0zpNd1fTqG47 Mi119oaSd1j/AKTvcT4ccBRHQ+ljEbhij9XZkfa2s3v/AJ71ftO+d0/znujj5K+kkpZYtP1N6BTl tzK68j7SzaBY7MynEhh3ta7dedzZ7HRbaSSmu3BxWZ1nUGsjKurZTZZJ1rrLnMbtnboXnsh4XR+m 4FWRVh0ClmZbZfkAEnfZb9NxJJ58uOyuJJKQ4eJj4OJTh4rPTx8djaqWSXbWMG1olxJOnijJJJKU kkkkpSSSSSlJJJJKUkkkkpSSSSSlJJJJKUkkkkpSSSSSlJJJJKUkkkkpSSSSSlKr0r/kvD/4ir/q ArSq9K/5Lw/+Iq/6gJKbSHa68R6LGPPfe4s/IxyIkkpxMvN6tTnPFOKHOdWwO27rBALyDIDI5PPg h/avrLZ9GnZ/ZA/6srbbVF77p+mxjI8NheZ/6aIpOMfuj6reE9y4Ho/Wez6Vmz5sH/UJfsjrtn85 mQPD1H/khb6SXunoIj6K4B3P2uB/zayH/wA7lz/ZLvyuCI36rY4+ne8/AAf3rbSQ92fdXBHs5Lfq 109vJsd8XD+DQo1dB6fY/IYWuArsDWEOMx6bHd/NxWwkl7ku5Vwx7OK/6r4h/m7bG/GHfwCF/wA2 8qv+Yy4+Rb/1JK30kvdn3VwR7OB9g+sVP83kep/bJ/8APgS+0fWan6dfqf2Wu/6hb6SPud4xP0Vw diXA/b3U6v5/Dj+y9n5ZU2fWmk/zmO5v9Vwd+UNW4oPpps/nK2v/AKwB/KlxQ6w+wqqX734OLR9Y sOqotNdhJfY/hsQ97nj87wKTvrTWPoY5PxcB/ArQxMDFbW4ux6w71LYlgnb6jtvbiIhW211s+g0N +AASMsdn0k/VAEu/4OF/zhzn/wA1hz/nO/IAl+0vrDZ9DF2f9bcP+qK30kuOPSATwn94uBu+tNnA 2D/rY/Lql9g+sdn0snZP8sj/AKgLfSS9ztGI+iuDxP2uB+wep2fz2ZPj7nu/LCHj9AybMeu6vK2+ oxrg2CIDhMaFdGo11srrbWwQxgDWjwA0CXuy/kFcAcL9idXb/N5vHHvePyJfsz6wsiMvd/1xx/6p q30kvdl2H2K4B4/a4H2b6zN4t3f2mn8oS3fWpsyNw/61/Bb6SXuf1Y/Yrg8T9rgfa/rKzmjdH8kH /qSl+1evtgOw93/W3/wK30kuMfuBXCf3i89jdV6vXj1Mrwi9jGNax2x5kAQDoiftjrX/AHBP/bdi 2MWp1ONTS4gurY1hI4loARUjON/KFCJ/eLhftjrX/cE/9t2JftjrX/cE/wDbdi3UkOOP7gVwn94u F+2Otf8AcE/9t2JftjrX/cE/9t2LdSS44/uBXCf3i89k9V6vZj2sswixj2Oa92x4gEQTqpftH6w2 fRxds/8ABuH/AFRW1lVOuxrqWkB1jHMBPEuBCKjxxr5QrhP7xcD1frQ/6LNvfisf9Ul9m+sz/pW7 f7TR/wBSFvpJe52jH7FcHiftcD9k9ef9PMgdx6j/AMgCX/N7Of8AzmZP+c78pC30kvdl4D6K4B4u CPqs3l+ST8GR/wB+Ka/6uY1VYd6ryS+tnYaPe1h7ea30xa1whwBEgwfEGQl7s+6uCPZxHfVaj829 w+IB/uUP+bNrP5vLj+yRr8nLfSQ92fdXBHs4H7E6uz+azI8Pe9v5JS+wfWJn0cnd/bJ/6oLfSR92 XUA/RXAPH7XA2/WlnB3j/rZ/Kl9r+stf0qN39kH/AKkrfSS9z+rH7FcP9YuBX1DrFuVjsvxQ2LPa S1zATse3Vx3Dgk8Laqdkkn1q2MEaFjy4z82NT2Veo+p8x6Ty+PGWuZH/AEkRNlIGqACQCOtqSSST UqSSSSUpJJJJSklSPWujNJa7PxgRoQbmTP8AnIGb9Yel04WRdRm41l1dT31V+qw7ntaS1sNdJkoW O64Y5kgcJ18HUSXn3/jg9a/0ON/mWf8ApVdB9X/rVRnYT7ep342Le20sazeK5YGtIdtseTySmjJE mmWfK5YR4iPs1ehSVH9udF/8sMb/ALer/wDJKWX1XBxOm3dUfYLMShjrX2VQ/wBrdSRt5T7DCYyG 4I824ksqn6xYVmdThmq+oZW4YmRZXtpuLQXObW6Zna2RuAkcSllfWLFoyLqKcfJzXYhAyzi1+oKp bvh0lu52381m52o01SQ6qSy7vrH0qrHwsoWOtp6kSMR9TS/edjrQABrJDTHnoidN6zj9QuyMYVXY 2Vi7Tdj5DQx4a/dseNpc1zXbTBB8jBSU6CSrZfUMfDtxqrtwOZb6FTgJbv2ueA49pDTCHd1HG+13 dPDnDIqx/tFhaJ2McXMaZ/eJaYHkkpupLEp+sHTsPpXS77r7shnUWNGNc9k2WuNZtbubWBDnhugA 50WjTlX5WAMimh1F72Esx8obHNcJAbZs3xr4SkptJLB+ruX1SzqfWcPqOQ3JdhXUNrLGCtjfUx67 nBrZJjc4xucT5qhR1rqlP1uyqsm82dKdlN6fXTsaBVa/Gqyan7wA6Hu3t1J1ISU9akuW+vHWOpYe JZR0m842TRjXZ197WNftqpG1jPeHAGyxw7cNcunrJdW1x5IBKSmSSSSSlJJJJKUkkkkpSSSSSlJJ JJKUkkkkpSSSSSlJJLN6p1puDkU4VGNbn52Q19leNRsBFdcB9j33PrY1oLgOeSkp0klR6V1WnqVV pbXZj349no5ONaALK7AA7a7Y5zTo4EEGCFeSUpVelf8AJeH/AMRV/wBQFaVXpX/JeH/xFX/UBJTa VLrPUv2X027O9P1vR2/o52zuc1nMH97wV1Yv1y/8TeZ/1r/z7WhI0CfBfiAlkhE7GQB+1xf/ABxj /wCV3/g//qJdP0bqX7U6bTnen6Prbv0c7o2uczmB+74LySQum6N9Sf2p02nP+2+j6279H6W6Nr3M +l6jf3fBRQnMn978G9zHLYIwBv2td9ZfSn0JJcV/42//AJsf/Af/AFKl/wCNv/5sf/Af/UqfxT/c /Fre1g/z/wD42XtUlxX/AI2//mx/8B/9Spf+Nv8A+bH/AMB/9SpcU/3PxV7WD/P/APjZeh+sPWv2 LhMyvR9ffaKtm7Zy1zpna791c/8A+OMf/K7/AMH/APUSz+sfUjK6djMvxrX573PDDVXSZAIcd3tc /wAI4WR+xes/9wMn/tmz/wAimSnO9q/Fs4cHLGFkieu+sfwt9Uwsn7XhY+UG7PtFTLdkzG9odE/N HXC4v1Ez7cWm12caXWMa41OY4FhIB2H3DjhF/wCY/WRo3qeg41eNPvT+KX7v4tc4cNmswGv7pe1S XFf8yeuN1Z1T3Dj3WD8ZS/5ofWf/AMtf/Bbf7kuKX7pR7OL/AD0f8UvarL619YcLovo/amWv9fds 9INP0Nszuc395c9/zT+trP5rqsE8/prm/kaVi/WLpnWunnH/AGrl/a/V3+j+kss27dm7+cAiZHCE pyA+Uhfi5bFKYHuCe+g0L1H/AI4PRv8AQ5I/s1/+lV068XPC7P8A5o/Wg6u6rqef0tx1+5CGSRvS /Jkz8rijw1P27v5tbe1SXFf8xusO0d1P2nn6Z0+Epf8Aje5L9LOpS3/iyfwNgTuKX7v4sHs4eucf 4hezc9jPpuDZ4kwhuy8Vhh11bT5uA/iuRb/i4YPp9QJ+FUf+jCiN/wAXOKB7s2wnyYB/EpcU/wB3 8Ve3y/8Anif8ApPrJ9b8rpuczHwBj31moPc50vIcXOEex7ewCo4P186pdnY9N9eMym21jLHhr27W ucGuMusIEBZ/XPqpldPy2U4FWRmVOrD3WtrLgHFzht9gI4AVTD+r/VL8yim/DyaqbLGMssNTxta5 wDnS5sCAozKfF1bcMXL+2Njp8x3+x9LHVOmkwMugk8AWM/vU/t2F/wByKv8APb/euaP+LvpkaZN4 Padn/kVD/wAbrC/7mW/5rVJc/wB0fa1ODl/87L/Eepbl4r9GXVujwcD/ABUvXo/0jfvC5N3+LnFI 9ubYD5sB/iFH/wAbij/uc7/tsf8Ak0uKf7v4q9vl/wDPH/EL2LXNcJaQ4eI1XM9Z+uv7L6ldgjD9 b0dv6T1ds7mtfx6bv3vFUnf4t2z7eoEDwNM/+jAuX6x039ldSuwPU9b0dv6Tbtncxr/oy797xTZz mBtw/izcvgwSmRx+7p8vCY/W3tejfXX9qdSpwTh+j6279J6u6NrXP49Nv7viunXkfR+nv6n1KnCr t9F1u6LImNrHP7EeC6f/AJg9Rb7q+pe4ce1w/EPKUJyI24lcxy+CMgOP2tPloy+tvapLiv8AmP1r /wAs/wAbP70v+Zn1hZ/NdUgHn32t/JKdxS/dP2sPs4v88P8AFL2qS4r/AJofWf8A8tf/AAW3+5L/ AJr/AFybozq3tHH6xePw2pcUv3Sr2Mf+ej9hdPK+vPScXKuxbKchz6HureWtZBLDtMTYPBWejfWn p/WMl+NjV3MsYw2E2NaBALW/mvd+8vNs2q6nMyKch/qX12vZa+S7c8OIc6XamT4q79X8TquXmvr6 Td6F4qLnP3Fns3NBEtB7kJgySv8AY2p8niGMkGjXzE6PqqS4r9jfXuvVudvJ0j1if+qal+y/r/8A 9y//AAQf3J/Gf3S1fu8f89j+17VJcV9i/wAYTPa2/cPHfWf+qEpfZf8AGJ/pv+lT/clx/wBWX2K+ 7D/PY/8AGe1WL/zy+rf/AHM/8Dt/8gsT/wBeT/r9lXGDhNlkIqhX94M2Hk4S4uKYlVfzcr+3R9b6 b1npvVPU+w3et6Mep7XNjdMfTa3wKurzD6u/85ZyP2D/ACPtH81/L2fz3z4W16X+Mez6T9kca44/ 6hGOQkfKfoNFmTlIxmQMkAO05er6vapLivsv+MT/AE3/AEqf7kv2b/jAd7jlbSe3qNH/AFIhHj/q yWfdx/nsf+M9qhZWQzFxrsmyTXQx1jw3UwwFxj7lx/7L+vx0OXE9/UH9yBndF+uVeFkWZOdvoZU9 1zPWcZYGkuEbdZCRmf3SkcvCxeWG/Qur/wCOD0b/AEGT/m1/+lVsdH6xi9YxXZWK17GMeayLAAZA a781zv3l5MvQf8X3/I1//hl3/nupNhMk0WbmeWx48fFG7sdXp0kklK0FJJJJKUoXVMupfTZqyxpY 4DQw4QVNJJTy/wD43vRf9Nk/5zP/AEmgZ31B6ZThZFuPZk2X11PfVXLHbntaS1sNrkyV16Sb7cez MOazA/OS+SfsXrP/AHAyf+2bP/IroPq/9S6M/Dfd1NuTi3i0sbXArlga0h22ysnkld2kmjEAe7LP nsko0BweIeX/APG86L/psn/Or/8ASSn1joLMD6mdV6b01luQ+2i4sZ/OWPe5sQ0MaJ44AXSpJ4jE bBgnmyTFSkSHD63j5FmX9X3VVPe2jN33FrSQxv2bIbufH0RJA1VTp+Zd0K/qOHmYmXe7IzbsrDuo pfc21l5FgaXVhwrLCdnvIECeF06SLG8fg9Gz8Gn6s03VOdZTm5OTlBgL20/aKsqza5wEQ11obPcr SGDdd9aepOe22vGyOnY9IyGF1fuFmTuDLWxDmhwOhkLeSSU4HU/q7HQsvFwrb78oFuTiHKvtvIyK CLaYda5zgNzRICj0GvKysTqPWcvGtxsrqhPp41zNttdFLPSqrc3nV25/9pdCkkp5DBwcxvT/AKls fj2B2Jt+1NLHA1RhWs/SCPb7iBr3XV33Noosvc1721NLy2tpe8homGsYC5x8AERJJTyn1f6lu+sX V3uws6mvqV1D8ay7EvrZFeNXW4ve+sBvuYRqns6Lk54+s9BY+izIyqrsC9zSB6tOPjuqtYTG4NtZ +ELqkklPE2Y3VepfVHrnVMvDtq6n1bHeyrCLCbq6qmGuqrbG4lztz4j86F2dQIrYDoQ0fkU0klKS SSSUpJJJJSkkkklKSSSSUpJJJJSkkkklKSSSSUpYFJDPr1lB+jremUGknuK77/UDf6pe2fiFvqj1 Lo3T+p+m7LY71aZ9K6qx9NrA6NwbbS5jwDAkTqkpyvq+yw/Wf6z3B+7HdkYrGNAGljMWv1Pd/aaI 8l0ar4HT8Pp2OMbDrFVQJcRJcXOcZc973Euc5x5c4yVYSU1n2dRDyK6KXMn2l1zmkjzApdH3qr02 zqI6dihlFLmejXtJucCRtESPRMfetNDx6WY9FdDJLKmNY0nmGiBKSkPqdU/7j0f9vv8A/SCXqdU/ 7j0f9vv/APSCtJJKavqdU/7j0f8Ab7//AEgl6nVP+49H/b7/AP0grSSSmr6nVP8AuPR/2+//ANII eRl9Rx6LL341JZUxz3AXumGjcY/QK8h5FLMiiyh8hlrHMcRzDhBhJSH1Oqf9x6P+33/+kEvU6p/3 Ho/7ff8A+kFaSSU1fU6p/wBx6P8At9//AKQS9Tqn/cej/t9//pBWkklNX1Oqf9x6P+33/wDpBL1O qf8Acej/ALff/wCkFaSSU0b8vqNDA9+NSQXsZpe7mxzax/gPFyJ6nVP+49H/AG+//wBII11LLmBj 5AD2P08a3Cwfi1ESU1fU6p/3Ho/7ff8A+kEDJxr8vb9q6fh5Gydnq2F8TzG7HMcLRSSUCRqNHH/Z FP8A5UdP+8f+8yvep1T/ALj0f9vv/wDSCtJJUkyJ3JPm1fU6p/3Ho/7ff/6QQ7MvqNb6mOxqSbnl jYvdyGus1/QeDFeQ7KWWPqe6ZpeXtjxLXV6/J5SQh9Tqn/cej/t9/wD6QS9Tqn/cej/t9/8A6QVp JJTV9Tqn/cej/t9//pBL1Oqf9x6P+33/APpBWkklNX1Oqf8Acej/ALff/wCkEvU6p/3Ho/7ff/6Q VpJJTRdl9Rbeyg41O+xj3g+u6IYWNP8AgP5YRPU6p/3Ho/7ff/6QRnUsdey8zvrY5gHaHlhP/UBE SU1fU6p/3Ho/7ff/AOkEvU6p/wBx6P8At9//AKQVpJJTV9Tqn/cej/t9/wD6QS9Tqn/cej/t9/8A 6QVpJJTV9Tqn/cej/t9//pBDbl9Rde+gY1O+tjHk+u6IeXtH+A/kFXkNtLG3vvE77GNYR2hheR/1 ZSUh9Tqn/cej/t9//pBL1Oqf9x6P+33/APpBWkklNX1Oqf8Acej/ALff/wCkEvU6p/3Ho/7ff/6Q VpJJTV9Tqn/cej/t9/8A6QS9Tqn/AHHo/wC33/8ApBWkklNGvL6jY+1jcakGl4Y6b3clrbNP0Hg9 E9Tqn/cej/t9/wD6QRq6WVvte2ZueHunxDW16fJgRElNX1Oqf9x6P+33/wDpBYn/ADR6f/5V0f8A sXkf+k10qSBAO4tdGc43wyMb7GnI6b0p3S/U+wYNFPrbfU/WbXTtnb9Ol37xV31Oqf8Acej/ALff /wCkFaSRArZBkZG5Ek9y1fU6p/3Ho/7ff/6QQ6MvqN7C9mNSAHvZre7mtzqz/gPFqvIdNLKWFjJI L3v18bHGw/i5JCH1Oqf9x6P+33/+kFF56jYx1dmLjvY8FrmuucQQdCCDjq4kkpx/2RT/AOU/T/vH /vMrOPTlYrDXi4OJQwncWV2lgniYbjjwV9JKgkykdCSfq1fU6p/3Ho/7ff8A+kEvU6p/3Ho/7ff/ AOkFaSSQixb/ALRi05G3b6zG2bZmNwDolFQ8elmPRXQySypjWNJ5hogSiJKUkkkkpSSSSSlJJJJK UkkkkpSSSSSlJJJJKUkkkkpSSSSSlJJJJKUkkkkpSSSSSlJJJJKUkkkkpSSSSSlJJJJKUkkkkpSS SSSlJJJJKUkkkkpSSSSSlJJJJKUkqGJ1zpWbnXdPxMht+Rjs32hkloG51f042khzSCAdFfSUpJJJ JSkkkklKSQ776sel99zttdYLnugmAPIarP6f9Y+mdQyjh1etTkhnqNpyaLcdz2AwXsF7GbgJ7JKd RJJJJSkkkklKSSQMzMowsd2ReXbGwIYx1jyTwGsrDnOJ8AElJ0ln9M65gdUfbVjmyu/H2m7HyKrK LWh87Xenc1roMcrQSUpJJJJSkkkklKSTEgAkmANSSqPSet9N6zVbd0631q6bPSe7a5o3bWvG3eBI LXAgjQpKb6SSSSlJJJJKUkkqXVOsYPSq6n5Zs/WLPSpZVVZc9z9rrIDKWvd9FhPCSm6kqnTup4/U a3W47LmNY7aRfTbQ6YnRt7GEjzVtJSkkkklKSSSSUpJVOpdVwumVMsy3uBtd6dNVbHW22POu2uqo Oe4wJ0Cfp/UaeoUuupruqDXbHMyKbKHzAP0LmsJGvI0SU2kkkklKSSSSUpJJZeb9YsDCyX411WW6 xkSasPJtZqA7SyqpzTz2KSnUSVPpfVcLq2L9rwnOdTvdXL2PrcHVna8FtjWu0IjhXElKSSSSUpJJ JJSklk531o6VhZFuPZ69rsaDkux8e69lUjf+lfTW9rTt1iZhaVF9ORTXkUPbbTa0PrsYZa5rhLXN I5BCSkiSSSSlJJJJKUkkkkpSSSSSlJJJJKUkkkkpSSSSSlJJJJKUkkkkpSSSSSlJJJJKUkkkkpSS SSSlJJJJKUkkkkpSSSSSlJJJJKUkkkkpSSSSSlJJJJKUkkkkpSSSSSlJiARB1BTpklPPYtVVP14v qqY2utnSMdrGMAa0AZGRoAOF0SwKfqk6rqQ6mesdQsydjKnl7seH1VvNgrcG4w0lx4181vpKUkkk kpSSSSSlLn6Gu6v9Zq+qUiMDpdN2PTd/p7rnM9XZ/IrFcT3JPgtfqWCzqOBfgvtsoZkMNbraXbbG h3O1xBg/JZ/TPq4/prqG1dVzbcbGaGMxLPs4q2gbWtirGY6B5FJTspJJJKUkkkkpSFknIFFhxWsf kBp9Jtri1hd2DnNa4gfIoqq5+D9tpbWL7sV7Hb2XY79jw6C3hwc1wh3DmkeSSnD6Q7KZ9asn9sVN q6nlYbDj/Z3GzH+z0WHcA57WP3h9o3S0doXTLM6f0KnDynZ9+Rdn57q/R+1ZBZubXO7YxtTK2NBO phuvdaaSlJJJJKUkkkkp5362dYwMY4vSczLZhVdQLjk3WODB9nqj1GNc4RusLgz4Ensq/wBTeqdJ y+pddqwciq7dmC2plTgZqGPj1bmx+buELqlUwum0YV2ZdU57nZ932i0OIIDvTZVDYA0iscpKbaSS SSlJJJJKUsvrfTM3Ofg3YN9WPkYGQb2m6t1rDNVtBaWssqP+E/eWoqfUen25jWejmZGDZXMWY5Zq DE7mWssYePDRJTU6R1TOt6hl9J6kyoZeGyq31sfcKrK7t4adj5cxwNZkSfitdUOmdHxunOuua+zI y8otOTl3kOts2DawHaGtAb2a0AK+kpSSSSSlJJJJKeX6k7qNv14xqMQVVur6XdZRkXg2Ma599TLf 0TCxxdAZrvGhK0uh9TzMq/qGBntr+19MtZVZbSHNrsFlTL2uDHlxbo+CNxRup9Hrz7acll9uHmY4 c2nKx9m8MfG9hFrHsc120aFqn0zpeP02uxtTn3W3v9XIyLiHWW2QGbnloaOGgQAAElN1JJJJSkkk klKWZ9Yuo3dP6VbbjAOzbdtGEwyQ6+0+nVIGsAmT5Baap5fS8fMzcLMuc8u6e59lNQI9M2Pb6e9w iSWtJ269/gkpXR+m1dK6Zj9PqJcKGBrnn6T3n3Psce7nuJcT4q4kkkpSSSSSlJJJJKeLvb1t2T1d /wBWdl2DkXuGf6haLRkNbXTf9in2OcGMiLYG/vGi6ToD+nWdEwXdLn7B6FYxt07hWGhrQ6dZEaqq /wCrLG5F1uF1DLwKsqw25GNjmr03WO+m8erVY5hf+dtcPHlaeDhY3T8OnBxGenj4zBXUySYa0QNT qUlJ0kkklKSSSSUpJJJJSkkkklKSSSSUpJJJJSkkkklKSSSSUpJJJJSkkkklKSSSSUpJJJJSkkkk lKSSSSUpJJJJSkkkklKSSSSUpJJJJSkkkklKSSSSUpJJJJSkkkklKSSSSUpJJJJSkkkklKSSSSUp JJJJSkkkklKSSSSUpJJJJSkkkklKSSSSUpJJJJSkkkklKSSSSUpJJJJSkkkklKSSSSUpJJJJSkkk klKSSSSUpJJJJSkkkklKSSSSUpJJJJSkkkklKSSSSUpJJJJSkkkklKSSSSUpJJJJSkkkklKSSSSU pJJJJSkkkklKSSSSUpJJJJSkkkklKSSSSUpJJJJSkkkklKSSSSUpJJJJSkkkklKSSSSUpJJJJSkk kklKSSSSUpJJJJSkkkklKSSSSUpJJJJSkkkklKSSSSUpJJJJSkkkklKSSSSUpJJJJSkkkklOQ/62 /Vat7q7Or4bHsJa5rr6wQRoQRuRKvrL0O/MxMKjMrvu6g2x+J6R3ssFU+pFjZb7dp7rkvrR0PorP rv8AVmlnT8VtWW/LOVWKaw20hjXA2DbD4JnVQ+suBbj/AF6+reF0EY/TrBRliiKh6Ve5ljnuFTNg Jgkjz5SU+hpLgK/rL9YsXo/1ow8zKbkdU+r4aac9tTGb23NLmE1QWS3b4ferQ+sHX+l/VTL+tnVL 68pmVRj34GBXWGNoN0NaHWaOfPqNLp8DCSntUlwXRvrR1U9Z6dQc6zq1HUNzcxjsKzFGM/bvY6p5 pZuZPtO5xKn9aeudXwbs/IwvrDjVv6e02DpDMVtpIAlrbrt5c1zvkkp7pUsTrHT83Ozen41u/K6c axls2uGw2guZ7nAAyAeFymT9ZOv9a6h0fpHRr6+lXZ/TWdUy8p1YvLG2Aba6m2e068z2S+ogzh9a /rY3qBrdltfhi19IIY4hloDgHajcNY7JKeuf1Xpleczp1mXSzOtG6vFc9otcNTLWTJ+iVM52GMwY BvrGYa/WGPuHqGudu/ZztnSV539bum3dR+ueZ9gBHV8Dp1HUOnvH7+Pc7dXyPph8Kx0HrlPX/r70 3qtIDftHQj6jBPssbkWNsZrHDgUlPoaS43E+sPV7fqR1jqz7wc7EfmNot2M9oqc4V+3btO3zHxVa 36yfWPIzfqzg4WRVTb1zpvrXWWVh7G2+m291oaIJIDXAN3Aa6pKe7VLqHWOndNuxKc230rM+4Y+M Icd1juGy0GJ81xeNn/X/ADMbrGEzqWLTkdDse05ooBffDPUY3Yf0dYjk7Tz5San1l6ln9X6T9Suo N9OvPys6h7S4E1C4loDi0Gdu7WJSU+mJLh6PrJ13oPWuo9L69ks6pXR06zqtF9dTaHAVkg07G6QY MEmfNZuD9des2Dp/UG5r8x+ZdW3K6S3CsZVVTYY3VZPo+5zOZL4OqSn0pJcV1Tqn1ozPrjlfVvpG bXg1txK8puQ+ptprDXbXhjXD3F5e0e7gDTVdoJgTqe5SUukkkkpSSSSSlJJJJKUkkkkpSSSSSlJJ JJKUkkkkpSSSSSlJJJJKUkkkkpSSSSSlJJJJKUkkkkpSSSSSlJJJJKUkkkkpSSSSSlJJJJKUkkkk pSSSSSlJJJJKUkkkkpSSSSSlJJJJKUkkkkpSSSSSlJJJJKUkkkkpSSSSSlJJJJKUkkkkpSSSSSlJ JJJKUkkkkpSSSSSlJJJJKUkkkkpSSSSSlJJJJKcbqv1d/aPXukdY+0el+yDcfR2bvU9Zob9LcNsR 4FLO+rjcz6zdN6+cgsPTK7qxj7J3m5rmTv3aRu8FspJKeXyfqT67/rG77Zt/5xtpbHpT6Potc2f5 z3zu8loXfVrDyfquz6t5TnWY7MavFNoADv0TWtZYAZAILQ5bCSSnC6V0f6yYd1DczrTcvDxxtFIx W12WANLW+pbvdxz7QJKzb/qLllnV8TE6ocbp3Wn2X30+g19jbbR7otc/6BPIifAjldekkp5LK+o+ UG9KyOk9Ud0/qnSsRmAcwUtsbbSxobDqnuga6jUq79W/qq7oXUOqZz86zOf1U0uebWgPDqg8OJcD B3F+gDQGjRdAkkpx6/q+1n1qs+sfrkuswxhDH26ACwWl+/drxEQs3pH1Cw+kfWvK+sOJkEV5THt+ xbNGvtc17nCzdxI+jtXVJJKeJt/xd5rq+pYFPXLqOj9RfbcMJtTSW226627g4sDvzBE9+86dP1OZ T1PoOeMokdAxDiMr2fzs1ehvLt3t01iCujSSU42F9XfstvWbPtG/9s2GyNkelNfpR9I7vHss2/6h tv6T0Tpxz31nobvUZkV1gPc9oOxzQ5zg3a6Ha7l1aSSnl+l/UuxmZmdQ6/nnrObm4xwi81NoY3Hd 9JgrrJEnxUuk/Vr6wdKZj4NHXN3S8VzfTpdjMN5qaZ9I3b4jtOyYXTJJKcan6uNq+tl/1k+0Euvx BhjG2QAA5ry/fu1+jxC2UkklKSSSSUpJJJJSkkkklKSSSSUpJJJJSkkkklKSSSSUpJJJJSkkkklK SSSSUpJJJJSkkkklKSSSSUpJJJJSkkkklKSSSSUpJJJJSkkkklKSSSSUpJJJJSkkkklKSSSSUpJJ JJSkkkklKSSSSUpJJJJSkkkklKSSSSUpJJJJSkkkklKSSSSUpJJJJSkkkklKSSSSUpJJJJSkkkkl KSSSSUpJJJJSkkkklKSSSSUpJJJJSkkkklKSSSSUpJJJJSkkkklKSSSSUpJJJJSkkkklKSSSSUpJ JJJSkkkklKSSSSUpJJJJSkkkklKSSSSUpJJJJSkkkklKSSSSUpJJJJSkkkklKSSSSUpJJJJSkkkk lKSSSSUpJJJJSkkkklKSSSSUpJJJJSkkkklKSSSSUpJfKqSSn6qSXyqkkp+qkl8qpJKfqpJfKqSS n6qSXyqkkp+qkl8qpJKfqpJfKqSSn6qSXyqkkp+qkl8qpJKfqpJfKqSSn6qSXyqkkp+qkl8qpJKf qpJfKqSSn6qSXyqkkp+qkl8qpJKfqpJfKqSSn6qSXyqkkp+qkl8qpJKfqpJfKqSSn6qSXyqkkp+q kl8qpJKfqpJfKqSSn6qSXyqkkp+qkl8qpJKfqpJfKqSSn6qSXyqkkp+qkl8qpJKfqpJfKqSSn6qS Xyqkkp+qkl8qpJKfqpJfKqSSn6qSXyqkkp+qkl8qpJKfqpJfKqSSn6qSXyqkkp+qkl8qpJKfqpJf KqSSn6qSXyqkkp+qkl8qpJKfqpJfKqSSn6qSXyqkkp+qkl8qpJKfqpJfKqSSn6qSXyqkkp+qkl8q pJKfqpJfKqSSn6qSXyqkkp+qkl8qpJKf/9kKDWVuZHN0cmVhbQ1lbmRvYmoNMiAwIG9iag08PCAv Rm9udEZpbGUzIDExMyAwIFIgL0NoYXJTZXQgKC9BL2YvaS9uL3QveS9oeXBoZW4vYS93L3IvZS9z cGFjZS9EL20vYy9QL2cvUy9oL2QvdS9sL28vVi9NL3MvRi9vbmUvcGVyaW9kL0wvdHdvL0MvYi92 L3ovVC9rL3RocmVlL3AvVS9xL2ZvdXIvZml2ZS9xdW90ZXJpZ2h0L0IvTy9zaXgvUi9FL3NldmVu L2VpZ2h0L0kvbmluZS94KSAvQ2FwSGVpZ2h0IDcxNSAvQXNjZW50IDcxNSAvRmxhZ3MgNCAvSXRh bGljQW5nbGUgMCAvRGVzY2VudCAtMjA5IC9YSGVpZ2h0IDUxOCAvRm9udE5hbWUgL0JOTElDRitB cmlhbE1UIC9Gb250QkJveA1bIC02NjUgLTMyNSAyMDAwIDEwMDYNXSAvVHlwZSAvRm9udERlc2Ny aXB0b3IgL1N0ZW1WIDANPj4NZW5kb2JqDTMgMCBvYmoNWyAvSW5kZXhlZCAxMjQgMCBSIDUyIDEy NiAwIFINXQ1lbmRvYmoNNCAwIG9iag08PCAvRmlsdGVyIC9GbGF0ZURlY29kZSAvTGVuZ3RoIDI2 Mw0+Pg1zdHJlYW0KeJx9UD1vgzAQ3fkVb+iQDoA/MaxJGJiqqB66IkJSKrCbiAz9Sf2XPQOqItFU Psl3fvfuPR8O0SW6QCuGcKSGzGAkQzMgfesY9h7UgnzGBYVhUCtcsLlBTSFWuF7mM8qm6yGugod/ cGnW/K2NqMjBGewppMWS8onFwRVPdAFD3uwQbYQ7oirLEpUb26urx867usfOu1N7bV3Twjvsen87 0tvweRs7d4Ztm3fne3/+Qk3816YLnc/2Y9bO7/XIrtKTVGHymMUmK3SsJBOxSsnZk8gSWsM3LYqq 4CSMuSPLmbx/qegjCeesSCc75CYJnETzv4Ul+1UWSoSe0j5eP1/2d4h+AGAaeYoNZW5kc3RyZWFt DWVuZG9iag01IDAgb2JqDVsgL0luZGV4ZWQgMTI0IDAgUiAwIDEyOCAwIFINXQ1lbmRvYmoNNiAw IG9iag08PCAvRmlsdGVyIC9GbGF0ZURlY29kZSAvTGVuZ3RoIDEwNTMyDT4+DXN0cmVhbQpIiYxX XW/byA5996+YRwmoFc3o+761aXc3F+1NsXXSCyz2QbGcRKg/srac3PbXX/KQIym20xQGLGmGw+Fw yMPDfyZnv39JzN1uYk1MP2tsVCSWPqKyyMvMzFeTsz8Xy7prHxfnm+Vm264W3badm207OTvf5Wa+ m8RYupuvJ+9m9DHbTuIojsvCzOb8lsWZmT1Nzn5zpH52O7E0VspueMtSU1gbWWdmq8lfwX04tVmU BN/DLI+K4CFMHD0W4TSmwa1OzkOX0Gi9XO7CNKY3021E0LShS+m5VslHGdbZb2EJZVhtbmVwLypo RVoMurtW13hNfqd+A/kMp4mNyuA6tGzuJ//AZGQuREcna8xKt67lcahaxbwLFiEZRMN3Ir2XB7ki xxrs5DWHf5vZvycfZrgDdr9439mSnU/uTRMz+3js/CSqyqpyJq+qKKvKLJdbuCTtwRf+M/f8X4fT EluqpwNzw/90nJROhZGmDcuAXRq0fMqgCYteWIY7HBDHy3EJOrFfs3b2O44TwPPBuiZ9S/Z20HEw BG/oggLzRL5SFS2W3BuSa9mFh17IKpz9xSOXZRQXhQ88KKOIwpkaWMfBx3eVIvDYC84FU9ruEefZ 0lu3pz++TjX1B947PUIUupKsslnwTt0lFxe0zYIH8C7nGps+Hd1gVlk+RXzq9px1UZ5UcXp4lutP n8h40k120zYbfn3YkKW7Bf8Zuk5bHbhL0zXJXokY2qzIoyzL8lIztuXru9Orpf8FH3jHzkHAcNiW bAlfLY+s796ElqJiahE+Oi9TkIIukXliN93rWkRJUvGVY82KRxCa3xa8eodgu9sfGHBJb18wNZdY ptm1wWMpcV2Si9iUm1DMp0XbPb+vj+7Fcoqwp6xzee8p+5Kr8oxcmrhEXNXS+ZIq4iy61zcgAryA KMNYG8Y0tL5jcInJtJK+bvFvfpArEiwjY/J+hchENFmw9q8LM69VcrnUF9qTXJiUETtqCjl9zsWG wSToXj3fChbe18CmYeNGJp/8btvnOrDIz+lu+mifj3Z+t0YOehSbcL57NTYpvTNri0oc/hj6wJH4 6/h1r0YRvCAX+e0HRwPGun4MMSERadi6QIORIrDlYqHBKALrIfTx13BUGZlEqG2bJ4GT3hjIGbyy 8P6BUjR9ZikCmvCBM2GQG29b+wCW+QuYjLUIY8T39BhbNIZjF/sYttVLHk1d5BLnCoWWGUMhX+1f pJuelk5BF5aGU773v2VQ7z2P4ECqgRwpkDNvP72fitD1gYpspCITFZ1utoCqOf7vRZr0ZjlCH59L ldTPO931O/lKMsNWR3USThBykio5cXJ4h5M7F/mC6FhDHLiD9R9paXa4NK+YzYxXH5Xn1OoFxFKk ThhAIEsXMNZyTse3FB6upAcBOf03hBSWK+uXOb7vdXi/pFIFqSlxq4oW8fAJMEu1ymQ2/SlLy/PI kUfoo/TGTOFoSfiU81YGWsnkVNElFXTJFV1SQQausCK+1+dSVy22OmBaHVE1HjJJxDQLFWJUzBVg SBcHQRqlwbEJ2HMwgbGp2TOTGu0cDoiqgKx4TV//FUULOcv6VOm0WfYKOtF1u5JeiGu5oudaTV+u pJCOkKTxSeALFEbXAxRo1ejB5GEYwIKHzTAANQpsBDPrAZo8XmTssJJBnvFqXJAN9NzChvPPJHMl 9KVEZhE6XUAHli96lYJLLxAbZ1+rnt5dJbHgLKeuBO7q2ELQmgUzzCOaw38bBVka7IQq4n/DJBF4 FBgI36LUn7P05ys+3E5g9Fa81Gs215+ENHGtZNx/NtuE/Q5rfr0T2jPN/O6QNV9p5Qd8X7D63//g DWenXNSnpU3zV2KKyGzl6Elo4ZI0V5Cufdw2yA/jk/WtRPFnedDVIUm+ftAMuFCx32X+jxCIOhuS Cd8+ueo11bhpgtyUPNzgf5xBBDqjtFUF95KNtSZrjyBG1ouucbp789XuK1FjOo8Qqz6Dhegcom3V o60j5l+92BbAkzn1U7ZnbNSQZIyrsLVCM8BnCi3D6cEk9WtA2UaE6Nb5c6VrWhFeqzB3dSkQumKF 1L+wyjfc31jo1EVTS4YxhqbDqGF/oOeBGbVo9hRSbYHkUue6llqWBNuJrH7Wy/3YDCaQbJtE5sHh ZOE5BN+GtqDHZ7V6tExPu/aWnu5L48LHtS1PEw9/HfSSJmmhjU1907dN6LDIfMlxl2pHidaMjkX9 FRvmqCts8N5hnnu2VavETtpQhlJuHp81p2mBxoRu73/o9VY8uV+hizgnHZ/ZhCtpOhlboXI1amph Hu92Qu9x7XBF+goaen+Qwyvbs7EGuDz0QYLZiskz/uhbMsqLazJnQG/zsB1o7qg9A3R/5xJh2h7F G7wOdLqBxkYk1qMKdYvHXvSZb2IQyPC/BBaPykGmIZGmv4h1SRxR01tqhr5jwpcFl5dfhJlmCMeY GeQV40EW/Of9B535U2R7gcvrgxkN4SLKlLdmwltp5kJo6XsGryz4CBm/OqKYgNRWFzFf7Ze2KtVh jdnJs4ZIv8tOt7mV5+a5PiNrvKaVPimwcY7jAlL0BaT4KdoRRJV5lWi7BLpUKCMqtEUrhD4VwUKn 36DNpEB+YiBOlFYVgP/E61hQJvJnrTq8zr3qAqwUgadyhZaVQkA80apQULKu9c1v7ytDL0ocoJQV UOSt3vhRyLbE7pJ+E2oLHH1G/iSzA5V+1UICYvhUGzpo8zstly/iHPn4Z+6Pi4jArcq8+z2urYBL VOEUUnbSzHH2cSkQrMOg2XocI7CCsYpu1K2McO4OGT9GpqkgAv2P8IwaS9FKXgeds3TWmnV3YhEW Q81LxI7PG5/KX5cVlOQJ4dvBsa80QTkJc0nOw8Jh7S9y67TKotLlmZLFJ8VehvCevt0bZcL0rYRP qOPDZiejnfqUg23E4CCqmCHGRmHKOOsZKcR2WAfZ6xG1NCIiLPJRKGOpbFQY43rQMZBcEcINTssT 9dQnumPGciLSeseUaZTE5HnlNXyRyD8mxZE3+Ek+WoroGxGowxgIgED/FopoOay/oCwrCBUJCQpC RcdJ/QFikXn3Eve3SfVimNicFLokyQ9N9givrZlen/jT7B70yogY8R3LdE2WLkXA9wll3wv0/J1d LNf8XQq6tADPhZ55/hfisCDvlEmuRUr2BGwHhx3L47h9GKLhoM9Bz3AGqUvP9HSOz64NiSigCERj xnl0qRjgHSFHrEfbier3H2nNB48KtGYcuhobLtXw/SYNYymKj5Gg0mu2+S/2eGluI0ctXinu2ofs JmRcEgc3fKnfGZtgd0G75sqBqc6y/zL4gY/DEE/emod8+WPJGy9ldryo87ldoNQGhmmED7ECPNxx ZcPNkJNY4T2UVbjGAltTDdddd4DpNixEM1a3kFvqf/HzPi/9RXxLqQ4lFdNFdtQNeqWFNFRSnFKy NZYuS9onfDV7siNDk9RoN6VNW4t534SpCt/jLfWJeplrvUy1QRh2kLar3qpm/6yh2veidzq6OGjX /HzX939FhCCEJad7PzWTy5Qe5udyJyh3onTzRU8nZeSsZ5nCZ/dIJvMPKC4YMP+nY6Lc8/EFB+zW s++MXelp9YhxC4/eDiS9MTci9Iyd43VEzG9gQSfZR1y2Yi+ijnG6NkCU0d5z/uuO+PeYqMTpKw1Z 7xeXR0QYi6p3jKcf4Cd1127CLFfagc5Kep/2AayBK0zQjnoi6Z/GPRIfYc6d0nYYaAbMh2zf5wkb omqDVo8jqjp13Xy4s99SQzB0O7FODuboVCYlMuIUdxx3TnGQHKz/P+NVstzGkUTv/oo6AhEi3NXV q2+SZ7xEiGHHUJYdMZpDE2gQCGLRkABp6SvmkyfzvazuxkKIFxS6lsysrFzeey9H8+OjRS1N9+D0 iW9DFp1bFC8YUBbq3KGUt2PE8410MRkXLQZN39TLn+XmTkKdSYZUXApGSwfjD7bc8HNqAty1ckKk u0eaY9WGl4LC1xnNTs3so5goikmauSCQK09p/K/oCQjKYCEwiIarsVJI7bgP2nL3fEKg1K8EmRY7 ijDaXgTPWNJEiLxZY1NW2iaEhYDHzNAyImgQUupC/EdgVQaGBwLX0ivl/40G6JvxKQZNQDmJ6svy deU6VIr0q7yge5op6cV/QU32RpBIJQQ56X11Clhbxhm+kDLYQgaDpQWX7IsyHknH7o2G4ZBrbIsN HUm6JQOiDaQzxn1MjLpABZjJDQca6GzPNBpDoSZgZreDglUkabvjvZmQACmVUIIasOWJKNw+11HA mRqe5HV6sYgHgWFZWXoLzx9/l4f/Qx8btXqGsnpYJwuW2b5aa0lIFUdVEhqV+kM2Nrq8YRnGSYff p9ZAWJoN6/2saw+QzWo+KOE4O3O7rt5TGpTApIVD8V5EU6WzYHFGdHYUpmVM3zKpL3unkM6R54VV HnG4n1RMp0mqLbWcgBkKpQI3nOgl8KXJo3vtyEM8stZ4Uu/Jk+G2icwur8ZBW9SOswuIjUdaTjYz zD5Si7OtDQWY0ntseTP22PLMrQuTs5R8Lzrpbn0ggCdFVXp4hUTGPdaE8JDi7M0O7LETzq45p+yX WE2SZa+Eu0FQXBZCauBiCLUHsB6Ifi8TUpCU02DSDZlCRBuRqjySxkiMVobUQQUeIxe4cc8UuiL4 cAjjIe3sOjLZApXdt9akO0VuPVi+66hVY5WYRTf4s0mb5q9EGkEQmEDk0pKXKdAnq4vZHEZXt0ib /cautTNjmHT3SHac+XtKGqA0jOhpPo6wicnlVl0WMsWWSOk75nrD2gBqKYKoL8rMtf14YBxxKC1d MoclYRdn4H9M1DStXxs5gr6KkKalNRRAae2qAlZHW/wubW6GL0HAiF23tmmkRGWoWytUCJq571Pw JElTFHzfiZ4ubCcyVXM8KgC47oaWcvFVGlMQtb+MkZ5brj630WD54zPWAUgX14UJ8bMo33VKH460 98pZcbi/cdNFA/v7m921cMBJedSWQVSWlpfLo4jzSV1Z/EmLzkXexgxXBBrgbkw/2LREqXztudbg Y8UdS3x85QdhcjmQN1GAJ+Z+sA3YLbcsUb/klvKlzZiL+O5MIexdL227De49d6fczff1bNpRgVRN ddLCJLW21Ua7YtvfPLD0Zv70UGfNz1S/57QkRtLbtKOoC7lQZ8XlV0nCJK/KYE3rN0bfDQc3s0Rg KLQWmy7GBDNk59gdYkowpkopZJW9ZM5EiV0MY8u8cH1srk3OMoqPW6nGmbZxQmcN4zgqIc2tjOZW pK8V6WvaZ9GframK5/YQvXHW/XbHSXrs3zTU5t+g7eob2NWndeHSOp0kRa4cQB19Y+XhAwpKPfrX P+3PW1u4ttHdtnoJUNKsREG5qmRYcBCnS6MmgJHhAS6rR/cSVVLu9S0gdUcZC5MBDIWF+dzEP9jS kTY5KNuPpMexMSFf7C0fzeYo/KuNLY/HZfdpZAK8jfGy7+z7i9Wt4fmqO6/FLT8hppNQ1K9ADHyM KpnkmeAGPkZAc7lGo32H/1+sQ+faiq5oegHFBbxBB0lXcPk1EMW7eAJw44rGFnKHT2O7k9bakFqT c7db7l04CtpyuMLqU0TSmWHcvXXgzKA0RX1VOxr83fWzKqmy8qSNlc85o9pDj+V5XX8zetOQZC4t avmXJjkd9kRVnYXyf09DXmVeFgEE/w+vuyV+WhswoaMpQe2XqDY5EKmoIEUVsa8MnbNmMFamfR1f pY61fbOXuSoZ3WKSmt12fpYU+Rc5UQiylkrbyZOk8Mec6Hs16aN8yZS8BScl9KtPYzeAO7OIOo24 rDvA9GCRqLZ9GvmfRVQXZdicIaeqEQQaOnM4BMgEcauOfg32nGA/81UV7QgnydXzoLpKvuGRTJKz rL2BqgVRf3PAU2acfNY81zV8DUgMeMJnjiuEchp3GQ06T5nWE+Mz/+goB5pOs+SflU2QH7nZGSYz PTTGDn7GTsCMfMDqIvvpKA3RIVxrc3u7+Fmy43NvYVZX/rJXQzbJ8rI0ktP+/VliVyiXN8yntT5h Q0Axbjeal9oDmpVNRdrBdXWjJ8D03azg8goFV0UpofFh1EQFrbvD6tI2P9leCNrYJihZdl83lN9O o4Z4eIvDG/zSXzn+s0l7a9KZtWiPFl33WgBYa0MVvr818/u0YWfWr8v6spfl7etQpHUkSVo5WEXY Au459PXbaoeaujmt5WrMaTUXgXlxVCpj32A9oNjtY2SAkZ0etJ6/jBnGQir3jzpvhzajyM2MjMbW xBY3VIBtrJUTNroz5dAH779NOOlL7yeFRKxByz87Xuf2+quRZ9+/jTXB5B8ijdUPTHLZVS+QTJaw je6c4aDctpbb/jW2orWxxJOfzxY8WTWQ59y/0/I/jnBl11VaIQLgoFdmBmIViNuKMLUflE0tkaCq DTnp0dIRNEn9t5EJnZaoj/Ngab62GGHhfhxHpTB7PyaeyAve5REdBjdoH0RwopuSZHhis4uy5Ik9 gioIBj1qBzo5uLhu3+MV4AG37JXp0qJ3+vO4RzgqZKn7NyetpIo1bwDYLsIPX1WTwofK0vInFbu8 U7PGhCGIctXqebWMVDaTuzGbuCHEadRvnl7fslnyznq/rU7McT9hAlUvX2rhDM+ATIIgXW84Me/k CKNLEJxBEFg7pzgyO20vYbSTE8EKn+7Zmt9UzBR5jm3R7qw8ace5z18ZUb4sxdM+M+IBWqtvqiZC F5TvgRp3WHszThPtBDq9gxue9HcZy7GEGzwnjUVz9CsM3uE/L+KkVufstdq1w2j2OLaQkPkdNrm1 tNJi6Fv3XjelWMT1xQly88PHUwH9FdIzfvGvDKkin+QGUaCNbtB/2mT8gS/woDRkaUbBnCtgsHXL 0syjnXNZZdbbYYjqS65xl+H1v+hfxzfHk7R2QVQd+J2HHq0KQpP6dexF4AoqYOMwjC+A2YtRQ/fo v6zM82NY6/YdWLxDtdBC4k+0PX/3/U8ixX2Yfyc6oSAV6c4rjKHMVE8mo+zo5Hs5mR+fFPqhodwf PunwiSIj3lH/ndVfFnrHgZS3UjwnfDU/CSRLQRqOOKOUV8GX+Fw+lmg18UtKBNbm41y/dggE5qvK ad2vj4/7+IEcD6eA2qpgKDzNTc3coycpBGfKTRSUWic9rGmZ4Tq8v2JOAQEKBVbtkwZDK6+1Alwa HdQURA+6nITQqu1zG8E7KAEIrh2PSY3Lc9uH+bX7WbfvqalmgO6koctwgyw4DtaTdzM3+Kq8nLhS L+tUXk+dmld5QV98vL5+Iw5O0Pc0n14AfmmSQn5yTnYtj+dPZW9n+6kESGnUkShJGejW3S/Rdg2J GSYUArkixyX6mgHXytMbGltFNBkh3JTIRoXPt8ZCbyDrGr8gjlJgfgB/+zDkuGjTxwFlXCKNKPfl NDdn1sKVJP6MuzZa5gmiM/IKaG8kz4XJePUAFpoxmYMgcD+6R7CxBsmfKateA6ZUkBdACtojcD+G KNx9pJgfIeZ3fvwhkaNCmw1mZ1Rh2hd2sh33pGZgeTiwHCfjzkuqjnwpvnlNMAosCT4rrI2wDrN1 7fpWCFY4GrQBJxZAP7RLAdXwPUhqaRODxjjv0nAw+QYg51AS+9Ryhb7sIq7JDJoIhJNSwF6zR0Nm FZBcr861uDNkNWeAFVmRn6VR5haps2UdUsOwZHwE/DKozROD+jK2M3zGTTuJrdxoY85oytUs7lWq qdife/c2rri55WYVXMj4PwRBrzbyUkzu7GgLdcez0ZgtTIurSopU0C8aObqoR587QTDtqbXN8Xr/ p7xamtvGkfDdvwJHq8pmiDdw3PVsUls1M8msk8xZlmxZFYlKLCmp7K/ffoESRRkbHSQSYL/Q6P66 +0aYljs1m3bYrLtesJy1d7NmV6pb16QAOKTgMzydmq1HaMnt322AcdWcHcOsjk10Ad6ixmGtL+Xz JfXn2x3fNcREt9jDHlw/BcUzzYif7/D/wycaEiF+ZDjDOASuNcexiKKvTxOKzCRk+NbR2w7e1Oc/ tgLTUmiEBKqkDHhH5sBvUWYIJ1vIQEtWPZ1E2fzJvdb52qqNreYxOckGaC/grnIPhAgU18PUkp6f j2v1sAZOCVoAtN3hgGW86ORE1MVxe4iDi6L2rzsaOLrhkHKinys46yOa3ZLbTtiPAGA885yCyDiF jdQIrgzjFO49AtDWxh7a1nh5hN4QTFlyDJGVphi5XVfgGLsF/q5eZTRcE0Dr0e43HErhZS9PIAsN VUuLwnesboxL5VDGvFrjnfNNyjgQnRxty9muJftRecLa0e+ihYVmQ986Sm447LJ/2z3LW6EE2IHG jUNGyiSKaY/Y57QHN2cieQ4pzfXfy9056I3S3eajPulsbe9vEFDYe4MuwWOKgdDMFKsjw6sVrIIv fObIkAk9b7fgF8WVt7ChgyyFBBI/0OqxCFEbWj/Rv5rxqteAKNnLv6GTx6OYYfvKDHbEsSAxxb7d Ul6+s26mUWW3WPZ1wDTbDU3rFS77UwOun+vTy2DR2mrGwEDZmhylSRdpy91+it0TJix1RFbqSeQC TebTLcw2vKS05kmDzFnL/ouwCbmS74/lDvFQGF88yTZWrknIqHhV2m8b49nDwdCTI2UNFHcPQ5YU 9X+sCGUQ3J8PdWFPYyG+8aZ6t+cWN2K9AdR7f0/9CC24CixJzneuHkCmdoKsCIxrHjXh9QvLSRIs rPZQbKKQzXFz2w9F/HmPsjrqoY8KShrddIhGUkun12sqXrUzjTEpSWqRUj4HVcGncuaDdR2XOKyE x4VVauIdjy6FWOSVmqi2M6w4z33RpO/k2JVAPRckkD4jh6E+vGucShOkAaYsIhliqdoeVXDUNrRI lQp8BoJKHpj6pNZ7yUJWQsSkAQBZyTfLKACBjNAYKXSjpL0laIw0chHpRpZFBAV9xBwgEVMhW8vz kWQpJrqjvLE4TCHtJ8wH+PgiovYkulNC9W0PaGIxi/aPsqWmhfaBLd2V9fRFSMqRVvL8iRkYBdqt tIwCZrY/5IyXjzeFrBz3B5NvxlDkeigKVSzSUF+Sz04GWTTHCYKEAimHDXKnk/YG23PH45HD3kPD 45b61QfmEuY90XUiYk4rlkCDGvYhaaDDRVhOmXDL4tVu+oXW8lX498W8Yw1bnNSQRfSrIlmoCx2M M20v6gczsSnLGZ+TV2rd66bdIn/gc+krvEtVd7exCcFJg/075pfBnpiDCkdCWEwxy2aCjTR8EQXo JhjjHQQPxq2y3jLUmYDdEs+F5RPGKsjodgIFCZvhhFGnAXr/3SlSOUeB2KkjnlCLDW8b6kZvmPJu oNIzhzAgqKAJAEH5YDjc937FKAfbL+M4NX2cVh0HPTeiSBvYc3RbBgdYrm6G76Z/fJm01FIhxtEG 33nikDQceIYaYNwVLgwjc+jL8cue6btuymoeeL0i+cJGPT0874j9Ay8+sYWqWLorukj885JoFyzt YAbEtul1E+VXJil7y01ZJ5L6EzuFg5qTA3XihldKuba56vPkmmB0KH1hX8GpGKwO1XfWF98V1oOj KnG+tn7ryxIWqb7wq8MAN4Plqnyb952BktGodBHqn/j//v39xzIecXkEHaT+z9/+RR/+wzPZaxiZ AQBz3RUROvW21ekw9jVjAERUaNTHZ95YYhkJPYBxZ7xeLo4hazpBHoHBJS02Q5BSAkz8ccWUK1oo gdkCyq+B9dPZbcQEkgyogKasKJRcr/B5SN7bU1B1N+UPYtLIu+hQzmxTnR990I2PKUoF6qgXwdnK 4gi3fuAntbo0/9FXuGnapqNlysAIz7sJNKF4IbigigTflltek3/skRCQ6XF/x89n2Z6yqo6JS6k7 I7hR7/mt2Dxjzlfkgh3M94WELflrR4s5/VePcabamGjP9+LFtR6WELrs2SV3vAmb5YLuC8rPaY/g B1RXux791YY76dvU47rNUgbU3QeQ+GliTemieH9Pmaqk8OypEkgRkaqHzINy5wfl7seEW36sVwQs mNQPk0M5PE3mEm3uF4ZeF+DNW2hVrEtSjNcYJ5SuPDlho4IWGh6TrtdfEZDoy47+MWES3Cv2bqcj AhmDhkB3ZUg7vXhggAbBZttIIRtjM14pnUQ76Z6d0XSUN2+1gpenE6HWhaaNOQZlU9sEm31k2W9x 0sA+dAG3EWQwNDwY0sCom/NGj3yWdANgSeLdqd3frjSTKhghgvVJwTE8vDg1W1/dls2Yjeyur7AL 0hZmo6Pd1dEuqDG817Mftp6v/r7qrt68u/dqse11HxH2ut/cbYO6u79qieb+7k9MmZTUDzwtOPLl soMCk0Gm9mxYQa10MWc/YP79mHnEkmH20Blu+ZjF1Fmg2DtjX7dwzAExorMeHuquxuJaCA6o+mHA Mq2yaPRbqwccszoHzDEQq0O7nqssAC+hNW7o4sc6S2pScjb+usMANprok04DlnWVxWHapTB02LLO YhtvYFoYsGzrLLlpHYDWBSzeNQA52l7gsYAPneMFWoJvfI6xkjdjFsDBGIcO21Q5IuaXNwOOrsqR ML1s1BeYlWwD2BGGh3+os2Q4/Ild9ZNkdJeOecCyq7OkJjuI419PFt9CJ+J8a3799B7wN5kTu6ou 9hpGUuP9rx/eG3gE115wjx5rlXZhyHI7YIFqb/JZWA4OmTMEQSAgLLXx+0nlO8eam2RT9Kes1cS2 EQoszEz2lOulzhWgbGGZP+GqhoWN0CbqMxbuq1wpNNpHhPchVxXhbdZNSGMDV3Umh9U4p8tcmGNj WoelYcj133rVMk3KbXvZsRzEfAwpjiys5yOUO20cdCqXnMtBtsRAAD7kqsOFoaY2nzLVsc9gn2Dd 6Lrq8GewnwxmpKvuQgvI3CYz0lW3EGumw6nvhGte5wrA5e0ou+rngsrpzRkLv1e5vIfhybSX5b/z MLNZly/Lfxeg6Yhu5Ix6FAK2pZT1KAqr6e8ixm4KI131SwaACh4nkkvyHxpinLDshS5MpoH20Ixc WM//BLNYa8a66ueC+SMn3Y7O9X/qMUBo69OIq34urOLpDFzXKyYW8gRevCi9PDwymDnCmkOi/NXP UDJ5GseDp4UOG4bAN28NT5sjfLatsh77Vxb5cXJrzfVGPcB46RL4AJfzxePk1kfQZyw48zZBu4Jf YTdfqy0MooHf10Q+xdcO/4DWRREyI+LFlBZf1cOjEMDqR5EgIjuSrt7R9h53YNu4a9bEPOo9Le7p Xx1UzmHDDyEE/dEmzw7BugwO0ejHs52CxiKCk6V1BnC3dYk98/mPP27AChhJr9VmoqHvA9PoAa5K uDsxUCHRCmvg+TiBNgCOBoMOfNvOJhGez4OP8/2qX9v2IOkGz6OR4mmiHT+Qaim7RcWSZO5k9+fE QoZCMwUy3HWRIAaU5cvAAPXbByG/P2sf7e3pf4U30OssFizYAzcTOuSp00sQau/F59D1vubzaHLA cIQ+P7f92AUhwdFAYcdBuZnj+x7/IKic5sih4Gj0IRYgYPBKrjninp44DLujuOZI+olRfUv0UwnH JG8vR2GOoji+Sd1RGmzmvU5YzdVXMfO7ZA/QW3ewb5BAGKu0wQo5wr+MPKnFkSmTI1/3nwaAyDCL CVre6kQxxH9LWnf/Y7zaltu4Yei7v4KP2plkI5LLvTw2TjrT6WXcxm1f8qLIsqxWF1deJ81f9JN7 cACuV5GUeDSz4g0gCAIHhzRH2z2/iByk23iWy3fy2bO/KWrT1qOlKzm9ZdMVWRUHHXKldNdYeUfp RRE6U/wC2zCFYTJ88UF23ptBta1ZYhZnhTNCkEWPovOeivMtcc9QmQA3/SifRcFI5fThm4C5j6dK jkN/NhDbiPCL4JJ1k3xSTz4UEmueCRIqvTdmr4QSbmy7fIEURT5h3VXRTV6+U4H6UEBMHglxaimD Kn0rzZ189hq+XLYRgftBdDGMUem2HxlhAC3bzjRIBRz/gC2XV/j8XghwHkHjEF0NiuA385TuCVI0 U2y8umcuMNXJxaBuT7a4VoCOoDaH3f1KYAIhwBOXnpaXxGq5Z8Apl++t+6jdvPiEdGyPpbdH3bwV bYADQObEBR5//z2w5/Z5r7w877V0/+jMo8ov8v9hXElhaei9s3mp/mqrso4hDLwYRaqMSLxUlw2T SLoz2bKZbFZzbczWUlKaydrWlcdBfaKeA3envnahiahx0zaeINWvvq+MDgSVDVb3XAAXqAx9Y/nF dj9BMB0J4nmCajkWPA6xEDTEpj4E5SPHBsRYttWBHgnaEmHrvrsFvpZBYGlaEr2rklCOl1Hu9brk My4Sfy+1N9Pep9m+CL5kyuDrfhaIKIN1TfJO1aG6dOVJ/BDDQ1kzM478FoQsDH4DgE38s7yHMire G4kfe69Kg/fSWe919N5Iz/VKDpSAFa1yB6MOLes2e+4S0NmN6rkAsydN4PDOiv7alh+VpRQNWVuF jq/yzIBmZlM/WMjn0He9lIoOrYXGvvvXZlr7r3EMDM/2ts5y5E7SPrKgtyXZKYahZZ5bj5TbD9q5 /MVoPxBYL9nVF9PRwkddOLfdz2gD2kj/FmgC2z6ys7KledGh6Mx6a8HqkpSC/ZmdY2v9Y5yJGaWn 8dsonULrvLxRUpuMDWzo2TjZ7FAG1D4crVEQwoYr+gGNmes/FZVYsxO0FHIkrl2b/Ef9W+iguyp8 S/tFYDmec9ezD7pVFnXvJ5y50p2u3xc6X9IZ9eTtbF5UDQbuzDZ3f2irmT7P2/DP7M7mD+c4R0fh yvQMHsBHgG+bsoq19wOjGliafpXjLbeZKbYE91qoSqsJxfeUCrp7/Uf6RTHfH5C/D+tML7sJICRC yRV1HQidk3CrkW3cL/LBpka0T1zWCO0L3UHIrtHY0UPOGYXd2WPrQPdhZPqmyw+q9vyLiuzUN8Ia Rux07JKFWry7dRXJz4/c7DXbn4X99PmsZokQSDvE/Mkl5Egjt9yQYksqTo6I96F3fbJnJlicvCFX X3ht/vRg3ekwXw4S0yKlyt7wi7h+GVK+RDH+LeV0KyOSp56pPlmhRJ30z4jRLgL7fS3kYuCqdKhU N3Gpl9LoblhHV4UUT4WlMCAkTsPZPP5ZUgz1b7G1gX404zUnZf2OKRkM7liNdTn6UnOZhR0DfLSL U1ZVsYMrhsYgl0xVtnWWIFbzrhs5xL2tmtn00voLHutB8i1k/cMh85xouFd92Stz7ebd8jk+0rQF Qqiq86Fbucrky3AClvW+YqzbZ3JnFE3kysCd/5QgurPUq5QMMoEltgT+CH41oY/AR9ije3londA1 LGUTAe/Jqp9L3GXFWcKxCmgNMCHBf+x3IyMIFBsdb4IPEq0Sbh3FjZpbHiuRdf1KH2LMoS95Uznt 2vbr1NhXIBzdQI15JJrEfXs11+mZ1mu3fXJGv7qVP7W/H50U/C43jw/KudlWTBd7F2L9ZuT53v0u e20LBXcJR8EEqVwTyvLDNUjz5nyZST6cPbnCoXD1ZmDoHwoiHRGI309Fxh+F316fVzRK681Si8Ed huiwdmKF5uZmAK7uoFy5XJAkT/wxJBLkdqp9VDZ2iqjO3qYZEpfjupDx2af8fL3k328x4+CZ1Gmr 55RjdRm4RqraaCwy33MlF/oyhz7c0SrlQNiGKaoX42QcOs6ILWPscV4kALKTaWHKPaNh4yyw4dRr OzerRYgWKQ+y2XrG2rSiWi421T/JOEf5+VsCjtutbjTsTnC8zPOnzbexRP0xbRBwdWeU/3UR8GK9 vV3IscXeTgL3GqZ4mZMn7/sCqdxIHGDsjksW0gTUhM5kdtKciw5Oweqon93TGmRkbJiRs/XTnI7q CvGjKNbaPewm9MwiCZgDmZt9tmI62kq87+HQwJobGtN/Ooa+nmddKtM0WXW85r28lispiWmDxn8u vIq7qmxRT1uHbE5oVG6+uUgplB1CFU+tDvNdi+HNRcQzqcHAeHQ9Gk0xwZbA0ScNp0fHGv682MKe EFHLAJG0CoRc2qI71pWtT41X8179sPHuze7iV/y+doxXlw+1u3wn8DStHR48jXxTjO7d5S+Q/IvG B+ygZqam40ETilYVm4PR9WhUjKkQwPn4qmE8enfxDrb9L8AALCm4QQ1lbmRzdHJlYW0NZW5kb2Jq DTcgMCBvYmoNPDwgL1N1YnR5cGUgL1R5cGUxQyAvRmlsdGVyIC9GbGF0ZURlY29kZSAvTGVuZ3Ro IDEwMDMxDT4+DXN0cmVhbQpo3px5eZQb9ZVuG2hVJcN0EogYdxWpIg4hIfAIkxUIDiRAWGyId7u9 994tdau171KpVIukprXVor20taTe1Iu723ZjvGEbGzAQT/ZMCJnhkGTem5cw8/LmlJzqzHk/tSEh THJm5h39oyP96ta93733u/erWtdyw3Ut69ata//mM5uffPTxu3YMDveanum1bRsZ7tRt2f70juaf n2zceqO68Ykbb1l9Vbl0K3Tld1Sr3PoR+d6Pyk98TLj1XuymluvXrWu96VP9X7j//s9/a/sOh773 tntv6+nt+4/WWtaBTwvU0vKhm1uwdS0bkJavt7Q83NLyzVtbHC0tcEvLYEuLraVlpGVdoGXdX93W ckfLZ2/euO4byIGWQy2dtzIt3HWJlpYO4HJLewu67ol1xXXy9fdev+n6qeuPXv+/rv/9DaEb3mzd rbpJ9VXVCagTCsJ74d9+6MCH3vlw64dv/7DwV9ob191o+mvsr+fbdB+55yPMR9d99Icfe/xj373p 0ZsWb9528798vKim1W/fEril8Tcr6/Pt97cT7UL7ZPsyIqGfQ+u3dtz6vU/0YUdw923QbUc+qf/k pQ1XPzV5+2duf+fThTs+f8dbn3n8Mz/57GOf/cmdY5978HPP3nXvXRvveutu4u43/0fynm33HLxn uXH/1Ztvudq6Gvh9K5Rt/Ju60b/6i9V+VdttbY37G3zjbnUqlGA5ChaJqNeN7B/ZtvVx7OBLh7/T 9f1L00cnxqtwuZqcnkXqxKSxjJVN2kQv2tXvM2vxLp318HbEHrHGLFjcktBnBjd27uwa6YF1PZ7u HqQ7Ozitw3Qzxzxn0YU5Lj2D19PzlaX5+sCUqeaG3RM1uobOTSdKNbxWys8mn3Ok1tNmn8PthQmX nbGgZjOXMuPmtKGsm51fmXl+8szk6eJ0SkyLRW4iDOeVTkgZ+YGaLQSlLJLn8pkClk8XxUm0KFHu NJ5xczYzMkzqbSbMZhy2dtlci+Qkk4enVreqKbstYEN7h1I1C26u+qbnkGlxqlDDCrXJylIp3y1p cvqcfvLwsS0avcFp98NtJtmltKmtFVeVqBE1ct6/AvsusK9cQS7HX05dxFIv5k9Wj1QX61NLJbgI fa3/qS0d98EdXzV+/jPIt1JPVDZh1U3z20/sr2uWdSeNcB7SlPXjtgqw+6+N36iLxqwhqU/qEwP8 QTixNbb5W8gm5hnvFozYYttr6DX0aoa6LbAdemP+1Ysn34RP/bzyq3eQv/O+ZryMGS73nz/wvKbe NdkxDluhurlmKhjhNvnbjXNqR9GdJjiYI4gIiZL+AE3jNB2g/Iib82RITKAr1BI1zhZpyW+nbIwt METbWH/Ay5A07Ydpf9BPIf4oxVMYzQuBBCoIkRiPJzkpN15LZ3LpfCrkGiVC/hDFumkLTFkCdjfi jvo4GvMLCTaJCnxU4HFeiCZSSJqpEosYXQwWR6WCJ+dOuQqmrDtJw3QyERRQUYhyHM5xUV5EUkyS EDEiYRC6OVPMGncKOa7IVWLHxJoginBCiCWSiBgQaA7jaH/Uh/p8QYbEfYzLZTZ4XC6PgwiXYhWh CgvVaDGNZAMpWsAEimoeJQN+CqdAlE6EiFkSWoy3xCxjZkfSnnUWAHDd8gtX1HJQDi4pQTnQrQSU QLccUIJQ223y/Xeqy5PNbpiiKs48lnfaBQvqdDM+L074GI8LccW8Aon5xSSbQ+PxsUgc55J8JIqG w6PBCB4JjDEMYvAb7WbMYTY4B32wBTqdWyiVJ0EhLMtb1HL8B0oc9OZbf6/2kSzoR3fMmyAxn5hi M2gmFUuIeEKMpTJIhk35RCxBemNu1O1lfSTe9qDMXN2kVujf72ldVMn01T2tbW//i/rho2f7XkFn 6snxWXy2MrlYOguXXki8+mNEXmd8a89l7Ez3gWoHqh32WXV4r2G4y7wTNu/wPfUw8gXp4bnN2PnG LWr+xezRcg0uSHmxhOazrC+F510ZQ7IXznTwmx9GPk0/6N6OkX0evd0Nu+wOyoH2j4yfdODmC74f /hI5H70gvIi1yR9p/FQtlnKxJMrzITaOx9koFSbhiCc8tA9Rfgd1h0xBCgtQDONnSdYWGhqFHXJE gobHbGEyRsYYLijAQTFUXkAa512Q8pWNrW2NTbJaTblJH0H5KIL1BOGg2zQ6gCoPqfK5U2ffePuF i4vnK2fgzCxfn0VOOJb7Z7G5/oO5nWhHp0s7iA9qrQeob8OSKjlfmKjk4Xx1SphB56c9+gpe1acG O5Ed5mf2P4ntf/KBLyvQBtjRQKHnZHVr22uNivrc7NHaaXS6SlqLeNGa0GsQA2MirJjParcb3OBD GoOwOwNVK6xvHK+QeSLtFUnBIzjghCluNCADxJDRiBmMOq8G9RDhiBenwx7OLtpEIs6E4QjlH6NQ 31rfUqBvSYTgiawP82WnmePoL6/Uzp3AF45Kpy4gS+ScdRKzTg2Vu7LwS6enTj2PTPomrBVsTtcN Yj3cT5hGcJ3RNGg/CLc1bpSD6sajOyHl4uqm1qflGeWRN+RH3r4CrX76Ftkl/6xV+RnUJndcvUut 3KyIL4We98972lfsc/rqAFwdSPV1I53uAR2g9pFBTy9qNPI5E+5O+OJMBI7Q9Jh/zWMKp5mmxy7B I3kwrzRJL6GLRwTpCF5NjWeLxVJRqqSn4PQUNzOHXLKcOXwc6zj9rfqXksffXi/vVx15E+T2vqv3 qQd6aU833u0+PHKo61DX4D7zLti0i9i2Bfn89EMvb8WGpxfdK+hrZyfOLeP1ldzpc8gF5wnNPLag 6ZEOovv3u7T78eRK+og0k5spTdWq1WqtUEvWUnPCsSggYYVRXlLHMqlIEl2etnWV8FJXYt92ZK+v 16LH9GajdwQ12fiMCzcXnVPEPOxbYGankVpkPn4Mm5AKiXQMbltoRNRpBpgv1zLtQrYaXUDlp1TK 3tX/2XpOJeuv3tGaV2So7ReyX20bIXXDSF96cEKL9cydsr2CXjiRq8/jc3Vp8QSyQMwZ65i90ju3 7fi5uYUpqQrnqkKlgiy46ppJbFJzOL0L3XHQNaTBNUPOvsPICK/PGLCMYXbw7OG9A4Nauw7+taxV uzJE1p+D/blALodUxXIREFVxQqyj9Rppz+N5m6gfRAys2WfDSKtxpGcA/kelS51yxK1mROczWe2Y zTpC9qMDulQFzN8KUT+KTHOTqRqWqhUqtdLf7ThxsDwAt73hUb98ITd3Br989PTZ+Vfg+cvSle8j PzNd2X8eW+k5UNqBbtqt39GNaw4492xFtuT21fux/vqS4zl0+bls/TTu3WbaPbhvcN+Apt/eb+8m O0G/Q/KYfFlN2xwBNzpkSE9Ycd2i5+wV5HRisVTFqsVqahKtlJphFGyZkUQ/nOiLDWoRY3CQ6cRc Xgdpo+G2B/9PY+t/mz5HV69T+3ws8YFrkrFE4g/XJH2JD1Dub/4/7vTG6tJ/eYpkUe4/ThF2jP2T KUKAuf/eFJG7pQaqbpSXVssqZd8N176AXxvL8j+rV0uyo/UQ1OhQOlY7lD3NryXZDjptXYORb1an hjizB/Gxfj+F+WkHa2gScFqC9GErB8Z1yjVpP644GyfXO1WKZ/WYbZ99yOVqpygHM8KCk70SpA1b Y34eJnmWTyDJeD5RxY7/tlUWVQozr5YhuShfrxRb2+RXGs83PqkuVMWpOrLonTVMYcapvuLeBMxr D0d3ocqio6KqSLQnhQu+mKELWf0G1Bcw0QTmJGx+PWp0yK+qfniOS8/j8+nJUnEKLk6JM3XkmGth aAozFwezB8TF5FShUIWVX8tGNVedjNbRS8959DP4tD6r6UGMjNlrxQir3W3ywaRpgN2HOpxjYy7c PeYJE2H4wA3CWGIsMwaPpXPPFtATi7R3Gp/xlO1pE5wxc4C7e1yaIQOmHzro3YL29UWFXrwZ1htX H1AHXAxB+WGGoYJ+lPFHOQ9ePrAvuR99ert7aDe+e7j78PAOWLfd/cyTyP2lR1eewR649A9d8nXo pbPp2nH8eG3xWP2iW1zfs6O/X+OA7ZpefyfacShZ7sV7x3V1+3HYfpw8cwn5vvhS4SRWPDkxN1eG S3NLiePomRW3bgFfGJ7cW3gCzqjcsqWZXPm1W+SP//PclVfw8y9P/PhXyBXXpaGzmPZM15HdJbi8 56HEnahSbiKepz3JP0Xchzl8Nv8IQFwlb2001MLCbGwS/cllw66T+KldlUfuRe41PtKxC9u1d7P+ YXRkICZ0ARy4BnoVUs+UQ2wKz9FJkvcKHs7EDcB5FS3f0brKO8ZVtQLjTeACGTV0IquPQNqQJUBi QR9N+ViY9rhB/5scDV51QX6g1aaydlmHbTaXy0U6WZh16oN9qHKDyk6EowxOR9hYiIOD8VFpEpFH 5DugiUKQTuMpRvDHiZg/ao1pYUl2OVShXr/B6YZ9XiPTiyp3yBnQGPvk3wJXZ6tBOotnmbQv4Um6 RTM/BOeuueoDrmYzASqNi0ycjlJwlAybNU14ugNGisRchI3SA1flBcmkcrujvAcHk5AL8HAAbCp1 RO6Vb4RKuSCTwJNrDsFxImo3IJJscagCfX6Tl4AJr40ZQZUb5ZSq2Yq/AjU06gz6AizMBJgggzJE hHPgfWk9b4vCUZslbEKf3ObR7cO3Dh7Yq9kMj+z07NiCfK3y6Kmnsftf+99d8sfR48sxYR5fEBcy CwVYPgTNR8pcCssJEl9Bk5IiOFQ1KcgCZgPKL+aDY2TEokGUHZCVsPjNNMyYzUEj2tWVHO/Buyva I6YzsPEM8eIryE+k1xfOY68fv1z/OfryKXvvIj5hKPXkdoMNyin3rhVbV+OYeiZciopYNMHxYgzm 0ploBh2XlAWAZQZgmcFFFmDpb2JpGfxvYHlQvqQcfO+w1/7eYbPKBQ67cfL9hxvfgK55EQFeJK55 kUXLf/QiDYJ/nxfKduUSBFTeEUn9Z24NrC1FK7yIZVN5vvaBYP6zwlC1zcgfudqufveuf3K8A9IH 7KDNfBTFgs2JFHI07p0iJT+QbZQ/4gN7IUv6cIoKEC7EJjhzbswtjVNT6JGZJFDO1XK+lpiGE9Ox 5VOI/OP3nEwW3nNyraJubwyoL16q13luvFzM5cScmOaSoJSSqXAalZSgIwPlEkEGyC8WbHAIGSD8 Xsym27rlc1/oHbBYaaZZQvVw8X05zTRzWv4ADEwzLt9fguFamjwgTfT7cqqBZLtilZwiEWHaI0yY phCKpSkGoylP0I465CsSNBLW8SOZkfTARPeaKFvfpJjCP6mddrvXRsG0dSCwB92r6jSEI0DaRZhY gINZMZivIY2vQIuRSkzEYqIopOOgCiqRORDyWUcF+gDd9QbNTbojrtFdQwTU84Qr4uxyDjvt7W2N ycbGW2S+ca519dvvMqPTZ6VG3gtNb+fSBO4X2coy0ngMWoiOcwksB/Iw2URpi0ohVzMK1ci0KttA 7wGCSgE+4KmYH+a8EYsOWX3sPasAsDWrHtAEBmDVC6wGmla/DcnC6rlmj3lBMeXTo0ERz9NpRqRF KuPJm+HVzvfZ0KHmP2PjbqjxxOp0q9Q4r/qjixPNUvE4yqraNUTImBEgcjO0+rkG26p8q1lC8obG 2+pHn+j/8gbk9umvvvwU9tTLP9L+Cv3Fj+qvX8ZfeW3m5+8gvx762eZXsVc3P1z/Mvrlh3Xbnsbl f3erV7aXvqK0IhtsX+/ah+3t3mN6Gt1yoLTSjx940fym3IL8W+mnK+ew4/MnShfRV05aDs3jTU6W 5LPqkJQbzaKvns7NggV5Vjr+ArJEzJonMdOkrjCYgpOD++NbUCXw7txqbgpRY+e1RJpo8g+JBNkx qozXspNgK0cReRdUZAvBfBD+tvy6Ol4tRnJobZwhSniRyNkTJjhpjBt0SCcxaDRgBpPOO4iSvrEx L+4JuyPOCNxsqFX5w+qVl8rffQN5R/vm5tfWov4Seu9GzVOb8E1Pau//LLI5sbN0ACsdmO5Z0tas C7YT9rpmaWhF95zupPm067Tref9KCM5Ce6OHMj21nlr/Uc2F75UuLq+8DCv3NHzqafv4UL4THt+Z fPJB5HbLxkO7sIN9HZZn0C373wXvZwA8eV35jZWz2LH554sX0cVZ0jbdXEKu3iep+6M6wZy2ZPST Q8eVT8jb1p9LHi1Wp+DaVGp+CTlC1M0TmLmmy2sSsKjZHXsUVZj3LwB/AUiDyuh4H5A7oVhsNBaL PhtFxdSzYzlctiivtMqPqVY1jd+r4zOVSB49Ous1VPGKIaXpRDpdA1o9NjK037s5GHg2wLLPMijI duNpMPCCbqD5wWxnabA00d4o78Bz3X1CP7p9v3OgH+8bdHTtR0bixpQZS1ok67h93L5svKC9oJ21 pci8J+0SnLDgijpdyDBhNFswq0nr60IHNHxGhw9nrQV32TNOzFHPww7FJqnCmWgiFoNjUS7Mo3yB 9c3gM2SREUNwMCeN5sFok+YX8cWF/LFTSI2pEOOYd9xZNEsW6XDl6fpDy/vqtnHYk6OlAlJLlEtF rFiaBAJraopyT+AT7qI1Y8gaxIH4IbB4AAqWuQWgpmnl3ta8KjzFjSelZC6TzMXhWKoYnkZ/uhpR faD55wClGN6llLXGjfwTNFEK+HN41p/2iHaw2NgjI2v71L1r+/uzgBLeT2hKEXqU6fDqMGLYBGQ/ bB/s8R9GB3XxJJB0SUeGyHvzVIWdhdl6aLKKyEeblMUnAR/khQm0Ir27gjd3tIQ33jSYhL4W25nQ YZnDNc2CETYunPN+D339TKq6iB+pVadTC3BqnjvzGiKXoAWwbYhYKV1IVJumPNemUBRg4IBGo+Fn w2gpkGVEPywAAiQRN2Vw92HKvasfVzY21re65+hKDklERYHDBL4Qm47AkjLugIqhbDDJJBiRAgzF CPakTh5b/c56SSU7Gy+l65nxXLY9mZD48SgsQW2Nn1+1rt2wkA2xSZwPxgNRGo6tDRgXPeLpxpSb VtcpN8urre5lejKHpKMiz2O8kIrm0ZykiA5VShwNxcGVfIAHq0CMjTKCl/NwzuzB9YUdynXKFeVv GnCrZ5muJoG7gnDtaglNNEeqKp8JMkkw7cHS543SgjHTJe9ZPdF0987Gg/Jdqw+2FlTy5sZ0+pg4 wSXawVBOJuJwXExHJLTp/7rGfGNGXZsrlDOpTCor5rhkLBPJjwEwCAdUzoaCHM6H4myMhqNsmKER OkQHGSxIU4THoXxIuXP9HfLdra4yJSURISaITTClaLV5/SUHNDM66a+4xl3Tg3O75Y8rO9Yr9ygd Zp3V4nC32z12sPQ3n6Y5Q0DXERJkHHNGKQ72c01dx4XjEQ6LxIVUWpIx+bH1cquyMWvm3RG2PUKN AXyZEFhcMZZhA3QQDvg9oeYcX5AgXdjE27P2zPBCz0VlgzywvhmlEVRuLhUKCLgQ4JhmjuhI8xE1 abYNYcotymEFkwdbbdNkMYmkuUSKw7hUGiwfGUmZd6iSYigYx8d9WZKneCptK2nkJ5X6euXzHxyn C5JFpbf9cUjLGyH5i3K4MJ0tp9PtqXQmkeVhLpuK8mhKUlzNpv1HUD8e5QHQtPElvsanhUwykWke qkbnUHlAtbpx9V9bHY15aFp+BGwKO2x9Fnu7w6z1d6FKRdV44ur1rWChPKV8Ua1suLoob1hUtP/e ImtVbaaFqzer5Q2/X1Q29Mja37Uo4LdGXHlUvZrubqRVbW/JZwS1T0gxWbQ+Vzm5gNcgm91L0Cwc CgRGWZRlw5EgHogEuZAAj4qjVUDGd0PHgpNMGvMXPVm7CKcMWq4b3d1NmHW4zuQx6hBPlOCBrufE QBJNiVEeVA8fTWaQ0YnWTDyZSmCJZDZeQGtFypnG0y5u6BDigL4+ssOksWtsZqvXApMu1m5BBsWR ghWzFqq+KbSQj/ISnohPFp6bh/Uxh+jDlNZFtd3FZzy4J0vny0g+nktksURGylQzGX4mdbIAK1+H NF1alxGQ/z1XN6ktKgXdwTlaY+lEREB5LsTG8FggSoV9cIQYG9qDrHZBE/aap0bC/lqNraLnTheX V/CzJ6uX/x75jvOFwUVscbC7cADt2D/8zGH8FK8WcjnQhjOT7iEweoZSh7YhT3v3G7WYxqB3DaN2 R5R34g7BmXRmYbkAFfK5VIqD295qbJAfUzu7nXqHG7YaRnxa9OBAYVmPG5a9z59FzqaO1maw8Xwt OYMWsiwJBB0Zd4ftYXvUG6dhr5BmCmg6EeX4JrBiCql4xkfKWFnXnzyEbu2wHOrEOw9Ztz2GfDO/ 7chh7PDCivUUemwxOz2Hz82MryQvwm3yO151WSW3n2OlVsZNhMAkZMIxBmejAT6UhIOJ0ZkzSCNt gRRkR7wJWDLC/znA7oMqBm2qG928W7+rG+/aZdv6FLJJ2r3QhXXNH7OdRMdLMbGIF8VirlSGv+xT D2hzc6BM5jynX0VezZyaqmPVUjU1gWYz7NrESXkEh+iIW8MWWHFAwyMj7mEUwPVFeUZ9znVcW8fq 2s5cB7plr/VwD95z2Lbl68hjIMgurHNxxfoCempZWpjB6/OFZW7FLa539zhGrC7YZTGAJfVQb35B g2uPuMDkWJBhdbE0LtbQXI71AT1Opjy8PeaL2MI6WOlWRReSU8Vi81XcDxp/q55ToBnoSvhYLIdF c3xS5GE+kQK8kARKRgRqJEGkHEkgK3iwVfCAxJtvmAQeF0BuBETy5+xprKTTJgbRPo3fPozr7Baj Zwh2D9F9BxHdlwbeUp6HtCFrwIcFfJSfZGDaRwS9qM0hF6Uulc317h5UA0zyPNT21m/UfhfrJRAy 4ucojKOS/hw5pHU5QkGH1edkCDhIhSgKATVXcWG6Y2c9r6BvvD5+4hQ+V8/NLiA1f8khYY68KTEU tUUOR54Y6xuzhP1jrrAvysZgNhaMxxAuwscEoGQEMZOC6XIpWEJfOJqZBLvLVHZ+GVnwTznK2Iuq NP/sWBiPjIXDY2PwWHQsziPcaDwUwUbDobEQ+ClEPetB71YVh/rETnT3YZdWg2u0zt5DiI4zZExY xlSwT3gHR6wWvxuWB+SL6rIu0bUH6aZ0Lgdmd9n8RtRgTRSduGXCt3QaWeIns3ksnyuI42i16LOC xK1+SX1qtM7maDhH84QTMXssI4Az9IfIregz+8WCBrcn/ekMkoym+AzGpZOZTG6RvRD4fgg0wSeb b7GQNUbIJCLcn2WEO6GRkCPgxwJ+lmaCMEO4gzYwYwwSZHZFYn7cH2PiQAQG+VB+CpFJaLwKdC8P N4khi2ZTARqsNRRPxNxwzB3R7kWUL0LGZ92jDBYgWD9Fw4zfE7SipEMekVRWTzhG4XSUiQd5mE2E 8hOI/AXofPAIU8T8U56SIw2nHRbOiFqsjM+KW306Q38PLP8UantQvu7qRrWfZAkv4okRoh8jhSSb RlNJIEdxQYgl00iKTfpFTCCJmLep9f0kfk7Rq99lxFQivMaIgWb8ETpCwhH3WPNt2TcgfcjOkliA ZBgwFgKUJ2QB8Q9LkNXd9JaKgo1FaGpsCXi7es2VB9WknyU8f+JKGrgi4OKaK2k2SQqY6CdinrXH Dn78vDLyl1wBqfCMNZH7LrQ/NBT0YAEPS1IMzNBUkEJ9Xi7twl1pkmcicNRPhdfeClFU80EGSSA+ zpfxYb50iZ1CzxzNL9Tx+kL2wo+Qxm6oTd7QzH/7Dt7RGk+LYe7dm8bZCAVuGvaNaUH+74YM1+Kn gGIIwKzPGTSD+G1gVXGFo2vZWotfCOUnEfmzkPwJ5ZHWlDNO0GA5YQNBLMBSIeIaYjZ387EBEfWI 7owvYa1olxRIvmO9DP3fYqGQkvj2HFeK1sbgrLLLBSVHhVCMheNsmKWRwGggGACmPB6TWWn91PrG tibQ9/3BfwDa+wj6Pf+HOpDVu5r5C5AYED0MBfJHe0JWtFltoH6b+QP1+67/IH+NX4J18H75/kan 2qr6z9Lx0HuW/SATABnqmmXQGSbXu5UR/yMyNJSRCtlaBnSGFMuh1YLPmsYTrpihH1F2QvpR1ygL WoKhAP8xfmfQBCxZgI/uSIwEPtLx4B96TAOFimOxSrmYzQntgtQcwBMF0gp0uTt6zZphzVrQx/hB xdI+d8CO+tcazO55r2WBOVCyzQbbCS0Fpug85qt5Cnag9h3WuAk1mRgCyBevzqjppqc947YsnLOZ +BHU5QzSTtxFu0g3wbB2u1YDeOQrfxEvwCREk0m0OxHlAUgbsFAE5qPcjLnZ8UZJZXK+10OsAIMl 6xqHHDuyWDwC9IzfLuIJR2wYaKLNICh3MyiCWWMNyg1Yw99EW/XHPmyyxrWgtkPLa0GRE56CAwTl bAa1r2No826g2+9oPKrW2PXDti7Y2k12dSHbc3vqB7GdSy/oX0eXj4jFWbxerE3nl+H8sri8hJx3 nh44jp3u2lF9HO0bIO0aXH68Qz17MLf5QWQzedBqwAw2g1eLdg6OnzDghhPe868iS7F6ooolKmkp B4S/lAMpn59yDZXxtlhjvTqWFIEcFvhQIA5AakolGOzzDh2yurE5Cpsv5+kAA9qNJlxBB0o0pYEK 9Nu1WmjG2ayqaUS+Fcp6MmQKZFkqBCvoueeKywv48VOlyz9GrjjO9x3D5oZ7pYOo0Ui5zLjJbR4x 98C/tUPKJ3a0yhqjms82H9VOVLzGIj7Vl9n1OPKMd79egxlBPBpUb+EyDtyR9uVYCQ4mR8fnEflr UG0qn0vG4bbGPSDrTsJB2v2E6OFdQOS7nBEHummnad9B/OB+y9MPIU/mds32YD2zi7ZjaLnMpUp4 OVUZn5qDlV2ged43VljSA+L0N2te9YfuWXt2yYekSaTxfUj52OqtasrtALXcp8lOG3D9tHflJeT/ 8Wo2MXKbZRwXgh370G6E6Ibd15KtppCoLS2KQEUc4IA4QA+IQyuQiBpp22wyu9Nsdj5tj2f8Mf6a zYy/Zvwx4/F4vnY3mdlNNk2Upq3UL3FoD73ADZAQSIgDFyQOnuAV4vUkQVy5cLef9+/nfZ/nfX6P n8+99/em+HRv1r2NDQKZ94me4LBmBbUqGpkF8SWkQjJVZjFWdAYKhofUeHRI7cUhXQxHiE0ebfKN zC+SdL/zOBTlWi0JHlpJ0h0Fk1dZM3mCM2oQUlHJU/uTJBT9aXfY8VDLMjUTs2yJ6xBcF7Iz5tqL GujxQI6X/M9kGYPC3rqU/skG8XdkeRb9GupRaqqs1lFVTWhD4jSDJqxsUaexNzfZbJbIZquZDbBt 5bsk3iGnxQ/y7+empM+gPtMi84ASy5UqXq2QYgHbuuqOdojsiDoS3kPL8Xf9VEs3IWOZ7brqEMKt qXyA3TlyJ1NiOuke3gMfbd7/6Qz/8a1Mt9jhvTV4iPwAdCHxubjbCcwRdnMs0CHRp/0t91eoH30r BTPuuflfV6qbXB6Sb54ukmWSplhKRMu/iT9FtrScVcYtxmE7NRTWHEoXGw5b/oAIe72xM0PJlFQV eV5ERZ5TOazKG7ZA1GwlhNnxPvKPxtLhc9E5eCuN56+tUMiN3VBuC2hbMOgdEJtILlukKQEVqLJS gbWh5VUIxhP3IY99HJ+nkLG/4FrZSjrjRq3JFEF8AVnXN60CbuU9MqigTDAUJ9hoYDghETo39+7c Q18aIhH4VIQMwLJ1/r8ZwEkO/PRDEE2Q5fb8Ryu+6tQN1ZbaklmzahZrUdF3Tp5eHaSi8/OvtUdO z7HXLMPRewn1f5NCek7S0TB24ZUho5raUGUgKBWRwp+L7TPR9SXRVz0X2FrbMnHTtDUP6wTxRtK9 MeFqodIR27V2zS63c9E3Tp5a7aWi1ehu9JX4btLLeH5+2jsa9G/oa0H8LIX0d926KaOWrEkS4NVk lZfi3bNRa0mF5agFIOyZBm63fH2UqLtCIeGup1qKV7OrrdLk1dUX4o0XI3tJ6tQ9G7SbFnzaMBwt SJ7+ObLsJYp8RfAIT+jnx1f+GJ9afTn+6tW3ijmWXxMkXmHrKB2d7SFMg9NECxVhRdgCptMb3MR/ +7cvXlwavG2TNSCqoqTgYo1VKxgdXe4hZIPRuRbbKo2v3Y2/HL2y+tkf9o+HY99Zc1sd3U+Wf4FC 3HYyw2TArxOBwJZyW/jGL7c+FB2ppRprrC95sOrWTCPRbDc9LIAxD5Ms3DLFlVuyoViwMHYYq2rw 0SvxX1a3fsBe5UgonOc4mcfUWtOoEhbJaBzGVJUavB4FhasCxmQ9WDi5vtTH9ved4Q3iYDg6DO5H r85fW22FhqfpLceyLBhjtuYmUs9SSGfRxzLquqopaFNtKBKo1qtSBT8XN+IvRaUlbigHHmjrLbjt luVoXcyGelMQ8c5G+IqSVgoyLzI8z8qw0s6raSz+Xir6eH5mqXfyFFKPT8Hdb4yNsN0znVbL1lG9 nbQ1o+dT8Ucnzy5RcwIxInxpOToV/T5+eYUaCKMxCPWJNcWtmb4/BIfsLDvFc7Mr4wvBB71b4/EU HU/d2QyMlD1xhotTZa8PJu1REOLB4KB7p432kNfFNwrpDTS9Qa9fBDn9mpXBrYyeo0COL5AlvFS6 xqZllESO5H02LKH9ol3IA1rJihlczCjXcuBib/1oAz+6/KDwSQ3au9Te9qkQXY7P/w7Wb/86c/ef Z5BE8Q8fPr0SlNr5LCCVnccvF8CmuznJ4OOt27n3qAv05VzubTSXYTc3QUHfsbYSJdkSyAp5qoRT xW3mkoDSyCetB8OjY/Todu/eu2Cs7IvT5MsmPTCyh/0BHob77pGB9pG0cc0thSg54IcjEOjjxE1T fX8MHtB308d4+viN4esWtHdHOGCCIrr88OvRM//7uGD0p9P/h1fg/XZhvrNyY9q59Q6E3BEd4H0q GXchy1K1QiQ8QkMeqSY8Yruyh5lWQ2sRMHAaOqYbqqwTmtKs8XDnGIHFWSpPpUtoHjnu7PfCAbr8 5y/mJyuFbS6zBbbb+R6Jk0EoDLGgazou4Tqm5y+oxsbtBWBJ4q4qEnVR2lUwWW0aKqHq9ZYD+mbg +bjrD/wbXTRE1qtbxeI2GlVPJ6bTC9OQfHuhMMACPzHtuWbHT9iNT9iNg8AkPjFdVzFF0XSFUI26 1QahEThd3O4O/cM+3Nw32UypsA2Fw3RZXhkeONMjcCCM/+MXuixxLFFlpQrzhNNsB3KatfBL0zKa GmboqpKMATUlHpAyxTM4xxTpTRItIe+403B4AJU3E9s3D6HPx8mIEVWCtikmsZ2MGD2yzT/xufnI ttmEPtfrsrbwOQdKEl2l8Wq5VL7KQNv3vNlgcABLLCOyV068y3MvtRzt9BdN9nu7e6LDog5nbl8E J99HLkrbHMxT7I64ngwRHQfIemPH4lyUc6SDd8Fci36GHE5UOSB6cpd1SZe0so0MGqTq0beXlq9f T83VZ6KHK/8WYACzBc9LCg1lbmRzdHJlYW0NZW5kb2JqDTggMCBvYmoNPDwgL0hlaWdodCA0MzUg L0JpdHNQZXJDb21wb25lbnQgOCAvU3VidHlwZSAvSW1hZ2UgL0xlbmd0aCAyNTQxMiAvSW50ZW50 IC9SZWxhdGl2ZUNvbG9yaW1ldHJpYyAvV2lkdGggNjkzIC9UeXBlIC9YT2JqZWN0IC9GaWx0ZXIg L0RDVERlY29kZSAvQ29sb3JTcGFjZSAxMjQgMCBSDT4+DXN0cmVhbQr/2P/uAA5BZG9iZQBkgAAA AAH/2wCEAAwICAgJCAwJCQwRCwoLERUPDAwPFRgTExUTExgXEhQUFBQSFxcbHB4cGxckJCcnJCQ1 MzMzNTs7Ozs7Ozs7OzsBDQsLDQ4NEA4OEBQODw4UFBARERAUHRQUFRQUHSUaFxcXFxolICMeHh4j ICgoJSUoKDIyMDIyOzs7Ozs7Ozs7O//AABEIAbMCtQMBIgACEQEDEQH/xAE/AAABBQEBAQEBAQAA AAAAAAADAAECBAUGBwgJCgsBAAEFAQEBAQEBAAAAAAAAAAEAAgMEBQYHCAkKCxAAAQQBAwIEAgUH BggFAwwzAQACEQMEIRIxBUFRYRMicYEyBhSRobFCIyQVUsFiMzRygtFDByWSU/Dh8WNzNRaisoMm RJNUZEXCo3Q2F9JV4mXys4TD03Xj80YnlKSFtJXE1OT0pbXF1eX1VmZ2hpamtsbW5vY3R1dnd4eX p7fH1+f3EQACAgECBAQDBAUGBwcGBTUBAAIRAyExEgRBUWFxIhMFMoGRFKGxQiPBUtHwMyRi4XKC kkNTFWNzNPElBhaisoMHJjXC0kSTVKMXZEVVNnRl4vKzhMPTdePzRpSkhbSVxNTk9KW1xdXl9VZm doaWprbG1ub2JzdHV2d3h5ent8f/2gAMAwEAAhEDEQA/AOt+rP1Z+rd31b6Vdd0rCtttwsd9lj8e pznOdUwuc5xZJJK0/wDmp9Vv/KfA/wDYan/yCX1U/wDEt0b/AMIY3/nli1UlOV/zU+q3/lPgf+w1 P/kEv+an1W/8p8D/ANhqf/ILVSSU5X/NT6rf+U+B/wCw1P8A5BL/AJqfVb/ynwP/AGGp/wDILVSS U5X/ADU+q3/lPgf+w1P/AJBL/mp9Vv8AynwP/Yan/wAgtVJJTlf81Pqt/wCU+B/7DU/+QS/5qfVb /wAp8D/2Gp/8gtVJJTlf81Pqt/5T4H/sNT/5BL/mp9Vv/KfA/wDYan/yC1UklOV/zU+q3/lPgf8A sNT/AOQS/wCan1W/8p8D/wBhqf8AyC1UDFe97Hl5kiyxo+DXEBJTR/5qfVb/AMp8D/2Gp/8AIJf8 1Pqt/wCU+B/7DU/+QWqkkpyv+an1W/8AKfA/9hqf/IJf81Pqt/5T4H/sNT/5BaqSSnK/5qfVb/yn wP8A2Gp/8gl/zU+q3/lPgf8AsNT/AOQWqkkpyv8Amp9Vv/KfA/8AYan/AMgl/wA1Pqt/5T4H/sNT /wCQWqkkpyv+an1W/wDKfA/9hqf/ACCX/NT6rf8AlPgf+w1P/kFqpJKcr/mp9Vv/ACnwP/Yan/yC X/NT6rf+U+B/7DU/+QWqkkpyv+an1W/8p8D/ANhqf/IJf81Pqt/5T4H/ALDU/wDkFqpJKcr/AJqf Vb/ynwP/AGGp/wDIJf8ANT6rf+U+B/7DU/8AkFqpJKcr/mp9Vv8AynwP/Yan/wAgl/zU+q3/AJT4 H/sNT/5BaqSSnK/5qfVb/wAp8D/2Gp/8gl/zU+q3/lPgf+w1P/kFqpJKcr/mp9Vv/KfA/wDYan/y CX/NT6rf+U+B/wCw1P8A5BaqSSnK/wCan1W/8p8D/wBhqf8AyCX/ADU+q3/lPgf+w1P/AJBaqSSn K/5qfVb/AMp8D/2Gp/8AIJf81Pqt/wCU+B/7DU/+QWqkkpyv+an1W/8AKfA/9hqf/IJf81Pqt/5T 4H/sNT/5BaqSSnK/5qfVb/ynwP8A2Gp/8gl/zU+q3/lPgf8AsNT/AOQWqkkpyv8Amp9Vv/KfA/8A Yan/AMgl/wA1Pqt/5T4H/sNT/wCQWqkkpyv+an1W/wDKfA/9hqf/ACCX/NT6rf8AlPgf+w1P/kFq pJKcr/mp9Vv/ACnwP/Yan/yCX/NT6rf+U+B/7DU/+QWqkkpyv+an1W/8p8D/ANhqf/IJf81Pqt/5 T4H/ALDU/wDkFqpJKcr/AJqfVb/ynwP/AGGp/wDIJf8ANT6rf+U+B/7DU/8AkFqpJKcr/mp9Vv8A ynwP/Yan/wAgl/zU+q3/AJT4H/sNT/5BaqSSnK/5qfVb/wAp8D/2Gp/8gl/zU+q3/lPgf+w1P/kF qpJKcr/mp9Vv/KfA/wDYan/yCX/NT6rf+U+B/wCw1P8A5BaqSSnK/wCan1W/8p8D/wBhqf8AyCX/ ADU+q3/lPgf+w1P/AJBaqSSnK/5qfVb/AMp8D/2Gp/8AIJf81Pqt/wCU+B/7DU/+QWqkkpyv+an1 W/8AKfA/9hqf/IJf81Pqt/5T4H/sNT/5BaqSSnK/5qfVb/ynwP8A2Gp/8gl/zU+q3/lPgf8AsNT/ AOQWqkkpyv8Amp9Vv/KfA/8AYan/AMgl/wA1Pqt/5T4H/sNT/wCQWqkkpyv+an1W/wDKfA/9hqf/ ACCX/NT6rf8AlPgf+w1P/kFqpJKcr/mp9Vv/ACnwP/Yan/yCX/NT6rf+U+B/7DU/+QWqkkpyv+an 1W/8p8D/ANhqf/IJf81Pqt/5T4H/ALDU/wDkFqpJKcr/AJqfVb/ynwP/AGGp/wDIJf8ANT6rf+U+ B/7DU/8AkFqpJKcr/mp9Vv8AynwP/Yan/wAgl/zU+q3/AJT4H/sNT/5BaqSSnK/5qfVb/wAp8D/2 Gp/8gl/zU+q3/lPgf+w1P/kFqpJKcr/mp9Vv/KfA/wDYan/yCX/NT6rf+U+B/wCw1P8A5BaqSSnK /wCan1W/8p8D/wBhqf8AyCX/ADU+q3/lPgf+w1P/AJBaqSSnK/5qfVb/AMp8D/2Gp/8AIJLVSSU5 X1U/8S3Rv/CGN/55YtVZX1U/8S3Rv/CGN/55YtVJSkkkklKWR9ZOq2dNxaPRIZbl3sx2PI3bdwc5 ztvf2tK11ndZ6Y/qFNHpPFV+Lc3Ipc4S3c2RDh4EOKSnHv6zbXjY9ePml/rZgx8nJsrh1DSxz9W+ ZaAJ8UA9b6nZRfRTebfsudXTZlVM3ONDwHOO3xErVq6PnVNyr99FuZnWtsuD2n0g1jdga0cqeH0n N6fj2nFsqOXkW+re57SKzptDWtbwAkpqXdXeMLHqwcs335WS3GN9jQHVz9KWaagKvd1jqmNnP6N6 wsufbWyrJc0SGPBLpaNJ0Vr/AJsW+g+31wOoOyW5gsDf0YsboG7f3YSs+rWTe92bbewdSNjLa3ta fTbs0DYOsFJTZ6Rl5n7QzOm5Vnr/AGbY6u6NpLXjh0LYWb0zpt2NfkZmXY2zKyi3fsBDA1ogBsrS SUwfYxn0jEqthXVCuyXD+et/6tytkA8hV8Jo9OzT/DW/9W5JSX16v3gl69X7wU9rfAJQ3wCSmHr1 fvBL16f3gpQ3wCeG+ASUw9er94JevV+8FPa3wCW1vgElMPXq/eCXr1fvBT2t8Altb4BJTD16v3gl 69X7wU9rfAJbW+ASUw9er94JevV+8FPa3wCW1vgElMPXq/eCXr1fvBT2t8Altb4BJTD16v3gl69X 7wU9rfAJbW+ASUw9er94JevV+8FPa3wCW1vgElMPXq/eCXr1fvBT2t8Altb4BJTD16v3gl69X7wU 9rfAJbW+ASUw9er94JevV+8FPa3wCW1vgElMPXq/eCXr1fvBT2t8Altb4BJTD16v3gl69X7wU9rf AJbW+ASUw9er94JevV+8FPa3wCW1vgElMPXq/eCXr1fvBT2t8Altb4BJTD16v3gl69X7wU9rfAJb W+ASUw9er94JevV+8FPa3wCW1vgElMPXq/eCXr1fvBT2t8Altb4BJTD16v3gl69X7wU9rfAJbW+A SUw9er94JevV+8FPa3wCW1vgElMPXq/eCXr1fvBT2t8Altb4BJTD16v3gl69X7wU9rfAJbW+ASUw 9er94JevV+8FPa3wCW1vgElMPXq/eCXr1fvBT2t8Altb4BJTD16v3gl69X7wU9rfAJbW+ASUw9er 94JevV+8FPa3wCW1vgElMPXq/eCXr1fvBT2t8Altb4BJTD16v3gl69X7wU9rfAJbW+ASUw9er94J evV+8FPa3wCW1vgElMPXq/eCXr1fvBT2t8Altb4BJTD16v3gl69X7wU9rfAJbW+ASUw9er94JevV +8FPa3wCW1vgElMPXq/eCXr1fvBT2t8Altb4BJTD16v3gl69X7wU9rfAJbW+ASUxFtbjAcCVNNA8 E6SlJJJJKcr6qf8AiW6N/wCEMb/zyxaqyvqp/wCJbo3/AIQxv/PLFqpKUkkkkpSSSSSlJJJJKUkk kkpSSSSSlKtg/wA3Z/x1v/VuVlVsH+bs/wCOt/6tySmwqXWXuZ0zIc0lrgwwQrqHkUV5FD6LdWPE OHGhQOyYkCQJ2BfLf2jnf9yLP84r0boL32dKx3PcXOLNSeVz3X/qpjY2EcjAa7dWZe0kulvzW59W 7hb0qkbDWaxtLXT2+KjgCJEHs3eayY8mGMoCqlRdZJJJStFSSSSSlJJJJKUkkkkpSSSSSlJJJJKU kkkkpSSSSSlJJJJKUkkkkpSSSSSlJJJJKUkkkkpSSSSSlJJJJKUkkkkpSSSSSlJJJJKUkkkkpSSS SSlJJJJKUkkkkpSSSSSlJJJJKUkkkkpSSSSSlJJJJKUkkkkpSSSSSlJJJJKUkkkkpSSSSSlJJJJK UkkkkpSSSSSnK+qn/iW6N/4Qxv8Azyxaqyvqp/4lujf+EMb/AM8sWqkpSSSSSlKr1LPp6dh2ZlwJ ZWB7W6lxJ2taPMkq0sj60dOu6j0a3Gob6lm6uwVzt3em9ry2dOYSUxu63l4eA/MzcRjCXV149VV3 que+1wY1ria2Bh3ETyhP+sxxm5VWbi+lmYxqDaKrPUbYb3bKtjy1nLtDI0VGrpPq2Z11nT76unWV Utbhgj1XXVvLjcxu/wBpbp31hV7Pq/1C05PUqqrjaLMZ+PRkvDrXtxrPUdJmG7tYSU7D/rKcVuUz qON6GTjMa8VVv9UWB52t2OLa9Z01CjZ9ZnYZtq6liehkMY2yqqqwWiwOO0NDi1kGfJUOpdL6l1d+ XnMx3UOFdTcem3aHvNb/AFHTBMeGqj1XpvU+s3vz68V+OaK2Cqq4tDnua8PcNHHw7pKdvA6tfdmv wM3GGLktYLWhlnqtcw/ytjNR30WosTBqy8vrTup2478WplApY22N7nEy7RpOgW2kpSrYP83Z/wAd b/1bkZ9TH/SEx5lVcKio12SOLbe5/fd5pKbqZD+z0/un7z/el9np8PxP96SmZAIg6hZWV9YMTCz6 8C2p7DYQBZps147ytL7PV4fif71kdf8Aq+OpVMOORXfWdHGeE2V1puyYuAyqd8J/B2wQdQkqmFhG rGrrvPqWMaA54kTHzR/s9Xh+JTlh0JSpIX2en90/ef70vs9P7p+8/wB6SEqSF9np/dP3n+9L7PT+ 6fvP96SkqSF9np/dP3n+9L7PT+6fvP8AekpKkhfZ6f3T95/vS+z0/un7z/ekpKkhfZ6f3T95/vS+ z0/un7z/AHpKSpIX2en90/ef70vs9P7p+8/3pKSpIX2en90/ef70vs9P7p+8/wB6SkqSF9np/dP3 n+9L7PT+6fvP96SkqSF9np/dP3n+9L7PT+6fvP8AekpKkhfZ6f3T95/vS+z0/un7z/ekpKkhfZ6f 3T95/vS+z0/un7z/AHpKSpIX2en90/ef70vs9P7p+8/3pKSpIX2en90/ef70vs9P7p+8/wB6SkqS F9np/dP3n+9L7PT+6fvP96SkqSF9np/dP3n+9L7PT+6fvP8AekpKkhfZ6f3T95/vS+z0/un7z/ek pKkhfZ6f3T95/vS+z0/un7z/AHpKSpIX2en90/ef70vs9P7v4n+9JSVJC+z0/un7z/el9np/dP3n +9JSVJC+z0/un7z/AHpfZ6fD8T/ekpKkhfZ6fD8T/el9np/dP3n+9JSVJC+z0+H4n+9L7PT+7+J/ vSUlSQvs9Ph+J/vS+z0/un7z/ekpKkhfZ6f3T95/vS+z0+H4n+9JSVJC+z0+H4n+9L7PT4fif70l JUkL7PT+7+J/vS+z0/un7z/ekpKkhfZ6f3T95/vS+z0/u/if70lJUkL7PT4H7z/el9np8PxP96Sk qSF9np/d/E/3pfZ6f3T95/vSUlSQvs9P7p+8/wB6X2en90/ef70lJUkL7PT+6fvP96X2en90/ef7 0lJUkL7PT+6fvP8Ael9np/dP3n+9JSVJDbTW0y0ajzKIkpSSSSSnK+qn/iW6N/4Qxv8Azyxaqyvq p/4lujf+EMb/AM8sWqkpSSSSSlJJJJKUkkkkpSSSSSlJJJJKUq2D/N2f8db/ANW5WVWwf5uz/jrf +rckpspJJJKUmKdJJTymV1TqHS+vsryrC/DuMNngB39y6lpDhI1B4Kr5eDhZMWZVTbPSkgu7KOF1 HAyi6rEsa/0oBA7JoBBOrLOQnGJEaMRUq2biSSScxKSSSSUpJJJJSkkkklKSSSSUpJJJJSkkkklK SSSSUpJJJJSkkkklKSSSSUpJJJJSkkkklKSSSSUpJJJJSkkkklKSSSSUpJJQsc5tbnNG5wBIb4lJ TJJYJ611uf8Akx/3pftrrn/lY/70/wBuXh9oWe4PH7HeQn5NFdjKn2NbZZ9BpOpjwWN+2uuf+Vjx 81yHUM3OvzXX5Jc29jtBxtjsPgpMfLmZOoHlqsnmEQKB+r6akuY6d17rVuGxwwnZEaeqNJjurP7a 65/5WP8AvTDikCRp9oXjJEjr9jvJiQASTAGpKwv211z/AMrH/er+e3JyujXtY015FtLgG9w4jhNl Ejf8EiQO1rUdd6fkXCukve1ztrbgx3pEjsLI2rQkeK5/pPVMFvRKsRr/AE8llJrNEEPD2tM6LJ9H KxvqnjZFL7Ddk21fbbXucSKtx3d9Br2TVz20iJnRUX9Yw2X5NJ3F+J6fqhrS7+d+jELl7W5FHT7S zK9TAtzcYXtpc9xqoJAuh7vdB0VbIFdf7df019hqL8MVvBcT9IBwa46kJKe6qyse2yyqqxr7KjFj AZLSfFVb+tYFGUcRxe61sb9jHODN3G9zR7Z81ldDxcTH+sXVfaWZD3tdWCXatLdSJMcoXWrGYGdb n9NyS3PJY27CLS4W6wI84SU9TI8VW6f1DH6hjjIxydhc5muhlh2n8iwMO3Ht6tlO6q+yrLba37LX ucBsI02huh15Wb03Ffi4PT8yo2tvf1B7H+50em579NvEJKe6kTE6qtn9Qx8Cplt5O19jKhGp3PO1 v4rkMAZ+Rmiy/Jbj57Mx+9rnP3GsPdFYZ9HaWcKvkmq7FqdlPtPWP2pF1cu0Y287Rt+jt9PaQkp9 AkKjT1jEuD9m87LzjGGk+8fDtquWzM+yjD6piWWWDLPUpqYN270nmsgj+TypMORXU7ZvaXdY90SJ advh2SU9rInnVLcOJXEV03VYVfUG2XHKHUdklziPTLyC3adIhAwrq87rlPrWOZbTmPc+x9rgHsEh lYYDt5SU9+kmTpKUkkkkpSSSSSlJJJJKUkkkkpyvqp/4lujf+EMb/wA8sWqsr6qf+Jbo3/hDG/8A PLFqpKUkkkkpSSSSSlJJJJKUqdHUW3Z1+GKrGmgAmxwhjt37pVxUqX9RPUbmW1sGEGg02A+8u7yE lN1JJJJSlWwf5uz/AI63/q3Kyq2D/N2f8db/ANW5JTZSSSSUpJJJJSxAOhXL09Gz8D6wHJw2g4lv 84JiA7n7l1CBmOvZi2PxwHXNaSxp4JHZNIBo9mTHklGwK9Y4TadKFh/Vvrz+pttryAG5FZ+iNNFu IggiwtnAwkYy3C6SSSK1SSSSSlJJJJKUkkkkpSSSSSlJJJJKUkkkkpSSSSSlJJJJKUkkkkpSSSSS lJJJJKUkkkkpSSSSSlJJJJKUkkkkpSSSSSlJJJJKUsrqX1eweoX132Da9p95b+cPArVTIiRibBpB AO4Y11sqY2utoaxohrRwAFNJJBKkkkklMPSrDi/Y3ceXQJT7Ghu0AbfDspJJKYCqtrCxrGhp5aAI +5IVVAQGNjwgdlNJJTHYzdv2jdxujVMa6y4PLQXDh0aqaSSmJrYXBxaC4cOjVN6bIjaIBkCO6mkk ph6Ve/ftG/8AegT96RqrLi4saXHkwJ0U0klMDVW47ixpcdCSBKXps/dHM8d/FTSSUwNdZbtLRHMR 3WUz6s4LXs99jqa7fXZQT7BZMythJJSydJJJSkkkklKSSSSUpJJJJSkkkklOV9VP/Et0b/whjf8A nli1VlfVT/xLdG/8IY3/AJ5YtVJSkkkklKSSSSUpJJJJSlTx8PJqzr8l+U+2m0AV45A2sju34q4k kpSSSSSlKtg/zdn/AB1v/VuVlVsH+bs/463/AKtySmykkkkpSSSSSlJk6SSnKp6J0/Dzn9QYSyx5 JImG686LTa5r2hzSHNOoI1Co9b6f+0On2UAw+JrI/eCyvqdnXOofgZAcH0EhhI7TqPkU2wDVbs3C Z4zMysw0o9npUkkk5hUkkkkpSSSSSlJJJJKUkkkkpSSSSSlJJJJKUkkkkpSSSSSlJJJJKUkkkkpS SSSSlJJJJKUkkkkpSSSSSlJJJJKUouO1pMTAmFJMkp5x/wBbLmvc39nXnaSJAPb5Jv8Andf/AOV1 /wDmn+5dJA8EoHgm1L95m9zF/mv+cXmz9br4P+Tr/wDNP9y5a7rvVza8jKuYC4w3cdPJemFoIiFz 1v1I6ZbY6x1twLySQC2Nf7CbKMzVSZsGfl4k8WOv+d+bmdE+s+bTjObdTfmuLpFgl0Dw4K0f+d13 /ldf/mn+5a3SekY3SqHUUOc9rnbiXwTPyAV2B4IiMqHqY8mXCZEjFp/er8HnP+d13/lbf/mn+5at WfZk9KtyxW6h/pvcGu5BaCr0DwUL6vWospnb6jHMnw3CJTgD1Nsc5wI9MOA+dvK1ZfU8PouH1n7Z ZfvdWMmi2HNc2x2326S0iUC3rGecjOdjZlj82nOFOPhAbmOr3NkObt42k6rXxvq1lfZ8bCzc1t+F iOa5lNVPpF5YZb6jnW2THlCv9N6TXgW5dod6jsu91/0Y27vzeTKLGi6v1C49Oy2dJtrt6lUyW0sc 1z2wRPs8fiqGH1/FowjZXkX5177a6G4t4Dbm22aBh9rY8Vt5GK51bziObjZDoi8Ma7uD7gYkH4rI t+qz8iy3MyMsftF9lNteRXVsrY6gks/RF7pGpmXJKR9W6p1SrI6XtofXZbkOZZjseIeNjiJd4Kbv rdjsrDLKhVlm11Bpse1jQ5okn1HaRCuP6RlZF2HkZmWLbcO02+yrY10tLdobucRz3JVS36qNOQ/L qyA3JN7r63PqFjBuG0sczcNw+BCSl6frXTk11NxaTdl22OqFLXt2g1/SdvEghVej9fyA+xuYywvy OoWY9bHuk1gCdvwELQu6Fk2fZr2ZNdWdiucW2soioh30mmr1J/6Srs+qtjKDGaXZYyjmMyH1gje7 Qh1bXNkfMJKR9U63bbYKscuoON1KrFtcD9NpaHn5HcpVfWI04zHMqtyrMjPvw2Nc5shzHvHOnt9u inX9Vnj1HXZptttzWZz3+mG+5rWt2AB3GiJT9Wm1CgfaCfs+dbn/AEOTa57tn0u2/lJSzfrNNLh9 mcM1uT9j+z7hHqEBwO/w2mVb6J1S3qdFtltH2d1Vrqizdu1ZodQsPr/1eyAHPp3315WcMq8Vs3Or aKwzRm736tWr9WasynCfTkUiitlh+z+z0nuYfzrGbnQZSU7KSSSSlJJJJKUkkkkpSSSSSlJJJJKU kkkkpyvqp/4lujf+EMb/AM8sWlZYyqt1jzDWAknyCzfqp/4lujf+EMb/AM8sWoRI1SU84/61Z15P 7J6Pk5jO1z4prPwL9fwUR9aOsY5nqXQsimr862lzbgB4kNg/grX1i6vb0m3CtcSzCL3DIe1u7gS1 vzKy+l53Xj1HBysrIc6nqjrP1EsAFVQ1Y6eZ8UlPU4eXTmY1eTQSa7RubIIP3FHTAACBoE6Sli4N Bc4wBqSUNmTj2AlljXBolxBBgIXUsZ+X0/Jxq3Bj7q3Ma48AuESYXP41VzPW+rluPRj5duETXk0u LmODYrJfLWuBkykp6avIotn07GvjnaQU7LqrJ2Pa7bzBmFxubl5HS+n5fSn49VGUzEDxk4zi4Oa0 tY4nc1pBT9Za3pdv+TP0YfgPNmw+EbXnz80lPYsuqsJDHtcW8gGYU1y+Nj0YnVej/Yxt9fHd68H6 Q2g7nfNdQkpSrYP83Z/x1v8A1bkZ/q6bA0+O4kfklVcI5Hp2QGfztvc/vu8klN1JCnJ/dZ95/wDI pTk/us+8/wDkUlJUkKcn91n3n/yKU5H7rPvP9ySkqSFOT+6z7z/5FKcn91n3n+5JSRZ3VOq4vSK2 221uIeYlg7+auzkeDPvP9yqdT6e/qOI/GtDAHcOBMg+PCButN10OHiHF8vWm1jZFeTQy+oyywBzT 8UVZnSen39MxhiixtrZlm4kEeXCvzkeDPvP/AJFIbaokAJHhNjolSQpyP3Wfef7kpyf3Wfef/Ioo SpIU5P7rPvP/AJFKcn91n3n/AMikpKkhTk/us+8/+RSnJ/dZ95/8ikpKkhTk/us+8/8AkUpyf3Wf ef8AyKSkqSFOT+6z7z/5FKcn91n3n/yKSkqSFOT+6z7z/wCRSnJ/dZ95/wDIpKSpIU5P7rPvP/kU pyf3Wfef/IpKSpIU5P7rPvP/AJFKcn91n3n/AMikpKkhTk/us+8/+RSnJ/dZ95/8ikpKkhTk/us+ 8/8AkUpyf3Wfef8AyKSkqSFOT+6z7z/5FKcn91n3n/yKSkqSFOT+6z7z/wCRSnJ/dZ95/wDIpKSp IU5P7rPvP/kUpyf3Wfef/IpKSpIU5P7rPvP/AJFKcn91n3n/AMikpKkhTk/us+8/+RSnJ/dZ95/8 ikpKkhTk/us+8/8AkUpyf3Wfef8AyKSkqSFOT+6z7z/5FKcn91n3n/yKSkqSFOT+6z7z/wCRSnJ/ dZ95/wDIpKSpIU5P7rPvP/kUpyf3Wfef/IpKSpIU5P7rPvP/AJFKcn91n3n/AMikpKkhTk/us+8/ +RSnJ/dZ95/8ikpKkhTk/us+8/8AkUpyf3Wfef8AyKSkqSFOT+6z7z/5FKcn91n3n/yKSkqSFOT+ 6z7z/wCRSnJ/dZ95/wDIpKSpIU5P7rPvP/kUpyf3Wfef/IpKSpIU5P7rPvP/AJFKcn91n3n/AMik pKkhTk/us+8/+RSnJ/dZ95/8ikpKkhTk/us+8/8AkUpyf3Wfef8AyKSkqSFOT+6z7z/5FKcn91n3 n/yKSkqSFOT+6z7z/wCRSnJ/dZ95/wDIpKSpIU5P7rPvP9ym3ft98B3eOElMkkkklOV9VP8AxLdG /wDCGN/55YtDIqddRZU15qc9paLG8tJ7hZ/1U/8AEt0b/wAIY3/nli1UlPMPq+t3ThBFPW8Vv5rg K7o+ftcUfF+tvSLLW1Z1b+nZTdBXks2x5NfwsTK+tn1no6nfh5FWPgsbY5uO/JDgx7J9pFgkcLVx Kev9SsYOrU4ORgOHvNfvMfyZSU9Ix7HtD2EOa4SHDUEKSHRRVj1NpqaGVsENaOAAiJKR3VNuqfU+ drwWmDBg+ap0dEwKPVLGuL7m7H2OcS/b+6HHhaCSSnPp6H06kWj0zYb27LHWEvJb+7LuyWL0Tp2K Hiusu9Rnpu3kv9n7vu7LQSSU0MLouBg2erQw7wNrS5xdtb4NngK+kkkpSrYP83Z/x1v/AFblZVbB /m7P+Ot/6tySmwkkgZ2WzDxbMiwEtYJgalIC9FHRPInzSXntn1l6g7qP2wOIAMCr83b4Ltul9Rq6 jiNyK9J0c09ipcmCUACerHDLGZIDdSSSUTIpJJJJTxP1qzsnC61VZTY4bWh2yfbPwV3of1qyuoZ7 MW2trWuB1HkpfWT6uZnUswZFDmhrWbSDzosf6o4zh1steQ19AcC08nsofUJ+BLogYZ8tehnCH2Pf J0ydTOcpJJJJSkkkklKSSSSUpJJJJSkkkklKSSSSUpJJJJSkkkklKSSSSUpJJJJSkkkklKSSSSUp JJJJSkkkklKSSSSUpJJJJSkkkklKSSSSUpJJJJSkkkklKSSSSUpJJJJSkkkklKSSSSUpJJJJSkkk klKSSSSUpJJJJSkkkklKSSSSUpJJJJTlfVT/AMS3Rv8Awhjf+eWLVWV9VP8AxLdG/wDCGN/55YtK 1/p1uftL9oJ2t1JjsElPN9V+s/Tciy3puFhu6xkMJZYxrR6THDkPsfoI8lU+rX1c6vidT+33ZDML GdP+S6HF7NfEu/gqf2b/ABY5WVa/La3DzLHF99WU6zHfucZJIeWj7kfHf/i26LlMy8O6p2U3+abR Y+95J0gNY5ySnt0lXwsoZeLXkit9QsG4MtG14/rN7KwkpSShbu9N+z6W07fjC5jpXVbMemepZOSO o+jZZ9myGbK3Fkk+mdgmB5pKeqSXIu6r1Pp+L0/qV+Q69nUGONtBA2sLqzazZAnSIU2dS6nhV9Oz sjIdezqDHOtpIG1pLPUbsgfJJT1aS5XF6h1OuvpfULcl1repWbLMcgbGh0luyBOkLqklKVbB/m7P +Ot/6tyM95bw1zp8I/iQquFaRXZ+jf8Az1nh++7+UkpuqL2NsYWPAc1wggqHrO/0T/w/8kl6zv8A RP8Aw/8AJJKeI+svRaunZFd1U/Z7nat8D4LsemV49eDSMYBtZaCI81Q+smOc3pVrBU7ez3tJjt81 X+qPUDd030S1zn0HbpHHzIU85GeEG9YGiwxAjkIA0kHokkL1j/on/h/5JL1nf6J/4f8AklAzJUkL 1nf6J/4f+SS9Z3+if+H/AJJJSRcV1dp6R9Z6stmlV5Bd4a6OXY+q7/RP/D/ySwPrhiOy+neq2pwf QdwOnHfumTGl9tWflZAZOE/LP0H6vRMeHtDhwRITrF+rPUzl9Lrlrn2Vex8RyPmtb1nf6J/4f+ST gbALFOBhKUT0NJUkL1nf6J/4f+SS9Z3+if8Ah/5JFalSQvWd/on/AIf+SS9Z3+if+H/kklJUkL1n f6J/4f8AkkvWd/on/h/5JJSVJC9Z3+if+H/kkvWd/on/AIf+SSUlSQvWd/on/h/5JL1nf6J/4f8A kklJUkL1nf6J/wCH/kkvWd/on/h/5JJSVJC9Z3+if+H/AJJL1nf6J/4f+SSUlSQvWd/on/h/5JL1 nf6J/wCH/kklJUkL1nf6J/4f+SS9Z3+if+H/AJJJSVJC9Z3+if8Ah/5JL1nf6J/4f+SSUlSQvWd/ on/h/wCSS9Z3+if+H/kklJUkL1nf6J/4f+SS9Z3+if8Ah/5JJSVJC9Z3+if+H/kkvWd/on/h/wCS SUlSQvWd/on/AIf+SS9Z3+if+H/kklJUkL1nf6J/4f8AkkvWd/on/h/5JJSVJC9Z3+if+H/kkvWd /on/AIf+SSUlSQvWd/on/h/5JL1nf6J/4f8AkklJUkL1nf6J/wCH/kkvWd/on/h/5JJSVJC9Z3+i f+H/AJJL1nf6J/4f+SSUlSQvWd/on/h/5JL1nf6J/wCH/kklJUkL1nf6J/4f+SS9Z3+if+H/AJJJ SVJC9Z3+if8Ah/5JL1nf6J/4f+SSUlSQvWd/on/h/wCSS9Z3+if+H/kklJUkL1nf6J/4f+SS9Z3+ if8Ah/5JJSVJC9Z3+if+H/kkvWd/on/h/wCSSUlSQvWd/on/AIf+SS9Z3+if+H/kklJUkL1nf6J/ 4f8AkkvWd/on/h/5JJSVJC9Z3+if+H/kkvWd/on/AIf+SSUlSQvWd/on/h/5JL1nf6J/4f8AkklJ UkL1nf6J/wCH/klNrtwmC3yPP4JKZJJJJKcr6qf+Jbo3/hDG/wDPLFqLL+qn/iW6N/4Qxv8Azyxa VrXvqe2t/pvcCGviYPjBSU4f1nyWVjGxa+m1dTy8txbTVeG7BtEkuc4FV+iY/WqMxjbeh9PwMZ0+ pbjPG8f2RW2VS6h0Hq9mXi05X1heMgvLsaKGAhzRJ1HktDExurYHUsZuf1x2U28lrMc0sbvIE/Sb wkp6NOkkkpi4EtIaYJGh5WO/oWTmZlOT1TIbcMZtjaa6mbBNrfTc50kz7StpJJTgUfVmwtx6MzJ9 fFwmOZjVhu0w5pYC8zqWtKli/Vy1px68zJ+0Y2E1zMesN2mHDbLzJkhq3UklOFifV2+l2LVflerh 4Di7GqDIdPbe6ddsrdSSSUpVsH+bs/463/q3Kyq2D/N2f8db/wBW5JTZSSSSUxc0PaWnUOEFcd0V x6X9Y7sJ2ldxIb+Vq7Jcj9b6XYudjdRr0MgOI8W6qbAbMoH9MMWUVUh+iXrkkLFvbfj13N1D2h33 oqh20ZbXSSSSUsoX1NuqfU4S14IPzREySni/q1a7pnXMjplphlhO0eY4/BdouO+uGO/D6hjdVpEa gPI8W/7F1eHkNycWu9pkWNDp+KZDQmPZs8yOIQyj9MVL+8E6SZOntZSSSSSlJJJJKUkkkkpSSSSS lJJJJKUkkkkpSSSSSlJJJJKUkkkkpSSSSSlJJJJKUkkkkpSSSSSlJJJJKUkkkkpSSSSSlJJJJKUk kkkpSSSSSlJJJJKUkkkkpSSSSSlJJJJKUkkkkpSSSSSlJJJJKUkkkkpSSSSSlJJJJKUkkkkpyvqp /wCJbo3/AIQxv/PLFpW2Nqqda6drAXGNdAs36qf+Jbo3/hDG/wDPLFqQkp826zkfVLO6rX1C/Kzq SXHexpsaCSNoFf7vyWl9XnfVE9ZpbiOy7s4Amn7U6xwaO5G/hbP1kwsw2YWdhYzcv7HYX2Y2gLgR Eie4VTFd1Xq3WsTLf049Oow9xsssI3v3CNg29klPVJJJJKUkksGn6yi/rt/TK6ZpppfaMidHPrLW uaPhuSU7ySxOldbyMzEOdc2pmOGOsIY/c8BpPI+Shj/WO4uxrMvHFOLnNc7HsDpMNG73DzCSneSW DjfWK+x+JbdjCvDz3lmPZul0/mlzfOFvJKUq2D/N2f8AHW/9W5HdYxn0jEqrhXVCuyXD+et/6tyS m4kh+vV+8EvXp/eCSmay/rJhfbOk3NAl9Y3s+IWj69X7wTPtpc0tLhBEH5oxNSB7G0SFgju4n1Oz fX6b6LjL6Dtjy7LfXGdFtHTPrFdiOMVXEhvhPLV2Hr1fvBSZxU7G0tQsxG40d46JEkP16v3gl69X 7wUTIkSQ/Xq/eCXr1fvBJTR6/gjO6XdVEvA3M+IWX9Sc424VmFYf0mM6AD+6V0JupIguC4tjx0b6 1aGMfIMeUP8A9qZLSQl9Gzh9eLJj6j1x+m73CdCF9P7wT+vT+8E9rJEkP16v3gl69X7wSUkSQ/Xq /eCXr1fvBJSRJD9er94JevV+8ElJEkP16v3gl69X7wSUkSQ/Xq/eCXr1fvBJSRJD9er94JevV+8E lJEkP16v3gl69X7wSUkSQ/Xq/eCXr1fvBJSRJD9er94JevV+8ElJEkP16v3gl69X7wSUkSQ/Xq/e CXr1fvBJSRJD9er94JevV+8ElJEkP16v3gl69X7wSUkSQ/Xq/eCXr1fvBJSRJD9er94JevV+8ElJ EkP16v3gl69X7wSUkSQ/Xq/eCXr1fvBJSRJD9er94JevV+8ElJEkP16v3gl69X7wSUkSQ/Xq/eCX r1fvBJSRJD9er94JevV+8ElJEkP16v3gl69X7wSUkSQ/Xq/eCXr1fvBJSRJD9er94JevV+8ElJEk P16v3gl69X7wSUkSQ/Xq/eCXr1fvBJSRJD9er94JevV+8ElJEkP16v3gl69X7wSUkSQ/Xq/eCm1z XCWmQkpdJJJJTlfVT/xLdG/8IY3/AJ5YtVZX1U/8S3Rv/CGN/wCeWLVSU8r9YMCjExq22uz7an3P tfZjPJczfrBj80dkP6vY/QH5td2H1PJuvZMY19rp+bHQtT6z1/WKzEb+wrqqbAf0xt0Jb/JcQ4Ar l/q4/ow+sVVfUGXv69B22vsbczjxqgD5hJT6EkkkkpHkMssosrrf6b3tLWvidpI5XM4HQOq4HWsW z1GXYlGJZU9waAXOc9joPm6JldUmSU8tb0i/OzmPxsM9NpbVay8mB6hsbDRDZ4OqVXTOp5tXT8LJ oOOzp9bm2Wkgh7tnpt2R2XUpJKeXw+ndTsr6Z0+/HNTOm2b7LyQWvDZDdka6yupSSSUsQDyq+E1v p2aD+et/6tysqtg/zdn/AB1v/VuSU2NrfAJbW+ATpJKW2t8Altb4BOkkp5D64Y7sbMxupVCCCAT5 tMhdRiXV5ONXewAtsaHD5ql9YsIZnSbmAS9g3s+LdVS+pmb6/TjjuPvx3QB/JPCml6sIPXGa+hYh 6chHSb0G1vgEtrfAJJ1CyrbW+AS2t8AnSSUx2t8AuZ+u+BvxK82se/Hd7iP3T/tXToGbjMysW3Hf q2xpafmhIWCGTDPgyRl2P4NXoOa3O6XTfoXxtf8A1hytDa3wC4/6m5L8TOyek3aGS5g826Oj5LsU IG4hPMQ4MkgNj6h5FW1vgEtrfAJ0k5iW2t8Altb4BOkkpba3wCW1vgE6SSltrfAJbW+ATpJKW2t8 Altb4BOkkpba3wCW1vgE6SSltrfAJbW+ATpJKW2t8Altb4BOkkpba3wCW1vgE6SSltrfAJbW+ATp JKW2t8Altb4BOkkpba3wCW1vgE6SSltrfAJbW+ATpJKW2t8Altb4BOkkpba3wCW1vgE6SSltrfAJ bW+ATpJKW2t8Altb4BOkkpba3wCW1vgE6SSltrfAJbW+ATpJKW2t8Altb4BOkkpba3wCW1vgE6SS ltrfAJbW+ATpJKW2t8Altb4BOkkpba3wCW1vgE6SSltrfAJbW+ATpJKW2t8Altb4BOkkpba3wCW1 vgE6SSltrfAJbW+ATpJKW2t8AkABwnSSUpJJJJTlfVT/AMS3Rv8Awhjf+eWLRts9Kp9m1z9gLtrB LjHYBZ31U/8AEt0b/wAIY3/nli1UlPC9e+svRuoCmvqXS+sV1tfDGNpNYe46bTFg3K79X+sdAZn1 9MwejZeBfY0uD7scViB3Lt5K0vrHg9StfiZ/TRXbkYLy8UXHa14cII3diqOI36wdV6viZfUsWjp1 GFuc1jLm3WWOcIiWaBqSnqUkkklKSSWUz6xdPf1i7pDd5ux6jdZbA9MBpaC3dP0huHZJTqpLHx/r Nh3WVh9N1FOQHOxsiwNDLAwSdu1znDQT7gE+L9ZMTIuqYabqK8gOdjX2hoZYG8lu1znD+0Akp10l kY31kxMi6lno3V05LizGyXtaK7HN7NhxcPm0LXSUpVsH+bs/463/AKtysqthfzdn/HW/9W5JTZSS SSUpJJJJTFwBBB4OhXHdKJ6V9aLcM/zV5LW/P3NXZLkfrljvxszG6nVo5pAJ82mQpsBsygf0xTFm FAS/dNvXJ0HFyGZONXkM1ba0OHzCKodmVdJJJJSkydMkp4r6yVu6V1/H6nUIbaZd8W6OHzBXZ1WN srbY3VrwCPgVjfW3p/2zpL3NE2Y59Vny+kPuTfVDqH2vpTa3GbMc7HfDsmDSZH72rZyevBCfXH6J eXR3Ukkk9rKSSSSUpJJJJSkkkklKSSSSUpJJJJSkkkklKSSSSUpJJJJSkkkklKSSSSUpJJJJSkkk klKSSSSUpJJJJSkkkklKSSSSUpJJJJSkkkklKSSSSUpJJJJSkkkklKSSSSUpJJJJSkkkklKSSSSU pJJJJSkkkklKSSSSUpJJJJTlfVT/AMS3Rv8Awhjf+eWLVWV9VP8AxLdG/wDCGN/55YtVJTyn14uw 6z09nUcl2P0+y0jIFbyxztNPo6wO6F0Kj6it6nU7pWX6uZr6bPWe+f7JK0vrPnXUfZsbFxKszKyX OFYvA2NDRucdQVjdA6v1S3OwH5WBh42Pm7xXbUBvDmT7eNDokp7dJJJJSLI9Y0WehHrbT6e7jdGk rjKOk9ap6qyizHr3WYGQ27Ia9zg6yx7HOdJYPcTwPBdwkkp4qyjJ6pgdL6dTRZVfg1u+0l7C0MLa nV7ZOh3HwRGV5HUsfpeDXRZVdg1uGSXsLQxwrNe2TzJXYpJKePw2X5GP0fpwosZkdPs3ZO5ha1oY CPpHQ7l2CSSSmD698e4iPAwquFTNdnvd/O2jn+W5XVWwf5uz/jrf+rckpJ6H8t/3peh/Lf8AeipJ KReh/Lf96Xofy3/eipJKRej/AC3/AHrO+sHTftfSr2Auc9jd7ATOrdVqpEAiOyMZEEEdESFgh5v6 nZP2jp7qHPcH0OgAGPadV0Ho/wAt/wB65DpZ/ZP1ntwzpVcSG/B3uauzUmcVOxtMcQWYj6aO8dEf ofy3/el6H8t/3oqSiZEXofy3/el6H8t/3oqSSkD8Zr2Fhe4hwIInxXHdHnpP1kt6fY4squJDYMeb P7l265H664jqbcfqlWjmODXEeWrSmTG0v3WxypsyxHbKK/wuj1Xoj99/3pej/Lf96F07LbmYVWS3 /CNBPx7qynsBBBIO4R+h/Lf96Xofy3/eipJIReh/Lf8Ael6H8t/3oqSSkXofy3/el6H8t/3oqSSk Xofy3/el6H8t/wB6KkkpF6H8t/3peh/Lf96KkkpF6H8t/wB6Xofy3/eipJKReh/Lf96Xofy3/eip JKReh/Lf96Xofy3/AHoqSSkXofy3/el6H8t/3oqSSkXofy3/AHpeh/Lf96KkkpF6H8t/3peh/Lf9 6KkkpF6H8t/3peh/Lf8AeipJKReh/Lf96Xofy3/eipJKReh/Lf8Ael6H8t/3oqSSkXofy3/el6H8 t/3oqSSkXofy3/el6H8t/wB6KkkpF6H8t/3peh/Lf96KkkpF6H8t/wB6Xofy3/eipJKReh/Lf96X ofy3/eipJKReh/Lf96Xofy3/AHoqSSkXofy3/el6H8t/3oqSSkXofy3/AHpeh/Lf96KkkpF6H8t/ 3peh/Lf96KkkpF6H8t/3peh/Lf8AeipJKReh/Lf96Xofy3/eipJKReh/Lf8Ael6H8t/3oqSSkXof y3/el6H8t/3oqSSkXofy3/eptbtEST5lSSSUpJJJJTlfVT/xLdG/8IY3/nli1VlfVT/xLdG/8IY3 /nli1UlPM9U+sf1YHUG15VzhfgOJ9RrTsDo1YX8T5LL+rv7Gu6821rMyguL7cGjI0pJd9J1SFk9O +tDenZnSq+k1XV35Flzcg2gEh1m8HbHgtLHZ9ZM7qfTXZvTWYePhOLnWNtDz9HbEQElPWpJJJKUk koNsrcSGuBLfpAEGPikpmkhsvoe7ayxrnd2tcCfwTixjnFrXAubyAdQkpmkoCxhcWBwLhy0HUfJT SUpVsH+bs/463/q3Kyq2D/N2f8db/wBW5JTZSSSSUpJJJJSkkkklPJfXPHdTkY3UqtHNIa4jxGrV 0uFkNysSnIbqLGB33hVuvYQzel31AS4N3M/rN1WZ9S831cF+K4+6h2g/klTH1YQeuM19CxD05D2n r9XpEkklCyqSSSSUsqXWcFud06/GPLm+0+BGoV1JIi0xkYkEbg28r9SM0+ld0+3R9LiWg+HddUuJ zQei/WlmQ3205B93h7tCu1aQQCNQdQmYzpX7ujPzURxDIPlyji+vVkkkkntdSSSSSlJJJJKUkkkk pSSSSSlJJJJKUkkkkpSSSSSlJJJklLpJJklLpJk6SlJJJJKUkkkkpSSSSSlJJJJKUkkkkpSSSSSl JJJJKUkkkkpSSSSSlJJJJKUkkkkpSSSSSlJJJJKUkkkkpSSSSSlJJJJKUkkkkpSSSSSnK+qn/iW6 N/4Qxv8Azyxaqyvqp/4lujf+EMb/AM8sWqkpSSSSSlJJJJKWcAQQeDoVyTcc431oxqfs4wa8ii+q j0zIucBu/SRxtAldY9oe0tdqHCCPIrPx+gdNx7xkMbY+1jSyt1ttlmxruRX6jnbfkkpwaXXdBqZg ZGLUMm2i70Muklxc5gc/3y0HhCDGYWL0bNw9MnIqcbnDU2TWXuLvH3LpMfoXTqLvXDX22hpY199t lxa13LW+q50A+SbE6B0vDtFtFTtzQRWHve9rA7kVte4ho+CSnnsWqunE6Fn06ZeVb+ntB9zw8OLt y7NZuN9X+l4uQMimtwcwk1tc97mMLudlbnFrZ8gtJJTB5s02AHxkwquEb/Tshrf563uf33eSuqtg /wA3Z/x1v/VuSUk3ZH7rfvP9yW7I/db95/uRUklIt2R+637z/cluyP3W/ef7kVJJSLdkfut+8/3J bsj91v3n+5FSSUhPrkRtbB8z/cuPwTZ0j6z2Y8AMvJgdofq1dquU+ueM6uzH6jXo6s7XEfeFNgOp gdpimLKNBIfol6ecj91v3n+5Kcj91v3n+5D6flNy8KnIbqLGg/PurChIo0yA2LR7sj91v3n+5Ldk fut+8/3IqSSUW7I/db95/uS3ZH7rfvP9yKkkp5r644NuR08ZO0B+Md0gyY7q39XOo25vS6nANLqx sdJ10+S081tb8S1tglhYdw8oXBfV7r9fSLLm2Ne+iwywNiR95UciIzB/ebeOEsuCUQLljNx+r385 H7rfvP8AclOR+637z/cgdM6jV1LEblVNcxriQA6J0+Eq2n21SCCQdwj3ZH7rfvP9yW7I/db95/uR UkUIt2R+637z/cluyP3W/ef7kVJJSLdkfut+8/3Jbsj91v3n+5FSSUi3ZH7rfvP9yW7I/db95/uR UySke7I/db95/uS3ZH7rfvP9yKmSUj3ZH7rfvP8AclOR+637z/cibglKSkc5H7rfvP8AcluyP3W/ ef7lNzmtEuMDxKoZXXuk4s+rksBH5oMn7ggSBukRkdgT5Nycj91v3n+5Kcj91v3n+5YT/rfXadvT 8S7Kd2IEN+9R+0fW/N/mqqsFh7u9zh9/9yHGOmrJ7Ev0qh/eLe611mzpOO259Qs3u2wHR/BY9X16 9S1lf2WN7g2d3iY8ELq31b63bQ19mU7NtLtauGt8xqsuv6r9bFjCKSzUe6RprymSlO9AabWLDyxx +qYMter6CHZBE7W/ef7k85H7rfvP9y53d9benfSDOoVD5PhGo+uGHu9POqsw7O4eDH3hP4h1082q cEt41Mf1Xc3ZH7rfvP8AclOR+637z/coY2diZTd2Pa20fyTKOnMZBGhFI92R+637z/cluyP3W/ef 7kROkhFuyP3W/ef7kt2R+637z/ciJ0lIt2R+637z/cluyP3W/ef7kVJJSLdkfut+8/3Jbsj91v3n +5FSSUi3ZH7rfvP9yW7I/db95/uREklI92R+637z/cluyP3W/ef7kVJJSLdkfut+8/3Jbsj91v3n +5FSSUi3ZH7rfvP9yW7I/db95/uRUklIt2R+637z/cluyP3W/ef7kVJJSLdkfut+8/3Jbsj91v3n +5FSSUi3ZH7rfvP9yW7I/db95/uRUklIt2R+637z/cluyP3W/ef7kVJJSLdkfut+8/3Jbsj91v3n +5FSSUi3ZH7rfvP9yW7I/db95/uRUySke7I/db95/uS3ZH7rfvP9yIkkpHuyP3W/ef7lNpdHuAB8 lJJJSkkkklOV9VP/ABLdG/8ACGN/55YtVZX1U/8AEt0b/wAIY3/nli1UlKSSSSUpJJJJSkkkySl0 kySSl0kydJSlWwf5uz/jrf8Aq3Kyq2D/ADdn/HW/9W5JTZSSSSUpJJJJSkkkklLKh1vDGZ0y6mJd tJb8RwtBMRIg8FEGiD2QRYI7vN/UrML8OzDefdQ7QeRXSLjcaekfWp9X0acg6fB2v5V2Skzj1cQ2 mOJZiPp4TvE0ukmSUTIumTpJKQ5LC/Hta0S5zCAPiF5v/wA3utf9xLPuXpqUJk4CW7Pg5mWHi4QD xd3kOlYX1rwsNpxjXsBP6taII/J+VXB9Y+q4unUemvAHNlXuH3f7V0aYtB51REa2JRLOJEmcIm+2 hcjG+tfR7ztdb6L/AN2wFv5Vp1ZWPeJqsa8eRlByOk9OyQRdjsfPeNVmW/U/AndiW24j+2xxj7il 6h4qrCesof8AODvJLnP2Z9aML+i5rclg4baIJ/1+Kzur9f8ArHiNrZdUMV5J97YcHfeCgZ1qQUx5 czIEJxlf0e0SXn2J9autnJrDn+sCf5sNaC7y4W/+0/rTk/0fAZSPG10/+RSGQHa05OUyQIEjEX/W eiTFzW8kD4rnf2f9asn+eza6GnkMEn8ik36pus/pmffd5A7R+Uo2eg+1Z7cB82Qf4IJde7qnT6BN uQxvxcFn5P1s6NW0tZd6jiCBsBd/BSp+qfRajJp9R3i8kq/V0zp9IirHrZ8GgJerwCv1A/fl9gfM bsq99z3ix4DnEgbj3K3/AKvN+sWThuZg3Mqp3HdY/wBzp8pldC76qdEc4vdRq4yfc7v81ewOnYnT 6jTis2MJkiSdfmmRxyBsltZucxyhwwhr/WDit+ql2Qd3UuoXXn91p2t/GVfxfq10bGgsxmucPzn+ 8/8ASlaiSeIjs1DmyHTiIHYaD8GLKq6xDGho8AIUkkk5jUknSSUsg5GJjZLdt9TbWns4A/lRkklA kbOBk/U/p7nGzDfZh28g1nSfgf70D0Prb03+atZ1CkcB/wBOPy/iV0ySbwjpoyjPPaVTH9bV56r6 3V1u9PqWLZiP4JI3N++FXu+vWMy1zGY7rGAw14cII8V0t2PTe0ttY14PZwlcFm/Vbqpy7jTR+iLz sggCE2fGBpqz4By+QnjHB/haPWdD67X1dlr21mr0iBBIMytSR4rjui/VTKLLDmWW4rpGwVuifitP /mo4fR6hkD5oxMq1CzLjwCZEclDyv8XfkJLn/wDmvlD6PVLx/r8U3/NnqP5vVrh8p/78jZ/dY+DH /nP+aXoUHKzMbDr9XJsFTJjc7QSVif8AN7q4+j1aw/Fv/mSyvrF0zqWNhB+TnHJZuA2OEfPlK5HQ RNpjixki8orru9K36w9GcQ0ZdZJ0AnxWgCCJHBXk7GkPYWGHBwgnjldlXm/WmpogY17QOzgD+VEj JE1OP2JljwyiJYsgP9409OkucH1h61V/P9NJHdzHT/BSb9caG6X4l9R7kgEfglxBb7E+lHyIehSW LV9buiv0NpYf5bSP4K5V1zpVv83k1n5hLiHdacWQbxP2N5JYOZ9cMHFyXUGqyzZ+ezaWn8Ufpf1l w+pWPY1jqfTEk2EAH7iUegPQ6I4JaitQLLsJlXd1DCb9K9g/tBBf1vpTPpZNY/tBCx3UISO0T9jf SWU76zdEb/2qYfgZQXfW7orf8I53wa4/wS4h3T7OT9yX2O0kuU6x9a8e/CfXhG1lro22bS2PmVzn 7Y6qP+1dpI/lFERlIExjxCOui72gDETmISkaAL6ckuZxvrTkjHrH2G6xwaAX6QT4qR+tPUD9Hprv m6P4IcXgfsUcEx2/xg9KmXMH6z9XPHT2t/rWD+5Dd9Zus/8AcelnxsCWvY/YUeyesoj/AAg9WqWR 1npmLaacjIZXYOWuMHVc676zda/7qN+Lx/5Jc/1PIuy8x+RkFjrHASatW6fenRhkkQIxP1Vw4oAy yTFAfomzb6JidV6fmPLMa9trgJIaZ0VtcJ9T8mijqTha7YbW7W+ZXdpShKBqQ1WGWOVHGSY113XS SSQQpJJJJTlfVT/xLdG/8IY3/nli1VlfVT/xLdG/8IY3/nli1UlKSSSSUpJJJJSxEgjie65A512D 1w11PyGVDGuc5uVP6WxmoNQPhyV1zhuaWzEiJCyW/V9r8urJzch+U7HY9lIfADRYNjjp326JKcSz LzOm4fTOpi+y6zOY45DHOlpLqzYC0dtpRGZGXgU9L6h69lz86tzshj3S0k1mwbR2hauN9WaKzU26 599GM1zMep/DA8bfnoU+J9XKaH0+rc++rGa5mPU/hgcI+eiSnKxbsumnpHUjkWWW9Qt25DHOlkPB Ptb2iF1qx8T6uU49lG699tGI4uxqHcMJ/uWykpg+zb+a53wEqrhXRXZ7H/ztvb+W5XVWwf5uz/jr f+rckpJ6/wDIf/mpev8AyH/5qKkkpF6/8h/+al6/8h/+aipJKRev/If/AJqXr/yH/wCaipJKRev/ ACH/AOal638h/wDmoqZJTx31xso+0491ZLclnLSIMdlr9D+sFPUKBW8EZLBDmATMdwqP1n+rr8hz s/Fl1kfpK/GO4WJ0/C6pg+n1QUOdUx2reDHw8FbEcc8IF+qO38GsZTjkJrQvf+t/If8A5qXrfyH/ AOaqnS+tYfUq5pdtsH0q3aOCvqqQQaIotgEEWCj9f+Q//NS9f+Q//NRUkEovX/kP/wA1L1/5D/8A NRUklIvX/kP/AM1L1/5D/wDNRUklIvX/AJD/APNS9b+Q/wDzUVJJSL1h+4//ADVk9d6QzrDag51l XpEnRkzK2kkCLFLoTlCQlE0Q8rhfVGvEyqsgXWONbg7b6fMfNdN638h/+aiJJCIGwTkyzyEGZshH 638h/wDmpet/If8AcipIrEXr/wAh/wDmpev/ACH/AOaipJKRev8AyH/5qXr/AMh/+aipJKRev/If /mpev/If/moqZJSP1/5D/wDNS9f+Q/8AzUVJJSL1v5D/ALkvX/kP/wA1U+s9Yo6Xjl7zutd/N19y Vj9E+tjbnup6g4McSSyzgfAp4xTlEyA0WHJAHhJ1ek9b+Q//ADUvW/kP/wA1U3/WDo7PpZTPy/kQ XfWrozeLi7+q0lDgn+6U8cf3g6XrfyH/AOal638h/wDmrIP1u6b+Yy158mFQP1qaf5vByH/2YR9q f7qPch3dr1v5D/8ANQMjqeLjFoyCa95hu4clZf8Azg6k/wDmemWnw3aLlOtZOffmudmtdXYPo1n8 0eSkx4DI0SBosnmERYD6KLwRIY8g94UbMyqsTZLR5iFyXQ/271Kn0mZDqcasR6kanyC16/qpjuO7 MyLch3fc6B9ybLHGJIlLbsuE5SFiLYt+s3SKSWutlw7NBJ/BVXfWiy47cDBtuPZzhtC0cfonS8aP Sx2SO5En8VdaxrRDQGjwCbeMbRMvNNTO5A8nnDkfWvLMCpuGzxIkqvmfVzPyqHOvyrLrwJawtIZK 6xJEZSD6QI+SDjBGpJfNsLoubk5n2Z1bmbD+lMfRC6ofVnpgaBtvBjUglbwY0EuAAJ5PinTsnMTk R+j5IhhjG+rz5+rGD2flN+Diou+rOOeL8n56rokkz3Z91/BHt9jy1n1Qofzdd82BAd9SKe19nzr/ ANq7BKEDkJ3o/RcLG0pD6l806n0nJ6dbssa70phlhEAo3Seg5XUdzwXVUj/CAEyfBd/lYmPl0mnI YHsPYqVNFVFTaqmhjGiAApTnBxiHCL/BjjCUchmJF5D/AJkT9K95/sFOPqRWOb3/APbf+1dkkohK ug+xlMpnecvteRb9S62mRkWA+Vf+1Fb9VNnGTcP+thdSkj7kvD7FpF9ZfaXlr/qs59LmjIucY9rX M0n5Lna+i57837H6ThYOdOB4r0tNsbu3QNx0nunw5iUQRobY54YyINl52n6r4wra223Jc4DWCQEQ fVnpg+kMh3xJW+kme7P94ruCPZwx9WujDnHsd8dyI3oHRm8Ybj8QVsJIe5P94/angj2Dlt6R0hv/ AGi+9qpdY+r2Jl0fqtJovZ9GGwD5FdCkiMkwQRIqMIkUQHmPq50D7GftObU43/mMiQ3z+K6P1v5D /uREkJzMzclRiIigj9f+Q/8AzVNrtwmCPI6FSSTVykkkklOV9VP/ABLdG/8ACGN/55YtVZX1U/8A Et0b/wAIY3/nli1UlKSSSSUpJJJJSkkkklKSSSSUpJJJJSlWwf5uz/jrf+rcrKrYP83Z/wAdb/1b klNlJJJJSkkkklKSSSSUpJJJJSyYtbG2BHgpJklOB1T6tB1n2zpjvs+U3WBo0qHTfrI+u37F1dho vGgsOjSuiVLqXScPqVXp5DJI+i8fSHzUgyAjhmLHfqGMwINw08OhbjXBwDmmQdQQnXJizq/1bfFk 5XTp+l3b/cui6f1LE6hSLcZ4cPzm9wfAhCWMjUHij3CYzB0OkuzbSTJ0xepJJJJSkkkklKSSSSUp JJJJSkkkklKSSSSUpJMkkpSSSo9R6zgdObORYN/aturj8kQCTQFoJAFk03lmdS+sHT+nja53q3dq mamfNZRy+vddO3EYcLDPNrtHOHktLpv1cwMEixw9e/k2v1M+SfwRj85s/uj9pWcUpfKNO5cPJ6d1 j6w2farKhjVtb+iDuSq3R/qxlZGWRmMNdNRh8/nHwC7vyCSf95mAYgCI2Hgj2Ikgk2WizofSmCG4 zNPESjN6fgs+jQwf2QrCdQ8Uu5ZOEdgjFFI4Y0fABTDQOBCdJBKyz+q9FxOptaLhD2nR45+C0EkR Ig2DRQQCKIRY2NTi0tppaGsaIACKknQ8SlSSSSSlJJJJKUkkkkpSSSSSlJJJJKUkkkkpSSSSSlJJ JJKUkkkkpSSSSSlJJJJKUkkkkpSSSSSlJJJJKUkkkkpyvqp/4lujf+EMb/zyxaqyvqp/4lujf+EM b/zyxaqSlJJJJKUkkkkpYzBjQ9iuf+29Vxeu1dPdkDMbfj23WNDA01FkbCI7OJjVb7t207Y3QYni Vh9G6V1jBvuvyn4992US6/JG/wBQwPY1oIgNb4JKavSet2DHdbnZlhzWVPsfhW0mn6M/R3tbujyS q6v1TFbgZuZa26jqDHOdSGhvpnZ6jQ1w5001Vu7omb1DMqyOp2VbcdljK2UB2psbsLnF3l2UMb6v ZhGLRn3V242AxzKAwEOdI2AvnuG+CSkGL1XqrW9Nz77m2UdSs2OxwyAwOks2u57Lp1z+J9X82s4e Pk31vw+nOL8cNB9R3Zu+dNJ7LoElMH21s+m9rZ4kgflVXCyKBXZNjR+ltP0h++5XFXwf5uz/AI63 /q3JKSfacf8A0rP84Jfacf8A0rP84IkJQkpH9px/9Kz/ADgl9px/9Kz/ADgiQlCSkf2nH/0rP84J facf/Ss/zgiQlCSkf2nH/wBKz/OCX2nH/wBKz/OCJCUJKR/acf8A0rP84Jfacf8A0rP84IkJQkpH 9px/9Kz/ADgl9px/9Kz/ADgiQlASUiddivaWPsY5p0IJEFc3n9EGLd9u6JkNqtGrqdwg+Q1/BdSk nQmYnT7FsoiW/wBrg9I+tFGU4Y2aBj5Q0M6NJ8itZ2fhMsbW69ge/wCiNw1VHrvRcbqGM94rnJY0 mt7dHSOy4K6zJF36Zz/Vq0G4nc2FNDFDLrE8PgxSySx6SHF4vp/2nH/0rP8AOCX2nH/0rP8AOC5r pn1mzRiM9fCuvIEesxuhA+Suf86qh/OYd7f7KjOGYJFX5MgyxIu3Z+04/wDpWf5wS+04/wDpWf5w WMPrf00fTrub8WKbfrb0c8ue34tKHtT/AHSr3Idw632nH/0rP84JfaMf/Ss/zgs1v1o6IebwPiD/ AHKj1r6141ePs6e8W3WaB44aPHVKOKZIHCVHJEC7eg+04/8ApWf5wS+04/8ApWf5wXK9A+tYaPs/ U36DVlx/I5bDvrR0QcZAd8Af7kZYZxNUT5KjlgRdgOl9px/9Kz/OCX2nH/0rP84LJd9bekDhz3fB pUP+d2Af5um5/wAGIe1P90q9yH7wdn7Tj/6Vn+cEvtOP/pWf5wWL/wA6S7+b6fkP+DUv+cPUX/zf S7v7WiPtT7fiFe5Hu61mfhVFosvY0vMN9w1Khl9V6fiVGy69gHYAgk/ABefdXy87JzXPzA5lrTAr Om0eAWx9WOmV9Ssfk57X3+nAY55JaY7a8qQ8uIxEpS8wGMZjKRjEfa2revdS6s809LaMenh2RYQD HkrfTvq/0zHf9oy7m5eSdS57gQD8JW6ytlbQxjQ1o0DQIAUoUZyaVEcI/H7WQQ6yPEUQvxgIFjAB wNwT/acf/Ss/zgiQlAUa9H9px/8ASs/zgl9px/8ASs/zgiQlCSkf2nH/ANKz/OCX2nH/ANKz/OCJ CUJKR/acf/Ss/wA4Jfacf/Ss/wA4IkJQkpH9px/9Kz/OCX2nH/0rP84IkJQkpH9px/8ASs/zgl9p x/8ASs/zgiQlCSkf2nH/ANKz/OCX2nH/ANKz/OCJCUJKR/acf/Ss/wA4Jfacf/Ss/wA4IkJQkpH9 px/9Kz/OCX2nH/0rP84IkJQkpH9px/8ASs/zgl9px/8ASs/zgiQlCSkf2nH/ANKz/OCX2nH/ANKz /OCJCUJKR/acf/Ss/wA4Jfacf/Ss/wA4IkJQkpH9px/9Kz/OCX2nH/0rP84IkJQkpH9px/8ASs/z gl9px/8ASs/zgiQlCSkf2nH/ANKz/OCX2nH/ANKz/OCJCUJKR/acf/Ss/wA4Jfacf/Ss/wA4IkJQ kpH9px/9Kz/OCX2nH/0rP84IkJQkpH9px/8ASs/zgl9px/8ASs/zgiQlCSkf2nH/ANKz/OCX2nH/ ANKz/OCJCUJKR/acf/Ss/wA4KbXNeNzSHDxGqeAnSUpJJJJTlfVT/wAS3Rv/AAhjf+eWLVWV9VP/ ABLdG/8ACGN/55YtVJSkkkklKSSSSUpJJJJSkkkklKSSSSUpVsH+bs/463/q3Kyq2D/N2f8AHW/9 W5JTZSSSSUpJJJJSkkkklKSSSSUpJJJJSkkkklKSSSSUssrqX1cwOoXsvsGx4Mv2/nDwK1UkYyMT YNIMQdwwqqrqrbVW0NY0Q1o4gKUDwTpIJWLGHlo+5QdjY7vpVMPxaERJKyig13dN6e76WNUfixv9 yzerfVnBzKT6FbaLm/QcwQD5ELaSTozlE2CQgwiRRDyfQvqmWWG7qTAQ0wyo6g+ZXRt6b09v0cWp vwY3+5WUkZ5JTNkojjjEUAjbjY7fo1MHwaAp7GDsE6SZa5UBJOkkly+rdBw+plrrRssafpt5I8Cr 2NjU4tLaKWhlbBAARUkTKRABOg2RwgG61UnSSQSpJJJJSkkkklKSSSSUpJJJJSkkkklKSSSSUpJJ JJSkkkklKSSSSUpJJJJSkkkklKSSSSUpJJJJSkkkklKSSSSUpJJJJSkkkklKSSSSUpJJJJSkkkkl KSSSSU5X1U/8S3Rv/CGN/wCeWLVWV9VP/Et0b/whjf8Anli1UlKSSSSUpJJJJSxMAkCSOyx29ffV 1BmFnYpxjdVZdS/cHgtq1cDHBgrXcdrS6JgEwOSuVw68nqmXk5Wfj3U5V9VmPisc32U1Ed3fvO7p Kb9P1mBdRZk4zqMXMa52NcXA7g0F3ub2kCVLG+snqWY5yMZ1GPmNc7GuLgdwaN3uHaQsp3Tuo9Sw undNsxn45wGOF1ro2lzazU0Mg6zyp14PUM+jpuDbjPx/sFbm3WvjaXBnpt2QdZ5SU6WN9ZDdZjOs xnVYua4sxry4HcR4t7Sttcph4fULquldPsxn1Hptm6+50bCGAhuwjndK6tJSlWwf5uz/AI63/q3I z2bo9xbHgYVfGxnsY8Oc4E2PcNexcSCkptpIXo/y3/el6P8ALf8AekpKkhej/Lf96Xo/y3/ekpKk hej/AC3/AHpej/Lf96SkqSF6P8t/3pej/Lf96SkqSF6P8t/3pej/AC3/AHpKSpIXo/y3/el6P8t/ 3pKSpIXo/wAt/wB6Xo/y3/ekpKkhej/Lf96Xo/y3/ekpKkhej/Lf96Xo/wAt/wB6SkqSF6P8t/3p ej/Lf96SkqSF6P8ALf8Ael6P8t/3pKSpIXo/y3/el6P8t/3pKSpIXo/y3/el6P8ALf8AekpKkhej /Lf96Xo/y3/ekpKkhej/AC3/AHpej/Lf96SkqSF6P8t/3pej/Lf96SkqSF6P8t/3pej/AC3/AHpK SpIXo/y3/el6P8t/3pKSpIXo/wAt/wB6Xo/y3/ekpKkhej/Lf96Xo/y3/ekpKkhej/Lf96Xo/wAt /wB6SkqSF6P8t/3pej/Lf96SkqSF6P8ALf8Ael6P8t/3pKSpIXo/y3/el6P8t/3pKSpIXo/y3/el 6P8ALf8AekpKkhej/Lf96Xo/y3/ekpKkhej/AC3/AHpej/Lf96SkqSF6P8t/3pej/Lf96SkqSF6P 8t/3pej/AC3/AHpKSpIXo/y3/el6P8t/3pKSpIXo/wAt/wB6Xo/y3/ekpKkhej/Lf96Xo/y3/ekp Kkhej/Lf96Xo/wAt/wB6SkqSF6P8t/3pej/Lf96SkqSF6P8ALf8Ael6P8t/3pKSpIXo/y3/eptbt EST5lJTJJJJJTlfVT/xLdG/8IY3/AJ5YtVZX1U/8S3Rv/CGN/wCeWLVSUpJJJJSkkkklKSSSSUpJ JJJSkkkklKSSSSUpJJJJSkklldX627pluPWMWy9t9rKnWiG1s3mB7jyfIJKdVJJJJSkkkySl0lld Z627pZpAxbMgWva11jYaxgcdsuce/kFoX3ejj2XkSK2F+3xgTCSkqSzOj9Sz+o1NyLcamjHsbuYW Xm1+vZzDSwD/ADlpJKXSSSSUpJJZ3VeoZ+DU+7Hwxk1UsNlrjaKzDdSGja6THjHxSU6KSr4OXVm4 dOZVIrvYHtB0MOEqwkpSSSSSlJJLM6v1LO6fW++nDGRj0t32vNorMDkMbtduPxhJTppKoOoVv6b+ 0K2l1Zq9ZrToSI3QgdI6jndQqbkXY1NFFjQ6s13m1+vZzfRrA+9JTpJJJJKUkkkkpSSzOsdTzOnV PyKsQX49TS+17rRWQB2Y3a6T8YV3FyG5WNVkMBa21ge0O5AcJ1SUmSSSSUpJJJJSkll9Y6rmdNqs yWYYvxaG77rDaGOgchjNrtx+JCPldSbR0p/UmsL2Nq9ZtZO0kEbgDzCSm6kqHTMvPy6hbk0U0Me0 OZ6VxuPuE+6aq4V9JSkkkklKSSUXOaxpc4w1okk+ASUySWP0P6ws6xkZlVdDqWYj2tZY50+oHCdw ECAthJSkkkklKSSUXvbWxz3kNa0S4nsAkpkksfoP1gb1p+WGY7qGYr2tY5zpNjHAlr4gRMJ3dXzn 9Wv6fi4tT24wrNltt5rJ9QT7WCl8x8UlOukmExrynSUpJJJJSklT6tn/ALN6bkZ2z1fs7C/052zH bdDo+5Lp+RnZDN+XRVSCAWejcbpnx3VVQkpuJJJJKUkkkkpSSpdX6iem9PtzBX6xqAisu2AkmPpQ 6PuUsC/OurL8umqk6bBTabgQfEuqqhJTbSWQOr513U78LFxansxi0WWW3mtx3CfaxtL5+9aw80lL pJJJKUkkq3UM6np+JZl3yWViYbySeAPMpKbKSpdPys7JaXZWMzHaQCwMt9V2vZ42N2n4Eq6kpSSS SSlJJJJKcr6qf+Jbo3/hDG/88sWqsr6qf+Jbo3/hDG/88sWqkpSSSSSlJJJJKUkkkkpSSSSSlJJJ JKUkkkkpSSSSSlLB+tX2m2nGpx8W7IczIquca2yA1h1+a3kklMKn+pW15aWbhO1wgjyKmkkkpSSS SSnC+tX2mzFqoxsa3Id6rLCa2yAGOkyr7su12yv7Ha+u2pznkwII/McCeSrySSnm8HAsHW6cnBw7 On4ddb25LX+0WOMbQGbjx4rpEkklKSSSSUpc/wDWV+fkPr6dVj3OwrhOXfS3cS3/AEY10ldAkkpB hhgxam11mljWgNrcILQNIIR0kklKSSSSUpc99ZH52TfV05mNe7AeN+XdS3cXAH+ab8e66FJJTnsv O37M3Cs+zijcJAAPb0tpPMLL6bgWDrleVh4lnT8FlLmX12e0WPJBbtYHO+j4rpEklKSSSSUpJJJJ Tg/WXHGZU7GdgX5Liw+hbU6Gh543e4ceYWn0qrKp6dj1ZZDshlbRYR4gK2kkpSSSSSlJJJJKef8A rNijNqfjnAvyLdn6vbW6GB543e4DQ/vBWqX5jMNuFnYrsotx2+u9u3a98Q5gBI1Wskkp57o+DdX1 izKx8azB6eagz0bDG6wH6QZJjRdCkkkpSSSSSlKl1fDyM7Atxca0UWWab3AuEdxAIV1JJTzn1e6Z 1XC6rnuyRUMZ4qbUa2lodsbHtlx4XRpJJKUkkkkpSodawcnqGA/Fx7RS6wjc5wLgWzq3QjlX0klP MdIxes9MzOqZF9Lbq7HVejXQ0t37W7fZucdApdewzmeoMbp1o6g8MFeYIaGx3Lw781dKkkpHjtsZ RWy07rGtAc7xIGqIkkkpSSSSSmtnit2JYyyg5VbhD6GgEuB7Q4hZPQ8K+rqeTk1UWYWA9jWsx7Dq Xjl4buO1b6SSlJJJJKUkkkkpq9RbW7Ee23Hdl1u0dS0Akj4EhYvS6M3CyM7Now7a8OxtYowSRvLx O94aXHaF0iSSnmevYbsz1GYnTrWdQft9PMEMa0iDuLw7sujpa9tTG2Hc8NAc7xIGpU0klKSSSSUp ZX1m6fd1Ho92NQ3fYS1zWTG7Y4O2zpzC1UklPPdEwr6+qW5VWNZg4Rpaw02HV1gP0g3c7jxXQpJJ KUkkkkpSSSSSnK+qn/iW6N/4Qxv/ADyxaqyvqp/4lujf+EMb/wA8sWqkpSSSSSlJJJJKUkkkkpSS SSSlJJJJKUkkkkpSSSSSlJJJJKUkkkkpSSSSSlJJJJKUkkkkpSSSSSlJJJJKUkkkkpSSSSSlJJJJ KUkkkkpSSSSSlJJJJKUkkkkpSS5v65dQy8KrD9O1+Nh23bczKqEurZGnw17pPspxPq7m5bOqXZmN s3syGOa6xgAEhrv70lPSJLB6h9Y/2Vg15L8W7Jxm0NtfkAt0BH5090S/6y0VUYbm49tmVns9SnEa P0m0CSXeEJKdpRDmuEtII8Qufy/rTQ/oXUsupj6cnCY5tlFmj2vI9v3rG643quB9XeiYfTsp9GVl WtFlrTq5z2Gwgz5pKe7USQBJMAckrAxvrM0/VT9r2fz9dZY+vv67fZt+blnfU53U86rq2B1jIfkP Dgw7j9D1GSWt+EpKexkHUJ1g/UvMtyehV13kuvw32YthPJNTiwE/JbySlJJJJKUkkkkpSSSSSlJJ JJKUkkkkpSSSSSlJJJJKUkkkkpSSSSSlJJJJKUkkkkpSSSSSlJJJJKUkkkkpSSSSSlJJJJKUkkkk pyvqp/4lujf+EMb/AM8sWqsr6qf+Jbo3/hDG/wDPLFqpKUkkkkpSSSSSlJJJJKUkkkkpSSSSSlJJ JJKUkkkkpSSSSSlJJJJKUkkkkpSSSSSlJJJJKUkkkkpSSSSSlJJJJKUkkkkpSSSSSlJJJJKUkkkk pSSSSSlJJJJKc3q+ZditYBgvzqLJFza4Jb4e13K5MdEz3dP+sV2JhvxMbPra3DwDG7e0He/aNG7p XfJJKeL61+0LLuldOvwb7ul49TL8sVAH1LWACul2o9oOpT9f6ZdmdTwOt/Zcl+KKHU241LzVfXuO 5p9rh8Ildmkkp4jJ6LQfq11h+Jh5GNdfXuP2l5e+w16jkuhW86q/qmJ9WsrErNtdd9Vtpbw1oZBJ +a6pzWvaWOEtcIIPcFAwMDG6fjNxcVpZSwktbJMSZ03E6JKeRf8AV7qf/Oc4gr/yFZaM5x7eqPzP v1Wt0HEyMTqvW8jIrNVNtwfU88FobyF0KFk49eTRZj2gmu1pY8AlpIcIOoghJTz/ANQ2OPR7sxwg Z2VfkMB/dc87fvAXSoOLjUYmPXjY7BXTS0MrYOABoAjJKUkkkkpSSSSSlJJJJKUkkkkpSSSSSlJJ JJKUkkkkpSSSSSlJJJJKUkkkkpSSSSSlJJJJKUkkkkpSSSSSlJJJJKUkkkkpSSSSSnK+qn/iW6N/ 4Qxv/PLFqr5VSSU/VSS+VUklP1UkvlVJJT9VJL5VSSU/VSS+VUklP1UkvlVJJT9VJL5VSSU/VSS+ VUklP1UkvlVJJT9VJL5VSSU/VSS+VUklP1UkvlVJJT9VJL5VSSU/VSS+VUklP1UkvlVJJT9VJL5V SSU/VSS+VUklP1UkvlVJJT9VJL5VSSU/VSS+VUklP1UkvlVJJT9VJL5VSSU/VSS+VUklP1UkvlVJ JT9VJL5VSSU/VSS+VUklP1UkvlVJJT9VJL5VSSU/VSS+VUklP1UkvlVJJT9VJL5VSSU/VSS+VUkl P1UkvlVJJT9VJL5VSSU/VSS+VUklP1UkvlVJJT9VJL5VSSU/VSS+VUklP1UkvlVJJT9VJL5VSSU/ VSS+VUklP1UkvlVJJT9VJL5VSSU/VSS+VUklP//ZCg1lbmRzdHJlYW0NZW5kb2JqDTkgMCBvYmoN PDwgL0ZpbHRlciAvRmxhdGVEZWNvZGUgL0xlbmd0aCAxMA0+Pg1zdHJlYW0KeJwr5AIAAO4AfA1l bmRzdHJlYW0NZW5kb2JqDTEwIDAgb2JqDTw8IC9MZW5ndGggNA0+Pg1zdHJlYW0Kvc/oCg1lbmRz dHJlYW0NZW5kb2JqDTExIDAgb2JqDTw8IC9IZWlnaHQgOTkgL0JpdHNQZXJDb21wb25lbnQgOCAv TGVuZ3RoIDUzNSAvV2lkdGggNzYgL0NvbG9yU3BhY2UgMzIgMCBSIC9GaWx0ZXIgL0ZsYXRlRGVj b2RlDT4+DXN0cmVhbQpIiexXO1LDQAz1nai4RSpoMhTJLeiofAqoUoaGHARo0HVw7Dir/67sdQZm rIx/sfz0nlb7A1httX9ljWLpT+YA+AIXh0V5AeUjeCGq5JFjMb/uDFc1ehJIMM7L+iKGtUC+ynnN wUIFQM7D3fIaSYGGiE8Ilsei9TBTZEVezJe00VATWu+2NJohmz9Q90b4GC87FWO+nJ5fjlW/i6h0 XI3l+QLu4IU1XStqLHNltCmvdu/9CjRCwtp6TNqYRtd9V8ALaRzcT3B/eIVnOPT38KkG0rXhfBH3 I+VVki/B62xf3bF53MBH//RzxnUTIK0VZPK8SHWMPRpSO546yPfu+g1w94QC+Rpxf8/I2HsvpVn1 peTLbsMSXmZ9KbjCHdukdkzfInt7gYdcffkyzEAhXmqRcV7a8gTRu9k4werLrtVhytq2u9Y+MlCy IdyXEgv0mcgPGUuWA6V5uZNpNKKXMsxJ3eaE5RmbJYE1umkrk+rL5KzD9GB84grxmqGRbgKFw8R1 NMUyBvMpxOMaI5vFHFZz7QaXuoth1bR87lGHRFOdiTUoQvf9E98K3NSkrArtaI2d5PUSajK8VHrJ wxheXSyKazmAKtpKlRK2bhIyqyJPY3SMrolVPx0ZB3vlHg5Ga8vLl6zOxYxOFe78qA7SaRFhz7V6 3fMet5xiJYKde00Acg2QY/IZcFCCyBg5r7baapb9DgBj5IfPDWVuZHN0cmVhbQ1lbmRvYmoNMTIg MCBvYmoNPDwgL0ZpbHRlciAvRmxhdGVEZWNvZGUgL0xlbmd0aCAzMDUNPj4Nc3RyZWFtCmjeVJHJ boMwEIbvfoo5psrBLIUQCSFVRJE4dFGT5k7sIUUqxjLkkLfvjE3T1hLm82y/PSPrZteYfgb55kZ1 wBm63miH03h1CuGMl95AnIDu1byc/K6G1oKk5MNtmnFoTDdCWQr5Ts5pdjdYPfm13ifr6AHkq9Po enOB1TH+OJHhcLX2Cwc0M0RQVaCxE7J+bu1LOyDIP9m/ruPNIiT+HC/XGDVOtlXoWnNBKJOognJL Gxr93yc2IePcqc/WiRAZRfQjzgPnxJn2nO2Yu8B74iKtuLyPKTLPcUrMYszbSpDmUj370QrSZVJQ UHoOKgVlpaySojekLPUYE2chgliUORs24TI5GwrmAoNavaiF+vxYnse9ferqHHXWD813jnvWG7zP 1Y6WW8Sf+BZgAGhklW0KDWVuZHN0cmVhbQ1lbmRvYmoNMTMgMCBvYmoNPDwgL0hlaWdodCAyNjYg L0JpdHNQZXJDb21wb25lbnQgOCAvU3VidHlwZSAvSW1hZ2UgL0xlbmd0aCAyNzYzIC9XaWR0aCA0 MjAgL1R5cGUgL1hPYmplY3QgL0ZpbHRlciAvRmxhdGVEZWNvZGUgL0NvbG9yU3BhY2UgMyAwIFIN Pj4Nc3RyZWFtCmje7JsNf5s2EMaBGUrdjrXzXuqFbGtq1rVLYpzw/T/bdJJs8AtwgLAEfp5fE9e2 gmP9fac76YnnQRAEQRAEQRAEQRAEQRA0N/2EKXBed5gCMIIalLyuxHd/XRS5/F6knhcWhXwUjFxQ sLn/QjSSjO75nySZxdPKi3cRGDlDiRgtHpcVRnGuHwYjhxiJ5EZJjnLdy9KLsyNGH+7u7v64g8zr QydGIrOFLzKWRJI7YYQ4ciPXfYu84EEyErhkrlP3wMgZRvRNVwlJjprBLclqmxKdXIhCdceL5T0w mpbACIwgMAIjaEaMqMa/pJNK/2jk+XPQAEbb7fbw/0SViGczLwp7f53qERmPETUDkHFGos3ywuxy HClGtLfx4xJxZI2R3qQNHv4uUt18Udf177coeHindgVDFWayFwseft8filRHLgmVuJH/1IikuBSf UA9GGkCwyVRIhGr3ItnRlB9yXbaHSePiXXQ2ssLoMOJkJ9FhbfV8bKtrgG1G5e+zZ0R5Sm6q7yIx +XrKNSOR816W9KgaJ547G1mNI3lnSoyuyacPo0OuI0a5Cq0zRnS0GB8xOh15xijYlIUGGA1j5K9z qhkkI12VVTJYQoxiOq9Kda7TUXI88sv+B0pG4VQAucxoL9qsVUBUsstlJXD/WT4UUmWgQ0LXDEu1 bFVHlj9QyXXPynEBRgYYjSTyXeiMOAFIjtYMI4vi6GUq/ZIxRsq7JWsseLecZLT3bnnxV5Hw4d1y M45Uu7F4fF8ygnfLDCIjfEpGSUqFE9e75eikOObMOmJkwLuVH7Yu4d1yNI5op1KXCfBuuZrrSijw bpmDZKZm2Hu3FCN4t1xkxBUYgREYOcfoJs7GHd1Tfau/1DqXe4fdJdKteUzcZHRAJHcs/PUuolv9 RzM35zFx9mxCIVK7SsEmpVtd3d+cx8RVRvtIUjt/SVaJo/l7TM4gOVkzlOuRYpTSevS6okDJZu8x mQaj4/WIkpzeSd9r1h6TicTR8XqUqJpBa/Yek8kw0jrU3iWj2XtMzhBdkU8fRqY0KY/JjTKalMfk RhlNWWA0BUhmvVux7Obh3XKRkfZuBZ8jf53Bu+VoHB3a+CSDd8txRnTL9W5BFrxbKoyk4N0yFkZG YqjCSO2jefBuucso2SOCd8s5Rtq7JbfFdhG8W2YhwRcERmAERmAERg4guiIfMAIjMAIjMILqIaFm ACMwAiMwAiMHEF2RDxiBERiB0fQZKe+WcmvBu2UWklHvlj55hXfLRUb6rFy7teDdcpmRcgLBu2VS R4yGe7cqVODdMhZGRmLoONcptxa8W44yqlQJ8G65xkh7t7RbC94tN+OIJzDqAwl7qmAERmAERmDk AKIr8gEjMAIjMAIjqB4SagYwAiMwAiMwcgDRFfmAERiB0UGL50Iou/xkDO+WfUaKUB2lxeOSzsvh 3TILqVvNEGz2c55QoDQzgnfLCqM2ieyWq5NzeLfc827p6Nq90fEF75bFOPLXWbC5lOgojHKV7zx4 twwi6p7nRGSc+320qEII1VPwbllk5H/6ZZ3rYDmPMVl0w7tlmZGY+ZflSXiwBUbjM2qpvcFoFEgd a4ayh+2DCIyuwahlLwiMnGA0SGAERrNE1IMPdbDUnoKRs4yoB0pr+iMwcoNRsEkTMJoAo/gFjK4H qXvNkFDtnfd7OTAazOitV37VihaknltBYDSYEQvRIIHRpbnvwIiJKKZch/VoOKDq/DeNPBnHwCTa IzCyyIgTSf46bXqSygl4t8ZjxEt2YUMcJXKvFd6t0RjxEDXlOt3awrvFxdS5ZvCY61HWHGIpvFsc R1Zl7jt4t6qIGrxbSV7PqPScwLs1Thyxkl1jrvsW7d1a8G6Nwmj4ekRRo6sEeLdaJ746/00jT8YN 3WkIJT14t0Zk1I4ofv0VPWzz1Os5HYkRI4rAyC6j8bdU586o2znPWP1ReLK5A0bXZtQeSWBkmREj 2YXapYr1yA4jznoERtz5bB/I5Nm5P0Kus80I65HzjOBncJ4R+qPhhJjzfsyTzZ17fgRG5hk1T3sP fx0YmWbUMu3w17kQR83R0cNfB0acee9WMzQiOuE+GJO/Ft3tDXu3+jFqnPYe/rpmxV8fljPzbvXL X4wEdhjfUjIcvf5wRIvH9yWjmXi3ejNqjo4tt+8x3R8lKZlM5uXdqq7ZLUPr1pgW79ZFQ1add6sc 2+DdalCYH4xAM/JuVeaodWQ5vv0Tb6c/kn8+psqEGXm3+jFqT0zW+qM9lBl5t/oyaptOa/0RMZqX d6tvzdCawCrjr9ofteiGGLUnsHL8dfsjMHK+PwIj9/ujOTKqrtlvW6az0znPxf6o+fVv7vyoxxlb awIrx7vaH90Ao5ZPfHW8s/3RzBm1feKr453tjybCaNvP8/HWY68d6I8sMWqdIvRHDjBirx0e+iPD jEz1J+iPRuLE70/QH1ljxO5PPPRHlhjx+xP0R/ZyHbc/mUN/FMuDI4veLa53atuvP5lBfxR8jvx1 ZtO71Y+Ruf5kGv1Rktn0bnH7k+1I/ckk+iOCYs27VdefXHJZ1awdF4bWrTFDXv/O5Ot/6B5GamWy 4d0avT+ZRX9E+U3Kindr9P7Em0F/lOSV/12/Zhi9P5lBf7R4lq4ta96t0fsTnB/VvJWjz2YrJV5/ crv9kUuMjOV4nB91ZWSoP7np/mhkRqbOb3B+ZJRRXX9ycWRlPPojO4w8y/2J7dd39vzIof4E50cM Rpb7E/RHNW+lSy5Gf2SdkWeqP0F/NCIj9Efoj670+uiP0B+ZYtQ9x6M/uvZ61D3Hoz8yhojp3bqU Yx3vT+bTHzG8Wwb6k5bPHPojDqMm75bt/uTm+yNr3q0b1c89OQ32bt2NMNL6UOu/6pEGe7fAaHRG g71bYDQqo3rv1kf+RT6OMNL6UOu/KgRBEARBEARBEARBEARBEDS6khNfSr1itZ1ueKjnr09252vH KSsNd2zOGkmHBAXvF6B3xZ4sgwo291+YLxt8jvx1xhv6l8cdKt751wceo0/8+UmyLpMQ8nAuHpfS JGKB0pcOHw3+e2dfdvH43jgjmk2+/HXKvqr7jNhjY3ZW8pI0eGDnOmZSkgmM+wuQr8DjXtYKok6M OqQQf817OyLPMBlJ9rzppFkPmTzZYSTe/u4Nn7wlRp0CnfnpTOgjz16JmRddfIv45NkwadnqlkWv zyhhIwqzLqM7xBHzovSeYm4GYyeHuEt0GpQsaJkfzmf2ULoqu/bmMgoL/kVD9tLVITK6FP8QBEEQ BEEQBEEQBEEQBEEQBEEQBEHX0uK54WQ61r6GxXM64CpQXwUbMpcUf7IYPa0kiCKtsReB0VhKXpa8 OFI2GMFoF4GRDUbfyUi4ePqtyMgZIqhQhIln4qL4/roiX0e2B/G9SIlRKOJJ4KOfKbKEfkRfRV9A XQwyx2gX0XyLG7nsiMd+iASmTISGv35dxaWdZ/F8v3l5V2EkfiYpsmCTq6sUqb6AvBhkkBGFTyqT Vaz+ZEFaonLKc+IrLN1RgkBY/FNllNGNv95F9F/xpS+AzDciI7X8iBsRG5oRmdjyAyMRWf81MVIX AKPxGIVqFRHpLSxycUfmupQY7BlR3UCZTT51xEhmTH0BMBqPkUx2u0jUDBQtiSjMn1Z0Z3WII7KD 555+qspIlg/7C4ARBEEQBEEQBEEQBEEQBEHH+l+AAQCscX+KCg1lbmRzdHJlYW0NZW5kb2JqDTE0 IDAgb2JqDTw8IC9GaWx0ZXIgL0ZsYXRlRGVjb2RlIC9MZW5ndGggODANPj4Nc3RyZWFtCnicUwjk KuQqVLAwUABBIyAyN1AwMVBIzlXQj8g0U3DJVwjkcgrhAnIMzRQsFELSuAzBSg0VjA2AKk0VQnK5 NIxMLDRDsrhcQ7gCuQDFLREEDWVuZHN0cmVhbQ1lbmRvYmoNMTUgMCBvYmoNWyAvSW5kZXhlZCAx MjQgMCBSIDAgMTAgMCBSDV0NZW5kb2JqDTE2IDAgb2JqDTw8IC9Dcm9wQm94DVsgMCAwIDYxMiA3 OTINXSAvQmxlZWRCb3gNWyAwIDAgNjEyIDc5Mg1dIC9NZWRpYUJveA1bIDAgMCA2MTIgNzkyDV0g L1JvdGF0ZSAwIC9UcmltQm94DVsgMCAwIDYxMiA3OTINXSAvVGh1bWIgMTIwIDAgUiAvUmVzb3Vy Y2VzDTw8IC9Gb250DTw8IC9GMSA2NyAwIFIgL0YyIDcyIDAgUiAvRjMgNTIgMCBSIC9GNCA1NyAw IFIgL0Y1IDYyIDAgUiAvWGkxNyAxMTcgMCBSDT4+IC9Qcm9jU2V0DVsgL1BERiAvVGV4dCAvSW1h Z2VCIC9JbWFnZUMgL0ltYWdlSQ1dIC9FeHRHU3RhdGUNPDwgL0dTMSA0MiAwIFINPj4gL1hPYmpl Y3QNPDwgL1hpNyAxMjMgMCBSDT4+DT4+IC9BcnRCb3gNWyAwIDAgNjEyIDc5Mg1dIC9QYXJlbnQg MzcgMCBSIC9Db250ZW50cw1bIDc5IDAgUiAxMTQgMCBSIDc0IDAgUg1dIC9UeXBlIC9QYWdlDT4+ DWVuZG9iag0xNyAwIG9iag08PCAvVHlwZSAvRW5jb2RpbmcgL0RpZmZlcmVuY2VzDVsgMiAvZzI5 OSAzMiAvc3BhY2UgMzggL2FtcGVyc2FuZCA0MCAvcGFyZW5sZWZ0IC9wYXJlbnJpZ2h0IC9hc3Rl cmlzayAvcGx1cyAvY29tbWEgL2h5cGhlbiAvcGVyaW9kIC9zbGFzaCAvemVybyAvb25lIC90d28g L3RocmVlIC9mb3VyIC9maXZlIC9zaXggL3NldmVuIC9laWdodCAvbmluZSAvY29sb24gL3NlbWlj b2xvbiA2MSAvZXF1YWwgL2dyZWF0ZXIgNjUgL0EgL0IgL0MgL0QgL0UgL0YgL0cgL0ggL0kgL0og L0sgL0wgL00gL04gL08gL1AgL1EgL1IgL1MgL1QgL1UgL1YgL1cgL1ggL1kgL1ogL2JyYWNrZXRs ZWZ0IDkzIC9icmFja2V0cmlnaHQgOTUgL3VuZGVyc2NvcmUgOTcgL2EgL2IgL2MgL2QgL2UgL2Yg L2cgL2ggL2kgL2ogL2sgL2wgL20gL24gL28gL3AgL3EgL3IgL3MgL3QgL3UgL3YgL3cgL3ggL3kg L3ogL2JyYWNlbGVmdCAvYmFyIC9icmFjZXJpZ2h0IDEzMSAvZWxsaXBzaXMgMTMzIC9lbmRhc2gg MTQxIC9xdW90ZWRibGxlZnQgL3F1b3RlZGJscmlnaHQgMTQ0IC9xdW90ZXJpZ2h0DV0NPj4NZW5k b2JqDTE4IDAgb2JqDTw8IC9IZWlnaHQgNTI5IC9CaXRzUGVyQ29tcG9uZW50IDggL1N1YnR5cGUg L0ltYWdlIC9MZW5ndGggNTM5MzIgL0ludGVudCAvUmVsYXRpdmVDb2xvcmltZXRyaWMgL1dpZHRo IDkxMyAvVHlwZSAvWE9iamVjdCAvRmlsdGVyIC9EQ1REZWNvZGUgL0NvbG9yU3BhY2UgMTI0IDAg Ug0+Pg1zdHJlYW0K/9j/7gAOQWRvYmUAZIAAAAAB/9sAhAAMCAgICQgMCQkMEQsKCxEVDwwMDxUY ExMVExMYFxIUFBQUEhcXGxweHBsXJCQnJyQkNTMzMzU7Ozs7Ozs7Ozs7AQ0LCw0ODRAODhAUDg8O FBQQEREQFB0UFBUUFB0lGhcXFxcaJSAjHh4eIyAoKCUlKCgyMjAyMjs7Ozs7Ozs7Ozv/wAARCAIR A5EDASIAAhEBAxEB/8QBPwAAAQUBAQEBAQEAAAAAAAAAAwABAgQFBgcICQoLAQABBQEBAQEBAQAA AAAAAAABAAIDBAUGBwgJCgsQAAEEAQMCBAIFBwYIBQMMMwEAAhEDBCESMQVBUWETInGBMgYUkaGx QiMkFVLBYjM0coLRQwclklPw4fFjczUWorKDJkSTVGRFwqN0NhfSVeJl8rOEw9N14/NGJ5SkhbSV xNTk9KW1xdXl9VZmdoaWprbG1ub2N0dXZ3eHl6e3x9fn9xEAAgIBAgQEAwQFBgcHBgU1AQACEQMh MRIEQVFhcSITBTKBkRShsUIjwVLR8DMkYuFygpJDUxVjczTxJQYWorKDByY1wtJEk1SjF2RFVTZ0 ZeLys4TD03Xj80aUpIW0lcTU5PSltcXV5fVWZnaGlqa2xtbm9ic3R1dnd4eXp7fH/9oADAMBAAIR AxEAPwD1VJJJJSkkkklKSSSSUpJJJJSkkkklKSSSSUpJJJJSkkkklKSSSSUpJJJJSkkkklKSSSSU pJJJJSkkkklKSSSSUpJJJJSkkkklKSSSSUpJJJJSkkkklKSSSSUpJJJJSkkkklKSSSSUpJJJJSkk kklKSSSSUpJJJJSkkkklKSSSSUpJJJJSkkkklKSSSSUpJJJJSkkkklKSSSSUpJJJJSkkkklKSSSS UpJJJJSkkkklKSSSSUpJJJJSkkkklKSSSSUpJJJJSkkkklKSSSSUpJJJJSkkkklKSSSSUpJJJJSk kkklKSSSSUpJJJJSkkkklKSSSSUpJJJJSkkkklKSSSSUpJJJJSkkkklNfPszasV78CluRlaCuux/ pskmJc+HQBzoFg09b+sWB1rB6b12jFfT1Te3GycI2RXaxvqGuxt2p0Bhwj4BdI97K2Oe9waxoLnO cYAA1JJK5jpzH/WXrtH1hc1zOldNa9nSQ6Wm6ywbLckt/c26MnzKSnU6rZ9ZjeKejVYjKw3c/KzH PcN2vsbTTBPGpLhz3Qfq71+7qWLmftGgYeZ0y9+PmMa7dXLAH72O52lpnVWeudaq6Ritf6bsjLyH elhYler7rSJDR4AcuPACxm/V/J6f9TOs02kZHVep0ZeRmOYTtdkX1OGyvd+a3RrUlMWdf+tuV0x3 X8HDxD03Y66nBsdZ9qupbJa8Wt9jHPb7g3Yfiuk6dnUdRwMfPxyTTlVttrnQ7XjcJWX9W7aW/Unp tjo9NnTaS/sPbS3d+RL6iscz6n9IDxBOMw/Jw3D8Ckp3UklXtZnF5NN1TGdmvqc8/wCcLWfkSU2E lQpf1S2y9nrUD0LBXPovMyxlk/z+n04RfT6p/wByKP8Ath//AKXSU2klV9Pqn/cij/th/wD6XS9P qn/cij/th/8A6XSU2klV9Pqn/cij/th//pdL0+qf9yKP+2H/APpdJTaSVX0+qf8Acij/ALYf/wCl 0vT6p/3Io/7Yf/6XSU2klV9Pqn/cij/th/8A6XS9Pqn/AHIo/wC2H/8ApdJTaSVX0+qf9yKP+2H/ APpdL0+qf9yKP+2H/wDpdJTaSVX0+qf9yKP+2H/+l0vT6p/3Io/7Yf8A+l0lNpJVfT6p/wByKP8A th//AKXS9Pqn/cij/th//pdJTaSVX0+qf9yKP+2H/wDpdL0+qf8Acij/ALYf/wCl0lNpJVfT6p/3 Io/7Yf8A+l0vT6p/3Io/7Yf/AOl0lNpJVfT6p/3Io/7Yf/6XS9Pqn/cij/th/wD6XSU2klV9Pqn/ AHIo/wC2H/8ApdL0+qf9yKP+2H/+l0lNpJVfT6p/3Io/7Yf/AOl0vT6p/wByKP8Ath//AKXSU2kl V9Pqn/cij/th/wD6XS9Pqn/cij/th/8A6XSU2klV9Pqn/cij/th//pdL0+qf9yKP+2H/APpdJTaS VX0+qf8Acij/ALYf/wCl0vT6p/3Io/7Yf/6XSU2klV9Pqn/cij/th/8A6XS9Pqn/AHIo/wC2H/8A pdJTaSVX0+qf9yKP+2H/APpdL0+qf9yKP+2H/wDpdJTaSVX0+qf9yKP+2H/+l0vT6p/3Io/7Yf8A +l0lNpJVfT6p/wByKP8Ath//AKXS9Pqn/cij/th//pdJTaSVX0+qf9yKP+2H/wDpdL0+qf8Acij/ ALYf/wCl0lNpJVfT6p/3Io/7Yf8A+l0vT6p/3Io/7Yf/AOl0lNpJVfT6p/3Io/7Yf/6XS9Pqn/ci j/th/wD6XSU2klV9Pqn/AHIo/wC2H/8ApdL0+qf9yKP+2H/+l0lNpJVfT6p/3Io/7Yf/AOl0vT6p /wByKP8Ath//AKXSU2klV9Pqn/cij/th/wD6XS9Pqn/cij/th/8A6XSU2klV9Pqn/cij/th//pdL 0+qf9yKP+2H/APpdJTaSVX0+qf8Acij/ALYf/wCl0vT6p/3Io/7Yf/6XSU2klV9Pqn/cij/th/8A 6XS9Pqn/AHIo/wC2H/8ApdJTaSVX0+qf9yKP+2H/APpdL0+qf9yKP+2H/wDpdJTaSVX0+qf9yKP+ 2H/+l0vT6p/3Io/7Yf8A+l0lNpJVfT6p/wByKP8Ath//AKXS9Pqn/cij/th//pdJTaSVX0+qf9yK P+2H/wDpdL0+qf8Acij/ALYf/wCl0lNpJVfT6p/3Io/7Yf8A+l0vT6p/3Io/7Yf/AOl0lNpJVfT6 p/3Io/7Yf/6XS9Pqn/cij/th/wD6XSU2klV9Pqn/AHIo/wC2H/8ApdL0+qf9yKP+2H/+l0lNpJVf T6p/3Io/7Yf/AOl0vT6p/wByKP8Ath//AKXSU2klV9Pqn/cij/th/wD6XS9Pqn/cij/th/8A6XSU 2klV9Pqn/cij/th//pdL0+qf9yKP+2H/APpdJTaSVX0+qf8Acij/ALYf/wCl0vT6p/3Io/7Yf/6X SU2klV9Pqn/cij/th/8A6XS9Pqn/AHIo/wC2H/8ApdJTaSVX0+qf9yKP+2H/APpdL0+qf9yKP+2H /wDpdJTaSVX0+qf9yKP+2H/+l0vT6p/3Io/7Yf8A+l0lNpJVfT6p/wByKP8Ath//AKXS9Pqn/cij /th//pdJTaSVX0+qf9yKP+2H/wDpdL0+qf8Acij/ALYf/wCl0lNpJVfT6p/3Io/7Yf8A+l0vT6p/ 3Io/7Yf/AOl0lNpJVfT6p/3Io/7Yf/6XS9Pqn/cij/th/wD6XSU2klV9Pqn/AHIo/wC2H/8ApdWW 7to3EF0akCBPkJKSl0kkklKSSSSUpJJJJSkkkklKSSSSUpJJJJTn9e6Lj9d6Xd0vJtupov2+o+hw Y+GkO2y5rhBjXRUsb6sX49tTx1vqdjKXNIpe+j03BpnY4Nx2naeNCt1JJThdT+qdPUOrt6w3qGbh 5TKfs7Psz6w0MJ3OgW1WQXHmFd6X0mzp/q+r1DL6gLYEZbq3BkT9D06q+Z1laCSSnnP+ZGCGOxGZ mYzpL3FzulNsaMeDqawdnqhhP5u+PlouhrrZVW2utoYxgDWNAgADQABSSSUpJJJJTVw/6Rnf8e3/ AM8Uq0quH/SM7/j2/wDnilWklKSSSSUpJJJJSkkkklKSSSSUpJJJJSklm9R+sHTenXDGudZbklof 9nxqrMiwMJI3uZS15a3Tkq1hZuNn47cnGcXVuke5rmOBGha5jw1zSPAhJTYSSSSUpJU7epUVdUxu mOa43ZVVtzHCNobSa2uDtZk+oI0Ts6phnFdl2POPQ2w1F+QDV7t/pD+cj6T9G+PZJTbSSWTX9Zul W5f2Wo32A2Gn7SzHudj+oDsLPtAZ6ch2n0uUlOskkqdnUqK+q09LLXetfRZkNeI2BtTq2OB1mZsH ZJTcSSSSUpJVep59XTenZPULmufViVPue1kFxbW0uIbJAnRWK3iyttjdA8BwnmCJSUySVTqvUael 9Nyeo3tc+rErda9rILiGiSGyQFP7ZV9qrxdtm+2t1rXBjiwNaQDueBtB93EpKbCSSSSlJJJJKUkk kkpSSSSSlJJJJKUkkkkpSSSSSlJJJJKUkkkkpSSSSSlJJJJKUkkkkpSSSSSlJJJJKUkkkkpSSSSS lJJJJKUkkkkpSSSSSlJJJJKUkkkkpSSSSSlJJJJKUkkkkpSSSSSlJJJJKUkkkkpSSSSSlJJJJKUk kkkpSSSSSlJJJJKUkkkkpSSSSSlJJJJKUkkkkpSSSSSlJJJJKUkkkkpSSSSSmvn4VefivxbX2V12 RvdS81vgGS0Pb7hPBhcjd0nB6B9b+iUdCFmMc4XjqGM1z312U11yLrd7ne7fHu5K6T6w9cxegdIv 6rlhz6qAIYwSXOcdrW+Uk8rnPq11z6ufbHZ2d1fGy+vdTLKnCsnbW0n9Hi0Aj6ILufzjqkpsW0Y3 1l+t3Uum9Ra+3p/RKcdv2QuIpsuygbvUsa0+/a1oDZ4MoeFkD6s9Q69g1F9nTcHCZ1PEx3OL/SAb Y2yqsvdoyava3spOysP6ufXLqmb1Oz7NhdcpxnU5VmlQuxmvqdUX8NdthwnlNj4v/OTN69n0bm9P zsBvTMPIILfVEWmy1gcPoTZDT3SUh6d9VMLqn1Zp6vlOtf13NxvtbepCx4uqsub6rBU5rvYxu6A0 aQui+q/UbuqfV7p3UL4N2RjsfaQIBfEOMeZXPdJ+tnTsH6r4/S7nOb1zCxm4Z6XtP2k31sFbWtr7 h0A7uI1XQ/Vjp13S/q907p98etj47GWgagPiXCfIpKdRJJV7cKm15e91oJ7MutYP81jwElMcP+kZ 3/Ht/wDPFKtLMxen0OvzAXXe24ARfcP8DUdYs157qz+zcf8Afv8A/Yi//wBKJKbSSFRjV0bthsO6 J9Sx9nHh6jnR8kVJSkkkklOB1rq/XsTM9HAwDfSGg+r6b7JJ/wCLIiFQ/wCcX1t/8rP/AAC7/wAk uuSUscsQADjifFjMJEk8ZDwvUvrL191D8XLx24gubG707K3x3273fJFxPrT9ZLag3HxG5IrAa6xt VjySBy4sdElb3U/qzhdTyjk5F1wdtDQ1jmhoA8JYSidJ6Bi9JssfjW2uFoAc2wtLdOD7WN1Upy4e D5Bxb1WjH7eXi+Y136uJ/wA4vrb/AOVn/gF3/kle6N1jr+XminPwDTSQSbfTsr2kCR/OEzK6BJRS yxII9uI8WQY5Ag8ZLzX1PNr876yXZLQ3KPVbKye5prqpGPPP5mqsfWO7ObndGxcPIdijNyrKr3sA JLBj3PPOk+3Q9ijZv1bx8jOf1DFysnpuZcGtyLcRzQLQ3RvqV2ssYXAaB23d2mEQdBxQ/CsdbfZZ gXPya32Wb3PssY+p3qF4OkWGA2I+GiiZHJzLLa+q0/VxludbjY+F9puspsJybDbY+qsOyN7XgM2O 41OmqFfm9epw/sD334/23qdeHhZtoYb241jPWe50bm7mlr62kjwmVu9S6LVnX1Zld92FnUMdXVlY 5bvFby1z2Oba17HAlo5b8FG7oVOT077Dm5F+UfUZc3Je5rbW21lrmPYa2Ma3a5oMBsJKclvT3YH1 x6XWMm/IpODmbG5D/Vc0h+Nu/SO97t2n0iVmdVfkdR+pFt+TkWmyvqXpgh0S1vUm0sDvHa0CF02J 9XqqM+jqV+XkZmbj120i64s9zLSxxBZXWxo2+nptA5Mykfq3089Gv6M91jsbIssuc7cBY19lxydz HNAgseZb8ElOhi4/2altXqWXbZ99rtzzJnU6Lmzb1H6n0sZYK8z6vi8MFs7MjGbkWbWhzSNtrGvf EyDHiuiw8azGxm0W5FuW9s7r7tge6TOvpMrbpwICzP8AmtS91deVn5mZh0vZZVhX2NdWHVuD2bni sWv2uaDD3nzlJSJpv6x13qeJZk3Y+N0s49ddeO81F1ljBkOse9urhDmtDTpoZBlVs7Cvs+tXSsU5 doczpuSLshu1ttgbZig6taA0uPJaB5QtXN6BXkZ56hj5eRgZNjG1ZD8csi2usuLGvbbXYNNxgiCi 19Gxq83FzQ+11uHjPxK9798sea3Fz3Pl7nfohruSU867rGd0fpXXqhdZlO6ZlVY2Fdf+lsAyWY+z eSW+p6brvzjJHJV3GZ1PH6nhOxRn20Wvc3qP21zXM2Gs7bWS87HB7WiGaanRaTvq/wBOsb1Ou8Ou q6w7dl1uOn80yiGbQ0j2sHeZSwOkX4lwss6nl5dbNK6bjVsAiNTXUx7o/lOKSnlc2rM6p9SOpdeu zsll2Zi5Noxtw9BlIFgbj+iRtnbo530p7xot6vLyW/WLpmG2wjGs6bda+rsXsfjNa75B5Su+p+Fb j5WF9qyq+nZgt34LHsFTX3lzn2MJrL/pOLg0u2z2VvP6FVlnGtqyLsPKw2munKoLN+x+0PY4WMew h20ctSU8/wBcy8m/o31zpusL68YGuhp4Y04lNhA/tOJWw7LyW/Wfp+G2wjGs6fkWvq7F7LMdrXfI PKkfqt084XU8I23mvrH9KeXhzwfSZSXMc5p1IZOs6+Wiuu6Xju6nR1Iuf62NRZjMbI2Flrq3uJET M1jukp5R1nVLfqr1Drjuo5Dcvp785+KGODawMa64NZYyIsBDdp3duIOq0+p53q9VxsfNyLsXBfh/ aP1Vz2uN29v846pu5oA+gN0O9wIMLQH1ewh0XK6Lvt+zZn2j1Hy31B9qc+yzadsaGwxosrqnSnO6 4Lb6cwYbcNlFGT0+19Vhe173OZkehYx7oBBZpt1ckp0fqqM79j12Z7rn32PsLTkSLDUHubS57D9B zqw1xbA17DhbCy+gM6k3Gu+3eoGuvecRl5a65tEANFrmOcCSQSO8ETqtRJSkkkklKSQLsSq9we91 gIEey2ysfdW9oUP2bj/v3/8AsRf/AOlElNpJVf2bj/v3/wDsRf8A+lEv2bj/AL9//sRf/wClElNp JVf2bj/v3/8AsRf/AOlEv2bj/v3/APsRf/6USU2klV/ZuP8Av3/+xF//AKUS/ZuP+/f/AOxF/wD6 USU2klV/ZuP+/f8A+xF//pRL9m4/79//ALEX/wDpRJTaSVX9m4/79/8A7EX/APpRL9m4/wC/f/7E X/8ApRJTaSVX9m4/79//ALEX/wDpRL9m4/79/wD7EX/+lElNpJVf2bj/AL9//sRf/wClEv2bj/v3 /wDsRf8A+lElNpJVf2bj/v3/APsRf/6US/ZuP+/f/wCxF/8A6USU2klV/ZuP+/f/AOxF/wD6US/Z uP8Av3/+xF//AKUSU2klV/ZuP+/f/wCxF/8A6US/ZuP+/f8A+xF//pRJTaSVX9m4/wC/f/7EX/8A pRL9m4/79/8A7EX/APpRJTaSVX9m4/79/wD7EX/+lEv2bj/v3/8AsRf/AOlElNpJVf2bj/v3/wDs Rf8A+lEv2bj/AL9//sRf/wClElNpJVf2bj/v3/8AsRf/AOlEv2bj/v3/APsRf/6USU2klV/ZuP8A v3/+xF//AKUS/ZuP+/f/AOxF/wD6USU2klV/ZuP+/f8A+xF//pRL9m4/79//ALEX/wDpRJTaSVX9 m4/79/8A7EX/APpRL9m4/wC/f/7EX/8ApRJTaSVX9m4/79//ALEX/wDpRL9m4/79/wD7EX/+lElN pJVf2bj/AL9//sRf/wClEv2bj/v3/wDsRf8A+lElNpJVf2bj/v3/APsRf/6US/ZuP+/f/wCxF/8A 6USU2klV/ZuP+/f/AOxF/wD6US/ZuP8Av3/+xF//AKUSU2klV/ZuP+/f/wCxF/8A6US/ZuP+/f8A +xF//pRJTaSVX9m4/wC/f/7EX/8ApRL9m4/79/8A7EX/APpRJTaSVX9m4/79/wD7EX/+lEv2bj/v 3/8AsRf/AOlElNpJVf2bj/v3/wDsRf8A+lEv2bj/AL9//sRf/wClElNpJVf2bj/v3/8AsRf/AOlE v2bj/v3/APsRf/6USU2klV/ZuP8Av3/+xF//AKUS/ZuP+/f/AOxF/wD6USU2klV/ZuP+/f8A+xF/ /pRL9m4/79//ALEX/wDpRJTxX1o6n1GnruTVTlXVVs9PaxljmtE1sJ0aR3KX1X6n1G7ruNVdlXW1 v9Tcx9jnNMVvI0cT3Cr/AFsxPs/W7WscXttaxzQXOe4e0MhxfJmW+PCt/V/6v9Tq6vRZlY9lVDd+ 94cWESxwHuYQRqoRDIZXRq7+luocuAcuIkx4zjrbXi4XvElV/ZuP+/f/AOxF/wD6UVlrQ1oaJgCB JJOniTqpnLXSSSSUpJJJJSkkkklKSSSSUpJJJJSkkkklKSSVLA6z0rqV+Tj4GVXk24Za3JbWd2wu 3QCRp+aUlNwgEQRI8CnVDqfXOl9KLG51+yy2TXSxr7bXAEAltVTXvIE6mFPpnVundWoOR0+9uRW1 2x+2Q5jgJLHscA5rhPDhKSm3tbO6BPE906xb/rl9WMfKdi257Gvrd6dlm15pY8aFll4aamO8nOWy CCJGoKSl0kkklNXD/pGd/wAe3/zxSrSq4f8ASM7/AI9v/nilWklKSSSSUpJJJJSkkkklKSSSSUpJ JJJSkkkklKSSSSUpJJJJSkkkklKSSSSUpJJJJSkkkklKSSSSUpJJJJSkkkklKSSSSUpJJJJSkkkk lKSSSSUpJJJJSkkkklKSSSSUpJJJJSkkkklKSSSSUpJJJJSkkkklKSSSSUpJJJJSkkkklKSSSSUp JJJJSkkkklKSSSSUpJJJJSkkkklKSSSSUpJJJJSkkkklKSSSSUpJJJJSkkkklKSSSSUpJJJJSlGy xlVbrLDtYwFznHsAJJUli/WjMbTg/Z/9NLrB/wAFWNzx/aMM+aRXQjxSA+3y6vNdOa/rX1pbdaJa H+vYD2az6LT8Pa0rv1yv1FxHejk9Qs1fc7Y0nwHucfmSPuXVJ0xVR7BEpcUiemw8h+zspJJJNQpJ JJJSkkkklKSSSSUpJJJJSkkkklKSSSSUiysanLx342Q3fTYIe2SJHhp4rlfqtj0Y311+tePj1tpp qHTW11MAa1rRjugNaNAupy7b6cay3HoOVcwSyhrmsLz4B1hDR8yuR6K36zY31o6t1PI6HbXj9Zdh tB+0YxNLaKzU9zw20k8z7UlJuuZFvRfrZT1amr9onOxRiWdPpG7MaK7C8XUt4cyXw+YjmVX6XmR0 n6z/AFqx3trzcqp9xwpM4zsXHLamXNO0iwxuf+U8q/fi9Z6X9Zs3rGNhO6ri9Qooq2V2VstodTuG 1rbixpY7du+lM9lPp/RcrNz+rdR6njNw6uq49eJ9j3Ne/wBNjXhz7iyWbnepEAnTukpf6vdOxLfq HhYb62mrL6ex1wI0c6+v1LHO8y5xMqx9Sb7Mj6pdJttcXPONWC4mSdo26k/BZWE3624PRWfV2vpo svoq+yUdU9WsY3phuxlzmbvVkN/N28941XSdH6bX0rpWJ02pxezEpZUHnQu2iC75nVJTcVe3Npqe WPbaSO7KbXj/ADmMIVhJJTmYvUKG35hLbvdcCIouP+BqGsV6cd1Z/aWP+5f/AOw9/wD6TSw/6Rnf 8e3/AM8Uq0kpFRk137tgsG2J9St9fPh6jWz8kVJJJSkkkklKSVfIz8HGcG5ORVQ4iQ2x7WEj+0Qh /tno/wD3Oxv+3Wf+SQsd1whI6iJP0biS4/q/1zy8bqFtGCMe/GZt2W+58y1rj7mWAaEwjdB+t92b lvq6k7HxqRWXNsk1y4OaNs2PI4JTfcjdMx5PMIcdaVxeP2PVJKn+2ej/APc7G/7dZ/5JEx8/ByXF mNk1XOAktre1xA+DSU6x3YTCQ1MSPo2ElzNFfV+qdY6wxnV8nCqwciumimlmO5oDsem0k+tQ9x9z z3QrfrB1JnRvrJj3WVt6t0Kuwi+oCHNfT6+Pd6btwaSDBGokfJFa9WkuVsv6x0fJ6O93ULup1dUy GYt+PeygOaH1vs9Wt1NdMbNnumdPNdJmWXVYl9uPX6t1dbnVVfvPAJa35lJSZJc59WH359NHUx1q 3Nc9n65huZS2tlhHurDG1ttrLHdnOPmr+R9YcSnIupqpyMsYp25dmPX6jaTs9Ta6DucdpGjA46pK dRJc0/rFmJ9aupUFmRlj7HiPow6BvM7sne5oe5rGzAkkjstOv6wdMs6U3qoscMZzvTAc1ws9Xf6P pemRu37/AG7Y5SU6SSzsPreNk5D8S2q3CyWVm70cloaXVB2w2Nc1zmkAxOsiRMSsHrf1pry+l02Y LMvHrvzMRuLmFjq67mHIq37HtO4Nc2fpgbhxISU9ekqtXUMa3qF/Tmk/aMauu2wEabbS8Mg/9bKx uudXbk9KpyMC2ysN6rjYtjgSwksy2U2t0OrTBHmkp6NJZteZSOr51Rvte/Hx6bX4xDfTY1xth7DG 4udsMyeyrU/W7plzcS5leR9jzjW2nNNZFAst2+nW507gSXRMbZ0mUlO2kszP69j4d1tLcfIyn47B bk/Z694qY4OLS6XN3E7Posl3kreBm1Z+HVmUgim9ofWXRq06tcNpIgjUJKbCSSSSlJJJJKUkkkkp Bdl1UODHtsJIn2VWWD762OCh+0sf9y//ANh7/wD0mrSSSmr+0sf9y/8A9h7/AP0ml+0sf9y//wBh 7/8A0mrSSSmr+0sf9y//ANh7/wD0ml+0sf8Acv8A/Ye//wBJq0kkpq/tLH/cv/8AYe//ANJpftLH /cv/APYe/wD9Jq0kkpq/tLH/AHL/AP2Hv/8ASaX7Sx/3L/8A2Hv/APSatJJKav7Sx/3L/wD2Hv8A /SaX7Sx/3L//AGHv/wDSatJJKav7Sx/3L/8A2Hv/APSaX7Sx/wBy/wD9h7//AEmrSSSmr+0sf9y/ /wBh7/8A0ml+0sf9y/8A9h7/AP0mrSSSmr+0sf8Acv8A/Ye//wBJpftLH/cv/wDYe/8A9Jq0kkpq /tLH/cv/APYe/wD9JpftLH/cv/8AYe//ANJq0kkpq/tLH/cv/wDYe/8A9JpftLH/AHL/AP2Hv/8A SatJJKav7Sx/3L//AGHv/wDSaX7Sx/3L/wD2Hv8A/SatJJKav7Sx/wBy/wD9h7//AEml+0sf9y// ANh7/wD0mrSSSmr+0sf9y/8A9h7/AP0ml+0sf9y//wBh7/8A0mrSSSmr+0sf9y//ANh7/wD0ml+0 sf8Acv8A/Ye//wBJq0kkpq/tLH/cv/8AYe//ANJpftLH/cv/APYe/wD9Jq0kkpq/tLH/AHL/AP2H v/8ASaX7Sx/3L/8A2Hv/APSatJJKav7Sx/3L/wD2Hv8A/SaX7Sx/3L//AGHv/wDSatJJKav7Sx/3 L/8A2Hv/APSaX7Sx/wBy/wD9h7//AEmrSSSmr+0sf9y//wBh7/8A0ml+0sf9y/8A9h7/AP0mrSSS mr+0sf8Acv8A/Ye//wBJpftLH/cv/wDYe/8A9Jq0kkpq/tLH/cv/APYe/wD9JpftLH/cv/8AYe// ANJq0kkpq/tLH/cv/wDYe/8A9JpftLH/AHL/AP2Hv/8ASatJJKav7Sx/3L//AGHv/wDSaX7Sx/3L /wD2Hv8A/SatJJKav7Sx/wBy/wD9h7//AEml+0sf9y//ANh7/wD0mrSSSmr+0sf9y/8A9h7/AP0m l+0sf9y//wBh7/8A0mrSSSmr+0sf9y//ANh7/wD0ml+0sf8Acv8A/Ye//wBJq0kkpq/tLH/cv/8A Ye//ANJpftLH/cv/APYe/wD9Jq0kkpq/tLH/AHL/AP2Hv/8ASa436y9TblvsNe6LnCqqWub+hqMu PuA+nb/1K7DquTZjYTzT/SLSKccf8JYdrfu5XG4NFfUfrJTRX78XDhrD410fnf236/NOxxEpgH5Y jjl5BffBilMfNL0Q8y9R0i3HwOm4+LsvDq2Df+r3fTPud/g/Eq5+0sf9y/8A9h7/AP0mrSSBJJJP XVjAoADo1f2lj/uX/wDsPf8A+k1Za4OaHCYIkSCDr4g6p0kEqSSSSUpJJJJSkkkklKSSSSUpJJJJ SkkkklKSQsrI+zY77/TfdsEiuobnuPADQsP6ufWHqPVOr9X6dn4bMJ/TPsxbW1/qOjJY62LHD27g AJ26eZ5SU9CksfqvWcyvqNHR+lUV5GfdWb7X3OLaqKAdnqP2AucXO0a0RMHUQrHT39Zqqtd1p2KR W0Obdi+o0Ee4v3V27tu0Aa7jPkkp0ElyTOv/AFtyumO6/g4eIem7HXU4NjrPtV1LZLXi1vsY57fc G7D8V0nTs6jqOBj5+OSacqtttc6Ha8bhKSmykkkkpq4f9Izv+Pb/AOeKVaVXD/pGd/x7f/PFKtJK UkkkkpSSSSSnNyuh4+Rl2ZYttqstDRZs9NwOwQ3S2t8fJD/5v1/9y7v83H/9ILWSQ4QyDLMAC9tN nzvr3ReoM6te3Hx8jJq9m24VE7vY2damNbodNArH1Y6Jmv6hYMqrIxKxS6LDWGy7cz2/pq3NXeJJ ntC7tsHnpnHwcI24bcn/AJv1/wDcu7/Nx/8A0gp43QsejLqyzdbbbSHCsO9NoG8bXfzVbJ08VppJ /CGv706IvfTYPLYfUT0vrvW2X4WbZ9ryqrMd9OLdZW9v2aiv+dazYPc0jUoGT0jOf0P60dStxXV9 Q63S/Zht/SWiurH9Cis+nuBedTDZ1MarsEkWNyekfV7pfT205FVDvtLa4Ft9ll1jNwG9rHXveWAx qBCmOl14F1/U6X5uVdtsf9lOTZYxxPu2V1XWek09m8QtNJJTyF7Kup/WDpuf0jAyMTMovP7SzLcd +MDjem8Pqe6wM9UuftiN0cqx07Lv6Hf1LCycPKyLMjMvy8OzHqdY25l59UN9QeyssJ2fpHN4nhdO kkpxcKi9v1s6nkOqe2mzDw212lpDXOa7JLmh3BLdwmFhu6V1N3RWPZTeH4fW8jMsx2TXbZQci9pN c7Z9tnqN/ejTldskkp5duFgdZryji/tBuU7DyMWrJy2X1CsXhrXBv2hrJMgHQdlUzcrMzfq9h9Mr 6blV5mLb08ZdRpeGV+lfSX7LNu2wDb+ZOmphdmkkp52+2zpf1oys27Hvux+oYuPTS/HqfdFtL7i5 j/TB2SLBBdp5rMZg9RP1dbW/FtZeeui91O0lwr/aHql+g1bt927iNeF2qSSnAbjZP/OPrN3pP9K3 AxWVWbTtc5pytzWu4JG4SPNZ78HN/wCYXR8QY9v2mr9mepRsd6jfTuodZuZEjaASfBdekkp47Lsz v2/1dmDVlmu70Ksi7Abj2Bp9L6Vn2h7HNuAd2DvZt0ldF0J/TndIxWdMn7HQwUVNdO5op/RFjt2u 5pbBlQf0LFOVflU234tmWQckU2lrXuaAwOLTIDtoAlsFW8PDx8HFrxMVmymoQxpJcfEkucSSSdST qUlJ0kkklKSSSSUpJJJJSkkkklKSSSSUpJJJJSkkkklKSSSSUpJJJJSkkkklKSSSSUpJJJJSkkkk lKSSSSUpJJJJSkkkklKSSSSUpJJJJSkkkklKSSSSUpJJJJSkkkklKSSSSUpJJJJSkkkklKSSSSUp JJJJSkkkklKSSSSUpJJJJSkkkLJyK8bHsyLTFdTS9x8miUlAWaDz/wBZc8sssLDphs2sj/uRe0if +t1bnfNB+omFtpyM5w1eRVWfJvud+JCyOuXWGttdn865xsuH/DW7bHj/AK2zYz712vRsL7D0zHxi IcxgL/67vc78SpIDhwmXXKaH92Kc5/WRxjbFGz/el/K26kkko0KSSSSUpJJJJSkkkklKSSSSUpJJ JJSkkkklKSSSSUpcp9Xf/F39bv8A2m/+27l0uXjuycayht1mObBAupIFjfNpc1wn4hYOD9Sa8LqV vU6ur9SdkZLqnZW+yki70RtY2yMcabdNISU07cHKzfr11GmvPu6ePsOK6ccV+o9gfcPpXV2QA7wC DkO6syv6z/V23Ks6mxnTDdh22tYLgb6rq/Se6sMa6SyQdq6Hq31ex+pZVOezIvwc/Ga6uvLxnBr/ AE3GXVva9r2ObOsFvKn0joOF0r7Q+o2ZGVmOD8vLyHb7rS0bW73QBDRoGgADsElNT6t20t+pPTbH R6bOm0l/Ye2lu78iX1FY5n1P6QHiCcZh+ThuH4FB/wCZGCGOxGZmYzpL3FzulNsaMeDqawdnqhhP 5u+PlouhrrZVW2utoYxgDWNAgADQABJTJV7WZxeTTdUxnZr6nPP+cLWfkVhJJTmYtfUfXzNt9IIu G4mlxk+jVx+mEaKz6fVP+5FH/bD/AP0ulh/0jO/49v8A54pVpJSKhuU3d9osrs42+mwsjxndY+UV JJJSkkkklKSSSSUpJJJJSkkkklKSSSSUpJJJJSkkkklKSSSSUpJJJJSkkkklKSSSSUpJJJJSkkkk lKSSSSUpJJJJSC5mY5wNFtdbI1D63PM/FtrPyKHp9U/7kUf9sP8A/S6tJJKavp9U/wC5FH/bD/8A 0ul6fVP+5FH/AGw//wBLq0kkpq+n1T/uRR/2w/8A9Lpen1T/ALkUf9sP/wDS6tJJKavp9U/7kUf9 sP8A/S6Xp9U/7kUf9sP/APS6tJJKavp9U/7kUf8AbD//AEul6fVP+5FH/bD/AP0urSSSmr6fVP8A uRR/2w//ANLpen1T/uRR/wBsP/8AS6tJJKavp9U/7kUf9sP/APS6Xp9U/wC5FH/bD/8A0urSSSmr 6fVP+5FH/bD/AP0ul6fVP+5FH/bD/wD0urSSSmr6fVP+5FH/AGw//wBLpen1T/uRR/2w/wD9Lq0k kpq+n1T/ALkUf9sP/wDS6Xp9U/7kUf8AbD//AEurSSSmr6fVP+5FH/bD/wD0ul6fVP8AuRR/2w// ANLq0kkpq+n1T/uRR/2w/wD9Lpen1T/uRR/2w/8A9Lq0kkpq+n1T/uRR/wBsP/8AS6Xp9U/7kUf9 sP8A/S6tJJKavp9U/wC5FH/bD/8A0ul6fVP+5FH/AGw//wBLq0kkpq+n1T/uRR/2w/8A9Lpen1T/ ALkUf9sP/wDS6tJJKavp9U/7kUf9sP8A/S6Xp9U/7kUf9sP/APS6tJJKavp9U/7kUf8AbD//AEul 6fVP+5FH/bD/AP0urSSSmr6fVP8AuRR/2w//ANLpen1T/uRR/wBsP/8AS6tJJKavp9U/7kUf9sP/ APS6Xp9U/wC5FH/bD/8A0urSSSmr6fVP+5FH/bD/AP0ul6fVP+5FH/bD/wD0urSSSmr6fVP+5FH/ AGw//wBLpen1T/uRR/2w/wD9Lq0kkpq+n1T/ALkUf9sP/wDS6Xp9U/7kUf8AbD//AEurSSSmr6fV P+5FH/bD/wD0ul6fVP8AuRR/2w//ANLq0kkpq+n1T/uRR/2w/wD9Lpen1T/uRR/2w/8A9Lq0kkpq +n1T/uRR/wBsP/8AS6Xp9U/7kUf9sP8A/S6tJJKavp9U/wC5FH/bD/8A0ul6fVP+5FH/AGw//wBL q0kkpq+n1T/uRR/2w/8A9Lpen1T/ALkUf9sP/wDS6tJJKavp9U/7kUf9sP8A/S6yeu3ZrGsxrbqn sDTkXNbU4eykgtaf0xne/a2F0C5W7JbkZNua/wB1InJI8aMUltDf+uXS75ISs1Eby0ZcIFmcvlgL cqjEyc76wVYj3tdZQTZc8tJbvk22bm7tfednIXa+n1T/ALkUf9sP/wDS65/6kYzn/aupW6vtd6bX Hv8AnvPzJC6pT56BEBtjAj9erWxky4sh3yEyavp9U/7kUf8AbD//AEul6fVP+5FH/bD/AP0urSSh ZGr6fVP+5FH/AGw//wBLqy3dtG4gujUgQJ8hJTpJKUkkkkpSSSSSlJJJJKUkkkkpSS5vqvVPrlZm 3YfQulVCqqAOo51u2pztJDKa/edO/wDqaTXf41qnb3s6PkMBl1TTc0kdw1xgD5pKexSWb0LqPU8/ Fe7qnTn9Lyq3bXUue21rhyHMsZoQtJJSkkLKrvtx3149voWuENt2h23zDToSuT+p9D8T62/WjCOR dkto+wEWZDy95c+l73uPYS48AAeGiSnsUli/WPLyXijovT3+nn9TJb6o5px2x9ov+IadrP5RCzPq zljpX1X6tkuL7q+mZPUHMD3F7zXjvftbueZPtbGpSU9akuJ6d9VMLqn1Zp6vlOtf13NxvtbepCx4 uqsub6rBU5rvYxu6A0aQui+q/UbuqfV7p3UL4N2RjsfaQIBfEOMeZSU6iSSSSmrh/wBIzv8Aj2/+ eKVaVXD/AKRnf8e3/wA8Uq0kpSSSSSlJJJJKUkkkkpSSSSSlJJJJKUkkkkpSSSSSlJJJJKUkkkkp SSSSSlJJJJKUkkkkpSSSSSlJJJJKUkkkkpSSSSSlJJJJKUkkkkpSSSSSlJJJJKUkkkkpSSSSSlJJ JJKUkkkkpSSSSSlJJJJKUkkkkpSSSSSlJJJJKUkkkkpSSSSSlJJJJKUkkkkpSSSSSlJJJJKUkkkk pSSSSSlJJJJKUkkkkpSSSSSlJJJJKUkkkkpSSSSSnz/q31l62zOzMVmTtpbbbU1oYzRoc5sbts8e azP2rnOptx3PBruZWxw2tHtpj0wNoGgWl1ToGZZ1jKDH1k25IDdXc5BfY1p9vLWjc7yQuldHs/5x V4FpZZ6D5ucwkthnuI1A7+1M5cT94SIJjA8R8AHR5qWAcrKA4IzyRAjQ1JL3HRcL7D0vHxiIe1gN n9d3ud+JV5JJSEkkk9TbmgUAB0UkkkglSSSSSlJJJJKUkkkkpSSSSSlJJJJKcn61VdSu6Bls6Xv+ 1wwtFTtljmNe11rK3dnOrDgPNcbn0/WHrbM/6zNZ1Hp78b0aeg9N97Hue1zd9l9ImQ5xgk6beeJX QZf1Y6/i5N2b9X+tW1Oue+52DnD18YudJ2tP062z+7KD/wA7frF0k7PrJ0Sw1CGnqHTT9opM8udU YsY0eaSnrWztG7mNY8U6o9H630vreGM3pd4yMfdsLgCC1wAcWua4Agw4K8kpDl5eNhY1mXl2CnHp G6yx3DR4lcN9XPrP9Xz9d/rFaM6os6k7p9eE6dLXNpNbgz4OMLv0klPOXdE+sVfW8zquBnYg+1tr ra3Ix7LHV1VDStrmXsEb3Odx3WT9VundXz+idcwcrIoONl39Rxi2qpzLBdZY9j7A91jhs1MN2/Nd ykkp4rpP1s6dg/VfH6Xc5zeuYWM3DPS9p+0m+tgra1tfcOgHdxGq6H6sdOu6X9XundPvj1sfHYy0 DUB8S4T5Fae1s7oE8T3TpKUq9uBg3PNl2NVY88vexrjp5kKwkkpzMXpvTnX5gdi0kMuAaDW3QejU 6Bp4lWf2V0v/ALh0f9tM/uSw/wCkZ3/Ht/8APFKtJKav7K6X/wBw6P8Atpn9yX7K6X/3Do/7aZ/c rSSSmr+yul/9w6P+2mf3Jfsrpf8A3Do/7aZ/crSSSmr+yul/9w6P+2mf3Jfsrpf/AHDo/wC2mf3K 0kkpq/srpf8A3Do/7aZ/cl+yul/9w6P+2mf3K0kkpq/srpf/AHDo/wC2mf3Jfsrpf/cOj/tpn9yt JJKav7K6X/3Do/7aZ/cl+yul/wDcOj/tpn9ytJJKav7K6X/3Do/7aZ/cl+yul/8AcOj/ALaZ/crS SSmr+yul/wDcOj/tpn9yX7K6X/3Do/7aZ/crSSSmr+yul/8AcOj/ALaZ/cl+yul/9w6P+2mf3K0k kpq/srpf/cOj/tpn9yX7K6X/ANw6P+2mf3K0kkpq/srpf/cOj/tpn9yX7K6X/wBw6P8Atpn9ytJJ Kav7K6X/ANw6P+2mf3Jfsrpf/cOj/tpn9ytJJKav7K6X/wBw6P8Atpn9yX7K6X/3Do/7aZ/crSSS mr+yul/9w6P+2mf3Jfsrpf8A3Do/7aZ/crSSSmr+yul/9w6P+2mf3Jfsrpf/AHDo/wC2mf3K0kkp q/srpf8A3Do/7aZ/cl+yul/9w6P+2mf3K0kkpq/srpf/AHDo/wC2mf3Jfsrpf/cOj/tpn9ytJJKa v7K6X/3Do/7aZ/cl+yul/wDcOj/tpn9ytJJKav7K6X/3Do/7aZ/cl+yul/8AcOj/ALaZ/crSSSmr +yul/wDcOj/tpn9yX7K6X/3Do/7aZ/crSSSmr+yul/8AcOj/ALaZ/cl+yul/9w6P+2mf3K0kkpq/ srpf/cOj/tpn9yX7K6X/ANw6P+2mf3K0kkpq/srpf/cOj/tpn9yX7K6X/wBw6P8Atpn9ytJJKav7 K6X/ANw6P+2mf3Jfsrpf/cOj/tpn9ytJJKav7K6X/wBw6P8Atpn9yX7K6X/3Do/7aZ/crSSSmr+y ul/9w6P+2mf3Jfsrpf8A3Do/7aZ/crSSSmr+yul/9w6P+2mf3Jfsrpf/AHDo/wC2mf3K0kkpq/sr pf8A3Do/7aZ/cl+yul/9w6P+2mf3K0kkpq/srpf/AHDo/wC2mf3Jfsrpf/cOj/tpn9ytJJKav7K6 X/3Do/7aZ/cl+yul/wDcOj/tpn9ytJJKav7K6X/3Do/7aZ/cl+yul/8AcOj/ALaZ/crSSSmr+yul /wDcOj/tpn9yX7K6X/3Do/7aZ/crSSSmr+yul/8AcOj/ALaZ/cl+yul/9w6P+2mf3K0kkpq/srpf /cOj/tpn9yX7K6X/ANw6P+2mf3K0kkpq/srpf/cOj/tpn9yX7K6X/wBw6P8Atpn9ytJJKav7K6X/ ANw6P+2mf3Jfsrpf/cOj/tpn9ytJJKav7K6X/wBw6P8Atpn9yX7K6X/3Do/7aZ/crSSSmr+yul/9 w6P+2mf3Jfsrpf8A3Do/7aZ/crSSSmr+yul/9w6P+2mf3Jfsrpf/AHDo/wC2mf3K0kkpq/srpf8A 3Do/7aZ/cl+yul/9w6P+2mf3K0kkpq/srpf/AHDo/wC2mf3Jfsrpf/cOj/tpn9ytJJKav7K6X/3D o/7aZ/cl+yul/wDcOj/tpn9ytJJKav7K6X/3Do/7aZ/cov6b0mtjnvxKA1gLnE1s0A1PZXFm9dsB xG4m7acx4pcfCvV9zvlW0oE0F0I8UgO/5OHh0YINmfkY9Qqx6X5VjCxsb8gzTXEfm1tGniVH6m9M oyWZOblUstDnenW17QWg/ScQCPMKn1rPjAZjs9r855y72+FZ0or+TGgrb+peZVb0w4gAbZjOO4eI eS4O/grEIGHLGX+cIv8AusefIJ8zw9MYIA8err/srpf/AHDo/wC2mf3Jfsrpf/cOj/tpn9ytJKBc 1f2V0v8A7h0f9tM/uS/ZXS/+4dH/AG0z+5WkklNX9ldL/wC4dH/bTP7lZa1rWhrQGtaIAGgAHYJ0 klKSSSSUpJJJJSkkkklKSSSSU8J9euqfXHB6vR+zcizB6MaAbsyvFblBt0vn1Bte9o2gagIHSD9d Orsbd03644eWzRzmNxqtwB1h7PTa9vzhbH1q+vdHQc5nS6McZPULahe0XX1YtAYXFnuuvcBPtOi5 GzpHTOudTb1Xrf1g6P0q1hJZX0i6plpmINmQ5wJcIjgpKfVa6aat/pVtr9R29+0AbnEAbnRyYCmk kkphbbVTW6257a62Aue9xAaAO5JWZ0X6z9J65kZmP0577Dg+n6r3MLGuFwc6tzC6C5pDZn7lp21V XVmu5jbK3RLHCQYM6grl/q7p9evrcB/5rf8A23ckp1uq/WCjp14xm4mXn5Jb6hpw6TYQ3XVz3FrG /RMS6SjdF630/reIcvAeXMY91Vtb2llldjfpMsY7Vrgj52didPxLc3MsbTj0NLrLHGAAFyeBT1HC +qX1i63c04uX1NuX1Gmkth9LTSfRDx+/DQXeaSnRt+vPSmNsyGY2Zd02hzmXdTqoLsZpYS1+s+o5 rSPpNYR5roa7GW1tsrcHseA5jhqCCJBCw/q5RS76kdOpcB6VnTag8Hj30gvn7yl9RXOf9T+kF2p+ zMHyAgfgElO8kkq9uTdW8tZi22gfnsNQB/z7Gn8ElMcP+kZ3/Ht/88Uq0szFyrxfmEYdzt1wJANO n6GoQZt+eis/bMj/ALg3/wCdR/6WSU2klV+2ZH/cG/8AzqP/AEsl9syP+4N/+dR/6WSU2klV+2ZH /cG//Oo/9LJfbMj/ALg3/wCdR/6WSU2klV+2ZH/cG/8AzqP/AEsl9syP+4N/+dR/6WSU2klV+2ZH /cG//Oo/9LJfbMj/ALg3/wCdR/6WSU2klV+2ZH/cG/8AzqP/AEsl9syP+4N/+dR/6WSU2klV+2ZH /cG//Oo/9LJfbMj/ALg3/wCdR/6WSU2klV+2ZH/cG/8AzqP/AEsl9syP+4N/+dR/6WSU2klV+2ZH /cG//Oo/9LJfbMj/ALg3/wCdR/6WSU2klV+2ZH/cG/8AzqP/AEsl9syP+4N/+dR/6WSU2klV+2ZH /cG//Oo/9LJfbMj/ALg3/wCdR/6WSU2klV+2ZH/cG/8AzqP/AEsl9syP+4N/+dR/6WSU2klV+2ZH /cG//Oo/9LJfbMj/ALg3/wCdR/6WSU2klV+2ZH/cG/8AzqP/AEsl9syP+4N/+dR/6WSU2klV+2ZH /cG//Oo/9LJfbMj/ALg3/wCdR/6WSU2klV+2ZH/cG/8AzqP/AEsl9syP+4N/+dR/6WSU2klV+2ZH /cG//Oo/9LJfbMj/ALg3/wCdR/6WSU2klV+2ZH/cG/8AzqP/AEsl9syP+4N/+dR/6WSU2klV+2ZH /cG//Oo/9LJfbMj/ALg3/wCdR/6WSU2klV+2ZH/cG/8AzqP/AEsl9syP+4N/+dR/6WSU2klV+2ZH /cG//Oo/9LJfbMj/ALg3/wCdR/6WSU2klV+2ZH/cG/8AzqP/AEsl9syP+4N/+dR/6WSU2klV+2ZH /cG//Oo/9LJfbMj/ALg3/wCdR/6WSU2klV+2ZH/cG/8AzqP/AEsl9syP+4N/+dR/6WSU2klV+2ZH /cG//Oo/9LJfbMj/ALg3/wCdR/6WSU2klV+2ZH/cG/8AzqP/AEsl9syP+4N/+dR/6WSU2klV+2ZH /cG//Oo/9LJfbMj/ALg3/wCdR/6WSU2klV+2ZH/cG/8AzqP/AEsl9syP+4N/+dR/6WSU2klV+2ZH /cG//Oo/9LJfbMj/ALg3/wCdR/6WSU2klV+2ZH/cG/8AzqP/AEsl9syP+4N/+dR/6WSU2klV+2ZH /cG//Oo/9LJfbMj/ALg3/wCdR/6WSU2klV+2ZH/cG/8AzqP/AEsl9syP+4N/+dR/6WSU2klV+2ZH /cG//Oo/9LJfbMj/ALg3/wCdR/6WSU2klV+2ZH/cG/8AzqP/AEsl9syP+4N/+dR/6WSU2klV+2ZH /cG//Oo/9LJfbMj/ALg3/wCdR/6WSU2klV+2ZH/cG/8AzqP/AEsl9syP+4N/+dR/6WSU2klV+2ZH /cG//Oo/9LJfbMj/ALg3/wCdR/6WSU2klV+2ZH/cG/8AzqP/AEsl9syP+4N/+dR/6WSU2klV+2ZH /cG//Oo/9LJfbMj/ALg3/wCdR/6WSU2klV+2ZH/cG/8AzqP/AEsl9syP+4N/+dR/6WSU2klV+2ZH /cG//Oo/9LJfbMj/ALg3/wCdR/6WSU2klV+2ZH/cG/8AzqP/AEsl9syP+4N/+dR/6WSU2klV+2ZH /cG//Oo/9LJfbMj/ALg3/wCdR/6WSU2lz3WHOzOoHGYeA3DYR2fkfpL3f2aW/itS3qFtVb7bMK9r K2lz3F1OgAkn+eXLW9Qux6rcuyp7Lgx5DiWQMjM94Ojp9lIAGnxhDhMpRgP0iy4iIRnlP6A/H+Wi 1GNR1v6027WD7HR9IDhzawGN/wA4/gusxOldPwrDZi0Nqe4bS5vMTMfgsP6pY92FgG/7JbY/KIcH tNQGwfR+na0+J4W79syP+4N/+dR/6WU+eZ4uCJPDAcP2NXFHTiI9Ujxfa2klV+2ZH/cG/wDzqP8A 0sl9syP+4N/+dR/6WULK2klV+2ZH/cG//Oo/9LJfbMj/ALg3/wCdR/6WSU2klV+2ZH/cG/8AzqP/ AEsrLSS0EgtJElpiR5GJCSl0kkklKSSSSUpJJJJSkkkklPGfWPrP1Gr6pZX9aOnmu+mKqsvJxXWV 2MjePSsY18gbj81Tyeof4nMave9nT3gmAKqDY6fhWwq99bep/XPpjc3Mpr6Seh47Wua7L9Y2kQ0E Oa1waSXmGgeSxcnM+vPR8NnVsjpPQcKq59fr3elY11RtLWNfeWWdiQ0kTHwSU9z0PrlPW6LMnHx8 iihj9lb8ms1eqIDt9bXalusStJJJJSHLOWMaw4Ta3ZMfom3Fzay7+U5gcQPgFy3Sej/XHD+sPUer XM6aWdWdjfaWMuvJrZjs9I+nNA3EtM6rr0klPMfWLo/1j6h1nFyMZuFk9MxGiyvDy7La5yZ0teK6 rA7YPog99VqYDOt5FWRT12nEZVY3YwYlllm4ODg8P9WuuNIiFppJKeTx+i/W7E6YPq/j34n2BjPs 9PUnF/2llEbQPQ2bDY0aA747x2XSdPwaOnYGPgYwIoxa201zqdrBtE+eisJJKUkkkkpq4f8ASM7/ AI9v/nilWlVw/wCkZ3/Ht/8APFKtJKUkkkkpSSSSSlJJJJKUkkkkpSSSSSlJJJJKUkkkkpSSSSSl JJJJKUkkkkpSSSSSlJJJJKUkkkkpSSSSSlJJJJKUkkkkpSSSSSlJJJJKUkkkkpSSSSSlJJJJKUkk kkpSSSSSlJJJJKUkkkkpSSSSSlJJJJKUkkkkpSSSSSlJJJJKUkkkkpSSSSSlJJJJKUkkkkpSSSSS lJJJJKUkkkkpSSSSSlJJJJKUkkkkpSSSSSlJJJJKczr1jfs1eI4wMp+20+FLB6tx/wA1sfNcnler 1POxentkOveci8D8113v/wDA6g0LX+sGUx+ReXn9HU0Yoj+UPXyY/wCtta35oX1MxX5GRldXvEue 4sYe0u9zyPwCkwaGeU/oDhj/AHinmNMePD1yHjl/d/t/Y9XXWyqttVY2sYA1oHYAQApJJKNCkkkk lKSSSSUpJJJJSkkkklKSSSSUpJJJJSkkkklNDrvTMHqvSMrp/UDsxL6yLXyG7NvuD5doNpAOq4ej oVPV8R1Wf9cT1P6v41ldd1IayvcQ5vpV2ZG8kyY17nzXYfWzpuV1T6v5mFiQb7AxzWOMB/pvbY6p xkaWBpYfiuD39Vz29b6Jg/VzKwR1h9FdfqVCrHxq6qqqLHF2jTBYS3bykp9SAAAA4HCdM0Q0AmYE SnSUiyrL6sd78er17gP0dW4N3HzceAue+rHV+uZfXuu9M6u6lzunfZDU3HaQxv2it9rmhzvc6NBJ +4cLplyn1d/8Xf1u/wDab/7buSU2M7P6r1Lr93Q+k5bMCvApZbn5QrbbcH3Emqqttksb7Wlzi4HQ iPFLpPWs3EyuqdM67cy5/SqmZTc5rRV6mM9rjusYDtD2ljt0QEHorDj/AF9+sjLSA7NpwMigTqWV 1vpcY8nBVOpY9nU+t/WirEh7h0ZuESOPXsbkPawkd4cJSUkx7vrj1Doo+sWNn1UPtqdk4nSvQa6k 1QX1sttP6Xe5sSWuAnsuk6P1KvqvSsTqVbSxmXUy0MOpbuElvyWV9Xs/Fr+omBmPe0UY/Tq/UcSN o9KoNeD82o31Jotx/ql0mq1pa8Y1ZLToRuG4T96SnbSSVe3GuseXMyragfzGCogf59bj+KSmOH/S M7/j2/8AnilWlmYuLeb8wDMubtuAJAp1/Q1GTNXy0Vn7Hkf9zr/82j/0ikptJKr9jyP+51/+bR/6 RS+x5H/c6/8AzaP/AEikptJKr9jyP+51/wDm0f8ApFL7Hkf9zr/82j/0ikptJKr9jyP+51/+bR/6 RS+x5H/c6/8AzaP/AEikptJKr9jyP+51/wDm0f8ApFL7Hkf9zr/82j/0ikptJKr9jyP+51/+bR/6 RS+x5H/c6/8AzaP/AEikptJKr9jyP+51/wDm0f8ApFL7Hkf9zr/82j/0ikptJKr9jyP+51/+bR/6 RS+x5H/c6/8AzaP/AEikptJKr9jyP+51/wDm0f8ApFL7Hkf9zr/82j/0ikptJKr9jyP+51/+bR/6 RS+x5H/c6/8AzaP/AEikptJKr9jyP+51/wDm0f8ApFL7Hkf9zr/82j/0ikptJKr9jyP+51/+bR/6 RS+x5H/c6/8AzaP/AEikptJKr9jyP+51/wDm0f8ApFL7Hkf9zr/82j/0ikptJKr9jyP+51/+bR/6 RS+x5H/c6/8AzaP/AEikptJKr9jyP+51/wDm0f8ApFL7Hkf9zr/82j/0ikptJKr9jyP+51/+bR/6 RS+x5H/c6/8AzaP/AEikptJKr9jyP+51/wDm0f8ApFL7Hkf9zr/82j/0ikptJKr9jyP+51/+bR/6 RS+x5H/c6/8AzaP/AEikptJKr9jyP+51/wDm0f8ApFL7Hkf9zr/82j/0ikptJKr9jyP+51/+bR/6 RS+x5H/c6/8AzaP/AEikptJKr9jyP+51/wDm0f8ApFL7Hkf9zr/82j/0ikptJKr9jyP+51/+bR/6 RS+x5H/c6/8AzaP/AEikptJKr9jyP+51/wDm0f8ApFL7Hkf9zr/82j/0ikptJKr9jyP+51/+bR/6 RS+x5H/c6/8AzaP/AEikptJKr9jyP+51/wDm0f8ApFL7Hkf9zr/82j/0ikptJKr9jyP+51/+bR/6 RS+x5H/c6/8AzaP/AEikptJKr9jyP+51/wDm0f8ApFL7Hkf9zr/82j/0ikptJKr9jyP+51/+bR/6 RS+x5H/c6/8AzaP/AEikptJKr9jyP+51/wDm0f8ApFL7Hkf9zr/82j/0ikptJKr9jyP+51/+bR/6 RS+x5H/c6/8AzaP/AEikptJKr9jyP+51/wDm0f8ApFL7Hkf9zr/82j/0ikptJKr9jyP+51/+bR/6 RS+x5H/c6/8AzaP/AEikptJKr9jyP+51/wDm0f8ApFL7Hkf9zr/82j/0ikptJKr9jyP+51/+bR/6 RS+x5H/c6/8AzaP/AEikptJKr9jyP+51/wDm0f8ApFL7Hkf9zr/82j/0ikptJKr9jyP+51/+bR/6 RS+x5H/c6/8AzaP/AEikptJKr9jyP+51/wDm0f8ApFL7Hkf9zr/82j/0ikptJKr9jyP+51/+bR/6 RS+x5H/c6/8AzaP/AEikptJKr9jyP+51/wDm0f8ApFL7Hkf9zr/82j/0ikptJKr9jyP+51/+bR/6 RS+x5H/c6/8AzaP/AEikptJKr9jyP+51/wDm0f8ApFL7Hkf9zr/82j/0ikptJKr9jyP+51/+bR/6 RS+x5H/c6/8AzaP/AEikptIeRezHosvsMMqaXuPk0SUH7Hkf9zr/APNo/wDSKzOuVvZVVjW5lz67 3F14Ip0ppHq2H21DwA+aBNBdCPFID7fLq8v1i657qsTU3uG+5o1/S5BFz2/KWNHwXddKwW9P6fRi N5rb7yO7jq4/euM+rmHd1frD8u2xzfSJudaNpO9xlv0mlvOvHZdp9jyP+51/+bR/6RU0/Rjhj8OO Xmf4BZKXHlnPpfBHyG9eZbSSq/Y8j/udf/m0f+kUvseR/wBzr/8ANo/9IqJLaSVX7Hkf9zr/APNo /wDSKX2PI/7nX/5tH/pFJTaSVX7Hkf8Ac6//ADaP/SKX2PI/7nX/AObR/wCkUlNpJVfseR/3Ov8A 82j/ANIqy0ENAJLiBBcYk+ZiAkpdJJJJSkkkklKSSSSUpJJJJTk/WvqeV0roGXnYkevUGBr3Auaz e9lbrXATIrDt5+C5J3W+qdK6P9YW2dZ+3ZmBZjfYslwr/SOsqpuNbK2yC17nFsDWO67H6x9Uwekd Ey+odQr9XFpZFlUbt+8itrIOnuc4BecY9GF0LKr691T6l/YMAWMc7KGUcj0N7hsf9ncSNHEdhHZJ T6w0ktBIgkahOmBBAI4PCdJSHLxKM3GsxcgF1No2vDXOYY8n1lrh8isbG+o31ZxMsZmPj2syA5jz Z9qySXOr+hv3XEOjwct9JJTndV6B0rqz6rM2pxuon0r6rH02tB5aLKXMdB8JhG6b0vA6XjDFwKRT VJcQCS5zjy97nEuc49yTKJmZ+DgVevnZFWLTMepc9tbZP8p5AU8fJx8qlt+Nay+l4lllbg9rge4c 2QUlOQ76m/Vx2S7IOIffZ6z6PUs+zmznecff6Uzr9HnXlbXGgVWzq3SqsxuBZmUMzH6sxnWsFp54 rLtx48FbSUpJJJJTVw/6Rnf8e3/zxSrSq4f9Izv+Pb/54pVpJSkkkklKSSSSUpJJJJSkkkklKSSS SUpJJJJSkkkklKSSSSUpJJJJSkkkklKSSSSUpJJJJSkkkklKSSSSUpJJJJSkkkklKSSSSUpJJJJS kkkklKSSSSUpJJJJSkkkklKSSSSUpJJJJSkkkklKSSSSUpJJJJSkkkklKSSSSUpJJJJSkkkklKSS SSUpJJJJSkkkklKSSSSUpJJJJSkkkklKSSSSUpJJJJSkkkklKSSSSUpcd9as73ZJaeduFV8BF2Q7 /qGrq8vIZi4tuTZ9Cljnn+yJhcL9ns6n1rG6c6SKdck/8I8+tkH4ydnyRhESnEH5fml5BkieCE8g 3rhj/eP8g9N9U+n/AGLpLHuEW5P6V/jB+gPu1W0mAAAAEAaABOjORlIyPUsUY8IAHRSSSSalSSSS SlJJJJKUkkkkpSSSSSlJJJJKUkkkkpSSSSSnN+sOA/qnSMrpdT6W3ZdewC8FzNpI3EtY5ruOCDod Vw2f0P60Z5b9Xs/63YNzyWEYD6qfUf6RFjA5m3c/6MwZnutj6w3dY6L9Z39bw+k29Xbl4LcOh1AL n02se+zbYACRW/cCT5LDyvqTkYn1NOZZim/635mTVkjJa0vtrvsva86skNDWTu7Skp7n6u4f1hxM e1nXuoM6lc54NVjKm1bWxq0hjWg6rWTNnaN3Ma/FOkpSSSSSnj/rDdj9I+tVHWesUjI6VdjNxKLY 9Q49/qFx/QauPqggbmAnTVC6Hc3C6X9Y/rT09ja+nZbXZnT8NpaGj7PQd1hayQx1zmyRyO+qs5Vm R0v63ZXVOo4mRmYV2PTX07Ix6XZH2ct3evWWV7ntL3Q7dtg8JumdJPUcvrtzcWzA6T1fHZQym1pq dZY5j2XX+joWS1wGsEwkpj0b6s9IzvqPTXk41dt3UsQZWRkOaDa6/IZ6ptLzruDnaeC1/qhmX531 X6Zl5Di+63GYbHnlzgNpcfjCxOndX6lgfV+roLul5b+s4tAw62tqccd5Yz02W/ao9P041Os9oldH 0Dph6T0TB6a5we7EoZW9w4LgPcR80lOgq9ufg0vNd2TVW8cse9rTr5EqwkkpzMXqXTm35hdlUgPu BaTY3UejU2Rr4hWf2r0v/uZR/wBus/vSw/6Rnf8AHt/88Uq0kpq/tXpf/cyj/t1n96X7V6X/ANzK P+3Wf3q0kkpq/tXpf/cyj/t1n96X7V6X/wBzKP8At1n96tJJKav7V6X/ANzKP+3Wf3pftXpf/cyj /t1n96tJJKav7V6X/wBzKP8At1n96X7V6X/3Mo/7dZ/erSSSmr+1el/9zKP+3Wf3pftXpf8A3Mo/ 7dZ/erSSSmr+1el/9zKP+3Wf3pftXpf/AHMo/wC3Wf3q0kkpq/tXpf8A3Mo/7dZ/el+1el/9zKP+ 3Wf3q0kkpq/tXpf/AHMo/wC3Wf3pftXpf/cyj/t1n96tJJKav7V6X/3Mo/7dZ/el+1el/wDcyj/t 1n96tJJKav7V6X/3Mo/7dZ/el+1el/8Acyj/ALdZ/erSSSmr+1el/wDcyj/t1n96X7V6X/3Mo/7d Z/erSSSmr+1el/8Acyj/ALdZ/el+1el/9zKP+3Wf3q0kkpq/tXpf/cyj/t1n96X7V6X/ANzKP+3W f3q0kkpq/tXpf/cyj/t1n96X7V6X/wBzKP8At1n96tJJKav7V6X/ANzKP+3Wf3pftXpf/cyj/t1n 96tJJKav7V6X/wBzKP8At1n96X7V6X/3Mo/7dZ/erSSSmr+1el/9zKP+3Wf3pftXpf8A3Mo/7dZ/ ei35ONjM9TJtZSwmA6xwaJ8JdCB+2ekHQZ2P/wBus/8AJIWFwjI6gE+QZftXpf8A3Mo/7dZ/el+1 el/9zKP+3Wf3q0kitav7V6X/ANzKP+3Wf3pftXpf/cyj/t1n96tJJKav7V6X/wBzKP8At1n96X7V 6X/3Mo/7dZ/erSSSmr+1el/9zKP+3Wf3pftXpf8A3Mo/7dZ/erSSSmr+1el/9zKP+3Wf3pftXpf/ AHMo/wC3Wf3q0kkpq/tXpf8A3Mo/7dZ/el+1el/9zKP+3Wf3q0kkpq/tXpf/AHMo/wC3Wf3pftXp f/cyj/t1n96tJJKav7V6X/3Mo/7dZ/el+1el/wDcyj/t1n96tJJKav7V6X/3Mo/7dZ/el+1el/8A cyj/ALdZ/erSSSmr+1el/wDcyj/t1n96X7V6X/3Mo/7dZ/erSSSmr+1el/8Acyj/ALdZ/el+1el/ 9zKP+3Wf3q0kkpq/tXpf/cyj/t1n96X7V6X/ANzKP+3Wf3q0kkpq/tXpf/cyj/t1n96X7V6X/wBz KP8At1n96tJJKav7V6X/ANzKP+3Wf3pftXpf/cyj/t1n96tJJKav7V6X/wBzKP8At1n96X7V6X/3 Mo/7dZ/erSSSmr+1el/9zKP+3Wf3pftXpf8A3Mo/7dZ/erSSSmr+1el/9zKP+3Wf3pftXpf/AHMo /wC3Wf3q0kkpq/tXpf8A3Mo/7dZ/el+1el/9zKP+3Wf3q0kkpq/tXpf/AHMo/wC3Wf3pftXpf/cy j/t1n96tJJKav7V6X/3Mo/7dZ/el+1el/wDcyj/t1n96tJJKav7V6X/3Mo/7dZ/el+1el/8Acyj/ ALdZ/erSSSmr+1el/wDcyj/t1n96X7V6X/3Mo/7dZ/erSSSmr+1el/8Acyj/ALdZ/el+1el/9zKP +3Wf3q0kkpq/tXpf/cyj/t1n96X7V6X/ANzKP+3Wf3q0qufmtw6Q7abLrDsopHL3ngfDuT2CSQCT Q3L5nZ1TqdzCy3Lvex3LXWPIMa8Erf8AqTfiVZGbkZdzK7SGBr7XgE7i5z/pHXUCVzl2Oabn1B7L fTO31GElpj90kBdj9Q8V1eNlZJexzbnMaGtJ3NNe+d0gc7xEKKGPLGpkERPV0ubz8ucc8cZRMxXp G+4d/wDavS/+5lH/AG6z+9L9q9L/AO5lH/brP71aSUrmNX9q9L/7mUf9us/vS/avS/8AuZR/26z+ 9WkklNX9q9L/AO5lH/brP70v2r0v/uZR/wBus/vVpJJTV/avS/8AuZR/26z+9L9q9L/7mUf9us/v VpJJTV/avS/+5lH/AG6z+9WWua5oc0hzXCQRqCD3CdJJSkkkklKSSSSUpJJJJSkkkklKSSSSUpJJ JJSkkkklKSWX1brgwcnHwMbGszuoZYc6rGrLWgVsgPttseQGMBcB3PgCi9NzOpXss/aeCOnvrAIL bm3VuB3TteAx3tjWWjnSUlN9JcufrjnvxH9WxOjW5HRKt7jlC1jb31sJDrasYj3M0kS8Ejsujxcm jMxqsrHeLKL2NsqeOC1w3NP3JKSpJJJKauH/AEjO/wCPb/54pVpVcP8ApGd/x7f/ADxSrSSlJJJJ KUkkkkpSSSSSlJJJJKUkkkkpSSSSSlJJJJKUkkkkpSSSSSlJJJJKUkkkkpSSSSSlJJJJKUkkkkpS SSSSlJJJJKeb+vn/ACRT/wCGW/8AUWLhDwu96/bV1C1uF6fr1UWAbASPUyS0hlQLYgMa4ueeyz+o fVbEw2UMaz1H3Vur3kuj7Q39IzSeHgFn3d1BkiZEkOpyuaOPHGE74pWR5PZJIOJk15eLVk1/QtaH AeE9j8EZTuYQQSD0UkkkkhSSSSSlJJJJKUkkkkpSSSSSlJJJJKUkkkkpSSSSSlJJJJKUkkkkpSSS SSlJJJJKUkkkkpSSSSSlJJJJKUkkkkpSSSSSlJJJJKUkkkkpSSSSSlJJJJKUkkmc5rWlziGtaJJO gACSkeTk04tD8i922usS4/wHiSuM671S8mx9ntybQay2f5ms6+i3+W4a2Ht9FaPUOouzLRc13p01 NNmOXDRjBocuxv4VN7nVZnQum/tnqJyLGEYGMdGuMlxncGuPcuPucU7FATJlL+bhv4nsyZJezERj /PZNv6o7t/6ufVfGswvtXUqvUffDqqyS3azsTtI1cuhwemYPTw8YdQqFkF8FxmOPpE+Ksp0Z5ZTJ smj+j0YYwjGtNe/VSSSSYuUkkkkpSSSSSlJJJJKUkkkkpSSSSSlJJJJKUkkkkpSSSSSlJJJJKUkk kkpSSSSSnj7ausZH166i3p19GI9mBitN19Tr3bC+50MYLKx9LmSo5fU+tjD+snROoPrvy8Tpr8jE y8VjqnPbbVa0bq9z9r2vZpDlsdV6DlZHU6usdLzPsHUK6jj2F9YuqtqJ3htjNzDLXatIcp9I6B9i tzMzNyHZ/UOo7RlXuaGM2MBayqqoEhjG7j3JPclJSL6tir/mV0wH+b/ZtO//ALZbuUfqJu/5n9I3 TP2ZnPh2/BVa/ql1WnDPRqOsOr6IQWNp9EHJbSeaW5O+I7TsmPvXR4uNRiY1WLjsFdFDG11MHDWs G1o+4JKSqva/ODyKaans7Ofa5h/zRU/8qsJJKczFs6j6+ZtopJNw3A3OEH0auP0JnRWfU6p/3Ho/ 7ff/AOkEsP8ApGd/x7f/ADxSrSSmr6nVP+49H/b7/wD0gl6nVP8AuPR/2+//ANIK0kkpq+p1T/uP R/2+/wD9IJep1T/uPR/2+/8A9IK0kkpq+p1T/uPR/wBvv/8ASCXqdU/7j0f9vv8A/SCtJJKavqdU /wC49H/b7/8A0gl6nVP+49H/AG+//wBIK0kkpq+p1T/uPR/2+/8A9IJep1T/ALj0f9vv/wDSCtJJ KavqdU/7j0f9vv8A/SCXqdU/7j0f9vv/APSCtJJKavqdU/7j0f8Ab7//AEgl6nVP+49H/b7/AP0g rSSSmr6nVP8AuPR/2+//ANIJep1T/uPR/wBvv/8ASCtJJKavqdU/7j0f9vv/APSCXqdU/wC49H/b 7/8A0grSSSmr6nVP+49H/b7/AP0gl6nVP+49H/b7/wD0grSSSmr6nVP+49H/AG+//wBIJep1T/uP R/2+/wD9IK0kkpq+p1T/ALj0f9vv/wDSCXqdU/7j0f8Ab7//AEgrSSSmr6nVP+49H/b7/wD0gl6n VP8AuPR/2+//ANIK0kkpq+p1T/uPR/2+/wD9IJep1T/uPR/2+/8A9IK0kkpq+p1T/uPR/wBvv/8A SCXqdU/7j0f9vv8A/SCtJJKavqdU/wC49H/b7/8A0gqPU+pdRx2CltdFd94dsf6rnCtrRLrXg0t9 rVp5WTTiY78i47a6xLj3+A8z2WDi413VM6x+UIaC05Y5AA91WIP6v0rPPRNkeg3LLigDc5fLH8WX RcPOa1maMestLNuM221wc1rjL7HfoTLrT7ifDRXuo0dTzMR9Ho0MeYdW8XOJa9p3McP0A4IWmkiA KpbLJIz4+oOjz3Qs7NJfj101RbOTUx1rm7Q9xbawRU76NgM+ErX9Tqn/AHHo/wC33/8ApBY2aD03 qhvbpW132tv/ABdkV5bfkdti6IEESNQeChHt2X5wLExtMX9Wt6nVP+49H/b7/wD0gl6nVP8AuPR/ 2+//ANIK0knMLV9Tqn/cej/t9/8A6QS9Tqn/AHHo/wC33/8ApBWkklNX1Oqf9x6P+33/APpBL1Oq f9x6P+33/wDpBWkklNX1Oqf9x6P+33/+kEvU6p/3Ho/7ff8A+kFaSSU1fU6p/wBx6P8At9//AKQS 9Tqn/cej/t9//pBWkklNX1Oqf9x6P+33/wDpBL1Oqf8Acej/ALff/wCkFaSSU1fU6p/3Ho/7ff8A +kEvU6p/3Ho/7ff/AOkFaSSU1fU6p/3Ho/7ff/6QS9Tqn/cej/t9/wD6QVpJJTV9Tqn/AHHo/wC3 3/8ApBL1Oqf9x6P+33/+kFaSSU1fU6p/3Ho/7ff/AOkEvU6p/wBx6P8At9//AKQVpJJTV9Tqn/ce j/t9/wD6QS9Tqn/cej/t9/8A6QVpJJTV9Tqn/cej/t9//pBL1Oqf9x6P+33/APpBWkklNX1Oqf8A cej/ALff/wCkEvU6p/3Ho/7ff/6QVpcf/jB/7QDt+m/9FJspcIJZMGL3ckYXw8V677C3pvU6p/3H o/7ff/6QS9Tqn/cej/t9/wD6QXmfS7GU9Tw7bHBjGX1ue46ANDwST8l6pXZXawWVPbYx2rXNIIPw IQhPivSmTmeW9kxHFxcXWqa/qdU/7j0f9vv/APSCXqdU/wC49H/b7/8A0grSSe12r6nVP+49H/b7 /wD0gl6nVP8AuPR/2+//ANIK0kkpq+p1T/uPR/2+/wD9IJep1T/uPR/2+/8A9IK0kkpq+p1T/uPR /wBvv/8ASCXqdU/7j0f9vv8A/SCtJJKavqdU/wC49H/b7/8A0gl6nVP+49H/AG+//wBIK0q3Uc+n p2HZmXhzq6o3BgBd7nBoiSO5SSASQBqSaC3qdU/7j0f9vv8A/SCXqdU/7j0f9vv/APSCxf8An50j /Q5P+az/ANKLVw+t9NysRmWLm0ssmG3Oaxw2kt1G4+CaJxOxZJYMsBcoEdEvqdU/7j0f9vv/APSC XqdU/wC49H/b7/8A0ghO690Zpj7ZS4+DHB//AFEqr1HruIenZX2Z1xt9Gz03sqt9rthIdv2QI8ZR 4h3CBhyEgcMtfBv+p1T/ALj0f9vv/wDSCxOp9Rzcx4xGUVvqFvpOrZa4+u8amsO9JvsZzZ90rkP2 x1c/9rsj/t1//klpdN6qzA6Nba15f1Cx7sfHLiT6VQDXuLQfo6u+/wCCbAnLIQiN2zk5cctA5pyE uHYDukzTmZmUOi0bH5D7Jy7mOLmveB47W7WVjQN7Lq+nYmb0/ErxaMajbWNXeu+XOPLj+g7qn9VO inAxfteQ39byBJnlrDqG/E8lb6sZZAAY4fLD8T3c+HFInJP5p/gOgavqdU/7j0f9vv8A/SCXqdU/ 7j0f9vv/APSCtJKJe1fU6p/3Ho/7ff8A+kEvU6p/3Ho/7ff/AOkFaSSU1fU6p/3Ho/7ff/6QS9Tq n/cej/t9/wD6QVpJJTV9Tqn/AHHo/wC33/8ApBL1Oqf9x6P+33/+kFaSSU1fU6p/3Ho/7ff/AOkE vU6p/wBx6P8At9//AKQVpJJTV9Tqn/cej/t9/wD6QVlu7aNwAdGoBkT5GAnSSUpJJJJSkkkklKSS SSUpJJJJSkkkklKSSSSUpJJJJSklk/WHqGTjY1WH0+D1PqL/AEMQHUMnWy938mpku89B3Wf9Wup3 431e6jmdSybMsdMyM1r77ILzVivcBO0DXa3sElPTJLjMPpfWuqfV9nXz1fMp6tlUHLxmVv24tYe0 2VVfZo2PaGkAlwJPK6P6v9TPVuiYPUnNDH5VLLHtHAcR7gPmkp0EkkklNXD/AKRnf8e3/wA8Uq0q uH/SM7/j2/8AnilWklKSSSSUpJJJJSkkkklKSSSSUpJJJJSkkkklKSSSSUpJJJJSkkkklKSSSSUp JJJJSkkkklKSSSSUpJJJJSklT6h1fp/TfT+22+l6s7Pa507Yn6DT4rH6l9a+l3VNxsPJINx223Bj wWMj3bZaJc7hqaZAbkMkMOSdERlR/So0z6hl25+YyrGhzWPLMUHVr7m/Tvd4sp7eLltYeJVh47Me qSG8uOrnOOrnOPiTqqfRsA0V/abWenda0NZV/oqW/QqH5XeJWmlEdTuU5ZjSEflj+JUkkknMTm9d o3Ygymt3vwz6hZ+9URtuZ82EpdDu3YhxXO3vxHekH/vVwHUv/tMIWiQCCCJB0IK53AJ6b1MY7jDG u+yO863TbiPPw91aadJA92aHrxyh1j6h/L+W70aSSScwqSSSSUpJJJJSkkkklKSSSSUpJJJJSkkk klKSSSSUpJJcT9YvrF1nC6zkY2NkenTXs2t2MPLGuOrmk8lNlIRFllw4ZZpGMSAQL1e2SXJfVLrv Veo9RsozL/VrbS54GxjYcHMH5jR+8utRjISFhGbFLFPgkQTV6KSSSRY1JJLK6n1ltPqUYrm+pX/P 3u1rpniY+k8/msCBIG66EJTNAJ+odTZifoqwLcpwLm1TtDWjmyx35jB4rCHQndeubl5dtnotBm8e 31JiBTW4HZW3sTq5Xun9Hdkfp81rhS8h/o2a2WuHFmSf+pYNAtzjQJtcW+3Zm9wYdMZ9fWX8Hnq/ qP0uqxttd+S2yshzHbq9HAyD/NpWdJ6jhPN2N7u5txIpsPnZju/Q2fKCuiSR4I9NFv3nKfmPH4Sc LF69kh5qvrGS5v0hUDXe3+vjWe7/ADCVbs+sPRq6PXsyWtZuDC2Hbw4gmHVgbhx3Ct5WDiZjAzJq baB9Ekag+LXDUfJcp9cel/ZcKq4XOtZ6oY1toD7Gy15gXfT26cGUJGUQTuvxxw5ZxiQYEno7X/O7 6vf9y/8AwO3/AMgtheQHhd8K/rC8hzzljyD8Rp/6LCE2GQm7H2MvMcnDHw8M6u74z+T0KDl5ePhY 78nJf6dNcbnQTEkNGjQTyVifZeuvILjlCOxyaB/1FCz+v4vVW9JvsyRaKmlkh+SLBq9oE1tpbOv8 pOM6BNFhhy4M4gzjqQPSRf0dn/nd9Xv+5f8A4Hb/AOQVk9d6VtaWXi1z2hza6g6x5BEj2MBcPmF5 evQuj9Gqs6XiuuvueyymtxpY70matBgikMLv7RTYZJS6Bn5jlcOEAky1NdP4M8n6wurMNobQTwcu xtZPwqZ6lh/zVkdey+p5XSr3WGw4/sLttHo1RvbHuvd6rtfABdTjdPwcQfq1FdR7lrQCfi7kqwnG JIIJYI5scJAxx3RB1/kafIJC7T6t9G+09Ix8j1/S375DaaS7R7m/zllbnHhdWkhHEAbJtlzc8ckR ER4Nbu+L9jmt6K0CDm5ZHgLAzn/imsQ8v6vYl2JfWw2Pvsre2t919rgHOEAkF5HPktZQuuqoqddc 4MrYJc52gAT+EHSmr70wb4iK17Pnuf8AVTN6fQbsrJxmN12je/c4gTDR6epVn6odD+2ZP23IbONj u9oPD3jgfAclVvrF1kdWzA6uRjUjbSDyZ+k+PNdt0N2K7pOMcQbadg9vcOH0p890qf2BggJi+OWn kCtnzuTmSccjHgiRLbUkN9JJJQoUkkkkpSSSSSlJJJJKUkkkkpSSSSSlJJJJKUkkkkpSSSSSlJJJ JKUkkkkpSSSSSlJJJJKUkkkkp5i/E+s9P1iyuqUYeLm1urZRhGzJdUaqh77Bs9Cz3Pf9IzwG+Cy/ q5T1nqX1f6/063Hppqy7epVttZabHDIte9hZ6fptG0Fx927XwXdodGNj47XNx6mUte91jxW0NBe8 7nOO3kuOpKSnmOhfWDpmL9RcTIuvYx2Fhsx7aif0guqYKjVs+lvLhELT+qGFfgfVjpmJkNLLqsas WMPLXEbi0/CYVo9D6K7O/aJwMY507vtRqZ6sxE79u6YV5JSlXtxrrHlzMq2oH8xgqIH+fW4/irCS SnMxcW835gGZc3bcASBTr+hqMmavlorP2PI/7nX/AObR/wCkUsP+kZ3/AB7f/PFKtJKav2PI/wC5 1/8Am0f+kUvseR/3Ov8A82j/ANIq0kkpq/Y8j/udf/m0f+kUvseR/wBzr/8ANo/9Iq0kkpq/Y8j/ ALnX/wCbR/6RS+x5H/c6/wDzaP8A0irSSSmr9jyP+51/+bR/6RS+x5H/AHOv/wA2j/0irSSSmr9j yP8Audf/AJtH/pFL7Hkf9zr/APNo/wDSKtJJKav2PI/7nX/5tH/pFL7Hkf8Ac6//ADaP/SKtJJKa v2PI/wC51/8Am0f+kUvseR/3Ov8A82j/ANIq0kkpq/Y8j/udf/m0f+kUvseR/wBzr/8ANo/9Iq0k kpq/Y8j/ALnX/wCbR/6RS+x5H/c6/wDzaP8A0irSSSmr9jyP+51/+bR/6RS+x5H/AHOv/wA2j/0i rSSSmr9jyP8Audf/AJtH/pFL7Hkf9zr/APNo/wDSKtJJKav2PI/7nX/5tH/pFL7Hkf8Ac6//ADaP /SKtJJKav2PI/wC51/8Am0f+kUvseR/3Ov8A82j/ANIq0kkpq/Y8j/udf/m0f+kUvseR/wBzr/8A No/9Iq0kkp4r69U2VHB332Xz6seoGCI9Pj02M/Fc/wBKaXdUw2hxaXZFQ3CJEvbqNwI+8Lserub1 PObSxjLfTc7Hxt7Q4G1wHrWEH82lv/SWtjdF6VjNqFeLTvpDdtpraXy3h26JnzUJgZTJBdCHMjDg jjkCZES/FJ9jyP8Audf/AJtH/pFL7Hkf9zr/APNo/wDSKtJKZz2r9jyP+51/+bR/6RS+x5H/AHOv /wA2j/0irSSSmr9jyP8Audf/AJtH/pFZHXOm2h1V5yrS20jHte4VjbJ3Uu9tbdG2x56roUHMxq8v FtxrPo2tLSe4ngj4ISFhfjnwzB+1pdOGTmYdd7s29lhBbazbR7bGna9v8z2cFZ+x5H/c6/8AzaP/ AEiszoWTYzJfRdo/IBc4eGRTFV4/te14+K3UomwnLDhmR03DV+x5H/c6/wDzaP8A0il9jyP+51/+ bR/6RVpJFjav2PI/7nX/AObR/wCkUvseR/3Ov/zaP/SKtJJKav2PI/7nX/5tH/pFL7Hkf9zr/wDN o/8ASKtJJKav2PI/7nX/AObR/wCkUvseR/3Ov/zaP/SKskgCToByV5DzqeUyc+GtLts8ty3v8Xq4 eGul7vqv2PI/7nX/AObR/wCkUvseR/3Ov/zaP/SK5r6m9QGN022t1F9o9cu31VmxolrBENl3bwW+ OvdJmH5ApJ7XNdV/58a1GMwQDssyYJwnKIBlwncBN9jyP+51/wDm0f8ApFL7Hkf9zr/82j/0ii05 eLfrRdXb/UcHfkKxMr66dLxsm3GfVe59L3VuLWsiWnaYmweCJkBuVkMWSZIjEkjd1vseR/3Ov/za P/SKhbS+it1t3Ubq62CXPcKAAPiaVm1/W3Hy6rHYVDwao32ZJbXUwOmC5zXOJ40AElQqw+odSsbf Y47QZZkXshrf/C+MdB/Xs18kOMHbVf7Eh/OegDvuxyepZZcwYuXeyt59lltdTn2f8RQ2kPd/WMBZ mV9UOsZ2Q/LNjW+qQYybC63QAe8117e3A44XW4fTsXELnVgvuf8Azl9h3WO/rOP5OFaQMOL5l0eY 9o/qgB0s7l4nF+pPVarC919Dfb7S0uJmRw4sG34haDq+vYdYZ62VWBzZFeawx/YZaP8ANK6ZJIQA 20VLmpzNzAl9HmsXquXYdr8i3II5OIaHuH9aiyllg+4qt1P60HCvbVRdk5ALA55d6VJa4kjaWPxS ey6bKwMLLEZNDLY4LgNw+DuQuM+tXRcpvUaxhUZORT6LdYsuDTuf7A47o+EoTMwNCycvHl8k6lHh 0Ol6fayq+tGdnX14tb8iv1SQ7YarHkbT7WbaK9pJ/OnRbnTvq7ZWyq3JyHstqJdTUwVubXu7kurI fZ4vhc79V+m9Ro67i23Yl1VbfU3PfW9rRNbwJLhHK79LHctZd1c2YYyMeKhEizRtq/Y8j/udf/m0 f+kUvseR/wBzr/8ANo/9Iq0kpGm1fseR/wBzr/8ANo/9IpfY8j/udf8A5tH/AKRVpJJTV+x5H/c6 /wDzaP8A0ihZHShksFeTk2XMB3BtleO4TxMOoPir6SSgSNQ5H/Nrp/l/2xi/+86u/Y8j/udf/m0f +kVaSSoJMidyT5tX7Hkf9zr/APNo/wDSKhd0119Zqvyrba3fSY9lDmmDOoNCupJIcj/m10/y/wC2 MX/3nVtmBbWxrGZlzGMAa1rW0AADQAAUq4klQSZSO5J82r9jyP8Audf/AJtH/pFL7Hkf9zr/APNo /wDSKtJJIav2PI/7nX/5tH/pFL7Hkf8Ac6//ADaP/SKtKt1DqGL07GdkZL9rBoB3cf3WjuUQCTQ1 JUSALKDKH2Oh2Rk9RurqYJLiKPuH6HUrlg7qv1nyjj122Dp9TpL7A0QPF3ptYHO8AiV1dS+tmZ6t s0dOqOgHA8m/vP8AE9l1+JiY+FQ3HxmCupnAH5T4lT6YR+9l/CP9rDrl8Mf4y/scVv1K6U0Aepcf Mln/AKTV7D6K3BqNOLlX1VklxaBUdT/WqPgtJJQmc5byJ8yyCERsAPo1fseR/wBzr/8ANo/9IpfY 8j/udf8A5tH/AKRVpJNXNX7Hkf8Ac6//ADaP/SKX2PI/7nX/AObR/wCkVaSSU1fseR/3Ov8A82j/ ANIpfY8j/udf/m0f+kVaSSU1fseR/wBzr/8ANo/9IpfY8j/udf8A5tH/AKRVpJJTV+x5H/c6/wDz aP8A0il9jyP+51/+bR/6RVpJJTV+x5H/AHOv/wA2j/0il9jyP+51/wDm0f8ApFWkklNX7Hkf9zr/ APNo/wDSKstBDQCS4gQXGJPmYgJ0klKSSSSUpJJJJSkkkklKSSSSUpJJJJSkkkklKSSSSU18zqGB gV+rnZNOJXxvvsbW2fi8gItdtd1bbKntsreJa9pBaR5EKpk9G6Rk5X27MxKb8hjPTFtzA8tZrIbv kNncZhcr9V8j9mfVv6xdTwKy3ptN+Zk9KqJ9hqqr3TXzDHPaYSU9bZ1bpVWY3AszKGZj9WYzrWC0 88Vl248eCtrkOjfVnpGd9R6a8nGrtu6liDKyMhzQbXX5DPVNpeddwc7TwWv9UMy/O+q/TMvIcX3W 4zDY88ucBtLj8YSU7CSSr25+DS813ZNVbxyx72tOvkSkpjh/0jO/49v/AJ4pVpZmL1Lpzb8wuyqQ H3AtJsbqPRqbI18QrP7V6X/3Mo/7dZ/ekptJKr+1el/9zKP+3Wf3pftXpf8A3Mo/7dZ/ekptJKr+ 1el/9zKP+3Wf3pftXpf/AHMo/wC3Wf3pKbSSq/tXpf8A3Mo/7dZ/el+1el/9zKP+3Wf3pKbSSq/t Xpf/AHMo/wC3Wf3pftXpf/cyj/t1n96Sm0kqv7V6X/3Mo/7dZ/el+1el/wDcyj/t1n96Sm0kqv7V 6X/3Mo/7dZ/el+1el/8Acyj/ALdZ/ekptJKr+1el/wDcyj/t1n96X7V6X/3Mo/7dZ/ekptJKr+1e l/8Acyj/ALdZ/el+1el/9zKP+3Wf3pKbSSq/tXpf/cyj/t1n96X7V6X/ANzKP+3Wf3pKbSSq/tXp f/cyj/t1n96X7V6X/wBzKP8At1n96Sm0kqv7V6X/ANzKP+3Wf3pftXpf/cyj/t1n96Sm0kqv7V6X /wBzKP8At1n96X7V6X/3Mo/7dZ/ekptJKr+1el/9zKP+3Wf3pftXpf8A3Mo/7dZ/ekptKh1fMfj0 Cqlwbk5BLKnHhgAl9rvJjdUQ9W6WBJzKNP8AhGf3rnzm4nVM7ddkV103j37ntbtxmO9tWp+lc4S4 fupsj0G5ZcMASZS+WOpdToOGxtf23aWte0V4jXfSbQDO4/yrD73LXVQdU6WBAy6ABwPUZ/en/avS /wDuZR/26z+9EChSyczORkW0kqv7V6X/ANzKP+3Wf3pftXpf/cyj/t1n96K1tJKr+1el/wDcyj/t 1n96X7V6X/3Mo/7dZ/ekptJKr+1el/8Acyj/ALdZ/el+1el/9zKP+3Wf3pKcjq9T8TqH2ikSbIya gO91Ai1n/XKSfuW9Vay6pltZ3MsaHMPiCJCyusZvTrsJzqszH+0Y5F9E2s+nXqBz+cPb80HonWem V0WYzsqmuup27H32Nb+itHqNZqeWSWkeSZdSruzmJyYhIAkw9J8neSVT9q9LOozKP+3Wf3p/2r0v /uZR/wBus/vT2BtJKr+1el/9zKP+3Wf3pftXpf8A3Mo/7dZ/ekptIGXm4+HV6t7toJ2taNXOceGs aNSSs/O+seDSRVjXVX3uEgmxoqYP3rH/AMBqVl4tlGdeci/PZWDIdkPe1lrh3ZRWT+hZ5/SKaZdB qWWGLTimeGP4lsZGRndVuOO2uWt5xZhjPA5djeT/AME35qFf1C6YGNFl97nge4tLGgnyBY6PvWvj 5nRMWltGPkY9dbeGtsZ/5LlF/avS/wDuZR/26z+9LgB+bVd94nHTEeCPh1aWH9Vej4lRr9M3EuLv VsI9QSAIDmBmmiMeiUARTkZNDf3W3Oc3/Nt3hH/avS/+5lH/AG6z+9L9q9L/AO5lH/brP70eEdlh zZCbMifNzbvq2X6+tVaexvxqnO/z6vScuD6hWac/JqO2a7rGnbIbo4j27iTHzXp37V6X/wBzKP8A t1n96qPH1Xse6ywYD3vJc5zvRJJOpJJTJ4720Z+X5w4yeMcQrSqDz/1Dxce67Lutra+yn0vSLhO0 u9SSPPRdqs/HyPq/i7vstuJRvjd6bq2THE7Y8Ub9q9L/AO5lH/brP706EeGNMPMZfdyGeoBqgeja SVX9q9L/AO5lH/brP70v2r0v/uZR/wBus/vTmJtJKr+1el/9zKP+3Wf3pftXpf8A3Mo/7dZ/ekpt JKr+1el/9zKP+3Wf3pftXpf/AHMo/wC3Wf3pKbSSq/tXpf8A3Mo/7dZ/el+1el/9zKP+3Wf3pKbS Sq/tXpf/AHMo/wC3Wf3pftXpf/cyj/t1n96Sm0kqv7V6X/3Mo/7dZ/el+1el/wDcyj/t1n96Sm0k qv7V6X/3Mo/7dZ/el+1el/8Acyj/ALdZ/ekptJKr+1el/wDcyj/t1n96X7V6X/3Mo/7dZ/ekptJK r+1el/8Acyj/ALdZ/el+1el/9zKP+3Wf3pKbSSq/tXpf/cyj/t1n96X7V6X/ANzKP+3Wf3pKbSSq Hq3Smgk5lED/AIRn965/qv12Y3dT0xm93HrvHt/st5PzT4Y5zPpH16LZzjHcut1X6xYPS7PRu3Ot NZsa1o51hrSe0rAwun9Q+s+X9v6gTXhNMVsGkj91n8XLnbsq7JvdkZD/AFbXmXOd3j+C9FwetdKt w6bBfTQCwfoS9rdkabdpI4VicfYgDEeqWhl28mCEvdkQflGoj3827TTVRU2mlgrrYIa1ugARFV/a vS/+5lH/AG6z+9L9q9L/AO5lH/brP71UbLaSVX9q9L/7mUf9us/vS/avS/8AuZR/26z+9JTaSVX9 q9L/AO5lH/brP70v2r0v/uZR/wBus/vSU2klV/avS/8AuZR/26z+9L9q9L/7mUf9us/vSU2klV/a vS/+5lH/AG6z+9L9q9L/AO5lH/brP70lNpJVf2r0v/uZR/26z+9L9q9L/wC5lH/brP70lNpJVf2r 0v8A7mUf9us/vS/avS/+5lH/AG6z+9JTaSVX9q9L/wC5lH/brP70v2r0v/uZR/26z+9JTaSVX9q9 L/7mUf8AbrP71Za5rmhzSHNcJBGoIPcJKXSSSSUpJJJJSkkkklKSSSSUpJJJJSkkkklKSSSSU8j9 b+o5ludV0U4meOl2V+rnZmFj2XGxs7RisdUDs3cvPMad1pYluB1rpOV0ijCysDF+znG2ZGPZjN9O xjq9te8NnaPDhbiSSnjOndX6lgfV+roLul5b+s4tAw62tqccd5Yz02W/ao9P041Os9oldH0Dph6T 0TB6a5we7EoZW9w4LgPcR81oJJKUkkkkpq4f9Izv+Pb/AOeKVaVXD/pGd/x7f/PFKtJKUkkkkpSS SSSlJJJJKUkkkkpSSSSSlJJJJKUkkkkpSSSjZZXWwvscGMbq5ziAB8SUlMkl5V1WxlvVMy1jg9j7 7XMcNQWl5gj5Lf8AqLm4uNZl132tqNvpemHmASPUkAnSdVEMtyqvrbdyciYYjkEuIgA8PD3+r2yS SSlaSkkkklKSSSSUpJJAzcuvDxX5DwXBg9rBy5x0a0ebjokkAkgDcuZ17MaR9i1dWALMsN5c0nbX QP5VrtPhKvdLw34uOTdByrz6mQ4cbj+aP5LR7QszpOI/Jy3ZGQQ8Y9hfY7s/KIh0fyaW+xvnKj1n 6242ITj4IGTlfRkasafl9I+QSx45ZJaC2TPkjjgIXtrLxLq9U6nj9NxH5FrhuAPpMJ1e7s0Lnvqv 9Ym7rMTqFsOtebKrXnTc4y5pPbXUIWL9WeqdWec3q97qnP8AosIl8f1dAweSsv8AqJjlpDMt4d2J aCPyhWhHBGJhKVyO5A28mkTllISjGgOh6vUpLjKeo9a+rVrcbPYcjCJhjgZEf8G8/wDUldTgdSw+ o0+tiWB7fzm8OafBw7KGeIx1+aJ2kNmWGQS02l1iW0kkko16kkkklOP9bv8AxPZf/W//AD6xecL1 nLxMfNx342Sz1KbI3NkiYIcNWkHkLN/5o/V7/uJ/4Jb/AOTUWTGZGxWze5Tm8eHGYyEiTK9K7Of0 7M6xX0/GbWbfTFNfpg4he2A1ugfXcCR5wj/trqjfphonUb8TKZ8RpvW9TTXRSyioba6mhjG6mGtE AaqaeInuwSzRJJMBqfAfseW6h17Js6fk1OONFlLwIN7HwWkGBZSBOviuJgL1nNx/tWHfi7tnr1vr 3RMb2lsxp4rlf/G/P/c//wAB/wDUqjyQkSOra5XmcMIyB/V2fE39gbf1T6XTb0rGysg+q0Oe6mkg BjXB7m7yB9N2nJ47LpVT6R0/9mdOqwvU9X0t36SNs7nOfxJ8fFXFJEVEDwaefJx5JG7HEeHytSSS ScxKSSSSUpJJJJSkkkklKSSSSUpJJJJSkkkklKSSSSUpJJJJSkkOm+m9hfS8WNDi0luurTBCqZnX OlYUjIyWB45Y07nf5rZKIjImgCT2QSALJFN9JctlfXiou9Pp+K+550a6zTXya2SVm9S6n9anY32n KLsLHc4NaGj0iSdYH+E4Cmjy0zV1C+5/YxnPAbXKuz2GJ1LFzL8iilxL8V+yye58R5TIVteU0Od6 zQLjTvIa6wE6Ankxquo/5r/WKv8AmepxHH6S1v5JTsnLxiR6+G9rC2GaUh8l12L1yS5H9jfXKr6G fvjj9K8/9W1Rtr+u+LW6114NdTS5zi6o6ASfphM9kHbJD7V3unrCT1ptqBc0vaCwBzwSJDTME+A0 KwOq/XHExyacBv2q/gO/wYPy1d8vvXIvy8jqGWHZuQW+u5rbrY0DRAktbtGi73pX1e6b0wB1TPUv 73v1d/Z7N+SfLFDFRncydojQfatjknksQ9IG5O/2OBT0PrvXbG5HVrXUUctrIh0fya+G/E6rpend IwOms24tQa46OsOr3fFyupKKeWUtPlj+6NAyRxxjrvLud1JJJKNepJJJJSkkkklKSSSSUpJJJJSk kkklKSSSSUpJJJJSkkkklKSSSSUpJJJJSkkkklKSSSSUpJJJJSkkkklKSSSSUpJJJJSkxIAJJgDU kp1mfWc2j6tdWNO4WjCyPTLJ3bvSft2xrMpKco/XHPfiP6tidGtyOiVb3HKFrG3vrYSHW1YxHuZp Il4JHZdHi5NGZjVZWO8WUXsbZU8cFrhuafuWR9WxV/zK6YD/ADf7Np3/APbLdyj9RN3/ADP6Rumf szOfDt+CSneSSVe1+cHkU01PZ2c+1zD/AJoqf+VJTHD/AKRnf8e3/wA8Uot+TjYzPUybWUsJgOsc GifCXQqOLZ1H18zbRSSbhuBucIPo1cfoTOiyPrq/Md0ukX1V1s+0Ngssc8zss7OqZ+VCRoE9mTDA TyRgTXEad39s9H/7nY3/AG6z/wAkrbHsexr2ODmOALXAyCDwQV5Eupwv+fX2Oj7LP2b02ej/AEf6 G0bPpa8eKZDIZE6NnmOTjjAImNT+lo9soW3U0Vm257aq2/Se8hrROmpK48W/X42upBPqMa17hGNo HFwaf+iVW6v/AM8f2fb+0/6H7fV/mP3m7f5v3fSjhPJoE1sGGGASlGPuQ1IGh11ev/bPR/8Audjf 9us/8krVV1N9Ytpe22t30XsIc0xpoQvI1v8AS8f6229PqPT3Pbh+70tr62fnO3cnd9KeUzHkMjR0 0Z+Y5KOOAkJ9a9VB9AQczI+y4l+SW7/QrfZtmJ2NLon5LjD0365uubQ/ItY97XPb+sEaNLQ76B/l hDy+gfWZuLfdlZBdVXW6ywOuc6Q0EnTWdFIRoaI/H+DWjCHEASdSNqP7W7/44B/7gf8Ag3/qJdJ0 jqH7S6fVm+n6Xq7vZO6NrnM5geC8skLd6X0Pr2VgsysG8NpeXBrG2uYRDiDIGnKixSlKRBI266N3 m+Ww48YMQYHiqxr0PcvoSS4azpX1xoNbftVhNrtjGjIcdQ1z/wA4xw0ojcL691mWvsdGmttbv+rK mrxH4/waPADtL7aH7Xd/53fV7/uX/wCB2/8AkEev6wdHsx/tDMlpr3FgEODi4AGGsI3HnsF5iOFr 9Hwuv341j+lsiovLH2MNbHzAlu9xDwIPYwocc5Tlw+keejc5jlMOHGZkzNHz/IPV5fXsguFVFYx3 O+h6wL7nf1MWv3/5xCFX0rqOc8W5MtjUWZcWvHmzHZ+hZ85KyacX649Or/Q1tpa5zWlwGOXOc9wY 3c7VxknurX/rwP8AX7MrP3a98uP/ABmj97EdMeKY8THVtX/UvpG51+Rk3gvdL3ufW0Fzz/xfclGo +qWLiV2NxMm5ptgPbaK7a3ATo+ssAPK5jq/UevknB6pbqwh5rAr0MS2TUPPhXsDqH1zz6jZh2erW w7CYoBkD+WAU48kBES4oDxvT7Vn+kcpPDcz4UDt4On9n6r0vWoOrqHegG/H/ALWO8+pX/YcVbxfr C1zN2VX+jGjsnHJtqH9cAepX/aase236+U1PusO2utpe8/q5gNEk6IF/TPrlkWi+yqL28XVmit/+ fWWuKb92I2y4/LiX/eoT/nMU/wC9GOr0dv1p6BS8sfltJAB9jXvGon6TGkI2B13pXUbnU4d/q2Nb vLdj2+0ECfe0eK856nXm151rM8bcobfUA292tI/m/bwj9C/bP2x/7H/pPpnf/N/Q3Nn+d05hVvcl x8JrQ1o3jyWL2fcjKVmIkOI0Nfo+nJLjDV9fyZl2v8rH/vQq6vrzfW2+t9jmWtD2H1KhIcJGkhS1 4hp+2P3o/aHoer/WXA6Tktxsiu173sFgNYaRBJb+c9v7qweofWzGzchhqbZUyps0F7W6Wu9ptcGu P822do8VidZq6tVltHVi45BrBbuc152S6NWkjmVHouGM7qlGK5oeHlxLS4sB2tc6Nwa8jjwUXH+s ESfTxAGuzejy0I4DliLmISkLOl07LMvqnWWN6Z0is4+BUNrnEwSO5tePHmB+K6Lo31awelgWEevl d7nDj+oO35VYx683GqbTj4mNVW36LW3PA/8APCejL6jewvZjUgB72a3u5rc6s/4DxarU8unBAcEO w6+bkjHrxzPHM9T+xvJKr6nVP+49H/b7/wD0gl6nVP8AuPR/2+//ANIKJkTX0U5FTqb2Cyt4hzHC QVy2f9Wc7pt32/oVjvbqaZlwHgJ+mPI/iuj9Tqn/AHHo/wC33/8ApBDry+o2PtY3GpBpeGOm93Ja 2zT9B4PT4ZJQ22O4OxWzhGW+/Qjdy+jfW3HynDG6gBjZQO3cdGOPz+ifit9ltT3PYx4c6sgPaDJa SNwn5Fc59ZemC/EtzcnHootqbPrV3OLj2DS30AHTx/Fcx03qPU8S3ZgW7LLy1hB2kE8Nn1AQOVMM McsTKHo8DtfmxHLLGRGfq8Rv9j6akuR/9eB/r9mUBb9fDa6kH9IxrXuH6voHFwaf+iUz2P8AWY/8 Zd739Sf+K9ioCys2GoOHqNAcWTqAZAMfJcjbb9fKa322O211gue4/ZtABJKxGdb6q3MdnNvIyrG7 HP2t1bpptLdvbwTo8qZXU4n+6b1RLmAKuMh5in0xJcgD9fyAQZB1BH2ZRFv18NrqQf0jGte4fq+g cXBp/wCiU32P9Zj/AMZPvf1J/wCK9ioG2oWNqLgLHguaydSGxJA8pXJk/X8CTx/6DLCs611V+YzN svJyqRtY8NboNdIA2906PLGV1OJr9035IlnA3jIeYp9MSXHU3fXu+pl1Tt9djQ5jh9n1BSNv18Fr aSf0j2ue0fq+oaWhx/6QTfY/1mP/ABk+9/Un/ivYodl9NTq22PDXWu2Vgn6ToJgfcuV/9eB/r9mW Fn9U6vdks+23br8R52QGDa4HWPTEHUJ0OWMj88T/AHTaJZ6HyyH94U+lpLi8TJ+uvUKG349u6l0w /wDQN1BjiA5Tsp+u4dXXZftNztjDur5DXP8AzR4NKacFGjkgPqkZr2hP7HsUHLzMbDqFuS8V1lwY HHxcYC5f9mfXV/tOXtHj6kf9SJWF1W3qbb3YedlOyDS7Uby5odHn3CdDlxI1xxPfhWyzmIvgI830 tJcF0rD+sHVqHuxuoua2shrq7LrQQI0MNDhCsZH1c+sdVYdZnhzXPZXAttOtjm1jlvi5A4IxNSyA EeC4ZZEWIE/V7VV8/NpwMSzLunZUJgck8AD4lcmfqh18iDmVkHkepZ/5BY3Uun5eBknFus9Z7QC7 YXFoJ1j3AdkYYISlQyX1oDotnlnEWYV9X0erKx7aWXtePTtaHtJMaESouz8Fv0smps8S9o/ivPek dFt6nc+lhDHsbvh5LZEwYhjvFat31Ofj0W33Q5tTXPcGXQYaNxicdKeLFAkSmf8AFTHJkkLEB9r1 DutdHbzm0fKxp/IVVyvrP0emix9eQy2xrTsrbJ3O7DQLLb9S6xzVu+OSf4YoVTqP1Szd7Bg4jWtA l7hfvknt+kbXEfBKEMBIHFL60AqUswF8I+mpdLD+ufT/ALHW7NLhlRFjGNJEjuO2qjb9e+nj+ax7 n/1trfyFyodJ+rXU8fLDsvBqvqc0gi2xu0HkO9u8/gujqw7Kf5rp2HXH7ryPyY6OT2Iy0BneuktE Q96Q1Ij01Grhn67ZlxjE6fu7D3Of+DWhV836zfWVtW63HGJXZLWvNbmnUdjYV1GPldRvx6r68akM tY17QbnAgOEiYoQszCuzdn2vBxrvTnZuvfpMT/gPJNjlxAj9UK87KTjyEfzhvyp4fpdWVnXt6bXl HHquJcWku2F0fut0JIC6nD+pPTKYdkvfku7gnY37m6/irNfRq6rG219NxGvYQ5jhc+QRqD/MK/6n VP8AuPR/2+//ANII5eZMj6CYjqrHgA+cCR6M8XBw8Ru3FpZSO+xoBPxPJR1Roy+o3sL2Y1IAe9mt 7ua3OrP+A8WonqdU/wC49H/b7/8A0gq5JOp1ZgK2bSSq+p1T/uPR/wBvv/8ASCXqdU/7j0f9vv8A /SCSm0g5eLTmY78a8E1WRuAJaTBnkfBV68vqNj7WNxqQaXhjpvdyWts0/QeD0T1Oqf8Acej/ALff /wCkEgaNhTQ/5pdD/wBC7/Pd/etaqplNTKmTsraGtkkmAIGpQPU6p/3Ho/7ff/6QS9Tqn/cej/t9 /wD6QTpTlL5iT5oEYjYAeTaSVFuX1F176BjU762MeT67oh5e0f4D+QUT1Oqf9x6P+33/APpBNS2k lV9Tqn/cej/t9/8A6QS9Tqn/AHHo/wC33/8ApBJTaSVF2X1Ft7KDjU77GPeD67ohhY0/4D+WET1O qf8Acej/ALff/wCkElNpJVfU6p/3Ho/7ff8A+kEvU6p/3Ho/7ff/AOkElNpJUbMvqNb6mOxqSbnl jYvdyGus1/QeDET1Oqf9x6P+33/+kElNpJVfU6p/3Ho/7ff/AOkEvU6p/wBx6P8At9//AKQSU2kl Rvy+o0MD341JBexml7ubHNrH+A8XInqdU/7j0f8Ab7//AEgkptJKr6nVP+49H/b7/wD0gl6nVP8A uPR/2+//ANIJKbSSo5GX1HHosvfjUllTHPcBe6YaNxj9Aiep1T/uPR/2+/8A9IJKbSSq+p1T/uPR /wBvv/8ASCXqdU/7j0f9vv8A/SCSm0kqvqdU/wC49H/b7/8A0gi4t/2jFpyNu31mNs2zMbgHRKSk qSSSSlJJJJKUkkkkpSSSSSlJJJJKUkkkkpSSSSSlKL2te0seNzXAhwPcFSSSU8vX9Uuq04Z6NR1h 1fRCCxtPog5LaTzS3J3xHadkx966PFxqMTGqxcdgrooY2upg4a1g2tH3BFSSUpJJJJSGil1duS9x BF1ge2OwFddevzYoZ/TsPqNLaMyv1a2uDw3c5vuAImWEHgqykkkEg2CQR1Dj/wDNH6vf9xP/AAS3 /wAmtWmmuimuioba6mhjG6mGtEAa+SmkgABsAEyyTl80pSr942hZS5uZbeSNtldbAO8sdY4/9WEs zDx83HfjZLPUpsjc2SJghw1aQeQjJIoBIIINEOP/AM0fq9/3E/8ABLf/ACa0sPDx8LHZjYzPTprn a2SYklx1cSeSjJICIGwAXSyZJCpTlIeJJQvpc7MqvBG2uuxhHeXurcP+oKLzoU6SKxh6NP7jfuCk GhohoAHgE6SSkN9LrLcZ7SAKbC909wa7K9Pm9GSSSU4//NH6vf8AcT/wS3/yavYHTcLp1TqcOv0q 3O3ubuc73EAT7yfBWkkBEDYAL5ZckhUpykOxkShy6XX1NY0gEWVP18K7GWH8GoySSKxzMj6t9Fyb n3345fbYS57vUsEk/B6PgdJ6f07f9jq9L1Y3+5zp2zH03HxVxJOM5kUZEjtei0QiDYAvvSHNpdkY d9DCA62t7Gk8S5paJRkkk1c5uX9XOjZuQ/Jycf1LrI3u32NmAGjRrgOApYHQuldOuN+HR6VpaWF2 97vaSDEOcR2Wgkhwi7oL/dycPDxy4dq4jVeSkHCpdj4dFDyC6qtjHEcS1oaYRkkVjQz+h9L6ja27 Mo9Wxrdgdue32gkx7XDxUMT6udGw8hmTjY/p3VzsfveYkFp0LiOCtJJGymztakHEpdRU5jiCTZa/ TwssfYPwcjJIIUkkkkpSDRS6u3Je4gi6wPbHYCuuvX5sRkklNfNwMXPp9DLZ6lUh23c5uo/qEeKo f81Ogf8AcX/wSz/ya10k4TmBQkR5FaYROpAPmFgIEITKXNzLbyRtsrrYB3ljrHH/AKsIySauRZWL Rl0Px8hu+qzR7QS2YM8tIKzf+afQP+4v/gln/k1rpJwnKOkZEeRQYxO4B8wwpqroqZTUNtdbQxgk mABAEnVQZS5uZbeSNtldbAO8sdY4/wDVhGSTUsLa2W1uqsEseC1w4kEQeFm/81+hf9xB/nP/APJL VSThOUdiR5FBjE7gHzRYuLRiUNx8duypk7WyTEmTzPimfS52ZVeCNtddjCO8vdW4f9QUZJNJvUpU s7/m90Q/9o6/x/vWikiJEbEjyQQDuAUGJhYuFWasWsVMJ3FreJiJ/BPfS6y3Ge0gCmwvdPcGuyvT 5vRkkCSdTqkCtlKq/pXS7HufZh0Pe4kuc6phJJ5JJCtJIgkbGkEA7ocfDw8Xd9moro3xu9NjWTHE 7QEsul19TWNIBFlT9fCuxlh/BqMkgSTulSSSSSlIObS7Iw76GEB1tb2NJ4lzS0SjJJKUkkkkpSSS SSkOFS7Hw6KHkF1VbGOI4lrQ0wjJJJKUkkkkpDiUuoqcxxBJstfp4WWPsH4ORkkklKSSSSUhopdX bkvcQRdYHtjsBXXXr82IySSSlJJJJKQspc3MtvJG2yutgHeWOscf+rCMkkkpSSSSSkL6XOzKrwRt rrsYR3l7q3D/AKgoySSSlJJJJKQ30ustxntIApsL3T3Brsr0+b0ZJJJSkkkklIcul19TWNIBFlT9 fCuxlh/BqMkkkpSSSSSkObS7Iw76GEB1tb2NJ4lzS0SjJJJKUkkkkpSDhUux8Oih5BdVWxjiOJa0 NMIySSlJJJJKUkkkkpSSSSSlJJJJKUkkkkpSSSSSlJJJJKUkkkkpSSSSSlJJJJKUqXVesdN6Pi/a +o3topkMaTJc551DGNbLnOMcAK6ud+s9d+P1HpPWRjWZuL099wyaKW73s9ZjWtyG1z7vT2kaCYcY SUt/z66XG77J1H0/9J9iv2/H6C2OmdV6f1bFGX0+4X0klpIBaWuHLXtcA5rh4ELA/wDHO+pQf6Rz ni4O2Gk4+Rv3TG2PS5lH+rRtzOrdV6zXjWYeBmihlDLmmt9r6RYLLzU4At3BzWgnUwkp6NJJY/1s 6d1HqPRbaem5N2LlsLba3Y9hpe/YZdV6jfo7xpPikp2FWOfijqDeml/62+l2Q2uD/Nsc2tzt0R9J 40XNU/UX1amWf84frAze0O2PzYcJHBHp8hS6P9WMnpH1sbkjMz+o4r+n21uyM+71tlhupc2th2ti Q0lJT1iZzmtaXOIa1okk6AAJ1i/XLDys36sdQxsRrrLn1g+kzR1jGua+ypp11ewFvzSU2cD6x9A6 jecfA6jjZN4BPpVWtc6ByQAdVZyM/Fx8nFxLn7bs1z2Y7YJ3OrY61wkCBDWk6rLv+qf1cz8GljMJ mLsY04t9DfQvp0lpY9m17SPD71jg9fb9Zug9P6pS/JOHbk2N6rU39DbUca2tptj+btkgEcHskp7R RssrqYbLHBjG6uc4gAfElSVXqnTcbqvT8jp2Vu9DKYa7Nhh0HwKSlftTpn/cuj/txn96D0vrvTeq NccW1u5tttPpuc3eTS91bnNa1xlp2yPJcv8A83undDEdW6Jh9T6e3jqONiM9Zje32jGY0l3m+v8A zQrX1D6T0F2E7quJh43q/bMz7NlsraHCo3WsZseBO3YYHkkp65MSAJOgHJTqp1fFuzOlZuHj2Gq7 Jx7aqrRoWvexzWu0jglJTT6Z9bfq31XKtxOn9QqyL6ZL2NJGjeXNLgA8DxbIQ8D649B6hmMw8a5+ +4ubj2vqsZVcWfSFNrmhj+Ox1XMdROT1/pGH9W+ndIyMLNxmtFl99TqacUUt2vay1pG/1f5v2HVp JV3J67h9XPTeg9Oxb8fqONl4tuRjOpewYldDxZYX2bdkbWFjdp90pKe1SSSSU5tXXsCzor+uEurw K2WWl7gCTXUXDe0MLpDg2W+Sy6vrq5pot6j0jO6dg5L2MrzL2sLGmzRnrNY9zqwXECSOTqs3qfTu vYPQM76t19Od1Hp11d1fT8nFfWH1MfLq67qbXM/myYBaTIHYqx1DL+sn1j6Y7pDOi29PbmtFWZl5 dlYZWx0C01sY5znuidugSU9gkmaNrQOYEap0lOB1T68fVvpWZZhZeS716Gh2QKqrLRUHceo6trg1 atfU8K/p56li2tyMX0za2yohwc1okx5rP+r3TL+n5PWGX1DZlZr8qnIkE2Mua1212s/o3S0eUKh1 f6v5vThlZ/1ZrbOVW8ZvSZFdV5cCPVrPFdo+EO7pKeg6dm1dR6fi9QpDm1ZdNd9bXwHBtjQ8B0Ei YKsrO+ruNfifV/pmJkM9O/Hw6KrWGDteytrXN000IWikpyuo/Wr6u9LyTidQz6cbIADjXYYMHg8L My/8Y31VouxWU51F7Mi307ntfHpM2Pf6h9pkbmhvzWh1P6vtycv9pYGQ7B6mGhhuAD67Wt+jXfS7 RzRPIhw7FY+Zd1TJ6x0XDz+mOpvx802vyqG+piWVjHvbua/6TNXD2vA8p5SU9RgZ+H1HEZm4Nzcj Gtn07WatO0lhj4EEKwmAAEAQPAJ0lOb1n6x9E6Eyp/VstmKLztqDpc50RMNYHGBOp4CFnfWnomFR jXuvOQ3NBditxmOvfY0CXPa2oOO0dyqPWLz0j6yV9ZyMXIy8S3D+yMdjVOudRY2x1jiWMkgWhwEg fmiVi9Ky2fV/Ny/rH1jAt6f0/qoLsYCt9jsRrXEll1de70/Xn1DDdHSDqkp7XpvUsLqmGzNwbPVo skB0FpBadrmua6C0giCCrSwPqi6y+rqXUfTfTjdQzn34ldrSx3pBldW8sdBbvdW53wMrfSUguzMa i+jHtfF2U5zaGAE7ixpsd9EGAAOSs/q/1p6T0jJZh5Drbcyxnqtxsep91npg7d7m1tMCfFC+sONm 15fT+tYOOc23pzrWXYzSBY+jIa0WGrcQ0va5jTBPErDxvrV07H+sudnW42e2vNxcZjA7Dv3tsodd vr27O4sB00SU9V0jrPTus4xyun2+rWx7qrAWuY9ljfpMex4DmkeYV5c79WhlZfVeqdafiW9Pxc4U V0U3t2W2ei14dkPr/N3bw0TrDV0SSkeRkUY1D8jJsbTTUC6y15DWtaOS5x0Cq9O670bqpe3pudRl ur1e2mxr3AHuQDKzfrpgPzun4jDS7JxKs7HtzsZoLjZjh2142gEkNLg8jvEIvUvqj0nL234dbem9 RoE42ditFdjCPoh22A9ni12iSnTOfijqDeml/wCtvpdkNrg61sc2tzt0R9J40Vhch0i7rV/1yrb1 bDdTfh9MuptyqwTjXOffQ5j6n9twaZadQuvSUhy8vGwsazLy7BTj0jdZY7ho8Ssb/n79Tv8Ay2x/ 84/3LYzMPGzsW3Dy6xdj3tLLa3cOae2iw/sfWehCcVrut9Nb/wBp7C37bU3wqtdtbc0eDyHfyjwk pn0H679C63b9mpyam5j7bq6sYP3Oeypz9tg9o0exu9dAsD6l1n9k23PofQbs3Mtrbcw12BlmRY5k teARoVvpKYve2tjnvO1rQXOJ4AGpKwOn/Xfo2dYAa8nDpsDn42Vl0upova1vqF1NjtD7ROsGFr9U wW9R6ZmdPc4sbmUWUF45AtYWT8pXI5+B9ZvrF06j6uZfTW9Nx6g37XnvfXaxxoj0hj1tk+94BO4C GyElOxg/W+vKyMdtvTsvEw81+zCzrmtFVjjqyQHF7N4Ht3DVdAuPyMzrXWrcLo1vR8jBfjZWNfm5 btn2VrMd4u/QWB3v3urDQI0nVdgkpSzauvYFnRX9cJdXgVsstL3AEmuouG9oYXSHBst8lpLh+p9O 69g9Azvq3X053UenXV3V9PycV9YfUx8urruptcz+bJgFpMgdikp0qvrq5pot6j0jO6dg5L2MrzL2 sLGmzRnrNY9zqwXECSOTqumXH9Qy/rJ9Y+mO6QzotvT25rRVmZeXZWGVsdAtNbGOc57onboF17Rt aBzAjVJS6wOqfXj6t9KzLMLLyXevQ0OyBVVZaKg7j1HVtcGrfWL9XumX9PyesMvqGzKzX5VORIJs Zc1rtrtZ/Rulo8oSU6FfU8K/p56li2tyMX0za2yohwc1okx5p+nZtXUen4vUKQ5tWXTXfW18BwbY 0PAdBImCuf6v9X83pwys/wCrNbZyq3jN6TIrqvLgR6tZ4rtHwh3dbH1dxr8T6v8ATMTIZ6d+Ph0V WsMHa9lbWubppoQkp0VldR+tX1d6XknE6hn042QAHGuwwYPB4Wqsfqf1fbk5f7SwMh2D1MNDDcAH 12tb9Gu+l2jmieRDh2KSnPy/8Y31VouxWU51F7Mi307ntfHpM2Pf6h9pkbmhvzXQYGfh9RxGZuDc 3IxrZ9O1mrTtJYY+BBC5fMu6pk9Y6Lh5/THU34+abX5VDfUxLKxj3t3Nf9Jmrh7XgeU8rrwABAED wCSl1k9b+smH0e2jHfRlZuVkBzq8bCpdfZsYWh9jmtiGguC1lz3Vq+qdP643rXT8F3U2X4ow8iit 7GWM9N77a3t9XaCD6jg7XwSUyv8ArhhFmMOl49/VMjKa54xqGhr62VnY83eqWCva72w7WVpdI6rR 1XD+01Mspc1zqrqLhtsrsYYcx411C5bBq670HJy/rFmdMdl2dZh+bhYAZZdjOr9tLW/RNoLPpwfp agarb+q2Pmtqz8/NodiW9Ty3ZLcV5BfXWGV0Vh+0kbnCrcfCYSU7aqZPUaMfNxMFwc6/NNnphsaN qbve90kHaJA0nUhW1j9e6f1C63D6n0oVuz+nPeW03Hay2q1u22reA7YTDXAxyElMOq/WU4XUB0zC 6fk9TzRUL7WUBrWV1ucWtL7LHNbLoMDyVnonXMfrFd2yq3FycWz0srEyG7La3xubIBIIc0y0gwQu do6p13G69l9QP1dzYzseip9bX0O22Y7rdQ8W7S0ts/Ba31exOqv6hn9a6rQ3Ctzm01U4bXixzKqN 5abXt9pe51h44CSneVXqfU8HpOFbn9QuFGNSJfY6e+gAA1JPYBWli/WnpuRn42E7HrGQ7CzqMp+O SALGMJa9vuIEhrtwnuAkpbpP1y+r/V8o4eJkFuVtD20XVvpe5p7sFrW7vkr7uqUN6uzpBa717Md+ UH6bNlb2VEHWZmwdlDrHROn9ZxvQza9xad1NzfbbU8fRsqeNWuHiFh9IwPrHV9a2WdVY3IxsTp9u NV1NpA9cvupe31KuWvDWHdGhSU9Wg5eXjYWNZl5dgpx6Russdw0eJRkDMw8bOxbcPLrF2Pe0strd w5p7aJKcf/n79Tv/AC2x/wDOP9yboP136F1u37NTk1NzH23V1Ywfuc9lTn7bB7Ro9jd6h9j6z0IT itd1vprf+09hb9tqb4VWu2tuaPB5Dv5R4RPqXWf2Tbc+h9Buzcy2ttzDXYGWZFjmS14BGhSU76i9 7a2Oe87WtBc4ngAakqSq9UwW9R6ZmdPc4sbmUWUF45AtYWT8pSU5HT/rv0bOsANeTh02Bz8bKy6X U0Xta31C6mx2h9onWDCfB+t9eVkY7benZeJh5r9mFnXNaKrHHVkgOL2bwPbuGqx8/A+s31i6dR9X Mvprem49Qb9rz3vrtY40R6Qx62yfe8AncBDZCsZGZ1rrVuF0a3o+RgvxsrGvzct2z7K1mO8XfoLA 7373VhoEaTqkp7BJJJJTm1dewLOiv64S6vArZZaXuAJNdRcN7QwukODZb5LLq+urmmi3qPSM7p2D kvYyvMvawsabNGes1j3OrBcQJI5Oqzep9O69g9Azvq3X053UenXV3V9PycV9YfUx8urruptcz+bJ gFpMgdirHUMv6yfWPpjukM6Lb09ua0VZmXl2VhlbHQLTWxjnOe6J26BJT2CSZo2tA5gRqnSU4HVP rx9W+lZlmFl5LvXoaHZAqqstFQdx6jq2uDVq19Twr+nnqWLa3IxfTNrbKiHBzWiTHms/6vdMv6fk 9YZfUNmVmvyqciQTYy5rXbXaz+jdLR5QqHV/q/m9OGVn/Vmts5Vbxm9JkV1XlwI9Ws8V2j4Q7ukp 6Dp2bV1Hp+L1CkObVl0131tfAcG2NDwHQSJgqys76u41+J9X+mYmQz078fDoqtYYO17K2tc3TTQh aKSlJJJJKUkkkkpSSSSSlJJJJKUkkkkpSSSSSlJJJJKUkkkkpSSSSSlJJJJKUkkkkpSSSSSlJJJJ KUkkkkpSSSSSlJJJJKUkkkkpSZrWtENAaPAac6p0klKSSSSUpJJJJSkkkklPJN/xiY9jrBj9C61k MqsfU6ynED2bq3FjgHNt7EKj1/8Axg5TOjZb8Po3WcHJFZNWXkYYbVW7957nPcAPkuxxun42Lk5O RQCx2Y4WXtH0TYGhm+P3iAJ+CXU+nY3VMC/p+WCcfJbstDTtO0+BSU2kkkklPKO6t9cOoZedf0Sr C/Z/T8h2MynJ9T1sh9J23w9h2s1lrZHPkqlOZ9dOsYrvrL0zNpxcCHvw+k20td61VZcA6276TXWR IjjTzXV4XTacK/Ltpc/bm2+u+pxlrbC0NcWeG7aCfNDPSaauju6T09xwqfSdTS5nuNYcCJbvPInS UlJel59fUum4nUa2ljMumu9rXcgWND4PwlWkHDxacLEow6Btpx621Vt8GsAa38AjJKcnp+fk39e6 th3O21Ygxxj0+3VtlZe63jd7nkt1Me3TusXp+H9Y+vY9/VW9cu6e59+RXiYtVVRqqbTa+hosbY1x sJNe4691t9W+ruL1LIZmsuuweoVN9NmZiv2WbJ3bHghzHtns4GOyyqPqTmVMto/5wZ4xr7H221Ve jUS6w7rPeyuW7iZO2ElOv9W+p39U6PTlZTWtyQ6ynIFf0DbRY6mxzJ12lzJHktNVundPxOmYNOBh M9LGx2hlTJJgDxJ5JVlJTg9c+sGfidSx+kdHwR1HqF1ZyLGvsFVdVAOze98O+k7QCEulfWe27Lb0 zreE7pHU3yaa3uFlNwH+hvaA1zo128q9Z0qeu09Yqt2ObjvxciqJFjC4WVmZEFjpj4lE6r0nB6ti HEzWb6yQ5jmktex7dW2VvGrXNPBCSmv0TqeRn3dUZcGgYOc/Fq2AiWNqpsBdJOs2Faixvqx0TK6N Rm15eb+0LsvLfkuvLAx0FldYa4N03RXqVspKc/P6qcPqfTMH0t46lZbWbN0bPSpffMQZnZCzOtdW +sdnVf2N9W6MY30UtyMvKzi/0WNsc5tdbW1e8udsJniFZ+sfQs7qr8G/p3UP2Zl4Fj7Kr/Rbkfzl bqnDY9zW/RcVD6vdB6r03MzM7qnVf2rkZjKa9/2dmPtbQbSBFbiD/OnskpN0Hq2dlnIweq014/Vc HZ9oZS4uqe2wTXbUXe7a6CIOoIWus3D6bZT1rqHU7bGuOWyimqto+hXQHn3eLnPscfhC0klNHrHW umdEw/t3VLvs+MHBnqbXv9zuBFbXHt4LC/8AHS+on/ln/wCAZH/pFdB1TpuP1TBtwsmfTtGj2mHM c07mWMd2c1wBBVipr66WNtf6j2NAfZG3cQNXR2lJTzfRvrv03r31iHT+j3tycNmHZkXP9Oxjxa22 pjR+lDNNrz2XTqiemVv61X1j1DvrxX4orEbS2yyu0un/AK2rySnO+sPVj0bo+T1FtfrvpDRVSNN9 ljm1Vtnze4LFbl/4wOnNZmdQx8PqWNtnJxcEPZkM/wCK9V2yzb4aE9l0PVOnYvVOnZHT8sE4+TWa 7IMEA9wfEcrLd9c/qniRj39Yx321DY9xe1xLm6Eu2aSkphZ9YGZmf9X39LyA/B6jdkMvAAlwrx7b AxwcNzXNe3UaFdCuYwOlfVjqvXKfrF0fNa+zGc911GLY00vttrdV6ltY4ftdzoSunSUjvdYyix9T d9jWOLGeLgNB8yuS6V9ZPrd1Vr242L0xmTTAycO2+9l9JPa2s0SPI8HsV2K5f6w9T+pNt4rz+p04 nUsaRVk02huTS7ycyfm10g9wkprdBzvrnd1nqVV9WG+irMqbktN9rvSaaaXObjg1wRtO6DHuJ+K7 Fcx9Tbunvs6g+nrNHWMnLubfY6oNY8NbXXQ0vra7mGakACey6dJSlyOGz6z/AFlxm9Wo6v8AsrBy Wudh4uPQx79m6K33W3SZIEkNA5XXLher1YPR81+NR9bj0XGsc623pxFVrm+pqfRc+X1AmTGvlCSk vT+pfWbpnRaOu5+a3qmAGg9SpfU1l1O0+nc+mymA9rHCdrmzHeV2gIIkagrmMK36o9V6H/zX6V1K qyn0BjiuuxpuNYjfo7UkjkgLpwAAAOBwkpdcuHfWH6wZeU/B6kOk9Nw8i3EDaqW232vp9ljnPulr Bv4Ab2XULnuofVjqD8y3L6L1i7pP2p4sy6RXXfW9wG0uY236DnACSNPJJTmdOP1yxcTKzB1JvVXd PvuqyMG+pjDYyp0g03VbS17qyDDgRK63BzKM/Cx87HO6jKrZdUTodr2hzdPgVSwOj4/S+j24Lb3n eLbMjMtIL3WXFz7LnaBvJlWekUYmN0rDx8F4txKqK2Y9gIcHVtYAx24aGRrKSm2uZy7vrJ1Trmbi 9Iz6unY3SfSZY2ygXm+22sXEOl7Sxga9uo1mV0ywus/VqnPynZVXUcrpduQwUZBxbGsFrRO2Q9ro cJMObqkpy+nZXXvrW7Iuqz3dGp6e92I+vFFVxflV/wA89zrA79GD9AQCRqt76t9Rv6j0irIyYOSx 9tF7miGusosfQ57R2DiyVi9S6L03pLsWjpfXG/Vuy1jKBSTU4Xsr9rYZkH+c1jeNfGV0PSOm4/Su m0dPxi59VDY3vMve5xLnvee7nuJcfNJTcWSc/J/50jpznbMUYPrsZ7f0lht2O5G79G0Dgx7tey1l idfxug5uRi4udljC6kNz8C6u0U5DSdHekfzge7SCD3CSmg2jrfXeq9Uczq13TcXp2QMTHx8dlclz aq7XW2Osa/duNug8lo/VjOz8jHysPqVjb83pmQ7EuyWN2NthrLWWbB9Ellg3DxlZ9f1M6hVffdX9 Yc5n2stdeWtoDnOa0Vh24Vc7QBMLb6P0fC6NhDDww8sL3WWWWOL7LLHnc+yx7tXOcUlN5Yf1i6p1 XHyMDpfRWUnqHUXWFtmTuNVdNAa615DILj72gDzW4qeZ06nKycPJc91d+FYbKnMMSHNLHscDy1wK Snmbc/665mZ/zbFuN0/qLGHKv6pQw21/Zi4Mp9Om7h73bg6Tpt05Wr9Xc7q32rN6N1mxmTm4DarG 5lbBW26q8P2uNY0a4OrcCBp4K5nXdD6Zk/tXqF9OHdbW3GF99grDmNc6xrBvcAYLiUumYeL9qyur 0ZAy/wBpemWWsLSwVVN21src2ZbJc6fEpKdFYX1wyc+jp2Kzp+ScPIyc7FxvtDWteWtutFbjteCD yt1Z/Wen0Z1FByLvQrw8mnML9AP1d4tAcXaAGNUlOQ7rP1o6KQ3rPT/2nhjQ9Q6aCbBqADbiO93f UsceFsdJ690jrNRt6blMyA36bAYsYfB9boc0/EKg769fU9jtp6vjSPB4I+8SFd6eOg5156z037Nk XWMNLsyja5zmyHFjns8wNCkp0VT6xk5mJ0zJycDH+15VTC6nHE+9w/N0VxJJTyXTOvfW7qtByMCn pNzGnZY0ZF4ex45ZYx1Acxw7hwlL6nZv1syQ85zMZ+EMvMZbd61r7mltto2VtdXBY142tk/R+5bH U/q9i5twzcex/T+pNEMzsaBZA/Nsa4FljfJ4PlCj0LCHRMSvAzcuu7My8jIua4D0vUfa9+Q8V1lz j7QSeUlOuqvVM5vTum5fUHtL24dFl7mjkipheQPuVpRsrZbW6uwBzHgtc08EEQQkp4y/q31q+r/S m9f6vl4/Usa5rDZhV1No9B1wArFVxf72h5Adv7azorLmfWLov2Lqef1V2aMnIpozcI11ilv2l4qH oFoDh6bnDkmQjYv1M6WzKqGTnZPUcfDDhi9PybWvqq3N2TtDQ5xaw7W7yY+Ki36snEy8R/Uut3X9 Lxb6j0/AyBW0C4Etoa+6N9sOI2A6yBykp6hJJJJTxXRc367u6ceq49lHWKbLskfYLox7mim+ylra r2gtMhn57fmtfp/1y6TlZAwswWdK6gSR9kzm+k5xBI/RvPssGmm1y0Oi9Mr6V05mFVYbWNfbZvMA k3WvuI08C+FXuyfqv119nSbrsPqNjJ9TEL67XtLTDjskkFp+5JTrJJJJKcnpPVr8t3VzkNaG9OzL MerYCCa2VVW+6SfdLyufwz9fMzAr+stfU6GV31fa6uiGhpqNLm72VnJ0s3Fsaxz5K/m/UPGys3Ky 6ur9VwvtthtuoxMkVVF5a1hOwVnkNHK129Nqw+gjpVF7qasfF+zV5L9rnsYxnpiw6BsgCeISUn6d nVdR6fjZ9MirLqZcwHkNsaHCfvVlVOlUYeP0vDowXCzDqorZj2NO4OrawBjg7vLdZVtJSkkkklKS SSSUpJJJJSkkkklKSSSSUpJJJJSkkkklKSSSSUpJJJJSkkkklKSSSSUpJJJJSkkkklKSSSSUpJJJ JSkkkklKSSSSUpJJJJSkkkklKSSSSUpJJJJSkkkklKSSSSUpJJJJSkkkklKSSSSUpJJJJTzf1m6n 9acTqWBi9FZgijND2G7OFxaLm+5tc0HTc0GJHbnhA/8AXp/+aH/2cXUvrrsAFjQ8AhwDgDqNQdfB SSU8x9Rf2hs63+0/R+2/tSz1/s270t3oY30PU90fFdOosrrZuLGhu87nQAJce581JJTzX1tblZmf 0fozcq3Bw+oW3fab8d2yxxpr9WuhrwPbv9xn+TCE7pHWvq2XZnSMrJ6thA7sjpeW8227e5xbXahw 52Oncumux6L9hurbYaniyvcAdr28ObPBCIkp5b6s9TwuqfWbreZhWC2l+PgA9nNcPtO5j2nVrm9w V1Kr4/T8HGyMjJx8euq/LLXZNrGhrrC2Q0vI5iSrCSnB+uOa7BwcHI9c41beo4Yvt3+m0VG5vqb3 SPbt+lOkLM6q7ov1v67hdGGdXm9Krx78vLx8S8FtljH011NtdS7dA9QuAkarqsvCw86g4+bRXlUE gmq5jbGEjg7XghAwuh9F6fab8Dp+LiXFpYbKKa63FpIJbuY0GNElON0fp2P9XfrE3ovTN7emZeJZ lNxXvdYKbara2F1ZsLnAWC3UTyF06CMPGGW7NFY+1PrFLrvzvTaS5rPhLiUZJTi/XKjKyPqxn1Yr XWPcxvqV16vfSHtN9bAPzn1BzQq3TvrD9Q6sStmHm9PxKg0AUufXQ5o/ddXZtcD4yFvZGTj4tL8j KtZRRWJstscGMaPFznQAufy83/Fxm3G/Nv6Lk3EQbLn4tjo/rPJKSmo3N6LnfW3ptn1dfVffWLf2 pfibTX9mNbtjbns9pPq7dvfntK7Bc7j/AFj+r1PUOm9H6G/CvZmvsY5mHbVFTaqX3B3p0zodm3su iSU1OrV5lvSsyvAdszH0WtxnntaWOFZ4PDoXN/VnrP1HwekY2NXdidNuqra3Ix8osx722gQ8Wi3a 4unv3XWW2V01vtscGV1tLnuPAaBJK4rI+tH1b6n6ef1P6u33dNcSKuq5OHXbUGf6Q7tz2sMcwkpL 1fqP1fz+pdLb0G2jK6yzLqc2zDLHlmOHD7V6r69PT9OdD3iNV2aw7cvpPRcDCv6Ri4/2XPysfHZ9 mDK69uTYGeo302w6N0+a3ElKXE/VTqP1Z6XhOxer3Y2F11lth6k7L202W3F7nOtD7du5j+WkaQu2 XJZf1m+q/VQW5PScnqddL3MD3dPfkVh7CWO2u2OboZGiSmv9bOrfVfO6c6npeRjZvXHOb+yxhuZZ eMmf0bmurJ2gfnSYjldo2do3cxrHiuH6d9aeiYHV8jFweh34mMKKrWjG6dZXcbHusa82MYweyGt2 mPFdykpS47Iw/rrlfWDOxaevnp2MNt2Cz7FRe11TtHN9R+125jtCD2g/DsVzeR9bctubktxOkX5n S8B7qszqFVlftewA2CugnfZsmHbdZBEJKaOd9XvryMLIL/rX6rRU/dWOnY43DaZbIdIlb31WY+v6 sdIrsaWPZg4zXNcIIIqYCCCst/1q6rl+vmdC6dX1DpGKSHZJvDH3Fmtn2Zu1wcG8akSV0WJlUZuJ TmY7t9GRW22p3i14Dmn7ikpMuQyPq90vrv1q6pX16r7V6NFA6fS5z2tbRY0+q9m0t95tDgSONF16 oYnU2ZXVM/BZWB+zvSY+2dS+1nqlu3bwGlpmdZ8klPPdC+qHT8hmfb1/F+3XjIsxsezNbvc3Eo/Q 0bHP/ea3cXDkklaf1JdYfq3i73utra65mNY4yXY7bbG45J7/AKINVIfWH6zdQbk5HSej0ZXTarLa azfkCu3I9FxreWN2Oa0F7XAbit3o3UMXqXTMfNxGGqmxsClw2urc0lj63NHBY4FpCSm6uX6r0zp/ VPrnj4nUMevKx3dKyCa7GhwkZGPqPA+YXULE659YsTpObjYzMO7qHU8prvSoxWB1gqafc9znFoay fPlJTT/5t9d6Q42fVzqbn441/ZnUi6+r8321Xz6tY0P7w1Wx0fN6hmYrn9RwXdPya3mt1Re2xroA PqVvZy0zpOqrdE+tGB1e1+J6d2D1CobrMDLZ6V4bMb2tk7m+YVjpPVT1G3qFZq9L9n5bsSd27ftr qt38CP5yISU6C5X649UwekdV+r/Ueo2+hiUZGR6tu1z4341rG+1gc7Vzh2XVKnl9UoxM7BwbGuNn UX2V1ObG0Gqt1x3yR+azskp5XpV31Z+uf1mzs0BnVcTBxcerGZfW41sfa+91xFV7QNx2M921af1e x6MDr/WemYDBV0+luNc2hmjKr7m2eqxg4bLWsdtHjPdE659ZM/Ez29K6L0x/V+oemL76xY2iuqok taX22DbucQYb81a6B1ZnUq7xbiO6d1Gh4bnYj9pc17mhzXb2aPa5v0XJKdVc59eamv6VjPyK3X9N pzKLep0saXl2M0mfY0Eua2zY53kCujQMzOwsCn7RnZFWLTIb6tz21sk8Dc8gJKcij6x/UhtIbT1H ptdUQGC2lmnhsJH5FR6LkdMy/rdfkfV8sfgfZC3qV2PHoPyd7PQgt0dYGb5I7RPZFvv/AMWeRa67 Is6Hda/V9ljsRzieNXOklW+nfWPpGT1lnRekvxsigYlmS63FtY9rCyyusVllUgT6k8pKdxUutV9T s6VlM6TaKOoGs/ZbHAOAeNRIeHDXjUK6q3UeoYvTMG/PzH+nj4zDZa6J0HgByUlPK9O6V9ec/Cpy 2/Wt1XqtBdVZ03HD2O4cx3v5adFEdI+suJ9aOg29U6wesUC7JhoxK8cVk4to3l1RPMxqrtH19xN1 Tup9Ozuk4uQAas3LqDaNT7RY9rnbCe25a+d1b7L1HpeE2sWN6nZbX6m6NgrpffIEHdOyElOiqvVT ljpeYcGPtnoW/Zp49XYfT/6UK0oXWsopsuf9Cppe6OYaJKSnjOh/Ub6sZ3QsHPobdV1C2pt/7SbY 5uUL3j9I5ztxG4OkFpkIPWupdTxndL6J1xpflHquCcPPY2K8mtl7CS7bpXa0fSbweQtej699KupZ bj4XUrKbBurfXhXOa4HWWlrYIKD0v67U9Q6nk4V2BlhteVXViu+yWjYH11ndkFwIrIc86mPbBSU9 Wkkkkp8vb9duhdP+pmf0b7c6jrDft7GVNrt3B9l97mRY1m0GHDXdot/6w/Vv6v8ARvq1bm9Nw6cX N6dWyzCyq2BtxuaWioGwe95sdDSCTMq1R9dLbHHMs6XdX9X95YzrHqVuaQHGv1XUg721SPp+GvCE /wCtPUbaD1Z/Sq3/AFca8EZL7R63oh0fahSWbdg+kPdMapKerbO0btDGo806bnUJ0lPHZGH9dcr6 wZ2LT189OxhtuwWfYqL2uqdo5vqP2u3MdoQe0H4NnfV768jCyC/61+q0VP3Vjp2ONw2mWyHSJVr/ AJ5ZVWdnsyOlX2dNwcg4rs7F/TFrmsZYTZQ0bwIeNWytrpXW+k9ZxxkdMyq8qvvsPubImHsMOade CElIfqsx9f1Y6RXY0sezBxmua4QQRUwEEFaiSSSlJJJJKUkkkkpSSSSSlJJJJKUkkkkpSSSSSlJJ JJKUkkkkpSSSSSlJJJJKUkkkkpSSSSSlJJJJKUkkkkpSSSSSlJJJJKUkkkkpSSSSSlJJJJKUkkkk pSSSSSlJJJJKUkkkkpSSSSSlJJJJKUkkkkpSSSSSlJJJJKUkkkkpSSSSSlJJJJKUkkkkpSSSSSmt 1Lp+L1PAv6flt34+Sw12N40PceY7LK6d9Tug0YVNOb0vp+RkVtDH3jFpG/boHkemIJGp81vJJKcF 31S6XT1fpvUem4mLgnBfa670aWVusbZS+kNmto4L51W8kkkpr9Qw68/AycG3+by6bKHxztsaWH8C g9GxsrG6RiYedsfkUUsptNf0HFg2bgIbG4CYhXkklPI9R+qGdVmYg6LbXX0s5+Pm5mDbO2s02C1z 8Ut+jvjVh0niF1ySSSlLFy/q4GZL+odFvPTM+zW3aN2Pcf8Ah8eQ0n+W2Hea2kklPOdEp63Z9Ys7 P6rhtxJxMfHa6uwW1WOrsve51Z9r4h4+k0Lo0kklKXK5HSfrZiWZuH0SzErweoXPvGVcXm7Hde7d ftrALX+4lzNRqV1SSSnkB07609Cwj0PoWLTndPe1zMTKyLyx2MHgki5ha42NDySNvbRdJ0rAZ03p eJ05ji9uHTXQHnk+m0Mn5wraSSlLC6j0vrNHU39W6FbSbMhjK8vBytwqt9OdljLK5LHgOg+0giOI W6uZ6v8AWfr2J1x3SOmdC/aLm0tyG2nLrx9zCdri1trNdrtDB8PEJKanS6Pr5gYtuBj4OBUx111t V1mQ97axfY64jYyppdtc8xwuh6D0o9I6VTgvtORa0vsvvI277bXutsft7S5x0WJ/zi+vf/zo/wDw yx//ACKufUbJy8v6s4+RmFxyH25XqB7/AFHNIybm7N/faBtCSnfWVZ0q8fWarrNJaa34jsPKY76U Nf61LmaHglwI058lqrnOtP63n9fp6N03NPS6KsX7Zk5La22PsLnmplTPUBaNu2XfJJTo9a6Hi9Xq r3udj5eO71MTNqgW0vHdpPIPdp0IVT6p9M6v0+nqDusOpflZma/J348hhaa6qgdrtWk+nMLFpwPr F17NyekdS6vfi19E9OuzJ6eRj2ZN1rfWbY+N20Nrcz2jTdPktz6rZWdZTm4Gfb9pv6XlOxftRABt Zsrure8DQO22Qfgkp21g/WbpnXMvI6bm9DdijL6dbZZtzTZ6ZFtT6T/Mgu4f5LeWJ1nMsxeudEFl 3o4N1l9dh3Fodea/0DHQYII3mHdwO6SkX1d6d9ZKep5/UuvnCN2XVj01NwTbtAoNxO71hOvq+Kt4 PT8mvr/U+pXBrKsmvGoxwDJc2kWOc93hLrYA8B5rKzemft3605eHn5OTXh4OJjvx8ai51LXuvfdv tf6Za5xb6QA1Vj6tG3D6p1Xof2qzOxcH0baLb3+pZV64eXY77OXbNm5s6w5JT0SzfrB0XG650u3p +RA3w+p5aHBljDuY/a6QYPIOhGi0li/WrN6lj4WNj9LeKMzqGVXiV5Tm720h4c51hadDAZAnuQkp lT9U/q36TPW6N071do9TZjVbd0axLOFDE+q+BgfWBnVen4+Ph0jEsxrKaKm1Fz32V2B52ADQVwsX Mx/rVTnY31cs6w+6rq3qWDqLa2U5NNWO0etWw1+2Xueza6JGvkr3Rac/onXW9Ctzr+p4eTiPyse3 LdvvrfVYyt7C+Bua4WgjwhJT06zPrH0l3WOiZXTq3iu21rXUvcJaLa3NtrLhrI3tErTWP9br8nH+ rubfjPdU6trXWWMLmubSHt9dzXM9wcKtxBCSnT9P18b08utjvUYBdV9Jkke5vuGoXMUfVTqWD17p bsO9tnQcCy+5lFxJuoNtNlIqqd+dXL9AdWqz9ZXO6g7ouDj5VlGB1PJLb8jFs2OexlFt7K22N1Ae 5msFV6sFv1c+sXTMXAy8i3G6p6tV+BkXOvDfSrdc3Ir9Quc2CNjux3BJT1aYgEEESDoQU6rdTyzg 9Ny81rDacWmy4Vt1LjW0v2j4wkpy7fq9fgWPyvq5cMN7yX2dPsl2HaeTDBrS4/vV/NpTfVijqgye r5nUsT7FZmZTHsq3tsBDKKai5rmctLmGJAPksvp/T/rvfgY3WKuu13ZOQwZBwX0s+yObY3e2ptjP eAAfpiVLqH1lfm4uHSBZ0/qmP1TBpz8LcQ9ofc1phzY31WDg8EJKewSSSSU8d/zd+s/2IfVptuLX 0CTU7KBeco4ZJPobCNocW+zfu415TZnTPrbbgO+qzceizpljBj/td10PbjSG7XUFpcbRXpMwTqhM 6j9bR1F+B1DqlHSr32OGI27D31Wsk7PSyBc1jn7eWGHeXdRx8D63H615tbesY4yRg4zrLfsctcw2 ZGxoZ62had2s90lPcAAAAcDQJ0kklOT0Lp2Tg3dWfeABm578mmDP6N1VNYnwMsKF1P6odG6hecxt bsHqPLc/Dd6N88e5zNH8fnArOq6dlfWbMzcjN6jmYmLh5duJRgYln2cFtXs9S5zPe4v+kNQIhUul dH6njYWbldK6vlWZfTsnIqFWTab8a9tLy5tb22SWHadhcwiCkp7TGqspxqqbLXX2Vsax9z4DnuaI L3bYEu50RVV6Xn19S6ZidQraWMy6a72tdyBY0Pg/CVaSUpJJJJSkkkklKSSSSUpJJJJSkkkklKSS SSUpJJJJSkkkklKSSSSUpJJJJSkkkklKSSSSUpJJJJSkkkklKSSSSUpJJJJSkkkklKSSSSUpJJJJ SkkkklKSSSSUpJJJJSkkkklKSSSSUpJJJJSkkkklKSSSSUpJJJJSkkkklKSSSSUpJJJJSkkkklKS SSSUpJJJJSkkkklKSSSSUpJJJJSkkkklKSSSSUpJJJJSkkkklKQrMXHtvqyHsBuo3elZ3buEOHwK KkkpSDiYmNhUDHxaxVS0ucGN4l7jY8/NziUZJJSlXswMWzNpz3M/WqGPrrsBIOyyC5pjkS0HVWEk lI2UUssstZW1tlxBteAA5xaNrdx7wNEHA6dj9Prsro3H1rX32vedznWWHc4k/gPAK0kkpSr52Bhd QxX4mdSzJx7I31WAOaYMjQ+BVhJJTzR/xf8AQRaLWWZtZDdgDcy/6EzskvLo8pWx0no3TOjYxxun UCitzi98Euc955e97iXOPmSrqSSlKvnYGLn0ehlM31h7LG6kEPrcHsc1zYIIcJVhY/1s6d1HqPRb aem5N2LlsLba3Y9hpe/YZdV6jfo7xpPikp1HUUvtZc+trrag4V2EAuaHRu2ntMaqiB01n1hMvcep 34ktYZLRj1WAO26bRL7BPc/JYdP1F9Wpln/OH6wM3tDtj82HCRwR6fIUuj/VjJ6R9bG5IzM/qOK/ p9tbsjPu9bZYbqXNrYdrYkNJSU9YovLAxxeQGAHcXcR3mVJYv1yw8rN+rHUMbEa6y59YPpM0dYxr mvsqaddXsBb80lOJR0L/ABe9XyTR0vNa20O9VuNgZjmNDm/n10sftHxaFr4PRvq50HqNHpteepdR 3005F77L7XBjDc5nqWF20bWE9lK/6p/VzPwaWMwmYuxjTi30N9C+nSWlj2bXtI8PvWOD19v1m6D0 /qlL8k4duTY3qtTf0NtRxra2m2P5u2SARweySntFC01ip5tgVhp3l3G2NZ8oU1W6ixz+n5TGAue6 mwNaNSSWmAElIcQ9K6b0et+PayvpdFIfVaX7qxTG5pDyT7Y414WFj9T+of1y6njPouZldR6Y9uRj EtspsGw7ht3tZvaCJI1WIzqd/Ufq/wBG+rV3QeqsNb+nU5ll+IW45ZRZT62524+yGHlvxXU/WmgO HSjj1zmM6hjDHexsljN36fUD2s9HfPb5wkp3kkkklPN9W+tP1Ytff0m+uzquw+nk4+PjvymtdwWv LGubuB7TIWf9W836t4XV7BXkZ9ORmsrxsajqddrAG1F721VW3sk6vMBzyfBR6P8AWPpn1R6ZX0n6 wtuwL8ex7DlOpssqySXOcL22VNsk2DUg6gpus/WnpH1p6Tf0n6vtt6ll5JFdNrabWVU2SHNufbYx oZ6f0p58ElPbpJmghoBMkDUp0lPEfWdv1T/a7wczqGP1V2x2ZT0d1pe8NHs+0Mpa9olp5MOhWenf WD6q4OC3o4qzOmY1m6sWZdF9Qc60nc519jfpOLuXHlQx+s4f1TyuqM67VdRTlZlmVV1MVPtqtruI LGOfUHlrqvoQ7sBCfL+vn1Y6vhZOD0xt3WbrqzX9kqxriHF4LQHmytrWjzKSnqsTGoxMWnFxmhlF FbaqmjgMYA1o+4Iyo9DxcnD6NgYmY/1MnHx6qr3yXS9jA1x3HU6jlXklKSSSSUpJJJJSkkkklKSS SSUpJJJJSkkkklKSSSSUpJJJJSkkkklKSSSSUpJJJJSkkkklKSSSSUpJJJJSkkkklKSSSSUpJJJJ SkkkklKSSSSUpJJJJSkkkklKSSSSUpJJJJSkkkklKSSSSUpJJJJSkkkklKSSSSUpJJJJSkkkklKS SSSUpJJJJSkkkklKSSSSUpJJJJSkkkklKSSSSUpJJJJSkkkklKSSSSUpJJJJSkkkklKSSSSUpJJJ JSkkkklKSSSSUpJJJJSkkkklKSSSSUpJJJJSkkkklKSSSSUpJJJJSkkkklPLW/4zvqPVY+qzqUPr cWuHoZBggweKlR6x/jW+q9XTMmzpOc2/qDWE41VlF4a5/YGa2D8V1XT+l1dPuynY7iKMu31/Q/NZ Y4fpCzwDz7iPGT3Tdb6XX1jpWV0y15qZlsNbrGgEgHuJSU3kkkklPL3/AFo69kZ2bT0Ho7eoYvTr DRdfZkNo33M/nK6gWunbwSe6vYP1lx+oYOW+pj8bqGFW52Rg5Ddttbg0kbm/nMMaOboVa6X0r9m3 57q7d1GdkHKZURHpvsaBaAZ4c4buOSVW+sP1br6uz18a44PVK2OrozqxJDXiHV2NOj2O8D8Qkpt9 DzbeodF6fn3houy8Wm+wMBDQ6ytr3bQSdJKvKn0jBPTek4XTy/1Dh49WObAI3ekxrN0axMK4kpSS SSSlJJJJKUkkkkpSSSSSlJJJJKUkkkkpSSSSSlJJJJKUkkkkpSSSSSlJJJJKUkkkkpSSSSSlJJJJ KUkkkkpSSSSSlJJJJKUkkkkpSSSSSlJJJJKUkkkkpSSSSSlJJJJKUkkkkpSSSSSlJJJJKUkkkkpS SSSSlJJJJKUkkkkpSSSSSlJJJJKUkkkkpSSSSSlJJJJKUkkkkpSSSSSlJJJJKUkkkkpSSSSSlJJJ JKUkkkkpSSSSSlJJJJKUkkkkpSSSSSlJJJJKUkkkkpSSSSSlJJJJKUkkkkpSSSSSlJJJJKUkkkkp SSSSSlJJJJKUkkkkpSSSSSlJJJJKUkkkkpSSSSSlJJJJKUkkkkpSSSSSlJJJJKUkkkkpSSSSSlJJ JJKUkkkkpSSSSSlJJJJKUkkkkpSSSSSlJJJJKUkkkkpSSSSSlJJJJKUkkkkpSSSSSlJJJJKUkkkk pSSSSSlJJJJKUkkkkpSSSSSlJJJJKUuE+rn176pnfWWzpnUqqGYV2Tl4mDZU14f6uJseWv3OcNa3 j5ru15PRiXu+rHWuq4k/a+ifWHI6hVBiRUKvUafLYSfkkp3frz9eur9CznU9Koouowq6rOoPuBJB vftqrZteIJDSdQuo6t9ZOi9HeyvqGT6dtgLm1MY+2zaOXbKWvcG+cQvNut4+Rk/4vM7r2TWRm9fz q8kt0Lm0h/p49UgCQ1vHxWp1R9/TPr31TJz+r2dEx86ij7HlejXbW9rGhr6d19b2tIcCYHKSnub+ vdHo6YOrW5dYwHgFl7TuDt2gDA2S4nwAlAb9augO6bZ1T7WG4lL/AErHPY9jxZpFfpPaLNxkQNsn suVf0r6r0/U3Crf1S2rCrzTk4HVPSLBXkBz3NdsDAwMndEgNOkdlXbns639Xnu+suf6DMDqLf2X1 6ilzGWPqZNd7mFu2DqJ0bOgSU9kz61fV93TbOqHMbXh0P9K2y1r6y1+h2Orsa14JBECNU/RvrR0D rtdlnS8xmQKRNohzHNHi5tjWujTmFx1f1v8ArDX9XbMu30cttPUWYtfWjQ4VfZyNcw0+3dt/kwNf JVPtDM/61dbsZceq12/Vy9otYz7O20b2tIrdBBHbcJ/BJT2lX14+qt17aK+oML7HBlRLXhtjidsV PLQ1+untJRupfWz6v9LyvsmbmCu8AOe1rH2bAYh1rq2uFY15eQuI+qubj5F31b/avUm1NwKg3p2P 9kuo9S22ptQY7Jtlj4BIGyNyEzbgdV+seD1vrb+jjOyrbPTsoqtryce0e0tsvqeTDTt2g6JKfUa7 GWMbZW4PY8BzHNMgg6ggrjPq99YvrT9ZA/qWA/Aowq8n0ndPtbY7IFTXDebHtfDbC2S0bYXR/V7G x8LoGDj4tj78eqhgpssaWPcyJbLHAEGOy84+sGV9WsrNZm/Uz7Tj/Wx1zC7Foqup3bnA2DIa5rWA fvawe6Snuv2s7H+sufTl9UoGHjYTck4HpFtlTGkb73XHRw5kDjTQd7XTfrT9Xuq5BxunZ9OTeGl5 rYZO0cn8VzFmXXgf4yerdQygTRi9DNtxaCdGvrcQPjtKy/q11Pp3X6OuZFOS131r6xi3tox2Mtb9 moazZXSy1zA3mCS06lJT3GP9b/q5lZ46fRmtfkOca2e14re8csZcW+m53k10q31rqLeldIzOpOG4 YlL7Q3xLWkhvzK826I3ped0vpHSuodetqyMS6nZ0c4tbbasit2jQW0+rydXTxyu2+v1Nl31N6syt xa4Y5eS2J2sIe4a9iGwUlOTlfWLrXRv8W+N111rczqVtdFzrMhvtP2hzXRtr9P6LXQFbx+u/WPB+ s2F0LrLcXKZ1Kux9N+G2xjqzUC53qsse/wBp7ELL+vWQzL/xWVZNc7LqcN7QeQHGswYVDp9nSLfr R0vI+olmTkbrDX1i237Q+j7MNpIe7KE74nZHdJT32L17pGXiZWZRktdj4L7K8uwgt9N1OtgeHgEb Vh9Q/wAY3Q8PqXS8ZtrH4nUa3XW5b3Or9GvZvpcWOZJ9TjsuZ+ttWd0vrvUPq/gMc2j64mh1NjQC 2u42CvK9o7OZJcfP7tX63v6f9X/rB9U83Jb6HScBuTQ+0Mc5jAaWsqaQxrj20CSnqOpfWjoXS/S+ 25Qa69nqVVsZZa8sid+ylj3BvmRCpfWrqmT/AM07+s9AymF9DW5VVrYdXZWxwNjT5Fk/7Fy+fe/A +u/Uc3L6vZ0XE6lj47sHL9BlldlbWAOq3X1vDCHCdojzWmMbpvT/APFn1NnT8p2XhPx8t1V72elJ s3j2s2tAbuPtgR4JKev6fmU5+Dj51BmrKqZdWf5NjQ4c/FWFkfVGqyn6rdJqtBbY3Do3NcIIOxpg g+C10lKSSSSUpJJJJSkkkklKSSSSUpJJJJSkkkklKSSSSUpJJJJSkkkklKSSSSUpJJJJSkkkklKS SSSUpJJJJSkkkklKSSSSUpJJJJSkkkklKSSSSUpJJJJSkkkklKSSSSUpJJJJSkkkklKSSSSUpJJJ JSkkkklKSSSSUpJJJJSkkkklKSSSSUpJJJJSkkkklKSSSSUpJJJJSkkkklKSSSSUpJJJJSkkkklK SSSSUpJJJJSkkkklKSSSSUpJJJJSkkkklKSSSSUpJJJJSkxa1whwBHgU6SSliARBEjwS2tjbAjiO ydJJS0CNsacR2hVeq9Mx+qdMyOm5Bc2jKrdU81mHAOES3QjT4K2kkp5hn1Jda/Bb1PqmT1DE6ZYy 7ExXspraH1DbWXuqra9+0ea6YtaYJAMcSnSSUpNtbO6BJ5PdOkkpSSSSSltrZ3QJ8e6jdVXfS+m1 ofXa0se08FrhBH3KaSSnP6F0hnRelUdLrusyKsYFtdlsb9skhp2gD2zAWgkkkpycr6vU5f1iw+u3 3Pc7p9T68bGgbGvskPtnkktMeC1SARBEhOkkpYta4Q4AjwKzuv8AQ8fr3TXdMynvZjWPrfc1mhe2 tws2T2BLRwtJJJSzQGgNaIAEAeSdJJJSkkkklKSSSSUpJJJJSkkkklKSSSSUpJJJJSkkkklKSSSS UpJJJJSkkkklKSSSSUpJJJJSkkkklKSSSSUpJJJJSkkkklKSSSSUpJJJJSkkkklKSSSSUpJJJJSk kkklKSSSSUpJJJJSkkkklKSSSSUpJJJJSkkkklKSSSSUpJJJJSkkkklKSSSSUpJJJJSkkkklKSSS SUpJJJJSkkkklKSSSSUpJJJJSkkkklKSSSSUpJJJJSkkkklKSSSSUpJJJJSkkkklKSSSSUpJJJJS kkkklKSSSSUpJJJJSkkkklKSSSSUpJJJJSkkkklKSSSSUpJJJJSkkkklKSSSSUpJJJJSkkkklKSS SSUpJJJJSkkkklKSSSSUpJJJJSkkkklKSSSSUpJJJJSkkkklKSSSSUpJJJJSkkkklKSSSSUpJJJJ SkkkklKSSSSUpJJJJSkl8qpJKfqpJfKqSSn6qSXyqkkp+qkl8qpJKfqpJfKqSSn6qSXyqkkp+qkl 8qpJKfqpJfKqSSn6qSXyqkkp+qkl8qpJKfqpJfKqSSn6qSXyqkkp+qkl8qpJKfqpJfKqSSn6qSXy qkkp+qkl8qpJKfqpJfKqSSn6qSXyqkkp+qkl8qpJKfqpJfKqSSn6qSXyqkkp+qkl8qpJKfqpJfKq SSn6qSXyqkkp+qkl8qpJKfqpJfKqSSn6qSXyqkkp+qkl8qpJKfqpJfKqSSn6qSXyqkkp+qkl8qpJ KfqpJfKqSSn6qSXyqkkp+qkl8qpJKfqpJfKqSSn6qSXyqkkp+qkl8qpJKfqpJfKqSSn6qSXyqkkp +qkl8qpJKfqpJfKqSSn6qSXyqkkp+qkl8qpJKfqpJfKqSSn6qSXyqkkp+qkl8qpJKfqpJfKqSSn6 qSXyqkkp+qkl8qpJKfqpJfKqSSn6qSXyqkkp+qkl8qpJKfqpJfKqSSn6qSXyqkkp+qkl8qpJKfqp JfKqSSn6qSXyqkkp+qkl8qpJKf/ZCg1lbmRzdHJlYW0NZW5kb2JqDTE5IDAgb2JqDTw8IC9GaWx0 ZXIgL0ZsYXRlRGVjb2RlIC9MZW5ndGggMTANPj4Nc3RyZWFtCnicK+QCAADuAHwNZW5kc3RyZWFt DWVuZG9iag0yMCAwIG9iag08PCAvU0EgdHJ1ZSAvVHlwZSAvRXh0R1N0YXRlIC9TTSAwLjAyDT4+ DWVuZG9iag0yMSAwIG9iag08PCAvQ3JvcEJveA1bIDAgMCA2MTIgNzkyDV0gL0JsZWVkQm94DVsg MCAwIDYxMiA3OTINXSAvTWVkaWFCb3gNWyAwIDAgNjEyIDc5Mg1dIC9Sb3RhdGUgMCAvVHJpbUJv eA1bIDAgMCA2MTIgNzkyDV0gL1RodW1iIDMzIDAgUiAvUmVzb3VyY2VzDTw8IC9Qcm9jU2V0DVsg L1BERiAvVGV4dCAvSW1hZ2VCIC9JbWFnZUMgL0ltYWdlSQ1dIC9FeHRHU3RhdGUNPDwgL0dTMyA0 MiAwIFIgL0dTNSA0NyAwIFINPj4gL0ZvbnQNPDwgL0YxIDY3IDAgUiAvRjIgNzIgMCBSIC9GNCA1 NyAwIFIgL0Y1IDYyIDAgUiAvWGkxNiAxMTcgMCBSDT4+IC9Db2xvclNwYWNlDTw8IC9DczYgMTI0 IDAgUg0+PiAvWE9iamVjdA08PCAvWGk2IDEyMyAwIFIgL0ltMjAgMTggMCBSIC9JbTE3IDggMCBS IC9JbTE5IDIzIDAgUiAvSW0xOCAxMyAwIFINPj4NPj4gL0FydEJveA1bIDAgMCA2MTIgNzkyDV0g L1BhcmVudCAzNyAwIFIgL0NvbnRlbnRzDVsgMTkgMCBSIDI4IDAgUiAxNCAwIFINXSAvVHlwZSAv UGFnZQ0+Pg1lbmRvYmoNMjIgMCBvYmoNPDwgL0ZvbnRGaWxlMyA3IDAgUiAvQ2hhclNldCAoL3Nw YWNlL1ovaC9pL0wvY29tbWEvWS91L2UvYi9uL0IvYS9IL3kvby9nL00vVC9kL3YvbC9wL20vdC9m L2h5cGhlbi9jL3Ivcy9wYXJlbmxlZnQvVi9wYXJlbnJpZ2h0L3BlcmlvZC96L1gvYnJhY2tldGxl ZnQvZml2ZS9icmFja2V0cmlnaHQvSy90d28vdy9uaW5lL0MvUC9VL2svQS9vbmUvdGhyZWUvTy9T L0QvSS94L2ZvdXIvVy9zaXgvc2V2ZW4vY29sb24vemVyby9zZW1pY29sb24vRS9HL04vUi9zbGFz aC9xL2VpZ2h0L0YvcXVvdGVyaWdodC9xdW90ZWRibGxlZnQvcXVvdGVkYmxyaWdodC9nMjk5L2Vx dWFsL2FzdGVyaXNrL3BsdXMvZW5kYXNoL2ovZ3JlYXRlci9icmFjZWxlZnQvdW5kZXJzY29yZS9i cmFjZXJpZ2h0L2Jhci9lbGxpcHNpcy9hbXBlcnNhbmQvSi9RKSAvQ2FwSGVpZ2h0IDY2MiAvQXNj ZW50IDY5NCAvRmxhZ3MgNCAvSXRhbGljQW5nbGUgMCAvRGVzY2VudCAtMjE1IC9YSGVpZ2h0IDQ0 NyAvRm9udE5hbWUgL0JOTElERytUaW1lc05ld1JvbWFuUFNNVCAvRm9udEJCb3gNWyAtNTY4IC0z MDcgMjAwMCAxMDA3DV0gL1R5cGUgL0ZvbnREZXNjcmlwdG9yIC9TdGVtViAwDT4+DWVuZG9iag0y MyAwIG9iag08PCAvSGVpZ2h0IDM0NyAvQml0c1BlckNvbXBvbmVudCA4IC9TdWJ0eXBlIC9JbWFn ZSAvTGVuZ3RoIDMzNTQ4IC9JbnRlbnQgL1JlbGF0aXZlQ29sb3JpbWV0cmljIC9XaWR0aCA1ODYg L1R5cGUgL1hPYmplY3QgL0ZpbHRlciAvRENURGVjb2RlIC9Db2xvclNwYWNlIDEyNCAwIFINPj4N c3RyZWFtCv/Y/+4ADkFkb2JlAGSAAAAAAf/bAIQADAgICAkIDAkJDBELCgsRFQ8MDA8VGBMTFRMT GBcSFBQUFBIXFxscHhwbFyQkJyckJDUzMzM1Ozs7Ozs7Ozs7OwENCwsNDg0QDg4QFA4PDhQUEBER EBQdFBQVFBQdJRoXFxcXGiUgIx4eHiMgKCglJSgoMjIwMjI7Ozs7Ozs7Ozs7/8AAEQgBWwJKAwEi AAIRAQMRAf/EAT8AAAEFAQEBAQEBAAAAAAAAAAMAAQIEBQYHCAkKCwEAAQUBAQEBAQEAAAAAAAAA AQACAwQFBgcICQoLEAABBAEDAgQCBQcGCAUDDDMBAAIRAwQhEjEFQVFhEyJxgTIGFJGhsUIjJBVS wWIzNHKC0UMHJZJT8OHxY3M1FqKygyZEk1RkRcKjdDYX0lXiZfKzhMPTdePzRieUpIW0lcTU5PSl tcXV5fVWZnaGlqa2xtbm9jdHV2d3h5ent8fX5/cRAAICAQIEBAMEBQYHBwYFNQEAAhEDITESBEFR YXEiEwUygZEUobFCI8FS0fAzJGLhcoKSQ1MVY3M08SUGFqKygwcmNcLSRJNUoxdkRVU2dGXi8rOE w9N14/NGlKSFtJXE1OT0pbXF1eX1VmZ2hpamtsbW5vYnN0dXZ3eHl6e3x//aAAwDAQACEQMRAD8A 9VSSSSUpJJJJSkkkklKSSSSUpJRssZW0OedoJa0HzcQ1o+ZKkkpSSSSSlJJJJKUkkkkpSSSSSlJJ JJKUkkkkpSSSSSlJJJJKUkkkkpSSSSSlJJJJKUkkkkpSSSSSlJJJJKUkkkkpSSSSSlJJJJKUkkkk pSSSSSlJJJJKUkkkkpSSSSSlJJJJKUkkkkpSSSSSlJJJJKUkkkkpSSSSSlJJJJKUkkkkpSSSSSlJ JJJKUkkkkpSSSYzGnPZJTg129UxOv4eDZnuzxlVXW5dLqqmMpa3b6dlXpsD2tLzsAe90+OhVZnXs +36wVPbZt6NZVl+lVtbNn2T0g6/dBdBc9waAYIE91Z6T0Dq2FffZl52PmfbHE5lpxbK8ixsEMYLf tbmsawGGgMgfEkpq/qZ0yjPwcrGsyK6MCuypmK7JybGEP2Bob6l5DWtDNWxDu/CGunkftN/knSz5 tTB6l1kU9F6tfmG+nrNjG3YTq6211NyGOtq9FzGNslkAHe506rq1g4P1ayKDg0ZOaL+n9Kdvwcdt Rrslocyr17fVcLPTY6BtY3XUreTjWtdzX93oCjX8NfNzep5+CKxUcmoWMvo3ML27hturLpE9gNVY /avS/wDuZR/26z+9LqX9HZ/x+P8A+f61aQU1f2r0v/uZR/26z+9L9q9L/wC5lH/brP71aSSUwqtq uYLKXtsrdw9hDgY00IU0kklKSQ35FNdtdL3htt0+mw8u2iXR8ERJSkkLJycfEx35OS8VU1Dc97uA ELB6ji57Xux/UBrMPZdVZRYJ4JrvYx8HsYhJTaSSVfJzasa7GpeHF2U91dZaJALWPtO7XwYeElNh JVqOoYt9worc4XGpt/pvY+twreS1pc2xrSDLTodUPE6xgZmTZjY73usq3AuNdja3bHbH+na9gZZt dodrjCX8vs3U3UlXyc2rGtxarA4uzLTTWWxAcK7LpdJGkVlWElKSQM7MqwcO/MtDnV47HWPDYLiG iTEkIwMiUlLpKph9Tx8sxW2wHffXLmHbOPYaXy9ssEuHtBMkduVbSV+xSrP6l05jix+VS17SQ5ps aCCOQRKspJKav7V6X/3Mo/7dZ/el+1el/wDcyj/t1n96tJJKav7V6X/3Mo/7dZ/el+1el/8Acyj/ ALdZ/erSSSmr+1el/wDcyj/t1n96X7V6X/3Mo/7dZ/erSSSmr+1el/8Acyj/ALdZ/el+1el/9zKP +3Wf3q0kkpq/tXpf/cyj/t1n96X7V6X/ANzKP+3Wf3q0kkpq/tXpf/cyj/t1n96X7V6X/wBzKP8A t1n96tJJKav7V6X/ANzKP+3Wf3pftXpf/cyj/t1n96tJJKav7V6X/wBzKP8At1n96X7V6X/3Mo/7 dZ/erSSSmr+1el/9zKP+3Wf3pftXpf8A3Mo/7dZ/erSSSmr+1el/9zKP+3Wf3pftXpf/AHMo/wC3 Wf3q0kkpq/tXpf8A3Mo/7dZ/el+1el/9zKP+3Wf3q0kkpq/tXpf/AHMo/wC3Wf3pftXpf/cyj/t1 n96tJJKav7V6X/3Mo/7dZ/el+1el/wDcyj/t1n96tJJKav7V6X/3Mo/7dZ/el+1el/8Acyj/ALdZ /erSSSmr+1el/wDcyj/t1n96X7V6X/3Mo/7dZ/erSSSmr+1el/8Acyj/ALdZ/el+1el/9zKP+3Wf 3q0kkpq/tXpf/cyj/t1n96X7V6X/ANzKP+3Wf3q0kkpq/tXpf/cyj/t1n96X7V6X/wBzKP8At1n9 6tJJKav7V6X/ANzKP+3Wf3pftXpf/cyj/t1n96tJJKav7V6X/wBzKP8At1n96X7V6X/3Mo/7dZ/e rSSSmr+1el/9zKP+3Wf3olOZh5Di3HvrucBJDHtcQPH2lGSSUpJJJJSkkkklKSSTEwJ8ElOZjder uzasO7DycM5LXuxLMhrGttFcF0NZY6xh2mYsa0psfr9dubViX4mThnJa92LbkNY1torguhrbHPYd p3RY1phZnS+oftTrgz87HzMY0iynp2Lbh5TAxp/nL7rXVCrfYGw0btG+Z0HhZZ611V+TmUZmI5rL cbpuNZiZLBWHgizIuudUKg94HtG72jzOg1rQXoTX5J0s3pqB/F08T60YeTkY9f2fIpx85zmYObY1 gpvcwF0M22Osbua0ubvY2QNOy2Vx/TmZd+F9X+j/AGTIqyOk2VHOfbVZXUwYtbqvZa9oZbvdG3Y4 6arsE4ga1rRIB7juj+Fkdj2avUv6Oz/j8f8A8/1q0s3qeNcaw/7VaGm+iGAVbRN1YEfo507SVY+x 5H/c6/8AzaP/AEigptJKr9jyP+51/wDm0f8ApFL7Hkf9zr/82j/0ikpPbWLan1uJAe0tJaYIBEaF c/8A8xuk/wCmyP8AOZ/6TXQVMcxga57rXDl79oJ+OxrR+CmnRyTj8pq1soRl8wt4HN+qXU25VjcL Ge/GBit77KtxA7/Sbz8Fs1/Ufpbq2ue/JY4gFzC+swSNRIrjRdKkpJczkIAuq7LBggCdLvu89kfV kYnTH1dML77W30ZTarngB5x7G2+mCGgN3RE+MKefiZHXDgtzemOqxKMv1LqMl1Ly5govZueyqyxh bve0RuM9xC3klEZEkk62b17/AMgyAAChpoY/Q/77yb/q/kf85znW05L2NurfiZOP9i9OqprGt9J7 rmtymtkO3NrJaQfMpYXQ8mvrFGQ/porvpy8m3J6pvrJvrtbcKuHmx23c1sPaNv5shdYkh0rwI+1J 6+P8v2vK9F+r7sHqHTMvI6c197enU41uS0Ul1F1TSHFzi8PO5p2As3eeia/pvWbDn4/Tse7p9F9O QLK7bmPosuefZZi7Hvsq3Sd2jBrO3curSSOv/O/5xtN635fg81+xMXLowKK+iN6dh1Zpty8N7cdr XN+z2173NxrLGPBc5rYOp7iFnZ/1YzLMTCxrMa67BxnZbBh4/wBjscwPuLsd4Z1AOq2tq9o2kObM eK7ZJI/y/JHbwFfjbx3WugZWSLGHpz+ovswK6MLJvsp9TGtYH7/Uc54hz5bLq53HQ6K5lYPVft2V TXhuspyc7EzBlepWGNrpGMyxpaX+pvHpE/RiO86LpUkb1vxv8eJVaV4V+x5LK6F1SzGya20S6zH6 zWwb2CXZl7bMcfS/PaJ8u8Kv9YOm0dHws99OPVj4OScHc0hhpfa213rG5lltLDubtDy97Q796V2q SHQDt/G0k39sj9ZPP/UhmA3oc4Nba2WX2vs9NlTKy9ztzvS+z2317B9FsWOiImQugSVZ+Le5xcMy 5gJJDQKYHkN1RKJNoH7S2UlV+x5H/c6//No/9IpfY8j/ALnX/wCbR/6RQU2klV+x5H/c6/8AzaP/ AEil9jyP+51/+bR/6RSU2klV+x5H/c6//No/9IpfY8j/ALnX/wCbR/6RSU2klV+x5H/c6/8AzaP/ AEil9jyP+51/+bR/6RSU2klV+x5H/c6//No/9IpfY8j/ALnX/wCbR/6RSU2klTfjW1sL7OoXMY0S 5zhQAAO5JpXO/wDPDAn+kZ8ePp4v/kUDIDc0vhiyZL4ImVb09ckqv2PI/wC51/8Am0f+kUvseR/3 Ov8A82j/ANIorG0kqv2PI/7nX/5tH/pFL7Hkf9zr/wDNo/8ASKSm0kqv2PI/7nX/AObR/wCkUvse R/3Ov/zaP/SKSm0kqv2PI/7nX/5tH/pFL7Hkf9zr/wDNo/8ASKSm0kqv2PI/7nX/AObR/wCkUvse R/3Ov/zaP/SKSm0kqv2PI/7nX/5tH/pFL7Hkf9zr/wDNo/8ASKSm0kqv2PI/7nX/AObR/wCkUvse R/3Ov/zaP/SKSm0kqv2PI/7nX/5tH/pFL7Hkf9zr/wDNo/8ASKSm0kqv2PI/7nX/AObR/wCkUvse R/3Ov/zaP/SKSm0kqv2PI/7nX/5tH/pFL7Hkf9zr/wDNo/8ASKSm0kqv2PI/7nX/AObR/wCkUvse R/3Ov/zaP/SKSm0kqv2PI/7nX/5tH/pFL7Hkf9zr/wDNo/8ASKSm0kqv2PI/7nX/AObR/wCkUvse R/3Ov/zaP/SKSm0kqv2PI/7nX/5tH/pFL7Hkf9zr/wDNo/8ASKSm0kqv2PI/7nX/AObR/wCkUSmi 2pxL8iy8ERteKwB5/o62FJSZJJJJSkkkklKSSSSU1cbqvS8vItxcXMovyaJ9amqxj3sg7TvY0ktg 6apU9V6XkZdmFRmUW5dMm3GZYx1rNpg7mNO4QT3Cw62t6n1KvI6TW2vp/Rab6ce9jQ1lt9jfTNdO 3/B17dSNC7QcFZlQYfq99UziAHP3tdWW/S3mi37UTH8qd/n5oXpf93/nEgH8E1qR/e/5ounr6eq9 LyMuzCozKLcumTbjMsY61m0wdzGncIJ7hWlxWCMc9G+p5qAOX61ZBb9OTTZ9rJjznfPddqnEVY/d Jj511/FF7eI4vtvT8Gr1L+js/wCPx/8Az/WrSzepvzvTAFNRrF9G1xtduP6avbLfS0k86qx6nVP+ 49H/AG+//wBIIKbSSq+p1T/uPR/2+/8A9IJep1T/ALj0f9vv/wDSCSm0khbLLsd1d4FbrGua8VuJ gGR7X7WnjyWWPqtggAbyY7mjEJ+ZOMgSegtfGMT80uH6Wkv+tHQqLn0W5O2ypxY9vp2GHNMESGEL SptrvpZdUd1drQ9juJa4SDquAzPql1s5d5oxt9Jseanb6my3cdp2hzQNO0BdHhfVbHGHQLztuFbB a30cV0O2jcNzsdxOvckpkZTJNxbGXDy8YxMctk77S/AbOxm5uPgYz8rJc5tLIDi1jrHS4hjQGVtc 4kkxoFTb9Yukuxr8n1LGtxS1t9T6bm3tNhArnHdWLffPt9uvZVc3ohxemZDMBj8m2yzHs9EejXIp tY8hjWimsGAeeVVzum9U6q/KzPsr8B9jMXHoY51Lr4qyBfZa7Y62n2g+wSe+msJ4vq1pAA6G9vr3 d3A6lh9RqfZiucRW812MsY+qxjwA7a+u5rHtMEHUcKGJ1jAzMmzGx3vdZVuBca7G1u2O2P8ATtew Ms2u0O1xhAo6G7HY70eoZTb7rvXysmKDZcQ1tYa8OoLGtDWgexrVkX9N6zYc/H6dj3dPovpyBZXb cx9Flzz7LMXY99lW6Tu0YNZ27kf4fjS3+P4PR5ObVjW4tVgcXZlpprLYgOFdl0ukjSKyrC5r9iYu XRgUV9Eb07DqzTbl4b247Wub9ntr3ubjWWMeC5zWwdT3ELOz/qxmWYmFjWY112DjOy2DDx/sdjmB 9xdjvDOoB1W1tXtG0hzZjxSKu3l+Nl6/OzKsHDvzLQ51eOx1jw2C4hokxJCMDIlcf1roGVkixh6c /qL7MCujCyb7KfUxrWB+/wBRzniHPlsurncdDormVg9V+3ZVNeG6ynJzsTMGV6lYY2ukYzLGlpf6 m8ekT9GI7zojWteNX9a/tV0+lu1h9Tx8sxW2wHffXLmHbOPYaXy9ssEuHtBMkduVbXJZXQuqWY2T W2iXWY/Wa2DewS7MvbZjj6X57RPl3hV/rB02jo+Fnvpx6sfByTg7mkMNL7W2u9Y3MstpYdzdoeXv aHfvSgdh46fUmkka6d5fYHtUlz/1IZgN6HODW2tll9r7PTZUysvc7c70vs9t9ewfRbFjoiJkLoES KQP2lSSSrPs6iHEMopLJO0m5wJHaR6Jj70FNlJVfU6p/3Ho/7ff/AOkEvU6p/wBx6P8At9//AKQS U2klV9Tqn/cej/t9/wD6QS9Tqn/cej/t9/8A6QSU2klV9Tqn/cej/t9//pBL1Oqf9x6P+33/APpB JTaSVX1Oqf8Acej/ALff/wCkEvU6p/3Ho/7ff/6QSU2klV9Tqn/cej/t9/8A6QTOu6kxpc6igNaJ JN79AP8ArCSmj1ax+Vl19PqMQWl3cbzLhP8AxbWl/wAdq5LN+qfUcLZ61lJa8E72ucQNsTMsHDSX fAFdN0c9QvyLs/0Ki50gB9rmwbA2w/4J3DPTZ/ZR+sjOswi+7Hp2UEWOi5x9gltg/mRyxzgo5REh ZbmPPLDMY41Wgl5uykszp+R1SzDqJppe5gNb3G5wJfWTW+R6J/Oae6s+p1T/ALj0f9vv/wDSCkDU IokdjTaSVX1Oqf8Acej/ALff/wCkEvU6p/3Ho/7ff/6QSQ2klV9Tqn/cej/t9/8A6QS9Tqn/AHHo /wC33/8ApBJTaSVX1Oqf9x6P+33/APpBL1Oqf9x6P+33/wDpBJTaSVX1Oqf9x6P+33/+kEvU6p/3 Ho/7ff8A+kElNpJVfU6p/wBx6P8At9//AKQS9Tqn/cej/t9//pBJTaSVX1Oqf9x6P+33/wDpBL1O qf8Acej/ALff/wCkElNpJVfU6p/3Ho/7ff8A+kEvU6p/3Ho/7ff/AOkElNpJVfU6p/3Ho/7ff/6Q S9Tqn/cej/t9/wD6QSU2klV9Tqn/AHHo/wC33/8ApBL1Oqf9x6P+33/+kElNpJVfU6p/3Ho/7ff/ AOkEvU6p/wBx6P8At9//AKQSU2klV9Tqn/cej/t9/wD6QS9Tqn/cej/t9/8A6QSU2klV9Tqn/cej /t9//pBL1Oqf9x6P+33/APpBJTaSVX1Oqf8Acej/ALff/wCkEvU6p/3Ho/7ff/6QSU2klV9Tqn/c ej/t9/8A6QRKXZjnH7RVXW2NCyxzzPwdWxJSZJJJJSkkkklKTEAiDqDyE6SSnOxvq79X8S9uTi9M xMfIZJZdVRWx7SRBhzWghHx+ldLxsqzMxsOinKvn1siutjbH7juO97QHOk66rL6Tl9bd9YeoYfU7 qnVMopvx6KGw2sWWXMg2OAe9xbWCSYE8BY3SPrLnXdUqosz3X5VZyndWwH11MpoZTuA+zWNra+wh +1v036TugpX+RP0G6iN/MD6nUPW4/Sul42VZmY2HRTlXz62RXWxtj9x3He9oDnSddVaXKYPUusin ovVr8w309ZsY27CdXW2upuQx1tXouYxtksgA73OnVdWjVadjw12I6fiq/wARxef8qavUv6Oz/j8f /wA/1q0s3qefgisVHJqFjL6NzC9u4bbqy6RPYDVWP2r0v/uZR/26z+9BTaSVX9q9L/7mUf8AbrP7 0v2r0v8A7mUf9us/vSU2klV/avS/+5lH/brP70v2r0v/ALmUf9us/vSU2klV/avS/wDuZR/26z+9 L9q9L/7mUf8AbrP70lNpJVf2r0v/ALmUf9us/vS/avS/+5lH/brP70lNpJVf2r0v/uZR/wBus/vS /avS/wDuZR/26z+9JTaSVX9q9L/7mUf9us/vS/avS/8AuZR/26z+9JTaSVX9q9L/AO5lH/brP70v 2r0v/uZR/wBus/vSU2klV/avS/8AuZR/26z+9L9q9L/7mUf9us/vSU2klV/avS/+5lH/AG6z+9L9 q9L/AO5lH/brP70lNpJVf2r0v/uZR/26z+9L9q9L/wC5lH/brP70lNpJVf2r0v8A7mUf9us/vS/a vS/+5lH/AG6z+9JTaSVX9q9L/wC5lH/brP70v2r0v/uZR/26z+9JTaSVX9q9L/7mUf8AbrP70v2r 0v8A7mUf9us/vSU2klV/avS/+5lH/brP70v2r0v/ALmUf9us/vSU2ln9bubXgOrcYF59Nx/kQXWn 5VtcUb9q9L/7mUf9us/vWR1PqGBl9Qox/tNRpbAe7e3b7yXv1n9yvb/bQlt5smIXME7R9R+jr9Mp dThViwbbXzbaPB9h3uHyJhHuqbdTZS/6NjSx3wcIKB+1el/9zKP+3Wf3pftXpf8A3Mo/7dZ/ejWl LDImRl1u2l9XbXGi2qz6bXNefi9oD/8AwVr1rrnsDPwMfq+Q37TUKrN8P3t2/Sbe3WfG9/3LX/av S/8AuZR/26z+9Njt5L83z2NpASDaSVX9q9L/AO5lH/brP70v2r0v/uZR/wBus/vTmNtJKr+1el/9 zKP+3Wf3pftXpf8A3Mo/7dZ/ekptJKr+1el/9zKP+3Wf3pftXpf/AHMo/wC3Wf3pKbSSq/tXpf8A 3Mo/7dZ/el+1el/9zKP+3Wf3pKbSSq/tXpf/AHMo/wC3Wf3pftXpf/cyj/t1n96Sm0kqv7V6X/3M o/7dZ/el+1el/wDcyj/t1n96Sm0kqv7V6X/3Mo/7dZ/el+1el/8Acyj/ALdZ/ekptJKr+1el/wDc yj/t1n96X7V6X/3Mo/7dZ/ekptJKr+1el/8Acyj/ALdZ/el+1el/9zKP+3Wf3pKbSSq/tXpf/cyj /t1n96X7V6X/ANzKP+3Wf3pKbSSq/tXpf/cyj/t1n96X7V6X/wBzKP8At1n96Sm0kqv7V6X/ANzK P+3Wf3pftXpf/cyj/t1n96Sm0kqv7V6X/wBzKP8At1n96X7V6X/3Mo/7dZ/ekptJKr+1el/9zKP+ 3Wf3olOZh5Di3HvrucBJDHtcQPH2lJSZJJJJSkkkklKSSSSU4lPRurN61f1K7Ox31ZNTceyhmM9j vSrNjmbbDlOh36TU7fkFXxPqpkVt6di5WZXf0/pDt2JUzHNVxhjqmerd6zw72vO7axu4/crfS+vv 6h1XMwHYVuJXisZZVbf7XWte+yvcKo3MbNZjdqR2Cfp3WM3qJGXTi1M6Q4u2ZVl5Fz2Mkeo2htLm 7XOGk2AxrHZLSvCr18Em7Pfb7R/BBg/VrIoODRk5ov6f0p2/Bx21GuyWhzKvXt9Vws9NjoG1jddS t5YGH9Zsm5+DdfginpvVXlmFktt32SWl9Ruq9NoYLGtMQ93YFb6Ov46+fj4o6/T8PBq9S/o7P+Px /wDz/WrSq9S/o7P+Px//AD/WrSClJJJJKUkkkkpSSSSSlJJJJKUkkkkpSSSSSlJJJJKUkkkkpSSS SSlJJJJKUkkkkpSSSSSlJJKFt1NFZtue2qtv0nvIa0TpqSkpmkszI+sXSaiG15DMixwJDKnsOg5l 7nNYPmUH/nF4Y/8A05/I0ocQ7sgw5Drwn66Ojk9RwMQ7crIqpdG4Ne9rXEeIaTJWZ0EjMuu6huD5 JaC0gw+zbY8SP3WCtn9lYXXcDq/XM9uRjYh2sqbXMlo0c53N7apPu7Ld+qXTszp3Tracyv0rHXOe G7mu9pYxsywkchMEiZbaDqzyxwx4SeMe5KrjYsO2kkkpGo42b+g67j28Cz05/wDBKXfjYxbKxvrG CxtGSBrXv/6AGSPxoC2AQQCNQeE0bkMuTWGOXgY/YukkknMSkkkklKSSSSUpJJJJSkkkklKSSSSU pJJJJSkkkklKSSSSUpJJJJSkkkklKSSSSUpQtuporNtz21Vt+k95DWidNSVNZH1rY6zoORWwF9jz U1jGiS4+qzQAclAmgT2C7HHinGJNcRAvzb1PU+nZFgqoyqbbHcMZY1zjGvAKsrz/AOqmBnM61iZD 8a1tEPPquY4Mh1bwDuIjWV6AhCRkLIpl5nDHFMRjLi0tSSSScwKXM9Yp+s1t7nN6/idBoabHUVto Ze99NYaXWWvyXMALeSGtho5JXTLhPrFZ1Z94Z9YukZF/T6XWMbm9Hc20W0WOa/0b8exptYwtrHqO a4ajTlDr/HZI/l3el6AesGj9ezcXquM5jXYvUMdvpvtn6RfW0vr+DmO+S1lh/VDM+rl/SvR+r2S3 IxKX2OLQNjmG177INWyssbJO32jRbicd1oeexv2k76z5WVb0vIqxMnHqxm3ufjFoNT7nF7msyHP2 kPEQ2fILI6Z9VMiodOw/2azCyMFz25nWGmofaKQx9Qrb6Vhud6gc3SxoAjyC7NmVjPvsxmWsdkVB rraQ4F7Q76Jc2ZAMaJjl4jcpuG66sZT2GxuOXD1CwGC4MndE902tK/keq6zqfL8qeb6f03rD8fov SsjEONV0V7HXZjn1uruGOx1VfoNZY6z3yHHe1sBdUqtPVel5GXZhUZlFuXTJtxmWMdazaYO5jTuE E9wrSdd6/vHi8yev4Ir8Bw+Qc3qeFSaxZut3OvokC60N911YMN3wOdI4Vj9m4/79/wD7EX/+lEup f0dn/H4//n+tWkFNX9m4/wC/f/7EX/8ApRL9m4/79/8A7EX/APpRWkklNX9m4/79/wD7EX/+lEv2 bj/v3/8AsRf/AOlFaSSU1f2bj/v3/wDsRf8A+lEv2bj/AL9//sRf/wClFaSSU1f2bj/v3/8AsRf/ AOlEv2bj/v3/APsRf/6UVpJJTV/ZuP8Av3/+xF//AKUS/ZuP+/f/AOxF/wD6UVpJJTV/ZuP+/f8A +xF//pRL9m4/79//ALEX/wDpRWkklNX9m4/79/8A7EX/APpRL9m4/wC/f/7EX/8ApRWkklNX9m4/ 79//ALEX/wDpRL9m4/79/wD7EX/+lFaSSU1f2bj/AL9//sRf/wClEv2bj/v3/wDsRf8A+lFaSSU1 f2bj/v3/APsRf/6US/ZuP+/f/wCxF/8A6UVpJJTV/ZuP+/f/AOxF/wD6US/ZuP8Av3/+xF//AKUV pJJTV/ZuP+/f/wCxF/8A6US/ZuP+/f8A+xF//pRWkklNX9m4/wC/f/7EX/8ApRZn1k6aw9HuZQbX 3PdW2tj77HBzjYzTbY8tK3VjdYc7JzKMBhI43EdnWBzZ/s1NsPxhNlsR30ZMP85E/uni+x5z6ufV 3qJ6hi5eRQ5uGdzvVbYGmCx2wjY8P+lHC7L9m4/79/8A7EX/APpRWWtaxoY0Q1oAAHYBOlCIiKCc +eWafFIAUKFdmr+zcf8Afv8A/Yi//wBKJfs3H/fv/wDYi/8A9KK0knMTV/ZuP+/f/wCxF/8A6US/ ZuP+/f8A+xF//pRWkklOR1fpuOMPfuuIZZWXbrrXe0va1/0nn8wlT6XhU3dOx3vff6nptFkX3Abm ja7QWeIVzPpORg5FA5sqe0fEtMKr0G71sN5HAtc4fC6MgfhYm/pfRl3w/wB2X4Fsfs3H/fv/APYi /wD9KJfs3H/fv/8AYi//ANKK0knMTV/ZuP8Av3/+xF//AKUS/ZuP+/f/AOxF/wD6UVpJJTV/ZuP+ /f8A+xF//pRL9m4/79//ALEX/wDpRWkklNX9m4/79/8A7EX/APpRL9m4/wC/f/7EX/8ApRWkklNX 9m4/79//ALEX/wDpRL9m4/79/wD7EX/+lFaSSU1f2bj/AL9//sRf/wClEv2bj/v3/wDsRf8A+lFa SSU1f2bj/v3/APsRf/6US/ZuP+/f/wCxF/8A6UVpJJTV/ZuP+/f/AOxF/wD6US/ZuP8Av3/+xF// AKUVpJJTV/ZuP+/f/wCxF/8A6US/ZuP+/f8A+xF//pRWkklNX9m4/wC/f/7EX/8ApRL9m4/79/8A 7EX/APpRWkklNX9m4/79/wD7EX/+lEv2bj/v3/8AsRf/AOlFaSSU1f2bj/v3/wDsRf8A+lEv2bj/ AL9//sRf/wClFaSSU1f2bj/v3/8AsRf/AOlFj5uJXl9RrwqX3bGGHk3Wuh2hscNzz9Bh2/F/ktrO yvsuM6xo3WGG1MP5z3aNH38+SyMfIq6X0q7qtx3usEUToXgklp/668l58j5IUZERHVkgRCMsh6aD zdNnTsMDZW+6Ge3a3Iu0gcaWaaI1OJVQ4uY6wkiPfbZYPusc4Lmvqpd1VuZacqm00Zs3es5pDd/0 t08Q4fwXVqTJDglw3fkwwnxC6pSSSSYuUvNfrzVl9N6rldRu6/kDGsZW+rpOL1B2Hktktq/Q0+ne LAYn83uvSl5v9YOkDH6/mdUtxPrFTkZjtrb+hWV21WVMawNLoa2ys6atdpPBKH6Q+v8AvJGx+j1v 1TxsavpNeTXVmMvvkXXdUaBnvDHvDPtDgJdtn2T+attYX1Sszj09tV2Pm14tYmjI6ra1+baXEud6 tbAdgbMCXT5LdTpblaHmul4OF0z609UbiU7Guw6L7Q2Xvssfbkue5znEue4+ZWLi5xs+sODmWU5V fU86nNc9luJkV+mXChuPSC+po21tHucDt3SZ1XX1fV/oNOUMynpuJXlBxeMhlFbbNx5dvDd0mVcd RQ+5l7q2uuqDm12FoLmh8bg13ImBKbWgHgR9trr9V+IP2CtXjsEY56N9TzUAcv1qyC36cmmz7WTH nO+e67VVcfpXS8bKszMbDopyr59bIrrY2x+47jve0BzpOuqtJxN2e5MvK+n4IrbwHD+Zv8XN6m/O 9MAU1GsX0bXG124/pq9st9LSTzqrHqdU/wC49H/b7/8A0gl1L+js/wCPx/8Az/WrSCmr6nVP+49H /b7/AP0gl6nVP+49H/b7/wD0grSSSmr6nVP+49H/AG+//wBIJep1T/uPR/2+/wD9IK0kkpq+p1T/ ALj0f9vv/wDSCXqdU/7j0f8Ab7//AEgrSSSmr6nVP+49H/b7/wD0gl6nVP8AuPR/2+//ANIK0kkp q+p1T/uPR/2+/wD9IJep1T/uPR/2+/8A9IK0kkpq+p1T/uPR/wBvv/8ASCXqdU/7j0f9vv8A/SCt JJKavqdU/wC49H/b7/8A0gl6nVP+49H/AG+//wBIK0kkpq+p1T/uPR/2+/8A9IJep1T/ALj0f9vv /wDSCtJJKavqdU/7j0f9vv8A/SCXqdU/7j0f9vv/APSCtJJKavqdU/7j0f8Ab7//AEgl6nVP+49H /b7/AP0grSSSmr6nVP8AuPR/2+//ANIJep1T/uPR/wBvv/8ASCtJJKavqdU/7j0f9vv/APSCXqdU /wC49H/b7/8A0grSSSmr6nVP+49H/b7/AP0gsjpj8/Kzrs5tNTuS3da4AeoGbYIqPFbGn+15rV6r aa8GwNdtfbFTHeBsOzd/ZmVHo1QrwGPDdvrk27fBrvoN/ss2hNOpA7assfTjlL948I/ak9Tqn/ce j/t9/wD6QS9Tqn/cej/t9/8A6QVpJOYmr6nVP+49H/b7/wD0gl6nVP8AuPR/2+//ANIK0kkpq+p1 T/uPR/2+/wD9IJep1T/uPR/2+/8A9IK0kkpq+p1T/uPR/wBvv/8ASCyOiPz6bsjGZTUdkaOtc0fo 3Po0io9qx8oXQrFo/Q/WG1v5tu+P7bKnt/Gt6adwWXHrHJHw4v8AFdD1Oqf9x6P+33/+kEvU6p/3 Ho/7ff8A+kFaSTmJq+p1T/uPR/2+/wD9IJep1T/uPR/2+/8A9IK0kkpq+p1T/uPR/wBvv/8ASCXq dU/7j0f9vv8A/SCtJJKavqdU/wC49H/b7/8A0gl6nVP+49H/AG+//wBIK0kkpq+p1T/uPR/2+/8A 9IJep1T/ALj0f9vv/wDSCtJJKavqdU/7j0f9vv8A/SCXqdU/7j0f9vv/APSCtJJKavqdU/7j0f8A b7//AEgl6nVP+49H/b7/AP0grSSSmr6nVP8AuPR/2+//ANIJep1T/uPR/wBvv/8ASCtJJKavqdU/ 7j0f9vv/APSCXqdU/wC49H/b7/8A0grSSSmr6nVP+49H/b7/AP0gl6nVP+49H/b7/wD0grSSSmr6 nVP+49H/AG+//wBIJep1T/uPR/2+/wD9IK0kkpq+p1T/ALj0f9vv/wDSCXqdU/7j0f8Ab7//AEgr SzepdbwcWmxleVT9qB9NrC9steTEvbMgN5KBIG66MJSNRFudmWdQ6lntxG1VBtW5rttro02+q7d6 Q/Nd6Y05J8NKTzlfWPqba66q/sHTz7qxYRW90xo/051j93hLJyH4+FXiYUvz+rBoZr7m45nZJ/ef JcfMldH0jptXTMGvFr1I1sf+888lS4/RD3D88/l8B3W5yJzGIfJi+bxPZkH9TAgY9AA4Hrv/APSC LS7Mc4/aKq62xoWWOeZ+Dq2IySjUpJJJJSlxX1h6/wDXLpPVK6PW6JjYWY+37JdmOvr2srAd+mfu awOMjRq7Vcb/AIyM77Jj9P8AtIqb04378my/GbltJYWhtW17Xhm9rnndE6aIHp9iR1+37Hb+qnVc vq/QsfqGb6P2i02B5xt3pHZY+sFm8uJBDeZWusj6q3vyOhY9xr9Kpxs+zM9MVfq4seMf9G0NDZq2 9lrp0tz0Wjbu870dnUaPrP1KjMzrMwOxqL2sIDKq99mQ3bVUJDQGtaJJJPcoUPwOv104OTlZbqMa 6/qzbrn3Mhwmj2Odsre57TtbW1vtnSIWhR0B9PVbOqftPLstta2uypwxvTNbC9zGe3Ga6Gl513T4 kqPSfq2elvcaupZd1Vlj7b6rhjOFr3/SdZY3Gba7/P7AcaJutaaGiPt2XaWTvrE15buPgPzKsT6v 9a+15FmR1WysZ1dlr30vblVut2spc411+m4DbsaNNDyV2Kx8L6sYmJdju+0ZF+Pguc7BxLTWaqC6 W+zZW17trXFrd7nQFsJxrWtBZIHYdkfwo+J7ub1PPwRWKjk1Cxl9G5he3cNt1ZdInsBqrH7V6X/3 Mo/7dZ/el1L+js/4/H/8/wBatIKav7V6X/3Mo/7dZ/el+1el/wDcyj/t1n96tJJKav7V6X/3Mo/7 dZ/el+1el/8Acyj/ALdZ/erSSSmr+1el/wDcyj/t1n96X7V6X/3Mo/7dZ/erSSSmr+1el/8Acyj/ ALdZ/el+1el/9zKP+3Wf3q0kkpq/tXpf/cyj/t1n96X7V6X/ANzKP+3Wf3q0kkpq/tXpf/cyj/t1 n96X7V6X/wBzKP8At1n96tJJKav7V6X/ANzKP+3Wf3pftXpf/cyj/t1n96tJJKav7V6X/wBzKP8A t1n96X7V6X/3Mo/7dZ/erSSSmr+1el/9zKP+3Wf3pftXpf8A3Mo/7dZ/erSSSmr+1el/9zKP+3Wf 3pftXpf/AHMo/wC3Wf3q0kkpq/tXpf8A3Mo/7dZ/el+1el/9zKP+3Wf3q0kkpq/tXpf/AHMo/wC3 Wf3pftXpf/cyj/t1n96tJJKef611HBybaMWvJqLDO9wsbANn6HmezHPP3LVHVOlAADLoAGgHqM/v VHB/W+sXZPLKtxb+NFf/AFFh/tLZTY9T3ZcugjD90a+Zav7V6X/3Mo/7dZ/el+1el/8Acyj/ALdZ /erSScxNX9q9L/7mUf8AbrP70v2r0v8A7mUf9us/vVpJJTV/avS/+5lH/brP70v2r0v/ALmUf9us /vVpJJTV/avS/wDuZR/26z+9ZHUOoYLOrY2TXk1Ob7Nxa9pA2udVrB/dyCfl5LoVk/WKpz8at7Pp tc5gPm9jgz/wTYhLZkw/OAdpWC3P2r0v/uZR/wBus/vS/avS/wDuZR/26z+9GotbdTXc36NjQ9vw cJREWM6NX9q9L/7mUf8AbrP70v2r0v8A7mUf9us/vVpJJTV/avS/+5lH/brP70v2r0v/ALmUf9us /vVpJJTV/avS/wDuZR/26z+9L9q9L/7mUf8AbrP71aSSU1f2r0v/ALmUf9us/vS/avS/+5lH/brP 71aSSU1f2r0v/uZR/wBus/vS/avS/wDuZR/26z+9WkklNX9q9L/7mUf9us/vS/avS/8AuZR/26z+ 9WkklNX9q9L/AO5lH/brP70v2r0v/uZR/wBus/vVpJJTV/avS/8AuZR/26z+9L9q9L/7mUf9us/v VpJJTV/avS/+5lH/AG6z+9L9q9L/AO5lH/brP71aSSU1f2r0v/uZR/26z+9L9q9L/wC5lH/brP71 aSSU1f2r0v8A7mUf9us/vXmnVXts6nmWVndW++1zXDUEOe4gg+a9B63m+lV9lrn1Lh79phwYTthp /eefa37+y5HIry+pX7MKg5NGK73lg9jnmN0ce2GhrR+6AjHD70qJ4Yx1lJnx8weWgZgcUsmkY+W5 dP6p14VLf2jn5VQyXNFVLH2NDmVtAZwTpoI+HxXS/tXpf/cyj/t1n96PS7dTW7YapaD6Z0LdPo6e CmjKRJ16aDyDXHU9yZHzLV/avS/+5lH/AG6z+9EpzMPIcW499dzgJIY9riB4+0oySalSSSSSlLjP 8ZPVcrpOP0/NF+RRhMvm8Yj2ssfYC11bH7i0urLRZuAPguzXI/XbAuzrsXKxX9Je3pXqHMq6u4ml ovDG1l7GggfR0Lo8u6B6eaR+wux9Vb8rJ6Hj5eSXbso2X1B7/UcKbbH2UNc4EzFbm91rLmvqNgdb 6f0v7Nnv6fZhR6mC/p7rHAttc+15JsAbt9w2bNIXSp0tzS0ON036wuzup5uFZh24lWHWy2u6/wBr rWOdZWX+lG5jZqMbtSOwQMX60X2HCyMnCFHTOpuLcPKFu+zVrrKjdV6bQwWMaSIe7sCoVV9Ru+sW bdd0zJqw8zFrxBe5+MQDW68ueWsyHP2kWCIbPkFVxekdWyMHpPRMrEONR0ot9fMc+tzLW01vpr9B tdhs9+4OO9rYHmm61fXT8zxfhS41Z7f2CvxtvYf1mybn4N1+CKem9VeWYWS23fZJaX1G6r02hgsa 0xD3dgVvrlen9N6w/H6L0rIxDjVdFex12Y59bq7hjsdVX6DWWOs98hx3tbAXVJxrWu5rxj0JR/DX zavUv6Oz/j8f/wA/1q0s3qeFSaxZut3OvokC60N911YMN3wOdI4Vj9m4/wC/f/7EX/8ApRBTaSVX 9m4/79//ALEX/wDpRL9m4/79/wD7EX/+lElNpJVf2bj/AL9//sRf/wClEv2bj/v3/wDsRf8A+lEl NpJVf2bj/v3/APsRf/6US/ZuP+/f/wCxF/8A6USU2klV/ZuP+/f/AOxF/wD6US/ZuP8Av3/+xF// AKUSU2klV/ZuP+/f/wCxF/8A6US/ZuP+/f8A+xF//pRJTaSVX9m4/wC/f/7EX/8ApRL9m4/79/8A 7EX/APpRJTaSVX9m4/79/wD7EX/+lEv2bj/v3/8AsRf/AOlElNpJVf2bj/v3/wDsRf8A+lEv2bj/ AL9//sRf/wClElNpJVf2bj/v3/8AsRf/AOlEv2bj/v3/APsRf/6USU2klV/ZuP8Av3/+xF//AKUS /ZuP+/f/AOxF/wD6USU2klV/ZuP+/f8A+xF//pRL9m4/79//ALEX/wDpRJTaVbqOQ7Hw7bK/52Nl Q8bHnYwf5xCb9m4/79//ALEX/wDpRefdX6j1AdQyscZV3o032NrYbHOADHOa36RJ0CbOQiPNn5bA cs6FenU29z0KhtWF6jdW3GWHxraBXWf7TWh3zWksrpWDTZ0vDsc+7c+ipxi+4CSwHQCyArf7Nx/3 7/8A2Iv/APSiI2DHkJM5X3LaSVX9m4/79/8A7EX/APpRL9m4/wC/f/7EX/8ApRFY2klV/ZuP+/f/ AOxF/wD6US/ZuP8Av3/+xF//AKUSU2klV/ZuP+/f/wCxF/8A6US/ZuP+/f8A+xF//pRJTaXPfXe6 6npNTqnurJyGSWkg6Ne8ajwc0Fa/7Nx/37//AGIv/wDSiY9NxiILryD/AN2L/wD0ohIWCO6/FPgn GdcXCbp576h5OTczMrttfZXSKRU17i4NH6QQ2eOAusXPdEwqW3ZGI91oNcQG3Wt+g59B+i8fm1tP zWv+zcf9+/8A9iL/AP0ohAVEBfzR4s0iBV1+TaSVX9m4/wC/f/7EX/8ApRL9m4/79/8A7EX/APpR OYW0kqv7Nx/37/8A2Iv/APSiX7Nx/wB+/wD9iL//AEokptJKr+zcf9+//wBiL/8A0ol+zcf9+/8A 9iL/AP0okptJKr+zcf8Afv8A/Yi//wBKJfs3H/fv/wDYi/8A9KJKbSSq/s3H/fv/APYi/wD9KJfs 3H/fv/8AYi//ANKJKbSSq/s3H/fv/wDYi/8A9KJfs3H/AH7/AP2Iv/8ASiSm0kqv7Nx/37//AGIv /wDSiX7Nx/37/wD2Iv8A/SiSm0kqv7Nx/wB+/wD9iL//AEol+zcf9+//ANiL/wD0okptJKr+zcf9 +/8A9iL/AP0ol+zcf9+//wBiL/8A0okptIWTkV41D77J2sHA1JJ0a1o8SdAhfs3H/fv/APYi/wD9 KLlvrFl1tsFOK+57t2yhputfLwdrrAC8/RPsb4nd4JUSQBqToF0ADZlpGOsj4Icu/M6lnnCx4dk3 uPqvBlrNNroP7rG+0fM/nLr+m9Po6diMxaB7WfSd3c48uPxWZ0L6tU4WKH5Bf9rsE2Gux7IB/M/R ubMLT/ZuP+/f/wCxF/8A6UT5EADHHYak/vS7rCTORnIVekR+7HoG0kqv7Nx/37//AGIv/wDSiX7N x/37/wD2Iv8A/SiYltJKr+zcf9+//wBiL/8A0oiU4lVDi5jrCSI99tlg+6xzgkpMkkkkpS5nqX1K r6l1o5uTmOd0y22vJyelGtpZbfSz0mOdYTOzaBLIgrpkkut9ld/Fz+hdJZ0bplfT2PD21useC1ux o9Sx1u1rJdta3dAErQSSSUpVKOr9KyMuzCx83Huy6p9XHrtY61u07XbmNcXCDyrL3BrHOPDQSY50 Xn/TPt9TOh32Ct/S7HX/ALDZUf1lll9Vrqjl6bXRXu3bODzu5QvfwH+8mv5fm9xT1XpeRl2YVGZR bl0ybcZljHWs2mDuY07hBPcK0uKwRjno31PNQBy/WrILfpyabPtZMec757rtU4irH7pMfOuv4ovb xHF9t6fg1epf0dn/AB+P/wCf61aWb1N+d6YApqNYvo2uNrtx/TV7Zb6WknnVWPU6p/3Ho/7ff/6Q QU2klV9Tqn/cej/t9/8A6QS9Tqn/AHHo/wC33/8ApBJTaSVX1Oqf9x6P+33/APpBL1Oqf9x6P+33 /wDpBJTaSVX1Oqf9x6P+33/+kEvU6p/3Ho/7ff8A+kElNpJVfU6p/wBx6P8At9//AKQS9Tqn/cej /t9//pBJTaSVX1Oqf9x6P+33/wDpBL1Oqf8Acej/ALff/wCkElNpJVfU6p/3Ho/7ff8A+kEvU6p/ 3Ho/7ff/AOkElNpJVfU6p/3Ho/7ff/6QS9Tqn/cej/t9/wD6QSU2klV9Tqn/AHHo/wC33/8ApBL1 Oqf9x6P+33/+kElNpJVfU6p/3Ho/7ff/AOkEvU6p/wBx6P8At9//AKQSU2klV9Tqn/cej/t9/wD6 QS9Tqn/cej/t9/8A6QSU2klV9Tqn/cej/t9//pBL1Oqf9x6P+33/APpBJSe66uil91p211tLnHwA Elc50/6vdP6jfkZmbjyXvcS3e8fpHOL7PouH0JDPiCrHVsvqNtleAymkWOcxxAtc4Ekn02umpvBb vP8AJb5q/jV9QxseuivHo21iJN75J7k/oOSdSmkCR12DNGUscLiTGU+xr0huU010UsoqG2upoYxu phrRAGqmqvqdU/7j0f8Ab7//AEgl6nVP+49H/b7/AP0gnMLaSVX1Oqf9x6P+33/+kEvU6p/3Ho/7 ff8A+kElNpJVfU6p/wBx6P8At9//AKQS9Tqn/cej/t9//pBJTaSVX1Oqf9x6P+33/wDpBL1Oqf8A cej/ALff/wCkElNpJVfU6p/3Ho/7ff8A+kEvU6p/3Ho/7ff/AOkElOeP1b6w+Db/AP0az/yWN+K2 lz3W359N2PmPpqb6c/Rtc6fTLcjvU38yt4+a1vU6p/3Ho/7ff/6QTY7keLLk1jjl3jw/4rbSVX1O qf8Acej/ALff/wCkEvU6p/3Ho/7ff/6QTmJtJKr6nVP+49H/AG+//wBIJep1T/uPR/2+/wD9IJKb SSq+p1T/ALj0f9vv/wDSCXqdU/7j0f8Ab7//AEgkptJKr6nVP+49H/b7/wD0gl6nVP8AuPR/2+// ANIJKbSSq+p1T/uPR/2+/wD9IJep1T/uPR/2+/8A9IJKbSSq+p1T/uPR/wBvv/8ASCXqdU/7j0f9 vv8A/SCSm0kqvqdU/wC49H/b7/8A0gl6nVP+49H/AG+//wBIJKbSSq+p1T/uPR/2+/8A9IJep1T/ ALj0f9vv/wDSCSm0kqvqdU/7j0f9vv8A/SChbk9QqrdbZTjtYwFznG98ADUn+YSU879f2ud9i2gu DBa58CYBNTQXeGuir/UbpjLci7OurMUbW0Ej2lzt24jzaB+KFmvz+udVGEGtY9xFlg3EhjWt9rHH ZpsBPb6Tiuh6P0rO6SyxlLK7GWkHa+90AjuIxxykMYH6wyIkflj/AFdmefMEY/uwiJRHzSvaV8VO 2kqvqdU/7j0f9vv/APSCXqdU/wC49H/b7/8A0gkwNpJVfU6p/wBx6P8At9//AKQS9Tqn/cej/t9/ /pBJTaSVX1Oqf9x6P+33/wDpBEpdmOcftFVdbY0LLHPM/B1bElJkkkklKSSSSUpJJJJSlSx+jdHx cp2ZjYONRlWbt+RXUxljtxl0va0OMnlXHHa0mJgTAXF9G6xuqxOr9Sp6j9o6hvdj3m4/Yi9zHOZQ 3GpyIADW7QX1akTMwhdWew/Pp9U1b1eP0rpeNlWZmNh0U5V8+tkV1sbY/cdx3vaA50nXVWlx2A/M qxPq/wBa+15FmR1WysZ1dlr30vblVut2spc411+m4DbsaNNDyV2KcRVj908J8x/vov8AEcX0P+81 epf0dn/H4/8A5/rVpZvU82kVivbbubfRJFNpb7bqyYdsg8aRyrH7Sx/3L/8A2Hv/APSaCm0kqv7S x/3L/wD2Hv8A/SaX7Sx/3L//AGHv/wDSaSm0kqv7Sx/3L/8A2Hv/APSaX7Sx/wBy/wD9h7//AEmk ptJKr+0sf9y//wBh7/8A0ml+0sf9y/8A9h7/AP0mkptJKr+0sf8Acv8A/Ye//wBJpftLH/cv/wDY e/8A9JpKbSSq/tLH/cv/APYe/wD9JpftLH/cv/8AYe//ANJpKbSSq/tLH/cv/wDYe/8A9JpftLH/ AHL/AP2Hv/8ASaSm0kqv7Sx/3L//AGHv/wDSaX7Sx/3L/wD2Hv8A/SaSm0kqv7Sx/wBy/wD9h7// AEml+0sf9y//ANh7/wD0mkptJKr+0sf9y/8A9h7/AP0ml+0sf9y//wBh7/8A0mkptJKr+0sf9y// ANh7/wD0ml+0sf8Acv8A/Ye//wBJpKbSDl5LMWh1zgXRAawcucTDWt8ydFVyOvdLxdpybH0b52+p VayY5jcwLJv6pj9ZzRVjusfi0mHOrrscQHD3P9jSQSPY3+0fBAmvNkx4zLUioDUlv9Gxn22P6heQ 9zyfTcOCTG948vaGt/kjzWuqbc/FY0MZXe1rQA0DHuAAHb+bUv2lj/uX/wDsPf8A+k0gKC2cuKV/ YPBtJKr+0sf9y/8A9h7/AP0ml+0sf9y//wBh7/8A0mitbSSq/tLH/cv/APYe/wD9JpftLH/cv/8A Ye//ANJpKbSSq/tLH/cv/wDYe/8A9JpftLH/AHL/AP2Hv/8ASaSm0kqv7Sx/3L//AGHv/wDSaX7S x/3L/wD2Hv8A/SaSm0kqv7Sx/wBy/wD9h7//AEml+0sf9y//ANh7/wD0mkpD1utr8EvcJbS9j3f1 J22f9BzkXpVjrOnUF+tjWBln9ev2P/6TVDIzMXIx7aHsv22scx36vfw4R/o1n9B6nWKLK7W27w4W ENptdrY0Gz6LD/hd6b+l5hlGuI/1ZX9C7ySq/tLH/cv/APYe/wD9JpftLH/cv/8AYe//ANJpzE2k lV/aWP8AuX/+w9//AKTS/aWP+5f/AOw9/wD6TSU2klV/aWP+5f8A+w9//pNL9pY/7l//ALD3/wDp NJTaSVX9pY/7l/8A7D3/APpNL9pY/wC5f/7D3/8ApNJTaSVX9pY/7l//ALD3/wDpNL9pY/7l/wD7 D3/+k0lNpJVf2lj/ALl//sPf/wCk0v2lj/uX/wDsPf8A+k0lNpJVf2lj/uX/APsPf/6TS/aWP+5f /wCw9/8A6TSU2klV/aWP+5f/AOw9/wD6TS/aWP8AuX/+w9//AKTSU2lg/WXqbaa3UtMiqH2DsX/S rZ+G93kAPzlczet42NQ54ZabSD6THU2sBIE8uYNABJ8lyeVuz82nDm13qO9TId6b9+wmS/YG7vf9 LiI2jsjCPHIR6byPaI3Xg+3A5CLO0B3kXc+p3TnVYr+o3Sb8wy0nU7J8/wB46rolTZn4lbG1srva xgDWtGPfAA0A/m1L9pY/7l//ALD3/wDpNGcuKRO3Ydh0Y4ihrqdye56tpJVf2lj/ALl//sPf/wCk 0v2lj/uX/wDsPf8A+k01LaSVX9pY/wC5f/7D3/8ApNL9pY/7l/8A7D3/APpNJTaSVX9pY/7l/wD7 D3/+k0SnLqvcWsbYCBPvqsrH32NaElJkkkklKSSSSUpJJJJSli4n1Wwsa2j9PfdiYb3WYeDYazRS 9+73M21tsdtD3Bu97on4LaWL/wA5K3fWAdIZTupDLTZmb9BbSK3vrDNpna21smedEtL+h/BTLC+r GJiXY7vtGRfj4LnOwcS01mqgulvs2Vte7a1xa3e50BbCwMP6zZNz8G6/BFPTeqvLMLJbbvsktL6j dV6bQwWNaYh7uwK30tf5d/HxV1/ls1epf0dn/H4//n+tWlV6l/R2f8fj/wDn+tWklKSSSSUpJJJJ SkkkklKSSSSUpJJJJSkkkklKSSSSUpJJJJSkkkklKSSQMzLZiUGxw3OJ211jQueeGj+PgNUkgEmh 1eY+vddl9mDVQx1tjfU3NYC4j1CwMmP3i0wifUbDzMX7b9poso3+ls9RjmTHqTG4DxWl0jEffaep ZB3l5Lqj2JI2mwT+bHtZ/J15cthRiFy42zPPw4fu4ANby8btSSSSkaqkkkklKSSSSUpJJJJSkkkk lKSSSSUpYuD+rdbvo4bbvA+ZGQz8bbPuW0sXq/6t1LGzOB7S4/8AFu2u/wDA7nn5Jsuh7MuHUyj+ 9E159HaSSSTmJSSSYkASdAElKJABJMAclcb9but3F+M3AvtpYA8usreWB/0YIDSHFvME6HstbKyb erXjExP6Ny5x1a4fvv8A5H7rfz/6vOtiYlOJXsrBJcZfY7Vz3fvOKYbkKBod2xjMcMhOY4pfufxe W+rfWupMwH2X7sqoWkG20vMe1unq+8D+1A8102J1HGy/awllsbjU+A6P3hBIcPNpIVpZuX0Si334 xFFgO4NAOzd+9DS0sd/KYQfiiAQN7ROePJIkx9u+o1DpJLyv9s9X/wC52RP/ABr/APyS7v8A5xCr TKo9M9/eK/8A26GOmxyA+C/NyeTHVESu9tNnZSXOdY+tZxsRluFWHWusDT6u1zdsOP8AgrOdPFVO kfXPJyMh7M6uoVhhc01kVndLRzfaG9/ij7kbpYOUymBnWg8dXrlWu6n07HsNV+VTVY3lj7GtcJ14 JWcetZt+mJizPDofZ/1LWV/+CLlOudO61kdUvufh3vc/bLmVEt0Y0aembG9v3ilKdDQWuw8txSIy SENL3FvoVV1N1YtpsbZU76L2EOaY00I0WX1vqeGOm5tNdnq2mmxpbV7tpLSJeRo35lZ3Q/q863pd BzC6p3vml9TS5vvdEi9rwJ5+iFt0dIwqS1xabXM1YbDuDT4tZ9BvyCNyI2qwtMcWOZ9Rnwy2Arbx fMsO2qnLousaH112Mc9n7zQ4Ej5hd19VcW2xt/WMoTkZziW+VYPb4n8AFV61lO6z1eroVDttFb92 S8HktEuaP6o/H4LqK62VVtqrG1jAGtaOAAIAUscfs46v1ZKJ8I/2rOY5n7zkEuHhjisb3ciySSST GNSSSSSlJJJJKUkkkkpSSSSSlJJJJKUkkkkpi8PLHBjtjyCGuiYPYx3XJ0fVnr2P1Dptb8rHycPH pyq8i9uO6t5OQa3PL5yny+1wJ3AQDOmoXXLOw+v9KzcluLj2uNr2ufSX1W1stawgOdTZYxrLQJGr CdNUKv8Al4JutezjdP6b1h+P0XpWRiHGq6K9jrsxz63V3DHY6qv0GssdZ75Djva2AuqWbjfWLo+V ltw6bybbC9tTnV2MqsdUYsbTc9grsLfBjitJOu9f3jxX3J6or8BXkHN6nhUmsWbrdzr6JAutDfdd WDDd8DnSOFY/ZuP+/f8A+xF//pRLqX9HZ/x+P/5/rVpBTV/ZuP8Av3/+xF//AKUS/ZuP+/f/AOxF /wD6UVpJJTV/ZuP+/f8A+xF//pRL9m4/79//ALEX/wDpRWkklNX9m4/79/8A7EX/APpRL9m4/wC/ f/7EX/8ApRWkklNX9m4/79//ALEX/wDpRL9m4/79/wD7EX/+lFaSSU1f2bj/AL9//sRf/wClEv2b j/v3/wDsRf8A+lFaSSU1f2bj/v3/APsRf/6US/ZuP+/f/wCxF/8A6UVpJJTV/ZuP+/f/AOxF/wD6 US/ZuP8Av3/+xF//AKUVpJJTV/ZuP+/f/wCxF/8A6US/ZuP+/f8A+xF//pRWkklNX9m4/wC/f/7E X/8ApRL9m4/79/8A7EX/APpRWlm9a6lRj4OVWy6Mr0bCxlcl7TtMOhurQPEoE0LXRiZSER1SX4mD j1OuutvZWwS5xyL/AP0osrG6d+1Ml1l3rNxayWljrrHdoNQJedT/AIT/ADR3XKYOdn5nUcOjIy77 GPvrEG15jc4NJEnQweV6XVVXTW2qpoZWwQ1o0AATIy4/INjLi+70L4py69g1x03GAgOvAH/di/8A 9KJ/2bj/AL9//sRf/wClFaSUjVav7Nx/37//AGIv/wDSiX7Nx/37/wD2Iv8A/SitJJKav7Nx/wB+ /wD9iL//AEol+zcf9+//ANiL/wD0orSSSmr+zcf9+/8A9iL/AP0ol+zcf9+//wBiL/8A0orSSSmr +zcf9+//ANiL/wD0ol+zcf8Afv8A/Yi//wBKK0kkpq/s3H/fv/8AYi//ANKJfs3H/fv/APYi/wD9 KK0kkpq/s3H/AH7/AP2Iv/8ASiX7Nx/37/8A2Iv/APSitJJKav7Nx/37/wD2Iv8A/Sio9Y6XjHCN pdcRSQ5+66136M+y36Tz/g3OWwovY2xjmPEteC1w8QdCgRYpdCXDIHsXO6diVX4VT7H3+qAWWxkX fzjDsf8A4T94FWf2bj/v3/8AsRf/AOlFldL6hjYF9+Bm5FdTmQ6bHtb7m/ozyR9Noa/5lbrHsexr 2ODmOALXAyCDwQUomwuywMZHTQ6g9NXPz8WnFwcnJY64voqfY0HIvgljS4T+l8lyWD1XP6vmVdPc A1t+4OHrZEEBjid2+58jSY78Sui6lY/q9h6djk+g4EPeODHtc8x+Yw/R/ed5AqXTvql07p2ZXmU2 3Osq3bQ9zS33NLDO1gPBTJcUiK+Xqz4jix45e4P1hBMNNuzcxui4ePXta64uMGx/r2tLnAAbnbXg dkX9m4/79/8A7EX/APpRWklI1SSTZav7Nx/37/8A2Iv/APSiX7Nx/wB+/wD9iL//AEorSSSGr+zc f9+//wBiL/8A0ol+zcf9+/8A9iL/AP0orSSSnIzvqx0zNrDHm5ha4O3Ntc46AiP0u8d/BD6f9Uum 4F5uqtyHOLSzWzZoSDzSKz28VtpIcIu61ZBmyCJhxHhPRq/s3H/fv/8AYi//ANKJfs3H/fv/APYi /wD9KK0kixtX9m4/79//ALEX/wDpRZH1gyKOn0tx8Z978/I9tDBfcSJ03R6n3K91rrmP0uoCPVyr NKaByT4nwCqdB6Ne253Vuqe/Pu1a0/4MH+MfcFLCIA457foj94/wY5SJPBHfqeyDp31Prp9HJvyL RlNIfZ6btok/SbuHu8iZW3+zcf8Afv8A/Yi//wBKK0kmTnKZuRtdGEYigKav7Nx/37//AGIv/wDS iX7Nx/37/wD2Iv8A/SitJJq5q/s3H/fv/wDYi/8A9KJfs3H/AH7/AP2Iv/8ASitJJKav7Nx/37// AGIv/wDSiX7Nx/37/wD2Iv8A/SitJJKav7Nx/wB+/wD9iL//AEoiU4lVDi5jrCSI99tlg+6xzgjJ JKUkkkkpSSSSSlJJJJKWJAEnQDkrkcbrfTPrH1n1sfPx2MxGX0dNx/Vr+0XXPaWWXGqd4Y1ohgOp 1dxC69JAi7B6gj7U3X2g/Y8R03Kxcvp/1Z6VjObb1Hp9tRzcdsGzH+z1PqvNzea/d7deZXbpJJxN 2f3iZHzP+8itvAcI8h/vub1Nmd6YIuqFZvo2tNTtw/TV7Zd6usHnRWPT6p/3Io/7Yf8A+l0upf0d n/H4/wD5/rVpBTV9Pqn/AHIo/wC2H/8ApdL0+qf9yKP+2H/+l1aSSU1fT6p/3Io/7Yf/AOl0vT6p /wByKP8Ath//AKXVpJJTV9Pqn/cij/th/wD6XS9Pqn/cij/th/8A6XVpJJTV9Pqn/cij/th//pdL 0+qf9yKP+2H/APpdWkklNX0+qf8Acij/ALYf/wCl0vT6p/3Io/7Yf/6XVpJJTV9Pqn/cij/th/8A 6XS9Pqn/AHIo/wC2H/8ApdWkklNX0+qf9yKP+2H/APpdL0+qf9yKP+2H/wDpdPn9Rw+nUi/Ms9Kt zgwOhzvcQTENBPZUR9aOkWhwxbDfY0bi0NcwAcbnPtDWga+KBkBuV8cWSQuMSR3rT7W45nUmgudk 44aNSTS8AD/t9cd1f60dYp6jdVi5jHUt27HV1MDTLWkkeoHnk/vLoBj9R6s4PyD6WNMgEe3+xW8S 4/yrBHg3ur7ei9Kj9Ji1XPP0rbmix7j4ue8ElNkJSGh4fFmxHFhleQDISK4dwPtcPpNXX+sYbMrJ zGehZuDQQ4H2uLdW0OpB47n5K/R9X7ahDrqbgDuDH0EMB8fTZc1hPmRK16aaaKxVQxtVbfosYA1o kzoApoiPfUsc80iTw+iJOkY6NT0+p/8Acij/ALYf/wCl0/p9U/7kUf8AbD//AEurSScxNX0+qf8A cij/ALYf/wCl0vT6p/3Io/7Yf/6XVpJJTV9Pqn/cij/th/8A6XS9Pqn/AHIo/wC2H/8ApdWkklNX 0+qf9yKP+2H/APpdL0+qf9yKP+2H/wDpdWkklNX0+qf9yKP+2H/+l0vT6p/3Io/7Yf8A+l1aSSU1 fT6p/wByKP8Ath//AKXS9Pqn/cij/th//pdWkklNX0+qf9yKP+2H/wDpdL0+qf8Acij/ALYf/wCl 1aSSU1fT6p/3Io/7Yf8A+l0vT6p/3Io/7Yf/AOl1aSSU1fT6p/3Io/7Yf/6XS9Pqn/cij/th/wD6 XVpJJT599Y+mdWt6zk2DHtvDtn6Wml+wxWwafT445Wth39bycCjApDGNbVXWYrsDgGgAtss3ANEc 7fd4BdWkmDHRJvdsy5rihCBgP1YAib7CnNw+m52Gxza76C55lzjQ6TGjW6XgANGgCsen1T/uRR/2 w/8A9Lq0kntckk2dy1fT6p/3Io/7Yf8A+l0vT6p/3Io/7Yf/AOl1aQ776sel99zttdbS57vABJCH 0+qf9yKP+2H/APpdL0+qf9yKP+2H/wDpdRu6v0uipttuVW1jgHN9wkgiQQ0arKu+ueBv9PCouy7O wa3aD98u/wCinxxTltErTkiNyHX9Pqn/AHIo/wC2H/8ApdL0+qf9yKP+2H/+l1yOT9b+pfb2Wij0 GUBzH4riTJPO/Ruojw0WqPrH1uoTkdHsc067qy4iPk1yeeXyCttfELBmgb308HZ9Pqn/AHIo/wC2 H/8ApdL0+qf9yKP+2H/+l1jH66UVj9NhZFbhyCB/GFTwfrT1vN30YmIy++XODiYDWE+0Ee36PEyg OXyUSQBXcp96F1d+QekLOpgEnIoAGpJof/6XXN9a+tGTSfs+HlVXPDgX21VFoG0zAc614dPfRWv2 F1vqZB6zm7Kefs1H5DoG/lWrj9A6NRUKm4lTwPzrGB7j8XPBKMfbgQZH3D2jt9qDxzFAcA7ndyOh dGusDOsuyq8jJyBu3W1us2HggEWs1HHHwW76fVP+5FH/AGw//wBLo9NNNFYqorbVWOGMAa0T5BTU c5mUifs8AvhERAH2+bV9Pqn/AHIo/wC2H/8ApdL0+qf9yKP+2H/+l1aSTVzV9Pqn/cij/th//pdL 0+qf9yKP+2H/APpdWkklNX0+qf8Acij/ALYf/wCl0vT6p/3Io/7Yf/6XVpJJTV9Pqn/cij/th/8A 6XS9Pqn/AHIo/wC2H/8ApdWkklNX0+qf9yKP+2H/APpdEpbmNcftFtdjY0DK3MM/F1j0ZJJSkkkk lKSSSSUpJJJJSkPIsNVFloG41sc4N8YEwiJiARB1B5CBujWhSNxbx+A/MqxPq/1r7XkWZHVbKxnV 2WvfS9uVW63aylzjXX6bgNuxo00PJXYrHwvqxiYl2O77RkX4+C5zsHEtNZqoLpb7NlbXu2tcWt3u dAWwnGta0Fkgdh2R/Cj4nu5vU82kVivbbubfRJFNpb7bqyYdsg8aRyqnX/rE/p+Gy7DrJsdYGH16 bWN2lrjy4M108VsZNHr1hk7YfXZMT/NvbZHz2oef07D6jS2jMr9Wtrg8N3Ob7gCJlhB4KbK6Nbr8 ZiJxMxxRB1Dz3RvrfmZQtGVhWZBZt2nCqLondO/c/TjRaI+srS4sHTOobwAS30BIBmDG/vBVvp/R um9Nc9+FUajYAH+97pA40e4qy2jblWZE/wA4xle2ONhsdM+e9KIoDisnwP8AYuyzgZk44AQ0oG7/ AALyPUvrr1KnNsqoxm01s2wzJrcLdWg+4CyO+nktGv61ZH2Wu9/S8pwNYfZY1hFfElzXa+1aGX9X OjZuQ/Jycf1LrI3u32NmAGjRrgOArLsGr9nuwKf0dRqNLOXbWlu0fSMmPihEEE2bHRfkyYTCAhjq QHrP8NXBz/rL1M4eQ1nScqia3gXkPbs0Pvn09NvPK57pHW+rs6hU71sjM+l+r7n27va78zdrHK9F uprvpfTaN1drSx7dRLXCCNFn4v1b6LiZDMnGx/TurMseH2GJEd3QkY2QbquycfMQhCcfbsyG9uaf rF1QuDPseQx5Bc1pw3OJAif+1LOJCwfrRn5uYcb7VTbSGb9nq0mkGdkxL3zx8l3zqN2VXkT/ADbH 17Y53mt0z5bEHP6VgdRDBmV+qK5LBuc2J5+g4eCJhGQomQvrv+GizFzBxzExCBrp8p/xtfyeP+rX U+oYmFZXjUXXVm0umvHN7Z2s03Ntrg6LWb9Z+rES3pV94BIkVPZq07SNPU7rcwenYfT6nVYdfp1u duLdznaxE+8nwRMaj0Kyyd0vssmI/nHusj5bkhGMRQJNdT/BU8/uSMpQiL6Df/GfPP8And9YeftX y9Ov/wAguit+sXV9knDyKZIA/VXHVx2gb3Xdz/JV9/1U+r73uecQS4kmHvaJPgGuAC0b8cXVNr3b Q19b55/m3tsj57UIwreRl+H8V+bmISr28UYVe4/hTw3Wr+sZ+LF+LltbU/1CbWewABwn2V1gc95+ KD9VrBjdQfkWYluY1lZDRRX6rmvLmkO1iNAdV3+Vi0ZlDsbIbvqfG5slswZ5aQeyrYPROmdPuN2H T6Vjm7Sd73aEgxDnEdlII4NzGXF010+rCeZ5jh9uMoiB3qNH6NUfWRpcWDpufvABLfQ1AMwY394K q9S+t32ZjAzCyKbXOBjJr9MFgPv2+469lvNo25VmRP8AOMZXtjjYbHTPnvVXO6J0zqFwuzKfVsa3 aDve3QEmIa4Dunwliv1QNeBYJRyV6Za+IarPrKyxgfX07Pexwlrm0SCD3BD0mfWRr2h7Om57mOAL XCiQQeCDvWni4tGHQ3Gx27KmTtbJdEmeXEnuljY4oxasbduFVba93E7RtnyQMoXpDTzSBOtZfg4F P1yZZn2UfZL3VQBVWxgN28fT3M3f6wrh+sjWlod03PBeYaDRyYLoHv8AAItP1a6JRcy+rHLba3B7 HepYYIMg6vV+6j1bKHzHoPNkRzLH1x/00ZyxacMDt1NIjHJ+lIfRx8r60sx6H2O6fmVEAhjrqtjN 35oc7d4qHT/rX9oxWOdg5V1rRttdj1b693kdy187p2H1CptWZX6lbXbg3c5usRPsI8VHA6VgdODx h1ekLY3jc507Zj6bj4pcWLh+Q8V99FcOTi+YcLRH1ka4uDem55LDDgKODAdB9/gVTzPrkyjKpr+y 31MBJyGXMDLNpHt2Dd89V0FNHpWXvmfXeLIjiGMrj/oKlk/V3o+Xe/IyKDZbYZc71LBMCOA8BKEs V+qBrwNqlHJXpkPqgd9ZWMYXv6dntY0FznGiAANSSd6d31ka1pc7pvUGtaJJNEAAf2lo24jH4L8J hLGOqNLTq4gFuwcmTHxU76Ksil9Fw3V2Ate0EiQeRLSChxQv5NPNNT/e/B57A+uAyLbmOxL7juLq W47A9wr4943cq4frI0ODD03P3kEhvoakCJMb+0hWMPoHScK9uRi0ena2QHb3nkQdHOIVx1G7KryJ /m2Pr2xzvNbpny2Izliv0wNeJpEY5K9Uhfg4XU/rYcfHPp4eTRe/Sp2TVsZoRu/O10R6PrRXfU22 vp+dYx3Dq6Q5pI0MODtdVez+j9O6i5jsyo2msEM972xPOjHBFwsHFwKfQxWenVJdt3OdqfNxJSMs XCKgeLz0Vw5OI+ocLm/85dwmrpme8SQT6OktO0jRx4IhUP8Anmf2j6X2W30o9M0bR63q7vCflC6T Go9CssndL7LJiP5x7rI+W5Uj9XejG31jjD1N2/dufO6Zn6SUJYteKB8KKpRyacMvtazvrM9gl/S8 1oJAk1Rq47QPmSh5H1qsorNr+l5bGNGr7WFjQToJMFbWTR69YZO2H12TE/zb22R89qbKxMbMq9HJ rFtcg7XcSEBLHesNPMpMZ1pL8HnOm/W7Mux9pwbczIr+m+ke3UnbIa0xojn60dQ3FjejZJsaAS07 gQDME/ozzBWxidMwMJ7n4tDaXOEOLe4RW0bcqzIn+cYyvbHGw2OmfPenSnis1j08SUCGStZ/g8l1 D64dRa+qsYbsKyt4ssZYSS9v7pDmNgFWD9autuq9dnSneht3eoQ8t287t20CF0duDhXPNluPVY88 uexrjp5kJX4ldmHbiVgVMsrdWNoENDgRo0R4pHJjoVjF+JKBCdm5n7Hmn/WH61RI6bsaB7nOqtMe f0ln4vVvrI7LtdWXMflEF26pzmgtEDa0NeRppwu8SSGaIBHtx1UcRJHrlo8iT9Y7Xiu/qTq3OBIb XjXTAiSIx2HSVWz+j9StY0fbcnL3T6jbaclrRERA2Pldk6jdlV5E/wA2x9e2Od5rdM+WxFQGeYNg RHlEJOKJGpJ+peQ6N0Pp1NbndTxrLrg72EVZBbtju30wOVv42Z02qvbi02MrBIivGtAlp2ke2vsV oIWNR6FZZO6X2WTEfzj3WR8tybPJKZuR+nRdGEYigGuc3CJk02knk/Zrv/Sad3VMRglwuaJABNFw 1cdoH833JVxCyaPXrDJ2w+uyYn+be2yPntTFzVyMrAyaXUZFN1lT43MOPfBgyP8ABoOLX0XDsNuL i21WEbS5uPfMHt/N+S1UkeIgUCa7IoXdatMdUxC4sAu3gAlvoXSAZgx6feCpftLH/cv/APYe/wD9 JoraNuVZkT/OMZXtjjYbHTPnvRUEtX9pY/7l/wD7D3/+k1FnVMR7Q9gucxwBa4UXEEHgg+mriFi0 fZ8WnHnd6LG17oidoDZhJSL9pY/7l/8A7D3/APpNRPVMRpaHC4F5hoNF2pgugfo/AK4hXUerZQ+Y 9B5siOZY+uP+mkpF+0sf9y//ANh7/wD0ml+0sf8Acv8A/Ye//wBJq0kkppjqmI4uDRcSww4Ci7Qw HQf0fgVL9pY/7l//ALD3/wDpNFpo9Ky98z67xZEcQxlcf9BFSU039UxGNL3i5rGglzjRcAAOST6a l+0sf9y//wBh7/8A0mi5VH2jFux52+sx1e6JjcC2YRUlNX9pY/7l/wD7D3/+k1KnOout9Ju9thaX BtldlcgEAkeo1sxuCsITqN2VXkT/ADbH17Y53mt0z5bElJUkkklKSSSSUpJJJJSkkkklKSSSSUpJ JJJSkkkklOTd9aOjVZl2C2y3IycaPtFeLj35Pp7pgWHGqsDTpwSrnTep4HVMRmb0+9uRj2fRezx7 hwMFpHcHULPb0frGHk5Dul9RqqxMh7rvsuVjeuK7bHOssdXZVfjuh5dMO3R2VnonSrem0WjJynZ2 Zk2etlZLmNr3v2trG2uv2tAawCEhtr2/FR307/g6KDl5WPhYtuXku9OihjrLXwTDWiXGGgk/JD6l 07E6pgXdPzWCzHyG7HtMfEETOoOoWZf9SfqvdhPxD03FY59ZrOTXj0MuBI2+o1zagA7voEkitPxd wEEAjgrP6n9YOkdJtZTn3muyxjrQ1tdlm2thAdZZ6THbGDd9J0BaAEAAdtFTHTtvWT1RtkepjjGt qLZnY82Vua+dI3ukRrp4JdR21/JA2130SM6jg2XUU1XNsflVOyKCz3NfU0sBe17ZbH6RvdWVjYn1 apwut/tLFudXi+lbW3p+0emyy59b7LKj+aHenq3iZOkmdlLoO+v5q6uPd9cfqpRW6x/WMIhnIZfW 93yYxxcfkFpYuXiZtDcnDuryaHzsuqcHsMGDDmkgwQsLqv1azfsN2H0TIZVjZPtswckudSwEgl2O 4bnVR+5BZ4BvK6NLorq5/Ves09MdSx1F+Vdfvc2nGaHvFdQ3WWEOc32tkcakkAAlVsH61dNz8yvH x2XOoyHPrxc8sH2a6ypu+xlb926QJ5aAdpgmEbq/S8vMsoyMDM+w5VAsr9U1C4Gu4APG0ubDg5rX NM8jUFVOn/VizBycRrc59vTOnufZiYb2A2NssYa5fful7Wh79o2j6XJgJDxUdtHeVC3rnTKcc5Dr S6sXOxgGV2WPdcwlrq6662Oe8gtP0QeCr6wsz6vZxyarum51eNXTkvzG1X45vDbbGvZYGFl1BDH+ o5xBkydCOEuqun8u38adXCz8XPp9fFeXMDixwc11b2uby19dga9jh4OEp83NxcDEtzcywU41DS+2 x3AaPhqfgFS6JTVS7Ob9o+1ZrsndnvDDUwXGqqGsYd0NFeyPc7zMpfWZmI7oeS7MyBh0VBlxyHN3 hjqnttYSwQX+5o9o54SPTyH4qG9eK9H1k6LkYuVlV5EV4LS/LY9ljLamxvl9D2tsEgSPbr2WkCCA RwVxv1jz/qt1vH9EdSdg572Ox/tTaLd1TLXei+rLY5g9Nj3H6NpbrBGuq7Jo2tA8BCPS/ort+P7G nm9b6L0+0U9Qz8bEtc3e2u+6utxbMbgHuBiQh9O+sPQuqXWUdOz6Mq6qd9dVjXOgRLgAdW+4e4aI HVKen25b7W5bun9Sw8f1nZTJAbQS+PXDv0dlctd7Xcalu06qr9Ucv1G5jMixpzMi92XtFN+OHVPa yttjK8utjoO3WNwHG4oR1vyJ/HRUtK8wPw/3nolz4+ufT3bGsxsp9uS6On0hjd2W3cWmzHmwN2Db uJeWw2CdCJ6BcP06rByM6jGw+vTl4HqU9Ga7Gcyr02PLb6/eWNy4aAwmtwgCdDql1pXQl67pvUKO pYVeZjhzWWSCyxu17HNJY9j2nhzXAgomRl4+M6llz9rsmz0aRBO55a58aA/mtJVL6u1UU9LZVTkH Mc2y4X5Lm7C+/wBV/wBods/N/S7oAU+rsxrTiU2Xuxsp984NrW7iLmMe8iCCINYeHTGncGEjvp3/ AAV38L/Dv+1ZvX+lOzPsYtd6nqGj1DVaKTaOahkFnol86bd0zpytFcXhfZ3ZrejZfV6bqmZ7rjVR h20NdlNs+1/ZxlWW21Ha8yWD39pXaJdAe/8ABR3I7OXnfWbofT8w4eZlCm5oY6wljzXWLCW1+tcG muvcRpvcFeZmY1mVZhsfN9LGW2Mg6MsLwwzEaljlWx+lspzuoZDnCynqPpusocwGHMZ6LpdPua5r W6R4+KodE6TidM6zn14+W+0Oox/TwntP6vSHXljWWfnMLi7a380COISHj/LwUepHg7dttVNT7rnt rqraX2WPIa1rWiS5xOgACyrPrj9U6g0u6xhHc4MG2+t+rjAnY4wPEnQLUyG47se1uUGOx3McLhZB YWEe7fu0iOZXIYtuN1K/FxuidTF+Dj205rsPObc3IZTW7f6mNZc0WW1nj3AjweBDUhv4aX4DqVHa +uv29HsKbqr6mXUPbbVY0PrsYQ5rmkSHNcNCCqXVes09MdSx1F+Vdfvc2nGaHvFdQ3WWEOc32tkc akkAAlW8TKozMWrLxnb6MhjbKnwRLXDc0w4AjTxWP9ZTjVWYuS7rGP0XKaLa67cn0yH12BvqNa21 9fua4McDOhGoISOn9qgkwfrV03PzK8fHZc6jIc+vFzywfZrrKm77GVv3bpAnloB2mCYWyuO6GOhH quLgYP1gozcXpxdbhdODmPt9SytzSftAefVaxpsO1rZE6nQLsUT0U0LeudMpxzkOtLqxc7GAZXZY 91zCWurrrrY57yC0/RB4KPhZ+Ln0+vivLmBxY4Oa6t7XN5a+uwNexw8HCVyvWLsXEz2fY+omluNm G81np+RnVsyrmurdU23FLGt3+qSWOJduPbhb/QKaW412UzKbm25txuyLmN9NvqBraSxtUuLNgrDd riXA86oDUX/K9FHQ0P5btzNzcXAxLc3MsFONQ0vtsdwGj4an4BU6PrJ0XIxcrKryIrwWl+Wx7LGW 1NjfL6HtbYJAke3Xsn+sOPj5HSL2ZOQ3ErZst+0PAc1jqnttYXNJbuG5o0nVYfXLegfWFr8NuVf0 zqPp+iMu3EvpAryJZ6Npyaq2OZafotLtXfR9wSG/8vtTppend60EEAjgp0zRtaB4CFy31qweg29T xb8p2P8AtN1fp1VZmOMnHfWH7Wi6WO9Eb7Ia8Ob7jru+il1A7lA213p6eu6m0vFT2vNbiywNIO1w AJa6ODrwprjvqGeiPyOoux8LGwuoevYWspY0fq8tqmi5tbPUp9St0FuniAV2BSOwPcAq6kdiR9jk n62dA2WvGVPovFRa2uwue5z3VN9FgZutBe0iaw4aHwWhhZuLn4tWZh2C7HvbursbwQfjqPMFcc7C yOn19N6lkZ/S6qOkA0dKfbbsqyGWS13qXPb+jf6TRGzdrJMjRdP9X8S3F6VU262u6651mTbZR/NF +Q917vSnlgL/AGnuEhsVHdvWXU1Fgse1hsdsrDiBucQTtbPJgIA6r0t2cenNzKDnN1OILGesBG7+ bndxrwq3XmUtxasy3Jpw3YFzb67skhtO6HVbXkubG5thaD2OuvCwMGq++yjpORkdMpNmYeq1/Z8s 35L2uuOW0V1uppkHj1J+j2SGprx/l+1R0F/y6/2fa9kqw6n012aenty6TnNG52KLG+sBG6TXO7gz wrK5HpFP1a6q/qnS334+VlM6hfkDYXV5db5B9Qb2se11ROxr2SIA17JDevAn8ldL8QHq2XU2OsZW 9r3VO2WtaQS10B210cGHAqayPq90vqXTxnHqV9eVblZPqsurBaXMbVVS02NiA8+nLtunh4K51Xpm J1bAt6fmN3UXAbgIkFpD2mHAtMOAMEEHuCEj08h/aob/AFbD7qWPZW97W2WkithIBcQNx2jvA1U1 xQ+qmLT1rpuLldL6bditdcftbKaKn2gVO2suxto3PB1muW94Zwu040CSmlm9a6ZgZNOLl3+ndka1 t2ucANzaw57mtLWAucGguIBOij0/r3Sep324+FkC22kFzhte0OaHOr31ue0Cxm5pG5kiVh/Wna3q f2VuTj0jrGKMPK9ZtjnV1C3aLW7GPrG713MHqFo3RqeFH6rWtyeqtqGVjW19HxHYmI2hljHW1utD DcfUrYzaPQa39EXN3TrwEo6/878P5BR0/D8f5F65VMjq/SsXGZl5Obj0Y1piu+y1jK3EyYa9zgDw rTiA0k8ASfguK6HfZmXYV/1du6f1TF6XRdjViy+3HvbXa5gZ6lP2e5zHN9GNx+nzAS60npb2ldld tbbK3B9bwHMe0yCDqCCOQVDKy8XDodk5d1ePRXG+61wYxsmBLnEAalVui9Pf03pzMWx7X2B1ljyw bWA22OtLGAzDW7oHkgddwm5junNL6d1ObXc2m90Nt2Nfua0QZc1pL2iOW/NLrXiAgdfAE/Y3mZ2C /HrymZFTsa0tFV7XtNbi87GBrwYO5xgI65PqXSsC3qrMTomdiY2S/Joyep9LL2y8U2V3m5tTDuZb DdTthwPu7FdYl0vx/BXWlJJJJKUkkkkpSSSSSlJJJJKUkkkkpSSSSSlJJJJKUkkkkpSSSSSlJJJJ KUkkkkpSSSSSlJJJJKUsb/mh9W3ZeVl3dPxsizMf6tgupqsh8Q4tLmbvdydefmtlJJTR6X0bp/SR kNwKm0VZVvrOpY1rK2u2MrhjWNaAIZPxUuq9P/aOC/F3+k4ursZZG4NfU9trCWyJG5gkSriSXbwr 8NlOXn9Ax8vH6lU1/p2dWY2vIsLQ6Gtb6ftHt/N8TytMAAADgaJ0klOR1voVnUWXnGyBi25WO7Ev L6/VrfU7dEsD63bmbnbSH9zIKlgdKzWZrM/qWWzKyKaXY9AppNDAx5Y57nNdbcXOca2/nAeS1Ukh p/L+XdR1/l/LsssrH+ruM3odXRsl3rVUCKLWj07GbXE0vY4E7bKxHvHfVayxMb6lfVbHa9p6Zi3B 9jrAbsel5bvO7Y13pztB4mfuS/l9ikv1Yxq8XpIoZlnPLb8n1Ml1fpF1hvsNgLOPa+Rpoeyj9ZW4 DMbHzMzNu6f9kva6i7Ha2yw22NdQ1ja30379wsOgZKudK6XidJwxhYY2UNfZYxkABvqvdaWtDQ0B oLoA8E3UunfbjiPbZ6VmFkMyWEt3g7Q5jmkSPpMe4A9jqkdx5j7Oqv3v8L63/FxqB0S7oeOzG6gb carqFT7brGTcch2SLfSsrrbV6T3WuAMsEA6hdMsbrH1ap6jl0ZlNzsO+u2mzJLGhzciuixtzK7W6 agt9ruW69jC2Uen+ET+A1V1+jznUOn/U1+X1DrXUqce04oZRnHIpZY0Pa1r2Eb63OL9tjQNh10Gp AR/q7jfVsZOZl9DrbjOeK6MrFZT9m2Or3vaXUOrre1zhZy4aiIU7vq1Vbm25P23JbVfkVZduGPQN TraRWGGXUG0D9E3h6u0YHpdTyuoF4ccmumoVhsbRSbDJO47iTZ4BAbfT+X42os+pY1GX07Kxch/p 0X02V2vkDax7S1zpOmgK5jK6z9Ws7o2Obc21rsXayjrdWHkV013NPomxlzqnUhjne1wL9pGhMLqs zFpzcS7DvBNORW6qwAwdrwWug/ArGd0n6ztw3YjeuVNqBMZLsJpyRWHTt3C4Uk7fbPo/KUDsb2Nf h49E9vAn8XT6NhtwekYWEy0ZDcaiupt4EB4Y0N3gAu555VL6y29Eoqx7upZD8PI9TZg34+85PqPg bamVNe6yTEsLXNOm4FXejNwmdIwm9PebMJtFYxnumXVho2OMhpkjyWZ9aX42M/CzPt7un57HurxX Modl+o122y6p2PW0vc0tq1LS0jxTpn1G/wB7fYojt9Gr9WuoCzrefVm5TH5t9dBprdRfh22VVCxv qGjKYzuYOwuHw4XUrmcQnOzum9Uzes052NY5w6ZRhY/pUuv9O7e97zbkPkV7xG5oEeK6ZI/j1QPD bd47Iv6fX1DI6VV1B92LTlNzcvDxsHIyrq7XW/adhycbexgNrJ2uZuiRK2/q8/ByKsrqOBltzMbq N5yGlg2hn6OussIJkO9kukAyeFj3dQwulZmY3D+s3Tsal1j7LcHMbXc6q5znvu2GrJx7Pc4/Rdug 8eC0/qmMN3T7MnH6m3rNuVZ6uVmsDGg27GNDfTq0rhjW+06+KEdv8H86/gmW/wBf5H8XQ6p09nUc J+I55qLix7LGgEtfW9ttboOhhzRosjqPSbR03q2V1fPr35OKKbMinHeyuqmr1H7hT61rnOBscZ3e EBX/AKyN6a/oeWzqlbrsR7Nj6mAOe5ziG1trB/PLyNvmuWy2fUZ2Jbg2dELLaqizqV1WHjNvwgT6 XrXOYNrSfpg1h2g3AbUhvSe3a3u2/REGdOVzX1kxXPz/AEWZeFjDrOOMC5uU/bdta8ndjVkEWu23 OG0xrtOvC6VoAaANQBosPqXRcXP6rlG91Dxk9P8AszmWQ62oeo9zbGsP5ridTI1aPkDvte+nfQ6f VEdt6+X8x+W7V+rlD7OoN/XMHJo6NjOwKG4Tw+yHvb7shgEVENpaNonXcfJdM4gNJPAEn4LnuiYf R39Rx8ro2TiX4+BhHBs+yva9xLnsez1BXIAGxxEmZJXQWNLmOaOXAgfNGd13NS366n891DfsNPpp t9Hi+h32Zl2Ff9Xbun9Uxel0XY1Ysvtx7212uYGepT9nucxzfRjcfp8wF1HRenv6b05mLY9r7A6y x5YNrAbbHWljAZhrd0DyWNg9G+r2fg4nTL7se/q/SKK6H34V23JofW30ztsqLbWDdOh08QtvpTDX hNqOa7qPpuez7S/YXna5zdrzUGtLmRtOnI11RPUXfY9wo/y8Cg63h15dnTQ59QdRmMuZTcQBYWMs kNEGXNBL26ct7crH/YvQmXnpeBkYbeoDqNfUbKWuY2+trHts2traXO+h7ewgrX63h2ZNvT34+XTh 5WPkGzH9es2tscaba3MDG20uJ2uLtHdllM6b08CnpFeZhXdZpzx1HI2ltdwLrfXte2ndbYCa3bNT 9HuhHceY/OOv0pUtv8H/AL7+L1K5W7F+quPiHpn1lysAZDci/KqFt7araxfe+9jq3udXYx0Eathd Uuexul9Z6Vn51vT8bAy6c6w3G659mNk7nOe4steyjIFrW7oZ9GBoknp9Q6PRMYY+EBX1CzqeNYd+ Nfc5trhW4CG+swD1BOocZPmUXqvTMTq2Bb0/MbuouA3ARILSHtMOBaYcAYIIPcEKh9VunP6fiZFN z8X7Q+82X42A3Zj0PLK/0VbCZEgB5mJLphXur49eT0zJpsyX4LDWScuuw1Oq2+71N7XNgNiTrwlL 7dAf5H9qBv8AX+Wjyzvqni4vUcM53Sumv6ZierZkdSFNFILPTcGjJpLWt3B2u5vt7wzhdoIgRx2h cvd0LoPUuhZDqeq22UvpfXZnN6hlXY7XBsPe5j8t7C0clrnfFdQ0Q0AGYA1RKPHvf02eZ+s9EZZa c3Bw6usYwwL/ALZYGWbWvJ3Y7He2x225w2mNdp14RukdMzsTqeNXnXYorwMN+L0+ugkW217699tl bmtDNrWViGSJJ1EgK5f0VmR1t+dkV05GLbh/ZH12jcW/pC8hrXNLS2wO939Ucql0voduJ1xt2LlV 3dJw6LsanGLi63HssdS807tZraK5aHatmOIgR6f4X7a/P8Uy6/4P7P4fg9BYJrcJiWkSeOFzDuk/ Vqv6v9Kd1rIxqbcbHqpxuq13ihwcK4Bx8oOrdB1IEwfBdO9u5jm8bgRPxXF9Jv6TiPxrc7qdGdX0 ak4GJXXhXMscbXNo31h1lxuLvRLJqbH0kO42uj9lp6fy6vWdNosowqqn5b8+ASzKs2b3sJlm41hr XQ2BMa8oHV+m5Wa/Duw8ivGvwbjcx1tRuY6a7KS0sbbSeLJ+khfVWuhnQ8f7NZXZjvNtlBpJNba7 LXvZW2WsI2NO2NoiIQfrbkdNp6fS3qHUX9KF2RWynIY+6sF+p2WOx31kMc0GZcAOZCdLf6oGx8js hs6BXi9Oxq7Lcf7S3qLM23Mc30Jssv3v9MONp3PDvSALtRpK6JYFn1a6Zm0Y9+HmZL2NtoyarXZm TlVPbVYy76FmQ6twcGwDrHK30ulf1jp9AP2K634ftJUkkkgpSSSSSlJJJJKUkkkkpSSSSSlJJJJK UkkkkpSSSSSlJJJJKUkkkkpSSSSSlJJJJKUkkkkpSSSSSlJJJJKUkkkkpSSSSSlJJJJKUkkkkpSS SSSlJJJJKYXU1ZFL6LmCyq1pZYxwkOa4Q4EeYWNjfUr6rY+KzGPTMS7Y3aLrcel1hHbc4ViSPHnx 1W4klX4qa/T8Krp+Bj4FBc6rFqZTWXwXFrGhomABOnghZXTvX6lhdQbZsfhi1jmFu4PZcGyAZG0h zGmfl3V1JImzfVTjX/Vql3W8bq2Nc7HbVa6/JxWtBrutNT6W29tj4s1cPpCJ4C2UkkldbcXqHQ8l rcm7ot4xrskO9fFu3OxbXPBl20a1PJM72cnVzXLR6ZjWYnTcTEsINmPTXU8t1BLGhpiY00VlJIaW O9fht+ajqb8/x/3mp1XAPUMCzFbaaLHbX1XAB2yytwsrftOh2vaDCxbfqn1C1uTu6q4P6n7eqkUj bZXIAbjtNh9GK5rmXaGTrqulSS8VLAAAAcBYnX+jZuY3Ls6eaXW52I7Bvrvc6sbffse2xjbCNvqO luz3eIhbiy+o9Dbn59OU/Kyaqq2Ortx6cjIpa+dWO/V7qoc09yDI+UA6pBrbw/AtfAxc39r05XUv suLkVYj6KcXFtdabGb63PsJsrpO1hAAaGmJ51W2snF+ruPidWq6jRfe706LaHVZF9+TPqOqfua7I ts2x6fAGvyWsUTqPt08yfzQBX4fk8jjYP1dp6IzHyOoYWNndHe5jep0XVh9Fznu2vsc6IdZ/hGO0 cZBlbX1YxMnE6PWzKtpyLrbLsg3YxJpcL7X3tczd2h/+0qn036o4mO3pT8iul1/SmWsDmsn1N5O2 wuIb7tS46H3E/FaHQemu6X0xmG7YNtlr2srnYxtlr7W1skDRodA0R7/yCjr9rDreHbkPwLaMunDy MbIL6DfWbWWOdVbV6ewW0kna8nR3ZZTOndOaKOkMzcK3rVWeOoZG0tqu3Ot+0WuZTutsk1nZqfo9 4W51TBsy2UWUOazJw7hkUGwFzC4NdW5rgCD7mPcJ7c6xCxcTonXH1sxMyrDx8dueeoG+m6y62fXO T6Ya/HpEknaX7vo9kI7jzB+wj+X0VLbvpX/S/j+L065t+F0JvUeoHM6zaXNIyLMYdRyKTjMIG7c2 vKaGskgiWiJ8IXSLnm/VLFt/pddLyzqVnUGWbNzniw79lkhsEGG99Gj4Bdf2/Uf76un12+hbf1ew MHFqysjp+X9txc+/167fVdkRFddJb677LHP1r5ny7KX1lwxm9FvxjZVXvNZH2h22pxbYxwrsOvts I2HTul0XCrxLup+m+oi/MdcaaTIrLq6tHjTa90byP5SP1nGqyum3MtubjNZtuF9kFlbqXNua94Lm gta5gJ1GiROgPhH8v2KG/wBT+bgfWjpfTrnXYvTc7D6Z1zqNPoPx7XtYMqt4NbRZU07nOb+Y8NkR HEhdW0Q0A9gAuNFGd1HC6taLel/s3qj91/Uact1wpbXVXS9wHoNYS0V7hNg2nuV2Q4EGfNHoFHcf V5r609K6FdmY+dmXYNWeW+jRV1JtVlN7WmfT23e4EF+jqyDrqHDRS+qvSMXp12U+/p2L0zqGTda+ mmn0i/7OBU0+m6sNca9+vA5EgFXLumY2T9YLci8Y+TU7BGPfj2w57Gusc4H0yCNlo3B0/ujntn9C wMc9abldK6jjZ3RsPHtoporsFtmO+51L/S3tLgawKvaHGW8cRAjp9RL6a/tr8VS1+hj9dP2W9OuR HQesYX2LMttwGN6Ax1WB6hc1llTz6b3X2uYTS70w0Dbu90kyDC69ebde6T9Wel0ZPT8Q9HyHPOwU 5L8SnNxnOIPttft9RoHawh/8p3CQ3/l/Lqr9Evc9DwMjA6ayjKcx+S99l2QagRX6l9jrntr3a7QX wJUOsUNN2Bn23VUY3Tr35GRZc7Y0MNFtP0jpzYOSFdxMXDxMdlGFTXj4zZNdVLWsYNx3Ha1gA1Jl UPrFj+pi05fqU1/s69uXGU706HbA5sWWQ7ZG7cHQYIGiROt+P2KGt9bEvrf8XOwMD6s5HUPtH1Z6 lVjZDXC3Kx+n31vptbLWu9bGBfWJGm9oDp7rplyGF9l6rY92Nn9Ot6o/Pq6h6OJktv8ARrqFVNux zWNe4vrYQZaB7oXXo9B+X0H+8rqVJJJIKUkkkkpSSSSSlJJJJKUkkkkpSSSSSlJJJJKUkkkkpSSS SSlJJJJKUkkkkpSSSSSlJJJJKUkkkkpSSSSSlJJJJKUkkkkpSSSSSlJJJJKUkkkkpSSSSSlJJJJK UkkkkpSSSSSlJJJJKUkkkkpSSSSSlJJJJKUkkkkpSSSSSlLG/wCbVL8vKyL8zNsZkP8AUqqZmZdQ qke5rfSyGt2zqBtEfCI2UklOd0fo1fSjmCq2y1mXf649V77Ht/R11bTbc+x7/wCbmSfJL6wdNs6p 0m/Cq2b7CxwbbPpv9N7bPTs2gna/btOnBWikl28K/DZTzv1i+q783GyrOjOqweoZdRoyCQRTfW5p ZtuDB9Jk+x8SOOCQuhaIaAewATpJK7eDg9X+r2fnZObZjZtWPT1HFZh5NdlDrXbGG3Wt7ciqCRae WlW6+kNp6zTm49dVNFWG7Fc1g2ud72OqaWhsbaw07de/C00khp+P4iv2qOu/8qr+AUuXw+jdf6V0 /J6Vh4fS8rHs3Cu+51lBsDmBu7LpZRcLXn847xuHguoWJjfVXHra8ZGZnZBNjnVu+3ZrCGOMtY7b kwdvEgDRLv4ik3+bY+rmG3B6RVituqvNbrd7scRS15se59Vbdztra3HYBOkKv9bsKrK6ULLbsSlu JYLx+0QHYb3AOrazIBc32kv0PYwdeFc6L0tvScH7E2x1zRbdYHvLi6LrX2w5z3Pc4jfEk68qHWum WdQGEWCtwxMuvJfVbOx7WBzTwHat3bm6fSA+KR1I8xr213+iBpf+F9f99x8irqHWLOm5uSOlY2BR cy2vOpvdlWud6jNleNa6mhrBaW7HaukGIXVLneqfVex2RXd0d9eJVblUZHUcVwIqt9K1lxtYGfQt 9kExDvzuAR0SPT/COn2aq/gFJJJIKUkkkkpSSSSSlJJJJKUkkkkpSSSSSlJJJJKUkkkkpSSSSSlJ JJJKUkkkkpSSSSSlJJJJKUkkkkpSSSSSlLNwvrH0bPtzacXJD39NJGYC17Nm0uadXtbuEsOrZWkv PbPqh191rvQrFVfUczLx+pkvZP2C+4XssbD/AKUBwA1Pu4S1uu4Ovj0TpV+I+zq9r0nrHTus4Yze m2+vjlxZvLHs9zeRtsa134K6vOb/AKn9XsLa8nFut6d9qz3nExjhuePXeDRcG5u6r6EjkPb27rTy Pq/1NnWem5WJi2ZIqx6se6/PdRaa62NdL22g+tVkAnV1Ycx0z2S6A960+iO47X+BezSXnVP1a67X 00YB6Ux2C3Ka4g1dPdnPrFT/AH2eqX4r3NeQ31HDeRJhY32duHlYXTfrHWDZiU4VbqizHvvGy+1z WY3qZFbtrgWtf6VdkjTQ6IgagdzEfaNfsUdj5E/YafXlR6j1rp3TX115djhZcHOrrqrsueWs+m/Z Sx7g1s6uIhcz0H6tZuL9YHdQ6hVlnKF+Q8ZtbsMY9lVs+m20jbluAbADHSGkCNFofW7peVmGm/p+ Lku6jSx4xM7DvrodU8lp2XC57Q6pxAkQ7voh0ie+47K6kdti7WJnty7cittNtbcd7WC2xu2u0Oa1 ++l0nc33RPirS8+6n9Wut5Lc+vN6a3qH2/JxHXZFX2cvbXXQxmRZjjIsr2Oc5pYOCAZVln1Yy3fW T7dk42Y2pt2PZgW4zsINoprY1v2e11h9drWncHNqcWuB7ojevL8hf5o6X5mvyerzerYuFmYeHYHu vz3PbU1gBhtTDZY98kQ1o/EhV+mfWfovVbmUYV73WW1m6kWU3UiytpDXOrddWwPAJ/NlUOttdX9b Oi5Dh+iupzMVruwue1ljB8XNrdC53pf1M6lbi4uHl4l2E1mDkY3ULsm9l7HF8Op+ytbdca9lgDzA YNO6aDoSex/C/wCA+1cR+z8ev5/Y97mdQw8E44yrPTOXc3Ho0c7da8Etb7QYnadTorK8z6d0LP67 0nF+sGfhs6jm259FttUVuNmHjVnHLWHIcxsPdL4JErXf9Ws2z61WdRy6ct7PtFNuDk4rsMNqqY1r TTY66MhrQd25tR2uB8U6taPf8KH8Stv8vxs/weo6Z1XG6k3INAex2JfZi312ABzbKzrwSIcCHDyK urnfqoDbm9ezGfzGR1FzaT2d6NddNjh/baR8l0SHSJ7xiftFp6nwlIfYVJJJJKUkkkkpSSSSSlJJ JJKUkkkkpSSSSSlJJJJKUkkkkpSSSSSlJJJJKUkkkkpSSSSSlJJJJKUkkkkpSSSSSlJJJJKUkkkk pSSSSSlJJJJKUkkkkpSSSSSlJJJJKUkkkkpSSSSSlJJJJKUkkkkpSSSSSlJJJJKUkkkkpSSSSSlJ JJJKUkkkkpSSSSSlJJJJKUkkkkpSSSSSlJJJJKUkkkkpSSSSSlJJJJKUkkkkpSSSSSlJJJJKUkkk kpSSSSSlJJJJKUkkkkpSSSSSlJJJJKUkkkkpSSSSSlJJJJKf/9kKDWVuZHN0cmVhbQ1lbmRvYmoN MjQgMCBvYmoNPDwgL0ZpbHRlciAvRmxhdGVEZWNvZGUgL0xlbmd0aCA4MA0+Pg1zdHJlYW0KeJxT COQq5CpUsDBQAEEjIDI3UDAxUEjOVdCPyDRVcMlXCORyCuECcgxNFSwUQtK4DMFKDRWMDYAqTRVC crk0jEzMNUOyuFxDuAK5AMTJEQENZW5kc3RyZWFtDWVuZG9iag0yNSAwIG9iag08PCAvTGFzdENo YXIgMTMxIC9TdWJ0eXBlIC9UeXBlMSAvRm9udERlc2NyaXB0b3IgMTEwIDAgUiAvQmFzZUZvbnQg L0JOTElMSCtDYW1icmlhTWF0aCAvRW5jb2RpbmcgMTA0IDAgUiAvV2lkdGhzDVsgMTMyNiAzNTkg NTM5IDU5NyAzMTYgNzA4IDYyOCA2MjMgNTg3IDQ4MyA1MzYgNjMzIDYyNSA2MzAgNDYwIDczMiA2 OTIgNjIwIDY4OSAzMTcgNTgwIDMxNiA0OTYgNTQ3IDc0NyA3ODUgNzEyIDc3MSA2MDcgNTA3IDIy MCA3NDkgNTk1IDcyOCA2MzcgNjI1IDUyOSA2NzYgNDE1IDQxNSA1MzIgNzQ3IDIwNSA2NTggNjU4 IDY1OCA1NTQgNTU0IDU1NCA2NTggNjU4IDY1OCA2NTggNjU4IDY1OCA2NTggNjU4IDY1OCA3NDkg NzQ3IDc0OSA2NTggNjU4IDYyMyA2NTggNTYzIDY2MiA1NzUgNjU4IDYxMSA2ODcgMzI0IDY1OCA2 NTggNTM3IDgxNSA2ODEgNjUzIDU2OCA2NTggNjIxIDQ5NiA1OTMgNjQ4IDYwNCA2NTggNjU4IDY1 OCA2NTggNjU4IDY1OCA2NTggNjU4IDM3MSA2NTggNDg4IDU0NyA0NDEgNTU1IDQ4OCAzMDMgNDk0 IDU1MiAyNzggMjY2IDY1OCAyNzEgNjU4IDU1OCA1MzEgNTU2IDU0NyA2NTggNDMwIDMzOCA1NTIg NTA0IDc3NCA0ODMgNTA0IDY1OCAzODcgMzE2IDM4NyA2NTggNjU4IDY1OCA2NTggNjU4IDc1Mg1d IC9GaXJzdENoYXIgMiAvVHlwZSAvRm9udCAvVG9Vbmljb2RlIDk4IDAgUg0+Pg1lbmRvYmoNMjYg MCBvYmoNPDwgL0Nyb3BCb3gNWyAwIDAgNjEyIDc5Mg1dIC9CbGVlZEJveA1bIDAgMCA2MTIgNzky DV0gL01lZGlhQm94DVsgMCAwIDYxMiA3OTINXSAvUm90YXRlIDAgL1RyaW1Cb3gNWyAwIDAgNjEy IDc5Mg1dIC9UaHVtYiA2OCAwIFIgL1Jlc291cmNlcw08PCAvRm9udA08PCAvRjEgNjcgMCBSIC9G MiA3MiAwIFIgL0Y0IDU3IDAgUiAvRjUgNjIgMCBSIC9YaTE1IDExNyAwIFIgL0Y3IDU4IDAgUg0+ PiAvUHJvY1NldA1bIC9QREYgL1RleHQgL0ltYWdlQiAvSW1hZ2VDIC9JbWFnZUkNXSAvRXh0R1N0 YXRlDTw8IC9HUzEgNDIgMCBSIC9HUzIgNDcgMCBSDT4+IC9YT2JqZWN0DTw8IC9YaTUgMTIzIDAg Ug0+Pg0+PiAvQXJ0Qm94DVsgMCAwIDYxMiA3OTINXSAvUGFyZW50IDM3IDAgUiAvQ29udGVudHMN WyAyOSAwIFIgNjMgMCBSIDI0IDAgUg1dIC9UeXBlIC9QYWdlDT4+DWVuZG9iag0yNyAwIG9iag08 PCAvRmlsdGVyIC9GbGF0ZURlY29kZSAvTGVuZ3RoIDMzNg0+Pg1zdHJlYW0KSIm0UluVQkEMqwUs YKEWsICFWLgWsBALWMBCLGABC9lkPGz/eqZN85iZ1M5ghjOacbvdWcxyVrPuI3aAAQcauLPcIYYc auiuakcYcaSRgzTeMcYca+wCFzpYWc60e6eFXe5q1z2bDlhwoYXLIo/EkkstXVKZFVZcaeVwzOoa a661dilXQ0iHZWi5Cnop0MHKsiuofYqAAFdfzqYjQYGu3LDIowgJctSHVGZhwoJdM2pWtmNH9Lve VFLAQjosXat6ONiBDpbrXJ/Tp0S6RkZfzqaTKMfXyA2LPNKiXZubCjpbo13X6x26WjvcEKoQRSpp N5PyQIEL7UbUafROy0ksRkZfzqaT7fMbfPL2SdQnM59UfHz3cdbHOx93fPT7KPTR4MPSh4fPJR8s n2mf/na73e/3x+PxfD6v63q9Xu/3+/P5fL/f3+/nf6u/AQAQcatjDWVuZHN0cmVhbQ1lbmRvYmoN MjggMCBvYmoNPDwgL0ZpbHRlciAvRmxhdGVEZWNvZGUgL0xlbmd0aCA3ODczDT4+DXN0cmVhbQpI icxXS3MbuRG+81fgOFO1HA/ewHGt2KmkslnHlpNDKocxSUlT5kNLUtY6vz5fN0BqhqIhKrmkWMXB o79Go9/4bfLmj5+0uN1NpGjxk0I2Loi2Cd4YMVtN3nxcLLt9/21xtVlutv1qsd/2M7HtJ2+udk7M dpOWcbvZevL2GpPr7aRtWu3E9ePkzXsFhtc3E4mlkPjzyBrhpWykEteryT+rXR2q+0UtbcV/c9HX 0lVrsafPXT1VBhs6VqLGaMvzjilumV5saP2G/oRUgb9vv9cmVPt6GhJPOkLwdJPotGy9OkPqmPSn eipVJR5rrY4CgMt2IMtz4f4lrv88eXdNepjimtLiejNoQ4WoSB24sNHi+i/n1OFibGwM1iWNXOF8 26jqQz31+HzGWQ0usEvT+xr8FY6d6kDfuSDy6n6ZFzpIpfH9DvEByyhxWBbzRWY/6/NSJjlMvx0I BG6sIwabOoDTMu8vkgANpsz5fYInogNEXI2mizm4S4PR/iBHPnWWuN0dCR/qqcPg6bQ28WGRYBoG D9UNLUKNrGxpPOv6jIpDaFrvD063IdtCk7Dighxgy0O4+qa2cC2e7cjGYrAgeAX0Pi/M+b8nBmnh NtHVnsyg9JFMk8jK5mMW5Hkz2l/QX/+N9vsDB60rsSKK7ms6jjj+nf6hUvgEBp9r02bx+P+R5v1+ Rqg7Xj51x6OCdDyrIN3EEOGozrvGWoskwGq6IWZkQ7JDqH57gO0j3UqTIdklQPCdjhc9j284Jvc8 ftwk2a8ouj583onE6YGjl4fpv88qxvCWEcT6Lp+qZYr89VGKPisqRSAWv9Bw8yQq0z/x2Kbg9hQZ yWiafJ6in/6W2YjJMnzc0LlyFLdPQSzPRvFRg84iA2qlkwb7fFk6jXILp67VMTOJqw9Y/FwfpE45 5oEvLEjdoH5gylFS6onB8onLH9gzXDX9hMGMEtIgb80fmDJJcstS/ICEU9n2h8EVTTmRHVWAkZXS x6QC9vRuTf+Copx8nLyAVmsKvTAMlv0iBwa7ETt0jhnNCekQgd1yCmM1str3RLVKBH12lcQIZDmw WQZm13PorwWduhoE922ywZRdh47NbsNSYj5PHtPt2NmfqcglHbWtPihJxrKSjGqUVsonJT1Skk/X xGe5TAdhKJYkMAbdPH3Flzxfdol4zbkxZZTEwuDT1Irhz52Z5VNJJiVUcI1WwkQk4xz1z7OHybeT NlV2mSp7bDIfHjikbSOM98fS/p6iCvaGrTk2JRsWQrmmlmcD7Vxykq1pxnzfHoG/HTuXqWki7GAE y6udj5E6mFZ4UjaQUx9lAxfeLib/mKyp87HDzucAn47x3OhcfcqNzqerv3JJD+KRZJbU8LxGXGAU N0nnXEOiKbKRStQQ3A3BzyFE2EY3gqyLEDiJdq0JI8i8DImNtr71I8hjEaLhTlChHUH6MiQ2EXeR rxDMuEbiLnoE2Zch6DK8kWML3RUh1iKdaTdWsihDQiOtceoV13cSdcPbV1jSeSCMfIVYDirG39j2 n4oQNAQ6RjO+yXUREtB3BkqJQ8jHIiS21J2dCPauDEFT3Eo9NuTPJYhqdeOtt2Md/1KESAVDahku V7JCm+vjqYd9KUIU2f7UwxZlCDVqr3EXFBvI5dqxJWdlSGi0jCeWLAaLMgZyRT1W2KoIQU00+vSU Yt5TiK/o9DghbYsIB6dszYkhv5Yh/GQ4UdiT7f92rCEAH1+745qIUtF4JTQyqD3nPGeqq2yM8YYK xA/qrKe7C41+Abbx8oVS65vzVbZNJ5hzJ0i4sAko5ieHPIn+39fd/6Xecu08auV5MURGCEnmi5IO +qT0JBxCHso1ivKU8WNIOUtrUiG9By6HoDXUsg1jSLl6GIv+XMNQl59i0aTGdnzIbRnhG6NiGN/+ hYrT4ipocoeIcoF2yAYK3fErLo/OU7dxfJNiypGe1NX6sbcUE64MbeMllfTLLx/Qallrx6dsyhAk ChSPEeKmXAdVEy2c8hVyRTQ0UY6N8utLldPCx8Y3uS9DIootzHK5ihWeMa227SucmCqn8tqOrVIu 6cjFzrfSjSAfynUQfaZVTl6uY4VuFs2ZCa8QzCC8tJSv8HxlKbzGpi9XdPSyQfswhpQrpyV9Ba0u 92LlLCAmjvU1HUEaZLl49hmEDsJ49oKWOqlo/ZkW6vwLylKMWmtOoeXItni4amjlFPVC960gpg/x FFXUv6SeopVen6LKLxBvGmVa9exe5SSH9CPVmbPKT0p0LM4Y605RRSehLGSCa+0pqthhobNo8Lbw zzS/eykZ4QnnnqGGrdn53uoHHVVwDfogE5rwQjMVmlrKSvxf9EFPrdzzxsY3anif8gtP6yYqvD6G iHLAILep1qowRLzQ0Vh0tWYEmL/UnLigtRwiyh6IzGbV+IjyLRweXfDZkeVfCF68udAD+CHiWzlw VdNGO75GuTYj1L12anTGCy1D20Q8a+MQUW4ZgmmgWqMulwoREj2S5BDxp5camWBRM4eIYvnDO7NR Vo6u8bacB8ipYnv5NVSL7BtiHF3jSxGBl5BWwV7sVUrSvZU2F8eGUg4+Ag1f7IdKy0Z7VPEholhA lPYNcpAaKbdYPJRBTownZxQLh7LwdemdujhkuRmxYRQcxXqBDgwNNTqL8xY/Zn1pc9pXAQmX8746 /2ZERKOqUgo8tsFTdGF4BYKPodyv6Su+1KiKsDyvrrEa8Z3VSmP1Lk9X3TaPvu5ErUx112EeMP82 RItOPNZoixxauykYmGqOHbS+2JptmPJA3zZcfphnl4lvidgwn1VeSqB1Yn9bTx3tXmWeH9KFPteY uXEPRhUHj8yDpjzXEvRl+lxvZQ2oqQKhpaB+EA1CCp9NbdCEVg9rOshXc1FrVXX392l52UNLiKGq 26dvv8E+vmuWz6PUM13DGhOfSDO6uq5p7WOifMeTn9POL+nD1P0uTzoyBL7777WlhfseGtHV4eSl WKTR78ypqyl+qtX9kqnynshy3aSPOFGUQiQc1CPL+sEcLaWUOWZ2pJdQsWgqXzsk2RR8B6onGxPJ ZkzCAqnqYZdIxeohLSz3fVqZsvz7A6eQODF2kRZZMQqllvZ+qhUdJn4lrSm83mhxkSjWPFndpxPE Pi/vEumepRR5lsXoD0TJ15lBx4SZjte7B944Cnm4Gt/0IG2+Tzrme5bh1ACHkL7UT1FOnKYuMT+j TFutRW18dddDPsSJCdUdy7gjj/1ee6hhVutY3W1pdcMLjPs3AToa7WnE+A3h1z/VriX/I+ZzAog9 je8WtSN/JMJH3DVRI4sYMg2OyAetiLij4fbrrg5gdUMkWybnzVM1tKgTrAcZtbnQI4Nv8KpU6lC2 KVv8klLQW1I2Gttum9PFIuU0kXPbJu2vVnmwzttEDUfgCczN2SrtsC1PCO/TpOOTt/zfJbLlcpEH sET2ZVcdhOkOvNJ0l2S+SaLkAxO7RvycNpdDdv0Yz2vdgYLDwZGReH53VIDxLPhA76mmHDIlvaiS 4tHkFBXv4dz/obxqmtvGkeg9v4JHqsqiCQIgyOsm8VYOs5PdJDNbNZUDI9E2K7LklSl7nF+/rz9A kZIlJweJJIBuNBrdr19bGxQJ2r/vW64nVkGdDETDmgqOA4nWPRcMNlKGOD7jai4gNmVAsVKiALAq 0quEzsr51ypJABC03gAXG32JMqo46bViWU7FkCbvRBlqCEHknF1k0U7w6OI22rXcUdFhW1ifHCtu fsObJ2qYaI5HamTnvSE0efMs6vZ38EqTRakhl+PRaOFu5qUVxDi+HGtQpQDPZRIMXaEvrVwPLgeh CsPg8WsBAPE9/nFDFTyLFH4irOCVKxpbUYYnDAhrvqs1r9/NohBnuyhhfTvW8vYj/r9QHNfwKpKZ yijNiviSVfUk38SdvzNKof8ExrwXFMIMI8wtC8lOp2CzdmdRc++Vsq4zXzvwcPYKbf0CNBL28T/O A3hL+H0riE8mTSCVAPFluQs+zjta/HFmc/gCqz7R50JhFHsu6Q9Fx4q3BckZvhO2SdCX3k4nbe29 JO3pc1foDUIRvCbrtQZ7fLaLfohueT5K7La6APHgKGq5fgUKClkW02AxpHEzTdWYfW9V0UcZ/kKA Bj27CArdkF4/9KU5NGnDqbYW1P32PKPTpcl2n6cLLGTgOUjOI8eVRY3cYt8Byl7zXSgz741VoNut iQuybxYtDlnJWSvJd2ZbMIlp3zNxMex/p+OdPm9mQVCCCV6U6uP0hqfX+pVNg56tJoPrDGhA9vIL mtHMAZxx7Ny90CzOGVP0yMZLurjCcG29vDLSQEx1Wo9DwFE+8dTFhdor3biCpaZObwAEUs6YZyJR amSwGW38P5ga6iJBd5bMQ20oUbftmz/frN9cvn0ok7ef3uS836e3/2KaXiVPZC1gbjs66tHdIJrB 0Nkq7ZPeHzjpBRCoPTawdir397mOzOV5ViFtJhJnm1eX40atgafHIme7V2eKzIf84Dxnm1FnkM21 tfVEZH1WBLGU13k9Fbk5K0LF3ObeTETa8yLU81o7PX5yXgQ9ZA3cHktszko4lwVrq+m1XJ8XIYfl rvwFuxD8weZuusuH8yKgbMZOj/LbWYmyQFrW9dRf/zgvUmdFHvJfOUowWeWqfHqUb+dF4LAqePcL d1/R6XMbfiEoqxqG1VX9CwmGLAYUV+bnE8znJrMht9Pj350VwaPw9PKzKelR3EJw5dRh2/MiNRxG nG4s8v2sSIHTGxfCicv/97REXF4VL+I6lTbEDxhi+VL8XF45EVOhvYir0bxqeSmzI8i9vPJHgrCz qiaCR02fi6WYsIbNPt7fWkTKRM1/ZiX4ZYsKX1NfRGQTXAn/vYwtkz/5ueH/7fcXymhWhspNHHVU NGyOjIMCr4xx4LZE+SvEKqhIZKigb8sdE2ehzDx8Q6QvuWcCrHNzlXtmlne/GpgwDzCF5k8hgEKv dyzBeps9Nacm0Y8J+EpYOZbynI2WmBd7vlK8YFxZDvzZnCTQJZVn50OG1sT7mBNz7lMXxPLwaFc6 0MqAkLNyWNfrk3ooRzx3XnKXeqvruO0lfwnv3Cu4xi06vks3jN01a31btIlMXYM6QfwPIpklsJcf Scec0YHT0hrZOyrpd42+rTo17sdgbRwR5WsWzIj7kNbPh0YfxnWlYR38SYIpPnU+q41TftlrY0Y3 vaRA63ik29D7WsaxYbpCABryvAsUgYbtcByB/O6UYaa87AKUNBUJhJLnoNUoSRseBkPHBtuoyaIz oWClVu2lnWR+h9+Kv7YSttwkVjyXfCKp9+/o/4q6mItZkacvpaEJ8MJ5F1lQ4dpQnErYDc2sBPtu 351yfj3OYkbKKkqqZuhrk2vp1wpRYrNa0iXE3BoS7Lvkz5KTkjOMRSU/7+8PEpqbw34Yk4Zw2J8C B7DxFykozNeELX+UpjLuuhs++yGTl7zjUfY6DS9TmPCK8wCOVVkXMcBuueWCdj50zUmJFekTdVQF zAbDoFhBbtLBUArTQWRm8MUo50mk3erEg8gmqqNTlf0td2uZSZcYsgFDlMkF/mmTQbxd60ufLGT/ OCALo74btmaH3fFBseoyxk7ZjI2LS6dq9DRZ8kGHyYiEL9/oHjseI2eALuGLxgb7eN+L49JVaI6D kiiEmvoVBEXZ9VVdxoKyZTxh19KOS9QwOkSRizGoe2lSUNTQbFF8hYttSUtWq+TbrCCbW1mdAC9U Bz8IQ9HAxE++ibTfiEzSi9DtsL3o+O8M/UgRrVnrbMI4IEu2UwldmRHWYuGHfmSg6kTOSGDxysVO ng+JmrLf5ASAelBkdC6xRL3iXzRteVkVfgSnI9SCMYC5piO8Wu9hkxFOcJDR9W4Etzf8n1A2/0Er ftsD6hPh2mYPnN/5v9PEZ1lb6DLeHpeGBBiLJCvO+Z4RW4QWzzNv0jni0YhNLLreo3nXd4+kQU50 DA1eHVeUr5QeW1WZB8FRaHiiLPGcOl5j3+NM9IWMd/s5STnCJvpCclkENfmEBhN1OUs/zyxxFC7o dqS1Vw23GPA00TZAWco9+DZp1rpMNhBQEOFAa5GOXnLaM7kCHnjBrzgZ90FcFrzqKLhCZJ3o2F5y EqifDQFO9Ohp2D2fcbBMaqAHt2rlczv9TATCuZyMpuiT6yie+vkojxZH2y9tYH0gQsu6FkRs8dmo pD46XoRINsPHQgtYD6Lgac2a0dFGEY57PDfyiNslzb0M3CPasFG3kJ2bXp6drl/r+gdEMj4v4lF2 Mr2IPpHT66ojnwfNaJfXxU8wzlDUZQKymfm8IAG6A+xL2N8Rv6QEDVwV6H8lQ60UtTmP9fRR4cb4 QTEh4MYVopHHUiYvWeBOlOxkbCVKuvnM5lwoVVvQ6lPG/bgI5Qy9QaohGXkxE1zTT2Q1PdYquJDt p9o2dKeVnqv7obp1426YlcWXEh3NK/r5seUcHW3Aox1fW5H+UI/MT0Cwqd3r8CvXhWSuK2YnDL+R t1aKmAxZPUUZpSYGfidsXI8AWhCOgXPdzYgBEAleMFPd42AvoNrg0MTwBbp73izhtZIzipeEuc88 14+48h0KKLvNjsbdUdwad5pgVTZ3iXVF5kqwATkzG4F8SpUYM2WXvByDODa3hSzG5swveUFFVLxK P9KaL3TGRI9NoUpH+IC3y9/3jFpLnMQJUUXw2k5ZP81PtGVcWFLdu+IEJqugTbTrZrYQEn9YXAqn EeG9+4kUrq0pCEqz2gavlOcDU+JLSsb0dw5Wskl4+LfNDsYEbE4cm/1ITFsJMozseBT9Zp3Kgsi3 6Tx0DuZ6OKzS7c80fcvjrXYN/Ar5683wwdFpcSd39N7QrOh6Zo+KxsVY1ZxuA8t29AfTykKUbtUE uO6bGPiggYXJ5SmKY0JuXk2wKrfwJSDFmdL4UaxJUCWHVOdOWxW8dqP3nmm/wRhDf60RypqYVXR8 +8Jc6DQCaGgcKTcWs0r3kERFYbeGq0/aNSvZ5Z4TYDXK2+Pozzg0P49NPs68YmDVZ2KsMrbAW463 Olbqp1k8UeRluI8udqdg0wHnLvBqyfqvNHa/Xy0JvKEM29Mv3F01BiBBMganEUJ17Rii9pmaiGfJ Atmj58QTjzHOHziJ6rWJRzjixqXi8Ul3AIozG0xRij8IHQRSGWnaPaBUeo+Mo/zWCzY+7FmuomRJ EMUNnJx4xdY1pKMbs93+8FJfO7sbnf3wqErSgLOxBTh95grdoKsimb0mxTtKVGXVlP4RLYiCczRQ uq+4RtArTz8TfU8UkK4Vw7GYJRggcERI3PJoy1j+T4bSuWI+pT+rQnWr0k8C7rId91Fx+2Q5iDyy M+iT7WxnEcKQqclf5iviU/wXDeHvzcNMcW3JM6fwpdQShva0OtmfMr4UAWQ85FZ82Egt5Yu+u9sN Nfkoqz1Xleb/jFfbcuO4EX3XV+DRqoq5JIgL+ZiaTVLzMNnd8u5mq1zzwLFlWxnqEl3s8t/n9AUg Kcn2zJRFstFoNBqN06elJg9lTyr6STnjzGILT2eti6/VYXbhhc7/3FkX0SV4h1I09XZxf+y5m8iM m1hPK7Q0cJLK11/UrGalLP7GHPiVf98rfD+CSdZGY4MtShcbxeqVFKl7nDKi9sAH9qrHrkUYXNYM OTKqNYaS6B+s9zNH9p8Jg88rE+rMkY30rJ/KEqXHQVwwnGjiz1Yq1uaZ9VRjvLK4suOqvDk+siEZ 3x4HX085U3znsnJsPLo06126q5zX4oo5JQjxXYKwHe11yg6IsQ/SdAPHDIFK/q0l01eOzXzVZUwO i0y+RyzqOt0yWdnINRTbp/cuFXYX7Jt57HG7nQvAtWk00IUR3FIHwfePmHnfa6NBLK24QMzSVXfR fswk5AiQ9WVZt1oj/vzy5ZpO8puUA6ZdxFyZdu33dCrUJVHkfkFdoPL9IGUWPzuJCGHDilW2g5QV nhVjK8YL5heUvxzPz/Sqls1WKm7UyQ8EbqMlxHo3j2rmDm8LrFqIR58F5C/Ep/Iu9zL2g9y0sXCN 9dpyCogQ0gOXcLeQXiC0+N4TjDjpHVQDRxQ4gdFWcQpD4JDEILm029yGivY1mVErW/nagEoWTjEp D6qqOSzV4kqfacVvr9Rr4uWu05Gd+pBWe6XGj4+Ah9MCj0A79pgeg7+ysQ1Lt/y7oKMa2U3rZJdE eXBct3yWporwZVvVbx5DbZG8Fuu0oSqbhBH41rQoqCbxJ+cDgTfSV+CcAItFqmH+dVzsD2B8eP3l pgD5Y3Hg4lrjxleOhrYXzT/LY6km7+VzwaDEcNDQ2t08yMK0SKe6++80agm5SCmJX8RLmZJWW4iB vFqUMZqXdnNklU4qVy/beTvHY/kD3ZmGucSx1k2oc5Xi40zneycZllJ8yZdgPbkSRrP0RFXKseVZ Od3MvB0lL2f13VOnObXOi4iCJlHSpx6N0vJFxHmdfKEEkcnaOFMPOn2ZttRzpSfkGl853UTWvnxR Tlw7JVzR+Y/Rl8Netei9qli1EnaNEMBrpy90n7zCjcXbAh0Is2f2II2b9PmEo/CcqB7PZM1wx/ek X4us3emTN+3RH1HIAnKVvnod5PPxuAPN8JHGzCP89I5MrfWY8Zp8X6Z1XufsO6FzZHcucPvwNtFr 2yL6AEg+idatLSeMmCmwcuEwptnKjd+hxjYE+6NXpWqqom5ddIkdwzBu+KFjSktN5jV1bUqDEwWm FugbdzyjbpI7JQ6SsukN4XNLNBpsZ0yRlUc7btaO+Ou1kZWOq8mEGus8Daw7a7MD3EMemMebFY/z D7dq5w3bGa7YRGfaKrwP2lVoiyZaBRNKQ+IxC0leChaAtSq4rtNDQoAyruI04W5O0uOO80ZKJttZ E6PzxH+67ZbSjqR0J8s8qdOvA3+lsRP7Zrk2fFUsQXw1UtxxXeD+jb+PMpys9vo0N19+NXukN5nY J+XFSl8KrpZQ+/sFkK4zSPsPgulRAVybGognbVT4UsUraVdSiyPAxDUJ26oVlGsB5Zjn8jUetI76 7HX2cq2CR+mCHtIaLOxUa6VPNcZ4HBmQBn++Jz9u9aXW51epXTopmdzLp9lOjCx0E4vUox2mK99r rybXUMc2Y2G2lHhbTWXi5EjQ9/KJ+LZKZbNq2jexwFlfmcpFwH1VKxZwmaYo+yD0gNpeIqi/Mhj9 IayETgnQsOJfIrnmJU1JhNZMLUU+SO4Ur7lxEWTj6bSKmDIvGxre8STiHXSggUtbowz+Xro0Skt/ 9aKs/nyxN1Cy9Hrx30dJ9DCtqXAnvGsaxeqEblYhi78JmXZzuW0KWGt8HoxQiA5pQLwT28B+lzyl Y5hajiwx7hVz4v23SKr2ymLGV8E40u3mFcMgmzd/zYeV6FtZwgPpixtLRj+xzQDdLxU8KXOrDKAT vLS1AjCPPRD+H06i6Hz4mBSEOjSmwumUlkmEdh7EgWWVbi5tLoBDq4QEROCcqU8qRPs5WlfUHE+N HN5W7Ns9zneJC31FzaXcdC0gn4YYDNVpKcUhlSJ3XlwoQvxJJ/k3PgeufKK41IrUnCZVXcc3YU+i AAD2ZSgrZaTddzk6rvFVOIk3Lr4Z+d71F4LDHzk4zAaEO0BwHBJK3OcpfW9GZdYMrxsKnrxec5KO QycN2dWKpYflMz0WZ+xDqoBijvP+R/iHrwM+y6JtasomigtjI0rnnAqO4LtV0u2p9C12WuEKqbLt 1e84DamXjmaqAbPSIsygahNdtAykDWMsI4fjK5kb2DT+nGyyDdGWZnFYgWGrUxWzvjBf1+6TjgBd 8gTJSkrfJ+4nM4/ioOpcpJiV/fgCUoQbMP1gSVsCjCzfbjcDz2ROuWSO+WhomMcehEoxvk4paadQ HJEr2Fc1MrDK9BTZie9O8J03CWCWRfjyQP4nXr7wHxKqIIZCS53yaYLrVndcUi69m1WohRXhewRy 1m2IsuffqWy2fIUJ8hbyuZt+GkFXzqnRUJ2Hei7nLd9REk4/V0l3K88FDm4w9CBKqpukK1lZF12r 9C4ZELdWOmm9ZIuHExuAxZLUbnnU8m+giBJ20YCIIv9OZY2w86/zloeqlreagv+/WUAQfdk4tCxo E2sbarOaWaRT27YTaT+ShrrBQYk0GxgLn2b/ma1h3VqLc3RyetRgkR5SFv/Etrc1JtytZj99XlXR /LyZ/Yb/P33aB/PphogNmqyyiJF+fV2bm0//nlXmv7Sqy6v6Ut1ugUrZQa++DFJasKqz2y7vOwmf ZjcUEl/EkoZq9IZtCklbgT/FibQfSV3ELSlrsZ0MjIVDSAKosYbE1YWzcNcXoWzUdlOOQtKkkEDF ZpuBVcgpC1txIu1HUjKHW5ScsnlXSagbDhqLKiDrmpBtl6GZSPuR1LYBK3qxnQyMhcOG0faElANo G2nDiIFNtptmtOF2tOFWbUYE0WenvC6fpP1ISuacupoNjIWyYVQuSGrjca1CS4bRtRTBNVnSZ0mI VNMjJGnWuWSYlbZM6Ze2jNPgsDuciqzggF6yX1um/dJ45WG8xi3C/mACvZS5pvkNgH23gOu/zf4v wAAMbMouDWVuZHN0cmVhbQ1lbmRvYmoNMjkgMCBvYmoNPDwgL0ZpbHRlciAvRmxhdGVEZWNvZGUg L0xlbmd0aCAxMA0+Pg1zdHJlYW0KeJwr5AIAAO4AfA1lbmRzdHJlYW0NZW5kb2JqDTMwIDAgb2Jq DTw8IC9IZWlnaHQgOTYgL0JpdHNQZXJDb21wb25lbnQgOCAvU3VidHlwZSAvSW1hZ2UgL0xlbmd0 aCA0MiAvV2lkdGggMTUyIC9UeXBlIC9YT2JqZWN0IC9GaWx0ZXIgL0ZsYXRlRGVjb2RlIC9Db2xv clNwYWNlIDEyMiAwIFINPj4Nc3RyZWFtCmje7MExAQAAAMKg9U9tDQ+gAAAAAAAAAAAAAAAAAAC+ TAABBgA5AAABCg1lbmRzdHJlYW0NZW5kb2JqDTMxIDAgb2JqDTw8IC9Dcm9wQm94DVsgMCAwIDYx MiA3OTINXSAvQmxlZWRCb3gNWyAwIDAgNjEyIDc5Mg1dIC9NZWRpYUJveA1bIDAgMCA2MTIgNzky DV0gL1JvdGF0ZSAwIC9UcmltQm94DVsgMCAwIDYxMiA3OTINXSAvVGh1bWIgNzggMCBSIC9SZXNv dXJjZXMNPDwgL0ZvbnQNPDwgL0YxIDY3IDAgUiAvRjIgNzIgMCBSIC9GNCA1NyAwIFIgL1hpMTQg MTE3IDAgUiAvRjUgNjIgMCBSIC9GNiAyNSAwIFINPj4gL1Byb2NTZXQNWyAvUERGIC9UZXh0IC9J bWFnZUIgL0ltYWdlQyAvSW1hZ2VJDV0gL0V4dEdTdGF0ZQ08PCAvR1MzIDQyIDAgUiAvR1M1IDQ3 IDAgUg0+PiAvWE9iamVjdA08PCAvWGk0IDEyMyAwIFINPj4NPj4gL0FydEJveA1bIDAgMCA2MTIg NzkyDV0gL1BhcmVudCAzNyAwIFIgL0NvbnRlbnRzDVsgMzkgMCBSIDczIDAgUiAzNCAwIFINXSAv VHlwZSAvUGFnZQ0+Pg1lbmRvYmoNMzIgMCBvYmoNWyAvSW5kZXhlZCAvRGV2aWNlUkdCIDI1NSAy NyAwIFINXQ1lbmRvYmoNMzMgMCBvYmoNPDwgL0hlaWdodCA5OSAvQml0c1BlckNvbXBvbmVudCA4 IC9MZW5ndGggNzkzIC9XaWR0aCA3NiAvQ29sb3JTcGFjZSAzMiAwIFIgL0ZpbHRlciAvRmxhdGVE ZWNvZGUNPj4Nc3RyZWFtCkiJ7FexctswDFXHTPWUL/DmrdefaJZMVTukHqTrF2TpadPEjN66OZM3 eol/Ip2iLsHvlLJICQQBUrSbu/bOT0fKEmDgAQQpEuCCC/4rFFGICuDa2/GCydOxx0wmXjC9xz+k GJlwnMJwgwJ5doJYvrw3xNm5ULWq5MbzYgfMKNxFHSVtTXkZ1b/BirNVcy9lRHg1Ei8ps7166x7K tm1Rg8pXrdSd2HoFX51xNCEWcR2qY6zpv4+qutHAXLm8YqpVoP4T/dbA8hoESK1sV06Gx/Fg77cA 2y7kVVsrvxlebL6aLdWYeOmB0xZC+LweJ3YPnkbAi0NiHIFme1R9EniRwdHGd78ErTTDC1X1fF4a a2Dfoi2OF6MxAqk20DXmtus6LCO8fMdsfY34uicyeba6GctYXpuh/sjLuGWSWVgUrXmJ8wxbg29t Wzktn2X2qhktxZiMQ60iV6+APgSZps8DP0Yn0YjUTqWcM/K9Gzvw/SXX+xxefVdGZEzs6Af1fXPF zu7FwEvOZ5BTzOvl4NtSOQGCzckb8KJQmbYqkVdiGeR8f4fnq7/Eqy5YXtdHWaYt1T8SXgvbT7yo RT4O47u4IbwWG4CNG8cMHH1PvN4HvOJBUl5Dvq7dmw3Aqfky7VPZspfKjDG5/7JnjDnfophvRWOk JxkuXxg/IrIEkutqRu4j2lbqMsYo8EU7x2cOeBsZMSZ3Meisy5xtPVsz6ms+L4BX0OvlZ/qxgxP2 E8fe7HG+CLJg5LzHuO9XIsuIsQb8IYvtRtNQ4BnDu8QPjpc0rwNee/DhNtHw4uULcGlI+Tqg5/uA cxbE+npI1Bew9TWisffOjOUvGMdRmNncOI6wx77dzpPxfFhblte9uYbKMuN40CHnORh5taY0lua+ IrIIqVi+oN3r/W7VLt91xe1Sa8XF6FvlecU4z4RKyaSyHyaEp1+Z84XYbIw5Z4CZarMh2nIBIYIg OcQJ4LZZcnz55CdX4SpBbFHm/uQ7N08kBETFp3SqMwgM2S7J69STbLQSC9ZZ+CHNC1L2NVPzvK3O BRf8g/gzAP18rgUNZW5kc3RyZWFtDWVuZG9iag0zNCAwIG9iag08PCAvRmlsdGVyIC9GbGF0ZURl Y29kZSAvTGVuZ3RoIDgwDT4+DXN0cmVhbQp4nFMI5CrkKlSwMFAAQSMgMjdQMDFQSM5V0I/INFFw yVcI5HIK4QJyDE0ULBRC0rgMwUoNFYwNgCpNFUJyuTSMTMw0Q7K4XEO4ArkAxGUQ/g1lbmRzdHJl YW0NZW5kb2JqDTM1IDAgb2JqDTw8IC9IZWlnaHQgOTUgL0JpdHNQZXJDb21wb25lbnQgOCAvU3Vi dHlwZSAvSW1hZ2UgL0xlbmd0aCA0MCAvV2lkdGggMTUxIC9UeXBlIC9YT2JqZWN0IC9GaWx0ZXIg L0ZsYXRlRGVjb2RlIC9Db2xvclNwYWNlIDE1IDAgUg0+Pg1zdHJlYW0KaN7swTEBAAAAwqD1T20N D6AAAAAAAAAAAAAAAAAAgFsTYAA4CQABCg1lbmRzdHJlYW0NZW5kb2JqDTM2IDAgb2JqDTw8IC9D cm9wQm94DVsgMCAwIDYxMiA3OTINXSAvQmxlZWRCb3gNWyAwIDAgNjEyIDc5Mg1dIC9NZWRpYUJv eA1bIDAgMCA2MTIgNzkyDV0gL1JvdGF0ZSAwIC9UcmltQm94DVsgMCAwIDYxMiA3OTINXSAvVGh1 bWIgODggMCBSIC9SZXNvdXJjZXMNPDwgL1Byb2NTZXQNWyAvUERGIC9UZXh0IC9JbWFnZUIgL0lt YWdlQyAvSW1hZ2VJDV0gL0V4dEdTdGF0ZQ08PCAvR1MxIDQyIDAgUiAvR1MyIDQ3IDAgUg0+PiAv Rm9udA08PCAvRjEgNjcgMCBSIC9GMiA3MiAwIFIgL1hpMTMgMTE3IDAgUiAvRjUgNjIgMCBSIC9G NiAyNSAwIFIgL0Y0IDU3IDAgUg0+PiAvQ29sb3JTcGFjZQ08PCAvQ3M2IDEyNCAwIFINPj4gL1hP YmplY3QNPDwgL1hpMyAxMjMgMCBSDT4+DT4+IC9BcnRCb3gNWyAwIDAgNjEyIDc5Mg1dIC9QYXJl bnQgMzcgMCBSIC9Db250ZW50cw1bIDQ5IDAgUiA4MyAwIFIgNDQgMCBSDV0gL1R5cGUgL1BhZ2UN Pj4NZW5kb2JqDTM3IDAgb2JqDTw8IC9Db3VudCA4IC9UeXBlIC9QYWdlcyAvS2lkcw1bIDEyNyAw IFIgNDYgMCBSIDQxIDAgUiAzNiAwIFIgMzEgMCBSIDI2IDAgUiAyMSAwIFIgMTYgMCBSDV0NPj4N ZW5kb2JqDTM4IDAgb2JqDTw8IC9TdWJ0eXBlIC9UeXBlMUMgL0ZpbHRlciAvRmxhdGVEZWNvZGUg L0xlbmd0aCAxOTgxDT4+DXN0cmVhbQpo3sxWTYzcSBXuWZKZIopmBUpDYkd2LoC0IJD2kpUQlywb YBUtSPyIRUhsYCfKKDPRTE9P/7ttt+1ylbtcVbbbbvffdM9kMpPdIECR4LRacVjEigPisGdOnBAX pJW6l54VlLs30iKBuOKy6mDpe/Vefd/7nldy557JraysPHvjlVsv33zpiy/e3tr8aWEz+3R1Jl/M z65e/MzZzvwHV8+9/Y9b5//87N8/1bl6If507pmVlfX8V25+93vVnY1rL1x7fePOU6R4VnKfz93I fT13M/fN3Ldy3869mruQHXJvZeuZ65+4c6563lh7EbzwyS9d+Gxx8sHF/IcXZxsfXFw7e/7sL/nZ W9N/nr21dnP2tTzsW6mRGInWqQUgrJVpUTZMDxuqiVu4hVrIRg52EEQYY4SRh4Dntl1Hgm2XIMUl mGAFE+IR2SOkTWSfEp+rjAY0FKtDOz6gnYQk8unE1lI11YJKUTI8E5kKNl3LsR3xtlzgmgbWZGvV gtiFqutih5j+85dFeOIpInyber5HxQ4ob3O5ExLCVU58n0n0vT7p0TS4kgZJ1InjJOzyPuB9OjyQ hmgA+8qX53/MexwzRDF1fUgAgZDYsu14HlSh52IkHux6EHjQg7ZkE4e4CoG+SxFFDHMPeDzwQjnk y2OZ71NKfUY4IIwEoRR63OPK+vrt2TfeFkd51BNHYR+LozAiWJ6zaWl6d5X6hPgqFZvvEypWhm/z QAraGd5jYgmY5yNfADFB8vzu9EfT9seB9N+A4ceB4o4QeQr87aptI2irNkRWUzp7d61JrRAqMAxR KE/fWfWzaKqfpZIFZIQBwpe5BB5T1n84e276bv4UPXDGijMxh1pP61Xj/RCE+ztsS67VMKqrNdRw Nai5TceEhmNB13UhWlyk69nWQiXiIsVGsEhNVAY8X/Aos8DnkRrxmHeDbpDyAQd8MPLH8miAYVdN 3diOrKgVGKwJaNNv1KTNV9Y2t5Czo+44xVZFr+iNhlkBZhWWClKJVcKaEtYTLdVTY9A6cIAzmqAj +eQ4SI7UB8nh4GACfrImJOtjxccLRnnoRUJGTF7QKWQqGGHSV6e5fLlYqVcNYFQrcF/eLYeppjZ6 9uhISmmXxwpPwiiJkjANhhSwwYF/KP9pdf3aTPpbfkGDYEMUuuQBy66DnIwEyzZtw9YdTeSm1VFF rlRp2FAbYTMxe0bfGsJDACfo+FR6J/7N5JHyxuRR/4l8MEQwVXuw68S2uBIngAAGAeIyY5RTlXIS pUI7TPKY6A261ADOZM5c5rBWIBbXmcF02qTiJjWiyfd3YKugFsxSo1KuVhq75hYwtuCd16QNttm5 r3TudwvD8qA8bhybwHhwCh/L/T6hPbVPU9blqeAsDuIg5IwxTkW7L5aQUFuICLCnChLdcG/2/elB /pH70H6o2Mf6YeOgPir39xKQ7G0Hm/K9bcfYVXeN/Xq1VClpu61tYG7DzQ3pdX63s63E273CqHxQ PmycmsA8eRP+Up6MfTpSR3RIe0zkwjosYoHIwF+8IEuESsQXiYha24wt2oopghPPV4R/LPtxyQpG lmoj09VdXei3jgCqV3BJ3i2ysKpWo0Zi9PSeNYBjAMf48IE0/fVqFFIeqCGnnVSav/cgT0QmfBgM on7cjbtp3I9A2B+ysfzkkb43Vsd7nU3vNlj/zuzl2Y/zHLnUkedXVk1q+rpIVtdJUy4UXbukluyq 0Wg2NL1mlUGr7O4XpH1aDRpK0Ii0WNd1U7PqwKq7tbKkMS3UlajZNfuWabWs7LVbsOVkZm0AZHqm IdVYI2wooZY0B+bAmFjHQnTHb6BfyL96zKIT9SQ6TEa9YZoOogPQGbGDsXTgDu2+YvXMbjPW4kZU 4VVepvtkvsovV4nGzBAYEex0pdiPaKSwkIVB0LG7zkAocjjEI/n4iIUTdRKO4n6vn3aHInQ0ZocP pT7uCQ92e1ZX74I/rPKPlOtHiZR4HcSV+aX5S3lkOEZWiWnrIqKhobq8XYyGwmIG1tEjKfW7rKvQ bmbxYScWFg940qN9+c0jqzZQh7WouC01sWBTeTL/a941RSRxP5pTF9HqJbwnb2zzZF8tJcZgIoUk JIHih36QFcLD7IlEU0/Pu5dPvDEcmKBvRo2KZGATmso6nL06/Xn+MTqBhwo8bI2bA31YT8sxiMsF fl8u7jl6Ud3Ti9XiHpj217JZlQku8zwkvM/JJo7dtmTLaYuJ4whzFJPUw9jDwBMbkj68tiZMOxt1 Ymhkjcy8YDF02pEchW0xdALh0JlPL5VOCPWl6e/XDk8nk3Ef9MbjcCwPUuR0VWEVVmhEBm+yOmAN v1yQ5sl/jh5m0YP/Ev1/FV0oOM09tdDcKxV2wO/WRNdhsqhZNJmPhOXLBDpte1Gzq0JXlKk+rdlr Iyyd3fr/q/m56fG0lZ9emt4+T5nPqSSQiCjIX5LoWG1TtuyMRFGQtywIe4sNf25+/fIXptcXA5xc ye4hG8auQMrEsQXQtNqeLdiHHsIAYQ8hSaiDuso0P//Z/Or83nnkYjf7KH5UFIqXGQdRuyN3okXG jBAm/gKo/5Hn0fenNy6/P7+xnK1XFs4vIJR7gezxqB3LsQAKzyJcgBYjLiuJITHf2+3VaenS7CT/ LwEGABbdDS4KDWVuZHN0cmVhbQ1lbmRvYmoNMzkgMCBvYmoNPDwgL0ZpbHRlciAvRmxhdGVEZWNv ZGUgL0xlbmd0aCAxMA0+Pg1zdHJlYW0KeJwr5AIAAO4AfA1lbmRzdHJlYW0NZW5kb2JqDTQwIDAg b2JqDTw8IC9IZWlnaHQgMTE3IC9CaXRzUGVyQ29tcG9uZW50IDggL1N1YnR5cGUgL0ltYWdlIC9M ZW5ndGggNDUgL1dpZHRoIDE3MiAvVHlwZSAvWE9iamVjdCAvRmlsdGVyIC9GbGF0ZURlY29kZSAv Q29sb3JTcGFjZSA1IDAgUg0+Pg1zdHJlYW0KaN7swQEBAAAAgiD/r25IQAEAAAAAAAAAAAAAAAAA AAAAAADwbgIMAE6cAAEKDWVuZHN0cmVhbQ1lbmRvYmoNNDEgMCBvYmoNPDwgL0Nyb3BCb3gNWyAw IDAgNjEyIDc5Mg1dIC9CbGVlZEJveA1bIDAgMCA2MTIgNzkyDV0gL01lZGlhQm94DVsgMCAwIDYx MiA3OTINXSAvUm90YXRlIDAgL1RyaW1Cb3gNWyAwIDAgNjEyIDc5Mg1dIC9UaHVtYiAxMTIgMCBS IC9SZXNvdXJjZXMNPDwgL1Byb2NTZXQNWyAvUERGIC9UZXh0IC9JbWFnZUIgL0ltYWdlQyAvSW1h Z2VJDV0gL0V4dEdTdGF0ZQ08PCAvR1M4IDIwIDAgUiAvR1MyIDQ3IDAgUiAvR1MxIDQyIDAgUg0+ PiAvRm9udA08PCAvRjEgNjcgMCBSIC9GMiA3MiAwIFIgL1hpMTIgMTE3IDAgUiAvRjQgNTcgMCBS IC9GNSA2MiAwIFIgL0Y2IDI1IDAgUg0+PiAvQ29sb3JTcGFjZQ08PCAvQ3M2IDEyNCAwIFINPj4g L1hPYmplY3QNPDwgL0ltNSAzNSAwIFIgL0ltNCAzMCAwIFIgL0ltMiA2MCAwIFIgL0ltMyA2NSAw IFIgL1hpMiAxMjMgMCBSIC9JbTEwIDcwIDAgUiAvSW0xMSA3NSAwIFIgL0ltMTIgODAgMCBSIC9J bTEzIDg1IDAgUiAvSW0xNCA5MCAwIFIgL0ltMTUgOTUgMCBSIC9JbTE2IDEwMCAwIFIgL0ltOSA1 NSAwIFIgL0ltOCA1MCAwIFIgL0ltNyA0NSAwIFIgL0ltNiA0MCAwIFINPj4NPj4gL0FydEJveA1b IDAgMCA2MTIgNzkyDV0gL1BhcmVudCAzNyAwIFIgL0NvbnRlbnRzDVsgNjkgMCBSIDEwNiAwIFIg NjQgMCBSDV0gL1R5cGUgL1BhZ2UNPj4NZW5kb2JqDTQyIDAgb2JqDTw8IC9TQSBmYWxzZSAvVHlw ZSAvRXh0R1N0YXRlIC9TTSAwLjAyDT4+DWVuZG9iag00MyAwIG9iag08PCAvRmlsdGVyIC9GbGF0 ZURlY29kZSAvTGVuZ3RoIDI3Mg0+Pg1zdHJlYW0KaN5UkU1PxCAQhu/8ijmu2QNtV1sPpIlZNenB j9jVOwvT2sRSQumh/94B6qokMA/MOwwz8GNz35jBA391k2rRQzcY7XCeFqcQztgPBvIC9KD8tour GqUFTsHtOnscG9NNIATjb+ScvVthdxfH/rHaZ1fAX5xGN5gedqf8/YMO2sXaLxzReMigrkFjx/jx SdpnOSLwP9G/rtNqEYq4z7dnTBpnKxU6aXoEUWQ1iOq2BjT6v49VKeLcqU/pWFJmGRkmrm8ik2Gi zCOTIT4kPgROmjJqMPEDcUhGTIZRzu32/CdXSi3KikRlUhInZfKFh4ZeXkpXi3PUldjwWHWodzB4 +RM72VBemOxbgAEAU5WGoAoNZW5kc3RyZWFtDWVuZG9iag00NCAwIG9iag08PCAvRmlsdGVyIC9G bGF0ZURlY29kZSAvTGVuZ3RoIDgwDT4+DXN0cmVhbQp4nFMI5CrkKlSwMFAAQSMgMjdQMDFQSM5V 0I/INFZwyVcI5HIK4QJyDI0VLBRC0rgMwUoNFYwNgCpNFUJyuTSMTEw1Q7K4XEO4ArkAxAEQ+w1l bmRzdHJlYW0NZW5kb2JqDTQ1IDAgb2JqDTw8IC9IZWlnaHQgOTMgL0JpdHNQZXJDb21wb25lbnQg OCAvU3VidHlwZSAvSW1hZ2UgL0xlbmd0aCA0MCAvV2lkdGggMTQ4IC9UeXBlIC9YT2JqZWN0IC9G aWx0ZXIgL0ZsYXRlRGVjb2RlIC9Db2xvclNwYWNlIDEyMiAwIFINPj4Nc3RyZWFtCmje7MExAQAA AMKg9U9tCj+gAAAAAAAAAAAAAAAAAHiZAAMANcQAAQoNZW5kc3RyZWFtDWVuZG9iag00NiAwIG9i ag08PCAvQ3JvcEJveA1bIDAgMCA2MTIgNzkyDV0gL0JsZWVkQm94DVsgMCAwIDYxMiA3OTINXSAv TWVkaWFCb3gNWyAwIDAgNjEyIDc5Mg1dIC9Sb3RhdGUgMCAvVHJpbUJveA1bIDAgMCA2MTIgNzky DV0gL1RodW1iIDExIDAgUiAvUmVzb3VyY2VzDTw8IC9Qcm9jU2V0DVsgL1BERiAvVGV4dCAvSW1h Z2VCIC9JbWFnZUMgL0ltYWdlSQ1dIC9FeHRHU3RhdGUNPDwgL0dTMyA0MiAwIFIgL0dTNSA0NyAw IFINPj4gL0ZvbnQNPDwgL0YxIDY3IDAgUiAvRjIgNzIgMCBSIC9YaTExIDExNyAwIFIgL0Y0IDU3 IDAgUiAvRjUgNjIgMCBSDT4+IC9Db2xvclNwYWNlDTw8IC9DczYgMTI0IDAgUg0+PiAvWE9iamVj dA08PCAvSW0xIDEgMCBSIC9YaTEgMTIzIDAgUg0+Pg0+PiAvQXJ0Qm94DVsgMCAwIDYxMiA3OTIN XSAvUGFyZW50IDM3IDAgUiAvQ29udGVudHMNWyA1OSAwIFIgNiAwIFIgNTQgMCBSDV0gL1R5cGUg L1BhZ2UNPj4NZW5kb2JqDTQ3IDAgb2JqDTw8IC9TQSB0cnVlIC9UeXBlIC9FeHRHU3RhdGUNPj4N ZW5kb2JqDTQ4IDAgb2JqDTw8IC9UeXBlIC9FbmNvZGluZyAvRGlmZmVyZW5jZXMNWyAzMiAvc3Bh Y2UgNjkgL0UgOTcgL2EgOTkgL2MgMTAxIC9lIDEwMyAvZyAvaCAxMTAgL24gMTIwIC94DV0NPj4N ZW5kb2JqDTQ5IDAgb2JqDTw8IC9GaWx0ZXIgL0ZsYXRlRGVjb2RlIC9MZW5ndGggMTANPj4Nc3Ry ZWFtCnicK+QCAADuAHwNZW5kc3RyZWFtDWVuZG9iag01MCAwIG9iag08PCAvSGVpZ2h0IDk2IC9C aXRzUGVyQ29tcG9uZW50IDggL1N1YnR5cGUgL0ltYWdlIC9MZW5ndGggNDAgL1dpZHRoIDE1MSAv VHlwZSAvWE9iamVjdCAvRmlsdGVyIC9GbGF0ZURlY29kZSAvQ29sb3JTcGFjZSAxMjIgMCBSDT4+ DXN0cmVhbQpo3uzBMQEAAADCoPVPbQZ/oAAAAAAAAAAAAAAAAAAAPhNgADigAAEKDWVuZHN0cmVh bQ1lbmRvYmoNNTEgMCBvYmoNPDwgL1N1YnR5cGUgL1R5cGUxQyAvRmlsdGVyIC9GbGF0ZURlY29k ZSAvTGVuZ3RoIDk0MTYNPj4Nc3RyZWFtCmjefHlnlCPlmW4PIE3h0BjbsqUqXAUGbLBZAw4sa2Mb MMyQPDNMDj2hp7O6FVqhFUuqUgVJjVJJKpVyTp27p7snZzKMhxx81gav1767Xod7fM76lGbV95z7 lQYW9uzee/RXVfWG532e5/2+dV3XXdO1bt26mx/e9NTjj2789vYRzYBx04Blq07Tq92y7e8eN/WO jfT9fHvnPy3kc4rWTZ/7yhrbfvE//v0/YjLx8zeI3/2C+NiN8Zu+/fUvdl2zbl33N+7esG27TT9w 8z039w8M/j9f17UO/LquX9f1+Wu6bry266uyrluu77pL1vV9WdfDqi6oq+sLXV1f6Vr3mZu77lh3 1zX3XHuf7MHrn5Rtk/Wqol1dj4CQu1RdSNeermTXv3aJ6+5ad/6aW64JXfvza3973fXX/aPMIftf cuP630Cj1z90/e8+U/zswc995nPvff5c9/03KG8ofWHLF35/Y/CLd3/p81+iv7zly5cU7FdGvvqd r55TDqk2qH4Lv3vTZ296/Wta9C70Q+yJm4dvueOW4tfHbr391sXbxm577/bT33jkG7//5tt3LN6x duemO3vv/G3rH658+StXZGv+/yNbn2n9TdEaWfv92oi8++Zuo6gUFP+Y/uepP6PTf1764NTrSxdP n3nxOJFVtlXf/tYdW26H9t5v/Ltb4QPRA8mDaGZr44kjD2VjysEPrG+9DIOn97dGFD9yfldzJzp2 58D9+zYMbN+7Z/OBhFMpqv74x7+8+Ffo9AeVP/w7fJw+5jqO2p/VX+p/x+5RLv59/meb4O6b2zde dzQzWy5PQeVmYqoBZ9kkmUATBBHBERfBkiTmIVk3DtMBOsiiAV+EjVFRKsIGfFCQDbAM7Gbcbhfq tFtwIwF1G0+IIYXlCZnIyQuXZN03n3pHIT3vgvGIO06iHl5gk0hKiMTjGM9HhBScZAUPj8ZJt/Q9 N+shsW7RceWzil0HDj2m/h6kfRB/8CH4p6ntzWF0uLFgX0VqpQhfwGazM43pI0unp54vXoaKlxOX LsHv4he18+i8bjjbi/QOODXDmPgAo0jbo+ND8PfNbdmhNobq7xvdPDAMuXA7bUEstljWiTmzdHUO fk34dfVPaP6dwouFk8WThel8GkoX8tE8Ush67Gmsu4VeuV/R/of9nE0WzqWCMSQR89FRjGNCHgKm J5lJBvV6XbQRbcvWUGKA0BNOFU2SFM5QPpt/fJK2KcWwPJIbC1ojHk5FcV5egFORcnwGFe9tHZd1 t74hKhUWOW0FsREQYTczeqT9I/nf/vCbD159a/VUczWzBPHVSK0Jr+Dz2iba1A6nepHBEbdpFBs1 GdX23iylPDa1WDqBzNaJiSJWnOB1I3Cv67ChH915f/vaNtR+oP1NyCZ+uL5b9Im/UzScBUvSCCWN nG4M7ieHrCPoiNVo1yJudzBMYO6QI2ZJTAhujglCIYoKeBA36aU8GEV5SQJ2Rd0pEsWL0/QKcvxo orSCrZRnpisrUHlFWFmGFz0z9hpqr40XRlIXS0vVch0qNRLNKXje3TSW0bJpLNGPjGlJqx4bt5p1 9oEcqzzemCktIuU8Zc9iGXtsYhwewTU6A9o/8rTxATeEr5/1T1ENB9Tduu0Kqthq3j68c//Ont5t Y09CY084H38M3p06UO9H++vL1vPI8xfqF89gZy5WL78Pn3Uua6fQKe1wuhcxa2nnMLZ86cSFc6vn Vi40nk1C+fV72F5K7YLa97ajinCCDwpIvUxO5LH8RFzbDz/ieEq9Hd0xOqwfQEwWvmDD7AVPfR6+ XP7g5F/QrJCK8SGoW7y+lVYU5MVmLp+JQdFMM3wMEe+Vt3+59u4RW2v9ldtl2fav13e39rQ2KypT wswCvOCc0dTRurY/2YPsPewYG8XUY47BQ7ApYuJNaMKU1zSHH1TvHtEPQ/ohfGgQPpQdnFWjo7PH HOeRF84UjixjK8uFE+fhKbrpnELxKdP06NyF/FKl0oTaA2cUnjxbKMHNeDmXR3O5cryJTFdIK8jK Gh9Xw8PkqFWPWvU6y7B7eNkwh9eh37UzirQmqtPBQ64xwzg6Pj7mGkSGtImiGTOXiOY8fExYqS6h 1SOLzdOFIwcbQ+kxkPjdGcXzpYvz50+cO7lycfoSNP1q+tIv4HP4Cd0R9Ii+L78L2bpTt303tnub 4fEfwweT/bURVF1bsp8GRBAIJbBEKMMVeF3P2OHh4eGhfs1BowHXkiM05Fh/JrIan0tC4r2AVbwE 4XchepPUAFvB0zwCv5N5deYCen56ob6ElAukNYdlLXH9EPyw6f7930HtbpwifYCSxI2tBxXkxyzE e1CST7ApJJWI8DzGxz9iIVJiIYn1cEJioa+3//afzEV8wlyJSJzH4nwk8QlzEZ8wl1HcAD51lTDB Yzz5Xz/VeSz16U91HmvftXZGsZArCjGulM3mhSIkFLliCVBxSqLiDjW63SzpwcjOm5kAE2IkKmai nk+omGFgwktSBEoRZueIBUzJiy2xtV/h3MmUySyeUCWcNs6MaEdw/QC2Z+jwvrEt0NgW584eeDim z02gE7kiWUZKtXi2iTWzR5ZOvQAxGp/RBk9w9iSBuoU8U0WOHU3WwaTX51ZrL0D155MvvAi/iD+n O49qLxxe3tGAGjs2pTYiP/zxRO/PsId7tz7d9xDU95Dlh/fBP8w9tPgYurjx7O7Lg9DgL96yvY/8 5Z8bF9/H3r944a3m7yGtfPB7Ox7bsB/av+HHpvuQDU9kpjdjW2Z6TqhfgtQvOV57F/5V7v2ld9Gl d88+9+oytPzqG4X3kBcuuAynsdOGpaF6D1Tfl9y9DX7avd24AzXt1PaPmCCjWus2IQQVjtIYHfXG eVgIZiJ5NFxInii9/Zy4S9lW9CsEF2efgNWeXtsulNTYNSbwM5stOOScsNBWxOnikoANk2y2CDfi S/mTaO3VmbOLS1CtWklWkWyKcQlAs6It5soPFWvY2sLQXp3a5lTZnGbKOMkC3t8NeN8awMOeqIqK SVHEgrFwHA3F+XS6cPlflOJWuefvfQM+k5dQsThQDQbyuOzsBOKWszaZmAKPywy2YITEiDAVpXnI G/XxSTgWyIaq6JnWaVm7e+0BRfuHcnGbmJaBUMQfXFEpqlkvHcdidIR0wy7WSI6gbWjtG66DpI5y qQDsaBfj8dqBNDEgRK/82dVQpI4txmaEWraeLZWzU1B2KjYzCzfJ+kQVnaiOFg6lL6VPlZrTUHM6 PbcEV6mKs4Q6SqbsqAAlx4a4fqTtkdM2WSTyDIeI3zUrwrk0oNJjMx5rEStYeUA6Bx2Dai2qVe9x bkQ8zmcCExgxqAikk4EE8uwyYapiVbMw2gfvtBzuG0PH+g44dyEWXTAyBAr8ypWHQIFxp4dkfJCP of0UQrlDURuW7huKjSIbNlr6N2KP9e/c0b8R6t9ofeRncE/iYOkwWuqdHls1QabVU8QF5KVzyfox 7Gh9eXXhOcgkH+tVjw1NQJbhw+R+ZPPe/NIANnDEevZV+JXky7WX0Zl3jj337Ao0c+xc5nmkVPDR OSzHpD0CIRBxnHNyzpAtaA3uUObkp8VRIOHrxLulwmd8ncKHSRds8xo9o1LhbycOEzoPrqI9HsrF flL4Wflrz0ZTx7ETqdXS0tSRqWY9X8lVs7PpFSi9El09Cp91nRw/hhqODc8eKkDFg4/z9yLtYTkD cME6FG9etA4uYouD+a0/gTe6NwPkG3eqe/s02okh5wHgIg7uY0EB8UCIwpgAG/JFIG94MhKGY5Fi YhYVb2uFZYFGOZBDJPx++8p6xbOLPiaNFakskXBCMXcYt8PkpMvvRHPyFfH7sjW99GVefhVbcTrs ccF2tpPi+rXb3b2klCLj8XwaW62o/BXx5zKbXLNtpL/fDJkGdhNPIZvlJmcwzGIUx3JRmA+nuBx6 SbTLfiGfKfi9gCu9MSbigTgqROCw02dnLGhB/ppIgffgQzaDFYdcFjV9EHlK/u5VzLd6rkCK41N+ XxLLsRmP4IYSnbl2Tdq9FlTq0I9ka0kp/Gpm0gf64+PYMANFmCDtgW2sgQQ5yNduc/cS+qs5fNQm Q8e6CXIuNxw0h4F183DeWAJOREqJGfRFcVD2O/lChSWSWJLgHBbY7XewUqiviwwIdaLfMm51Q26r hulHvi9/T8xIKLnyNACyBww6ALK3A2SaCHEOLDNwKNaDPLkJ123Beif6dUNDQ8NADHdBxt3u7Vvh Q/yh4iG0eGhm5KgeGj/6nOsNZKoZ4upYPbogHM+fFh9QCqvxGhePJXk+EYG4RD5URSJ5WbshZ62y pHy6xHpSEiMAy4p7rcCs7mv/REOaGadP5XM6Jh3IY3tKx4GdPO648BL8r7UPz76H/tulD0/+FTlz xG1oYg1DSjcKE5NWn7FT0IEO5I+3GgphOVHnU9FEIp7moEgiEywhgLPaqU65s1K541fLHe6UW4KM ugMZVy+p/++QEePycG40OBGmPi53KlKKN9GXxBGZ+LL86fZBlwS1j2mM6jwntSkGqFJ6ruOwWfBc MlLip1DxM627E0uJeiKjivJCPBPtxFhGOBBjTuLY/wESdtYAYN3Tvl/WflkOhH1zVeEJMWFvBGIj fi4Gx7kiP4eK61u3Csf5qVhSFU0m+HQMivCZYKHzZu5q9v7Om6PeT2VvuJr9be6+zp7AkASFA7DZ /PpOFiWQhQ4QiyekArTXKrTqiuePz1QjoWwiE89w6WghUg6Hc0rAA6xN8IPSMiqODQEDQPtoFtgb fMI2Zmy7248qz4g/EY7y9WhCxfF8PBX9KDypOcGro1z5FFtZAVuN/f/6IshjuaGg6eoYsHEwBlwR jMFl0S4i7aGMgXcEaVXYE/CQwIt4SA/qoRyM2S+J4AKYINmogUtaMatgaGpPtO8XOWW3uK9VELco bHKX2dTvMHpIld1uxS0U5NYNMD3IE3KLKxhhMfC1KKCJSD5eR4HR/lbyRLzOxVXxFB9PchCXLIam kRBIqiR1MxQG+lPNXKWoCKAoJxhvtcTCdxD9hJ4Em5mHpEBeH29mLbe8u6UXN135toK11Xx5b5xV 8QxPJvD2rWsepXuIMJME5MSN9Cji6mjyOGjRSHAicpUP4klYiJT5eQlo37m0tiAryFtIa6F9zdqX nXuIUcqponAP8G4Q7bJ6DR+9oiHJuluut4bjbswTkaophLPREire0Lo/sRxvxFNSfnwizIWKwfkQ lGvfvX7ta2uLT7QWAeG9It7QCXd6suRNU6oUncIFSxtZG1W6B0kDCbIjmU8vn4PgcxqwfFIfL5/Z SCU2jYqfbd0j6tYuylJysIceSyzxNWlKEkIsHf1okiUsj0ghh8PPhJEyqGusQ/1uoG4GEuDlmrUv tfe3Eh02+BMQwB7zwbHDfb2Hh/doNkGazc5NPwcWcyg7iGYGa5o5IMVzR4mzyJuvF1cuY79YufDC yi+hlV8W330TXiaPWBdR66K+MZKH8up+/iCycw9h7sFEeq+iMiL0H4A3u57UP4qOb1Bv7T8wNqwx aJ2QU6elNcieodyCETPOu1dOwq+mX596G62+WD81vTi9MF2fzkCZ6ZnYLHJqwT5Skcya+C0Q57S/ 6I1TEMAI2GedzJjrANpet9bt2ImrcbfK7TIyw4jUqSQonfoqq0hsBFwkVxOW0YviNhlx6gg7hZw5 zheOYqv5mVppGirOJGZn4VX7wsgU2hzZnd6ItNNy8YEDish0LVRClqdIa+EjNzRGjTm0qF1rNnfS GKWHEbMmEgdup+pU1BLpZB6JJfxsElvE656sF/Jlc/48srwQz85is9laNTsN5WbiM3Nwk244ayhe H1vYe3LvybFZvAi5inSpBNcS5WIBLRQb/ByyOu8y1LCaIQkMlnvSOWlBs/Kzoh7IlMdBETQLsTTl 9yAM+0yAxfwBMmyN6RO2KAm2f7s9aEN2HHCoR7Bhtb1vP6yN6tLjaNxRNM6oL29c6UnrId4asZjh EUJj1qPjZrWrF9k/mGpoMV0DXzgOZwL5YAW1y3e0JwF49/1Ly6HIyfk5oZbOp3OFdCUO8ZWZyDKy JG/ftDaK95AaMDU0mBoPA1G45T+nZlGiEbNcbwtHgR2OsjyYmths9jwqqlrDsgvy4w3Wk8DS7qjN BFt8JmYcKNUF8RHZGieX4Pll0PZFf9nL09BVCDu9khQ91p4gh2mDH1d5zX6LBd5XPLQygA6uXLBe Rp4/JZSPYMvlZiM/l58vvlD54B0xoUwsxCsxISbE40BpI4lcsNoh1UEQ5JS/4OUpFU9JOuuk1c49 KFAsot814BhUOQccGuuEzWy2GYAvGNcyI8juPqE6hmmqzqkFOBPMhfNoMBVrJo+9LT6jjM/GS3Eh lkzEhIgQKQYbAQ7w/qxcgvBPnIrW9a3w0vnGfC6rymWzyRxYTIVQJhAB/9kL6L04mfJGaVWMCVEe mPJTLIHSTtu4rr8ttP+mXGrdHJ4LFcIxFZeMdQwDXwg1PhJuUOucvJxlSbCeezgXDpN+q1+H7lg7 LZOo8i6nQvywxe9Y48HfxH9q8TNnStO8oMoVMqlkNBVNR7KdKHbLvba8P+mN0aooqLcH9vjcLI4y uNNgHm4Ptt9WJsXuxL9F34y+EV4McKE8MIKxSCzKRUOgqhKrS+HkwVvm/WUmQaoSZAS3sc+wNNwO rSkXxSvhU7GppKAShDI32/lzACTemCywPPizh3NaYcLv8JvRrVLkwCbGAAIqk1lfnIGAZrIU0EyK pVDHuE59+PBttyoPiPfLqKY3F4OjQS7MoWGOC8dCUCiaDlylQk+nxUVKcKkEPDWU2XK+vU3Z3t7e uX//kGbcqbKTJkbnkyRPD3jDFMJD3qCKjLKxOMwFuVAE5fhccXpa/I54r/Jk+0ey+FjY4gFySXlo 1O2xsvrOzihxjjFgC7kjKneEBEsfFacyVNm9QNW82b3iY0rxp+LDy0dnm+W0qpKqx2ciUrmNAOT3 tX6kcOyhS0QG51Vx3BYxI0MDLn0ftmvk0IGRrZB6m33Hbngkrs9bUWu+TNaQeiOWaWDLpaNHTl4k BpXUuM/igPEQ+CpKc3GfgGRzsQzY4NL5Sn7WLiidGreVoiCW9fp9iM8fCPkxf8gfjsChQCgQRoXj fxA/lLWVvYqEm7Po4eDPdI9u3QDt7jk43oc4nFzSjbmSTLYEH02dapxHGxdmlhfrUL5a4ctIIcO4 pW36q1fuUdjWB1OJQBRJJfxMDIsAgwOaxZjc/Wj7mwB3g2dO204hq8dSzWPYsebCSvMc1DybPn8O XiZmzWW0YtYJI4jBxLhNmNk9btaM/kn8vbL9pbWnFMLR4ny9ClUbjWQTyWcpewpL2aNGDbyH2G3e i07sGR/STEATWi2pQ0y6eG4M6/5tCxI/p9CodSYwti6DgTEg6nE+D7xMnqzPwmeSZ+pn0PJKfWa6 BJVnZhIzSC7po3mM84YYGvZNeid9qN/HMjRN0SztZyEfOwn8GhmiogxKR2M+HkkmuASPCSkuW4BL npw9jaZt+ugwcqDHqenBejSD/bp9kG4fvncPfDA5XBtHx2sLrhPIkQU+P48BZpqaW4a6wRL3A6lw 2SQoXCLuZ6JYxBsEIVB+wutCfYTXydj2t3+gdGVwAY9CUdwRtiJDfbj+ILZ9+OCBke2Qeod91154 kNcUzKi5WCHqAB98fgpbbZw6c+5t6yYlOcYabLAzTAB8UFzMGwf4iGeBpuXy1fyMnVfax1wWmoa8 Xt+kD/H7A0EJH5OhEByPFKXz7gdb/yRrl9dWFA9v3z/Yh9g+hkS+Ar9cvXT6NfS10yfnTiCFLONK YimwxVng7fondzyEdv9WLIujimcLq7XmDFSqJmp1OE9l7Sk0ZTeAUvX04LoD2H7dYJ9mD6TZ7dyz Dx4S1BUNqqksOE8hb7y99P4vMTJ1UK2eMJMqj9nEGhHtOF+YwCaKZKUJ84FUMINejp5LLCahjeK3 FPNLC7k5JJP0eoCVpMJgFTWRpgkDajGMmQ/bxlx9nr1M7vXGuaUFqPsBkWz9TFF5O3MiVsgs5RqF HJRMZ6N5JMr5fWEs5A94vbDPz3op1Ev7aRamQjTHoEyn+UI8HIth0Vg4LsBpOulMokncyhkRk5F2 GrBx3Gg2au0T9jFrP651W0mCBCuDG2yP7gm/BqFHZX+U39X+zcRPXQdYXEWqCYPb7rbhLqcH8jhw Lw40PRD0Yf7gZDAEh0KhSASNciGwxETB6sChEYYOdQ736c7hPlAtV4TkKdSdyjJ5ZGoqUZzGjtQX z8y9XT1bfav2hxfEMeVb8vgMUAKkdY/CyTtjTiCCDkvQgGzcYRs8jB0esvTuh3X8eNGEFkx15zx9 2KZ3uMDS7mRwF4zHXGkCPWw04B4GJ90ujxPyOFkch21RR8qOph0V1ywJeWYX2WXkxCqXXMKWhGYu X4IKJb5Sh0tUwZFF7dnh9E7hrpLSGME5JgIxnI/jYECwUQ7NpqrJOf5S+GxucQ5anMstHYUzvgyT Q38lT52RtR9pKxX0uGfCbSccuMsOPmW3szbEZI1lHJgjQxWq8LJwpLqILlZncktINU8701jaKd1I ED4rbUAfbL+hWKDLnqQbEgjO7YINdovagTrUfVQPsuMwX9Bi1hSZK8G5aD6ZQ1P5QqYu/HrirDvv hbrFGwG5WdfzAVlQiAc46SYJjCmQR2k33Ny+b+152dvyqf8drwvVdFl1+s3GSpyfXmzUKkkomhTC PBKL+L0RLOwNsgzY4y2UEX2yvVvm6qfHnbA77IlSKB2LexNIQghHwQDFMqlcIV9I5/isk1c6xh1W Ow6xXhaQt9cfDHVwEQ7DoXAyVgWr3EEZPxWpFeECm3EnUIHAOQcyOuLUDmHD2r1bnrpXvKmlUwK0 P33lOumkG8yE61NXe0nhowNyIQmn2ITnvx6qt2XtPpB6uJQG9BSPSmlIvE7DHsZMDqEb2+Myj847 4ZbSiFEoFeO9SSRfiGVLWKNUbRRn7QmlXW+32J0Qy7B+FvF5A2E/5uuoTzicilbQv4p/kYHodl65 5r9dPKY+Fd2nLx5dH5/D39geBOQZC3CBcAAKcBGw7nzUHCZMU7CPnSCG0HbX2medu+1qm11lt5qo ccTreyYAGC4wKf2CylAwFAmhMeAaYjCAJAMEn6ZCJEJ6vDTVmS8SVIxISDFl2AIAeHb+CHZkbvq5 0i/FL7YeVwKWg658RxEAi2xGCEo07mM5jOvoHzNJ+ynU1dP+AVjZ3pOfER+6/PxUW1l6MGkBHkO6 akjnoqkclk81mvPHgVZb9Tar3QWxFONjEIbmkgzGJN0r9jeIFc8sXT66pOTjxexsNZvM8jkOrJ/h Sse4qSUHmJWn+Ek/+PZk2B/0QUFfwOeDvT6aoVCrsX9g067tPUrxay2TVHDkqmJnEoEYkuT9n0QM ijaItr+2dkhGDLJGN0yA1no6rU0g2Swn5LFKrjHVPOpMK+1ax4QThxiG8TOgrAGATV94ErSWC+di TUk4fiUtmadbdyvCYB3NC8GrDeKwKBuiJZ1l/QzqPnxP+3XZW/LpPxWei+VyS5XlmdXplVqjIEDA SIcTCBf2e8NYmA0ywHexE+Qo+t32Kdk78sr7tVcap1ffPfH8qRUolU1H00gk4mfD0qiB9jPPgLAA d1sACHa175U5e6hRJ0hH8klUZ+CEZDgGvEQ0my6U86VUNpZ08EqnySkNHEOxvo5bktQw7A8BvEbL yRX0JXGLLFoM5fNwhc12rntcYOD0esKsw/b07Xh02x1LYrcyVgsXMnCWSRHS3TwecSAWG0vYMI1t TDt62DJu6NfufkXUK7vPAkKO2HIhWYCPBkJgxiTsRDrVoVkziPx77RcBvZR/lZhJTWfrqulzU0cb c825eqWWgmIpiV447iq9hIDJxlkroJcnAL24B2i9RC8fuUKvgKQynJDDarn6VHMVEItNZ59wuiAv cIVexO+TXKEvJBFLJJyKVQCxHJLxM1wtD+eZNCEAYnFydmRUjWuHsWHd3s1P3PuKOK7sbt3fuk3R 0A2nDiGHDuK6/ZKaDwDjo9+H79sHH0gNNnSotrGIH0OOHU81TmAnGgtLtVNQ7WTy9Cn4BL6ga6J3 tBcVG/oOjexHjBbpgt+RpSrT8GuF11ZeR19fPjZ3CqnkKQcgdIfk+R6xbDi8Ee0+3/oBICbJN/EI H/OzEjFJh3WMz07p0fYNaz919xIGwqMiPROMpmPR7Z17GXsgBFTz6smgN+LnonAsnIlW0QXxixlP ikl6VT4h7c8g77+2+M4L2PPvNN9+E14kpybKaNliSGgRrY6y6zCdY1QzfHhGvE75aNuvSF+onZpf hlbm5wsLSCZN4wIm4JxVD4+yo4QaJdRuncuAG50TdqvdZsdtQMBsNtaOjOiEigXrbt3S+onCsYOu uHPOhCoBjIQJMLhL34/tHe47qNkBaXY4d++Fx2La7Diqz1RdM0i5Gs/VsMXq8rGjrzzWZpXksMdI ERRBUm6W8ln8o52FxiVl7MCDYRJjQuxHGUejcDScBRmL35Ouou5sOxSGnaOH+tWQ2WAiLIgDl+7P iCSTq8AvlV49DuzdsdW5ZSSfoYG9S3YO6ftdBwy70O6ZZ1u3KEJZAYii1IOOdwUaJx3fDQPgPid7 V555ORCNlVKLKh7IY7I4c7YJTHeuKCTjYQj4GvBkKDTpC2FBf9DLwEFgsCMsxAJIx5CUEE1HsUSB K5RgAex/HBoFxEwg9gnCrMd6+ndtfPrO10WPsv2AXtY9I/65tUnh9LgpHGHdoagDs3NE2AtkweMJ EMiQhjCbMJOZGB+F7WF7zI7Gbfnx5khzOK+PW6EIEQLKY6HtThzFcQttQEbH+aINsxbJef8ZyCbX tL8HFud0LBFNIVxcuvAgputsBTk6n6w1sUY9NTULF5mSq4K6y/r5QycdWTLF8hAb9yd4OMMlBUAD QoYrINUiaclK196jwYNQTj4lfuv/MmpuP05UcRwPiS2jD/tEk6GTzGiiL6KJL8ZE4c0HDTERY+Qi glQtlL23S9vZdjqXM7cuO+10zkxn2067ddvusnShlMAuZi9xowYwMRASfUIfQIj/AJmS0cQzID4a M8k8njkz53e+3893zs8XY21wPTT86fjpeDqeHs2e5OU0/kvwTa8X4E7KE3SYKXKmQAqwrFQQu5fK DtV2FpeXVjM2njid8dmdYwVZ9PHAx8aCL8GW3rRXyPvulcDtIDwfeC942cWRGL+GmJeNJN9NHkwP 704NJ06NRkejiQTNYRzNyBwBZK2gUHIxr5fCNuxUVslt941Adc04Xw9XFBuYpAk45MDppMhMUWP0 +PjEV1UeP3e+UYeIKSHUIFEs+itaUDVV8UEhd5I85O0JTB8C0Xg4q+fKHMlbc3KN6PaclctU/8L6 zR8ext/OHJTPYDKdz3K+5ZREP2b5qlUtlWtUy1k49/VlpownT+VSsoKyrIxU62mWndH897WNpbk1 8nd3IzB0rz2gQoWqjZytMQemIdU+VPN2QS+CPvhPt3p9w9i63l9fuLjQqy3DNqZXC7Xas8N7ji3l CFZ41jfDI/ZlEftWOYMHYUEVVJ5UciDL0RIfjx0/ALjEeOS4fFfdVjvyJlgDPbEN2nzLo0Zx/yzg FVSU3mferzPl/GL+6m7JfY79LbXtvXgaR96LZoiymO3/n7U5mNRj9juGt0PzKKwZdI+5D7reA1R0 9fpi99K13je9jYvfLq01etYSmrFWdfzOLwREluAvByuoCFZE0YcVUfPbDYpSSTIlKKEtqWIFpI1i OMvHUzEyduDYBx+9HxvsQOCyNngLQcCsBc9CYsFRBKRbgpU1kppsnZjfC+jpscnIBLKrDOvzm6oQ ilg0AFVmOf0pIIlPnsn5PgPFf5Cy0YC1eWq5c+X7rfvNVysfGzksVa7wDcKu+qjTbXe6zf60iecS mTSdxYAAVFS6sqYrlKJLVanzhbsXX9podZsOZlqWDgndUuUapUJjxiBsqwgtStc1OBe2FFOApAG4 IkPwIK8CKicz/DSTYZgsm/l8P57bFJYlGzisk3GwoXvOYI8PIlrdRjjbrEocSomcMaIfXvRu4tnk 1MTIcCKRpNFmUBUln/ezsE+KBVVXoWqgu4YVFHlW9Ls7OJ7iEE3nwvy/BG8RzrxRbVGtSu/ixnd3 7t74efP21q0LW84KVl8xz3XCTbnGIydFxMA8qbEneImG4Ao8GqIEoGSqllpStTyG4ifaPfKMlJdJ VIbpzOTkiakYHY8eHo+mEklXxOV1ZUWpKTVQ5xrYUPeqeyNUD5oNq2JCdJVMDRFxfXaZcF8Keg+9 RwHGvbNzFWkAHRTOCFkgiECQhDymCsmZGOG9HHQfuo8CtvfjzqGEGxl8GfpfXYZgVvrPLkM6xSR4 P2v/8Xh/6M8X/joSWA0Onn98JDDkvj7YF7oqXwAdrs02U7UxzBmDsUj4w+zRkSgZHYnRUUIAswWR EhDD5MqYcyZtThMspwiAEtDWZMNZg53jSabREVeIft9q9KnFaqfRarfb88vOJcy5BK9cC9+a2j7W J0dbEecT2LuLu0cRSwW8yeDQ2bPBgbrLfRz6W4ABAGK+fiEKDWVuZHN0cmVhbQ1lbmRvYmoNNTIg MCBvYmoNPDwgL0xhc3RDaGFyIDE0NCAvU3VidHlwZSAvVHlwZTEgL0ZvbnREZXNjcmlwdG9yIDY2 IDAgUiAvQmFzZUZvbnQgL0JOTElFRytUaW1lc05ld1JvbWFuUFMtSXRhbGljTVQgL0VuY29kaW5n IDYxIDAgUiAvV2lkdGhzDVsgMjUwIDc3OCA3NzggNzc4IDc3OCA3NzggNzc4IDc3OCAzMzMgMzMz IDc3OCA3NzggMjUwIDMzMyAyNTAgMjc4IDUwMCA1MDAgNTAwIDUwMCA3NzggNTAwIDUwMCA1MDAg NTAwIDUwMCAzMzMgMzMzIDc3OCA3NzggNzc4IDc3OCA5MjAgNjExIDYxMSA2NjcgNzIyIDYxMSA2 MTEgNzIyIDcyMiAzMzMgNzc4IDY2NyA1NTYgODMzIDY2NyA3MjIgNjExIDc3OCA3NzggNTAwIDU1 NiA3MjIgNjExIDgzMyA2MTEgNzc4IDc3OCA3NzggNzc4IDc3OCA3NzggNzc4IDc3OCA1MDAgNTAw IDQ0NCA1MDAgNDQ0IDI3OCA1MDAgNTAwIDI3OCAyNzggNDQ0IDI3OCA3MjIgNTAwIDUwMCA1MDAg NTAwIDM4OSAzODkgMjc4IDUwMCA0NDQgNjY3IDQ0NCA0NDQgMzg5IDc3OCA3NzggNzc4IDc3OCA3 NzggNzc4IDc3OCA3NzggNzc4IDc3OCA3NzggNzc4IDc3OCA3NzggNzc4IDc3OCA3NzggNzc4IDc3 OCA3NzggNzc4IDMzMw1dIC9GaXJzdENoYXIgMzIgL1R5cGUgL0ZvbnQgL1RvVW5pY29kZSA1NiAw IFINPj4NZW5kb2JqDTUzIDAgb2JqDTw8IC9Gb250RmlsZTMgMzggMCBSIC9DaGFyU2V0ICgvc3Bh Y2UvRS94L2MvaC9hL24vZy9lKSAvQ2FwSGVpZ2h0IDAgL0FzY2VudCAwIC9GbGFncyA0IC9JdGFs aWNBbmdsZSAwIC9EZXNjZW50IC0xNzcgL1hIZWlnaHQgNDY2IC9Gb250TmFtZSAvQk5MSkZFK0Nh bGlicmkgL0ZvbnRCQm94DVsgLTQ3NiAtMTk0IDEyMTQgOTUyDV0gL1R5cGUgL0ZvbnREZXNjcmlw dG9yIC9TdGVtViAwDT4+DWVuZG9iag01NCAwIG9iag08PCAvRmlsdGVyIC9GbGF0ZURlY29kZSAv TGVuZ3RoIDc5DT4+DXN0cmVhbQp4nFMI5CrkKlSwMFAAQSMgMjdQMDFQSM5V0I/INFRwyVcI5HIK 4QJxDBUsFELSuAzBSg0VjA2AKk0VQnK5NIxMjDVDsrhcQ7gCuQDDORD1DWVuZHN0cmVhbQ1lbmRv YmoNNTUgMCBvYmoNPDwgL0hlaWdodCA5NSAvQml0c1BlckNvbXBvbmVudCA4IC9TdWJ0eXBlIC9J bWFnZSAvTGVuZ3RoIDQwIC9XaWR0aCAxNDkgL1R5cGUgL1hPYmplY3QgL0ZpbHRlciAvRmxhdGVE ZWNvZGUgL0NvbG9yU3BhY2UgMTUgMCBSDT4+DXN0cmVhbQpo3uzBAQ0AAADCoPdPbQ8HFAAAAAAA AAAAAAAAAABcmwADADdLAAEKDWVuZHN0cmVhbQ1lbmRvYmoNNTYgMCBvYmoNPDwgL0ZpbHRlciAv RmxhdGVEZWNvZGUgL0xlbmd0aCAyOTcNPj4Nc3RyZWFtCmjeVJFNb4QgEIbv/Io5brMH/OxqQkxa myYe+pHutnfE0ZpUJOge9t93ALttTYDhnXlgfOF189DocQX+amd1xBX6UXcWl/lsFUKLw6ghTqAb 1brt/KwmaYATfLwsK06N7mcQgvE3Si6rvcDuzn/7x3Qf3QB/sR3aUQ+wO8XvHyQcz8Z84YR6hQiq CjrsGa+fpHmWEwL/Q/+mTheDkPh9vLUxd7gYqdBKPSCIJKpAlDSh7v7nWBKItlef0rJQGUW0MA+Q EJcVI26rOPzUB1wkhSsqA1UQlSiK0zQINQlp7oTWCxQzkblzs4Bk7qLMJfNwc3ZPQu7wvPACxUzc xhQfpBcoDv2EDtwvOdevJqmzteSffxrvj3Nm1Hh9PTMbZ4Qb7FuAAQBDv49bCg1lbmRzdHJlYW0N ZW5kb2JqDTU3IDAgb2JqDTw8IC9MYXN0Q2hhciAxNDQgL1N1YnR5cGUgL1R5cGUxIC9Gb250RGVz Y3JpcHRvciA4NiAwIFIgL0Jhc2VGb250IC9CTkxJRUgrVGltZXNOZXdSb21hblBTLUJvbGRNVCAv RW5jb2RpbmcgODEgMCBSIC9XaWR0aHMNWyAyNTAgNzc4IDc3OCA3NzggNzc4IDc3OCA3NzggNzc4 IDc3OCA3NzggNzc4IDc3OCA3NzggMzMzIDI1MCA3NzggNTAwIDUwMCA1MDAgNTAwIDUwMCA1MDAg NTAwIDUwMCA1MDAgNTAwIDMzMyA3NzggNzc4IDc3OCA3NzggNzc4IDc3OCA3MjIgNjY3IDcyMiA3 MjIgNjY3IDYxMSA3NzggNzc4IDM4OSA3NzggNzc4IDY2NyA5NDQgNzIyIDc3OCA2MTEgNzc4IDcy MiA1NTYgNjY3IDcyMiA3MjIgMTAwMCA3MjIgNzIyIDc3OCA3NzggNzc4IDc3OCA3NzggNzc4IDc3 OCA1MDAgNzc4IDQ0NCA1NTYgNDQ0IDMzMyA1MDAgNTU2IDI3OCAzMzMgNTU2IDI3OCA4MzMgNTU2 IDUwMCA1NTYgNzc4IDQ0NCAzODkgMzMzIDU1NiA1MDAgNzIyIDUwMCA1MDAgNzc4IDc3OCA3Nzgg Nzc4IDc3OCA3NzggNzc4IDc3OCA3NzggNzc4IDc3OCA3NzggNzc4IDc3OCA3NzggNzc4IDc3OCA3 NzggNzc4IDc3OCA3NzggNzc4IDMzMw1dIC9GaXJzdENoYXIgMzIgL1R5cGUgL0ZvbnQgL1RvVW5p Y29kZSA3NiAwIFINPj4NZW5kb2JqDTU4IDAgb2JqDTw8IC9MYXN0Q2hhciAxMjAgL1N1YnR5cGUg L1R5cGUxIC9Gb250RGVzY3JpcHRvciA1MyAwIFIgL0Jhc2VGb250IC9CTkxKRkUrQ2FsaWJyaSAv RW5jb2RpbmcgNDggMCBSIC9XaWR0aHMNWyAyMjYgNTA3IDUwNyA1MDcgNTA3IDUwNyA1MDcgNTA3 IDUwNyA1MDcgNTA3IDUwNyA1MDcgNTA3IDUwNyA1MDcgNTA3IDUwNyA1MDcgNTA3IDUwNyA1MDcg NTA3IDUwNyA1MDcgNTA3IDUwNyA1MDcgNTA3IDUwNyA1MDcgNTA3IDUwNyA1MDcgNTA3IDUwNyA1 MDcgNDg4IDUwNyA1MDcgNTA3IDUwNyA1MDcgNTA3IDUwNyA1MDcgNTA3IDUwNyA1MDcgNTA3IDUw NyA1MDcgNTA3IDUwNyA1MDcgNTA3IDUwNyA1MDcgNTA3IDUwNyA1MDcgNTA3IDUwNyA1MDcgNTA3 IDQ3OSA1MDcgNDIzIDUwNyA0OTggNTA3IDQ3MSA1MjUgNTA3IDUwNyA1MDcgNTA3IDUwNyA1MjUg NTA3IDUwNyA1MDcgNTA3IDUwNyA1MDcgNTA3IDUwNyA1MDcgNDMzDV0gL0ZpcnN0Q2hhciAzMiAv VHlwZSAvRm9udCAvVG9Vbmljb2RlIDQzIDAgUg0+Pg1lbmRvYmoNNTkgMCBvYmoNPDwgL0ZpbHRl ciAvRmxhdGVEZWNvZGUgL0xlbmd0aCAxMA0+Pg1zdHJlYW0KeJwr5AIAAO4AfA1lbmRzdHJlYW0N ZW5kb2JqDTYwIDAgb2JqDTw8IC9IZWlnaHQgMTE3IC9CaXRzUGVyQ29tcG9uZW50IDggL1N1YnR5 cGUgL0ltYWdlIC9MZW5ndGggNDUgL1dpZHRoIDE3NCAvVHlwZSAvWE9iamVjdCAvRmlsdGVyIC9G bGF0ZURlY29kZSAvQ29sb3JTcGFjZSA1IDAgUg0+Pg1zdHJlYW0KaN7swQEBAAAAgiD/r25IQAEA AAAAAAAAAAAAAAAAAAAAAADAiwkwAE+GAAEKDWVuZHN0cmVhbQ1lbmRvYmoNNjEgMCBvYmoNPDwg L1R5cGUgL0VuY29kaW5nIC9EaWZmZXJlbmNlcw1bIDMyIC9zcGFjZSA0MCAvcGFyZW5sZWZ0IC9w YXJlbnJpZ2h0IDQ0IC9jb21tYSAvaHlwaGVuIC9wZXJpb2QgL3NsYXNoIC96ZXJvIC9vbmUgL3R3 byAvdGhyZWUgNTMgL2ZpdmUgL3NpeCAvc2V2ZW4gL2VpZ2h0IC9uaW5lIC9jb2xvbiAvc2VtaWNv bG9uIDY0IC9hdCAvQSAvQiAvQyAvRCAvRSAvRiAvRyAvSCAvSSA3NSAvSyAvTCAvTSAvTiAvTyAv UCA4MyAvUyAvVCAvVSAvViAvVyAvWCA5NyAvYSAvYiAvYyAvZCAvZSAvZiAvZyAvaCAvaSAvaiAv ayAvbCAvbSAvbiAvbyAvcCAvcSAvciAvcyAvdCAvdSAvdiAvdyAveCAveSAveiAxNDQgL3F1b3Rl cmlnaHQNXQ0+Pg1lbmRvYmoNNjIgMCBvYmoNPDwgL0xhc3RDaGFyIDMyIC9TdWJ0eXBlIC9UeXBl MSAvRm9udERlc2NyaXB0b3IgMTA3IDAgUiAvQmFzZUZvbnQgL0JOTElFSStBcmlhbC1Cb2xkTVQg L0VuY29kaW5nIDEwMSAwIFIgL1dpZHRocw1bIDI3OA1dIC9GaXJzdENoYXIgMzIgL1R5cGUgL0Zv bnQgL1RvVW5pY29kZSA5NiAwIFINPj4NZW5kb2JqDTYzIDAgb2JqDTw8IC9GaWx0ZXIgL0ZsYXRl RGVjb2RlIC9MZW5ndGggMTE2MDcNPj4Nc3RyZWFtCkiJlFdLc9tGEr7zV8wRqDJhzBPAIYfIdmRv 2bHWkjepTVIuGqQkrilSIfWID3va8+5v3q+7Z0CCL8tWmZhX9/S7v3l+eq7V1WqgVYk/rXTR6KYO qiysLvFtbwaluhqcXOBzsRyURamNungcPP/J4PTF5UBjqRZiHoVQGKcqrQs6eDP4LSvyoTbZIjcu u6Wfu3xoTfaJhvN8iN9Rrn12kw/rbEIj9UOuQ6b+m+sqG98OV3mdtbR+zYcntDmm+X3eZDOimtKS sLoirv+j3Wc5LlX5H+rib4NXF6TAEPJBwItWRo7UgJTOqou3e9XwdDw0TeGb2odOGVNmqxZCXbMe kxxSfpryeMyC/wB9oQXL8yvJ8woLIfv50zkJ+4J+Xq+XX36k8Vvww9yV2Qfi8eklnTo7fwYmuq9F SQqULPtBkeu6KKsq2f8/ffrkwcPkVSi896HedN+Y/fcpOiOsneGz8f1s23fjWzooh23TO/xp1599 FgVz2FL5mLjBF6V1CLo92iZPt0fovS28NlHbf++Qa2/Z5IiUYGPM6OZ4zDhTGGsTz3FeFxUSAGFR WAS+fFf5sMKnpTBqMJiwESAMhgrxZOz6kCLjL9PBHGJ1W7cyA/eAzzyeWcGIuDOx+cwSzCiaCoSs uowS0e+Swq5wmUoC5SVW+1IZGk4T8yumU/+Q8y+iPmcy/Sg3R2aULqzARccwh0TVvpgutKX0PJKU 3lHwNkEFCxm1rqPPOZw4QMfrmKI44ySExo85Z2pKy7Sy5NOLWJRSCI9ouFwzUv+iiLwnfnxKSb1R /ZQ4Es+UP+pHupBXiYBJn8nOhnBcBEWRKQ0vv27lrin35u7aMLopdFNGu9xtZSr8juG9lEqW+U7q J9/q6lhEEW02Jbx8WC7OeyZgNdTvWc8Q6YxPZ7AnujPh77ncvoihnO5ha4/HwuqKl3bEfgmLneH/ 8EmFbG2MsipCqJtYus8POyrdLj7GeMlirYOC+8o0TgO7kHQrv6dQ+SYgsCsfy3KP8vlPLrZTI6QG aiiPSuxiEfHF1k1vQeS3iYKltrtJt1P8pXvvXFeJ7TYoz3KtqdiQOS5zzTUGvW8pztbkOs0VB326 5WOTHE59hYb4MIL76+x+BAtKFcoW811TfQNE+OCK6jus5Xxh1tYi7+g+1a65GjbXBuG2uUpq/C2P nDtkuiBht+byCuCjCNlfufH43JIRqcTCdA3mUzJWwUasC7IaLc7vEHLaYXlGFRIt8CwORvKBKZHc LrsUqkU8vWRqJJ+mGr7bvLSIH4zRTzG5RTOMJn9PJVwDZoGR5u5DXzX5i/SxcQ2lX0OhsmhIBghK IUOzOcG8GtPRLK5zE7sWLXXsZpoqNrF6HKUFIVe3aDKM75iWAokHl7y84N9EcRPbpZa2B+K768SM L30T5Txhsnei146tjIttqKy+2YVKU2OAbtqsoeHJjEHgKELBYUPJY6ihyrChXHF1xL+8sOQD6jXK yTlnkMFIAwUEag42UHPg+gwCLkbXzEEJC9pbqD+5mt1HJB3vxnjINmnk+sWSCflStbhUb/jIjjxS 2H+NyUx0cgQ6M0HpuZ/vMZ72XqxnAo2i+fRe+0GqBpniKSeqoLWYb8TyUvco8atMwfHus/I0brwm 5/rsn7wvwMJTuZHdB/jWZxOJCZ99RVOl7bu4/UhOJ5BALFQbVxdMlGgYWHmBLp7wEN93HXdH3TGO qYAwMnTFCfNQb41i3N8mPdqcP4l8UiQM5AUD+cMRWNqwt7FFw7kGYextiHG3Su5i1AJvPWyMJel4 KMHBsMidMg1FwocfefiOf2HVYPc5t4qpYUx1qMc55eqqgM9NrB9R3QoGY5NWYuAq2rtil9nksqoD uUjVCvFcd3A2osmqy+sq+uBFPDyJxaaSmlVRMtFnGPe9xFKVOcVqTufyfSnHFnyXlK8qG03Trark DeSgJmw9jQc6IShRRC0G2dwJd6Dt2qvGhKfVFWCEoimbKjYTSy/ZgvR1hNEKmlqaom6gUHzNK0Mt Bu+s5QMdmApCga8Z05FFne23wvUjcn8rdVTZTK+VmifBD+6nm9Q7/ZSNcbCJbpKeSN0EKm3xc41u CefkpJDLvuRAIhQVu8Fa1jFYja+roy1PW00dm80d70SS5vReIRcbdq2l15U6vZ+s7rht48b35+Jw tJ1K/F6y25F0Lxc5P4Zu4tlRLpGzfe5jx2GYnktlSoFRXJv19xY5v592DFpHbeumOfo65eoRApwL WBVcmWDei5z6gnQDAvjvKXzO6WeIHU9xhAig4EsjAuloLK9Gbe7opYh1eVZpZJQmaIKVm9F0zfRj 7gCVpyv+EJ7JZjM+1fIT4G7CLw4FMzVZnVtHj0uQvWDcn+ipHlNbxK6m+Sk/8Pbnmrb6CU2IrYER XpKlFWt8oJTht9o7+nlGyaZqGp6SOie0jfcI5us0+8KLI8rAec79V9TE/liePNi/lVemJn/6QC30 jo5dT/IAhT5zpk5pZXyFmI+hMJ/QCr9IHinXJaG/KElzbM15DzwsYXQu8pi3JAqTHgaEpan08XIE C9UB4MY5XeDt4hux0GUEU30MtgG5JDrUtEOAkzWCpAOtTIV+LhN8vFsfbe+4ueosATsKFjkttz0K 0EvbuJyYcRRKVU/8Eygt5cAocRjLfO/ZUfwKrE0UH+XK4gj0cZqhjz2UgtQmjQ0oOZijqRLQJJP+ EjtkB0FmEUNMGOu0CcR0aOZaji3ZaunYRI0ZikzjoUueXebVJi6azOPgrmMWoRK/UvwG/llcxkF7 ny5a9gHMmpe8CYXfSISbpt3IT3DdmgPNRjdbCWy1tU+LSgsQFKwPMW8/C/yTq9PNrUwT7LrpINyX VQRvapas1UkZLT9ONs/RJeq1Nlz86uxirSx/5f6+31CmOh6mqDvegjrVZMtA9/vAaMorcq+8vMLG oSnfc9O7ldJOu33wUnsrgWprZ77ZK8TKgHQwcsLocq/lmyIqs/JAtKS7JbgkWtq0G5vFKK62TMkR xZ11vS5fDsaKqucwgSq+caxi2WnJelW3/sCzaZq23eiKN+SZACne9Ki2hBrz5phvSDgPiqRBd6Mz mD1LLoEZ1DtR8kw+csluh45mL0v7jZdlZ3ZAktq6EOvDbPqZzIIaz4B0JOAhQeWv1E+g0/0KWcjO 4c84Z+RC78eVAFh1cytspq0cuTayMWS2GpgKn4InEfr+RtFPW+u1P/DrCI+W22iEYiyp6rRALy3Q i3EhKcoDXcLHRlkAEZseC+n9airkEv0inhxFvS6+hVx3YB28GHrc1R7wqg9RA4Tgn+8xOOkY/DnQ cloNAaOMtY1C1hnbBNXegHcFKBmg47BqAGWdWk4Gvwzmg+en50ZdrTriRDvsEZ8ykKvVI8kJ8ZZ7 xKsPCAYKs5fCIW2aSvftPdmk2yHxSFJTNn0jzo+ToDkGApWbJO1RkmCoZcIImyTXx0kQe3XZ6B7J zVGSCpkZtm8ZHSWpUa1ruKVHsjxOAqRuwlZQfzlK0pD6je8H2uo4Cd6Xld3SRR0jMWVZoKKYqkfy /jgJ+hCity/Yw1ESNBwkddM8PcaMbpACof4OIwM7FaiJVn+HYAbArtFbukyPklC/r1xpv0MX1Azb VHXfyI9HSZCVpa29PuDKv3cVAxg0MCEPKMuQZFoXFX1RNTYfPgefukBvFJvu/6RXy3LcthLd5yu4 FKsshgAfIJe2yqlkocQV69ZNVZLFSDPSTHkeqtEovvLX39MPkADIke2KFiOyCZxuNBoHp7uCBgpx 1J30CHtuF9Y7euYm5igNzYR26d6y83qhB22V0BJVhXNg+kYvrqsFNbsn+llRY/JwIKF4ZK5/oZ4v vSsN6xIiRWfqOU+G1FddNuAZ3MY12Na3sQy9ZDfZrzl1QvC6U9fNzK083CTTYwbGtChnSVjV9dr6 cFPK7euR29rNgu5l3FQTofV6umzpaBHYCslXhytfquycZnslI4gP/xiMM9JZTb5qE9Fqi1iVqaLH 151+YEk/KqTTGMlr9x0US8c2iERqEss6gxHAZVUHtm1gc0XpWsS9DSePxvUP9/OomF60bWzdRtZv QKbhpjsDXc8hxyGH88/FbHtsaZKJwbadz850wYJqsMeuTGENjj+iiHFHY4ARzE+R+wqsMUGGtUn8 bUNriD0iJNjocanRTbDJSrG4CDuwBigBQoId7ECAPW5WAH12W9MK0Iy8Is30NApp4Lg4N0ccYHIS 79SnKKH/TKT04YpYCD+Vucg+3jB1/E5U8p4f315Pqbb0NFi7dpYG+47Ir4M36PC26jvt0N6C+Y5H 5r6XvG5TiT6sgVs/M09OaBEsV2gJJmgGhqUu4mLzZTXh7TEzl6/AgkrrsiybNOLrVc48DfADeaDO 0FLw5fwVdBYf29Iyfhz2u1wai464ja6Iz8TZGzIsT+Rw/b1UhxJDfaakNFi3iZXK0UaHPDDG1IHU m5Q6Bts2ohPvayasCXUEsCNLBLgRn3iMmHoi5PHgh8gjSYTQEaEM2BH5hNjBwQ+wA5IIsGNC8Sgx +YTYwdEPsEeWCKAjPgm3daSeKCOvU8eEJxrIpcx2EHGN1xbvqSA/4ChcXeW2mTlgTgQLJEHnRpE0 Sw5Q41AFoCLbuaIxTaNH4bfHFd3v0LcX1x+yaxyMgk8CCKtDr+bwdtTvdBTxepmGIToTD1XLDAiN U50Nwlnqu6xroMErU0kQt6v8sqezWJNPLHrNj6zU+Jge+f1T9sSc8EyjEWPtSEfi5E7VHOukdqRN pNXUs8KLlF1X9QbJRwVa13vhfbPO2XFbA//SsFwCVeTdOaY7L+7IB+in8hvcdbrDvz4T22CdYLZb elxNoEvjsat5au5AzdZiY12JLXZ1o23TPMlfnkcClXSud20a5M2G6HK3ot/v5cXSgNcnvDhYI17U sxbzYmCMeNG2FhUU8+JoC3gx8DUTVsqLIexAgSFuQJYjRsirCfLAahHywIARdMCWAXbArDH2yGoh 9siAIXbIliNKyKwx9shrIfZAgSF0QJbxtnpeTTLyOi/KlZ6SY1fgMNtaW6JfrnEI36X1LTQEuK7s m/k+saMC77nSTUOVznAfc6YQdLn7JXW5R36+o59/wLvFHPMq8YJS55mul7Nk4IsZ3YXK5ulpwTz2 MN9/4qEeiPSc0sOYBug1x+DbO9FhH18TZdo8elY8xwWszNhDHP/NUZvBhe8KtXu8zzu0iiv/+RWK PEM+4N7SNn26pI+PuSP+7fDjwL4smL+PhKhYG5OS0GjdJlYq7IiEQmNMQrVDISUkNNi2ETF5XzNh TUgogB1JKMCNmKkxKQlNkEcSCpFHEgqhI2pqTEpCKXZAQgF2QEIBdkxNjUlJKMUOSCjAHkkogI6Y KdzWkcSijHyFhHBOLNXrjz85jLq5/6Gn9o3m8IOpSly6Gcq08Grh/f/ypgRpmBrixZBaMA6KpnI4 5T2xS1v03124aNZal5aXt22TksMhjcorMKblNcKGRTACp6UhKGmBjthhEYzYYRGM2GlpCEpaRiN2 WAQjdlAEI3RSGYKRFtGIPKYK25n2WKNtO5/76Sa9ghqkLsCNrU1Pwn8bA3hjsoMRtOeCCHlgjWBX ZyrAIxufoxB5PPQhdGT18cUIUdQzKFHdJdjz1VjO5noOZRfWUoAdW4e4I4Qw7jmUqKYT7PlKT0/F iD3dyaBSA+zY6iOMEcK451DC85JAzx6i9Lz9C+QguvmV8D4WZW1aJ5yoz5cWstG0oEhjC+e6WCHC Vckt748/WWHoiWZE8uHfQr6ozvuZdN6GpMTDOvuQk6KAUDpyW3dPzc2BfuR9R58W1Fbu+f2OHqXN vOJh3Js+PtPjiR43NEHGPkijhJ8r+lmzkbG2NHIrYqbq/XB+zv6S+Ciuq6u/8uxPR5P/ZhHHQT/R 54muEtULyYQOkDRjkgVQV1naDgLLsKxqNBcQoIT2xDqUFwALRwQBvOTnozzrmBWZTjLrcJ/JExsH DJ9dAXnQiS/hdxZyO0F5pMkrToG4usfAi4M87zQkj3YnScOMzPug6/QSSf0UOF1qQCQSEeVU/BpV 2JYErUrsWQU/JI7EtkMdmiFxFmUsstdcPK4oBjzcneIPb/BK/7ONCGWM2OqIZ0TZ4v/w5QHaGau5 UqgPgvAfVBSZvaccKzAX3t8qL/FxCTe1JTceS+w+mM+CcWAHRx3yifJWX9yy0a9nr7hL/a8zN/rZ m09rBXmT7fTTSgLzrweUaeDsRdYWdzpV1ZpXOxzcgX1vkfwOS+/rVpuBY7TIxRBbN5+nmv5TikxH KVrsNfEZHaoxYTz+6xlrLpY++Vvv+kUWO2z2ysPcFd703xW7e0Z4lnZqhf6MA73Rob+zq/f69lY+ XuvmTzpEp+xXt9VXCtin0DVgcWtVp95SxI47xcLprlc4Xvy61tcdqAevC/l3VOsnGZRBz54OApOd FOiJ4nXIYslWmejhdEymgx7ldSUdowxdemzKs4Lfq4+dzt+p3feYL3lDcNkxdrNYyrAiu0nDgAB0 wszJHI3sWd62XDuVruYpr3lRyVYI8V5qq/AttdyiHpvSdZ5IwPpH4f7nHNy1R3l1WB3Ht9zAKzLA tFjrfSGj9yf6lN3R80EmbvKWriHQLF9DYn1Cei6y25e8b2lHYF+Ltye5BwHyJWdmJ+NhcJVJZJyl BQ14yZ2V26fITTWpSmXUztej6eeyQNexRR4y09iic8bqRfSeyHsZ3J635Ph5vIn5NpX7mu/Q40Iu UUzQm5QvVrx+68185dM43P4sBHAD02cOyN/CPP43vDwGF/Z1TgPSy5hOp+v96XTfyG+1Kaq67/Rw 7jZ3ed0K8ZhWyNTg9TJ3+L2VF5Qscc5eh9zJ61pfd1TCxI3WBjif5PUp4wX8KUCdGP8WxsmSKeom O2kMMlXOO92xOD58zxB50oGvgiD8XEwp/VCc1uZ82Ede4SEes/kigxYKv9FQ9nqniK7SbPCXJcNM WbNVkWRc/Y2saXt0Ya7Sw8qE1iqT1MIaLR0aME0rhEYHqS9aZRYOjIynjQ7aq53pZJy7Vygmvjum tJaSQ+62ecmwPIIpCgMX/uGzAK107Hb8shDTEWnyvwuGUngdV2S/8LcTf8vUaRzXialwWM1Gxoxr EYe5HUakuTcVp56yjpvUcqr5oamR8r7otfSzf/E3uDSyk9klguTGC22GraRzaDq1Uata+XautBPr NrG6vi0trBGAN3L3ol6908vAqyfIeO3QlPHiw6Q1aIB4KD9wmrg0eaSZpFcpp6x6phxHoDSbH2i7 66xvi9qh2VJfLWsPLMKgoC0dJUiUqkSlMLuD6SpVV471LI047GUkqq4bx2TLg5r18wG4LKYMW+8U /3B4iqbpaLzi1yMyQfGzn/6PH+Z5SeKpOhamJnCogNBhJNeyP0Jve15cXeSWGKL0/9/If2onOBWK y4NPcXoWPqC9X64OVrtP1a183epsv9q0CynroQlRMurkzoz3rjUkfTNSwKa3jezeH9o0Qb/vc2N4 /T0IyBiWRY0a0M621GHBjODq5uJ0xwSzJgst2VKuLUnhy6qUx2cMVKhHBjkoKt+j1rtdMsQzj9jz 72mzFZggos8UZ5Hj9nyHT7W0LeJHvC95mECy+Q0NFkdr/WZajY99ylhe2YLRJAZc/RpfsJY7Hhvg MIKfIIuh21+mbGQdE+qqKy/xrPXqxhpzdqtcV9ga0/xW9SI6C2o2LL1kVfF/1quuuW0dh/4VPsoz iVYSKYl67O3HbGfauZm93d6Hvfug2oqtie14Y6tp+usXOAAp2Y7TzOy+iCIJgiAI4hwwXNmE2mtm vz90nINQuCaYreGIqtBHV4fDKBFi647FZBkKX3oZDba8FtrKY8EWLNsap2ZkY8shO83eL6XSEMfe Kt2xjbjnBEwtPdi6MjW/Bs10+25WK4XnjXsgPVtW4xik1jI0Erow/0djft91W5X/fKN1wiEuxPkP WM8BX060q55lHPXiRKzcaKubXpn9AE5C9YLh2GiP543yyam5oTuHEao/HElMujq3VLprbdVGUXEX bDlNGXmpDCYr8+pFZqk+r5omLRtfVoG/XCtFuc5AAIjyVXGUi12nZVUVqtzAZCqtbqtY3RI/Sbms 5WeDFaP2LGWSPdXWxklzWOlYtzHHWy/DlqNI2PxE0rx8kskeRhZ8x1elo1EqTqTpzNNuJCyXfOt9 mtV1COldp+Uia+cIuKXHVpO9jYail2jDS2tRUm51dD4jJpF06XMFFWf8Z0ygfNE0vHdVV2lZlpUS g4/bw0k1JGWKTz6iiEFZhVkpYub8u0KthCLv4Q5ifyUfed1v3PlrZv7FbfNvTPUsizLQYAVlJd0P lZQZYn8BediDstKMprGMiJ9x9EBkGp+/zNHDNVREkKzlzIzMwly0EfracIokpsrwvtkJgZFxCatc CD3KJKcFB0bJadByI81HWWRupboYoCkIz2UtE/yymoyrIcyubTFWK2qA6AhmGC2nfmB0p7TF1ROR XrbZ6PD2+ABXUgY0iSoyol9t6J5JJKWGV1WWr0okVBGVeV4re/yD31sp7wmhRO+JL9zT90F73fw7 +qY9njfv8exKOi1WzzG6kg4gfaJSU0IpibffSoH0UQc/ixm/iV5NzdB9L0OdmNDq6FrbIW5meTos gvPKmD0mAw+6YTzKXna+hfruIRp55ucikrxC/Swk75KfXZEWtmBKKNFM2xRMxOiqhPpwuxA3PPL1 ejApS8MHbcV6ep/s73H6lpDIw2IPiyHTbfUnLDa65ZyP7qOubjGQ80oLKzATNKg8Uwfg41kK42P/ 7QPVL+YLFUlCl6gJB6Z8GOCpZCVZYk90fKLl5dlyekbeHy0/yyVWiUmWVfUlK+gM3h2p+cesVGxn 1M85XQ9CotZcK1h1VR0mKb4X5g0WbVsS4Z8nvDxiAfBO/Vxg6AMkwmjFtkJtOw0MmxGxzFJN8AS4 86MY32hvd/yA4is8j+a3x8900YdnYDSq56IqrlvQ+avJ82GAL5MY9AjDUuOsTOJ+5p2ou6E+NdeQ dyF3zMWacRNVN2gbNuu3OrDUV37mSb3liqj3LzNZWXhTEikq6kiKcGgGYb5iMceO8W7D6wb342tX vgOCyuR9wDcKdT+YCdhMmUADLsiq5aKsXEOdBC0HHUbE1PyOCjaHmdWjDPUqsY6tMHqoCXuIFVt8 DUM77/Qd3S7IPOns8TNpvHsF0MJxnn8qLn3Ycd9InTIwp8dxEjtO/eiSTfugf3eQNiGFf2WvO8ng TmOo0qNSGl+JVNfqwFwH9iJ/sgsHJDFWhKlTP7lg2YPGHTsseYgrMKfqdtLrVFK1H1RPMOq7nJfU O97miZG8kiio4vm1O8S9bYa9T2mOxKyt8lfGLNG8wrpKcWHHZQPnI8fchYLolgkZcwsct0o2V7Mi S8AK2Es531PhdJIjUJgI+EMUcLUKGH6com6LAajvl/gfiOeoXAvIBfNRwT3XMQ1TQ3F23I15Sp60 MHmtUD3ZmpniXuotkt5gDVWlTGnOfacPvnB5/YrIdQy9ZeVSosuFkvUPmp5n+kxRfO2ZQpEv10/M 5CxIFYkp4tEZguAwQ1251a7RZD9najaqE+U7kT2go4LwThw0a5BUKgqCAWR9RoSZfjMDoozpfqN2 BC29jG9FC1g35lsMzGV2FYycTydVRScWP1d3ZCUzcSEs/jJjEedSnnTW1nmoMukeVygv7vlih+UK RQI6G60Bqku1CH43Ego5UIb6d5OCQ0ZExawoQN9J51rqEt3GQO8P/nTQO0iFQi9Zli64zzmlorCM KhlGecksF6W0oNFiBvqfuI5hlkLG/KmS1QuYZL1tXh2ijoqLPC8Ulg4RiiLezAVwApDshkOAKIBB NVljWhU6gYAwvAwQMQM9Ean2BGgEUzqIskt/zLXE7XYHLV3NLWTuAwaKoQqpx+Yi5VoFJ5fcRuU8 +Sgrzj3pQj1YVM2vU6U4ksHXN17fOp+Ko+TbrKGr3sJwLgQbufgcZZXKtGv9MTvM3+s8YX6DaotT P9dV11LbfVmpus5oepUePbI8SFHkUWetmg66AU9KydLGVaaNk3SYnJ0rRjSiAHOhvReZR9UbTKKI OEua1xPEKfJfxGPRpI1vGnJjTpVCVdtAPGd8Wx5ZkN7iwIG/xa/xht/G7ztkbRn7fGMOJLwiYUKg bmbxoPjd7VmWwAeowo/njy+YeI/vm8+UdAtgLvUO+K5klwVL9wpH4UPxm4hB/Cd788aXALdwxSsB N6N4dCVzSgki4JkPwMcQoYjV/wR84d8cAJoGeAl3HAClAnPmGPIo3AXoNvcjpIpi5KNvrKQVXKVS LgGY9wtFBNLjOYd6XdIukPssV4skweCgmLyESec5yunLqp28rEuucE2Z+sKV4om3SpIik1roQK/1 gwOVribkDFQoiA3ajiwNqSuytHarfwshjO9E5w3Htz0uIpgWRiuYrxf82wcqthQF/yNljKXS/4s0 OurzM81f4IVZ84sr8ZSGM5spVrxvmXtIRMTYmLAv8DSODyGEE55IrFwjV6JrjKwxfiK98+R+j8QW AlUE5mNYP4QglBlE4U9kuSOamIKd8viX0ydxQlOx16B012nom56p0jPeK8V9RPTKl/1XF2nt80oh AkyqTEKlaT6EijZD3UkMrhTSN1a9nYSGqWQ4lRqXSIGrpaqdSm05NphuNELmzgSEQpbBkJ9h+F60 30pjCCo8bOBvC+vAVctE17Nj5EfbTbtei84rId2q8dDqsHDRoPNZzdc1bD/LH4WmVJ8VrywgXZWn RdnkWsXMhXBQsHAeS708MM5VxKzipL5xyqcLHIEqyE+FGafZfp9EoRSr37DVhRivCt/J/400kkgK SSTnWsSQhQoN2q51z36rA0ttzcw2KMq4w2HjtSAs5Gb4PYFpHsYdsOFFnM6aV1aGzjVpbevaik+/ vmV8vfknnskxVHv59DOvQLkUyJrh3F6xdY+VPCiAvb8DYEvFJumAV0222dPtCTemJ7k/aB7gDVpg lbxlz84KmzBY74ljRUkoRf8ePJ4F2PvgMmLxM87K9b27+tUs2xHVKnJ2HNzF108VghQGyNlMt+Ty EuNmYFRFnfDfFf7IEyVdpMhSqUP1GxhckywBBRIknOgpmS0HDtNGsgaw3DahCuk4OMnTiIgEHIID G5IS3TGx2kAwVz1zRQWZPPDE9GIU5bl7TRVni8oZVxCBtFWtj/PvuIhHqdH4zr5L5Rb41tXMcRTE G9Qbk/iSSzd/zJn4rY7nB63WEAYWHJyudjMLsUFRWctgOyGBEjFfj8KunaG6CDE5DeqpHL/l/Bws aq0siqr6FScefcRQT2KKG5SXqWYTuKIt8Kab5D9SlQ7SdJxgcsE9lBCQWVN2LcHTmendUhXGjP5I m7kLCmp80dlJQz5Om6hzKYMML2tVQmxQxzicvumgeGItJrQiEZTMw26YpFh3bMMjJTbqrlSoJ55R TfoIyrXaFvbcgwXzhuaTaCu0exFDssZfxGtxfEbZssn9KXKM4GCGHYVXQQCThMmDtgwckprn98CZ MTcj+Qe5dntANTUm+idGS48cgOP+2Z+oXgXEEv1jejd92ESh5SHMBOt08w5oYcQwDgSfmCDyoGpD 2x6bRRpYo1FNwbaf4dhy3Uhb6TMVQGH1BeQ2u+x+olKVsU2R2uq/jFfJjuNGD36VOtpAWrBUWo/J ZAbIoZEG5p+Zs1rehPaWttyd5CnyyD/5kSxJXtpzsFwLi2SxuHysUvX7jgXCC1LxzQd2RyoaD3jn d6DEPZef4f4Rt+DAEDIxMvIh5kccc89K3ujyfsq32OpsIaJdI0QbIzrCvEEW4zHE128nWegAwEXJ se4xp3OqRSBbQJgpvtzbyMTXcnqny42dEgPsl9yu4JIEM2K+3MOlzxtI5d7yQ6OX5BlpXg1KFQGx RrCkOFqmjQ81EwQedyvyQz/rQdslLbc7WqKAPrFvmNa1um6YT0Fkp8utnbN/F+At+O+BHjuAucDc aPcyfXfGLWjl5NzubL7E131S5V7DJVoEKQu6nU+41H9s3LyKPDW1fmDcRAyW9DBQjItgshikO+eT UQyT97SWD5AQbXczjnQJcRdq+iCgDSRewENjIWeNfK6cuHY8285sIFGnIQWFZLSSkwf87c9hbYDU ON0nv2x2nj/YxKnYmix51dQJhWNW5TTKKKnNkpn68Z/cHh6mgARU/nePPHziD0yznaJvRFuZ+8nr fppyFCVcjp65A1ww1t41/F1vGXPWPHx94T2H5T0PKZdjD9xotDty++lATI4NXOy5kibs4AJGOIT5 7BK81ji34vEae5fuVqgJYl/cR+vid5SFqGOikgZjHJFXCrG11wcr5AUKdZNCA7SAF/REMjvpDC5E kLMTJynE64rJy3hfqkHBlR1zEwGH8xplNDVX5GEzltupAD0SlltdH1NLDzuYDxmPhbbG2Tg1lI39 pN5cYLcyD7jhXhL1KfVJlRYuMWQKtB3lYhNGj6RhTpYsozyQQLfcKF293ZP/RECZ2F+BmrIZ9tej s4spVYecAVHZSyGLpzP6bzcbzQG8WU957YCxfPWwyXFL0W6gOuv1F2hP106oSgwxWW7kfhUFSA9c RfVZK7neXrULYi+dXeM9S4p7NucsQi1pLkbX5EM8v7BLpvq8ZEKUo1TfP5WKQWQFbiWemmrruTYa d1gg//fHliDf2wtgbVub0EaYLtyq5t6JhgcDxWI7bHeq0rvYZqFT3Q0XGKgBrcan9leMpo3YLIvv QayY8kCcW2uB6C0RAVaPSlGn5DYK05P+b/jBpURhjgdOrJz3c3bZZGJUe8zeZc9Id7oppO5stzNF hm9SqjFaO4vI6eUo4C3tSgtcyYl4BrzJRDFBGS4qzl6Ks1uZ7C+OvjeZ/KdpEeJ3euSk/1s98ww5 ajnjy/AQ1zjPKwYfbj9WnKQ0mgG/laGkcfvppiWCSVoqRKXkh0m75YuQRyczQwg0JZxExJvWtM/p flwFtziy4vErsay7llOP8G/CaUwx2vD7imQwf1XxtIUdwjAlkgJ7BMtyTNothLbErxVdsMZdW8o9 23nNV9w6s1oXVzdrHayUlISK48xrHmgIavNT8i1i5J8kBf7mHCewqWRXY4dmtfUuRkRvFpNGf4qF +dS0ksodOOXsVojLMf9X1wkOeIBfKIb4RRj+Ttd/mhaTh6+wr6+GJwEAS8EjBK+Pt0nA8vWWRyVp ch8giNGKIvKVH1YsqULkHQmXe/pQTisGDyxOth56HR5avA4FeLLEc74DE7Wd+pwHIJQSIw4k4twG EzjbC4+OfENhBEfp6oHXQoq4riJSL+BRT3QDzdjXzmwUp8XHwZbkFLIFj7T5lOI5NA1X2ivXQCCJ 5yOo6pdpObTbd/5+wvvT4BsbRzYGt1Ob9YEFTm58ytVLxrJQoJVzbfcPAOeBo2vATmL5wgxWJqr4 jjGyNPJZPFP8OIdPI3yW4uq9Y+7g9O7TEwn7ptnBS3dLJCdJBX+dQCtfdu9oykHxP0QQmB/Vc3xi wWkRSgksRDDCaj8MWUHT7A9veIdAcGIxwnAQububoZPnd0ySUpuSVPnIPYJjut72Jxa5fZbWI/Hm JRYfcQgk8SB6V5DV8z4EcBPxkQa5dy97V8Kgk4w81sfgjARGvQkrP6WhdJ/JJTjrAXEyy0Oiie9k Guo8/KyIMzHc9090Q0IxT9+mADUMH2JFvIwMHRvg+2N0BeSw7Ji08B/nOO4IU3qnJCa0X2ZFLIK/ IpsBPZD9KgEOk0XzRmOH0j/ZzUl6PvmMyd/NtBKkMKl3K6rsfiZgcQhLGCgSWS3MarS40uhOFhvX AQhMBCROjkuiXMjSxe2szY39vcicEdDI06SQWz2TYhXbLuWS8QBsk2r5QaV7xfwFX0QEIkQO4CJ/ wI0e4QK/0QU92teHSk+CPyMnzyiOYsvNsa4Z4UFSwphcuMsZ9zIQOO/V2C+VKU4cIV4WWnzlwIqJ 7FKSAi79IhPT+TLNPrZdXOVRkSal1xgW7GgPFGWCHTNA/cyAbsatDJYP7KEZK0zoLgPCpLosML8W IJgB72YTY7gCelgTJ0qodqRW0rnwO0ZoQUgOOqj+MBc3Xu6Ufi30t5ixXNeEu9DjGjom2mbRKuGb XE5n97DpxwHObhuXWZQkM691c9sXPnxqCh3KeZLMkP4k2yDZbF3byc4Gx5B8Ok1mr4J3kBqBJesB hGVYqvmQ6n1YZJ4fKaDZ0qT25VaA8Lq7gKPiYpb3iuw+voJRCh/lVVlp/ZQ30TYw10YnR/uTajeS o4VI4T+pdhAMEXZOh5y/Isn/oVfM8ezWowb+zRtWpbXNtb/qBS0Cea2KHIXAfaakJ9LWwokI4lSS M05wHsSCEzW2xuFloQePoqaTXEgjSoPq/0F5OzQXIccrBk80HVa+vN8GwOJ5EqXULA0b2wQxYu1m IvJQOElVUkPyfbCf9m+ESDVYEgQLd55bnQs/Za5/te6txARh3WE9RTYpg4g9ZsbPPWMqi50urpXU KSNTZi7GDwIkbxDdj4VrwhXqbqSrK8H7Si1Xl07Tn3TpjNhVRRXwMadlihx+W35Z1Bt0lxx5TiZH II9jTY3PVsEJA6DhJgAB4ECPUSgIT1OAYKZ7ljhnWP+AAsYvivDl6vP9ESeX0p2KQiUb1uYdmKz7 E1+Zl0iZ6wHUoYIqaEFPDsIrHWl2u7zAQGR/X+SZxnwNcAyBc2j4mRn/LU3pYHOFsvYL8HDoT1Ei jz12BaIFlt056RLdF6osGK7OW1iwKZXZmRJfAsC+fqwSYP5j2H3S8Aps9lYoituNFcxCPlpmmaKw R840Hhg1kizd/9XksJ6SInkvU5T0dbrV/ruQZUewOGUySeU00D+j3IJJLdQbTDYijLFNZOhNltaI WGlymcfziGXXbXRjN6Zr5PSLnqKH2LTjGwmCl6WdkTFOuCH4aGZJi4G4uey206pns5rGBbidp8y0 sgfJq48fhEV5n2snA8BQRhWXz3iGYOCZIoaEhoSQqZ+zmZGTIpQ05KZb3eOUw6WWkmplf7XuIT16 GlCoMr89viYOIIfJ9oNNZ3xr8DXJhIv8cPenpOq6q8MFuSwWdNBI7YJdG65IGZZIKrnkzc4xvgeV uCNJKkq08SyNyjhOtEj9YKRiTVuAMdd7uUtYw/OF5AkGMP9KH9oOgY6gnU3dN3nhFEVD2sfCSNyI 36BtnQOLiRvXFxYZASW6Yn63rORV4hNXUa2iuqJlRUDQSeHGErOlQouAW9xhz6+ZK1jaBBQj0KOd jlFN364xk+CwXvANAJmgLJVn8KTpdHCGybp1rcOOPI8EzBdhLgcUh9kJk9YGHGiq9WoJMtKWkTXj BmjW30pUQ/uYR+cFalDOBwj1Jm7PyzjxroyjIi+8N8BEj34Q76gEduO9OQQoAH7n7Sf+PJDzfOVB M/IbIj9t4Dio4SvK0upJN+jg8a+9/wKA77i4owtoG3jbjnHG5p9pxu+6PfDOoH94m6JwW2DAnMa6 t9D/BRgAEWogNw1lbmRzdHJlYW0NZW5kb2JqDTY0IDAgb2JqDTw8IC9GaWx0ZXIgL0ZsYXRlRGVj b2RlIC9MZW5ndGggODANPj4Nc3RyZWFtCnicUwjkKuQqVLAwUABBIyAyN1AwMVBIzlXQj8g0UnDJ VwjkcgrhAnIMjRQsFELSuAzBSg0VjA2AKk0VQnK5NIxMTDRDsrhcQ7gCuQDDnRD4DWVuZHN0cmVh bQ1lbmRvYmoNNjUgMCBvYmoNPDwgL0hlaWdodCA5MyAvQml0c1BlckNvbXBvbmVudCA4IC9TdWJ0 eXBlIC9JbWFnZSAvTGVuZ3RoIDQwIC9XaWR0aCAxNDkgL1R5cGUgL1hPYmplY3QgL0ZpbHRlciAv RmxhdGVEZWNvZGUgL0NvbG9yU3BhY2UgMTIyIDAgUg0+Pg1zdHJlYW0KaN7swQENAAAAwqD3T20O N6AAAAAAAAAAAAAAAAAAuDQBBgA2IQABCg1lbmRzdHJlYW0NZW5kb2JqDTY2IDAgb2JqDTw8IC9G b250RmlsZTMgNTEgMCBSIC9DaGFyU2V0ICgvc3BhY2UvUy9jL2gvby9sL2YvQy9tL3AvdS90L2Uv ci9pL24vY29tbWEvQi9qL2cvSy95L0wvYS9iL04vdy9rL1QvSC9VL3Yvcy96L2F0L3BlcmlvZC9k L29uZS9uaW5lL2VpZ2h0L3NpeC9WL2h5cGhlbi9jb2xvbi9HL08vUC9wYXJlbmxlZnQvcGFyZW5y aWdodC9zZW1pY29sb24vTS9BL0QvVy9xdW90ZXJpZ2h0L3EvRi9JL1gveC90aHJlZS9FL3plcm8v dHdvL3NldmVuL3NsYXNoL2ZpdmUpIC9DYXBIZWlnaHQgNjYyIC9Bc2NlbnQgNjk5IC9GbGFncyA3 MCAvSXRhbGljQW5nbGUgLTE1IC9EZXNjZW50IC0yMTUgL1hIZWlnaHQgNDQxIC9Gb250TmFtZSAv Qk5MSUVHK1RpbWVzTmV3Um9tYW5QUy1JdGFsaWNNVCAvRm9udEJCb3gNWyAtNDk4IC0zMDcgMTEy MCAxMDIzDV0gL1R5cGUgL0ZvbnREZXNjcmlwdG9yIC9TdGVtViAwDT4+DWVuZG9iag02NyAwIG9i ag08PCAvTGFzdENoYXIgMTQ0IC9TdWJ0eXBlIC9UeXBlMSAvRm9udERlc2NyaXB0b3IgMiAwIFIg L0Jhc2VGb250IC9CTkxJQ0YrQXJpYWxNVCAvRW5jb2RpbmcgMTI1IDAgUiAvV2lkdGhzDVsgMjc4 IDc1MCA3NTAgNzUwIDc1MCA3NTAgNzUwIDc1MCA3NTAgNzUwIDc1MCA3NTAgNzUwIDMzMyAyNzgg NzUwIDc1MCA1NTYgNTU2IDU1NiA1NTYgNTU2IDU1NiA1NTYgNTU2IDU1NiA3NTAgNzUwIDc1MCA3 NTAgNzUwIDc1MCA3NTAgNjY3IDY2NyA3MjIgNzIyIDY2NyA2MTEgNzUwIDc1MCAyNzggNzUwIDc1 MCA1NTYgODMzIDc1MCA3NzggNjY3IDc1MCA3MjIgNjY3IDYxMSA3MjIgNjY3IDc1MCA3NTAgNzUw IDc1MCA3NTAgNzUwIDc1MCA3NTAgNzUwIDc1MCA1NTYgNTU2IDUwMCA1NTYgNTU2IDI3OCA1NTYg NTU2IDIyMiA3NTAgNTAwIDIyMiA4MzMgNTU2IDU1NiA1NTYgNTU2IDMzMyA1MDAgMjc4IDU1NiA1 MDAgNzIyIDUwMCA1MDAgNTAwIDc1MCA3NTAgNzUwIDc1MCA3NTAgNzUwIDc1MCA3NTAgNzUwIDc1 MCA3NTAgNzUwIDc1MCA3NTAgNzUwIDc1MCA3NTAgNzUwIDc1MCA3NTAgNzUwIDIyMg1dIC9GaXJz dENoYXIgMzIgL1R5cGUgL0ZvbnQgL1RvVW5pY29kZSAxMTkgMCBSDT4+DWVuZG9iag02OCAwIG9i ag08PCAvSGVpZ2h0IDk5IC9CaXRzUGVyQ29tcG9uZW50IDggL0xlbmd0aCA0NjEgL1dpZHRoIDc2 IC9Db2xvclNwYWNlIDMyIDAgUiAvRmlsdGVyIC9GbGF0ZURlY29kZQ0+Pg1zdHJlYW0KSInsV0kO AyEM4/8fzHcqdcoSEmdhoFLVyQWGgmObtURPPPFjUVg4P4891e77eVEvLV68YSlVjhfKBb067JcT cB4VXh5Ny/mTGj0JzsyEoXZLmE1yeSF66bTOQJxpLRmVDtlqtN/QLC/oKe/qLSAdpo5L8xIbp9t2 T/OdwOtB+uVt/S5Jcw7l7atm0dpFjXZXuHzUn9QrRUVoxRmNNNlfPwAvEwv4gPuKEcAEL/+GMGkl eSEjJNZ8pMg3k3kCf2fdGxqNXqrA6/Pk+eW+pRIaA8mKeFgWfQ9tv0p7Oom1XWMMy+BFkNewGay0 OdIxIb7GON7UrumfAWHWBcmlFi0fz5CZxxGhgg971sCSl/ERjb1hzPphyY4cVuNYlyl1uvg5ZWlU 5lHyeiuf/Yo82k/4xUdH5lHh1fziRIn7GMSSvPj6ymvkDVGNlPQ+pVH3S8kb1Tjybnx0jfzSXfEr wsv1a2s0YV19//eg90S0gFEab6xOYLV2+AbY6oZQQUN1WnCLGics3CHi12kTxlxKxhWNwbfJUaGC CmOn89LFfPFd6PW864aFlSF2FZ9KqfVivVdR4usSqwT62hSzFFHZDmh9eIbXE0/8U7wGAB5o55sN ZW5kc3RyZWFtDWVuZG9iag02OSAwIG9iag08PCAvRmlsdGVyIC9GbGF0ZURlY29kZSAvTGVuZ3Ro IDEwDT4+DXN0cmVhbQp4nCvkAgAA7gB8DWVuZHN0cmVhbQ1lbmRvYmoNNzAgMCBvYmoNPDwgL0hl aWdodCAxMTggL0JpdHNQZXJDb21wb25lbnQgOCAvU3VidHlwZSAvSW1hZ2UgL0xlbmd0aCA0NiAv V2lkdGggMTczIC9UeXBlIC9YT2JqZWN0IC9GaWx0ZXIgL0ZsYXRlRGVjb2RlIC9Db2xvclNwYWNl IDUgMCBSDT4+DXN0cmVhbQpo3uzBgQAAAADDoPlT3+AEVQEAAAAAAAAAAAAAAAAAAAAAAAAA3wQY AE++AAEKDWVuZHN0cmVhbQ1lbmRvYmoNNzEgMCBvYmoNPDwgL1N1YnR5cGUgL1R5cGUxQyAvRmls dGVyIC9GbGF0ZURlY29kZSAvTGVuZ3RoIDc2MDINPj4Nc3RyZWFtCmjelHl5dBxnla8c6K5vQiIg Mx3kqlDl5DGcMJAHHJZkGEggECdOHDuxnXi3Y8taWlKrtfRaXb3V1t2Kuru6qnqrrl7V6ta+WnJs S3FsiJ3FySSPDNsMhMcjjwkMD+bMg2pTGs77WglbBs6D4/9k1Xfv/X33/n6/+2lLy7uva9myZQt+ 766dO+574KP7zJaO4V0dzj1Wy4n+R/beca+179TD+5q/cWsDu8HUuOWGmzcu6VduQV75VcqgXf9e 7SPv0+55v3zLh267qeW6LVtaP/Tx7Xv3uQc6tn1i26mOzj9xWssW+K+ldUvL+69vuc3Y8nctLR9r bbm3peUrN7bsRVpAy5brt7XcseUT13/JuKPlodYTLe03DiFiS8vdMNOWrS23wA9ObLlhS8eWb183 ct3su+541z+96z/f/U2Dz/Bj41HkU8hV0P9XN/1V9Xrb9d95T/4G7IaXb7znxvXWR1v/9b2Z97ne 98/vF25Cbrrw1/LffMRkMpVufvjmqx842Ta69b9vzaOH0V9in7zlzlte/eBRHOB54gRxbtvd29Rb P33rz25L36ZpyLW/vvmaYSP0nwYk1/iFqdG18cZGl7F145Ot+ve057UZk774YW2x+YN/1G4yeTyM y4baJVfOg3tyBaaMVQpSLkfkclKhjFaYgieH5zwuyYbZXYzHQ7Q27m3UTdSZobmeGhjv6cqcwjq7 fANmwjw4dIo8BJy7gju+jD4uHsgexFOdaYtiL1gqtnESeMbrzDRWHxczY8RYppQvlPMVZSI1Bwpf k59/Cf164GX7c7j+no07TJEOxupzgwDt5z0Y5Y9LNEFLrMJXADsdfuFNVPti9GfxCVyYkIrpFJCk VDyL5TN8QCbSHskSOwZGnaMP6ABt1V64dpdJD+vvkklDcqyYULGkHOYlQuISXIwBMWbU1Yfq/4ac iAyEAjjvZ2g/B1i/M2zF3KT27yplHHLFxQDhF1k5lAbhVGT8NNpYQlob+7W9JrcxYKcpluVYmg+E QThoG+nG9P9m1K7TWr7++swVMPZU+swqOsZUqRruqdtLAzmgWPukHuzIScrSRXRZBo6SO/Nc23pt qfo0NjkesJWIki1lNaNHfIeHDuFDh+79qH6DfhsINFCkVVvURNNUZ+7kMbSfHiZduIt0BIcxa39m vJforboVPgqEYDAawLx+PhAgAkHeR6EO2VPw4a7xZfqr2Osvj51fJ9bXqs++gp4OzjrruLPWX+nM T6jlYqYCshWxUkUXqBlLHa9bOrNHsWMnvQOdRJe1r922D+Z5fnpp7Cw2UQ26CkTRlRweQF28K+DC g06/l6K99GCwMwBI5Ir37OBUB2itarebNEa/XUO125/7+a7GPY8Y9Zc37jFojJYz6Tn9MaR1Rvuu KZ95UsZ+8HV317PE17omjj6KWmmby4m7XLbgAOb3R+NBwiuQSWemt2zP+gQg+Hwx329qDPB+L+pO kkUv7pxYCV7Enj6bLK0QK6WZycoSqCyllk+jLw49c3AV333h03X93fHqS21a1rim3WTQXzC2aqHG r007Og4c6H4IdD3k3v4l9EDySOEJvPhErXfWBuxzC4HT2OJcsjhDzBSr9fw8yC/Iy2fQ58m1nnl8 vudk/iDmsIdZB0GH/RwVTK/nYOjibH1ivjI/dq5wWQFZ5DMj97ge7ABhfdQ0VgjYs0S5O/XwJ9HH uG6/GycDXprCKF8iHSQo1T9JrwB6JXTmKbQ0OhN7Ck+VVCGDtWqi16QNX/t7wwZhPKyfMBSM6Vou n0+CbO20+AymfdCoP7DxlKG1cXfjQVNhTK5PoSvkvHkCnzQfUnZiD+4nzR1EZ4/r1HHULPYrg7gy NNtz4dRhu3nIMQAcg8HebvRI/tR8D947v+55CXvlYn7hNLG8UDz7DLpIz7oncPdkz/SR2aXCRCk/ BnTbeRM5To+NoRWpqCh4TilIZWysQJNZIm+Xe06gw2E758Q5J+32kwdnzJNkFWgf2EBMFmbYA4sm nbQN83gFmSK8sl9hS4Aphsan0LFYRSjjQjmRE9NxUZST8vcfXd098hBo1fJrpquL6xdmXgAzL6ov v4peDJ5zrOLOFeu0uQzK5s7UKazLHHSaiR7noNXdBdxddPtxdKd6aKYL75pZca9jOSUazxLZuCqW kvRR6qS9y95tgczfOXzU9ZgfeJE3Yt8uvbQEQlrINOxKlb2EYzbwwhvoxcRCpoBn5YyYwzLJECsR ii/tkKwgc0Dc+whqHekNd+EBB8n7sSbDXtfYY/JQjNMOSdWZo3CPUoSkWi5KOYXIKVKxjJaZogeC RjklO2Z3Mh6KGNFf+8uJ+HJj/y9Msl3wj4ZBlBvlODQYYlgeZ4Pu0CDmI7XXVKMz6kkEklTGPWO7 oDON5TbaqAc3qvYDLrPHs5XyuILDIUBqAypijtnjtAAomc3mUSWel0v4xFWDRhn1vnnTv2uOn+oO Q2u88WLj46ZKNT0xhU7RdXcNd9WGin1ZkOl9TPwipv8P0jhZCvMpIsVJbDwIBDpq60I3vox0RWw8 jYdohgnwgAs4whaM1H6IvPn14tIasTxTPL2OnnMvdU7ig8Xj+Z3KZeV0oVIF+kWt13R+LhQsEeWg 6k25QNqVGO5H+7lhvwv3u0jKHgQBu5k/gmmGx03jwQKZGQaZocRAHzrADQXsuN/hIe1++Ds2bhAj fXEZSokcyqpoFdG6kfVFPliFQF675drnTBF4gQwLGIYOBTHGlUhbiOL+Q8mj2M7dnr69xN6+Y8d7 9oCePZ7dO9Hdyt7Jx/GJx1dPXrSC/ksveF/FLp6T1WViOb9UX1gCX0M6jnX2mV3A3d1Bn8AOnkhX +yBHDy9Qa4BaYy9eRp9LXiqt4bnF6tTsGBibW0ivYGtnPL1LxFJv7Uh2NyhopLH1svb8zatT0XiR eEpaTE/lppR6qVIdGy9OK8tAWRJXz6EvU1f6LuKWZ44tP1IDpcMPpT6P6Wtk2ZhXwmzzGkQ2ToMY HXWY0Y0diHnEEWZxPsAwQQ5wQSrswuyksWFoaKYZb32g1A5qBzL3fxa9zfmFUwfxzv6Trn2YxxcV aIKLh+JhEYQTI7k62sgil5b4YIVojWtvXjOY1mfDXJ6YCo5RqkN1ZM3yYZj/gY2nYR4llaczTcGl 4wEwyo66LM08eiKOMAPz4Biah4L7Vh6NV4yTWqfBbfQ8OnC8A+Laecj7MNZudHljAkMwAieGJRCW IuUFVNuFTI+FmByh0oonPZwZlvriHTDmz1xG/oD/lGsADLr6fCcwn1Yxtu7XfghzfGY+wheJObpG FewFR6pHOAaK2p6NS38Sqz+ao/ZT1W50UzFoCoIJRgzLICRHSrOodryAzE0FnTWi7lRPJnYCVfs+ aQx1M/0+p8/hodw0oF3DoX7MpY1D2UGufQZ2HOtimx3HsnSYxjjYcVDH0zaJgjo+aIn1Yts+Zd5+ H3Hf9u47b0f3pg5WjuH57mrftHXKumA/TQJy5QL9ArZ2TpDPEmeTZ7IrBaB9EKmOKrEEnkhD8hRk QY1Vo0DVv0GqSC4T5tJEioVVQuvDRskBVP8g4uZI3hMCYZKMUNjR9lSlhzCXh+eo84A6z156Eb0g Pp1Zx7PrY4vTdVCfWcmuYRfOe3rOEKs9M4fKzTq9xla9pv1ENf0RWBo7kJloKSbhQkqUJAGIaSVW wMqq/tO/GPYmao1fNp43nV+arGQSWTEfrzRLS5FIfSQfEUMgy4pBH0qSdrMV10f0wwatHZkdLcXf jh6H0dVYBVP175IlpACDJzdpKkaD+O8FDzF4KMAyzFvBnZiD1H6gGofcsQS0G7C2ULO2kdIcqu1A xorax/Q9hskOZcCHMmEOki/He8P2CKTUf1MRl1tIkcRw1lrvWdG92lNtkD81jTJR+z2nyAFywOGy +YHP1s91Y/uMva7RGEP4BXYzQnITvX/4PfRkiF4qB9GbUPVf/GXoNV43VjXK0KrNaqvXPmrSK2Tp t59LDDTCb9d/J2IZIcNoyMP7WYajg6yfB7zPCxuDIzWnauyzC0kvQaXoTEgFEfHJ4gza6ES01MZP DCmjJjV+btjw/zaDP4Twp6rD6Nrsj0Bis8Lwn+yPIlZS9ZJR37Gxw9B6OQsTJpHiiBJO8Sku7c+6 s2TbhhnpZgcpL055h5hOqCQB1YPYnWLGTZBZenyxiVxj78a6QW2sGadjZSGDCxlJTibkRCFej8Ou sZLIwuh4MOcCKW9ioB3VFxH9O42PQ4wQDW980/TAjp6//wj6qfEvPv0Q/rmr/9quvQfT3vOjle9f JdZerL72Ovp/ev5lx0v4jqufmbot9JH4XX0PPAi0N2dNVXfJkjsO1CekHZ9Gv8Q84jmKe47ae/od wGOzMmbsYEdh0Uq0X3R+TzOgP868Nr6OPz91buoKNjNJu6ES7W/cq101nUstlGqToDaVWVhFn3as nJzFZ0/cr34M01f+TH11hvsgKm+oiMURE97u2yTg5UhlHtV2It+4GJemCH2b9pJpdTpgKze3jq6D 6KFAp8OGD9v7/KcwjnlyNEBoy0iTrO7QWkwXXhj/xv+EdX8X1v3Sjjtn/hb70J09O3YQDzzYc9ft 6GerXzq/C197+OqpfybH9swfP28B/ecuUVewpTOJzBoxiYQp34gPO9yeKkMhLNlmqNXX0s8vXngR 6Lc0dpuqhzN334rqLc7PtT+Gd1o7XAexQ6c2obrkfF0zom9mXqtdwJ+bfmryMvbcWcvuKSja2gva JZNm1i8ZtI680T1KCd4ULXrzjrr+Kc3etpycVspFMDedP72GLvvnbJP48KSl2JkCqc5HEv+A6c/9 AZY03J2idojlfRBL+3/F8kd/gKUM+GSkDLHcjVzQvmV6ZtE/PEZUhtOdB9Fuzuqz4z6Hm7LTgLGZ Q8cwq7ZibN3WOAwpP+Tk/TycKp6DlM94hJSdsCfdoicOBKcj5sAeOeTqPEWc6nQdexztE63ZQTw7 VByuOcadq4PP9a86Jt2qT/WlvbIXSFSc8qCDAZvdiTsd/cFO7Mjx/MJJ4uSC9aL3VUDqMdWYyEpJ OQFEWY7JWDITZnNEPVBh8jwIFYqREvbSpeLyKrG6XD73VXTVtzQwiw/MPD5/99LeWneBSjkUSgkq gE2FMwpaSZYKKp4vjssz2OoyaV4gFnrGjsn7QNHIa4PQGs43qeX+AiKu5RfqNVAozshnsPMbsvG/ MMI7hLTJCL9TDHkdmSo3laocyHvT7ow7bUmehDJzP7RDlWuoqV6IcCkiyYuMAIk7GB3uQPVvIXvl J9QePN87ObDqANTUGeZrcIdR6svE0kR1OjUHkrPCV7+NagJSixbiKTyhyKm0BOkmF89jWVV3k8Za KcRmm+fSog8kfDGHBdUryH3cQZ8V91tdtiEP8AxamC6sbzCRcRKODJWjC4AuhJauoNq3kMXoWFzG 40lRTCaAIOdj45iq6j+GSTeYTQqrFMI8PD8kcgIDEmyUDqJMJBD24yE/Pezp0j+gn23Tb9W+S83R 5Yi0NSyNiAk0CZcgARdThfgEllT1V0jjeDjPygE5UOio7dQcG9W2nFFzNuK1K8WlbG5roVzKVCG/ wal949qVzbjjI/mQzACZjQd8aHAkGA7ikQDrDFj0Fn2hTb9Re9ngXWIqIipGxbiAxwUhLsZALJmL NqXy6yRSUppDkuSStOSTfOnBbEdte9ttuqjfrH3D4FlmammYpiQmcElUYpVRSK7L8KOI0kzTr/SU 92nWjcU21ag92PiKdtfGVwx5o9beOFM4l6xG41sTaUmWIC8n45nRZt6XG081Fkyzp0tVScqm01Ja APFN06DqIagD2UgoSci8yCVYIDBRhkbd7r6u4/j9d92lvdf8tCEijIgiKm/mk5Ay8Lucqv8LaVQi 6ZAUknmJkQPxUM5WO6l9QY+26W36p08dtvTZqa2k3870N3chUUUc3tEoS1Bxf4KRAAu/k9GsUp1c xH+uvfcn+m2FgZRLCG6NhkZ5DqVDLMvhDOcJDTZl/5sqQkaphC/pk+11y1n9QW2sDRYlbt7FRKTE pxggcXGWRj3eHstBXL9BP6zfoFkNg+d9k2k0EU9ICVwQszBz2Jevkk0DHcwQ6WDZPLVX+4S+2KZv /WMaayYbiNppdHtjYvC3Ggu9MrSmn0a0D2nc3PPjC7ns1nRSTZRimx3yUtrkV4rcONxNhZRK5FNq PjdGpdv8NBR/LBQajYWJcDQcjyTAiDCSKaHafchaZIrP4myJLA7lQWHILB+HWzcXgKYxMEi6HcDl oG02lBS9WT/uy6pcESvkEqk0kU4lsjk0w2V8WZxO8nIClQQRVipnVaGMZdJNM5Zkf2PG7Gb0KPLh ow92WqzAYqX6utFB2aGSOKmW6XHszHp17atEbEh2Kz5w54smrz8uM0QgzUOWyifUTB4vjE9WlypA /xjicrhoEq7lVk37pon1ekIebNghZt3EcME14VsC3iX29Cp6QVpUq7iaykoKlpJCjERAdqGizliP ZE/7gC+T4wpYXkmkoFjAQgrohLdmreBj1s70Eewr+6x72omeI+S+h9GH8vsWjuJH59dsz2Hzs81n o2mYS/k0lWpzOkmvlwGt27Qa7AUHUs5Gmi+RoURTx2PsqLMb1QnEVXIrpARk0hW3Y+a+oLOfsDht /eQpQJ5injiI7srur53A988+NfgsVikKyTyRh7xcqYMvI9pjCwYVcY/64qzACCEpnIQerWlUGxVE /+DGOdOxoQG7FfMFYgnY25lAkakBuh5aeRa9EF8Sq7hUTebTSQAJLJbG5iZsR8cIiFvjusYnTYvm 9sJRbO9h+zEoL8ccu+5BH87ur8M85p4e/EdsaS5ZmiQmS7X56jqZanNbSacnAAIeN+/CegeyNRvR P+c5F34OaHFj+J/cXzUvAv2QfotJRdaTy4UJiHtGUrG0HOZE2OcyJbhAwhnr2o82X1MuNu4wnd/+ LPJ9JB9LJyRIMlJcxqREhBeIeCgKB5Af4Uc4PEKPcGE0KASTNGwwaFCxYk54q/HSsC2CqkvBFZdF bMcePeLpMxPmPrL9CGpDeh46/CIyqr9qGIp44EyFGY6DzjlEe8MOqPplFbGOuBLBNGSBcGEKHdFe hRbR2+gx7Tni6ekiOnvcHcdQc9JSGMSLg1OOM54Oz4CbdADSTjtsaGcJSjbexziCAT8I+DkfhXpE SvHiincsMMsAZnYhdBq7tCblVohaqpJTK0CtSNUaesY93VnClcEj4nbssyMGJxUXm2/goWQKzQqp ZBJPJtNxBRtZKI6MYtWamJkiprLVfH4M5Mfk+gxaCOWZPM5lAllPDvzgon6HMdPTl7BgzzxmUhxi +6Pofs7sc+NuH0m7MDcl532EL8/NrKGXE8uZAl7I5OQCVlAYKkm8uuE15UMZVoYOiYtyNOrwkYN+ 3D/YzR3FHu8SMy7ClQ0qOVSVs4UkNPLl2Az2rXORcJ5o3Tb3lnsPZ6CsggQTs3ejGx1Id9jBszgT 8HKuJmV64KYU8yW4NOClCNwptAiSLWdyGRnI6Uw8jclSmBcJkRcYyA6x4OhwJ6o/gfSEHRwDD/Gz nrcPcUbhIZCv5XAZbmfbkQvhBbaMs2VfwamCnGNY6sfsdj4AtTtgcw0NAi2PtG6Y3rj2IRNFsW4H 6hBJhcIpRWVLWCkvKgqhKKJaQktsnoLNQ7lFB1xlWIoivqIfhmWVRxReCgKRjjt7UL0IM3KyLB4M UJxjBGYUVRE7NKVMEmYUapb1a6TZ0Dc243lZt/MP4hXV38UrwnhZ2CJuEa5ObpbyEtvfihdRoOsB IhP3OtCRQYM+h0R1YGCi9lgXHnWO+jjUHw7yHM5yXJjFaC4mcASfiEhpNPqkMCriwpNCHFVCKVbE RTYY92M+Px8IEsEgXPJQW9JZIHFPYYJZxpan5cIYMZZXq9IUEEqxmTNow4K0bpv5c64z8NZNsBLg 5BC8ie8hE/X/rW81ZJ2il0X5cCgUwkM8Ewlu7m0IOeoVAylGHJx/4kW9Rftk2/r66srEeFbaqkiq UGj6iRPQT4Sz0DkBcVM56TDNB3Eu6KPsjltva4NLJLzH4mZu8E44iW7eiaMX3bD8/+6kcRXq4N0L jaPvLEtPv7Ms/9sNlmz64dI0qo0g6piaVyBjplKxTLNLueZflmCXBkE8MDp4EtUPIgMjZKTJKjzL 8iwXDPtG3kLIAatmmg0fLs00j1KKWUVJgWQ2K2Sx5G8ano4FNo9qbx7VG3ZykNv8Pva3MMd8Aic3 qanZ8LuRtdD82w3vygLFNST2YoNDrG+YGPYNOQb7g3VPyZkBWfgf/digjQ84CHtzEqzgOXi3c38O CJ6mu/EnmkHhlM02M18aGy/WMel3MxpszqgNuvLjzZThJsXClMnfm9HNznh7Rp8Jz/EFnBvzlZw5 oLqG4IwO2biAnXD4bW7bELiMtL7ZuNXUcdi1Zwe6s7B34TB+eOHC8CvYqxfHn1kmZlZzl15En6JP uxdxcnFwwlwEJXNnsh3bcWD4UAeh7Z0wNRUl4QQJR6xjH3pHeCdrwUNOxuMLACboD3kxyptIBwh/ msmHK4CfjEzPoS9Fn44v4LEFqZpOg0w6m8hh2VSYlSGhaUrcFChXuCo2N5Us1omJYmlCWQTKorh6 Fl1ll70LOLXgmBgogZLVkjJj1iGWGibIgIf02MAV/bF3sMaGE2LkYplmh/KbHaqoiI2KxhmCiXOJ 5lYkRXJjqHYPkneqVI4BB7T/ZTpXqo3NYCU16EoThX758c+j9zD7yQHc5ffSbqzXUlyyNqV7fvNG c5FUOBFKhISmt4oxo54BVE8g7aFhNoiztI93Nm9mdNM4xJh4Myp0jtBGpwtoDfm/yKIwl5zGxWIy l0k190govvH4SCRGREckLg1lPqNwKqZkEukkkUoLahkt8rlACk8FqIQbc9gZykbYPQN9liPgP5Dm Q+GzDbOJ8fNsKAIgFYxwGMfGBJpI22yJIexot7cftqvV39uN9qb6SwO44p4eXOuetZVJOQCSfsHn QX28PxjE6WDzr8O24VRpiBgqOaepVUAaJf0ug2pURVlKYTExEk4S3vkJSK/1cTFdISoZtZAZA5lq olpF60yVquBUua9+ZPrwdH8lmGkOEnT6KSEly7gsp+MZrFRiyBIB3W5v8ShQjaz2CUOTww9fM5js 7UPd/b39vd19J/sBeUV/EjkUtcQCuODMuItwVyxWmQns8urU8+MElTL0up0eB8bxUUjJrBCCpAzC 4ohaQ7U5reU85L3PwxHUVv7IDIYR96CH9NGAo+G2iDFMVGAJTuBF6O+aj2iQPq7qu9751Q7k8Vin 6MBFR9ZVpGA2ZWYcq1UTqTJRSpcL5XGwS9v1Tsn8FSTDnM+kfUz7Vf5MdlyWt0IUhGzzlfUjJFIY yYRFtknBTBB10xbyCXy3fvsXtXsM3lmmsrkEShIuJJIxBS5rPIlkw83nxaRfGcg/oX1c/2VzD0rB 403ar7OnU9W3j1eax99CIvmRdCjBgQQXo31wqfIwNvwR/a4Hte0GeozPSagYS8TjuBBPx/JNTfCS iBJOhSRWZCVPcljwtz2ob38A/nawzqkCmogJCQEmk4o2k/GQiMqn4UKapnI9+QNaq/56W9WovVf7 oXaT/kPo6P5D+4WpPFuowB0onU8UmwE+CwNEkuEEDxKhGMeilHdosAt3D3S9zCgheSS2Fc6IIKBC NB6N4YuyQdUFOGwjWTgUmUDBMn74O/qH2zr2de8f6HX7tvpdTs4OBe9+FaGCozGe4KN8PCyAsDCS kFBhVIiJeDQuZXKVmbW25S8Zkk7BS6NsJMRDsQz5IpvsCzdTz6g/TotU1j47cOFz2kfbWjX3HhN5 iOrzeQFNMzyD8aEo3Nsi8YiUQct8LpjEU0GfQGKkl/NBnvNzHhdql905D06pZaaGzdaztTKRK1Qv zHwfXs2P2irPKrPJpJx6+2o+2nx9zUKgQfPF0Y+6gt2ug/jjOvEF7QGDZ4GuplEpLiYSuCikYrkm cnBPV/gMvPiUP9dX3q/drv+orTk1lsZ9pvp89vRZdDE46SzjJedwyorZXIyHJDwk47ajTtGdhY4o q7Jw+03HBJmIxWOjUSwajTQZJzwa4lErM0AO4uSg1dHpAQ7kkroyXl8ArU8+aWyE/wZ6gP8nwAAF YCNbCg1lbmRzdHJlYW0NZW5kb2JqDTcyIDAgb2JqDTw8IC9MYXN0Q2hhciAxNDQgL1N1YnR5cGUg L1R5cGUxIC9Gb250RGVzY3JpcHRvciAyMiAwIFIgL0Jhc2VGb250IC9CTkxJREcrVGltZXNOZXdS b21hblBTTVQgL0VuY29kaW5nIDE3IDAgUiAvV2lkdGhzDVsgNTc4IDc3OCA3NzggNzc4IDc3OCA3 NzggNzc4IDc3OCA3NzggNzc4IDc3OCA3NzggNzc4IDc3OCA3NzggNzc4IDc3OCA3NzggNzc4IDc3 OCA3NzggNzc4IDc3OCA3NzggNzc4IDc3OCA3NzggNzc4IDc3OCA3NzggMjUwIDc3OCA3NzggNzc4 IDc3OCA3NzggNzc4IDc3OCAzMzMgMzMzIDUwMCA1NjQgMjUwIDMzMyAyNTAgMjc4IDUwMCA1MDAg NTAwIDUwMCA1MDAgNTAwIDUwMCA1MDAgNTAwIDUwMCAyNzggMjc4IDc3OCA1NjQgNTY0IDc3OCA3 NzggNzIyIDY2NyA2NjcgNzIyIDYxMSA1NTYgNzIyIDcyMiAzMzMgMzg5IDcyMiA2MTEgODg5IDcy MiA3MjIgNTU2IDcyMiA2NjcgNTU2IDYxMSA3MjIgNzIyIDk0NCA3MjIgNzIyIDYxMSAzMzMgNzc4 IDMzMyA3NzggNTAwIDc3OCA0NDQgNTAwIDQ0NCA1MDAgNDQ0IDMzMyA1MDAgNTAwIDI3OCAyNzgg NTAwIDI3OCA3NzggNTAwIDUwMCA1MDAgNTAwIDMzMyAzODkgMjc4IDUwMCA1MDAgNzIyIDUwMCA1 MDAgNDQ0IDQ4MCAyMDAgNDgwIDc3OCA3NzggNzc4IDc3OCA3NzggMTAwMCA3NzggNTAwIDc3OCA3 NzggNzc4IDc3OCA3NzggNzc4IDc3OCA0NDQgNDQ0IDc3OCAzMzMNXSAvRmlyc3RDaGFyIDIgL1R5 cGUgL0ZvbnQgL1RvVW5pY29kZSAxMiAwIFINPj4NZW5kb2JqDTczIDAgb2JqDTw8IC9GaWx0ZXIg L0ZsYXRlRGVjb2RlIC9MZW5ndGggMTExMTgNPj4Nc3RyZWFtCkiJ5FfLcttGFt3zK3oJTJkw+gGg e5loxp5JZeEpSZ6k4ixoEqIYk5RCUda4aj4inzznPgA+RFEqV7SQY5fYD9x333v79Ou3p95MbwbW lPhvjS0aZ21jyiI2IZjxYlCa6eD7Mwxnq0FZeGfN2d3g9RsH4rOLgS2LMgovz6pgGmsL68zZYvBL ts5tnV3mQxeyUW6rbGlO3uUxO8+9y17l1mXmjqZCMcuHMRvnPmWXhuc39M0w41zWMbvKQWn493Zl cuchWD/R3+2CVtf0eU0zlsPUS/Mh+0iTDzlxQQNMW7KELStbUsb0K15/YXX5r+bsh8E/zjgQRelr igG8rBtz9uOhGNQpFb6q6yBhWPRWTGjWklL2qMiH1mbmXxdskli9awtvLsUtNr8lgpVE4IKtew+/ N2E11+LZciNjwmQa0m1XyI2SXHj9pj58ns7GIpQh7nu0E5IhSJsy4d+hcDiHZCp9RGaUROi8Jsf/ 9sJaVpU5Gw8eEeaL5GJ9L8Qn7873XBs/ZlewRfK2co/Y5Vx63KxQF6khWXtmfShRMfuxAoMIRIVt TuCBinK1K8p0QPQrHHCJ0z+hc4X3BxK1jF1EXVNpzgZ/OGeL0pJhdWyK6CsNxV0eyqLKZvO5+Yjk wpRyF4NBetmqoFrh7bW51o1ZHiKG7vsyjxuuiW4aSWTe+7wjt2MzqvlS120emu3PJOCy1+gChqkI 6nbNCWt+h2LAcC7izOhCqDBYZi23pKqg9Ze8Ih6zHt0I9ycluFEpK13firDl7ucid0x17zCcHgaK gQ/jwTNo6sJb39RyCN+REU61RIm4Q6OAsU7dlZ6C5QpOu87AKGFzmfjhOtYlvAYRaOrsQrb0S8dn 9qTP2DXmQeCvr2Q1n42FjAPWfZ2pso0Moh2xYbolhOs7EaO6Ta+MGaaye6m2xmykpuogVMuehwWv dyxZd35/uqGkdAeORE7EBXf8QOpQNKlvEOvRJ+q0M27NHMWp9O+UrSkl6BT0AxmASFxxZ+a+/1/6 aUE6psmt3D9wQm4Fzvu+3vg86l1FJIilMr0SsPzbG+4BLHc0xsnz8TEhthd8LmSQXkC8pFx9Utuw 8WDjoxC50tamrlC+1kcrIfqnFM4V19edtIT2cyv10pXPKy2U2VoKj6t6pjVnOqe3u4zSKcktS0c+ JBmIhFKSGslsr6GsmbbTqM1MBODK5c3fRPqtDDf6TTSOOmlqqMbVMyEbo8M9tcwwU/658quRV7v9 Y6LEe7w9FS+LPOw3F7pTrB4ZsFvX5+3xA6PrL1mvTeYMuQLkBd2cGsNGT2NrfZdbTimQfcm9pwKn j7LTIqaJsFhHLpxjw4uxEk1uAXsq5D+nQGZO/8AYikTKcLFTJIisnYgcs+DxCpJlh0ODo46d+AcK 2jrf36z3L1Rb1B7lvB+C0VrqSCrNoHmE/ZbB0p94kfqyCLiytWd02I2hrLd89Nkd4T+/q+P1m6BA wIlYx4AS0qNICsRUZmHPMIIQ1T5nnQiKbzHfK/XQdJeS9YLs76nHbUT+bIT8Pa+Lhm7WCsPwdIzW 3nCjbuAhzemYncNktpya75haN6ZXhHgLalyOKNHa8Lu+XBxI6FosC97VR98cNVp8MBXQURm2k7mo OSsBYCUvi5ozs6gleTCOzalscD2GrGfLYUHNbuCsiGGpX6YsDtCL2Im7xvhH18+4ZBYqfCRCeta5 7n+hcg7UUtQIoRtfseiO+1rHOcvemKwekKVxYyk3H8hcbzxgh+539qYrEHnIHc9jl2pTARBWNlZa JALhvFz5jbYueoRBX5MtpP2iWVzneryBqWL/228JI1/zDULHYIDSiIlUjKzQBphnxCn2ifdaIWDH G8UajeIV333tGGc5rVTVivm52HdcMCqrFZ7fRcStDC2dtO9px92uqLkSyRdi7f1M7oBfZd3j3Vmi 3lRoTbXV6/Q9nbrLTli9Q+nx8pwMBliT7koga6mTaauUBcqPaefrjojyLMKvoaCsYS04j79tej6D tZKlj5ama+3Y/czsIqSjnBjuyzeiSr4t9FsrikxnWjsdqW1rpZjtSG5Ne5HjDYJoClk77ggh3zX7 MI4ijPIXHJea9DhekQATpLMdxIZJnuVT47/B9YKABHh5J0AOUzOjZ5bO3ygsI6bp7Yo3W/puArUG yJjztyuRO2E4Wtjso6znRIppUnljmhI/SAwvRqqMKWrcgGtmNB9FS7vhFZtvaWPFpPxtQnfEgUD1 92Osq6dmIoCdTRXhC4rU9wI9oXjGmictQ+0bfY2uJXbeMQ2coaplINxiiiCyW+TKG001ArW32F4p F6iqXI5B3ngUR9q4uyHAgcnlSNA9KXh/QgF5d84Q9+eCjbCGQlnRkyNbTojqIZSQwhN7IIBC3fim r0ZYgeclPy75aZmZnwRND0NW0mOlh/HUmDK8Fxj068MqO/hI4JfAkx8Kr0iVmfN8NJFYxs0jwfeP ju23QuxeCrlke3y4lKy3jyQI8FpyNIIYjU0rqUtfKBiTgsuuOIDxLmSfK0kKZLt2NGVP2YWrV7Ja b8uw+ipYaKr0mrQIVlu6qHJlpjV4JU9XLaStGmdIikQ2112J82lg+p6nJ8z4jufn97Jpgwgfio/F Pe1iVBw4YSWk/rqlk1lJ+eTq34R7wxc8mLL9EkYzbqCgSBY/sbJmNR1Yj9somJAA0YI1gFTRASU1 Raq8WbWDi8Hvg9dvTyszvcFRAuM1bCEOOqXoeT5ewP63kJ7QMeGG+QF/v7Fk3D5DEh2BGgitNd4M SXZk2aeDf/eySzPdwa5ARaWvWD4eRXgUWlQQWViVHqPG4uTdOR5dx/yLuJBLz/45dKyD/h3xa88n SKuqinxq4Jt7wCf15Z4LCY+wCChOLri62bgwO35EEYlQh10f/Ff7QOLqyn6tEzZG9LQDTiyOOuFQ 5Kn505wgcWTNVzrhkJvJx/tOLHsnYI3UorEVAHLtTKipqdVizn0PiXgBVaEmRjxR8HQzgB+um9MA 7kG3BLxGQOb9OkGcNyLAoXZQlmU3GQ+GFgHrP8wHuKAcHNU1HoEFQKLK6FaigXhlzQbMuyXbpmIQ cJGPaLMn88HF3xDAg2ciAbF16kISwqEz+qUukrMgKlJAwf5amskmSJXGCHBrSIakfqWjxIk34EZq NFC8AS/x6mQpQwpAQ/Z1MwmVjf2GxArWdhudxE7QZi2jBEx2ROV8syPGqkQJm41bYbvkxDtYOUFy FmcCoXrbvaes274PbOHosjzAHYqYfElBR09rYhQBPxf2WM4CNaLMXlbKVs+ashwRW8VvKGXjTsp2 up83iT01XPtAEh/LXk+Z6DV7fyrKA9nrAi4JoGZqLy+u4T5D9ko8QkoaEVtWh7L3xWXqn5iXziNE eGJSc03lk/PSUTq7hrtqg8D7vqu6Y3mJHhKq6oUl5jMgga3E5JDgxvl2uuqzAYE+V9FDU3oICBzL VY+zSBsEcKiH2pRwns1fB7Ueufw5FBXoJBhN8C+0fT4fNo0IUVkpNm2efK0nnIltelCa+mvdH0tJ gWAvLCW/4l5/Ukoew6MvICWf7UaXlKwVaboHUhIBLUu678cPZWfsQWfos/PQ5W5LV5Su6iDWt5+d O5d79AUubx9RxRGhRzhcKhDNVTv4z2B5MIU5XsF2EXN/eVBaHszCZKESuFKQ6UN5bJHrlMY/HhDw f+6rbcdx44i+5yv4SAIWze4m2c282XsBDBjZdXbXRoB90YyoGWF1y4zkwQL5iHxyTl2aokhKM2sg QJx5GJHNqurq6qpTp8AWqipEilqaMqax6afxxA2VTe4rA/kX9D1cTpHzwT90JVGGvCop94venwGb CMInLiuC8Tnyw9pqWvKXs76AmDuXuMbmjX+GqpS5r6liAvK1Slweykaf4WxDhSdvuD2H84q48blp uF7lAfdNH1x8n53pzM7tzfpbzeL+xbMIT4eyqD091iTAX6bG2Keq5ZzwD5tXlT7zfz6m4QR2qHaR nuE4lqs7PslBoRoXZmdqszOLs/5es+iAHPR+cGdNyIvy/+vG6EiuQaVeu7D/4cuZbKIm5IZcKDA7 4AsDx6vdZrPbJoRBfQgCRCCUUwhkYcU7D8rmwFuqBgESS+9X2227OLfU76iAPmPjbPgn66h/YAQ5 66iTLZMCUjSVhsSj8v+cLfO/NogANYNjxhYQs0uDCLrlpVZpStuQOsLfxHHkH+fjyPTFUF97CZWB DkS5lYXYy+DS92+RJ8nH5V+aHClPovxga1x0YGIV1Jsxf3WemAOeDAL9ERvmJeUfTvj9WzNl1QAw qqZBUqIqKfjeiO23q2xGxZreHTNb5y59wLvFeyuvyN1eJIrEo5JrGJx5pimR7qFxw9snchCBfhBm U7Br8DJIffOTqQisxI2p8xV0irFShbg3qIO+3sezGx6q1BZjUijPt7q/rhJQxjST9lXaqyoQ9Ajs 5fOMNZCELvjzoyyuqgRLKGj9N/gVcJTCGnOmsryqggv1lUcavXyXBm0o0CjaV7m9pmIxBISiAnXp qxyuq+DyLVL95UG2BVK6qQc3ubuqYip087p6ecCoyZkKQf4GvyywxBFc9VU+XFfx1LrLc8f+fVUF w6tr6kvx+iXCiKlKhRFL4PF0gqShxRoTBcxVgV6k9u6zmWvyMm0f4sMy83mNIIN3pN3id9kMByjT 5CkzSHzkE3bG6x4SFZBO5feyvMtm6D/pYzYjnTaZQ9uReFwRMcKoCr8r/dzq50SMLfl/1DmoUHRp Ljbispq8g8kyr85MMv5FFx7F/0SMy0Zr/RZ/dyLzpO79NZthICpH+MYhRxNh4DZo6ROIpxHHXBQw wWnQP5PzTfo5yzNj0/0K26WgZVlIX73Hv0+Zs2mCgwV4Ykt6hAAuytIxTQVH8NQTfaL/K5JnpXt8 d+mW5cWAbrE9mVjw+mDLuZiAqG7JNh/52zlhLCh/YmeI9HF4duRFUVA/cQ68wDeFzq+H1abNSp/m mTVjw42lDqHRRUZPNR+NqiXQxhSiQc0aXPQNvMXP54zfcpwYTXDPL6sMFIcDgxTxdHp0U5e+4o/v 5eVTVhpKl8Muc44fROleleB4oOVJpSf5XR3u+WuyViO6jlZcamfm/XVZheLylwxndGnUnS/kN5/M PnTgy+Ex1Dlr08Xnli6ekm72B7IOObHuvrElzhZeS3oGOGWWCFqa3GQxASUt2VSCe7KlZOvnjDN5 TtYkNyUtP6fsXJRZiD/0r5fUkqeDoIxjQUloLKZDh0nIg2fpBHPP7u/3beYaNcvVOMjHskaLi0lu LlV4RfVgAyhaY62P8V7EWPOpdnSA3I6PsOnOekeLD/OukLtih9roNn6lcMfAGy1evhjWZYO/Z1Ec 9wTxr8hehYsenGylwGegzkEiL45dqv6XFb31aCOe8ZHCcdxeAKGpqJuC2t3Lol4T9Q+ug9a2n+XH U9LEhAc25iEdQeqgDqYgdUrtVBOswYuPmWolv0t6xzo5ynUA+hNWWXJe/0A7Dy6FHR0Co+lAMQhE coBqf/0a8OQC6E1kaDTmKZw1Akmmqy1eOxLgmHRzI78q8qBfk50sLwlnjQChESA0AoRYbGWXf/K3 I/+frx/HAEZHKGTcqacZi6nppxydYzRL+UJiMjF00ARRojJhA14VhRbov4YBrioN8DVbaAZ17e3Q Hwyqo+M941agAQrAdMUrZnd25NVFfmcwbZaNc83QvfxC/4bVMlytZ+4lDbyzJRh/De7YtVvCeSAP Wm2gRlvipgNnEfFALh/NKsJpa7l8sHLPKy1xFGrBNRpwoASqKX0KkJUsRNVojoUXeE1upMrwCgJH rdNyZrIIamm1lCbEGyV3+B5E+lFYzU6aXN+FRwE8KtQD05JRanWxeqYTcKsxGG4tkNSVxijf2ZGr ybtf3/Cuf2dPiGIylYU7PxE2vP4ZQm84kobKbJQGlZa/KWsTKWe4zDn5yizea1vb7sqI0BpCJK5p 3JwsgN1TTScsATwFiwp5c+X7LbHtCQPzLbNzQ5dFp+i2bDsFXp8/qFzL0HMES7cEJ+0iIQWm/g2z 8yaNosmXNhoDlhMamTRud5dkjdJ3o2pzfVvIzmL35uzTunNXz9N+NxH3sot7+WznQ8QdT60Vrl8r RSemOGjFyeT2Xlxq4xQUJ5QFzySdmMw18eNg3IkD06Eb46hPIb9uT/NOf+KCID64wJYKEpwDwWX/ 9yL5SQekOx3iuqHs0E1HPJb9pGqv5fPPb+KMNziverRVBy7gUOnsJfbGMTWNx100XktqM9cRB1X0 NavgjqDAkep7K+AhrRfvjBnri4Aj0DB/mMSE1Zr+r4mrF+lccKWHa3dkmrGPUr3G3eGdAZFnsDmL bnQHWhFgGieZU4ipjHshyJiA6Dde6ZUUCc0YYLnp4oi0cTRGrLb64Q635rtEcXItWLjd8Qe+ZKfp 5QifaHUpSkcibTVr3bYqqT9zVYj7fyV24InUyvpKf2X7KDVnLw8DGQJnLEePc8IUuPJbm8z3exR3 5WQDEhJkIWK8zDzeFYlcTFOXygm+YWo6Rda7HJkWqi60HWFFXDlJiPqdcUEMEQkvM6dbMoU7kXFi hEL5hIsO2Oaj5Ev8ynZkvySSZvnhzzwlJMtuuFp3/HJ3Yq190eN+oPEwqEJrnwkIGFRZ2TJSyAEH Ps2M/MTjnMyFeymXE+2X5zs57HFDQjdZNCSBTjrOzGF5PPHiE83WKCqj7zh/onMpzzQSzjL0R624 V913ejdZklZh3/ryemyqIm9s02iybBhxjuzfLTH9ex0tZwY96MdWzjWTic/RaDgjFk4yskydNLoH XfAREeRgfNEgdhe8kEDslsioGSMbvb/n508oACNWqf+xNwKIEpfkhJBr3YLUdsmNjCh72ZhuzlsZ WxYTyOUlTq4mBvvcYGiCTwy1hSIQn6GICYJ4aXT4obqNeOLpgChrH3HMI6VlQevcpyJPlE/eGZg8 zV6hwyev3MDTzbB6m4jeUrR/EKVX+hWXYNkI9zKnvQxa2273bulrZqnNJXetfjswl/GUbX0Pbr+M PdeFMeHUoBZlWcdJ72I44WkIPs4PnzJGv7+9ZrYJ6+CblSA6/zLn5E1x+z/K2rt3Hz6q9MVBwTST dUBc02EcTQwFqq5q7Ue/UbOTZio5u9mfuvCG/28PlNLAcVNIi9a+SeIInfZ1qSTm7RuaDGjGOHTj wR1pjKaK+e/dlCBdfU5y8u2BbXARxOmiZ43o+CAANjzfkOUiijIPEFLad1htZJxg32UumSIePd7B C3uJXIOCIL6wOp2Fc1jDgnrg2DbjmYoRXt9H1Rpphs6ST9QTJ2bTpsprW40Pddvi1tB3gQ7kIlep 9G9kM/CBeTyNMNTiZlpQzCyJV0pBeVVY639zkRQWmvoXJ50u9o3Lq7qstQZOQyKBWGAICzIhLuSK qSPoLNgPH13XYBpl4ie8D4R9MMKS/JrtsFgrvDHhK5uvj6AFNBrZaOaenOFrhSlK6FYguKOyj7zl KBqKBrauXkAOOR7BAjustbFjY9zz7DWV+wpuMrq9YopEh809H5cWwfv5QQnio3xNDsrOGPnYTGSQ KnFgTjeXRXmJEqq6VAs/8bavRe1n8e0NKyQbFX0Y7HFuobNeCl1k0Tx5l5nAX89OS7fEFs/poPkP 8dW2I0VyRH+l/FaFh6LynmmEpfUYxEor7WjN8oSEmrnAyEPPaGYavAKe9gf8yT4RkVXdde0eePBL V9clIyPjcs4JCVsBjRm9QmOQLnQmuFScfhzUofasjx6TDGrcVOANBdQ7bYqgFB5Yn0MvULdTNFwt 6BPRL90gUWwBQNBNJpz74awxLE+pvtVZ0VbWak1/VywM2ZyU+TtBFcJXBzUgCLm6vFrtDEd/mxZC JuUoaJcWGX4bBJAW+rFDDRIZqk7lJ+RNkZKINWMHEpO6l+/bl0hxErWM+1vmysQDBX92/eky/1tn A7JQ5q0HbRR5nwviY37xIX9IapIsruSTbudNu+M9qQVZe73uFrHCO87+nnD1pSzC/stPRfnR06H+ bklmPqAxoqFVsN1IAgG3obHgsfNZz5Gqpk3uWbaxSBQ1yqITkkahDi6uZW3RikgrOlsWrUjkycPT LEwTa1esfNUq0phl/w29ZA2T9aPoRV74B5fS5wyTpCbvtv+vWq+SfHy/9ZLlMDjfWHTuZ/iV3f13 xcFj1TrJFXvCF3ztdJO1yeeq5cqrq7rSu/wDLZ/YAv+xdbJKWVwtZkaVgUGIlJlU1VpNArHRTe1N aiwEEo6ijM148Mu5qD83NZmSpScvPFDp1cXYpEEludSkock3jTFjojdZlhvPnPHkhZ4xS+joko5D s2CoJskAEWrTwrvIcINEMZxe8OWaf2/zK2Z+XI8zAJ/I7e+ZSLK9c7YnwTCtodaEGPwonLC6yh9d FWfXsvhjfrK6bP3JVml6InP3H1b5xX1RKdLnl3kJfVgeDRvQa78tI2hdQfn5XGzT6zQFrUU6ysUz Eki1Lr9U2sfal68rHVRNs5kGP3vEA0BaE4APC8DXyfMu/MdgdURaMGAqL+ZV322lI6d55F4wtW19 Iw1Fa49eV8pIXhTcp7wo7Tgxy37YpgGY9/zQh/kBssS7oR9/Uh9Lrhivvtsv62rNbvkMi18H2OBZ NA5XYS8X8nlcCn6+iybXO1QRtObCzqMwcPR2Y/Bt1K+mkxomdrJ8tmmtp5Q0Kg3s1oXgi6qHQNlV 92xN22jJJjR03yYCY3dNDcKRVB36xXEzUhA2ny3YRSiyKQClB9sTqcXynZDI/ZCDdlhFWIQ4eQyG OoNhJHCjDtfRz8I2tBt6h8DDhSaDIUOa7kOaFkiLgj08SlBBa3IQq5lN+Z6gM/LoQ1/DWYQiQ51u b2lQEdigYcXRn/Mz4uxIL/PS1vB5t7jd4k4+mMn5MrHYgI4IRKSDQ+/JPNcL1uDs8v3mZsTNuaqN b/Se1DuMmeKA7/jHBZ5V+GSs6mNW9TLd0eO7NqgifWRQiCXRyWQ4aoio/SVgEtWh9rVJQbWnWyNF KDYSXYo1FyTOe9Y5r6FOjk/w8zuJaZJTtajBlzKIdp+fUtFy5R4NCCgy/6AUlE0HpMwQaUcImoGT wj8o+LIYZm9bDoM8gmao4BFebSc6eFwuhjseG9s2U/20k5lxYC00GGCTGA1LFbzfcqabgowJE9Gj qILe3XwfPBniiJ2zjYpUdeDQpMUadQ3Gyt7eRxgRtEygmOmmg02nCU1KKS1m1BlgROC4hhrjqI/T lLY1NbZgERyFaa0fnRGrLZiwmHO01eEHvKBhSKsYdr14NnSh8Vk9L/Ugl7eCkjFdeRfFVwK8UdKn 1JNxTCaKdpkoa5q6vJtUTxbFoGXrlt7/+hVzgoZqP2RnP9p5s9hRJlgSEr0NRxHLSKr6+DAn6gNN Pjb2bAKTdFMW/5DpB7R1yeR5VgWZve6O5IOrzKmkzvsBCzL1EGFF5ZbVBNVzwzprxwUCJf8Mwjgq SHLchMMQCrZ68RzqYCH4sUpyxCa7DhyN9qwbVBsX80hfBtvbVB8Nd50WvTib70f+T5G6avrEQ8RK spx11cGy1jXQfCYa8Tg8WNa6JmA9NdrszqNWx2VQYt9msLVJbn/ROsgf5GJg8gjix1rmfWZ9HhLl 78M1LqGTj073txhmZRAZyNHQb+fL3a/nz+NG5TeSpq00bkj1sCrxeh4ROT2YxoKi0TO78pglB7Vs Xx6TXv60oidX/M2GnpyzDCGR/BMvOZb7i+vbOcBpRLnt0SOoHqc8gVjfveL1Me9zwnpoPNFNdbvh eLkUSV6O492V1byYNCImyRXdDkaz58sTgQtqUnNkPRhU4SB4Y2x0HkxeXBOQ3srUQXi64pOeAjc/ UNTHO6YDBTl0L3oRk9VwSw5m4GDqiWAOaIhwCBZ0F4RBGHXUnebk9hz5ER1ngp3oAFwpxhRA+MQR 7U4PzmUHtQK8bfqGvwxFZCNcg8QAEBajpRNrYTScx0wUfDuHHp/sDZElmsQ6iJ0co/+Mhkff1klc PJZxioqOfWiD9ewHasDr2jZmYHGhAOZ5zEA1q/4pL2eAaP50qSEFvevLY4aOv6P+VXlzy6BzfZox JhIi2Sbj0rW8fYpPzWhYkD7k/ptuv8QpcgQK1mT/nzyaDexSTDE1WdukkbmH9ZUHSsPCDB1IG4Tc WRDkSqTyRHt5wxXjdvjhA4NIHcq74h0UWG1K+V1X4JKyuCHJhobO9/IrX5wV7/4o2tf3FSQsbHxo H7zHFWgIZMIoZIUYeJ+rzXllFNm+vsjfFD8dz9HqHNORBZOM7x3m0ZMRDFI/GZUBV/p6MuFiyxAM du3880VFVPWmHDi3t5OsrjGQ2KG9ZdYnaNB0Mlf7qTQzMeouy1FPZhjSweWD5KD8BV0TdB3LV0iR Ll/+9rzyuP4LscfDl79WSJcuf0HkcPvPStNHmDIfJ9yu5eVZhUkPT19XJEmIwkF35QTYTUppzX08 fyztQmppQTeThWu9l6xvj9Xywng2mnICvEI9vePEzQTDL3EI4GgQ2DdV8RsVyHmlXMlCaHO7fkoU PY04jVShn5xiBXUYfTXNMTb+OO7ARt/Y96COijQpzqIOkCbuIM8S6pArOXefGQtiKWARy3ughKEK 6x5wrXZwEjOcRIET08FJbOFEd3ASvwNOrI+11gmD7q6XYwGnOoWql2fRACuhgcjZsfeZhl2MZKt8 vatsU0Myr6/vBWZBmuV6fX6WR7fZUWMWE2NtGud7mwISpwoydQdxnRidLUvHB2ksqqIjsOdXdxVK 6ZwR8ucqlRcVUe0IKw+UHqpO4nl/lz2I6fMgqevvB0xAI/UJ77sFTBv/f4AJFZ30wqkOwcuMdzun ehBeukZ0+NaHTQ8vR6WnLKPj7n6HTawo+uRYms+tZUmclfkidhqKHZS+buFutYb+S9Ap3wWhFmIl JRcGRh+GoYFZI6djnMxxNQIF84ZzINR0eKv2cJYJrlbK9Q0+hn4Gh4H/GHEhlBsBYqrmIr8sWGn/ Cpmny9cCr8/lCzAe3b2pvkwkybSDSzD7FZcjx9B9RnUC6QZCXrHApCE34c/b/OCU3DRwWm43+Yp5 B4Lf10TC/MEVYycpVNKVp/f59i1ZNs2u5T5SPWhSstph6jM6Dv1/UG1Ym2rUPVGFmqqNebLCIGCt 7N3iZPWU0jPkjFbVLCeC4dY6lPv2JHdVJF3jRde83aw/0pWqBEyM0rhd0V9+CfpNJd++ozdX8gyS 6A3Shcs539xyRb09pf83myOOUPGJFpzSNjcbOsKQqbat30xi99Z7q1Dpug3HGdeRFEM5TUmLnY/S 8lH5odkheg56XaS3BQu3OLYZiEwVHNfYFP9Bl/J2ea8jUEcEIoI7lEf3oqgUEp72Q05MNEbsunFY WZk0coJz4kij9EBrCYZdpBhAozWxg2GqiLOzUR4WUxBqpxIhRM/UvgzYOtAS1aHdMAFOT8bfpbrb axt/ryj61lLs7SGRhx6Nve0PjHxO2c7205EXzZ2p0If5JIBsbAPwDr7V7t/GanKP6IMNKglrm7aO nlAiH1WkXU8qQgP063rNjc09PkG0sdOZh6jAWNvGGDXct2Bc9YyraiINEwLGJEvgmCM7M734yVpI 2QCDrOw/nucElGqNjl4eLBpFPZHbqzMIEiXg+x/t1dfjuG3E3/MphCZtpcNZlUiKlIDcQ3H30ocA B1zSBOgWC63tXRuwvYZXvssi14/Qfub+ZobUP8ve3btkgbXI4XBmOBzO/Aa1qYjvE43EAeRIJY0a SYRBEddr+QYyNwtFHG08+yc//yjTenOUwTLyDLdUtsHwd9wSvm+FGnmlnvvgpYfvMqGHB6W8KtUT efTRbx67IQv9UJ4LDE15cC6iKBh1SeWu7Uhf1QQ4KioCwCpcC/C5p7PnXDM0FhcyXQvrzlPvhBo1 QvZ7gAeoDjYi6ODFe56laPE7H/2Oq3hxlaBPYpbznVKANC576oiWYq+gZvGP6ZRyVIaxlmd1Stqq aazBl9m1SvZSqySKRcj3uIuC8OOfvv3uz3/59q+vrqjjqumdSjOUcTNUSi9USSvkXtAKcVtxwWw4 oG2F8ulOCEllYPMLG6FS3N5ZsD/JIwJRLvQ4iupC34YxfG5T5eUWx6K6UWlUbUF8oBzModVcc+Bv 13d4rHg6ZVw3WNBxfUOEDY0R36Owg96ieAYkQlI0jtDhUP3biXscXSE6QyOYKqCKX08gnrroP5OX HAWs2VfnMy3dBciONkDycE/MC/G6oyP0T/JMvG4YXfQVT+P1fqd7EbBn6LRQJ1PrWsD+e0Bere1Y 7LMgLxlVvBBwuTQo+xrAxXivr/65gEuusqf+S6CuIeWIb2u+GuoWsGMo6llQV+eckqebjTOutzql 8sHKvtz1QDND9c9tMk60fx3UtbA5UhVqij6HdSm32raKG1/GL70vllmqFJ2fP93fXiG72vhHggw2 XjFcMpx4U+pZ8eYaxl02bupNSzUevhnBWzbe3siXk7H1sAuwwO9lzGapVAK9WFwI6Xwvk58I8FlO +MTiv8ESL8Cr4SwA6kKm0W7I1QR9H6etSdQY6wWYp7zzlDnrPEdxp4A3SpeVAeW9pX7hJ6pDkfQL R3LOll7LTRLaB4F7yImznBwKRJbb8XO81LGI5iJPMx3SwT9uSRKw1ufRcZ7EWQbQ0Fng/KHAp15l TmlNmTINR9+P8UoxnQ8t4QvW5YP485tEWRO/ObkHehnAoPib9ISrKH/jKZAwVxQhwX0+U/cvCsMb KPEM9cCyqaJ/2SiTASNyZ/eEUZ2ICx0VYIwq83xg01VyHk9lxfkUXhkXKQ2JVeXsEFJphlSXAVVM HDf4f0wKy5N6TvH84gJsVJEqVxUn1lwOOKM5ASukjdJMF2A32eUazWBE6VACJgHxGACVBGD7yoY1 5/ydodyrThln/JOnbc+meeQ9k6GxVDnKdlVZ75r/9PdXVNBpEw/QGKWUw3PSK6i/Zc5FdqRTVeWV ihh1lVmOZna+/UajcylKAorWIYUCMuYRUVWa2TKzPepmRK3Q2hZM7UsI1NU3t2dkF4SFzJC6GVGf lo03lZb2nGw7KXto91DCtN0q55Zr5JOOOvZJ56nTk1+S3dnSlz2kOj2W3acOfTKUHU4/lD3tqVOv fo3svoXTpyHZSGsUjRymMkSvADxSuWiGbkpTbkOo9vMcPXQafTp9PjqLVMZ1SUoiktQO/1FDiYrw A2U74+JoD2qX/I6YLfBPUCGeYTAnKs8WfhP2R5IMmfwRTAwl8vh1MjOCUUSYJMu5JNX9sqUfWBLh p7SM1w9JN6mjW5JJgIZBlPW716xqFxFSKgV0TTVRWpyCBKAFsuQoYlPJBRnCWYVqnZcVMGRZ2BbJ U8sYz1frZKaR+OIlzpe6eAk0QfaAEniuEkZOmo6tkHHoDAqAlhmR11EhHPBVyxbVOJGuMFqwyE7i PIH5rUBFAkkBA8zxpodk5sgs2dJ4W65lCmgFiK2ByoV8x3sOXkIduJfhCDe8vgnk65vH69qfex4F IV5jFHbfiyGThRcF32ZV6/tp1EbOdwqlJXfQhB4k987nu17Rz5rbWo41QqsSNuQwiTVyVRmno3Dj wn3kQKfdW9o9KuOmV8ZxYTVtkzhbsAa+gLx9D4Zkgn27prEXRdw1r40E5lPdTO7xlsvd5DvtnAHw 7Codyhx7ny4Uv/ukkksixOxpNNrxqOHTRsS0bonyi7mLOYBgPHN1IcXvGZQj9onD9vzrZWC0689Z REkn/IgN8/0RvtIZCcHKY6K1Z6q3XjP9zsVqLBu6LTUOm2GDcd41BcGkXPmi/iPdzoobigMnlQdc r8zv6UY21GDIfa5pSMvRA4cOztNwumlo4Z5bHldwSmP66tCJOd5xquSGTsi8f8+/Ne1nITxdRGzI r1iED4R7TZStsGj2McVMMChNcn0aLVkZ4LktL2cwjQ8SPJxjdOpM5Ty2fvd+BhVpEX+YJxYf+AVo kd4SzRaydpTPhvMPXbFL+bqZ8w4Hwid6mCdQ0pfgzkpYCutBqOR2Jj9QVsf8RkTWgTwQhbaUV3d+ +ssymMPTf/7wg0h5HX2SQTAoaOns5A2jxERNKxcFZZ+Rl0qN3iKHeKWc1h5bHxKOCVMiGeGHL3YB h1Ju1JxG6H45UNaJyeJdI/kDDIdbKrJ1wpUMXBwKEmssMGIJvLTitcVxk1jjN/MiIoVri0HgQ/hK lpY0jtYS/tozsB6IRFfS0PrhOCdhrO5I6g68eSJJubZyuqcrpzgJAN1lRVn5fCV1yvk3j8GRk6mT PIPvOqEStfMzSiaaspZM73naCmm8DAYW2lcwJ6XIyVkDi+wEbqBP0NkaQ3UR4tYD5l0rjstv1Kz8 ttqzNWyqv1AhBd6gwZuyDKfjzDqyab318z3Pg2OWgbwMzmgmbsSHbVb47Jjm6IUu30hWpUZZ7eRG 6FQ4JmJJQIMRbzD6EzrF2qzQNCQ/W+9nJMN/wTCi52ygia3//hsHsZLKie3nZSQuM3TLmXwsrbwT je/lM/PbPwQ70Nt1ZrQ7mefovxsfDEZKFwkVjNh4jfdsS/Rlx/QCzxejpx9A5dIqM5VPEr36ggwf 3Tzy60aWwOzWB1LpiwC/Whne9WqPrzGUIB4YeedFS6Qac73YE/16wdNbAeJSTygB3CaDAsg/959o 6QEVG3eWM7LMR8h5srJoSpslAr7UpuoOyGejpNKec9LQY2sEzw+BqzsjJdDrBbF1R7J0JLyaN7jF OPotUeVEoiJr+JqUrc70Pd56Z4BFFbpZtj7dMa71+IRg+jJ6E/33HYVrRWGKrozD1GD6QaiwGFhw 5TdKGCkaroOwu6QCR9TyZyf8BavCQbFCr4v4/ve6O9f/BRgAR8/sIQ1lbmRzdHJlYW0NZW5kb2Jq DTc0IDAgb2JqDTw8IC9GaWx0ZXIgL0ZsYXRlRGVjb2RlIC9MZW5ndGggODANPj4Nc3RyZWFtCnic UwjkKuQqVLAwUABBIyAyN1AwMVBIzlXQj8g0V3DJVwjkcgrhAnIMzRUsFELSuAzBSg0VjA2AKk0V QnK5NIxMLDVDsrhcQ7gCuQDFkREHDWVuZHN0cmVhbQ1lbmRvYmoNNzUgMCBvYmoNPDwgL0hlaWdo dCA5NCAvQml0c1BlckNvbXBvbmVudCA4IC9TdWJ0eXBlIC9JbWFnZSAvTGVuZ3RoIDM5IC9XaWR0 aCAxNDggL1R5cGUgL1hPYmplY3QgL0ZpbHRlciAvRmxhdGVEZWNvZGUgL0NvbG9yU3BhY2UgMTIy IDAgUg0+Pg1zdHJlYW0KaN7swQEBAAAAgiD/r25IQAEAAAAAAAAAAAAAAADwZAIMADZYAAEKDWVu ZHN0cmVhbQ1lbmRvYmoNNzYgMCBvYmoNPDwgL0ZpbHRlciAvRmxhdGVEZWNvZGUgL0xlbmd0aCAy OTcNPj4Nc3RyZWFtCmjeVFHLbsMgELzzFXtMlQN+NVYkFKlNVMmHPlSnuRNYu5ZqjLB98N93ATdt LcEOuzuzeODH6lSZbgL+5gZV4wRNZ7TDcZidQrhi2xlIM9CdmtZT2FUvLXAi18s4YV+ZZgAhGH+n 4ji5BTYP4ds+FdvkDvir0+g608LmnH5cKFHP1n5hj2aCBA4H0NgwfnyW9kX2CPwP+7d0XixCFs7p eo1B42ilQidNiyCy5ABiTxsa/b/Gisi4NupTOhY7k4QCE8U+YApM7NKAKbAgRI0p5UlvZe5+dKKs yLRvwqh2IlbuWbkMiTzIe8mijDO8bnElfL8OffRDc8JlvBFhJsrMJ2IH4Tg+DvR/5s2/eaVm58jG 8ELBJm9QZ/D2iHaw3g+/2LcAAwCC45C0Cg1lbmRzdHJlYW0NZW5kb2JqDTc3IDAgb2JqDTw8IC9G aWx0ZXIgL0ZsYXRlRGVjb2RlIC9MZW5ndGggMTEzNQ0+Pg1zdHJlYW0KSImUVlmPIzUQfs+v8KMt TUz7atvLE4tACBHBQ3aENNqHkEkyLXKM0jk0/HrqcCfdCTsjEqltl6vKX532k4xaGSuF+iqmv45+ mo4+T0em0lUSFfx55mzWOTubhLVG19nXUUw3o6eh1Hc/e2HEdDkylmWtcCbqWAtbWVRDIlb3ZSox /Q0Ew52grXVKA8EPz3JOJz8QmaixqeXuoMZRNmps5WmmbCWv691WAcONZls03zrBwSxX2tn/ZbuJ la79xfaxqaQZSt4b7ywa35ccHAZwKhCZ0ySL6fm/3ZHRHX0lfy5UkNtP4geBXvgMWKzcKxtkgxtL ZbwUv58WQHdMP8GUN88wi0MUYzw9MQxrGMV7rgtZG3sBEuVWjZ2VDxCGChRbL2cXothhWF5hvcBQ MXGsxkm2tHMkwh4Jc2ICaI+TyUWXw+gCXysalTqdc+WMfKE5nkTSK1oucIfPXFI+dFwJuWD2TN+z 8gmIqHjfk7vzSRUy/kqAjK3RN0Yb7zDZ73yDaRKgtIyPOuQUavbRGZRrj4YkXWPK4gDArNc1++ug TACOjrbgJW11tCK9ApcMOT0sWxW17zSLV+YBy6qr4ImJZbXmoYivyiieTP0VegiiFdNbTC6x0v7B YsbjLblAKZbv+GzxN+9ivTrY3fLyubNhbC3CL9zLIvRItk3g68hOJz9ByIyu7yuppLCxjuL0zfC4 Wlcxdik8BTdryieDBkDKgQcpKZNsTjhr1kRG3wNDBsTIBPxoGuxvO1GrM5QBZu4cWWZrFnxGJkFS kJpRbmac2BBeFq1w/QDGQRI2rfKljPZXSC2XEejZcR1gTSCt+QuJfI5YMgNXFKb/oaSQCaDGx1uX 2Trkb7rK2whNAHwTQqhLG2bkW4AwW8Fngeo3pJkh0XmCECxLKcL00PnWR/IquCIxzM2s5wUy/HvS cMFNUgncyh5loU3xOnqVcsnexMENooC6KBK+ROIub0Lpfd6ES4Wb90vcOF1Bd3fsF9SrA8YGvmwU TBBPgPELGAbDA/czDBusSuET40thXPCS8g/G9QwNYDoO4syKruzYaCjWocdVDrjZPbHOwtRROzA7 3t2TAdzDXxlMGaBjoLamIJoV5E0R3F70EUIxGx5TsNx5Pvvu8rPh495aW7xLK6ODMTGz548qU/Mw 2CV4AWX3pgKuIdGQQG71YAku1opbEs7flHPXfWbWtyAtYRzTBfBBdsDlmOB9lbLr7mnFl0uWW3HC S6fBHN8f+OqjS8hgNwZig7N/FCUw8LeUqQfceVlcOwJNWy5zED/ukTpHgesOtAHreX8vnncqQsmg XjqLAGxbFWpMFOA+zlXt5Eu5t6kMUcejcpX8EYl/4PoLCtw/L/svB3haFveY/H4IY9Kxyqn031/4 ZCzdEyPEKV/1K3wPXC7+HT/xrOMrnxlXSORr/oC95cAvxQsra8bHxZw6VpRtKwaPB3oWRLisco+y 4D5FeFKPhor4iDV939Cf5bnyOGnFEQ8oDbffb8W/AgwATEx7fA1lbmRzdHJlYW0NZW5kb2JqDTc4 IDAgb2JqDTw8IC9IZWlnaHQgOTkgL0JpdHNQZXJDb21wb25lbnQgOCAvTGVuZ3RoIDUzNyAvV2lk dGggNzYgL0NvbG9yU3BhY2UgMzIgMCBSIC9GaWx0ZXIgL0ZsYXRlRGVjb2RlDT4+DXN0cmVhbQpI ieyXC3KDMAxEdf/j9DDxdToBYyRLqw846XQGT0NCcLVv1zYOrT3taf+qEe1/22u044utw3RNtIRA S3SyuIDeITt973FBeruW6zFT64rfQgYmGLEMGjsePedvztORKNDV0dI8QSbBksfzjbq4cVly2cE0 TsHyaKyHzCvBdfHy1NnIvDHgUq1GMvF9gZFVSyR1KPsmdqrx0TbRGUSys5DCLnnMXzangslljrhV C9S8zqVPxoAhtg/nZVhFXE4EOKt6XrFHFCgBj2u4rMGBXFpLrYMTXxy1cMD1Pn9t//+zHV+qFnJv 11rIFXS2gVAt4pvqtMFWufroq6PJFdwq/Vo1rsbciaPNxcmMWroi7uxzjey5R87FTce1luXF5wSp OTFN3qBWSTjksj93rmKtfV8/bsx84K/lBbnGrBJv5vKMhGtru7MlJ3ZcS9ZTXIqOjL3Dv52Pzsja 5+aXHCRlw9gfYa1oVJff77PrEXm8wgXzojOvBsHUb4C8cPXy3LkgJSzqe0X5d47PhRfFF+Y90hZP ekEtG/0iV9AqXPopbfaY50LeBNcp1h9EHS5n3Jfm5ff2x1E+yAS//8mspTa/seqh0FwqYxIRqVp5 Bzdkj1odYZ4aN8UaT9VaCjCJux7Zfj9ubKvChORDE/Zs7LWfu1yK7RaytuBHUuBKaLEEsh4XyhY9 1lSwWp1LTZ8VbZXBpz3t79vvALVOL/MNZW5kc3RyZWFtDWVuZG9iag03OSAwIG9iag08PCAvRmls dGVyIC9GbGF0ZURlY29kZSAvTGVuZ3RoIDEwDT4+DXN0cmVhbQp4nCvkAgAA7gB8DWVuZHN0cmVh bQ1lbmRvYmoNODAgMCBvYmoNPDwgL0hlaWdodCA5NyAvQml0c1BlckNvbXBvbmVudCA4IC9TdWJ0 eXBlIC9JbWFnZSAvTGVuZ3RoIDQwIC9XaWR0aCAxNTEgL1R5cGUgL1hPYmplY3QgL0ZpbHRlciAv RmxhdGVEZWNvZGUgL0NvbG9yU3BhY2UgMTIyIDAgUg0+Pg1zdHJlYW0KaN7swQENAAAAwqD3T20P BxQAAAAAAAAAAAAAAAAAwIUJMAA5NwABCg1lbmRzdHJlYW0NZW5kb2JqDTgxIDAgb2JqDTw8IC9U eXBlIC9FbmNvZGluZyAvRGlmZmVyZW5jZXMNWyAzMiAvc3BhY2UgNDUgL2h5cGhlbiAvcGVyaW9k IDQ4IC96ZXJvIC9vbmUgL3R3byAvdGhyZWUgL2ZvdXIgL2ZpdmUgL3NpeCAvc2V2ZW4gL2VpZ2h0 IC9uaW5lIC9jb2xvbiA2NSAvQSAvQiAvQyAvRCAvRSAvRiAvRyA3MyAvSSA3NSAvSyAvTCAvTSAv TiAvTyAvUCAvUSAvUiAvUyAvVCAvVSAvViAvVyAvWCAvWSA5NyAvYSA5OSAvYyAvZCAvZSAvZiAv ZyAvaCAvaSAvaiAvayAvbCAvbSAvbiAvbyAvcCAxMTQgL3IgL3MgL3QgL3UgL3YgL3cgL3ggL3kg MTQ0IC9xdW90ZXJpZ2h0DV0NPj4NZW5kb2JqDTgyIDAgb2JqDTw8IC9GaWx0ZXIgL0ZsYXRlRGVj b2RlIC9MZW5ndGggMTM5OQ0+Pg1zdHJlYW0KSImUV1lv4zYQfs+v4CMJ1IJ4iKReu+1DiwZYIO62 QNEHxZYTIz4CS0aa/vrORdmOd5MtDIjXzDfD4Vye/3rz8/zmx/lNreaLm7pyLqr5y42tqzqrGn48 8zZVyUflm7ZKNtRAtL35S6+NjXpnZi7oJX1pY2Fsozv8jGaW9d7AwYGOB5O1WhnnzzfVp8+w/bvx Xs/uaf8okAoXhNHhB7mfBuOd/sHMrNPqBedrPBpBWmX1I/ExBk1H1IdgzlQlxN74VhRY4XmP+h5O l2DSBzy6lBNFijJ/q/lkvaquc8MmrGvfvGvDkCvb2ujYhiOIqBoEhSs0oIfzMKjNHoTCpFvyqO5l vemYYScMC14KX2VcjdRvlEvBt237Va1cW7XJW6e8j1WMrU2s1xxxo+iF9qGlkncrex72BjAKDKNQ kOIRrEqDGq9wkEc983Fnavg+82ZvMnwP9OVHE2jAbCIdMcgD03emrfClaAHvYwOc/SsSliK/G0xA GUoUEvU2YGCiezGuOV2iUr/wuaAqlFgOxQYLPhrX+zekZzafgXFt49kjbIiebA8zmPz2bdcAVWxI yfMTOLquR3f3MIAfghoJ1AB0WC57OR/MLMGw4H0wkm9hBIM4ZLsHe56Y/mTaHuye0IeItAgoLBs6 3cjqSKtBViOtDiK6m3ZnzlVuet7xUaB7eshPpEPRrF+CIJ+RTV3qPnEtIX4jacL4/XQ3EgsOgYAr A3Z7e6frd3ASmcG14d3ItKC7i65l83+5vVUdmihCRC2NtRhYC9QIQ6xDXTAi17KxkvWr8RiXapT9 R0FAS/iq1QURMhCGbz8MBQE4gj9D2K9UJ0fqkgs8ocXdYTGhL4+gWYO0693DV3zRsQ18rN27Nqhd ZeuAyQxtwO/rIEJzleGL5nfykE7vabfQoC7goA6S0MwlGCGWEpzv8O2chNIdvhX4yWIUrrWMjLVj Kk/B7NgxnXh+phfOk+M79ElvUTJLKGoVyHuC7EW8uCTIVkXjFRGsSMvCtJtAUFbR8hVDPekZCbbT lUWvsiwKFJFXJcJPJSJPCcF+MyOECDPXwptmF/g9thRgnnOQl6yaNNUEz5nISypMnLa83vIhGDHU ZzzrhQnpbK0E8xJLQY61gCh7TEqp1GvR5VAARqYqgD3jq07IZUDDnqAEeXzFDI8p6I2MPQ9Fhtyl w+RLDDu6a5ayMwlRYye3f4I3xs6D7n4VF1PV9nVsPs7R/CKprepYt1MTlLgcc53+cjtIKVZ3vYlU oSMHt42cLmjcGyrfEx+myYBJrykNC9MJGhg3STJxlAYmQkym1AIMLOgIUZFxeS2JWwPqyWhrZWyS VEWUJ3RPpEtGYmET3sOEh4cQTPG0WvLZteeXSpi+w++baKNyEVTzubFi5S12DHqDNZiiIOjdaDJ5 q2ZvIF+QBgT9wGr1E/Zrn/EzAzewmDAyxQ45KVV0DzpnqHFZb9aECrMH7FMh5ZH3wT72WBo9FFMb tH53iNgTDncBRXSDjMYl7lw4IiZRIV37H8Y1ZYQodrG5/cAu4PYuTtmZ6knIPN3g+4Gi1Gqj0DVt DMUuQLKi/IovDgePxEqtr+rx9B/aeJZt7pBD5t53SyxEzCJLZ44mwmnpDYkXwFjskTY23D2zNvgn gOn2W2LcM9FBPcs2U8pA93k+4VZY8rT6A+c9vcd1tStmTf/D4QLkTJ8aqXyoSoMNZU8tCoy7UVpM xXk+cJ4P1KQ4GDtecs2AU/gDg21O4jIRqcRFXZifpJktKQ/vgYGcdRHIcIuCt5aRYXYCo2Lh7srW UjpoJE96cUm/oI57I1hHljHIDU4ipLMVGWusyzBN36nbZfzTW3ycXPkVPBRSGy2FvfpPgAEApbIi 8g1lbmRzdHJlYW0NZW5kb2JqDTgzIDAgb2JqDTw8IC9GaWx0ZXIgL0ZsYXRlRGVjb2RlIC9MZW5n dGggMTQ5NDUNPj4Nc3RyZWFtCkiJnFfbbhvJEX3nV/TjjFdq9/0SwA+JkCwSZBdGJDsPURDINGXT kESZotd2Vvu0yH/nVPcMOdNzoWwQ4Ny6q6rrcurUx8XzH88le/ewkEzgJ5nkKhit2KngwkkhY2TL 28Xzf6xurnbrX1Znm5vNdn272m3XS7ZdL56fPTi2fFiItP1hebf40wUeLraL539REHdxvZCQFLL0 dCeF5sYwLxzXJP7idvGv6lIIVf+bXfxt8ecLEuF4dGlPupEicoUdhkuX16+7iwcapOSuUPCiu4EO h9OxiyXMdBNmSs+1tS4Ugh5fdyUJklEYqyy332KtCrx0x2NPB4wNpIduVIiRVn2ecbCWMMCUhj+r Q3VeS1fdbGqtqh37YXAQQXLJOcqwi7/P+MYpbnw0PqmwTgY1Hsbk6Ggb47PUgTBvuQtG+TIlqtdn 9SmiYKuXuCpcXxVukXrofoX0Ktz/01/LfdkgZSQZVOyHphAkScAhg3ImC/nwsS9E0mmWCzkuRTrD dQzWMBc1D8aqsPeQPqmlUlzSvRnEYDKsSkkuykR5VuyfCZpSji6DurNlrmX3FF7RgjvT8yqdZPQE FHT4by5FlQ58YErN2CDtfZv3WpNAxX1wY0nkPVc+4Mb5wJVG7LJQ9gP77iwPkVuJVCKRxodo5nJ8 PsXhNqcbUR3rcoLn9H5ScmescD5F8ttzW2pUkwwaEgw34pDb94UQH/e5PSImInltREY7Z7l3xja2 fDipva8+TmKXnoctY3lsXGQmIOt/ePH9AZUQHRArl0MaZJyFrfmQoqydj8L0DP7mgCrgm5mLaDJF zeEVyjpQvRUxXd8P/DQVT2QE1wijKQNapoUIh1geK3DLB7HkOZq4pHjiumPsssKHiBaJthkAAjW6 VxHkBChmHw8XMxRo68ci4xxKLAXGGgqyaQz454q9XdWnKIFYXdcR+LuuT4HDsbrDW7JhVUu8Zef1 KdxS3TRfN2ntrnlitTLVVfPwkFeyvGQvhu1aybfNdVULkvzQSpYd7cv0tOJ4NEnBaHofwXYh0G60 d+Whz6ZJlQL6StqgOiD8oR9xZVPODtSBYJnWwQ2/+hUBjH19WGvMaDPBiVWpWRb91apR1Yhf6Ks+ eZpS4/lApxroHD+v1Qmaukp/f6Jan13cVvcHYI2rLVxbjRDJvI+pYLODBDcjcSk0BE+Ep6sk6Zih nCqKHPrDeX7rrp8u62iIIGBTd++wbedSlSCISF3kih9t2uTV6FDOTkfuxB6O39ZKo2QCVRTAP2P/ il4+UDNgO6rB9+lbesuW9J+WpQU7lu6v6Y/drt/RdZuWX9FCVCf230H+u7KddID/eNFRO9FSg5kU 9hddQMbqP7iN1U8AiGq0Xw+bAgKqU2sYJZ8wUuU5oJkK/Dwaq5y/ZGYTsh1cBNQfxs7a/fGn4UY7 sMHUSA8iz16+GiZ0/1zIGbSn7sHWZQHa+YNYTxy4o/UkORnIGqpPtQaavicc3cN0QEZQFgzaSTOT SCVDzlHl1GSOBouTUp9NDT/pXVIP0EmdJsi/hgH51Tr9A+NhUKS8o+8nbLXLGwjnfcU+AC6RuFd3 DAdAr6ze1KlztPLWlPsWpUD/qy/pQn2GWlfFrhodrSZ2lhYg4zwlnKfOBCXNvuXqPl3JAqxd84ke A1R2oy314ASYKqV1oQ05Tv2KHPxiUEWuETtTQB5dc0zsr3QaQ6eJ1bGckuh8QCMMbbHJiKf1ESky xMp0afsI+ibUgmsc14t08KqnuGwmKowqRvMj6txV/DsCYymVTQAVgBlKkBmqmHiTX20cMQa0zfVs eTyrIZ+EEPF4RYGPoFWPQ05YmhcwuPb98tuweBpCKrzRCYXmaH3AmVxqGR2ZrPZwA3Lx7i3qBfml UFGpQnC3ouylr7ka6A1wm1hh82FFCE908jr95+zH+5f586tMMk+o0vh08Td1Pz5QWmp0znvmBE07 vjX8M1VXU6RNbQ87yBNyHx3ehaBkKf+xl/unaiRkgrsjMCklmnN0wZbSWe1MQijCxZBRckctM6Mm CLDNL+8+3dKiN3V+66otPI7769RvD3UPNJOStgAhqgvyu+zJIi3pLmlpZcjGkBKHKB7Cy1nHUWAw Amhmo8TUsme64Dx+cobzdDcyKiA9tPQkC041FO7vG+OwHf82hD0n+sYpjmBM+ABLAo1zc1Pc6YQI B/iO1J+6ZgwmuCizFVrKI3UrAgFc9kybPVpEVIBJ48vNDXtDHEJSdRoab5rrlzQNNQ/LfPmUh6gV TXkSXY2e2CZvv+s97dI4ROzOpMEpQeI2LzlLF4CaT6CW7HjIT5xdZNnv82XdCGg+U4ZW64e85aRW cgwXRLB7QmV7zHU6G6kzUuOy3nLv9hTwUkjBvhCs8wTsQEDc3OPOwh5bUYI5njo2Zik70m5SOZRJ IqEDqnTLfr6U49p4yxEpIbKJe/vkGTxFfUZZ0g/+A0OlcJhLlPNV/+uRZuhUypWOYfdPs8ybgVmv izYq9AhFlhh6Yl/jSZnqLjTlIlIr/jzUHnUWcjCAwQLFvlLbTA1EGkqmj2im+0c1ynRHwqWM6Br4 dXYiM2lL6YvySCaPp5NNq+VplgIS97BPBmNWySfw3CPEksg/slDj6eWTIC4CbSH4AAdfPz4txjJt IZPCdJSlH+NYhttC58k4xg9ZFtHCjs5vhnRpExHqKu9jetOLDUHtAM4dwh7gfouBxao9LPTLooc5 SC07mqTeAO8L92kidAQt53QeXG82RJ4CxiJQcQSZ3rHX8yjTnnssddOAN3f48R5EaSxEOnfAs5pM lVzTw/HO8SZ7O2c9rxUmphs0ElGBQOiAHlEyOtVhXFOzI/iCjUH00oIPmgB8neMhfG4BNgd4tNYU ZQgqSkYnm7K9IN70nqg89SBQpAcKQsXut+ndiohdfpV40V16u+uuTPzrsPgTCdwlTrVN/1dp8Q29 zhr+S8vy293h7eYujYdgaLoR2jEtSe5YdL3pPJzkLbtiOdv80tnW+ZBVv2Wba7a3rbWQlRAW2tlB 6NAMnYRqcw7W4Mre+BbMAGVE9ZHZVMkG2URd3uVxIn0EUdAK122aC0IeH2BhvmRqQD4FvmDxed68 zF/fj+75RDQCR1rlPdus5nPWvq7pvxHX7l/nx7v0jdV6sKARxe5XtbUdY7O0TT7B22Z7aF9c5wvb rW9bASm06X/d+iHz8T+gkZc8R3RGHxvt/IwCDPWJ3GB4tId2gqI0XZl9DCACiy3ktrx8Odf40IKp rUBBUz8vxgpymB2gBYSw1L5psjUd5iVUkXNZwsy0FBLqHGwoZQzbEqUlMsLoGBui3jsk6JbuubYk chhqhSI3CYCHDEqNSJk2WIHPPcFnk4GVqKgczyPOI1nj8CdN5EJroqMK04SyLW15LJyP0SvG0elL WppNQ+t6jEBtr57xPfrpvOsHSuiAjZEjFhbiaT5QOSpjISHY8r4PYNNhciZVwiFOz2oiX8AbsDy0 7FqDz1c79gObKFExH8WYsqiXCT9Pn00JR1kzUZfTbVMK3tfxbMBhXOIwk4YSVVE9R/zx9Y9HRgqF YVBMm9v0/BnvE4Xpe/+yOrusGbusauOpCRDUot9e1jQbln1qzyg+L5Clo/nrAK6G8t5EInmmyd4T agsmwbwCyFuZkJ1uwWKGgZbI/DgPw4qLiGJhJoD5C6vC0ViDCGKVCablOU+LdQbjpGY+1POJGQme OlKOR1siQ/7PebXtxo0c0V/hI5lIBPvCbnIBB1hIeVhgAxjw5Ukvk9F4PBt5ZGjGNoJsnvLjOXVp ineNLEBDsq/V1VV1zmnt6w02tupvdEeq1eNG3wxv09RJCb5UGIHnvjKt+NoPC+Nccaxape9LMBXg i8Y3QytFjCgxt4vEfOSjNlAJ87GlxJjl5JURY+a5eVWLJvEx4po7bv7HiJtDZLaqMr2ZWYdKcGtB wzOPw0WkgF7ZH1cFymebX8j1DYu7vl9w7Ju5A43OYSnbBn6YHKFq0oUbOsxUVVnny9GtFIUBXc24 QODtcDhQU7tEn8bAIQHMHnkNltugkd8ZMtjPls651ZClKuTIH7iW0Dj3MhBEh8iGqaa0c8nG7nMa 1aDdq1UWoUSFhvdO5kcjrNmh5DX4PTKxjcJgXX7eSSdzVUcyg/iU0uIotPi5mWluf7iu8kke2ZfD Xt6edP5Ghp8POvBYtKWHMpDlki1Cmq8KogV5pnOObO49//4UIltIwdZ4lIK+RxDXNf4D/uMKPAfM GNzKXWWrV2JeNBxM/c0J9AjwMka8EwmRiSZrrXA0oTU2rusyjzHECr0Pyt94J1xYrffoe/e4+V44 iQXufsJ1uHyzl94df2Vb+XqUkSfSWrjBwuh9O7lvl+67fV6Hx+jOB/7Q8UfuL/mes3HVNmQzHdbX 9KaHNUsgTyzXo2AEF6ggMqQV1/AxSVxEToDJ/PmI0PH5FRrpKzvDFw70I99l0vOdf3cFbAgUsNzZ DZLmjS55r80Zs5Vj+rqVnQAcAU6+5nCuQSm5lSWsf17xnrsD1Ks8k7mHozbs9Zl1LX2jOeV8Z9EX fe5kl0kUdTXXmvUAgjZtUbo9ljHGhygupd3yw/nbBrSY07cOnK5kHff9MrnL14jZQKKNMhPcvnKx ipdo2ciqwWOFhJa3a2IjNgwqtIN/lZptmrIR2lFRQV3VY1VYZxyVo+TvG/HnxxfplyGR5CsWLBeI KspwO9xj2YkteT5zLeP9i5rKrWsq0Pl6uPOiqPopTVUT7SMU7W+xAqYogER2lyJkRRy6sh0f5JW6 ishlO7T0AqrdBL67JYtfRhlEZ5kSyfel1V9RhaZlITSd71cUImmpapQ8N8TEqMzdvP0w8Y2tZ6ih 97Ra/2yH+weqjTWq1niFJgWdDXGWI9ZsyuCc0I9U/VohEHckI9nC72CKwBtA7WzQLSN2Q9lq/HCb EQUkrr2mP11DZLZqw8zs9XBHAAUPr49WAPMwK0UxUCI71KzqmalMypSpvbgXFd6v+oD0bTIhnQB5 nt/vGJN8LuDnGV4D0P6a8Yfx0gv0+g630M5Xk0YdiqqDrskcWfAT/2Zfuhny3OvuT/rcaPs5DZDZ R+1OEIq391fZJtl8L4svhcVSPtRA9TYiEftuuZBIxpoo5Nr9rIRjVQ6vQvijHRPiBPckEeoE96ad 54uZg+SwzBklJxnO6ZpKQ+SNGYsRYpGaiTZaaXnizs2+ayC+yETPCmk4syhgSZAEASY1+aZjEY0I AHm7pTlvgRegTw0BBxEnkKyeEbg1kKYmf+hm7fFfQi7k2a804VT46nmlgJUm1cWn6lKZdYpJDgLt D7GpnDjo3bYIygwtRy2Ru/tvD/p94O/jPuPi4/KvBVM3bdZBJwn17OMNeD9eUEKZvUFYXTOte5RZ WeqX8WnUQUcddRkaBGquk75or1iWibkbbTzt+POUoXzz0u9kDRksY5MRh6ExyfjMy8wSqUZTnXwi EsE8Qn41Cca67lFBG+xq1SOHe0Bn3bHASwEmMvK52j5TmVl8qUpbO5o+Q/So1nkGbmGI/4HH6/wG gVbjEmxd5R9egnBbYYlQajqZBdPx2lhGjsl0KvbdQWzH+RbOYsC4Zs5iILS8Hxzm6gYXRLFkfPvy MVDkKt8/yZTrzl0CzbMxusvtj2HWfqCfHdn/v8JaoDudIzR0jujyaWjU7Qz3AO/W06TY+POmqFHK sApswDLXFiShGVLl0X21cXpftLJtoKXouKgRxq4ed+6o1hqizf2j/ncK2Kmi29j0mPISVCBRa2Yf vUUzFaoN455VLG3y7UZfzvpkIG4EiBuuLqjTCuGNKEw7hZyYLKxN1FRvwnxJxWjCG+dqiM2YXLal 621QbfhxYuCA9CHooEeGYkj2EDjg8aFga07yle3l+VjwCRjuwcCADHIEtNb5WRfMfuPWW5nyu0z5 Ox0ax/oh637WBXYFZQBqn8yEh6CUVMkAxO61/Z/6/bCR1dL+eqadPDKAK6+exj/pMF3uX/IgaoVG 3RNltp74u19QjX+hoCZ3w7KosUC4khODr0jGgrhYh3+/TFxAhSlGbSzdMw+leSA8Nt5VrlrTpG0s 7WD/IRe/7lEWxwn8UoCbykIogQsNVsU9NwgpxI6wEtCC4/2J37NPxAQe6eeJcIygthEQh78bRV7k RCP4SYBIwWC9QGdak8bek/Nwhfj9N5Ol3+j19veCo8gobAPUT9k0j41mSeWemcdilkALoqKQxkhl 6weJrjaXZDT57qgvypANE9+Wz8j9FNWmI+Cgbt0EomUYmb53HNv5R0p6Q/FhpDzy5wfZVYZsnvpT XDJpowYc9Hk+pKX3ulhi4UYXElPPOr47kmi4p8HQeXtO8kVEJPLQibfrTubUydt2Wa9Vts1cVZXR tEbV3nsxC3X8Kb18Kqiuk/F13jVesQ21SM9zNyn7uhuM+8Rfw7lyczU5sMLjqM1b+dxlWxmehn3l r41WInFTrV6vxSVpB3I3DUKsNgxFvOJZh/5QgNqlHRG2gzPdH3T+eab4EBK9HMAOWGAbXGsblc1t iNsf+VLv6RU8nWp6m1+/w8sW9ZEiwRIjRS/xak5LE3QSiDWGHCjBTlS+fhG5MuR3wSlmGxvUyBDN apnsAgDspfQOf6nMOfOmMBbRD2nn56vwsFa2qPUk1wxxDoW2UWRap050tWjNRc3HNIht0rWy60Uo cOtHFCQg0hI8akptO+W6UvhDheGAS939dsTenO/qGdsw9moDz8t+usAbuNGaS9yIo9dhsDlmDmBm 0W16A71t/zLaccVNAKvWDibDQ4A6A6gzcdlTxjA4rhnMRcmu3rgBG8RVD7bPb+6K6bX/WD4CUhKh ZVwYHWPo+DFzr5jQDs23F/nb1AFwvOzwZUMDuK9pquZn/I0Es6v2XuLuZmL5691tqwa5N3b3qzmW dbGcXMDFHMvWxLiHJylGJP0FZ1iINxfsMPqyu/w7IBmLTfA1cTbjmoQFpmmX4LUmqWohk9oABSqL /3rKbt9ek6PebUG4Eh+LwrG+0c9DR8yO9Lln8kUcISoz+94xuwN/89RT9kXn0e9eeV+jU4j7Sc+j IAtjCCGq0516DSce02OFZKmSQvo+EfZXQ0LpzFQgNa4DzuSttjJL0GmoCHhKyZoYCznry2FPnM3h JIg3mAC2jKOo1fTxKP1H7ie14ak1e9jJoBPRpu6R6dTPuhp/6NSbtBGxiyiczLFuxFY6L3sn62wL H3mZmbHf+PeBjTv0d9jzb1lYNvB9sqRiS6B76GDcRXzqoBZf6fBJHIYOQtZLu60hXU1NiTp07Two jdIzOE4w78s6zNd3UI/IlHOycawYx3lXmfu3S7YEBvrJlnYmq7crWd0ONy4X8zg2NqVxOx+YYOYt ZbFtyxBbr5zuH6SKJCOOnACsmz4jN5BkSIWHLneuCp/3Mt6Zy1KesvErvWobZpxoC2HbQyH3UcUX 96sh1MlZzAk7oxM0NQ1ctcpp0/kNeE3dVMoRhZo7JeES3FGTx6kwQkCn7kfuPhIbp2CWUdvNMUvT QL8dDoMLET5PecSD4RjXaG7EVAUPx4x5ukuDdzI4LTTcVlfCUEsZnm2TeVtZ7XPaPvvE41P34UFf vg2tLNWK959H23HOUrWUfdW2s/Zm42HTO5GkLn1sE4efhZbuTqoArmkbvRPa1QMbyLshqTeEkWqz IHUKISIHJBihCbv/c15tu20jSfQ9X9GPEhAx7Au7yQF2gESzs9h9SLzjSRYL5EWRKFkbWTIsOU7+ Ip88py5N6up4A8Mi2Zfq6urTp07d64zcvKB40WhpRq1JrebPm4na2QlF6XDeZhxIOXhcmDyTpWyC 8q18isd7eqYuaqRmKJsiXeSpH0qBEujIQd3TRdhXdAPz62nV9bRCAqXXPrBbexaftR8SNny+B/s5 EXq5pAqiRZ4QOYlp/HBndHykl0Yey1g+ZtSmr+nUcabNmZyTtU/0HWdeyuVlhMQEt6AoKYNmHBUQ 24dbLmvvdgd6ZJRIdxGRfaIGcqymO5PZb9bLnV6N7Dqa3R6IkSQ8ue74VbQMW6ZeFkaGV57zuSqF ckyYR7eZfZXisxtC2zRFupSUDzOifwanxhggxcEHVVOq7uyTxpa2Qx83E1mWt7NH81uzn3xmqhBD H+N+03fDLlA54KHUiRRxG3XWYchrsbof8bQXb1nyKOYHieiU3oKqwRQqjs/FsCS6Ohn5a2adwCwc NfEEHGWtJAeSCplcg5ArTieP2/C4e7XBDKiUyPMovGJgrC9XRGcBIMBXpawWJPHYgVJpyOzaW5ys dMFHcQAhDTTxG8lKJUmYab/qvKW27Dq/ZYD4m/fcmo3Mz8upH0/v7qcvbncAsQQdU43KJ7B/rHJF t4SVRuoF3CC0bLTeIFDddrXGaRXSyZyF4fc9ucI1xB7cZYrZxxSlIEa/3u4scswb+n337vpPmTM5 pI3/9352BBaaovQUEY4D+/D2t7/zGn9c4g26CV957Sm8oK+7HXttTgJ1vAv6lq4HJsX1hD+Ytnpy OLxmmSEr5bOjmkyY7vQu1l1lVkssnA1PY8JDtLDs4FjIdanlutR0XVDvCopryiWOnkYlUp3vC17m QyQjBq4bdI0v84SfEg8Onjlfn/OxJsDaEumzRN51Hv/hCR1RRdIRFqVD6NIuzUO+dulj6Y9Ln8qd K31sbIrGsTd6gz4O/4YdVoPy+CC803MI4ckUbhuHNN/YA6sIcwAC3jK6NrTZx5fS9EjiDUi5o+Ov pe8L2kIzyIllOKqEpUq9lb/I1TmtNDNtl2W+NjE9fSC4NqgzoTWsq/YvECJolefgcx0Hv1JU8ncY lAYJ6cuStX2gfPQUGi5GCqK2ifXx2mfuQJKNVS6ljg/OFoERsKgSJJS1vqhsIPokmwrvlOGdBN5S eORyJGV4p06Ko0nquO7zaAIp8KS5IanSTiiYKMnYIvVMIaPLXAlRsaNVE25nbwFi5sC+Dm7XO23R Bjg40Zad+U3aruQxOj0MhAbasWl+SKaWUpAtLajEpUpidw2emiLJEhId5S68zh5WojmI/Ba0SeQ6 8ggZhwrdlRCooyzLBCdU6jhvYv4XyFY2JI17liciaGjkbsjwlwTTEHeyWuG1xhrXziEtdLAYT8ON s45EMhpW2S126KX0sF9L6tnRz01eTSz6M6raVkoBLkiBcrHqy4GswS5NqjSOS9EKyDb3+tJKIads TO6UhSZcXzI068Gcf82M9kZMTLClVoKNy3DGS2e8NZ94CkOTojEKRPisdriVV2xlKZ30c2yOoiGG CBo+3OczKycwBzi1wTVlYJ4rBS/XSRZqKpimPKz+auJJgGE9M4dmLlV+Fbg61VXsLT3P9+SoPjv2 3T3P95Qo5xz7TsC07inU2ZRRZ+vL5Zyra5NqpFlwu6yg3IUzN3ctQyODRrC1OWi7VYBMBD57sFrw uAzZO8HlMda471Hg3HagNHs+MJ12AxmU4oHRWzAVY90M5prKZ7TXmUL5EvP8pZpbdc/yxLc+sFZC ZkYIV0qIkkUaapDWp7ciFqA8JOTeyUUfRVckn84G3VtwbhUBh2RZr2dNMx8GlLT3sl3k7pt2GEHs hh/rFTVNiGfuF/Tb0jiQWAXm8iyTA7mOQVshKpDTrBvIbYKXbJsZC9QIrcYfPASRi0EIEdGFjLjZ kN1HeuUBynqTIYsL/KiNSVa5BAG2x3POoLNTp0/mFo5SJK6IDSRH01UsdJKUXeS4u8PWenEvfVLX lHlReJQqFrj7geazxOX0R/JWcuTguxhgPAtCMKUZiF1G8WDXmULwppthIzMZnVqoSkun/zlrwZWW rcwoy+A2X+LPV78H5QAnsXAaCBMTC08OQSAr5cAf2SDmrU6mo8bEBd+fflQylaXvZGCMl7wgMR8O zLxBii2YPx0VucvpkNXetTwBMHrQ6UDWINOuF78gKOXg+jtdwXAZGTbEJ/Wy9yDVWGcZ/5+WpXAV RPpoXoPG2SlAcKsbPT4eIKc0NdcMpA5Fw1EUOqCrM+iPmQUetvUdckDf52jeCDL0EqlRgc4dusRS Kw1tDwZBCqGI0UVC/jQOTcffz7kjxN8R1U3NeYljMmMmbAbfcGML3UzRCEM3StiNkmAj9Mn78GC/ OxYKDUsLnspf6+NWNkgEb7UkhAGKKJ7fcfKWokSdMuFeJ2xlxM5MJ7r4aqUv2gUvANicguj4XkvH lTz+yVbV+IZ/s/He6B237/Tr4WAUgKgr9WvQzu3pvagVkI0UR5ejH6rCV8nqxdhNtkSGn5kuJ/Oh t6B2ouT1EhjafWNeXComMJBHbGjEPX/fsoDdLTc0cG2GtUyXTh53q2pXhDBawfuJqA2vY4y/opf3 ys5el6FdDr7u2Ct63bEp3A6W2yKUva7yQI3rYuhqakWaOqNuc85DpeB+EB8PYPkqKoO/5iVWLL23 silcLMphj0POvg2TsHci7T9TQytSnmU9Q8SpCodYrTtZP2pYtUvjRlaYCTdv5kbWHaMO5eHyOZ9L DbDmObkeoN9vHJMxj920tNic33XClFaT11aLjVDrVNZnRBQb8qw6wZbebxd/EDfs09vglOlmXLdM 6Wy5DJnxL8T/QSGiaVhHL/YqHv4xXNLMhxpNbGqu/FVrvcTKYUdb+kap3+x18dBNX0jdUhcL6J0U d1zDhTy8YL3xbijhRcO0d+M1zmkstkVXnNJgVHw1dfpBnNCQGqfwIlIIqBeJsGKud2J33aPyHukZ SUTo4BeMTJamEB923XmWmF3p3Jl0Em6rIin1RZEQRVSdGbqlVt2zpBVvJ/r9mWRBLGIuUjsfW9Yp RRSlgueVfL5Xn6fiTt5cfrZsfytj7zrPPWXotX7OeMnEzEytZGeR/T4H06pLQvZiFkoOVQ5qm8Kl 0mtZJ2e+h4cR54LbDsCLHkn7IEL3mnoWWuSMCEUfCCTjK6DmPcPlv3gruMsancIM8buIX7L+0JsX zHlc/TfU+HFojqG8b4Q4hO+U1IYH0I2K6qGLJ6xI4XDNRaxKjGq8hdRkKqwJGzUvyd7odq/x/Z34 GEjKG1rJD11w3tr6TnzmxN2oAv9A96oPkw5Z91GY8dX/NMzf881xmJbCdbS4WD7klyo3P4NhLmTU MlU/iFKKoMcqqJ6ZcALUJMq0vcxptEuh7kwKZWbbKP8IMUJ8bYf5dd2n1J1pj1oe+HXBRRC/viT5 ivOg8kmcmFLavcmmwYdsY9KndlmKvVkuxL26T+3D+kyEfNbi/jLrSYxiKHDZSisxIr9Q6C5Xq1x7 WGImvvxI9pznC8rvNY0iuvHdoIX0mZ2O1gfxFE66H4eYJ2qfSvNkSCvqx42OaeVT4sGxLkh4W1pW +7QR19cX+wLYGvrbTl94JL5kvQkRboTaNNAPTTIoKGw09+2L+YuSQ4Kh58sncFlyEja8RpjwEZSI +AU8U5Vv317wbeGI3c7MBMN7lJ8Oc6GTK5fz8Xhze7tZmw/jq/fmj4e1+fdD+9CebiZU4E6UWLQZ 5CucYyzKcHE3pw5UJeQOioKAosfGXHwduG6bpjnvfUikIRLwEkBYHvlS8XK1XK/b2eiC9yWVEwbb tfipKzmVQKdSmSrgLCtvLEpCRBTln49eNvLqH9fOLLYvXo230YyvdWPX47cwCPkHOJt/4f9/R7bC qa3rg6CEovJ/kV8lO24jSfSur+BRHFic3JdjTwEGejCHMrzDnoNatclWqexapjB/0Z/cLzJJiWuS cvdMt6pgmMUUIzKWfBHx0sXLKL1ynIrC2ESoWoO6G1ueCGL5ko4BhriXwa4mg90YoogYFhl1DSAX 4MTkGpC8d22ddg09j2PEplwbExl1zWEC24M9w1wHepOejYmMeaYYXEJhdlzbn+d3ICc0wgzoK4RS mSYSBRCsrnv9JuFr2FKKFB2qLpOF9jq+4oFhvZqFBREXn23igsvYfYIi+q0MHbh8Wc0WaBVaVOvN bIFS87v1AlvRKu5RruL2UI3LaHpTLaNT5TYsK/dnkL/42+zVSNy7GH80xD83QvJ/M7sCPl4NF7rk QBYukUaWrTd0rZ7u3adOnqF7aoHu6bUrd/hY8ASwlAUbt3YcWMeZ9AFY1aM+8ggnw0o5xOyGYEU8 jAjWigDGWBJjCiNYWQd2rzBgwn4f0iDzrvDY85mBrBb10ffnFswCE020MEah+ylYGwOaxrhUlu27 GesBmmK+8MRkMC6smwC0Yz2GFtT64j76GKdBjWgUo2knKXQ3CrW+HXA9EdzHiQnETcMYQAnDEybm seZ/AGP1uI8+xgMxhhQwI38fxhgxWVVhbGBgOtz1DJ9O949zYMbst8dmT+xPIs7RoWl9YRFwmvf3 XXEFTPKphL9M7xPnYklo1WL/xLCJYjD4b5adPZGwU7eACmSBmQ2NyxTIiIcZv+9ffTNSCrLyDHhY A2YSFpwFvCTqEPrXM61BKIzf/bLZ/aKNwM3T4JdKq/vLXuv9bJvK7SCIjzutKRgLUdge0jcCYqEL q2WH6A2AWAPy0IqDqEZ44KotFKccvN5J40ehcDB6RA4eK26zSbIwLCXVC9dDoq96C0sZU2gnM60s 8oOT9YXDGXEB7Mns9nx20RLRXZHXwRyj7XqTictYobzJNNKkfXnHo0byZZfLXtcUuBSNd9j1OIo+ 18ZERl2DIiOuBddw3nvX1knXNGMpt5Kfx1zSTBVM2oNdKiGQcmtMZNQ1YQuhZNe1L323H2sLjgIn q0SJn2xnb99+unF/QglTf3hmrZfqnkeWyoyeTCCUlQVXgqoSeDPCpGlqlW9SM2zCDehY8z2As3rc Rx/jVEwph6D5j2BKWUfkaT/Qk5gC/ZdSPj9M1eI++hgn9ylGVG8AUtiO4R745l/phsUE7krMy6ph 9bFF6oeOSAsGhOBPGFyNK08q+icSaQJiWpjC42ZA0Qvuh0HWjzCNm5xzvhyJFqwtORKrHFMZK/eE R2ISYbXonykB26EOnU35odaWhBsjEqvT01JzBr1nR/R7wj76EMchxUjZjJD61LTUzBRa79i9HhmW McnPjYh1w/7Enl33qqCW4mUpfDXJ2IdefClNRg4gYz+a7b9Csttsvxv780OZUqYw2nWZ2SRippRH D2NdYjaANmtASWw5M9x+ZsBnWyhOyXi9k8aPAsRF6BE5eK64zSbJwrCUBGyuh0TrEJEGDILBYW6w uSnLw1iqDGfoidOu1YeDH5Tw+LYQhYZHm5ktBP5Wq/jRFtruVxr5wIJVLy2o9vrBpcke/3jTdcjU js75wso/PRF9bvx/8+B5wXASSoIjWpVumCgpOEs7euFgHIQhvuLJqZzjyhfc+SwKc144GbpFfEHJ 0wdVrRc6UNqoUi6q3cplsFNqsfCvM197ohi+I9SjsPsobCMKe3gUrh6Fa0bheqNoH4bUolBohJMP Qx1yGGooDPlDYcihw+iLouPxpMT/zzzuVIEgknFAFfwxif+9+GlXQTeKXgLw1wkgMchpRAgKRqF/ 2ZL0ndxcX99ss/Y8R89Ucuh6goku4YdSoC9C+fKOc7rebs/PujsN8QJQBiPBRlrb/Hy2Oe9ssmBo RtJmb4CYgnGFt8fZ31+COmVvLmbIUdw7vEiwJGtwdGEV9ny5zhfcFXZ++ZDjROX8FmuB9Xlc4khy pF3NsxolYZmFdwZ7LCyaoVfZ7fns/WwLD4RzYZ78E/+/kH+wc0uREqDhGe4mgc/hcMOb1HRgDZdO GuypLW9kwbnlTZWbtIovpDZGNVSukyrWFt4rOsmayrekilOFkNLyhsoyrYJ5rI1uOnabVPFEVx2T DZV1WoV4I/NNx+5SKgq3H8YU5vvkJCtctBhKvxnLNqnCkTHoNQGZpVUMKBN3zdP/JakC1soFazl2 nlZxhVFEaesq90kVSRljLcce0yoeyEflTvcL3QlXDi0PUNEYKpa1rKSPRYMuG+vtAceiMQOktk3H VkkVo1GUXtsDIGZ5wL6bXsfAfaFs28qIij+0waBB9zSYZJI141CRQk5PsmbUYAw/oMHQPLLae32A Y1xDxeqmyllSRWAEeMMOqGON+yYYj1fT+6uWRJKE5tM7n8blFpFIf0D4kjLGvTtABVXpPdfTi1Jr AJnrVktK51jjvsV5K2HNHIOXgAiDUvRNAK8Z4RMEgPBgo/67DhvptnVZGNtRTI5oxcNJgQa2tE7T WiSrlW9rvU23aty8vDC8rZXuV8Iiqh5bydmrZDg2aoxNrYe0Fp2c1B2tdBNWBF3JOh6m41KgbF6y znl9T3dvsGUptDksLu3olHcnt9NKzyOj4KHynfNK27IMHiInh9mydCkwUre1irSWK4AM0dHaZ/5V vAZg3EfWzdHGA+kWkXR36k+yQKmEiju9z4Ukfg1SvaLXm1yK+fU3el2CfevAwQ1JgH+T2D09rmo/ 3uV4XYdPD1HNze/XN7k2gBWJZWHPC3pk70j4BBKn9PI2V2yeXa8v6dstfl2G3ddBYRsU8gV++IVe g7X7x7wyHB6lheadiFFwIRks3EB4dUvqJCPcQeiaID0rLHfAXdlTYPX2PJcerZA8IkfvyTTChS+r 3Mj51Tn9Gr4/0GMTXcOX22xJqlv6NXzPXudSzX8Nr3gUHFmCcNgLOyJVVze5ciBplLUsmNtmL2m1 JkFciKwghyhfkiRxExLzN2TlKpoMzmbr/bZkbHtDelmrtYbUSN57BdpnxKK3e7u/CSyqOLdbIMPh UELMeDvPgRMcrZufnOLxNphf05dt0CpxA8+uwjrKB9Ub+rSiT2HP8FtW2+U2WozbfH8ImvTEQTyS QLVhyHYQarnRQkZVJgKEOh2+CW3ZuBj+BzJZ5As1Z9g6BHSZu1g496ECsgDS5Yp++VrJ3AckZ42a UbasmftlEIlVVKuRn6F9hv8bfGEwigegAIWbqkyyr7EgFjxWwTdarmMtXHYtVqW7CRssz/oSI6zb lQofqRWQch74YnnjoU03y305hhwEsy8oY9lJ9HvnzBk91rmf38dErFrOhu8PObchBTKG/HmO508k /jkv01vYeaN3BOF4GH195uPuDHmQAdYKyrmumlzsfd3T6isfkNKJnUUpzAtufcxWrQIC4s+yUAIX oTXUcbtALF/Iz1/vKNxG/YX3UOrby3pVaEo4593auG1ZDVu+xgn8irz+gzb9nGfX9CWU7WVof0Hy flfgdx3YLGoFxVAsEwCkBY0gic7sZTmB3p2QidO3IQMfcT7AOwt94CKCHg/4H6ZHjygPoo/00zKc 2V32LQYS2k94hGKxwNWCGudCIEM/3Q3sRshYlxsBT4WmFFR+dNuJL8MXkycNbijaVXAg4GmMgwck t6Ae5vAMdv18Gf8EPIYlw5PgjT9fozziVvTrOnwrBa/qm1yVBtbx22XUK0VOwp/TuOXbuFW2vIgy 5Z+4dXRsff9fjCS8vAB4EBHwk4OI1vzYbKKdbPmfqH5T7nKW5SS/qseyQnXVXDyPS+AwyKzr8d5F cy/QDENsA11diQkYtMIbvBFmtTIVefuN/WrpceM4wnf+ijmSgWfcj+rX0RAgxIEOCiTFNowc1rtc iwrJtVcrC/n3+aqrh5whh0NSayjJLgVo2d3TVV2Pr15t6vhtDuDkVmhxtVxC3yDadRPUOueTjKud HLNoS/y0kw8l4e7c/MBVvMol4L6ba6TctdnooZL2I59u+qHSH22pdngfCNKDFS9bxCRuNq3SYpGP aB1ghzoAa4FrTSyBIIGyfYMHLHBEe4s/0enq4/XEYg6laCoTdXYKMK8wx2rbGATK/XxyO/kdhClF OICFqXFBYW7l9fUKn3wM1Wfw8Y3SvqpNBG+IC0aY5WpmpDKjN+iAVSbDs21+/vYlSfdLjQt4nj9j GSOheLE9NCTzkLCUsBev38EfowoBd4TcxQqRyPFlCjF+0Z5mhVKwxxUaUMG4RjEpVPCUtiosxlUI BBOGx6uAUcZi9SgVMNjoOKDCalyFlBrvHq8CKeSK4B+lAinbeB/2VVhvVPh9oiXSgLqAlgGXHZoW FIEsy75+fHmFtyiw+DCRgqnQPaSyxl+TquuJ7BDAFvVn2W4pcxRqjVjWHOdlcT2pMfM52+6Xk9o3 AYAu+5qZQcDCZLOVJ0BdDkSC5WYv0hVesLc8AmNPbv8CEw57Q6yRYPFsj+Bd6nrnZ8ggmpP11T9V dbM1TLRiGA388dvUbuQnm4a3LB78utzswRMtm3CooTRBLbVZFfP4zYHYh1UrBy3HltN2L7/FRHwi Ty63ByJoYViM5LORWK/l5H2G23CgEBDPgeKRULnHkI4JMOvmeCRZrnZD2c4ApCk5WDoh8ahUxrmf Gj0GUxMbC5HPgyn9L6OUBkEq9j8NqmwTY1O4QPUIVG3MOXUYqqMYxWBAWG4wqgYwSloDm5I6krtg 1BWLUCkviXSkC0YPF+2IasPp1KXTMUrKN5EcY9Rz29zBqB3DKHKGuyC0i1CT/W/MBaFHEGoTWtL4 JQi1/LxuEfrjcKUv48+XNaRPEaNiETTyl570WKEPCSZLR3rSATpMbSjzQ82oGUqiFnOmpspQwNDX FnpMXPgbPf+FPzYYdTzAseB5AXWCMtiBlN8ru/yN0enaDTRQ7BK1WY2lsSyRd1FkIo1QyVJpyxjZ ChI3kuAqJIhZkoDRsm638hF+Uclut+CfXBans9y6oxu/BpQJ4RKa2IpxKH4BWoBYVV7s2URAWNY+ l6nriewSvuhKbmtuylj9sgCWeh/qLknd51Z3H6rb19XRsRA6aaW8F62iOa2NwUEyop3JnmeJyoZ/ SPTjLaTVvhKCmhWhkN+XlajY+VTIC1m7a3m2e3mwbsUQNff9peGTyihoYcITcRerBI1EKx1CbzT6 Ks6xPefYHefYE51DnpPJ0/KO6BSMH/bOz+qrB9JjfDVcT1LIVw1qGoXSKr24W63u1hWXo241QlNF RldvXw3yQc+h0EagZ8I1TqeZ1evFej2/2WPFpTMdYEUh8HQQOCYSGivySXh9f7Oc9zn1ezEXde6N lTmSy59CL3akC3OIQRJrcKW+dGEHuzCNjsLYiBxyoAnTjVHofIZhn1sIWyYGDd+UeWGoGbNWoymW eYGewbhQIGrB32t+xmdKtHcuNDqYzclyc2KSbwyL1hLtHWxpfpish+GfzUygyoZGnrHHsvZzhL6h xqCL5gFE63QY+weAbwL8QmUO8fCIaaGvDkA/Bk7PaOFbfzxl7Iv9/4sREIOBnbO9FfeXlwgYigCb fE7+1pkvyf6wLipAzv7c9bg2BGwnBIYdBF9QBN/BFCUuUagsET4wljVmNYZChlDCEkxgMEnAdkZn Km0buL66n09uD4iQO8PtkxCm8QicmvloNJhgpNkFYKQyoyxAJsOrgwalCF1YBgA0tA0g2/PDxhyD GsAEMWYFgjy8r8HXjiCRyYhZEUDIbkcCSOzFkOtbbjlRnfX7U8yIhOqgOpsxIcdszLgYNaNDs4xc PG7HE5DgEFqK5w1mZLilPh8JjmcWO6DCalwFS8De4zUAm2T94zSwnOr3FVgPFDdKuvEKlncOAvun X9xGZo9sC+RoJ9aIdBk+DtUfTpcaVuAOLFh3bgdGEenO5OLjFSIkth3YT40eAylGQk/mAlIBKVvD arIXkB4BqU05lQ6DdBSd1vI4tkXn0HzgCDEQJWkY/7zRKbYIWgqKcep8cPozwOn/f8HJRdrylIMM mtTp4HSErJpSSZ02dcBpx8CJZBFVvIBTwAlrhOR9vKDzCDqROglm/AJ0InUmm1p0/jhY2J2Bn6y7 dJ+MzmyL4Myl+zyKTkxD5O2R7hOjoOLEej3IwQPXCfbca0DNIE7hJGtz3rCMtWeNU7aFs0GsoUMb t88dp+oQ1GzjuAmNDSpOOj2VAqKOfEml5FXcpNIhiJL3wDGnUkKRe96FXmzhkxgjeJd6CFXPEJwD U45DD8TVBkmUTDh9OvIar0XGpUtNMmpb4oemI/aFNZI6ldHPHpfWUJB2XOmdCn8El8+k9WRc8sCC fMmBew4so23TpXZmC8vuXDTsFgccKfhzMF+IJ9BNpAjTG8uKvtngOyRcg8YK6JNhV65XAbFBvau1 gSHZCY32rnP1AOfaJBiTY0R1/zkfCbYdfOnvg7FFDgYJBohPjUEVQWGJQAh85WDD+/nkFoax8LrX HBY+I301cS4UMl+w356YhPzKodQS7R1saX6YrIeNnoWyHL4sVrB0NEmz3Nnpy3bJeHPG40B11gIu lZ+D+sNwCVAFcibTKFc6yO9vlvMKSDsGFzxktLIZLYl0pAG0/InuP+Rq6PXtS7inens7SbB2pssL 9pPC7JXdgPtZu1781Awq4oYFC+j09vNEoyEOOHoFrnqIq+XZLiTEJvzG/CFc5vxyMat1mv76aWb8 9B5rO53zErbefVP73JCr/CD2UZTNKwuXMByYeSvzm64vEGum8pCkDknD8gxdgZdBw8Om/xv+f+C3 8Mq9NGT7r3DA9l5505XSFMpX+5QwJmEK8D3iRZd4n4Qjzpu+Vg+jJEAkKZX6r3waJ0HQkaK+Vldj JLgNFFqrTxeMVEDBTMmdrj5HivYq9V+5GydhIyuyPZL1KIkxDUyg+iTVOImDX84TzGpWH1mkS3I7 TkJcBjWdIZhlIwfVf2U5SkIwskNcnqELoQ9JwZ2BF6e51bN9VW7GSZCsMB2eo71HzVI86HRJfhkn 4aSxK9i4LsFgICMdz7BxcJwdlT/jlai4N9xxyziQkWCSj323XI9ScLJI2vahPx8n4c4TGDvdLU7B LQgwd7pbHJKFtsH1X7kfJcFPsE6b03HskCxSIN93/r9GSQxbLFA43WJOJpedXLn1ZK7EXE9jqadO a65vm+K8l68tVogOKqz+OtN+evd5RnE6/2M+syYXUT/9ZlYTPGPQKE0XtzOrp9XDHX/Of6rV3fYq 6q2dVv9gRi9mcfp6Vofpuxmp6Uc+qhby89uCKdbrWR2ZgqY31Qx+ApCxfqgyv3WH3wOfL1b56jcz o8rJ+3KFQh83UC6UVkIjgQ+VUB2a4Llaa3LIDhFDQTZBlu/hil8Vhf5gWa4eFncz54tMIp/YId/P e5GuGtJ6dfVvpq5m6Lzk8vU1v/Cp2A0XKya+kusfmVJ0y5c/8748veB7Zf2Szxe/8pVPeLXrAOLD Jltqt/MxbbdleagZ6H62pkHZ4OaqzC/fZf4f5e0XWZfXefMOj0OwmrHAIEksPDB0lY8KgXxY5w93 ZXefd5/Wa9yMavrLMhPMZ3ViCIEMkNh9CFi0vnze+1jeuhXGdyuR6e4/hFfNToNAEL77FBzl0rgg ZetVPZhoUlP1Ti1G0oVWgZj6FD6yM9/MUrDYXmADy+7sfD8zNLhLUHloEt344BA+1CGVOjnN7KmE kaZtSv9F3jEJiqxSMhNWQBPMDZYhTspYlQLhJwWQNXi0EvS86GYqJUTJXCm6NDNpFBZ+IaoUcbR+ 0Qobajp1xh09v+EF7/nlLWYotRIl9ZYnFhJQx/hopHvX9ETmRHKMmcT0n6deU294k1I5SwJ+uWY3 mD/XwZbfEEQJ85+GS77IMTF0SOYOJyYEExLIOGLUJXFMo000Oq90yr+fw8CyoumJDND41Pg89oDs LGiq+gv+YLV3klaIQLz7oAsrNhecrBBhXK5deqkZEUczTMOjlnYBA0xjOdATbfCuyoJL6OiNlbDR XONZyuriIJyessv7CsYEufTQcExZ+qrC9684SMpkMVN9Fiwe5mwNzNBgud8LU9Y0OWfQK9k5Jup9 SVLTc/YTQ2umGjsMssSGvNouPKJUE8Wd+5t/c0XlNLB2kiRxZH1boA56KcbdKtusihZVqGfAPHRq 0d56x1nQNlCTwwrfkO2gpAj2C0KEZP1DlWUyqC0OVSiX8tDjHZXTeEZfBNt9BcYHsBeHgErxmh0T b9BdnK6NKbW0sbEqjDJb4xB/xYGiLRFsaBNXwPdQ8a76nYBPhrYAfC0EfaELraLuh9wyyyTtg3aA a70ItBRrwhBI1aE9dFdJQi3vB5x5PPsVYADZFpqBDWVuZHN0cmVhbQ1lbmRvYmoNODQgMCBvYmoN PDwgL0ZvbnRGaWxlMiA4OSAwIFIgL0NhcEhlaWdodCA2OTkgL0FzY2VudCA2OTMgL0ZsYWdzIDMy IC9JdGFsaWNBbmdsZSAwIC9EZXNjZW50IC0yMTUgL0ZvbnROYW1lIC9OWklFV1grVGltZXNOZXdS b21hblBTTVQgL0ZvbnRCQm94DVsgLTU2OCAtMzA2IDIwMDAgMTAwNg1dIC9UeXBlIC9Gb250RGVz Y3JpcHRvciAvU3RlbVYgODANPj4NZW5kb2JqDTg1IDAgb2JqDTw8IC9IZWlnaHQgOTYgL0JpdHNQ ZXJDb21wb25lbnQgOCAvU3VidHlwZSAvSW1hZ2UgL0xlbmd0aCA0MCAvV2lkdGggMTUwIC9UeXBl IC9YT2JqZWN0IC9GaWx0ZXIgL0ZsYXRlRGVjb2RlIC9Db2xvclNwYWNlIDE1IDAgUg0+Pg1zdHJl YW0KaN7swQENAAAAwqD3T20PBxQAAAAAAAAAAAAAAAAA8GYCDAA4QAABCg1lbmRzdHJlYW0NZW5k b2JqDTg2IDAgb2JqDTw8IC9Gb250RmlsZTMgNzEgMCBSIC9DaGFyU2V0ICgvc3BhY2UvQS9CL1Mv VC9SL0Mvb25lL3BlcmlvZC9JL24vdC9yL28vZC91L2MvaS90d28vTS92L2EvWC9lL2NvbG9uL2Yv Ty93L2gvbC90aHJlZS9nL3MvZm91ci95L1AvVS9oeXBoZW4vbS9wL0cvRC9GL2svTC9WL3F1b3Rl cmlnaHQvUS9qL1kvemVyby9maXZlL0UveC9zaXgvVy9zZXZlbi9laWdodC9LL04vbmluZSkgL0Nh cEhlaWdodCA2NjIgL0FzY2VudCA2NjIgL0ZsYWdzIDQgL0l0YWxpY0FuZ2xlIDAgL0Rlc2NlbnQg LTIxNSAvWEhlaWdodCA0NTYgL0ZvbnROYW1lIC9CTkxJRUgrVGltZXNOZXdSb21hblBTLUJvbGRN VCAvRm9udEJCb3gNWyAtNTU4IC0zMDcgMjAwMCAxMDI2DV0gL1R5cGUgL0ZvbnREZXNjcmlwdG9y IC9TdGVtViAwDT4+DWVuZG9iag04NyAwIG9iag08PCAvRmlsdGVyIC9GbGF0ZURlY29kZSAvTGVu Z3RoIDEzOTkNPj4Nc3RyZWFtCkiJjBfJbts49O6v4FEEIkFcREnHxp1DB1OMgTi5TOegSootxJEN L8m0Xz9vo6MmbloEIam386308s/ZH8vZ9XKW5lmeV2rZzvLM2Votn2cmM94ZtfxrZgBZqRz++ORM mZW2qK3yVcgs0DzO/kkWe506m2y1CUmry6SH/8NBp9YzjNEH9SXRaZXcfF580XhQByReE7LXVdKd NnQe4DyurnRqbKI+LlJimpKWSYdiT7gAi8+ZhbArBAKvzRN1BBGBTVC0fsWFoQ2tzId4/a9aTl1i ioJ9YmpfnJ3yC5+UPgtVVQR2y1ddZQWYC+IK1GrdZBcwuqaGXc3BngIOC52WsN2CUQg+kYzINGzi 4bscmjNK9i0xjOg82DMQj2Kup6bciyomjRb0GnHqwPpbJl1HJMXG4nEYBbYi9ivR8MwGiwrVNmLP Dgx0SHh6pY2w6rh+BZjGIZcIYC4+v+f34DITSmPZ7/MFRPVWQzKoBnPn/l5DJg54HCkpB0mDKvmm PeThlggUQdZE0WuDtsCJgCTmAFIfcFE6yhjVHXx/xnRHeINcY6d2SLCX/Ifl6ay/Y8FMqD4AE9r6 SZEBRLu/kIlW/GCt/akjXFC+MFnwRahe0q8Sh1vJDwuVg8HHOuF9gLCTXwSKPDEqlqMCgJ3g5TsK bfso9okYexIWVaiooxGiHRFRTgJ2+UpJtOHqrfqPmJSWa8MkqRDeMLQ9U8cktTFJzxdqm43YEPcD 5mt1qe49ezsvJ3X/82aIfvcYG2cd+12shySCAIOFnu32ySeyGxINIxOwVMASD+VYZoGKMYhjPZeR l2r0XI0+OQumixbILBf1yUqBADNVfse8c9EqRlBjCVKv4UXkWbOaiGjERCFuJkQRJRY+kPlvvJlX gb1pTR5+3UXRmRYE5aasYxKT8b0OeEf+GLDlgzZq+LAf0DtB2j25kt28F/yJv0feMpwNZGtqi+TD RpgOxFVg9ulSfG0pSqhZUTHzLAIi0dhql/9AiowdkqBS2qL4gXAjA+UeLBSGYPhNIWzLQZPjmftu ziSL2wid9s/JZDfu3dYBe17lrmCvPzY7bJ9Qr2C4JbsNmo0t9bilbU69C6C3Guavalqkg8UlhN8T R4fH4QI30h2RY004rHOQcY84WAzyOO5Z0IG/6QLCJWKIZqLiEaU0JGsgMHFCkP2F2vZ1zMZQv+uO HFKhqGp531zrGkoLWjesEPqQ1WSahb0TVOoRKkh8fuAu9QOH3RbqFQ4bYYvsLTRMA1PIwQCDKwpU xCiYFqnxcHqaGLARXVuC7SJJp7A2wT0IZdyeJi/IeYhE/Q5UuBJOo+BWRKmiXczYnC+H1ilsIFCI U8ymiQL4Bv3V28SLfTR34T1fu9pnuSt9yb5+hnTicoAagbppOa/X0N6Sx54/Gt5GoTkwi8LwZzix pwJ67bGg9vJJs/thYMoooCMOEFNNxNzzBp2ORoXH2W89QsTEYbNRsTgKajusHto7HcRYBSFyZqJN rN8MLO670HWZtqT/b1Z3Yil7Xb0uax5Tjt1b2NJJYzVV/V5ndZXNSkhqeZ32/2HuQANzMnUcvQVK qChMWpf0Iz/dHPd4J/lYwCmS0JXLZBR+oTtGefI4dTRUGuGNMB7qDueShS0V9A1DZagDaycIfD+W Mr4dNxUEr2SXJ4pjt5fnO+F0LWm6vsCi+RTY8kLPlKGV2/A7v4fQt6XJrAuFiVNLejmogZfmUQ77 +ADAdkXDl8ANzc4xIrX8ThCSVAYgkXJyvkgaVvw9MPXIX3E2byieInD+I6cI7Ej3INrUgQd9e1E5 0540jySiOOtlwhW/AuT62LdpLgu/CD8Or8ifotXiJLJI57Gkokphx2ip/wUYABJ7LL0NZW5kc3Ry ZWFtDWVuZG9iag04OCAwIG9iag08PCAvSGVpZ2h0IDk5IC9CaXRzUGVyQ29tcG9uZW50IDggL0xl bmd0aCA1NTAgL1dpZHRoIDc2IC9Db2xvclNwYWNlIDMyIDAgUiAvRmlsdGVyIC9GbGF0ZURlY29k ZQ0+Pg1zdHJlYW0KSInsV9FyhDAI5P+/xaf7mON3anuaAGEhRKczncq0Z6rcsrshMWV+4om/G0Te PRhuPoun5+i3ecUQVwlJaWp48uKEy8iLzLA/9UyH0Nedjst+1LEvf3G6XXnsYkVm3NBlltd0iwV5 3S9FVYwYYV23dkKjSxho5IPvkMqiJ2z/A6zBhPPWWg8HX0LOp7xYyfP90mbUKCcmRbzUh7KejkUq /6zR2l703vYvb7S9v7E2ov26/+6jXIJSU+GVQB3z2C4CE+3nx9PUUP5pvw37dXaCXZutTLtndVR5 SWrg74Ebbn5rNvT+3NajMF4HWDmovR+AiDeBNF/WsC/MWEeB1wzW9XB3y7CBMNS4apwcM7ggUjap ujrE+mbAYnzQHB2AOqZ8mcRSGmYBoxRU2M3PKk7y0YW8auid2uZs1vu4WWM9swoaFqyzXsw7XDmL vsjLJiAsvSGvLru+4ZtquPsSXkCjn+Ut8du2ybSs/6CqUSf4xo3EErjbogCZsrA8Y43xllTBypl/ ftoyMIc7U5apf4J57O+FK/NYwUrkffTIC1nRIa2medRozkLh/1bc8s8Ng176sLuqURWbm0coU+SS M/LLIjyZNoyWoyMs8aIqr0ms8Qy2GHklJw8sSYSX1Rz2GLDwPTiYWNlQXWMKZgFeiotcvkUsjXtH VwcBGTm89DOT7WCNE52U5T6PGkANCieRsnNAn6fR7sGTGkVqmvDEE/80vgYAMpo+Mw1lbmRzdHJl YW0NZW5kb2JqDTg5IDAgb2JqDTw8IC9GaWx0ZXIgL0ZsYXRlRGVjb2RlIC9MZW5ndGggMTg3OTMg L0xlbmd0aDEgMzc4MjANPj4Nc3RyZWFtCnic7L13fFRV+j/+nHPuvTOTmcmUlEmfO5nMpEx6JRDJ DZBQQgk9QSOhSHdJaAqCiQWBAIINO8SCIqAkoQVwJbqWRUVw7YIQFRVLlHWxIMnM9zl3Jgjs7sfd 7+/z++f7Yob3eU6/5z7nOU+5MxmAAEAQNAADecr1k2q/Umb1xprtALZZUxYtkP+R+vEtABERAJpX p9VOv/4vT8XiCHsHgJQ1fc7iaSNufjUHwB0KkPzyjOsmTT1ydextACM+xDnyZ2CF9QfrzwAVZiwn zLh+wY0t/cJfx3IuQFTSnLlTJhHtyS0As67Bcur1k26sNRLzcwC3r8T+cu2862pP9br3SSxjH1MI 1rEAYoCvG/QKljBnKANBnwBAYrCgwdabST1ZR+4mj5Fmcpz4aBV9jR6inzDCGNMxJ7uZNbI17DH2 lmAQRgjXCBOFe4T7hUeFJ4SdwgHhI+Fr8S/iN+JZySBFS3aptzRW6pS8ccvjzskmOUyOk+Nlt5wu Z8o5cm+5SO4rD5DnyvXyk/LT8naH6AhxhDviHW5HumOM41rHfY4t8TReijfFW+PD4qPi7fHJ8Z74 QfGT4q9zUqfZ6XCBi7oMLrMr1BXhinEluFJdua4i1xxXg+t210rXGtc9rsdc212trv2u510vu95w HXF95PrSXeRW3P3cNe4p7mnu2afF0xGne5+hZ7LO0/Py+fzzRef7ni85P+B8y/mvzvu6JncXd//o 7fJ1+Xycs9CkcqeJ7CCHyW/InVeROx8yuMCd25E7d7InBCIECyOFa4X1wgbhIeFx4TmhTfhQOC02 i0fFMwHuOCRFqpHOxDXENckGOUS2yTJyJwW5ky0XBrgzC7nzBHJn6yXcGe242rH+AncsyJ3I+LgA d2rip6rckf8NdyoucGe9q8m19QJ3XkfufIjc6X2BO9e5Z50mKnfIGeE8OR97PuV8L+SOcr7/+bLz 75zv6rq2uy9yp4Fzx/c5Cth9vlD6Ov0zy/Adp28CeE0oWXeTG8hsMq+rCcszuex5Pd4Ub7I3CbNL YQksgjkwA4ZCX4Cuo11vdHV0/a3rCARen1cDfHbcn+9Yjrjv06s7bu849+mWjhuwtBexHtHYsezT hSdnnVzcsf/z1I47T245ueHEhhOPn1gNcOIpPvak7UTdiYlYyjyhnMg5kXC87Hjp8aLjhcfzj+cc zzyefDz+ePTx0OPk2PfHvj12+tgXxz7jo469euzgsReO4VWOvXJs87Edx0qP9TtWcizhWPwxx7G4 qPao36I+Nb8AICI0j2oe0TyseUjzoH+10tdSX3GtCGwKP2ckCi550df9uKT8Lv2tp8wGXdqfKRfl r0EJaxP+BiB8h9d+RGwS8eSLzRf3F1EPibv8+HcvcSOH2BQoPfLve/7TyAXiogv5ef9jz8pLVyZu l26Vtl7ShcETcDssZ9fCBvgS7oA7YTU8Cs/Ak2CGRmTdbXAPnIG/w1q4H1bCS3AcfoCNsBX+AT/C WXgcNe5f4VV4FibDFFgPU+F1uA5eg0PwFrwBb8Jh+AqmwdtwBI7CczAdvoe74F34G7yDMvc1fAur YBbMhNlwPUrhn6AJ5kId1MI8mA8LYQHK5g1wGm5EKV0MN8EylNe98BjUw82o92+Bb+A72Ec2kPsJ JYwIRITz0EUeIA+Sh8jD0A1eIhEN0YKPPEIeJRvJJtQbjxEdCSJ6YiCPkyfgZ/iFPEk2k6fI02QL eYZsJdvIdvIseQ71SzNpIa1kJ/wK75FGsprsIrvJHrKXtBEjCSb7yH5iImZiIVbogE9JCAklB8jz JIyEkzXkz+QFcpC0kxfJS8RGImAHNJNIEkX+Ql4m0ajrY0kceYW8CufgN/gMPid2IhMHiSevkb+S Q+R18gZ5E/XbW8RJEoiLuMkRcpS8Tf5G3iHvwn6SSJJIMkmBU/AFeQ/eh5PwEXwMx+AEfACfkB/I GfJ3tB0/kn+Qs+Rn8gv5lZwjvxEPOU+6SDfxklS0K0AJpZRRgYpUohqqpToaRNKonhqokQZTEzVT C7XSEBpK0mkYDScZJJPaaASNpFE0msbQWBpH7VSma6iDxpMskk2dJIcmUBd100SaRJNpCvXQlXSV aBYtdC29k66j6+ld9G56D72X3kc34Pt++gB9kD5EH6aP0EfpRrqJ/sBuYbex5WwFW8XWsnXsHnYf e5A9ihZvM3uGbWPPsh2she1m+9if2YvsFXaIHaZn2NvsPfYR+4R9yr5gX7NO9gP7O/07/ZH+g56l P9Gf6S/0V7GXWCj2pufob/Q87aLd1Et9aDcIo2g7BPodE8UkMVXsIxaJfUUF+/YTB4hl4iBxiDhc HCWOEycwu3itOFmcJs4S/yTOExexRHGJeLPYIN4q3i7eIa4UG8U14p3ievFu8V5xg/iA+JD4CPPw Ey4+KW4Rt6Pt2SXuEfeLB8SDaKVfE98Qj4hvszTxHfED8Zh4UvycZYlfid+KP4j/EH8Rz4s+iUka SS+ZJIsUItnYt1KkFIt2S0bLFS8lSG4pSUqRUqV0KZPlSdlSrtQLLX5ftGr9pAFMK5VKZdJAaZA0 WBoilUtDpWHScGmEVCGNlEZJo6Ux6BuMk8ZLlVKVNAFbru7hDQtiembw80a6Bi3kVGmGNFN4Utgs PCU8LWwRnhG2CtuE7cKzaFV3CM1Ci9CK3scuYbewR9iLdnafsB99keeFPwsvCAeFduFF4SXhL8LL wivCq8Jrwl+FQ8LrwhvCm8Jh4S3hiHBUeFv4m/CO8K7wnvC+8AFa6Y+Ej4VjwnHhE+GEcFLoED4V PhM+F04JXwhfCl8Jp4WvhW+Eb4XvhE7he+EH4Yzwd+FH4R/CWeEn8jk5Jfws/CL8KpwTfhPOQwu0 0kaSC7thD/yFfAE7YRe8DLfCi7CCDWcj2ChWwUaysWwcG88q2Wg2Bn4iX9F24WZ4Hh6ETtR2m+Fu UgzrSAlZRO5CW3oPuQHayFLSSb4X6oR5wi3CfFbFJrCr0SpUC7cLC4UbhOXCIuEOYbGwQlgprBIa hdXCGuFG4V5hrXCnsA49krtUn+Rh4RH02zai9/aA8KCwTNgkNAmPoafyhLRAWijdgJ7NCXqSdtBP 6Wf0c3qKfkG/pF+hdF6F0jhaHCOOZXYmMweLR5mcIk4Vr0M5HSFWiCNRSieKNeIklNxycag4DGXt ZfEV8VWUtzfFw+JbKLvz0YIsRCmeK9aKdSyRJbFkloLSfJO4VFyGkrwK5XkFyvNqlO965mGpKNV3 sTSWzjJYJsti2SyH5aKUnhV/En9Gif1O7BS/Rzk1o6Ra+TVRTuOkWSirs6U57Fv2DeI7lMsSlMz+ KOkd4qfiZyi9ySjDiSjDHrFMypSyUKZdKM9pKMV9pCLpKpbH8tk/2Fm03xL4HWd8EYoJvczQYSMT REmj1QXpDcZgk9liDQkNC7dFREZFx8TG2WVHvDPB5U5MSk7xpKalZ2RmZefk5uUX9Crs3afoqr7F Skm//gNKywYOGjykfOiw4SMqRo4aPWbsuPGVVROuvqb62ok1k2DylKnXTZs+Y+as2XOu/9Pc2rp5 8xcsXHTDjYuX3LR02c31Dbfcetvty+9YsXJV4+o1a+9ct/6uu++5974N9z/w4EMPP/Loxk1Njz3+ xJObn3p6yzNbt7Htzz63o7mldeeu3Xv2tu3bf+D5P79wsP3Fl/7y8iuvvvbXQ6+/8ebht44chbf/ 9s67773/wYcffXzs+CcnTl6JFK5EClcihSuRwpVI4UqkcCVSuBIpXIkUrkQKVyKFyyMF8U7EULAj Yti9EA3g+xRxCnHaO8TXJc4Gp3eWr4Pxp/LPBgDgQpu2CRLgDMnCvWyHIfAUlEAF3AsD0SLtgGBY TN4AAZwwALaAi9gxAikDG1qSB1GnXoN26AvU7klQDidQzydAKdqmcCj0fY1pOaz07cNeQdAfLdt+ MoeMhgzMD6KpxINXXudrBxsk+Q77PsTSo6irE3wtMAhzX4IFEtGK3QVWtH6v+7pwpQloP59Gufoa HFADq4VcodE3G/qg5L5HyjE3DBaLH+p2o5W8C55Am9LuO+n7Cl4QCFrbepTolbjiVmin6aw/ehQy uOEqGA6TsPUm+AitUxZTfIm+fr4HsfZp+BE186tMg+vwwGCYiLb9MeTG+2hRfkLbmIfWchu+3ybf i/yTk3K0xUvQ4j6K3Hsa7f0+1PZZaAtsyC0bJMNYbFuHJ6UVz9dRUk6quOVjm8VMb7Ev1Bfm+wp9 9xSoxBVuwpN3Cs6STOyDV2DxbIEQJywQs7tvwTucCo+gl/A2ruME8v0n+JWk4PtTejOt9433bfF9 gWvRgh16wUiYgJ4C9w4ex119Cc/038l5tGA30yPCKyjHZ3x3I2/d0A/XPgJ7j8a5V+MutUIbvt/H u7Sgxc0ivchwMopMx5hiA9r1j8hHaAsdtI5+w5rZG+y4kC+Kvt44UzjE4XWdMB69ljnofayEu/F+ t8ArcAgtvpuk4R29j+N/pn3oAHw/QY/QE2jF1gld4h3eDu+33vO+RozvBqDcVSI3tyIXfkBPQUY7 PovMJ5/jytfTXSyYmTGKyWMlbAxqlZXsXvZXjPTmobb9WByMJ3qbZpL3T963feW+24FHxxKuKxFS IRcKUH6moTTNxvXVqh7UUvSQGtGbuwvX2gTb8L4Polf2HnyCXtNZAuhvZJKZePXrUeqWkzvx/SD6 Pi+iX3KIfIp+A74pBjhoyfNpMe1Py+h0uhzf99Kj9H16msWwKayeNeB7I9vDPhJAEASfmI3vQag3 npbe0CRpBmkma9/s6uxO6a7qPuEFb5T3au8G74ver3zjfItx/S5Ig3Rc6Qpc5YMog5vxvRUlcQ96 lG9ybwbX+iN6dyL3otAbSkHfJYsUk4FkML6HkZH4Hovv8WQCvieRyWQGvutJA7mV3EZuJ2vJfeqb +4Sb0b/bo3pw+/H9HjlJviTfkB/REwL0g2zotyTSDFqId9qfDqQj6Ch8T6dz8V1L59FFuENP0510 H32fhTAX6sJJrA49k+fYS+xddk6gQqqQIRQJ44Tpwm1o1d5GO3ZetIul4gz0AF7CeDMX7e0s6QFp h3Ra6tJImgrNZM1Szbsan9aF2uo1vO/dl/jlGdIRMl8MFW6kJ/FcRLBacQUZixyT6Bg2ByOQv4nT yBkmk49JI5vJZvueYGX0VzaXjKMHSTz6Kr3ZNFiDvu82tCBn6VdCGBlDvyZJwl1kL53L+lNJjQfe EcKE28TTGP18AL3pMtJOX0H/6zbfn6G3uJGcFDfSt0EWOmgInMRTvYLej4PeojPpaqgUcsXzMBP5 /ox4I/K7L11JUti7wkb4gjnpP9AL3YBa4zAZIiTQa2kh2YYat5vEQSdBD5/cBwr6y5+QNiBkC3ua DKUG3K1maiQFGHMcZg7yLguCKr5G4qZhpIKeoWPZ89JRlkcIaom/wRL0+TNRdnpeXowfpsG9NBF1 Wilqk3dINkRgzFICZ73Pc40tfiiuRjl7jKXCKMiEavoG9Maz8QW+KzHuyYb9KIMrIZM+AEt9DWQq 6v1hqD8p2vtZkEH0qC1tuLZ6tBfhNB51IcazGB0EYcTTH8rJ93ADkfFktUOSwFvWCKWomWpQ/67G 91SoxtIjcLe0W3wHRhAbRo+ydyNK+XG4Fm3O53j9KCjC9U2Ax4RUXLWMmrkORzziHQQKvu+ANwjF GKg3RuqzoEIYhJp3g28W3uFMtFFD0SYegpm++6E/7t0o322+1TDR95jvGoy5Rvu2oP5d5GuFfFgh VtFxokfIRR17iLyM9ugYWY16exB8jPrIhbHKN/jGeBb6igegUfgAdWexb43vPQhDfsQjhyajFT2F 8dr3yLdBrB1yvMNpi6+M1aKFOgkjfU/77CQIZvjmoOZ9HjZrRNQ9DRAnbkbZBaXf2DFKcd+rivr0 LuxVkJ+Xm5OdlZmRnpbqSUlOSnS7EpzxDtkeFxsTHRUZYQsPDbFazKZgo0EfpNNqJFFglEBqqbOs Rm521zQLbuegQWm87JyEFZMuqqhplrGq7NI+zXKN2k2+tKeCPadd1lPx91Qu9CRmuQiK0lLlUqfc fHiAU24jE0ZWYn7tAGeV3Nyp5oep+fVq3oh5hwMHyKURMwbIzaRGLm0uWzSjsbRmAE7Xog/q7+x/ XVBaKrQE6TGrx1yzzVnbQmx9iZqhttLeLRS0RlxUc5RzQGlzpHMAX0Ezc5VOmtpcMbKydEC0w1GV ltpM+k9xTm4GZ79mk0ftAv3VyzRL/Zs16mXkmfxuYLXcktreuKbNDJNrPIapzqmTrqlsZpOq+DUs HrzugGbbklMRvxdxcmv/yhUXt0azxtKImTIvNjaukJubRlZe3OrgaVUVztFMXWU1jWV44TXIwvLR Ml6LLq+qbCbL8YIyvw9+T/67u85ZymtqZsnNOmc/54zGWTW4MVGNzTBqsaM1KkrZ5+uAqFK5cUyl 09FcHO2smjQgpiUUGkct3hmpyJGXtqSltpgtfra2BJsCGYPx4sx1F9rUnNqd58pHXeAr4StyDkZx aJanyLiSSifeUy+eXNcLGqf0wm74qiI4qnkq7sfMZl3/mkZzb6w38/HNosvslBt/Atx/Z+d3l9ZM CtRILvNPwLNcSi4IGrb35Js9nuaUFC4gmv64o7jGvmo5Ly11URttdtaaZSTIPqhA3k6q6p2BzHc4 +PaublNgMhaaG0ZW+ssyTI5uBSXDU9VMa3hLe09L2Fje0tDTcmF4jRPleJf6qD6sWeu+8M9kDg8p ndG7mYT/D83X+dvLRzvLR06olEsbawK8LR9zScnf3utCWyBH/A3I8GbBhZwa7ETRGzWhklfgP9FV 5iydWTMIjxqusTmkfyWLplX+HI1m6lQov9dcmJkXKg18LsElqfI/tU2jRQFWa4hc1myuGeRPq4Ic jv9wUJvvDB+lkt+HBe6pubfn0nKfS8qXLM/QyHDBgpuWj5nQ2Bh0SVsZKqvGxjKnXNZY0zipzdcw 2SmbnY37MHStbKwtrenZ/jbf/tXRzWVrqvAmZpDeKNoU+rU4ycqRLQpZOXpC5T4zgLxyTGUrJbR/ Tb+qlgRsq9wno35Waymv5ZW8IPMC2jc8Fa1Uq/aP3qcANKitglqhlqe0EVDrtD11BKa0UX+duaeO Yp3gr1PUOv7imqL/mMqLZUA9WFVp3LJTEoOeSozIn1VqYFgLJQfoC+j7aujBVhCFNvrCLgZBGp7Z TSBSK4kHsZ0CI8mgI7PJtRDhMf9c1F003Hy2aFh3ERRj3tyFSVamw+KwuDAhMQJ0yay9S+FPEWWh Ha81xzeVPSi+gHYrFfLIupaYgjZyn1IVMjM/MSqjYKVtTcaqTLF3bnnuxNxpqYttiyIXpi7KXJy3 StwQ+6z0rGZH6I6wF3NezTsn/pYXEhRJFG2iWxQER15aZIQgh4dlu9KEPHekKJCQ8LAIQ2LwQXIX hNFIMEEw2QSJZMouk8kgkufJdhDIFHCQB3fFx9uN6Det5UeNrN25I5SEtpH1Snj2Z00xJCYKCohc oBTUFHQUCAXBchtLVHRGcNQ4ah3M0UatrSmf6drIN4rBjO7FRAyhBIjM348OMkEWIXeqh53tPFut cqq67ufqYVjoNHciv8ynOjsx7cbSKYu10FpYaLHxlPCCjRdaJL6D+yDSd2anzprrxqOgGDEjmjHJ 4wl48FWVldl/sZKSnpWUHBsXpM/MysiiUnpc9mSSpE+ZDFmxaZMhzp6elhyUiFWJegOYi8xFHjUh Hk/KLfiCumpS7QnJCQ+3WdyJ7rzc/IK8nLBwGxadbneiJTw8LFTShDnzsEAskhQWGh6SX5CP3oY7 cU6qfsN9n5bn7d2qjOoV+0SicfXqrnVv71eufXwymTx1UuWz5Um9SkY8SoavujuYDlo9e+j1N7WF XHONGKzp631v0z3BXqH56aWNfzM3NAjOJBZF3jZMHz64vmu9McJZp/RbNIdHZaNJA63E6JhBsSJT sSF2an69iCym0MwYUDOpQC2/njSRo0TCsDN3NzQIYyZwGe2uxvuEjE5MszL5PTrCHKOp2H2e2u7n M9/lO0Xmoh+pB48SA4qkZ4pO6Z2nU4rzJurIJt0OHdUtN8xawueqm+fx4NZ1ZmW6sjlDnPGcUwQy lJL09JKSl9Q0PUPh8zLfKdpXvBNXPErRgfiGfXo++uVcfIyUhVKKy8ZTqEdP2K6EyiyT1bBa1sQ6 mMQOkGfpG0Ibmdtykl+VSwzKS3HRCjHds8z8clamh2DgRvt6wyrIt+Kdv40Tt/LPeYf4TrO94gww QwLsb52kRXdKahXFME6Mxqg2YlKsuihwK26quGvcTe4Ot+C28OpgLrf1sA6DWhEiXftJ3O/S26nK 7TB+2/zGUdKGkgRnQnwCxvUYLlBJ44qJjo2Oi2ZSiNvk0rsjIm2RVHIIlslgl6Imk9BgzIUbMJdA 5MkkWouJ1Rw2GSKDMOECTHiSoiIl5ZaQXGtBfk62LdwSSpHDie4Csy08JxulzZKbiLLpjNdIdMia BRNqHln68Mp3Jr90y/UvlxbW5S+IS89MKEzuPSBvUC7deJqMGFWy6RXvju+8e+774sVfvKdb7ps0 bzspPP3w/EzHVaO9j+AenUH1JyHHwuF+JVSJqIloiuiIECBCiaCLMDigwSUhGM+XoMZrQj+dqXkt 5p24wb+CicyEcKwB8qMSTEwmqsOoWqc1UAb7yS/YfbBiDQ42KZa8TFO9ab2pySSYIm37aQI5FWCu p2gYHn5zkbq7eOyJpRB+6uwiP3k8WRhNkbrqEFeOJRQPZZgjry/N4wzg93+GDHGEFF3jpTW9woM0 rihXP+G1x86vmNcrjrpcNDZrCT1+b4ocZ+dymIr3uA3vMY7MUG7VROgLbRExV+VGKJhE8sQUFx6e rCnSDNY8o5EU+WphgvZq24SI2doFlgXWR/SPBj9o2a7fHnxIPGT7a8RHto8iOuRzwjlbWBiJFSLF 6LDI8EhbbIRGZ9NH6GNzIwdGrrKtkzURkZTaoiINkZKRRVJRwsAjLFQTIhjbcBk6nRJqKG7QEV0b y0HFKUatiySbIndE0sj9LAcZt3YnoYa4NrJWMYL02YiQiSFzQ+pDhJA2olFCuA2MAlmRG2RWIzfJ VI48QM7hOTMSRQmdSOfSerqOHqRH6En6AxrOSPt+cufv8nyqqDOgiXsUcWd3dV1RcXedX93uXacj B3VHdBSq66o8qJlRFVtVpVxIzf4uu5ZFro3E9qrgohVmcdnLwXgkSd28atwxFGLwEObIA0DV6IyX NM58FGZ+85KGahzZ+fkFbNvErg50ROWNf5q6ye2KPPLw5k8yhzx1ri+ZPGd8WRQRveddpB954Jlb nlpYt+/Vd9dPn/74bu+ZXuasNK4J8ZSPw/3MJkP3QZCvo9VQqGvztStFhsISXWlQmb48XjiiI8nJ vZKV3JrcI7kdub8EaSCXlOjqnUvStybsS9iffij9pPOk61j6N/FfuwyDtcltZM3OpCQztNFTO49m ksw2lrubieZwEt5GNu2OVTwZubFtpP9OszE56QCZAaGgo58r+grcA7pe3QPcyZ3NBmLgplNfkdaQ RtenNaXRNKzfPVFTj/feRr9QgpRc0pTbnktzUe/13auEHAyhIZE5XOGcvrBB6u50Vted5ckp9C9Q 9Xg65xV3VndaCzP8Oig/PSPOHWQSpHiH05HgcDkESXQFu91BqFwyhLTJJM6EOYceLV6QLl3KnEzs xliubfw2z9Nj9vgZmwd1Hk9IvqpzcJ/C1c1yqKqdV4Wr2idP1T1up5OfQ76zmhm9W25/Yny//csa au/2frtqSoYjMspyo82VMu1+Z5Tds2G4PGLToFtqHp4hDFl136wRE+7dmLXnpuZbtgxIjE3VisWS fuOcEeW9YpNK4oKuvX3E9PqnuA5Hf5Htw90NAiN8oCSFG4kJSo2KiSkmkmIgYRpUuITpRIkIBr0R BINRkAxGPFUxilWjDdVotFomaCSDFtCpMR4gj6BPpyebFKNIJJ1WkrSiYDAIB8hgPC9aMk3R63Qm RjaxHYyyNvKLEkGK1eNlIjWorzpMzCQpGqKJDL7oDNUVqTtUhAcIs1+aufdXXJjB/Qlzp7l7XpGl 0KIemBXpHgHtFc+aTCbUaPPQyaibR8KcFqfFkUdykBC2b8/m7pfowj9t9iaQs3d6HyLTGtitXWvo Y90Tuf6ajPK+WByKrlqc0v9JgVir4mbG1Yv1Un3sGmFtrCaP5jnGsrHyeMfsmEXi4pgVtDGqMeYJ tkXX5OxwmsBJ1K84oS+jDUXLyzirLLIDTa4gO6KiY5gmQhCxdtNOWXaE7EdNEsFCFOQp+QzoZw4H +nP7SV+IJgN3N2iauByTn1COnURx1jipEw/IuT1m2uQgDj6JopMVc5OZmiPjuQ/4tcqxU9Wo5s3V nDuqaJ/i3h/qnuJOVaBR63Mts0Kb7hGRXcALfkWjGOeReXSefCu5ld4qS6hxuKJBPYOhk6KfLcy1 To2rFWtjxeoqUk00Do3AJViSNAHPBBVPQHhRdhMJWzzcO6OK6B5ePv72kfMXL5mb7oxKzCgftrBl 4+rrnyeCOHTrnsSNK9tm72lILBidHeMxO3Jb6m96r3eahpq4dFbiXrSgdEZAEnQpKQt1i4JuCL5V 95Hra5ckMbKMLRGWhC+3CUXaJElkzsikSInJE7VEi7pjj+wmbrcJnbO1OyNA5M7JTpORIHMVvkeK VR8FKUoKVVJqUppSOlKElEg/37EJQswhckhmiBKyPqQpRBMSmfy7i9JVPaz7VMBHUVUFKnTkanXn PGQj+Z2Xu/RStERVFqL+SI1x6ayxMXExVLK4jG6Xzokawhw9GRzBmEsIck8mMVZ5MsQbMIEeH4Ur DVVlkLBgpunR69xHseRaE/JzCPeLeziOyp9tuP3pJ2YnrL9r9ZvTl765etILdxPTr7O737QOLMsZ PH7VymXu8eIMl3HE46+tmtLRvHXN1mt2ktg9ZJC3snvAitE1n/bLePKBbb/JeAqG+k6xzXgK9PDi PhB8HTtDovuKbb4OxYOZSC0RWYquHyjGGmOT8XVyiH5IPqQdRmQp0RMwKkZGMUxqI/coUYyGMkYF ZhSVgXniZ0RCIn1GUMzbyIN7mvREH2kQ99PTwOhXigEEs6AIFUKTIArP0y/BEOC7mYuxP7rhFtRj 7vT4/dMVwcteDgivboG4QLpdvF0SAoKLFnIe8hE9cHRfHejGaRLfoh94i2rJfd7VdZljcmLFoe7f XhBeiU6v0fPIdCnKWyPKWyS4IYcsUfZXEaLLseekJM7NWRLfoG8wNEQ1RN/qanA35jwTsTnqaddO w66ove4Dia8EvaL/wBiugSAiGWmULjHcaItyGV3B5WQNuc24PPgZCO4DvUk5RuGDkyaSqxOvyZkF s8hMOt09K3FGzk1kaeKi1KU564R1YoOmQXur5VbrutB14Q8IG7T3WjZYHw5/yv1s4rM5bcIe7df6 bwxfB3+d+HV2ssaoS+wNhaRXtjhAC4aoREFNzDbVF5fENE5CjLElOtTrOpR8jkzMm1EXmyFPyaNK Xk1eU15HnpDnfB4bGJ6BFDwDQZk2xbbexmyRufvJ9wHFwt3zs6pS6Tx11u+hc4EntkJVyLM9GXHx lnBBG+ZyiE50xzWxk0lqKMaE6Va0iPECmsg47o57wjFEzLCk+UU9IOvcPnJlU8d3zR1QJzwKDLf5 Yx81THTlB2SdS36IGhgGrCVZ9Vj1m888+dc525oLh37c8uKccYtJ1o3KomnTGvKy8kdXrL1+zq3u gXTb7U3jbj/YOm/oxtkrh0+rW/fG4knzJ7S8P2fZiJk3LBqROyPD+1XZ5ppbHl4yflDhLNRBI/Ek bEGZsGE0b1Bybkr8SPwg/qNEYYawWFymXaK7wXCjcXHIDfJq7W0hQTrtumTaRysmRjgSI0QW5xJA I+7HwD+CKLsSK9CyoWZSdBmuuS70nCGOb0+wiDpqzS6bDYwRXANFEdNesJqtspVZ28h1qI2SleSG ZKYk1yQ3JXckC8mE6zAHdlOCDgbRoMikS/yZTr9D0+3X+sUB5WQ+i1ul6n3VtfSH8NEJWovBbXbF uJ1uu9ExGWJNPGzSYk7Wx2HsZMEkXue6WCXxjVJtgi0vP99a4Nf8BQFnhqJ2InyD/DukqqY5t3a8 nfxo/bo3p9306tM33H3i1cdeoDnWfouHVd1RVTIx/eYYF11IEnZc98ne1tXPNG47/5l38S2z6L5b h0/69Mamje/cMC4V9dEQ36eiSZwNCYQq/XRxGSSDZrAM+wbTg3FPmJ6w7jHtteq1cSTchkbhprAb w9eyxvBH2Yao7ewA0xlYsEBjB7EqJmZozZaEaFQ94m4aTch+aGPle+SHxKQYRtroyd0WT7OZmNtY ye51xk1GamxjGUpGqI5ux1iaZJu377AQu6XYQi1RCpoXXZEcQUwR9ggagQacjo0Y7Jo6Rd0GT/U8 NZL9eV4dHpk6PCvd6F+e/bK487uzncTMT9EhdQ/ksGjJgCGVW+8Od0nRujQwhGGijRTTSJDNmMY5 Ty7m+zy0BiFOlcE0LNSqRqo2SXDK/HhYE/g+5GQX5BcIb9vtfb98bMXHyxZ1PnD764vt07xnDnh3 7GvcQ4r/fM+6FGt0aJRenO3NObJnlffdk23eH9fXbQndveW3/V1vkDEHBoWHRGdyG4yxp8j9oXCU OKZU6aP1sXeY7zO/ZxYXmReFrjA/EPJg2KHoQ7HvmrURFmtobBzThJEVUSvjaJJWskcD6l17tNHh tDki7UnBwUYamRQeDtqYohFW4hfzTKtiFa1tvhN7OA+tg508vOhbnIc+j+wktU7uVzGnwyaFhNCx NgMGvpjyrjZU6QazmY6V1EopildKG+MnBfbAg/Fut5riiZjn+VndFP+pQFgKC3nYi3sQExVnCjO7 Qt1xpphxJCoMk1iLfRyJDokc18N+bojryLzqupw8zl41NEbn3CEL1jAzuu+JyHWwmAEddWfOuITw mMRhOTSJZJKrXtz+onfhsfpxp0m2960zE+a7Chzz2Zx6OdXV6H3hHe8XL7w7OYaUERuJJANiuQea AiDsQo7nkHylWMmbHnNDzMOZz0RszzyQ2ZGnHRdZK9Vq6rX1ugapQbNOu06nS7BHxzriXfZoj8Op VThDtI7gYLsuWqvhrHTwGo2DUrsUrYkxR1PiDDaZYnNgsycd0sw8aKLvKI7UVA8K1ObY6NMxMbFa 3XatVtpezCMp0Jg1IzQM5/pSqVDnWpS+PdVjT8vAoXOitsvRSvTJaBY9uiKvFk0JywOzulVmdVfM 6laZ410J6lYlqJUJ6lYlbMzt2EdWqOadb5O6V3hmqjvPVp/qxu2q7izyP7r8Dp1+JF70abuLUKEV dRdxNWbu/A7MP3lIgAaeYlQTi4OfAHT31RDKwZ9o5KhPdApyMFTm+/f7BvKzhDmynaQsSMyVXK7g YOuosd73zUm9vpw/I7NvSdLC899mZnpkW1TCmEwhzJQYlpOddJ1Iu0870xd4k6bEOJO8JRMSbXJG 32Xe7S6bWZnC6m6JS3J5P5hdEca/vg05eJBu5N99gheVuQ51hxwK54BDScqLdEyyTM3X2qOpIz7C Hm11xEfao4nDqbNHWxxOq4VSoo2IpJyjkVrOvEiBD42M19VqG7QdWubTkkxthbZGyyZq27VHtUwr 8G5alcfaNt+vu/hYzHiVWFU4Jsm1jgZHh4NlOiocNQ7W7jjqoJOO46HBY6KeG091Xd28wOFRHxZ5 VOby1BXm+P0E+FkYxh+RhVlQ3aPuoTd2H8gc444wBtlTMzNpadZod6QxSPZkulyuLHkJmzPdEWmN UPNd96p5rmUGoX6/EfW7AaKhRcm637pF80zQM2bhBrJYs4Ks1Aj9tcYkYGFJki6iyM4yGAVmZvwx psJENjiWy3lUcZ4cq8TSWEuRWSfrqEln11Hd4JiASuaHf5i5zvOzXwv0PF3MJtH8KWKUO8QdbLCk YQAQkUZCNZgLFzFnDjKmkUiKiVUblgY2ARPPRcbQcwupriYyP/oOnhbkc61kUR8hWi3mRDftJFpy m3eJ91vvae9txw/+sudPq+68fufBc6v+hNp3rvdd7xveGRjsFpH+b7YMXrHF+7x3186VJIWUkGu2 reS8GeA7JYjinSg9abS8haq+rjtDlaJkKULVeapcBHQhyLHhQbw2XC+3+c4qFquVjpUNXAZktTfW /qqox1CO4CPkmP3sM4j1te/RYSnWbm1jnynmEEUXTMeGhILLpdOkpjLIQI4Vf+LpzECQDPXe2z/x vGxu5/nDKBzRAT98lBVHoQPBGB8aUxtLlNga3Ba7HqfRh6M+kMaGC2azxFcYyqmMAosp5S2ynJGe rPZRb04aK0kZ6XjWMzyHPSrByx72ePgGflJdfRj9G1th8Sd4/eh9kOFr3zlwYG4Gl4Z+nvTcmoyl wlKxUWjI2JHRnqFRMhoyKGSEp4R5xopjtWM8GzSaQRoiZxQEDQwaF/SA8HRKU4amPeOMh8oyyI79 vg7QY8xTWiSPkK+VpwXNkZfIm2CTvFWzT/Nqit6tDUk0lFjjQgaExSaGl8TExQ6w4zC9kBqmcs2e SlJT7UxvB73DgB75dMUaVhPeEL4jnNnD14fT8G+TKyRc686k9FxO92Jk1D+9f33Aeg3r7J7HP8jh Lx70zMNbttgKzeoTW/ATVYSj3B5Bm+hya5Nl8AiYJGlcMkkRU+Ue74Fbr174Uv1rgi6Ex1NVhTG0 6rxZ0Wfwu2yaRP/jXzzfNtGZZ0mn6snmLjZ9rX/DkA0dv/5l8QiTHBHlMRJLmskRHp2m955Jl4qm ZFSWXt085+rpZVedf+UVMnDYM48OijI7a89/8tjAGIuz7hD5cEBt4YgZf339A9SHV6FYm1Ciw8hd fnneBzbfz0osl85Qg/qNf54lqh4jksGAqaHN96OqyDDzzS5ehZnPdvF+mHl/F5dkzJzYzccYxD+j SGsRGghBadaHhCo6PnkYVmSgFGd3mjt7pBilCcX4ZfOrF8lwYoiVC2aoKp4hOAxAQ1SpJJRXEVVi +aLO7OJlzJzdxat4zV7ez2CwhQfklV8Ar6pKKe5G9N71tnbbGYyt+N4Xl+VyqvQu7JNLbK3GqfkV NqLYKmw1tloMwJqwo8aQHKcZEk+S46REZ2iisSQkLnQALkkjBQFJMBoC0xhUJZjXJ3e9gVQYSI2h 1rDe0GQ4YxANreGtT6hBNP9Eqajbr9MvPPlHi1lHuJyQeVVVRBUAVPLZqpEMiAW5KTJ3oLe4OD0q 2B4RlWQhFvHO8yXjesUmJEQVjWXKwwP5bnNbZwGQMtkOGM/eCegqW5XCVVCVavFsFnVrLWOHZvpZ Rsdm8g3l28drFBPf40yP2suTVVDW06uspxevURy8V1nJwBK1X4kqKCWqoJQMDeVXG9ozDjM/q1Iy tGcCzPymRPK+Q4P4NEM96nCPOtxTwD/11POKAjMfhuV3FT0fVxDDJ8byN4qddy2gartqmQss6hwW dQ4LatjT/jnkzIDGfck/h5yiauM238eKnneVaaC9C2WUa+jwyIzs0kFcA8sDx4xVeJ+MsWTE2Llj 68eyseOkgVkRrlS9pihV1Kg2LCMjg+tBz2Fzdzt/BWRaFbp/zgZEHVOUd49KX0XKLXuP5Bfh9Di7 XiNqxowdp4nIGmhRJd4iqypb9khczD1qnaegRC2VqKWSoXgf3+z1K/HKAu548Go1w3th5ke1taCg Evfge7VyaM8JwsyvauvQoVWVgYNjuZCaceUq8BZAvefDxcX8mSZKb7OxfEzlQSjznYZSRAYi03d6 d1REZERERC//qypaicnVHK36IZw1oIhX1Rir81GHra8islZOjotoo1274guS47Iwo+jjhybHDRwS b0mOs7Wx4F1OT3JcZhsz7nKWJMeVYUbp6xybOKxkTNzYAdrkgmFKYXKSFjSugePG841xpRqC9BpJ EDUDy7IyI2xBVTZbFIadjkyZ1MrN/MMLkqeYCpLTPQm9MgtIbUFzAS3gdeHDxpckDB1qH1YxjDYM Wz+MwjDzMDoMz/We0PDcYTWVVW10wk7HU/URbWTqco9nOMaZ3E9Dp9h8FjPdp/ykaHjpdQO+xEPO X8Xqv2H8+W9RT/zf86mf361DExIaj4650eV0JxgcMSTYFB/sikGVYC7yx53zoNqDtgO1A/8Qnj/m 9afhqtenqgs16Ay41fGSRmP7XY9cqNZImku1S2KP1SEVU61pM3LGLQ2bfmf54DpHuDEo/ypvUUgf hy1IiE4clzd7KKVhvcu8WUML9aIjdUR+3ui0yKxyb5/i7CidJi4qJtFEQj30u6kmd8rUiTeWl4/t vdS7aJwcbk9IsJmdlgrSWJuu5A3Se7zl16ZjZUKCZRTWZSmxqQXesAn50QkJ0X3GkmvvT3VEmhJq 0e8q9Z1i+1CTmSCWGgK6LAbNk2ppVP/JoMY2BrNej2mUwFUOb+QZJYRXCmo3webS6s0u8J9Y9YQe Vg8k91p6Hl7ydt4vig+O5gchSghVLU6owaxaFrNqVgRVP/GsIMQZDPY4flbUI8KPN56RgGsbrZRa G8LI0+F7wl8hh3Qvx36kk6xfBZFButLw8WHLyRrdKtNH0Rq7kp0n2PvjcdhkJ6+GHYqiip0M1vas xipwo+Kx6otHCEQRyFGeVgg1Qq2wXmgWJOE7g4KNimGTgRr6x/UvV32Xeei7VHNbU96cNLq8uWLk hBZD3OAWuzB41ITKP4PB1w4Cwu5r50ezf+XzEMWyQYBQlv21+evoi4ootVW/++r5JNbqCnZTV4w7 yCW5LaZQGWJJlEzCdZiL0GAuxGiWSTTDJExvkyFSxOQSf5177PMIt4N1aPf6VyqWhXShtCRoSfAS 643hCyMWxmirqwIfeehizJbCaEQYMr1FX8hnqsJDkO3/2CPwSBI9fv4c0hp4Dknh6M2zFx2pP7Jk +rI3R+fN7rfp1kk3zxzIdmxcseOmrobNq5+9+dwNJcUbl/7Ve6LpL2fX1HCrSVHWutm94KKZAUkL T1StpjbgCunlpIDl6ApYlriA5TilhKiWJUrtGGVVrZTVr3TVzG+q+cPM2d28ozWBu/s2tDDBES5J LwdHSLGpwXoNBojtu3kEoA0C9PHRsy62Fhaikv3Ob1MO+40I9/kvcpTGaxSMPGsx6AzSy/qI4ASX DWf1T6knWtVXCvL7Sqr3JEepnlOUakyiglQ5t2q1blmrhgCS33q4rdzb412s3HzzJp5R7YPVmui+ 2D5gwi2Dah487VxYis2HzYf5U060jPyIKXkkkSt8ObEmsTaxOVHI1RfYe8uD7INkMUobMiIuItHp GBHnSnRqE0mJJk47QNa7YrVtpFQJCUJPPjJSvZ/gIH2QXu9QHflgaCbERGrJJnKECKSN/llxWSOj EqzWipD1IbQBk+YQ5v8cqTmkPeRoiBRS437J79pf0Nn8iwDo36tfyFAfSqkfafKVX/DNUOrN0TEm S4wpKgbMlmhzbAyoeln9ZKja0+Ow+T121aN3q26bJo8/9+BPPbCUmMemoLduTwz2fp+2aGnpsLrU mIJBpKSq2HN9eeEEdm/3e5tUP/2lhn5VaxrIgyXZ0cTV/XBDRf5QqhleQF3AUB9+Kh7FGN2EkWgJ yVBci6yLbPUZ9dlL8sSB2VVJY1Ores1MmpY2s9fCsNrM2qzlGfoRWrSb/RVD1sSsuVn1WSyrMKdv GxunhMrxDkdOiZzrmgGF5kK5MLNQKGxjYzCoLQOWXmbKsedk5BTnCDlqZUSZVpf5QFa+nB//ADiI o42kKdGCp8WUb8/PyC/OF/K/NMSUNaFCahfOCILQxpyKMbSswlCDWqmhn/+LWdWd3dWd5rN++D++ wIyanFWfKZn51+KqM06pTO9N7H5VE+cOV5VNlAvVzQKwk5gFxKbDXKQGc6huFpBYhkmYPmIBRIuY XKZuUOGoD6WyBWtYKBWc8QmUP6i1xQv8+a2Qk51gzculCbbAQ11N4DONAhvuJeTlQs+HqgUsaCcZ c/B573Ntbd4dzx8kY1qf8L7+3DaSu2ULydv2nPf1A6GJCY/+aVRDclzSnvv+stC1+uxfvedIxMfp Vw2PNJjD9eLsvd5t+9q8zx04QEa17SNj9161xXvomS3eN7dvx1meIQVb2r2nb1g4oNBz54h3Dz0e 8gZh+9qJyRCltcT4f+aDAURvPbd7oqnoJ22kVv2jjcc/j32J033v7U46v6B7jRm0wVjUYX//D4Pw n8VweEthvBnOL/C6zb//YEjgJTVKhfz7of4fD1GxFU6xAbBcAHAh5khbYZBUCOWkDkZi2xhEOtbf JdyGGhPgT1gejfQuWggM64cgziBSEaMRMmIyohIxFLEUMRL7NiPu5HP0gK2FazTXwiTxNTCL4yAe MQTzTuFzSBHmgwPzg3gZr5fDYiEF8/HYlqyJxb6v+b7g7dgvXu03DsfNhwZs74tlPcKqWYsi8hqY ECFYH4XzbOFrRlrOXuT36vsB84twHYMxfx5pGa51ANKhWD8C81chjDimiBb6pmDegvmrkDcWzBsQ pTjuHB+D/Y24xqnYHoplyvvidY1Io3lfnDOZfUCiyUPwGPsAWoQxEIrtwSrwvvk999wTXz9f079B GV/fxfCvTwVfK/19bf8EehmuYznqXt0SuNdH6GGoZU2+HzHvlEKhlEPzAcTh/X2HKBSm4lGM9Z3G NQ4Wd0EelrWICBV8zkfgDnYWFGzzSBtQbqZCX5qFDXm+3+hNECu5YCDeL/IbEnHtVVz2UBYSsN9o dfxUiBO+gCjMKxwo9V9e4BPyBve+HGl/5Pv3WvB14hz9OXCefYgXcbwNr5/BecD3nYzzbsO+X2Pb DYj5KCORCBu2r1ZlGMfw8XidEn4N/z6AWZVBBJc9RHYPAvvTA30PVP5vVRGOsCEKEPy6GxAHEMMR 9/I+OG849o/DddzMZYbLJpcPLhuq/KM8qTLL93E+8obLmP/MbKbTYCUiFJEqAdwRQAr2Vc8L30e+ Zn4W+NxctrjM9FBsd/vlnvzA75PL1EXUKaaq11bPIJeti2gyl31OmaLeQzJth3wus35e91B1DaX8 PPIz0UN71sPPp3pGkLLZEMJ5x/e9h/bw4gJtAhe2DRU/goFCFoxnr6D8X4P5CqQFyJ+N6hn8QbgP TtHlQDXtkIp7yc/ug5fRBzg075FZOF878tItHIYHVfoejRfeI6K4zfe1uI3e7EdP/mJ6OUi7v41T jovb/tv6/xvQ98VtMA3z34jv+XzCe3A3txKab0kmQu6hWN+KaECkaD3kAe1s0qYZC2aUm7OIuYIC vUUFCgT054Qw9dy5sH4szp0hzIY+OI6RdljFxsLj0jbIZe/hPuK16PtwGwefH2ntBTm6XOb+WZZU 2iOv/4LyM2DsoeqZKvSdUM9Voe+keiYLfV4/hUJuG7h+Vu0DqLrZ0iOvF+TyUXCzny6Sz8vk9CL5 7IPjzJfL5UU0mNOAbTH2nFMcE85tDb9/VT+OU8+TquewrbWn/+X0wvit0Ea3+o6pevgwTOg514gs hAvb/xLQI6iHcb+5zVzru0a6wXcNG+K7Bu9zj7QC6Y++nTTR13LBprogO6DLonpsKeeTeBhiLthR F4wI6DMXt6fCFrThfjsaotrPryBC/FHVbdnqevk55GcwA/VeItrxn32/CVb4E1uFLgueS16PMjKS twlaCGOfos4dAgvYRt877C5VB5UyL1QxD55hHIs8ixApxIgDoBzHgDof74OU1/H1SwLKJ9cFg7CM e9Wjl/neS7+BEZEofo/6aBz22areq0vV4w9AAueDOnYh2hWcS+MBq0DBE+jjUsdcj/6Cyg/UgRfx ImCb+/I5pVGqzJrUMTm+37RWKOQQn4J8vL5LvdYg6K0tBLc4zve96ldYYTh7DTLZILBjPkqV+xVo o5LRXg5C+4hgnyO8KJtmf1m11Sr1nVPtfb1qzw1iBoxX/QneJkGclAzpHIIT22ogjT2F88xFufoN 88/5fKp/8AlY+LWxvizgn3A/garn5W0cdwjS+Bnja1DtDV/PQyhvR8DObaLmceRhED+DhCC/YwJ2 0IplinTdRVgfqIvxU+KgH8E4tW0MdNAX6A76gm829wPZxzCRPYn7twMcbALa71fQNvZBGz4EeXUU KtlbmI/H+o2IRej7LQCTYIKpGEgPp9nYVovjDuMcj2M7xx045jjS5+Aq9jrMZO3oH3zGfQRwCAuR ViMGQH+yHWbTczBbykeb3Mf3qDo/xwLf1SoeR7v5WWBsAOpae/Cv1rwYfbt/sV51rRevk6/xX6yP z8HnVcdhH0HAiA98xxEuP/WOpGthG6KJfox9h8FissW3nzwCZeQLxCMBPAuDVNqCGIlnLI8sRaQL ebAXcQvmU5G+gNjhL8NDiGOI5Tj3i0h3SuoPJBCg/VCekWLdRsQDiDd62i4Gv9a/qr8YYrRv/yXl 3WhrEOQs3sPZS9vUa94C+Xi9fOEq334O9jXaEIRUD6GaRRDKErE+DsddVhajUc/thoQ/Ws8fgRyB TJWHfij/yT3+p+Bnl9vn/635/lPg/tYjqtU1fI/6WJUhCCbv+44jHUfeR7u9EHUpAstpWA7p4WfP PmH9PWr9ZfuHsoJhqu+Xy+svL1++r39Upjth4sXokYML8nA39OUQirE/4vKy9hD05ZBewbZX/rks PP0HmIA+ykN8TSiDif9clkZAIgdNwLVG8TF45hAXykdQryJ4X3W8Ee0lQj27CLoLbTHiQnse6nzE RXzN53xlD/nbe/anZ18u3x9cnyK8hZiA/uxbkIl0NNKSHnpBvgP64hKZH+mX9wtlrku+uKzP72fi 97OBZ+Xfzfn/EvDsvI54DfHq/9/XIoCyijAjVB+1D8bgeeh7juOParrfBOgKRRqCdgFPXlcH5t/F /GT+K5WY34t1DyBdiRRVTZcX631oRxjSjUIU+u8AKxE4h7fWP7b7Z8QN/jm6DwCc/zCABf7xXWsQ ZdiGnlnXLsQWxHOIATimZ567sFyH9C9YHuifqwvz3Z8iViDKEff7aVcjgrfr8BofcH/kX8Sh/6v0 38Uf/ykNxBlFPfSfYoj/hvb5j+glMUfP/v8R7Ykl/gVV+RBYv3TRev5djHMJRfnRXQz0pZ3cp+R+ NPdluf/M/ccLlMdtg1QaEpinh5q4DeS+M/dfxRz1eSOPgTwXxYOlPXbjYt1KzsJGhBkRHaCzsc85 jHXeQttkQp36E97fkxyqbeN2DYHrPaK2v+87yPsgPYzlWKQ/9di0Ht36Tzr2D2za/3b5v7WR/xc2 NTuAiZfh39X3oFcAgzkut8X/Lf7Idv9f2/J/Y6MvttP/X8s9dr4Hf+SX/pMf8AflP5rvvy1f7nf8 1+XL/JKe8uX4p/bLZa/Hn4nCGLgHl527/xY8thB2/+7796zh8nN84bz1xAj1aFMvAuqBJLRZyYjH UV9kImIRVsTdWHeztguytc9CNpZ3I/ZgXSfSqbwN6Sb+6xL0Z183lm/Fslk4rPatDGDqH8nz5XLL /XPVP0SeqXpwPV8/ZCD6IKyIFsT1PXvNY0+89lf0eQAe5woTfD8JbyEu8wH/kOZBHeJZLJuwbAp8 YLTo34M+98dg6IewGsTfAERU7/y30zRtALoNAEHoSxhy0QRgv+AnAcxYb+37nyEE+4alAIR3XYqI uH+NyN7/+4gx/M+IxXuNb/XDFfevkfjS/ztIfvkKruAKruAKruAKruAKruAKruAKruAKruAKruAK ruAKruAK/h8C4X9ZBD9CESwCDVAwQwb/9F183RQCDOh+GONrZ5/uLC3NVtqQetJV2pqUnL2PN7RG xWT/mX1Kt0Mi/0tVdrI1PFptOdHar18gk9/Ln9mZkpZ9siSInYAfEJSdYCchyT9qZ1J69pkSI1YQ djOYCAE7NLFPoBlBQWEf70xwZ286yN7E9tfZIZiqDjvUarRk44Svsb1gBTvbw3YHWnbvDLZkQ8l8 thZvsB3To4gOxBmEAHPZ01CPWIfYgRDAhKkdkYEYwWvYNrYN17kZx5swzUDMRaxDCDCGbcX62Txl W9gsiMexa9i9EIZ0NbtHpU8ijUL6ONbHIX0My5xuCpQfRsrbHwrUP4jlcKQPBOj9WB+NdIP638DZ 2X2B8iK2UB23IECb2PzWOLu5JA7bZUQmgmHuXszdi6y7l/85GqaE3cbmqFdqQZqN9Ho/RXYta3U4 1T1attMWmd2ELF2GrF+GnFuGnFvG/w6ZLe3ps9TfJ40txT5Lsc9S7LMUuZLJ5uP15vMvnmBqRsgI hnyfj3yfr/4s/HzsPx/78/rbMV2PaOIldgPyMRlXtYrNak2yo5BN31moZBcfYNOQ1QqbtjMyNnvd 7yVdEBdEpMEBauJ9r1Nbr9upM/Da63ZGxfop9ppdEsymwE0ICqGYJiByEQMQApvSmpBh38+Gw/Va UILt9bSe1Qv1opA5gFgPsmyo0AKKpJWlQRF2SLZPLCIFNbpaXYOO8Z9RytQpugqdOJfVs3WM8Z9e KmYj2EQmtvnaWzW9c/jfhw+Ueues1zfpm/Xt+qN6sVlql45KHdIZSZSlTEmRKqQaqVZqkNZLTZJu vbReQ2v0tfoGPTPrZX2mXtFX6EW7hjSVLGeT+bHF1IyoRaxHCMjjiVgvs2sRE3E3JiIrruXfXsUU sGRGHMV8B1IRSybsZ8J+Jqw1Ya0J+P88YVJbKhA1iNpAq3ShpWcM73+GtyD4l/+DsTYYeduB6Rme QwzBkhFLRiwZsddR2oUrNGMqIyoQTK3rQKDUYNrTlhlor0FIavsZtU9Pm8LH0i5lUmJ7MmlOJk3J ZH0yUYqKS7KVeEysVutE50TXxKSJm4W5zrmuuUlzNwsjnCNcI5JGbBaKncWu4qTizUKGM8OVkZSx WbA77S57kn2zsG7ojqEHhx4ZKkwcOndo/VBWwH83ptWTma3SeBenu1sjo7ILTCV96A68nYmYbkKc RDCwY5qBKEbMRQh0B6Z2+izWPou1z8IIxESEiCOe5eoFU3ugjddvUtt4jrfTS9oZ3vj21t45I0qG oMqdiNiEYDj3dmzfrvb253ao9c2Ydqj1IwL9m9R6O6Y9YxgquAmqmpuAx28CFCMmImoRIhxh4+Ek AmfG1I6oRexACGwCvsez8fRZfG+n21mqYswKs0N4OABYLVpziZkaUAaMZIuaPqCmq9S0WE0TlOAh xp+HGF8YYrxjiDERMzQJSrDhXjV1KPoS464S44gSY3KJEWezgQOMNExNJZ6Sb9V0uJqmKqEO4zmH 8R8O498dxkcdxjqH8SoHHxeDZ9dIQ9VUz1OyQU2HqKlb0duNr9qN4+3GAruxxEg2Erw69FPTODWN 5in5cZdpgAl0B8iPMABnIq1FyfY2CiohvtaiEiTe1qKBSLpbizYi+a216B778+QcUU0a+bk14ZS9 JIycJYMFXv5HgP6dDIZtSM8gnY70KSgiLqRPthbdwvs/geMfwvLjEK/l/R+DCnXcJjJYrX80MO6R 1tTJeNWHW1MX41UfglT1qve3pp7C2ntaU1chubs1dQ6Sda0uvsBZrUUp9hILmQ4JlPedAi7KVzI0 cMVBOPMcpAP9g0tbU/moAfwCbaR/qzMLSSJf5fPECRXq5eytTvUmY8GpThEDTnXR0eBSaTAxqYs3 QrxKta3OW3AWaZfrlP2XogP8xuEnYmrdaP/8eby/cVj8jAxu3WZ/ex9nV6v9SGobce2xv+U8YH8l oY2Ma7W3p7ZpseFgahslu+0tyORm7EvJHvuO1On2Z51q62YntuJWbypKsz/snGB/0IXlVvstqc/z ZcD1eMfjsLkqta99aNE2e5mrjWCzUoQXU4LsvZ3z7IVY3auNDN65zZ6V0MaXkolzbNtjT8Erup3q UsYW7Kd5oCELlVTNAs1kzTjNSE0fTY4mTSNrYjUxmlCtVWvWBmsN2iCtVitpBS3VgjZU/dVo/jff oZL6p9+SwFNBzZup+uMX/j8Sp0RL8ew0h7ByWj66H2m2lkP5mH7NBZ7yNo1vVHMvT3mztuLqyhZC 7qzCUjNd2UZgTCUKKK9aHs3/k7N9QEjG8rXRnC5dvraqipQ3t0+B8sly88+j8T6CRk5oFp39IiB8 UXFEsbWvpbBswL9IagLpRX/FH3Hxn/R7ImKbN5SPrmzeGlvVnM0zvtiq8uaB/L9H20fr6NzSAfto LSdVlfvIElpXOorXkyUDqi50g3hai92giBPebSfE824QT3aq3Yaq3VBM40sHtMTH+zu9RAbzTig+ L6mdpvvnSsBL4FwVnGA3GgcJ6lwJNI53Q3nwT2a6eDIDEJM6mckA6mQxvFOLy4VdUl28S0uBCzu0 uArU5m2/Nztd/uVUgUu9jotUqdch5Pc+Sf4+KAWBPlSLfTz/m6/r+v0XncnOScenTuH/SV2Ns/Q6 RE3z6v/T1vW7tg2E0ZMVl5D0h5tCEXixT9DlMBSHQCFHq59dBKXUHaQSqBXFJZlSOF3HuNCpU4b+ AR4KplukGErxkqFblwzdSrZuXTp069T3SSYl4EPve+h70j0h3UmavnuzbxVvdzudcu9isXrdveFu tk+cjooLexQUe3bQKdNsiZyRnNpBybLweVxmzig4TZ00tNMgmU3HfnTF6/2llz9e0tmYOvPJaxot kSOSp+QVkVdEXlNnWnlFzzwjehqXq8xL/J2aZ431NcyHYbubeHdbrx9Wk2O7ax215ysMn611kRTX ba+4AZDUc3suSZidJN2kZQgXknW03W3PjU8LqYX0bdtjglnhQXC5KaVygtYCMddWlcsxabuDqHhM i6bJQoaFMwySqjyGXjQ/dlpn8lw2DuVYHsuJPJFNrROkN874OW+85Id8zI/5hJ/wayTsxJ8dOeG/ uakxmowcLQwqTw3GRru5VtQYDBRQ2wkt/NjlLDNpaRMT8Q5gA5vAAGiyr4jfgZ/AH2CFvUP8AHwE ZpQxe2YvtA4CckwEvXQssz+7v9V/8AWcvqp58KLm8EnN0u1b4NNHm2vuLfx4G2yO+A34AfwC/gJN s2/2q851PWoTxZQwcPlUWKSqLqJEbgiq7Ei3O1dCMAINcDyBqo7f1XHPDKUZbgUeCAgHVVlFp2ni /wf+A3dO2VsNZW5kc3RyZWFtDWVuZG9iag05MCAwIG9iag08PCAvSGVpZ2h0IDExNyAvQml0c1Bl ckNvbXBvbmVudCA4IC9TdWJ0eXBlIC9JbWFnZSAvTGVuZ3RoIDQ2IC9XaWR0aCAxNzMgL1R5cGUg L1hPYmplY3QgL0ZpbHRlciAvRmxhdGVEZWNvZGUgL0NvbG9yU3BhY2UgNSAwIFINPj4Nc3RyZWFt Cmje7MExAQAAAMKg9U9tDB+gAAAAAAAAAAAAAAAAAAAAAAAAAOBgAgwATxEAAQoNZW5kc3RyZWFt DWVuZG9iag05MSAwIG9iag08PCAvU3VidHlwZSAvVHlwZTFDIC9GaWx0ZXIgL0ZsYXRlRGVjb2Rl IC9MZW5ndGggMTI1DT4+DXN0cmVhbQpo3mJkYGFkYGRkFHHy8/F09dR2LMpMzNF1ys9J8Q0BiUv+ kOYR/SHDI/aX4w+PDPuFX22sTwX7vvMLMTAxMvJJ6bsFh1QWpCoYKKSkpqHoZQApkJT52fSTVewn 65+Ov6zss398Ff2R8efpnww2vu+r+Lq72QACDABqxSi8Cg1lbmRzdHJlYW0NZW5kb2JqDTkyIDAg b2JqDTw8IC9GaWx0ZXIgL0ZsYXRlRGVjb2RlIC9MZW5ndGggMTUzMw0+Pg1zdHJlYW0KSImMF9lu 20bw3V+xj1zAIrgnycfWKFAUDRqgSl/iPDASTRKhZEEmbShf37mWkmLngADuzs6xM7Nzaf3XzR/r m9/XN0VeFJVX6w3uQlGq9cuNyY13av33jYGzShXw411weV3Z0gJY59552K13Nx+zO13lPnuvTYTl g/YFLOqoVybkMWu1dQA/MfZROwvLzIdA4wqg2TAIpB6WW9XwZi8itoxWBNbZxNj++gKFpybbNQzu G1Kqa7UzsO5a7csLkSJDPbA+olbSWe1E6O4bxEkHtEI1Yo564VXIxxExbL/+pNaLl9nBtvSLf833 HFzbStVlXhtrS3Zv32gTUAXrs60CZ/hs0KsKXFplX3JtbKZ+0wwqIkVXCH2LMGLmEVkmUDe7BWOA Z4MoOn1E+nmLJ5GBHR4f5gmXAU/3nfpojLYx+8R37LfqT/ANa9IhT39tMtjjKjL3O0ZWMXcVxBMb +R50bM92PoBDWRWGSSG+mGBSvkXN1N2Fxng6awyRRXE86sgrH429JW8ZZHB6VUC8fMKXM5m6z8gc VOPuXqvufDXdup2bxV30OWkP7p5YLfh8gUCrITgVubgX57s6+9Yr4BaMBpNHeuC3/UNZVvq8iiU6 ER3UHA4YWU5iseSYddnhiCHosoEC32VTy6t6ZvyAkX7mmjTKmBnXjIL9mpiHR4xwJ3lScihNLVNt mKgnEUBRnrUYZe2E78RicohM0m4knonl9NcWzITr2DoWfnaaYc+oFSR3bZ3HTVH4UKnNDj0Kj1iY UEoFqyty6SqYvCjfTDFnQGsf0c9Vncfoisj+fYZ6gd5agY0lVaaa3MXwTNhGoDGRfU0nUzp5JMK9 QArCqRkT1xXJCzvmid2opl5ubNUTY3ohb3TJ70foIYnumEqxtAf6XkqZrxTZyoopdhENSaVTihUG 9yKlY6kHWpJooRXFE8sG06k8e2hxwHX0W+k1AbPgB63m4pnKCohMlDqxw/Rq8LPREZQaIGyyvWQa 5ixtnzCXHzFFZwTJXGAA0jMaar/1THRUW5LzgAB80E8AHum7p4xW/yHPO/w8QWxnXEl2SNCgyP1J lzZlPwtF8XJ86QWKWF+zH4wP9Y97woUnYsyjqY20BUj8FdYKMKGGCvaZvuh3C2ftTjbwTDEX3+Cz Vohst0qbgoLbLgIUS4AIQUD4Hq+kPgsFvm2NMWU8yr7PZCdMs4AbjRW2T2TNohKYBFfcCeI9c32Q 4/laWNMJ3N6qZBTruFvUd1jCj2Ldia15VXaj1IjLLvwTh4cAJaUsnYQeFcnIo0WU0SLKaBGlZHou chAgnMeRpxqZcSIVu5gdGTVMVCeRuGX0pIszbQ4WgcB7TfcJxBU18ov2cidV0piuVoNcLQvfKeoq oU3qcp+I3CeiVIbFCmh7xDUOX1mnRhBDEoMlbqChJ77hdPa5c292ugtPe5eHMtpaJh5QIpJRUCYh w9REezVQpz/g/ngmQQNoAuP6Z9BUSGGIr4qGUhpJIa4mmldGmp/QGrCF2h3bQBcNk0wyVTYl/yZx 3TfXMsOeDgj32vogxS4N1t+3H3xZBI8MaD+/TeA2HbLdZ14pRnBCquDL7xigXMEDBRznCCmnR5Gw jNSoLcA98Q5CzJBCwMojniU1uiAVkIQCaVFgy2yiFYQwzcxTv9wJ+QD4Se4UlVYUxaPIeOalJVHj 6wIZpFG4WKROYeqfpKuFDlQGJ+k6cBfzVKcCDekrnMwP1+BrKk5yOZ4UNTpPxSxKEwSqLQ7UwZ0Z joKhsoV/EVKCJcGpOQOHOrTkjMSzabmNeppCIOC2/F/HZF1DVY21pn8sn5mClZ+E7YV1bNuk9hsd x0n9K8wvtF4XVYA/eTbAiM7uJO1xDpDWgsPdq4gvU1uz2MzeiHgLM3LpjFW+xlusl4j/R9Nfuxlm HWzX+IWEK7m6G2wDo6amo/jvD+33TDcx1BMEUcxz+IHAhqd8BiAw41n8QgnFJeDl8NeKqUjcE2s0 sICOtZAbG9HlX6Y5Mf8O/zViQ5r4BsqyTL1LppGEUbQdVuA79b8AAwBGFF3NDWVuZHN0cmVhbQ1l bmRvYmoNOTMgMCBvYmoNPDwgL1N1YnR5cGUgL1R5cGUxQyAvRmlsdGVyIC9GbGF0ZURlY29kZSAv TGVuZ3RoIDExMzI4DT4+DXN0cmVhbQpo3qx5CZQc1ZVlSSgzgsVpA05cFSFHCIMMtpFZtCAwBiEa cINsCYSEQAKtVaVS7bnvGfuSyiW23PfMWlVV2gUCCWFkwIAFmDY0bnuGPuOl3WaaYbp9piPlKNzz IyVsc7pn6578p6KiKiPiv//fe/fd+2JBx6KFHQsWLLh67ffW/eW673zjvp2Duxx9O7+707XX/Pf1 rXuvsLfWXnHN4t9/e/E/71x8+YrFVyyz6O9+vnX5F1o3X6ktXr30qo4bFyywXv4FO4Jdd+Oy21Z9 a839D61/7Imnd+8ddHiCUVqIS+lCdWz64LGTr/y4d/nK5ct7b1296jbzcAc43HZH7/JVt93ee8cq 8P8Vq28zD6vNwwpwuOOO3pUrzEvBBbeuXgH+v7p9+8qV5p+3mH+ah/YlK8xLVt1qfrvKPFthnt3e u3L1rb3Ll9+xunflqlt6V94Bvlq1alXvypXgybev6l2+4tb2A8w7lpt3rDAPy82nrGjPYZ4tX33z Axsf8490L1m9ZE93z59vUccCMDouXdBxxYKOKxd2fHlhx1c6Oq5f2HHjwo5lizqWL+pY09Gx9tKO 73Z0rL+k4zFrx7aFHf6OBfzSBVcuAdv2jQW3LLxr4b0d9y18cOG6RY8u2t6x89KBjqFLnNbgQraj 42ngmY6fd3yw4CsLuhcQC04tfGjhyUt2XBK8RLnk4KLli16zxKx/AVmhv4e3wv/l0h9clrn87stb V/zz596xbf78TZ9//vM//EL9yuGrPnf1gqtLX9xkf+2a179085ekL/2ua2FXChHQvsUPLz715dCX 57EU/sSSa5a8sOS1a0eula794CsPX3fpdcp1les/d/3q61+5/m+XXrN0z9KPvtp7w903/OBG9Wv3 ff3qr//6G1tu2nXTu8vcy3627DffVG+++uZNN398y4ZbPLcuuu3y5Xct/6cVZ1euW/nG2/p/1il7 EtL2q3EZiytJOSmnlJSiKLKiaulMIZ/NpbNaRs3IaTmdSifScDIdz2SRvJjlMhifpdOkSqoRJSjB qaA36Ubdbp524y7GQ/lIeN3zUDKd1FJqSpUUGXwUcAonFS2eQasFNpzBMxHJ50SiMVKgMJHkaZ7i adYcDEMzdDRCEeA3xdE8KzACE2PhGLufZRACIjfZ73rnZ5Cx2cDtrXdb8Py70Pyd5xfYP/lma+D8 NyHbvNVm3Kd7W2X74Xd/cPr9sciRzpscax/bshrestpxg3EZYlw2dsOZ1diZ1e9u+tCRPdK5Zmzj 6Z734N73fL/VrYi+sPJ3h97FzGds2GvvuXfjk2sc2e7OD8fefenMB/CZD8Y+1i9D9MscH2/5ANvy wdqzN41Fujvfd7z85KG18KG1lVuMhYhh9S3rvRez6beeX6XL9nNGRT/4gHHQqDykV4y5H+tzwEj7 Od1iTzrjTgfiFL1CEBOCbJiJ0NFoOBgcH+ycbjSrpUqpkq2oZVitpGoNpC40+Dpm6209+J/sh1+t /EKHEH2R/4O9Z7GzfZsn7kMHhpjICD4Sdnl8w76hUC+5HSZ2cI+vR4xFpdsPbsQem3tx+B30J2en Xz2MG83W1fbUIWVaG9PGspVCHs4Vy0oDHauR3hJe9uT2pZ+C09uk9WuQr5FrfU9h23xDrt3oroGx 0z7c+wL5N/8DOZk4njoEzNF/0zpu/0H8mcQBbMRq+IzFte6pSqNQzXRlKgUpjWqKwKZwiU2QEWR+ CeQWAzyJCSRL0xzFEnxQCAmjYm8M7tU/OQQ5PIl4CA8lIkkySaboFCezsqCKaVjQYoUyAmZb/jf2 qdMnX379zcNHxycKpUIpV8oVs8V0QckrBTmfzMOpQrxYQs6EjgxMYOMDT+XWo8ODPL0X76N7wnv8 8LJXobdrx2dfQ5tVjijhRTIbUnyw6kt5HEhIDPEhjA+xAQqMsNfvCrqHB3p2bn+yb6er17nXtze8 F3a1vgqp+nWWXVY2yBMCA2KXZXmWowVShEUqEguiNn35+dV++3vQ/IQeaIEfCwjSj4265QHoQlTo 9h/Nf/Qw1PrI2G4/N//RQ1D7Dj1l/zG4Tq9b1kKtCSMwD34s90K22dbvr2lCoRQhUSqt0Gk2z+aY CjNu3Nk63vltq7F9/nCkLzIa8XeFfUHSL8BOfU8T8iZDMqnBpMblqwjI3WQOS2TlstosnerUfdby ulQwFU5GuhKRRJRAoiLFMxjPgHWABUWBX2AndE/rfftvjLctxg6rbaT1rfO32ZOO4fgQumFLeGgH vmO4f5f7cdi9mfjeA4hxSe32ZzZiG0+8PvwBeuRQIjWDz6QOyAc0WMefhMh+whkNEIFwNMDAdMDN j6B7h7INB+5s+OeiJ+HISfalHyFvqGcLz2KFk9W58Tpcn5jOzKKNisAU8SKdj2aD2UDapQzDp3XU 2q8NyY4kbPuJHo3bzz6TlGbxWXlKG8tNF8ertbHmZPlQ7jicPaGcPou8xDwfOYqFj3pnR8ZHJvZV 9+Tg/O4nlO+iRp/TWuAygszLgsSluCSbpBMkHCfjARcyfyfkjgViJCYSIs1zwL88yzMCyYd4sDH6 184vtMcrtXgDPXWc9B3E57wTA5WdcGVHetNfIvvEQX4Y44cZB+2mXFFvOBD2hyJ+0k/6GDcH8x6H MII6fPF4BLeFXj1/i90J/ZkdbJK7YAcRD7btcMb8YhTYAfKFYdgw6+VgZ2sLlNbvsTxpZd1cgCf4 KEdwBEuyFAMuoThSgAXSjETjG/rB31kLWZFTcJVXGImUSSmU8sHP6eufsnJeLsiBqwHm8jBPR8Uw ep2u6d+05tIxMY1roirInMLJjExLNLg1KkWlsBSET+k3Wm21VkNfY6/Gi/EMFgcFImlivCxLsqSl Mim4aTzhhMp8jlUZhZGJZARORhKeIWQI2kuO+gNY0DdM7UF7B80ocIAoiJyEoyeZs2+AKHgpb0ZB bXaiATfGD2QOoeM1gQGpyhQuRoE2BExArH3agDychFPDQ/FB9JEnwsM78J3D+3a7NsPux6NmTC6q 3X5iI/bocTMmp8eTcgNvKHWtnjvY3XkkbbH9Q+ut1gn7RKKSyGLJjKQpoFblpLIEbN/phKpsllNY mZPoJAknibhvCDHWGE19DdTYX0xksEQmqaakpCyBuikn06mCueZd/++u1He1czvFpFgwBBkMNZaG xfT+Yh3Rd+rAGGgk5hOimEBwNMMyXIT1gyDUdzahSJICUWtOI6TMIYK7Ywq4O6bF8hXEBkrPHrDE Rtw0ON42OAUMloHBmVT+P2gwC0zmUuatognRsXQMGGzb3J6xub9kblEazCinJDBj8j+yRa2HQbRv AdHODHEuLsyHuChHgkFzLPhwJkWgBUqEY2Q0FkaNq6023X1eAIll3GE1NsyPGGtaIxZj7WfSnU1x if/zUh8wl0qChf4bS9UfhM7Gvh97EYt9XzwoVmHNqj84H7W8bNU3tXwW1Sr6Yn3iFjj2ROyJJxFj PTT6qRMphmPYi07c/r+ZoHUndMFziUzij55TwD4Cz9n+Tu8xF7js//OiPobO7T8XexOLnROfE8dg 1SpHlPbIekrD+tj8ts7XWs9am/E/ulcyh+neiwF1n+ne9EWDksCkBB0n4QSxHxi0FNoa3xzfgCU2 xHcnfDBjpct0kS7QBbIUrcC2N1rdB+zHx2eONV6EGy9mzr2P/BX5mvc05n1h8PCecXh899bsI+hj WyMju/Bdw/17zNrzOLHuPmSDvCW3E8vuKPc1RhrDk96ZCBydOcgcRX9wKjd+AjdeaK21K4fS07mx /Hi5UsvD+dqYPIXOTpOeMXzMXdlX2Abnt6kb/gJ5hNkS3Y5Fd/j2OVywyzlI9KIbd46/OIgPvRh+ /2Pk2eQxGXAet75HP2YXK5P7D6Mz00l1Gp9SxnL1Uq1Uqmcn4MyEfGAOedV/snsKm+p5tHAPanCf 9dL/VZbta0LBFJGkTWCQOAXcqolZWMzEClWkxS2KF5vxGbReFbgyXuaLdC6aI9Ih1QcrvpRrGOlh hyIuLOL2B50UTDoHuR50o9V2QC/oz9qL2Zio4qqoCApAd5VWoyqR8eWcz9zRmfFeHL5cANbRpjWY jKYohZSpNJWlskQ50tz+887ATLARLoQLgaxXhVPQ6fLhZvMAPDaTPfIs8orvmZ5JbLL70fy/c927 LkZnkr0QnRKAwwyAw1ipieh3Qn+l/8J+eIolanidLAbTXjjjkUYHkCHeQXkwyhsNhohQNMiA5OL9 bnEIfUx/xhovN+NTqG3ZWf0mu4FAgTdfpc6gM1MpeQIfVxqZSr5SKFQyTTjdlKfmkGlmItLAog1/ 1VV2lfdVd1X3lkaLgZw/HynQRZguchXAxqVKuoili7lMSYXVEmDogFAKTAEvsjkiE8wGNbdqVqlO 615tUHYm4KTLGXegO7qZ0D58X9jhCYzAgRF6oAdxSK6MB8t4it66v+Gf9h3xH/VOBaqhSjgfVAOw Fkx5nEg3OeTxYl7vENmNDrtSagD3q+EsUSJKVJ2dgm3JmRZnP22Vx+WaUlJKal7TVE2T00kg23KJ AvravGD17g+JgM+QoimqWB58AKcBwMmIlAmeTt1pRlw0yQDizUo8qPt/HnHC61A5J/Iargkqq5pE FIg/Jai6ASU7pd89P261vdJ67mI9zfypnsrterrZCVXYvEnnL9TTBJEw6+kr0G6xn3NhvJP2EoFo EPBDGqb9Xt6FOj1JKYAH5bAayUazVImpwWydH59B9I+g/1XJLnIZEGkyD7icOZg4BSeoeGAUMd6D dqb61GFMHcm5Kt6ytxGapGB6apY71o6DJt5UqulStpTJF7KlbEWrKWOwPJY8cBCx5TNthpbjM7zK qCzIhagSUT3qkH7H/InOH1n17a0jmel0Xc13qTk1rcqqkknlUhcsqvFFVqNgjUqFfQi3n49xGBdj RRaLMSIrMu3BGkvml3Ya1tZXuCJfEHNdQjaWzSDZRDqlYClFkoGKTmWShSTchGzGcAsyLrO/PA89 CtmW6j+/Rkea1rBZjS/ki8RLoiKqoP5rgAak95tJczf0DHeArGNkLVzwZuC0b1TqR90ekffgHs7D emkPMxrtD8IP/whSJ7LVQg6owaoyDsg3T+bxPJUOA4Uke5MjfcgAtIy7P7TNAW8bdfZsRdySN+3H 0oFCuAJQplLjxtDJCTnbxMeyE7XJKVXspP7WHuQCZAAjg+Gwn4BJv5d1o8FwIkXghEQqTAam00Kh gswVx2ZL2GzptPZmHLbt0O8+v94+bDUu5yyjUEnMtnmRBDwLfMuAGkcBmg5gfr97AJmfhObouekm UadrfBdXr4tj6DOH0+UD+EylMVk8BJcOqye/j5xhng0fxCKHfOOOMlx2DGp7UZ9fYIN4kA3SADRI n9/lgkXrqkWFZF7OYHI2nc2ZQ8tJsJwrJCvo4cngvjJe6de2PoQ8TG7z9mP9nqHgHrCceDKCR4BA I1VCZTQ2zaX5rFiAxYJYHQM07Gv6f23ts6cABIwACCC9AAK8jiF/D+zrpnY+idxd2jCzC9s9+7zn NbRUSCTzODBByssFJafm0rl0Pl+qDM90etzeoA+Erc/DuVCXT9KA7Vo0RxapIlPlG7DQEMcmkWek w+lpLD2dr5cLcL5UVRtoMS9waTzDabQWbfdsPPDr/2h1yW7JBUTU3tbnWk/YfapfDgC48PsSbnR3 L+Xvx/v9o8NtG8mnNyN3Fx6Z2oXtmjru/T5aLSeVEl6Si1oxU8iUirW6Inay37JMW3VIsoxB/lT0 AruQBAW4TQP4HcvsL48hrTeGQPRecCkoC+Bb6UKyApeCVDV7BPG2T43fLQrGIqLZKRAonga8l6ZI kqIYCqgbigf6RqSisRDaO1Kc9eP+GerU68gbmVP1WWy2fqB0Ai3kRCGDZ4Q0pzEardIScE0qkgzB iWDc60BsS1s36ZDd43IHPSRMepzcCNrvUPNe3FsI1+hxmBrnZ48gmv5DKPYsf4ieYCaJRrgcLvvz rjSccQ1L+9CdPaYf+4EfAz2wv4fe8STy7dKGOeDHuTPet9CxRkqp4TWlopVy5WylVKvDxmn9SXvq hcyR6gQ8URvPz6H1MhvN47loOqC4FLc0FN8L24xj+plWr92Az1jH4tVEAUsUkzkpncpIqiwrQGCp yYudtEKGpzXcRGLZC5/+lTXpdydG0SGHwLpxN+MlfCFfMOQj3ZSbGRL2xkJiVKQB1rMiL4DBi+0R 42M0+AJ2vGqcMiUv2PMYAarCRcnLXpS8+rYmFE4SZllOguJglmVNzJjFwWTCp3QYsn2j5TftXmOV nK6kCx11CIzZEPSRwUggHAlQXpjycM5hZFAeyTqxnKvka0ZGvH4/GYIJgBF+JJgKaVFMA2hfYB0R XzgcgCMBxudFXJIvE8LSoUK0SlaoBjsBivvktDiDnjwi5+fw2dxYpdyES01tYhoZ42tkGaPKwbwn A2fcw9Je1LjU6g7EkwROJs2WEszJopZFKtnyWAVjqg1hAv3h8/mpGXx2qnj8+0hVqHAljC3TOTKT kjp/zVuMt0h7rdhMH0DLRZ4yETETVr1mzwisJhgL8mFMAJKEJhiCpAgGZqNhIYAOODN1UMDq1Mwx 5Kg2Xaxir8yvsv/EWimIfBbP8hrQ1QqotRcin6IQLxsgwhgRChIeUAQ9Dn4Q3dar5F24Kx+tTSOl VFHNY1o+myuBolxtxCZQW7f+AIDJIeufckr5I0wmmORnYXLZZzoawkX3EnzYdO8m4N4UmTRFKCdf 0AQXZKTp3vVQPpVTcpgCIBHMn8lqQOBL6WwihzbKLJHDc4Tql1xwypXYtwMxvngxjkQQR2AGjjNn EyghcnEirxSVGYmVeVUwda5YnUT0ddBErC6UML7MFdgsk6PSpEZoUTmcglPhYNKPBkICF8LDXIgO kWHC6x91AKy2Gef+4fxX7Tf9+kPIWPLJV+36Y01rIBWVGJmROVXIwEImVgFP/8dByLDwYIvyQkZQ wbwyC0gOkyDiUTge2R/wIkYf5AJGE4AfmUYDamRafsFom/HTvzdn+dWHkGistw9aDav5rDKfFRRe 4YHMAVkBtpowma3fgRj/AjlELx/ChCAXZUiGomiSIZgQqLOlHZ0nsjOFRqVZAQE1AWsT0uGToED8 pO1I8ORLTUcW2/XOBMfkxXr3GXAEnvTHwjECJKoI6BvgchzLMTzBBS9ucLC9BTTYAvHTLbD1t6pN +wXZ/imxFi/2GUr19v6LdaHc3n8G7D+dJjRSjcgRydz/BNj/oMCG8BB7cf8DTieT6JR/Zvl0N/5d O+sEDoP+LYc9BBVBEc6CiNNAxOVzWTUrwVImm8yhuXRMUHGgXQAIyYBRtvsQVDIKRijug+P+uMf1 pxgUzGAHk34ag9H2pJBtQ+uKqn22PD5ZPgyXD2vPvYS873+l9xh2vHdz9QGA7ZR/X7v++UxsJ5/e hHy7vOHQbmz3wRe9b6Mnj2qVGdx4qrXAPlebLh9DGzU6BGRYuOBMD8CZfmn3NmRUdPAmsWU8pJ/y R8IhEqCcnwO1dbB8yIO7D5Fn3kLeSJ+uzWG2Pj0s2vlqXWwC4qJVDuAHyk2TuBQBcXkJ+Wn41SFg 2NCu6iY0EhVFAo+CZUTYKAMGGaWCIa/3X/tCbg8QPyCGEkyCjZsy/EJr83bIFwvFTOFlNn3Nni8j mK1NwuwcbwXhY+J8W3a2lVs7SjL7C3Xkn6AiU2YrPLxZ/6E9l8gBB0nAQTnzo+VNllRMltH3jjxs XP0wubXNcgYBPXL7E3IYj0hRlUyTGSYvlGC+KI4dQGw7Wjnje/Zo0pR75ny8GfUmXbgoOl6E9ql9 g76MV/FLXZLPm3Ci27spfx++z9d2ja+HemoTck9+wxRwDaAmL6G1Skqp4GW1lC5kitlisVSFjbsg 9/6gWdfaASiwZrKAdGn3uPVtADlaiP0C2wAhSoEvaZCygG6QbbZB8hRgGyQRC3+Gbbyeeb4+h83V ZwDbKBdENovnuIyZNVElnArAqWDcOQgSe0Xr8tZ2+4DiSHkTcMLriXvQnn6OGMGHSU8o7IVDPsY5 Cni0LxPE0sF8uEyUo43odORguBnN0YB7kwoJy2QyHEDCYpQjMZZk2q9O2u4So0Qsig46lVwAD+Qj NWoa3rrU2mTH2HFQIsfHxUl0vJmU6ng9VVGLYEOyea0Eq2WpPobUuSpZwIhiOO/P+nOjuX35fXlX JqJFVEpj0jCbFrIFpKaWClksW6wBOVAuCGbhaq8yTahB1Qc/DxBYKrdW2n9iNK2bM3uqTsxROxA5 gdZrUhqwn3S91Ki7JzoJIsoQLMwRESGChqPJFIVTEg3IP5PmCkIFFsvi+AFEH9Rve8G4Tb/iAYgf ElxCiA+CMCc5kgb4SbJhDjjM1n2otd5e5XIs0JIAahKmloz7hxFjHbRD6tecWNqV91cIOFptstNo c0zJj+HN3Hh9YgpwVKHNURf9iaMCKARKVwCE4I8cVf+FsQTIPUFrJxBIHyHJJ/kECwYDUihOxYGU Mx6GgkKYiWIsyMAwGFEqyoH1RcUo6gslFcA1FEoFOiDD5YUqLFRjU0cQPWHgkG2lBliSE8oKaQHA Fy+bPXlKCWgOvWt+QefLVv0O/Q9aTS0q2S4lowCFKwPylwPiz3jYCVXbDXUY8AYiglBAy5sMmYuw oRsMsnOVvp8HMlXUusR0TNMQLaEkJSwpXWz4Js32K2TT17UY0f6mVb9WN9SaUpDSXVJaUiSzkZeU klJCTmoJMNvdZvs+yyk0rDJJMBsJaCEB8JSP8tGVBt25pGWzPGg1rpq33a0nhJzwp3lzSU2RMVnJ SRVTBm9q7ybAaokzFytRckB16Zcaf+h826p/sXWJxbZE3wyglNE4jVdgQRUVFSnm0uMprGlsdELK hUaVqb4pDVCvgu93xnWdS42rQn4iQpFdIFdpiqNBoBAmuN/ehCJxCoAJzAI00RA1LidlLCmDJSrv f9T5zo0yLQE87AKQyDBIIEKOCJhT3wLuAgAVyUSy4WKwblyif73zv+tfKDeKxVymK5fOKm1JvwI4 TtRAyYdlLsEywAVAnWA8zQJlsu5bnbaVrfv08/YL7vvX3qtc8J4KvBcGtxKCWZ+4KBf5mhHtXKGL f+Y99VPvySmzeQ70f9Gcf2s7cMy6Z+4lJZNKUHPqi+cXdYaHok7CF/VTYYqkKZo13+gwVIxECToh sTgrg83NwTu+buXrVbGMTjaVbA2v5iqV0hgYs+VjgOZsf0532WdiDaYQgoth1e9CCN5F78WYPn5g BLm/8viRPuxI38uB90U4d5ixbu3JNUfxkbHIiVeRRnJSnsOU2WQzj0zSjWAJC5a9ObcGa1BdreaK ZbhYVuuTSF5oMnMYOytMNpCXc8cmxrDm+OHsKVQ5ErHeIz4a6O6Du/t8TzyIjKQGlb2Y2pdyRREX 7Q+GsVDYRffHYJu+BVClNX+49q8B+GzXf6uX7ANxpxLKw8ECU64j2WRDPYipc6kDE8jbvhe657Du uUdK9yTgSLdqff5w1DmOTzjyuzYiLn6Y7cOYfYIzhIyorqIfKwUqkToFU5Cb9kUCfjjop93DSDjp VPoweV9qyI1sCO8ccWDO0Z7INpTuyVnfT7xSOjIHH5mrnHkHmeAP0Acxek5oZJG6UinmsUK+qR6I A5NX6TbdYjcsH+kWSL/2mj87+W/gxHbe9fvg4kU5+3Nz3t0NvLGrsEm5Hz6nn1hsdD9lPX/THy7/ ZM0fVli2Ll50GBrTf2+5zxq+JbDBOwKPeociPegnv7Sev/T8by2vQvM/Pz9jsRlBnQZ81XWT5RfW +oeWp40LnRSeHa3F8iCVuhQuSYaQEO9g9mF3Gb9jBphR2tdFe6kQRZAESYM8AlAtBlF/NJ5kcGKH hc/kY0X02JxSmMKnio16ebo8nT+WfgG2bdE/1Bfabzfeteg3WaWmOxFO0XIXI/PpPACCsjyG6Ve2 XuxXn+73ZX2qWcb93oQX3bYjNNiN7xkabL9C3kJs2og8me6ujmAj1YnIIXRyMl0FM9WmpiePwgf1 2+3cCOOivbSPDoAADwMGao5oFFhLMCQwlyREEnWHtCKFkyV+fBZ5TjlZeA4rnqwemgBqe3w6P4uO AbWdwdOE7HMgHsHNOzGb0uLO32pPtd9qP/5U1LED3+Ho6R3YNrDN+Vjgu7B/Hf3YVuQ7xcdn9mJ7 Z57zv4a+9SOt9Bo+rWOWbdbgQNAZ9AcDgYifgRm/h3cAhpBt+PFAkzr0AvJG5u36e1jjvelXj56E Tx49Xj+JzjZpfwEv+NWh5G5QPKf0zoH0sOxIdYGg/r3Nvmax8R0Q1fplrfXnF9vL7R5GGkCnyrZb roQaVUKKV/Upo9oA/KI+NP/xsFU/NP+w8dL8cstI61+gvE5ZHrVyI5ybDXABNtJ+I0ybr5sonhRh gQjFvKjxnlWvtBZaDkMGpX9isR1pnrfY9fAnFstfW/WJ8xbLndZ7jfstxgHr9/T7Lfr6+QP26/Vn LLrHapvVb9R/ak9MpJpyXa5p5Uwhk89mc2peLUpVoNSq4/FZVN/2trHNunkHFwUEkBjyuUado4FB sg8m+7idjyMDiUF5BJNGVGfak3bnvaVAyV+KVKgKVWObALQak0DY63veNnZZdw2kVCB/FV8uXAwV iSrTZBr8hDgNt25422oT3jp/if1B/ZfGk8YHD+ofGKPGLx9s3XL+EgjUkwP6UbuOn+s/a1x5W15f ZnnIWjCWGVf9qv8xfclDxpKHZjbpV/0yZCyznLOG9WX6lctnXrLYNrXiLc6u3zP/iBOqAxmkthu3 ozuQ+bugHsHJEBhLBGgHA4pMfxMakH0ZNg8DOtuYQVqCvhQar9FB4N1goS/3OGx7pvXONXIznABc WumiFcAECjzgArHx3tbxzrVW4835I76BsJsMd5GgioH6AeKYjHHOTn2rVW5a9kmB4iQAs7xcxOSS VsnVJ0516v3W5DpLPBQPR5E+zkWGMSoSZrwiuOto6227ZA3vd8X3YfH++IgH0YxbLcZGq+3gi+dv sbPOogCKOdWl0hIQSqlQwp/wzMyf6Dxn1d9sHakeAnI015XOapoqq5IKKIDU7ARu5JyWWbYYHEH+ J61WHtxGdcZnOpW8M4AoTJdKu2W33AOFQKEFWkK5YaCQQIJjEhInsWPHciRZh2Xdq2t1OfJKWt3S SrIuO5Il24lJYouEQMJwmKMpR4fpAC1t6cEUCnQ6T5l1O30rh3RKmdJ2hnkjzf6z73vv2+/7fr/f ex/lt3ksBG1xGe2j/NDKeVLfAei6U6Lxyng6jE1OZJkkwaQisSgrnH9nhNclC+2LgQz1GeFblNPu dFJuO015bH7Eb7ONU/igOlGGyVJyzT+FLYQPxZaI+FLqMHeQO5SfLU5PTpUmS2kkXa6yU3iz7DIL iRNTMX0wcWrgWzBxWE1IxmhVEwp80xZKs53crhkYVDyu2DrabV6PWNa5u7f8S+pO5plQgSyEq/Fm tjIgPRBvgjVsPVwMpWXhdCgunLSHO1fVMSbZ2X0P3H12POmPemRRT8hhxfQ+Da0gJPwF7ZvAp2gZ fE0UH9wV3o4P7HZbhkm5VaXT7tEqjINUH0LtpAeGsO5kf2WEGCnP2Vr4XDOagcouW6/UGsqaVKcb NY05EIde61HiGkM0S5EU5yk3sMXoEvckkX2yOF+tItVO4UrH/Z4oGfWGXSEH45gwBXUQUi5u1zvf lRtPwgIhYzsrNPg17mFCzl/jHnL3u7bJnFs9wwED4hE799uWjMf5b7bPk/LXiT/3FgXFD5SDVMDm t928cpbUPewd89kh1escvXqFK3YogighzMBtsMibg/bPinwGK4QqbJ04BHpii/HFaEsWa4XrExzC ilObM5u5zeCSlZukkG12tXPQ2aUwdHYqlBAussPhCOSb0NlMBMbKJ+C6L9wOhCi4pNUVyb54STvF T8wybJ2ssdPxSgqOwlS5WinVco18MzMfX0DiC+GDh7HD9H6qQVAzhqq6oMmr0goWiSr7Q1vw3u1o kMvsTePLLbN8hqwPZR+7D3vcs43aQdi3G/rU/epdCtWgCTEN9jp7cLUpGHSSktqZ9aZ8rBAgjMOC Gf+r9W6DLrQEHRM0I/NMeMP+MOKLjEfjWGRvNBglgvAvyAbZiQSTqoNLpYHi9N4GfqIV5RbIA1y9 Wp5DSnOJg0ewqq/ozhPuvD1rSVmSYzFdBIlo94R24fxF/B/RV8ERUbA4GSzgizMuU57Mm+MjA9iI T+MaJdyj9jGL2Wo22HUuxK1V+PpxyUfgmlPnoJCaQmZg9GnccmIzb6CVHo1fJ/ONBsaMWE9mV22E UNcOUSfwpw6y2VmymdlXKTVLs7ml1HPLYFHK1iMwm0JpSHnZEEymyGoyMUIyPfT5oDP4BF/dxz/v 6nMMUxqZTWs26G0INaqm5fiQJpYzk6ace2oO44K5CY5gskwulH8BVAUrJWglFYZRJOiWcCeKUh0r j4nPfBEJXwWPQBqkv1r0nrj0gYjftGJDXQPePTpMxxqSFsKa4tyTeKUYScKqkKyWZpojU1LDqMXq cCNuByzGuItmIj5SuHlPYVyozM4QPwOviM5wqdQqlxI8ZvHp4GYkTvAxOBelx3xGE6aPmJM2gkpm 6QJeLrIpgW1XirUZ9ZR0bNS6asQhGPEwES80EjhjBJzTnhesnAutQJeNswEZ6w/7GS8itHc4Mde4 PUAJ6Wr3O7W8SGqKm1kzRF+z6cuJVb0Wn5wmp4u1Rn0JmQbf/aqI1dvgVtTV51XoP+/sVMfZxf/s 7Cz0Q4MAZ0M/qAQ/eDt+iKz6IeRFmI4f3OPO8c6Zjc1nRiTXtCUARdVqrUFHIZRWTStxpV4oq7aM p9LEShOToTzxyVvp6WPksenqE8exprNiyBJZgyq6C+8fcJl3k0NmhbZTwXdT/Yi9nx4cwnpS/VUV MVKdt7aEs7lcg5zhZqozswi/ARxCG7UZroHn0h5HjIzbQ1YDpnSNmk2EyaylhuHGhnf5tuHZZ8uL tQYi2dG+62107rncb4UO4i7zr+THieNDm6bvxu/pVqzfTQ6uN93AizG+i7uxsZHY2Dg28jr+xjOd bt3r2y+iby2s4deHST4gBuuZJ/7wCzy4wqNrd34ANvhJMC7mNwT6r74FP9N0vNpU2nPqcvAg2tpf PvEG9pr66e4m0ei+h/s+3gxNRmNELJZhJ4Wr815d16Q3TcdcSNQVHhvC+B7XVbfxl2B3lXuOyImj 8teNfwogga5hn97jIGinxa3zQA7UW+7SRqxROo7QCX+xgU10/TnyZqm1HxkB16I88pN1POojwN+6 ADr+0sP82djKnfyFqHKfdfEFuP2XngcXRAj+7133TmzJKPZBPJO0f/Mq2loqvfwu9qr5afk8VJo7 8j34hh2GPgWp6LNsvBvjh7ouim1aBgj2+7k3XztOqJoiXnz7husvw/gLf3knWEsT/M53wM6u95mT 5dYSwveBy9Dng4dD0wQzFS+mswiXyUeLeK1kVeZIThnb2Y3xVzz0Y/5cmpCA+9tvgxT6A/OD8n6i b3jz2AP4A1smn4CwvmBZfg9rr7tl5cGu75RvaW0iulsn1e/jvzs5daxFto6V3/wAa+9c2yXhQAB8 A93jG/XYCNpmdCg9qz0VyrApTgtE0QfR/eWuFzOv198l6u+Un84VkVIul8zj6YTbzJKL74ujJjNj wuVKhx7q6lFNr+Zezb3GddSjCC02fWp8y/iU8ZihYcwiWYOOVeF6Y+f6mh6jNGMlhZTLFWIFPMs5 DHBzY5WN9TVIfU32tvWY5Oa2oz2EXinWr+3lz72XvwXyATc43/SBehlZVg/Wt+FKuVA0CiOidD7D JvCZ+o6bYJG4sXB5kj9LKCKbujHF0a7D06JgNpgvYocDC/4mcRyc9xa4/CPwI2S1e/nn6E+F7mW7 0L1c4B9bgT/h8UP+otPhGAZHKqgAfB6GXsU9fyQQjUeC0SjWQT2IexNxJvXX9pj0DTGXCPhZEia8 J+wOuUNUsHN5q1NgS+ID4HbRCise5H8oaom5+cxUMgtHIgkBMJllCviL4ktWtLTSq/daZV6rz+mF CsgrtAn6XLBqeiAE90GVRZz6ejuPRiCahE+jSaiDJhEmehpNThNAX3QV362dymslAlaBKMn5K6V8 RtwAV7KdKWQhyGvCp+f4JyL1fB73PpvDbwt8KdnqgUrAOEExUEF4In5BUe9NdhrvJtKh7AJ4SAqy 4n7+fmEKv13m68zhc3v+bQ4TJGx0ROaGc2Sw2N640A2aZDKhPCJptS8HL6LP5xan6rNIbTZ76CiW 83PeLOHJ0hlHypmkEpaoNWqMjEGE0Y8wQzivFH9VtOd0ADTBtdIT4lTidBOyl/WwdMQZFtqPrYyp eKk02heTx1UI+LYwJSM0ycncUGbRUU/Mk/ClodLK+nP2E1LvPnfJmXVxVNqSQPi18+gymBMF87lg Di9y44EUmQok/HFf3Bf1RqAVGGp0yM24VhuUKBs27N5jUREWld6ghpgyMujZiktm/2+i2r5HfAjc KtoqtqntY04LHHYnVH5OjwPKXrs1YMT5y8TLYFb0oTibDAQiZCQQ9sC1hFxBsxo7KD4MHhb1iu1a u4mCwsFu9urwNeITICYCN3Q6tmG2BCK+sBcOJ2ODEm8sOALFUhNcJZKsmwdXo0oem3bXPU2vzDs7 E6jhiweiHGRx3FQpX0fy9fjsQodUFiCppPIWzpzT5fcUB6u6SSqPUDl6soKVIsVEnojns5lCAklM lsNTeDHnp6Ej6YRD6AcLrdqcBucp4ipWG5KFNOoJJd67q6OQLGq9SYUYlS75AKYL62NGIm5ImqC2 txQsZfOUuWDJ2NK2uI21IKw1ZDZgOyi5VkfoNHJ7Lz6giudNpKng2reASd4D1VPnozt0pw9rui0P IeZ17o2PY/dxPc1BYnfziOkVfOlQoniQPFjcP9tYmlmqPMMtI7nl6LNHsZMdgJmTP557EH9sq123 gwQDKyJUd4fykYE+pG+wz7Adv2P30Y8PRo6kTpDJE7mnSkul1tRcrYJU6o3kLP76/JYr7rPfrbuD lDwyHUTb3xMfAY/CL+tQOXQOIxxWh1249LB7ER9lDuhx/mzxX9rq/61SfHlQIZK9e8Xg5Dfbv0b/ IcAAH+LWZAoNZW5kc3RyZWFtDWVuZG9iag05NCAwIG9iag08PCAvRm9udEZpbGUyIDk5IDAgUiAv Q2FwSGVpZ2h0IDY5OSAvQXNjZW50IDY5MyAvRmxhZ3MgMzIgL0l0YWxpY0FuZ2xlIDAgL0Rlc2Nl bnQgLTIxNSAvRm9udE5hbWUgL1ZIWFlQRStUaW1lc05ld1JvbWFuUFNNVCAvRm9udEJCb3gNWyAt NTY4IC0zMDYgMjAwMCAxMDA2DV0gL1R5cGUgL0ZvbnREZXNjcmlwdG9yIC9TdGVtViA4MA0+Pg1l bmRvYmoNOTUgMCBvYmoNPDwgL0hlaWdodCAzMCAvQml0c1BlckNvbXBvbmVudCA4IC9TdWJ0eXBl IC9JbWFnZSAvTGVuZ3RoIDE3IC9JbnRlbnQgL1JlbGF0aXZlQ29sb3JpbWV0cmljIC9XaWR0aCAz IC9UeXBlIC9YT2JqZWN0IC9GaWx0ZXIgL0ZsYXRlRGVjb2RlIC9Db2xvclNwYWNlIDEyNCAwIFIN Pj4Nc3RyZWFtCmje+v9/FCAAQIABAGN3DQIKDWVuZHN0cmVhbQ1lbmRvYmoNOTYgMCBvYmoNPDwg L0ZpbHRlciAvRmxhdGVEZWNvZGUgL0xlbmd0aCAyMTgNPj4Nc3RyZWFtCmjeVFDBasMwDL37K3Ts 6MFOYLcQGB2FHNqNpdvdtZXMsMhGcQ75+9lu1m0CSUhPDz1JHrrnjlwE+cre9BhhcGQZZ7+wQbji 6AiqGqwzcatKNJMOIBO5X+eIU0eDh6YR8i2Bc+QVdk/F9sfHvXoA+cIW2dEIu0v1/pEa/RLCF05I ERS0LVgchDycdDjrCUH+Yf9ClzUg1KWuNhne4hy0QdY0IjS1am8Byf7HfhjXwXxqFrdJpVISaXbr ZlY+7K7DLMxJYrm+SMjLHeH9QcGHvCu7+BZgAGRea64KDWVuZHN0cmVhbQ1lbmRvYmoNOTcgMCBv YmoNPDwgL0ZpbHRlciAvRmxhdGVEZWNvZGUgL0xlbmd0aCAxNDQ4DT4+DXN0cmVhbQpIiYxXWW/b RhB+16/YRy5gMdrltXxs3QZoG6MBqhoBkjxQ1GEilGRIZFz31+ebgzIlO4ZhgJrZOXd2Ls//nPw+ n/w6n8zi2SzkZl4T5IvUzB8mLnZpYuYfJg5nwczwJ1CWxGXpg/FlGZd56sC9nXyOqrUNcR6tG+tT /O4aRjvBHq1P8GOanU08ce0P1ucAttbRTzVmbuwM3z0fKf+VebAZMa6YZu6Z2AuxM5CDSj47iEJl r8ZnS0aMnJmjHIpC5VDfV0pjvaJ2LRSzHUuJJmXu1VQ6u9TQ7cVPY7+a+VnIEw35LCk45D+LdAhx mvpCAt2wD0lEMUiidrUlk0m02jHOMUwkQgmHMpEg0g8fyc9GzsySsccxX8VHakU01KJVKG0r2KMR /Cic8kRwpG0vCHh8CkIQOI2+rSgdwClODoLCcRChb62gommp3p5H0HlfnFLVvZqrRR6XfuZzCeFi pLrlCwqsAajVv5i9/UWv25pGQ/1q5EVT1wi2V72nuzccFB+ZWmyMGdYioy+0Gi7djVWxkk8r9dTc Cu2GafJF8EfP/WLkJO0Qj7cVep7FSRmCl+BdH2xAAUxDtGxwF9wbIMopIEsA3ZGDQu5bojNMMrF1 uPffgHpCzYqo/xH1XnkSj3wDtB0s7Lh+CCL9ZrkaqPvdkbi7QXfVnUyZ7uRGJb79BoaP1s2i6TgK Uy5BCUVWujcmEoBQ5InW4j+kH9eG7TsCV7ZAxAH09Glht2HijtANO7MXsgQO33t1HN/Dmn+Y47A9 mmsGhLYkNlEmcog4bnhm+8Sn1qcsEsbWF9alqHZW0NlB6NiNeMH6UraEMnlbtqTItywlborQdzJb HSQSeLeeH5IrgR94eQI5e6rTg+9JhpnXdCVGzfVHgv8FOEXZumix7zlFlobfvyL+b0O6XHG+PdhU bUte7HtmNZep4PwbMyBBLBKfBu3GfIvuLNHX+hyCcZHsNpqWSPosMi3fsOLLGzvFd1FxsVS7mhhY GPWCwr18i1eeIEdjwVT2xrsyTpyb6Wg+U/HufWpwwfUEF2ZRbzKcYJjneiUXX5j8AKHsUihP0H/P 5J7Nt6Sk1HnBYMHujmX/wFvFJWUqPWuH7aAAul/2tSWga/a750n57r0XzWWsuhnIyhjv5IKPXf4T z4KTpE6LMrw0eSmS8Bo/6t+c+qyjQnMZ/FkJiumJJu6ABny/U6t1A63dC3ovLFtIpk+SO1XUqSJl XsuP2fYi1aqUsjVTNlQLUWUOTz7RqekUqG1asMvMBYNJSSEVdPBuo8KPNIId9WSWHdyrFsqu5xhe 4TKa3oW3LYwuy2JfhEwf5Sg1g9w/cPeh8I1xnpDsL7sji5bgbbOUnk+9QzkC7zIcBRrQdMPA15Ij otH6yZq/y6Q5mWJFveX2Q4Oeop1G24pCyG8uq6H6wT6yM+ZLBKFbAm/o88XaxKFu/eyF/oIq45xz aZ6+tu0hinGRFU7H7fyOXw4z1dSYm1O0H3ZbzmSv5rLhvplgU5T2ioQDDTOw2Snz0U4L5pKNVzVU A6M05YEZMQqnXXxgFtG+4uxIKTtZstHf/8WNSlHhHoi6zxuSJU/5UPbo+g5Ws/TE1J6JbETro3VF LCEX63qdvlZ8iNOzyA9D3oehxbtQvpqoyPm0CLnT/2wk+8ynlcxS5I75TF06oy79lT5XFnb/ur3B +bSMPB0pEZJXuA4S4vbmgXcSGfWshtYFEgkxCeG4HGlkITIpw7m2ePkSyUXnSDSa5jVtQlb2C96G aOJMh6VjcVoFOs1bzMXnrXDIyjes0sEX6LgefmT50Fs3B5l2fDVa9FsuOplq/K+PbLBaR1yMphnV coXmThKcGrko2Y7KfsMqWN1TpR2xeiNGpIsoNDPGNjDyDbe4iGYsMyVltOAD4mvZyk4DC3D1NImp B4trvHIgXuaHAAMAqtZNJQ1lbmRzdHJlYW0NZW5kb2JqDTk4IDAgb2JqDTw8IC9GaWx0ZXIgL0Zs YXRlRGVjb2RlIC9MZW5ndGggMzUyDT4+DXN0cmVhbQpo3lRSTW+DMAy951f42KkHIEDoJIS0dqvU wz60drtDMB3SCFGgh/772QnqNiSI85z3no0T7Q6PB9PPEL25UR9xhq43rcNpvDiN0OC5N5BIaHs9 Lzv/1UNtISLy8TrNOBxMN0JZiuidktPsrrB68M96r9bxHUSvrkXXmzOsTsnHJwHHi7XfOKCZIYaq ghY7Ee2ea/tSDwjRH/Zv6nS1CNLvk6WMscXJ1hpdbc4IpYwrKDdpBWja/zmRB0bT6a/aiXAyjmkR ZZb4mBZR5p2P8z3FSvtY7ShmUSJJVQnSXlToxyyiwaOUGz51H6Q3RJMNA0FHbglI2TeVHkjZPOVk igFgp4ydsjyUlDJQMBBEKSaAKXloIGNKznq5CpVLrpw7UnUon9tSbFCEPtUTAQW7FEG0YJeCKy3a AGyXLkNb/DN53rfx6ItzNDl/KfxkeCa9wdu9saPlEfArfgQYAPiJqL4KDWVuZHN0cmVhbQ1lbmRv YmoNOTkgMCBvYmoNPDwgL0ZpbHRlciAvRmxhdGVEZWNvZGUgL0xlbmd0aCAyMjA3MiAvTGVuZ3Ro MSA0MzA2NA0+Pg1zdHJlYW0KeJzsvHd81EX+Pz4z77I1u+/dzfb23mzLZpPsphcCeUMKJZQgLQEi oQgIeiRRsZxKLIiASuziqeBZD70jIGCwRkU9Cwee5fSQ4ondKOehp0Ky39fMbhC87+f7+Px+f9++ mffMe9p75jXPV5t5B4QRQlrUjTgkLzx/fsdnyrJqyHkcIfuyhSsvlP+V//erEHI4EFK9srhjyfkv PeyFFv4jCIlFS867dLG45OmXEIpkIzRq1NJz5i/aN8d7DUKLpkMf5Ushw/yt+Qd4vgGeQ0vPv/CS bWNsr8NzL0Ku3PNWLJyPVz/wD4SufB+e88+ff0lHFpb+hNBGHurLHV3ndBytvO1BeA4hZLRAHpcJ HkTHjXQKPEFK34h4HdTBHnhQQemVeBXegG/B9+Ne/CFOkVbyKnmNHOQwx3EaLshdya3jbuDu5/7C 6/kp/Fx+Hn8rfyd/L/8A/wT/NP8B/4XwkvClcFzUi27RL1aLM8QBcci32veTbJStsk/OkSNyoZyU S+RquUYeJdfLK+RV8oPyI/LjASFgCdgCOYFIoDAwPXB24PbAozkkR8wx5phzrDmuHH9OLCeeMy5n fs45QRKUgoEwCpOwPiyFs8OOsCccCueHS8M14fPC3eFrw9eHbwjfGr4//Hh4e/ip8DPhPeE3wvvC H4Q/jdRElMiYSHtkYWRxZPnnwueOz6uPkWNFJ8gJ+UT5iZoTo06MPlF/YtuJz06kTi4YrB38buhk 6mQqRSmLNjPqbMZb8V78M1DnFaDO+xw6RZ1rgTo3cQ/wmDfwU/mz+R7+Dv5u/vf8n/g+/n3+c6FX 2C8cy1AnICpiu3jM1+3bLOtli2yXZaBOHlCnWK7KUGcZUOcBoM6WM6gzLTAn0HOKOiagjjPHl6FO e84iRh35f6BO8ynq9IQ3h7ecos7rQJ33gTrVp6hzTmTZ55hRBx/jT+AT3hN5JyqBOsqJuhONJ94+ cfLk2YOjgDrdlDqpjwFgt6eyyevkWS6R+pC8idCQEZB1C74YL8ddJzfD87kUe0Pxobyh2FAuJC9H l6GV6Dy0FE1EoxA6uf/kGyePnPzryX0o8/u4DaF/fJhOH1kN4faP5hy59shPHz165GJ4ehJCD4R1 R6746KLDyw5feuSpj/OP3HT40cN3HLrj0O8PrUfo0MO07WH7oc5D8+ApeUg5VHIo9GHjhw0f1nxY 9WH5hyUfJj+MfZjzofvD7A/xgW8OfHXg8wOfHPgHbXXglQPPH3juALzlwMsHHjqw9UDDgTEHRh8I Hcg5EDjgc/W7fnZ9JD2HkABBda/qHtXvVHerNqZHK34hjhJuFBC3kPIZdqEzfuT1dDjj+R3y8/Az N+7M+pxyWnouIKyP/ytC/Nfw7nuEzQJwvtB7en0B5JCwIx3+p59wHw3C5szTPf9zzf9oeaGw8lS6 6/9Zs+XMkQmPi1eLW86owqEH0LVoNXc2ugN9iq5DN6H16F70B/QgktA6IN016FZ0DP0T3YjuRNej F9GH6Ft0H9qC/oW+Q8fR70Hi/hm9gv6IFqCFqActQq+jc9Cr6DX0F/QGehPtRZ+hxegttA/tR39C S9A36Gb0Dvorehsw9wX6Cq1Fy9C5aDk6H1D4G7QZrUCdqAN1oQvQRehCwObF6HN0CaD0UvRbdAXg 9Ul0P1qFrgS5fxX6En2NduM78J2YYA7zWEAn0El8F96I78a/Q4NoCItYhdUohe/B9+L78CaQG/dj DdZiHdbj3+MH0A/o3/hB/BB+GD+CH8V/wFvwY/hx/Ef8J5AvvXgb3o6fQD+id/E6vB7vwDvxLvwk 7sNZ2IB346ewEUvYhM3oCPoIW3A2fho/g63Yhm/Az+Ln8PO4H7+AX8R27EBbUS92Yhd+Ce/BbpD1 XuzDL+NX0E/oZ/QP9DH2YxkHcA5+Ff8Zv4Zfx2/gN0G+/QUHcQiHcQTvw/vxW/iv+G38DnoKR3Eu juE8dBR9gt9F76HD6AP0d3QAHUJ/Qwfxt/gY/ifoju/wv/Bx/AP+N/4R/4R/xnF8Ap/Eg3gI54Ne QQQTQjjCE4GIREXUREO0uIDoiJ5kEQMxEomYiJlYSDYuJFZiwwmcJHbiIE7iIm7iIV7iI34ikxtI gOTgIlxMgriEhEiYREiU5JIYySNxcj1ZK0iCidxIbiIbSA+5mdxCbiW3kdvJHXDdSe4iG8nd5Hfk HnIvuY9sIt9yV3HXcKu5Ndxa7kZuA3crdzu3kbsXNN5D3B+4x7g/clu5bdxObjf3LPcC9zL3GreX HOPe4t7lPuAOch9xn3BfcAPct9w/yT/Jd+Rf5Dj5nvxA/k1+FCqFKqGa/ER+JifISTJIhkgK9Abm COgOnnzNCUKukC+MEGqEUYICdccI9UKjME6YIEwWzhJmCrM5v3C2sEBYLCwTfiN0CSu5qHCZcKXQ LVwtXCtcJ1wvrBNuEG4SeoRbhNuEO4S7hLuFe7g45XDhQeFR4XHQPTuEXcJTwtPC86ClXxXeEPYJ b3EFwtvC34QDwmHhY65I+Ez4SvhW+Jfwb+GEkBI5USXqRKNoEi2inftKdIpe0FsyaK4cMSRGxFwx T8wXC8UkVyYWi6ViJWj8UaDVxoj1nFpsEBvFseI4cbw4QWwSJ4qTxMniFLFZnCqeJU4Tp4NtMFOc JbaIreJsKJkzTBtOy+k4fZo24lzQkIvEpeK5/IP8Q/zD/CP8o/wf+C38Y/zj/B9Bq27le/lt/Haw PnbwO/ld/JOgZ3fzT4Et8gz/LP8c/zzfz7/Av8i/xO/hX+Zf4V/l/8y/xr/Ov8G/ye/l/8Lv4/fz b/F/5d/m3+Hf5d/j/wZa+gP+7/wB/kP+IH+IP8wf4T/i/8F/zB/lP+E/5T/jP+e/4L/kv+K/5gf4 b/hv+WP8P/nv+H/xx/nv8cf4KP8D/2/+R/4n/mf+BNqGtpN1uBTtRLvQS/gT9ATagfagq9ELaA03 mZvCncU1c1O5GdxMbhbXwk3jpqPv8Wekn78SPYM2ogGQdg+hW3At2oBH45X4ZtClt+KLUR++HA/g b/hOvou/ir+Aa+Vmc3NAK7Tx1/IX8Rfzq/mV/HX8pfwa/np+Lb+OX8/fwF/C38bfyN/EbwCL5GZm k/yOvwfstvvAeruL38hfwW/iN/P3g6XygHiheJF4MVg2h8hhcoR8RP5BPiZHySfkU/IZoHMkoHGa MF2Ywfk5mQtwOYDJhcIi4RzA6RShWZgKKJ0ntAvzAblNwkRhEmBtj/Cy8Arg7U1hr/AXwO4FoEEu AhSvEDqETi7K5XIxLg/Q/FvhcuEKQPJawPMawPN6wPcqLs7lA6pv5gq4Qi7BJbkirpgr4UoBpceF 74UfALFfCwPCN4BTCZBqpu8EnPrEZYDV5eJ53FfclxC+BlyOBmTWAdKPCB8J/wD0xgDDUcBwXGgU k2IRYDoMeC4AFI8Qa8SRXBlXzv2LOw76W0Rpwxl+mMCN/ErRQSHHC6JKrdHq9FkGo2QyW7KtNrvD 6XJ7vD6/HMgJhsKRaG4sL55fUJhIFhWXlJaVV1RWVY+oGTmqVhk9pq6+oXHsuPETmiZOmjyleepZ 06bPmDmrpXX2nLltZ89rn48WLFx0zuIlS89dtvy883+zoqOz64ILL1p58SWXXvbby6+4clX3VVdf c+3q69Zcv3bd+htuvGlDz8233Hrb7XfcedfGu393z733bdp8/+8fePChhx959A9bHuMe/+OftvZu 2/7Ejp27nuzb/dTTzzz73PP9L7z40p6XX3n1z6+9/sabe/+ybz96669vv/Pue397/4O/H/jw4KHD //UU/usp/NdT+K+n8F9P4b+ewn89hf96Cv/1FP7rKfzXU/i1pyDcBGEi8kPwcLchN0KpjyAchfD5 0ITUSWE5Cg4tSx3h6K78HzMBoTDotE0ohI7hIljLfjQBPYxGo2Z0GxoLGmkrMqBL8RuIR0FUjx5F YewHD6QR2UGTbASZOhf00Ccg3XNREzoEcj6EGkA32VBV6gu4N6HrU7uhlhbVgWZ7Cp+Hp6EEpMeR fByHN29I9SM7yk3tTb0PT/eCrA6ltqFxkPoUmVAUtNjNyAza7/XUSRhpCPTnI4CrL1AAtaP1fCm/ LrUcjQDkvoubIDUJXSq8r9kJWvJm9ADolP7U4dRn6Dkeg7ZdBYi+Hka8HfWTQq4OLAoZRdBINBnN h9Lfog9AOxVxSiqaGpPaCLmPoO9AMr/CqWAccTQezQPdfj9Q4z3QKN+DbiwDbfkYXG/hb4T3YWxN oIsvA417L1DvEdD3u0HaF4EusAO17CiGZkDZBuCU7cBf+3ETbqWaj3tISA7VprJT1tRnYLvnoRYY 4SbgvKPoOE5CHXgDl8NdyPv4C4XiwatghovQPWAlvAXjOAR0/x79iPPg+ohcSValZqUeTX0CY1Ej P6pEU9FssBSodfB7WNUXgaf/iU+ABruS7ONfBhwfS90CtI2gMTD2KVB7GvS9HlZpO+qD6z2YpQk0 bhGuxJPxWXgJ+BR3gF7/AH8AujBAOsmXXC/3BvchXy4IqWroyYZ88N4gmgVWy3lgfVyPboH5Pope Rq+Bxo/gApjRe9D+BzKC1MP1ANlHDoEW28CfFK4bOjL01dCJ1Drw7+oBdy1AzS1AhW/BUpBBjy/D F+CPYeQ9ZAdn4CTwYsq40dx0kCrXc7dxfwZPrwuk7d+F8cDRj6nmD/1m6K1UU+paRL1jEcYVRfmo FFUAfhYDmpbD+DqYBXU5WEjrwJq7Gca6GT0G834erLJ30UGwmo5jBPZGEp8Lbz8fULca3wTXRrB9 XgC75DX8EdgNcBFwcECTl5NaUkcayRKyGq7byH7yHvmc83ALuVVcN1z3cbu4D3jE83xKKIZrHMiN R8Q3VLmqcaoF6jdPDgzmDbYOHhpCQ66hOUN3DL0w9FlqZupSGH8YFaBCGOkaGOVGwOBDcG0BJO4C i/JNas3AWL8D606gVhRYQ3lguxThWjwWj4drEp4K1wy4ZuHZcM3HC/BSuFbhbnw1vgZfi2/Et7OL 2oQPgX23i1lwT8H1Lj6MP8Vf4u/AEkJgB9nBbomSBKmCmdaRsWQKOQuuJWQFXB2ki6yEFXqEPEF2 k/c4CxcGWTif6wTL5E/ci9w73E884fP5BF/Dz+SX8NeAVnsL9NgJwS80CEvBAngR/M1S0LfLxLvE reLn4kmVqGpWLVBdrnpHlVKHQVq9CvPeeYZdnhD34QuEbP4Schj4wsF1CGvwDKCYSKZz54EH8ldh MT7GyfjveB13Lrc89QDXSH7kVuCZ5HmcA7ZKNbcY3QC272OgQY6Tz3grnk6+wLn8zfhJsoKrIyLz B97mrfw1wufg/fwNVZMrcD95Geyva1LPomrhPnxYuI+8hWT+CLGgw8DVa8id0Ogv5FyyHrXwpcIJ dC7Q/Q/CJUDvUeR6nMe9w9+HPuGC5F9ghd4BUmMvnsCHyNmkCj8GEncQ+9AABgsf344UsJcP4j6E 8aPcI3gi0cNq9ZIsXAE+x14ugN/htKiVjhFHiBU3k2NkBveMuJ8rwxikxF/RZWDzJwE7w78h8B8W o9tIFGRaA0iTt3ExcoDPMhodH3qGSmzhfWE94Ox+Lh+dhZKojbyBqoE3PoGrBfyeYvQUYPB6lCR3 octT3XgRyP1JID8J6PtlKIF1IC3tMLZVoC9sJAdkIfiz4B1oweOpQ034G3QxloGz+lEuT0tu4BtA MrWD/F0P1yLUBk/3oFvEncLbaAq2g/coD90HKP8QnQ0652N4vwvVwPhmo/v5fBi1DJK5E1rcMzQO KXBdh97ABHygavDUl6FmfhxI3jtSy2CG54KOmgg68TV0bupOVAdrd1bqmtR6NC91f2ou+FzTUo+C /F2Z2o7K0RqhlcwU4nwpyNjX8B7QRwfwepDb49DfQR6FwVf5Ei7wZ9Eo4Wm0jv8byM7a1A2pd5EV 6JEDFFoAWvQo+GvfAN3Gcf2oZGgy2ZZq5DpAQx1GU1OPpPxYi5amzgPJ+wx6SCWA7OlGPuEhwC5S xsyYrtSOGlkzorqqsqK8rLSkuCiZKCzIj+fFcqORcCiYE5D9Pq/H7XI67LZsi9kkGQ1Zep1Wo1aJ As8RjPIbgo3tcm+kvZePBMeNK6DPwfmQMf+0jPZeGbIaz6zTK7ezavKZNRWoufhXNZV0TeVUTSzJ NaimIF9uCMq9e+uDch+ePbUF0jfWB1vl3gGWnsTSPSydBelAABrIDY6l9XIvbpcbehtXLl3X0F4P 3W3TaeuCdedoC/LRNq0OkjpI9dqDHduwfRRmCWJvqN5GkDoLBtXrCtY39DqD9XQEvVy4Yf6i3uap LQ317kCgtSC/F9ctDC7oRcExvcY4q4Lq2Gt6xbpeFXuNfC6dDVovb8vvX3dDn4QWtMf1i4KL5s9t 6eXmt9J3mOLw3vpe+2VHHb88QufmupY1p5e6uXUNjnNl+rhu3Rq5d/PUltNLA/Te2gp99JJwY/u6 RnjxDUDCpmkyvIusbm3pxavhhTKdB51TenbnBBtoTvsyuVcTHBNcum5ZOyyMa10vOuvSwHaXS9md OoJcDfK66S3BQG+tO9g6v96zLRutO+vSJ5yK7DyzpCB/m2RKk3WbwZhJ6LNOT5xzqoylWHWaajrr FF0xHVFwPMChV14ow0hagjCnSno7pxKtW1gJ1eDXiqFV7yJYj3N7NXXt66RqyJdo+14hLAXldd8j WP/gwNdn5szP5Ihh6XtEkxQlp4AG5cPp3ni8Ny+PAkRVBysKYxzFnssK8lf2kd5ghyRDBORDzUDb +a3VCSB+IECXd32fghbAQ2/31Jb0s4wWuLcjJRFv7SXttKR/uMQ6g5Z0D5ecat4eBBzvYFv11l51 5NQ/o2SzNCyt7sW2/0fxOenypmnBpqmzW+SGde0Z2jZNP+MpXV55qiyTwukCIHgvHwZKjQ8C9M6a 3UIz4J8Qbgw2nNs+DlgNxthrqWvh3KQ1nSJujnUF+J17qmf60KKnffFhkeF/UZ9KDQBmOVhu7JXa x6XvrdpA4H/ZqC91jLZi0S/NMnPqrY6f+TzijOczhqdfx8GA+Qhpmj573TrtGWWNIKzWrWsMyo3r 2tfN70t1LwjKUnDdbnBdW9Z1NLQPL39f6qn17t7GG1phEktxNUCboDHbgvj6qdsUfP202S27JYTk 66e3bCeY1LWPad0WgrKW3TLIZ5ZLaC7NpA8yfQD9BlyxnahZffduBaFuVsqzDPa8sA8jlqcezsNo YR9J50nDeQTy+HSewvLoj0qKuuktp2OAMVZrAdXsBHvAUvEIdK9ShSZtI/hp8hzYviry/HYk8H3k uR0c0qpoYidGTrUoPA/lBHE4hjR4OT4bOeLSDzWDNZOl4zWTBmtQLaSlk3ArSgZMAVMYbtjDo5My 139SobuIMt8Pg8+HFz4mLEU+vFS5WuXQVdkdnpGlDgVuTnoz+my2mKpGNV71B5WoyHP42eo59tmO 5eoLTRea79Hda9hoelz3uOE14TX7nx0f2D9wHJF/4n+yW63YyzsFt9Vpc9q9DpXGrnPovKXOsc61 9g2yyuEkxO5y6p1iFuckgghq0JqtsvBZfTAMjUbJ1td2a7CmjytR9JLg2uDEm5xbncT5FFcCM77x CUz0vj58o5KFxH9MscyzrLCssvCWPqxSLHRFXEhW5G6Za5c3y0R2Po1/AqpmYUXJngem7iqygTwP zsth8i0so9P/FLgFGMgHlGubdLRmYLLU1vlD26TjbQPSAJBxYLCts6Z2sHObSJfvyQ0a/Lxmn4ag ts7W+FGT2V5lMldhCFVESlfZcYXzRieUtxpq1kjCFXsMe4qSuLOrDbXheDyO4pgLlCFUVhoJ5oiq YHl5STGdvKgiqkBxeXkF99i8k0dALMr3/WbRpkjYue93Dx1MTnj4p1F4wXmzGl1YGDoRxmPwXX+4 6uGLOne/8k7PkiW/3zl0rFIqKoCpT0h9JBiF5SiEiTJG40vgBElwCf8dxo2+B4wPmHcZnzTr1D5s s+MruN9aL7HdyK2z3cvd4Xqce5rT6DkDT7zjwC0TEmrJFHKDWSjsJG6Mn0J9XNMu+W4h18PhPnJ4 J6hCCUt93OidG7I2ZZGsPi6hJLI15HGwdXGx9PhWE/abak3E5FIiOKKpkR3Y6PA7iEOflUVmOMaH Fy1kFI+3dU2iFP+hq3PSwPFOIPhg5/G245/WDnx9fABLA8cHpNeKknWXKrLVLepVYVdEF7GFRbem AOmtcFM7hQKstWcBE8XjlL7wu+oq3NmGujrbsCUYoVQm1myzraS4vMIu8kE5GikrNYdKiu2QVVFe wb/l94/69P41f79i5cBd175+qX/x0LGnh7buXrcL1z5764Y8szvbpROWD5Xs27V26J3DfUPf9XQ+ mr3z0Z+fOvkGnv70OJvFnaR+ah5YuzuEiagElyu1StkSz8We3yX/4Hg8+XTySJl6prND7FCtUq/S dIvdqg3qDRpNyO/2BnLCfnc8EFQrkkRmqAMGg1/jVqv6Uv1KgOaoAoT4RbfKI7kJDhqMRm8Jeihe iAqkAlLQR95WAvn5cZjeQ1735x6PV615XK0WH69VrVIRpJJUU1Qc9PWp0sz6Wln4eH7cX5CApue5 Hpfdivuwm3NPay7rKNtcxpUhSbRYyAxJbzTSO10nKScc0tO2IZYZctHM0H2lR3bjNUzgALVrBukN VrBt4Hjb0cEf4m1tAzWMc6SvpcEaiIbaaiBhrkqANKKcIg18jaTv4zgTx+NF4KngNmwK0PUoMQUj UVi2gCnbZiuhqwZ5wDJ0scrLTKXRSDBYFqArCynw5vMujJaK4bDBYD5rxtB7Um7lpxcsTY4anXvR ia+Sybhsd4WmJ3mrMWotKc49RyCDnwcLLxzKXegJ5g6Nnh21y4lRVww9HrZLykKu8ypfbnjob8ub rfRQEZWAWL6E7sihF5QVAbZCAYVSIKDkljkD802LytV+NwnkOPxucyDH6XfjQFDjd5sCQbOJEKwG MUcp6lRT4jl52tSZo+lQd6uPqLmUGifVzep2NTdP3a/er+bUPK2mZjRW96V+3EHbQmJI8TJwzJc7 At2BIwEuGWgOtAe4/sD+AJn/IbBRW2cXcBL82jo7u0D60wUB+tfWxBlx6T1sTVOQETBNQmswRyVa Tdl2G3ACuWTw6eT0iCNL689PJklD0bSIM0srx5PhcLhIvow7b0nAaXaw9MnbWJpSqDv1ES+AtKkk sxSn+fZ8bMRGouOQkc9FMSE+BU8hGlN1H25U9pdXlrs4Nz/PMc85zzXPLQpZggHl9VfzF+ouzLrQ sNLY4evwdyQ6kmvV1+nWZK0xXGtcE3+Uf7REMmeVZJVmlXlLvKXeMirQCnjZJ/tjsYKSUeCR1/JJ Z9KX9CcDI0tHlo3LGpc3XTcza5Y0MzYz7vVjP3GX+Mvc5dMd053TXa3Fc0vmls4tm1s+u8LA6XQx i84dC+rk6hGxZHWXucuyNnSX6q7ExuSjif7cF/JeifdXH6vOnqyudKMVxL0V78MEr8IZeahkld1d 5HF7V/jdPt9TXppT6rw7Ow+orzdk6/WGuD7PwEc0LBKDeBAhMbeIC+ZSOYkVX04pxn6Qjn04qEgJ 0/MmctiEZdNW02ETZ+oja570P+6LS1QPQgX/pkL8fOG3halCrlAZW6YU7oMHDhXKhcnC/kK+8Bnc iKpwIzi3aU3WFu8Eydp1nKqvrsGuqkQcWHKglrImVVqY3tYYCuOGK6Q9DiQNS1uWasNSJ6SZ3C0P JVWW3IguX1OCYsZICQ5Z4KZKwqO2QF+CdPr8eFTKK8FGQywvbA6WIHVCLMEgjaUaqSZ9w8NiGaRy W12LolmoW5y1RFoY59ta20A1xlEnagPrU9HrHMYqPmmsKoEAXcRbsSlYSECEWylMfSDpxGBONJJW naYSHwH5AJo0GglFQKqXp4U61aFhc9vjc5deHx/1xXPrm759ZkSp/yWX06sKh10tO8+74uaK6ujQ g7dOPPLH8y6ttLsCWpDv8TWbz141dVRJ0xWLz79t6t2HNUItqM+3brm5/drZxYvzfS9deMP0W94u c/oTFPmjQNr3MtnwT6V6Np5NZntn+5bj5WS5d7lPnQjUBqYE7hLudD8qPOxWEez12fxuKZAD0sEY CKocQeQnklEd6CP9ikWD40ixG2rNRuiuGW1FPOojuYpLrWECWcNkr4YJZE2O3eaP+6h+MNAWyCf5 5vk2+3jfUyQX2VJfKzoqK2xMiNig9yfkRW1pQX0cKL8b+VL923VltIPtOmMpEDh+VEpL8ONsZZCi K4MwXPQpEyODIEiw9BrVxJiaMZa0hA5S2VFSckqyUHkCy2Lh7zdGdBb/kunPuyNTEoMvJGeGbA/M yy2doIpIwsShF6eHqitOHL/CnxcOl8pdvN5gOW8uHkW/jBqfGuDWcltRMRrJjd9GqDWlyLVM5tYq lBZWt6owrNbpyIwwo0cY6UvAIVF0ZjOZUWKjVeD50A5KBEgcV6yUdiWsbkmVisWqgkJKP1kDTQpL kI+P5SdL9YoGOtUrXi+9m6BI35d6R/HRSno9v8qBHSzXwWo4pLBPVZPPowRw1B6Qu6DcKMT3Jgap JfhOfC9OwAODfX//wXh8j/TOXiqI3coKnWddCTFPK8dm2V/VXfuoZpeWM8fNV6ArSq5D63Xry0Sv 2VYt1XbX8hrPRGGi2CA35EysVmrXetVag0pGOeNxk3a8bnxZU0Vd9fiRs3RLdKs112qv1Rmn266x EX/tvFrSri5BpTWFsYLSp7Eb6ZE+1b9LU6XP1VXp6dxd1WWSvllPFLi16zmZRSv1vL7G0Zd6X4np qqY45jlWOLiEYxXYbFf6wdaDGSdrlBoC0+4o6AYbogzo1sc1KiZeV9hfgAvaw6gkS68vLQXCn4QV EGeUPI2XoBAK0zcaqlDYH+4O94R5JXwsTLrDOCzRSuGnSR24PFZApL/K2oeXKD53oqpIpRiqZFWz qlvFSSp8TIWbVVhVN6ruN2nx1tnVFQeDcSAuDYLW66JWSI2Uvn5oA+V3fPBomzTQWTvQBfIvbqqi deLxRNpC387pMdjnIAip8V7F5NzYshGeoGCpqCyvJKJGrVUTMZAj5xCxTFclI5PX4kFmi9Gf5cE5 wRFClQdVqktlXFaqM3skDzbkwK1arPEgZgxRkceEXzyel5d3FUi+LtyJOkHUgZxr2V5rxm2tuC2O ukDo7SiCmQIij2yXWLTLUFUhw9z7Up9v19PoiKLTVTlkcM0geCjaXboqLSxlRS6NtRBrIdZArGFC 8/RfK8wzLKpAaoJ8BAOqgvkdoPft2ek8JjPB/WLWFrW/rDQ/aoI2IHQhi4y9MVQ+ct5vfbE3vp41 rTYcIYlIONG76bLJIzxmrd0o6a01HYuLqvGd+VPqZ1ZOvPZ8k/PqZXVF9ZfMDK1dnJOTX11YXFow syfmHxNfPfTaNSOyVVk1lXfU34rbapz57VXj5lF52pg6yk0Azg/g77ereTzM+8QlMvtTZDJQZPwr 2sJGjao90BEgAQDzTsr0AS9w6w5LNpkBidd3UWngLeKAPYH14m21ewYwZca94Im5t5mDlAUuyCso RcG6rLZye9YsgXgs0/lpwjRxuqrF3eJRLRFWCt2oO7DD/bK8Xz6CPhE0FXgsnumY4ZkXbHe0e1Y6 ujzrzDdZekw9jofxg2Rr8An8An5V9arzC/VRz5fycewQyQTzLPN6/3q5O3gsqDLJ+JnUESRD8MNi Iy+izJOUArgdzDqCAlJAZoZdR6AnsDnQG6D23ZHAsUBWYLH3MBhWr9rCGhVM7/3t2VU0UirNVTBJ XeBNvx5P0W/QE31CQkmkoHbUgXpQL+pHR5CGZhC05QLXNS7S7MKbXNjVh/WK+ZiIkSiJspgUFVEQ 63LqdpOb08YD9cXaujoHO9uOdnZRsyEerx0Y6GRsd9Sc5iFFO8270HuBl7vVi6kvDFxUWVmJK6nr 1Ya7ELAbBTeSHFVuwOwuS5UgSVWYKh6Jorp/m5QGK463tuJOLALsSFkpYt5wWslH00jNTuOSmxB+ /5p7Psd4x5o/FeWP8Jl0weCoRSOn3r92weSKUjx350tYPPw+NmyYFElErCv9vgkL7n/wRF3hpTD7 +tRRsFNvAvVaQJoy2IokmEUfEx0MVOo0wBjYkOy1aZkG1clUiZgonmQ9BZrMakPujwqDpOygLWTP U9w/kJcKWXjy+s193D8UyaJoDGSGJRuFYeHy8zmmLWoPxgcSEHBGOxwE3dDPwAn6wZ2h7VlmaIVk HcfRpp4OL1a87V7i9eugG50N2ECcYeOp9IQRZtNYBucB7oSWyHKiMMbqsMmJM0QxUWiiKmpv3JTW VP1743FqDh5sa9tbOwCmYO1BeL97N0qk+p8YO7Y0QVlkTLywtD1xOX+5sI7vTmxN9CdUSqI7QVDC lmeNzxBmqKfH71CpxqmwnKjQjtXO1N7FP5K3OaHqTxyLE1lGcuApQLsOJFhDjTxFPlterD1Pvkze hDbJW1S7Va/k6SJqS1Q/2uyz1Fu9Udtoj89b74dmOj7fyqjmz8f5+X5O50e6gF6mysFsbbd127ba OL+tx0ZsX8WaRRjrE7mFpTR+cmyZWFdYtyq9twAaYrCrDcwX+qNbOV0wZZO9Svp+4CT+HqUjJv1d kTivjoYj6piM4jzcclVhGecJ+fLwvsJVV6G2SopwwHcn7upsA9kKkjUtRM0gREGwUrxGwyUZUWoX gmUmarxmMExereuecMeRH1+6dIpRdrjiWdhUYAzY3AW6oWOFYs3CREvDnN7z5ixpHHni5Zfx2El/ uHecSwp2nDh4/1iPKdj5Gn6/vqNqytI/v/43QPREkJfTuF6UjbzcFRlE56pt2VakNwIEkYFFBiYw DdakgrAMooEgJNHDvlQ/k5U0oZhMJkghnTtsUtE9A0J3H3bQ1iomXaGeiu9LvcdaQOL1Jyk38EU6 HRMM1PoBBFFUtYHnT2F9MN6f2NtPRW0azV5rN9oM4oiTmXTi0oNIvzG91xGiEJZUsqpXxSFVOyj9 zSpedQv/e347z9FXqWBqlBMjFM7Z2X4fzJMmYbYAezpbiAw2mmUw+H1plIPd1Z+G/f69MNa2PeAU FbOxwkgp3MFnnedoc7aj9uz3OMEpe0DFeqpsiqfKT0elrZtQqvZTFeFnEMstZdnT8gpL3aJT02I5 2zbPPtsxx6XCnEZUadR6wTpeXEtuENfo10mrvQ+Qxxw7Le+QD4x/l46Tf3EWc7uqXd0Bs1ureUH1 Z+MxFWg6Vda1hNNQPhGBTyaUaxrJWM0U/3QyXbOAdJG1lrXOjZYHNQ9q+9Q7Nb3aV8ln5Ij+uDZb vV+FkWq/inTSmNKuB4jWqxJVV/DZKGmz0qFazFXmedZV1k3Ww1beanW/zWNYwf2gQHhqXlho9L4y zlxFaTzXjemKqN5U23LdVUYbXmFbZdtg42zHs7O76WZFj5ok1RvUh9WcpFbUMBN1r/qIWlRvMVh5 tJbiistXzEmDYmg2cMggGWQDd8yADXQkGqCloc5X15TmTDDfJg121khgnLVBNAA2Gt0yogwKvNZl giUCO2mFFeykON3IBn+2s6uKuR+VlaizDde17BARJqSzlRl29Mesqd1IBW/TBav0SkFVFgQ11Ti5 Vap0RGXEdnf6yZ0uyzxp00/a9JOGPSkGTZVVclY5ZVNVFgQmCs6wsFpbWy2iPbO3mNZgZqrBwoFI 2kv9O160aM3s1QV+6+t3PfTVP3fd/crgGvyoIDkXlk+7hox488ILF16SvfYjjD/4Cqve2FLdEqpU rgJ7aApC3GXCDShO1BnuDhcwfVWgULVTwHwiN3hlBhGrDTGsps/YDLT+UjFTBjWYGeszJWUQqXrS gE7SqkNhnx0hY8zYh93bzaIaJWoH+qX+2r0D0kBaKYFK6pf2SK/Qaw/bPcow8m5kZG0QNFW8MTEE PaljmDEiFikHYkIZmQ3jfUXHuJHlw/Pfn6RFBkNB/rAKOkhv8Pq9e+m+BGXHUevljdaNEa6eq9eP c67mVuuFu3mcKFgV6BF7VJvUmzT3SfeZegs0kghyal7evDjxqA07fOpbcvAOn6qPUyv+oG+T73kf 8ZlCYTuON4PjksyLmU2iWqWVAOB9+KwnNoCz0kd+2I7z4n1YUrJyY9hsNEm3GI04RMH6RHt7KYur q9NxbW06DhWxWLF5AqU9BkwhPs/QYeg37DeIBmf+U5zIqTLbL2lQThoA6DKvpAaiT9uOdjF/uqZm sKumdhC8kgTdnwP9Yw5Hs22RsDUStuV6UDQ75MEZrUNVDd3LBiPpNHeb7oQGy0rAfGf2O7OY0gYT WO3WEit+2BMeNW3wYCx3jHP79padnee2VJf67CUT/P5IoeL5mps4+HB3Tn4olFu/gMweV7P2uYvq Cyp9ZYHzLZaiJe+NGUfPoUYONXIHwCYfgcajVu5O5WqzrfnOyMZyDhVIc8jKvJXTCMoTC8Wz1st8 bcWUOSsqLop0zNnAbxCusV/r2FC2btQ1DRuarptyu/12x8YpffxuYYd9h+O10tea+ufsn3NkzrE5 bpdsLZHKssv9c4RH1BPKa93IxpUHJriRs+6XryI0Fku2Rg0OozlMfXsz6KEwXY5sfS2NwfnX1W4K bw0/H+bCffi+nS3x7gAG1+CQkkXrmjcFtgaeD3CBTBsWQ5MA1FUcPRPwBHreNEGBrAn5lHUmNGfj 7D6sViwr1HiVGhIm6EZdJm6sw3V9XJGid07QJpy42dntJM5nyV+RCMw1CdVAkVZUOafiqfn5xknP cUnQdz64V6FJXFLxS0m8IrkhuSnJJR1Uvyb1lCWSZVWFXPd0PJ3OLQu4FRKv75CyWeIQ86OnU6dP mwWMND3sz8W5DIN2V+mGXDwltyO3P3d/Lp9roDWh6PgOyvKQ+EYxU4GRe5E8JzlHmbMZaC7MoU09 On3pHMOGOxpxI/PAG4tkGzbaOmz7QNj3pb5TTGwPSU8NAxsbo62PPKtYNtbi2qIk18yRZg4jTuII R0np9JayGHrl6OupmUwTT9I5cufOnvMUvgT8Ou22tY54/If0NnUX+OUsMRDvOirFO39gD/EuKv3j ndJRsN3aukAiZZTC4KdURdRKA3SfG6yMLonWh8qgJXbsCxwOENATXccHwCiL05zw4TDkdFHGy5zQ nTqlG/b3L2uaVd0QKvN47Q4sRMLFRSVFpUWcODoyJVIYzovMDE/3YM8Inwc1lU2S0RhcK6ORQq0H NRdM8qCz4tNlXO9o9OAZ0VkePHOWt9oN1d0j0MSiCTJumlBWrpA6me4T8jUePDkx1YOmxabKqMFe 50FMgwzvjWZuw2dX6V8eMP5VbNugjSq7TqbaFG2hBBgtk8x0n+DYNnNmh3R45xP0DjtGBT0UzPhQ zIW3s4uVULeKbgPAxVrh9MYq20SNRrB4+hM8l02fvXfzNe0vxg2cKHDG+MWVex6qH5vvDyQ9HX8Z 2bZi2T0nXljdpDOVqeaVxquwdcKi+tLmiQsaSoZ+TCSrFz2747GS0rs/wpNjt7Zev0cRRI3dpRXE cR3du7IjVdkmWcVzgiar46zOhbfMKi53OMJjNAv9Rf7g2WTNysvumzWm67JNs8ecvKqkJZwMjVo1 rtRm40HpoywQTv8Cb66cbMjoRm+lQhlX0pq0TBFqHSH67GDboA56lkJ5wkH3UpiH5zBQkDoiVFv6 aUYkUFoWLcABXq8nMwKsj0CBg/ZR0Jf6eQfNhcQPO2hBwTCPQeJrxciUMuuvAIMXNloLqtYMIQwh F0IUlYLiNZYpGmhbVo6iJm8+rwJYJxLUFwSt+/XXAMqMP8iMVmnPK8XSnng6Zy84iHtO8w1bSs2U JcvYHd4YLYVOaZemqJapXy1TuVqmlrUOluVgWQ6W5XBUVuAAyw6w7ADLDsBsjjFpA4nvdtACSJx8 kpYVFFRWZLQ2U9qZ9F5qdMEswI3cm95Hw3SHM1Gp5JVpK9vBbjaGjZHuyp5Kvreyv3J/JRcXcXNl e2UHzVIqsax2xHymPs6omHIKYr7ohBxtzCdNCAZivkgfZ1AKg2XRwtGlvrJ6LEfLEZslmFUmk6R1 OkKaHi3u1WKjtkO7SbtPy2upkAoXoECo0F/QXNBe0FHAdxf0FJDeAkwPTPsL9hfwBe0VD6+iG+LU oKSW5WA6pseVcMFcakxVVcwxTB+egajIdnkEtRh2RzyC04NVapfKS9Uz3d1jZ81d9PSykxqD2MSO 89l2GrBcRlezU7f0mQVzDSE3c5aZ8RjxpBVXj57c4bYYtEllaJRVKdZy/vpk0bIJ1qrGoeqRwWyH 0e+yJgzYLNw0uOCyhplzlS1Dz8ySHZ5QKBqRJuP6O85OlE4Z8pxd6A+FLNrKmdzItPdId9Vr4KYC ftGhHJLZVd+NQqAIvBTO5iwG96wA28kIOCiyAxYHpwENwmQ5JI4w4GuoF8jOIvpSf9lFa2uyHMMS HxL/2JFhtyPD7PbeTsZtMt0OsU8JrAisAjWcswJ4uF3EIrNkmddOOxBzRAtYg++BUN/bJh1sy+yQ pHfR9wJLgMyM008pTnFClsx4IMDutJ8dTU2ZxOjR6YTirKgQZyh0q2uzSOhLEZIDOSoLnd4Pioe2 1GhCwSzGD1mEwj6L8QOdWZofHJTxGf9AzpNpFgoFT+OBtI8JYz+4t3ZveqM5wwrOnhBuD3WEekKb Q8dCghxqDhGF3kJUYRYXl7K4sjodFyTTcTDMYqXQ6SoFBrFMyMmK+czAFlHnaNkXqNc79ZYemEoV Qjl6lcWs7dFgTRXVwdvrymikGGvLuOV6fZYzK+RQ4lUOtudfXl3a48DNDtzu6HD0ODY7jjkEx/bg 9gcYO9BhD1AeANU7kDZTQfPS0/oMM7Ap0f06cNlwF2A9s1FH9YjlFK4zR/QZXMfyRozIy6sZcaWz aPRQXV2hW6PyuTy5Bpwt3EQLavLyRgwFBuWZVQBkV80MPP/2fNlpDHUAQkYCao2AWiu+eRizdlgy htlsPfurR+bzsFNzLFIRjfVUdFEwQeJLJrX1w7DUU/BSNELi0E7aRi88C+JZDUGFLABQnSWbyehs K2RQ2Vx8yiVKr/Me6hWdJomjFoa8bLYBZ4FmCKky3lDaD2J7cnRQaSDp04qDJdJA0uvttjOEaS3b h6PYebLH3m8/ZufszAFpLKWxUl01ohTbt2ctKm+2Y8XebG+3d9h77Juhokof86km5OCYT4wGs6NZ oy2+7HoYkkrUIhzK0me6SR//lI0o7dHjZj1u13foe/Sb9cf0gn677TQopEVibc0viw9mCPNJ2Nqf ud7Dy/1bZ+nYodraQpfB73DlmrBJuOnE6JmVXra2nPK7sWmJhJEJITEJnsUs7u2MBre3Mg3eyvxa u4ktrWnGxOSwrk3SBaXLR3MUI13jZJzVihdVNA7XahyuRXOUAK3VOHrsaFZvNAPKaAaU0ROz6dsm DrebOKzbJw53AImfFSetO1FLu5kYZ83jrHm8gp050owKiTaroGeF7OS1wkM7rmCGBa1aQVg5+w6k wsT6MLE+TPSAJ92HnMzsKb+Y7kPOY/vN4DMrOlpVJpnyk4BRugdtcyaKG8ZRoSqPnT5DoXUSM/CU GStmrJrBzZgpji1yhPN1qpp8QcXO/BPU1GhrAyk62E9/w7YGBd1/JjNQpzbqHinO4leY5D21EaDU QPfQu04lqKbPmKlyFI01McSbZLYpLceZYRFnefGK0expNHsaPRHm8eWT6W3qlgpqmtHsirSNxhLf sdKKipaJVAPRzInDHASJH1npxImtLRnGMZ26SzByFmAKiM15b20t9SEAvb1ZTdNbnkeNqc9RA4QE hGTq850uh9MBBlH61+pWPKWq/a3f2rhugHgrtWDiWbinFQwVOeZz9JGTO3IqYr4iSCi6nIkx39gJ OaaYzw62yo5gPOZL9nFZO4KjY75GSCijgjOik0ZP982oV8cqJilVsVw1UoXHzpxFFyacr9fqVCIv qMY2FiUddm2r3e6STKFAUsYdcq9M5D5cphgrYoXxUGWyAndU9FaQCppnmzRrdGjiRP+k5kmke1LP JIImSZPIJODrXdm20kntLa19ZPYTAbBy+vCi1fH45OPU36qZJNFtNGrrHE1HNZMbzqmn5/v0V8v+ TQJa1dZkPg+pQqesoGE7KCekN2aFg5GQPuDBBmOOIXy6HQRmUByzjQqweJgZ9H8xhirKM98gUWtI Zf9FjpzKVp1mJZ2hTUpw8yJzwdKSmZdbl9zUNL4zYMvSlo8cqrGMCNi1vDs6s2z5REKs1Y1DRROr dEIgf0p52bQCZ1HT0IjaYhfTPFEjzo6TrxcZI3mL5l3S1DSj+vKhlTNlGxhNdiloasbrOgqVsnG6 +FATs6RCIdNZkFekePMrhqyzy92hkHvEDHz2nfmBjJbSgy/yb5BkJeSUJCtjkizJHI0idjeojbYg FQmF9CnoDcXUTCRlvvhi8kBtYy5L5ssNdtZkGxZPtuFPGmzUq4/Q6jbkZY29rCMv68IbYx5LjDkj Mco87ICLMg+tGhsWcjEq27S0RQx5SChJBYmmSKFHV0XFWc+BQpQg5KR9GEUTMoaKVa58wmRJIsEc Fgk8F9OZXku8/zT5IVEBIqUdl1/ExtkJG9vxYHsKRSzNBlCU7t8YUjPtqWaSQs2khtrGjrRsLMum plk2W1kp8rKaXpbhZYVeNlF26jUsLmJUmNAasVhZ6f/WgQGzrboMPBh1GeX/ZFlzWXtZR1lPmVDA Y4Wlu+Gpt0zsLdtfRnrLcDtk9JdxXrUt5jOmnZlYzBeakKOO+QwTgt6YL5h2ZoqieaOTvqJ6DwoW l7AZh4JBo9GgtdtCqh417lVjo7pDvUm9T82rqTPjjpV4Q3n+WHOsPdYR47tjPbHeGIdiUozE2KY6 MHysvTTt0MT/9w6N2eHkRD7s5OweLIgOwTXMxvQTrU74R09wmT/zP3ozwJGnZ/5iBJTgpvtvaTpP thl0RWOGRliUEi0/etLFK3UGyojZjUXgyWT4cODFppk1lw9dOsvvZH6McQq++IrOq4e8bTYvcNrY RXj6Q+NclM8ICO2j3G7gMyPyEn2G0zxgBjKLjm1y69lZl16iHwfpXTzlHVpIE4qFZvKsGm8Pq3VS GKU1Y/qzgLSL8cuBlYaW03ou2thNMeXisxnisvUSs+AkZr7xzA6gSZ736fXpgyemiii4QBeh4a3t BnO3FT9i22V7Gb+m2eP9QCOaP9PicZoG2yzranyDZq3xA7fKrxSX8ezAaZMfv2J9zUUUPx6vHh6N maeLHjfraqcAFHm8n96b+Xa+g+/he3mR/1pPNzEV/SY90Z86a6HfyVBnN97Umzutqbd56uxtet/4 bX5+/FmzW56lXwYhHoI/1U9VYF3LM8jFFSMeZXPFX0hfuE97BO3QmpkQ/TAQe81hQ4SEPRFtWIyY jNky8mKXjG0aSDlUkLJkSTJ2c3Cz6uwycgpwSx/5n/qxL2MAa4A6XNeimC4iF4mXaS8zXGa+xHaR 4yKPuq21Lf1toMYjmarcEKx080uX3vyibgjb/s5sbZWX2+kOeLY5s4lF0P4rl6/ct2rfZUuueHNa 2fIxm66ef+W5Y7mt963Z+tuT3Q+t/+OVP108uva+y/88dGjzS8dvaAenI/XT0ATuKcBaFFWRnAzW YiPY92fF2jwa0S0WustkcSKZi1mYDLbI7PMzme4XDdtrTO6yTwiymGHH5cbNvEF00eMYO3U5wPwo DBvKW0VVlElhxKQwwoBOkLBguQ0wgctUciItaPv7pVdAsCbO+GJgNypOndxJgVispZhkx/5a7Yhq GB3DrYXJSIuc1gEiHdQ3ipsZazLUyhUNUYSdBhiMjo6GDoCudK2Uloz41Inq/syRapyi+krtCIrW Kmm8NEdaa+Kvy8cj8mtHNOXPyV9mWpZ/gfpS06X516ofUn2h/kmTlRzRUtJael4pr4zACTWXGzNb wKxyXpdjAeMqGkTRwJSoD9UTczyX4wulckxHQlR0TE6HobjIr+3RknZtt3arltN+JRML/R7ALcvN 9FOg7gCmn9CkP5sRAu3VLzZlnBn68TlIRfohCxWH1Ku1n/JqOYNE7Z/0nxgkylRZ6nBpRB9JhstU xTJOZMGtRFMu4yJdofyrPzFge7MAQS5cYh0+hklvsUaHDZgS22n7PEJaYNJPJTOGDsGuyNgNU9bN 7by+Y8uE8txie1XTkOysiFqsUtDnCONSjeH8aYtGTZ2rtCQTIa6q671L55937TsDv1tlNRYMfXF2 iS8cxjZd0SJuQWvSYVg1tGVFsLpl8uLdf+2c7DCj9F4peRKwnIt3Dn8lkMeQLPrtpigzIaIOP844 XKf7J/5h68M/bDf4KWbY2YCfuU9+Zmj4mV/CKmKJc9icTwO4HSgCcDZMia6Iropy0VyVQ88BpPZS P2QAvJD/sB3o/o505kZnkHYXgbYrNKs0RAMdOEQYKYOzifkZdIw/Mzj7qd9GBTNNsJNGvz8v9ovK h/7ZSWPbKU3vVlaAkW0sJsVGhSjGq3mVkofn5WE/xSKz6q8LRqPy6IgvWo+0ujxTtixh3kH/LKlK 0mN9K8chFdjt80SsiFgs9OfhPGQK+f1+GXfLPTJBsgR2fL+8Xxbk9tjDp75bTFviXUc705ss0kDX QJspbXFXodM2W7pAC4N4s5YPfxE1bBvbT20hVpzufE+84NKKcaWh4Cyr2VqQtGSNGTUUb8xxaoWs oMsf1WIrt/Uvf6nLj5Y3ZMfOHho/MQoqNmRjVu/CzSM9VM0CXrJT/yQ1/AvIjQeHz529ihmW2ctO n3V6ZmLqrRYsWFjSwkBgGd5jt1DUMHFIxRCzfi06db7Rls3TA2f63yHW7h3cvzcxsCez/gdBniXi e093L5329KkTu1tPS7vBZ2aWnWs44aReNNuA6dBhndGNredm4/HZmL1O8WAR3q1zY4GJP4GZiwJD kGBJG8giGynDDiR+Zt6lxeL1nGYusq9Hagf3t7X1S3ulPW3DO2EgDty7URYMYLS+ah6eR0itd6Np o/N56/O2PufnTtUmL17rwlP0U7Lm6edlfe8AW8vqiDo4m9XhdHGY3rLdmzFnTWZGyyUJwaK+jA7a ts962PqtlbOek+1+E+n68NdKvgzAK0x4e73EizDmeSGU3WzB3RaMLJKl19Jv2W85YhEt7Z7H1g4L v8H0R7Ft7M/ZAIBgGA4epbCTBqDoKAboIQhmYAl21ARSrYvtZJdYg6Zs9mVDCfvKKUJPnMvp0RGe 8N57JbmBUaZosLu+sCXv5ooLCuwx/oWhtxsH/9Q6Kpa7YGHJvIVkacB27rjIORRVBKy3Qe42FCbJ DKpsUeYlqTObeDo5N7PnkZElsi+jQ48qFqY6Xayiy8z2V8zDcDMPa1tIHGebzebQsHI1OMKiTjY4 RG++Qaei33PspMpVrUWJg3H6zQEwXK008HVmnzm9/UG/xztNBs1SpT904dRanaxzGEJhO/Sa7lKH 1WyXT5ve5WP7frKL7fm5mHhyaZnlaFarIzJDniym9z0iZrpPSauYh/eWaYJhz2yORk7f2YCbxDwq euunQKwFEDIhBrKUfcVUhqPUVZGj7dGOaG+UL9VV+Kvlcf5xsuBSW6ZQ3RqY4gtHg+ooHq3yqetl Xdir7sMNikWLwmGnk83HoNVpdboA+8jOgHoxNuIOvAnvwzxmBytmpws81GZLj4V0w63XwlHQyRnY AegiL646U8bRP5wcrAH0UV9kIO2PSMxtPCXlQOtKbo/R5DG6PEgyuSWvBzFXhH5uh9viw1uN6a/p hnEIMk9VFsigE56iZdxCY8DmjxqGvilYeXnDpM58T8U4PLq1Nn5+U9Vs7rbBdzexb+he7B7TekM3 3ji62I3Dg7/rbi6fSFSTK0iYevJDjdxxwGjxKZsvW6OJ53HokiiOes1iNjsfyQYzbZeJJU00SViS 0GQxSxZDchsS6bdxA/Gv4apN7G1j5tsv/oVPE0febBO5rBgXI7OIxOBl9B3G7OwShEpLMk4EmIBt e2C1D7btZ0YXcGiv1DQdbHZ36kfkTB1DLjCEtVJm6+oxDT0dNsRvjxFLaaFtUfk1wmqRaDSCWe1U uzTxbFdEEzKHXJF4JS43l7nHmpdqlmrPdS52LXQvzb9Efan2UufFrgvdl+Sv1a513oXu0tzpuiP+ NNpf+okY1GjU8Xh+Xp4Wq4kPW5zZPgvKL/Yhs9bkM0fUstPlSuZps6FCfjwe0qizgXLQJM+l4bXq fIidWo1aHbSYzRgjMcq+rYLRRhPBKq+x1G53Oen3Fu4NWnxYe4waeR3ab8HIu6JWM0UzT8NprgC4 GhRv/D2jjI3yJtDcG+bl40R+bT7Jd5aU/oFud9GtrrauSUfbOo8OHm+jX4wNZra4Jg0ejafhd+ov n9Tpv3xaYyh0xCGm2teBpAEs9f/nXSWpa9Q16S3wOP0r3tZWC/3rOXpabrEway5C/55OFEE/Y/G0 7+opPitwhB6mR/X4MWtBQeDwXpNKnRPHeeFch8Y5tL5869QREyuSgapcrW9saPTQk8aAU7KXcLeF o95ow1Ax/jmWa9bossJh3hEw1J78zerr6/PzSmzGUa2byBP+wqBe0qP0fzHMIeTe8tPOecaa72HJ 2X8Y8/uPvS/SePe7O3NPXDh4g4TUBnjUQP30f0pM/0vewFADmiWhExcORaRf/rPizE9cJ1bRv01P /8fFLGxBR7l6tJpHKAzhPHELGidWoSbciaZC2XQIhZB/M38NyHuEfgPP0yC+mVQhDvInQDgGIR/C NAgyhAUQWiBMhHA5hKlQtxfCTbSP4cDdiOaqzkbzhVeRJMxEORAmQDrIf4zy+AtQANLj6DO8r4Tz ojxI50BZTOWFuq+mPqHlUC+H1ZsJ7S5A3VA+Cp51EMyqG5EbYiMEC+S7oJ9H6ZghbuJeoHNNfQvp lTCO8ZA+AXEjjLUe4omQPwXSIyFkQZsaUpVaCGkTpEcCbUyQ1kNogHY/0TZQPwvGuAjKs+GZ0Lrw 3iyI3bQu9Bnj/obd+G50P/c3tI2fjrKh3MACzJvOeXhOdPx0TP9DaKTjOz2kx8cCHSv5ZWz/Eciv wjlcCVurqzJzvYfsRR3c5tR3kA6K2aiBBtXfkA/m9zWEKn4Rcqq8qc9hjOOFHagMntUQHCzQPu9B 13HHkQJlcfEOwM0iNIoUQUFZ6mfyW+QVw2gszBfojaIw9laKPcBCCOpNY+0XIR//CXJBWqEBUP/p KToBbWDtmyCuA7p/o0apAeijjgboZzeEF6C9Hd6foDSg645nDj0Gdb+AsoshXAAYcUKwQ/l6hmFo Q9vDe0bTd6TXAUkMgxAo9iAUD4fM+gwH3XBg9N/Cgg2CHUIFBPreOyA8DWEyhNtoHejXBvV9MI4r KWYoNik+KDYY/gFPDLN0HS8A2lCMpXnmIbIYXQ8hG0K+iNB1mZAHdRm/0HWkY6a8QPum2KKYGY6h PJLGPf6WzpNi6rQ4KOSzdzMepNg6LY5R7NOYU9gcYqQflVPMpmk9HLMxNFB+pDwxHA+Ph/In4xGI ueXIQmlH1304HqbFqXgzCkPZROEDNJYvQrO4lwH/cyHdDHEF0Oc+xoPf8rejo2Q1Iqp+lA9rSXl3 46/iu2hQvYuXQX/9QMsIvxdtZPG7JId/FwvCY6kvhMfIlekwnD49/nXA/ekyGtNwetn/1/z/P4G8 JzyGFkP6S+HdVIp/F91CtYTqK5yEIA/HkL8dQjeEPHUc36VejvtUM5AEuDkOYQWvoGpBQRU8WKO8 lfFdGPJnQN8JfjkaAe043I/WcjPQ78XHUCn3LqwjvIu8h66hgfYPcccpHP0ac/+JJRYP4/X/ElMe yBqOGU9VpQ4xvqpKHWY8WZUaSseoiuoGKp+ZfkBMNpuG8XoKl/eiCPf9afj8FU5Pw+cIaCf9Gpen xQYaZ3RL1jCfQhsb1TV0/kw+zmT8xOQclG0frv/r+FT7LaiPbEkdYHJ4L5o9zNcQiiCEofyljBwB OQzrTXXmjam54sWpudyE1FyY5y5xDcTfpZ4g0dS2Uzo1jIozssw1rEspnYS9yHNKj4bRlIw8C1N9 yj8KOjytRy1Mf36GHMJ3TLYVs/FSPqQ8mAC5FwU9/kPqZ96MfsOtBZMF+JLmA0am0jJejazcRyBz J6ALuftSb3M3MxnUwA2hVi4OPAxtgWYOgSCPUI+aoA1i/dE6ENM8On6RB3xSWTAOnmGthuUyXXvx Z5QFISp8A/JoJtTZwuYaZnL8LhSidGBtLwK9An2p4sjMExTP1AmzNueDvcDoATLwNFpkdPMo2qd4 FsOskbUpSf2sNqMqGoSHUTm8P8zeNQ5Vq6tQRJiZ+obZFWY0mXsVJblxyA9pF8P9GtBRMdCX40A/ QuA+hjAE2JTSz0xXszj1E9P3q5g+1wsJNIvZE7RMRD4xhgpp4INQ1o4KuIehnxWAq58h/adUitkH B5GJvhvyGzP2CbUTCOOXt6Dda6iA8hgdA9M3dDx3A972IT/ViarfAw21lAcxBnp7MnrQDM8E4g2n hZ5M3v9p72yAm7quPH7uu0+yjJAlDKEOxjxLssCO5NgR5SOxgiUjQ0De2ASWWG5a2RgnTUjGZmXT SRdi2C7ZpC2FDWySkgS7NFCmxrX8BMQYNnjbSTthG2Bnd7K7WTaQNJ2d/SzNB510Dd7/vZKMLcwY WnZmZ0eC3znv3HPux7vvvnvvA/tpdkIzu/KPtFb61tBF5U2lT3lzZIPYB/L3KMJfx/XrIztvwPr9 FtbGCqzhK9FX56ien8GxA+n7wCbs/drJqlppPf8QcV742pDvHZSxH37Bs8hzHvpHdD8/TY/zIewP PhR7BLKrHdBfBkFayg7TBuVz2mBciDW5YuQ1Wb6gfeRLkv1YNz9M5k0i25piojY/jb3dBO2VbR3b TtHGCdonyhDlynyIUVWyEo2cB66EvrpK2UE9oFt5D7F/QE+zQyOD7FVaxn4JXk3SSw9I3Q9W4R5b wDaDu9UF9AbYhmMP9JugL2HTXvBPYDvK/ivouFG+nJWRUoXxDI20feBl8Ncp31hEXROlj8WQPzI4 zj6KtQawT3EOn473yTq30ULUt1C9f2RQwP8VawgwdtKMrE00g89D+hzkS7MN+ZjnjlLRZO2ZDHaW ymUfJvDfzDneLOLeFevz7SrvZsH17QRflm34L8zHcgxRDnt35Dz0WvYu1u0OzKUAdins6an+TF0n pO+W6WnXD2MFj6kjv0lPT7fTr+tkthKnyFhS42B0PLxASwRqJeJBum16m5YIjG/B99b1tvqDSWjA HmWvaBPG4LzrbWMtzRMoRWjrLJEH9xwYtc9iXgUiVua3YL0E8t4FyhGsxWDUvwBzPhjTrwtFv/K9 CX/q+qSuS/r1Qfv86hnQgP3sGSqHXg0dSOnR8Z2cL8aN+VWJ8T5qi7nkl2kx1+6Ja/cG7pUblfn/ Cdw7p8HPwE//t+tihLEKbEDuUSvwDL4Ae8+14p9qrvycaHgG9HSsC7jzhi/i+O9wvE58Qw6O30Da y9DPQWOqGb6K9BGsIxx6nzoL+3ei5wDKuNqWyHvlMvhaoowrJ4j++x+StCfyD38bLIMPO7PhI+AQ +BEIIk+qnD+HvRH6J7CXJ8oaxvGVD8CfgRB4KaGHvwmEPxt1/L3Yj0zwHHpb9Y2eP25WJ58zfCl9 3TPEreiKm9LjnjlS138ynXqWmEDLfki23zimPTd6xhmnMX6yx4K9tFPsKcU+Wuxlxf5Z7B9HtXhu e0Dq6clyUtoq1kCxdxb7V8N8+e+N4hnIPeZ5sDq1boydW9mntA/YQH5Sb0DM53jWOYO1yYo59TOc 3+sCubaJdQ2gvWel/92RUyIG+h3YBdCfpda01Nx63Rw7yZp2u+1bXSN/hzXVmySSxo3SUyxOskKQ vhbfKpOt3b/zWn6DNXrsOv372ql1PsVk+9Lr9gGT2JOVd6t2+r7jlu20fUnKTuc6f/rYS+1nZuEZ OEXafXeriGcL9ei1vX+qDen38ej9lnpG6MSaOgbMA8VYs0rAfswX5aAA5IIXkPaMaZi8pl7ywj4K jiHtP6HXCx90F9uBye3yyBXYfwLbpr4jY+uTrJ9sPKePW7E/l/tD9JmcB3eJ9lMZqAC5oB88lbrW 4tkTdf+LcpJIPOeqDSOfqWdA2h5wUr2ANoJe2FbY1uR/GG26/SjLfn/wFC0xvDAe45GbIxt7GLG8 3So5VxNMewTbqLuJ8nKIZqFe7S4iRwORy3aNuf9B5MZ4KZtDdA/2PV9cm2DhswkW4/m+Yut4lizJ kCFDhgwZMmTIkCFDhgwZMmTIkCFDhgwZMmT4PwETv1lEH5OPNlEWKWSjMvG/74bT1unESRmkNSND /IN4dbXXPwDtvltqvbjEe1w49FmzvX/JP1AO0zzx5gp+QZ+ZLz3v61VVyYOFixMH8btKvRcCU/j7 9Cug8Pf5BSpO5IoX3+29FLAggfFnyMoYadTN/5liQCE/fy9eNNfbdYr/HP7T/G1aL7O9rVumeVHg z/gblEsaP8aPJj1H4znTvBSI8h04wSHIc+AiuARUauU/oE6wE/QBlayQGigDtSKF9/AetPMA8lsh y0Ar2AlUWsN/iPQNQvJD/AlyIO+3+R66A/pbfLfUr0PPgt6P9DnQ34MtdFfSfgVa+Pcm078Leyb0 y0n9EtLzoV+ELfRfJO1NvEPma0/qbh7V52i2wBz4C0E54Djag6M96Lo94tfRIBn/Bn9S1tQP7YV+ KqHRXVt0u1Neoy3xL9zp7UaXbkHXb0HPbUHPbRHvJeGbUzGbEzGlfDNiNiNmM2I2o1fKeRT1RcUP nkDaQCHg6Pco+l2kxyCHwDmZ/qeQu0C3sPjX0I8laNXz/Am9WMMgeyx+r99beYI/iq7280fjdxZ4 d16zsqeIgQidk9RWEdsivS3x7KkitSU+qyChEbUhkMOb6Y+BQjMgi8AXQRCovFkvKtMG+YP0lIn8 OVqn0sk71U6DWh5kuae4l+pMhCGZy0vJh4ASLeJjixqz27K3ZnNbdmF2ebY/uy7b0Mo7+U7ONV7G K3ktj3CDeBdk1n3zxe9ZLjfeN3+XudscMw+Zz5kNMeOQ8ZzxovGS0ZD46pc6Y6OxzbjVuMvYbcwW 71lXGs1t5q1mbjMXmsvNfnOd2aBlse7Adr5O3LaQNtAGdgEVfRxBeiH/CojgakTQFV8RP70KSbBs 4ByOL0IbYFkRZ0WcFalWpFpJfOutVXrqQCNoS3qNo55UHhF/SXiA+OH/HKTmoG8vQl4SR2AlLAss CywLos4pw2ihDbIQ1AEu0y4CjBrIlK886W8ERum/JGNSPr/Iqwz7m+YNlbBYCesuYbtKmN9XGfD6 HRC5ubkRZ8QVKY4cUFudra7W4tYDaq2z1lVbXHtArXRWuiqLKw+oZc4yV1lx2QFVc2ourVg7oO6s 6as5VXO2Ro3UtNZ01vBF4n2NurvcK7XDJfRR/c5Z3kXWQIXSh9OJQHaBC4CTBlkGKkErUJU+SE3p RWovUnupFkSAATl6xfQCqSV9Ir1L+sSR8Cvj/Bwnfli/b35tYCWm3AjoAhxlH4b/sIxOHPXJ9Bjk RZlem4zvlukaZCoPxwTXIKe5Btx+DVQJIqANGOgsf5guAJQMqYE20AdU3oA/D/OHlV78Oawc5h6/ 5Z47NJo5k4hyp5lsAZsyFWPAwg5J+bKUz0tZKWWRP2el5fJKy5srLc+utMzDgVJMATj2SGn3mwOW IwFLbcBSErCgtC+QnSzKHVIahWT/LuWDUnr8M+yWz+2WT+yWX9str9ktG+2W++0i32zcuxZlhpRm IdmLUq6Ucq7frFl+qlke1iyLNEvAwvYx1E5VUs6RMl9I9vERa9BK2SfYxxRESUz3lWgDCknFRnRf AOqq7lsOdUX37YP6re7brZ1knzO5pLHLetFHWuAO9ilboQr7k6T+NVtBPdCXoB+DPkg+5oJ+Xfdt E/HfR/69sPeTwyTiv0d1Ml8XWyHTX0vme1X3rEOtr+iep1HrXvLIWl/SPR8hdbfueR7qBd3zJNRO 3SUa+ITuu0sLTBNfD6eI2GZyKaIlNckaH0DJT0IvT2Su1j0iV1BUMMCW6s57oOaJVp5kTqqT1Wm6 U55kATllEbPJKRudTy6pc5hVNt5CDqlNunMbSjEecX2k/cZ3Qpw4fcas+j7tFydxfmthfshW6D3a 3xwX3aVrZz0DzHVMO+M8ob1VNMDW6tqQZ8AExynPgMKOav3o5BhiFXZM6/M8pvU6pfeAE15c6i5f qfaKs0H7rgu2rm3znBTNoKdwxmvhDnuWaDW+Hm2Za4DB7fehMv8U7T7nH2n3InnxAFsR79HuKRoQ TSlHGT3HtLtQ41ynbMofLhpUFlAW6/B7stqz1mWtzVqVVZE1P6s0qzCrIGt21gxTrslmyjFNNU0x mUxGk2pSTGSaId6I7pbvfTHKX/02qkKq8timyFd3JH5JXGEmBfdObDoPKaHVVSyWG6LQmqrYIndo IGvkodhidyhmqvtSfT9j3wnDiinPDTBaU48BKpK258dyxddPMla2fUe+0Ju37wiHWSg21EyhdYWx y6txHlNWNcQMzqo8mrmpMq8yd8m0e5cFJxCNSTnmhfl57rGfvILYi6HV9bEfFoRjXnEwUhAOxZav Lnyk/riyUWmtDh5X2oQK1x9nX1c2Vj8k0tnXg+HRMHIobQgjn1AiLE4OEUYOFpdhNTIMw9RRHex3 OBJBP2YrRBCGz49l0GOJsopQBcqqEwphyhwqkmUVKXNEGMZDojDr2MKmErPKwqxTSRY2WwT1u1wI 8bhESP8iFwL6XYuku+ea2+lKNCdMLlmPi4VlPYxdiylOxGAUJGMUE2Lct/PTUnULwSzedH59c3WL s7rRWd0CGmPf2vTVvNjWdYWF/evPC0dhjM9tXNf8VaGbWmLnnS3B2HpnsLC/qXkCd7NwNzmD/dRc vaa+v9nfEtSb/E3VzqZgOH6wc2loXF3Pj9a1tHOCwjpFYUtFXQdDE7hDwn1Q1BUSdYVEXQf9B2Vd oYeqWKiuvt9EVeGljyR0XDFPwf3QmG8PV820tS2RN0eFPe+Z/EGVsGyZ3eHYVGdVzAKEqzRQGhAu 8TNlcOUg2Zp05T1TYc8fZIeSLhuSpzmryE151Y8HR/9Go9F2QUeHG7K9I0+mteOmta8OxZataqiP +WK+6pi/MRiWLzfqSH6W1vttp3xnfUqrr9O309fl6/MZOjrCSM495TjrUCKOVkenY6ejy9HnMArH I/XH/L4ux68cvAOjibXjUx2UdXZA468w2zui4kOoIAoS1bk73EvrAw5q5uKL7DnkdOAE88FqYKCf QP4t+AX4BKj0Dcjd4PsgLlJ4KS+tzns8KGoMu8Wkk8e98fIF3sUD0E2PJvTqhoSufjChfQFvHrRe OX9KwIqNN6NByNPgPfBv4LfAwL3cKwvvSIzacJSibobmi7cRtgsRdbfL74hiorvbo243ReWbopDQ HpXvzx4/7olFOwhdgQsChSCZGhXZOoS+Fvg/xssarA1lbmRzdHJlYW0NZW5kb2JqDTEwMCAwIG9i ag08PCAvSGVpZ2h0IDk1IC9CaXRzUGVyQ29tcG9uZW50IDggL1N1YnR5cGUgL0ltYWdlIC9MZW5n dGggNDAgL1dpZHRoIDE1MCAvVHlwZSAvWE9iamVjdCAvRmlsdGVyIC9GbGF0ZURlY29kZSAvQ29s b3JTcGFjZSAxNSAwIFINPj4Nc3RyZWFtCmje7MExAQAAAMKg9U9tB2+gAAAAAAAAAAAAAAAAAIDf BBgAN6oAAQoNZW5kc3RyZWFtDWVuZG9iag0xMDEgMCBvYmoNPDwgL1R5cGUgL0VuY29kaW5nIC9E aWZmZXJlbmNlcw1bIDMyIC9zcGFjZQ1dDT4+DWVuZG9iag0xMDIgMCBvYmoNPDwgL1N1YmplY3Qg KDJuZCBJRUVFIEludGVybmF0aW9uYWwgQ29uZmVyZW5jZSBvbiBDbG91ZCBDb21wdXRpbmcgVGVj aG5vbG9neSBhbmQgU2NpZW5jZSkgL01vZERhdGUgKEQ6MjAxMTAyMDEwNzU5NDYtMDUnKSAvQXV0 aG9yIChaaGkgTGksIFl1ZWJpbiBCYWksIEh1aXlvbmcgWmhhbmcsIFlhbyBNYSkgL1RpdGxlIChB ZmZpbml0eS1Bd2FyZSBEeW5hbWljIFBpbm5pbmcgU2NoZWR1bGluZyBmb3IgVmlydHVhbCBNYWNo aW5lcykgL0tleXdvcmRzICgpIC9Qcm9kdWNlciAoaVRleHRTaGFycCA0LjAuNyBcKGJhc2VkIG9u IGlUZXh0IDIuMC43XCkpIC9DcmVhdGlvbkRhdGUgKEQ6MjAxMDExMDIxODU3MTMtMDcnMDAnKQ0+ Pg1lbmRvYmoNMTAzIDAgb2JqDTw8IC9GaWx0ZXIgL0ZsYXRlRGVjb2RlIC9MZW5ndGggMTQ3MQ0+ Pg1zdHJlYW0KSImMV82O2zYQvu9T8CgCWUGkKIlqT0nTBi0adIF120PTg9byX2NLjiVtsG+RR+7M N5QsZzduYcDSkMPhzDe/Wvxy8+Pi5s3iJoltYq1afL4xSZx4ldBP3jIXJ4n1Xrk8iQufZ0YtDjd/ RUt966OqaVptXdQzoSp+3fMr/rAjbL02ebQ6Mx2PJ00M+N+BY5KyYlYV9lt+4DC42kYRX2yjdg1Z 2qZE/HDHDL8Tp2J2XNPx8YHJpTYZC82I/W+1GA2+JeMSTxYvyXZjMrE9Ni4l+369goIrY5u7JBcU SA+Ts0KaBNroRHfTQ610HvvoMWyuwvPE+vroKZDq3UBqxX7a70RIP+7/Jvz3sqzYrp0uaKWZrXTt QS6VO9USj0o4unErXBCrxZaQBIadgieq46Qeo37JLwqMZDPpJwJGLSzhxjd68JBJxSXWc6izzPgA tfHli1CncVlaQjot4tJnWSZIV2vN8tc7iYBmB7IX6kmzJrdYqvD/WWf5RJy0+EG9lRdhb2bsB9kI wpfYV3dC7WbcjU4tLwm1EUrdg5JTW1lbgaixMcjS/qtTndz50rFhrx3Ik3aC8ddwOoEzTfPiPyJ3 hNPmscvTkL0fIp2a2EUAxEV37GgHAF10j39Wy5Fa/L7Ce433Af9sCynsyBgmP2ihYvWnvKxEIGU7 yB0EHOQy5LAB8E4cSGs9HOYokXhVtQ9suIv+CYKWPaHFjN+JQPXmJAy7Wp4bCso0zsWDjvyExybc 2G8v1bqAU5BMsjKdkLxeAkiR0pk8lIBurDkHzQWxlzSlioTSpzacZdVRPfATfOD4rF04hr9GvaPT w8TT6cBHRYArgGUsm1r9wYLfM/n+FWWllRqYSnmUu1E5maMeqPaZsLVRgkjV8IHyhYgKMJTl/4yn hJA0JTeNMT0lOZGa8Gv0dMuQaI9sxMsJjUAd8ADPFup6iq7UcrxwdRup43iCGR5JcXa3j+QW/iOv l4inCB4myczUV3yGIfzYoZswAwI2Wre8wBBBBTAGj1kOPiIh+KUIydL8xQYZAElLE/syL4oAyEM7 9KFLuXmPqtC71lNTa3aTEk8TP8g2uBv+/l690bcF5c2J7ZCT/EYQUCaXEnIN/224XEdqOErUKGnR j6G5ZtScgcml/401V43zVGsKl9pzzCO8t4jWepg6f1CMffNKc3y+JdY7vvb2Xk5MMc5VbgIBaRJC uhsjWAGG7Xk4EEBmYEopCbNIoB6k2x/PqjRyH0S2wO8r803hs6vm5z721LmCb4cmCG/OxojwBvmY 0aQiSpxV/dKNA8ogx2Z2q08Dxp5BDtVP/Giqg55XEsTqfi9xQvuxgPWT5EfK/ftZThuJXEuJetW8 rIhTW7rg3X7LzdWQl6m0GqQhPQb8o5WaSJbaOdvqlbZgRyU3aBpErcUpO1DhdCePXrZQInGgmC1K yTZSsol+r0s0DSwuw6Z0IYO8d9HrGvrUc0VX3Xil2CKNz1ANZabX3LiYVK0ICtq+lP42S+z1BkFo eltYlTqa6pKi9AInqlgrGTOOwRwMHQKxDnRqxc3TSHzE3IsJOEy966m8H86LfUhDzmkkSrPZn6ft aVzm7Vk1CcGz0FNCcuBV4Ftf5vFOehZtPD2bomeNw9j0WyEmoKSkCX0+OAGFZyGuxqHAh2oc+sau 1aG6qV0XLCNi3429AH1iyayf0DZJX54HohW3B2q13AqCcF5V5+7guDt4RGD0URqD3LDCfbz3oPkD hkGpBWYCuX1eNMTsPPtm4RCzrY2L6aNJ0n8GvpS5Ch8pHwF5i8lgP00G9UZ8018WT6h+tZXwobMX wdlK4xs/yMI31azyhmLtaRK89LIfZyNzdWZPDQ2VNLOHyL8fewTp8rzaq+X05Xf+aJSkqKQJv+YV VNCfQctX4SOLgxzOHZOE2osB69xB0ZI6ZFw8NSJAd5xAxC31rGUp+KO5ADs0S/WvAAMADMtYpw1l bmRzdHJlYW0NZW5kb2JqDTEwNCAwIG9iag08PCAvVHlwZSAvRW5jb2RpbmcgL0RpZmZlcmVuY2Vz DVsgMiAvZzM1MzMgL2cxODYyIC9nMTg2OSAvZzE4MjkgL2czNjI3IC9nOTYzIC9nMTQ4MiAvZzE0 ODggL2cxNDg0IC9nMTQ5OSAvZzU0MiAvZzE4MjcgL2cxODQ4IC9nMTgzMyAvZzE4NTUgL2cxODQw IC9nMTgzMCAvZzE4NDIgL2cxODQ3IC9nMTg2MSAvZzE4NTYgL2cxODY0IC9nMTg1NyAvZzU4MSAv ZzMzOTggL2c1NjAgL2c1OTYgL2cxNjY2IC9nNTU5IC9nNTc2IC9zcGFjZSAvZzM0MTAgL2cxODQ2 IC9nMTgzNCAvZzE4NDQgL2cxODMxIC9nMTg0NSAvZzE4NDEgL3BhcmVubGVmdCAvcGFyZW5yaWdo dCAvZzE4MzggL3BsdXMgL2NvbW1hIDQ4IC96ZXJvIC9vbmUgL3R3byA2MCAvbGVzcyAvZXF1YWwg L2dyZWF0ZXIgNjUgL0EgNjcgL0MgL0QgL0UgNzEgL0cgL0ggL0kgNzYgL0wgL00gL04gL08gL1Ag ODIgL1IgL1MgL1QgL1UgL1YgOTUgL3VuZGVyc2NvcmUgOTcgL2EgL2IgL2MgL2QgL2UgL2YgL2cg L2ggL2kgL2ogMTA4IC9sIDExMCAvbiAvbyAvcCAvcSAxMTUgL3MgL3QgL3UgL3YgL3cgL3ggL3kg MTIzIC9icmFjZWxlZnQgL2JhciAvYnJhY2VyaWdodCAxMzEgL2VsbGlwc2lzDV0NPj4NZW5kb2Jq DTEwNSAwIG9iag08PCAvSGVpZ2h0IDIyNSAvQml0c1BlckNvbXBvbmVudCA4IC9TdWJ0eXBlIC9J bWFnZSAvTGVuZ3RoIDI1Njk2IC9XaWR0aCAzNzIgL0NvbG9yU3BhY2UgL0RldmljZUdyYXkgL0Zp bHRlciAvRENURGVjb2RlIC9UeXBlIC9YT2JqZWN0DT4+DXN0cmVhbQr/2P/gABBKRklGAAECAQEs ASwAAP/hDOFFeGlmAABNTQAqAAAACAAHARIAAwAAAAEAAQAAARoABQAAAAEAAABiARsABQAAAAEA AABqASgAAwAAAAEAAgAAATEAAgAAABQAAAByATIAAgAAABQAAACGh2kABAAAAAEAAACcAAAAyAAA ASwAAAABAAABLAAAAAFBZG9iZSBQaG90b3Nob3AgNy4wADIwMDc6MDM6MTUgMTU6MDk6MzEAAAAA A6ABAAMAAAAB//8AAKACAAQAAAABAAABdKADAAQAAAABAAAA4QAAAAAAAAAGAQMAAwAAAAEABgAA ARoABQAAAAEAAAEWARsABQAAAAEAAAEeASgAAwAAAAEAAgAAAgEABAAAAAEAAAEmAgIABAAAAAEA AAuzAAAAAAAAAEgAAAABAAAASAAAAAH/2P/gABBKRklGAAECAQBIAEgAAP/tAAxBZG9iZV9DTQAD /+4ADkFkb2JlAGSAAAAAAf/bAIQADAgICAkIDAkJDBELCgsRFQ8MDA8VGBMTFRMTGBEMDAwMDAwR DAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAENCwsNDg0QDg4QFA4ODhQUDg4ODhQRDAwMDAwR EQwMDAwMDBEMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwM/8AAEQgATQCAAwEiAAIRAQMRAf/d AAQACP/EAT8AAAEFAQEBAQEBAAAAAAAAAAMAAQIEBQYHCAkKCwEAAQUBAQEBAQEAAAAAAAAAAQAC AwQFBgcICQoLEAABBAEDAgQCBQcGCAUDDDMBAAIRAwQhEjEFQVFhEyJxgTIGFJGhsUIjJBVSwWIz NHKC0UMHJZJT8OHxY3M1FqKygyZEk1RkRcKjdDYX0lXiZfKzhMPTdePzRieUpIW0lcTU5PSltcXV 5fVWZnaGlqa2xtbm9jdHV2d3h5ent8fX5/cRAAICAQIEBAMEBQYHBwYFNQEAAhEDITESBEFRYXEi EwUygZEUobFCI8FS0fAzJGLhcoKSQ1MVY3M08SUGFqKygwcmNcLSRJNUoxdkRVU2dGXi8rOEw9N1 4/NGlKSFtJXE1OT0pbXF1eX1VmZ2hpamtsbW5vYnN0dXZ3eHl6e3x//aAAwDAQACEQMRAD8A9Sqq qoqZTSxtVVTQyutgDWta0bWMYxvtaxrVNJJJSkkkklKSSUXPYyC9wbJDRJiSfotSUySVazqfTarT TZl0stB2mt1jQ4E/m7S7clf1Lp2O815GVTS9upZZY1pAP8lzklNlJV78/BxyG5GTVS5w3NFj2tJH 7w3FGrsrtrbZU4PreA5r2kEEHhzXBJTJJJJJSkkkklKSSSSU/wD/0PVUlnZeZkPyH4mG5lXpNDsr Ks1bXv8A5uqtm5jX5L/p+93p0s2Ps9T1GVrIx8s39V+yOyMvHc2s2OyLrq53SzYxuNWLMDbsf/o0 lPUJLPxMy9mQ3DzHMtNjS7Fyq/a20N/na3s3P9PIr+l7XbLq/wBLV/N21VVuq/XD6t9HyhidRzW0 5G0PdWGvsLGkhrX3egy30Gu3t/nvTSU7KxfrSAaOnSJjqWGf/BmonVvrX9X+jurZ1DLFb7azcytj H2u9Mf4d1eMy57KdP51/6ND6n1b6s24WBl52ZWMO/Irsw8gPIqNtW7Ir33M/Rsa30X7/AF3en/g0 lOT0jFusvznM6PiZlZ6nk7sq2xrbP533P9M41rv0X5n6b/B/mIgxr7es9cdX0jE6kPtlYNuRY1jh +pYH6La/GyPY36X0/wDCKgep/wCL/Iry+o09cy8er1t19dOVl0g23Hf+gwmGuyz1nb3/AKvS9XMq 76nZTWdc/a+TiUdXsht1GXkY1Lra6xUXWsrdVXj2NoxWsf8AaG1fzaSk+dRbZ9aMsU9Mxuo7cDD0 yHhmz9N1KPT3UZP0/wA76H0F0eIwsxaWGpuOWsaDRWQWMMa1Vua2vcxn0foLmMOz6pfWa1+X07qe UbsWium91GRk4zzVXvspfewmi2/b69v6d3+kWni9b6Fh/Vuvq4zHv6TWwRmX+rY8gv8ARa6z1Wuy nu9Z2z3MSU7KS5TO+vnT8H63noWTayvFrxg6y3ZY6z7VY9gpxGCsH/tPZ630HrRy/rn9WcLOdgZW eyvIrc1lvtea63PnYzIymMdjY7vb/hrq0lO0ksnqn1r+r/SLrMfqWazGuqqbe5jw6TW5xqY6vax3 rO3td+iq32rUre2xjbGzteA4bgWmDr7mPDXs/quSUySSSSU//9Hoetln2qkZ0/YzmW/bOY3bmejv 2/8Amt9D0v8AgvU9NTYzoh+sWQ2wY37M9D2j2ejO2n+b/wAHv+n9D3rduqe9w6p0s15VWTW11tBI 9O9kbqL6bvcxt2w+x/8ANX1fo7P8FbVjMwMhub9s/WDluMOoOGz0yNG+nu9X7I1vt/nPtX/XUlNb oE+oRi7vswzavskzExkev/I3/s3+f/sKf1PfhjO+truoOrGQOo3HJNxbIww39V9b1P8AtK2n1dm/ 9FsXR4WJkWXtzc1jKnsaW42Kw7m0h38691kN9XItj6bW7Kq/0VX+GtvF1H6r/V7qmS3L6h0+jJyG x+le0biB9Ftn+lb/ACbElOH9VrGv+u/1ode5jsh/2R+O4EHdjGt3pGn/AIPb6XrbP8IuWqqpu6Ng 0hgs6VZ9cWswa3AOpdiOL2hlLD+jdjOf63/B/wA4vRep/VX6u9W9H9oYFNxx2hlJjYWsb9GkOq2O 9Fv+h/mlZd0jpb6MbHOLV6GDYy7EqDQG1WVz6VlTG+1jq9ySnnxRQ/8AxousfW1z6+jNfW8tBLXH IfUXtd+a/wBJ3p7v9GuWY3FGD05uQKxjD61XB7bNorDZt0cH+zavTRgYQzz1EUs+2mr0DkR7/S3e r6W79z1Peue+sX1XryD0qjp2DU7Er6mMvqFRDNhY5tjcmyyu3+e9Tf8AQ2vSU0+qlh/xjUDFI9Vv Sb/t2zn05/QC3b/wvp/T/kLEzL6G/wCJShrrGNda2muoFwG54ym2OrZ+89rKrX7P+DsXb14f1Y+q PT8jMrpp6biCHZFrRq6PoNJ99tvuf+hq/wC21i9H6T9Q8/Lya6eiPxMi6tz7K8vFtpaaiQx1mMLh 9mo3bv8AtP6VqSmx/wDnT/8AaD/7uLnfq10/q/Uvqp1XAszcCmuy/Lb1UZVD3312lx9TIybzk1M9 Zmz1arbaf0Xps/0a287qX+L3ruVifbqRe1lv2fCzn02147rGk/q1OcGV49vuY7bX6noIv1lb9Q6e qss6vgMzOqOZ6zmVY777PSZ7TkZVdDXNdTW1v0sn8z+okppdM6fTV9fem417mZrsH6uVelkEBwNj L/Q+1VF2/a6xjn+/d/hF3SxcLP8Aq3kdYxvsbWnqOR01t+PY2tzT9gc9pqbuc1jWV+r/AID+cUKP rr9X8jKqorus9PItOPjZhpsGLbcC5noY+a5n2e1+5j9vv2Wf4NJTupLlelfXH7Z9ZerdOtZb9mxT QzCazFv3ya7Lct2V+jc6r3s/Qer6Hq1/zHqrYp+sPSL+iHr9d89NFbrTftcPawubZ+jj1NzXsczZ tSU//9L1OutlbG11tDGMAaxoEAAaNa0KSSSSlJJJJKUkkkkpSSSSSnC+ueH0TP6KcPrWW3p9N1jB RkueGbbxL6drn+x30X7mu/we/wCh/OLlrOp/WI39T+q7+pVfWIZPSMm6nIx6213V2bDVVVY3Gc+r 9Lu9v+F320/9c9ByMbHyqXUZNTL6XiH1WND2uHg5j5a5Cwel9M6c17On4lGG2wgvbRWyoOI4LxU1 m5JT5z1PqnScv/FJi9Pwra7M26rFxqsNhDrnZDLafXY2hk2+o/ZbZ9H3/wDXFsdHzcLpf16+sI6v dXi35NGHbjW5DgwPqrp9PI9K63a12y1v6T3f4L/gl1jOj9JrzT1CvCx2ZzpLsptTBaSRtdN4b6vu /rKWd0rpnUQ1vUMOjMbWSWC+tloaTzt9Vr9qSniurWN6t9ass9KsF7s36rXjDsrd9J1lzm1bXfm+ 9YuBgnqv1VwsXJ+t+PiYUVV/s9+Jjttpurc3bRv9WrL9Wu5v89/OX1/pn/o7V6mMTEbe3JbTWL2V +i24NG8Vzu9Ftkb/AEt3+DQP2L0f7b+0PsGN9und9q9FnrTG3d6+31d23+Ukp57oWTjVfX361VW2 srsuPTxUxzgHPIxzPptd9P6X5q5zKo2vy/8AF+wjbmdZreykaFvTrW/tS447nf8AcZ+O5r16Pb0v pl+ZXnXYlFuZSAKsl9bHWsAJLRXc5vqM27nfnLJxOhZl31rv+sXUW0M9Go4fTqave4V7tzsvIuc1 n6xb9FlVfspos9NJT//T9VSSSSUpJJJJSkkkklKSSSSUpJJJJSkkkklKSSSSUpJJJJT/AP/Z/+0R BFBob3Rvc2hvcCAzLjAAOEJJTQQEAAAAAAAHHAIAAAIAAgA4QklNBCUAAAAAABBGDPKJJrhW2rCc AaGwp5B3OEJJTQPtAAAAAAAQASwAAAABAAEBLAAAAAEAAThCSU0EJgAAAAAADgAAAAAAAAAAAAA/ gAAAOEJJTQQNAAAAAAAEAAAAHjhCSU0EGQAAAAAABAAAAB44QklNA/MAAAAAAAkAAAAAAAAAAAEA OEJJTQQKAAAAAAABAAA4QklNJxAAAAAAAAoAAQAAAAAAAAABOEJJTQP0AAAAAAASADUAAAABAC0A AAAGAAAAAAABOEJJTQP3AAAAAAAcAAD/////////////////////////////A+gAADhCSU0ECAAA AAAAEAAAAAEAAAJAAAACQAAAAAA4QklNBB4AAAAAAAQAAAAAOEJJTQQaAAAAAANFAAAABgAAAAAA AAAAAAAA4QAAAXQAAAAIAFMAdABtAHAAQwBTAF8AMwAAAAEAAAAAAAAAAAAAAAAAAAAAAAAAAQAA AAAAAAAAAAABdAAAAOEAAAAAAAAAAAAAAAAAAAAAAQAAAAAAAAAAAAAAAAAAAAAAAAAQAAAAAQAA AAAAAG51bGwAAAACAAAABmJvdW5kc09iamMAAAABAAAAAAAAUmN0MQAAAAQAAAAAVG9wIGxvbmcA AAAAAAAAAExlZnRsb25nAAAAAAAAAABCdG9tbG9uZwAAAOEAAAAAUmdodGxvbmcAAAF0AAAABnNs aWNlc1ZsTHMAAAABT2JqYwAAAAEAAAAAAAVzbGljZQAAABIAAAAHc2xpY2VJRGxvbmcAAAAAAAAA B2dyb3VwSURsb25nAAAAAAAAAAZvcmlnaW5lbnVtAAAADEVTbGljZU9yaWdpbgAAAA1hdXRvR2Vu ZXJhdGVkAAAAAFR5cGVlbnVtAAAACkVTbGljZVR5cGUAAAAASW1nIAAAAAZib3VuZHNPYmpjAAAA AQAAAAAAAFJjdDEAAAAEAAAAAFRvcCBsb25nAAAAAAAAAABMZWZ0bG9uZwAAAAAAAAAAQnRvbWxv bmcAAADhAAAAAFJnaHRsb25nAAABdAAAAAN1cmxURVhUAAAAAQAAAAAAAG51bGxURVhUAAAAAQAA AAAAAE1zZ2VURVhUAAAAAQAAAAAABmFsdFRhZ1RFWFQAAAABAAAAAAAOY2VsbFRleHRJc0hUTUxi b29sAQAAAAhjZWxsVGV4dFRFWFQAAAABAAAAAAAJaG9yekFsaWduZW51bQAAAA9FU2xpY2VIb3J6 QWxpZ24AAAAHZGVmYXVsdAAAAAl2ZXJ0QWxpZ25lbnVtAAAAD0VTbGljZVZlcnRBbGlnbgAAAAdk ZWZhdWx0AAAAC2JnQ29sb3JUeXBlZW51bQAAABFFU2xpY2VCR0NvbG9yVHlwZQAAAABOb25lAAAA CXRvcE91dHNldGxvbmcAAAAAAAAACmxlZnRPdXRzZXRsb25nAAAAAAAAAAxib3R0b21PdXRzZXRs b25nAAAAAAAAAAtyaWdodE91dHNldGxvbmcAAAAAADhCSU0EEQAAAAAAAQEAOEJJTQQUAAAAAAAE AAAAAjhCSU0EDAAAAAALzwAAAAEAAACAAAAATQAAAYAAAHOAAAALswAYAAH/2P/gABBKRklGAAEC AQBIAEgAAP/tAAxBZG9iZV9DTQAD/+4ADkFkb2JlAGSAAAAAAf/bAIQADAgICAkIDAkJDBELCgsR FQ8MDA8VGBMTFRMTGBEMDAwMDAwRDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAENCwsNDg0Q Dg4QFA4ODhQUDg4ODhQRDAwMDAwREQwMDAwMDBEMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwM /8AAEQgATQCAAwEiAAIRAQMRAf/dAAQACP/EAT8AAAEFAQEBAQEBAAAAAAAAAAMAAQIEBQYHCAkK CwEAAQUBAQEBAQEAAAAAAAAAAQACAwQFBgcICQoLEAABBAEDAgQCBQcGCAUDDDMBAAIRAwQhEjEF QVFhEyJxgTIGFJGhsUIjJBVSwWIzNHKC0UMHJZJT8OHxY3M1FqKygyZEk1RkRcKjdDYX0lXiZfKz hMPTdePzRieUpIW0lcTU5PSltcXV5fVWZnaGlqa2xtbm9jdHV2d3h5ent8fX5/cRAAICAQIEBAME BQYHBwYFNQEAAhEDITESBEFRYXEiEwUygZEUobFCI8FS0fAzJGLhcoKSQ1MVY3M08SUGFqKygwcm NcLSRJNUoxdkRVU2dGXi8rOEw9N14/NGlKSFtJXE1OT0pbXF1eX1VmZ2hpamtsbW5vYnN0dXZ3eH l6e3x//aAAwDAQACEQMRAD8A9SqqqoqZTSxtVVTQyutgDWta0bWMYxvtaxrVNJJJSkkkklKSSUXP YyC9wbJDRJiSfotSUySVazqfTarTTZl0stB2mt1jQ4E/m7S7clf1Lp2O815GVTS9upZZY1pAP8lz klNlJV78/BxyG5GTVS5w3NFj2tJH7w3FGrsrtrbZU4PreA5r2kEEHhzXBJTJJJJJSkkkklKSSSSU /wD/0PVUlnZeZkPyH4mG5lXpNDsrKs1bXv8A5uqtm5jX5L/p+93p0s2Ps9T1GVrIx8s39V+yOyMv Hc2s2OyLrq53SzYxuNWLMDbsf/o0lPUJLPxMy9mQ3DzHMtNjS7Fyq/a20N/na3s3P9PIr+l7XbLq /wBLV/N21VVuq/XD6t9HyhidRzW05G0PdWGvsLGkhrX3egy30Gu3t/nvTSU7KxfrSAaOnSJjqWGf /BmonVvrX9X+jurZ1DLFb7azcytjH2u9Mf4d1eMy57KdP51/6ND6n1b6s24WBl52ZWMO/Irsw8gP IqNtW7Ir33M/Rsa30X7/AF3en/g0lOT0jFusvznM6PiZlZ6nk7sq2xrbP533P9M41rv0X5n6b/B/ mIgxr7es9cdX0jE6kPtlYNuRY1jh+pYH6La/GyPY36X0/wDCKgep/wCL/Iry+o09cy8er1t19dOV l0g23Hf+gwmGuyz1nb3/AKvS9XMq76nZTWdc/a+TiUdXsht1GXkY1Lra6xUXWsrdVXj2NoxWsf8A aG1fzaSk+dRbZ9aMsU9Mxuo7cDD0yHhmz9N1KPT3UZP0/wA76H0F0eIwsxaWGpuOWsaDRWQWMMa1 Vua2vcxn0foLmMOz6pfWa1+X07qeUbsWium91GRk4zzVXvspfewmi2/b69v6d3+kWni9b6Fh/Vuv q4zHv6TWwRmX+rY8gv8ARa6z1Wuynu9Z2z3MSU7KS5TO+vnT8H63noWTayvFrxg6y3ZY6z7VY9gp xGCsH/tPZ630HrRy/rn9WcLOdgZWeyvIrc1lvtea63PnYzIymMdjY7vb/hrq0lO0ksnqn1r+r/SL rMfqWazGuqqbe5jw6TW5xqY6vax3rO3td+iq32rUre2xjbGzteA4bgWmDr7mPDXs/quSUySSSSU/ /9Hoetln2qkZ0/YzmW/bOY3bmejv2/8Amt9D0v8AgvU9NTYzoh+sWQ2wY37M9D2j2ejO2n+b/wAH v+n9D3rduqe9w6p0s15VWTW11tBI9O9kbqL6bvcxt2w+x/8ANX1fo7P8FbVjMwMhub9s/WDluMOo OGz0yNG+nu9X7I1vt/nPtX/XUlNboE+oRi7vswzavskzExkev/I3/s3+f/sKf1PfhjO+truoOrGQ Oo3HJNxbIww39V9b1P8AtK2n1dm/9FsXR4WJkWXtzc1jKnsaW42Kw7m0h38691kN9XItj6bW7Kq/ 0VX+GtvF1H6r/V7qmS3L6h0+jJyGx+le0biB9Ftn+lb/ACbElOH9VrGv+u/1ode5jsh/2R+O4EHd jGt3pGn/AIPb6XrbP8IuWqqpu6Ng0hgs6VZ9cWswa3AOpdiOL2hlLD+jdjOf63/B/wA4vRep/VX6 u9W9H9oYFNxx2hlJjYWsb9GkOq2O9Fv+h/mlZd0jpb6MbHOLV6GDYy7EqDQG1WVz6VlTG+1jq9yS nnxRQ/8AxousfW1z6+jNfW8tBLXHIfUXtd+a/wBJ3p7v9GuWY3FGD05uQKxjD61XB7bNorDZt0cH +zavTRgYQzz1EUs+2mr0DkR7/S3er6W79z1Peue+sX1XryD0qjp2DU7Er6mMvqFRDNhY5tjcmyyu 3+e9Tf8AQ2vSU0+qlh/xjUDFI9VvSb/t2zn05/QC3b/wvp/T/kLEzL6G/wCJShrrGNda2muoFwG5 4ym2OrZ+89rKrX7P+DsXb14f1Y+qPT8jMrpp6biCHZFrRq6PoNJ99tvuf+hq/wC21i9H6T9Q8/Ly a6eiPxMi6tz7K8vFtpaaiQx1mMLh9mo3bv8AtP6VqSmx/wDnT/8AaD/7uLnfq10/q/Uvqp1XAszc Cmuy/Lb1UZVD3312lx9TIybzk1M9Zmz1arbaf0Xps/0a287qX+L3ruVifbqRe1lv2fCzn02147rG k/q1OcGV49vuY7bX6noIv1lb9Q6eqss6vgMzOqOZ6zmVY777PSZ7TkZVdDXNdTW1v0sn8z+okppd M6fTV9fem417mZrsH6uVelkEBwNjL/Q+1VF2/a6xjn+/d/hF3SxcLP8Aq3kdYxvsbWnqOR01t+PY 2tzT9gc9pqbuc1jWV+r/AID+cUKPrr9X8jKqorus9PItOPjZhpsGLbcC5noY+a5n2e1+5j9vv2Wf 4NJTupLlelfXH7Z9ZerdOtZb9mxTQzCazFv3ya7Lct2V+jc6r3s/Qer6Hq1/zHqrYp+sPSL+iHr9 d89NFbrTftcPawubZ+jj1NzXsczZtSU//9L1OutlbG11tDGMAaxoEAAaNa0KSSSSlJJJJKUkkkkp SSSSSnC+ueH0TP6KcPrWW3p9N1jBRkueGbbxL6drn+x30X7mu/we/wCh/OLlrOp/WI39T+q7+pVf WIZPSMm6nIx6213V2bDVVVY3Gc+r9Lu9v+F320/9c9ByMbHyqXUZNTL6XiH1WND2uHg5j5a5Cwel 9M6c17On4lGG2wgvbRWyoOI4LxU1m5JT5z1PqnScv/FJi9Pwra7M26rFxqsNhDrnZDLafXY2hk2+ o/ZbZ9H3/wDXFsdHzcLpf16+sI6vdXi35NGHbjW5DgwPqrp9PI9K63a12y1v6T3f4L/gl1jOj9Jr zT1CvCx2ZzpLsptTBaSRtdN4b6vu/rKWd0rpnUQ1vUMOjMbWSWC+tloaTzt9Vr9qSniurWN6t9as s9KsF7s36rXjDsrd9J1lzm1bXfm+9YuBgnqv1VwsXJ+t+PiYUVV/s9+Jjttpurc3bRv9WrL9Wu5v 89/OX1/pn/o7V6mMTEbe3JbTWL2V+i24NG8Vzu9Ftkb/AEt3+DQP2L0f7b+0PsGN9und9q9FnrTG 3d6+31d23+Ukp57oWTjVfX361VW2srsuPTxUxzgHPIxzPptd9P6X5q5zKo2vy/8AF+wjbmdZreyk aFvTrW/tS447nf8AcZ+O5r16Pb0vpl+ZXnXYlFuZSAKsl9bHWsAJLRXc5vqM27nfnLJxOhZl31rv +sXUW0M9Go4fTqave4V7tzsvIuc1n6xb9FlVfspos9NJT//T9VSSSSUpJJJJSkkkklKSSSSUpJJJ JSkkkklKSSSSUpJJJJT/AP/ZADhCSU0EIQAAAAAAVQAAAAEBAAAADwBBAGQAbwBiAGUAIABQAGgA bwB0AG8AcwBoAG8AcAAAABMAQQBkAG8AYgBlACAAUABoAG8AdABvAHMAaABvAHAAIAA3AC4AMAAA AAEAOEJJTQQGAAAAAAAHAAYAAQABAQD/4RJIaHR0cDovL25zLmFkb2JlLmNvbS94YXAvMS4wLwA8 P3hwYWNrZXQgYmVnaW49J++7vycgaWQ9J1c1TTBNcENlaGlIenJlU3pOVGN6a2M5ZCc/Pgo8P2Fk b2JlLXhhcC1maWx0ZXJzIGVzYz0iQ1IiPz4KPHg6eGFwbWV0YSB4bWxuczp4PSdhZG9iZTpuczpt ZXRhLycgeDp4YXB0az0nWE1QIHRvb2xraXQgMi44LjItMzMsIGZyYW1ld29yayAxLjUnPgo8cmRm OlJERiB4bWxuczpyZGY9J2h0dHA6Ly93d3cudzMub3JnLzE5OTkvMDIvMjItcmRmLXN5bnRheC1u cyMnIHhtbG5zOmlYPSdodHRwOi8vbnMuYWRvYmUuY29tL2lYLzEuMC8nPgoKIDxyZGY6RGVzY3Jp cHRpb24gYWJvdXQ9J3V1aWQ6NjBhZGY5ZmEtZDM0MS0xMWRiLThhNmYtOGI4Mzg4ZTlmMDVjJwog IHhtbG5zOnhhcE1NPSdodHRwOi8vbnMuYWRvYmUuY29tL3hhcC8xLjAvbW0vJz4KICA8eGFwTU06 RG9jdW1lbnRJRD5hZG9iZTpkb2NpZDpwaG90b3Nob3A6NjBhZGY5ZjQtZDM0MS0xMWRiLThhNmYt OGI4Mzg4ZTlmMDVjPC94YXBNTTpEb2N1bWVudElEPgogPC9yZGY6RGVzY3JpcHRpb24+Cgo8L3Jk ZjpSREY+CjwveDp4YXBtZXRhPgogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAKICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIAogICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAKICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIAog ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgCiAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAKICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgIAogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAKICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIAogICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAKICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIAogICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgCiAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAKICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgIAogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg CiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAKICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIAogICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAKICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIAogICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgCiAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAKICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgIAogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgCiAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAKICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgIAogICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAKICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIAogICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgCiAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAKICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgIAogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgCiAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAKICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgIAogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAKPD94cGFja2V0IGVuZD0ndyc/Pv/uAA5BZG9iZQBkAAAAAAD/2wBDAAICAgIC AgICAgIDAgICAwQDAgIDBAUEBAQEBAUGBQUFBQUFBgYHBwgHBwYJCQoKCQkMDAwMDAwMDAwMDAwM DAz/wAALCADhAXQBAREA/90ABAAv/8QAewABAAIDAAMBAQAAAAAAAAAAAAgJBgcKAQQFAwIQAAAG AQMCAwQEBgoJDw0AAAABAgMEBQYRBwghEjETCUFRIhRhcTIVgSO0FnY4kaGx0UIzsyQXN1JicpJU lHUYGYLCc5PTNHSEJZW1JjZWV6Ky0lNE1IVmhpZHdzn/2gAIAQEAAD8Av8AAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAf/Qv8AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAf/Rv8AAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAf/Sv8AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAf/Tv8AAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAf/Uv8AAAAAAAAAAEeNrOSOG7tbn7vbVUFbaQ77Zqa1ByOXMaQiO8t3UiOOpKlGZdP4REMR5 K8xdtuLtlhtTnNNkFxOzlElVIxRQ/m1GcU0EtKk9yT1PvLQi1EdP9Ktsp/4Z7nf/AG87/wCkNk7R eoRtbvJuHj229BgmeVNrka3URLC3pnI0Ns2m1OH5rpmfaRknTX3jf3IvkLhfGbb8tyM8iWU2j+8Y 1Z5NWyT7/nSjMkH2mpJafD16iG5eqvspoRltnucaVESkqLH3dDI/Ay+L2j36v1R9mbW0q6pjbbcp p+1mR4TDrtA4htK5DiWkqUo1dCI1amLCsyyyuwjD8jzW2becq8ZrJFrPaYT3vKZjNm6skJ6aq0Lo Qrdg+rJsVZRGZ0DbzciZEkJ1Zkx6JTratPHtWhZpPT6DHtH6q+yuhn/Rlud0Iz/7Pu+z/VCwPa/c Gr3VwDFtw6WBPrKrK4SZ0KBZsnHltIUpSe15o+qT+EZ6AAAAAAAAAAAAA//Vv8AAAAAAAAAAFUnC n9c/nv8ApDA/14882T05kcBz6H/1jseiiIy8G/Ej1IWpfJxP8FZ/vE/vDyiNHQolIjtoWXgpKEkZ fh0FZHq2dOLEf9NaH+XMWKYhHjuYniy3I7S1Kp4Jmo0J/wAHR9AyH5OJ4/KskZHqXwJ/eGouRf8A ULvH+h9x+SOCNfpoNMvcMdoTdZbcNLE4iNSUn/7W79AnicOJ/grP94n94fuhKUJJCEkhKehJSWhF 9RD+gAAAAAAAAAAAAH//1r/AAAAAAAAAABVJwp/XP57/AKQwP9eMP9RtzOmuSXC53bJitk7gItLQ 8Sj3BmUBcz8V2lJMupI018Bsv709WD/uxs5/jb/743FsTO56SNwGG+QNJt1B25+RkHIkY2+65P8A nC08gkpUenafXuGnPVvNwuKjXlaG7+edF5fd4d3nK01/CPm0lp6qJUlL914zs6db93xfkDXKfJRs +Uns7i1+126a6dNRm2HWXqcry7F0Ztjm07OGrtIxZW9XyXlSk15rL5g2SM+qyRr2/SJb8iv6hd4t f+59xr/ijgqE4ZWHqDs8btuW9kqLbKZtwlmSVDIvX3m7FReevzPPSk+37fdpp7BJ9dr6sPYvtxjZ zu0Pt0lv+P4T0FkOJKyReL48vMW4rWWKrox5I1BMzjJnG2nzyZM+poJevb9AyEAAAAAAAAAAAAB/ /9e/wAAAAAAAAAAVScKf1z+e/wCkMD/XjzzZIz5k8BySRmf5x2OhF9TYtaAVgerZ+qxH/TWh/lzF jmHEZYjixGWhlUQdSP8A4OgZGNM8i/6hd4/0PuPyRwRw9MwjLhhtFqWmrM4y/wAbdE9QAAAAAAAA AAAAAB//0L/BjGV5ljOEVblxlFuxUwUakhTqvjdURa9jSC1UtR+4iEWHeQG5+4bzkPZrbh9cFS1N t5RaFoz0P7Wqu1tPT2Gagc245O27K597u5Bx0kpNx2NFJXY2RdT7lJShJERD0IFByWrmV2OIbq0m 4sWKoydjG4hwjURam2ZqJSSP6O4h92n5MXWMz4tJvRgk3EJDi/JO+ZQpcVa/7Ik9dS9pmhR/UJXV NxV3sCPaU1gxaV0pPdHmRlk42oj9xp9vvLxIfSAAAAABEbY3jJN2f3t5BbuSMvavWN7bJifFpERD YXXkzr8C3TWonDPXxIkjCeXvELLeR+WbVZnhe7Ktqr/a1Ux2rs2YRyn/AD5Ro7XWlE4jsNJJ09vi NG/5kHMo+v8An+ZJ/wA3q/3cZntzxA5V4lnuI5Nk/Na/zLHaKyal3WKvwlIbsI6D+OOtXnGRErwP UjEguYnG+Zyl2jLbKDlqMLkJuYNsm4cinLL+ZqNXZ5ZLR1Mz6HqIjt8G+YrLTLDPPnI2mI7aGWGk 1yiJLbaSShJF5/gRFoPK+D3Mo0mRc/ckJWpaf8nq95H7HyMWOZlg83L9qch27k3Rpscgxt6ikZC4 33n5z8Y2FSVN6lrqo+4y1FXuF+nbyi29xirw7DOb9xjWN06FJr6aBVqajsmtXcvsT55mWqj16mMo Lg/zJ9vPzJP+b1f7uJ/7DYDm+2W2dHh+4m4srdXK65ySqfmsxs2npKXnVONpNJqUf4tJkktT9g3E A/GRIjxGHZMp9uNGYSa3pDqiQhCS8TUpRkRF9Yw7HNytvcvt7KhxTN6PJbmnbS9a1tXOYlux0LUa UqdSytXaRmWhajNwAAAAAAAAAB//0bxNxM8ptt8Us8qu1/zeCjSNFSZeZIfV0bZQXtNRiKe3+11/ vlbJ3T3jUpyilES8TxFtxaWks92pGpJeCNC+tfifQbuz/e3b3ZuTX4xYwpbUhcEpFbV1kQzbJlKj QlJGnRCepeAhnupyUyfcSHKoKeGeLYtK+CU33d06U3/YOrLohB+1KfH3jfvDFttvBcoJtCUJ+/XO iS0L+KQJUZFjVFllVIpcjq49tWSi0diyEkoiP2KSfilRewyPUhCa2q8q4qZK1eUD0m92bu5SSua5 z8a7CWvxPppooi+yr+EXRXUTgorusySnrr2mlJm1dqwiRCko8FIWWpfhLwMh9YevLlxIEd2XOktQ 4rJdz0l9aW20F71KUZEQwGq3f2qvbH7optxccs7Q1GkoEayjOOmovYSSXqZ/UNi6lpr7B/LjjbSF uuuJabbI1LcWZJSki8TMz6EMLTuXt2qxOoTnVAqzI9DgFYxvN193Z36jNULQ4lK0KJaFlqhaT1Iy PwMjIeTMiLUz0L3mPSiWlbPdkswbCNNehKJExph1DimlH1JKySZ9p/QY+Jb5xhmPy2a+9yuop50l RJYhzJrDDqjPwIkLWRjJmnW3m0PMuJdadSSm3UGSkqSfUjIy6GRj4F9l+K4s2l7JckrKBtZkSF2E pqPrr4aeYpOo+nW2tZcxG59RYxrSE6WrUuI6h5tX1LQZkY/SZPg17Xnz5rEFn/1shxLaf2VGRD1q y7p7qvTa1FrEs6tfd22MV5DrB9hmStHEGaehl16j5MXOsKnWC6mFl1NLtGz0XXszmFvEfu7ErNX7 Qyofi/Ijxm1PSX247KOq3XVEhJfWZmRD0qq6qL2O5KpbSLbRWXlx3ZMN5DzaXWz0Wg1IMy7k+0vY Pp6kXiPnNW9S9OXWM2cV6xbQbrkBDyFPJQR6Go2yM1EWp6amQhB6lVmuv4b7u/LyPJdkx4cVXas0 q7XZTZGXwmR9SFf3otVkKPZ7/wBoTbbLjaaSGhzonRPluuGX4T6i+5DrbmpIcSsy8SSZHp+wPVsL OuqYrs61nx62EyWr0uU6llpJF11NazIiGIUm6O22STPu7H88oLmf7IcOwjuun9SErMzGeD1Js+DW xnZljNYgxGUmp6TIcS02gi6malKMiIeG7CA7BRZtzWF1rjRPonpcSbJtGXcSyc17e3TrrroMex/P cIyyZNr8Yy2oyCdWlrYRK+YzJcZIz7dVpbUoyLXp1GWgAAAAA//Ssh3DYXvJyDodvu5cjEcAaTOy OORn5S3zIlrJWnTUiNLZe4zMbO3R5CYftY63jVZC+/8AIIqEoVSQjS21DbItEk8vwT08El1GgH+W L1xLaQ/tJAuJ6y7I7RmUl80666JLy1K0/aEdty8ik5VmM27l4x+Z0h9hlpWP9nlm15aeizTon7X1 DZ2zm8+RbX41cQqnBJOUQJM9cyZbNE55bCjQkjbUaEn4EWo2W1zRs1GhS8CZU0Z/F2Sz16eJFqnx Eh8R3DwHf/FLqiJJsvSoyo9zjsvtKQySy0J1BfwkkfUlF7Rq7jXZ2uIZNnWx92+cksSeOXj8hR+M ZxWhpSXu6kovrEocxy2iwLFchzTKJya3HsXr37K4mr8G2I6DWs/pPQtCL2mOX7c3e/kZ6ie9TOAb euWNdido65+auAxpS4tfDq2laKsrl1rt7zMjJR69NdEpIbjzT0dN38LxNzLMD3HrMwzKnZOWrGY0 d2teeWgu40QpZOak5/Y92mpi2vgxhW8e2XHen/zgMzsbjIpSHLQqy6UTkigrySZphvyVGa3VJSnv Uaj+HXQhTByM5Wb5c1d74Ozey06yx3DrG0focPxyumLiHbeUs/PsrJ9oyMmkoQa+0j0Sj3mY3HI9 FnN2scO1h74w3s+Qx5xQVQ30Q1SCLu8opRO+cRGfQlGX0jT/ABQ5h7ycUd5v6Ht8LaysMDK8Rj2a 0+QPuSJOOyTX5Lc2I+53KNjU0mpOvaaD7i6kL2uXlbIyTjBvCVJdzaeajF5VnT3dVIWw+hyKj5hp bbrRkrRXZoeh9SMcyfGrf3kFgkfN8D2Oj2uS59vpHhQ25rSnpthEeb1NyUx3moicUlZpN1w9EF1E ob30qOWeT4zYbjZlmlRf52uKufIxayny5tg6pKTX5Pzxn5ZOmRaERfDr01GpePXPffjYXCMy2zok zM7k5IhMPb9Ns67NlUFoZmwomGld63kn4Ez7FpLTpqN5VPpmcvuQdKvczeHctmqym8bVOg45lL8q bN1X8SUyENqJqL3f2CS+H2jTfCvePdLjVyjxva6dazWMdtsqVhW4WDSZDj0FuQbhslJjpWZkhba9 FJUn7SehiyT1lIchGzu111FsJkNUXLvk5LUaQ6yh5qVHWRpcJtSSPQ0kZaitHYpXLfkXt7iXGPYl ybje3WCrlry7KY0lyDDcenuqeUc+YjRZ9iVdqGGz1PxMZtvD6XnITY7Dpm6VFl0bPnsdaObfxMeX MiW8ZlBdzkiMpS9XvLL4jIj7tOpCXnphc3smy+8Tx63dyN7JLCXFXN2wzCevukvtspI3a6Q4ehuL Sn4m1H10I0mNk+sXbXFZs1tc3VXNhUIn5epmemDJdjee38so+x3y1J7iI+pEftGyPSTIi4iwT6mp WW3prUZmZmfmoLUzPqZiYHKGdOrOOu9VhWTpFZYQ8QtHYVhFcNp9lxMdRpW2tOhpUR+BkKR/R8sL O15BbnTbi2n3U5eCtmubYynZTpmuwbNWq3VKProNl+ptxh3Lad3M5Ir3XX/R221Vsntj5krtcUky Y17O/wAjoo+4vh1EHeG3FHdHkxG3Ak7b7vL2rTiMmHGt2mnJbapypLanELP5ZaNSQRafELztjNvI /AzjvnuT7zbly86nwn5F9k2SyZD7pKQ0gmokKIiStaiNWmhEXitQpUYtOS3qbb5TMebyKbj+Il3T ZNSl51ukxumJfa15zTRpKRJWXQu7qpWvgkht7ez0mc92Uwax3N2o3HmZzcYk0c6zoYsddbYnGbLV 16C8w4Zm42Wquw/Ei6dRJP0wObOUbh2T/H/dm/dyO6YgKsNuMumKI5UuKx/HQZKz0NbjZfElR9TI jIxinrM1l1Ck7NXsLIraHTX7NlTXOPx5rzMKQuOSH2nXGULJKlaOGnUy8BDnEs25YcutudruL+zV fZsYttVSJgZrdMzlw4s1S1q8lyzmEZGlptr4G2SMzV1MyFvXpz8M8h4r45nljuGzVq3BzKwQz59W 8b7LVXFSXlIS4oiP43FKWovqFlQAAAAAP//TsE2YyFVVim/W8DiSftn5T7kZxX1LeSX1arT+wIVy JUyxkyLCa8qZaWrxvzJCz1U6+8fU1H9Z/sC1zZPaKh25xiC78q1Mye0ZbkXVytJKcU4tOvltmfVK Ea6ERCDHJr+ujIv+BQf5IST4bpSvBMpQtJLQd65qhRakerSNehjBeVW01JQx4242OQ01ypk1EXJo TJdrK/NLtbkJQXRKiV0PTx1EWcCyeVhWbY1k0NxTaoM1puYST08yM6okOIV7y0MTTyo0Y7yr28vo X4tjOalUeWSfBfwKSRn+wQ1V6rOaTcU4kZFWQHDaczm4rsfkOF/g77huOp/1SW9BCz0YcRiv5Rvp nTiNZNbEqsfgK/sG3O+Q6RfWaUi/kQ+565vN2/4m7x3la6tiwk051kV9H2kHOWlhRkfs+FRimv0e sTgWvIfMsilMpekYThjbdatfU23LJ7tcWn6TSgy1+kdKug5lfV4wuBR8mKa+iMIZPP8ADGn7QkFp 5j8F1ccnFfSaNC1Fpe0+ZWWd+mbDyK4kHKs17W2cKXIUeprOCw/FSZn7+1otRV76OiEK5FZCpSEq UjAj7FGRGadX2iPQ/ZqOl17+Jd/uFfuDk24Ox48nnNty3JYbkIRlt46hDiSURLbVLUhREftSZakf sMdZo5Ns+Iv9JHbFp/8AmyN+UIFqvrH/AKveB/p1C/kXR970gEILi5ZqJCUrXmdsbiyIiNRkaCI1 H7dC94tPlMNyo0mM6kltSGltOIMtSNK0mkyMvpIxx67eOJ265r42iGXyjGL7yvwYzaPh7I7k9bZI Ii06dq9NBcF6zB67O7RmXgeZK/JVDbPpKfqi1/6WXv8ALIEteV36tW+X6GW35OsUi+jd/XzuZ+gj P/SCBZx6n/6mu5n+y135UgQz9Fv/AHjyA/ylT/k6xvj1fcgdrOMlLQtL7SyvM6yNIRr9pqKl2UZH 7/iaSK8vTq5b7IcW6jdL+lJV23d5lZQXKpVTX/OJOHFYNJk4rzEGk+9R9BZG96tnER9l1lb+YGh5 CkKI6PoZKLQ9fx4o+4v5BHgc1tsL/G1riVFpuPLVTEpJIWVdYvOG02tBdEn2K0NPsFpvrPlrimwn u+/rb8mZEhfScx2nquItDeQYTbNrlt9cTb+cRF5kh1mUuM13K8TJDbZEkvYLMAAAAAAB/9SeO0lP Kstot+MBjoNV7XyH0FD0/GKUlCkEWn0m0ZCG7a1pQy4lB+YwpC/JV0PuaMjNJkfgepaC5rbnMKbO MQpryllIkMuR225TRGXew+hJE404XiSkn7xXDya/rpyP/gUH+SEleGn/AGHyn/Lzn8kgfly+zGtj 4jAwZmW09dXM1iRLhpUSnGYjB95uLIvs9xkRFr4iBVHUSshv6KigtqelW9jHYaQnx6uEaj+oiLUT qzpH3jya2dx6KrzVYtWG/N7epoSlClan9ZaDRnq5Y7NuOKZ20RhTzeKZTVWU80Fr2MGpbKln7iI3 C1MRl9F7Ia9D+/uJreSm1ckVNwwwZ/EuOppbKlEXuSoiI/rF74hZ6heJ2GY8Qt4q6sbW9Lg1iLNL KC7lKTDdQ6siL+5IzFQPo8ZPCrOQ2b0D76G38wwtp6vQo9DcVXvka0p95kleo6URzX+sPkVfYcis HpY7qVycUwhSrUiP+LVMkrcbJXuM0p1FjGxVBPxz0vIMCyjriy3ts7maphwtFEiWiS+2ZkfvQsj/ AAitj0c/1icj/QI/yhodLb38S7/cK/cHJ5wX/Xp27/Sm/wD3ZY6xxyb5/wD/ANI7b/8Adcb8oQLV PWP/AFe8D/TqF/IujIPSBIy4tTz06HmVvp/fIFp77qGGXnnFdrbKFLWo/YSSMzMcfeDNHuFzhozh fzpvI96X5cdbfxkthmetfeWniXajXUW9esx02d2kL/5zV+SqG2PSTMv80WB16llt7r/tqBLXleZF xq3zNRkkiwy26mehf73WKRvRt/r43M/QRn/pBAs49T/9TXcz/Za78qQIZ+i3/vHkD/lKn/J1je3q /Y87Z8ZqK+aQaixTM62TIURa6NSkOxT1P2fE4kQz9Lrj7sJvxju7zW7m31bnF5jVxAKpXOcfSuPD kRjMyQTLrfQ1pPqevUWr/wCjy4Yf+AVB/t07/wB5H28a4LcS8OyGmyvGdk6WoyHHpTc2mtGXZprY kNHqhxJKkKSZkfvIxX76z3/ZTYT/AC9bfkzIlD6Vv6mG33+U7z/pF4WKAAAAAAD/1bJZUpOzvJlb 7qiYxbdhgjeWro23KUokrMzPoWjpEr6lGPx3c4rSrm6mZNt1LjRXLV1T9rj00zQz5quqnI7iSPt7 j8UmWg1niO0HJXAZj8zEmG6lcg/52yicy5HfMuhG40su0z9x6ajTW6is2Vm9h/SKcf8AO4o8cp5R uzy/L7fxX8X8Oug2RsyjfZ3HLlnaZ2K3TKnqKzW6pgnUyjQnU0G6RmXw6DzL45b6X1rJsriujyrG xc75trMsEOLUfvWZEZ6F7CISY2g2BqdqG5GcZvPj2WR17DrrchvUolewlJms2+7qpZkXVR/gGNbC pkbjbtbibyuRTbpVn90Y2twviNKTIlGn6kEWv1iQ28m19JvRtfm+1+QqU1VZpVP1z0lv7bK3E/in k/ShZEr8A5caadv/AOm5yBclzqZsrGG0utkKltufcuUUhuEslR5Ohdqj7SURkfc2vootBP8Azj1o quTiLzG3G0E2BnMtg22pl/NYcrYTyi08ztj/AIx8kn1Ii7dfaJc8ANwOQu+uzmXO8ksbVLxzIHn0 Yjlk1lMKRcV85KkyGjgkRdrLeujbhkXcR+3TUU4bxbObxenfyHodxccilOxmstpFjtxlvlOLrZkF 81JeqrE0F+Kc8tZoNJn16LRqLAV+tHtz+aHzLez+Qfn0cfQqhUuL92FJ7dNfnNe42+7r9ju0Ffmx +ye7/qE8gbTcTMozzuG2Ny1M3TzJKVR4TMNrq3UVxmXxr8tJNkSfsp1Uo9R0bb+VVfQ8a906WqjI hVdRgtlDrojZaIaYYgrbbQkvclJEQoa9HJaFciskSlRGosCPUvqkNajpde/iXf7hX7g5OeCzrZ86 tu0Esu48pvtE/wCNmOsscmefuo/0ktqXd1PeuMen/GEELWPWQ1/zesEIvE85haf7S6KuuLnK/fzi Ji0LJ6rFFZbsDmVvKJ6vmoUmL95MGSJRRJzZK+Wf6Fq24Xarx0EguQXq45TuZg1lhO0+EObZOX8d US8y2fNamzW47qe11uC20hKULURmXerXQvAtRtD0s+GeQV9+xyS3NoJFJEr4q4+01HPQbcl05Cfx 1q42rRSUqSfa13ERnqavcJb+qhs7l26vHWLZ4VTPX9vtxeM38ypipNyS5AS2puUplsiM1qQkyUaS 66EengKp+DPqDMcWKK82+zDFZeX7e21k5bV8iqcbTYVkt5JJkINl00k42s0kempKSY23vVzN3k5/ XUbjhxvwSZj+K5EZOZE7MdIpsyOyZLUqwfbM2ocRKklqWpqWrQtfYNX+mHl9ptpy7ewyXj9jYPZT X2GJ5EzBjqfXWSYb/mJfkkn+LZQ6ypC1q0IiURi73njttkm63FfdTEsRgLtciVBbn1lW31ckKhOp eU22ReKjSk+0vafQUJcCOZ2O8Scjz+JnWN2NvjGbojHNVWpT9410+ASmzS5HdUjuSoj0MtSNJkLu 9vd3dmPUe2Z3cw+FSWsDFEulQ2KbRLbUtLrrJPxpjKW1L7DQstU6nrqkUUR3OSfpq75vS3YPkIfN UUpMltblDllOhzVBk8noh0i6+JLbVr00FiLfrU4B9xJdd2SyD85/K+OAiyiHC83TrpIMu7t1/tNR mvCLlby35Lb1XmRZHgsWJx/fhOxzcYYOLEqpKD7o/wAtLeLzJrq/Bwi+EvH4dBhfrQLSjE9gzWfb /wAvW3X/AIsyJQ+lWpK+F+3xpPUvvO96/wDxF4WLAAAAAAD/1rpN49roG6mIyaZxSYlzDM5OPW2n xR5SS6dS69qvBRfvDTmy+9UqvmK2m3XSdBmGPkmJBs5jmjc5CfhQk1q0+PTTQ9dFF9IzTeDfCx25 ntUNHhFjk1rMhfNxrBCVFBb1UaSJxaSUozLTXQiFcl+jM8ovLTIrqosZNrcPnImOpiPJTqfRKEF2 9EpLoRDPNqc63A2ntpM2qxmfaVVn2lcUTzDzaXTR9lxtfYfY4kj0100MvEWP7d7ixc9xV3KHqebi rMZ95iXEtUk0tHkkRqXqehdnXoYjDuTuHd765EW0W1Ti14ypxKcyzFpJm15ZK+JCVdC8stPHX4j6 F0EusIw+pwLF6jFaVBpg1TJNpcV9pxfitxWntUepmMrHwb/FsZyyImBlOO1mSQUKNaIVpEZltJUZ aakh5Ky10+ga5qOO+w1BOVZU2zmG109au85bVNDJwlEeuqT8o+0/qG4UIQ2hLbaEttoSSW0JLQkk XQiIi6FoPn29LT5BAeq76qh3VZJIikV05huQwvTqXc24lST/AAkNEFxH4xlbfff9BWG/eXf5nnfd bHZ3a66+V2+X/wCSN8VNNUUMFmro6qHTVkfX5evgsNx2Ea+Pa22SUl+Ah7cqLGmx34kyO3KiyUKb kRnkkttxCi0UlSVEZGRl4kYx2lwfDMbkqmY7iVNQy1t+SuVXwY8Zw29dew1tISfb08NRlGnTQ/b4 jEYG32CVU9u1rMKoq60ZWpxmxi18Zp9C169ykuIbJRGep6nqMvGHubfYG9Zqu3cKonblT5SlWy66 Mck3y8HTdNvv7+n2tdRV36x36veB/p1C/kXR73pL09TfcTLarvKuJc1kjMrb5ivnMokML+JH2m3C Uk/2BYNV8fdi6SzeuajZ/Dq60fV3uTmKaGhzu111SZNfCevu0G3koShKUISSUIIkpSRaERF0IiIh 5MtSMvEj8SMR1y/iRxnz22VeZZsnitrbOGZuz/kUsOOGZ6mpzyPLJZmfiatTG0MF2w262xr/ALq2 8wmlw2AaSS4xUw2oxuEXUvMUhJKXp71GY9mi29wbF8gybKscxKppMkzN1t/KruFFbZkz3GkkhCpD iEkazIi9vifU+ozIaMy3jNx9zy0++su2cxO8tjUa3LJ+tYS84pR6mpxaEpNZmftVqNlYnhGHYHWl UYVi1TidYXbrAqYjMRpRpLQjUlpKSUentPqPfvccx/J4R1uS0VfkFeZ9xwLKM1KZM9NNTbeSpP7Q 1RA4z8equwO1gbKYXGsFGavmE00QzIz8TIjbMi/AQ3NCgw62KxBr4jMCFFSSI0OO2lpptJeCUIQR ERfUQ+bd4vjWTIjt5Hj9bftxFGuKixitSiaUotFGgnUq7TPT2D26mmqKCC3WUdXEpq1k1KZgQWUR 2UGs+5RpbbJKS1M9T6D6QAPWmSmYEOVOkq7I8Jlb76iLXRDaTUo/2CFXmzfqZ02/nIDENmdvtq7O JTX788p+X3UpthxuPAjOvKcaiNksz7lIJOilF4i0wAAB/9e/wam3Q2aw7dWATV9FONaxk6V1/GIk yWT8SLX+Ekj9h/g0EeGInJvZsijxSY3WxCHqllhRmctDKfskRnosjIvrH2WOW8SEkmcn2wyOnnJ6 OtIYNxPd7SIzSQ/ORyrsLfWNg20t/czXPhZXIaNtvvPw10T4fhHyV7c7/wC9Km/6Sb1rBsPkrJx7 Ga89HjQX8BRJPrr/AGxiVuD7f4tt3TopMVrG6+KWipDpdXX1kWne6vxM/wBoZoAAAAAAAAAr39Rj j3uZyQ2pw3Cdr4MKXcQsrj2U52wklGYZjNNOJNalGRmfVRdCLUZbwJ475vxn2SewDP5tbNvpV9Ot VHVrU6y23JNPak1rSnU+h69BNsBXVyR9SzYvj5kdpgzUey3FzimIit6mkJv5aE6Za+VJlrV2JWkv tJLUy9vURAp/Wzxdc9lOQ7HW0GqcXocqJYsuuEjXxJC0IJR/QRiynjRzE2g5UxrstuH7ONcY0hpy /obWIuO/HQ+Zk2vuLubUSjI9NFfgEl7q6qMcqbG9vrKPT0tRHXKs7SW4lphhlpPctxxajIkkRF4m Kq9w/WF444nZTK7FaLJNwW4jymUXEJluJCfNJ6GplyQolLT7j7S1H3tqfVs417h3dVQ5BFvNtpNu +mNHs7lptdch1fRJOymVGlsjPpqotC9otDjSY8yOxLiPtyosltLsaSysnG3G1lqlaFpMyURkepGQ +ff39Li1LaZHkdpGpKKljOS7a2mOJaYjsNF3LW4tWhEREKldx/WO2LxixlQMHwzIs/jRXja+/iJq vhPdp6d7Jvn3qSfsM0lqNo7FeqZx93jyKmw+3i2+2mSXzqY1Sm7QhUGRIWeiGkzGjNBKWZ6J7iLU xJ3kryl234s45j+S7js2siJk05dfVMVMb5lxTzbfmK7i7kkRaGPf408jMU5P7eyNyMNqLKnpWreX UNx7RKEPrXE7O5ztQaiIj7/DXUZVvRvhtrsBhUvPd0MiaoKOOomYyNPMky31fZYisJ+JxZ+4vDxP QhVrdetRs5DtflKjarKrOvSvQ5z7sWK4pOv2iZUozLp7zE1ONfO7Ynk5YPY5iNjMx3No7JyDw6+a KNLeaSWqlxjJRoeJPt7T1Lx00H68uuXO1fGyljUG4R2xWO4VRZs48ddF+YSTiWjaLzT7k9pd6y6j nJ4W71YPx75B45utuN86eM09bcRnVV7PzD5Pz2TbZ0bM06lqfU9eg6FtjvUI2P5BXuRUO39fk8h3 FKKXkN7Lk1poZZiRC1UWqVqM1r8EJ/hGMf2f9SjYbe7d/H9oMMg5A1ZZImYmvu7SKmJFU/EbU6bJ EpZrNSyQenTxFhY0dyC5BYDxrwL+kXcVyYVGqxj1jLNez8xJckSSWaCQ3qkzIiQZmfsEK/8AS3cY fu772+7c0+7fmvkfnPudXZ8x5fm+Xr5n2uz4tPcP/9C/wAHruxYr56vRmnj960JV+6Q/tqOwyWjL LbRe5CST+4P1AAAAAAAAAAAAGkuSWW2+B7B7u5hQOmxdUGL2MqskJ6m28TJpQ4X0pM9SHNF6de0+ Cb8clquj3YSnIayJSzMoOlluapt7NDiTP5jU9XST3m4pPt9vQdNWRcftkssojxrINq8ZsaU2fl0w VVzCSQ3ppohSEEpOhe0jHwNgeM+0/GmpyWl2rpXKmDlVqu1sfPdVIcJZpJKGUuL1V5bZFohJn0FQ 3rA8grReQYrx1oLV2LRw68sk3IisKNPzS3VdtfEdMvFBElTpp8DM06+AkfwN4F7R0WzmKbk7qYTA zTcXP4Ddq6Vw2UiPWwpJd8aNGYV8CT8syUpWmpmf0DVfqPcENtKfbK2322fxiNh1vhpIdzXG61tL cCyrXHEtrfNnXtQ6waiVqkviTrr4D6/pGcjLDJcdyTjvlE1UyVg0f76wGa+4pby6p93tkRDNRnqU d1STR1+yvTwIaG9XLkfZXWdVvHqgs3WMUw6G1c5/HjrNKZtjII1RYzxFp3JZb+LtPoalCXPCj08d nsf2oxXPd4MKh5zuRmta1Zzo9wnz4lWxKT3sxI8c/gI0tqLvUZamrX6BuCs9NbjfQb441vPjlK/S sY6tU1G3rSiXTOWRdWJhNL1NBtH1JCT7TPQ9BGz1mv6rtl/0ulfkY2d6Ra0t8UJjjiiShvNLxS1H 7CI2jMzFQnJzc3K+aPLtvGKOc6VI9kqMG20hKWa48SM0+bUmwJs9E9zhpW4Z6a6ERDoS274R8a9v sBiYEztZR3sc4iWLu3tYqJU2e8aNHXnn3CNXco9T6aaewc8vNbY+Tw05GwXNr50ylo32G8u2vnE8 pT8B5h3+cQ0uEfcpCFF0JR9UnoYvqtML2k5acccJ3g3Mweqy+5LBH7aokSUqUmJLdhKW8bWhlpo6 jUvdoKFvTv20wXdzk5R4TuRjUTLcWlUF5KepppGpk3oyEmy5oky6o16Dpk2o477L7Hqu17Wbf1eH LyNLaLpcJsyOQhrXsSs1GfQu4+g5i+SmMWHEbmpdWWPJNmLiWUws7xNJHprAmuFIcZLt9hdziB1f YtkMDLcax/KqpfmVmSV0WzgL8dWpTSXUftKFCXrGbu/P5rt3s5FeP5LFK97J8gQk/GRKI22EmXt7 W0GZfWMk/wAz8v8ARZ/Nfdpf0k939L/mdifN87t7vlddde37u/F6a+I//9G/wAAAAAAAAAAAAAAA GNZlidLneKZHhmRxzl0WUV0istY5HoamJLZtr7T9hkR6kfvHLzvXwI5M8bcy++9vqe7zDGaeYqTh e4WHKcOyhtkozaKQ0yZPMuoT8KjIjSr6R4xr1GObG2NgxFyLLlX6Yy0odpM1oyaccJHQ0KfbQw73 Hp46i6vhbz0xTlamwxS0oVYPutQQym2mOeb58OZF7iQqVAf6KUlKjIlJUXcnX2+Iod9Q6fKs+Ze9 5znDc+UsKuCzr/BjtQmCQkvwGY6rttmmGNusBYjERRmccqkMEXh2JiNEn9oaq5cxm5fGLfZh5JKb VhlqoyPw1QwpRftkOfX0o5DjfL3F0IMyTKxO7Q99JJjoWWv4UkNB8tpD+Q8w96fvFZuqmbhs169T 1ImUPMNJT9RJHX7SR24dNUxGUklqNDYabSXQiShtJFp+wPpimb1mv6rtl/0ulfkYyT0xX34vBvO5 MUzTJj3eVuMKLxJaWSNJl+EUGbL2u5VbuZht5tHFfst1ollIlYjFjxkzXnJalOG52x3PhcPtNWpG LND319Xbr/1VyUv/AKQhfvCPO9mE8/8AkTOorTd3aPLMln4xGkRqSQxQNQfKbkdXEqJjQl6mReIv F4lYxl+GcEqHF85o52OZHTYjcx5lNYtGzIYSSJBtpWhXUvhMjIUwelT+uLjf6M5H/wCYkdSgow9Y /ZVmRX7d78V0ZJLhuLxLMVpLQ3I8rVyE4rT+xWS06/SQmJ6Z+8Bbl8VMYiWssnLza11/F7xazLUm oXxxXFfQbCklr/aijfciVY81Odk6nrlOP1WbZiiggrTrozQU6+2Q4Rp8CNtpRkfvMdV/5qUf5pfm T8g1+bv3X9z/AHdp+L+U8nyPL093Z0H/0r/AAAAAAAAAAAAAAAAfLurqpxyosr6+sWKmlp47ku0s 5SybZYYaLuW44s+hJSRamY/KgyGiyqogZBjNxDv6OzaS/XW0B5EiO+2otSUhxszSZfhGmeSe3m2O cbMblRNyamtVRt0E+VKupDDXnQ1MMKcRJaeUnuQtCkkZGRjnI9MRi4k8yNul0q1rYiVF47dPF/Cr vI7EmvT2KcNGn0jO/Vl2xm4fybVmaGTTTbuY/GmQpBF8P3hUoKLJb1L29nlr/CL3OGu6dZvBxr2o yyBJbekxqONT3jCD1VHn1raYzzSy9h/ASvqMhr71D90qDbPivuUzZzmmrrO69eN4pWKWROy5U0yQ 52J11Mm2jUtRl4aFr4iqP0f9r7a73ty3dJTDiMc2+x9ynRPNJ+W9ZWhoImCUZdTQwhSlaeGqdfER 69STbW52z5bZ7apjLZg7gHEzHF5Zp0bdcT2pfQg/aaHmtD92o6V+O+61DvZsxt9uNj0xuVGvaiP8 +0hWqo01lBNyo7heKVtupUkyP6/aM0yjcfA8KtcWossyysx+5zab924lWTX0tP2ErTu8phB9VHp+ AVOes1/Vbsv+l0r8jGx/SVitTuI9pCfLuYmZhfsPJ8dUOeWlX7RilaG3P4dc0oruSRHmoe0+euSJ Pak+52inuLNElsi8S8h3u6e4x1w47kVJltFU5NjdnHuKK8itzKqzirJxp5l5JKQtKkmZHqRj52ZZ 1hu3tQm+znJq7FKZySxCbsrOQiO0qRJWTbLSVLMtVLUZEREPw3AUlzb7N1oUS0rx6yNCk9SMjiOa GQ5mvSrcbRzHxdK1ElT2N5Ghoj/hKJolaF+AjMdS4jTy+2gb3y467nbfJQarOZVLn48pP2k2MD+c xjL61I7fwigDgzv01tJtZzCpLOSdZNnYMdvTMqWbbh2rHfXLYbLx7yN4j6deg3B6Ouz8q93UzPeK xZWdZgFOVDVSFFqh20szJ6Sep/wm20l1/th0aj//07/AAAAAAAAAAAAAAAAaL5I7QWm++zeZbWVO ZycElZVGJhV5GaS9qgj7lMOoMyM23dCSvtMj08BRW3wm9RfjM8+nZHMpFpSPH8bWIW5tsLPXXuVW WBEkj95pIevbbN+qxyChfmHuDKyGNiU5aG7Vm9mQ6uvcQk9e6SmKXmPJLxNJEZH7hadwe4MUfFOo schyGyjZbu7kzPy91kUZK0Q4UIldyIMBCyJRI1IjWsy1UfuIiG8uT/GbBeUW28zB8uaKHaRDVLw3 LGUEcqpsCToh9o+mqVaETiDPRSenuMqNGeIXqOcWbW2j7KW0+yprZRKlWGFzmlxZhp6JcerZpEaH NPaSfwj2YvB/n7ymyaps9/cgk0dfVaMM3uXzG33ocdw9Xfka2J8JLP3npqfiYvp2C2IwbjntnSbY 4FGcKsrO5+xtZJkqXYznur8uSsiLVaz9hdEpIkl0Iap5hcRMQ5YYIzUWEksdzzG/MkYJmiU96ojy y+NiQgurkd3QiWnxL7SepdaZKjh56k/HGwta7Z22mJqbJxK5MnErhn5GUvw81UKbp2L959pGNibe enHy23r3EodxOT25EqhaqZjElyc7aHYZD5bCycS1ANojYh6qSXxF1Lx0MTz9Qzi3uhyM262uxPav 5CdPwy4XLsXryb5Cls/KkwhanTSZrWZlqo9PHqNg+n9sJuFxy2Je2+3Lar2ciXkllaJRWyfmmfIl eWaD8wiLrqk+gxrmzwNxjlNCjZXjk6Nhe8dM0mPAyl1tSothETr/ADOwQ2RqUktdULIu5Ph1IVUU XF31POPvzOK7WT7qNjrjxraaxm7jyKxRmf8AGNx5fVnu8TIkkNjU/p381eR11U2vKLdp+ox+K4Rr iz7A7WwZbI/iOJEZ0itOGXQlKPUhfXjOH1+NYTS4ImTLuaqmqWqb5qydN+TIYaZJnV9zQu5Skl1M c6e6np58rdg91nc146sTMopoFi9PwXJqGU0zc1yHjUfy8mM7oSu1KzQZlqlafEWDcIq31B5O40/I +T9i+3t19yOQ4lLZLhtSTnd6VNPojRE666EZKUs/qIWpGRGRkZakfQyMch/NfYDJ+O+8mWOZAutY otwbq3v8Nh18onHfu1T/AH6yGU6eURqVokj8THQH6cO0kvaTirgkW2jpj32aG9lNujtMlpOyMnGU L1LUzS0SRO4f/9S/wAAAAAAAAAAAAAAAAeNAHkB40HkAAB4+roPIAAAPGg0jvbyL2g49UjV1upl8 bHimturp6rRTs2epoi7kRmEEalnqZF7i16mOdLHIue+pFzTayV+ldj4ZCnw37uOrVTFLitc93MsP L+z58oy6pLqajP2EOpWLHjw40eJFaTHixW0MxmEFolDaCJKUpL2ERFoQ/cf/1b/AAAAAAAAAAAAA AAAAAAAAAAAAAAABGvkrxX2v5TY/j1BuRHltpxmyKxq7WtcJiYglJNDzBPaGZNulp3EXuI/EhnOz 2xm1Ww2Nni21WHwsUrHTQueqOnWRLcQntJ2S8rVbitPaoxtsB//Wv8AAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAf/Xv8AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAf/Qv8AAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAf/Rv8AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAf/Sv8AAAAAAAAAAAAAAAAAAAAAAAAAAAAAA Af/Tv8AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAf/ZDWVuZHN0cmVhbQ1lbmRvYmoNMTA2IDAgb2Jq DTw8IC9GaWx0ZXIgL0ZsYXRlRGVjb2RlIC9MZW5ndGggMjYxOTMNPj4Nc3RyZWFtCkiJnFfbbtzI EX2fr+hHEvDQ7OY9b4qRNRys4MVq4jxk80BxKIkw57IzHBnyPyTfnKpT1eRcNBIQG+Kwi9XV1aer q079Ofv4+c6ax/3Mmpj+W2OjMrFxauKoLNLUNKvZx9/bvh665/bTpt/sulU77LrG7LrZx0/73DT7 WYyp+2Y9++uCBovdbB5HcVyaRTOjF7Ky+DH7+Isj64uHmSVRKYvhLc8jl5rC2sg6s1jN/hV8Cedl sA7LwIRzmwfPIT06Gu7CeeKCgd4O9FeH8yroocEff+KtxpNVOrxteC6b+kBDF5jPh3bPX83XOxO6 NHiiCfSz53cSJFFF2rwKJpr9gV1pwsQGT/xm6rAIIGMjT5PmjmWdLs7PlzC1gXkIvQ/sexIYmUaL kW5a+nX/bRZ/n/1twfAxcgSHIFcmBUNHyKSJWfx6AV2WEsyuJAyrKsqqMssFwAdsarPDGit4aTYP 5odgmMJTIMnPlvyN6fu2hYuiUHsFr7tZq8O0uch6OPcCsnnCxxfezZaPpYUDYqphgdjrxydhI3bF AqAveCk+eJ71vPku/izJlKNjMeLtRueJ1sO0x/ISx7MIfA09l1Co52UZxUXhw+/b7W1EixIm/6TT bunPLOlBxxiYo+CQczYNfeKo2CmYRYDAmuIDooaGGosKLL23HFfHAgMVCposMJ94S7/zOIHNOQl/ hILqqQtY4J4eL/xC3n8Q78/hsFmmeGQ2uwZIkhAMeZFHWZblpQByH5ZRxneOnrRkWtCvGXh3FHVB yydDx5fR8cX0XOmIjo+HFHUUMVkwqq9lL0fzmw1Mr1UwjAbwM4r55CGhmIELgrPIxIQRV/3S/C1o /EK1t/TIIZ/SyxLafNijvYXXfm2xs62NBveyxRPEEX/+IrsiHy+yvXaTBfo84zeXCPQ11l0zYlEu iKQUBmlMP2YrQw6IOOI8kzgaNiIl3TRKxbXxx+jUru8JKqirTbPTNQ4iXgOinC66i48mPqlW14QU BjyGtsF97/wqcjBY/+nU9bNVdcIQYo2LPJhUPhG6ivGLX4POJUlEBSu5wG6z3W4QrRUyEf9yDrH0 e1iroOPTneScwSLO2xs/4/JM/R2KK/r3bnqWQ80oaqwtKnGMTyiot5QSBkabvUMRw0mXwSMqH6kM qFB6x2lMBz5q82GLIXxiIOVhujUUHji5bKYJKzZGZXwTZrkEFAU+p4nF8SppoeocPhc2IKTsknI2 PvMNi3NUHEuXeD3g2YeUqHWFV5K1zRJBNsUBAlZbvQ1r6iKXOFcorDWuZ6IZI5E49MLmzwO/srzz CoMkp0Ive+KTUjKmN4KXUC8jye883mDUtMgLSaA/Rn8bzgxJME6mwC6C5YFKXsb226VB4fTrrfB9 paNWJi912GEl7/9wqtTr8CVMuHJ+QA5LzsPVpnnyboji6lAGKSwRDoGy9Qjptg4nEHTw2qs84pvc +SPQ2pMpTbvlO1ZitnguQFI1sHY6ETky4+tcNW3Y49CDDyTBPCxoukelGzGMzBeknISilzWOTlJI hhm8Kd3cd9X3wXD22TsDHQFi7WdcTfhZnF+rsIDbVpEtq6TyBVaTIqfBB1oi9cl8N6VPzqYfTCcv PmPSHTvKusn/k3V1CvF6VYYdXd+s5Gv9nckKC8bJIvezvZgKw3HdibR8fMGmHny1cMlY03ShwRea ix2gzmCKl9WisoPNpbf5ep621VXuh4OIiyjPiyrTcssews1A02g3vHDCNJ2vw7l8Ps6sACHoIKJ4 LoM/AnosQe/wqe56TYfMxMUU692FPlEikw9qQrhgwu8RJ1v3R0jVl0kk1w2AZ9AAkZ1+H/pqgFOm q3eZWQHFWzBkVc65IrPHmTSQK0sxX8llpPRF/tiz5B2z9Y+/pNrdOTFPNlOTEY9MlUQmEfoMdzb1 V5qanU/NK+4Fj2dfHK/VakEHXUh7eeEATectHlm5BalhTp9JRs0ilCtHP5vlpg8tMvzjCzduKXKU jbglcrjtn+qtzjmoqFWD16KPF2bfnPp2Bn+eR9TrZTmZ8L0Het3dSA3qHtHyE2d9VLzzwLevpZb9 +zNucHjkmHnSltS9VrIRTxttQlC9hU5wE4dcwiTBbPRKEC36LbSFLAcDB45yNDakMb/svgoFocqL dws62tiMimSaxv64tmg25YQYZap1WpNiqdn42oS5lAeMev01N0tq2nB41C7hzFltvzd0OeecxH+7 oWs1r7h4jvVmUnwUpRqDnQyW8iMKOjB+4X2IokEoF0oAxFjCxcv8B3PEVQqqTFmKkxKmHKQ4kh5E aSOr6GiPypQH/yU77nq/mzqJuzervnVVTi/Eem0VpwL4auwnVxpI9JB+8wUZCJulreNB/enU9BKw 9y/IQp8P7V7b2a93kbSi34jLAEVtWQ9IX/OKjqvko3rdIE4q+MbnZLNXGGPqubjLy2vZzSW0uYwP oeIeTMKqinBVchdx8PLoGc8O3IKDmkct0KaRNKwPEG78ZOIyJQDBjC3VUscBm9GgV6E31+BjPZyJ xdRaTdG1KvhQu7Us95n8izj5xuIK5RlWgtBbMl9lfCc/pql18r1ugOealWrX2y1vqZy2NJx4Qtcb Zm7Ek+gyqemFTso0eRtvS4sUuVXAucOQa2wlabrUM8bdJGNuVvf6rZExyMHEt4ZQLj501qJy8Jpu GhCWbGSlVldqxi/GFR3XvhFLdd+r5lIUza1ngjESTFocuT8uf7qbG5miFpanK7ajX/n0c3l/C9/v 5lwP3gKYaEuSpb5q8EXhZvUWKY3fqB+gWlaBNwnnJj8qWjnm9pbvG/166fPpcCkm6BKSUAeGmxHU CR4NqrmRiWYvumpHBnxFKLkgMbNuDwPUTMFC7XWOze257LIFtetNaErB/K93VOnwlTMSS77d3kbj bq+QQDd1QfbNljKt6AJPLeXipGSmWl/RxBoQsWPB8INzpFCxoUY9FtonBfqcNko93gmRS7QEQ7Wv PRvUap95bgc5lmnbaRLCla6tZGiIQTapWHPJ5k/0+AtIwClCVXa1TRE4SmJBcVU6z5/ITt0IF2fK S86vJ3TmTFuUDPBhYW1BDyQam+uExfa4/osJ1BMQaCcTCMKq6bkYQWW4QbLhkfuNzVDoM/JiZwkw zsIhs1fTluy2oDtbFonSj6vuE6HvT/Y6AeOj5ahdADTmnZ2mE/lnZoaaUAg8x5FkUJIKaTDgn2Mx Lc/bL6VdMEdR20nsrervwu1KWfIMGZsWbwOT28jlaZUIMK8RSelYdVvPY7BqE9WOUamkEhtbjmG6 m5CCw+L1mxfknA6/dkH8EZjPIUgHIKjExkDFk37Qgl3cmmvMyubvRFBKfFLoF9g8UhMTIAn2Unhh gM6QUqGSoEd6afmFdlwKkw3usU+AxWzIPCP4Qs+QPI1COM2hWgojDn6GhcqGUQYit+bHB/Fnj6kN feTCJhAAXnN7+w8E7FZsF0LbkMUvOb7NFJjcuasUTJChgHYujjWEnilBCN9ihoXuUnlNAtLDX2sd 9V7tp5cMXrKB4lqnS1T50RJVhaQot07rdzma9d/Fxg9R4vp0ovWo45abjhLwFUK1VGHtl+lWKvEm eh23/gNYwOTuYIYnfdUvl3FXWU9xrX23hxKgXR5VKeU6f1dpCIATysg1Rmsd7XsM+Wy5GotqpyMK mRS6GQqrsEqIWogG1ftBvyj62fjJ2zffbiisVFIJmeAfc3sTEu+sziimBFTiS7Zzb/Yw+f8Yr5bd yJEceN+vyKMKsNVKKfXam7d3emFggTHQ092XuahLKltwvdZW9cB/v2SQlFQvey6lUiaTyUyRwQj6 XGWSBhfosgNpGG3ZX5hTZJpamaZWZpxr0OG1Pt+Ep8lnJST7S8zwten1sRuZp9i77+L+Th7c1L3w POzCuQTxJMb8VemmnnS20wGz7h57AP1ZdJ3xRl3wm45/lV0f5MFBs41mPGMXFOnyOIr9QhRkJRuU fuKjx21AyX3q36WeIaFUJi2lhfx9wYKB0n/HxbcCdAyMGHRo+t8BW57xeNnaUE73z+Ov3EQVw1gm 0cSz2++EWgCxeAHcEWTi4ug9XviU+Tb3sop3kzY97sYwbk5o5VbXcwRXo8zqC/oyT7X4cv8+Hc9q +hCkd2oVmBQnzaVIBzpX98ofLI304VrJqnFgydmWaloYKpKaHJAd5samgXJrtTHbTlzYDiwix8Sj WebMqWKdwWw6PmV0o29ut1IvNj+54a2fRYymKm4Mz2h67XR/1mkGoXS8Z8rUkLJHlFdl0Z7dOFWz FH9ylY/IfVfkn+RPLve95N7ZoC9SLEEbwSOPdpZBWTp98WDt9jt63p1whN3Kid1oQY74U9LLbik5 dMvkQWgI1rTTHjRCrAN2sqaHs7343MkYC5WUCdosEEr6LeDHc0VngNsPI70idChT/cdKR+6wIMjI Ui3jBuoEP71ytgGk182YLIPdXMFs0G+NhjlIOqHHoFMyMPEyJ8x/z7TkMHkBT2vB3fG3AUPt17K9 qA38zHZu+4lsPorgQhDuiJqGC0xubDBJGYp3G8x0Uzl1fJ9UhVwVl0fGILqi85VScoSoht2xtRJr RNtG4Xn9N5vOMLUuNIER33WrNVVXqdU1dSaD9Knb6MDYsbDJ6F2aBEnH+ewNNZNWW5u2Edv8F946 613D+UbnVz2Sl+IqOZQbDtTMqzqozMTOte7s9YREMcYBJwYr/MoRvLRkbwf0kdhYmLTcPWOkp+ub nLdm1YzO8Tm4rNnO3hr1ehpUfK0UfR0unZlpS5H4wmVZiMuirFUq/BBxIsw7Fd6ixbYHL8NfKBcp puFpqh7Hny+6WsKfF5Us7+jG1AIV1c802uAgKuGJF5Ce1Lrix/8ODffILSQFcOAN4xcIhM/zvwtB 3B5Cnge5gs8P5Pwb3ArQrVZTEwfGghQAG98WE5reX2IduQ6AWTBPeAZZEHSi2ZeZ4V7IxnbiEC1l WLBdHXOcWXA/37Df4XVhtEIbQBVdTYbwQUPzxCLpnxKI1YR0uP7NkYCtzgXszYJF3RH4cY784sXN mofHtW43pokbPzZlOTB37WZwfeZueu+lwUqztCyUqGKE8mOBq8SqoytJwwdUKiGbJCmCtfZUAFCI XdCBverbcNpJjsPux7CcZNK8laXXW5lsh6uQCpr5b1p1LfkxNqAFeMb8xihHLrRV2IlXbNAPFGAW 1xdyR9lQUld5Xdcm/6qr+g8XmFYEaGnqs+kCYzraet3JPwa8YN+S/zYyLt2mQCeONXQfBwQfB6Bm ULErp4j1HGxMh4PXQcYbGEPUEF+UKX1TixcMHvCrISJz2PJedtzK/o6Blm8db9T4q8mLBLUze565 GT9ELJ+Cw+3kFfWAyzjIn87pWj3khRY2foIPuUKWkUpIyzIOlL5ayNyTqMBuGWWokZTC14W9swbi HKBOw/dHbUXIEzps1KHhoOVHXevggoDHV9bREHwd7aEldFGDrqSb0NEyaVcRLFeLWptjNPP9zFG9 SoT9WGdk4vYYFCk6uqyjFu/x+VXV2u19WlyrcLmiIo+rsk6VvP+h3JfpMj02+trJK0fmuasT551N hZklIXUMaRh4AWEzGrq9q3Gjxq28foIg8dFfLIuw2NcSA6yG453csiEyy25tzwYiqOK5O43wM8Lg u5tFYw7tGDgVS6w9CVQxsakLe/P0Wl/f1P1VOptzxb8DrCn9IyZbebn2Exo4kTnjfYctROxEMJV9 Opleybp75aif1Oh3NTJ2ulx2uk4fTI/Zq/vRuY0aNSC0uNJ8vtiN5QCWyUaP2LY/Cn6rvBmJKXHJ hC2dn05orO1gjPwgLjo51AVSk1Qf3C6lU5UVWTlqBKFlRByMpQgusahcMusAC9lS/Y80RPlErlYr PX3KCEc/G4wmqE5YYJQCSeKFiEqqXeM/XPTCakCfYI938KE1WuIvIUN4p5+DRDFSLvCZPOH3G2xw nd/XlX//dlgv+VBrT1JKbcS8Vyq9fJJPuGyMZNPtVBMTn7KBqqM9LGmZ/JVlJ167rQxLhnrNUB/9 LmbOCL1lqI/04cxDs2dwLWak3yxIJJHzYhQFbdtpMConzlp5PorO/P2bIhwq6yzUdlMhiXPtY7ko rRydLh/vYz7TtJhCeza7R+6cufC+OEfnzYXw4U3W64phkcyXJ1gOQ7fRLTZMkWYr3+Q1BhvFKhlf ihNdNXXlo9MEmcoikl+I0ry2Eqzw9ZW8rMSkR1i2jWgcNu1fNdKrPCrJrnYmufykitMyTbQz0UcF 5xiUORlPAekY2VQC0tEr45B7DUyldeCnUg2xNxqkr4Poq9jqONSnLETwh8P+9CU4KrPVP6iHIviU Inee6J6R5YyhJomyk/X/paX56dKCsjU9Wn12b9l4b3lxJYCy4Auce7lb5HSEh4Xnw99zew3RP7mV EeD8a3FbxyyXqKPRFbWPPYy3jwTQ3YLH3Fd5buSWGoZlwrCB5Srm/0PU359f0kxppZnEmmqsJx+7 KEiCOE80jcJHxD9EGTGWbifJBUHkHk01DeghR0po1ARBJdYt24Hfb8SKldUDQ+03OAOjPhYDKgT6 UZT4C6IEiIzhY2GSXcDkVL+Zz/yHhDUhqeA8sbGcBEYx0oKKCzRwK7olJKOuA0FoTUTmdi1BIZ/J prmX0XxegMeRtNqajypqHfoJ4zGd5KteG40seYcB9kerHCdyVkSeQbqOZLC10ZQfVOb36nD3IvOI V/4r2sDleaKUIxZf7elyNfyvLC1PgIqlAk8mkqEU8VEqbmXRRgq8pLOFkh5POt7J4laoFX7XIDSd 2L0oDdNNBGzJBuBWEsAAV8pIx4mcV7NdNYhf8ujhWLYy+8aCxzZ3EuODPO4xeMPqq4xsoychWktZ L29O3xp5qLOfsqvtdKUuQ5a+f9lEoPI8L6pJtppoRTOIHB0oOkzFgUKjELi/pYKrop+eznhKKDSG PADIkksVQRVDAiUwOByHQlSDaWLFspeJAP95XDAGMZdlXPvCLIEj8rEwFDZ5lcHhxjXocLa0Q8dg MSjtQKxsKcFmQadM0G7kjfk3b3PjHmSR7bBDEKAvhWyYMVqefwGTCCROR1DwF1GBtEud2l1kqfI1 TpBME7+UNqw5l2kKlsAqpvKDPHudtkXuzwhOkHIZecTsnwsMIvUydHDMUnYf+VZf7UK5uigLPnUp hTXOxVBltN0PGe5k2GlUT+oQRTcLDjirLvQh/M6NaM61/VPi0C0tOqfhreThxiNWcHNGmhWhM8/9 9T2Ito9B/S73vqznwi1A4hSjtCFG4b4zOw0kRDku7sF4/cbhFMi0EuxFlr/oMs61ArlWKLcpkNfI Tj79H9MG/Vb/rqhJFxqBOdpgaaPuxVF/FCuvZsrmlma1x7iFdDjy17V4vbFY7o5P51aLah6DDL5P Ct5J/BGGkjKuqzoLE+Zr1wXADI2WsoEN8Iny1wtwKu/TFi0sAOOKWcPAqUcOoG7A/SRhOF3o3tNE L12AbCIcjNiRGvIalMoZD8HgfgEOMwuc40JAAqfulGecXhsl3XtQXVOmFEV9dkNgNnP6MpsTkD42 vsR1elYXxnOas+KpFcny/DqO5z4uqsoXx3H+3B2Yn3hmZbe+5urwnosjEynIuMbjqx4vzDkysBKk Z0l0K60ZR/g/xRi5f8PBAxj3LZa+gpcsn7BUukZOWPOCSaqpeXP0ErG7JQWU1qQ96Hh5kRE4LDcn yZvWfNbbIonrsrh04oy6QlkU1LlKTymehFo712+/NAstSYRtDv0GWfh/xqtlt60kh+7zFXcpA52L ej+WQQMDZDGAMUl6r5YdW2hbdltKz/Tfz+GjHrKcdLyw7qnLInlZLPKQq2LPspAvs0y7MIlpJ0aq l56xJPJm1nPpSGsduSnl8SJXybhQB23ypydx8bVnrzPBlNKamik/LKMjOqmikBaKMUfnNyRCWcHQ v1B556+lIghyCza7sq8o6KX/3l5hdNgcn+Xtk2w+6MsbWd2jMLq+eCeL63cGugtPPaW4D/AUA5VJ zr4xmL0xhMkXYrIpq35aWH9mBPQ4olLmfRf105WKvzYGZvudMdB7v5Ywa/qMClf5BFHoKHKVbkzA jwCcvsUPUdW6uTssT18pVhD6tOP39yJGl8gZ3vXeeqh6EVVvBxQsiTPgIjIep9IjQxfW/lR86BDL vPsiPr5loXHuu7GpHJuhBZ+YkR088hb5RIuH/eEOTBKUj1LO0astJ6RDbeS8FPn/XkXOUXn1wmt/ vHE/2vUQt5y6dZlyS3JonXpsH47L9YvMTcKn2ermeFw+8gjHr77SI78X0ccrdRWlslDN5P5jk4oT 9cOGa9YAxkeVXYSOC2241xFSedjzUHyLt49K9lmehVj1V1ZzRCSn/VxyeZhsrt6R2C9X4S0epqzY ++R/ooBQ40tIwWpLTMrEhBmh1gu5Ik4qo5MuyxzGfcA3MpqV4PhNmxSb+JPOhu+JCz8wx6eqyHAh grPZbR+YKvFrZamonJMfH8SPa/n5qOPhclLxJx3jtoqfT2rmWxsnVc8rtb+qItX7RRy/ZFupDxpO Q0od+4chNbi0nhogh3TLJFqoBPNHI7yR2d3+RP2LuOzTmRRzYJZgXs+0yEtt1lXAtPnfScXlbeOM 32T1cNjT4Dus3Z1Jn7ZH4dF/yDJRNXr7UXcLGf+XyBDN4SGx8DDHEi/nzqhapxxXlPFgETd/yQ6V bBvbt2v3XrVLrmlz8fVvk2CT448HjnEqsdLRZc1zZgFM1YSXnW4HCeZGzechDV5SZfMfevZMNnWK ZSXS0bczLXR0L6qwAXD9MNHh5d/ELZRxo8TccTViMlMG8Vh2whx3xBPulc/qDDKTaGhmOrSn3adv XLMc3SR3MTcE79yP54UpVBmkokYbNYFvyPubM17u5euEsWv1cuGM92PWXD6/dve5+cgez0HGNSny uD9ofcQGuh4eXJSrMTBHaDu5sdxIuIseIUfuNA8Cex4WLoql05mVh9CfyyBQAZN9VgoD9YEODx3g yJaen9jFA68fW42HI78/aDmH6PL16YXFiKFjEQStbv78xkt7EhC1e21NeLzjFnKihXs1iWykpMTy NZv5QsmzbY3MMuGX1G6qTrzwN5/BpJudCdyR8HpLvpy03XDDPCxs5fe/3+g1WhiRWOlN5jfihkse o3NZW4yUZNyZgz5wp0lIW2jbSB3HLdy311Rz4PZvIvVBfrT+J67/ge7V/Ba3jivSzS3XkbRp0lvq PXwuDB/09/ZmwYXtFpdPouZWpHdt9/7M5kE6mF+1HKBw8rLc1IV0tYajle+Nnm1K1J7tavyHOIa4 Gm+KlzgeiVVGoQr4vWV0QxQ+UselnwdmVJEpfKQjp8U7+eF++CzPsvdFwF438cjQNf6yyGwRdbaA gsdzwQNFh2r9qa/jy7va5auINfUv6veRYkyb8nCKBZuAqv/rfPvN7XHy6LI/ZI1qMv4fogqeH031 VaLKfS5rx5QJD/BJfl509XErtOe01xcHISGPCm8Y7pkrQYPtQOmSvMdoST/cBHVQxe+1/HwUkZNq bMRqJwru1ZEzfUJ4HpqhwA7TEoY1R4PIZ1kcm9Fbx6dyx8400sx+vL8cS3D5beQR6odxxQBQS67a RD6hRO2ocN1zReEaxjSSChTx6ruF5s3N7e5K6qbMn5vbIy4mGiOq0bTzREIN45ppSRV2Mb3cS3X2 NJehgJTNr9f494UbzqGpS+rNkaros3hz2CvZd8Sa8G+9sm66vX++s/LVyB9MhaCEPmOmQ2/YPSJC OYFSL/itGV0FNSQEG0Dt39Gex3coTqYmPD70x9XZtAC4TMAjfwFC8Qp275Dp1SrCtrpa1yXr6mpu OhTQFuvWYJzYac8iBBRzU04olzpM2cJS3RhwcEMa/M74rkkR7cORJ+QF22vPIkXTYG4KnFuJV3dz GAyj9cMccHa1S+d1qOFn3lPRi5speY5rzoXdXU1yr6FFDrB23CefwgXGyMAwwTkEeoI2RILRNYxJ AAGqZcLd94QbZusZrj62b0lxtaafdkP0PYlCbuV72rNKwXZxXQMKHiz32OUAKhOHPWDnuzRQsP3Q G+J9iDnf3IfxrFLofLlHH6jUOGUhZiw3fS9w9M0fQtn002qI96W14AqwvfasUgl1okeo5NUZO+xV jA2uDHvAZcSzemIiPfMV8b4Etq/xbM8qlVY34gkU5nhag7yYA2oNZUDziKEfIe1Q9mJksVnvWwNN EN2rlKEmrsWEyS7y0fnpgtNCGJEliKLS1TUoeynpNLgdNMGwlhFeVG7k3BRfi6If5wDTQg6hbwCs I8Qdyl5KvlZe5LmJhdXWETTAYPJsteIYw2TVY6cbGwAjVw+qmwxrIidDlv20wBUrFEvvLTUlhk4h XwKCLI7gcoXp772keFQo3llVjlLp+XWlbwFBYFTYE9wv3BXsiKo60BSKheScvLc4V5S7mFWcig97 y+JIg5QXZGqq9B7pBwj6aLPAjNNJiIIVcSygzoPxZCfvSyWYRTyjVjmFLJ5h3c/vcf4Mk0KkNsHY xQPtr1082oWkZkQEv0ljASdn5ciwD4nCWDxNhOoMwQpszf1TaAV0HLPXw9mKhFb0gXbQWXZ7iicP LJofPmjyQVeGSjTBks9wRFwmN5CRzs5eUIqisAiOkXBqR4Shj3CpoauwCyiVqWqjpETYVfXbIFmB fYszvEQhdDjXpMcY0eDQzbxnr8HOkNiurHakSUWa0UoIIgEuQFCyDM0thoZ1Q/LnEhERIZzVBDgI YYeuqIkbcPi4iSnydzuEEgwObCUGuRUOTtJdMrHdIgOd9BOq3MqC+0SCYDlyKR3jEGO7ppztlhuM 3HKcA2H+cC0DirkwoN+43FYezlY8fRhgCgy5MgCGoIj3o31brwu83RILG/J0UdPQ1mFzAHwG1HV2 YKzwFktcoOsDsn52gLiUyZMDRLWGuCMlXVVDzbhB3rowGx8rvAPQ9O8FLIhfnqwbkEY7GQe2dZJH 3XF+aOtQHajEZctkfyzQBqA8Yg8UvR3Gq5S+bhztuIzIA1FRapo6apaRdmdhHwssbzh9my6k0Rz0 grs5xxw41i4NFHrMO1C7xfItHXbHAotbvoBNEyV4GXYzLpmZwp2pBHRpIKq+qmkgtZwpU+dYjwWW RwsZsQZKc6wTSMwca1DJWppnhMqI9UBqGZw1WzdZHgssj4QdsU6Uo3FYjtSCyrAMnEasgaLtpzaQ Wo6UnnO0xwLLY/4Z0Y6UnVO0Ma2mOdrAvvSrBeRGtAdSy4GSs06WxwLLe9D0Hj+gLIVMLHui+3FY BjYj2qj3VKtV00BqGXW2nEV7LLA8+syINhXlOdqo13WONnAuzTNCaUR7ILXsKD3TZHkssDwa1Khk jvKzTqUEfaG6YRk4jGgDedPPbaBWyCg952iPBZZHSx/Rpv4/R9sS8ZqiTRwi1y5t0I96tAdquY3o +8lwx5zZ6OQ9eIkb5LCKI63DaG9tJApGbPqBdSAWcT3qVLE7hCjuUWrfgRtWxv1Fq40jtsiAfsaJ SQT1TUPcK+JyoEkSHd29A4SLgD57vCOOgedAcsQe5JnESg7jVdV3hWZcE0VfIteRS5UpQ0Y7J4n/ 010tybHsKnDuVfQGfKL0Kam0jLsGR7xRe/D2P7mZQCIdO+6oK9UCEoQQsCN5Jr8niFfGjr0b6jwM Aj7s7/rg5yjcxvoP0Gu3bSZ1293Bww4/0DQtEwpQi+0zBHfvBe8DorSiieB5okXiDIKGF4jdSqCv j8AFvg+ODbE7sCsC6GiRE9QnTRZ25S1NcoTC4yklxaIiEyViFBhv/ijbokNXgwZgxSeD3dOcd86y hrB0hgVZgjjYYXT0l81eBZ5F6wge8oL/NHptfQR6j8b1+/GThZ9saG5ov0geQWS/f8FlJiYp83IV m1cWrNqUtLDVCfj31wfaxdXzn9E54fFtQ4VYHLTYr34hM6fNSTd6SLzmOb96/mqc81/Ncrit2nbF PHj5vMgGAZwQW0p/5wKYjRXvEN+8nzgE3j81vL0nHcPPEuy/90oqKRfnvPV7IWR+a7GuDd09b9G0 SHzvlYKX4t56cM1/r4TUbz2yNdepOVYOPSiQPJjfK/+ph+8Kag8uZ0GMkLpUzAeza+FtC7wbsUDY 0KAV3svisNi/9fFZadpzjIVmEwIgai1gtwEh4T2qtvvMcsdolQs29bg2lpuy0hrgE8LkQjh9M5ny +bPBwT0J+JW+xoI733mBQqCxh+mpDnDUO40RujGjAsirETw3uq1caSEcfZ8LFojQpjCFrR3G4KIw B1Mdwt+ndtySPMaJmnvN4xixUFfuMJjaAUp9DutYuO6R7AixT9w3jEOMhX2Ie4HBCW2KXFhTXI2J Yh4sdSLhxT7C8HMfIRbqnTsIm5sydYud0TYFeCcNAj/8UU8UBxgL+wD3ggXBdClAYWcHMHgowMFS wf/7tJjIqDOP0e6o1d+5QOtl2rWwEe4nDoH3Tw08gmlFeauMha1ChfLnwn/p8M57oquAsT4LlUaT Gwve5VbHzxLGtIiFu/VjAf3ErFMLyxqMudZh5K+FB93TFomFrZQieB232b+JsotFYqHIXkYawUPn eZn1+LYnh6jMEQ8RUVv7xfpsaGbKyjeLXftV924WrpGaAtkYgR1XdXv69l1AHV1SaAAaz9r2+sA7 P7Y9YD4U2o1e9GqpKZDJoQvHZXB78R27VrzNrmFhTri3vRvRqnXbAx41dwM915ImIZPj5Yt46jt2 4ebveN683Ec8B2fXI56BkQ+ej6xyo//CyPT5HGf6E1+RVY1tD1y4rCAiI8ZeeOcChAau8Bb5tZAi //v45+P/H8U6k/LqHGDYdk+0Oki+r++Py/KLUZzGgj0SzwSxKuybyiz57TEQGji72A1v6KPpsO8v 6rUvGzGsNzL4qR6K0p9nQ/X1kZA2P3dHdVmnWdc0qrj7E204ueKTvR29LaWEYAJXmpAGQ8CYSE/w DQPBGTmwAiA5JB6frjgATfrulzjC6GP7SRfDgH29+VU7PcJHL/IzgWtNSHlJGI9QFHRlIfgCeujM sycCbi4LRDgELVQh9Uq+IIA2y4i3hrbecwKftyUFPmZmRQLXnJCaJGF8pCmou4UgDjCWNlbOgU3O C0RgBC1oIfUKtrCu2vX90dGXNA95rzYcXK/e/lgFo7C+Xa8QTWq7kZGaYJ2l0nmjri7tzBprnp8F 9+sjoUXMhV5Hoc0aiDuIZt9p3xVvLf/HR8tMSRDXUNDuYUj4RXRFQTxrrhMHrEs7s1qb92fpNrmS mSKp11Gzs5x+f4yCKjaMOz47R6bX4IyhA0vguhPSriSMkTQF+SzgTv7m1Jb1RqXfAnC+Aybn0AIX Uq/jARgoC5EvrIWRL/icli+TQ2KI69s1C9GothsdqQnmMhDMR8eAqq0AMxMmQYRG0MIWUq+kCwKs EN4VoNV82jLmz4V+le8ZPmrVsSWIkiVoxSwknHxoCvKyEeQBS+YMwFVvRUAggiNocQupVzIGAxSJ yJkHLXXkDD6b5Qw+7syZBEFe0MiHhFfo0BTkZSPIA95XbmUp0vElCAOCZjykXskYTwRKRbmN/EJ7 2f3Zxue42bng46k6uQSuOyHtSsIYSZOeobChd6haQxlbOXA9UiIQBgTNeEi9kjEK/8V64XlTrmmt pr2h+F6WOeV6MOTk25AoHo7E9qpIyh8c6dPjJFt6nYDLtXejPmUGbSQ7ws4iJF+bP/YU1I/yuC8F HW33To7f1RKJX73pMDcKG4mNgaScnfTJF9mSL8D92rtZr7K9SCQ7ws4iJF+bP/ZUFJTIqlIbhgF3 Bc/9bW1OqShf9rBWjJU4AlQ2XoN7DhMfOHgjcPu/07qd56mGBlj9sTmU6OYE96ei9SRq0I9xYboc D7dYlefeGy0/H5dFBdaU6IKJpOIj/ooP8Lye3AyimbMbRXwSW3wk+dox4Z5lsUImo7oiRu2y6QDD Ki5U4fSz2Icu3CghZGPhSCvMnpgT1cY3neYchQv/oIhTFkFDiXX0ZXbudfzZrc13QSGq9a3Ebvad mDEFRTjwPCQ8zEn0jegSWV5MFvhha4Axafm/F/+9nmmS18BUiVMoEQocGZqUdtuf/WlEo77+jtL2 vFRKfG88bYB4nwsPtCgWaASvu2cwAmY0jr/pYAonpPIdELf+PvFVXZzKyp/nbtuWQ+duXPR/uuLC p2fb01qQ3eNwlRdona4ip9lnmHokC1K++slObEMjuT2dqD9YqIi6cUX9B2xjGWy4w/x3ydVyWeta W7dzWI+ru3z7BVcru0ClSiUX5Eb8z8Dwus2yoVPfgQzn3udCawokQLlXBjLgDmT+n5Fq7fUjbp6J d0fu0UKxajSxAwvFTovhQ8Q50BYVAQdfVrga/HH8NnxBuTYjg8EDqLSNWOftvPfCtAoXsjBbHZpq h18qkoHfVqvY1eR+77gZjOexG3VhEuElrHKz4kXhhbEayff3IZwGbnR33IxL5ZtntZhY7hFepruO 2L4jxnqPO9kUBr5N6IdK3WEpaCZQYCMsQAOZFmERyrDsBQuLZMNNqc6wyHbGBQujHwIegVSXUOZi IdiEcDA9/eJeJH1r288LTes1tp/AXdsJWllSLJR294LxCtEgLcXby7C8vcSFPAQKX5TtpJB8dBwu hmS4eLpEWsifNtLFhew/EhywZH4DXJneArK5MRlJztlKaXono+kdmiFmb4YDD3RtO1YJFctYiFCH cBzD6RB4QeU+wYf1qKV7DwYlVDGHALMoMQRkcmMykpzTlVK5FyblHODc+Qm0ysw4JYooBvYQh6AH //ADdPAqHIk5h1VEuQV46wzx3TMrBWRuY5IJMecplXJKFuUVcO8ZAXblGRyBiJxDj6oLebhPF0CF xXGmR2P+udMfgPpIDgA1IhQKyNjGZCI5J+kq5Y/syZ/Z/pSdgUCt9AxMoghbYI9pCHq0Ty9Ap7Ex lU83K/JOvnvaE+oQ4MnkE5C9jclGcs5USuVXmJRbgE/LzYPFNJNvowheYI9sCHrMDz9Ap1tLLbc6 Ors10y3A8ZSAAHcJjfEtawlJRUJOUxrlkwzKKeA7IQBHAQUnUYQusMfV5TzgpxNgw/K106/hWUiP AFqmH0DN9BOQtY3JRXLO01XKJdmTS8DsqxQAFMydfhtF5AJ7VEPQw316ATooWrVsp9iT9e3WZd23 Q/Zzl85eQAY3NrdCLtwKpXJMNuUY8NoJ2Fgqn9SUKMIX2GMbgh710xMQGkeP9v3BMerIQM5XmYEA Q+cf3+mWILlIyHlKo7ySQXllE+fe7W2vNCUKM4GdQgg6t9MNPGssXk96hblgrJJeAfbMQoB2KQUE 9vMv7M2By6lxcKX5FIfNfInR/+88BLqv3ZolCjuBnUQIOr3TE9RLdFw7DfFzZCGEp3Zi8tk56N8Z REGLsMtE8F1d1nW3lc8ULkRuZanM5EsQz5RDf6ZcyCv6wf3r45PBvNOVz4Hneve9n3RbD+8nRyc9 vAKytjGpSM5ZSqk8kk25BFzH3o3mZ6VTG/1LebXk1nbjwLlXcccN+OHoLy0ja3hIRvYgnf0DXVUk Jdkv6UbDgK9KRyIpiqSKrsexGeEbzbz7JFwI2mTFMaFNwNHQeI5hQd25HHyVtAo5g2XvqaGUqlIk taec6BCOVmG1ou8drzsbiSRUQQLYR8xYnacmKlpUwqdoc11VulbS5t6blhdMVFWeml80rcpBT6Vw ZO4jQ8vKfhR3WC1D34tQx4/QEpwtDm6c5JElOF8xh63y+uYVrsbljKpGFsekmwYiM3ECPPQlmNjY TlDug6zNdcwOZOkiA/bBU6NOwAmA7SmCHXfo0FRXsIDrey793u0Qsm01sev+uCdmzrae2QPPt24Q FJ095ky+P/GGcHNz6nupOneftrw1nXo81ZePLnHDpS+IBWx9vb557Tii438KL5K7Kz4+Llz6PJ5B 67LG8YzByzPnu1xxdjuM4PMJ0/5xT+Rs+yUOR17zqDNo+2VOfI+z2Ob7ZB4wFVwLoayDYjDwpHu2 wp2oZCCNYynsc4ZcPEQWx+Bj8CkCt3ItCBlSLSkniPrk2uk1oiAfG/CSSUADl/cjK0HKj4HSjEwf 3ZOP2VaQe102LCDMPRZGaYD94TbjrPnF22sWA5COYpXdLcjJobh3r2TWy6e3feOYGxYu2wmWcg0j ZDNq4KdwQr8KjFt4Xwih9Xo4KOhAHu7A2QfnPjjs4KL4DPsXNyVWmABlDltvsDNTfAfKWX2FJAEs dB2CH4R97aUw64FslIDHygwSAKBXPwOvBTxhVwlsk0OBJre1unwlezrYVqyijEEVyavR8cTPtz/e fnv78w178YeKNlk9cVFoMAeu6Cc4wYt/f/184wpQb4Q0WJ/+fzjCs9DUdqLkzm8oVjKyqvnTPrzH F4exzaa/w1j8SMIf//pfVpuxOCSu4R0/rZos2MOSbeNLB5mHitw5U0UYnTMFaqg1sXLJ3+e8RCGf 70fJfl5+eI8vDq9tKl9bpnuD78nljQ3tAd6mfvHUUWInj4Ob1755wyYd3j6ihqqni7A/uqveTGHH o/p+rl8w6QGj7cyF7/C655qOKD93KEJ8pOeyjjgnmeif4ottjH0mFajWrfJoJII5eW1jv6LrIM/c UswHocFNCvWEI/+t7zw4v8RmY/bhRssgJ/i7jHrHUw8KYpUGwyVdxrtKwYiJ/cjMg3Nuvn5C+K84 ycfvtvEX2JPHyMi/INO0zyw7/ulgJPk410LJYs6RtiFM8YtCzAuDO1Gvz0nNEHcdh3i7x5SCM9qO qF5cP+3cqpLEHxuDQa8ZGEVtwsU5ME4FbMtBMdovKKdxVH2DoYlnrmP8GCi8PCrfcz0dq1nNfvLr 379j2V2NkK2Y/j89U8sOKg1hT2do9SfODTDTOi8O3snaj0+6CK8v7eLCLsSBPT4DufnYw6OhLVk/ 1hOi9TjmdhSRebd8NAGPdlbba+6CAmnfwvPaTFuMfdUC9+tbApI4X0+pc9mtj4yxhz1EpE4uKZD2 4Yar1Yw99lVoA9J2DluEPK+nGwWmtSu6UEWPK4Fa3RcSSPuGKp0FrI99FXq448/C7u7yZyUPuvxZ SRfCHqJ5/BlI+8hpvFLE2FexndseAiolHX0NfdXtT+DV4/t7KyAG0sd6TCS5TiaBl/Y+7LEaWKRc kaG0gajrSttjasi1xUmebF8laBno4pnPI47X0Iw+ZJa8h/eGJgwUhzmLJ6wt2WMlmWsRK2Svbehb qUSz2sqKKmDIVkL/+dgmxUwyPCBWc6AUQmEXrEJ2sPI1MMXKbY7gwSziuPHsXb5Dt4PYNyyx6FVw v2VcKFvL4VjE2fc6nss2U5Rz7tDk8KgGvU8jX7p9YouDrbXcsLV1qc+47dkv/RkF8MlbP2ABPQx1 Do9+ZGPW43Mw5cmFTR3WKOZvkugMP5Z5q+9KbkGUK0K/5Y4IcGjLa13398JGFl0fCqWCoEhYN+cg ZjpuCKmcFcQDWl4ZQlEhGW7kw+VRIbbQ7KjYnFjLw7EQDl8+UI0KWbOYNsJ8soKnH0XKS8CmWLJ0 cmj5Jek28XFPlKz1DW0UUCLxAyyIbIeW1rLWJiy32XHFBsC6akg7yLWjQpS5Lu1nQutx22keYcgy O4trR6lqo13aMcEmNjYApjlD2kGuHfXwWfnSfia0HuUjpyMMfeHTLu28vzEv7Zh4+rbvPSPRVgpp B7l2xOJALB7tZ0LrUUTScWQmO16X9jTxQudLOybG5XnANvc9HuTa8dbVL54/E1qPenh5HjB98TyC 9YvjkQBtWweUj9s3cM0dt1AuxRtzcRf32eEGztEvraj6fV1a8dYff7Psh9I9Np2o3XHW8so4inmZ VRvpXdiBsmqg2GSlEhOAbHYp61Tek6Vg6ZSHi8LLhYxtaHxBGlJRMkN414PCzF+sDPgVIs9Hf4f7 BCjgY0ibUQNwHbNXsOObahNAo0CSaoJOgfb2oG51WIxgB+9jTetnnJOWCSF91FHxhQ0EgYVjdig2 xkkfMxYIJbiKzAbK8LD2Y/wggE20g9CE+JhqMrm+CGZTnPEwkXPpFdlfR6qCvve/f+39IKTkanEi R2Yp6lw6Y3t/haY/QQIDvmp2HhDj2fw4No7T2AMaOlnU+WiCOL9IJnl3jW3bUFACPWy4mHu44s7h KH7bNlYcqGOzL1Vf+qTsole/iQTwqOllBIfpro5vMmLnQ4q1ZlKU9kRuMnl3iGi1QQwmHJrUso6l kGfqIEEGN6Ypgh/Mls0cMrpO0HdEAm7f0McbC25xhFKceOS0mCllMtSzopAcsAMVMAeMxUYqMi3G rfgqIJJcNWIb0rkmAaCCXJpwgjW0j3oBG5NdBjHgk9IQtjo4R/EJY+q1zZggbExAE0VIJrcVcWLw oTYzBGsPEy/IA/hyTuANDa5d09/gOPE1IYGELW91pONFZ2tPvEfdzteQgoTDkx0PPuE0vxA6ER09 Jj404S7WBsDeJb/WL9CP4xPQVqtvN1xEbIdfJkMhdBkyU2fKO2zCVl/tB7HQiXNG8IQbLHzCRxZA B9Gmn9uD6Oqe3P2GeQe/TFjQ3Vjy/IZdlwfAtsTjw+304PEzfEmTn7fihPT8vE3jxJdw6F9M+WVi b/nj7be3P9+SMhPUYE5xujLZ9CLVP98eWjSZ4eBN1gTWhGT+6+cb93zyCXzUt/D/ByeRItNG9kKe z7ZaPZCt2V/5itpmdmS3mH+Q/3kt+XYIsCw+lQOtFZL656cbypgfsgnRiXB84NmpOpZG2mNr+gL1 h1Gj1cgwRpdkaCwHaCQjabfBd5NiuzfwbjIgdcYur4ugKWvI1MRG0VpVDBdH5D8p+cYNTOiGVOgb ZEnIcXtdgdu88H46AJGL7T40wQ6o0la/wkYonVpPc/Hma/TBUa48UWYkxjk3MKkbcn/skB0uyM0N DW4voLlOJ5vucB05gLsjoFzlu17bXhiAAJHhINTFYwLDpqAgyd5RsYFJ3pCSYofsCUluumlwwwH6 ioUALZU4fAB3TEA5zXe93FpoJ/XqMrwyoc3lGE5yzxd7k+ybY2xyA1FlLJcxIcatDgVudyHzi/OB ZKQVJw/gXgkoj9mm1zYW6rt6JOxFpYPtuBHcGZ6EV2U1ErsAz2zI10Qe05NSEHDNVxWpInhYGFnh oTepLBZbRh6JgooMgLw5VU2zgYdkaBV2sYApiUagmla0QpWEhcSpoxjDHrZtMpYdVFJjVZsYD8g7 7PMvoD2t2ULyMTsVQBm8/kb6dZ8XFqI5QLFH+4Ni/hlw88jAyANcUiPHEipTaIA2ODKf0Lj9lT9n p5DJ1VpiU/vxH/arZNeN44ru+RVc2gFI1dQ1bC0PiJABsQh4YXgREFKihM+C9ZQY+fucc4fqJvlk ZZGdBEGPfbqrbt1769xphXmRtZSjfakdokD2UQP75rrLrq0h0y704R0/07DZ8q9Yrk7FAlV0h3am oWnY+pW6rjsNUe40zM69bHAtw02zIcIdqGga51+nBbLzyh5ZWzE2IvwSjH8g5qyGmYukQTbR4WzB cFZIepn2SqnKjR503ENbbXzgV11bmkx/qRmPSJ3MCVG4U4rI7TgUqGI6A2oLyY5TI1gKFaRBHzKS Ye5jZ493bEShiVMlyNTWuoRMYrMLcV2CqbANw7fFIk26fiid7GpoNevttQ80k2AcyAkhyPwJz0Gu wgshgkoR45/Nc2KYOogYb7MlGsUNvrRtcBYbeBOpaD1R8YU4DYcApbmYCfQMg3K+bRLFrkzQlN7a tCiR6tMgoJjdIubhmk2iAz9txVTF96mWJtMt8hPdosyInRaihYu1TNdMZI4zrF61jervrR1aY/u0 Cl0fM5ibhVLYs69lXazVRDrw81ZMbXyfaupC3S470s1KOl+6D5DH67yqFZn3DKtrbaM6fWOHNjqt TLNYPdq0Cp00/SCIkWHi9NFPckQtbIMqaLLcGD/JrQHOk3aR01ycXpnIfGZYHar71NNb7aXH3BCP ffY0BeE6aYc4nqyzZz9pQqphe1RDlebG2EluC+pYnytZ/CbdJlD5BuVo2yQqbTXnhISmeExDDiDJ JicchjT8CgFScWMc+Gkrpiq+T7V0oW6Rn+kmAac4uQgUSpqSJrJzDKsStlHV21rCgSshe0re7iwA B1Razc01cjyDG8hQ9BWZsxuyPDoVJIKcZHDkC/AYL2Kq8r0wlSJBYxwkTMNzrq4OKG9MysWEIyL4 fakCW59ZmcuVS8z9nDhY9VEYoFoIXJ7UEKTyPswSKMWq0rt8ZhmBYeyI5OMiMEe3Oy9KGPm6DA0T 3Me1T7gWKkUW59yy+Egw/o4iFzNxUx/1LOWYLQRhxZUYVCcURtT6PTHc5mZDQ4qsv7CzL9sXS9ft lAbY6jxMke6mLv7VzdCdW6Omkbj+UNtqJHxfVhM7XF6miRhBljwPVbQauH6lvutORbVsrLNDL9sX qedpHTm5lNWXClf75nc3QTdvDdLFWZrt2ocYyKEXbMT8R+dwRmts2UdRQgQZF0d2tgSfaIgCCKJf DxFB14m6sSUeO85hrzM/gnZBeRYbD8nSvpLSbaEKMS4SACEiaGFzEsQSUazVlfCoHA+iHLpIXVym n+KQASEkN7XL+BCTehEdZ5G54doNmpFk2n1g0uhtyMCFx1o5ezFdDJ+4JtCZaEJxiu2QScol2czl Z9jMBagjoCwdNjiKEAd2gEM53Hbtp8bn3evdX3a8hRqTiCOxcQ81p2X/yKENOYKdGWgCOSke2Sd3 XHjfv3uF3b/scMf4x5EOd2prF6SXM6qVfIKYIN7BwaoXyn6SLneLJW8oBqrUF4j0SjL+ASWaBMhZ DzDiEogWWRrQaBsKtgyPkQ5IeoLhhns2IUB9+AGR/XLSrTw+QSZqpalG1GQtFTdEy+wRl2I6KHb9 VIgqP08wy/R4M9o0W1EdvrQ3pZQ+2jkmw87RA9xH60tb4htE0sHZEUTsesA8mqEmLgvtHvudhe3T tRz5K9RyBnx1wvPp192zbwu4cnq9K8cl4Qb4mY/gTWWg7jNGj9PD7scv/vjq4e27/3z50/70YvfN 6TdJmighCfMGahNZihtjHwqH3tIUi1lphaZQ4EM0HfWapo6dpsAbmi7xiqbDCJj05oNQGpWZ9xK6 AWep9Mi1ZyOpwNaF9xRAkvT4fyRpQrJeSWo33scWUZsPUI+71x+6YfprQyh57U8QmDzKAxLwLXbv hu3TtZwnCXVPIbQuA7Pu5NDXbx7/ORm0TVVRx8eO9UiE5ABKQ8Q2/A76GXQrJZaVFSxv1Zxhj+jo FlN7PslfFKkaxrrJ8GWDWym+dPOoq2jnTV7lpLBRVjVC+x4Wvx55ND0Y8C3dwlULXf0EvtcKKV2/ pKoQFYobW5pQpfta/EVt2F7ZxpSCAO31SVNyHdOUlKcYwhLnGQanBrZ6KmiCPuJg8ne0O/yhC6UR T9JtiVK+c0dXDq4I5Y57/HuCc2WgV1+WPZoieE3KI+zAv5VhicNZUi/wWXJtSM3xWFY/GB7S6a/r h2T6y5Q1JNfRkPkkO3ydynMpilDqo46XAfkVWbIxCNHz5Cy/nPA81HlO5CAZ4eOHDfHE5QbRLvS0 Lr6Bvti8PDh2DXEaH9HgF7AFnVlAmwmLftvJuUqWLK1pL8nA7siM9FwfhWVjLAFCN9kelGlCNXSd YVhR48THSD12cNoA+jNtmhUuHPOQxJqUGUdDmmFBHIawAZNdbg5wDdLjG+QcKKkwY4oYG8gmVTHn KHTtmLQSOtYkAPxhGZM5zLAqd9nZWlXcxKhJeoRae97Y/VSklhZkXqUjS6//iyMPJl96Xz/qJq+j lR+e77OEMHJb9Oci1QAW6ReMJJ0uNQgiMvJFAgbayFysv2e5Oo50Ai8buCzan8xHTrjRIQ5cKLjl Yc8I7ECBguTPRZ8hEfkoWYAGKd7TYhqPWSMlaffhsWLrDYgErheEPNAlVwEG1PJbrG5YcZI45Am5 u/OuPHze+v7D9zgDohW9xhgksw60JO0j9+hEsadtpGwDBc+tzjhRZETlPXKhklgFGL2D8369SI+D FevgE9ZHY4LCyZEoWhh/goyeCrNVDP1F/U/GpQ/cpvh673fA9WMilXHe3KDE/sFi7wZ6ZB6uQvNw FZuH6+C8u8+SkwxypeMDzn7Am3hMy/oGPEXuSanPNwW+kfS5IMbGCqFzJh3tBQgvVeyyvsCciC7V 5S0xImkhHOxEx5CAlr2i+/Q3EFFp41j31C6ldcqcWA+lDH9TZXyEDEvi2zeIyxjnG/fGEgo0XDaY V8o7v/XXZffD7mf4MeO0WLPExWhs0QqLN+7D31zmm2VBuA/Nqbrr/s26S+XThRF5oHRUq8CSSPva WN9c5hv6qC7md266e7Hu+eF3Kv7mCh52d5d0e4dXdzwv3Vlw2d2x5IZENzRbL31DPLv0uceudMqc eFLvhgaX3T1Rbol0TbXznS/mFUSMq0WC+oA8nzBC0cYc1El5SBZ89vuHtP/6LYLL//1yZxmDLB8L ctjGVnvjVNu+yUhq9BjmWGoaFiS8/cpmwnFlvL5Zjd/cyp0Lb118rer5M78/FX6jbpTk/E5HbNyT ghH1ioyq2fmd7/iNZaHFK37fpsnbVLp948n2Nhlfp+snU/qG8nWpV0l+fVPwZplvXFueyyFoxdCs qYeu7fmc5D+dIKgyNWoQkPxFmgAcIKzLiwdBeSoItin94Qka3VJt+8bJeEvWazqfn6L8fd6/qQ0a BFfF47a2XFef8xMV6nMMfCoxsIjPvBCMojHQgsZAjB4Dy3UMPPvuZdr/7XGdEUW+2xll0/PHun/+ ErMi5Nv/l8//xNkR4fArtr7A/3/YxMhhBRMspxUWp8DBiZNR6Zybij9jDqoyjymUuVAoZhgqZ0xL KkHmOiAVbejs85+MhgmRmB0fKD25EEd6BOcpwarBxaEoZ2J8Cvz77qW6qG9ddGAJ7BzPYoA69ND3 ry5/ff/m36+ev728fffm4dX7d2/O+3dv1HXnx50KfDz/vPvqBHB6h4E1ItZPf9g9+7ZA5un1rh7L MvRsPNboMxaYNMqxI6mdHnY/fvHdv149vt//+eU+ffnT/vRi980Jt++q5ZKOkTxqDTvkysOxLw2V Gr+jcKgcSCcDuth9BZsz4QjMomGdQZFy1vH0mJBWdHYVBxLaZAuf9xEnGscR7RvUX7Ch6VUqGGCt 3LtC9uKdF6gz7gqXYxyKoVtmVLR9AseTgFr1OiMlKVblLjtbq4qbGDVJj1Brzxu7g5D1tRSE6chG C9SRRS/5Y478L/tV0yu3bUX3+hVaOosRRJEixa1TI4BRNIs3u8CLQnDhFJoUjZP27/fcL5Kixmiy fg+G5/HcGV6S9577dVP9TCk7Kkc5QFeUqDdFuDCyBgjnbI1qEulq+k3AyWRShXFagxtFA0YZl3CU /N3ZdT4qPBq4rokvUJZI5egJFeLAlRQnXFbW6OZmUsiIPw5ZQ6PDubzbwqO8mB6PwrbQVzdEMJKP /F4Ba6DfM1pBzchWSlJGOyxmqFhMRCd4pEox3snCe2v7b/uxBEQK4kY3w6DwIyIm/R8/GlF01UZK GyjnOBGkRCU/0g+FxKJA6T0b76sjLQ4qTimIJ22pTBBYOOL4FsqfmbsCgfJpbEK2W5RL3/Am23o0 H/DvDYiKvXEgh/5NI7GDFpi3U2TeTqF5O8fmxZ3eb6DQ1vRpnrS5ranHnkaRZnzxKH+ZaqjW44qt Hpuk1uMqkXpsOq3a2qm1HvuIhJdzU49xNopIrdk+SYEpOgu27qRKbESyPN5IfJ42bvZEYhaxQaxi awZ7m1mnsCSSJzQLISEJB6r2sGcGL30+SY9GSk0g8h9Lq4bn0laDdifUjqetaRB9QliErWn2TFL6 Qdt0EVwaxN4tj+HquN6xZ9dXMtQe8UqgnmBnClYyNKRUMpQ96uqis+BCyo4ex3AlUEewjoL7xR6l T3dIrdYkovOEEnpkUqv7bE1i7Ael/mUPptfml1MAisQoqJLgysTiw4x2N9tAU1kuE0/7eJuBegO1 EjNhZ+Luqvsb718776mcNcNRoDEE1FyVe9Eb79OF9/gZZsWO9+e02qfeVmLJuUveXXp/WgKaUIhr PBWFKpkhcUVit6Vz5yU1GDdLqxaF9j1vReEtOCJvlODwk9soONBVbsJPv1pwbM+Coy0Bjyf06inY SpSkPYk7mu/PQuFaJ7paIsHRFpu+FnXVan9S0d5i47XHxgq/1MKRgxSOJUpsOGexkc+xUcZP1mvx 4PjH33+N4/cvGEOhV/+/fP83GksRHv/F1o/4/08dRmkQ2iJPQrhLoKFzpKkLboePg63pvVJGGPLI KRQRjKt6RJpo4JGRigOrVrTbaMlTJ9nLG76JNVWJITmCZjXGcoPDIF9O1diA+WV4KYa5mWVujWne 34c4BWIM/QjL6OCs4KfkQKKcEc7reH8MP737y68//+fzr+N3n8b7x+HDnXa6aRnvf32qAAGO1BCh gsIMPhMd/3r8/edfiop/V6dt25TB0oTn+40uNlPMoo7jbw40pmYklTx+3dVLs06ueD6m29kGWdhi QdW3gZcBzLOq2QjCI5lTATS7gkBPp995XBkb0uSWzUAGR9nbArF59Y7jDx51DV4nx+5eF2qLcXIi L9IIYAj9iY6xjOV2h0G5uaiRJ+kRAvbm4TNz9B9cF8yQASHjo2NLIj//EUve7ACmUjksU9Kfp1lM ywjcmpMiXJvejQRha5SWSBfUb8IU+ZYK8TrYXjRgDvIzXYiUK9jZj0v58mhwmh0/tyyXaUFZUYhz V9K/bV7XOHoFuwdG/HHIWpgiuy1E6vPJFKh2cBxSD8I4wKOywxAroS0CV5wZ2WqIeUp+HRaLVCzW okPAd7UjH28m3i8OaJ3zxNPpHDIpiJ/dTA/kEEydo3P1c64hVPzMEI827iHvFk7y2oJJkJL5MChM p/0aAqpZ40Oc7GONl4rznMXJtqQeYTOIYxPnw2WzNY7eFuFbWlR4KEIupA9ScPJzbgxhloA3clKX z8nJXgOiTlxOWNPFjaI1xh5aLBu2NETRXDNUY/q9dYr4129h0gK+4LGoR1gFii+V4I2bQ8qNReIT Zh0u8mHa6BoFR85xVKRE0hZsk2jBVp2lYOuptWAHB23JNQU7OHRvue4Jywy3hqKzYmtgqqTMXJL5 W0EEoXMd3MQeZa4zWFrIs71KG7FQCFEipCpPjXKgLgKMMclRJNQhrpxYbNdVUnepftjPr5n7PCQ2 qF8cSm8RHEVQW0PdchGULdYqdrZ/DBfv9N7r/Fs9bhw4hgtLehZ1PKser7Y1j5vE/Gk6Kzbm9Rw4 hgtLehZ1PNsv9jAfoMug0UlaRUw43JxBqTboPlur6OZ+juqfRiZeJx4MmjATiXGtlehAg47YJVfm HeOyzEPt421C6g3UStSEvYm7m+5vBH81BKfaNNdZiKhHFAyLkCz6QnDXE5x+t+iYZwTvEmWXShuB pdo+E59S9bNs3hI+hmT5XUPEJBESXyR2Uzp2dluDaZZh65yf8pbiX1EEgFmLRQB+sgTuANIsPPRr iYDlWQS0Cf3xhEgd11qBkbEn65nO+xPKX7N+VxhI0BWOvq6cK8/+pDq9xcCriQG4fqsxQC0PZ+og MeBciQF/jgEbFUWxPcfzrMiDEA+XkYcPHBJoBBxp0IFm+C7YGmNNZBIKpMkrygwhmKYy/Fg00MBG xUNUK9p1sFvoVTeKNW/4RtoXU2JIjqDxiLHc4DDIl1M1Nt99GV7Kg2/24lvz5Pf3IYIJWbZgGZ2O OcT7DM+mdbw/hp/e/fD756+/jT++jO67T+P94/DhDi+YbgrZ2SVECmbYwLactjXhJfibA012Gb/J 49ddrTzTsLclnXbnrBBvWRLPiGswYJZWSOMlpQuYimhWYJ7ynBR6h2usI/KJTwby5Nh6CrFdzmen uAbTYGqQZtY1jcsKtxQQQC8eIAWbHxTK3UWLPEpPELA3T5+bEbeYEonJIy+SKd3q/4gtb3YAk6E9 7GgOAzNgH73RFOnJ8FnUNTJ7pLjXbwKYwjlZYETULqNowFDhIh2mi5096KPho8E0ddAdynKZluAM 4syVdFM/JWscmzn7EOKPQ9bCEdlt5K7PJhOg0CwLZQMEYPBOdxhiJbRF4DptW2RrIVrBih6LNSoW S9EhqFqFqjg+F6/2hm+d8m0PW7CkIP51Mz1wym6Gkj/p4DaO2jA6R5Eg5fBhkPmtRhbmz7ao/k1N xApOKYh/bakUEVjI4xBvhVhO+leG8mk0QwZbsrLsuZPF4mwFdcVoLpLNhkTh3jhYssRNg7THNZe2 QXxro/jWhfHVwesMz8XEJWXGRdEYZNQ5rrsiAZsz1UJfJCGDe1T5ULxiSg1GXLClTEJ9zxy5u4Ak z1kkPKSwZEkscX47SZAmE3dgGdUkau1FYqGbgHaorMQ7wnJXw/uAmMc5VXJAghKLdtMkK8y1knmh 06FSVEzJi1WYgFo1crWVilaCFogSu0rMjNz45aXB1DuRV3tDW1MQcBrNgdSwxUCd2bqGybsiOEyw rmgiV2kEZc9VUjepdpjUcwOEBpFa55XJVQRHEVCz4hdzlc/PJGWTNn69+R+FKtVBRgQxdsVq7J47 x3BlV8++Mz+rz6tpzecmMZeazoqNsR0LjuFKk55GZ6LtF2sUHzged6TtQwdP98Ib121jE8++tH2h H336OHoMnQGPk8BnDU7prCMipY+p/Vtxd4nNc/y+kfV1kBUoKlfBp9BQdUartBaqrj1V+3fBeyBP Cq59qUosK7YStO+R/yx0zzkoRy3xCm6fLpL69uqUqwF7A5+vur+x+5WwG73RGiwVL2BcYC6GuDHV lmT8Thd642fexxO9+4LeF/1WYm1B3zacG4unzUcj8S5YOzJvJwnu4IrALkviuK0NdlwU9stz3hL8 qwkBKJotBPzktsDN6qp8ytlC4NKM9Pn88YRFPdNaiXGxo+qZy/szvl9zflcXJALOlaMrLOfKsz+p Tm8R8GoiYF5qEchBIiBvwsJUm5x4DgHHe5y8eFn0NSv9mr54DN5PfotYHlRpAlrqeSR3hm2kcLA1 AiHSBRUuYXLMc8MRfXkaVcOCiRcWUtWKdhyoy2O4LXiPN3wj7YspMSRH7INiucFhkC+namb+tw9f hpfy4Ju9+NY8+f19AMfXLFuwjG5l0/hAf8O0wRv3x/DTux9+//z1t/HHl/GX7z6N94/DhzvazJij W8YZd1432Altp1/W8SvchkYT7vGgBnS7gCjFDT0Ca/z1f8RX2Y4dxw1911fcR9tAd2phbY+BDAMO bEDBKM6zMJmRFGgBFBtC/j6HZFV19XKXkRIFgn2LPd1cD0+RD88eZUYtpWS1O2FBMUCMfOVjKPXD XFKrizndPcc3qdjT51oo0RqkUPU4iQWughnOnIS/ViVwDSET8mCDPOAj2oDRFU6+gEPRJRLw84+f Hk43xYrCZFh/arD8med17lsHC5ARWukLo+Uaga98QpejwqAzBMPsUm4sLX8YrKcL0YpW0h7U4wQL 0Wqw7XhTYUGyMJnB9VEj/QXM8Or+zcNNwRI6EDzuMy5VV2pR8X+LebBG2wmFQDtJXg3eL8H9674G Bc+NMH4toVvJgF8VIRQqIuGSQwDGWZZcYl5mGShj2ST+q/WZJYtGrZLR1/goDjN5N5lmE+RFo1C1 ITUTkBxeuX9WHbByQaprfKbYsa0SB1aPYKHqgsrNPVFRfe/6W2RqfYmaPWuS+q3vFmXjeqyGqpJq qJroWVoe15faJ6KrHrQwgFQ30Y0HYdYW9UZuVTPjaa1H/v94FZ0EXAJJvtjZQn5iJ0aHUcIK4ihL 6hOn9SrxyHfeF8Uq8QX1bYgnCkFqtPTUaGt7rWgH3YngLsXKX8XEWfoy2mELWuF+3Edq1NjLzwcx B4e5JQkFUQ5PpyCenUosawoqZziIXw7J/09IyK84yBr39RzESgYO8l9PQaaUgYJsyf9XCmL7y0vs 2xdRUAg7+UspyByClIdryzPttjNvAijPpd6vaOiW+Ue/M/jiG9NQwFidrL3EQ0NH+QzwNd5RD8/n Qn2dXJbFVhBTz9jxXBMxekNM1GTogFzk75XYtjK4R2QznJp6sfS+v2pWakhWt/raRmwAGaLlOZie FiygE3zrDj52K352OezFGhkaIrmViDWv5cW0hJnBy0MUCeNR+hp+Twu/pw6hQ+QAeqHkSubn5smR jrGUyRqEzYqc5jNFm7mBU0mEWLC1Eba6JZ9gQiJ1Us6SdM6NygiYZd38qsy0FmL7AB8zS7gsYS1H yXd/VcWmCb/cXdWO6da9vGOB2PetYir2AjKFZhpe3z1oHzyeySqhDw2jrrjZ1aTOJ/wbMnp4t0N/ tFGoB9dFSKiMZNglDoUiJ4phLDhAjj/3O9CCsQWTeQ4A90YMLZsJF0np4t1ZEPrgwbsFSCMgIxNa ZYPCgtGlm2dfUuWru1X/+YD+wqLCaqzrfPj+GboBjMWeMEKD+Gtkhkdef9joiELmlAC+RcOkKqYe HA6230u90X44GyQZZNZ6kDp7F0tO7mKQ7JzmcxdlSWgLUWOsXwWJ61f9GoKUu30TJBmMVYkThYT5 sA4T8U1NyxAmhZvCJJQmGzy9rZYG3IMvTN6FybMnMK3FRN0O4rwaJvAQwZ5SS1Muh6kT2Y1hBsub bQE5sXuoUswXwpzUP1Bt3pcz2AxS4zjTnJ3bOLkUdFpCTftQA4841kuoIdIqWzEskV6qZ9fF/Qgj GCnwduXdQjnhBfwGvvtwjyUfx0vbcd/Um6wJmFEFwBMPq3tR6Z29GI4H1yr8SbiZyODe8Pl2f0qf IlxCr8jgyEdrhax5ChIxswKLl+/1VRc4zxZXh4hy6eH2zaPoc3+dH4Q5y3bT7e4egFJNI36p40rE npNy0NzQXsS6kvQ+X44yRFdRZ2gWHFviERqCwah7/0wnaGgUEIvjvFVlWgS2JS9KJrxe6VXiuFWF pkS1t3yp4Xb/sUfaA/dHNcTgwzXM5GsNnYnse7EYDeROJ6xqmxqKyneLwHe6bQ9wF+4fwNtY6rqR 8lYE1IoQ/6Qf7mSHwDXV/dR3AcDMEbucc/AccYzFCuw84wZAIJkY6OQcqAJiFA7fLJoeniIJ7V1J Rk5FNpNirOQyGa7XkgztGTO0D7vHgQm4aSULGtxsnIo+D68ndPdaxC+ywDlINJMbVFlEQcWtH8Qg nxsZNflB5rL0N3KZwULrB5Gy+tMeZD8o5VzlVQT1AS4Tl2MH4yAyKquosGSBbMUlBLCzwJOBCdEU pgJUA1Suh1xK3x8fNyOAx7UBLTGCB2t5QorEQI/SuSnTeoYvvuMMUoqLdGCAZwHETzEI692gH5eV lU2H1QdwYZeO1BNvRV79b1PdFf+jtI0N6n+gRTrccyKqn9VA8DcZSMIsWjyr3BPPqOfuyFzFoT2a HuGk2syMCK3jKHOBWSLX6j4xZS2YkHLlBpg6wTUstcO9YJDcALr+oNk04/EojDUjaJcHnelzCrIW RszZeZWpcxEuhLKVdUg047ETVhtIPN5mJ9QZe9JbSS4aXyLz093oOuEtQBq7FYKvrpOW15FusSNP Y08QxGemSwzQUautYhFKOeoCBJDERqzDMJAXlqlp+HKqSqemVU12USN+sx0hDyycjQIf8AWQunKI dm9pG4NXqI6JWgWxzs3UVQMAumA2o2MIh256DoOWcGp6qgK5YZrtTeDT7tW7igyoxU6JyygUHXBx jOh7H0iHUqCfL0XZKl/8fPr11YdXrx8+Datlz0TEPRrZJtg+x2uQAcM6uZpllgGPOGmLKpa5DIA5 HMBdxmzKCOYh3+RUU7+sqRNrsVbhwwZ86gZgXZZcn9xZ8IgFF1V/vAE9bL0qR2hlTqkLUzN1ISCP Kw+7WJQMJsyEbh+S+t21NRmmW+NP4sb5jggZ7Q8bEZx4JaReBTlMPT4znK8UyPlWoOTPFMjVAul5 cL8fNYZDmFICsANgypMvOF1genf/5uEff7w7g1KsEIHH0IhxVEBjT/yvR00YTZSA9YRhyXhxqJ0w TmGawTLnucDgU+xX7W8YbLA7rCXT3zL964mAR7qYQEoBc3lijnE81lLZZzCJIVHmlV0YBzuZfZVl or7fZDZmkQenfo1/2ny5Ubyxu2Ct5ZnjzbxeAV9lvMEZ5bKI9SY8j9WCj4WDGBv5ClpZG3W9BNO4 4LwS63I+n25ZWnp+4TTohevknAJTtMaqyimHbjsrBnurt5wG5aZ63PsbL8ODsxMK5jZxscSQD/hi yXY7twAWO+5Kj2FKBYrJo3OQCGmx356/+FvvrjNfYf1MCfAgjwyEXL/89eOHt79/HFvzCrs76LEl HIDfgyYd3QSlzuW3QsnlppfZu5fjttIIlZfEVM7ekzv0vrvcWPxCYQaY5TwHU26NBCmyymb1+NS2 GGj8QixLJdr5yTALYLmCvl3h7McX0xWYFc8jftrCrN4Bbz+8ProEMPRmsBPBV29cG8xBsOufYVrh JaHGJ0c/l0D1VminhImJB3PMdtZjQWvPUd8c7eVmZvLIzlgdJGPfCscs4zqIAKP+vOtyMzT5MBdT 9g+6rB9sxKbuuHF4EZDGcRiGy7WJQaZb6nMVz+xlmeowhPp8ba4jY3gMwijNJkPG7LlPBC59in0v SMZ2G2sHzm0FRlYoMRCvtZBO6GVRzmvBIt0w2fGOED2Pn5rFZA4mu422JvOiENvQxdN7uVAqrKeo LCPIpHIlLM6h1xzW49TjNMP5v1gpPY9hHId0ZiGBD4Z7NswOUUqX//nx8S2uk39Prz6/+vQwMgUS CSext3w+1AUO9WQyPMeAw8GIutOPD78/3F+/ncjmuRCvoxy5DwF+7UK3BX6mC7fTYXFENSYuVUwn mTpQW1wozuqOd9P4gpEgAgMT68GYq9ML/+oQsJtefOGtjakxzTbFZWCTMJTa63Gqzii1tfMFnEhI rmUrFhMvZqudm6/djpxr7k7L8mqOi8xdl6BGSN42wLz4eUTJn35yiP3lIwZ1qymUQwhhjid4Ord7 6LTDFhSilTCaBDZvcfUg3S9/gUp7pBIXKDq/wB+PVQVJKkE1//T2ewT83es/vnfxu084++8e+Hhy 84jCU0I3RpnICwicuIJ/f/YBHricJY1/wX//ZPfg8idOyr1mBluUyVplOXlUGMG1Fno5RmY4gv9w Xi09biNH+K/wKAIzNPvd3CCHxRgGfDAwwdo+BVjQksajWI/JSGPHyeaUP56vqpoUxdcIexHFZnVV V/VXVV8NNoDJIc1BbdtNj91NA/lA417EfNDKr+flwTCsjh35elY+4mK99+Es/zwvD4fLwHmf5Jez 8qAUypRoEFf6i9QBVjrqN3PiNM1pp008y5/m5QHGskIiXRdOi4lOGR39le5ahS7tutGcPw6AHAJ4 4Fn+ZVYe3K9EMO2Vt2V1BfJ1oX/eXdBFVAvV0X+YlQehsZXznet6mJV3NMEa3ZE/zsvDXxXK6trw e1U4W1bmSrSh7SD+lbXXxicYcFzg4Sy/mpcnTlzGeO39RvR+pEzH3+28fCwUisPV6YJyVxJ7Osvv 5+UD5MtuNfk6J4/ejXKqjLoSD5i9Cl2FbrrP4tkpqibRXlvdHLol6L/u5ONuVp4YjFXhWjw4g4HJ O9e53x+z8hY9PUbrr8wvZwMGhlDFa+Pj6H4v9H9r5f+WmlJqZW/eWemtqbNyX6WpKzPGgsrLdlug i5YLPWhsb965wXZDk+DF9otWT53eNK2+xBw0cQpwDPDgrpq3Oajt4j5XKDeL29+WecDzMQd38Lgg esF4mmtQ9gWG1OwDzgzKhtiyxEpEkkDWc4VOQ6yLD5MYzKArGYymYIFRjvN+nysHRWDcqO/K4yj4 B+6hDeqZ0YvsmEccDItL+nzKbyN9jjiRtki5W/ze5AqCP0h8TULZE8mDtJhKxL7TDyvJkhHaVuds FLqytzByn6MCICT4u8yxU4R4F4WE7WLv/ispG9xGFPcVGgrzLoXMGiMtjAviRgb9UIfY3MuBTv8C 26cndhj+E+vyyHp84K/yvjuyi3fnFRZe5XQ+nOyUscAyt4Fc6H4n9VuS2aTY4eNXrGVfSNnP3EHv Qx4vrNWy4d+k42Ib3c2JFjpGMvrZ8faVeAGsFLkuR4hqCpjR1SgbbOOkQWPAlxvG+xF6YZGvOtIJ zq8BB1dMVtPriU+24V8AHRdO/tNbluKbBI8v+MEXo3iPle81i8qGI6tGaMVhvhIs/DhmYqRzJNq6 b1/JLj2PRznHiVH5M7eIyYGCnb29vx3m0SsxQbPSxvmURAJZ4HQSskWuxjDbVhDjW9SqUdgia3Xw RVDU8WRAgGYqEjl4CIMFdBApa+n1dIM7pwLxQ94JCPS6q7+tcyOlg6Aqy49pM0GIPj2ICMGIas32 AC2R61ES/JoRwuqjnCA9Xvggu5wkn2TraXMApgvBrByPRYFIPShfmIakjo767h1SG9ND6pR/z9lO wW58HHfjlBw41bKwzZr0IakX+bj7Is8UoSaOWdqbQpF9loPfsdX7/BbUePFJYpt8yvjqH2RboyZp 2XFostVBduzqjVjrhSXbtLqgane41LVGQRkGDSDyLYjsK6jFhOl9NC2dxyF8ChtVY0QJWM2pz2RA NDnrqVO1zmKdigk9f5XlpWw6vdQUKCTrlqoY/txkm6SfvJK9PYPr9P3sbIoEJSlvSNrTt10jtKfT HS8OsG4O3/pCqp/Zg82lbrAAIzGOw6qonJFoahXMfCMxJE5lFDMqhHwlUf0Cm2EBfNJJDFkDETPA aFlwPwAjMDgujJlzqaK1F964o86LN1Gzfk4fgUd6f+BfoPGWdN4lG/fy+on8C9R8SQjVztLqnt9g xJPa9Uo0iPqf8vJW9kNNxOM2af1NVpftmbmiOdKyac78VRRs0qGP6QQTvbl0qilzqppvzhrRjT6Y lO9b7m7cV6X7dhpfLUHkpnIbJEkZtYzZRVafMgFHEqQ90mpPmx30uoU0yPfYxr0+ExnuomznBqGE NNVSWc06DTrbUY3rMgEuFr1TyKmX3NX2eRyGCHNDQybdlQRGK1yBdZVtgAcG7ySrHKGAn9T0aHkv r8TXqrPUKgkz/YMfQUQUL/beKVS0DFdouZatu8beXU567+UjfCajAAbvaVWmvQc5art3KWLgg/hN MslceqM0Eiu8UySXsv2xd0CuJ5u0EbWHRKkR0nOz3TZSE/wxlK9V0TKAZFsnUX/EZdbEGIU1Wko1 4SCpdHthYS2pPHFdXGy+C1vGypbJtkCyJp8Wyw6+Wl7Z5X2i/nQYkkDLBaDd3dnJhHTD37aJppAw 66A2t8ieO7iv5ZT8sqcfSYLJelnqVC8n46YqX5jSlL4ZLrlWNNWlKSHLRwHjNr2nSlmn15W8Muvj hUO3nrVSomP90CmarYHmz7opYsu08BMI7hevMxcspGS9eeen5yoVLVwMMbn4uavKF5Vncf5jjCsA NBXROpL05hKROgQyPjCDVoqRhS0lRv7X/6CVGYxOn3uYNrqsqoq09Iw7OOovjaseF3N61LrHnekL 6zdXWw3oKj2remDVjZrFHtMz+78bvjbX83po15amqPR0qAnGnu+2vw941Up2elvqVGf/6Pk7vhc8 MaCmd61ewkGEM4vqrJEcEcQwjpyup5eYYEwnGjlOP3BWxX7g/js1CGoXCeiloFyPo9yCuMfg1SUC qR5F5CZNWph59uf57JTKEka8NHF0x8XsKFNipDIEuQfukp/vSMn9J5LPHs4TJYvsOLMH1du5TqZq SsC5VKWa5OBApoIqzHm2vYPReTBR3lLq+KrQE1hSTScP3EgmQ2lMJGjwERJCCNJBhjYpjIkALtZ9 h1Vo/S3nfQ2oF+xh19AfryWNCZEeU34OExTk/9LCFMxKH9R8XACsoJEMXXUZDT9qcSSs1HlIEFvx L1p8TEA5nNGSdaFG3Y16pkobXxooedCmBNC0bRSI6DjEQJglKuYzDWSfm4NEMfPMn6bIhQ2pl/gw w+0M6gZKtKt8k+Sp03+jk6zzSnjDE5NN6Zb8vV6dV77wwrbDeZlZ8MYhnxViehQvGqad7WohJYln P7VG1+BWSWvGlLnlK/OpOQ9VhwvSpaG0vPT+9bR0IHeAE/iqtaPdtH8Fk+hzIK6eD5CQ9wuPukPm 05ZNY6ouQRgvNlQzgGBfNkX+1SI3yURey3cFcw5FqGdvhosEXyDbrHs1eFrFV1K35JJGlpuKRkkj 8NpumQmvhMH2w1m1Dk76ZkHztSWXOhYokAgWhlelMXeoavE7/lZI9Q8I6OL9wJAeoQiYaqlCdkPw NIiBb4IQ5iFkvVC0ThSo94FhSkIVlFobIvIF3Xqk0fREZJw+cKbTn/QkGo4HpSAOx9nZ7prEpG1m yNQJxzFJ+aUMtJtzAzyD8i+S3r9etmMeVcbg6v8cXImguLGTzODVak5RhAcUqxLxfwy7cLoua7Sf vy4dCxpPyL7t9GEK8FImCr/YbtOf9WoEuu4K7PoAwq97hgS8ILEMXzwBYLrZ3z+87zf8kaJXOia2 l4H4Z3+jTnEo3XzhA750LwzZDpMF+q3FbOTLdPvoLDxoTnc5afBAn9czXQ5XrlVRqapM5iQnCNuc D22pSM3vT/cVg9BXWtmqb/AKuhclxIoHpim+F5LflZ0PsYmRCwOdIsG8YKSh1n9kvlcEyXDD6cWv NL3KmNtZvGm2yTArMy5af71N79tMdqT1z/ktid9xFeFiaUo8gTZPnzf7pHgih6dbNgITraIQdZya yV2HakY5MB/QNp7ziIUPporVhe1HZCxmke9MksD66imUgmf41LetmYapMjgs23HpvKfNjoo1hheq fdvNUhgRVceEVKZQ/2q4Gn9/oZ8TEyT+Khx/Q9V9IfRqQ3/3qcjiWuyCuVv2JLRNqCXJsY1VV5BX HiRXWM1ObHyk/9KBO4bk8P2oVImdl4aDMhWLCrUytEX6kFuFUCtxX/jfY+OkJT5qCF1HEstqeTzQ 2oF+tlve/wMx+oUry/lQ/x8AVIxMcA1lbmRzdHJlYW0NZW5kb2JqDTEwNyAwIG9iag08PCAvRm9u dEZpbGUzIDkxIDAgUiAvQ2hhclNldCAoL3NwYWNlKSAvQ2FwSGVpZ2h0IDAgL0FzY2VudCAwIC9G bGFncyA0IC9JdGFsaWNBbmdsZSAwIC9EZXNjZW50IDAgL0ZvbnROYW1lIC9CTkxJRUkrQXJpYWwt Qm9sZE1UIC9Gb250QkJveA1bIC02MjggLTM3NiAyMDAwIDEwMTANXSAvVHlwZSAvRm9udERlc2Ny aXB0b3IgL1N0ZW1WIDANPj4NZW5kb2JqDTEwOCAwIG9iag08PCAvUGFnZUxheW91dCAvU2luZ2xl UGFnZSAvVmlld2VyUHJlZmVyZW5jZXMNPDwgL0NlbnRlcldpbmRvdyB0cnVlIC9EaXNwbGF5RG9j VGl0bGUgdHJ1ZQ0+PiAvUGFnZXMgMzcgMCBSIC9PcGVuQWN0aW9uDTw8IC9EDVsgMTI3IDAgUiAv Rml0SCAxMDAwMA1dIC9TIC9Hb1RvDT4+IC9UeXBlIC9DYXRhbG9nDT4+DWVuZG9iag0xMDkgMCBv YmoNPDwgL0ZpbHRlciAvRmxhdGVEZWNvZGUgL0xlbmd0aCAxNTMzDT4+DXN0cmVhbQpIiYxXS4/b NhC++1fMkQTWiihSEtVemgRNg77bOO2h6UEry7a6srT1yjbcX995ULLX2RrFAhaHnMfH4ccZrolM BovvZ6/eWTCwWM1MAjH+4SfzkYMsM1GRwGI7+0PBh2rT9y302hSRUSs9T6JCwVudodTreYzS9nE/ 1DvtcQbVm7qr6js9N7QEb/S8wG+tLa42fzXdWhzBd+yhPsH35X0vxuWg/4TFt7OvF7M3ixm6juPY w6Ka4cjQ6DiLCfcZrjUmip8DZl+JOkFPWJPIK/gRQyUMIVHDUTuSEHoS46JoP8CirjZd3/brk0D3 AboPds37slvDx6451GLyxL/NcAL4HLWbUDtCbSLjngPPi8ghboc+nOBum3/QY6Y2zVeUoUxViCOL HAfKGEWmBJtT9/uyjMK4Xu7HYdWNCnB/ug9+bujSMlAi1PFyD1dJTgoXFdkzsE3bEtpcbU6M0ioO lgfQlkHnDDpXEtFeALFnIHYCbRVsy1PZm8Jnwdt6WzbtpNdvz5k2Ag4w3SYvUkAeJHnsc6i2YQcV /RyR40ngOB6HFyse2Ri3ZLNpS2fff0/eSTHNkVlplNnUevIeA01kmJd5XiDtHOzq2e+z7gzJRaZI rKMBMiEVq8gWHo6EDXm6Q1gmwLLEXLbkEcMyeZT4a1i/3IQ1Ui/hC/Pqnbu+2caZyGaQ+jxKw1V5 jQw3KVL8g55n+Floh5T+9fXbBVzRobqoFVd5zDiFaZ5GeXYNmYwRkzdyHVyaFuE6mII59rKvzEXO xy5k4DedOKodGo8ar6uhsjHsy1ZGeGv4W2qb0ELTy6ADXahHLivBpmfhELwtRa1+kkUoebWTIqYT LBcr0VzVOqHaVQ2NTBzCBGxD5K5c65RqWh1m6i6AQUdONUG6SkuSZWNpsC/lInV8mjhIseKmRRx4 SoBVTXtSB/lwlAq3R/BlnYSWgy9xRLnhzJAGDvFGYYVYkOKG5Jo9DOysvHTzyMaeMyi7UlVNuiAC rd2PoTiVCiggZUqtVjx7YTuw6WfVMi+EHsY4ocd/ZgIp7OxIswcmb4HB5Nstn+T0ejmFlUhPdVjf HXhiEp9gt++6yXo9Hr07ewzcGIK8CccbHJdbPc+5t+UkP8pqG5TLYRVG2JFYb3uHBU6UHrhMXmAX jXUIyOkLS3uO1opCG0BeX7DQJXOHF30klbnNqgTbsklNKsmkKHLo1PGgZ5FvADbCDUsl/+5EZcnC UafZ9UoN40DHZ5ficH+pWPE98iqC95c6wWct5MbRHafj0ARxEFD7C0ytTEkpGCcHDt/Ikrjmi+hf YKAf+7Vz7n9eSuOxotvchH4YejWeIz6g1BDEHb2PHL01aHYpn73Gcz2393pq8wl1eBhtj9pSew62 c/pYJtel0QGpl03SuArB1xhig922FT+j6u7pC5mAvnvmY+Iea/XboPVNQH1GyzsbwcJPH2T9DgLu jSigPh7AlIlzlGsGjycQ2+x2DYjxiPMkySXxA3HTjRWsZIEp5/COxSw4fg/J0k6WagjTFesEH5qR LrUckueE8lQtcxKjP48DJ51wcjQqL03xoUzSzyJ91CF5koRPigjpqMPR52XVOZ3OJ60t1j71pQSf dt3LNvAYcFmqOe8k5r3Kzp+n2iBpbybYFWlk09hbSfCKt2hVL5+tJhri7i2lnqdqOnn7LCNWMmKJ 6ySVrYjSMq00a3zRbdibNEhyhKw9K/W82ImK2A8yxzuzkj981MgLwaofeFF+KWHkk/iYkjcJVQd4 NaAN9mDOuZWcW8m5leOxL3A0vGLi213KeaxqSWELSeC5fzLpeNO8VWIaUSZ0T3qQ4Mn2/KEZhMbA GJb0Y2ncNPeafQF3dhD3rDH5G+5wg4GyU0QWW3oHUFZCb4aW1w7c2NvPWrQ8pfF1bf3tbeeY75je 4uGZ4qn+eCoE1CINlT/qZparGAGa839f/NriSj33bAUNoVp39I8cPq4Gxkj0UysqjuQxcWIO0kF4 tiTbh4tZdtit+DlErrbkjlU5QN8BWfSXPjYl54udsJIEx3TAvwIMAIK3Vl0NZW5kc3RyZWFtDWVu ZG9iag0xMTAgMCBvYmoNPDwgL0ZvbnRGaWxlMyA5MyAwIFIgL0NoYXJTZXQgKC9WL2kvZXF1YWwv YnJhY2VsZWZ0L29uZS9jb21tYS90d28vZWxsaXBzaXMvYmFyL2JyYWNlcmlnaHQvQy9QL1UvdW5k ZXJzY29yZS9NL0kvcC9qL3EvZzM1MzMvcGFyZW5sZWZ0L2cxODYyL2cxODY5L2cxODI5L2czNjI3 L2c5NjMvZzE0ODIvc3BhY2UveC9nMTQ4OC9nMTQ4NC95L2cxNDk5L1MvbC9vL3QvZzU0Mi9jL04v QS9HL3BhcmVucmlnaHQvZzE4MjcvZzE4NDgvZzE4MzMvZzE4NTUvRC9kL2Uvdi9nMTg0MC9nMTgz MC9nMTg0Mi9nMTg0Ny9nMTg2MS9nMTg1Ni9nMTg2NC9nMTg1Ny9nNTgxL2dyZWF0ZXIvemVyby9n MzM5OC9nNTYwL2c1OTYvdS9nMTY2Ni9wbHVzL2c1NTkvZzU3Ni9oL2Evcy9iL24vZy9mL2czNDEw L1QvSC9SL0UvTy9ML3cvbGVzcy9nMTg0Ni9nMTgzNC9nMTg0NC9nMTgzMS9nMTg0NS9nMTg0MS9n MTgzOCkgL0NhcEhlaWdodCA2NjcgL0FzY2VudCA2OTggL0ZsYWdzIDQgL0l0YWxpY0FuZ2xlIDAg L0Rlc2NlbnQgLTIxNyAvWEhlaWdodCA0NjYgL0ZvbnROYW1lIC9CTkxJTEgrQ2FtYnJpYU1hdGgg L0ZvbnRCQm94DVsgLTc4IC02NjkgMTIzOCAxMjQwDV0gL1R5cGUgL0ZvbnREZXNjcmlwdG9yIC9T dGVtViAwDT4+DWVuZG9iag0xMTEgMCBvYmoNPDwgL1N1YnR5cGUgL1RydWVUeXBlIC9Gb250RGVz Y3JpcHRvciA5NCAwIFIgL0Jhc2VGb250IC9WSFhZUEUrVGltZXNOZXdSb21hblBTTVQgL0VuY29k aW5nIC9XaW5BbnNpRW5jb2RpbmcgL1dpZHRocw1bIDI1MCAwIDAgMCAwIDAgMCAwIDAgMCAwIDAg MCAwIDAgMCAwIDAgNTAwIDAgMCAwIDAgMCAwIDAgMCAwIDAgMCAwIDAgMCAwIDAgNjY2IDAgNjEw IDAgMCAwIDMzMyAwIDAgMCAwIDAgMCAwIDAgMCA1NTYgNjEwIDAgMCAwIDAgMCAwIDAgMCAwIDAg MCAwIDQ0MyAwIDQ0MyA1MDAgNDQzIDMzMyA1MDAgNTAwIDI3NyAwIDAgMjc3IDc3NyA1MDAgNTAw IDUwMCAwIDMzMyAwIDI3NyA1MDAgMCAwIDAgNTAwDV0gL0ZpcnN0Q2hhciAzMiAvVHlwZSAvRm9u dCAvTGFzdENoYXIgMTIxDT4+DWVuZG9iag0xMTIgMCBvYmoNPDwgL0hlaWdodCA5OSAvQml0c1Bl ckNvbXBvbmVudCA4IC9MZW5ndGggNTg5IC9XaWR0aCA3NiAvQ29sb3JTcGFjZSAzMiAwIFIgL0Zp bHRlciAvRmxhdGVEZWNvZGUNPj4Nc3RyZWFtCkiJ7FddcoMgEN47tWdx+kTP0slD7FnQh0wu0pfI dYoY5WeXhSWJnc64mWCi5PsTkBhz1FH/q4ArdN0kn18oi1MW66qwmAcT6yrk9czCsnfRtavHRl1Y JCmcxXraoBAp58lYWem4x2FUs5qGMdFgcT0tJ8ujybBEtIX5hvMu9733jn/LeFz6SIV7BjxAaFmB IG9cTpuflClZ/VqW9xgojmlzXalwW2ljJxX3Ucb0mC5M3AU1uva6nitihWPJYV0BLAaMAN3g2tG4 b4bBCkDWxBxWDwN0XX8dTDf2ZrjOWMYehxSrXFYSzIbmdnBtP3uEGo8osN567MewtefG5SjDKnPV F9yC39601v6bhinVVXh2aFAAJ3Wyb9CTnkKsgfF4hzYxFlEKlIJLoqvs0ekCq+tbJXC8LiJNy+7r Yk2C+lTzW8GU6sqHtXqc4leY14/QI1foPiZSwg+GWsRnRQOVCEu7Yp0TrPM6yuqwltExd7DTRcM8 eeB9k0XrqsrL6YK3D6/rq9njptSf1rVY4bhfOi0NuC36Zj99DlV5rNyEFjtkGDK8jE9DLCQyW62V bpVw9n4VMuSihC1mt2rZ2CmsXFYvyIZike3v/V5OILAcR0VQL6hWXZS8ItZy3N1nlhR5JFeMBo8R 3i42ZbqoDjGWyVyrI2sXznfdc+xs4GVKLoxH4qCGD8MljiKrGWOFaogNlJQ2npPRGcNM2O0Pk8yj BwxXenRznhwtsuEnVp5M8kwJyBYzKNDtTyGK40ke+byakY866qg/qd8BAFzOtsANZW5kc3RyZWFt DWVuZG9iag0xMTMgMCBvYmoNPDwgL1N1YnR5cGUgL1R5cGUxQyAvRmlsdGVyIC9GbGF0ZURlY29k ZSAvTGVuZ3RoIDQ4MjQNPj4Nc3RyZWFtCmjeNFd5dBvlvZUhkoYmKBAqPWeGM5OW13JKkwJ12rym NA0kJARngSxeE1teZG3Wvu+L5S0Ex5Zt7fu+23JkW7bj2MFOAmSDtGxtINCUltO+B33n8TLyG+Wc N0rL0R+jmXO+mfv9fvfe3/2qCOseIlRVVW186fDBA3v2/fRFMbut+9DxyqMtJWgDtfTkBtr9bdgn T5Lf+z8z8U8b0UcfQ3/0+NiT32duIjxUVUWhPrvv2HGVkLHluS2djK7vVhOq8B+BUkXYBBB+SCQ8 QyBsqyI8V0WoWUd4CSAc3EgACFXrt+APnwdeJB4gHKw6UnV0XRvA3WglEHbgeAibCU8SfkKoITQT PqgarMo99IOHPnr4ew9/sS6w7kPiIIlKGiLFSYukd0gfkilkO/lbQPdI3SOsR5Ye+ep7K+u3r09u eGqDf8MXj5559KNH/4tCo/yQEqPc28jY+NVjpx5zPc54vLBp/abtm0Sbsk9seuKFJzrRp9aItDVi eeA+kewu/S+1xCp/WWaRKNinFCyGrqBc6l0sUkPG79FjtG+efppMKQFrHdSjJG23iNvF6eLQBU1S 4Jfk2HjKnfNn/XF/wA+UV++SKehP71DH3Q63y+1yZVNLs1eXi9OxVCzlT9higD0+Ek+AK4qFjjyc 7zju2w/tP65idSDtLGl97ytfmquLjlw0AkciWccMdC5jkESQiMTOZ4EcHVPYBQu66hp21TZ2MJhC rrBbydVzLcp++Rk5UOLfIVFQ4iy1a3pJ+S703qXgzBxSnA0tvwPOG/LSFCxNcfz08Ywr7PdEAE9k NJEEM+aUOg6rEuIQxwN4OKzRDuhYs4bDQBhcySnja3c11dYZZyYUBAKhuC0HZeNGeRAJym0iDtih 5fEUsJLHNnVB/X1vnOlFzLuI1nBgyAOdy+qFUSQmcnA6QLqOxefDfAFL1waxeLagBJEE1ROmxRpD 9ciRcHOBAVBKz9LQ3/7n7WdKnXvI2B/LncSd6FXst2RMhg5TURn6IRHD242um8E3tqy6Bv3h3cSl IpKf961cA2/KV+gz8Ay9LngIOtmi5dGRPHqCiObvYChpX3ndZwZHwOsJOjY7QpGRBDQ3qePHkDjf 2dEI1mnb+FyYy2dq2iAmzxYS47g0WUvxWQuOK9RUYOK49q1tp6aYp9xHod1HhMdbkIaDoqcxBMQe C9XMnYBPzF8WfgDN5McDWSTrjyV9ecA3NT5drIBqx0G1NwZfgzicHi0P6daIJHLumVujK+68eyqY iAUAVzAyGodySb04jDi1NvEo60/WasuKbIaZBrAR7DY1Ecs6z+H9r0COChydjWCDvl3Ig3kirpYB iSRWlxSROlUBfRzQx3vxXs458/E4TCn9YO1haktD26HO3Z0vdu+S/1r+gnHf6WPAl6ThW7br3ivh z3Ofzf6xeLt4bW4BuFnu2EGmfIR+TJV2GzpPgoeC9TNtcNvMqvwW9P5qoDCDzEwHl94GZ415aRqW pjmhVmfOGfN5wjiBxhIZcEk5y5iEJxiN3oPQoUYVqwvpYipb60H2GM8jhr2SmHJS12pkyyTdAPoI OksNBOO2LJSJG2U4j2Q2IRfsNgrlclguExpZEEtgC8gQedAYz4BJWzQYhGXYZWoslnMWoJmcThhH 4gInqw1s07GFQlgorJBKKB5xSBCpQ+U1hgFDqDccAQuOXCwGU9D1OWp3bk6zAi3POeNTyFQiUfBf BPwXx3//V/Cu6YZiDlbM83OdESDCoDtOQa/WyVrpCL1F/vpL4Mv+owU6TC8syi9DE5kxTxJJeUNB bxzoOdPXD3b1Mc0suIdlFOjleoVarTAAerm0VwhxRWNeBaLw6uKWczss1dZjgdYJfOdj6KdUvoit 64Da2c6EEBHGdZNF8IKzkEjD6UTWPQXl01q8zzGeo6PS506RAKZc+Zr2CcojohdJn2H4hUDCimt0 4lMkLH6fjlO8dIbqLjrnxudtnZ7G0OEPsaZqbIBEuYJ+TZvLnx1NI6nRqD3gCri9QWcCcCasqSxY MEw88AF2gO7IeiIBdwzwxEYTqYoPKJOwMikKcZyAi9NqPQFhwft00t/WNlDRp0hLEwOWABKweAw2 FWBTjcgloLhXblDDerXKKOkB+lS8gTYIe5a0Yx26k1TM9feEkUiPT+dQAE6lVSICpX1ysxo2qQx6 nVlrVllk/cCgQXa6G8L24Z5FLo2jZGp3V4u2DqK320I4iYKCrLoIqObMy2+D89Y51yzsKkZzk1Eg NjnneAtamDJI8B1KwwxP/VfBauV19oWmCWCy6Yh3L1R7VMevQ+r57W2CYwD/uO7V3eB+R23kNThy ZLJlgQt0L7yr+Rj64F1/YQm5UJi47P9ka7haf0R8iskDcCzoXdosXr8Mkh2N28PusDsQ9Mf8cXfW MQ04pkfOXwSvmleUi7ByUVBgpPgRlqd9HLDy6UPHIeyN70r2DGml0GeKIjl9UhhuById9td3gyd6 T+kZsIGh4smkGo3MIDIDZmFX/0kI24b3rbRGu1OuRQdKyJ0yggpLO++UnffpZMpZ9GUa+gn65zvY n1FJqfpOWVF5is+k12hr9K2V/yUP7Q727dqGBzeoHN1JK90jox3le8TPSSij9Hdi+e9/WaNjT5Cx 3eU+VYOB0SPa3BM25jTz2G9KZ6uxH+KoKehv/4zuosaOFVqWuQBn+YrmJvTOJVdiGbmYnJ5JrAKJ Vde134O3dFcFq7BgpWO2Lg2k6o64D0A//hX7lVqk9hXuz7D14CHnkdgxGKWWfkqdO78augEtTBsk eSQvSXB8rQA+fRpeB5+V7j3VCDeeek28F3r59cj5U8jJRenNL8B74Y8X5nDao7tpaBE9SP7H+4Fp XLTTvqUr4IQlrU3CuoQyJPFI3HwbcwQYFjPfbIaw0HclryXNJAf7XUjE4te5ZIBLPirige16rkgK S8WtxsMQdqhCNfQlGnoLfYgc9p4eHEdc/c5el9lpdmu8Uo80xInT/4b9pBr9Hgl7DK0X50VpYWSz 3q60i+03xy6EMlkgk3PPXACnTBOKDKxI43JxAA5O00gthL3/AMjjVFROWp4yynAByOxCNijtlekV sF6p0krwdos5/a0Q1oq3+/N/UCNdWf6sElDOXjRfgy7MjfnOIQVfOhrIAMGsbSIP5k1ZRRJWJHjh Np/AUefe5dnlafaoPIDSYw5EwYQjEg3AgVjBdgl6q2CQxpGE1M0ebvmLtXpw2piXZWSZ7kg7PtY7 To7VQc2tPZpOpEPNkyi6ATnXxOkCOaN8jxD2iCLSrCqmm9Ne117TzBh8lqQhoHNoAIfaqpCBMotc r4J1SoVWYASMAm4fE+rosjq5CMcl8WpDmpAp2T/x857qM80OegQf5mfRe7S1DajxTvnqDtR4fwO5 Iu8ZdIX6vPYwPnC7eU2al6EO9qhbgAjcipAhARiTvcV3wdLzW8s/J+8eO+Jthb2tKc60FJDOvGW4 Ab33liM2g0xHEznPNOCeHr10Cyz9fCsZF8xGGprBHfEZEnai7NF2GjqNnZuNE4Yp7TR2uOSp/ncS msSdklLaSfsryei3BPqDwEBgcOk2iD5CnjodG3DBvWGzX+/WuxUOwThgEzCHW6GWzl4DG2HrRWqV VCXT83q6vjBUj026on7cGP1J6zQ0mzUpgohHNypmDrzRYwDZhnrTnh52v6hP1S+1yM1KvVKvVRvk gFHRKxGDdBczJYQFqVndKpTNjNiSSNKe8mXiQ+Jh+ZgSkKBKamcf36SEDSKlQqgFtCKehQ2xRKMu NaJym31h0HXWOWqHRx32MZfVNRIdmRi+OrZgSztwt3r6GrUhtyB+G3p7OXx+FpldCL53F8z35YwZ 2JTWxZVhVUjiFeAc5fNGuNDRZunJLgQdq7lP/5RcKG2lZuIZTx7KZzRcfPZwHY37wQO6RgEH5gg4 agbU3BUqChB1rKf4Dviu83w8A1O2oPe/osqlfCMborPcKXySpfWL74PvORfjKTgdm3AXoUTErA4g fpVLNMr63FFtWpIWmHEgwTzlPAa1tpnkDKRLzueq2gBlm7npOLg9eGDmJHxqZlV6C1pZ8GSmkHw2 Mjd2+Rf26t5WLVcqx3OYAne6GsxG1gYVHjG+GYnA2g3RGUYpC2HLRFx1G6BuM5+sB+vGT/raYV9H lJvD2ZPLGwvQ1YXohQxygIz1lLZR07G0uxKp1Jw4EuM46/eCtfpmYTfcLeRoOiEGx53BSZnRLV4H bzoWo2k8Sz30J6paKjRzoVamK8lH+CnNzMAqUPo30vgbo8PgF7LrrfPwfOux8D5oz+uS5hakpVm2 fzu4I/hq8SR8cvaK9CPoynlXAt9TIlZwLj9nr9Z3qYRSNYC9hn6G55pKwitOqNlxxCuzcc+2Atg0 aajomojHgIrD76GV6r+5+eMFcmo4YLfBNpt3JAa5vYMDXsTxMXGEJxwSQwyeRSdHZDqd0iwDetUD IhZ4/Df7PynXkynfYi9QBflF3TvQ0uy4L4dM+KNRdxbwZEdXb4Ol4ztryYsdjZFDUEuHUYpTXiqq dEXVZm5pBPf4Dk/Vww3n3hLdglYXQsUp5Oggo08NW3haGQ5fI+vuacc/PeqWI2q7yT8Q/aW9+vQx b1teCFwqfYAXOoMXeiqr4SaQONfZXIvz6kGhBWxNJQM9YE5Kv3gD59V8LIVHtZ/R0AlyYTg9HoLH Qh48sgCOUNgahXIxk8KH+BRj3FYQu30XvU2+0DtliMGGqDwgcAEuAWeUAR1skDS3I6itpjIAy1T0 Z6Uy9Zuap8l3y2VqyV1TdpNx4uJfaCe/fRl9EfM+CFN89A9oE35YwEgkrBNjEktbv1u+tUK3f81S fFWQPD88MRaBxyMuXwBnXyBkDUOZkEnpRFwKK78TxL68i14kX7TnwxE4HE7ZJ6CAp8/sQlwmm2FY C4xohsQsEPvjXbREvqybFcThhKDTWQ8dOME73I6YEuqg2A24JVx8IyxejxavjEam0IiB379QAf7P ytxwFmMhOBxL2yehsL/P6EG8JrvWqgasqiEhE8Ru3kV/Rz43mBhww30Rc1Dv1XsVLpENsIn4I93Q nuOCowzkgwfv++Yy9WTxsvR30FzBFsCJGUgk/FOAPz++dAP8VHq1Bedzy+uhPVDtCWVnC1J3Srh3 K1gTfKV4Cr6B/jc1k5hwz0KzExpOAklwXE214H5tIx83DD5T3YqLxJ3BRZLR4gq67lpMZCqNxZqp 6AjZpfRpQ3rAEI72JqBzeVtoEpkIxjK+acA3Mz6/DC6ai+ppWF0Q4UcMIMTutLVAHL5Fj58W9XKF UgTc/PX9djK6sfQtNZfIeCbxvKzhxCoibjoAvqxrqHiWkP1PEacfuNL56+AN54VEDhexEoew1v7C y+SLzIZYLdTOMMpxustF3RW6t5tw4/hl6JXZJrhpdln8DhSPjjjw4e3wuR0+ABslY5oSSs3gzpGH pjJqFk5olrN+H/jqA+fgCrkaBtTJ8eDOwced40bFCivOgcXQbTQ0TJ4czo6n4RG/ze2yAzaXd8QH BQK9hiCSuk30dfPG+JBc2WtQI2qjUqxgAn940KMtX6eogtwF3U2oMGF1ppGMEz+yRwFPdCyWBJOW iM4P6/wKl8QmHqc7D3noNtGoeUg7Yhy1jAGW8f5xG+gdc3scsMOTsJ6DstEeLS4hrU1+VvgF7qpZ U0zn1/qlbp4NsHczRzogoWjAIkUkFpVZZ1LptRqTAp9dfXIpKB6ROOSwQ+FTRwwRw6zummbekDQ5 egCPcUyjAGUmpVIDqxW8HlzU3WM+GSLz6mJ9ue266vHjwfYJwQMXE3xI1ZvePGtBLMN9wwOjwIB1 0B0B0dW7N2vQA+SaOiL2/Vf3X8OWyHVn2VY1bNXYdV4TYPJE+tKQLzg0HEEMHxMHNfrTZgjvJQ0X NJYkt/RxzBLYJNWopDpALxVbRJBQZnWoELXD4O0NAQPuwdQciJ6rwT4gM94UDqnhEdGYzK52qPza qBEwxOK9KTxaJC6fQ3ZV3KFIQxtLbuLzJAzA3tcxjByLEM8Sxpwhgz2MXq3eRkIbym5iJT+O0L4t PeWv+Qy7SvwLCd2BL/oF6Xlsmf+06OvfoBfxN/wKW1UfMLNO927moev+A10iPkdCn6ss3oISaSiC NkUY97DtxHskfAgE0b3oEHEL6RcYxaDWK7XyzWaXwacN/grdWI0RSOhebAg7igUra9djXdR42Orw IwGnN+BK2APuqeAq2lCKVNeQsIexFR3D0GnCE1BBf06XxwjocgV1Y9nbbx60DPZtNrDMsl6zxWAy G3oBi1EzoIB06qFhJTK+k2gJ+Po9EGVLSUL7COsls7sGBzqQi2+jOfRT4qXyr/eiXeR45sybkwh2 u7yRuOeBSxLWqqinhfi5TtOj1RtVlgCrOukI+p1RYNw3nJ4Bb2/7EZnyxhuk0vL3S/9D/X8BBgAY gbbFCg1lbmRzdHJlYW0NZW5kb2JqDTExNCAwIG9iag08PCAvRmlsdGVyIC9GbGF0ZURlY29kZSAv TGVuZ3RoIDEzMTE2DT4+DXN0cmVhbQpIiYxXWY/bRhJ+n1/RjyRg0exuno/OOA6862ANWMkGSPLA kagDljiCjpm1f/1WfVVNUhrJkxlA7KPurvPtL1+sWR7urEnp3xqblGmdliZN8rLOMjPb3qVmeffT lD7T/V2apC4z0xktLEFNn+/efnCENl3cWbqrhApWeWZKaxPrzHR792f0HOdFtFrHtohmsa+jlYld JsvHOKuibsG/uF+e4tJF+zYussgc4yyNVrT2kTnE3hGKHBDi/LRhGFzuD8yAwIkACIL+HnfNmCtd kRhEY4klwHZtXJXRHiIAeb9liIZ/OiCCn4n/NtN/3f08hT2SlLSEKdK6qtkWpG3mzfTTNVsUdZ3k dZUXYo6Hb6LdKp6QbG3sPAvsk5pMQAJ1OF6wvo/8s8d+2zDccY2jzsQlgc8YvNnxyfE0gLZ8PE9i VxCM+TP2NsriKvo7hmEcHYJWxz8NYeTR5hsb8DtEmYs8dJzY6MikxnLu+LcdeC2Y+lhMiCTkJ7C8 y4KK5wYMvpTZAva7YraqStKyDF70uGDXMHhQcYeW32j/xI8mSzPyqYMYkJYbxoB3zfGqcKt17yyd eRAKhEoPTj6zGjxg/xVOooCiHPNnjba8Ejc8KgsXTQiGDDcIIm54rr1o7ov6luZlkeR5XlSi+W4T TypmnBMjWi1EJPbxeEK/Wz40OMCV+SNmfUikzjzxAZQVWEh6Ai1QNaI37i5hQbED9REUKCT0uk7i 7P4zcfsIvn9F999Y51lPvuWfA3veZ5Epp1ca22JCOttcfSHNrb1lkiJPUp+x17BJPsJBESy+pu+B hEoKki1NID0OTzFR50QjsGQ7ijLWUL7stgQdSPwVKxyCsYyacDGPKwIzn5xEhY9mjVKYMWTBAQLA VjG3F4wO8aQcPq1IpTtD+WdiswRvaRnarF9TCl/l/YpS/EKsy74XUfkGvBOUExWJRgYJVeMX75SF pOfYNa+/U+6T3Dr1XObiEk6sdULusiMx6D7sn/DbknpO0qGv6K41jWLNcfNEOLRpOiLmS17p9RLX LcwG/2dqC+G0URhy9AS5CaQDRi1nZHbCmwV6s14CslFB3+RK1Erdy7TuOVHeQXOfsQ2gd5lcYH4i pPwSqfAJfge8F1UmdTX/qdnTurzBv4T9x6TuH7sZZb6K/JVdhpzgQHp7fmQq9NFjZ67lpNwXP6zs RZFQCBZkL69p+WMnhXclKZAzxCHWErxrOPx3SB77N5IyniVzcxKd4/MkJUIyBqoJYxqgcr3StIPj M9gqEqAdEEYpC6dS83FoRgnzhVOHOpQWr5Rx8n9XF6agfTkUc9KY9Nnil2XgLuJJDjvslrAE8vYK B+SwtZjnRKc5jFZBdyfL71g2DHYMp1zLqP5AxYW5x+IzKuxvwdj7gfoBN48nOiq5a5oErg/fTA9G 8XWiq7wUrkHah0dhurpastyN/KzGyanTcUPJRh3Q14CLTMLzGVSVdagO8JjLsmZQWX6LfUoty4RC 10YPuD6JR8zF8ZpA5CuooLR1c/Gzpudy7JsAQV6ihB/lHo3LROvTSzlutH7O3kiCwRhVmZRDFT8w BzRao9ZoRSJL5ySN3bA8wSwWfe0ZILqpZo5r6lCS2LI7saDTcbeWlXp6iAPJDTkcqRtaSHK6NXpF YSPNpwH68ZKSrCE9h7NVWZ6Y1HrgIKe3C7y3nDZ+ZDPqfNxQ5rVYzVAB+zLLvT/XEVrutWZTP+JQ Tj9IzVyf1cyLmrfR7zeplW8C7rPgaoGmZjKUVK6Goajv5LZBrcii/VntJz8bmoHbbcL2ZWeAxuMB nJR/kPZZ24Z2qOm3RpEb/SQlOZ9mJi+oFehLc3C13h8n5BDynntaHalHpGfewCu+98MHQ7PnjFr8 OeMYwZSguYnNfvcmdohSxp+zA5u5dOpIYzx0jGg3jC/TCZxMXM2MYgWpbw1/pYknvTSOzUpN67a+ lda95wLO/uR9sM5ZKGEoox92lBQVrO7HobPw5S0WEFNAGrPFQsc9XHPwihKYnzhOPbyEp7nqbJjT kZB7F8K5p5/PMbI+W65ZxJWQWHcD9BH2Mkcx6UUoppUTb7E2d69WPDFNZpPa2kpj8oGSZAK1KXpQ nChqWKdJRZ+lfNqYOzVKXdxHrRS0xQ4vtuTYyBI2GagZpSp4R6X5zJEQ8OS3U1rml1N7CHDmP1/I oxiTEj8M8fuvv745O6oDpyD3o2yf5DNooWJMbMmEX2Yyr2Nrzqvr0SZWo7Ll61SNpsME+cM7DmfP xZs/H3WkoKJTcVeG332A1WTiJbtEgQYShI+Qrig3H4QUJ8ky6jGwC5nSwxmFNL2m15znufuVbOij 8G1hrzx6fyboRAX9EpiB3OpcorkCnfQbSMI7+WAJ/a4MFnUoqUXdO6X9sVdSa1sVZZ33laKgNoH6 DMog0sjXoVI4Xkq/zz0QtcFWh4g64LVoL+YB5hEwXdj+MQbqT+8BtO956fn6qKTNlyATefpIqDNW J/1uFKkV4EA1Me/HvHcK3ULNToHmEGQdtstBC+/HAl9p6Jx7ve0Vc6f07FmR2zDYXfRzo9Zqwb4q /RO6qmbUf00quemQxxGqAB9171tcvUOmq6KPb2KeGt7rdvIlPmvtwRyvrH1ctzSH2yAyiUhvGNpu /rlsWlh3d7OawiBZTYnCkVnEIDvhbnTKOEHJcMjBUl/YjDj+ToL2PS55YsmPtBgaz5E5Apjjcjnq I8O0s+3NO/TcUGsj0FkYltAjhxksD/rrqEX8FchfzX1WS0ftyx92GlmVJT71hRfbfG0R/jZqd2v4 qNVUZpEQSGlJFBb5DzJgN5fLh7PDTRNwZ610fVRA/9uid8h7qJ1yDN/AAC1fzVUZWdMirupor2Br BWv11ohACxFED48KFJACz3DeLoOWPRkhIMQC2rVwzLJ/mP2y0iVlZW31Ihz7mer1OJDp5sxxZbAa X/djEgDMth+5vkrgj52YnEawxP0D6dH1eZAV6U0/Ei0Lmzgao7SIznvddgigvc43OrjNB1+n8sZZ A34+MsvIGkbjBFmL9UDNe4ARLsZEagSBvcTSjIfasXG1Fw3sMEWpuAly2HQc/76+FmAaX69EV1Yn pS84P7FV2v+RNSaUQNA2MGeZVaK2O7IfUsbg+JNhQzycVKkRgiWXLfj27FGPkKfEp0FLzqihLbnd nUjOcD60xXwAx+fQon7iK06Ei6CiKVACzGQRo3byIfcW5BjUnE0ASqWZ3IxvTiJNwT3FVUuFgbLy 5asFTKxGEelsVmm/EGaz3Y7U8TbJojCTzfoBD9sjJslwKbNgmMR0fEuoWmFyDOfShFKnM5oGY3RC /bgoTJTACTw2OsuGwU8v5fn4YntDCPA+BtJNwG+pf2z0MJypGNJ9Z0hsXIHLkYqB7ro3gHz5fRMe E1+8RSFvUadV8eqwJW/hqKXxuffjtyikoc36rShEc5RBK1qwu1SQgM1RSCtaRLNVgJvrxUm/m3Wn V0s9kRReSEuWRT0mvwZPsrI96XcjUGids14capkDWZ7/RjeP2G1VfNkdddeGZr4I9C4bDlfm/9CT 2RmsrzT+d+IeuYqR41FzsB/ORCjkrZQ+nR7zzJCTbAIsiEFQPn/CyVqR98roqPsTbhvdbcw2LGec MKnnHBi1YvlcCnAe6S5QaoN8ptXFYiRR4D+jRVYweCB73OgVkeV4ooYgt0zmZW1l2779kBmqq4s7 qi0wLA+3xlMnVxZizCq5wPxESPklUkFl3p3hvchQ9JzMFsvS32Be4mHHdN7d//v/nFddd9s2Ev0r fNpDnmNrCYAEiX1Lm6Rpmro+cbbJrrsPtCRLjm3Kx7acur+iP3nnzgwoipQ/Yj9YBDAzGAAzd+5w albpwW+fP7x5/dOvdJHomd4cfOJ2gkB0tBeVSGXzRahlKytbhYluxh84KzGzyspen8h0oGZ3SUHA dNjbCerVfjFhjogXRNnHKuIIo3MeEYpwJXG+p4C5G8bSmgHNgnwRKaNqzaOVjqKpW9XHi9PPLDm5 T+KcuISVGqYPqH7SuNExSVFK1J0Hq5ZWSti80BW0XhZWp2L8TOejxXaqH/PkrUqu1u0MVT3vubbZ IFmdAnzqUdbmubauRe2N5q+ziJvx3VfEioM3+tRoHwOfNKh/KLY5U13uF5J1mwEoiY9dU/XEzE+Z MUwhedhQgaeEDHxBhgkmy0/AfsAwvZEJisBcvipP/RQbb6JxfrhbdUDcmasDfO9CvZnf8mbRV91M Xb5QT96JJ1FoIUJL+RlHrrdye3mwFrc3vjRPsFdZt4lZG0Mj0O902VJclYgO1PEKcba4R8Gg4N2I 3cWPTujqUr/iSgtktLgIym4K8do7WvH4PETIlmw6fjWqRVbovCSD+MAEMxvYXYq9M91GzUc9tCsp RZz6Hp24ViP8zpIq/d02PsqmB3rMlczj3dn33ehHkZkXYXdolvTeoYwNmyXMepURdeR/uflv5lPq NYTG9o0/AKiU36VGefgeQO3pjQHVMcg9jKI95Y9zIplyrYxw1ygYFeAAHZkphnnMNKYS8w8iJ+qM RuGx+d/oiv/51uzS9PAqD35LfweCG80DV5tHENxTV+md27YmWGfw/Nx1UvTgjJShdwJgTOINWtOZ /jYc2pv5PS46pPpKMr4zddBTkBaX7QlM7EWpjZbgzuueFgRuOskfGPQ6wX+r4DX3Iosov2rPBYp5 pRYHRSOKCOzMuKbs8Ht8waG74PoJmIZHG5iW2w1aC0J6Jx4ErXUBbNHiUCdS2EIaBS4ZAwHTKoES O1g3ehvUOX3huwhaowhYkyjYop/g9/qR+4rARTk+eEj/Bew1Aj2b1bh9/F236GIhP42Gb/VM8Wyi CHdrsGzUuyj6Tb2LY36XjbPJ9EoPuR5XSBvwp/dvbLUb6HOqwhugp9slVgSijn5lOZ+tucI4rSwV B4CT+kKXd4qK6KQmOXGOmJJq62yrNnV4oYaiwRkbbETlVifnMpQ1eiKKMhcn233x6ETsyc2AA1nD QpQxsCoOLuV3xYbUkdvhiVhkQV3FloMDl3Ye9VJMqWHJr2pMVkz3CAIy7gGws4FIelEXtTzGIbV+ 2Im6iikdnlsi6nIzI76n7QIbUxEElSD/qDO6xf8lSbBo4lh7hnUqfT7qZUaOJVIs00KmYXURWmVG J+njgo1PeaP2dKDKX7ApToo7GCe/4wAwhxJrrW663rY6qjhlvK36ifJpazspKlNpRzbPTJ3+SQ8j X1N8rfGFfBNuhPaQJtqEJVr8u8MRZA2NllEJ/LtkPRW1cmeeHhte/5GiKv/+5s0f2SOJxxXOcR+i NXhnfaHiMgkWBWZwpL0uogSIrEQf8QS6Q2q8uvWrRlNS41+zgfVSYz3lDFaNCNFGDxRiZSwej7Dr xj2Vc1cYde/YjguynvPxqjyws4OgdoU5PKswDwxS++ZQt4QGUiAnH7JScZMU0/ked7JSwbQYyBhZ csTdrVFiR5O/aGVnnrixeqO7LLkRQi04X1/qWqM7qcpeNHX4fNtlNF0bHKEzcaAacYu7r6qzutWP 5Kg7+EIjZ9mdeJRveR0Tzj1Ro21ZTUqTu1Jr9JLDD9WqZpLPrPiM6yunTNkbJv/JmJGT146GX0W4 VQtn50BbcGluOZOj9dXVSgxcI3Qj+0ZzGBXRMi5EJjlS4dNt4eQjezaXPQnRtWPhN9ec+JT13bzM tINh0UQWVfEGRKJOz2UrHXW42jtzEvdfynhOJSx2Pa4nNg77Luqfgr6C0p8CX9nSu2y/MOk9gPVq jliUHiZlJlpJoKYrmVPeM44D3wGA5vDOMmVyQzFAJHjgAkEhbuJvsl6m1PbmaRhjA2LskXQ2FM+1 s/XQ9l4Gj22ODUwuI1RrDiYmI3yz/CTyIAH/Kka/fRRuQ3o15ibCWF8Ef3RHgT6ILE2q4HN17th9 PwhWSLqBnTGBqzraYJ/AwMoWI3s/Euev0qUQuMi3hC+BRXG9oMrxGYlXSd3YTOOOsUotKIzIZDSh Mk3L2ec7G9G0LC+ynA3tM3lLIBoImKkubSxtiV7o5Fo9+5DhQJ3swFKjujOhh5Djc7azRrzZ0YwU XTPiuEA/gnXxrS3qsbVKjz/QdXhuPUqqvtIIFIQg6HcLosuUegV9JO8YqwvOSFJAj+JzGgvjL5jY 0r1Jk1OAqti+/izuIFey0WM4x0LyVlWZiBbKggvtOgptEArtHwrJfZg+F0pwKmor9iOuEV+jm/Td bmr7VofruEn0Kvk1zkyXaLLgT8sW4/bDmLYusiLUkMcQLt4/njyUeDmuOPdZxQyMWTzDdE5ndjXN FXgQopcvRrZA7ZqQie1Nt5EtjOlel6b1Y9hGIWJrJj/b5ve0BDJuWTo24tpKBlrBOSmbtpaC56WQ QIdpHgkZmTV0+fSfEY9+GTClqLpd5eY7MM+EalKVVVCfj4sXYt7AztglF4kfU8CnQW9g8JBDk+kV 0x7id7YgtLi6akDehWdZK+yJxyspCHvgEyT/cZL8fJ8RU2KyuKWxF21+mRAu7qOoLEU52moXncxr 2XeiZg+isW/zDLYphSw4HIEzNk86CzOiHKZWRgrepweYkQB2nHO0mM7AZTS8w+mC3x7pvgMLXcTC qnwOEJoaFbkwsbbsM3daMgWVolJMnCKJ02h1AmxO+j5tTmoRw4/gjEv/iuJRLi6sWrWf/ENXEmFO USGuNxeqwYArhMf0DMVxsjqVrZMmiXNa+aLrd1yLep4aVpyuWlDyCl7FzaL1Gas0DN67DjGq7Mb0 Eu9Bjmcq2q2s4p2fzNtpxm++vMz4jZtrRGEAIfUc87txb5LbJ6GP8J2xabCnQl/yN3VJROqIXdWP dLuMgdWj/M4TxHI4be+z6XMFA2vpUxkD3cPdrTXK4V0u6xNVeBnSmdrSrVMZq0yo1bPj8gVIF+zQ zI4E7Lh+7Z8Autr4ob1DxiSvFIRe6IeMS7IkhpcM88hPXga8gKkJPfB636wWOiLjgVpGSQXlgu+s LVZ3Es0+ne5F2V+YWvRceNupSWpFGtB50+16tPFeJt6pLWaQHmnNJmcZk5duy0+Z73v7TrwdnDl6 caZnjc50u78StZ4Z2RxkqNiIDQPd1v04z80TqCnBVHKpD5W82seMG8+JFqnkICtywWwM1wsQXhqe NESBUQPm15kJUpxE4ees8H0Dh6IBeskljZnxLe7BgCBVrGswmTTtTITp/LxrZ+SzEmr5UVunsvOZ 2JrL2oWMZuJdZ+DL1jEI7lyebrZDSqtLFI5GrIWeI7qjyiQrsa4ODJ/BmOIZ2Bmvv6DrNwG8jNEM jQHIdM4xboXc5kJtC4TWxdlfGVPhRn5uz1aZq0BrJxlz4OQhMNgJq9RzTiq3w5Oj38Bej/B84JUh tbilPHcvJZclnSIQex1uNCSX7uXk0jO5LJhcupQAPJLL3g4vBF5bU9kwaJUI6tTzY//9wFsHajAG dp6Vx4+AbzB+ZJOAB5zsG24RnehXCV3NWkJGntfcucwKjIBW+L3PSqTSXMO81bBv5udoeIu+Hucv 3+t7nWtFiQr+xtKaB8n7ziKPF+qL7jqf32gOr9u49F4VxrWpKDpyWDwBc/J0hqt5rST8PSErsmq1 ovbTocCAA4GHfsgqLQuVNqn4NfTrFJExJpyvtBhgeKPmzplkluk+WE/RLfMrbKQB/06MG+1pnfa0 pSxX2tNiuNbetsm4VlzoNF86ulsHJjdd8s5FZ6TV8ZwrGbaZym5RMJ5sttYJMhx2GFhkqEzJqTi1 4lE8AIE9IaD/P+dV09w2jkTv+RU8klWxTHwQIHNLJVvjTSozrkk2u4e5KLJsOZFllT7sin/F/OTp 190gRdKy17kIAtBoNMDGe6/zU13zB9OUH3+u0v1/iNiYihCJKsPa0D+REXNoOohcC8BFCNZp/wYQ NcU8RRtzaE+cK7LSNOUjcSRFY5rn9CZFOQnBVmYYUCc4SbCQ4rRl3ozSs1VOzVOQSJfmYh3icAtA IrRjyRkpv41IjAZSEyVFfjXnBqlnJRsIKejwNbIPhobXyW854U9jnoE/0oXmiUfUEIrGJgaFv/iL 8Nd3M6ZPRr7n8K7vZLGTMncHxG/ytfD8myIArU5Pr2eCW0uZngjJ6+C2AOhM9qBR8vBD2sm8qLmo 5d5eHJ7KLgsZXM9E66ifU3ASMs/6HmQZjt5kJ5RQdU0VDDanzIjZ7Kb/FU5CnNTNIwzkCL0iypIs UgBlbU36BvXLvoFDyUgwGIeOxnkBfj76GRzp1SaUduRnAZSyAC+6mjrfraX/hu7Y8g05Gk3t/f09 fQrC/JqxEK3az5SyZ9IdWl2IOEjDUx1O1ntpf0hDu3nstmEghBMepodj6gOfUxmGlXxU7i607Esh 38rOa40vLV5p/4aYDbNs9O2IUc91nU+OvMkjagS5UJeBIDU0BMneVykXml/IhRBIaAwcjV5kmciW ge0onnFSxHFg/y4qz4zC9d9uXoBJltk7kAfwnOlts5bp1C2MaFyXNG7oXFARaG1nOxOrvUzeQESA B+LBnmI/yUah8MqlkOm51HJqg3q1GTrSrRa9raZFbCP+ISGRMKVfynom+P/I9tvCt/5I28fHxTrd t0tE+fTnryN/P73l30CGe5SUVP7MQZLZFL+rCzkdSWVkosPbJJPFLUYv+HfJI/z3iiSbwwUbtd6C XmfKuaz8aGZNcFvpf162GvNtSyn1I2x/cIpIiBoiiJKTmCQlEdkwk48nMVVwoW4I0AaOHpGMsZWM 8ckspiZ6YqGhx08stmJ+zkASc1Y/Ln/HzzuS5AbFRiqUABWRWZy1E+ajVL0NjYuwi8AQypVIWYKH qCIqtu29Is9hC7ciQSMlH3ubbdOAyMuYr5bqIU1c3d4lp6Lcoqq/qMI1ihTtXCQzyEqO8TQFu9Gz Qwi6/Lu6Te5mesTkNm2rsa550bUOzmTPtIXF6+NroMqlZo42XLQ9gmmcWJV7Mq8qAvfSQ3l2eWV+ Ja/6jkbFmjHp2ZqnxN5BWvUdvi0wAy0bUGRxndvkD1AR/LgiF1XQK9m/CnRYqFNNR5fsOat44bWM zmQdwLXs1qvz9X4nVnOad6HzpWZ7gYq/cmjoJpft1JMVk78KmZPPQzLnXsLXYCYoO/kUmOzOZMZH Sh5mvWFdcqpx6qRttyMkPZ4Sx/nSVKStgydfIfheStiXpURTgy/7jsZQU/mmaRLa1NVzaVF7a4dO 30JqVnn2Gz/7ShOjyu/wNlFjXvO7qbggRHt7h1dH7yL/QbYVTF4zdJAT1ID856N62xcl/dKzNOWB 7w0KB17m0GZnGsOfZBfUjprvuqy1+1j0t5mJ3YIgi47X+V8VvWVfB0eUoNYs6iqGSd60tf+zgLPx bYe6rbZqZU5njySC9aRZA4Eb3XmlwP67Qg7XVRCtjJs1I1NJ7f67YtG1TnB9BmzCxWAg+534kiRd MgBVHjhcfdfxdgDlBPtx6GZvZXnrj+ycmHEAU9W5F8n/3VwdtZGcqz7lB/xZO2m7QTjJy09UQ7Yd nqRozvqHucI9oOw5ETdpq3nn3SG6S5m+lbOl0Ru9u4Oj85lmaflYbYakNp3Xz1nVRz6no+cSKBpb oybkr3n2swiOaHc9Bz2HfHMHqAv59fZW/kCoBdy5r9se67rAkpxU2XXBxL2DvAss2FqL3X4DwEuj W5Z4If8KhRdwZdCFm91etpqy0VL86OSDOJKpXW+KAoSzFZgQusFSKKlzJjucS/cdKs+AF8ddPfJ2 J1HdiNetuEOVNJKadLuNbRJKJb3pG8E/9yhUtReO6oZsvV44KUsi7vPCG1ZDBmqG3nYFrt/s/i4L h7/xuNRV1H0cIAPhfuMoFQbbvqaj55ktkfBlFPaYAFGaIzq0MU8kUdWAlF1VHXKDexE3RBPtyNEj 3GBaYjDPEIMl0RqGHt/KGS/4+TDv095G4dIksBYlwdJB7NAFlV5cqyFjSE1/hCVo5ae92v7ofFsR CSwBlD24MOCV26n+uUt/0m6vwSSGge0w2BSEQn6SO4ZZrdbTqC7hNpFaF1Ny0Ub98cAVNUKPKki6 a0khr0ZwY6qOq0vzLOJ4521W1fXEdgTyGaqHIQIN0Z6r+IXX/Jj5aU8EEAin2XQupptLaP+Ahx8Z i6y83tAtn8lLn3MP9WvVmayXuF6CD91Zluyu1d2KCk4MZ9rXzYh3rWPQKWVPXsSd/VR2W4p/sXgQ 59JZXRUe8EfFEOQQcTYfb1k42Voj6R1IYx+9BJd425R1H4GO3nukbxjStb9T3l7yJyee3ipP7nRg 3lGRBdN8UspBqgRw0OJaLZWQ50pt244STTnkKMROUSXcLJ+CzJoKnaoh7dmP/Oy8sGX+7mtxwthv HWI0FPjfKK/ykpIkr4/j5RHI8BRzqE0ZB7v1kLL+NYyU6yeWicEDwTqQ9C8DSRttGDoaXy9qOz6w rZ86MYOkwWMdeHyPmgM8tGG4cEzzUuZidIWaJgKeiFRj/o2GGzUuqU2Lb7Zc7TpUu7Bfqd3r7INO JIeXlzSEojYtnRERR4AWL9iyrhv5mXBQ9KjpCXajO1bRne8lZ6vjd4toWSx0J9vp9F58pwCW1zr+ wJGk4V0aHoQyUgclYLEFRmOr55R1RVVPVlVu4n0ZonyGL4VgFwuQmcDOQrBlJc0tP1mvHAMJxMNX 0vwErQM6YNRAYdadzUZ62XsFQfVAXzqONt3p5PxC1tKdMzSe6vgfovgmTCq+nV4x5rWLxVcKNfsi EDg43krDG57oZ1GxkPvAhNaO7/UYq+kSkgkxiOCzZSkWYTLGz8Oql17tk5+E3kjpS9McPtrqZY/W BcLqgaMxkfqWRcNzb9YCpPr+3oJYfP6pQDq8x2V6pSrP3OOFqjxTlVeq8kJVyYKpyjMP+sSDdLXS ZP+V2TnPfmNypIU7cSCjJOdFK9MjyZlsvXADsoBTA5SmSt2TrjFo9tLMxD8kO7pXuu2jBxt9zJMW 3UGD1ZEvGkwg9KRraEKrPu6A68h+Fj8Np6uhmGzgOjJHXun8A+0ug7tuEInIwk1VFXNFGTA6YeZo Y0UsJttctV/ctWl4wphhFTNGsTf0UDzJWY29clqsLfhWKZz1myIAzU5P73FDLu8ay0jJWIcP60T9 OLp8B0yd8LU7kRzt5OmddKkAkUwBIj6I5VQazQ+wQTqgyeSI9PbrugkZPoVrYja7eeXqOGkqEih0 BMoXE0qX3byqSIA0pj+6HIySo9LQaN9DGl28umy3PUn7nhxsXGbtfTsuHfpXW6HI1WuVO52Mk4uw 7VhKxYpyKkPEzlp/iBHhRRgR/MDJWO+FVPg0z8CDsd7Zgbv3EHus3Jr8DrIt5hfyTCEDY76QMZQL lsCU7Zac30uemEhmfwHF54s5z2fiVDqXeDviZCWNPCT5f6crULhU+V4D0MEd924zWQDnVZVn/6PU Vt8rifSMtwOp5WsxgjSt0nkk9lt+xBruWDOnOwzPKeYYKCmyqvRUqVRRddE5H58FMYeGh+9EL/NB CcTm2WLKkpTuTbU1w0LJEhLLy0i1Fd9o84iQbHnpeMpxZL6mxC1r0xOT8YU510D29h2NlIxLeVc2 /rnEc877ocPPLGL4tEL6ytKsIz4QeqIeWs23gKhughRE5ErN1Fyp0e1GUQlSWXFvJ7OZOllLMTWn 71MxjbGtGukSrSeJXFglbElWwGi7k+l/eK+i7bZxI/orfCTPkVQCIAiwb5tsTpJuduMTZTdp3xRJ ltTYtGtLdtOv2E/u3JkBJZO2FeWcVg8iAQwGw8HMnTtLPTCb3RcVKM2MChbK17KlnhMvt0JX1Nxs I/KqNiOZfJbdiT16pGrQE3ayNmNqdKGnDeO0S/b6eKQGOD00E+8MdRns9Euwolo7tZo6Ne7MaglS sZfHy0wlr7gutz2xrT5llfyqV+n4js4KVP6kGmBg+GPsfmNaXEpLyJqjehFDzoy06VedTFYvkhlJ +qGR3d5Pb+FhTjMx7Hc1ZcoNSU3cyFSH61Y1lN0TegOPFOom/kcyk2+CCnFsXLSHiRlPS0wf7UDR gDAylj2XjdR0hr6WKeUXlbiPReXBCphQBxT/hlsKoBr6LQYtrP5UeEPyL4lHqDzP3BQVpVuiSEQh 6GbHCH4iaB6ETpXcFugaCfxmEOF50TvDZItjF0ySPhRV1APeQMXgLAPiQXvkLLqifDzImipRaBeq I/1WaJz3WeWria+bJu6LpBVCKlHna071sWNcQVxyCiMDlJtys9GyPMV8DeJ6LomepFEtwFkvBQH/ qgD3kTvK/XISn9M8Pb4i9pk+r7hRpcOugWtQcTVfqnAy7babyLp9bFNGYJRmbhJoynCXTrxQaFYD O0NACfiDRFU6YlAgTDjIjWdgSjyOrqFJ/HXZokMNXMEbopJsIrgoz+ripawt2y1ch/ykbA5DO5CV fPvGehijWeYezY8aZHJo0Bl6UuYVnh5Xc+4mPRDFYH5KqO3zV4R7Pv8NlcxTl0OA5vPPspEiAmtt i/6BXqQrpfmPSxByT15tZWXD6OWl7/VcD3yepF8WDY7nOZU/V3nVoxbqqGVJCosBYqWu6Amc8Agf 54ETD/yQGhlkoTQz1N1M4IQhY3kWEiPxVlJO8B29D4eQ2JwGibH2pqfndEQMZXQ9Jf9DQKRLAUr9 X1Fx0sNFJIbtEqP0R2Ax2rIhNxsmE7FOsEgJB/sR4beENRahN6MxIn+igUncnnNFlzeSFysRWjJ3 8IR+FWSo0jsOcF5sWbFu2MpDl3QbsawAQdWWqdBalTN7+LI7L2B3ro8lKFmnIZur1TKrozWfrBZn 6RSeZJ1M5eLeAFWmx6sDVOWFiBCM8rN/EE9uWnni8gcMA1D6XUiql1QSWntvQoLSOzRGDCuwMzKK 5u0l4luwk5FzSDYRCxwe1ffBZnzk9DOUMTqSqlctDKpBnKJDmp5xu/SOO7n33AFNeWbMveBnFnrL 7/RfIYJHJ+NY5eKk9LFp+oah6QKG1SNOqH2Krg6Se6wE1OCvYoPGwCiqu7yLs+4k1HPUN2WuIepl wgPYs+VJsBeMi6GvaHCDxjXqJFs3x3q0Jpqmr/HvO+a8DRxCNbbJv+iYAlZesheFxdXMVGAzYpLe oFaNK3peoTiYPMmvZJh93slLJ/4PtDwGjYEckL2TiQ3TnIahmEhAQyeRsbgcyuYm/4oAmcR8nAy4 nxURcW4tmw3Z7As/Zqo6bU3ftFCT5izF9tpHSKQPiUSS54+gpWuMz1zkyhm0dIKTGeInczSKIV/T 8R58ZbEjolVjasN9SOCqjUAcE0QQnzkHqgSu+syEHLOcuyR9I8tbHTJ9w8QF429g/sYvaUEInO0O Wuo8h3Oy8hs4luuGSXuSTTonzIz7pOtBZj6HGxXx1thYG/rO+rgGg6EsrbVrNAgNpNsU/9+Qn4Rg Nr++uqUAZHgz+e6yILDJ3mOhHSQnoPPJvOQLC2SDqY3aQJQtv74G9VL1bNICJCy/ksNxxm67l6BC NAibugub+sAdj+dhpIivCbP6pozYzdqheu1Q8TQFaL6M/F7sesbBVeerpdwgzZloaBJt7xgRg72i I3ZP6JokHU93uU/WnyriJulOQ2jQc+3RzZyGbs4a01c0QDci9g1+XbTVRyDOwrd9tURijH42WjYE T8m9zRiuWqFMc++DxRt0HDUKKCZHBTeFVM646es0vCzQv6nQv5PUjIgh9C44zaYTnf7AwhswKRJu lyKlByWh6Vym18uFaN2JdReyjWMP7aZam70Fm6ryv+i8flLWyanYnTzT9A3aqEqSbQL6efjpetSA WpeVup9KTOInTyWZD1SPXEXuL01U91+mU6TH5ZZ3LfaCFOG5lNlMRYmC19J8stBWxzfEoOUirekb ytFSdzH8LJOJgeKkagaG/vHq1Z8UKsi1QKlyQodRoXerTDB9lSNKZ6L0JbgE/8WiKmkWAXJdoNIR LVtBhJsCbhEyA+BB80C1yshOh+r4GBeZ03X4EJ9KV19XhDTUrboSEHyQrva0dK3AFXuKBhdgveuQ 8DnKxplqvfd9ja85wVK9cvmV1EKqlGkm+zQB3cTbzyq8ay+4dDktf448O+bSJkDnUFFAFpwUZgcG QnG2P2ax0wkpqPsFLry0f9HbcLdMR6JkBz4Q65e9/a3Ob3U+SwelDYtiX7b3YuCm5aH9TwP1U4lY 156C0RKE1FX94OLdiRcPGO0pGrJQ27FQH49dvIOensbXE3YIkcR3aOGEEzqmgiB/zDEduGT28yR7 vWO/7CcLZEra2Wl6sVaxJP6Nck9JIgRanR5l/ZmF6KWwIVceaPxA7IDHfN4vyca0bYU6Q8sIt2Zv 3vlW5e7TOTfgpeGx/Ild/sRjBDT4miod4qUqo5II4XBR4y8SD2yFCMb8Xztho1EJXxQymHYgji3X Dx5KIMf8WhKQ1u+SzkRLY57WtiqsvDTmFyqQBP+DtNtbtZCz3oL9W/SF5CbSe50MTHqZFccEAnuj 0jHtXF86067ajFu4JLnjk5I5yU4yq4I9Y9E/7w5IegRi+pQXdCTdj7FWwvzxCrO/nxLCNRiM8k1S T+yS/n/F6ZYqODc3b2X0igXSv4OV2fQbOC8ug4mwfIDBh+Hz4BanH08Xihc55UZk52uZTXu2+gTT xfJWzt+RD/x++lZGHCLnuuNKFKlg9ht/hconrfeFRJMKfZXVdDbYi0EizUQVmFLfw7YjfNLeukQ5 nqSkDHU2UsZRkRI/w8NO2ynQeHkYLhYbfDCVgtlWXjba54j7nHx6gNthfDfeqthSZlWrLo4GZMEc awQqMqepIrHVh6YTYWAzKNakPxt1/ZcFCbqerURgKU0mhwSVCOokxoArR5SB1wN/fTkBCNkfLiE2 cIF+UEGqH6ggD/UMCwhgTgpIbb+rgDxU+DdyEq0gcxlb3gFbOPBshUQZMcjQwieO2iT2hiGr4dAc ZS8kOgH3NVZ/KixQ4YvuBXpj/mIzShJIjzTdqtgCkUFZSIXqTON+xofuBZI+NUV0vZHTkskrUbNO hg88VvnkseC/q1bYupo0IaJHhcuIgpCPPOKITvDIa4vneWHp/wrpsp+8xFcGeml11xzmyWZMU6PB 8pcUdPQ/Jp9VePsGbPI5mlUHecoXWx48qQiQ+z36GG5v32cbQLjxuSrcsMJkxlbFdrKYjLrIOvvm Bc5b8y5kdsU2l2KqmlDT/2SIPA9bTVsd6yN8SdkTStrS8+wZgLsWoKRmZs6QUef6QPWrFXWox1lx AhOxZ3hNaDtsw8rSC9t/BgnlmqmGNqU1UYz5XS5qyj54xd8O5PZScXz+uWCvZH/KsIQVPq+5iMB1 PGx3M3kRguwl8j/yF3lhGeiACFR7Yi/5qCvVcq7Tuo8d1I3klshZA6CS5usInAZiYOaR7x+hgcps iQ/L6wmPAKxmAInPo6H4loKaLtvHQzj0p8Ghb6rQV9S/bHO0e6pcaPpa3qBvRGAZlCdOD2pBEF/5 ekfk1enUP7EofvkFW3jyBt9CaQlKaCRb+PapEM7pgvL1PYvyFPoSB8RyUc9DTcrX2RnuEvfaUByT Ply8DA8MYnVLcAD3CAMwZa2XXlonCfk8tsWK8M9arqGhEk9MUfRqAgOHx6wI9H8BzK908AU8heaW IkEwRFFTA4Yg876wSODsj/9yXm27jdtA9Ff0aAOJVyQlXvJWJIstii7aArtt2jfXdmIjsWRsbKfo V/STO1dKkR17kzxEEj03kjNnzvBzxavfMG2IMeMXVERVk1lbdzL/9j1uX/zUsksEUCpvOM09L636 kVFlSfwS3eMdQ8QlB6BRfdvuWF/3x94khAUtzlmiuGEdXnzpdtaXf5owSB22G0zJTBoUg07xX74X 6MrRV1hVlKG/ji2SqJvr/6gBAD8Z43c4QQMJjMO5+ndwf84fcZnpU+ZV4ZBXvc6qQgJW5TtWFfVx SadN7MqxjXdQLD6jEqgylnEfVPzbQMXHOg0NHRkvQx4vwzmAqW0yQ4s/j3HveTq6JuYTkKPYmqgx jk8BCx4fD7I8lWWeOwEU9rpSAJywzFyegFKJXfDdfCJywjbYMgxqnXjT89w57sY3uJXP4lVEhsHs 1KSOAWryPm8PWJxF1a9EJ8Bsu+/tlJSHJyDh5l0dkreQyVs4B3AJb8sk6mre8E3ctTzOMDFCDzj2 EplyQqYCkKmNhKxiooUkyQl3C8LFAhEjGof0aEn1nlWAl+n28VS3IrWUxQVZLG75mUX3rLyiUUSD UN0d/ziVMDKJCxKf2s6excladqHLGrHa1aNBZh2Gp/8q0/s+UOO7iEDUbZ3s++geiXV0zyCOFFt+ LklaVAvibp64myfu5om7eeZuFXM3PyKu5pmreeVqXkgYuPoi9mZLkVixs9n0Ubxfk1UJqVEKKmqy MflqKJj30rQaysMFBwPh4BBf0LQ607Q3kjS+nlBOTIzO9vE0vA1P4c8MDR3BU5/x1J/DU29LN7T4 A95vJXgF18BY5QVG4KxbaTPNhYrg8fwkYoySyNAIoTzDDkhDJXh8aZ9E8kIl/xx4/AKZA1xmzPzm 0pdyw1WOgTC1Z4ERuedco1Hn8CQu9QA5TzxDLEzF4Jqyq/tusum8QgHMZe/FH9nVsJCR43PiwSmf RtGEjKIwNXGDSgjzX8B54ugZe3gcTRcNpDgk5WgzNvC/RZoQiQhPLBYTXCL2e5QAPgV3SuQXV5E8 oGwjOk+y3sh6sRHLcBQB1qHoY+dBFtfIMyLBIarOWGNxNa4smvgFby4Cd+OoRGm5mM6fkNuBxIoN NBS9ojSGsRSd4pZtSDDNeYJwatqUE63SJMQAwwid6J4vveuMW/neaeN9lD5brOVFf5gtV5S2ge7f 5V5KO9EP/mkvSD901jZrWXkpvxVXkEiVOdaPZeboodfRFlAhPlpX2eG2f//4EaMEUgtTTgnbmKRR /TpCvjbD4uRaJeuG5l+CI39t8J0Gqns5IMfjW4FMdeQuCfacIukhPT2JpMkaDMPVE1OXJvWRNL4J SWNZl2Fo6DDxMpCmczgKGJ+G9m6QCRCoJQaoerTbYOZxdiVCL4fkEviFTq+fSIlOEPOnHs0bIlEL 0qCh9YItyknDajMnkQKIsLqD1glVCJhXs87DlN4Rea1QXRAQ4VvyyR6azyzSXMGi+Y7ucgrdXOnq wmBZW++Erf8mSN0SnGqPWAsqt81KusRWV7QLuIoZC8+r94rDegxHIHrT6xakfceY3+r3AejP5EUV i42KtqKrATzKcyUmuoBy4K3KDPqaGp8tcbMxCudhWcgG0290G222GshWHB6Z67SQT+Ij3wlS1Cp5 z3fyIyAwEkYYpeDuuUaBj9KLiUHyVKVKzDSQoyT9G2dSzWS8C1TkwrbV0equA4xwx2OrIKkKUwI4 VtGGfnmnt5W3dc4MDb1S3ieq2pWxroZmllRrXMZbqpENrVwhaTU45cAP/P+Zav6Zquu5Bwb7Nek9 a6lzYUOtE1xiO7BgaYYfLYuyPUxGb0btfDejauYguKY/kBzXMK/88yFv2NC+TAH5E2PyBSaIS6GY rXPy2Ikz/vBaAPtNTCkWAUCuK+LuLP8fAFBpUscNZW5kc3RyZWFtDWVuZG9iag0xMTUgMCBvYmoN PDwgL0ZpbHRlciAvRmxhdGVEZWNvZGUgL0xlbmd0aCA4NDMNPj4Nc3RyZWFtCkiJlJdRbxQ5DMff 51PkcVdiUttxnPgRdEfR6ZDu1NWdAPHA9UpBokWUqyq+/Tm7C2wCsmbUh0l35pfY8d92cnZ+geH6 84QB7A8DxqoqEmaOXCtyuLyZIFxPT3b22N1NZ0/tm7B7O2GKSgdoP1KKHAqUmCnsbqZXm8fb12H3 2/Trbvr0bfYZIhbNgWLRCsfJi9GCFOaiGJXD3dX093Q7nZ1f0KllR3Tu2PMJYtIaHpqB2AxcYZch 9DMEwZhSoXbc21PuR6RE4FR5BYIYBVQ64r1P5CgWlB65dRHiCBVttHwVKvYYXfnPRRJFFar9hn1x EYbIAKlfZfaRHFHVNHCKvHGRTLHWVLRDHlxE2oPSmlVKi6Rgv8qdj5Rou8apQ65cpHK02FPpkOAj NUqug2G/uIhWCyWkFaEkEMvBJCtkSaZksLDU5ZtMZIlPMOzYjYukHJlTwuXip6SRaqZ+lUsXYbEd U1gRF8pgoQTt4/KHi4jVPxkN830RjqawQfx+XErLl4q4AqloO4a1rDCsWiLTOsM0xSKjYdcekqyK o4yGuXFJkKNqpb5aXrhIq8lgay0XTKJkOya1z5d3LpKsMybEurxcJFOyYB4M+9dFuEbKOtTkexfJ YhVmyLAPLmFCZh3tcvWSTMi5pFyX6yWV1pHK4IqvFxOyIA5lzNeLCdma/lCS3a6fFCwpQXrko49Y FU88VD63vTBwxFyqLveF7UPTPvdx+ctFsMSUadgxN5RMaD2ch1D6vpDEAtK74h5H2LLFKtlgl6tj tmxRlDUNidk+VB02zNU+Z7SGhIMq/bDkbMUiUe/LcxeRdhbNg/u+L4UtXQR5eRXjSlFYhx1zqxjb +d4aeOEVetHWKoau52Z+htYpRGh5qcx2Em99srfrs4+oSX/Mlu+R/PPb9cXgs6d0uDOp+bKfZD9I IEG0NdyRPrkuQc3tfjSjJTRUwnbtsSnbG7A5L+3+A9YVdw/TcWpsZ7gmgCAlRzvF7+d+uZ0RLDoz 2n6nsgm/7394v8WyeWRD3IQX91c2KJt/Dh/Z6HaLuglP7H82+bR3e/b4/bP77UzHL79sk1oRmxkP 0HU4WfCAHn7/utabj+H5ttqr1Mt/7xdocyz8L8AAmnL5BA1lbmRzdHJlYW0NZW5kb2JqDTExNiAw IG9iag08PCAvTGVuZ3RoIDQNPj4Nc3RyZWFtCtvk8goNZW5kc3RyZWFtDWVuZG9iag0xMTcgMCBv YmoNPDwgL1N1YnR5cGUgL1RydWVUeXBlIC9Gb250RGVzY3JpcHRvciA4NCAwIFIgL0Jhc2VGb250 IC9OWklFV1grVGltZXNOZXdSb21hblBTTVQgL0VuY29kaW5nDTw8IC9UeXBlIC9FbmNvZGluZyAv RGlmZmVyZW5jZXMNWyAzMiAvc3BhY2UgMzYgL2RvbGxhciA0NSAvaHlwaGVuIC9wZXJpb2QgL3Ns YXNoIC96ZXJvIC9vbmUgL3R3byAvdGhyZWUgL2ZvdXIgL2ZpdmUgL3NpeCAvc2V2ZW4gL2VpZ2h0 IC9uaW5lIDY3IC9DIC9EIC9FIDczIC9JIDc5IC9PIDEwMCAvZCAxMDggL2wgL20gMTExIC9vIDEx NyAvdSAxNjkgL2NvcHlyaWdodA1dDT4+IC9XaWR0aHMNWyAyNTAgMCAwIDAgNTAwIDAgMCAwIDAg MCAwIDAgMCAzMzMgMjUwIDI3NyA1MDAgNTAwIDUwMCA1MDAgNTAwIDUwMCA1MDAgNTAwIDUwMCA1 MDAgMCAwIDAgMCAwIDAgMCAwIDAgNjY2IDcyMiA2MTAgMCAwIDAgMzMzIDAgMCAwIDAgMCA3MjIg MCAwIDAgMCAwIDAgMCAwIDAgMCAwIDAgMCAwIDAgMCAwIDAgMCAwIDUwMCAwIDAgMCAwIDAgMCAw IDI3NyA3NzcgMCA1MDAgMCAwIDAgMCAwIDUwMCAwIDAgMCAwIDAgMCAwIDAgMCAwIDAgMCAwIDAg MCAwIDAgMCAwIDAgMCAwIDAgMCAwIDAgMCAwIDAgMCAwIDAgMCAwIDAgMCAwIDAgMCAwIDAgMCAw IDAgMCAwIDAgMCAwIDAgMCA3NTkNXSAvRmlyc3RDaGFyIDMyIC9UeXBlIC9Gb250IC9MYXN0Q2hh ciAxNjkNPj4NZW5kb2JqDTExOCAwIG9iag08PCAvRmlsdGVyIC9GbGF0ZURlY29kZSAvTiAzIC9M ZW5ndGggMjU5OCAvQWx0ZXJuYXRlIC9EZXZpY2VSR0INPj4Nc3RyZWFtCmjenJZ3VFTXFofPvXd6 oc0w0hl6ky4wgPQuIB0EURhmBhjKAMMMTWyIqEBEEREBRZCggAGjoUisiGIhKKhgD0gQUGIwiqio ZEbWSnx5ee/l5ffHvd/aZ+9z99l7n7UuACRPHy4vBZYCIJkn4Ad6ONNXhUfQsf0ABniAAaYAMFnp qb5B7sFAJC83F3q6yAn8i94MAUj8vmXo6U+ng/9P0qxUvgAAyF/E5mxOOkvE+SJOyhSkiu0zIqbG JIoZRomZL0pQxHJijlvkpZ99FtlRzOxkHlvE4pxT2clsMfeIeHuGkCNixEfEBRlcTqaIb4tYM0mY zBXxW3FsMoeZDgCKJLYLOKx4EZuImMQPDnQR8XIAcKS4LzjmCxZwsgTiQ7mkpGbzuXHxArouS49u am3NoHtyMpM4AoGhP5OVyOSz6S4pyalMXjYAi2f+LBlxbemiIluaWltaGpoZmX5RqP+6+Dcl7u0i vQr43DOI1veH7a/8UuoAYMyKarPrD1vMfgA6tgIgd/8Pm+YhACRFfWu/8cV5aOJ5iRcIUm2MjTMz M424HJaRuKC/6386/A198T0j8Xa/l4fuyollCpMEdHHdWClJKUI+PT2VyeLQDf88xP848K/zWBrI ieXwOTxRRKhoyri8OFG7eWyugJvCo3N5/6mJ/zDsT1qca5Eo9Z8ANcoISN2gAuTnPoCiEAESeVDc 9d/75oMPBeKbF6Y6sTj3nwX9+65wifiRzo37HOcSGExnCfkZi2viawnQgAAkARXIAxWgAXSBITAD VsAWOAI3sAL4gWAQDtYCFogHyYAPMkEu2AwKQBHYBfaCSlAD6kEjaAEnQAc4DS6Ay+A6uAnugAdg BIyD52AGvAHzEARhITJEgeQhVUgLMoDMIAZkD7lBPlAgFA5FQ3EQDxJCudAWqAgqhSqhWqgR+hY6 BV2ArkID0D1oFJqCfoXewwhMgqmwMqwNG8MM2An2hoPhNXAcnAbnwPnwTrgCroOPwe3wBfg6fAce gZ/DswhAiAgNUUMMEQbigvghEUgswkc2IIVIOVKHtCBdSC9yCxlBppF3KAyKgqKjDFG2KE9UCIqF SkNtQBWjKlFHUe2oHtQt1ChqBvUJTUYroQ3QNmgv9Cp0HDoTXYAuRzeg29CX0HfQ4+g3GAyGhtHB WGE8MeGYBMw6TDHmAKYVcx4zgBnDzGKxWHmsAdYO64dlYgXYAux+7DHsOewgdhz7FkfEqeLMcO64 CBwPl4crxzXhzuIGcRO4ebwUXgtvg/fDs/HZ+BJ8Pb4LfwM/jp8nSBN0CHaEYEICYTOhgtBCuER4 SHhFJBLVidbEACKXuIlYQTxOvEIcJb4jyZD0SS6kSJKQtJN0hHSedI/0ikwma5MdyRFkAXknuZF8 kfyY/FaCImEk4SXBltgoUSXRLjEo8UISL6kl6SS5VjJHslzypOQNyWkpvJS2lIsUU2qDVJXUKalh qVlpirSptJ90snSxdJP0VelJGayMtoybDFsmX+awzEWZMQpC0aC4UFiULZR6yiXKOBVD1aF6UROo RdRvqP3UGVkZ2WWyobJZslWyZ2RHaAhNm+ZFS6KV0E7QhmjvlygvcVrCWbJjScuSwSVzcopyjnIc uUK5Vrk7cu/l6fJu8onyu+U75B8poBT0FQIUMhUOKlxSmFakKtoqshQLFU8o3leClfSVApXWKR1W 6lOaVVZR9lBOVd6vfFF5WoWm4qiSoFKmclZlSpWiaq/KVS1TPaf6jC5Ld6In0SvoPfQZNSU1TzWh Wq1av9q8uo56iHqeeqv6Iw2CBkMjVqNMo1tjRlNV01czV7NZ874WXouhFa+1T6tXa05bRztMe5t2 h/akjpyOl06OTrPOQ12yroNumm6d7m09jB5DL1HvgN5NfVjfQj9ev0r/hgFsYGnANThgMLAUvdR6 KW9p3dJhQ5Khk2GGYbPhqBHNyMcoz6jD6IWxpnGE8W7jXuNPJhYmSSb1Jg9MZUxXmOaZdpn+aqZv xjKrMrttTjZ3N99o3mn+cpnBMs6yg8vuWlAsfC22WXRbfLS0suRbtlhOWWlaRVtVWw0zqAx/RjHj ijXa2tl6o/Vp63c2ljYCmxM2v9ga2ibaNtlOLtdZzllev3zMTt2OaVdrN2JPt4+2P2Q/4qDmwHSo c3jiqOHIdmxwnHDSc0pwOub0wtnEme/c5jznYuOy3uW8K+Lq4Vro2u8m4xbiVun22F3dPc692X3G w8Jjncd5T7Snt+duz2EvZS+WV6PXzAqrFetX9HiTvIO8K72f+Oj78H26fGHfFb57fB+u1FrJW9nh B/y8/Pb4PfLX8U/z/z4AE+AfUBXwNNA0MDewN4gSFBXUFPQm2Dm4JPhBiG6IMKQ7VDI0MrQxdC7M Naw0bGSV8ar1q66HK4RzwzsjsBGhEQ0Rs6vdVu9dPR5pEVkQObRGZ03WmqtrFdYmrT0TJRnFjDoZ jY4Oi26K/sD0Y9YxZ2O8YqpjZlgurH2s52xHdhl7imPHKeVMxNrFlsZOxtnF7YmbineIL4+f5rpw K7kvEzwTahLmEv0SjyQuJIUltSbjkqOTT/FkeIm8nhSVlKyUgVSD1ILUkTSbtL1pM3xvfkM6lL4m vVNAFf1M9Ql1hVuFoxn2GVUZbzNDM09mSWfxsvqy9bN3ZE/kuOd8vQ61jrWuO1ctd3Pu6Hqn9bUb oA0xG7o3amzM3zi+yWPT0c2EzYmbf8gzySvNe70lbEtXvnL+pvyxrR5bmwskCvgFw9tst9VsR23n bu/fYb5j/45PhezCa0UmReVFH4pZxde+Mv2q4quFnbE7+0ssSw7uwuzi7Rra7bD7aKl0aU7p2B7f Pe1l9LLCstd7o/ZeLV9WXrOPsE+4b6TCp6Jzv+b+Xfs/VMZX3qlyrmqtVqreUT13gH1g8KDjwZYa 5ZqimveHuIfu1nrUttdp15UfxhzOOPy0PrS+92vG140NCg1FDR+P8I6MHA082tNo1djYpNRU0gw3 C5unjkUeu/mN6zedLYYtta201qLj4Ljw+LNvo78dOuF9ovsk42TLd1rfVbdR2grbofbs9pmO+I6R zvDOgVMrTnV32Xa1fW/0/ZHTaqerzsieKTlLOJt/duFczrnZ86nnpy/EXRjrjup+cHHVxds9AT39 l7wvXbnsfvlir1PvuSt2V05ftbl66hrjWsd1y+vtfRZ9bT9Y/NDWb9nffsPqRudN65tdA8sHzg46 DF645Xrr8m2v29fvrLwzMBQydHc4cnjkLvvu5L2key/vZ9yff7DpIfph4SOpR+WPlR7X/aj3Y+uI 5ciZUdfRvidBTx6Mscae/5T+04fx/Kfkp+UTqhONk2aTp6fcp24+W/1s/Hnq8/npgp+lf65+ofvi u18cf+mbWTUz/pL/cuHX4lfyr468Xva6e9Z/9vGb5Dfzc4Vv5d8efcd41/s+7P3EfOYH7IeKj3of uz55f3q4kLyw8JsAAwD3hPP7Cg1lbmRzdHJlYW0NZW5kb2JqDTExOSAwIG9iag08PCAvRmlsdGVy IC9GbGF0ZURlY29kZSAvTGVuZ3RoIDMwNQ0+Pg1zdHJlYW0KaN5UUctuwyAQvPMVe0yVA37FbSQU qXUUyYc+1CS9E1i7lmqMsH3I33cBN22RgGF2Z7Ts8qre16abgL+5QR1xgqYz2uE4zE4hXLDtDKQZ 6E5NyyucqpcWOImP13HCvjbNAEIw/k7BcXJXWD2GtT6k6+QO+KvT6DrTwuqUnj+IOM7WfmGPZoIE djvQ2DBePUv7InsE/kf9GzpdLUIW3ulSxqBxtFKhk6ZFEFmyA7GlA43+H2N5VFwa9Skdi5lJQhcT xTZgulgQUzAlTB5L9sOPNlqJTPskjA57UuUp4TzaECZLTxRl9A2E8oSOROWJhvAmVlEciNhknogS wkyU3qOMpqX3KC+E72UknpYCY0n+v34ktw6q2TlqbphbaJ5vW2fwNlo7WN8lv9m3AAMAlgGVtAoN ZW5kc3RyZWFtDWVuZG9iag0xMjAgMCBvYmoNPDwgL0hlaWdodCA5OSAvQml0c1BlckNvbXBvbmVu dCA4IC9MZW5ndGggNDMxIC9XaWR0aCA3NiAvQ29sb3JTcGFjZSAzMiAwIFIgL0ZpbHRlciAvRmxh dGVEZWNvZGUNPj4Nc3RyZWFtCkiJ7FdbjoMwDMwP9z+er1NVW4JjZvyApKtK+GO3pdN5hQAVeeaZ n5rmjgP4qi/rIjBuuQawmFeIy/dlCN/vZEkpH16S1ekrnwfL/ocYWKQaU01WAreViMq1dPtKYFZX g1YeChu+uEw4i7B1vBaT90WrT4Ezsnrp9gNiM8b8wMv1PlLGcwVAO60510LORiKuuhYmE/7tbZ5D c23vka0Pl4Vn9SC+mZmYESQNoV5B12UrXGgPyGl7TRIbdR3osKJqb5dl9ff1uyGjsnjxlsa7OnE5 yEb3NjlRjiozyjen0FczK6hewXUPZGlhEaBcwhyW8oD1y/ny7h0MXqjrc+z4O2wlzEUzFnRvTzvO O7A7oC+P6/jmIr9INvnsC67Va31FS6g8WW9pLra35QyJuU6A8BGRay7oFidMQFea2sXw4wHzJeZ/ hzuFWkaWsbFzwqlAy6154M0ZL/weigAV2QkRfEBZwHDFFxPma5YJ7Csr1D9hSHs8zijs89kZj/79 uwdOuB88Z4y5cCMEQMvAvpa05Z6r2JcDdQCWLg2clDFL30El47dln3nmmV+Y1wD85xuADWVuZHN0 cmVhbQ1lbmRvYmoNMTIxIDAgb2JqDTw8IC9IZWlnaHQgOTkgL0JpdHNQZXJDb21wb25lbnQgOCAv TGVuZ3RoIDM2NyAvV2lkdGggNzYgL0NvbG9yU3BhY2UgMzIgMCBSIC9GaWx0ZXIgL0ZsYXRlRGVj b2RlDT4+DXN0cmVhbQpIiexXSRbCMAjt/S/IdVz4MhAgDCHaalj4Wkv4g5AagBMnHhdXKPbX+r/g zbFZJKz7vv0iIeV+L6sT941Yt+7vm9akBQz6a1VDT1F8CFs1MGOHYR3eSzmdRqDfBzW+l0GxfLZX tOf0MwIryxwS6I0XLIFXCFapxatPNRSKoUwq7trWX3FYwBc4gZNrkVBTdUO3hCpBJU5qkSWcX8sa W22urE9jzC8etqLg1HgDsvJmGjU7LLBQRaA5YvYvBUxNxfYQ23aFkdeaRsP70bN/IzCnxvFFmt73 84womGG20SY/zPq6xq46kFHI0cj8Nltne15LEOfkBXgv1H/HzLBprERHenIt8k9YAENN4ycuCCCp pBcrvxW/uARfvV8PdCabJnyU1n2DTgY+CpCezwErSNK5gx+zGAe11jzhorWkEwFbC3BCCnH5bKUq sMAqx51cMPOy3vfEV7wgYYfGgTrQWqX8hS+AST1x4vnxGgDMbLcbDWVuZHN0cmVhbQ1lbmRvYmoN MTIyIDAgb2JqDVsgL0luZGV4ZWQgMTI0IDAgUiAwIDExNiAwIFINXQ1lbmRvYmoNMTIzIDAgb2Jq DTw8IC9IZWlnaHQgMjAgL0JpdHNQZXJDb21wb25lbnQgMiAvU3VidHlwZSAvSW1hZ2UgL0xlbmd0 aCAxMiAvTWFzaw1bIDIgMg1dIC9XaWR0aCAyMCAvQ29sb3JTcGFjZQ1bIC9JbmRleGVkIC9EZXZp Y2VSR0IgMyAoAAAA////////AAAAKQ1dIC9GaWx0ZXIgL0ZsYXRlRGVjb2RlIC9UeXBlIC9YT2Jq ZWN0DT4+DXN0cmVhbQp4nAsNpT0AAI2AITUNZW5kc3RyZWFtDWVuZG9iag0xMjQgMCBvYmoNWyAv SUNDQmFzZWQgMTE4IDAgUg1dDWVuZG9iag0xMjUgMCBvYmoNPDwgL1R5cGUgL0VuY29kaW5nIC9E aWZmZXJlbmNlcw1bIDMyIC9zcGFjZSA0NSAvaHlwaGVuIC9wZXJpb2QgNDkgL29uZSAvdHdvIC90 aHJlZSAvZm91ciAvZml2ZSAvc2l4IC9zZXZlbiAvZWlnaHQgL25pbmUgNjUgL0EgL0IgL0MgL0Qg L0UgL0YgNzMgL0kgNzYgL0wgL00gNzkgL08gL1AgODIgL1IgL1MgL1QgL1UgL1YgOTcgL2EgL2Ig L2MgL2QgL2UgL2YgL2cgL2ggL2kgMTA3IC9rIC9sIC9tIC9uIC9vIC9wIC9xIC9yIC9zIC90IC91 IC92IC93IC94IC95IC96IDE0NCAvcXVvdGVyaWdodA1dDT4+DWVuZG9iag0xMjYgMCBvYmoNPDwg L0ZpbHRlciAvRmxhdGVEZWNvZGUgL0xlbmd0aCAxMTINPj4Nc3RyZWFtCmjeHIvBDQQxDAKpywXx viqyXxQpJaSDyO/tw8V4ySELy4bptqo7u6pLnfRRdsUL5D/IziSTOOfsvddac05Vq0qVEqVQePA8 zxiD2TThwBDBkI0IAqEKZRggL3GFcAXewO8F0yXgdv34BBgAxENO3woNZW5kc3RyZWFtDWVuZG9i ag0xMjcgMCBvYmoNPDwgL0Nyb3BCb3gNWyAwIDAgNjEyIDc5Mg1dIC9CbGVlZEJveA1bIDAgMCA2 MTIgNzkyDV0gL01lZGlhQm94DVsgMCAwIDYxMiA3OTINXSAvUm90YXRlIDAgL1RyaW1Cb3gNWyAw IDAgNjEyIDc5Mg1dIC9UaHVtYiAxMjEgMCBSIC9SZXNvdXJjZXMNPDwgL0ZvbnQNPDwgL0YxIDY3 IDAgUiAvRjIgNzIgMCBSIC9GMyA1MiAwIFIgL0Y0IDU3IDAgUiAvRjUgNjIgMCBSIC9YaTggMTE3 IDAgUiAvWGk5IDExMSAwIFINPj4gL1Byb2NTZXQNWyAvUERGIC9UZXh0IC9JbWFnZUIgL0ltYWdl QyAvSW1hZ2VJDV0gL0V4dEdTdGF0ZQ08PCAvR1MxIDQyIDAgUiAvR1MyIDQ3IDAgUg0+PiAvWE9i amVjdA08PCAvWGkxMCAxMDUgMCBSIC9YaTAgMTIzIDAgUg0+Pg0+PiAvQXJ0Qm94DVsgMCAwIDYx MiA3OTINXSAvUGFyZW50IDM3IDAgUiAvQ29udGVudHMNWyA5IDAgUiAxMTUgMCBSIDEwOSAwIFIg MTAzIDAgUiA5NyAwIFIgOTIgMCBSIDg3IDAgUiA4MiAwIFIgNzcgMCBSIDQgMCBSDV0gL1R5cGUg L1BhZ2UNPj4NZW5kb2JqDTEyOCAwIG9iag08PCAvTGVuZ3RoIDQNPj4Nc3RyZWFtCv///woNZW5k c3RyZWFtDWVuZG9iaiB4cmVmDTAgMTI5DTAwMDAwMDAwMDAgNjU1MzUgZg0KMDAwMDAwMDA0NCAw MDAwMCBuDQowMDAwMDM1ODk4IDAwMDAwIG4NCjAwMDAwMzYyNzcgMDAwMDAgbg0KMDAwMDAzNjMy NCAwMDAwMCBuDQowMDAwMDM2NjU5IDAwMDAwIG4NCjAwMDAwMzY3MDUgMDAwMDAgbg0KMDAwMDA0 NzMxMSAwMDAwMCBuDQowMDAwMDU3NDMzIDAwMDAwIG4NCjAwMDAwODMwNDEgMDAwMDAgbg0KMDAw MDA4MzEyMiAwMDAwMCBuDQowMDAwMDgzMTc2IDAwMDAwIG4NCjAwMDAwODM4NDQgMDAwMDAgbg0K MDAwMDA4NDIyMiAwMDAwMCBuDQowMDAwMDg3MTUxIDAwMDAwIG4NCjAwMDAwODczMDMgMDAwMDAg bg0KMDAwMDA4NzM0OSAwMDAwMCBuDQowMDAwMDg3Nzg4IDAwMDAwIG4NCjAwMDAwODgzNTQgMDAw MDAgbg0KMDAwMDE0MjQ4MyAwMDAwMCBuDQowMDAwMTQyNTY1IDAwMDAwIG4NCjAwMDAxNDI2MjIg MDAwMDAgbg0KMDAwMDE0MzE0MiAwMDAwMCBuDQowMDAwMTQzNzUzIDAwMDAwIG4NCjAwMDAxNzc0 OTggMDAwMDAgbg0KMDAwMDE3NzY1MCAwMDAwMCBuDQowMDAwMTc4MzUwIDAwMDAwIG4NCjAwMDAx Nzg3OTkgMDAwMDAgbg0KMDAwMDE3OTIwOCAwMDAwMCBuDQowMDAwMTg3MTU1IDAwMDAwIG4NCjAw MDAxODcyMzcgMDAwMDAgbg0KMDAwMDE4NzQ0NCAwMDAwMCBuDQowMDAwMTg3ODkzIDAwMDAwIG4N CjAwMDAxODc5NDQgMDAwMDAgbg0KMDAwMDE4ODg3MCAwMDAwMCBuDQowMDAwMTg5MDIyIDAwMDAw IG4NCjAwMDAxODkyMjYgMDAwMDAgbg0KMDAwMDE4OTcwNiAwMDAwMCBuDQowMDAwMTg5ODE3IDAw MDAwIG4NCjAwMDAxOTE4ODkgMDAwMDAgbg0KMDAwMDE5MTk3MSAwMDAwMCBuDQowMDAwMTkyMTgw IDAwMDAwIG4NCjAwMDAxOTI4NjIgMDAwMDAgbg0KMDAwMDE5MjkyMCAwMDAwMCBuDQowMDAwMTkz MjY1IDAwMDAwIG4NCjAwMDAxOTM0MTcgMDAwMDAgbg0KMDAwMDE5MzYyMiAwMDAwMCBuDQowMDAw MTk0MTAxIDAwMDAwIG4NCjAwMDAxOTQxNDkgMDAwMDAgbg0KMDAwMDE5NDI2MyAwMDAwMCBuDQow MDAwMTk0MzQ1IDAwMDAwIG4NCjAwMDAxOTQ1NTAgMDAwMDAgbg0KMDAwMDIwNDA1NyAwMDAwMCBu DQowMDAwMjA0NzAwIDAwMDAwIG4NCjAwMDAyMDQ5MzggMDAwMDAgbg0KMDAwMDIwNTA4OSAwMDAw MCBuDQowMDAwMjA1MjkzIDAwMDAwIG4NCjAwMDAyMDU2NjMgMDAwMDAgbg0KMDAwMDIwNjMwNSAw MDAwMCBuDQowMDAwMjA2ODM1IDAwMDAwIG4NCjAwMDAyMDY5MTcgMDAwMDAgbg0KMDAwMDIwNzEy NiAwMDAwMCBuDQowMDAwMjA3NDk4IDAwMDAwIG4NCjAwMDAyMDc2ODIgMDAwMDAgbg0KMDAwMDIx OTM2NCAwMDAwMCBuDQowMDAwMjE5NTE2IDAwMDAwIG4NCjAwMDAyMTk3MjEgMDAwMDAgbg0KMDAw MDIyMDE4NCAwMDAwMCBuDQowMDAwMjIwODExIDAwMDAwIG4NCjAwMDAyMjE0MDUgMDAwMDAgbg0K MDAwMDIyMTQ4NyAwMDAwMCBuDQowMDAwMjIxNjk3IDAwMDAwIG4NCjAwMDAyMjkzOTAgMDAwMDAg bg0KMDAwMDIzMDE0NiAwMDAwMCBuDQowMDAwMjQxMzM5IDAwMDAwIG4NCjAwMDAyNDE0OTEgMDAw MDAgbg0KMDAwMDI0MTY5NSAwMDAwMCBuDQowMDAwMjQyMDY1IDAwMDAwIG4NCjAwMDAyNDMyNzQg MDAwMDAgbg0KMDAwMDI0Mzk0NCAwMDAwMCBuDQowMDAwMjQ0MDI2IDAwMDAwIG4NCjAwMDAyNDQy MzEgMDAwMDAgbg0KMDAwMDI0NDU1OCAwMDAwMCBuDQowMDAwMjQ2MDMxIDAwMDAwIG4NCjAwMDAy NjEwNTEgMDAwMDAgbg0KMDAwMDI2MTI1OSAwMDAwMCBuDQowMDAwMjYxNDYzIDAwMDAwIG4NCjAw MDAyNjE4NzggMDAwMDAgbg0KMDAwMDI2MzM1MSAwMDAwMCBuDQowMDAwMjY0MDM0IDAwMDAwIG4N CjAwMDAyODI5MTcgMDAwMDAgbg0KMDAwMDI4MzEyNyAwMDAwMCBuDQowMDAwMjgzMzQyIDAwMDAw IG4NCjAwMDAyODQ5NDkgMDAwMDAgbg0KMDAwMDI5NjM2OSAwMDAwMCBuDQowMDAwMjk2NTc3IDAw MDAwIG4NCjAwMDAyOTY3ODcgMDAwMDAgbg0KMDAwMDI5NzA3OCAwMDAwMCBuDQowMDAwMjk4NjAw IDAwMDAwIG4NCjAwMDAyOTkwMjUgMDAwMDAgbg0KMDAwMDMyMTE4NyAwMDAwMCBuDQowMDAwMzIx MzkyIDAwMDAwIG4NCjAwMDAzMjE0NTggMDAwMDAgbg0KMDAwMDMyMTgzMSAwMDAwMCBuDQowMDAw MzIzMzc3IDAwMDAwIG4NCjAwMDAzMjM5ODkgMDAwMDAgbg0KMDAwMDM0OTg1NyAwMDAwMCBuDQow MDAwMzc2MTI2IDAwMDAwIG4NCjAwMDAzNzYzMzkgMDAwMDAgbg0KMDAwMDM3NjUzNSAwMDAwMCBu DQowMDAwMzc4MTQzIDAwMDAwIG4NCjAwMDAzNzg3ODIgMDAwMDAgbg0KMDAwMDM3OTE5MCAwMDAw MCBuDQowMDAwMzc5OTEzIDAwMDAwIG4NCjAwMDAzODQ4MjkgMDAwMDAgbg0KMDAwMDM5ODAyMSAw MDAwMCBuDQowMDAwMzk4OTM4IDAwMDAwIG4NCjAwMDAzOTg5OTMgMDAwMDAgbg0KMDAwMDM5OTcw MCAwMDAwMCBuDQowMDAwNDAyNDAwIDAwMDAwIG4NCjAwMDA0MDI3NzkgMDAwMDAgbg0KMDAwMDQw MzM0NCAwMDAwMCBuDQowMDAwNDAzODQ1IDAwMDAwIG4NCjAwMDA0MDM4OTMgMDAwMDAgbg0KMDAw MDQwNDExNyAwMDAwMCBuDQowMDAwNDA0MTU2IDAwMDAwIG4NCjAwMDA0MDQ0NTkgMDAwMDAgbg0K MDAwMDQwNDY0NSAwMDAwMCBuDQowMDAwNDA1MTcyIDAwMDAwIG4NCnRyYWlsZXINDTw8IC9Sb290 IDEwOCAwIFIgL1NpemUgMTI5IC9JRA1bIDw4ZTFhNmM4MTY2ZDhjMWFhMjg3YmZjOGJkODAzYmVk OD4gPDZiZDJlODgxN2Q4YmUzN2M2N2M4MDBiMTFlZmZlOGU4Pg1dIC9JbmZvIDEwMiAwIFINPj4N c3RhcnR4cmVmDTQwNTIyNw0lJUVPRgoN --0015175ce16ab718e004ad55e1ec Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel --0015175ce16ab718e004ad55e1ec-- From xen-devel-bounces@lists.xensource.com Tue Sep 20 08:02:52 2011 Return-path: <xen-devel-bounces@lists.xensource.com> Envelope-to: www-data@lists.xensource.com Delivery-date: Tue, 20 Sep 2011 08:02:52 -0700 Received: from localhost ([127.0.0.1] helo=lists.colo.xensource.com) by lists.xensource.com with esmtp (Exim 4.43) id 1R61qV-0006ok-JM; Tue, 20 Sep 2011 08:02:51 -0700 Received: from mail174.messagelabs.com ([85.158.138.51]) by lists.xensource.com with esmtp (Exim 4.43) id 1R61nE-0006Zu-Pm for xen-devel@lists.xensource.com; Tue, 20 Sep 2011 07:59:53 -0700 X-Env-Sender: olaf@aepfle.de X-Msg-Ref: server-3.tower-174.messagelabs.com!1316530764!26076387!1 X-Originating-IP: [81.169.146.161] X-StarScan-Version: 6.4.1; banners=-,-,- X-VirusChecked: Checked Received: (qmail 20328 invoked from network); 20 Sep 2011 14:59:25 -0000 Received: from mo-p00-ob.rzone.de (HELO mo-p00-ob.rzone.de) (81.169.146.161) by server-3.tower-174.messagelabs.com with DHE-RSA-AES256-SHA encrypted SMTP; 20 Sep 2011 14:59:25 -0000 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; t=1316530763; l=2393; s=domk; d=aepfle.de; h=To:From:Date:Subject:Content-Transfer-Encoding:MIME-Version: Content-Type:X-RZG-CLASS-ID:X-RZG-AUTH; bh=RzF/A+rI2uHkL5m6T465/Vq1Ncg=; b=IjmyVKkySX820QkeFlHCQLjJyyWCz+8jhlNCJX5LgU6L26sc6O0M2uitcwoIgbj6Nts iKcMCCgj9fA/DRJ2SvY2QGHaLGZPa28w/6vxl4TMIDBBil/j3QCKCmbS21has41WPn2lP eJlvcfftNMo3n7BR+wO0y/hqzm5xdFLLjUc= X-RZG-AUTH: :P2EQZWCpfu+qG7CngxMFH1J+zrwiavkK6tmQaLfmztM8TOFGhy0PGxWA X-RZG-CLASS-ID: mo00 Received: from probook.site (dslb-088-065-089-185.pools.arcor-ip.net [88.65.89.185]) by smtp.strato.de (jimi mo42) (RZmta 26.7) with (DHE-RSA-AES256-SHA encrypted) ESMTPA id J01357n8KDF9Of for <xen-devel@lists.xensource.com>; Tue, 20 Sep 2011 16:59:04 +0200 (MEST) Received: from probook.site (localhost [IPv6:::1]) by probook.site (Postfix) with ESMTP id C966E18892 for <xen-devel@lists.xensource.com>; Tue, 20 Sep 2011 16:59:03 +0200 (CEST) Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Mercurial-Node: 56c7b8e10d3ba46e34d7a1be3b708da6f999b1a0 Message-Id: <56c7b8e10d3ba46e34d7.1316530742@probook.site> User-Agent: Mercurial-patchbomb/1.7.5 Date: Tue, 20 Sep 2011 16:59:02 +0200 From: Olaf Hering <olaf@aepfle.de> To: xen-devel@lists.xensource.com Subject: [Xen-devel] [PATCH] linux-2.6.18/Input: mousedev - handle mice that use absolute coordinates X-BeenThere: xen-devel@lists.xensource.com X-Mailman-Version: 2.1.5 Precedence: list List-Id: Xen developer discussion <xen-devel.lists.xensource.com> List-Unsubscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe> List-Post: <mailto:xen-devel@lists.xensource.com> List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help> List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=subscribe> Sender: xen-devel-bounces@lists.xensource.com Errors-To: xen-devel-bounces@lists.xensource.com # HG changeset patch # User Olaf Hering <olaf@aepfle.de> # Date 1316530721 -7200 # Node ID 56c7b8e10d3ba46e34d7a1be3b708da6f999b1a0 # Parent f4f25124b1b6d926b6e19a499bf4a3fdc97f0157 linux-2.6.18/Input: mousedev - handle mice that use absolute coordinates After commit 1083:211849d9d511 the mouse multiplexer /dev/input/mice does not receive updates because the base kernel lacks a change from 2.6.24. If xorg.conf uses the mouse driver instead of the evdev driver, the mouse is stuck because now the "Xen Virtual Pointer" is not seen as a mouse anymore. Adding the backported patch below fixes it. Mainline commit 6724f93463c332018e05f538a2ab3ce41eac0e8a Input: mousedev - handle mice that use absolute coordinates Devices like the HP Integrated Remote Console Virtual Mouse, which are standard equipment on all Proliant and Integrity servers, produce absolute coordinates instead of relative coordinates. This is done to synchronize the position of the mouse cursor on the client desktop with the mouse cursor position on the server. Mousedev is not designed to pass those absolute events directly to X, but it can translate them into relative movements. It currently does this for tablet like devices and touchpads. This patch merely tells it to also include a device with ABS_X, ABS_Y, and mouse buttons in its list of devices to process input for. This patch enables the mouse pointer to move when using the remote console. Signed-off-by: Micah Parrish <micah.parrish@hp.com> Signed-off-by: Dmitry Torokhov <dtor@mail.ru> Signed-off-by: Olaf Hering <olaf@aepfle.de> diff -r f4f25124b1b6 -r 56c7b8e10d3b drivers/input/mousedev.c --- a/drivers/input/mousedev.c +++ b/drivers/input/mousedev.c @@ -712,6 +712,12 @@ static struct input_device_id mousedev_i .keybit = { [LONG(BTN_TOOL_FINGER)] = BIT(BTN_TOOL_FINGER) }, .absbit = { BIT(ABS_X) | BIT(ABS_Y) | BIT(ABS_PRESSURE) | BIT(ABS_TOOL_WIDTH) }, }, /* A touchpad */ + { + .flags = INPUT_DEVICE_ID_MATCH_EVBIT | INPUT_DEVICE_ID_MATCH_KEYBIT | INPUT_DEVICE_ID_MATCH_ABSBIT, + .evbit = { BIT(EV_KEY) | BIT(EV_ABS) | BIT(EV_SYN) }, + .keybit = { [LONG(BTN_LEFT)] = BIT(BTN_LEFT) }, + .absbit = { BIT(ABS_X) | BIT(ABS_Y) }, + }, /* Mouse-like device with absolute X and Y but ordinary clicks, like hp ILO2 High Performance mouse */ { }, /* Terminating entry */ }; _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel From xen-devel-bounces@lists.xensource.com Tue Sep 20 08:16:13 2011 Return-path: <xen-devel-bounces@lists.xensource.com> Envelope-to: www-data@lists.xensource.com Delivery-date: Tue, 20 Sep 2011 08:16:13 -0700 Received: from localhost ([127.0.0.1] helo=lists.colo.xensource.com) by lists.xensource.com with esmtp (Exim 4.43) id 1R623R-0007Q1-M2; Tue, 20 Sep 2011 08:16:13 -0700 Received: from mail21.messagelabs.com ([85.158.143.35]) by lists.xensource.com with esmtp (Exim 4.43) id 1R622R-0007DJ-O8 for xen-devel@lists.xensource.com; Tue, 20 Sep 2011 08:15:12 -0700 X-Env-Sender: JBeulich@suse.com X-Msg-Ref: server-8.tower-21.messagelabs.com!1316531692!59706879!1 X-Originating-IP: [130.57.49.28] X-StarScan-Version: 6.4.1; banners=-,-,- X-VirusChecked: Checked Received: (qmail 4175 invoked from network); 20 Sep 2011 15:14:52 -0000 Received: from nat28.tlf.novell.com (HELO nat28.tlf.novell.com) (130.57.49.28) by server-8.tower-21.messagelabs.com with DHE-RSA-AES256-SHA encrypted SMTP; 20 Sep 2011 15:14:52 -0000 Received: from EMEA1-MTA by nat28.tlf.novell.com with Novell_GroupWise; Tue, 20 Sep 2011 16:15:07 +0100 Message-Id: <4E78CA350200007800056D18@nat28.tlf.novell.com> X-Mailer: Novell GroupWise Internet Agent 8.0.1 Date: Tue, 20 Sep 2011 16:15:33 +0100 From: "Jan Beulich" <JBeulich@suse.com> To: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com> Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: quoted-printable Content-Disposition: inline Subject: [Xen-devel] [PATCH 0/7] PCI multi-segment support X-BeenThere: xen-devel@lists.xensource.com X-Mailman-Version: 2.1.5 Precedence: list List-Id: Xen developer discussion <xen-devel.lists.xensource.com> List-Unsubscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe> List-Post: <mailto:xen-devel@lists.xensource.com> List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help> List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=subscribe> Sender: xen-devel-bounces@lists.xensource.com Errors-To: xen-devel-bounces@lists.xensource.com In order for Xen to be able to boot on systems with multiple PCI segments (also called domains), a number of changes are necessary to the hypervisor, the hypercall interface, the tools, and the Dom0 kernel, as in most code paths and definitions there were not even provisions for passing a segment number. 1: introduce notion of PCI segments 2: add new physdevop-s 3: adjust domctl interface 4: VT-d specific adjustments 5: AMD-IOMMU specific adjustments 6: Pass-through adjustments 7: config space accessor adjustments Signed-off-by: Jan Beulich <jbeulich@suse.com> _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel From xen-devel-bounces@lists.xensource.com Tue Sep 20 08:17:46 2011 Return-path: <xen-devel-bounces@lists.xensource.com> Envelope-to: www-data@lists.xensource.com Delivery-date: Tue, 20 Sep 2011 08:17:46 -0700 Received: from localhost ([127.0.0.1] helo=lists.colo.xensource.com) by lists.xensource.com with esmtp (Exim 4.43) id 1R624w-0007no-EK; Tue, 20 Sep 2011 08:17:46 -0700 Received: from mail21.messagelabs.com ([85.158.143.35]) by lists.xensource.com with esmtp (Exim 4.43) id 1R623g-0007TL-Vo for xen-devel@lists.xensource.com; Tue, 20 Sep 2011 08:16:30 -0700 X-Env-Sender: JBeulich@suse.com X-Msg-Ref: server-3.tower-21.messagelabs.com!1316531796!52304442!1 X-Originating-IP: [130.57.49.28] X-StarScan-Version: 6.4.1; banners=-,-,- X-VirusChecked: Checked Received: (qmail 1468 invoked from network); 20 Sep 2011 15:16:37 -0000 Received: from nat28.tlf.novell.com (HELO nat28.tlf.novell.com) (130.57.49.28) by server-3.tower-21.messagelabs.com with DHE-RSA-AES256-SHA encrypted SMTP; 20 Sep 2011 15:16:37 -0000 Received: from EMEA1-MTA by nat28.tlf.novell.com with Novell_GroupWise; Tue, 20 Sep 2011 16:16:25 +0100 Message-Id: <4E78CA820200007800056D1C@nat28.tlf.novell.com> X-Mailer: Novell GroupWise Internet Agent 8.0.1 Date: Tue, 20 Sep 2011 16:16:50 +0100 From: "Jan Beulich" <JBeulich@suse.com> To: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com> Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="=__Part82ADB972.0__=" Subject: [Xen-devel] [PATCH 1/7] PCI multi-seg: introduce notion of PCI segments X-BeenThere: xen-devel@lists.xensource.com X-Mailman-Version: 2.1.5 Precedence: list List-Id: Xen developer discussion <xen-devel.lists.xensource.com> List-Unsubscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe> List-Post: <mailto:xen-devel@lists.xensource.com> List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help> List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=subscribe> Sender: xen-devel-bounces@lists.xensource.com Errors-To: xen-devel-bounces@lists.xensource.com This is a MIME message. If you are reading this text, you may want to consider changing to a mail reader or gateway that understands how to properly handle MIME multipart messages. --=__Part82ADB972.0__= Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: quoted-printable Content-Disposition: inline Signed-off-by: Jan Beulich <jbeulich@suse.com> --- 2011-08-25.orig/xen/arch/x86/setup.c 2011-08-08 08:29:50.0000000= 00 +0200 +++ 2011-08-25/xen/arch/x86/setup.c 2011-08-25 15:06:23.000000000 = +0200 @@ -1246,6 +1246,8 @@ void __init __start_xen(unsigned long mb =20 local_irq_enable(); =20 + pt_pci_init(); + #ifdef CONFIG_X86_64 vesa_mtrr_init(); =20 --- 2011-08-25.orig/xen/arch/x86/x86_64/acpi_mmcfg.c 2011-08-19 = 17:08:35.000000000 +0200 +++ 2011-08-25/xen/arch/x86/x86_64/acpi_mmcfg.c 2011-08-25 15:06:23.0000000= 00 +0200 @@ -111,6 +111,7 @@ int __init acpi_parse_mcfg(struct acpi_t pci_mmcfg_config_num =3D 0; return -ENODEV; } + pci_add_segment(pci_mmcfg_config[i].pci_segment); } =20 return 0; --- 2011-08-25.orig/xen/arch/x86/x86_64/mmconfig-shared.c 2011-08-08 = 08:29:50.000000000 +0200 +++ 2011-08-25/xen/arch/x86/x86_64/mmconfig-shared.c 2011-08-25 = 15:06:23.000000000 +0200 @@ -171,6 +171,7 @@ static const char __init *pci_mmcfg_amd_ pci_mmcfg_config[i].pci_segment =3D i; pci_mmcfg_config[i].start_bus_number =3D 0; pci_mmcfg_config[i].end_bus_number =3D (1 << busnbits) - 1; + pci_add_segment(i); } =20 return "AMD Family 10h NB"; --- 2011-08-25.orig/xen/drivers/passthrough/pci.c 2011-08-16 = 08:15:46.000000000 +0200 +++ 2011-08-25/xen/drivers/passthrough/pci.c 2011-08-25 15:06:23.0000000= 00 +0200 @@ -26,29 +26,93 @@ #include <asm/hvm/irq.h> #include <xen/delay.h> #include <xen/keyhandler.h> +#include <xen/radix-tree.h> #include <xen/tasklet.h> #ifdef CONFIG_X86 #include <asm/msi.h> #endif =20 -LIST_HEAD(alldevs_list); +struct pci_seg { + struct list_head alldevs_list; + u16 nr; + /* bus2bridge_lock protects bus2bridge array */ + spinlock_t bus2bridge_lock; +#define MAX_BUSES 256 + struct { + u8 map; + u8 bus; + u8 devfn; + } bus2bridge[MAX_BUSES]; +}; + spinlock_t pcidevs_lock =3D SPIN_LOCK_UNLOCKED; +static struct radix_tree_root pci_segments; =20 -#define MAX_BUSES 256 -static struct { - u8 map; - u8 bus; - u8 devfn; -} bus2bridge[MAX_BUSES]; +static inline struct pci_seg *get_pseg(u16 seg) +{ + return radix_tree_lookup(&pci_segments, seg); +} + +static struct pci_seg *alloc_pseg(u16 seg) +{ + struct pci_seg *pseg =3D get_pseg(seg); + + if ( pseg ) + return pseg; + + pseg =3D xmalloc(struct pci_seg); + if ( !pseg ) + return NULL; + + pseg->nr =3D seg; + INIT_LIST_HEAD(&pseg->alldevs_list); + spin_lock_init(&pseg->bus2bridge_lock); + memset(pseg->bus2bridge, 0, sizeof(pseg->bus2bridge)); + + if ( radix_tree_insert(&pci_segments, seg, pseg) ) + { + xfree(pseg); + pseg =3D NULL; + } + + return pseg; +} =20 -/* bus2bridge_lock protects bus2bridge array */ -static DEFINE_SPINLOCK(bus2bridge_lock); +static int pci_segments_iterate( + int (*handler)(struct pci_seg *, void *), void *arg) +{ + u16 seg =3D 0; + int rc =3D 0; + + do { + struct pci_seg *pseg; + + if ( !radix_tree_gang_lookup(&pci_segments, (void **)&pseg, seg, = 1) ) + break; + rc =3D handler(pseg, arg); + seg =3D pseg->nr + 1; + } while (!rc && seg); + + return rc; +} + +void __init pt_pci_init(void) +{ + radix_tree_init(&pci_segments); + if ( !alloc_pseg(0) ) + panic("Could not initialize PCI segment 0\n"); +} =20 -static struct pci_dev *alloc_pdev(u8 bus, u8 devfn) +int __init pci_add_segment(u16 seg) +{ + return alloc_pseg(seg) ? 0 : -ENOMEM; +} + +static struct pci_dev *alloc_pdev(struct pci_seg *pseg, u8 bus, u8 devfn) { struct pci_dev *pdev; =20 - list_for_each_entry ( pdev, &alldevs_list, alldevs_list ) + list_for_each_entry ( pdev, &pseg->alldevs_list, alldevs_list ) if ( pdev->bus =3D=3D bus && pdev->devfn =3D=3D devfn ) return pdev; =20 @@ -61,7 +125,7 @@ static struct pci_dev *alloc_pdev(u8 bus *((u8*) &pdev->devfn) =3D devfn; pdev->domain =3D NULL; INIT_LIST_HEAD(&pdev->msi_list); - list_add(&pdev->alldevs_list, &alldevs_list); + list_add(&pdev->alldevs_list, &pseg->alldevs_list); spin_lock_init(&pdev->msix_table_lock); =20 return pdev; @@ -75,11 +139,15 @@ static void free_pdev(struct pci_dev *pd =20 struct pci_dev *pci_get_pdev(int bus, int devfn) { + struct pci_seg *pseg =3D get_pseg(0); struct pci_dev *pdev =3D NULL; =20 ASSERT(spin_is_locked(&pcidevs_lock)); =20 - list_for_each_entry ( pdev, &alldevs_list, alldevs_list ) + if ( !pseg ) + return NULL; + + list_for_each_entry ( pdev, &pseg->alldevs_list, alldevs_list ) if ( (pdev->bus =3D=3D bus || bus =3D=3D -1) && (pdev->devfn =3D=3D devfn || devfn =3D=3D -1) ) { @@ -91,9 +159,13 @@ struct pci_dev *pci_get_pdev(int bus, in =20 struct pci_dev *pci_get_pdev_by_domain(struct domain *d, int bus, int = devfn) { + struct pci_seg *pseg =3D get_pseg(0); struct pci_dev *pdev =3D NULL; =20 - list_for_each_entry ( pdev, &alldevs_list, alldevs_list ) + if ( !pseg ) + return NULL; + + list_for_each_entry ( pdev, &pseg->alldevs_list, alldevs_list ) if ( (pdev->bus =3D=3D bus || bus =3D=3D -1) && (pdev->devfn =3D=3D devfn || devfn =3D=3D -1) && (pdev->domain =3D=3D d) ) @@ -145,6 +217,7 @@ void pci_enable_acs(struct pci_dev *pdev =20 int pci_add_device(u8 bus, u8 devfn, const struct pci_dev_info *info) { + struct pci_seg *pseg; struct pci_dev *pdev; unsigned int slot =3D PCI_SLOT(devfn), func =3D PCI_FUNC(devfn); const char *pdev_type; @@ -167,7 +240,10 @@ int pci_add_device(u8 bus, u8 devfn, con return -EINVAL; =20 spin_lock(&pcidevs_lock); - pdev =3D alloc_pdev(bus, devfn); + pseg =3D alloc_pseg(0); + if ( !pseg ) + goto out; + pdev =3D alloc_pdev(pseg, bus, devfn); if ( !pdev ) goto out; =20 @@ -262,11 +338,15 @@ out: =20 int pci_remove_device(u8 bus, u8 devfn) { + struct pci_seg *pseg =3D get_pseg(0); struct pci_dev *pdev; int ret =3D -ENODEV; =20 + if ( !pseg ) + return -ENODEV; + spin_lock(&pcidevs_lock); - list_for_each_entry ( pdev, &alldevs_list, alldevs_list ) + list_for_each_entry ( pdev, &pseg->alldevs_list, alldevs_list ) if ( pdev->bus =3D=3D bus && pdev->devfn =3D=3D devfn ) { ret =3D iommu_remove_device(pdev); @@ -384,22 +464,26 @@ int pdev_type(u8 bus, u8 devfn) */ int find_upstream_bridge(u8 *bus, u8 *devfn, u8 *secbus) { + struct pci_seg *pseg =3D get_pseg(0); int ret =3D 0; int cnt =3D 0; =20 if ( *bus =3D=3D 0 ) return 0; =20 - if ( !bus2bridge[*bus].map ) + if ( !pseg ) + return -1; + + if ( !pseg->bus2bridge[*bus].map ) return 0; =20 ret =3D 1; - spin_lock(&bus2bridge_lock); - while ( bus2bridge[*bus].map ) + spin_lock(&pseg->bus2bridge_lock); + while ( pseg->bus2bridge[*bus].map ) { *secbus =3D *bus; - *devfn =3D bus2bridge[*bus].devfn; - *bus =3D bus2bridge[*bus].bus; + *devfn =3D pseg->bus2bridge[*bus].devfn; + *bus =3D pseg->bus2bridge[*bus].bus; if ( cnt++ >=3D MAX_BUSES ) { ret =3D -1; @@ -408,7 +492,7 @@ int find_upstream_bridge(u8 *bus, u8 *de } =20 out: - spin_unlock(&bus2bridge_lock); + spin_unlock(&pseg->bus2bridge_lock); return ret; } =20 @@ -431,14 +515,13 @@ int __init pci_device_detect(u8 bus, u8=20 * scan pci devices to add all existed PCI devices to alldevs_list, * and setup pci hierarchy in array bus2bridge. */ -int __init scan_pci_devices(void) +static int __init _scan_pci_devices(struct pci_seg *pseg, void *arg) { struct pci_dev *pdev; int bus, dev, func; u8 sec_bus, sub_bus; int type; =20 - spin_lock(&pcidevs_lock); for ( bus =3D 0; bus < 256; bus++ ) { for ( dev =3D 0; dev < 32; dev++ ) @@ -448,11 +531,10 @@ int __init scan_pci_devices(void) if ( pci_device_detect(bus, dev, func) =3D=3D 0 ) continue; =20 - pdev =3D alloc_pdev(bus, PCI_DEVFN(dev, func)); + pdev =3D alloc_pdev(pseg, bus, PCI_DEVFN(dev, func)); if ( !pdev ) { printk("%s: alloc_pdev failed.\n", __func__); - spin_unlock(&pcidevs_lock); return -ENOMEM; } =20 @@ -470,14 +552,15 @@ int __init scan_pci_devices(void) sub_bus =3D pci_conf_read8(bus, dev, func, PCI_SUBORDINATE_BUS); =20 - spin_lock(&bus2bridge_lock); + spin_lock(&pseg->bus2bridge_lock); for ( sub_bus &=3D 0xff; sec_bus <=3D sub_bus; = sec_bus++ ) { - bus2bridge[sec_bus].map =3D 1; - bus2bridge[sec_bus].bus =3D bus; - bus2bridge[sec_bus].devfn =3D PCI_DEVFN(dev, = func); + pseg->bus2bridge[sec_bus].map =3D 1; + pseg->bus2bridge[sec_bus].bus =3D bus; + pseg->bus2bridge[sec_bus].devfn =3D + PCI_DEVFN(dev, func); } - spin_unlock(&bus2bridge_lock); + spin_unlock(&pseg->bus2bridge_lock); break; =20 case DEV_TYPE_PCIe_ENDPOINT: @@ -487,7 +570,6 @@ int __init scan_pci_devices(void) default: printk("%s: unknown type: bdf =3D %x:%x.%x\n", __func__, bus, dev, func); - spin_unlock(&pcidevs_lock); return -EINVAL; } =20 @@ -498,39 +580,53 @@ int __init scan_pci_devices(void) } } =20 - spin_unlock(&pcidevs_lock); return 0; } =20 +int __init scan_pci_devices(void) +{ + int ret; + + spin_lock(&pcidevs_lock); + ret =3D pci_segments_iterate(_scan_pci_devices, NULL); + spin_unlock(&pcidevs_lock); + + return ret; +} + /* Disconnect all PCI devices from the PCI buses. From the PCI spec: * "When a 0 is written to [the COMMAND] register, the device is * logically disconnected from the PCI bus for all accesses except * configuration accesses. All devices are required to support * this base level of functionality." */ -void disconnect_pci_devices(void) +static int _disconnect_pci_devices(struct pci_seg *pseg, void *arg) { struct pci_dev *pdev; =20 - spin_lock(&pcidevs_lock); - - list_for_each_entry ( pdev, &alldevs_list, alldevs_list ) + list_for_each_entry ( pdev, &pseg->alldevs_list, alldevs_list ) pci_conf_write16(pdev->bus, PCI_SLOT(pdev->devfn), PCI_FUNC(pdev->devfn), PCI_COMMAND, 0); =20 + return 0; +} + +void disconnect_pci_devices(void) +{ + spin_lock(&pcidevs_lock); + pci_segments_iterate(_disconnect_pci_devices, NULL); spin_unlock(&pcidevs_lock); } =20 #ifdef SUPPORT_MSI_REMAPPING -static void dump_pci_devices(unsigned char ch) +static int _dump_pci_devices(struct pci_seg *pseg, void *arg) { struct pci_dev *pdev; struct msi_desc *msi; =20 - printk("=3D=3D=3D=3D PCI devices =3D=3D=3D=3D\n"); - spin_lock(&pcidevs_lock); + printk("=3D=3D=3D=3D segment %04x =3D=3D=3D=3D\n", pseg->nr); =20 - list_for_each_entry ( pdev, &alldevs_list, alldevs_list ) + list_for_each_entry ( pdev, &pseg->alldevs_list, alldevs_list ) { printk("%02x:%02x.%x - dom %-3d - MSIs < ", pdev->bus, PCI_SLOT(pdev->devfn), PCI_FUNC(pdev->devfn), @@ -540,6 +636,14 @@ static void dump_pci_devices(unsigned ch printk(">\n"); } =20 + return 0; +} + +static void dump_pci_devices(unsigned char ch) +{ + printk("=3D=3D=3D=3D PCI devices =3D=3D=3D=3D\n"); + spin_lock(&pcidevs_lock); + pci_segments_iterate(_dump_pci_devices, NULL); spin_unlock(&pcidevs_lock); } =20 --- 2011-08-25.orig/xen/include/xen/iommu.h 2011-08-25 08:21:53.0000000= 00 +0200 +++ 2011-08-25/xen/include/xen/iommu.h 2011-08-25 15:06:23.000000000 = +0200 @@ -92,6 +92,8 @@ void iommu_pte_flush(struct domain *d, u void iommu_set_pgd(struct domain *d); void iommu_domain_teardown(struct domain *d); =20 +void pt_pci_init(void); + struct pirq; int hvm_do_IRQ_dpci(struct domain *, struct pirq *); int dpci_ioport_intercept(ioreq_t *p); --- 2011-08-25.orig/xen/include/xen/pci.h 2011-08-16 08:15:46.0000000= 00 +0200 +++ 2011-08-25/xen/include/xen/pci.h 2011-08-25 15:06:23.000000000 = +0200 @@ -89,6 +89,7 @@ struct pci_dev *pci_lock_pdev(int bus, i struct pci_dev *pci_lock_domain_pdev(struct domain *d, int bus, int = devfn); =20 void pci_release_devices(struct domain *d); +int pci_add_segment(u16 seg); int pci_add_device(u8 bus, u8 devfn, const struct pci_dev_info *); int pci_remove_device(u8 bus, u8 devfn); struct pci_dev *pci_get_pdev(int bus, int devfn); --=__Part82ADB972.0__= Content-Type: text/plain; name="pci-segments.patch" Content-Transfer-Encoding: quoted-printable Content-Disposition: attachment; filename="pci-segments.patch" Signed-off-by: Jan Beulich <jbeulich@suse.com>=0A=0A--- 2011-08-25.orig/xen= /arch/x86/setup.c 2011-08-08 08:29:50.000000000 +0200=0A+++ = 2011-08-25/xen/arch/x86/setup.c 2011-08-25 15:06:23.000000000 +0200=0A@@ = -1246,6 +1246,8 @@ void __init __start_xen(unsigned long mb=0A =0A = local_irq_enable();=0A =0A+ pt_pci_init();=0A+=0A #ifdef CONFIG_X86_64= =0A vesa_mtrr_init();=0A =0A--- 2011-08-25.orig/xen/arch/x86/x86_64/acp= i_mmcfg.c 2011-08-19 17:08:35.000000000 +0200=0A+++ 2011-08-25/xen/ar= ch/x86/x86_64/acpi_mmcfg.c 2011-08-25 15:06:23.000000000 +0200=0A@@ = -111,6 +111,7 @@ int __init acpi_parse_mcfg(struct acpi_t=0A = pci_mmcfg_config_num =3D 0;=0A return -ENODEV;=0A = }=0A+ pci_add_segment(pci_mmcfg_config[i].pci_segment);=0A }=0A = =0A return 0;=0A--- 2011-08-25.orig/xen/arch/x86/x86_64/mmconfig-shared= .c 2011-08-08 08:29:50.000000000 +0200=0A+++ 2011-08-25/xen/arch/x86/x= 86_64/mmconfig-shared.c 2011-08-25 15:06:23.000000000 +0200=0A@@ -171,6 = +171,7 @@ static const char __init *pci_mmcfg_amd_=0A pci_mmcfg_con= fig[i].pci_segment =3D i;=0A pci_mmcfg_config[i].start_bus_number = =3D 0;=0A pci_mmcfg_config[i].end_bus_number =3D (1 << busnbits) - = 1;=0A+ pci_add_segment(i);=0A }=0A =0A return "AMD Family = 10h NB";=0A--- 2011-08-25.orig/xen/drivers/passthrough/pci.c 2011-08-16 = 08:15:46.000000000 +0200=0A+++ 2011-08-25/xen/drivers/passthrough/pci.c = 2011-08-25 15:06:23.000000000 +0200=0A@@ -26,29 +26,93 @@=0A #include = <asm/hvm/irq.h>=0A #include <xen/delay.h>=0A #include <xen/keyhandler.h>=0A= +#include <xen/radix-tree.h>=0A #include <xen/tasklet.h>=0A #ifdef = CONFIG_X86=0A #include <asm/msi.h>=0A #endif=0A =0A-LIST_HEAD(alldevs_list)= ;=0A+struct pci_seg {=0A+ struct list_head alldevs_list;=0A+ u16 = nr;=0A+ /* bus2bridge_lock protects bus2bridge array */=0A+ = spinlock_t bus2bridge_lock;=0A+#define MAX_BUSES 256=0A+ struct {=0A+ = u8 map;=0A+ u8 bus;=0A+ u8 devfn;=0A+ } bus2bridge[MA= X_BUSES];=0A+};=0A+=0A spinlock_t pcidevs_lock =3D SPIN_LOCK_UNLOCKED;=0A+s= tatic struct radix_tree_root pci_segments;=0A =0A-#define MAX_BUSES = 256=0A-static struct {=0A- u8 map;=0A- u8 bus;=0A- u8 devfn;=0A-} = bus2bridge[MAX_BUSES];=0A+static inline struct pci_seg *get_pseg(u16 = seg)=0A+{=0A+ return radix_tree_lookup(&pci_segments, seg);=0A+}=0A+=0A+= static struct pci_seg *alloc_pseg(u16 seg)=0A+{=0A+ struct pci_seg = *pseg =3D get_pseg(seg);=0A+=0A+ if ( pseg )=0A+ return = pseg;=0A+=0A+ pseg =3D xmalloc(struct pci_seg);=0A+ if ( !pseg )=0A+ = return NULL;=0A+=0A+ pseg->nr =3D seg;=0A+ INIT_LIST_HEAD(&pse= g->alldevs_list);=0A+ spin_lock_init(&pseg->bus2bridge_lock);=0A+ = memset(pseg->bus2bridge, 0, sizeof(pseg->bus2bridge));=0A+=0A+ if ( = radix_tree_insert(&pci_segments, seg, pseg) )=0A+ {=0A+ = xfree(pseg);=0A+ pseg =3D NULL;=0A+ }=0A+=0A+ return = pseg;=0A+}=0A =0A-/* bus2bridge_lock protects bus2bridge array */=0A-static= DEFINE_SPINLOCK(bus2bridge_lock);=0A+static int pci_segments_iterate(=0A+ = int (*handler)(struct pci_seg *, void *), void *arg)=0A+{=0A+ u16 = seg =3D 0;=0A+ int rc =3D 0;=0A+=0A+ do {=0A+ struct pci_seg = *pseg;=0A+=0A+ if ( !radix_tree_gang_lookup(&pci_segments, (void = **)&pseg, seg, 1) )=0A+ break;=0A+ rc =3D handler(pseg, = arg);=0A+ seg =3D pseg->nr + 1;=0A+ } while (!rc && seg);=0A+=0A+= return rc;=0A+}=0A+=0A+void __init pt_pci_init(void)=0A+{=0A+ = radix_tree_init(&pci_segments);=0A+ if ( !alloc_pseg(0) )=0A+ = panic("Could not initialize PCI segment 0\n");=0A+}=0A =0A-static struct = pci_dev *alloc_pdev(u8 bus, u8 devfn)=0A+int __init pci_add_segment(u16 = seg)=0A+{=0A+ return alloc_pseg(seg) ? 0 : -ENOMEM;=0A+}=0A+=0A+static = struct pci_dev *alloc_pdev(struct pci_seg *pseg, u8 bus, u8 devfn)=0A {=0A = struct pci_dev *pdev;=0A =0A- list_for_each_entry ( pdev, &alldevs_l= ist, alldevs_list )=0A+ list_for_each_entry ( pdev, &pseg->alldevs_list,= alldevs_list )=0A if ( pdev->bus =3D=3D bus && pdev->devfn =3D=3D = devfn )=0A return pdev;=0A =0A@@ -61,7 +125,7 @@ static struct = pci_dev *alloc_pdev(u8 bus=0A *((u8*) &pdev->devfn) =3D devfn;=0A = pdev->domain =3D NULL;=0A INIT_LIST_HEAD(&pdev->msi_list);=0A- = list_add(&pdev->alldevs_list, &alldevs_list);=0A+ list_add(&pdev->alldev= s_list, &pseg->alldevs_list);=0A spin_lock_init(&pdev->msix_table_lock)= ;=0A =0A return pdev;=0A@@ -75,11 +139,15 @@ static void free_pdev(stru= ct pci_dev *pd=0A =0A struct pci_dev *pci_get_pdev(int bus, int devfn)=0A = {=0A+ struct pci_seg *pseg =3D get_pseg(0);=0A struct pci_dev *pdev = =3D NULL;=0A =0A ASSERT(spin_is_locked(&pcidevs_lock));=0A =0A- = list_for_each_entry ( pdev, &alldevs_list, alldevs_list )=0A+ if ( = !pseg )=0A+ return NULL;=0A+=0A+ list_for_each_entry ( pdev, = &pseg->alldevs_list, alldevs_list )=0A if ( (pdev->bus =3D=3D bus = || bus =3D=3D -1) &&=0A (pdev->devfn =3D=3D devfn || devfn = =3D=3D -1) )=0A {=0A@@ -91,9 +159,13 @@ struct pci_dev *pci_get_pde= v(int bus, in=0A =0A struct pci_dev *pci_get_pdev_by_domain(struct domain = *d, int bus, int devfn)=0A {=0A+ struct pci_seg *pseg =3D get_pseg(0);= =0A struct pci_dev *pdev =3D NULL;=0A =0A- list_for_each_entry ( = pdev, &alldevs_list, alldevs_list )=0A+ if ( !pseg )=0A+ return = NULL;=0A+=0A+ list_for_each_entry ( pdev, &pseg->alldevs_list, = alldevs_list )=0A if ( (pdev->bus =3D=3D bus || bus =3D=3D -1) = &&=0A (pdev->devfn =3D=3D devfn || devfn =3D=3D -1) &&=0A = (pdev->domain =3D=3D d) )=0A@@ -145,6 +217,7 @@ void pci_enable_= acs(struct pci_dev *pdev=0A =0A int pci_add_device(u8 bus, u8 devfn, const = struct pci_dev_info *info)=0A {=0A+ struct pci_seg *pseg;=0A struct = pci_dev *pdev;=0A unsigned int slot =3D PCI_SLOT(devfn), func =3D = PCI_FUNC(devfn);=0A const char *pdev_type;=0A@@ -167,7 +240,10 @@ int = pci_add_device(u8 bus, u8 devfn, con=0A return -EINVAL;=0A =0A = spin_lock(&pcidevs_lock);=0A- pdev =3D alloc_pdev(bus, devfn);=0A+ = pseg =3D alloc_pseg(0);=0A+ if ( !pseg )=0A+ goto out;=0A+ = pdev =3D alloc_pdev(pseg, bus, devfn);=0A if ( !pdev )=0A goto = out;=0A =0A@@ -262,11 +338,15 @@ out:=0A =0A int pci_remove_device(u8 bus, = u8 devfn)=0A {=0A+ struct pci_seg *pseg =3D get_pseg(0);=0A struct = pci_dev *pdev;=0A int ret =3D -ENODEV;=0A =0A+ if ( !pseg )=0A+ = return -ENODEV;=0A+=0A spin_lock(&pcidevs_lock);=0A- list_for_eac= h_entry ( pdev, &alldevs_list, alldevs_list )=0A+ list_for_each_entry ( = pdev, &pseg->alldevs_list, alldevs_list )=0A if ( pdev->bus =3D=3D = bus && pdev->devfn =3D=3D devfn )=0A {=0A ret =3D = iommu_remove_device(pdev);=0A@@ -384,22 +464,26 @@ int pdev_type(u8 bus, = u8 devfn)=0A */=0A int find_upstream_bridge(u8 *bus, u8 *devfn, u8 = *secbus)=0A {=0A+ struct pci_seg *pseg =3D get_pseg(0);=0A int ret = =3D 0;=0A int cnt =3D 0;=0A =0A if ( *bus =3D=3D 0 )=0A = return 0;=0A =0A- if ( !bus2bridge[*bus].map )=0A+ if ( !pseg )=0A+ = return -1;=0A+=0A+ if ( !pseg->bus2bridge[*bus].map )=0A = return 0;=0A =0A ret =3D 1;=0A- spin_lock(&bus2bridge_lock);=0A- = while ( bus2bridge[*bus].map )=0A+ spin_lock(&pseg->bus2bridge_lock);=0A= + while ( pseg->bus2bridge[*bus].map )=0A {=0A *secbus =3D = *bus;=0A- *devfn =3D bus2bridge[*bus].devfn;=0A- *bus =3D = bus2bridge[*bus].bus;=0A+ *devfn =3D pseg->bus2bridge[*bus].devfn;= =0A+ *bus =3D pseg->bus2bridge[*bus].bus;=0A if ( cnt++ = >=3D MAX_BUSES )=0A {=0A ret =3D -1;=0A@@ -408,7 = +492,7 @@ int find_upstream_bridge(u8 *bus, u8 *de=0A }=0A =0A = out:=0A- spin_unlock(&bus2bridge_lock);=0A+ spin_unlock(&pseg->bus2br= idge_lock);=0A return ret;=0A }=0A =0A@@ -431,14 +515,13 @@ int __init = pci_device_detect(u8 bus, u8 =0A * scan pci devices to add all existed = PCI devices to alldevs_list,=0A * and setup pci hierarchy in array = bus2bridge.=0A */=0A-int __init scan_pci_devices(void)=0A+static int = __init _scan_pci_devices(struct pci_seg *pseg, void *arg)=0A {=0A = struct pci_dev *pdev;=0A int bus, dev, func;=0A u8 sec_bus, = sub_bus;=0A int type;=0A =0A- spin_lock(&pcidevs_lock);=0A for = ( bus =3D 0; bus < 256; bus++ )=0A {=0A for ( dev =3D 0; dev < = 32; dev++ )=0A@@ -448,11 +531,10 @@ int __init scan_pci_devices(void)=0A = if ( pci_device_detect(bus, dev, func) =3D=3D 0 )=0A = continue;=0A =0A- pdev =3D alloc_pdev(bus, = PCI_DEVFN(dev, func));=0A+ pdev =3D alloc_pdev(pseg, bus, = PCI_DEVFN(dev, func));=0A if ( !pdev )=0A = {=0A printk("%s: alloc_pdev failed.\n", __func__);=0A- = spin_unlock(&pcidevs_lock);=0A = return -ENOMEM;=0A }=0A =0A@@ -470,14 +552,15 @@ int = __init scan_pci_devices(void)=0A sub_bus =3D = pci_conf_read8(bus, dev, func,=0A = PCI_SUBORDINATE_BUS);=0A =0A- spin_lock(&bus= 2bridge_lock);=0A+ spin_lock(&pseg->bus2bridge_lock)= ;=0A for ( sub_bus &=3D 0xff; sec_bus <=3D = sub_bus; sec_bus++ )=0A {=0A- = bus2bridge[sec_bus].map =3D 1;=0A- = bus2bridge[sec_bus].bus =3D bus;=0A- bus2bridge= [sec_bus].devfn =3D PCI_DEVFN(dev, func);=0A+ = pseg->bus2bridge[sec_bus].map =3D 1;=0A+ = pseg->bus2bridge[sec_bus].bus =3D bus;=0A+ = pseg->bus2bridge[sec_bus].devfn =3D=0A+ = PCI_DEVFN(dev, func);=0A }=0A- = spin_unlock(&bus2bridge_lock);=0A+ spin_unlock(&p= seg->bus2bridge_lock);=0A break;=0A =0A = case DEV_TYPE_PCIe_ENDPOINT:=0A@@ -487,7 +570,6 @@ int __init = scan_pci_devices(void)=0A default:=0A = printk("%s: unknown type: bdf =3D %x:%x.%x\n",=0A = __func__, bus, dev, func);=0A- = spin_unlock(&pcidevs_lock);=0A return -EINVAL;=0A = }=0A =0A@@ -498,39 +580,53 @@ int __init scan_pci_devices(vo= id)=0A }=0A }=0A =0A- spin_unlock(&pcidevs_lock);=0A = return 0;=0A }=0A =0A+int __init scan_pci_devices(void)=0A+{=0A+ int = ret;=0A+=0A+ spin_lock(&pcidevs_lock);=0A+ ret =3D pci_segments_itera= te(_scan_pci_devices, NULL);=0A+ spin_unlock(&pcidevs_lock);=0A+=0A+ = return ret;=0A+}=0A+=0A /* Disconnect all PCI devices from the PCI buses. = >From the PCI spec:=0A * "When a 0 is written to [the COMMAND] register, = the device is=0A * logically disconnected from the PCI bus for all = accesses except=0A * configuration accesses. All devices are required = to support=0A * this base level of functionality."=0A */=0A-void = disconnect_pci_devices(void)=0A+static int _disconnect_pci_devices(struct = pci_seg *pseg, void *arg)=0A {=0A struct pci_dev *pdev;=0A =0A- = spin_lock(&pcidevs_lock);=0A-=0A- list_for_each_entry ( pdev, &alldevs_l= ist, alldevs_list )=0A+ list_for_each_entry ( pdev, &pseg->alldevs_list,= alldevs_list )=0A pci_conf_write16(pdev->bus, PCI_SLOT(pdev->devfn= ),=0A PCI_FUNC(pdev->devfn), PCI_COMMAND, 0);=0A = =0A+ return 0;=0A+}=0A+=0A+void disconnect_pci_devices(void)=0A+{=0A+ = spin_lock(&pcidevs_lock);=0A+ pci_segments_iterate(_disconnect_pci_devi= ces, NULL);=0A spin_unlock(&pcidevs_lock);=0A }=0A =0A #ifdef = SUPPORT_MSI_REMAPPING=0A-static void dump_pci_devices(unsigned char = ch)=0A+static int _dump_pci_devices(struct pci_seg *pseg, void *arg)=0A = {=0A struct pci_dev *pdev;=0A struct msi_desc *msi;=0A =0A- = printk("=3D=3D=3D=3D PCI devices =3D=3D=3D=3D\n");=0A- spin_lock(&pcidev= s_lock);=0A+ printk("=3D=3D=3D=3D segment %04x =3D=3D=3D=3D\n", = pseg->nr);=0A =0A- list_for_each_entry ( pdev, &alldevs_list, alldevs_li= st )=0A+ list_for_each_entry ( pdev, &pseg->alldevs_list, alldevs_list = )=0A {=0A printk("%02x:%02x.%x - dom %-3d - MSIs < ",=0A = pdev->bus, PCI_SLOT(pdev->devfn), PCI_FUNC(pdev->devfn),=0A@@ = -540,6 +636,14 @@ static void dump_pci_devices(unsigned ch=0A = printk(">\n");=0A }=0A =0A+ return 0;=0A+}=0A+=0A+static void = dump_pci_devices(unsigned char ch)=0A+{=0A+ printk("=3D=3D=3D=3D PCI = devices =3D=3D=3D=3D\n");=0A+ spin_lock(&pcidevs_lock);=0A+ = pci_segments_iterate(_dump_pci_devices, NULL);=0A spin_unlock(&pcidevs_= lock);=0A }=0A =0A--- 2011-08-25.orig/xen/include/xen/iommu.h 2011-08-25 = 08:21:53.000000000 +0200=0A+++ 2011-08-25/xen/include/xen/iommu.h = 2011-08-25 15:06:23.000000000 +0200=0A@@ -92,6 +92,8 @@ void iommu_pte_flus= h(struct domain *d, u=0A void iommu_set_pgd(struct domain *d);=0A void = iommu_domain_teardown(struct domain *d);=0A =0A+void pt_pci_init(void);=0A+= =0A struct pirq;=0A int hvm_do_IRQ_dpci(struct domain *, struct pirq = *);=0A int dpci_ioport_intercept(ioreq_t *p);=0A--- 2011-08-25.orig/xen/inc= lude/xen/pci.h 2011-08-16 08:15:46.000000000 +0200=0A+++ 2011-08-25/xen/in= clude/xen/pci.h 2011-08-25 15:06:23.000000000 +0200=0A@@ -89,6 +89,7 @@ = struct pci_dev *pci_lock_pdev(int bus, i=0A struct pci_dev *pci_lock_domain= _pdev(struct domain *d, int bus, int devfn);=0A =0A void pci_release_device= s(struct domain *d);=0A+int pci_add_segment(u16 seg);=0A int pci_add_device= (u8 bus, u8 devfn, const struct pci_dev_info *);=0A int pci_remove_device(u= 8 bus, u8 devfn);=0A struct pci_dev *pci_get_pdev(int bus, int devfn);=0A --=__Part82ADB972.0__= Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel --=__Part82ADB972.0__=-- From xen-devel-bounces@lists.xensource.com Tue Sep 20 08:19:11 2011 Return-path: <xen-devel-bounces@lists.xensource.com> Envelope-to: www-data@lists.xensource.com Delivery-date: Tue, 20 Sep 2011 08:19:11 -0700 Received: from localhost ([127.0.0.1] helo=lists.colo.xensource.com) by lists.xensource.com with esmtp (Exim 4.43) id 1R626J-0008Hn-0c; Tue, 20 Sep 2011 08:19:11 -0700 Received: from mail21.messagelabs.com ([85.158.143.35]) by lists.xensource.com with esmtp (Exim 4.43) id 1R624M-0007c6-IM for xen-devel@lists.xensource.com; Tue, 20 Sep 2011 08:17:12 -0700 X-Env-Sender: JBeulich@suse.com X-Msg-Ref: server-15.tower-21.messagelabs.com!1316531828!51313830!1 X-Originating-IP: [130.57.49.28] X-StarScan-Version: 6.4.1; banners=-,-,- X-VirusChecked: Checked Received: (qmail 26060 invoked from network); 20 Sep 2011 15:17:08 -0000 Received: from nat28.tlf.novell.com (HELO nat28.tlf.novell.com) (130.57.49.28) by server-15.tower-21.messagelabs.com with DHE-RSA-AES256-SHA encrypted SMTP; 20 Sep 2011 15:17:08 -0000 Received: from EMEA1-MTA by nat28.tlf.novell.com with Novell_GroupWise; Tue, 20 Sep 2011 16:17:06 +0100 Message-Id: <4E78CAAC0200007800056D20@nat28.tlf.novell.com> X-Mailer: Novell GroupWise Internet Agent 8.0.1 Date: Tue, 20 Sep 2011 16:17:32 +0100 From: "Jan Beulich" <JBeulich@suse.com> To: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com> Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="=__Part6C43579C.0__=" Subject: [Xen-devel] [PATCH 2/7] PCI multi-seg: add new physdevop-s X-BeenThere: xen-devel@lists.xensource.com X-Mailman-Version: 2.1.5 Precedence: list List-Id: Xen developer discussion <xen-devel.lists.xensource.com> List-Unsubscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe> List-Post: <mailto:xen-devel@lists.xensource.com> List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help> List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=subscribe> Sender: xen-devel-bounces@lists.xensource.com Errors-To: xen-devel-bounces@lists.xensource.com This is a MIME message. If you are reading this text, you may want to consider changing to a mail reader or gateway that understands how to properly handle MIME multipart messages. --=__Part6C43579C.0__= Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: quoted-printable Content-Disposition: inline The new PHYSDEVOP_pci_device_add is intended to be extensible, with a first extension (to pass the proximity domain of a device) added right away. A couple of directly related functions at once get adjusted to account for the segment number. Should we deprecate the PHYSDEVOP_manage_pci_* sub-hypercalls? Signed-off-by: Jan Beulich <jbeulich@suse.com> --- 2011-09-20.orig/xen/arch/ia64/xen/hypercall.c 2011-07-25 = 09:10:24.000000000 +0200 +++ 2011-09-20/xen/arch/ia64/xen/hypercall.c 2011-08-25 15:06:35.0000000= 00 +0200 @@ -665,7 +665,7 @@ long do_physdev_op(int cmd, XEN_GUEST_HA if ( copy_from_guest(&manage_pci, arg, 1) !=3D 0 ) break; =20 - ret =3D pci_add_device(manage_pci.bus, manage_pci.devfn, NULL); + ret =3D pci_add_device(0, manage_pci.bus, manage_pci.devfn, = NULL); break; } =20 @@ -678,7 +678,7 @@ long do_physdev_op(int cmd, XEN_GUEST_HA if ( copy_from_guest(&manage_pci, arg, 1) !=3D 0 ) break; =20 - ret =3D pci_remove_device(manage_pci.bus, manage_pci.devfn); + ret =3D pci_remove_device(0, manage_pci.bus, manage_pci.devfn); break; } =20 @@ -698,7 +698,7 @@ long do_physdev_op(int cmd, XEN_GUEST_HA pdev_info.is_virtfn =3D manage_pci_ext.is_virtfn; pdev_info.physfn.bus =3D manage_pci_ext.physfn.bus; pdev_info.physfn.devfn =3D manage_pci_ext.physfn.devfn; - ret =3D pci_add_device(manage_pci_ext.bus, + ret =3D pci_add_device(0, manage_pci_ext.bus, manage_pci_ext.devfn, &pdev_info); break; --- 2011-09-20.orig/xen/arch/x86/irq.c 2011-09-15 09:03:15.000000000 = +0200 +++ 2011-09-20/xen/arch/x86/irq.c 2011-09-20 16:03:51.000000000 = +0200 @@ -1715,7 +1715,7 @@ int map_domain_pirq( if ( !cpu_has_apic ) goto done; =20 - pdev =3D pci_get_pdev(msi->bus, msi->devfn); + pdev =3D pci_get_pdev(msi->seg, msi->bus, msi->devfn); ret =3D pci_enable_msi(msi, &msi_desc); if ( ret ) goto done; --- 2011-09-20.orig/xen/arch/x86/msi.c 2011-09-05 09:12:30.000000000 = +0200 +++ 2011-09-20/xen/arch/x86/msi.c 2011-08-25 15:06:35.000000000 = +0200 @@ -528,7 +528,7 @@ static u64 read_pci_mem_bar(u8 bus, u8 s =20 if ( vf >=3D 0 ) { - struct pci_dev *pdev =3D pci_get_pdev(bus, PCI_DEVFN(slot, = func)); + struct pci_dev *pdev =3D pci_get_pdev(0, bus, PCI_DEVFN(slot, = func)); unsigned int pos =3D pci_find_ext_capability(0, bus, PCI_DEVFN(slot, func), PCI_EXT_CAP_ID_SRIOV); @@ -767,7 +767,7 @@ static int __pci_enable_msi(struct msi_i struct msi_desc *old_desc; =20 ASSERT(spin_is_locked(&pcidevs_lock)); - pdev =3D pci_get_pdev(msi->bus, msi->devfn); + pdev =3D pci_get_pdev(msi->seg, msi->bus, msi->devfn); if ( !pdev ) return -ENODEV; =20 @@ -775,7 +775,8 @@ static int __pci_enable_msi(struct msi_i if ( old_desc ) { dprintk(XENLOG_WARNING, "irq %d has already mapped to MSI on " - "device %02x:%02x.%01x.\n", msi->irq, msi->bus, + "device %04x:%02x:%02x.%01x\n", + msi->irq, msi->seg, msi->bus, PCI_SLOT(msi->devfn), PCI_FUNC(msi->devfn)); *desc =3D old_desc; return 0; @@ -785,7 +786,7 @@ static int __pci_enable_msi(struct msi_i if ( old_desc ) { dprintk(XENLOG_WARNING, "MSI-X is already in use on " - "device %02x:%02x.%01x\n", msi->bus, + "device %04x:%02x:%02x.%01x\n", msi->seg, msi->bus, PCI_SLOT(msi->devfn), PCI_FUNC(msi->devfn)); pci_disable_msi(old_desc); } @@ -830,7 +831,7 @@ static int __pci_enable_msix(struct msi_ struct msi_desc *old_desc; =20 ASSERT(spin_is_locked(&pcidevs_lock)); - pdev =3D pci_get_pdev(msi->bus, msi->devfn); + pdev =3D pci_get_pdev(msi->seg, msi->bus, msi->devfn); if ( !pdev ) return -ENODEV; =20 @@ -844,7 +845,8 @@ static int __pci_enable_msix(struct msi_ if ( old_desc ) { dprintk(XENLOG_WARNING, "irq %d has already mapped to MSIX on " - "device %02x:%02x.%01x.\n", msi->irq, msi->bus, + "device %04x:%02x:%02x.%01x\n", + msi->irq, msi->seg, msi->bus, PCI_SLOT(msi->devfn), PCI_FUNC(msi->devfn)); *desc =3D old_desc; return 0; @@ -854,7 +856,7 @@ static int __pci_enable_msix(struct msi_ if ( old_desc ) { dprintk(XENLOG_WARNING, "MSI is already in use on " - "device %02x:%02x.%01x\n", msi->bus, + "device %04x:%02x:%02x.%01x\n", msi->seg, msi->bus, PCI_SLOT(msi->devfn), PCI_FUNC(msi->devfn)); pci_disable_msi(old_desc); =20 @@ -962,8 +964,10 @@ int pci_restore_msi_state(struct pci_dev =20 if (desc->msi_desc !=3D entry) { - dprintk(XENLOG_ERR, "Restore MSI for dev %x:%x not set = before?\n", - pdev->bus, pdev->devfn); + dprintk(XENLOG_ERR, + "Restore MSI for dev %04x:%02x:%02x:%x not set = before?\n", + pdev->seg, pdev->bus, PCI_SLOT(pdev->devfn), + PCI_FUNC(pdev->devfn)); spin_unlock_irqrestore(&desc->lock, flags); return -EINVAL; } --- 2011-09-20.orig/xen/arch/x86/physdev.c 2011-09-05 09:12:30.0000000= 00 +0200 +++ 2011-09-20/xen/arch/x86/physdev.c 2011-09-20 16:03:39.000000000 = +0200 @@ -357,6 +357,15 @@ ret_t do_physdev_op(int cmd, XEN_GUEST_H if ( copy_from_guest(&map, arg, 1) !=3D 0 ) break; =20 + if ( map.type =3D=3D MAP_PIRQ_TYPE_MSI_SEG ) + { + map.type =3D MAP_PIRQ_TYPE_MSI; + msi.seg =3D map.bus >> 16; + } + else + { + msi.seg =3D 0; + } msi.bus =3D map.bus; msi.devfn =3D map.devfn; msi.entry_nr =3D map.entry_nr; @@ -480,7 +489,7 @@ ret_t do_physdev_op(int cmd, XEN_GUEST_H if ( copy_from_guest(&manage_pci, arg, 1) !=3D 0 ) break; =20 - ret =3D pci_add_device(manage_pci.bus, manage_pci.devfn, NULL); + ret =3D pci_add_device(0, manage_pci.bus, manage_pci.devfn, = NULL); break; } =20 @@ -493,7 +502,7 @@ ret_t do_physdev_op(int cmd, XEN_GUEST_H if ( copy_from_guest(&manage_pci, arg, 1) !=3D 0 ) break; =20 - ret =3D pci_remove_device(manage_pci.bus, manage_pci.devfn); + ret =3D pci_remove_device(0, manage_pci.bus, manage_pci.devfn); break; } =20 @@ -517,12 +526,52 @@ ret_t do_physdev_op(int cmd, XEN_GUEST_H pdev_info.is_virtfn =3D manage_pci_ext.is_virtfn; pdev_info.physfn.bus =3D manage_pci_ext.physfn.bus; pdev_info.physfn.devfn =3D manage_pci_ext.physfn.devfn; - ret =3D pci_add_device(manage_pci_ext.bus, + ret =3D pci_add_device(0, manage_pci_ext.bus, manage_pci_ext.devfn, &pdev_info); break; } =20 + case PHYSDEVOP_pci_device_add: { + struct physdev_pci_device_add add; + struct pci_dev_info pdev_info; + + ret =3D -EPERM; + if ( !IS_PRIV(current->domain) ) + break; + + ret =3D -EFAULT; + if ( copy_from_guest(&add, arg, 1) !=3D 0 ) + break; + + pdev_info.is_extfn =3D !!(add.flags & XEN_PCI_DEV_EXTFN); + if ( add.flags & XEN_PCI_DEV_VIRTFN ) + { + pdev_info.is_virtfn =3D 1; + pdev_info.physfn.bus =3D add.physfn.bus; + pdev_info.physfn.devfn =3D add.physfn.devfn; + } + else + pdev_info.is_virtfn =3D 0; + ret =3D pci_add_device(add.seg, add.bus, add.devfn, &pdev_info); + break; + } + + case PHYSDEVOP_pci_device_remove: { + struct physdev_pci_device dev; + + ret =3D -EPERM; + if ( !IS_PRIV(v->domain) ) + break; + + ret =3D -EFAULT; + if ( copy_from_guest(&dev, arg, 1) !=3D 0 ) + break; + + ret =3D pci_remove_device(dev.seg, dev.bus, dev.devfn); + break; + } + #ifdef __x86_64__ case PHYSDEVOP_pci_mmcfg_reserved: { struct physdev_pci_mmcfg_reserved info; @@ -554,11 +603,31 @@ ret_t do_physdev_op(int cmd, XEN_GUEST_H break; =20 spin_lock(&pcidevs_lock); - pdev =3D pci_get_pdev(restore_msi.bus, restore_msi.devfn); + pdev =3D pci_get_pdev(0, restore_msi.bus, restore_msi.devfn); + ret =3D pdev ? pci_restore_msi_state(pdev) : -ENODEV; + spin_unlock(&pcidevs_lock); + break; + } + + case PHYSDEVOP_restore_msi_ext: { + struct physdev_pci_device dev; + struct pci_dev *pdev; + + ret =3D -EPERM; + if ( !IS_PRIV(v->domain) ) + break; + + ret =3D -EFAULT; + if ( copy_from_guest(&dev, arg, 1) !=3D 0 ) + break; + + spin_lock(&pcidevs_lock); + pdev =3D pci_get_pdev(dev.seg, dev.bus, dev.devfn); ret =3D pdev ? pci_restore_msi_state(pdev) : -ENODEV; spin_unlock(&pcidevs_lock); break; } + case PHYSDEVOP_setup_gsi: { struct physdev_setup_gsi setup_gsi; =20 --- 2011-09-20.orig/xen/arch/x86/x86_64/physdev.c 2011-08-08 = 08:29:50.000000000 +0200 +++ 2011-09-20/xen/arch/x86/x86_64/physdev.c 2011-08-25 15:06:35.0000000= 00 +0200 @@ -67,6 +67,14 @@ CHECK_physdev_get_free_pirq; CHECK_physdev_pci_mmcfg_reserved; #undef xen_physdev_pci_mmcfg_reserved =20 +#define xen_physdev_pci_device_add physdev_pci_device_add +CHECK_physdev_pci_device_add +#undef xen_physdev_pci_device_add + +#define xen_physdev_pci_device physdev_pci_device +CHECK_physdev_pci_device +#undef xen_physdev_pci_device + #define COMPAT #undef guest_handle_okay #define guest_handle_okay compat_handle_okay --- 2011-09-20.orig/xen/drivers/passthrough/amd/pci_amd_iommu.c 2011-09-12 = 08:34:38.000000000 +0200 +++ 2011-09-20/xen/drivers/passthrough/amd/pci_amd_iommu.c 2011-09-20 = 16:03:27.000000000 +0200 @@ -131,7 +131,7 @@ static void __init amd_iommu_setup_dom0_ { for ( devfn =3D 0; devfn < 256; devfn++ ) { - pdev =3D pci_get_pdev(bus, devfn); + pdev =3D pci_get_pdev(0, bus, devfn); if ( !pdev ) continue; =20 @@ -313,7 +313,7 @@ static int reassign_device( struct domai struct hvm_iommu *t =3D domain_hvm_iommu(target); =20 ASSERT(spin_is_locked(&pcidevs_lock)); - pdev =3D pci_get_pdev_by_domain(source, bus, devfn); + pdev =3D pci_get_pdev_by_domain(source, 0, bus, devfn); if ( !pdev ) return -ENODEV; =20 --- 2011-09-20.orig/xen/drivers/passthrough/iommu.c 2011-09-05 = 09:12:30.000000000 +0200 +++ 2011-09-20/xen/drivers/passthrough/iommu.c 2011-08-25 15:06:35.0000000= 00 +0200 @@ -282,7 +282,7 @@ int deassign_device(struct domain *d, u8 return -EINVAL; =20 ASSERT(spin_is_locked(&pcidevs_lock)); - pdev =3D pci_get_pdev(bus, devfn); + pdev =3D pci_get_pdev(0, bus, devfn); if ( !pdev ) return -ENODEV; =20 --- 2011-09-20.orig/xen/drivers/passthrough/pci.c 2011-08-25 = 15:06:23.000000000 +0200 +++ 2011-09-20/xen/drivers/passthrough/pci.c 2011-08-25 15:06:35.0000000= 00 +0200 @@ -121,6 +121,7 @@ static struct pci_dev *alloc_pdev(struct return NULL; memset(pdev, 0, sizeof(struct pci_dev)); =20 + *(u16*) &pdev->seg =3D pseg->nr; *((u8*) &pdev->bus) =3D bus; *((u8*) &pdev->devfn) =3D devfn; pdev->domain =3D NULL; @@ -137,41 +138,59 @@ static void free_pdev(struct pci_dev *pd xfree(pdev); } =20 -struct pci_dev *pci_get_pdev(int bus, int devfn) +struct pci_dev *pci_get_pdev(int seg, int bus, int devfn) { - struct pci_seg *pseg =3D get_pseg(0); + struct pci_seg *pseg =3D get_pseg(seg); struct pci_dev *pdev =3D NULL; =20 ASSERT(spin_is_locked(&pcidevs_lock)); + ASSERT(seg !=3D -1 || bus =3D=3D -1); + ASSERT(bus !=3D -1 || devfn =3D=3D -1); =20 if ( !pseg ) - return NULL; + { + if ( seg =3D=3D -1 ) + radix_tree_gang_lookup(&pci_segments, (void **)&pseg, 0, 1); + if ( !pseg ) + return NULL; + } =20 - list_for_each_entry ( pdev, &pseg->alldevs_list, alldevs_list ) - if ( (pdev->bus =3D=3D bus || bus =3D=3D -1) && - (pdev->devfn =3D=3D devfn || devfn =3D=3D -1) ) - { - return pdev; - } + do { + list_for_each_entry ( pdev, &pseg->alldevs_list, alldevs_list ) + if ( (pdev->bus =3D=3D bus || bus =3D=3D -1) && + (pdev->devfn =3D=3D devfn || devfn =3D=3D -1) ) + return pdev; + } while ( radix_tree_gang_lookup(&pci_segments, (void **)&pseg, + pseg->nr + 1, 1) ); =20 return NULL; } =20 -struct pci_dev *pci_get_pdev_by_domain(struct domain *d, int bus, int = devfn) +struct pci_dev *pci_get_pdev_by_domain( + struct domain *d, int seg, int bus, int devfn) { - struct pci_seg *pseg =3D get_pseg(0); + struct pci_seg *pseg =3D get_pseg(seg); struct pci_dev *pdev =3D NULL; =20 + ASSERT(seg !=3D -1 || bus =3D=3D -1); + ASSERT(bus !=3D -1 || devfn =3D=3D -1); + if ( !pseg ) - return NULL; + { + if ( seg =3D=3D -1 ) + radix_tree_gang_lookup(&pci_segments, (void **)&pseg, 0, 1); + if ( !pseg ) + return NULL; + } =20 - list_for_each_entry ( pdev, &pseg->alldevs_list, alldevs_list ) - if ( (pdev->bus =3D=3D bus || bus =3D=3D -1) && - (pdev->devfn =3D=3D devfn || devfn =3D=3D -1) && - (pdev->domain =3D=3D d) ) - { - return pdev; - } + do { + list_for_each_entry ( pdev, &pseg->alldevs_list, alldevs_list ) + if ( (pdev->bus =3D=3D bus || bus =3D=3D -1) && + (pdev->devfn =3D=3D devfn || devfn =3D=3D -1) && + (pdev->domain =3D=3D d) ) + return pdev; + } while ( radix_tree_gang_lookup(&pci_segments, (void **)&pseg, + pseg->nr + 1, 1) ); =20 return NULL; } @@ -215,7 +234,7 @@ void pci_enable_acs(struct pci_dev *pdev pci_conf_write16(bus, dev, func, pos + PCI_ACS_CTRL, ctrl); } =20 -int pci_add_device(u8 bus, u8 devfn, const struct pci_dev_info *info) +int pci_add_device(u16 seg, u8 bus, u8 devfn, const struct pci_dev_info = *info) { struct pci_seg *pseg; struct pci_dev *pdev; @@ -230,17 +249,20 @@ int pci_add_device(u8 bus, u8 devfn, con else if (info->is_virtfn) { spin_lock(&pcidevs_lock); - pdev =3D pci_get_pdev(info->physfn.bus, info->physfn.devfn); + pdev =3D pci_get_pdev(seg, info->physfn.bus, info->physfn.devfn); spin_unlock(&pcidevs_lock); if ( !pdev ) - pci_add_device(info->physfn.bus, info->physfn.devfn, NULL); + pci_add_device(seg, info->physfn.bus, info->physfn.devfn, = NULL); pdev_type =3D "virtual function"; } else - return -EINVAL; + { + info =3D NULL; + pdev_type =3D "device"; + } =20 spin_lock(&pcidevs_lock); - pseg =3D alloc_pseg(0); + pseg =3D alloc_pseg(seg); if ( !pseg ) goto out; pdev =3D alloc_pdev(pseg, bus, devfn); @@ -251,7 +273,7 @@ int pci_add_device(u8 bus, u8 devfn, con pdev->info =3D *info; else if ( !pdev->vf_rlen[0] ) { - unsigned int pos =3D pci_find_ext_capability(0, bus, devfn, + unsigned int pos =3D pci_find_ext_capability(seg, bus, devfn, PCI_EXT_CAP_ID_SRIOV); u16 ctrl =3D pci_conf_read16(bus, slot, func, pos + PCI_SRIOV_CTRL= ); =20 @@ -271,9 +293,10 @@ int pci_add_device(u8 bus, u8 devfn, con if ( (bar & PCI_BASE_ADDRESS_SPACE) =3D=3D PCI_BASE_ADDRESS_SPACE_IO ) { - printk(XENLOG_WARNING "SR-IOV device %02x:%02x.%x = with vf" - " BAR%u in IO space\n", - bus, slot, func, i); + printk(XENLOG_WARNING + "SR-IOV device %04x:%02x:%02x.%u with vf = BAR%u" + " in IO space\n", + seg, bus, slot, func, i); continue; } pci_conf_write32(bus, slot, func, idx, ~0); @@ -282,9 +305,10 @@ int pci_add_device(u8 bus, u8 devfn, con { if ( i >=3D PCI_SRIOV_NUM_BARS ) { - printk(XENLOG_WARNING "SR-IOV device %02x:%02x.%x = with" - " 64-bit vf BAR in last = slot\n", - bus, slot, func); + printk(XENLOG_WARNING + "SR-IOV device %04x:%02x:%02x.%u with = 64-bit" + " vf BAR in last slot\n", + seg, bus, slot, func); break; } hi =3D pci_conf_read32(bus, slot, func, idx + 4); @@ -309,9 +333,10 @@ int pci_add_device(u8 bus, u8 devfn, con } } else - printk(XENLOG_WARNING "SR-IOV device %02x:%02x.%x has its = virtual" - " functions already enabled (%04x)\n", - bus, slot, func, ctrl); + printk(XENLOG_WARNING + "SR-IOV device %04x:%02x:%02x.%u has its virtual" + " functions already enabled (%04x)\n", + seg, bus, slot, func, ctrl); } =20 ret =3D 0; @@ -331,14 +356,14 @@ int pci_add_device(u8 bus, u8 devfn, con =20 out: spin_unlock(&pcidevs_lock); - printk(XENLOG_DEBUG "PCI add %s %02x:%02x.%x\n", pdev_type, - bus, slot, func); + printk(XENLOG_DEBUG "PCI add %s %04x:%02x:%02x.%u\n", pdev_type, + seg, bus, slot, func); return ret; } =20 -int pci_remove_device(u8 bus, u8 devfn) +int pci_remove_device(u16 seg, u8 bus, u8 devfn) { - struct pci_seg *pseg =3D get_pseg(0); + struct pci_seg *pseg =3D get_pseg(seg); struct pci_dev *pdev; int ret =3D -ENODEV; =20 @@ -354,8 +379,8 @@ int pci_remove_device(u8 bus, u8 devfn) list_del(&pdev->domain_list); pci_cleanup_msi(pdev); free_pdev(pdev); - printk(XENLOG_DEBUG "PCI remove device %02x:%02x.%x\n", bus, - PCI_SLOT(devfn), PCI_FUNC(devfn)); + printk(XENLOG_DEBUG "PCI remove device %04x:%02x:%02x.%u\n", + seg, bus, PCI_SLOT(devfn), PCI_FUNC(devfn)); break; } =20 @@ -413,7 +438,7 @@ void pci_release_devices(struct domain * =20 spin_lock(&pcidevs_lock); pci_clean_dpci_irqs(d); - while ( (pdev =3D pci_get_pdev_by_domain(d, -1, -1)) ) + while ( (pdev =3D pci_get_pdev_by_domain(d, -1, -1, -1)) ) { pci_cleanup_msi(pdev); bus =3D pdev->bus; devfn =3D pdev->devfn; --- 2011-09-20.orig/xen/drivers/passthrough/vtd/iommu.c 2011-09-12 = 08:34:38.000000000 +0200 +++ 2011-09-20/xen/drivers/passthrough/vtd/iommu.c 2011-09-20 = 16:03:17.000000000 +0200 @@ -280,7 +280,7 @@ static u64 addr_to_dma_page_maddr(struct * just get any passthrough device in the domainr - assume user * assigns only devices from same node to a given guest. */ - pdev =3D pci_get_pdev_by_domain(domain, -1, -1); + pdev =3D pci_get_pdev_by_domain(domain, -1, -1, -1); drhd =3D acpi_find_matched_drhd_unit(pdev); if ( !alloc || ((hd->pgd_maddr =3D alloc_pgtable_maddr(drhd, 1)) = =3D=3D 0) ) goto out; @@ -297,7 +297,7 @@ static u64 addr_to_dma_page_maddr(struct if ( !alloc ) break; =20 - pdev =3D pci_get_pdev_by_domain(domain, -1, -1); + pdev =3D pci_get_pdev_by_domain(domain, -1, -1, -1); drhd =3D acpi_find_matched_drhd_unit(pdev); maddr =3D alloc_pgtable_maddr(drhd, 1); if ( !maddr ) @@ -1273,7 +1273,7 @@ int domain_context_mapping_one( =20 /* First try to get domain ownership from device structure. If = that's * not available, try to read it from the context itself. */ - pdev =3D pci_get_pdev(bus, devfn); + pdev =3D pci_get_pdev(0, bus, devfn); if ( pdev ) { if ( pdev->domain !=3D domain ) @@ -1396,7 +1396,7 @@ static int domain_context_mapping(struct int ret =3D 0; u32 type; u8 secbus; - struct pci_dev *pdev =3D pci_get_pdev(bus, devfn); + struct pci_dev *pdev =3D pci_get_pdev(0, bus, devfn); =20 drhd =3D acpi_find_matched_drhd_unit(pdev); if ( !drhd ) @@ -1521,7 +1521,7 @@ static int domain_context_unmap(struct d int ret =3D 0; u32 type; u8 tmp_bus, tmp_devfn, secbus; - struct pci_dev *pdev =3D pci_get_pdev(bus, devfn); + struct pci_dev *pdev =3D pci_get_pdev(0, bus, devfn); int found =3D 0; =20 BUG_ON(!pdev); @@ -1632,7 +1632,7 @@ static int reassign_device_ownership( int ret; =20 ASSERT(spin_is_locked(&pcidevs_lock)); - pdev =3D pci_get_pdev_by_domain(source, bus, devfn); + pdev =3D pci_get_pdev_by_domain(source, 0, bus, devfn); =20 if (!pdev) return -ENODEV; @@ -1941,7 +1941,7 @@ static void __init setup_dom0_devices(st { for ( devfn =3D 0; devfn < 256; devfn++ ) { - pdev =3D pci_get_pdev(bus, devfn); + pdev =3D pci_get_pdev(0, bus, devfn); if ( !pdev ) continue; =20 @@ -2175,7 +2175,7 @@ int device_assigned(u8 bus, u8 devfn) struct pci_dev *pdev; =20 spin_lock(&pcidevs_lock); - pdev =3D pci_get_pdev_by_domain(dom0, bus, devfn); + pdev =3D pci_get_pdev_by_domain(dom0, 0, bus, devfn); if (!pdev) { spin_unlock(&pcidevs_lock); @@ -2197,7 +2197,7 @@ static int intel_iommu_assign_device(str return -ENODEV; =20 ASSERT(spin_is_locked(&pcidevs_lock)); - pdev =3D pci_get_pdev(bus, devfn); + pdev =3D pci_get_pdev(0, bus, devfn); if (!pdev) return -ENODEV; =20 --- 2011-09-20.orig/xen/drivers/passthrough/vtd/quirks.c 2011-03-11 = 10:13:55.000000000 +0100 +++ 2011-09-20/xen/drivers/passthrough/vtd/quirks.c 2011-08-25 = 15:06:35.000000000 +0200 @@ -286,7 +286,7 @@ static void map_me_phantom_function(stru struct pci_dev *pdev; =20 /* find ME VT-d engine base on a real ME device */ - pdev =3D pci_get_pdev(0, PCI_DEVFN(dev, 0)); + pdev =3D pci_get_pdev(0, 0, PCI_DEVFN(dev, 0)); drhd =3D acpi_find_matched_drhd_unit(pdev); =20 /* map or unmap ME phantom function */ --- 2011-09-20.orig/xen/drivers/passthrough/vtd/x86/ats.c 2011-03-31 = 08:50:59.000000000 +0200 +++ 2011-09-20/xen/drivers/passthrough/vtd/x86/ats.c 2011-08-25 = 15:06:35.000000000 +0200 @@ -37,6 +37,7 @@ static LIST_HEAD(ats_dev_drhd_units); =20 struct pci_ats_dev { struct list_head list; + u16 seg; u8 bus; u8 devfn; u16 ats_queue_depth; /* ATS device invalidation queue depth */ @@ -91,7 +92,7 @@ int ats_device(int seg, int bus, int dev if ( !ats_enabled || !iommu_qinval ) return 0; =20 - pdev =3D pci_get_pdev(bus, devfn); + pdev =3D pci_get_pdev(seg, bus, devfn); if ( !pdev ) return 0; =20 @@ -130,8 +131,9 @@ int enable_ats_device(int seg, int bus,=20 BUG_ON(!pos); =20 if ( iommu_verbose ) - dprintk(XENLOG_INFO VTDPREFIX, "%x:%x.%x: ATS capability = found\n", - bus, PCI_SLOT(devfn), PCI_FUNC(devfn)); + dprintk(XENLOG_INFO VTDPREFIX, + "%04x:%02x:%02x.%u: ATS capability found\n", + seg, bus, PCI_SLOT(devfn), PCI_FUNC(devfn)); =20 /* BUGBUG: add back seg when multi-seg platform support is enabled */ value =3D pci_conf_read16(bus, PCI_SLOT(devfn), @@ -140,7 +142,7 @@ int enable_ats_device(int seg, int bus,=20 { list_for_each_entry ( pdev, &ats_devices, list ) { - if ( pdev->bus =3D=3D bus && pdev->devfn =3D=3D devfn ) + if ( pdev->seg =3D=3D seg && pdev->bus =3D=3D bus && = pdev->devfn =3D=3D devfn ) { pos =3D 0; break; @@ -161,6 +163,7 @@ int enable_ats_device(int seg, int bus,=20 =20 if ( pos ) { + pdev->seg =3D seg; pdev->bus =3D bus; pdev->devfn =3D devfn; value =3D pci_conf_read16(bus, PCI_SLOT(devfn), @@ -170,8 +173,10 @@ int enable_ats_device(int seg, int bus,=20 } =20 if ( iommu_verbose ) - dprintk(XENLOG_INFO VTDPREFIX, "%x:%x.%x: ATS %s enabled\n", - bus, PCI_SLOT(devfn), PCI_FUNC(devfn), pos ? "is" : = "was"); + dprintk(XENLOG_INFO VTDPREFIX, + "%04x:%02x:%02x.%u: ATS %s enabled\n", + seg, bus, PCI_SLOT(devfn), PCI_FUNC(devfn), + pos ? "is" : "was"); =20 return pos; } @@ -194,7 +199,7 @@ void disable_ats_device(int seg, int bus =20 list_for_each_entry ( pdev, &ats_devices, list ) { - if ( pdev->bus =3D=3D bus && pdev->devfn =3D=3D devfn ) + if ( pdev->seg =3D=3D seg && pdev->bus =3D=3D bus && pdev->devfn = =3D=3D devfn ) { list_del(&pdev->list); xfree(pdev); @@ -203,8 +208,9 @@ void disable_ats_device(int seg, int bus } =20 if ( iommu_verbose ) - dprintk(XENLOG_INFO VTDPREFIX, "%x:%x.%x: ATS is disabled\n", - bus, PCI_SLOT(devfn), PCI_FUNC(devfn)); + dprintk(XENLOG_INFO VTDPREFIX, + "%04x:%02x:%02x.%u: ATS is disabled\n", + seg, bus, PCI_SLOT(devfn), PCI_FUNC(devfn)); } =20 =20 --- 2011-09-20.orig/xen/include/asm-x86/msi.h 2011-09-05 09:12:30.0000000= 00 +0200 +++ 2011-09-20/xen/include/asm-x86/msi.h 2011-08-25 15:06:35.0000000= 00 +0200 @@ -59,8 +59,9 @@ #endif =20 struct msi_info { - int bus; - int devfn; + u16 seg; + u8 bus; + u8 devfn; int irq; int entry_nr; uint64_t table_base; --- 2011-09-20.orig/xen/include/public/physdev.h 2011-08-08 = 08:29:50.000000000 +0200 +++ 2011-09-20/xen/include/public/physdev.h 2011-08-25 15:06:35.0000000= 00 +0200 @@ -142,6 +142,7 @@ DEFINE_XEN_GUEST_HANDLE(physdev_irq_t); #define MAP_PIRQ_TYPE_MSI 0x0 #define MAP_PIRQ_TYPE_GSI 0x1 #define MAP_PIRQ_TYPE_UNKNOWN 0x2 +#define MAP_PIRQ_TYPE_MSI_SEG 0x3 =20 #define PHYSDEVOP_map_pirq 13 struct physdev_map_pirq { @@ -152,7 +153,7 @@ struct physdev_map_pirq { int index; /* IN or OUT */ int pirq; - /* IN */ + /* IN - high 16 bits hold segment for MAP_PIRQ_TYPE_MSI_SEG */ int bus; /* IN */ int devfn; @@ -268,6 +269,41 @@ struct physdev_pci_mmcfg_reserved { typedef struct physdev_pci_mmcfg_reserved physdev_pci_mmcfg_reserved_t; DEFINE_XEN_GUEST_HANDLE(physdev_pci_mmcfg_reserved_t); =20 +#define XEN_PCI_DEV_EXTFN 0x1 +#define XEN_PCI_DEV_VIRTFN 0x2 +#define XEN_PCI_DEV_PXM 0x4 + +#define PHYSDEVOP_pci_device_add 25 +struct physdev_pci_device_add { + /* IN */ + uint16_t seg; + uint8_t bus; + uint8_t devfn; + uint32_t flags; + struct { + uint8_t bus; + uint8_t devfn; + } physfn; +#if defined(__STDC_VERSION__) && __STDC_VERSION__ >=3D 199901L + uint32_t optarr[]; +#elif defined(__GNUC__) + uint32_t optarr[0]; +#endif +}; +typedef struct physdev_pci_device_add physdev_pci_device_add_t; +DEFINE_XEN_GUEST_HANDLE(physdev_pci_device_add_t); + +#define PHYSDEVOP_pci_device_remove 26 +#define PHYSDEVOP_restore_msi_ext 27 +struct physdev_pci_device { + /* IN */ + uint16_t seg; + uint8_t bus; + uint8_t devfn; +}; +typedef struct physdev_pci_device physdev_pci_device_t; +DEFINE_XEN_GUEST_HANDLE(physdev_pci_device_t); + /* * Notify that some PIRQ-bound event channels have been unmasked. * ** This command is obsolete since interface version 0x00030202 and is = ** --- 2011-09-20.orig/xen/include/xen/pci.h 2011-08-25 15:06:23.0000000= 00 +0200 +++ 2011-09-20/xen/include/xen/pci.h 2011-08-25 15:06:35.000000000 = +0200 @@ -56,6 +56,7 @@ struct pci_dev { spinlock_t msix_table_lock; =20 struct domain *domain; + const u16 seg; const u8 bus; const u8 devfn; struct pci_dev_info info; @@ -90,10 +91,11 @@ struct pci_dev *pci_lock_domain_pdev(str =20 void pci_release_devices(struct domain *d); int pci_add_segment(u16 seg); -int pci_add_device(u8 bus, u8 devfn, const struct pci_dev_info *); -int pci_remove_device(u8 bus, u8 devfn); -struct pci_dev *pci_get_pdev(int bus, int devfn); -struct pci_dev *pci_get_pdev_by_domain(struct domain *d, int bus, int = devfn); +int pci_add_device(u16 seg, u8 bus, u8 devfn, const struct pci_dev_info = *); +int pci_remove_device(u16 seg, u8 bus, u8 devfn); +struct pci_dev *pci_get_pdev(int seg, int bus, int devfn); +struct pci_dev *pci_get_pdev_by_domain( + struct domain *, int seg, int bus, int devfn); =20 void disconnect_pci_devices(void); =20 --- 2011-09-20.orig/xen/include/xlat.lst 2011-08-08 08:29:50.0000000= 00 +0200 +++ 2011-09-20/xen/include/xlat.lst 2011-08-25 15:06:35.000000000 = +0200 @@ -65,6 +65,8 @@ ? physdev_irq_status_query physdev.h ? physdev_manage_pci physdev.h ? physdev_manage_pci_ext physdev.h +? physdev_pci_device physdev.h +? physdev_pci_device_add physdev.h ? physdev_pci_mmcfg_reserved physdev.h ? physdev_unmap_pirq physdev.h ? physdev_restore_msi physdev.h --=__Part6C43579C.0__= Content-Type: text/plain; name="pci-multi-seg-physdevop.patch" Content-Transfer-Encoding: quoted-printable Content-Disposition: attachment; filename="pci-multi-seg-physdevop.patch" The new PHYSDEVOP_pci_device_add is intended to be extensible, with = a=0Afirst extension (to pass the proximity domain of a device) added = right=0Aaway.=0A=0AA couple of directly related functions at once get = adjusted to account=0Afor the segment number.=0A=0AShould we deprecate the = PHYSDEVOP_manage_pci_* sub-hypercalls?=0A=0ASigned-off-by: Jan Beulich = <jbeulich@suse.com>=0A=0A--- 2011-09-20.orig/xen/arch/ia64/xen/hypercall.c = 2011-07-25 09:10:24.000000000 +0200=0A+++ 2011-09-20/xen/arch/ia64/xen/hype= rcall.c 2011-08-25 15:06:35.000000000 +0200=0A@@ -665,7 +665,7 @@ long = do_physdev_op(int cmd, XEN_GUEST_HA=0A if ( copy_from_guest(&manage= _pci, arg, 1) !=3D 0 )=0A break;=0A =0A- ret =3D = pci_add_device(manage_pci.bus, manage_pci.devfn, NULL);=0A+ ret =3D = pci_add_device(0, manage_pci.bus, manage_pci.devfn, NULL);=0A = break;=0A }=0A =0A@@ -678,7 +678,7 @@ long do_physdev_op(int cmd, = XEN_GUEST_HA=0A if ( copy_from_guest(&manage_pci, arg, 1) !=3D 0 = )=0A break;=0A =0A- ret =3D pci_remove_device(manage_pci= .bus, manage_pci.devfn);=0A+ ret =3D pci_remove_device(0, manage_pci= .bus, manage_pci.devfn);=0A break;=0A }=0A =0A@@ -698,7 = +698,7 @@ long do_physdev_op(int cmd, XEN_GUEST_HA=0A pdev_info.is_= virtfn =3D manage_pci_ext.is_virtfn;=0A pdev_info.physfn.bus =3D = manage_pci_ext.physfn.bus;=0A pdev_info.physfn.devfn =3D manage_pci= _ext.physfn.devfn;=0A- ret =3D pci_add_device(manage_pci_ext.bus,=0A= + ret =3D pci_add_device(0, manage_pci_ext.bus,=0A = manage_pci_ext.devfn,=0A = &pdev_info);=0A break;=0A--- 2011-09-20.orig/xen/arch/x86/irq.c = 2011-09-15 09:03:15.000000000 +0200=0A+++ 2011-09-20/xen/arch/x86/irq.c = 2011-09-20 16:03:51.000000000 +0200=0A@@ -1715,7 +1715,7 @@ int map_domain_= pirq(=0A if ( !cpu_has_apic )=0A goto done;=0A =0A- = pdev =3D pci_get_pdev(msi->bus, msi->devfn);=0A+ pdev =3D = pci_get_pdev(msi->seg, msi->bus, msi->devfn);=0A ret =3D pci_enable= _msi(msi, &msi_desc);=0A if ( ret )=0A goto done;=0A---= 2011-09-20.orig/xen/arch/x86/msi.c 2011-09-05 09:12:30.000000000 = +0200=0A+++ 2011-09-20/xen/arch/x86/msi.c 2011-08-25 15:06:35.0000000= 00 +0200=0A@@ -528,7 +528,7 @@ static u64 read_pci_mem_bar(u8 bus, u8 s=0A = =0A if ( vf >=3D 0 )=0A {=0A- struct pci_dev *pdev =3D = pci_get_pdev(bus, PCI_DEVFN(slot, func));=0A+ struct pci_dev *pdev = =3D pci_get_pdev(0, bus, PCI_DEVFN(slot, func));=0A unsigned int = pos =3D pci_find_ext_capability(0, bus,=0A = PCI_DEVFN(slot, func),=0A = PCI_EXT_CAP_ID_SRIOV);=0A@@ -767,7 +767,7 @@ static = int __pci_enable_msi(struct msi_i=0A struct msi_desc *old_desc;=0A =0A = ASSERT(spin_is_locked(&pcidevs_lock));=0A- pdev =3D pci_get_pdev(msi= ->bus, msi->devfn);=0A+ pdev =3D pci_get_pdev(msi->seg, msi->bus, = msi->devfn);=0A if ( !pdev )=0A return -ENODEV;=0A =0A@@ = -775,7 +775,8 @@ static int __pci_enable_msi(struct msi_i=0A if ( = old_desc )=0A {=0A dprintk(XENLOG_WARNING, "irq %d has already = mapped to MSI on "=0A- "device %02x:%02x.%01x.\n", = msi->irq, msi->bus,=0A+ "device %04x:%02x:%02x.%01x\n",=0A+ = msi->irq, msi->seg, msi->bus,=0A PCI_SLOT(ms= i->devfn), PCI_FUNC(msi->devfn));=0A *desc =3D old_desc;=0A = return 0;=0A@@ -785,7 +786,7 @@ static int __pci_enable_msi(struct = msi_i=0A if ( old_desc )=0A {=0A dprintk(XENLOG_WARNING, = "MSI-X is already in use on "=0A- "device %02x:%02x.%01x\n",= msi->bus,=0A+ "device %04x:%02x:%02x.%01x\n", msi->seg, = msi->bus,=0A PCI_SLOT(msi->devfn), PCI_FUNC(msi->devfn));= =0A pci_disable_msi(old_desc);=0A }=0A@@ -830,7 +831,7 @@ = static int __pci_enable_msix(struct msi_=0A struct msi_desc *old_desc;= =0A =0A ASSERT(spin_is_locked(&pcidevs_lock));=0A- pdev =3D = pci_get_pdev(msi->bus, msi->devfn);=0A+ pdev =3D pci_get_pdev(msi->seg, = msi->bus, msi->devfn);=0A if ( !pdev )=0A return -ENODEV;=0A = =0A@@ -844,7 +845,8 @@ static int __pci_enable_msix(struct msi_=0A if = ( old_desc )=0A {=0A dprintk(XENLOG_WARNING, "irq %d has = already mapped to MSIX on "=0A- "device %02x:%02x.%01x.\n", = msi->irq, msi->bus,=0A+ "device %04x:%02x:%02x.%01x\n",=0A+ = msi->irq, msi->seg, msi->bus,=0A PCI_SLOT(ms= i->devfn), PCI_FUNC(msi->devfn));=0A *desc =3D old_desc;=0A = return 0;=0A@@ -854,7 +856,7 @@ static int __pci_enable_msix(struct = msi_=0A if ( old_desc )=0A {=0A dprintk(XENLOG_WARNING, = "MSI is already in use on "=0A- "device %02x:%02x.%01x\n", = msi->bus,=0A+ "device %04x:%02x:%02x.%01x\n", msi->seg, = msi->bus,=0A PCI_SLOT(msi->devfn), PCI_FUNC(msi->devfn));= =0A pci_disable_msi(old_desc);=0A =0A@@ -962,8 +964,10 @@ int = pci_restore_msi_state(struct pci_dev=0A =0A if (desc->msi_desc = !=3D entry)=0A {=0A- dprintk(XENLOG_ERR, "Restore MSI = for dev %x:%x not set before?\n",=0A- = pdev->bus, pdev->devfn);=0A+ dprintk(XENLOG_ERR,=0A+ = "Restore MSI for dev %04x:%02x:%02x:%x not set before?\n",=0A+ = pdev->seg, pdev->bus, PCI_SLOT(pdev->devfn),=0A+ = PCI_FUNC(pdev->devfn));=0A spin_unlock_irqrestore(&desc= ->lock, flags);=0A return -EINVAL;=0A }=0A--- = 2011-09-20.orig/xen/arch/x86/physdev.c 2011-09-05 09:12:30.000000000 = +0200=0A+++ 2011-09-20/xen/arch/x86/physdev.c 2011-09-20 16:03:39.0000000= 00 +0200=0A@@ -357,6 +357,15 @@ ret_t do_physdev_op(int cmd, XEN_GUEST_H=0A= if ( copy_from_guest(&map, arg, 1) !=3D 0 )=0A = break;=0A =0A+ if ( map.type =3D=3D MAP_PIRQ_TYPE_MSI_SEG )=0A+ = {=0A+ map.type =3D MAP_PIRQ_TYPE_MSI;=0A+ msi.seg = =3D map.bus >> 16;=0A+ }=0A+ else=0A+ {=0A+ = msi.seg =3D 0;=0A+ }=0A msi.bus =3D map.bus;=0A = msi.devfn =3D map.devfn;=0A msi.entry_nr =3D map.entry_nr;=0A@@ = -480,7 +489,7 @@ ret_t do_physdev_op(int cmd, XEN_GUEST_H=0A if ( = copy_from_guest(&manage_pci, arg, 1) !=3D 0 )=0A break;=0A = =0A- ret =3D pci_add_device(manage_pci.bus, manage_pci.devfn, = NULL);=0A+ ret =3D pci_add_device(0, manage_pci.bus, manage_pci.devf= n, NULL);=0A break;=0A }=0A =0A@@ -493,7 +502,7 @@ ret_t = do_physdev_op(int cmd, XEN_GUEST_H=0A if ( copy_from_guest(&manage_= pci, arg, 1) !=3D 0 )=0A break;=0A =0A- ret =3D = pci_remove_device(manage_pci.bus, manage_pci.devfn);=0A+ ret =3D = pci_remove_device(0, manage_pci.bus, manage_pci.devfn);=0A = break;=0A }=0A =0A@@ -517,12 +526,52 @@ ret_t do_physdev_op(int cmd, = XEN_GUEST_H=0A pdev_info.is_virtfn =3D manage_pci_ext.is_virtfn;=0A= pdev_info.physfn.bus =3D manage_pci_ext.physfn.bus;=0A = pdev_info.physfn.devfn =3D manage_pci_ext.physfn.devfn;=0A- ret =3D = pci_add_device(manage_pci_ext.bus,=0A+ ret =3D pci_add_device(0, = manage_pci_ext.bus,=0A manage_pci_ext.devfn,= =0A &pdev_info);=0A break;=0A = }=0A =0A+ case PHYSDEVOP_pci_device_add: {=0A+ struct physdev_pci= _device_add add;=0A+ struct pci_dev_info pdev_info;=0A+=0A+ = ret =3D -EPERM;=0A+ if ( !IS_PRIV(current->domain) )=0A+ = break;=0A+=0A+ ret =3D -EFAULT;=0A+ if ( copy_from_guest(&add= , arg, 1) !=3D 0 )=0A+ break;=0A+=0A+ pdev_info.is_extfn = =3D !!(add.flags & XEN_PCI_DEV_EXTFN);=0A+ if ( add.flags & = XEN_PCI_DEV_VIRTFN )=0A+ {=0A+ pdev_info.is_virtfn =3D = 1;=0A+ pdev_info.physfn.bus =3D add.physfn.bus;=0A+ = pdev_info.physfn.devfn =3D add.physfn.devfn;=0A+ }=0A+ = else=0A+ pdev_info.is_virtfn =3D 0;=0A+ ret =3D = pci_add_device(add.seg, add.bus, add.devfn, &pdev_info);=0A+ = break;=0A+ }=0A+=0A+ case PHYSDEVOP_pci_device_remove: {=0A+ = struct physdev_pci_device dev;=0A+=0A+ ret =3D -EPERM;=0A+ = if ( !IS_PRIV(v->domain) )=0A+ break;=0A+=0A+ ret =3D = -EFAULT;=0A+ if ( copy_from_guest(&dev, arg, 1) !=3D 0 )=0A+ = break;=0A+=0A+ ret =3D pci_remove_device(dev.seg, dev.bus, = dev.devfn);=0A+ break;=0A+ }=0A+=0A #ifdef __x86_64__=0A = case PHYSDEVOP_pci_mmcfg_reserved: {=0A struct physdev_pci_mmcfg_re= served info;=0A@@ -554,11 +603,31 @@ ret_t do_physdev_op(int cmd, = XEN_GUEST_H=0A break;=0A =0A spin_lock(&pcidevs_lock);= =0A- pdev =3D pci_get_pdev(restore_msi.bus, restore_msi.devfn);=0A+ = pdev =3D pci_get_pdev(0, restore_msi.bus, restore_msi.devfn);=0A+ = ret =3D pdev ? pci_restore_msi_state(pdev) : -ENODEV;=0A+ = spin_unlock(&pcidevs_lock);=0A+ break;=0A+ }=0A+=0A+ case = PHYSDEVOP_restore_msi_ext: {=0A+ struct physdev_pci_device dev;=0A+ = struct pci_dev *pdev;=0A+=0A+ ret =3D -EPERM;=0A+ if = ( !IS_PRIV(v->domain) )=0A+ break;=0A+=0A+ ret =3D = -EFAULT;=0A+ if ( copy_from_guest(&dev, arg, 1) !=3D 0 )=0A+ = break;=0A+=0A+ spin_lock(&pcidevs_lock);=0A+ pdev =3D = pci_get_pdev(dev.seg, dev.bus, dev.devfn);=0A ret =3D pdev ? = pci_restore_msi_state(pdev) : -ENODEV;=0A spin_unlock(&pcidevs_lock= );=0A break;=0A }=0A+=0A case PHYSDEVOP_setup_gsi: {=0A = struct physdev_setup_gsi setup_gsi;=0A =0A--- 2011-09-20.orig/xen/arch= /x86/x86_64/physdev.c 2011-08-08 08:29:50.000000000 +0200=0A+++ = 2011-09-20/xen/arch/x86/x86_64/physdev.c 2011-08-25 15:06:35.0000000= 00 +0200=0A@@ -67,6 +67,14 @@ CHECK_physdev_get_free_pirq;=0A CHECK_physdev= _pci_mmcfg_reserved;=0A #undef xen_physdev_pci_mmcfg_reserved=0A =0A+#defin= e xen_physdev_pci_device_add physdev_pci_device_add=0A+CHECK_physdev_pci_de= vice_add=0A+#undef xen_physdev_pci_device_add=0A+=0A+#define xen_physdev_pc= i_device physdev_pci_device=0A+CHECK_physdev_pci_device=0A+#undef = xen_physdev_pci_device=0A+=0A #define COMPAT=0A #undef guest_handle_okay=0A= #define guest_handle_okay compat_handle_okay=0A--- 2011-09-20.ori= g/xen/drivers/passthrough/amd/pci_amd_iommu.c 2011-09-12 08:34:38.0000000= 00 +0200=0A+++ 2011-09-20/xen/drivers/passthrough/amd/pci_amd_iommu.c = 2011-09-20 16:03:27.000000000 +0200=0A@@ -131,7 +131,7 @@ static void = __init amd_iommu_setup_dom0_=0A {=0A for ( devfn =3D 0; devfn = < 256; devfn++ )=0A {=0A- pdev =3D pci_get_pdev(bus, = devfn);=0A+ pdev =3D pci_get_pdev(0, bus, devfn);=0A = if ( !pdev )=0A continue;=0A =0A@@ -313,7 +313,7 @@ = static int reassign_device( struct domai=0A struct hvm_iommu *t =3D = domain_hvm_iommu(target);=0A =0A ASSERT(spin_is_locked(&pcidevs_lock));= =0A- pdev =3D pci_get_pdev_by_domain(source, bus, devfn);=0A+ pdev = =3D pci_get_pdev_by_domain(source, 0, bus, devfn);=0A if ( !pdev )=0A = return -ENODEV;=0A =0A--- 2011-09-20.orig/xen/drivers/passthrough/io= mmu.c 2011-09-05 09:12:30.000000000 +0200=0A+++ 2011-09-20/xen/drivers/pa= ssthrough/iommu.c 2011-08-25 15:06:35.000000000 +0200=0A@@ -282,7 = +282,7 @@ int deassign_device(struct domain *d, u8=0A return = -EINVAL;=0A =0A ASSERT(spin_is_locked(&pcidevs_lock));=0A- pdev =3D = pci_get_pdev(bus, devfn);=0A+ pdev =3D pci_get_pdev(0, bus, devfn);=0A = if ( !pdev )=0A return -ENODEV;=0A =0A--- 2011-09-20.orig/xen/dr= ivers/passthrough/pci.c 2011-08-25 15:06:23.000000000 +0200=0A+++ = 2011-09-20/xen/drivers/passthrough/pci.c 2011-08-25 15:06:35.0000000= 00 +0200=0A@@ -121,6 +121,7 @@ static struct pci_dev *alloc_pdev(struct=0A = return NULL;=0A memset(pdev, 0, sizeof(struct pci_dev));=0A = =0A+ *(u16*) &pdev->seg =3D pseg->nr;=0A *((u8*) &pdev->bus) =3D = bus;=0A *((u8*) &pdev->devfn) =3D devfn;=0A pdev->domain =3D = NULL;=0A@@ -137,41 +138,59 @@ static void free_pdev(struct pci_dev *pd=0A = xfree(pdev);=0A }=0A =0A-struct pci_dev *pci_get_pdev(int bus, int = devfn)=0A+struct pci_dev *pci_get_pdev(int seg, int bus, int devfn)=0A = {=0A- struct pci_seg *pseg =3D get_pseg(0);=0A+ struct pci_seg *pseg = =3D get_pseg(seg);=0A struct pci_dev *pdev =3D NULL;=0A =0A = ASSERT(spin_is_locked(&pcidevs_lock));=0A+ ASSERT(seg !=3D -1 || bus = =3D=3D -1);=0A+ ASSERT(bus !=3D -1 || devfn =3D=3D -1);=0A =0A if ( = !pseg )=0A- return NULL;=0A+ {=0A+ if ( seg =3D=3D -1 = )=0A+ radix_tree_gang_lookup(&pci_segments, (void **)&pseg, 0, = 1);=0A+ if ( !pseg )=0A+ return NULL;=0A+ }=0A =0A- = list_for_each_entry ( pdev, &pseg->alldevs_list, alldevs_list )=0A- = if ( (pdev->bus =3D=3D bus || bus =3D=3D -1) &&=0A- (pdev->dev= fn =3D=3D devfn || devfn =3D=3D -1) )=0A- {=0A- return = pdev;=0A- }=0A+ do {=0A+ list_for_each_entry ( pdev, = &pseg->alldevs_list, alldevs_list )=0A+ if ( (pdev->bus =3D=3D = bus || bus =3D=3D -1) &&=0A+ (pdev->devfn =3D=3D devfn || = devfn =3D=3D -1) )=0A+ return pdev;=0A+ } while ( = radix_tree_gang_lookup(&pci_segments, (void **)&pseg,=0A+ = pseg->nr + 1, 1) );=0A =0A return NULL;=0A }=0A = =0A-struct pci_dev *pci_get_pdev_by_domain(struct domain *d, int bus, int = devfn)=0A+struct pci_dev *pci_get_pdev_by_domain(=0A+ struct domain *d, = int seg, int bus, int devfn)=0A {=0A- struct pci_seg *pseg =3D = get_pseg(0);=0A+ struct pci_seg *pseg =3D get_pseg(seg);=0A struct = pci_dev *pdev =3D NULL;=0A =0A+ ASSERT(seg !=3D -1 || bus =3D=3D = -1);=0A+ ASSERT(bus !=3D -1 || devfn =3D=3D -1);=0A+=0A if ( !pseg = )=0A- return NULL;=0A+ {=0A+ if ( seg =3D=3D -1 )=0A+ = radix_tree_gang_lookup(&pci_segments, (void **)&pseg, 0, 1);=0A+ = if ( !pseg )=0A+ return NULL;=0A+ }=0A =0A- list_for_e= ach_entry ( pdev, &pseg->alldevs_list, alldevs_list )=0A- if ( = (pdev->bus =3D=3D bus || bus =3D=3D -1) &&=0A- (pdev->devfn = =3D=3D devfn || devfn =3D=3D -1) &&=0A- (pdev->domain =3D=3D = d) )=0A- {=0A- return pdev;=0A- }=0A+ do = {=0A+ list_for_each_entry ( pdev, &pseg->alldevs_list, alldevs_list = )=0A+ if ( (pdev->bus =3D=3D bus || bus =3D=3D -1) &&=0A+ = (pdev->devfn =3D=3D devfn || devfn =3D=3D -1) &&=0A+ = (pdev->domain =3D=3D d) )=0A+ return pdev;=0A+ } = while ( radix_tree_gang_lookup(&pci_segments, (void **)&pseg,=0A+ = pseg->nr + 1, 1) );=0A =0A return NULL;=0A = }=0A@@ -215,7 +234,7 @@ void pci_enable_acs(struct pci_dev *pdev=0A = pci_conf_write16(bus, dev, func, pos + PCI_ACS_CTRL, ctrl);=0A }=0A = =0A-int pci_add_device(u8 bus, u8 devfn, const struct pci_dev_info = *info)=0A+int pci_add_device(u16 seg, u8 bus, u8 devfn, const struct = pci_dev_info *info)=0A {=0A struct pci_seg *pseg;=0A struct = pci_dev *pdev;=0A@@ -230,17 +249,20 @@ int pci_add_device(u8 bus, u8 = devfn, con=0A else if (info->is_virtfn)=0A {=0A spin_lock(&= pcidevs_lock);=0A- pdev =3D pci_get_pdev(info->physfn.bus, = info->physfn.devfn);=0A+ pdev =3D pci_get_pdev(seg, info->physfn.bus= , info->physfn.devfn);=0A spin_unlock(&pcidevs_lock);=0A = if ( !pdev )=0A- pci_add_device(info->physfn.bus, info->physfn.d= evfn, NULL);=0A+ pci_add_device(seg, info->physfn.bus, = info->physfn.devfn, NULL);=0A pdev_type =3D "virtual function";=0A = }=0A else=0A- return -EINVAL;=0A+ {=0A+ info =3D = NULL;=0A+ pdev_type =3D "device";=0A+ }=0A =0A spin_lock(&pci= devs_lock);=0A- pseg =3D alloc_pseg(0);=0A+ pseg =3D alloc_pseg(seg);= =0A if ( !pseg )=0A goto out;=0A pdev =3D alloc_pdev(pseg, = bus, devfn);=0A@@ -251,7 +273,7 @@ int pci_add_device(u8 bus, u8 devfn, = con=0A pdev->info =3D *info;=0A else if ( !pdev->vf_rlen[0] = )=0A {=0A- unsigned int pos =3D pci_find_ext_capability(0, bus, = devfn,=0A+ unsigned int pos =3D pci_find_ext_capability(seg, bus, = devfn,=0A PCI_EXT_CAP_ID= _SRIOV);=0A u16 ctrl =3D pci_conf_read16(bus, slot, func, pos + = PCI_SRIOV_CTRL);=0A =0A@@ -271,9 +293,10 @@ int pci_add_device(u8 bus, u8 = devfn, con=0A if ( (bar & PCI_BASE_ADDRESS_SPACE) = =3D=3D=0A PCI_BASE_ADDRESS_SPACE_IO )=0A = {=0A- printk(XENLOG_WARNING "SR-IOV device %02x:%02x.= %x with vf"=0A- " BAR%u in IO = space\n",=0A- bus, slot, func, i);=0A+ = printk(XENLOG_WARNING=0A+ "SR-IOV = device %04x:%02x:%02x.%u with vf BAR%u"=0A+ " in = IO space\n",=0A+ seg, bus, slot, func, i);=0A = continue;=0A }=0A = pci_conf_write32(bus, slot, func, idx, ~0);=0A@@ -282,9 +305,10 @@ int = pci_add_device(u8 bus, u8 devfn, con=0A {=0A = if ( i >=3D PCI_SRIOV_NUM_BARS )=0A {=0A- = printk(XENLOG_WARNING "SR-IOV device %02x:%02x.%x = with"=0A- " 64-bit vf BAR in = last slot\n",=0A- bus, slot, func);=0A+ = printk(XENLOG_WARNING=0A+ = "SR-IOV device %04x:%02x:%02x.%u with 64-bit"=0A+ = " vf BAR in last slot\n",=0A+ seg, bus, = slot, func);=0A break;=0A }=0A = hi =3D pci_conf_read32(bus, slot, func, idx + 4);=0A@@ = -309,9 +333,10 @@ int pci_add_device(u8 bus, u8 devfn, con=0A = }=0A }=0A else=0A- printk(XENLOG_WARNING = "SR-IOV device %02x:%02x.%x has its virtual"=0A- = " functions already enabled (%04x)\n",=0A- bus, = slot, func, ctrl);=0A+ printk(XENLOG_WARNING=0A+ = "SR-IOV device %04x:%02x:%02x.%u has its virtual"=0A+ = " functions already enabled (%04x)\n",=0A+ seg, bus, = slot, func, ctrl);=0A }=0A =0A ret =3D 0;=0A@@ -331,14 +356,14 @@ = int pci_add_device(u8 bus, u8 devfn, con=0A =0A out:=0A spin_unlock(&pc= idevs_lock);=0A- printk(XENLOG_DEBUG "PCI add %s %02x:%02x.%x\n", = pdev_type,=0A- bus, slot, func);=0A+ printk(XENLOG_DEBUG "PCI = add %s %04x:%02x:%02x.%u\n", pdev_type,=0A+ seg, bus, slot, = func);=0A return ret;=0A }=0A =0A-int pci_remove_device(u8 bus, u8 = devfn)=0A+int pci_remove_device(u16 seg, u8 bus, u8 devfn)=0A {=0A- = struct pci_seg *pseg =3D get_pseg(0);=0A+ struct pci_seg *pseg =3D = get_pseg(seg);=0A struct pci_dev *pdev;=0A int ret =3D -ENODEV;=0A = =0A@@ -354,8 +379,8 @@ int pci_remove_device(u8 bus, u8 devfn)=0A = list_del(&pdev->domain_list);=0A pci_cleanup_msi(pdev);= =0A free_pdev(pdev);=0A- printk(XENLOG_DEBUG "PCI = remove device %02x:%02x.%x\n", bus,=0A- PCI_SLOT(devfn), = PCI_FUNC(devfn));=0A+ printk(XENLOG_DEBUG "PCI remove device = %04x:%02x:%02x.%u\n",=0A+ seg, bus, PCI_SLOT(devfn), = PCI_FUNC(devfn));=0A break;=0A }=0A =0A@@ -413,7 = +438,7 @@ void pci_release_devices(struct domain *=0A =0A spin_lock(&pc= idevs_lock);=0A pci_clean_dpci_irqs(d);=0A- while ( (pdev =3D = pci_get_pdev_by_domain(d, -1, -1)) )=0A+ while ( (pdev =3D pci_get_pdev_= by_domain(d, -1, -1, -1)) )=0A {=0A pci_cleanup_msi(pdev);=0A = bus =3D pdev->bus; devfn =3D pdev->devfn;=0A--- 2011-09-20.orig/xen/= drivers/passthrough/vtd/iommu.c 2011-09-12 08:34:38.000000000 +0200=0A+++ = 2011-09-20/xen/drivers/passthrough/vtd/iommu.c 2011-09-20 16:03:17.0000000= 00 +0200=0A@@ -280,7 +280,7 @@ static u64 addr_to_dma_page_maddr(struct=0A = * just get any passthrough device in the domainr - assume user=0A = * assigns only devices from same node to a given guest.=0A = */=0A- pdev =3D pci_get_pdev_by_domain(domain, -1, -1);=0A+ = pdev =3D pci_get_pdev_by_domain(domain, -1, -1, -1);=0A drhd =3D = acpi_find_matched_drhd_unit(pdev);=0A if ( !alloc || ((hd->pgd_madd= r =3D alloc_pgtable_maddr(drhd, 1)) =3D=3D 0) )=0A goto = out;=0A@@ -297,7 +297,7 @@ static u64 addr_to_dma_page_maddr(struct=0A = if ( !alloc )=0A break;=0A =0A- pdev = =3D pci_get_pdev_by_domain(domain, -1, -1);=0A+ pdev =3D = pci_get_pdev_by_domain(domain, -1, -1, -1);=0A drhd =3D = acpi_find_matched_drhd_unit(pdev);=0A maddr =3D alloc_pgtable_m= addr(drhd, 1);=0A if ( !maddr )=0A@@ -1273,7 +1273,7 @@ int = domain_context_mapping_one(=0A =0A /* First try to get domain = ownership from device structure. If that's=0A * not available, = try to read it from the context itself. */=0A- pdev =3D pci_get_pdev= (bus, devfn);=0A+ pdev =3D pci_get_pdev(0, bus, devfn);=0A = if ( pdev )=0A {=0A if ( pdev->domain !=3D domain = )=0A@@ -1396,7 +1396,7 @@ static int domain_context_mapping(struct=0A = int ret =3D 0;=0A u32 type;=0A u8 secbus;=0A- struct pci_dev = *pdev =3D pci_get_pdev(bus, devfn);=0A+ struct pci_dev *pdev =3D = pci_get_pdev(0, bus, devfn);=0A =0A drhd =3D acpi_find_matched_drhd_uni= t(pdev);=0A if ( !drhd )=0A@@ -1521,7 +1521,7 @@ static int domain_cont= ext_unmap(struct d=0A int ret =3D 0;=0A u32 type;=0A u8 = tmp_bus, tmp_devfn, secbus;=0A- struct pci_dev *pdev =3D pci_get_pdev(bu= s, devfn);=0A+ struct pci_dev *pdev =3D pci_get_pdev(0, bus, devfn);=0A = int found =3D 0;=0A =0A BUG_ON(!pdev);=0A@@ -1632,7 +1632,7 @@ = static int reassign_device_ownership(=0A int ret;=0A =0A ASSERT(spi= n_is_locked(&pcidevs_lock));=0A- pdev =3D pci_get_pdev_by_domain(source,= bus, devfn);=0A+ pdev =3D pci_get_pdev_by_domain(source, 0, bus, = devfn);=0A =0A if (!pdev)=0A return -ENODEV;=0A@@ -1941,7 = +1941,7 @@ static void __init setup_dom0_devices(st=0A {=0A = for ( devfn =3D 0; devfn < 256; devfn++ )=0A {=0A- pdev = =3D pci_get_pdev(bus, devfn);=0A+ pdev =3D pci_get_pdev(0, bus, = devfn);=0A if ( !pdev )=0A continue;=0A =0A@@ = -2175,7 +2175,7 @@ int device_assigned(u8 bus, u8 devfn)=0A struct = pci_dev *pdev;=0A =0A spin_lock(&pcidevs_lock);=0A- pdev =3D = pci_get_pdev_by_domain(dom0, bus, devfn);=0A+ pdev =3D pci_get_pdev_by_d= omain(dom0, 0, bus, devfn);=0A if (!pdev)=0A {=0A = spin_unlock(&pcidevs_lock);=0A@@ -2197,7 +2197,7 @@ static int intel_iommu_= assign_device(str=0A return -ENODEV;=0A =0A ASSERT(spin_is_lock= ed(&pcidevs_lock));=0A- pdev =3D pci_get_pdev(bus, devfn);=0A+ pdev = =3D pci_get_pdev(0, bus, devfn);=0A if (!pdev)=0A return = -ENODEV;=0A =0A--- 2011-09-20.orig/xen/drivers/passthrough/vtd/quirks.c = 2011-03-11 10:13:55.000000000 +0100=0A+++ 2011-09-20/xen/drivers/passthroug= h/vtd/quirks.c 2011-08-25 15:06:35.000000000 +0200=0A@@ -286,7 +286,7 @@ = static void map_me_phantom_function(stru=0A struct pci_dev *pdev;=0A = =0A /* find ME VT-d engine base on a real ME device */=0A- pdev =3D = pci_get_pdev(0, PCI_DEVFN(dev, 0));=0A+ pdev =3D pci_get_pdev(0, 0, = PCI_DEVFN(dev, 0));=0A drhd =3D acpi_find_matched_drhd_unit(pdev);=0A = =0A /* map or unmap ME phantom function */=0A--- 2011-09-20.orig/xen/dr= ivers/passthrough/vtd/x86/ats.c 2011-03-31 08:50:59.000000000 +0200=0A+++ = 2011-09-20/xen/drivers/passthrough/vtd/x86/ats.c 2011-08-25 = 15:06:35.000000000 +0200=0A@@ -37,6 +37,7 @@ static LIST_HEAD(ats_dev_drhd_= units);=0A =0A struct pci_ats_dev {=0A struct list_head list;=0A+ = u16 seg;=0A u8 bus;=0A u8 devfn;=0A u16 ats_queue_depth; /* = ATS device invalidation queue depth */=0A@@ -91,7 +92,7 @@ int ats_device(i= nt seg, int bus, int dev=0A if ( !ats_enabled || !iommu_qinval )=0A = return 0;=0A =0A- pdev =3D pci_get_pdev(bus, devfn);=0A+ pdev = =3D pci_get_pdev(seg, bus, devfn);=0A if ( !pdev )=0A return = 0;=0A =0A@@ -130,8 +131,9 @@ int enable_ats_device(int seg, int bus, =0A = BUG_ON(!pos);=0A =0A if ( iommu_verbose )=0A- dprintk(XENLOG_I= NFO VTDPREFIX, "%x:%x.%x: ATS capability found\n",=0A- bus, = PCI_SLOT(devfn), PCI_FUNC(devfn));=0A+ dprintk(XENLOG_INFO = VTDPREFIX,=0A+ "%04x:%02x:%02x.%u: ATS capability = found\n",=0A+ seg, bus, PCI_SLOT(devfn), PCI_FUNC(devfn));= =0A =0A /* BUGBUG: add back seg when multi-seg platform support is = enabled */=0A value =3D pci_conf_read16(bus, PCI_SLOT(devfn),=0A@@ = -140,7 +142,7 @@ int enable_ats_device(int seg, int bus, =0A {=0A = list_for_each_entry ( pdev, &ats_devices, list )=0A {=0A- = if ( pdev->bus =3D=3D bus && pdev->devfn =3D=3D devfn )=0A+ = if ( pdev->seg =3D=3D seg && pdev->bus =3D=3D bus && pdev->devfn =3D=3D = devfn )=0A {=0A pos =3D 0;=0A = break;=0A@@ -161,6 +163,7 @@ int enable_ats_device(int seg, int bus, =0A = =0A if ( pos )=0A {=0A+ pdev->seg =3D seg;=0A = pdev->bus =3D bus;=0A pdev->devfn =3D devfn;=0A value =3D = pci_conf_read16(bus, PCI_SLOT(devfn),=0A@@ -170,8 +173,10 @@ int enable_ats= _device(int seg, int bus, =0A }=0A =0A if ( iommu_verbose )=0A- = dprintk(XENLOG_INFO VTDPREFIX, "%x:%x.%x: ATS %s enabled\n",=0A- = bus, PCI_SLOT(devfn), PCI_FUNC(devfn), pos ? "is" : "was");=0A+ = dprintk(XENLOG_INFO VTDPREFIX,=0A+ "%04x:%02x:%02x.%u: = ATS %s enabled\n",=0A+ seg, bus, PCI_SLOT(devfn), PCI_FUNC(d= evfn),=0A+ pos ? "is" : "was");=0A =0A return pos;=0A = }=0A@@ -194,7 +199,7 @@ void disable_ats_device(int seg, int bus=0A =0A = list_for_each_entry ( pdev, &ats_devices, list )=0A {=0A- if ( = pdev->bus =3D=3D bus && pdev->devfn =3D=3D devfn )=0A+ if ( = pdev->seg =3D=3D seg && pdev->bus =3D=3D bus && pdev->devfn =3D=3D devfn = )=0A {=0A list_del(&pdev->list);=0A = xfree(pdev);=0A@@ -203,8 +208,9 @@ void disable_ats_device(int seg, int = bus=0A }=0A =0A if ( iommu_verbose )=0A- dprintk(XENLOG_INFO= VTDPREFIX, "%x:%x.%x: ATS is disabled\n",=0A- bus, = PCI_SLOT(devfn), PCI_FUNC(devfn));=0A+ dprintk(XENLOG_INFO = VTDPREFIX,=0A+ "%04x:%02x:%02x.%u: ATS is disabled\n",=0A+ = seg, bus, PCI_SLOT(devfn), PCI_FUNC(devfn));=0A }=0A =0A = =0A--- 2011-09-20.orig/xen/include/asm-x86/msi.h 2011-09-05 = 09:12:30.000000000 +0200=0A+++ 2011-09-20/xen/include/asm-x86/msi.h = 2011-08-25 15:06:35.000000000 +0200=0A@@ -59,8 +59,9 @@=0A #endif=0A =0A = struct msi_info {=0A- int bus;=0A- int devfn;=0A+ u16 seg;=0A+ = u8 bus;=0A+ u8 devfn;=0A int irq;=0A int entry_nr;=0A = uint64_t table_base;=0A--- 2011-09-20.orig/xen/include/public/physdev.h = 2011-08-08 08:29:50.000000000 +0200=0A+++ 2011-09-20/xen/include/public/phy= sdev.h 2011-08-25 15:06:35.000000000 +0200=0A@@ -142,6 +142,7 @@ = DEFINE_XEN_GUEST_HANDLE(physdev_irq_t);=0A #define MAP_PIRQ_TYPE_MSI = 0x0=0A #define MAP_PIRQ_TYPE_GSI 0x1=0A #define = MAP_PIRQ_TYPE_UNKNOWN 0x2=0A+#define MAP_PIRQ_TYPE_MSI_SEG = 0x3=0A =0A #define PHYSDEVOP_map_pirq 13=0A struct = physdev_map_pirq {=0A@@ -152,7 +153,7 @@ struct physdev_map_pirq {=0A = int index;=0A /* IN or OUT */=0A int pirq;=0A- /* IN */=0A+ = /* IN - high 16 bits hold segment for MAP_PIRQ_TYPE_MSI_SEG */=0A int = bus;=0A /* IN */=0A int devfn;=0A@@ -268,6 +269,41 @@ struct = physdev_pci_mmcfg_reserved {=0A typedef struct physdev_pci_mmcfg_reserved = physdev_pci_mmcfg_reserved_t;=0A DEFINE_XEN_GUEST_HANDLE(physdev_pci_mmcfg_= reserved_t);=0A =0A+#define XEN_PCI_DEV_EXTFN 0x1=0A+#define = XEN_PCI_DEV_VIRTFN 0x2=0A+#define XEN_PCI_DEV_PXM = 0x4=0A+=0A+#define PHYSDEVOP_pci_device_add 25=0A+struct = physdev_pci_device_add {=0A+ /* IN */=0A+ uint16_t seg;=0A+ = uint8_t bus;=0A+ uint8_t devfn;=0A+ uint32_t flags;=0A+ struct = {=0A+ uint8_t bus;=0A+ uint8_t devfn;=0A+ } physfn;=0A+#if= defined(__STDC_VERSION__) && __STDC_VERSION__ >=3D 199901L=0A+ = uint32_t optarr[];=0A+#elif defined(__GNUC__)=0A+ uint32_t optarr[0];=0A= +#endif=0A+};=0A+typedef struct physdev_pci_device_add physdev_pci_device_a= dd_t;=0A+DEFINE_XEN_GUEST_HANDLE(physdev_pci_device_add_t);=0A+=0A+#define = PHYSDEVOP_pci_device_remove 26=0A+#define PHYSDEVOP_restore_msi_ext = 27=0A+struct physdev_pci_device {=0A+ /* IN */=0A+ uint16_t = seg;=0A+ uint8_t bus;=0A+ uint8_t devfn;=0A+};=0A+typedef struct = physdev_pci_device physdev_pci_device_t;=0A+DEFINE_XEN_GUEST_HANDLE(physdev= _pci_device_t);=0A+=0A /*=0A * Notify that some PIRQ-bound event channels = have been unmasked.=0A * ** This command is obsolete since interface = version 0x00030202 and is **=0A--- 2011-09-20.orig/xen/include/xen/pci.h = 2011-08-25 15:06:23.000000000 +0200=0A+++ 2011-09-20/xen/include/xen/pci.h = 2011-08-25 15:06:35.000000000 +0200=0A@@ -56,6 +56,7 @@ struct pci_dev = {=0A spinlock_t msix_table_lock;=0A =0A struct domain *domain;=0A+ = const u16 seg;=0A const u8 bus;=0A const u8 devfn;=0A = struct pci_dev_info info;=0A@@ -90,10 +91,11 @@ struct pci_dev *pci_lock_do= main_pdev(str=0A =0A void pci_release_devices(struct domain *d);=0A int = pci_add_segment(u16 seg);=0A-int pci_add_device(u8 bus, u8 devfn, const = struct pci_dev_info *);=0A-int pci_remove_device(u8 bus, u8 devfn);=0A-stru= ct pci_dev *pci_get_pdev(int bus, int devfn);=0A-struct pci_dev *pci_get_pd= ev_by_domain(struct domain *d, int bus, int devfn);=0A+int pci_add_device(u= 16 seg, u8 bus, u8 devfn, const struct pci_dev_info *);=0A+int pci_remove_d= evice(u16 seg, u8 bus, u8 devfn);=0A+struct pci_dev *pci_get_pdev(int seg, = int bus, int devfn);=0A+struct pci_dev *pci_get_pdev_by_domain(=0A+ = struct domain *, int seg, int bus, int devfn);=0A =0A void disconnect_pci_d= evices(void);=0A =0A--- 2011-09-20.orig/xen/include/xlat.lst 2011-08-08 = 08:29:50.000000000 +0200=0A+++ 2011-09-20/xen/include/xlat.lst 2011-08-25 = 15:06:35.000000000 +0200=0A@@ -65,6 +65,8 @@=0A ? physdev_irq_status_= query physdev.h=0A ? physdev_manage_pci physdev.h=0A ? = physdev_manage_pci_ext physdev.h=0A+? physdev_pci_device = physdev.h=0A+? physdev_pci_device_add physdev.h=0A ? physdev_pci= _mmcfg_reserved physdev.h=0A ? physdev_unmap_pirq = physdev.h=0A ? physdev_restore_msi physdev.h=0A --=__Part6C43579C.0__= Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel --=__Part6C43579C.0__=-- From xen-devel-bounces@lists.xensource.com Tue Sep 20 08:20:34 2011 Return-path: <xen-devel-bounces@lists.xensource.com> Envelope-to: www-data@lists.xensource.com Delivery-date: Tue, 20 Sep 2011 08:20:34 -0700 Received: from localhost ([127.0.0.1] helo=lists.colo.xensource.com) by lists.xensource.com with esmtp (Exim 4.43) id 1R627e-0000KH-5n; Tue, 20 Sep 2011 08:20:34 -0700 Received: from mail21.messagelabs.com ([85.158.143.35]) by lists.xensource.com with esmtp (Exim 4.43) id 1R6251-0007on-P7 for xen-devel@lists.xensource.com; Tue, 20 Sep 2011 08:17:53 -0700 X-Env-Sender: JBeulich@suse.com X-Msg-Ref: server-2.tower-21.messagelabs.com!1316531867!34833353!1 X-Originating-IP: [130.57.49.28] X-StarScan-Version: 6.4.1; banners=-,-,- X-VirusChecked: Checked Received: (qmail 22030 invoked from network); 20 Sep 2011 15:17:47 -0000 Received: from nat28.tlf.novell.com (HELO nat28.tlf.novell.com) (130.57.49.28) by server-2.tower-21.messagelabs.com with DHE-RSA-AES256-SHA encrypted SMTP; 20 Sep 2011 15:17:47 -0000 Received: from EMEA1-MTA by nat28.tlf.novell.com with Novell_GroupWise; Tue, 20 Sep 2011 16:17:47 +0100 Message-Id: <4E78CAD60200007800056D24@nat28.tlf.novell.com> X-Mailer: Novell GroupWise Internet Agent 8.0.1 Date: Tue, 20 Sep 2011 16:18:14 +0100 From: "Jan Beulich" <JBeulich@suse.com> To: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com> Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="=__Part56796DA6.0__=" Subject: [Xen-devel] [PATCH 3/7] PCI multi-seg: adjust domctl interface X-BeenThere: xen-devel@lists.xensource.com X-Mailman-Version: 2.1.5 Precedence: list List-Id: Xen developer discussion <xen-devel.lists.xensource.com> List-Unsubscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe> List-Post: <mailto:xen-devel@lists.xensource.com> List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help> List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=subscribe> Sender: xen-devel-bounces@lists.xensource.com Errors-To: xen-devel-bounces@lists.xensource.com This is a MIME message. If you are reading this text, you may want to consider changing to a mail reader or gateway that understands how to properly handle MIME multipart messages. --=__Part56796DA6.0__= Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: quoted-printable Content-Disposition: inline Again, a couple of directly related functions at once get adjusted to account for the segment number. Do we need to bump XEN_DOMCTL_INTERFACE_VERSION for the changes to the domctl interface (namely the renaming and bit-reassigment of the machine_bdf member of two of the interface structures)? If so, this can probably be done as the patch gets checked in (rather than me having to re-submit)? Signed-off-by: Jan Beulich <jbeulich@suse.com> --- 2011-09-20.orig/tools/libxc/xc_domain.c 2011-06-16 09:21:02.0000000= 00 +0200 +++ 2011-09-20/tools/libxc/xc_domain.c 2011-09-15 16:51:12.000000000 = +0200 @@ -1132,13 +1132,13 @@ int xc_domain_setdebugging(xc_interface=20 int xc_assign_device( xc_interface *xch, uint32_t domid, - uint32_t machine_bdf) + uint32_t machine_sbdf) { DECLARE_DOMCTL; =20 domctl.cmd =3D XEN_DOMCTL_assign_device; domctl.domain =3D domid; - domctl.u.assign_device.machine_bdf =3D machine_bdf; + domctl.u.assign_device.machine_sbdf =3D machine_sbdf; =20 return do_domctl(xch, &domctl); } @@ -1146,7 +1146,7 @@ int xc_assign_device( int xc_get_device_group( xc_interface *xch, uint32_t domid, - uint32_t machine_bdf, + uint32_t machine_sbdf, uint32_t max_sdevs, uint32_t *num_sdevs, uint32_t *sdev_array) @@ -1164,7 +1164,7 @@ int xc_get_device_group( domctl.cmd =3D XEN_DOMCTL_get_device_group; domctl.domain =3D (domid_t)domid; =20 - domctl.u.get_device_group.machine_bdf =3D machine_bdf; + domctl.u.get_device_group.machine_sbdf =3D machine_sbdf; domctl.u.get_device_group.max_sdevs =3D max_sdevs; =20 set_xen_guest_handle(domctl.u.get_device_group.sdev_array, sdev_array)= ; @@ -1181,13 +1181,13 @@ int xc_get_device_group( int xc_test_assign_device( xc_interface *xch, uint32_t domid, - uint32_t machine_bdf) + uint32_t machine_sbdf) { DECLARE_DOMCTL; =20 domctl.cmd =3D XEN_DOMCTL_test_assign_device; domctl.domain =3D domid; - domctl.u.assign_device.machine_bdf =3D machine_bdf; + domctl.u.assign_device.machine_sbdf =3D machine_sbdf; =20 return do_domctl(xch, &domctl); } @@ -1195,13 +1195,13 @@ int xc_test_assign_device( int xc_deassign_device( xc_interface *xch, uint32_t domid, - uint32_t machine_bdf) + uint32_t machine_sbdf) { DECLARE_DOMCTL; =20 domctl.cmd =3D XEN_DOMCTL_deassign_device; domctl.domain =3D domid; - domctl.u.assign_device.machine_bdf =3D machine_bdf; + domctl.u.assign_device.machine_sbdf =3D machine_sbdf; =20 return do_domctl(xch, &domctl); } --- 2011-09-20.orig/tools/libxl/libxl_pci.c 2011-09-05 09:12:30.0000000= 00 +0200 +++ 2011-09-20/tools/libxl/libxl_pci.c 2011-09-15 15:40:28.000000000 = +0200 @@ -45,10 +45,10 @@ static unsigned int pcidev_encode_bdf(li { unsigned int value; =20 - value =3D 0; - value |=3D (pcidev->bus & 0xff) << 16; - value |=3D (pcidev->dev & 0x1f) << (8+3); - value |=3D (pcidev->func & 0x7) << (8+0); + value =3D pcidev->domain << 16; + value |=3D (pcidev->bus & 0xff) << 8; + value |=3D (pcidev->dev & 0x1f) << 3; + value |=3D (pcidev->func & 0x7); =20 return value; } --- 2011-09-20.orig/tools/python/xen/lowlevel/xc/xc.c 2010-11-05 = 09:22:58.000000000 +0100 +++ 2011-09-20/tools/python/xen/lowlevel/xc/xc.c 2011-09-15 = 15:48:10.000000000 +0200 @@ -609,7 +609,7 @@ static PyObject *pyxc_test_assign_device { uint32_t dom; char *pci_str; - int32_t bdf =3D 0; + int32_t sbdf =3D 0; int seg, bus, dev, func; =20 static char *kwd_list[] =3D { "domid", "pci", NULL }; @@ -619,20 +619,21 @@ static PyObject *pyxc_test_assign_device =20 while ( next_bdf(&pci_str, &seg, &bus, &dev, &func) ) { - bdf |=3D (bus & 0xff) << 16; - bdf |=3D (dev & 0x1f) << 11; - bdf |=3D (func & 0x7) << 8; + sbdf =3D seg << 16; + sbdf |=3D (bus & 0xff) << 8; + sbdf |=3D (dev & 0x1f) << 3; + sbdf |=3D (func & 0x7); =20 - if ( xc_test_assign_device(self->xc_handle, dom, bdf) !=3D 0 ) + if ( xc_test_assign_device(self->xc_handle, dom, sbdf) !=3D 0 ) { if (errno =3D=3D ENOSYS) - bdf =3D -1; + sbdf =3D -1; break; } - bdf =3D 0; + sbdf =3D 0; } =20 - return Py_BuildValue("i", bdf); + return Py_BuildValue("i", sbdf); } =20 static PyObject *pyxc_assign_device(XcObject *self, @@ -641,7 +642,7 @@ static PyObject *pyxc_assign_device(XcOb { uint32_t dom; char *pci_str; - int32_t bdf =3D 0; + int32_t sbdf =3D 0; int seg, bus, dev, func; =20 static char *kwd_list[] =3D { "domid", "pci", NULL }; @@ -651,20 +652,21 @@ static PyObject *pyxc_assign_device(XcOb =20 while ( next_bdf(&pci_str, &seg, &bus, &dev, &func) ) { - bdf |=3D (bus & 0xff) << 16; - bdf |=3D (dev & 0x1f) << 11; - bdf |=3D (func & 0x7) << 8; + sbdf =3D seg << 16; + sbdf |=3D (bus & 0xff) << 8; + sbdf |=3D (dev & 0x1f) << 3; + sbdf |=3D (func & 0x7); =20 - if ( xc_assign_device(self->xc_handle, dom, bdf) !=3D 0 ) + if ( xc_assign_device(self->xc_handle, dom, sbdf) !=3D 0 ) { if (errno =3D=3D ENOSYS) - bdf =3D -1; + sbdf =3D -1; break; } - bdf =3D 0; + sbdf =3D 0; } =20 - return Py_BuildValue("i", bdf); + return Py_BuildValue("i", sbdf); } =20 static PyObject *pyxc_deassign_device(XcObject *self, @@ -673,7 +675,7 @@ static PyObject *pyxc_deassign_device(Xc { uint32_t dom; char *pci_str; - int32_t bdf =3D 0; + int32_t sbdf =3D 0; int seg, bus, dev, func; =20 static char *kwd_list[] =3D { "domid", "pci", NULL }; @@ -683,26 +685,27 @@ static PyObject *pyxc_deassign_device(Xc =20 while ( next_bdf(&pci_str, &seg, &bus, &dev, &func) ) { - bdf |=3D (bus & 0xff) << 16; - bdf |=3D (dev & 0x1f) << 11; - bdf |=3D (func & 0x7) << 8; + sbdf =3D seg << 16; + sbdf |=3D (bus & 0xff) << 8; + sbdf |=3D (dev & 0x1f) << 3; + sbdf |=3D (func & 0x7); =20 - if ( xc_deassign_device(self->xc_handle, dom, bdf) !=3D 0 ) + if ( xc_deassign_device(self->xc_handle, dom, sbdf) !=3D 0 ) { if (errno =3D=3D ENOSYS) - bdf =3D -1; + sbdf =3D -1; break; } - bdf =3D 0; + sbdf =3D 0; } =20 - return Py_BuildValue("i", bdf); + return Py_BuildValue("i", sbdf); } =20 static PyObject *pyxc_get_device_group(XcObject *self, PyObject *args) { - uint32_t bdf =3D 0; + uint32_t sbdf; uint32_t max_sdevs, num_sdevs; int domid, seg, bus, dev, func, rc, i; PyObject *Pystr; @@ -720,12 +723,13 @@ static PyObject *pyxc_get_device_group(X if (sdev_array =3D=3D NULL) return PyErr_NoMemory(); =20 - bdf |=3D (bus & 0xff) << 16; - bdf |=3D (dev & 0x1f) << 11; - bdf |=3D (func & 0x7) << 8; + sbdf =3D seg << 16; + sbdf |=3D (bus & 0xff) << 8; + sbdf |=3D (dev & 0x1f) << 3; + sbdf |=3D (func & 0x7); =20 rc =3D xc_get_device_group(self->xc_handle, - domid, bdf, max_sdevs, &num_sdevs, sdev_array); + domid, sbdf, max_sdevs, &num_sdevs, sdev_array); =20 if ( rc < 0 ) { --- 2011-09-20.orig/xen/arch/ia64/xen/dom0_ops.c 2011-09-19 = 10:58:18.000000000 +0200 +++ 2011-09-20/xen/arch/ia64/xen/dom0_ops.c 2011-09-15 16:32:59.0000000= 00 +0200 @@ -258,138 +258,6 @@ long arch_do_domctl(xen_domctl_t *op, XE } break; =20 - case XEN_DOMCTL_get_device_group: - { - struct domain *d; - u32 max_sdevs; - u8 bus, devfn; - XEN_GUEST_HANDLE_64(uint32) sdevs; - int num_sdevs; - - ret =3D -ENOSYS; - if ( !iommu_enabled ) - break; - - ret =3D -EINVAL; - if ( (d =3D rcu_lock_domain_by_id(op->domain)) =3D=3D NULL ) - break; - - bus =3D (op->u.get_device_group.machine_bdf >> 16) & 0xff; - devfn =3D (op->u.get_device_group.machine_bdf >> 8) & 0xff; - max_sdevs =3D op->u.get_device_group.max_sdevs; - sdevs =3D op->u.get_device_group.sdev_array; - - num_sdevs =3D iommu_get_device_group(d, bus, devfn, sdevs, = max_sdevs); - if ( num_sdevs < 0 ) - { - dprintk(XENLOG_ERR, "iommu_get_device_group() failed!\n"); - ret =3D -EFAULT; - op->u.get_device_group.num_sdevs =3D 0; - } - else - { - ret =3D 0; - op->u.get_device_group.num_sdevs =3D num_sdevs; - } - if ( copy_to_guest(u_domctl, op, 1) ) - ret =3D -EFAULT; - rcu_unlock_domain(d); - } - break; - - case XEN_DOMCTL_test_assign_device: - { - u8 bus, devfn; - - ret =3D -ENOSYS; - if ( !iommu_enabled ) - break; - - ret =3D -EINVAL; - bus =3D (op->u.assign_device.machine_bdf >> 16) & 0xff; - devfn =3D (op->u.assign_device.machine_bdf >> 8) & 0xff; - - if ( device_assigned(bus, devfn) ) - { - printk( "XEN_DOMCTL_test_assign_device: " - "%x:%x.%x already assigned, or non-existent\n", - bus, PCI_SLOT(devfn), PCI_FUNC(devfn)); - break; - } - ret =3D 0; - } - break; - - case XEN_DOMCTL_assign_device: - { - struct domain *d; - u8 bus, devfn; - - ret =3D -ENOSYS; - if ( !iommu_enabled ) - break; - - ret =3D -EINVAL; - if ( unlikely((d =3D get_domain_by_id(op->domain)) =3D=3D NULL) ) - { - gdprintk(XENLOG_ERR, - "XEN_DOMCTL_assign_device: get_domain_by_id() failed\n"); - break; - } - bus =3D (op->u.assign_device.machine_bdf >> 16) & 0xff; - devfn =3D (op->u.assign_device.machine_bdf >> 8) & 0xff; - - if ( device_assigned(bus, devfn) ) - { - gdprintk(XENLOG_ERR, "XEN_DOMCTL_assign_device: " - "%x:%x.%x already assigned, or non-existent\n", - bus, PCI_SLOT(devfn), PCI_FUNC(devfn)); - break; - } - - ret =3D assign_device(d, bus, devfn); - if ( ret ) - gdprintk(XENLOG_ERR, "XEN_DOMCTL_assign_device: " - "assign device (%x:%x.%x) failed\n", - bus, PCI_SLOT(devfn), PCI_FUNC(devfn)); - put_domain(d); - } - break; - - case XEN_DOMCTL_deassign_device: - { - struct domain *d; - u8 bus, devfn; - - ret =3D -ENOSYS; - if ( !iommu_enabled ) - break; - - ret =3D -EINVAL; - if ( unlikely((d =3D get_domain_by_id(op->domain)) =3D=3D NULL) ) - { - gdprintk(XENLOG_ERR, - "XEN_DOMCTL_deassign_device: get_domain_by_id() failed\n")= ; - break; - } - bus =3D (op->u.assign_device.machine_bdf >> 16) & 0xff; - devfn =3D (op->u.assign_device.machine_bdf >> 8) & 0xff; - - if ( !device_assigned(bus, devfn) ) - break; - - spin_lock(&pcidevs_lock); - ret =3D deassign_device(d, bus, devfn); - spin_unlock(&pcidevs_lock); - if ( ret ) - gdprintk(XENLOG_ERR, "XEN_DOMCTL_deassign_device: " - "deassign device (%x:%x.%x) failed\n", - bus, PCI_SLOT(devfn), PCI_FUNC(devfn)); - - put_domain(d); - } - break; - case XEN_DOMCTL_bind_pt_irq: { struct domain * d; @@ -707,8 +575,8 @@ long arch_do_domctl(xen_domctl_t *op, XE break; =20 default: - printk("arch_do_domctl: unrecognized domctl: %d!!!\n",op->cmd); - ret =3D -ENOSYS; + ret =3D iommu_do_domctl(op, u_domctl); + break; =20 } =20 --- 2011-09-20.orig/xen/arch/x86/domctl.c 2011-06-16 09:21:02.0000000= 00 +0200 +++ 2011-09-20/xen/arch/x86/domctl.c 2011-09-15 16:09:39.000000000 = +0200 @@ -742,144 +742,6 @@ long arch_do_domctl( } break; =20 - case XEN_DOMCTL_get_device_group: - { - struct domain *d; - u32 max_sdevs; - u8 bus, devfn; - XEN_GUEST_HANDLE_64(uint32) sdevs; - int num_sdevs; - - ret =3D -ENOSYS; - if ( !iommu_enabled ) - break; - - ret =3D -EINVAL; - if ( (d =3D rcu_lock_domain_by_id(domctl->domain)) =3D=3D NULL ) - break; - - bus =3D (domctl->u.get_device_group.machine_bdf >> 16) & 0xff; - devfn =3D (domctl->u.get_device_group.machine_bdf >> 8) & 0xff; - max_sdevs =3D domctl->u.get_device_group.max_sdevs; - sdevs =3D domctl->u.get_device_group.sdev_array; - - num_sdevs =3D iommu_get_device_group(d, bus, devfn, sdevs, = max_sdevs); - if ( num_sdevs < 0 ) - { - dprintk(XENLOG_ERR, "iommu_get_device_group() failed!\n"); - ret =3D -EFAULT; - domctl->u.get_device_group.num_sdevs =3D 0; - } - else - { - ret =3D 0; - domctl->u.get_device_group.num_sdevs =3D num_sdevs; - } - if ( copy_to_guest(u_domctl, domctl, 1) ) - ret =3D -EFAULT; - rcu_unlock_domain(d); - } - break; - - case XEN_DOMCTL_test_assign_device: - { - u8 bus, devfn; - - ret =3D -ENOSYS; - if ( !iommu_enabled ) - break; - - ret =3D xsm_test_assign_device(domctl->u.assign_device.machine_bdf= ); - if ( ret ) - break; - - ret =3D -EINVAL; - bus =3D (domctl->u.assign_device.machine_bdf >> 16) & 0xff; - devfn =3D (domctl->u.assign_device.machine_bdf >> 8) & 0xff; - - if ( device_assigned(bus, devfn) ) - { - gdprintk(XENLOG_ERR, "XEN_DOMCTL_test_assign_device: " - "%x:%x.%x already assigned, or non-existent\n", - bus, PCI_SLOT(devfn), PCI_FUNC(devfn)); - break; - } - ret =3D 0; - } - break; - - case XEN_DOMCTL_assign_device: - { - struct domain *d; - u8 bus, devfn; - - ret =3D -ENOSYS; - if ( !iommu_enabled ) - break; - - ret =3D -EINVAL; - if ( unlikely((d =3D get_domain_by_id(domctl->domain)) =3D=3D = NULL) ) - { - gdprintk(XENLOG_ERR, - "XEN_DOMCTL_assign_device: get_domain_by_id() failed\n"); - break; - } - - ret =3D xsm_assign_device(d, domctl->u.assign_device.machine_bdf);= - if ( ret ) - goto assign_device_out; - - bus =3D (domctl->u.assign_device.machine_bdf >> 16) & 0xff; - devfn =3D (domctl->u.assign_device.machine_bdf >> 8) & 0xff; - - ret =3D assign_device(d, bus, devfn); - if ( ret ) - gdprintk(XENLOG_ERR, "XEN_DOMCTL_assign_device: " - "assign device (%x:%x.%x) failed\n", - bus, PCI_SLOT(devfn), PCI_FUNC(devfn)); - - assign_device_out: - put_domain(d); - } - break; - - case XEN_DOMCTL_deassign_device: - { - struct domain *d; - u8 bus, devfn; - - ret =3D -ENOSYS; - if ( !iommu_enabled ) - break; - - ret =3D -EINVAL; - if ( unlikely((d =3D get_domain_by_id(domctl->domain)) =3D=3D = NULL) ) - { - gdprintk(XENLOG_ERR, - "XEN_DOMCTL_deassign_device: get_domain_by_id() failed\n")= ; - break; - } - - ret =3D xsm_assign_device(d, domctl->u.assign_device.machine_bdf);= - if ( ret ) - goto deassign_device_out; - - bus =3D (domctl->u.assign_device.machine_bdf >> 16) & 0xff; - devfn =3D (domctl->u.assign_device.machine_bdf >> 8) & 0xff; - - spin_lock(&pcidevs_lock); - ret =3D deassign_device(d, bus, devfn); - spin_unlock(&pcidevs_lock); - if ( ret ) - gdprintk(XENLOG_ERR, "XEN_DOMCTL_deassign_device: " - "deassign device (%x:%x.%x) failed\n", - bus, PCI_SLOT(devfn), PCI_FUNC(devfn)); - - deassign_device_out: - put_domain(d); - } - break; - case XEN_DOMCTL_bind_pt_irq: { struct domain * d; @@ -1601,7 +1463,7 @@ long arch_do_domctl( break; =20 default: - ret =3D -ENOSYS; + ret =3D iommu_do_domctl(domctl, u_domctl); break; } =20 --- 2011-09-20.orig/xen/drivers/passthrough/amd/pci_amd_iommu.c 2011-09-20 = 16:03:27.000000000 +0200 +++ 2011-09-20/xen/drivers/passthrough/amd/pci_amd_iommu.c 2011-09-20 = 16:04:06.000000000 +0200 @@ -305,7 +305,7 @@ static void amd_iommu_disable_domain_dev } =20 static int reassign_device( struct domain *source, struct domain *target, - u8 bus, u8 devfn) + u16 seg, u8 bus, u8 devfn) { struct pci_dev *pdev; struct amd_iommu *iommu; @@ -313,7 +313,7 @@ static int reassign_device( struct domai struct hvm_iommu *t =3D domain_hvm_iommu(target); =20 ASSERT(spin_is_locked(&pcidevs_lock)); - pdev =3D pci_get_pdev_by_domain(source, 0, bus, devfn); + pdev =3D pci_get_pdev_by_domain(source, seg, bus, devfn); if ( !pdev ) return -ENODEV; =20 @@ -346,7 +346,7 @@ static int reassign_device( struct domai return 0; } =20 -static int amd_iommu_assign_device(struct domain *d, u8 bus, u8 devfn) +static int amd_iommu_assign_device(struct domain *d, u16 seg, u8 bus, u8 = devfn) { int bdf =3D (bus << 8) | devfn; int req_id =3D get_dma_requestor_id(bdf); @@ -361,7 +361,7 @@ static int amd_iommu_assign_device(struc ivrs_mappings[req_id].read_permission); } =20 - return reassign_device(dom0, d, bus, devfn); + return reassign_device(dom0, d, seg, bus, devfn); } =20 static void deallocate_next_page_table(struct page_info* pg, int level) @@ -426,9 +426,9 @@ static void amd_iommu_domain_destroy(str } =20 static int amd_iommu_return_device( - struct domain *s, struct domain *t, u8 bus, u8 devfn) + struct domain *s, struct domain *t, u16 seg, u8 bus, u8 devfn) { - return reassign_device(s, t, bus, devfn); + return reassign_device(s, t, seg, bus, devfn); } =20 static int amd_iommu_add_device(struct pci_dev *pdev) @@ -475,7 +475,7 @@ static int amd_iommu_remove_device(struc return 0; } =20 -static int amd_iommu_group_id(u8 bus, u8 devfn) +static int amd_iommu_group_id(u16 seg, u8 bus, u8 devfn) { int rt; int bdf =3D (bus << 8) | devfn; --- 2011-09-20.orig/xen/drivers/passthrough/iommu.c 2011-08-25 = 15:06:35.000000000 +0200 +++ 2011-09-20/xen/drivers/passthrough/iommu.c 2011-09-15 17:00:38.0000000= 00 +0200 @@ -19,6 +19,7 @@ #include <xen/paging.h> #include <xen/guest_access.h> #include <xen/softirq.h> +#include <xsm/xsm.h> =20 static void parse_iommu_param(char *s); static int iommu_populate_page_table(struct domain *d); @@ -165,7 +166,22 @@ int iommu_remove_device(struct pci_dev * return hd->platform_ops->remove_device(pdev); } =20 -int assign_device(struct domain *d, u8 bus, u8 devfn) +/* + * If the device isn't owned by dom0, it means it already + * has been assigned to other domain, or it doesn't exist. + */ +static int device_assigned(u16 seg, u8 bus, u8 devfn) +{ + struct pci_dev *pdev; + + spin_lock(&pcidevs_lock); + pdev =3D pci_get_pdev_by_domain(dom0, seg, bus, devfn); + spin_unlock(&pcidevs_lock); + + return pdev ? 0 : -1; +} + +static int assign_device(struct domain *d, u16 seg, u8 bus, u8 devfn) { struct hvm_iommu *hd =3D domain_hvm_iommu(d); int rc =3D 0; @@ -174,7 +190,7 @@ int assign_device(struct domain *d, u8 b return 0; =20 spin_lock(&pcidevs_lock); - if ( (rc =3D hd->platform_ops->assign_device(d, bus, devfn)) ) + if ( (rc =3D hd->platform_ops->assign_device(d, seg, bus, devfn)) ) goto done; =20 if ( has_arch_pdevs(d) && !need_iommu(d) ) @@ -272,7 +288,7 @@ int iommu_unmap_page(struct domain *d, u } =20 /* caller should hold the pcidevs_lock */ -int deassign_device(struct domain *d, u8 bus, u8 devfn) +int deassign_device(struct domain *d, u16 seg, u8 bus, u8 devfn) { struct hvm_iommu *hd =3D domain_hvm_iommu(d); struct pci_dev *pdev =3D NULL; @@ -282,7 +298,7 @@ int deassign_device(struct domain *d, u8 return -EINVAL; =20 ASSERT(spin_is_locked(&pcidevs_lock)); - pdev =3D pci_get_pdev(0, bus, devfn); + pdev =3D pci_get_pdev(seg, bus, devfn); if ( !pdev ) return -ENODEV; =20 @@ -293,12 +309,12 @@ int deassign_device(struct domain *d, u8 return -EINVAL; } =20 - ret =3D hd->platform_ops->reassign_device(d, dom0, bus, devfn); + ret =3D hd->platform_ops->reassign_device(d, dom0, seg, bus, devfn); if ( ret ) { dprintk(XENLOG_ERR VTDPREFIX, - "d%d: Deassign device (%x:%x.%x) failed!\n", - d->domain_id, bus, PCI_SLOT(devfn), PCI_FUNC(devfn)); + "d%d: Deassign device (%04x:%02x:%02x.%u) failed!\n", + d->domain_id, seg, bus, PCI_SLOT(devfn), PCI_FUNC(devfn));= return ret; } =20 @@ -347,7 +363,8 @@ int __init iommu_setup(void) return rc; } =20 -int iommu_get_device_group(struct domain *d, u8 bus, u8 devfn,=20 +static int iommu_get_device_group( + struct domain *d, u16 seg, u8 bus, u8 devfn, XEN_GUEST_HANDLE_64(uint32) buf, int max_sdevs) { struct hvm_iommu *hd =3D domain_hvm_iommu(d); @@ -360,15 +377,16 @@ int iommu_get_device_group(struct domain if ( !iommu_enabled || !ops || !ops->get_device_group_id ) return 0; =20 - group_id =3D ops->get_device_group_id(bus, devfn); + group_id =3D ops->get_device_group_id(seg, bus, devfn); =20 spin_lock(&pcidevs_lock); for_each_pdev( d, pdev ) { - if ( (pdev->bus =3D=3D bus) && (pdev->devfn =3D=3D devfn) ) + if ( (pdev->seg !=3D seg) || + ((pdev->bus =3D=3D bus) && (pdev->devfn =3D=3D devfn)) ) continue; =20 - sdev_id =3D ops->get_device_group_id(pdev->bus, pdev->devfn); + sdev_id =3D ops->get_device_group_id(seg, pdev->bus, pdev->devfn);= if ( (sdev_id =3D=3D group_id) && (i < max_sdevs) ) { bdf =3D 0; @@ -443,6 +461,154 @@ void iommu_crash_shutdown(void) iommu_enabled =3D 0; } =20 +int iommu_do_domctl( + struct xen_domctl *domctl, + XEN_GUEST_HANDLE(xen_domctl_t) u_domctl) +{ + struct domain *d; + u16 seg; + u8 bus, devfn; + int ret =3D 0; + + if ( !iommu_enabled ) + return -ENOSYS; + + switch ( domctl->cmd ) + { + case XEN_DOMCTL_get_device_group: + { + u32 max_sdevs; + XEN_GUEST_HANDLE_64(uint32) sdevs; + + ret =3D -EINVAL; + if ( (d =3D rcu_lock_domain_by_id(domctl->domain)) =3D=3D NULL ) + break; + + seg =3D domctl->u.get_device_group.machine_sbdf >> 16; + bus =3D (domctl->u.get_device_group.machine_sbdf >> 8) & 0xff; + devfn =3D domctl->u.get_device_group.machine_sbdf & 0xff; + max_sdevs =3D domctl->u.get_device_group.max_sdevs; + sdevs =3D domctl->u.get_device_group.sdev_array; + + ret =3D iommu_get_device_group(d, seg, bus, devfn, sdevs, = max_sdevs); + if ( ret < 0 ) + { + dprintk(XENLOG_ERR, "iommu_get_device_group() failed!\n"); + ret =3D -EFAULT; + domctl->u.get_device_group.num_sdevs =3D 0; + } + else + { + domctl->u.get_device_group.num_sdevs =3D ret; + ret =3D 0; + } + if ( copy_to_guest(u_domctl, domctl, 1) ) + ret =3D -EFAULT; + rcu_unlock_domain(d); + } + break; + + case XEN_DOMCTL_test_assign_device: + ret =3D xsm_test_assign_device(domctl->u.assign_device.machine_sbd= f); + if ( ret ) + break; + + seg =3D domctl->u.get_device_group.machine_sbdf >> 16; + bus =3D (domctl->u.assign_device.machine_sbdf >> 8) & 0xff; + devfn =3D domctl->u.assign_device.machine_sbdf & 0xff; + + if ( device_assigned(seg, bus, devfn) ) + { + gdprintk(XENLOG_ERR, "XEN_DOMCTL_test_assign_device: " + "%04x:%02x:%02x.%u already assigned, or non-existent\= n", + seg, bus, PCI_SLOT(devfn), PCI_FUNC(devfn)); + ret =3D -EINVAL; + } + break; + + case XEN_DOMCTL_assign_device: + if ( unlikely((d =3D get_domain_by_id(domctl->domain)) =3D=3D = NULL) ) + { + gdprintk(XENLOG_ERR, + "XEN_DOMCTL_assign_device: get_domain_by_id() failed\n"); + ret =3D -EINVAL; + break; + } + + ret =3D xsm_assign_device(d, domctl->u.assign_device.machine_sbdf)= ; + if ( ret ) + goto assign_device_out; + + seg =3D domctl->u.get_device_group.machine_sbdf >> 16; + bus =3D (domctl->u.assign_device.machine_sbdf >> 8) & 0xff; + devfn =3D domctl->u.assign_device.machine_sbdf & 0xff; + +#ifdef __ia64__ /* XXX Is this really needed? */ + if ( device_assigned(seg, bus, devfn) ) + { + gdprintk(XENLOG_ERR, "XEN_DOMCTL_assign_device: " + "%x:%x.%x already assigned, or non-existent\n", + bus, PCI_SLOT(devfn), PCI_FUNC(devfn)); + ret =3D -EINVAL; + goto assign_device_out; + } +#endif + + ret =3D assign_device(d, seg, bus, devfn); + if ( ret ) + gdprintk(XENLOG_ERR, "XEN_DOMCTL_assign_device: " + "assign device (%04x:%02x:%02x.%u) failed\n", + seg, bus, PCI_SLOT(devfn), PCI_FUNC(devfn)); + + assign_device_out: + put_domain(d); + break; + + case XEN_DOMCTL_deassign_device: + if ( unlikely((d =3D get_domain_by_id(domctl->domain)) =3D=3D = NULL) ) + { + gdprintk(XENLOG_ERR, + "XEN_DOMCTL_deassign_device: get_domain_by_id() failed\n")= ; + ret =3D -EINVAL; + break; + } + + ret =3D xsm_assign_device(d, domctl->u.assign_device.machine_sbdf)= ; + if ( ret ) + goto deassign_device_out; + + seg =3D domctl->u.get_device_group.machine_sbdf >> 16; + bus =3D (domctl->u.assign_device.machine_sbdf >> 8) & 0xff; + devfn =3D domctl->u.assign_device.machine_sbdf & 0xff; + +#ifdef __ia64__ /* XXX Is this really needed? */ + if ( !device_assigned(seg, bus, devfn) ) + { + ret =3D -EINVAL; + goto deassign_device_out; + } +#endif + + spin_lock(&pcidevs_lock); + ret =3D deassign_device(d, seg, bus, devfn); + spin_unlock(&pcidevs_lock); + if ( ret ) + gdprintk(XENLOG_ERR, "XEN_DOMCTL_deassign_device: " + "deassign device (%04x:%02x:%02x.%u) failed\n", + seg, bus, PCI_SLOT(devfn), PCI_FUNC(devfn)); + + deassign_device_out: + put_domain(d); + break; + + default: + ret =3D -ENOSYS; + break; + } + + return ret; +} + /* * Local variables: * mode: C --- 2011-09-20.orig/xen/drivers/passthrough/pci.c 2011-08-25 = 15:06:35.000000000 +0200 +++ 2011-09-20/xen/drivers/passthrough/pci.c 2011-08-25 15:06:40.0000000= 00 +0200 @@ -441,11 +441,12 @@ void pci_release_devices(struct domain * while ( (pdev =3D pci_get_pdev_by_domain(d, -1, -1, -1)) ) { pci_cleanup_msi(pdev); - bus =3D pdev->bus; devfn =3D pdev->devfn; - if ( deassign_device(d, bus, devfn) ) - printk("domain %d: deassign device (%02x:%02x.%x) failed!\n", - d->domain_id, pdev->bus, PCI_SLOT(pdev->devfn), - PCI_FUNC(pdev->devfn)); + bus =3D pdev->bus; + devfn =3D pdev->devfn; + if ( deassign_device(d, pdev->seg, bus, devfn) ) + printk("domain %d: deassign device (%04x:%02x:%02x.%u) = failed!\n", + d->domain_id, pdev->seg, bus, + PCI_SLOT(devfn), PCI_FUNC(devfn)); } spin_unlock(&pcidevs_lock); } --- 2011-09-20.orig/xen/drivers/passthrough/vtd/iommu.c 2011-09-20 = 16:03:17.000000000 +0200 +++ 2011-09-20/xen/drivers/passthrough/vtd/iommu.c 2011-09-20 = 16:04:11.000000000 +0200 @@ -1626,13 +1626,13 @@ out: static int reassign_device_ownership( struct domain *source, struct domain *target, - u8 bus, u8 devfn) + u16 seg, u8 bus, u8 devfn) { struct pci_dev *pdev; int ret; =20 ASSERT(spin_is_locked(&pcidevs_lock)); - pdev =3D pci_get_pdev_by_domain(source, 0, bus, devfn); + pdev =3D pci_get_pdev_by_domain(source, seg, bus, devfn); =20 if (!pdev) return -ENODEV; @@ -2166,27 +2166,8 @@ int __init intel_vtd_setup(void) return ret; } =20 -/* - * If the device isn't owned by dom0, it means it already - * has been assigned to other domain, or it's not exist. - */ -int device_assigned(u8 bus, u8 devfn) -{ - struct pci_dev *pdev; - - spin_lock(&pcidevs_lock); - pdev =3D pci_get_pdev_by_domain(dom0, 0, bus, devfn); - if (!pdev) - { - spin_unlock(&pcidevs_lock); - return -1; - } - - spin_unlock(&pcidevs_lock); - return 0; -} - -static int intel_iommu_assign_device(struct domain *d, u8 bus, u8 devfn) +static int intel_iommu_assign_device( + struct domain *d, u16 seg, u8 bus, u8 devfn) { struct acpi_rmrr_unit *rmrr; int ret =3D 0, i; @@ -2197,7 +2178,7 @@ static int intel_iommu_assign_device(str return -ENODEV; =20 ASSERT(spin_is_locked(&pcidevs_lock)); - pdev =3D pci_get_pdev(0, bus, devfn); + pdev =3D pci_get_pdev(seg, bus, devfn); if (!pdev) return -ENODEV; =20 @@ -2208,7 +2189,7 @@ static int intel_iommu_assign_device(str return -EBUSY; } =20 - ret =3D reassign_device_ownership(dom0, d, bus, devfn); + ret =3D reassign_device_ownership(dom0, d, seg, bus, devfn); if ( ret ) goto done; =20 @@ -2240,7 +2221,7 @@ done: return ret; } =20 -static int intel_iommu_group_id(u8 bus, u8 devfn) +static int intel_iommu_group_id(u16 seg, u8 bus, u8 devfn) { u8 secbus; if ( find_upstream_bridge(&bus, &devfn, &secbus) < 0 ) --- 2011-09-20.orig/xen/include/public/domctl.h 2011-09-19 10:58:18.0000000= 00 +0200 +++ 2011-09-20/xen/include/public/domctl.h 2011-09-15 15:39:21.0000000= 00 +0200 @@ -455,15 +455,15 @@ DEFINE_XEN_GUEST_HANDLE(xen_domctl_sendt /* XEN_DOMCTL_test_assign_device */ /* XEN_DOMCTL_deassign_device */ struct xen_domctl_assign_device { - uint32_t machine_bdf; /* machine PCI ID of assigned device */ + uint32_t machine_sbdf; /* machine PCI ID of assigned device */ }; typedef struct xen_domctl_assign_device xen_domctl_assign_device_t; DEFINE_XEN_GUEST_HANDLE(xen_domctl_assign_device_t); =20 -/* Retrieve sibling devices infomation of machine_bdf */ +/* Retrieve sibling devices infomation of machine_sbdf */ /* XEN_DOMCTL_get_device_group */ struct xen_domctl_get_device_group { - uint32_t machine_bdf; /* IN */ + uint32_t machine_sbdf; /* IN */ uint32_t max_sdevs; /* IN */ uint32_t num_sdevs; /* OUT */ XEN_GUEST_HANDLE_64(uint32) sdev_array; /* OUT */ --- 2011-09-20.orig/xen/include/xen/iommu.h 2011-08-25 15:06:23.0000000= 00 +0200 +++ 2011-09-20/xen/include/xen/iommu.h 2011-09-15 16:46:28.000000000 = +0200 @@ -74,11 +74,7 @@ int iommu_remove_device(struct pci_dev * int iommu_domain_init(struct domain *d); void iommu_dom0_init(struct domain *d); void iommu_domain_destroy(struct domain *d); -int device_assigned(u8 bus, u8 devfn); -int assign_device(struct domain *d, u8 bus, u8 devfn); -int deassign_device(struct domain *d, u8 bus, u8 devfn); -int iommu_get_device_group(struct domain *d, u8 bus, u8 devfn, - XEN_GUEST_HANDLE_64(uint32) buf, int max_sdevs); +int deassign_device(struct domain *d, u16 seg, u8 bus, u8 devfn); =20 /* iommu_map_page() takes flags to direct the mapping operation. */ #define _IOMMUF_readable 0 @@ -125,14 +121,14 @@ struct iommu_ops { void (*dom0_init)(struct domain *d); int (*add_device)(struct pci_dev *pdev); int (*remove_device)(struct pci_dev *pdev); - int (*assign_device)(struct domain *d, u8 bus, u8 devfn); + int (*assign_device)(struct domain *d, u16 seg, u8 bus, u8 devfn); void (*teardown)(struct domain *d); int (*map_page)(struct domain *d, unsigned long gfn, unsigned long = mfn, unsigned int flags); int (*unmap_page)(struct domain *d, unsigned long gfn); int (*reassign_device)(struct domain *s, struct domain *t, - u8 bus, u8 devfn); - int (*get_device_group_id)(u8 bus, u8 devfn); + u16 seg, u8 bus, u8 devfn); + int (*get_device_group_id)(u16 seg, u8 bus, u8 devfn); void (*update_ire_from_apic)(unsigned int apic, unsigned int reg, = unsigned int value); void (*update_ire_from_msi)(struct msi_desc *msi_desc, struct msi_msg = *msg); void (*read_msi_from_ire)(struct msi_desc *msi_desc, struct msi_msg = *msg); @@ -155,4 +151,6 @@ void iommu_crash_shutdown(void); void iommu_set_dom0_mapping(struct domain *d); void iommu_share_p2m_table(struct domain *d); =20 +int iommu_do_domctl(struct xen_domctl *, XEN_GUEST_HANDLE(xen_domctl_t)); + #endif /* _IOMMU_H_ */ --=__Part56796DA6.0__= Content-Type: text/plain; name="pci-multi-seg-domctl.patch" Content-Transfer-Encoding: quoted-printable Content-Disposition: attachment; filename="pci-multi-seg-domctl.patch" Again, a couple of directly related functions at once get adjusted = to=0Aaccount for the segment number.=0A=0ADo we need to bump XEN_DOMCTL_INT= ERFACE_VERSION for the changes to the=0Adomctl interface (namely the = renaming and bit-reassigment of the=0Amachine_bdf member of two of the = interface structures)? If so, this=0Acan probably be done as the patch = gets checked in (rather than me=0Ahaving to re-submit)?=0A=0ASigned-off-by:= Jan Beulich <jbeulich@suse.com>=0A=0A--- 2011-09-20.orig/tools/libxc/xc_do= main.c 2011-06-16 09:21:02.000000000 +0200=0A+++ 2011-09-20/tools/libxc/xc= _domain.c 2011-09-15 16:51:12.000000000 +0200=0A@@ -1132,13 +1132,13 = @@ int xc_domain_setdebugging(xc_interface =0A int xc_assign_device(=0A = xc_interface *xch,=0A uint32_t domid,=0A- uint32_t machine_bdf)=0A+= uint32_t machine_sbdf)=0A {=0A DECLARE_DOMCTL;=0A =0A = domctl.cmd =3D XEN_DOMCTL_assign_device;=0A domctl.domain =3D = domid;=0A- domctl.u.assign_device.machine_bdf =3D machine_bdf;=0A+ = domctl.u.assign_device.machine_sbdf =3D machine_sbdf;=0A =0A return = do_domctl(xch, &domctl);=0A }=0A@@ -1146,7 +1146,7 @@ int xc_assign_device(= =0A int xc_get_device_group(=0A xc_interface *xch,=0A uint32_t = domid,=0A- uint32_t machine_bdf,=0A+ uint32_t machine_sbdf,=0A = uint32_t max_sdevs,=0A uint32_t *num_sdevs,=0A uint32_t *sdev_array= )=0A@@ -1164,7 +1164,7 @@ int xc_get_device_group(=0A domctl.cmd =3D = XEN_DOMCTL_get_device_group;=0A domctl.domain =3D (domid_t)domid;=0A = =0A- domctl.u.get_device_group.machine_bdf =3D machine_bdf;=0A+ = domctl.u.get_device_group.machine_sbdf =3D machine_sbdf;=0A domctl.u.ge= t_device_group.max_sdevs =3D max_sdevs;=0A =0A set_xen_guest_handle(dom= ctl.u.get_device_group.sdev_array, sdev_array);=0A@@ -1181,13 +1181,13 @@ = int xc_get_device_group(=0A int xc_test_assign_device(=0A xc_interface = *xch,=0A uint32_t domid,=0A- uint32_t machine_bdf)=0A+ uint32_t = machine_sbdf)=0A {=0A DECLARE_DOMCTL;=0A =0A domctl.cmd =3D = XEN_DOMCTL_test_assign_device;=0A domctl.domain =3D domid;=0A- = domctl.u.assign_device.machine_bdf =3D machine_bdf;=0A+ domctl.u.assign_= device.machine_sbdf =3D machine_sbdf;=0A =0A return do_domctl(xch, = &domctl);=0A }=0A@@ -1195,13 +1195,13 @@ int xc_test_assign_device(=0A int = xc_deassign_device(=0A xc_interface *xch,=0A uint32_t domid,=0A- = uint32_t machine_bdf)=0A+ uint32_t machine_sbdf)=0A {=0A DECLARE_DO= MCTL;=0A =0A domctl.cmd =3D XEN_DOMCTL_deassign_device;=0A = domctl.domain =3D domid;=0A- domctl.u.assign_device.machine_bdf =3D = machine_bdf;=0A+ domctl.u.assign_device.machine_sbdf =3D machine_sbdf;= =0A =0A return do_domctl(xch, &domctl);=0A }=0A--- 2011-09-20.orig/too= ls/libxl/libxl_pci.c 2011-09-05 09:12:30.000000000 +0200=0A+++ = 2011-09-20/tools/libxl/libxl_pci.c 2011-09-15 15:40:28.000000000 = +0200=0A@@ -45,10 +45,10 @@ static unsigned int pcidev_encode_bdf(li=0A = {=0A unsigned int value;=0A =0A- value =3D 0;=0A- value |=3D = (pcidev->bus & 0xff) << 16;=0A- value |=3D (pcidev->dev & 0x1f) << = (8+3);=0A- value |=3D (pcidev->func & 0x7) << (8+0);=0A+ value =3D = pcidev->domain << 16;=0A+ value |=3D (pcidev->bus & 0xff) << 8;=0A+ = value |=3D (pcidev->dev & 0x1f) << 3;=0A+ value |=3D (pcidev->func & = 0x7);=0A =0A return value;=0A }=0A--- 2011-09-20.orig/tools/python/xen/= lowlevel/xc/xc.c 2010-11-05 09:22:58.000000000 +0100=0A+++ = 2011-09-20/tools/python/xen/lowlevel/xc/xc.c 2011-09-15 15:48:10.0000000= 00 +0200=0A@@ -609,7 +609,7 @@ static PyObject *pyxc_test_assign_device=0A = {=0A uint32_t dom;=0A char *pci_str;=0A- int32_t bdf =3D 0;=0A+ = int32_t sbdf =3D 0;=0A int seg, bus, dev, func;=0A =0A static = char *kwd_list[] =3D { "domid", "pci", NULL };=0A@@ -619,20 +619,21 @@ = static PyObject *pyxc_test_assign_device=0A =0A while ( next_bdf(&pci_s= tr, &seg, &bus, &dev, &func) )=0A {=0A- bdf |=3D (bus & 0xff) = << 16;=0A- bdf |=3D (dev & 0x1f) << 11;=0A- bdf |=3D (func & = 0x7) << 8;=0A+ sbdf =3D seg << 16;=0A+ sbdf |=3D (bus & = 0xff) << 8;=0A+ sbdf |=3D (dev & 0x1f) << 3;=0A+ sbdf |=3D = (func & 0x7);=0A =0A- if ( xc_test_assign_device(self->xc_handle, = dom, bdf) !=3D 0 )=0A+ if ( xc_test_assign_device(self->xc_handle, = dom, sbdf) !=3D 0 )=0A {=0A if (errno =3D=3D ENOSYS)=0A= - bdf =3D -1;=0A+ sbdf =3D -1;=0A = break;=0A }=0A- bdf =3D 0;=0A+ sbdf =3D 0;=0A = }=0A =0A- return Py_BuildValue("i", bdf);=0A+ return Py_BuildValue("i= ", sbdf);=0A }=0A =0A static PyObject *pyxc_assign_device(XcObject = *self,=0A@@ -641,7 +642,7 @@ static PyObject *pyxc_assign_device(XcOb=0A = {=0A uint32_t dom;=0A char *pci_str;=0A- int32_t bdf =3D 0;=0A+ = int32_t sbdf =3D 0;=0A int seg, bus, dev, func;=0A =0A static = char *kwd_list[] =3D { "domid", "pci", NULL };=0A@@ -651,20 +652,21 @@ = static PyObject *pyxc_assign_device(XcOb=0A =0A while ( next_bdf(&pci_s= tr, &seg, &bus, &dev, &func) )=0A {=0A- bdf |=3D (bus & 0xff) = << 16;=0A- bdf |=3D (dev & 0x1f) << 11;=0A- bdf |=3D (func & = 0x7) << 8;=0A+ sbdf =3D seg << 16;=0A+ sbdf |=3D (bus & = 0xff) << 8;=0A+ sbdf |=3D (dev & 0x1f) << 3;=0A+ sbdf |=3D = (func & 0x7);=0A =0A- if ( xc_assign_device(self->xc_handle, dom, = bdf) !=3D 0 )=0A+ if ( xc_assign_device(self->xc_handle, dom, sbdf) = !=3D 0 )=0A {=0A if (errno =3D=3D ENOSYS)=0A- = bdf =3D -1;=0A+ sbdf =3D -1;=0A break;=0A = }=0A- bdf =3D 0;=0A+ sbdf =3D 0;=0A }=0A =0A- = return Py_BuildValue("i", bdf);=0A+ return Py_BuildValue("i", sbdf);=0A = }=0A =0A static PyObject *pyxc_deassign_device(XcObject *self,=0A@@ -673,7 = +675,7 @@ static PyObject *pyxc_deassign_device(Xc=0A {=0A uint32_t = dom;=0A char *pci_str;=0A- int32_t bdf =3D 0;=0A+ int32_t sbdf = =3D 0;=0A int seg, bus, dev, func;=0A =0A static char *kwd_list[] = =3D { "domid", "pci", NULL };=0A@@ -683,26 +685,27 @@ static PyObject = *pyxc_deassign_device(Xc=0A =0A while ( next_bdf(&pci_str, &seg, &bus, = &dev, &func) )=0A {=0A- bdf |=3D (bus & 0xff) << 16;=0A- = bdf |=3D (dev & 0x1f) << 11;=0A- bdf |=3D (func & 0x7) << 8;=0A+ = sbdf =3D seg << 16;=0A+ sbdf |=3D (bus & 0xff) << 8;=0A+ = sbdf |=3D (dev & 0x1f) << 3;=0A+ sbdf |=3D (func & 0x7);=0A =0A- = if ( xc_deassign_device(self->xc_handle, dom, bdf) !=3D 0 )=0A+ = if ( xc_deassign_device(self->xc_handle, dom, sbdf) !=3D 0 )=0A = {=0A if (errno =3D=3D ENOSYS)=0A- bdf =3D = -1;=0A+ sbdf =3D -1;=0A break;=0A }=0A- = bdf =3D 0;=0A+ sbdf =3D 0;=0A }=0A =0A- return = Py_BuildValue("i", bdf);=0A+ return Py_BuildValue("i", sbdf);=0A }=0A = =0A static PyObject *pyxc_get_device_group(XcObject *self,=0A = PyObject *args)=0A {=0A- uint32_t bdf =3D = 0;=0A+ uint32_t sbdf;=0A uint32_t max_sdevs, num_sdevs;=0A int = domid, seg, bus, dev, func, rc, i;=0A PyObject *Pystr;=0A@@ -720,12 = +723,13 @@ static PyObject *pyxc_get_device_group(X=0A if (sdev_array = =3D=3D NULL)=0A return PyErr_NoMemory();=0A =0A- bdf |=3D (bus = & 0xff) << 16;=0A- bdf |=3D (dev & 0x1f) << 11;=0A- bdf |=3D (func & = 0x7) << 8;=0A+ sbdf =3D seg << 16;=0A+ sbdf |=3D (bus & 0xff) << = 8;=0A+ sbdf |=3D (dev & 0x1f) << 3;=0A+ sbdf |=3D (func & 0x7);=0A = =0A rc =3D xc_get_device_group(self->xc_handle,=0A- domid, bdf, = max_sdevs, &num_sdevs, sdev_array);=0A+ domid, sbdf, max_sdevs, = &num_sdevs, sdev_array);=0A =0A if ( rc < 0 )=0A {=0A--- 2011-09-20= .orig/xen/arch/ia64/xen/dom0_ops.c 2011-09-19 10:58:18.000000000 = +0200=0A+++ 2011-09-20/xen/arch/ia64/xen/dom0_ops.c 2011-09-15 = 16:32:59.000000000 +0200=0A@@ -258,138 +258,6 @@ long arch_do_domctl(xen_do= mctl_t *op, XE=0A }=0A break;=0A =0A- case XEN_DOMCTL_get_device= _group:=0A- {=0A- struct domain *d;=0A- u32 max_sdevs;=0A-= u8 bus, devfn;=0A- XEN_GUEST_HANDLE_64(uint32) sdevs;=0A- = int num_sdevs;=0A-=0A- ret =3D -ENOSYS;=0A- if ( = !iommu_enabled )=0A- break;=0A-=0A- ret =3D -EINVAL;=0A- = if ( (d =3D rcu_lock_domain_by_id(op->domain)) =3D=3D NULL )=0A- = break;=0A-=0A- bus =3D (op->u.get_device_group.machine_bdf = >> 16) & 0xff;=0A- devfn =3D (op->u.get_device_group.machine_bdf >> = 8) & 0xff;=0A- max_sdevs =3D op->u.get_device_group.max_sdevs;=0A- = sdevs =3D op->u.get_device_group.sdev_array;=0A-=0A- = num_sdevs =3D iommu_get_device_group(d, bus, devfn, sdevs, max_sdevs);=0A- = if ( num_sdevs < 0 )=0A- {=0A- dprintk(XENLOG_ERR,= "iommu_get_device_group() failed!\n");=0A- ret =3D -EFAULT;=0A-= op->u.get_device_group.num_sdevs =3D 0;=0A- }=0A- = else=0A- {=0A- ret =3D 0;=0A- op->u.get_devic= e_group.num_sdevs =3D num_sdevs;=0A- }=0A- if ( copy_to_guest= (u_domctl, op, 1) )=0A- ret =3D -EFAULT;=0A- rcu_unlock_d= omain(d);=0A- }=0A- break;=0A-=0A- case XEN_DOMCTL_test_assign_dev= ice:=0A- {=0A- u8 bus, devfn;=0A-=0A- ret =3D -ENOSYS;=0A-= if ( !iommu_enabled )=0A- break;=0A-=0A- ret =3D = -EINVAL;=0A- bus =3D (op->u.assign_device.machine_bdf >> 16) & = 0xff;=0A- devfn =3D (op->u.assign_device.machine_bdf >> 8) & = 0xff;=0A-=0A- if ( device_assigned(bus, devfn) )=0A- {=0A- = printk( "XEN_DOMCTL_test_assign_device: "=0A- = "%x:%x.%x already assigned, or non-existent\n",=0A- = bus, PCI_SLOT(devfn), PCI_FUNC(devfn));=0A- break;=0A- = }=0A- ret =3D 0;=0A- }=0A- break;=0A-=0A- case XEN_DOMCTL_a= ssign_device:=0A- {=0A- struct domain *d;=0A- u8 bus, = devfn;=0A-=0A- ret =3D -ENOSYS;=0A- if ( !iommu_enabled = )=0A- break;=0A-=0A- ret =3D -EINVAL;=0A- if ( = unlikely((d =3D get_domain_by_id(op->domain)) =3D=3D NULL) )=0A- = {=0A- gdprintk(XENLOG_ERR,=0A- "XEN_DOMCTL_assign= _device: get_domain_by_id() failed\n");=0A- break;=0A- = }=0A- bus =3D (op->u.assign_device.machine_bdf >> 16) & 0xff;=0A- = devfn =3D (op->u.assign_device.machine_bdf >> 8) & 0xff;=0A-=0A- = if ( device_assigned(bus, devfn) )=0A- {=0A- gdprintk(X= ENLOG_ERR, "XEN_DOMCTL_assign_device: "=0A- "%x:%x.%x = already assigned, or non-existent\n",=0A- bus, = PCI_SLOT(devfn), PCI_FUNC(devfn));=0A- break;=0A- = }=0A-=0A- ret =3D assign_device(d, bus, devfn);=0A- if ( ret = )=0A- gdprintk(XENLOG_ERR, "XEN_DOMCTL_assign_device: "=0A- = "assign device (%x:%x.%x) failed\n",=0A- = bus, PCI_SLOT(devfn), PCI_FUNC(devfn));=0A- put_domain(d);=0A- = }=0A- break;=0A-=0A- case XEN_DOMCTL_deassign_device:=0A- {=0A- = struct domain *d;=0A- u8 bus, devfn;=0A-=0A- ret =3D = -ENOSYS;=0A- if ( !iommu_enabled )=0A- break;=0A-=0A- = ret =3D -EINVAL;=0A- if ( unlikely((d =3D get_domain_by_id(op->d= omain)) =3D=3D NULL) )=0A- {=0A- gdprintk(XENLOG_ERR,=0A-= "XEN_DOMCTL_deassign_device: get_domain_by_id() failed\n");= =0A- break;=0A- }=0A- bus =3D (op->u.assign_device= .machine_bdf >> 16) & 0xff;=0A- devfn =3D (op->u.assign_device.machi= ne_bdf >> 8) & 0xff;=0A-=0A- if ( !device_assigned(bus, devfn) = )=0A- break;=0A-=0A- spin_lock(&pcidevs_lock);=0A- = ret =3D deassign_device(d, bus, devfn);=0A- spin_unlock(&pcidevs_lo= ck);=0A- if ( ret )=0A- gdprintk(XENLOG_ERR, "XEN_DOMCTL_= deassign_device: "=0A- "deassign device (%x:%x.%x) = failed\n",=0A- bus, PCI_SLOT(devfn), PCI_FUNC(devfn));= =0A-=0A- put_domain(d);=0A- }=0A- break;=0A-=0A case = XEN_DOMCTL_bind_pt_irq:=0A {=0A struct domain * d;=0A@@ -707,8 = +575,8 @@ long arch_do_domctl(xen_domctl_t *op, XE=0A break;=0A =0A = default:=0A- printk("arch_do_domctl: unrecognized domctl: = %d!!!\n",op->cmd);=0A- ret =3D -ENOSYS;=0A+ ret =3D = iommu_do_domctl(op, u_domctl);=0A+ break;=0A =0A }=0A =0A--- = 2011-09-20.orig/xen/arch/x86/domctl.c 2011-06-16 09:21:02.000000000 = +0200=0A+++ 2011-09-20/xen/arch/x86/domctl.c 2011-09-15 16:09:39.0000000= 00 +0200=0A@@ -742,144 +742,6 @@ long arch_do_domctl(=0A }=0A = break;=0A =0A- case XEN_DOMCTL_get_device_group:=0A- {=0A- = struct domain *d;=0A- u32 max_sdevs;=0A- u8 bus, devfn;=0A- = XEN_GUEST_HANDLE_64(uint32) sdevs;=0A- int num_sdevs;=0A-=0A- = ret =3D -ENOSYS;=0A- if ( !iommu_enabled )=0A- = break;=0A-=0A- ret =3D -EINVAL;=0A- if ( (d =3D rcu_lock_doma= in_by_id(domctl->domain)) =3D=3D NULL )=0A- break;=0A-=0A- = bus =3D (domctl->u.get_device_group.machine_bdf >> 16) & 0xff;=0A- = devfn =3D (domctl->u.get_device_group.machine_bdf >> 8) & 0xff;=0A- = max_sdevs =3D domctl->u.get_device_group.max_sdevs;=0A- sdevs =3D = domctl->u.get_device_group.sdev_array;=0A-=0A- num_sdevs =3D = iommu_get_device_group(d, bus, devfn, sdevs, max_sdevs);=0A- if ( = num_sdevs < 0 )=0A- {=0A- dprintk(XENLOG_ERR, "iommu_get_= device_group() failed!\n");=0A- ret =3D -EFAULT;=0A- = domctl->u.get_device_group.num_sdevs =3D 0;=0A- }=0A- = else=0A- {=0A- ret =3D 0;=0A- domctl->u.get_de= vice_group.num_sdevs =3D num_sdevs;=0A- }=0A- if ( copy_to_gu= est(u_domctl, domctl, 1) )=0A- ret =3D -EFAULT;=0A- = rcu_unlock_domain(d);=0A- }=0A- break;=0A-=0A- case XEN_DOMCTL_tes= t_assign_device:=0A- {=0A- u8 bus, devfn;=0A-=0A- ret =3D = -ENOSYS;=0A- if ( !iommu_enabled )=0A- break;=0A-=0A- = ret =3D xsm_test_assign_device(domctl->u.assign_device.machine_bdf);=0A= - if ( ret )=0A- break;=0A-=0A- ret =3D = -EINVAL;=0A- bus =3D (domctl->u.assign_device.machine_bdf >> 16) & = 0xff;=0A- devfn =3D (domctl->u.assign_device.machine_bdf >> 8) & = 0xff;=0A-=0A- if ( device_assigned(bus, devfn) )=0A- {=0A- = gdprintk(XENLOG_ERR, "XEN_DOMCTL_test_assign_device: "=0A- = "%x:%x.%x already assigned, or non-existent\n",=0A- = bus, PCI_SLOT(devfn), PCI_FUNC(devfn));=0A- break;=0A-= }=0A- ret =3D 0;=0A- }=0A- break;=0A-=0A- case = XEN_DOMCTL_assign_device:=0A- {=0A- struct domain *d;=0A- = u8 bus, devfn;=0A-=0A- ret =3D -ENOSYS;=0A- if ( !iommu_enabl= ed )=0A- break;=0A-=0A- ret =3D -EINVAL;=0A- if ( = unlikely((d =3D get_domain_by_id(domctl->domain)) =3D=3D NULL) )=0A- = {=0A- gdprintk(XENLOG_ERR,=0A- "XEN_DOMCTL_assig= n_device: get_domain_by_id() failed\n");=0A- break;=0A- = }=0A-=0A- ret =3D xsm_assign_device(d, domctl->u.assign_device.machi= ne_bdf);=0A- if ( ret )=0A- goto assign_device_out;=0A-= =0A- bus =3D (domctl->u.assign_device.machine_bdf >> 16) & = 0xff;=0A- devfn =3D (domctl->u.assign_device.machine_bdf >> 8) & = 0xff;=0A-=0A- ret =3D assign_device(d, bus, devfn);=0A- if ( = ret )=0A- gdprintk(XENLOG_ERR, "XEN_DOMCTL_assign_device: "=0A- = "assign device (%x:%x.%x) failed\n",=0A- = bus, PCI_SLOT(devfn), PCI_FUNC(devfn));=0A-=0A- assign_device_out:= =0A- put_domain(d);=0A- }=0A- break;=0A-=0A- case = XEN_DOMCTL_deassign_device:=0A- {=0A- struct domain *d;=0A- = u8 bus, devfn;=0A-=0A- ret =3D -ENOSYS;=0A- if ( !iommu_ena= bled )=0A- break;=0A-=0A- ret =3D -EINVAL;=0A- if = ( unlikely((d =3D get_domain_by_id(domctl->domain)) =3D=3D NULL) )=0A- = {=0A- gdprintk(XENLOG_ERR,=0A- "XEN_DOMCTL_dea= ssign_device: get_domain_by_id() failed\n");=0A- break;=0A- = }=0A-=0A- ret =3D xsm_assign_device(d, domctl->u.assign_device.ma= chine_bdf);=0A- if ( ret )=0A- goto deassign_device_out;= =0A-=0A- bus =3D (domctl->u.assign_device.machine_bdf >> 16) & = 0xff;=0A- devfn =3D (domctl->u.assign_device.machine_bdf >> 8) & = 0xff;=0A-=0A- spin_lock(&pcidevs_lock);=0A- ret =3D = deassign_device(d, bus, devfn);=0A- spin_unlock(&pcidevs_lock);=0A- = if ( ret )=0A- gdprintk(XENLOG_ERR, "XEN_DOMCTL_deassign_= device: "=0A- "deassign device (%x:%x.%x) failed\n",=0A= - bus, PCI_SLOT(devfn), PCI_FUNC(devfn));=0A-=0A- = deassign_device_out:=0A- put_domain(d);=0A- }=0A- break;=0A-= =0A case XEN_DOMCTL_bind_pt_irq:=0A {=0A struct domain * = d;=0A@@ -1601,7 +1463,7 @@ long arch_do_domctl(=0A break;=0A =0A = default:=0A- ret =3D -ENOSYS;=0A+ ret =3D iommu_do_domctl(dom= ctl, u_domctl);=0A break;=0A }=0A =0A--- 2011-09-20.orig/xen/dr= ivers/passthrough/amd/pci_amd_iommu.c 2011-09-20 16:03:27.000000000 = +0200=0A+++ 2011-09-20/xen/drivers/passthrough/amd/pci_amd_iommu.c = 2011-09-20 16:04:06.000000000 +0200=0A@@ -305,7 +305,7 @@ static void = amd_iommu_disable_domain_dev=0A }=0A =0A static int reassign_device( = struct domain *source, struct domain *target,=0A- = u8 bus, u8 devfn)=0A+ u16 seg, u8 bus, u8 = devfn)=0A {=0A struct pci_dev *pdev;=0A struct amd_iommu *iommu;=0A= @@ -313,7 +313,7 @@ static int reassign_device( struct domai=0A struct = hvm_iommu *t =3D domain_hvm_iommu(target);=0A =0A ASSERT(spin_is_locked= (&pcidevs_lock));=0A- pdev =3D pci_get_pdev_by_domain(source, 0, bus, = devfn);=0A+ pdev =3D pci_get_pdev_by_domain(source, seg, bus, devfn);=0A= if ( !pdev )=0A return -ENODEV;=0A =0A@@ -346,7 +346,7 @@ = static int reassign_device( struct domai=0A return 0;=0A }=0A = =0A-static int amd_iommu_assign_device(struct domain *d, u8 bus, u8 = devfn)=0A+static int amd_iommu_assign_device(struct domain *d, u16 seg, u8 = bus, u8 devfn)=0A {=0A int bdf =3D (bus << 8) | devfn;=0A int = req_id =3D get_dma_requestor_id(bdf);=0A@@ -361,7 +361,7 @@ static int = amd_iommu_assign_device(struc=0A ivrs_mappings[req_id].read_per= mission);=0A }=0A =0A- return reassign_device(dom0, d, bus, = devfn);=0A+ return reassign_device(dom0, d, seg, bus, devfn);=0A }=0A = =0A static void deallocate_next_page_table(struct page_info* pg, int = level)=0A@@ -426,9 +426,9 @@ static void amd_iommu_domain_destroy(str=0A = }=0A =0A static int amd_iommu_return_device(=0A- struct domain *s, = struct domain *t, u8 bus, u8 devfn)=0A+ struct domain *s, struct domain = *t, u16 seg, u8 bus, u8 devfn)=0A {=0A- return reassign_device(s, t, = bus, devfn);=0A+ return reassign_device(s, t, seg, bus, devfn);=0A }=0A = =0A static int amd_iommu_add_device(struct pci_dev *pdev)=0A@@ -475,7 = +475,7 @@ static int amd_iommu_remove_device(struc=0A return 0;=0A = }=0A =0A-static int amd_iommu_group_id(u8 bus, u8 devfn)=0A+static int = amd_iommu_group_id(u16 seg, u8 bus, u8 devfn)=0A {=0A int rt;=0A = int bdf =3D (bus << 8) | devfn;=0A--- 2011-09-20.orig/xen/drivers/passthrou= gh/iommu.c 2011-08-25 15:06:35.000000000 +0200=0A+++ 2011-09-20/xen/dr= ivers/passthrough/iommu.c 2011-09-15 17:00:38.000000000 +0200=0A@@ = -19,6 +19,7 @@=0A #include <xen/paging.h>=0A #include <xen/guest_access.h>= =0A #include <xen/softirq.h>=0A+#include <xsm/xsm.h>=0A =0A static void = parse_iommu_param(char *s);=0A static int iommu_populate_page_table(struct = domain *d);=0A@@ -165,7 +166,22 @@ int iommu_remove_device(struct pci_dev = *=0A return hd->platform_ops->remove_device(pdev);=0A }=0A =0A-int = assign_device(struct domain *d, u8 bus, u8 devfn)=0A+/*=0A+ * If the = device isn't owned by dom0, it means it already=0A+ * has been assigned to = other domain, or it doesn't exist.=0A+ */=0A+static int device_assigned(u16= seg, u8 bus, u8 devfn)=0A+{=0A+ struct pci_dev *pdev;=0A+=0A+ = spin_lock(&pcidevs_lock);=0A+ pdev =3D pci_get_pdev_by_domain(dom0, = seg, bus, devfn);=0A+ spin_unlock(&pcidevs_lock);=0A+=0A+ return = pdev ? 0 : -1;=0A+}=0A+=0A+static int assign_device(struct domain *d, u16 = seg, u8 bus, u8 devfn)=0A {=0A struct hvm_iommu *hd =3D domain_hvm_iomm= u(d);=0A int rc =3D 0;=0A@@ -174,7 +190,7 @@ int assign_device(struct = domain *d, u8 b=0A return 0;=0A =0A spin_lock(&pcidevs_lock);= =0A- if ( (rc =3D hd->platform_ops->assign_device(d, bus, devfn)) )=0A+ = if ( (rc =3D hd->platform_ops->assign_device(d, seg, bus, devfn)) )=0A = goto done;=0A =0A if ( has_arch_pdevs(d) && !need_iommu(d) = )=0A@@ -272,7 +288,7 @@ int iommu_unmap_page(struct domain *d, u=0A }=0A = =0A /* caller should hold the pcidevs_lock */=0A-int deassign_device(struct= domain *d, u8 bus, u8 devfn)=0A+int deassign_device(struct domain *d, u16 = seg, u8 bus, u8 devfn)=0A {=0A struct hvm_iommu *hd =3D domain_hvm_iomm= u(d);=0A struct pci_dev *pdev =3D NULL;=0A@@ -282,7 +298,7 @@ int = deassign_device(struct domain *d, u8=0A return -EINVAL;=0A =0A = ASSERT(spin_is_locked(&pcidevs_lock));=0A- pdev =3D pci_get_pdev(0, = bus, devfn);=0A+ pdev =3D pci_get_pdev(seg, bus, devfn);=0A if ( = !pdev )=0A return -ENODEV;=0A =0A@@ -293,12 +309,12 @@ int = deassign_device(struct domain *d, u8=0A return -EINVAL;=0A = }=0A =0A- ret =3D hd->platform_ops->reassign_device(d, dom0, bus, = devfn);=0A+ ret =3D hd->platform_ops->reassign_device(d, dom0, seg, = bus, devfn);=0A if ( ret )=0A {=0A dprintk(XENLOG_ERR = VTDPREFIX,=0A- "d%d: Deassign device (%x:%x.%x) failed!\n",= =0A- d->domain_id, bus, PCI_SLOT(devfn), PCI_FUNC(devfn));= =0A+ "d%d: Deassign device (%04x:%02x:%02x.%u) failed!\n",= =0A+ d->domain_id, seg, bus, PCI_SLOT(devfn), PCI_FUNC(devfn= ));=0A return ret;=0A }=0A =0A@@ -347,7 +363,8 @@ int __init = iommu_setup(void)=0A return rc;=0A }=0A =0A-int iommu_get_device_group(= struct domain *d, u8 bus, u8 devfn, =0A+static int iommu_get_device_group(= =0A+ struct domain *d, u16 seg, u8 bus, u8 devfn,=0A XEN_GUEST_HANDL= E_64(uint32) buf, int max_sdevs)=0A {=0A struct hvm_iommu *hd =3D = domain_hvm_iommu(d);=0A@@ -360,15 +377,16 @@ int iommu_get_device_group(str= uct domain=0A if ( !iommu_enabled || !ops || !ops->get_device_group_id = )=0A return 0;=0A =0A- group_id =3D ops->get_device_group_id(bus= , devfn);=0A+ group_id =3D ops->get_device_group_id(seg, bus, devfn);=0A= =0A spin_lock(&pcidevs_lock);=0A for_each_pdev( d, pdev )=0A = {=0A- if ( (pdev->bus =3D=3D bus) && (pdev->devfn =3D=3D devfn) = )=0A+ if ( (pdev->seg !=3D seg) ||=0A+ ((pdev->bus = =3D=3D bus) && (pdev->devfn =3D=3D devfn)) )=0A continue;=0A = =0A- sdev_id =3D ops->get_device_group_id(pdev->bus, pdev->devfn);= =0A+ sdev_id =3D ops->get_device_group_id(seg, pdev->bus, pdev->devf= n);=0A if ( (sdev_id =3D=3D group_id) && (i < max_sdevs) )=0A = {=0A bdf =3D 0;=0A@@ -443,6 +461,154 @@ void iommu_crash_shu= tdown(void)=0A iommu_enabled =3D 0;=0A }=0A =0A+int iommu_do_domctl(=0A= + struct xen_domctl *domctl,=0A+ XEN_GUEST_HANDLE(xen_domctl_t) = u_domctl)=0A+{=0A+ struct domain *d;=0A+ u16 seg;=0A+ u8 bus, = devfn;=0A+ int ret =3D 0;=0A+=0A+ if ( !iommu_enabled )=0A+ = return -ENOSYS;=0A+=0A+ switch ( domctl->cmd )=0A+ {=0A+ case = XEN_DOMCTL_get_device_group:=0A+ {=0A+ u32 max_sdevs;=0A+ = XEN_GUEST_HANDLE_64(uint32) sdevs;=0A+=0A+ ret =3D -EINVAL;=0A+ = if ( (d =3D rcu_lock_domain_by_id(domctl->domain)) =3D=3D NULL )=0A+ = break;=0A+=0A+ seg =3D domctl->u.get_device_group.machine_sb= df >> 16;=0A+ bus =3D (domctl->u.get_device_group.machine_sbdf >> = 8) & 0xff;=0A+ devfn =3D domctl->u.get_device_group.machine_sbdf & = 0xff;=0A+ max_sdevs =3D domctl->u.get_device_group.max_sdevs;=0A+ = sdevs =3D domctl->u.get_device_group.sdev_array;=0A+=0A+ ret = =3D iommu_get_device_group(d, seg, bus, devfn, sdevs, max_sdevs);=0A+ = if ( ret < 0 )=0A+ {=0A+ dprintk(XENLOG_ERR, "iommu_get= _device_group() failed!\n");=0A+ ret =3D -EFAULT;=0A+ = domctl->u.get_device_group.num_sdevs =3D 0;=0A+ }=0A+ = else=0A+ {=0A+ domctl->u.get_device_group.num_sdevs =3D = ret;=0A+ ret =3D 0;=0A+ }=0A+ if ( copy_to_guest(u= _domctl, domctl, 1) )=0A+ ret =3D -EFAULT;=0A+ rcu_unlock= _domain(d);=0A+ }=0A+ break;=0A+=0A+ case XEN_DOMCTL_test_assign_d= evice:=0A+ ret =3D xsm_test_assign_device(domctl->u.assign_device.ma= chine_sbdf);=0A+ if ( ret )=0A+ break;=0A+=0A+ = seg =3D domctl->u.get_device_group.machine_sbdf >> 16;=0A+ bus =3D = (domctl->u.assign_device.machine_sbdf >> 8) & 0xff;=0A+ devfn =3D = domctl->u.assign_device.machine_sbdf & 0xff;=0A+=0A+ if ( device_ass= igned(seg, bus, devfn) )=0A+ {=0A+ gdprintk(XENLOG_ERR, = "XEN_DOMCTL_test_assign_device: "=0A+ "%04x:%02x:%02x.%= u already assigned, or non-existent\n",=0A+ seg, bus, = PCI_SLOT(devfn), PCI_FUNC(devfn));=0A+ ret =3D -EINVAL;=0A+ = }=0A+ break;=0A+=0A+ case XEN_DOMCTL_assign_device:=0A+ = if ( unlikely((d =3D get_domain_by_id(domctl->domain)) =3D=3D NULL) )=0A+ = {=0A+ gdprintk(XENLOG_ERR,=0A+ "XEN_DOMCTL= _assign_device: get_domain_by_id() failed\n");=0A+ ret =3D = -EINVAL;=0A+ break;=0A+ }=0A+=0A+ ret =3D = xsm_assign_device(d, domctl->u.assign_device.machine_sbdf);=0A+ if = ( ret )=0A+ goto assign_device_out;=0A+=0A+ seg =3D = domctl->u.get_device_group.machine_sbdf >> 16;=0A+ bus =3D = (domctl->u.assign_device.machine_sbdf >> 8) & 0xff;=0A+ devfn =3D = domctl->u.assign_device.machine_sbdf & 0xff;=0A+=0A+#ifdef __ia64__ /* XXX = Is this really needed? */=0A+ if ( device_assigned(seg, bus, devfn) = )=0A+ {=0A+ gdprintk(XENLOG_ERR, "XEN_DOMCTL_assign_devic= e: "=0A+ "%x:%x.%x already assigned, or non-existent\n"= ,=0A+ bus, PCI_SLOT(devfn), PCI_FUNC(devfn));=0A+ = ret =3D -EINVAL;=0A+ goto assign_device_out;=0A+ = }=0A+#endif=0A+=0A+ ret =3D assign_device(d, seg, bus, devfn);=0A+ = if ( ret )=0A+ gdprintk(XENLOG_ERR, "XEN_DOMCTL_assign_dev= ice: "=0A+ "assign device (%04x:%02x:%02x.%u) = failed\n",=0A+ seg, bus, PCI_SLOT(devfn), PCI_FUNC(devf= n));=0A+=0A+ assign_device_out:=0A+ put_domain(d);=0A+ = break;=0A+=0A+ case XEN_DOMCTL_deassign_device:=0A+ if ( = unlikely((d =3D get_domain_by_id(domctl->domain)) =3D=3D NULL) )=0A+ = {=0A+ gdprintk(XENLOG_ERR,=0A+ "XEN_DOMCTL_deass= ign_device: get_domain_by_id() failed\n");=0A+ ret =3D = -EINVAL;=0A+ break;=0A+ }=0A+=0A+ ret =3D = xsm_assign_device(d, domctl->u.assign_device.machine_sbdf);=0A+ if = ( ret )=0A+ goto deassign_device_out;=0A+=0A+ seg =3D = domctl->u.get_device_group.machine_sbdf >> 16;=0A+ bus =3D = (domctl->u.assign_device.machine_sbdf >> 8) & 0xff;=0A+ devfn =3D = domctl->u.assign_device.machine_sbdf & 0xff;=0A+=0A+#ifdef __ia64__ /* XXX = Is this really needed? */=0A+ if ( !device_assigned(seg, bus, = devfn) )=0A+ {=0A+ ret =3D -EINVAL;=0A+ goto = deassign_device_out;=0A+ }=0A+#endif=0A+=0A+ spin_lock(&pcide= vs_lock);=0A+ ret =3D deassign_device(d, seg, bus, devfn);=0A+ = spin_unlock(&pcidevs_lock);=0A+ if ( ret )=0A+ = gdprintk(XENLOG_ERR, "XEN_DOMCTL_deassign_device: "=0A+ = "deassign device (%04x:%02x:%02x.%u) failed\n",=0A+ = seg, bus, PCI_SLOT(devfn), PCI_FUNC(devfn));=0A+=0A+ deassign_device_out= :=0A+ put_domain(d);=0A+ break;=0A+=0A+ default:=0A+ = ret =3D -ENOSYS;=0A+ break;=0A+ }=0A+=0A+ return = ret;=0A+}=0A+=0A /*=0A * Local variables:=0A * mode: C=0A--- 2011-09-20.o= rig/xen/drivers/passthrough/pci.c 2011-08-25 15:06:35.000000000 = +0200=0A+++ 2011-09-20/xen/drivers/passthrough/pci.c 2011-08-25 = 15:06:40.000000000 +0200=0A@@ -441,11 +441,12 @@ void pci_release_devices(s= truct domain *=0A while ( (pdev =3D pci_get_pdev_by_domain(d, -1, -1, = -1)) )=0A {=0A pci_cleanup_msi(pdev);=0A- bus =3D = pdev->bus; devfn =3D pdev->devfn;=0A- if ( deassign_device(d, bus, = devfn) )=0A- printk("domain %d: deassign device (%02x:%02x.%x) = failed!\n",=0A- d->domain_id, pdev->bus, PCI_SLOT(pdev->d= evfn),=0A- PCI_FUNC(pdev->devfn));=0A+ bus =3D = pdev->bus;=0A+ devfn =3D pdev->devfn;=0A+ if ( deassign_devic= e(d, pdev->seg, bus, devfn) )=0A+ printk("domain %d: deassign = device (%04x:%02x:%02x.%u) failed!\n",=0A+ d->domain_id, = pdev->seg, bus,=0A+ PCI_SLOT(devfn), PCI_FUNC(devfn));=0A= }=0A spin_unlock(&pcidevs_lock);=0A }=0A--- 2011-09-20.orig/xen/dr= ivers/passthrough/vtd/iommu.c 2011-09-20 16:03:17.000000000 +0200=0A+++ = 2011-09-20/xen/drivers/passthrough/vtd/iommu.c 2011-09-20 16:04:11.0000000= 00 +0200=0A@@ -1626,13 +1626,13 @@ out:=0A static int reassign_device_owner= ship(=0A struct domain *source,=0A struct domain *target,=0A- = u8 bus, u8 devfn)=0A+ u16 seg, u8 bus, u8 devfn)=0A {=0A struct = pci_dev *pdev;=0A int ret;=0A =0A ASSERT(spin_is_locked(&pcidevs_lo= ck));=0A- pdev =3D pci_get_pdev_by_domain(source, 0, bus, devfn);=0A+ = pdev =3D pci_get_pdev_by_domain(source, seg, bus, devfn);=0A =0A if = (!pdev)=0A return -ENODEV;=0A@@ -2166,27 +2166,8 @@ int __init = intel_vtd_setup(void)=0A return ret;=0A }=0A =0A-/*=0A- * If the = device isn't owned by dom0, it means it already=0A- * has been assigned to = other domain, or it's not exist.=0A- */=0A-int device_assigned(u8 bus, u8 = devfn)=0A-{=0A- struct pci_dev *pdev;=0A-=0A- spin_lock(&pcidevs_lock= );=0A- pdev =3D pci_get_pdev_by_domain(dom0, 0, bus, devfn);=0A- if = (!pdev)=0A- {=0A- spin_unlock(&pcidevs_lock);=0A- return = -1;=0A- }=0A-=0A- spin_unlock(&pcidevs_lock);=0A- return = 0;=0A-}=0A-=0A-static int intel_iommu_assign_device(struct domain *d, u8 = bus, u8 devfn)=0A+static int intel_iommu_assign_device(=0A+ struct = domain *d, u16 seg, u8 bus, u8 devfn)=0A {=0A struct acpi_rmrr_unit = *rmrr;=0A int ret =3D 0, i;=0A@@ -2197,7 +2178,7 @@ static int = intel_iommu_assign_device(str=0A return -ENODEV;=0A =0A = ASSERT(spin_is_locked(&pcidevs_lock));=0A- pdev =3D pci_get_pdev(0, = bus, devfn);=0A+ pdev =3D pci_get_pdev(seg, bus, devfn);=0A if = (!pdev)=0A return -ENODEV;=0A =0A@@ -2208,7 +2189,7 @@ static int = intel_iommu_assign_device(str=0A return -EBUSY;=0A }=0A =0A- = ret =3D reassign_device_ownership(dom0, d, bus, devfn);=0A+ ret =3D = reassign_device_ownership(dom0, d, seg, bus, devfn);=0A if ( ret )=0A = goto done;=0A =0A@@ -2240,7 +2221,7 @@ done:=0A return ret;=0A = }=0A =0A-static int intel_iommu_group_id(u8 bus, u8 devfn)=0A+static int = intel_iommu_group_id(u16 seg, u8 bus, u8 devfn)=0A {=0A u8 secbus;=0A = if ( find_upstream_bridge(&bus, &devfn, &secbus) < 0 )=0A--- 2011-09-20.= orig/xen/include/public/domctl.h 2011-09-19 10:58:18.000000000 = +0200=0A+++ 2011-09-20/xen/include/public/domctl.h 2011-09-15 = 15:39:21.000000000 +0200=0A@@ -455,15 +455,15 @@ DEFINE_XEN_GUEST_HANDLE(xe= n_domctl_sendt=0A /* XEN_DOMCTL_test_assign_device */=0A /* XEN_DOMCTL_deas= sign_device */=0A struct xen_domctl_assign_device {=0A- uint32_t = machine_bdf; /* machine PCI ID of assigned device */=0A+ uint32_t = machine_sbdf; /* machine PCI ID of assigned device */=0A };=0A typedef = struct xen_domctl_assign_device xen_domctl_assign_device_t;=0A DEFINE_XEN_G= UEST_HANDLE(xen_domctl_assign_device_t);=0A =0A-/* Retrieve sibling = devices infomation of machine_bdf */=0A+/* Retrieve sibling devices = infomation of machine_sbdf */=0A /* XEN_DOMCTL_get_device_group */=0A = struct xen_domctl_get_device_group {=0A- uint32_t machine_bdf; /* = IN */=0A+ uint32_t machine_sbdf; /* IN */=0A uint32_t = max_sdevs; /* IN */=0A uint32_t num_sdevs; /* OUT */=0A = XEN_GUEST_HANDLE_64(uint32) sdev_array; /* OUT */=0A--- 2011-09-20.o= rig/xen/include/xen/iommu.h 2011-08-25 15:06:23.000000000 +0200=0A+++ = 2011-09-20/xen/include/xen/iommu.h 2011-09-15 16:46:28.000000000 = +0200=0A@@ -74,11 +74,7 @@ int iommu_remove_device(struct pci_dev *=0A int = iommu_domain_init(struct domain *d);=0A void iommu_dom0_init(struct domain = *d);=0A void iommu_domain_destroy(struct domain *d);=0A-int device_assigned= (u8 bus, u8 devfn);=0A-int assign_device(struct domain *d, u8 bus, u8 = devfn);=0A-int deassign_device(struct domain *d, u8 bus, u8 devfn);=0A-int = iommu_get_device_group(struct domain *d, u8 bus, u8 devfn,=0A- = XEN_GUEST_HANDLE_64(uint32) buf, int max_sdevs);=0A+int deassign_device(str= uct domain *d, u16 seg, u8 bus, u8 devfn);=0A =0A /* iommu_map_page() = takes flags to direct the mapping operation. */=0A #define _IOMMUF_readable= 0=0A@@ -125,14 +121,14 @@ struct iommu_ops {=0A void (*dom0_init)(stru= ct domain *d);=0A int (*add_device)(struct pci_dev *pdev);=0A int = (*remove_device)(struct pci_dev *pdev);=0A- int (*assign_device)(struct = domain *d, u8 bus, u8 devfn);=0A+ int (*assign_device)(struct domain = *d, u16 seg, u8 bus, u8 devfn);=0A void (*teardown)(struct domain = *d);=0A int (*map_page)(struct domain *d, unsigned long gfn, unsigned = long mfn,=0A unsigned int flags);=0A int (*unmap_pa= ge)(struct domain *d, unsigned long gfn);=0A int (*reassign_device)(str= uct domain *s, struct domain *t,=0A- u8 bus, u8 = devfn);=0A- int (*get_device_group_id)(u8 bus, u8 devfn);=0A+ = u16 seg, u8 bus, u8 devfn);=0A+ int (*get_device_group_id)(u1= 6 seg, u8 bus, u8 devfn);=0A void (*update_ire_from_apic)(unsigned int = apic, unsigned int reg, unsigned int value);=0A void (*update_ire_from_= msi)(struct msi_desc *msi_desc, struct msi_msg *msg);=0A void = (*read_msi_from_ire)(struct msi_desc *msi_desc, struct msi_msg *msg);=0A@@ = -155,4 +151,6 @@ void iommu_crash_shutdown(void);=0A void iommu_set_dom0_ma= pping(struct domain *d);=0A void iommu_share_p2m_table(struct domain = *d);=0A =0A+int iommu_do_domctl(struct xen_domctl *, XEN_GUEST_HANDLE(xen_d= omctl_t));=0A+=0A #endif /* _IOMMU_H_ */=0A --=__Part56796DA6.0__= Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel --=__Part56796DA6.0__=-- From xen-devel-bounces@lists.xensource.com Tue Sep 20 08:21:52 2011 Return-path: <xen-devel-bounces@lists.xensource.com> Envelope-to: www-data@lists.xensource.com Delivery-date: Tue, 20 Sep 2011 08:21:52 -0700 Received: from localhost ([127.0.0.1] helo=lists.colo.xensource.com) by lists.xensource.com with esmtp (Exim 4.43) id 1R628u-0000nU-LU; Tue, 20 Sep 2011 08:21:52 -0700 Received: from mail21.messagelabs.com ([85.158.143.35]) by lists.xensource.com with esmtp (Exim 4.43) id 1R625a-00082c-2L for xen-devel@lists.xensource.com; Tue, 20 Sep 2011 08:18:27 -0700 X-Env-Sender: JBeulich@suse.com X-Msg-Ref: server-11.tower-21.messagelabs.com!1316531885!43316351!1 X-Originating-IP: [130.57.49.28] X-StarScan-Version: 6.4.1; banners=-,-,- X-VirusChecked: Checked Received: (qmail 15954 invoked from network); 20 Sep 2011 15:18:05 -0000 Received: from nat28.tlf.novell.com (HELO nat28.tlf.novell.com) (130.57.49.28) by server-11.tower-21.messagelabs.com with DHE-RSA-AES256-SHA encrypted SMTP; 20 Sep 2011 15:18:05 -0000 Received: from EMEA1-MTA by nat28.tlf.novell.com with Novell_GroupWise; Tue, 20 Sep 2011 16:18:22 +0100 Message-Id: <4E78CAF70200007800056D28@nat28.tlf.novell.com> X-Mailer: Novell GroupWise Internet Agent 8.0.1 Date: Tue, 20 Sep 2011 16:18:47 +0100 From: "Jan Beulich" <JBeulich@suse.com> To: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com> Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="=__Part37180CC7.0__=" Subject: [Xen-devel] [PATCH 4/7] PCI multi-seg: VT-d specific adjustments X-BeenThere: xen-devel@lists.xensource.com X-Mailman-Version: 2.1.5 Precedence: list List-Id: Xen developer discussion <xen-devel.lists.xensource.com> List-Unsubscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe> List-Post: <mailto:xen-devel@lists.xensource.com> List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help> List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=subscribe> Sender: xen-devel-bounces@lists.xensource.com Errors-To: xen-devel-bounces@lists.xensource.com This is a MIME message. If you are reading this text, you may want to consider changing to a mail reader or gateway that understands how to properly handle MIME multipart messages. --=__Part37180CC7.0__= Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: quoted-printable Content-Disposition: inline Signed-off-by: Jan Beulich <jbeulich@suse.com> --- 2011-09-20.orig/xen/drivers/passthrough/vtd/dmar.c 2011-08-16 = 08:15:46.000000000 +0200 +++ 2011-09-20/xen/drivers/passthrough/vtd/dmar.c 2011-08-25 = 15:06:43.000000000 +0200 @@ -188,6 +188,9 @@ struct acpi_drhd_unit * acpi_find_matche =20 list_for_each_entry ( drhd, &acpi_drhd_units, list ) { + if ( drhd->segment !=3D pdev->seg ) + continue; + for (i =3D 0; i < drhd->scope.devices_cnt; i++) if ( drhd->scope.devices[i] =3D=3D PCI_BDF2(bus, devfn) ) return drhd; @@ -201,13 +204,16 @@ struct acpi_drhd_unit * acpi_find_matche return include_all; } =20 -struct acpi_atsr_unit * acpi_find_matched_atsr_unit(u8 bus, u8 devfn) +struct acpi_atsr_unit * acpi_find_matched_atsr_unit(u16 seg, u8 bus, u8 = devfn) { struct acpi_atsr_unit *atsr; struct acpi_atsr_unit *all_ports =3D NULL; =20 list_for_each_entry ( atsr, &acpi_atsr_units, list ) { + if ( atsr->segment !=3D seg ) + continue; + if ( test_bit(bus, atsr->scope.buses) ) return atsr; =20 @@ -269,8 +275,8 @@ static int scope_device_count(void *star } =20 =20 -static int __init acpi_parse_dev_scope(void *start, void *end, - void *acpi_entry, int type) +static int __init acpi_parse_dev_scope( + void *start, void *end, void *acpi_entry, int type, u16 seg) { struct dmar_scope *scope =3D acpi_entry; struct acpi_ioapic_unit *acpi_ioapic_unit; @@ -314,8 +320,8 @@ static int __init acpi_parse_dev_scope(v bus, path->dev, path->fn, PCI_SUBORDINATE_BUS); if ( iommu_verbose ) dprintk(VTDPREFIX, - " bridge: %x:%x.%x start =3D %x sec =3D %x sub = =3D %x\n", - bus, path->dev, path->fn, + " bridge: %04x:%02x:%02x.%u start=3D%x sec=3D%x = sub=3D%x\n", + seg, bus, path->dev, path->fn, acpi_scope->start_bus, sec_bus, sub_bus); =20 dmar_scope_add_buses(scope, sec_bus, sub_bus); @@ -323,20 +329,21 @@ static int __init acpi_parse_dev_scope(v =20 case ACPI_DEV_MSI_HPET: if ( iommu_verbose ) - dprintk(VTDPREFIX, " MSI HPET: %x:%x.%x\n", - bus, path->dev, path->fn); + dprintk(VTDPREFIX, " MSI HPET: %04x:%02x:%02x.%u\n", + seg, bus, path->dev, path->fn); break; =20 case ACPI_DEV_ENDPOINT: if ( iommu_verbose ) - dprintk(VTDPREFIX, " endpoint: %x:%x.%x\n", - bus, path->dev, path->fn); + dprintk(VTDPREFIX, " endpoint: %04x:%02x:%02x.%u\n", + seg, bus, path->dev, path->fn); =20 if ( type =3D=3D DMAR_TYPE ) { struct acpi_drhd_unit *drhd =3D acpi_entry; =20 - if ( (bus =3D=3D 0) && (path->dev =3D=3D 2) && (path->fn = =3D=3D 0) ) + if ( (seg =3D=3D 0) && (bus =3D=3D 0) && (path->dev = =3D=3D 2) && + (path->fn =3D=3D 0) ) igd_drhd_address =3D drhd->address; } =20 @@ -344,8 +351,8 @@ static int __init acpi_parse_dev_scope(v =20 case ACPI_DEV_IOAPIC: if ( iommu_verbose ) - dprintk(VTDPREFIX, " IOAPIC: %x:%x.%x\n", - bus, path->dev, path->fn); + dprintk(VTDPREFIX, " IOAPIC: %04x:%02x:%02x.%u\n", + seg, bus, path->dev, path->fn); =20 if ( type =3D=3D DMAR_TYPE ) { @@ -398,6 +405,7 @@ acpi_parse_one_drhd(struct acpi_dmar_ent memset(dmaru, 0, sizeof(struct acpi_drhd_unit)); =20 dmaru->address =3D drhd->address; + dmaru->segment =3D drhd->segment; dmaru->include_all =3D drhd->flags & 1; /* BIT0: INCLUDE_ALL */ INIT_LIST_HEAD(&dmaru->ioapic_list); if ( iommu_verbose ) @@ -411,7 +419,7 @@ acpi_parse_one_drhd(struct acpi_dmar_ent dev_scope_start =3D (void *)(drhd + 1); dev_scope_end =3D ((void *)drhd) + header->length; ret =3D acpi_parse_dev_scope(dev_scope_start, dev_scope_end, - dmaru, DMAR_TYPE); + dmaru, DMAR_TYPE, drhd->segment); =20 if ( dmaru->include_all ) { @@ -528,11 +536,12 @@ acpi_parse_one_rmrr(struct acpi_dmar_ent =20 rmrru->base_address =3D base_addr; rmrru->end_address =3D end_addr; + rmrru->segment =3D rmrr->segment; =20 dev_scope_start =3D (void *)(rmrr + 1); dev_scope_end =3D ((void *)rmrr) + header->length; ret =3D acpi_parse_dev_scope(dev_scope_start, dev_scope_end, - rmrru, RMRR_TYPE); + rmrru, RMRR_TYPE, rmrr->segment); =20 if ( ret || (rmrru->scope.devices_cnt =3D=3D 0) ) xfree(rmrru); @@ -609,6 +618,7 @@ acpi_parse_one_atsr(struct acpi_dmar_ent return -ENOMEM; memset(atsru, 0, sizeof(struct acpi_atsr_unit)); =20 + atsru->segment =3D atsr->segment; atsru->all_ports =3D atsr->flags & 1; /* BIT0: ALL_PORTS */ if ( iommu_verbose ) dprintk(VTDPREFIX, @@ -618,7 +628,7 @@ acpi_parse_one_atsr(struct acpi_dmar_ent dev_scope_start =3D (void *)(atsr + 1); dev_scope_end =3D ((void *)atsr) + header->length; ret =3D acpi_parse_dev_scope(dev_scope_start, dev_scope_end, - atsru, ATSR_TYPE); + atsru, ATSR_TYPE, atsr->segment); } else { --- 2011-09-20.orig/xen/drivers/passthrough/vtd/dmar.h 2011-06-20 = 08:41:50.000000000 +0200 +++ 2011-09-20/xen/drivers/passthrough/vtd/dmar.h 2011-08-25 = 15:06:43.000000000 +0200 @@ -49,6 +49,7 @@ struct acpi_drhd_unit { struct dmar_scope scope; /* must be first member of struct = */ struct list_head list; u64 address; /* register base address of the = unit */ + u16 segment; u8 include_all:1; struct iommu *iommu; struct list_head ioapic_list; @@ -59,12 +60,14 @@ struct acpi_rmrr_unit { struct list_head list; u64 base_address; u64 end_address; + u16 segment; u8 allow_all:1; }; =20 struct acpi_atsr_unit { struct dmar_scope scope; /* must be first member of struct = */ struct list_head list; + u16 segment; u8 all_ports:1; }; =20 @@ -84,7 +87,7 @@ struct acpi_rhsa_unit { idx < rmrr->scope.devices_cnt; idx++) =20 struct acpi_drhd_unit * acpi_find_matched_drhd_unit(struct pci_dev = *pdev); -struct acpi_atsr_unit * acpi_find_matched_atsr_unit(u8 bus, u8 devfn); +struct acpi_atsr_unit * acpi_find_matched_atsr_unit(u16 seg, u8 bus, u8 = devfn); =20 #define DMAR_TYPE 1 #define RMRR_TYPE 2 @@ -114,7 +117,7 @@ void *map_to_nocache_virt(int nr_iommus, =20 int vtd_hw_check(void); void disable_pmr(struct iommu *iommu); -int is_usb_device(u8 bus, u8 devfn); +int is_usb_device(u16 seg, u8 bus, u8 devfn); int is_igd_drhd(struct acpi_drhd_unit *drhd); =20 #endif /* _DMAR_H_ */ --- 2011-09-20.orig/xen/drivers/passthrough/vtd/iommu.c 2011-09-20 = 16:04:11.000000000 +0200 +++ 2011-09-20/xen/drivers/passthrough/vtd/iommu.c 2011-09-20 = 16:06:24.000000000 +0200 @@ -835,16 +835,17 @@ static int iommu_page_fault_do_one(struc { const char *reason; int fault_type; + u16 seg =3D iommu->intel->drhd->segment; reason =3D iommu_get_fault_reason(fault_reason, &fault_type); =20 if ( fault_type =3D=3D DMA_REMAP ) { INTEL_IOMMU_DEBUG( - "DMAR:[%s] Request device [%02x:%02x.%d] " + "DMAR:[%s] Request device [%04x:%02x:%02x.%u] " "fault addr %"PRIx64", iommu reg =3D %p\n" "DMAR:[fault reason %02xh] %s\n", (type ? "DMA Read" : "DMA Write"), - (source_id >> 8), PCI_SLOT(source_id & 0xFF), + seg, (source_id >> 8), PCI_SLOT(source_id & 0xFF), PCI_FUNC(source_id & 0xFF), addr, iommu->reg, fault_reason, reason); #ifndef __i386__ /* map_domain_page() cannot be used in this context */ @@ -855,10 +856,10 @@ static int iommu_page_fault_do_one(struc } else INTEL_IOMMU_DEBUG( - "INTR-REMAP: Request device [%02x:%02x.%d] " + "INTR-REMAP: Request device [%04x:%02x:%02x.%u] " "fault index %"PRIx64", iommu reg =3D %p\n" "INTR-REMAP:[fault reason %02xh] %s\n", - (source_id >> 8), PCI_SLOT(source_id & 0xFF), + seg, (source_id >> 8), PCI_SLOT(source_id & 0xFF), PCI_FUNC(source_id & 0xFF), addr >> 48, iommu->reg, fault_reason, reason); return 0; @@ -1258,6 +1259,7 @@ int domain_context_mapping_one( struct hvm_iommu *hd =3D domain_hvm_iommu(domain); struct context_entry *context, *context_entries; u64 maddr, pgd_maddr; + u16 seg =3D iommu->intel->drhd->segment; int agaw; =20 ASSERT(spin_is_locked(&pcidevs_lock)); @@ -1273,7 +1275,7 @@ int domain_context_mapping_one( =20 /* First try to get domain ownership from device structure. If = that's * not available, try to read it from the context itself. */ - pdev =3D pci_get_pdev(0, bus, devfn); + pdev =3D pci_get_pdev(seg, bus, devfn); if ( pdev ) { if ( pdev->domain !=3D domain ) @@ -1385,18 +1387,20 @@ int domain_context_mapping_one( =20 unmap_vtd_domain_page(context_entries); =20 - me_wifi_quirk(domain, bus, devfn, MAP_ME_PHANTOM_FUNC); + if ( !seg ) + me_wifi_quirk(domain, bus, devfn, MAP_ME_PHANTOM_FUNC); =20 return 0; } =20 -static int domain_context_mapping(struct domain *domain, u8 bus, u8 = devfn) +static int domain_context_mapping( + struct domain *domain, u16 seg, u8 bus, u8 devfn) { struct acpi_drhd_unit *drhd; int ret =3D 0; u32 type; u8 secbus; - struct pci_dev *pdev =3D pci_get_pdev(0, bus, devfn); + struct pci_dev *pdev =3D pci_get_pdev(seg, bus, devfn); =20 drhd =3D acpi_find_matched_drhd_unit(pdev); if ( !drhd ) @@ -1414,18 +1418,20 @@ static int domain_context_mapping(struct =20 case DEV_TYPE_PCIe_ENDPOINT: if ( iommu_verbose ) - dprintk(VTDPREFIX, "d%d:PCIe: map bdf =3D %x:%x.%x\n", - domain->domain_id, bus, PCI_SLOT(devfn), PCI_FUNC(devf= n)); + dprintk(VTDPREFIX, "d%d:PCIe: map %04x:%02x:%02x.%u\n", + domain->domain_id, seg, bus, + PCI_SLOT(devfn), PCI_FUNC(devfn)); ret =3D domain_context_mapping_one(domain, drhd->iommu, bus, = devfn); - if ( !ret && ats_device(0, bus, devfn) ) - enable_ats_device(0, bus, devfn); + if ( !ret && ats_device(seg, bus, devfn) ) + enable_ats_device(seg, bus, devfn); =20 break; =20 case DEV_TYPE_PCI: if ( iommu_verbose ) - dprintk(VTDPREFIX, "d%d:PCI: map bdf =3D %x:%x.%x\n", - domain->domain_id, bus, PCI_SLOT(devfn), PCI_FUNC(devf= n)); + dprintk(VTDPREFIX, "d%d:PCI: map %04x:%02x:%02x.%u\n", + domain->domain_id, seg, bus, + PCI_SLOT(devfn), PCI_FUNC(devfn)); =20 ret =3D domain_context_mapping_one(domain, drhd->iommu, bus, = devfn); if ( ret ) @@ -1448,9 +1454,9 @@ static int domain_context_mapping(struct break; =20 default: - dprintk(XENLOG_ERR VTDPREFIX, "d%d:unknown(%u): bdf =3D %x:%x.%x\n= ", + dprintk(XENLOG_ERR VTDPREFIX, "d%d:unknown(%u): %04x:%02x:%02x.%u\= n", domain->domain_id, type, - bus, PCI_SLOT(devfn), PCI_FUNC(devfn)); + seg, bus, PCI_SLOT(devfn), PCI_FUNC(devfn)); ret =3D -EINVAL; break; } @@ -1509,19 +1515,21 @@ int domain_context_unmap_one( spin_unlock(&iommu->lock); unmap_vtd_domain_page(context_entries); =20 - me_wifi_quirk(domain, bus, devfn, UNMAP_ME_PHANTOM_FUNC); + if ( !iommu->intel->drhd->segment ) + me_wifi_quirk(domain, bus, devfn, UNMAP_ME_PHANTOM_FUNC); =20 return 0; } =20 -static int domain_context_unmap(struct domain *domain, u8 bus, u8 devfn) +static int domain_context_unmap( + struct domain *domain, u16 seg, u8 bus, u8 devfn) { struct acpi_drhd_unit *drhd; struct iommu *iommu; int ret =3D 0; u32 type; u8 tmp_bus, tmp_devfn, secbus; - struct pci_dev *pdev =3D pci_get_pdev(0, bus, devfn); + struct pci_dev *pdev =3D pci_get_pdev(seg, bus, devfn); int found =3D 0; =20 BUG_ON(!pdev); @@ -1541,18 +1549,19 @@ static int domain_context_unmap(struct d =20 case DEV_TYPE_PCIe_ENDPOINT: if ( iommu_verbose ) - dprintk(VTDPREFIX, "d%d:PCIe: unmap bdf =3D %x:%x.%x\n", - domain->domain_id, bus, PCI_SLOT(devfn), PCI_FUNC(devf= n)); + dprintk(VTDPREFIX, "d%d:PCIe: unmap %04x:%02x:%02x.%u\n", + domain->domain_id, seg, bus, + PCI_SLOT(devfn), PCI_FUNC(devfn)); ret =3D domain_context_unmap_one(domain, iommu, bus, devfn); - if ( !ret && ats_device(0, bus, devfn) ) - disable_ats_device(0, bus, devfn); + if ( !ret && ats_device(seg, bus, devfn) ) + disable_ats_device(seg, bus, devfn); =20 break; =20 case DEV_TYPE_PCI: if ( iommu_verbose ) - dprintk(VTDPREFIX, "d%d:PCI: unmap bdf =3D %x:%x.%x\n", - domain->domain_id, bus, PCI_SLOT(devfn), PCI_FUNC(devf= n)); + dprintk(VTDPREFIX, "d%d:PCI: unmap %04x:%02x:%02x.%u\n", + domain->domain_id, seg, bus, PCI_SLOT(devfn), = PCI_FUNC(devfn)); ret =3D domain_context_unmap_one(domain, iommu, bus, devfn); if ( ret ) break; @@ -1577,9 +1586,9 @@ static int domain_context_unmap(struct d break; =20 default: - dprintk(XENLOG_ERR VTDPREFIX, "d%d:unknown(%u): bdf =3D %x:%x.%x\n= ", + dprintk(XENLOG_ERR VTDPREFIX, "d%d:unknown(%u): %04x:%02x:%02x.%u\= n", domain->domain_id, type, - bus, PCI_SLOT(devfn), PCI_FUNC(devfn)); + seg, bus, PCI_SLOT(devfn), PCI_FUNC(devfn)); ret =3D -EINVAL; goto out; } @@ -1590,7 +1599,7 @@ static int domain_context_unmap(struct d */ for_each_pdev ( domain, pdev ) { - if ( pdev->bus =3D=3D bus && pdev->devfn =3D=3D devfn ) + if ( pdev->seg =3D=3D seg && pdev->bus =3D=3D bus && pdev->devfn = =3D=3D devfn ) continue; =20 drhd =3D acpi_find_matched_drhd_unit(pdev); @@ -1645,11 +1654,11 @@ static int reassign_device_ownership( if ( (target !=3D dom0) && !iommu_intremap ) untrusted_msi =3D 1; =20 - ret =3D domain_context_unmap(source, bus, devfn); + ret =3D domain_context_unmap(source, seg, bus, devfn); if ( ret ) return ret; =20 - ret =3D domain_context_mapping(target, bus, devfn); + ret =3D domain_context_mapping(target, seg, bus, devfn); if ( ret ) return ret; =20 @@ -1884,7 +1893,8 @@ static int intel_iommu_add_device(struct if ( !pdev->domain ) return -EINVAL; =20 - ret =3D domain_context_mapping(pdev->domain, pdev->bus, pdev->devfn); + ret =3D domain_context_mapping(pdev->domain, pdev->seg, pdev->bus, + pdev->devfn); if ( ret ) { dprintk(XENLOG_ERR VTDPREFIX, "d%d: context mapping failed\n", @@ -1894,7 +1904,9 @@ static int intel_iommu_add_device(struct =20 for_each_rmrr_device ( rmrr, bdf, i ) { - if ( PCI_BUS(bdf) =3D=3D pdev->bus && PCI_DEVFN2(bdf) =3D=3D = pdev->devfn ) + if ( rmrr->segment =3D=3D pdev->seg && + PCI_BUS(bdf) =3D=3D pdev->bus && + PCI_DEVFN2(bdf) =3D=3D pdev->devfn ) { ret =3D rmrr_identity_mapping(pdev->domain, rmrr); if ( ret ) @@ -1922,13 +1934,15 @@ static int intel_iommu_remove_device(str { for_each_rmrr_device ( rmrr, bdf, i ) { - if ( PCI_BUS(bdf) =3D=3D pdev->bus && + if ( rmrr->segment =3D=3D pdev->seg && + PCI_BUS(bdf) =3D=3D pdev->bus && PCI_DEVFN2(bdf) =3D=3D pdev->devfn ) return 0; } } =20 - return domain_context_unmap(pdev->domain, pdev->bus, pdev->devfn); + return domain_context_unmap(pdev->domain, pdev->seg, pdev->bus, + pdev->devfn); } =20 static void __init setup_dom0_devices(struct domain *d) @@ -1947,7 +1961,7 @@ static void __init setup_dom0_devices(st =20 pdev->domain =3D d; list_add(&pdev->domain_list, &d->arch.pdev_list); - domain_context_mapping(d, pdev->bus, pdev->devfn); + domain_context_mapping(d, pdev->seg, pdev->bus, pdev->devfn); pci_enable_acs(pdev); pci_vtd_quirk(pdev); } @@ -2196,7 +2210,7 @@ static int intel_iommu_assign_device( /* FIXME: Because USB RMRR conflicts with guest bios region, * ignore USB RMRR temporarily. */ - if ( is_usb_device(bus, devfn) ) + if ( is_usb_device(seg, bus, devfn) ) { ret =3D 0; goto done; @@ -2205,7 +2219,9 @@ static int intel_iommu_assign_device( /* Setup rmrr identity mapping */ for_each_rmrr_device( rmrr, bdf, i ) { - if ( PCI_BUS(bdf) =3D=3D bus && PCI_DEVFN2(bdf) =3D=3D devfn ) + if ( rmrr->segment =3D=3D seg && + PCI_BUS(bdf) =3D=3D bus && + PCI_DEVFN2(bdf) =3D=3D devfn ) { ret =3D rmrr_identity_mapping(d, rmrr); if ( ret ) --- 2011-09-20.orig/xen/drivers/passthrough/vtd/utils.c 2011-08-19 = 17:08:35.000000000 +0200 +++ 2011-09-20/xen/drivers/passthrough/vtd/utils.c 2011-08-25 = 15:06:43.000000000 +0200 @@ -32,7 +32,7 @@ #include <asm/io_apic.h> #endif =20 -int is_usb_device(u8 bus, u8 devfn) +int is_usb_device(u16 seg, u8 bus, u8 devfn) { u16 class =3D pci_conf_read16(bus, PCI_SLOT(devfn), PCI_FUNC(devfn), PCI_CLASS_DEVICE); @@ -106,8 +106,9 @@ void print_vtd_entries(struct iommu *iom u64 *l, val; u32 l_index, level; =20 - printk("print_vtd_entries: iommu =3D %p bdf =3D %x:%x.%x gmfn =3D = %"PRIx64"\n", - iommu, bus, PCI_SLOT(devfn), PCI_FUNC(devfn), gmfn); + printk("print_vtd_entries: iommu %p dev %04x:%02x:%02x.%u gmfn = %"PRIx64"\n", + iommu, iommu->intel->drhd->segment, bus, + PCI_SLOT(devfn), PCI_FUNC(devfn), gmfn); =20 if ( iommu->root_maddr =3D=3D 0 ) { --- 2011-09-20.orig/xen/drivers/passthrough/vtd/x86/ats.c 2011-08-25 = 15:06:35.000000000 +0200 +++ 2011-09-20/xen/drivers/passthrough/vtd/x86/ats.c 2011-08-25 = 15:06:43.000000000 +0200 @@ -104,7 +104,7 @@ int ats_device(int seg, int bus, int dev !ecap_dev_iotlb(drhd->iommu->ecap) ) return 0; =20 - if ( !acpi_find_matched_atsr_unit(bus, devfn) ) + if ( !acpi_find_matched_atsr_unit(seg, bus, devfn) ) return 0; =20 ats_drhd =3D find_ats_dev_drhd(drhd->iommu); --=__Part37180CC7.0__= Content-Type: text/plain; name="pci-multi-seg-vtd.patch" Content-Transfer-Encoding: quoted-printable Content-Disposition: attachment; filename="pci-multi-seg-vtd.patch" Signed-off-by: Jan Beulich <jbeulich@suse.com>=0A=0A--- 2011-09-20.orig/xen= /drivers/passthrough/vtd/dmar.c 2011-08-16 08:15:46.000000000 +0200=0A+++ = 2011-09-20/xen/drivers/passthrough/vtd/dmar.c 2011-08-25 15:06:43.0000000= 00 +0200=0A@@ -188,6 +188,9 @@ struct acpi_drhd_unit * acpi_find_matche=0A = =0A list_for_each_entry ( drhd, &acpi_drhd_units, list )=0A {=0A+ = if ( drhd->segment !=3D pdev->seg )=0A+ continue;=0A+=0A = for (i =3D 0; i < drhd->scope.devices_cnt; i++)=0A if ( = drhd->scope.devices[i] =3D=3D PCI_BDF2(bus, devfn) )=0A = return drhd;=0A@@ -201,13 +204,16 @@ struct acpi_drhd_unit * acpi_find_matc= he=0A return include_all;=0A }=0A =0A-struct acpi_atsr_unit * = acpi_find_matched_atsr_unit(u8 bus, u8 devfn)=0A+struct acpi_atsr_unit * = acpi_find_matched_atsr_unit(u16 seg, u8 bus, u8 devfn)=0A {=0A struct = acpi_atsr_unit *atsr;=0A struct acpi_atsr_unit *all_ports =3D NULL;=0A = =0A list_for_each_entry ( atsr, &acpi_atsr_units, list )=0A {=0A+ = if ( atsr->segment !=3D seg )=0A+ continue;=0A+=0A = if ( test_bit(bus, atsr->scope.buses) )=0A return atsr;=0A = =0A@@ -269,8 +275,8 @@ static int scope_device_count(void *star=0A }=0A = =0A =0A-static int __init acpi_parse_dev_scope(void *start, void *end,=0A- = void *acpi_entry, int type)=0A+static= int __init acpi_parse_dev_scope(=0A+ void *start, void *end, void = *acpi_entry, int type, u16 seg)=0A {=0A struct dmar_scope *scope =3D = acpi_entry;=0A struct acpi_ioapic_unit *acpi_ioapic_unit;=0A@@ -314,8 = +320,8 @@ static int __init acpi_parse_dev_scope(v=0A bus, = path->dev, path->fn, PCI_SUBORDINATE_BUS);=0A if ( iommu_verbos= e )=0A dprintk(VTDPREFIX,=0A- " = bridge: %x:%x.%x start =3D %x sec =3D %x sub =3D %x\n",=0A- = bus, path->dev, path->fn,=0A+ " bridge: = %04x:%02x:%02x.%u start=3D%x sec=3D%x sub=3D%x\n",=0A+ = seg, bus, path->dev, path->fn,=0A acpi_scope->st= art_bus, sec_bus, sub_bus);=0A =0A dmar_scope_add_buses(scope, = sec_bus, sub_bus);=0A@@ -323,20 +329,21 @@ static int __init acpi_parse_dev= _scope(v=0A =0A case ACPI_DEV_MSI_HPET:=0A if ( = iommu_verbose )=0A- dprintk(VTDPREFIX, " MSI HPET: = %x:%x.%x\n",=0A- bus, path->dev, path->fn);=0A+ = dprintk(VTDPREFIX, " MSI HPET: %04x:%02x:%02x.%u\n",=0A+ = seg, bus, path->dev, path->fn);=0A break;=0A = =0A case ACPI_DEV_ENDPOINT:=0A if ( iommu_verbose = )=0A- dprintk(VTDPREFIX, " endpoint: %x:%x.%x\n",=0A- = bus, path->dev, path->fn);=0A+ dprintk(VTD= PREFIX, " endpoint: %04x:%02x:%02x.%u\n",=0A+ seg, = bus, path->dev, path->fn);=0A =0A if ( type =3D=3D DMAR_TYPE = )=0A {=0A struct acpi_drhd_unit *drhd =3D = acpi_entry;=0A =0A- if ( (bus =3D=3D 0) && (path->dev = =3D=3D 2) && (path->fn =3D=3D 0) )=0A+ if ( (seg =3D=3D 0) = && (bus =3D=3D 0) && (path->dev =3D=3D 2) &&=0A+ = (path->fn =3D=3D 0) )=0A igd_drhd_address =3D = drhd->address;=0A }=0A =0A@@ -344,8 +351,8 @@ static int = __init acpi_parse_dev_scope(v=0A =0A case ACPI_DEV_IOAPIC:=0A = if ( iommu_verbose )=0A- dprintk(VTDPREFIX, " = IOAPIC: %x:%x.%x\n",=0A- bus, path->dev, path->fn);= =0A+ dprintk(VTDPREFIX, " IOAPIC: %04x:%02x:%02x.%u\n",=0A+ = seg, bus, path->dev, path->fn);=0A =0A = if ( type =3D=3D DMAR_TYPE )=0A {=0A@@ -398,6 +405,7 @@ = acpi_parse_one_drhd(struct acpi_dmar_ent=0A memset(dmaru, 0, sizeof(str= uct acpi_drhd_unit));=0A =0A dmaru->address =3D drhd->address;=0A+ = dmaru->segment =3D drhd->segment;=0A dmaru->include_all =3D drhd->flags= & 1; /* BIT0: INCLUDE_ALL */=0A INIT_LIST_HEAD(&dmaru->ioapic_list);= =0A if ( iommu_verbose )=0A@@ -411,7 +419,7 @@ acpi_parse_one_drhd(stru= ct acpi_dmar_ent=0A dev_scope_start =3D (void *)(drhd + 1);=0A = dev_scope_end =3D ((void *)drhd) + header->length;=0A ret =3D = acpi_parse_dev_scope(dev_scope_start, dev_scope_end,=0A- = dmaru, DMAR_TYPE);=0A+ dmaru, = DMAR_TYPE, drhd->segment);=0A =0A if ( dmaru->include_all )=0A = {=0A@@ -528,11 +536,12 @@ acpi_parse_one_rmrr(struct acpi_dmar_ent=0A =0A = rmrru->base_address =3D base_addr;=0A rmrru->end_address =3D = end_addr;=0A+ rmrru->segment =3D rmrr->segment;=0A =0A dev_scope_sta= rt =3D (void *)(rmrr + 1);=0A dev_scope_end =3D ((void *)rmrr) + = header->length;=0A ret =3D acpi_parse_dev_scope(dev_scope_start, = dev_scope_end,=0A- rmrru, RMRR_TYPE);=0A+ = rmrru, RMRR_TYPE, rmrr->segment);=0A =0A if = ( ret || (rmrru->scope.devices_cnt =3D=3D 0) )=0A xfree(rmrru);=0A@= @ -609,6 +618,7 @@ acpi_parse_one_atsr(struct acpi_dmar_ent=0A = return -ENOMEM;=0A memset(atsru, 0, sizeof(struct acpi_atsr_unit));=0A = =0A+ atsru->segment =3D atsr->segment;=0A atsru->all_ports =3D = atsr->flags & 1; /* BIT0: ALL_PORTS */=0A if ( iommu_verbose )=0A = dprintk(VTDPREFIX,=0A@@ -618,7 +628,7 @@ acpi_parse_one_atsr(struct = acpi_dmar_ent=0A dev_scope_start =3D (void *)(atsr + 1);=0A = dev_scope_end =3D ((void *)atsr) + header->length;=0A ret =3D = acpi_parse_dev_scope(dev_scope_start, dev_scope_end,=0A- = atsru, ATSR_TYPE);=0A+ = atsru, ATSR_TYPE, atsr->segment);=0A }=0A else=0A {=0A--- = 2011-09-20.orig/xen/drivers/passthrough/vtd/dmar.h 2011-06-20 = 08:41:50.000000000 +0200=0A+++ 2011-09-20/xen/drivers/passthrough/vtd/dmar.= h 2011-08-25 15:06:43.000000000 +0200=0A@@ -49,6 +49,7 @@ struct = acpi_drhd_unit {=0A struct dmar_scope scope; /* must be = first member of struct */=0A struct list_head list;=0A u64 = address; /* register base address of the unit */=0A+ = u16 segment;=0A u8 include_all:1;=0A struct iommu = *iommu;=0A struct list_head ioapic_list;=0A@@ -59,12 +60,14 @@ struct = acpi_rmrr_unit {=0A struct list_head list;=0A u64 base_address;= =0A u64 end_address;=0A+ u16 segment;=0A u8 allow_all:= 1;=0A };=0A =0A struct acpi_atsr_unit {=0A struct dmar_scope scope; = /* must be first member of struct */=0A struct list_head = list;=0A+ u16 segment;=0A u8 all_ports:1;=0A };=0A =0A@@ = -84,7 +87,7 @@ struct acpi_rhsa_unit {=0A idx < rmrr->scop= e.devices_cnt; idx++)=0A =0A struct acpi_drhd_unit * acpi_find_matched_drhd= _unit(struct pci_dev *pdev);=0A-struct acpi_atsr_unit * acpi_find_matched_a= tsr_unit(u8 bus, u8 devfn);=0A+struct acpi_atsr_unit * acpi_find_matched_at= sr_unit(u16 seg, u8 bus, u8 devfn);=0A =0A #define DMAR_TYPE 1=0A #define = RMRR_TYPE 2=0A@@ -114,7 +117,7 @@ void *map_to_nocache_virt(int nr_iommus,= =0A =0A int vtd_hw_check(void);=0A void disable_pmr(struct iommu = *iommu);=0A-int is_usb_device(u8 bus, u8 devfn);=0A+int is_usb_device(u16 = seg, u8 bus, u8 devfn);=0A int is_igd_drhd(struct acpi_drhd_unit *drhd);=0A= =0A #endif /* _DMAR_H_ */=0A--- 2011-09-20.orig/xen/drivers/passthrough/vt= d/iommu.c 2011-09-20 16:04:11.000000000 +0200=0A+++ 2011-09-20/xen/dr= ivers/passthrough/vtd/iommu.c 2011-09-20 16:06:24.000000000 +0200=0A@@ = -835,16 +835,17 @@ static int iommu_page_fault_do_one(struc=0A {=0A = const char *reason;=0A int fault_type;=0A+ u16 seg =3D iommu->intel-= >drhd->segment;=0A reason =3D iommu_get_fault_reason(fault_reason, = &fault_type);=0A =0A if ( fault_type =3D=3D DMA_REMAP )=0A {=0A = INTEL_IOMMU_DEBUG(=0A- "DMAR:[%s] Request device = [%02x:%02x.%d] "=0A+ "DMAR:[%s] Request device [%04x:%02x:%0= 2x.%u] "=0A "fault addr %"PRIx64", iommu reg =3D %p\n"=0A = "DMAR:[fault reason %02xh] %s\n",=0A (type = ? "DMA Read" : "DMA Write"),=0A- (source_id >> 8), = PCI_SLOT(source_id & 0xFF),=0A+ seg, (source_id >> 8), = PCI_SLOT(source_id & 0xFF),=0A PCI_FUNC(source_id & 0xFF), = addr, iommu->reg,=0A fault_reason, reason);=0A #ifndef = __i386__ /* map_domain_page() cannot be used in this context */=0A@@ = -855,10 +856,10 @@ static int iommu_page_fault_do_one(struc=0A }=0A = else=0A INTEL_IOMMU_DEBUG(=0A- "INTR-REMAP: = Request device [%02x:%02x.%d] "=0A+ "INTR-REMAP: Request = device [%04x:%02x:%02x.%u] "=0A "fault index %"PRIx64", = iommu reg =3D %p\n"=0A "INTR-REMAP:[fault reason %02xh] = %s\n",=0A- (source_id >> 8), PCI_SLOT(source_id & 0xFF),=0A+= seg, (source_id >> 8), PCI_SLOT(source_id & 0xFF),=0A = PCI_FUNC(source_id & 0xFF), addr >> 48, iommu->reg,=0A = fault_reason, reason);=0A return 0;=0A@@ -1258,6 +1259,7 @@ int = domain_context_mapping_one(=0A struct hvm_iommu *hd =3D domain_hvm_iomm= u(domain);=0A struct context_entry *context, *context_entries;=0A = u64 maddr, pgd_maddr;=0A+ u16 seg =3D iommu->intel->drhd->segment;=0A = int agaw;=0A =0A ASSERT(spin_is_locked(&pcidevs_lock));=0A@@ -1273,7 = +1275,7 @@ int domain_context_mapping_one(=0A =0A /* First try to = get domain ownership from device structure. If that's=0A * not = available, try to read it from the context itself. */=0A- pdev =3D = pci_get_pdev(0, bus, devfn);=0A+ pdev =3D pci_get_pdev(seg, bus, = devfn);=0A if ( pdev )=0A {=0A if ( pdev->domai= n !=3D domain )=0A@@ -1385,18 +1387,20 @@ int domain_context_mapping_one(= =0A =0A unmap_vtd_domain_page(context_entries);=0A =0A- me_wifi_quir= k(domain, bus, devfn, MAP_ME_PHANTOM_FUNC);=0A+ if ( !seg )=0A+ = me_wifi_quirk(domain, bus, devfn, MAP_ME_PHANTOM_FUNC);=0A =0A return = 0;=0A }=0A =0A-static int domain_context_mapping(struct domain *domain, u8 = bus, u8 devfn)=0A+static int domain_context_mapping(=0A+ struct domain = *domain, u16 seg, u8 bus, u8 devfn)=0A {=0A struct acpi_drhd_unit = *drhd;=0A int ret =3D 0;=0A u32 type;=0A u8 secbus;=0A- = struct pci_dev *pdev =3D pci_get_pdev(0, bus, devfn);=0A+ struct = pci_dev *pdev =3D pci_get_pdev(seg, bus, devfn);=0A =0A drhd =3D = acpi_find_matched_drhd_unit(pdev);=0A if ( !drhd )=0A@@ -1414,18 = +1418,20 @@ static int domain_context_mapping(struct=0A =0A case = DEV_TYPE_PCIe_ENDPOINT:=0A if ( iommu_verbose )=0A- = dprintk(VTDPREFIX, "d%d:PCIe: map bdf =3D %x:%x.%x\n",=0A- = domain->domain_id, bus, PCI_SLOT(devfn), PCI_FUNC(devfn));=0A+ = dprintk(VTDPREFIX, "d%d:PCIe: map %04x:%02x:%02x.%u\n",=0A+ = domain->domain_id, seg, bus,=0A+ PCI_SLOT(devfn), = PCI_FUNC(devfn));=0A ret =3D domain_context_mapping_one(domain, = drhd->iommu, bus, devfn);=0A- if ( !ret && ats_device(0, bus, = devfn) )=0A- enable_ats_device(0, bus, devfn);=0A+ if ( = !ret && ats_device(seg, bus, devfn) )=0A+ enable_ats_device(seg,= bus, devfn);=0A =0A break;=0A =0A case DEV_TYPE_PCI:=0A = if ( iommu_verbose )=0A- dprintk(VTDPREFIX, "d%d:PCI: map bdf = =3D %x:%x.%x\n",=0A- domain->domain_id, bus, PCI_SLOT(de= vfn), PCI_FUNC(devfn));=0A+ dprintk(VTDPREFIX, "d%d:PCI: map = %04x:%02x:%02x.%u\n",=0A+ domain->domain_id, seg, = bus,=0A+ PCI_SLOT(devfn), PCI_FUNC(devfn));=0A =0A = ret =3D domain_context_mapping_one(domain, drhd->iommu, bus, devfn);=0A = if ( ret )=0A@@ -1448,9 +1454,9 @@ static int domain_context_mappin= g(struct=0A break;=0A =0A default:=0A- dprintk(XENLOG_ER= R VTDPREFIX, "d%d:unknown(%u): bdf =3D %x:%x.%x\n",=0A+ dprintk(XENL= OG_ERR VTDPREFIX, "d%d:unknown(%u): %04x:%02x:%02x.%u\n",=0A = domain->domain_id, type,=0A- bus, PCI_SLOT(devfn), = PCI_FUNC(devfn));=0A+ seg, bus, PCI_SLOT(devfn), PCI_FUNC(de= vfn));=0A ret =3D -EINVAL;=0A break;=0A }=0A@@ = -1509,19 +1515,21 @@ int domain_context_unmap_one(=0A spin_unlock(&iomm= u->lock);=0A unmap_vtd_domain_page(context_entries);=0A =0A- = me_wifi_quirk(domain, bus, devfn, UNMAP_ME_PHANTOM_FUNC);=0A+ if ( = !iommu->intel->drhd->segment )=0A+ me_wifi_quirk(domain, bus, = devfn, UNMAP_ME_PHANTOM_FUNC);=0A =0A return 0;=0A }=0A =0A-static int = domain_context_unmap(struct domain *domain, u8 bus, u8 devfn)=0A+static = int domain_context_unmap(=0A+ struct domain *domain, u16 seg, u8 bus, = u8 devfn)=0A {=0A struct acpi_drhd_unit *drhd;=0A struct iommu = *iommu;=0A int ret =3D 0;=0A u32 type;=0A u8 tmp_bus, = tmp_devfn, secbus;=0A- struct pci_dev *pdev =3D pci_get_pdev(0, bus, = devfn);=0A+ struct pci_dev *pdev =3D pci_get_pdev(seg, bus, devfn);=0A = int found =3D 0;=0A =0A BUG_ON(!pdev);=0A@@ -1541,18 +1549,19 @@ = static int domain_context_unmap(struct d=0A =0A case DEV_TYPE_PCIe_ENDP= OINT:=0A if ( iommu_verbose )=0A- dprintk(VTDPREFIX, = "d%d:PCIe: unmap bdf =3D %x:%x.%x\n",=0A- domain->domain= _id, bus, PCI_SLOT(devfn), PCI_FUNC(devfn));=0A+ dprintk(VTDPREF= IX, "d%d:PCIe: unmap %04x:%02x:%02x.%u\n",=0A+ = domain->domain_id, seg, bus,=0A+ PCI_SLOT(devfn), = PCI_FUNC(devfn));=0A ret =3D domain_context_unmap_one(domain, = iommu, bus, devfn);=0A- if ( !ret && ats_device(0, bus, devfn) = )=0A- disable_ats_device(0, bus, devfn);=0A+ if ( !ret = && ats_device(seg, bus, devfn) )=0A+ disable_ats_device(seg, = bus, devfn);=0A =0A break;=0A =0A case DEV_TYPE_PCI:=0A = if ( iommu_verbose )=0A- dprintk(VTDPREFIX, "d%d:PCI: unmap = bdf =3D %x:%x.%x\n",=0A- domain->domain_id, bus, = PCI_SLOT(devfn), PCI_FUNC(devfn));=0A+ dprintk(VTDPREFIX, = "d%d:PCI: unmap %04x:%02x:%02x.%u\n",=0A+ domain->domain= _id, seg, bus, PCI_SLOT(devfn), PCI_FUNC(devfn));=0A ret =3D = domain_context_unmap_one(domain, iommu, bus, devfn);=0A if ( ret = )=0A break;=0A@@ -1577,9 +1586,9 @@ static int domain_context_u= nmap(struct d=0A break;=0A =0A default:=0A- dprintk(XENL= OG_ERR VTDPREFIX, "d%d:unknown(%u): bdf =3D %x:%x.%x\n",=0A+ = dprintk(XENLOG_ERR VTDPREFIX, "d%d:unknown(%u): %04x:%02x:%02x.%u\n",=0A = domain->domain_id, type,=0A- bus, PCI_SLOT(dev= fn), PCI_FUNC(devfn));=0A+ seg, bus, PCI_SLOT(devfn), = PCI_FUNC(devfn));=0A ret =3D -EINVAL;=0A goto out;=0A = }=0A@@ -1590,7 +1599,7 @@ static int domain_context_unmap(struct d=0A = */=0A for_each_pdev ( domain, pdev )=0A {=0A- if ( = pdev->bus =3D=3D bus && pdev->devfn =3D=3D devfn )=0A+ if ( = pdev->seg =3D=3D seg && pdev->bus =3D=3D bus && pdev->devfn =3D=3D devfn = )=0A continue;=0A =0A drhd =3D acpi_find_matched_drhd_u= nit(pdev);=0A@@ -1645,11 +1654,11 @@ static int reassign_device_ownership(= =0A if ( (target !=3D dom0) && !iommu_intremap )=0A untrusted_m= si =3D 1;=0A =0A- ret =3D domain_context_unmap(source, bus, devfn);=0A+ = ret =3D domain_context_unmap(source, seg, bus, devfn);=0A if ( ret = )=0A return ret;=0A =0A- ret =3D domain_context_mapping(target, = bus, devfn);=0A+ ret =3D domain_context_mapping(target, seg, bus, = devfn);=0A if ( ret )=0A return ret;=0A =0A@@ -1884,7 +1893,8 = @@ static int intel_iommu_add_device(struct=0A if ( !pdev->domain )=0A = return -EINVAL;=0A =0A- ret =3D domain_context_mapping(pdev->dom= ain, pdev->bus, pdev->devfn);=0A+ ret =3D domain_context_mapping(pdev->d= omain, pdev->seg, pdev->bus,=0A+ pdev->devf= n);=0A if ( ret )=0A {=0A dprintk(XENLOG_ERR VTDPREFIX, = "d%d: context mapping failed\n",=0A@@ -1894,7 +1904,9 @@ static int = intel_iommu_add_device(struct=0A =0A for_each_rmrr_device ( rmrr, bdf, = i )=0A {=0A- if ( PCI_BUS(bdf) =3D=3D pdev->bus && PCI_DEVFN2(bd= f) =3D=3D pdev->devfn )=0A+ if ( rmrr->segment =3D=3D pdev->seg = &&=0A+ PCI_BUS(bdf) =3D=3D pdev->bus &&=0A+ = PCI_DEVFN2(bdf) =3D=3D pdev->devfn )=0A {=0A ret =3D = rmrr_identity_mapping(pdev->domain, rmrr);=0A if ( ret )=0A@@ = -1922,13 +1934,15 @@ static int intel_iommu_remove_device(str=0A {=0A = for_each_rmrr_device ( rmrr, bdf, i )=0A {=0A- = if ( PCI_BUS(bdf) =3D=3D pdev->bus &&=0A+ if ( rmrr->segment = =3D=3D pdev->seg &&=0A+ PCI_BUS(bdf) =3D=3D pdev->bus = &&=0A PCI_DEVFN2(bdf) =3D=3D pdev->devfn )=0A = return 0;=0A }=0A }=0A =0A- return domain_context_unmap(= pdev->domain, pdev->bus, pdev->devfn);=0A+ return domain_context_unmap(p= dev->domain, pdev->seg, pdev->bus,=0A+ = pdev->devfn);=0A }=0A =0A static void __init setup_dom0_devices(struct = domain *d)=0A@@ -1947,7 +1961,7 @@ static void __init setup_dom0_devices(st= =0A =0A pdev->domain =3D d;=0A list_add(&pdev->doma= in_list, &d->arch.pdev_list);=0A- domain_context_mapping(d, = pdev->bus, pdev->devfn);=0A+ domain_context_mapping(d, = pdev->seg, pdev->bus, pdev->devfn);=0A pci_enable_acs(pdev);=0A= pci_vtd_quirk(pdev);=0A }=0A@@ -2196,7 +2210,7 @@ = static int intel_iommu_assign_device(=0A /* FIXME: Because USB RMRR = conflicts with guest bios region,=0A * ignore USB RMRR temporarily.=0A= */=0A- if ( is_usb_device(bus, devfn) )=0A+ if ( is_usb_device(= seg, bus, devfn) )=0A {=0A ret =3D 0;=0A goto = done;=0A@@ -2205,7 +2219,9 @@ static int intel_iommu_assign_device(=0A = /* Setup rmrr identity mapping */=0A for_each_rmrr_device( rmrr, bdf, = i )=0A {=0A- if ( PCI_BUS(bdf) =3D=3D bus && PCI_DEVFN2(bdf) = =3D=3D devfn )=0A+ if ( rmrr->segment =3D=3D seg &&=0A+ = PCI_BUS(bdf) =3D=3D bus &&=0A+ PCI_DEVFN2(bdf) =3D=3D devfn = )=0A {=0A ret =3D rmrr_identity_mapping(d, rmrr);=0A = if ( ret )=0A--- 2011-09-20.orig/xen/drivers/passthrough/vtd/util= s.c 2011-08-19 17:08:35.000000000 +0200=0A+++ 2011-09-20/xen/drivers/pa= ssthrough/vtd/utils.c 2011-08-25 15:06:43.000000000 +0200=0A@@ -32,7 = +32,7 @@=0A #include <asm/io_apic.h>=0A #endif=0A =0A-int is_usb_device(u8 = bus, u8 devfn)=0A+int is_usb_device(u16 seg, u8 bus, u8 devfn)=0A {=0A = u16 class =3D pci_conf_read16(bus, PCI_SLOT(devfn), PCI_FUNC(devfn),=0A = PCI_CLASS_DEVICE);=0A@@ -106,8 +106,9 @@ void = print_vtd_entries(struct iommu *iom=0A u64 *l, val;=0A u32 = l_index, level;=0A =0A- printk("print_vtd_entries: iommu =3D %p bdf =3D = %x:%x.%x gmfn =3D %"PRIx64"\n",=0A- iommu, bus, PCI_SLOT(devfn), = PCI_FUNC(devfn), gmfn);=0A+ printk("print_vtd_entries: iommu %p dev = %04x:%02x:%02x.%u gmfn %"PRIx64"\n",=0A+ iommu, iommu->intel->drh= d->segment, bus,=0A+ PCI_SLOT(devfn), PCI_FUNC(devfn), gmfn);=0A = =0A if ( iommu->root_maddr =3D=3D 0 )=0A {=0A--- 2011-09-20.orig/xe= n/drivers/passthrough/vtd/x86/ats.c 2011-08-25 15:06:35.000000000 = +0200=0A+++ 2011-09-20/xen/drivers/passthrough/vtd/x86/ats.c 2011-08-25 = 15:06:43.000000000 +0200=0A@@ -104,7 +104,7 @@ int ats_device(int seg, int = bus, int dev=0A !ecap_dev_iotlb(drhd->iommu->ecap) )=0A = return 0;=0A =0A- if ( !acpi_find_matched_atsr_unit(bus, devfn) )=0A+ = if ( !acpi_find_matched_atsr_unit(seg, bus, devfn) )=0A return = 0;=0A =0A ats_drhd =3D find_ats_dev_drhd(drhd->iommu);=0A --=__Part37180CC7.0__= Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel --=__Part37180CC7.0__=-- From xen-devel-bounces@lists.xensource.com Tue Sep 20 08:22:59 2011 Return-path: <xen-devel-bounces@lists.xensource.com> Envelope-to: www-data@lists.xensource.com Delivery-date: Tue, 20 Sep 2011 08:22:59 -0700 Received: from localhost ([127.0.0.1] helo=lists.colo.xensource.com) by lists.xensource.com with esmtp (Exim 4.43) id 1R629y-0001GD-VV; Tue, 20 Sep 2011 08:22:59 -0700 Received: from mail21.messagelabs.com ([85.158.143.35]) by lists.xensource.com with esmtp (Exim 4.43) id 1R6267-0008Dl-MA for xen-devel@lists.xensource.com; Tue, 20 Sep 2011 08:19:00 -0700 X-Env-Sender: JBeulich@suse.com X-Msg-Ref: server-15.tower-21.messagelabs.com!1316531937!51314167!1 X-Originating-IP: [130.57.49.28] X-StarScan-Version: 6.4.1; banners=-,-,- X-VirusChecked: Checked Received: (qmail 31634 invoked from network); 20 Sep 2011 15:18:57 -0000 Received: from nat28.tlf.novell.com (HELO nat28.tlf.novell.com) (130.57.49.28) by server-15.tower-21.messagelabs.com with DHE-RSA-AES256-SHA encrypted SMTP; 20 Sep 2011 15:18:57 -0000 Received: from EMEA1-MTA by nat28.tlf.novell.com with Novell_GroupWise; Tue, 20 Sep 2011 16:18:55 +0100 Message-Id: <4E78CB180200007800056D2C@nat28.tlf.novell.com> X-Mailer: Novell GroupWise Internet Agent 8.0.1 Date: Tue, 20 Sep 2011 16:19:20 +0100 From: "Jan Beulich" <JBeulich@suse.com> To: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com> Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="=__Part183723E8.0__=" Subject: [Xen-devel] [PATCH 5/7] PCI multi-seg: AMD-IOMMU specific adjustments X-BeenThere: xen-devel@lists.xensource.com X-Mailman-Version: 2.1.5 Precedence: list List-Id: Xen developer discussion <xen-devel.lists.xensource.com> List-Unsubscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe> List-Post: <mailto:xen-devel@lists.xensource.com> List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help> List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=subscribe> Sender: xen-devel-bounces@lists.xensource.com Errors-To: xen-devel-bounces@lists.xensource.com This is a MIME message. If you are reading this text, you may want to consider changing to a mail reader or gateway that understands how to properly handle MIME multipart messages. --=__Part183723E8.0__= Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: quoted-printable Content-Disposition: inline There are two places here where it is entirely unclear to me where the necessary PCI segment number should be taken from (as IVMD descriptors don't have such, only IVHD ones do). AMD confirmed that for the time being it is acceptable to imply that only segment 0 exists. Signed-off-by: Jan Beulich <jbeulich@suse.com> --- 2011-09-20.orig/xen/drivers/passthrough/amd/iommu_acpi.c 2011-06-28 = 09:41:39.000000000 +0200 +++ 2011-09-20/xen/drivers/passthrough/amd/iommu_acpi.c 2011-09-20 = 15:13:42.000000000 +0200 @@ -30,6 +30,7 @@ static unsigned short __initdata last_bd static void __init add_ivrs_mapping_entry( u16 bdf, u16 alias_id, u8 flags, struct amd_iommu *iommu) { + struct ivrs_mappings *ivrs_mappings =3D get_ivrs_mappings(iommu->seg);= u8 sys_mgt, lint1_pass, lint0_pass, nmi_pass, ext_int_pass, init_pass;= ASSERT( ivrs_mappings !=3D NULL ); =20 @@ -118,9 +119,10 @@ static void __init reserve_iommu_exclusi } =20 static void __init reserve_unity_map_for_device( - u16 bdf, unsigned long base, + u16 seg, u16 bdf, unsigned long base, unsigned long length, u8 iw, u8 ir) { + struct ivrs_mappings *ivrs_mappings =3D get_ivrs_mappings(seg); unsigned long old_top, new_top; =20 /* need to extend unity-mapped range? */ @@ -147,6 +149,7 @@ static void __init reserve_unity_map_for static int __init register_exclusion_range_for_all_devices( unsigned long base, unsigned long limit, u8 iw, u8 ir) { + int seg =3D 0; /* XXX */ unsigned long range_top, iommu_top, length; struct amd_iommu *iommu; u16 bdf; @@ -163,7 +166,7 @@ static int __init register_exclusion_ran /* reserve r/w unity-mapped page entries for devices */ /* note: these entries are part of the exclusion range */ for ( bdf =3D 0; bdf < ivrs_bdf_entries; bdf++ ) - reserve_unity_map_for_device(bdf, base, length, iw, ir); + reserve_unity_map_for_device(seg, bdf, base, length, iw, ir); /* push 'base' just outside of virtual address space */ base =3D iommu_top; } @@ -180,11 +183,13 @@ static int __init register_exclusion_ran static int __init register_exclusion_range_for_device( u16 bdf, unsigned long base, unsigned long limit, u8 iw, u8 ir) { + int seg =3D 0; /* XXX */ + struct ivrs_mappings *ivrs_mappings =3D get_ivrs_mappings(seg); unsigned long range_top, iommu_top, length; struct amd_iommu *iommu; u16 req; =20 - iommu =3D find_iommu_for_device(bdf); + iommu =3D find_iommu_for_device(seg, bdf); if ( !iommu ) { AMD_IOMMU_DEBUG("IVMD Error: No IOMMU for Dev_Id 0x%x!\n", bdf); @@ -202,8 +207,8 @@ static int __init register_exclusion_ran length =3D range_top - base; /* reserve unity-mapped page entries for device */ /* note: these entries are part of the exclusion range */ - reserve_unity_map_for_device(bdf, base, length, iw, ir); - reserve_unity_map_for_device(req, base, length, iw, ir); + reserve_unity_map_for_device(seg, bdf, base, length, iw, ir); + reserve_unity_map_for_device(seg, req, base, length, iw, ir); =20 /* push 'base' just outside of virtual address space */ base =3D iommu_top; @@ -240,11 +245,13 @@ static int __init register_exclusion_ran /* note: these entries are part of the exclusion range */ for ( bdf =3D 0; bdf < ivrs_bdf_entries; bdf++ ) { - if ( iommu =3D=3D find_iommu_for_device(bdf) ) + if ( iommu =3D=3D find_iommu_for_device(iommu->seg, bdf) ) { - reserve_unity_map_for_device(bdf, base, length, iw, ir); - req =3D ivrs_mappings[bdf].dte_requestor_id; - reserve_unity_map_for_device(req, base, length, iw, ir); + reserve_unity_map_for_device(iommu->seg, bdf, base, = length, + iw, ir); + req =3D get_ivrs_mappings(iommu->seg)[bdf].dte_requestor_i= d; + reserve_unity_map_for_device(iommu->seg, req, base, = length, + iw, ir); } } =20 @@ -627,7 +634,7 @@ static u16 __init parse_ivhd_device_exte } =20 static u16 __init parse_ivhd_device_special( - union acpi_ivhd_device *ivhd_device, + union acpi_ivhd_device *ivhd_device, u16 seg, u16 header_length, u16 block_length, struct amd_iommu *iommu) { u16 dev_length, bdf; @@ -648,7 +655,8 @@ static u16 __init parse_ivhd_device_spec =20 add_ivrs_mapping_entry(bdf, bdf, ivhd_device->header.flags, iommu); /* set device id of ioapic */ - ioapic_bdf[ivhd_device->special.handle] =3D bdf; + ioapic_sbdf[ivhd_device->special.handle].bdf =3D bdf; + ioapic_sbdf[ivhd_device->special.handle].seg =3D seg; return dev_length; } =20 @@ -729,7 +737,7 @@ static int __init parse_ivhd_block(struc break; case AMD_IOMMU_ACPI_IVHD_DEV_SPECIAL: dev_length =3D parse_ivhd_device_special( - ivhd_device, + ivhd_device, ivhd_block->pci_segment, ivhd_block->header.length, block_length, iommu); break; default: --- 2011-09-20.orig/xen/drivers/passthrough/amd/iommu_detect.c 2011-04-04 = 09:11:24.000000000 +0200 +++ 2011-09-20/xen/drivers/passthrough/amd/iommu_detect.c 2011-08-25 = 15:06:47.000000000 +0200 @@ -27,8 +27,8 @@ #include <asm/hvm/svm/amd-iommu-proto.h> #include <asm/hvm/svm/amd-iommu-acpi.h> =20 -static int __init get_iommu_msi_capabilities(u8 bus, u8 dev, u8 func, - struct amd_iommu *iommu) +static int __init get_iommu_msi_capabilities( + u16 seg, u8 bus, u8 dev, u8 func, struct amd_iommu *iommu) { int cap_ptr, cap_id; u32 cap_header; @@ -66,8 +66,8 @@ static int __init get_iommu_msi_capabili return 0; } =20 -static int __init get_iommu_capabilities(u8 bus, u8 dev, u8 func, u8 = cap_ptr, - struct amd_iommu *iommu) +static int __init get_iommu_capabilities( + u16 seg, u8 bus, u8 dev, u8 func, u8 cap_ptr, struct amd_iommu = *iommu) { u32 cap_header, cap_range, misc_info; =20 @@ -121,6 +121,11 @@ int __init amd_iommu_detect_one_acpi(voi =20 spin_lock_init(&iommu->lock); =20 + iommu->seg =3D ivhd_block->pci_segment; + if (alloc_ivrs_mappings(ivhd_block->pci_segment)) { + xfree(iommu); + return -ENOMEM; + } iommu->bdf =3D ivhd_block->header.dev_id; iommu->cap_offset =3D ivhd_block->cap_offset; iommu->mmio_base_phys =3D ivhd_block->mmio_base; @@ -147,8 +152,9 @@ int __init amd_iommu_detect_one_acpi(voi bus =3D iommu->bdf >> 8; dev =3D PCI_SLOT(iommu->bdf & 0xFF); func =3D PCI_FUNC(iommu->bdf & 0xFF); - get_iommu_capabilities(bus, dev, func, iommu->cap_offset, iommu); - get_iommu_msi_capabilities(bus, dev, func, iommu); + get_iommu_capabilities(iommu->seg, bus, dev, func, + iommu->cap_offset, iommu); + get_iommu_msi_capabilities(iommu->seg, bus, dev, func, iommu); =20 list_add_tail(&iommu->list, &amd_iommu_head); =20 --- 2011-09-20.orig/xen/drivers/passthrough/amd/iommu_init.c 2011-09-12 = 08:34:38.000000000 +0200 +++ 2011-09-20/xen/drivers/passthrough/amd/iommu_init.c 2011-08-25 = 15:06:47.000000000 +0200 @@ -33,7 +33,7 @@ static struct amd_iommu **__read_mostly=20 static int __initdata nr_amd_iommus; =20 unsigned short ivrs_bdf_entries; -struct ivrs_mappings *ivrs_mappings; +static struct radix_tree_root ivrs_maps; struct list_head amd_iommu_head; struct table_struct device_table; =20 @@ -697,7 +697,6 @@ error_out: static void __init amd_iommu_init_cleanup(void) { struct amd_iommu *iommu, *next; - int bdf; =20 /* free amd iommu list */ list_for_each_entry_safe ( iommu, next, &amd_iommu_head, list ) @@ -713,21 +712,13 @@ static void __init amd_iommu_init_cleanu } =20 /* free interrupt remapping table */ - for ( bdf =3D 0; bdf < ivrs_bdf_entries; bdf++ ) - { - if ( ivrs_mappings[bdf].intremap_table ) - amd_iommu_free_intremap_table(bdf); - } + iterate_ivrs_entries(amd_iommu_free_intremap_table); =20 /* free device table */ deallocate_iommu_table_struct(&device_table); =20 /* free ivrs_mappings[] */ - if ( ivrs_mappings ) - { - xfree(ivrs_mappings); - ivrs_mappings =3D NULL; - } + radix_tree_destroy(&ivrs_maps, xfree); =20 /* free irq_to_iommu[] */ if ( irq_to_iommu ) @@ -741,19 +732,71 @@ static void __init amd_iommu_init_cleanu iommu_intremap =3D 0; } =20 -static int __init init_ivrs_mapping(void) +/* + * We allocate an extra array element to store the segment number + * (and in the future perhaps other global information). + */ +#define IVRS_MAPPINGS_SEG(m) m[ivrs_bdf_entries].dte_requestor_id + +struct ivrs_mappings *get_ivrs_mappings(u16 seg) +{ + return radix_tree_lookup(&ivrs_maps, seg); +} + +int iterate_ivrs_mappings(int (*handler)(u16 seg, struct ivrs_mappings = *)) { + u16 seg =3D 0; + int rc =3D 0; + + do { + struct ivrs_mappings *map; + + if ( !radix_tree_gang_lookup(&ivrs_maps, (void **)&map, seg, 1) ) + break; + seg =3D IVRS_MAPPINGS_SEG(map); + rc =3D handler(seg, map); + } while ( !rc && ++seg ); + + return rc; +} + +int iterate_ivrs_entries(int (*handler)(u16 seg, struct ivrs_mappings *)) +{ + u16 seg =3D 0; + int rc =3D 0; + + do { + struct ivrs_mappings *map; + int bdf; + + if ( !radix_tree_gang_lookup(&ivrs_maps, (void **)&map, seg, 1) ) + break; + seg =3D IVRS_MAPPINGS_SEG(map); + for ( bdf =3D 0; !rc && bdf < ivrs_bdf_entries; ++bdf ) + rc =3D handler(seg, map + bdf); + } while ( !rc && ++seg ); + + return rc; +} + +int __init alloc_ivrs_mappings(u16 seg) +{ + struct ivrs_mappings *ivrs_mappings; int bdf; =20 BUG_ON( !ivrs_bdf_entries ); =20 - ivrs_mappings =3D xmalloc_array( struct ivrs_mappings, ivrs_bdf_entrie= s); + if ( get_ivrs_mappings(seg) ) + return 0; + + ivrs_mappings =3D xmalloc_array(struct ivrs_mappings, ivrs_bdf_entries= + 1); if ( ivrs_mappings =3D=3D NULL ) { AMD_IOMMU_DEBUG("Error allocating IVRS Mappings table\n"); return -ENOMEM; } memset(ivrs_mappings, 0, ivrs_bdf_entries * sizeof(struct ivrs_mapping= s)); + IVRS_MAPPINGS_SEG(ivrs_mappings) =3D seg; =20 /* assign default values for device entries */ for ( bdf =3D 0; bdf < ivrs_bdf_entries; bdf++ ) @@ -775,10 +818,14 @@ static int __init init_ivrs_mapping(void if ( amd_iommu_perdev_intremap ) spin_lock_init(&ivrs_mappings[bdf].intremap_lock); } + + radix_tree_insert(&ivrs_maps, seg, ivrs_mappings); + return 0; } =20 -static int __init amd_iommu_setup_device_table(void) +static int __init amd_iommu_setup_device_table( + u16 seg, struct ivrs_mappings *ivrs_mappings) { int bdf; void *intr_tb, *dte; @@ -849,7 +896,8 @@ int __init amd_iommu_init(void) if ( !ivrs_bdf_entries ) goto error_out; =20 - if ( init_ivrs_mapping() !=3D 0 ) + radix_tree_init(&ivrs_maps); + if ( alloc_ivrs_mappings(0) !=3D 0 ) goto error_out; =20 if ( amd_iommu_update_ivrs_mapping_acpi() !=3D 0 ) @@ -860,7 +908,7 @@ int __init amd_iommu_init(void) goto error_out; =20 /* allocate and initialize a global device table shared by all iommus = */ - if ( amd_iommu_setup_device_table() !=3D 0 ) + if ( iterate_ivrs_mappings(amd_iommu_setup_device_table) !=3D 0 ) goto error_out; =20 /* per iommu initialization */ @@ -905,7 +953,8 @@ static void invalidate_all_domain_pages( amd_iommu_flush_all_pages(d); } =20 -static void invalidate_all_devices(void) +static int _invalidate_all_devices( + u16 seg, struct ivrs_mappings *ivrs_mappings) { int bdf, req_id; unsigned long flags; @@ -913,7 +962,7 @@ static void invalidate_all_devices(void) =20 for ( bdf =3D 0; bdf < ivrs_bdf_entries; bdf++ ) { - iommu =3D find_iommu_for_device(bdf); + iommu =3D find_iommu_for_device(seg, bdf); req_id =3D ivrs_mappings[bdf].dte_requestor_id; if ( iommu ) { @@ -924,6 +973,13 @@ static void invalidate_all_devices(void) spin_unlock_irqrestore(&iommu->lock, flags); } } + + return 0; +} + +static void invalidate_all_devices(void) +{ + iterate_ivrs_mappings(_invalidate_all_devices); } =20 void amd_iommu_suspend(void) --- 2011-09-20.orig/xen/drivers/passthrough/amd/iommu_intr.c 2011-08-19 = 17:08:35.000000000 +0200 +++ 2011-09-20/xen/drivers/passthrough/amd/iommu_intr.c 2011-09-20 = 15:19:03.000000000 +0200 @@ -27,21 +27,21 @@ #define INTREMAP_LENGTH 0xB #define INTREMAP_ENTRIES (1 << INTREMAP_LENGTH) =20 -int ioapic_bdf[MAX_IO_APICS]; +struct ioapic_sbdf ioapic_sbdf[MAX_IO_APICS]; void *shared_intremap_table; static DEFINE_SPINLOCK(shared_intremap_lock); =20 -static spinlock_t* get_intremap_lock(int req_id) +static spinlock_t* get_intremap_lock(int seg, int req_id) { return (amd_iommu_perdev_intremap ? - &ivrs_mappings[req_id].intremap_lock: + &get_ivrs_mappings(seg)[req_id].intremap_lock: &shared_intremap_lock); } =20 -static int get_intremap_requestor_id(int bdf) +static int get_intremap_requestor_id(int seg, int bdf) { ASSERT( bdf < ivrs_bdf_entries ); - return ivrs_mappings[bdf].dte_requestor_id; + return get_ivrs_mappings(seg)[bdf].dte_requestor_id; } =20 static int get_intremap_offset(u8 vector, u8 dm) @@ -53,20 +53,20 @@ static int get_intremap_offset(u8 vector return offset; } =20 -static u8 *get_intremap_entry(int bdf, int offset) +static u8 *get_intremap_entry(int seg, int bdf, int offset) { u8 *table; =20 - table =3D (u8*)ivrs_mappings[bdf].intremap_table; + table =3D (u8*)get_ivrs_mappings(seg)[bdf].intremap_table; ASSERT( (table !=3D NULL) && (offset < INTREMAP_ENTRIES) ); =20 return (u8*) (table + offset); } =20 -static void free_intremap_entry(int bdf, int offset) +static void free_intremap_entry(int seg, int bdf, int offset) { u32* entry; - entry =3D (u32*)get_intremap_entry(bdf, offset); + entry =3D (u32*)get_intremap_entry(seg, bdf, offset); memset(entry, 0, sizeof(u32)); } =20 @@ -125,8 +125,8 @@ static void update_intremap_entry_from_i spinlock_t *lock; int offset; =20 - req_id =3D get_intremap_requestor_id(bdf); - lock =3D get_intremap_lock(req_id); + req_id =3D get_intremap_requestor_id(iommu->seg, bdf); + lock =3D get_intremap_lock(iommu->seg, req_id); =20 delivery_mode =3D rte->delivery_mode; vector =3D rte->vector; @@ -136,7 +136,7 @@ static void update_intremap_entry_from_i spin_lock_irqsave(lock, flags); =20 offset =3D get_intremap_offset(vector, delivery_mode); - entry =3D (u32*)get_intremap_entry(req_id, offset); + entry =3D (u32*)get_intremap_entry(iommu->seg, req_id, offset); update_intremap_entry(entry, vector, delivery_mode, dest_mode, dest); =20 spin_unlock_irqrestore(lock, flags); @@ -157,7 +157,7 @@ int __init amd_iommu_setup_ioapic_remapp u32* entry; int apic, pin; u8 delivery_mode, dest, vector, dest_mode; - u16 bdf, req_id; + u16 seg, bdf, req_id; struct amd_iommu *iommu; spinlock_t *lock; int offset; @@ -174,17 +174,18 @@ int __init amd_iommu_setup_ioapic_remapp continue; =20 /* get device id of ioapic devices */ - bdf =3D ioapic_bdf[IO_APIC_ID(apic)]; - iommu =3D find_iommu_for_device(bdf); + bdf =3D ioapic_sbdf[IO_APIC_ID(apic)].bdf; + seg =3D ioapic_sbdf[IO_APIC_ID(apic)].seg; + iommu =3D find_iommu_for_device(seg, bdf); if ( !iommu ) { AMD_IOMMU_DEBUG("Fail to find iommu for ioapic " - "device id =3D 0x%x\n", bdf); + "device id =3D %04x:%04x\n", seg, bdf); continue; } =20 - req_id =3D get_intremap_requestor_id(bdf); - lock =3D get_intremap_lock(req_id); + req_id =3D get_intremap_requestor_id(iommu->seg, bdf); + lock =3D get_intremap_lock(iommu->seg, req_id); =20 delivery_mode =3D rte.delivery_mode; vector =3D rte.vector; @@ -193,7 +194,7 @@ int __init amd_iommu_setup_ioapic_remapp =20 spin_lock_irqsave(lock, flags); offset =3D get_intremap_offset(vector, delivery_mode); - entry =3D (u32*)get_intremap_entry(req_id, offset); + entry =3D (u32*)get_intremap_entry(iommu->seg, req_id, = offset); update_intremap_entry(entry, vector, delivery_mode, dest_mode, dest); spin_unlock_irqrestore(lock, flags); @@ -216,7 +217,7 @@ void amd_iommu_ioapic_update_ire( struct IO_APIC_route_entry old_rte =3D { 0 }; struct IO_APIC_route_entry new_rte =3D { 0 }; unsigned int rte_lo =3D (reg & 1) ? reg - 1 : reg; - int saved_mask, bdf; + int saved_mask, seg, bdf; struct amd_iommu *iommu; =20 if ( !iommu_intremap ) @@ -226,12 +227,13 @@ void amd_iommu_ioapic_update_ire( } =20 /* get device id of ioapic devices */ - bdf =3D ioapic_bdf[IO_APIC_ID(apic)]; - iommu =3D find_iommu_for_device(bdf); + bdf =3D ioapic_sbdf[IO_APIC_ID(apic)].bdf; + seg =3D ioapic_sbdf[IO_APIC_ID(apic)].seg; + iommu =3D find_iommu_for_device(seg, bdf); if ( !iommu ) { - AMD_IOMMU_DEBUG("Fail to find iommu for ioapic device id =3D = 0x%x\n", - bdf); + AMD_IOMMU_DEBUG("Fail to find iommu for ioapic device id =3D" + " %04x:%04x\n", seg, bdf); __io_apic_write(apic, reg, value); return; } @@ -289,28 +291,28 @@ static void update_intremap_entry_from_m int offset; =20 bdf =3D (pdev->bus << 8) | pdev->devfn; - req_id =3D get_dma_requestor_id(bdf); - alias_id =3D get_intremap_requestor_id(bdf); + req_id =3D get_dma_requestor_id(pdev->seg, bdf); + alias_id =3D get_intremap_requestor_id(pdev->seg, bdf); =20 if ( msg =3D=3D NULL ) { - lock =3D get_intremap_lock(req_id); + lock =3D get_intremap_lock(iommu->seg, req_id); spin_lock_irqsave(lock, flags); - free_intremap_entry(req_id, msi_desc->remap_index); + free_intremap_entry(iommu->seg, req_id, msi_desc->remap_index); spin_unlock_irqrestore(lock, flags); =20 if ( ( req_id !=3D alias_id ) && - ivrs_mappings[alias_id].intremap_table !=3D NULL ) + get_ivrs_mappings(pdev->seg)[alias_id].intremap_table !=3D = NULL ) { - lock =3D get_intremap_lock(alias_id); + lock =3D get_intremap_lock(iommu->seg, alias_id); spin_lock_irqsave(lock, flags); - free_intremap_entry(alias_id, msi_desc->remap_index); + free_intremap_entry(iommu->seg, alias_id, msi_desc->remap_inde= x); spin_unlock_irqrestore(lock, flags); } goto done; } =20 - lock =3D get_intremap_lock(req_id); + lock =3D get_intremap_lock(iommu->seg, req_id); =20 spin_lock_irqsave(lock, flags); dest_mode =3D (msg->address_lo >> MSI_ADDR_DESTMODE_SHIFT) & 0x1; @@ -320,7 +322,7 @@ static void update_intremap_entry_from_m offset =3D get_intremap_offset(vector, delivery_mode); msi_desc->remap_index =3D offset; =20 - entry =3D (u32*)get_intremap_entry(req_id, offset); + entry =3D (u32*)get_intremap_entry(iommu->seg, req_id, offset); update_intremap_entry(entry, vector, delivery_mode, dest_mode, dest); spin_unlock_irqrestore(lock, flags); =20 @@ -331,12 +333,12 @@ static void update_intremap_entry_from_m * devices. */ =20 - lock =3D get_intremap_lock(alias_id); + lock =3D get_intremap_lock(iommu->seg, alias_id); if ( ( req_id !=3D alias_id ) && - ivrs_mappings[alias_id].intremap_table !=3D NULL ) + get_ivrs_mappings(pdev->seg)[alias_id].intremap_table !=3D NULL = ) { spin_lock_irqsave(lock, flags); - entry =3D (u32*)get_intremap_entry(alias_id, offset); + entry =3D (u32*)get_intremap_entry(iommu->seg, alias_id, offset); update_intremap_entry(entry, vector, delivery_mode, dest_mode, = dest); spin_unlock_irqrestore(lock, flags); } @@ -362,7 +364,7 @@ void amd_iommu_msi_msg_update_ire( if ( !iommu_intremap ) return; =20 - iommu =3D find_iommu_for_device((pdev->bus << 8) | pdev->devfn); + iommu =3D find_iommu_for_device(pdev->seg, (pdev->bus << 8) | = pdev->devfn); =20 if ( !iommu ) { @@ -379,15 +381,18 @@ void amd_iommu_read_msi_from_ire( { } =20 -void __init amd_iommu_free_intremap_table(int bdf) +int __init amd_iommu_free_intremap_table( + u16 seg, struct ivrs_mappings *ivrs_mapping) { - void *tb =3D ivrs_mappings[bdf].intremap_table; + void *tb =3D ivrs_mapping->intremap_table; =20 if ( tb ) { __free_amd_iommu_tables(tb, INTREMAP_TABLE_ORDER); - ivrs_mappings[bdf].intremap_table =3D NULL; + ivrs_mapping->intremap_table =3D NULL; } + + return 0; } =20 void* __init amd_iommu_alloc_intremap_table(void) --- 2011-09-20.orig/xen/drivers/passthrough/amd/iommu_map.c 2011-08-25 = 08:21:53.000000000 +0200 +++ 2011-09-20/xen/drivers/passthrough/amd/iommu_map.c 2011-08-25 = 15:06:47.000000000 +0200 @@ -719,8 +719,8 @@ static int update_paging_mode(struct dom for_each_pdev( d, pdev ) { bdf =3D (pdev->bus << 8) | pdev->devfn; - req_id =3D get_dma_requestor_id(bdf); - iommu =3D find_iommu_for_device(bdf); + req_id =3D get_dma_requestor_id(pdev->seg, bdf); + iommu =3D find_iommu_for_device(pdev->seg, bdf); if ( !iommu ) { AMD_IOMMU_DEBUG("%s Fail to find iommu.\n", __func__); --- 2011-09-20.orig/xen/drivers/passthrough/amd/pci_amd_iommu.c 2011-09-20 = 16:04:06.000000000 +0200 +++ 2011-09-20/xen/drivers/passthrough/amd/pci_amd_iommu.c 2011-09-20 = 16:06:32.000000000 +0200 @@ -29,10 +29,12 @@ extern bool_t __read_mostly opt_irq_perdev_vector_map; extern bool_t __read_mostly iommu_amd_perdev_vector_map; =20 -struct amd_iommu *find_iommu_for_device(int bdf) +struct amd_iommu *find_iommu_for_device(int seg, int bdf) { + struct ivrs_mappings *ivrs_mappings =3D get_ivrs_mappings(seg); + BUG_ON ( bdf >=3D ivrs_bdf_entries ); - return ivrs_mappings[bdf].iommu; + return ivrs_mappings ? ivrs_mappings[bdf].iommu : NULL; } =20 /* @@ -43,8 +45,9 @@ struct amd_iommu *find_iommu_for_device( * Return original device id, if device has valid interrupt remapping * table setup for both select entry and alias entry. */ -int get_dma_requestor_id(u16 bdf) +int get_dma_requestor_id(u16 seg, u16 bdf) { + struct ivrs_mappings *ivrs_mappings =3D get_ivrs_mappings(seg); int req_id; =20 BUG_ON ( bdf >=3D ivrs_bdf_entries ); @@ -95,7 +98,7 @@ static void amd_iommu_setup_domain_devic valid =3D 0; =20 /* get device-table entry */ - req_id =3D get_dma_requestor_id(bdf); + req_id =3D get_dma_requestor_id(iommu->seg, bdf); dte =3D iommu->dev_table.buffer + (req_id * IOMMU_DEV_TABLE_ENTRY_SIZE= ); =20 spin_lock_irqsave(&iommu->lock, flags); @@ -139,7 +142,7 @@ static void __init amd_iommu_setup_dom0_ list_add(&pdev->domain_list, &d->arch.pdev_list); =20 bdf =3D (bus << 8) | devfn; - iommu =3D find_iommu_for_device(bdf); + iommu =3D find_iommu_for_device(pdev->seg, bdf); =20 if ( likely(iommu !=3D NULL) ) amd_iommu_setup_domain_device(d, iommu, bdf); @@ -287,7 +290,7 @@ static void amd_iommu_disable_domain_dev int req_id; =20 BUG_ON ( iommu->dev_table.buffer =3D=3D NULL ); - req_id =3D get_dma_requestor_id(bdf); + req_id =3D get_dma_requestor_id(iommu->seg, bdf); dte =3D iommu->dev_table.buffer + (req_id * IOMMU_DEV_TABLE_ENTRY_SIZE= ); =20 spin_lock_irqsave(&iommu->lock, flags); @@ -318,12 +321,12 @@ static int reassign_device( struct domai return -ENODEV; =20 bdf =3D (bus << 8) | devfn; - iommu =3D find_iommu_for_device(bdf); + iommu =3D find_iommu_for_device(seg, bdf); if ( !iommu ) { AMD_IOMMU_DEBUG("Fail to find iommu." - " %02x:%x02.%x cannot be assigned to domain = %d\n",=20 - bus, PCI_SLOT(devfn), PCI_FUNC(devfn), + " %04x:%02x:%x02.%x cannot be assigned to = dom%d\n", + seg, bus, PCI_SLOT(devfn), PCI_FUNC(devfn), target->domain_id); return -ENODEV; } @@ -339,8 +342,8 @@ static int reassign_device( struct domai allocate_domain_resources(t); =20 amd_iommu_setup_domain_device(target, iommu, bdf); - AMD_IOMMU_DEBUG("Re-assign %02x:%02x.%x from domain %d to domain = %d\n", - bus, PCI_SLOT(devfn), PCI_FUNC(devfn), + AMD_IOMMU_DEBUG("Re-assign %04x:%02x:%02x.%u from dom%d to dom%d\n", + seg, bus, PCI_SLOT(devfn), PCI_FUNC(devfn), source->domain_id, target->domain_id); =20 return 0; @@ -348,8 +351,9 @@ static int reassign_device( struct domai =20 static int amd_iommu_assign_device(struct domain *d, u16 seg, u8 bus, u8 = devfn) { + struct ivrs_mappings *ivrs_mappings =3D get_ivrs_mappings(seg); int bdf =3D (bus << 8) | devfn; - int req_id =3D get_dma_requestor_id(bdf); + int req_id =3D get_dma_requestor_id(seg, bdf); =20 if ( ivrs_mappings[req_id].unity_map_enable ) { @@ -439,12 +443,12 @@ static int amd_iommu_add_device(struct p return -EINVAL; =20 bdf =3D (pdev->bus << 8) | pdev->devfn; - iommu =3D find_iommu_for_device(bdf); + iommu =3D find_iommu_for_device(pdev->seg, bdf); if ( !iommu ) { AMD_IOMMU_DEBUG("Fail to find iommu." - " %02x:%02x.%x cannot be assigned to domain = %d\n",=20 - pdev->bus, PCI_SLOT(pdev->devfn), + " %04x:%02x:%02x.%u cannot be assigned to = dom%d\n", + pdev->seg, pdev->bus, PCI_SLOT(pdev->devfn), PCI_FUNC(pdev->devfn), pdev->domain->domain_id); return -ENODEV; } @@ -461,12 +465,12 @@ static int amd_iommu_remove_device(struc return -EINVAL; =20 bdf =3D (pdev->bus << 8) | pdev->devfn; - iommu =3D find_iommu_for_device(bdf); + iommu =3D find_iommu_for_device(pdev->seg, bdf); if ( !iommu ) { AMD_IOMMU_DEBUG("Fail to find iommu." - " %02x:%02x.%x cannot be removed from domain = %d\n",=20 - pdev->bus, PCI_SLOT(pdev->devfn), + " %04x:%02x:%02x.%u cannot be removed from = dom%d\n", + pdev->seg, pdev->bus, PCI_SLOT(pdev->devfn), PCI_FUNC(pdev->devfn), pdev->domain->domain_id); return -ENODEV; } @@ -480,7 +484,7 @@ static int amd_iommu_group_id(u16 seg, u int rt; int bdf =3D (bus << 8) | devfn; rt =3D ( bdf < ivrs_bdf_entries ) ? - get_dma_requestor_id(bdf) : + get_dma_requestor_id(seg, bdf) : bdf; return rt; } --- 2011-09-20.orig/xen/include/asm-x86/amd-iommu.h 2011-06-16 = 09:21:02.000000000 +0200 +++ 2011-09-20/xen/include/asm-x86/amd-iommu.h 2011-08-25 15:06:47.0000000= 00 +0200 @@ -40,6 +40,7 @@ struct amd_iommu { struct list_head list; spinlock_t lock; /* protect iommu */ =20 + u16 seg; u16 bdf; u8 cap_offset; u8 revision; @@ -101,6 +102,10 @@ struct ivrs_mappings { }; =20 extern unsigned short ivrs_bdf_entries; -extern struct ivrs_mappings *ivrs_mappings; + +int alloc_ivrs_mappings(u16 seg); +struct ivrs_mappings *get_ivrs_mappings(u16 seg); +int iterate_ivrs_mappings(int (*)(u16 seg, struct ivrs_mappings *)); +int iterate_ivrs_entries(int (*)(u16 seg, struct ivrs_mappings *)); =20 #endif /* _ASM_X86_64_AMD_IOMMU_H */ --- 2011-09-20.orig/xen/include/asm-x86/hvm/svm/amd-iommu-proto.h = 2011-08-19 17:08:35.000000000 +0200 +++ 2011-09-20/xen/include/asm-x86/hvm/svm/amd-iommu-proto.h 2011-09-20 = 15:12:40.000000000 +0200 @@ -65,7 +65,7 @@ int amd_iommu_reserve_domain_unity_map(s void amd_iommu_share_p2m(struct domain *d); =20 /* device table functions */ -int get_dma_requestor_id(u16 bdf); +int get_dma_requestor_id(u16 seg, u16 bdf); void amd_iommu_add_dev_table_entry( u32 *dte, u8 sys_mgt, u8 dev_ex, u8 lint1_pass, u8 lint0_pass,=20 u8 nmi_pass, u8 ext_int_pass, u8 init_pass); @@ -80,12 +80,12 @@ int send_iommu_command(struct amd_iommu=20 void flush_command_buffer(struct amd_iommu *iommu); =20 /* find iommu for bdf */ -struct amd_iommu *find_iommu_for_device(int bdf); +struct amd_iommu *find_iommu_for_device(int seg, int bdf); =20 /* interrupt remapping */ int amd_iommu_setup_ioapic_remapping(void); void *amd_iommu_alloc_intremap_table(void); -void amd_iommu_free_intremap_table(int bdf); +int amd_iommu_free_intremap_table(u16 seg, struct ivrs_mappings *); void invalidate_interrupt_table(struct amd_iommu *iommu, u16 device_id); void amd_iommu_ioapic_update_ire( unsigned int apic, unsigned int reg, unsigned int value); @@ -94,7 +94,9 @@ void amd_iommu_msi_msg_update_ire( void amd_iommu_read_msi_from_ire( struct msi_desc *msi_desc, struct msi_msg *msg); =20 -extern int ioapic_bdf[MAX_IO_APICS]; +extern struct ioapic_sbdf { + u16 bdf, seg; +} ioapic_sbdf[MAX_IO_APICS]; extern void *shared_intremap_table; =20 /* power management support */ --=__Part183723E8.0__= Content-Type: text/plain; name="pci-multi-seg-amd-iommu.patch" Content-Transfer-Encoding: quoted-printable Content-Disposition: attachment; filename="pci-multi-seg-amd-iommu.patch" There are two places here where it is entirely unclear to me where = the=0Anecessary PCI segment number should be taken from (as IVMD descriptor= s=0Adon't have such, only IVHD ones do). AMD confirmed that for the = time=0Abeing it is acceptable to imply that only segment 0 exists.=0A=0ASig= ned-off-by: Jan Beulich <jbeulich@suse.com>=0A=0A--- 2011-09-20.orig/xen/dr= ivers/passthrough/amd/iommu_acpi.c 2011-06-28 09:41:39.000000000 = +0200=0A+++ 2011-09-20/xen/drivers/passthrough/amd/iommu_acpi.c 2011-09-20 = 15:13:42.000000000 +0200=0A@@ -30,6 +30,7 @@ static unsigned short = __initdata last_bd=0A static void __init add_ivrs_mapping_entry(=0A = u16 bdf, u16 alias_id, u8 flags, struct amd_iommu *iommu)=0A {=0A+ = struct ivrs_mappings *ivrs_mappings =3D get_ivrs_mappings(iommu->seg);=0A = u8 sys_mgt, lint1_pass, lint0_pass, nmi_pass, ext_int_pass, init_pass;= =0A ASSERT( ivrs_mappings !=3D NULL );=0A =0A@@ -118,9 +119,10 @@ = static void __init reserve_iommu_exclusi=0A }=0A =0A static void __init = reserve_unity_map_for_device(=0A- u16 bdf, unsigned long base,=0A+ = u16 seg, u16 bdf, unsigned long base,=0A unsigned long length, u8 iw, = u8 ir)=0A {=0A+ struct ivrs_mappings *ivrs_mappings =3D get_ivrs_mapping= s(seg);=0A unsigned long old_top, new_top;=0A =0A /* need to = extend unity-mapped range? */=0A@@ -147,6 +149,7 @@ static void __init = reserve_unity_map_for=0A static int __init register_exclusion_range_for_all= _devices(=0A unsigned long base, unsigned long limit, u8 iw, u8 ir)=0A = {=0A+ int seg =3D 0; /* XXX */=0A unsigned long range_top, = iommu_top, length;=0A struct amd_iommu *iommu;=0A u16 bdf;=0A@@ = -163,7 +166,7 @@ static int __init register_exclusion_ran=0A /* = reserve r/w unity-mapped page entries for devices */=0A /* note: = these entries are part of the exclusion range */=0A for ( bdf =3D = 0; bdf < ivrs_bdf_entries; bdf++ )=0A- reserve_unity_map_for_dev= ice(bdf, base, length, iw, ir);=0A+ reserve_unity_map_for_device= (seg, bdf, base, length, iw, ir);=0A /* push 'base' just outside = of virtual address space */=0A base =3D iommu_top;=0A }=0A@@ = -180,11 +183,13 @@ static int __init register_exclusion_ran=0A static int = __init register_exclusion_range_for_device(=0A u16 bdf, unsigned long = base, unsigned long limit, u8 iw, u8 ir)=0A {=0A+ int seg =3D 0; /* XXX = */=0A+ struct ivrs_mappings *ivrs_mappings =3D get_ivrs_mappings(seg);= =0A unsigned long range_top, iommu_top, length;=0A struct = amd_iommu *iommu;=0A u16 req;=0A =0A- iommu =3D find_iommu_for_devic= e(bdf);=0A+ iommu =3D find_iommu_for_device(seg, bdf);=0A if ( = !iommu )=0A {=0A AMD_IOMMU_DEBUG("IVMD Error: No IOMMU for = Dev_Id 0x%x!\n", bdf);=0A@@ -202,8 +207,8 @@ static int __init register_exc= lusion_ran=0A length =3D range_top - base;=0A /* reserve = unity-mapped page entries for device */=0A /* note: these entries = are part of the exclusion range */=0A- reserve_unity_map_for_device(= bdf, base, length, iw, ir);=0A- reserve_unity_map_for_device(req, = base, length, iw, ir);=0A+ reserve_unity_map_for_device(seg, bdf, = base, length, iw, ir);=0A+ reserve_unity_map_for_device(seg, req, = base, length, iw, ir);=0A =0A /* push 'base' just outside of = virtual address space */=0A base =3D iommu_top;=0A@@ -240,11 = +245,13 @@ static int __init register_exclusion_ran=0A /* note: = these entries are part of the exclusion range */=0A for ( bdf =3D = 0; bdf < ivrs_bdf_entries; bdf++ )=0A {=0A- if ( iommu = =3D=3D find_iommu_for_device(bdf) )=0A+ if ( iommu =3D=3D = find_iommu_for_device(iommu->seg, bdf) )=0A {=0A- = reserve_unity_map_for_device(bdf, base, length, iw, ir);=0A- = req =3D ivrs_mappings[bdf].dte_requestor_id;=0A- = reserve_unity_map_for_device(req, base, length, iw, ir);=0A+ = reserve_unity_map_for_device(iommu->seg, bdf, base, length,=0A+ = iw, ir);=0A+ req =3D = get_ivrs_mappings(iommu->seg)[bdf].dte_requestor_id;=0A+ = reserve_unity_map_for_device(iommu->seg, req, base, length,=0A+ = iw, ir);=0A }=0A }=0A = =0A@@ -627,7 +634,7 @@ static u16 __init parse_ivhd_device_exte=0A }=0A = =0A static u16 __init parse_ivhd_device_special(=0A- union acpi_ivhd_dev= ice *ivhd_device,=0A+ union acpi_ivhd_device *ivhd_device, u16 seg,=0A = u16 header_length, u16 block_length, struct amd_iommu *iommu)=0A {=0A = u16 dev_length, bdf;=0A@@ -648,7 +655,8 @@ static u16 __init parse_ivhd_d= evice_spec=0A =0A add_ivrs_mapping_entry(bdf, bdf, ivhd_device->header.= flags, iommu);=0A /* set device id of ioapic */=0A- ioapic_bdf[ivhd_= device->special.handle] =3D bdf;=0A+ ioapic_sbdf[ivhd_device->special.ha= ndle].bdf =3D bdf;=0A+ ioapic_sbdf[ivhd_device->special.handle].seg =3D = seg;=0A return dev_length;=0A }=0A =0A@@ -729,7 +737,7 @@ static int = __init parse_ivhd_block(struc=0A break;=0A case = AMD_IOMMU_ACPI_IVHD_DEV_SPECIAL:=0A dev_length =3D parse_ivhd_d= evice_special(=0A- ivhd_device,=0A+ = ivhd_device, ivhd_block->pci_segment,=0A ivhd_block->header= .length, block_length, iommu);=0A break;=0A default:=0A= --- 2011-09-20.orig/xen/drivers/passthrough/amd/iommu_detect.c 2011-04-04 = 09:11:24.000000000 +0200=0A+++ 2011-09-20/xen/drivers/passthrough/amd/iommu= _detect.c 2011-08-25 15:06:47.000000000 +0200=0A@@ -27,8 +27,8 @@=0A = #include <asm/hvm/svm/amd-iommu-proto.h>=0A #include <asm/hvm/svm/amd-iommu= -acpi.h>=0A =0A-static int __init get_iommu_msi_capabilities(u8 bus, u8 = dev, u8 func,=0A- struct amd_iommu *iommu)=0A+static int __init = get_iommu_msi_capabilities(=0A+ u16 seg, u8 bus, u8 dev, u8 func, = struct amd_iommu *iommu)=0A {=0A int cap_ptr, cap_id;=0A u32 = cap_header;=0A@@ -66,8 +66,8 @@ static int __init get_iommu_msi_capabili=0A= return 0;=0A }=0A =0A-static int __init get_iommu_capabilities(u8 = bus, u8 dev, u8 func, u8 cap_ptr,=0A- = struct amd_iommu *iommu)=0A+static int __init get_iommu_capabilities(=0A+ = u16 seg, u8 bus, u8 dev, u8 func, u8 cap_ptr, struct amd_iommu *iommu)=0A= {=0A u32 cap_header, cap_range, misc_info;=0A =0A@@ -121,6 +121,11 @@ = int __init amd_iommu_detect_one_acpi(voi=0A =0A spin_lock_init(&iommu->= lock);=0A =0A+ iommu->seg =3D ivhd_block->pci_segment;=0A+ if = (alloc_ivrs_mappings(ivhd_block->pci_segment)) {=0A+ xfree(iommu);= =0A+ return -ENOMEM;=0A+ }=0A iommu->bdf =3D ivhd_block->head= er.dev_id;=0A iommu->cap_offset =3D ivhd_block->cap_offset;=0A = iommu->mmio_base_phys =3D ivhd_block->mmio_base;=0A@@ -147,8 +152,9 @@ int = __init amd_iommu_detect_one_acpi(voi=0A bus =3D iommu->bdf >> 8;=0A = dev =3D PCI_SLOT(iommu->bdf & 0xFF);=0A func =3D PCI_FUNC(iommu->bdf = & 0xFF);=0A- get_iommu_capabilities(bus, dev, func, iommu->cap_offset, = iommu);=0A- get_iommu_msi_capabilities(bus, dev, func, iommu);=0A+ = get_iommu_capabilities(iommu->seg, bus, dev, func,=0A+ = iommu->cap_offset, iommu);=0A+ get_iommu_msi_capabilities(iommu->s= eg, bus, dev, func, iommu);=0A =0A list_add_tail(&iommu->list, = &amd_iommu_head);=0A =0A--- 2011-09-20.orig/xen/drivers/passthrough/amd/iom= mu_init.c 2011-09-12 08:34:38.000000000 +0200=0A+++ 2011-09-20/xen/dr= ivers/passthrough/amd/iommu_init.c 2011-08-25 15:06:47.000000000 = +0200=0A@@ -33,7 +33,7 @@ static struct amd_iommu **__read_mostly =0A = static int __initdata nr_amd_iommus;=0A =0A unsigned short ivrs_bdf_entries= ;=0A-struct ivrs_mappings *ivrs_mappings;=0A+static struct radix_tree_root = ivrs_maps;=0A struct list_head amd_iommu_head;=0A struct table_struct = device_table;=0A =0A@@ -697,7 +697,6 @@ error_out:=0A static void __init = amd_iommu_init_cleanup(void)=0A {=0A struct amd_iommu *iommu, = *next;=0A- int bdf;=0A =0A /* free amd iommu list */=0A = list_for_each_entry_safe ( iommu, next, &amd_iommu_head, list )=0A@@ = -713,21 +712,13 @@ static void __init amd_iommu_init_cleanu=0A }=0A = =0A /* free interrupt remapping table */=0A- for ( bdf =3D 0; bdf < = ivrs_bdf_entries; bdf++ )=0A- {=0A- if ( ivrs_mappings[bdf].intre= map_table )=0A- amd_iommu_free_intremap_table(bdf);=0A- = }=0A+ iterate_ivrs_entries(amd_iommu_free_intremap_table);=0A =0A = /* free device table */=0A deallocate_iommu_table_struct(&device_table)= ;=0A =0A /* free ivrs_mappings[] */=0A- if ( ivrs_mappings )=0A- = {=0A- xfree(ivrs_mappings);=0A- ivrs_mappings =3D NULL;=0A- = }=0A+ radix_tree_destroy(&ivrs_maps, xfree);=0A =0A /* free = irq_to_iommu[] */=0A if ( irq_to_iommu )=0A@@ -741,19 +732,71 @@ = static void __init amd_iommu_init_cleanu=0A iommu_intremap =3D 0;=0A = }=0A =0A-static int __init init_ivrs_mapping(void)=0A+/*=0A+ * We allocate = an extra array element to store the segment number=0A+ * (and in the = future perhaps other global information).=0A+ */=0A+#define IVRS_MAPPINGS_S= EG(m) m[ivrs_bdf_entries].dte_requestor_id=0A+=0A+struct ivrs_mappings = *get_ivrs_mappings(u16 seg)=0A+{=0A+ return radix_tree_lookup(&ivrs_maps= , seg);=0A+}=0A+=0A+int iterate_ivrs_mappings(int (*handler)(u16 seg, = struct ivrs_mappings *))=0A {=0A+ u16 seg =3D 0;=0A+ int rc =3D = 0;=0A+=0A+ do {=0A+ struct ivrs_mappings *map;=0A+=0A+ if = ( !radix_tree_gang_lookup(&ivrs_maps, (void **)&map, seg, 1) )=0A+ = break;=0A+ seg =3D IVRS_MAPPINGS_SEG(map);=0A+ rc =3D = handler(seg, map);=0A+ } while ( !rc && ++seg );=0A+=0A+ return = rc;=0A+}=0A+=0A+int iterate_ivrs_entries(int (*handler)(u16 seg, struct = ivrs_mappings *))=0A+{=0A+ u16 seg =3D 0;=0A+ int rc =3D 0;=0A+=0A+ = do {=0A+ struct ivrs_mappings *map;=0A+ int bdf;=0A+=0A+ = if ( !radix_tree_gang_lookup(&ivrs_maps, (void **)&map, seg, 1) )=0A+ = break;=0A+ seg =3D IVRS_MAPPINGS_SEG(map);=0A+ = for ( bdf =3D 0; !rc && bdf < ivrs_bdf_entries; ++bdf )=0A+ rc = =3D handler(seg, map + bdf);=0A+ } while ( !rc && ++seg );=0A+=0A+ = return rc;=0A+}=0A+=0A+int __init alloc_ivrs_mappings(u16 seg)=0A+{=0A+ = struct ivrs_mappings *ivrs_mappings;=0A int bdf;=0A =0A BUG_ON( = !ivrs_bdf_entries );=0A =0A- ivrs_mappings =3D xmalloc_array( struct = ivrs_mappings, ivrs_bdf_entries);=0A+ if ( get_ivrs_mappings(seg) )=0A+ = return 0;=0A+=0A+ ivrs_mappings =3D xmalloc_array(struct = ivrs_mappings, ivrs_bdf_entries + 1);=0A if ( ivrs_mappings =3D=3D = NULL )=0A {=0A AMD_IOMMU_DEBUG("Error allocating IVRS Mappings = table\n");=0A return -ENOMEM;=0A }=0A memset(ivrs_mappings,= 0, ivrs_bdf_entries * sizeof(struct ivrs_mappings));=0A+ IVRS_MAPPINGS_= SEG(ivrs_mappings) =3D seg;=0A =0A /* assign default values for device = entries */=0A for ( bdf =3D 0; bdf < ivrs_bdf_entries; bdf++ )=0A@@ = -775,10 +818,14 @@ static int __init init_ivrs_mapping(void=0A if = ( amd_iommu_perdev_intremap )=0A spin_lock_init(&ivrs_mappings[= bdf].intremap_lock);=0A }=0A+=0A+ radix_tree_insert(&ivrs_maps, = seg, ivrs_mappings);=0A+=0A return 0;=0A }=0A =0A-static int __init = amd_iommu_setup_device_table(void)=0A+static int __init amd_iommu_setup_dev= ice_table(=0A+ u16 seg, struct ivrs_mappings *ivrs_mappings)=0A {=0A = int bdf;=0A void *intr_tb, *dte;=0A@@ -849,7 +896,8 @@ int __init = amd_iommu_init(void)=0A if ( !ivrs_bdf_entries )=0A goto = error_out;=0A =0A- if ( init_ivrs_mapping() !=3D 0 )=0A+ radix_tree_i= nit(&ivrs_maps);=0A+ if ( alloc_ivrs_mappings(0) !=3D 0 )=0A = goto error_out;=0A =0A if ( amd_iommu_update_ivrs_mapping_acpi() !=3D = 0 )=0A@@ -860,7 +908,7 @@ int __init amd_iommu_init(void)=0A goto = error_out;=0A =0A /* allocate and initialize a global device table = shared by all iommus */=0A- if ( amd_iommu_setup_device_table() !=3D 0 = )=0A+ if ( iterate_ivrs_mappings(amd_iommu_setup_device_table) !=3D 0 = )=0A goto error_out;=0A =0A /* per iommu initialization = */=0A@@ -905,7 +953,8 @@ static void invalidate_all_domain_pages(=0A = amd_iommu_flush_all_pages(d);=0A }=0A =0A-static void invalidate_all_devi= ces(void)=0A+static int _invalidate_all_devices(=0A+ u16 seg, struct = ivrs_mappings *ivrs_mappings)=0A {=0A int bdf, req_id;=0A unsigned = long flags;=0A@@ -913,7 +962,7 @@ static void invalidate_all_devices(void)= =0A =0A for ( bdf =3D 0; bdf < ivrs_bdf_entries; bdf++ )=0A {=0A- = iommu =3D find_iommu_for_device(bdf);=0A+ iommu =3D find_iommu= _for_device(seg, bdf);=0A req_id =3D ivrs_mappings[bdf].dte_request= or_id;=0A if ( iommu )=0A {=0A@@ -924,6 +973,13 @@ static = void invalidate_all_devices(void)=0A spin_unlock_irqrestore(&io= mmu->lock, flags);=0A }=0A }=0A+=0A+ return 0;=0A+}=0A+=0A+s= tatic void invalidate_all_devices(void)=0A+{=0A+ iterate_ivrs_mappings(_= invalidate_all_devices);=0A }=0A =0A void amd_iommu_suspend(void)=0A--- = 2011-09-20.orig/xen/drivers/passthrough/amd/iommu_intr.c 2011-08-19 = 17:08:35.000000000 +0200=0A+++ 2011-09-20/xen/drivers/passthrough/amd/iommu= _intr.c 2011-09-20 15:19:03.000000000 +0200=0A@@ -27,21 +27,21 @@=0A = #define INTREMAP_LENGTH 0xB=0A #define INTREMAP_ENTRIES (1 << INTREMAP_LENG= TH)=0A =0A-int ioapic_bdf[MAX_IO_APICS];=0A+struct ioapic_sbdf ioapic_sbdf[= MAX_IO_APICS];=0A void *shared_intremap_table;=0A static DEFINE_SPINLOCK(sh= ared_intremap_lock);=0A =0A-static spinlock_t* get_intremap_lock(int = req_id)=0A+static spinlock_t* get_intremap_lock(int seg, int req_id)=0A = {=0A return (amd_iommu_perdev_intremap ?=0A- &ivrs_mappings[r= eq_id].intremap_lock:=0A+ &get_ivrs_mappings(seg)[req_id].intrema= p_lock:=0A &shared_intremap_lock);=0A }=0A =0A-static int = get_intremap_requestor_id(int bdf)=0A+static int get_intremap_requestor_id(= int seg, int bdf)=0A {=0A ASSERT( bdf < ivrs_bdf_entries );=0A- = return ivrs_mappings[bdf].dte_requestor_id;=0A+ return get_ivrs_mappings= (seg)[bdf].dte_requestor_id;=0A }=0A =0A static int get_intremap_offset(u8 = vector, u8 dm)=0A@@ -53,20 +53,20 @@ static int get_intremap_offset(u8 = vector=0A return offset;=0A }=0A =0A-static u8 *get_intremap_entry(int = bdf, int offset)=0A+static u8 *get_intremap_entry(int seg, int bdf, int = offset)=0A {=0A u8 *table;=0A =0A- table =3D (u8*)ivrs_mappings[bdf]= .intremap_table;=0A+ table =3D (u8*)get_ivrs_mappings(seg)[bdf].intremap= _table;=0A ASSERT( (table !=3D NULL) && (offset < INTREMAP_ENTRIES) = );=0A =0A return (u8*) (table + offset);=0A }=0A =0A-static void = free_intremap_entry(int bdf, int offset)=0A+static void free_intremap_entry= (int seg, int bdf, int offset)=0A {=0A u32* entry;=0A- entry =3D = (u32*)get_intremap_entry(bdf, offset);=0A+ entry =3D (u32*)get_intremap_= entry(seg, bdf, offset);=0A memset(entry, 0, sizeof(u32));=0A }=0A = =0A@@ -125,8 +125,8 @@ static void update_intremap_entry_from_i=0A = spinlock_t *lock;=0A int offset;=0A =0A- req_id =3D get_intremap_req= uestor_id(bdf);=0A- lock =3D get_intremap_lock(req_id);=0A+ req_id = =3D get_intremap_requestor_id(iommu->seg, bdf);=0A+ lock =3D get_intrema= p_lock(iommu->seg, req_id);=0A =0A delivery_mode =3D rte->delivery_mode= ;=0A vector =3D rte->vector;=0A@@ -136,7 +136,7 @@ static void = update_intremap_entry_from_i=0A spin_lock_irqsave(lock, flags);=0A =0A = offset =3D get_intremap_offset(vector, delivery_mode);=0A- entry = =3D (u32*)get_intremap_entry(req_id, offset);=0A+ entry =3D (u32*)get_in= tremap_entry(iommu->seg, req_id, offset);=0A update_intremap_entry(entr= y, vector, delivery_mode, dest_mode, dest);=0A =0A spin_unlock_irqresto= re(lock, flags);=0A@@ -157,7 +157,7 @@ int __init amd_iommu_setup_ioapic_re= mapp=0A u32* entry;=0A int apic, pin;=0A u8 delivery_mode, = dest, vector, dest_mode;=0A- u16 bdf, req_id;=0A+ u16 seg, bdf, = req_id;=0A struct amd_iommu *iommu;=0A spinlock_t *lock;=0A = int offset;=0A@@ -174,17 +174,18 @@ int __init amd_iommu_setup_ioapic_remap= p=0A continue;=0A =0A /* get device id of = ioapic devices */=0A- bdf =3D ioapic_bdf[IO_APIC_ID(apic)];=0A- = iommu =3D find_iommu_for_device(bdf);=0A+ bdf =3D = ioapic_sbdf[IO_APIC_ID(apic)].bdf;=0A+ seg =3D ioapic_sbdf[IO_AP= IC_ID(apic)].seg;=0A+ iommu =3D find_iommu_for_device(seg, = bdf);=0A if ( !iommu )=0A {=0A = AMD_IOMMU_DEBUG("Fail to find iommu for ioapic "=0A- = "device id =3D 0x%x\n", bdf);=0A+ = "device id =3D %04x:%04x\n", seg, bdf);=0A continue;=0A = }=0A =0A- req_id =3D get_intremap_requestor_id(bdf);=0A= - lock =3D get_intremap_lock(req_id);=0A+ req_id =3D = get_intremap_requestor_id(iommu->seg, bdf);=0A+ lock =3D = get_intremap_lock(iommu->seg, req_id);=0A =0A delivery_mode = =3D rte.delivery_mode;=0A vector =3D rte.vector;=0A@@ -193,7 = +194,7 @@ int __init amd_iommu_setup_ioapic_remapp=0A =0A = spin_lock_irqsave(lock, flags);=0A offset =3D get_intremap_offs= et(vector, delivery_mode);=0A- entry =3D (u32*)get_intremap_entr= y(req_id, offset);=0A+ entry =3D (u32*)get_intremap_entry(iommu-= >seg, req_id, offset);=0A update_intremap_entry(entry, = vector,=0A delivery_mode, dest_mode, = dest);=0A spin_unlock_irqrestore(lock, flags);=0A@@ -216,7 = +217,7 @@ void amd_iommu_ioapic_update_ire(=0A struct IO_APIC_route_ent= ry old_rte =3D { 0 };=0A struct IO_APIC_route_entry new_rte =3D { 0 = };=0A unsigned int rte_lo =3D (reg & 1) ? reg - 1 : reg;=0A- int = saved_mask, bdf;=0A+ int saved_mask, seg, bdf;=0A struct amd_iommu = *iommu;=0A =0A if ( !iommu_intremap )=0A@@ -226,12 +227,13 @@ void = amd_iommu_ioapic_update_ire(=0A }=0A =0A /* get device id of = ioapic devices */=0A- bdf =3D ioapic_bdf[IO_APIC_ID(apic)];=0A- = iommu =3D find_iommu_for_device(bdf);=0A+ bdf =3D ioapic_sbdf[IO_APIC_ID= (apic)].bdf;=0A+ seg =3D ioapic_sbdf[IO_APIC_ID(apic)].seg;=0A+ = iommu =3D find_iommu_for_device(seg, bdf);=0A if ( !iommu )=0A = {=0A- AMD_IOMMU_DEBUG("Fail to find iommu for ioapic device id =3D = 0x%x\n",=0A- bdf);=0A+ AMD_IOMMU_DEBUG("Fail = to find iommu for ioapic device id =3D"=0A+ " = %04x:%04x\n", seg, bdf);=0A __io_apic_write(apic, reg, value);=0A = return;=0A }=0A@@ -289,28 +291,28 @@ static void update_intremap= _entry_from_m=0A int offset;=0A =0A bdf =3D (pdev->bus << 8) | = pdev->devfn;=0A- req_id =3D get_dma_requestor_id(bdf);=0A- alias_id = =3D get_intremap_requestor_id(bdf);=0A+ req_id =3D get_dma_requestor_id(= pdev->seg, bdf);=0A+ alias_id =3D get_intremap_requestor_id(pdev->seg, = bdf);=0A =0A if ( msg =3D=3D NULL )=0A {=0A- lock =3D = get_intremap_lock(req_id);=0A+ lock =3D get_intremap_lock(iommu->seg= , req_id);=0A spin_lock_irqsave(lock, flags);=0A- free_intre= map_entry(req_id, msi_desc->remap_index);=0A+ free_intremap_entry(io= mmu->seg, req_id, msi_desc->remap_index);=0A spin_unlock_irqrestore= (lock, flags);=0A =0A if ( ( req_id !=3D alias_id ) &&=0A- = ivrs_mappings[alias_id].intremap_table !=3D NULL )=0A+ = get_ivrs_mappings(pdev->seg)[alias_id].intremap_table !=3D NULL )=0A = {=0A- lock =3D get_intremap_lock(alias_id);=0A+ = lock =3D get_intremap_lock(iommu->seg, alias_id);=0A spin_lock_= irqsave(lock, flags);=0A- free_intremap_entry(alias_id, = msi_desc->remap_index);=0A+ free_intremap_entry(iommu->seg, = alias_id, msi_desc->remap_index);=0A spin_unlock_irqrestore(loc= k, flags);=0A }=0A goto done;=0A }=0A =0A- lock =3D = get_intremap_lock(req_id);=0A+ lock =3D get_intremap_lock(iommu->seg, = req_id);=0A =0A spin_lock_irqsave(lock, flags);=0A dest_mode =3D = (msg->address_lo >> MSI_ADDR_DESTMODE_SHIFT) & 0x1;=0A@@ -320,7 +322,7 @@ = static void update_intremap_entry_from_m=0A offset =3D get_intremap_off= set(vector, delivery_mode);=0A msi_desc->remap_index =3D offset;=0A = =0A- entry =3D (u32*)get_intremap_entry(req_id, offset);=0A+ entry = =3D (u32*)get_intremap_entry(iommu->seg, req_id, offset);=0A update_int= remap_entry(entry, vector, delivery_mode, dest_mode, dest);=0A = spin_unlock_irqrestore(lock, flags);=0A =0A@@ -331,12 +333,12 @@ static = void update_intremap_entry_from_m=0A * devices.=0A */=0A =0A- = lock =3D get_intremap_lock(alias_id);=0A+ lock =3D get_intremap_lock(iom= mu->seg, alias_id);=0A if ( ( req_id !=3D alias_id ) &&=0A- = ivrs_mappings[alias_id].intremap_table !=3D NULL )=0A+ get_ivrs_map= pings(pdev->seg)[alias_id].intremap_table !=3D NULL )=0A {=0A = spin_lock_irqsave(lock, flags);=0A- entry =3D (u32*)get_intremap_ent= ry(alias_id, offset);=0A+ entry =3D (u32*)get_intremap_entry(iommu->= seg, alias_id, offset);=0A update_intremap_entry(entry, vector, = delivery_mode, dest_mode, dest);=0A spin_unlock_irqrestore(lock, = flags);=0A }=0A@@ -362,7 +364,7 @@ void amd_iommu_msi_msg_update_ire(= =0A if ( !iommu_intremap )=0A return;=0A =0A- iommu =3D = find_iommu_for_device((pdev->bus << 8) | pdev->devfn);=0A+ iommu =3D = find_iommu_for_device(pdev->seg, (pdev->bus << 8) | pdev->devfn);=0A =0A = if ( !iommu )=0A {=0A@@ -379,15 +381,18 @@ void amd_iommu_read_msi_fr= om_ire(=0A {=0A }=0A =0A-void __init amd_iommu_free_intremap_table(int = bdf)=0A+int __init amd_iommu_free_intremap_table(=0A+ u16 seg, struct = ivrs_mappings *ivrs_mapping)=0A {=0A- void *tb =3D ivrs_mappings[bdf].in= tremap_table;=0A+ void *tb =3D ivrs_mapping->intremap_table;=0A =0A = if ( tb )=0A {=0A __free_amd_iommu_tables(tb, INTREMAP_TABLE_OR= DER);=0A- ivrs_mappings[bdf].intremap_table =3D NULL;=0A+ = ivrs_mapping->intremap_table =3D NULL;=0A }=0A+=0A+ return 0;=0A = }=0A =0A void* __init amd_iommu_alloc_intremap_table(void)=0A--- 2011-09-20= .orig/xen/drivers/passthrough/amd/iommu_map.c 2011-08-25 08:21:53.0000000= 00 +0200=0A+++ 2011-09-20/xen/drivers/passthrough/amd/iommu_map.c = 2011-08-25 15:06:47.000000000 +0200=0A@@ -719,8 +719,8 @@ static int = update_paging_mode(struct dom=0A for_each_pdev( d, pdev )=0A = {=0A bdf =3D (pdev->bus << 8) | pdev->devfn;=0A- = req_id =3D get_dma_requestor_id(bdf);=0A- iommu =3D find_iommu_f= or_device(bdf);=0A+ req_id =3D get_dma_requestor_id(pdev->seg, = bdf);=0A+ iommu =3D find_iommu_for_device(pdev->seg, bdf);=0A = if ( !iommu )=0A {=0A AMD_IOMMU_DEBUG= ("%s Fail to find iommu.\n", __func__);=0A--- 2011-09-20.orig/xen/drivers/p= assthrough/amd/pci_amd_iommu.c 2011-09-20 16:04:06.000000000 +0200=0A+++ = 2011-09-20/xen/drivers/passthrough/amd/pci_amd_iommu.c 2011-09-20 = 16:06:32.000000000 +0200=0A@@ -29,10 +29,12 @@=0A extern bool_t __read_most= ly opt_irq_perdev_vector_map;=0A extern bool_t __read_mostly iommu_amd_perd= ev_vector_map;=0A =0A-struct amd_iommu *find_iommu_for_device(int = bdf)=0A+struct amd_iommu *find_iommu_for_device(int seg, int bdf)=0A {=0A+ = struct ivrs_mappings *ivrs_mappings =3D get_ivrs_mappings(seg);=0A+=0A = BUG_ON ( bdf >=3D ivrs_bdf_entries );=0A- return ivrs_mappings[bdf].i= ommu;=0A+ return ivrs_mappings ? ivrs_mappings[bdf].iommu : NULL;=0A = }=0A =0A /*=0A@@ -43,8 +45,9 @@ struct amd_iommu *find_iommu_for_device(=0A= * Return original device id, if device has valid interrupt remapping=0A = * table setup for both select entry and alias entry.=0A */=0A-int = get_dma_requestor_id(u16 bdf)=0A+int get_dma_requestor_id(u16 seg, u16 = bdf)=0A {=0A+ struct ivrs_mappings *ivrs_mappings =3D get_ivrs_mappings(= seg);=0A int req_id;=0A =0A BUG_ON ( bdf >=3D ivrs_bdf_entries = );=0A@@ -95,7 +98,7 @@ static void amd_iommu_setup_domain_devic=0A = valid =3D 0;=0A =0A /* get device-table entry */=0A- req_id =3D = get_dma_requestor_id(bdf);=0A+ req_id =3D get_dma_requestor_id(iommu->se= g, bdf);=0A dte =3D iommu->dev_table.buffer + (req_id * IOMMU_DEV_TABLE= _ENTRY_SIZE);=0A =0A spin_lock_irqsave(&iommu->lock, flags);=0A@@ = -139,7 +142,7 @@ static void __init amd_iommu_setup_dom0_=0A = list_add(&pdev->domain_list, &d->arch.pdev_list);=0A =0A bdf = =3D (bus << 8) | devfn;=0A- iommu =3D find_iommu_for_device(bdf)= ;=0A+ iommu =3D find_iommu_for_device(pdev->seg, bdf);=0A =0A = if ( likely(iommu !=3D NULL) )=0A amd_iommu_setup= _domain_device(d, iommu, bdf);=0A@@ -287,7 +290,7 @@ static void amd_iommu_= disable_domain_dev=0A int req_id;=0A =0A BUG_ON ( iommu->dev_table.= buffer =3D=3D NULL );=0A- req_id =3D get_dma_requestor_id(bdf);=0A+ = req_id =3D get_dma_requestor_id(iommu->seg, bdf);=0A dte =3D iommu->dev= _table.buffer + (req_id * IOMMU_DEV_TABLE_ENTRY_SIZE);=0A =0A = spin_lock_irqsave(&iommu->lock, flags);=0A@@ -318,12 +321,12 @@ static int = reassign_device( struct domai=0A return -ENODEV;=0A =0A bdf = =3D (bus << 8) | devfn;=0A- iommu =3D find_iommu_for_device(bdf);=0A+ = iommu =3D find_iommu_for_device(seg, bdf);=0A if ( !iommu )=0A = {=0A AMD_IOMMU_DEBUG("Fail to find iommu."=0A- = " %02x:%x02.%x cannot be assigned to domain %d\n", =0A- = bus, PCI_SLOT(devfn), PCI_FUNC(devfn),=0A+ " = %04x:%02x:%x02.%x cannot be assigned to dom%d\n",=0A+ = seg, bus, PCI_SLOT(devfn), PCI_FUNC(devfn),=0A = target->domain_id);=0A return -ENODEV;=0A }=0A@@ -339,8 +342,8 = @@ static int reassign_device( struct domai=0A allocate_domain_reso= urces(t);=0A =0A amd_iommu_setup_domain_device(target, iommu, = bdf);=0A- AMD_IOMMU_DEBUG("Re-assign %02x:%02x.%x from domain %d to = domain %d\n",=0A- bus, PCI_SLOT(devfn), PCI_FUNC(devfn),= =0A+ AMD_IOMMU_DEBUG("Re-assign %04x:%02x:%02x.%u from dom%d to = dom%d\n",=0A+ seg, bus, PCI_SLOT(devfn), PCI_FUNC(devfn)= ,=0A source->domain_id, target->domain_id);=0A =0A = return 0;=0A@@ -348,8 +351,9 @@ static int reassign_device( struct = domai=0A =0A static int amd_iommu_assign_device(struct domain *d, u16 seg, = u8 bus, u8 devfn)=0A {=0A+ struct ivrs_mappings *ivrs_mappings =3D = get_ivrs_mappings(seg);=0A int bdf =3D (bus << 8) | devfn;=0A- int = req_id =3D get_dma_requestor_id(bdf);=0A+ int req_id =3D get_dma_request= or_id(seg, bdf);=0A =0A if ( ivrs_mappings[req_id].unity_map_enable = )=0A {=0A@@ -439,12 +443,12 @@ static int amd_iommu_add_device(struct = p=0A return -EINVAL;=0A =0A bdf =3D (pdev->bus << 8) | = pdev->devfn;=0A- iommu =3D find_iommu_for_device(bdf);=0A+ iommu =3D = find_iommu_for_device(pdev->seg, bdf);=0A if ( !iommu )=0A {=0A = AMD_IOMMU_DEBUG("Fail to find iommu."=0A- " = %02x:%02x.%x cannot be assigned to domain %d\n", =0A- = pdev->bus, PCI_SLOT(pdev->devfn),=0A+ " %04x:%02x:= %02x.%u cannot be assigned to dom%d\n",=0A+ = pdev->seg, pdev->bus, PCI_SLOT(pdev->devfn),=0A = PCI_FUNC(pdev->devfn), pdev->domain->domain_id);=0A return = -ENODEV;=0A }=0A@@ -461,12 +465,12 @@ static int amd_iommu_remove_devic= e(struc=0A return -EINVAL;=0A =0A bdf =3D (pdev->bus << 8) | = pdev->devfn;=0A- iommu =3D find_iommu_for_device(bdf);=0A+ iommu =3D = find_iommu_for_device(pdev->seg, bdf);=0A if ( !iommu )=0A {=0A = AMD_IOMMU_DEBUG("Fail to find iommu."=0A- " = %02x:%02x.%x cannot be removed from domain %d\n", =0A- = pdev->bus, PCI_SLOT(pdev->devfn),=0A+ " = %04x:%02x:%02x.%u cannot be removed from dom%d\n",=0A+ = pdev->seg, pdev->bus, PCI_SLOT(pdev->devfn),=0A = PCI_FUNC(pdev->devfn), pdev->domain->domain_id);=0A return = -ENODEV;=0A }=0A@@ -480,7 +484,7 @@ static int amd_iommu_group_id(u16 = seg, u=0A int rt;=0A int bdf =3D (bus << 8) | devfn;=0A rt =3D = ( bdf < ivrs_bdf_entries ) ?=0A- get_dma_requestor_id(bdf) :=0A+ = get_dma_requestor_id(seg, bdf) :=0A bdf;=0A return rt;=0A = }=0A--- 2011-09-20.orig/xen/include/asm-x86/amd-iommu.h 2011-06-16 = 09:21:02.000000000 +0200=0A+++ 2011-09-20/xen/include/asm-x86/amd-iommu.h = 2011-08-25 15:06:47.000000000 +0200=0A@@ -40,6 +40,7 @@ struct amd_iommu = {=0A struct list_head list;=0A spinlock_t lock; /* protect iommu = */=0A =0A+ u16 seg;=0A u16 bdf;=0A u8 cap_offset;=0A u8 = revision;=0A@@ -101,6 +102,10 @@ struct ivrs_mappings {=0A };=0A =0A = extern unsigned short ivrs_bdf_entries;=0A-extern struct ivrs_mappings = *ivrs_mappings;=0A+=0A+int alloc_ivrs_mappings(u16 seg);=0A+struct = ivrs_mappings *get_ivrs_mappings(u16 seg);=0A+int iterate_ivrs_mappings(int= (*)(u16 seg, struct ivrs_mappings *));=0A+int iterate_ivrs_entries(int = (*)(u16 seg, struct ivrs_mappings *));=0A =0A #endif /* _ASM_X86_64_AMD_IOM= MU_H */=0A--- 2011-09-20.orig/xen/include/asm-x86/hvm/svm/amd-iommu-proto.h= 2011-08-19 17:08:35.000000000 +0200=0A+++ 2011-09-20/xen/include/as= m-x86/hvm/svm/amd-iommu-proto.h 2011-09-20 15:12:40.000000000 +0200=0A@@ = -65,7 +65,7 @@ int amd_iommu_reserve_domain_unity_map(s=0A void amd_iommu_s= hare_p2m(struct domain *d);=0A =0A /* device table functions */=0A-int = get_dma_requestor_id(u16 bdf);=0A+int get_dma_requestor_id(u16 seg, u16 = bdf);=0A void amd_iommu_add_dev_table_entry(=0A u32 *dte, u8 sys_mgt, = u8 dev_ex, u8 lint1_pass, u8 lint0_pass, =0A u8 nmi_pass, u8 ext_int_pa= ss, u8 init_pass);=0A@@ -80,12 +80,12 @@ int send_iommu_command(struct = amd_iommu =0A void flush_command_buffer(struct amd_iommu *iommu);=0A =0A = /* find iommu for bdf */=0A-struct amd_iommu *find_iommu_for_device(int = bdf);=0A+struct amd_iommu *find_iommu_for_device(int seg, int bdf);=0A =0A = /* interrupt remapping */=0A int amd_iommu_setup_ioapic_remapping(void);=0A= void *amd_iommu_alloc_intremap_table(void);=0A-void amd_iommu_free_intrema= p_table(int bdf);=0A+int amd_iommu_free_intremap_table(u16 seg, struct = ivrs_mappings *);=0A void invalidate_interrupt_table(struct amd_iommu = *iommu, u16 device_id);=0A void amd_iommu_ioapic_update_ire(=0A = unsigned int apic, unsigned int reg, unsigned int value);=0A@@ -94,7 +94,9 = @@ void amd_iommu_msi_msg_update_ire(=0A void amd_iommu_read_msi_from_ire(= =0A struct msi_desc *msi_desc, struct msi_msg *msg);=0A =0A-extern int = ioapic_bdf[MAX_IO_APICS];=0A+extern struct ioapic_sbdf {=0A+ u16 bdf, = seg;=0A+} ioapic_sbdf[MAX_IO_APICS];=0A extern void *shared_intremap_table;= =0A =0A /* power management support */=0A --=__Part183723E8.0__= Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel --=__Part183723E8.0__=-- From xen-devel-bounces@lists.xensource.com Tue Sep 20 08:24:05 2011 Return-path: <xen-devel-bounces@lists.xensource.com> Envelope-to: www-data@lists.xensource.com Delivery-date: Tue, 20 Sep 2011 08:24:05 -0700 Received: from localhost ([127.0.0.1] helo=lists.colo.xensource.com) by lists.xensource.com with esmtp (Exim 4.43) id 1R62B3-0001iu-5p; Tue, 20 Sep 2011 08:24:05 -0700 Received: from mail21.messagelabs.com ([85.158.143.35]) by lists.xensource.com with esmtp (Exim 4.43) id 1R626f-0008OJ-7J for xen-devel@lists.xensource.com; Tue, 20 Sep 2011 08:19:35 -0700 X-Env-Sender: JBeulich@suse.com X-Msg-Ref: server-3.tower-21.messagelabs.com!1316531981!52304855!1 X-Originating-IP: [130.57.49.28] X-StarScan-Version: 6.4.1; banners=-,-,- X-VirusChecked: Checked Received: (qmail 9573 invoked from network); 20 Sep 2011 15:19:41 -0000 Received: from nat28.tlf.novell.com (HELO nat28.tlf.novell.com) (130.57.49.28) by server-3.tower-21.messagelabs.com with DHE-RSA-AES256-SHA encrypted SMTP; 20 Sep 2011 15:19:41 -0000 Received: from EMEA1-MTA by nat28.tlf.novell.com with Novell_GroupWise; Tue, 20 Sep 2011 16:19:29 +0100 Message-Id: <4E78CB3A0200007800056D30@nat28.tlf.novell.com> X-Mailer: Novell GroupWise Internet Agent 8.0.1 Date: Tue, 20 Sep 2011 16:19:54 +0100 From: "Jan Beulich" <JBeulich@suse.com> To: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com> Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="=__PartFBD4C00A.0__=" Subject: [Xen-devel] [PATCH 6/7] PCI multi-seg: Pass-through adjustments X-BeenThere: xen-devel@lists.xensource.com X-Mailman-Version: 2.1.5 Precedence: list List-Id: Xen developer discussion <xen-devel.lists.xensource.com> List-Unsubscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe> List-Post: <mailto:xen-devel@lists.xensource.com> List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help> List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=subscribe> Sender: xen-devel-bounces@lists.xensource.com Errors-To: xen-devel-bounces@lists.xensource.com This is a MIME message. If you are reading this text, you may want to consider changing to a mail reader or gateway that understands how to properly handle MIME multipart messages. --=__PartFBD4C00A.0__= Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: quoted-printable Content-Disposition: inline Signed-off-by: Jan Beulich <jbeulich@suse.com> --- 2011-09-20.orig/xen/drivers/passthrough/amd/pci_amd_iommu.c 2011-09-20 = 16:06:32.000000000 +0200 +++ 2011-09-20/xen/drivers/passthrough/amd/pci_amd_iommu.c 2011-09-20 = 16:06:38.000000000 +0200 @@ -123,35 +123,17 @@ static void amd_iommu_setup_domain_devic spin_unlock_irqrestore(&iommu->lock, flags); } =20 -static void __init amd_iommu_setup_dom0_devices(struct domain *d) +static void __init amd_iommu_setup_dom0_device(struct pci_dev *pdev) { - struct amd_iommu *iommu; - struct pci_dev *pdev; - int bus, devfn, bdf; + int bdf =3D (pdev->bus << 8) | pdev->devfn; + struct amd_iommu *iommu =3D find_iommu_for_device(pdev->seg, bdf); =20 - spin_lock(&pcidevs_lock); - for ( bus =3D 0; bus < 256; bus++ ) - { - for ( devfn =3D 0; devfn < 256; devfn++ ) - { - pdev =3D pci_get_pdev(0, bus, devfn); - if ( !pdev ) - continue; - - pdev->domain =3D d; - list_add(&pdev->domain_list, &d->arch.pdev_list); - - bdf =3D (bus << 8) | devfn; - iommu =3D find_iommu_for_device(pdev->seg, bdf); - - if ( likely(iommu !=3D NULL) ) - amd_iommu_setup_domain_device(d, iommu, bdf); - else - AMD_IOMMU_DEBUG("No iommu for device %02x:%02x.%x\n", - bus, PCI_SLOT(devfn), PCI_FUNC(devfn)); - } - } - spin_unlock(&pcidevs_lock); + if ( likely(iommu !=3D NULL) ) + amd_iommu_setup_domain_device(pdev->domain, iommu, bdf); + else + AMD_IOMMU_DEBUG("No iommu for device %04x:%02x:%02x.%u\n", + pdev->seg, pdev->bus, + PCI_SLOT(pdev->devfn), PCI_FUNC(pdev->devfn)); } =20 int __init amd_iov_detect(void) @@ -279,7 +261,7 @@ static void __init amd_iommu_dom0_init(s } } =20 - amd_iommu_setup_dom0_devices(d); + setup_dom0_pci_devices(d, amd_iommu_setup_dom0_device); } =20 static void amd_iommu_disable_domain_device( --- 2011-09-20.orig/xen/drivers/passthrough/pci.c 2011-08-25 = 15:06:40.000000000 +0200 +++ 2011-09-20/xen/drivers/passthrough/pci.c 2011-08-25 15:12:12.0000000= 00 +0200 @@ -202,9 +202,7 @@ struct pci_dev *pci_get_pdev_by_domain( void pci_enable_acs(struct pci_dev *pdev) { int pos; - u16 cap; - u16 ctrl; - + u16 cap, ctrl, seg =3D pdev->seg; u8 bus =3D pdev->bus; u8 dev =3D PCI_SLOT(pdev->devfn); u8 func =3D PCI_FUNC(pdev->devfn); @@ -212,7 +210,7 @@ void pci_enable_acs(struct pci_dev *pdev if ( !iommu_enabled ) return; =20 - pos =3D pci_find_ext_capability(0, bus, pdev->devfn, PCI_EXT_CAP_ID_AC= S); + pos =3D pci_find_ext_capability(seg, bus, pdev->devfn, PCI_EXT_CAP_ID_= ACS); if (!pos) return; =20 @@ -453,7 +451,7 @@ void pci_release_devices(struct domain * =20 #define PCI_CLASS_BRIDGE_PCI 0x0604 =20 -int pdev_type(u8 bus, u8 devfn) +int pdev_type(u16 seg, u8 bus, u8 devfn) { u16 class_device; u16 status, creg; @@ -488,9 +486,9 @@ int pdev_type(u8 bus, u8 devfn) * return 1: find PCIe-to-PCI/PCIX bridge or PCI legacy bridge * return -1: fail */ -int find_upstream_bridge(u8 *bus, u8 *devfn, u8 *secbus) +int find_upstream_bridge(u16 seg, u8 *bus, u8 *devfn, u8 *secbus) { - struct pci_seg *pseg =3D get_pseg(0); + struct pci_seg *pseg =3D get_pseg(seg); int ret =3D 0; int cnt =3D 0; =20 @@ -525,7 +523,7 @@ out: /* * detect pci device, return 0 if it exists, or return 0 */ -int __init pci_device_detect(u8 bus, u8 dev, u8 func) +int __init pci_device_detect(u16 seg, u8 bus, u8 dev, u8 func) { u32 vendor; =20 @@ -554,7 +552,7 @@ static int __init _scan_pci_devices(stru { for ( func =3D 0; func < 8; func++ ) { - if ( pci_device_detect(bus, dev, func) =3D=3D 0 ) + if ( pci_device_detect(pseg->nr, bus, dev, func) =3D=3D 0 = ) continue; =20 pdev =3D alloc_pdev(pseg, bus, PCI_DEVFN(dev, func)); @@ -565,7 +563,7 @@ static int __init _scan_pci_devices(stru } =20 /* build bus2bridge */ - type =3D pdev_type(bus, PCI_DEVFN(dev, func)); + type =3D pdev_type(pseg->nr, bus, PCI_DEVFN(dev, func)); switch ( type ) { case DEV_TYPE_PCIe_BRIDGE: @@ -594,8 +592,8 @@ static int __init _scan_pci_devices(stru break; =20 default: - printk("%s: unknown type: bdf =3D %x:%x.%x\n", - __func__, bus, dev, func); + printk("%s: unknown type: %04x:%02x:%02x.%u\n", + __func__, pseg->nr, bus, dev, func); return -EINVAL; } =20 @@ -620,6 +618,44 @@ int __init scan_pci_devices(void) return ret; } =20 +struct setup_dom0 { + struct domain *d; + void (*handler)(struct pci_dev *); +}; + +static int __init _setup_dom0_pci_devices(struct pci_seg *pseg, void = *arg) +{ + struct setup_dom0 *ctxt =3D arg; + int bus, devfn; + + for ( bus =3D 0; bus < 256; bus++ ) + { + for ( devfn =3D 0; devfn < 256; devfn++ ) + { + struct pci_dev *pdev =3D pci_get_pdev(pseg->nr, bus, devfn); + + if ( !pdev ) + continue; + + pdev->domain =3D ctxt->d; + list_add(&pdev->domain_list, &ctxt->d->arch.pdev_list); + ctxt->handler(pdev); + } + } + + return 0; +} + +void __init setup_dom0_pci_devices( + struct domain *d, void (*handler)(struct pci_dev *)) +{ + struct setup_dom0 ctxt =3D { .d =3D d, .handler =3D handler }; + + spin_lock(&pcidevs_lock); + pci_segments_iterate(_setup_dom0_pci_devices, &ctxt); + spin_unlock(&pcidevs_lock); +} + /* Disconnect all PCI devices from the PCI buses. From the PCI spec: * "When a 0 is written to [the COMMAND] register, the device is * logically disconnected from the PCI bus for all accesses except @@ -654,8 +690,9 @@ static int _dump_pci_devices(struct pci_ =20 list_for_each_entry ( pdev, &pseg->alldevs_list, alldevs_list ) { - printk("%02x:%02x.%x - dom %-3d - MSIs < ", - pdev->bus, PCI_SLOT(pdev->devfn), PCI_FUNC(pdev->devfn), + printk("%04x:%02x:%02x.%u - dom %-3d - MSIs < ", + pseg->nr, pdev->bus, + PCI_SLOT(pdev->devfn), PCI_FUNC(pdev->devfn), pdev->domain ? pdev->domain->domain_id : -1); list_for_each_entry ( msi, &pdev->msi_list, list ) printk("%d ", msi->irq); --- 2011-09-20.orig/xen/drivers/passthrough/vtd/dmar.c 2011-08-25 = 15:06:43.000000000 +0200 +++ 2011-09-20/xen/drivers/passthrough/vtd/dmar.c 2011-08-25 = 15:12:12.000000000 +0200 @@ -457,11 +457,11 @@ acpi_parse_one_drhd(struct acpi_dmar_ent d =3D PCI_SLOT(dmaru->scope.devices[i]); f =3D PCI_FUNC(dmaru->scope.devices[i]); =20 - if ( pci_device_detect(b, d, f) =3D=3D 0 ) + if ( pci_device_detect(drhd->segment, b, d, f) =3D=3D 0 ) { dprintk(XENLOG_WARNING VTDPREFIX, - " Non-existent device (%x:%x.%x) is reported " - "in this DRHD's scope!\n", b, d, f); + " Non-existent device (%04x:%02x:%02x.%u) is = reported" + " in this DRHD's scope!\n", drhd->segment, b, d, = f); invalid_cnt++; } } @@ -556,12 +556,13 @@ acpi_parse_one_rmrr(struct acpi_dmar_ent d =3D PCI_SLOT(rmrru->scope.devices[i]); f =3D PCI_FUNC(rmrru->scope.devices[i]); =20 - if ( pci_device_detect(b, d, f) =3D=3D 0 ) + if ( pci_device_detect(rmrr->segment, b, d, f) =3D=3D 0 ) { dprintk(XENLOG_WARNING VTDPREFIX, - " Non-existent device (%x:%x.%x) is reported " - "in RMRR (%"PRIx64", %"PRIx64")'s scope!\n", - b, d, f, rmrru->base_address, rmrru->end_address); + " Non-existent device (%04x:%02x:%02x.%u) is = reported" + " in RMRR (%"PRIx64", %"PRIx64")'s scope!\n", + rmrr->segment, b, d, f, + rmrru->base_address, rmrru->end_address); ignore =3D 1; } else --- 2011-09-20.orig/xen/drivers/passthrough/vtd/intremap.c 2011-08-19 = 17:08:35.000000000 +0200 +++ 2011-09-20/xen/drivers/passthrough/vtd/intremap.c 2011-08-25 = 15:12:12.000000000 +0200 @@ -448,15 +448,17 @@ void io_apic_write_remap_rte( static void set_msi_source_id(struct pci_dev *pdev, struct iremap_entry = *ire) { int type; + u16 seg; u8 bus, devfn, secbus; int ret; =20 if ( !pdev || !ire ) return; =20 + seg =3D pdev->seg; bus =3D pdev->bus; devfn =3D pdev->devfn; - type =3D pdev_type(bus, devfn); + type =3D pdev_type(seg, bus, devfn); switch ( type ) { case DEV_TYPE_PCIe_BRIDGE: @@ -469,7 +471,7 @@ static void set_msi_source_id(struct pci break; =20 case DEV_TYPE_PCI: - ret =3D find_upstream_bridge(&bus, &devfn, &secbus); + ret =3D find_upstream_bridge(seg, &bus, &devfn, &secbus); if ( ret =3D=3D 0 ) /* integrated PCI device */ { set_ire_sid(ire, SVT_VERIFY_SID_SQ, SQ_ALL_16, @@ -477,19 +479,20 @@ static void set_msi_source_id(struct pci } else if ( ret =3D=3D 1 ) /* find upstream bridge */ { - if ( pdev_type(bus, devfn) =3D=3D DEV_TYPE_PCIe2PCI_BRIDGE ) + if ( pdev_type(seg, bus, devfn) =3D=3D DEV_TYPE_PCIe2PCI_BRIDG= E ) set_ire_sid(ire, SVT_VERIFY_BUS, SQ_ALL_16, (bus << 8) | pdev->bus); - else if ( pdev_type(bus, devfn) =3D=3D DEV_TYPE_LEGACY_PCI_BRI= DGE ) + else if ( pdev_type(seg, bus, devfn) =3D=3D DEV_TYPE_LEGACY_PC= I_BRIDGE ) set_ire_sid(ire, SVT_VERIFY_BUS, SQ_ALL_16, PCI_BDF2(bus, devfn)); } break; =20 default: - dprintk(XENLOG_WARNING VTDPREFIX, "d%d: unknown(%u): bdf =3D = %x:%x.%x\n", + dprintk(XENLOG_WARNING VTDPREFIX, + "d%d: unknown(%u): %04x:%02x:%02x.%u\n", pdev->domain->domain_id, type, - bus, PCI_SLOT(devfn), PCI_FUNC(devfn)); + seg, bus, PCI_SLOT(devfn), PCI_FUNC(devfn)); break; } } --- 2011-09-20.orig/xen/drivers/passthrough/vtd/iommu.c 2011-09-20 = 16:06:24.000000000 +0200 +++ 2011-09-20/xen/drivers/passthrough/vtd/iommu.c 2011-09-20 = 16:06:42.000000000 +0200 @@ -50,7 +50,7 @@ bool_t __read_mostly untrusted_msi; =20 int nr_iommus; =20 -static void setup_dom0_devices(struct domain *d); +static void setup_dom0_device(struct pci_dev *); static void setup_dom0_rmrr(struct domain *d); =20 static int domain_iommu_domid(struct domain *d, @@ -1240,7 +1240,7 @@ static void __init intel_iommu_dom0_init iommu_set_dom0_mapping(d); } =20 - setup_dom0_devices(d); + setup_dom0_pci_devices(d, setup_dom0_device); setup_dom0_rmrr(d); =20 iommu_flush_all(); @@ -1408,7 +1408,7 @@ static int domain_context_mapping( =20 ASSERT(spin_is_locked(&pcidevs_lock)); =20 - type =3D pdev_type(bus, devfn); + type =3D pdev_type(seg, bus, devfn); switch ( type ) { case DEV_TYPE_PCIe_BRIDGE: @@ -1437,7 +1437,7 @@ static int domain_context_mapping( if ( ret ) break; =20 - if ( find_upstream_bridge(&bus, &devfn, &secbus) < 1 ) + if ( find_upstream_bridge(seg, &bus, &devfn, &secbus) < 1 ) break; =20 ret =3D domain_context_mapping_one(domain, drhd->iommu, bus, = devfn); @@ -1447,7 +1447,7 @@ static int domain_context_mapping( * requester-id. It may originate from devfn=3D0 on the secondary = bus * behind the bridge. Map that id as well if we didn't already. */ - if ( !ret && pdev_type(bus, devfn) =3D=3D DEV_TYPE_PCIe2PCI_BRIDGE= && + if ( !ret && pdev_type(seg, bus, devfn) =3D=3D DEV_TYPE_PCIe2PCI_B= RIDGE && (secbus !=3D pdev->bus || pdev->devfn !=3D 0) ) ret =3D domain_context_mapping_one(domain, drhd->iommu, = secbus, 0); =20 @@ -1539,7 +1539,7 @@ static int domain_context_unmap( return -ENODEV; iommu =3D drhd->iommu; =20 - type =3D pdev_type(bus, devfn); + type =3D pdev_type(seg, bus, devfn); switch ( type ) { case DEV_TYPE_PCIe_BRIDGE: @@ -1568,11 +1568,11 @@ static int domain_context_unmap( =20 tmp_bus =3D bus; tmp_devfn =3D devfn; - if ( find_upstream_bridge(&tmp_bus, &tmp_devfn, &secbus) < 1 ) + if ( find_upstream_bridge(seg, &tmp_bus, &tmp_devfn, &secbus) < 1 = ) break; =20 /* PCIe to PCI/PCIx bridge */ - if ( pdev_type(tmp_bus, tmp_devfn) =3D=3D DEV_TYPE_PCIe2PCI_BRIDGE= ) + if ( pdev_type(seg, tmp_bus, tmp_devfn) =3D=3D DEV_TYPE_PCIe2PCI_B= RIDGE ) { ret =3D domain_context_unmap_one(domain, iommu, tmp_bus, = tmp_devfn); if ( ret ) @@ -1945,28 +1945,11 @@ static int intel_iommu_remove_device(str pdev->devfn); } =20 -static void __init setup_dom0_devices(struct domain *d) +static void __init setup_dom0_device(struct pci_dev *pdev) { - struct pci_dev *pdev; - int bus, devfn; - - spin_lock(&pcidevs_lock); - for ( bus =3D 0; bus < 256; bus++ ) - { - for ( devfn =3D 0; devfn < 256; devfn++ ) - { - pdev =3D pci_get_pdev(0, bus, devfn); - if ( !pdev ) - continue; - - pdev->domain =3D d; - list_add(&pdev->domain_list, &d->arch.pdev_list); - domain_context_mapping(d, pdev->seg, pdev->bus, pdev->devfn); - pci_enable_acs(pdev); - pci_vtd_quirk(pdev); - } - } - spin_unlock(&pcidevs_lock); + domain_context_mapping(pdev->domain, pdev->seg, pdev->bus, pdev->devfn= ); + pci_enable_acs(pdev); + pci_vtd_quirk(pdev); } =20 void clear_fault_bits(struct iommu *iommu) @@ -2240,7 +2223,7 @@ done: static int intel_iommu_group_id(u16 seg, u8 bus, u8 devfn) { u8 secbus; - if ( find_upstream_bridge(&bus, &devfn, &secbus) < 0 ) + if ( find_upstream_bridge(seg, &bus, &devfn, &secbus) < 0 ) return -1; else return PCI_BDF2(bus, devfn); --- 2011-09-20.orig/xen/include/xen/pci.h 2011-08-25 15:06:35.0000000= 00 +0200 +++ 2011-09-20/xen/include/xen/pci.h 2011-08-25 15:12:12.000000000 = +0200 @@ -82,13 +82,15 @@ enum { DEV_TYPE_PCI, }; =20 -int pci_device_detect(u8 bus, u8 dev, u8 func); +int pci_device_detect(u16 seg, u8 bus, u8 dev, u8 func); int scan_pci_devices(void); -int pdev_type(u8 bus, u8 devfn); -int find_upstream_bridge(u8 *bus, u8 *devfn, u8 *secbus); -struct pci_dev *pci_lock_pdev(int bus, int devfn); -struct pci_dev *pci_lock_domain_pdev(struct domain *d, int bus, int = devfn); +int pdev_type(u16 seg, u8 bus, u8 devfn); +int find_upstream_bridge(u16 seg, u8 *bus, u8 *devfn, u8 *secbus); +struct pci_dev *pci_lock_pdev(int seg, int bus, int devfn); +struct pci_dev *pci_lock_domain_pdev( + struct domain *, int seg, int bus, int devfn); =20 +void setup_dom0_pci_devices(struct domain *, void (*)(struct pci_dev *)); void pci_release_devices(struct domain *d); int pci_add_segment(u16 seg); int pci_add_device(u16 seg, u8 bus, u8 devfn, const struct pci_dev_info = *); --=__PartFBD4C00A.0__= Content-Type: text/plain; name="pci-multi-seg-pt.patch" Content-Transfer-Encoding: quoted-printable Content-Disposition: attachment; filename="pci-multi-seg-pt.patch" Signed-off-by: Jan Beulich <jbeulich@suse.com>=0A=0A--- 2011-09-20.orig/xen= /drivers/passthrough/amd/pci_amd_iommu.c 2011-09-20 16:06:32.0000000= 00 +0200=0A+++ 2011-09-20/xen/drivers/passthrough/amd/pci_amd_iommu.c = 2011-09-20 16:06:38.000000000 +0200=0A@@ -123,35 +123,17 @@ static void = amd_iommu_setup_domain_devic=0A spin_unlock_irqrestore(&iommu->lock, = flags);=0A }=0A =0A-static void __init amd_iommu_setup_dom0_devices(struct = domain *d)=0A+static void __init amd_iommu_setup_dom0_device(struct = pci_dev *pdev)=0A {=0A- struct amd_iommu *iommu;=0A- struct pci_dev = *pdev;=0A- int bus, devfn, bdf;=0A+ int bdf =3D (pdev->bus << 8) | = pdev->devfn;=0A+ struct amd_iommu *iommu =3D find_iommu_for_device(pdev-= >seg, bdf);=0A =0A- spin_lock(&pcidevs_lock);=0A- for ( bus =3D 0; = bus < 256; bus++ )=0A- {=0A- for ( devfn =3D 0; devfn < 256; = devfn++ )=0A- {=0A- pdev =3D pci_get_pdev(0, bus, = devfn);=0A- if ( !pdev )=0A- continue;=0A-=0A- = pdev->domain =3D d;=0A- list_add(&pdev->domain_list, = &d->arch.pdev_list);=0A-=0A- bdf =3D (bus << 8) | devfn;=0A- = iommu =3D find_iommu_for_device(pdev->seg, bdf);=0A-=0A- = if ( likely(iommu !=3D NULL) )=0A- amd_iommu_setup_domain_d= evice(d, iommu, bdf);=0A- else=0A- AMD_IOMMU_DEBU= G("No iommu for device %02x:%02x.%x\n",=0A- = bus, PCI_SLOT(devfn), PCI_FUNC(devfn));=0A- }=0A- }=0A- = spin_unlock(&pcidevs_lock);=0A+ if ( likely(iommu !=3D NULL) )=0A+ = amd_iommu_setup_domain_device(pdev->domain, iommu, bdf);=0A+ else=0A+ = AMD_IOMMU_DEBUG("No iommu for device %04x:%02x:%02x.%u\n",=0A+ = pdev->seg, pdev->bus,=0A+ = PCI_SLOT(pdev->devfn), PCI_FUNC(pdev->devfn));=0A }=0A =0A int __init = amd_iov_detect(void)=0A@@ -279,7 +261,7 @@ static void __init amd_iommu_dom= 0_init(s=0A }=0A }=0A =0A- amd_iommu_setup_dom0_devices(d);= =0A+ setup_dom0_pci_devices(d, amd_iommu_setup_dom0_device);=0A }=0A = =0A static void amd_iommu_disable_domain_device(=0A--- 2011-09-20.orig/xen/= drivers/passthrough/pci.c 2011-08-25 15:06:40.000000000 +0200=0A+++ = 2011-09-20/xen/drivers/passthrough/pci.c 2011-08-25 15:12:12.0000000= 00 +0200=0A@@ -202,9 +202,7 @@ struct pci_dev *pci_get_pdev_by_domain(=0A = void pci_enable_acs(struct pci_dev *pdev)=0A {=0A int pos;=0A- u16 = cap;=0A- u16 ctrl;=0A-=0A+ u16 cap, ctrl, seg =3D pdev->seg;=0A = u8 bus =3D pdev->bus;=0A u8 dev =3D PCI_SLOT(pdev->devfn);=0A u8 = func =3D PCI_FUNC(pdev->devfn);=0A@@ -212,7 +210,7 @@ void pci_enable_acs(s= truct pci_dev *pdev=0A if ( !iommu_enabled )=0A return;=0A = =0A- pos =3D pci_find_ext_capability(0, bus, pdev->devfn, PCI_EXT_CAP_ID= _ACS);=0A+ pos =3D pci_find_ext_capability(seg, bus, pdev->devfn, = PCI_EXT_CAP_ID_ACS);=0A if (!pos)=0A return;=0A =0A@@ -453,7 = +451,7 @@ void pci_release_devices(struct domain *=0A =0A #define = PCI_CLASS_BRIDGE_PCI 0x0604=0A =0A-int pdev_type(u8 bus, u8 devfn)=0A+i= nt pdev_type(u16 seg, u8 bus, u8 devfn)=0A {=0A u16 class_device;=0A = u16 status, creg;=0A@@ -488,9 +486,9 @@ int pdev_type(u8 bus, u8 = devfn)=0A * return 1: find PCIe-to-PCI/PCIX bridge or PCI legacy = bridge=0A * return -1: fail=0A */=0A-int find_upstream_bridge(u8 *bus, = u8 *devfn, u8 *secbus)=0A+int find_upstream_bridge(u16 seg, u8 *bus, u8 = *devfn, u8 *secbus)=0A {=0A- struct pci_seg *pseg =3D get_pseg(0);=0A+ = struct pci_seg *pseg =3D get_pseg(seg);=0A int ret =3D 0;=0A int = cnt =3D 0;=0A =0A@@ -525,7 +523,7 @@ out:=0A /*=0A * detect pci device, = return 0 if it exists, or return 0=0A */=0A-int __init pci_device_detect(u= 8 bus, u8 dev, u8 func)=0A+int __init pci_device_detect(u16 seg, u8 bus, = u8 dev, u8 func)=0A {=0A u32 vendor;=0A =0A@@ -554,7 +552,7 @@ static = int __init _scan_pci_devices(stru=0A {=0A for ( func = =3D 0; func < 8; func++ )=0A {=0A- if ( = pci_device_detect(bus, dev, func) =3D=3D 0 )=0A+ if ( = pci_device_detect(pseg->nr, bus, dev, func) =3D=3D 0 )=0A = continue;=0A =0A pdev =3D alloc_pdev(pseg, bus, = PCI_DEVFN(dev, func));=0A@@ -565,7 +563,7 @@ static int __init _scan_pci_de= vices(stru=0A }=0A =0A /* build bus2bridge = */=0A- type =3D pdev_type(bus, PCI_DEVFN(dev, func));=0A+ = type =3D pdev_type(pseg->nr, bus, PCI_DEVFN(dev, func));=0A = switch ( type )=0A {=0A = case DEV_TYPE_PCIe_BRIDGE:=0A@@ -594,8 +592,8 @@ static int __init = _scan_pci_devices(stru=0A break;=0A =0A = default:=0A- printk("%s: unknown type: bdf = =3D %x:%x.%x\n",=0A- __func__, bus, dev, = func);=0A+ printk("%s: unknown type: %04x:%02x:%02x.= %u\n",=0A+ __func__, pseg->nr, bus, dev, = func);=0A return -EINVAL;=0A }=0A = =0A@@ -620,6 +618,44 @@ int __init scan_pci_devices(void)=0A return = ret;=0A }=0A =0A+struct setup_dom0 {=0A+ struct domain *d;=0A+ void = (*handler)(struct pci_dev *);=0A+};=0A+=0A+static int __init _setup_dom0_pc= i_devices(struct pci_seg *pseg, void *arg)=0A+{=0A+ struct setup_dom0 = *ctxt =3D arg;=0A+ int bus, devfn;=0A+=0A+ for ( bus =3D 0; bus < = 256; bus++ )=0A+ {=0A+ for ( devfn =3D 0; devfn < 256; devfn++ = )=0A+ {=0A+ struct pci_dev *pdev =3D pci_get_pdev(pseg->n= r, bus, devfn);=0A+=0A+ if ( !pdev )=0A+ = continue;=0A+=0A+ pdev->domain =3D ctxt->d;=0A+ = list_add(&pdev->domain_list, &ctxt->d->arch.pdev_list);=0A+ = ctxt->handler(pdev);=0A+ }=0A+ }=0A+=0A+ return 0;=0A+}=0A+=0A= +void __init setup_dom0_pci_devices(=0A+ struct domain *d, void = (*handler)(struct pci_dev *))=0A+{=0A+ struct setup_dom0 ctxt =3D { .d = =3D d, .handler =3D handler };=0A+=0A+ spin_lock(&pcidevs_lock);=0A+ = pci_segments_iterate(_setup_dom0_pci_devices, &ctxt);=0A+ spin_unlock(&p= cidevs_lock);=0A+}=0A+=0A /* Disconnect all PCI devices from the PCI = buses. From the PCI spec:=0A * "When a 0 is written to [the COMMAND] = register, the device is=0A * logically disconnected from the PCI bus = for all accesses except=0A@@ -654,8 +690,9 @@ static int _dump_pci_devices(= struct pci_=0A =0A list_for_each_entry ( pdev, &pseg->alldevs_list, = alldevs_list )=0A {=0A- printk("%02x:%02x.%x - dom %-3d - MSIs = < ",=0A- pdev->bus, PCI_SLOT(pdev->devfn), PCI_FUNC(pdev->dev= fn),=0A+ printk("%04x:%02x:%02x.%u - dom %-3d - MSIs < ",=0A+ = pseg->nr, pdev->bus,=0A+ PCI_SLOT(pdev->devfn), = PCI_FUNC(pdev->devfn),=0A pdev->domain ? pdev->domain->domai= n_id : -1);=0A list_for_each_entry ( msi, &pdev->msi_list, list = )=0A printk("%d ", msi->irq);=0A--- 2011-09-20.orig/xen/driv= ers/passthrough/vtd/dmar.c 2011-08-25 15:06:43.000000000 +0200=0A+++ = 2011-09-20/xen/drivers/passthrough/vtd/dmar.c 2011-08-25 15:12:12.0000000= 00 +0200=0A@@ -457,11 +457,11 @@ acpi_parse_one_drhd(struct acpi_dmar_ent= =0A d =3D PCI_SLOT(dmaru->scope.devices[i]);=0A f = =3D PCI_FUNC(dmaru->scope.devices[i]);=0A =0A- if ( pci_device_d= etect(b, d, f) =3D=3D 0 )=0A+ if ( pci_device_detect(drhd->segme= nt, b, d, f) =3D=3D 0 )=0A {=0A dprintk(XENLOG_= WARNING VTDPREFIX,=0A- " Non-existent device (%x:%x.%x)= is reported "=0A- "in this DRHD's scope!\n", b, d, = f);=0A+ " Non-existent device (%04x:%02x:%02x.%u) = is reported"=0A+ " in this DRHD's scope!\n", = drhd->segment, b, d, f);=0A invalid_cnt++;=0A = }=0A }=0A@@ -556,12 +556,13 @@ acpi_parse_one_rmrr(struct = acpi_dmar_ent=0A d =3D PCI_SLOT(rmrru->scope.devices[i]);=0A = f =3D PCI_FUNC(rmrru->scope.devices[i]);=0A =0A- if ( = pci_device_detect(b, d, f) =3D=3D 0 )=0A+ if ( pci_device_detect= (rmrr->segment, b, d, f) =3D=3D 0 )=0A {=0A = dprintk(XENLOG_WARNING VTDPREFIX,=0A- " Non-existent = device (%x:%x.%x) is reported "=0A- "in RMRR (%"PRIx64",= %"PRIx64")'s scope!\n",=0A- b, d, f, rmrru->base_addres= s, rmrru->end_address);=0A+ " Non-existent device = (%04x:%02x:%02x.%u) is reported"=0A+ " in RMRR = (%"PRIx64", %"PRIx64")'s scope!\n",=0A+ rmrr->segmen= t, b, d, f,=0A+ rmrru->base_address, rmrru->end_addr= ess);=0A ignore =3D 1;=0A }=0A = else=0A--- 2011-09-20.orig/xen/drivers/passthrough/vtd/intremap.c = 2011-08-19 17:08:35.000000000 +0200=0A+++ 2011-09-20/xen/drivers/passthroug= h/vtd/intremap.c 2011-08-25 15:12:12.000000000 +0200=0A@@ -448,15 = +448,17 @@ void io_apic_write_remap_rte(=0A static void set_msi_source_id(s= truct pci_dev *pdev, struct iremap_entry *ire)=0A {=0A int type;=0A+ = u16 seg;=0A u8 bus, devfn, secbus;=0A int ret;=0A =0A if ( = !pdev || !ire )=0A return;=0A =0A+ seg =3D pdev->seg;=0A = bus =3D pdev->bus;=0A devfn =3D pdev->devfn;=0A- type =3D pdev_type(= bus, devfn);=0A+ type =3D pdev_type(seg, bus, devfn);=0A switch ( = type )=0A {=0A case DEV_TYPE_PCIe_BRIDGE:=0A@@ -469,7 +471,7 @@ = static void set_msi_source_id(struct pci=0A break;=0A =0A case = DEV_TYPE_PCI:=0A- ret =3D find_upstream_bridge(&bus, &devfn, = &secbus);=0A+ ret =3D find_upstream_bridge(seg, &bus, &devfn, = &secbus);=0A if ( ret =3D=3D 0 ) /* integrated PCI device */=0A = {=0A set_ire_sid(ire, SVT_VERIFY_SID_SQ, SQ_ALL_16,=0A@@ = -477,19 +479,20 @@ static void set_msi_source_id(struct pci=0A = }=0A else if ( ret =3D=3D 1 ) /* find upstream bridge */=0A = {=0A- if ( pdev_type(bus, devfn) =3D=3D DEV_TYPE_PCIe2PCI_BRIDG= E )=0A+ if ( pdev_type(seg, bus, devfn) =3D=3D DEV_TYPE_PCIe2PCI= _BRIDGE )=0A set_ire_sid(ire, SVT_VERIFY_BUS, SQ_ALL_16,=0A= (bus << 8) | pdev->bus);=0A- else = if ( pdev_type(bus, devfn) =3D=3D DEV_TYPE_LEGACY_PCI_BRIDGE )=0A+ = else if ( pdev_type(seg, bus, devfn) =3D=3D DEV_TYPE_LEGACY_PCI_BRIDGE = )=0A set_ire_sid(ire, SVT_VERIFY_BUS, SQ_ALL_16,=0A = PCI_BDF2(bus, devfn));=0A }=0A = break;=0A =0A default:=0A- dprintk(XENLOG_WARNING VTDPREFIX, = "d%d: unknown(%u): bdf =3D %x:%x.%x\n",=0A+ dprintk(XENLOG_WARNING = VTDPREFIX,=0A+ "d%d: unknown(%u): %04x:%02x:%02x.%u\n",=0A = pdev->domain->domain_id, type,=0A- bus, = PCI_SLOT(devfn), PCI_FUNC(devfn));=0A+ seg, bus, PCI_SLOT(de= vfn), PCI_FUNC(devfn));=0A break;=0A }=0A }=0A--- 2011-09-20.ori= g/xen/drivers/passthrough/vtd/iommu.c 2011-09-20 16:06:24.000000000 = +0200=0A+++ 2011-09-20/xen/drivers/passthrough/vtd/iommu.c 2011-09-20 = 16:06:42.000000000 +0200=0A@@ -50,7 +50,7 @@ bool_t __read_mostly = untrusted_msi;=0A =0A int nr_iommus;=0A =0A-static void setup_dom0_devices(= struct domain *d);=0A+static void setup_dom0_device(struct pci_dev *);=0A = static void setup_dom0_rmrr(struct domain *d);=0A =0A static int domain_iom= mu_domid(struct domain *d,=0A@@ -1240,7 +1240,7 @@ static void __init = intel_iommu_dom0_init=0A iommu_set_dom0_mapping(d);=0A }=0A = =0A- setup_dom0_devices(d);=0A+ setup_dom0_pci_devices(d, setup_dom0_= device);=0A setup_dom0_rmrr(d);=0A =0A iommu_flush_all();=0A@@ = -1408,7 +1408,7 @@ static int domain_context_mapping(=0A =0A ASSERT(spi= n_is_locked(&pcidevs_lock));=0A =0A- type =3D pdev_type(bus, devfn);=0A+= type =3D pdev_type(seg, bus, devfn);=0A switch ( type )=0A = {=0A case DEV_TYPE_PCIe_BRIDGE:=0A@@ -1437,7 +1437,7 @@ static int = domain_context_mapping(=0A if ( ret )=0A break;=0A = =0A- if ( find_upstream_bridge(&bus, &devfn, &secbus) < 1 )=0A+ = if ( find_upstream_bridge(seg, &bus, &devfn, &secbus) < 1 )=0A = break;=0A =0A ret =3D domain_context_mapping_one(domain, = drhd->iommu, bus, devfn);=0A@@ -1447,7 +1447,7 @@ static int domain_context= _mapping(=0A * requester-id. It may originate from devfn=3D0 on = the secondary bus=0A * behind the bridge. Map that id as well if = we didn't already.=0A */=0A- if ( !ret && pdev_type(bus, = devfn) =3D=3D DEV_TYPE_PCIe2PCI_BRIDGE &&=0A+ if ( !ret && = pdev_type(seg, bus, devfn) =3D=3D DEV_TYPE_PCIe2PCI_BRIDGE &&=0A = (secbus !=3D pdev->bus || pdev->devfn !=3D 0) )=0A ret =3D = domain_context_mapping_one(domain, drhd->iommu, secbus, 0);=0A =0A@@ = -1539,7 +1539,7 @@ static int domain_context_unmap(=0A return = -ENODEV;=0A iommu =3D drhd->iommu;=0A =0A- type =3D pdev_type(bus, = devfn);=0A+ type =3D pdev_type(seg, bus, devfn);=0A switch ( type = )=0A {=0A case DEV_TYPE_PCIe_BRIDGE:=0A@@ -1568,11 +1568,11 @@ = static int domain_context_unmap(=0A =0A tmp_bus =3D bus;=0A = tmp_devfn =3D devfn;=0A- if ( find_upstream_bridge(&tmp_bus, = &tmp_devfn, &secbus) < 1 )=0A+ if ( find_upstream_bridge(seg, = &tmp_bus, &tmp_devfn, &secbus) < 1 )=0A break;=0A =0A = /* PCIe to PCI/PCIx bridge */=0A- if ( pdev_type(tmp_bus, tmp_devfn)= =3D=3D DEV_TYPE_PCIe2PCI_BRIDGE )=0A+ if ( pdev_type(seg, tmp_bus, = tmp_devfn) =3D=3D DEV_TYPE_PCIe2PCI_BRIDGE )=0A {=0A = ret =3D domain_context_unmap_one(domain, iommu, tmp_bus, tmp_devfn);=0A = if ( ret )=0A@@ -1945,28 +1945,11 @@ static int intel_iommu_remove= _device(str=0A pdev->devfn);=0A }=0A = =0A-static void __init setup_dom0_devices(struct domain *d)=0A+static void = __init setup_dom0_device(struct pci_dev *pdev)=0A {=0A- struct pci_dev = *pdev;=0A- int bus, devfn;=0A-=0A- spin_lock(&pcidevs_lock);=0A- = for ( bus =3D 0; bus < 256; bus++ )=0A- {=0A- for ( devfn =3D 0; = devfn < 256; devfn++ )=0A- {=0A- pdev =3D pci_get_pdev(0,= bus, devfn);=0A- if ( !pdev )=0A- continue;=0A-= =0A- pdev->domain =3D d;=0A- list_add(&pdev->domain_l= ist, &d->arch.pdev_list);=0A- domain_context_mapping(d, = pdev->seg, pdev->bus, pdev->devfn);=0A- pci_enable_acs(pdev);=0A= - pci_vtd_quirk(pdev);=0A- }=0A- }=0A- spin_unlock(= &pcidevs_lock);=0A+ domain_context_mapping(pdev->domain, pdev->seg, = pdev->bus, pdev->devfn);=0A+ pci_enable_acs(pdev);=0A+ pci_vtd_quirk(= pdev);=0A }=0A =0A void clear_fault_bits(struct iommu *iommu)=0A@@ -2240,7 = +2223,7 @@ done:=0A static int intel_iommu_group_id(u16 seg, u8 bus, u8 = devfn)=0A {=0A u8 secbus;=0A- if ( find_upstream_bridge(&bus, = &devfn, &secbus) < 0 )=0A+ if ( find_upstream_bridge(seg, &bus, &devfn, = &secbus) < 0 )=0A return -1;=0A else=0A return = PCI_BDF2(bus, devfn);=0A--- 2011-09-20.orig/xen/include/xen/pci.h = 2011-08-25 15:06:35.000000000 +0200=0A+++ 2011-09-20/xen/include/xen/pci.h = 2011-08-25 15:12:12.000000000 +0200=0A@@ -82,13 +82,15 @@ enum {=0A = DEV_TYPE_PCI,=0A };=0A =0A-int pci_device_detect(u8 bus, u8 dev, u8 = func);=0A+int pci_device_detect(u16 seg, u8 bus, u8 dev, u8 func);=0A int = scan_pci_devices(void);=0A-int pdev_type(u8 bus, u8 devfn);=0A-int = find_upstream_bridge(u8 *bus, u8 *devfn, u8 *secbus);=0A-struct pci_dev = *pci_lock_pdev(int bus, int devfn);=0A-struct pci_dev *pci_lock_domain_pdev= (struct domain *d, int bus, int devfn);=0A+int pdev_type(u16 seg, u8 bus, = u8 devfn);=0A+int find_upstream_bridge(u16 seg, u8 *bus, u8 *devfn, u8 = *secbus);=0A+struct pci_dev *pci_lock_pdev(int seg, int bus, int devfn);=0A= +struct pci_dev *pci_lock_domain_pdev(=0A+ struct domain *, int seg, = int bus, int devfn);=0A =0A+void setup_dom0_pci_devices(struct domain *, = void (*)(struct pci_dev *));=0A void pci_release_devices(struct domain = *d);=0A int pci_add_segment(u16 seg);=0A int pci_add_device(u16 seg, u8 = bus, u8 devfn, const struct pci_dev_info *);=0A --=__PartFBD4C00A.0__= Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel --=__PartFBD4C00A.0__=-- From xen-devel-bounces@lists.xensource.com Tue Sep 20 08:25:14 2011 Return-path: <xen-devel-bounces@lists.xensource.com> Envelope-to: www-data@lists.xensource.com Delivery-date: Tue, 20 Sep 2011 08:25:14 -0700 Received: from localhost ([127.0.0.1] helo=lists.colo.xensource.com) by lists.xensource.com with esmtp (Exim 4.43) id 1R62CA-0002B6-K4; Tue, 20 Sep 2011 08:25:14 -0700 Received: from mail21.messagelabs.com ([85.158.143.35]) by lists.xensource.com with esmtp (Exim 4.43) id 1R627B-0000A0-Qm for xen-devel@lists.xensource.com; Tue, 20 Sep 2011 08:20:07 -0700 X-Env-Sender: JBeulich@suse.com X-Msg-Ref: server-4.tower-21.messagelabs.com!1316531966!60950695!1 X-Originating-IP: [130.57.49.28] X-StarScan-Version: 6.4.1; banners=-,-,- X-VirusChecked: Checked Received: (qmail 4507 invoked from network); 20 Sep 2011 15:19:27 -0000 Received: from nat28.tlf.novell.com (HELO nat28.tlf.novell.com) (130.57.49.28) by server-4.tower-21.messagelabs.com with DHE-RSA-AES256-SHA encrypted SMTP; 20 Sep 2011 15:19:27 -0000 Received: from EMEA1-MTA by nat28.tlf.novell.com with Novell_GroupWise; Tue, 20 Sep 2011 16:20:01 +0100 Message-Id: <4E78CB5B0200007800056D55@nat28.tlf.novell.com> X-Mailer: Novell GroupWise Internet Agent 8.0.1 Date: Tue, 20 Sep 2011 16:20:27 +0100 From: "Jan Beulich" <JBeulich@suse.com> To: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com> Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="=__PartDAF5E12B.0__=" Subject: [Xen-devel] [PATCH 7/7] PCI multi-seg: config space accessor adjustments X-BeenThere: xen-devel@lists.xensource.com X-Mailman-Version: 2.1.5 Precedence: list List-Id: Xen developer discussion <xen-devel.lists.xensource.com> List-Unsubscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe> List-Post: <mailto:xen-devel@lists.xensource.com> List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help> List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=subscribe> Sender: xen-devel-bounces@lists.xensource.com Errors-To: xen-devel-bounces@lists.xensource.com This is a MIME message. If you are reading this text, you may want to consider changing to a mail reader or gateway that understands how to properly handle MIME multipart messages. --=__PartDAF5E12B.0__= Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: quoted-printable Content-Disposition: inline Signed-off-by: Jan Beulich <jbeulich@suse.com> --- 2011-09-20.orig/xen/arch/x86/cpu/amd.c 2011-08-16 08:15:46.0000000= 00 +0200 +++ 2011-09-20/xen/arch/x86/cpu/amd.c 2011-08-25 15:13:05.000000000 = +0200 @@ -262,15 +262,15 @@ static void disable_c1_ramping(void)=20 int node, nr_nodes; =20 /* Read the number of nodes from the first Northbridge. */ - nr_nodes =3D ((pci_conf_read32(0, 0x18, 0x0, 0x60)>>4)&0x07)+1; + nr_nodes =3D ((pci_conf_read32(0, 0, 0x18, 0x0, 0x60)>>4)&0x07)+1; for (node =3D 0; node < nr_nodes; node++) { /* PMM7: bus=3D0, dev=3D0x18+node, function=3D0x3, = register=3D0x87. */ - pmm7 =3D pci_conf_read8(0, 0x18+node, 0x3, 0x87); + pmm7 =3D pci_conf_read8(0, 0, 0x18+node, 0x3, 0x87); /* Invalid read means we've updated every Northbridge. */ if (pmm7 =3D=3D 0xFF) break; pmm7 &=3D 0xFC; /* clear pmm7[1:0] */ - pci_conf_write8(0, 0x18+node, 0x3, 0x87, pmm7); + pci_conf_write8(0, 0, 0x18+node, 0x3, 0x87, pmm7); printk ("AMD: Disabling C1 Clock Ramping Node #%x\n", = node); } } --- 2011-09-20.orig/xen/arch/x86/dmi_scan.c 2011-09-05 09:12:30.0000000= 00 +0200 +++ 2011-09-20/xen/arch/x86/dmi_scan.c 2011-08-25 15:36:55.000000000 = +0200 @@ -284,15 +284,15 @@ static int __init ich10_bios_quirk(struc { u32 port, smictl; =20 - if ( pci_conf_read16(0, 0x1f, 0, PCI_VENDOR_ID) !=3D 0x8086 ) + if ( pci_conf_read16(0, 0, 0x1f, 0, PCI_VENDOR_ID) !=3D 0x8086 ) return 0; =20 - switch ( pci_conf_read16(0, 0x1f, 0, PCI_DEVICE_ID) ) { + switch ( pci_conf_read16(0, 0, 0x1f, 0, PCI_DEVICE_ID) ) { case 0x3a14: case 0x3a16: case 0x3a18: case 0x3a1a: - port =3D (pci_conf_read16(0, 0x1f, 0, 0x40) & 0xff80) + 0x30; + port =3D (pci_conf_read16(0, 0, 0x1f, 0, 0x40) & 0xff80) + 0x30; smictl =3D inl(port); /* turn off LEGACY_USB{,2}_EN if enabled */ if ( smictl & 0x20008 ) --- 2011-09-20.orig/xen/arch/x86/msi.c 2011-08-25 15:06:35.000000000 = +0200 +++ 2011-09-20/xen/arch/x86/msi.c 2011-08-25 15:13:05.000000000 = +0200 @@ -166,23 +166,25 @@ static void read_msi_msg(struct msi_desc { struct pci_dev *dev =3D entry->dev; int pos =3D entry->msi_attrib.pos; - u16 data; + u16 data, seg =3D dev->seg; u8 bus =3D dev->bus; u8 slot =3D PCI_SLOT(dev->devfn); u8 func =3D PCI_FUNC(dev->devfn); =20 - msg->address_lo =3D pci_conf_read32(bus, slot, func, + msg->address_lo =3D pci_conf_read32(seg, bus, slot, func, msi_lower_address_reg(pos)); if ( entry->msi_attrib.is_64 ) { - msg->address_hi =3D pci_conf_read32(bus, slot, func, + msg->address_hi =3D pci_conf_read32(seg, bus, slot, func, msi_upper_address_reg(pos));= - data =3D pci_conf_read16(bus, slot, func, msi_data_reg(pos, = 1)); + data =3D pci_conf_read16(seg, bus, slot, func, + msi_data_reg(pos, 1)); } else { msg->address_hi =3D 0; - data =3D pci_conf_read16(bus, slot, func, msi_data_reg(pos, = 0)); + data =3D pci_conf_read16(seg, bus, slot, func, + msi_data_reg(pos, 0)); } msg->data =3D data; break; @@ -231,21 +233,22 @@ static void write_msi_msg(struct msi_des { struct pci_dev *dev =3D entry->dev; int pos =3D entry->msi_attrib.pos; + u16 seg =3D dev->seg; u8 bus =3D dev->bus; u8 slot =3D PCI_SLOT(dev->devfn); u8 func =3D PCI_FUNC(dev->devfn); =20 - pci_conf_write32(bus, slot, func, msi_lower_address_reg(pos), + pci_conf_write32(seg, bus, slot, func, msi_lower_address_reg(pos),= msg->address_lo); if ( entry->msi_attrib.is_64 ) { - pci_conf_write32(bus, slot, func, msi_upper_address_reg(pos), + pci_conf_write32(seg, bus, slot, func, msi_upper_address_reg(p= os), msg->address_hi); - pci_conf_write16(bus, slot, func, msi_data_reg(pos, 1), + pci_conf_write16(seg, bus, slot, func, msi_data_reg(pos, 1), msg->data); } else - pci_conf_write16(bus, slot, func, msi_data_reg(pos, 0), + pci_conf_write16(seg, bus, slot, func, msi_data_reg(pos, 0), msg->data); break; } @@ -295,38 +298,38 @@ void set_msi_affinity(unsigned int irq,=20 static void msi_set_enable(struct pci_dev *dev, int enable) { int pos; - u16 control; + u16 control, seg =3D dev->seg; u8 bus =3D dev->bus; u8 slot =3D PCI_SLOT(dev->devfn); u8 func =3D PCI_FUNC(dev->devfn); =20 - pos =3D pci_find_cap_offset(bus, slot, func, PCI_CAP_ID_MSI); + pos =3D pci_find_cap_offset(seg, bus, slot, func, PCI_CAP_ID_MSI); if ( pos ) { - control =3D pci_conf_read16(bus, slot, func, pos + PCI_MSI_FLAGS);= + control =3D pci_conf_read16(seg, bus, slot, func, pos + PCI_MSI_FL= AGS); control &=3D ~PCI_MSI_FLAGS_ENABLE; if ( enable ) control |=3D PCI_MSI_FLAGS_ENABLE; - pci_conf_write16(bus, slot, func, pos + PCI_MSI_FLAGS, control); + pci_conf_write16(seg, bus, slot, func, pos + PCI_MSI_FLAGS, = control); } } =20 static void msix_set_enable(struct pci_dev *dev, int enable) { int pos; - u16 control; + u16 control, seg =3D dev->seg; u8 bus =3D dev->bus; u8 slot =3D PCI_SLOT(dev->devfn); u8 func =3D PCI_FUNC(dev->devfn); =20 - pos =3D pci_find_cap_offset(bus, slot, func, PCI_CAP_ID_MSIX); + pos =3D pci_find_cap_offset(seg, bus, slot, func, PCI_CAP_ID_MSIX); if ( pos ) { - control =3D pci_conf_read16(bus, slot, func, pos + PCI_MSIX_FLAGS)= ; + control =3D pci_conf_read16(seg, bus, slot, func, pos + PCI_MSIX_F= LAGS); control &=3D ~PCI_MSIX_FLAGS_ENABLE; if ( enable ) control |=3D PCI_MSIX_FLAGS_ENABLE; - pci_conf_write16(bus, slot, func, pos + PCI_MSIX_FLAGS, control); + pci_conf_write16(seg, bus, slot, func, pos + PCI_MSIX_FLAGS, = control); } } =20 @@ -348,15 +351,16 @@ static void msi_set_mask_bit(unsigned in if (entry->msi_attrib.maskbit) { int pos; u32 mask_bits; + u16 seg =3D entry->dev->seg; u8 bus =3D entry->dev->bus; u8 slot =3D PCI_SLOT(entry->dev->devfn); u8 func =3D PCI_FUNC(entry->dev->devfn); =20 pos =3D (long)entry->mask_base; - mask_bits =3D pci_conf_read32(bus, slot, func, pos); + mask_bits =3D pci_conf_read32(seg, bus, slot, func, pos); mask_bits &=3D ~(1); mask_bits |=3D flag; - pci_conf_write32(bus, slot, func, pos, mask_bits); + pci_conf_write32(seg, bus, slot, func, pos, mask_bits); } break; case PCI_CAP_ID_MSIX: @@ -379,7 +383,8 @@ static int msi_get_mask_bit(const struct case PCI_CAP_ID_MSI: if (!entry->dev || !entry->msi_attrib.maskbit) break; - return pci_conf_read32(entry->dev->bus, PCI_SLOT(entry->dev->devfn= ), + return pci_conf_read32(entry->dev->seg, entry->dev->bus, + PCI_SLOT(entry->dev->devfn), PCI_FUNC(entry->dev->devfn), (unsigned long)entry->mask_base) & 1; case PCI_CAP_ID_MSIX: @@ -473,14 +478,14 @@ static int msi_capability_init(struct pc { struct msi_desc *entry; int pos; - u16 control; + u16 control, seg =3D dev->seg; u8 bus =3D dev->bus; u8 slot =3D PCI_SLOT(dev->devfn); u8 func =3D PCI_FUNC(dev->devfn); =20 ASSERT(spin_is_locked(&pcidevs_lock)); - pos =3D pci_find_cap_offset(bus, slot, func, PCI_CAP_ID_MSI); - control =3D pci_conf_read16(bus, slot, func, msi_control_reg(pos)); + pos =3D pci_find_cap_offset(seg, bus, slot, func, PCI_CAP_ID_MSI); + control =3D pci_conf_read16(seg, bus, slot, func, msi_control_reg(pos)= ); /* MSI Entry Initialization */ msi_set_enable(dev, 0); /* Ensure msi is disabled as I set it up */ =20 @@ -503,12 +508,12 @@ static int msi_capability_init(struct pc { unsigned int maskbits, temp; /* All MSIs are unmasked by default, Mask them all */ - maskbits =3D pci_conf_read32(bus, slot, func, + maskbits =3D pci_conf_read32(seg, bus, slot, func, msi_mask_bits_reg(pos, is_64bit_address= (control))); temp =3D (1 << multi_msi_capable(control)); temp =3D ((temp - 1) & ~temp); maskbits |=3D temp; - pci_conf_write32(bus, slot, func, + pci_conf_write32(seg, bus, slot, func, msi_mask_bits_reg(pos, is_64bit_address(control))= , maskbits); } @@ -516,27 +521,28 @@ static int msi_capability_init(struct pc =20 *desc =3D entry; /* Restore the original MSI enabled bits */ - pci_conf_write16(bus, slot, func, msi_control_reg(pos), control); + pci_conf_write16(seg, bus, slot, func, msi_control_reg(pos), = control); =20 return 0; } =20 -static u64 read_pci_mem_bar(u8 bus, u8 slot, u8 func, u8 bir, int vf) +static u64 read_pci_mem_bar(u16 seg, u8 bus, u8 slot, u8 func, u8 bir, = int vf) { u8 limit; u32 addr, base =3D PCI_BASE_ADDRESS_0, disp =3D 0; =20 if ( vf >=3D 0 ) { - struct pci_dev *pdev =3D pci_get_pdev(0, bus, PCI_DEVFN(slot, = func)); - unsigned int pos =3D pci_find_ext_capability(0, bus, + struct pci_dev *pdev =3D pci_get_pdev(seg, bus, PCI_DEVFN(slot, = func)); + unsigned int pos =3D pci_find_ext_capability(seg, bus, PCI_DEVFN(slot, func), PCI_EXT_CAP_ID_SRIOV); - u16 ctrl =3D pci_conf_read16(bus, slot, func, pos + PCI_SRIOV_CTRL= ); - u16 num_vf =3D pci_conf_read16(bus, slot, func, pos + PCI_SRIOV_NU= M_VF); - u16 offset =3D pci_conf_read16(bus, slot, func, + u16 ctrl =3D pci_conf_read16(seg, bus, slot, func, pos + = PCI_SRIOV_CTRL); + u16 num_vf =3D pci_conf_read16(seg, bus, slot, func, + pos + PCI_SRIOV_NUM_VF); + u16 offset =3D pci_conf_read16(seg, bus, slot, func, pos + PCI_SRIOV_VF_OFFSET); - u16 stride =3D pci_conf_read16(bus, slot, func, + u16 stride =3D pci_conf_read16(seg, bus, slot, func, pos + PCI_SRIOV_VF_STRIDE); =20 if ( !pdev || !pos || @@ -562,7 +568,8 @@ static u64 read_pci_mem_bar(u8 bus, u8 s disp =3D vf * pdev->vf_rlen[bir]; limit =3D PCI_SRIOV_NUM_BARS; } - else switch ( pci_conf_read8(bus, slot, func, PCI_HEADER_TYPE) & 0x7f = ) + else switch ( pci_conf_read8(seg, bus, slot, func, + PCI_HEADER_TYPE) & 0x7f ) { case PCI_HEADER_TYPE_NORMAL: limit =3D 6; @@ -579,7 +586,7 @@ static u64 read_pci_mem_bar(u8 bus, u8 s =20 if ( bir >=3D limit ) return 0; - addr =3D pci_conf_read32(bus, slot, func, base + bir * 4); + addr =3D pci_conf_read32(seg, bus, slot, func, base + bir * 4); if ( (addr & PCI_BASE_ADDRESS_SPACE) =3D=3D PCI_BASE_ADDRESS_SPACE_IO = ) return 0; if ( (addr & PCI_BASE_ADDRESS_MEM_TYPE_MASK) =3D=3D PCI_BASE_ADDRESS_M= EM_TYPE_64 ) @@ -588,7 +595,8 @@ static u64 read_pci_mem_bar(u8 bus, u8 s if ( ++bir >=3D limit ) return 0; return addr + disp + - ((u64)pci_conf_read32(bus, slot, func, base + bir * 4) << = 32); + ((u64)pci_conf_read32(seg, bus, slot, func, + base + bir * 4) << 32); } return (addr & PCI_BASE_ADDRESS_MEM_MASK) + disp; } @@ -616,6 +624,7 @@ static int msix_capability_init(struct p u8 bir; void __iomem *base; int idx; + u16 seg =3D dev->seg; u8 bus =3D dev->bus; u8 slot =3D PCI_SLOT(dev->devfn); u8 func =3D PCI_FUNC(dev->devfn); @@ -623,8 +632,8 @@ static int msix_capability_init(struct p ASSERT(spin_is_locked(&pcidevs_lock)); ASSERT(desc); =20 - pos =3D pci_find_cap_offset(bus, slot, func, PCI_CAP_ID_MSIX); - control =3D pci_conf_read16(bus, slot, func, msix_control_reg(pos)); + pos =3D pci_find_cap_offset(seg, bus, slot, func, PCI_CAP_ID_MSIX); + control =3D pci_conf_read16(seg, bus, slot, func, msix_control_reg(pos= )); msix_set_enable(dev, 0);/* Ensure msix is disabled as I set it up */ =20 /* MSI-X Table Initialization */ @@ -633,7 +642,8 @@ static int msix_capability_init(struct p return -ENOMEM; =20 /* Request & Map MSI-X table region */ - table_offset =3D pci_conf_read32(bus, slot, func, msix_table_offset_re= g(pos)); + table_offset =3D pci_conf_read32(seg, bus, slot, func, + msix_table_offset_reg(pos)); bir =3D (u8)(table_offset & PCI_MSIX_BIRMASK); table_offset &=3D ~PCI_MSIX_BIRMASK; entry_offset =3D msi->entry_nr * PCI_MSIX_ENTRY_SIZE; @@ -685,7 +695,7 @@ static int msix_capability_init(struct p =20 ASSERT(!dev->msix_used_entries); WARN_ON(msi->table_base !=3D - read_pci_mem_bar(pbus, pslot, pfunc, bir, vf)); + read_pci_mem_bar(seg, pbus, pslot, pfunc, bir, vf)); =20 dev->msix_nr_entries =3D nr_entries; dev->msix_table.first =3D PFN_DOWN(table_paddr); @@ -694,10 +704,10 @@ static int msix_capability_init(struct p WARN_ON(rangeset_overlaps_range(mmio_ro_ranges, dev->msix_table.fi= rst, dev->msix_table.last)); =20 - pba_offset =3D pci_conf_read32(bus, slot, func, + pba_offset =3D pci_conf_read32(seg, bus, slot, func, msix_pba_offset_reg(pos)); bir =3D (u8)(pba_offset & PCI_MSIX_BIRMASK); - pba_paddr =3D read_pci_mem_bar(pbus, pslot, pfunc, bir, vf); + pba_paddr =3D read_pci_mem_bar(seg, pbus, pslot, pfunc, bir, vf); WARN_ON(!pba_paddr); pba_paddr +=3D pba_offset & ~PCI_MSIX_BIRMASK; =20 @@ -744,7 +754,7 @@ static int msix_capability_init(struct p =20 *desc =3D entry; /* Restore MSI-X enabled bits */ - pci_conf_write16(bus, slot, func, msix_control_reg(pos), control); + pci_conf_write16(seg, bus, slot, func, msix_control_reg(pos), = control); =20 return 0; } @@ -835,8 +845,9 @@ static int __pci_enable_msix(struct msi_ if ( !pdev ) return -ENODEV; =20 - pos =3D pci_find_cap_offset(msi->bus, slot, func, PCI_CAP_ID_MSIX); - control =3D pci_conf_read16(msi->bus, slot, func, msix_control_reg(pos= )); + pos =3D pci_find_cap_offset(msi->seg, msi->bus, slot, func, PCI_CAP_ID= _MSIX); + control =3D pci_conf_read16(msi->seg, msi->bus, slot, func, + msix_control_reg(pos)); nr_entries =3D multi_msix_capable(control); if (msi->entry_nr >=3D nr_entries) return -EINVAL; @@ -870,23 +881,24 @@ static void __pci_disable_msix(struct ms { struct pci_dev *dev; int pos; - u16 control; + u16 control, seg; u8 bus, slot, func; =20 dev =3D entry->dev; + seg =3D dev->seg; bus =3D dev->bus; slot =3D PCI_SLOT(dev->devfn); func =3D PCI_FUNC(dev->devfn); =20 - pos =3D pci_find_cap_offset(bus, slot, func, PCI_CAP_ID_MSIX); - control =3D pci_conf_read16(bus, slot, func, msix_control_reg(pos)); + pos =3D pci_find_cap_offset(seg, bus, slot, func, PCI_CAP_ID_MSIX); + control =3D pci_conf_read16(seg, bus, slot, func, msix_control_reg(pos= )); msix_set_enable(dev, 0); =20 BUG_ON(list_empty(&dev->msi_list)); =20 writel(1, entry->mask_base + PCI_MSIX_ENTRY_VECTOR_CTRL_OFFSET); =20 - pci_conf_write16(bus, slot, func, msix_control_reg(pos), control); + pci_conf_write16(seg, bus, slot, func, msix_control_reg(pos), = control); =20 if ( !--dev->msix_used_entries ) { @@ -995,7 +1007,7 @@ int pci_restore_msi_state(struct pci_dev unsigned int pci_msix_get_table_len(struct pci_dev *pdev) { int pos; - u16 control; + u16 control, seg =3D pdev->seg; u8 bus, slot, func; unsigned int len; =20 @@ -1003,11 +1015,11 @@ unsigned int pci_msix_get_table_len(stru slot =3D PCI_SLOT(pdev->devfn); func =3D PCI_FUNC(pdev->devfn); =20 - pos =3D pci_find_cap_offset(bus, slot, func, PCI_CAP_ID_MSIX); + pos =3D pci_find_cap_offset(seg, bus, slot, func, PCI_CAP_ID_MSIX); if ( !pos ) return 0; =20 - control =3D pci_conf_read16(bus, slot, func, msix_control_reg(pos)); + control =3D pci_conf_read16(seg, bus, slot, func, msix_control_reg(pos= )); len =3D msix_table_size(control) * PCI_MSIX_ENTRY_SIZE; =20 return len; --- 2011-09-20.orig/xen/arch/x86/oprofile/op_model_athlon.c 2011-06-16 = 09:21:02.000000000 +0200 +++ 2011-09-20/xen/arch/x86/oprofile/op_model_athlon.c 2011-08-25 = 15:13:05.000000000 +0200 @@ -470,7 +470,7 @@ static int __init init_ibs_nmi(void) for (bus =3D 0; bus < 256; bus++) { for (dev =3D 0; dev < 32; dev++) { for (func =3D 0; func < 8; func++) { - id =3D pci_conf_read32(bus, dev, func, = PCI_VENDOR_ID); + id =3D pci_conf_read32(0, bus, dev, func, = PCI_VENDOR_ID); =20 vendor_id =3D id & 0xffff; dev_id =3D (id >> 16) & 0xffff; @@ -478,10 +478,10 @@ static int __init init_ibs_nmi(void) if ((vendor_id =3D=3D PCI_VENDOR_ID_AMD) = && (dev_id =3D=3D PCI_DEVICE_ID_AMD_10= H_NB_MISC)) { =20 - pci_conf_write32(bus, dev, func, = IBSCTL, + pci_conf_write32(0, bus, dev, = func, IBSCTL, IBSCTL_LVTOFFSETVAL | = APIC_EILVT_LVTOFF_IBS); =20 - value =3D pci_conf_read32(bus, = dev, func, IBSCTL); + value =3D pci_conf_read32(0, bus, = dev, func, IBSCTL); =20 if (value !=3D (IBSCTL_LVTOFFSETVAL= | APIC_EILVT_LVTOFF_IBS)) { --- 2011-09-20.orig/xen/arch/x86/x86_32/pci.c 2011-08-08 08:29:50.0000000= 00 +0200 +++ 2011-09-20/xen/arch/x86/x86_32/pci.c 2011-08-25 15:13:05.0000000= 00 +0200 @@ -12,46 +12,61 @@ (0x80000000 | (bus << 16) | (dev << 11) | (func << 8) | (reg & ~3)) =20 uint8_t pci_conf_read8( - unsigned int bus, unsigned int dev, unsigned int func, unsigned int = reg) + unsigned int seg, unsigned int bus, unsigned int dev, unsigned int = func, + unsigned int reg) { + if ( seg ) + return ~0; BUG_ON((bus > 255) || (dev > 31) || (func > 7) || (reg > 255)); return pci_conf_read(PCI_CONF_ADDRESS(bus, dev, func, reg), reg & 3, = 1); } =20 uint16_t pci_conf_read16( - unsigned int bus, unsigned int dev, unsigned int func, unsigned int = reg) + unsigned int seg, unsigned int bus, unsigned int dev, unsigned int = func, + unsigned int reg) { + if ( seg ) + return ~0; BUG_ON((bus > 255) || (dev > 31) || (func > 7) || (reg > 255)); return pci_conf_read(PCI_CONF_ADDRESS(bus, dev, func, reg), reg & 2, = 2); } =20 uint32_t pci_conf_read32( - unsigned int bus, unsigned int dev, unsigned int func, unsigned int = reg) + unsigned int seg, unsigned int bus, unsigned int dev, unsigned int = func, + unsigned int reg) { + if ( seg ) + return ~0; BUG_ON((bus > 255) || (dev > 31) || (func > 7) || (reg > 255)); return pci_conf_read(PCI_CONF_ADDRESS(bus, dev, func, reg), 0, 4); } =20 void pci_conf_write8( - unsigned int bus, unsigned int dev, unsigned int func, unsigned int = reg, - uint8_t data) + unsigned int seg, unsigned int bus, unsigned int dev, unsigned int = func, + unsigned int reg, uint8_t data) { + if ( seg ) + return; BUG_ON((bus > 255) || (dev > 31) || (func > 7) || (reg > 255)); pci_conf_write(PCI_CONF_ADDRESS(bus, dev, func, reg), reg & 3, 1, = data); } =20 void pci_conf_write16( - unsigned int bus, unsigned int dev, unsigned int func, unsigned int = reg, - uint16_t data) + unsigned int seg, unsigned int bus, unsigned int dev, unsigned int = func, + unsigned int reg, uint16_t data) { + if ( seg ) + return; BUG_ON((bus > 255) || (dev > 31) || (func > 7) || (reg > 255)); pci_conf_write(PCI_CONF_ADDRESS(bus, dev, func, reg), reg & 2, 2, = data); } =20 void pci_conf_write32( - unsigned int bus, unsigned int dev, unsigned int func, unsigned int = reg, - uint32_t data) + unsigned int seg, unsigned int bus, unsigned int dev, unsigned int = func, + unsigned int reg, uint32_t data) { + if ( seg ) + return; BUG_ON((bus > 255) || (dev > 31) || (func > 7) || (reg > 255)); pci_conf_write(PCI_CONF_ADDRESS(bus, dev, func, reg), 0, 4, data); } --- 2011-09-20.orig/xen/arch/x86/x86_64/mmconf-fam10h.c 2011-08-08 = 08:29:50.000000000 +0200 +++ 2011-09-20/xen/arch/x86/x86_64/mmconf-fam10h.c 2011-08-25 = 15:13:05.000000000 +0200 @@ -51,7 +51,7 @@ static void __init get_fam10h_pci_mmconf =20 bus =3D pci_probes[i].bus; slot =3D pci_probes[i].slot; - id =3D pci_conf_read32(bus, slot, 0, PCI_VENDOR_ID); + id =3D pci_conf_read32(0, bus, slot, 0, PCI_VENDOR_ID); =20 vendor =3D id & 0xffff; device =3D (id>>16) & 0xffff; @@ -82,12 +82,12 @@ static void __init get_fam10h_pci_mmconf * above 4G */ for (hi_mmio_num =3D i =3D 0; i < 8; i++) { - val =3D pci_conf_read32(bus, slot, 1, 0x80 + (i << 3)); + val =3D pci_conf_read32(0, bus, slot, 1, 0x80 + (i << 3)); if (!(val & 3)) continue; =20 start =3D (val & 0xffffff00) << 8; /* 39:16 on 31:8*/ - val =3D pci_conf_read32(bus, slot, 1, 0x84 + (i << 3)); + val =3D pci_conf_read32(0, bus, slot, 1, 0x84 + (i << 3)); end =3D ((val & 0xffffff00) << 8) | 0xffff; /* 39:16 on = 31:8*/ =20 if (end < tom2) --- 2011-09-20.orig/xen/arch/x86/x86_64/mmconfig-shared.c 2011-08-25 = 15:06:23.000000000 +0200 +++ 2011-09-20/xen/arch/x86/x86_64/mmconfig-shared.c 2011-08-25 = 15:13:05.000000000 +0200 @@ -50,7 +50,7 @@ custom_param("mmcfg", parse_mmcfg); static const char __init *pci_mmcfg_e7520(void) { u32 win; - win =3D pci_conf_read16(0, 0, 0, 0xce); + win =3D pci_conf_read16(0, 0, 0, 0, 0xce); =20 win =3D win & 0xf000; if(win =3D=3D 0x0000 || win =3D=3D 0xf000) @@ -76,7 +76,7 @@ static const char __init *pci_mmcfg_inte =20 pci_mmcfg_config_num =3D 1; =20 - pciexbar =3D pci_conf_read32(0, 0, 0, 0x48); + pciexbar =3D pci_conf_read32(0, 0, 0, 0, 0x48); =20 /* Enable bit */ if (!(pciexbar & 1)) @@ -201,14 +201,14 @@ static const char __init *pci_mmcfg_nvid u32 l, extcfg; u16 vendor, device; =20 - l =3D pci_conf_read32(bus, 0, 0, 0); + l =3D pci_conf_read32(0, bus, 0, 0, 0); vendor =3D l & 0xffff; device =3D (l >> 16) & 0xffff; =20 if (PCI_VENDOR_ID_NVIDIA !=3D vendor || 0x0369 !=3D device) continue; =20 - extcfg =3D pci_conf_read32(bus, 0, 0, extcfg_regnum); + extcfg =3D pci_conf_read32(0, bus, 0, 0, extcfg_regnum); =20 if (extcfg & extcfg_enable_mask) i++; @@ -227,14 +227,14 @@ static const char __init *pci_mmcfg_nvid u16 vendor, device; int size_index; =20 - l =3D pci_conf_read32(bus, 0, 0, 0); + l =3D pci_conf_read32(0, bus, 0, 0, 0); vendor =3D l & 0xffff; device =3D (l >> 16) & 0xffff; =20 if (PCI_VENDOR_ID_NVIDIA !=3D vendor || 0x0369 !=3D device) continue; =20 - extcfg =3D pci_conf_read32(bus, 0, 0, extcfg_regnum); + extcfg =3D pci_conf_read32(0, bus, 0, 0, extcfg_regnum); =20 if (!(extcfg & extcfg_enable_mask)) continue; @@ -300,7 +300,7 @@ static int __init pci_mmcfg_check_hostbr for (i =3D 0; !name && i < ARRAY_SIZE(pci_mmcfg_probes); i++) { bus =3D pci_mmcfg_probes[i].bus; devfn =3D pci_mmcfg_probes[i].devfn; - l =3D pci_conf_read32(bus, PCI_SLOT(devfn), PCI_FUNC(devfn), 0); + l =3D pci_conf_read32(0, bus, PCI_SLOT(devfn), PCI_FUNC(devfn), = 0); vendor =3D l & 0xffff; device =3D (l >> 16) & 0xffff; =20 @@ -473,7 +473,7 @@ int pci_find_ext_capability(int seg, int int ttl =3D 480; /* 3840 bytes, minimum 8 bytes per capability */ int pos =3D 0x100; =20 - header =3D pci_conf_read32(bus, PCI_SLOT(devfn), PCI_FUNC(devfn), = pos); + header =3D pci_conf_read32(seg, bus, PCI_SLOT(devfn), PCI_FUNC(devfn),= pos); =20 /* * If we have no capabilities, this is indicated by cap ID, @@ -488,7 +488,7 @@ int pci_find_ext_capability(int seg, int pos =3D PCI_EXT_CAP_NEXT(header); if ( pos < 0x100 ) break; - header =3D pci_conf_read32(bus, PCI_SLOT(devfn), PCI_FUNC(devfn), = pos); + header =3D pci_conf_read32(seg, bus, PCI_SLOT(devfn), PCI_FUNC(dev= fn), pos); } return 0; } --- 2011-09-20.orig/xen/arch/x86/x86_64/pci.c 2009-10-07 13:31:36.0000000= 00 +0200 +++ 2011-09-20/xen/arch/x86/x86_64/pci.c 2011-08-25 15:13:05.0000000= 00 +0200 @@ -12,13 +12,14 @@ (0x80000000 | (bus << 16) | (dev << 11) | (func << 8) | (reg & ~3)) =20 uint8_t pci_conf_read8( - unsigned int bus, unsigned int dev, unsigned int func, unsigned int = reg) + unsigned int seg, unsigned int bus, unsigned int dev, unsigned int = func, + unsigned int reg) { u32 value; =20 - if ( reg > 255 ) + if ( seg || reg > 255 ) { - pci_mmcfg_read(0, bus, PCI_DEVFN(dev, func), reg, 1, &value); + pci_mmcfg_read(seg, bus, PCI_DEVFN(dev, func), reg, 1, &value); return value; } else @@ -29,13 +30,14 @@ uint8_t pci_conf_read8( } =20 uint16_t pci_conf_read16( - unsigned int bus, unsigned int dev, unsigned int func, unsigned int = reg) + unsigned int seg, unsigned int bus, unsigned int dev, unsigned int = func, + unsigned int reg) { u32 value; =20 - if ( reg > 255 ) + if ( seg || reg > 255 ) { - pci_mmcfg_read(0, bus, PCI_DEVFN(dev, func), reg, 2, &value); + pci_mmcfg_read(seg, bus, PCI_DEVFN(dev, func), reg, 2, &value); return value; } else @@ -46,13 +48,14 @@ uint16_t pci_conf_read16( } =20 uint32_t pci_conf_read32( - unsigned int bus, unsigned int dev, unsigned int func, unsigned int = reg) + unsigned int seg, unsigned int bus, unsigned int dev, unsigned int = func, + unsigned int reg) { u32 value; =20 - if ( reg > 255 ) + if ( seg || reg > 255 ) { - pci_mmcfg_read(0, bus, PCI_DEVFN(dev, func), reg, 4, &value); + pci_mmcfg_read(seg, bus, PCI_DEVFN(dev, func), reg, 4, &value); return value; } else @@ -63,11 +66,11 @@ uint32_t pci_conf_read32( } =20 void pci_conf_write8( - unsigned int bus, unsigned int dev, unsigned int func, unsigned int = reg, - uint8_t data) + unsigned int seg, unsigned int bus, unsigned int dev, unsigned int = func, + unsigned int reg, uint8_t data) { - if ( reg > 255 ) - pci_mmcfg_write(0, bus, PCI_DEVFN(dev, func), reg, 1, data); + if ( seg || reg > 255 ) + pci_mmcfg_write(seg, bus, PCI_DEVFN(dev, func), reg, 1, data); else { BUG_ON((bus > 255) || (dev > 31) || (func > 7)); @@ -76,11 +79,11 @@ void pci_conf_write8( } =20 void pci_conf_write16( - unsigned int bus, unsigned int dev, unsigned int func, unsigned int = reg, - uint16_t data) + unsigned int seg, unsigned int bus, unsigned int dev, unsigned int = func, + unsigned int reg, uint16_t data) { - if ( reg > 255 ) - pci_mmcfg_write(0, bus, PCI_DEVFN(dev, func), reg, 2, data); + if ( seg || reg > 255 ) + pci_mmcfg_write(seg, bus, PCI_DEVFN(dev, func), reg, 2, data); else { BUG_ON((bus > 255) || (dev > 31) || (func > 7)); @@ -89,11 +92,11 @@ void pci_conf_write16( } =20 void pci_conf_write32( - unsigned int bus, unsigned int dev, unsigned int func, unsigned int = reg, - uint32_t data) + unsigned int seg, unsigned int bus, unsigned int dev, unsigned int = func, + unsigned int reg, uint32_t data) { - if ( reg > 255 ) - pci_mmcfg_write(0, bus, PCI_DEVFN(dev, func), reg, 4, data); + if ( seg || reg > 255 ) + pci_mmcfg_write(seg, bus, PCI_DEVFN(dev, func), reg, 4, data); else { BUG_ON((bus > 255) || (dev > 31) || (func > 7)); --- 2011-09-20.orig/xen/drivers/acpi/reboot.c 2010-12-23 08:18:08.0000000= 00 +0100 +++ 2011-09-20/xen/drivers/acpi/reboot.c 2011-08-25 15:13:05.0000000= 00 +0200 @@ -24,7 +24,7 @@ void acpi_reboot(void) case ACPI_ADR_SPACE_PCI_CONFIG: printk("Resetting with ACPI PCI RESET_REG.\n"); /* Write the value that resets us. */ - pci_conf_write8(0, + pci_conf_write8(0, 0, (rr->address >> 32) & 31, (rr->address >> 16) & 7, (rr->address & 255), --- 2011-09-20.orig/xen/drivers/char/ns16550.c 2011-09-05 09:12:30.0000000= 00 +0200 +++ 2011-09-20/xen/drivers/char/ns16550.c 2011-09-20 16:06:57.0000000= 00 +0200 @@ -212,12 +212,12 @@ static void pci_serial_early_init(struct return; =20 if ( uart->pb_bdf_enable ) - pci_conf_write16(uart->pb_bdf[0], uart->pb_bdf[1], uart->pb_bdf[2]= , + pci_conf_write16(0, uart->pb_bdf[0], uart->pb_bdf[1], uart->pb_bdf= [2], 0x1c, (uart->io_base & 0xF000) | ((uart->io_base & 0xF000) >> = 8)); =20 - pci_conf_write32(uart->ps_bdf[0], uart->ps_bdf[1], uart->ps_bdf[2], + pci_conf_write32(0, uart->ps_bdf[0], uart->ps_bdf[1], uart->ps_bdf[2],= 0x10, uart->io_base | 0x1); - pci_conf_write16(uart->ps_bdf[0], uart->ps_bdf[1], uart->ps_bdf[2], + pci_conf_write16(0, uart->ps_bdf[0], uart->ps_bdf[1], uart->ps_bdf[2],= 0x4, 0x1); } =20 @@ -329,10 +329,10 @@ static void ns16550_suspend(struct seria if ( uart->bar ) { uart->bar =3D pci_conf_read32( - uart->pb_bdf[0], uart->pb_bdf[1], uart->pb_bdf[2], + 0, uart->pb_bdf[0], uart->pb_bdf[1], uart->pb_bdf[2], PCI_BASE_ADDRESS_0 + uart->bar_idx*4); uart->cr =3D pci_conf_read32( - uart->pb_bdf[0], uart->pb_bdf[1], uart->pb_bdf[2], + 0, uart->pb_bdf[0], uart->pb_bdf[1], uart->pb_bdf[2], PCI_COMMAND); } } @@ -346,9 +346,9 @@ static void ns16550_resume(struct serial =20 if ( uart->bar ) { - pci_conf_write32(uart->pb_bdf[0], uart->pb_bdf[1], uart->pb_bdf[2],= + pci_conf_write32(0, uart->pb_bdf[0], uart->pb_bdf[1], uart->pb_bdf[= 2], PCI_BASE_ADDRESS_0 + uart->bar_idx*4, uart->bar); - pci_conf_write32(uart->pb_bdf[0], uart->pb_bdf[1], uart->pb_bdf[2],= + pci_conf_write32(0, uart->pb_bdf[0], uart->pb_bdf[1], uart->pb_bdf[= 2], PCI_COMMAND, uart->cr); } } @@ -467,19 +467,20 @@ pci_uart_config (struct ns16550 *uart, i { for ( f =3D 0; f < 0x8; f++ ) { - class =3D pci_conf_read16(b, d, f, PCI_CLASS_DEVICE); + class =3D pci_conf_read16(0, b, d, f, PCI_CLASS_DEVICE); if ( class !=3D 0x700 ) continue; =20 - bar =3D pci_conf_read32(b, d, f, PCI_BASE_ADDRESS_0 + = bar_idx*4); + bar =3D pci_conf_read32(0, b, d, f, + PCI_BASE_ADDRESS_0 + bar_idx*4); =20 /* Not IO */ if ( !(bar & 1) ) continue; =20 - pci_conf_write32(b, d, f, PCI_BASE_ADDRESS_0, ~0u); - len =3D pci_conf_read32(b, d, f, PCI_BASE_ADDRESS_0); - pci_conf_write32(b, d, f, PCI_BASE_ADDRESS_0 + bar_idx*4, = bar); + pci_conf_write32(0, b, d, f, PCI_BASE_ADDRESS_0, ~0u); + len =3D pci_conf_read32(0, b, d, f, PCI_BASE_ADDRESS_0); + pci_conf_write32(0, b, d, f, PCI_BASE_ADDRESS_0 + = bar_idx*4, bar); =20 /* Not 8 bytes */ if ( (len & 0xffff) !=3D 0xfff9 ) --- 2011-09-20.orig/xen/drivers/passthrough/amd/iommu_detect.c 2011-08-25 = 15:06:47.000000000 +0200 +++ 2011-09-20/xen/drivers/passthrough/amd/iommu_detect.c 2011-08-25 = 15:13:05.000000000 +0200 @@ -35,14 +35,14 @@ static int __init get_iommu_msi_capabili u16 control; int count =3D 0; =20 - cap_ptr =3D pci_conf_read8(bus, dev, func, + cap_ptr =3D pci_conf_read8(seg, bus, dev, func, PCI_CAPABILITY_LIST); =20 while ( cap_ptr >=3D PCI_MIN_CAP_OFFSET && count < PCI_MAX_CAP_BLOCKS ) { cap_ptr &=3D PCI_CAP_PTR_MASK; - cap_header =3D pci_conf_read32(bus, dev, func, cap_ptr); + cap_header =3D pci_conf_read32(seg, bus, dev, func, cap_ptr); cap_id =3D get_field_from_reg_u32(cap_header, PCI_CAP_ID_MASK, PCI_CAP_ID_SHIFT); =20 @@ -60,7 +60,7 @@ static int __init get_iommu_msi_capabili return -ENODEV; =20 AMD_IOMMU_DEBUG("Found MSI capability block \n"); - control =3D pci_conf_read16(bus, dev, func, + control =3D pci_conf_read16(seg, bus, dev, func, iommu->msi_cap + PCI_MSI_FLAGS); iommu->maskbit =3D control & PCI_MSI_FLAGS_MASKBIT; return 0; @@ -71,18 +71,18 @@ static int __init get_iommu_capabilities { u32 cap_header, cap_range, misc_info; =20 - cap_header =3D pci_conf_read32(bus, dev, func, cap_ptr); + cap_header =3D pci_conf_read32(seg, bus, dev, func, cap_ptr); iommu->revision =3D get_field_from_reg_u32( cap_header, PCI_CAP_REV_MASK, PCI_CAP_REV_SHIFT); iommu->pte_not_present_cached =3D get_field_from_reg_u32( cap_header, PCI_CAP_NP_CACHE_MASK, PCI_CAP_NP_CACHE_SHIFT); =20 - cap_range =3D pci_conf_read32(bus, dev, func, + cap_range =3D pci_conf_read32(seg, bus, dev, func, cap_ptr + PCI_CAP_RANGE_OFFSET); iommu->unit_id =3D get_field_from_reg_u32( cap_range, PCI_CAP_UNIT_ID_MASK, PCI_CAP_UNIT_ID_SHIFT); =20 - misc_info =3D pci_conf_read32(bus, dev, func, + misc_info =3D pci_conf_read32(seg, bus, dev, func, cap_ptr + PCI_MISC_INFO_OFFSET); iommu->msi_number =3D get_field_from_reg_u32( misc_info, PCI_CAP_MSI_NUMBER_MASK, PCI_CAP_MSI_NUMBER_SHIFT); --- 2011-09-20.orig/xen/drivers/passthrough/amd/iommu_init.c 2011-08-25 = 15:06:47.000000000 +0200 +++ 2011-09-20/xen/drivers/passthrough/amd/iommu_init.c 2011-08-25 = 15:19:59.000000000 +0200 @@ -269,7 +269,7 @@ static void set_iommu_event_log_control( writel(entry, iommu->mmio_base + IOMMU_CONTROL_MMIO_OFFSET); } =20 -static void parse_event_log_entry(u32 entry[]); +static void parse_event_log_entry(struct amd_iommu *, u32 entry[]); =20 static int amd_iommu_read_event_log(struct amd_iommu *iommu) { @@ -290,7 +290,7 @@ static int amd_iommu_read_event_log(stru (iommu->event_log_head * IOMMU_EVENT_LOG_ENTRY_SIZE)); =20 - parse_event_log_entry(event_log); + parse_event_log_entry(iommu, event_log); =20 if ( ++iommu->event_log_head =3D=3D iommu->event_log.entries ) iommu->event_log_head =3D 0; @@ -351,6 +351,7 @@ static void iommu_msi_set_affinity(unsig struct amd_iommu *iommu =3D irq_to_iommu[irq]; struct irq_desc *desc =3D irq_to_desc(irq); struct irq_cfg *cfg =3D desc->chip_data; + u16 seg =3D iommu->seg; u8 bus =3D (iommu->bdf >> 8) & 0xff; u8 dev =3D PCI_SLOT(iommu->bdf & 0xff); u8 func =3D PCI_FUNC(iommu->bdf & 0xff); @@ -379,11 +380,11 @@ static void iommu_msi_set_affinity(unsig MSI_ADDR_REDIRECTION_LOWPRI; msg.address_lo |=3D MSI_ADDR_DEST_ID(dest & 0xff); =20 - pci_conf_write32(bus, dev, func, + pci_conf_write32(seg, bus, dev, func, iommu->msi_cap + PCI_MSI_DATA_64, msg.data); - pci_conf_write32(bus, dev, func, + pci_conf_write32(seg, bus, dev, func, iommu->msi_cap + PCI_MSI_ADDRESS_LO, msg.address_lo); - pci_conf_write32(bus, dev, func, + pci_conf_write32(seg, bus, dev, func, iommu->msi_cap + PCI_MSI_ADDRESS_HI, msg.address_hi); =20 } @@ -395,12 +396,12 @@ static void amd_iommu_msi_enable(struct=20 int dev =3D PCI_SLOT(iommu->bdf & 0xff); int func =3D PCI_FUNC(iommu->bdf & 0xff); =20 - control =3D pci_conf_read16(bus, dev, func, + control =3D pci_conf_read16(iommu->seg, bus, dev, func, iommu->msi_cap + PCI_MSI_FLAGS); control &=3D ~(1); if ( flag ) control |=3D flag; - pci_conf_write16(bus, dev, func, + pci_conf_write16(iommu->seg, bus, dev, func, iommu->msi_cap + PCI_MSI_FLAGS, control); } =20 @@ -459,7 +460,7 @@ static hw_irq_controller iommu_msi_type=20 .set_affinity =3D iommu_msi_set_affinity, }; =20 -static void parse_event_log_entry(u32 entry[]) +static void parse_event_log_entry(struct amd_iommu *iommu, u32 entry[]) { u16 domain_id, device_id, bdf, cword; u32 code; @@ -500,11 +501,12 @@ static void parse_event_log_entry(u32 en /* Tell the device to stop DMAing; we can't rely on the guest to * control it for us. */ for ( bdf =3D 0; bdf < ivrs_bdf_entries; bdf++ ) - if ( get_dma_requestor_id(bdf) =3D=3D device_id )=20 + if ( get_dma_requestor_id(iommu->seg, bdf) =3D=3D device_id ) { - cword =3D pci_conf_read16(PCI_BUS(bdf), PCI_SLOT(bdf),=20 - PCI_FUNC(bdf), PCI_COMMAND); - pci_conf_write16(PCI_BUS(bdf), PCI_SLOT(bdf),=20 + cword =3D pci_conf_read16(iommu->seg, PCI_BUS(bdf), + PCI_SLOT(bdf), PCI_FUNC(bdf), + PCI_COMMAND); + pci_conf_write16(iommu->seg, PCI_BUS(bdf), PCI_SLOT(bdf), PCI_FUNC(bdf), PCI_COMMAND,=20 cword & ~PCI_COMMAND_MASTER); } --- 2011-09-20.orig/xen/drivers/passthrough/pci.c 2011-08-25 = 15:12:12.000000000 +0200 +++ 2011-09-20/xen/drivers/passthrough/pci.c 2011-08-25 15:13:05.0000000= 00 +0200 @@ -214,8 +214,8 @@ void pci_enable_acs(struct pci_dev *pdev if (!pos) return; =20 - cap =3D pci_conf_read16(bus, dev, func, pos + PCI_ACS_CAP); - ctrl =3D pci_conf_read16(bus, dev, func, pos + PCI_ACS_CTRL); + cap =3D pci_conf_read16(seg, bus, dev, func, pos + PCI_ACS_CAP); + ctrl =3D pci_conf_read16(seg, bus, dev, func, pos + PCI_ACS_CTRL); =20 /* Source Validation */ ctrl |=3D (cap & PCI_ACS_SV); @@ -229,7 +229,7 @@ void pci_enable_acs(struct pci_dev *pdev /* Upstream Forwarding */ ctrl |=3D (cap & PCI_ACS_UF); =20 - pci_conf_write16(bus, dev, func, pos + PCI_ACS_CTRL, ctrl); + pci_conf_write16(seg, bus, dev, func, pos + PCI_ACS_CTRL, ctrl); } =20 int pci_add_device(u16 seg, u8 bus, u8 devfn, const struct pci_dev_info = *info) @@ -273,7 +273,7 @@ int pci_add_device(u16 seg, u8 bus, u8 d { unsigned int pos =3D pci_find_ext_capability(seg, bus, devfn, PCI_EXT_CAP_ID_SRIOV); - u16 ctrl =3D pci_conf_read16(bus, slot, func, pos + PCI_SRIOV_CTRL= ); + u16 ctrl =3D pci_conf_read16(seg, bus, slot, func, pos + = PCI_SRIOV_CTRL); =20 if ( !pos ) /* Nothing */; @@ -285,7 +285,7 @@ int pci_add_device(u16 seg, u8 bus, u8 d for ( i =3D 0; i < PCI_SRIOV_NUM_BARS; ++i ) { unsigned int idx =3D pos + PCI_SRIOV_BAR + i * 4; - u32 bar =3D pci_conf_read32(bus, slot, func, idx); + u32 bar =3D pci_conf_read32(seg, bus, slot, func, idx); u32 hi =3D 0; =20 if ( (bar & PCI_BASE_ADDRESS_SPACE) =3D=3D @@ -297,7 +297,7 @@ int pci_add_device(u16 seg, u8 bus, u8 d seg, bus, slot, func, i); continue; } - pci_conf_write32(bus, slot, func, idx, ~0); + pci_conf_write32(seg, bus, slot, func, idx, ~0); if ( (bar & PCI_BASE_ADDRESS_MEM_TYPE_MASK) =3D=3D PCI_BASE_ADDRESS_MEM_TYPE_64 ) { @@ -309,21 +309,22 @@ int pci_add_device(u16 seg, u8 bus, u8 d seg, bus, slot, func); break; } - hi =3D pci_conf_read32(bus, slot, func, idx + 4); - pci_conf_write32(bus, slot, func, idx + 4, ~0); + hi =3D pci_conf_read32(seg, bus, slot, func, idx + = 4); + pci_conf_write32(seg, bus, slot, func, idx + 4, ~0); } - pdev->vf_rlen[i] =3D pci_conf_read32(bus, slot, func, = idx) & + pdev->vf_rlen[i] =3D pci_conf_read32(seg, bus, slot, = func, idx) & PCI_BASE_ADDRESS_MEM_MASK; if ( (bar & PCI_BASE_ADDRESS_MEM_TYPE_MASK) =3D=3D PCI_BASE_ADDRESS_MEM_TYPE_64 ) { - pdev->vf_rlen[i] |=3D (u64)pci_conf_read32(bus, slot, = func, + pdev->vf_rlen[i] |=3D (u64)pci_conf_read32(seg, bus, + slot, func, idx + 4) << = 32; - pci_conf_write32(bus, slot, func, idx + 4, hi); + pci_conf_write32(seg, bus, slot, func, idx + 4, hi); } else if ( pdev->vf_rlen[i] ) pdev->vf_rlen[i] |=3D (u64)~0 << 32; - pci_conf_write32(bus, slot, func, idx, bar); + pci_conf_write32(seg, bus, slot, func, idx, bar); pdev->vf_rlen[i] =3D -pdev->vf_rlen[i]; if ( (bar & PCI_BASE_ADDRESS_MEM_TYPE_MASK) =3D=3D PCI_BASE_ADDRESS_MEM_TYPE_64 ) @@ -458,23 +459,24 @@ int pdev_type(u16 seg, u8 bus, u8 devfn) int pos; u8 d =3D PCI_SLOT(devfn), f =3D PCI_FUNC(devfn); =20 - class_device =3D pci_conf_read16(bus, d, f, PCI_CLASS_DEVICE); + class_device =3D pci_conf_read16(seg, bus, d, f, PCI_CLASS_DEVICE); if ( class_device =3D=3D PCI_CLASS_BRIDGE_PCI ) { - pos =3D pci_find_next_cap(bus, devfn, + pos =3D pci_find_next_cap(seg, bus, devfn, PCI_CAPABILITY_LIST, PCI_CAP_ID_EXP); if ( !pos ) return DEV_TYPE_LEGACY_PCI_BRIDGE; - creg =3D pci_conf_read16(bus, d, f, pos + PCI_EXP_FLAGS); + creg =3D pci_conf_read16(seg, bus, d, f, pos + PCI_EXP_FLAGS); return ((creg & PCI_EXP_FLAGS_TYPE) >> 4) =3D=3D PCI_EXP_TYPE_PCI_= BRIDGE ? DEV_TYPE_PCIe2PCI_BRIDGE : DEV_TYPE_PCIe_BRIDGE; } =20 - status =3D pci_conf_read16(bus, d, f, PCI_STATUS); + status =3D pci_conf_read16(seg, bus, d, f, PCI_STATUS); if ( !(status & PCI_STATUS_CAP_LIST) ) return DEV_TYPE_PCI; =20 - if ( pci_find_next_cap(bus, devfn, PCI_CAPABILITY_LIST, PCI_CAP_ID_EXP= ) ) + if ( pci_find_next_cap(seg, bus, devfn, PCI_CAPABILITY_LIST, + PCI_CAP_ID_EXP) ) return DEV_TYPE_PCIe_ENDPOINT; =20 return DEV_TYPE_PCI; @@ -527,7 +529,7 @@ int __init pci_device_detect(u16 seg, u8 { u32 vendor; =20 - vendor =3D pci_conf_read32(bus, dev, func, PCI_VENDOR_ID); + vendor =3D pci_conf_read32(seg, bus, dev, func, PCI_VENDOR_ID); /* some broken boards return 0 or ~0 if a slot is empty: */ if ( (vendor =3D=3D 0xffffffff) || (vendor =3D=3D 0x00000000) || (vendor =3D=3D 0x0000ffff) || (vendor =3D=3D 0xffff0000) ) @@ -571,9 +573,9 @@ static int __init _scan_pci_devices(stru =20 case DEV_TYPE_PCIe2PCI_BRIDGE: case DEV_TYPE_LEGACY_PCI_BRIDGE: - sec_bus =3D pci_conf_read8(bus, dev, func, + sec_bus =3D pci_conf_read8(pseg->nr, bus, dev, = func, PCI_SECONDARY_BUS); - sub_bus =3D pci_conf_read8(bus, dev, func, + sub_bus =3D pci_conf_read8(pseg->nr, bus, dev, = func, PCI_SUBORDINATE_BUS); =20 spin_lock(&pseg->bus2bridge_lock); @@ -597,7 +599,7 @@ static int __init _scan_pci_devices(stru return -EINVAL; } =20 - if ( !func && !(pci_conf_read8(bus, dev, func, + if ( !func && !(pci_conf_read8(pseg->nr, bus, dev, func, PCI_HEADER_TYPE) & 0x80) ) break; } @@ -667,7 +669,7 @@ static int _disconnect_pci_devices(struc struct pci_dev *pdev; =20 list_for_each_entry ( pdev, &pseg->alldevs_list, alldevs_list ) - pci_conf_write16(pdev->bus, PCI_SLOT(pdev->devfn), + pci_conf_write16(pseg->nr, pdev->bus, PCI_SLOT(pdev->devfn), PCI_FUNC(pdev->devfn), PCI_COMMAND, 0); =20 return 0; --- 2011-09-20.orig/xen/drivers/passthrough/vtd/dmar.c 2011-08-25 = 15:12:12.000000000 +0200 +++ 2011-09-20/xen/drivers/passthrough/vtd/dmar.c 2011-08-25 = 15:13:05.000000000 +0200 @@ -307,17 +307,18 @@ static int __init acpi_parse_dev_scope( =20 while ( --depth > 0 ) { - bus =3D pci_conf_read8(bus, path->dev, path->fn, PCI_SECONDARY= _BUS); + bus =3D pci_conf_read8(seg, bus, path->dev, path->fn, + PCI_SECONDARY_BUS); path++; } =20 switch ( acpi_scope->dev_type ) { case ACPI_DEV_P2PBRIDGE: - sec_bus =3D pci_conf_read8( - bus, path->dev, path->fn, PCI_SECONDARY_BUS); - sub_bus =3D pci_conf_read8( - bus, path->dev, path->fn, PCI_SUBORDINATE_BUS); + sec_bus =3D pci_conf_read8(seg, bus, path->dev, path->fn, + PCI_SECONDARY_BUS); + sub_bus =3D pci_conf_read8(seg, bus, path->dev, path->fn, + PCI_SUBORDINATE_BUS); if ( iommu_verbose ) dprintk(VTDPREFIX, " bridge: %04x:%02x:%02x.%u start=3D%x sec=3D%x = sub=3D%x\n", --- 2011-09-20.orig/xen/drivers/passthrough/vtd/iommu.c 2011-09-20 = 16:06:42.000000000 +0200 +++ 2011-09-20/xen/drivers/passthrough/vtd/iommu.c 2011-09-20 = 16:06:48.000000000 +0200 @@ -941,11 +941,12 @@ static void iommu_page_fault(int irq, vo =20 /* Tell the device to stop DMAing; we can't rely on the guest to * control it for us. */ - cword =3D pci_conf_read16(PCI_BUS(source_id), PCI_SLOT(source_id),= =20 + cword =3D pci_conf_read16(iommu->intel->drhd->segment, + PCI_BUS(source_id), PCI_SLOT(source_id), PCI_FUNC(source_id), PCI_COMMAND); - pci_conf_write16(PCI_BUS(source_id), PCI_SLOT(source_id),=20 - PCI_FUNC(source_id), PCI_COMMAND,=20 - cword & ~PCI_COMMAND_MASTER); + pci_conf_write16(iommu->intel->drhd->segment, PCI_BUS(source_id), + PCI_SLOT(source_id), PCI_FUNC(source_id), + PCI_COMMAND, cword & ~PCI_COMMAND_MASTER); =20 fault_index++; if ( fault_index > cap_num_fault_regs(iommu->cap) ) --- 2011-09-20.orig/xen/drivers/passthrough/vtd/quirks.c 2011-08-25 = 15:06:35.000000000 +0200 +++ 2011-09-20/xen/drivers/passthrough/vtd/quirks.c 2011-08-25 = 15:13:05.000000000 +0200 @@ -70,7 +70,7 @@ int is_igd_vt_enabled_quirk(void) return 1; =20 /* integrated graphics on Intel platforms is located at 0:2.0 */ - ggc =3D pci_conf_read16(0, IGD_DEV, 0, GGC); + ggc =3D pci_conf_read16(0, 0, IGD_DEV, 0, GGC); return ( ggc & GGC_MEMORY_VT_ENABLED ? 1 : 0 ); } =20 @@ -84,12 +84,12 @@ static void __init cantiga_b3_errata_ini u16 vid; u8 did_hi, rid; =20 - vid =3D pci_conf_read16(0, IGD_DEV, 0, 0); + vid =3D pci_conf_read16(0, 0, IGD_DEV, 0, 0); if ( vid !=3D 0x8086 ) return; =20 - did_hi =3D pci_conf_read8(0, IGD_DEV, 0, 3); - rid =3D pci_conf_read8(0, IGD_DEV, 0, 8); + did_hi =3D pci_conf_read8(0, 0, IGD_DEV, 0, 3); + rid =3D pci_conf_read8(0, 0, IGD_DEV, 0, 8); =20 if ( (did_hi =3D=3D 0x2A) && (rid =3D=3D 0x7) ) is_cantiga_b3 =3D 1; @@ -125,8 +125,8 @@ static void __init map_igd_reg(void) return; =20 /* get IGD mmio address in PCI BAR */ - igd_mmio =3D ((u64)pci_conf_read32(0, IGD_DEV, 0, 0x14) << 32) + - pci_conf_read32(0, IGD_DEV, 0, 0x10); + igd_mmio =3D ((u64)pci_conf_read32(0, 0, IGD_DEV, 0, 0x14) << 32) + + pci_conf_read32(0, 0, IGD_DEV, 0, 0x10); =20 /* offset of IGD regster we want to access is in 0x2000 range */ igd_reg =3D (igd_mmio & IGD_BAR_MASK) + 0x2000; @@ -251,8 +251,8 @@ void vtd_ops_postamble_quirk(struct iomm /* initialize platform identification flags */ void __init platform_quirks_init(void) { - ioh_id =3D pci_conf_read32(0, IOH_DEV, 0, 0); - igd_id =3D pci_conf_read32(0, IGD_DEV, 0, 0); + ioh_id =3D pci_conf_read32(0, 0, IOH_DEV, 0, 0); + igd_id =3D pci_conf_read32(0, 0, IGD_DEV, 0, 0); =20 /* Mobile 4 Series Chipset neglects to set RWBF capability. */ if ( ioh_id =3D=3D 0x2a408086 ) @@ -302,15 +302,15 @@ void me_wifi_quirk(struct domain *domain { u32 id; =20 - id =3D pci_conf_read32(0, 0, 0, 0); + id =3D pci_conf_read32(0, 0, 0, 0, 0); if ( IS_CTG(id) ) { /* quit if ME does not exist */ - if ( pci_conf_read32(0, 3, 0, 0) =3D=3D 0xffffffff ) + if ( pci_conf_read32(0, 0, 3, 0, 0) =3D=3D 0xffffffff ) return; =20 /* if device is WLAN device, map ME phantom device 0:3.7 */ - id =3D pci_conf_read32(bus, PCI_SLOT(devfn), PCI_FUNC(devfn), 0); + id =3D pci_conf_read32(0, bus, PCI_SLOT(devfn), PCI_FUNC(devfn), = 0); switch (id) { case 0x42328086: @@ -330,11 +330,11 @@ void me_wifi_quirk(struct domain *domain else if ( IS_ILK(id) || IS_CPT(id) ) { /* quit if ME does not exist */ - if ( pci_conf_read32(0, 22, 0, 0) =3D=3D 0xffffffff ) + if ( pci_conf_read32(0, 0, 22, 0, 0) =3D=3D 0xffffffff ) return; =20 /* if device is WLAN device, map ME phantom device 0:22.7 */ - id =3D pci_conf_read32(bus, PCI_SLOT(devfn), PCI_FUNC(devfn), 0); + id =3D pci_conf_read32(0, bus, PCI_SLOT(devfn), PCI_FUNC(devfn), = 0); switch (id) { case 0x00878086: /* Kilmer Peak */ @@ -364,16 +364,17 @@ void me_wifi_quirk(struct domain *domain void __init pci_vtd_quirk(struct pci_dev *pdev) { #ifdef CONFIG_X86_64 + int seg =3D pdev->seg; int bus =3D pdev->bus; int dev =3D PCI_SLOT(pdev->devfn); int func =3D PCI_FUNC(pdev->devfn); int id, val; =20 - id =3D pci_conf_read32(bus, dev, func, 0); + id =3D pci_conf_read32(seg, bus, dev, func, 0); if ( id =3D=3D 0x342e8086 || id =3D=3D 0x3c288086 ) { - val =3D pci_conf_read32(bus, dev, func, 0x1AC); - pci_conf_write32(bus, dev, func, 0x1AC, val | (1 << 31)); + val =3D pci_conf_read32(seg, bus, dev, func, 0x1AC); + pci_conf_write32(seg, bus, dev, func, 0x1AC, val | (1 << 31)); } #endif } --- 2011-09-20.orig/xen/drivers/passthrough/vtd/utils.c 2011-08-25 = 15:06:43.000000000 +0200 +++ 2011-09-20/xen/drivers/passthrough/vtd/utils.c 2011-08-25 = 15:13:05.000000000 +0200 @@ -34,7 +34,7 @@ =20 int is_usb_device(u16 seg, u8 bus, u8 devfn) { - u16 class =3D pci_conf_read16(bus, PCI_SLOT(devfn), PCI_FUNC(devfn), + u16 class =3D pci_conf_read16(seg, bus, PCI_SLOT(devfn), PCI_FUNC(devf= n), PCI_CLASS_DEVICE); return (class =3D=3D 0xc03); } --- 2011-09-20.orig/xen/drivers/passthrough/vtd/x86/ats.c 2011-08-25 = 15:06:43.000000000 +0200 +++ 2011-09-20/xen/drivers/passthrough/vtd/x86/ats.c 2011-08-25 = 15:13:05.000000000 +0200 @@ -135,8 +135,7 @@ int enable_ats_device(int seg, int bus,=20 "%04x:%02x:%02x.%u: ATS capability found\n", seg, bus, PCI_SLOT(devfn), PCI_FUNC(devfn)); =20 - /* BUGBUG: add back seg when multi-seg platform support is enabled */ - value =3D pci_conf_read16(bus, PCI_SLOT(devfn), + value =3D pci_conf_read16(seg, bus, PCI_SLOT(devfn), PCI_FUNC(devfn), pos + ATS_REG_CTL); if ( value & ATS_ENABLE ) { @@ -157,7 +156,7 @@ int enable_ats_device(int seg, int bus,=20 if ( !(value & ATS_ENABLE) ) { value |=3D ATS_ENABLE; - pci_conf_write16(bus, PCI_SLOT(devfn), PCI_FUNC(devfn), + pci_conf_write16(seg, bus, PCI_SLOT(devfn), PCI_FUNC(devfn), pos + ATS_REG_CTL, value); } =20 @@ -166,7 +165,7 @@ int enable_ats_device(int seg, int bus,=20 pdev->seg =3D seg; pdev->bus =3D bus; pdev->devfn =3D devfn; - value =3D pci_conf_read16(bus, PCI_SLOT(devfn), + value =3D pci_conf_read16(seg, bus, PCI_SLOT(devfn), PCI_FUNC(devfn), pos + ATS_REG_CAP); pdev->ats_queue_depth =3D value & ATS_QUEUE_DEPTH_MASK; list_add(&pdev->list, &ats_devices); @@ -190,11 +189,10 @@ void disable_ats_device(int seg, int bus pos =3D pci_find_ext_capability(seg, bus, devfn, PCI_EXT_CAP_ID_ATS); BUG_ON(!pos); =20 - /* BUGBUG: add back seg when multi-seg platform support is enabled */ - value =3D pci_conf_read16(bus, PCI_SLOT(devfn), + value =3D pci_conf_read16(seg, bus, PCI_SLOT(devfn), PCI_FUNC(devfn), pos + ATS_REG_CTL); value &=3D ~ATS_ENABLE; - pci_conf_write16(bus, PCI_SLOT(devfn), PCI_FUNC(devfn), + pci_conf_write16(seg, bus, PCI_SLOT(devfn), PCI_FUNC(devfn), pos + ATS_REG_CTL, value); =20 list_for_each_entry ( pdev, &ats_devices, list ) --- 2011-09-20.orig/xen/drivers/pci/pci.c 2008-10-13 13:36:27.0000000= 00 +0200 +++ 2011-09-20/xen/drivers/pci/pci.c 2011-08-25 15:13:05.000000000 = +0200 @@ -7,25 +7,25 @@ #include <xen/pci.h> #include <xen/pci_regs.h> =20 -int pci_find_cap_offset(u8 bus, u8 dev, u8 func, u8 cap) +int pci_find_cap_offset(u16 seg, u8 bus, u8 dev, u8 func, u8 cap) { u8 id; int max_cap =3D 48; u8 pos =3D PCI_CAPABILITY_LIST; u16 status; =20 - status =3D pci_conf_read16(bus, dev, func, PCI_STATUS); + status =3D pci_conf_read16(seg, bus, dev, func, PCI_STATUS); if ( (status & PCI_STATUS_CAP_LIST) =3D=3D 0 ) return 0; =20 while ( max_cap-- ) { - pos =3D pci_conf_read8(bus, dev, func, pos); + pos =3D pci_conf_read8(seg, bus, dev, func, pos); if ( pos < 0x40 ) break; =20 pos &=3D ~3; - id =3D pci_conf_read8(bus, dev, func, pos + PCI_CAP_LIST_ID); + id =3D pci_conf_read8(seg, bus, dev, func, pos + PCI_CAP_LIST_ID);= =20 if ( id =3D=3D 0xff ) break; @@ -38,19 +38,19 @@ int pci_find_cap_offset(u8 bus, u8 dev,=20 return 0; } =20 -int pci_find_next_cap(u8 bus, unsigned int devfn, u8 pos, int cap) +int pci_find_next_cap(u16 seg, u8 bus, unsigned int devfn, u8 pos, int = cap) { u8 id; int ttl =3D 48; =20 while ( ttl-- ) { - pos =3D pci_conf_read8(bus, PCI_SLOT(devfn), PCI_FUNC(devfn), = pos); + pos =3D pci_conf_read8(seg, bus, PCI_SLOT(devfn), PCI_FUNC(devfn),= pos); if ( pos < 0x40 ) break; =20 pos &=3D ~3; - id =3D pci_conf_read8(bus, PCI_SLOT(devfn), PCI_FUNC(devfn), + id =3D pci_conf_read8(seg, bus, PCI_SLOT(devfn), PCI_FUNC(devfn), pos + PCI_CAP_LIST_ID); =20 if ( id =3D=3D 0xff ) --- 2011-09-20.orig/xen/include/xen/pci.h 2011-08-25 15:12:12.0000000= 00 +0200 +++ 2011-09-20/xen/include/xen/pci.h 2011-08-25 15:13:05.000000000 = +0200 @@ -102,28 +102,31 @@ struct pci_dev *pci_get_pdev_by_domain( void disconnect_pci_devices(void); =20 uint8_t pci_conf_read8( - unsigned int bus, unsigned int dev, unsigned int func, unsigned int = reg); + unsigned int seg, unsigned int bus, unsigned int dev, unsigned int = func, + unsigned int reg); uint16_t pci_conf_read16( - unsigned int bus, unsigned int dev, unsigned int func, unsigned int = reg); + unsigned int seg, unsigned int bus, unsigned int dev, unsigned int = func, + unsigned int reg); uint32_t pci_conf_read32( - unsigned int bus, unsigned int dev, unsigned int func, unsigned int = reg); + unsigned int seg, unsigned int bus, unsigned int dev, unsigned int = func, + unsigned int reg); void pci_conf_write8( - unsigned int bus, unsigned int dev, unsigned int func, unsigned int = reg, - uint8_t data); + unsigned int seg, unsigned int bus, unsigned int dev, unsigned int = func, + unsigned int reg, uint8_t data); void pci_conf_write16( - unsigned int bus, unsigned int dev, unsigned int func, unsigned int = reg, - uint16_t data); + unsigned int seg, unsigned int bus, unsigned int dev, unsigned int = func, + unsigned int reg, uint16_t data); void pci_conf_write32( - unsigned int bus, unsigned int dev, unsigned int func, unsigned int = reg, - uint32_t data); + unsigned int seg, unsigned int bus, unsigned int dev, unsigned int = func, + unsigned int reg, uint32_t data); uint32_t pci_conf_read(uint32_t cf8, uint8_t offset, uint8_t bytes); void pci_conf_write(uint32_t cf8, uint8_t offset, uint8_t bytes, uint32_t = data); int pci_mmcfg_read(unsigned int seg, unsigned int bus, unsigned int devfn, int reg, int len, u32 *value); int pci_mmcfg_write(unsigned int seg, unsigned int bus, unsigned int devfn, int reg, int len, u32 value); -int pci_find_cap_offset(u8 bus, u8 dev, u8 func, u8 cap); -int pci_find_next_cap(u8 bus, unsigned int devfn, u8 pos, int cap); +int pci_find_cap_offset(u16 seg, u8 bus, u8 dev, u8 func, u8 cap); +int pci_find_next_cap(u16 seg, u8 bus, unsigned int devfn, u8 pos, int = cap); int pci_find_ext_capability(int seg, int bus, int devfn, int cap); =20 struct pirq; --=__PartDAF5E12B.0__= Content-Type: text/plain; name="pci-multi-seg.patch" Content-Transfer-Encoding: quoted-printable Content-Disposition: attachment; filename="pci-multi-seg.patch" Signed-off-by: Jan Beulich <jbeulich@suse.com>=0A=0A--- 2011-09-20.orig/xen= /arch/x86/cpu/amd.c 2011-08-16 08:15:46.000000000 +0200=0A+++ = 2011-09-20/xen/arch/x86/cpu/amd.c 2011-08-25 15:13:05.000000000 = +0200=0A@@ -262,15 +262,15 @@ static void disable_c1_ramping(void) =0A = int node, nr_nodes;=0A =0A /* Read the number of nodes from the first = Northbridge. */=0A- nr_nodes =3D ((pci_conf_read32(0, 0x18, 0x0, = 0x60)>>4)&0x07)+1;=0A+ nr_nodes =3D ((pci_conf_read32(0, 0, 0x18, 0x0, = 0x60)>>4)&0x07)+1;=0A for (node =3D 0; node < nr_nodes; node++) {=0A = /* PMM7: bus=3D0, dev=3D0x18+node, function=3D0x3, register=3D0x87. */=0A- = pmm7 =3D pci_conf_read8(0, 0x18+node, 0x3, 0x87);=0A+ = pmm7 =3D pci_conf_read8(0, 0, 0x18+node, 0x3, 0x87);=0A /* = Invalid read means we've updated every Northbridge. */=0A if = (pmm7 =3D=3D 0xFF)=0A break;=0A pmm7 &=3D = 0xFC; /* clear pmm7[1:0] */=0A- pci_conf_write8(0, 0x18+node, 0x3, = 0x87, pmm7);=0A+ pci_conf_write8(0, 0, 0x18+node, 0x3, = 0x87, pmm7);=0A printk ("AMD: Disabling C1 Clock Ramping = Node #%x\n", node);=0A }=0A }=0A--- 2011-09-20.orig/xen/arch/x86/dmi_scan.= c 2011-09-05 09:12:30.000000000 +0200=0A+++ 2011-09-20/xen/arch/x86/d= mi_scan.c 2011-08-25 15:36:55.000000000 +0200=0A@@ -284,15 +284,15 = @@ static int __init ich10_bios_quirk(struc=0A {=0A u32 port, = smictl;=0A =0A- if ( pci_conf_read16(0, 0x1f, 0, PCI_VENDOR_ID) !=3D = 0x8086 )=0A+ if ( pci_conf_read16(0, 0, 0x1f, 0, PCI_VENDOR_ID) !=3D = 0x8086 )=0A return 0;=0A =0A- switch ( pci_conf_read16(0, 0x1f, = 0, PCI_DEVICE_ID) ) {=0A+ switch ( pci_conf_read16(0, 0, 0x1f, 0, = PCI_DEVICE_ID) ) {=0A case 0x3a14:=0A case 0x3a16:=0A case = 0x3a18:=0A case 0x3a1a:=0A- port =3D (pci_conf_read16(0, 0x1f, = 0, 0x40) & 0xff80) + 0x30;=0A+ port =3D (pci_conf_read16(0, 0, = 0x1f, 0, 0x40) & 0xff80) + 0x30;=0A smictl =3D inl(port);=0A = /* turn off LEGACY_USB{,2}_EN if enabled */=0A if ( smictl & = 0x20008 )=0A--- 2011-09-20.orig/xen/arch/x86/msi.c 2011-08-25 = 15:06:35.000000000 +0200=0A+++ 2011-09-20/xen/arch/x86/msi.c 2011-08-25 = 15:13:05.000000000 +0200=0A@@ -166,23 +166,25 @@ static void read_msi_msg(s= truct msi_desc=0A {=0A struct pci_dev *dev =3D entry->dev;=0A = int pos =3D entry->msi_attrib.pos;=0A- u16 data;=0A+ = u16 data, seg =3D dev->seg;=0A u8 bus =3D dev->bus;=0A u8 = slot =3D PCI_SLOT(dev->devfn);=0A u8 func =3D PCI_FUNC(dev->devfn);= =0A =0A- msg->address_lo =3D pci_conf_read32(bus, slot, func,=0A+ = msg->address_lo =3D pci_conf_read32(seg, bus, slot, func,=0A = msi_lower_address_reg(pos));=0A = if ( entry->msi_attrib.is_64 )=0A {=0A- msg->address_hi = =3D pci_conf_read32(bus, slot, func,=0A+ msg->address_hi =3D = pci_conf_read32(seg, bus, slot, func,=0A = msi_upper_address_reg(pos));=0A- data =3D pci_conf_r= ead16(bus, slot, func, msi_data_reg(pos, 1));=0A+ data =3D = pci_conf_read16(seg, bus, slot, func,=0A+ = msi_data_reg(pos, 1));=0A }=0A else=0A {=0A = msg->address_hi =3D 0;=0A- data =3D pci_conf_read16(bus, = slot, func, msi_data_reg(pos, 0));=0A+ data =3D pci_conf_read16(= seg, bus, slot, func,=0A+ msi_data_reg(po= s, 0));=0A }=0A msg->data =3D data;=0A break;=0A@@ = -231,21 +233,22 @@ static void write_msi_msg(struct msi_des=0A {=0A = struct pci_dev *dev =3D entry->dev;=0A int pos =3D entry->msi_= attrib.pos;=0A+ u16 seg =3D dev->seg;=0A u8 bus =3D = dev->bus;=0A u8 slot =3D PCI_SLOT(dev->devfn);=0A u8 func = =3D PCI_FUNC(dev->devfn);=0A =0A- pci_conf_write32(bus, slot, func, = msi_lower_address_reg(pos),=0A+ pci_conf_write32(seg, bus, slot, = func, msi_lower_address_reg(pos),=0A msg->address_= lo);=0A if ( entry->msi_attrib.is_64 )=0A {=0A- = pci_conf_write32(bus, slot, func, msi_upper_address_reg(pos),=0A+ = pci_conf_write32(seg, bus, slot, func, msi_upper_address_reg(pos),=0A = msg->address_hi);=0A- pci_conf_write16= (bus, slot, func, msi_data_reg(pos, 1),=0A+ pci_conf_write16(seg= , bus, slot, func, msi_data_reg(pos, 1),=0A = msg->data);=0A }=0A else=0A- pci_conf_write16(bu= s, slot, func, msi_data_reg(pos, 0),=0A+ pci_conf_write16(seg, = bus, slot, func, msi_data_reg(pos, 0),=0A = msg->data);=0A break;=0A }=0A@@ -295,38 +298,38 @@ void = set_msi_affinity(unsigned int irq, =0A static void msi_set_enable(struct = pci_dev *dev, int enable)=0A {=0A int pos;=0A- u16 control;=0A+ = u16 control, seg =3D dev->seg;=0A u8 bus =3D dev->bus;=0A u8 slot = =3D PCI_SLOT(dev->devfn);=0A u8 func =3D PCI_FUNC(dev->devfn);=0A =0A- = pos =3D pci_find_cap_offset(bus, slot, func, PCI_CAP_ID_MSI);=0A+ = pos =3D pci_find_cap_offset(seg, bus, slot, func, PCI_CAP_ID_MSI);=0A = if ( pos )=0A {=0A- control =3D pci_conf_read16(bus, slot, = func, pos + PCI_MSI_FLAGS);=0A+ control =3D pci_conf_read16(seg, = bus, slot, func, pos + PCI_MSI_FLAGS);=0A control &=3D ~PCI_MSI_FLA= GS_ENABLE;=0A if ( enable )=0A control |=3D PCI_MSI_FLA= GS_ENABLE;=0A- pci_conf_write16(bus, slot, func, pos + PCI_MSI_FLAGS= , control);=0A+ pci_conf_write16(seg, bus, slot, func, pos + = PCI_MSI_FLAGS, control);=0A }=0A }=0A =0A static void msix_set_enable(s= truct pci_dev *dev, int enable)=0A {=0A int pos;=0A- u16 control;=0A= + u16 control, seg =3D dev->seg;=0A u8 bus =3D dev->bus;=0A u8 = slot =3D PCI_SLOT(dev->devfn);=0A u8 func =3D PCI_FUNC(dev->devfn);=0A = =0A- pos =3D pci_find_cap_offset(bus, slot, func, PCI_CAP_ID_MSIX);=0A+ = pos =3D pci_find_cap_offset(seg, bus, slot, func, PCI_CAP_ID_MSIX);=0A = if ( pos )=0A {=0A- control =3D pci_conf_read16(bus, slot, = func, pos + PCI_MSIX_FLAGS);=0A+ control =3D pci_conf_read16(seg, = bus, slot, func, pos + PCI_MSIX_FLAGS);=0A control &=3D ~PCI_MSIX_F= LAGS_ENABLE;=0A if ( enable )=0A control |=3D = PCI_MSIX_FLAGS_ENABLE;=0A- pci_conf_write16(bus, slot, func, pos + = PCI_MSIX_FLAGS, control);=0A+ pci_conf_write16(seg, bus, slot, = func, pos + PCI_MSIX_FLAGS, control);=0A }=0A }=0A =0A@@ -348,15 = +351,16 @@ static void msi_set_mask_bit(unsigned in=0A if = (entry->msi_attrib.maskbit) {=0A int pos;=0A u32 = mask_bits;=0A+ u16 seg =3D entry->dev->seg;=0A u8 = bus =3D entry->dev->bus;=0A u8 slot =3D PCI_SLOT(entry->dev->de= vfn);=0A u8 func =3D PCI_FUNC(entry->dev->devfn);=0A =0A = pos =3D (long)entry->mask_base;=0A- mask_bits =3D = pci_conf_read32(bus, slot, func, pos);=0A+ mask_bits =3D = pci_conf_read32(seg, bus, slot, func, pos);=0A mask_bits &=3D = ~(1);=0A mask_bits |=3D flag;=0A- pci_conf_write32(b= us, slot, func, pos, mask_bits);=0A+ pci_conf_write32(seg, bus, = slot, func, pos, mask_bits);=0A }=0A break;=0A case = PCI_CAP_ID_MSIX:=0A@@ -379,7 +383,8 @@ static int msi_get_mask_bit(const = struct=0A case PCI_CAP_ID_MSI:=0A if (!entry->dev || !entry->ms= i_attrib.maskbit)=0A break;=0A- return pci_conf_read32(e= ntry->dev->bus, PCI_SLOT(entry->dev->devfn),=0A+ return pci_conf_rea= d32(entry->dev->seg, entry->dev->bus,=0A+ = PCI_SLOT(entry->dev->devfn),=0A PCI_FUNC(ent= ry->dev->devfn),=0A (unsigned long)entry->ma= sk_base) & 1;=0A case PCI_CAP_ID_MSIX:=0A@@ -473,14 +478,14 @@ static = int msi_capability_init(struct pc=0A {=0A struct msi_desc *entry;=0A = int pos;=0A- u16 control;=0A+ u16 control, seg =3D dev->seg;=0A = u8 bus =3D dev->bus;=0A u8 slot =3D PCI_SLOT(dev->devfn);=0A u8 = func =3D PCI_FUNC(dev->devfn);=0A =0A ASSERT(spin_is_locked(&pcidevs_lo= ck));=0A- pos =3D pci_find_cap_offset(bus, slot, func, PCI_CAP_ID_MSI);= =0A- control =3D pci_conf_read16(bus, slot, func, msi_control_reg(pos));= =0A+ pos =3D pci_find_cap_offset(seg, bus, slot, func, PCI_CAP_ID_MSI);= =0A+ control =3D pci_conf_read16(seg, bus, slot, func, msi_control_reg(p= os));=0A /* MSI Entry Initialization */=0A msi_set_enable(dev, 0); = /* Ensure msi is disabled as I set it up */=0A =0A@@ -503,12 +508,12 @@ = static int msi_capability_init(struct pc=0A {=0A unsigned int = maskbits, temp;=0A /* All MSIs are unmasked by default, Mask them = all */=0A- maskbits =3D pci_conf_read32(bus, slot, func,=0A+ = maskbits =3D pci_conf_read32(seg, bus, slot, func,=0A = msi_mask_bits_reg(pos, is_64bit_address(control)));=0A = temp =3D (1 << multi_msi_capable(control));=0A temp =3D ((temp - = 1) & ~temp);=0A maskbits |=3D temp;=0A- pci_conf_write32(bus= , slot, func,=0A+ pci_conf_write32(seg, bus, slot, func,=0A = msi_mask_bits_reg(pos, is_64bit_address(control)),=0A = maskbits);=0A }=0A@@ -516,27 +521,28 @@ static = int msi_capability_init(struct pc=0A =0A *desc =3D entry;=0A /* = Restore the original MSI enabled bits */=0A- pci_conf_write16(bus, = slot, func, msi_control_reg(pos), control);=0A+ pci_conf_write16(seg, = bus, slot, func, msi_control_reg(pos), control);=0A =0A return 0;=0A = }=0A =0A-static u64 read_pci_mem_bar(u8 bus, u8 slot, u8 func, u8 bir, int = vf)=0A+static u64 read_pci_mem_bar(u16 seg, u8 bus, u8 slot, u8 func, u8 = bir, int vf)=0A {=0A u8 limit;=0A u32 addr, base =3D PCI_BASE_ADDRE= SS_0, disp =3D 0;=0A =0A if ( vf >=3D 0 )=0A {=0A- struct = pci_dev *pdev =3D pci_get_pdev(0, bus, PCI_DEVFN(slot, func));=0A- = unsigned int pos =3D pci_find_ext_capability(0, bus,=0A+ struct = pci_dev *pdev =3D pci_get_pdev(seg, bus, PCI_DEVFN(slot, func));=0A+ = unsigned int pos =3D pci_find_ext_capability(seg, bus,=0A = PCI_DEVFN(slot, func),=0A = PCI_EXT_CAP_ID_SRIOV);=0A- u16 = ctrl =3D pci_conf_read16(bus, slot, func, pos + PCI_SRIOV_CTRL);=0A- = u16 num_vf =3D pci_conf_read16(bus, slot, func, pos + PCI_SRIOV_NUM_VF);= =0A- u16 offset =3D pci_conf_read16(bus, slot, func,=0A+ u16 = ctrl =3D pci_conf_read16(seg, bus, slot, func, pos + PCI_SRIOV_CTRL);=0A+ = u16 num_vf =3D pci_conf_read16(seg, bus, slot, func,=0A+ = pos + PCI_SRIOV_NUM_VF);=0A+ u16 offset =3D = pci_conf_read16(seg, bus, slot, func,=0A = pos + PCI_SRIOV_VF_OFFSET);=0A- u16 stride =3D pci_conf_read16(bu= s, slot, func,=0A+ u16 stride =3D pci_conf_read16(seg, bus, slot, = func,=0A pos + PCI_SRIOV_VF_STRIDE);= =0A =0A if ( !pdev || !pos ||=0A@@ -562,7 +568,8 @@ static u64 = read_pci_mem_bar(u8 bus, u8 s=0A disp =3D vf * pdev->vf_rlen[bir];= =0A limit =3D PCI_SRIOV_NUM_BARS;=0A }=0A- else switch ( = pci_conf_read8(bus, slot, func, PCI_HEADER_TYPE) & 0x7f )=0A+ else = switch ( pci_conf_read8(seg, bus, slot, func,=0A+ = PCI_HEADER_TYPE) & 0x7f )=0A {=0A case PCI_HEADER_TYPE_NORMA= L:=0A limit =3D 6;=0A@@ -579,7 +586,7 @@ static u64 read_pci_mem_ba= r(u8 bus, u8 s=0A =0A if ( bir >=3D limit )=0A return 0;=0A- = addr =3D pci_conf_read32(bus, slot, func, base + bir * 4);=0A+ addr = =3D pci_conf_read32(seg, bus, slot, func, base + bir * 4);=0A if ( = (addr & PCI_BASE_ADDRESS_SPACE) =3D=3D PCI_BASE_ADDRESS_SPACE_IO )=0A = return 0;=0A if ( (addr & PCI_BASE_ADDRESS_MEM_TYPE_MASK) =3D=3D = PCI_BASE_ADDRESS_MEM_TYPE_64 )=0A@@ -588,7 +595,8 @@ static u64 read_pci_me= m_bar(u8 bus, u8 s=0A if ( ++bir >=3D limit )=0A = return 0;=0A return addr + disp +=0A- ((u64)pci_conf_= read32(bus, slot, func, base + bir * 4) << 32);=0A+ = ((u64)pci_conf_read32(seg, bus, slot, func,=0A+ = base + bir * 4) << 32);=0A }=0A return (addr & PCI_BASE_AD= DRESS_MEM_MASK) + disp;=0A }=0A@@ -616,6 +624,7 @@ static int msix_capabili= ty_init(struct p=0A u8 bir;=0A void __iomem *base;=0A int = idx;=0A+ u16 seg =3D dev->seg;=0A u8 bus =3D dev->bus;=0A u8 = slot =3D PCI_SLOT(dev->devfn);=0A u8 func =3D PCI_FUNC(dev->devfn);=0A@= @ -623,8 +632,8 @@ static int msix_capability_init(struct p=0A = ASSERT(spin_is_locked(&pcidevs_lock));=0A ASSERT(desc);=0A =0A- pos = =3D pci_find_cap_offset(bus, slot, func, PCI_CAP_ID_MSIX);=0A- control = =3D pci_conf_read16(bus, slot, func, msix_control_reg(pos));=0A+ pos = =3D pci_find_cap_offset(seg, bus, slot, func, PCI_CAP_ID_MSIX);=0A+ = control =3D pci_conf_read16(seg, bus, slot, func, msix_control_reg(pos));= =0A msix_set_enable(dev, 0);/* Ensure msix is disabled as I set it up = */=0A =0A /* MSI-X Table Initialization */=0A@@ -633,7 +642,8 @@ = static int msix_capability_init(struct p=0A return -ENOMEM;=0A =0A = /* Request & Map MSI-X table region */=0A- table_offset =3D = pci_conf_read32(bus, slot, func, msix_table_offset_reg(pos));=0A+ = table_offset =3D pci_conf_read32(seg, bus, slot, func,=0A+ = msix_table_offset_reg(pos));=0A bir =3D (u8)(table_of= fset & PCI_MSIX_BIRMASK);=0A table_offset &=3D ~PCI_MSIX_BIRMASK;=0A = entry_offset =3D msi->entry_nr * PCI_MSIX_ENTRY_SIZE;=0A@@ -685,7 +695,7 = @@ static int msix_capability_init(struct p=0A =0A ASSERT(!dev->msi= x_used_entries);=0A WARN_ON(msi->table_base !=3D=0A- = read_pci_mem_bar(pbus, pslot, pfunc, bir, vf));=0A+ = read_pci_mem_bar(seg, pbus, pslot, pfunc, bir, vf));=0A =0A = dev->msix_nr_entries =3D nr_entries;=0A dev->msix_table.first =3D = PFN_DOWN(table_paddr);=0A@@ -694,10 +704,10 @@ static int msix_capability_i= nit(struct p=0A WARN_ON(rangeset_overlaps_range(mmio_ro_ranges, = dev->msix_table.first,=0A = dev->msix_table.last));=0A =0A- pba_offset =3D pci_conf_read32(bus, = slot, func,=0A+ pba_offset =3D pci_conf_read32(seg, bus, slot, = func,=0A msix_pba_offset_reg(pos));=0A= bir =3D (u8)(pba_offset & PCI_MSIX_BIRMASK);=0A- pba_paddr = =3D read_pci_mem_bar(pbus, pslot, pfunc, bir, vf);=0A+ pba_paddr = =3D read_pci_mem_bar(seg, pbus, pslot, pfunc, bir, vf);=0A = WARN_ON(!pba_paddr);=0A pba_paddr +=3D pba_offset & ~PCI_MSIX_BIRMA= SK;=0A =0A@@ -744,7 +754,7 @@ static int msix_capability_init(struct p=0A = =0A *desc =3D entry;=0A /* Restore MSI-X enabled bits */=0A- = pci_conf_write16(bus, slot, func, msix_control_reg(pos), control);=0A+ = pci_conf_write16(seg, bus, slot, func, msix_control_reg(pos), control);=0A = =0A return 0;=0A }=0A@@ -835,8 +845,9 @@ static int __pci_enable_msix(s= truct msi_=0A if ( !pdev )=0A return -ENODEV;=0A =0A- pos = =3D pci_find_cap_offset(msi->bus, slot, func, PCI_CAP_ID_MSIX);=0A- = control =3D pci_conf_read16(msi->bus, slot, func, msix_control_reg(pos));= =0A+ pos =3D pci_find_cap_offset(msi->seg, msi->bus, slot, func, = PCI_CAP_ID_MSIX);=0A+ control =3D pci_conf_read16(msi->seg, msi->bus, = slot, func,=0A+ msix_control_reg(pos));=0A = nr_entries =3D multi_msix_capable(control);=0A if (msi->entry_nr >=3D = nr_entries)=0A return -EINVAL;=0A@@ -870,23 +881,24 @@ static void = __pci_disable_msix(struct ms=0A {=0A struct pci_dev *dev;=0A int = pos;=0A- u16 control;=0A+ u16 control, seg;=0A u8 bus, slot, = func;=0A =0A dev =3D entry->dev;=0A+ seg =3D dev->seg;=0A bus = =3D dev->bus;=0A slot =3D PCI_SLOT(dev->devfn);=0A func =3D = PCI_FUNC(dev->devfn);=0A =0A- pos =3D pci_find_cap_offset(bus, slot, = func, PCI_CAP_ID_MSIX);=0A- control =3D pci_conf_read16(bus, slot, = func, msix_control_reg(pos));=0A+ pos =3D pci_find_cap_offset(seg, bus, = slot, func, PCI_CAP_ID_MSIX);=0A+ control =3D pci_conf_read16(seg, bus, = slot, func, msix_control_reg(pos));=0A msix_set_enable(dev, 0);=0A =0A = BUG_ON(list_empty(&dev->msi_list));=0A =0A writel(1, entry->mask_ba= se + PCI_MSIX_ENTRY_VECTOR_CTRL_OFFSET);=0A =0A- pci_conf_write16(bus, = slot, func, msix_control_reg(pos), control);=0A+ pci_conf_write16(seg, = bus, slot, func, msix_control_reg(pos), control);=0A =0A if ( = !--dev->msix_used_entries )=0A {=0A@@ -995,7 +1007,7 @@ int pci_restore= _msi_state(struct pci_dev=0A unsigned int pci_msix_get_table_len(struct = pci_dev *pdev)=0A {=0A int pos;=0A- u16 control;=0A+ u16 = control, seg =3D pdev->seg;=0A u8 bus, slot, func;=0A unsigned int = len;=0A =0A@@ -1003,11 +1015,11 @@ unsigned int pci_msix_get_table_len(stru= =0A slot =3D PCI_SLOT(pdev->devfn);=0A func =3D PCI_FUNC(pdev->devf= n);=0A =0A- pos =3D pci_find_cap_offset(bus, slot, func, PCI_CAP_ID_MSIX= );=0A+ pos =3D pci_find_cap_offset(seg, bus, slot, func, PCI_CAP_ID_MSIX= );=0A if ( !pos )=0A return 0;=0A =0A- control =3D = pci_conf_read16(bus, slot, func, msix_control_reg(pos));=0A+ control = =3D pci_conf_read16(seg, bus, slot, func, msix_control_reg(pos));=0A = len =3D msix_table_size(control) * PCI_MSIX_ENTRY_SIZE;=0A =0A return = len;=0A--- 2011-09-20.orig/xen/arch/x86/oprofile/op_model_athlon.c = 2011-06-16 09:21:02.000000000 +0200=0A+++ 2011-09-20/xen/arch/x86/oprofile/= op_model_athlon.c 2011-08-25 15:13:05.000000000 +0200=0A@@ -470,7 = +470,7 @@ static int __init init_ibs_nmi(void)=0A for (bus =3D 0; = bus < 256; bus++) {=0A for (dev =3D 0; dev < 32; dev++) {=0A = for (func =3D 0; func < 8; func++) {=0A- = id =3D pci_conf_read32(bus, dev, func, PCI_VENDOR_ID);=0A+ = id =3D pci_conf_read32(0, bus, dev, func, PCI_VENDOR_ID);=0A =0A = vendor_id =3D id & 0xffff;=0A = dev_id =3D (id >> 16) & 0xffff;=0A@@ -478,10 +478,10 @@ static int __init = init_ibs_nmi(void)=0A if ((vendor_id =3D=3D = PCI_VENDOR_ID_AMD) &&=0A (dev_id = =3D=3D PCI_DEVICE_ID_AMD_10H_NB_MISC)) {=0A =0A- = pci_conf_write32(bus, dev, func, IBSCTL,=0A+ = pci_conf_write32(0, bus, dev, func, IBSCTL,=0A = IBSCTL_LVTOFFSETVAL | APIC_EILVT_LVTOFF_IBS);=0A =0A- = value =3D pci_conf_read32(bus, dev, func, = IBSCTL);=0A+ value =3D pci_conf_read32(0= , bus, dev, func, IBSCTL);=0A =0A if = (value !=3D (IBSCTL_LVTOFFSETVAL |=0A = APIC_EILVT_LVTOFF_IBS)) {=0A--- 2011-09-20.orig/xen/arch/x86/x86_32/pci.c = 2011-08-08 08:29:50.000000000 +0200=0A+++ 2011-09-20/xen/arch/x86/x86_32/pc= i.c 2011-08-25 15:13:05.000000000 +0200=0A@@ -12,46 +12,61 @@=0A = (0x80000000 | (bus << 16) | (dev << 11) | (func << 8) | (reg & ~3))=0A =0A = uint8_t pci_conf_read8(=0A- unsigned int bus, unsigned int dev, = unsigned int func, unsigned int reg)=0A+ unsigned int seg, unsigned int = bus, unsigned int dev, unsigned int func,=0A+ unsigned int reg)=0A = {=0A+ if ( seg )=0A+ return ~0;=0A BUG_ON((bus > 255) || = (dev > 31) || (func > 7) || (reg > 255));=0A return pci_conf_read(PCI_C= ONF_ADDRESS(bus, dev, func, reg), reg & 3, 1);=0A }=0A =0A uint16_t = pci_conf_read16(=0A- unsigned int bus, unsigned int dev, unsigned int = func, unsigned int reg)=0A+ unsigned int seg, unsigned int bus, = unsigned int dev, unsigned int func,=0A+ unsigned int reg)=0A {=0A+ = if ( seg )=0A+ return ~0;=0A BUG_ON((bus > 255) || (dev > 31) = || (func > 7) || (reg > 255));=0A return pci_conf_read(PCI_CONF_ADDRESS= (bus, dev, func, reg), reg & 2, 2);=0A }=0A =0A uint32_t pci_conf_read32(= =0A- unsigned int bus, unsigned int dev, unsigned int func, unsigned = int reg)=0A+ unsigned int seg, unsigned int bus, unsigned int dev, = unsigned int func,=0A+ unsigned int reg)=0A {=0A+ if ( seg )=0A+ = return ~0;=0A BUG_ON((bus > 255) || (dev > 31) || (func > 7) || = (reg > 255));=0A return pci_conf_read(PCI_CONF_ADDRESS(bus, dev, func, = reg), 0, 4);=0A }=0A =0A void pci_conf_write8(=0A- unsigned int bus, = unsigned int dev, unsigned int func, unsigned int reg,=0A- uint8_t = data)=0A+ unsigned int seg, unsigned int bus, unsigned int dev, = unsigned int func,=0A+ unsigned int reg, uint8_t data)=0A {=0A+ if ( = seg )=0A+ return;=0A BUG_ON((bus > 255) || (dev > 31) || (func = > 7) || (reg > 255));=0A pci_conf_write(PCI_CONF_ADDRESS(bus, dev, = func, reg), reg & 3, 1, data);=0A }=0A =0A void pci_conf_write16(=0A- = unsigned int bus, unsigned int dev, unsigned int func, unsigned int = reg,=0A- uint16_t data)=0A+ unsigned int seg, unsigned int bus, = unsigned int dev, unsigned int func,=0A+ unsigned int reg, uint16_t = data)=0A {=0A+ if ( seg )=0A+ return;=0A BUG_ON((bus > 255) = || (dev > 31) || (func > 7) || (reg > 255));=0A pci_conf_write(PCI_CONF= _ADDRESS(bus, dev, func, reg), reg & 2, 2, data);=0A }=0A =0A void = pci_conf_write32(=0A- unsigned int bus, unsigned int dev, unsigned int = func, unsigned int reg,=0A- uint32_t data)=0A+ unsigned int seg, = unsigned int bus, unsigned int dev, unsigned int func,=0A+ unsigned int = reg, uint32_t data)=0A {=0A+ if ( seg )=0A+ return;=0A = BUG_ON((bus > 255) || (dev > 31) || (func > 7) || (reg > 255));=0A = pci_conf_write(PCI_CONF_ADDRESS(bus, dev, func, reg), 0, 4, data);=0A = }=0A--- 2011-09-20.orig/xen/arch/x86/x86_64/mmconf-fam10h.c 2011-08-08 = 08:29:50.000000000 +0200=0A+++ 2011-09-20/xen/arch/x86/x86_64/mmconf-fam10h= .c 2011-08-25 15:13:05.000000000 +0200=0A@@ -51,7 +51,7 @@ static = void __init get_fam10h_pci_mmconf=0A =0A bus =3D pci_probes[= i].bus;=0A slot =3D pci_probes[i].slot;=0A- id = =3D pci_conf_read32(bus, slot, 0, PCI_VENDOR_ID);=0A+ id =3D = pci_conf_read32(0, bus, slot, 0, PCI_VENDOR_ID);=0A =0A = vendor =3D id & 0xffff;=0A device =3D (id>>16) & 0xffff;=0A@@ = -82,12 +82,12 @@ static void __init get_fam10h_pci_mmconf=0A * above = 4G=0A */=0A for (hi_mmio_num =3D i =3D 0; i < 8; i++) {=0A- = val =3D pci_conf_read32(bus, slot, 1, 0x80 + (i << 3));=0A+ = val =3D pci_conf_read32(0, bus, slot, 1, 0x80 + (i << 3));=0A if = (!(val & 3))=0A continue;=0A =0A = start =3D (val & 0xffffff00) << 8; /* 39:16 on 31:8*/=0A- = val =3D pci_conf_read32(bus, slot, 1, 0x84 + (i << 3));=0A+ = val =3D pci_conf_read32(0, bus, slot, 1, 0x84 + (i << 3));=0A = end =3D ((val & 0xffffff00) << 8) | 0xffff; /* 39:16 on 31:8*/=0A =0A = if (end < tom2)=0A--- 2011-09-20.orig/xen/arch/x86/x86_64/mmconfig-shared.c= 2011-08-25 15:06:23.000000000 +0200=0A+++ 2011-09-20/xen/arch/x86/x= 86_64/mmconfig-shared.c 2011-08-25 15:13:05.000000000 +0200=0A@@ -50,7 = +50,7 @@ custom_param("mmcfg", parse_mmcfg);=0A static const char __init = *pci_mmcfg_e7520(void)=0A {=0A u32 win;=0A- win =3D pci_conf_read16(= 0, 0, 0, 0xce);=0A+ win =3D pci_conf_read16(0, 0, 0, 0, 0xce);=0A =0A = win =3D win & 0xf000;=0A if(win =3D=3D 0x0000 || win =3D=3D = 0xf000)=0A@@ -76,7 +76,7 @@ static const char __init *pci_mmcfg_inte=0A = =0A pci_mmcfg_config_num =3D 1;=0A =0A- pciexbar =3D pci_conf_re= ad32(0, 0, 0, 0x48);=0A+ pciexbar =3D pci_conf_read32(0, 0, 0, 0, = 0x48);=0A =0A /* Enable bit */=0A if (!(pciexbar & 1))=0A@@ = -201,14 +201,14 @@ static const char __init *pci_mmcfg_nvid=0A u32 = l, extcfg;=0A u16 vendor, device;=0A =0A- l =3D pci_conf_rea= d32(bus, 0, 0, 0);=0A+ l =3D pci_conf_read32(0, bus, 0, 0, 0);=0A = vendor =3D l & 0xffff;=0A device =3D (l >> 16) & 0xffff;=0A = =0A if (PCI_VENDOR_ID_NVIDIA !=3D vendor || 0x0369 !=3D device)=0A = continue;=0A =0A- extcfg =3D pci_conf_read32(bus, 0, 0, = extcfg_regnum);=0A+ extcfg =3D pci_conf_read32(0, bus, 0, 0, = extcfg_regnum);=0A =0A if (extcfg & extcfg_enable_mask)=0A = i++;=0A@@ -227,14 +227,14 @@ static const char __init *pci_mmcfg_nvid= =0A u16 vendor, device;=0A int size_index;=0A =0A- = l =3D pci_conf_read32(bus, 0, 0, 0);=0A+ l =3D pci_conf_read32(0, = bus, 0, 0, 0);=0A vendor =3D l & 0xffff;=0A device =3D (l = >> 16) & 0xffff;=0A =0A if (PCI_VENDOR_ID_NVIDIA !=3D vendor || = 0x0369 !=3D device)=0A continue;=0A =0A- extcfg =3D = pci_conf_read32(bus, 0, 0, extcfg_regnum);=0A+ extcfg =3D pci_conf_r= ead32(0, bus, 0, 0, extcfg_regnum);=0A =0A if (!(extcfg & = extcfg_enable_mask))=0A continue;=0A@@ -300,7 +300,7 @@ static = int __init pci_mmcfg_check_hostbr=0A for (i =3D 0; !name && i < = ARRAY_SIZE(pci_mmcfg_probes); i++) {=0A bus =3D pci_mmcfg_probes[i= ].bus;=0A devfn =3D pci_mmcfg_probes[i].devfn;=0A- l =3D = pci_conf_read32(bus, PCI_SLOT(devfn), PCI_FUNC(devfn), 0);=0A+ l = =3D pci_conf_read32(0, bus, PCI_SLOT(devfn), PCI_FUNC(devfn), 0);=0A = vendor =3D l & 0xffff;=0A device =3D (l >> 16) & 0xffff;=0A = =0A@@ -473,7 +473,7 @@ int pci_find_ext_capability(int seg, int=0A int = ttl =3D 480; /* 3840 bytes, minimum 8 bytes per capability */=0A int = pos =3D 0x100;=0A =0A- header =3D pci_conf_read32(bus, PCI_SLOT(devfn), = PCI_FUNC(devfn), pos);=0A+ header =3D pci_conf_read32(seg, bus, = PCI_SLOT(devfn), PCI_FUNC(devfn), pos);=0A =0A /*=0A * If we have = no capabilities, this is indicated by cap ID,=0A@@ -488,7 +488,7 @@ int = pci_find_ext_capability(int seg, int=0A pos =3D PCI_EXT_CAP_NEXT(he= ader);=0A if ( pos < 0x100 )=0A break;=0A- = header =3D pci_conf_read32(bus, PCI_SLOT(devfn), PCI_FUNC(devfn), = pos);=0A+ header =3D pci_conf_read32(seg, bus, PCI_SLOT(devfn), = PCI_FUNC(devfn), pos);=0A }=0A return 0;=0A }=0A--- 2011-09-20.orig= /xen/arch/x86/x86_64/pci.c 2009-10-07 13:31:36.000000000 +0200=0A+++ = 2011-09-20/xen/arch/x86/x86_64/pci.c 2011-08-25 15:13:05.000000000 = +0200=0A@@ -12,13 +12,14 @@=0A (0x80000000 | (bus << 16) | (dev << 11) = | (func << 8) | (reg & ~3))=0A =0A uint8_t pci_conf_read8(=0A- unsigned = int bus, unsigned int dev, unsigned int func, unsigned int reg)=0A+ = unsigned int seg, unsigned int bus, unsigned int dev, unsigned int = func,=0A+ unsigned int reg)=0A {=0A u32 value;=0A =0A- if ( reg = > 255 )=0A+ if ( seg || reg > 255 )=0A {=0A- pci_mmcfg_read(0= , bus, PCI_DEVFN(dev, func), reg, 1, &value);=0A+ pci_mmcfg_read(seg= , bus, PCI_DEVFN(dev, func), reg, 1, &value);=0A return value;=0A = }=0A else=0A@@ -29,13 +30,14 @@ uint8_t pci_conf_read8(=0A }=0A =0A = uint16_t pci_conf_read16(=0A- unsigned int bus, unsigned int dev, = unsigned int func, unsigned int reg)=0A+ unsigned int seg, unsigned int = bus, unsigned int dev, unsigned int func,=0A+ unsigned int reg)=0A {=0A = u32 value;=0A =0A- if ( reg > 255 )=0A+ if ( seg || reg > 255 = )=0A {=0A- pci_mmcfg_read(0, bus, PCI_DEVFN(dev, func), reg, 2, = &value);=0A+ pci_mmcfg_read(seg, bus, PCI_DEVFN(dev, func), reg, 2, = &value);=0A return value;=0A }=0A else=0A@@ -46,13 +48,14 = @@ uint16_t pci_conf_read16(=0A }=0A =0A uint32_t pci_conf_read32(=0A- = unsigned int bus, unsigned int dev, unsigned int func, unsigned int = reg)=0A+ unsigned int seg, unsigned int bus, unsigned int dev, unsigned = int func,=0A+ unsigned int reg)=0A {=0A u32 value;=0A =0A- if ( = reg > 255 )=0A+ if ( seg || reg > 255 )=0A {=0A- pci_mmcfg_re= ad(0, bus, PCI_DEVFN(dev, func), reg, 4, &value);=0A+ pci_mmcfg_read= (seg, bus, PCI_DEVFN(dev, func), reg, 4, &value);=0A return = value;=0A }=0A else=0A@@ -63,11 +66,11 @@ uint32_t pci_conf_read32(= =0A }=0A =0A void pci_conf_write8(=0A- unsigned int bus, unsigned int = dev, unsigned int func, unsigned int reg,=0A- uint8_t data)=0A+ = unsigned int seg, unsigned int bus, unsigned int dev, unsigned int = func,=0A+ unsigned int reg, uint8_t data)=0A {=0A- if ( reg > 255 = )=0A- pci_mmcfg_write(0, bus, PCI_DEVFN(dev, func), reg, 1, = data);=0A+ if ( seg || reg > 255 )=0A+ pci_mmcfg_write(seg, bus, = PCI_DEVFN(dev, func), reg, 1, data);=0A else=0A {=0A = BUG_ON((bus > 255) || (dev > 31) || (func > 7));=0A@@ -76,11 +79,11 @@ = void pci_conf_write8(=0A }=0A =0A void pci_conf_write16(=0A- unsigned = int bus, unsigned int dev, unsigned int func, unsigned int reg,=0A- = uint16_t data)=0A+ unsigned int seg, unsigned int bus, unsigned int = dev, unsigned int func,=0A+ unsigned int reg, uint16_t data)=0A {=0A- = if ( reg > 255 )=0A- pci_mmcfg_write(0, bus, PCI_DEVFN(dev, func), = reg, 2, data);=0A+ if ( seg || reg > 255 )=0A+ pci_mmcfg_write(se= g, bus, PCI_DEVFN(dev, func), reg, 2, data);=0A else=0A {=0A = BUG_ON((bus > 255) || (dev > 31) || (func > 7));=0A@@ -89,11 +92,11 @@ = void pci_conf_write16(=0A }=0A =0A void pci_conf_write32(=0A- unsigned = int bus, unsigned int dev, unsigned int func, unsigned int reg,=0A- = uint32_t data)=0A+ unsigned int seg, unsigned int bus, unsigned int = dev, unsigned int func,=0A+ unsigned int reg, uint32_t data)=0A {=0A- = if ( reg > 255 )=0A- pci_mmcfg_write(0, bus, PCI_DEVFN(dev, func), = reg, 4, data);=0A+ if ( seg || reg > 255 )=0A+ pci_mmcfg_write(se= g, bus, PCI_DEVFN(dev, func), reg, 4, data);=0A else=0A {=0A = BUG_ON((bus > 255) || (dev > 31) || (func > 7));=0A--- 2011-09-20.orig/xe= n/drivers/acpi/reboot.c 2010-12-23 08:18:08.000000000 +0100=0A+++ = 2011-09-20/xen/drivers/acpi/reboot.c 2011-08-25 15:13:05.000000000 = +0200=0A@@ -24,7 +24,7 @@ void acpi_reboot(void)=0A case ACPI_ADR_SPACE= _PCI_CONFIG:=0A printk("Resetting with ACPI PCI RESET_REG.\= n");=0A /* Write the value that resets us. */=0A- = pci_conf_write8(0,=0A+ pci_conf_write8(0, 0,=0A = (rr->address >> 32) & 31,=0A (rr->addres= s >> 16) & 7,=0A (rr->address & 255),=0A--- = 2011-09-20.orig/xen/drivers/char/ns16550.c 2011-09-05 09:12:30.0000000= 00 +0200=0A+++ 2011-09-20/xen/drivers/char/ns16550.c 2011-09-20 = 16:06:57.000000000 +0200=0A@@ -212,12 +212,12 @@ static void pci_serial_ear= ly_init(struct=0A return;=0A =0A if ( uart->pb_bdf_enable = )=0A- pci_conf_write16(uart->pb_bdf[0], uart->pb_bdf[1], uart->pb_bd= f[2],=0A+ pci_conf_write16(0, uart->pb_bdf[0], uart->pb_bdf[1], = uart->pb_bdf[2],=0A 0x1c, (uart->io_base & 0xF000) | ((uart->io= _base & 0xF000) >> 8));=0A =0A- pci_conf_write32(uart->ps_bdf[0], = uart->ps_bdf[1], uart->ps_bdf[2],=0A+ pci_conf_write32(0, uart->ps_bdf[0= ], uart->ps_bdf[1], uart->ps_bdf[2],=0A 0x10, uart->io_base | = 0x1);=0A- pci_conf_write16(uart->ps_bdf[0], uart->ps_bdf[1], uart->ps_bd= f[2],=0A+ pci_conf_write16(0, uart->ps_bdf[0], uart->ps_bdf[1], = uart->ps_bdf[2],=0A 0x4, 0x1);=0A }=0A =0A@@ -329,10 +329,10 @@ = static void ns16550_suspend(struct seria=0A if ( uart->bar )=0A = {=0A uart->bar =3D pci_conf_read32(=0A- uart->pb_bdf[0], = uart->pb_bdf[1], uart->pb_bdf[2],=0A+ 0, uart->pb_bdf[0], = uart->pb_bdf[1], uart->pb_bdf[2],=0A PCI_BASE_ADDRESS_0 + = uart->bar_idx*4);=0A uart->cr =3D pci_conf_read32(=0A- = uart->pb_bdf[0], uart->pb_bdf[1], uart->pb_bdf[2],=0A+ 0, = uart->pb_bdf[0], uart->pb_bdf[1], uart->pb_bdf[2],=0A PCI_COMMAN= D);=0A }=0A }=0A@@ -346,9 +346,9 @@ static void ns16550_resume(struct = serial=0A =0A if ( uart->bar )=0A {=0A- pci_conf_write32(uart= ->pb_bdf[0], uart->pb_bdf[1], uart->pb_bdf[2],=0A+ pci_conf_write32(0= , uart->pb_bdf[0], uart->pb_bdf[1], uart->pb_bdf[2],=0A = PCI_BASE_ADDRESS_0 + uart->bar_idx*4, uart->bar);=0A- pci_conf_w= rite32(uart->pb_bdf[0], uart->pb_bdf[1], uart->pb_bdf[2],=0A+ = pci_conf_write32(0, uart->pb_bdf[0], uart->pb_bdf[1], uart->pb_bdf[2],=0A = PCI_COMMAND, uart->cr);=0A }=0A }=0A@@ -467,19 = +467,20 @@ pci_uart_config (struct ns16550 *uart, i=0A {=0A = for ( f =3D 0; f < 0x8; f++ )=0A {=0A- = class =3D pci_conf_read16(b, d, f, PCI_CLASS_DEVICE);=0A+ = class =3D pci_conf_read16(0, b, d, f, PCI_CLASS_DEVICE);=0A = if ( class !=3D 0x700 )=0A continue;=0A =0A- = bar =3D pci_conf_read32(b, d, f, PCI_BASE_ADDRESS_0 + bar_idx*4);=0A+= bar =3D pci_conf_read32(0, b, d, f,=0A+ = PCI_BASE_ADDRESS_0 + bar_idx*4);=0A =0A = /* Not IO */=0A if ( !(bar & 1) )=0A = continue;=0A =0A- pci_conf_write32(b, d, f, PCI_BASE_ADDRESS= _0, ~0u);=0A- len =3D pci_conf_read32(b, d, f, PCI_BASE_ADDR= ESS_0);=0A- pci_conf_write32(b, d, f, PCI_BASE_ADDRESS_0 + = bar_idx*4, bar);=0A+ pci_conf_write32(0, b, d, f, PCI_BASE_A= DDRESS_0, ~0u);=0A+ len =3D pci_conf_read32(0, b, d, f, = PCI_BASE_ADDRESS_0);=0A+ pci_conf_write32(0, b, d, f, = PCI_BASE_ADDRESS_0 + bar_idx*4, bar);=0A =0A /* Not 8 = bytes */=0A if ( (len & 0xffff) !=3D 0xfff9 )=0A--- = 2011-09-20.orig/xen/drivers/passthrough/amd/iommu_detect.c 2011-08-25 = 15:06:47.000000000 +0200=0A+++ 2011-09-20/xen/drivers/passthrough/amd/iommu= _detect.c 2011-08-25 15:13:05.000000000 +0200=0A@@ -35,14 +35,14 @@ = static int __init get_iommu_msi_capabili=0A u16 control;=0A int = count =3D 0;=0A =0A- cap_ptr =3D pci_conf_read8(bus, dev, func,=0A+ = cap_ptr =3D pci_conf_read8(seg, bus, dev, func,=0A PCI_CAPABILI= TY_LIST);=0A =0A while ( cap_ptr >=3D PCI_MIN_CAP_OFFSET &&=0A = count < PCI_MAX_CAP_BLOCKS )=0A {=0A cap_ptr &=3D PCI_CAP_PTR_M= ASK;=0A- cap_header =3D pci_conf_read32(bus, dev, func, cap_ptr);=0A= + cap_header =3D pci_conf_read32(seg, bus, dev, func, cap_ptr);=0A = cap_id =3D get_field_from_reg_u32(cap_header,=0A = PCI_CAP_ID_MASK, PCI_CAP_ID_SHIFT);=0A =0A@@ -60,7 +60,7 @@ static int = __init get_iommu_msi_capabili=0A return -ENODEV;=0A =0A = AMD_IOMMU_DEBUG("Found MSI capability block \n");=0A- control =3D = pci_conf_read16(bus, dev, func,=0A+ control =3D pci_conf_read16(seg, = bus, dev, func,=0A iommu->msi_cap + PCI_MSI_FLAGS);=0A = iommu->maskbit =3D control & PCI_MSI_FLAGS_MASKBIT;=0A return 0;=0A@@ = -71,18 +71,18 @@ static int __init get_iommu_capabilities=0A {=0A u32 = cap_header, cap_range, misc_info;=0A =0A- cap_header =3D pci_conf_read32= (bus, dev, func, cap_ptr);=0A+ cap_header =3D pci_conf_read32(seg, bus, = dev, func, cap_ptr);=0A iommu->revision =3D get_field_from_reg_u32(=0A = cap_header, PCI_CAP_REV_MASK, PCI_CAP_REV_SHIFT);=0A iommu->pte= _not_present_cached =3D get_field_from_reg_u32(=0A cap_header, = PCI_CAP_NP_CACHE_MASK, PCI_CAP_NP_CACHE_SHIFT);=0A =0A- cap_range =3D = pci_conf_read32(bus, dev, func,=0A+ cap_range =3D pci_conf_read32(seg, = bus, dev, func,=0A cap_ptr + PCI_CAP_RANGE_= OFFSET);=0A iommu->unit_id =3D get_field_from_reg_u32(=0A = cap_range, PCI_CAP_UNIT_ID_MASK, PCI_CAP_UNIT_ID_SHIFT);=0A =0A- = misc_info =3D pci_conf_read32(bus, dev, func,=0A+ misc_info =3D = pci_conf_read32(seg, bus, dev, func,=0A = cap_ptr + PCI_MISC_INFO_OFFSET);=0A iommu->msi_number =3D get_field_fro= m_reg_u32(=0A misc_info, PCI_CAP_MSI_NUMBER_MASK, PCI_CAP_MSI_NUMBE= R_SHIFT);=0A--- 2011-09-20.orig/xen/drivers/passthrough/amd/iommu_init.c = 2011-08-25 15:06:47.000000000 +0200=0A+++ 2011-09-20/xen/drivers/passthroug= h/amd/iommu_init.c 2011-08-25 15:19:59.000000000 +0200=0A@@ -269,7 = +269,7 @@ static void set_iommu_event_log_control(=0A writel(entry, = iommu->mmio_base + IOMMU_CONTROL_MMIO_OFFSET);=0A }=0A =0A-static void = parse_event_log_entry(u32 entry[]);=0A+static void parse_event_log_entry(st= ruct amd_iommu *, u32 entry[]);=0A =0A static int amd_iommu_read_event_log(= struct amd_iommu *iommu)=0A {=0A@@ -290,7 +290,7 @@ static int amd_iommu_re= ad_event_log(stru=0A (iommu->event_log_head = *=0A IOMMU_EVENT_LOG_ENTRY_SIZE));=0A =0A- = parse_event_log_entry(event_log);=0A+ parse_event_log_entry(iommu,= event_log);=0A =0A if ( ++iommu->event_log_head =3D=3D iommu->even= t_log.entries )=0A iommu->event_log_head =3D 0;=0A@@ -351,6 = +351,7 @@ static void iommu_msi_set_affinity(unsig=0A struct amd_iommu = *iommu =3D irq_to_iommu[irq];=0A struct irq_desc *desc =3D irq_to_desc(= irq);=0A struct irq_cfg *cfg =3D desc->chip_data;=0A+ u16 seg =3D = iommu->seg;=0A u8 bus =3D (iommu->bdf >> 8) & 0xff;=0A u8 dev =3D = PCI_SLOT(iommu->bdf & 0xff);=0A u8 func =3D PCI_FUNC(iommu->bdf & = 0xff);=0A@@ -379,11 +380,11 @@ static void iommu_msi_set_affinity(unsig=0A = MSI_ADDR_REDIRECTION_LOWPRI;=0A msg.address_lo = |=3D MSI_ADDR_DEST_ID(dest & 0xff);=0A =0A- pci_conf_write32(bus, dev, = func,=0A+ pci_conf_write32(seg, bus, dev, func,=0A iommu->msi_ca= p + PCI_MSI_DATA_64, msg.data);=0A- pci_conf_write32(bus, dev, = func,=0A+ pci_conf_write32(seg, bus, dev, func,=0A iommu->msi_ca= p + PCI_MSI_ADDRESS_LO, msg.address_lo);=0A- pci_conf_write32(bus, dev, = func,=0A+ pci_conf_write32(seg, bus, dev, func,=0A iommu->msi_ca= p + PCI_MSI_ADDRESS_HI, msg.address_hi);=0A =0A }=0A@@ -395,12 +396,12 = @@ static void amd_iommu_msi_enable(struct =0A int dev =3D PCI_SLOT(iom= mu->bdf & 0xff);=0A int func =3D PCI_FUNC(iommu->bdf & 0xff);=0A =0A- = control =3D pci_conf_read16(bus, dev, func,=0A+ control =3D pci_conf_r= ead16(iommu->seg, bus, dev, func,=0A iommu->msi_cap + PCI_MSI_FLAGS= );=0A control &=3D ~(1);=0A if ( flag )=0A control |=3D = flag;=0A- pci_conf_write16(bus, dev, func,=0A+ pci_conf_write16(iommu= ->seg, bus, dev, func,=0A iommu->msi_cap + PCI_MSI_FLAGS, = control);=0A }=0A =0A@@ -459,7 +460,7 @@ static hw_irq_controller = iommu_msi_type =0A .set_affinity =3D iommu_msi_set_affinity,=0A };=0A = =0A-static void parse_event_log_entry(u32 entry[])=0A+static void = parse_event_log_entry(struct amd_iommu *iommu, u32 entry[])=0A {=0A = u16 domain_id, device_id, bdf, cword;=0A u32 code;=0A@@ -500,11 = +501,12 @@ static void parse_event_log_entry(u32 en=0A /* Tell the = device to stop DMAing; we can't rely on the guest to=0A * control = it for us. */=0A for ( bdf =3D 0; bdf < ivrs_bdf_entries; bdf++ = )=0A- if ( get_dma_requestor_id(bdf) =3D=3D device_id ) =0A+ = if ( get_dma_requestor_id(iommu->seg, bdf) =3D=3D device_id )=0A = {=0A- cword =3D pci_conf_read16(PCI_BUS(bdf), = PCI_SLOT(bdf), =0A- PCI_FUNC(bdf), = PCI_COMMAND);=0A- pci_conf_write16(PCI_BUS(bdf), PCI_SLOT(bd= f), =0A+ cword =3D pci_conf_read16(iommu->seg, PCI_BUS(bdf),= =0A+ PCI_SLOT(bdf), PCI_FUNC(bdf),= =0A+ PCI_COMMAND);=0A+ = pci_conf_write16(iommu->seg, PCI_BUS(bdf), PCI_SLOT(bdf),=0A = PCI_FUNC(bdf), PCI_COMMAND, =0A = cword & ~PCI_COMMAND_MASTER);=0A }=0A--- 2011-09-20.= orig/xen/drivers/passthrough/pci.c 2011-08-25 15:12:12.000000000 = +0200=0A+++ 2011-09-20/xen/drivers/passthrough/pci.c 2011-08-25 = 15:13:05.000000000 +0200=0A@@ -214,8 +214,8 @@ void pci_enable_acs(struct = pci_dev *pdev=0A if (!pos)=0A return;=0A =0A- cap =3D = pci_conf_read16(bus, dev, func, pos + PCI_ACS_CAP);=0A- ctrl =3D = pci_conf_read16(bus, dev, func, pos + PCI_ACS_CTRL);=0A+ cap =3D = pci_conf_read16(seg, bus, dev, func, pos + PCI_ACS_CAP);=0A+ ctrl =3D = pci_conf_read16(seg, bus, dev, func, pos + PCI_ACS_CTRL);=0A =0A /* = Source Validation */=0A ctrl |=3D (cap & PCI_ACS_SV);=0A@@ -229,7 = +229,7 @@ void pci_enable_acs(struct pci_dev *pdev=0A /* Upstream = Forwarding */=0A ctrl |=3D (cap & PCI_ACS_UF);=0A =0A- pci_conf_writ= e16(bus, dev, func, pos + PCI_ACS_CTRL, ctrl);=0A+ pci_conf_write16(seg,= bus, dev, func, pos + PCI_ACS_CTRL, ctrl);=0A }=0A =0A int pci_add_device(= u16 seg, u8 bus, u8 devfn, const struct pci_dev_info *info)=0A@@ -273,7 = +273,7 @@ int pci_add_device(u16 seg, u8 bus, u8 d=0A {=0A = unsigned int pos =3D pci_find_ext_capability(seg, bus, devfn,=0A = PCI_EXT_CAP_ID_SRIOV);=0A- = u16 ctrl =3D pci_conf_read16(bus, slot, func, pos + PCI_SRIOV_CTRL);=0A+ = u16 ctrl =3D pci_conf_read16(seg, bus, slot, func, pos + PCI_SRIOV_CTR= L);=0A =0A if ( !pos )=0A /* Nothing */;=0A@@ -285,7 = +285,7 @@ int pci_add_device(u16 seg, u8 bus, u8 d=0A for ( i = =3D 0; i < PCI_SRIOV_NUM_BARS; ++i )=0A {=0A = unsigned int idx =3D pos + PCI_SRIOV_BAR + i * 4;=0A- u32 = bar =3D pci_conf_read32(bus, slot, func, idx);=0A+ u32 bar = =3D pci_conf_read32(seg, bus, slot, func, idx);=0A u32 hi = =3D 0;=0A =0A if ( (bar & PCI_BASE_ADDRESS_SPACE) = =3D=3D=0A@@ -297,7 +297,7 @@ int pci_add_device(u16 seg, u8 bus, u8 d=0A = seg, bus, slot, func, i);=0A = continue;=0A }=0A- pci_conf_write32(bus, = slot, func, idx, ~0);=0A+ pci_conf_write32(seg, bus, slot, = func, idx, ~0);=0A if ( (bar & PCI_BASE_ADDRESS_MEM_TYPE_MA= SK) =3D=3D=0A PCI_BASE_ADDRESS_MEM_TYPE_64 )=0A = {=0A@@ -309,21 +309,22 @@ int pci_add_device(u16 seg, u8 bus, u8 = d=0A seg, bus, slot, func);=0A = break;=0A }=0A- hi =3D = pci_conf_read32(bus, slot, func, idx + 4);=0A- = pci_conf_write32(bus, slot, func, idx + 4, ~0);=0A+ hi = =3D pci_conf_read32(seg, bus, slot, func, idx + 4);=0A+ = pci_conf_write32(seg, bus, slot, func, idx + 4, ~0);=0A = }=0A- pdev->vf_rlen[i] =3D pci_conf_read32(bus, slot, func, = idx) &=0A+ pdev->vf_rlen[i] =3D pci_conf_read32(seg, bus, = slot, func, idx) &=0A PCI_BASE_ADDRESS_M= EM_MASK;=0A if ( (bar & PCI_BASE_ADDRESS_MEM_TYPE_MASK) = =3D=3D=0A PCI_BASE_ADDRESS_MEM_TYPE_64 )=0A = {=0A- pdev->vf_rlen[i] |=3D (u64)pci_conf_read32(b= us, slot, func,=0A+ pdev->vf_rlen[i] |=3D (u64)pci_conf_= read32(seg, bus,=0A+ = slot, func,=0A = idx + 4) << 32;=0A- pci_conf_write32(bus, slot, = func, idx + 4, hi);=0A+ pci_conf_write32(seg, bus, = slot, func, idx + 4, hi);=0A }=0A else if = ( pdev->vf_rlen[i] )=0A pdev->vf_rlen[i] |=3D (u64)~0 = << 32;=0A- pci_conf_write32(bus, slot, func, idx, bar);=0A+ = pci_conf_write32(seg, bus, slot, func, idx, bar);=0A = pdev->vf_rlen[i] =3D -pdev->vf_rlen[i];=0A if ( = (bar & PCI_BASE_ADDRESS_MEM_TYPE_MASK) =3D=3D=0A = PCI_BASE_ADDRESS_MEM_TYPE_64 )=0A@@ -458,23 +459,24 @@ int pdev_type(u16 = seg, u8 bus, u8 devfn)=0A int pos;=0A u8 d =3D PCI_SLOT(devfn), f = =3D PCI_FUNC(devfn);=0A =0A- class_device =3D pci_conf_read16(bus, d, = f, PCI_CLASS_DEVICE);=0A+ class_device =3D pci_conf_read16(seg, bus, d, = f, PCI_CLASS_DEVICE);=0A if ( class_device =3D=3D PCI_CLASS_BRIDGE_PCI = )=0A {=0A- pos =3D pci_find_next_cap(bus, devfn,=0A+ pos = =3D pci_find_next_cap(seg, bus, devfn,=0A = PCI_CAPABILITY_LIST, PCI_CAP_ID_EXP);=0A if ( !pos )=0A = return DEV_TYPE_LEGACY_PCI_BRIDGE;=0A- creg =3D pci_conf_read16(bus= , d, f, pos + PCI_EXP_FLAGS);=0A+ creg =3D pci_conf_read16(seg, = bus, d, f, pos + PCI_EXP_FLAGS);=0A return ((creg & PCI_EXP_FLAGS_T= YPE) >> 4) =3D=3D PCI_EXP_TYPE_PCI_BRIDGE ?=0A DEV_TYPE_PCIe2PC= I_BRIDGE : DEV_TYPE_PCIe_BRIDGE;=0A }=0A =0A- status =3D pci_conf_re= ad16(bus, d, f, PCI_STATUS);=0A+ status =3D pci_conf_read16(seg, bus, = d, f, PCI_STATUS);=0A if ( !(status & PCI_STATUS_CAP_LIST) )=0A = return DEV_TYPE_PCI;=0A =0A- if ( pci_find_next_cap(bus, devfn, = PCI_CAPABILITY_LIST, PCI_CAP_ID_EXP) )=0A+ if ( pci_find_next_cap(seg, = bus, devfn, PCI_CAPABILITY_LIST,=0A+ PCI_CAP_ID_E= XP) )=0A return DEV_TYPE_PCIe_ENDPOINT;=0A =0A return = DEV_TYPE_PCI;=0A@@ -527,7 +529,7 @@ int __init pci_device_detect(u16 seg, = u8=0A {=0A u32 vendor;=0A =0A- vendor =3D pci_conf_read32(bus, dev, = func, PCI_VENDOR_ID);=0A+ vendor =3D pci_conf_read32(seg, bus, dev, = func, PCI_VENDOR_ID);=0A /* some broken boards return 0 or ~0 if a = slot is empty: */=0A if ( (vendor =3D=3D 0xffffffff) || (vendor =3D=3D = 0x00000000) ||=0A (vendor =3D=3D 0x0000ffff) || (vendor =3D=3D = 0xffff0000) )=0A@@ -571,9 +573,9 @@ static int __init _scan_pci_devices(str= u=0A =0A case DEV_TYPE_PCIe2PCI_BRIDGE:=0A = case DEV_TYPE_LEGACY_PCI_BRIDGE:=0A- = sec_bus =3D pci_conf_read8(bus, dev, func,=0A+ = sec_bus =3D pci_conf_read8(pseg->nr, bus, dev, func,=0A = PCI_SECONDARY_BUS);=0A- = sub_bus =3D pci_conf_read8(bus, dev, func,=0A+ = sub_bus =3D pci_conf_read8(pseg->nr, bus, dev, func,=0A = PCI_SUBORDINATE_BUS);=0A =0A = spin_lock(&pseg->bus2bridge_lock);=0A@@ -597,7 +599,7 @@ static = int __init _scan_pci_devices(stru=0A return = -EINVAL;=0A }=0A =0A- if ( !func && = !(pci_conf_read8(bus, dev, func,=0A+ if ( !func && = !(pci_conf_read8(pseg->nr, bus, dev, func,=0A = PCI_HEADER_TYPE) & 0x80) )=0A = break;=0A }=0A@@ -667,7 +669,7 @@ static int _disconnect_pci_de= vices(struc=0A struct pci_dev *pdev;=0A =0A list_for_each_entry ( = pdev, &pseg->alldevs_list, alldevs_list )=0A- pci_conf_write16(pdev-= >bus, PCI_SLOT(pdev->devfn),=0A+ pci_conf_write16(pseg->nr, = pdev->bus, PCI_SLOT(pdev->devfn),=0A PCI_FUNC(pdev= ->devfn), PCI_COMMAND, 0);=0A =0A return 0;=0A--- 2011-09-20.orig/xen/d= rivers/passthrough/vtd/dmar.c 2011-08-25 15:12:12.000000000 +0200=0A+++ = 2011-09-20/xen/drivers/passthrough/vtd/dmar.c 2011-08-25 15:13:05.0000000= 00 +0200=0A@@ -307,17 +307,18 @@ static int __init acpi_parse_dev_scope(=0A= =0A while ( --depth > 0 )=0A {=0A- bus =3D = pci_conf_read8(bus, path->dev, path->fn, PCI_SECONDARY_BUS);=0A+ = bus =3D pci_conf_read8(seg, bus, path->dev, path->fn,=0A+ = PCI_SECONDARY_BUS);=0A path++;=0A }=0A = =0A switch ( acpi_scope->dev_type )=0A {=0A case = ACPI_DEV_P2PBRIDGE:=0A- sec_bus =3D pci_conf_read8(=0A- = bus, path->dev, path->fn, PCI_SECONDARY_BUS);=0A- = sub_bus =3D pci_conf_read8(=0A- bus, path->dev, path->fn, = PCI_SUBORDINATE_BUS);=0A+ sec_bus =3D pci_conf_read8(seg, bus, = path->dev, path->fn,=0A+ PCI_SECONDARY_= BUS);=0A+ sub_bus =3D pci_conf_read8(seg, bus, path->dev, = path->fn,=0A+ PCI_SUBORDINATE_BUS);=0A = if ( iommu_verbose )=0A dprintk(VTDPREFIX,=0A = " bridge: %04x:%02x:%02x.%u start=3D%x sec=3D%x = sub=3D%x\n",=0A--- 2011-09-20.orig/xen/drivers/passthrough/vtd/iommu.c = 2011-09-20 16:06:42.000000000 +0200=0A+++ 2011-09-20/xen/drivers/passthroug= h/vtd/iommu.c 2011-09-20 16:06:48.000000000 +0200=0A@@ -941,11 +941,12 = @@ static void iommu_page_fault(int irq, vo=0A =0A /* Tell the = device to stop DMAing; we can't rely on the guest to=0A * control = it for us. */=0A- cword =3D pci_conf_read16(PCI_BUS(source_id), = PCI_SLOT(source_id), =0A+ cword =3D pci_conf_read16(iommu->intel->dr= hd->segment,=0A+ PCI_BUS(source_id), = PCI_SLOT(source_id),=0A PCI_FUNC(source_id)= , PCI_COMMAND);=0A- pci_conf_write16(PCI_BUS(source_id), PCI_SLOT(so= urce_id), =0A- PCI_FUNC(source_id), PCI_COMMAND, = =0A- cword & ~PCI_COMMAND_MASTER);=0A+ = pci_conf_write16(iommu->intel->drhd->segment, PCI_BUS(source_id),=0A+ = PCI_SLOT(source_id), PCI_FUNC(source_id),=0A+ = PCI_COMMAND, cword & ~PCI_COMMAND_MASTER);=0A =0A = fault_index++;=0A if ( fault_index > cap_num_fault_regs(iommu->cap)= )=0A--- 2011-09-20.orig/xen/drivers/passthrough/vtd/quirks.c 2011-08-25 = 15:06:35.000000000 +0200=0A+++ 2011-09-20/xen/drivers/passthrough/vtd/quirk= s.c 2011-08-25 15:13:05.000000000 +0200=0A@@ -70,7 +70,7 @@ int = is_igd_vt_enabled_quirk(void)=0A return 1;=0A =0A /* integrated= graphics on Intel platforms is located at 0:2.0 */=0A- ggc =3D = pci_conf_read16(0, IGD_DEV, 0, GGC);=0A+ ggc =3D pci_conf_read16(0, 0, = IGD_DEV, 0, GGC);=0A return ( ggc & GGC_MEMORY_VT_ENABLED ? 1 : 0 = );=0A }=0A =0A@@ -84,12 +84,12 @@ static void __init cantiga_b3_errata_ini= =0A u16 vid;=0A u8 did_hi, rid;=0A =0A- vid =3D pci_conf_read16(= 0, IGD_DEV, 0, 0);=0A+ vid =3D pci_conf_read16(0, 0, IGD_DEV, 0, 0);=0A = if ( vid !=3D 0x8086 )=0A return;=0A =0A- did_hi =3D = pci_conf_read8(0, IGD_DEV, 0, 3);=0A- rid =3D pci_conf_read8(0, = IGD_DEV, 0, 8);=0A+ did_hi =3D pci_conf_read8(0, 0, IGD_DEV, 0, 3);=0A+ = rid =3D pci_conf_read8(0, 0, IGD_DEV, 0, 8);=0A =0A if ( (did_hi = =3D=3D 0x2A) && (rid =3D=3D 0x7) )=0A is_cantiga_b3 =3D 1;=0A@@ = -125,8 +125,8 @@ static void __init map_igd_reg(void)=0A return;=0A= =0A /* get IGD mmio address in PCI BAR */=0A- igd_mmio =3D = ((u64)pci_conf_read32(0, IGD_DEV, 0, 0x14) << 32) +=0A- = pci_conf_read32(0, IGD_DEV, 0, 0x10);=0A+ igd_mmio =3D ((u64)pci_conf_r= ead32(0, 0, IGD_DEV, 0, 0x14) << 32) +=0A+ pci_conf_rea= d32(0, 0, IGD_DEV, 0, 0x10);=0A =0A /* offset of IGD regster we want = to access is in 0x2000 range */=0A igd_reg =3D (igd_mmio & IGD_BAR_MASK= ) + 0x2000;=0A@@ -251,8 +251,8 @@ void vtd_ops_postamble_quirk(struct = iomm=0A /* initialize platform identification flags */=0A void __init = platform_quirks_init(void)=0A {=0A- ioh_id =3D pci_conf_read32(0, = IOH_DEV, 0, 0);=0A- igd_id =3D pci_conf_read32(0, IGD_DEV, 0, 0);=0A+ = ioh_id =3D pci_conf_read32(0, 0, IOH_DEV, 0, 0);=0A+ igd_id =3D = pci_conf_read32(0, 0, IGD_DEV, 0, 0);=0A =0A /* Mobile 4 Series = Chipset neglects to set RWBF capability. */=0A if ( ioh_id =3D=3D = 0x2a408086 )=0A@@ -302,15 +302,15 @@ void me_wifi_quirk(struct domain = *domain=0A {=0A u32 id;=0A =0A- id =3D pci_conf_read32(0, 0, 0, = 0);=0A+ id =3D pci_conf_read32(0, 0, 0, 0, 0);=0A if ( IS_CTG(id) = )=0A {=0A /* quit if ME does not exist */=0A- if ( = pci_conf_read32(0, 3, 0, 0) =3D=3D 0xffffffff )=0A+ if ( pci_conf_re= ad32(0, 0, 3, 0, 0) =3D=3D 0xffffffff )=0A return;=0A =0A = /* if device is WLAN device, map ME phantom device 0:3.7 */=0A- = id =3D pci_conf_read32(bus, PCI_SLOT(devfn), PCI_FUNC(devfn), 0);=0A+ = id =3D pci_conf_read32(0, bus, PCI_SLOT(devfn), PCI_FUNC(devfn), 0);=0A = switch (id)=0A {=0A case 0x42328086:=0A@@ = -330,11 +330,11 @@ void me_wifi_quirk(struct domain *domain=0A else if = ( IS_ILK(id) || IS_CPT(id) )=0A {=0A /* quit if ME does not = exist */=0A- if ( pci_conf_read32(0, 22, 0, 0) =3D=3D 0xffffffff = )=0A+ if ( pci_conf_read32(0, 0, 22, 0, 0) =3D=3D 0xffffffff )=0A = return;=0A =0A /* if device is WLAN device, map ME = phantom device 0:22.7 */=0A- id =3D pci_conf_read32(bus, PCI_SLOT(de= vfn), PCI_FUNC(devfn), 0);=0A+ id =3D pci_conf_read32(0, bus, = PCI_SLOT(devfn), PCI_FUNC(devfn), 0);=0A switch (id)=0A = {=0A case 0x00878086: /* Kilmer Peak */=0A@@ -364,16 = +364,17 @@ void me_wifi_quirk(struct domain *domain=0A void __init = pci_vtd_quirk(struct pci_dev *pdev)=0A {=0A #ifdef CONFIG_X86_64=0A+ = int seg =3D pdev->seg;=0A int bus =3D pdev->bus;=0A int dev =3D = PCI_SLOT(pdev->devfn);=0A int func =3D PCI_FUNC(pdev->devfn);=0A = int id, val;=0A =0A- id =3D pci_conf_read32(bus, dev, func, 0);=0A+ = id =3D pci_conf_read32(seg, bus, dev, func, 0);=0A if ( id =3D=3D = 0x342e8086 || id =3D=3D 0x3c288086 )=0A {=0A- val =3D pci_conf_r= ead32(bus, dev, func, 0x1AC);=0A- pci_conf_write32(bus, dev, func, = 0x1AC, val | (1 << 31));=0A+ val =3D pci_conf_read32(seg, bus, dev, = func, 0x1AC);=0A+ pci_conf_write32(seg, bus, dev, func, 0x1AC, val = | (1 << 31));=0A }=0A #endif=0A }=0A--- 2011-09-20.orig/xen/drivers/pas= sthrough/vtd/utils.c 2011-08-25 15:06:43.000000000 +0200=0A+++ = 2011-09-20/xen/drivers/passthrough/vtd/utils.c 2011-08-25 15:13:05.0000000= 00 +0200=0A@@ -34,7 +34,7 @@=0A =0A int is_usb_device(u16 seg, u8 bus, u8 = devfn)=0A {=0A- u16 class =3D pci_conf_read16(bus, PCI_SLOT(devfn), = PCI_FUNC(devfn),=0A+ u16 class =3D pci_conf_read16(seg, bus, PCI_SLOT(de= vfn), PCI_FUNC(devfn),=0A PCI_CLASS_DEVICE)= ;=0A return (class =3D=3D 0xc03);=0A }=0A--- 2011-09-20.orig/xen/driver= s/passthrough/vtd/x86/ats.c 2011-08-25 15:06:43.000000000 +0200=0A+++ = 2011-09-20/xen/drivers/passthrough/vtd/x86/ats.c 2011-08-25 = 15:13:05.000000000 +0200=0A@@ -135,8 +135,7 @@ int enable_ats_device(int = seg, int bus, =0A "%04x:%02x:%02x.%u: ATS capability = found\n",=0A seg, bus, PCI_SLOT(devfn), PCI_FUNC(devfn));= =0A =0A- /* BUGBUG: add back seg when multi-seg platform support is = enabled */=0A- value =3D pci_conf_read16(bus, PCI_SLOT(devfn),=0A+ = value =3D pci_conf_read16(seg, bus, PCI_SLOT(devfn),=0A = PCI_FUNC(devfn), pos + ATS_REG_CTL);=0A if ( value & = ATS_ENABLE )=0A {=0A@@ -157,7 +156,7 @@ int enable_ats_device(int seg, = int bus, =0A if ( !(value & ATS_ENABLE) )=0A {=0A value = |=3D ATS_ENABLE;=0A- pci_conf_write16(bus, PCI_SLOT(devfn), = PCI_FUNC(devfn),=0A+ pci_conf_write16(seg, bus, PCI_SLOT(devfn), = PCI_FUNC(devfn),=0A pos + ATS_REG_CTL, value);=0A = }=0A =0A@@ -166,7 +165,7 @@ int enable_ats_device(int seg, int bus, = =0A pdev->seg =3D seg;=0A pdev->bus =3D bus;=0A = pdev->devfn =3D devfn;=0A- value =3D pci_conf_read16(bus, PCI_SLOT(d= evfn),=0A+ value =3D pci_conf_read16(seg, bus, PCI_SLOT(devfn),=0A = PCI_FUNC(devfn), pos + ATS_REG_CAP);=0A = pdev->ats_queue_depth =3D value & ATS_QUEUE_DEPTH_MASK;=0A = list_add(&pdev->list, &ats_devices);=0A@@ -190,11 +189,10 @@ void = disable_ats_device(int seg, int bus=0A pos =3D pci_find_ext_capability(= seg, bus, devfn, PCI_EXT_CAP_ID_ATS);=0A BUG_ON(!pos);=0A =0A- /* = BUGBUG: add back seg when multi-seg platform support is enabled */=0A- = value =3D pci_conf_read16(bus, PCI_SLOT(devfn),=0A+ value =3D pci_conf_r= ead16(seg, bus, PCI_SLOT(devfn),=0A PCI_FUNC(de= vfn), pos + ATS_REG_CTL);=0A value &=3D ~ATS_ENABLE;=0A- pci_conf_wr= ite16(bus, PCI_SLOT(devfn), PCI_FUNC(devfn),=0A+ pci_conf_write16(seg, = bus, PCI_SLOT(devfn), PCI_FUNC(devfn),=0A pos + = ATS_REG_CTL, value);=0A =0A list_for_each_entry ( pdev, &ats_devices, = list )=0A--- 2011-09-20.orig/xen/drivers/pci/pci.c 2008-10-13 = 13:36:27.000000000 +0200=0A+++ 2011-09-20/xen/drivers/pci/pci.c 2011-08-25 = 15:13:05.000000000 +0200=0A@@ -7,25 +7,25 @@=0A #include <xen/pci.h>=0A = #include <xen/pci_regs.h>=0A =0A-int pci_find_cap_offset(u8 bus, u8 dev, = u8 func, u8 cap)=0A+int pci_find_cap_offset(u16 seg, u8 bus, u8 dev, u8 = func, u8 cap)=0A {=0A u8 id;=0A int max_cap =3D 48;=0A u8 pos = =3D PCI_CAPABILITY_LIST;=0A u16 status;=0A =0A- status =3D = pci_conf_read16(bus, dev, func, PCI_STATUS);=0A+ status =3D pci_conf_rea= d16(seg, bus, dev, func, PCI_STATUS);=0A if ( (status & PCI_STATUS_CAP_= LIST) =3D=3D 0 )=0A return 0;=0A =0A while ( max_cap-- )=0A = {=0A- pos =3D pci_conf_read8(bus, dev, func, pos);=0A+ pos = =3D pci_conf_read8(seg, bus, dev, func, pos);=0A if ( pos < 0x40 = )=0A break;=0A =0A pos &=3D ~3;=0A- id =3D = pci_conf_read8(bus, dev, func, pos + PCI_CAP_LIST_ID);=0A+ id =3D = pci_conf_read8(seg, bus, dev, func, pos + PCI_CAP_LIST_ID);=0A =0A = if ( id =3D=3D 0xff )=0A break;=0A@@ -38,19 +38,19 @@ int = pci_find_cap_offset(u8 bus, u8 dev, =0A return 0;=0A }=0A =0A-int = pci_find_next_cap(u8 bus, unsigned int devfn, u8 pos, int cap)=0A+int = pci_find_next_cap(u16 seg, u8 bus, unsigned int devfn, u8 pos, int cap)=0A = {=0A u8 id;=0A int ttl =3D 48;=0A =0A while ( ttl-- )=0A = {=0A- pos =3D pci_conf_read8(bus, PCI_SLOT(devfn), PCI_FUNC(devfn), = pos);=0A+ pos =3D pci_conf_read8(seg, bus, PCI_SLOT(devfn), = PCI_FUNC(devfn), pos);=0A if ( pos < 0x40 )=0A = break;=0A =0A pos &=3D ~3;=0A- id =3D pci_conf_read8(bus, = PCI_SLOT(devfn), PCI_FUNC(devfn),=0A+ id =3D pci_conf_read8(seg, = bus, PCI_SLOT(devfn), PCI_FUNC(devfn),=0A pos = + PCI_CAP_LIST_ID);=0A =0A if ( id =3D=3D 0xff )=0A--- 2011-09-20.o= rig/xen/include/xen/pci.h 2011-08-25 15:12:12.000000000 +0200=0A+++ = 2011-09-20/xen/include/xen/pci.h 2011-08-25 15:13:05.000000000 = +0200=0A@@ -102,28 +102,31 @@ struct pci_dev *pci_get_pdev_by_domain(=0A = void disconnect_pci_devices(void);=0A =0A uint8_t pci_conf_read8(=0A- = unsigned int bus, unsigned int dev, unsigned int func, unsigned int = reg);=0A+ unsigned int seg, unsigned int bus, unsigned int dev, = unsigned int func,=0A+ unsigned int reg);=0A uint16_t pci_conf_read16(= =0A- unsigned int bus, unsigned int dev, unsigned int func, unsigned = int reg);=0A+ unsigned int seg, unsigned int bus, unsigned int dev, = unsigned int func,=0A+ unsigned int reg);=0A uint32_t pci_conf_read32(= =0A- unsigned int bus, unsigned int dev, unsigned int func, unsigned = int reg);=0A+ unsigned int seg, unsigned int bus, unsigned int dev, = unsigned int func,=0A+ unsigned int reg);=0A void pci_conf_write8(=0A- = unsigned int bus, unsigned int dev, unsigned int func, unsigned int = reg,=0A- uint8_t data);=0A+ unsigned int seg, unsigned int bus, = unsigned int dev, unsigned int func,=0A+ unsigned int reg, uint8_t = data);=0A void pci_conf_write16(=0A- unsigned int bus, unsigned int = dev, unsigned int func, unsigned int reg,=0A- uint16_t data);=0A+ = unsigned int seg, unsigned int bus, unsigned int dev, unsigned int = func,=0A+ unsigned int reg, uint16_t data);=0A void pci_conf_write32(=0A= - unsigned int bus, unsigned int dev, unsigned int func, unsigned int = reg,=0A- uint32_t data);=0A+ unsigned int seg, unsigned int bus, = unsigned int dev, unsigned int func,=0A+ unsigned int reg, uint32_t = data);=0A uint32_t pci_conf_read(uint32_t cf8, uint8_t offset, uint8_t = bytes);=0A void pci_conf_write(uint32_t cf8, uint8_t offset, uint8_t = bytes, uint32_t data);=0A int pci_mmcfg_read(unsigned int seg, unsigned = int bus,=0A unsigned int devfn, int reg, int len, u32 = *value);=0A int pci_mmcfg_write(unsigned int seg, unsigned int bus,=0A = unsigned int devfn, int reg, int len, u32 value);=0A-int = pci_find_cap_offset(u8 bus, u8 dev, u8 func, u8 cap);=0A-int pci_find_next_= cap(u8 bus, unsigned int devfn, u8 pos, int cap);=0A+int pci_find_cap_offse= t(u16 seg, u8 bus, u8 dev, u8 func, u8 cap);=0A+int pci_find_next_cap(u16 = seg, u8 bus, unsigned int devfn, u8 pos, int cap);=0A int pci_find_ext_capa= bility(int seg, int bus, int devfn, int cap);=0A =0A struct pirq;=0A --=__PartDAF5E12B.0__= Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel --=__PartDAF5E12B.0__=-- From xen-devel-bounces@lists.xensource.com Tue Sep 20 08:42:13 2011 Return-path: <xen-devel-bounces@lists.xensource.com> Envelope-to: www-data@lists.xensource.com Delivery-date: Tue, 20 Sep 2011 08:42:13 -0700 Received: from localhost ([127.0.0.1] helo=lists.colo.xensource.com) by lists.xensource.com with esmtp (Exim 4.43) id 1R62Sb-0003nG-LW; Tue, 20 Sep 2011 08:42:13 -0700 Received: from mail27.messagelabs.com ([193.109.254.147]) by lists.xensource.com with esmtp (Exim 4.43) id 1R62Rt-0003Zp-Ur for xen-devel@lists.xensource.com; Tue, 20 Sep 2011 08:41:30 -0700 X-Env-Sender: JBeulich@suse.com X-Msg-Ref: server-2.tower-27.messagelabs.com!1316533262!55749014!1 X-Originating-IP: [130.57.49.28] X-StarScan-Version: 6.4.1; banners=-,-,- X-VirusChecked: Checked Received: (qmail 31388 invoked from network); 20 Sep 2011 15:41:02 -0000 Received: from nat28.tlf.novell.com (HELO nat28.tlf.novell.com) (130.57.49.28) by server-2.tower-27.messagelabs.com with DHE-RSA-AES256-SHA encrypted SMTP; 20 Sep 2011 15:41:02 -0000 Received: from EMEA1-MTA by nat28.tlf.novell.com with Novell_GroupWise; Tue, 20 Sep 2011 16:41:26 +0100 Message-Id: <4E78D0600200007800056D81@nat28.tlf.novell.com> X-Mailer: Novell GroupWise Internet Agent 8.0.1 Date: Tue, 20 Sep 2011 16:41:52 +0100 From: "Jan Beulich" <JBeulich@suse.com> To: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com> Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: quoted-printable Content-Disposition: inline Subject: [Xen-devel] [PATCH 0/4] cpumask and IRQ handling changes X-BeenThere: xen-devel@lists.xensource.com X-Mailman-Version: 2.1.5 Precedence: list List-Id: Xen developer discussion <xen-devel.lists.xensource.com> List-Unsubscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe> List-Post: <mailto:xen-devel@lists.xensource.com> List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help> List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=subscribe> Sender: xen-devel-bounces@lists.xensource.com Errors-To: xen-devel-bounces@lists.xensource.com This is only a loosely connected set of patches (the single strong dependency is that they won't apply in any other order). 1: convert more literal uses of cpumask_t to pointers 2: pass struct irq_desc * to set_affinity() IRQ accessors 3: pass struct irq_desc * to all other IRQ accessors 4: x86: split MSI IRQ chip Signed-off-by: Jan Beulich <jbeulich@suse.com> _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel From xen-devel-bounces@lists.xensource.com Tue Sep 20 08:43:30 2011 Return-path: <xen-devel-bounces@lists.xensource.com> Envelope-to: www-data@lists.xensource.com Delivery-date: Tue, 20 Sep 2011 08:43:30 -0700 Received: from localhost ([127.0.0.1] helo=lists.colo.xensource.com) by lists.xensource.com with esmtp (Exim 4.43) id 1R62Tp-0004CJ-UX; Tue, 20 Sep 2011 08:43:29 -0700 Received: from mail27.messagelabs.com ([193.109.254.147]) by lists.xensource.com with esmtp (Exim 4.43) id 1R62Sh-0003oJ-JL for xen-devel@lists.xensource.com; Tue, 20 Sep 2011 08:42:20 -0700 X-Env-Sender: JBeulich@suse.com X-Msg-Ref: server-4.tower-27.messagelabs.com!1316533318!41055666!1 X-Originating-IP: [130.57.49.28] X-StarScan-Version: 6.4.1; banners=-,-,- X-VirusChecked: Checked Received: (qmail 25873 invoked from network); 20 Sep 2011 15:41:58 -0000 Received: from nat28.tlf.novell.com (HELO nat28.tlf.novell.com) (130.57.49.28) by server-4.tower-27.messagelabs.com with DHE-RSA-AES256-SHA encrypted SMTP; 20 Sep 2011 15:41:58 -0000 Received: from EMEA1-MTA by nat28.tlf.novell.com with Novell_GroupWise; Tue, 20 Sep 2011 16:42:16 +0100 Message-Id: <4E78D0920200007800056D85@nat28.tlf.novell.com> X-Mailer: Novell GroupWise Internet Agent 8.0.1 Date: Tue, 20 Sep 2011 16:42:42 +0100 From: "Jan Beulich" <JBeulich@suse.com> To: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com> Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="=__Part88A7B362.0__=" Subject: [Xen-devel] [PATCH 1/4] convert more literal uses of cpumask_t to pointers X-BeenThere: xen-devel@lists.xensource.com X-Mailman-Version: 2.1.5 Precedence: list List-Id: Xen developer discussion <xen-devel.lists.xensource.com> List-Unsubscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe> List-Post: <mailto:xen-devel@lists.xensource.com> List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help> List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=subscribe> Sender: xen-devel-bounces@lists.xensource.com Errors-To: xen-devel-bounces@lists.xensource.com This is a MIME message. If you are reading this text, you may want to consider changing to a mail reader or gateway that understands how to properly handle MIME multipart messages. --=__Part88A7B362.0__= Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: quoted-printable Content-Disposition: inline This is particularly relevant as the number of CPUs to be supported increases (as recently happened for the default thereof). Signed-off-by: Jan Beulich <jbeulich@suse.com> --- a/xen/arch/ia64/linux-xen/iosapic.c +++ b/xen/arch/ia64/linux-xen/iosapic.c @@ -352,7 +352,7 @@ unmask_irq (unsigned int irq) =20 =20 static void -iosapic_set_affinity (unsigned int irq, cpumask_t mask) +iosapic_set_affinity (unsigned int irq, const cpumask_t *mask) { #ifdef CONFIG_SMP unsigned long flags; @@ -366,10 +366,10 @@ iosapic_set_affinity (unsigned int irq,=20 irq &=3D (~IA64_IRQ_REDIRECTED); vec =3D irq_to_vector(irq); =20 - if (cpus_empty(mask)) + if (cpumask_empty(mask)) return; =20 - dest =3D cpu_physical_id(first_cpu(mask)); + dest =3D cpu_physical_id(cpumask_first(mask)); =20 if (list_empty(&iosapic_intr_info[vec].rtes)) return; /* not an IOSAPIC interrupt */ --- a/xen/arch/ia64/linux-xen/mca.c +++ b/xen/arch/ia64/linux-xen/mca.c @@ -1312,7 +1312,7 @@ ia64_mca_cmc_int_handler(int cmc_irq, vo #ifndef XEN /* XXX FIXME */ schedule_work(&cmc_disable_work); #else - cpumask_raise_softirq(cpu_online_map, + cpumask_raise_softirq(&cpu_online_map, CMC_DISABLE_SOFTIRQ); #endif =20 @@ -1383,7 +1383,7 @@ ia64_mca_cmc_int_caller(int cmc_irq, voi #ifndef XEN /* XXX FIXME */ schedule_work(&cmc_enable_work); #else - cpumask_raise_softirq(cpu_online_map, + cpumask_raise_softirq(&cpu_online_map, CMC_ENABLE_SOFTIRQ); #endif cmc_polling_enabled =3D 0; @@ -1904,7 +1904,7 @@ ia64_mca_late_init(void) #ifndef XEN /* XXX FIXME */ schedule_work(&cmc_enable_work); #else - cpumask_raise_softirq(cpu_online_map, CMC_ENABLE_SOFTIRQ); + cpumask_raise_softirq(&cpu_online_map, CMC_ENABLE_SOFTIRQ); #endif =20 IA64_MCA_DEBUG("%s: CMCI/P setup and enabled.\n", __FUNCTION__); --- a/xen/arch/x86/hpet.c +++ b/xen/arch/x86/hpet.c @@ -154,16 +154,16 @@ static int reprogram_hpet_evt_channel( return ret; } =20 -static void evt_do_broadcast(cpumask_t mask) +static void evt_do_broadcast(cpumask_t *mask) { unsigned int cpu =3D smp_processor_id(); =20 - if ( cpu_test_and_clear(cpu, mask) ) + if ( cpumask_test_and_clear_cpu(cpu, mask) ) raise_softirq(TIMER_SOFTIRQ); =20 - cpuidle_wakeup_mwait(&mask); + cpuidle_wakeup_mwait(mask); =20 - if ( !cpus_empty(mask) ) + if ( !cpumask_empty(mask) ) cpumask_raise_softirq(mask, TIMER_SOFTIRQ); } =20 @@ -202,7 +202,7 @@ again: } =20 /* wakeup the cpus which have an expired event. */ - evt_do_broadcast(mask); + evt_do_broadcast(&mask); =20 if ( next_event !=3D STIME_MAX ) { @@ -305,14 +305,14 @@ static void hpet_msi_end(unsigned int ir { } =20 -static void hpet_msi_set_affinity(unsigned int irq, cpumask_t mask) +static void hpet_msi_set_affinity(unsigned int irq, const cpumask_t = *mask) { struct msi_msg msg; unsigned int dest; struct irq_desc * desc =3D irq_to_desc(irq); struct irq_cfg *cfg=3D desc->chip_data; =20 - dest =3D set_desc_affinity(desc, &mask); + dest =3D set_desc_affinity(desc, mask); if (dest =3D=3D BAD_APICID) return; =20 @@ -471,9 +471,7 @@ static void hpet_attach_channel(unsigned if ( ch->cpu !=3D cpu ) return; =20 - /* set irq affinity */ - irq_desc[ch->irq].handler-> - set_affinity(ch->irq, cpumask_of_cpu(ch->cpu)); + hpet_msi_set_affinity(ch->irq, cpumask_of(ch->cpu)); } =20 static void hpet_detach_channel(unsigned int cpu, @@ -495,9 +493,7 @@ static void hpet_detach_channel(unsigned } =20 ch->cpu =3D first_cpu(ch->cpumask); - /* set irq affinity */ - irq_desc[ch->irq].handler-> - set_affinity(ch->irq, cpumask_of_cpu(ch->cpu)); + hpet_msi_set_affinity(ch->irq, cpumask_of(ch->cpu)); } =20 #include <asm/mc146818rtc.h> --- a/xen/arch/x86/io_apic.c +++ b/xen/arch/x86/io_apic.c @@ -697,13 +697,13 @@ set_ioapic_affinity_irq_desc(struct irq_ } =20 static void -set_ioapic_affinity_irq(unsigned int irq, const struct cpumask mask) +set_ioapic_affinity_irq(unsigned int irq, const struct cpumask *mask) { struct irq_desc *desc; =20 desc =3D irq_to_desc(irq); =20 - set_ioapic_affinity_irq_desc(desc, &mask); + set_ioapic_affinity_irq_desc(desc, mask); } #endif /* CONFIG_SMP */ =20 @@ -802,7 +802,7 @@ void /*__init*/ setup_ioapic_dest(void) irq =3D pin_2_irq(irq_entry, ioapic, pin); cfg =3D irq_cfg(irq); BUG_ON(cpus_empty(cfg->cpu_mask)); - set_ioapic_affinity_irq(irq, cfg->cpu_mask); + set_ioapic_affinity_irq(irq, &cfg->cpu_mask); } =20 } @@ -2063,7 +2063,7 @@ static void __init check_timer(void) vector =3D FIRST_HIPRIORITY_VECTOR; clear_irq_vector(0); =20 - if ((ret =3D bind_irq_vector(0, vector, mask_all))) + if ((ret =3D bind_irq_vector(0, vector, &mask_all))) printk(KERN_ERR"..IRQ0 is not set correctly with ioapic!!!, = err:%d\n", ret); =20 irq_desc[0].status &=3D ~IRQ_DISABLED; --- a/xen/arch/x86/irq.c +++ b/xen/arch/x86/irq.c @@ -108,7 +108,7 @@ static void trace_irq_mask(u32 event, in trace_var(event, 1, sizeof(d), &d); } =20 -static int __init __bind_irq_vector(int irq, int vector, cpumask_t = cpu_mask) +static int __init __bind_irq_vector(int irq, int vector, const cpumask_t = *cpu_mask) { cpumask_t online_mask; int cpu; @@ -117,7 +117,7 @@ static int __init __bind_irq_vector(int=20 BUG_ON((unsigned)irq >=3D nr_irqs); BUG_ON((unsigned)vector >=3D NR_VECTORS); =20 - cpus_and(online_mask, cpu_mask, cpu_online_map); + cpus_and(online_mask, *cpu_mask, cpu_online_map); if (cpus_empty(online_mask)) return -EINVAL; if ((cfg->vector =3D=3D vector) && cpus_equal(cfg->cpu_mask, = online_mask)) @@ -140,7 +140,7 @@ static int __init __bind_irq_vector(int=20 return 0; } =20 -int __init bind_irq_vector(int irq, int vector, cpumask_t cpu_mask) +int __init bind_irq_vector(int irq, int vector, const cpumask_t *cpu_mask)= { unsigned long flags; int ret; @@ -582,7 +582,7 @@ void move_masked_irq(int irq) * For correct operation this depends on the caller masking the irqs. */ if (likely(cpus_intersects(desc->pending_mask, cpu_online_map))) - desc->handler->set_affinity(irq, desc->pending_mask); + desc->handler->set_affinity(irq, &desc->pending_mask); =20 cpus_clear(desc->pending_mask); } @@ -1409,7 +1409,7 @@ int pirq_guest_bind(struct vcpu *v, stru /* Attempt to bind the interrupt target to the correct CPU. */ cpu_set(v->processor, cpumask); if ( !opt_noirqbalance && (desc->handler->set_affinity !=3D NULL) = ) - desc->handler->set_affinity(irq, cpumask); + desc->handler->set_affinity(irq, &cpumask); } else if ( !will_share || !action->shareable ) { @@ -1963,7 +1963,7 @@ void fixup_irqs(void) desc->handler->disable(irq); =20 if ( desc->handler->set_affinity ) - desc->handler->set_affinity(irq, affinity); + desc->handler->set_affinity(irq, &affinity); else if ( !(warned++) ) set_affinity =3D 0; =20 --- a/xen/arch/x86/msi.c +++ b/xen/arch/x86/msi.c @@ -266,7 +266,7 @@ static void write_msi_msg(struct msi_des } } =20 -void set_msi_affinity(unsigned int irq, cpumask_t mask) +void set_msi_affinity(unsigned int irq, const cpumask_t *mask) { struct msi_msg msg; unsigned int dest; @@ -274,7 +274,7 @@ void set_msi_affinity(unsigned int irq,=20 struct msi_desc *msi_desc =3D desc->msi_desc; struct irq_cfg *cfg =3D desc->chip_data; =20 - dest =3D set_desc_affinity(desc, &mask); + dest =3D set_desc_affinity(desc, mask); if (dest =3D=3D BAD_APICID || !msi_desc) return; =20 --- a/xen/arch/x86/time.c +++ b/xen/arch/x86/time.c @@ -195,7 +195,7 @@ static void smp_send_timer_broadcast_ipi =20 if ( !cpus_empty(mask) ) { - cpumask_raise_softirq(mask, TIMER_SOFTIRQ); + cpumask_raise_softirq(&mask, TIMER_SOFTIRQ); } } =20 --- a/xen/common/keyhandler.c +++ b/xen/common/keyhandler.c @@ -207,10 +207,10 @@ static struct keyhandler reboot_machine_ .desc =3D "reboot machine" }; =20 -static void cpuset_print(char *set, int size, cpumask_t mask) +static void cpuset_print(char *set, int size, const cpumask_t *mask) { *set++ =3D '{'; - set +=3D cpulist_scnprintf(set, size-2, mask); + set +=3D cpulist_scnprintf(set, size-2, *mask); *set++ =3D '}'; *set++ =3D '\0'; } @@ -244,7 +244,7 @@ static void dump_domains(unsigned char k { unsigned int i; printk("General information for domain %u:\n", d->domain_id); - cpuset_print(tmpstr, sizeof(tmpstr), *d->domain_dirty_cpumask); + cpuset_print(tmpstr, sizeof(tmpstr), d->domain_dirty_cpumask); printk(" refcnt=3D%d dying=3D%d nr_pages=3D%d xenheap_pages=3D%= d " "dirty_cpus=3D%s max_pages=3D%u\n", atomic_read(&d->refcnt), d->is_dying, @@ -278,9 +278,9 @@ static void dump_domains(unsigned char k v->pause_flags, v->poll_evtchn, vcpu_info(v, evtchn_upcall_pending), vcpu_info(v, evtchn_upcall_mask)); - cpuset_print(tmpstr, sizeof(tmpstr), *v->vcpu_dirty_cpumask); + cpuset_print(tmpstr, sizeof(tmpstr), v->vcpu_dirty_cpumask); printk("dirty_cpus=3D%s ", tmpstr); - cpuset_print(tmpstr, sizeof(tmpstr), *v->cpu_affinity); + cpuset_print(tmpstr, sizeof(tmpstr), v->cpu_affinity); printk("cpu_affinity=3D%s\n", tmpstr); arch_dump_vcpu_info(v); periodic_timer_print(tmpstr, sizeof(tmpstr), v->periodic_perio= d); --- a/xen/common/rcupdate.c +++ b/xen/common/rcupdate.c @@ -117,7 +117,7 @@ static void force_quiescent_state(struct */ cpumask =3D rcp->cpumask; cpu_clear(rdp->cpu, cpumask); - cpumask_raise_softirq(cpumask, SCHEDULE_SOFTIRQ); + cpumask_raise_softirq(&cpumask, SCHEDULE_SOFTIRQ); } } =20 --- a/xen/common/sched_credit.c +++ b/xen/common/sched_credit.c @@ -310,7 +310,7 @@ __runq_tickle(unsigned int cpu, struct c =20 /* Send scheduler interrupts to designated CPUs */ if ( !cpus_empty(mask) ) - cpumask_raise_softirq(mask, SCHEDULE_SOFTIRQ); + cpumask_raise_softirq(&mask, SCHEDULE_SOFTIRQ); } =20 static void --- a/xen/common/softirq.c +++ b/xen/common/softirq.c @@ -68,15 +68,16 @@ void open_softirq(int nr, softirq_handle softirq_handlers[nr] =3D handler; } =20 -void cpumask_raise_softirq(cpumask_t mask, unsigned int nr) +void cpumask_raise_softirq(const cpumask_t *mask, unsigned int nr) { int cpu; + cpumask_t send_mask =3D CPU_MASK_NONE; =20 - for_each_cpu_mask(cpu, mask) - if ( test_and_set_bit(nr, &softirq_pending(cpu)) ) - cpu_clear(cpu, mask); + for_each_cpu_mask(cpu, *mask) + if ( !test_and_set_bit(nr, &softirq_pending(cpu)) ) + cpu_set(cpu, send_mask); =20 - smp_send_event_check_mask(&mask); + smp_send_event_check_mask(&send_mask); } =20 void cpu_raise_softirq(unsigned int cpu, unsigned int nr) --- a/xen/drivers/passthrough/amd/iommu_init.c +++ b/xen/drivers/passthrough/amd/iommu_init.c @@ -344,7 +344,7 @@ static void amd_iommu_reset_event_log(st set_iommu_event_log_control(iommu, IOMMU_CONTROL_ENABLED); } =20 -static void iommu_msi_set_affinity(unsigned int irq, cpumask_t mask) +static void iommu_msi_set_affinity(unsigned int irq, const cpumask_t = *mask) { struct msi_msg msg; unsigned int dest; @@ -355,7 +355,7 @@ static void iommu_msi_set_affinity(unsig u8 dev =3D PCI_SLOT(iommu->bdf & 0xff); u8 func =3D PCI_FUNC(iommu->bdf & 0xff); =20 - dest =3D set_desc_affinity(desc, &mask); + dest =3D set_desc_affinity(desc, mask); =20 if ( dest =3D=3D BAD_APICID ) { @@ -591,7 +591,7 @@ static void enable_iommu(struct amd_iomm register_iommu_event_log_in_mmio_space(iommu); register_iommu_exclusion_range(iommu); =20 - iommu_msi_set_affinity(iommu->irq, cpu_online_map); + iommu_msi_set_affinity(iommu->irq, &cpu_online_map); amd_iommu_msi_enable(iommu, IOMMU_CONTROL_ENABLED); =20 set_iommu_command_buffer_control(iommu, IOMMU_CONTROL_ENABLED); --- a/xen/drivers/passthrough/vtd/iommu.c +++ b/xen/drivers/passthrough/vtd/iommu.c @@ -998,7 +998,7 @@ static void dma_msi_end(unsigned int irq ack_APIC_irq(); } =20 -static void dma_msi_set_affinity(unsigned int irq, cpumask_t mask) +static void dma_msi_set_affinity(unsigned int irq, const cpumask_t *mask) { struct msi_msg msg; unsigned int dest; @@ -1009,7 +1009,7 @@ static void dma_msi_set_affinity(unsigne struct irq_cfg *cfg =3D desc->chip_data; =20 #ifdef CONFIG_X86 - dest =3D set_desc_affinity(desc, &mask); + dest =3D set_desc_affinity(desc, mask); if (dest =3D=3D BAD_APICID){ dprintk(XENLOG_ERR VTDPREFIX, "Set iommu interrupt affinity = error!\n"); return; @@ -1984,7 +1984,7 @@ static int init_vtd_hw(void) iommu =3D drhd->iommu; =20 cfg =3D irq_cfg(iommu->irq); - dma_msi_set_affinity(iommu->irq, cfg->cpu_mask); + dma_msi_set_affinity(iommu->irq, &cfg->cpu_mask); =20 clear_fault_bits(iommu); =20 --- a/xen/include/asm-x86/irq.h +++ b/xen/include/asm-x86/irq.h @@ -176,7 +176,7 @@ void move_masked_irq(int irq); =20 int __assign_irq_vector(int irq, struct irq_cfg *, const cpumask_t *); =20 -int bind_irq_vector(int irq, int vector, cpumask_t domain); +int bind_irq_vector(int irq, int vector, const cpumask_t *); =20 void irq_set_affinity(struct irq_desc *, const cpumask_t *mask); =20 --- a/xen/include/asm-x86/msi.h +++ b/xen/include/asm-x86/msi.h @@ -77,7 +77,7 @@ struct msi_desc; /* Helper functions */ extern void mask_msi_irq(unsigned int irq); extern void unmask_msi_irq(unsigned int irq); -extern void set_msi_affinity(unsigned int vector, cpumask_t mask); +extern void set_msi_affinity(unsigned int vector, const cpumask_t *); extern int pci_enable_msi(struct msi_info *msi, struct msi_desc **desc); extern void pci_disable_msi(struct msi_desc *desc); extern void pci_cleanup_msi(struct pci_dev *pdev); --- a/xen/include/xen/irq.h +++ b/xen/include/xen/irq.h @@ -45,7 +45,7 @@ struct hw_interrupt_type { void (*disable)(unsigned int irq); void (*ack)(unsigned int irq); void (*end)(unsigned int irq, u8 vector); - void (*set_affinity)(unsigned int irq, cpumask_t mask); + void (*set_affinity)(unsigned int irq, const cpumask_t *); }; =20 typedef const struct hw_interrupt_type hw_irq_controller; @@ -176,11 +176,6 @@ static inline void set_native_irq_info(u irq_desc[irq].affinity =3D *mask; } =20 -static inline void set_irq_info(int irq, cpumask_t mask) -{ - set_native_irq_info(irq, &mask); -} - unsigned int set_desc_affinity(struct irq_desc *, const cpumask_t *); =20 #endif /* __XEN_IRQ_H__ */ --- a/xen/include/xen/softirq.h +++ b/xen/include/xen/softirq.h @@ -27,7 +27,7 @@ asmlinkage void do_softirq(void); void open_softirq(int nr, softirq_handler handler); void softirq_init(void); =20 -void cpumask_raise_softirq(cpumask_t mask, unsigned int nr); +void cpumask_raise_softirq(const cpumask_t *, unsigned int nr); void cpu_raise_softirq(unsigned int cpu, unsigned int nr); void raise_softirq(unsigned int nr); =20 --=__Part88A7B362.0__= Content-Type: text/plain; name="cpumask-pointer.patch" Content-Transfer-Encoding: quoted-printable Content-Disposition: attachment; filename="cpumask-pointer.patch" This is particularly relevant as the number of CPUs to be supported=0Aincre= ases (as recently happened for the default thereof).=0A=0ASigned-off-by: = Jan Beulich <jbeulich@suse.com>=0A=0A--- a/xen/arch/ia64/linux-xen/iosapic.= c=0A+++ b/xen/arch/ia64/linux-xen/iosapic.c=0A@@ -352,7 +352,7 @@ = unmask_irq (unsigned int irq)=0A =0A =0A static void=0A-iosapic_set_affinit= y (unsigned int irq, cpumask_t mask)=0A+iosapic_set_affinity (unsigned int = irq, const cpumask_t *mask)=0A {=0A #ifdef CONFIG_SMP=0A unsigned = long flags;=0A@@ -366,10 +366,10 @@ iosapic_set_affinity (unsigned int = irq, =0A irq &=3D (~IA64_IRQ_REDIRECTED);=0A vec =3D irq_to_vect= or(irq);=0A =0A- if (cpus_empty(mask))=0A+ if (cpumask_empty(m= ask))=0A return;=0A =0A- dest =3D cpu_physical_id(first_cpu(= mask));=0A+ dest =3D cpu_physical_id(cpumask_first(mask));=0A =0A if = (list_empty(&iosapic_intr_info[vec].rtes))=0A return; = /* not an IOSAPIC interrupt */=0A--- a/xen/arch/ia64/linux-xen/mca.c=0A+++ = b/xen/arch/ia64/linux-xen/mca.c=0A@@ -1312,7 +1312,7 @@ ia64_mca_cmc_int_ha= ndler(int cmc_irq, vo=0A #ifndef XEN /* XXX FIXME */=0A = schedule_work(&cmc_disable_work);=0A #else=0A- cpumask_rai= se_softirq(cpu_online_map,=0A+ cpumask_raise_softirq(&cpu_= online_map,=0A CMC_DISABLE_SOFTIRQ);= =0A #endif=0A =0A@@ -1383,7 +1383,7 @@ ia64_mca_cmc_int_caller(int = cmc_irq, voi=0A #ifndef XEN /* XXX FIXME */=0A = schedule_work(&cmc_enable_work);=0A #else=0A- cpumask_rai= se_softirq(cpu_online_map,=0A+ cpumask_raise_softirq(&cpu_= online_map,=0A CMC_ENABLE_SOFTIRQ);= =0A #endif=0A cmc_polling_enabled =3D 0;=0A@@ -1904,7 = +1904,7 @@ ia64_mca_late_init(void)=0A #ifndef XEN /* XXX FIXME */=0A = schedule_work(&cmc_enable_work);=0A #else=0A- cpumask_raise_softi= rq(cpu_online_map, CMC_ENABLE_SOFTIRQ);=0A+ cpumask_raise_softirq(&cpu_= online_map, CMC_ENABLE_SOFTIRQ);=0A #endif=0A =0A IA64_MCA_DEBUG("%s:= CMCI/P setup and enabled.\n", __FUNCTION__);=0A--- a/xen/arch/x86/hpet.c= =0A+++ b/xen/arch/x86/hpet.c=0A@@ -154,16 +154,16 @@ static int reprogram_h= pet_evt_channel(=0A return ret;=0A }=0A =0A-static void evt_do_broadcas= t(cpumask_t mask)=0A+static void evt_do_broadcast(cpumask_t *mask)=0A {=0A = unsigned int cpu =3D smp_processor_id();=0A =0A- if ( cpu_test_and_c= lear(cpu, mask) )=0A+ if ( cpumask_test_and_clear_cpu(cpu, mask) )=0A = raise_softirq(TIMER_SOFTIRQ);=0A =0A- cpuidle_wakeup_mwait(&mask);= =0A+ cpuidle_wakeup_mwait(mask);=0A =0A- if ( !cpus_empty(mask) = )=0A+ if ( !cpumask_empty(mask) )=0A cpumask_raise_softirq(mask, = TIMER_SOFTIRQ);=0A }=0A =0A@@ -202,7 +202,7 @@ again:=0A }=0A =0A = /* wakeup the cpus which have an expired event. */=0A- evt_do_broadcast(= mask);=0A+ evt_do_broadcast(&mask);=0A =0A if ( next_event !=3D = STIME_MAX )=0A {=0A@@ -305,14 +305,14 @@ static void hpet_msi_end(unsig= ned int ir=0A {=0A }=0A =0A-static void hpet_msi_set_affinity(unsigned int = irq, cpumask_t mask)=0A+static void hpet_msi_set_affinity(unsigned int = irq, const cpumask_t *mask)=0A {=0A struct msi_msg msg;=0A = unsigned int dest;=0A struct irq_desc * desc =3D irq_to_desc(irq);=0A = struct irq_cfg *cfg=3D desc->chip_data;=0A =0A- dest =3D set_desc_aff= inity(desc, &mask);=0A+ dest =3D set_desc_affinity(desc, mask);=0A = if (dest =3D=3D BAD_APICID)=0A return;=0A =0A@@ -471,9 +471,7 @@ = static void hpet_attach_channel(unsigned=0A if ( ch->cpu !=3D cpu )=0A = return;=0A =0A- /* set irq affinity */=0A- irq_desc[ch->irq].= handler->=0A- set_affinity(ch->irq, cpumask_of_cpu(ch->cpu));=0A+ = hpet_msi_set_affinity(ch->irq, cpumask_of(ch->cpu));=0A }=0A =0A static = void hpet_detach_channel(unsigned int cpu,=0A@@ -495,9 +493,7 @@ static = void hpet_detach_channel(unsigned=0A }=0A =0A ch->cpu =3D = first_cpu(ch->cpumask);=0A- /* set irq affinity */=0A- irq_desc[ch->i= rq].handler->=0A- set_affinity(ch->irq, cpumask_of_cpu(ch->cpu));=0A= + hpet_msi_set_affinity(ch->irq, cpumask_of(ch->cpu));=0A }=0A =0A = #include <asm/mc146818rtc.h>=0A--- a/xen/arch/x86/io_apic.c=0A+++ = b/xen/arch/x86/io_apic.c=0A@@ -697,13 +697,13 @@ set_ioapic_affinity_irq_de= sc(struct irq_=0A }=0A =0A static void=0A-set_ioapic_affinity_irq(unsigned = int irq, const struct cpumask mask)=0A+set_ioapic_affinity_irq(unsigned = int irq, const struct cpumask *mask)=0A {=0A struct irq_desc *desc;=0A = =0A desc =3D irq_to_desc(irq);=0A =0A- set_ioapic_affinity_irq_desc(= desc, &mask);=0A+ set_ioapic_affinity_irq_desc(desc, mask);=0A }=0A = #endif /* CONFIG_SMP */=0A =0A@@ -802,7 +802,7 @@ void /*__init*/ = setup_ioapic_dest(void)=0A irq =3D pin_2_irq(irq_entry, = ioapic, pin);=0A cfg =3D irq_cfg(irq);=0A = BUG_ON(cpus_empty(cfg->cpu_mask));=0A- set_ioapic_affinity_irq(i= rq, cfg->cpu_mask);=0A+ set_ioapic_affinity_irq(irq, &cfg->cpu_m= ask);=0A }=0A =0A }=0A@@ -2063,7 +2063,7 @@ static void __init = check_timer(void)=0A vector =3D FIRST_HIPRIORITY_VECTOR;=0A = clear_irq_vector(0);=0A =0A- if ((ret =3D bind_irq_vector(0, vector, = mask_all)))=0A+ if ((ret =3D bind_irq_vector(0, vector, &mask_all)))=0A = printk(KERN_ERR"..IRQ0 is not set correctly with ioapic!!!, = err:%d\n", ret);=0A =0A irq_desc[0].status &=3D ~IRQ_DISABLED;=0A--= - a/xen/arch/x86/irq.c=0A+++ b/xen/arch/x86/irq.c=0A@@ -108,7 +108,7 @@ = static void trace_irq_mask(u32 event, in=0A trace_var(event, 1, = sizeof(d), &d);=0A }=0A =0A-static int __init __bind_irq_vector(int irq, = int vector, cpumask_t cpu_mask)=0A+static int __init __bind_irq_vector(int = irq, int vector, const cpumask_t *cpu_mask)=0A {=0A cpumask_t = online_mask;=0A int cpu;=0A@@ -117,7 +117,7 @@ static int __init = __bind_irq_vector(int =0A BUG_ON((unsigned)irq >=3D nr_irqs);=0A = BUG_ON((unsigned)vector >=3D NR_VECTORS);=0A =0A- cpus_and(online_mask, = cpu_mask, cpu_online_map);=0A+ cpus_and(online_mask, *cpu_mask, = cpu_online_map);=0A if (cpus_empty(online_mask))=0A return = -EINVAL;=0A if ((cfg->vector =3D=3D vector) && cpus_equal(cfg->cpu_mask= , online_mask))=0A@@ -140,7 +140,7 @@ static int __init __bind_irq_vector(i= nt =0A return 0;=0A }=0A =0A-int __init bind_irq_vector(int irq, int = vector, cpumask_t cpu_mask)=0A+int __init bind_irq_vector(int irq, int = vector, const cpumask_t *cpu_mask)=0A {=0A unsigned long flags;=0A = int ret;=0A@@ -582,7 +582,7 @@ void move_masked_irq(int irq)=0A * For = correct operation this depends on the caller masking the irqs.=0A = */=0A if (likely(cpus_intersects(desc->pending_mask, cpu_online_map)))= =0A- desc->handler->set_affinity(irq, desc->pending_mask);=0A+ = desc->handler->set_affinity(irq, &desc->pending_mask);=0A =0A = cpus_clear(desc->pending_mask);=0A }=0A@@ -1409,7 +1409,7 @@ int pirq_guest= _bind(struct vcpu *v, stru=0A /* Attempt to bind the interrupt = target to the correct CPU. */=0A cpu_set(v->processor, cpumask);=0A= if ( !opt_noirqbalance && (desc->handler->set_affinity !=3D NULL) = )=0A- desc->handler->set_affinity(irq, cpumask);=0A+ = desc->handler->set_affinity(irq, &cpumask);=0A }=0A else if ( = !will_share || !action->shareable )=0A {=0A@@ -1963,7 +1963,7 @@ void = fixup_irqs(void)=0A desc->handler->disable(irq);=0A =0A = if ( desc->handler->set_affinity )=0A- desc->handler->set_affin= ity(irq, affinity);=0A+ desc->handler->set_affinity(irq, = &affinity);=0A else if ( !(warned++) )=0A set_affinity = =3D 0;=0A =0A--- a/xen/arch/x86/msi.c=0A+++ b/xen/arch/x86/msi.c=0A@@ = -266,7 +266,7 @@ static void write_msi_msg(struct msi_des=0A }=0A }=0A = =0A-void set_msi_affinity(unsigned int irq, cpumask_t mask)=0A+void = set_msi_affinity(unsigned int irq, const cpumask_t *mask)=0A {=0A = struct msi_msg msg;=0A unsigned int dest;=0A@@ -274,7 +274,7 @@ void = set_msi_affinity(unsigned int irq, =0A struct msi_desc *msi_desc =3D = desc->msi_desc;=0A struct irq_cfg *cfg =3D desc->chip_data;=0A =0A- = dest =3D set_desc_affinity(desc, &mask);=0A+ dest =3D set_desc_affinity(= desc, mask);=0A if (dest =3D=3D BAD_APICID || !msi_desc)=0A = return;=0A =0A--- a/xen/arch/x86/time.c=0A+++ b/xen/arch/x86/time.c=0A@@ = -195,7 +195,7 @@ static void smp_send_timer_broadcast_ipi=0A =0A if ( = !cpus_empty(mask) )=0A {=0A- cpumask_raise_softirq(mask, = TIMER_SOFTIRQ);=0A+ cpumask_raise_softirq(&mask, TIMER_SOFTIRQ);=0A = }=0A }=0A =0A--- a/xen/common/keyhandler.c=0A+++ b/xen/common/keyhandle= r.c=0A@@ -207,10 +207,10 @@ static struct keyhandler reboot_machine_=0A = .desc =3D "reboot machine"=0A };=0A =0A-static void cpuset_print(char = *set, int size, cpumask_t mask)=0A+static void cpuset_print(char *set, int = size, const cpumask_t *mask)=0A {=0A *set++ =3D '{';=0A- set +=3D = cpulist_scnprintf(set, size-2, mask);=0A+ set +=3D cpulist_scnprintf(set= , size-2, *mask);=0A *set++ =3D '}';=0A *set++ =3D '\0';=0A }=0A@@ = -244,7 +244,7 @@ static void dump_domains(unsigned char k=0A {=0A = unsigned int i;=0A printk("General information for domain = %u:\n", d->domain_id);=0A- cpuset_print(tmpstr, sizeof(tmpstr), = *d->domain_dirty_cpumask);=0A+ cpuset_print(tmpstr, sizeof(tmpstr), = d->domain_dirty_cpumask);=0A printk(" refcnt=3D%d dying=3D%d = nr_pages=3D%d xenheap_pages=3D%d "=0A "dirty_cpus=3D%s = max_pages=3D%u\n",=0A atomic_read(&d->refcnt), d->is_dying,= =0A@@ -278,9 +278,9 @@ static void dump_domains(unsigned char k=0A = v->pause_flags, v->poll_evtchn,=0A vcpu_info(= v, evtchn_upcall_pending),=0A vcpu_info(v, evtchn_upcall= _mask));=0A- cpuset_print(tmpstr, sizeof(tmpstr), *v->vcpu_dirty= _cpumask);=0A+ cpuset_print(tmpstr, sizeof(tmpstr), v->vcpu_dirt= y_cpumask);=0A printk("dirty_cpus=3D%s ", tmpstr);=0A- = cpuset_print(tmpstr, sizeof(tmpstr), *v->cpu_affinity);=0A+ = cpuset_print(tmpstr, sizeof(tmpstr), v->cpu_affinity);=0A = printk("cpu_affinity=3D%s\n", tmpstr);=0A arch_dump_vcpu_info(v= );=0A periodic_timer_print(tmpstr, sizeof(tmpstr), v->periodic_= period);=0A--- a/xen/common/rcupdate.c=0A+++ b/xen/common/rcupdate.c=0A@@ = -117,7 +117,7 @@ static void force_quiescent_state(struct=0A = */=0A cpumask =3D rcp->cpumask;=0A cpu_clear(rdp->cpu, = cpumask);=0A- cpumask_raise_softirq(cpumask, SCHEDULE_SOFTIRQ);=0A+ = cpumask_raise_softirq(&cpumask, SCHEDULE_SOFTIRQ);=0A }=0A }=0A = =0A--- a/xen/common/sched_credit.c=0A+++ b/xen/common/sched_credit.c=0A@@ = -310,7 +310,7 @@ __runq_tickle(unsigned int cpu, struct c=0A =0A /* = Send scheduler interrupts to designated CPUs */=0A if ( !cpus_empty(mas= k) )=0A- cpumask_raise_softirq(mask, SCHEDULE_SOFTIRQ);=0A+ = cpumask_raise_softirq(&mask, SCHEDULE_SOFTIRQ);=0A }=0A =0A static = void=0A--- a/xen/common/softirq.c=0A+++ b/xen/common/softirq.c=0A@@ -68,15 = +68,16 @@ void open_softirq(int nr, softirq_handle=0A softirq_handlers[= nr] =3D handler;=0A }=0A =0A-void cpumask_raise_softirq(cpumask_t mask, = unsigned int nr)=0A+void cpumask_raise_softirq(const cpumask_t *mask, = unsigned int nr)=0A {=0A int cpu;=0A+ cpumask_t send_mask =3D = CPU_MASK_NONE;=0A =0A- for_each_cpu_mask(cpu, mask)=0A- if ( = test_and_set_bit(nr, &softirq_pending(cpu)) )=0A- cpu_clear(cpu,= mask);=0A+ for_each_cpu_mask(cpu, *mask)=0A+ if ( !test_and_set_= bit(nr, &softirq_pending(cpu)) )=0A+ cpu_set(cpu, send_mask);=0A= =0A- smp_send_event_check_mask(&mask);=0A+ smp_send_event_check_mask= (&send_mask);=0A }=0A =0A void cpu_raise_softirq(unsigned int cpu, = unsigned int nr)=0A--- a/xen/drivers/passthrough/amd/iommu_init.c=0A+++ = b/xen/drivers/passthrough/amd/iommu_init.c=0A@@ -344,7 +344,7 @@ static = void amd_iommu_reset_event_log(st=0A set_iommu_event_log_control(iommu,= IOMMU_CONTROL_ENABLED);=0A }=0A =0A-static void iommu_msi_set_affinity(uns= igned int irq, cpumask_t mask)=0A+static void iommu_msi_set_affinity(unsign= ed int irq, const cpumask_t *mask)=0A {=0A struct msi_msg msg;=0A = unsigned int dest;=0A@@ -355,7 +355,7 @@ static void iommu_msi_set_affinity= (unsig=0A u8 dev =3D PCI_SLOT(iommu->bdf & 0xff);=0A u8 func =3D = PCI_FUNC(iommu->bdf & 0xff);=0A =0A- dest =3D set_desc_affinity(desc, = &mask);=0A+ dest =3D set_desc_affinity(desc, mask);=0A =0A if ( = dest =3D=3D BAD_APICID )=0A {=0A@@ -591,7 +591,7 @@ static void = enable_iommu(struct amd_iomm=0A register_iommu_event_log_in_mmio_space(= iommu);=0A register_iommu_exclusion_range(iommu);=0A =0A- iommu_msi_= set_affinity(iommu->irq, cpu_online_map);=0A+ iommu_msi_set_affinity(iom= mu->irq, &cpu_online_map);=0A amd_iommu_msi_enable(iommu, IOMMU_CONTROL= _ENABLED);=0A =0A set_iommu_command_buffer_control(iommu, IOMMU_CONTROL= _ENABLED);=0A--- a/xen/drivers/passthrough/vtd/iommu.c=0A+++ b/xen/drivers/= passthrough/vtd/iommu.c=0A@@ -998,7 +998,7 @@ static void dma_msi_end(unsig= ned int irq=0A ack_APIC_irq();=0A }=0A =0A-static void dma_msi_set_affi= nity(unsigned int irq, cpumask_t mask)=0A+static void dma_msi_set_affinity(= unsigned int irq, const cpumask_t *mask)=0A {=0A struct msi_msg = msg;=0A unsigned int dest;=0A@@ -1009,7 +1009,7 @@ static void = dma_msi_set_affinity(unsigne=0A struct irq_cfg *cfg =3D desc->chip_data= ;=0A =0A #ifdef CONFIG_X86=0A- dest =3D set_desc_affinity(desc, = &mask);=0A+ dest =3D set_desc_affinity(desc, mask);=0A if (dest = =3D=3D BAD_APICID){=0A dprintk(XENLOG_ERR VTDPREFIX, "Set iommu = interrupt affinity error!\n");=0A return;=0A@@ -1984,7 +1984,7 @@ = static int init_vtd_hw(void)=0A iommu =3D drhd->iommu;=0A =0A = cfg =3D irq_cfg(iommu->irq);=0A- dma_msi_set_affinity(iommu->irq,= cfg->cpu_mask);=0A+ dma_msi_set_affinity(iommu->irq, &cfg->cpu_mask= );=0A =0A clear_fault_bits(iommu);=0A =0A--- a/xen/include/asm-x86/= irq.h=0A+++ b/xen/include/asm-x86/irq.h=0A@@ -176,7 +176,7 @@ void = move_masked_irq(int irq);=0A =0A int __assign_irq_vector(int irq, struct = irq_cfg *, const cpumask_t *);=0A =0A-int bind_irq_vector(int irq, int = vector, cpumask_t domain);=0A+int bind_irq_vector(int irq, int vector, = const cpumask_t *);=0A =0A void irq_set_affinity(struct irq_desc *, const = cpumask_t *mask);=0A =0A--- a/xen/include/asm-x86/msi.h=0A+++ b/xen/include= /asm-x86/msi.h=0A@@ -77,7 +77,7 @@ struct msi_desc;=0A /* Helper functions = */=0A extern void mask_msi_irq(unsigned int irq);=0A extern void unmask_msi= _irq(unsigned int irq);=0A-extern void set_msi_affinity(unsigned int = vector, cpumask_t mask);=0A+extern void set_msi_affinity(unsigned int = vector, const cpumask_t *);=0A extern int pci_enable_msi(struct msi_info = *msi, struct msi_desc **desc);=0A extern void pci_disable_msi(struct = msi_desc *desc);=0A extern void pci_cleanup_msi(struct pci_dev *pdev);=0A--= - a/xen/include/xen/irq.h=0A+++ b/xen/include/xen/irq.h=0A@@ -45,7 +45,7 = @@ struct hw_interrupt_type {=0A void (*disable)(unsigned int irq);=0A = void (*ack)(unsigned int irq);=0A void (*end)(unsigned int irq, u8 = vector);=0A- void (*set_affinity)(unsigned int irq, cpumask_t mask);=0A+= void (*set_affinity)(unsigned int irq, const cpumask_t *);=0A };=0A = =0A typedef const struct hw_interrupt_type hw_irq_controller;=0A@@ -176,11 = +176,6 @@ static inline void set_native_irq_info(u=0A irq_desc[irq].aff= inity =3D *mask;=0A }=0A =0A-static inline void set_irq_info(int irq, = cpumask_t mask)=0A-{=0A- set_native_irq_info(irq, &mask);=0A-}=0A-=0A = unsigned int set_desc_affinity(struct irq_desc *, const cpumask_t *);=0A = =0A #endif /* __XEN_IRQ_H__ */=0A--- a/xen/include/xen/softirq.h=0A+++ = b/xen/include/xen/softirq.h=0A@@ -27,7 +27,7 @@ asmlinkage void do_softirq(= void);=0A void open_softirq(int nr, softirq_handler handler);=0A void = softirq_init(void);=0A =0A-void cpumask_raise_softirq(cpumask_t mask, = unsigned int nr);=0A+void cpumask_raise_softirq(const cpumask_t *, = unsigned int nr);=0A void cpu_raise_softirq(unsigned int cpu, unsigned int = nr);=0A void raise_softirq(unsigned int nr);=0A =0A --=__Part88A7B362.0__= Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel --=__Part88A7B362.0__=-- From xen-devel-bounces@lists.xensource.com Tue Sep 20 08:45:01 2011 Return-path: <xen-devel-bounces@lists.xensource.com> Envelope-to: www-data@lists.xensource.com Delivery-date: Tue, 20 Sep 2011 08:45:01 -0700 Received: from localhost ([127.0.0.1] helo=lists.colo.xensource.com) by lists.xensource.com with esmtp (Exim 4.43) id 1R62VJ-0004jx-9p; Tue, 20 Sep 2011 08:45:01 -0700 Received: from mail27.messagelabs.com ([193.109.254.147]) by lists.xensource.com with esmtp (Exim 4.43) id 1R62TR-00043R-5J for xen-devel@lists.xensource.com; Tue, 20 Sep 2011 08:43:06 -0700 X-Env-Sender: JBeulich@suse.com X-Msg-Ref: server-5.tower-27.messagelabs.com!1316533362!45670505!1 X-Originating-IP: [130.57.49.28] X-StarScan-Version: 6.4.1; banners=-,-,- X-VirusChecked: Checked Received: (qmail 25854 invoked from network); 20 Sep 2011 15:42:42 -0000 Received: from nat28.tlf.novell.com (HELO nat28.tlf.novell.com) (130.57.49.28) by server-5.tower-27.messagelabs.com with DHE-RSA-AES256-SHA encrypted SMTP; 20 Sep 2011 15:42:42 -0000 Received: from EMEA1-MTA by nat28.tlf.novell.com with Novell_GroupWise; Tue, 20 Sep 2011 16:43:01 +0100 Message-Id: <4E78D0BE0200007800056D89@nat28.tlf.novell.com> X-Mailer: Novell GroupWise Internet Agent 8.0.1 Date: Tue, 20 Sep 2011 16:43:26 +0100 From: "Jan Beulich" <JBeulich@suse.com> To: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com> Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="=__Part644B5F8E.0__=" Subject: [Xen-devel] [PATCH 2/4] pass struct irq_desc * to set_affinity() IRQ accessors X-BeenThere: xen-devel@lists.xensource.com X-Mailman-Version: 2.1.5 Precedence: list List-Id: Xen developer discussion <xen-devel.lists.xensource.com> List-Unsubscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe> List-Post: <mailto:xen-devel@lists.xensource.com> List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help> List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=subscribe> Sender: xen-devel-bounces@lists.xensource.com Errors-To: xen-devel-bounces@lists.xensource.com This is a MIME message. If you are reading this text, you may want to consider changing to a mail reader or gateway that understands how to properly handle MIME multipart messages. --=__Part644B5F8E.0__= Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: quoted-printable Content-Disposition: inline This is because the descriptor is generally more useful (with the IRQ number being accessible in it if necessary) and going forward will hopefully allow to remove all direct accesses to the IRQ descriptor array, in turn making it possible to make this some other, more efficient data structure. Signed-off-by: Jan Beulich <jbeulich@suse.com> --- a/xen/arch/ia64/linux-xen/iosapic.c +++ b/xen/arch/ia64/linux-xen/iosapic.c @@ -352,18 +352,18 @@ unmask_irq (unsigned int irq) =20 =20 static void -iosapic_set_affinity (unsigned int irq, const cpumask_t *mask) +iosapic_set_affinity (struct irq_desc *desc, const cpumask_t *mask) { #ifdef CONFIG_SMP unsigned long flags; u32 high32, low32; int dest, rte_index; char __iomem *addr; - int redir =3D (irq & IA64_IRQ_REDIRECTED) ? 1 : 0; + int redir =3D (desc->irq & IA64_IRQ_REDIRECTED) ? 1 : 0; + unsigned int irq =3D desc->irq & ~IA64_IRQ_REDIRECTED; ia64_vector vec; struct iosapic_rte_info *rte; =20 - irq &=3D (~IA64_IRQ_REDIRECTED); vec =3D irq_to_vector(irq); =20 if (cpumask_empty(mask)) --- a/xen/arch/x86/hpet.c +++ b/xen/arch/x86/hpet.c @@ -258,24 +258,14 @@ static void hpet_msi_mask(unsigned int i hpet_write32(cfg, HPET_Tn_CFG(ch->idx)); } =20 -static void hpet_msi_write(unsigned int irq, struct msi_msg *msg) +static void hpet_msi_write(struct hpet_event_channel *ch, struct msi_msg = *msg) { - unsigned int ch_idx =3D irq_to_channel(irq); - struct hpet_event_channel *ch =3D hpet_events + ch_idx; - - BUG_ON(ch_idx >=3D num_hpets_used); - hpet_write32(msg->data, HPET_Tn_ROUTE(ch->idx)); hpet_write32(msg->address_lo, HPET_Tn_ROUTE(ch->idx) + 4); } =20 -static void hpet_msi_read(unsigned int irq, struct msi_msg *msg) +static void hpet_msi_read(struct hpet_event_channel *ch, struct msi_msg = *msg) { - unsigned int ch_idx =3D irq_to_channel(irq); - struct hpet_event_channel *ch =3D hpet_events + ch_idx; - - BUG_ON(ch_idx >=3D num_hpets_used); - msg->data =3D hpet_read32(HPET_Tn_ROUTE(ch->idx)); msg->address_lo =3D hpet_read32(HPET_Tn_ROUTE(ch->idx) + 4); msg->address_hi =3D 0; @@ -305,23 +295,22 @@ static void hpet_msi_end(unsigned int ir { } =20 -static void hpet_msi_set_affinity(unsigned int irq, const cpumask_t = *mask) +static void hpet_msi_set_affinity(struct irq_desc *desc, const cpumask_t = *mask) { struct msi_msg msg; unsigned int dest; - struct irq_desc * desc =3D irq_to_desc(irq); struct irq_cfg *cfg=3D desc->chip_data; =20 dest =3D set_desc_affinity(desc, mask); if (dest =3D=3D BAD_APICID) return; =20 - hpet_msi_read(irq, &msg); + hpet_msi_read(desc->action->dev_id, &msg); msg.data &=3D ~MSI_DATA_VECTOR_MASK; msg.data |=3D MSI_DATA_VECTOR(cfg->vector); msg.address_lo &=3D ~MSI_ADDR_DEST_ID_MASK; msg.address_lo |=3D MSI_ADDR_DEST_ID(dest); - hpet_msi_write(irq, &msg); + hpet_msi_write(desc->action->dev_id, &msg); } =20 /* @@ -338,12 +327,12 @@ static hw_irq_controller hpet_msi_type =3D .set_affinity =3D hpet_msi_set_affinity, }; =20 -static void __hpet_setup_msi_irq(unsigned int irq) +static void __hpet_setup_msi_irq(struct irq_desc *desc) { struct msi_msg msg; =20 - msi_compose_msg(irq, &msg); - hpet_msi_write(irq, &msg); + msi_compose_msg(desc->irq, &msg); + hpet_msi_write(desc->action->dev_id, &msg); } =20 static int __init hpet_setup_msi_irq(unsigned int irq) @@ -357,7 +346,7 @@ static int __init hpet_setup_msi_irq(uns if ( ret < 0 ) return ret; =20 - __hpet_setup_msi_irq(irq); + __hpet_setup_msi_irq(desc); =20 return 0; } @@ -471,7 +460,7 @@ static void hpet_attach_channel(unsigned if ( ch->cpu !=3D cpu ) return; =20 - hpet_msi_set_affinity(ch->irq, cpumask_of(ch->cpu)); + hpet_msi_set_affinity(irq_to_desc(ch->irq), cpumask_of(ch->cpu)); } =20 static void hpet_detach_channel(unsigned int cpu, @@ -493,7 +482,7 @@ static void hpet_detach_channel(unsigned } =20 ch->cpu =3D first_cpu(ch->cpumask); - hpet_msi_set_affinity(ch->irq, cpumask_of(ch->cpu)); + hpet_msi_set_affinity(irq_to_desc(ch->irq), cpumask_of(ch->cpu)); } =20 #include <asm/mc146818rtc.h> @@ -619,7 +608,7 @@ void hpet_broadcast_resume(void) for ( i =3D 0; i < n; i++ ) { if ( hpet_events[i].irq >=3D 0 ) - __hpet_setup_msi_irq(hpet_events[i].irq); + __hpet_setup_msi_irq(irq_to_desc(hpet_events[i].irq)); =20 /* set HPET Tn as oneshot */ cfg =3D hpet_read32(HPET_Tn_CFG(hpet_events[i].idx)); --- a/xen/arch/x86/io_apic.c +++ b/xen/arch/x86/io_apic.c @@ -658,7 +658,7 @@ unsigned int set_desc_affinity(struct ir } =20 static void -set_ioapic_affinity_irq_desc(struct irq_desc *desc, const cpumask_t = *mask) +set_ioapic_affinity_irq(struct irq_desc *desc, const cpumask_t *mask) { unsigned long flags; unsigned int dest; @@ -695,16 +695,6 @@ set_ioapic_affinity_irq_desc(struct irq_ spin_unlock_irqrestore(&ioapic_lock, flags); =20 } - -static void -set_ioapic_affinity_irq(unsigned int irq, const struct cpumask *mask) -{ - struct irq_desc *desc; - - desc =3D irq_to_desc(irq); - - set_ioapic_affinity_irq_desc(desc, mask); -} #endif /* CONFIG_SMP */ =20 /* @@ -802,7 +792,7 @@ void /*__init*/ setup_ioapic_dest(void) irq =3D pin_2_irq(irq_entry, ioapic, pin); cfg =3D irq_cfg(irq); BUG_ON(cpus_empty(cfg->cpu_mask)); - set_ioapic_affinity_irq(irq, &cfg->cpu_mask); + set_ioapic_affinity_irq(irq_to_desc(irq), &cfg->cpu_mask); } =20 } @@ -1780,7 +1770,7 @@ static void mask_and_ack_level_ioapic_ir =20 if ((irq_desc[irq].status & IRQ_MOVE_PENDING) && !io_apic_level_ack_pending(irq)) - move_masked_irq(irq); + move_masked_irq(desc); =20 if ( !(v & (1 << (i & 0x1f))) ) { spin_lock(&ioapic_lock); @@ -1799,7 +1789,9 @@ static void end_level_ioapic_irq (unsign { if ( directed_eoi_enabled ) { - if ( !(irq_desc[irq].status & (IRQ_DISABLED|IRQ_MOVE_PENDING))= ) + struct irq_desc *desc =3D irq_to_desc(irq); + + if ( !(desc->status & (IRQ_DISABLED|IRQ_MOVE_PENDING)) ) { eoi_IO_APIC_irq(irq); return; @@ -1807,9 +1799,9 @@ static void end_level_ioapic_irq (unsign =20 mask_IO_APIC_irq(irq); eoi_IO_APIC_irq(irq); - if ( (irq_desc[irq].status & IRQ_MOVE_PENDING) && + if ( (desc->status & IRQ_MOVE_PENDING) && !io_apic_level_ack_pending(irq) ) - move_masked_irq(irq); + move_masked_irq(desc); } =20 if ( !(irq_desc[irq].status & IRQ_DISABLED) ) --- a/xen/arch/x86/irq.c +++ b/xen/arch/x86/irq.c @@ -557,10 +557,8 @@ void __setup_vector_irq(int cpu) } } =20 -void move_masked_irq(int irq) +void move_masked_irq(struct irq_desc *desc) { - struct irq_desc *desc =3D irq_to_desc(irq); - if (likely(!(desc->status & IRQ_MOVE_PENDING))) return; =20 @@ -582,7 +580,7 @@ void move_masked_irq(int irq) * For correct operation this depends on the caller masking the irqs. */ if (likely(cpus_intersects(desc->pending_mask, cpu_online_map))) - desc->handler->set_affinity(irq, &desc->pending_mask); + desc->handler->set_affinity(desc, &desc->pending_mask); =20 cpus_clear(desc->pending_mask); } @@ -598,7 +596,7 @@ void move_native_irq(int irq) return; =20 desc->handler->disable(irq); - move_masked_irq(irq); + move_masked_irq(desc); desc->handler->enable(irq); } =20 @@ -1409,7 +1407,7 @@ int pirq_guest_bind(struct vcpu *v, stru /* Attempt to bind the interrupt target to the correct CPU. */ cpu_set(v->processor, cpumask); if ( !opt_noirqbalance && (desc->handler->set_affinity !=3D NULL) = ) - desc->handler->set_affinity(irq, &cpumask); + desc->handler->set_affinity(desc, &cpumask); } else if ( !will_share || !action->shareable ) { @@ -1963,7 +1961,7 @@ void fixup_irqs(void) desc->handler->disable(irq); =20 if ( desc->handler->set_affinity ) - desc->handler->set_affinity(irq, &affinity); + desc->handler->set_affinity(desc, &affinity); else if ( !(warned++) ) set_affinity =3D 0; =20 --- a/xen/arch/x86/msi.c +++ b/xen/arch/x86/msi.c @@ -266,11 +266,10 @@ static void write_msi_msg(struct msi_des } } =20 -void set_msi_affinity(unsigned int irq, const cpumask_t *mask) +void set_msi_affinity(struct irq_desc *desc, const cpumask_t *mask) { struct msi_msg msg; unsigned int dest; - struct irq_desc *desc =3D irq_to_desc(irq); struct msi_desc *msi_desc =3D desc->msi_desc; struct irq_cfg *cfg =3D desc->chip_data; =20 --- a/xen/drivers/passthrough/amd/iommu_init.c +++ b/xen/drivers/passthrough/amd/iommu_init.c @@ -344,12 +344,11 @@ static void amd_iommu_reset_event_log(st set_iommu_event_log_control(iommu, IOMMU_CONTROL_ENABLED); } =20 -static void iommu_msi_set_affinity(unsigned int irq, const cpumask_t = *mask) +static void iommu_msi_set_affinity(struct irq_desc *desc, const cpumask_t = *mask) { struct msi_msg msg; unsigned int dest; - struct amd_iommu *iommu =3D irq_to_iommu[irq]; - struct irq_desc *desc =3D irq_to_desc(irq); + struct amd_iommu *iommu =3D desc->action->dev_id; struct irq_cfg *cfg =3D desc->chip_data; u8 bus =3D (iommu->bdf >> 8) & 0xff; u8 dev =3D PCI_SLOT(iommu->bdf & 0xff); @@ -591,7 +590,7 @@ static void enable_iommu(struct amd_iomm register_iommu_event_log_in_mmio_space(iommu); register_iommu_exclusion_range(iommu); =20 - iommu_msi_set_affinity(iommu->irq, &cpu_online_map); + iommu_msi_set_affinity(irq_to_desc(iommu->irq), &cpu_online_map); amd_iommu_msi_enable(iommu, IOMMU_CONTROL_ENABLED); =20 set_iommu_command_buffer_control(iommu, IOMMU_CONTROL_ENABLED); --- a/xen/drivers/passthrough/vtd/iommu.c +++ b/xen/drivers/passthrough/vtd/iommu.c @@ -998,14 +998,12 @@ static void dma_msi_end(unsigned int irq ack_APIC_irq(); } =20 -static void dma_msi_set_affinity(unsigned int irq, const cpumask_t *mask) +static void dma_msi_set_affinity(struct irq_desc *desc, const cpumask_t = *mask) { struct msi_msg msg; unsigned int dest; unsigned long flags; - - struct iommu *iommu =3D irq_to_iommu[irq]; - struct irq_desc *desc =3D irq_to_desc(irq); + struct iommu *iommu =3D desc->action->dev_id; struct irq_cfg *cfg =3D desc->chip_data; =20 #ifdef CONFIG_X86 @@ -1984,7 +1982,7 @@ static int init_vtd_hw(void) iommu =3D drhd->iommu; =20 cfg =3D irq_cfg(iommu->irq); - dma_msi_set_affinity(iommu->irq, &cfg->cpu_mask); + dma_msi_set_affinity(irq_to_desc(iommu->irq), &cfg->cpu_mask); =20 clear_fault_bits(iommu); =20 --- a/xen/include/asm-x86/irq.h +++ b/xen/include/asm-x86/irq.h @@ -172,7 +172,7 @@ void unlock_vector_lock(void); void __setup_vector_irq(int cpu); =20 void move_native_irq(int irq); -void move_masked_irq(int irq); +void move_masked_irq(struct irq_desc *); =20 int __assign_irq_vector(int irq, struct irq_cfg *, const cpumask_t *); =20 --- a/xen/include/asm-x86/msi.h +++ b/xen/include/asm-x86/msi.h @@ -77,7 +77,7 @@ struct msi_desc; /* Helper functions */ extern void mask_msi_irq(unsigned int irq); extern void unmask_msi_irq(unsigned int irq); -extern void set_msi_affinity(unsigned int vector, const cpumask_t *); +extern void set_msi_affinity(struct irq_desc *, const cpumask_t *); extern int pci_enable_msi(struct msi_info *msi, struct msi_desc **desc); extern void pci_disable_msi(struct msi_desc *desc); extern void pci_cleanup_msi(struct pci_dev *pdev); --- a/xen/include/xen/irq.h +++ b/xen/include/xen/irq.h @@ -33,6 +33,8 @@ struct irqaction { #define NEVER_ASSIGN_IRQ (-2) #define FREE_TO_ASSIGN_IRQ (-3) =20 +struct irq_desc; + /* * Interrupt controller descriptor. This is all we need * to describe about the low-level hardware.=20 @@ -45,7 +47,7 @@ struct hw_interrupt_type { void (*disable)(unsigned int irq); void (*ack)(unsigned int irq); void (*end)(unsigned int irq, u8 vector); - void (*set_affinity)(unsigned int irq, const cpumask_t *); + void (*set_affinity)(struct irq_desc *, const cpumask_t *); }; =20 typedef const struct hw_interrupt_type hw_irq_controller; --=__Part644B5F8E.0__= Content-Type: text/plain; name="irq-set-affinity-desc.patch" Content-Transfer-Encoding: quoted-printable Content-Disposition: attachment; filename="irq-set-affinity-desc.patch" This is because the descriptor is generally more useful (with the = IRQ=0Anumber being accessible in it if necessary) and going forward = will=0Ahopefully allow to remove all direct accesses to the IRQ descriptor= =0Aarray, in turn making it possible to make this some other, more=0Aeffici= ent data structure.=0A=0ASigned-off-by: Jan Beulich <jbeulich@suse.com>=0A= =0A--- a/xen/arch/ia64/linux-xen/iosapic.c=0A+++ b/xen/arch/ia64/linux-xen/= iosapic.c=0A@@ -352,18 +352,18 @@ unmask_irq (unsigned int irq)=0A =0A =0A = static void=0A-iosapic_set_affinity (unsigned int irq, const cpumask_t = *mask)=0A+iosapic_set_affinity (struct irq_desc *desc, const cpumask_t = *mask)=0A {=0A #ifdef CONFIG_SMP=0A unsigned long flags;=0A = u32 high32, low32;=0A int dest, rte_index;=0A char __iomem = *addr;=0A- int redir =3D (irq & IA64_IRQ_REDIRECTED) ? 1 : 0;=0A+ = int redir =3D (desc->irq & IA64_IRQ_REDIRECTED) ? 1 : 0;=0A+ unsigned = int irq =3D desc->irq & ~IA64_IRQ_REDIRECTED;=0A ia64_vector = vec;=0A struct iosapic_rte_info *rte;=0A =0A- irq &=3D (~IA64_IRQ= _REDIRECTED);=0A vec =3D irq_to_vector(irq);=0A =0A if = (cpumask_empty(mask))=0A--- a/xen/arch/x86/hpet.c=0A+++ b/xen/arch/x86/hpet= .c=0A@@ -258,24 +258,14 @@ static void hpet_msi_mask(unsigned int i=0A = hpet_write32(cfg, HPET_Tn_CFG(ch->idx));=0A }=0A =0A-static void hpet_msi_w= rite(unsigned int irq, struct msi_msg *msg)=0A+static void hpet_msi_write(s= truct hpet_event_channel *ch, struct msi_msg *msg)=0A {=0A- unsigned = int ch_idx =3D irq_to_channel(irq);=0A- struct hpet_event_channel *ch = =3D hpet_events + ch_idx;=0A-=0A- BUG_ON(ch_idx >=3D num_hpets_used);=0A= -=0A hpet_write32(msg->data, HPET_Tn_ROUTE(ch->idx));=0A hpet_write= 32(msg->address_lo, HPET_Tn_ROUTE(ch->idx) + 4);=0A }=0A =0A-static void = hpet_msi_read(unsigned int irq, struct msi_msg *msg)=0A+static void = hpet_msi_read(struct hpet_event_channel *ch, struct msi_msg *msg)=0A {=0A- = unsigned int ch_idx =3D irq_to_channel(irq);=0A- struct hpet_event_ch= annel *ch =3D hpet_events + ch_idx;=0A-=0A- BUG_ON(ch_idx >=3D = num_hpets_used);=0A-=0A msg->data =3D hpet_read32(HPET_Tn_ROUTE(ch->idx= ));=0A msg->address_lo =3D hpet_read32(HPET_Tn_ROUTE(ch->idx) + 4);=0A = msg->address_hi =3D 0;=0A@@ -305,23 +295,22 @@ static void hpet_msi_end= (unsigned int ir=0A {=0A }=0A =0A-static void hpet_msi_set_affinity(unsigne= d int irq, const cpumask_t *mask)=0A+static void hpet_msi_set_affinity(stru= ct irq_desc *desc, const cpumask_t *mask)=0A {=0A struct msi_msg = msg;=0A unsigned int dest;=0A- struct irq_desc * desc =3D irq_to_des= c(irq);=0A struct irq_cfg *cfg=3D desc->chip_data;=0A =0A dest =3D = set_desc_affinity(desc, mask);=0A if (dest =3D=3D BAD_APICID)=0A = return;=0A =0A- hpet_msi_read(irq, &msg);=0A+ hpet_msi_read(desc->a= ction->dev_id, &msg);=0A msg.data &=3D ~MSI_DATA_VECTOR_MASK;=0A = msg.data |=3D MSI_DATA_VECTOR(cfg->vector);=0A msg.address_lo &=3D = ~MSI_ADDR_DEST_ID_MASK;=0A msg.address_lo |=3D MSI_ADDR_DEST_ID(dest);= =0A- hpet_msi_write(irq, &msg);=0A+ hpet_msi_write(desc->action->dev_= id, &msg);=0A }=0A =0A /*=0A@@ -338,12 +327,12 @@ static hw_irq_controller = hpet_msi_type =3D=0A .set_affinity =3D hpet_msi_set_affinity,=0A = };=0A =0A-static void __hpet_setup_msi_irq(unsigned int irq)=0A+static = void __hpet_setup_msi_irq(struct irq_desc *desc)=0A {=0A struct = msi_msg msg;=0A =0A- msi_compose_msg(irq, &msg);=0A- hpet_msi_write(i= rq, &msg);=0A+ msi_compose_msg(desc->irq, &msg);=0A+ hpet_msi_write(d= esc->action->dev_id, &msg);=0A }=0A =0A static int __init hpet_setup_msi_ir= q(unsigned int irq)=0A@@ -357,7 +346,7 @@ static int __init hpet_setup_msi_= irq(uns=0A if ( ret < 0 )=0A return ret;=0A =0A- __hpet_setu= p_msi_irq(irq);=0A+ __hpet_setup_msi_irq(desc);=0A =0A return 0;=0A = }=0A@@ -471,7 +460,7 @@ static void hpet_attach_channel(unsigned=0A if = ( ch->cpu !=3D cpu )=0A return;=0A =0A- hpet_msi_set_affinity(ch= ->irq, cpumask_of(ch->cpu));=0A+ hpet_msi_set_affinity(irq_to_desc(ch->i= rq), cpumask_of(ch->cpu));=0A }=0A =0A static void hpet_detach_channel(unsi= gned int cpu,=0A@@ -493,7 +482,7 @@ static void hpet_detach_channel(unsigne= d=0A }=0A =0A ch->cpu =3D first_cpu(ch->cpumask);=0A- hpet_msi_s= et_affinity(ch->irq, cpumask_of(ch->cpu));=0A+ hpet_msi_set_affinity(irq= _to_desc(ch->irq), cpumask_of(ch->cpu));=0A }=0A =0A #include <asm/mc146818= rtc.h>=0A@@ -619,7 +608,7 @@ void hpet_broadcast_resume(void)=0A for ( = i =3D 0; i < n; i++ )=0A {=0A if ( hpet_events[i].irq >=3D 0 = )=0A- __hpet_setup_msi_irq(hpet_events[i].irq);=0A+ = __hpet_setup_msi_irq(irq_to_desc(hpet_events[i].irq));=0A =0A /* = set HPET Tn as oneshot */=0A cfg =3D hpet_read32(HPET_Tn_CFG(hpet_e= vents[i].idx));=0A--- a/xen/arch/x86/io_apic.c=0A+++ b/xen/arch/x86/io_apic= .c=0A@@ -658,7 +658,7 @@ unsigned int set_desc_affinity(struct ir=0A }=0A = =0A static void=0A-set_ioapic_affinity_irq_desc(struct irq_desc *desc, = const cpumask_t *mask)=0A+set_ioapic_affinity_irq(struct irq_desc *desc, = const cpumask_t *mask)=0A {=0A unsigned long flags;=0A unsigned = int dest;=0A@@ -695,16 +695,6 @@ set_ioapic_affinity_irq_desc(struct = irq_=0A spin_unlock_irqrestore(&ioapic_lock, flags);=0A =0A }=0A-=0A-st= atic void=0A-set_ioapic_affinity_irq(unsigned int irq, const struct = cpumask *mask)=0A-{=0A- struct irq_desc *desc;=0A-=0A- desc =3D = irq_to_desc(irq);=0A-=0A- set_ioapic_affinity_irq_desc(desc, mask);=0A-}= =0A #endif /* CONFIG_SMP */=0A =0A /*=0A@@ -802,7 +792,7 @@ void /*__init*/= setup_ioapic_dest(void)=0A irq =3D pin_2_irq(irq_entry, = ioapic, pin);=0A cfg =3D irq_cfg(irq);=0A = BUG_ON(cpus_empty(cfg->cpu_mask));=0A- set_ioapic_affinity_irq(i= rq, &cfg->cpu_mask);=0A+ set_ioapic_affinity_irq(irq_to_desc(irq= ), &cfg->cpu_mask);=0A }=0A =0A }=0A@@ -1780,7 +1770,7 @@ = static void mask_and_ack_level_ioapic_ir=0A =0A if ((irq_desc[irq].stat= us & IRQ_MOVE_PENDING) &&=0A !io_apic_level_ack_pending(irq))=0A- = move_masked_irq(irq);=0A+ move_masked_irq(desc);=0A =0A if = ( !(v & (1 << (i & 0x1f))) ) {=0A spin_lock(&ioapic_lock);=0A@@ = -1799,7 +1789,9 @@ static void end_level_ioapic_irq (unsign=0A {=0A = if ( directed_eoi_enabled )=0A {=0A- if ( = !(irq_desc[irq].status & (IRQ_DISABLED|IRQ_MOVE_PENDING)) )=0A+ = struct irq_desc *desc =3D irq_to_desc(irq);=0A+=0A+ if ( = !(desc->status & (IRQ_DISABLED|IRQ_MOVE_PENDING)) )=0A {=0A = eoi_IO_APIC_irq(irq);=0A return;=0A@@ -1807,9 = +1799,9 @@ static void end_level_ioapic_irq (unsign=0A =0A = mask_IO_APIC_irq(irq);=0A eoi_IO_APIC_irq(irq);=0A- = if ( (irq_desc[irq].status & IRQ_MOVE_PENDING) &&=0A+ if ( = (desc->status & IRQ_MOVE_PENDING) &&=0A !io_apic_level_ack= _pending(irq) )=0A- move_masked_irq(irq);=0A+ = move_masked_irq(desc);=0A }=0A =0A if ( !(irq_desc[irq].st= atus & IRQ_DISABLED) )=0A--- a/xen/arch/x86/irq.c=0A+++ b/xen/arch/x86/irq.= c=0A@@ -557,10 +557,8 @@ void __setup_vector_irq(int cpu)=0A }=0A }=0A = =0A-void move_masked_irq(int irq)=0A+void move_masked_irq(struct irq_desc = *desc)=0A {=0A- struct irq_desc *desc =3D irq_to_desc(irq);=0A-=0A = if (likely(!(desc->status & IRQ_MOVE_PENDING)))=0A return;=0A = =0A@@ -582,7 +580,7 @@ void move_masked_irq(int irq)=0A * For correct = operation this depends on the caller masking the irqs.=0A */=0A = if (likely(cpus_intersects(desc->pending_mask, cpu_online_map)))=0A- = desc->handler->set_affinity(irq, &desc->pending_mask);=0A+ = desc->handler->set_affinity(desc, &desc->pending_mask);=0A =0A = cpus_clear(desc->pending_mask);=0A }=0A@@ -598,7 +596,7 @@ void move_native= _irq(int irq)=0A return;=0A =0A desc->handler->disable(irq);=0A= - move_masked_irq(irq);=0A+ move_masked_irq(desc);=0A desc->handl= er->enable(irq);=0A }=0A =0A@@ -1409,7 +1407,7 @@ int pirq_guest_bind(struc= t vcpu *v, stru=0A /* Attempt to bind the interrupt target to the = correct CPU. */=0A cpu_set(v->processor, cpumask);=0A if ( = !opt_noirqbalance && (desc->handler->set_affinity !=3D NULL) )=0A- = desc->handler->set_affinity(irq, &cpumask);=0A+ desc->handler= ->set_affinity(desc, &cpumask);=0A }=0A else if ( !will_share || = !action->shareable )=0A {=0A@@ -1963,7 +1961,7 @@ void fixup_irqs(void)= =0A desc->handler->disable(irq);=0A =0A if ( desc->hand= ler->set_affinity )=0A- desc->handler->set_affinity(irq, = &affinity);=0A+ desc->handler->set_affinity(desc, &affinity);=0A= else if ( !(warned++) )=0A set_affinity =3D 0;=0A = =0A--- a/xen/arch/x86/msi.c=0A+++ b/xen/arch/x86/msi.c=0A@@ -266,11 = +266,10 @@ static void write_msi_msg(struct msi_des=0A }=0A }=0A = =0A-void set_msi_affinity(unsigned int irq, const cpumask_t *mask)=0A+void = set_msi_affinity(struct irq_desc *desc, const cpumask_t *mask)=0A {=0A = struct msi_msg msg;=0A unsigned int dest;=0A- struct irq_desc *desc = =3D irq_to_desc(irq);=0A struct msi_desc *msi_desc =3D desc->msi_desc;= =0A struct irq_cfg *cfg =3D desc->chip_data;=0A =0A--- a/xen/drivers/pa= ssthrough/amd/iommu_init.c=0A+++ b/xen/drivers/passthrough/amd/iommu_init.c= =0A@@ -344,12 +344,11 @@ static void amd_iommu_reset_event_log(st=0A = set_iommu_event_log_control(iommu, IOMMU_CONTROL_ENABLED);=0A }=0A = =0A-static void iommu_msi_set_affinity(unsigned int irq, const cpumask_t = *mask)=0A+static void iommu_msi_set_affinity(struct irq_desc *desc, const = cpumask_t *mask)=0A {=0A struct msi_msg msg;=0A unsigned int = dest;=0A- struct amd_iommu *iommu =3D irq_to_iommu[irq];=0A- struct = irq_desc *desc =3D irq_to_desc(irq);=0A+ struct amd_iommu *iommu =3D = desc->action->dev_id;=0A struct irq_cfg *cfg =3D desc->chip_data;=0A = u8 bus =3D (iommu->bdf >> 8) & 0xff;=0A u8 dev =3D PCI_SLOT(iommu->bd= f & 0xff);=0A@@ -591,7 +590,7 @@ static void enable_iommu(struct = amd_iomm=0A register_iommu_event_log_in_mmio_space(iommu);=0A = register_iommu_exclusion_range(iommu);=0A =0A- iommu_msi_set_affinity(io= mmu->irq, &cpu_online_map);=0A+ iommu_msi_set_affinity(irq_to_desc(iommu= ->irq), &cpu_online_map);=0A amd_iommu_msi_enable(iommu, IOMMU_CONTROL_= ENABLED);=0A =0A set_iommu_command_buffer_control(iommu, IOMMU_CONTROL_= ENABLED);=0A--- a/xen/drivers/passthrough/vtd/iommu.c=0A+++ b/xen/drivers/p= assthrough/vtd/iommu.c=0A@@ -998,14 +998,12 @@ static void dma_msi_end(unsi= gned int irq=0A ack_APIC_irq();=0A }=0A =0A-static void dma_msi_set_aff= inity(unsigned int irq, const cpumask_t *mask)=0A+static void dma_msi_set_a= ffinity(struct irq_desc *desc, const cpumask_t *mask)=0A {=0A struct = msi_msg msg;=0A unsigned int dest;=0A unsigned long flags;=0A-=0A- = struct iommu *iommu =3D irq_to_iommu[irq];=0A- struct irq_desc *desc = =3D irq_to_desc(irq);=0A+ struct iommu *iommu =3D desc->action->dev_id;= =0A struct irq_cfg *cfg =3D desc->chip_data;=0A =0A #ifdef CONFIG_X86= =0A@@ -1984,7 +1982,7 @@ static int init_vtd_hw(void)=0A iommu =3D = drhd->iommu;=0A =0A cfg =3D irq_cfg(iommu->irq);=0A- = dma_msi_set_affinity(iommu->irq, &cfg->cpu_mask);=0A+ dma_msi_set_af= finity(irq_to_desc(iommu->irq), &cfg->cpu_mask);=0A =0A clear_fault= _bits(iommu);=0A =0A--- a/xen/include/asm-x86/irq.h=0A+++ b/xen/include/asm= -x86/irq.h=0A@@ -172,7 +172,7 @@ void unlock_vector_lock(void);=0A void = __setup_vector_irq(int cpu);=0A =0A void move_native_irq(int irq);=0A-void = move_masked_irq(int irq);=0A+void move_masked_irq(struct irq_desc *);=0A = =0A int __assign_irq_vector(int irq, struct irq_cfg *, const cpumask_t = *);=0A =0A--- a/xen/include/asm-x86/msi.h=0A+++ b/xen/include/asm-x86/msi.h= =0A@@ -77,7 +77,7 @@ struct msi_desc;=0A /* Helper functions */=0A extern = void mask_msi_irq(unsigned int irq);=0A extern void unmask_msi_irq(unsigned= int irq);=0A-extern void set_msi_affinity(unsigned int vector, const = cpumask_t *);=0A+extern void set_msi_affinity(struct irq_desc *, const = cpumask_t *);=0A extern int pci_enable_msi(struct msi_info *msi, struct = msi_desc **desc);=0A extern void pci_disable_msi(struct msi_desc *desc);=0A= extern void pci_cleanup_msi(struct pci_dev *pdev);=0A--- a/xen/include/xen= /irq.h=0A+++ b/xen/include/xen/irq.h=0A@@ -33,6 +33,8 @@ struct irqaction = {=0A #define NEVER_ASSIGN_IRQ (-2)=0A #define FREE_TO_ASSIGN_IRQ = (-3)=0A =0A+struct irq_desc;=0A+=0A /*=0A * Interrupt controller = descriptor. This is all we need=0A * to describe about the low-level = hardware. =0A@@ -45,7 +47,7 @@ struct hw_interrupt_type {=0A void = (*disable)(unsigned int irq);=0A void (*ack)(unsigned int irq);=0A = void (*end)(unsigned int irq, u8 vector);=0A- void (*set_affinity)(unsig= ned int irq, const cpumask_t *);=0A+ void (*set_affinity)(struct = irq_desc *, const cpumask_t *);=0A };=0A =0A typedef const struct = hw_interrupt_type hw_irq_controller;=0A --=__Part644B5F8E.0__= Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel --=__Part644B5F8E.0__=-- From xen-devel-bounces@lists.xensource.com Tue Sep 20 08:46:16 2011 Return-path: <xen-devel-bounces@lists.xensource.com> Envelope-to: www-data@lists.xensource.com Delivery-date: Tue, 20 Sep 2011 08:46:16 -0700 Received: from localhost ([127.0.0.1] helo=lists.colo.xensource.com) by lists.xensource.com with esmtp (Exim 4.43) id 1R62WW-00059v-2w; Tue, 20 Sep 2011 08:46:16 -0700 Received: from mail27.messagelabs.com ([193.109.254.147]) by lists.xensource.com with esmtp (Exim 4.43) id 1R62Tz-0004Ej-BP for xen-devel@lists.xensource.com; Tue, 20 Sep 2011 08:43:40 -0700 X-Env-Sender: JBeulich@suse.com X-Msg-Ref: server-8.tower-27.messagelabs.com!1316533399!47391717!1 X-Originating-IP: [130.57.49.28] X-StarScan-Version: 6.4.1; banners=-,-,- X-VirusChecked: Checked Received: (qmail 6761 invoked from network); 20 Sep 2011 15:43:20 -0000 Received: from nat28.tlf.novell.com (HELO nat28.tlf.novell.com) (130.57.49.28) by server-8.tower-27.messagelabs.com with DHE-RSA-AES256-SHA encrypted SMTP; 20 Sep 2011 15:43:20 -0000 Received: from EMEA1-MTA by nat28.tlf.novell.com with Novell_GroupWise; Tue, 20 Sep 2011 16:43:35 +0100 Message-Id: <4E78D0E00200007800056D8D@nat28.tlf.novell.com> X-Mailer: Novell GroupWise Internet Agent 8.0.1 Date: Tue, 20 Sep 2011 16:44:00 +0100 From: "Jan Beulich" <JBeulich@suse.com> To: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com> Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="=__Part3A1501D0.0__=" Subject: [Xen-devel] [PATCH 3/4] pass struct irq_desc * to all other IRQ accessors X-BeenThere: xen-devel@lists.xensource.com X-Mailman-Version: 2.1.5 Precedence: list List-Id: Xen developer discussion <xen-devel.lists.xensource.com> List-Unsubscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe> List-Post: <mailto:xen-devel@lists.xensource.com> List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help> List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=subscribe> Sender: xen-devel-bounces@lists.xensource.com Errors-To: xen-devel-bounces@lists.xensource.com This is a MIME message. If you are reading this text, you may want to consider changing to a mail reader or gateway that understands how to properly handle MIME multipart messages. --=__Part3A1501D0.0__= Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: quoted-printable Content-Disposition: inline This is again because the descriptor is generally more useful (with the IRQ number being accessible in it if necessary) and going forward will hopefully allow to remove all direct accesses to the IRQ descriptor array, in turn making it possible to make this some other, more efficient data structure. This additionally makes the .end() accessor optional, noting that in a number of cases the functions were empty. Signed-off-by: Jan Beulich <jbeulich@suse.com> --- a/xen/arch/ia64/linux-xen/iosapic.c +++ b/xen/arch/ia64/linux-xen/iosapic.c @@ -276,7 +276,7 @@ set_rte (unsigned int gsi, unsigned int=20 } =20 static void -nop (unsigned int vector) +nop (struct irq_desc *desc) { /* do nothing... */ } @@ -300,13 +300,13 @@ kexec_disable_iosapic(void) } =20 static void -mask_irq (unsigned int irq) +mask_irq (struct irq_desc *desc) { unsigned long flags; char __iomem *addr; u32 low32; int rte_index; - ia64_vector vec =3D irq_to_vector(irq); + ia64_vector vec =3D irq_to_vector(desc->irq); struct iosapic_rte_info *rte; =20 if (list_empty(&iosapic_intr_info[vec].rtes)) @@ -326,13 +326,13 @@ mask_irq (unsigned int irq) } =20 static void -unmask_irq (unsigned int irq) +unmask_irq (struct irq_desc *desc) { unsigned long flags; char __iomem *addr; u32 low32; int rte_index; - ia64_vector vec =3D irq_to_vector(irq); + ia64_vector vec =3D irq_to_vector(desc->irq); struct iosapic_rte_info *rte; =20 if (list_empty(&iosapic_intr_info[vec].rtes)) @@ -408,19 +408,19 @@ iosapic_set_affinity (struct irq_desc *d */ =20 static unsigned int -iosapic_startup_level_irq (unsigned int irq) +iosapic_startup_level_irq (struct irq_desc *desc) { - unmask_irq(irq); + unmask_irq(desc); return 0; } =20 static void -iosapic_end_level_irq (unsigned int irq) +iosapic_end_level_irq (struct irq_desc *desc) { - ia64_vector vec =3D irq_to_vector(irq); + ia64_vector vec =3D irq_to_vector(desc->irq); struct iosapic_rte_info *rte; =20 - move_irq(irq); + move_irq(desc->irq); list_for_each_entry(rte, &iosapic_intr_info[vec].rtes, rte_list) iosapic_eoi(rte->addr, vec); } --- a/xen/arch/x86/hpet.c +++ b/xen/arch/x86/hpet.c @@ -49,9 +49,6 @@ static unsigned int __read_mostly num_hp =20 DEFINE_PER_CPU(struct hpet_event_channel *, cpu_bc_channel); =20 -static unsigned int *__read_mostly irq_channel; -#define irq_to_channel(irq) irq_channel[irq] - unsigned long __read_mostly hpet_address; =20 /* @@ -232,26 +229,20 @@ static void hpet_interrupt_handler(int i ch->event_handler(ch); } =20 -static void hpet_msi_unmask(unsigned int irq) +static void hpet_msi_unmask(struct irq_desc *desc) { u32 cfg; - unsigned int ch_idx =3D irq_to_channel(irq); - struct hpet_event_channel *ch =3D hpet_events + ch_idx; - - BUG_ON(ch_idx >=3D num_hpets_used); + struct hpet_event_channel *ch =3D desc->action->dev_id; =20 cfg =3D hpet_read32(HPET_Tn_CFG(ch->idx)); cfg |=3D HPET_TN_FSB; hpet_write32(cfg, HPET_Tn_CFG(ch->idx)); } =20 -static void hpet_msi_mask(unsigned int irq) +static void hpet_msi_mask(struct irq_desc *desc) { u32 cfg; - unsigned int ch_idx =3D irq_to_channel(irq); - struct hpet_event_channel *ch =3D hpet_events + ch_idx; - - BUG_ON(ch_idx >=3D num_hpets_used); + struct hpet_event_channel *ch =3D desc->action->dev_id; =20 cfg =3D hpet_read32(HPET_Tn_CFG(ch->idx)); cfg &=3D ~HPET_TN_FSB; @@ -271,30 +262,21 @@ static void hpet_msi_read(struct hpet_ev msg->address_hi =3D 0; } =20 -static unsigned int hpet_msi_startup(unsigned int irq) +static unsigned int hpet_msi_startup(struct irq_desc *desc) { - hpet_msi_unmask(irq); + hpet_msi_unmask(desc); return 0; } =20 -static void hpet_msi_shutdown(unsigned int irq) -{ - hpet_msi_mask(irq); -} +#define hpet_msi_shutdown hpet_msi_mask =20 -static void hpet_msi_ack(unsigned int irq) +static void hpet_msi_ack(struct irq_desc *desc) { - struct irq_desc *desc =3D irq_to_desc(irq); - irq_complete_move(desc); - move_native_irq(irq); + move_native_irq(desc); ack_APIC_irq(); } =20 -static void hpet_msi_end(unsigned int irq, u8 vector) -{ -} - static void hpet_msi_set_affinity(struct irq_desc *desc, const cpumask_t = *mask) { struct msi_msg msg; @@ -323,7 +305,6 @@ static hw_irq_controller hpet_msi_type =3D .enable =3D hpet_msi_unmask, .disable =3D hpet_msi_mask, .ack =3D hpet_msi_ack, - .end =3D hpet_msi_end, .set_affinity =3D hpet_msi_set_affinity, }; =20 @@ -335,14 +316,13 @@ static void __hpet_setup_msi_irq(struct=20 hpet_msi_write(desc->action->dev_id, &msg); } =20 -static int __init hpet_setup_msi_irq(unsigned int irq) +static int __init hpet_setup_msi_irq(unsigned int irq, struct hpet_event_c= hannel *ch) { int ret; irq_desc_t *desc =3D irq_to_desc(irq); =20 desc->handler =3D &hpet_msi_type; - ret =3D request_irq(irq, hpet_interrupt_handler, - 0, "HPET", hpet_events + irq_channel[irq]); + ret =3D request_irq(irq, hpet_interrupt_handler, 0, "HPET", ch); if ( ret < 0 ) return ret; =20 @@ -358,12 +338,9 @@ static int __init hpet_assign_irq(unsign if ( (irq =3D create_irq()) < 0 ) return irq; =20 - irq_channel[irq] =3D idx; - - if ( hpet_setup_msi_irq(irq) ) + if ( hpet_setup_msi_irq(irq, hpet_events + idx) ) { destroy_irq(irq); - irq_channel[irq] =3D -1; return -EINVAL; } =20 @@ -511,11 +488,6 @@ void __init hpet_broadcast_init(void) if ( hpet_rate =3D=3D 0 ) return; =20 - irq_channel =3D xmalloc_array(unsigned int, nr_irqs); - BUG_ON(irq_channel =3D=3D NULL); - for ( i =3D 0; i < nr_irqs; i++ ) - irq_channel[i] =3D -1; - cfg =3D hpet_read32(HPET_CFG); =20 hpet_fsb_cap_lookup(); @@ -527,9 +499,6 @@ void __init hpet_broadcast_init(void) } else { - xfree(irq_channel); - irq_channel =3D NULL; - hpet_id =3D hpet_read32(HPET_ID); if ( !(hpet_id & HPET_ID_LEGSUP) ) return; --- a/xen/arch/x86/i8259.c +++ b/xen/arch/x86/i8259.c @@ -85,18 +85,18 @@ BUILD_16_IRQS(0xc) BUILD_16_IRQS(0xd) BU =20 static DEFINE_SPINLOCK(i8259A_lock); =20 -static void mask_and_ack_8259A_irq(unsigned int irq); +static void mask_and_ack_8259A_irq(struct irq_desc *); =20 -static unsigned int startup_8259A_irq(unsigned int irq) +static unsigned int startup_8259A_irq(struct irq_desc *desc) { - enable_8259A_irq(irq); + enable_8259A_irq(desc); return 0; /* never anything pending */ } =20 -static void end_8259A_irq(unsigned int irq, u8 vector) +static void end_8259A_irq(struct irq_desc *desc, u8 vector) { - if (!(irq_desc[irq].status & (IRQ_DISABLED|IRQ_INPROGRESS))) - enable_8259A_irq(irq); + if (!(desc->status & (IRQ_DISABLED|IRQ_INPROGRESS))) + enable_8259A_irq(desc); } =20 static struct hw_interrupt_type __read_mostly i8259A_irq_type =3D { @@ -133,28 +133,28 @@ static unsigned int cached_irq_mask =3D 0x */ unsigned int __read_mostly io_apic_irqs; =20 -void disable_8259A_irq(unsigned int irq) +void disable_8259A_irq(struct irq_desc *desc) { - unsigned int mask =3D 1 << irq; + unsigned int mask =3D 1 << desc->irq; unsigned long flags; =20 spin_lock_irqsave(&i8259A_lock, flags); cached_irq_mask |=3D mask; - if (irq & 8) + if (desc->irq & 8) outb(cached_A1,0xA1); else outb(cached_21,0x21); spin_unlock_irqrestore(&i8259A_lock, flags); } =20 -void enable_8259A_irq(unsigned int irq) +void enable_8259A_irq(struct irq_desc *desc) { - unsigned int mask =3D ~(1 << irq); + unsigned int mask =3D ~(1 << desc->irq); unsigned long flags; =20 spin_lock_irqsave(&i8259A_lock, flags); cached_irq_mask &=3D mask; - if (irq & 8) + if (desc->irq & 8) outb(cached_A1,0xA1); else outb(cached_21,0x21); @@ -226,9 +226,9 @@ static inline int i8259A_irq_real(unsign * first, _then_ send the EOI, and the order of EOI * to the two 8259s is important! */ -static void mask_and_ack_8259A_irq(unsigned int irq) +static void mask_and_ack_8259A_irq(struct irq_desc *desc) { - unsigned int irqmask =3D 1 << irq; + unsigned int irqmask =3D 1 << desc->irq; unsigned long flags; =20 spin_lock_irqsave(&i8259A_lock, flags); @@ -252,15 +252,15 @@ static void mask_and_ack_8259A_irq(unsig cached_irq_mask |=3D irqmask; =20 handle_real_irq: - if (irq & 8) { + if (desc->irq & 8) { inb(0xA1); /* DUMMY - (do we need this?) */ outb(cached_A1,0xA1); - outb(0x60+(irq&7),0xA0);/* 'Specific EOI' to slave */ + outb(0x60 + (desc->irq & 7), 0xA0);/* 'Specific EOI' to slave */ outb(0x62,0x20); /* 'Specific EOI' to master-IRQ2 */ } else { inb(0x21); /* DUMMY - (do we need this?) */ outb(cached_21,0x21); - outb(0x60+irq,0x20); /* 'Specific EOI' to master */ + outb(0x60 + desc->irq, 0x20);/* 'Specific EOI' to master */ } spin_unlock_irqrestore(&i8259A_lock, flags); return; @@ -269,7 +269,7 @@ static void mask_and_ack_8259A_irq(unsig /* * this is the slow path - should happen rarely. */ - if (i8259A_irq_real(irq)) + if (i8259A_irq_real(desc->irq)) /* * oops, the IRQ _is_ in service according to the * 8259A - not spurious, go handle it. @@ -283,7 +283,7 @@ static void mask_and_ack_8259A_irq(unsig * lets ACK and report it. [once per IRQ] */ if (!(spurious_irq_mask & irqmask)) { - printk("spurious 8259A interrupt: IRQ%d.\n", irq); + printk("spurious 8259A interrupt: IRQ%d.\n", desc->irq); spurious_irq_mask |=3D irqmask; } /* --- a/xen/arch/x86/io_apic.c +++ b/xen/arch/x86/io_apic.c @@ -436,21 +436,21 @@ static void __level_IO_APIC_irq (unsigne __modify_IO_APIC_irq(irq, 0x00008000, 0); } =20 -static void mask_IO_APIC_irq (unsigned int irq) +static void mask_IO_APIC_irq(struct irq_desc *desc) { unsigned long flags; =20 spin_lock_irqsave(&ioapic_lock, flags); - __mask_IO_APIC_irq(irq); + __mask_IO_APIC_irq(desc->irq); spin_unlock_irqrestore(&ioapic_lock, flags); } =20 -static void unmask_IO_APIC_irq (unsigned int irq) +static void unmask_IO_APIC_irq(struct irq_desc *desc) { unsigned long flags; =20 spin_lock_irqsave(&ioapic_lock, flags); - __unmask_IO_APIC_irq(irq); + __unmask_IO_APIC_irq(desc->irq); spin_unlock_irqrestore(&ioapic_lock, flags); } =20 @@ -1145,7 +1145,7 @@ static void __init setup_IO_APIC_irqs(vo ioapic_register_intr(irq, IOAPIC_AUTO); =20 if (!apic && platform_legacy_irq(irq)) - disable_8259A_irq(irq); + disable_8259A_irq(irq_to_desc(irq)); } cfg =3D irq_cfg(irq); SET_DEST(entry.dest.dest32, entry.dest.logical.logical_dest, @@ -1170,7 +1170,7 @@ static void __init setup_ExtINT_IRQ0_pin =20 memset(&entry,0,sizeof(entry)); =20 - disable_8259A_irq(0); + disable_8259A_irq(irq_to_desc(0)); =20 /* mask LVT0 */ apic_write_around(APIC_LVT0, APIC_LVT_MASKED | APIC_DM_EXTINT); @@ -1199,7 +1199,7 @@ static void __init setup_ExtINT_IRQ0_pin */ ioapic_write_entry(apic, pin, 0, entry); =20 - enable_8259A_irq(0); + enable_8259A_irq(irq_to_desc(0)); } =20 static inline void UNEXPECTED_IO_APIC(void) @@ -1627,18 +1627,18 @@ static int __init timer_irq_works(void) * This is not complete - we should be able to fake * an edge even if it isn't on the 8259A... */ -static unsigned int startup_edge_ioapic_irq(unsigned int irq) +static unsigned int startup_edge_ioapic_irq(struct irq_desc *desc) { int was_pending =3D 0; unsigned long flags; =20 spin_lock_irqsave(&ioapic_lock, flags); - if (platform_legacy_irq(irq)) { - disable_8259A_irq(irq); - if (i8259A_irq_pending(irq)) + if (platform_legacy_irq(desc->irq)) { + disable_8259A_irq(desc); + if (i8259A_irq_pending(desc->irq)) was_pending =3D 1; } - __unmask_IO_APIC_irq(irq); + __unmask_IO_APIC_irq(desc->irq); spin_unlock_irqrestore(&ioapic_lock, flags); =20 return was_pending; @@ -1649,16 +1649,14 @@ static unsigned int startup_edge_ioapic_ * interrupt for real. This prevents IRQ storms from unhandled * devices. */ -static void ack_edge_ioapic_irq(unsigned int irq) +static void ack_edge_ioapic_irq(struct irq_desc *desc) { - struct irq_desc *desc =3D irq_to_desc(irq); - =20 irq_complete_move(desc); - move_native_irq(irq); + move_native_irq(desc); =20 if ((desc->status & (IRQ_PENDING | IRQ_DISABLED)) =3D=3D (IRQ_PENDING | IRQ_DISABLED)) - mask_IO_APIC_irq(irq); + mask_IO_APIC_irq(desc); ack_APIC_irq(); } =20 @@ -1676,9 +1674,9 @@ static void ack_edge_ioapic_irq(unsigned * generic IRQ layer and by the fact that an unacked local * APIC does not accept IRQs. */ -static unsigned int startup_level_ioapic_irq (unsigned int irq) +static unsigned int startup_level_ioapic_irq(struct irq_desc *desc) { - unmask_IO_APIC_irq(irq); + unmask_IO_APIC_irq(desc); =20 return 0; /* don't check for pending */ } @@ -1726,11 +1724,10 @@ static bool_t io_apic_level_ack_pending( return 0; } =20 -static void mask_and_ack_level_ioapic_irq (unsigned int irq) +static void mask_and_ack_level_ioapic_irq(struct irq_desc *desc) { unsigned long v; int i; - struct irq_desc *desc =3D irq_to_desc(irq); =20 irq_complete_move(desc); =20 @@ -1738,7 +1735,7 @@ static void mask_and_ack_level_ioapic_ir return; =20 if ( !directed_eoi_enabled ) - mask_IO_APIC_irq(irq); + mask_IO_APIC_irq(desc); =20 /* * It appears there is an erratum which affects at least version 0x11 @@ -1759,7 +1756,7 @@ static void mask_and_ack_level_ioapic_ir * operation to prevent an edge-triggered interrupt escaping meanwhile. * The idea is from Manfred Spraul. --macro */ - i =3D IO_APIC_VECTOR(irq); + i =3D IO_APIC_VECTOR(desc->irq); =20 v =3D apic_read(APIC_TMR + ((i & ~0x1f) >> 1)); =20 @@ -1768,19 +1765,19 @@ static void mask_and_ack_level_ioapic_ir if ( directed_eoi_enabled ) return; =20 - if ((irq_desc[irq].status & IRQ_MOVE_PENDING) && - !io_apic_level_ack_pending(irq)) + if ((desc->status & IRQ_MOVE_PENDING) && + !io_apic_level_ack_pending(desc->irq)) move_masked_irq(desc); =20 if ( !(v & (1 << (i & 0x1f))) ) { spin_lock(&ioapic_lock); - __edge_IO_APIC_irq(irq); - __level_IO_APIC_irq(irq); + __edge_IO_APIC_irq(desc->irq); + __level_IO_APIC_irq(desc->irq); spin_unlock(&ioapic_lock); } } =20 -static void end_level_ioapic_irq (unsigned int irq, u8 vector) +static void end_level_ioapic_irq(struct irq_desc *desc, u8 vector) { unsigned long v; int i; @@ -1789,23 +1786,21 @@ static void end_level_ioapic_irq (unsign { if ( directed_eoi_enabled ) { - struct irq_desc *desc =3D irq_to_desc(irq); - if ( !(desc->status & (IRQ_DISABLED|IRQ_MOVE_PENDING)) ) { - eoi_IO_APIC_irq(irq); + eoi_IO_APIC_irq(desc->irq); return; } =20 - mask_IO_APIC_irq(irq); - eoi_IO_APIC_irq(irq); + mask_IO_APIC_irq(desc); + eoi_IO_APIC_irq(desc->irq); if ( (desc->status & IRQ_MOVE_PENDING) && - !io_apic_level_ack_pending(irq) ) + !io_apic_level_ack_pending(desc->irq) ) move_masked_irq(desc); } =20 - if ( !(irq_desc[irq].status & IRQ_DISABLED) ) - unmask_IO_APIC_irq(irq); + if ( !(desc->status & IRQ_DISABLED) ) + unmask_IO_APIC_irq(desc); =20 return; } @@ -1829,7 +1824,7 @@ static void end_level_ioapic_irq (unsign * operation to prevent an edge-triggered interrupt escaping meanwhile. * The idea is from Manfred Spraul. --macro */ - i =3D IO_APIC_VECTOR(irq); + i =3D IO_APIC_VECTOR(desc->irq); =20 /* Manually EOI the old vector if we are moving to the new */ if ( vector && i !=3D vector ) @@ -1843,30 +1838,21 @@ static void end_level_ioapic_irq (unsign =20 ack_APIC_irq(); =20 - if ((irq_desc[irq].status & IRQ_MOVE_PENDING) && - !io_apic_level_ack_pending(irq)) - move_native_irq(irq); + if ( (desc->status & IRQ_MOVE_PENDING) && + !io_apic_level_ack_pending(desc->irq) ) + move_native_irq(desc); =20 if (!(v & (1 << (i & 0x1f)))) { spin_lock(&ioapic_lock); - __mask_IO_APIC_irq(irq); - __edge_IO_APIC_irq(irq); - __level_IO_APIC_irq(irq); - if ( !(irq_desc[irq].status & IRQ_DISABLED) ) - __unmask_IO_APIC_irq(irq); + __mask_IO_APIC_irq(desc->irq); + __edge_IO_APIC_irq(desc->irq); + __level_IO_APIC_irq(desc->irq); + if ( !(desc->status & IRQ_DISABLED) ) + __unmask_IO_APIC_irq(desc->irq); spin_unlock(&ioapic_lock); } } =20 -static void disable_edge_ioapic_irq(unsigned int irq) -{ -} - -static void end_edge_ioapic_irq(unsigned int irq, u8 vector) -{ -} - - /* * Level and edge triggered IO-APIC interrupts need different handling, * so we use two separate IRQ descriptors. Edge triggered IRQs can be @@ -1878,11 +1864,10 @@ static void end_edge_ioapic_irq(unsigned static hw_irq_controller ioapic_edge_type =3D { .typename =3D "IO-APIC-edge", .startup =3D startup_edge_ioapic_irq, - .shutdown =3D disable_edge_ioapic_irq, + .shutdown =3D irq_shutdown_none, .enable =3D unmask_IO_APIC_irq, - .disable =3D disable_edge_ioapic_irq, + .disable =3D irq_disable_none, .ack =3D ack_edge_ioapic_irq, - .end =3D end_edge_ioapic_irq, .set_affinity =3D set_ioapic_affinity_irq, }; =20 @@ -1897,26 +1882,24 @@ static hw_irq_controller ioapic_level_ty .set_affinity =3D set_ioapic_affinity_irq, }; =20 -static unsigned int startup_msi_irq(unsigned int irq) +static unsigned int startup_msi_irq(struct irq_desc *desc) { - unmask_msi_irq(irq); + unmask_msi_irq(desc); return 0; } =20 -static void ack_msi_irq(unsigned int irq) +static void ack_msi_irq(struct irq_desc *desc) { - struct irq_desc *desc =3D irq_to_desc(irq); - irq_complete_move(desc); - move_native_irq(irq); + move_native_irq(desc); =20 if ( msi_maskable_irq(desc->msi_desc) ) ack_APIC_irq(); /* ACKTYPE_NONE */ } =20 -static void end_msi_irq(unsigned int irq, u8 vector) +static void end_msi_irq(struct irq_desc *desc, u8 vector) { - if ( !msi_maskable_irq(irq_desc[irq].msi_desc) ) + if ( !msi_maskable_irq(desc->msi_desc) ) ack_APIC_irq(); /* ACKTYPE_EOI */ } =20 @@ -1946,7 +1929,7 @@ static inline void init_IO_APIC_traps(vo make_8259A_irq(irq); } =20 -static void enable_lapic_irq(unsigned int irq) +static void enable_lapic_irq(struct irq_desc *desc) { unsigned long v; =20 @@ -1954,7 +1937,7 @@ static void enable_lapic_irq(unsigned in apic_write_around(APIC_LVT0, v & ~APIC_LVT_MASKED); } =20 -static void disable_lapic_irq(unsigned int irq) +static void disable_lapic_irq(struct irq_desc *desc) { unsigned long v; =20 @@ -1962,13 +1945,11 @@ static void disable_lapic_irq(unsigned i apic_write_around(APIC_LVT0, v | APIC_LVT_MASKED); } =20 -static void ack_lapic_irq(unsigned int irq) +static void ack_lapic_irq(struct irq_desc *desc) { ack_APIC_irq(); } =20 -#define end_lapic_irq end_edge_ioapic_irq - static hw_irq_controller lapic_irq_type =3D { .typename =3D "local-APIC-edge", .startup =3D NULL, /* startup_irq() not used for IRQ0 */ @@ -1976,7 +1957,6 @@ static hw_irq_controller lapic_irq_type=20 .enable =3D enable_lapic_irq, .disable =3D disable_lapic_irq, .ack =3D ack_lapic_irq, - .end =3D end_lapic_irq, }; =20 /* @@ -2051,7 +2031,7 @@ static void __init check_timer(void) /* * get/set the timer IRQ vector: */ - disable_8259A_irq(0); + disable_8259A_irq(irq_to_desc(0)); vector =3D FIRST_HIPRIORITY_VECTOR; clear_irq_vector(0); =20 @@ -2071,7 +2051,7 @@ static void __init check_timer(void) init_8259A(1); /* XEN: Ripped out the legacy missed-tick logic, so below is not = needed. */ /*timer_ack =3D 1;*/ - /*enable_8259A_irq(0);*/ + /*enable_8259A_irq(irq_to_desc(0));*/ =20 pin1 =3D find_isa_irq_pin(0, mp_INT); apic1 =3D find_isa_irq_apic(0, mp_INT); @@ -2085,7 +2065,7 @@ static void __init check_timer(void) /* * Ok, does IRQ0 through the IOAPIC work? */ - unmask_IO_APIC_irq(0); + unmask_IO_APIC_irq(irq_to_desc(0)); if (timer_irq_works()) { local_irq_restore(flags); return; @@ -2125,10 +2105,10 @@ static void __init check_timer(void) =20 printk(KERN_INFO "...trying to set up timer as Virtual Wire IRQ..."); =20 - disable_8259A_irq(0); + disable_8259A_irq(irq_to_desc(0)); irq_desc[0].handler =3D &lapic_irq_type; apic_write_around(APIC_LVT0, APIC_DM_FIXED | vector); /* Fixed = mode */ - enable_8259A_irq(0); + enable_8259A_irq(irq_to_desc(0)); =20 if (timer_irq_works()) { local_irq_restore(flags); @@ -2401,7 +2381,7 @@ int io_apic_set_pci_routing (int ioapic, ioapic_register_intr(irq, edge_level); =20 if (!ioapic && platform_legacy_irq(irq)) - disable_8259A_irq(irq); + disable_8259A_irq(desc); =20 spin_lock_irqsave(&ioapic_lock, flags); __ioapic_write_entry(ioapic, pin, 0, entry); @@ -2410,7 +2390,7 @@ int io_apic_set_pci_routing (int ioapic, =20 spin_lock(&desc->lock); if (!(desc->status & (IRQ_DISABLED | IRQ_GUEST))) - desc->handler->startup(irq); + desc->handler->startup(desc); spin_unlock_irqrestore(&desc->lock, flags); =20 return 0; --- a/xen/arch/x86/irq.c +++ b/xen/arch/x86/irq.c @@ -192,7 +192,7 @@ static void dynamic_irq_cleanup(unsigned =20 spin_lock_irqsave(&desc->lock, flags); desc->status |=3D IRQ_DISABLED; - desc->handler->shutdown(irq); + desc->handler->shutdown(desc); action =3D desc->action; desc->action =3D NULL; desc->msi_desc =3D NULL; @@ -347,25 +347,20 @@ static void __do_IRQ_guest(int vector); =20 void no_action(int cpl, void *dev_id, struct cpu_user_regs *regs) { } =20 -static void enable_none(unsigned int vector) { } -static void end_none(unsigned int irq, u8 vector) { } -static unsigned int startup_none(unsigned int vector) { return 0; } -static void disable_none(unsigned int vector) { } -static void ack_none(unsigned int irq) +void irq_actor_none(struct irq_desc *desc) { } +unsigned int irq_startup_none(struct irq_desc *desc) { return 0; } +static void ack_none(struct irq_desc *desc) { - ack_bad_irq(irq); + ack_bad_irq(desc->irq); } =20 -#define shutdown_none disable_none - hw_irq_controller no_irq_type =3D { "none", - startup_none, - shutdown_none, - enable_none, - disable_none, + irq_startup_none, + irq_shutdown_none, + irq_enable_none, + irq_disable_none, ack_none, - end_none }; =20 static vmask_t *irq_get_used_vector_mask(int irq) @@ -585,19 +580,17 @@ void move_masked_irq(struct irq_desc *de cpus_clear(desc->pending_mask); } =20 -void move_native_irq(int irq) +void move_native_irq(struct irq_desc *desc) { - struct irq_desc *desc =3D irq_to_desc(irq); - if (likely(!(desc->status & IRQ_MOVE_PENDING))) return; =20 if (unlikely(desc->status & IRQ_DISABLED)) return; =20 - desc->handler->disable(irq); + desc->handler->disable(desc); move_masked_irq(desc); - desc->handler->enable(irq); + desc->handler->enable(desc); } =20 /* For re-setting irq interrupt affinity for specific irq */ @@ -654,7 +647,7 @@ asmlinkage void do_IRQ(struct cpu_user_r desc =3D irq_to_desc(irq); =20 spin_lock(&desc->lock); - desc->handler->ack(irq); + desc->handler->ack(desc); =20 if ( likely(desc->status & IRQ_GUEST) ) { @@ -664,7 +657,7 @@ asmlinkage void do_IRQ(struct cpu_user_r s_time_t now =3D NOW(); if ( now < (desc->rl_quantum_start + MILLISECS(10)) ) { - desc->handler->disable(irq); + desc->handler->disable(desc); /* * If handler->disable doesn't actually mask the = interrupt, a=20 * disabled irq still can fire. This check also avoids = possible=20 @@ -716,7 +709,8 @@ asmlinkage void do_IRQ(struct cpu_user_r desc->status &=3D ~IRQ_INPROGRESS; =20 out: - desc->handler->end(irq, regs->entry_vector); + if ( desc->handler->end ) + desc->handler->end(desc, regs->entry_vector); out_no_end: spin_unlock(&desc->lock); irq_exit(); @@ -733,7 +727,7 @@ static void irq_ratelimit_timer_fn(void=20 list_for_each_entry_safe ( desc, tmp, &irq_ratelimit_list, rl_link ) { spin_lock(&desc->lock); - desc->handler->enable(desc->irq); + desc->handler->enable(desc); list_del(&desc->rl_link); INIT_LIST_HEAD(&desc->rl_link); spin_unlock(&desc->lock); @@ -796,7 +790,7 @@ void __init release_irq(unsigned int irq action =3D desc->action; desc->action =3D NULL; desc->status |=3D IRQ_DISABLED; - desc->handler->shutdown(irq); + desc->handler->shutdown(desc); spin_unlock_irqrestore(&desc->lock,flags); =20 /* Wait to make sure it's not being used on another CPU */ @@ -823,7 +817,7 @@ int __init setup_irq(unsigned int irq, s =20 desc->action =3D new; desc->status &=3D ~IRQ_DISABLED; - desc->handler->startup(irq); + desc->handler->startup(desc); =20 spin_unlock_irqrestore(&desc->lock,flags); =20 @@ -914,7 +908,8 @@ static void irq_guest_eoi_timer_fn(void=20 switch ( action->ack_type ) { case ACKTYPE_UNMASK: - desc->handler->end(irq, 0); + if ( desc->handler->end ) + desc->handler->end(desc, 0); break; case ACKTYPE_EOI: cpu_eoi_map =3D action->cpu_eoi_map; @@ -942,7 +937,8 @@ static void __do_IRQ_guest(int irq) /* An interrupt may slip through while freeing an ACKTYPE_EOI = irq. */ ASSERT(action->ack_type =3D=3D ACKTYPE_EOI); ASSERT(desc->status & IRQ_DISABLED); - desc->handler->end(irq, vector); + if ( desc->handler->end ) + desc->handler->end(desc, vector); return; } =20 @@ -1156,7 +1152,8 @@ static void flush_ready_eoi(void) ASSERT(irq > 0); desc =3D irq_to_desc(irq); spin_lock(&desc->lock); - desc->handler->end(irq, peoi[sp].vector); + if ( desc->handler->end ) + desc->handler->end(desc, peoi[sp].vector); spin_unlock(&desc->lock); } =20 @@ -1234,7 +1231,8 @@ void desc_guest_eoi(struct irq_desc *des if ( action->ack_type =3D=3D ACKTYPE_UNMASK ) { ASSERT(cpus_empty(action->cpu_eoi_map)); - desc->handler->end(irq, 0); + if ( desc->handler->end ) + desc->handler->end(desc, 0); spin_unlock_irq(&desc->lock); return; } @@ -1402,7 +1400,7 @@ int pirq_guest_bind(struct vcpu *v, stru =20 desc->status |=3D IRQ_GUEST; desc->status &=3D ~IRQ_DISABLED; - desc->handler->startup(irq); + desc->handler->startup(desc); =20 /* Attempt to bind the interrupt target to the correct CPU. */ cpu_set(v->processor, cpumask); @@ -1486,8 +1484,9 @@ static irq_guest_action_t *__pirq_guest_ { case ACKTYPE_UNMASK: if ( test_and_clear_bool(pirq->masked) && - (--action->in_flight =3D=3D 0) ) - desc->handler->end(irq, 0); + (--action->in_flight =3D=3D 0) && + desc->handler->end ) + desc->handler->end(desc, 0); break; case ACKTYPE_EOI: /* NB. If #guests =3D=3D 0 then we clear the eoi_map later on. */ @@ -1516,7 +1515,7 @@ static irq_guest_action_t *__pirq_guest_ =20 /* Disabling IRQ before releasing the desc_lock avoids an IRQ storm. = */ desc->status |=3D IRQ_DISABLED; - desc->handler->disable(irq); + desc->handler->disable(desc); =20 /* * Mark any remaining pending EOIs as ready to flush. @@ -1538,7 +1537,7 @@ static irq_guest_action_t *__pirq_guest_ =20 desc->action =3D NULL; desc->status &=3D ~(IRQ_GUEST|IRQ_INPROGRESS); - desc->handler->shutdown(irq); + desc->handler->shutdown(desc); =20 /* Caller frees the old guest descriptor block. */ return action; @@ -1958,7 +1957,7 @@ void fixup_irqs(void) } =20 if ( desc->handler->disable ) - desc->handler->disable(irq); + desc->handler->disable(desc); =20 if ( desc->handler->set_affinity ) desc->handler->set_affinity(desc, &affinity); @@ -1966,7 +1965,7 @@ void fixup_irqs(void) set_affinity =3D 0; =20 if ( desc->handler->enable ) - desc->handler->enable(irq); + desc->handler->enable(desc); =20 spin_unlock(&desc->lock); =20 --- a/xen/arch/x86/msi.c +++ b/xen/arch/x86/msi.c @@ -336,11 +336,11 @@ int msi_maskable_irq(const struct msi_de || entry->msi_attrib.maskbit; } =20 -static void msi_set_mask_bit(unsigned int irq, int flag) +static void msi_set_mask_bit(struct irq_desc *desc, int flag) { - struct msi_desc *entry =3D irq_desc[irq].msi_desc; + struct msi_desc *entry =3D desc->msi_desc; =20 - ASSERT(spin_is_locked(&irq_desc[irq].lock)); + ASSERT(spin_is_locked(&desc->lock)); BUG_ON(!entry || !entry->dev); switch (entry->msi_attrib.type) { case PCI_CAP_ID_MSI: @@ -387,14 +387,14 @@ static int msi_get_mask_bit(const struct return -1; } =20 -void mask_msi_irq(unsigned int irq) +void mask_msi_irq(struct irq_desc *desc) { - msi_set_mask_bit(irq, 1); + msi_set_mask_bit(desc, 1); } =20 -void unmask_msi_irq(unsigned int irq) +void unmask_msi_irq(struct irq_desc *desc) { - msi_set_mask_bit(irq, 0); + msi_set_mask_bit(desc, 0); } =20 static struct msi_desc* alloc_msi_entry(void) @@ -974,7 +974,7 @@ int pci_restore_msi_state(struct pci_dev =20 write_msi_msg(entry, &entry->msg); =20 - msi_set_mask_bit(irq, entry->msi_attrib.masked); + msi_set_mask_bit(desc, entry->msi_attrib.masked); =20 if ( entry->msi_attrib.type =3D=3D PCI_CAP_ID_MSI ) msi_set_enable(pdev, 1); --- a/xen/drivers/passthrough/amd/iommu_init.c +++ b/xen/drivers/passthrough/amd/iommu_init.c @@ -29,7 +29,6 @@ #include <asm-x86/fixmap.h> #include <mach_apic.h> =20 -static struct amd_iommu **__read_mostly irq_to_iommu; static int __initdata nr_amd_iommus; =20 unsigned short ivrs_bdf_entries; @@ -403,10 +402,10 @@ static void amd_iommu_msi_enable(struct=20 iommu->msi_cap + PCI_MSI_FLAGS, control); } =20 -static void iommu_msi_unmask(unsigned int irq) +static void iommu_msi_unmask(struct irq_desc *desc) { unsigned long flags; - struct amd_iommu *iommu =3D irq_to_iommu[irq]; + struct amd_iommu *iommu =3D desc->action->dev_id; =20 /* FIXME: do not support mask bits at the moment */ if ( iommu->maskbit ) @@ -417,11 +416,10 @@ static void iommu_msi_unmask(unsigned in spin_unlock_irqrestore(&iommu->lock, flags); } =20 -static void iommu_msi_mask(unsigned int irq) +static void iommu_msi_mask(struct irq_desc *desc) { unsigned long flags; - struct amd_iommu *iommu =3D irq_to_iommu[irq]; - struct irq_desc *desc =3D irq_to_desc(irq); + struct amd_iommu *iommu =3D desc->action->dev_id; =20 irq_complete_move(desc); =20 @@ -434,15 +432,15 @@ static void iommu_msi_mask(unsigned int=20 spin_unlock_irqrestore(&iommu->lock, flags); } =20 -static unsigned int iommu_msi_startup(unsigned int irq) +static unsigned int iommu_msi_startup(struct irq_desc *desc) { - iommu_msi_unmask(irq); + iommu_msi_unmask(desc); return 0; } =20 -static void iommu_msi_end(unsigned int irq, u8 vector) +static void iommu_msi_end(struct irq_desc *desc, u8 vector) { - iommu_msi_unmask(irq); + iommu_msi_unmask(desc); ack_APIC_irq(); } =20 @@ -557,13 +555,11 @@ static int __init set_iommu_interrupt_ha } =20 irq_desc[irq].handler =3D &iommu_msi_type; - irq_to_iommu[irq] =3D iommu; ret =3D request_irq(irq, amd_iommu_page_fault, 0, "amd_iommu", iommu); if ( ret ) { irq_desc[irq].handler =3D &no_irq_type; - irq_to_iommu[irq] =3D NULL; destroy_irq(irq); AMD_IOMMU_DEBUG("can't request irq\n"); return 0; @@ -728,13 +724,6 @@ static void __init amd_iommu_init_cleanu ivrs_mappings =3D NULL; } =20 - /* free irq_to_iommu[] */ - if ( irq_to_iommu ) - { - xfree(irq_to_iommu); - irq_to_iommu =3D NULL; - } - iommu_enabled =3D 0; iommu_passthrough =3D 0; iommu_intremap =3D 0; @@ -838,11 +827,6 @@ int __init amd_iommu_init(void) =20 BUG_ON( !iommu_found() ); =20 - irq_to_iommu =3D xmalloc_array(struct amd_iommu *, nr_irqs); - if ( irq_to_iommu =3D=3D NULL ) - goto error_out; - memset(irq_to_iommu, 0, nr_irqs * sizeof(struct iommu*)); - ivrs_bdf_entries =3D amd_iommu_get_ivrs_dev_entries(); =20 if ( !ivrs_bdf_entries ) --- a/xen/drivers/passthrough/vtd/iommu.c +++ b/xen/drivers/passthrough/vtd/iommu.c @@ -829,7 +829,6 @@ static const char *iommu_get_fault_reaso } } =20 -static struct iommu **irq_to_iommu; static int iommu_page_fault_do_one(struct iommu *iommu, int type, u8 fault_reason, u16 source_id, u64 = addr) { @@ -961,9 +960,9 @@ clear_overflow: } } =20 -static void dma_msi_unmask(unsigned int irq) +static void dma_msi_unmask(struct irq_desc *desc) { - struct iommu *iommu =3D irq_to_iommu[irq]; + struct iommu *iommu =3D desc->action->dev_id; unsigned long flags; =20 /* unmask it */ @@ -972,11 +971,10 @@ static void dma_msi_unmask(unsigned int=20 spin_unlock_irqrestore(&iommu->register_lock, flags); } =20 -static void dma_msi_mask(unsigned int irq) +static void dma_msi_mask(struct irq_desc *desc) { unsigned long flags; - struct iommu *iommu =3D irq_to_iommu[irq]; - struct irq_desc *desc =3D irq_to_desc(irq); + struct iommu *iommu =3D desc->action->dev_id; =20 irq_complete_move(desc); =20 @@ -986,15 +984,15 @@ static void dma_msi_mask(unsigned int ir spin_unlock_irqrestore(&iommu->register_lock, flags); } =20 -static unsigned int dma_msi_startup(unsigned int irq) +static unsigned int dma_msi_startup(struct irq_desc *desc) { - dma_msi_unmask(irq); + dma_msi_unmask(desc); return 0; } =20 -static void dma_msi_end(unsigned int irq, u8 vector) +static void dma_msi_end(struct irq_desc *desc, u8 vector) { - dma_msi_unmask(irq); + dma_msi_unmask(desc); ack_APIC_irq(); } =20 @@ -1071,7 +1069,6 @@ static int __init iommu_set_interrupt(st } =20 irq_desc[irq].handler =3D &dma_msi_type; - irq_to_iommu[irq] =3D iommu; #ifdef CONFIG_X86 ret =3D request_irq(irq, iommu_page_fault, 0, "dmar", iommu); #else @@ -1080,7 +1077,6 @@ static int __init iommu_set_interrupt(st if ( ret ) { irq_desc[irq].handler =3D &no_irq_type; - irq_to_iommu[irq] =3D NULL; destroy_irq(irq); dprintk(XENLOG_ERR VTDPREFIX, "IOMMU: can't request irq\n"); return ret; @@ -2091,13 +2087,6 @@ int __init intel_vtd_setup(void) =20 platform_quirks_init(); =20 - irq_to_iommu =3D xmalloc_array(struct iommu*, nr_irqs); - BUG_ON(!irq_to_iommu); - memset(irq_to_iommu, 0, nr_irqs * sizeof(struct iommu*)); - - if(!irq_to_iommu) - return -ENOMEM; - /* We enable the following features only if they are supported by all = VT-d * engines: Snoop Control, DMA passthrough, Queued Invalidation and * Interrupt Remapping. --- a/xen/include/asm-x86/irq.h +++ b/xen/include/asm-x86/irq.h @@ -27,6 +27,8 @@ typedef struct { DECLARE_BITMAP(_bits,NR_VECTORS); } vmask_t; =20 +struct irq_desc; + struct irq_cfg { s16 vector; /* vector itself is only 8 bits, */ s16 old_vector; /* but we use -1 for unassigned */ @@ -107,8 +109,8 @@ fastcall void smp_irq_move_cleanup_inter =20 asmlinkage void do_IRQ(struct cpu_user_regs *regs); =20 -void disable_8259A_irq(unsigned int irq); -void enable_8259A_irq(unsigned int irq); +void disable_8259A_irq(struct irq_desc *); +void enable_8259A_irq(struct irq_desc *); int i8259A_irq_pending(unsigned int irq); void mask_8259A(void); void unmask_8259A(void); @@ -161,7 +163,6 @@ int irq_to_vector(int irq); int create_irq(void); void destroy_irq(unsigned int irq); =20 -struct irq_desc; extern void irq_complete_move(struct irq_desc *); =20 extern struct irq_desc *irq_desc; @@ -171,7 +172,7 @@ void unlock_vector_lock(void); =20 void __setup_vector_irq(int cpu); =20 -void move_native_irq(int irq); +void move_native_irq(struct irq_desc *); void move_masked_irq(struct irq_desc *); =20 int __assign_irq_vector(int irq, struct irq_cfg *, const cpumask_t *); --- a/xen/include/asm-x86/msi.h +++ b/xen/include/asm-x86/msi.h @@ -75,8 +75,8 @@ struct msi_msg { =20 struct msi_desc; /* Helper functions */ -extern void mask_msi_irq(unsigned int irq); -extern void unmask_msi_irq(unsigned int irq); +extern void mask_msi_irq(struct irq_desc *); +extern void unmask_msi_irq(struct irq_desc *); extern void set_msi_affinity(struct irq_desc *, const cpumask_t *); extern int pci_enable_msi(struct msi_info *msi, struct msi_desc **desc); extern void pci_disable_msi(struct msi_desc *desc); --- a/xen/include/xen/irq.h +++ b/xen/include/xen/irq.h @@ -41,12 +41,12 @@ struct irq_desc; */ struct hw_interrupt_type { const char *typename; - unsigned int (*startup)(unsigned int irq); - void (*shutdown)(unsigned int irq); - void (*enable)(unsigned int irq); - void (*disable)(unsigned int irq); - void (*ack)(unsigned int irq); - void (*end)(unsigned int irq, u8 vector); + unsigned int (*startup)(struct irq_desc *); + void (*shutdown)(struct irq_desc *); + void (*enable)(struct irq_desc *); + void (*disable)(struct irq_desc *); + void (*ack)(struct irq_desc *); + void (*end)(struct irq_desc *, u8 vector); void (*set_affinity)(struct irq_desc *, const cpumask_t *); }; =20 @@ -133,6 +133,11 @@ extern int request_irq(unsigned int irq, =20 extern hw_irq_controller no_irq_type; extern void no_action(int cpl, void *dev_id, struct cpu_user_regs *regs); +extern unsigned int irq_startup_none(struct irq_desc *); +extern void irq_actor_none(struct irq_desc *); +#define irq_shutdown_none irq_actor_none +#define irq_disable_none irq_actor_none +#define irq_enable_none irq_actor_none =20 struct domain; struct vcpu; --=__Part3A1501D0.0__= Content-Type: text/plain; name="irq-controller-actions-desc.patch" Content-Transfer-Encoding: quoted-printable Content-Disposition: attachment; filename="irq-controller-actions-desc.patch" This is again because the descriptor is generally more useful (with=0Athe = IRQ number being accessible in it if necessary) and going forward=0Awill = hopefully allow to remove all direct accesses to the IRQ=0Adescriptor = array, in turn making it possible to make this some other,=0Amore = efficient data structure.=0A=0AThis additionally makes the .end() accessor = optional, noting that in a=0Anumber of cases the functions were = empty.=0A=0ASigned-off-by: Jan Beulich <jbeulich@suse.com>=0A=0A--- = a/xen/arch/ia64/linux-xen/iosapic.c=0A+++ b/xen/arch/ia64/linux-xen/iosapic= .c=0A@@ -276,7 +276,7 @@ set_rte (unsigned int gsi, unsigned int =0A }=0A = =0A static void=0A-nop (unsigned int vector)=0A+nop (struct irq_desc = *desc)=0A {=0A /* do nothing... */=0A }=0A@@ -300,13 +300,13 @@ kexec_disa= ble_iosapic(void)=0A }=0A =0A static void=0A-mask_irq (unsigned int = irq)=0A+mask_irq (struct irq_desc *desc)=0A {=0A unsigned long = flags;=0A char __iomem *addr;=0A u32 low32;=0A int rte_index;=0A- = ia64_vector vec =3D irq_to_vector(irq);=0A+ ia64_vector vec =3D = irq_to_vector(desc->irq);=0A struct iosapic_rte_info *rte;=0A =0A if = (list_empty(&iosapic_intr_info[vec].rtes))=0A@@ -326,13 +326,13 @@ = mask_irq (unsigned int irq)=0A }=0A =0A static void=0A-unmask_irq = (unsigned int irq)=0A+unmask_irq (struct irq_desc *desc)=0A {=0A = unsigned long flags;=0A char __iomem *addr;=0A u32 low32;=0A = int rte_index;=0A- ia64_vector vec =3D irq_to_vector(irq);=0A+ = ia64_vector vec =3D irq_to_vector(desc->irq);=0A struct iosapic_rte_= info *rte;=0A =0A if (list_empty(&iosapic_intr_info[vec].rtes))=0A@@ = -408,19 +408,19 @@ iosapic_set_affinity (struct irq_desc *d=0A */=0A =0A = static unsigned int=0A-iosapic_startup_level_irq (unsigned int irq)=0A+iosa= pic_startup_level_irq (struct irq_desc *desc)=0A {=0A- unmask_irq(irq);=0A= + unmask_irq(desc);=0A return 0;=0A }=0A =0A static void=0A-iosapi= c_end_level_irq (unsigned int irq)=0A+iosapic_end_level_irq (struct = irq_desc *desc)=0A {=0A- ia64_vector vec =3D irq_to_vector(irq);=0A+= ia64_vector vec =3D irq_to_vector(desc->irq);=0A struct = iosapic_rte_info *rte;=0A =0A- move_irq(irq);=0A+ move_irq(desc->irq)= ;=0A list_for_each_entry(rte, &iosapic_intr_info[vec].rtes, rte_list)=0A= iosapic_eoi(rte->addr, vec);=0A }=0A--- a/xen/arch/x86/hpet= .c=0A+++ b/xen/arch/x86/hpet.c=0A@@ -49,9 +49,6 @@ static unsigned int = __read_mostly num_hp=0A =0A DEFINE_PER_CPU(struct hpet_event_channel *, = cpu_bc_channel);=0A =0A-static unsigned int *__read_mostly irq_channel;=0A-= #define irq_to_channel(irq) irq_channel[irq]=0A-=0A unsigned long = __read_mostly hpet_address;=0A =0A /*=0A@@ -232,26 +229,20 @@ static void = hpet_interrupt_handler(int i=0A ch->event_handler(ch);=0A }=0A = =0A-static void hpet_msi_unmask(unsigned int irq)=0A+static void hpet_msi_u= nmask(struct irq_desc *desc)=0A {=0A u32 cfg;=0A- unsigned int = ch_idx =3D irq_to_channel(irq);=0A- struct hpet_event_channel *ch =3D = hpet_events + ch_idx;=0A-=0A- BUG_ON(ch_idx >=3D num_hpets_used);=0A+ = struct hpet_event_channel *ch =3D desc->action->dev_id;=0A =0A cfg = =3D hpet_read32(HPET_Tn_CFG(ch->idx));=0A cfg |=3D HPET_TN_FSB;=0A = hpet_write32(cfg, HPET_Tn_CFG(ch->idx));=0A }=0A =0A-static void hpet_msi_m= ask(unsigned int irq)=0A+static void hpet_msi_mask(struct irq_desc = *desc)=0A {=0A u32 cfg;=0A- unsigned int ch_idx =3D irq_to_channel(i= rq);=0A- struct hpet_event_channel *ch =3D hpet_events + ch_idx;=0A-=0A-= BUG_ON(ch_idx >=3D num_hpets_used);=0A+ struct hpet_event_channel = *ch =3D desc->action->dev_id;=0A =0A cfg =3D hpet_read32(HPET_Tn_CFG(ch= ->idx));=0A cfg &=3D ~HPET_TN_FSB;=0A@@ -271,30 +262,21 @@ static void = hpet_msi_read(struct hpet_ev=0A msg->address_hi =3D 0;=0A }=0A = =0A-static unsigned int hpet_msi_startup(unsigned int irq)=0A+static = unsigned int hpet_msi_startup(struct irq_desc *desc)=0A {=0A- hpet_msi_u= nmask(irq);=0A+ hpet_msi_unmask(desc);=0A return 0;=0A }=0A = =0A-static void hpet_msi_shutdown(unsigned int irq)=0A-{=0A- hpet_msi_ma= sk(irq);=0A-}=0A+#define hpet_msi_shutdown hpet_msi_mask=0A =0A-static = void hpet_msi_ack(unsigned int irq)=0A+static void hpet_msi_ack(struct = irq_desc *desc)=0A {=0A- struct irq_desc *desc =3D irq_to_desc(irq);=0A-= =0A irq_complete_move(desc);=0A- move_native_irq(irq);=0A+ = move_native_irq(desc);=0A ack_APIC_irq();=0A }=0A =0A-static void = hpet_msi_end(unsigned int irq, u8 vector)=0A-{=0A-}=0A-=0A static void = hpet_msi_set_affinity(struct irq_desc *desc, const cpumask_t *mask)=0A = {=0A struct msi_msg msg;=0A@@ -323,7 +305,6 @@ static hw_irq_controller= hpet_msi_type =3D=0A .enable =3D hpet_msi_unmask,=0A = .disable =3D hpet_msi_mask,=0A .ack =3D hpet_msi_ack,=0A- = .end =3D hpet_msi_end,=0A .set_affinity =3D hpet_msi_set_affin= ity,=0A };=0A =0A@@ -335,14 +316,13 @@ static void __hpet_setup_msi_irq(str= uct =0A hpet_msi_write(desc->action->dev_id, &msg);=0A }=0A =0A-static = int __init hpet_setup_msi_irq(unsigned int irq)=0A+static int __init = hpet_setup_msi_irq(unsigned int irq, struct hpet_event_channel *ch)=0A = {=0A int ret;=0A irq_desc_t *desc =3D irq_to_desc(irq);=0A =0A = desc->handler =3D &hpet_msi_type;=0A- ret =3D request_irq(irq, = hpet_interrupt_handler,=0A- 0, "HPET", hpet_events + = irq_channel[irq]);=0A+ ret =3D request_irq(irq, hpet_interrupt_handler, = 0, "HPET", ch);=0A if ( ret < 0 )=0A return ret;=0A =0A@@ = -358,12 +338,9 @@ static int __init hpet_assign_irq(unsign=0A if ( = (irq =3D create_irq()) < 0 )=0A return irq;=0A =0A- irq_channel[= irq] =3D idx;=0A-=0A- if ( hpet_setup_msi_irq(irq) )=0A+ if ( = hpet_setup_msi_irq(irq, hpet_events + idx) )=0A {=0A destroy_ir= q(irq);=0A- irq_channel[irq] =3D -1;=0A return -EINVAL;=0A = }=0A =0A@@ -511,11 +488,6 @@ void __init hpet_broadcast_init(void)=0A = if ( hpet_rate =3D=3D 0 )=0A return;=0A =0A- irq_channel =3D = xmalloc_array(unsigned int, nr_irqs);=0A- BUG_ON(irq_channel =3D=3D = NULL);=0A- for ( i =3D 0; i < nr_irqs; i++ )=0A- irq_channel[i] = =3D -1;=0A-=0A cfg =3D hpet_read32(HPET_CFG);=0A =0A hpet_fsb_cap_l= ookup();=0A@@ -527,9 +499,6 @@ void __init hpet_broadcast_init(void)=0A = }=0A else=0A {=0A- xfree(irq_channel);=0A- = irq_channel =3D NULL;=0A-=0A hpet_id =3D hpet_read32(HPET_ID);=0A = if ( !(hpet_id & HPET_ID_LEGSUP) )=0A return;=0A--- = a/xen/arch/x86/i8259.c=0A+++ b/xen/arch/x86/i8259.c=0A@@ -85,18 +85,18 @@ = BUILD_16_IRQS(0xc) BUILD_16_IRQS(0xd) BU=0A =0A static DEFINE_SPINLOCK(i825= 9A_lock);=0A =0A-static void mask_and_ack_8259A_irq(unsigned int irq);=0A+s= tatic void mask_and_ack_8259A_irq(struct irq_desc *);=0A =0A-static = unsigned int startup_8259A_irq(unsigned int irq)=0A+static unsigned int = startup_8259A_irq(struct irq_desc *desc)=0A {=0A- enable_8259A_irq(irq);= =0A+ enable_8259A_irq(desc);=0A return 0; /* never anything pending = */=0A }=0A =0A-static void end_8259A_irq(unsigned int irq, u8 vector)=0A+st= atic void end_8259A_irq(struct irq_desc *desc, u8 vector)=0A {=0A- if = (!(irq_desc[irq].status & (IRQ_DISABLED|IRQ_INPROGRESS)))=0A- = enable_8259A_irq(irq);=0A+ if (!(desc->status & (IRQ_DISABLED|IRQ_INPROG= RESS)))=0A+ enable_8259A_irq(desc);=0A }=0A =0A static struct = hw_interrupt_type __read_mostly i8259A_irq_type =3D {=0A@@ -133,28 +133,28 = @@ static unsigned int cached_irq_mask =3D 0x=0A */=0A unsigned int = __read_mostly io_apic_irqs;=0A =0A-void disable_8259A_irq(unsigned int = irq)=0A+void disable_8259A_irq(struct irq_desc *desc)=0A {=0A- unsigned = int mask =3D 1 << irq;=0A+ unsigned int mask =3D 1 << desc->irq;=0A = unsigned long flags;=0A =0A spin_lock_irqsave(&i8259A_lock, flags);=0A = cached_irq_mask |=3D mask;=0A- if (irq & 8)=0A+ if (desc->irq & = 8)=0A outb(cached_A1,0xA1);=0A else=0A outb(cached_21,0= x21);=0A spin_unlock_irqrestore(&i8259A_lock, flags);=0A }=0A =0A-void = enable_8259A_irq(unsigned int irq)=0A+void enable_8259A_irq(struct = irq_desc *desc)=0A {=0A- unsigned int mask =3D ~(1 << irq);=0A+ = unsigned int mask =3D ~(1 << desc->irq);=0A unsigned long flags;=0A = =0A spin_lock_irqsave(&i8259A_lock, flags);=0A cached_irq_mask = &=3D mask;=0A- if (irq & 8)=0A+ if (desc->irq & 8)=0A = outb(cached_A1,0xA1);=0A else=0A outb(cached_21,0x21);=0A@@ = -226,9 +226,9 @@ static inline int i8259A_irq_real(unsign=0A * first, = _then_ send the EOI, and the order of EOI=0A * to the two 8259s is = important!=0A */=0A-static void mask_and_ack_8259A_irq(unsigned int = irq)=0A+static void mask_and_ack_8259A_irq(struct irq_desc *desc)=0A {=0A- = unsigned int irqmask =3D 1 << irq;=0A+ unsigned int irqmask =3D 1 << = desc->irq;=0A unsigned long flags;=0A =0A spin_lock_irqsave(&i8259A= _lock, flags);=0A@@ -252,15 +252,15 @@ static void mask_and_ack_8259A_irq(u= nsig=0A cached_irq_mask |=3D irqmask;=0A =0A handle_real_irq:=0A- = if (irq & 8) {=0A+ if (desc->irq & 8) {=0A inb(0xA1); = /* DUMMY - (do we need this?) */=0A outb(cached_A1,0xA1);=0A- = outb(0x60+(irq&7),0xA0);/* 'Specific EOI' to slave */=0A+ = outb(0x60 + (desc->irq & 7), 0xA0);/* 'Specific EOI' to slave */=0A = outb(0x62,0x20); /* 'Specific EOI' to master-IRQ2 */=0A } else = {=0A inb(0x21); /* DUMMY - (do we need this?) */=0A = outb(cached_21,0x21);=0A- outb(0x60+irq,0x20); /* = 'Specific EOI' to master */=0A+ outb(0x60 + desc->irq, 0x20);/* = 'Specific EOI' to master */=0A }=0A spin_unlock_irqrestore(&i8259A_= lock, flags);=0A return;=0A@@ -269,7 +269,7 @@ static void mask_and_ack= _8259A_irq(unsig=0A /*=0A * this is the slow path - should happen = rarely.=0A */=0A- if (i8259A_irq_real(irq))=0A+ if (i8259A_irq_r= eal(desc->irq))=0A /*=0A * oops, the IRQ _is_ in service = according to the=0A * 8259A - not spurious, go handle it.=0A@@ = -283,7 +283,7 @@ static void mask_and_ack_8259A_irq(unsig=0A * = lets ACK and report it. [once per IRQ]=0A */=0A if = (!(spurious_irq_mask & irqmask)) {=0A- printk("spurious 8259A = interrupt: IRQ%d.\n", irq);=0A+ printk("spurious 8259A = interrupt: IRQ%d.\n", desc->irq);=0A spurious_irq_mask |=3D = irqmask;=0A }=0A /*=0A--- a/xen/arch/x86/io_apic.c=0A+++ = b/xen/arch/x86/io_apic.c=0A@@ -436,21 +436,21 @@ static void __level_IO_API= C_irq (unsigne=0A __modify_IO_APIC_irq(irq, 0x00008000, 0);=0A }=0A = =0A-static void mask_IO_APIC_irq (unsigned int irq)=0A+static void = mask_IO_APIC_irq(struct irq_desc *desc)=0A {=0A unsigned long = flags;=0A =0A spin_lock_irqsave(&ioapic_lock, flags);=0A- __mask_IO_= APIC_irq(irq);=0A+ __mask_IO_APIC_irq(desc->irq);=0A spin_unlock_irq= restore(&ioapic_lock, flags);=0A }=0A =0A-static void unmask_IO_APIC_irq = (unsigned int irq)=0A+static void unmask_IO_APIC_irq(struct irq_desc = *desc)=0A {=0A unsigned long flags;=0A =0A spin_lock_irqsave(&ioapi= c_lock, flags);=0A- __unmask_IO_APIC_irq(irq);=0A+ __unmask_IO_APIC_i= rq(desc->irq);=0A spin_unlock_irqrestore(&ioapic_lock, flags);=0A }=0A = =0A@@ -1145,7 +1145,7 @@ static void __init setup_IO_APIC_irqs(vo=0A = ioapic_register_intr(irq, IOAPIC_AUTO);=0A =0A = if (!apic && platform_legacy_irq(irq))=0A- disable_8259A= _irq(irq);=0A+ disable_8259A_irq(irq_to_desc(irq));=0A = }=0A cfg =3D irq_cfg(irq);=0A SET_DEST(e= ntry.dest.dest32, entry.dest.logical.logical_dest,=0A@@ -1170,7 +1170,7 @@ = static void __init setup_ExtINT_IRQ0_pin=0A =0A memset(&entry,0,sizeof(= entry));=0A =0A- disable_8259A_irq(0);=0A+ disable_8259A_irq(irq_to_d= esc(0));=0A =0A /* mask LVT0 */=0A apic_write_around(APIC_LVT0, = APIC_LVT_MASKED | APIC_DM_EXTINT);=0A@@ -1199,7 +1199,7 @@ static void = __init setup_ExtINT_IRQ0_pin=0A */=0A ioapic_write_entry(apic, = pin, 0, entry);=0A =0A- enable_8259A_irq(0);=0A+ enable_8259A_irq(irq= _to_desc(0));=0A }=0A =0A static inline void UNEXPECTED_IO_APIC(void)=0A@@ = -1627,18 +1627,18 @@ static int __init timer_irq_works(void)=0A * This is = not complete - we should be able to fake=0A * an edge even if it isn't on = the 8259A...=0A */=0A-static unsigned int startup_edge_ioapic_irq(unsigned= int irq)=0A+static unsigned int startup_edge_ioapic_irq(struct irq_desc = *desc)=0A {=0A int was_pending =3D 0;=0A unsigned long flags;=0A = =0A spin_lock_irqsave(&ioapic_lock, flags);=0A- if (platform_legacy_= irq(irq)) {=0A- disable_8259A_irq(irq);=0A- if (i8259A_irq_pe= nding(irq))=0A+ if (platform_legacy_irq(desc->irq)) {=0A+ = disable_8259A_irq(desc);=0A+ if (i8259A_irq_pending(desc->irq))=0A = was_pending =3D 1;=0A }=0A- __unmask_IO_APIC_irq(irq);=0A= + __unmask_IO_APIC_irq(desc->irq);=0A spin_unlock_irqrestore(&ioapic= _lock, flags);=0A =0A return was_pending;=0A@@ -1649,16 +1649,14 @@ = static unsigned int startup_edge_ioapic_=0A * interrupt for real. This = prevents IRQ storms from unhandled=0A * devices.=0A */=0A-static void = ack_edge_ioapic_irq(unsigned int irq)=0A+static void ack_edge_ioapic_irq(st= ruct irq_desc *desc)=0A {=0A- struct irq_desc *desc =3D irq_to_desc(irq)= ;=0A- =0A irq_complete_move(desc);=0A- move_native_irq(irq);=0A+ = move_native_irq(desc);=0A =0A if ((desc->status & (IRQ_PENDING | = IRQ_DISABLED))=0A =3D=3D (IRQ_PENDING | IRQ_DISABLED))=0A- = mask_IO_APIC_irq(irq);=0A+ mask_IO_APIC_irq(desc);=0A ack_APIC_i= rq();=0A }=0A =0A@@ -1676,9 +1674,9 @@ static void ack_edge_ioapic_irq(unsi= gned=0A * generic IRQ layer and by the fact that an unacked local=0A * = APIC does not accept IRQs.=0A */=0A-static unsigned int startup_level_ioap= ic_irq (unsigned int irq)=0A+static unsigned int startup_level_ioapic_irq(s= truct irq_desc *desc)=0A {=0A- unmask_IO_APIC_irq(irq);=0A+ = unmask_IO_APIC_irq(desc);=0A =0A return 0; /* don't check for pending = */=0A }=0A@@ -1726,11 +1724,10 @@ static bool_t io_apic_level_ack_pending(= =0A return 0;=0A }=0A =0A-static void mask_and_ack_level_ioapic_irq = (unsigned int irq)=0A+static void mask_and_ack_level_ioapic_irq(struct = irq_desc *desc)=0A {=0A unsigned long v;=0A int i;=0A- struct = irq_desc *desc =3D irq_to_desc(irq);=0A =0A irq_complete_move(desc);=0A= =0A@@ -1738,7 +1735,7 @@ static void mask_and_ack_level_ioapic_ir=0A = return;=0A =0A if ( !directed_eoi_enabled )=0A- mask_IO_APIC_= irq(irq);=0A+ mask_IO_APIC_irq(desc);=0A =0A /*=0A * It appears = there is an erratum which affects at least version 0x11=0A@@ -1759,7 = +1756,7 @@ static void mask_and_ack_level_ioapic_ir=0A * operation to = prevent an edge-triggered interrupt escaping meanwhile.=0A * The idea is = from Manfred Spraul. --macro=0A */=0A- i =3D IO_APIC_VECTOR(irq);=0A+ = i =3D IO_APIC_VECTOR(desc->irq);=0A =0A v =3D apic_read(APIC_TMR + = ((i & ~0x1f) >> 1));=0A =0A@@ -1768,19 +1765,19 @@ static void mask_and_ack= _level_ioapic_ir=0A if ( directed_eoi_enabled )=0A return;=0A = =0A- if ((irq_desc[irq].status & IRQ_MOVE_PENDING) &&=0A- = !io_apic_level_ack_pending(irq))=0A+ if ((desc->status & IRQ_MOVE_PENDIN= G) &&=0A+ !io_apic_level_ack_pending(desc->irq))=0A = move_masked_irq(desc);=0A =0A if ( !(v & (1 << (i & 0x1f))) ) {=0A = spin_lock(&ioapic_lock);=0A- __edge_IO_APIC_irq(irq);=0A- = __level_IO_APIC_irq(irq);=0A+ __edge_IO_APIC_irq(desc->irq);=0A+ = __level_IO_APIC_irq(desc->irq);=0A spin_unlock(&ioapic_lock);= =0A }=0A }=0A =0A-static void end_level_ioapic_irq (unsigned int irq, = u8 vector)=0A+static void end_level_ioapic_irq(struct irq_desc *desc, u8 = vector)=0A {=0A unsigned long v;=0A int i;=0A@@ -1789,23 +1786,21 = @@ static void end_level_ioapic_irq (unsign=0A {=0A if ( = directed_eoi_enabled )=0A {=0A- struct irq_desc *desc = =3D irq_to_desc(irq);=0A-=0A if ( !(desc->status & (IRQ_DISABLE= D|IRQ_MOVE_PENDING)) )=0A {=0A- eoi_IO_APIC_irq(= irq);=0A+ eoi_IO_APIC_irq(desc->irq);=0A = return;=0A }=0A =0A- mask_IO_APIC_irq(irq);=0A- = eoi_IO_APIC_irq(irq);=0A+ mask_IO_APIC_irq(desc);=0A+ = eoi_IO_APIC_irq(desc->irq);=0A if ( (desc->status & = IRQ_MOVE_PENDING) &&=0A- !io_apic_level_ack_pending(irq) = )=0A+ !io_apic_level_ack_pending(desc->irq) )=0A = move_masked_irq(desc);=0A }=0A =0A- if ( !(irq_desc[ir= q].status & IRQ_DISABLED) )=0A- unmask_IO_APIC_irq(irq);=0A+ = if ( !(desc->status & IRQ_DISABLED) )=0A+ unmask_IO_APIC_irq= (desc);=0A =0A return;=0A }=0A@@ -1829,7 +1824,7 @@ static = void end_level_ioapic_irq (unsign=0A * operation to prevent an edge-trigge= red interrupt escaping meanwhile.=0A * The idea is from Manfred Spraul. = --macro=0A */=0A- i =3D IO_APIC_VECTOR(irq);=0A+ i =3D IO_APIC_VECTO= R(desc->irq);=0A =0A /* Manually EOI the old vector if we are moving = to the new */=0A if ( vector && i !=3D vector )=0A@@ -1843,30 +1838,21 = @@ static void end_level_ioapic_irq (unsign=0A =0A ack_APIC_irq();=0A = =0A- if ((irq_desc[irq].status & IRQ_MOVE_PENDING) &&=0A- = !io_apic_level_ack_pending(irq))=0A- move_native_irq(irq);=0A+ = if ( (desc->status & IRQ_MOVE_PENDING) &&=0A+ !io_apic_level_ack_pe= nding(desc->irq) )=0A+ move_native_irq(desc);=0A =0A if (!(v & = (1 << (i & 0x1f)))) {=0A spin_lock(&ioapic_lock);=0A- = __mask_IO_APIC_irq(irq);=0A- __edge_IO_APIC_irq(irq);=0A- = __level_IO_APIC_irq(irq);=0A- if ( !(irq_desc[irq].status & = IRQ_DISABLED) )=0A- __unmask_IO_APIC_irq(irq);=0A+ = __mask_IO_APIC_irq(desc->irq);=0A+ __edge_IO_APIC_irq(desc->irq);=0A= + __level_IO_APIC_irq(desc->irq);=0A+ if ( !(desc->status & = IRQ_DISABLED) )=0A+ __unmask_IO_APIC_irq(desc->irq);=0A = spin_unlock(&ioapic_lock);=0A }=0A }=0A =0A-static void disable_edge_io= apic_irq(unsigned int irq)=0A-{=0A-}=0A-=0A-static void end_edge_ioapic_irq= (unsigned int irq, u8 vector)=0A-{=0A-}=0A-=0A-=0A /*=0A * Level and edge = triggered IO-APIC interrupts need different handling,=0A * so we use two = separate IRQ descriptors. Edge triggered IRQs can be=0A@@ -1878,11 = +1864,10 @@ static void end_edge_ioapic_irq(unsigned=0A static hw_irq_contr= oller ioapic_edge_type =3D {=0A .typename =3D "IO-APIC-edge",=0A = .startup =3D startup_edge_ioapic_irq,=0A- .shutdown =3D = disable_edge_ioapic_irq,=0A+ .shutdown =3D irq_shutdown_none,=0A = .enable =3D unmask_IO_APIC_irq,=0A- .disable =3D = disable_edge_ioapic_irq,=0A+ .disable =3D irq_disable_none,=0A = .ack =3D ack_edge_ioapic_irq,=0A- .end =3D = end_edge_ioapic_irq,=0A .set_affinity =3D set_ioapic_affinity_irq= ,=0A };=0A =0A@@ -1897,26 +1882,24 @@ static hw_irq_controller ioapic_level= _ty=0A .set_affinity =3D set_ioapic_affinity_irq,=0A };=0A = =0A-static unsigned int startup_msi_irq(unsigned int irq)=0A+static = unsigned int startup_msi_irq(struct irq_desc *desc)=0A {=0A- unmask_msi_= irq(irq);=0A+ unmask_msi_irq(desc);=0A return 0;=0A }=0A =0A-static = void ack_msi_irq(unsigned int irq)=0A+static void ack_msi_irq(struct = irq_desc *desc)=0A {=0A- struct irq_desc *desc =3D irq_to_desc(irq);=0A-= =0A irq_complete_move(desc);=0A- move_native_irq(irq);=0A+ = move_native_irq(desc);=0A =0A if ( msi_maskable_irq(desc->msi_desc) = )=0A ack_APIC_irq(); /* ACKTYPE_NONE */=0A }=0A =0A-static void = end_msi_irq(unsigned int irq, u8 vector)=0A+static void end_msi_irq(struct = irq_desc *desc, u8 vector)=0A {=0A- if ( !msi_maskable_irq(irq_desc[irq]= .msi_desc) )=0A+ if ( !msi_maskable_irq(desc->msi_desc) )=0A = ack_APIC_irq(); /* ACKTYPE_EOI */=0A }=0A =0A@@ -1946,7 +1929,7 @@ static = inline void init_IO_APIC_traps(vo=0A make_8259A_irq(irq);=0A = }=0A =0A-static void enable_lapic_irq(unsigned int irq)=0A+static void = enable_lapic_irq(struct irq_desc *desc)=0A {=0A unsigned long v;=0A = =0A@@ -1954,7 +1937,7 @@ static void enable_lapic_irq(unsigned in=0A = apic_write_around(APIC_LVT0, v & ~APIC_LVT_MASKED);=0A }=0A =0A-static = void disable_lapic_irq(unsigned int irq)=0A+static void disable_lapic_irq(s= truct irq_desc *desc)=0A {=0A unsigned long v;=0A =0A@@ -1962,13 = +1945,11 @@ static void disable_lapic_irq(unsigned i=0A apic_write_arou= nd(APIC_LVT0, v | APIC_LVT_MASKED);=0A }=0A =0A-static void ack_lapic_irq(u= nsigned int irq)=0A+static void ack_lapic_irq(struct irq_desc *desc)=0A = {=0A ack_APIC_irq();=0A }=0A =0A-#define end_lapic_irq end_edge_ioapic_= irq=0A-=0A static hw_irq_controller lapic_irq_type =3D {=0A .typename = =3D "local-APIC-edge",=0A .startup =3D NULL, /* startup_irq() not = used for IRQ0 */=0A@@ -1976,7 +1957,6 @@ static hw_irq_controller = lapic_irq_type =0A .enable =3D enable_lapic_irq,=0A .disable = =3D disable_lapic_irq,=0A .ack =3D ack_lapic_irq,=0A- = .end =3D end_lapic_irq,=0A };=0A =0A /*=0A@@ -2051,7 +2031,7 @@ = static void __init check_timer(void)=0A /*=0A * get/set the timer = IRQ vector:=0A */=0A- disable_8259A_irq(0);=0A+ disable_8259A_ir= q(irq_to_desc(0));=0A vector =3D FIRST_HIPRIORITY_VECTOR;=0A = clear_irq_vector(0);=0A =0A@@ -2071,7 +2051,7 @@ static void __init = check_timer(void)=0A init_8259A(1);=0A /* XEN: Ripped out the = legacy missed-tick logic, so below is not needed. */=0A /*timer_ack = =3D 1;*/=0A- /*enable_8259A_irq(0);*/=0A+ /*enable_8259A_irq(irq_to_d= esc(0));*/=0A =0A pin1 =3D find_isa_irq_pin(0, mp_INT);=0A apic1 = =3D find_isa_irq_apic(0, mp_INT);=0A@@ -2085,7 +2065,7 @@ static void = __init check_timer(void)=0A /*=0A * Ok, does IRQ0 through = the IOAPIC work?=0A */=0A- unmask_IO_APIC_irq(0);=0A+ = unmask_IO_APIC_irq(irq_to_desc(0));=0A if (timer_irq_works()) = {=0A local_irq_restore(flags);=0A return;=0A@@ = -2125,10 +2105,10 @@ static void __init check_timer(void)=0A =0A = printk(KERN_INFO "...trying to set up timer as Virtual Wire IRQ...");=0A = =0A- disable_8259A_irq(0);=0A+ disable_8259A_irq(irq_to_desc(0));=0A = irq_desc[0].handler =3D &lapic_irq_type;=0A apic_write_around(APIC_= LVT0, APIC_DM_FIXED | vector); /* Fixed mode */=0A- enable_8259A_irq(0)= ;=0A+ enable_8259A_irq(irq_to_desc(0));=0A =0A if (timer_irq_works()= ) {=0A local_irq_restore(flags);=0A@@ -2401,7 +2381,7 @@ int = io_apic_set_pci_routing (int ioapic,=0A ioapic_register_intr(irq, = edge_level);=0A =0A if (!ioapic && platform_legacy_irq(irq))=0A- = disable_8259A_irq(irq);=0A+ disable_8259A_irq(desc);=0A =0A = spin_lock_irqsave(&ioapic_lock, flags);=0A __ioapic_write_entry(ioapic,= pin, 0, entry);=0A@@ -2410,7 +2390,7 @@ int io_apic_set_pci_routing (int = ioapic,=0A =0A spin_lock(&desc->lock);=0A if (!(desc->status & = (IRQ_DISABLED | IRQ_GUEST)))=0A- desc->handler->startup(irq);=0A+ = desc->handler->startup(desc);=0A spin_unlock_irqrestore(&desc->loc= k, flags);=0A =0A return 0;=0A--- a/xen/arch/x86/irq.c=0A+++ b/xen/arch= /x86/irq.c=0A@@ -192,7 +192,7 @@ static void dynamic_irq_cleanup(unsigned= =0A =0A spin_lock_irqsave(&desc->lock, flags);=0A desc->status = |=3D IRQ_DISABLED;=0A- desc->handler->shutdown(irq);=0A+ desc->handle= r->shutdown(desc);=0A action =3D desc->action;=0A desc->action = =3D NULL;=0A desc->msi_desc =3D NULL;=0A@@ -347,25 +347,20 @@ static = void __do_IRQ_guest(int vector);=0A =0A void no_action(int cpl, void = *dev_id, struct cpu_user_regs *regs) { }=0A =0A-static void enable_none(uns= igned int vector) { }=0A-static void end_none(unsigned int irq, u8 vector) = { }=0A-static unsigned int startup_none(unsigned int vector) { return 0; = }=0A-static void disable_none(unsigned int vector) { }=0A-static void = ack_none(unsigned int irq)=0A+void irq_actor_none(struct irq_desc *desc) { = }=0A+unsigned int irq_startup_none(struct irq_desc *desc) { return 0; = }=0A+static void ack_none(struct irq_desc *desc)=0A {=0A- ack_bad_irq(ir= q);=0A+ ack_bad_irq(desc->irq);=0A }=0A =0A-#define shutdown_none = disable_none=0A-=0A hw_irq_controller no_irq_type =3D {=0A "none",=0A- = startup_none,=0A- shutdown_none,=0A- enable_none,=0A- = disable_none,=0A+ irq_startup_none,=0A+ irq_shutdown_none,=0A+ = irq_enable_none,=0A+ irq_disable_none,=0A ack_none,=0A- = end_none=0A };=0A =0A static vmask_t *irq_get_used_vector_mask(int = irq)=0A@@ -585,19 +580,17 @@ void move_masked_irq(struct irq_desc *de=0A = cpus_clear(desc->pending_mask);=0A }=0A =0A-void move_native_irq(int = irq)=0A+void move_native_irq(struct irq_desc *desc)=0A {=0A- struct = irq_desc *desc =3D irq_to_desc(irq);=0A-=0A if (likely(!(desc->status = & IRQ_MOVE_PENDING)))=0A return;=0A =0A if (unlikely(desc->stat= us & IRQ_DISABLED))=0A return;=0A =0A- desc->handler->disable(ir= q);=0A+ desc->handler->disable(desc);=0A move_masked_irq(desc);=0A- = desc->handler->enable(irq);=0A+ desc->handler->enable(desc);=0A }=0A = =0A /* For re-setting irq interrupt affinity for specific irq */=0A@@ = -654,7 +647,7 @@ asmlinkage void do_IRQ(struct cpu_user_r=0A desc =3D = irq_to_desc(irq);=0A =0A spin_lock(&desc->lock);=0A- desc->handler->= ack(irq);=0A+ desc->handler->ack(desc);=0A =0A if ( likely(desc->sta= tus & IRQ_GUEST) )=0A {=0A@@ -664,7 +657,7 @@ asmlinkage void = do_IRQ(struct cpu_user_r=0A s_time_t now =3D NOW();=0A = if ( now < (desc->rl_quantum_start + MILLISECS(10)) )=0A = {=0A- desc->handler->disable(irq);=0A+ = desc->handler->disable(desc);=0A /*=0A * = If handler->disable doesn't actually mask the interrupt, a =0A = * disabled irq still can fire. This check also avoids possible =0A@@ = -716,7 +709,8 @@ asmlinkage void do_IRQ(struct cpu_user_r=0A desc->stat= us &=3D ~IRQ_INPROGRESS;=0A =0A out:=0A- desc->handler->end(irq, = regs->entry_vector);=0A+ if ( desc->handler->end )=0A+ desc->hand= ler->end(desc, regs->entry_vector);=0A out_no_end:=0A spin_unlock(&des= c->lock);=0A irq_exit();=0A@@ -733,7 +727,7 @@ static void irq_ratelimi= t_timer_fn(void =0A list_for_each_entry_safe ( desc, tmp, &irq_ratelimi= t_list, rl_link )=0A {=0A spin_lock(&desc->lock);=0A- = desc->handler->enable(desc->irq);=0A+ desc->handler->enable(desc);= =0A list_del(&desc->rl_link);=0A INIT_LIST_HEAD(&desc->rl_l= ink);=0A spin_unlock(&desc->lock);=0A@@ -796,7 +790,7 @@ void = __init release_irq(unsigned int irq=0A action =3D desc->action;=0A = desc->action =3D NULL;=0A desc->status |=3D IRQ_DISABLED;=0A- = desc->handler->shutdown(irq);=0A+ desc->handler->shutdown(desc);=0A = spin_unlock_irqrestore(&desc->lock,flags);=0A =0A /* Wait to make sure = it's not being used on another CPU */=0A@@ -823,7 +817,7 @@ int __init = setup_irq(unsigned int irq, s=0A =0A desc->action =3D new;=0A = desc->status &=3D ~IRQ_DISABLED;=0A- desc->handler->startup(irq);=0A+ = desc->handler->startup(desc);=0A =0A spin_unlock_irqrestore(&desc->loc= k,flags);=0A =0A@@ -914,7 +908,8 @@ static void irq_guest_eoi_timer_fn(void= =0A switch ( action->ack_type )=0A {=0A case ACKTYPE_UNMASK:= =0A- desc->handler->end(irq, 0);=0A+ if ( desc->handler->end = )=0A+ desc->handler->end(desc, 0);=0A break;=0A = case ACKTYPE_EOI:=0A cpu_eoi_map =3D action->cpu_eoi_map;=0A@@ = -942,7 +937,8 @@ static void __do_IRQ_guest(int irq)=0A /* An = interrupt may slip through while freeing an ACKTYPE_EOI irq. */=0A = ASSERT(action->ack_type =3D=3D ACKTYPE_EOI);=0A ASSERT(desc->status= & IRQ_DISABLED);=0A- desc->handler->end(irq, vector);=0A+ = if ( desc->handler->end )=0A+ desc->handler->end(desc, = vector);=0A return;=0A }=0A =0A@@ -1156,7 +1152,8 @@ static = void flush_ready_eoi(void)=0A ASSERT(irq > 0);=0A desc =3D = irq_to_desc(irq);=0A spin_lock(&desc->lock);=0A- desc->handl= er->end(irq, peoi[sp].vector);=0A+ if ( desc->handler->end )=0A+ = desc->handler->end(desc, peoi[sp].vector);=0A spin_unlock(&= desc->lock);=0A }=0A =0A@@ -1234,7 +1231,8 @@ void desc_guest_eoi(struc= t irq_desc *des=0A if ( action->ack_type =3D=3D ACKTYPE_UNMASK )=0A = {=0A ASSERT(cpus_empty(action->cpu_eoi_map));=0A- = desc->handler->end(irq, 0);=0A+ if ( desc->handler->end )=0A+ = desc->handler->end(desc, 0);=0A spin_unlock_irq(&desc->lock);= =0A return;=0A }=0A@@ -1402,7 +1400,7 @@ int pirq_guest_bind(st= ruct vcpu *v, stru=0A =0A desc->status |=3D IRQ_GUEST;=0A = desc->status &=3D ~IRQ_DISABLED;=0A- desc->handler->startup(irq);=0A= + desc->handler->startup(desc);=0A =0A /* Attempt to bind = the interrupt target to the correct CPU. */=0A cpu_set(v->processor= , cpumask);=0A@@ -1486,8 +1484,9 @@ static irq_guest_action_t *__pirq_guest= _=0A {=0A case ACKTYPE_UNMASK:=0A if ( test_and_clear_bool(= pirq->masked) &&=0A- (--action->in_flight =3D=3D 0) )=0A- = desc->handler->end(irq, 0);=0A+ (--action->in_flight = =3D=3D 0) &&=0A+ desc->handler->end )=0A+ = desc->handler->end(desc, 0);=0A break;=0A case ACKTYPE_EOI:=0A = /* NB. If #guests =3D=3D 0 then we clear the eoi_map later on. = */=0A@@ -1516,7 +1515,7 @@ static irq_guest_action_t *__pirq_guest_=0A =0A = /* Disabling IRQ before releasing the desc_lock avoids an IRQ storm. = */=0A desc->status |=3D IRQ_DISABLED;=0A- desc->handler->disable(irq= );=0A+ desc->handler->disable(desc);=0A =0A /*=0A * Mark any = remaining pending EOIs as ready to flush.=0A@@ -1538,7 +1537,7 @@ static = irq_guest_action_t *__pirq_guest_=0A =0A desc->action =3D NULL;=0A = desc->status &=3D ~(IRQ_GUEST|IRQ_INPROGRESS);=0A- desc->handler->shutdo= wn(irq);=0A+ desc->handler->shutdown(desc);=0A =0A /* Caller frees = the old guest descriptor block. */=0A return action;=0A@@ -1958,7 = +1957,7 @@ void fixup_irqs(void)=0A }=0A =0A if ( = desc->handler->disable )=0A- desc->handler->disable(irq);=0A+ = desc->handler->disable(desc);=0A =0A if ( desc->handler->s= et_affinity )=0A desc->handler->set_affinity(desc, &affinity);= =0A@@ -1966,7 +1965,7 @@ void fixup_irqs(void)=0A set_affinity = =3D 0;=0A =0A if ( desc->handler->enable )=0A- = desc->handler->enable(irq);=0A+ desc->handler->enable(desc);=0A = =0A spin_unlock(&desc->lock);=0A =0A--- a/xen/arch/x86/msi.c=0A+++ = b/xen/arch/x86/msi.c=0A@@ -336,11 +336,11 @@ int msi_maskable_irq(const = struct msi_de=0A || entry->msi_attrib.maskbit;=0A }=0A = =0A-static void msi_set_mask_bit(unsigned int irq, int flag)=0A+static = void msi_set_mask_bit(struct irq_desc *desc, int flag)=0A {=0A- struct = msi_desc *entry =3D irq_desc[irq].msi_desc;=0A+ struct msi_desc *entry = =3D desc->msi_desc;=0A =0A- ASSERT(spin_is_locked(&irq_desc[irq].lock));= =0A+ ASSERT(spin_is_locked(&desc->lock));=0A BUG_ON(!entry || = !entry->dev);=0A switch (entry->msi_attrib.type) {=0A case = PCI_CAP_ID_MSI:=0A@@ -387,14 +387,14 @@ static int msi_get_mask_bit(const = struct=0A return -1;=0A }=0A =0A-void mask_msi_irq(unsigned int = irq)=0A+void mask_msi_irq(struct irq_desc *desc)=0A {=0A- msi_set_mask_b= it(irq, 1);=0A+ msi_set_mask_bit(desc, 1);=0A }=0A =0A-void unmask_msi_i= rq(unsigned int irq)=0A+void unmask_msi_irq(struct irq_desc *desc)=0A = {=0A- msi_set_mask_bit(irq, 0);=0A+ msi_set_mask_bit(desc, 0);=0A = }=0A =0A static struct msi_desc* alloc_msi_entry(void)=0A@@ -974,7 +974,7 = @@ int pci_restore_msi_state(struct pci_dev=0A =0A write_msi_msg(en= try, &entry->msg);=0A =0A- msi_set_mask_bit(irq, entry->msi_attrib.m= asked);=0A+ msi_set_mask_bit(desc, entry->msi_attrib.masked);=0A = =0A if ( entry->msi_attrib.type =3D=3D PCI_CAP_ID_MSI )=0A = msi_set_enable(pdev, 1);=0A--- a/xen/drivers/passthrough/amd/iommu_init= .c=0A+++ b/xen/drivers/passthrough/amd/iommu_init.c=0A@@ -29,7 +29,6 @@=0A = #include <asm-x86/fixmap.h>=0A #include <mach_apic.h>=0A =0A-static struct = amd_iommu **__read_mostly irq_to_iommu;=0A static int __initdata nr_amd_iom= mus;=0A =0A unsigned short ivrs_bdf_entries;=0A@@ -403,10 +402,10 @@ = static void amd_iommu_msi_enable(struct =0A iommu->msi_cap + = PCI_MSI_FLAGS, control);=0A }=0A =0A-static void iommu_msi_unmask(unsigned = int irq)=0A+static void iommu_msi_unmask(struct irq_desc *desc)=0A {=0A = unsigned long flags;=0A- struct amd_iommu *iommu =3D irq_to_iommu[irq];= =0A+ struct amd_iommu *iommu =3D desc->action->dev_id;=0A =0A /* = FIXME: do not support mask bits at the moment */=0A if ( iommu->maskbit= )=0A@@ -417,11 +416,10 @@ static void iommu_msi_unmask(unsigned in=0A = spin_unlock_irqrestore(&iommu->lock, flags);=0A }=0A =0A-static void = iommu_msi_mask(unsigned int irq)=0A+static void iommu_msi_mask(struct = irq_desc *desc)=0A {=0A unsigned long flags;=0A- struct amd_iommu = *iommu =3D irq_to_iommu[irq];=0A- struct irq_desc *desc =3D irq_to_desc(= irq);=0A+ struct amd_iommu *iommu =3D desc->action->dev_id;=0A =0A = irq_complete_move(desc);=0A =0A@@ -434,15 +432,15 @@ static void iommu_msi_= mask(unsigned int =0A spin_unlock_irqrestore(&iommu->lock, flags);=0A = }=0A =0A-static unsigned int iommu_msi_startup(unsigned int irq)=0A+static = unsigned int iommu_msi_startup(struct irq_desc *desc)=0A {=0A- = iommu_msi_unmask(irq);=0A+ iommu_msi_unmask(desc);=0A return 0;=0A = }=0A =0A-static void iommu_msi_end(unsigned int irq, u8 vector)=0A+static = void iommu_msi_end(struct irq_desc *desc, u8 vector)=0A {=0A- iommu_msi_= unmask(irq);=0A+ iommu_msi_unmask(desc);=0A ack_APIC_irq();=0A }=0A = =0A@@ -557,13 +555,11 @@ static int __init set_iommu_interrupt_ha=0A = }=0A =0A irq_desc[irq].handler =3D &iommu_msi_type;=0A- = irq_to_iommu[irq] =3D iommu;=0A ret =3D request_irq(irq, amd_iommu_page= _fault, 0,=0A "amd_iommu", iommu);=0A if = ( ret )=0A {=0A irq_desc[irq].handler =3D &no_irq_type;=0A- = irq_to_iommu[irq] =3D NULL;=0A destroy_irq(irq);=0A = AMD_IOMMU_DEBUG("can't request irq\n");=0A return 0;=0A@@ -728,13 = +724,6 @@ static void __init amd_iommu_init_cleanu=0A ivrs_mappings= =3D NULL;=0A }=0A =0A- /* free irq_to_iommu[] */=0A- if ( = irq_to_iommu )=0A- {=0A- xfree(irq_to_iommu);=0A- = irq_to_iommu =3D NULL;=0A- }=0A-=0A iommu_enabled =3D 0;=0A = iommu_passthrough =3D 0;=0A iommu_intremap =3D 0;=0A@@ -838,11 +827,6 = @@ int __init amd_iommu_init(void)=0A =0A BUG_ON( !iommu_found() );=0A = =0A- irq_to_iommu =3D xmalloc_array(struct amd_iommu *, nr_irqs);=0A- = if ( irq_to_iommu =3D=3D NULL )=0A- goto error_out;=0A- = memset(irq_to_iommu, 0, nr_irqs * sizeof(struct iommu*));=0A-=0A = ivrs_bdf_entries =3D amd_iommu_get_ivrs_dev_entries();=0A =0A if ( = !ivrs_bdf_entries )=0A--- a/xen/drivers/passthrough/vtd/iommu.c=0A+++ = b/xen/drivers/passthrough/vtd/iommu.c=0A@@ -829,7 +829,6 @@ static const = char *iommu_get_fault_reaso=0A }=0A }=0A =0A-static struct iommu = **irq_to_iommu;=0A static int iommu_page_fault_do_one(struct iommu *iommu, = int type,=0A u8 fault_reason, u16 = source_id, u64 addr)=0A {=0A@@ -961,9 +960,9 @@ clear_overflow:=0A = }=0A }=0A =0A-static void dma_msi_unmask(unsigned int irq)=0A+static void = dma_msi_unmask(struct irq_desc *desc)=0A {=0A- struct iommu *iommu =3D = irq_to_iommu[irq];=0A+ struct iommu *iommu =3D desc->action->dev_id;=0A = unsigned long flags;=0A =0A /* unmask it */=0A@@ -972,11 +971,10 = @@ static void dma_msi_unmask(unsigned int =0A spin_unlock_irqrestore(&= iommu->register_lock, flags);=0A }=0A =0A-static void dma_msi_mask(unsigned= int irq)=0A+static void dma_msi_mask(struct irq_desc *desc)=0A {=0A = unsigned long flags;=0A- struct iommu *iommu =3D irq_to_iommu[irq];=0A- = struct irq_desc *desc =3D irq_to_desc(irq);=0A+ struct iommu *iommu = =3D desc->action->dev_id;=0A =0A irq_complete_move(desc);=0A =0A@@ = -986,15 +984,15 @@ static void dma_msi_mask(unsigned int ir=0A = spin_unlock_irqrestore(&iommu->register_lock, flags);=0A }=0A =0A-static = unsigned int dma_msi_startup(unsigned int irq)=0A+static unsigned int = dma_msi_startup(struct irq_desc *desc)=0A {=0A- dma_msi_unmask(irq);=0A+= dma_msi_unmask(desc);=0A return 0;=0A }=0A =0A-static void = dma_msi_end(unsigned int irq, u8 vector)=0A+static void dma_msi_end(struct = irq_desc *desc, u8 vector)=0A {=0A- dma_msi_unmask(irq);=0A+ = dma_msi_unmask(desc);=0A ack_APIC_irq();=0A }=0A =0A@@ -1071,7 +1069,6 = @@ static int __init iommu_set_interrupt(st=0A }=0A =0A irq_desc[ir= q].handler =3D &dma_msi_type;=0A- irq_to_iommu[irq] =3D iommu;=0A = #ifdef CONFIG_X86=0A ret =3D request_irq(irq, iommu_page_fault, 0, = "dmar", iommu);=0A #else=0A@@ -1080,7 +1077,6 @@ static int __init = iommu_set_interrupt(st=0A if ( ret )=0A {=0A irq_desc[irq].= handler =3D &no_irq_type;=0A- irq_to_iommu[irq] =3D NULL;=0A = destroy_irq(irq);=0A dprintk(XENLOG_ERR VTDPREFIX, "IOMMU: can't = request irq\n");=0A return ret;=0A@@ -2091,13 +2087,6 @@ int = __init intel_vtd_setup(void)=0A =0A platform_quirks_init();=0A =0A- = irq_to_iommu =3D xmalloc_array(struct iommu*, nr_irqs);=0A- BUG_ON(!irq_= to_iommu);=0A- memset(irq_to_iommu, 0, nr_irqs * sizeof(struct = iommu*));=0A-=0A- if(!irq_to_iommu)=0A- return -ENOMEM;=0A-=0A = /* We enable the following features only if they are supported by all = VT-d=0A * engines: Snoop Control, DMA passthrough, Queued Invalidation= and=0A * Interrupt Remapping.=0A--- a/xen/include/asm-x86/irq.h=0A+++= b/xen/include/asm-x86/irq.h=0A@@ -27,6 +27,8 @@ typedef struct {=0A = DECLARE_BITMAP(_bits,NR_VECTORS);=0A } vmask_t;=0A =0A+struct irq_desc;=0A+= =0A struct irq_cfg {=0A s16 vector; /* vector = itself is only 8 bits, */=0A s16 old_vector; /* but = we use -1 for unassigned */=0A@@ -107,8 +109,8 @@ fastcall void smp_irq_mo= ve_cleanup_inter=0A =0A asmlinkage void do_IRQ(struct cpu_user_regs = *regs);=0A =0A-void disable_8259A_irq(unsigned int irq);=0A-void enable_825= 9A_irq(unsigned int irq);=0A+void disable_8259A_irq(struct irq_desc = *);=0A+void enable_8259A_irq(struct irq_desc *);=0A int i8259A_irq_pending(= unsigned int irq);=0A void mask_8259A(void);=0A void unmask_8259A(void);=0A= @@ -161,7 +163,6 @@ int irq_to_vector(int irq);=0A int create_irq(void);=0A= void destroy_irq(unsigned int irq);=0A =0A-struct irq_desc;=0A extern = void irq_complete_move(struct irq_desc *);=0A =0A extern struct irq_desc = *irq_desc;=0A@@ -171,7 +172,7 @@ void unlock_vector_lock(void);=0A =0A = void __setup_vector_irq(int cpu);=0A =0A-void move_native_irq(int = irq);=0A+void move_native_irq(struct irq_desc *);=0A void move_masked_irq(s= truct irq_desc *);=0A =0A int __assign_irq_vector(int irq, struct irq_cfg = *, const cpumask_t *);=0A--- a/xen/include/asm-x86/msi.h=0A+++ b/xen/includ= e/asm-x86/msi.h=0A@@ -75,8 +75,8 @@ struct msi_msg {=0A =0A struct = msi_desc;=0A /* Helper functions */=0A-extern void mask_msi_irq(unsigned = int irq);=0A-extern void unmask_msi_irq(unsigned int irq);=0A+extern void = mask_msi_irq(struct irq_desc *);=0A+extern void unmask_msi_irq(struct = irq_desc *);=0A extern void set_msi_affinity(struct irq_desc *, const = cpumask_t *);=0A extern int pci_enable_msi(struct msi_info *msi, struct = msi_desc **desc);=0A extern void pci_disable_msi(struct msi_desc *desc);=0A= --- a/xen/include/xen/irq.h=0A+++ b/xen/include/xen/irq.h=0A@@ -41,12 = +41,12 @@ struct irq_desc;=0A */=0A struct hw_interrupt_type {=0A = const char *typename;=0A- unsigned int (*startup)(unsigned int = irq);=0A- void (*shutdown)(unsigned int irq);=0A- void (*enable)(unsi= gned int irq);=0A- void (*disable)(unsigned int irq);=0A- void = (*ack)(unsigned int irq);=0A- void (*end)(unsigned int irq, u8 = vector);=0A+ unsigned int (*startup)(struct irq_desc *);=0A+ void = (*shutdown)(struct irq_desc *);=0A+ void (*enable)(struct irq_desc = *);=0A+ void (*disable)(struct irq_desc *);=0A+ void (*ack)(struct = irq_desc *);=0A+ void (*end)(struct irq_desc *, u8 vector);=0A void = (*set_affinity)(struct irq_desc *, const cpumask_t *);=0A };=0A =0A@@ = -133,6 +133,11 @@ extern int request_irq(unsigned int irq,=0A =0A extern = hw_irq_controller no_irq_type;=0A extern void no_action(int cpl, void = *dev_id, struct cpu_user_regs *regs);=0A+extern unsigned int irq_startup_no= ne(struct irq_desc *);=0A+extern void irq_actor_none(struct irq_desc = *);=0A+#define irq_shutdown_none irq_actor_none=0A+#define irq_disable_none= irq_actor_none=0A+#define irq_enable_none irq_actor_none=0A =0A struct = domain;=0A struct vcpu;=0A --=__Part3A1501D0.0__= Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel --=__Part3A1501D0.0__=-- From xen-devel-bounces@lists.xensource.com Tue Sep 20 08:47:57 2011 Return-path: <xen-devel-bounces@lists.xensource.com> Envelope-to: www-data@lists.xensource.com Delivery-date: Tue, 20 Sep 2011 08:47:57 -0700 Received: from localhost ([127.0.0.1] helo=lists.colo.xensource.com) by lists.xensource.com with esmtp (Exim 4.43) id 1R62Y8-0005cN-Tv; Tue, 20 Sep 2011 08:47:56 -0700 Received: from mail27.messagelabs.com ([193.109.254.147]) by lists.xensource.com with esmtp (Exim 4.43) id 1R62UT-0004Qa-OJ for xen-devel@lists.xensource.com; Tue, 20 Sep 2011 08:44:10 -0700 X-Env-Sender: JBeulich@suse.com X-Msg-Ref: server-7.tower-27.messagelabs.com!1316533423!49454125!1 X-Originating-IP: [130.57.49.28] X-StarScan-Version: 6.4.1; banners=-,-,- X-VirusChecked: Checked Received: (qmail 7737 invoked from network); 20 Sep 2011 15:43:43 -0000 Received: from nat28.tlf.novell.com (HELO nat28.tlf.novell.com) (130.57.49.28) by server-7.tower-27.messagelabs.com with DHE-RSA-AES256-SHA encrypted SMTP; 20 Sep 2011 15:43:43 -0000 Received: from EMEA1-MTA by nat28.tlf.novell.com with Novell_GroupWise; Tue, 20 Sep 2011 16:44:06 +0100 Message-Id: <4E78D0FF0200007800056D91@nat28.tlf.novell.com> X-Mailer: Novell GroupWise Internet Agent 8.0.1 Date: Tue, 20 Sep 2011 16:44:31 +0100 From: "Jan Beulich" <JBeulich@suse.com> To: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com> Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="=__Part250A1ECF.0__=" Subject: [Xen-devel] [PATCH 4/4] x86: split MSI IRQ chip X-BeenThere: xen-devel@lists.xensource.com X-Mailman-Version: 2.1.5 Precedence: list List-Id: Xen developer discussion <xen-devel.lists.xensource.com> List-Unsubscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe> List-Post: <mailto:xen-devel@lists.xensource.com> List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help> List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=subscribe> Sender: xen-devel-bounces@lists.xensource.com Errors-To: xen-devel-bounces@lists.xensource.com This is a MIME message. If you are reading this text, you may want to consider changing to a mail reader or gateway that understands how to properly handle MIME multipart messages. --=__Part250A1ECF.0__= Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: quoted-printable Content-Disposition: inline With the .end() accessor having become optional and noting that several of the accessors' behavior really depends on the result of msi_maskable_irq(), the splits the MSI IRQ chip type into two - one for the maskable ones, and the other for the (MSI only) non-maskable ones. At once the implementation of those methods gets moved from io_apic.c to msi.c. Signed-off-by: Jan Beulich <jbeulich@suse.com> --- a/xen/arch/x86/hpet.c +++ b/xen/arch/x86/hpet.c @@ -312,7 +312,7 @@ static void __hpet_setup_msi_irq(struct=20 { struct msi_msg msg; =20 - msi_compose_msg(desc->irq, &msg); + msi_compose_msg(desc, &msg); hpet_msi_write(desc->action->dev_id, &msg); } =20 --- a/xen/arch/x86/hvm/vmsi.c +++ b/xen/arch/x86/hvm/vmsi.c @@ -382,7 +382,7 @@ int msixtbl_pt_register(struct domain *d return r; } =20 - if ( irq_desc->handler !=3D &pci_msi_type ) + if ( !irq_desc->msi_desc ) goto out; =20 msi_desc =3D irq_desc->msi_desc; @@ -426,7 +426,7 @@ void msixtbl_pt_unregister(struct domain if ( !irq_desc ) return; =20 - if ( irq_desc->handler !=3D &pci_msi_type ) + if ( !irq_desc->msi_desc ) goto out; =20 msi_desc =3D irq_desc->msi_desc; --- a/xen/arch/x86/io_apic.c +++ b/xen/arch/x86/io_apic.c @@ -1882,44 +1882,6 @@ static hw_irq_controller ioapic_level_ty .set_affinity =3D set_ioapic_affinity_irq, }; =20 -static unsigned int startup_msi_irq(struct irq_desc *desc) -{ - unmask_msi_irq(desc); - return 0; -} - -static void ack_msi_irq(struct irq_desc *desc) -{ - irq_complete_move(desc); - move_native_irq(desc); - - if ( msi_maskable_irq(desc->msi_desc) ) - ack_APIC_irq(); /* ACKTYPE_NONE */ -} - -static void end_msi_irq(struct irq_desc *desc, u8 vector) -{ - if ( !msi_maskable_irq(desc->msi_desc) ) - ack_APIC_irq(); /* ACKTYPE_EOI */ -} - -#define shutdown_msi_irq mask_msi_irq - -/* - * IRQ Chip for MSI PCI/PCI-X/PCI-Express Devices, - * which implement the MSI or MSI-X Capability Structure. - */ -hw_irq_controller pci_msi_type =3D { - .typename =3D "PCI-MSI", - .startup =3D startup_msi_irq, - .shutdown =3D shutdown_msi_irq, - .enable =3D unmask_msi_irq, - .disable =3D mask_msi_irq, - .ack =3D ack_msi_irq, - .end =3D end_msi_irq, - .set_affinity =3D set_msi_affinity, -}; - static inline void init_IO_APIC_traps(void) { int irq; --- a/xen/arch/x86/irq.c +++ b/xen/arch/x86/irq.c @@ -1303,7 +1303,7 @@ static int pirq_acktype(struct domain *d * MSIs are treated as edge-triggered interrupts, except * when there is no proper way to mask them. */ - if ( desc->handler =3D=3D &pci_msi_type ) + if ( desc->msi_desc ) return msi_maskable_irq(desc->msi_desc) ? ACKTYPE_NONE : = ACKTYPE_EOI; =20 /* @@ -1722,7 +1722,7 @@ int map_domain_pirq( if ( desc->handler !=3D &no_irq_type ) dprintk(XENLOG_G_ERR, "dom%d: irq %d in use\n", d->domain_id, irq); - desc->handler =3D &pci_msi_type; + setup_msi_handler(desc, msi_desc); =20 if ( opt_irq_vector_map =3D=3D OPT_IRQ_VECTOR_MAP_PERDEV && !desc->chip_data->used_vectors ) @@ -1738,7 +1738,7 @@ int map_domain_pirq( } =20 set_domain_irq_pirq(d, irq, info); - setup_msi_irq(msi_desc, irq); + setup_msi_irq(desc); spin_unlock_irqrestore(&desc->lock, flags); } else @@ -1806,6 +1806,12 @@ int unmap_domain_pirq(struct domain *d,=20 radix_tree_int_to_ptr(-pirq)); } =20 + if ( msi_desc ) + { + desc->handler =3D &no_irq_type; + desc->msi_desc =3D NULL; + } + spin_unlock_irqrestore(&desc->lock, flags); if (msi_desc) msi_free_irq(msi_desc); @@ -1818,9 +1824,6 @@ int unmap_domain_pirq(struct domain *d,=20 dprintk(XENLOG_G_ERR, "dom%d: could not deny access to irq %d\n", d->domain_id, pirq); =20 - if ( desc->handler =3D=3D &pci_msi_type ) - desc->handler =3D &no_irq_type; - done: return ret; } --- a/xen/arch/x86/msi.c +++ b/xen/arch/x86/msi.c @@ -120,11 +120,11 @@ static void msix_put_fixmap(struct pci_d /* * MSI message composition */ -void msi_compose_msg(int irq, struct msi_msg *msg) +void msi_compose_msg(struct irq_desc *desc, struct msi_msg *msg) { unsigned dest; cpumask_t domain; - struct irq_cfg *cfg =3D irq_cfg(irq); + struct irq_cfg *cfg =3D desc->chip_data; int vector =3D cfg->vector; domain =3D cfg->cpu_mask; =20 @@ -205,19 +205,6 @@ static void read_msi_msg(struct msi_desc iommu_read_msi_from_ire(entry, msg); } =20 -static int set_irq_msi(struct msi_desc *entry) -{ - if ( entry->irq >=3D nr_irqs ) - { - dprintk(XENLOG_ERR, "Trying to install msi data for irq %d\n", - entry->irq); - return -EINVAL; - } - - irq_desc[entry->irq].msi_desc =3D entry; - return 0; -} - static void write_msi_msg(struct msi_desc *entry, struct msi_msg *msg) { entry->msg =3D *msg; @@ -266,7 +253,7 @@ static void write_msi_msg(struct msi_des } } =20 -void set_msi_affinity(struct irq_desc *desc, const cpumask_t *mask) +static void set_msi_affinity(struct irq_desc *desc, const cpumask_t = *mask) { struct msi_msg msg; unsigned int dest; @@ -387,16 +374,65 @@ static int msi_get_mask_bit(const struct return -1; } =20 -void mask_msi_irq(struct irq_desc *desc) +static void mask_msi_irq(struct irq_desc *desc) { msi_set_mask_bit(desc, 1); } =20 -void unmask_msi_irq(struct irq_desc *desc) +static void unmask_msi_irq(struct irq_desc *desc) { msi_set_mask_bit(desc, 0); } =20 +static unsigned int startup_msi_irq(struct irq_desc *desc) +{ + unmask_msi_irq(desc); + return 0; +} + +static void ack_nonmaskable_msi_irq(struct irq_desc *desc) +{ + irq_complete_move(desc); + move_native_irq(desc); +} + +static void ack_maskable_msi_irq(struct irq_desc *desc) +{ + ack_nonmaskable_msi_irq(desc); + ack_APIC_irq(); /* ACKTYPE_NONE */ +} + +static void end_nonmaskable_msi_irq(struct irq_desc *desc, u8 vector) +{ + ack_APIC_irq(); /* ACKTYPE_EOI */ +} + +/* + * IRQ chip for MSI PCI/PCI-X/PCI-Express devices, + * which implement the MSI or MSI-X capability structure. + */ +static hw_irq_controller pci_msi_maskable =3D { + .typename =3D "PCI-MSI/-X", + .startup =3D startup_msi_irq, + .shutdown =3D mask_msi_irq, + .enable =3D unmask_msi_irq, + .disable =3D mask_msi_irq, + .ack =3D ack_maskable_msi_irq, + .set_affinity =3D set_msi_affinity +}; + +/* As above, but without having masking capability. */ +static hw_irq_controller pci_msi_nonmaskable =3D { + .typename =3D "PCI-MSI", + .startup =3D irq_startup_none, + .shutdown =3D irq_shutdown_none, + .enable =3D irq_enable_none, + .disable =3D irq_disable_none, + .ack =3D ack_nonmaskable_msi_irq, + .end =3D end_nonmaskable_msi_irq, + .set_affinity =3D set_msi_affinity +}; + static struct msi_desc* alloc_msi_entry(void) { struct msi_desc *entry; @@ -412,15 +448,19 @@ static struct msi_desc* alloc_msi_entry( return entry; } =20 -int setup_msi_irq(struct msi_desc *msidesc, int irq) +void setup_msi_handler(struct irq_desc *desc, struct msi_desc *msidesc) { - struct msi_msg msg; + desc->msi_desc =3D msidesc; + desc->handler =3D msi_maskable_irq(msidesc) ? &pci_msi_maskable + : &pci_msi_nonmaskable; +} =20 - msi_compose_msg(irq, &msg); - set_irq_msi(msidesc); - write_msi_msg(irq_desc[irq].msi_desc, &msg); +void setup_msi_irq(struct irq_desc *desc) +{ + struct msi_msg msg; =20 - return 0; + msi_compose_msg(desc, &msg); + write_msi_msg(desc->msi_desc, &msg); } =20 int msi_free_irq(struct msi_desc *entry) @@ -1018,19 +1058,20 @@ static void dump_msi(unsigned char key) { struct irq_desc *desc =3D irq_to_desc(irq); const struct msi_desc *entry; - u32 addr, data; + u32 addr, data, dest32; + int mask; + struct msi_attrib attr; unsigned long flags; char type; =20 spin_lock_irqsave(&desc->lock, flags); =20 entry =3D desc->msi_desc; - type =3D desc->handler =3D=3D &pci_msi_type && entry; - - spin_unlock_irqrestore(&desc->lock, flags); - - if ( !type ) + if ( !entry ) + { + spin_unlock_irqrestore(&desc->lock, flags); continue; + } =20 switch ( entry->msi_attrib.type ) { @@ -1041,6 +1082,11 @@ static void dump_msi(unsigned char key) =20 data =3D entry->msg.data; addr =3D entry->msg.address_lo; + dest32 =3D entry->msg.dest32; + attr =3D entry->msi_attrib; + mask =3D msi_get_mask_bit(entry); + + spin_unlock_irqrestore(&desc->lock, flags); =20 printk(" MSI%c %4u vec=3D%02x%7s%6s%3sassert%5s%7s" " dest=3D%08x mask=3D%d/%d/%d\n", @@ -1051,9 +1097,7 @@ static void dump_msi(unsigned char key) data & MSI_DATA_LEVEL_ASSERT ? "" : "de", addr & MSI_ADDR_DESTMODE_LOGIC ? "log" : "phys", addr & MSI_ADDR_REDIRECTION_LOWPRI ? "lowest" : "cpu", - entry->msg.dest32, - entry->msi_attrib.maskbit, entry->msi_attrib.masked, - msi_get_mask_bit(entry)); + dest32, attr.maskbit, attr.masked, mask); } } =20 --- a/xen/include/asm-x86/msi.h +++ b/xen/include/asm-x86/msi.h @@ -73,15 +73,14 @@ struct msi_msg { u32 dest32; /* used when Interrupt Remapping with EIM = is enabled */ }; =20 +struct irq_desc; struct msi_desc; /* Helper functions */ -extern void mask_msi_irq(struct irq_desc *); -extern void unmask_msi_irq(struct irq_desc *); -extern void set_msi_affinity(struct irq_desc *, const cpumask_t *); extern int pci_enable_msi(struct msi_info *msi, struct msi_desc **desc); extern void pci_disable_msi(struct msi_desc *desc); extern void pci_cleanup_msi(struct pci_dev *pdev); -extern int setup_msi_irq(struct msi_desc *desc, int irq); +extern void setup_msi_handler(struct irq_desc *, struct msi_desc *); +extern void setup_msi_irq(struct irq_desc *); extern void teardown_msi_irq(int irq); extern int msi_free_vector(struct msi_desc *entry); extern int pci_restore_msi_state(struct pci_dev *pdev); @@ -89,14 +88,14 @@ extern int pci_restore_msi_state(struct=20 extern unsigned int pci_msix_get_table_len(struct pci_dev *pdev); =20 struct msi_desc { - struct { + struct msi_attrib { __u8 type : 5; /* {0: unused, 5h:MSI, 11h:MSI-X} = */ __u8 maskbit : 1; /* mask-pending bit supported ? = */ __u8 masked : 1; __u8 is_64 : 1; /* Address size: 0=3D32bit = 1=3D64bit */ __u8 pos; /* Location of the msi capability = */ __u16 entry_nr; /* specific enabled entry = */ - }msi_attrib; + } msi_attrib; =20 struct list_head list; =20 @@ -122,8 +121,6 @@ int msi_free_irq(struct msi_desc *entry) */ #define NR_HP_RESERVED_VECTORS 20 =20 -extern const struct hw_interrupt_type pci_msi_type; - #define PCI_MSIX_ENTRY_SIZE 16 #define PCI_MSIX_ENTRY_LOWER_ADDR_OFFSET 0 #define PCI_MSIX_ENTRY_UPPER_ADDR_OFFSET 4 @@ -221,5 +218,6 @@ struct msg_address { __u32 hi_address; } __attribute__ ((packed)); =20 -void msi_compose_msg(int irq, struct msi_msg *); +void msi_compose_msg(struct irq_desc *, struct msi_msg *); + #endif /* __ASM_MSI_H */ --=__Part250A1ECF.0__= Content-Type: text/plain; name="x86-msi-type-split.patch" Content-Transfer-Encoding: quoted-printable Content-Disposition: attachment; filename="x86-msi-type-split.patch" With the .end() accessor having become optional and noting that=0Aseveral = of the accessors' behavior really depends on the result of=0Amsi_maskable_i= rq(), the splits the MSI IRQ chip type into two - one=0Afor the maskable = ones, and the other for the (MSI only) non-maskable=0Aones.=0A=0AAt once = the implementation of those methods gets moved from io_apic.c=0Ato = msi.c.=0A=0ASigned-off-by: Jan Beulich <jbeulich@suse.com>=0A=0A--- = a/xen/arch/x86/hpet.c=0A+++ b/xen/arch/x86/hpet.c=0A@@ -312,7 +312,7 @@ = static void __hpet_setup_msi_irq(struct =0A {=0A struct msi_msg = msg;=0A =0A- msi_compose_msg(desc->irq, &msg);=0A+ msi_compose_msg(de= sc, &msg);=0A hpet_msi_write(desc->action->dev_id, &msg);=0A }=0A = =0A--- a/xen/arch/x86/hvm/vmsi.c=0A+++ b/xen/arch/x86/hvm/vmsi.c=0A@@ = -382,7 +382,7 @@ int msixtbl_pt_register(struct domain *d=0A = return r;=0A }=0A =0A- if ( irq_desc->handler !=3D &pci_msi_type = )=0A+ if ( !irq_desc->msi_desc )=0A goto out;=0A =0A = msi_desc =3D irq_desc->msi_desc;=0A@@ -426,7 +426,7 @@ void msixtbl_pt_unre= gister(struct domain=0A if ( !irq_desc )=0A return;=0A =0A- = if ( irq_desc->handler !=3D &pci_msi_type )=0A+ if ( !irq_desc->msi_desc= )=0A goto out;=0A =0A msi_desc =3D irq_desc->msi_desc;=0A--- = a/xen/arch/x86/io_apic.c=0A+++ b/xen/arch/x86/io_apic.c=0A@@ -1882,44 = +1882,6 @@ static hw_irq_controller ioapic_level_ty=0A .set_affinity = =3D set_ioapic_affinity_irq,=0A };=0A =0A-static unsigned int startup_msi_i= rq(struct irq_desc *desc)=0A-{=0A- unmask_msi_irq(desc);=0A- return = 0;=0A-}=0A-=0A-static void ack_msi_irq(struct irq_desc *desc)=0A-{=0A- = irq_complete_move(desc);=0A- move_native_irq(desc);=0A-=0A- if ( = msi_maskable_irq(desc->msi_desc) )=0A- ack_APIC_irq(); /* ACKTYPE_NO= NE */=0A-}=0A-=0A-static void end_msi_irq(struct irq_desc *desc, u8 = vector)=0A-{=0A- if ( !msi_maskable_irq(desc->msi_desc) )=0A- = ack_APIC_irq(); /* ACKTYPE_EOI */=0A-}=0A-=0A-#define shutdown_msi_irq = mask_msi_irq=0A-=0A-/*=0A- * IRQ Chip for MSI PCI/PCI-X/PCI-Express = Devices,=0A- * which implement the MSI or MSI-X Capability Structure.=0A- = */=0A-hw_irq_controller pci_msi_type =3D {=0A- .typename =3D = "PCI-MSI",=0A- .startup =3D startup_msi_irq,=0A- .shutdown =3D = shutdown_msi_irq,=0A- .enable =3D unmask_msi_irq,=0A- = .disable =3D mask_msi_irq,=0A- .ack =3D ack_msi_irq,=0A- = .end =3D end_msi_irq,=0A- .set_affinity =3D set_msi_affinity,= =0A-};=0A-=0A static inline void init_IO_APIC_traps(void)=0A {=0A int = irq;=0A--- a/xen/arch/x86/irq.c=0A+++ b/xen/arch/x86/irq.c=0A@@ -1303,7 = +1303,7 @@ static int pirq_acktype(struct domain *d=0A * MSIs are = treated as edge-triggered interrupts, except=0A * when there is no = proper way to mask them.=0A */=0A- if ( desc->handler =3D=3D = &pci_msi_type )=0A+ if ( desc->msi_desc )=0A return msi_maskable= _irq(desc->msi_desc) ? ACKTYPE_NONE : ACKTYPE_EOI;=0A =0A /*=0A@@ = -1722,7 +1722,7 @@ int map_domain_pirq(=0A if ( desc->handler !=3D = &no_irq_type )=0A dprintk(XENLOG_G_ERR, "dom%d: irq %d in = use\n",=0A d->domain_id, irq);=0A- desc->handler= =3D &pci_msi_type;=0A+ setup_msi_handler(desc, msi_desc);=0A =0A = if ( opt_irq_vector_map =3D=3D OPT_IRQ_VECTOR_MAP_PERDEV=0A = && !desc->chip_data->used_vectors )=0A@@ -1738,7 +1738,7 @@ int = map_domain_pirq(=0A }=0A =0A set_domain_irq_pirq(d, irq, = info);=0A- setup_msi_irq(msi_desc, irq);=0A+ setup_msi_irq(de= sc);=0A spin_unlock_irqrestore(&desc->lock, flags);=0A }=0A = else=0A@@ -1806,6 +1806,12 @@ int unmap_domain_pirq(struct domain *d, =0A = radix_tree_int_to_ptr(-pirq));=0A }=0A =0A+ if ( = msi_desc )=0A+ {=0A+ desc->handler =3D &no_irq_type;=0A+ = desc->msi_desc =3D NULL;=0A+ }=0A+=0A spin_unlock_irqrestore(&desc->= lock, flags);=0A if (msi_desc)=0A msi_free_irq(msi_desc);=0A@@ = -1818,9 +1824,6 @@ int unmap_domain_pirq(struct domain *d, =0A = dprintk(XENLOG_G_ERR, "dom%d: could not deny access to irq %d\n",=0A = d->domain_id, pirq);=0A =0A- if ( desc->handler =3D=3D = &pci_msi_type )=0A- desc->handler =3D &no_irq_type;=0A-=0A = done:=0A return ret;=0A }=0A--- a/xen/arch/x86/msi.c=0A+++ b/xen/arch/x= 86/msi.c=0A@@ -120,11 +120,11 @@ static void msix_put_fixmap(struct = pci_d=0A /*=0A * MSI message composition=0A */=0A-void msi_compose_msg(in= t irq, struct msi_msg *msg)=0A+void msi_compose_msg(struct irq_desc *desc, = struct msi_msg *msg)=0A {=0A unsigned dest;=0A cpumask_t domain;=0A= - struct irq_cfg *cfg =3D irq_cfg(irq);=0A+ struct irq_cfg *cfg =3D = desc->chip_data;=0A int vector =3D cfg->vector;=0A domain =3D = cfg->cpu_mask;=0A =0A@@ -205,19 +205,6 @@ static void read_msi_msg(struct = msi_desc=0A iommu_read_msi_from_ire(entry, msg);=0A }=0A =0A-static= int set_irq_msi(struct msi_desc *entry)=0A-{=0A- if ( entry->irq >=3D = nr_irqs )=0A- {=0A- dprintk(XENLOG_ERR, "Trying to install msi = data for irq %d\n",=0A- entry->irq);=0A- return = -EINVAL;=0A- }=0A-=0A- irq_desc[entry->irq].msi_desc =3D entry;=0A- = return 0;=0A-}=0A-=0A static void write_msi_msg(struct msi_desc *entry, = struct msi_msg *msg)=0A {=0A entry->msg =3D *msg;=0A@@ -266,7 +253,7 = @@ static void write_msi_msg(struct msi_des=0A }=0A }=0A =0A-void = set_msi_affinity(struct irq_desc *desc, const cpumask_t *mask)=0A+static = void set_msi_affinity(struct irq_desc *desc, const cpumask_t *mask)=0A = {=0A struct msi_msg msg;=0A unsigned int dest;=0A@@ -387,16 = +374,65 @@ static int msi_get_mask_bit(const struct=0A return -1;=0A = }=0A =0A-void mask_msi_irq(struct irq_desc *desc)=0A+static void mask_msi_i= rq(struct irq_desc *desc)=0A {=0A msi_set_mask_bit(desc, 1);=0A }=0A = =0A-void unmask_msi_irq(struct irq_desc *desc)=0A+static void unmask_msi_ir= q(struct irq_desc *desc)=0A {=0A msi_set_mask_bit(desc, 0);=0A }=0A = =0A+static unsigned int startup_msi_irq(struct irq_desc *desc)=0A+{=0A+ = unmask_msi_irq(desc);=0A+ return 0;=0A+}=0A+=0A+static void ack_nonmaska= ble_msi_irq(struct irq_desc *desc)=0A+{=0A+ irq_complete_move(desc);=0A+= move_native_irq(desc);=0A+}=0A+=0A+static void ack_maskable_msi_irq(str= uct irq_desc *desc)=0A+{=0A+ ack_nonmaskable_msi_irq(desc);=0A+ = ack_APIC_irq(); /* ACKTYPE_NONE */=0A+}=0A+=0A+static void end_nonmaskable_= msi_irq(struct irq_desc *desc, u8 vector)=0A+{=0A+ ack_APIC_irq(); /* = ACKTYPE_EOI */=0A+}=0A+=0A+/*=0A+ * IRQ chip for MSI PCI/PCI-X/PCI-Express = devices,=0A+ * which implement the MSI or MSI-X capability structure.=0A+ = */=0A+static hw_irq_controller pci_msi_maskable =3D {=0A+ .typename = =3D "PCI-MSI/-X",=0A+ .startup =3D startup_msi_irq,=0A+ = .shutdown =3D mask_msi_irq,=0A+ .enable =3D unmask_msi_irq,=0A= + .disable =3D mask_msi_irq,=0A+ .ack =3D ack_maskable_= msi_irq,=0A+ .set_affinity =3D set_msi_affinity=0A+};=0A+=0A+/* As = above, but without having masking capability. */=0A+static hw_irq_controlle= r pci_msi_nonmaskable =3D {=0A+ .typename =3D "PCI-MSI",=0A+ = .startup =3D irq_startup_none,=0A+ .shutdown =3D irq_shutdown_n= one,=0A+ .enable =3D irq_enable_none,=0A+ .disable =3D = irq_disable_none,=0A+ .ack =3D ack_nonmaskable_msi_irq,=0A+ = .end =3D end_nonmaskable_msi_irq,=0A+ .set_affinity =3D = set_msi_affinity=0A+};=0A+=0A static struct msi_desc* alloc_msi_entry(void)= =0A {=0A struct msi_desc *entry;=0A@@ -412,15 +448,19 @@ static struct = msi_desc* alloc_msi_entry(=0A return entry;=0A }=0A =0A-int setup_msi_i= rq(struct msi_desc *msidesc, int irq)=0A+void setup_msi_handler(struct = irq_desc *desc, struct msi_desc *msidesc)=0A {=0A- struct msi_msg = msg;=0A+ desc->msi_desc =3D msidesc;=0A+ desc->handler =3D msi_maskab= le_irq(msidesc) ? &pci_msi_maskable=0A+ = : &pci_msi_nonmaskable;=0A+}=0A =0A- msi_compose_msg(irq, = &msg);=0A- set_irq_msi(msidesc);=0A- write_msi_msg(irq_desc[irq].msi_= desc, &msg);=0A+void setup_msi_irq(struct irq_desc *desc)=0A+{=0A+ = struct msi_msg msg;=0A =0A- return 0;=0A+ msi_compose_msg(desc, = &msg);=0A+ write_msi_msg(desc->msi_desc, &msg);=0A }=0A =0A int = msi_free_irq(struct msi_desc *entry)=0A@@ -1018,19 +1058,20 @@ static void = dump_msi(unsigned char key)=0A {=0A struct irq_desc *desc =3D = irq_to_desc(irq);=0A const struct msi_desc *entry;=0A- u32 = addr, data;=0A+ u32 addr, data, dest32;=0A+ int mask;=0A+ = struct msi_attrib attr;=0A unsigned long flags;=0A = char type;=0A =0A spin_lock_irqsave(&desc->lock, flags);=0A =0A = entry =3D desc->msi_desc;=0A- type =3D desc->handler =3D=3D = &pci_msi_type && entry;=0A-=0A- spin_unlock_irqrestore(&desc->lock, = flags);=0A-=0A- if ( !type )=0A+ if ( !entry )=0A+ = {=0A+ spin_unlock_irqrestore(&desc->lock, flags);=0A = continue;=0A+ }=0A =0A switch ( entry->msi_attrib.type = )=0A {=0A@@ -1041,6 +1082,11 @@ static void dump_msi(unsigned char = key)=0A =0A data =3D entry->msg.data;=0A addr =3D = entry->msg.address_lo;=0A+ dest32 =3D entry->msg.dest32;=0A+ = attr =3D entry->msi_attrib;=0A+ mask =3D msi_get_mask_bit(entry);=0A= +=0A+ spin_unlock_irqrestore(&desc->lock, flags);=0A =0A = printk(" MSI%c %4u vec=3D%02x%7s%6s%3sassert%5s%7s"=0A " = dest=3D%08x mask=3D%d/%d/%d\n",=0A@@ -1051,9 +1097,7 @@ static void = dump_msi(unsigned char key)=0A data & MSI_DATA_LEVEL_ASSERT = ? "" : "de",=0A addr & MSI_ADDR_DESTMODE_LOGIC ? "log" : = "phys",=0A addr & MSI_ADDR_REDIRECTION_LOWPRI ? "lowest" : = "cpu",=0A- entry->msg.dest32,=0A- entry->msi_at= trib.maskbit, entry->msi_attrib.masked,=0A- msi_get_mask_bit(= entry));=0A+ dest32, attr.maskbit, attr.masked, mask);=0A = }=0A }=0A =0A--- a/xen/include/asm-x86/msi.h=0A+++ b/xen/include/asm-x86/m= si.h=0A@@ -73,15 +73,14 @@ struct msi_msg {=0A u32 dest32; /* = used when Interrupt Remapping with EIM is enabled */=0A };=0A =0A+struct = irq_desc;=0A struct msi_desc;=0A /* Helper functions */=0A-extern void = mask_msi_irq(struct irq_desc *);=0A-extern void unmask_msi_irq(struct = irq_desc *);=0A-extern void set_msi_affinity(struct irq_desc *, const = cpumask_t *);=0A extern int pci_enable_msi(struct msi_info *msi, struct = msi_desc **desc);=0A extern void pci_disable_msi(struct msi_desc *desc);=0A= extern void pci_cleanup_msi(struct pci_dev *pdev);=0A-extern int = setup_msi_irq(struct msi_desc *desc, int irq);=0A+extern void setup_msi_han= dler(struct irq_desc *, struct msi_desc *);=0A+extern void setup_msi_irq(st= ruct irq_desc *);=0A extern void teardown_msi_irq(int irq);=0A extern int = msi_free_vector(struct msi_desc *entry);=0A extern int pci_restore_msi_stat= e(struct pci_dev *pdev);=0A@@ -89,14 +88,14 @@ extern int pci_restore_msi_s= tate(struct =0A extern unsigned int pci_msix_get_table_len(struct pci_dev = *pdev);=0A =0A struct msi_desc {=0A- struct {=0A+ struct msi_attrib = {=0A __u8 type : 5; /* {0: unused, 5h:MSI, 11h:MSI-X} = */=0A __u8 maskbit : 1; /* mask-pending bit supported ? = */=0A __u8 masked : 1;=0A __u8 is_64 : = 1; /* Address size: 0=3D32bit 1=3D64bit */=0A __u8 = pos; /* Location of the msi capability */=0A = __u16 entry_nr; /* specific enabled entry */=0A- = }msi_attrib;=0A+ } msi_attrib;=0A =0A struct list_head list;=0A = =0A@@ -122,8 +121,6 @@ int msi_free_irq(struct msi_desc *entry)=0A */=0A = #define NR_HP_RESERVED_VECTORS 20=0A =0A-extern const struct hw_interrupt_= type pci_msi_type;=0A-=0A #define PCI_MSIX_ENTRY_SIZE = 16=0A #define PCI_MSIX_ENTRY_LOWER_ADDR_OFFSET 0=0A #define PCI_MSIX_ENTR= Y_UPPER_ADDR_OFFSET 4=0A@@ -221,5 +218,6 @@ struct msg_address {=0A = __u32 hi_address;=0A } __attribute__ ((packed));=0A =0A-void msi_compose_= msg(int irq, struct msi_msg *);=0A+void msi_compose_msg(struct irq_desc *, = struct msi_msg *);=0A+=0A #endif /* __ASM_MSI_H */=0A --=__Part250A1ECF.0__= Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel --=__Part250A1ECF.0__=-- From xen-devel-bounces@lists.xensource.com Tue Sep 20 09:59:49 2011 Return-path: <xen-devel-bounces@lists.xensource.com> Envelope-to: www-data@lists.xensource.com Delivery-date: Tue, 20 Sep 2011 09:59:49 -0700 Received: from localhost ([127.0.0.1] helo=lists.colo.xensource.com) by lists.xensource.com with esmtp (Exim 4.43) id 1R63fh-0001qI-C1; Tue, 20 Sep 2011 09:59:49 -0700 Received: from mail21.messagelabs.com ([85.158.143.35]) by lists.xensource.com with esmtp (Exim 4.43) id 1R63eO-0001dv-Eq for xen-devel@lists.xensource.com; Tue, 20 Sep 2011 09:58:29 -0700 X-Env-Sender: dan.magenheimer@oracle.com X-Msg-Ref: server-12.tower-21.messagelabs.com!1316537888!50685488!1 X-Originating-IP: [141.146.126.227] X-StarScan-Version: 6.4.1; banners=-,-,- X-VirusChecked: Checked Received: (qmail 5011 invoked from network); 20 Sep 2011 16:58:09 -0000 Received: from acsinet15.oracle.com (HELO acsinet15.oracle.com) (141.146.126.227) by server-12.tower-21.messagelabs.com with DHE-RSA-AES256-SHA encrypted SMTP; 20 Sep 2011 16:58:09 -0000 Received: from acsinet21.oracle.com (acsinet21.oracle.com [141.146.126.237]) by acsinet15.oracle.com (Switch-3.4.4/Switch-3.4.4) with ESMTP id p8KGw9Sw014312 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Tue, 20 Sep 2011 16:58:11 GMT Received: from acsmt357.oracle.com (acsmt357.oracle.com [141.146.40.157]) by acsinet21.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id p8KGw9Bd019221 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 20 Sep 2011 16:58:09 GMT Received: from abhmt110.oracle.com (abhmt110.oracle.com [141.146.116.62]) by acsmt357.oracle.com (8.12.11.20060308/8.12.11) with ESMTP id p8KGw4s9007330; Tue, 20 Sep 2011 11:58:04 -0500 MIME-Version: 1.0 Message-ID: <63997331-e53b-48e5-bf7c-87141aae49d6@default> Date: Tue, 20 Sep 2011 09:57:47 -0700 (PDT) From: Dan Magenheimer <dan.magenheimer@oracle.com> To: David Vrabel <david.vrabel@citrix.com>, xen-devel@lists.xensource.com Subject: RE: [Xen-devel] xen: memory initialization/balloon fixes (#3) References: <1316089768-22461-1-git-send-email-david.vrabel@citrix.com> In-Reply-To: <1316089768-22461-1-git-send-email-david.vrabel@citrix.com> X-Priority: 3 X-Mailer: Oracle Beehive Extensions for Outlook 2.0.1.4.1.0 (410211) [OL 12.0.6557.5001] Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable X-Source-IP: acsinet21.oracle.com [141.146.126.237] X-Auth-Type: Internal IP X-CT-RefId: str=0001.0A090205.4E78C623.00CF:SCFMA922111,ss=1,re=-4.000,fgs=0 Cc: Konrad Wilk <konrad.wilk@oracle.com> X-BeenThere: xen-devel@lists.xensource.com X-Mailman-Version: 2.1.5 Precedence: list List-Id: Xen developer discussion <xen-devel.lists.xensource.com> List-Unsubscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe> List-Post: <mailto:xen-devel@lists.xensource.com> List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help> List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=subscribe> Sender: xen-devel-bounces@lists.xensource.com Errors-To: xen-devel-bounces@lists.xensource.com > From: David Vrabel [mailto:david.vrabel@citrix.com] > Sent: Thursday, September 15, 2011 6:29 AM > To: xen-devel@lists.xensource.com > Cc: Konrad Rzeszutek Wilk > Subject: [Xen-devel] xen: memory initialization/balloon fixes (#3) >=20 > This set of patches fixes some bugs in the memory initialization under > Xen and in Xen's memory balloon driver. They can make 100s of MB of > additional RAM available (depending on the system/configuration). >=20 > Patch 1 is already applied. >=20 > Patch 2 fixes a bug in patch 1 and should be queued for 3.1 (and along > with patch 1 considered for 3.0 stable). >=20 > Patch 3 is a bug fix and should be queued for 3.1 and possibly > queued for the 3.0 stable tree. >=20 > Patches 5 & 6 increase the amount of low memory in 32 bit domains > started with < 1 GiB of RAM. Please queue for 3.2 >=20 > Patch 7 releases all pages in the initial allocation with PFNs that > lie within a 1-1 mapping. This seems correct to me as I think that > once the 1-1 mapping is set the MFN of the original page is lost so > it's no longer accessible by the kernel (and it cannot be used by > another domain Hi David -- Thanks for your patches! I am looking at a memory capacity/ballooning weirdness that I hoped your patchset might fix, but so far it has not. I'm wondering if there was an earlier fix that you are building upon and that I am missing. My problem occurs in a PV domU with an upstream-variant kernel based on 3.0.5. The problem is that the total amount of memory as seen from inside the guest is always substantially less than the amount of memory seen from outside the guest. The difference seems to be fixed within a given boot, but assigning a different vm.cfg mem=3D changes the amount. (For example, the difference D is about 18MB on a mem=3D128 boot and about 36MB on a mem=3D1024 boot.) Part B of the problem (and the one most important to me) is that setting /sys/devices/system/xen_memory/xen_memory0/target_kb to X results in a MemTotal inside the domU (as observed by "head -1 /proc/meminfo") of X-D. This can be particularly painful when X is aggressively small as X-D may result in OOMs. To use kernel function/variable names (and I observed this with some debugging code), when balloon_set_new_target(X) is called totalram_pages gets driven to X-D. I am using xm, but I don't think this is a toolchain problem because the problem can be provoked and observed entirely within the guest... though I suppose it is possible that that the initial "mem=3D" is the origin of the problem and the balloon driver just perpetuates the initial difference. (I tried xl... same problem... my Xen/toolset version is 4.1.2-rc1-pre cset 23102) The descriptions in your patchset sound exactly as if you are attacking the same problem, but I'm not seeing any improved result. Any thoughts or ideas? Thanks, Dan _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel From xen-devel-bounces@lists.xensource.com Tue Sep 20 10:47:10 2011 Return-path: <xen-devel-bounces@lists.xensource.com> Envelope-to: www-data@lists.xensource.com Delivery-date: Tue, 20 Sep 2011 10:47:10 -0700 Received: from localhost ([127.0.0.1] helo=lists.colo.xensource.com) by lists.xensource.com with esmtp (Exim 4.43) id 1R64PV-0004TY-Kp; Tue, 20 Sep 2011 10:47:09 -0700 Received: from mail27.messagelabs.com ([193.109.254.147]) by lists.xensource.com with esmtp (Exim 4.43) id 1R64Oe-0004H2-RW for Xen-devel@lists.xensource.com; Tue, 20 Sep 2011 10:46:17 -0700 X-Env-Sender: tim@xen.org X-Msg-Ref: server-10.tower-27.messagelabs.com!1316540753!36544311!1 X-Originating-IP: [81.29.64.94] X-StarScan-Version: 6.4.1; banners=-,-,- X-VirusChecked: Checked Received: (qmail 3554 invoked from network); 20 Sep 2011 17:45:53 -0000 Received: from ocelot.phlegethon.org (HELO mail.phlegethon.org) (81.29.64.94) by server-10.tower-27.messagelabs.com with DHE-RSA-AES256-SHA encrypted SMTP; 20 Sep 2011 17:45:53 -0000 Received: from tjd by mail.phlegethon.org with local (Exim 4.67 (FreeBSD)) (envelope-from <tim@xen.org>) id 1R64Ob-0009EK-4g; Tue, 20 Sep 2011 17:46:13 +0000 Date: Tue, 20 Sep 2011 18:46:13 +0100 From: Tim Deegan <tim@xen.org> To: Pratik shinde <pracshi@gmail.com> Subject: Re: [Xen-devel] proposing an idea for my last year project Message-ID: <20110920174613.GA35343@ocelot.phlegethon.org> References: <CAEAezkXkZHOX1bVw355AjOSzq373zBzdN5O7V3Q2SsO-fjUa+Q@mail.gmail.com> Mime-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline In-Reply-To: <CAEAezkXkZHOX1bVw355AjOSzq373zBzdN5O7V3Q2SsO-fjUa+Q@mail.gmail.com> User-Agent: Mutt/1.4.2.1i Cc: Xen-devel@lists.xensource.com X-BeenThere: xen-devel@lists.xensource.com X-Mailman-Version: 2.1.5 Precedence: list List-Id: Xen developer discussion <xen-devel.lists.xensource.com> List-Unsubscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe> List-Post: <mailto:xen-devel@lists.xensource.com> List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help> List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=subscribe> Sender: xen-devel-bounces@lists.xensource.com Errors-To: xen-devel-bounces@lists.xensource.com At 07:40 -0700 on 18 Sep (1316331619), Pratik shinde wrote: > Idea is that if any page i know can be shared between domains and is > already present in memory then same page is used rather than bringing it > from hard disk.I read memory merging but they are bringing page in memory > and then deciding the page duplication. > I want to know whether above idea can be implemented or not It has been implemented at least twice. Here's a paper about it: http://www.usenix.org/event/usenix09/tech/full_papers/milos/milos_html/index.html Cheers, Tim. _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel From xen-devel-bounces@lists.xensource.com Tue Sep 20 10:58:46 2011 Return-path: <xen-devel-bounces@lists.xensource.com> Envelope-to: www-data@lists.xensource.com Delivery-date: Tue, 20 Sep 2011 10:58:46 -0700 Received: from localhost ([127.0.0.1] helo=lists.colo.xensource.com) by lists.xensource.com with esmtp (Exim 4.43) id 1R64ai-00051U-Nj; Tue, 20 Sep 2011 10:58:44 -0700 Received: from mail216.messagelabs.com ([85.158.143.99]) by lists.xensource.com with esmtp (Exim 4.43) id 1R64ZK-0004oq-KY for xen-devel@lists.xensource.com; Tue, 20 Sep 2011 10:57:19 -0700 X-Env-Sender: tim@xen.org X-Msg-Ref: server-10.tower-216.messagelabs.com!1316541435!10907194!1 X-Originating-IP: [81.29.64.94] X-StarScan-Version: 6.4.1; banners=-,-,- X-VirusChecked: Checked Received: (qmail 27182 invoked from network); 20 Sep 2011 17:57:15 -0000 Received: from ocelot.phlegethon.org (HELO mail.phlegethon.org) (81.29.64.94) by server-10.tower-216.messagelabs.com with DHE-RSA-AES256-SHA encrypted SMTP; 20 Sep 2011 17:57:15 -0000 Received: from tjd by mail.phlegethon.org with local (Exim 4.67 (FreeBSD)) (envelope-from <tim@xen.org>) id 1R64ZF-0009Gj-0U; Tue, 20 Sep 2011 17:57:13 +0000 Date: Tue, 20 Sep 2011 18:57:12 +0100 From: Tim Deegan <tim@xen.org> To: AP <apxeng@gmail.com>, Eddie Dong <eddie.dong@intel.com> Subject: Re: [Xen-devel] Testing nested virtualization on Intel CPUs Message-ID: <20110920175712.GB35343@ocelot.phlegethon.org> References: <CAGU+autjPnjevraC5vhX4RAMC2XrqkfKUN_ZuJz1r0r3078=0Q@mail.gmail.com> Mime-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline In-Reply-To: <CAGU+autjPnjevraC5vhX4RAMC2XrqkfKUN_ZuJz1r0r3078=0Q@mail.gmail.com> User-Agent: Mutt/1.4.2.1i Cc: xen-devel@lists.xensource.com X-BeenThere: xen-devel@lists.xensource.com X-Mailman-Version: 2.1.5 Precedence: list List-Id: Xen developer discussion <xen-devel.lists.xensource.com> List-Unsubscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe> List-Post: <mailto:xen-devel@lists.xensource.com> List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help> List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=subscribe> Sender: xen-devel-bounces@lists.xensource.com Errors-To: xen-devel-bounces@lists.xensource.com Hi, Cc'ing Eddie Dong, who wrote this code. At 18:16 -0700 on 16 Sep (1316196980), AP wrote: > I am testing out nested virtualization on a Lenovo x220 (Intel > i7-2620M). I am running xen-unstable (23842:483c5f8319ad) and Linux > 3.0 (Ubuntu 10.10). > I brought up a Centos 5.6 VM and installed Xen that is packaged with > it. I think it is a variant of 3.0. The CentOS Xen VM boots very > slowly but it does finally come up in to the nested Dom0. Yes, booting Xen as a nested guest is very slow at startup, because of how Xen relocates the bottom 1MB at boot time. You might find that 32-bit Xen boots faster. In general I expect performance of a nested-HVM guest on Intel to be quite poor, because it doesn't yet have nested EPT support. Eddie, is that something you're working on? Tim. _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel From xen-devel-bounces@lists.xensource.com Tue Sep 20 11:02:40 2011 Return-path: <xen-devel-bounces@lists.xensource.com> Envelope-to: www-data@lists.xensource.com Delivery-date: Tue, 20 Sep 2011 11:02:40 -0700 Received: from localhost ([127.0.0.1] helo=lists.colo.xensource.com) by lists.xensource.com with esmtp (Exim 4.43) id 1R64eU-0005RP-De; Tue, 20 Sep 2011 11:02:38 -0700 Received: from mail21.messagelabs.com ([85.158.143.35]) by lists.xensource.com with esmtp (Exim 4.43) id 1R64be-00058S-Kj for xen-devel@lists.xensource.com; Tue, 20 Sep 2011 10:59:56 -0700 X-Env-Sender: Ian.Jackson@eu.citrix.com X-Msg-Ref: server-7.tower-21.messagelabs.com!1316541549!55601100!1 X-Originating-IP: [62.200.22.115] X-StarScan-Version: 6.4.1; banners=-,-,- X-VirusChecked: Checked Received: (qmail 2382 invoked from network); 20 Sep 2011 17:59:09 -0000 Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115) by server-7.tower-21.messagelabs.com with RC4-SHA encrypted SMTP; 20 Sep 2011 17:59:09 -0000 X-IronPort-AV: E=Sophos;i="4.68,412,1312156800"; d="scan'208";a="7961541" Received: from lonpmailmx01.citrite.net ([10.30.203.162]) by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5; 20 Sep 2011 17:59:39 +0000 Received: from norwich.cam.xci-test.com (10.80.248.129) by smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id 8.3.137.0; Tue, 20 Sep 2011 18:59:38 +0100 Received: from mariner.cam.xci-test.com ([10.80.2.22] helo=mariner.uk.xensource.com ident=Debian-exim) by norwich.cam.xci-test.com with esmtp (Exim 4.72) (envelope-from <Ian.Jackson@eu.citrix.com>) id 1R64ba-0008MX-KT; Tue, 20 Sep 2011 17:59:38 +0000 Received: from iwj by mariner.uk.xensource.com with local (Exim 4.69) (envelope-from <Ian.Jackson@eu.citrix.com>) id 1R64ba-0001vi-JJ; Tue, 20 Sep 2011 18:59:38 +0100 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Message-ID: <20088.54410.590177.546463@mariner.uk.xensource.com> Date: Tue, 20 Sep 2011 18:59:38 +0100 To: Thomas Goirand <thomas@goirand.fr> Subject: Re: [Xen-devel] [patch] Spelling typos fix Newsgroups: chiark.mail.xen.devel In-Reply-To: <4E5DEAAB.8000100@goirand.fr> References: <4E5DEAAB.8000100@goirand.fr> X-Mailer: VM 8.0.9 under Emacs 21.4.1 (i486-pc-linux-gnu) From: Ian Jackson <Ian.Jackson@eu.citrix.com> Cc: xen-devel@lists.xensource.com, Stefano Stabellini <Stefano.Stabellini@eu.citrix.com> X-BeenThere: xen-devel@lists.xensource.com X-Mailman-Version: 2.1.5 Precedence: list List-Id: Xen developer discussion <xen-devel.lists.xensource.com> List-Unsubscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe> List-Post: <mailto:xen-devel@lists.xensource.com> List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help> List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=subscribe> Sender: xen-devel-bounces@lists.xensource.com Errors-To: xen-devel-bounces@lists.xensource.com Thomas Goirand writes ("[Xen-devel] [patch] Spelling typos fix"): > Please apply this tiny patch, which is correcting 2 spelling issues. The xenpm part of this has been applied to xen-unstable.hg. I'm not sure it's best to apply the qemu part to qemu-xen-unstable. That tree is intended to be obsolete and to be replaced with the new upstream version of qemu. If it is applicable to modern qemu it's worth considering applying it there, so I've CC'd Stefano. Ian. _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel From xen-devel-bounces@lists.xensource.com Tue Sep 20 11:07:03 2011 Return-path: <xen-devel-bounces@lists.xensource.com> Envelope-to: www-data@lists.xensource.com Delivery-date: Tue, 20 Sep 2011 11:07:03 -0700 Received: from localhost ([127.0.0.1] helo=lists.colo.xensource.com) by lists.xensource.com with esmtp (Exim 4.43) id 1R64il-0005rY-47; Tue, 20 Sep 2011 11:07:03 -0700 Received: from mail27.messagelabs.com ([193.109.254.147]) by lists.xensource.com with esmtp (Exim 4.43) id 1R64eB-0005O4-9F for xen-devel@lists.xensource.com; Tue, 20 Sep 2011 11:02:22 -0700 X-Env-Sender: Ian.Jackson@eu.citrix.com X-Msg-Ref: server-13.tower-27.messagelabs.com!1316541724!40850615!1 X-Originating-IP: [62.200.22.115] X-StarScan-Version: 6.4.1; banners=-,-,- X-VirusChecked: Checked Received: (qmail 32754 invoked from network); 20 Sep 2011 18:02:04 -0000 Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115) by server-13.tower-27.messagelabs.com with RC4-SHA encrypted SMTP; 20 Sep 2011 18:02:04 -0000 X-IronPort-AV: E=Sophos;i="4.68,412,1312156800"; d="scan'208";a="7961588" Received: from lonpmailmx01.citrite.net ([10.30.203.162]) by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5; 20 Sep 2011 18:02:15 +0000 Received: from norwich.cam.xci-test.com (10.80.248.129) by smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id 8.3.137.0; Tue, 20 Sep 2011 19:02:15 +0100 Received: from mariner.cam.xci-test.com ([10.80.2.22] helo=mariner.uk.xensource.com ident=Debian-exim) by norwich.cam.xci-test.com with esmtp (Exim 4.72) (envelope-from <Ian.Jackson@eu.citrix.com>) id 1R64e7-0008NA-Gs; Tue, 20 Sep 2011 18:02:15 +0000 Received: from iwj by mariner.uk.xensource.com with local (Exim 4.69) (envelope-from <Ian.Jackson@eu.citrix.com>) id 1R64e7-0001vy-G8; Tue, 20 Sep 2011 19:02:15 +0100 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Message-ID: <20088.54567.491056.744920@mariner.uk.xensource.com> Date: Tue, 20 Sep 2011 19:02:15 +0100 To: Keir Fraser <keir@xen.org> Subject: Re: [Xen-devel] [PATCH, RFC 0/7] PCI multi-segment support In-Reply-To: <CA8A95BF.31189%keir@xen.org> References: <4E64EF860200007800054B03@nat28.tlf.novell.com> <CA8A95BF.31189%keir@xen.org> X-Mailer: VM 8.0.9 under Emacs 21.4.1 (i486-pc-linux-gnu) From: Ian Jackson <Ian.Jackson@eu.citrix.com> Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>, Jan Beulich <JBeulich@suse.com> X-BeenThere: xen-devel@lists.xensource.com X-Mailman-Version: 2.1.5 Precedence: list List-Id: Xen developer discussion <xen-devel.lists.xensource.com> List-Unsubscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe> List-Post: <mailto:xen-devel@lists.xensource.com> List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help> List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=subscribe> Sender: xen-devel-bounces@lists.xensource.com Errors-To: xen-devel-bounces@lists.xensource.com Keir Fraser writes ("Re: [Xen-devel] [PATCH, RFC 0/7] PCI multi-segment support"): > I think the intention is to maintain API compatibility for libxenlight, and > have out-of-tree tool stacks/librariues build on top of that. Yes, but we're not there yet. > I think there are libvirt bindings to libxenlight now, for example? There are but I'm not sure of their release status. > My conclusion would be you can do the cleaner change to domctl. Interested > in Ian Jackson's view however. We need to preserve compatibility with other versions of linux and qemu. Do these programs need to know about these changes too ? Ian. _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel From xen-devel-bounces@lists.xensource.com Tue Sep 20 11:09:02 2011 Return-path: <xen-devel-bounces@lists.xensource.com> Envelope-to: www-data@lists.xensource.com Delivery-date: Tue, 20 Sep 2011 11:09:02 -0700 Received: from localhost ([127.0.0.1] helo=lists.colo.xensource.com) by lists.xensource.com with esmtp (Exim 4.43) id 1R64kf-0006F1-4K; Tue, 20 Sep 2011 11:09:01 -0700 Received: from mail21.messagelabs.com ([85.158.143.35]) by lists.xensource.com with smtp (Exim 4.43) id 1R64ee-0005Sf-9p for xen-devel@lists.xensource.com; Tue, 20 Sep 2011 11:02:59 -0700 X-Env-Sender: allen.m.kay@intel.com X-Msg-Ref: server-10.tower-21.messagelabs.com!1316541750!54859266!1 X-Originating-IP: [134.134.136.20] X-StarScan-Version: 6.4.1; banners=-,-,- X-VirusChecked: Checked Received: (qmail 18517 invoked from network); 20 Sep 2011 18:02:30 -0000 Received: from mga02.intel.com (HELO mga02.intel.com) (134.134.136.20) by server-10.tower-21.messagelabs.com with SMTP; 20 Sep 2011 18:02:30 -0000 Received: from orsmga002.jf.intel.com ([10.7.209.21]) by orsmga101.jf.intel.com with ESMTP; 20 Sep 2011 11:02:44 -0700 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="4.67,351,1309762800"; d="scan'208";a="50766534" Received: from orsmsx604.amr.corp.intel.com ([10.22.226.87]) by orsmga002.jf.intel.com with ESMTP; 20 Sep 2011 11:02:44 -0700 Received: from orsmsx605.amr.corp.intel.com (10.22.226.10) by orsmsx604.amr.corp.intel.com (10.22.226.87) with Microsoft SMTP Server (TLS) id 8.2.255.0; Tue, 20 Sep 2011 11:02:43 -0700 Received: from orsmsx505.amr.corp.intel.com ([10.22.226.208]) by orsmsx605.amr.corp.intel.com ([10.22.226.10]) with mapi; Tue, 20 Sep 2011 11:02:43 -0700 From: "Kay, Allen M" <allen.m.kay@intel.com> To: Jan Beulich <JBeulich@suse.com> Date: Tue, 20 Sep 2011 11:02:42 -0700 Subject: RE: [Xen-devel] RE: Resend: RE: enable_ats_device() call site Thread-Topic: [Xen-devel] RE: Resend: RE: enable_ats_device() call site Thread-Index: Acx3nRxLzuSwnN4bTfWikxrKGggfvAAIbEuw Message-ID: <987664A83D2D224EAE907B061CE93D5301EDED2D32@orsmsx505.amr.corp.intel.com> References: <4E4E48360200007800051F65@nat28.tlf.novell.com> <987664A83D2D224EAE907B061CE93D5301EA5B67F0@orsmsx505.amr.corp.intel.com> <4E5380890200007800052B61@nat28.tlf.novell.com> <4E78B7CA0200007800056CCE@nat28.tlf.novell.com> In-Reply-To: <4E78B7CA0200007800056CCE@nat28.tlf.novell.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: Xen Devel <xen-devel@lists.xensource.com> X-BeenThere: xen-devel@lists.xensource.com X-Mailman-Version: 2.1.5 Precedence: list List-Id: Xen developer discussion <xen-devel.lists.xensource.com> List-Unsubscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe> List-Post: <mailto:xen-devel@lists.xensource.com> List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help> List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=subscribe> Sender: xen-devel-bounces@lists.xensource.com Errors-To: xen-devel-bounces@lists.xensource.com Jan, Thanks for the reminder. This has slip through the cracks. The patch look= good. With this patch, we shouldn't need the existing call to pci_enable_= acs() in setup_dom0_devices(), correct? I agree that the same problem exists for bus-to-bridge mapping function pci= _scan_device(). By the way, we probably should take the opportunity to giv= e it a proper name that reflects to the true purpose of this function. Allen -----Original Message----- From: Jan Beulich [mailto:JBeulich@suse.com]=20 Sent: Tuesday, September 20, 2011 6:57 AM To: Kay, Allen M Cc: Xen Devel Subject: [Xen-devel] RE: Resend: RE: enable_ats_device() call site Ping? >>> On 23.08.11 at 10:27, "Jan Beulich" <JBeulich@novell.com> wrote: >>>> On 23.08.11 at 00:01, "Kay, Allen M" <allen.m.kay@intel.com> wrote: >>> And why is it VT-d specific then? The problem to solve is that enabling >>>may not happen when it is first attempted, in the case where Xen on its >>>own can't be certain that using MMCFG is safe. Hence when the device >>>gets reported by Dom0 (or when MMCFG gets enabled for the respective >>>bus), another attempt needs to be made at enabling it. De-assigning and >>>then re-assigning the device to Dom0 seems to be overkill to me. >>=20 >> The part that is VT-d specific is ATS capability reporting in ACPI DMAR >> table for reporting ATS capability in root ports. I not so clear on wha= t >> do you mean by making another attempt when initial ATS enabling attempt= =20 >> fails. >=20 > The initial enabling may fail because of the unavailability of MMCFG > accesses (due to the memory range(s) used not being reserved in E820, > which is not required to be the case by the spec). Once MMCFG gets > enabled, this needs to be re-attempted at some point, and the logical > point appears to be when the device gets re-registered by Dom0. >=20 >> Do you have a patch to address this issue? >=20 > Only for the (trivial) ACS part so far (see below). >=20 > There's also a second aspect here: the bus-to-bridge mappings > currently get established just once, during boot. This is already > hot(un)plug incompatible, but will become even more of a problem > when multi-segment support gets in (I should be sending out patches > soon), for the same MMCFG-initially-unavailable reason as outlined > above (as in that case non-zero segments can't be scanned at boot). >=20 > Jan >=20 > --- a/xen/drivers/passthrough/pci.c > +++ b/xen/drivers/passthrough/pci.c > @@ -350,9 +350,10 @@ int pci_add_device(u16 seg, u8 bus, u8 d > } > =20 > list_add(&pdev->domain_list, &dom0->arch.pdev_list); > - pci_enable_acs(pdev); > } > =20 > + pci_enable_acs(pdev); > + > out: > spin_unlock(&pcidevs_lock); > printk(XENLOG_DEBUG "PCI add %s %04x:%02x:%02x.%u\n", pdev_type, >=20 >=20 >=20 > _______________________________________________ > Xen-devel mailing list > Xen-devel@lists.xensource.com=20 > http://lists.xensource.com/xen-devel=20 _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel From xen-devel-bounces@lists.xensource.com Tue Sep 20 11:11:56 2011 Return-path: <xen-devel-bounces@lists.xensource.com> Envelope-to: www-data@lists.xensource.com Delivery-date: Tue, 20 Sep 2011 11:11:56 -0700 Received: from localhost ([127.0.0.1] helo=lists.colo.xensource.com) by lists.xensource.com with esmtp (Exim 4.43) id 1R64nT-0006df-SX; Tue, 20 Sep 2011 11:11:55 -0700 Received: from mail182.messagelabs.com ([85.158.139.83]) by lists.xensource.com with esmtp (Exim 4.43) id 1R64mQ-0006Qt-Au for xen-devel@lists.xensource.com; Tue, 20 Sep 2011 11:10:51 -0700 X-Env-Sender: Stefano.Stabellini@eu.citrix.com X-Msg-Ref: server-14.tower-182.messagelabs.com!1316542247!18933224!1 X-Originating-IP: [62.200.22.115] X-StarScan-Version: 6.4.1; banners=-,-,- X-VirusChecked: Checked Received: (qmail 7790 invoked from network); 20 Sep 2011 18:10:47 -0000 Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115) by server-14.tower-182.messagelabs.com with RC4-SHA encrypted SMTP; 20 Sep 2011 18:10:47 -0000 X-IronPort-AV: E=Sophos;i="4.68,412,1312156800"; d="scan'208";a="7961729" Received: from lonpmailmx01.citrite.net ([10.30.203.162]) by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5; 20 Sep 2011 18:10:47 +0000 Received: from kaball.uk.xensource.com (10.80.2.59) by LONPMAILMX01.citrite.net (10.30.203.162) with Microsoft SMTP Server id 8.3.137.0; Tue, 20 Sep 2011 19:10:47 +0100 Date: Tue, 20 Sep 2011 19:10:33 +0100 From: Stefano Stabellini <stefano.stabellini@eu.citrix.com> X-X-Sender: sstabellini@kaball-desktop To: duolvxendev <duolvxendev@yahoo.cn> Subject: Re: [Xen-devel] Permission for xenstore operation on HVM In-Reply-To: <1316338995760-4815691.post@n5.nabble.com> Message-ID: <alpine.DEB.2.00.1109201908010.8700@kaball-desktop> References: <1316338995760-4815691.post@n5.nabble.com> User-Agent: Alpine 2.00 (DEB 1167 2008-08-23) MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com> X-BeenThere: xen-devel@lists.xensource.com X-Mailman-Version: 2.1.5 Precedence: list List-Id: Xen developer discussion <xen-devel.lists.xensource.com> List-Unsubscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe> List-Post: <mailto:xen-devel@lists.xensource.com> List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help> List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=subscribe> Sender: xen-devel-bounces@lists.xensource.com Errors-To: xen-devel-bounces@lists.xensource.com On Sun, 18 Sep 2011, duolvxendev wrote: > Hi, I'm trying to write some message using xenbus_printf to xenstore from a > debian HVM guest with pv-on-HVM driver. I got a permission denied error > return code. How should I do if I want write the message to xenstore in > kernel module? > > PS: the hypervisor is xen-3.4.2; the dom0 is CentOS 5.4 and the guest is > Debian 6; the pv-on-HVM driver is built from Alex Bligh's patch and it works > well. Where are you trying to write to? Most locations, other than /local/domain/$DOMID and subpaths, cannot be written by unprivileged guests. _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel From xen-devel-bounces@lists.xensource.com Tue Sep 20 12:24:52 2011 Return-path: <xen-devel-bounces@lists.xensource.com> Envelope-to: www-data@lists.xensource.com Delivery-date: Tue, 20 Sep 2011 12:24:52 -0700 Received: from localhost ([127.0.0.1] helo=lists.colo.xensource.com) by lists.xensource.com with esmtp (Exim 4.43) id 1R65w4-0000lP-HR; Tue, 20 Sep 2011 12:24:52 -0700 Received: from mail216.messagelabs.com ([85.158.143.99]) by lists.xensource.com with esmtp (Exim 4.43) id 1R65v0-0000Yr-LY for xen-devel@lists.xensource.com; Tue, 20 Sep 2011 12:23:47 -0700 X-Env-Sender: Ian.Campbell@eu.citrix.com X-Msg-Ref: server-2.tower-216.messagelabs.com!1316546623!18562163!1 X-Originating-IP: [62.200.22.115] X-StarScan-Version: 6.4.1; banners=-,-,- X-VirusChecked: Checked Received: (qmail 12428 invoked from network); 20 Sep 2011 19:23:43 -0000 Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115) by server-2.tower-216.messagelabs.com with RC4-SHA encrypted SMTP; 20 Sep 2011 19:23:43 -0000 X-IronPort-AV: E=Sophos;i="4.68,413,1312156800"; d="scan'208";a="7962477" Received: from lonpmailmx01.citrite.net ([10.30.203.162]) by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5; 20 Sep 2011 19:23:43 +0000 Received: from [127.0.0.1] (10.80.16.67) by smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id 8.3.137.0; Tue, 20 Sep 2011 20:23:43 +0100 Subject: Re: [Xen-devel] XL: pv guests dont reboot after migration (xen4.1.2-rc2-pre) From: Ian Campbell <Ian.Campbell@citrix.com> To: Andreas Olsowski <andreas.olsowski@leuphana.de> In-Reply-To: <4E785FDD.40209@leuphana.de> References: <4E785FDD.40209@leuphana.de> Content-Type: text/plain; charset="ISO-8859-1" Organization: Citrix Systems, Inc. Date: Tue, 20 Sep 2011 20:23:41 +0100 Message-ID: <1316546621.5182.23.camel@dagon.hellion.org.uk> MIME-Version: 1.0 X-Mailer: Evolution 2.32.3 Content-Transfer-Encoding: 7bit Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com> X-BeenThere: xen-devel@lists.xensource.com X-Mailman-Version: 2.1.5 Precedence: list List-Id: Xen developer discussion <xen-devel.lists.xensource.com> List-Unsubscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe> List-Post: <mailto:xen-devel@lists.xensource.com> List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help> List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=subscribe> Sender: xen-devel-bounces@lists.xensource.com Errors-To: xen-devel-bounces@lists.xensource.com On Tue, 2011-09-20 at 10:41 +0100, Andreas Olsowski wrote: > A pv guest will not reboot after migration, the guest itself does > everything right, including the shutdown, but xl does not recreate the > guest, it just shuts it down. After the migrate but before the shutdown is there an xl process associated with the guest? Please take alook at http://wiki.xen.org/xenwiki/ReportingBugs it includes a useful list of bits of info (logfiles etc), including those in your report will help us to help you. For example: What exact commands are you running on the host and in the guest? What is in your guest cfg file? What does /var/log/xen/*-$GUESTNAME* contain? Ian. > > This goes for 2.6.39 and 3.0.4 guest kernels, havent tried different > ones. I also haven tried different xen versions. > > Dont know if this would affect hvm, probably not since qemu leaves the > guest running and does a "proper" restart. > > > I guess this behavior has always been that way and noone ever bothered > to bring it up, well now i do :) > _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel From xen-devel-bounces@lists.xensource.com Tue Sep 20 12:28:33 2011 Return-path: <xen-devel-bounces@lists.xensource.com> Envelope-to: www-data@lists.xensource.com Delivery-date: Tue, 20 Sep 2011 12:28:33 -0700 Received: from localhost ([127.0.0.1] helo=lists.colo.xensource.com) by lists.xensource.com with esmtp (Exim 4.43) id 1R65zc-0001B3-Ng; Tue, 20 Sep 2011 12:28:33 -0700 Received: from mail182.messagelabs.com ([85.158.139.83]) by lists.xensource.com with esmtp (Exim 4.43) id 1R65z9-0000yo-E1 for xen-devel@lists.xensource.com; Tue, 20 Sep 2011 12:28:03 -0700 X-Env-Sender: Ian.Campbell@eu.citrix.com X-Msg-Ref: server-11.tower-182.messagelabs.com!1316546880!19104525!1 X-Originating-IP: [62.200.22.115] X-StarScan-Version: 6.4.1; banners=-,-,- X-VirusChecked: Checked Received: (qmail 22894 invoked from network); 20 Sep 2011 19:28:00 -0000 Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115) by server-11.tower-182.messagelabs.com with RC4-SHA encrypted SMTP; 20 Sep 2011 19:28:00 -0000 X-IronPort-AV: E=Sophos;i="4.68,413,1312156800"; d="scan'208";a="7962514" Received: from lonpmailmx01.citrite.net ([10.30.203.162]) by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5; 20 Sep 2011 19:27:59 +0000 Received: from [127.0.0.1] (10.80.16.67) by smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id 8.3.137.0; Tue, 20 Sep 2011 20:28:00 +0100 Subject: Re: [Xen-devel] pv guests die after failed migration From: Ian Campbell <Ian.Campbell@citrix.com> To: Andreas Olsowski <andreas.olsowski@leuphana.de> In-Reply-To: <4E786015.80603@leuphana.de> References: <4E786015.80603@leuphana.de> Content-Type: text/plain; charset="ISO-8859-1" Organization: Citrix Systems, Inc. Date: Tue, 20 Sep 2011 20:27:59 +0100 Message-ID: <1316546879.5182.26.camel@dagon.hellion.org.uk> MIME-Version: 1.0 X-Mailer: Evolution 2.32.3 Content-Transfer-Encoding: 7bit Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com> X-BeenThere: xen-devel@lists.xensource.com X-Mailman-Version: 2.1.5 Precedence: list List-Id: Xen developer discussion <xen-devel.lists.xensource.com> List-Unsubscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe> List-Post: <mailto:xen-devel@lists.xensource.com> List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help> List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=subscribe> Sender: xen-devel-bounces@lists.xensource.com Errors-To: xen-devel-bounces@lists.xensource.com On Tue, 2011-09-20 at 10:42 +0100, Andreas Olsowski wrote: > When xm failed to do a live migration the system was resumed on the > sending host. > Xl does not do that it TRIES to, but just crashes the guest: > kernel BUG at drivers/xen/events.c:1466! > (In this example the target host didnt have the logical volume activated.) > > Now that cant be right. No, it's a bug, perhaps in the kernel but likely in the toolstack. Please can you provide full logs from /var/log/xen on both ends. Running "xl -vvv migrate" will also produce more stuff on stdout, some of which may be useful. Also please capture the complete guest log in case it is an issue there. > Imho xl should do some checking if the target is a viable migration > target (are the disks and vifs there, is there enough memory available) > and preserve a safe state on the sender until the guest has properly > started on the receiver. xl does have some checks and does preserve the sender side until it gets confirmation of correct restart, but obviously something is wrong with the bit which restarts the old guest. I'm sure it worked at one point though. Thanks, Ian. _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel From xen-devel-bounces@lists.xensource.com Tue Sep 20 14:28:58 2011 Return-path: <xen-devel-bounces@lists.xensource.com> Envelope-to: www-data@lists.xensource.com Delivery-date: Tue, 20 Sep 2011 14:28:58 -0700 Received: from localhost ([127.0.0.1] helo=lists.colo.xensource.com) by lists.xensource.com with esmtp (Exim 4.43) id 1R67sA-0004sM-32; Tue, 20 Sep 2011 14:28:58 -0700 Received: from mail182.messagelabs.com ([85.158.139.83]) by lists.xensource.com with esmtp (Exim 4.43) id 1R67rH-0004fs-B9; Tue, 20 Sep 2011 14:28:13 -0700 X-Env-Sender: hwang.jinho@gmail.com X-Msg-Ref: server-3.tower-182.messagelabs.com!1316554078!16315027!1 X-Originating-IP: [209.85.161.171] X-StarScan-Version: 6.4.1; banners=-,-,- X-VirusChecked: Checked Received: (qmail 16390 invoked from network); 20 Sep 2011 21:28:00 -0000 Received: from mail-gx0-f171.google.com (HELO mail-gx0-f171.google.com) (209.85.161.171) by server-3.tower-182.messagelabs.com with RC4-SHA encrypted SMTP; 20 Sep 2011 21:28:00 -0000 Received: by gxk27 with SMTP id 27so271038gxk.30 for <multiple recipients>; Tue, 20 Sep 2011 14:27:58 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:from:date:message-id:subject:to:content-type; bh=KrCt9+Y8yMRmo1Ibojf3lHEdyUVonv5q7fnZEFcl5KU=; b=PGHI00qB3Mp6W0UwfpBai996YFtAptXiaei261IDDpSgkkobYjFb6d5E5qbFAY2sq2 674vzSyGI887u79iJcDR5bZ5HZn6eKxCphUiwnwYn3ZfP6F6+TmM2KaRdFNPnNgflOq/ dfAAJm3TW+pnsprXq7WsaqWEs+j3YC8AswfDM= Received: by 10.150.61.2 with SMTP id j2mr166947yba.66.1316554078110; Tue, 20 Sep 2011 14:27:58 -0700 (PDT) MIME-Version: 1.0 Received: by 10.151.154.16 with HTTP; Tue, 20 Sep 2011 14:27:38 -0700 (PDT) From: jinho hwang <hwang.jinho@gmail.com> Date: Tue, 20 Sep 2011 17:27:38 -0400 Message-ID: <CAPQGAnFCgAn8h-wmcM-syJEP-g0fOr739HkwvF1RqRXZ=hzF+Q@mail.gmail.com> To: xen-devel@lists.xensource.com, xen-users@lists.xensource.com Cc: Subject: [Xen-devel] [Xen-users] kernel panic in domU X-BeenThere: xen-devel@lists.xensource.com X-Mailman-Version: 2.1.5 Precedence: list List-Id: Xen developer discussion <xen-devel.lists.xensource.com> List-Unsubscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe> List-Post: <mailto:xen-devel@lists.xensource.com> List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help> List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=subscribe> Content-Type: multipart/mixed; boundary="===============1330270665==" Sender: xen-devel-bounces@lists.xensource.com Errors-To: xen-devel-bounces@lists.xensource.com --===============1330270665== Content-Type: multipart/alternative; boundary=000e0cd4c4502742c504ad66223a --000e0cd4c4502742c504ad66223a Content-Type: text/plain; charset=ISO-8859-1 Hi All, I'm using xen 4.0.1, kernel 2.6.32.45 for DomU, kernel 2.6.32.46 for Dom0. I also use pygrub to boot the domU kernel in the xen. I tried all the things I know for making this work, but unfortunately it does not work at this moment. The kernel shows panic message and then escapes. The following is thetrace.. it tells me that the hypercall_page might trigger the xen_panic_event and then kernel got it to make itself panic. ----------------------------------------------------------------------------- cs:eip: 0061:c04023a7 hypercall_page+0x3a7 flags: 00001286 i s nz p ss:esp: 0069:dfc1ff14 eax: 00000000 ebx: 00000002 ecx: dfc1ff18 edx: 00000000 esi: 00000000 edi: 00000000 ebp: dfc1ff28 ds: 007b es: 007b fs: 00d8 gs: 0000 Code (instr addr c04023a7) cc cc cc cc cc cc cc cc cc cc cc cc cc cc b8 1d 00 00 00 cd 82 <c3> cc cc cc cc cc cc cc cc cc cc Stack: c04036f2 00000003 c086ecc8 00000000 00000000 dfc1ff44 c06f7e45 c092b99c c0874c24 dfc22cc0 c087379c dfc22cc0 dfc1ff54 c06f7e89 ffffffff 00000000 dfc1ff70 c06f3e55 c07da467 c092b99c dfc1ff7c dfc22cc0 c087379c dfc1ffa4 c043eba9 c07da8ae c0406fab c040b33b dfc10000 00000000 00000001 dfc1ff90 Call Trace: [<c04023a7>] hypercall_page+0x3a7 <-- [<c04036f2>] xen_panic_event+0x1d [<c06f7e45>] notifier_call_chain+0x26 [<c06f7e89>] atomic_notifier_call_chain+0xf [<c06f3e55>] panic+0x59 [<c043eba9>] do_exit+0x5c [<c0406fab>] xen_restore_fl_direct_reloc+0x4 [<c040b33b>] do_softirq+0xd5 [<c043f1f1>] sys_exit+0x13 [<c0409389>] syscall_call+0x7 ----------------------------------------------------------------------------- I also include some logs from console. ------------------------------------------------------------------------------- cpuidle: using governor ladder cpuidle: using governor menu usbcore: registered new interface driver hiddev usbcore: registered new interface driver usbhid usbhid: v2.6:USB HID core driver nf_conntrack version 0.5.0 (7992 buckets, 31968 max) CONFIG_NF_CT_ACCT is deprecated and will be removed soon. Please use nf_conntrack.acct=1 kernel parameter, acct=1 nf_conntrack module option or sysctl net.netfilter.nf_conntrack_acct=1 to enable it. ip_tables: (C) 2000-2006 Netfilter Core Team TCP cubic registered Initializing XFRM netlink socket NET: Registered protocol family 17 Bridge firewalling registered Using IPI No-Shortcut mode registered taskstats version 1 XENBUS: Device with no driver: device/vbd/51714 XENBUS: Device with no driver: device/vbd/51713 XENBUS: Device with no driver: device/console/0 Magic number: 1:252:3141 Freeing unused kernel memory: 464k freed Write protecting the kernel text: 3048k Write protecting the kernel read-only data: 1464k Loading, please wait... <30>udev[493]: starting version 167 Begin: Loading essential drivers ... JINHO: 1. xlblk_init called JINHO: 2. xlblk_init called JINHO: 3. xlblk_init called blkfront: xvda2: barriers enabled (tag) Setting capacity to 8388608 blkfront: xvda1: barriers enabled (tag) Setting capacity to 2097152 xvda1: detected capacity change from 0 to 1073741824 done. Begin: Running /scripts/init-premount ... done. Begin: Mounting root file system ... Begin: Running /scripts/local-top ... done. Begin: Running /scripts/local-premount ... done. kjournald starting. Commit interval 5 seconds EXT3-fs: mounted filesystem with writeback data mode. Begin: Running /scripts/local-bottom ... done. done. Begin: Running /scripts/init-bottom ... done. run-init: /sbin/init: No such file or directory Kernel panic - not syncing: Attempted to kill init! Pid: 1, comm: run-init Not tainted 2.6.32.45 #1 Call Trace: [<c06f3efc>] ? printk+0xf/0x13 [<c06f3e35>] panic+0x39/0xf1 [<c043eba9>] do_exit+0x5c/0x5cf [<c0406fab>] ? xen_restore_fl_direct_end+0x0/0x1 [<c040b33b>] ? do_softirq+0xd5/0xde [<c043f1f1>] complete_and_exit+0x0/0x17 [<c0409389>] syscall_call+0x7/0xb ------------------------------------------------------------------ Please help me to solve this problem. I have spent one week with this problem. Thank you, Jinho -- Jinho Hwang PhD Student Department of Computer Science The George Washington University Washington, DC 20052 hwang.jinho@gmail.com (email) 276.336.0971 (Cell) 202.994.4875 (fax) 070.8285.6546 (myLg070) --000e0cd4c4502742c504ad66223a Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable <br>Hi All, <br><br>I'm using xen 4.0.1, kernel 2.6.32.45 for DomU, ker= nel 2.6.32.46 for Dom0. I also use pygrub to boot the domU kernel in the xe= n. I tried all the things I know for making this work, but unfortunately it= does not work at this moment. <br> The kernel shows panic message and then escapes. The following is thetrace.= . it tells me that the hypercall_page might trigger the xen_panic_event and= then kernel got it to make itself panic. <br><br>-------------------------= ----------------------------------------------------<br> cs:eip: 0061:c04023a7 hypercall_page+0x3a7 <br>flags: 00001286 i s nz p<br>= ss:esp: 0069:dfc1ff14<br>eax: 00000000=A0=A0=A0 ebx: 00000002=A0=A0=A0 ecx:= dfc1ff18=A0=A0=A0 edx: 00000000<br>esi: 00000000=A0=A0=A0 edi: 00000000=A0= =A0=A0 ebp: dfc1ff28<br>=A0ds:=A0=A0=A0=A0 007b=A0=A0=A0 =A0es:=A0=A0=A0=A0= 007b=A0=A0=A0 =A0fs:=A0=A0=A0=A0 00d8=A0=A0=A0 =A0gs:=A0=A0=A0=A0 0000<br> Code (instr addr c04023a7)<br>cc cc cc cc cc cc cc cc cc cc cc cc cc cc b8 = 1d 00 00 00 cd 82 <c3> cc cc cc cc cc cc cc cc cc cc <br><br><br>Stac= k:<br>=A0c04036f2 00000003 c086ecc8 00000000 00000000 dfc1ff44 c06f7e45 c09= 2b99c<br> =A0c0874c24 dfc22cc0 c087379c dfc22cc0 dfc1ff54 c06f7e89 ffffffff 00000000<= br>=A0dfc1ff70 c06f3e55 c07da467 c092b99c dfc1ff7c dfc22cc0 c087379c dfc1ff= a4<br>=A0c043eba9 c07da8ae c0406fab c040b33b dfc10000 00000000 00000001 dfc= 1ff90<br> <br>Call Trace:<br>=A0 [<c04023a7>] hypercall_page+0x3a7=A0 <--<br= >=A0 [<c04036f2>] xen_panic_event+0x1d <br>=A0 [<c06f7e45>] not= ifier_call_chain+0x26 <br>=A0 [<c06f7e89>] atomic_notifier_call_chain= +0xf <br> =A0 [<c06f3e55>] panic+0x59 <br>=A0 [<c043eba9>] do_exit+0x5c <= br>=A0 [<c0406fab>] xen_restore_fl_direct_reloc+0x4 <br>=A0 [<c040= b33b>] do_softirq+0xd5 <br>=A0 [<c043f1f1>] sys_exit+0x13 <br>=A0 = [<c0409389>] syscall_call+0x7 <br> ---------------------------------------------------------------------------= --<br><br>I also include some logs from console. <br><br>------------------= -------------------------------------------------------------<br>cpuidle: u= sing governor ladder<br> cpuidle: using governor menu<br>usbcore: registered new interface driver hi= ddev<br>usbcore: registered new interface driver usbhid<br>usbhid: v2.6:USB= HID core driver<br>nf_conntrack version 0.5.0 (7992 buckets, 31968 max)<br= > CONFIG_NF_CT_ACCT is deprecated and will be removed soon. Please use<br>nf_= conntrack.acct=3D1 kernel parameter, acct=3D1 nf_conntrack module option or= <br>sysctl net.netfilter.nf_conntrack_acct=3D1 to enable it.<br>ip_tables: = (C) 2000-2006 Netfilter Core Team<br> TCP cubic registered<br>Initializing XFRM netlink socket<br>NET: Registered= protocol family 17<br>Bridge firewalling registered<br>Using IPI No-Shortc= ut mode<br>registered taskstats version 1<br>XENBUS: Device with no driver:= device/vbd/51714<br> XENBUS: Device with no driver: device/vbd/51713<br>XENBUS: Device with no d= river: device/console/0<br>=A0 Magic number: 1:252:3141<br>Freeing unused k= ernel memory: 464k freed<br>Write protecting the kernel text: 3048k<br>Writ= e protecting the kernel read-only data: 1464k<br> Loading, please wait...<br><30>udev[493]: starting version 167<br>Beg= in: Loading essential drivers ... JINHO: 1. xlblk_init called<br>JINHO: 2. = xlblk_init called<br>JINHO: 3. xlblk_init called<br>blkfront: xvda2: barrie= rs enabled (tag)<br> Setting capacity to 8388608<br>blkfront: xvda1: barriers enabled (tag)<br>S= etting capacity to 2097152<br>xvda1: detected capacity change from 0 to 107= 3741824<br>done.<br>Begin: Running /scripts/init-premount ... done.<br> Begin: Mounting root file system ... Begin: Running /scripts/local-top ... = done.<br>Begin: Running /scripts/local-premount ... done.<br>kjournald star= ting.=A0 Commit interval 5 seconds<br>EXT3-fs: mounted filesystem with writ= eback data mode.<br> Begin: Running /scripts/local-bottom ... done.<br>done.<br>Begin: Running /= scripts/init-bottom ... done.<br>run-init: /sbin/init: No such file or dire= ctory<br>Kernel panic - not syncing: Attempted to kill init!<br>Pid: 1, com= m: run-init Not tainted 2.6.32.45 #1<br> Call Trace:<br>=A0[<c06f3efc>] ? printk+0xf/0x13<br>=A0[<c06f3e35&= gt;] panic+0x39/0xf1<br>=A0[<c043eba9>] do_exit+0x5c/0x5cf<br>=A0[<= ;c0406fab>] ? xen_restore_fl_direct_end+0x0/0x1<br>=A0[<c040b33b>]= ? do_softirq+0xd5/0xde<br> =A0[<c043f1f1>] complete_and_exit+0x0/0x17<br>=A0[<c0409389>] s= yscall_call+0x7/0xb<br>----------------------------------------------------= --------------<br><br>Please help me to solve this problem. I have spent on= e week with this problem. <br> <br>Thank you,<br><br>Jinho<br><br clear=3D"all"><br>-- <br>Jinho Hwang<br>= PhD Student<br>Department of Computer Science<br>The George Washington Univ= ersity<br>Washington, DC 20052<br><a href=3D"mailto:hwang.jinho@gmail.com">= hwang.jinho@gmail.com</a> (email)<br> 276.336.0971 (Cell)<br>202.994.4875 (fax)<br>070.8285.6546 (myLg070)<br> --000e0cd4c4502742c504ad66223a-- --===============1330270665== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel --===============1330270665==-- From xen-devel-bounces@lists.xensource.com Tue Sep 20 17:08:55 2011 Return-path: <xen-devel-bounces@lists.xensource.com> Envelope-to: www-data@lists.xensource.com Delivery-date: Tue, 20 Sep 2011 17:08:55 -0700 Received: from localhost ([127.0.0.1] helo=lists.colo.xensource.com) by lists.xensource.com with esmtp (Exim 4.43) id 1R6AMv-0001ja-SE; Tue, 20 Sep 2011 17:08:53 -0700 Received: from mail216.messagelabs.com ([85.158.143.99]) by lists.xensource.com with smtp (Exim 4.43) id 1R6ALn-0001Wz-9P for xen-devel@lists.xensource.com; Tue, 20 Sep 2011 17:07:57 -0700 X-Env-Sender: allen.m.kay@intel.com X-Msg-Ref: server-11.tower-216.messagelabs.com!1316563659!11434251!1 X-Originating-IP: [134.134.136.24] X-StarScan-Version: 6.4.1; banners=-,-,- X-VirusChecked: Checked Received: (qmail 12346 invoked from network); 21 Sep 2011 00:07:40 -0000 Received: from mga09.intel.com (HELO mga09.intel.com) (134.134.136.24) by server-11.tower-216.messagelabs.com with SMTP; 21 Sep 2011 00:07:40 -0000 Received: from orsmga002.jf.intel.com ([10.7.209.21]) by orsmga102.jf.intel.com with ESMTP; 20 Sep 2011 17:07:39 -0700 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="4.67,351,1309762800"; d="scan'208";a="50899649" Received: from orsmsx603.amr.corp.intel.com ([10.22.226.49]) by orsmga002.jf.intel.com with ESMTP; 20 Sep 2011 17:07:39 -0700 Received: from orsmsx505.amr.corp.intel.com ([10.22.226.208]) by orsmsx603.amr.corp.intel.com ([10.22.226.49]) with mapi; Tue, 20 Sep 2011 17:07:39 -0700 From: "Kay, Allen M" <allen.m.kay@intel.com> To: Jan Beulich <JBeulich@novell.com>, Tim Deegan <tim@xen.org> Date: Tue, 20 Sep 2011 17:07:37 -0700 Subject: RE: [Xen-devel] Xen Advisory 5 (CVE-2011-3131) IOMMU fault livelock Thread-Topic: [Xen-devel] Xen Advisory 5 (CVE-2011-3131) IOMMU fault livelock Thread-Index: AcxcLgH/N/5li+NgSJ6W00vLiYTH6wbwmbVA Message-ID: <987664A83D2D224EAE907B061CE93D5301EDED333E@orsmsx505.amr.corp.intel.com> References: <20037.10841.995717.397090@mariner.uk.xensource.com> <4E454C880200007800051000@nat28.tlf.novell.com> <20110812140901.GC11708@ocelot.phlegethon.org> <4E4559440200007800051062@nat28.tlf.novell.com> <20110815092608.GD11708@ocelot.phlegethon.org> <4E4A32650200007800051651@nat28.tlf.novell.com> <20110816150621.GM11708@ocelot.phlegethon.org> <4E4AAFF402000078000518CF@nat28.tlf.novell.com> In-Reply-To: <4E4AAFF402000078000518CF@nat28.tlf.novell.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>, "Dugger, Donald D" <donald.d.dugger@intel.com>, Xen.org, security team <security@xen.org> X-BeenThere: xen-devel@lists.xensource.com X-Mailman-Version: 2.1.5 Precedence: list List-Id: Xen developer discussion <xen-devel.lists.xensource.com> List-Unsubscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe> List-Post: <mailto:xen-devel@lists.xensource.com> List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help> List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=subscribe> Sender: xen-devel-bounces@lists.xensource.com Errors-To: xen-devel-bounces@lists.xensource.com Catching up on an old thread ... If I understand correctly, the proposal is to check for VT-d faults in do_s= oftirq() handler. If so, we probably don't even need to enable VT-d MSI in= terrupt at all if iommu_debug is not set, basically handling VT-d faults wi= th polling method. This sounds fine to me as long as we still turn on VT-d MSI interrupt for i= ommu_debug case. Allen -----Original Message----- From: xen-devel-bounces@lists.xensource.com [mailto:xen-devel-bounces@lists= .xensource.com] On Behalf Of Jan Beulich Sent: Tuesday, August 16, 2011 8:59 AM To: Tim Deegan Cc: xen-devel@lists.xensource.com; Xen.org security team Subject: Re: [Xen-devel] Xen Advisory 5 (CVE-2011-3131) IOMMU fault liveloc= k >>> On 16.08.11 at 17:06, Tim Deegan <tim@xen.org> wrote: > At 08:03 +0100 on 16 Aug (1313481813), Jan Beulich wrote: >> >>> On 15.08.11 at 11:26, Tim Deegan <tim@xen.org> wrote: >> > At 15:48 +0100 on 12 Aug (1313164084), Jan Beulich wrote: >> >> >>> On 12.08.11 at 16:09, Tim Deegan <tim@xen.org> wrote: >> >> > At 14:53 +0100 on 12 Aug (1313160824), Jan Beulich wrote: >> >> >> > This issue is resolved in changeset 23762:537ed3b74b3f of >> >> >> > xen-unstable.hg, and 23112:84e3706df07a of xen-4.1-testing.hg. >> >> >>=20 >> >> >> Do you really think this helps much? Direct control of the device = means >> >> >> it could also (perhaps on a second vCPU) constantly re-enable the = bus >> >> >> mastering bit.=20 >> >> >=20 >> >> > That path goes through qemu/pciback, so at least lets Xen schedule = the >> >> > dom0 tools. >> >>=20 >> >> Are you sure? If (as said) the guest uses a second vCPU for doing the >> >> config space accesses, I can't see how this would save the pCPU the >> >> fault storm is occurring on. >> >=20 >> > Hmmm. Yes, I see what you mean. >>=20 >> Actually, a second vCPU may not even be needed: Since the "fault" >> really is an external interrupt, if that one gets handled on a pCPU othe= r >> than the one the guest's vCPU is running on, it could execute such a >> loop even in that case. >>=20 >> As to yesterdays softirq-based handling thoughts - perhaps the clearing >> of the bus master bit on the device should still be done in the actual I= RQ >> handler, while the processing of the fault records could be moved out to >> a softirq. >=20 > Hmmm. I like the idea of using a softirq but in fact by the time we've > figured out which BDF to silence we've pretty much done handling the > fault. Ugly, but yes, indeed. > Reading the VTd docs it looks like we can just ack the IOMMU fault > interrupt and it won't send any more until we clear the log, so we can > leave the whole business to a softirq. Delaying that might cause the > log to overflow, but that's not necessarily the end of the world. > Looks like we can do the same on AMD by disabling interrupt generation > in the main handler and reenabling it in the softirq. >=20 > Is there any situation where we rally care terribly about the IOfault > logs overflowing? As long as older entries don't get overwritten, I don't think that's going to be problematic. The more that we basically shut off the offending device(s). Jan _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel From xen-devel-bounces@lists.xensource.com Tue Sep 20 18:30:09 2011 Return-path: <xen-devel-bounces@lists.xensource.com> Envelope-to: www-data@lists.xensource.com Delivery-date: Tue, 20 Sep 2011 18:30:09 -0700 Received: from localhost ([127.0.0.1] helo=lists.colo.xensource.com) by lists.xensource.com with esmtp (Exim 4.43) id 1R6BdZ-0003Ux-LV; Tue, 20 Sep 2011 18:30:09 -0700 Received: from mail27.messagelabs.com ([193.109.254.147]) by lists.xensource.com with esmtp (Exim 4.43) id 1R6BcF-0003Ht-5Y for xen-devel@lists.xensource.com; Tue, 20 Sep 2011 18:28:49 -0700 X-Env-Sender: jeremy@goop.org X-Msg-Ref: server-3.tower-27.messagelabs.com!1316568499!40483291!1 X-Originating-IP: [74.207.240.146] X-StarScan-Version: 6.4.1; banners=-,-,- X-VirusChecked: Checked Received: (qmail 23917 invoked from network); 21 Sep 2011 01:28:21 -0000 Received: from claw.goop.org (HELO claw.goop.org) (74.207.240.146) by server-3.tower-27.messagelabs.com with DHE-RSA-AES256-SHA encrypted SMTP; 21 Sep 2011 01:28:21 -0000 Received: from saboo.goop.org (unknown [IPv6:2001:470:1f05:899:f2de:f1ff:fe5c:34ed]) (Authenticated sender: smtp-saboo) by claw.goop.org (Postfix) with ESMTPSA id 3DA22946C; Tue, 20 Sep 2011 18:28:41 -0700 (PDT) Received: from saboo.goop.org (localhost [IPv6:::1]) by saboo.goop.org (Postfix) with ESMTP id E307D20C4A; Tue, 20 Sep 2011 18:28:36 -0700 (PDT) Message-ID: <4E793DC4.7080808@goop.org> Date: Tue, 20 Sep 2011 18:28:36 -0700 From: Jeremy Fitzhardinge <jeremy@goop.org> User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:6.0.2) Gecko/20110906 Thunderbird/6.0.2 MIME-Version: 1.0 To: Daniel Castro <evil.dani@gmail.com> Subject: Re: [Xen-devel] Sched_op hypercall small questions References: <CAP2B85_rPbB=hZpKJYSPgC59jU=YG6deD4ZkWMmXwtMV4un1mg@mail.gmail.com> <CA9D757C.2119E%keir.xen@gmail.com> <CAP2B85-e64NKts_iC21Bh0OL3X3nUh4jLriYfE2+stHkPfMFWg@mail.gmail.com> In-Reply-To: <CAP2B85-e64NKts_iC21Bh0OL3X3nUh4jLriYfE2+stHkPfMFWg@mail.gmail.com> X-Enigmail-Version: 1.3.1 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: Keir Fraser <keir.xen@gmail.com>, xen-devel@lists.xensource.com X-BeenThere: xen-devel@lists.xensource.com X-Mailman-Version: 2.1.5 Precedence: list List-Id: Xen developer discussion <xen-devel.lists.xensource.com> List-Unsubscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe> List-Post: <mailto:xen-devel@lists.xensource.com> List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help> List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=subscribe> Sender: xen-devel-bounces@lists.xensource.com Errors-To: xen-devel-bounces@lists.xensource.com On 09/19/2011 11:17 PM, Daniel Castro wrote: > On Tue, Sep 20, 2011 at 2:41 PM, Keir Fraser <keir.xen@gmail.com> wrote: >> On 19/09/2011 22:21, "Daniel Castro" <evil.dani@gmail.com> wrote: >> >>> Greetings all. >>> >>> Some small question regarding schedule poll operation hypercall. >>> >>> 1. struct sched_poll poll.timeout is measured in what unit of time? >>> Secs, ms? ns? >> It is an absolute system time (rather than a duration), in nanoseconds. > really an absolute system time? > > When the timeout is set and the timeout is reached, the system behaves > like if the event had been received? i.e the bit is changed? You specify the timeout in the the form "wake up by time t". If t is in the past, it times out immediately. >>> 2. After issuing the hypercall_sched_op(SCHEDOP_poll, &poll); if no >>> timeout is used in poll struct how long will I yield the CPU? >> Until one of the specified event channel ports is pending. > If the channel port never changes (the event never arrives) then I > would yield for ever? If you have events unmasked and you get an unmasked event, then it will go into the event handler. >>> 3. If I issue the hypercall and the event never comes is it possible >>> to to yield the CPU for ever? >> Yes, if you do not specify a timeout. > Keir thanks for the answer. > > I am trying to read from xenstore, so I have the following: > I write on my xenstore ring the query I want, then, > hypercall_event_channel_op(EVTCHNOP_send ... > If I read the ring inmediatly the answer is not ready so I issue a > hypercall_sched_op(SCHEDOP_poll, &poll); > But while I am entering the yield state the answer comes, so the event > is never seen because it has already been delivered. It generally only makes sense to poll on masked events. > > If I use some way to wait (just for very brief instant) after the > event_channel_op send then, when I check the ring the answer is there; > And I do not need to yield the CPU. > > Should I issue the wait after the send, rather than when I am about to > read the answer? What environment is this in? J _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel From xen-devel-bounces@lists.xensource.com Tue Sep 20 18:36:03 2011 Return-path: <xen-devel-bounces@lists.xensource.com> Envelope-to: www-data@lists.xensource.com Delivery-date: Tue, 20 Sep 2011 18:36:03 -0700 Received: from localhost ([127.0.0.1] helo=lists.colo.xensource.com) by lists.xensource.com with esmtp (Exim 4.43) id 1R6BjH-00045g-5V; Tue, 20 Sep 2011 18:36:03 -0700 Received: from mail216.messagelabs.com ([85.158.143.99]) by lists.xensource.com with esmtp (Exim 4.43) id 1R6BiM-0003tp-Kj for xen-devel@lists.xensource.com; Tue, 20 Sep 2011 18:35:07 -0700 X-Env-Sender: jeremy@goop.org X-Msg-Ref: server-9.tower-216.messagelabs.com!1316568901!19026061!1 X-Originating-IP: [74.207.240.146] X-StarScan-Version: 6.4.1; banners=-,-,- X-VirusChecked: Checked Received: (qmail 15771 invoked from network); 21 Sep 2011 01:35:03 -0000 Received: from claw.goop.org (HELO claw.goop.org) (74.207.240.146) by server-9.tower-216.messagelabs.com with DHE-RSA-AES256-SHA encrypted SMTP; 21 Sep 2011 01:35:03 -0000 Received: from saboo.goop.org (unknown [IPv6:2001:470:1f05:899:f2de:f1ff:fe5c:34ed]) (Authenticated sender: smtp-saboo) by claw.goop.org (Postfix) with ESMTPSA id 552029482; Tue, 20 Sep 2011 18:35:01 -0700 (PDT) Received: from saboo.goop.org (localhost [IPv6:::1]) by saboo.goop.org (Postfix) with ESMTP id 31D3720478; Tue, 20 Sep 2011 18:34:58 -0700 (PDT) Message-ID: <4E793F42.7070803@goop.org> Date: Tue, 20 Sep 2011 18:34:58 -0700 From: Jeremy Fitzhardinge <jeremy@goop.org> User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:6.0.2) Gecko/20110906 Thunderbird/6.0.2 MIME-Version: 1.0 To: Ian Campbell <Ian.Campbell@citrix.com> Subject: Re: [Xen-devel] xl create crash when using stub domains References: <4E729960.2080101@goop.org> In-Reply-To: <4E729960.2080101@goop.org> X-Enigmail-Version: 1.3.1 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>, Ian Jackson <Ian.Jackson@eu.citrix.com>, Stefano Stabellini <stefano.stabellini@eu.citrix.com> X-BeenThere: xen-devel@lists.xensource.com X-Mailman-Version: 2.1.5 Precedence: list List-Id: Xen developer discussion <xen-devel.lists.xensource.com> List-Unsubscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe> List-Post: <mailto:xen-devel@lists.xensource.com> List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help> List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=subscribe> Sender: xen-devel-bounces@lists.xensource.com Errors-To: xen-devel-bounces@lists.xensource.com On 09/15/2011 05:33 PM, Jeremy Fitzhardinge wrote: > When I create an HVM domain with stubdom enabled, it crashes at: > > (gdb) run create -c /etc/xen/f14hv64 vcpus=4 xen_platform_pci=0 'boot="d"' > Starting program: /usr/sbin/xl create -c /etc/xen/f14hv64 vcpus=4 xen_platform_pci=0 'boot="d"' > [Thread debugging using libthread_db enabled] > Parsing config file /etc/xen/f14hv64 > xc: info: VIRTUAL MEMORY ARRANGEMENT: > Loader: 0000000000100000->000000000017b9ec > TOTAL: 0000000000000000->000000003f800000 > ENTRY ADDRESS: 0000000000100000 > xc: info: PHYSICAL MEMORY ALLOCATION: > 4KB PAGES: 0x0000000000000200 > 2MB PAGES: 0x00000000000001fb > 1GB PAGES: 0x0000000000000000 > xc: error: panic: xc_dom_bzimageloader.c:588: xc_dom_probe_bzimage_kernel: kernel is not a bzImage: Invalid kernel > Detaching after fork from child process 26888. > [New Thread 0x7ffff7342700 (LWP 26889)] > [Thread 0x7ffff7342700 (LWP 26889) exited] > [New Thread 0x7ffff7342700 (LWP 26921)] > > Program received signal SIGSEGV, Segmentation fault. > 0x00007ffff7bbbec5 in libxl__wait_for_device_model (gc=0x7fffffffdbb0, > domid=22, state=0x7ffff7bc1b8c "running", starting=0x623760, > check_callback=0, check_callback_userdata=0x0) at libxl_device.c:555 > 555 if (starting && starting->for_spawn->fd > xs_fileno(xsh)) > (gdb) bt This patch seems to fix it, but I don't know if it is a real fix or just papering over something else. J diff -r 7779e12cc99e tools/libxl/libxl_device.c --- a/tools/libxl/libxl_device.c Tue Aug 16 17:05:18 2011 -0700 +++ b/tools/libxl/libxl_device.c Tue Sep 20 18:23:03 2011 -0700 @@ -552,7 +552,7 @@ tv.tv_sec = LIBXL_DEVICE_MODEL_START_TIMEOUT; tv.tv_usec = 0; nfds = xs_fileno(xsh) + 1; - if (starting && starting->for_spawn->fd > xs_fileno(xsh)) + if (starting && starting->for_spawn && starting->for_spawn->fd > xs_fileno(xsh)) nfds = starting->for_spawn->fd + 1; while (rc > 0 || (!rc && tv.tv_sec > 0)) { @@ -586,7 +586,7 @@ free(p); FD_ZERO(&rfds); FD_SET(xs_fileno(xsh), &rfds); - if (starting) + if (starting && starting->for_spawn) FD_SET(starting->for_spawn->fd, &rfds); rc = select(nfds, &rfds, NULL, NULL, &tv); if (rc > 0) { @@ -597,7 +597,7 @@ else goto again; } - if (starting && FD_ISSET(starting->for_spawn->fd, &rfds)) { + if (starting && starting->for_spawn && FD_ISSET(starting->for_spawn->fd, &rfds)) { unsigned char dummy; if (read(starting->for_spawn->fd, &dummy, sizeof(dummy)) != 1) LIBXL__LOG_ERRNO(ctx, LIBXL__LOG_DEBUG, _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel From xen-devel-bounces@lists.xensource.com Tue Sep 20 18:38:10 2011 Return-path: <xen-devel-bounces@lists.xensource.com> Envelope-to: www-data@lists.xensource.com Delivery-date: Tue, 20 Sep 2011 18:38:10 -0700 Received: from localhost ([127.0.0.1] helo=lists.colo.xensource.com) by lists.xensource.com with esmtp (Exim 4.43) id 1R6BlK-0004a5-FQ; Tue, 20 Sep 2011 18:38:10 -0700 Received: from mail174.messagelabs.com ([85.158.138.51]) by lists.xensource.com with esmtp (Exim 4.43) id 1R6Bjq-0004H2-7l; Tue, 20 Sep 2011 18:36:39 -0700 X-Env-Sender: jeremy@goop.org X-Msg-Ref: server-8.tower-174.messagelabs.com!1316568777!18487514!1 X-Originating-IP: [74.207.240.146] X-StarScan-Version: 6.4.1; banners=-,-,- X-VirusChecked: Checked Received: (qmail 6313 invoked from network); 21 Sep 2011 01:32:59 -0000 Received: from claw.goop.org (HELO claw.goop.org) (74.207.240.146) by server-8.tower-174.messagelabs.com with DHE-RSA-AES256-SHA encrypted SMTP; 21 Sep 2011 01:32:59 -0000 Received: from saboo.goop.org (unknown [IPv6:2001:470:1f05:899:f2de:f1ff:fe5c:34ed]) (Authenticated sender: smtp-saboo) by claw.goop.org (Postfix) with ESMTPSA id 2E1339480; Tue, 20 Sep 2011 18:32:57 -0700 (PDT) Received: from saboo.goop.org (localhost [IPv6:::1]) by saboo.goop.org (Postfix) with ESMTP id D80CF20C4A; Tue, 20 Sep 2011 18:32:53 -0700 (PDT) Message-ID: <4E793EC5.20209@goop.org> Date: Tue, 20 Sep 2011 18:32:53 -0700 From: Jeremy Fitzhardinge <jeremy@goop.org> User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:6.0.2) Gecko/20110906 Thunderbird/6.0.2 MIME-Version: 1.0 To: jinho hwang <hwang.jinho@gmail.com> Subject: Re: [Xen-devel] [Xen-users] kernel panic in domU References: <CAPQGAnFCgAn8h-wmcM-syJEP-g0fOr739HkwvF1RqRXZ=hzF+Q@mail.gmail.com> In-Reply-To: <CAPQGAnFCgAn8h-wmcM-syJEP-g0fOr739HkwvF1RqRXZ=hzF+Q@mail.gmail.com> X-Enigmail-Version: 1.3.1 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: xen-devel@lists.xensource.com, xen-users@lists.xensource.com X-BeenThere: xen-devel@lists.xensource.com X-Mailman-Version: 2.1.5 Precedence: list List-Id: Xen developer discussion <xen-devel.lists.xensource.com> List-Unsubscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe> List-Post: <mailto:xen-devel@lists.xensource.com> List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help> List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=subscribe> Sender: xen-devel-bounces@lists.xensource.com Errors-To: xen-devel-bounces@lists.xensource.com On 09/20/2011 02:27 PM, jinho hwang wrote: > > Hi All, > > I'm using xen 4.0.1, kernel 2.6.32.45 for DomU, kernel 2.6.32.46 for > Dom0. I also use pygrub to boot the domU kernel in the xen. I tried > all the things I know for making this work, but unfortunately it does > not work at this moment. > The kernel shows panic message and then escapes. The following is > thetrace.. it tells me that the hypercall_page might trigger the > xen_panic_event and then kernel got it to make itself panic. > > ----------------------------------------------------------------------------- > cs:eip: 0061:c04023a7 hypercall_page+0x3a7 > flags: 00001286 i s nz p > ss:esp: 0069:dfc1ff14 > eax: 00000000 ebx: 00000002 ecx: dfc1ff18 edx: 00000000 > esi: 00000000 edi: 00000000 ebp: dfc1ff28 > ds: 007b es: 007b fs: 00d8 gs: 0000 > Code (instr addr c04023a7) > cc cc cc cc cc cc cc cc cc cc cc cc cc cc b8 1d 00 00 00 cd 82 <c3> cc > cc cc cc cc cc cc cc cc cc > > > Stack: > c04036f2 00000003 c086ecc8 00000000 00000000 dfc1ff44 c06f7e45 c092b99c > c0874c24 dfc22cc0 c087379c dfc22cc0 dfc1ff54 c06f7e89 ffffffff 00000000 > dfc1ff70 c06f3e55 c07da467 c092b99c dfc1ff7c dfc22cc0 c087379c dfc1ffa4 > c043eba9 c07da8ae c0406fab c040b33b dfc10000 00000000 00000001 dfc1ff90 > > Call Trace: > [<c04023a7>] hypercall_page+0x3a7 <-- > [<c04036f2>] xen_panic_event+0x1d > [<c06f7e45>] notifier_call_chain+0x26 > [<c06f7e89>] atomic_notifier_call_chain+0xf > [<c06f3e55>] panic+0x59 > [<c043eba9>] do_exit+0x5c > [<c0406fab>] xen_restore_fl_direct_reloc+0x4 > [<c040b33b>] do_softirq+0xd5 > [<c043f1f1>] sys_exit+0x13 > [<c0409389>] syscall_call+0x7 > ----------------------------------------------------------------------------- > > I also include some logs from console. > > ------------------------------------------------------------------------------- > cpuidle: using governor ladder > cpuidle: using governor menu > usbcore: registered new interface driver hiddev > usbcore: registered new interface driver usbhid > usbhid: v2.6:USB HID core driver > nf_conntrack version 0.5.0 (7992 buckets, 31968 max) > CONFIG_NF_CT_ACCT is deprecated and will be removed soon. Please use > nf_conntrack.acct=1 kernel parameter, acct=1 nf_conntrack module option or > sysctl net.netfilter.nf_conntrack_acct=1 to enable it. > ip_tables: (C) 2000-2006 Netfilter Core Team > TCP cubic registered > Initializing XFRM netlink socket > NET: Registered protocol family 17 > Bridge firewalling registered > Using IPI No-Shortcut mode > registered taskstats version 1 > XENBUS: Device with no driver: device/vbd/51714 > XENBUS: Device with no driver: device/vbd/51713 > XENBUS: Device with no driver: device/console/0 > Magic number: 1:252:3141 > Freeing unused kernel memory: 464k freed > Write protecting the kernel text: 3048k > Write protecting the kernel read-only data: 1464k > Loading, please wait... > <30>udev[493]: starting version 167 > Begin: Loading essential drivers ... JINHO: 1. xlblk_init called > JINHO: 2. xlblk_init called > JINHO: 3. xlblk_init called > blkfront: xvda2: barriers enabled (tag) > Setting capacity to 8388608 > blkfront: xvda1: barriers enabled (tag) > Setting capacity to 2097152 > xvda1: detected capacity change from 0 to 1073741824 > done. > Begin: Running /scripts/init-premount ... done. > Begin: Mounting root file system ... Begin: Running /scripts/local-top > ... done. > Begin: Running /scripts/local-premount ... done. > kjournald starting. Commit interval 5 seconds > EXT3-fs: mounted filesystem with writeback data mode. > Begin: Running /scripts/local-bottom ... done. > done. > Begin: Running /scripts/init-bottom ... done. > run-init: /sbin/init: No such file or directory > Kernel panic - not syncing: Attempted to kill init! > Pid: 1, comm: run-init Not tainted 2.6.32.45 #1 > Call Trace: > [<c06f3efc>] ? printk+0xf/0x13 > [<c06f3e35>] panic+0x39/0xf1 > [<c043eba9>] do_exit+0x5c/0x5cf > [<c0406fab>] ? xen_restore_fl_direct_end+0x0/0x1 > [<c040b33b>] ? do_softirq+0xd5/0xde > [<c043f1f1>] complete_and_exit+0x0/0x17 > [<c0409389>] syscall_call+0x7/0xb > ------------------------------------------------------------------ > > Please help me to solve this problem. I have spent one week with this > problem. It looks like there's something wrong with your filesystem configuration: it is missing an /sbin/init. When this fails to start, the kernel panics as it has no way to start up the usermode environment without it. J _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel From xen-devel-bounces@lists.xensource.com Tue Sep 20 18:52:51 2011 Return-path: <xen-devel-bounces@lists.xensource.com> Envelope-to: www-data@lists.xensource.com Delivery-date: Tue, 20 Sep 2011 18:52:51 -0700 Received: from localhost ([127.0.0.1] helo=lists.colo.xensource.com) by lists.xensource.com with esmtp (Exim 4.43) id 1R6BzX-0005sj-0p; Tue, 20 Sep 2011 18:52:51 -0700 Received: from mail182.messagelabs.com ([85.158.139.83]) by lists.xensource.com with esmtp (Exim 4.43) id 1R6ByR-0005g9-FL for xen-devel@lists.xensource.com; Tue, 20 Sep 2011 18:51:43 -0700 X-Env-Sender: Ian.Jackson@eu.citrix.com X-Msg-Ref: server-3.tower-182.messagelabs.com!1316569900!16324995!1 X-Originating-IP: [62.200.22.115] X-StarScan-Version: 6.4.1; banners=-,-,- X-VirusChecked: Checked Received: (qmail 11576 invoked from network); 21 Sep 2011 01:51:40 -0000 Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115) by server-3.tower-182.messagelabs.com with RC4-SHA encrypted SMTP; 21 Sep 2011 01:51:40 -0000 X-IronPort-AV: E=Sophos;i="4.68,414,1312156800"; d="scan'208";a="7965548" Received: from lonpmailmx01.citrite.net ([10.30.203.162]) by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5; 21 Sep 2011 01:51:40 +0000 Received: from woking.xci-test.com (10.80.248.135) by smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id 8.3.137.0; Wed, 21 Sep 2011 02:51:39 +0100 Received: from osstest by woking.xci-test.com with local (Exim 4.69) (envelope-from <ian.jackson@eu.citrix.com>) id 1R6ByN-00080L-Lf; Wed, 21 Sep 2011 02:51:39 +0100 To: <xen-devel@lists.xensource.com> Message-ID: <osstest-8986-mainreport@xen.org> From: xen.org <ian.jackson@eu.citrix.com> Date: Wed, 21 Sep 2011 02:51:39 +0100 MIME-Version: 1.0 Content-Type: text/plain Cc: ian.jackson@eu.citrix.com Subject: [Xen-devel] [xen-unstable test] 8986: tolerable FAIL X-BeenThere: xen-devel@lists.xensource.com X-Mailman-Version: 2.1.5 Precedence: list List-Id: Xen developer discussion <xen-devel.lists.xensource.com> List-Unsubscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe> List-Post: <mailto:xen-devel@lists.xensource.com> List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help> List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=subscribe> Sender: xen-devel-bounces@lists.xensource.com Errors-To: xen-devel-bounces@lists.xensource.com flight 8986 xen-unstable real [real] http://www.chiark.greenend.org.uk/~xensrcts/logs/8986/ Failures :-/ but no regressions. Tests which did not succeed, but are not blocking, including regressions (tests previously passed) regarded as allowable: test-amd64-amd64-xl-pcipt-intel 1 xen-build-check(1) blocked n/a test-amd64-amd64-xl 1 xen-build-check(1) blocked n/a test-amd64-i386-pair 1 xen-build-check(1) blocked n/a test-amd64-i386-xl-multivcpu 1 xen-build-check(1) blocked n/a test-amd64-i386-rhel6hvm-intel 1 xen-build-check(1) blocked n/a test-i386-i386-pv 1 xen-build-check(1) blocked n/a build-i386-pvops 4 kernel-build fail like 8975 test-amd64-i386-pv 1 xen-build-check(1) blocked n/a test-amd64-amd64-pv 1 xen-build-check(1) blocked n/a test-i386-i386-xl 1 xen-build-check(1) blocked n/a build-amd64-pvops 4 kernel-build fail like 8975 test-amd64-i386-xl 1 xen-build-check(1) blocked n/a test-amd64-i386-xl-credit2 1 xen-build-check(1) blocked n/a test-amd64-i386-rhel6hvm-amd 1 xen-build-check(1) blocked n/a test-amd64-amd64-pair 1 xen-build-check(1) blocked n/a test-i386-i386-pair 1 xen-build-check(1) blocked n/a test-amd64-amd64-win 1 xen-build-check(1) blocked n/a test-amd64-amd64-xl-win 1 xen-build-check(1) blocked n/a test-amd64-i386-win 1 xen-build-check(1) blocked n/a test-i386-i386-win 1 xen-build-check(1) blocked n/a test-amd64-amd64-xl-sedf 1 xen-build-check(1) blocked n/a test-amd64-i386-win-vcpus1 1 xen-build-check(1) blocked n/a test-amd64-i386-xl-win-vcpus1 1 xen-build-check(1) blocked n/a test-i386-i386-xl-win 1 xen-build-check(1) blocked n/a version targeted for testing: xen 994b5b125c31 baseline version: xen 994b5b125c31 jobs: build-amd64 pass build-i386 pass build-amd64-oldkern pass build-i386-oldkern pass build-amd64-pvops fail build-i386-pvops fail test-amd64-amd64-xl blocked test-amd64-i386-xl blocked test-i386-i386-xl blocked test-amd64-i386-rhel6hvm-amd blocked test-amd64-i386-xl-credit2 blocked test-amd64-amd64-xl-pcipt-intel blocked test-amd64-i386-rhel6hvm-intel blocked test-amd64-i386-xl-multivcpu blocked test-amd64-amd64-pair blocked test-amd64-i386-pair blocked test-i386-i386-pair blocked test-amd64-amd64-pv blocked test-amd64-i386-pv blocked test-i386-i386-pv blocked test-amd64-amd64-xl-sedf blocked test-amd64-i386-win-vcpus1 blocked test-amd64-i386-xl-win-vcpus1 blocked test-amd64-amd64-win blocked test-amd64-i386-win blocked test-i386-i386-win blocked test-amd64-amd64-xl-win blocked test-i386-i386-xl-win blocked ------------------------------------------------------------ sg-report-flight on woking.cam.xci-test.com logs: /home/xc_osstest/logs images: /home/xc_osstest/images Logs, config files, etc. are available at http://www.chiark.greenend.org.uk/~xensrcts/logs Test harness code can be found at http://xenbits.xensource.com/gitweb?p=osstest.git;a=summary Published tested tree is already up to date. _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel From xen-devel-bounces@lists.xensource.com Tue Sep 20 19:20:24 2011 Return-path: <xen-devel-bounces@lists.xensource.com> Envelope-to: www-data@lists.xensource.com Delivery-date: Tue, 20 Sep 2011 19:20:24 -0700 Received: from localhost ([127.0.0.1] helo=lists.colo.xensource.com) by lists.xensource.com with esmtp (Exim 4.43) id 1R6CQC-0006gx-AD; Tue, 20 Sep 2011 19:20:24 -0700 Received: from mail27.messagelabs.com ([193.109.254.147]) by lists.xensource.com with esmtp (Exim 4.43) id 1R6CPB-0006U4-QH; Tue, 20 Sep 2011 19:19:26 -0700 X-Env-Sender: hwang.jinho@gmail.com X-Msg-Ref: server-4.tower-27.messagelabs.com!1316571539!41094154!1 X-Originating-IP: [209.85.160.171] X-StarScan-Version: 6.4.1; banners=-,-,- X-VirusChecked: Checked Received: (qmail 1655 invoked from network); 21 Sep 2011 02:19:00 -0000 Received: from mail-gy0-f171.google.com (HELO mail-gy0-f171.google.com) (209.85.160.171) by server-4.tower-27.messagelabs.com with RC4-SHA encrypted SMTP; 21 Sep 2011 02:19:00 -0000 Received: by gyh3 with SMTP id 3so1363250gyh.30 for <multiple recipients>; Tue, 20 Sep 2011 19:19:17 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=V5N/QtHjmv+XEGkOeMgLSRGs0pAgiMbVAj1pdMdR4vE=; b=fcT4vLllXowvIj7jWxmPx3zBdYzMQBdtJxV3JaPKJ34aGr52l4y4f53VelQkcI7HJw NZCmS2TD0CJ1RjRKoM9QnSKPADwCaYYfG5gnLNnAMvKSrApUZZ+5RhszIb6bCoYiH1Bb rqdOHJEVTRCtxYrxnacZWIpvrlzHpeBjGfhSA= Received: by 10.150.176.21 with SMTP id y21mr341084ybe.123.1316571557104; Tue, 20 Sep 2011 19:19:17 -0700 (PDT) MIME-Version: 1.0 Received: by 10.151.154.16 with HTTP; Tue, 20 Sep 2011 19:18:57 -0700 (PDT) In-Reply-To: <4E793EC5.20209@goop.org> References: <CAPQGAnFCgAn8h-wmcM-syJEP-g0fOr739HkwvF1RqRXZ=hzF+Q@mail.gmail.com> <4E793EC5.20209@goop.org> From: jinho hwang <hwang.jinho@gmail.com> Date: Tue, 20 Sep 2011 22:18:57 -0400 Message-ID: <CAPQGAnGxTOUTb_9kQnevY99U5CiEcFTeGLtZUUvrRb2ETkg7iw@mail.gmail.com> Subject: Re: [Xen-devel] [Xen-users] kernel panic in domU To: Jeremy Fitzhardinge <jeremy@goop.org> Cc: xen-devel@lists.xensource.com, xen-users@lists.xensource.com X-BeenThere: xen-devel@lists.xensource.com X-Mailman-Version: 2.1.5 Precedence: list List-Id: Xen developer discussion <xen-devel.lists.xensource.com> List-Unsubscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe> List-Post: <mailto:xen-devel@lists.xensource.com> List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help> List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=subscribe> Content-Type: multipart/mixed; boundary="===============2132354085==" Sender: xen-devel-bounces@lists.xensource.com Errors-To: xen-devel-bounces@lists.xensource.com --===============2132354085== Content-Type: multipart/alternative; boundary=000e0cdf0d6cfb8e6e04ad6a33ed --000e0cdf0d6cfb8e6e04ad6a33ed Content-Type: text/plain; charset=ISO-8859-1 Thanks for replay. This is my fstab. Do I have to do something else for mounting? proc /proc proc defaults 0 0 devpts /dev/pts devpts rw,noexec,nosuid,gid=5,mode=620 0 0 /dev/xvda1 none swap sw 0 0 /dev/xvda2 / ext3 noatime,nodiratime,errors=remount-ro 0 1 Jinho On Tue, Sep 20, 2011 at 9:32 PM, Jeremy Fitzhardinge <jeremy@goop.org>wrote: > On 09/20/2011 02:27 PM, jinho hwang wrote: > > > > Hi All, > > > > I'm using xen 4.0.1, kernel 2.6.32.45 for DomU, kernel 2.6.32.46 for > > Dom0. I also use pygrub to boot the domU kernel in the xen. I tried > > all the things I know for making this work, but unfortunately it does > > not work at this moment. > > The kernel shows panic message and then escapes. The following is > > thetrace.. it tells me that the hypercall_page might trigger the > > xen_panic_event and then kernel got it to make itself panic. > > > > > ----------------------------------------------------------------------------- > > cs:eip: 0061:c04023a7 hypercall_page+0x3a7 > > flags: 00001286 i s nz p > > ss:esp: 0069:dfc1ff14 > > eax: 00000000 ebx: 00000002 ecx: dfc1ff18 edx: 00000000 > > esi: 00000000 edi: 00000000 ebp: dfc1ff28 > > ds: 007b es: 007b fs: 00d8 gs: 0000 > > Code (instr addr c04023a7) > > cc cc cc cc cc cc cc cc cc cc cc cc cc cc b8 1d 00 00 00 cd 82 <c3> cc > > cc cc cc cc cc cc cc cc cc > > > > > > Stack: > > c04036f2 00000003 c086ecc8 00000000 00000000 dfc1ff44 c06f7e45 c092b99c > > c0874c24 dfc22cc0 c087379c dfc22cc0 dfc1ff54 c06f7e89 ffffffff 00000000 > > dfc1ff70 c06f3e55 c07da467 c092b99c dfc1ff7c dfc22cc0 c087379c dfc1ffa4 > > c043eba9 c07da8ae c0406fab c040b33b dfc10000 00000000 00000001 dfc1ff90 > > > > Call Trace: > > [<c04023a7>] hypercall_page+0x3a7 <-- > > [<c04036f2>] xen_panic_event+0x1d > > [<c06f7e45>] notifier_call_chain+0x26 > > [<c06f7e89>] atomic_notifier_call_chain+0xf > > [<c06f3e55>] panic+0x59 > > [<c043eba9>] do_exit+0x5c > > [<c0406fab>] xen_restore_fl_direct_reloc+0x4 > > [<c040b33b>] do_softirq+0xd5 > > [<c043f1f1>] sys_exit+0x13 > > [<c0409389>] syscall_call+0x7 > > > ----------------------------------------------------------------------------- > > > > I also include some logs from console. > > > > > ------------------------------------------------------------------------------- > > cpuidle: using governor ladder > > cpuidle: using governor menu > > usbcore: registered new interface driver hiddev > > usbcore: registered new interface driver usbhid > > usbhid: v2.6:USB HID core driver > > nf_conntrack version 0.5.0 (7992 buckets, 31968 max) > > CONFIG_NF_CT_ACCT is deprecated and will be removed soon. Please use > > nf_conntrack.acct=1 kernel parameter, acct=1 nf_conntrack module option > or > > sysctl net.netfilter.nf_conntrack_acct=1 to enable it. > > ip_tables: (C) 2000-2006 Netfilter Core Team > > TCP cubic registered > > Initializing XFRM netlink socket > > NET: Registered protocol family 17 > > Bridge firewalling registered > > Using IPI No-Shortcut mode > > registered taskstats version 1 > > XENBUS: Device with no driver: device/vbd/51714 > > XENBUS: Device with no driver: device/vbd/51713 > > XENBUS: Device with no driver: device/console/0 > > Magic number: 1:252:3141 > > Freeing unused kernel memory: 464k freed > > Write protecting the kernel text: 3048k > > Write protecting the kernel read-only data: 1464k > > Loading, please wait... > > <30>udev[493]: starting version 167 > > Begin: Loading essential drivers ... JINHO: 1. xlblk_init called > > JINHO: 2. xlblk_init called > > JINHO: 3. xlblk_init called > > blkfront: xvda2: barriers enabled (tag) > > Setting capacity to 8388608 > > blkfront: xvda1: barriers enabled (tag) > > Setting capacity to 2097152 > > xvda1: detected capacity change from 0 to 1073741824 > > done. > > Begin: Running /scripts/init-premount ... done. > > Begin: Mounting root file system ... Begin: Running /scripts/local-top > > ... done. > > Begin: Running /scripts/local-premount ... done. > > kjournald starting. Commit interval 5 seconds > > EXT3-fs: mounted filesystem with writeback data mode. > > Begin: Running /scripts/local-bottom ... done. > > done. > > Begin: Running /scripts/init-bottom ... done. > > run-init: /sbin/init: No such file or directory > > Kernel panic - not syncing: Attempted to kill init! > > Pid: 1, comm: run-init Not tainted 2.6.32.45 #1 > > Call Trace: > > [<c06f3efc>] ? printk+0xf/0x13 > > [<c06f3e35>] panic+0x39/0xf1 > > [<c043eba9>] do_exit+0x5c/0x5cf > > [<c0406fab>] ? xen_restore_fl_direct_end+0x0/0x1 > > [<c040b33b>] ? do_softirq+0xd5/0xde > > [<c043f1f1>] complete_and_exit+0x0/0x17 > > [<c0409389>] syscall_call+0x7/0xb > > ------------------------------------------------------------------ > > > > Please help me to solve this problem. I have spent one week with this > > problem. > > It looks like there's something wrong with your filesystem > configuration: it is missing an /sbin/init. When this fails to start, > the kernel panics as it has no way to start up the usermode environment > without it. > > J > -- Jinho Hwang PhD Student Department of Computer Science The George Washington University Washington, DC 20052 hwang.jinho@gmail.com (email) 276.336.0971 (Cell) 202.994.4875 (fax) 070.8285.6546 (myLg070) --000e0cdf0d6cfb8e6e04ad6a33ed Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable <div><br></div>Thanks for replay. This is my fstab. Do I have to do somethi= ng else for mounting?<div><br></div><div><div>proc =A0 =A0 =A0 =A0 =A0 =A0/= proc =A0 =A0 =A0 =A0 =A0 proc =A0 =A0defaults =A0 =A0 =A0 =A00 =A0 =A0 =A0 = 0</div><div>devpts =A0 =A0 =A0 =A0 =A0/dev/pts =A0 =A0 =A0 =A0devpts =A0rw,= noexec,nosuid,gid=3D5,mode=3D620 0 =A00</div> <div>/dev/xvda1 none swap sw 0 0</div><div>/dev/xvda2 / ext3 noatime,nodira= time,errors=3Dremount-ro 0 1</div><div><br></div><div>Jinho</div><div><br><= div class=3D"gmail_quote">On Tue, Sep 20, 2011 at 9:32 PM, Jeremy Fitzhardi= nge <span dir=3D"ltr"><<a href=3D"mailto:jeremy@goop.org">jeremy@goop.or= g</a>></span> wrote:<br> <blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1p= x #ccc solid;padding-left:1ex;"><div><div></div><div class=3D"h5">On 09/20/= 2011 02:27 PM, jinho hwang wrote:<br> ><br> > Hi All,<br> ><br> > I'm using xen 4.0.1, kernel 2.6.32.45 for DomU, kernel 2.6.32.46 f= or<br> > Dom0. I also use pygrub to boot the domU kernel in the xen. I tried<br= > > all the things I know for making this work, but unfortunately it does<= br> > not work at this moment.<br> > The kernel shows panic message and then escapes. The following is<br> > thetrace.. it tells me that the hypercall_page might trigger the<br> > xen_panic_event and then kernel got it to make itself panic.<br> ><br> > ----------------------------------------------------------------------= -------<br> > cs:eip: 0061:c04023a7 hypercall_page+0x3a7<br> > flags: 00001286 i s nz p<br> > ss:esp: 0069:dfc1ff14<br> > eax: 00000000 =A0 =A0ebx: 00000002 =A0 =A0ecx: dfc1ff18 =A0 =A0edx: 00= 000000<br> > esi: 00000000 =A0 =A0edi: 00000000 =A0 =A0ebp: dfc1ff28<br> > =A0ds: =A0 =A0 007b =A0 =A0 es: =A0 =A0 007b =A0 =A0 fs: =A0 =A0 00d8 = =A0 =A0 gs: =A0 =A0 0000<br> > Code (instr addr c04023a7)<br> > cc cc cc cc cc cc cc cc cc cc cc cc cc cc b8 1d 00 00 00 cd 82 <c3&= gt; cc<br> > cc cc cc cc cc cc cc cc cc<br> ><br> ><br> > Stack:<br> > =A0c04036f2 00000003 c086ecc8 00000000 00000000 dfc1ff44 c06f7e45 c092= b99c<br> > =A0c0874c24 dfc22cc0 c087379c dfc22cc0 dfc1ff54 c06f7e89 ffffffff 0000= 0000<br> > =A0dfc1ff70 c06f3e55 c07da467 c092b99c dfc1ff7c dfc22cc0 c087379c dfc1= ffa4<br> > =A0c043eba9 c07da8ae c0406fab c040b33b dfc10000 00000000 00000001 dfc1= ff90<br> ><br> > Call Trace:<br> > =A0 [<c04023a7>] hypercall_page+0x3a7 =A0<--<br> > =A0 [<c04036f2>] xen_panic_event+0x1d<br> > =A0 [<c06f7e45>] notifier_call_chain+0x26<br> > =A0 [<c06f7e89>] atomic_notifier_call_chain+0xf<br> > =A0 [<c06f3e55>] panic+0x59<br> > =A0 [<c043eba9>] do_exit+0x5c<br> > =A0 [<c0406fab>] xen_restore_fl_direct_reloc+0x4<br> > =A0 [<c040b33b>] do_softirq+0xd5<br> > =A0 [<c043f1f1>] sys_exit+0x13<br> > =A0 [<c0409389>] syscall_call+0x7<br> > ----------------------------------------------------------------------= -------<br> ><br> > I also include some logs from console.<br> ><br> > ----------------------------------------------------------------------= ---------<br> > cpuidle: using governor ladder<br> > cpuidle: using governor menu<br> > usbcore: registered new interface driver hiddev<br> > usbcore: registered new interface driver usbhid<br> > usbhid: v2.6:USB HID core driver<br> > nf_conntrack version 0.5.0 (7992 buckets, 31968 max)<br> > CONFIG_NF_CT_ACCT is deprecated and will be removed soon. Please use<b= r> > nf_conntrack.acct=3D1 kernel parameter, acct=3D1 nf_conntrack module o= ption or<br> > sysctl net.netfilter.nf_conntrack_acct=3D1 to enable it.<br> > ip_tables: (C) 2000-2006 Netfilter Core Team<br> > TCP cubic registered<br> > Initializing XFRM netlink socket<br> > NET: Registered protocol family 17<br> > Bridge firewalling registered<br> > Using IPI No-Shortcut mode<br> > registered taskstats version 1<br> > XENBUS: Device with no driver: device/vbd/51714<br> > XENBUS: Device with no driver: device/vbd/51713<br> > XENBUS: Device with no driver: device/console/0<br> > =A0 Magic number: 1:252:3141<br> > Freeing unused kernel memory: 464k freed<br> > Write protecting the kernel text: 3048k<br> > Write protecting the kernel read-only data: 1464k<br> > Loading, please wait...<br> > <30>udev[493]: starting version 167<br> > Begin: Loading essential drivers ... JINHO: 1. xlblk_init called<br> > JINHO: 2. xlblk_init called<br> > JINHO: 3. xlblk_init called<br> > blkfront: xvda2: barriers enabled (tag)<br> > Setting capacity to 8388608<br> > blkfront: xvda1: barriers enabled (tag)<br> > Setting capacity to 2097152<br> > xvda1: detected capacity change from 0 to 1073741824<br> > done.<br> > Begin: Running /scripts/init-premount ... done.<br> > Begin: Mounting root file system ... Begin: Running /scripts/local-top= <br> > ... done.<br> > Begin: Running /scripts/local-premount ... done.<br> > kjournald starting. =A0Commit interval 5 seconds<br> > EXT3-fs: mounted filesystem with writeback data mode.<br> > Begin: Running /scripts/local-bottom ... done.<br> > done.<br> > Begin: Running /scripts/init-bottom ... done.<br> > run-init: /sbin/init: No such file or directory<br> > Kernel panic - not syncing: Attempted to kill init!<br> > Pid: 1, comm: run-init Not tainted 2.6.32.45 #1<br> > Call Trace:<br> > =A0[<c06f3efc>] ? printk+0xf/0x13<br> > =A0[<c06f3e35>] panic+0x39/0xf1<br> > =A0[<c043eba9>] do_exit+0x5c/0x5cf<br> > =A0[<c0406fab>] ? xen_restore_fl_direct_end+0x0/0x1<br> > =A0[<c040b33b>] ? do_softirq+0xd5/0xde<br> > =A0[<c043f1f1>] complete_and_exit+0x0/0x17<br> > =A0[<c0409389>] syscall_call+0x7/0xb<br> > ------------------------------------------------------------------<br> ><br> > Please help me to solve this problem. I have spent one week with this<= br> > problem.<br> <br> </div></div>It looks like there's something wrong with your filesystem<= br> configuration: it is missing an /sbin/init. =A0When this fails to start,<br= > the kernel panics as it has no way to start up the usermode environment<br> without it.<br> <font color=3D"#888888"><br> =A0 =A0J<br> </font></blockquote></div><br><br clear=3D"all"><div><br></div>-- <br>Jinho= Hwang<br>PhD Student<br>Department of Computer Science<br>The George Washi= ngton University<br>Washington, DC 20052<br><a href=3D"mailto:hwang.jinho@g= mail.com">hwang.jinho@gmail.com</a> (email)<br> 276.336.0971 (Cell)<br>202.994.4875 (fax)<br>070.8285.6546 (myLg070)<br> </div></div> --000e0cdf0d6cfb8e6e04ad6a33ed-- --===============2132354085== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel --===============2132354085==-- From xen-devel-bounces@lists.xensource.com Tue Sep 20 20:22:19 2011 Return-path: <xen-devel-bounces@lists.xensource.com> Envelope-to: www-data@lists.xensource.com Delivery-date: Tue, 20 Sep 2011 20:22:19 -0700 Received: from localhost ([127.0.0.1] helo=lists.colo.xensource.com) by lists.xensource.com with esmtp (Exim 4.43) id 1R6DO7-0003Ht-JH; Tue, 20 Sep 2011 20:22:19 -0700 Received: from mail27.messagelabs.com ([193.109.254.147]) by lists.xensource.com with esmtp (Exim 4.43) id 1R6CS3-0007KL-3b for xen-devel@lists.xensource.com; Tue, 20 Sep 2011 19:22:19 -0700 X-Env-Sender: duolvxendev@yahoo.cn X-Msg-Ref: server-9.tower-27.messagelabs.com!1316571718!45363455!1 X-Originating-IP: [216.139.236.26] X-StarScan-Version: 6.4.1; banners=-,-,- X-VirusChecked: Checked Received: (qmail 30678 invoked from network); 21 Sep 2011 02:21:59 -0000 Received: from sam.nabble.com (HELO sam.nabble.com) (216.139.236.26) by server-9.tower-27.messagelabs.com with AES256-SHA encrypted SMTP; 21 Sep 2011 02:21:59 -0000 Received: from [192.168.236.26] (helo=sam.nabble.com) by sam.nabble.com with esmtp (Exim 4.72) (envelope-from <duolvxendev@yahoo.cn>) id 1R6CRy-00047c-Br for xen-devel@lists.xensource.com; Tue, 20 Sep 2011 19:22:14 -0700 Date: Tue, 20 Sep 2011 19:22:14 -0700 (PDT) From: duolvxendev <duolvxendev@yahoo.cn> To: xen-devel@lists.xensource.com Message-ID: <1316571734360-4824822.post@n5.nabble.com> In-Reply-To: <alpine.DEB.2.00.1109201908010.8700@kaball-desktop> References: <1316338995760-4815691.post@n5.nabble.com> <alpine.DEB.2.00.1109201908010.8700@kaball-desktop> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Mailman-Approved-At: Tue, 20 Sep 2011 20:10:52 -0700 Subject: [Xen-devel] Re: Permission for xenstore operation on HVM X-BeenThere: xen-devel@lists.xensource.com X-Mailman-Version: 2.1.5 Precedence: list List-Id: Xen developer discussion <xen-devel.lists.xensource.com> List-Unsubscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe> List-Post: <mailto:xen-devel@lists.xensource.com> List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help> List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=subscribe> Sender: xen-devel-bounces@lists.xensource.com Errors-To: xen-devel-bounces@lists.xensource.com I'm trying to create a directory and write some messages, i.e. to some path like /local/domain/$DOMID/my_directory/my_key. This is OK on pv domU, but denied on HVM. I can write to /local/domain/device directory by frontend driver, but I cannot create or write to some arbitrary path that doesn't exist. It looks like that one needs special permission on HVM. -- View this message in context: http://xen.1045712.n5.nabble.com/Permission-for-xenstore-operation-on-HVM-tp4815691p4824822.html Sent from the Xen - Dev mailing list archive at Nabble.com. _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel From xen-devel-bounces@lists.xensource.com Tue Sep 20 22:20:04 2011 Return-path: <xen-devel-bounces@lists.xensource.com> Envelope-to: www-data@lists.xensource.com Delivery-date: Tue, 20 Sep 2011 22:20:04 -0700 Received: from localhost ([127.0.0.1] helo=lists.colo.xensource.com) by lists.xensource.com with esmtp (Exim 4.43) id 1R6FE4-0006cI-7p; Tue, 20 Sep 2011 22:20:04 -0700 Received: from mail216.messagelabs.com ([85.158.143.99]) by lists.xensource.com with esmtp (Exim 4.43) id 1R6FD4-0006PA-AB for xen-devel@lists.xensource.com; Tue, 20 Sep 2011 22:19:02 -0700 X-Env-Sender: apxeng@gmail.com X-Msg-Ref: server-15.tower-216.messagelabs.com!1316582337!18530437!1 X-Originating-IP: [209.85.216.49] X-StarScan-Version: 6.4.1; banners=-,-,- X-VirusChecked: Checked Received: (qmail 14850 invoked from network); 21 Sep 2011 05:18:58 -0000 Received: from mail-qw0-f49.google.com (HELO mail-qw0-f49.google.com) (209.85.216.49) by server-15.tower-216.messagelabs.com with RC4-SHA encrypted SMTP; 21 Sep 2011 05:18:58 -0000 Received: by qwi2 with SMTP id 2so2791746qwi.8 for <xen-devel@lists.xensource.com>; Tue, 20 Sep 2011 22:18:57 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=Kma9LbzrlIkLfObzsoC+c8Yq8zDrecfhT2RaN1tabdQ=; b=m/uOYAoOnrHxs0FA8xbdlWipwO/FS8MwAUWSZ4DeEdDV1bSyeC95VDU/pIz1uJmR39 WysUeGUubzOqKAKelGHdbwRkezKtJf2lw8HXeUZvyhJ/snb3tb1r8ew2x3RaCw8H4X88 4/wta4mdHhKI9Z1jJ36g/H/uRgXkOYD7rzS0Y= MIME-Version: 1.0 Received: by 10.229.246.10 with SMTP id lw10mr161488qcb.124.1316582337171; Tue, 20 Sep 2011 22:18:57 -0700 (PDT) Received: by 10.229.21.1 with HTTP; Tue, 20 Sep 2011 22:18:56 -0700 (PDT) Received: by 10.229.21.1 with HTTP; Tue, 20 Sep 2011 22:18:56 -0700 (PDT) In-Reply-To: <20110920175712.GB35343@ocelot.phlegethon.org> References: <CAGU+autjPnjevraC5vhX4RAMC2XrqkfKUN_ZuJz1r0r3078=0Q@mail.gmail.com> <20110920175712.GB35343@ocelot.phlegethon.org> Date: Tue, 20 Sep 2011 22:18:56 -0700 Message-ID: <CAGU+autdJ0fXw2w4xmhe1Z7YZe_7H+XVr11k1-yjj9eyWMW1cA@mail.gmail.com> Subject: Re: [Xen-devel] Testing nested virtualization on Intel CPUs From: AP <apxeng@gmail.com> To: Tim Deegan <tim@xen.org> Cc: xen-devel@lists.xensource.com, Eddie Dong <eddie.dong@intel.com> X-BeenThere: xen-devel@lists.xensource.com X-Mailman-Version: 2.1.5 Precedence: list List-Id: Xen developer discussion <xen-devel.lists.xensource.com> List-Unsubscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe> List-Post: <mailto:xen-devel@lists.xensource.com> List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help> List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=subscribe> Content-Type: multipart/mixed; boundary="===============1042961362==" Sender: xen-devel-bounces@lists.xensource.com Errors-To: xen-devel-bounces@lists.xensource.com --===============1042961362== Content-Type: multipart/alternative; boundary=0016363b965e86518204ad6cb68a --0016363b965e86518204ad6cb68a Content-Type: text/plain; charset=ISO-8859-1 On Sep 20, 2011 10:57 AM, "Tim Deegan" <tim@xen.org> wrote: > > Hi, > > Cc'ing Eddie Dong, who wrote this code. > > At 18:16 -0700 on 16 Sep (1316196980), AP wrote: > > I am testing out nested virtualization on a Lenovo x220 (Intel > > i7-2620M). I am running xen-unstable (23842:483c5f8319ad) and Linux > > 3.0 (Ubuntu 10.10). > > I brought up a Centos 5.6 VM and installed Xen that is packaged with > > it. I think it is a variant of 3.0. The CentOS Xen VM boots very > > slowly but it does finally come up in to the nested Dom0. > > Yes, booting Xen as a nested guest is very slow at startup, because of > how Xen relocates the bottom 1MB at boot time. You might find that > 32-bit Xen boots faster. > Could please expand a little on why the relocation causes it to slow down? Thanks, AP > In general I expect performance of a nested-HVM guest on Intel to be > quite poor, because it doesn't yet have nested EPT support. Eddie, is > that something you're working on? > > Tim. > --0016363b965e86518204ad6cb68a Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable <p><br> On Sep 20, 2011 10:57 AM, "Tim Deegan" <<a href=3D"mailto:tim@= xen.org">tim@xen.org</a>> wrote:<br> ><br> > Hi,<br> ><br> > Cc'ing Eddie Dong, who wrote this code.<br> ><br> > At 18:16 -0700 on 16 Sep (1316196980), AP wrote:<br> > > I am testing out nested virtualization on a Lenovo x220 (Intel<br= > > > i7-2620M). I am running xen-unstable (23842:483c5f8319ad) and Lin= ux<br> > > 3.0 (Ubuntu 10.10).<br> > > I brought up a Centos 5.6 VM and installed Xen that is packaged w= ith<br> > > it. I think it is a variant of 3.0. The CentOS Xen VM boots very<= br> > > slowly but it does finally come up in to the nested Dom0.<br> ><br> > Yes, booting Xen as a nested guest is very slow at startup, because of= <br> > how Xen relocates the bottom 1MB at boot time. =A0You might find that<= br> > 32-bit Xen boots faster.<br> ></p> <p>Could please expand a little on why the relocation causes it to slow dow= n?</p> <p>Thanks,<br> AP</p> <p>> In general I expect performance of a nested-HVM guest on Intel to b= e<br> > quite poor, because it doesn't yet have nested EPT support. =A0Edd= ie, is<br> > that something you're working on?<br> ><br> > Tim.<br> ><br> </p> --0016363b965e86518204ad6cb68a-- --===============1042961362== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel --===============1042961362==-- From xen-devel-bounces@lists.xensource.com Tue Sep 20 23:45:43 2011 Return-path: <xen-devel-bounces@lists.xensource.com> Envelope-to: www-data@lists.xensource.com Delivery-date: Tue, 20 Sep 2011 23:45:43 -0700 Received: from localhost ([127.0.0.1] helo=lists.colo.xensource.com) by lists.xensource.com with esmtp (Exim 4.43) id 1R6GYx-00008T-NZ; Tue, 20 Sep 2011 23:45:43 -0700 Received: from mail174.messagelabs.com ([85.158.138.51]) by lists.xensource.com with esmtp (Exim 4.43) id 1R6GXv-0008Ng-3E for xen-devel@lists.xensource.com; Tue, 20 Sep 2011 23:44:40 -0700 X-Env-Sender: JBeulich@suse.com X-Msg-Ref: server-13.tower-174.messagelabs.com!1316587475!32201534!1 X-Originating-IP: [130.57.49.28] X-StarScan-Version: 6.4.1; banners=-,-,- X-VirusChecked: Checked Received: (qmail 7828 invoked from network); 21 Sep 2011 06:44:35 -0000 Received: from nat28.tlf.novell.com (HELO nat28.tlf.novell.com) (130.57.49.28) by server-13.tower-174.messagelabs.com with DHE-RSA-AES256-SHA encrypted SMTP; 21 Sep 2011 06:44:35 -0000 Received: from EMEA1-MTA by nat28.tlf.novell.com with Novell_GroupWise; Wed, 21 Sep 2011 07:44:34 +0100 Message-Id: <4E79A40D0200007800056F4B@nat28.tlf.novell.com> X-Mailer: Novell GroupWise Internet Agent 8.0.1 Date: Wed, 21 Sep 2011 07:45:01 +0100 From: "Jan Beulich" <JBeulich@suse.com> To: "Allen M Kay" <allen.m.kay@intel.com> Subject: RE: [Xen-devel] RE: Resend: RE: enable_ats_device() call site References: <4E4E48360200007800051F65@nat28.tlf.novell.com> <987664A83D2D224EAE907B061CE93D5301EA5B67F0@orsmsx505.amr.corp.intel.com> <4E5380890200007800052B61@nat28.tlf.novell.com> <4E78B7CA0200007800056CCE@nat28.tlf.novell.com> <987664A83D2D224EAE907B061CE93D5301EDED2D32@orsmsx505.amr.corp.intel.com> In-Reply-To: <987664A83D2D224EAE907B061CE93D5301EDED2D32@orsmsx505.amr.corp.intel.com> Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: quoted-printable Content-Disposition: inline Cc: Xen Devel <xen-devel@lists.xensource.com> X-BeenThere: xen-devel@lists.xensource.com X-Mailman-Version: 2.1.5 Precedence: list List-Id: Xen developer discussion <xen-devel.lists.xensource.com> List-Unsubscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe> List-Post: <mailto:xen-devel@lists.xensource.com> List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help> List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=subscribe> Sender: xen-devel-bounces@lists.xensource.com Errors-To: xen-devel-bounces@lists.xensource.com >>> On 20.09.11 at 20:02, "Kay, Allen M" <allen.m.kay@intel.com> wrote: > Thanks for the reminder. This has slip through the cracks. The patch = look=20 > good. With this patch, we shouldn't need the existing call to=20 > pci_enable_acs() in setup_dom0_devices(), correct? Ah, indeed, I didn't even pay attention to this. But you didn't say anything about the subject of the mail, which is what keeps me from pushing the (incomplete) patch. > I agree that the same problem exists for bus-to-bridge mapping = function=20 > pci_scan_device(). By the way, we probably should take the opportunity = to=20 > give it a proper name that reflects to the true purpose of this = function. It's not that far off, if you mean scan_pci_devices() (and _scan_pci_devices() once the multi-seg patches get committed). What alternative name were you thinking of? Also, if the bus2bridge data got maintained dynamically (i.e. out of pci_{add,remove}_device()), I would think these functions could go away again (and hence renaming them would become mute). Jan _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel From xen-devel-bounces@lists.xensource.com Tue Sep 20 23:47:53 2011 Return-path: <xen-devel-bounces@lists.xensource.com> Envelope-to: www-data@lists.xensource.com Delivery-date: Tue, 20 Sep 2011 23:47:53 -0700 Received: from localhost ([127.0.0.1] helo=lists.colo.xensource.com) by lists.xensource.com with esmtp (Exim 4.43) id 1R6Gb3-0000X5-0A; Tue, 20 Sep 2011 23:47:53 -0700 Received: from mail174.messagelabs.com ([85.158.138.51]) by lists.xensource.com with esmtp (Exim 4.43) id 1R6GaO-0000Kn-6l for xen-devel@lists.xensource.com; Tue, 20 Sep 2011 23:47:12 -0700 X-Env-Sender: JBeulich@suse.com X-Msg-Ref: server-12.tower-174.messagelabs.com!1316587628!32180657!1 X-Originating-IP: [130.57.49.28] X-StarScan-Version: 6.4.1; banners=-,-,- X-VirusChecked: Checked Received: (qmail 7949 invoked from network); 21 Sep 2011 06:47:09 -0000 Received: from nat28.tlf.novell.com (HELO nat28.tlf.novell.com) (130.57.49.28) by server-12.tower-174.messagelabs.com with DHE-RSA-AES256-SHA encrypted SMTP; 21 Sep 2011 06:47:09 -0000 Received: from EMEA1-MTA by nat28.tlf.novell.com with Novell_GroupWise; Wed, 21 Sep 2011 07:47:08 +0100 Message-Id: <4E79A4A90200007800056F50@nat28.tlf.novell.com> X-Mailer: Novell GroupWise Internet Agent 8.0.1 Date: Wed, 21 Sep 2011 07:47:37 +0100 From: "Jan Beulich" <JBeulich@suse.com> To: "Allen M Kay" <allen.m.kay@intel.com> Subject: RE: [Xen-devel] Xen Advisory 5 (CVE-2011-3131) IOMMU fault livelock References: <20037.10841.995717.397090@mariner.uk.xensource.com> <4E454C880200007800051000@nat28.tlf.novell.com> <20110812140901.GC11708@ocelot.phlegethon.org> <4E4559440200007800051062@nat28.tlf.novell.com> <20110815092608.GD11708@ocelot.phlegethon.org> <4E4A32650200007800051651@nat28.tlf.novell.com> <20110816150621.GM11708@ocelot.phlegethon.org> <4E4AAFF402000078000518CF@nat28.tlf.novell.com> <987664A83D2D224EAE907B061CE93D5301EDED333E@orsmsx505.amr.corp.intel.com> In-Reply-To: <987664A83D2D224EAE907B061CE93D5301EDED333E@orsmsx505.amr.corp.intel.com> Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: quoted-printable Content-Disposition: inline Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>, Tim Deegan <tim@xen.org>, Donald D Dugger <donald.d.dugger@intel.com>, "Xen.orgsecurity team" <security@xen.org> X-BeenThere: xen-devel@lists.xensource.com X-Mailman-Version: 2.1.5 Precedence: list List-Id: Xen developer discussion <xen-devel.lists.xensource.com> List-Unsubscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe> List-Post: <mailto:xen-devel@lists.xensource.com> List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help> List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=subscribe> Sender: xen-devel-bounces@lists.xensource.com Errors-To: xen-devel-bounces@lists.xensource.com >>> On 21.09.11 at 02:07, "Kay, Allen M" <allen.m.kay@intel.com> wrote: > Catching up on an old thread ... >=20 > If I understand correctly, the proposal is to check for VT-d faults = in=20 > do_softirq() handler. If so, we probably don't even need to enable VT-d = MSI=20 > interrupt at all if iommu_debug is not set, basically handling VT-d = faults=20 > with polling method. No, I don't think switching to polling mode was implied here. My thinking was rather along the lines of a dedicated softirq that the interrupt handler would raise, for the bulk of the handling to take place there. Jan _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel From xen-devel-bounces@lists.xensource.com Wed Sep 21 00:23:18 2011 Return-path: <xen-devel-bounces@lists.xensource.com> Envelope-to: www-data@lists.xensource.com Delivery-date: Wed, 21 Sep 2011 00:23:18 -0700 Received: from localhost ([127.0.0.1] helo=lists.colo.xensource.com) by lists.xensource.com with esmtp (Exim 4.43) id 1R6H9I-0002le-C7; Wed, 21 Sep 2011 00:23:16 -0700 Received: from mail21.messagelabs.com ([85.158.143.35]) by lists.xensource.com with esmtp (Exim 4.43) id 1R6H8V-0002Z3-GZ for xen-devel@lists.xensource.com; Wed, 21 Sep 2011 00:22:28 -0700 X-Env-Sender: JBeulich@suse.com X-Msg-Ref: server-4.tower-21.messagelabs.com!1316589708!61010430!1 X-Originating-IP: [130.57.49.28] X-StarScan-Version: 6.4.1; banners=-,-,- X-VirusChecked: Checked Received: (qmail 28463 invoked from network); 21 Sep 2011 07:21:48 -0000 Received: from nat28.tlf.novell.com (HELO nat28.tlf.novell.com) (130.57.49.28) by server-4.tower-21.messagelabs.com with DHE-RSA-AES256-SHA encrypted SMTP; 21 Sep 2011 07:21:48 -0000 Received: from EMEA1-MTA by nat28.tlf.novell.com with Novell_GroupWise; Wed, 21 Sep 2011 08:22:24 +0100 Message-Id: <4E79ACEA0200007800056F71@nat28.tlf.novell.com> X-Mailer: Novell GroupWise Internet Agent 8.0.1 Date: Wed, 21 Sep 2011 08:22:50 +0100 From: "Jan Beulich" <JBeulich@suse.com> To: "Ian Jackson" <Ian.Jackson@eu.citrix.com>, "Keir Fraser" <keir@xen.org> Subject: Re: [Xen-devel] [PATCH, RFC 0/7] PCI multi-segment support References: <4E64EF860200007800054B03@nat28.tlf.novell.com> <CA8A95BF.31189%keir@xen.org> <20088.54567.491056.744920@mariner.uk.xensource.com> In-Reply-To: <20088.54567.491056.744920@mariner.uk.xensource.com> Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: quoted-printable Content-Disposition: inline Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com> X-BeenThere: xen-devel@lists.xensource.com X-Mailman-Version: 2.1.5 Precedence: list List-Id: Xen developer discussion <xen-devel.lists.xensource.com> List-Unsubscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe> List-Post: <mailto:xen-devel@lists.xensource.com> List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help> List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=subscribe> Sender: xen-devel-bounces@lists.xensource.com Errors-To: xen-devel-bounces@lists.xensource.com >>> On 20.09.11 at 20:02, Ian Jackson <Ian.Jackson@eu.citrix.com> wrote: > Keir Fraser writes ("Re: [Xen-devel] [PATCH, RFC 0/7] PCI multi-segment= =20 > support"): >> My conclusion would be you can do the cleaner change to domctl. = Interested >> in Ian Jackson's view however. >=20 > We need to preserve compatibility with other versions of linux and > qemu. Do these programs need to know about these changes too ? I didn't find any references to those domctl operations there (the kernel certainly shouldn't have any, despite there being a couple of things that currently can't be done without the use of domctls in the kernel), and qemu also shouldn't have anything to do with the operations changed here. Jan _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel From xen-devel-bounces@lists.xensource.com Wed Sep 21 00:33:35 2011 Return-path: <xen-devel-bounces@lists.xensource.com> Envelope-to: www-data@lists.xensource.com Delivery-date: Wed, 21 Sep 2011 00:33:35 -0700 Received: from localhost ([127.0.0.1] helo=lists.colo.xensource.com) by lists.xensource.com with esmtp (Exim 4.43) id 1R6HJH-0003QP-OM; Wed, 21 Sep 2011 00:33:35 -0700 Received: from mail182.messagelabs.com ([85.158.139.83]) by lists.xensource.com with esmtp (Exim 4.43) id 1R6HIi-0003Bu-DQ for xen-devel@lists.xensource.com; Wed, 21 Sep 2011 00:33:01 -0700 X-Env-Sender: JBeulich@suse.com X-Msg-Ref: server-12.tower-182.messagelabs.com!1316590377!18988011!1 X-Originating-IP: [130.57.49.28] X-StarScan-Version: 6.4.1; banners=-,-,- X-VirusChecked: Checked Received: (qmail 21068 invoked from network); 21 Sep 2011 07:32:57 -0000 Received: from nat28.tlf.novell.com (HELO nat28.tlf.novell.com) (130.57.49.28) by server-12.tower-182.messagelabs.com with DHE-RSA-AES256-SHA encrypted SMTP; 21 Sep 2011 07:32:57 -0000 Received: from EMEA1-MTA by nat28.tlf.novell.com with Novell_GroupWise; Wed, 21 Sep 2011 08:32:56 +0100 Message-Id: <4E79AF630200007800056F80@nat28.tlf.novell.com> X-Mailer: Novell GroupWise Internet Agent 8.0.1 Date: Wed, 21 Sep 2011 08:33:23 +0100 From: "Jan Beulich" <JBeulich@suse.com> To: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com> Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: quoted-printable Content-Disposition: inline Subject: [Xen-devel] xzalloc() & Co? X-BeenThere: xen-devel@lists.xensource.com X-Mailman-Version: 2.1.5 Precedence: list List-Id: Xen developer discussion <xen-devel.lists.xensource.com> List-Unsubscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe> List-Post: <mailto:xen-devel@lists.xensource.com> List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help> List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=subscribe> Sender: xen-devel-bounces@lists.xensource.com Errors-To: xen-devel-bounces@lists.xensource.com While I seem to recall that this idea was rejected a couple of years back, shouldn't we re-think and follow e.g. Linux in having zeroing variants of xmalloc() & Co? That would not only reduce code size, but also eliminate one source of potential bugs (see e.g. the thread starting at http://marc.info/?l=3Dkernel-janitors&m=3D131615631720174&w=3D2). Jan _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel From xen-devel-bounces@lists.xensource.com Wed Sep 21 01:03:11 2011 Return-path: <xen-devel-bounces@lists.xensource.com> Envelope-to: www-data@lists.xensource.com Delivery-date: Wed, 21 Sep 2011 01:03:11 -0700 Received: from localhost ([127.0.0.1] helo=lists.colo.xensource.com) by lists.xensource.com with esmtp (Exim 4.43) id 1R6Hlr-0004ul-UC; Wed, 21 Sep 2011 01:03:08 -0700 Received: from mail182.messagelabs.com ([85.158.139.83]) by lists.xensource.com with esmtp (Exim 4.43) id 1R6Hhq-0004ex-5u for xen-devel@lists.xensource.com; Wed, 21 Sep 2011 00:59:43 -0700 X-Env-Sender: JBeulich@suse.com X-Msg-Ref: server-10.tower-182.messagelabs.com!1316591921!19130490!1 X-Originating-IP: [130.57.49.28] X-StarScan-Version: 6.4.1; banners=-,-,- X-VirusChecked: Checked Received: (qmail 6812 invoked from network); 21 Sep 2011 07:58:42 -0000 Received: from nat28.tlf.novell.com (HELO nat28.tlf.novell.com) (130.57.49.28) by server-10.tower-182.messagelabs.com with DHE-RSA-AES256-SHA encrypted SMTP; 21 Sep 2011 07:58:42 -0000 Received: from EMEA1-MTA by nat28.tlf.novell.com with Novell_GroupWise; Wed, 21 Sep 2011 08:58:41 +0100 Message-Id: <4E79B56C0200007800056F8E@nat28.tlf.novell.com> X-Mailer: Novell GroupWise Internet Agent 8.0.1 Date: Wed, 21 Sep 2011 08:59:08 +0100 From: "Jan Beulich" <JBeulich@suse.com> To: "Allen M Kay" <allen.m.kay@intel.com> Subject: RE: [Xen-devel] RE: Resend: RE: enable_ats_device() call site Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: quoted-printable Content-Disposition: inline Cc: Xen Devel <xen-devel@lists.xensource.com> X-BeenThere: xen-devel@lists.xensource.com X-Mailman-Version: 2.1.5 Precedence: list List-Id: Xen developer discussion <xen-devel.lists.xensource.com> List-Unsubscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe> List-Post: <mailto:xen-devel@lists.xensource.com> List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help> List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=subscribe> Sender: xen-devel-bounces@lists.xensource.com Errors-To: xen-devel-bounces@lists.xensource.com >>> On 20.09.11 at 20:02, "Kay, Allen M" <allen.m.kay@intel.com> wrote: > I agree that the same problem exists for bus-to-bridge mapping = function=20 > pci_scan_device(). By the way, we probably should take the opportunity = to=20 > give it a proper name that reflects to the true purpose of this = function. How about the below (applying only on top of the multi-seg patches, and not yet removing the scanning functions)? Jan --- a/xen/drivers/passthrough/pci.c +++ b/xen/drivers/passthrough/pci.c @@ -129,11 +129,67 @@ static struct pci_dev *alloc_pdev(struct list_add(&pdev->alldevs_list, &pseg->alldevs_list); spin_lock_init(&pdev->msix_table_lock); =20 + /* update bus2bridge */ + switch ( pdev_type(pseg->nr, bus, devfn) ) + { + u8 sec_bus, sub_bus; + + case DEV_TYPE_PCIe_BRIDGE: + break; + + case DEV_TYPE_PCIe2PCI_BRIDGE: + case DEV_TYPE_LEGACY_PCI_BRIDGE: + sec_bus =3D pci_conf_read8(pseg->nr, bus, PCI_SLOT(devfn), + PCI_FUNC(devfn), PCI_SECONDARY_BUS); + sub_bus =3D pci_conf_read8(pseg->nr, bus, PCI_SLOT(devfn), + PCI_FUNC(devfn), PCI_SUBORDINATE_BUS)= ; + + spin_lock(&pseg->bus2bridge_lock); + for ( ; sec_bus <=3D sub_bus; sec_bus++ ) + { + pseg->bus2bridge[sec_bus].map =3D 1; + pseg->bus2bridge[sec_bus].bus =3D bus; + pseg->bus2bridge[sec_bus].devfn =3D devfn; + } + spin_unlock(&pseg->bus2bridge_lock); + break; + + case DEV_TYPE_PCIe_ENDPOINT: + case DEV_TYPE_PCI: + break; + + default: + printk(XENLOG_WARNING "%s: unknown type: %04x:%02x:%02x.%u\n",= + __func__, pseg->nr, bus, PCI_SLOT(devfn), PCI_FUNC(devf= n)); + break; + } + return pdev; } =20 -static void free_pdev(struct pci_dev *pdev) +static void free_pdev(struct pci_seg *pseg, struct pci_dev *pdev) { + /* update bus2bridge */ + switch ( pdev_type(pseg->nr, pdev->bus, pdev->devfn) ) + { + u8 dev, func, sec_bus, sub_bus; + + case DEV_TYPE_PCIe2PCI_BRIDGE: + case DEV_TYPE_LEGACY_PCI_BRIDGE: + dev =3D PCI_SLOT(pdev->devfn); + func =3D PCI_FUNC(pdev->devfn); + sec_bus =3D pci_conf_read8(pseg->nr, pdev->bus, dev, func, + PCI_SECONDARY_BUS); + sub_bus =3D pci_conf_read8(pseg->nr, pdev->bus, dev, func, + PCI_SUBORDINATE_BUS); + + spin_lock(&pseg->bus2bridge_lock); + for ( ; sec_bus <=3D sub_bus; sec_bus++ ) + pseg->bus2bridge[sec_bus].map =3D 0; + spin_unlock(&pseg->bus2bridge_lock); + break; + } + list_del(&pdev->alldevs_list); xfree(pdev); } @@ -378,7 +434,7 @@ int pci_remove_device(u16 seg, u8 bus, u if ( pdev->domain ) list_del(&pdev->domain_list); pci_cleanup_msi(pdev); - free_pdev(pdev); + free_pdev(pseg, pdev); printk(XENLOG_DEBUG "PCI remove device %04x:%02x:%02x.%u\n", seg, bus, PCI_SLOT(devfn), PCI_FUNC(devfn)); break; @@ -546,8 +602,6 @@ static int __init _scan_pci_devices(stru { struct pci_dev *pdev; int bus, dev, func; - u8 sec_bus, sub_bus; - int type; =20 for ( bus =3D 0; bus < 256; bus++ ) { @@ -565,41 +619,6 @@ static int __init _scan_pci_devices(stru return -ENOMEM; } =20 - /* build bus2bridge */ - type =3D pdev_type(pseg->nr, bus, PCI_DEVFN(dev, func)); - switch ( type ) - { - case DEV_TYPE_PCIe_BRIDGE: - break; - - case DEV_TYPE_PCIe2PCI_BRIDGE: - case DEV_TYPE_LEGACY_PCI_BRIDGE: - sec_bus =3D pci_conf_read8(pseg->nr, bus, dev, = func, - PCI_SECONDARY_BUS); - sub_bus =3D pci_conf_read8(pseg->nr, bus, dev, = func, - PCI_SUBORDINATE_BUS); - - spin_lock(&pseg->bus2bridge_lock); - for ( sub_bus &=3D 0xff; sec_bus <=3D sub_bus; = sec_bus++ ) - { - pseg->bus2bridge[sec_bus].map =3D 1; - pseg->bus2bridge[sec_bus].bus =3D bus; - pseg->bus2bridge[sec_bus].devfn =3D - PCI_DEVFN(dev, func); - } - spin_unlock(&pseg->bus2bridge_lock); - break; - - case DEV_TYPE_PCIe_ENDPOINT: - case DEV_TYPE_PCI: - break; - - default: - printk("%s: unknown type: %04x:%02x:%02x.%u\n", - __func__, pseg->nr, bus, dev, func); - return -EINVAL; - } - if ( !func && !(pci_conf_read8(pseg->nr, bus, dev, func, PCI_HEADER_TYPE) & 0x80) ) break; _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel From xen-devel-bounces@lists.xensource.com Wed Sep 21 01:57:47 2011 Return-path: <xen-devel-bounces@lists.xensource.com> Envelope-to: www-data@lists.xensource.com Delivery-date: Wed, 21 Sep 2011 01:57:47 -0700 Received: from localhost ([127.0.0.1] helo=lists.colo.xensource.com) by lists.xensource.com with esmtp (Exim 4.43) id 1R6Ick-0007ex-Gq; Wed, 21 Sep 2011 01:57:47 -0700 Received: from mail21.messagelabs.com ([85.158.143.35]) by lists.xensource.com with esmtp (Exim 4.43) id 1R6Ibe-0007R6-03 for xen-devel@lists.xensource.com; Wed, 21 Sep 2011 01:56:38 -0700 X-Env-Sender: Ian.Campbell@eu.citrix.com X-Msg-Ref: server-15.tower-21.messagelabs.com!1316595396!51389495!1 X-Originating-IP: [62.200.22.115] X-StarScan-Version: 6.4.1; banners=-,-,- X-VirusChecked: Checked Received: (qmail 18672 invoked from network); 21 Sep 2011 08:56:36 -0000 Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115) by server-15.tower-21.messagelabs.com with RC4-SHA encrypted SMTP; 21 Sep 2011 08:56:36 -0000 X-IronPort-AV: E=Sophos;i="4.68,416,1312156800"; d="scan'208";a="7970868" Received: from lonpmailmx01.citrite.net ([10.30.203.162]) by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5; 21 Sep 2011 08:56:34 +0000 Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net (10.30.203.162) with Microsoft SMTP Server id 8.3.137.0; Wed, 21 Sep 2011 09:56:34 +0100 Subject: Re: [Xen-devel] xl create crash when using stub domains From: Ian Campbell <Ian.Campbell@eu.citrix.com> To: Jeremy Fitzhardinge <jeremy@goop.org> Date: Wed, 21 Sep 2011 09:56:34 +0100 In-Reply-To: <4E793F42.7070803@goop.org> References: <4E729960.2080101@goop.org> <4E793F42.7070803@goop.org> Organization: Citrix Systems, Inc. Content-Type: text/plain; charset="UTF-8" X-Mailer: Evolution 3.0.3- Content-Transfer-Encoding: 7bit Message-ID: <1316595394.3891.105.camel@zakaz.uk.xensource.com> MIME-Version: 1.0 Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>, Ian Jackson <Ian.Jackson@eu.citrix.com>, Stefano Stabellini <Stefano.Stabellini@eu.citrix.com> X-BeenThere: xen-devel@lists.xensource.com X-Mailman-Version: 2.1.5 Precedence: list List-Id: Xen developer discussion <xen-devel.lists.xensource.com> List-Unsubscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe> List-Post: <mailto:xen-devel@lists.xensource.com> List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help> List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=subscribe> Sender: xen-devel-bounces@lists.xensource.com Errors-To: xen-devel-bounces@lists.xensource.com On Wed, 2011-09-21 at 02:34 +0100, Jeremy Fitzhardinge wrote: > On 09/15/2011 05:33 PM, Jeremy Fitzhardinge wrote: > > When I create an HVM domain with stubdom enabled, it crashes at: > > > > (gdb) run create -c /etc/xen/f14hv64 vcpus=4 xen_platform_pci=0 'boot="d"' > > Starting program: /usr/sbin/xl create -c /etc/xen/f14hv64 vcpus=4 xen_platform_pci=0 'boot="d"' > > [Thread debugging using libthread_db enabled] > > Parsing config file /etc/xen/f14hv64 > > xc: info: VIRTUAL MEMORY ARRANGEMENT: > > Loader: 0000000000100000->000000000017b9ec > > TOTAL: 0000000000000000->000000003f800000 > > ENTRY ADDRESS: 0000000000100000 > > xc: info: PHYSICAL MEMORY ALLOCATION: > > 4KB PAGES: 0x0000000000000200 > > 2MB PAGES: 0x00000000000001fb > > 1GB PAGES: 0x0000000000000000 > > xc: error: panic: xc_dom_bzimageloader.c:588: xc_dom_probe_bzimage_kernel: kernel is not a bzImage: Invalid kernel FWIW I don't get this message. It seems unrelated to the issue here but makes me curious... > > Detaching after fork from child process 26888. > > [New Thread 0x7ffff7342700 (LWP 26889)] > > [Thread 0x7ffff7342700 (LWP 26889) exited] > > [New Thread 0x7ffff7342700 (LWP 26921)] > > > > Program received signal SIGSEGV, Segmentation fault. > > 0x00007ffff7bbbec5 in libxl__wait_for_device_model (gc=0x7fffffffdbb0, > > domid=22, state=0x7ffff7bc1b8c "running", starting=0x623760, > > check_callback=0, check_callback_userdata=0x0) at libxl_device.c:555 > > 555 if (starting && starting->for_spawn->fd > xs_fileno(xsh)) > > (gdb) bt > > This patch seems to fix it, but I don't know if it is a real fix or just > papering over something else. I think this is correct because starting->for_spawn is only valid if the device model was launched with libxl__spawn_spawn which is only the case for process based stubdom. libxl__create_device_model heads off into libxl__create_stubdom for this case and explicitly sets for_spawn == NULL. Hmm, actually this function never uses starting except to get at for_spawn perhaps we should just pass in the for_spawn directly. Patch to that effect follows. Ian. ps: can you add this to your ~/.hgrc please: [diff] showfunc = True 8<----------------------------------------------- # HG changeset patch # User Ian Campbell <ian.campbell@citrix.com> # Date 1316595312 -3600 # Node ID eb9330c89fd3843ff0b1348b0ef21cfeb22d4a76 # Parent 21db7a7dd18483aab5c651f2364c09e8e492d7b1 libxl: make libxl__wait_for_device_model use libxl__spawn_starrting directly Instead of indirecting via libxl_device_model_starting. This fixes a segmentation fault using stubdomains where starting->for_spawn is (validly) NULL because starting a stubdom doesn't need to spawn a process. Most callers of libxl__wait_for_device_model already pass NULL for this variable (because they are not on the starting path) so on libxl__confirm_device_model_startup needs to change. Reported-by: Jeremy Fitzhardinge <jeremy@goop.org> Signed-off-by: Ian Campbell <ian.campbell@citrix.com> diff -r 21db7a7dd184 -r eb9330c89fd3 tools/libxl/libxl_device.c --- a/tools/libxl/libxl_device.c Tue Sep 20 16:50:44 2011 +0100 +++ b/tools/libxl/libxl_device.c Wed Sep 21 09:55:12 2011 +0100 @@ -528,7 +528,7 @@ out: int libxl__wait_for_device_model(libxl__gc *gc, uint32_t domid, char *state, - libxl__device_model_starting *starting, + libxl__spawn_starting *spawning, int (*check_callback)(libxl__gc *gc, uint32_t domid, const char *state, @@ -558,12 +558,12 @@ int libxl__wait_for_device_model(libxl__ tv.tv_sec = LIBXL_DEVICE_MODEL_START_TIMEOUT; tv.tv_usec = 0; nfds = xs_fileno(xsh) + 1; - if (starting && starting->for_spawn->fd > xs_fileno(xsh)) - nfds = starting->for_spawn->fd + 1; + if (spawning && spawning->fd > xs_fileno(xsh)) + nfds = spawning->fd + 1; while (rc > 0 || (!rc && tv.tv_sec > 0)) { - if ( starting ) { - rc = libxl__spawn_check(gc, starting->for_spawn); + if ( spawning ) { + rc = libxl__spawn_check(gc, spawning); if ( rc ) { LIBXL__LOG(ctx, LIBXL__LOG_ERROR, "Device Model died during startup"); @@ -592,8 +592,8 @@ again: free(p); FD_ZERO(&rfds); FD_SET(xs_fileno(xsh), &rfds); - if (starting) - FD_SET(starting->for_spawn->fd, &rfds); + if (spawning) + FD_SET(spawning->fd, &rfds); rc = select(nfds, &rfds, NULL, NULL, &tv); if (rc > 0) { if (FD_ISSET(xs_fileno(xsh), &rfds)) { @@ -603,9 +603,9 @@ again: else goto again; } - if (starting && FD_ISSET(starting->for_spawn->fd, &rfds)) { + if (spawning && FD_ISSET(spawning->fd, &rfds)) { unsigned char dummy; - if (read(starting->for_spawn->fd, &dummy, sizeof(dummy)) != 1) + if (read(spawning->fd, &dummy, sizeof(dummy)) != 1) LIBXL__LOG_ERRNO(ctx, LIBXL__LOG_DEBUG, "failed to read spawn status pipe"); } diff -r 21db7a7dd184 -r eb9330c89fd3 tools/libxl/libxl_dm.c --- a/tools/libxl/libxl_dm.c Tue Sep 20 16:50:44 2011 +0100 +++ b/tools/libxl/libxl_dm.c Wed Sep 21 09:55:12 2011 +0100 @@ -934,7 +934,7 @@ int libxl__confirm_device_model_startup( { int detach; int problem = libxl__wait_for_device_model(gc, starting->domid, "running", - starting, NULL, NULL); + starting->for_spawn, NULL, NULL); detach = detach_device_model(gc, starting); return problem ? problem : detach; } diff -r 21db7a7dd184 -r eb9330c89fd3 tools/libxl/libxl_internal.h --- a/tools/libxl/libxl_internal.h Tue Sep 20 16:50:44 2011 +0100 +++ b/tools/libxl/libxl_internal.h Wed Sep 21 09:55:12 2011 +0100 @@ -288,7 +288,7 @@ _hidden int libxl__confirm_device_model_ _hidden int libxl__detach_device_model(libxl__gc *gc, libxl__device_model_starting *starting); _hidden int libxl__wait_for_device_model(libxl__gc *gc, uint32_t domid, char *state, - libxl__device_model_starting *starting, + libxl__spawn_starting *spawning, int (*check_callback)(libxl__gc *gc, uint32_t domid, const char *state, _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel From xen-devel-bounces@lists.xensource.com Wed Sep 21 02:12:07 2011 Return-path: <xen-devel-bounces@lists.xensource.com> Envelope-to: www-data@lists.xensource.com Delivery-date: Wed, 21 Sep 2011 02:12:07 -0700 Received: from localhost ([127.0.0.1] helo=lists.colo.xensource.com) by lists.xensource.com with esmtp (Exim 4.43) id 1R6Iqd-0001C7-Kb; Wed, 21 Sep 2011 02:12:07 -0700 Received: from mail216.messagelabs.com ([85.158.143.99]) by lists.xensource.com with esmtp (Exim 4.43) id 1R6Imd-0008MK-Og; Wed, 21 Sep 2011 02:08:03 -0700 X-Env-Sender: Ian.Campbell@eu.citrix.com X-Msg-Ref: server-13.tower-216.messagelabs.com!1316596076!19066938!1 X-Originating-IP: [62.200.22.115] X-StarScan-Version: 6.4.1; banners=-,-,- X-VirusChecked: Checked Received: (qmail 12333 invoked from network); 21 Sep 2011 09:07:56 -0000 Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115) by server-13.tower-216.messagelabs.com with RC4-SHA encrypted SMTP; 21 Sep 2011 09:07:56 -0000 X-IronPort-AV: E=Sophos;i="4.68,416,1312156800"; d="scan'208";a="7971673" Received: from lonpmailmx01.citrite.net ([10.30.203.162]) by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5; 21 Sep 2011 09:07:56 +0000 Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net (10.30.203.162) with Microsoft SMTP Server id 8.3.137.0; Wed, 21 Sep 2011 10:07:56 +0100 Subject: Re: [Xen-devel] [Xen-users] kernel panic in domU From: Ian Campbell <Ian.Campbell@citrix.com> To: jinho hwang <hwang.jinho@gmail.com> Date: Wed, 21 Sep 2011 10:07:56 +0100 In-Reply-To: <CAPQGAnGxTOUTb_9kQnevY99U5CiEcFTeGLtZUUvrRb2ETkg7iw@mail.gmail.com> References: <CAPQGAnFCgAn8h-wmcM-syJEP-g0fOr739HkwvF1RqRXZ=hzF+Q@mail.gmail.com> <4E793EC5.20209@goop.org> <CAPQGAnGxTOUTb_9kQnevY99U5CiEcFTeGLtZUUvrRb2ETkg7iw@mail.gmail.com> Organization: Citrix Systems, Inc. Content-Type: text/plain; charset="UTF-8" X-Mailer: Evolution 3.0.3- Content-Transfer-Encoding: 7bit Message-ID: <1316596076.3891.112.camel@zakaz.uk.xensource.com> MIME-Version: 1.0 Cc: Jeremy Fitzhardinge <jeremy@goop.org>, "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>, "xen-users@lists.xensource.com" <xen-users@lists.xensource.com> X-BeenThere: xen-devel@lists.xensource.com X-Mailman-Version: 2.1.5 Precedence: list List-Id: Xen developer discussion <xen-devel.lists.xensource.com> List-Unsubscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe> List-Post: <mailto:xen-devel@lists.xensource.com> List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help> List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=subscribe> Sender: xen-devel-bounces@lists.xensource.com Errors-To: xen-devel-bounces@lists.xensource.com Please don't top-post. See http://wiki.xen.org/xenwiki/ReportingBugs for other list-etiquette pointers. On Wed, 2011-09-21 at 03:18 +0100, jinho hwang wrote: > Thanks for replay. This is my fstab. Do I have to do something else > for mounting? Do you have the necessary filesystem for xvda2 either builtin or modular and loaded in your initramfs? Are you sure /sbin/init exists in that filesystem? Please mount it in dom0 and check. Do you have the necessary personalty to run the binary? For example a 64 bit kernel with a 32 bit userspace will need CONFIG_IA32_EMULATION. While you have the filesystem mounted in dom0 can you run "file $MNT/sbin/init" to confirm what sort of binary it is. Does using init=/bin/sh work for you? Failing all that perhaps you can use whatever (distro-specific) mechanism that is provided to allow you to break into a shell in the initramfs and check out what it is doing, which modules it is loading etc etc. You appear to be using Debian so I think "break=init" on the kernel command line will cause you to drop to a shell just before launching /sbin/init. If none of this helps please post your guest config file and your kernel config. Ian. _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel From xen-devel-bounces@lists.xensource.com Wed Sep 21 02:25:08 2011 Return-path: <xen-devel-bounces@lists.xensource.com> Envelope-to: www-data@lists.xensource.com Delivery-date: Wed, 21 Sep 2011 02:25:08 -0700 Received: from localhost ([127.0.0.1] helo=lists.colo.xensource.com) by lists.xensource.com with esmtp (Exim 4.43) id 1R6J3D-0003H5-SO; Wed, 21 Sep 2011 02:25:07 -0700 Received: from mail27.messagelabs.com ([193.109.254.147]) by lists.xensource.com with esmtp (Exim 4.43) id 1R6J2n-00034h-Ft for xen-devel@lists.xensource.com; Wed, 21 Sep 2011 02:24:41 -0700 X-Env-Sender: Ian.Campbell@eu.citrix.com X-Msg-Ref: server-10.tower-27.messagelabs.com!1316597058!36615026!1 X-Originating-IP: [62.200.22.115] X-StarScan-Version: 6.4.1; banners=-,-,- X-VirusChecked: Checked Received: (qmail 24105 invoked from network); 21 Sep 2011 09:24:18 -0000 Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115) by server-10.tower-27.messagelabs.com with RC4-SHA encrypted SMTP; 21 Sep 2011 09:24:18 -0000 X-IronPort-AV: E=Sophos;i="4.68,416,1312156800"; d="scan'208";a="7972422" Received: from lonpmailmx01.citrite.net ([10.30.203.162]) by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5; 21 Sep 2011 09:24:38 +0000 Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net (10.30.203.162) with Microsoft SMTP Server id 8.3.137.0; Wed, 21 Sep 2011 10:24:37 +0100 Subject: Re: [Xen-devel] [PATCH] xenpaging: libxl support From: Ian Campbell <Ian.Campbell@citrix.com> To: Olaf Hering <olaf@aepfle.de> Date: Wed, 21 Sep 2011 10:24:36 +0100 In-Reply-To: <c9a9779fd9581666c327.1316100011@probook.site> References: <c9a9779fd9581666c327.1316100011@probook.site> Organization: Citrix Systems, Inc. Content-Type: text/plain; charset="UTF-8" X-Mailer: Evolution 3.0.3- Content-Transfer-Encoding: 7bit Message-ID: <1316597077.3891.124.camel@zakaz.uk.xensource.com> MIME-Version: 1.0 Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com> X-BeenThere: xen-devel@lists.xensource.com X-Mailman-Version: 2.1.5 Precedence: list List-Id: Xen developer discussion <xen-devel.lists.xensource.com> List-Unsubscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe> List-Post: <mailto:xen-devel@lists.xensource.com> List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help> List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=subscribe> Sender: xen-devel-bounces@lists.xensource.com Errors-To: xen-devel-bounces@lists.xensource.com On Thu, 2011-09-15 at 16:20 +0100, Olaf Hering wrote: > # HG changeset patch > # User Olaf Hering <olaf@aepfle.de> > # Date 1316099907 -7200 > # Node ID c9a9779fd9581666c3276f95020ad12e8ceff930 > # Parent 7fb21fac6d7d0a20a7af9aa2caa6fb4145ee3e23 > xenpaging: libxl support > > Add support to libxl for starting xenpaging, I send it out for review. > It mimics what the code to start qemu-dm does. > > The patch adds four new config options: > xenpaging=<int> , the number of pages to page-out > xenpaging_dir=<string>, the working directory where the pagefile is stored > xenpaging_debug=<int>, enable or disable debug output > xenpaging_policy_mru_size=<int>, tweak the number of most-recently-used pages > > There are still a few pieces missing like 'xl list -l'. > > Signed-off-by: Olaf Hering <olaf@aepfle.de> > > diff -r 7fb21fac6d7d -r c9a9779fd958 tools/libxl/libxl.h > --- a/tools/libxl/libxl.h > +++ b/tools/libxl/libxl.h > @@ -229,6 +229,7 @@ typedef struct { > libxl_domain_create_info c_info; > libxl_domain_build_info b_info; > libxl_device_model_info dm_info; > + libxl_xenpaging_info xp_info; > > int num_disks, num_vifs, num_pcidevs, num_vfbs, num_vkbs; > > diff -r 7fb21fac6d7d -r c9a9779fd958 tools/libxl/libxl.idl > --- a/tools/libxl/libxl.idl > +++ b/tools/libxl/libxl.idl > @@ -190,6 +190,17 @@ by libxl_domain_build/restore. If either > then the user is responsible for calling > libxl_file_reference_unmap.""") > > +libxl_xenpaging_info = Struct("xenpaging_info",[ I'm not convinced this needs to be it's own struct (rather than being part of e.g. build_info or create_info) but I don't feel particularly strongly one way or the other. > + ("xenpaging", integer, False, "number of pages"), > + ("xenpaging_workdir", string, False, "directory to store guest page file"), Really a directory or actually a file? xenpaging_path would probably be a nicer name. > + ("xenpaging_debug", bool, False, "enable debug output in pager"), Perhaps a generic "extra_arguments" type field (string) would be more useful? > + ("xenpaging_policy_mru_size", integer, False, "number of paged-in pages to keep in memory"), How is the distinct from / related to the xenpaging integer? > + ], > + comment= > +"""xenpaging information. > + > +Something review is missing""") > + > libxl_device_model_info = Struct("device_model_info",[ > ("domid", libxl_domid), > ("uuid", libxl_uuid, False, "this is use only with stubdom, and must be different from the domain uuid"), > diff -r 7fb21fac6d7d -r c9a9779fd958 tools/libxl/libxl_create.c > --- a/tools/libxl/libxl_create.c > +++ b/tools/libxl/libxl_create.c > @@ -429,6 +429,109 @@ retry_transaction: > return rc; > } > > +static void xp_xenstore_record_pid(void *for_spawn, pid_t innerchild) > +{ > + libxl__device_model_starting *starting = for_spawn; Do you mean libxl__xenpaging_starting here? It looks like xp_xenstore_record_pid could be shared with the dm one with only a little refactoring/abstraction. > +static int libxl__create_xenpaging(libxl__gc *gc, char *dom_name, uint32_t domid, libxl_xenpaging_info *xp_info) > +{ > [...] > + /* Set working directory if not specified in config file */ > + if (!xp_info->xenpaging_workdir) > + xp_info->xenpaging_workdir = "/var/lib/xen/xenpaging"; Should come from libxl_paths, see e.g. libxl_sbindir_path(). > + /* Spawn the child */ > + rc = libxl__spawn_spawn(gc, NULL, "xenpaging", xp_xenstore_record_pid, &buf_starting); No libxl__spawn_starting argument. Do you handle failure to exec etc? I wonder if we should make that argument to spawn_spawn mandatory? > + if (rc < 0) > + goto out_close; > + if (!rc) { /* inner child */ > + setsid(); > + /* Enable debug output in the child */ > + if (xp_info->xenpaging_debug) > + setenv("XENPAGING_DEBUG", "1", 1); > + /* Adjust most-recently-used value in the child */ > + if (xp_info->xenpaging_policy_mru_size) > + setenv("XENPAGING_POLICY_MRU_SIZE", libxl__sprintf(gc, "%d", xp_info->xenpaging_policy_mru_size), 1); I think the xenpaging binary should have a proper command line interface rather than passing them via the environment. In the case of the policy mru size perhaps that should be in xenstore such that it can be changed on the fly? > diff -r 7fb21fac6d7d -r c9a9779fd958 tools/libxl/libxl_internal.h > --- a/tools/libxl/libxl_internal.h > +++ b/tools/libxl/libxl_internal.h > @@ -251,6 +251,11 @@ typedef struct { > libxl__spawn_starting *for_spawn; > } libxl__device_model_starting; > > +typedef struct { > + char *dom_path; /* from libxl_malloc, only for xp_xenstore_record_pid */ > + int domid; > +} libxl__xenpaging_starting; > + > /* from xl_create */ > _hidden int libxl__domain_make(libxl__gc *gc, libxl_domain_create_info *info, uint32_t *domid); > _hidden int libxl__domain_build(libxl__gc *gc, > diff -r 7fb21fac6d7d -r c9a9779fd958 tools/libxl/xl_cmdimpl.c > --- a/tools/libxl/xl_cmdimpl.c > +++ b/tools/libxl/xl_cmdimpl.c > @@ -290,6 +290,7 @@ static void dolog(const char *file, int > > static void printf_info(int domid, > libxl_domain_config *d_config, > + libxl_xenpaging_info *xp_info, xp_info is d_config->xpo_info or something isn't it? I'm not sure why dm_info is called out specially though. I think perhaps because of stubdomains there can be more than one so we need to pass round the relevant one for the context. Or maybe it's just a historical wart. In either case it doesn't really apply to the xp_info. > libxl_device_model_info *dm_info) > { > int i; > @@ -519,6 +520,7 @@ static void parse_config_data(const char > const char *configfile_data, > int configfile_len, > libxl_domain_config *d_config, > + libxl_xenpaging_info *xp_info, Same comment as above. Did I miss a call to libxl_xenpaging_info_destroy() somewhere or does this leak? Ian. _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel From xen-devel-bounces@lists.xensource.com Wed Sep 21 02:27:59 2011 Return-path: <xen-devel-bounces@lists.xensource.com> Envelope-to: www-data@lists.xensource.com Delivery-date: Wed, 21 Sep 2011 02:27:59 -0700 Received: from localhost ([127.0.0.1] helo=lists.colo.xensource.com) by lists.xensource.com with esmtp (Exim 4.43) id 1R6J5y-0003fX-UI; Wed, 21 Sep 2011 02:27:58 -0700 Received: from mail174.messagelabs.com ([85.158.138.51]) by lists.xensource.com with esmtp (Exim 4.43) id 1R6J52-0003T7-6P for xen-devel@lists.xensource.com; Wed, 21 Sep 2011 02:27:00 -0700 X-Env-Sender: Ian.Campbell@eu.citrix.com X-Msg-Ref: server-5.tower-174.messagelabs.com!1316597216!28517110!1 X-Originating-IP: [62.200.22.115] X-StarScan-Version: 6.4.1; banners=-,-,- X-VirusChecked: Checked Received: (qmail 19094 invoked from network); 21 Sep 2011 09:26:57 -0000 Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115) by server-5.tower-174.messagelabs.com with RC4-SHA encrypted SMTP; 21 Sep 2011 09:26:57 -0000 X-IronPort-AV: E=Sophos;i="4.68,416,1312156800"; d="scan'208";a="7972510" Received: from lonpmailmx01.citrite.net ([10.30.203.162]) by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5; 21 Sep 2011 09:26:56 +0000 Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net (10.30.203.162) with Microsoft SMTP Server id 8.3.137.0; Wed, 21 Sep 2011 10:26:56 +0100 Subject: Re: [Xen-devel] [PATCH] xenpaging: track number of paged pages in struct domain From: Ian Campbell <Ian.Campbell@citrix.com> To: Tim Deegan <tim@xen.org> Date: Wed, 21 Sep 2011 10:26:56 +0100 In-Reply-To: <20110916112403.GB95880@ocelot.phlegethon.org> References: <13b4be345ebac016abe2.1316089567@probook.site> <20110916112403.GB95880@ocelot.phlegethon.org> Organization: Citrix Systems, Inc. Content-Type: text/plain; charset="UTF-8" X-Mailer: Evolution 3.0.3- Content-Transfer-Encoding: 7bit Message-ID: <1316597216.3891.125.camel@zakaz.uk.xensource.com> MIME-Version: 1.0 Cc: Olaf Hering <olaf@aepfle.de>, "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com> X-BeenThere: xen-devel@lists.xensource.com X-Mailman-Version: 2.1.5 Precedence: list List-Id: Xen developer discussion <xen-devel.lists.xensource.com> List-Unsubscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe> List-Post: <mailto:xen-devel@lists.xensource.com> List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help> List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=subscribe> Sender: xen-devel-bounces@lists.xensource.com Errors-To: xen-devel-bounces@lists.xensource.com On Fri, 2011-09-16 at 12:24 +0100, Tim Deegan wrote: > At 14:26 +0200 on 15 Sep (1316096767), Olaf Hering wrote: > > # HG changeset patch > > # User Olaf Hering <olaf@aepfle.de> > > # Date 1316089500 -7200 > > # Node ID 13b4be345ebac016abe26386417824a0c47d762d > > # Parent e90438f6e6d1585a71b18784a99c162b5d95f390 > > xenpaging: track number of paged pages in struct domain > > > > The toolstack should know how many pages are paged-out at a given point > > in time so it could make smarter decisions about how many pages should > > be paged or ballooned. > > > > Add a new member to xen_domctl_getdomaininfo and bump interface version. > > Use the new member in xc_dominfo_t. > > The SONAME of libxc should be changed if this patch gets applied. > > > > Signed-off-by: Olaf Hering <olaf@aepfle.de> > > For the xen parts, Acked-by: Tim Deegan <tim@xen.org> > > Again, I'd like the tools maintainers to ack/nack the change to the domctl > interface and associated libxc plumbing. They look alright to me: Acked-by: Ian Campbell <ian.campbell@citrix.com> _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel From xen-devel-bounces@lists.xensource.com Wed Sep 21 02:33:02 2011 Return-path: <xen-devel-bounces@lists.xensource.com> Envelope-to: www-data@lists.xensource.com Delivery-date: Wed, 21 Sep 2011 02:33:02 -0700 Received: from localhost ([127.0.0.1] helo=lists.colo.xensource.com) by lists.xensource.com with esmtp (Exim 4.43) id 1R6JAs-0004AW-5p; Wed, 21 Sep 2011 02:33:02 -0700 Received: from mail182.messagelabs.com ([85.158.139.83]) by lists.xensource.com with esmtp (Exim 4.43) id 1R6JAE-0003xU-43 for xen-devel@lists.xensource.com; Wed, 21 Sep 2011 02:32:22 -0700 X-Env-Sender: yong.zhang0@gmail.com X-Msg-Ref: server-8.tower-182.messagelabs.com!1316597539!19173684!1 X-Originating-IP: [74.125.82.176] X-StarScan-Version: 6.4.1; banners=-,-,- X-VirusChecked: Checked Received: (qmail 4526 invoked from network); 21 Sep 2011 09:32:19 -0000 Received: from mail-wy0-f176.google.com (HELO mail-wy0-f176.google.com) (74.125.82.176) by server-8.tower-182.messagelabs.com with RC4-SHA encrypted SMTP; 21 Sep 2011 09:32:19 -0000 Received: by wyg10 with SMTP id 10so2067595wyg.7 for <xen-devel@lists.xensource.com>; Wed, 21 Sep 2011 02:32:18 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=from:to:cc:subject:date:message-id:x-mailer:in-reply-to:references; bh=mA75JrCOKiY8aa1z1JX09uXSaoTAEQtelxZlmabQNS8=; b=YEQVyexKmR1xjcnps08P4rz5EvMMP89MHX7NvSEj0jmB0PFw92cfdfYN6plxGbxIqz hNh2Ren1tncEx9ZItBQu6QBY0wlegV40YjnotOpNiGZfxtdicW2q/w2BfV6lJfgUbIS3 ywdjP4C8mLwQkOLEFyWpqu/Oi+w6LfQDASsA0= Received: by 10.227.204.14 with SMTP id fk14mr438122wbb.88.1316597538356; Wed, 21 Sep 2011 02:32:18 -0700 (PDT) Received: from localhost ([61.148.56.138]) by mx.google.com with ESMTPS id o7sm6161635wbh.8.2011.09.21.02.32.16 (version=TLSv1/SSLv3 cipher=OTHER); Wed, 21 Sep 2011 02:32:17 -0700 (PDT) From: Yong Zhang <yong.zhang0@gmail.com> To: linux-arch@vger.kernel.org, linux-kernel@vger.kernel.org Date: Wed, 21 Sep 2011 17:28:22 +0800 Message-Id: <1316597339-29861-22-git-send-email-yong.zhang0@gmail.com> X-Mailer: git-send-email 1.7.4.1 In-Reply-To: <1316597339-29861-1-git-send-email-yong.zhang0@gmail.com> References: <1316597339-29861-1-git-send-email-yong.zhang0@gmail.com> Cc: xen-devel@lists.xensource.com, "Venkatesh Pallipadi \(Venki\)" <venki@google.com>, Jeremy Fitzhardinge <jeremy.fitzhardinge@citrix.com>, Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>, x86@kernel.org, Paul Gortmaker <paul.gortmaker@windriver.com>, Ralf Baechle <ralf@linux-mips.org>, virtualization@lists.linux-foundation.org, yong.zhang0@gmail.com, Ingo Molnar <mingo@redhat.com>, "H. Peter Anvin" <hpa@zytor.com>, tglx@linutronix.de, Andrew Morton <akpm@linux-foundation.org> Subject: [Xen-devel] [PATCH 21/57] x86: irq: Remove IRQF_DISABLED X-BeenThere: xen-devel@lists.xensource.com X-Mailman-Version: 2.1.5 Precedence: list List-Id: Xen developer discussion <xen-devel.lists.xensource.com> List-Unsubscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe> List-Post: <mailto:xen-devel@lists.xensource.com> List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help> List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=subscribe> Sender: xen-devel-bounces@lists.xensource.com Errors-To: xen-devel-bounces@lists.xensource.com Since commit [c58543c8: genirq: Run irq handlers with interrupts disabled], We run all interrupt handlers with interrupts disabled and we even check and yell when an interrupt handler returns with interrupts enabled (see commit [b738a50a: genirq: Warn when handler enables interrupts]). So now this flag is a NOOP and can be removed. Signed-off-by: Yong Zhang <yong.zhang0@gmail.com> --- arch/x86/include/asm/floppy.h | 4 ++-- arch/x86/kernel/hpet.c | 2 +- arch/x86/kernel/time.c | 2 +- arch/x86/xen/smp.c | 8 ++++---- arch/x86/xen/spinlock.c | 2 +- arch/x86/xen/time.c | 5 ++--- 6 files changed, 11 insertions(+), 12 deletions(-) diff --git a/arch/x86/include/asm/floppy.h b/arch/x86/include/asm/floppy.h index dbe82a5..22bf4d6 100644 --- a/arch/x86/include/asm/floppy.h +++ b/arch/x86/include/asm/floppy.h @@ -145,10 +145,10 @@ static int fd_request_irq(void) { if (can_use_virtual_dma) return request_irq(FLOPPY_IRQ, floppy_hardint, - IRQF_DISABLED, "floppy", NULL); + 0, "floppy", NULL); else return request_irq(FLOPPY_IRQ, floppy_interrupt, - IRQF_DISABLED, "floppy", NULL); + 0, "floppy", NULL); } static unsigned long dma_mem_alloc(unsigned long size) diff --git a/arch/x86/kernel/hpet.c b/arch/x86/kernel/hpet.c index b946a9e..5c21a30 100644 --- a/arch/x86/kernel/hpet.c +++ b/arch/x86/kernel/hpet.c @@ -516,7 +516,7 @@ static int hpet_setup_irq(struct hpet_dev *dev) { if (request_irq(dev->irq, hpet_interrupt_handler, - IRQF_TIMER | IRQF_DISABLED | IRQF_NOBALANCING, + IRQF_TIMER | IRQF_NOBALANCING, dev->name, dev)) return -1; diff --git a/arch/x86/kernel/time.c b/arch/x86/kernel/time.c index 25046df..0c3fc9a 100644 --- a/arch/x86/kernel/time.c +++ b/arch/x86/kernel/time.c @@ -55,7 +55,7 @@ EXPORT_SYMBOL(profile_pc); static irqreturn_t timer_interrupt(int irq, void *dev_id); static struct irqaction irq0 = { .handler = timer_interrupt, - .flags = IRQF_DISABLED | IRQF_NOBALANCING | IRQF_IRQPOLL | IRQF_TIMER, + .flags = IRQF_NOBALANCING | IRQF_IRQPOLL | IRQF_TIMER, .name = "timer" }; diff --git a/arch/x86/xen/smp.c b/arch/x86/xen/smp.c index 041d4fe..a375a75 100644 --- a/arch/x86/xen/smp.c +++ b/arch/x86/xen/smp.c @@ -100,7 +100,7 @@ static int xen_smp_intr_init(unsigned int cpu) rc = bind_ipi_to_irqhandler(XEN_RESCHEDULE_VECTOR, cpu, xen_reschedule_interrupt, - IRQF_DISABLED|IRQF_PERCPU|IRQF_NOBALANCING, + IRQF_PERCPU|IRQF_NOBALANCING, resched_name, NULL); if (rc < 0) @@ -111,7 +111,7 @@ static int xen_smp_intr_init(unsigned int cpu) rc = bind_ipi_to_irqhandler(XEN_CALL_FUNCTION_VECTOR, cpu, xen_call_function_interrupt, - IRQF_DISABLED|IRQF_PERCPU|IRQF_NOBALANCING, + IRQF_PERCPU|IRQF_NOBALANCING, callfunc_name, NULL); if (rc < 0) @@ -120,7 +120,7 @@ static int xen_smp_intr_init(unsigned int cpu) debug_name = kasprintf(GFP_KERNEL, "debug%d", cpu); rc = bind_virq_to_irqhandler(VIRQ_DEBUG, cpu, xen_debug_interrupt, - IRQF_DISABLED | IRQF_PERCPU | IRQF_NOBALANCING, + IRQF_PERCPU | IRQF_NOBALANCING, debug_name, NULL); if (rc < 0) goto fail; @@ -130,7 +130,7 @@ static int xen_smp_intr_init(unsigned int cpu) rc = bind_ipi_to_irqhandler(XEN_CALL_FUNCTION_SINGLE_VECTOR, cpu, xen_call_function_single_interrupt, - IRQF_DISABLED|IRQF_PERCPU|IRQF_NOBALANCING, + IRQF_PERCPU|IRQF_NOBALANCING, callfunc_name, NULL); if (rc < 0) diff --git a/arch/x86/xen/spinlock.c b/arch/x86/xen/spinlock.c index cc9b1e1..27882f5 100644 --- a/arch/x86/xen/spinlock.c +++ b/arch/x86/xen/spinlock.c @@ -354,7 +354,7 @@ void __cpuinit xen_init_lock_cpu(int cpu) irq = bind_ipi_to_irqhandler(XEN_SPIN_UNLOCK_VECTOR, cpu, dummy_handler, - IRQF_DISABLED|IRQF_PERCPU|IRQF_NOBALANCING, + IRQF_PERCPU|IRQF_NOBALANCING, name, NULL); diff --git a/arch/x86/xen/time.c b/arch/x86/xen/time.c index 0296a95..9157113 100644 --- a/arch/x86/xen/time.c +++ b/arch/x86/xen/time.c @@ -408,9 +408,8 @@ void xen_setup_timer(int cpu) name = "<timer kasprintf failed>"; irq = bind_virq_to_irqhandler(VIRQ_TIMER, cpu, xen_timer_interrupt, - IRQF_DISABLED|IRQF_PERCPU| - IRQF_NOBALANCING|IRQF_TIMER| - IRQF_FORCE_RESUME, + IRQF_PERCPU|IRQF_NOBALANCING| + IRQF_TIMER|IRQF_FORCE_RESUME, name, NULL); evt = &per_cpu(xen_clock_events, cpu); -- 1.7.4.1 _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel From xen-devel-bounces@lists.xensource.com Wed Sep 21 02:35:48 2011 Return-path: <xen-devel-bounces@lists.xensource.com> Envelope-to: www-data@lists.xensource.com Delivery-date: Wed, 21 Sep 2011 02:35:48 -0700 Received: from localhost ([127.0.0.1] helo=lists.colo.xensource.com) by lists.xensource.com with esmtp (Exim 4.43) id 1R6JDX-0004Zt-Vi; Wed, 21 Sep 2011 02:35:48 -0700 Received: from mail21.messagelabs.com ([85.158.143.35]) by lists.xensource.com with esmtp (Exim 4.43) id 1R6JCo-0004N3-VW for xen-devel@lists.xensource.com; Wed, 21 Sep 2011 02:35:03 -0700 X-Env-Sender: Ian.Campbell@eu.citrix.com X-Msg-Ref: server-2.tower-21.messagelabs.com!1316597698!34915183!1 X-Originating-IP: [62.200.22.115] X-StarScan-Version: 6.4.1; banners=-,-,- X-VirusChecked: Checked Received: (qmail 7242 invoked from network); 21 Sep 2011 09:34:58 -0000 Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115) by server-2.tower-21.messagelabs.com with RC4-SHA encrypted SMTP; 21 Sep 2011 09:34:58 -0000 X-IronPort-AV: E=Sophos;i="4.68,416,1312156800"; d="scan'208";a="7972768" Received: from lonpmailmx01.citrite.net ([10.30.203.162]) by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5; 21 Sep 2011 09:34:59 +0000 Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net (10.30.203.162) with Microsoft SMTP Server id 8.3.137.0; Wed, 21 Sep 2011 10:34:59 +0100 Subject: Re: [Xen-devel] [PATCH] expose shared page count through xenlight From: Ian Campbell <Ian.Campbell@citrix.com> To: Adin Scannell <adin@gridcentric.com> Date: Wed, 21 Sep 2011 10:34:59 +0100 In-Reply-To: <CAAJKtqpMqpWckNY=a9HrNZY8hT+cmH8odyLM2HKctSMY63=RRA@mail.gmail.com> References: <CAAJKtqpMqpWckNY=a9HrNZY8hT+cmH8odyLM2HKctSMY63=RRA@mail.gmail.com> Organization: Citrix Systems, Inc. Content-Type: text/plain; charset="UTF-8" X-Mailer: Evolution 3.0.3- Content-Transfer-Encoding: 7bit Message-ID: <1316597699.3891.130.camel@zakaz.uk.xensource.com> MIME-Version: 1.0 Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com> X-BeenThere: xen-devel@lists.xensource.com X-Mailman-Version: 2.1.5 Precedence: list List-Id: Xen developer discussion <xen-devel.lists.xensource.com> List-Unsubscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe> List-Post: <mailto:xen-devel@lists.xensource.com> List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help> List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=subscribe> Sender: xen-devel-bounces@lists.xensource.com Errors-To: xen-devel-bounces@lists.xensource.com Hi Adin, On Thu, 2011-09-15 at 13:17 +0100, Adin Scannell wrote: > Attached is a simple patch to expose the shared page information > through libxl and xl. I think this is generally fine but I'm a bit concerned that the "xl list" output is now > 80 characters long by default. Can we only print this info in verbose mode, or only if >=1 domain has shared pages or something? I don't suppose just printing the total number of shared pages across the system is as useful as printing the nr for each domain? Perhaps we need a get-meminfo type command to get all the various memory stats for a domain, e.g. sharing, ballooning, paging etc? Also, was the change from \t to explicit padding in the header intentional? I agree it's a bit odd to use \t in the header and spaces in the actual info lines. Ian. _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel From xen-devel-bounces@lists.xensource.com Wed Sep 21 02:37:10 2011 Return-path: <xen-devel-bounces@lists.xensource.com> Envelope-to: www-data@lists.xensource.com Delivery-date: Wed, 21 Sep 2011 02:37:10 -0700 Received: from localhost ([127.0.0.1] helo=lists.colo.xensource.com) by lists.xensource.com with esmtp (Exim 4.43) id 1R6JEs-0004zT-2O; Wed, 21 Sep 2011 02:37:10 -0700 Received: from mail182.messagelabs.com ([85.158.139.83]) by lists.xensource.com with esmtp (Exim 4.43) id 1R6JEB-0004ka-IZ for xen-devel@lists.xensource.com; Wed, 21 Sep 2011 02:36:28 -0700 X-Env-Sender: yong.zhang0@gmail.com X-Msg-Ref: server-14.tower-182.messagelabs.com!1316597784!18999674!1 X-Originating-IP: [209.85.215.171] X-StarScan-Version: 6.4.1; banners=-,-,- X-VirusChecked: Checked Received: (qmail 881 invoked from network); 21 Sep 2011 09:36:24 -0000 Received: from mail-ey0-f171.google.com (HELO mail-ey0-f171.google.com) (209.85.215.171) by server-14.tower-182.messagelabs.com with RC4-SHA encrypted SMTP; 21 Sep 2011 09:36:24 -0000 Received: by eye3 with SMTP id 3so1115507eye.30 for <xen-devel@lists.xensource.com>; Wed, 21 Sep 2011 02:36:24 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=from:to:cc:subject:date:message-id:x-mailer:in-reply-to:references; bh=BTGQQbE0dvSLUhWl2yVoiaypmZoubC3oxVrvBFSW6Wk=; b=PizzJc94ZqIGa8lf0iwFMDFF7opEn5VAdsblnq+TNWDSm7K2+dJ2Y/H8CNVCwhZB1u Za3L7hXcVerVm3/QquyV5c2ezM2o7/xRA9YSZovboW+q5wWShQgDNSr8kV00qG6hLH8u 2U9AlYMP/672egrhW0MRjDrqKy5IhR9O/r7N0= Received: by 10.216.203.168 with SMTP id f40mr1977955weo.6.1316597784280; Wed, 21 Sep 2011 02:36:24 -0700 (PDT) Received: from localhost ([61.148.56.138]) by mx.google.com with ESMTPS id fa7sm6139709wbb.26.2011.09.21.02.36.22 (version=TLSv1/SSLv3 cipher=OTHER); Wed, 21 Sep 2011 02:36:23 -0700 (PDT) From: Yong Zhang <yong.zhang0@gmail.com> To: linux-arch@vger.kernel.org, linux-kernel@vger.kernel.org Date: Wed, 21 Sep 2011 17:28:53 +0800 Message-Id: <1316597339-29861-53-git-send-email-yong.zhang0@gmail.com> X-Mailer: git-send-email 1.7.4.1 In-Reply-To: <1316597339-29861-1-git-send-email-yong.zhang0@gmail.com> References: <1316597339-29861-1-git-send-email-yong.zhang0@gmail.com> Cc: Jeremy Fitzhardinge <jeremy.fitzhardinge@citrix.com>, Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>, virtualization@lists.linux-foundation.org, yong.zhang0@gmail.com, xen-devel@lists.xensource.com, tglx@linutronix.de Subject: [Xen-devel] [PATCH 52/57] xen: irq: Remove IRQF_DISABLED X-BeenThere: xen-devel@lists.xensource.com X-Mailman-Version: 2.1.5 Precedence: list List-Id: Xen developer discussion <xen-devel.lists.xensource.com> List-Unsubscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe> List-Post: <mailto:xen-devel@lists.xensource.com> List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help> List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=subscribe> Sender: xen-devel-bounces@lists.xensource.com Errors-To: xen-devel-bounces@lists.xensource.com Since commit [c58543c8: genirq: Run irq handlers with interrupts disabled], We run all interrupt handlers with interrupts disabled and we even check and yell when an interrupt handler returns with interrupts enabled (see commit [b738a50a: genirq: Warn when handler enables interrupts]). So now this flag is a NOOP and can be removed. Signed-off-by: Yong Zhang <yong.zhang0@gmail.com> --- drivers/xen/evtchn.c | 2 +- drivers/xen/platform-pci.c | 2 +- 2 files changed, 2 insertions(+), 2 deletions(-) diff --git a/drivers/xen/evtchn.c b/drivers/xen/evtchn.c index dbc13e9..95e2507 100644 --- a/drivers/xen/evtchn.c +++ b/drivers/xen/evtchn.c @@ -265,7 +265,7 @@ static int evtchn_bind_to_user(struct per_user_data *u, int port) set_port_user(port, u); set_port_enabled(port, true); /* start enabled */ - rc = bind_evtchn_to_irqhandler(port, evtchn_interrupt, IRQF_DISABLED, + rc = bind_evtchn_to_irqhandler(port, evtchn_interrupt, 0, u->name, (void *)(unsigned long)port); if (rc >= 0) rc = 0; diff --git a/drivers/xen/platform-pci.c b/drivers/xen/platform-pci.c index 319dd0a..482beff 100644 --- a/drivers/xen/platform-pci.c +++ b/drivers/xen/platform-pci.c @@ -84,7 +84,7 @@ static irqreturn_t do_hvm_evtchn_intr(int irq, void *dev_id) static int xen_allocate_irq(struct pci_dev *pdev) { return request_irq(pdev->irq, do_hvm_evtchn_intr, - IRQF_DISABLED | IRQF_NOBALANCING | IRQF_TRIGGER_RISING, + IRQF_NOBALANCING | IRQF_TRIGGER_RISING, "xen-platform-pci", pdev); } -- 1.7.4.1 _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel From xen-devel-bounces@lists.xensource.com Wed Sep 21 02:45:03 2011 Return-path: <xen-devel-bounces@lists.xensource.com> Envelope-to: www-data@lists.xensource.com Delivery-date: Wed, 21 Sep 2011 02:45:03 -0700 Received: from localhost ([127.0.0.1] helo=lists.colo.xensource.com) by lists.xensource.com with esmtp (Exim 4.43) id 1R6JMV-0006FH-82; Wed, 21 Sep 2011 02:45:03 -0700 Received: from mail216.messagelabs.com ([85.158.143.99]) by lists.xensource.com with esmtp (Exim 4.43) id 1R6JJA-0005Qu-HV for xen-devel@lists.xensource.com; Wed, 21 Sep 2011 02:41:36 -0700 X-Env-Sender: Ian.Campbell@eu.citrix.com X-Msg-Ref: server-2.tower-216.messagelabs.com!1316598093!18623566!1 X-Originating-IP: [62.200.22.115] X-StarScan-Version: 6.4.1; banners=-,-,- X-VirusChecked: Checked Received: (qmail 20403 invoked from network); 21 Sep 2011 09:41:33 -0000 Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115) by server-2.tower-216.messagelabs.com with RC4-SHA encrypted SMTP; 21 Sep 2011 09:41:33 -0000 X-IronPort-AV: E=Sophos;i="4.68,416,1312156800"; d="scan'208";a="7972963" Received: from lonpmailmx01.citrite.net ([10.30.203.162]) by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5; 21 Sep 2011 09:41:33 +0000 Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net (10.30.203.162) with Microsoft SMTP Server id 8.3.137.0; Wed, 21 Sep 2011 10:41:33 +0100 Subject: Re: [Xen-devel] [PATCH 1 of 2] hotplug: add hotplug-status disconnected From: Ian Campbell <Ian.Campbell@citrix.com> To: Roger Pau Monne <roger.pau@entel.upc.edu> Date: Wed, 21 Sep 2011 10:41:33 +0100 In-Reply-To: <00949e363f6f2c70001d.1316187418@loki> References: <patchbomb.1316187417@loki> <00949e363f6f2c70001d.1316187418@loki> Organization: Citrix Systems, Inc. Content-Type: text/plain; charset="UTF-8" X-Mailer: Evolution 3.0.3- Content-Transfer-Encoding: 7bit Message-ID: <1316598093.3891.134.camel@zakaz.uk.xensource.com> MIME-Version: 1.0 Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com> X-BeenThere: xen-devel@lists.xensource.com X-Mailman-Version: 2.1.5 Precedence: list List-Id: Xen developer discussion <xen-devel.lists.xensource.com> List-Unsubscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe> List-Post: <mailto:xen-devel@lists.xensource.com> List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help> List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=subscribe> Sender: xen-devel-bounces@lists.xensource.com Errors-To: xen-devel-bounces@lists.xensource.com On Fri, 2011-09-16 at 16:36 +0100, Roger Pau Monne wrote: > # HG changeset patch > # User Roger Pau Monne <roger.pau@entel.upc.edu> > # Date 1316186985 -7200 > # Node ID 00949e363f6f2c70001da548403475628df93b97 > # Parent 63e254468d6e8d81baeafaed68f05791dc21eb4e > hotplug: add hotplug-status disconnected > > Added hotplug-status disconnected when vbd are removed. > > Signed-off-by: Roger Pau Monne <roger.pau@entel.upc.edu> > Generally looks good, but I don't think you've got the logical separation between the two patches quite right: > diff -r 63e254468d6e -r 00949e363f6f tools/xenbackendd/xenbackendd.c > --- a/tools/xenbackendd/xenbackendd.c Wed Sep 14 14:18:40 2011 +0200 > +++ b/tools/xenbackendd/xenbackendd.c Fri Sep 16 17:29:45 2011 +0200 > @@ -169,7 +172,7 @@ main(int argc, char * const argv[]) > log_file = optarg; > break; > case 'p': > - pidfile = pidfile; > + pidfile = optarg; This is an unrelated bugfix? If so please post it as such. > case 's': > vbd_script = optarg; > break; > @@ -297,11 +300,38 @@ main(int argc, char * const argv[]) > strerror(errno)); > goto next2; > } > - doexec(s, vec[XS_WATCH_PATH], sstate); > + doexec(s, vec[XS_WATCH_PATH], sstate, NULL); > break; > > case DEVTYPE_VBD: > - doexec(vbd_script, vec[XS_WATCH_PATH], sstate); > + /* check if given file is a block device or a raw image */ > + snprintf(buf, sizeof(buf), "%s/params", vec[XS_WATCH_PATH]); > + params = xs_read(xs, XBT_NULL, buf, 0); > + if(params == NULL) { > + dolog(LOG_ERR, > + "Failed to read %s (%s)", buf, strerror(errno)); > + goto next2; > + } > + if (stat(params, &stab) < 0) { > + dolog(LOG_ERR, > + "Failed to get info about %s (%s)", params, > + strerror(errno)); > + goto next3; > + } > + stype = NULL; > + if (S_ISBLK(stab.st_mode)) > + stype = "phy"; > + if (S_ISREG(stab.st_mode)) > + stype = "file"; > + if (stype == NULL) { > + dolog(LOG_ERR, > + "Failed to attach %s (not a block device or raw image)", > + params, strerror(errno)); > + goto next3; > + } > + doexec(vbd_script, vec[XS_WATCH_PATH], sstate, stype); > +next3: > + free(params); Isn't this more like part of patch 2/2? It doesn't seem to relate to the addition of the hotplug-status xenstore node. Ian. _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel From xen-devel-bounces@lists.xensource.com Wed Sep 21 02:46:39 2011 Return-path: <xen-devel-bounces@lists.xensource.com> Envelope-to: www-data@lists.xensource.com Delivery-date: Wed, 21 Sep 2011 02:46:39 -0700 Received: from localhost ([127.0.0.1] helo=lists.colo.xensource.com) by lists.xensource.com with esmtp (Exim 4.43) id 1R6JO3-0006hv-F9; Wed, 21 Sep 2011 02:46:39 -0700 Received: from mail216.messagelabs.com ([85.158.143.99]) by lists.xensource.com with esmtp (Exim 4.43) id 1R6JMQ-0006DJ-Kh for xen-devel@lists.xensource.com; Wed, 21 Sep 2011 02:44:59 -0700 X-Env-Sender: Stefano.Stabellini@eu.citrix.com X-Msg-Ref: server-3.tower-216.messagelabs.com!1316598295!18031251!1 X-Originating-IP: [62.200.22.115] X-StarScan-Version: 6.4.1; banners=-,-,- X-VirusChecked: Checked Received: (qmail 30807 invoked from network); 21 Sep 2011 09:44:55 -0000 Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115) by server-3.tower-216.messagelabs.com with RC4-SHA encrypted SMTP; 21 Sep 2011 09:44:55 -0000 X-IronPort-AV: E=Sophos;i="4.68,416,1312156800"; d="scan'208";a="7973107" Received: from lonpmailmx01.citrite.net ([10.30.203.162]) by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5; 21 Sep 2011 09:44:55 +0000 Received: from kaball.uk.xensource.com (10.80.2.59) by LONPMAILMX01.citrite.net (10.30.203.162) with Microsoft SMTP Server id 8.3.137.0; Wed, 21 Sep 2011 10:44:55 +0100 Date: Wed, 21 Sep 2011 10:44:45 +0100 From: Stefano Stabellini <stefano.stabellini@eu.citrix.com> X-X-Sender: sstabellini@kaball-desktop To: Ian Jackson <Ian.Jackson@eu.citrix.com> Subject: Re: [Xen-devel] [patch] Spelling typos fix In-Reply-To: <20088.54410.590177.546463@mariner.uk.xensource.com> Message-ID: <alpine.DEB.2.00.1109211044280.8700@kaball-desktop> References: <4E5DEAAB.8000100@goirand.fr> <20088.54410.590177.546463@mariner.uk.xensource.com> User-Agent: Alpine 2.00 (DEB 1167 2008-08-23) MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>, Thomas Goirand <thomas@goirand.fr>, Stefano Stabellini <Stefano.Stabellini@eu.citrix.com> X-BeenThere: xen-devel@lists.xensource.com X-Mailman-Version: 2.1.5 Precedence: list List-Id: Xen developer discussion <xen-devel.lists.xensource.com> List-Unsubscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe> List-Post: <mailto:xen-devel@lists.xensource.com> List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help> List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=subscribe> Sender: xen-devel-bounces@lists.xensource.com Errors-To: xen-devel-bounces@lists.xensource.com On Tue, 20 Sep 2011, Ian Jackson wrote: > Thomas Goirand writes ("[Xen-devel] [patch] Spelling typos fix"): > > Please apply this tiny patch, which is correcting 2 spelling issues. > > The xenpm part of this has been applied to xen-unstable.hg. > > I'm not sure it's best to apply the qemu part to qemu-xen-unstable. > That tree is intended to be obsolete and to be replaced with the new > upstream version of qemu. If it is applicable to modern qemu it's > worth considering applying it there, so I've CC'd Stefano. it has already been fixed in upstream qemu _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel From xen-devel-bounces@lists.xensource.com Wed Sep 21 02:50:09 2011 Return-path: <xen-devel-bounces@lists.xensource.com> Envelope-to: www-data@lists.xensource.com Delivery-date: Wed, 21 Sep 2011 02:50:09 -0700 Received: from localhost ([127.0.0.1] helo=lists.colo.xensource.com) by lists.xensource.com with esmtp (Exim 4.43) id 1R6JRR-00077b-6W; Wed, 21 Sep 2011 02:50:09 -0700 Received: from mail216.messagelabs.com ([85.158.143.99]) by lists.xensource.com with esmtp (Exim 4.43) id 1R6JQs-0006uv-TE for xen-devel@lists.xensource.com; Wed, 21 Sep 2011 02:49:35 -0700 X-Env-Sender: Ian.Campbell@eu.citrix.com X-Msg-Ref: server-9.tower-216.messagelabs.com!1316598571!19070823!1 X-Originating-IP: [62.200.22.115] X-StarScan-Version: 6.4.1; banners=-,-,- X-VirusChecked: Checked Received: (qmail 21419 invoked from network); 21 Sep 2011 09:49:32 -0000 Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115) by server-9.tower-216.messagelabs.com with RC4-SHA encrypted SMTP; 21 Sep 2011 09:49:32 -0000 X-IronPort-AV: E=Sophos;i="4.68,416,1312156800"; d="scan'208";a="7973236" Received: from lonpmailmx01.citrite.net ([10.30.203.162]) by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5; 21 Sep 2011 09:49:31 +0000 Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net (10.30.203.162) with Microsoft SMTP Server id 8.3.137.0; Wed, 21 Sep 2011 10:49:31 +0100 Subject: Re: [Xen-devel] [PATCH 2 of 2] libxl: add support for booting PV domains from NetBSD using raw files as disks From: Ian Campbell <Ian.Campbell@citrix.com> To: Roger Pau Monne <roger.pau@entel.upc.edu> Date: Wed, 21 Sep 2011 10:49:31 +0100 In-Reply-To: <aff3960421768180410c.1316187419@loki> References: <patchbomb.1316187417@loki> <aff3960421768180410c.1316187419@loki> Organization: Citrix Systems, Inc. Content-Type: text/plain; charset="UTF-8" X-Mailer: Evolution 3.0.3- Content-Transfer-Encoding: 7bit Message-ID: <1316598571.3891.138.camel@zakaz.uk.xensource.com> MIME-Version: 1.0 Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com> X-BeenThere: xen-devel@lists.xensource.com X-Mailman-Version: 2.1.5 Precedence: list List-Id: Xen developer discussion <xen-devel.lists.xensource.com> List-Unsubscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe> List-Post: <mailto:xen-devel@lists.xensource.com> List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help> List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=subscribe> Sender: xen-devel-bounces@lists.xensource.com Errors-To: xen-devel-bounces@lists.xensource.com On Fri, 2011-09-16 at 16:36 +0100, Roger Pau Monne wrote: > # HG changeset patch > # User Roger Pau Monne <roger.pau@entel.upc.edu> > # Date 1316187362 -7200 > # Node ID aff3960421768180410c8d553acf8881435bc3b4 > # Parent 00949e363f6f2c70001da548403475628df93b97 > libxl: add support for booting PV domains from NetBSD using raw files as disks. > > Used the hotplug-status attribute in xenstore for vbd to check when the device is offline. > > Signed-off-by: Roger Pau Monne <roger.pau@entel.upc.edu> Again this generally looks good but I think the functional split between the patches isn't quite right. > > diff -r 00949e363f6f -r aff396042176 tools/libxl/libxl_device.c > --- a/tools/libxl/libxl_device.c Fri Sep 16 17:29:45 2011 +0200 > +++ b/tools/libxl/libxl_device.c Fri Sep 16 17:36:02 2011 +0200 > @@ -366,14 +371,26 @@ int libxl__device_destroy(libxl__gc *gc, This bit (and most of this patch) goes along with the hotplug script changes in patch 1/2, doesn't it? > libxl_ctx *ctx = libxl__gc_owner(gc); > xs_transaction_t t; > char *state_path = libxl__sprintf(gc, "%s/state", be_path); > + char *hotplug_path = libxl__sprintf(gc, "%s/hotplug-status", be_path); > char *state = libxl__xs_read(gc, XBT_NULL, state_path); > + char *hotplug = libxl__xs_read(gc, XBT_NULL, hotplug_path); > int rc = 0; > > if (!state) > goto out; > - if (atoi(state) != 4) { > - xs_rm(ctx->xsh, XBT_NULL, be_path); > - goto out; > + > + if (!strstr(be_path, "vbd")) { I've got a WIP patch which passes a libxl__device to functions like this which will be helpful for removing these strstr things, since you can just use the DEVICE_* enum. > + if (atoi(state) != 4) { > + xs_rm(ctx->xsh, XBT_NULL, be_path); > + goto out; > + } > + } else { > + if (!hotplug) > + goto out; > + if (!strcmp(hotplug, "disconnected")) { > + xs_rm(ctx->xsh, XBT_NULL, be_path); > + goto out; > + } > } > > retry_transaction: > @@ -389,8 +406,13 @@ retry_transaction: > } > } > if (!force) { > - xs_watch(ctx->xsh, state_path, be_path); > - rc = 1; > + if (strstr(be_path, "vbd")) { > + xs_watch(ctx->xsh, hotplug_path, be_path); > + rc = 1; > + } else { > + xs_watch(ctx->xsh, state_path, be_path); > + rc = 1; > + } > } else { > xs_rm(ctx->xsh, XBT_NULL, be_path); > } > @@ -405,6 +427,7 @@ static int wait_for_dev_destroy(libxl__g > unsigned int n; > fd_set rfds; > char **l1 = NULL; > + char *state, *hotplug; > > rc = 1; > nfds = xs_fileno(ctx->xsh) + 1; > @@ -413,15 +436,29 @@ static int wait_for_dev_destroy(libxl__g > if (select(nfds, &rfds, NULL, NULL, tv) > 0) { > l1 = xs_read_watch(ctx->xsh, &n); > if (l1 != NULL) { > - char *state = libxl__xs_read(gc, XBT_NULL, l1[XS_WATCH_PATH]); > - if (!state || atoi(state) == 6) { > - xs_unwatch(ctx->xsh, l1[0], l1[1]); > - xs_rm(ctx->xsh, XBT_NULL, l1[XS_WATCH_TOKEN]); > - LIBXL__LOG(ctx, LIBXL__LOG_DEBUG, "Destroyed device backend at %s", l1[XS_WATCH_TOKEN]); > - rc = 0; > + if (strstr(l1[XS_WATCH_PATH], "hotplug-status")) { > + hotplug = libxl__xs_read(gc, XBT_NULL, l1[XS_WATCH_PATH]); > + if (!hotplug || !strcmp(hotplug, "disconnected")) { > + xs_unwatch(ctx->xsh, l1[0], l1[1]); > + xs_rm(ctx->xsh, XBT_NULL, l1[XS_WATCH_TOKEN]); > + LIBXL__LOG(ctx, LIBXL__LOG_DEBUG, "Destroyed device backend at %s hotplug-status: %s", > + l1[XS_WATCH_TOKEN], hotplug); > + rc = 0; > + } > + } else { > + state = libxl__xs_read(gc, XBT_NULL, l1[XS_WATCH_PATH]); > + if (!state || atoi(state) == 6) { > + xs_unwatch(ctx->xsh, l1[0], l1[1]); > + xs_rm(ctx->xsh, XBT_NULL, l1[XS_WATCH_TOKEN]); > + LIBXL__LOG(ctx, LIBXL__LOG_DEBUG, "Destroyed device backend at %s", l1[XS_WATCH_TOKEN]); > + rc = 0; > + } > } > free(l1); > } > + } else { > + /* timeout reached */ > + rc = 0; > } > return rc; > } > @@ -482,7 +519,7 @@ int libxl__devices_destroy(libxl__gc *gc > tv.tv_usec = 0; > while (n_watches > 0) { > if (wait_for_dev_destroy(gc, &tv)) { > - break; > + continue; > } else { > n_watches--; > } This looks like an independent bug fix? > diff -r 00949e363f6f -r aff396042176 tools/libxl/libxl_osdeps.h > --- a/tools/libxl/libxl_osdeps.h Fri Sep 16 17:29:45 2011 +0200 > +++ b/tools/libxl/libxl_osdeps.h Fri Sep 16 17:36:02 2011 +0200 > @@ -25,6 +25,7 @@ > > #if defined(__NetBSD__) || defined(__OpenBSD__) > #include <util.h> > +#define HAVE_PHY_BACKEND_FILE_SUPPORT > #elif defined(__linux__) > #include <pty.h> > #elif defined(__sun__) > > _______________________________________________ > Xen-devel mailing list > Xen-devel@lists.xensource.com > http://lists.xensource.com/xen-devel _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel From xen-devel-bounces@lists.xensource.com Wed Sep 21 02:51:12 2011 Return-path: <xen-devel-bounces@lists.xensource.com> Envelope-to: www-data@lists.xensource.com Delivery-date: Wed, 21 Sep 2011 02:51:12 -0700 Received: from localhost ([127.0.0.1] helo=lists.colo.xensource.com) by lists.xensource.com with esmtp (Exim 4.43) id 1R6JSS-0007Us-Kx; Wed, 21 Sep 2011 02:51:12 -0700 Received: from mail182.messagelabs.com ([85.158.139.83]) by lists.xensource.com with esmtp (Exim 4.43) id 1R6JRz-0007I7-W0 for xen-devel@lists.xensource.com; Wed, 21 Sep 2011 02:50:44 -0700 X-Env-Sender: Stefano.Stabellini@eu.citrix.com X-Msg-Ref: server-12.tower-182.messagelabs.com!1316598640!19011170!1 X-Originating-IP: [62.200.22.115] X-StarScan-Version: 6.4.1; banners=-,-,- X-VirusChecked: Checked Received: (qmail 23612 invoked from network); 21 Sep 2011 09:50:41 -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; 21 Sep 2011 09:50:41 -0000 X-IronPort-AV: E=Sophos;i="4.68,416,1312156800"; d="scan'208";a="7973313" Received: from lonpmailmx01.citrite.net ([10.30.203.162]) by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5; 21 Sep 2011 09:50:27 +0000 Received: from kaball.uk.xensource.com (10.80.2.59) by LONPMAILMX01.citrite.net (10.30.203.162) with Microsoft SMTP Server id 8.3.137.0; Wed, 21 Sep 2011 10:50:27 +0100 Date: Wed, 21 Sep 2011 10:50:17 +0100 From: Stefano Stabellini <stefano.stabellini@eu.citrix.com> X-X-Sender: sstabellini@kaball-desktop To: Ian Campbell <Ian.Campbell@citrix.com> In-Reply-To: <1316098809.26990.19.camel@cthulhu.hellion.org.uk> Message-ID: <alpine.DEB.2.00.1109211049010.8700@kaball-desktop> References: <alpine.DEB.2.00.1109151536130.12963@kaball-desktop> <1316098843-19974-3-git-send-email-stefano.stabellini@eu.citrix.com> <1316098809.26990.19.camel@cthulhu.hellion.org.uk> User-Agent: Alpine 2.00 (DEB 1167 2008-08-23) MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Cc: Ian Jackson <Ian.Jackson@eu.citrix.com>, "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>, "keir@xen.org" <keir@xen.org>, Stefano Stabellini <Stefano.Stabellini@eu.citrix.com> Subject: [Xen-devel] Re: [PATCH v4 3/4] Clone and build upstream Qemu by default X-BeenThere: xen-devel@lists.xensource.com X-Mailman-Version: 2.1.5 Precedence: list List-Id: Xen developer discussion <xen-devel.lists.xensource.com> List-Unsubscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe> List-Post: <mailto:xen-devel@lists.xensource.com> List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help> List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=subscribe> Sender: xen-devel-bounces@lists.xensource.com Errors-To: xen-devel-bounces@lists.xensource.com On Thu, 15 Sep 2011, Ian Campbell wrote: > On Thu, 2011-09-15 at 11:00 -0400, stefano.stabellini@eu.citrix.com > wrote: > > > > +# Only available through the git protocol at the moment > > This comment is now out of date... comment removed _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel From xen-devel-bounces@lists.xensource.com Wed Sep 21 02:52:07 2011 Return-path: <xen-devel-bounces@lists.xensource.com> Envelope-to: www-data@lists.xensource.com Delivery-date: Wed, 21 Sep 2011 02:52:07 -0700 Received: from localhost ([127.0.0.1] helo=lists.colo.xensource.com) by lists.xensource.com with esmtp (Exim 4.43) id 1R6JTL-0007sR-5R; Wed, 21 Sep 2011 02:52:07 -0700 Received: from mail182.messagelabs.com ([85.158.139.83]) by lists.xensource.com with esmtp (Exim 4.43) id 1R6JSI-0007P7-75 for xen-devel@lists.xensource.com; Wed, 21 Sep 2011 02:51:02 -0700 X-Env-Sender: Stefano.Stabellini@eu.citrix.com X-Msg-Ref: server-2.tower-182.messagelabs.com!1316598658!18163296!1 X-Originating-IP: [62.200.22.115] X-StarScan-Version: 6.4.1; banners=-,-,- X-VirusChecked: Checked Received: (qmail 6025 invoked from network); 21 Sep 2011 09:50:59 -0000 Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115) by server-2.tower-182.messagelabs.com with RC4-SHA encrypted SMTP; 21 Sep 2011 09:50:59 -0000 X-IronPort-AV: E=Sophos;i="4.68,416,1312156800"; d="scan'208";a="7973331" Received: from lonpmailmx01.citrite.net ([10.30.203.162]) by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5; 21 Sep 2011 09:50:58 +0000 Received: from kaball.uk.xensource.com (10.80.2.59) by LONPMAILMX01.citrite.net (10.30.203.162) with Microsoft SMTP Server id 8.3.137.0; Wed, 21 Sep 2011 10:50:58 +0100 Date: Wed, 21 Sep 2011 10:50:49 +0100 From: Stefano Stabellini <stefano.stabellini@eu.citrix.com> X-X-Sender: sstabellini@kaball-desktop To: Christoph Egger <Christoph.Egger@amd.com> Subject: Re: [Xen-devel] [PATCH v4 1/4] Introduce git-checkout.sh In-Reply-To: <4E7216D1.4030603@amd.com> Message-ID: <alpine.DEB.2.00.1109211049350.8700@kaball-desktop> References: <alpine.DEB.2.00.1109151536130.12963@kaball-desktop> <1316098843-19974-1-git-send-email-stefano.stabellini@eu.citrix.com> <4E7216D1.4030603@amd.com> User-Agent: Alpine 2.00 (DEB 1167 2008-08-23) MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Cc: Ian Campbell <Ian.Campbell@eu.citrix.com>, "keir@xen.org" <keir@xen.org>, "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>, Ian Jackson <Ian.Jackson@eu.citrix.com>, Stefano Stabellini <Stefano.Stabellini@eu.citrix.com> X-BeenThere: xen-devel@lists.xensource.com X-Mailman-Version: 2.1.5 Precedence: list List-Id: Xen developer discussion <xen-devel.lists.xensource.com> List-Unsubscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe> List-Post: <mailto:xen-devel@lists.xensource.com> List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help> List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=subscribe> Sender: xen-devel-bounces@lists.xensource.com Errors-To: xen-devel-bounces@lists.xensource.com On Thu, 15 Sep 2011, Christoph Egger wrote: > On 09/15/11 17:00, stefano.stabellini@eu.citrix.com wrote: > > Introduce a script to perform git checkout on an external git tree; use > > git-checkout.sh in ioemu-dir-find. > > > > Signed-off-by: Stefano Stabellini<stefano.stabellini@eu.citrix.com> > > > > diff --git a/.hgignore b/.hgignore > > --- a/.hgignore > > +++ b/.hgignore > > @@ -291,7 +291,7 @@ > > ^tools/xm-test/lib/XmTestLib/config.py$ > > ^tools/xm-test/lib/XmTestReport/xmtest.py$ > > ^tools/xm-test/tests/.*\.test$ > > -^tools/ioemu-remote > > +^tools/ioemu-dir-remote > > ^tools/ioemu-dir$ > > ^tools/ocaml/.*/.*\.annot$ > > ^tools/ocaml/.*/.*\.cmx?a$ > > diff --git a/scripts/git-checkout.sh b/scripts/git-checkout.sh > > new file mode 100755 > > --- /dev/null > > +++ b/scripts/git-checkout.sh > > @@ -0,0 +1,21 @@ > > +#!/bin/bash > > This should be #!/bin/sh . fixed _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel From xen-devel-bounces@lists.xensource.com Wed Sep 21 02:55:26 2011 Return-path: <xen-devel-bounces@lists.xensource.com> Envelope-to: www-data@lists.xensource.com Delivery-date: Wed, 21 Sep 2011 02:55:26 -0700 Received: from localhost ([127.0.0.1] helo=lists.colo.xensource.com) by lists.xensource.com with esmtp (Exim 4.43) id 1R6JWY-0008Ha-Go; Wed, 21 Sep 2011 02:55:26 -0700 Received: from mail182.messagelabs.com ([85.158.139.83]) by lists.xensource.com with esmtp (Exim 4.43) id 1R6JVq-00084k-4F for xen-devel@lists.xensource.com; Wed, 21 Sep 2011 02:54:42 -0700 X-Env-Sender: Stefano.Stabellini@eu.citrix.com X-Msg-Ref: server-11.tower-182.messagelabs.com!1316598879!19167490!1 X-Originating-IP: [62.200.22.115] X-StarScan-Version: 6.4.1; banners=-,-,- X-VirusChecked: Checked Received: (qmail 22607 invoked from network); 21 Sep 2011 09:54:39 -0000 Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115) by server-11.tower-182.messagelabs.com with RC4-SHA encrypted SMTP; 21 Sep 2011 09:54:39 -0000 X-IronPort-AV: E=Sophos;i="4.68,416,1312156800"; d="scan'208";a="7973442" Received: from lonpmailmx01.citrite.net ([10.30.203.162]) by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5; 21 Sep 2011 09:54:38 +0000 Received: from kaball.uk.xensource.com (10.80.2.59) by LONPMAILMX01.citrite.net (10.30.203.162) with Microsoft SMTP Server id 8.3.137.0; Wed, 21 Sep 2011 10:54:38 +0100 Date: Wed, 21 Sep 2011 10:54:29 +0100 From: Stefano Stabellini <Stefano.Stabellini@eu.citrix.com> X-X-Sender: sstabellini@kaball-desktop To: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com> Message-ID: <alpine.DEB.2.00.1109211051270.8700@kaball-desktop> User-Agent: Alpine 2.00 (DEB 1167 2008-08-23) MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Cc: Ian Campbell <Ian.Campbell@eu.citrix.com>, Keir Fraser <keir@xen.org>, Stefano Stabellini <Stefano.Stabellini@eu.citrix.com> Subject: [Xen-devel] [PATCH v5] build upstream qemu and seabios by default X-BeenThere: xen-devel@lists.xensource.com X-Mailman-Version: 2.1.5 Precedence: list List-Id: Xen developer discussion <xen-devel.lists.xensource.com> List-Unsubscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe> List-Post: <mailto:xen-devel@lists.xensource.com> List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help> List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=subscribe> Sender: xen-devel-bounces@lists.xensource.com Errors-To: xen-devel-bounces@lists.xensource.com Hi all, this is the fifth version of the patch series to introduce upstream qemu and seabios in the xen-unstable build system. Changes to v4: - remove an obsolete comment; - use /bin/sh to execute git-checkout.sh rathen than /bin/bash. Changes to v3: - reduce the scope of git-checkout.sh, now it only does what the name says; calling "configure" is responsibility of the caller. As a result of this change, the build still works when the user specifies a local directory in the CONFIG_QEMU environmental variable; - use a more official qemu repository hosted on xenbits; - use a changeset as QEMU_UPSTREAM_TAG rather than a branch name. Changes to v2: - move tools/git-checkout.sh to scripts/git-checkout.sh; - use git-checkout.sh for seabios; - improve seabios integration with tools/firmware make system; - add qemu-xen-traditional, qemu-xen and seabios dir entries to .hgignore. Changes to v1: - always build upstream qemu and seabios, rather than introducing them as an option. Cheers, Stefano _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel From xen-devel-bounces@lists.xensource.com Wed Sep 21 02:56:39 2011 Return-path: <xen-devel-bounces@lists.xensource.com> Envelope-to: www-data@lists.xensource.com Delivery-date: Wed, 21 Sep 2011 02:56:39 -0700 Received: from localhost ([127.0.0.1] helo=lists.colo.xensource.com) by lists.xensource.com with esmtp (Exim 4.43) id 1R6JXj-0000DS-Gb; Wed, 21 Sep 2011 02:56:39 -0700 Received: from mail27.messagelabs.com ([193.109.254.147]) by lists.xensource.com with esmtp (Exim 4.43) id 1R6JWY-0008GD-7l for xen-devel@lists.xensource.com; Wed, 21 Sep 2011 02:55:26 -0700 X-Env-Sender: Stefano.Stabellini@eu.citrix.com X-Msg-Ref: server-12.tower-27.messagelabs.com!1316598906!43314131!1 X-Originating-IP: [66.165.176.63] X-StarScan-Version: 6.4.1; banners=-,-,- X-VirusChecked: Checked Received: (qmail 30423 invoked from network); 21 Sep 2011 09:55:07 -0000 Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63) by server-12.tower-27.messagelabs.com with RC4-SHA encrypted SMTP; 21 Sep 2011 09:55:07 -0000 X-IronPort-AV: E=Sophos;i="4.68,416,1312171200"; d="scan'208";a="164094957" Received: from ftlpmailmx02.citrite.net ([10.13.107.66]) by FTLPIPO02.CITRIX.COM with ESMTP/TLS/RC4-MD5; 21 Sep 2011 05:55:21 -0400 Received: from smtp01.ad.xensource.com (10.219.128.104) by smtprelay.citrix.com (10.13.107.66) with Microsoft SMTP Server id 8.3.137.0; Wed, 21 Sep 2011 05:55:21 -0400 Received: from localhost.localdomain (kaball.uk.xensource.com [10.80.2.59]) by smtp01.ad.xensource.com (8.13.1/8.13.1) with ESMTP id p8L9tD1E023496; Wed, 21 Sep 2011 02:55:14 -0700 From: <stefano.stabellini@eu.citrix.com> To: xen-devel@lists.xensource.com Date: Wed, 21 Sep 2011 10:55:14 +0100 Message-ID: <1316598917-21515-1-git-send-email-stefano.stabellini@eu.citrix.com> X-Mailer: git-send-email 1.7.0.4 In-Reply-To: <alpine.DEB.2.00.1109211051270.8700@kaball-desktop> References: <alpine.DEB.2.00.1109211051270.8700@kaball-desktop> MIME-Version: 1.0 Content-Type: text/plain Cc: Ian.Campbell@eu.citrix.com, Ian.Jackson@eu.citrix.com, Stefano Stabellini <stefano.stabellini@eu.citrix.com>, keir@xen.org, Stefano.Stabellini@eu.citrix.com Subject: [Xen-devel] [PATCH v5 1/4] Introduce git-checkout.sh X-BeenThere: xen-devel@lists.xensource.com X-Mailman-Version: 2.1.5 Precedence: list List-Id: Xen developer discussion <xen-devel.lists.xensource.com> List-Unsubscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe> List-Post: <mailto:xen-devel@lists.xensource.com> List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help> List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=subscribe> Sender: xen-devel-bounces@lists.xensource.com Errors-To: xen-devel-bounces@lists.xensource.com Introduce a script to perform git checkout on an external git tree; use git-checkout.sh in ioemu-dir-find. Signed-off-by: Stefano Stabellini <stefano.stabellini@eu.citrix.com> diff --git a/.hgignore b/.hgignore --- a/.hgignore +++ b/.hgignore @@ -291,7 +291,7 @@ ^tools/xm-test/lib/XmTestLib/config.py$ ^tools/xm-test/lib/XmTestReport/xmtest.py$ ^tools/xm-test/tests/.*\.test$ -^tools/ioemu-remote +^tools/ioemu-dir-remote ^tools/ioemu-dir$ ^tools/ocaml/.*/.*\.annot$ ^tools/ocaml/.*/.*\.cmx?a$ diff --git a/scripts/git-checkout.sh b/scripts/git-checkout.sh new file mode 100755 --- /dev/null +++ b/scripts/git-checkout.sh @@ -0,0 +1,21 @@ +#!/bin/sh + +TREE=$1 +TAG=$2 +DIR=$3 + + +if test \! -d $DIR-remote; then + rm -rf $DIR-remote $DIR-remote.tmp; + mkdir $DIR-remote.tmp; rmdir $DIR-remote.tmp; + git clone $TREE $DIR-remote.tmp; + if test "$TAG" ; then + cd $DIR-remote.tmp + git branch -D dummy >/dev/null 2>&1 ||: + git checkout -b dummy $TAG + cd .. + fi + mv $DIR-remote.tmp $DIR-remote +fi +rm -f $DIR +ln -sf $DIR-remote $DIR diff --git a/tools/Makefile b/tools/Makefile --- a/tools/Makefile +++ b/tools/Makefile @@ -70,7 +70,7 @@ clean: subdirs-clean .PHONY: distclean distclean: subdirs-distclean - rm -rf ioemu-dir ioemu-remote + rm -rf ioemu-dir ioemu-dir-remote ifneq ($(XEN_COMPILE_ARCH),$(XEN_TARGET_ARCH)) IOEMU_CONFIGURE_CROSS ?= --cpu=$(XEN_TARGET_ARCH) \ @@ -88,20 +88,7 @@ ioemu-dir-find: if test -d $(CONFIG_QEMU); then \ mkdir -p ioemu-dir; \ else \ - if [ ! -d ioemu-remote ]; then \ - rm -rf ioemu-remote ioemu-remote.tmp; \ - mkdir ioemu-remote.tmp; rmdir ioemu-remote.tmp; \ - $(GIT) clone $(CONFIG_QEMU) ioemu-remote.tmp; \ - if [ "$(QEMU_TAG)" ]; then \ - cd ioemu-remote.tmp; \ - $(GIT) branch -D dummy >/dev/null 2>&1 ||:; \ - $(GIT) checkout -b dummy $(QEMU_TAG); \ - cd ..; \ - fi; \ - mv ioemu-remote.tmp ioemu-remote; \ - fi; \ - rm -f ioemu-dir; \ - ln -sf ioemu-remote ioemu-dir; \ + $(XEN_ROOT)/scripts/git-checkout.sh $(CONFIG_QEMU) $(QEMU_TAG) ioemu-dir; \ fi set -e; \ $(buildmakevars2shellvars); \ @@ -112,7 +99,7 @@ ioemu-dir-find: ioemu-dir-force-update: set -ex; \ if [ "$(QEMU_TAG)" ]; then \ - cd ioemu-remote; \ + cd ioemu-dir-remote; \ $(GIT) fetch origin; \ $(GIT) reset --hard $(QEMU_TAG); \ fi _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel From xen-devel-bounces@lists.xensource.com Wed Sep 21 02:58:37 2011 Return-path: <xen-devel-bounces@lists.xensource.com> Envelope-to: www-data@lists.xensource.com Delivery-date: Wed, 21 Sep 2011 02:58:37 -0700 Received: from localhost ([127.0.0.1] helo=lists.colo.xensource.com) by lists.xensource.com with esmtp (Exim 4.43) id 1R6JZc-0000f8-FP; Wed, 21 Sep 2011 02:58:36 -0700 Received: from mail182.messagelabs.com ([85.158.139.83]) by lists.xensource.com with esmtp (Exim 4.43) id 1R6JWf-0008Ij-5W for xen-devel@lists.xensource.com; Wed, 21 Sep 2011 02:55:33 -0700 X-Env-Sender: Stefano.Stabellini@eu.citrix.com X-Msg-Ref: server-13.tower-182.messagelabs.com!1316598928!19003438!1 X-Originating-IP: [66.165.176.89] X-StarScan-Version: 6.4.1; banners=-,-,- X-VirusChecked: Checked Received: (qmail 4040 invoked from network); 21 Sep 2011 09:55:29 -0000 Received: from smtp.citrix.com (HELO SMTP.CITRIX.COM) (66.165.176.89) by server-13.tower-182.messagelabs.com with RC4-SHA encrypted SMTP; 21 Sep 2011 09:55:29 -0000 X-IronPort-AV: E=Sophos;i="4.68,416,1312171200"; d="scan'208";a="17562976" Received: from ftlpmailmx02.citrite.net ([10.13.107.66]) by FTLPIPO01.CITRIX.COM with ESMTP/TLS/RC4-MD5; 21 Sep 2011 05:55:28 -0400 Received: from smtp01.ad.xensource.com (10.219.128.104) by smtprelay.citrix.com (10.13.107.66) with Microsoft SMTP Server id 8.3.137.0; Wed, 21 Sep 2011 05:55:28 -0400 Received: from localhost.localdomain (kaball.uk.xensource.com [10.80.2.59]) by smtp01.ad.xensource.com (8.13.1/8.13.1) with ESMTP id p8L9tD1F023496; Wed, 21 Sep 2011 02:55:16 -0700 From: <stefano.stabellini@eu.citrix.com> To: xen-devel@lists.xensource.com Date: Wed, 21 Sep 2011 10:55:15 +0100 Message-ID: <1316598917-21515-2-git-send-email-stefano.stabellini@eu.citrix.com> X-Mailer: git-send-email 1.7.0.4 In-Reply-To: <alpine.DEB.2.00.1109211051270.8700@kaball-desktop> References: <alpine.DEB.2.00.1109211051270.8700@kaball-desktop> MIME-Version: 1.0 Content-Type: text/plain Cc: Ian.Campbell@eu.citrix.com, Ian.Jackson@eu.citrix.com, Stefano Stabellini <stefano.stabellini@eu.citrix.com>, keir@xen.org, Stefano.Stabellini@eu.citrix.com Subject: [Xen-devel] [PATCH v5 2/4] Rename ioemu-dir as qemu-xen-traditional-dir X-BeenThere: xen-devel@lists.xensource.com X-Mailman-Version: 2.1.5 Precedence: list List-Id: Xen developer discussion <xen-devel.lists.xensource.com> List-Unsubscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe> List-Post: <mailto:xen-devel@lists.xensource.com> List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help> List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=subscribe> Sender: xen-devel-bounces@lists.xensource.com Errors-To: xen-devel-bounces@lists.xensource.com Signed-off-by: Stefano Stabellini <stefano.stabellini@eu.citrix.com> diff -r 1993c6e145b5 .hgignore --- a/.hgignore Thu Sep 15 09:38:49 2011 +0000 +++ b/.hgignore Thu Sep 15 11:08:51 2011 +0000 @@ -291,8 +291,8 @@ ^tools/xm-test/lib/XmTestLib/config.py$ ^tools/xm-test/lib/XmTestReport/xmtest.py$ ^tools/xm-test/tests/.*\.test$ -^tools/ioemu-dir-remote -^tools/ioemu-dir$ +^tools/qemu-xen-traditional-dir-remote +^tools/qemu-xen-traditional-dir$ ^tools/ocaml/.*/.*\.annot$ ^tools/ocaml/.*/.*\.cmx?a$ ^tools/ocaml/.*/META$ diff -r 1993c6e145b5 Makefile --- a/Makefile Thu Sep 15 09:38:49 2011 +0000 +++ b/Makefile Thu Sep 15 11:08:51 2011 +0000 @@ -70,7 +70,7 @@ install-tools: $(MAKE) -C tools install ifeq ($(CONFIG_IOEMU),y) -install-tools: tools/ioemu-dir +install-tools: tools/qemu-xen-traditional-dir endif .PHONY: install-kernels @@ -78,18 +78,18 @@ install-kernels: for i in $(XKERNELS) ; do $(MAKE) $$i-install || exit 1; done .PHONY: install-stubdom -install-stubdom: tools/ioemu-dir install-tools +install-stubdom: tools/qemu-xen-traditional-dir install-tools $(MAKE) -C stubdom install ifeq (x86_64,$(XEN_TARGET_ARCH)) XEN_TARGET_ARCH=x86_32 $(MAKE) -C stubdom install-grub endif -tools/ioemu-dir: - $(MAKE) -C tools ioemu-dir-find +tools/qemu-xen-traditional-dir: + $(MAKE) -C tools qemu-xen-traditional-dir-find -.PHONY: tools/ioemu-dir-force-update -tools/ioemu-dir-force-update: - $(MAKE) -C tools ioemu-dir-force-update +.PHONY: tools/qemu-xen-traditional-dir-force-update +tools/qemu-xen-traditional-dir-force-update: + $(MAKE) -C tools qemu-xen-traditional-dir-force-update .PHONY: install-docs install-docs: diff -r 1993c6e145b5 stubdom/Makefile --- a/stubdom/Makefile Thu Sep 15 09:38:49 2011 +0000 +++ b/stubdom/Makefile Thu Sep 15 11:08:51 2011 +0000 @@ -218,15 +218,15 @@ cross-ocaml: $(OCAML_STAMPFILE) QEMU_ROOT := $(shell if [ -d "$(CONFIG_QEMU)" ]; then echo "$(CONFIG_QEMU)"; else echo .; fi) ifeq ($(QEMU_ROOT),.) -$(XEN_ROOT)/tools/ioemu-dir: - $(CROSS_MAKE) -C $(XEN_ROOT)/tools ioemu-dir-find +$(XEN_ROOT)/tools/qemu-xen-traditional-dir: + $(CROSS_MAKE) -C $(XEN_ROOT)/tools qemu-xen-traditional-dir-find -ioemu/linkfarm.stamp: $(XEN_ROOT)/tools/ioemu-dir +ioemu/linkfarm.stamp: $(XEN_ROOT)/tools/qemu-xen-traditional-dir mkdir -p ioemu set -e; \ $(buildmakevars2shellvars); \ cd ioemu; \ - src="$$XEN_ROOT/tools/ioemu-dir"; export src; \ + src="$$XEN_ROOT/tools/qemu-xen-traditional-dir"; export src; \ (cd $$src && find * -type d -print) | xargs mkdir -p; \ (cd $$src && find * ! -type l -type f $(addprefix ! -name , \ '*.[oda1]' 'config-*' config.mak qemu-dm qemu-img-xen \ diff -r 1993c6e145b5 tools/Makefile --- a/tools/Makefile Thu Sep 15 09:38:49 2011 +0000 +++ b/tools/Makefile Thu Sep 15 11:08:51 2011 +0000 @@ -30,7 +30,7 @@ SUBDIRS-$(LIBXENAPI_BINDINGS) += libxen # do not recurse in to a dir we are about to delete ifneq "$(MAKECMDGOALS)" "distclean" -SUBDIRS-$(CONFIG_IOEMU) += ioemu-dir +SUBDIRS-$(CONFIG_IOEMU) += qemu-xen-traditional-dir endif SUBDIRS-y += xenpmd @@ -70,7 +70,7 @@ clean: subdirs-clean .PHONY: distclean distclean: subdirs-distclean - rm -rf ioemu-dir ioemu-dir-remote + rm -rf qemu-xen-traditional-dir qemu-xen-traditional-dir-remote ifneq ($(XEN_COMPILE_ARCH),$(XEN_TARGET_ARCH)) IOEMU_CONFIGURE_CROSS ?= --cpu=$(XEN_TARGET_ARCH) \ @@ -83,33 +83,33 @@ ifneq ($(QEMU_ROOT),.) export QEMU_ROOT endif -ioemu-dir-find: +qemu-xen-traditional-dir-find: set -ex; \ if test -d $(CONFIG_QEMU); then \ - mkdir -p ioemu-dir; \ + mkdir -p qemu-xen-traditional-dir; \ else \ - $(XEN_ROOT)/scripts/git-checkout.sh $(CONFIG_QEMU) $(QEMU_TAG) ioemu-dir; \ + $(XEN_ROOT)/scripts/git-checkout.sh $(CONFIG_QEMU) $(QEMU_TAG) qemu-xen-traditional-dir; \ fi set -e; \ $(buildmakevars2shellvars); \ - cd ioemu-dir; \ + cd qemu-xen-traditional-dir; \ $(QEMU_ROOT)/xen-setup $(IOEMU_CONFIGURE_CROSS) -.PHONY: ioemu-dir-force-update -ioemu-dir-force-update: +.PHONY: qemu-xen-traditional-dir-force-update +qemu-xen-traditional-dir-force-update: set -ex; \ if [ "$(QEMU_TAG)" ]; then \ - cd ioemu-dir-remote; \ + cd qemu-xen-traditional-dir-remote; \ $(GIT) fetch origin; \ $(GIT) reset --hard $(QEMU_TAG); \ fi -subdir-all-ioemu-dir subdir-install-ioemu-dir: ioemu-dir-find +subdir-all-qemu-xen-traditional-dir subdir-install-qemu-xen-traditional-dir: qemu-xen-traditional-dir-find -subdir-clean-ioemu-dir: - set -e; if test -d ioemu-dir/.; then \ +subdir-clean-qemu-xen-traditional-dir: + set -e; if test -d qemu-xen-traditional-dir/.; then \ $(buildmakevars2shellvars); \ - $(MAKE) -C ioemu-dir clean; \ + $(MAKE) -C qemu-xen-traditional-dir clean; \ fi subdir-clean-debugger/gdbsx subdir-distclean-debugger/gdbsx: .phony _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel From xen-devel-bounces@lists.xensource.com Wed Sep 21 03:03:49 2011 Return-path: <xen-devel-bounces@lists.xensource.com> Envelope-to: www-data@lists.xensource.com Delivery-date: Wed, 21 Sep 2011 03:03:49 -0700 Received: from localhost ([127.0.0.1] helo=lists.colo.xensource.com) by lists.xensource.com with esmtp (Exim 4.43) id 1R6Jed-0001Da-Rg; Wed, 21 Sep 2011 03:03:47 -0700 Received: from mail182.messagelabs.com ([85.158.139.83]) by lists.xensource.com with esmtp (Exim 4.43) id 1R6JWg-0008J9-Ec for xen-devel@lists.xensource.com; Wed, 21 Sep 2011 02:55:35 -0700 X-Env-Sender: Stefano.Stabellini@eu.citrix.com X-Msg-Ref: server-11.tower-182.messagelabs.com!1316598930!19167653!1 X-Originating-IP: [66.165.176.63] X-StarScan-Version: 6.4.1; banners=-,-,- X-VirusChecked: Checked Received: (qmail 27047 invoked from network); 21 Sep 2011 09:55:31 -0000 Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63) by server-11.tower-182.messagelabs.com with RC4-SHA encrypted SMTP; 21 Sep 2011 09:55:31 -0000 X-IronPort-AV: E=Sophos;i="4.68,416,1312171200"; d="scan'208";a="164094967" Received: from ftlpmailmx02.citrite.net ([10.13.107.66]) by FTLPIPO02.CITRIX.COM with ESMTP/TLS/RC4-MD5; 21 Sep 2011 05:55:29 -0400 Received: from smtp01.ad.xensource.com (10.219.128.104) by smtprelay.citrix.com (10.13.107.66) with Microsoft SMTP Server id 8.3.137.0; Wed, 21 Sep 2011 05:55:29 -0400 Received: from localhost.localdomain (kaball.uk.xensource.com [10.80.2.59]) by smtp01.ad.xensource.com (8.13.1/8.13.1) with ESMTP id p8L9tD1G023496; Wed, 21 Sep 2011 02:55:17 -0700 From: <stefano.stabellini@eu.citrix.com> To: xen-devel@lists.xensource.com Date: Wed, 21 Sep 2011 10:55:16 +0100 Message-ID: <1316598917-21515-3-git-send-email-stefano.stabellini@eu.citrix.com> X-Mailer: git-send-email 1.7.0.4 In-Reply-To: <alpine.DEB.2.00.1109211051270.8700@kaball-desktop> References: <alpine.DEB.2.00.1109211051270.8700@kaball-desktop> MIME-Version: 1.0 Content-Type: text/plain Cc: Ian.Campbell@eu.citrix.com, Ian.Jackson@eu.citrix.com, Stefano Stabellini <stefano.stabellini@eu.citrix.com>, keir@xen.org, Stefano.Stabellini@eu.citrix.com Subject: [Xen-devel] [PATCH v5 3/4] Clone and build upstream Qemu by default X-BeenThere: xen-devel@lists.xensource.com X-Mailman-Version: 2.1.5 Precedence: list List-Id: Xen developer discussion <xen-devel.lists.xensource.com> List-Unsubscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe> List-Post: <mailto:xen-devel@lists.xensource.com> List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help> List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=subscribe> Sender: xen-devel-bounces@lists.xensource.com Errors-To: xen-devel-bounces@lists.xensource.com Signed-off-by: Stefano Stabellini <stefano.stabellini@eu.citrix.com> diff -r 51795795b213 .hgignore --- a/.hgignore Wed Sep 21 09:48:34 2011 +0000 +++ b/.hgignore Wed Sep 21 09:48:52 2011 +0000 @@ -293,6 +293,8 @@ ^tools/xm-test/tests/.*\.test$ ^tools/qemu-xen-traditional-dir-remote ^tools/qemu-xen-traditional-dir$ +^tools/qemu-xen-dir-remote +^tools/qemu-xen-dir$ ^tools/ocaml/.*/.*\.annot$ ^tools/ocaml/.*/.*\.cmx?a$ ^tools/ocaml/.*/META$ diff -r 51795795b213 Config.mk --- a/Config.mk Wed Sep 21 09:48:34 2011 +0000 +++ b/Config.mk Wed Sep 21 09:48:52 2011 +0000 @@ -192,6 +192,13 @@ else QEMU_REMOTE=git://xenbits.xensource.com/qemu-xen-unstable.git endif +ifeq ($(GIT_HTTP),y) +QEMU_UPSTREAM_URL ?= http://xenbits.xensource.com/git-http/qemu-upstream-unstable.git +else +QEMU_UPSTREAM_URL ?= git://xenbits.xensource.com/qemu-upstream-unstable.git +endif +QEMU_UPSTREAM_TAG ?= 6dd84c71dff047f9e492d67e7c99928d09202760 + # Specify which qemu-dm to use. This may be `ioemu' to use the old # Mercurial in-tree version, or a local directory, or a git URL. # CONFIG_QEMU ?= `pwd`/$(XEN_ROOT)/../qemu-xen.git diff -r 51795795b213 Makefile --- a/Makefile Wed Sep 21 09:48:34 2011 +0000 +++ b/Makefile Wed Sep 21 09:48:52 2011 +0000 @@ -70,7 +70,7 @@ install-tools: $(MAKE) -C tools install ifeq ($(CONFIG_IOEMU),y) -install-tools: tools/qemu-xen-traditional-dir +install-tools: tools/qemu-xen-traditional-dir tools/qemu-xen-dir endif .PHONY: install-kernels @@ -91,6 +91,9 @@ tools/qemu-xen-traditional-dir: tools/qemu-xen-traditional-dir-force-update: $(MAKE) -C tools qemu-xen-traditional-dir-force-update +tools/qemu-xen-dir: + $(MAKE) -C tools qemu-xen-dir-find + .PHONY: install-docs install-docs: sh ./docs/check_pkgs && $(MAKE) -C docs install || true diff -r 51795795b213 tools/Makefile --- a/tools/Makefile Wed Sep 21 09:48:34 2011 +0000 +++ b/tools/Makefile Wed Sep 21 09:48:52 2011 +0000 @@ -31,6 +31,7 @@ SUBDIRS-$(LIBXENAPI_BINDINGS) += libxen # do not recurse in to a dir we are about to delete ifneq "$(MAKECMDGOALS)" "distclean" SUBDIRS-$(CONFIG_IOEMU) += qemu-xen-traditional-dir +SUBDIRS-$(CONFIG_IOEMU) += qemu-xen-dir endif SUBDIRS-y += xenpmd @@ -71,6 +72,7 @@ clean: subdirs-clean .PHONY: distclean distclean: subdirs-distclean rm -rf qemu-xen-traditional-dir qemu-xen-traditional-dir-remote + rm -rf qemu-xen-dir qemu-xen-dir-remote ifneq ($(XEN_COMPILE_ARCH),$(XEN_TARGET_ARCH)) IOEMU_CONFIGURE_CROSS ?= --cpu=$(XEN_TARGET_ARCH) \ @@ -95,6 +97,24 @@ qemu-xen-traditional-dir-find: cd qemu-xen-traditional-dir; \ $(QEMU_ROOT)/xen-setup $(IOEMU_CONFIGURE_CROSS) +qemu-xen-dir-find: + if test -d $(QEMU_UPSTREAM_URL) ; then \ + ln -sf $(QEMU_UPSTREAM_URL) qemu-xen-dir; \ + else \ + $(XEN_ROOT)/scripts/git-checkout.sh $(QEMU_UPSTREAM_URL) $(QEMU_UPSTREAM_TAG) qemu-xen-dir ; \ + fi + cd qemu-xen-dir; \ + ./configure --enable-xen --target-list=i386-softmmu \ + --source-path=$$ROOT \ + --extra-cflags="-I$(XEN_ROOT)/tools/include \ + -I$(XEN_ROOT)/tools/libxc \ + -I$(XEN_ROOT)/tools/xenstore" \ + --extra-ldflags="-L$(XEN_ROOT)/tools/libxc \ + -L$(XEN_ROOT)/tools/libxenstore" \ + --bindir=/usr/lib/xen/bin \ + --disable-kvm \ + $(IOEMU_CONFIGURE_CROSS) + .PHONY: qemu-xen-traditional-dir-force-update qemu-xen-traditional-dir-force-update: set -ex; \ @@ -112,6 +132,14 @@ subdir-clean-qemu-xen-traditional-dir: $(MAKE) -C qemu-xen-traditional-dir clean; \ fi +subdir-all-qemu-xen-dir subdir-install-qemu-xen-dir: qemu-xen-dir-find + +subdir-clean-qemu-xen-dir: + set -e; if test -d qemu-xen-dir/.; then \ + $(buildmakevars2shellvars); \ + $(MAKE) -C qemu-xen-dir clean; \ + fi + subdir-clean-debugger/gdbsx subdir-distclean-debugger/gdbsx: .phony $(MAKE) -C debugger/gdbsx clean _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel From xen-devel-bounces@lists.xensource.com Wed Sep 21 03:06:15 2011 Return-path: <xen-devel-bounces@lists.xensource.com> Envelope-to: www-data@lists.xensource.com Delivery-date: Wed, 21 Sep 2011 03:06:15 -0700 Received: from localhost ([127.0.0.1] helo=lists.colo.xensource.com) by lists.xensource.com with esmtp (Exim 4.43) id 1R6Jh1-0001fc-15; Wed, 21 Sep 2011 03:06:15 -0700 Received: from mail182.messagelabs.com ([85.158.139.83]) by lists.xensource.com with esmtp (Exim 4.43) id 1R6JWg-0008JA-M0 for xen-devel@lists.xensource.com; Wed, 21 Sep 2011 02:55:35 -0700 X-Env-Sender: Stefano.Stabellini@eu.citrix.com X-Msg-Ref: server-13.tower-182.messagelabs.com!1316598928!19003438!2 X-Originating-IP: [66.165.176.89] X-StarScan-Version: 6.4.1; banners=-,-,- X-VirusChecked: Checked Received: (qmail 4163 invoked from network); 21 Sep 2011 09:55:31 -0000 Received: from smtp.citrix.com (HELO SMTP.CITRIX.COM) (66.165.176.89) by server-13.tower-182.messagelabs.com with RC4-SHA encrypted SMTP; 21 Sep 2011 09:55:31 -0000 X-IronPort-AV: E=Sophos;i="4.68,416,1312171200"; d="scan'208";a="17562977" Received: from ftlpmailmx02.citrite.net ([10.13.107.66]) by FTLPIPO01.CITRIX.COM with ESMTP/TLS/RC4-MD5; 21 Sep 2011 05:55:30 -0400 Received: from smtp01.ad.xensource.com (10.219.128.104) by smtprelay.citrix.com (10.13.107.66) with Microsoft SMTP Server id 8.3.137.0; Wed, 21 Sep 2011 05:55:31 -0400 Received: from localhost.localdomain (kaball.uk.xensource.com [10.80.2.59]) by smtp01.ad.xensource.com (8.13.1/8.13.1) with ESMTP id p8L9tD1H023496; Wed, 21 Sep 2011 02:55:19 -0700 From: <stefano.stabellini@eu.citrix.com> To: xen-devel@lists.xensource.com Date: Wed, 21 Sep 2011 10:55:17 +0100 Message-ID: <1316598917-21515-4-git-send-email-stefano.stabellini@eu.citrix.com> X-Mailer: git-send-email 1.7.0.4 In-Reply-To: <alpine.DEB.2.00.1109211051270.8700@kaball-desktop> References: <alpine.DEB.2.00.1109211051270.8700@kaball-desktop> MIME-Version: 1.0 Content-Type: text/plain Cc: Ian.Campbell@eu.citrix.com, Ian.Jackson@eu.citrix.com, Stefano Stabellini <stefano.stabellini@eu.citrix.com>, keir@xen.org, Stefano.Stabellini@eu.citrix.com Subject: [Xen-devel] [PATCH v5 4/4] Clone and build Seabios by default X-BeenThere: xen-devel@lists.xensource.com X-Mailman-Version: 2.1.5 Precedence: list List-Id: Xen developer discussion <xen-devel.lists.xensource.com> List-Unsubscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe> List-Post: <mailto:xen-devel@lists.xensource.com> List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help> List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=subscribe> Sender: xen-devel-bounces@lists.xensource.com Errors-To: xen-devel-bounces@lists.xensource.com Signed-off-by: Stefano Stabellini <stefano.stabellini@eu.citrix.com> diff -r 9832a4edea7f .hgignore --- a/.hgignore Thu Sep 15 14:25:11 2011 +0000 +++ b/.hgignore Thu Sep 15 14:37:33 2011 +0000 @@ -295,6 +295,8 @@ ^tools/qemu-xen-traditional-dir$ ^tools/qemu-xen-dir-remote ^tools/qemu-xen-dir$ +^tools/tools/firmware/seabios-dir-remote +^tools/tools/firmware/seabios-dir$ ^tools/ocaml/.*/.*\.annot$ ^tools/ocaml/.*/.*\.cmx?a$ ^tools/ocaml/.*/META$ diff -r 9832a4edea7f Config.mk --- a/Config.mk Thu Sep 15 14:25:11 2011 +0000 +++ b/Config.mk Thu Sep 15 14:37:33 2011 +0000 @@ -199,6 +199,8 @@ else QEMU_UPSTREAM_URL ?= git://xenbits.xensource.com/qemu-upstream-unstable.git endif QEMU_UPSTREAM_TAG ?= 6dd84c71dff047f9e492d67e7c99928d09202760 +SEABIOS_UPSTREAM_URL ?= git://git.qemu.org/seabios.git +SEABIOS_UPSTREAM_TAG ?= 7fc039e9c262b4199fab497f3e12f4e425c37560 # Specify which qemu-dm to use. This may be `ioemu' to use the old # Mercurial in-tree version, or a local directory, or a git URL. @@ -212,15 +214,6 @@ QEMU_TAG ?= cd776ee9408ff127f934a707c1a3 # Short answer -- do not enable this unless you know what you are # doing and are prepared for some pain. -# SeaBIOS integration is a work in progress. Before enabling this -# option you must clone git://git.qemu.org/seabios.git/, possibly add -# some development patches and then build it yourself before pointing -# this variable to it (using an absolute path). -# -# Note that using SeaBIOS requires the use the upstream qemu as the -# device model. -SEABIOS_DIR ?= - # Optional components XENSTAT_XENTOP ?= y VTPM_TOOLS ?= n diff -r 9832a4edea7f tools/firmware/Makefile --- a/tools/firmware/Makefile Thu Sep 15 14:25:11 2011 +0000 +++ b/tools/firmware/Makefile Thu Sep 15 14:37:33 2011 +0000 @@ -6,13 +6,18 @@ TARGET := hvmloader/hvmloader INST_DIR := $(DESTDIR)$(XENFIRMWAREDIR) SUBDIRS := +SUBDIRS += seabios-dir SUBDIRS += rombios SUBDIRS += vgabios SUBDIRS += etherboot SUBDIRS += hvmloader +seabios-dir: + $(XEN_ROOT)/scripts/git-checkout.sh $(SEABIOS_UPSTREAM_URL) $(SEABIOS_UPSTREAM_TAG) seabios-dir + cp seabios-config seabios-dir/.config; + .PHONY: all -all: +all: seabios-dir @set -e; if [ $$((`( bcc -v 2>&1 | grep version || echo 0.0.0 ) | cut -d' ' -f 3 | awk -F. '{ printf "0x%02x%02x%02x", $$1, $$2, $$3}'`)) -lt $$((0x00100e)) ] ; then \ echo "==========================================================================="; \ echo "Require dev86 rpm or bin86 & bcc debs version >= 0.16.14 to build firmware!"; \ @@ -35,4 +40,7 @@ clean: subdirs-clean distclean: subdirs-distclean subdir-distclean-etherboot: .phony - $(MAKE) -C etherboot distclean \ No newline at end of file + $(MAKE) -C etherboot distclean + +subdir-distclean-seabios-dir: .phony + rm -rf seabios-dir seabios-dir-remote diff -r 9832a4edea7f tools/firmware/hvmloader/Makefile --- a/tools/firmware/hvmloader/Makefile Thu Sep 15 14:25:11 2011 +0000 +++ b/tools/firmware/hvmloader/Makefile Thu Sep 15 14:37:33 2011 +0000 @@ -44,6 +44,7 @@ CFLAGS += -DENABLE_ROMBIOS ROMBIOS_ROM := $(ROMBIOS_DIR)/BIOS-bochs-latest endif +SEABIOS_DIR := ../seabios-dir ifneq ($(SEABIOS_DIR),) OBJS += seabios.o CFLAGS += -DENABLE_SEABIOS diff -r 9832a4edea7f tools/firmware/seabios-config --- /dev/null Thu Jan 01 00:00:00 1970 +0000 +++ b/tools/firmware/seabios-config Thu Sep 15 14:37:33 2011 +0000 @@ -0,0 +1,73 @@ +# +# Automatically generated make config: don't edit +# SeaBIOS Configuration +# Wed Sep 7 13:03:21 2011 +# + +# +# General Features +# +# CONFIG_COREBOOT is not set +CONFIG_XEN=y +CONFIG_THREADS=y +# CONFIG_THREAD_OPTIONROMS is not set +CONFIG_RELOCATE_INIT=y +CONFIG_BOOTMENU=y +# CONFIG_BOOTSPLASH is not set +CONFIG_BOOTORDER=y + +# +# Hardware support +# +CONFIG_ATA=y +CONFIG_ATA_DMA=y +CONFIG_ATA_PIO32=y +CONFIG_AHCI=y +CONFIG_VIRTIO_BLK=y +CONFIG_FLOPPY=y +CONFIG_PS2PORT=y +CONFIG_USB=y +CONFIG_USB_UHCI=y +CONFIG_USB_OHCI=y +CONFIG_USB_EHCI=y +CONFIG_USB_MSC=y +CONFIG_USB_HUB=y +CONFIG_USB_KEYBOARD=y +CONFIG_USB_MOUSE=y +CONFIG_SERIAL=y +CONFIG_LPT=y +# CONFIG_USE_SMM is not set +CONFIG_MTRR_INIT=y + +# +# BIOS interfaces +# +CONFIG_DRIVES=y +CONFIG_CDROM_BOOT=y +CONFIG_CDROM_EMU=y +CONFIG_PCIBIOS=y +CONFIG_APMBIOS=y +CONFIG_PNPBIOS=y +CONFIG_OPTIONROMS=y +# CONFIG_OPTIONROMS_DEPLOYED is not set +CONFIG_PMM=y +CONFIG_BOOT=y +CONFIG_KEYBOARD=y +CONFIG_KBD_CALL_INT15_4F=y +CONFIG_MOUSE=y +CONFIG_S3_RESUME=y +# CONFIG_DISABLE_A20 is not set + +# +# BIOS Tables +# +CONFIG_PIRTABLE=y +CONFIG_MPTABLE=y +CONFIG_SMBIOS=y +CONFIG_ACPI=y + +# +# Debugging +# +CONFIG_DEBUG_LEVEL=1 +# CONFIG_DEBUG_SERIAL is not set _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel From xen-devel-bounces@lists.xensource.com Wed Sep 21 03:09:03 2011 Return-path: <xen-devel-bounces@lists.xensource.com> Envelope-to: www-data@lists.xensource.com Delivery-date: Wed, 21 Sep 2011 03:09:03 -0700 Received: from localhost ([127.0.0.1] helo=lists.colo.xensource.com) by lists.xensource.com with esmtp (Exim 4.43) id 1R6Jjh-00028R-0R; Wed, 21 Sep 2011 03:09:01 -0700 Received: from mail27.messagelabs.com ([193.109.254.147]) by lists.xensource.com with esmtp (Exim 4.43) id 1R6Jek-0001ET-F9 for xen-devel@lists.xensource.com; Wed, 21 Sep 2011 03:03:57 -0700 X-Env-Sender: Ian.Campbell@eu.citrix.com X-Msg-Ref: server-4.tower-27.messagelabs.com!1316599413!41143074!1 X-Originating-IP: [62.200.22.115] X-StarScan-Version: 6.4.1; banners=-,-,- X-VirusChecked: Checked Received: (qmail 6310 invoked from network); 21 Sep 2011 10:03:33 -0000 Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115) by server-4.tower-27.messagelabs.com with RC4-SHA encrypted SMTP; 21 Sep 2011 10:03:33 -0000 X-IronPort-AV: E=Sophos;i="4.68,416,1312156800"; d="scan'208";a="7973707" Received: from lonpmailmx01.citrite.net ([10.30.203.162]) by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5; 21 Sep 2011 10:03: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.137.0; Wed, 21 Sep 2011 11:03:51 +0100 From: Ian Campbell <Ian.Campbell@eu.citrix.com> To: Daniel De Graaf <dgdegra@tycho.nsa.gov> Date: Wed, 21 Sep 2011 11:03:50 +0100 In-Reply-To: <1316472208-12104-2-git-send-email-dgdegra@tycho.nsa.gov> References: <1313764724-12683-1-git-send-email-dgdegra@tycho.nsa.gov> <1316472208-12104-1-git-send-email-dgdegra@tycho.nsa.gov> <1316472208-12104-2-git-send-email-dgdegra@tycho.nsa.gov> Organization: Citrix Systems, Inc. Content-Type: text/plain; charset="UTF-8" X-Mailer: Evolution 3.0.3- Content-Transfer-Encoding: 7bit Message-ID: <1316599431.3891.147.camel@zakaz.uk.xensource.com> MIME-Version: 1.0 Cc: Stefano Stabellini <Stefano.Stabellini@eu.citrix.com>, "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>, Ian Jackson <Ian.Jackson@eu.citrix.com>, "konrad.wilk@oracle.com" <konrad.wilk@oracle.com> Subject: [Xen-devel] Re: [PATCH 1/3] libxc: add xc_gnttab_map_grant_ref_notify X-BeenThere: xen-devel@lists.xensource.com X-Mailman-Version: 2.1.5 Precedence: list List-Id: Xen developer discussion <xen-devel.lists.xensource.com> List-Unsubscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe> List-Post: <mailto:xen-devel@lists.xensource.com> List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help> List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=subscribe> Sender: xen-devel-bounces@lists.xensource.com Errors-To: xen-devel-bounces@lists.xensource.com On Mon, 2011-09-19 at 23:43 +0100, Daniel De Graaf wrote: > @@ -116,4 +116,35 @@ struct ioctl_gntdev_set_max_grants { > uint32_t count; > }; > > +/* > + * Sets up an unmap notification within the page, so that the other side can do > + * cleanup if this side crashes. Required to implement cross-domain robust > + * mutexes or close notification on communication channels. > + * > + * Each mapped page only supports one notification; multiple calls referring to > + * the same page overwrite the previous notification. You must clear the > + * notification prior to the IOCTL_GNTALLOC_DEALLOC_GREF if you do not want it > + * to occur. > + */ > +#define IOCTL_GNTDEV_SET_UNMAP_NOTIFY \ > +_IOC(_IOC_NONE, 'G', 7, sizeof(struct ioctl_gntdev_unmap_notify)) > +struct ioctl_gntdev_unmap_notify { > + /* IN parameters */ > + /* Offset in the file descriptor for a byte within the page (same as > + * used in mmap). I'm probably being thick but I don't understand what this means, i.e. what this thing is relative to. > If using UNMAP_NOTIFY_CLEAR_BYTE, this is the byte to > + * be cleared. Otherwise, it can be any byte in the page whose > + * notification we are adjusting. > + */ > + uint64_t index; > + /* Action(s) to take on unmap */ > + uint32_t action; > + /* Event channel to notify */ > + uint32_t event_channel_port; evtchn_port_t ? > +}; > + > +/* Clear (set to zero) the byte specified by index */ > +#define UNMAP_NOTIFY_CLEAR_BYTE 0x1 > +/* Send an interrupt on the indicated event channel */ > +#define UNMAP_NOTIFY_SEND_EVENT 0x2 > + > #endif /* __LINUX_PUBLIC_GNTDEV_H__ */ > diff --git a/tools/libxc/xc_gnttab.c b/tools/libxc/xc_gnttab.c > index 4f55fce..3d3c63b 100644 > --- a/tools/libxc/xc_gnttab.c > +++ b/tools/libxc/xc_gnttab.c > @@ -18,6 +18,7 @@ > */ > > #include "xc_private.h" > +#include <errno.h> > > int xc_gnttab_op(xc_interface *xch, int cmd, void * op, int op_size, int count) > { > @@ -174,6 +175,28 @@ void *xc_gnttab_map_domain_grant_refs(xc_gnttab *xcg, > count, domid, refs, prot); > } > > +void *xc_gnttab_map_grant_ref_notify(xc_gnttab *xcg, > + uint32_t domid, > + uint32_t ref, > + uint32_t notify_offset, > + evtchn_port_t notify_port, > + int *notify_result) > +{ > + if (xcg->ops->u.gnttab.map_grant_ref_notify) > + return xcg->ops->u.gnttab.map_grant_ref_notify(xcg, xcg->ops_handle, > + domid, ref, notify_offset, notify_port, notify_result); > + else { > + void* area = xcg->ops->u.gnttab.map_grant_ref(xcg, xcg->ops_handle, > + domid, ref, PROT_READ|PROT_WRITE); > + if (area && notify_result) { > + *notify_result = -1; > + errno = ENOSYS; > + } > + return area; > + } I think the new public interface is fine but do we really need a new internal interface here? I think you can just add the notify_* arguments to the existing OSDEP function and have those OS backends which don't implement that feature return ENOSYS if notify_offset != 0 (or ~0 or whatever invalid value works). Why doesn't the *_notify variant take a prot argument? I'd be tempted to do away with notify_result too -- if the caller asked for notification and we fail to give that then we can cleanup and return an error. If they want to try again without the notification then that's up to them. > +} > + > + > int xc_gnttab_munmap(xc_gnttab *xcg, > void *start_address, > uint32_t count) > diff --git a/tools/libxc/xc_linux_osdep.c b/tools/libxc/xc_linux_osdep.c > index dca6718..3040cb6 100644 > --- a/tools/libxc/xc_linux_osdep.c > +++ b/tools/libxc/xc_linux_osdep.c > @@ -613,6 +613,62 @@ static void *linux_gnttab_map_domain_grant_refs(xc_gnttab *xcg, xc_osdep_handle > return do_gnttab_map_grant_refs(xcg, h, count, &domid, 0, refs, prot); > } > > +static void *linux_gnttab_map_grant_ref_notify(xc_gnttab *xch, xc_osdep_handle h, > + uint32_t domid, uint32_t ref, > + uint32_t notify_offset, > + evtchn_port_t notify_port, > + int *notify_result) > +{ > + int fd = (int)h; > + int rv = 0; > + struct ioctl_gntdev_map_grant_ref map; > + struct ioctl_gntdev_unmap_notify notify; > + void *addr; > + > + map.count = 1; > + map.refs[0].domid = domid; > + map.refs[0].ref = ref; > + > + if ( ioctl(fd, IOCTL_GNTDEV_MAP_GRANT_REF, &map) ) { > + PERROR("xc_gnttab_map_grant_ref: ioctl MAP_GRANT_REF failed"); > + return NULL; > + } > + > + addr = mmap(NULL, XC_PAGE_SIZE, PROT_READ|PROT_WRITE, MAP_SHARED, fd, map.index); > + if ( addr == MAP_FAILED ) > + { > + int saved_errno = errno; > + struct ioctl_gntdev_unmap_grant_ref unmap_grant; > + > + PERROR("xc_gnttab_map_grant_ref: mmap failed"); > + unmap_grant.index = map.index; > + unmap_grant.count = 1; > + ioctl(fd, IOCTL_GNTDEV_UNMAP_GRANT_REF, &unmap_grant); > + errno = saved_errno; > + return NULL; > + } The non-notify variant handles EAGAIN, why doesn't this one need to do so? > + > + notify.index = map.index; > + notify.action = 0; > + if (notify_offset >= 0) { > + notify.index += notify_offset; > + notify.action |= UNMAP_NOTIFY_CLEAR_BYTE; > + } > + if (notify_port >= 0) { > + notify.event_channel_port = notify_port; > + notify.action |= UNMAP_NOTIFY_SEND_EVENT; > + } > + if (notify.action) > + rv = ioctl(fd, IOCTL_GNTDEV_SET_UNMAP_NOTIFY, ¬ify); Is there a race if the other end (or this process) dies between the MAP ioctl and here? Ian. _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel From xen-devel-bounces@lists.xensource.com Wed Sep 21 03:11:55 2011 Return-path: <xen-devel-bounces@lists.xensource.com> Envelope-to: www-data@lists.xensource.com Delivery-date: Wed, 21 Sep 2011 03:11:55 -0700 Received: from localhost ([127.0.0.1] helo=lists.colo.xensource.com) by lists.xensource.com with esmtp (Exim 4.43) id 1R6JmV-0002bq-Hr; Wed, 21 Sep 2011 03:11:55 -0700 Received: from mail174.messagelabs.com ([85.158.138.51]) by lists.xensource.com with esmtp (Exim 4.43) id 1R6JlV-0002Nn-4c for xen-devel@lists.xensource.com; Wed, 21 Sep 2011 03:10:56 -0700 X-Env-Sender: Christoph.Egger@amd.com X-Msg-Ref: server-3.tower-174.messagelabs.com!1316599848!26161918!1 X-Originating-IP: [65.55.88.13] X-StarScan-Version: 6.4.1; banners=-,-,- X-VirusChecked: Checked Received: (qmail 24191 invoked from network); 21 Sep 2011 10:10:50 -0000 Received: from tx2ehsobe003.messaging.microsoft.com (HELO TX2EHSOBE005.bigfish.com) (65.55.88.13) by server-3.tower-174.messagelabs.com with AES128-SHA encrypted SMTP; 21 Sep 2011 10:10:50 -0000 Received: from mail84-tx2-R.bigfish.com (10.9.14.241) by TX2EHSOBE005.bigfish.com (10.9.40.25) with Microsoft SMTP Server id 14.1.225.22; Wed, 21 Sep 2011 10:10:48 +0000 Received: from mail84-tx2 (localhost.localdomain [127.0.0.1]) by mail84-tx2-R.bigfish.com (Postfix) with ESMTP id 7A4FF19E03DE; Wed, 21 Sep 2011 10:10:48 +0000 (UTC) X-SpamScore: -11 X-BigFish: VPS-11(zzbb2dK1432N98dKzz1202hzz8275bhz32i668h839h62h) X-Spam-TCS-SCL: 1:0 X-Forefront-Antispam-Report: CIP:163.181.249.108; KIP:(null); UIP:(null); IPVD:NLI; H:ausb3twp01.amd.com; RD:none; EFVD:NLI X-FB-SS: 0, Received: from mail84-tx2 (localhost.localdomain [127.0.0.1]) by mail84-tx2 (MessageSwitch) id 1316599821863565_23800; Wed, 21 Sep 2011 10:10:21 +0000 (UTC) Received: from TX2EHSMHS024.bigfish.com (unknown [10.9.14.242]) by mail84-tx2.bigfish.com (Postfix) with ESMTP id 3A46E1A88052; Wed, 21 Sep 2011 10:10:21 +0000 (UTC) Received: from ausb3twp01.amd.com (163.181.249.108) by TX2EHSMHS024.bigfish.com (10.9.99.124) with Microsoft SMTP Server id 14.1.225.22; Wed, 21 Sep 2011 10:10:16 +0000 X-WSS-ID: 0LRVAX0-01-07Z-02 X-M-MSG: Received: from sausexedgep01.amd.com (sausexedgep01-ext.amd.com [163.181.249.72]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by ausb3twp01.amd.com (Axway MailGate 3.8.1) with ESMTP id 28C461028277; Wed, 21 Sep 2011 05:10:11 -0500 (CDT) Received: from sausexhtp01.amd.com (163.181.3.165) by sausexedgep01.amd.com (163.181.36.54) with Microsoft SMTP Server (TLS) id 8.3.106.1; Wed, 21 Sep 2011 05:10:25 -0500 Received: from storexhtp02.amd.com (172.24.4.4) by sausexhtp01.amd.com (163.181.3.165) with Microsoft SMTP Server (TLS) id 8.3.83.0; Wed, 21 Sep 2011 05:10:14 -0500 Received: from rhodium.osrc.amd.com (165.204.15.173) by storexhtp02.amd.com (172.24.4.4) with Microsoft SMTP Server id 8.3.83.0; Wed, 21 Sep 2011 06:10:13 -0400 Message-ID: <4E79B802.8050401@amd.com> Date: Wed, 21 Sep 2011 12:10:10 +0200 From: Christoph Egger <Christoph.Egger@amd.com> User-Agent: Mozilla/5.0 (X11; U; NetBSD amd64; en-US; rv:1.9.2.17) Gecko/20110523 Lightning/1.0b3pre Thunderbird/3.1.10 MIME-Version: 1.0 To: "stefano.stabellini@eu.citrix.com" <stefano.stabellini@eu.citrix.com> Subject: Re: [Xen-devel] [PATCH v5 3/4] Clone and build upstream Qemu by default References: <alpine.DEB.2.00.1109211051270.8700@kaball-desktop> <1316598917-21515-3-git-send-email-stefano.stabellini@eu.citrix.com> In-Reply-To: <1316598917-21515-3-git-send-email-stefano.stabellini@eu.citrix.com> Content-Type: text/plain; charset="ISO-8859-1"; format=flowed Content-Transfer-Encoding: 7bit X-OriginatorOrg: amd.com Cc: "Ian.Campbell@eu.citrix.com" <Ian.Campbell@eu.citrix.com>, "keir@xen.org" <keir@xen.org>, "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>, "Ian.Jackson@eu.citrix.com" <Ian.Jackson@eu.citrix.com> X-BeenThere: xen-devel@lists.xensource.com X-Mailman-Version: 2.1.5 Precedence: list List-Id: Xen developer discussion <xen-devel.lists.xensource.com> List-Unsubscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe> List-Post: <mailto:xen-devel@lists.xensource.com> List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help> List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=subscribe> Sender: xen-devel-bounces@lists.xensource.com Errors-To: xen-devel-bounces@lists.xensource.com On 09/21/11 11:55, stefano.stabellini@eu.citrix.com wrote: > Signed-off-by: Stefano Stabellini<stefano.stabellini@eu.citrix.com> > > diff -r 51795795b213 .hgignore > --- a/.hgignore Wed Sep 21 09:48:34 2011 +0000 > +++ b/.hgignore Wed Sep 21 09:48:52 2011 +0000 > @@ -293,6 +293,8 @@ > ^tools/xm-test/tests/.*\.test$ > ^tools/qemu-xen-traditional-dir-remote > ^tools/qemu-xen-traditional-dir$ > +^tools/qemu-xen-dir-remote > +^tools/qemu-xen-dir$ > ^tools/ocaml/.*/.*\.annot$ > ^tools/ocaml/.*/.*\.cmx?a$ > ^tools/ocaml/.*/META$ > diff -r 51795795b213 Config.mk > --- a/Config.mk Wed Sep 21 09:48:34 2011 +0000 > +++ b/Config.mk Wed Sep 21 09:48:52 2011 +0000 > @@ -192,6 +192,13 @@ else > QEMU_REMOTE=git://xenbits.xensource.com/qemu-xen-unstable.git > endif > > +ifeq ($(GIT_HTTP),y) > +QEMU_UPSTREAM_URL ?= http://xenbits.xensource.com/git-http/qemu-upstream-unstable.git > +else > +QEMU_UPSTREAM_URL ?= git://xenbits.xensource.com/qemu-upstream-unstable.git > +endif > +QEMU_UPSTREAM_TAG ?= 6dd84c71dff047f9e492d67e7c99928d09202760 > + > # Specify which qemu-dm to use. This may be `ioemu' to use the old > # Mercurial in-tree version, or a local directory, or a git URL. > # CONFIG_QEMU ?= `pwd`/$(XEN_ROOT)/../qemu-xen.git > diff -r 51795795b213 Makefile > --- a/Makefile Wed Sep 21 09:48:34 2011 +0000 > +++ b/Makefile Wed Sep 21 09:48:52 2011 +0000 > @@ -70,7 +70,7 @@ install-tools: > $(MAKE) -C tools install > > ifeq ($(CONFIG_IOEMU),y) > -install-tools: tools/qemu-xen-traditional-dir > +install-tools: tools/qemu-xen-traditional-dir tools/qemu-xen-dir > endif > > .PHONY: install-kernels > @@ -91,6 +91,9 @@ tools/qemu-xen-traditional-dir: > tools/qemu-xen-traditional-dir-force-update: > $(MAKE) -C tools qemu-xen-traditional-dir-force-update > > +tools/qemu-xen-dir: > + $(MAKE) -C tools qemu-xen-dir-find > + > .PHONY: install-docs > install-docs: > sh ./docs/check_pkgs&& $(MAKE) -C docs install || true > diff -r 51795795b213 tools/Makefile > --- a/tools/Makefile Wed Sep 21 09:48:34 2011 +0000 > +++ b/tools/Makefile Wed Sep 21 09:48:52 2011 +0000 > @@ -31,6 +31,7 @@ SUBDIRS-$(LIBXENAPI_BINDINGS) += libxen > # do not recurse in to a dir we are about to delete > ifneq "$(MAKECMDGOALS)" "distclean" > SUBDIRS-$(CONFIG_IOEMU) += qemu-xen-traditional-dir > +SUBDIRS-$(CONFIG_IOEMU) += qemu-xen-dir > endif > > SUBDIRS-y += xenpmd > @@ -71,6 +72,7 @@ clean: subdirs-clean > .PHONY: distclean > distclean: subdirs-distclean > rm -rf qemu-xen-traditional-dir qemu-xen-traditional-dir-remote > + rm -rf qemu-xen-dir qemu-xen-dir-remote > > ifneq ($(XEN_COMPILE_ARCH),$(XEN_TARGET_ARCH)) > IOEMU_CONFIGURE_CROSS ?= --cpu=$(XEN_TARGET_ARCH) \ > @@ -95,6 +97,24 @@ qemu-xen-traditional-dir-find: > cd qemu-xen-traditional-dir; \ > $(QEMU_ROOT)/xen-setup $(IOEMU_CONFIGURE_CROSS) > > +qemu-xen-dir-find: > + if test -d $(QEMU_UPSTREAM_URL) ; then \ > + ln -sf $(QEMU_UPSTREAM_URL) qemu-xen-dir; \ > + else \ > + $(XEN_ROOT)/scripts/git-checkout.sh $(QEMU_UPSTREAM_URL) $(QEMU_UPSTREAM_TAG) qemu-xen-dir ; \ > + fi > + cd qemu-xen-dir; \ > + ./configure --enable-xen --target-list=i386-softmmu \ > + --source-path=$$ROOT \ > + --extra-cflags="-I$(XEN_ROOT)/tools/include \ > + -I$(XEN_ROOT)/tools/libxc \ > + -I$(XEN_ROOT)/tools/xenstore" \ > + --extra-ldflags="-L$(XEN_ROOT)/tools/libxc \ > + -L$(XEN_ROOT)/tools/libxenstore" \ > + --bindir=/usr/lib/xen/bin \ This doesn't work on NetBSD and also breaks installations into non-default directories. Please use --bindir=$(LIBEXEC) Christoph > + --disable-kvm \ > + $(IOEMU_CONFIGURE_CROSS) > + > .PHONY: qemu-xen-traditional-dir-force-update > qemu-xen-traditional-dir-force-update: > set -ex; \ > @@ -112,6 +132,14 @@ subdir-clean-qemu-xen-traditional-dir: > $(MAKE) -C qemu-xen-traditional-dir clean; \ > fi > > +subdir-all-qemu-xen-dir subdir-install-qemu-xen-dir: qemu-xen-dir-find > + > +subdir-clean-qemu-xen-dir: > + set -e; if test -d qemu-xen-dir/.; then \ > + $(buildmakevars2shellvars); \ > + $(MAKE) -C qemu-xen-dir clean; \ > + fi > + > subdir-clean-debugger/gdbsx subdir-distclean-debugger/gdbsx: .phony > $(MAKE) -C debugger/gdbsx clean > > > _______________________________________________ > Xen-devel mailing list > Xen-devel@lists.xensource.com > http://lists.xensource.com/xen-devel > -- ---to satisfy European Law for business letters: Advanced Micro Devices GmbH Einsteinring 24, 85689 Dornach b. Muenchen Geschaeftsfuehrer: Alberto Bozzo, Andrew Bowd Sitz: Dornach, Gemeinde Aschheim, Landkreis Muenchen Registergericht Muenchen, HRB Nr. 43632 _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel From xen-devel-bounces@lists.xensource.com Wed Sep 21 03:14:27 2011 Return-path: <xen-devel-bounces@lists.xensource.com> Envelope-to: www-data@lists.xensource.com Delivery-date: Wed, 21 Sep 2011 03:14:27 -0700 Received: from localhost ([127.0.0.1] helo=lists.colo.xensource.com) by lists.xensource.com with esmtp (Exim 4.43) id 1R6Jox-00033g-AP; Wed, 21 Sep 2011 03:14:27 -0700 Received: from mail174.messagelabs.com ([85.158.138.51]) by lists.xensource.com with esmtp (Exim 4.43) id 1R6Jnd-0002pa-MF for xen-devel@lists.xensource.com; Wed, 21 Sep 2011 03:13:06 -0700 X-Env-Sender: Ian.Campbell@eu.citrix.com X-Msg-Ref: server-13.tower-174.messagelabs.com!1316599982!32235286!1 X-Originating-IP: [62.200.22.115] X-StarScan-Version: 6.4.1; banners=-,-,- X-VirusChecked: Checked Received: (qmail 4327 invoked from network); 21 Sep 2011 10:13:02 -0000 Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115) by server-13.tower-174.messagelabs.com with RC4-SHA encrypted SMTP; 21 Sep 2011 10:13:02 -0000 X-IronPort-AV: E=Sophos;i="4.68,416,1312156800"; d="scan'208";a="7973942" Received: from lonpmailmx01.citrite.net ([10.30.203.162]) by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5; 21 Sep 2011 10:13:02 +0000 Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net (10.30.203.162) with Microsoft SMTP Server id 8.3.137.0; Wed, 21 Sep 2011 11:13:02 +0100 From: Ian Campbell <Ian.Campbell@eu.citrix.com> To: Daniel De Graaf <dgdegra@tycho.nsa.gov> Date: Wed, 21 Sep 2011 11:13:02 +0100 In-Reply-To: <1316472208-12104-3-git-send-email-dgdegra@tycho.nsa.gov> References: <1313764724-12683-1-git-send-email-dgdegra@tycho.nsa.gov> <1316472208-12104-1-git-send-email-dgdegra@tycho.nsa.gov> <1316472208-12104-3-git-send-email-dgdegra@tycho.nsa.gov> Organization: Citrix Systems, Inc. Content-Type: text/plain; charset="UTF-8" X-Mailer: Evolution 3.0.3- Content-Transfer-Encoding: 7bit Message-ID: <1316599982.3891.151.camel@zakaz.uk.xensource.com> MIME-Version: 1.0 Cc: Stefano Stabellini <Stefano.Stabellini@eu.citrix.com>, "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>, Ian Jackson <Ian.Jackson@eu.citrix.com>, "konrad.wilk@oracle.com" <konrad.wilk@oracle.com> Subject: [Xen-devel] Re: [PATCH 2/3] libxc: add xc_gntshr_* functions X-BeenThere: xen-devel@lists.xensource.com X-Mailman-Version: 2.1.5 Precedence: list List-Id: Xen developer discussion <xen-devel.lists.xensource.com> List-Unsubscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe> List-Post: <mailto:xen-devel@lists.xensource.com> List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help> List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=subscribe> Sender: xen-devel-bounces@lists.xensource.com Errors-To: xen-devel-bounces@lists.xensource.com On Mon, 2011-09-19 at 23:43 +0100, Daniel De Graaf wrote: > +static void *linux_gntshr_share_pages(xc_gntshr *xch, xc_osdep_handle h, > + uint32_t domid, int count, > + uint32_t *refs, int writable) > [...] > +static void *linux_gntshr_share_page_notify(xc_gntshr *xch, xc_osdep_handle h, > + uint32_t domid, uint32_t *ref, > + int writable, uint32_t notify_offset, > + evtchn_port_t notify_port, > + int *notify_result) I have the same opinion of the need for both of these as for the gntmap ones. They are identical apart from the notify block in the middle, right? Ian. _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel From xen-devel-bounces@lists.xensource.com Wed Sep 21 03:23:50 2011 Return-path: <xen-devel-bounces@lists.xensource.com> Envelope-to: www-data@lists.xensource.com Delivery-date: Wed, 21 Sep 2011 03:23:50 -0700 Received: from localhost ([127.0.0.1] helo=lists.colo.xensource.com) by lists.xensource.com with esmtp (Exim 4.43) id 1R6Jy2-0003eA-Gm; Wed, 21 Sep 2011 03:23:50 -0700 Received: from mail216.messagelabs.com ([85.158.143.99]) by lists.xensource.com with esmtp (Exim 4.43) id 1R6JxU-0003SP-Oa for xen-devel@lists.xensource.com; Wed, 21 Sep 2011 03:23:17 -0700 X-Env-Sender: juergen.gross@ts.fujitsu.com X-Msg-Ref: server-2.tower-216.messagelabs.com!1316600593!18629770!1 X-Originating-IP: [80.70.172.51] X-StarScan-Version: 6.4.1; banners=-,-,- X-VirusChecked: Checked Received: (qmail 22978 invoked from network); 21 Sep 2011 10:23:13 -0000 Received: from dgate20.ts.fujitsu.com (HELO dgate20.ts.fujitsu.com) (80.70.172.51) by server-2.tower-216.messagelabs.com with RC4-SHA encrypted SMTP; 21 Sep 2011 10:23:13 -0000 DomainKey-Signature: s=s1536a; d=ts.fujitsu.com; c=nofws; q=dns; h=X-SBRSScore:X-IronPort-AV:Received:X-IronPort-AV: Received:Received:Message-ID:Date:From:Organization: User-Agent:MIME-Version:To:CC:Subject:References: In-Reply-To:Content-Type:Content-Transfer-Encoding; b=N9WhDWbd1pPk2RZpnN3yscZ8alILx9CUke/dCKy3LQNbPopLbDSoFyvZ bUjHXRVbSGF16CsdD/C3EBLD3h/nNr8B2uBBpanHlcVz1Ov0pxcLWkxcO jFGEjIysnb+xNqY6UoJNTpRUuqYhnYMNh2LL1JnaOXHMuZgSSHN72H9H/ nw8Q5Jyl+urZgrGDWIMabh40JoHwXNQqiWtqdDlrLpoXDIyrQXhrha8Vk jRWdjlhlb9hfbX22JUmT2QtBtZDO0; DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=ts.fujitsu.com; i=juergen.gross@ts.fujitsu.com; q=dns/txt; s=s1536b; t=1316600593; x=1348136593; h=message-id:date:from:mime-version:to:cc:subject: references:in-reply-to:content-transfer-encoding; bh=cPKCnJ6e5k6m8DhT2NCc9LGPPIJHABzrERpSsYVWoL0=; b=QN7WX+KD4E44jtVFGotbdvojlYxODpvJH3CxRkvNTF8CbDznzJ/0toI2 c7/v03OBu64iEHSKsaYsBRKfHiTbP8a06uyuGx0ZJE7RyivzX+xtG5pWF V6Yd1xn6Kp16St/tBBhY5VOj06LGCxG/d+htInPjDFco61lM0dmAkRiNQ f1UAQ0JaHgVJgse0/tt/E0qJcFuK7Zi/hyW8kX8cwYugz2fCsNr1cdJrJ +yMhxmHtfvL4Ij0lkJgjY2V05wGSf; X-SBRSScore: None X-IronPort-AV: E=Sophos;i="4.68,416,1312149600"; d="scan'208";a="74920445" Received: from abgdgate30u.abg.fsc.net ([172.25.138.66]) by dgate20u.abg.fsc.net with ESMTP; 21 Sep 2011 12:23:13 +0200 X-IronPort-AV: E=Sophos;i="4.68,416,1312149600"; d="scan'208";a="119925935" Received: from sanpedro.mch.fsc.net ([172.17.20.6]) by abgdgate30u.abg.fsc.net with ESMTP; 21 Sep 2011 12:23:13 +0200 Received: from [172.17.21.50] (verdon.osd.mch.fsc.net [172.17.21.50]) by sanpedro.mch.fsc.net (Postfix) with ESMTP id 2498B959B5E; Wed, 21 Sep 2011 12:23:13 +0200 (CEST) Message-ID: <4E79BB11.5040005@ts.fujitsu.com> Date: Wed, 21 Sep 2011 12:23:13 +0200 From: Juergen Gross <juergen.gross@ts.fujitsu.com> Organization: Fujitsu Technology Solutions User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.2.21) Gecko/20110831 Iceowl/1.0b2 Icedove/3.1.13 MIME-Version: 1.0 To: stefano.stabellini@eu.citrix.com Subject: Re: [Xen-devel] [PATCH v5 1/4] Introduce git-checkout.sh References: <alpine.DEB.2.00.1109211051270.8700@kaball-desktop> <1316598917-21515-1-git-send-email-stefano.stabellini@eu.citrix.com> In-Reply-To: <1316598917-21515-1-git-send-email-stefano.stabellini@eu.citrix.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: Ian.Campbell@eu.citrix.com, keir@xen.org, xen-devel@lists.xensource.com, Ian.Jackson@eu.citrix.com X-BeenThere: xen-devel@lists.xensource.com X-Mailman-Version: 2.1.5 Precedence: list List-Id: Xen developer discussion <xen-devel.lists.xensource.com> List-Unsubscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe> List-Post: <mailto:xen-devel@lists.xensource.com> List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help> List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=subscribe> Sender: xen-devel-bounces@lists.xensource.com Errors-To: xen-devel-bounces@lists.xensource.com On 09/21/2011 11:55 AM, stefano.stabellini@eu.citrix.com wrote: > Introduce a script to perform git checkout on an external git tree; use > git-checkout.sh in ioemu-dir-find. > > Signed-off-by: Stefano Stabellini<stefano.stabellini@eu.citrix.com> > > diff --git a/.hgignore b/.hgignore > --- a/.hgignore > +++ b/.hgignore > @@ -291,7 +291,7 @@ > ^tools/xm-test/lib/XmTestLib/config.py$ > ^tools/xm-test/lib/XmTestReport/xmtest.py$ > ^tools/xm-test/tests/.*\.test$ > -^tools/ioemu-remote > +^tools/ioemu-dir-remote > ^tools/ioemu-dir$ > ^tools/ocaml/.*/.*\.annot$ > ^tools/ocaml/.*/.*\.cmx?a$ > diff --git a/scripts/git-checkout.sh b/scripts/git-checkout.sh > new file mode 100755 > --- /dev/null > +++ b/scripts/git-checkout.sh > @@ -0,0 +1,21 @@ > +#!/bin/sh > + > +TREE=$1 > +TAG=$2 > +DIR=$3 > + > + > +if test \! -d $DIR-remote; then > + rm -rf $DIR-remote $DIR-remote.tmp; > + mkdir $DIR-remote.tmp; rmdir $DIR-remote.tmp; > + git clone $TREE $DIR-remote.tmp; > + if test "$TAG" ; then > + cd $DIR-remote.tmp > + git branch -D dummy>/dev/null 2>&1 ||: > + git checkout -b dummy $TAG Can't you use $GIT here? This would enable using GIT="socksify git" (e.g. behind a firewall). Juergen > + cd .. > + fi > + mv $DIR-remote.tmp $DIR-remote > +fi > +rm -f $DIR > +ln -sf $DIR-remote $DIR > diff --git a/tools/Makefile b/tools/Makefile > --- a/tools/Makefile > +++ b/tools/Makefile > @@ -70,7 +70,7 @@ clean: subdirs-clean > > .PHONY: distclean > distclean: subdirs-distclean > - rm -rf ioemu-dir ioemu-remote > + rm -rf ioemu-dir ioemu-dir-remote > > ifneq ($(XEN_COMPILE_ARCH),$(XEN_TARGET_ARCH)) > IOEMU_CONFIGURE_CROSS ?= --cpu=$(XEN_TARGET_ARCH) \ > @@ -88,20 +88,7 @@ ioemu-dir-find: > if test -d $(CONFIG_QEMU); then \ > mkdir -p ioemu-dir; \ > else \ > - if [ ! -d ioemu-remote ]; then \ > - rm -rf ioemu-remote ioemu-remote.tmp; \ > - mkdir ioemu-remote.tmp; rmdir ioemu-remote.tmp; \ > - $(GIT) clone $(CONFIG_QEMU) ioemu-remote.tmp; \ > - if [ "$(QEMU_TAG)" ]; then \ > - cd ioemu-remote.tmp; \ > - $(GIT) branch -D dummy>/dev/null 2>&1 ||:; \ > - $(GIT) checkout -b dummy $(QEMU_TAG); \ > - cd ..; \ > - fi; \ > - mv ioemu-remote.tmp ioemu-remote; \ > - fi; \ > - rm -f ioemu-dir; \ > - ln -sf ioemu-remote ioemu-dir; \ > + $(XEN_ROOT)/scripts/git-checkout.sh $(CONFIG_QEMU) $(QEMU_TAG) ioemu-dir; \ > fi > set -e; \ > $(buildmakevars2shellvars); \ > @@ -112,7 +99,7 @@ ioemu-dir-find: > ioemu-dir-force-update: > set -ex; \ > if [ "$(QEMU_TAG)" ]; then \ > - cd ioemu-remote; \ > + cd ioemu-dir-remote; \ > $(GIT) fetch origin; \ > $(GIT) reset --hard $(QEMU_TAG); \ > fi > > _______________________________________________ > Xen-devel mailing list > Xen-devel@lists.xensource.com > http://lists.xensource.com/xen-devel > > -- Juergen Gross Principal Developer Operating Systems PDG ES&S SWE OS6 Telephone: +49 (0) 89 3222 2967 Fujitsu Technology Solutions e-mail: juergen.gross@ts.fujitsu.com Domagkstr. 28 Internet: ts.fujitsu.com D-80807 Muenchen Company details: ts.fujitsu.com/imprint.html _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel From xen-devel-bounces@lists.xensource.com Wed Sep 21 03:43:03 2011 Return-path: <xen-devel-bounces@lists.xensource.com> Envelope-to: www-data@lists.xensource.com Delivery-date: Wed, 21 Sep 2011 03:43:03 -0700 Received: from localhost ([127.0.0.1] helo=lists.colo.xensource.com) by lists.xensource.com with esmtp (Exim 4.43) id 1R6KGc-0004X7-Ol; Wed, 21 Sep 2011 03:43:03 -0700 Received: from mail216.messagelabs.com ([85.158.143.99]) by lists.xensource.com with esmtp (Exim 4.43) id 1R6KFp-0004LG-Hk for xen-devel@lists.xensource.com; Wed, 21 Sep 2011 03:42:13 -0700 X-Env-Sender: Stefano.Stabellini@eu.citrix.com X-Msg-Ref: server-7.tower-216.messagelabs.com!1316601730!19072121!1 X-Originating-IP: [62.200.22.115] X-StarScan-Version: 6.4.1; banners=-,-,- X-VirusChecked: Checked Received: (qmail 13762 invoked from network); 21 Sep 2011 10:42:10 -0000 Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115) by server-7.tower-216.messagelabs.com with RC4-SHA encrypted SMTP; 21 Sep 2011 10:42:10 -0000 X-IronPort-AV: E=Sophos;i="4.68,416,1312156800"; d="scan'208";a="7974710" Received: from lonpmailmx01.citrite.net ([10.30.203.162]) by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5; 21 Sep 2011 10:42:10 +0000 Received: from kaball.uk.xensource.com (10.80.2.59) by LONPMAILMX01.citrite.net (10.30.203.162) with Microsoft SMTP Server id 8.3.137.0; Wed, 21 Sep 2011 11:42:10 +0100 Date: Wed, 21 Sep 2011 11:42:01 +0100 From: Stefano Stabellini <stefano.stabellini@eu.citrix.com> X-X-Sender: sstabellini@kaball-desktop To: Jeremy Fitzhardinge <jeremy@goop.org> In-Reply-To: <4E727017.4030001@goop.org> Message-ID: <alpine.DEB.2.00.1109211124050.8700@kaball-desktop> References: <1316090411-22608-1-git-send-email-david.vrabel@citrix.com> <4E727017.4030001@goop.org> User-Agent: Alpine 2.00 (DEB 1167 2008-08-23) MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Cc: "linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>, Andrew Morton <akpm@linux-foundation.org>, "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>, David Vrabel <david.vrabel@citrix.com>, Konrad Rzeszutek Wilk <konrad.wilk@oracle.com> Subject: [Xen-devel] Re: [PATCH 0/6] xen: don't call vmalloc_sync_all() when mapping foreign pages X-BeenThere: xen-devel@lists.xensource.com X-Mailman-Version: 2.1.5 Precedence: list List-Id: Xen developer discussion <xen-devel.lists.xensource.com> List-Unsubscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe> List-Post: <mailto:xen-devel@lists.xensource.com> List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help> List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=subscribe> Sender: xen-devel-bounces@lists.xensource.com Errors-To: xen-devel-bounces@lists.xensource.com On Thu, 15 Sep 2011, Jeremy Fitzhardinge wrote: > On 09/15/2011 05:40 AM, David Vrabel wrote: > > This set of pages avoids the need to call vmalloc_sync_all() when > > mapping foreign pages. Two new functions are adding for mapping > > foreign pages onto RAM pages instead of vmalloc space. > > > > This does waste a page of RAM for each mapped page. In the future a > > ballooned page could be used instead (once the API for getting a > > ballooned page with the right GFP flags is available). > > You can allocate a pfn, free ("balloon out") the underlying mfn, and > replace it with a granted page; it doesn't need any particular new > infrastructure. David, give a look at drivers/xen/balloon.c:alloc_xenballooned_pages, in particular after my changes to it: http://marc.info/?l=linux-kernel&m=131552369305998&w=2 it allows the caller to allocate a lowmem page and balloon it out right away. > But that said, if you want to allocate virtual addresses for mapping > granted pages, then alloc_vm_area() is the right thing to use. You need > to make sure you touch the pages from within the kernel before passing > those addresses to a hypercall to make sure the mappings are established > within the current task (possibly within a no-preempt region to > guarantee that nothing odd happens). Or alternatively, you could switch > the current pagetable to init_mm for the hypercall (if it isn't already) > - since that's the reference pagetable - assuming you're not passing > usermode virtual addresses to the hypercall. This problem is not very different from the one we are trying to solve with alloc_xenballooned_pages: in case we want a page that is mapped in kernel space we just use allocate a lowmem page, balloon it out, change the p2m and add the page to the m2p_override. Why should we solve that issue differently? > This series is relying on regular ram mappings are already synced to all > tasks, but I'm not sure that's necessarily guaranteed (for example, if > you hotplug new memory into the domain, the new pages won't be mapped > into every mm unless they're synced). the series is using GFP_KERNEL, so this problem shouldn't occur, right? _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel From xen-devel-bounces@lists.xensource.com Wed Sep 21 03:54:24 2011 Return-path: <xen-devel-bounces@lists.xensource.com> Envelope-to: www-data@lists.xensource.com Delivery-date: Wed, 21 Sep 2011 03:54:24 -0700 Received: from localhost ([127.0.0.1] helo=lists.colo.xensource.com) by lists.xensource.com with esmtp (Exim 4.43) id 1R6KRb-00054O-TW; Wed, 21 Sep 2011 03:54:23 -0700 Received: from mail174.messagelabs.com ([85.158.138.51]) by lists.xensource.com with esmtp (Exim 4.43) id 1R6KR0-0004s0-3P for xen-devel@lists.xensource.com; Wed, 21 Sep 2011 03:53:46 -0700 X-Env-Sender: Ian.Campbell@eu.citrix.com X-Msg-Ref: server-14.tower-174.messagelabs.com!1316602422!32228015!1 X-Originating-IP: [62.200.22.115] X-StarScan-Version: 6.4.1; banners=-,-,- X-VirusChecked: Checked Received: (qmail 4892 invoked from network); 21 Sep 2011 10:53:42 -0000 Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115) by server-14.tower-174.messagelabs.com with RC4-SHA encrypted SMTP; 21 Sep 2011 10:53:42 -0000 X-IronPort-AV: E=Sophos;i="4.68,416,1312156800"; d="scan'208";a="7974989" Received: from lonpmailmx01.citrite.net ([10.30.203.162]) by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5; 21 Sep 2011 10:53:42 +0000 Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net (10.30.203.162) with Microsoft SMTP Server id 8.3.137.0; Wed, 21 Sep 2011 11:53:42 +0100 From: Ian Campbell <Ian.Campbell@eu.citrix.com> To: Daniel De Graaf <dgdegra@tycho.nsa.gov> Date: Wed, 21 Sep 2011 11:53:42 +0100 In-Reply-To: <1316472208-12104-4-git-send-email-dgdegra@tycho.nsa.gov> References: <1313764724-12683-1-git-send-email-dgdegra@tycho.nsa.gov> <1316472208-12104-1-git-send-email-dgdegra@tycho.nsa.gov> <1316472208-12104-4-git-send-email-dgdegra@tycho.nsa.gov> Organization: Citrix Systems, Inc. Content-Type: text/plain; charset="UTF-8" X-Mailer: Evolution 3.0.3- Content-Transfer-Encoding: 7bit Message-ID: <1316602422.3891.171.camel@zakaz.uk.xensource.com> MIME-Version: 1.0 Cc: Stefano Stabellini <Stefano.Stabellini@eu.citrix.com>, "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>, Ian Jackson <Ian.Jackson@eu.citrix.com>, "konrad.wilk@oracle.com" <konrad.wilk@oracle.com> Subject: [Xen-devel] Re: [PATCH 3/3] libvchan: interdomain communications library X-BeenThere: xen-devel@lists.xensource.com X-Mailman-Version: 2.1.5 Precedence: list List-Id: Xen developer discussion <xen-devel.lists.xensource.com> List-Unsubscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe> List-Post: <mailto:xen-devel@lists.xensource.com> List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help> List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=subscribe> Sender: xen-devel-bounces@lists.xensource.com Errors-To: xen-devel-bounces@lists.xensource.com On Mon, 2011-09-19 at 23:43 +0100, Daniel De Graaf wrote: > This library implements a bidirectional communication interface between > applications in different domains, similar to unix sockets. Data can be > sent using the byte-oriented libvchan_read/libvchan_write or the > packet-oriented libvchan_recv/libvchan_send. > > Channel setup is done using a client-server model; domain IDs and a port > number must be negotiated prior to initialization. The server allocates > memory for the shared pages and determines the sizes of the > communication rings (which may span multiple pages, although the default > places rings and control within a single page). > > With properly sized rings, testing has shown that this interface > provides speed comparable to pipes within a single Linux domain; it is > significantly faster than network-based communication. > > Signed-off-by: Daniel De Graaf <dgdegra@tycho.nsa.gov> I only skimmed this one I had a few minor thoughts below but really I'm pretty much OK for it to go in (modulo any fallout from comments on patches 1+2). Definite Bonus Points for the doxygen/kernel doc commentary in the headers, which tool parses them? (a few comments in the code itself seem to have the "/**" marker but not the rest of the syntax). You changed the library name to libxenvchan but not the path to the source nor the API names? > +static int init_gnt_srv(struct libvchan *ctrl) > +{ > + int pages_left = ctrl->read.order >= PAGE_SHIFT ? 1 << (ctrl->read.order - PAGE_SHIFT) : 0; Here you do >= PAGE_SHIFT but on the out_unmap_left path you do > 11. (am I right that left == server and right == client in the libvhan terminology?) > + if (ctrl->read.order == 10) { > + ctrl->read.buffer = ((void*)ctrl->ring) + 1024; > + } else if (ctrl->read.order == 11) { > + ctrl->read.buffer = ((void*)ctrl->ring) + 2048; > + } else { > + ctrl->read.buffer = xc_gntshr_share_pages(ctrl->gntshr, ctrl->other_domain_id, > + pages_left, ctrl->ring->grants, 1); > + if (!ctrl->read.buffer) > + goto out_ring; > + } switch (...read.order)? In other places you have MAX_LARGE_RING/MAX_SMALL_RING etc, I think using SMALL/LARGE_RING_ORDER instead of 10 and 11 seems like a good idea. Similarly using LARGE/SMALL_RING_OFFSET instead of 1024/2048 would help clarity. > + if (ctrl->write.order < 10 || ctrl->write.order > 24) > + goto out_unmap_ring; What is the significance of 2^24? > + > +// find xenstore entry > + snprintf(buf, sizeof buf, "/local/domain/%d/data/vchan/%s/%d/ring-ref", > + ctrl->other_domain_id, domid_str, ctrl->device_number); I wonder if the base of this path (up to and including "%s/%d"?) ought to be caller provided? My thinking is that the rendezvous between client and server is out of band and the path is really an element (or even the total encoding) of that OOB communication. It would also push the selection of xs location to be pushed up into the application which also defines the protocol. For example I might want to build a pv protocol with this library which is supported by the toolstack and therefore want to put my stuff under devices etc or in any other protocol specific xs location. The wart I previously mentioned wrt using the "data" directory would then be an application wart (which I think is ok) rather than baked into the libraries. Ian. _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel From xen-devel-bounces@lists.xensource.com Wed Sep 21 04:04:21 2011 Return-path: <xen-devel-bounces@lists.xensource.com> Envelope-to: www-data@lists.xensource.com Delivery-date: Wed, 21 Sep 2011 04:04:21 -0700 Received: from localhost ([127.0.0.1] helo=lists.colo.xensource.com) by lists.xensource.com with esmtp (Exim 4.43) id 1R6KbF-0005fG-2Z; Wed, 21 Sep 2011 04:04:21 -0700 Received: from mail27.messagelabs.com ([193.109.254.147]) by lists.xensource.com with esmtp (Exim 4.43) id 1R6KXc-0005ME-VC for xen-devel@lists.xensource.com; Wed, 21 Sep 2011 04:01:01 -0700 X-Env-Sender: Ian.Campbell@eu.citrix.com X-Msg-Ref: server-5.tower-27.messagelabs.com!1316602814!45767966!1 X-Originating-IP: [62.200.22.115] X-StarScan-Version: 6.4.1; banners=-,-,- X-VirusChecked: Checked Received: (qmail 19643 invoked from network); 21 Sep 2011 11:00:14 -0000 Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115) by server-5.tower-27.messagelabs.com with RC4-SHA encrypted SMTP; 21 Sep 2011 11:00:14 -0000 X-IronPort-AV: E=Sophos;i="4.68,416,1312156800"; d="scan'208";a="7975147" Received: from lonpmailmx01.citrite.net ([10.30.203.162]) by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5; 21 Sep 2011 11:00:22 +0000 Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net (10.30.203.162) with Microsoft SMTP Server id 8.3.137.0; Wed, 21 Sep 2011 12:00:22 +0100 From: Ian Campbell <Ian.Campbell@eu.citrix.com> To: "stefano.stabellini@eu.citrix.com" <stefano.stabellini@eu.citrix.com> Date: Wed, 21 Sep 2011 12:00:21 +0100 In-Reply-To: <1316598917-21515-4-git-send-email-stefano.stabellini@eu.citrix.com> References: <alpine.DEB.2.00.1109211051270.8700@kaball-desktop> <1316598917-21515-4-git-send-email-stefano.stabellini@eu.citrix.com> Organization: Citrix Systems, Inc. Content-Type: text/plain; charset="UTF-8" X-Mailer: Evolution 3.0.3- Content-Transfer-Encoding: 7bit Message-ID: <1316602822.3891.173.camel@zakaz.uk.xensource.com> MIME-Version: 1.0 Cc: Ian Jackson <Ian.Jackson@eu.citrix.com>, "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>, "keir@xen.org" <keir@xen.org> Subject: [Xen-devel] Re: [PATCH v5 4/4] Clone and build Seabios by default X-BeenThere: xen-devel@lists.xensource.com X-Mailman-Version: 2.1.5 Precedence: list List-Id: Xen developer discussion <xen-devel.lists.xensource.com> List-Unsubscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe> List-Post: <mailto:xen-devel@lists.xensource.com> List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help> List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=subscribe> Sender: xen-devel-bounces@lists.xensource.com Errors-To: xen-devel-bounces@lists.xensource.com On Wed, 2011-09-21 at 10:55 +0100, stefano.stabellini@eu.citrix.com wrote: > Signed-off-by: Stefano Stabellini <stefano.stabellini@eu.citrix.com> > > diff -r 9832a4edea7f .hgignore > --- a/.hgignore Thu Sep 15 14:25:11 2011 +0000 > +++ b/.hgignore Thu Sep 15 14:37:33 2011 +0000 > @@ -295,6 +295,8 @@ > ^tools/qemu-xen-traditional-dir$ > ^tools/qemu-xen-dir-remote > ^tools/qemu-xen-dir$ > +^tools/tools/firmware/seabios-dir-remote > +^tools/tools/firmware/seabios-dir$ > ^tools/ocaml/.*/.*\.annot$ > ^tools/ocaml/.*/.*\.cmx?a$ > ^tools/ocaml/.*/META$ > diff -r 9832a4edea7f Config.mk > --- a/Config.mk Thu Sep 15 14:25:11 2011 +0000 > +++ b/Config.mk Thu Sep 15 14:37:33 2011 +0000 > @@ -199,6 +199,8 @@ else > QEMU_UPSTREAM_URL ?= git://xenbits.xensource.com/qemu-upstream-unstable.git > endif > QEMU_UPSTREAM_TAG ?= 6dd84c71dff047f9e492d67e7c99928d09202760 > +SEABIOS_UPSTREAM_URL ?= git://git.qemu.org/seabios.git I use git://git.seabios.org/seabios.git but I don't suppose there is much distinction? More importantly does anyone know of an http mirror? (another argument for hosting on xenbits?) Ian. _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel From xen-devel-bounces@lists.xensource.com Wed Sep 21 04:06:27 2011 Return-path: <xen-devel-bounces@lists.xensource.com> Envelope-to: www-data@lists.xensource.com Delivery-date: Wed, 21 Sep 2011 04:06:27 -0700 Received: from localhost ([127.0.0.1] helo=lists.colo.xensource.com) by lists.xensource.com with esmtp (Exim 4.43) id 1R6KdH-00065b-Fs; Wed, 21 Sep 2011 04:06:27 -0700 Received: from mail21.messagelabs.com ([85.158.143.35]) by lists.xensource.com with esmtp (Exim 4.43) id 1R6KYf-0005NC-Mc for xen-devel@lists.xensource.com; Wed, 21 Sep 2011 04:01:51 -0700 X-Env-Sender: JBeulich@suse.com X-Msg-Ref: server-10.tower-21.messagelabs.com!1316602882!54936351!1 X-Originating-IP: [130.57.49.28] X-StarScan-Version: 6.4.1; banners=-,-,- X-VirusChecked: Checked Received: (qmail 15485 invoked from network); 21 Sep 2011 11:01:22 -0000 Received: from nat28.tlf.novell.com (HELO nat28.tlf.novell.com) (130.57.49.28) by server-10.tower-21.messagelabs.com with DHE-RSA-AES256-SHA encrypted SMTP; 21 Sep 2011 11:01:22 -0000 Received: from EMEA1-MTA by nat28.tlf.novell.com with Novell_GroupWise; Wed, 21 Sep 2011 12:01:31 +0100 Message-Id: <4E79E046020000780005705F@nat28.tlf.novell.com> X-Mailer: Novell GroupWise Internet Agent 8.0.1 Date: Wed, 21 Sep 2011 12:01:58 +0100 From: "Jan Beulich" <JBeulich@suse.com> To: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com> Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="=__PartAD829736.0__=" Subject: [Xen-devel] [PATCH] x86: IO-APIC code has no dependency on PCI X-BeenThere: xen-devel@lists.xensource.com X-Mailman-Version: 2.1.5 Precedence: list List-Id: Xen developer discussion <xen-devel.lists.xensource.com> List-Unsubscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe> List-Post: <mailto:xen-devel@lists.xensource.com> List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help> List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=subscribe> Sender: xen-devel-bounces@lists.xensource.com Errors-To: xen-devel-bounces@lists.xensource.com This is a MIME message. If you are reading this text, you may want to consider changing to a mail reader or gateway that understands how to properly handle MIME multipart messages. --=__PartAD829736.0__= Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: quoted-printable Content-Disposition: inline The IRQ handling code requires pcidevs_lock to be held only for MSI interrupts. As the handling of which was now fully moved into msi.c (i.e. while applying fine without, the patch needs to be applied after the one titled "x86: split MSI IRQ chip"), io_apic.c now also doesn't need to include PCI headers anymore. Signed-off-by: Jan Beulich <jbeulich@suse.com> --- a/xen/arch/x86/io_apic.c +++ b/xen/arch/x86/io_apic.c @@ -27,8 +27,6 @@ #include <xen/delay.h> #include <xen/sched.h> #include <xen/acpi.h> -#include <xen/pci.h> -#include <xen/pci_regs.h> #include <xen/keyhandler.h> #include <asm/mc146818rtc.h> #include <asm/smp.h> @@ -2493,12 +2491,10 @@ int ioapic_guest_write(unsigned long phy =20 add_pin_to_irq(irq, apic, pin); } - spin_lock(&pcidevs_lock); spin_lock(&dom0->event_lock); ret =3D map_domain_pirq(dom0, pirq, irq, MAP_PIRQ_TYPE_GSI, NULL); spin_unlock(&dom0->event_lock); - spin_unlock(&pcidevs_lock); if ( ret < 0 ) return ret; =20 --- a/xen/arch/x86/irq.c +++ b/xen/arch/x86/irq.c @@ -1661,10 +1661,7 @@ int map_domain_pirq( struct pirq *info; struct irq_desc *desc; unsigned long flags; - struct msi_desc *msi_desc; - struct pci_dev *pdev =3D NULL; =20 - ASSERT(spin_is_locked(&pcidevs_lock)); ASSERT(spin_is_locked(&d->event_lock)); =20 if ( !IS_PRIV(current->domain) && @@ -1707,6 +1704,10 @@ int map_domain_pirq( if ( type =3D=3D MAP_PIRQ_TYPE_MSI ) { struct msi_info *msi =3D (struct msi_info *)data; + struct msi_desc *msi_desc; + struct pci_dev *pdev; + + ASSERT(spin_is_locked(&pcidevs_lock)); =20 ret =3D -ENODEV; if ( !cpu_has_apic ) --=__PartAD829736.0__= Content-Type: text/plain; name="x86-ioapic-no-pci.patch" Content-Transfer-Encoding: quoted-printable Content-Disposition: attachment; filename="x86-ioapic-no-pci.patch" The IRQ handling code requires pcidevs_lock to be held only for MSI=0Ainter= rupts.=0A=0AAs the handling of which was now fully moved into msi.c (i.e. = while=0Aapplying fine without, the patch needs to be applied after the = one=0Atitled "x86: split MSI IRQ chip"), io_apic.c now also doesn't need = to=0Ainclude PCI headers anymore.=0A=0ASigned-off-by: Jan Beulich = <jbeulich@suse.com>=0A=0A--- a/xen/arch/x86/io_apic.c=0A+++ b/xen/arch/x86/= io_apic.c=0A@@ -27,8 +27,6 @@=0A #include <xen/delay.h>=0A #include = <xen/sched.h>=0A #include <xen/acpi.h>=0A-#include <xen/pci.h>=0A-#include = <xen/pci_regs.h>=0A #include <xen/keyhandler.h>=0A #include <asm/mc146818rt= c.h>=0A #include <asm/smp.h>=0A@@ -2493,12 +2491,10 @@ int ioapic_guest_wri= te(unsigned long phy=0A =0A add_pin_to_irq(irq, apic, pin);=0A = }=0A- spin_lock(&pcidevs_lock);=0A spin_lock(&dom0->event_lock);=0A = ret =3D map_domain_pirq(dom0, pirq, irq,=0A MAP_PIRQ_TYPE_G= SI, NULL);=0A spin_unlock(&dom0->event_lock);=0A- spin_unlock(&pcide= vs_lock);=0A if ( ret < 0 )=0A return ret;=0A =0A--- a/xen/arch= /x86/irq.c=0A+++ b/xen/arch/x86/irq.c=0A@@ -1661,10 +1661,7 @@ int = map_domain_pirq(=0A struct pirq *info;=0A struct irq_desc = *desc;=0A unsigned long flags;=0A- struct msi_desc *msi_desc;=0A- = struct pci_dev *pdev =3D NULL;=0A =0A- ASSERT(spin_is_locked(&pcidevs_l= ock));=0A ASSERT(spin_is_locked(&d->event_lock));=0A =0A if ( = !IS_PRIV(current->domain) &&=0A@@ -1707,6 +1704,10 @@ int map_domain_pirq(= =0A if ( type =3D=3D MAP_PIRQ_TYPE_MSI )=0A {=0A struct = msi_info *msi =3D (struct msi_info *)data;=0A+ struct msi_desc = *msi_desc;=0A+ struct pci_dev *pdev;=0A+=0A+ ASSERT(spin_is_l= ocked(&pcidevs_lock));=0A =0A ret =3D -ENODEV;=0A if ( = !cpu_has_apic )=0A --=__PartAD829736.0__= Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel --=__PartAD829736.0__=-- From xen-api-bounces@lists.xensource.com Wed Sep 21 04:07:12 2011 Return-path: <xen-api-bounces@lists.xensource.com> Envelope-to: www-data@lists.xensource.com Delivery-date: Wed, 21 Sep 2011 04:07:12 -0700 Received: from localhost ([127.0.0.1] helo=lists.colo.xensource.com) by lists.xensource.com with esmtp (Exim 4.43) id 1R6Kdz-0006JY-4J; Wed, 21 Sep 2011 04:07:11 -0700 Received: from mail216.messagelabs.com ([85.158.143.99]) by lists.xensource.com with esmtp (Exim 4.43) id 1R6Kb3-0005ca-4r; Wed, 21 Sep 2011 04:04:12 -0700 X-Env-Sender: Jonathan.Ludlam@eu.citrix.com X-Msg-Ref: server-8.tower-216.messagelabs.com!1316602936!17486154!1 X-Originating-IP: [62.200.22.115] X-StarScan-Version: 6.4.1; banners=-,-,- X-VirusChecked: Checked Received: (qmail 23390 invoked from network); 21 Sep 2011 11:02:16 -0000 Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115) by server-8.tower-216.messagelabs.com with RC4-SHA encrypted SMTP; 21 Sep 2011 11:02:16 -0000 X-IronPort-AV: E=Sophos;i="4.68,416,1312156800"; d="scan'208";a="7975189" Received: from lonpmailmx01.citrite.net ([10.30.203.162]) by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5; 21 Sep 2011 11:02:16 +0000 Received: from LONPMAILBOX01.citrite.net ([10.30.224.160]) by LONPMAILMX01.citrite.net ([10.30.203.162]) with mapi; Wed, 21 Sep 2011 12:02:16 +0100 From: Jonathan Ludlam <Jonathan.Ludlam@eu.citrix.com> To: "xen-api@lists.xensource.com" <xen-api@lists.xensource.com>, "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>, "xen-users@lists.xensource.com List" <xen-users@lists.xensource.com> Date: Wed, 21 Sep 2011 12:02:15 +0100 Thread-Topic: XCP 1.1 RC Thread-Index: Acx4Tew2TJRmXJvESgOq6h6CLaSSDg== Message-ID: <2A06687B-208D-4F90-B98F-5A7EB07A762B@eu.citrix.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: Subject: [Xen-API] XCP 1.1 RC X-BeenThere: xen-api@lists.xensource.com X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussion of API issues surrounding Xen <xen-api.lists.xensource.com> List-Unsubscribe: <http://lists.xensource.com/mailman/listinfo/xen-api>, <mailto:xen-api-request@lists.xensource.com?subject=unsubscribe> List-Post: <mailto:xen-api@lists.xensource.com> List-Help: <mailto:xen-api-request@lists.xensource.com?subject=help> List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-api>, <mailto:xen-api-request@lists.xensource.com?subject=subscribe> Sender: xen-api-bounces@lists.xensource.com Errors-To: xen-api-bounces@lists.xensource.com Hi all, XCP 1.1 Release Candidate is ready to be tested. Changes since Beta: * License expiry crept back in. It has now crept out again. * For OpenStack and others, support for ebtables and other netfilter option= s have been added to the kernel * License restrictions (e.g. memory checks) have been removed * Xapi version override feature has been added back in Please give this a good test, and if it's all OK I propose to call this XCP= 1.1 final. The ISOs are available here: http://downloads.xen.org/XCP/50674/index.html Cheers, Jon _______________________________________________ xen-api mailing list xen-api@lists.xensource.com http://lists.xensource.com/mailman/listinfo/xen-api From xen-devel-bounces@lists.xensource.com Wed Sep 21 04:15:34 2011 Return-path: <xen-devel-bounces@lists.xensource.com> Envelope-to: www-data@lists.xensource.com Delivery-date: Wed, 21 Sep 2011 04:15:35 -0700 Received: from localhost ([127.0.0.1] helo=lists.colo.xensource.com) by lists.xensource.com with esmtp (Exim 4.43) id 1R6Km4-0007nf-MR; Wed, 21 Sep 2011 04:15:33 -0700 Received: from mail21.messagelabs.com ([85.158.143.35]) by lists.xensource.com with esmtp (Exim 4.43) id 1R6KdZ-0006Bv-AG for xen-devel@lists.xensource.com; Wed, 21 Sep 2011 04:06:45 -0700 X-Env-Sender: JBeulich@suse.com X-Msg-Ref: server-2.tower-21.messagelabs.com!1316603200!34929941!1 X-Originating-IP: [130.57.49.28] X-StarScan-Version: 6.4.1; banners=-,-,- X-VirusChecked: Checked Received: (qmail 15314 invoked from network); 21 Sep 2011 11:06:40 -0000 Received: from nat28.tlf.novell.com (HELO nat28.tlf.novell.com) (130.57.49.28) by server-2.tower-21.messagelabs.com with DHE-RSA-AES256-SHA encrypted SMTP; 21 Sep 2011 11:06:40 -0000 Received: from EMEA1-MTA by nat28.tlf.novell.com with Novell_GroupWise; Wed, 21 Sep 2011 12:06:36 +0100 Message-Id: <4E79E1770200007800057064@nat28.tlf.novell.com> X-Mailer: Novell GroupWise Internet Agent 8.0.1 Date: Wed, 21 Sep 2011 12:07:03 +0100 From: "Jan Beulich" <JBeulich@suse.com> To: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com> Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="=__PartDDF2E747.1__=" Cc: Allen M Kay <allen.m.kay@intel.com> Subject: [Xen-devel] [PATCH] VT-d: eliminate a mis-use of pcidevs_lock X-BeenThere: xen-devel@lists.xensource.com X-Mailman-Version: 2.1.5 Precedence: list List-Id: Xen developer discussion <xen-devel.lists.xensource.com> List-Unsubscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe> List-Post: <mailto:xen-devel@lists.xensource.com> List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help> List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=subscribe> Sender: xen-devel-bounces@lists.xensource.com Errors-To: xen-devel-bounces@lists.xensource.com This is a MIME message. If you are reading this text, you may want to consider changing to a mail reader or gateway that understands how to properly handle MIME multipart messages. --=__PartDDF2E747.1__= Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: quoted-printable Content-Disposition: inline dma_pte_clear_one() shouldn't acquire this global lock for the purpose of processing a per-domain list. Furthermore the function a few lines earlier has a comment stating that acquiring pcidevs_lock isn't necessary here (whether that's really correct is another question). Use the domain's mappin_lock instead to protect the mapped_rmrrs list. Fold domain_rmrr_mapped() into its sole caller so that the otherwise implicit dependency on pcidevs_lock there becomes more obvious (see the comment there). Signed-off-by: Jan Beulich <jbeulich@suse.com> --- a/xen/drivers/passthrough/vtd/iommu.c +++ b/xen/drivers/passthrough/vtd/iommu.c @@ -589,7 +589,6 @@ static void dma_pte_clear_one(struct dom u64 pg_maddr; int flush_dev_iotlb; int iommu_domid; - struct list_head *rmrr_list, *tmp; struct mapped_rmrr *mrmrr; =20 spin_lock(&hd->mapping_lock); @@ -636,10 +635,9 @@ static void dma_pte_clear_one(struct dom /* if the cleared address is between mapped RMRR region, * remove the mapped RMRR */ - spin_lock(&pcidevs_lock); - list_for_each_safe ( rmrr_list, tmp, &hd->mapped_rmrrs ) + spin_lock(&hd->mapping_lock); + list_for_each_entry ( mrmrr, &hd->mapped_rmrrs, list ) { - mrmrr =3D list_entry(rmrr_list, struct mapped_rmrr, list); if ( addr >=3D mrmrr->base && addr <=3D mrmrr->end ) { list_del(&mrmrr->list); @@ -647,7 +645,7 @@ static void dma_pte_clear_one(struct dom break; } } - spin_unlock(&pcidevs_lock); + spin_unlock(&hd->mapping_lock); } =20 static void iommu_free_pagetable(u64 pt_maddr, int level) @@ -1824,22 +1822,6 @@ void iommu_set_pgd(struct domain *d) hd->pgd_maddr =3D pagetable_get_paddr(pagetable_from_mfn(pgd_mfn)); } =20 -static int domain_rmrr_mapped(struct domain *d, - struct acpi_rmrr_unit *rmrr) -{ - struct hvm_iommu *hd =3D domain_hvm_iommu(d); - struct mapped_rmrr *mrmrr; - - list_for_each_entry( mrmrr, &hd->mapped_rmrrs, list ) - { - if ( mrmrr->base =3D=3D rmrr->base_address && - mrmrr->end =3D=3D rmrr->end_address ) - return 1; - } - - return 0; -} - static int rmrr_identity_mapping(struct domain *d, struct acpi_rmrr_unit *rmrr) { @@ -1851,8 +1833,16 @@ static int rmrr_identity_mapping(struct=20 ASSERT(spin_is_locked(&pcidevs_lock)); ASSERT(rmrr->base_address < rmrr->end_address); =20 - if ( domain_rmrr_mapped(d, rmrr) ) - return 0; + /* + * No need to acquire hd->mapping_lock, as the only theoretical race = is + * with the insertion below (impossible due to holding pcidevs_lock). + */ + list_for_each_entry( mrmrr, &hd->mapped_rmrrs, list ) + { + if ( mrmrr->base =3D=3D rmrr->base_address && + mrmrr->end =3D=3D rmrr->end_address ) + return 0; + } =20 base =3D rmrr->base_address & PAGE_MASK_4K; base_pfn =3D base >> PAGE_SHIFT_4K; @@ -1872,7 +1862,9 @@ static int rmrr_identity_mapping(struct=20 return -ENOMEM; mrmrr->base =3D rmrr->base_address; mrmrr->end =3D rmrr->end_address; + spin_lock(&hd->mapping_lock); list_add_tail(&mrmrr->list, &hd->mapped_rmrrs); + spin_unlock(&hd->mapping_lock); =20 return 0; } --=__PartDDF2E747.1__= Content-Type: text/plain; name="vtd-mapped_rmrrs.patch" Content-Transfer-Encoding: quoted-printable Content-Disposition: attachment; filename="vtd-mapped_rmrrs.patch" dma_pte_clear_one() shouldn't acquire this global lock for the purpose=0Aof= processing a per-domain list. Furthermore the function a few lines=0Aearli= er has a comment stating that acquiring pcidevs_lock isn't=0Anecessary = here (whether that's really correct is another question).=0A=0AUse the = domain's mappin_lock instead to protect the mapped_rmrrs list.=0AFold = domain_rmrr_mapped() into its sole caller so that the otherwise=0Aimplicit = dependency on pcidevs_lock there becomes more obvious (see=0Athe comment = there).=0A=0ASigned-off-by: Jan Beulich <jbeulich@suse.com>=0A=0A--- = a/xen/drivers/passthrough/vtd/iommu.c=0A+++ b/xen/drivers/passthrough/vtd/i= ommu.c=0A@@ -589,7 +589,6 @@ static void dma_pte_clear_one(struct dom=0A = u64 pg_maddr;=0A int flush_dev_iotlb;=0A int iommu_domid;=0A- = struct list_head *rmrr_list, *tmp;=0A struct mapped_rmrr *mrmrr;=0A = =0A spin_lock(&hd->mapping_lock);=0A@@ -636,10 +635,9 @@ static void = dma_pte_clear_one(struct dom=0A /* if the cleared address is between = mapped RMRR region,=0A * remove the mapped RMRR=0A */=0A- = spin_lock(&pcidevs_lock);=0A- list_for_each_safe ( rmrr_list, tmp, = &hd->mapped_rmrrs )=0A+ spin_lock(&hd->mapping_lock);=0A+ list_for_ea= ch_entry ( mrmrr, &hd->mapped_rmrrs, list )=0A {=0A- mrmrr =3D = list_entry(rmrr_list, struct mapped_rmrr, list);=0A if ( addr >=3D = mrmrr->base && addr <=3D mrmrr->end )=0A {=0A = list_del(&mrmrr->list);=0A@@ -647,7 +645,7 @@ static void dma_pte_clear_one= (struct dom=0A break;=0A }=0A }=0A- spin_unlock(= &pcidevs_lock);=0A+ spin_unlock(&hd->mapping_lock);=0A }=0A =0A static = void iommu_free_pagetable(u64 pt_maddr, int level)=0A@@ -1824,22 +1822,6 = @@ void iommu_set_pgd(struct domain *d)=0A hd->pgd_maddr =3D pagetable_= get_paddr(pagetable_from_mfn(pgd_mfn));=0A }=0A =0A-static int domain_rmrr_= mapped(struct domain *d,=0A- struct acpi_rmrr_= unit *rmrr)=0A-{=0A- struct hvm_iommu *hd =3D domain_hvm_iommu(d);=0A- = struct mapped_rmrr *mrmrr;=0A-=0A- list_for_each_entry( mrmrr, = &hd->mapped_rmrrs, list )=0A- {=0A- if ( mrmrr->base =3D=3D = rmrr->base_address &&=0A- mrmrr->end =3D=3D rmrr->end_address = )=0A- return 1;=0A- }=0A-=0A- return 0;=0A-}=0A-=0A = static int rmrr_identity_mapping(struct domain *d,=0A = struct acpi_rmrr_unit *rmrr)=0A {=0A@@ -1851,8 +1833,16 @@ = static int rmrr_identity_mapping(struct =0A ASSERT(spin_is_locked(&pcid= evs_lock));=0A ASSERT(rmrr->base_address < rmrr->end_address);=0A =0A- = if ( domain_rmrr_mapped(d, rmrr) )=0A- return 0;=0A+ /*=0A+ = * No need to acquire hd->mapping_lock, as the only theoretical race = is=0A+ * with the insertion below (impossible due to holding pcidevs_lo= ck).=0A+ */=0A+ list_for_each_entry( mrmrr, &hd->mapped_rmrrs, list = )=0A+ {=0A+ if ( mrmrr->base =3D=3D rmrr->base_address &&=0A+ = mrmrr->end =3D=3D rmrr->end_address )=0A+ return = 0;=0A+ }=0A =0A base =3D rmrr->base_address & PAGE_MASK_4K;=0A = base_pfn =3D base >> PAGE_SHIFT_4K;=0A@@ -1872,7 +1862,9 @@ static int = rmrr_identity_mapping(struct =0A return -ENOMEM;=0A mrmrr->base= =3D rmrr->base_address;=0A mrmrr->end =3D rmrr->end_address;=0A+ = spin_lock(&hd->mapping_lock);=0A list_add_tail(&mrmrr->list, &hd->mappe= d_rmrrs);=0A+ spin_unlock(&hd->mapping_lock);=0A =0A return 0;=0A = }=0A --=__PartDDF2E747.1__= Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel --=__PartDDF2E747.1__=-- From xen-devel-bounces@lists.xensource.com Wed Sep 21 04:17:15 2011 Return-path: <xen-devel-bounces@lists.xensource.com> Envelope-to: www-data@lists.xensource.com Delivery-date: Wed, 21 Sep 2011 04:17:15 -0700 Received: from localhost ([127.0.0.1] helo=lists.colo.xensource.com) by lists.xensource.com with esmtp (Exim 4.43) id 1R6Knj-0008Gb-L4; Wed, 21 Sep 2011 04:17:15 -0700 Received: from mail21.messagelabs.com ([85.158.143.35]) by lists.xensource.com with esmtp (Exim 4.43) id 1R6Kgr-0007DO-EC for xen-devel@lists.xensource.com; Wed, 21 Sep 2011 04:10:13 -0700 X-Env-Sender: JBeulich@suse.com X-Msg-Ref: server-2.tower-21.messagelabs.com!1316603404!34930566!1 X-Originating-IP: [130.57.49.28] X-StarScan-Version: 6.4.1; banners=-,-,- X-VirusChecked: Checked Received: (qmail 26248 invoked from network); 21 Sep 2011 11:10:05 -0000 Received: from nat28.tlf.novell.com (HELO nat28.tlf.novell.com) (130.57.49.28) by server-2.tower-21.messagelabs.com with DHE-RSA-AES256-SHA encrypted SMTP; 21 Sep 2011 11:10:05 -0000 Received: from EMEA1-MTA by nat28.tlf.novell.com with Novell_GroupWise; Wed, 21 Sep 2011 12:10:00 +0100 Message-Id: <4E79E2430200007800057079@nat28.tlf.novell.com> X-Mailer: Novell GroupWise Internet Agent 8.0.1 Date: Wed, 21 Sep 2011 12:10:27 +0100 From: "Jan Beulich" <JBeulich@suse.com> To: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com> Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="=__PartAA859033.1__=" Cc: Allen M Kay <allen.m.kay@intel.com> Subject: [Xen-devel] [PATCH] VT-d: fix off-by-one error in RMRR validation X-BeenThere: xen-devel@lists.xensource.com X-Mailman-Version: 2.1.5 Precedence: list List-Id: Xen developer discussion <xen-devel.lists.xensource.com> List-Unsubscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe> List-Post: <mailto:xen-devel@lists.xensource.com> List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help> List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=subscribe> Sender: xen-devel-bounces@lists.xensource.com Errors-To: xen-devel-bounces@lists.xensource.com This is a MIME message. If you are reading this text, you may want to consider changing to a mail reader or gateway that understands how to properly handle MIME multipart messages. --=__PartAA859033.1__= Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: quoted-printable Content-Disposition: inline (base_addr,end_addr) is an inclusive range, and hence there shouldn't be a subtraction of 1 in the second invocation of page_is_ram_type(). For RMRRs covering a single page that actually resulted in the immediately preceding page to get checked (which could have resulted in a false warning). Signed-off-by: Jan Beulich <jbeulich@suse.com> --- a/xen/drivers/passthrough/vtd/dmar.c +++ b/xen/drivers/passthrough/vtd/dmar.c @@ -520,7 +520,7 @@ acpi_parse_one_rmrr(struct acpi_dmar_ent * inform the user */ if ( (!page_is_ram_type(paddr_to_pfn(base_addr), RAM_TYPE_RESERVED)) = || - (!page_is_ram_type(paddr_to_pfn(end_addr) - 1, RAM_TYPE_RESERVED)= ) ) + (!page_is_ram_type(paddr_to_pfn(end_addr), RAM_TYPE_RESERVED)) ) { dprintk(XENLOG_WARNING VTDPREFIX, " RMRR address range not in reserved memory " --=__PartAA859033.1__= Content-Type: text/plain; name="vtd-rmrr-reserved-check.patch" Content-Transfer-Encoding: quoted-printable Content-Disposition: attachment; filename="vtd-rmrr-reserved-check.patch" (base_addr,end_addr) is an inclusive range, and hence there shouldn't=0Abe = a subtraction of 1 in the second invocation of page_is_ram_type().=0AFor = RMRRs covering a single page that actually resulted in the=0Aimmediately = preceding page to get checked (which could have resulted=0Ain a false = warning).=0A=0ASigned-off-by: Jan Beulich <jbeulich@suse.com>=0A=0A--- = a/xen/drivers/passthrough/vtd/dmar.c=0A+++ b/xen/drivers/passthrough/vtd/dm= ar.c=0A@@ -520,7 +520,7 @@ acpi_parse_one_rmrr(struct acpi_dmar_ent=0A = * inform the user=0A */=0A if ( (!page_is_ram_type(paddr_to_pfn(b= ase_addr), RAM_TYPE_RESERVED)) ||=0A- (!page_is_ram_type(paddr_to_p= fn(end_addr) - 1, RAM_TYPE_RESERVED)) )=0A+ (!page_is_ram_type(padd= r_to_pfn(end_addr), RAM_TYPE_RESERVED)) )=0A {=0A dprintk(XENLO= G_WARNING VTDPREFIX,=0A " RMRR address range not in = reserved memory "=0A --=__PartAA859033.1__= Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel --=__PartAA859033.1__=-- From xen-devel-bounces@lists.xensource.com Wed Sep 21 04:21:59 2011 Return-path: <xen-devel-bounces@lists.xensource.com> Envelope-to: www-data@lists.xensource.com Delivery-date: Wed, 21 Sep 2011 04:21:59 -0700 Received: from localhost ([127.0.0.1] helo=lists.colo.xensource.com) by lists.xensource.com with esmtp (Exim 4.43) id 1R6KsJ-0000GB-Le; Wed, 21 Sep 2011 04:21:59 -0700 Received: from mail216.messagelabs.com ([85.158.143.99]) by lists.xensource.com with esmtp (Exim 4.43) id 1R6KrP-0008VC-FX for xen-devel@lists.xensource.com; Wed, 21 Sep 2011 04:21:04 -0700 X-Env-Sender: Stefano.Stabellini@eu.citrix.com X-Msg-Ref: server-10.tower-216.messagelabs.com!1316604060!10988320!1 X-Originating-IP: [62.200.22.115] X-StarScan-Version: 6.4.1; banners=-,-,- X-VirusChecked: Checked Received: (qmail 26094 invoked from network); 21 Sep 2011 11:21:00 -0000 Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115) by server-10.tower-216.messagelabs.com with RC4-SHA encrypted SMTP; 21 Sep 2011 11:21:00 -0000 X-IronPort-AV: E=Sophos;i="4.68,417,1312156800"; d="scan'208";a="7975809" Received: from lonpmailmx01.citrite.net ([10.30.203.162]) by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5; 21 Sep 2011 11:21:00 +0000 Received: from kaball.uk.xensource.com (10.80.2.59) by LONPMAILMX01.citrite.net (10.30.203.162) with Microsoft SMTP Server id 8.3.137.0; Wed, 21 Sep 2011 12:21:00 +0100 Date: Wed, 21 Sep 2011 12:20:51 +0100 From: Stefano Stabellini <stefano.stabellini@eu.citrix.com> X-X-Sender: sstabellini@kaball-desktop To: =?UTF-8?B?6LW15b2s?= <haibinfeier@gmail.com> Subject: Re: [Xen-devel] something about time synchronization In-Reply-To: <CABFOHEvsk8e48j3tvrwaJ8oReeeeuoJ3Xhyd9nFBJr54zWOvsg@mail.gmail.com> Message-ID: <alpine.DEB.2.00.1109211220060.8700@kaball-desktop> References: <CABFOHEvsk8e48j3tvrwaJ8oReeeeuoJ3Xhyd9nFBJr54zWOvsg@mail.gmail.com> User-Agent: Alpine 2.00 (DEB 1167 2008-08-23) MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com> X-BeenThere: xen-devel@lists.xensource.com X-Mailman-Version: 2.1.5 Precedence: list List-Id: Xen developer discussion <xen-devel.lists.xensource.com> List-Unsubscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe> List-Post: <mailto:xen-devel@lists.xensource.com> List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help> List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=subscribe> Sender: xen-devel-bounces@lists.xensource.com Errors-To: xen-devel-bounces@lists.xensource.com On Sat, 17 Sep 2011, ?? wrote: > In PV Xen,dom0 can make time synchronization with dom U,but how about in HVM dom ?Can dom0 make time synronization with > HVM dom? with modern pvops kernels, dom0 cannot force time synchronization even with normal domU guests _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel From xen-devel-bounces@lists.xensource.com Wed Sep 21 05:04:04 2011 Return-path: <xen-devel-bounces@lists.xensource.com> Envelope-to: www-data@lists.xensource.com Delivery-date: Wed, 21 Sep 2011 05:04:04 -0700 Received: from localhost ([127.0.0.1] helo=lists.colo.xensource.com) by lists.xensource.com with esmtp (Exim 4.43) id 1R6LX1-0002AS-L5; Wed, 21 Sep 2011 05:04:03 -0700 Received: from mail27.messagelabs.com ([193.109.254.147]) by lists.xensource.com with esmtp (Exim 4.43) id 1R6LRu-0001u5-Hn for xen-devel@lists.xensource.com; Wed, 21 Sep 2011 04:59:07 -0700 X-Env-Sender: olaf@aepfle.de X-Msg-Ref: server-13.tower-27.messagelabs.com!1316606295!40943244!1 X-Originating-IP: [81.169.146.161] X-StarScan-Version: 6.4.1; banners=-,-,- X-VirusChecked: Checked Received: (qmail 27959 invoked from network); 21 Sep 2011 11:58:15 -0000 Received: from mo-p00-ob.rzone.de (HELO mo-p00-ob.rzone.de) (81.169.146.161) by server-13.tower-27.messagelabs.com with DHE-RSA-AES256-SHA encrypted SMTP; 21 Sep 2011 11:58:15 -0000 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; t=1316606306; l=4281; s=domk; d=aepfle.de; h=In-Reply-To:Content-Type:MIME-Version:References:Subject:Cc:To:From: Date:X-RZG-CLASS-ID:X-RZG-AUTH; bh=GI1wRGri5aRrJE26WX8FFaENCG0=; b=MIv7lKWCtz3paY70z4nG2Nd7W93nWhyuS/9n/F7kVF5QT4AD3MIarlbd0TSrhEZ3hAZ 72i1HzNkUfhctV//VIaJescwaFn5VzW0P39FGeFyMdF3GzHSI2/CHzVXO27BBCdT7DBlQ vdO9EASpWgZHXTmi/LNmNFh7TMqoOUH9yEM= X-RZG-AUTH: :P2EQZWCpfu+qG7CngxMFH1J+zrwiavkK6tmQaLfmwtM48/ll387iF8M= X-RZG-CLASS-ID: mo00 Received: from probook.site (dslb-084-057-086-095.pools.arcor-ip.net [84.57.86.95]) by smtp.strato.de (cohen mo35) (RZmta 26.7) with (DHE-RSA-AES256-SHA encrypted) ESMTPA id a058c2n8LAWQWA ; Wed, 21 Sep 2011 13:58:19 +0200 (MEST) Received: by probook.site (Postfix, from userid 1000) id 6160B18B65; Wed, 21 Sep 2011 13:58:18 +0200 (CEST) Date: Wed, 21 Sep 2011 13:58:18 +0200 From: Olaf Hering <olaf@aepfle.de> To: Ian Campbell <Ian.Campbell@citrix.com> Subject: Re: [Xen-devel] [PATCH] xenpaging: libxl support Message-ID: <20110921115818.GA479@aepfle.de> References: <c9a9779fd9581666c327.1316100011@probook.site> <1316597077.3891.124.camel@zakaz.uk.xensource.com> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline In-Reply-To: <1316597077.3891.124.camel@zakaz.uk.xensource.com> User-Agent: Mutt/1.5.21.rev5535 (2011-07-01) Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com> X-BeenThere: xen-devel@lists.xensource.com X-Mailman-Version: 2.1.5 Precedence: list List-Id: Xen developer discussion <xen-devel.lists.xensource.com> List-Unsubscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe> List-Post: <mailto:xen-devel@lists.xensource.com> List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help> List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=subscribe> Sender: xen-devel-bounces@lists.xensource.com Errors-To: xen-devel-bounces@lists.xensource.com On Wed, Sep 21, Ian Campbell wrote: > > + ("xenpaging", integer, False, "number of pages"), > > + ("xenpaging_workdir", string, False, "directory to store guest page file"), > > Really a directory or actually a file? xenpaging_path would probably be > a nicer name. Yes, that could be changed. Right now xenpaging opens the file in the current directory. But since all config values could be passed via xenstore, it may contain the full path to the paging file as well. > > + ("xenpaging_debug", bool, False, "enable debug output in pager"), > > Perhaps a generic "extra_arguments" type field (string) would be more > useful? Yes, that would work too. > > + ("xenpaging_policy_mru_size", integer, False, "number of paged-in pages to keep in memory"), > > How is the distinct from / related to the xenpaging integer? It defines how many pages are seen as "hot" by xenpaging, they wont be paged-out again until that many other pages were paged-in. See tools/xenpaging/policy_default.c:policy_notify_paged_in(). For example, a value of less than 1024 for a fully paged-out guest will make it nearly unusuable. But a guest with a smaller xenpaging value can also have a smaller mru size. > > +static void xp_xenstore_record_pid(void *for_spawn, pid_t innerchild) > > +{ > > + libxl__device_model_starting *starting = for_spawn; > > Do you mean libxl__xenpaging_starting here? Yes, thats a typo. I did just copy&paste. > It looks like xp_xenstore_record_pid could be shared with the dm one > with only a little refactoring/abstraction. Yes, but could share the same struct libxl__*_starting. > > +static int libxl__create_xenpaging(libxl__gc *gc, char *dom_name, uint32_t domid, libxl_xenpaging_info *xp_info) > > +{ > > [...] > > > + /* Set working directory if not specified in config file */ > > + if (!xp_info->xenpaging_workdir) > > + xp_info->xenpaging_workdir = "/var/lib/xen/xenpaging"; > > Should come from libxl_paths, see e.g. libxl_sbindir_path(). I will update that part. > > + /* Spawn the child */ > > + rc = libxl__spawn_spawn(gc, NULL, "xenpaging", xp_xenstore_record_pid, &buf_starting); > > No libxl__spawn_starting argument. Do you handle failure to exec etc? I will update that part. > > + if (rc < 0) > > + goto out_close; > > + if (!rc) { /* inner child */ > > + setsid(); > > + /* Enable debug output in the child */ > > + if (xp_info->xenpaging_debug) > > + setenv("XENPAGING_DEBUG", "1", 1); > > + /* Adjust most-recently-used value in the child */ > > + if (xp_info->xenpaging_policy_mru_size) > > + setenv("XENPAGING_POLICY_MRU_SIZE", libxl__sprintf(gc, "%d", xp_info->xenpaging_policy_mru_size), 1); > > I think the xenpaging binary should have a proper command line interface > rather than passing them via the environment. I will add a --debug option. > In the case of the policy mru size perhaps that should be in xenstore > such that it can be changed on the fly? Changing it on the fly needs some refactoring of the code, but it should be doable. > > diff -r 7fb21fac6d7d -r c9a9779fd958 tools/libxl/libxl_internal.h > > --- a/tools/libxl/libxl_internal.h > > +++ b/tools/libxl/libxl_internal.h > > @@ -251,6 +251,11 @@ typedef struct { > > libxl__spawn_starting *for_spawn; > > } libxl__device_model_starting; > > > > +typedef struct { > > + char *dom_path; /* from libxl_malloc, only for xp_xenstore_record_pid */ > > + int domid; > > +} libxl__xenpaging_starting; > > + > > /* from xl_create */ > > _hidden int libxl__domain_make(libxl__gc *gc, libxl_domain_create_info *info, uint32_t *domid); > > _hidden int libxl__domain_build(libxl__gc *gc, > > diff -r 7fb21fac6d7d -r c9a9779fd958 tools/libxl/xl_cmdimpl.c > > --- a/tools/libxl/xl_cmdimpl.c > > +++ b/tools/libxl/xl_cmdimpl.c > > @@ -290,6 +290,7 @@ static void dolog(const char *file, int > > > > static void printf_info(int domid, > > libxl_domain_config *d_config, > > + libxl_xenpaging_info *xp_info, > > xp_info is d_config->xpo_info or something isn't it? Yes, depends were it ends up. I will move it elsewhere. > Did I miss a call to libxl_xenpaging_info_destroy() somewhere or does > this leak? I will check. Thanks for the comments. Olaf _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel From xen-devel-bounces@lists.xensource.com Wed Sep 21 05:38:09 2011 Return-path: <xen-devel-bounces@lists.xensource.com> Envelope-to: www-data@lists.xensource.com Delivery-date: Wed, 21 Sep 2011 05:38:09 -0700 Received: from localhost ([127.0.0.1] helo=lists.colo.xensource.com) by lists.xensource.com with esmtp (Exim 4.43) id 1R6M41-0003BS-NE; Wed, 21 Sep 2011 05:38:09 -0700 Received: from mail21.messagelabs.com ([85.158.143.35]) by lists.xensource.com with esmtp (Exim 4.43) id 1R6M3D-0002yv-IK for xen-devel@lists.xensource.com; Wed, 21 Sep 2011 05:37:21 -0700 X-Env-Sender: keir.xen@gmail.com X-Msg-Ref: server-9.tower-21.messagelabs.com!1316608590!49254215!1 X-Originating-IP: [209.85.213.43] X-StarScan-Version: 6.4.1; banners=-,-,- X-VirusChecked: Checked Received: (qmail 13095 invoked from network); 21 Sep 2011 12:36:31 -0000 Received: from mail-yw0-f43.google.com (HELO mail-yw0-f43.google.com) (209.85.213.43) by server-9.tower-21.messagelabs.com with RC4-SHA encrypted SMTP; 21 Sep 2011 12:36:31 -0000 Received: by ywm21 with SMTP id 21so1698972ywm.30 for <xen-devel@lists.xensource.com>; Wed, 21 Sep 2011 05:37:15 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=user-agent:date:subject:from:to:message-id:thread-topic :thread-index:in-reply-to:mime-version:content-type :content-transfer-encoding; bh=mAFsKbzV/UYBxry8MfBd5IMnMv6yzar2lQpluUsG3Gw=; b=WmAmAfC5JskkXr8E6nrtd+S+xo/dRkd/CjZj7kioPgkKi061mfvP2F2mwqdU8SDbPX 2I0ul+4Cxq2MmqrebedHnLIADqvQ4WTC4LfAxRDODyxBug+roKwFXHpfcZx1KaBwboqo PEVgOuJ2RLuCbmnIfppK8kSKWS43ZU4aGw+Yg= Received: by 10.236.191.103 with SMTP id f67mr4910849yhn.16.1316608634864; Wed, 21 Sep 2011 05:37:14 -0700 (PDT) Received: from [10.255.255.36] ([96.49.135.17]) by mx.google.com with ESMTPS id x65sm6413218yhh.26.2011.09.21.05.37.09 (version=SSLv3 cipher=OTHER); Wed, 21 Sep 2011 05:37:13 -0700 (PDT) User-Agent: Microsoft-Entourage/12.30.0.110427 Date: Wed, 21 Sep 2011 05:37:03 -0700 Subject: Re: [Xen-devel] [PATCH 3/7] PCI multi-seg: adjust domctl interface From: Keir Fraser <keir.xen@gmail.com> To: Jan Beulich <JBeulich@suse.com>, "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>, Ian Jackson <Ian.Jackson@eu.citrix.com> Message-ID: <CA9F287F.212AC%keir.xen@gmail.com> Thread-Topic: [Xen-devel] [PATCH 3/7] PCI multi-seg: adjust domctl interface Thread-Index: Acx4WyoQgZ5KO3pYwEWcZtG2CDyqyA== In-Reply-To: <4E78CAD60200007800056D24@nat28.tlf.novell.com> Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit Cc: X-BeenThere: xen-devel@lists.xensource.com X-Mailman-Version: 2.1.5 Precedence: list List-Id: Xen developer discussion <xen-devel.lists.xensource.com> List-Unsubscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe> List-Post: <mailto:xen-devel@lists.xensource.com> List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help> List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=subscribe> Sender: xen-devel-bounces@lists.xensource.com Errors-To: xen-devel-bounces@lists.xensource.com On 20/09/2011 08:18, "Jan Beulich" <JBeulich@suse.com> wrote: > Again, a couple of directly related functions at once get adjusted to > account for the segment number. > > Do we need to bump XEN_DOMCTL_INTERFACE_VERSION for the changes to the > domctl interface (namely the renaming and bit-reassigment of the > machine_bdf member of two of the interface structures)? If so, this > can probably be done as the patch gets checked in (rather than me > having to re-submit)? Ian suggests we should keep compatibility with old qemu versions. Are any of these hypercall commands used by qemu? -- Keir > Signed-off-by: Jan Beulich <jbeulich@suse.com> > > --- 2011-09-20.orig/tools/libxc/xc_domain.c 2011-06-16 09:21:02.000000000 > +0200 > +++ 2011-09-20/tools/libxc/xc_domain.c 2011-09-15 16:51:12.000000000 +0200 > @@ -1132,13 +1132,13 @@ int xc_domain_setdebugging(xc_interface > int xc_assign_device( > xc_interface *xch, > uint32_t domid, > - uint32_t machine_bdf) > + uint32_t machine_sbdf) > { > DECLARE_DOMCTL; > > domctl.cmd = XEN_DOMCTL_assign_device; > domctl.domain = domid; > - domctl.u.assign_device.machine_bdf = machine_bdf; > + domctl.u.assign_device.machine_sbdf = machine_sbdf; > > return do_domctl(xch, &domctl); > } > @@ -1146,7 +1146,7 @@ int xc_assign_device( > int xc_get_device_group( > xc_interface *xch, > uint32_t domid, > - uint32_t machine_bdf, > + uint32_t machine_sbdf, > uint32_t max_sdevs, > uint32_t *num_sdevs, > uint32_t *sdev_array) > @@ -1164,7 +1164,7 @@ int xc_get_device_group( > domctl.cmd = XEN_DOMCTL_get_device_group; > domctl.domain = (domid_t)domid; > > - domctl.u.get_device_group.machine_bdf = machine_bdf; > + domctl.u.get_device_group.machine_sbdf = machine_sbdf; > domctl.u.get_device_group.max_sdevs = max_sdevs; > > set_xen_guest_handle(domctl.u.get_device_group.sdev_array, sdev_array); > @@ -1181,13 +1181,13 @@ int xc_get_device_group( > int xc_test_assign_device( > xc_interface *xch, > uint32_t domid, > - uint32_t machine_bdf) > + uint32_t machine_sbdf) > { > DECLARE_DOMCTL; > > domctl.cmd = XEN_DOMCTL_test_assign_device; > domctl.domain = domid; > - domctl.u.assign_device.machine_bdf = machine_bdf; > + domctl.u.assign_device.machine_sbdf = machine_sbdf; > > return do_domctl(xch, &domctl); > } > @@ -1195,13 +1195,13 @@ int xc_test_assign_device( > int xc_deassign_device( > xc_interface *xch, > uint32_t domid, > - uint32_t machine_bdf) > + uint32_t machine_sbdf) > { > DECLARE_DOMCTL; > > domctl.cmd = XEN_DOMCTL_deassign_device; > domctl.domain = domid; > - domctl.u.assign_device.machine_bdf = machine_bdf; > + domctl.u.assign_device.machine_sbdf = machine_sbdf; > > return do_domctl(xch, &domctl); > } > --- 2011-09-20.orig/tools/libxl/libxl_pci.c 2011-09-05 09:12:30.000000000 > +0200 > +++ 2011-09-20/tools/libxl/libxl_pci.c 2011-09-15 15:40:28.000000000 +0200 > @@ -45,10 +45,10 @@ static unsigned int pcidev_encode_bdf(li > { > unsigned int value; > > - value = 0; > - value |= (pcidev->bus & 0xff) << 16; > - value |= (pcidev->dev & 0x1f) << (8+3); > - value |= (pcidev->func & 0x7) << (8+0); > + value = pcidev->domain << 16; > + value |= (pcidev->bus & 0xff) << 8; > + value |= (pcidev->dev & 0x1f) << 3; > + value |= (pcidev->func & 0x7); > > return value; > } > --- 2011-09-20.orig/tools/python/xen/lowlevel/xc/xc.c 2010-11-05 > 09:22:58.000000000 +0100 > +++ 2011-09-20/tools/python/xen/lowlevel/xc/xc.c 2011-09-15 15:48:10.000000000 > +0200 > @@ -609,7 +609,7 @@ static PyObject *pyxc_test_assign_device > { > uint32_t dom; > char *pci_str; > - int32_t bdf = 0; > + int32_t sbdf = 0; > int seg, bus, dev, func; > > static char *kwd_list[] = { "domid", "pci", NULL }; > @@ -619,20 +619,21 @@ static PyObject *pyxc_test_assign_device > > while ( next_bdf(&pci_str, &seg, &bus, &dev, &func) ) > { > - bdf |= (bus & 0xff) << 16; > - bdf |= (dev & 0x1f) << 11; > - bdf |= (func & 0x7) << 8; > + sbdf = seg << 16; > + sbdf |= (bus & 0xff) << 8; > + sbdf |= (dev & 0x1f) << 3; > + sbdf |= (func & 0x7); > > - if ( xc_test_assign_device(self->xc_handle, dom, bdf) != 0 ) > + if ( xc_test_assign_device(self->xc_handle, dom, sbdf) != 0 ) > { > if (errno == ENOSYS) > - bdf = -1; > + sbdf = -1; > break; > } > - bdf = 0; > + sbdf = 0; > } > > - return Py_BuildValue("i", bdf); > + return Py_BuildValue("i", sbdf); > } > > static PyObject *pyxc_assign_device(XcObject *self, > @@ -641,7 +642,7 @@ static PyObject *pyxc_assign_device(XcOb > { > uint32_t dom; > char *pci_str; > - int32_t bdf = 0; > + int32_t sbdf = 0; > int seg, bus, dev, func; > > static char *kwd_list[] = { "domid", "pci", NULL }; > @@ -651,20 +652,21 @@ static PyObject *pyxc_assign_device(XcOb > > while ( next_bdf(&pci_str, &seg, &bus, &dev, &func) ) > { > - bdf |= (bus & 0xff) << 16; > - bdf |= (dev & 0x1f) << 11; > - bdf |= (func & 0x7) << 8; > + sbdf = seg << 16; > + sbdf |= (bus & 0xff) << 8; > + sbdf |= (dev & 0x1f) << 3; > + sbdf |= (func & 0x7); > > - if ( xc_assign_device(self->xc_handle, dom, bdf) != 0 ) > + if ( xc_assign_device(self->xc_handle, dom, sbdf) != 0 ) > { > if (errno == ENOSYS) > - bdf = -1; > + sbdf = -1; > break; > } > - bdf = 0; > + sbdf = 0; > } > > - return Py_BuildValue("i", bdf); > + return Py_BuildValue("i", sbdf); > } > > static PyObject *pyxc_deassign_device(XcObject *self, > @@ -673,7 +675,7 @@ static PyObject *pyxc_deassign_device(Xc > { > uint32_t dom; > char *pci_str; > - int32_t bdf = 0; > + int32_t sbdf = 0; > int seg, bus, dev, func; > > static char *kwd_list[] = { "domid", "pci", NULL }; > @@ -683,26 +685,27 @@ static PyObject *pyxc_deassign_device(Xc > > while ( next_bdf(&pci_str, &seg, &bus, &dev, &func) ) > { > - bdf |= (bus & 0xff) << 16; > - bdf |= (dev & 0x1f) << 11; > - bdf |= (func & 0x7) << 8; > + sbdf = seg << 16; > + sbdf |= (bus & 0xff) << 8; > + sbdf |= (dev & 0x1f) << 3; > + sbdf |= (func & 0x7); > > - if ( xc_deassign_device(self->xc_handle, dom, bdf) != 0 ) > + if ( xc_deassign_device(self->xc_handle, dom, sbdf) != 0 ) > { > if (errno == ENOSYS) > - bdf = -1; > + sbdf = -1; > break; > } > - bdf = 0; > + sbdf = 0; > } > > - return Py_BuildValue("i", bdf); > + return Py_BuildValue("i", sbdf); > } > > static PyObject *pyxc_get_device_group(XcObject *self, > PyObject *args) > { > - uint32_t bdf = 0; > + uint32_t sbdf; > uint32_t max_sdevs, num_sdevs; > int domid, seg, bus, dev, func, rc, i; > PyObject *Pystr; > @@ -720,12 +723,13 @@ static PyObject *pyxc_get_device_group(X > if (sdev_array == NULL) > return PyErr_NoMemory(); > > - bdf |= (bus & 0xff) << 16; > - bdf |= (dev & 0x1f) << 11; > - bdf |= (func & 0x7) << 8; > + sbdf = seg << 16; > + sbdf |= (bus & 0xff) << 8; > + sbdf |= (dev & 0x1f) << 3; > + sbdf |= (func & 0x7); > > rc = xc_get_device_group(self->xc_handle, > - domid, bdf, max_sdevs, &num_sdevs, sdev_array); > + domid, sbdf, max_sdevs, &num_sdevs, sdev_array); > > if ( rc < 0 ) > { > --- 2011-09-20.orig/xen/arch/ia64/xen/dom0_ops.c 2011-09-19 10:58:18.000000000 > +0200 > +++ 2011-09-20/xen/arch/ia64/xen/dom0_ops.c 2011-09-15 16:32:59.000000000 > +0200 > @@ -258,138 +258,6 @@ long arch_do_domctl(xen_domctl_t *op, XE > } > break; > > - case XEN_DOMCTL_get_device_group: > - { > - struct domain *d; > - u32 max_sdevs; > - u8 bus, devfn; > - XEN_GUEST_HANDLE_64(uint32) sdevs; > - int num_sdevs; > - > - ret = -ENOSYS; > - if ( !iommu_enabled ) > - break; > - > - ret = -EINVAL; > - if ( (d = rcu_lock_domain_by_id(op->domain)) == NULL ) > - break; > - > - bus = (op->u.get_device_group.machine_bdf >> 16) & 0xff; > - devfn = (op->u.get_device_group.machine_bdf >> 8) & 0xff; > - max_sdevs = op->u.get_device_group.max_sdevs; > - sdevs = op->u.get_device_group.sdev_array; > - > - num_sdevs = iommu_get_device_group(d, bus, devfn, sdevs, max_sdevs); > - if ( num_sdevs < 0 ) > - { > - dprintk(XENLOG_ERR, "iommu_get_device_group() failed!\n"); > - ret = -EFAULT; > - op->u.get_device_group.num_sdevs = 0; > - } > - else > - { > - ret = 0; > - op->u.get_device_group.num_sdevs = num_sdevs; > - } > - if ( copy_to_guest(u_domctl, op, 1) ) > - ret = -EFAULT; > - rcu_unlock_domain(d); > - } > - break; > - > - case XEN_DOMCTL_test_assign_device: > - { > - u8 bus, devfn; > - > - ret = -ENOSYS; > - if ( !iommu_enabled ) > - break; > - > - ret = -EINVAL; > - bus = (op->u.assign_device.machine_bdf >> 16) & 0xff; > - devfn = (op->u.assign_device.machine_bdf >> 8) & 0xff; > - > - if ( device_assigned(bus, devfn) ) > - { > - printk( "XEN_DOMCTL_test_assign_device: " > - "%x:%x.%x already assigned, or non-existent\n", > - bus, PCI_SLOT(devfn), PCI_FUNC(devfn)); > - break; > - } > - ret = 0; > - } > - break; > - > - case XEN_DOMCTL_assign_device: > - { > - struct domain *d; > - u8 bus, devfn; > - > - ret = -ENOSYS; > - if ( !iommu_enabled ) > - break; > - > - ret = -EINVAL; > - if ( unlikely((d = get_domain_by_id(op->domain)) == NULL) ) > - { > - gdprintk(XENLOG_ERR, > - "XEN_DOMCTL_assign_device: get_domain_by_id() failed\n"); > - break; > - } > - bus = (op->u.assign_device.machine_bdf >> 16) & 0xff; > - devfn = (op->u.assign_device.machine_bdf >> 8) & 0xff; > - > - if ( device_assigned(bus, devfn) ) > - { > - gdprintk(XENLOG_ERR, "XEN_DOMCTL_assign_device: " > - "%x:%x.%x already assigned, or non-existent\n", > - bus, PCI_SLOT(devfn), PCI_FUNC(devfn)); > - break; > - } > - > - ret = assign_device(d, bus, devfn); > - if ( ret ) > - gdprintk(XENLOG_ERR, "XEN_DOMCTL_assign_device: " > - "assign device (%x:%x.%x) failed\n", > - bus, PCI_SLOT(devfn), PCI_FUNC(devfn)); > - put_domain(d); > - } > - break; > - > - case XEN_DOMCTL_deassign_device: > - { > - struct domain *d; > - u8 bus, devfn; > - > - ret = -ENOSYS; > - if ( !iommu_enabled ) > - break; > - > - ret = -EINVAL; > - if ( unlikely((d = get_domain_by_id(op->domain)) == NULL) ) > - { > - gdprintk(XENLOG_ERR, > - "XEN_DOMCTL_deassign_device: get_domain_by_id() failed\n"); > - break; > - } > - bus = (op->u.assign_device.machine_bdf >> 16) & 0xff; > - devfn = (op->u.assign_device.machine_bdf >> 8) & 0xff; > - > - if ( !device_assigned(bus, devfn) ) > - break; > - > - spin_lock(&pcidevs_lock); > - ret = deassign_device(d, bus, devfn); > - spin_unlock(&pcidevs_lock); > - if ( ret ) > - gdprintk(XENLOG_ERR, "XEN_DOMCTL_deassign_device: " > - "deassign device (%x:%x.%x) failed\n", > - bus, PCI_SLOT(devfn), PCI_FUNC(devfn)); > - > - put_domain(d); > - } > - break; > - > case XEN_DOMCTL_bind_pt_irq: > { > struct domain * d; > @@ -707,8 +575,8 @@ long arch_do_domctl(xen_domctl_t *op, XE > break; > > default: > - printk("arch_do_domctl: unrecognized domctl: %d!!!\n",op->cmd); > - ret = -ENOSYS; > + ret = iommu_do_domctl(op, u_domctl); > + break; > > } > > --- 2011-09-20.orig/xen/arch/x86/domctl.c 2011-06-16 09:21:02.000000000 +0200 > +++ 2011-09-20/xen/arch/x86/domctl.c 2011-09-15 16:09:39.000000000 +0200 > @@ -742,144 +742,6 @@ long arch_do_domctl( > } > break; > > - case XEN_DOMCTL_get_device_group: > - { > - struct domain *d; > - u32 max_sdevs; > - u8 bus, devfn; > - XEN_GUEST_HANDLE_64(uint32) sdevs; > - int num_sdevs; > - > - ret = -ENOSYS; > - if ( !iommu_enabled ) > - break; > - > - ret = -EINVAL; > - if ( (d = rcu_lock_domain_by_id(domctl->domain)) == NULL ) > - break; > - > - bus = (domctl->u.get_device_group.machine_bdf >> 16) & 0xff; > - devfn = (domctl->u.get_device_group.machine_bdf >> 8) & 0xff; > - max_sdevs = domctl->u.get_device_group.max_sdevs; > - sdevs = domctl->u.get_device_group.sdev_array; > - > - num_sdevs = iommu_get_device_group(d, bus, devfn, sdevs, max_sdevs); > - if ( num_sdevs < 0 ) > - { > - dprintk(XENLOG_ERR, "iommu_get_device_group() failed!\n"); > - ret = -EFAULT; > - domctl->u.get_device_group.num_sdevs = 0; > - } > - else > - { > - ret = 0; > - domctl->u.get_device_group.num_sdevs = num_sdevs; > - } > - if ( copy_to_guest(u_domctl, domctl, 1) ) > - ret = -EFAULT; > - rcu_unlock_domain(d); > - } > - break; > - > - case XEN_DOMCTL_test_assign_device: > - { > - u8 bus, devfn; > - > - ret = -ENOSYS; > - if ( !iommu_enabled ) > - break; > - > - ret = xsm_test_assign_device(domctl->u.assign_device.machine_bdf); > - if ( ret ) > - break; > - > - ret = -EINVAL; > - bus = (domctl->u.assign_device.machine_bdf >> 16) & 0xff; > - devfn = (domctl->u.assign_device.machine_bdf >> 8) & 0xff; > - > - if ( device_assigned(bus, devfn) ) > - { > - gdprintk(XENLOG_ERR, "XEN_DOMCTL_test_assign_device: " > - "%x:%x.%x already assigned, or non-existent\n", > - bus, PCI_SLOT(devfn), PCI_FUNC(devfn)); > - break; > - } > - ret = 0; > - } > - break; > - > - case XEN_DOMCTL_assign_device: > - { > - struct domain *d; > - u8 bus, devfn; > - > - ret = -ENOSYS; > - if ( !iommu_enabled ) > - break; > - > - ret = -EINVAL; > - if ( unlikely((d = get_domain_by_id(domctl->domain)) == NULL) ) > - { > - gdprintk(XENLOG_ERR, > - "XEN_DOMCTL_assign_device: get_domain_by_id() failed\n"); > - break; > - } > - > - ret = xsm_assign_device(d, domctl->u.assign_device.machine_bdf); > - if ( ret ) > - goto assign_device_out; > - > - bus = (domctl->u.assign_device.machine_bdf >> 16) & 0xff; > - devfn = (domctl->u.assign_device.machine_bdf >> 8) & 0xff; > - > - ret = assign_device(d, bus, devfn); > - if ( ret ) > - gdprintk(XENLOG_ERR, "XEN_DOMCTL_assign_device: " > - "assign device (%x:%x.%x) failed\n", > - bus, PCI_SLOT(devfn), PCI_FUNC(devfn)); > - > - assign_device_out: > - put_domain(d); > - } > - break; > - > - case XEN_DOMCTL_deassign_device: > - { > - struct domain *d; > - u8 bus, devfn; > - > - ret = -ENOSYS; > - if ( !iommu_enabled ) > - break; > - > - ret = -EINVAL; > - if ( unlikely((d = get_domain_by_id(domctl->domain)) == NULL) ) > - { > - gdprintk(XENLOG_ERR, > - "XEN_DOMCTL_deassign_device: get_domain_by_id() failed\n"); > - break; > - } > - > - ret = xsm_assign_device(d, domctl->u.assign_device.machine_bdf); > - if ( ret ) > - goto deassign_device_out; > - > - bus = (domctl->u.assign_device.machine_bdf >> 16) & 0xff; > - devfn = (domctl->u.assign_device.machine_bdf >> 8) & 0xff; > - > - spin_lock(&pcidevs_lock); > - ret = deassign_device(d, bus, devfn); > - spin_unlock(&pcidevs_lock); > - if ( ret ) > - gdprintk(XENLOG_ERR, "XEN_DOMCTL_deassign_device: " > - "deassign device (%x:%x.%x) failed\n", > - bus, PCI_SLOT(devfn), PCI_FUNC(devfn)); > - > - deassign_device_out: > - put_domain(d); > - } > - break; > - > case XEN_DOMCTL_bind_pt_irq: > { > struct domain * d; > @@ -1601,7 +1463,7 @@ long arch_do_domctl( > break; > > default: > - ret = -ENOSYS; > + ret = iommu_do_domctl(domctl, u_domctl); > break; > } > > --- 2011-09-20.orig/xen/drivers/passthrough/amd/pci_amd_iommu.c 2011-09-20 > 16:03:27.000000000 +0200 > +++ 2011-09-20/xen/drivers/passthrough/amd/pci_amd_iommu.c 2011-09-20 > 16:04:06.000000000 +0200 > @@ -305,7 +305,7 @@ static void amd_iommu_disable_domain_dev > } > > static int reassign_device( struct domain *source, struct domain *target, > - u8 bus, u8 devfn) > + u16 seg, u8 bus, u8 devfn) > { > struct pci_dev *pdev; > struct amd_iommu *iommu; > @@ -313,7 +313,7 @@ static int reassign_device( struct domai > struct hvm_iommu *t = domain_hvm_iommu(target); > > ASSERT(spin_is_locked(&pcidevs_lock)); > - pdev = pci_get_pdev_by_domain(source, 0, bus, devfn); > + pdev = pci_get_pdev_by_domain(source, seg, bus, devfn); > if ( !pdev ) > return -ENODEV; > > @@ -346,7 +346,7 @@ static int reassign_device( struct domai > return 0; > } > > -static int amd_iommu_assign_device(struct domain *d, u8 bus, u8 devfn) > +static int amd_iommu_assign_device(struct domain *d, u16 seg, u8 bus, u8 > devfn) > { > int bdf = (bus << 8) | devfn; > int req_id = get_dma_requestor_id(bdf); > @@ -361,7 +361,7 @@ static int amd_iommu_assign_device(struc > ivrs_mappings[req_id].read_permission); > } > > - return reassign_device(dom0, d, bus, devfn); > + return reassign_device(dom0, d, seg, bus, devfn); > } > > static void deallocate_next_page_table(struct page_info* pg, int level) > @@ -426,9 +426,9 @@ static void amd_iommu_domain_destroy(str > } > > static int amd_iommu_return_device( > - struct domain *s, struct domain *t, u8 bus, u8 devfn) > + struct domain *s, struct domain *t, u16 seg, u8 bus, u8 devfn) > { > - return reassign_device(s, t, bus, devfn); > + return reassign_device(s, t, seg, bus, devfn); > } > > static int amd_iommu_add_device(struct pci_dev *pdev) > @@ -475,7 +475,7 @@ static int amd_iommu_remove_device(struc > return 0; > } > > -static int amd_iommu_group_id(u8 bus, u8 devfn) > +static int amd_iommu_group_id(u16 seg, u8 bus, u8 devfn) > { > int rt; > int bdf = (bus << 8) | devfn; > --- 2011-09-20.orig/xen/drivers/passthrough/iommu.c 2011-08-25 > 15:06:35.000000000 +0200 > +++ 2011-09-20/xen/drivers/passthrough/iommu.c 2011-09-15 17:00:38.000000000 > +0200 > @@ -19,6 +19,7 @@ > #include <xen/paging.h> > #include <xen/guest_access.h> > #include <xen/softirq.h> > +#include <xsm/xsm.h> > > static void parse_iommu_param(char *s); > static int iommu_populate_page_table(struct domain *d); > @@ -165,7 +166,22 @@ int iommu_remove_device(struct pci_dev * > return hd->platform_ops->remove_device(pdev); > } > > -int assign_device(struct domain *d, u8 bus, u8 devfn) > +/* > + * If the device isn't owned by dom0, it means it already > + * has been assigned to other domain, or it doesn't exist. > + */ > +static int device_assigned(u16 seg, u8 bus, u8 devfn) > +{ > + struct pci_dev *pdev; > + > + spin_lock(&pcidevs_lock); > + pdev = pci_get_pdev_by_domain(dom0, seg, bus, devfn); > + spin_unlock(&pcidevs_lock); > + > + return pdev ? 0 : -1; > +} > + > +static int assign_device(struct domain *d, u16 seg, u8 bus, u8 devfn) > { > struct hvm_iommu *hd = domain_hvm_iommu(d); > int rc = 0; > @@ -174,7 +190,7 @@ int assign_device(struct domain *d, u8 b > return 0; > > spin_lock(&pcidevs_lock); > - if ( (rc = hd->platform_ops->assign_device(d, bus, devfn)) ) > + if ( (rc = hd->platform_ops->assign_device(d, seg, bus, devfn)) ) > goto done; > > if ( has_arch_pdevs(d) && !need_iommu(d) ) > @@ -272,7 +288,7 @@ int iommu_unmap_page(struct domain *d, u > } > > /* caller should hold the pcidevs_lock */ > -int deassign_device(struct domain *d, u8 bus, u8 devfn) > +int deassign_device(struct domain *d, u16 seg, u8 bus, u8 devfn) > { > struct hvm_iommu *hd = domain_hvm_iommu(d); > struct pci_dev *pdev = NULL; > @@ -282,7 +298,7 @@ int deassign_device(struct domain *d, u8 > return -EINVAL; > > ASSERT(spin_is_locked(&pcidevs_lock)); > - pdev = pci_get_pdev(0, bus, devfn); > + pdev = pci_get_pdev(seg, bus, devfn); > if ( !pdev ) > return -ENODEV; > > @@ -293,12 +309,12 @@ int deassign_device(struct domain *d, u8 > return -EINVAL; > } > > - ret = hd->platform_ops->reassign_device(d, dom0, bus, devfn); > + ret = hd->platform_ops->reassign_device(d, dom0, seg, bus, devfn); > if ( ret ) > { > dprintk(XENLOG_ERR VTDPREFIX, > - "d%d: Deassign device (%x:%x.%x) failed!\n", > - d->domain_id, bus, PCI_SLOT(devfn), PCI_FUNC(devfn)); > + "d%d: Deassign device (%04x:%02x:%02x.%u) failed!\n", > + d->domain_id, seg, bus, PCI_SLOT(devfn), PCI_FUNC(devfn)); > return ret; > } > > @@ -347,7 +363,8 @@ int __init iommu_setup(void) > return rc; > } > > -int iommu_get_device_group(struct domain *d, u8 bus, u8 devfn, > +static int iommu_get_device_group( > + struct domain *d, u16 seg, u8 bus, u8 devfn, > XEN_GUEST_HANDLE_64(uint32) buf, int max_sdevs) > { > struct hvm_iommu *hd = domain_hvm_iommu(d); > @@ -360,15 +377,16 @@ int iommu_get_device_group(struct domain > if ( !iommu_enabled || !ops || !ops->get_device_group_id ) > return 0; > > - group_id = ops->get_device_group_id(bus, devfn); > + group_id = ops->get_device_group_id(seg, bus, devfn); > > spin_lock(&pcidevs_lock); > for_each_pdev( d, pdev ) > { > - if ( (pdev->bus == bus) && (pdev->devfn == devfn) ) > + if ( (pdev->seg != seg) || > + ((pdev->bus == bus) && (pdev->devfn == devfn)) ) > continue; > > - sdev_id = ops->get_device_group_id(pdev->bus, pdev->devfn); > + sdev_id = ops->get_device_group_id(seg, pdev->bus, pdev->devfn); > if ( (sdev_id == group_id) && (i < max_sdevs) ) > { > bdf = 0; > @@ -443,6 +461,154 @@ void iommu_crash_shutdown(void) > iommu_enabled = 0; > } > > +int iommu_do_domctl( > + struct xen_domctl *domctl, > + XEN_GUEST_HANDLE(xen_domctl_t) u_domctl) > +{ > + struct domain *d; > + u16 seg; > + u8 bus, devfn; > + int ret = 0; > + > + if ( !iommu_enabled ) > + return -ENOSYS; > + > + switch ( domctl->cmd ) > + { > + case XEN_DOMCTL_get_device_group: > + { > + u32 max_sdevs; > + XEN_GUEST_HANDLE_64(uint32) sdevs; > + > + ret = -EINVAL; > + if ( (d = rcu_lock_domain_by_id(domctl->domain)) == NULL ) > + break; > + > + seg = domctl->u.get_device_group.machine_sbdf >> 16; > + bus = (domctl->u.get_device_group.machine_sbdf >> 8) & 0xff; > + devfn = domctl->u.get_device_group.machine_sbdf & 0xff; > + max_sdevs = domctl->u.get_device_group.max_sdevs; > + sdevs = domctl->u.get_device_group.sdev_array; > + > + ret = iommu_get_device_group(d, seg, bus, devfn, sdevs, max_sdevs); > + if ( ret < 0 ) > + { > + dprintk(XENLOG_ERR, "iommu_get_device_group() failed!\n"); > + ret = -EFAULT; > + domctl->u.get_device_group.num_sdevs = 0; > + } > + else > + { > + domctl->u.get_device_group.num_sdevs = ret; > + ret = 0; > + } > + if ( copy_to_guest(u_domctl, domctl, 1) ) > + ret = -EFAULT; > + rcu_unlock_domain(d); > + } > + break; > + > + case XEN_DOMCTL_test_assign_device: > + ret = xsm_test_assign_device(domctl->u.assign_device.machine_sbdf); > + if ( ret ) > + break; > + > + seg = domctl->u.get_device_group.machine_sbdf >> 16; > + bus = (domctl->u.assign_device.machine_sbdf >> 8) & 0xff; > + devfn = domctl->u.assign_device.machine_sbdf & 0xff; > + > + if ( device_assigned(seg, bus, devfn) ) > + { > + gdprintk(XENLOG_ERR, "XEN_DOMCTL_test_assign_device: " > + "%04x:%02x:%02x.%u already assigned, or non-existent\n", > + seg, bus, PCI_SLOT(devfn), PCI_FUNC(devfn)); > + ret = -EINVAL; > + } > + break; > + > + case XEN_DOMCTL_assign_device: > + if ( unlikely((d = get_domain_by_id(domctl->domain)) == NULL) ) > + { > + gdprintk(XENLOG_ERR, > + "XEN_DOMCTL_assign_device: get_domain_by_id() failed\n"); > + ret = -EINVAL; > + break; > + } > + > + ret = xsm_assign_device(d, domctl->u.assign_device.machine_sbdf); > + if ( ret ) > + goto assign_device_out; > + > + seg = domctl->u.get_device_group.machine_sbdf >> 16; > + bus = (domctl->u.assign_device.machine_sbdf >> 8) & 0xff; > + devfn = domctl->u.assign_device.machine_sbdf & 0xff; > + > +#ifdef __ia64__ /* XXX Is this really needed? */ > + if ( device_assigned(seg, bus, devfn) ) > + { > + gdprintk(XENLOG_ERR, "XEN_DOMCTL_assign_device: " > + "%x:%x.%x already assigned, or non-existent\n", > + bus, PCI_SLOT(devfn), PCI_FUNC(devfn)); > + ret = -EINVAL; > + goto assign_device_out; > + } > +#endif > + > + ret = assign_device(d, seg, bus, devfn); > + if ( ret ) > + gdprintk(XENLOG_ERR, "XEN_DOMCTL_assign_device: " > + "assign device (%04x:%02x:%02x.%u) failed\n", > + seg, bus, PCI_SLOT(devfn), PCI_FUNC(devfn)); > + > + assign_device_out: > + put_domain(d); > + break; > + > + case XEN_DOMCTL_deassign_device: > + if ( unlikely((d = get_domain_by_id(domctl->domain)) == NULL) ) > + { > + gdprintk(XENLOG_ERR, > + "XEN_DOMCTL_deassign_device: get_domain_by_id() failed\n"); > + ret = -EINVAL; > + break; > + } > + > + ret = xsm_assign_device(d, domctl->u.assign_device.machine_sbdf); > + if ( ret ) > + goto deassign_device_out; > + > + seg = domctl->u.get_device_group.machine_sbdf >> 16; > + bus = (domctl->u.assign_device.machine_sbdf >> 8) & 0xff; > + devfn = domctl->u.assign_device.machine_sbdf & 0xff; > + > +#ifdef __ia64__ /* XXX Is this really needed? */ > + if ( !device_assigned(seg, bus, devfn) ) > + { > + ret = -EINVAL; > + goto deassign_device_out; > + } > +#endif > + > + spin_lock(&pcidevs_lock); > + ret = deassign_device(d, seg, bus, devfn); > + spin_unlock(&pcidevs_lock); > + if ( ret ) > + gdprintk(XENLOG_ERR, "XEN_DOMCTL_deassign_device: " > + "deassign device (%04x:%02x:%02x.%u) failed\n", > + seg, bus, PCI_SLOT(devfn), PCI_FUNC(devfn)); > + > + deassign_device_out: > + put_domain(d); > + break; > + > + default: > + ret = -ENOSYS; > + break; > + } > + > + return ret; > +} > + > /* > * Local variables: > * mode: C > --- 2011-09-20.orig/xen/drivers/passthrough/pci.c 2011-08-25 > 15:06:35.000000000 +0200 > +++ 2011-09-20/xen/drivers/passthrough/pci.c 2011-08-25 15:06:40.000000000 > +0200 > @@ -441,11 +441,12 @@ void pci_release_devices(struct domain * > while ( (pdev = pci_get_pdev_by_domain(d, -1, -1, -1)) ) > { > pci_cleanup_msi(pdev); > - bus = pdev->bus; devfn = pdev->devfn; > - if ( deassign_device(d, bus, devfn) ) > - printk("domain %d: deassign device (%02x:%02x.%x) failed!\n", > - d->domain_id, pdev->bus, PCI_SLOT(pdev->devfn), > - PCI_FUNC(pdev->devfn)); > + bus = pdev->bus; > + devfn = pdev->devfn; > + if ( deassign_device(d, pdev->seg, bus, devfn) ) > + printk("domain %d: deassign device (%04x:%02x:%02x.%u) > failed!\n", > + d->domain_id, pdev->seg, bus, > + PCI_SLOT(devfn), PCI_FUNC(devfn)); > } > spin_unlock(&pcidevs_lock); > } > --- 2011-09-20.orig/xen/drivers/passthrough/vtd/iommu.c 2011-09-20 > 16:03:17.000000000 +0200 > +++ 2011-09-20/xen/drivers/passthrough/vtd/iommu.c 2011-09-20 > 16:04:11.000000000 +0200 > @@ -1626,13 +1626,13 @@ out: > static int reassign_device_ownership( > struct domain *source, > struct domain *target, > - u8 bus, u8 devfn) > + u16 seg, u8 bus, u8 devfn) > { > struct pci_dev *pdev; > int ret; > > ASSERT(spin_is_locked(&pcidevs_lock)); > - pdev = pci_get_pdev_by_domain(source, 0, bus, devfn); > + pdev = pci_get_pdev_by_domain(source, seg, bus, devfn); > > if (!pdev) > return -ENODEV; > @@ -2166,27 +2166,8 @@ int __init intel_vtd_setup(void) > return ret; > } > > -/* > - * If the device isn't owned by dom0, it means it already > - * has been assigned to other domain, or it's not exist. > - */ > -int device_assigned(u8 bus, u8 devfn) > -{ > - struct pci_dev *pdev; > - > - spin_lock(&pcidevs_lock); > - pdev = pci_get_pdev_by_domain(dom0, 0, bus, devfn); > - if (!pdev) > - { > - spin_unlock(&pcidevs_lock); > - return -1; > - } > - > - spin_unlock(&pcidevs_lock); > - return 0; > -} > - > -static int intel_iommu_assign_device(struct domain *d, u8 bus, u8 devfn) > +static int intel_iommu_assign_device( > + struct domain *d, u16 seg, u8 bus, u8 devfn) > { > struct acpi_rmrr_unit *rmrr; > int ret = 0, i; > @@ -2197,7 +2178,7 @@ static int intel_iommu_assign_device(str > return -ENODEV; > > ASSERT(spin_is_locked(&pcidevs_lock)); > - pdev = pci_get_pdev(0, bus, devfn); > + pdev = pci_get_pdev(seg, bus, devfn); > if (!pdev) > return -ENODEV; > > @@ -2208,7 +2189,7 @@ static int intel_iommu_assign_device(str > return -EBUSY; > } > > - ret = reassign_device_ownership(dom0, d, bus, devfn); > + ret = reassign_device_ownership(dom0, d, seg, bus, devfn); > if ( ret ) > goto done; > > @@ -2240,7 +2221,7 @@ done: > return ret; > } > > -static int intel_iommu_group_id(u8 bus, u8 devfn) > +static int intel_iommu_group_id(u16 seg, u8 bus, u8 devfn) > { > u8 secbus; > if ( find_upstream_bridge(&bus, &devfn, &secbus) < 0 ) > --- 2011-09-20.orig/xen/include/public/domctl.h 2011-09-19 10:58:18.000000000 > +0200 > +++ 2011-09-20/xen/include/public/domctl.h 2011-09-15 15:39:21.000000000 +0200 > @@ -455,15 +455,15 @@ DEFINE_XEN_GUEST_HANDLE(xen_domctl_sendt > /* XEN_DOMCTL_test_assign_device */ > /* XEN_DOMCTL_deassign_device */ > struct xen_domctl_assign_device { > - uint32_t machine_bdf; /* machine PCI ID of assigned device */ > + uint32_t machine_sbdf; /* machine PCI ID of assigned device */ > }; > typedef struct xen_domctl_assign_device xen_domctl_assign_device_t; > DEFINE_XEN_GUEST_HANDLE(xen_domctl_assign_device_t); > > -/* Retrieve sibling devices infomation of machine_bdf */ > +/* Retrieve sibling devices infomation of machine_sbdf */ > /* XEN_DOMCTL_get_device_group */ > struct xen_domctl_get_device_group { > - uint32_t machine_bdf; /* IN */ > + uint32_t machine_sbdf; /* IN */ > uint32_t max_sdevs; /* IN */ > uint32_t num_sdevs; /* OUT */ > XEN_GUEST_HANDLE_64(uint32) sdev_array; /* OUT */ > --- 2011-09-20.orig/xen/include/xen/iommu.h 2011-08-25 15:06:23.000000000 > +0200 > +++ 2011-09-20/xen/include/xen/iommu.h 2011-09-15 16:46:28.000000000 +0200 > @@ -74,11 +74,7 @@ int iommu_remove_device(struct pci_dev * > int iommu_domain_init(struct domain *d); > void iommu_dom0_init(struct domain *d); > void iommu_domain_destroy(struct domain *d); > -int device_assigned(u8 bus, u8 devfn); > -int assign_device(struct domain *d, u8 bus, u8 devfn); > -int deassign_device(struct domain *d, u8 bus, u8 devfn); > -int iommu_get_device_group(struct domain *d, u8 bus, u8 devfn, > - XEN_GUEST_HANDLE_64(uint32) buf, int max_sdevs); > +int deassign_device(struct domain *d, u16 seg, u8 bus, u8 devfn); > > /* iommu_map_page() takes flags to direct the mapping operation. */ > #define _IOMMUF_readable 0 > @@ -125,14 +121,14 @@ struct iommu_ops { > void (*dom0_init)(struct domain *d); > int (*add_device)(struct pci_dev *pdev); > int (*remove_device)(struct pci_dev *pdev); > - int (*assign_device)(struct domain *d, u8 bus, u8 devfn); > + int (*assign_device)(struct domain *d, u16 seg, u8 bus, u8 devfn); > void (*teardown)(struct domain *d); > int (*map_page)(struct domain *d, unsigned long gfn, unsigned long mfn, > unsigned int flags); > int (*unmap_page)(struct domain *d, unsigned long gfn); > int (*reassign_device)(struct domain *s, struct domain *t, > - u8 bus, u8 devfn); > - int (*get_device_group_id)(u8 bus, u8 devfn); > + u16 seg, u8 bus, u8 devfn); > + int (*get_device_group_id)(u16 seg, u8 bus, u8 devfn); > void (*update_ire_from_apic)(unsigned int apic, unsigned int reg, > unsigned int value); > void (*update_ire_from_msi)(struct msi_desc *msi_desc, struct msi_msg > *msg); > void (*read_msi_from_ire)(struct msi_desc *msi_desc, struct msi_msg > *msg); > @@ -155,4 +151,6 @@ void iommu_crash_shutdown(void); > void iommu_set_dom0_mapping(struct domain *d); > void iommu_share_p2m_table(struct domain *d); > > +int iommu_do_domctl(struct xen_domctl *, XEN_GUEST_HANDLE(xen_domctl_t)); > + > #endif /* _IOMMU_H_ */ > > > _______________________________________________ > Xen-devel mailing list > Xen-devel@lists.xensource.com > http://lists.xensource.com/xen-devel _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel From xen-devel-bounces@lists.xensource.com Wed Sep 21 05:39:42 2011 Return-path: <xen-devel-bounces@lists.xensource.com> Envelope-to: www-data@lists.xensource.com Delivery-date: Wed, 21 Sep 2011 05:39:42 -0700 Received: from localhost ([127.0.0.1] helo=lists.colo.xensource.com) by lists.xensource.com with esmtp (Exim 4.43) id 1R6M5W-0003ic-Hw; Wed, 21 Sep 2011 05:39:42 -0700 Received: from mail216.messagelabs.com ([85.158.143.99]) by lists.xensource.com with esmtp (Exim 4.43) id 1R6M3r-00037z-N1 for xen-devel@lists.xensource.com; Wed, 21 Sep 2011 05:38:00 -0700 X-Env-Sender: Stefano.Stabellini@eu.citrix.com X-Msg-Ref: server-2.tower-216.messagelabs.com!1316608675!18651332!1 X-Originating-IP: [66.165.176.63] X-StarScan-Version: 6.4.1; banners=-,-,- X-VirusChecked: Checked Received: (qmail 30167 invoked from network); 21 Sep 2011 12:37:56 -0000 Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63) by server-2.tower-216.messagelabs.com with RC4-SHA encrypted SMTP; 21 Sep 2011 12:37:56 -0000 X-IronPort-AV: E=Sophos;i="4.68,417,1312171200"; d="scan'208";a="164112601" Received: from ftlpmailmx02.citrite.net ([10.13.107.66]) by FTLPIPO02.CITRIX.COM with ESMTP/TLS/RC4-MD5; 21 Sep 2011 08:37:55 -0400 Received: from smtp01.ad.xensource.com (10.219.128.104) by smtprelay.citrix.com (10.13.107.66) with Microsoft SMTP Server id 8.3.137.0; Wed, 21 Sep 2011 08:37:54 -0400 Received: from localhost.localdomain (kaball.uk.xensource.com [10.80.2.59]) by smtp01.ad.xensource.com (8.13.1/8.13.1) with ESMTP id p8LCbiKR024297; Wed, 21 Sep 2011 05:37:45 -0700 From: <stefano.stabellini@eu.citrix.com> To: konrad.wilk@oracle.com Date: Wed, 21 Sep 2011 13:37:50 +0100 Message-ID: <1316608670-23167-1-git-send-email-stefano.stabellini@eu.citrix.com> X-Mailer: git-send-email 1.7.0.4 MIME-Version: 1.0 Content-Type: text/plain Cc: Ian.Campbell@eu.citrix.com, jeremy@goop.org, xen-devel@lists.xensource.com, Stefano Stabellini <stefano.stabellini@eu.citrix.com>, Stefano.Stabellini@eu.citrix.com Subject: [Xen-devel] [PATCH] xen: change XEN_PLATFORM_PCI to bool default y X-BeenThere: xen-devel@lists.xensource.com X-Mailman-Version: 2.1.5 Precedence: list List-Id: Xen developer discussion <xen-devel.lists.xensource.com> List-Unsubscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe> List-Post: <mailto:xen-devel@lists.xensource.com> List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help> List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=subscribe> Sender: xen-devel-bounces@lists.xensource.com Errors-To: xen-devel-bounces@lists.xensource.com From: Stefano Stabellini <stefano.stabellini@eu.citrix.com> The xen-platform-pci module is small and for PV on HVM guests is a requirement for xenbus. Signed-off-by: Stefano Stabellini <stefano.stabellini@eu.citrix.com> --- drivers/xen/Kconfig | 4 ++-- 1 files changed, 2 insertions(+), 2 deletions(-) diff --git a/drivers/xen/Kconfig b/drivers/xen/Kconfig index 5f7ff8e..a64b8e8 100644 --- a/drivers/xen/Kconfig +++ b/drivers/xen/Kconfig @@ -138,9 +138,9 @@ config XEN_GRANT_DEV_ALLOC or as part of an inter-domain shared memory channel. config XEN_PLATFORM_PCI - tristate "xen platform pci device driver" + bool "xen platform pci device driver" depends on XEN_PVHVM && PCI - default m + default y help Driver for the Xen PCI Platform device: it is responsible for initializing xenbus and grant_table when running in a Xen HVM -- 1.7.2.3 _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel From xen-devel-bounces@lists.xensource.com Wed Sep 21 05:44:08 2011 Return-path: <xen-devel-bounces@lists.xensource.com> Envelope-to: www-data@lists.xensource.com Delivery-date: Wed, 21 Sep 2011 05:44:08 -0700 Received: from localhost ([127.0.0.1] helo=lists.colo.xensource.com) by lists.xensource.com with esmtp (Exim 4.43) id 1R6M9n-0004EM-V6; Wed, 21 Sep 2011 05:44:08 -0700 Received: from mail182.messagelabs.com ([85.158.139.83]) by lists.xensource.com with esmtp (Exim 4.43) id 1R6M9I-000423-4t for xen-devel@lists.xensource.com; Wed, 21 Sep 2011 05:43:36 -0700 X-Env-Sender: Stefano.Stabellini@eu.citrix.com X-Msg-Ref: server-9.tower-182.messagelabs.com!1316609012!19177521!1 X-Originating-IP: [62.200.22.115] X-StarScan-Version: 6.4.1; banners=-,-,- X-VirusChecked: Checked Received: (qmail 29204 invoked from network); 21 Sep 2011 12:43:33 -0000 Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115) by server-9.tower-182.messagelabs.com with RC4-SHA encrypted SMTP; 21 Sep 2011 12:43:33 -0000 X-IronPort-AV: E=Sophos;i="4.68,417,1312156800"; d="scan'208";a="7978465" Received: from lonpmailmx01.citrite.net ([10.30.203.162]) by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5; 21 Sep 2011 12:42:31 +0000 Received: from kaball.uk.xensource.com (10.80.2.59) by LONPMAILMX01.citrite.net (10.30.203.162) with Microsoft SMTP Server id 8.3.137.0; Wed, 21 Sep 2011 13:42:31 +0100 Date: Wed, 21 Sep 2011 13:42:22 +0100 From: Stefano Stabellini <stefano.stabellini@eu.citrix.com> X-X-Sender: sstabellini@kaball-desktop To: Keir Fraser <keir.xen@gmail.com> Subject: Re: [Xen-devel] [PATCH 3/7] PCI multi-seg: adjust domctl interface In-Reply-To: <CA9F287F.212AC%keir.xen@gmail.com> Message-ID: <alpine.DEB.2.00.1109211339250.8700@kaball-desktop> References: <CA9F287F.212AC%keir.xen@gmail.com> User-Agent: Alpine 2.00 (DEB 1167 2008-08-23) MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>, Ian Jackson <Ian.Jackson@eu.citrix.com>, Jan Beulich <JBeulich@suse.com> X-BeenThere: xen-devel@lists.xensource.com X-Mailman-Version: 2.1.5 Precedence: list List-Id: Xen developer discussion <xen-devel.lists.xensource.com> List-Unsubscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe> List-Post: <mailto:xen-devel@lists.xensource.com> List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help> List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=subscribe> Sender: xen-devel-bounces@lists.xensource.com Errors-To: xen-devel-bounces@lists.xensource.com On Wed, 21 Sep 2011, Keir Fraser wrote: > On 20/09/2011 08:18, "Jan Beulich" <JBeulich@suse.com> wrote: > > > Again, a couple of directly related functions at once get adjusted to > > account for the segment number. > > > > Do we need to bump XEN_DOMCTL_INTERFACE_VERSION for the changes to the > > domctl interface (namely the renaming and bit-reassigment of the > > machine_bdf member of two of the interface structures)? If so, this > > can probably be done as the patch gets checked in (rather than me > > having to re-submit)? > > Ian suggests we should keep compatibility with old qemu versions. Are any of > these hypercall commands used by qemu? > Before b4bb8b3f09d1c873f522f6aebe1f125a6d1854d0 xc_assign_device and xc_deassign_device were called by qemu. Now they are called by libxl. _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel From xen-devel-bounces@lists.xensource.com Wed Sep 21 06:03:12 2011 Return-path: <xen-devel-bounces@lists.xensource.com> Envelope-to: www-data@lists.xensource.com Delivery-date: Wed, 21 Sep 2011 06:03:12 -0700 Received: from localhost ([127.0.0.1] helo=lists.colo.xensource.com) by lists.xensource.com with esmtp (Exim 4.43) id 1R6MSG-0004sH-CG; Wed, 21 Sep 2011 06:03:12 -0700 Received: from mail27.messagelabs.com ([193.109.254.147]) by lists.xensource.com with esmtp (Exim 4.43) id 1R6MPg-0004dF-A7 for xen-devel@lists.xensource.com; Wed, 21 Sep 2011 06:00:39 -0700 X-Env-Sender: anthony.perard@citrix.com X-Msg-Ref: server-7.tower-27.messagelabs.com!1316610004!49569723!1 X-Originating-IP: [66.165.176.63] X-StarScan-Version: 6.4.1; banners=-,-,- X-VirusChecked: Checked Received: (qmail 22615 invoked from network); 21 Sep 2011 13:00:06 -0000 Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63) by server-7.tower-27.messagelabs.com with RC4-SHA encrypted SMTP; 21 Sep 2011 13:00:06 -0000 X-IronPort-AV: E=Sophos;i="4.68,417,1312171200"; d="scan'208";a="164115861" Received: from ftlpmailmx02.citrite.net ([10.13.107.66]) by FTLPIPO02.CITRIX.COM with ESMTP/TLS/RC4-MD5; 21 Sep 2011 09:00:27 -0400 Received: from smtp01.ad.xensource.com (10.219.128.104) by smtprelay.citrix.com (10.13.107.66) with Microsoft SMTP Server id 8.3.137.0; Wed, 21 Sep 2011 09:00:27 -0400 Received: from perard.uk.xensource.com (dhcp-3-28.uk.xensource.com [10.80.3.28] (may be forged)) by smtp01.ad.xensource.com (8.13.1/8.13.1) with ESMTP id p8LD0PSE024347; Wed, 21 Sep 2011 06:00:25 -0700 From: Anthony PERARD <anthony.perard@citrix.com> To: Xen Devel <xen-devel@lists.xensource.com> Date: Wed, 21 Sep 2011 13:59:50 +0100 Message-ID: <1316609997-26002-1-git-send-email-anthony.perard@citrix.com> X-Mailer: git-send-email 1.7.2.5 MIME-Version: 1.0 Content-Type: text/plain Cc: Ian Campbell <Ian.Campbell@eu.citrix.com>, Anthony PERARD <anthony.perard@citrix.com>, Stefano Stabellini <stefano.stabellini@eu.citrix.com> Subject: [Xen-devel] [PATCH RESEND V8 0/7] Introduce a QMP client X-BeenThere: xen-devel@lists.xensource.com X-Mailman-Version: 2.1.5 Precedence: list List-Id: Xen developer discussion <xen-devel.lists.xensource.com> List-Unsubscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe> List-Post: <mailto:xen-devel@lists.xensource.com> List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help> List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=subscribe> Sender: xen-devel-bounces@lists.xensource.com Errors-To: xen-devel-bounces@lists.xensource.com Patch series rebased on last xen-unstable. No other change have been done. Anthony PERARD (7): libxl: Rename libxl.idl to libxl_types.idl. libxl: Add get/set_default_namespace in libxltypes.py. libxl: Introduce libxl_internal_types.idl. libxl: Introduce libxl__realloc. libxl: Intruduce libxl__strndup. libxl: Introduce JSON parsing stuff. libxl: Introduce a QMP client README | 1 + tools/libxl/Makefile | 21 +- tools/libxl/gentypes.py | 9 +- tools/libxl/libxl.c | 2 + tools/libxl/libxl_create.c | 4 + tools/libxl/libxl_dm.c | 10 + tools/libxl/libxl_internal.c | 34 ++ tools/libxl/libxl_internal.h | 122 ++++++ tools/libxl/libxl_json.c | 560 ++++++++++++++++++++++++++ tools/libxl/libxl_qmp.c | 587 ++++++++++++++++++++++++++++ tools/libxl/{libxl.idl => libxl_types.idl} | 2 + tools/libxl/libxl_types_internal.idl | 9 + tools/libxl/libxltypes.py | 18 +- tools/ocaml/libs/xl/Makefile | 4 +- tools/python/Makefile | 4 +- 15 files changed, 1369 insertions(+), 18 deletions(-) create mode 100644 tools/libxl/libxl_json.c create mode 100644 tools/libxl/libxl_qmp.c rename tools/libxl/{libxl.idl => libxl_types.idl} (99%) create mode 100644 tools/libxl/libxl_types_internal.idl -- Anthony PERARD _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel From xen-devel-bounces@lists.xensource.com Wed Sep 21 06:04:41 2011 Return-path: <xen-devel-bounces@lists.xensource.com> Envelope-to: www-data@lists.xensource.com Delivery-date: Wed, 21 Sep 2011 06:04:41 -0700 Received: from localhost ([127.0.0.1] helo=lists.colo.xensource.com) by lists.xensource.com with esmtp (Exim 4.43) id 1R6MTh-0005FG-Jd; Wed, 21 Sep 2011 06:04:41 -0700 Received: from mail21.messagelabs.com ([85.158.143.35]) by lists.xensource.com with esmtp (Exim 4.43) id 1R6MPj-0004dJ-E1 for xen-devel@lists.xensource.com; Wed, 21 Sep 2011 06:00:39 -0700 X-Env-Sender: anthony.perard@citrix.com X-Msg-Ref: server-4.tower-21.messagelabs.com!1316609993!61062359!3 X-Originating-IP: [66.165.176.89] X-StarScan-Version: 6.4.1; banners=-,-,- X-VirusChecked: Checked Received: (qmail 10650 invoked from network); 21 Sep 2011 12:59:56 -0000 Received: from smtp.citrix.com (HELO SMTP.CITRIX.COM) (66.165.176.89) by server-4.tower-21.messagelabs.com with RC4-SHA encrypted SMTP; 21 Sep 2011 12:59:56 -0000 X-IronPort-AV: E=Sophos;i="4.68,417,1312171200"; d="scan'208";a="17568590" Received: from ftlpmailmx02.citrite.net ([10.13.107.66]) by FTLPIPO01.CITRIX.COM with ESMTP/TLS/RC4-MD5; 21 Sep 2011 09:00:31 -0400 Received: from smtp01.ad.xensource.com (10.219.128.104) by smtprelay.citrix.com (10.13.107.66) with Microsoft SMTP Server id 8.3.137.0; Wed, 21 Sep 2011 09:00:31 -0400 Received: from perard.uk.xensource.com (dhcp-3-28.uk.xensource.com [10.80.3.28] (may be forged)) by smtp01.ad.xensource.com (8.13.1/8.13.1) with ESMTP id p8LD0PSI024347; Wed, 21 Sep 2011 06:00:30 -0700 From: Anthony PERARD <anthony.perard@citrix.com> To: Xen Devel <xen-devel@lists.xensource.com> Date: Wed, 21 Sep 2011 13:59:54 +0100 Message-ID: <1316609997-26002-5-git-send-email-anthony.perard@citrix.com> X-Mailer: git-send-email 1.7.2.5 In-Reply-To: <1316609997-26002-1-git-send-email-anthony.perard@citrix.com> References: <1316609997-26002-1-git-send-email-anthony.perard@citrix.com> MIME-Version: 1.0 Content-Type: text/plain Cc: Ian Campbell <Ian.Campbell@eu.citrix.com>, Anthony PERARD <anthony.perard@citrix.com>, Stefano Stabellini <stefano.stabellini@eu.citrix.com> Subject: [Xen-devel] [PATCH RESEND V8 4/7] libxl: Introduce libxl__realloc. X-BeenThere: xen-devel@lists.xensource.com X-Mailman-Version: 2.1.5 Precedence: list List-Id: Xen developer discussion <xen-devel.lists.xensource.com> List-Unsubscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe> List-Post: <mailto:xen-devel@lists.xensource.com> List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help> List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=subscribe> Sender: xen-devel-bounces@lists.xensource.com Errors-To: xen-devel-bounces@lists.xensource.com Signed-off-by: Anthony PERARD <anthony.perard@citrix.com> --- tools/libxl/libxl_internal.c | 24 ++++++++++++++++++++++++ tools/libxl/libxl_internal.h | 1 + 2 files changed, 25 insertions(+), 0 deletions(-) diff --git a/tools/libxl/libxl_internal.c b/tools/libxl/libxl_internal.c index e259278..c4d54f9 100644 --- a/tools/libxl/libxl_internal.c +++ b/tools/libxl/libxl_internal.c @@ -102,6 +102,30 @@ void *libxl__calloc(libxl__gc *gc, size_t nmemb, size_t size) return ptr; } +void *libxl__realloc(libxl__gc *gc, void *ptr, size_t new_size) +{ + void *new_ptr = realloc(ptr, new_size); + int i = 0; + + if (new_ptr == NULL && new_size != 0) { + return NULL; + } + + if (ptr == NULL) { + libxl__ptr_add(gc, new_ptr); + } else if (new_ptr != ptr) { + for (i = 0; i < gc->alloc_maxsize; i++) { + if (gc->alloc_ptrs[i] == ptr) { + gc->alloc_ptrs[i] = new_ptr; + break; + } + } + } + + + return new_ptr; +} + char *libxl__sprintf(libxl__gc *gc, const char *fmt, ...) { char *s; diff --git a/tools/libxl/libxl_internal.h b/tools/libxl/libxl_internal.h index 739e45e..5d270bb 100644 --- a/tools/libxl/libxl_internal.h +++ b/tools/libxl/libxl_internal.h @@ -145,6 +145,7 @@ _hidden int libxl__ptr_add(libxl__gc *gc, void *ptr); _hidden void libxl__free_all(libxl__gc *gc); _hidden void *libxl__zalloc(libxl__gc *gc, int bytes); _hidden void *libxl__calloc(libxl__gc *gc, size_t nmemb, size_t size); +_hidden void *libxl__realloc(libxl__gc *gc, void *ptr, size_t new_size); _hidden char *libxl__sprintf(libxl__gc *gc, const char *fmt, ...) PRINTF_ATTRIBUTE(2, 3); _hidden char *libxl__strdup(libxl__gc *gc, const char *c); _hidden char *libxl__dirname(libxl__gc *gc, const char *s); -- Anthony PERARD _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel From xen-devel-bounces@lists.xensource.com Wed Sep 21 06:05:35 2011 Return-path: <xen-devel-bounces@lists.xensource.com> Envelope-to: www-data@lists.xensource.com Delivery-date: Wed, 21 Sep 2011 06:05:35 -0700 Received: from localhost ([127.0.0.1] helo=lists.colo.xensource.com) by lists.xensource.com with esmtp (Exim 4.43) id 1R6MUZ-0005c6-A0; Wed, 21 Sep 2011 06:05:35 -0700 Received: from mail21.messagelabs.com ([85.158.143.35]) by lists.xensource.com with esmtp (Exim 4.43) id 1R6MPi-0004dI-E7 for xen-devel@lists.xensource.com; Wed, 21 Sep 2011 06:00:39 -0700 X-Env-Sender: anthony.perard@citrix.com X-Msg-Ref: server-4.tower-21.messagelabs.com!1316609993!61062359!2 X-Originating-IP: [66.165.176.89] X-StarScan-Version: 6.4.1; banners=-,-,- X-VirusChecked: Checked Received: (qmail 10559 invoked from network); 21 Sep 2011 12:59:55 -0000 Received: from smtp.citrix.com (HELO SMTP.CITRIX.COM) (66.165.176.89) by server-4.tower-21.messagelabs.com with RC4-SHA encrypted SMTP; 21 Sep 2011 12:59:55 -0000 X-IronPort-AV: E=Sophos;i="4.68,417,1312171200"; d="scan'208";a="17568589" Received: from ftlpmailmx02.citrite.net ([10.13.107.66]) by FTLPIPO01.CITRIX.COM with ESMTP/TLS/RC4-MD5; 21 Sep 2011 09:00:30 -0400 Received: from smtp01.ad.xensource.com (10.219.128.104) by smtprelay.citrix.com (10.13.107.66) with Microsoft SMTP Server id 8.3.137.0; Wed, 21 Sep 2011 09:00:30 -0400 Received: from perard.uk.xensource.com (dhcp-3-28.uk.xensource.com [10.80.3.28] (may be forged)) by smtp01.ad.xensource.com (8.13.1/8.13.1) with ESMTP id p8LD0PSH024347; Wed, 21 Sep 2011 06:00:29 -0700 From: Anthony PERARD <anthony.perard@citrix.com> To: Xen Devel <xen-devel@lists.xensource.com> Date: Wed, 21 Sep 2011 13:59:53 +0100 Message-ID: <1316609997-26002-4-git-send-email-anthony.perard@citrix.com> X-Mailer: git-send-email 1.7.2.5 In-Reply-To: <1316609997-26002-1-git-send-email-anthony.perard@citrix.com> References: <1316609997-26002-1-git-send-email-anthony.perard@citrix.com> MIME-Version: 1.0 Content-Type: text/plain Cc: Ian Campbell <Ian.Campbell@eu.citrix.com>, Anthony PERARD <anthony.perard@citrix.com>, Stefano Stabellini <stefano.stabellini@eu.citrix.com> Subject: [Xen-devel] [PATCH RESEND V8 3/7] libxl: Introduce libxl_internal_types.idl. X-BeenThere: xen-devel@lists.xensource.com X-Mailman-Version: 2.1.5 Precedence: list List-Id: Xen developer discussion <xen-devel.lists.xensource.com> List-Unsubscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe> List-Post: <mailto:xen-devel@lists.xensource.com> List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help> List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=subscribe> Sender: xen-devel-bounces@lists.xensource.com Errors-To: xen-devel-bounces@lists.xensource.com Signed-off-by: Anthony PERARD <anthony.perard@citrix.com> --- tools/libxl/Makefile | 4 +++- tools/libxl/gentypes.py | 9 +++++---- tools/libxl/libxl_internal.h | 1 + tools/libxl/libxl_types_internal.idl | 9 +++++++++ 4 files changed, 18 insertions(+), 5 deletions(-) create mode 100644 tools/libxl/libxl_types_internal.idl diff --git a/tools/libxl/Makefile b/tools/libxl/Makefile index 330ee6e..1f6b418 100644 --- a/tools/libxl/Makefile +++ b/tools/libxl/Makefile @@ -35,7 +35,7 @@ LIBXL_OBJS-$(CONFIG_IA64) += libxl_nocpuid.o LIBXL_OBJS = flexarray.o libxl.o libxl_create.o libxl_dm.o libxl_pci.o \ libxl_dom.o libxl_exec.o libxl_xshelp.o libxl_device.o \ libxl_internal.o libxl_utils.o libxl_uuid.o $(LIBXL_OBJS-y) -LIBXL_OBJS += _libxl_types.o libxl_flask.o +LIBXL_OBJS += _libxl_types.o libxl_flask.o _libxl_types_internal.o $(LIBXL_OBJS): CFLAGS += $(CFLAGS_libxenctrl) $(CFLAGS_libxenguest) $(CFLAGS_libxenstore) $(CFLAGS_libblktapctl) @@ -81,8 +81,10 @@ _libxl_paths.h: genpath libxl_paths.c: _libxl_paths.h libxl.h: _libxl_types.h +libxl_internal.h: _libxl_types_internal.h $(LIBXL_OBJS) $(LIBXLU_OBJS) $(XL_OBJS): libxl.h +$(LIBXL_OBJS): libxl_internal.h _libxl_type%.h _libxl_type%.c: libxl_type%.idl gentypes.py libxltypes.py $(PYTHON) gentypes.py libxl_type$*.idl __libxl_type$*.h __libxl_type$*.c diff --git a/tools/libxl/gentypes.py b/tools/libxl/gentypes.py index c66a33c..ecf5f15 100644 --- a/tools/libxl/gentypes.py +++ b/tools/libxl/gentypes.py @@ -150,8 +150,9 @@ if __name__ == '__main__': f = open(header, "w") - f.write("""#ifndef __LIBXL_TYPES_H -#define __LIBXL_TYPES_H + header_define = header.upper().replace('.','_') + f.write("""#ifndef %s +#define %s /* * DO NOT EDIT. @@ -160,7 +161,7 @@ if __name__ == '__main__': * "%s" */ -""" % " ".join(sys.argv)) +""" % (header_define, header_define, " ".join(sys.argv))) for ty in types: f.write(libxl_C_type_define(ty) + ";\n") @@ -172,7 +173,7 @@ if __name__ == '__main__': f.write("extern libxl_enum_string_table %s_string_table[];\n" % (ty.typename)) f.write("\n") - f.write("""#endif /* __LIBXL_TYPES_H */\n""") + f.write("""#endif /* %s */\n""" % (header_define)) f.close() print "outputting libxl type implementations to %s" % impl diff --git a/tools/libxl/libxl_internal.h b/tools/libxl/libxl_internal.h index b73b6c4..739e45e 100644 --- a/tools/libxl/libxl_internal.h +++ b/tools/libxl/libxl_internal.h @@ -35,6 +35,7 @@ #include "flexarray.h" #include "libxl_utils.h" +#include "_libxl_types_internal.h" #define LIBXL_DESTROY_TIMEOUT 10 #define LIBXL_DEVICE_MODEL_START_TIMEOUT 10 diff --git a/tools/libxl/libxl_types_internal.idl b/tools/libxl/libxl_types_internal.idl new file mode 100644 index 0000000..20236a6 --- /dev/null +++ b/tools/libxl/libxl_types_internal.idl @@ -0,0 +1,9 @@ +namespace("libxl__") + +libxl__qmp_message_type = Enumeration("qmp_message_type", [ + (1, "QMP"), + (2, "return"), + (3, "error"), + (4, "event"), + (5, "invalid"), + ]) -- Anthony PERARD _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel From xen-devel-bounces@lists.xensource.com Wed Sep 21 06:06:28 2011 Return-path: <xen-devel-bounces@lists.xensource.com> Envelope-to: www-data@lists.xensource.com Delivery-date: Wed, 21 Sep 2011 06:06:28 -0700 Received: from localhost ([127.0.0.1] helo=lists.colo.xensource.com) by lists.xensource.com with esmtp (Exim 4.43) id 1R6MVQ-0005z2-FF; Wed, 21 Sep 2011 06:06:28 -0700 Received: from mail27.messagelabs.com ([193.109.254.147]) by lists.xensource.com with esmtp (Exim 4.43) id 1R6MPh-0004dH-H3 for xen-devel@lists.xensource.com; Wed, 21 Sep 2011 06:00:39 -0700 X-Env-Sender: anthony.perard@citrix.com X-Msg-Ref: server-7.tower-27.messagelabs.com!1316610004!49569723!2 X-Originating-IP: [66.165.176.63] X-StarScan-Version: 6.4.1; banners=-,-,- X-VirusChecked: Checked Received: (qmail 22758 invoked from network); 21 Sep 2011 13:00:07 -0000 Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63) by server-7.tower-27.messagelabs.com with RC4-SHA encrypted SMTP; 21 Sep 2011 13:00:07 -0000 X-IronPort-AV: E=Sophos;i="4.68,417,1312171200"; d="scan'208";a="164115880" Received: from ftlpmailmx02.citrite.net ([10.13.107.66]) by FTLPIPO02.CITRIX.COM with ESMTP/TLS/RC4-MD5; 21 Sep 2011 09:00:29 -0400 Received: from smtp01.ad.xensource.com (10.219.128.104) by smtprelay.citrix.com (10.13.107.66) with Microsoft SMTP Server id 8.3.137.0; Wed, 21 Sep 2011 09:00:29 -0400 Received: from perard.uk.xensource.com (dhcp-3-28.uk.xensource.com [10.80.3.28] (may be forged)) by smtp01.ad.xensource.com (8.13.1/8.13.1) with ESMTP id p8LD0PSG024347; Wed, 21 Sep 2011 06:00:28 -0700 From: Anthony PERARD <anthony.perard@citrix.com> To: Xen Devel <xen-devel@lists.xensource.com> Date: Wed, 21 Sep 2011 13:59:52 +0100 Message-ID: <1316609997-26002-3-git-send-email-anthony.perard@citrix.com> X-Mailer: git-send-email 1.7.2.5 In-Reply-To: <1316609997-26002-1-git-send-email-anthony.perard@citrix.com> References: <1316609997-26002-1-git-send-email-anthony.perard@citrix.com> MIME-Version: 1.0 Content-Type: text/plain Cc: Ian Campbell <Ian.Campbell@eu.citrix.com>, Anthony PERARD <anthony.perard@citrix.com>, Stefano Stabellini <stefano.stabellini@eu.citrix.com> Subject: [Xen-devel] [PATCH RESEND V8 2/7] libxl: Add get/set_default_namespace in libxltypes.py. X-BeenThere: xen-devel@lists.xensource.com X-Mailman-Version: 2.1.5 Precedence: list List-Id: Xen developer discussion <xen-devel.lists.xensource.com> List-Unsubscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe> List-Post: <mailto:xen-devel@lists.xensource.com> List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help> List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=subscribe> Sender: xen-devel-bounces@lists.xensource.com Errors-To: xen-devel-bounces@lists.xensource.com Signed-off-by: Anthony PERARD <anthony.perard@citrix.com> --- tools/libxl/libxl_types.idl | 2 ++ tools/libxl/libxltypes.py | 18 ++++++++++++++++-- 2 files changed, 18 insertions(+), 2 deletions(-) diff --git a/tools/libxl/libxl_types.idl b/tools/libxl/libxl_types.idl index 5b7e731..0d28283 100644 --- a/tools/libxl/libxl_types.idl +++ b/tools/libxl/libxl_types.idl @@ -3,6 +3,8 @@ # Builtin libxl types # +namespace("libxl_") + libxl_domid = Builtin("domid") libxl_uuid = Builtin("uuid", passby=PASS_BY_REFERENCE) libxl_mac = Builtin("mac", passby=PASS_BY_REFERENCE) diff --git a/tools/libxl/libxltypes.py b/tools/libxl/libxltypes.py index f1a4dcf..86ab4b9 100644 --- a/tools/libxl/libxltypes.py +++ b/tools/libxl/libxltypes.py @@ -8,10 +8,23 @@ DIR_IN = 1 DIR_OUT = 2 DIR_BOTH = 3 +_default_namespace = "" +def namespace(s): + if type(s) != str: + raise TypeError, "Require a string for the default namespace." + global _default_namespace + _default_namespace = s + +def _get_default_namespace(): + global _default_namespace + return _default_namespace + + class Type(object): def __init__(self, typename, **kwargs): self.comment = kwargs.setdefault('comment', None) - self.namespace = kwargs.setdefault('namespace', "libxl_") + self.namespace = kwargs.setdefault('namespace', + _get_default_namespace()) self.dir = kwargs.setdefault('dir', DIR_BOTH) if self.dir not in [DIR_NONE, DIR_IN, DIR_OUT, DIR_BOTH]: raise ValueError @@ -256,7 +269,8 @@ def parse(f): elif isinstance(t,type(object)) and issubclass(t, Type): globs[n] = t elif n in ['PASS_BY_REFERENCE', 'PASS_BY_VALUE', - 'DIR_NONE', 'DIR_IN', 'DIR_OUT', 'DIR_BOTH']: + 'DIR_NONE', 'DIR_IN', 'DIR_OUT', 'DIR_BOTH', + 'namespace']: globs[n] = t try: -- Anthony PERARD _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel From xen-devel-bounces@lists.xensource.com Wed Sep 21 06:07:17 2011 Return-path: <xen-devel-bounces@lists.xensource.com> Envelope-to: www-data@lists.xensource.com Delivery-date: Wed, 21 Sep 2011 06:07:17 -0700 Received: from localhost ([127.0.0.1] helo=lists.colo.xensource.com) by lists.xensource.com with esmtp (Exim 4.43) id 1R6MWD-0006Lv-8V; Wed, 21 Sep 2011 06:07:17 -0700 Received: from mail27.messagelabs.com ([193.109.254.147]) by lists.xensource.com with esmtp (Exim 4.43) id 1R6MPk-0004dM-LN for xen-devel@lists.xensource.com; Wed, 21 Sep 2011 06:00:39 -0700 X-Env-Sender: anthony.perard@citrix.com X-Msg-Ref: server-7.tower-27.messagelabs.com!1316610004!49569723!3 X-Originating-IP: [66.165.176.63] X-StarScan-Version: 6.4.1; banners=-,-,- X-VirusChecked: Checked Received: (qmail 23105 invoked from network); 21 Sep 2011 13:00:10 -0000 Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63) by server-7.tower-27.messagelabs.com with RC4-SHA encrypted SMTP; 21 Sep 2011 13:00:10 -0000 X-IronPort-AV: E=Sophos;i="4.68,417,1312171200"; d="scan'208";a="164115887" Received: from ftlpmailmx02.citrite.net ([10.13.107.66]) by FTLPIPO02.CITRIX.COM with ESMTP/TLS/RC4-MD5; 21 Sep 2011 09:00:33 -0400 Received: from smtp01.ad.xensource.com (10.219.128.104) by smtprelay.citrix.com (10.13.107.66) with Microsoft SMTP Server id 8.3.137.0; Wed, 21 Sep 2011 09:00:33 -0400 Received: from perard.uk.xensource.com (dhcp-3-28.uk.xensource.com [10.80.3.28] (may be forged)) by smtp01.ad.xensource.com (8.13.1/8.13.1) with ESMTP id p8LD0PSJ024347; Wed, 21 Sep 2011 06:00:31 -0700 From: Anthony PERARD <anthony.perard@citrix.com> To: Xen Devel <xen-devel@lists.xensource.com> Date: Wed, 21 Sep 2011 13:59:55 +0100 Message-ID: <1316609997-26002-6-git-send-email-anthony.perard@citrix.com> X-Mailer: git-send-email 1.7.2.5 In-Reply-To: <1316609997-26002-1-git-send-email-anthony.perard@citrix.com> References: <1316609997-26002-1-git-send-email-anthony.perard@citrix.com> MIME-Version: 1.0 Content-Type: text/plain Cc: Ian Campbell <Ian.Campbell@eu.citrix.com>, Anthony PERARD <anthony.perard@citrix.com>, Stefano Stabellini <stefano.stabellini@eu.citrix.com> Subject: [Xen-devel] [PATCH RESEND V8 5/7] libxl: Intruduce libxl__strndup. X-BeenThere: xen-devel@lists.xensource.com X-Mailman-Version: 2.1.5 Precedence: list List-Id: Xen developer discussion <xen-devel.lists.xensource.com> List-Unsubscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe> List-Post: <mailto:xen-devel@lists.xensource.com> List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help> List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=subscribe> Sender: xen-devel-bounces@lists.xensource.com Errors-To: xen-devel-bounces@lists.xensource.com Signed-off-by: Anthony PERARD <anthony.perard@citrix.com> --- tools/libxl/libxl_internal.c | 10 ++++++++++ tools/libxl/libxl_internal.h | 1 + 2 files changed, 11 insertions(+), 0 deletions(-) diff --git a/tools/libxl/libxl_internal.c b/tools/libxl/libxl_internal.c index c4d54f9..0fb2315 100644 --- a/tools/libxl/libxl_internal.c +++ b/tools/libxl/libxl_internal.c @@ -159,6 +159,16 @@ char *libxl__strdup(libxl__gc *gc, const char *c) return s; } +char *libxl__strndup(libxl__gc *gc, const char *c, size_t n) +{ + char *s = strndup(c, n); + + if (s) + libxl__ptr_add(gc, s); + + return s; +} + char *libxl__dirname(libxl__gc *gc, const char *s) { char *c; diff --git a/tools/libxl/libxl_internal.h b/tools/libxl/libxl_internal.h index 5d270bb..d873243 100644 --- a/tools/libxl/libxl_internal.h +++ b/tools/libxl/libxl_internal.h @@ -148,6 +148,7 @@ _hidden void *libxl__calloc(libxl__gc *gc, size_t nmemb, size_t size); _hidden void *libxl__realloc(libxl__gc *gc, void *ptr, size_t new_size); _hidden char *libxl__sprintf(libxl__gc *gc, const char *fmt, ...) PRINTF_ATTRIBUTE(2, 3); _hidden char *libxl__strdup(libxl__gc *gc, const char *c); +_hidden char *libxl__strndup(libxl__gc *gc, const char *c, size_t n); _hidden char *libxl__dirname(libxl__gc *gc, const char *s); _hidden char **libxl__xs_kvs_of_flexarray(libxl__gc *gc, flexarray_t *array, int length); -- Anthony PERARD _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel From xen-devel-bounces@lists.xensource.com Wed Sep 21 06:08:15 2011 Return-path: <xen-devel-bounces@lists.xensource.com> Envelope-to: www-data@lists.xensource.com Delivery-date: Wed, 21 Sep 2011 06:08:15 -0700 Received: from localhost ([127.0.0.1] helo=lists.colo.xensource.com) by lists.xensource.com with esmtp (Exim 4.43) id 1R6MX9-0006if-Dg; Wed, 21 Sep 2011 06:08:15 -0700 Received: from mail21.messagelabs.com ([85.158.143.35]) by lists.xensource.com with esmtp (Exim 4.43) id 1R6MPh-0004dG-3i for xen-devel@lists.xensource.com; Wed, 21 Sep 2011 06:00:39 -0700 X-Env-Sender: anthony.perard@citrix.com X-Msg-Ref: server-4.tower-21.messagelabs.com!1316609993!61062359!1 X-Originating-IP: [66.165.176.89] X-StarScan-Version: 6.4.1; banners=-,-,- X-VirusChecked: Checked Received: (qmail 10450 invoked from network); 21 Sep 2011 12:59:54 -0000 Received: from smtp.citrix.com (HELO SMTP.CITRIX.COM) (66.165.176.89) by server-4.tower-21.messagelabs.com with RC4-SHA encrypted SMTP; 21 Sep 2011 12:59:54 -0000 X-IronPort-AV: E=Sophos;i="4.68,417,1312171200"; d="scan'208";a="17568588" Received: from ftlpmailmx02.citrite.net ([10.13.107.66]) by FTLPIPO01.CITRIX.COM with ESMTP/TLS/RC4-MD5; 21 Sep 2011 09:00:28 -0400 Received: from smtp01.ad.xensource.com (10.219.128.104) by smtprelay.citrix.com (10.13.107.66) with Microsoft SMTP Server id 8.3.137.0; Wed, 21 Sep 2011 09:00:28 -0400 Received: from perard.uk.xensource.com (dhcp-3-28.uk.xensource.com [10.80.3.28] (may be forged)) by smtp01.ad.xensource.com (8.13.1/8.13.1) with ESMTP id p8LD0PSF024347; Wed, 21 Sep 2011 06:00:27 -0700 From: Anthony PERARD <anthony.perard@citrix.com> To: Xen Devel <xen-devel@lists.xensource.com> Date: Wed, 21 Sep 2011 13:59:51 +0100 Message-ID: <1316609997-26002-2-git-send-email-anthony.perard@citrix.com> X-Mailer: git-send-email 1.7.2.5 In-Reply-To: <1316609997-26002-1-git-send-email-anthony.perard@citrix.com> References: <1316609997-26002-1-git-send-email-anthony.perard@citrix.com> MIME-Version: 1.0 Content-Type: text/plain Cc: Ian Campbell <Ian.Campbell@eu.citrix.com>, Anthony PERARD <anthony.perard@citrix.com>, Stefano Stabellini <stefano.stabellini@eu.citrix.com> Subject: [Xen-devel] [PATCH RESEND V8 1/7] libxl: Rename libxl.idl to libxl_types.idl. X-BeenThere: xen-devel@lists.xensource.com X-Mailman-Version: 2.1.5 Precedence: list List-Id: Xen developer discussion <xen-devel.lists.xensource.com> List-Unsubscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe> List-Post: <mailto:xen-devel@lists.xensource.com> List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help> List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=subscribe> Sender: xen-devel-bounces@lists.xensource.com Errors-To: xen-devel-bounces@lists.xensource.com Signed-off-by: Anthony PERARD <anthony.perard@citrix.com> --- tools/libxl/Makefile | 12 ++++++------ tools/libxl/{libxl.idl => libxl_types.idl} | 0 tools/ocaml/libs/xl/Makefile | 4 ++-- tools/python/Makefile | 4 ++-- 4 files changed, 10 insertions(+), 10 deletions(-) rename tools/libxl/{libxl.idl => libxl_types.idl} (100%) diff --git a/tools/libxl/Makefile b/tools/libxl/Makefile index 3eeb26f..330ee6e 100644 --- a/tools/libxl/Makefile +++ b/tools/libxl/Makefile @@ -52,8 +52,8 @@ $(XL_OBJS): CFLAGS += $(CFLAGS_libxenctrl) # For xentoollog.h $(XL_OBJS): CFLAGS += $(CFLAGS_libxenlight) testidl.o: CFLAGS += $(CFLAGS_libxenctrl) $(CFLAGS_libxenlight) -testidl.c: libxl.idl gentest.py libxl.h - $(PYTHON) gentest.py libxl.idl testidl.c.new +testidl.c: libxl_types.idl gentest.py libxl.h + $(PYTHON) gentest.py libxl_types.idl testidl.c.new mv testidl.c.new testidl.c .PHONY: all @@ -84,10 +84,10 @@ libxl.h: _libxl_types.h $(LIBXL_OBJS) $(LIBXLU_OBJS) $(XL_OBJS): libxl.h -_libxl_%.h _libxl_%.c: libxl.idl gen%.py libxl%.py - $(PYTHON) gen$*.py libxl.idl __libxl_$*.h __libxl_$*.c - $(call move-if-changed,__libxl_$*.h,_libxl_$*.h) - $(call move-if-changed,__libxl_$*.c,_libxl_$*.c) +_libxl_type%.h _libxl_type%.c: libxl_type%.idl gentypes.py libxltypes.py + $(PYTHON) gentypes.py libxl_type$*.idl __libxl_type$*.h __libxl_type$*.c + $(call move-if-changed,__libxl_type$*.h,_libxl_type$*.h) + $(call move-if-changed,__libxl_type$*.c,_libxl_type$*.c) libxenlight.so: libxenlight.so.$(MAJOR) ln -sf $< $@ diff --git a/tools/libxl/libxl.idl b/tools/libxl/libxl_types.idl similarity index 100% rename from tools/libxl/libxl.idl rename to tools/libxl/libxl_types.idl diff --git a/tools/ocaml/libs/xl/Makefile b/tools/ocaml/libs/xl/Makefile index 342dc35..a1e79a5 100644 --- a/tools/ocaml/libs/xl/Makefile +++ b/tools/ocaml/libs/xl/Makefile @@ -45,10 +45,10 @@ xl.mli: xl.mli.in _libxl_types.mli.in < xl.mli.in > xl.mli.tmp $(Q)mv xl.mli.tmp xl.mli -_libxl_types.ml.in _libxl_types.mli.in _libxl_types.inc: genwrap.py $(XEN_ROOT)/tools/libxl/libxl.idl \ +_libxl_types.ml.in _libxl_types.mli.in _libxl_types.inc: genwrap.py $(XEN_ROOT)/tools/libxl/libxl_types.idl \ $(XEN_ROOT)/tools/libxl/libxltypes.py PYTHONPATH=$(XEN_ROOT)/tools/libxl $(PYTHON) genwrap.py \ - $(XEN_ROOT)/tools/libxl/libxl.idl \ + $(XEN_ROOT)/tools/libxl/libxl_types.idl \ _libxl_types.mli.in _libxl_types.ml.in _libxl_types.inc libs: $(LIBS) diff --git a/tools/python/Makefile b/tools/python/Makefile index de44178..b7bc501 100644 --- a/tools/python/Makefile +++ b/tools/python/Makefile @@ -10,10 +10,10 @@ genpath-target = $(call buildmakevars2file,$(XENPATH)) $(eval $(genpath-target)) .PHONY: build -build: genpath genwrap.py $(XEN_ROOT)/tools/libxl/libxl.idl \ +build: genpath genwrap.py $(XEN_ROOT)/tools/libxl/libxl_types.idl \ $(XEN_ROOT)/tools/libxl/libxltypes.py PYTHONPATH=$(XEN_ROOT)/tools/libxl $(PYTHON) genwrap.py \ - $(XEN_ROOT)/tools/libxl/libxl.idl \ + $(XEN_ROOT)/tools/libxl/libxl_types.idl \ xen/lowlevel/xl/_pyxl_types.h \ xen/lowlevel/xl/_pyxl_types.c CC="$(CC)" CFLAGS="$(CFLAGS)" $(PYTHON) setup.py build -- Anthony PERARD _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel From xen-devel-bounces@lists.xensource.com Wed Sep 21 06:09:05 2011 Return-path: <xen-devel-bounces@lists.xensource.com> Envelope-to: www-data@lists.xensource.com Delivery-date: Wed, 21 Sep 2011 06:09:05 -0700 Received: from localhost ([127.0.0.1] helo=lists.colo.xensource.com) by lists.xensource.com with esmtp (Exim 4.43) id 1R6MXx-00075d-57; Wed, 21 Sep 2011 06:09:05 -0700 Received: from mail27.messagelabs.com ([193.109.254.147]) by lists.xensource.com with esmtp (Exim 4.43) id 1R6MPn-0004dR-HX for xen-devel@lists.xensource.com; Wed, 21 Sep 2011 06:00:43 -0700 X-Env-Sender: anthony.perard@citrix.com X-Msg-Ref: server-7.tower-27.messagelabs.com!1316610004!49569723!4 X-Originating-IP: [66.165.176.63] X-StarScan-Version: 6.4.1; banners=-,-,- X-VirusChecked: Checked Received: (qmail 23277 invoked from network); 21 Sep 2011 13:00:13 -0000 Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63) by server-7.tower-27.messagelabs.com with RC4-SHA encrypted SMTP; 21 Sep 2011 13:00:13 -0000 X-IronPort-AV: E=Sophos;i="4.68,417,1312171200"; d="scan'208";a="164115892" Received: from ftlpmailmx02.citrite.net ([10.13.107.66]) by FTLPIPO02.CITRIX.COM with ESMTP/TLS/RC4-MD5; 21 Sep 2011 09:00:35 -0400 Received: from smtp01.ad.xensource.com (10.219.128.104) by smtprelay.citrix.com (10.13.107.66) with Microsoft SMTP Server id 8.3.137.0; Wed, 21 Sep 2011 09:00:35 -0400 Received: from perard.uk.xensource.com (dhcp-3-28.uk.xensource.com [10.80.3.28] (may be forged)) by smtp01.ad.xensource.com (8.13.1/8.13.1) with ESMTP id p8LD0PSL024347; Wed, 21 Sep 2011 06:00:34 -0700 From: Anthony PERARD <anthony.perard@citrix.com> To: Xen Devel <xen-devel@lists.xensource.com> Date: Wed, 21 Sep 2011 13:59:57 +0100 Message-ID: <1316609997-26002-8-git-send-email-anthony.perard@citrix.com> X-Mailer: git-send-email 1.7.2.5 In-Reply-To: <1316609997-26002-1-git-send-email-anthony.perard@citrix.com> References: <1316609997-26002-1-git-send-email-anthony.perard@citrix.com> MIME-Version: 1.0 Content-Type: text/plain Cc: Ian Campbell <Ian.Campbell@eu.citrix.com>, Anthony PERARD <anthony.perard@citrix.com>, Stefano Stabellini <stefano.stabellini@eu.citrix.com> Subject: [Xen-devel] [PATCH RESEND V8 7/7] libxl: Introduce a QMP client X-BeenThere: xen-devel@lists.xensource.com X-Mailman-Version: 2.1.5 Precedence: list List-Id: Xen developer discussion <xen-devel.lists.xensource.com> List-Unsubscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe> List-Post: <mailto:xen-devel@lists.xensource.com> List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help> List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=subscribe> Sender: xen-devel-bounces@lists.xensource.com Errors-To: xen-devel-bounces@lists.xensource.com QMP stands for QEMU Monitor Protocol and it is used to query information from QEMU or to control QEMU. This implementation will ask QEMU the list of chardevice and store the path to serial ports in xenstored. So we will be able to use xl console with QEMU upstream. In order to connect to the QMP server, a socket file is created in /var/run/xen/qmp-libxl-$(domid). Signed-off-by: Anthony PERARD <anthony.perard@citrix.com> --- tools/libxl/Makefile | 2 +- tools/libxl/libxl.c | 2 + tools/libxl/libxl_create.c | 4 + tools/libxl/libxl_dm.c | 10 + tools/libxl/libxl_internal.h | 19 ++ tools/libxl/libxl_qmp.c | 587 ++++++++++++++++++++++++++++++++++++++++++ 6 files changed, 623 insertions(+), 1 deletions(-) create mode 100644 tools/libxl/libxl_qmp.c diff --git a/tools/libxl/Makefile b/tools/libxl/Makefile index e50874e..f10c7e8 100644 --- a/tools/libxl/Makefile +++ b/tools/libxl/Makefile @@ -37,7 +37,7 @@ LIBXL_LIBS += -lyajl LIBXL_OBJS = flexarray.o libxl.o libxl_create.o libxl_dm.o libxl_pci.o \ libxl_dom.o libxl_exec.o libxl_xshelp.o libxl_device.o \ libxl_internal.o libxl_utils.o libxl_uuid.o libxl_json.o \ - $(LIBXL_OBJS-y) + libxl_qmp.o $(LIBXL_OBJS-y) LIBXL_OBJS += _libxl_types.o libxl_flask.o _libxl_types_internal.o $(LIBXL_OBJS): CFLAGS += $(CFLAGS_libxenctrl) $(CFLAGS_libxenguest) $(CFLAGS_libxenstore) $(CFLAGS_libblktapctl) diff --git a/tools/libxl/libxl.c b/tools/libxl/libxl.c index 426058f..fbd522d 100644 --- a/tools/libxl/libxl.c +++ b/tools/libxl/libxl.c @@ -762,6 +762,8 @@ int libxl_domain_destroy(libxl_ctx *ctx, uint32_t domid, int force) if (dm_present) { if (libxl__destroy_device_model(&gc, domid) < 0) LIBXL__LOG(ctx, LIBXL__LOG_ERROR, "libxl__destroy_device_model failed for %d", domid); + + libxl__qmp_cleanup(&gc, domid); } if (libxl__devices_destroy(&gc, domid, force) < 0) LIBXL__LOG(ctx, LIBXL__LOG_ERROR, "libxl_destroy_devices failed for %d", domid); diff --git a/tools/libxl/libxl_create.c b/tools/libxl/libxl_create.c index ce76729..c97819a 100644 --- a/tools/libxl/libxl_create.c +++ b/tools/libxl/libxl_create.c @@ -573,6 +573,10 @@ static int do_domain_create(libxl__gc *gc, libxl_domain_config *d_config, } if (dm_starting) { + if (dm_info->device_model_version + == LIBXL_DEVICE_MODEL_VERSION_QEMU_XEN) { + libxl__qmp_initializations(ctx, domid); + } ret = libxl__confirm_device_model_startup(gc, dm_starting); if (ret < 0) { LIBXL__LOG(ctx, LIBXL__LOG_ERROR, diff --git a/tools/libxl/libxl_dm.c b/tools/libxl/libxl_dm.c index e854a50..ef09079 100644 --- a/tools/libxl/libxl_dm.c +++ b/tools/libxl/libxl_dm.c @@ -248,6 +248,16 @@ static char ** libxl__build_device_model_args_new(libxl__gc *gc, flexarray_vappend(dm_args, dm, "-xen-domid", libxl__sprintf(gc, "%d", info->domid), NULL); + flexarray_append(dm_args, "-chardev"); + flexarray_append(dm_args, + libxl__sprintf(gc, "socket,id=libxl-cmd," + "path=%s/qmp-libxl-%d,server,nowait", + libxl_run_dir_path(), + info->domid)); + + flexarray_append(dm_args, "-mon"); + flexarray_append(dm_args, "chardev=libxl-cmd,mode=control"); + if (info->type == LIBXL_DOMAIN_TYPE_PV) { flexarray_append(dm_args, "-xen-attach"); } diff --git a/tools/libxl/libxl_internal.h b/tools/libxl/libxl_internal.h index f495e86..2ea1582 100644 --- a/tools/libxl/libxl_internal.h +++ b/tools/libxl/libxl_internal.h @@ -387,6 +387,25 @@ _hidden int libxl__e820_alloc(libxl_ctx *ctx, uint32_t domid, libxl_domain_confi #define STRINGIFY(x) #x #define TOSTRING(x) STRINGIFY(x) +/* from libxl_qmp */ +typedef struct libxl__qmp_handler libxl__qmp_handler; + +/* Initialise and connect to the QMP socket. + * Return an handler or NULL if there is an error + */ +_hidden libxl__qmp_handler *libxl__qmp_initialize(libxl_ctx *ctx, + uint32_t domid); +/* ask to QEMU the serial port information and store it in xenstore. */ +_hidden int libxl__qmp_query_serial(libxl__qmp_handler *qmp); +/* close and free the QMP handler */ +_hidden void libxl__qmp_close(libxl__qmp_handler *qmp); +/* remove the socket file, if the file has already been removed, + * nothing happen */ +_hidden void libxl__qmp_cleanup(libxl__gc *gc, uint32_t domid); + +/* this helper calls qmp_initialize, query_serial and qmp_close */ +_hidden int libxl__qmp_initializations(libxl_ctx *ctx, uint32_t domid); + /* from libxl_json */ #include <yajl/yajl_gen.h> diff --git a/tools/libxl/libxl_qmp.c b/tools/libxl/libxl_qmp.c new file mode 100644 index 0000000..6e8ecea --- /dev/null +++ b/tools/libxl/libxl_qmp.c @@ -0,0 +1,587 @@ +/* + * Copyright (C) 2011 Citrix Ltd. + * Author Anthony PERARD <anthony.perard@citrix.com> + * + * This program is free software; you can redistribute it and/or modify + * it under the terms of the GNU Lesser General Public License as published + * by the Free Software Foundation; version 2.1 only. with the special + * exception on linking described in file LICENSE. + * + * This program is distributed in the hope that it will be useful, + * but WITHOUT ANY WARRANTY; without even the implied warranty of + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the + * GNU Lesser General Public License for more details. + */ + +/* + * This file implement a client for QMP (QEMU Monitor Protocol). For the + * Specification, see in the QEMU repository. + */ + +#include <unistd.h> +#include <sys/un.h> +#include <sys/queue.h> + +#include <yajl/yajl_gen.h> + +#include "libxl_internal.h" + +/* #define DEBUG_RECEIVED */ + +#ifdef DEBUG_RECEIVED +# define DEBUG_REPORT_RECEIVED(buf, len) \ + LIBXL__LOG(qmp->ctx, LIBXL__LOG_DEBUG, "received: '%.*s'", len, buf) +#else +# define DEBUG_REPORT_RECEIVED(buf, len) ((void)0) +#endif + +/* + * QMP types & constant + */ + +#define QMP_RECEIVE_BUFFER_SIZE 4096 + +typedef int (*qmp_callback_t)(libxl__qmp_handler *qmp, + const libxl__json_object *tree); + +typedef struct callback_id_pair { + int id; + qmp_callback_t callback; + SIMPLEQ_ENTRY(callback_id_pair) next; +} callback_id_pair; + +struct libxl__qmp_handler { + struct sockaddr_un addr; + int qmp_fd; + bool connected; + time_t timeout; + /* wait_for_id will be used by the synchronous send function */ + int wait_for_id; + + char buffer[QMP_RECEIVE_BUFFER_SIZE]; + libxl__yajl_ctx *yajl_ctx; + + libxl_ctx *ctx; + uint32_t domid; + + int last_id_used; + SIMPLEQ_HEAD(callback_list, callback_id_pair) callback_list; +}; + +static int qmp_send(libxl__qmp_handler *qmp, + const char *cmd, qmp_callback_t callback); + +static const int QMP_SOCKET_CONNECT_TIMEOUT = 5; + +/* + * QMP callbacks functions + */ + +static int store_serial_port_info(libxl__qmp_handler *qmp, + const char *chardev, + int port) +{ + libxl__gc gc = LIBXL_INIT_GC(qmp->ctx); + char *path = NULL; + int ret = 0; + + if (!(chardev && strncmp("pty:", chardev, 4) == 0)) { + return -1; + } + + path = libxl__xs_get_dompath(&gc, qmp->domid); + path = libxl__sprintf(&gc, "%s/serial/%d/tty", path, port); + + ret = libxl__xs_write(&gc, XBT_NULL, path, "%s", chardev + 4); + + libxl__free_all(&gc); + return ret; +} + +static int register_serials_chardev_callback(libxl__qmp_handler *qmp, + const libxl__json_object *o) +{ + const libxl__json_object *obj = NULL; + const libxl__json_object *label = NULL; + const char *s = NULL; + int i = 0; + const char *chardev = NULL; + int ret = 0; + + for (i = 0; (obj = libxl__json_array_get(o, i)); i++) { + if (!libxl__json_object_is_map(obj)) + continue; + label = libxl__json_map_get("label", obj, JSON_STRING); + s = libxl__json_object_get_string(label); + + if (s && strncmp("serial", s, strlen("serial")) == 0) { + const libxl__json_object *filename = NULL; + char *endptr = NULL; + int port_number; + + filename = libxl__json_map_get("filename", obj, JSON_STRING); + chardev = libxl__json_object_get_string(filename); + + s += strlen("serial"); + port_number = strtol(s, &endptr, 10); + if (*s == 0 || *endptr != 0) { + LIBXL__LOG(qmp->ctx, LIBXL__LOG_ERROR, + "Invalid serial port number: %s", s); + return -1; + } + ret = store_serial_port_info(qmp, chardev, port_number); + if (ret) { + LIBXL__LOG_ERRNO(qmp->ctx, LIBXL__LOG_ERROR, + "Failed to store serial port information" + " in xenstore"); + return ret; + } + } + }; + + return ret; +} + +static int qmp_capabilities_callback(libxl__qmp_handler *qmp, + const libxl__json_object *o) +{ + qmp->connected = true; + + return 0; +} + +/* + * QMP commands + */ + +static int enable_qmp_capabilities(libxl__qmp_handler *qmp) +{ + return qmp_send(qmp, "qmp_capabilities", qmp_capabilities_callback); +} + +/* + * Helpers + */ + +static libxl__qmp_message_type qmp_response_type(libxl__qmp_handler *qmp, + const libxl__json_object *o) +{ + libxl__qmp_message_type type; + libxl__json_map_node *node = NULL; + int i = 0; + + for (i = 0; (node = libxl__json_map_node_get(o, i)); i++) { + if (libxl__qmp_message_type_from_string(node->map_key, &type) == 0) + return type; + } + + return LIBXL__QMP_MESSAGE_TYPE_INVALID; +} + +static callback_id_pair *qmp_get_callback_from_id(libxl__qmp_handler *qmp, + const libxl__json_object *o) +{ + const libxl__json_object *id_object = libxl__json_map_get("id", o, + JSON_INTEGER); + int id = -1; + callback_id_pair *pp = NULL; + + if (id_object) { + id = libxl__json_object_get_integer(id_object); + + SIMPLEQ_FOREACH(pp, &qmp->callback_list, next) { + if (pp->id == id) { + return pp; + } + } + } + return NULL; +} + +static void qmp_handle_error_response(libxl__qmp_handler *qmp, + const libxl__json_object *resp) +{ + callback_id_pair *pp = qmp_get_callback_from_id(qmp, resp); + + resp = libxl__json_map_get("error", resp, JSON_MAP); + resp = libxl__json_map_get("desc", resp, JSON_STRING); + + if (pp) { + pp->callback(qmp, NULL); + if (pp->id == qmp->wait_for_id) { + /* tell that the id have been processed */ + qmp->wait_for_id = 0; + } + SIMPLEQ_REMOVE(&qmp->callback_list, pp, callback_id_pair, next); + free(pp); + } + + LIBXL__LOG(qmp->ctx, LIBXL__LOG_ERROR, + "received an error message from QMP server: %s", + libxl__json_object_get_string(resp)); +} + +static int qmp_handle_response(libxl__qmp_handler *qmp, + const libxl__json_object *resp) +{ + libxl__qmp_message_type type = LIBXL__QMP_MESSAGE_TYPE_INVALID; + + type = qmp_response_type(qmp, resp); + LIBXL__LOG(qmp->ctx, LIBXL__LOG_DEBUG, + "message type: %s", libxl__qmp_message_type_to_string(type)); + + switch (type) { + case LIBXL__QMP_MESSAGE_TYPE_QMP: + /* On the greeting message from the server, enable QMP capabilities */ + enable_qmp_capabilities(qmp); + break; + case LIBXL__QMP_MESSAGE_TYPE_RETURN: { + callback_id_pair *pp = qmp_get_callback_from_id(qmp, resp); + + if (pp) { + pp->callback(qmp, + libxl__json_map_get("return", resp, JSON_ANY)); + if (pp->id == qmp->wait_for_id) { + /* tell that the id have been processed */ + qmp->wait_for_id = 0; + } + SIMPLEQ_REMOVE(&qmp->callback_list, pp, callback_id_pair, next); + free(pp); + } + break; + } + case LIBXL__QMP_MESSAGE_TYPE_ERROR: + qmp_handle_error_response(qmp, resp); + break; + case LIBXL__QMP_MESSAGE_TYPE_EVENT: + break; + case LIBXL__QMP_MESSAGE_TYPE_INVALID: + return -1; + } + return 0; +} + +/* + * Handler functions + */ + +static libxl__qmp_handler *qmp_init_handler(libxl_ctx *ctx, uint32_t domid) +{ + libxl__qmp_handler *qmp = NULL; + + qmp = calloc(1, sizeof (libxl__qmp_handler)); + if (qmp == NULL) { + LIBXL__LOG_ERRNO(ctx, LIBXL__LOG_ERROR, + "Failed to allocate qmp_handler"); + return NULL; + } + qmp->ctx = ctx; + qmp->domid = domid; + qmp->timeout = 5; + + SIMPLEQ_INIT(&qmp->callback_list); + + return qmp; +} + +static int qmp_open(libxl__qmp_handler *qmp, const char *qmp_socket_path, + int timeout) +{ + int ret; + int i = 0; + + qmp->qmp_fd = socket(AF_UNIX, SOCK_STREAM | SOCK_NONBLOCK, 0); + if (qmp->qmp_fd < 0) { + return -1; + } + + memset(&qmp->addr, 0, sizeof (&qmp->addr)); + qmp->addr.sun_family = AF_UNIX; + strncpy(qmp->addr.sun_path, qmp_socket_path, + sizeof (qmp->addr.sun_path)); + + do { + ret = connect(qmp->qmp_fd, (struct sockaddr *) &qmp->addr, + sizeof (qmp->addr)); + if (ret == 0) + break; + if (errno == ENOENT || errno == ECONNREFUSED) { + /* ENOENT : Socket may not have shown up yet + * ECONNREFUSED : Leftover socket hasn't been removed yet */ + continue; + } + return -1; + } while ((++i / 5 <= timeout) && (usleep(200 * 1000) <= 0)); + + return ret; +} + +static void qmp_close(libxl__qmp_handler *qmp) +{ + callback_id_pair *pp = NULL; + callback_id_pair *tmp = NULL; + + close(qmp->qmp_fd); + SIMPLEQ_FOREACH(pp, &qmp->callback_list, next) { + if (tmp) + free(tmp); + tmp = pp; + } + if (tmp) + free(tmp); +} + +static int qmp_next(libxl__gc *gc, libxl__qmp_handler *qmp) +{ + ssize_t rd; + char *s = NULL; + char *s_end = NULL; + + char *incomplete = NULL; + size_t incomplete_size = 0; + + do { + fd_set rfds; + int ret = 0; + struct timeval timeout = { + .tv_sec = qmp->timeout, + .tv_usec = 0, + }; + + FD_ZERO(&rfds); + FD_SET(qmp->qmp_fd, &rfds); + + ret = select(qmp->qmp_fd + 1, &rfds, NULL, NULL, &timeout); + if (ret == 0) { + LIBXL__LOG(qmp->ctx, LIBXL__LOG_ERROR, "timeout"); + return -1; + } else if (ret < 0) { + LIBXL__LOG_ERRNO(qmp->ctx, LIBXL__LOG_ERROR, "Select error"); + return -1; + } + + rd = read(qmp->qmp_fd, qmp->buffer, QMP_RECEIVE_BUFFER_SIZE); + if (rd == 0) { + continue; + } else if (rd < 0) { + LIBXL__LOG_ERRNO(qmp->ctx, LIBXL__LOG_ERROR, "Socket read error"); + return rd; + } + + DEBUG_REPORT_RECEIVED(qmp->buffer, rd); + + do { + char *end = NULL; + if (incomplete) { + size_t current_pos = s - incomplete; + incomplete_size += rd; + incomplete = libxl__realloc(gc, incomplete, + incomplete_size + 1); + incomplete = strncat(incomplete, qmp->buffer, rd); + s = incomplete + current_pos; + s_end = incomplete + incomplete_size; + } else { + incomplete = libxl__strndup(gc, qmp->buffer, rd); + incomplete_size = rd; + s = incomplete; + s_end = s + rd; + } + + end = strstr(s, "\r\n"); + if (end) { + libxl__json_object *o = NULL; + + *end = '\0'; + + o = libxl__json_parse(gc, s); + s = end + 2; + + if (o) { + qmp_handle_response(qmp, o); + libxl__json_object_free(gc, o); + } else { + LIBXL__LOG(qmp->ctx, LIBXL__LOG_ERROR, + "Parse error of : %s\n", s); + return -1; + } + } else { + break; + } + } while (s < s_end); + } while (s < s_end); + + return 1; +} + +static int qmp_send(libxl__qmp_handler *qmp, + const char *cmd, qmp_callback_t callback) +{ + yajl_gen_config conf = { 0, NULL }; + const unsigned char *buf; + unsigned int len = 0; + yajl_gen_status s; + yajl_gen hand; + + hand = yajl_gen_alloc(&conf, NULL); + if (!hand) { + return -1; + } + + yajl_gen_map_open(hand); + libxl__yajl_gen_asciiz(hand, "execute"); + libxl__yajl_gen_asciiz(hand, cmd); + libxl__yajl_gen_asciiz(hand, "id"); + yajl_gen_integer(hand, ++qmp->last_id_used); + yajl_gen_map_close(hand); + + s = yajl_gen_get_buf(hand, &buf, &len); + + if (s) { + LIBXL__LOG(qmp->ctx, LIBXL__LOG_ERROR, + "Failed to generate a qmp command"); + return -1; + } + + if (callback) { + callback_id_pair *elm = malloc(sizeof (callback_id_pair)); + if (elm == NULL) { + LIBXL__LOG_ERRNO(qmp->ctx, LIBXL__LOG_ERROR, + "Failed to allocate a QMP callback"); + yajl_gen_free(hand); + return -1; + } + elm->id = qmp->last_id_used; + elm->callback = callback; + SIMPLEQ_INSERT_TAIL(&qmp->callback_list, elm, next); + } + + LIBXL__LOG(qmp->ctx, LIBXL__LOG_DEBUG, "next qmp command: '%s'", buf); + + if (libxl_write_exactly(qmp->ctx, qmp->qmp_fd, buf, len, + "QMP command", "QMP socket")) + goto error; + if (libxl_write_exactly(qmp->ctx, qmp->qmp_fd, "\r\n", 2, + "CRLF", "QMP socket")) + goto error; + + yajl_gen_free(hand); + + return qmp->last_id_used; + +error: + yajl_gen_free(hand); + return -1; +} + +static int qmp_synchronous_send(libxl__qmp_handler *qmp, const char *cmd, + qmp_callback_t callback, int ask_timeout) +{ + int id = 0; + int ret = 0; + libxl__gc gc = LIBXL_INIT_GC(qmp->ctx); + + id = qmp_send(qmp, cmd, callback); + if (id <= 0) { + return -1; + } + qmp->wait_for_id = id; + + while (qmp->wait_for_id == id) { + if ((ret = qmp_next(&gc, qmp)) < 0) { + return ret; + } + } + + libxl__free_all(&gc); + + return 0; +} + +static void qmp_free_handler(libxl__qmp_handler *qmp) +{ + free(qmp); +} + +/* + * API + */ + +libxl__qmp_handler *libxl__qmp_initialize(libxl_ctx *ctx, uint32_t domid) +{ + int ret = 0; + libxl__qmp_handler *qmp = NULL; + char *qmp_socket; + libxl__gc gc = LIBXL_INIT_GC(ctx); + + qmp = qmp_init_handler(ctx, domid); + + qmp_socket = libxl__sprintf(&gc, "%s/qmp-libxl-%d", + libxl_run_dir_path(), domid); + if ((ret = qmp_open(qmp, qmp_socket, QMP_SOCKET_CONNECT_TIMEOUT)) < 0) { + LIBXL__LOG_ERRNO(ctx, LIBXL__LOG_ERROR, "Connection error"); + libxl__free_all(&gc); + qmp_free_handler(qmp); + return NULL; + } + + LIBXL__LOG(qmp->ctx, LIBXL__LOG_DEBUG, "connected to %s", qmp_socket); + + /* Wait for the response to qmp_capabilities */ + while (!qmp->connected) { + if ((ret = qmp_next(&gc, qmp)) < 0) { + break; + } + } + + libxl__free_all(&gc); + if (!qmp->connected) { + LIBXL__LOG(ctx, LIBXL__LOG_ERROR, "Failed to connect to QMP"); + libxl__qmp_close(qmp); + return NULL; + } + return qmp; +} + +void libxl__qmp_close(libxl__qmp_handler *qmp) +{ + if (!qmp) + return; + qmp_close(qmp); + qmp_free_handler(qmp); +} + +void libxl__qmp_cleanup(libxl__gc *gc, uint32_t domid) +{ + libxl_ctx *ctx = libxl__gc_owner(gc); + char *qmp_socket; + + qmp_socket = libxl__sprintf(gc, "%s/qmp-libxl-%d", + libxl_run_dir_path(), domid); + if (unlink(qmp_socket) == -1) { + if (errno != ENOENT) { + LIBXL__LOG_ERRNO(ctx, LIBXL__LOG_ERROR, + "Failed to remove QMP socket file %s", + qmp_socket); + } + } +} + +int libxl__qmp_query_serial(libxl__qmp_handler *qmp) +{ + return qmp_synchronous_send(qmp, "query-chardev", + register_serials_chardev_callback, + qmp->timeout); +} + +int libxl__qmp_initializations(libxl_ctx *ctx, uint32_t domid) +{ + libxl__qmp_handler *qmp = NULL; + int ret = 0; + + qmp = libxl__qmp_initialize(ctx, domid); + if (!qmp) + return -1; + ret = libxl__qmp_query_serial(qmp); + libxl__qmp_close(qmp); + return ret; +} -- Anthony PERARD _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel From xen-devel-bounces@lists.xensource.com Wed Sep 21 06:09:54 2011 Return-path: <xen-devel-bounces@lists.xensource.com> Envelope-to: www-data@lists.xensource.com Delivery-date: Wed, 21 Sep 2011 06:09:54 -0700 Received: from localhost ([127.0.0.1] helo=lists.colo.xensource.com) by lists.xensource.com with esmtp (Exim 4.43) id 1R6MYk-0007S0-Ha; Wed, 21 Sep 2011 06:09:54 -0700 Received: from mail21.messagelabs.com ([85.158.143.35]) by lists.xensource.com with esmtp (Exim 4.43) id 1R6MPn-0004dP-4v for xen-devel@lists.xensource.com; Wed, 21 Sep 2011 06:00:43 -0700 X-Env-Sender: anthony.perard@citrix.com X-Msg-Ref: server-4.tower-21.messagelabs.com!1316609993!61062359!4 X-Originating-IP: [66.165.176.89] X-StarScan-Version: 6.4.1; banners=-,-,- X-VirusChecked: Checked Received: (qmail 10826 invoked from network); 21 Sep 2011 12:59:59 -0000 Received: from smtp.citrix.com (HELO SMTP.CITRIX.COM) (66.165.176.89) by server-4.tower-21.messagelabs.com with RC4-SHA encrypted SMTP; 21 Sep 2011 12:59:59 -0000 X-IronPort-AV: E=Sophos;i="4.68,417,1312171200"; d="scan'208";a="17568591" Received: from ftlpmailmx02.citrite.net ([10.13.107.66]) by FTLPIPO01.CITRIX.COM with ESMTP/TLS/RC4-MD5; 21 Sep 2011 09:00:34 -0400 Received: from smtp01.ad.xensource.com (10.219.128.104) by smtprelay.citrix.com (10.13.107.66) with Microsoft SMTP Server id 8.3.137.0; Wed, 21 Sep 2011 09:00:34 -0400 Received: from perard.uk.xensource.com (dhcp-3-28.uk.xensource.com [10.80.3.28] (may be forged)) by smtp01.ad.xensource.com (8.13.1/8.13.1) with ESMTP id p8LD0PSK024347; Wed, 21 Sep 2011 06:00:32 -0700 From: Anthony PERARD <anthony.perard@citrix.com> To: Xen Devel <xen-devel@lists.xensource.com> Date: Wed, 21 Sep 2011 13:59:56 +0100 Message-ID: <1316609997-26002-7-git-send-email-anthony.perard@citrix.com> X-Mailer: git-send-email 1.7.2.5 In-Reply-To: <1316609997-26002-1-git-send-email-anthony.perard@citrix.com> References: <1316609997-26002-1-git-send-email-anthony.perard@citrix.com> MIME-Version: 1.0 Content-Type: text/plain Cc: Ian Campbell <Ian.Campbell@eu.citrix.com>, Anthony PERARD <anthony.perard@citrix.com>, Stefano Stabellini <stefano.stabellini@eu.citrix.com> Subject: [Xen-devel] [PATCH RESEND V8 6/7] libxl: Introduce JSON parsing stuff. X-BeenThere: xen-devel@lists.xensource.com X-Mailman-Version: 2.1.5 Precedence: list List-Id: Xen developer discussion <xen-devel.lists.xensource.com> List-Unsubscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe> List-Post: <mailto:xen-devel@lists.xensource.com> List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help> List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=subscribe> Sender: xen-devel-bounces@lists.xensource.com Errors-To: xen-devel-bounces@lists.xensource.com We use the yajl parser, but we need to make a tree from the parse result to use it outside the parser. So this patch include json_object struct that is used to hold the JSON data. Signed-off-by: Anthony PERARD <anthony.perard@citrix.com> --- README | 1 + tools/libxl/Makefile | 5 +- tools/libxl/libxl_internal.h | 100 ++++++++ tools/libxl/libxl_json.c | 560 ++++++++++++++++++++++++++++++++++++++++++ 4 files changed, 665 insertions(+), 1 deletions(-) create mode 100644 tools/libxl/libxl_json.c diff --git a/README b/README index ff154b2..c9bf699 100644 --- a/README +++ b/README @@ -47,6 +47,7 @@ provided by your OS distributor: * Development install of openssl (e.g., openssl-dev) * Development install of x11 (e.g. xorg-x11-dev) * Development install of uuid (e.g. uuid-dev) + * Development install of yajl (e.g. libyajl-dev) * bridge-utils package (/sbin/brctl) * iproute package (/sbin/ip) * hotplug or udev diff --git a/tools/libxl/Makefile b/tools/libxl/Makefile index 1f6b418..e50874e 100644 --- a/tools/libxl/Makefile +++ b/tools/libxl/Makefile @@ -32,9 +32,12 @@ endif LIBXL_OBJS-$(CONFIG_X86) += libxl_cpuid.o LIBXL_OBJS-$(CONFIG_IA64) += libxl_nocpuid.o +LIBXL_LIBS += -lyajl + LIBXL_OBJS = flexarray.o libxl.o libxl_create.o libxl_dm.o libxl_pci.o \ libxl_dom.o libxl_exec.o libxl_xshelp.o libxl_device.o \ - libxl_internal.o libxl_utils.o libxl_uuid.o $(LIBXL_OBJS-y) + libxl_internal.o libxl_utils.o libxl_uuid.o libxl_json.o \ + $(LIBXL_OBJS-y) LIBXL_OBJS += _libxl_types.o libxl_flask.o _libxl_types_internal.o $(LIBXL_OBJS): CFLAGS += $(CFLAGS_libxenctrl) $(CFLAGS_libxenguest) $(CFLAGS_libxenstore) $(CFLAGS_libblktapctl) diff --git a/tools/libxl/libxl_internal.h b/tools/libxl/libxl_internal.h index d873243..f495e86 100644 --- a/tools/libxl/libxl_internal.h +++ b/tools/libxl/libxl_internal.h @@ -387,4 +387,104 @@ _hidden int libxl__e820_alloc(libxl_ctx *ctx, uint32_t domid, libxl_domain_confi #define STRINGIFY(x) #x #define TOSTRING(x) STRINGIFY(x) +/* from libxl_json */ +#include <yajl/yajl_gen.h> + +_hidden yajl_gen_status libxl__yajl_gen_asciiz(yajl_gen hand, const char *str); + +typedef enum { + JSON_ERROR, + JSON_NULL, + JSON_TRUE, + JSON_FALSE, + JSON_INTEGER, + JSON_DOUBLE, + JSON_STRING, + JSON_MAP, + JSON_ARRAY, + JSON_ANY +} libxl__json_node_type; + +typedef struct libxl__json_object { + libxl__json_node_type type; + union { + long i; + double d; + char *string; + /* List of libxl__json_object */ + flexarray_t *array; + /* List of libxl__json_map_node */ + flexarray_t *map; + } u; + struct libxl__json_object *parent; +} libxl__json_object; + +typedef struct { + char *map_key; + libxl__json_object *obj; +} libxl__json_map_node; + +typedef struct libxl__yajl_ctx libxl__yajl_ctx; + +static inline bool libxl__json_object_is_string(const libxl__json_object *o) +{ + return o != NULL && o->type == JSON_STRING; +} +static inline bool libxl__json_object_is_integer(const libxl__json_object *o) +{ + return o != NULL && o->type == JSON_INTEGER; +} +static inline bool libxl__json_object_is_map(const libxl__json_object *o) +{ + return o != NULL && o->type == JSON_MAP; +} +static inline bool libxl__json_object_is_array(const libxl__json_object *o) +{ + return o != NULL && o->type == JSON_ARRAY; +} + +static inline +const char *libxl__json_object_get_string(const libxl__json_object *o) +{ + if (libxl__json_object_is_string(o)) + return o->u.string; + else + return NULL; +} +static inline +flexarray_t *libxl__json_object_get_map(const libxl__json_object *o) +{ + if (libxl__json_object_is_map(o)) + return o->u.map; + else + return NULL; +} +static inline +flexarray_t *libxl__json_object_get_array(const libxl__json_object *o) +{ + if (libxl__json_object_is_array(o)) + return o->u.array; + else + return NULL; +} +static inline long libxl__json_object_get_integer(const libxl__json_object *o) +{ + if (libxl__json_object_is_integer(o)) + return o->u.i; + else + return -1; +} + +_hidden libxl__json_object *libxl__json_array_get(const libxl__json_object *o, + int i); +_hidden +libxl__json_map_node *libxl__json_map_node_get(const libxl__json_object *o, + int i); +_hidden const libxl__json_object *libxl__json_map_get(const char *key, + const libxl__json_object *o, + libxl__json_node_type expected_type); +_hidden void libxl__json_object_free(libxl__gc *gc, libxl__json_object *obj); + +_hidden libxl__json_object *libxl__json_parse(libxl__gc *gc, const char *s); + #endif diff --git a/tools/libxl/libxl_json.c b/tools/libxl/libxl_json.c new file mode 100644 index 0000000..e771925 --- /dev/null +++ b/tools/libxl/libxl_json.c @@ -0,0 +1,560 @@ +/* + * Copyright (C) 2011 Citrix Ltd. + * + * This program is free software; you can redistribute it and/or modify + * it under the terms of the GNU Lesser General Public License as published + * by the Free Software Foundation; version 2.1 only. with the special + * exception on linking described in file LICENSE. + * + * This program is distributed in the hope that it will be useful, + * but WITHOUT ANY WARRANTY; without even the implied warranty of + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the + * GNU Lesser General Public License for more details. + */ + +#include <assert.h> +#include <string.h> + +#include <yajl/yajl_parse.h> +#include <yajl/yajl_gen.h> + +#include "libxl_internal.h" + +/* #define DEBUG_ANSWER */ + +struct libxl__yajl_ctx { + libxl__gc *gc; + yajl_handle hand; + libxl__json_object *head; + libxl__json_object *current; +#ifdef DEBUG_ANSWER + yajl_gen g; +#endif +}; + +#ifdef DEBUG_ANSWER +# define DEBUG_GEN_ALLOC(ctx) \ + if ((ctx)->g == NULL) { \ + yajl_gen_config conf = { 1, " " }; \ + (ctx)->g = yajl_gen_alloc(&conf, NULL); \ + } +# define DEBUG_GEN_FREE(ctx) \ + if ((ctx)->g) yajl_gen_free((ctx)->g) +# define DEBUG_GEN(ctx, type) yajl_gen_##type(ctx->g) +# define DEBUG_GEN_VALUE(ctx, type, value) yajl_gen_##type(ctx->g, value) +# define DEBUG_GEN_STRING(ctx, str, n) yajl_gen_string(ctx->g, str, n) +# define DEBUG_GEN_REPORT(yajl_ctx) \ + do { \ + const unsigned char *buf = NULL; \ + unsigned int len = 0; \ + yajl_gen_get_buf((yajl_ctx)->g, &buf, &len); \ + LIBXL__LOG(libxl__gc_owner((yajl_ctx)->gc), \ + LIBXL__LOG_DEBUG, "response:\n%s", buf); \ + yajl_gen_free((yajl_ctx)->g); \ + (yajl_ctx)->g = NULL; \ + } while (0) +#else +# define DEBUG_GEN_ALLOC(ctx) ((void)0) +# define DEBUG_GEN_FREE(ctx) ((void)0) +# define DEBUG_GEN(ctx, type) ((void)0) +# define DEBUG_GEN_VALUE(ctx, type, value) ((void)0) +# define DEBUG_GEN_STRING(ctx, value, lenght) ((void)0) +# define DEBUG_GEN_REPORT(ctx) ((void)0) +#endif + +/* + * YAJL Helper + */ + +yajl_gen_status libxl__yajl_gen_asciiz(yajl_gen hand, const char *str) +{ + return yajl_gen_string(hand, (const unsigned char *)str, strlen(str)); +} + + +/* + * libxl__json_object helper functions + */ + +static libxl__json_object *json_object_alloc(libxl__gc *gc, + libxl__json_node_type type) +{ + libxl__json_object *obj; + + obj = calloc(1, sizeof (libxl__json_object)); + if (obj == NULL) { + LIBXL__LOG_ERRNO(libxl__gc_owner(gc), LIBXL__LOG_ERROR, + "Failed to allocate a libxl__json_object"); + return NULL; + } + + obj->type = type; + + if (type == JSON_MAP || type == JSON_ARRAY) { + flexarray_t *array = flexarray_make(1, 1); + if (array == NULL) { + LIBXL__LOG_ERRNO(libxl__gc_owner(gc), LIBXL__LOG_ERROR, + "Failed to allocate a flexarray"); + free(obj); + return NULL; + } + if (type == JSON_MAP) + obj->u.map = array; + else + obj->u.array = array; + } + + return obj; +} + +static int json_object_append_to(libxl__gc *gc, + libxl__json_object *obj, + libxl__json_object *dst) +{ + assert(dst != NULL); + + switch (dst->type) { + case JSON_MAP: { + libxl__json_map_node *last; + + if (dst->u.map->count == 0) { + LIBXL__LOG(libxl__gc_owner(gc), LIBXL__LOG_ERROR, + "Try to add a value to an empty map (with no key)"); + return -1; + } + flexarray_get(dst->u.map, dst->u.map->count - 1, (void**)&last); + last->obj = obj; + break; + } + case JSON_ARRAY: + if (flexarray_append(dst->u.array, obj) == 2) { + LIBXL__LOG_ERRNO(libxl__gc_owner(gc), LIBXL__LOG_ERROR, + "Failed to grow a flexarray"); + return -1; + } + break; + default: + LIBXL__LOG(libxl__gc_owner(gc), LIBXL__LOG_ERROR, + "Try append an object is not a map/array (%i)\n", + dst->type); + return -1; + } + + obj->parent = dst; + return 0; +} + +void libxl__json_object_free(libxl__gc *gc, libxl__json_object *obj) +{ + int index = 0; + + if (obj == NULL) + return; + switch (obj->type) { + case JSON_STRING: + free(obj->u.string); + break; + case JSON_MAP: { + libxl__json_map_node *node = NULL; + + for (index = 0; index < obj->u.map->count; index++) { + if (flexarray_get(obj->u.map, index, (void**)&node) != 0) + break; + libxl__json_object_free(gc, node->obj); + free(node->map_key); + free(node); + node = NULL; + } + flexarray_free(obj->u.map); + break; + } + case JSON_ARRAY: { + libxl__json_object *node = NULL; + break; + + for (index = 0; index < obj->u.array->count; index++) { + if (flexarray_get(obj->u.array, index, (void**)&node) != 0) + break; + libxl__json_object_free(gc, node); + node = NULL; + } + flexarray_free(obj->u.array); + break; + } + default: + break; + } + free(obj); +} + +libxl__json_object *libxl__json_array_get(const libxl__json_object *o, int i) +{ + flexarray_t *array = NULL; + libxl__json_object *obj = NULL; + + if ((array = libxl__json_object_get_array(o)) == NULL) { + return NULL; + } + + if (i >= array->count) + return NULL; + + if (flexarray_get(array, i, (void**)&obj) != 0) + return NULL; + + return obj; +} + +libxl__json_map_node *libxl__json_map_node_get(const libxl__json_object *o, + int i) +{ + flexarray_t *array = NULL; + libxl__json_map_node *obj = NULL; + + if ((array = libxl__json_object_get_map(o)) == NULL) { + return NULL; + } + + if (i >= array->count) + return NULL; + + if (flexarray_get(array, i, (void**)&obj) != 0) + return NULL; + + return obj; +} + +const libxl__json_object *libxl__json_map_get(const char *key, + const libxl__json_object *o, + libxl__json_node_type expected_type) +{ + flexarray_t *maps = NULL; + int index = 0; + + if (libxl__json_object_is_map(o)) { + libxl__json_map_node *node = NULL; + + maps = o->u.map; + for (index = 0; index < maps->count; index++) { + if (flexarray_get(maps, index, (void**)&node) != 0) + return NULL; + if (strcmp(key, node->map_key) == 0) { + if (expected_type == JSON_ANY + || (node->obj && node->obj->type == expected_type)) { + return node->obj; + } else { + return NULL; + } + } + } + } + return NULL; +} + + +/* + * JSON callbacks + */ + +static int json_callback_null(void *opaque) +{ + libxl__yajl_ctx *ctx = opaque; + libxl__json_object *obj; + + DEBUG_GEN(ctx, null); + + if ((obj = json_object_alloc(ctx->gc, JSON_NULL)) == NULL) + return 0; + + if (json_object_append_to(ctx->gc, obj, ctx->current) == -1) { + libxl__json_object_free(ctx->gc, obj); + return 0; + } + + return 1; +} + +static int json_callback_boolean(void *opaque, int boolean) +{ + libxl__yajl_ctx *ctx = opaque; + libxl__json_object *obj; + + DEBUG_GEN_VALUE(ctx, bool, boolean); + + if ((obj = json_object_alloc(ctx->gc, + boolean ? JSON_TRUE : JSON_FALSE)) == NULL) + return 0; + + if (json_object_append_to(ctx->gc, obj, ctx->current) == -1) { + libxl__json_object_free(ctx->gc, obj); + return 0; + } + + return 1; +} + +static int json_callback_integer(void *opaque, long value) +{ + libxl__yajl_ctx *ctx = opaque; + libxl__json_object *obj; + + DEBUG_GEN_VALUE(ctx, integer, value); + + if ((obj = json_object_alloc(ctx->gc, JSON_INTEGER)) == NULL) + return 0; + obj->u.i = value; + + if (json_object_append_to(ctx->gc, obj, ctx->current) == -1) { + libxl__json_object_free(ctx->gc, obj); + return 0; + } + + return 1; +} + +static int json_callback_double(void *opaque, double value) +{ + libxl__yajl_ctx *ctx = opaque; + libxl__json_object *obj; + + DEBUG_GEN_VALUE(ctx, double, value); + + if ((obj = json_object_alloc(ctx->gc, JSON_DOUBLE)) == NULL) + return 0; + obj->u.d = value; + + if (json_object_append_to(ctx->gc, obj, ctx->current) == -1) { + libxl__json_object_free(ctx->gc, obj); + return 0; + } + + return 1; +} + +static int json_callback_string(void *opaque, const unsigned char *str, + unsigned int len) +{ + libxl__yajl_ctx *ctx = opaque; + char *t = NULL; + libxl__json_object *obj = NULL; + + t = malloc(len + 1); + if (t == NULL) { + LIBXL__LOG_ERRNO(libxl__gc_owner(ctx->gc), LIBXL__LOG_ERROR, + "Failed to allocate"); + return 0; + } + + DEBUG_GEN_STRING(ctx, str, len); + + strncpy(t, (const char *) str, len); + t[len] = 0; + + if ((obj = json_object_alloc(ctx->gc, JSON_STRING)) == NULL) { + free(t); + return 0; + } + obj->u.string = t; + + if (json_object_append_to(ctx->gc, obj, ctx->current) == -1) { + libxl__json_object_free(ctx->gc, obj); + return 0; + } + + return 1; +} + +static int json_callback_map_key(void *opaque, const unsigned char *str, + unsigned int len) +{ + libxl__yajl_ctx *ctx = opaque; + char *t = NULL; + libxl__json_object *obj = ctx->current; + + t = malloc(len + 1); + if (t == NULL) { + LIBXL__LOG_ERRNO(libxl__gc_owner(ctx->gc), LIBXL__LOG_ERROR, + "Failed to allocate"); + return 0; + } + + DEBUG_GEN_STRING(ctx, str, len); + + strncpy(t, (const char *) str, len); + t[len] = 0; + + if (libxl__json_object_is_map(obj)) { + libxl__json_map_node *node = malloc(sizeof (libxl__json_map_node)); + if (node == NULL) { + LIBXL__LOG_ERRNO(libxl__gc_owner(ctx->gc), LIBXL__LOG_ERROR, + "Failed to allocate"); + return 0; + } + + node->map_key = t; + node->obj = NULL; + + if (flexarray_append(obj->u.map, node) == 2) { + LIBXL__LOG_ERRNO(libxl__gc_owner(ctx->gc), LIBXL__LOG_ERROR, + "Failed to grow a flexarray"); + return 0; + } + } else { + LIBXL__LOG(libxl__gc_owner(ctx->gc), LIBXL__LOG_ERROR, + "Current json object is not a map"); + return 0; + } + + return 1; +} + +static int json_callback_start_map(void *opaque) +{ + libxl__yajl_ctx *ctx = opaque; + libxl__json_object *obj = NULL; + + DEBUG_GEN(ctx, map_open); + + if ((obj = json_object_alloc(ctx->gc, JSON_MAP)) == NULL) + return 0; + + if (ctx->current) { + if (json_object_append_to(ctx->gc, obj, ctx->current) == -1) { + libxl__json_object_free(ctx->gc, obj); + return 0; + } + } + + ctx->current = obj; + if (ctx->head == NULL) { + ctx->head = obj; + } + + return 1; +} + +static int json_callback_end_map(void *opaque) +{ + libxl__yajl_ctx *ctx = opaque; + + DEBUG_GEN(ctx, map_close); + + if (ctx->current) { + ctx->current = ctx->current->parent; + } else { + LIBXL__LOG(libxl__gc_owner(ctx->gc), LIBXL__LOG_ERROR, + "No current libxl__json_object, cannot use his parent."); + return 0; + } + + return 1; +} + +static int json_callback_start_array(void *opaque) +{ + libxl__yajl_ctx *ctx = opaque; + libxl__json_object *obj = NULL; + + DEBUG_GEN(ctx, array_open); + + if ((obj = json_object_alloc(ctx->gc, JSON_ARRAY)) == NULL) + return 0; + + if (ctx->current) { + if (json_object_append_to(ctx->gc, obj, ctx->current) == -1) { + libxl__json_object_free(ctx->gc, obj); + return 0; + } + } + + ctx->current = obj; + if (ctx->head == NULL) { + ctx->head = obj; + } + + return 1; +} + +static int json_callback_end_array(void *opaque) +{ + libxl__yajl_ctx *ctx = opaque; + + DEBUG_GEN(ctx, array_close); + + if (ctx->current) { + ctx->current = ctx->current->parent; + } else { + LIBXL__LOG(libxl__gc_owner(ctx->gc), LIBXL__LOG_ERROR, + "No current libxl__json_object, cannot use his parent."); + return 0; + } + + return 1; +} + +static yajl_callbacks callbacks = { + json_callback_null, + json_callback_boolean, + json_callback_integer, + json_callback_double, + NULL, + json_callback_string, + json_callback_start_map, + json_callback_map_key, + json_callback_end_map, + json_callback_start_array, + json_callback_end_array +}; + +static void yajl_ctx_free(libxl__yajl_ctx *yajl_ctx) +{ + if (yajl_ctx->hand) { + yajl_free(yajl_ctx->hand); + yajl_ctx->hand = NULL; + } + DEBUG_GEN_FREE(yajl_ctx); +} + +libxl__json_object *libxl__json_parse(libxl__gc *gc, const char *s) +{ + yajl_status status; + libxl__yajl_ctx yajl_ctx; + + memset(&yajl_ctx, 0, sizeof (yajl_ctx)); + yajl_ctx.gc = gc; + + DEBUG_GEN_ALLOC(&yajl_ctx); + + if (yajl_ctx.hand == NULL) { + yajl_parser_config cfg = { + .allowComments = 1, + .checkUTF8 = 1, + }; + yajl_ctx.hand = yajl_alloc(&callbacks, &cfg, NULL, &yajl_ctx); + } + status = yajl_parse(yajl_ctx.hand, (const unsigned char *)s, strlen(s)); + status = yajl_parse_complete(yajl_ctx.hand); + + if (status == yajl_status_ok) { + libxl__json_object *o = yajl_ctx.head; + + DEBUG_GEN_REPORT(&yajl_ctx); + + yajl_ctx.head = NULL; + + yajl_ctx_free(&yajl_ctx); + return o; + } else { + unsigned char *str = yajl_get_error(yajl_ctx.hand, 1, + (const unsigned char *)s, + strlen(s)); + + LIBXL__LOG(libxl__gc_owner(gc), LIBXL__LOG_ERROR, + "yajl error: %s", str); + yajl_free_error(yajl_ctx.hand, str); + + libxl__json_object_free(gc, yajl_ctx.head); + yajl_ctx_free(&yajl_ctx); + return NULL; + } +} -- Anthony PERARD _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel From xen-devel-bounces@lists.xensource.com Wed Sep 21 06:11:17 2011 Return-path: <xen-devel-bounces@lists.xensource.com> Envelope-to: www-data@lists.xensource.com Delivery-date: Wed, 21 Sep 2011 06:11:17 -0700 Received: from localhost ([127.0.0.1] helo=lists.colo.xensource.com) by lists.xensource.com with esmtp (Exim 4.43) id 1R6Ma5-00080c-Kp; Wed, 21 Sep 2011 06:11:17 -0700 Received: from mail216.messagelabs.com ([85.158.143.99]) by lists.xensource.com with smtp (Exim 4.43) id 1R6MSc-0004wv-T4 for xen-devel@lists.xensource.com; Wed, 21 Sep 2011 06:03:51 -0700 X-Env-Sender: stefan.bader@canonical.com X-Msg-Ref: server-15.tower-216.messagelabs.com!1316610192!18592538!1 X-Originating-IP: [91.189.89.112] X-StarScan-Version: 6.4.1; banners=-,-,- X-VirusChecked: Checked Received: (qmail 20672 invoked from network); 21 Sep 2011 13:03:12 -0000 Received: from youngberry.canonical.com (HELO youngberry.canonical.com) (91.189.89.112) by server-15.tower-216.messagelabs.com with SMTP; 21 Sep 2011 13:03:12 -0000 Received: from p5b2e3324.dip.t-dialin.net ([91.46.51.36] helo=[192.168.2.5]) by youngberry.canonical.com with esmtpsa (TLS1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.71) (envelope-from <stefan.bader@canonical.com>) id 1R6MSF-00088s-BQ; Wed, 21 Sep 2011 13:03:11 +0000 Message-ID: <4E79E08D.1090503@canonical.com> Date: Wed, 21 Sep 2011 15:03:09 +0200 From: Stefan Bader <stefan.bader@canonical.com> User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.2.21) Gecko/20110831 Lightning/1.0b2 Thunderbird/3.1.13 MIME-Version: 1.0 To: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>, Stefano Stabellini <stefano.stabellini@eu.citrix.com> X-Enigmail-Version: 1.1.2 Content-Type: multipart/mixed; boundary="------------060305050705090103090300" Cc: Subject: [Xen-devel] Still struggling with HVM: tx timeouts on emulated nics X-BeenThere: xen-devel@lists.xensource.com X-Mailman-Version: 2.1.5 Precedence: list List-Id: Xen developer discussion <xen-devel.lists.xensource.com> List-Unsubscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe> List-Post: <mailto:xen-devel@lists.xensource.com> List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help> List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=subscribe> Sender: xen-devel-bounces@lists.xensource.com Errors-To: xen-devel-bounces@lists.xensource.com This is a multi-part message in MIME format. --------------060305050705090103090300 Content-Type: text/plain; charset=ISO-8859-15 Content-Transfer-Encoding: 7bit This is on 3.0.4 based dom0 and domU with 4.1.1 hypervisor. I tried using the default 8139cp and ne2k_pci emulated nic. The 8139cp one at least comes up and gets configured via dhcp. And initial pings also get routed and done correctly. But slightly higher traffic (like checking for updates) hangs. And after a while there are messages about tx timeouts. The ne2k_pci type nic almost immediately has those issues and never comes up correctly. I am attaching the dmesg of the guest with apic=debug enabled. I am not sure how this should be but both nics get configured with level,low IRQs. Disk emulation seems to be ok but that seem to use IO-APIC-edge. And any other IRQs seem to be at least not level. Btw, what exactly is the difference between xen-pirq-ioapic and IO-APIC? Another problem came up recently though that may just be me doing the wrong thing. Normally I boot with xen_emul_unplug=unnecessary as I want the emulated devices. xen-blkfront is a module in my case and I thought I once had been able to use that by removing the unplug arg and making the blkfront driver load. But when I recently tried the module loaded but no disks appeared... Again, not sure I just forgot how to do that right or that was different when using a 4.1.0 hypervisor still... -Stefan --------------060305050705090103090300 Content-Type: text/plain; name="hvm-nic-tx-dmesg.txt" Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename="hvm-nic-tx-dmesg.txt" [ 0.000000] Initializing cgroup subsys cpuset [ 0.000000] Initializing cgroup subsys cpu [ 0.000000] Linux version 3.0.0-11-server (buildd@crested) (gcc version 4.6.1 (Ubuntu/Linaro 4.6.1-9ubuntu2) ) #18-Ubuntu SMP Wed Sep 14 01:20:37 UTC 2011 (Ubuntu 3.0.0-11.18-server 3.0.4) [ 0.000000] Command line: BOOT_IMAGE=/vmlinuz-3.0.0-11-server root=/dev/mapper/oneiric--server64-root ro debug apic=debug xen_emul_unplug=unnecessary [ 0.000000] KERNEL supported cpus: [ 0.000000] Intel GenuineIntel [ 0.000000] AMD AuthenticAMD [ 0.000000] Centaur CentaurHauls [ 0.000000] BIOS-provided physical RAM map: [ 0.000000] BIOS-e820: 0000000000000000 - 000000000009e000 (usable) [ 0.000000] BIOS-e820: 000000000009e000 - 00000000000a0000 (reserved) [ 0.000000] BIOS-e820: 00000000000e0000 - 0000000000100000 (reserved) [ 0.000000] BIOS-e820: 0000000000100000 - 000000007f800000 (usable) [ 0.000000] BIOS-e820: 00000000fc000000 - 0000000100000000 (reserved) [ 0.000000] NX (Execute Disable) protection: active [ 0.000000] DMI 2.4 present. [ 0.000000] DMI: Xen HVM domU, BIOS 4.1.1 09/01/2011 [ 0.000000] Hypervisor detected: Xen HVM [ 0.000000] Xen version 4.1. [ 0.000000] Xen Platform PCI: I/O protocol version 1 [ 0.000000] HVMOP_pagetable_dying not supported [ 0.000000] e820 update range: 0000000000000000 - 0000000000010000 (usable) ==> (reserved) [ 0.000000] e820 remove range: 00000000000a0000 - 0000000000100000 (usable) [ 0.000000] No AGP bridge found [ 0.000000] last_pfn = 0x7f800 max_arch_pfn = 0x400000000 [ 0.000000] MTRR default type: write-back [ 0.000000] MTRR fixed ranges enabled: [ 0.000000] 00000-9FFFF write-back [ 0.000000] A0000-BFFFF write-combining [ 0.000000] C0000-FFFFF write-back [ 0.000000] MTRR variable ranges enabled: [ 0.000000] 0 base 0000F0000000 mask FFFFF8000000 uncachable [ 0.000000] 1 base 0000F8000000 mask FFFFFC000000 uncachable [ 0.000000] 2 disabled [ 0.000000] 3 disabled [ 0.000000] 4 disabled [ 0.000000] 5 disabled [ 0.000000] 6 disabled [ 0.000000] 7 disabled [ 0.000000] TOM2: 0000000820000000 aka 33280M [ 0.000000] x86 PAT enabled: cpu 0, old 0x7040600070406, new 0x7010600070106 [ 0.000000] Scan SMP from ffff880000000000 for 1024 bytes. [ 0.000000] Scan SMP from ffff88000009fc00 for 1024 bytes. [ 0.000000] Scan SMP from ffff8800000f0000 for 65536 bytes. [ 0.000000] found SMP MP-table at [ffff8800000fbcb0] fbcb0 [ 0.000000] mpc: fbba0-fbcac [ 0.000000] initial memory mapped : 0 - 20000000 [ 0.000000] Base memory trampoline at [ffff880000099000] 99000 size 20480 [ 0.000000] init_memory_mapping: 0000000000000000-000000007f800000 [ 0.000000] 0000000000 - 007f800000 page 2M [ 0.000000] kernel direct mapping tables up to 7f800000 @ 7f7fd000-7f800000 [ 0.000000] RAMDISK: 364d4000 - 37262000 [ 0.000000] ACPI: RSDP 00000000000ea020 00024 (v02 Xen) [ 0.000000] ACPI: XSDT 00000000fc0134f0 0003C (v01 Xen HVM 00000000 HVML 00000000) [ 0.000000] ACPI: FACP 00000000fc0132d0 000F4 (v04 Xen HVM 00000000 HVML 00000000) [ 0.000000] ACPI: DSDT 00000000fc003440 0FE05 (v02 Xen HVM 00000000 INTL 20100528) [ 0.000000] ACPI: FACS 00000000fc003400 00040 [ 0.000000] ACPI: APIC 00000000fc0133d0 000D8 (v02 Xen HVM 00000000 HVML 00000000) [ 0.000000] ACPI: HPET 00000000fc0134b0 00038 (v01 Xen HVM 00000000 HVML 00000000) [ 0.000000] ACPI: Local APIC address 0xfee00000 [ 0.000000] mapped APIC to ffffffffff5fc000 ( fee00000) [ 0.000000] No NUMA configuration found [ 0.000000] Faking a node at 0000000000000000-000000007f800000 [ 0.000000] Initmem setup node 0 0000000000000000-000000007f800000 [ 0.000000] NODE_DATA [000000007f7f8000 - 000000007f7fcfff] [ 0.000000] [ffffea0000000000-ffffea0001bfffff] PMD -> [ffff88007ce00000-ffff88007e9fffff] on node 0 [ 0.000000] Zone PFN ranges: [ 0.000000] DMA 0x00000010 -> 0x00001000 [ 0.000000] DMA32 0x00001000 -> 0x00100000 [ 0.000000] Normal empty [ 0.000000] Movable zone start PFN for each node [ 0.000000] early_node_map[2] active PFN ranges [ 0.000000] 0: 0x00000010 -> 0x0000009e [ 0.000000] 0: 0x00000100 -> 0x0007f800 [ 0.000000] On node 0 totalpages: 522126 [ 0.000000] DMA zone: 56 pages used for memmap [ 0.000000] DMA zone: 5 pages reserved [ 0.000000] DMA zone: 3921 pages, LIFO batch:0 [ 0.000000] DMA32 zone: 7084 pages used for memmap [ 0.000000] DMA32 zone: 511060 pages, LIFO batch:31 [ 0.000000] ACPI: PM-Timer IO Port: 0xb008 [ 0.000000] ACPI: Local APIC address 0xfee00000 [ 0.000000] mapped APIC to ffffffffff5fc000 ( fee00000) [ 0.000000] ACPI: LAPIC (acpi_id[0x00] lapic_id[0x00] enabled) [ 0.000000] ACPI: LAPIC (acpi_id[0x01] lapic_id[0x02] enabled) [ 0.000000] ACPI: LAPIC (acpi_id[0x02] lapic_id[0x04] enabled) [ 0.000000] ACPI: LAPIC (acpi_id[0x03] lapic_id[0x06] enabled) [ 0.000000] ACPI: LAPIC (acpi_id[0x04] lapic_id[0x08] disabled) [ 0.000000] ACPI: LAPIC (acpi_id[0x05] lapic_id[0x0a] disabled) [ 0.000000] ACPI: LAPIC (acpi_id[0x06] lapic_id[0x0c] disabled) [ 0.000000] ACPI: LAPIC (acpi_id[0x07] lapic_id[0x0e] disabled) [ 0.000000] ACPI: LAPIC (acpi_id[0x08] lapic_id[0x10] disabled) [ 0.000000] ACPI: LAPIC (acpi_id[0x09] lapic_id[0x12] disabled) [ 0.000000] ACPI: LAPIC (acpi_id[0x0a] lapic_id[0x14] disabled) [ 0.000000] ACPI: LAPIC (acpi_id[0x0b] lapic_id[0x16] disabled) [ 0.000000] ACPI: LAPIC (acpi_id[0x0c] lapic_id[0x18] disabled) [ 0.000000] ACPI: LAPIC (acpi_id[0x0d] lapic_id[0x1a] disabled) [ 0.000000] ACPI: LAPIC (acpi_id[0x0e] lapic_id[0x1c] disabled) [ 0.000000] ACPI: IOAPIC (id[0x01] address[0xfec00000] gsi_base[0]) [ 0.000000] IOAPIC[0]: apic_id 1, version 17, address 0xfec00000, GSI 0-47 [ 0.000000] ACPI: INT_SRC_OVR (bus 0 bus_irq 0 global_irq 2 dfl dfl) [ 0.000000] Int: type 0, pol 0, trig 0, bus 00, IRQ 00, APIC ID 1, APIC INT 02 [ 0.000000] ACPI: INT_SRC_OVR (bus 0 bus_irq 5 global_irq 5 low level) [ 0.000000] Int: type 0, pol 3, trig 3, bus 00, IRQ 05, APIC ID 1, APIC INT 05 [ 0.000000] ACPI: INT_SRC_OVR (bus 0 bus_irq 10 global_irq 10 low level) [ 0.000000] Int: type 0, pol 3, trig 3, bus 00, IRQ 0a, APIC ID 1, APIC INT 0a [ 0.000000] ACPI: INT_SRC_OVR (bus 0 bus_irq 11 global_irq 11 low level) [ 0.000000] Int: type 0, pol 3, trig 3, bus 00, IRQ 0b, APIC ID 1, APIC INT 0b [ 0.000000] Int: type 0, pol 3, trig 3, bus 00, IRQ 09, APIC ID 1, APIC INT 09 [ 0.000000] ACPI: IRQ0 used by override. [ 0.000000] Int: type 0, pol 0, trig 0, bus 00, IRQ 01, APIC ID 1, APIC INT 01 [ 0.000000] ACPI: IRQ2 used by override. [ 0.000000] Int: type 0, pol 0, trig 0, bus 00, IRQ 03, APIC ID 1, APIC INT 03 [ 0.000000] Int: type 0, pol 0, trig 0, bus 00, IRQ 04, APIC ID 1, APIC INT 04 [ 0.000000] ACPI: IRQ5 used by override. [ 0.000000] Int: type 0, pol 0, trig 0, bus 00, IRQ 06, APIC ID 1, APIC INT 06 [ 0.000000] Int: type 0, pol 0, trig 0, bus 00, IRQ 07, APIC ID 1, APIC INT 07 [ 0.000000] Int: type 0, pol 0, trig 0, bus 00, IRQ 08, APIC ID 1, APIC INT 08 [ 0.000000] ACPI: IRQ9 used by override. [ 0.000000] ACPI: IRQ10 used by override. [ 0.000000] ACPI: IRQ11 used by override. [ 0.000000] Int: type 0, pol 0, trig 0, bus 00, IRQ 0c, APIC ID 1, APIC INT 0c [ 0.000000] Int: type 0, pol 0, trig 0, bus 00, IRQ 0d, APIC ID 1, APIC INT 0d [ 0.000000] Int: type 0, pol 0, trig 0, bus 00, IRQ 0e, APIC ID 1, APIC INT 0e [ 0.000000] Int: type 0, pol 0, trig 0, bus 00, IRQ 0f, APIC ID 1, APIC INT 0f [ 0.000000] Using ACPI (MADT) for SMP configuration information [ 0.000000] ACPI: HPET id: 0x8086a201 base: 0xfed00000 [ 0.000000] SMP: Allowing 15 CPUs, 11 hotplug CPUs [ 0.000000] mapped IOAPIC to ffffffffff5fb000 (fec00000) [ 0.000000] nr_irqs_gsi: 64 [ 0.000000] PM: Registered nosave memory: 000000000009e000 - 00000000000a0000 [ 0.000000] PM: Registered nosave memory: 00000000000a0000 - 00000000000e0000 [ 0.000000] PM: Registered nosave memory: 00000000000e0000 - 0000000000100000 [ 0.000000] Allocating PCI resources starting at 7f800000 (gap: 7f800000:7c800000) [ 0.000000] Booting paravirtualized kernel on Xen HVM [ 0.000000] setup_percpu: NR_CPUS:256 nr_cpumask_bits:256 nr_cpu_ids:15 nr_node_ids:1 [ 0.000000] PERCPU: Embedded 27 pages/cpu @ffff88007f400000 s79616 r8192 d22784 u131072 [ 0.000000] pcpu-alloc: s79616 r8192 d22784 u131072 alloc=1*2097152 [ 0.000000] pcpu-alloc: [0] 00 01 02 03 04 05 06 07 08 09 10 11 12 13 14 -- [ 0.000000] Built 1 zonelists in Node order, mobility grouping on. Total pages: 514981 [ 0.000000] Policy zone: DMA32 [ 0.000000] Kernel command line: BOOT_IMAGE=/vmlinuz-3.0.0-11-server root=/dev/mapper/oneiric--server64-root ro debug apic=debug xen_emul_unplug=unnecessary [ 0.000000] PID hash table entries: 4096 (order: 3, 32768 bytes) [ 0.000000] Checking aperture... [ 0.000000] No AGP bridge found [ 0.000000] Calgary: detecting Calgary via BIOS EBDA area [ 0.000000] Calgary: Unable to locate Rio Grande table in EBDA - bailing! [ 0.000000] Memory: 2028616k/2088960k available (6186k kernel code, 456k absent, 59888k reserved, 6936k data, 900k init) [ 0.000000] SLUB: Genslabs=15, HWalign=64, Order=0-3, MinObjects=0, CPUs=15, Nodes=1 [ 0.000000] Hierarchical RCU implementation. [ 0.000000] RCU dyntick-idle grace-period acceleration is enabled. [ 0.000000] NR_IRQS:16640 nr_irqs:1208 16 [ 0.000000] Xen HVM callback vector for event delivery is enabled [ 0.000000] Console: colour dummy device 80x25 [ 0.000000] console [tty0] enabled [ 0.000000] allocated 16777216 bytes of page_cgroup [ 0.000000] please try 'cgroup_disable=memory' option if you don't want memory cgroups [ 0.000000] hpet clockevent registered [ 0.000000] Detected 2000.196 MHz processor. [ 0.000000] Marking TSC unstable due to TSCs unsynchronized [ 0.020000] Calibrating delay loop (skipped), value calculated using timer frequency.. 4000.39 BogoMIPS (lpj=20001960) [ 0.020000] pid_max: default: 32768 minimum: 301 [ 0.020000] Security Framework initialized [ 0.020000] AppArmor: AppArmor initialized [ 0.020000] Yama: becoming mindful. [ 0.020000] Dentry cache hash table entries: 262144 (order: 9, 2097152 bytes) [ 0.020000] Inode-cache hash table entries: 131072 (order: 8, 1048576 bytes) [ 0.020000] Mount-cache hash table entries: 256 [ 0.020000] Initializing cgroup subsys cpuacct [ 0.020000] Initializing cgroup subsys memory [ 0.020000] Initializing cgroup subsys devices [ 0.020000] Initializing cgroup subsys freezer [ 0.020000] Initializing cgroup subsys net_cls [ 0.020000] Initializing cgroup subsys blkio [ 0.020000] Initializing cgroup subsys perf_event [ 0.020000] tseg: 00dff00000 [ 0.020000] CPU: Physical Processor ID: 0 [ 0.020000] CPU: Processor Core ID: 0 [ 0.020000] mce: CPU supports 6 MCE banks [ 0.020000] using AMD E400 aware idle routine [ 0.020000] ACPI: Core revision 20110413 [ 0.020671] ftrace: allocating 26000 entries in 102 pages [ 0.040103] Getting VERSION: 50014 [ 0.040118] Getting VERSION: 50014 [ 0.040126] Getting ID: 0 [ 0.040133] Getting ID: ff000000 [ 0.040141] Getting LVT0: 10700 [ 0.040147] Getting LVT1: 400 [ 0.041801] x2apic not enabled, IRQ remapping init failed [ 0.041807] Switched APIC routing to physical flat. [ 0.041873] masked ExtINT on CPU#0 [ 0.043550] ENABLING IO-APIC IRQs [ 0.043553] init IO_APIC IRQs [ 0.043556] apic 1 pin 0 not connected [ 0.043567] IOAPIC[0]: Set routing entry (1-1 -> 0x31 -> IRQ 1 Mode:0 Active:0) [ 0.043594] IOAPIC[0]: Set routing entry (1-2 -> 0x30 -> IRQ 0 Mode:0 Active:0) [ 0.050003] IOAPIC[0]: Set routing entry (1-3 -> 0x33 -> IRQ 3 Mode:0 Active:0) [ 0.050029] IOAPIC[0]: Set routing entry (1-4 -> 0x34 -> IRQ 4 Mode:0 Active:0) [ 0.050054] IOAPIC[0]: Set routing entry (1-5 -> 0x35 -> IRQ 5 Mode:1 Active:1) [ 0.050079] IOAPIC[0]: Set routing entry (1-6 -> 0x36 -> IRQ 6 Mode:0 Active:0) [ 0.050104] IOAPIC[0]: Set routing entry (1-7 -> 0x37 -> IRQ 7 Mode:0 Active:0) [ 0.050129] IOAPIC[0]: Set routing entry (1-8 -> 0x38 -> IRQ 8 Mode:0 Active:0) [ 0.050154] IOAPIC[0]: Set routing entry (1-9 -> 0x39 -> IRQ 9 Mode:1 Active:1) [ 0.050179] IOAPIC[0]: Set routing entry (1-10 -> 0x3a -> IRQ 10 Mode:1 Active:1) [ 0.050204] IOAPIC[0]: Set routing entry (1-11 -> 0x3b -> IRQ 11 Mode:1 Active:1) [ 0.050229] IOAPIC[0]: Set routing entry (1-12 -> 0x3c -> IRQ 12 Mode:0 Active:0) [ 0.050254] IOAPIC[0]: Set routing entry (1-13 -> 0x3d -> IRQ 13 Mode:0 Active:0) [ 0.050279] IOAPIC[0]: Set routing entry (1-14 -> 0x3e -> IRQ 14 Mode:0 Active:0) [ 0.050304] IOAPIC[0]: Set routing entry (1-15 -> 0x3f -> IRQ 15 Mode:0 Active:0) [ 0.050328] apic 1 pin 16 not connected [ 0.050332] apic 1 pin 17 not connected [ 0.050335] apic 1 pin 18 not connected [ 0.050338] apic 1 pin 19 not connected [ 0.050341] apic 1 pin 20 not connected [ 0.050345] apic 1 pin 21 not connected [ 0.050348] apic 1 pin 22 not connected [ 0.050351] apic 1 pin 23 not connected [ 0.050354] apic 1 pin 24 not connected [ 0.050358] apic 1 pin 25 not connected [ 0.050361] apic 1 pin 26 not connected [ 0.050364] apic 1 pin 27 not connected [ 0.050367] apic 1 pin 28 not connected [ 0.050370] apic 1 pin 29 not connected [ 0.050374] apic 1 pin 30 not connected [ 0.050377] apic 1 pin 31 not connected [ 0.050380] apic 1 pin 32 not connected [ 0.050383] apic 1 pin 33 not connected [ 0.050387] apic 1 pin 34 not connected [ 0.050390] apic 1 pin 35 not connected [ 0.050393] apic 1 pin 36 not connected [ 0.050396] apic 1 pin 37 not connected [ 0.050399] apic 1 pin 38 not connected [ 0.050403] apic 1 pin 39 not connected [ 0.050406] apic 1 pin 40 not connected [ 0.050409] apic 1 pin 41 not connected [ 0.050412] apic 1 pin 42 not connected [ 0.050416] apic 1 pin 43 not connected [ 0.050419] apic 1 pin 44 not connected [ 0.050422] apic 1 pin 45 not connected [ 0.050425] apic 1 pin 46 not connected [ 0.050428] apic 1 pin 47 not connected [ 0.050566] ..TIMER: vector=0x30 apic1=0 pin1=2 apic2=0 pin2=0 [ 0.151653] CPU0: AMD Opteron(tm) Processor 6128 stepping 01 [ 0.151670] Xen: using vcpuop timer interface [ 0.151686] installing Xen timer for CPU 0 [ 0.151766] Performance Events: Broken PMU hardware detected, using software events only. [ 0.152552] Booting Node 0, Processors #1 [ 0.152556] smpboot cpu 1: start_ip = 99000 [ 0.020000] masked ExtINT on CPU#1 [ 0.310459] installing Xen timer for CPU 1 [ 0.310616] #2 [ 0.310624] smpboot cpu 2: start_ip = 99000 [ 0.020000] masked ExtINT on CPU#2 [ 0.470391] installing Xen timer for CPU 2 [ 0.470506] #3 [ 0.470511] smpboot cpu 3: start_ip = 99000 [ 0.020000] masked ExtINT on CPU#3 [ 0.630436] Brought up 4 CPUs [ 0.630431] installing Xen timer for CPU 3 [ 0.630454] Total of 4 processors activated (16072.03 BogoMIPS). [ 0.631461] devtmpfs: initialized [ 0.631639] print_constraints: dummy: [ 0.631669] Time: 12:04:45 Date: 09/21/11 [ 0.631719] NET: Registered protocol family 16 [ 0.631836] Trying to unpack rootfs image as initramfs... [ 0.653188] Extended Config Space enabled on 0 nodes [ 0.653251] ACPI: bus type pci registered [ 0.653633] PCI: Using configuration type 1 for base access [ 0.653638] PCI: Using configuration type 1 for extended access [ 0.654361] bio: create slab <bio-0> at 0 [ 0.654361] ACPI: EC: Look up EC in DSDT [ 0.663724] ACPI: Interpreter enabled [ 0.663731] ACPI: (supports S0 S3 S4 S5) [ 0.663750] ACPI: Using IOAPIC for interrupt routing [ 0.778431] ACPI: No dock devices found. [ 0.778438] HEST: Table not found. [ 0.778443] PCI: Using host bridge windows from ACPI; if necessary, use "pci=nocrs" and report a bug [ 0.778513] ACPI: PCI Root Bridge [PCI0] (domain 0000 [bus 00-ff]) [ 0.778634] pci_root PNP0A03:00: host bridge window [io 0x0000-0x0cf7] [ 0.778640] pci_root PNP0A03:00: host bridge window [io 0x0d00-0xffff] [ 0.778645] pci_root PNP0A03:00: host bridge window [mem 0x000a0000-0x000bffff] [ 0.778651] pci_root PNP0A03:00: host bridge window [mem 0xf0000000-0xfbffffff] [ 0.778829] pci 0000:00:00.0: [8086:1237] type 0 class 0x000600 [ 0.780379] pci 0000:00:01.0: [8086:7000] type 0 class 0x000601 [ 0.782861] pci 0000:00:01.1: [8086:7010] type 0 class 0x000101 [ 0.784385] pci 0000:00:01.1: reg 20: [io 0xc300-0xc30f] [ 0.785463] pci 0000:00:01.3: [8086:7113] type 0 class 0x000680 [ 0.785515] * Found PM-Timer Bug on the chipset. Due to workarounds for a bug, [ 0.785517] * this clock source is slow. Consider trying other clock sources [ 0.787717] pci 0000:00:01.3: quirk: [io 0xb000-0xb03f] claimed by PIIX4 ACPI [ 0.788460] pci 0000:00:02.0: [1013:00b8] type 0 class 0x000300 [ 0.788835] pci 0000:00:02.0: reg 10: [mem 0xf0000000-0xf1ffffff pref] [ 0.789128] pci 0000:00:02.0: reg 14: [mem 0xf3000000-0xf3000fff] [ 0.790919] pci 0000:00:03.0: [5853:0001] type 0 class 0x00ff80 [ 0.791419] pci 0000:00:03.0: reg 10: [io 0xc000-0xc0ff] [ 0.791747] pci 0000:00:03.0: reg 14: [mem 0xf2000000-0xf2ffffff pref] [ 0.793759] pci 0000:00:04.0: [10ec:8139] type 0 class 0x000200 [ 0.794209] pci 0000:00:04.0: reg 10: [io 0xc100-0xc1ff] [ 0.794538] pci 0000:00:04.0: reg 14: [mem 0xf3001000-0xf30010ff] [ 0.796559] pci 0000:00:05.0: [10ec:8029] type 0 class 0x000200 [ 0.797009] pci 0000:00:05.0: reg 10: [io 0xc200-0xc2ff] [ 0.800179] ACPI: PCI Interrupt Routing Table [\_SB_.PCI0._PRT] [ 0.800570] pci0000:00: Requesting ACPI _OSC control (0x1d) [ 0.800577] pci0000:00: ACPI _OSC request failed (AE_NOT_FOUND), returned control mask: 0x1d [ 0.800582] ACPI _OSC control for PCIe not granted, disabling ASPM [ 0.935017] Freeing initrd memory: 13880k freed [ 0.986014] ACPI: PCI Interrupt Link [LNKA] (IRQs *5 10 11) [ 0.986234] ACPI: PCI Interrupt Link [LNKB] (IRQs 5 *10 11) [ 0.986432] ACPI: PCI Interrupt Link [LNKC] (IRQs 5 10 *11) [ 0.986626] ACPI: PCI Interrupt Link [LNKD] (IRQs *5 10 11) [ 0.986762] xen/balloon: Initialising balloon driver. [ 0.986768] last_pfn = 0x7f800 max_arch_pfn = 0x400000000 [ 0.986778] xen-balloon: Initialising balloon driver. [ 0.986905] vgaarb: device added: PCI:0000:00:02.0,decodes=io+mem,owns=io+mem,locks=none [ 0.986913] vgaarb: loaded [ 0.986916] vgaarb: bridge control possible 0000:00:02.0 [ 0.987107] SCSI subsystem initialized [ 0.987136] libata version 3.00 loaded. [ 0.987136] usbcore: registered new interface driver usbfs [ 0.987136] usbcore: registered new interface driver hub [ 0.987136] usbcore: registered new device driver usb [ 0.987136] PCI: Using ACPI for IRQ routing [ 0.987136] PCI: pci_cache_line_size set to 64 bytes [ 0.987136] reserve RAM buffer: 000000000009e000 - 000000000009ffff [ 0.987136] reserve RAM buffer: 000000007f800000 - 000000007fffffff [ 0.987136] NetLabel: Initializing [ 0.987136] NetLabel: domain hash size = 128 [ 0.987136] NetLabel: protocols = UNLABELED CIPSOv4 [ 0.987136] NetLabel: unlabeled traffic allowed by default [ 0.987136] [ 0.987136] printing PIC contents [ 0.987136] ... PIC IMR: ffff [ 0.987136] ... PIC IRR: 0001 [ 0.987136] ... PIC ISR: 0000 [ 0.987136] ... PIC ELCR: 0c20 [ 0.987136] printing local APIC contents on CPU#0/0: [ 0.987136] ... APIC ID: 00000000 (0) [ 0.987136] ... APIC VERSION: 00050014 [ 0.987136] ... APIC TASKPRI: 00000000 (00) [ 0.987136] ... APIC PROCPRI: 00000000 [ 0.987136] ... APIC LDR: 01000000 [ 0.987136] ... APIC DFR: ffffffff [ 0.987136] ... APIC SPIV: 000001ff [ 0.987136] ... APIC ISR field: [ 0.987136] 0000000000000000000000000000000000000000000000000000000000000000 [ 0.987136] ... APIC TMR field: [ 0.987136] 0000000000000000000000000000000000000000000000000000000000000000 [ 0.987136] ... APIC IRR field: [ 0.987136] 0000000000000000000000000000000000000000000000000000000000000000 [ 0.987136] ... APIC ESR: 00000000 [ 0.987136] ... APIC ICR: 00000699 [ 0.987136] ... APIC ICR2: 06000000 [ 0.987136] ... APIC LVTT: 00010000 [ 0.987136] ... APIC LVTPC: 00010000 [ 0.987136] ... APIC LVT0: 00010700 [ 0.987136] ... APIC LVT1: 00000400 [ 0.987136] ... APIC LVTERR: 000000fe [ 0.987136] ... APIC TMICT: 00000000 [ 0.987136] ... APIC TMCCT: 00000000 [ 0.987136] ... APIC TDCR: 00000000 [ 0.987136] [ 0.987136] number of MP IRQ sources: 15. [ 0.987136] number of IO-APIC #1 registers: 48. [ 0.987136] testing the IO APIC....................... [ 0.987136] [ 0.987136] IO APIC #1...... [ 0.987136] .... register #00: 00000000 [ 0.987136] ....... : physical APIC id: 00 [ 0.987136] ....... : Delivery Type: 0 [ 0.987136] ....... : LTS : 0 [ 0.987136] .... register #01: 002F0011 [ 0.987136] ....... : max redirection entries: 002F [ 0.987136] ....... : PRQ implemented: 0 [ 0.987136] ....... : IO APIC version: 0011 [ 0.987136] .... register #02: 00000000 [ 0.987136] ....... : arbitration: 00 [ 0.987136] .... IRQ redirection table: [ 0.987136] NR Dst Mask Trig IRR Pol Stat Dmod Deli Vect: [ 0.987136] 00 000 1 0 0 0 0 0 0 00 [ 0.987136] 01 000 0 0 0 0 0 0 0 31 [ 0.987136] 02 000 0 0 0 0 0 0 0 30 [ 0.987136] 03 000 0 0 0 0 0 0 0 33 [ 0.987136] 04 000 0 0 0 0 0 0 0 34 [ 0.987136] 05 000 1 1 0 1 0 0 0 35 [ 0.987136] 06 000 0 0 0 0 0 0 0 36 [ 0.987136] 07 000 0 0 0 0 0 0 0 37 [ 0.987136] 08 000 0 0 0 0 0 0 0 38 [ 0.987136] 09 000 0 1 0 1 0 0 0 39 [ 0.987136] 0a 000 1 1 0 1 0 0 0 3A [ 0.987136] 0b 000 1 1 0 1 0 0 0 3B [ 0.987136] 0c 000 0 0 0 0 0 0 0 3C [ 0.987136] 0d 000 0 0 0 0 0 0 0 3D [ 0.987136] 0e 000 0 0 0 0 0 0 0 3E [ 0.987136] 0f 000 0 0 0 0 0 0 0 3F [ 0.987136] 10 000 1 0 0 0 0 0 0 00 [ 0.987136] 11 000 1 0 0 0 0 0 0 00 [ 0.987136] 12 000 1 0 0 0 0 0 0 00 [ 0.987136] 13 000 1 0 0 0 0 0 0 00 [ 0.987136] 14 000 1 0 0 0 0 0 0 00 [ 0.987136] 15 000 1 0 0 0 0 0 0 00 [ 0.987136] 16 000 1 0 0 0 0 0 0 00 [ 0.987136] 17 000 1 0 0 0 0 0 0 00 [ 0.987136] 18 000 1 0 0 0 0 0 0 00 [ 0.987136] 19 000 1 0 0 0 0 0 0 00 [ 0.987136] 1a 000 1 0 0 0 0 0 0 00 [ 0.987136] 1b 000 1 0 0 0 0 0 0 00 [ 0.987136] 1c 000 1 0 0 0 0 0 0 00 [ 0.987136] 1d 000 1 0 0 0 0 0 0 00 [ 0.987136] 1e 000 1 0 0 0 0 0 0 00 [ 0.987136] 1f 000 1 0 0 0 0 0 0 00 [ 0.987136] 20 000 1 0 0 0 0 0 0 00 [ 0.987136] 21 000 1 0 0 0 0 0 0 00 [ 0.987136] 22 000 1 0 0 0 0 0 0 00 [ 0.987136] 23 000 1 0 0 0 0 0 0 00 [ 0.987136] 24 000 1 0 0 0 0 0 0 00 [ 0.987136] 25 000 1 0 0 0 0 0 0 00 [ 0.987136] 26 000 1 0 0 0 0 0 0 00 [ 0.987136] 27 000 1 0 0 0 0 0 0 00 [ 0.987136] 28 000 1 0 0 0 0 0 0 00 [ 0.987136] 29 000 1 0 0 0 0 0 0 00 [ 0.987136] 2a 000 1 0 0 0 0 0 0 00 [ 0.987136] 2b 000 1 0 0 0 0 0 0 00 [ 0.987136] 2c 000 1 0 0 0 0 0 0 00 [ 0.987136] 2d 000 1 0 0 0 0 0 0 00 [ 0.987136] 2e 000 1 0 0 0 0 0 0 00 [ 0.990006] 2f 000 1 0 0 0 0 0 0 00 [ 0.990012] IRQ to pin mappings: [ 0.990015] IRQ0 -> 0:2 [ 0.990019] IRQ1 -> 0:1 [ 0.990023] IRQ3 -> 0:3 [ 0.990026] IRQ4 -> 0:4 [ 0.990030] IRQ5 -> 0:5 [ 0.990033] IRQ6 -> 0:6 [ 0.990037] IRQ7 -> 0:7 [ 0.990040] IRQ8 -> 0:8 [ 0.990044] IRQ9 -> 0:9 [ 0.990048] IRQ10 -> 0:10 [ 0.990051] IRQ11 -> 0:11 [ 0.990055] IRQ12 -> 0:12 [ 0.990059] IRQ13 -> 0:13 [ 0.990062] IRQ14 -> 0:14 [ 0.990066] IRQ15 -> 0:15 [ 0.990071] .................................... done. [ 0.990087] HPET: 3 timers in total, 0 timers will be used for per-cpu timer [ 0.990108] hpet0: at MMIO 0xfed00000, IRQs 2, 8, 0 [ 0.990115] hpet0: 3 comparators, 64-bit 62.500000 MHz counter [ 1.020042] Switching to clocksource xen [ 1.020106] Switched to NOHz mode on CPU #2 [ 1.020419] Switched to NOHz mode on CPU #1 [ 1.026147] AppArmor: AppArmor Filesystem Enabled [ 1.026182] pnp: PnP ACPI init [ 1.026197] ACPI: bus type pnp registered [ 1.026228] pnp 00:00: [mem 0x00000000-0x0009ffff] [ 1.026267] system 00:00: [mem 0x00000000-0x0009ffff] could not be reserved [ 1.026274] system 00:00: Plug and Play ACPI device, IDs PNP0c02 (active) [ 1.026366] pnp 00:01: [bus 00-ff] [ 1.026370] pnp 00:01: [io 0x0cf8-0x0cff] [ 1.026374] pnp 00:01: [io 0x0000-0x0cf7 window] [ 1.026378] pnp 00:01: [io 0x0d00-0xffff window] [ 1.026382] pnp 00:01: [mem 0x000a0000-0x000bffff window] [ 1.026387] pnp 00:01: [mem 0xf0000000-0xfbffffff window] [ 1.026421] pnp 00:01: Plug and Play ACPI device, IDs PNP0a03 (active) [ 1.026432] pnp 00:02: [io 0x10c0-0x1141] [ 1.026436] pnp 00:02: [io 0xb044-0xb047] [ 1.026463] system 00:02: [io 0x10c0-0x1141] has been reserved [ 1.026468] system 00:02: [io 0xb044-0xb047] has been reserved [ 1.026473] system 00:02: Plug and Play ACPI device, IDs PNP0c02 (active) [ 1.026497] pnp 00:03: [mem 0xfed00000-0xfed003ff] [ 1.026518] pnp 00:03: Plug and Play ACPI device, IDs PNP0103 (active) [ 1.026538] pnp 00:04: [io 0x0010-0x001f] [ 1.026542] pnp 00:04: [io 0x0022-0x002d] [ 1.026545] pnp 00:04: [io 0x0030-0x003f] [ 1.026549] pnp 00:04: [io 0x0044-0x005f] [ 1.026552] pnp 00:04: [io 0x0062-0x0063] [ 1.026556] pnp 00:04: [io 0x0065-0x006f] [ 1.026559] pnp 00:04: [io 0x0072-0x007f] [ 1.026563] pnp 00:04: [io 0x0080] [ 1.026566] pnp 00:04: [io 0x0084-0x0086] [ 1.026569] pnp 00:04: [io 0x0088] [ 1.026573] pnp 00:04: [io 0x008c-0x008e] [ 1.026576] pnp 00:04: [io 0x0090-0x009f] [ 1.026580] pnp 00:04: [io 0x00a2-0x00bd] [ 1.026583] pnp 00:04: [io 0x00e0-0x00ef] [ 1.026587] pnp 00:04: [io 0x08a0-0x08a3] [ 1.026590] pnp 00:04: [io 0x0cc0-0x0ccf] [ 1.026594] pnp 00:04: [io 0x04d0-0x04d1] [ 1.026629] system 00:04: [io 0x08a0-0x08a3] has been reserved [ 1.026635] system 00:04: [io 0x0cc0-0x0ccf] has been reserved [ 1.026639] system 00:04: [io 0x04d0-0x04d1] has been reserved [ 1.026645] system 00:04: Plug and Play ACPI device, IDs PNP0c02 (active) [ 1.026659] pnp 00:05: [dma 4] [ 1.026662] pnp 00:05: [io 0x0000-0x000f] [ 1.026666] pnp 00:05: [io 0x0081-0x0083] [ 1.026671] pnp 00:05: [io 0x0087] [ 1.026674] pnp 00:05: [io 0x0089-0x008b] [ 1.026678] pnp 00:05: [io 0x008f] [ 1.026681] pnp 00:05: [io 0x00c0-0x00df] [ 1.026684] pnp 00:05: [io 0x0480-0x048f] [ 1.026713] pnp 00:05: Plug and Play ACPI device, IDs PNP0200 (active) [ 1.026725] pnp 00:06: [io 0x0070-0x0071] [ 1.026745] xen: --> irq=8, pirq=16 [ 1.026750] pnp 00:06: [irq 8] [ 1.026771] pnp 00:06: Plug and Play ACPI device, IDs PNP0b00 (active) [ 1.026781] pnp 00:07: [io 0x0061] [ 1.026803] pnp 00:07: Plug and Play ACPI device, IDs PNP0800 (active) [ 1.026825] xen: --> irq=12, pirq=17 [ 1.026829] pnp 00:08: [irq 12] [ 1.026850] pnp 00:08: Plug and Play ACPI device, IDs PNP0f13 (active) [ 1.026866] pnp 00:09: [io 0x0060] [ 1.026869] pnp 00:09: [io 0x0064] [ 1.026878] xen: --> irq=1, pirq=18 [ 1.026881] pnp 00:09: [irq 1] [ 1.026905] pnp 00:09: Plug and Play ACPI device, IDs PNP0303 PNP030b (active) [ 1.026922] pnp 00:0a: [io 0x03f0-0x03f5] [ 1.026926] pnp 00:0a: [io 0x03f7] [ 1.026934] xen: --> irq=6, pirq=19 [ 1.026938] pnp 00:0a: [irq 6] [ 1.026941] pnp 00:0a: [dma 2] [ 1.026962] pnp 00:0a: Plug and Play ACPI device, IDs PNP0700 (active) [ 1.026984] pnp 00:0b: [io 0x03f8-0x03ff] [ 1.026992] xen: --> irq=4, pirq=20 [ 1.026996] pnp 00:0b: [irq 4] [ 1.027018] pnp 00:0b: Plug and Play ACPI device, IDs PNP0501 (active) [ 1.027048] pnp 00:0c: [io 0x0378-0x037f] [ 1.027056] xen: --> irq=7, pirq=21 [ 1.027060] pnp 00:0c: [irq 7] [ 1.027084] pnp 00:0c: Plug and Play ACPI device, IDs PNP0400 (active) [ 1.029095] Switched to NOHz mode on CPU #0 [ 1.029911] Switched to NOHz mode on CPU #3 [ 1.098728] pnp: PnP ACPI: found 13 devices [ 1.098736] ACPI: ACPI bus type pnp unregistered [ 1.104769] PCI: max bus depth: 0 pci_try_num: 1 [ 1.104783] pci_bus 0000:00: resource 4 [io 0x0000-0x0cf7] [ 1.104789] pci_bus 0000:00: resource 5 [io 0x0d00-0xffff] [ 1.104794] pci_bus 0000:00: resource 6 [mem 0x000a0000-0x000bffff] [ 1.104799] pci_bus 0000:00: resource 7 [mem 0xf0000000-0xfbffffff] [ 1.104853] NET: Registered protocol family 2 [ 1.105001] IP route cache hash table entries: 65536 (order: 7, 524288 bytes) [ 1.105753] TCP established hash table entries: 262144 (order: 10, 4194304 bytes) [ 1.107366] TCP bind hash table entries: 65536 (order: 8, 1048576 bytes) [ 1.107785] TCP: Hash tables configured (established 262144 bind 65536) [ 1.107790] TCP reno registered [ 1.107801] UDP hash table entries: 1024 (order: 3, 32768 bytes) [ 1.107829] UDP-Lite hash table entries: 1024 (order: 3, 32768 bytes) [ 1.108003] NET: Registered protocol family 1 [ 1.108019] pci 0000:00:00.0: Limiting direct PCI/PCI transfers [ 1.108153] pci 0000:00:01.0: PIIX3: Enabling Passive Release [ 1.108392] pci 0000:00:01.0: Activating ISA DMA hang workarounds [ 1.108920] pci 0000:00:02.0: Boot video device [ 1.109529] PCI: CLS 0 bytes, default 64 [ 1.110111] audit: initializing netlink socket (disabled) [ 1.110125] type=2000 audit(1316606687.451:1): initialized [ 1.138892] HugeTLB registered 2 MB page size, pre-allocated 0 pages [ 1.152615] VFS: Disk quotas dquot_6.5.2 [ 1.152689] Dquot-cache hash table entries: 512 (order 0, 4096 bytes) [ 1.153476] fuse init (API version 7.16) [ 1.153577] msgmni has been set to 3989 [ 1.154960] Block layer SCSI generic (bsg) driver version 0.4 loaded (major 253) [ 1.155114] io scheduler noop registered [ 1.155120] io scheduler deadline registered (default) [ 1.155179] io scheduler cfq registered [ 1.155285] pci_hotplug: PCI Hot Plug PCI Core version: 0.5 [ 1.155313] pciehp: PCI Express Hot Plug Controller Driver version: 0.4 [ 1.155381] efifb: probing for efifb [ 1.155497] efifb: framebuffer at 0xf0000000, mapped to 0xffffc90000900000, using 1408k, total 1408k [ 1.155504] efifb: mode is 800x600x24, linelength=2400, pages=1 [ 1.155508] efifb: scrolling: redraw [ 1.155512] efifb: Truecolor: size=0:8:8:8, shift=0:16:8:0 [ 1.183380] Console: switching to colour frame buffer device 100x37 [ 1.210619] fb0: EFI VGA frame buffer device [ 1.211058] input: Power Button as /devices/LNXSYSTM:00/LNXPWRBN:00/input/input0 [ 1.211668] ACPI: Power Button [PWRF] [ 1.212013] input: Sleep Button as /devices/LNXSYSTM:00/LNXSLPBN:00/input/input1 [ 1.212617] ACPI: Sleep Button [SLPF] [ 1.212939] ACPI: acpi_idle registered with cpuidle [ 1.291734] ERST: Table is not found! [ 1.292124] Serial: 8250/16550 driver, 32 ports, IRQ sharing enabled [ 1.339997] serial8250: ttyS0 at I/O 0x3f8 (irq = 4) is a 16550A [ 2.236900] 00:0b: ttyS0 at I/O 0x3f8 (irq = 4) is a 16550A [ 2.238060] Linux agpgart interface v0.103 [ 2.239591] brd: module loaded [ 2.257113] loop: module loaded [ 2.273373] ata_piix 0000:00:01.1: version 2.13 [ 2.289886] ata_piix 0000:00:01.1: setting latency timer to 64 [ 2.306932] scsi0 : ata_piix [ 2.323107] scsi1 : ata_piix [ 2.338841] ata1: PATA max MWDMA2 cmd 0x1f0 ctl 0x3f6 bmdma 0xc300 irq 14 [ 2.354925] ata2: PATA max MWDMA2 cmd 0x170 ctl 0x376 bmdma 0xc308 irq 15 [ 2.355237] Fixed MDIO Bus: probed [ 2.355259] PPP generic driver version 2.4.2 [ 2.355300] tun: Universal TUN/TAP device driver, 1.6 [ 2.355302] tun: (C) 1999-2004 Max Krasnyansky <maxk@qualcomm.com> [ 2.355380] ehci_hcd: USB 2.0 'Enhanced' Host Controller (EHCI) Driver [ 2.355395] ohci_hcd: USB 1.1 'Open' Host Controller (OHCI) Driver [ 2.355405] uhci_hcd: USB Universal Host Controller Interface driver [ 2.355471] i8042: PNP: PS/2 Controller [PNP0303:PS2K,PNP0f13:PS2M] at 0x60,0x64 irq 1,12 [ 2.358680] serio: i8042 KBD port at 0x60,0x64 irq 1 [ 2.358688] serio: i8042 AUX port at 0x60,0x64 irq 12 [ 2.358743] mousedev: PS/2 mouse device common for all mice [ 2.358928] rtc_cmos 00:06: rtc core: registered rtc_cmos as rtc0 [ 2.358978] rtc0: alarms up to one day, 114 bytes nvram, hpet irqs [ 2.359079] device-mapper: uevent: version 1.0.3 [ 2.359144] device-mapper: ioctl: 4.20.0-ioctl (2011-02-02) initialised: dm-devel@redhat.com [ 2.359152] cpuidle: using governor ladder [ 2.359154] cpuidle: using governor menu [ 2.359156] EFI Variables Facility v0.08 2004-May-17 [ 2.359406] TCP cubic registered [ 2.359526] NET: Registered protocol family 10 [ 2.360127] NET: Registered protocol family 17 [ 2.360144] Registering the dns_resolver key type [ 2.360239] PM: Hibernation image not present or could not be loaded. [ 2.360251] registered taskstats version 1 [ 2.367547] input: AT Translated Set 2 keyboard as /devices/platform/i8042/serio0/input/input2 [ 2.374868] Magic number: 11:381:77 [ 2.512454] ata1.01: NODEV after polling detection [ 2.522271] ata1.00: ATA-7: QEMU HARDDISK, 0.10.2, max UDMA/100 [ 2.522275] ata1.00: 16384000 sectors, multi 16: LBA48 [ 2.524043] ata1.00: configured for MWDMA2 [ 2.524272] scsi 0:0:0:0: Direct-Access ATA QEMU HARDDISK 0.10 PQ: 0 ANSI: 5 [ 2.524424] sd 0:0:0:0: Attached scsi generic sg0 type 0 [ 2.524447] sd 0:0:0:0: [sda] 16384000 512-byte logical blocks: (8.38 GB/7.81 GiB) [ 2.524545] sd 0:0:0:0: [sda] Write Protect is off [ 2.524549] sd 0:0:0:0: [sda] Mode Sense: 00 3a 00 00 [ 2.524634] sd 0:0:0:0: [sda] Write cache: disabled, read cache: enabled, doesn't support DPO or FUA [ 2.544562] sda: sda1 sda2 < sda5 > [ 2.818026] rtc_cmos 00:06: setting system clock to 2011-09-21 12:04:46 UTC (1316606686) [ 2.818427] sd 0:0:0:0: [sda] Attached SCSI disk [ 3.097595] BIOS EDD facility v0.16 2004-Jun-25, 0 devices found [ 3.097598] EDD information not available. [ 3.165041] Freeing unused kernel memory: 900k freed [ 3.187512] Write protecting the kernel read-only data: 12288k [ 3.216820] Freeing unused kernel memory: 1988k freed [ 3.243501] Freeing unused kernel memory: 1372k freed [ 3.312423] udevd[95]: starting version 173 [ 3.349204] ne2k-pci.c:v1.03 9/22/2003 D. Becker/P. Gortmaker [ 3.375292] xen: --> irq=36, pirq=22 [ 3.397463] ne2k-pci 0000:00:05.0: PCI INT A -> GSI 36 (level, low) -> IRQ 36 [ 3.420185] 8139cp: 8139cp: 10/100 PCI Ethernet driver v1.3 (Mar 22, 2004) [ 3.423679] eth0: RealTek RTL-8029 found at 0xc200, IRQ 36, 00:16:3e:11:10:14. [ 3.461751] xen: --> irq=32, pirq=23 [ 3.481957] 8139cp 0000:00:04.0: PCI INT A -> GSI 32 (level, low) -> IRQ 32 [ 3.573231] 8139cp 0000:00:04.0: eth1: RTL-8139C+ at 0xffffc9000031c000, 00:16:3e:11:10:04, IRQ 32 [ 3.619031] 8139cp 0000:00:04.0: setting latency timer to 64 [ 3.653525] 8139too: 8139too Fast Ethernet driver 0.9.28 [ 3.653924] FDC 0 is a S82078B [ 4.348933] EXT4-fs (dm-0): mounted filesystem with ordered data mode. Opts: (null) [ 6.576003] udevd[329]: starting version 173 [ 6.587679] Adding 1044476k swap on /dev/mapper/oneiric--server64-swap_1. Priority:-1 extents:1 across:1044476k [ 6.607657] piix4_smbus 0000:00:01.3: SMBus base address uninitialized - upgrade BIOS or use force_addr=0xaddr [ 6.647843] xen map irq failed -22 [ 6.647850] xen-platform-pci 0000:00:03.0: PCI INT A: failed to register GSI [ 6.647861] xen-platform-pci: probe of 0000:00:03.0 failed with error -1 [ 6.692222] udevd[347]: renamed network interface eth1 to rename3 [ 6.694388] lp: driver loaded but no devices found [ 6.763849] parport_pc 00:0c: reported by Plug and Play ACPI [ 6.791506] parport0: PC-style at 0x378, irq 7 [PCSPP,TRISTATE] [ 6.828582] udevd[348]: renamed network interface eth0 to eth1 [ 6.831007] type=1400 audit(1316606690.953:2): apparmor="STATUS" operation="profile_load" name="/sbin/dhclient" pid=496 comm="apparmor_parser" [ 6.832850] type=1400 audit(1316606690.953:3): apparmor="STATUS" operation="profile_replace" name="/sbin/dhclient" pid=503 comm="apparmor_parser" [ 6.833442] type=1400 audit(1316606690.953:4): apparmor="STATUS" operation="profile_load" name="/usr/lib/NetworkManager/nm-dhcp-client.action" pid=503 comm="apparmor_parser" [ 6.833811] type=1400 audit(1316606690.953:5): apparmor="STATUS" operation="profile_load" name="/usr/lib/connman/scripts/dhclient-script" pid=503 comm="apparmor_parser" [ 6.836616] type=1400 audit(1316606690.953:6): apparmor="STATUS" operation="profile_replace" name="/usr/lib/NetworkManager/nm-dhcp-client.action" pid=496 comm="apparmor_parser" [ 6.840340] type=1400 audit(1316606690.963:7): apparmor="STATUS" operation="profile_replace" name="/usr/lib/connman/scripts/dhclient-script" pid=496 comm="apparmor_parser" [ 6.860412] udevd[347]: renamed network interface rename3 to eth0 [ 6.875981] lp0: using parport0 (interrupt-driven). [ 6.878190] ppdev: user-space parallel port driver [ 6.911760] 8139cp 0000:00:04.0: eth0: link up, 100Mbps, full-duplex, lpa 0x05E1 [ 7.010846] EXT4-fs (dm-0): re-mounted. Opts: errors=remount-ro [ 7.165200] input: ImExPS/2 Generic Explorer Mouse as /devices/platform/i8042/serio1/input/input3 [ 7.523428] type=1400 audit(1316606691.643:8): apparmor="STATUS" operation="profile_load" name="/usr/sbin/tcpdump" pid=696 comm="apparmor_parser" [ 7.523642] type=1400 audit(1316606691.643:9): apparmor="STATUS" operation="profile_replace" name="/sbin/dhclient" pid=695 comm="apparmor_parser" [ 7.524156] type=1400 audit(1316606691.643:10): apparmor="STATUS" operation="profile_replace" name="/usr/lib/NetworkManager/nm-dhcp-client.action" pid=695 comm="apparmor_parser" [ 7.524504] type=1400 audit(1316606691.643:11): apparmor="STATUS" operation="profile_replace" name="/usr/lib/connman/scripts/dhclient-script" pid=695 comm="apparmor_parser" [ 17.200108] eth0: no IPv6 routers present [ 332.040096] ------------[ cut here ]------------ [ 332.040108] WARNING: at /build/buildd/linux-3.0.0/net/sched/sch_generic.c:255 dev_watchdog+0x25a/0x270() [ 332.040111] Hardware name: HVM domU [ 332.040114] NETDEV WATCHDOG: eth1 (ne2k-pci): transmit queue 0 timed out [ 332.040116] Modules linked in: ppdev parport_pc psmouse serio_raw xen_platform_pci lp i2c_piix4 parport 8139too floppy 8139cp ne2k_pci 8390 [ 332.040131] Pid: 0, comm: swapper Not tainted 3.0.0-11-server #18-Ubuntu [ 332.040133] Call Trace: [ 332.040136] <IRQ> [<ffffffff8105e80f>] warn_slowpath_common+0x7f/0xc0 [ 332.040146] [<ffffffff8105e906>] warn_slowpath_fmt+0x46/0x50 [ 332.040151] [<ffffffff81091b92>] ? clockevents_program_event+0x62/0xa0 [ 332.040155] [<ffffffff81507e8a>] dev_watchdog+0x25a/0x270 [ 332.040158] [<ffffffff81507c30>] ? qdisc_reset+0x50/0x50 [ 332.040162] [<ffffffff81507c30>] ? qdisc_reset+0x50/0x50 [ 332.040167] [<ffffffff8106d2c6>] call_timer_fn+0x46/0x160 [ 332.040171] [<ffffffff81507c30>] ? qdisc_reset+0x50/0x50 [ 332.040174] [<ffffffff8106ebf2>] run_timer_softirq+0x132/0x2a0 [ 332.040179] [<ffffffff810076fc>] ? xen_timer_interrupt+0x2c/0x40 [ 332.040183] [<ffffffff81065db8>] __do_softirq+0xa8/0x210 [ 332.040189] [<ffffffff81607d1c>] call_softirq+0x1c/0x30 [ 332.040192] [<ffffffff8100c295>] do_softirq+0x65/0xa0 [ 332.040195] [<ffffffff8106619e>] irq_exit+0x8e/0xb0 [ 332.040200] [<ffffffff81385cf5>] xen_evtchn_do_upcall+0x35/0x50 [ 332.040204] [<ffffffff81607e43>] xen_hvm_callback_vector+0x13/0x20 [ 332.040206] <EOI> [<ffffffff81031c6b>] ? native_safe_halt+0xb/0x10 [ 332.040214] [<ffffffff810859d8>] ? hrtimer_start+0x18/0x20 [ 332.040218] [<ffffffff81012165>] default_idle+0x45/0x120 [ 332.040222] [<ffffffff8101229d>] amd_e400_idle+0x5d/0x120 [ 332.040225] [<ffffffff8100920b>] cpu_idle+0xab/0x100 [ 332.040230] [<ffffffff815c8b4e>] rest_init+0x72/0x74 [ 332.040235] [<ffffffff81ce6c2b>] start_kernel+0x3d4/0x3df [ 332.040239] [<ffffffff81ce6388>] x86_64_start_reservations+0x132/0x136 [ 332.040243] [<ffffffff81ce6140>] ? early_idt_handlers+0x140/0x140 [ 332.040247] [<ffffffff81ce6459>] x86_64_start_kernel+0xcd/0xdc [ 332.040249] ---[ end trace ad0f6614f5a7b7a3 ]--- [ 332.040349] eth1: Tx timed out, lost interrupt? TSR=0x1, ISR=0x2, t=44. [ 333.240212] eth1: Tx timed out, lost interrupt? TSR=0x1, ISR=0x2, t=22. [ 337.240207] eth1: Tx timed out, lost interrupt? TSR=0x1, ISR=0x3, t=21. [ 341.040211] eth1: Tx timed out, lost interrupt? TSR=0x1, ISR=0x3, t=71. [ 342.040103] eth1: no IPv6 routers present [ 342.040183] eth1: Tx timed out, lost interrupt? TSR=0x1, ISR=0x2, t=100. [ 352.040213] eth1: Tx timed out, lost interrupt? TSR=0x1, ISR=0x3, t=71. [ 365.040191] eth1: Tx timed out, lost interrupt? TSR=0x1, ISR=0x3, t=71. [ 403.040208] eth1: Tx timed out, lost interrupt? TSR=0x1, ISR=0x3, t=70. [ 441.040219] eth1: Tx timed out, lost interrupt? TSR=0x1, ISR=0x3, t=70. [ 467.040212] eth1: Tx timed out, lost interrupt? TSR=0x1, ISR=0x3, t=70. [ 495.040209] eth1: Tx timed out, lost interrupt? TSR=0x1, ISR=0x3, t=70. [ 522.040210] eth1: Tx timed out, lost interrupt? TSR=0x1, ISR=0x3, t=70. [ 550.040205] eth1: Tx timed out, lost interrupt? TSR=0x1, ISR=0x3, t=70. [ 578.040227] eth1: Tx timed out, lost interrupt? TSR=0x1, ISR=0x3, t=70. [ 605.040218] eth1: Tx timed out, lost interrupt? TSR=0x1, ISR=0x3, t=70. [ 631.040208] eth1: Tx timed out, lost interrupt? TSR=0x1, ISR=0x3, t=70. [ 1801.000294] 8139cp 0000:00:04.0: eth0: Transmit timeout, status d 3b 15 80ff --------------060305050705090103090300 Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel --------------060305050705090103090300-- From xen-devel-bounces@lists.xensource.com Wed Sep 21 06:12:58 2011 Return-path: <xen-devel-bounces@lists.xensource.com> Envelope-to: www-data@lists.xensource.com Delivery-date: Wed, 21 Sep 2011 06:12:58 -0700 Received: from localhost ([127.0.0.1] helo=lists.colo.xensource.com) by lists.xensource.com with esmtp (Exim 4.43) id 1R6Mbh-0008TI-Rw; Wed, 21 Sep 2011 06:12:58 -0700 Received: from mail174.messagelabs.com ([85.158.138.51]) by lists.xensource.com with esmtp (Exim 4.43) id 1R6MV3-0005oj-6E for xen-devel@lists.xensource.com; Wed, 21 Sep 2011 06:06:05 -0700 X-Env-Sender: Ian.Campbell@eu.citrix.com X-Msg-Ref: server-5.tower-174.messagelabs.com!1316610361!28549075!1 X-Originating-IP: [62.200.22.115] X-StarScan-Version: 6.4.1; banners=-,-,- X-VirusChecked: Checked Received: (qmail 9412 invoked from network); 21 Sep 2011 13:06:02 -0000 Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115) by server-5.tower-174.messagelabs.com with RC4-SHA encrypted SMTP; 21 Sep 2011 13:06:02 -0000 X-IronPort-AV: E=Sophos;i="4.68,417,1312156800"; d="scan'208";a="7979764" Received: from lonpmailmx01.citrite.net ([10.30.203.162]) by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5; 21 Sep 2011 13:06:01 +0000 Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net (10.30.203.162) with Microsoft SMTP Server id 8.3.137.0; Wed, 21 Sep 2011 14:06:01 +0100 From: Ian Campbell <Ian.Campbell@eu.citrix.com> To: "stefano.stabellini@eu.citrix.com" <stefano.stabellini@eu.citrix.com> Date: Wed, 21 Sep 2011 14:06:01 +0100 In-Reply-To: <1316598917-21515-3-git-send-email-stefano.stabellini@eu.citrix.com> References: <alpine.DEB.2.00.1109211051270.8700@kaball-desktop> <1316598917-21515-3-git-send-email-stefano.stabellini@eu.citrix.com> Organization: Citrix Systems, Inc. Content-Type: text/plain; charset="UTF-8" X-Mailer: Evolution 3.0.3- Content-Transfer-Encoding: 7bit Message-ID: <1316610361.3891.181.camel@zakaz.uk.xensource.com> MIME-Version: 1.0 Cc: Ian Jackson <Ian.Jackson@eu.citrix.com>, "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>, "keir@xen.org" <keir@xen.org> Subject: [Xen-devel] Re: [PATCH v5 3/4] Clone and build upstream Qemu by default X-BeenThere: xen-devel@lists.xensource.com X-Mailman-Version: 2.1.5 Precedence: list List-Id: Xen developer discussion <xen-devel.lists.xensource.com> List-Unsubscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe> List-Post: <mailto:xen-devel@lists.xensource.com> List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help> List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=subscribe> Sender: xen-devel-bounces@lists.xensource.com Errors-To: xen-devel-bounces@lists.xensource.com We should have this extra patch along with this change I guess.... (Ultimately it would awesome to stop shipping our own and use the distro /usr/bin/qemu but I don't think we are there yet...) # HG changeset patch # User Ian Campbell <ian.campbell@citrix.com> # Date 1316610277 -3600 # Node ID 5a91beb838a7573f97bc06adb84c96d438ff655f # Parent 466411f8a34da2bb4ef6edefcca87edfa1933d13 libxl: use new qemu at the location where xen-unstable installs it Signed-off-by: Ian Campbell <ian.campbell@citrix.com> diff -r 466411f8a34d -r 5a91beb838a7 tools/libxl/libxl_dm.c --- a/tools/libxl/libxl_dm.c Wed Sep 21 13:59:26 2011 +0100 +++ b/tools/libxl/libxl_dm.c Wed Sep 21 14:04:37 2011 +0100 @@ -55,7 +55,7 @@ const char *libxl__domain_device_model(l dm = libxl__abs_path(gc, "qemu-dm", libxl_libexec_path()); break; case LIBXL_DEVICE_MODEL_VERSION_QEMU_XEN: - dm = libxl__strdup(gc, "/usr/bin/qemu"); + dm = libxl__abs_path(gc, "qemu", libxl_libexec_path()); break; default: LIBXL__LOG(ctx, LIBXL__LOG_ERROR, _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel From xen-devel-bounces@lists.xensource.com Wed Sep 21 06:14:04 2011 Return-path: <xen-devel-bounces@lists.xensource.com> Envelope-to: www-data@lists.xensource.com Delivery-date: Wed, 21 Sep 2011 06:14:04 -0700 Received: from localhost ([127.0.0.1] helo=lists.colo.xensource.com) by lists.xensource.com with esmtp (Exim 4.43) id 1R6Mcm-0000PS-MV; Wed, 21 Sep 2011 06:14:04 -0700 Received: from mail27.messagelabs.com ([193.109.254.147]) by lists.xensource.com with esmtp (Exim 4.43) id 1R6MVc-00064G-Ba for xen-devel@lists.xensource.com; Wed, 21 Sep 2011 06:06:40 -0700 X-Env-Sender: Ian.Campbell@eu.citrix.com X-Msg-Ref: server-7.tower-27.messagelabs.com!1316610373!49571147!1 X-Originating-IP: [66.165.176.63] X-StarScan-Version: 6.4.1; banners=-,-,- X-VirusChecked: Checked Received: (qmail 18313 invoked from network); 21 Sep 2011 13:06:14 -0000 Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63) by server-7.tower-27.messagelabs.com with RC4-SHA encrypted SMTP; 21 Sep 2011 13:06:14 -0000 X-IronPort-AV: E=Sophos;i="4.68,417,1312171200"; d="scan'208";a="164117235" Received: from ftlpmailmx02.citrite.net ([10.13.107.66]) by FTLPIPO02.CITRIX.COM with ESMTP/TLS/RC4-MD5; 21 Sep 2011 09:06:35 -0400 Received: from smtp01.ad.xensource.com (10.219.128.104) by smtprelay.citrix.com (10.13.107.66) with Microsoft SMTP Server id 8.3.137.0; Wed, 21 Sep 2011 09:06:35 -0400 Received: from cosworth.uk.xensource.com (cosworth.uk.xensource.com [10.80.16.52]) by smtp01.ad.xensource.com (8.13.1/8.13.1) with ESMTP id p8LD6YVQ024366; Wed, 21 Sep 2011 06:06:34 -0700 Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Mercurial-Node: 0bde6820ca0c4a9152a8650a156c6c9b97c5f639 Message-ID: <0bde6820ca0c4a9152a8.1316610392@cosworth.uk.xensource.com> User-Agent: Mercurial-patchbomb/1.6.4 Date: Wed, 21 Sep 2011 14:06:32 +0100 From: Ian Campbell <ian.campbell@citrix.com> To: xen-devel@lists.xensource.com Cc: Ian Campbell <ian.campbell@citrix.com> Subject: [Xen-devel] [PATCH] libxl: libxl__e820_alloc must take a libxl__gc X-BeenThere: xen-devel@lists.xensource.com X-Mailman-Version: 2.1.5 Precedence: list List-Id: Xen developer discussion <xen-devel.lists.xensource.com> List-Unsubscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe> List-Post: <mailto:xen-devel@lists.xensource.com> List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help> List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=subscribe> Sender: xen-devel-bounces@lists.xensource.com Errors-To: xen-devel-bounces@lists.xensource.com # HG changeset patch # User Ian Campbell <ian.campbell@citrix.com> # Date 1316609966 -3600 # Node ID 0bde6820ca0c4a9152a8650a156c6c9b97c5f639 # Parent abbbe6c4abcc57ae90090a05d4bbf338e05693e5 libxl: libxl__e820_alloc must take a libxl__gc. Signed-off-by: Ian Campbell <ian.campbell@citrix.com> diff -r abbbe6c4abcc -r 0bde6820ca0c tools/libxl/libxl_create.c --- a/tools/libxl/libxl_create.c Wed Sep 21 13:59:26 2011 +0100 +++ b/tools/libxl/libxl_create.c Wed Sep 21 13:59:26 2011 +0100 @@ -599,7 +599,7 @@ static int do_domain_create(libxl__gc *g if (d_config->c_info.type == LIBXL_DOMAIN_TYPE_PV && d_config->b_info.u.pv.e820_host) { int rc; - rc = libxl__e820_alloc(ctx, domid, d_config); + rc = libxl__e820_alloc(gc, domid, d_config); if (rc) LIBXL__LOG_ERRNO(ctx, LIBXL__LOG_ERROR, "Failed while collecting E820 with: %d (errno:%d)\n", diff -r abbbe6c4abcc -r 0bde6820ca0c tools/libxl/libxl_internal.h --- a/tools/libxl/libxl_internal.h Wed Sep 21 13:59:26 2011 +0100 +++ b/tools/libxl/libxl_internal.h Wed Sep 21 13:59:26 2011 +0100 @@ -398,7 +398,7 @@ _hidden int libxl__error_set(libxl__gc * _hidden int libxl__file_reference_map(libxl_file_reference *f); _hidden int libxl__file_reference_unmap(libxl_file_reference *f); -_hidden int libxl__e820_alloc(libxl_ctx *ctx, uint32_t domid, libxl_domain_config *d_config); +_hidden int libxl__e820_alloc(libxl__gc *gc, uint32_t domid, libxl_domain_config *d_config); #define STRINGIFY(x) #x #define TOSTRING(x) STRINGIFY(x) diff -r abbbe6c4abcc -r 0bde6820ca0c tools/libxl/libxl_pci.c --- a/tools/libxl/libxl_pci.c Wed Sep 21 13:59:26 2011 +0100 +++ b/tools/libxl/libxl_pci.c Wed Sep 21 13:59:26 2011 +0100 @@ -1269,8 +1269,9 @@ static int e820_sanitize(libxl_ctx *ctx, return 0; } -int libxl__e820_alloc(libxl_ctx *ctx, uint32_t domid, libxl_domain_config *d_config) +int libxl__e820_alloc(libxl__gc *gc, uint32_t domid, libxl_domain_config *d_config) { + libxl_ctx *ctx = libxl__gc_owner(gc); int rc; uint32_t nr; struct e820entry map[E820MAX]; _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel From xen-devel-bounces@lists.xensource.com Wed Sep 21 06:14:58 2011 Return-path: <xen-devel-bounces@lists.xensource.com> Envelope-to: www-data@lists.xensource.com Delivery-date: Wed, 21 Sep 2011 06:14:58 -0700 Received: from localhost ([127.0.0.1] helo=lists.colo.xensource.com) by lists.xensource.com with esmtp (Exim 4.43) id 1R6Mdd-0000lt-VF; Wed, 21 Sep 2011 06:14:57 -0700 Received: from mail27.messagelabs.com ([193.109.254.147]) by lists.xensource.com with esmtp (Exim 4.43) id 1R6MYk-0007Qx-A3 for xen-devel@lists.xensource.com; Wed, 21 Sep 2011 06:09:54 -0700 X-Env-Sender: JBeulich@suse.com X-Msg-Ref: server-12.tower-27.messagelabs.com!1316610575!43346235!1 X-Originating-IP: [130.57.49.28] X-StarScan-Version: 6.4.1; banners=-,-,- X-VirusChecked: Checked Received: (qmail 5442 invoked from network); 21 Sep 2011 13:09:36 -0000 Received: from nat28.tlf.novell.com (HELO nat28.tlf.novell.com) (130.57.49.28) by server-12.tower-27.messagelabs.com with DHE-RSA-AES256-SHA encrypted SMTP; 21 Sep 2011 13:09:36 -0000 Received: from EMEA1-MTA by nat28.tlf.novell.com with Novell_GroupWise; Wed, 21 Sep 2011 14:09:50 +0100 Message-Id: <4E79FE5802000078000570E0@nat28.tlf.novell.com> X-Mailer: Novell GroupWise Internet Agent 8.0.1 Date: Wed, 21 Sep 2011 14:10:16 +0100 From: "Jan Beulich" <JBeulich@suse.com> To: "Ian Jackson" <Ian.Jackson@eu.citrix.com>, "Keir Fraser" <keir.xen@gmail.com> Subject: Re: [Xen-devel] [PATCH 3/7] PCI multi-seg: adjust domctl interface References: <CA9F287F.212AC%keir.xen@gmail.com> <alpine.DEB.2.00.1109211339250.8700@kaball-desktop> In-Reply-To: <alpine.DEB.2.00.1109211339250.8700@kaball-desktop> Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: quoted-printable Content-Disposition: inline Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>, Stefano Stabellini <stefano.stabellini@eu.citrix.com> X-BeenThere: xen-devel@lists.xensource.com X-Mailman-Version: 2.1.5 Precedence: list List-Id: Xen developer discussion <xen-devel.lists.xensource.com> List-Unsubscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe> List-Post: <mailto:xen-devel@lists.xensource.com> List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help> List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=subscribe> Sender: xen-devel-bounces@lists.xensource.com Errors-To: xen-devel-bounces@lists.xensource.com >>> On 21.09.11 at 14:42, Stefano Stabellini <stefano.stabellini@eu.citrix.= com> wrote: > On Wed, 21 Sep 2011, Keir Fraser wrote: >> On 20/09/2011 08:18, "Jan Beulich" <JBeulich@suse.com> wrote: >>=20 >> > Again, a couple of directly related functions at once get adjusted to >> > account for the segment number. >> > >> > Do we need to bump XEN_DOMCTL_INTERFACE_VERSION for the changes to = the >> > domctl interface (namely the renaming and bit-reassigment of the >> > machine_bdf member of two of the interface structures)? If so, this >> > can probably be done as the patch gets checked in (rather than me >> > having to re-submit)? >>=20 >> Ian suggests we should keep compatibility with old qemu versions. Are = any of >> these hypercall commands used by qemu? >>=20 >=20 > Before b4bb8b3f09d1c873f522f6aebe1f125a6d1854d0 xc_assign_device and > xc_deassign_device were called by qemu. Now they are called by libxl. Ian, Keir - what does that mean for my changes then? Do I need to re-spin them? Do I need to even introduce new domctl structures? Or just up the interface version (given that retaining compatibility with old qemu will be impossible anyway the first time the interface version gets changed, unless "old qemu" simply means git://xenbits.xensource.com/qemu-xen-unstable.git rather than my understanding of old, already built binaries)? Jan _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel From xen-devel-bounces@lists.xensource.com Wed Sep 21 06:31:41 2011 Return-path: <xen-devel-bounces@lists.xensource.com> Envelope-to: www-data@lists.xensource.com Delivery-date: Wed, 21 Sep 2011 06:31:41 -0700 Received: from localhost ([127.0.0.1] helo=lists.colo.xensource.com) by lists.xensource.com with esmtp (Exim 4.43) id 1R6Mtp-0001O2-9M; Wed, 21 Sep 2011 06:31:41 -0700 Received: from mail21.messagelabs.com ([85.158.143.35]) by lists.xensource.com with esmtp (Exim 4.43) id 1R6Mt9-0001Bq-Nr for xen-devel@lists.xensource.com; Wed, 21 Sep 2011 06:31:00 -0700 X-Env-Sender: Ian.Campbell@eu.citrix.com X-Msg-Ref: server-14.tower-21.messagelabs.com!1316611848!60429228!1 X-Originating-IP: [62.200.22.115] X-StarScan-Version: 6.4.1; banners=-,-,- X-VirusChecked: Checked Received: (qmail 4169 invoked from network); 21 Sep 2011 13:30:48 -0000 Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115) by server-14.tower-21.messagelabs.com with RC4-SHA encrypted SMTP; 21 Sep 2011 13:30:48 -0000 X-IronPort-AV: E=Sophos;i="4.68,417,1312156800"; d="scan'208";a="7980615" Received: from lonpmailmx01.citrite.net ([10.30.203.162]) by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5; 21 Sep 2011 13:30:56 +0000 Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net (10.30.203.162) with Microsoft SMTP Server id 8.3.137.0; Wed, 21 Sep 2011 14:30:56 +0100 From: Ian Campbell <Ian.Campbell@eu.citrix.com> To: Anthony PERARD <anthony.perard@citrix.com> Date: Wed, 21 Sep 2011 14:30:56 +0100 In-Reply-To: <1316609997-26002-2-git-send-email-anthony.perard@citrix.com> References: <1316609997-26002-1-git-send-email-anthony.perard@citrix.com> <1316609997-26002-2-git-send-email-anthony.perard@citrix.com> Organization: Citrix Systems, Inc. Content-Type: text/plain; charset="UTF-8" X-Mailer: Evolution 3.0.3- Content-Transfer-Encoding: 7bit Message-ID: <1316611856.3891.183.camel@zakaz.uk.xensource.com> MIME-Version: 1.0 Cc: Xen Devel <xen-devel@lists.xensource.com>, Stefano Stabellini <Stefano.Stabellini@eu.citrix.com> Subject: [Xen-devel] Re: [PATCH RESEND V8 1/7] libxl: Rename libxl.idl to libxl_types.idl. X-BeenThere: xen-devel@lists.xensource.com X-Mailman-Version: 2.1.5 Precedence: list List-Id: Xen developer discussion <xen-devel.lists.xensource.com> List-Unsubscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe> List-Post: <mailto:xen-devel@lists.xensource.com> List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help> List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=subscribe> Sender: xen-devel-bounces@lists.xensource.com Errors-To: xen-devel-bounces@lists.xensource.com On Wed, 2011-09-21 at 13:59 +0100, Anthony PERARD wrote: > Signed-off-by: Anthony PERARD <anthony.perard@citrix.com> Acked-by: Ian Campbell <ian.campbell@citrix.com> FWIW I acked v7 of this, collecting such acks in repostings of otherwise unchanged patches helps reviewer skip over them... > --- > tools/libxl/Makefile | 12 ++++++------ > tools/libxl/{libxl.idl => libxl_types.idl} | 0 > tools/ocaml/libs/xl/Makefile | 4 ++-- > tools/python/Makefile | 4 ++-- > 4 files changed, 10 insertions(+), 10 deletions(-) > rename tools/libxl/{libxl.idl => libxl_types.idl} (100%) > > diff --git a/tools/libxl/Makefile b/tools/libxl/Makefile > index 3eeb26f..330ee6e 100644 > --- a/tools/libxl/Makefile > +++ b/tools/libxl/Makefile > @@ -52,8 +52,8 @@ $(XL_OBJS): CFLAGS += $(CFLAGS_libxenctrl) # For xentoollog.h > $(XL_OBJS): CFLAGS += $(CFLAGS_libxenlight) > > testidl.o: CFLAGS += $(CFLAGS_libxenctrl) $(CFLAGS_libxenlight) > -testidl.c: libxl.idl gentest.py libxl.h > - $(PYTHON) gentest.py libxl.idl testidl.c.new > +testidl.c: libxl_types.idl gentest.py libxl.h > + $(PYTHON) gentest.py libxl_types.idl testidl.c.new > mv testidl.c.new testidl.c > > .PHONY: all > @@ -84,10 +84,10 @@ libxl.h: _libxl_types.h > > $(LIBXL_OBJS) $(LIBXLU_OBJS) $(XL_OBJS): libxl.h > > -_libxl_%.h _libxl_%.c: libxl.idl gen%.py libxl%.py > - $(PYTHON) gen$*.py libxl.idl __libxl_$*.h __libxl_$*.c > - $(call move-if-changed,__libxl_$*.h,_libxl_$*.h) > - $(call move-if-changed,__libxl_$*.c,_libxl_$*.c) > +_libxl_type%.h _libxl_type%.c: libxl_type%.idl gentypes.py libxltypes.py > + $(PYTHON) gentypes.py libxl_type$*.idl __libxl_type$*.h __libxl_type$*.c > + $(call move-if-changed,__libxl_type$*.h,_libxl_type$*.h) > + $(call move-if-changed,__libxl_type$*.c,_libxl_type$*.c) > > libxenlight.so: libxenlight.so.$(MAJOR) > ln -sf $< $@ > diff --git a/tools/libxl/libxl.idl b/tools/libxl/libxl_types.idl > similarity index 100% > rename from tools/libxl/libxl.idl > rename to tools/libxl/libxl_types.idl > diff --git a/tools/ocaml/libs/xl/Makefile b/tools/ocaml/libs/xl/Makefile > index 342dc35..a1e79a5 100644 > --- a/tools/ocaml/libs/xl/Makefile > +++ b/tools/ocaml/libs/xl/Makefile > @@ -45,10 +45,10 @@ xl.mli: xl.mli.in _libxl_types.mli.in > < xl.mli.in > xl.mli.tmp > $(Q)mv xl.mli.tmp xl.mli > > -_libxl_types.ml.in _libxl_types.mli.in _libxl_types.inc: genwrap.py $(XEN_ROOT)/tools/libxl/libxl.idl \ > +_libxl_types.ml.in _libxl_types.mli.in _libxl_types.inc: genwrap.py $(XEN_ROOT)/tools/libxl/libxl_types.idl \ > $(XEN_ROOT)/tools/libxl/libxltypes.py > PYTHONPATH=$(XEN_ROOT)/tools/libxl $(PYTHON) genwrap.py \ > - $(XEN_ROOT)/tools/libxl/libxl.idl \ > + $(XEN_ROOT)/tools/libxl/libxl_types.idl \ > _libxl_types.mli.in _libxl_types.ml.in _libxl_types.inc > > libs: $(LIBS) > diff --git a/tools/python/Makefile b/tools/python/Makefile > index de44178..b7bc501 100644 > --- a/tools/python/Makefile > +++ b/tools/python/Makefile > @@ -10,10 +10,10 @@ genpath-target = $(call buildmakevars2file,$(XENPATH)) > $(eval $(genpath-target)) > > .PHONY: build > -build: genpath genwrap.py $(XEN_ROOT)/tools/libxl/libxl.idl \ > +build: genpath genwrap.py $(XEN_ROOT)/tools/libxl/libxl_types.idl \ > $(XEN_ROOT)/tools/libxl/libxltypes.py > PYTHONPATH=$(XEN_ROOT)/tools/libxl $(PYTHON) genwrap.py \ > - $(XEN_ROOT)/tools/libxl/libxl.idl \ > + $(XEN_ROOT)/tools/libxl/libxl_types.idl \ > xen/lowlevel/xl/_pyxl_types.h \ > xen/lowlevel/xl/_pyxl_types.c > CC="$(CC)" CFLAGS="$(CFLAGS)" $(PYTHON) setup.py build _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel From xen-devel-bounces@lists.xensource.com Wed Sep 21 06:32:45 2011 Return-path: <xen-devel-bounces@lists.xensource.com> Envelope-to: www-data@lists.xensource.com Delivery-date: Wed, 21 Sep 2011 06:32:45 -0700 Received: from localhost ([127.0.0.1] helo=lists.colo.xensource.com) by lists.xensource.com with esmtp (Exim 4.43) id 1R6Mur-0001lb-DS; Wed, 21 Sep 2011 06:32:45 -0700 Received: from mail216.messagelabs.com ([85.158.143.99]) by lists.xensource.com with esmtp (Exim 4.43) id 1R6Mu0-0001RO-5S for xen-devel@lists.xensource.com; Wed, 21 Sep 2011 06:31:52 -0700 X-Env-Sender: Ian.Campbell@eu.citrix.com X-Msg-Ref: server-10.tower-216.messagelabs.com!1316611909!11009521!1 X-Originating-IP: [62.200.22.115] X-StarScan-Version: 6.4.1; banners=-,-,- X-VirusChecked: Checked Received: (qmail 23152 invoked from network); 21 Sep 2011 13:31:49 -0000 Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115) by server-10.tower-216.messagelabs.com with RC4-SHA encrypted SMTP; 21 Sep 2011 13:31:49 -0000 X-IronPort-AV: E=Sophos;i="4.68,417,1312156800"; d="scan'208";a="7980643" Received: from lonpmailmx01.citrite.net ([10.30.203.162]) by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5; 21 Sep 2011 13:31:48 +0000 Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net (10.30.203.162) with Microsoft SMTP Server id 8.3.137.0; Wed, 21 Sep 2011 14:31:49 +0100 From: Ian Campbell <Ian.Campbell@eu.citrix.com> To: Anthony PERARD <anthony.perard@citrix.com> Date: Wed, 21 Sep 2011 14:31:48 +0100 In-Reply-To: <1316609997-26002-3-git-send-email-anthony.perard@citrix.com> References: <1316609997-26002-1-git-send-email-anthony.perard@citrix.com> <1316609997-26002-3-git-send-email-anthony.perard@citrix.com> Organization: Citrix Systems, Inc. Content-Type: text/plain; charset="UTF-8" X-Mailer: Evolution 3.0.3- Content-Transfer-Encoding: 7bit Message-ID: <1316611908.3891.184.camel@zakaz.uk.xensource.com> MIME-Version: 1.0 Cc: Xen Devel <xen-devel@lists.xensource.com>, Stefano Stabellini <Stefano.Stabellini@eu.citrix.com> Subject: [Xen-devel] Re: [PATCH RESEND V8 2/7] libxl: Add get/set_default_namespace in libxltypes.py. X-BeenThere: xen-devel@lists.xensource.com X-Mailman-Version: 2.1.5 Precedence: list List-Id: Xen developer discussion <xen-devel.lists.xensource.com> List-Unsubscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe> List-Post: <mailto:xen-devel@lists.xensource.com> List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help> List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=subscribe> Sender: xen-devel-bounces@lists.xensource.com Errors-To: xen-devel-bounces@lists.xensource.com On Wed, 2011-09-21 at 13:59 +0100, Anthony PERARD wrote: > Signed-off-by: Anthony PERARD <anthony.perard@citrix.com> Acked-by: Ian Campbell <ian.campbell@citrix.com> > --- > tools/libxl/libxl_types.idl | 2 ++ > tools/libxl/libxltypes.py | 18 ++++++++++++++++-- > 2 files changed, 18 insertions(+), 2 deletions(-) > > diff --git a/tools/libxl/libxl_types.idl b/tools/libxl/libxl_types.idl > index 5b7e731..0d28283 100644 > --- a/tools/libxl/libxl_types.idl > +++ b/tools/libxl/libxl_types.idl > @@ -3,6 +3,8 @@ > # Builtin libxl types > # > > +namespace("libxl_") > + > libxl_domid = Builtin("domid") > libxl_uuid = Builtin("uuid", passby=PASS_BY_REFERENCE) > libxl_mac = Builtin("mac", passby=PASS_BY_REFERENCE) > diff --git a/tools/libxl/libxltypes.py b/tools/libxl/libxltypes.py > index f1a4dcf..86ab4b9 100644 > --- a/tools/libxl/libxltypes.py > +++ b/tools/libxl/libxltypes.py > @@ -8,10 +8,23 @@ DIR_IN = 1 > DIR_OUT = 2 > DIR_BOTH = 3 > > +_default_namespace = "" > +def namespace(s): > + if type(s) != str: > + raise TypeError, "Require a string for the default namespace." > + global _default_namespace > + _default_namespace = s > + > +def _get_default_namespace(): > + global _default_namespace > + return _default_namespace > + > + > class Type(object): > def __init__(self, typename, **kwargs): > self.comment = kwargs.setdefault('comment', None) > - self.namespace = kwargs.setdefault('namespace', "libxl_") > + self.namespace = kwargs.setdefault('namespace', > + _get_default_namespace()) > self.dir = kwargs.setdefault('dir', DIR_BOTH) > if self.dir not in [DIR_NONE, DIR_IN, DIR_OUT, DIR_BOTH]: > raise ValueError > @@ -256,7 +269,8 @@ def parse(f): > elif isinstance(t,type(object)) and issubclass(t, Type): > globs[n] = t > elif n in ['PASS_BY_REFERENCE', 'PASS_BY_VALUE', > - 'DIR_NONE', 'DIR_IN', 'DIR_OUT', 'DIR_BOTH']: > + 'DIR_NONE', 'DIR_IN', 'DIR_OUT', 'DIR_BOTH', > + 'namespace']: > globs[n] = t > > try: _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel From xen-devel-bounces@lists.xensource.com Wed Sep 21 06:33:44 2011 Return-path: <xen-devel-bounces@lists.xensource.com> Envelope-to: www-data@lists.xensource.com Delivery-date: Wed, 21 Sep 2011 06:33:44 -0700 Received: from localhost ([127.0.0.1] helo=lists.colo.xensource.com) by lists.xensource.com with esmtp (Exim 4.43) id 1R6Mvo-00028b-A5; Wed, 21 Sep 2011 06:33:44 -0700 Received: from mail216.messagelabs.com ([85.158.143.99]) by lists.xensource.com with esmtp (Exim 4.43) id 1R6Mu4-0001TD-9l for xen-devel@lists.xensource.com; Wed, 21 Sep 2011 06:31:56 -0700 X-Env-Sender: Stefano.Stabellini@eu.citrix.com X-Msg-Ref: server-10.tower-216.messagelabs.com!1316611909!11009521!2 X-Originating-IP: [62.200.22.115] X-StarScan-Version: 6.4.1; banners=-,-,- X-VirusChecked: Checked Received: (qmail 23597 invoked from network); 21 Sep 2011 13:31:53 -0000 Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115) by server-10.tower-216.messagelabs.com with RC4-SHA encrypted SMTP; 21 Sep 2011 13:31:53 -0000 X-IronPort-AV: E=Sophos;i="4.68,417,1312156800"; d="scan'208";a="7980647" Received: from lonpmailmx01.citrite.net ([10.30.203.162]) by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5; 21 Sep 2011 13:31:53 +0000 Received: from kaball.uk.xensource.com (10.80.2.59) by LONPMAILMX01.citrite.net (10.30.203.162) with Microsoft SMTP Server id 8.3.137.0; Wed, 21 Sep 2011 14:31:53 +0100 Date: Wed, 21 Sep 2011 14:31:45 +0100 From: Stefano Stabellini <stefano.stabellini@eu.citrix.com> X-X-Sender: sstabellini@kaball-desktop To: Stefan Bader <stefan.bader@canonical.com> In-Reply-To: <4E79E08D.1090503@canonical.com> Message-ID: <alpine.DEB.2.00.1109211422180.8700@kaball-desktop> References: <4E79E08D.1090503@canonical.com> User-Agent: Alpine 2.00 (DEB 1167 2008-08-23) MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>, Stabellini <Stefano.Stabellini@eu.citrix.com>, Stefano Subject: [Xen-devel] Re: Still struggling with HVM: tx timeouts on emulated nics X-BeenThere: xen-devel@lists.xensource.com X-Mailman-Version: 2.1.5 Precedence: list List-Id: Xen developer discussion <xen-devel.lists.xensource.com> List-Unsubscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe> List-Post: <mailto:xen-devel@lists.xensource.com> List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help> List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=subscribe> Sender: xen-devel-bounces@lists.xensource.com Errors-To: xen-devel-bounces@lists.xensource.com On Wed, 21 Sep 2011, Stefan Bader wrote: > This is on 3.0.4 based dom0 and domU with 4.1.1 hypervisor. I tried using the > default 8139cp and ne2k_pci emulated nic. The 8139cp one at least comes up and > gets configured via dhcp. And initial pings also get routed and done correctly. > But slightly higher traffic (like checking for updates) hangs. And after a while > there are messages about tx timeouts. > The ne2k_pci type nic almost immediately has those issues and never comes up > correctly. > > I am attaching the dmesg of the guest with apic=debug enabled. I am not sure how > this should be but both nics get configured with level,low IRQs. Disk emulation > seems to be ok but that seem to use IO-APIC-edge. And any other IRQs seem to be > at least not level. Does the e1000 emulated card work correctly? What happens if you disable interrupt remapping (see patch below)? diff --git a/arch/x86/pci/xen.c b/arch/x86/pci/xen.c index 1017c7b..472a58b 100644 --- a/arch/x86/pci/xen.c +++ b/arch/x86/pci/xen.c @@ -354,8 +354,7 @@ int __init pci_xen_init(void) int __init pci_xen_hvm_init(void) { - if (!xen_feature(XENFEAT_hvm_pirqs)) - return 0; + return 0; #ifdef CONFIG_ACPI /* > Btw, what exactly is the difference between xen-pirq-ioapic and IO-APIC? xen-pirq-ioapic interrupts are interrupts that have been remapped onto event channels > Another problem came up recently though that may just be me doing the wrong > thing. Normally I boot with xen_emul_unplug=unnecessary as I want the emulated > devices. xen-blkfront is a module in my case and I thought I once had been able > to use that by removing the unplug arg and making the blkfront driver load. But > when I recently tried the module loaded but no disks appeared... Again, not sure > I just forgot how to do that right or that was different when using a 4.1.0 > hypervisor still... xen_emul_unplug=unnecessary allows the kernel to use PV interfaces on older hypervisors that didn't support the unplug protocol and had other ways to cope with multiple drivers accessing the same devices. You can use xen_emul_unplug=never to prevent any unplug but you won't get any PV interfaces. _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel From xen-devel-bounces@lists.xensource.com Wed Sep 21 06:34:51 2011 Return-path: <xen-devel-bounces@lists.xensource.com> Envelope-to: www-data@lists.xensource.com Delivery-date: Wed, 21 Sep 2011 06:34:51 -0700 Received: from localhost ([127.0.0.1] helo=lists.colo.xensource.com) by lists.xensource.com with esmtp (Exim 4.43) id 1R6Mwt-0002W2-0r; Wed, 21 Sep 2011 06:34:51 -0700 Received: from mail21.messagelabs.com ([85.158.143.35]) by lists.xensource.com with esmtp (Exim 4.43) id 1R6Mv0-0001ol-9d for xen-devel@lists.xensource.com; Wed, 21 Sep 2011 06:32:55 -0700 X-Env-Sender: Ian.Campbell@eu.citrix.com X-Msg-Ref: server-14.tower-21.messagelabs.com!1316611962!60429656!1 X-Originating-IP: [62.200.22.115] X-StarScan-Version: 6.4.1; banners=-,-,- X-VirusChecked: Checked Received: (qmail 10877 invoked from network); 21 Sep 2011 13:32:43 -0000 Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115) by server-14.tower-21.messagelabs.com with RC4-SHA encrypted SMTP; 21 Sep 2011 13:32:43 -0000 X-IronPort-AV: E=Sophos;i="4.68,417,1312156800"; d="scan'208";a="7980678" Received: from lonpmailmx01.citrite.net ([10.30.203.162]) by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5; 21 Sep 2011 13:32: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.137.0; Wed, 21 Sep 2011 14:32:51 +0100 From: Ian Campbell <Ian.Campbell@eu.citrix.com> To: Anthony PERARD <anthony.perard@citrix.com> Date: Wed, 21 Sep 2011 14:32:50 +0100 In-Reply-To: <1316609997-26002-4-git-send-email-anthony.perard@citrix.com> References: <1316609997-26002-1-git-send-email-anthony.perard@citrix.com> <1316609997-26002-4-git-send-email-anthony.perard@citrix.com> Organization: Citrix Systems, Inc. Content-Type: text/plain; charset="UTF-8" X-Mailer: Evolution 3.0.3- Content-Transfer-Encoding: 7bit Message-ID: <1316611970.3891.185.camel@zakaz.uk.xensource.com> MIME-Version: 1.0 Cc: Xen Devel <xen-devel@lists.xensource.com>, Stefano Stabellini <Stefano.Stabellini@eu.citrix.com> Subject: [Xen-devel] Re: [PATCH RESEND V8 3/7] libxl: Introduce libxl_internal_types.idl. X-BeenThere: xen-devel@lists.xensource.com X-Mailman-Version: 2.1.5 Precedence: list List-Id: Xen developer discussion <xen-devel.lists.xensource.com> List-Unsubscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe> List-Post: <mailto:xen-devel@lists.xensource.com> List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help> List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=subscribe> Sender: xen-devel-bounces@lists.xensource.com Errors-To: xen-devel-bounces@lists.xensource.com On Wed, 2011-09-21 at 13:59 +0100, Anthony PERARD wrote: > Signed-off-by: Anthony PERARD <anthony.perard@citrix.com> Acked-by: Ian Campbell <ian.campbell@citrix.com> > --- > tools/libxl/Makefile | 4 +++- > tools/libxl/gentypes.py | 9 +++++---- > tools/libxl/libxl_internal.h | 1 + > tools/libxl/libxl_types_internal.idl | 9 +++++++++ > 4 files changed, 18 insertions(+), 5 deletions(-) > create mode 100644 tools/libxl/libxl_types_internal.idl > > diff --git a/tools/libxl/Makefile b/tools/libxl/Makefile > index 330ee6e..1f6b418 100644 > --- a/tools/libxl/Makefile > +++ b/tools/libxl/Makefile > @@ -35,7 +35,7 @@ LIBXL_OBJS-$(CONFIG_IA64) += libxl_nocpuid.o > LIBXL_OBJS = flexarray.o libxl.o libxl_create.o libxl_dm.o libxl_pci.o \ > libxl_dom.o libxl_exec.o libxl_xshelp.o libxl_device.o \ > libxl_internal.o libxl_utils.o libxl_uuid.o $(LIBXL_OBJS-y) > -LIBXL_OBJS += _libxl_types.o libxl_flask.o > +LIBXL_OBJS += _libxl_types.o libxl_flask.o _libxl_types_internal.o > > $(LIBXL_OBJS): CFLAGS += $(CFLAGS_libxenctrl) $(CFLAGS_libxenguest) $(CFLAGS_libxenstore) $(CFLAGS_libblktapctl) > > @@ -81,8 +81,10 @@ _libxl_paths.h: genpath > libxl_paths.c: _libxl_paths.h > > libxl.h: _libxl_types.h > +libxl_internal.h: _libxl_types_internal.h > > $(LIBXL_OBJS) $(LIBXLU_OBJS) $(XL_OBJS): libxl.h > +$(LIBXL_OBJS): libxl_internal.h > > _libxl_type%.h _libxl_type%.c: libxl_type%.idl gentypes.py libxltypes.py > $(PYTHON) gentypes.py libxl_type$*.idl __libxl_type$*.h __libxl_type$*.c > diff --git a/tools/libxl/gentypes.py b/tools/libxl/gentypes.py > index c66a33c..ecf5f15 100644 > --- a/tools/libxl/gentypes.py > +++ b/tools/libxl/gentypes.py > @@ -150,8 +150,9 @@ if __name__ == '__main__': > > f = open(header, "w") > > - f.write("""#ifndef __LIBXL_TYPES_H > -#define __LIBXL_TYPES_H > + header_define = header.upper().replace('.','_') > + f.write("""#ifndef %s > +#define %s > > /* > * DO NOT EDIT. > @@ -160,7 +161,7 @@ if __name__ == '__main__': > * "%s" > */ > > -""" % " ".join(sys.argv)) > +""" % (header_define, header_define, " ".join(sys.argv))) > > for ty in types: > f.write(libxl_C_type_define(ty) + ";\n") > @@ -172,7 +173,7 @@ if __name__ == '__main__': > f.write("extern libxl_enum_string_table %s_string_table[];\n" % (ty.typename)) > f.write("\n") > > - f.write("""#endif /* __LIBXL_TYPES_H */\n""") > + f.write("""#endif /* %s */\n""" % (header_define)) > f.close() > > print "outputting libxl type implementations to %s" % impl > diff --git a/tools/libxl/libxl_internal.h b/tools/libxl/libxl_internal.h > index b73b6c4..739e45e 100644 > --- a/tools/libxl/libxl_internal.h > +++ b/tools/libxl/libxl_internal.h > @@ -35,6 +35,7 @@ > > #include "flexarray.h" > #include "libxl_utils.h" > +#include "_libxl_types_internal.h" > > #define LIBXL_DESTROY_TIMEOUT 10 > #define LIBXL_DEVICE_MODEL_START_TIMEOUT 10 > diff --git a/tools/libxl/libxl_types_internal.idl b/tools/libxl/libxl_types_internal.idl > new file mode 100644 > index 0000000..20236a6 > --- /dev/null > +++ b/tools/libxl/libxl_types_internal.idl > @@ -0,0 +1,9 @@ > +namespace("libxl__") > + > +libxl__qmp_message_type = Enumeration("qmp_message_type", [ > + (1, "QMP"), > + (2, "return"), > + (3, "error"), > + (4, "event"), > + (5, "invalid"), > + ]) _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel From xen-devel-bounces@lists.xensource.com Wed Sep 21 06:36:00 2011 Return-path: <xen-devel-bounces@lists.xensource.com> Envelope-to: www-data@lists.xensource.com Delivery-date: Wed, 21 Sep 2011 06:36:00 -0700 Received: from localhost ([127.0.0.1] helo=lists.colo.xensource.com) by lists.xensource.com with esmtp (Exim 4.43) id 1R6My0-0002yX-6z; Wed, 21 Sep 2011 06:36:00 -0700 Received: from mail182.messagelabs.com ([85.158.139.83]) by lists.xensource.com with esmtp (Exim 4.43) id 1R6Mwj-0002RC-BE for xen-devel@lists.xensource.com; Wed, 21 Sep 2011 06:34:41 -0700 X-Env-Sender: Ian.Campbell@eu.citrix.com X-Msg-Ref: server-11.tower-182.messagelabs.com!1316612078!19204993!1 X-Originating-IP: [62.200.22.115] X-StarScan-Version: 6.4.1; banners=-,-,- X-VirusChecked: Checked Received: (qmail 3510 invoked from network); 21 Sep 2011 13:34:38 -0000 Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115) by server-11.tower-182.messagelabs.com with RC4-SHA encrypted SMTP; 21 Sep 2011 13:34:38 -0000 X-IronPort-AV: E=Sophos;i="4.68,417,1312156800"; d="scan'208";a="7980789" Received: from lonpmailmx01.citrite.net ([10.30.203.162]) by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5; 21 Sep 2011 13:34:37 +0000 Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net (10.30.203.162) with Microsoft SMTP Server id 8.3.137.0; Wed, 21 Sep 2011 14:34:37 +0100 From: Ian Campbell <Ian.Campbell@eu.citrix.com> To: Anthony PERARD <anthony.perard@citrix.com> Date: Wed, 21 Sep 2011 14:34:37 +0100 In-Reply-To: <1316609997-26002-5-git-send-email-anthony.perard@citrix.com> References: <1316609997-26002-1-git-send-email-anthony.perard@citrix.com> <1316609997-26002-5-git-send-email-anthony.perard@citrix.com> Organization: Citrix Systems, Inc. Content-Type: text/plain; charset="UTF-8" X-Mailer: Evolution 3.0.3- Content-Transfer-Encoding: 7bit Message-ID: <1316612077.3891.187.camel@zakaz.uk.xensource.com> MIME-Version: 1.0 Cc: Xen Devel <xen-devel@lists.xensource.com>, Stefano Stabellini <Stefano.Stabellini@eu.citrix.com> Subject: [Xen-devel] Re: [PATCH RESEND V8 4/7] libxl: Introduce libxl__realloc. X-BeenThere: xen-devel@lists.xensource.com X-Mailman-Version: 2.1.5 Precedence: list List-Id: Xen developer discussion <xen-devel.lists.xensource.com> List-Unsubscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe> List-Post: <mailto:xen-devel@lists.xensource.com> List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help> List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=subscribe> Sender: xen-devel-bounces@lists.xensource.com Errors-To: xen-devel-bounces@lists.xensource.com On Wed, 2011-09-21 at 13:59 +0100, Anthony PERARD wrote: > Signed-off-by: Anthony PERARD <anthony.perard@citrix.com> Acked-by: Ian Campbell <ian.campbell@citrix.com> > --- > tools/libxl/libxl_internal.c | 24 ++++++++++++++++++++++++ > tools/libxl/libxl_internal.h | 1 + > 2 files changed, 25 insertions(+), 0 deletions(-) > > diff --git a/tools/libxl/libxl_internal.c b/tools/libxl/libxl_internal.c > index e259278..c4d54f9 100644 > --- a/tools/libxl/libxl_internal.c > +++ b/tools/libxl/libxl_internal.c > @@ -102,6 +102,30 @@ void *libxl__calloc(libxl__gc *gc, size_t nmemb, size_t size) > return ptr; > } > > +void *libxl__realloc(libxl__gc *gc, void *ptr, size_t new_size) > +{ > + void *new_ptr = realloc(ptr, new_size); > + int i = 0; > + > + if (new_ptr == NULL && new_size != 0) { > + return NULL; > + } > + > + if (ptr == NULL) { > + libxl__ptr_add(gc, new_ptr); > + } else if (new_ptr != ptr) { > + for (i = 0; i < gc->alloc_maxsize; i++) { > + if (gc->alloc_ptrs[i] == ptr) { > + gc->alloc_ptrs[i] = new_ptr; > + break; > + } > + } > + } > + > + > + return new_ptr; > +} > + > char *libxl__sprintf(libxl__gc *gc, const char *fmt, ...) > { > char *s; > diff --git a/tools/libxl/libxl_internal.h b/tools/libxl/libxl_internal.h > index 739e45e..5d270bb 100644 > --- a/tools/libxl/libxl_internal.h > +++ b/tools/libxl/libxl_internal.h > @@ -145,6 +145,7 @@ _hidden int libxl__ptr_add(libxl__gc *gc, void *ptr); > _hidden void libxl__free_all(libxl__gc *gc); > _hidden void *libxl__zalloc(libxl__gc *gc, int bytes); > _hidden void *libxl__calloc(libxl__gc *gc, size_t nmemb, size_t size); > +_hidden void *libxl__realloc(libxl__gc *gc, void *ptr, size_t new_size); > _hidden char *libxl__sprintf(libxl__gc *gc, const char *fmt, ...) PRINTF_ATTRIBUTE(2, 3); > _hidden char *libxl__strdup(libxl__gc *gc, const char *c); > _hidden char *libxl__dirname(libxl__gc *gc, const char *s); _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel From xen-devel-bounces@lists.xensource.com Wed Sep 21 06:36:50 2011 Return-path: <xen-devel-bounces@lists.xensource.com> Envelope-to: www-data@lists.xensource.com Delivery-date: Wed, 21 Sep 2011 06:36:50 -0700 Received: from localhost ([127.0.0.1] helo=lists.colo.xensource.com) by lists.xensource.com with esmtp (Exim 4.43) id 1R6Myo-0003LM-Oj; Wed, 21 Sep 2011 06:36:50 -0700 Received: from mail182.messagelabs.com ([85.158.139.83]) by lists.xensource.com with esmtp (Exim 4.43) id 1R6Mxf-0002o3-Og for xen-devel@lists.xensource.com; Wed, 21 Sep 2011 06:35:40 -0700 X-Env-Sender: Ian.Campbell@eu.citrix.com X-Msg-Ref: server-8.tower-182.messagelabs.com!1316612136!19214341!1 X-Originating-IP: [62.200.22.115] X-StarScan-Version: 6.4.1; banners=-,-,- X-VirusChecked: Checked Received: (qmail 27700 invoked from network); 21 Sep 2011 13:35:36 -0000 Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115) by server-8.tower-182.messagelabs.com with RC4-SHA encrypted SMTP; 21 Sep 2011 13:35:36 -0000 X-IronPort-AV: E=Sophos;i="4.68,417,1312156800"; d="scan'208";a="7980807" Received: from lonpmailmx01.citrite.net ([10.30.203.162]) by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5; 21 Sep 2011 13:35:04 +0000 Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net (10.30.203.162) with Microsoft SMTP Server id 8.3.137.0; Wed, 21 Sep 2011 14:35:04 +0100 From: Ian Campbell <Ian.Campbell@eu.citrix.com> To: Anthony PERARD <anthony.perard@citrix.com> Date: Wed, 21 Sep 2011 14:35:04 +0100 In-Reply-To: <1316609997-26002-6-git-send-email-anthony.perard@citrix.com> References: <1316609997-26002-1-git-send-email-anthony.perard@citrix.com> <1316609997-26002-6-git-send-email-anthony.perard@citrix.com> Organization: Citrix Systems, Inc. Content-Type: text/plain; charset="UTF-8" X-Mailer: Evolution 3.0.3- Content-Transfer-Encoding: 7bit Message-ID: <1316612104.3891.188.camel@zakaz.uk.xensource.com> MIME-Version: 1.0 Cc: Xen Devel <xen-devel@lists.xensource.com>, Stefano Stabellini <Stefano.Stabellini@eu.citrix.com> Subject: [Xen-devel] Re: [PATCH RESEND V8 5/7] libxl: Intruduce libxl__strndup. X-BeenThere: xen-devel@lists.xensource.com X-Mailman-Version: 2.1.5 Precedence: list List-Id: Xen developer discussion <xen-devel.lists.xensource.com> List-Unsubscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe> List-Post: <mailto:xen-devel@lists.xensource.com> List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help> List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=subscribe> Sender: xen-devel-bounces@lists.xensource.com Errors-To: xen-devel-bounces@lists.xensource.com On Wed, 2011-09-21 at 13:59 +0100, Anthony PERARD wrote: > Signed-off-by: Anthony PERARD <anthony.perard@citrix.com> Acked-by: Ian Campbell <ian.campbell@citrix.com> > --- > tools/libxl/libxl_internal.c | 10 ++++++++++ > tools/libxl/libxl_internal.h | 1 + > 2 files changed, 11 insertions(+), 0 deletions(-) > > diff --git a/tools/libxl/libxl_internal.c b/tools/libxl/libxl_internal.c > index c4d54f9..0fb2315 100644 > --- a/tools/libxl/libxl_internal.c > +++ b/tools/libxl/libxl_internal.c > @@ -159,6 +159,16 @@ char *libxl__strdup(libxl__gc *gc, const char *c) > return s; > } > > +char *libxl__strndup(libxl__gc *gc, const char *c, size_t n) > +{ > + char *s = strndup(c, n); > + > + if (s) > + libxl__ptr_add(gc, s); > + > + return s; > +} > + > char *libxl__dirname(libxl__gc *gc, const char *s) > { > char *c; > diff --git a/tools/libxl/libxl_internal.h b/tools/libxl/libxl_internal.h > index 5d270bb..d873243 100644 > --- a/tools/libxl/libxl_internal.h > +++ b/tools/libxl/libxl_internal.h > @@ -148,6 +148,7 @@ _hidden void *libxl__calloc(libxl__gc *gc, size_t nmemb, size_t size); > _hidden void *libxl__realloc(libxl__gc *gc, void *ptr, size_t new_size); > _hidden char *libxl__sprintf(libxl__gc *gc, const char *fmt, ...) PRINTF_ATTRIBUTE(2, 3); > _hidden char *libxl__strdup(libxl__gc *gc, const char *c); > +_hidden char *libxl__strndup(libxl__gc *gc, const char *c, size_t n); > _hidden char *libxl__dirname(libxl__gc *gc, const char *s); > > _hidden char **libxl__xs_kvs_of_flexarray(libxl__gc *gc, flexarray_t *array, int length); _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel From xen-devel-bounces@lists.xensource.com Wed Sep 21 06:41:59 2011 Return-path: <xen-devel-bounces@lists.xensource.com> Envelope-to: www-data@lists.xensource.com Delivery-date: Wed, 21 Sep 2011 06:41:59 -0700 Received: from localhost ([127.0.0.1] helo=lists.colo.xensource.com) by lists.xensource.com with esmtp (Exim 4.43) id 1R6N3n-0003zq-7r; Wed, 21 Sep 2011 06:41:59 -0700 Received: from mail21.messagelabs.com ([85.158.143.35]) by lists.xensource.com with esmtp (Exim 4.43) id 1R6N3G-0003nj-O6 for xen-devel@lists.xensource.com; Wed, 21 Sep 2011 06:41:27 -0700 X-Env-Sender: keir.xen@gmail.com X-Msg-Ref: server-13.tower-21.messagelabs.com!1316612476!49779145!1 X-Originating-IP: [74.125.83.48] X-StarScan-Version: 6.4.1; banners=-,-,- X-VirusChecked: Checked Received: (qmail 15410 invoked from network); 21 Sep 2011 13:41:17 -0000 Received: from mail-gw0-f48.google.com (HELO mail-gw0-f48.google.com) (74.125.83.48) by server-13.tower-21.messagelabs.com with RC4-SHA encrypted SMTP; 21 Sep 2011 13:41:17 -0000 Received: by gwj22 with SMTP id 22so1589534gwj.7 for <xen-devel@lists.xensource.com>; Wed, 21 Sep 2011 06:41:22 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=user-agent:date:subject:from:to:cc:message-id:thread-topic :thread-index:in-reply-to:mime-version:content-type :content-transfer-encoding; bh=OshuPkXmA++Rr3kAJA+H8vnOWv5i/uuCJlD5y+0W0zw=; b=Qel8346+nDmJEqXZjiFF45p6PD4I8S+tfNWJ7Cd5yx4ZVA7AWEtg6d8bXj+2kTYu/G WFQSs2BfkKYS5ZuccbtobQPPVT/48gmCjCc/Rgc3TyXMlAQC4ob7h7IGJbw6dlwubazt RzGWQ7BldCk872E55+ypUCIR46KaAfEpPmNOU= Received: by 10.236.9.101 with SMTP id 65mr5577081yhs.11.1316612482405; Wed, 21 Sep 2011 06:41:22 -0700 (PDT) Received: from [10.255.255.36] ([96.49.135.17]) by mx.google.com with ESMTPS id o23sm6713810yhk.3.2011.09.21.06.41.15 (version=SSLv3 cipher=OTHER); Wed, 21 Sep 2011 06:41:19 -0700 (PDT) User-Agent: Microsoft-Entourage/12.30.0.110427 Date: Wed, 21 Sep 2011 06:41:09 -0700 Subject: Re: [Xen-devel] [PATCH 3/7] PCI multi-seg: adjust domctl interface From: Keir Fraser <keir.xen@gmail.com> To: Jan Beulich <JBeulich@suse.com>, Ian Jackson <Ian.Jackson@eu.citrix.com> Message-ID: <CA9F3785.212F3%keir.xen@gmail.com> Thread-Topic: [Xen-devel] [PATCH 3/7] PCI multi-seg: adjust domctl interface Thread-Index: Acx4ZB514S0TS/mTgEmY7iRaaweA+g== In-Reply-To: <4E79FE5802000078000570E0@nat28.tlf.novell.com> Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>, Stefano Stabellini <stefano.stabellini@eu.citrix.com> X-BeenThere: xen-devel@lists.xensource.com X-Mailman-Version: 2.1.5 Precedence: list List-Id: Xen developer discussion <xen-devel.lists.xensource.com> List-Unsubscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe> List-Post: <mailto:xen-devel@lists.xensource.com> List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help> List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=subscribe> Sender: xen-devel-bounces@lists.xensource.com Errors-To: xen-devel-bounces@lists.xensource.com On 21/09/2011 06:10, "Jan Beulich" <JBeulich@suse.com> wrote: >>>> On 21.09.11 at 14:42, Stefano Stabellini <stefano.stabellini@eu.citrix.com> > wrote: >> On Wed, 21 Sep 2011, Keir Fraser wrote: >>> On 20/09/2011 08:18, "Jan Beulich" <JBeulich@suse.com> wrote: >>> >>>> Again, a couple of directly related functions at once get adjusted to >>>> account for the segment number. >>>> >>>> Do we need to bump XEN_DOMCTL_INTERFACE_VERSION for the changes to the >>>> domctl interface (namely the renaming and bit-reassigment of the >>>> machine_bdf member of two of the interface structures)? If so, this >>>> can probably be done as the patch gets checked in (rather than me >>>> having to re-submit)? >>> >>> Ian suggests we should keep compatibility with old qemu versions. Are any of >>> these hypercall commands used by qemu? >>> >> >> Before b4bb8b3f09d1c873f522f6aebe1f125a6d1854d0 xc_assign_device and >> xc_deassign_device were called by qemu. Now they are called by libxl. > > Ian, Keir - what does that mean for my changes then? Do I need to > re-spin them? Do I need to even introduce new domctl structures? Or > just up the interface version (given that retaining compatibility with > old qemu will be impossible anyway the first time the interface version > gets changed, unless "old qemu" simply means > git://xenbits.xensource.com/qemu-xen-unstable.git rather than my > understanding of old, already built binaries)? I don't know that old qemu compat matters until we are wanting to support builds of upstream qemu. I'm not sure we are even quite there yet. So far, all our 'old qemus' are tied to a specific hypervisor version. So I'm not sure we have a problem, and probably your patch is fine. -- Keir > Jan > _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel From xen-devel-bounces@lists.xensource.com Wed Sep 21 06:42:46 2011 Return-path: <xen-devel-bounces@lists.xensource.com> Envelope-to: www-data@lists.xensource.com Delivery-date: Wed, 21 Sep 2011 06:42:46 -0700 Received: from localhost ([127.0.0.1] helo=lists.colo.xensource.com) by lists.xensource.com with esmtp (Exim 4.43) id 1R6N4Y-0004MP-Ik; Wed, 21 Sep 2011 06:42:46 -0700 Received: from mail21.messagelabs.com ([85.158.143.35]) by lists.xensource.com with esmtp (Exim 4.43) id 1R6N3U-0003r2-BC for xen-devel@lists.xensource.com; Wed, 21 Sep 2011 06:41:40 -0700 X-Env-Sender: keir.xen@gmail.com X-Msg-Ref: server-13.tower-21.messagelabs.com!1316612476!49779145!2 X-Originating-IP: [74.125.83.48] X-StarScan-Version: 6.4.1; banners=-,-,- X-VirusChecked: Checked Received: (qmail 16199 invoked from network); 21 Sep 2011 13:41:31 -0000 Received: from mail-gw0-f48.google.com (HELO mail-gw0-f48.google.com) (74.125.83.48) by server-13.tower-21.messagelabs.com with RC4-SHA encrypted SMTP; 21 Sep 2011 13:41:31 -0000 Received: by mail-gw0-f48.google.com with SMTP id 22so1589534gwj.7 for <xen-devel@lists.xensource.com>; Wed, 21 Sep 2011 06:41:37 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=user-agent:date:subject:from:to:message-id:thread-topic :thread-index:in-reply-to:mime-version:content-type :content-transfer-encoding; bh=xZqgtKx2m2gXuwNiNpyfe9lx2bAXBTh99Cmuo6z1Dns=; b=SvoGbBEQv53iYDN7CWpkob91qfLKY5lo+P/ABavtfWKy50zn2AVPnWy+Zuux2kVZGU vpwct3kAZF192ZV4or10oei2MssWL/G0dDmLU4tdV6fupwUH+I8/dSV1VcTeaP1yszSX IZ3RnXUA8gk2eeCbLzTNbo+Ijg+uFzMfmTVBA= Received: by 10.151.112.1 with SMTP id p1mr960922ybm.262.1316612496989; Wed, 21 Sep 2011 06:41:36 -0700 (PDT) Received: from [10.255.255.36] ([96.49.135.17]) by mx.google.com with ESMTPS id s19sm21277650anm.20.2011.09.21.06.41.33 (version=SSLv3 cipher=OTHER); Wed, 21 Sep 2011 06:41:35 -0700 (PDT) User-Agent: Microsoft-Entourage/12.30.0.110427 Date: Wed, 21 Sep 2011 06:41:29 -0700 Subject: Re: [Xen-devel] xzalloc() & Co? From: Keir Fraser <keir.xen@gmail.com> To: Jan Beulich <JBeulich@suse.com>, "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com> Message-ID: <CA9F3799.212F4%keir.xen@gmail.com> Thread-Topic: [Xen-devel] xzalloc() & Co? Thread-Index: Acx4ZCph/k8TWpEMbEqDcjkvTnTLIg== In-Reply-To: <4E79AF630200007800056F80@nat28.tlf.novell.com> Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit Cc: X-BeenThere: xen-devel@lists.xensource.com X-Mailman-Version: 2.1.5 Precedence: list List-Id: Xen developer discussion <xen-devel.lists.xensource.com> List-Unsubscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe> List-Post: <mailto:xen-devel@lists.xensource.com> List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help> List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=subscribe> Sender: xen-devel-bounces@lists.xensource.com Errors-To: xen-devel-bounces@lists.xensource.com On 21/09/2011 00:33, "Jan Beulich" <JBeulich@suse.com> wrote: > While I seem to recall that this idea was rejected a couple of years back, > shouldn't we re-think and follow e.g. Linux in having zeroing variants of > xmalloc() & Co? That would not only reduce code size, but also eliminate > one source of potential bugs (see e.g. the thread starting at > http://marc.info/?l=kernel-janitors&m=131615631720174&w=2). I don't know why we'd have rejected the idea. It sounds fine to me. -- Keir > Jan > > > _______________________________________________ > Xen-devel mailing list > Xen-devel@lists.xensource.com > http://lists.xensource.com/xen-devel _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel From xen-devel-bounces@lists.xensource.com Wed Sep 21 06:45:26 2011 Return-path: <xen-devel-bounces@lists.xensource.com> Envelope-to: www-data@lists.xensource.com Delivery-date: Wed, 21 Sep 2011 06:45:26 -0700 Received: from localhost ([127.0.0.1] helo=lists.colo.xensource.com) by lists.xensource.com with esmtp (Exim 4.43) id 1R6N77-0004kn-PF; Wed, 21 Sep 2011 06:45:25 -0700 Received: from mail21.messagelabs.com ([85.158.143.35]) by lists.xensource.com with esmtp (Exim 4.43) id 1R6N60-0004Xw-Of for xen-devel@lists.xensource.com; Wed, 21 Sep 2011 06:44:17 -0700 X-Env-Sender: javier.manzano@edu.uah.es X-Msg-Ref: server-14.tower-21.messagelabs.com!1316612644!60432239!1 X-Originating-IP: [216.139.236.26] X-StarScan-Version: 6.4.1; banners=-,-,- X-VirusChecked: Checked Received: (qmail 22135 invoked from network); 21 Sep 2011 13:44:05 -0000 Received: from sam.nabble.com (HELO sam.nabble.com) (216.139.236.26) by server-14.tower-21.messagelabs.com with AES256-SHA encrypted SMTP; 21 Sep 2011 13:44:05 -0000 Received: from [192.168.236.26] (helo=sam.nabble.com) by sam.nabble.com with esmtp (Exim 4.72) (envelope-from <javier.manzano@edu.uah.es>) id 1R6N5w-0000H9-4X for xen-devel@lists.xensource.com; Wed, 21 Sep 2011 06:44:12 -0700 Date: Wed, 21 Sep 2011 06:44:12 -0700 (PDT) From: JavMV <javier.manzano@edu.uah.es> To: xen-devel@lists.xensource.com Message-ID: <1316612652132-4826391.post@n5.nabble.com> In-Reply-To: <1315405921936-4778727.post@n5.nabble.com> References: <1315231341254-4770602.post@n5.nabble.com> <1315310225039-4774097.post@n5.nabble.com> <1315343879.61837.YahooMailNeo@web29818.mail.ird.yahoo.com> <1315382742268-4777689.post@n5.nabble.com> <1315389138.56652.YahooMailNeo@web29801.mail.ird.yahoo.com> <1315398360680-4778339.post@n5.nabble.com> <1315401901083-4778494.post@n5.nabble.com> <1315403644525-4778586.post@n5.nabble.com> <1315405372.87224.YahooMailNeo@web29801.mail.ird.yahoo.com> <1315405921936-4778727.post@n5.nabble.com> Subject: Re: Re : Re : Re : [Xen-devel] Re: Patches for VGA-Passthrough XEN 4.2 unstable MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-BeenThere: xen-devel@lists.xensource.com X-Mailman-Version: 2.1.5 Precedence: list List-Id: Xen developer discussion <xen-devel.lists.xensource.com> List-Unsubscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe> List-Post: <mailto:xen-devel@lists.xensource.com> List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help> List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=subscribe> Sender: xen-devel-bounces@lists.xensource.com Errors-To: xen-devel-bounces@lists.xensource.com Hi again, Im back on this issues ^^. I have tryed to replicate the same situation that u tested for me Komkom (thanks again) but Im having problems to get Xen working properly... I have written all the install process that I followed on this thread http://xen.1045712.n5.nabble.com/Problems-starting-xend-on-Squeeze-td4271295.html#a4826038 http://xen.1045712.n5.nabble.com/Problems-starting-xend-on-Squeeze-td4271295.html#a4826038 (I have used the David's tutorial to download the xen code 'hg clone -r 23350 http://xenbits.xensource.com/hg/staging/xen-unstable.hg/ xen_rev23350') Can you tell me how did you proceed to get Xen running with this configuration?: komkon555 wrote: > > xen 4.2-unstable changeset 23350 (clearly patched) + jeremi xen kernel > 2.6.32.43/45 (xenfs static) on debian squeeze. > Best Regards > Komkon555 > komkon555 wrote: > > Hi. There is the promised report to JavMV: with fixes on dsd are your > patches also functional. Windows XP starts and GTX260 works perfect with > driver version 275.33. > Can anyone help me with this problem? If I fix it I will be able to try the patches on my graphic card (GTX 460) and maybe it will work like in this video : http://www.youtube.com/watch?v=Gtmwnx-k2qg http://www.youtube.com/watch?v=Gtmwnx-k2qg Thanks in advance Javier ----- JavMV -- View this message in context: http://xen.1045712.n5.nabble.com/Patches-for-VGA-Passthrough-XEN-4-2-unstable-tp4406265p4826391.html Sent from the Xen - Dev mailing list archive at Nabble.com. _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel From xen-devel-bounces@lists.xensource.com Wed Sep 21 06:46:41 2011 Return-path: <xen-devel-bounces@lists.xensource.com> Envelope-to: www-data@lists.xensource.com Delivery-date: Wed, 21 Sep 2011 06:46:41 -0700 Received: from localhost ([127.0.0.1] helo=lists.colo.xensource.com) by lists.xensource.com with esmtp (Exim 4.43) id 1R6N8K-00057Q-DO; Wed, 21 Sep 2011 06:46:40 -0700 Received: from mail21.messagelabs.com ([85.158.143.35]) by lists.xensource.com with esmtp (Exim 4.43) id 1R6N6a-0004c7-KU for xen-devel@lists.xensource.com; Wed, 21 Sep 2011 06:44:54 -0700 X-Env-Sender: Ian.Campbell@eu.citrix.com X-Msg-Ref: server-15.tower-21.messagelabs.com!1316612690!51437038!1 X-Originating-IP: [62.200.22.115] X-StarScan-Version: 6.4.1; banners=-,-,- X-VirusChecked: Checked Received: (qmail 31170 invoked from network); 21 Sep 2011 13:44:51 -0000 Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115) by server-15.tower-21.messagelabs.com with RC4-SHA encrypted SMTP; 21 Sep 2011 13:44:51 -0000 X-IronPort-AV: E=Sophos;i="4.68,417,1312156800"; d="scan'208";a="7981137" Received: from lonpmailmx01.citrite.net ([10.30.203.162]) by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5; 21 Sep 2011 13:44:49 +0000 Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net (10.30.203.162) with Microsoft SMTP Server id 8.3.137.0; Wed, 21 Sep 2011 14:44:49 +0100 From: Ian Campbell <Ian.Campbell@eu.citrix.com> To: Daniel De Graaf <dgdegra@tycho.nsa.gov> Date: Wed, 21 Sep 2011 14:44:48 +0100 In-Reply-To: <1316472208-12104-4-git-send-email-dgdegra@tycho.nsa.gov> References: <1313764724-12683-1-git-send-email-dgdegra@tycho.nsa.gov> <1316472208-12104-1-git-send-email-dgdegra@tycho.nsa.gov> <1316472208-12104-4-git-send-email-dgdegra@tycho.nsa.gov> Organization: Citrix Systems, Inc. Content-Type: text/plain; charset="UTF-8" X-Mailer: Evolution 3.0.3- Content-Transfer-Encoding: 7bit Message-ID: <1316612688.3891.194.camel@zakaz.uk.xensource.com> MIME-Version: 1.0 Cc: Stefano Stabellini <Stefano.Stabellini@eu.citrix.com>, "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>, Ian Jackson <Ian.Jackson@eu.citrix.com>, "konrad.wilk@oracle.com" <konrad.wilk@oracle.com> Subject: [Xen-devel] Re: [PATCH 3/3] libvchan: interdomain communications library X-BeenThere: xen-devel@lists.xensource.com X-Mailman-Version: 2.1.5 Precedence: list List-Id: Xen developer discussion <xen-devel.lists.xensource.com> List-Unsubscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe> List-Post: <mailto:xen-devel@lists.xensource.com> List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help> List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=subscribe> Sender: xen-devel-bounces@lists.xensource.com Errors-To: xen-devel-bounces@lists.xensource.com On Mon, 2011-09-19 at 23:43 +0100, Daniel De Graaf wrote: > + * This library is free software; you can redistribute it and/or > + * modify it under the terms of the GNU Lesser General Public > + * License as published by the Free Software Foundation; either > + * version 2 of the License, or (at your option) any later version. LGPL v2 isn't all that widely used (I had some flaw or other which I don't recall and have failed to google up). Most of our libraries are LGPL v2.1 not v2 as well. Since you have the "or later version" clause I think it should be trivial to uprev? (by the same token it perhaps doesn't matter, but fewer licenses in use at once seems useful) Ian. > + * > + * This library is distributed in the hope that it will be useful, > + * but WITHOUT ANY WARRANTY; without even the implied warranty of > + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU > + * Lesser General Public License for more details. > + * > + * You should have received a copy of the GNU Lesser General Public > + * License along with this library; if not, write to the Free Software > + * Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston, MA 02110-1301 USA > + * > + * @section DESCRIPTION > + * > + * This file contains the setup code used to establish the ring buffer. > + */ > + > +#include <sys/types.h> > +#include <sys/mman.h> > +#include <sys/ioctl.h> > +#include <sys/user.h> > +#include <stdlib.h> > +#include <stdio.h> > +#include <stdint.h> > +#include <string.h> > +#include <unistd.h> > +#include <fcntl.h> > + > +#include <xs.h> > +#include <xen/sys/evtchn.h> > +#include <xen/sys/gntalloc.h> > +#include <xen/sys/gntdev.h> > +#include <libxenvchan.h> > + > +#ifndef PAGE_SHIFT > +#define PAGE_SHIFT 12 > +#endif > + > +#ifndef PAGE_SIZE > +#define PAGE_SIZE 4096 > +#endif > + > +#ifndef offsetof > +#define offsetof(TYPE, MEMBER) ((size_t) &((TYPE *)0)->MEMBER) > +#endif > + > +#define max(a,b) ((a > b) ? a : b) > + > +static int init_gnt_srv(struct libvchan *ctrl) > +{ > + int pages_left = ctrl->read.order >= PAGE_SHIFT ? 1 << (ctrl->read.order - PAGE_SHIFT) : 0; > + int pages_right = ctrl->write.order >= PAGE_SHIFT ? 1 << (ctrl->write.order - PAGE_SHIFT) : 0; > + uint32_t ring_ref = -1; > + void *ring; > + > + ring = xc_gntshr_share_page_notify(ctrl->gntshr, ctrl->other_domain_id, > + &ring_ref, 1, offsetof(struct vchan_interface, srv_live), > + ctrl->event_port, NULL); > + > + if (!ring) > + goto out; > + > + memset(ring, 0, PAGE_SIZE); > + > + ctrl->ring = ring; > + ctrl->read.shr = &ctrl->ring->left; > + ctrl->write.shr = &ctrl->ring->right; > + ctrl->ring->left_order = ctrl->read.order; > + ctrl->ring->right_order = ctrl->write.order; > + ctrl->ring->cli_live = 2; > + ctrl->ring->srv_live = 1; > + ctrl->ring->cli_notify = VCHAN_NOTIFY_WRITE; > + > + if (ctrl->read.order == 10) { > + ctrl->read.buffer = ((void*)ctrl->ring) + 1024; > + } else if (ctrl->read.order == 11) { > + ctrl->read.buffer = ((void*)ctrl->ring) + 2048; > + } else { > + ctrl->read.buffer = xc_gntshr_share_pages(ctrl->gntshr, ctrl->other_domain_id, > + pages_left, ctrl->ring->grants, 1); > + if (!ctrl->read.buffer) > + goto out_ring; > + } > + > + if (ctrl->write.order == 10) { > + ctrl->write.buffer = ((void*)ctrl->ring) + 1024; > + } else if (ctrl->write.order == 11) { > + ctrl->write.buffer = ((void*)ctrl->ring) + 2048; > + } else { > + ctrl->write.buffer = xc_gntshr_share_pages(ctrl->gntshr, ctrl->other_domain_id, > + pages_right, ctrl->ring->grants + pages_left, 1); > + if (!ctrl->write.buffer) > + goto out_unmap_left; > + } > + > +out: > + return ring_ref; > +out_unmap_left: > + if (ctrl->read.order > 11) > + xc_gntshr_munmap(ctrl->gntshr, ctrl->read.buffer, pages_left * PAGE_SIZE); > +out_ring: > + xc_gntshr_munmap(ctrl->gntshr, ring, PAGE_SIZE); > + ring_ref = -1; > + ctrl->ring = NULL; > + ctrl->write.order = ctrl->read.order = 0; > + goto out; > +} > + > +static int init_gnt_cli(struct libvchan *ctrl, uint32_t ring_ref) > +{ > + int rv = -1; > + uint32_t *grants; > + > + ctrl->ring = xc_gnttab_map_grant_ref_notify(ctrl->gnttab, > + ctrl->other_domain_id, ring_ref, > + offsetof(struct vchan_interface, cli_live), ctrl->event_port, > + NULL); > + > + if (!ctrl->ring) > + goto out; > + > + ctrl->write.order = ctrl->ring->left_order; > + ctrl->read.order = ctrl->ring->right_order; > + ctrl->write.shr = &ctrl->ring->left; > + ctrl->read.shr = &ctrl->ring->right; > + if (ctrl->write.order < 10 || ctrl->write.order > 24) > + goto out_unmap_ring; > + if (ctrl->read.order < 10 || ctrl->read.order > 24) > + goto out_unmap_ring; > + if (ctrl->read.order == ctrl->write.order && ctrl->read.order < 12) > + goto out_unmap_ring; > + > + grants = ctrl->ring->grants; > + > + if (ctrl->write.order == 10) { > + ctrl->write.buffer = ((void*)ctrl->ring) + 1024; > + } else if (ctrl->write.order == 11) { > + ctrl->write.buffer = ((void*)ctrl->ring) + 2048; > + } else { > + int pages_left = 1 << (ctrl->write.order - PAGE_SHIFT); > + ctrl->write.buffer = xc_gnttab_map_domain_grant_refs(ctrl->gnttab, > + pages_left, ctrl->other_domain_id, grants, PROT_READ|PROT_WRITE); > + if (!ctrl->write.buffer) > + goto out_unmap_ring; > + grants += pages_left; > + } > + > + if (ctrl->read.order == 10) { > + ctrl->read.buffer = ((void*)ctrl->ring) + 1024; > + } else if (ctrl->read.order == 11) { > + ctrl->read.buffer = ((void*)ctrl->ring) + 2048; > + } else { > + int pages_right = 1 << (ctrl->read.order - PAGE_SHIFT); > + ctrl->read.buffer = xc_gnttab_map_domain_grant_refs(ctrl->gnttab, > + pages_right, ctrl->other_domain_id, grants, PROT_READ); > + if (!ctrl->read.buffer) > + goto out_unmap_left; > + } > + > + rv = 0; > + out: > + return rv; > + out_unmap_left: > + if (ctrl->write.order >= PAGE_SHIFT) > + xc_gnttab_munmap(ctrl->gnttab, ctrl->write.buffer, > + 1 << ctrl->write.order); > + out_unmap_ring: > + xc_gnttab_munmap(ctrl->gnttab, ctrl->ring, PAGE_SIZE); > + ctrl->ring = 0; > + ctrl->write.order = ctrl->read.order = 0; > + rv = -1; > + goto out; > +} > + > +static int init_evt_srv(struct libvchan *ctrl, xentoollog_logger *logger) > +{ > + ctrl->event = xc_evtchn_open(logger, 0); > + if (!ctrl->event) > + return -1; > + ctrl->event_port = xc_evtchn_bind_unbound_port(ctrl->event, ctrl->other_domain_id); > + if (ctrl->event_port < 0) > + return -1; > + if (xc_evtchn_unmask(ctrl->event, ctrl->event_port)) > + return -1; > + return 0; > +} > + > +static int init_xs_srv(struct libvchan *ctrl, int ring_ref) > +{ > + int ret = -1; > + struct xs_handle *xs; > + struct xs_permissions perms[2]; > + char buf[64]; > + char ref[16]; > + char* domid_str = NULL; > + xs = xs_domain_open(); > + if (!xs) > + goto fail; > + domid_str = xs_read(xs, 0, "domid", NULL); > + if (!domid_str) > + goto fail_xs_open; > + > + // owner domain is us > + perms[0].id = atoi(domid_str); > + // permissions for domains not listed = none > + perms[0].perms = XS_PERM_NONE; > + // other domains > + perms[1].id = ctrl->other_domain_id; > + perms[1].perms = XS_PERM_READ; > + > + snprintf(ref, sizeof ref, "%d", ring_ref); > + snprintf(buf, sizeof buf, "data/vchan/%d/%d/ring-ref", ctrl->other_domain_id, ctrl->device_number); > + if (!xs_write(xs, 0, buf, ref, strlen(ref))) > + goto fail_xs_open; > + if (!xs_set_permissions(xs, 0, buf, perms, 2)) > + goto fail_xs_open; > + > + snprintf(ref, sizeof ref, "%d", ctrl->event_port); > + snprintf(buf, sizeof buf, "data/vchan/%d/%d/event-channel", ctrl->other_domain_id, ctrl->device_number); > + if (!xs_write(xs, 0, buf, ref, strlen(ref))) > + goto fail_xs_open; > + if (!xs_set_permissions(xs, 0, buf, perms, 2)) > + goto fail_xs_open; > + > + ret = 0; > + fail_xs_open: > + free(domid_str); > + xs_daemon_close(xs); > + fail: > + return ret; > +} > + > +static int min_order(size_t siz) > +{ > + int rv = PAGE_SHIFT; > + while (siz > (1 << rv)) > + rv++; > + return rv; > +} > + > +struct libvchan *libvchan_server_init(xentoollog_logger *logger, int domain, int devno, size_t left_min, size_t right_min) > +{ > + // if you go over this size, you'll have too many grants to fit in the shared page. > + size_t MAX_RING_SIZE = 256 * PAGE_SIZE; > + struct libvchan *ctrl; > + int ring_ref; > + if (left_min > MAX_RING_SIZE || right_min > MAX_RING_SIZE) > + return 0; > + > + ctrl = malloc(sizeof(*ctrl)); > + if (!ctrl) > + return 0; > + > + ctrl->other_domain_id = domain; > + ctrl->device_number = devno; > + ctrl->ring = NULL; > + ctrl->event = NULL; > + ctrl->is_server = 1; > + ctrl->server_persist = 0; > + > + ctrl->read.order = min_order(left_min); > + ctrl->write.order = min_order(right_min); > + > + // if we can avoid allocating extra pages by using in-page rings, do so > +#define MAX_SMALL_RING 1024 > +#define MAX_LARGE_RING 2048 > + if (left_min <= MAX_SMALL_RING && right_min <= MAX_LARGE_RING) { > + ctrl->read.order = 10; > + ctrl->write.order = 11; > + } else if (left_min <= MAX_LARGE_RING && right_min <= MAX_SMALL_RING) { > + ctrl->read.order = 11; > + ctrl->write.order = 10; > + } else if (left_min <= MAX_LARGE_RING) { > + ctrl->read.order = 11; > + } else if (right_min <= MAX_LARGE_RING) { > + ctrl->write.order = 11; > + } > + > + ctrl->gntshr = xc_gntshr_open(logger, 0); > + if (!ctrl->gntshr) > + goto out; > + > + if (init_evt_srv(ctrl, logger)) > + goto out; > + ring_ref = init_gnt_srv(ctrl); > + if (ring_ref < 0) > + goto out; > + if (init_xs_srv(ctrl, ring_ref)) > + goto out; > + return ctrl; > +out: > + libvchan_close(ctrl); > + return 0; > +} > + > +static int init_evt_cli(struct libvchan *ctrl, xentoollog_logger *logger) > +{ > + ctrl->event = xc_evtchn_open(logger, 0); > + if (!ctrl->event) > + return -1; > + ctrl->event_port = xc_evtchn_bind_interdomain(ctrl->event, > + ctrl->other_domain_id, ctrl->event_port); > + if (ctrl->event_port < 0) > + return -1; > + xc_evtchn_unmask(ctrl->event, ctrl->event_port); > + return 0; > +} > + > + > +struct libvchan *libvchan_client_init(xentoollog_logger *logger, int domain, int devno) > +{ > + struct libvchan *ctrl = malloc(sizeof(struct libvchan)); > + struct xs_handle *xs = NULL; > + char buf[64]; > + char *ref; > + int ring_ref; > + unsigned int len; > + char* domid_str = NULL; > + > + if (!ctrl) > + return 0; > + ctrl->other_domain_id = domain; > + ctrl->device_number = devno; > + ctrl->ring = NULL; > + ctrl->event = NULL; > + ctrl->write.order = ctrl->read.order = 0; > + ctrl->is_server = 0; > + > + xs = xs_daemon_open(); > + if (!xs) > + xs = xs_domain_open(); > + if (!xs) > + goto fail; > + > + domid_str = xs_read(xs, 0, "domid", NULL); > + if (!domid_str) > + goto fail; > + > +// find xenstore entry > + snprintf(buf, sizeof buf, "/local/domain/%d/data/vchan/%s/%d/ring-ref", > + ctrl->other_domain_id, domid_str, ctrl->device_number); > + ref = xs_read(xs, 0, buf, &len); > + if (!ref) > + goto fail; > + ring_ref = atoi(ref); > + free(ref); > + if (!ring_ref) > + goto fail; > + snprintf(buf, sizeof buf, "/local/domain/%d/data/vchan/%s/%d/event-channel", > + ctrl->other_domain_id, domid_str, ctrl->device_number); > + ref = xs_read(xs, 0, buf, &len); > + if (!ref) > + goto fail; > + ctrl->event_port = atoi(ref); > + free(ref); > + if (!ctrl->event_port) > + goto fail; > + > + ctrl->gnttab = xc_gnttab_open(logger, 0); > + if (!ctrl->gnttab) > + goto out; > + > +// set up event channel > + if (init_evt_cli(ctrl, logger)) > + goto fail; > + > +// set up shared page(s) > + if (init_gnt_cli(ctrl, ring_ref)) > + goto fail; > + > + ctrl->ring->cli_live = 1; > + ctrl->ring->srv_notify = VCHAN_NOTIFY_WRITE; > + > + out: > + free(domid_str); > + if (xs) > + xs_daemon_close(xs); > + return ctrl; > + fail: > + libvchan_close(ctrl); > + ctrl = NULL; > + goto out; > +} > diff --git a/tools/libvchan/io.c b/tools/libvchan/io.c > new file mode 100644 > index 0000000..08d5dcf > --- /dev/null > +++ b/tools/libvchan/io.c > @@ -0,0 +1,375 @@ > +/** > + * @file > + * @section AUTHORS > + * > + * Copyright (C) 2010 Rafal Wojtczuk <rafal@invisiblethingslab.com> > + * > + * Authors: > + * Rafal Wojtczuk <rafal@invisiblethingslab.com> > + * Daniel De Graaf <dgdegra@tycho.nsa.gov> > + * > + * @section LICENSE > + * > + * This library is free software; you can redistribute it and/or > + * modify it under the terms of the GNU Lesser General Public > + * License as published by the Free Software Foundation; either > + * version 2 of the License, or (at your option) any later version. > + * > + * This library is distributed in the hope that it will be useful, > + * but WITHOUT ANY WARRANTY; without even the implied warranty of > + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU > + * Lesser General Public License for more details. > + * > + * You should have received a copy of the GNU Lesser General Public > + * License along with this library; if not, write to the Free Software > + * Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston, MA 02110-1301 USA > + * > + * @section DESCRIPTION > + * > + * This file contains the communications interface built on the ring buffer. > + */ > + > +#include <sys/types.h> > +#include <sys/mman.h> > +#include <sys/ioctl.h> > +#include <sys/uio.h> > +#include <stdlib.h> > +#include <stdint.h> > +#include <string.h> > +#include <unistd.h> > + > +#include <xenctrl.h> > +#include <libxenvchan.h> > + > +#ifndef PAGE_SHIFT > +#define PAGE_SHIFT 12 > +#endif > + > +#ifndef PAGE_SIZE > +#define PAGE_SIZE 4096 > +#endif > + > +// allow vchan data to be easily observed in strace by doing a > +// writev() to FD -1 with the data being read/written. > +#ifndef VCHAN_DEBUG > +#define VCHAN_DEBUG 0 > +#endif > + > +#define barrier() asm volatile("" ::: "memory") > + > + > +static inline uint32_t rd_prod(struct libvchan *ctrl) > +{ > + return ctrl->read.shr->prod; > +} > + > +static inline uint32_t* _rd_cons(struct libvchan *ctrl) > +{ > + return &ctrl->read.shr->cons; > +} > +#define rd_cons(x) (*_rd_cons(x)) > + > +static inline uint32_t* _wr_prod(struct libvchan *ctrl) > +{ > + return &ctrl->write.shr->prod; > +} > +#define wr_prod(x) (*_wr_prod(x)) > + > +static inline uint32_t wr_cons(struct libvchan *ctrl) > +{ > + return ctrl->write.shr->cons; > +} > + > +static inline const void* rd_ring(struct libvchan *ctrl) > +{ > + return ctrl->read.buffer; > +} > + > +static inline void* wr_ring(struct libvchan *ctrl) > +{ > + return ctrl->write.buffer; > +} > + > +static inline uint32_t wr_ring_size(struct libvchan *ctrl) > +{ > + return (1 << ctrl->write.order); > +} > + > +static inline uint32_t rd_ring_size(struct libvchan *ctrl) > +{ > + return (1 << ctrl->read.order); > +} > + > +static inline void request_notify(struct libvchan *ctrl, uint8_t bit) > +{ > + uint8_t *notify = ctrl->is_server ? &ctrl->ring->cli_notify : &ctrl->ring->srv_notify; > + __sync_or_and_fetch(notify, bit); > +} > + > +static inline int send_notify(struct libvchan *ctrl, uint8_t bit) > +{ > + uint8_t *notify = ctrl->is_server ? &ctrl->ring->srv_notify : &ctrl->ring->cli_notify; > + uint8_t prev = __sync_fetch_and_and(notify, ~bit); > + if (prev & bit) > + return xc_evtchn_notify(ctrl->event, ctrl->event_port); > + else > + return 0; > +} > + > +/** > + * Get the amount of buffer space available and enable notifications if needed. > + */ > +static inline int fast_get_data_ready(struct libvchan *ctrl, size_t request) > +{ > + int ready = rd_prod(ctrl) - rd_cons(ctrl); > + if (ready >= request) > + return ready; > + /* We plan to consume all data; please tell us if you send more */ > + request_notify(ctrl, VCHAN_NOTIFY_WRITE); > + /* > + * If the writer moved rd_prod after our read but before request, we > + * will not get notified even though the actual amount of data ready is > + * above request. Reread rd_prod to cover this case. > + */ > + return rd_prod(ctrl) - rd_cons(ctrl); > +} > + > +int libvchan_data_ready(struct libvchan *ctrl) > +{ > + /* Since this value is being used outside libvchan, request notification > + * when it changes > + */ > + request_notify(ctrl, VCHAN_NOTIFY_WRITE); > + return rd_prod(ctrl) - rd_cons(ctrl); > +} > + > +/** > + * Get the amount of buffer space available and enable notifications if needed. > + */ > +static inline int fast_get_buffer_space(struct libvchan *ctrl, size_t request) > +{ > + int ready = wr_ring_size(ctrl) - (wr_prod(ctrl) - wr_cons(ctrl)); > + if (ready >= request) > + return ready; > + /* We plan to fill the buffer; please tell us when you've read it */ > + request_notify(ctrl, VCHAN_NOTIFY_READ); > + /* > + * If the reader moved wr_cons after our read but before request, we > + * will not get notified even though the actual amount of buffer space > + * is above request. Reread wr_cons to cover this case. > + */ > + return wr_ring_size(ctrl) - (wr_prod(ctrl) - wr_cons(ctrl)); > +} > + > +int libvchan_buffer_space(struct libvchan *ctrl) > +{ > + /* Since this value is being used outside libvchan, request notification > + * when it changes > + */ > + request_notify(ctrl, VCHAN_NOTIFY_READ); > + return wr_ring_size(ctrl) - (wr_prod(ctrl) - wr_cons(ctrl)); > +} > + > +int libvchan_wait(struct libvchan *ctrl) > +{ > + int ret = xc_evtchn_pending(ctrl->event); > + if (ret < 0) > + return -1; > + xc_evtchn_unmask(ctrl->event, ret); > + return 0; > +} > + > +/** > + * returns -1 on error, or size on success > + */ > +static int do_send(struct libvchan *ctrl, const void *data, size_t size) > +{ > + int real_idx = wr_prod(ctrl) & (wr_ring_size(ctrl) - 1); > + int avail_contig = wr_ring_size(ctrl) - real_idx; > + if (VCHAN_DEBUG) { > + char metainfo[32]; > + struct iovec iov[2]; > + iov[0].iov_base = metainfo; > + iov[0].iov_len = snprintf(metainfo, 32, "vchan wr %d/%d", ctrl->other_domain_id, ctrl->device_number); > + iov[1].iov_base = (void *)data; > + iov[1].iov_len = size; > + writev(-1, iov, 2); > + } > + if (avail_contig > size) > + avail_contig = size; > + memcpy(wr_ring(ctrl) + real_idx, data, avail_contig); > + if (avail_contig < size) > + { > + // we rolled across the end of the ring > + memcpy(wr_ring(ctrl), data + avail_contig, size - avail_contig); > + } > + barrier(); // data must be in the ring prior to increment > + wr_prod(ctrl) += size; > + barrier(); // increment must happen prior to notify > + if (send_notify(ctrl, VCHAN_NOTIFY_WRITE)) > + return -1; > + return size; > +} > + > +/** > + * returns 0 if no buffer space is available, -1 on error, or size on success > + */ > +int libvchan_send(struct libvchan *ctrl, const void *data, size_t size) > +{ > + int avail; > + while (1) { > + if (!libvchan_is_open(ctrl)) > + return -1; > + avail = fast_get_buffer_space(ctrl, size); > + if (size <= avail) > + return do_send(ctrl, data, size); > + if (!ctrl->blocking) > + return 0; > + if (size > wr_ring_size(ctrl)) > + return -1; > + if (libvchan_wait(ctrl)) > + return -1; > + } > +} > + > +int libvchan_write(struct libvchan *ctrl, const void *data, size_t size) > +{ > + int avail; > + if (!libvchan_is_open(ctrl)) > + return -1; > + if (ctrl->blocking) { > + size_t pos = 0; > + while (1) { > + avail = fast_get_buffer_space(ctrl, size - pos); > + if (pos + avail > size) > + avail = size - pos; > + if (avail) > + pos += do_send(ctrl, data + pos, avail); > + if (pos == size) > + return pos; > + if (libvchan_wait(ctrl)) > + return -1; > + if (!libvchan_is_open(ctrl)) > + return -1; > + } > + } else { > + avail = fast_get_buffer_space(ctrl, size); > + if (size > avail) > + size = avail; > + if (size == 0) > + return 0; > + return do_send(ctrl, data, size); > + } > +} > + > +static int do_recv(struct libvchan *ctrl, void *data, size_t size) > +{ > + int real_idx = rd_cons(ctrl) & (rd_ring_size(ctrl) - 1); > + int avail_contig = rd_ring_size(ctrl) - real_idx; > + if (avail_contig > size) > + avail_contig = size; > + barrier(); // data read must happen after rd_cons read > + memcpy(data, rd_ring(ctrl) + real_idx, avail_contig); > + if (avail_contig < size) > + { > + // we rolled across the end of the ring > + memcpy(data + avail_contig, rd_ring(ctrl), size - avail_contig); > + } > + rd_cons(ctrl) += size; > + if (VCHAN_DEBUG) { > + char metainfo[32]; > + struct iovec iov[2]; > + iov[0].iov_base = metainfo; > + iov[0].iov_len = snprintf(metainfo, 32, "vchan rd %d/%d", ctrl->other_domain_id, ctrl->device_number); > + iov[1].iov_base = data; > + iov[1].iov_len = size; > + writev(-1, iov, 2); > + } > + barrier(); // consumption must happen prior to notify of newly freed space > + if (send_notify(ctrl, VCHAN_NOTIFY_READ)) > + return -1; > + return size; > +} > + > +/** > + * reads exactly size bytes from the vchan. > + * returns 0 if insufficient data is available, -1 on error, or size on success > + */ > +int libvchan_recv(struct libvchan *ctrl, void *data, size_t size) > +{ > + while (1) { > + int avail = fast_get_data_ready(ctrl, size); > + if (size <= avail) > + return do_recv(ctrl, data, size); > + if (!libvchan_is_open(ctrl)) > + return -1; > + if (!ctrl->blocking) > + return 0; > + if (size > rd_ring_size(ctrl)) > + return -1; > + if (libvchan_wait(ctrl)) > + return -1; > + } > +} > + > +int libvchan_read(struct libvchan *ctrl, void *data, size_t size) > +{ > + while (1) { > + int avail = fast_get_data_ready(ctrl, size); > + if (avail && size > avail) > + size = avail; > + if (avail) > + return do_recv(ctrl, data, size); > + if (!libvchan_is_open(ctrl)) > + return -1; > + if (!ctrl->blocking) > + return 0; > + if (libvchan_wait(ctrl)) > + return -1; > + } > +} > + > +int libvchan_is_open(struct libvchan* ctrl) > +{ > + if (ctrl->is_server) > + return ctrl->server_persist ? 1 : ctrl->ring->cli_live; > + else > + return ctrl->ring->srv_live; > +} > + > +int libvchan_fd_for_select(struct libvchan *ctrl) > +{ > + return xc_evtchn_fd(ctrl->event); > +} > + > +void libvchan_close(struct libvchan *ctrl) > +{ > + if (!ctrl) > + return; > + if (ctrl->read.order >= PAGE_SHIFT) > + munmap(ctrl->read.buffer, 1 << ctrl->read.order); > + if (ctrl->write.order >= PAGE_SHIFT) > + munmap(ctrl->write.buffer, 1 << ctrl->write.order); > + if (ctrl->ring) { > + if (ctrl->is_server) { > + ctrl->ring->srv_live = 0; > + xc_gntshr_munmap(ctrl->gntshr, ctrl->ring, PAGE_SIZE); > + } else { > + ctrl->ring->cli_live = 0; > + xc_gnttab_munmap(ctrl->gnttab, ctrl->ring, PAGE_SIZE); > + } > + } > + if (ctrl->event) { > + if (ctrl->event_port >= 0 && ctrl->ring) > + xc_evtchn_notify(ctrl->event, ctrl->event_port); > + xc_evtchn_close(ctrl->event); > + } > + if (ctrl->is_server) { > + if (ctrl->gntshr) > + xc_gntshr_close(ctrl->gntshr); > + } else { > + if (ctrl->gnttab) > + xc_gnttab_close(ctrl->gnttab); > + } > + free(ctrl); > +} > diff --git a/tools/libvchan/libxenvchan.h b/tools/libvchan/libxenvchan.h > new file mode 100644 > index 0000000..c4a3ab9 > --- /dev/null > +++ b/tools/libvchan/libxenvchan.h > @@ -0,0 +1,173 @@ > +/** > + * @file > + * @section AUTHORS > + * > + * Copyright (C) 2010 Rafal Wojtczuk <rafal@invisiblethingslab.com> > + * > + * Authors: > + * Rafal Wojtczuk <rafal@invisiblethingslab.com> > + * Daniel De Graaf <dgdegra@tycho.nsa.gov> > + * > + * @section LICENSE > + * > + * This library is free software; you can redistribute it and/or > + * modify it under the terms of the GNU Lesser General Public > + * License as published by the Free Software Foundation; either > + * version 2 of the License, or (at your option) any later version. > + * > + * This library is distributed in the hope that it will be useful, > + * but WITHOUT ANY WARRANTY; without even the implied warranty of > + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU > + * Lesser General Public License for more details. > + * > + * You should have received a copy of the GNU Lesser General Public > + * License along with this library; if not, write to the Free Software > + * Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston, MA 02110-1301 USA > + * > + * @section DESCRIPTION > + * > + * Originally borrowed from the Qubes OS Project, http://www.qubes-os.org, > + * this code has been substantially rewritten to use the gntdev and gntalloc > + * devices instead of raw MFNs and map_foreign_range. > + * > + * This is a library for inter-domain communication. A standard Xen ring > + * buffer is used, with a datagram-based interface built on top. The grant > + * reference and event channels are shared in XenStore under the path > + * /local/domain/<srv-id>/data/vchan/<cli-id>/<port>/{ring-ref,event-channel} > + * > + * The ring.h macros define an asymmetric interface to a shared data structure > + * that assumes all rings reside in a single contiguous memory space. This is > + * not suitable for vchan because the interface to the ring is symmetric except > + * for the setup. Unlike the producer-consumer rings defined in ring.h, the > + * size of the rings used in vchan are determined at execution time instead of > + * compile time, so the macros in ring.h cannot be used to access the rings. > + */ > + > +#include <xen/io/libvchan.h> > +#include <xen/sys/evtchn.h> > +#include <xenctrl.h> > + > +struct libvchan_ring { > + /* Pointer into the shared page. Offsets into buffer. */ > + struct ring_shared* shr; > + /* ring data; may be its own shared page(s) depending on order */ > + void* buffer; > + /** > + * The size of the ring is (1 << order); offsets wrap around when they > + * exceed this. This copy is required because we can't trust the order > + * in the shared page to remain constant. > + */ > + int order; > +}; > + > +/** > + * struct libvchan: control structure passed to all library calls > + */ > +struct libvchan { > + /* person we communicate with */ > + int other_domain_id; > + /* "port" we communicate on (allows multiple vchans to exist in xenstore) */ > + int device_number; > + /* Mapping handle for shared ring page */ > + union { > + xc_gntshr *gntshr; /* for server */ > + xc_gnttab *gnttab; /* for client */ > + }; > + /* Pointer to shared ring page */ > + struct vchan_interface *ring; > + /* event channel interface */ > + xc_evtchn *event; > + uint32_t event_port; > + /* informative flags: are we acting as server? */ > + int is_server:1; > + /* true if server remains active when client closes (allows reconnection) */ > + int server_persist:1; > + /* true if operations should block instead of returning 0 */ > + int blocking:1; > + /* communication rings */ > + struct libvchan_ring read, write; > +}; > + > +/** > + * Set up a vchan, including granting pages > + * @param logger Logger for libxc errors > + * @param domain The peer domain that will be connecting > + * @param devno A device number, used to identify this vchan in xenstore > + * @param send_min The minimum size (in bytes) of the send ring (left) > + * @param recv_min The minimum size (in bytes) of the receive ring (right) > + * @return The structure, or NULL in case of an error > + */ > +struct libvchan *libvchan_server_init(xentoollog_logger *logger, int domain, int devno, size_t read_min, size_t write_min); > +/** > + * Connect to an existing vchan. Note: you can reconnect to an existing vchan > + * safely, however no locking is performed, so you must prevent multiple clients > + * from connecting to a single server. > + * > + * @param logger Logger for libxc errors > + * @param domain The peer domain to connect to > + * @param devno A device number, used to identify this vchan in xenstore > + * @return The structure, or NULL in case of an error > + */ > +struct libvchan *libvchan_client_init(xentoollog_logger *logger, int domain, int devno); > +/** > + * Close a vchan. This deallocates the vchan and attempts to free its > + * resources. The other side is notified of the close, but can still read any > + * data pending prior to the close. > + */ > +void libvchan_close(struct libvchan *ctrl); > + > +/** > + * Packet-based receive: always reads exactly $size bytes. > + * @param ctrl The vchan control structure > + * @param data Buffer for data that was read > + * @param size Size of the buffer and amount of data to read > + * @return -1 on error, 0 if nonblocking and insufficient data is available, or $size > + */ > +int libvchan_recv(struct libvchan *ctrl, void *data, size_t size); > +/** > + * Stream-based receive: reads as much data as possible. > + * @param ctrl The vchan control structure > + * @param data Buffer for data that was read > + * @param size Size of the buffer > + * @return -1 on error, otherwise the amount of data read (which may be zero if > + * the vchan is nonblocking) > + */ > +int libvchan_read(struct libvchan *ctrl, void *data, size_t size); > +/** > + * Packet-based send: send entire buffer if possible > + * @param ctrl The vchan control structure > + * @param data Buffer for data to send > + * @param size Size of the buffer and amount of data to send > + * @return -1 on error, 0 if nonblocking and insufficient space is available, or $size > + */ > +int libvchan_send(struct libvchan *ctrl, const void *data, size_t size); > +/** > + * Stream-based send: send as much data as possible. > + * @param ctrl The vchan control structure > + * @param data Buffer for data to send > + * @param size Size of the buffer > + * @return -1 on error, otherwise the amount of data sent (which may be zero if > + * the vchan is nonblocking) > + */ > +int libvchan_write(struct libvchan *ctrl, const void *data, size_t size); > +/** > + * Waits for reads or writes to unblock, or for a close > + */ > +int libvchan_wait(struct libvchan *ctrl); > +/** > + * Returns the event file descriptor for this vchan. When this FD is readable, > + * libvchan_wait() will not block, and the state of the vchan has changed since > + * the last invocation of libvchan_wait(). > + */ > +int libvchan_fd_for_select(struct libvchan *ctrl); > +/** > + * Query the state of the vchan shared page: > + * return 0 when one side has called libvchan_close() or crashed > + * return 1 when both sides are open > + * return 2 [server only] when no client has yet connected > + */ > +int libvchan_is_open(struct libvchan* ctrl); > +/** Amount of data ready to read, in bytes */ > +int libvchan_data_ready(struct libvchan *ctrl); > +/** Amount of data it is possible to send without blocking */ > +int libvchan_buffer_space(struct libvchan *ctrl); > diff --git a/tools/libvchan/node-select.c b/tools/libvchan/node-select.c > new file mode 100644 > index 0000000..ea1bfc6 > --- /dev/null > +++ b/tools/libvchan/node-select.c > @@ -0,0 +1,162 @@ > +/** > + * @file > + * @section AUTHORS > + * > + * Copyright (C) 2010 Rafal Wojtczuk <rafal@invisiblethingslab.com> > + * > + * Authors: > + * Rafal Wojtczuk <rafal@invisiblethingslab.com> > + * Daniel De Graaf <dgdegra@tycho.nsa.gov> > + * > + * @section LICENSE > + * > + * This program is free software; you can redistribute it and/or > + * modify it under the terms of the GNU Lesser General Public > + * License as published by the Free Software Foundation; either > + * version 2 of the License, or (at your option) any later version. > + * > + * This program is distributed in the hope that it will be useful, > + * but WITHOUT ANY WARRANTY; without even the implied warranty of > + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU > + * Lesser General Public License for more details. > + * > + * You should have received a copy of the GNU Lesser General Public > + * License along with this program; if not, write to the Free Software > + * Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston, MA 02110-1301 USA > + * > + * @section DESCRIPTION > + * > + * This is a test program for libvchan. Communications are bidirectional, > + * with either server (grant offeror) or client able to read and write. > + */ > + > +#include <stdlib.h> > +#include <stdio.h> > +#include <string.h> > +#include <unistd.h> > +#include <fcntl.h> > +#include <errno.h> > + > +#include <libxenvchan.h> > + > +void usage(char** argv) > +{ > + fprintf(stderr, "usage:\n" > + "\t%s [client|server] domainid nodeid [rbufsiz wbufsiz]\n", > + argv[0]); > + exit(1); > +} > + > +#define BUFSIZE 5000 > +char inbuf[BUFSIZE]; > +char outbuf[BUFSIZE]; > +int insiz = 0; > +int outsiz = 0; > +struct libvchan *ctrl = 0; > + > +void vchan_wr() { > + if (!insiz) > + return; > + int ret = libvchan_write(ctrl, inbuf, insiz); > + if (ret < 0) { > + fprintf(stderr, "vchan write failed\n"); > + exit(1); > + } > + if (ret > 0) { > + insiz -= ret; > + memmove(inbuf, inbuf + ret, insiz); > + } > +} > + > +void stdout_wr() { > + if (!outsiz) > + return; > + int ret = write(1, outbuf, outsiz); > + if (ret < 0 && errno != EAGAIN) > + exit(1); > + if (ret > 0) { > + outsiz -= ret; > + memmove(outbuf, outbuf + ret, outsiz); > + } > +} > + > +/** > + Simple libvchan application, both client and server. > + Both sides may write and read, both from the libvchan and from > + stdin/stdout (just like netcat). > +*/ > + > +int main(int argc, char **argv) > +{ > + int ret; > + int libvchan_fd; > + if (argc < 4) > + usage(argv); > + if (!strcmp(argv[1], "server")) { > + int rsiz = argc > 4 ? atoi(argv[4]) : 0; > + int wsiz = argc > 5 ? atoi(argv[5]) : 0; > + ctrl = libvchan_server_init(NULL, atoi(argv[2]), atoi(argv[3]), rsiz, wsiz); > + } else if (!strcmp(argv[1], "client")) > + ctrl = libvchan_client_init(NULL, atoi(argv[2]), atoi(argv[3])); > + else > + usage(argv); > + if (!ctrl) { > + perror("libvchan_*_init"); > + exit(1); > + } > + > + fcntl(0, F_SETFL, O_NONBLOCK); > + fcntl(1, F_SETFL, O_NONBLOCK); > + > + libvchan_fd = libvchan_fd_for_select(ctrl); > + for (;;) { > + fd_set rfds; > + fd_set wfds; > + FD_ZERO(&rfds); > + FD_ZERO(&wfds); > + if (insiz != BUFSIZE) > + FD_SET(0, &rfds); > + if (outsiz) > + FD_SET(1, &wfds); > + FD_SET(libvchan_fd, &rfds); > + ret = select(libvchan_fd + 1, &rfds, &wfds, NULL, NULL); > + if (ret < 0) { > + perror("select"); > + exit(1); > + } > + if (FD_ISSET(0, &rfds)) { > + ret = read(0, inbuf + insiz, BUFSIZE - insiz); > + if (ret < 0 && errno != EAGAIN) > + exit(1); > + if (ret == 0) { > + while (insiz) { > + vchan_wr(); > + libvchan_wait(ctrl); > + } > + return 0; > + } > + if (ret) > + insiz += ret; > + vchan_wr(); > + } > + if (FD_ISSET(libvchan_fd, &rfds)) { > + libvchan_wait(ctrl); > + vchan_wr(); > + } > + if (FD_ISSET(1, &wfds)) > + stdout_wr(); > + while (libvchan_data_ready(ctrl) && outsiz < BUFSIZE) { > + ret = libvchan_read(ctrl, outbuf + outsiz, BUFSIZE - outsiz); > + if (ret < 0) > + exit(1); > + outsiz += ret; > + stdout_wr(); > + } > + if (!libvchan_is_open(ctrl)) { > + fcntl(1, F_SETFL, 0); > + while (outsiz) > + stdout_wr(); > + return 0; > + } > + } > +} > diff --git a/tools/libvchan/node.c b/tools/libvchan/node.c > new file mode 100644 > index 0000000..6a9204c > --- /dev/null > +++ b/tools/libvchan/node.c > @@ -0,0 +1,169 @@ > +/** > + * @file > + * @section AUTHORS > + * > + * Copyright (C) 2010 Rafal Wojtczuk <rafal@invisiblethingslab.com> > + * > + * Authors: > + * Rafal Wojtczuk <rafal@invisiblethingslab.com> > + * Daniel De Graaf <dgdegra@tycho.nsa.gov> > + * > + * @section LICENSE > + * > + * This program is free software; you can redistribute it and/or > + * modify it under the terms of the GNU Lesser General Public > + * License as published by the Free Software Foundation; either > + * version 2 of the License, or (at your option) any later version. > + * > + * This program is distributed in the hope that it will be useful, > + * but WITHOUT ANY WARRANTY; without even the implied warranty of > + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU > + * Lesser General Public License for more details. > + * > + * You should have received a copy of the GNU Lesser General Public > + * License along with this program; if not, write to the Free Software > + * Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston, MA 02110-1301 USA > + * > + * @section DESCRIPTION > + * > + * This is a test program for libvchan. Communications are in one direction, > + * either server (grant offeror) to client or vice versa. > + */ > + > +#include <stdlib.h> > +#include <stdio.h> > +#include <string.h> > +#include <unistd.h> > +#include <time.h> > + > +#include <libxenvchan.h> > + > +int libvchan_write_all(struct libvchan *ctrl, char *buf, int size) > +{ > + int written = 0; > + int ret; > + while (written < size) { > + ret = libvchan_write(ctrl, buf + written, size - written); > + if (ret <= 0) { > + perror("write"); > + exit(1); > + } > + written += ret; > + } > + return size; > +} > + > +int write_all(int fd, char *buf, int size) > +{ > + int written = 0; > + int ret; > + while (written < size) { > + ret = write(fd, buf + written, size - written); > + if (ret <= 0) { > + perror("write"); > + exit(1); > + } > + written += ret; > + } > + return size; > +} > + > +void usage(char** argv) > +{ > + fprintf(stderr, "usage:\n" > + "%s [client|server] [read|write] domid nodeid\n", argv[0]); > + exit(1); > +} > + > +#define BUFSIZE 5000 > +char buf[BUFSIZE]; > +void reader(struct libvchan *ctrl) > +{ > + int size; > + for (;;) { > + size = rand() % (BUFSIZE - 1) + 1; > + size = libvchan_read(ctrl, buf, size); > + fprintf(stderr, "#"); > + if (size < 0) { > + perror("read vchan"); > + libvchan_close(ctrl); > + exit(1); > + } > + size = write_all(1, buf, size); > + if (size < 0) { > + perror("stdout write"); > + exit(1); > + } > + if (size == 0) { > + perror("write size=0?\n"); > + exit(1); > + } > + } > +} > + > +void writer(struct libvchan *ctrl) > +{ > + int size; > + for (;;) { > + size = rand() % (BUFSIZE - 1) + 1; > + size = read(0, buf, size); > + if (size < 0) { > + perror("read stdin"); > + libvchan_close(ctrl); > + exit(1); > + } > + if (size == 0) > + break; > + size = libvchan_write_all(ctrl, buf, size); > + fprintf(stderr, "#"); > + if (size < 0) { > + perror("vchan write"); > + exit(1); > + } > + if (size == 0) { > + perror("write size=0?\n"); > + exit(1); > + } > + } > +} > + > + > +/** > + Simple libvchan application, both client and server. > + One side does writing, the other side does reading; both from > + standard input/output fds. > +*/ > +int main(int argc, char **argv) > +{ > + int seed = time(0); > + struct libvchan *ctrl = 0; > + int wr = 0; > + if (argc < 4) > + usage(argv); > + if (!strcmp(argv[2], "read")) > + wr = 0; > + else if (!strcmp(argv[2], "write")) > + wr = 1; > + else > + usage(argv); > + if (!strcmp(argv[1], "server")) > + ctrl = libvchan_server_init(NULL, atoi(argv[3]), atoi(argv[4]), 0, 0); > + else if (!strcmp(argv[1], "client")) > + ctrl = libvchan_client_init(NULL, atoi(argv[3]), atoi(argv[4])); > + else > + usage(argv); > + if (!ctrl) { > + perror("libvchan_*_init"); > + exit(1); > + } > + ctrl->blocking = 1; > + > + srand(seed); > + fprintf(stderr, "seed=%d\n", seed); > + if (wr) > + writer(ctrl); > + else > + reader(ctrl); > + libvchan_close(ctrl); > + return 0; > +} > diff --git a/xen/include/public/io/libvchan.h b/xen/include/public/io/libvchan.h > new file mode 100644 > index 0000000..a3bf7cd > --- /dev/null > +++ b/xen/include/public/io/libvchan.h > @@ -0,0 +1,97 @@ > +/** > + * @file > + * @section AUTHORS > + * > + * Copyright (C) 2010 Rafal Wojtczuk <rafal@invisiblethingslab.com> > + * > + * Authors: > + * Rafal Wojtczuk <rafal@invisiblethingslab.com> > + * Daniel De Graaf <dgdegra@tycho.nsa.gov> > + * > + * @section LICENSE > + * > + * This library is free software; you can redistribute it and/or > + * modify it under the terms of the GNU Lesser General Public > + * License as published by the Free Software Foundation; either > + * version 2 of the License, or (at your option) any later version. > + * > + * This library is distributed in the hope that it will be useful, > + * but WITHOUT ANY WARRANTY; without even the implied warranty of > + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU > + * Lesser General Public License for more details. > + * > + * You should have received a copy of the GNU Lesser General Public > + * License along with this library; if not, write to the Free Software > + * Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston, MA 02110-1301 USA > + * > + * @section DESCRIPTION > + * > + * Originally borrowed from the Qubes OS Project, http://www.qubes-os.org, > + * this code has been substantially rewritten to use the gntdev and gntalloc > + * devices instead of raw MFNs and map_foreign_range. > + * > + * This is a library for inter-domain communication. A standard Xen ring > + * buffer is used, with a datagram-based interface built on top. The grant > + * reference and event channels are shared in XenStore under the path > + * /local/domain/<srv-id>/data/vchan/<cli-id>/<port>/{ring-ref,event-channel} > + * > + * The ring.h macros define an asymmetric interface to a shared data structure > + * that assumes all rings reside in a single contiguous memory space. This is > + * not suitable for vchan because the interface to the ring is symmetric except > + * for the setup. Unlike the producer-consumer rings defined in ring.h, the > + * size of the rings used in vchan are determined at execution time instead of > + * compile time, so the macros in ring.h cannot be used to access the rings. > + */ > + > +#include <stdint.h> > +#include <sys/types.h> > + > +struct ring_shared { > + uint32_t cons, prod; > +}; > + > +#define VCHAN_NOTIFY_WRITE 0x1 > +#define VCHAN_NOTIFY_READ 0x2 > + > +/** > + * vchan_interface: primary shared data structure > + */ > +struct vchan_interface { > + /** > + * Standard consumer/producer interface, one pair per buffer > + * left is client write, server read > + * right is client read, server write > + */ > + struct ring_shared left, right; > + /** > + * size of the rings, which determines their location > + * 10 - at offset 1024 in ring's page > + * 11 - at offset 2048 in ring's page > + * 12+ - uses 2^(N-12) grants to describe the multi-page ring > + * These should remain constant once the page is shared. > + * Only one of the two orders can be 10 (or 11). > + */ > + uint16_t left_order, right_order; > + /** > + * Shutdown detection: > + * 0: client (or server) has exited > + * 1: client (or server) is connected > + * 2: client has not yet connected > + */ > + uint8_t cli_live, srv_live; > + /** > + * Notification bits: > + * VCHAN_NOTIFY_WRITE: send notify when data is written > + * VCHAN_NOTIFY_READ: send notify when data is read (consumed) > + * cli_notify is used for the client to inform the server of its action > + */ > + uint8_t cli_notify, srv_notify; > + /** > + * Grant list: ordering is left, right. Must not extend into actual ring > + * or grow beyond the end of the initial shared page. > + * These should remain constant once the page is shared, to allow > + * for possible remapping by a client that restarts. > + */ > + uint32_t grants[0]; > +}; > + > -- > 1.7.6.2 > _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel From xen-devel-bounces@lists.xensource.com Wed Sep 21 06:48:11 2011 Return-path: <xen-devel-bounces@lists.xensource.com> Envelope-to: www-data@lists.xensource.com Delivery-date: Wed, 21 Sep 2011 06:48:11 -0700 Received: from localhost ([127.0.0.1] helo=lists.colo.xensource.com) by lists.xensource.com with esmtp (Exim 4.43) id 1R6N9n-0005aB-0L; Wed, 21 Sep 2011 06:48:11 -0700 Received: from mail21.messagelabs.com ([85.158.143.35]) by lists.xensource.com with esmtp (Exim 4.43) id 1R6N7j-0004uX-DP for xen-devel@lists.xensource.com; Wed, 21 Sep 2011 06:46:04 -0700 X-Env-Sender: olaf@aepfle.de X-Msg-Ref: server-13.tower-21.messagelabs.com!1316612753!49780067!1 X-Originating-IP: [81.169.146.161] X-StarScan-Version: 6.4.1; banners=-,-,- X-VirusChecked: Checked Received: (qmail 30526 invoked from network); 21 Sep 2011 13:45:54 -0000 Received: from mo-p00-ob.rzone.de (HELO mo-p00-ob.rzone.de) (81.169.146.161) by server-13.tower-21.messagelabs.com with EDH-RSA-DES-CBC3-SHA encrypted SMTP; 21 Sep 2011 13:45:54 -0000 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; t=1316612758; l=889; s=domk; d=aepfle.de; h=To:From:Date:Subject:Content-Transfer-Encoding:MIME-Version: Content-Type:X-RZG-CLASS-ID:X-RZG-AUTH; bh=H0kjaDonBS+JQvpovOlcBbdNr0w=; b=cC23yuDAvb/fKtUZij7mUSFWex3449SVphA7sUpDSB7vii0QLesag1ERp8oYT3uGhLD pIf6lkv7bNYQ+enOvmoLQiQQiMPFNWUJsq9UryP1Hz+W6OMKr48Y3HQD0PminNSHztMdt ONBME83+Epw/vuhkG+ilUjIok8Z9hLmYq3Q= X-RZG-AUTH: :P2EQZWCpfu+qG7CngxMFH1J+zrwiavkK6tmQaLfmwtM48/ll387iF8M= X-RZG-CLASS-ID: mo00 Received: from probook.site (dslb-084-057-086-095.pools.arcor-ip.net [84.57.86.95]) by post.strato.de (mrclete mo41) (RZmta 26.7) with (EDH-RSA-DES-CBC3-SHA encrypted) ESMTPA id i0304dn8LCr8Mp for <xen-devel@lists.xensource.com>; Wed, 21 Sep 2011 15:45:49 +0200 (MEST) Received: from probook.site (localhost [IPv6:::1]) by probook.site (Postfix) with ESMTP id 1304D18892 for <xen-devel@lists.xensource.com>; Wed, 21 Sep 2011 15:45:45 +0200 (CEST) Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Mercurial-Node: 4d03b2c3bf5953afddca325e15cce89ad5db0098 Message-Id: <4d03b2c3bf5953afddca.1316612744@probook.site> User-Agent: Mercurial-patchbomb/1.7.5 Date: Wed, 21 Sep 2011 15:45:44 +0200 From: Olaf Hering <olaf@aepfle.de> To: xen-devel@lists.xensource.com Subject: [Xen-devel] [PATCH] linux-2.6.18:xen-kbdfront: re-enable REL_WHEEL event X-BeenThere: xen-devel@lists.xensource.com X-Mailman-Version: 2.1.5 Precedence: list List-Id: Xen developer discussion <xen-devel.lists.xensource.com> List-Unsubscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe> List-Post: <mailto:xen-devel@lists.xensource.com> List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help> List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=subscribe> Sender: xen-devel-bounces@lists.xensource.com Errors-To: xen-devel-bounces@lists.xensource.com # HG changeset patch # User Olaf Hering <olaf@aepfle.de> # Date 1316612524 -7200 # Node ID 4d03b2c3bf5953afddca325e15cce89ad5db0098 # Parent 56c7b8e10d3ba46e34d7a1be3b708da6f999b1a0 linux-2.6.18:xen-kbdfront: re-enable REL_WHEEL event In commit 1083:211849d9d511 the wheel event was lost due to an incorrect backport of upstream commit 8c3c283e6bf463ab498d6e7823aff6c4762314b6. With this change the wheel event is available again in the guest. Signed-off-by: Olaf Hering <olaf@aepfle.de> diff -r 56c7b8e10d3b -r 4d03b2c3bf59 drivers/xen/fbfront/xenkbd.c --- a/drivers/xen/fbfront/xenkbd.c +++ b/drivers/xen/fbfront/xenkbd.c @@ -170,6 +170,7 @@ int __devinit xenkbd_probe(struct xenbus __set_bit(REL_Y, ptr->relbit); } __set_bit(REL_WHEEL, ptr->relbit); + __set_bit(EV_REL, ptr->evbit); __set_bit(EV_KEY, ptr->evbit); for (i = BTN_LEFT; i <= BTN_TASK; i++) _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel From xen-devel-bounces@lists.xensource.com Wed Sep 21 06:52:12 2011 Return-path: <xen-devel-bounces@lists.xensource.com> Envelope-to: www-data@lists.xensource.com Delivery-date: Wed, 21 Sep 2011 06:52:12 -0700 Received: from localhost ([127.0.0.1] helo=lists.colo.xensource.com) by lists.xensource.com with esmtp (Exim 4.43) id 1R6NDg-0005zg-KT; Wed, 21 Sep 2011 06:52:12 -0700 Received: from mail182.messagelabs.com ([85.158.139.83]) by lists.xensource.com with esmtp (Exim 4.43) id 1R6NCz-0005nM-7d for xen-devel@lists.xensource.com; Wed, 21 Sep 2011 06:51:30 -0700 X-Env-Sender: Ian.Campbell@eu.citrix.com X-Msg-Ref: server-4.tower-182.messagelabs.com!1316613086!19206289!1 X-Originating-IP: [62.200.22.115] X-StarScan-Version: 6.4.1; banners=-,-,- X-VirusChecked: Checked Received: (qmail 28619 invoked from network); 21 Sep 2011 13:51:26 -0000 Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115) by server-4.tower-182.messagelabs.com with RC4-SHA encrypted SMTP; 21 Sep 2011 13:51:26 -0000 X-IronPort-AV: E=Sophos;i="4.68,417,1312156800"; d="scan'208";a="7981324" Received: from lonpmailmx01.citrite.net ([10.30.203.162]) by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5; 21 Sep 2011 13:51:25 +0000 Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net (10.30.203.162) with Microsoft SMTP Server id 8.3.137.0; Wed, 21 Sep 2011 14:51:25 +0100 From: Ian Campbell <Ian.Campbell@eu.citrix.com> To: Anthony PERARD <anthony.perard@citrix.com> Date: Wed, 21 Sep 2011 14:51:25 +0100 In-Reply-To: <1316609997-26002-7-git-send-email-anthony.perard@citrix.com> References: <1316609997-26002-1-git-send-email-anthony.perard@citrix.com> <1316609997-26002-7-git-send-email-anthony.perard@citrix.com> Organization: Citrix Systems, Inc. Content-Type: text/plain; charset="UTF-8" X-Mailer: Evolution 3.0.3- Content-Transfer-Encoding: 7bit Message-ID: <1316613085.3891.196.camel@zakaz.uk.xensource.com> MIME-Version: 1.0 Cc: Xen Devel <xen-devel@lists.xensource.com>, Stefano Stabellini <Stefano.Stabellini@eu.citrix.com> Subject: [Xen-devel] Re: [PATCH RESEND V8 6/7] libxl: Introduce JSON parsing stuff. X-BeenThere: xen-devel@lists.xensource.com X-Mailman-Version: 2.1.5 Precedence: list List-Id: Xen developer discussion <xen-devel.lists.xensource.com> List-Unsubscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe> List-Post: <mailto:xen-devel@lists.xensource.com> List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help> List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=subscribe> Sender: xen-devel-bounces@lists.xensource.com Errors-To: xen-devel-bounces@lists.xensource.com On Wed, 2011-09-21 at 13:59 +0100, Anthony PERARD wrote: > We use the yajl parser, but we need to make a tree from the parse result > to use it outside the parser. > > So this patch include json_object struct that is used to hold the JSON > data. > > Signed-off-by: Anthony PERARD <anthony.perard@citrix.com> I didn't review this again but I recall being happy with it last time round so: Acked-by: Ian Campbell <ian.campbell@citrix.com> > --- > README | 1 + > tools/libxl/Makefile | 5 +- > tools/libxl/libxl_internal.h | 100 ++++++++ > tools/libxl/libxl_json.c | 560 ++++++++++++++++++++++++++++++++++++++++++ > 4 files changed, 665 insertions(+), 1 deletions(-) > create mode 100644 tools/libxl/libxl_json.c > > diff --git a/README b/README > index ff154b2..c9bf699 100644 > --- a/README > +++ b/README > @@ -47,6 +47,7 @@ provided by your OS distributor: > * Development install of openssl (e.g., openssl-dev) > * Development install of x11 (e.g. xorg-x11-dev) > * Development install of uuid (e.g. uuid-dev) > + * Development install of yajl (e.g. libyajl-dev) > * bridge-utils package (/sbin/brctl) > * iproute package (/sbin/ip) > * hotplug or udev > diff --git a/tools/libxl/Makefile b/tools/libxl/Makefile > index 1f6b418..e50874e 100644 > --- a/tools/libxl/Makefile > +++ b/tools/libxl/Makefile > @@ -32,9 +32,12 @@ endif > LIBXL_OBJS-$(CONFIG_X86) += libxl_cpuid.o > LIBXL_OBJS-$(CONFIG_IA64) += libxl_nocpuid.o > > +LIBXL_LIBS += -lyajl > + > LIBXL_OBJS = flexarray.o libxl.o libxl_create.o libxl_dm.o libxl_pci.o \ > libxl_dom.o libxl_exec.o libxl_xshelp.o libxl_device.o \ > - libxl_internal.o libxl_utils.o libxl_uuid.o $(LIBXL_OBJS-y) > + libxl_internal.o libxl_utils.o libxl_uuid.o libxl_json.o \ > + $(LIBXL_OBJS-y) > LIBXL_OBJS += _libxl_types.o libxl_flask.o _libxl_types_internal.o > > $(LIBXL_OBJS): CFLAGS += $(CFLAGS_libxenctrl) $(CFLAGS_libxenguest) $(CFLAGS_libxenstore) $(CFLAGS_libblktapctl) > diff --git a/tools/libxl/libxl_internal.h b/tools/libxl/libxl_internal.h > index d873243..f495e86 100644 > --- a/tools/libxl/libxl_internal.h > +++ b/tools/libxl/libxl_internal.h > @@ -387,4 +387,104 @@ _hidden int libxl__e820_alloc(libxl_ctx *ctx, uint32_t domid, libxl_domain_confi > #define STRINGIFY(x) #x > #define TOSTRING(x) STRINGIFY(x) > > +/* from libxl_json */ > +#include <yajl/yajl_gen.h> > + > +_hidden yajl_gen_status libxl__yajl_gen_asciiz(yajl_gen hand, const char *str); > + > +typedef enum { > + JSON_ERROR, > + JSON_NULL, > + JSON_TRUE, > + JSON_FALSE, > + JSON_INTEGER, > + JSON_DOUBLE, > + JSON_STRING, > + JSON_MAP, > + JSON_ARRAY, > + JSON_ANY > +} libxl__json_node_type; > + > +typedef struct libxl__json_object { > + libxl__json_node_type type; > + union { > + long i; > + double d; > + char *string; > + /* List of libxl__json_object */ > + flexarray_t *array; > + /* List of libxl__json_map_node */ > + flexarray_t *map; > + } u; > + struct libxl__json_object *parent; > +} libxl__json_object; > + > +typedef struct { > + char *map_key; > + libxl__json_object *obj; > +} libxl__json_map_node; > + > +typedef struct libxl__yajl_ctx libxl__yajl_ctx; > + > +static inline bool libxl__json_object_is_string(const libxl__json_object *o) > +{ > + return o != NULL && o->type == JSON_STRING; > +} > +static inline bool libxl__json_object_is_integer(const libxl__json_object *o) > +{ > + return o != NULL && o->type == JSON_INTEGER; > +} > +static inline bool libxl__json_object_is_map(const libxl__json_object *o) > +{ > + return o != NULL && o->type == JSON_MAP; > +} > +static inline bool libxl__json_object_is_array(const libxl__json_object *o) > +{ > + return o != NULL && o->type == JSON_ARRAY; > +} > + > +static inline > +const char *libxl__json_object_get_string(const libxl__json_object *o) > +{ > + if (libxl__json_object_is_string(o)) > + return o->u.string; > + else > + return NULL; > +} > +static inline > +flexarray_t *libxl__json_object_get_map(const libxl__json_object *o) > +{ > + if (libxl__json_object_is_map(o)) > + return o->u.map; > + else > + return NULL; > +} > +static inline > +flexarray_t *libxl__json_object_get_array(const libxl__json_object *o) > +{ > + if (libxl__json_object_is_array(o)) > + return o->u.array; > + else > + return NULL; > +} > +static inline long libxl__json_object_get_integer(const libxl__json_object *o) > +{ > + if (libxl__json_object_is_integer(o)) > + return o->u.i; > + else > + return -1; > +} > + > +_hidden libxl__json_object *libxl__json_array_get(const libxl__json_object *o, > + int i); > +_hidden > +libxl__json_map_node *libxl__json_map_node_get(const libxl__json_object *o, > + int i); > +_hidden const libxl__json_object *libxl__json_map_get(const char *key, > + const libxl__json_object *o, > + libxl__json_node_type expected_type); > +_hidden void libxl__json_object_free(libxl__gc *gc, libxl__json_object *obj); > + > +_hidden libxl__json_object *libxl__json_parse(libxl__gc *gc, const char *s); > + > #endif > diff --git a/tools/libxl/libxl_json.c b/tools/libxl/libxl_json.c > new file mode 100644 > index 0000000..e771925 > --- /dev/null > +++ b/tools/libxl/libxl_json.c > @@ -0,0 +1,560 @@ > +/* > + * Copyright (C) 2011 Citrix Ltd. > + * > + * This program is free software; you can redistribute it and/or modify > + * it under the terms of the GNU Lesser General Public License as published > + * by the Free Software Foundation; version 2.1 only. with the special > + * exception on linking described in file LICENSE. > + * > + * This program is distributed in the hope that it will be useful, > + * but WITHOUT ANY WARRANTY; without even the implied warranty of > + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the > + * GNU Lesser General Public License for more details. > + */ > + > +#include <assert.h> > +#include <string.h> > + > +#include <yajl/yajl_parse.h> > +#include <yajl/yajl_gen.h> > + > +#include "libxl_internal.h" > + > +/* #define DEBUG_ANSWER */ > + > +struct libxl__yajl_ctx { > + libxl__gc *gc; > + yajl_handle hand; > + libxl__json_object *head; > + libxl__json_object *current; > +#ifdef DEBUG_ANSWER > + yajl_gen g; > +#endif > +}; > + > +#ifdef DEBUG_ANSWER > +# define DEBUG_GEN_ALLOC(ctx) \ > + if ((ctx)->g == NULL) { \ > + yajl_gen_config conf = { 1, " " }; \ > + (ctx)->g = yajl_gen_alloc(&conf, NULL); \ > + } > +# define DEBUG_GEN_FREE(ctx) \ > + if ((ctx)->g) yajl_gen_free((ctx)->g) > +# define DEBUG_GEN(ctx, type) yajl_gen_##type(ctx->g) > +# define DEBUG_GEN_VALUE(ctx, type, value) yajl_gen_##type(ctx->g, value) > +# define DEBUG_GEN_STRING(ctx, str, n) yajl_gen_string(ctx->g, str, n) > +# define DEBUG_GEN_REPORT(yajl_ctx) \ > + do { \ > + const unsigned char *buf = NULL; \ > + unsigned int len = 0; \ > + yajl_gen_get_buf((yajl_ctx)->g, &buf, &len); \ > + LIBXL__LOG(libxl__gc_owner((yajl_ctx)->gc), \ > + LIBXL__LOG_DEBUG, "response:\n%s", buf); \ > + yajl_gen_free((yajl_ctx)->g); \ > + (yajl_ctx)->g = NULL; \ > + } while (0) > +#else > +# define DEBUG_GEN_ALLOC(ctx) ((void)0) > +# define DEBUG_GEN_FREE(ctx) ((void)0) > +# define DEBUG_GEN(ctx, type) ((void)0) > +# define DEBUG_GEN_VALUE(ctx, type, value) ((void)0) > +# define DEBUG_GEN_STRING(ctx, value, lenght) ((void)0) > +# define DEBUG_GEN_REPORT(ctx) ((void)0) > +#endif > + > +/* > + * YAJL Helper > + */ > + > +yajl_gen_status libxl__yajl_gen_asciiz(yajl_gen hand, const char *str) > +{ > + return yajl_gen_string(hand, (const unsigned char *)str, strlen(str)); > +} > + > + > +/* > + * libxl__json_object helper functions > + */ > + > +static libxl__json_object *json_object_alloc(libxl__gc *gc, > + libxl__json_node_type type) > +{ > + libxl__json_object *obj; > + > + obj = calloc(1, sizeof (libxl__json_object)); > + if (obj == NULL) { > + LIBXL__LOG_ERRNO(libxl__gc_owner(gc), LIBXL__LOG_ERROR, > + "Failed to allocate a libxl__json_object"); > + return NULL; > + } > + > + obj->type = type; > + > + if (type == JSON_MAP || type == JSON_ARRAY) { > + flexarray_t *array = flexarray_make(1, 1); > + if (array == NULL) { > + LIBXL__LOG_ERRNO(libxl__gc_owner(gc), LIBXL__LOG_ERROR, > + "Failed to allocate a flexarray"); > + free(obj); > + return NULL; > + } > + if (type == JSON_MAP) > + obj->u.map = array; > + else > + obj->u.array = array; > + } > + > + return obj; > +} > + > +static int json_object_append_to(libxl__gc *gc, > + libxl__json_object *obj, > + libxl__json_object *dst) > +{ > + assert(dst != NULL); > + > + switch (dst->type) { > + case JSON_MAP: { > + libxl__json_map_node *last; > + > + if (dst->u.map->count == 0) { > + LIBXL__LOG(libxl__gc_owner(gc), LIBXL__LOG_ERROR, > + "Try to add a value to an empty map (with no key)"); > + return -1; > + } > + flexarray_get(dst->u.map, dst->u.map->count - 1, (void**)&last); > + last->obj = obj; > + break; > + } > + case JSON_ARRAY: > + if (flexarray_append(dst->u.array, obj) == 2) { > + LIBXL__LOG_ERRNO(libxl__gc_owner(gc), LIBXL__LOG_ERROR, > + "Failed to grow a flexarray"); > + return -1; > + } > + break; > + default: > + LIBXL__LOG(libxl__gc_owner(gc), LIBXL__LOG_ERROR, > + "Try append an object is not a map/array (%i)\n", > + dst->type); > + return -1; > + } > + > + obj->parent = dst; > + return 0; > +} > + > +void libxl__json_object_free(libxl__gc *gc, libxl__json_object *obj) > +{ > + int index = 0; > + > + if (obj == NULL) > + return; > + switch (obj->type) { > + case JSON_STRING: > + free(obj->u.string); > + break; > + case JSON_MAP: { > + libxl__json_map_node *node = NULL; > + > + for (index = 0; index < obj->u.map->count; index++) { > + if (flexarray_get(obj->u.map, index, (void**)&node) != 0) > + break; > + libxl__json_object_free(gc, node->obj); > + free(node->map_key); > + free(node); > + node = NULL; > + } > + flexarray_free(obj->u.map); > + break; > + } > + case JSON_ARRAY: { > + libxl__json_object *node = NULL; > + break; > + > + for (index = 0; index < obj->u.array->count; index++) { > + if (flexarray_get(obj->u.array, index, (void**)&node) != 0) > + break; > + libxl__json_object_free(gc, node); > + node = NULL; > + } > + flexarray_free(obj->u.array); > + break; > + } > + default: > + break; > + } > + free(obj); > +} > + > +libxl__json_object *libxl__json_array_get(const libxl__json_object *o, int i) > +{ > + flexarray_t *array = NULL; > + libxl__json_object *obj = NULL; > + > + if ((array = libxl__json_object_get_array(o)) == NULL) { > + return NULL; > + } > + > + if (i >= array->count) > + return NULL; > + > + if (flexarray_get(array, i, (void**)&obj) != 0) > + return NULL; > + > + return obj; > +} > + > +libxl__json_map_node *libxl__json_map_node_get(const libxl__json_object *o, > + int i) > +{ > + flexarray_t *array = NULL; > + libxl__json_map_node *obj = NULL; > + > + if ((array = libxl__json_object_get_map(o)) == NULL) { > + return NULL; > + } > + > + if (i >= array->count) > + return NULL; > + > + if (flexarray_get(array, i, (void**)&obj) != 0) > + return NULL; > + > + return obj; > +} > + > +const libxl__json_object *libxl__json_map_get(const char *key, > + const libxl__json_object *o, > + libxl__json_node_type expected_type) > +{ > + flexarray_t *maps = NULL; > + int index = 0; > + > + if (libxl__json_object_is_map(o)) { > + libxl__json_map_node *node = NULL; > + > + maps = o->u.map; > + for (index = 0; index < maps->count; index++) { > + if (flexarray_get(maps, index, (void**)&node) != 0) > + return NULL; > + if (strcmp(key, node->map_key) == 0) { > + if (expected_type == JSON_ANY > + || (node->obj && node->obj->type == expected_type)) { > + return node->obj; > + } else { > + return NULL; > + } > + } > + } > + } > + return NULL; > +} > + > + > +/* > + * JSON callbacks > + */ > + > +static int json_callback_null(void *opaque) > +{ > + libxl__yajl_ctx *ctx = opaque; > + libxl__json_object *obj; > + > + DEBUG_GEN(ctx, null); > + > + if ((obj = json_object_alloc(ctx->gc, JSON_NULL)) == NULL) > + return 0; > + > + if (json_object_append_to(ctx->gc, obj, ctx->current) == -1) { > + libxl__json_object_free(ctx->gc, obj); > + return 0; > + } > + > + return 1; > +} > + > +static int json_callback_boolean(void *opaque, int boolean) > +{ > + libxl__yajl_ctx *ctx = opaque; > + libxl__json_object *obj; > + > + DEBUG_GEN_VALUE(ctx, bool, boolean); > + > + if ((obj = json_object_alloc(ctx->gc, > + boolean ? JSON_TRUE : JSON_FALSE)) == NULL) > + return 0; > + > + if (json_object_append_to(ctx->gc, obj, ctx->current) == -1) { > + libxl__json_object_free(ctx->gc, obj); > + return 0; > + } > + > + return 1; > +} > + > +static int json_callback_integer(void *opaque, long value) > +{ > + libxl__yajl_ctx *ctx = opaque; > + libxl__json_object *obj; > + > + DEBUG_GEN_VALUE(ctx, integer, value); > + > + if ((obj = json_object_alloc(ctx->gc, JSON_INTEGER)) == NULL) > + return 0; > + obj->u.i = value; > + > + if (json_object_append_to(ctx->gc, obj, ctx->current) == -1) { > + libxl__json_object_free(ctx->gc, obj); > + return 0; > + } > + > + return 1; > +} > + > +static int json_callback_double(void *opaque, double value) > +{ > + libxl__yajl_ctx *ctx = opaque; > + libxl__json_object *obj; > + > + DEBUG_GEN_VALUE(ctx, double, value); > + > + if ((obj = json_object_alloc(ctx->gc, JSON_DOUBLE)) == NULL) > + return 0; > + obj->u.d = value; > + > + if (json_object_append_to(ctx->gc, obj, ctx->current) == -1) { > + libxl__json_object_free(ctx->gc, obj); > + return 0; > + } > + > + return 1; > +} > + > +static int json_callback_string(void *opaque, const unsigned char *str, > + unsigned int len) > +{ > + libxl__yajl_ctx *ctx = opaque; > + char *t = NULL; > + libxl__json_object *obj = NULL; > + > + t = malloc(len + 1); > + if (t == NULL) { > + LIBXL__LOG_ERRNO(libxl__gc_owner(ctx->gc), LIBXL__LOG_ERROR, > + "Failed to allocate"); > + return 0; > + } > + > + DEBUG_GEN_STRING(ctx, str, len); > + > + strncpy(t, (const char *) str, len); > + t[len] = 0; > + > + if ((obj = json_object_alloc(ctx->gc, JSON_STRING)) == NULL) { > + free(t); > + return 0; > + } > + obj->u.string = t; > + > + if (json_object_append_to(ctx->gc, obj, ctx->current) == -1) { > + libxl__json_object_free(ctx->gc, obj); > + return 0; > + } > + > + return 1; > +} > + > +static int json_callback_map_key(void *opaque, const unsigned char *str, > + unsigned int len) > +{ > + libxl__yajl_ctx *ctx = opaque; > + char *t = NULL; > + libxl__json_object *obj = ctx->current; > + > + t = malloc(len + 1); > + if (t == NULL) { > + LIBXL__LOG_ERRNO(libxl__gc_owner(ctx->gc), LIBXL__LOG_ERROR, > + "Failed to allocate"); > + return 0; > + } > + > + DEBUG_GEN_STRING(ctx, str, len); > + > + strncpy(t, (const char *) str, len); > + t[len] = 0; > + > + if (libxl__json_object_is_map(obj)) { > + libxl__json_map_node *node = malloc(sizeof (libxl__json_map_node)); > + if (node == NULL) { > + LIBXL__LOG_ERRNO(libxl__gc_owner(ctx->gc), LIBXL__LOG_ERROR, > + "Failed to allocate"); > + return 0; > + } > + > + node->map_key = t; > + node->obj = NULL; > + > + if (flexarray_append(obj->u.map, node) == 2) { > + LIBXL__LOG_ERRNO(libxl__gc_owner(ctx->gc), LIBXL__LOG_ERROR, > + "Failed to grow a flexarray"); > + return 0; > + } > + } else { > + LIBXL__LOG(libxl__gc_owner(ctx->gc), LIBXL__LOG_ERROR, > + "Current json object is not a map"); > + return 0; > + } > + > + return 1; > +} > + > +static int json_callback_start_map(void *opaque) > +{ > + libxl__yajl_ctx *ctx = opaque; > + libxl__json_object *obj = NULL; > + > + DEBUG_GEN(ctx, map_open); > + > + if ((obj = json_object_alloc(ctx->gc, JSON_MAP)) == NULL) > + return 0; > + > + if (ctx->current) { > + if (json_object_append_to(ctx->gc, obj, ctx->current) == -1) { > + libxl__json_object_free(ctx->gc, obj); > + return 0; > + } > + } > + > + ctx->current = obj; > + if (ctx->head == NULL) { > + ctx->head = obj; > + } > + > + return 1; > +} > + > +static int json_callback_end_map(void *opaque) > +{ > + libxl__yajl_ctx *ctx = opaque; > + > + DEBUG_GEN(ctx, map_close); > + > + if (ctx->current) { > + ctx->current = ctx->current->parent; > + } else { > + LIBXL__LOG(libxl__gc_owner(ctx->gc), LIBXL__LOG_ERROR, > + "No current libxl__json_object, cannot use his parent."); > + return 0; > + } > + > + return 1; > +} > + > +static int json_callback_start_array(void *opaque) > +{ > + libxl__yajl_ctx *ctx = opaque; > + libxl__json_object *obj = NULL; > + > + DEBUG_GEN(ctx, array_open); > + > + if ((obj = json_object_alloc(ctx->gc, JSON_ARRAY)) == NULL) > + return 0; > + > + if (ctx->current) { > + if (json_object_append_to(ctx->gc, obj, ctx->current) == -1) { > + libxl__json_object_free(ctx->gc, obj); > + return 0; > + } > + } > + > + ctx->current = obj; > + if (ctx->head == NULL) { > + ctx->head = obj; > + } > + > + return 1; > +} > + > +static int json_callback_end_array(void *opaque) > +{ > + libxl__yajl_ctx *ctx = opaque; > + > + DEBUG_GEN(ctx, array_close); > + > + if (ctx->current) { > + ctx->current = ctx->current->parent; > + } else { > + LIBXL__LOG(libxl__gc_owner(ctx->gc), LIBXL__LOG_ERROR, > + "No current libxl__json_object, cannot use his parent."); > + return 0; > + } > + > + return 1; > +} > + > +static yajl_callbacks callbacks = { > + json_callback_null, > + json_callback_boolean, > + json_callback_integer, > + json_callback_double, > + NULL, > + json_callback_string, > + json_callback_start_map, > + json_callback_map_key, > + json_callback_end_map, > + json_callback_start_array, > + json_callback_end_array > +}; > + > +static void yajl_ctx_free(libxl__yajl_ctx *yajl_ctx) > +{ > + if (yajl_ctx->hand) { > + yajl_free(yajl_ctx->hand); > + yajl_ctx->hand = NULL; > + } > + DEBUG_GEN_FREE(yajl_ctx); > +} > + > +libxl__json_object *libxl__json_parse(libxl__gc *gc, const char *s) > +{ > + yajl_status status; > + libxl__yajl_ctx yajl_ctx; > + > + memset(&yajl_ctx, 0, sizeof (yajl_ctx)); > + yajl_ctx.gc = gc; > + > + DEBUG_GEN_ALLOC(&yajl_ctx); > + > + if (yajl_ctx.hand == NULL) { > + yajl_parser_config cfg = { > + .allowComments = 1, > + .checkUTF8 = 1, > + }; > + yajl_ctx.hand = yajl_alloc(&callbacks, &cfg, NULL, &yajl_ctx); > + } > + status = yajl_parse(yajl_ctx.hand, (const unsigned char *)s, strlen(s)); > + status = yajl_parse_complete(yajl_ctx.hand); > + > + if (status == yajl_status_ok) { > + libxl__json_object *o = yajl_ctx.head; > + > + DEBUG_GEN_REPORT(&yajl_ctx); > + > + yajl_ctx.head = NULL; > + > + yajl_ctx_free(&yajl_ctx); > + return o; > + } else { > + unsigned char *str = yajl_get_error(yajl_ctx.hand, 1, > + (const unsigned char *)s, > + strlen(s)); > + > + LIBXL__LOG(libxl__gc_owner(gc), LIBXL__LOG_ERROR, > + "yajl error: %s", str); > + yajl_free_error(yajl_ctx.hand, str); > + > + libxl__json_object_free(gc, yajl_ctx.head); > + yajl_ctx_free(&yajl_ctx); > + return NULL; > + } > +} > -- > Anthony PERARD > _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel From xen-devel-bounces@lists.xensource.com Wed Sep 21 06:53:33 2011 Return-path: <xen-devel-bounces@lists.xensource.com> Envelope-to: www-data@lists.xensource.com Delivery-date: Wed, 21 Sep 2011 06:53:33 -0700 Received: from localhost ([127.0.0.1] helo=lists.colo.xensource.com) by lists.xensource.com with esmtp (Exim 4.43) id 1R6NEz-0006N1-3h; Wed, 21 Sep 2011 06:53:33 -0700 Received: from mail21.messagelabs.com ([85.158.143.35]) by lists.xensource.com with esmtp (Exim 4.43) id 1R6NDn-00060z-SE for xen-devel@lists.xensource.com; Wed, 21 Sep 2011 06:52:21 -0700 X-Env-Sender: Ian.Campbell@eu.citrix.com X-Msg-Ref: server-15.tower-21.messagelabs.com!1316613138!51438558!1 X-Originating-IP: [62.200.22.115] X-StarScan-Version: 6.4.1; banners=-,-,- X-VirusChecked: Checked Received: (qmail 26906 invoked from network); 21 Sep 2011 13:52:18 -0000 Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115) by server-15.tower-21.messagelabs.com with RC4-SHA encrypted SMTP; 21 Sep 2011 13:52:18 -0000 X-IronPort-AV: E=Sophos;i="4.68,417,1312156800"; d="scan'208";a="7981351" Received: from lonpmailmx01.citrite.net ([10.30.203.162]) by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5; 21 Sep 2011 13:52:16 +0000 Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net (10.30.203.162) with Microsoft SMTP Server id 8.3.137.0; Wed, 21 Sep 2011 14:52:16 +0100 From: Ian Campbell <Ian.Campbell@eu.citrix.com> To: Anthony PERARD <anthony.perard@citrix.com> Date: Wed, 21 Sep 2011 14:52:15 +0100 In-Reply-To: <1316609997-26002-8-git-send-email-anthony.perard@citrix.com> References: <1316609997-26002-1-git-send-email-anthony.perard@citrix.com> <1316609997-26002-8-git-send-email-anthony.perard@citrix.com> Organization: Citrix Systems, Inc. Content-Type: text/plain; charset="UTF-8" X-Mailer: Evolution 3.0.3- Content-Transfer-Encoding: 7bit Message-ID: <1316613136.3891.197.camel@zakaz.uk.xensource.com> MIME-Version: 1.0 Cc: Xen Devel <xen-devel@lists.xensource.com>, Stefano Stabellini <Stefano.Stabellini@eu.citrix.com> Subject: [Xen-devel] Re: [PATCH RESEND V8 7/7] libxl: Introduce a QMP client X-BeenThere: xen-devel@lists.xensource.com X-Mailman-Version: 2.1.5 Precedence: list List-Id: Xen developer discussion <xen-devel.lists.xensource.com> List-Unsubscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe> List-Post: <mailto:xen-devel@lists.xensource.com> List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help> List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=subscribe> Sender: xen-devel-bounces@lists.xensource.com Errors-To: xen-devel-bounces@lists.xensource.com On Wed, 2011-09-21 at 13:59 +0100, Anthony PERARD wrote: > QMP stands for QEMU Monitor Protocol and it is used to query information > from QEMU or to control QEMU. > > This implementation will ask QEMU the list of chardevice and store the > path to serial ports in xenstored. So we will be able to use xl console > with QEMU upstream. > > In order to connect to the QMP server, a socket file is created in > /var/run/xen/qmp-libxl-$(domid). > > Signed-off-by: Anthony PERARD <anthony.perard@citrix.com> Again I didn't fully review but I remember being happy with it lasttime so: Acked-by: Ian Campbell <ian.campbell@citrix.com> > --- > tools/libxl/Makefile | 2 +- > tools/libxl/libxl.c | 2 + > tools/libxl/libxl_create.c | 4 + > tools/libxl/libxl_dm.c | 10 + > tools/libxl/libxl_internal.h | 19 ++ > tools/libxl/libxl_qmp.c | 587 ++++++++++++++++++++++++++++++++++++++++++ > 6 files changed, 623 insertions(+), 1 deletions(-) > create mode 100644 tools/libxl/libxl_qmp.c > > diff --git a/tools/libxl/Makefile b/tools/libxl/Makefile > index e50874e..f10c7e8 100644 > --- a/tools/libxl/Makefile > +++ b/tools/libxl/Makefile > @@ -37,7 +37,7 @@ LIBXL_LIBS += -lyajl > LIBXL_OBJS = flexarray.o libxl.o libxl_create.o libxl_dm.o libxl_pci.o \ > libxl_dom.o libxl_exec.o libxl_xshelp.o libxl_device.o \ > libxl_internal.o libxl_utils.o libxl_uuid.o libxl_json.o \ > - $(LIBXL_OBJS-y) > + libxl_qmp.o $(LIBXL_OBJS-y) > LIBXL_OBJS += _libxl_types.o libxl_flask.o _libxl_types_internal.o > > $(LIBXL_OBJS): CFLAGS += $(CFLAGS_libxenctrl) $(CFLAGS_libxenguest) $(CFLAGS_libxenstore) $(CFLAGS_libblktapctl) > diff --git a/tools/libxl/libxl.c b/tools/libxl/libxl.c > index 426058f..fbd522d 100644 > --- a/tools/libxl/libxl.c > +++ b/tools/libxl/libxl.c > @@ -762,6 +762,8 @@ int libxl_domain_destroy(libxl_ctx *ctx, uint32_t domid, int force) > if (dm_present) { > if (libxl__destroy_device_model(&gc, domid) < 0) > LIBXL__LOG(ctx, LIBXL__LOG_ERROR, "libxl__destroy_device_model failed for %d", domid); > + > + libxl__qmp_cleanup(&gc, domid); > } > if (libxl__devices_destroy(&gc, domid, force) < 0) > LIBXL__LOG(ctx, LIBXL__LOG_ERROR, "libxl_destroy_devices failed for %d", domid); > diff --git a/tools/libxl/libxl_create.c b/tools/libxl/libxl_create.c > index ce76729..c97819a 100644 > --- a/tools/libxl/libxl_create.c > +++ b/tools/libxl/libxl_create.c > @@ -573,6 +573,10 @@ static int do_domain_create(libxl__gc *gc, libxl_domain_config *d_config, > } > > if (dm_starting) { > + if (dm_info->device_model_version > + == LIBXL_DEVICE_MODEL_VERSION_QEMU_XEN) { > + libxl__qmp_initializations(ctx, domid); > + } > ret = libxl__confirm_device_model_startup(gc, dm_starting); > if (ret < 0) { > LIBXL__LOG(ctx, LIBXL__LOG_ERROR, > diff --git a/tools/libxl/libxl_dm.c b/tools/libxl/libxl_dm.c > index e854a50..ef09079 100644 > --- a/tools/libxl/libxl_dm.c > +++ b/tools/libxl/libxl_dm.c > @@ -248,6 +248,16 @@ static char ** libxl__build_device_model_args_new(libxl__gc *gc, > flexarray_vappend(dm_args, dm, > "-xen-domid", libxl__sprintf(gc, "%d", info->domid), NULL); > > + flexarray_append(dm_args, "-chardev"); > + flexarray_append(dm_args, > + libxl__sprintf(gc, "socket,id=libxl-cmd," > + "path=%s/qmp-libxl-%d,server,nowait", > + libxl_run_dir_path(), > + info->domid)); > + > + flexarray_append(dm_args, "-mon"); > + flexarray_append(dm_args, "chardev=libxl-cmd,mode=control"); > + > if (info->type == LIBXL_DOMAIN_TYPE_PV) { > flexarray_append(dm_args, "-xen-attach"); > } > diff --git a/tools/libxl/libxl_internal.h b/tools/libxl/libxl_internal.h > index f495e86..2ea1582 100644 > --- a/tools/libxl/libxl_internal.h > +++ b/tools/libxl/libxl_internal.h > @@ -387,6 +387,25 @@ _hidden int libxl__e820_alloc(libxl_ctx *ctx, uint32_t domid, libxl_domain_confi > #define STRINGIFY(x) #x > #define TOSTRING(x) STRINGIFY(x) > > +/* from libxl_qmp */ > +typedef struct libxl__qmp_handler libxl__qmp_handler; > + > +/* Initialise and connect to the QMP socket. > + * Return an handler or NULL if there is an error > + */ > +_hidden libxl__qmp_handler *libxl__qmp_initialize(libxl_ctx *ctx, > + uint32_t domid); > +/* ask to QEMU the serial port information and store it in xenstore. */ > +_hidden int libxl__qmp_query_serial(libxl__qmp_handler *qmp); > +/* close and free the QMP handler */ > +_hidden void libxl__qmp_close(libxl__qmp_handler *qmp); > +/* remove the socket file, if the file has already been removed, > + * nothing happen */ > +_hidden void libxl__qmp_cleanup(libxl__gc *gc, uint32_t domid); > + > +/* this helper calls qmp_initialize, query_serial and qmp_close */ > +_hidden int libxl__qmp_initializations(libxl_ctx *ctx, uint32_t domid); > + > /* from libxl_json */ > #include <yajl/yajl_gen.h> > > diff --git a/tools/libxl/libxl_qmp.c b/tools/libxl/libxl_qmp.c > new file mode 100644 > index 0000000..6e8ecea > --- /dev/null > +++ b/tools/libxl/libxl_qmp.c > @@ -0,0 +1,587 @@ > +/* > + * Copyright (C) 2011 Citrix Ltd. > + * Author Anthony PERARD <anthony.perard@citrix.com> > + * > + * This program is free software; you can redistribute it and/or modify > + * it under the terms of the GNU Lesser General Public License as published > + * by the Free Software Foundation; version 2.1 only. with the special > + * exception on linking described in file LICENSE. > + * > + * This program is distributed in the hope that it will be useful, > + * but WITHOUT ANY WARRANTY; without even the implied warranty of > + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the > + * GNU Lesser General Public License for more details. > + */ > + > +/* > + * This file implement a client for QMP (QEMU Monitor Protocol). For the > + * Specification, see in the QEMU repository. > + */ > + > +#include <unistd.h> > +#include <sys/un.h> > +#include <sys/queue.h> > + > +#include <yajl/yajl_gen.h> > + > +#include "libxl_internal.h" > + > +/* #define DEBUG_RECEIVED */ > + > +#ifdef DEBUG_RECEIVED > +# define DEBUG_REPORT_RECEIVED(buf, len) \ > + LIBXL__LOG(qmp->ctx, LIBXL__LOG_DEBUG, "received: '%.*s'", len, buf) > +#else > +# define DEBUG_REPORT_RECEIVED(buf, len) ((void)0) > +#endif > + > +/* > + * QMP types & constant > + */ > + > +#define QMP_RECEIVE_BUFFER_SIZE 4096 > + > +typedef int (*qmp_callback_t)(libxl__qmp_handler *qmp, > + const libxl__json_object *tree); > + > +typedef struct callback_id_pair { > + int id; > + qmp_callback_t callback; > + SIMPLEQ_ENTRY(callback_id_pair) next; > +} callback_id_pair; > + > +struct libxl__qmp_handler { > + struct sockaddr_un addr; > + int qmp_fd; > + bool connected; > + time_t timeout; > + /* wait_for_id will be used by the synchronous send function */ > + int wait_for_id; > + > + char buffer[QMP_RECEIVE_BUFFER_SIZE]; > + libxl__yajl_ctx *yajl_ctx; > + > + libxl_ctx *ctx; > + uint32_t domid; > + > + int last_id_used; > + SIMPLEQ_HEAD(callback_list, callback_id_pair) callback_list; > +}; > + > +static int qmp_send(libxl__qmp_handler *qmp, > + const char *cmd, qmp_callback_t callback); > + > +static const int QMP_SOCKET_CONNECT_TIMEOUT = 5; > + > +/* > + * QMP callbacks functions > + */ > + > +static int store_serial_port_info(libxl__qmp_handler *qmp, > + const char *chardev, > + int port) > +{ > + libxl__gc gc = LIBXL_INIT_GC(qmp->ctx); > + char *path = NULL; > + int ret = 0; > + > + if (!(chardev && strncmp("pty:", chardev, 4) == 0)) { > + return -1; > + } > + > + path = libxl__xs_get_dompath(&gc, qmp->domid); > + path = libxl__sprintf(&gc, "%s/serial/%d/tty", path, port); > + > + ret = libxl__xs_write(&gc, XBT_NULL, path, "%s", chardev + 4); > + > + libxl__free_all(&gc); > + return ret; > +} > + > +static int register_serials_chardev_callback(libxl__qmp_handler *qmp, > + const libxl__json_object *o) > +{ > + const libxl__json_object *obj = NULL; > + const libxl__json_object *label = NULL; > + const char *s = NULL; > + int i = 0; > + const char *chardev = NULL; > + int ret = 0; > + > + for (i = 0; (obj = libxl__json_array_get(o, i)); i++) { > + if (!libxl__json_object_is_map(obj)) > + continue; > + label = libxl__json_map_get("label", obj, JSON_STRING); > + s = libxl__json_object_get_string(label); > + > + if (s && strncmp("serial", s, strlen("serial")) == 0) { > + const libxl__json_object *filename = NULL; > + char *endptr = NULL; > + int port_number; > + > + filename = libxl__json_map_get("filename", obj, JSON_STRING); > + chardev = libxl__json_object_get_string(filename); > + > + s += strlen("serial"); > + port_number = strtol(s, &endptr, 10); > + if (*s == 0 || *endptr != 0) { > + LIBXL__LOG(qmp->ctx, LIBXL__LOG_ERROR, > + "Invalid serial port number: %s", s); > + return -1; > + } > + ret = store_serial_port_info(qmp, chardev, port_number); > + if (ret) { > + LIBXL__LOG_ERRNO(qmp->ctx, LIBXL__LOG_ERROR, > + "Failed to store serial port information" > + " in xenstore"); > + return ret; > + } > + } > + }; > + > + return ret; > +} > + > +static int qmp_capabilities_callback(libxl__qmp_handler *qmp, > + const libxl__json_object *o) > +{ > + qmp->connected = true; > + > + return 0; > +} > + > +/* > + * QMP commands > + */ > + > +static int enable_qmp_capabilities(libxl__qmp_handler *qmp) > +{ > + return qmp_send(qmp, "qmp_capabilities", qmp_capabilities_callback); > +} > + > +/* > + * Helpers > + */ > + > +static libxl__qmp_message_type qmp_response_type(libxl__qmp_handler *qmp, > + const libxl__json_object *o) > +{ > + libxl__qmp_message_type type; > + libxl__json_map_node *node = NULL; > + int i = 0; > + > + for (i = 0; (node = libxl__json_map_node_get(o, i)); i++) { > + if (libxl__qmp_message_type_from_string(node->map_key, &type) == 0) > + return type; > + } > + > + return LIBXL__QMP_MESSAGE_TYPE_INVALID; > +} > + > +static callback_id_pair *qmp_get_callback_from_id(libxl__qmp_handler *qmp, > + const libxl__json_object *o) > +{ > + const libxl__json_object *id_object = libxl__json_map_get("id", o, > + JSON_INTEGER); > + int id = -1; > + callback_id_pair *pp = NULL; > + > + if (id_object) { > + id = libxl__json_object_get_integer(id_object); > + > + SIMPLEQ_FOREACH(pp, &qmp->callback_list, next) { > + if (pp->id == id) { > + return pp; > + } > + } > + } > + return NULL; > +} > + > +static void qmp_handle_error_response(libxl__qmp_handler *qmp, > + const libxl__json_object *resp) > +{ > + callback_id_pair *pp = qmp_get_callback_from_id(qmp, resp); > + > + resp = libxl__json_map_get("error", resp, JSON_MAP); > + resp = libxl__json_map_get("desc", resp, JSON_STRING); > + > + if (pp) { > + pp->callback(qmp, NULL); > + if (pp->id == qmp->wait_for_id) { > + /* tell that the id have been processed */ > + qmp->wait_for_id = 0; > + } > + SIMPLEQ_REMOVE(&qmp->callback_list, pp, callback_id_pair, next); > + free(pp); > + } > + > + LIBXL__LOG(qmp->ctx, LIBXL__LOG_ERROR, > + "received an error message from QMP server: %s", > + libxl__json_object_get_string(resp)); > +} > + > +static int qmp_handle_response(libxl__qmp_handler *qmp, > + const libxl__json_object *resp) > +{ > + libxl__qmp_message_type type = LIBXL__QMP_MESSAGE_TYPE_INVALID; > + > + type = qmp_response_type(qmp, resp); > + LIBXL__LOG(qmp->ctx, LIBXL__LOG_DEBUG, > + "message type: %s", libxl__qmp_message_type_to_string(type)); > + > + switch (type) { > + case LIBXL__QMP_MESSAGE_TYPE_QMP: > + /* On the greeting message from the server, enable QMP capabilities */ > + enable_qmp_capabilities(qmp); > + break; > + case LIBXL__QMP_MESSAGE_TYPE_RETURN: { > + callback_id_pair *pp = qmp_get_callback_from_id(qmp, resp); > + > + if (pp) { > + pp->callback(qmp, > + libxl__json_map_get("return", resp, JSON_ANY)); > + if (pp->id == qmp->wait_for_id) { > + /* tell that the id have been processed */ > + qmp->wait_for_id = 0; > + } > + SIMPLEQ_REMOVE(&qmp->callback_list, pp, callback_id_pair, next); > + free(pp); > + } > + break; > + } > + case LIBXL__QMP_MESSAGE_TYPE_ERROR: > + qmp_handle_error_response(qmp, resp); > + break; > + case LIBXL__QMP_MESSAGE_TYPE_EVENT: > + break; > + case LIBXL__QMP_MESSAGE_TYPE_INVALID: > + return -1; > + } > + return 0; > +} > + > +/* > + * Handler functions > + */ > + > +static libxl__qmp_handler *qmp_init_handler(libxl_ctx *ctx, uint32_t domid) > +{ > + libxl__qmp_handler *qmp = NULL; > + > + qmp = calloc(1, sizeof (libxl__qmp_handler)); > + if (qmp == NULL) { > + LIBXL__LOG_ERRNO(ctx, LIBXL__LOG_ERROR, > + "Failed to allocate qmp_handler"); > + return NULL; > + } > + qmp->ctx = ctx; > + qmp->domid = domid; > + qmp->timeout = 5; > + > + SIMPLEQ_INIT(&qmp->callback_list); > + > + return qmp; > +} > + > +static int qmp_open(libxl__qmp_handler *qmp, const char *qmp_socket_path, > + int timeout) > +{ > + int ret; > + int i = 0; > + > + qmp->qmp_fd = socket(AF_UNIX, SOCK_STREAM | SOCK_NONBLOCK, 0); > + if (qmp->qmp_fd < 0) { > + return -1; > + } > + > + memset(&qmp->addr, 0, sizeof (&qmp->addr)); > + qmp->addr.sun_family = AF_UNIX; > + strncpy(qmp->addr.sun_path, qmp_socket_path, > + sizeof (qmp->addr.sun_path)); > + > + do { > + ret = connect(qmp->qmp_fd, (struct sockaddr *) &qmp->addr, > + sizeof (qmp->addr)); > + if (ret == 0) > + break; > + if (errno == ENOENT || errno == ECONNREFUSED) { > + /* ENOENT : Socket may not have shown up yet > + * ECONNREFUSED : Leftover socket hasn't been removed yet */ > + continue; > + } > + return -1; > + } while ((++i / 5 <= timeout) && (usleep(200 * 1000) <= 0)); > + > + return ret; > +} > + > +static void qmp_close(libxl__qmp_handler *qmp) > +{ > + callback_id_pair *pp = NULL; > + callback_id_pair *tmp = NULL; > + > + close(qmp->qmp_fd); > + SIMPLEQ_FOREACH(pp, &qmp->callback_list, next) { > + if (tmp) > + free(tmp); > + tmp = pp; > + } > + if (tmp) > + free(tmp); > +} > + > +static int qmp_next(libxl__gc *gc, libxl__qmp_handler *qmp) > +{ > + ssize_t rd; > + char *s = NULL; > + char *s_end = NULL; > + > + char *incomplete = NULL; > + size_t incomplete_size = 0; > + > + do { > + fd_set rfds; > + int ret = 0; > + struct timeval timeout = { > + .tv_sec = qmp->timeout, > + .tv_usec = 0, > + }; > + > + FD_ZERO(&rfds); > + FD_SET(qmp->qmp_fd, &rfds); > + > + ret = select(qmp->qmp_fd + 1, &rfds, NULL, NULL, &timeout); > + if (ret == 0) { > + LIBXL__LOG(qmp->ctx, LIBXL__LOG_ERROR, "timeout"); > + return -1; > + } else if (ret < 0) { > + LIBXL__LOG_ERRNO(qmp->ctx, LIBXL__LOG_ERROR, "Select error"); > + return -1; > + } > + > + rd = read(qmp->qmp_fd, qmp->buffer, QMP_RECEIVE_BUFFER_SIZE); > + if (rd == 0) { > + continue; > + } else if (rd < 0) { > + LIBXL__LOG_ERRNO(qmp->ctx, LIBXL__LOG_ERROR, "Socket read error"); > + return rd; > + } > + > + DEBUG_REPORT_RECEIVED(qmp->buffer, rd); > + > + do { > + char *end = NULL; > + if (incomplete) { > + size_t current_pos = s - incomplete; > + incomplete_size += rd; > + incomplete = libxl__realloc(gc, incomplete, > + incomplete_size + 1); > + incomplete = strncat(incomplete, qmp->buffer, rd); > + s = incomplete + current_pos; > + s_end = incomplete + incomplete_size; > + } else { > + incomplete = libxl__strndup(gc, qmp->buffer, rd); > + incomplete_size = rd; > + s = incomplete; > + s_end = s + rd; > + } > + > + end = strstr(s, "\r\n"); > + if (end) { > + libxl__json_object *o = NULL; > + > + *end = '\0'; > + > + o = libxl__json_parse(gc, s); > + s = end + 2; > + > + if (o) { > + qmp_handle_response(qmp, o); > + libxl__json_object_free(gc, o); > + } else { > + LIBXL__LOG(qmp->ctx, LIBXL__LOG_ERROR, > + "Parse error of : %s\n", s); > + return -1; > + } > + } else { > + break; > + } > + } while (s < s_end); > + } while (s < s_end); > + > + return 1; > +} > + > +static int qmp_send(libxl__qmp_handler *qmp, > + const char *cmd, qmp_callback_t callback) > +{ > + yajl_gen_config conf = { 0, NULL }; > + const unsigned char *buf; > + unsigned int len = 0; > + yajl_gen_status s; > + yajl_gen hand; > + > + hand = yajl_gen_alloc(&conf, NULL); > + if (!hand) { > + return -1; > + } > + > + yajl_gen_map_open(hand); > + libxl__yajl_gen_asciiz(hand, "execute"); > + libxl__yajl_gen_asciiz(hand, cmd); > + libxl__yajl_gen_asciiz(hand, "id"); > + yajl_gen_integer(hand, ++qmp->last_id_used); > + yajl_gen_map_close(hand); > + > + s = yajl_gen_get_buf(hand, &buf, &len); > + > + if (s) { > + LIBXL__LOG(qmp->ctx, LIBXL__LOG_ERROR, > + "Failed to generate a qmp command"); > + return -1; > + } > + > + if (callback) { > + callback_id_pair *elm = malloc(sizeof (callback_id_pair)); > + if (elm == NULL) { > + LIBXL__LOG_ERRNO(qmp->ctx, LIBXL__LOG_ERROR, > + "Failed to allocate a QMP callback"); > + yajl_gen_free(hand); > + return -1; > + } > + elm->id = qmp->last_id_used; > + elm->callback = callback; > + SIMPLEQ_INSERT_TAIL(&qmp->callback_list, elm, next); > + } > + > + LIBXL__LOG(qmp->ctx, LIBXL__LOG_DEBUG, "next qmp command: '%s'", buf); > + > + if (libxl_write_exactly(qmp->ctx, qmp->qmp_fd, buf, len, > + "QMP command", "QMP socket")) > + goto error; > + if (libxl_write_exactly(qmp->ctx, qmp->qmp_fd, "\r\n", 2, > + "CRLF", "QMP socket")) > + goto error; > + > + yajl_gen_free(hand); > + > + return qmp->last_id_used; > + > +error: > + yajl_gen_free(hand); > + return -1; > +} > + > +static int qmp_synchronous_send(libxl__qmp_handler *qmp, const char *cmd, > + qmp_callback_t callback, int ask_timeout) > +{ > + int id = 0; > + int ret = 0; > + libxl__gc gc = LIBXL_INIT_GC(qmp->ctx); > + > + id = qmp_send(qmp, cmd, callback); > + if (id <= 0) { > + return -1; > + } > + qmp->wait_for_id = id; > + > + while (qmp->wait_for_id == id) { > + if ((ret = qmp_next(&gc, qmp)) < 0) { > + return ret; > + } > + } > + > + libxl__free_all(&gc); > + > + return 0; > +} > + > +static void qmp_free_handler(libxl__qmp_handler *qmp) > +{ > + free(qmp); > +} > + > +/* > + * API > + */ > + > +libxl__qmp_handler *libxl__qmp_initialize(libxl_ctx *ctx, uint32_t domid) > +{ > + int ret = 0; > + libxl__qmp_handler *qmp = NULL; > + char *qmp_socket; > + libxl__gc gc = LIBXL_INIT_GC(ctx); > + > + qmp = qmp_init_handler(ctx, domid); > + > + qmp_socket = libxl__sprintf(&gc, "%s/qmp-libxl-%d", > + libxl_run_dir_path(), domid); > + if ((ret = qmp_open(qmp, qmp_socket, QMP_SOCKET_CONNECT_TIMEOUT)) < 0) { > + LIBXL__LOG_ERRNO(ctx, LIBXL__LOG_ERROR, "Connection error"); > + libxl__free_all(&gc); > + qmp_free_handler(qmp); > + return NULL; > + } > + > + LIBXL__LOG(qmp->ctx, LIBXL__LOG_DEBUG, "connected to %s", qmp_socket); > + > + /* Wait for the response to qmp_capabilities */ > + while (!qmp->connected) { > + if ((ret = qmp_next(&gc, qmp)) < 0) { > + break; > + } > + } > + > + libxl__free_all(&gc); > + if (!qmp->connected) { > + LIBXL__LOG(ctx, LIBXL__LOG_ERROR, "Failed to connect to QMP"); > + libxl__qmp_close(qmp); > + return NULL; > + } > + return qmp; > +} > + > +void libxl__qmp_close(libxl__qmp_handler *qmp) > +{ > + if (!qmp) > + return; > + qmp_close(qmp); > + qmp_free_handler(qmp); > +} > + > +void libxl__qmp_cleanup(libxl__gc *gc, uint32_t domid) > +{ > + libxl_ctx *ctx = libxl__gc_owner(gc); > + char *qmp_socket; > + > + qmp_socket = libxl__sprintf(gc, "%s/qmp-libxl-%d", > + libxl_run_dir_path(), domid); > + if (unlink(qmp_socket) == -1) { > + if (errno != ENOENT) { > + LIBXL__LOG_ERRNO(ctx, LIBXL__LOG_ERROR, > + "Failed to remove QMP socket file %s", > + qmp_socket); > + } > + } > +} > + > +int libxl__qmp_query_serial(libxl__qmp_handler *qmp) > +{ > + return qmp_synchronous_send(qmp, "query-chardev", > + register_serials_chardev_callback, > + qmp->timeout); > +} > + > +int libxl__qmp_initializations(libxl_ctx *ctx, uint32_t domid) > +{ > + libxl__qmp_handler *qmp = NULL; > + int ret = 0; > + > + qmp = libxl__qmp_initialize(ctx, domid); > + if (!qmp) > + return -1; > + ret = libxl__qmp_query_serial(qmp); > + libxl__qmp_close(qmp); > + return ret; > +} > -- > Anthony PERARD > _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel From xen-devel-bounces@lists.xensource.com Wed Sep 21 06:54:52 2011 Return-path: <xen-devel-bounces@lists.xensource.com> Envelope-to: www-data@lists.xensource.com Delivery-date: Wed, 21 Sep 2011 06:54:52 -0700 Received: from localhost ([127.0.0.1] helo=lists.colo.xensource.com) by lists.xensource.com with esmtp (Exim 4.43) id 1R6NGF-0006pP-R1; Wed, 21 Sep 2011 06:54:51 -0700 Received: from mail21.messagelabs.com ([85.158.143.35]) by lists.xensource.com with esmtp (Exim 4.43) id 1R6NFf-0006aa-KO for xen-devel@lists.xensource.com; Wed, 21 Sep 2011 06:54:16 -0700 X-Env-Sender: Ian.Campbell@eu.citrix.com X-Msg-Ref: server-12.tower-21.messagelabs.com!1316613235!50799135!1 X-Originating-IP: [66.165.176.63] X-StarScan-Version: 6.4.1; banners=-,-,- X-VirusChecked: Checked Received: (qmail 17656 invoked from network); 21 Sep 2011 13:53:57 -0000 Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63) by server-12.tower-21.messagelabs.com with RC4-SHA encrypted SMTP; 21 Sep 2011 13:53:57 -0000 X-IronPort-AV: E=Sophos;i="4.68,417,1312171200"; d="scan'208";a="164125879" Received: from ftlpmailmx02.citrite.net ([10.13.107.66]) by FTLPIPO02.CITRIX.COM with ESMTP/TLS/RC4-MD5; 21 Sep 2011 09:54:11 -0400 Received: from smtp01.ad.xensource.com (10.219.128.104) by smtprelay.citrix.com (10.13.107.66) with Microsoft SMTP Server id 8.3.137.0; Wed, 21 Sep 2011 09:54:10 -0400 Received: from cosworth.uk.xensource.com (cosworth.uk.xensource.com [10.80.16.52]) by smtp01.ad.xensource.com (8.13.1/8.13.1) with ESMTP id p8LDs91Y024468; Wed, 21 Sep 2011 06:54:09 -0700 Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Mercurial-Node: b43fd821d1aebc8671e684bfc285cda7a6002ff1 Message-ID: <b43fd821d1aebc8671e6.1316613248@cosworth.uk.xensource.com> User-Agent: Mercurial-patchbomb/1.6.4 Date: Wed, 21 Sep 2011 14:54:08 +0100 From: Ian Campbell <ian.campbell@citrix.com> To: xen-devel@lists.xensource.com Cc: Ian Campbell <ian.campbell@citrix.com> Subject: [Xen-devel] [PATCH] libxl: attempt to cleanup tapdisk processes on disk backend destroy X-BeenThere: xen-devel@lists.xensource.com X-Mailman-Version: 2.1.5 Precedence: list List-Id: Xen developer discussion <xen-devel.lists.xensource.com> List-Unsubscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe> List-Post: <mailto:xen-devel@lists.xensource.com> List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help> List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=subscribe> Sender: xen-devel-bounces@lists.xensource.com Errors-To: xen-devel-bounces@lists.xensource.com # HG changeset patch # User Ian Campbell <ian.campbell@citrix.com> # Date 1316609964 -3600 # Node ID b43fd821d1aebc8671e684bfc285cda7a6002ff1 # Parent 206afa070919e3fe0b13a03f870ca2da44ab604a libxl: attempt to cleanup tapdisk processes on disk backend destroy. Signed-off-by: Ian Campbell <ian.campbell@citrix.com> diff -r 206afa070919 -r b43fd821d1ae tools/blktap2/control/tap-ctl-list.c --- a/tools/blktap2/control/tap-ctl-list.c Wed Sep 21 13:59:24 2011 +0100 +++ b/tools/blktap2/control/tap-ctl-list.c Wed Sep 21 13:59:24 2011 +0100 @@ -506,17 +506,15 @@ out: } int -tap_ctl_find_minor(const char *type, const char *path) +tap_ctl_find(const char *type, const char *path, tap_list_t *tap) { tap_list_t **list, **_entry; - int minor, err; + int ret = -ENOENT, err; err = tap_ctl_list(&list); if (err) return err; - minor = -1; - for (_entry = list; *_entry != NULL; ++_entry) { tap_list_t *entry = *_entry; @@ -526,11 +524,13 @@ tap_ctl_find_minor(const char *type, con if (path && (!entry->path || strcmp(entry->path, path))) continue; - minor = entry->minor; + *tap = *entry; + tap->type = tap->path = NULL; + ret = 0; break; } tap_ctl_free_list(list); - return minor >= 0 ? minor : -ENOENT; + return ret; } diff -r 206afa070919 -r b43fd821d1ae tools/blktap2/control/tap-ctl.h --- a/tools/blktap2/control/tap-ctl.h Wed Sep 21 13:59:24 2011 +0100 +++ b/tools/blktap2/control/tap-ctl.h Wed Sep 21 13:59:24 2011 +0100 @@ -76,7 +76,7 @@ int tap_ctl_get_driver_id(const char *ha int tap_ctl_list(tap_list_t ***list); void tap_ctl_free_list(tap_list_t **list); -int tap_ctl_find_minor(const char *type, const char *path); +int tap_ctl_find(const char *type, const char *path, tap_list_t *tap); int tap_ctl_allocate(int *minor, char **devname); int tap_ctl_free(const int minor); diff -r 206afa070919 -r b43fd821d1ae tools/libxl/libxl_blktap2.c --- a/tools/libxl/libxl_blktap2.c Wed Sep 21 13:59:24 2011 +0100 +++ b/tools/libxl/libxl_blktap2.c Wed Sep 21 13:59:24 2011 +0100 @@ -18,6 +18,8 @@ #include "tap-ctl.h" +#include <string.h> + int libxl__blktap_enabled(libxl__gc *gc) { const char *msg; @@ -30,12 +32,13 @@ char *libxl__blktap_devpath(libxl__gc *g { const char *type; char *params, *devname = NULL; - int minor, err; + tap_list_t tap; + int err; type = libxl__device_disk_string_of_format(format); - minor = tap_ctl_find_minor(type, disk); - if (minor >= 0) { - devname = libxl__sprintf(gc, "/dev/xen/blktap-2/tapdev%d", minor); + err = tap_ctl_find(type, disk, &tap); + if (err == 0) { + devname = libxl__sprintf(gc, "/dev/xen/blktap-2/tapdev%d", tap.minor); if (devname) return devname; } @@ -49,3 +52,28 @@ char *libxl__blktap_devpath(libxl__gc *g return NULL; } + + +void libxl__device_destroy_tapdisk(libxl__gc *gc, char *be_path) +{ + char *path, *params, *type, *disk; + int err; + tap_list_t tap; + + path = libxl__sprintf(gc, "%s/tapdisk-params", be_path); + if (!path) return; + + params = libxl__xs_read(gc, XBT_NULL, path); + if (!params) return; + + type = params; + disk = strchr(params, ':'); + if (!disk) return; + + *disk++ = '\0'; + + err = tap_ctl_find(type, disk, &tap); + if (err < 0) return; + + tap_ctl_destroy(tap.id, tap.minor); +} diff -r 206afa070919 -r b43fd821d1ae tools/libxl/libxl_device.c --- a/tools/libxl/libxl_device.c Wed Sep 21 13:59:24 2011 +0100 +++ b/tools/libxl/libxl_device.c Wed Sep 21 13:59:24 2011 +0100 @@ -372,6 +372,7 @@ int libxl__device_destroy(libxl__gc *gc, if (!state) goto out; if (atoi(state) != 4) { + libxl__device_destroy_tapdisk(gc, be_path); xs_rm(ctx->xsh, XBT_NULL, be_path); goto out; } @@ -394,6 +395,7 @@ retry_transaction: } else { xs_rm(ctx->xsh, XBT_NULL, be_path); } + libxl__device_destroy_tapdisk(gc, be_path); out: return rc; } diff -r 206afa070919 -r b43fd821d1ae tools/libxl/libxl_internal.h --- a/tools/libxl/libxl_internal.h Wed Sep 21 13:59:24 2011 +0100 +++ b/tools/libxl/libxl_internal.h Wed Sep 21 13:59:24 2011 +0100 @@ -363,6 +363,12 @@ _hidden char *libxl__blktap_devpath(libx const char *disk, libxl_disk_format format); +/* libxl__device_destroy_tapdisk: + * Destroys any tapdisk process associated with the backend represented + * by be_path. + */ +_hidden void libxl__device_destroy_tapdisk(libxl__gc *gc, char *be_path); + _hidden char *libxl__uuid2string(libxl__gc *gc, const libxl_uuid uuid); struct libxl__xen_console_reader { diff -r 206afa070919 -r b43fd821d1ae tools/libxl/libxl_noblktap2.c --- a/tools/libxl/libxl_noblktap2.c Wed Sep 21 13:59:24 2011 +0100 +++ b/tools/libxl/libxl_noblktap2.c Wed Sep 21 13:59:24 2011 +0100 @@ -27,3 +27,7 @@ char *libxl__blktap_devpath(libxl__gc *g { return NULL; } + +void libxl__device_destroy_tapdisk(libxl__gc *gc, char *be_path) +{ +} _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel From xen-devel-bounces@lists.xensource.com Wed Sep 21 06:55:53 2011 Return-path: <xen-devel-bounces@lists.xensource.com> Envelope-to: www-data@lists.xensource.com Delivery-date: Wed, 21 Sep 2011 06:55:53 -0700 Received: from localhost ([127.0.0.1] helo=lists.colo.xensource.com) by lists.xensource.com with esmtp (Exim 4.43) id 1R6NHE-0007Cc-TC; Wed, 21 Sep 2011 06:55:52 -0700 Received: from mail27.messagelabs.com ([193.109.254.147]) by lists.xensource.com with esmtp (Exim 4.43) id 1R6NGF-0006oB-UM for xen-devel@lists.xensource.com; Wed, 21 Sep 2011 06:54:52 -0700 X-Env-Sender: Ian.Campbell@eu.citrix.com X-Msg-Ref: server-7.tower-27.messagelabs.com!1316613264!49581670!1 X-Originating-IP: [66.165.176.63] X-StarScan-Version: 6.4.1; banners=-,-,- X-VirusChecked: Checked Received: (qmail 16621 invoked from network); 21 Sep 2011 13:54:25 -0000 Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63) by server-7.tower-27.messagelabs.com with RC4-SHA encrypted SMTP; 21 Sep 2011 13:54:25 -0000 X-IronPort-AV: E=Sophos;i="4.68,417,1312171200"; d="scan'208";a="164125973" Received: from ftlpmailmx02.citrite.net ([10.13.107.66]) by FTLPIPO02.CITRIX.COM with ESMTP/TLS/RC4-MD5; 21 Sep 2011 09:54:47 -0400 Received: from smtp01.ad.xensource.com (10.219.128.104) by smtprelay.citrix.com (10.13.107.66) with Microsoft SMTP Server id 8.3.137.0; Wed, 21 Sep 2011 09:54:47 -0400 Received: from cosworth.uk.xensource.com (cosworth.uk.xensource.com [10.80.16.52]) by smtp01.ad.xensource.com (8.13.1/8.13.1) with ESMTP id p8LDsjZo024471; Wed, 21 Sep 2011 06:54:46 -0700 Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Mercurial-Node: b11af4a5cdc6a94e41a81d456f07b4d70cdb5ffe Message-ID: <b11af4a5cdc6a94e41a8.1316613284@cosworth.uk.xensource.com> User-Agent: Mercurial-patchbomb/1.6.4 Date: Wed, 21 Sep 2011 14:54:44 +0100 From: Ian Campbell <ian.campbell@citrix.com> To: xen-devel@lists.xensource.com Cc: Ian Campbell <ian.campbell@citrix.com> Subject: [Xen-devel] [PATCH] libxl: correct allocation size in libxl_list_nics X-BeenThere: xen-devel@lists.xensource.com X-Mailman-Version: 2.1.5 Precedence: list List-Id: Xen developer discussion <xen-devel.lists.xensource.com> List-Unsubscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe> List-Post: <mailto:xen-devel@lists.xensource.com> List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help> List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=subscribe> Sender: xen-devel-bounces@lists.xensource.com Errors-To: xen-devel-bounces@lists.xensource.com # HG changeset patch # User Ian Campbell <ian.campbell@citrix.com> # Date 1316609964 -3600 # Node ID b11af4a5cdc6a94e41a81d456f07b4d70cdb5ffe # Parent b43fd821d1aebc8671e684bfc285cda7a6002ff1 libxl: correct allocation size in libxl_list_nics The function returns a list of libxl_nicinfo not libxl_device_nic. Causes memory corruption on free. Signed-off-by: Ian Campbell <ian.campbell@citrix.com> diff -r b43fd821d1ae -r b11af4a5cdc6 tools/libxl/libxl.c --- a/tools/libxl/libxl.c Wed Sep 21 13:59:24 2011 +0100 +++ b/tools/libxl/libxl.c Wed Sep 21 13:59:24 2011 +0100 @@ -1296,7 +1296,7 @@ libxl_nicinfo *libxl_list_nics(libxl_ctx libxl__sprintf(&gc, "%s/device/vif", dompath), &nb_nics); if (!l) goto err; - nics = res = calloc(nb_nics, sizeof (libxl_device_nic)); + nics = res = calloc(nb_nics, sizeof (libxl_nicinfo)); if (!res) goto err; for (*nb = nb_nics; nb_nics > 0; --nb_nics, ++l, ++nics) { _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel From xen-devel-bounces@lists.xensource.com Wed Sep 21 06:56:55 2011 Return-path: <xen-devel-bounces@lists.xensource.com> Envelope-to: www-data@lists.xensource.com Delivery-date: Wed, 21 Sep 2011 06:56:55 -0700 Received: from localhost ([127.0.0.1] helo=lists.colo.xensource.com) by lists.xensource.com with esmtp (Exim 4.43) id 1R6NIF-0007Zt-5x; Wed, 21 Sep 2011 06:56:55 -0700 Received: from mail182.messagelabs.com ([85.158.139.83]) by lists.xensource.com with esmtp (Exim 4.43) id 1R6NGy-00074j-Ra for xen-devel@lists.xensource.com; Wed, 21 Sep 2011 06:55:37 -0700 X-Env-Sender: Ian.Campbell@eu.citrix.com X-Msg-Ref: server-6.tower-182.messagelabs.com!1316613332!19196286!1 X-Originating-IP: [66.165.176.89] X-StarScan-Version: 6.4.1; banners=-,-,- X-VirusChecked: Checked Received: (qmail 2204 invoked from network); 21 Sep 2011 13:55:33 -0000 Received: from smtp.citrix.com (HELO SMTP.CITRIX.COM) (66.165.176.89) by server-6.tower-182.messagelabs.com with RC4-SHA encrypted SMTP; 21 Sep 2011 13:55:33 -0000 X-IronPort-AV: E=Sophos;i="4.68,417,1312171200"; d="scan'208";a="17571141" Received: from ftlpmailmx02.citrite.net ([10.13.107.66]) by FTLPIPO01.CITRIX.COM with ESMTP/TLS/RC4-MD5; 21 Sep 2011 09:55:32 -0400 Received: from smtp01.ad.xensource.com (10.219.128.104) by smtprelay.citrix.com (10.13.107.66) with Microsoft SMTP Server id 8.3.137.0; Wed, 21 Sep 2011 09:55:32 -0400 Received: from cosworth.uk.xensource.com (cosworth.uk.xensource.com [10.80.16.52]) by smtp01.ad.xensource.com (8.13.1/8.13.1) with ESMTP id p8LDtU4r024474; Wed, 21 Sep 2011 06:55:31 -0700 Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Mercurial-Node: 4a6d34dffcf9d568a7830ee6de07a581c57e7342 Message-ID: <4a6d34dffcf9d568a783.1316613329@cosworth.uk.xensource.com> User-Agent: Mercurial-patchbomb/1.6.4 Date: Wed, 21 Sep 2011 14:55:29 +0100 From: Ian Campbell <ian.campbell@citrix.com> To: xen-devel@lists.xensource.com Cc: Ian Campbell <ian.campbell@citrix.com> Subject: [Xen-devel] [PATCH] libxl: correct allocation size in libxl_list_vm X-BeenThere: xen-devel@lists.xensource.com X-Mailman-Version: 2.1.5 Precedence: list List-Id: Xen developer discussion <xen-devel.lists.xensource.com> List-Unsubscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe> List-Post: <mailto:xen-devel@lists.xensource.com> List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help> List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=subscribe> Sender: xen-devel-bounces@lists.xensource.com Errors-To: xen-devel-bounces@lists.xensource.com # HG changeset patch # User Ian Campbell <ian.campbell@citrix.com> # Date 1316609964 -3600 # Node ID 4a6d34dffcf9d568a7830ee6de07a581c57e7342 # Parent b11af4a5cdc6a94e41a81d456f07b4d70cdb5ffe libxl: correct allocation size in libxl_list_vm *ptr has type libxl_vminfo not libxl_domid, so correct calloc call. This the second instance of this bug I've noticed recently, I did a quick audit of other similar uses of sizeof(...) and all I spotted were a couple of harmlessly reversed calloc arguments. It's a pretty strong argument for "foo = ..alloc(sizeof(*foo))" rather than "alloc(sizeof(foos_type))" though... Signed-off-by: Ian Campbell <ian.campbell@citrix.com> diff -r b11af4a5cdc6 -r 4a6d34dffcf9 tools/libxl/libxl.c --- a/tools/libxl/libxl.c Wed Sep 21 13:59:24 2011 +0100 +++ b/tools/libxl/libxl.c Wed Sep 21 13:59:24 2011 +0100 @@ -449,7 +449,7 @@ libxl_vminfo * libxl_list_vm(libxl_ctx * xc_domaininfo_t info[1024]; int size = 1024; - ptr = calloc(size, sizeof(libxl_dominfo)); + ptr = calloc(size, sizeof(libxl_vminfo)); if (!ptr) return NULL; diff -r b11af4a5cdc6 -r 4a6d34dffcf9 tools/libxl/libxl_dm.c --- a/tools/libxl/libxl_dm.c Wed Sep 21 13:59:24 2011 +0100 +++ b/tools/libxl/libxl_dm.c Wed Sep 21 13:59:24 2011 +0100 @@ -778,7 +778,7 @@ retry_transaction: libxl_domain_unpause(ctx, domid); if (starting_r) { - *starting_r = calloc(sizeof(libxl__device_model_starting), 1); + *starting_r = calloc(1, sizeof(libxl__device_model_starting)); (*starting_r)->domid = info->domid; (*starting_r)->dom_path = libxl__xs_get_dompath(gc, info->domid); (*starting_r)->for_spawn = NULL; @@ -855,11 +855,11 @@ int libxl__create_device_model(libxl__gc if (starting_r) { rc = ERROR_NOMEM; - *starting_r = calloc(sizeof(libxl__device_model_starting), 1); + *starting_r = calloc(1, sizeof(libxl__device_model_starting)); if (!*starting_r) goto out_close; p = *starting_r; - p->for_spawn = calloc(sizeof(libxl__spawn_starting), 1); + p->for_spawn = calloc(1, sizeof(libxl__spawn_starting)); } else { p = &buf_starting; p->for_spawn = NULL; _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel From xen-devel-bounces@lists.xensource.com Wed Sep 21 06:58:45 2011 Return-path: <xen-devel-bounces@lists.xensource.com> Envelope-to: www-data@lists.xensource.com Delivery-date: Wed, 21 Sep 2011 06:58:45 -0700 Received: from localhost ([127.0.0.1] helo=lists.colo.xensource.com) by lists.xensource.com with esmtp (Exim 4.43) id 1R6NJz-000821-Ui; Wed, 21 Sep 2011 06:58:44 -0700 Received: from mail21.messagelabs.com ([85.158.143.35]) by lists.xensource.com with esmtp (Exim 4.43) id 1R6NHW-0007KF-KB for xen-devel@lists.xensource.com; Wed, 21 Sep 2011 06:56:10 -0700 X-Env-Sender: Ian.Campbell@eu.citrix.com X-Msg-Ref: server-8.tower-21.messagelabs.com!1316613350!59831485!1 X-Originating-IP: [66.165.176.89] X-StarScan-Version: 6.4.1; banners=-,-,- X-VirusChecked: Checked Received: (qmail 20426 invoked from network); 21 Sep 2011 13:55:51 -0000 Received: from smtp.citrix.com (HELO SMTP.CITRIX.COM) (66.165.176.89) by server-8.tower-21.messagelabs.com with RC4-SHA encrypted SMTP; 21 Sep 2011 13:55:51 -0000 X-IronPort-AV: E=Sophos;i="4.68,417,1312171200"; d="scan'208";a="17571163" Received: from ftlpmailmx02.citrite.net ([10.13.107.66]) by FTLPIPO01.CITRIX.COM with ESMTP/TLS/RC4-MD5; 21 Sep 2011 09:56:05 -0400 Received: from smtp01.ad.xensource.com (10.219.128.104) by smtprelay.citrix.com (10.13.107.66) with Microsoft SMTP Server id 8.3.137.0; Wed, 21 Sep 2011 09:56:05 -0400 Received: from cosworth.uk.xensource.com (cosworth.uk.xensource.com [10.80.16.52]) by smtp01.ad.xensource.com (8.13.1/8.13.1) with ESMTP id p8LDu4qh024477; Wed, 21 Sep 2011 06:56:04 -0700 Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Mercurial-Node: 1b2f4f3c9f696270ba7e3c079b29536a39153956 Message-ID: <1b2f4f3c9f696270ba7e.1316613363@cosworth.uk.xensource.com> User-Agent: Mercurial-patchbomb/1.6.4 Date: Wed, 21 Sep 2011 14:56:03 +0100 From: Ian Campbell <ian.campbell@citrix.com> To: xen-devel@lists.xensource.com Cc: Ian Campbell <ian.campbell@citrix.com> Subject: [Xen-devel] [PATCH] libxl: fail to parse disk vpath if a disk+part number is required but unavailable X-BeenThere: xen-devel@lists.xensource.com X-Mailman-Version: 2.1.5 Precedence: list List-Id: Xen developer discussion <xen-devel.lists.xensource.com> List-Unsubscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe> List-Post: <mailto:xen-devel@lists.xensource.com> List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help> List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=subscribe> Sender: xen-devel-bounces@lists.xensource.com Errors-To: xen-devel-bounces@lists.xensource.com # HG changeset patch # User Ian Campbell <ian.campbell@citrix.com> # Date 1316609964 -3600 # Node ID 1b2f4f3c9f696270ba7e3c079b29536a39153956 # Parent 4a6d34dffcf9d568a7830ee6de07a581c57e7342 libxl: fail to parse disk vpath if a disk+part number is required but unavailable libxl__device_disk_dev_number() can parse a virtpath which is an encoded unsigned long but does not set *pdisk or *ppartition in that case. Ideally we would parse the number but for now simply fail to prevent cascading failures. Signed-off-by: Ian Campbell <ian.campbell@citrix.com> diff -r 4a6d34dffcf9 -r 1b2f4f3c9f69 tools/libxl/libxl_device.c --- a/tools/libxl/libxl_device.c Wed Sep 21 13:59:24 2011 +0100 +++ b/tools/libxl/libxl_device.c Wed Sep 21 13:59:24 2011 +0100 @@ -341,8 +341,12 @@ int libxl__device_disk_dev_number(const errno = 0; ul = strtoul(virtpath, &ep, 0); - if (!errno && !*ep && ul <= INT_MAX) + if (!errno && !*ep && ul <= INT_MAX) { + /* FIXME: should parse ul to determine these. */ + if (pdisk || ppartition) + return -1; return ul; + } if (device_virtdisk_matches(virtpath, "hd", &disk, 3, _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel From xen-devel-bounces@lists.xensource.com Wed Sep 21 07:08:55 2011 Return-path: <xen-devel-bounces@lists.xensource.com> Envelope-to: www-data@lists.xensource.com Delivery-date: Wed, 21 Sep 2011 07:08:55 -0700 Received: from localhost ([127.0.0.1] helo=lists.colo.xensource.com) by lists.xensource.com with esmtp (Exim 4.43) id 1R6NTp-0000o5-Mu; Wed, 21 Sep 2011 07:08:55 -0700 Received: from mail27.messagelabs.com ([193.109.254.147]) by lists.xensource.com with esmtp (Exim 4.43) id 1R6NI5-0007Xa-I3 for xen-devel@lists.xensource.com; Wed, 21 Sep 2011 06:56:46 -0700 X-Env-Sender: Ian.Campbell@eu.citrix.com X-Msg-Ref: server-9.tower-27.messagelabs.com!1316613384!45453415!1 X-Originating-IP: [66.165.176.89] X-StarScan-Version: 6.4.1; banners=-,-,- X-VirusChecked: Checked Received: (qmail 21939 invoked from network); 21 Sep 2011 13:56:25 -0000 Received: from smtp.citrix.com (HELO SMTP.CITRIX.COM) (66.165.176.89) by server-9.tower-27.messagelabs.com with RC4-SHA encrypted SMTP; 21 Sep 2011 13:56:25 -0000 X-IronPort-AV: E=Sophos;i="4.68,417,1312171200"; d="scan'208";a="17571173" Received: from ftlpmailmx02.citrite.net ([10.13.107.66]) by FTLPIPO01.CITRIX.COM with ESMTP/TLS/RC4-MD5; 21 Sep 2011 09:56:40 -0400 Received: from smtp01.ad.xensource.com (10.219.128.104) by smtprelay.citrix.com (10.13.107.66) with Microsoft SMTP Server id 8.3.137.0; Wed, 21 Sep 2011 09:56:40 -0400 Received: from cosworth.uk.xensource.com (cosworth.uk.xensource.com [10.80.16.52]) by smtp01.ad.xensource.com (8.13.1/8.13.1) with ESMTP id p8LDudN5024480; Wed, 21 Sep 2011 06:56:39 -0700 Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Mercurial-Node: 41cd57151203cf78a12ee1748bcce5475b181ad6 Message-ID: <41cd57151203cf78a12e.1316613398@cosworth.uk.xensource.com> User-Agent: Mercurial-patchbomb/1.6.4 Date: Wed, 21 Sep 2011 14:56:38 +0100 From: Ian Campbell <ian.campbell@citrix.com> To: xen-devel@lists.xensource.com Cc: Ian Campbell <ian.campbell@citrix.com> Subject: [Xen-devel] [PATCH] tools: fix install of lomount X-BeenThere: xen-devel@lists.xensource.com X-Mailman-Version: 2.1.5 Precedence: list List-Id: Xen developer discussion <xen-devel.lists.xensource.com> List-Unsubscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe> List-Post: <mailto:xen-devel@lists.xensource.com> List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help> List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=subscribe> Sender: xen-devel-bounces@lists.xensource.com Errors-To: xen-devel-bounces@lists.xensource.com # HG changeset patch # User Ian Campbell <ian.campbell@citrix.com> # Date 1316609964 -3600 # Node ID 41cd57151203cf78a12ee1748bcce5475b181ad6 # Parent 1b2f4f3c9f696270ba7e3c079b29536a39153956 tools: fix install of lomount $(BIN) went away in 23124:e3d4c34b14a3. Also there are no *.so, *.a or *.rpm built in here Signed-off-by: Ian Campbell <ian.campbell@citrix.com> diff -r 1b2f4f3c9f69 -r 41cd57151203 tools/misc/lomount/Makefile --- a/tools/misc/lomount/Makefile Wed Sep 21 13:59:24 2011 +0100 +++ b/tools/misc/lomount/Makefile Wed Sep 21 13:59:24 2011 +0100 @@ -11,11 +11,11 @@ build: lomount .PHONY: install install install-recurse: build - $(INSTALL_PROG) $(BIN) $(SCRIPTS) $(DESTDIR)$(BINDIR) + $(INSTALL_PROG) lomount $(SCRIPTS) $(DESTDIR)$(BINDIR) .PHONY: clean clean: - $(RM) *.a *.so *.o *.rpm $(BIN) + $(RM) *.o lomount lomount: lomount.o $(CC) $(CFLAGS) -o $@ $< _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel From xen-devel-bounces@lists.xensource.com Wed Sep 21 07:11:21 2011 Return-path: <xen-devel-bounces@lists.xensource.com> Envelope-to: www-data@lists.xensource.com Delivery-date: Wed, 21 Sep 2011 07:11:21 -0700 Received: from localhost ([127.0.0.1] helo=lists.colo.xensource.com) by lists.xensource.com with esmtp (Exim 4.43) id 1R6NWC-0001Je-1m; Wed, 21 Sep 2011 07:11:20 -0700 Received: from mail21.messagelabs.com ([85.158.143.35]) by lists.xensource.com with esmtp (Exim 4.43) id 1R6NI8-0007YV-QK for xen-devel@lists.xensource.com; Wed, 21 Sep 2011 06:56:49 -0700 X-Env-Sender: komkon555@freenet.de X-Msg-Ref: server-14.tower-21.messagelabs.com!1316613396!60434717!1 X-Originating-IP: [216.139.236.26] X-StarScan-Version: 6.4.1; banners=-,-,- X-VirusChecked: Checked Received: (qmail 4482 invoked from network); 21 Sep 2011 13:56:37 -0000 Received: from sam.nabble.com (HELO sam.nabble.com) (216.139.236.26) by server-14.tower-21.messagelabs.com with AES256-SHA encrypted SMTP; 21 Sep 2011 13:56:37 -0000 Received: from [192.168.236.26] (helo=sam.nabble.com) by sam.nabble.com with esmtp (Exim 4.72) (envelope-from <komkon555@freenet.de>) id 1R6NI4-0001VE-9e for xen-devel@lists.xensource.com; Wed, 21 Sep 2011 06:56:44 -0700 Date: Wed, 21 Sep 2011 06:56:44 -0700 (PDT) From: komkon555 <komkon555@freenet.de> To: xen-devel@lists.xensource.com Message-ID: <1316613404292-4826432.post@n5.nabble.com> In-Reply-To: <1316612652132-4826391.post@n5.nabble.com> References: <1315310225039-4774097.post@n5.nabble.com> <1315343879.61837.YahooMailNeo@web29818.mail.ird.yahoo.com> <1315382742268-4777689.post@n5.nabble.com> <1315389138.56652.YahooMailNeo@web29801.mail.ird.yahoo.com> <1315398360680-4778339.post@n5.nabble.com> <1315401901083-4778494.post@n5.nabble.com> <1315403644525-4778586.post@n5.nabble.com> <1315405372.87224.YahooMailNeo@web29801.mail.ird.yahoo.com> <1315405921936-4778727.post@n5.nabble.com> <1316612652132-4826391.post@n5.nabble.com> Subject: Re: Re : Re : Re : [Xen-devel] Re: Patches for VGA-Passthrough XEN 4.2 unstable MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-BeenThere: xen-devel@lists.xensource.com X-Mailman-Version: 2.1.5 Precedence: list List-Id: Xen developer discussion <xen-devel.lists.xensource.com> List-Unsubscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe> List-Post: <mailto:xen-devel@lists.xensource.com> List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help> List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=subscribe> Sender: xen-devel-bounces@lists.xensource.com Errors-To: xen-devel-bounces@lists.xensource.com Hi. Sorry, what does not run exactly? Kom. -- View this message in context: http://xen.1045712.n5.nabble.com/Patches-for-VGA-Passthrough-XEN-4-2-unstable-tp4406265p4826432.html Sent from the Xen - Dev mailing list archive at Nabble.com. _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel From xen-devel-bounces@lists.xensource.com Wed Sep 21 07:12:31 2011 Return-path: <xen-devel-bounces@lists.xensource.com> Envelope-to: www-data@lists.xensource.com Delivery-date: Wed, 21 Sep 2011 07:12:31 -0700 Received: from localhost ([127.0.0.1] helo=lists.colo.xensource.com) by lists.xensource.com with esmtp (Exim 4.43) id 1R6NXL-0001jZ-NM; Wed, 21 Sep 2011 07:12:31 -0700 Received: from mail27.messagelabs.com ([193.109.254.147]) by lists.xensource.com with esmtp (Exim 4.43) id 1R6NIK-0007bL-G9 for xen-devel@lists.xensource.com; Wed, 21 Sep 2011 06:57:00 -0700 X-Env-Sender: Ian.Campbell@eu.citrix.com X-Msg-Ref: server-5.tower-27.messagelabs.com!1316613396!45801195!1 X-Originating-IP: [66.165.176.63] X-StarScan-Version: 6.4.1; banners=-,-,- X-VirusChecked: Checked Received: (qmail 22491 invoked from network); 21 Sep 2011 13:56:38 -0000 Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63) by server-5.tower-27.messagelabs.com with RC4-SHA encrypted SMTP; 21 Sep 2011 13:56:38 -0000 X-IronPort-AV: E=Sophos;i="4.68,417,1312171200"; d="scan'208";a="164126317" Received: from ftlpmailmx02.citrite.net ([10.13.107.66]) by FTLPIPO02.CITRIX.COM with ESMTP/TLS/RC4-MD5; 21 Sep 2011 09:56:55 -0400 Received: from smtp01.ad.xensource.com (10.219.128.104) by smtprelay.citrix.com (10.13.107.66) with Microsoft SMTP Server id 8.3.137.0; Wed, 21 Sep 2011 09:56:55 -0400 Received: from cosworth.uk.xensource.com (cosworth.uk.xensource.com [10.80.16.52]) by smtp01.ad.xensource.com (8.13.1/8.13.1) with ESMTP id p8LDusPa024483; Wed, 21 Sep 2011 06:56:54 -0700 Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Mercurial-Node: 7c4b34932f2b44fb7050dd8552d6beabacb12256 Message-ID: <7c4b34932f2b44fb7050.1316613413@cosworth.uk.xensource.com> User-Agent: Mercurial-patchbomb/1.6.4 Date: Wed, 21 Sep 2011 14:56:53 +0100 From: Ian Campbell <ian.campbell@citrix.com> To: xen-devel@lists.xensource.com Cc: Ian Campbell <ian.campbell@citrix.com> Subject: [Xen-devel] [PATCH] libxl: correctly propagate errors from libxl_domain_destroy X-BeenThere: xen-devel@lists.xensource.com X-Mailman-Version: 2.1.5 Precedence: list List-Id: Xen developer discussion <xen-devel.lists.xensource.com> List-Unsubscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe> List-Post: <mailto:xen-devel@lists.xensource.com> List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help> List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=subscribe> Sender: xen-devel-bounces@lists.xensource.com Errors-To: xen-devel-bounces@lists.xensource.com # HG changeset patch # User Ian Campbell <ian.campbell@citrix.com> # Date 1316609965 -3600 # Node ID 7c4b34932f2b44fb7050dd8552d6beabacb12256 # Parent 41cd57151203cf78a12ee1748bcce5475b181ad6 libxl: correctly propagate errors from libxl_domain_destroy currently it return success e.g. even if xc_domain_destroy fails. Signed-off-by: Ian Campbell <ian.campbell@citrix.com> diff -r 41cd57151203 -r 7c4b34932f2b tools/libxl/libxl.c --- a/tools/libxl/libxl.c Wed Sep 21 13:59:24 2011 +0100 +++ b/tools/libxl/libxl.c Wed Sep 21 13:59:25 2011 +0100 @@ -785,7 +785,7 @@ int libxl_domain_destroy(libxl_ctx *ctx, rc = 0; out: libxl__free_all(&gc); - return 0; + return rc; } int libxl_console_exec(libxl_ctx *ctx, uint32_t domid, int cons_num, libxl_console_type type) _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel From xen-devel-bounces@lists.xensource.com Wed Sep 21 07:13:43 2011 Return-path: <xen-devel-bounces@lists.xensource.com> Envelope-to: www-data@lists.xensource.com Delivery-date: Wed, 21 Sep 2011 07:13:43 -0700 Received: from localhost ([127.0.0.1] helo=lists.colo.xensource.com) by lists.xensource.com with esmtp (Exim 4.43) id 1R6NYV-0002B3-Jt; Wed, 21 Sep 2011 07:13:43 -0700 Received: from mail21.messagelabs.com ([85.158.143.35]) by lists.xensource.com with esmtp (Exim 4.43) id 1R6NKe-00085x-TR for xen-devel@lists.xensource.com; Wed, 21 Sep 2011 06:59:25 -0700 X-Env-Sender: Christoph.Egger@amd.com X-Msg-Ref: server-7.tower-21.messagelabs.com!1316613531!55708531!1 X-Originating-IP: [213.199.154.139] X-StarScan-Version: 6.4.1; banners=-,-,- X-VirusChecked: Checked Received: (qmail 6520 invoked from network); 21 Sep 2011 13:58:51 -0000 Received: from db3ehsobe001.messaging.microsoft.com (HELO DB3EHSOBE001.bigfish.com) (213.199.154.139) by server-7.tower-21.messagelabs.com with AES128-SHA encrypted SMTP; 21 Sep 2011 13:58:51 -0000 Received: from mail32-db3-R.bigfish.com (10.3.81.251) by DB3EHSOBE001.bigfish.com (10.3.84.21) with Microsoft SMTP Server id 14.1.225.22; Wed, 21 Sep 2011 13:59:21 +0000 Received: from mail32-db3 (localhost.localdomain [127.0.0.1]) by mail32-db3-R.bigfish.com (Postfix) with ESMTP id 423AC1E8330; Wed, 21 Sep 2011 13:59:21 +0000 (UTC) X-SpamScore: -14 X-BigFish: VPS-14(zzbb2dK936eK1432N98dKzz1202hzz8275bhz32i668h839h93fh) X-Forefront-Antispam-Report: CIP:163.181.249.109; KIP:(null); UIP:(null); IPVD:NLI; H:ausb3twp02.amd.com; RD:none; EFVD:NLI X-FB-SS: 13, Received: from mail32-db3 (localhost.localdomain [127.0.0.1]) by mail32-db3 (MessageSwitch) id 1316613532744856_25508; Wed, 21 Sep 2011 13:58:52 +0000 (UTC) Received: from DB3EHSMHS019.bigfish.com (unknown [10.3.81.247]) by mail32-db3.bigfish.com (Postfix) with ESMTP id 6B1C99F00C2; Wed, 21 Sep 2011 13:58:52 +0000 (UTC) Received: from ausb3twp02.amd.com (163.181.249.109) by DB3EHSMHS019.bigfish.com (10.3.87.119) with Microsoft SMTP Server id 14.1.225.22; Wed, 21 Sep 2011 13:58:51 +0000 X-WSS-ID: 0LRVLHV-02-7GO-02 X-M-MSG: Received: from sausexedgep02.amd.com (sausexedgep02-ext.amd.com [163.181.249.73]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by ausb3twp02.amd.com (Axway MailGate 3.8.1) with ESMTP id 2BB05C82A4; Wed, 21 Sep 2011 08:58:43 -0500 (CDT) Received: from SAUSEXDAG02.amd.com (163.181.55.2) by sausexedgep02.amd.com (163.181.36.59) with Microsoft SMTP Server (TLS) id 8.3.106.1; Wed, 21 Sep 2011 08:58:59 -0500 Received: from storexhtp02.amd.com (172.24.4.4) by sausexdag02.amd.com (163.181.55.2) with Microsoft SMTP Server (TLS) id 14.1.289.1; Wed, 21 Sep 2011 08:58:47 -0500 Received: from rhodium.osrc.amd.com (165.204.15.173) by storexhtp02.amd.com (172.24.4.4) with Microsoft SMTP Server id 8.3.83.0; Wed, 21 Sep 2011 09:58:46 -0400 Message-ID: <4E79ED94.1000308@amd.com> Date: Wed, 21 Sep 2011 15:58:44 +0200 From: Christoph Egger <Christoph.Egger@amd.com> User-Agent: Mozilla/5.0 (X11; U; NetBSD amd64; en-US; rv:1.9.2.17) Gecko/20110523 Lightning/1.0b3pre Thunderbird/3.1.10 MIME-Version: 1.0 To: Ian Campbell <Ian.Campbell@eu.citrix.com> Subject: Re: [Xen-devel] Re: [PATCH RESEND V8 4/7] libxl: Introduce libxl__realloc. References: <1316609997-26002-1-git-send-email-anthony.perard@citrix.com> <1316609997-26002-5-git-send-email-anthony.perard@citrix.com> <1316612077.3891.187.camel@zakaz.uk.xensource.com> In-Reply-To: <1316612077.3891.187.camel@zakaz.uk.xensource.com> Content-Type: text/plain; charset="UTF-8"; format=flowed Content-Transfer-Encoding: 7bit X-OriginatorOrg: amd.com Cc: Anthony PERARD <anthony.perard@citrix.com>, Xen Devel <xen-devel@lists.xensource.com>, Stefano Stabellini <Stefano.Stabellini@eu.citrix.com> X-BeenThere: xen-devel@lists.xensource.com X-Mailman-Version: 2.1.5 Precedence: list List-Id: Xen developer discussion <xen-devel.lists.xensource.com> List-Unsubscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe> List-Post: <mailto:xen-devel@lists.xensource.com> List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help> List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=subscribe> Sender: xen-devel-bounces@lists.xensource.com Errors-To: xen-devel-bounces@lists.xensource.com On 09/21/11 15:34, Ian Campbell wrote: > On Wed, 2011-09-21 at 13:59 +0100, Anthony PERARD wrote: >> Signed-off-by: Anthony PERARD<anthony.perard@citrix.com> > > Acked-by: Ian Campbell<ian.campbell@citrix.com> > >> --- >> tools/libxl/libxl_internal.c | 24 ++++++++++++++++++++++++ >> tools/libxl/libxl_internal.h | 1 + >> 2 files changed, 25 insertions(+), 0 deletions(-) >> >> diff --git a/tools/libxl/libxl_internal.c b/tools/libxl/libxl_internal.c >> index e259278..c4d54f9 100644 >> --- a/tools/libxl/libxl_internal.c >> +++ b/tools/libxl/libxl_internal.c >> @@ -102,6 +102,30 @@ void *libxl__calloc(libxl__gc *gc, size_t nmemb, size_t size) >> return ptr; >> } >> >> +void *libxl__realloc(libxl__gc *gc, void *ptr, size_t new_size) >> +{ >> + void *new_ptr = realloc(ptr, new_size); >> + int i = 0; >> + >> + if (new_ptr == NULL&& new_size != 0) { >> + return NULL; >> + } >> + >> + if (ptr == NULL) { >> + libxl__ptr_add(gc, new_ptr); >> + } else if (new_ptr != ptr) { >> + for (i = 0; i< gc->alloc_maxsize; i++) { >> + if (gc->alloc_ptrs[i] == ptr) { >> + gc->alloc_ptrs[i] = new_ptr; >> + break; >> + } >> + } >> + } >> + >> + >> + return new_ptr; >> +} >> + >> char *libxl__sprintf(libxl__gc *gc, const char *fmt, ...) >> { >> char *s; >> diff --git a/tools/libxl/libxl_internal.h b/tools/libxl/libxl_internal.h >> index 739e45e..5d270bb 100644 >> --- a/tools/libxl/libxl_internal.h >> +++ b/tools/libxl/libxl_internal.h >> @@ -145,6 +145,7 @@ _hidden int libxl__ptr_add(libxl__gc *gc, void *ptr); >> _hidden void libxl__free_all(libxl__gc *gc); >> _hidden void *libxl__zalloc(libxl__gc *gc, int bytes); >> _hidden void *libxl__calloc(libxl__gc *gc, size_t nmemb, size_t size); What is the difference between libxl__zalloc and libxl__calloc? >> +_hidden void *libxl__realloc(libxl__gc *gc, void *ptr, size_t new_size); >> _hidden char *libxl__sprintf(libxl__gc *gc, const char *fmt, ...) PRINTF_ATTRIBUTE(2, 3); >> _hidden char *libxl__strdup(libxl__gc *gc, const char *c); >> _hidden char *libxl__dirname(libxl__gc *gc, const char *s); > > > > _______________________________________________ > Xen-devel mailing list > Xen-devel@lists.xensource.com > http://lists.xensource.com/xen-devel > -- ---to satisfy European Law for business letters: Advanced Micro Devices GmbH Einsteinring 24, 85689 Dornach b. Muenchen Geschaeftsfuehrer: Alberto Bozzo, Andrew Bowd Sitz: Dornach, Gemeinde Aschheim, Landkreis Muenchen Registergericht Muenchen, HRB Nr. 43632 _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel From xen-devel-bounces@lists.xensource.com Wed Sep 21 07:14:36 2011 Return-path: <xen-devel-bounces@lists.xensource.com> Envelope-to: www-data@lists.xensource.com Delivery-date: Wed, 21 Sep 2011 07:14:36 -0700 Received: from localhost ([127.0.0.1] helo=lists.colo.xensource.com) by lists.xensource.com with esmtp (Exim 4.43) id 1R6NZL-0002bR-Vx; Wed, 21 Sep 2011 07:14:36 -0700 Received: from mail182.messagelabs.com ([85.158.139.83]) by lists.xensource.com with esmtp (Exim 4.43) id 1R6NLL-0008D1-3w for xen-devel@lists.xensource.com; Wed, 21 Sep 2011 07:00:11 -0700 X-Env-Sender: Christoph.Egger@amd.com X-Msg-Ref: server-3.tower-182.messagelabs.com!1316613604!16413632!1 X-Originating-IP: [213.199.154.208] X-StarScan-Version: 6.4.1; banners=-,-,- X-VirusChecked: Checked Received: (qmail 1218 invoked from network); 21 Sep 2011 14:00:04 -0000 Received: from am1ehsobe005.messaging.microsoft.com (HELO AM1EHSOBE005.bigfish.com) (213.199.154.208) by server-3.tower-182.messagelabs.com with AES128-SHA encrypted SMTP; 21 Sep 2011 14:00:04 -0000 Received: from mail31-am1-R.bigfish.com (10.3.201.254) by AM1EHSOBE005.bigfish.com (10.3.204.25) with Microsoft SMTP Server id 14.1.225.22; Wed, 21 Sep 2011 14:00:03 +0000 Received: from mail31-am1 (localhost.localdomain [127.0.0.1]) by mail31-am1-R.bigfish.com (Postfix) with ESMTP id 8C68512E820A; Wed, 21 Sep 2011 14:00:03 +0000 (UTC) X-SpamScore: -14 X-BigFish: VPS-14(zzbb2dK936eK1432N98dKzz1202hzz8275bhz32i668h839h93fh61h) X-Spam-TCS-SCL: 0:0 X-Forefront-Antispam-Report: CIP:163.181.249.108; KIP:(null); UIP:(null); IPVD:NLI; H:ausb3twp01.amd.com; RD:none; EFVD:NLI Received: from mail31-am1 (localhost.localdomain [127.0.0.1]) by mail31-am1 (MessageSwitch) id 1316613602261288_1402; Wed, 21 Sep 2011 14:00:02 +0000 (UTC) Received: from AM1EHSMHS016.bigfish.com (unknown [10.3.201.254]) by mail31-am1.bigfish.com (Postfix) with ESMTP id 34B8E104805F; Wed, 21 Sep 2011 14:00:02 +0000 (UTC) Received: from ausb3twp01.amd.com (163.181.249.108) by AM1EHSMHS016.bigfish.com (10.3.207.154) with Microsoft SMTP Server id 14.1.225.22; Wed, 21 Sep 2011 13:59:52 +0000 X-WSS-ID: 0LRVLJN-01-010-02 X-M-MSG: Received: from sausexedgep01.amd.com (sausexedgep01-ext.amd.com [163.181.249.72]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by ausb3twp01.amd.com (Axway MailGate 3.8.1) with ESMTP id 288E2102827E; Wed, 21 Sep 2011 08:59:47 -0500 (CDT) Received: from SAUSEXDAG01.amd.com (163.181.55.1) by sausexedgep01.amd.com (163.181.36.54) with Microsoft SMTP Server (TLS) id 8.3.106.1; Wed, 21 Sep 2011 09:00:02 -0500 Received: from storexhtp02.amd.com (172.24.4.4) by sausexdag01.amd.com (163.181.55.1) with Microsoft SMTP Server (TLS) id 14.1.289.1; Wed, 21 Sep 2011 08:59:50 -0500 Received: from rhodium.osrc.amd.com (165.204.15.173) by storexhtp02.amd.com (172.24.4.4) with Microsoft SMTP Server id 8.3.83.0; Wed, 21 Sep 2011 09:59:50 -0400 Message-ID: <4E79EDD4.2030401@amd.com> Date: Wed, 21 Sep 2011 15:59:48 +0200 From: Christoph Egger <Christoph.Egger@amd.com> User-Agent: Mozilla/5.0 (X11; U; NetBSD amd64; en-US; rv:1.9.2.17) Gecko/20110523 Lightning/1.0b3pre Thunderbird/3.1.10 MIME-Version: 1.0 To: Ian Campbell <Ian.Campbell@eu.citrix.com> Subject: Re: [Xen-devel] Re: [PATCH RESEND V8 5/7] libxl: Intruduce libxl__strndup. References: <1316609997-26002-1-git-send-email-anthony.perard@citrix.com> <1316609997-26002-6-git-send-email-anthony.perard@citrix.com> <1316612104.3891.188.camel@zakaz.uk.xensource.com> In-Reply-To: <1316612104.3891.188.camel@zakaz.uk.xensource.com> Content-Type: text/plain; charset="UTF-8"; format=flowed Content-Transfer-Encoding: 7bit X-OriginatorOrg: amd.com Cc: Anthony PERARD <anthony.perard@citrix.com>, Xen Devel <xen-devel@lists.xensource.com>, Stefano Stabellini <Stefano.Stabellini@eu.citrix.com> X-BeenThere: xen-devel@lists.xensource.com X-Mailman-Version: 2.1.5 Precedence: list List-Id: Xen developer discussion <xen-devel.lists.xensource.com> List-Unsubscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe> List-Post: <mailto:xen-devel@lists.xensource.com> List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help> List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=subscribe> Sender: xen-devel-bounces@lists.xensource.com Errors-To: xen-devel-bounces@lists.xensource.com On 09/21/11 15:35, Ian Campbell wrote: > On Wed, 2011-09-21 at 13:59 +0100, Anthony PERARD wrote: >> Signed-off-by: Anthony PERARD<anthony.perard@citrix.com> > > Acked-by: Ian Campbell<ian.campbell@citrix.com> > >> --- >> tools/libxl/libxl_internal.c | 10 ++++++++++ >> tools/libxl/libxl_internal.h | 1 + >> 2 files changed, 11 insertions(+), 0 deletions(-) >> >> diff --git a/tools/libxl/libxl_internal.c b/tools/libxl/libxl_internal.c >> index c4d54f9..0fb2315 100644 >> --- a/tools/libxl/libxl_internal.c >> +++ b/tools/libxl/libxl_internal.c >> @@ -159,6 +159,16 @@ char *libxl__strdup(libxl__gc *gc, const char *c) >> return s; >> } >> >> +char *libxl__strndup(libxl__gc *gc, const char *c, size_t n) >> +{ >> + char *s = strndup(c, n); >> + >> + if (s) >> + libxl__ptr_add(gc, s); >> + >> + return s; >> +} >> + >> char *libxl__dirname(libxl__gc *gc, const char *s) >> { >> char *c; >> diff --git a/tools/libxl/libxl_internal.h b/tools/libxl/libxl_internal.h >> index 5d270bb..d873243 100644 >> --- a/tools/libxl/libxl_internal.h >> +++ b/tools/libxl/libxl_internal.h >> @@ -148,6 +148,7 @@ _hidden void *libxl__calloc(libxl__gc *gc, size_t nmemb, size_t size); >> _hidden void *libxl__realloc(libxl__gc *gc, void *ptr, size_t new_size); >> _hidden char *libxl__sprintf(libxl__gc *gc, const char *fmt, ...) PRINTF_ATTRIBUTE(2, 3); >> _hidden char *libxl__strdup(libxl__gc *gc, const char *c); >> +_hidden char *libxl__strndup(libxl__gc *gc, const char *c, size_t n); Will libxl_strdup() go away ? Christoph >> _hidden char *libxl__dirname(libxl__gc *gc, const char *s); >> >> _hidden char **libxl__xs_kvs_of_flexarray(libxl__gc *gc, flexarray_t *array, int length); > > > > _______________________________________________ > Xen-devel mailing list > Xen-devel@lists.xensource.com > http://lists.xensource.com/xen-devel > -- ---to satisfy European Law for business letters: Advanced Micro Devices GmbH Einsteinring 24, 85689 Dornach b. Muenchen Geschaeftsfuehrer: Alberto Bozzo, Andrew Bowd Sitz: Dornach, Gemeinde Aschheim, Landkreis Muenchen Registergericht Muenchen, HRB Nr. 43632 _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel From xen-devel-bounces@lists.xensource.com Wed Sep 21 07:15:48 2011 Return-path: <xen-devel-bounces@lists.xensource.com> Envelope-to: www-data@lists.xensource.com Delivery-date: Wed, 21 Sep 2011 07:15:48 -0700 Received: from localhost ([127.0.0.1] helo=lists.colo.xensource.com) by lists.xensource.com with esmtp (Exim 4.43) id 1R6NaW-00035Q-Mq; Wed, 21 Sep 2011 07:15:48 -0700 Received: from mail182.messagelabs.com ([85.158.139.83]) by lists.xensource.com with esmtp (Exim 4.43) id 1R6NT8-0000hJ-4M for xen-devel@lists.xensource.com; Wed, 21 Sep 2011 07:08:19 -0700 X-Env-Sender: javier.manzano@edu.uah.es X-Msg-Ref: server-7.tower-182.messagelabs.com!1316614085!14199533!1 X-Originating-IP: [216.139.236.26] X-StarScan-Version: 6.4.1; banners=-,-,- X-VirusChecked: Checked Received: (qmail 13028 invoked from network); 21 Sep 2011 14:08:06 -0000 Received: from sam.nabble.com (HELO sam.nabble.com) (216.139.236.26) by server-7.tower-182.messagelabs.com with AES256-SHA encrypted SMTP; 21 Sep 2011 14:08:06 -0000 Received: from [192.168.236.26] (helo=sam.nabble.com) by sam.nabble.com with esmtp (Exim 4.72) (envelope-from <javier.manzano@edu.uah.es>) id 1R6NT2-0002tZ-Ow for xen-devel@lists.xensource.com; Wed, 21 Sep 2011 07:08:04 -0700 Date: Wed, 21 Sep 2011 07:08:04 -0700 (PDT) From: JavMV <javier.manzano@edu.uah.es> To: xen-devel@lists.xensource.com Message-ID: <1316614084705-4826479.post@n5.nabble.com> In-Reply-To: <1316613404292-4826432.post@n5.nabble.com> References: <1315343879.61837.YahooMailNeo@web29818.mail.ird.yahoo.com> <1315382742268-4777689.post@n5.nabble.com> <1315389138.56652.YahooMailNeo@web29801.mail.ird.yahoo.com> <1315398360680-4778339.post@n5.nabble.com> <1315401901083-4778494.post@n5.nabble.com> <1315403644525-4778586.post@n5.nabble.com> <1315405372.87224.YahooMailNeo@web29801.mail.ird.yahoo.com> <1315405921936-4778727.post@n5.nabble.com> <1316612652132-4826391.post@n5.nabble.com> <1316613404292-4826432.post@n5.nabble.com> Subject: Re: Re : Re : Re : [Xen-devel] Re: Patches for VGA-Passthrough XEN 4.2 unstable MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-BeenThere: xen-devel@lists.xensource.com X-Mailman-Version: 2.1.5 Precedence: list List-Id: Xen developer discussion <xen-devel.lists.xensource.com> List-Unsubscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe> List-Post: <mailto:xen-devel@lists.xensource.com> List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help> List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=subscribe> Sender: xen-devel-bounces@lists.xensource.com Errors-To: xen-devel-bounces@lists.xensource.com Hi, I have installed the jeremy kernel 2.6.32.45 with xenfs static and (following the process I described in the link above) it is working with a functional xen system (so I can do xm list and see Dom0 running) but like I need the changeset 23350 to try the patches I execute: hg clone -r 23350 http://xenbits.xensource.com/hg/staging/xen-unstable.hg/ xen_rev23350 and after compile, install and reboot xend can't start anymore and xenstored returns the error 'FATAL: Failed to initialize dom0 state: Invalid argument' I imagine that the error is maybe caused by mixed xen versions dont know sure... ----- JavMV -- View this message in context: http://xen.1045712.n5.nabble.com/Patches-for-VGA-Passthrough-XEN-4-2-unstable-tp4406265p4826479.html Sent from the Xen - Dev mailing list archive at Nabble.com. _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel From xen-devel-bounces@lists.xensource.com Wed Sep 21 07:25:37 2011 Return-path: <xen-devel-bounces@lists.xensource.com> Envelope-to: www-data@lists.xensource.com Delivery-date: Wed, 21 Sep 2011 07:25:37 -0700 Received: from localhost ([127.0.0.1] helo=lists.colo.xensource.com) by lists.xensource.com with esmtp (Exim 4.43) id 1R6Nk1-0005ZU-5W; Wed, 21 Sep 2011 07:25:37 -0700 Received: from mail27.messagelabs.com ([193.109.254.147]) by lists.xensource.com with esmtp (Exim 4.43) id 1R6NjL-0005Lp-DH for xen-devel@lists.xensource.com; Wed, 21 Sep 2011 07:24:56 -0700 X-Env-Sender: javier.manzano@edu.uah.es X-Msg-Ref: server-3.tower-27.messagelabs.com!1316615068!40580717!1 X-Originating-IP: [216.139.236.26] X-StarScan-Version: 6.4.1; banners=-,-,- X-VirusChecked: Checked Received: (qmail 32442 invoked from network); 21 Sep 2011 14:24:29 -0000 Received: from sam.nabble.com (HELO sam.nabble.com) (216.139.236.26) by server-3.tower-27.messagelabs.com with AES256-SHA encrypted SMTP; 21 Sep 2011 14:24:29 -0000 Received: from [192.168.236.26] (helo=sam.nabble.com) by sam.nabble.com with esmtp (Exim 4.72) (envelope-from <javier.manzano@edu.uah.es>) id 1R6NjG-0004aR-Q3 for xen-devel@lists.xensource.com; Wed, 21 Sep 2011 07:24:50 -0700 Date: Wed, 21 Sep 2011 07:24:50 -0700 (PDT) From: JavMV <javier.manzano@edu.uah.es> To: xen-devel@lists.xensource.com Message-ID: <1316615090801-4826544.post@n5.nabble.com> In-Reply-To: <1316614084705-4826479.post@n5.nabble.com> References: <1315382742268-4777689.post@n5.nabble.com> <1315389138.56652.YahooMailNeo@web29801.mail.ird.yahoo.com> <1315398360680-4778339.post@n5.nabble.com> <1315401901083-4778494.post@n5.nabble.com> <1315403644525-4778586.post@n5.nabble.com> <1315405372.87224.YahooMailNeo@web29801.mail.ird.yahoo.com> <1315405921936-4778727.post@n5.nabble.com> <1316612652132-4826391.post@n5.nabble.com> <1316613404292-4826432.post@n5.nabble.com> <1316614084705-4826479.post@n5.nabble.com> Subject: Re: Re : Re : Re : [Xen-devel] Re: Patches for VGA-Passthrough XEN 4.2 unstable MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-BeenThere: xen-devel@lists.xensource.com X-Mailman-Version: 2.1.5 Precedence: list List-Id: Xen developer discussion <xen-devel.lists.xensource.com> List-Unsubscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe> List-Post: <mailto:xen-devel@lists.xensource.com> List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help> List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=subscribe> Sender: xen-devel-bounces@lists.xensource.com Errors-To: xen-devel-bounces@lists.xensource.com Also the directory /proc/xen is empty unless I add manually the line 'xenfs /proc/xen xenfs defaults 0 0' to /etc/fstab and restart... this is strange I dont know why this is not automatically done ----- JavMV -- View this message in context: http://xen.1045712.n5.nabble.com/Patches-for-VGA-Passthrough-XEN-4-2-unstable-tp4406265p4826544.html Sent from the Xen - Dev mailing list archive at Nabble.com. _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel From xen-devel-bounces@lists.xensource.com Wed Sep 21 07:32:18 2011 Return-path: <xen-devel-bounces@lists.xensource.com> Envelope-to: www-data@lists.xensource.com Delivery-date: Wed, 21 Sep 2011 07:32:18 -0700 Received: from localhost ([127.0.0.1] helo=lists.colo.xensource.com) by lists.xensource.com with esmtp (Exim 4.43) id 1R6NqS-0006jl-Mn; Wed, 21 Sep 2011 07:32:16 -0700 Received: from mail21.messagelabs.com ([85.158.143.35]) by lists.xensource.com with esmtp (Exim 4.43) id 1R6Npp-0006U0-VC for xen-devel@lists.xensource.com; Wed, 21 Sep 2011 07:31:38 -0700 X-Env-Sender: Ian.Jackson@eu.citrix.com X-Msg-Ref: server-8.tower-21.messagelabs.com!1316615478!59837767!1 X-Originating-IP: [62.200.22.115] X-StarScan-Version: 6.4.1; banners=-,-,- X-VirusChecked: Checked Received: (qmail 8415 invoked from network); 21 Sep 2011 14:31:18 -0000 Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115) by server-8.tower-21.messagelabs.com with RC4-SHA encrypted SMTP; 21 Sep 2011 14:31:18 -0000 X-IronPort-AV: E=Sophos;i="4.68,417,1312156800"; d="scan'208";a="7982691" Received: from lonpmailmx01.citrite.net ([10.30.203.162]) by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5; 21 Sep 2011 14:31:34 +0000 Received: from woking.xci-test.com (10.80.248.135) by smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id 8.3.137.0; Wed, 21 Sep 2011 15:31:35 +0100 Received: from osstest by woking.xci-test.com with local (Exim 4.69) (envelope-from <ian.jackson@eu.citrix.com>) id 1R6Npm-0005Hw-O5; Wed, 21 Sep 2011 15:31:34 +0100 To: xen-devel@lists.xensource.com Message-ID: <osstest-8990-mainreport@xen.org> From: xen.org <ian.jackson@eu.citrix.com> Date: Wed, 21 Sep 2011 15:31:34 +0100 MIME-Version: 1.0 Content-Type: text/plain Cc: ian.jackson@eu.citrix.com Subject: [Xen-devel] [xen-unstable test] 8990: tolerable FAIL - PUSHED X-BeenThere: xen-devel@lists.xensource.com X-Mailman-Version: 2.1.5 Precedence: list List-Id: Xen developer discussion <xen-devel.lists.xensource.com> List-Unsubscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe> List-Post: <mailto:xen-devel@lists.xensource.com> List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help> List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=subscribe> Sender: xen-devel-bounces@lists.xensource.com Errors-To: xen-devel-bounces@lists.xensource.com flight 8990 xen-unstable real [real] http://www.chiark.greenend.org.uk/~xensrcts/logs/8990/ Failures :-/ but no regressions. Tests which did not succeed, but are not blocking, including regressions (tests previously passed) regarded as allowable: test-amd64-amd64-xl-pcipt-intel 1 xen-build-check(1) blocked n/a test-amd64-amd64-xl 1 xen-build-check(1) blocked n/a build-i386-pvops 4 kernel-build fail like 8986 test-amd64-i386-pair 1 xen-build-check(1) blocked n/a test-amd64-i386-xl-multivcpu 1 xen-build-check(1) blocked n/a test-amd64-i386-rhel6hvm-intel 1 xen-build-check(1) blocked n/a test-i386-i386-pv 1 xen-build-check(1) blocked n/a test-amd64-i386-pv 1 xen-build-check(1) blocked n/a test-amd64-amd64-pv 1 xen-build-check(1) blocked n/a test-i386-i386-xl 1 xen-build-check(1) blocked n/a build-amd64-pvops 4 kernel-build fail like 8986 test-amd64-i386-xl 1 xen-build-check(1) blocked n/a test-amd64-i386-xl-credit2 1 xen-build-check(1) blocked n/a test-amd64-i386-rhel6hvm-amd 1 xen-build-check(1) blocked n/a test-amd64-amd64-pair 1 xen-build-check(1) blocked n/a test-i386-i386-pair 1 xen-build-check(1) blocked n/a test-amd64-amd64-win 1 xen-build-check(1) blocked n/a test-amd64-amd64-xl-win 1 xen-build-check(1) blocked n/a test-amd64-i386-win 1 xen-build-check(1) blocked n/a test-i386-i386-win 1 xen-build-check(1) blocked n/a test-amd64-amd64-xl-sedf 1 xen-build-check(1) blocked n/a test-amd64-i386-win-vcpus1 1 xen-build-check(1) blocked n/a test-amd64-i386-xl-win-vcpus1 1 xen-build-check(1) blocked n/a test-i386-i386-xl-win 1 xen-build-check(1) blocked n/a version targeted for testing: xen cd730c698299 baseline version: xen 994b5b125c31 ------------------------------------------------------------ People who touched revisions under test: Ian Jackson <ian.jackson@eu.citrix.com> Igor Mammedov <imammedo@redhat.com> Jan Beulich <jbeulich@suse.com> Keir Fraser <keir@xen.org> Olaf Hering <olaf@aepfle.de> Shan Haitao <haitao.shan@intel.com> ------------------------------------------------------------ jobs: build-amd64 pass build-i386 pass build-amd64-oldkern pass build-i386-oldkern pass build-amd64-pvops fail build-i386-pvops fail test-amd64-amd64-xl blocked test-amd64-i386-xl blocked test-i386-i386-xl blocked test-amd64-i386-rhel6hvm-amd blocked test-amd64-i386-xl-credit2 blocked test-amd64-amd64-xl-pcipt-intel blocked test-amd64-i386-rhel6hvm-intel blocked test-amd64-i386-xl-multivcpu blocked test-amd64-amd64-pair blocked test-amd64-i386-pair blocked test-i386-i386-pair blocked test-amd64-amd64-pv blocked test-amd64-i386-pv blocked test-i386-i386-pv blocked test-amd64-amd64-xl-sedf blocked test-amd64-i386-win-vcpus1 blocked test-amd64-i386-xl-win-vcpus1 blocked test-amd64-amd64-win blocked test-amd64-i386-win blocked test-i386-i386-win blocked test-amd64-amd64-xl-win blocked test-i386-i386-xl-win blocked ------------------------------------------------------------ sg-report-flight on woking.cam.xci-test.com logs: /home/xc_osstest/logs images: /home/xc_osstest/images Logs, config files, etc. are available at http://www.chiark.greenend.org.uk/~xensrcts/logs Test harness code can be found at http://xenbits.xensource.com/gitweb?p=osstest.git;a=summary Pushing revision : + branch=xen-unstable + revision=cd730c698299 + . cri-lock-repos ++ . cri-common +++ umask 002 +++ getconfig Repos +++ perl -e ' use Osstest; readconfigonly(); print $c{Repos} or die $!; ' ++ repos=/export/home/osstest/repos ++ repos_lock=/export/home/osstest/repos/lock ++ '[' x '!=' x/export/home/osstest/repos/lock ']' ++ OSSTEST_REPOS_LOCK_LOCKED=/export/home/osstest/repos/lock ++ exec with-lock-ex -w /export/home/osstest/repos/lock ./ap-push xen-unstable cd730c698299 + branch=xen-unstable + revision=cd730c698299 + . cri-lock-repos ++ . cri-common +++ umask 002 +++ getconfig Repos +++ perl -e ' use Osstest; readconfigonly(); print $c{Repos} or die $!; ' ++ repos=/export/home/osstest/repos ++ repos_lock=/export/home/osstest/repos/lock ++ '[' x/export/home/osstest/repos/lock '!=' x/export/home/osstest/repos/lock ']' + : xen@xenbits.xensource.com + : xen@xenbits.xensource.com:git/linux-pvops + : master + : tested/2.6.39.x + case "$branch" in + cd /export/home/osstest/repos/xen-unstable.hg + hg push -r cd730c698299 ssh://xen@xenbits.xensource.com/HG/xen-unstable.hg pushing to ssh://xen@xenbits.xensource.com/HG/xen-unstable.hg searching for changes remote: adding changesets remote: adding manifests remote: adding file changes remote: added 5 changesets with 25 changes to 22 files _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel From xen-devel-bounces@lists.xensource.com Wed Sep 21 07:33:07 2011 Return-path: <xen-devel-bounces@lists.xensource.com> Envelope-to: www-data@lists.xensource.com Delivery-date: Wed, 21 Sep 2011 07:33:07 -0700 Received: from localhost ([127.0.0.1] helo=lists.colo.xensource.com) by lists.xensource.com with esmtp (Exim 4.43) id 1R6NrH-000780-D5; Wed, 21 Sep 2011 07:33:07 -0700 Received: from mail27.messagelabs.com ([193.109.254.147]) by lists.xensource.com with esmtp (Exim 4.43) id 1R6NqM-0006i9-UF for xen-devel@lists.xensource.com; Wed, 21 Sep 2011 07:32:11 -0700 X-Env-Sender: komkon555@freenet.de X-Msg-Ref: server-6.tower-27.messagelabs.com!1316615507!49900640!1 X-Originating-IP: [216.139.236.26] X-StarScan-Version: 6.4.1; banners=-,-,- X-VirusChecked: Checked Received: (qmail 29968 invoked from network); 21 Sep 2011 14:31:48 -0000 Received: from sam.nabble.com (HELO sam.nabble.com) (216.139.236.26) by server-6.tower-27.messagelabs.com with AES256-SHA encrypted SMTP; 21 Sep 2011 14:31:48 -0000 Received: from [192.168.236.26] (helo=sam.nabble.com) by sam.nabble.com with esmtp (Exim 4.72) (envelope-from <komkon555@freenet.de>) id 1R6NqI-0005Dc-EU for xen-devel@lists.xensource.com; Wed, 21 Sep 2011 07:32:06 -0700 Date: Wed, 21 Sep 2011 07:32:06 -0700 (PDT) From: komkon555 <komkon555@freenet.de> To: xen-devel@lists.xensource.com Message-ID: <1316615526442-4826582.post@n5.nabble.com> In-Reply-To: <1316614084705-4826479.post@n5.nabble.com> References: <1315382742268-4777689.post@n5.nabble.com> <1315389138.56652.YahooMailNeo@web29801.mail.ird.yahoo.com> <1315398360680-4778339.post@n5.nabble.com> <1315401901083-4778494.post@n5.nabble.com> <1315403644525-4778586.post@n5.nabble.com> <1315405372.87224.YahooMailNeo@web29801.mail.ird.yahoo.com> <1315405921936-4778727.post@n5.nabble.com> <1316612652132-4826391.post@n5.nabble.com> <1316613404292-4826432.post@n5.nabble.com> <1316614084705-4826479.post@n5.nabble.com> Subject: Re: Re : Re : Re : [Xen-devel] Re: Patches for VGA-Passthrough XEN 4.2 unstable MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-BeenThere: xen-devel@lists.xensource.com X-Mailman-Version: 2.1.5 Precedence: list List-Id: Xen developer discussion <xen-devel.lists.xensource.com> List-Unsubscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe> List-Post: <mailto:xen-devel@lists.xensource.com> List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help> List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=subscribe> Sender: xen-devel-bounces@lists.xensource.com Errors-To: xen-devel-bounces@lists.xensource.com So, in this case you should try first of all http://pasik.reaktio.net/xen/kernel-config/config-2.6.32.43-pvops-dom0-xen-stable-x86_64 this configuration file for xen-kernel (compile it from the very beginning with last one). Just edit this config to "xenfs=y". Delete all original (stock) xen-programms (kernel, xen, xen-utils and so on) and xendomain, xencommon, xend from /etc/init.d/. Than compile jeremy kernel with new config: $ cd /usr/src/linux $ make oldconfig $ sudo make $ sudo apt-get install kernel-package fakeroot $ export CONCURRENCY_LEVEL=<number_of_cores +1> $ sudo make-kpkg clean $ sudo fakeroot make-kpkg --initrd --append-to-version=-pv kernel-image kernel-headers $ sudo dpkg -i ../<linux-image-2.6.XXX.deb> See details with this http://wiki.xensource.com/xenwiki/XenParavirtOps link . Than compile and install xen-unstable. After reboot you have to run /etc/init.d/xencommons start and /etc/init.d/xend start manually. If any reports about missing modules load them first. Best regards. -- View this message in context: http://xen.1045712.n5.nabble.com/Patches-for-VGA-Passthrough-XEN-4-2-unstable-tp4406265p4826582.html Sent from the Xen - Dev mailing list archive at Nabble.com. _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel From xen-devel-bounces@lists.xensource.com Wed Sep 21 07:40:33 2011 Return-path: <xen-devel-bounces@lists.xensource.com> Envelope-to: www-data@lists.xensource.com Delivery-date: Wed, 21 Sep 2011 07:40:33 -0700 Received: from localhost ([127.0.0.1] helo=lists.colo.xensource.com) by lists.xensource.com with esmtp (Exim 4.43) id 1R6NyT-0007so-Cj; Wed, 21 Sep 2011 07:40:33 -0700 Received: from mail21.messagelabs.com ([85.158.143.35]) by lists.xensource.com with esmtp (Exim 4.43) id 1R6Ny2-0007gK-MB for xen-devel@lists.xensource.com; Wed, 21 Sep 2011 07:40:07 -0700 X-Env-Sender: komkon555@freenet.de X-Msg-Ref: server-15.tower-21.messagelabs.com!1316616003!51445863!1 X-Originating-IP: [216.139.236.26] X-StarScan-Version: 6.4.1; banners=-,-,- X-VirusChecked: Checked Received: (qmail 10123 invoked from network); 21 Sep 2011 14:40:05 -0000 Received: from sam.nabble.com (HELO sam.nabble.com) (216.139.236.26) by server-15.tower-21.messagelabs.com with AES256-SHA encrypted SMTP; 21 Sep 2011 14:40:05 -0000 Received: from [192.168.236.26] (helo=sam.nabble.com) by sam.nabble.com with esmtp (Exim 4.72) (envelope-from <komkon555@freenet.de>) id 1R6Nxx-00060h-RS for xen-devel@lists.xensource.com; Wed, 21 Sep 2011 07:40:01 -0700 Date: Wed, 21 Sep 2011 07:40:01 -0700 (PDT) From: komkon555 <komkon555@freenet.de> To: xen-devel@lists.xensource.com Message-ID: <1316616001843-4826614.post@n5.nabble.com> In-Reply-To: <1316615526442-4826582.post@n5.nabble.com> References: <1315389138.56652.YahooMailNeo@web29801.mail.ird.yahoo.com> <1315398360680-4778339.post@n5.nabble.com> <1315401901083-4778494.post@n5.nabble.com> <1315403644525-4778586.post@n5.nabble.com> <1315405372.87224.YahooMailNeo@web29801.mail.ird.yahoo.com> <1315405921936-4778727.post@n5.nabble.com> <1316612652132-4826391.post@n5.nabble.com> <1316613404292-4826432.post@n5.nabble.com> <1316614084705-4826479.post@n5.nabble.com> <1316615526442-4826582.post@n5.nabble.com> Subject: Re: Re : Re : Re : [Xen-devel] Re: Patches for VGA-Passthrough XEN 4.2 unstable MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-BeenThere: xen-devel@lists.xensource.com X-Mailman-Version: 2.1.5 Precedence: list List-Id: Xen developer discussion <xen-devel.lists.xensource.com> List-Unsubscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe> List-Post: <mailto:xen-devel@lists.xensource.com> List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help> List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=subscribe> Sender: xen-devel-bounces@lists.xensource.com Errors-To: xen-devel-bounces@lists.xensource.com After xen-unstable ist compiled do not forget tu run "sudo update-grub"! It is very impotent tu run proper combination of xen kernel and xen-unstable while boot in! Kom. -- View this message in context: http://xen.1045712.n5.nabble.com/Patches-for-VGA-Passthrough-XEN-4-2-unstable-tp4406265p4826614.html Sent from the Xen - Dev mailing list archive at Nabble.com. _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel From xen-devel-bounces@lists.xensource.com Wed Sep 21 07:47:39 2011 Return-path: <xen-devel-bounces@lists.xensource.com> Envelope-to: www-data@lists.xensource.com Delivery-date: Wed, 21 Sep 2011 07:47:39 -0700 Received: from localhost ([127.0.0.1] helo=lists.colo.xensource.com) by lists.xensource.com with esmtp (Exim 4.43) id 1R6O5L-0000EB-9g; Wed, 21 Sep 2011 07:47:39 -0700 Received: from mail21.messagelabs.com ([85.158.143.35]) by lists.xensource.com with esmtp (Exim 4.43) id 1R6O4H-0008QU-0Z for xen-devel@lists.xensource.com; Wed, 21 Sep 2011 07:46:33 -0700 X-Env-Sender: david.vrabel@citrix.com X-Msg-Ref: server-11.tower-21.messagelabs.com!1316616371!43451484!1 X-Originating-IP: [66.165.176.89] X-StarScan-Version: 6.4.1; banners=-,-,- X-VirusChecked: Checked Received: (qmail 18102 invoked from network); 21 Sep 2011 14:46:12 -0000 Received: from smtp.citrix.com (HELO SMTP.CITRIX.COM) (66.165.176.89) by server-11.tower-21.messagelabs.com with RC4-SHA encrypted SMTP; 21 Sep 2011 14:46:12 -0000 X-IronPort-AV: E=Sophos;i="4.68,417,1312171200"; d="scan'208";a="17573099" Received: from ftlpmailmx02.citrite.net ([10.13.107.66]) by FTLPIPO01.CITRIX.COM with ESMTP/TLS/RC4-MD5; 21 Sep 2011 10:45:25 -0400 Received: from smtp01.ad.xensource.com (10.219.128.104) by smtprelay.citrix.com (10.13.107.66) with Microsoft SMTP Server id 8.3.137.0; Wed, 21 Sep 2011 10:45:25 -0400 Received: from [192.168.0.1] ([10.31.1.109]) by smtp01.ad.xensource.com (8.13.1/8.13.1) with ESMTP id p8LEjJqq024590; Wed, 21 Sep 2011 07:45:21 -0700 Message-ID: <4E79F867.2020909@citrix.com> Date: Wed, 21 Sep 2011 15:44:55 +0100 From: David Vrabel <david.vrabel@citrix.com> User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.1.16) Gecko/20110818 Icedove/3.0.11 MIME-Version: 1.0 To: Jeremy Fitzhardinge <jeremy@goop.org> Subject: Re: [Xen-devel] Re: [PATCH 0/6] xen: don't call vmalloc_sync_all() when mapping foreign pages References: <1316090411-22608-1-git-send-email-david.vrabel@citrix.com> <4E727017.4030001@goop.org> In-Reply-To: <4E727017.4030001@goop.org> Content-Type: text/plain; charset="ISO-8859-15" Content-Transfer-Encoding: 7bit Cc: Andrew Morton <akpm@linux-foundation.org>, xen-devel@lists.xensource.com, David Vrabel <david.vrabel@citrix.com>, Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>, linux-kernel@vger.kernel.org X-BeenThere: xen-devel@lists.xensource.com X-Mailman-Version: 2.1.5 Precedence: list List-Id: Xen developer discussion <xen-devel.lists.xensource.com> List-Unsubscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe> List-Post: <mailto:xen-devel@lists.xensource.com> List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help> List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=subscribe> Sender: xen-devel-bounces@lists.xensource.com Errors-To: xen-devel-bounces@lists.xensource.com On 15/09/11 22:37, Jeremy Fitzhardinge wrote: > On 09/15/2011 05:40 AM, David Vrabel wrote: >> This set of pages avoids the need to call vmalloc_sync_all() when >> mapping foreign pages. Two new functions are adding for mapping >> foreign pages onto RAM pages instead of vmalloc space. >> >> [...] > > But that said, if you want to allocate virtual addresses for mapping > granted pages, then alloc_vm_area() is the right thing to use. You need > to make sure you touch the pages from within the kernel before passing > those addresses to a hypercall to make sure the mappings are established > within the current task (possibly within a no-preempt region to > guarantee that nothing odd happens). Or alternatively, you could switch > the current pagetable to init_mm for the hypercall (if it isn't already) > - since that's the reference pagetable - assuming you're not passing > usermode virtual addresses to the hypercall. Making alloc_vm_area() fill in a array of pte_t *'s and passing the pointer to the PTE (using the GNTMAP_contains_pte flag) in the hypercall should allow Xen to update the PTEs in init_mm directly. However, I'm not sure what to do about ia64 where GNTMAP_contains_pte is not supported. Any ideas? Here's the untested patch I have so far. diff --git a/arch/x86/xen/grant-table.c b/arch/x86/xen/grant-table.c index 49ba9b5..77348e8 100644 --- a/arch/x86/xen/grant-table.c +++ b/arch/x86/xen/grant-table.c @@ -71,7 +71,7 @@ int arch_gnttab_map_shared(unsigned long *frames, unsigned long nr_gframes, if (shared == NULL) { struct vm_struct *area = - alloc_vm_area(PAGE_SIZE * max_nr_gframes); + alloc_vm_area(PAGE_SIZE * max_nr_gframes, NULL); BUG_ON(area == NULL); shared = area->addr; *__shared = shared; diff --git a/drivers/xen/xenbus/xenbus_client.c b/drivers/xen/xenbus/xenbus_client.c index cdacf92..75eb179 100644 --- a/drivers/xen/xenbus/xenbus_client.c +++ b/drivers/xen/xenbus/xenbus_client.c @@ -435,19 +435,20 @@ EXPORT_SYMBOL_GPL(xenbus_free_evtchn); int xenbus_map_ring_valloc(struct xenbus_device *dev, int gnt_ref, void **vaddr) { struct gnttab_map_grant_ref op = { - .flags = GNTMAP_host_map, + .flags = GNTMAP_host_map | GNTMAP_contains_pte, .ref = gnt_ref, .dom = dev->otherend_id, }; struct vm_struct *area; + pte_t *pte; *vaddr = NULL; - area = alloc_vm_area(PAGE_SIZE); + area = alloc_vm_area(PAGE_SIZE, &pte); if (!area) return -ENOMEM; - op.host_addr = (unsigned long)area->addr; + op.host_addr = (unsigned long)pte; if (HYPERVISOR_grant_table_op(GNTTABOP_map_grant_ref, &op, 1)) BUG(); diff --git a/include/linux/vmalloc.h b/include/linux/vmalloc.h index 9332e52..1a77252 100644 --- a/include/linux/vmalloc.h +++ b/include/linux/vmalloc.h @@ -118,7 +118,7 @@ unmap_kernel_range(unsigned long addr, unsigned long size) #endif /* Allocate/destroy a 'vmalloc' VM area. */ -extern struct vm_struct *alloc_vm_area(size_t size); +extern struct vm_struct *alloc_vm_area(size_t size, pte_t **ptes); extern void free_vm_area(struct vm_struct *area); /* for /dev/kmem */ diff --git a/mm/vmalloc.c b/mm/vmalloc.c index 5016f19..786b4f6 100644 --- a/mm/vmalloc.c +++ b/mm/vmalloc.c @@ -2105,23 +2105,30 @@ void __attribute__((weak)) vmalloc_sync_all(void) static int f(pte_t *pte, pgtable_t table, unsigned long addr, void *data) { - /* apply_to_page_range() does all the hard work. */ + pte_t ***p = data; + + if (p) { + *(*p) = pte; + (*p)++; + } return 0; } /** * alloc_vm_area - allocate a range of kernel address space * @size: size of the area + * @ptes: returns the PTEs for the address space * * Returns: NULL on failure, vm_struct on success * * This function reserves a range of kernel address space, and * allocates pagetables to map that range. No actual mappings - * are created. If the kernel address space is not shared - * between processes, it syncs the pagetable across all - * processes. + * are created. + * + * If @ptes is non-NULL, pointers to the PTEs (in init_mm) + * allocated for the VM area are returned. */ -struct vm_struct *alloc_vm_area(size_t size) +struct vm_struct *alloc_vm_area(size_t size, pte_t **ptes) { struct vm_struct *area; @@ -2135,19 +2142,11 @@ struct vm_struct *alloc_vm_area(size_t size) * of kernel virtual address space and mapped into init_mm. */ if (apply_to_page_range(&init_mm, (unsigned long)area->addr, - area->size, f, NULL)) { + area->size, f, ptes ? &ptes : NULL)) { free_vm_area(area); return NULL; } - /* - * If the allocated address space is passed to a hypercall - * before being used then we cannot rely on a page fault to - * trigger an update of the page tables. So sync all the page - * tables here. - */ - vmalloc_sync_all(); - return area; } EXPORT_SYMBOL_GPL(alloc_vm_area); David _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel From xen-devel-bounces@lists.xensource.com Wed Sep 21 07:49:14 2011 Return-path: <xen-devel-bounces@lists.xensource.com> Envelope-to: www-data@lists.xensource.com Delivery-date: Wed, 21 Sep 2011 07:49:14 -0700 Received: from localhost ([127.0.0.1] helo=lists.colo.xensource.com) by lists.xensource.com with esmtp (Exim 4.43) id 1R6O6s-0000hm-AI; Wed, 21 Sep 2011 07:49:14 -0700 Received: from mail216.messagelabs.com ([85.158.143.99]) by lists.xensource.com with esmtp (Exim 4.43) id 1R6O5d-0000I1-5d for xen-devel@lists.xensource.com; Wed, 21 Sep 2011 07:47:57 -0700 X-Env-Sender: komkon555@freenet.de X-Msg-Ref: server-6.tower-216.messagelabs.com!1316616472!17842042!1 X-Originating-IP: [216.139.236.26] X-StarScan-Version: 6.4.1; banners=-,-,- X-VirusChecked: Checked Received: (qmail 12072 invoked from network); 21 Sep 2011 14:47:54 -0000 Received: from sam.nabble.com (HELO sam.nabble.com) (216.139.236.26) by server-6.tower-216.messagelabs.com with AES256-SHA encrypted SMTP; 21 Sep 2011 14:47:54 -0000 Received: from [192.168.236.26] (helo=sam.nabble.com) by sam.nabble.com with esmtp (Exim 4.72) (envelope-from <komkon555@freenet.de>) id 1R6O5Y-0006o9-It for xen-devel@lists.xensource.com; Wed, 21 Sep 2011 07:47:52 -0700 Date: Wed, 21 Sep 2011 07:47:52 -0700 (PDT) From: komkon555 <komkon555@freenet.de> To: xen-devel@lists.xensource.com Message-ID: <1316616472579-4826635.post@n5.nabble.com> In-Reply-To: <1316616001843-4826614.post@n5.nabble.com> References: <1315398360680-4778339.post@n5.nabble.com> <1315401901083-4778494.post@n5.nabble.com> <1315403644525-4778586.post@n5.nabble.com> <1315405372.87224.YahooMailNeo@web29801.mail.ird.yahoo.com> <1315405921936-4778727.post@n5.nabble.com> <1316612652132-4826391.post@n5.nabble.com> <1316613404292-4826432.post@n5.nabble.com> <1316614084705-4826479.post@n5.nabble.com> <1316615526442-4826582.post@n5.nabble.com> <1316616001843-4826614.post@n5.nabble.com> Subject: Re: Re : Re : Re : [Xen-devel] Re: Patches for VGA-Passthrough XEN 4.2 unstable MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-BeenThere: xen-devel@lists.xensource.com X-Mailman-Version: 2.1.5 Precedence: list List-Id: Xen developer discussion <xen-devel.lists.xensource.com> List-Unsubscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe> List-Post: <mailto:xen-devel@lists.xensource.com> List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help> List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=subscribe> Sender: xen-devel-bounces@lists.xensource.com Errors-To: xen-devel-bounces@lists.xensource.com My .config for jeremy 2.6.32.45 is attached. Kom. http://xen.1045712.n5.nabble.com/file/n4826635/config config -- View this message in context: http://xen.1045712.n5.nabble.com/Patches-for-VGA-Passthrough-XEN-4-2-unstable-tp4406265p4826635.html Sent from the Xen - Dev mailing list archive at Nabble.com. _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel From xen-devel-bounces@lists.xensource.com Wed Sep 21 07:53:20 2011 Return-path: <xen-devel-bounces@lists.xensource.com> Envelope-to: www-data@lists.xensource.com Delivery-date: Wed, 21 Sep 2011 07:53:20 -0700 Received: from localhost ([127.0.0.1] helo=lists.colo.xensource.com) by lists.xensource.com with esmtp (Exim 4.43) id 1R6OAp-0001AK-GE; Wed, 21 Sep 2011 07:53:20 -0700 Received: from mail27.messagelabs.com ([193.109.254.147]) by lists.xensource.com with esmtp (Exim 4.43) id 1R6OAE-0000xd-Ap for xen-devel@lists.xensource.com; Wed, 21 Sep 2011 07:52:42 -0700 X-Env-Sender: javier.manzano@edu.uah.es X-Msg-Ref: server-5.tower-27.messagelabs.com!1316616738!45810711!1 X-Originating-IP: [216.139.236.26] X-StarScan-Version: 6.4.1; banners=-,-,- X-VirusChecked: Checked Received: (qmail 16684 invoked from network); 21 Sep 2011 14:52:20 -0000 Received: from sam.nabble.com (HELO sam.nabble.com) (216.139.236.26) by server-5.tower-27.messagelabs.com with AES256-SHA encrypted SMTP; 21 Sep 2011 14:52:20 -0000 Received: from [192.168.236.26] (helo=sam.nabble.com) by sam.nabble.com with esmtp (Exim 4.72) (envelope-from <javier.manzano@edu.uah.es>) id 1R6OA9-0007Jh-SJ for xen-devel@lists.xensource.com; Wed, 21 Sep 2011 07:52:37 -0700 Date: Wed, 21 Sep 2011 07:52:37 -0700 (PDT) From: JavMV <javier.manzano@edu.uah.es> To: xen-devel@lists.xensource.com Message-ID: <1316616757871-4826655.post@n5.nabble.com> In-Reply-To: <1316616472579-4826635.post@n5.nabble.com> References: <1315401901083-4778494.post@n5.nabble.com> <1315403644525-4778586.post@n5.nabble.com> <1315405372.87224.YahooMailNeo@web29801.mail.ird.yahoo.com> <1315405921936-4778727.post@n5.nabble.com> <1316612652132-4826391.post@n5.nabble.com> <1316613404292-4826432.post@n5.nabble.com> <1316614084705-4826479.post@n5.nabble.com> <1316615526442-4826582.post@n5.nabble.com> <1316616001843-4826614.post@n5.nabble.com> <1316616472579-4826635.post@n5.nabble.com> Subject: Re: Re : Re : Re : [Xen-devel] Re: Patches for VGA-Passthrough XEN 4.2 unstable MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-BeenThere: xen-devel@lists.xensource.com X-Mailman-Version: 2.1.5 Precedence: list List-Id: Xen developer discussion <xen-devel.lists.xensource.com> List-Unsubscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe> List-Post: <mailto:xen-devel@lists.xensource.com> List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help> List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=subscribe> Sender: xen-devel-bounces@lists.xensource.com Errors-To: xen-devel-bounces@lists.xensource.com Haha yeah! thank you, I realise that if I did update grub then the version of xen-tools and xen-kernel match up so now I can make xend run normally, I have to manually execute 'xenstored', 'xenconsoled' and then 'xend start' because xend fail to start at boot but anyways I have xend running now so I will fix the automatically start later. ----- JavMV -- View this message in context: http://xen.1045712.n5.nabble.com/Patches-for-VGA-Passthrough-XEN-4-2-unstable-tp4406265p4826655.html Sent from the Xen - Dev mailing list archive at Nabble.com. _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel From xen-devel-bounces@lists.xensource.com Wed Sep 21 08:04:52 2011 Return-path: <xen-devel-bounces@lists.xensource.com> Envelope-to: www-data@lists.xensource.com Delivery-date: Wed, 21 Sep 2011 08:04:52 -0700 Received: from localhost ([127.0.0.1] helo=lists.colo.xensource.com) by lists.xensource.com with esmtp (Exim 4.43) id 1R6OLy-0001qD-Lf; Wed, 21 Sep 2011 08:04:51 -0700 Received: from mail21.messagelabs.com ([85.158.143.35]) by lists.xensource.com with smtp (Exim 4.43) id 1R6OJz-0001Z2-Hh for xen-devel@lists.xensource.com; Wed, 21 Sep 2011 08:02:50 -0700 X-Env-Sender: dgdegra@tycho.nsa.gov X-Msg-Ref: server-15.tower-21.messagelabs.com!1316617365!51449475!1 X-Originating-IP: [63.239.65.39] X-StarScan-Version: 6.4.1; banners=-,-,- X-VirusChecked: Checked Received: (qmail 20233 invoked from network); 21 Sep 2011 15:02:45 -0000 Received: from msux-gh1-uea01.nsa.gov (HELO msux-gh1-uea01.nsa.gov) (63.239.65.39) by server-15.tower-21.messagelabs.com with SMTP; 21 Sep 2011 15:02:45 -0000 Received: from tarius.tycho.ncsc.mil (localhost [127.0.0.1]) by msux-gh1-uea01.nsa.gov (8.12.10/8.12.10) with ESMTP id p8LF2fPf027062; Wed, 21 Sep 2011 15:02:41 GMT Received: from moss-nexus.epoch.ncsc.mil (moss-nexus [144.51.25.48]) by tarius.tycho.ncsc.mil (8.13.1/8.13.1) with ESMTP id p8LF2fjt001756; Wed, 21 Sep 2011 11:02:41 -0400 Message-ID: <4E79FC9A.6040609@tycho.nsa.gov> Date: Wed, 21 Sep 2011 11:02:50 -0400 From: Daniel De Graaf <dgdegra@tycho.nsa.gov> Organization: National Security Agency User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:6.0) Gecko/20110816 Thunderbird/6.0 MIME-Version: 1.0 To: Ian Campbell <Ian.Campbell@eu.citrix.com> References: <1313764724-12683-1-git-send-email-dgdegra@tycho.nsa.gov> <1316472208-12104-1-git-send-email-dgdegra@tycho.nsa.gov> <1316472208-12104-2-git-send-email-dgdegra@tycho.nsa.gov> <1316599431.3891.147.camel@zakaz.uk.xensource.com> In-Reply-To: <1316599431.3891.147.camel@zakaz.uk.xensource.com> X-Enigmail-Version: 1.3 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Cc: Stefano Stabellini <Stefano.Stabellini@eu.citrix.com>, "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>, Ian Jackson <Ian.Jackson@eu.citrix.com>, "konrad.wilk@oracle.com" <konrad.wilk@oracle.com> Subject: [Xen-devel] Re: [PATCH 1/3] libxc: add xc_gnttab_map_grant_ref_notify X-BeenThere: xen-devel@lists.xensource.com X-Mailman-Version: 2.1.5 Precedence: list List-Id: Xen developer discussion <xen-devel.lists.xensource.com> List-Unsubscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe> List-Post: <mailto:xen-devel@lists.xensource.com> List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help> List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=subscribe> Sender: xen-devel-bounces@lists.xensource.com Errors-To: xen-devel-bounces@lists.xensource.com On 09/21/2011 06:03 AM, Ian Campbell wrote: > On Mon, 2011-09-19 at 23:43 +0100, Daniel De Graaf wrote: >> @@ -116,4 +116,35 @@ struct ioctl_gntdev_set_max_grants { >> uint32_t count; >> }; >> >> +/* >> + * Sets up an unmap notification within the page, so that the other side can do >> + * cleanup if this side crashes. Required to implement cross-domain robust >> + * mutexes or close notification on communication channels. >> + * >> + * Each mapped page only supports one notification; multiple calls referring to >> + * the same page overwrite the previous notification. You must clear the >> + * notification prior to the IOCTL_GNTALLOC_DEALLOC_GREF if you do not want it >> + * to occur. >> + */ >> +#define IOCTL_GNTDEV_SET_UNMAP_NOTIFY \ >> +_IOC(_IOC_NONE, 'G', 7, sizeof(struct ioctl_gntdev_unmap_notify)) >> +struct ioctl_gntdev_unmap_notify { >> + /* IN parameters */ >> + /* Offset in the file descriptor for a byte within the page (same as >> + * used in mmap). > > I'm probably being thick but I don't understand what this means, i.e. > what this thing is relative to. This is an offset that acts like a byte offset in the /dev/xen/gntdev device. Conceptually, if /dev/xen/evtchn implemented pwrite() then this offset would be the offset you would pass to modify your target byte. For example, if you use gntdev to map two pages, the first will be at offset 0 and the second at 4096; you would pass 4098 here to indicate the third byte of the second page. The offsets (0, 4096) are returned by the map-grant ioctls. >> If using UNMAP_NOTIFY_CLEAR_BYTE, this is the byte to >> + * be cleared. Otherwise, it can be any byte in the page whose >> + * notification we are adjusting. >> + */ >> + uint64_t index; >> + /* Action(s) to take on unmap */ >> + uint32_t action; >> + /* Event channel to notify */ >> + uint32_t event_channel_port; > > evtchn_port_t ? Using that would require an include dependency on event_channel.h which is not exposed as a userspace-visible header. Linux's evtchn.h also does not use evtchn_port_t (it uses unsigned int). Since this is just a direct copy of the header from the linux source tree, any changes really need to happen there first. >> +}; >> + >> +/* Clear (set to zero) the byte specified by index */ >> +#define UNMAP_NOTIFY_CLEAR_BYTE 0x1 >> +/* Send an interrupt on the indicated event channel */ >> +#define UNMAP_NOTIFY_SEND_EVENT 0x2 >> + >> #endif /* __LINUX_PUBLIC_GNTDEV_H__ */ >> diff --git a/tools/libxc/xc_gnttab.c b/tools/libxc/xc_gnttab.c >> index 4f55fce..3d3c63b 100644 >> --- a/tools/libxc/xc_gnttab.c >> +++ b/tools/libxc/xc_gnttab.c >> @@ -18,6 +18,7 @@ >> */ >> >> #include "xc_private.h" >> +#include <errno.h> >> >> int xc_gnttab_op(xc_interface *xch, int cmd, void * op, int op_size, int count) >> { >> @@ -174,6 +175,28 @@ void *xc_gnttab_map_domain_grant_refs(xc_gnttab *xcg, >> count, domid, refs, prot); >> } >> >> +void *xc_gnttab_map_grant_ref_notify(xc_gnttab *xcg, >> + uint32_t domid, >> + uint32_t ref, >> + uint32_t notify_offset, >> + evtchn_port_t notify_port, >> + int *notify_result) >> +{ >> + if (xcg->ops->u.gnttab.map_grant_ref_notify) >> + return xcg->ops->u.gnttab.map_grant_ref_notify(xcg, xcg->ops_handle, >> + domid, ref, notify_offset, notify_port, notify_result); >> + else { >> + void* area = xcg->ops->u.gnttab.map_grant_ref(xcg, xcg->ops_handle, >> + domid, ref, PROT_READ|PROT_WRITE); >> + if (area && notify_result) { >> + *notify_result = -1; >> + errno = ENOSYS; >> + } >> + return area; >> + } > > I think the new public interface is fine but do we really need a new > internal interface here? > > I think you can just add the notify_* arguments to the existing OSDEP > function and have those OS backends which don't implement that feature > return ENOSYS if notify_offset != 0 (or ~0 or whatever invalid value > works). > > Why doesn't the *_notify variant take a prot argument? At least for the byte-clear portion of the notify, the page must be writable or the notify will not work. I suppose an event channel alone could be used for a read-only mapping, but normally the unmapping of a read-only mapping is not an important event - although I guess you could contrive a use for this type of notificaiton, so there's no reason not to allow it. > I'd be tempted to do away with notify_result too -- if the caller asked > for notification and we fail to give that then we can cleanup and return > an error. If they want to try again without the notification then that's > up to them. The source of the error might be unclear, but this would make the interface cleaner. > >> +} >> + >> + >> int xc_gnttab_munmap(xc_gnttab *xcg, >> void *start_address, >> uint32_t count) >> diff --git a/tools/libxc/xc_linux_osdep.c b/tools/libxc/xc_linux_osdep.c >> index dca6718..3040cb6 100644 >> --- a/tools/libxc/xc_linux_osdep.c >> +++ b/tools/libxc/xc_linux_osdep.c >> @@ -613,6 +613,62 @@ static void *linux_gnttab_map_domain_grant_refs(xc_gnttab *xcg, xc_osdep_handle >> return do_gnttab_map_grant_refs(xcg, h, count, &domid, 0, refs, prot); >> } >> >> +static void *linux_gnttab_map_grant_ref_notify(xc_gnttab *xch, xc_osdep_handle h, >> + uint32_t domid, uint32_t ref, >> + uint32_t notify_offset, >> + evtchn_port_t notify_port, >> + int *notify_result) >> +{ >> + int fd = (int)h; >> + int rv = 0; >> + struct ioctl_gntdev_map_grant_ref map; >> + struct ioctl_gntdev_unmap_notify notify; >> + void *addr; >> + >> + map.count = 1; >> + map.refs[0].domid = domid; >> + map.refs[0].ref = ref; >> + >> + if ( ioctl(fd, IOCTL_GNTDEV_MAP_GRANT_REF, &map) ) { >> + PERROR("xc_gnttab_map_grant_ref: ioctl MAP_GRANT_REF failed"); >> + return NULL; >> + } >> + >> + addr = mmap(NULL, XC_PAGE_SIZE, PROT_READ|PROT_WRITE, MAP_SHARED, fd, map.index); >> + if ( addr == MAP_FAILED ) >> + { >> + int saved_errno = errno; >> + struct ioctl_gntdev_unmap_grant_ref unmap_grant; >> + >> + PERROR("xc_gnttab_map_grant_ref: mmap failed"); >> + unmap_grant.index = map.index; >> + unmap_grant.count = 1; >> + ioctl(fd, IOCTL_GNTDEV_UNMAP_GRANT_REF, &unmap_grant); >> + errno = saved_errno; >> + return NULL; >> + } > > The non-notify variant handles EAGAIN, why doesn't this one need to do > so? The non-notify variant doesn't need to handle EAGAIN anymore (with modern kernels, at least... perhaps it should remain for older kernels). Also, do_gnttab_map_grant_refs does not handle EAGAIN. >> + >> + notify.index = map.index; >> + notify.action = 0; >> + if (notify_offset >= 0) { >> + notify.index += notify_offset; >> + notify.action |= UNMAP_NOTIFY_CLEAR_BYTE; >> + } >> + if (notify_port >= 0) { >> + notify.event_channel_port = notify_port; >> + notify.action |= UNMAP_NOTIFY_SEND_EVENT; >> + } >> + if (notify.action) >> + rv = ioctl(fd, IOCTL_GNTDEV_SET_UNMAP_NOTIFY, ¬ify); > > Is there a race if the other end (or this process) dies between the MAP > ioctl and here? > > Ian. > Technically it's a race, but it doesn't impact any reasonable use of the notification. The local process can't actually be using the shared page at this point, and the other side will not be certain that the map has actually succeeded until after the function returns (and it is notified in some way - libvchan changes the notify byte from 2->1 at this point). If the domain whose memory we are mapping crashes, this ioctl will succeed unless the event channel it refers to has already been invalidated - but either way, the notifications are now irrelevant as there is nobody to listen to them. -- Daniel De Graaf National Security Agency _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel From xen-devel-bounces@lists.xensource.com Wed Sep 21 08:09:13 2011 Return-path: <xen-devel-bounces@lists.xensource.com> Envelope-to: www-data@lists.xensource.com Delivery-date: Wed, 21 Sep 2011 08:09:13 -0700 Received: from localhost ([127.0.0.1] helo=lists.colo.xensource.com) by lists.xensource.com with esmtp (Exim 4.43) id 1R6OQD-0002O4-Ke; Wed, 21 Sep 2011 08:09:13 -0700 Received: from mail27.messagelabs.com ([193.109.254.147]) by lists.xensource.com with esmtp (Exim 4.43) id 1R6OMk-00020J-2D for xen-devel@lists.xensource.com; Wed, 21 Sep 2011 08:05:38 -0700 X-Env-Sender: konrad@oracle.com X-Msg-Ref: server-7.tower-27.messagelabs.com!1316617510!49593830!1 X-Originating-IP: [148.87.113.117] X-StarScan-Version: 6.4.1; banners=-,-,- X-VirusChecked: Checked Received: (qmail 7363 invoked from network); 21 Sep 2011 15:05:11 -0000 Received: from rcsinet15.oracle.com (HELO rcsinet15.oracle.com) (148.87.113.117) by server-7.tower-27.messagelabs.com with DHE-RSA-AES256-SHA encrypted SMTP; 21 Sep 2011 15:05:11 -0000 Received: from rtcsinet21.oracle.com (rtcsinet21.oracle.com [66.248.204.29]) by rcsinet15.oracle.com (Switch-3.4.4/Switch-3.4.4) with ESMTP id p8LF5NLT030767 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Wed, 21 Sep 2011 15:05:25 GMT Received: from acsmt356.oracle.com (acsmt356.oracle.com [141.146.40.156]) by rtcsinet21.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id p8LF5MFf026500 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 21 Sep 2011 15:05:23 GMT Received: from abhmt102.oracle.com (abhmt102.oracle.com [141.146.116.54]) by acsmt356.oracle.com (8.12.11.20060308/8.12.11) with ESMTP id p8LF5H5b005019; Wed, 21 Sep 2011 10:05:17 -0500 Received: from oracle.com (/209.6.55.207) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Wed, 21 Sep 2011 08:05:17 -0700 Received: by oracle.com (Postfix, from userid 1000) id 076431362; Wed, 21 Sep 2011 11:05:22 -0400 (EDT) Date: Wed, 21 Sep 2011 11:05:22 -0400 From: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com> To: David Vrabel <david.vrabel@citrix.com> Subject: Re: [Xen-devel] [PATCH 3/7] xen/balloon: account for pages released during memory setup Message-ID: <20110921150522.GD541@phenom.oracle.com> References: <1316089768-22461-1-git-send-email-david.vrabel@citrix.com> <1316089768-22461-4-git-send-email-david.vrabel@citrix.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <1316089768-22461-4-git-send-email-david.vrabel@citrix.com> User-Agent: Mutt/1.5.21 (2010-09-15) X-Source-IP: rtcsinet21.oracle.com [66.248.204.29] X-CT-RefId: str=0001.0A090207.4E79FD38.011C,ss=1,re=0.000,fgs=0 Cc: xen-devel@lists.xensource.com, Konrad Rzeszutek Wilk <konrad.wilk@oracle.com> X-BeenThere: xen-devel@lists.xensource.com X-Mailman-Version: 2.1.5 Precedence: list List-Id: Xen developer discussion <xen-devel.lists.xensource.com> List-Unsubscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe> List-Post: <mailto:xen-devel@lists.xensource.com> List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help> List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=subscribe> Sender: xen-devel-bounces@lists.xensource.com Errors-To: xen-devel-bounces@lists.xensource.com On Thu, Sep 15, 2011 at 01:29:24PM +0100, David Vrabel wrote: > From: David Vrabel <david.vrabel@citrix.com> > > In xen_memory_setup() pages that occur in gaps in the memory map are > released back to Xen. This reduces the domain's current page count in > the hypervisor. The Xen balloon driver does not correctly decrease > its initial current_pages count to reflect this. If 'delta' pages are > released and the target is adjusted the resulting reservation is > always 'delta' less than the requested target. > > This affects dom0 if the initial allocation of pages overlaps the PCI > memory region but won't affect most domU guests that have been setup > with pseudo-physical memory maps that don't have gaps. > > Fix this by accouting for the released pages when starting the balloon > driver. Does this make the behaviour of the pvops guest be similar to the old-style XenOLinux? If so, perhaps we should include that in the git description for usability purposes (ie, when somebody searches the git log for what has happened in v3.2 Linux). > > If the domain's targets are managed by xapi, the domain may eventually > run out of memory and die because xapi currently gets its target > calculations wrong and whenever it is restarted it always reduces the > target by 'delta'. > > Signed-off-by: David Vrabel <david.vrabel@citrix.com> > --- > arch/x86/xen/setup.c | 7 ++++++- > drivers/xen/balloon.c | 4 +++- > include/xen/page.h | 2 ++ > 3 files changed, 11 insertions(+), 2 deletions(-) > > diff --git a/arch/x86/xen/setup.c b/arch/x86/xen/setup.c > index 46d6d21..c983717 100644 > --- a/arch/x86/xen/setup.c > +++ b/arch/x86/xen/setup.c > @@ -39,6 +39,9 @@ extern void xen_syscall32_target(void); > /* Amount of extra memory space we add to the e820 ranges */ > phys_addr_t xen_extra_mem_start, xen_extra_mem_size; > > +/* Number of pages released from the initial allocation. */ > +unsigned long xen_released_pages; > + > /* > * The maximum amount of extra memory compared to the base size. The > * main scaling factor is the size of struct page. At extreme ratios > @@ -313,7 +316,9 @@ char * __init xen_memory_setup(void) > extra_pages = 0; > } > > - extra_pages += xen_return_unused_memory(xen_start_info->nr_pages, &e820); > + xen_released_pages = xen_return_unused_memory(xen_start_info->nr_pages, > + &e820); > + extra_pages += xen_released_pages; > > /* > * Clamp the amount of extra memory to a EXTRA_MEM_RATIO > diff --git a/drivers/xen/balloon.c b/drivers/xen/balloon.c > index 5dfd8f8..4f59fb3 100644 > --- a/drivers/xen/balloon.c > +++ b/drivers/xen/balloon.c > @@ -565,7 +565,9 @@ static int __init balloon_init(void) > > pr_info("xen/balloon: Initialising balloon driver.\n"); > > - balloon_stats.current_pages = xen_pv_domain() ? min(xen_start_info->nr_pages, max_pfn) : max_pfn; > + balloon_stats.current_pages = xen_pv_domain() > + ? min(xen_start_info->nr_pages - xen_released_pages, max_pfn) > + : max_pfn; > balloon_stats.target_pages = balloon_stats.current_pages; > balloon_stats.balloon_low = 0; > balloon_stats.balloon_high = 0; > diff --git a/include/xen/page.h b/include/xen/page.h > index 0be36b9..92b61f8 100644 > --- a/include/xen/page.h > +++ b/include/xen/page.h > @@ -5,4 +5,6 @@ > > extern phys_addr_t xen_extra_mem_start, xen_extra_mem_size; > > +extern unsigned long xen_released_pages; > + > #endif /* _XEN_PAGE_H */ > -- > 1.7.2.5 > > > _______________________________________________ > Xen-devel mailing list > Xen-devel@lists.xensource.com > http://lists.xensource.com/xen-devel _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel From xen-devel-bounces@lists.xensource.com Wed Sep 21 08:11:44 2011 Return-path: <xen-devel-bounces@lists.xensource.com> Envelope-to: www-data@lists.xensource.com Delivery-date: Wed, 21 Sep 2011 08:11:44 -0700 Received: from localhost ([127.0.0.1] helo=lists.colo.xensource.com) by lists.xensource.com with esmtp (Exim 4.43) id 1R6OSd-0002qy-6l; Wed, 21 Sep 2011 08:11:43 -0700 Received: from mail216.messagelabs.com ([85.158.143.99]) by lists.xensource.com with esmtp (Exim 4.43) id 1R6ORC-0002bO-DE for xen-devel@lists.xensource.com; Wed, 21 Sep 2011 08:10:15 -0700 X-Env-Sender: konrad@oracle.com X-Msg-Ref: server-9.tower-216.messagelabs.com!1316617809!19125858!1 X-Originating-IP: [141.146.126.227] X-StarScan-Version: 6.4.1; banners=-,-,- X-VirusChecked: Checked Received: (qmail 27490 invoked from network); 21 Sep 2011 15:10:11 -0000 Received: from acsinet15.oracle.com (HELO acsinet15.oracle.com) (141.146.126.227) by server-9.tower-216.messagelabs.com with DHE-RSA-AES256-SHA encrypted SMTP; 21 Sep 2011 15:10:11 -0000 Received: from acsinet21.oracle.com (acsinet21.oracle.com [141.146.126.237]) by acsinet15.oracle.com (Switch-3.4.4/Switch-3.4.4) with ESMTP id p8LF9vwJ023100 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Wed, 21 Sep 2011 15:10:03 GMT Received: from acsmt356.oracle.com (acsmt356.oracle.com [141.146.40.156]) by acsinet21.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id p8LEwrIE028621 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 21 Sep 2011 14:58:54 GMT Received: from abhmt107.oracle.com (abhmt107.oracle.com [141.146.116.59]) by acsmt356.oracle.com (8.12.11.20060308/8.12.11) with ESMTP id p8LEwl4I031129; Wed, 21 Sep 2011 09:58:47 -0500 Received: from oracle.com (/209.6.55.207) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Wed, 21 Sep 2011 07:58:47 -0700 Received: by oracle.com (Postfix, from userid 1000) id 765B51362; Wed, 21 Sep 2011 10:58:53 -0400 (EDT) Date: Wed, 21 Sep 2011 10:58:53 -0400 From: konrad.wilk@oracle.com To: Stefano Stabellini <stefano.stabellini@eu.citrix.com> Message-ID: <20110921145853.GA541@phenom.oracle.com> References: <alpine.DEB.2.00.1109081944150.12963@kaball-desktop> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <alpine.DEB.2.00.1109081944150.12963@kaball-desktop> User-Agent: Mutt/1.5.21 (2010-09-15) X-Source-IP: acsinet21.oracle.com [141.146.126.237] X-Auth-Type: Internal IP X-CT-RefId: str=0001.0A090209.4E79FE4C.0186:SCFMA922111,ss=1,re=-6.300,fgs=0 Cc: Jeremy Fitzhardinge <jeremy@goop.org>, xen-devel@lists.xensource.com, linux-kernel@vger.kernel.org, Konrad Rzeszutek Wilk <konrad.wilk@oracle.com> Subject: [Xen-devel] Re: [PATCH v4 2/2] xen: modify kernel mappings corresponding to granted pages X-BeenThere: xen-devel@lists.xensource.com X-Mailman-Version: 2.1.5 Precedence: list List-Id: Xen developer discussion <xen-devel.lists.xensource.com> List-Unsubscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe> List-Post: <mailto:xen-devel@lists.xensource.com> List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help> List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=subscribe> Sender: xen-devel-bounces@lists.xensource.com Errors-To: xen-devel-bounces@lists.xensource.com On Thu, Sep 08, 2011 at 07:45:29PM +0100, Stefano Stabellini wrote: > If we want to use granted pages for AIO, changing the mappings of a user > vma and the corresponding p2m is not enough, we also need to update the > kernel mappings accordingly. Please add:" But only for pages that are created for user usages through /dev/xen/gntdev. As in, pages that have been in use by the kernel and use the P2M will not need this special mapping." Just so that it is quite clear when in a year somebody wants to debug this code and wants to figure out if this patch causes issues. .. more comments below. > In order to avoid the complexity of dealing with highmem, we allocated > the pages lowmem. > We issue a HYPERVISOR_grant_table_op right away in > m2p_add_override and we remove the mappings using another > HYPERVISOR_grant_table_op in m2p_remove_override. > Considering that m2p_add_override and m2p_remove_override are called > once per page we use multicalls and hypercall batching. > > Use the kmap_op pointer directly as argument to do the mapping as it is > guaranteed to be present up until the unmapping is done. > Before issuing any unmapping multicalls, we need to make sure that the > mapping has already being done, because we need the kmap->handle to be > set correctly. > > Signed-off-by: Stefano Stabellini <stefano.stabellini@eu.citrix.com> > --- > arch/x86/include/asm/xen/page.h | 5 ++- > arch/x86/xen/p2m.c | 68 +++++++++++++++++++++++++++++------ > drivers/block/xen-blkback/blkback.c | 2 +- > drivers/xen/gntdev.c | 27 +++++++++++++- > drivers/xen/grant-table.c | 6 ++-- > include/xen/grant_table.h | 1 + > 6 files changed, 92 insertions(+), 17 deletions(-) > > diff --git a/arch/x86/include/asm/xen/page.h b/arch/x86/include/asm/xen/page.h > index 7ff4669..0ce1884 100644 > --- a/arch/x86/include/asm/xen/page.h > +++ b/arch/x86/include/asm/xen/page.h > @@ -12,6 +12,7 @@ > #include <asm/pgtable.h> > > #include <xen/interface/xen.h> > +#include <xen/grant_table.h> > #include <xen/features.h> > > /* Xen machine address */ > @@ -31,8 +32,10 @@ typedef struct xpaddr { > #define INVALID_P2M_ENTRY (~0UL) > #define FOREIGN_FRAME_BIT (1UL<<(BITS_PER_LONG-1)) > #define IDENTITY_FRAME_BIT (1UL<<(BITS_PER_LONG-2)) > +#define GRANT_FRAME_BIT (1UL<<(BITS_PER_LONG-3)) > #define FOREIGN_FRAME(m) ((m) | FOREIGN_FRAME_BIT) > #define IDENTITY_FRAME(m) ((m) | IDENTITY_FRAME_BIT) > +#define GRANT_FRAME(m) ((m) | GRANT_FRAME_BIT) > > /* Maximum amount of memory we can handle in a domain in pages */ > #define MAX_DOMAIN_PAGES \ > @@ -48,7 +51,7 @@ extern unsigned long set_phys_range_identity(unsigned long pfn_s, > unsigned long pfn_e); > > extern int m2p_add_override(unsigned long mfn, struct page *page, > - bool clear_pte); > + struct gnttab_map_grant_ref *kmap_op); > extern int m2p_remove_override(struct page *page, bool clear_pte); > extern struct page *m2p_find_override(unsigned long mfn); > extern unsigned long m2p_find_override_pfn(unsigned long mfn, unsigned long pfn); > diff --git a/arch/x86/xen/p2m.c b/arch/x86/xen/p2m.c > index 58efeb9..23f8465 100644 > --- a/arch/x86/xen/p2m.c > +++ b/arch/x86/xen/p2m.c > @@ -161,7 +161,9 @@ > #include <asm/xen/page.h> > #include <asm/xen/hypercall.h> > #include <asm/xen/hypervisor.h> > +#include <xen/grant_table.h> > > +#include "multicalls.h" > #include "xen-ops.h" > > static void __init m2p_override_init(void); > @@ -676,7 +678,8 @@ static unsigned long mfn_hash(unsigned long mfn) > } > > /* Add an MFN override for a particular page */ > -int m2p_add_override(unsigned long mfn, struct page *page, bool clear_pte) > +int m2p_add_override(unsigned long mfn, struct page *page, > + struct gnttab_map_grant_ref *kmap_op) > { > unsigned long flags; > unsigned long pfn; > @@ -699,9 +702,20 @@ int m2p_add_override(unsigned long mfn, struct page *page, bool clear_pte) > if (unlikely(!set_phys_to_machine(pfn, FOREIGN_FRAME(mfn)))) > return -ENOMEM; > > - if (clear_pte && !PageHighMem(page)) > - /* Just zap old mapping for now */ > - pte_clear(&init_mm, address, ptep); > + if (kmap_op != NULL) { > + if (!PageHighMem(page)) { > + struct multicall_space mcs = xen_mc_entry(sizeof(*kmap_op)); > + > + MULTI_grant_table_op(mcs.mc, > + GNTTABOP_map_grant_ref, kmap_op, 1); > + > + xen_mc_issue(PARAVIRT_LAZY_MMU); > + } > + page->private |= GRANT_FRAME_BIT; > + /* let's use dev_bus_addr to record the old mfn instead */ > + kmap_op->dev_bus_addr = page->index; > + page->index = (unsigned long) kmap_op; > + } > spin_lock_irqsave(&m2p_override_lock, flags); > list_add(&page->lru, &m2p_overrides[mfn_hash(mfn)]); > spin_unlock_irqrestore(&m2p_override_lock, flags); > @@ -735,13 +749,45 @@ int m2p_remove_override(struct page *page, bool clear_pte) > spin_lock_irqsave(&m2p_override_lock, flags); > list_del(&page->lru); > spin_unlock_irqrestore(&m2p_override_lock, flags); > - set_phys_to_machine(pfn, page->index); > > - if (clear_pte && !PageHighMem(page)) > - set_pte_at(&init_mm, address, ptep, > - pfn_pte(pfn, PAGE_KERNEL)); > - /* No tlb flush necessary because the caller already > - * left the pte unmapped. */ > + if (clear_pte) { > + struct gnttab_map_grant_ref *map_op = > + (struct gnttab_map_grant_ref *) page->index; > + set_phys_to_machine(pfn, map_op->dev_bus_addr); > + if (!PageHighMem(page)) { > + struct multicall_space mcs; > + struct gnttab_unmap_grant_ref *unmap_op; > + > + /* > + * Has the grant_op mapping multicall being issued? If not, > + * make sure it is called now. > + */ > + if (map_op->handle == -1) > + xen_mc_flush(); How do you trigger this case? The mapping looks to be set by "gntdev_add_map" which is happening right after in gntdev_alloc_map.. If it had failed from the gntdev_alloc_map to gntdev_add_map this page would have never been used in the m2p as we would not have provided the proper op.index value to the user. Which mean that the user could not have mmaped and gotten to this code. > + if (map_op->handle == -1) { The other one I can understand, but this one I am baffled by. How would the xen_mc_flush trigger the handle to be set to -1? Is the hypercall writting that value in the op.handle after it has completed? Also, we might want to document somwhere -1 now that I think of it. It does not look like that is a value that is defined anywhere. > + printk(KERN_WARNING "m2p_remove_override: pfn %lx mfn %lx, " > + "failed to modify kernel mappings", pfn, mfn); > + return -1; > + } > + > + mcs = xen_mc_entry(sizeof(struct gnttab_unmap_grant_ref)); > + unmap_op = mcs.args; > + unmap_op->host_addr = map_op->host_addr; > + unmap_op->handle = map_op->handle; > + unmap_op->dev_bus_addr = 0; > + > + MULTI_grant_table_op(mcs.mc, > + GNTTABOP_unmap_grant_ref, unmap_op, 1); > + > + xen_mc_issue(PARAVIRT_LAZY_MMU); > + > + set_pte_at(&init_mm, address, ptep, > + pfn_pte(pfn, PAGE_KERNEL)); > + __flush_tlb_single(address); > + map_op->host_addr = 0; I am not sure that is neccesseray? When we are done, err, when we end up calling here that means the region has been unmapped or IOCTL_GNTDEV_UNMAP_GRANT_REF called right? And when we do end up here, then the a whole bunch of those pages get free-ed? Don't they? > + } > + } else > + set_phys_to_machine(pfn, page->index); > > return 0; > } > @@ -758,7 +804,7 @@ struct page *m2p_find_override(unsigned long mfn) > spin_lock_irqsave(&m2p_override_lock, flags); > > list_for_each_entry(p, bucket, lru) { > - if (p->private == mfn) { > + if ((p->private & (~GRANT_FRAME_BIT)) == mfn) { > ret = p; > break; > } > diff --git a/drivers/block/xen-blkback/blkback.c b/drivers/block/xen-blkback/blkback.c > index 2330a9a..1540792 100644 > --- a/drivers/block/xen-blkback/blkback.c > +++ b/drivers/block/xen-blkback/blkback.c > @@ -396,7 +396,7 @@ static int xen_blkbk_map(struct blkif_request *req, > continue; > > ret = m2p_add_override(PFN_DOWN(map[i].dev_bus_addr), > - blkbk->pending_page(pending_req, i), false); > + blkbk->pending_page(pending_req, i), NULL); > if (ret) { > pr_alert(DRV_PFX "Failed to install M2P override for %lx (ret: %d)\n", > (unsigned long)map[i].dev_bus_addr, ret); > diff --git a/drivers/xen/gntdev.c b/drivers/xen/gntdev.c > index 7b9b1d1..bfe1271 100644 > --- a/drivers/xen/gntdev.c > +++ b/drivers/xen/gntdev.c > @@ -83,6 +83,7 @@ struct grant_map { > struct ioctl_gntdev_grant_ref *grants; > struct gnttab_map_grant_ref *map_ops; > struct gnttab_unmap_grant_ref *unmap_ops; > + struct gnttab_map_grant_ref *kmap_ops; > struct page **pages; > }; > > @@ -116,10 +117,12 @@ static struct grant_map *gntdev_alloc_map(struct gntdev_priv *priv, int count) > add->grants = kzalloc(sizeof(add->grants[0]) * count, GFP_KERNEL); > add->map_ops = kzalloc(sizeof(add->map_ops[0]) * count, GFP_KERNEL); > add->unmap_ops = kzalloc(sizeof(add->unmap_ops[0]) * count, GFP_KERNEL); > + add->kmap_ops = kzalloc(sizeof(add->kmap_ops[0]) * count, GFP_KERNEL); > add->pages = kzalloc(sizeof(add->pages[0]) * count, GFP_KERNEL); > if (NULL == add->grants || > NULL == add->map_ops || > NULL == add->unmap_ops || > + NULL == add->kmap_ops || > NULL == add->pages) > goto err; > > @@ -129,6 +132,7 @@ static struct grant_map *gntdev_alloc_map(struct gntdev_priv *priv, int count) > for (i = 0; i < count; i++) { > add->map_ops[i].handle = -1; > add->unmap_ops[i].handle = -1; > + add->kmap_ops[i].handle = -1; > } > > add->index = 0; > @@ -142,6 +146,7 @@ err: > kfree(add->grants); > kfree(add->map_ops); > kfree(add->unmap_ops); > + kfree(add->kmap_ops); > kfree(add); > return NULL; > } > @@ -243,10 +248,30 @@ static int map_grant_pages(struct grant_map *map) > gnttab_set_unmap_op(&map->unmap_ops[i], addr, > map->flags, -1 /* handle */); > } > + } else { > + for (i = 0; i < map->count; i++) { > + unsigned level; > + unsigned long address = (unsigned long) > + pfn_to_kaddr(page_to_pfn(map->pages[i])); > + pte_t *ptep; > + u64 pte_maddr = 0; > + if (!PageHighMem(map->pages[i])) { > + ptep = lookup_address(address, &level); > + pte_maddr = > + arbitrary_virt_to_machine(ptep).maddr; > + } And it looks like having kmap->ops.host_addr = 0 is valid so that is good on the chance it is high map... but that begs the question whether we should the hypercall at all? As in, can we do anything with the grants if there is no PTE or MFN associated with it - just the handle? Does Xen do something special - like a relaxed "oh ok, we can handle that later on" ? > + gnttab_set_map_op(&map->kmap_ops[i], pte_maddr, > + map->flags | > + GNTMAP_host_map | > + GNTMAP_contains_pte, > + map->grants[i].ref, > + map->grants[i].domid); > + } So, on startup.. (before this function is called) the find_grant_ptes is called which pretty much does the exact thing for each virtual address. Except its flags are GNTMAP_application_map instead of GNTMAP_host_map. It even uses the same type structure.. It fills out map_ops[i] one. Can we use that instead of adding a new structure? > } > > pr_debug("map %d+%d\n", map->index, map->count); > - err = gnttab_map_refs(map->map_ops, map->pages, map->count); > + err = gnttab_map_refs(map->map_ops, use_ptemod ? map->kmap_ops : NULL, > + map->pages, map->count); > if (err) > return err; > > diff --git a/drivers/xen/grant-table.c b/drivers/xen/grant-table.c > index 4f44b34..8c71ab8 100644 > --- a/drivers/xen/grant-table.c > +++ b/drivers/xen/grant-table.c > @@ -448,7 +448,8 @@ unsigned int gnttab_max_grant_frames(void) > EXPORT_SYMBOL_GPL(gnttab_max_grant_frames); > > int gnttab_map_refs(struct gnttab_map_grant_ref *map_ops, > - struct page **pages, unsigned int count) > + struct gnttab_map_grant_ref *kmap_ops, > + struct page **pages, unsigned int count) > { > int i, ret; > pte_t *pte; > @@ -488,8 +489,7 @@ int gnttab_map_refs(struct gnttab_map_grant_ref *map_ops, > */ > return -EOPNOTSUPP; > } > - ret = m2p_add_override(mfn, pages[i], > - map_ops[i].flags & GNTMAP_contains_pte); > + ret = m2p_add_override(mfn, pages[i], &kmap_ops[i]); > if (ret) > return ret; > } > diff --git a/include/xen/grant_table.h b/include/xen/grant_table.h > index b1fab6b..6b99bfb 100644 > --- a/include/xen/grant_table.h > +++ b/include/xen/grant_table.h > @@ -156,6 +156,7 @@ unsigned int gnttab_max_grant_frames(void); > #define gnttab_map_vaddr(map) ((void *)(map.host_virt_addr)) > > int gnttab_map_refs(struct gnttab_map_grant_ref *map_ops, > + struct gnttab_map_grant_ref *kmap_ops, > struct page **pages, unsigned int count); > int gnttab_unmap_refs(struct gnttab_unmap_grant_ref *unmap_ops, > struct page **pages, unsigned int count); > -- > 1.7.2.3 > > -- > To unsubscribe from this list: send the line "unsubscribe linux-kernel" in > the body of a message to majordomo@vger.kernel.org > More majordomo info at http://vger.kernel.org/majordomo-info.html > Please read the FAQ at http://www.tux.org/lkml/ _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel From xen-devel-bounces@lists.xensource.com Wed Sep 21 08:14:53 2011 Return-path: <xen-devel-bounces@lists.xensource.com> Envelope-to: www-data@lists.xensource.com Delivery-date: Wed, 21 Sep 2011 08:14:53 -0700 Received: from localhost ([127.0.0.1] helo=lists.colo.xensource.com) by lists.xensource.com with esmtp (Exim 4.43) id 1R6OVf-0003Nr-TD; Wed, 21 Sep 2011 08:14:52 -0700 Received: from mail216.messagelabs.com ([85.158.143.99]) by lists.xensource.com with smtp (Exim 4.43) id 1R6OUL-00039W-Su for xen-devel@lists.xensource.com; Wed, 21 Sep 2011 08:13:37 -0700 X-Env-Sender: davidtecher@yahoo.fr X-Msg-Ref: server-2.tower-216.messagelabs.com!1316618006!18679565!1 X-Originating-IP: [77.238.189.213] X-StarScan-Version: 6.4.1; banners=-,-,- X-VirusChecked: Checked Received: (qmail 18555 invoked from network); 21 Sep 2011 15:13:26 -0000 Received: from nm3-vm0.bullet.mail.ird.yahoo.com (HELO nm3-vm0.bullet.mail.ird.yahoo.com) (77.238.189.213) by server-2.tower-216.messagelabs.com with SMTP; 21 Sep 2011 15:13:26 -0000 Received: from [77.238.189.231] by nm3.bullet.mail.ird.yahoo.com with NNFMP; 21 Sep 2011 15:13:26 -0000 Received: from [212.82.108.236] by tm12.bullet.mail.ird.yahoo.com with NNFMP; 21 Sep 2011 15:13:26 -0000 Received: from [127.0.0.1] by omp1001.mail.ird.yahoo.com with NNFMP; 21 Sep 2011 15:13:26 -0000 X-Yahoo-Newman-Property: ymail-3 X-Yahoo-Newman-Id: 520639.37026.bm@omp1001.mail.ird.yahoo.com Received: (qmail 76445 invoked by uid 60001); 21 Sep 2011 15:13:26 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.fr; s=s1024; t=1316618006; bh=5I6n6Bu5pWoRuilXYPmYXur+vlZ+py3VXQRsCVSY2eE=; h=X-YMail-OSG:Received:X-Mailer:References:Message-ID:Date:From:Reply-To:Subject:To:Cc:In-Reply-To:MIME-Version:Content-Type; b=xpHeLGFTXSb5QHSkK0bYi1pDvgQFUSHJHZ21lt7p1dWwFLpYibAOOnwIXjdSWcDkzwxAYvhELajmW0WZPvf9uMxipLYx0LIAj1g+YNdVjZ5bMBwUtLiOGgO/W5cjgDyVPXwVZAhFM7NvB7V9H0IkMik0NpFPYdd+JB7fKfTm8KA= DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.fr; h=X-YMail-OSG:Received:X-Mailer:References:Message-ID:Date:From:Reply-To:Subject:To:Cc:In-Reply-To:MIME-Version:Content-Type; b=YB1tgy0uLScds0MvfI6AzV69NexlH8BzZ5WQ7j4pz6pZstcjePJpnuO0GtqEBi61dqWxs2iauXzi1oFXXmH4Zz4e9QJh9W8y9eSj23XPQCu1gi2Vz6wzbcjkrATvsMKKynAKI9GVwM2Uo45dnQe7S2W7zwDpGt2EeoQnrrZKZBw=; X-YMail-OSG: QhALMtkVM1lO8rtFiZcn9wVCDkFXBzbkfVBEv0DtzGPpDrj B1JSfU6JcT5eQAa14NuLDf1D29ieLlRzjQUHxVx3F9cBwPm8q4e3UtH.g8sl cITs77dH92UJt9ZeJtTU.1sKeXp9ImnTfNu8MBL7YsdrF97kVXpNVqJR086M dOoem2R4LUyzT706SeofrycuMfwvwRC.SPw1FuhPj1OoE4WKhc6xOOuFZEWX sdGP8xGAzzqnSN4pQB718Mtvl5lhbEnOLPOL36VRYXdPGjkCulyS3hOUxImG ja2doyWE8GAxJElVeZ6DyIrIyo4peT4i0F3LDFvQcWrlznpV4ffdGoR7d.wF RIaboV6tOzWyk7rrexDgcL6GPUWk5AsZhTMeV0JcVeaHLga4qeuzX0wAUiJV i4PabXHE_8bZnADGNFTjJkW78izBbZR78nQz1wj88lfq8sbTElMlIouZMM3i 4puX8rWtkhVEUBp4Hu.QS_u_R9O1vEDR5oyGhKDN1jOSsPvljikinUbnLhAA nUnTmdDvnTtcsyCrahbIgLPIXv3HuEki_uGzrw6FJdZE2U.quBo62jqOS67H 7CYboz8UB94lM9MQRKuDuUIQ4ufXy1Eqpg3CsbUDaQgQRf29_J_YKPbkQkh3 puMM1Etxu0Pm37rkSpc5zyL9bCbqgzEWSGxhJGpx3aE5k9zvKVcSNL4WKp5l JwWiqkvm.TH_8XLqJuLZZ0cWWpT.NqAxJlNwIHKo0vuM8mKjMuNS6iFSkiYb 7uXJtzqyMQ5X3uwU0trcfaNy1.ocoWxfJ4IRUoyF7S9WRey7s5aSA0NOaTCK ePf6.0JvHMjK4lujXIIbViwMshCcM.fMRi8xrKThST4AH7GUZay0AJ1.x6NI Fp5YNXq3mVcwNto7YWfjzGb4DlS1lrLsTSbZatzxKWmw- Received: from [195.167.237.98] by web29818.mail.ird.yahoo.com via HTTP; Wed, 21 Sep 2011 16:13:26 BST X-Mailer: YahooMailWebService/0.8.114.317681 References: <1315401901083-4778494.post@n5.nabble.com> <1315403644525-4778586.post@n5.nabble.com> <1315405372.87224.YahooMailNeo@web29801.mail.ird.yahoo.com> <1315405921936-4778727.post@n5.nabble.com> <1316612652132-4826391.post@n5.nabble.com> <1316613404292-4826432.post@n5.nabble.com> <1316614084705-4826479.post@n5.nabble.com> <1316615526442-4826582.post@n5.nabble.com> <1316616001843-4826614.post@n5.nabble.com> <1316616472579-4826635.post@n5.nabble.com> <1316616757871-4826655.post@n5.nabble.com> Message-ID: <1316618006.67296.YahooMailNeo@web29818.mail.ird.yahoo.com> Date: Wed, 21 Sep 2011 16:13:26 +0100 (BST) From: David TECHER <davidtecher@yahoo.fr> Subject: Re : Re : Re : Re : [Xen-devel] Re: Patches for VGA-Passthrough XEN 4.2 unstable To: "JavMV \[via Xen\]" <ml-node+s1045712n4826655h3@n5.nabble.com> In-Reply-To: <1316616757871-4826655.post@n5.nabble.com> MIME-Version: 1.0 Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com> X-BeenThere: xen-devel@lists.xensource.com X-Mailman-Version: 2.1.5 Precedence: list Reply-To: David TECHER <davidtecher@yahoo.fr> List-Id: Xen developer discussion <xen-devel.lists.xensource.com> List-Unsubscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe> List-Post: <mailto:xen-devel@lists.xensource.com> List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help> List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=subscribe> Content-Type: multipart/mixed; boundary="===============0575994549==" Sender: xen-devel-bounces@lists.xensource.com Errors-To: xen-devel-bounces@lists.xensource.com --===============0575994549== Content-Type: multipart/alternative; boundary="576309831-230176069-1316618006=:67296" --576309831-230176069-1316618006=:67296 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable Once you are OK, can you tell us if VGA Passthrough works for your GTX 460.= =0A=0AI mean once you update dsd with the required memory ranges for you ca= rd.=0A=0A=0AIf it is ok, could you give us information about the manufactue= r's informations for you GTX 460 (MSI, Gigabite, and so on)..=0A=0AI am lit= tle exciting to know if it works for you :) I hope=0A=0A=0AFor the moment I= came to the conclusion that the video you speak about (Ubisoft on Youtube)= was not done with a GTX 460=A0 (that's my personal impression)=0A=0A=0AA l= ot of people - I am one of them - have tryed with a GTX 460. I've never see= n someone succeeding to use it.=0A=0ADavid=0A=0A=0A=0A_____________________= ___________=0ADe=A0: JavMV [via Xen] <ml-node+s1045712n4826655h3@n5.nabble.= com>=0A=C0=A0: David TECHER <davidtecher@yahoo.fr>=0AEnvoy=E9 le : Mercredi= 21 Septembre 2011 16h52=0AObjet=A0: Re: Re : Re : Re : [Xen-devel] Re: Pat= ches for VGA-Passthrough XEN 4.2 unstable=0A=0A=0AHaha yeah! thank you, I r= ealise that if I did update grub then the version of xen-tools and xen-kern= el match up so now I can make xend run normally, I have to manually execute= 'xenstored', 'xenconsoled' and then 'xend start' because xend fail to star= t at boot but anyways I have xend running now so I will fix the automatical= ly start later. =0AJavMV=0A=0A________________________________=0A =0AIf you= reply to this email, your message will be added to the discussion below:ht= tp://xen.1045712.n5.nabble.com/Patches-for-VGA-Passthrough-XEN-4-2-unstable= -tp4406265p4826655.html =0ATo unsubscribe from Patches for VGA-Passthrough = XEN 4.2 unstable, click here. --576309831-230176069-1316618006=:67296 Content-Type: text/html; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable <html><body><div style=3D"color:#000; background-color:#fff; font-family:ti= mes new roman, new york, times, serif;font-size:12pt"><div><span>Once you a= re OK, can you tell us if VGA Passthrough works for your GTX 460.</span></d= iv><div><br><span></span></div><div><span>I mean once you update dsd with t= he required memory ranges for you card.<br></span></div><div><br><span></sp= an></div><div><span>If it is ok, could you give us information about the ma= nufactuer's informations for you GTX 460 (MSI, Gigabite, and so on)..</span= ></div><div><br><span></span></div><div><span>I am little exciting to know = if it works for you :) I hope<br></span></div><div><br><span></span></div><= div><span>For the moment I came to the conclusion that the video you speak = about (Ubisoft on Youtube) was not done with a GTX 460  (that's my per= sonal impression)<br></span></div><div><br><span></span></div><div><span>A = lot of people - I am one of them - have tryed with a GTX 460. I've never seen someone succeeding to use it.</span></div><div><br><span></span= ></div><div><span>David<br></span></div><div><br></div><div style=3D"font-f= amily: times new roman, new york, times, serif; font-size: 12pt;"><div styl= e=3D"font-family: times new roman, new york, times, serif; font-size: 12pt;= "><font size=3D"2" face=3D"Arial"><hr size=3D"1"><b><span style=3D"font-wei= ght:bold;">De :</span></b> JavMV [via Xen] <ml-node+s1045712n482665= 5h3@n5.nabble.com><br><b><span style=3D"font-weight: bold;">=C0 :</= span></b> David TECHER <davidtecher@yahoo.fr><br><b><span style=3D"fo= nt-weight: bold;">Envoy=E9 le :</span></b> Mercredi 21 Septembre 2011 16h52= <br><b><span style=3D"font-weight: bold;">Objet :</span></b> Re: Re : = Re : Re : [Xen-devel] Re: Patches for VGA-Passthrough XEN 4.2 unstable<br><= /font><br><div id=3D"yiv402847711">=0A=0A=09Haha yeah! thank you, I realise= that if I did update grub then the version of xen-tools and xen-kernel mat= ch up so now I can make xend run normally, I have to manually execute 'xens= tored', 'xenconsoled' and then 'xend start' because xend fail to start at b= oot but anyways I have xend running now so I will fix the automatically sta= rt later.=0A=09<div class=3D"yiv402847711signature" style=3D"margin-top:1em= ;color:#666666;font-size:11px;">JavMV</div>=0A=09<br>=0A=09<br>=0A=09<hr no= shade=3D"noshade" size=3D"1" color=3D"#cccccc">=0A=09<div style=3D"color:#4= 44;font:12px tahoma, geneva, helvetica, arial, sans-serif;">=0A=09=09<div s= tyle=3D"font-weight:bold;">If you reply to this email, your message will be= added to the discussion below:</div>=0A=09=09<a rel=3D"nofollow" target=3D= "_blank" href=3D"http://xen.1045712.n5.nabble.com/Patches-for-VGA-Passthrou= gh-XEN-4-2-unstable-tp4406265p4826655.html">http://xen.1045712.n5.nabble.co= m/Patches-for-VGA-Passthrough-XEN-4-2-unstable-tp4406265p4826655.html</a>= =0A=09</div>=0A=09<div style=3D"color:#666;font:11px tahoma, geneva, helvet= ica, arial, sans-serif;margin-top:.4em;">=0A=09=09=0A=09=09To unsubscribe f= rom Patches for VGA-Passthrough XEN 4.2 unstable, <a rel=3D"nofollow" targe= t=3D"_blank" href=3D"http://xen.1045712.n5.nabble.com/template/NamlServlet.= jtp?macro=3Dunsubscribe_by_code&node=3D4406265&code=3DZGF2aWR0ZWNoZ= XJAeWFob28uZnJ8NDQwNjI2NXwtMTQ3OTEzNDcyNw=3D=3D">click here</a>.=0A=09</div= ></div><br><br></div></div></div></body></html> --576309831-230176069-1316618006=:67296-- --===============0575994549== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel --===============0575994549==-- From xen-devel-bounces@lists.xensource.com Wed Sep 21 08:17:06 2011 Return-path: <xen-devel-bounces@lists.xensource.com> Envelope-to: www-data@lists.xensource.com Delivery-date: Wed, 21 Sep 2011 08:17:06 -0700 Received: from localhost ([127.0.0.1] helo=lists.colo.xensource.com) by lists.xensource.com with esmtp (Exim 4.43) id 1R6OXq-0004Ei-Ea; Wed, 21 Sep 2011 08:17:06 -0700 Received: from mail216.messagelabs.com ([85.158.143.99]) by lists.xensource.com with esmtp (Exim 4.43) id 1R6OUZ-00039o-LY for xen-devel@lists.xensource.com; Wed, 21 Sep 2011 08:13:44 -0700 X-Env-Sender: konrad@oracle.com X-Msg-Ref: server-10.tower-216.messagelabs.com!1316618019!11028368!1 X-Originating-IP: [148.87.113.117] X-StarScan-Version: 6.4.1; banners=-,-,- X-VirusChecked: Checked Received: (qmail 29309 invoked from network); 21 Sep 2011 15:13:40 -0000 Received: from rcsinet15.oracle.com (HELO rcsinet15.oracle.com) (148.87.113.117) by server-10.tower-216.messagelabs.com with DHE-RSA-AES256-SHA encrypted SMTP; 21 Sep 2011 15:13:40 -0000 Received: from rtcsinet22.oracle.com (rtcsinet22.oracle.com [66.248.204.30]) by rcsinet15.oracle.com (Switch-3.4.4/Switch-3.4.4) with ESMTP id p8LFDZj0018361 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Wed, 21 Sep 2011 15:13:36 GMT Received: from acsmt358.oracle.com (acsmt358.oracle.com [141.146.40.158]) by rtcsinet22.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id p8LF9CpA001144 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 21 Sep 2011 15:09:12 GMT Received: from abhmt107.oracle.com (abhmt107.oracle.com [141.146.116.59]) by acsmt358.oracle.com (8.12.11.20060308/8.12.11) with ESMTP id p8LF96ZI011345; Wed, 21 Sep 2011 10:09:06 -0500 Received: from oracle.com (/209.6.55.207) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Wed, 21 Sep 2011 08:09:06 -0700 Received: by oracle.com (Postfix, from userid 1000) id 778B71362; Wed, 21 Sep 2011 11:09:12 -0400 (EDT) Date: Wed, 21 Sep 2011 11:09:12 -0400 From: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com> To: David Vrabel <david.vrabel@citrix.com> Message-ID: <20110921150912.GF541@phenom.oracle.com> References: <1316089768-22461-1-git-send-email-david.vrabel@citrix.com> <1316089768-22461-2-git-send-email-david.vrabel@citrix.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <1316089768-22461-2-git-send-email-david.vrabel@citrix.com> User-Agent: Mutt/1.5.21 (2010-09-15) X-Source-IP: rtcsinet22.oracle.com [66.248.204.30] X-CT-RefId: str=0001.0A090206.4E79FF21.008E,ss=1,re=0.000,fgs=0 Cc: xen-devel@lists.xensource.com, Konrad Rzeszutek Wilk <konrad.wilk@oracle.com> Subject: [Xen-devel] Re: [PATCH 1/7] xen: use maximum reservation to limit amount of usable RAM X-BeenThere: xen-devel@lists.xensource.com X-Mailman-Version: 2.1.5 Precedence: list List-Id: Xen developer discussion <xen-devel.lists.xensource.com> List-Unsubscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe> List-Post: <mailto:xen-devel@lists.xensource.com> List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help> List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=subscribe> Sender: xen-devel-bounces@lists.xensource.com Errors-To: xen-devel-bounces@lists.xensource.com On Thu, Sep 15, 2011 at 01:29:22PM +0100, David Vrabel wrote: > From: David Vrabel <david.vrabel@citrix.com> > > Use the domain's maximum reservation to limit the amount of extra RAM > for the memory balloon. This reduces the size of the pages tables and > the amount of reserved low memory (which defaults to about 1/32 of the > total RAM). > > On a system with 8 GiB of RAM with the domain limited to 1 GiB the > kernel reports: > > Before: > > Memory: 627792k/4472000k available > > After: > > Memory: 549740k/11132224k available > > A increase of about 76 MiB (~1.5% of the unused 7 GiB). The reserved > low memory is also reduced from 253 MiB to 32 MiB. The total > additional usable RAM is 329 MiB. > > For dom0, this requires at patch to Xen ('x86: use 'dom0_mem' to limit > the number of pages for dom0')[1]. Not going to pick this one up as it already is in 3.1. > > [1] http://lists.xensource.com/archives/html/xen-devel/2011-08/msg00567.html > > Signed-off-by: David Vrabel <david.vrabel@citrix.com> > --- > arch/x86/xen/setup.c | 19 +++++++++++++++++++ > 1 files changed, 19 insertions(+), 0 deletions(-) > > diff --git a/arch/x86/xen/setup.c b/arch/x86/xen/setup.c > index df118a8..c3b8d44 100644 > --- a/arch/x86/xen/setup.c > +++ b/arch/x86/xen/setup.c > @@ -184,6 +184,19 @@ static unsigned long __init xen_set_identity(const struct e820entry *list, > PFN_UP(start_pci), PFN_DOWN(last)); > return identity; > } > + > +static unsigned long __init xen_get_max_pages(void) > +{ > + unsigned long max_pages = MAX_DOMAIN_PAGES; > + domid_t domid = DOMID_SELF; > + int ret; > + > + ret = HYPERVISOR_memory_op(XENMEM_maximum_reservation, &domid); > + if (ret > 0) > + max_pages = ret; > + return min(max_pages, MAX_DOMAIN_PAGES); > +} > + > /** > * machine_specific_memory_setup - Hook for machine specific memory setup. > **/ > @@ -292,6 +305,12 @@ char * __init xen_memory_setup(void) > > sanitize_e820_map(e820.map, ARRAY_SIZE(e820.map), &e820.nr_map); > > + extra_limit = xen_get_max_pages(); > + if (extra_limit >= max_pfn) > + extra_pages = extra_limit - max_pfn; > + else > + extra_pages = 0; > + > extra_pages += xen_return_unused_memory(xen_start_info->nr_pages, &e820); > > /* > -- > 1.7.2.5 _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel From xen-devel-bounces@lists.xensource.com Wed Sep 21 08:26:39 2011 Return-path: <xen-devel-bounces@lists.xensource.com> Envelope-to: www-data@lists.xensource.com Delivery-date: Wed, 21 Sep 2011 08:26:39 -0700 Received: from localhost ([127.0.0.1] helo=lists.colo.xensource.com) by lists.xensource.com with esmtp (Exim 4.43) id 1R6Oh5-0004jv-QN; Wed, 21 Sep 2011 08:26:39 -0700 Received: from mail27.messagelabs.com ([193.109.254.147]) by lists.xensource.com with esmtp (Exim 4.43) id 1R6OgL-0004Wv-9i for xen-devel@lists.xensource.com; Wed, 21 Sep 2011 08:25:54 -0700 X-Env-Sender: Ian.Campbell@eu.citrix.com X-Msg-Ref: server-12.tower-27.messagelabs.com!1316618734!43370160!1 X-Originating-IP: [62.200.22.115] X-StarScan-Version: 6.4.1; banners=-,-,- X-VirusChecked: Checked Received: (qmail 12227 invoked from network); 21 Sep 2011 15:25:35 -0000 Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115) by server-12.tower-27.messagelabs.com with RC4-SHA encrypted SMTP; 21 Sep 2011 15:25:35 -0000 X-IronPort-AV: E=Sophos;i="4.68,417,1312156800"; d="scan'208";a="7984575" Received: from lonpmailmx01.citrite.net ([10.30.203.162]) by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5; 21 Sep 2011 15:25:33 +0000 Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net (10.30.203.162) with Microsoft SMTP Server id 8.3.137.0; Wed, 21 Sep 2011 16:25:33 +0100 From: Ian Campbell <Ian.Campbell@eu.citrix.com> To: Daniel De Graaf <dgdegra@tycho.nsa.gov> Date: Wed, 21 Sep 2011 16:25:33 +0100 In-Reply-To: <4E79FC9A.6040609@tycho.nsa.gov> References: <1313764724-12683-1-git-send-email-dgdegra@tycho.nsa.gov> <1316472208-12104-1-git-send-email-dgdegra@tycho.nsa.gov> <1316472208-12104-2-git-send-email-dgdegra@tycho.nsa.gov> <1316599431.3891.147.camel@zakaz.uk.xensource.com> <4E79FC9A.6040609@tycho.nsa.gov> Organization: Citrix Systems, Inc. Content-Type: text/plain; charset="UTF-8" X-Mailer: Evolution 3.0.3- Content-Transfer-Encoding: 7bit Message-ID: <1316618733.3891.206.camel@zakaz.uk.xensource.com> MIME-Version: 1.0 Cc: Stefano Stabellini <Stefano.Stabellini@eu.citrix.com>, "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>, Ian Jackson <Ian.Jackson@eu.citrix.com>, "konrad.wilk@oracle.com" <konrad.wilk@oracle.com> Subject: [Xen-devel] Re: [PATCH 1/3] libxc: add xc_gnttab_map_grant_ref_notify X-BeenThere: xen-devel@lists.xensource.com X-Mailman-Version: 2.1.5 Precedence: list List-Id: Xen developer discussion <xen-devel.lists.xensource.com> List-Unsubscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe> List-Post: <mailto:xen-devel@lists.xensource.com> List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help> List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=subscribe> Sender: xen-devel-bounces@lists.xensource.com Errors-To: xen-devel-bounces@lists.xensource.com On Wed, 2011-09-21 at 16:02 +0100, Daniel De Graaf wrote: > On 09/21/2011 06:03 AM, Ian Campbell wrote: > > On Mon, 2011-09-19 at 23:43 +0100, Daniel De Graaf wrote: > >> @@ -116,4 +116,35 @@ struct ioctl_gntdev_set_max_grants { > >> uint32_t count; > >> }; > >> > >> +/* > >> + * Sets up an unmap notification within the page, so that the other side can do > >> + * cleanup if this side crashes. Required to implement cross-domain robust > >> + * mutexes or close notification on communication channels. > >> + * > >> + * Each mapped page only supports one notification; multiple calls referring to > >> + * the same page overwrite the previous notification. You must clear the > >> + * notification prior to the IOCTL_GNTALLOC_DEALLOC_GREF if you do not want it > >> + * to occur. > >> + */ > >> +#define IOCTL_GNTDEV_SET_UNMAP_NOTIFY \ > >> +_IOC(_IOC_NONE, 'G', 7, sizeof(struct ioctl_gntdev_unmap_notify)) > >> +struct ioctl_gntdev_unmap_notify { > >> + /* IN parameters */ > >> + /* Offset in the file descriptor for a byte within the page (same as > >> + * used in mmap). > > > > I'm probably being thick but I don't understand what this means, i.e. > > what this thing is relative to. > > This is an offset that acts like a byte offset in the /dev/xen/gntdev device. > Conceptually, if /dev/xen/evtchn implemented pwrite() then this offset would > be the offset you would pass to modify your target byte. > > For example, if you use gntdev to map two pages, the first will be at offset > 0 and the second at 4096; you would pass 4098 here to indicate the third byte > of the second page. The offsets (0, 4096) are returned by the map-grant ioctls. Hmm. I think I was confused because it was an offset into the file rather than, say, a virtual address. When I map a page how do I know what the offset of it is wrt the file descriptor? DO I just have to remember how many pages I mapped an *= 4096? > > >> If using UNMAP_NOTIFY_CLEAR_BYTE, this is the byte to > >> + * be cleared. Otherwise, it can be any byte in the page whose > >> + * notification we are adjusting. > >> + */ > >> + uint64_t index; > >> + /* Action(s) to take on unmap */ > >> + uint32_t action; > >> + /* Event channel to notify */ > >> + uint32_t event_channel_port; > > > > evtchn_port_t ? > > Using that would require an include dependency on event_channel.h which is > not exposed as a userspace-visible header. Linux's evtchn.h also does not > use evtchn_port_t (it uses unsigned int). > > Since this is just a direct copy of the header from the linux source tree, > any changes really need to happen there first. OK, that's fine as it is then. > > >> +}; > >> + > >> +/* Clear (set to zero) the byte specified by index */ > >> +#define UNMAP_NOTIFY_CLEAR_BYTE 0x1 > >> +/* Send an interrupt on the indicated event channel */ > >> +#define UNMAP_NOTIFY_SEND_EVENT 0x2 > >> + > >> #endif /* __LINUX_PUBLIC_GNTDEV_H__ */ > >> diff --git a/tools/libxc/xc_gnttab.c b/tools/libxc/xc_gnttab.c > >> index 4f55fce..3d3c63b 100644 > >> --- a/tools/libxc/xc_gnttab.c > >> +++ b/tools/libxc/xc_gnttab.c > >> @@ -18,6 +18,7 @@ > >> */ > >> > >> #include "xc_private.h" > >> +#include <errno.h> > >> > >> int xc_gnttab_op(xc_interface *xch, int cmd, void * op, int op_size, int count) > >> { > >> @@ -174,6 +175,28 @@ void *xc_gnttab_map_domain_grant_refs(xc_gnttab *xcg, > >> count, domid, refs, prot); > >> } > >> > >> +void *xc_gnttab_map_grant_ref_notify(xc_gnttab *xcg, > >> + uint32_t domid, > >> + uint32_t ref, > >> + uint32_t notify_offset, > >> + evtchn_port_t notify_port, > >> + int *notify_result) > >> +{ > >> + if (xcg->ops->u.gnttab.map_grant_ref_notify) > >> + return xcg->ops->u.gnttab.map_grant_ref_notify(xcg, xcg->ops_handle, > >> + domid, ref, notify_offset, notify_port, notify_result); > >> + else { > >> + void* area = xcg->ops->u.gnttab.map_grant_ref(xcg, xcg->ops_handle, > >> + domid, ref, PROT_READ|PROT_WRITE); > >> + if (area && notify_result) { > >> + *notify_result = -1; > >> + errno = ENOSYS; > >> + } > >> + return area; > >> + } > > > > I think the new public interface is fine but do we really need a new > > internal interface here? > > > > I think you can just add the notify_* arguments to the existing OSDEP > > function and have those OS backends which don't implement that feature > > return ENOSYS if notify_offset != 0 (or ~0 or whatever invalid value > > works). > > > > Why doesn't the *_notify variant take a prot argument? > > At least for the byte-clear portion of the notify, the page must be writable > or the notify will not work. I suppose an event channel alone could be used > for a read-only mapping, but normally the unmapping of a read-only mapping is > not an important event - although I guess you could contrive a use for this > type of notificaiton, so there's no reason not to allow it. If you combine this the two functions then returning EINVAL for attempts to map without PROT_WRITE (or whatever perm is necessary) would be reasonable IMHO. > > I'd be tempted to do away with notify_result too -- if the caller asked > > for notification and we fail to give that then we can cleanup and return > > an error. If they want to try again without the notification then that's > > up to them. > > The source of the error might be unclear, but this would make the interface > cleaner. > > > > >> +} > >> + > >> + > >> int xc_gnttab_munmap(xc_gnttab *xcg, > >> void *start_address, > >> uint32_t count) > >> diff --git a/tools/libxc/xc_linux_osdep.c b/tools/libxc/xc_linux_osdep.c > >> index dca6718..3040cb6 100644 > >> --- a/tools/libxc/xc_linux_osdep.c > >> +++ b/tools/libxc/xc_linux_osdep.c > >> @@ -613,6 +613,62 @@ static void *linux_gnttab_map_domain_grant_refs(xc_gnttab *xcg, xc_osdep_handle > >> return do_gnttab_map_grant_refs(xcg, h, count, &domid, 0, refs, prot); > >> } > >> > >> +static void *linux_gnttab_map_grant_ref_notify(xc_gnttab *xch, xc_osdep_handle h, > >> + uint32_t domid, uint32_t ref, > >> + uint32_t notify_offset, > >> + evtchn_port_t notify_port, > >> + int *notify_result) > >> +{ > >> + int fd = (int)h; > >> + int rv = 0; > >> + struct ioctl_gntdev_map_grant_ref map; > >> + struct ioctl_gntdev_unmap_notify notify; > >> + void *addr; > >> + > >> + map.count = 1; > >> + map.refs[0].domid = domid; > >> + map.refs[0].ref = ref; > >> + > >> + if ( ioctl(fd, IOCTL_GNTDEV_MAP_GRANT_REF, &map) ) { > >> + PERROR("xc_gnttab_map_grant_ref: ioctl MAP_GRANT_REF failed"); > >> + return NULL; > >> + } > >> + > >> + addr = mmap(NULL, XC_PAGE_SIZE, PROT_READ|PROT_WRITE, MAP_SHARED, fd, map.index); > >> + if ( addr == MAP_FAILED ) > >> + { > >> + int saved_errno = errno; > >> + struct ioctl_gntdev_unmap_grant_ref unmap_grant; > >> + > >> + PERROR("xc_gnttab_map_grant_ref: mmap failed"); > >> + unmap_grant.index = map.index; > >> + unmap_grant.count = 1; > >> + ioctl(fd, IOCTL_GNTDEV_UNMAP_GRANT_REF, &unmap_grant); > >> + errno = saved_errno; > >> + return NULL; > >> + } > > > > The non-notify variant handles EAGAIN, why doesn't this one need to do > > so? > > The non-notify variant doesn't need to handle EAGAIN anymore (with modern > kernels, at least... perhaps it should remain for older kernels). Also, > do_gnttab_map_grant_refs does not handle EAGAIN. OK I guess that is fine (although if you combine them as I suggest it comes back?) I hadn't noticed that we have both map_gratn_ref and map_grant_refs, that seems like an area which could be cleaned up. (not saying you should, just noticing it) > > >> + > >> + notify.index = map.index; > >> + notify.action = 0; > >> + if (notify_offset >= 0) { > >> + notify.index += notify_offset; > >> + notify.action |= UNMAP_NOTIFY_CLEAR_BYTE; > >> + } > >> + if (notify_port >= 0) { > >> + notify.event_channel_port = notify_port; > >> + notify.action |= UNMAP_NOTIFY_SEND_EVENT; > >> + } > >> + if (notify.action) > >> + rv = ioctl(fd, IOCTL_GNTDEV_SET_UNMAP_NOTIFY, ¬ify); > > > > Is there a race if the other end (or this process) dies between the MAP > > ioctl and here? > > > > Ian. > > > > Technically it's a race, but it doesn't impact any reasonable use of the > notification. The local process can't actually be using the shared page > at this point, and the other side will not be certain that the map has > actually succeeded until after the function returns (and it is notified > in some way - libvchan changes the notify byte from 2->1 at this point). > > If the domain whose memory we are mapping crashes, this ioctl will succeed > unless the event channel it refers to has already been invalidated - but > either way, the notifications are now irrelevant as there is nobody to > listen to them. OK. Thanks, Ian. > _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel From xen-devel-bounces@lists.xensource.com Wed Sep 21 08:35:22 2011 Return-path: <xen-devel-bounces@lists.xensource.com> Envelope-to: www-data@lists.xensource.com Delivery-date: Wed, 21 Sep 2011 08:35:22 -0700 Received: from localhost ([127.0.0.1] helo=lists.colo.xensource.com) by lists.xensource.com with esmtp (Exim 4.43) id 1R6OpW-0005dk-6c; Wed, 21 Sep 2011 08:35:22 -0700 Received: from mail27.messagelabs.com ([193.109.254.147]) by lists.xensource.com with smtp (Exim 4.43) id 1R6Oow-0005RA-81 for xen-devel@lists.xensource.com; Wed, 21 Sep 2011 08:34:46 -0700 X-Env-Sender: stefan.bader@canonical.com X-Msg-Ref: server-9.tower-27.messagelabs.com!1316619266!45469728!1 X-Originating-IP: [91.189.89.112] X-StarScan-Version: 6.4.1; banners=-,-,- X-VirusChecked: Checked Received: (qmail 877 invoked from network); 21 Sep 2011 15:34:26 -0000 Received: from youngberry.canonical.com (HELO youngberry.canonical.com) (91.189.89.112) by server-9.tower-27.messagelabs.com with SMTP; 21 Sep 2011 15:34:26 -0000 Received: from p5b2e3324.dip.t-dialin.net ([91.46.51.36] helo=[192.168.2.5]) by youngberry.canonical.com with esmtpsa (TLS1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.71) (envelope-from <stefan.bader@canonical.com>) id 1R6Oos-0008Ai-9y; Wed, 21 Sep 2011 15:34:42 +0000 Message-ID: <4E7A0410.7050405@canonical.com> Date: Wed, 21 Sep 2011 17:34:40 +0200 From: Stefan Bader <stefan.bader@canonical.com> User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.2.21) Gecko/20110831 Lightning/1.0b2 Thunderbird/3.1.13 MIME-Version: 1.0 To: Stefano Stabellini <stefano.stabellini@eu.citrix.com> Subject: Re: [Xen-devel] Re: Still struggling with HVM: tx timeouts on emulated nics References: <4E79E08D.1090503@canonical.com> <alpine.DEB.2.00.1109211422180.8700@kaball-desktop> In-Reply-To: <alpine.DEB.2.00.1109211422180.8700@kaball-desktop> X-Enigmail-Version: 1.1.2 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>, Stefano@rly59j.srv.mailcontrol.com X-BeenThere: xen-devel@lists.xensource.com X-Mailman-Version: 2.1.5 Precedence: list List-Id: Xen developer discussion <xen-devel.lists.xensource.com> List-Unsubscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe> List-Post: <mailto:xen-devel@lists.xensource.com> List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help> List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=subscribe> Sender: xen-devel-bounces@lists.xensource.com Errors-To: xen-devel-bounces@lists.xensource.com On 21.09.2011 15:31, Stefano Stabellini wrote: > On Wed, 21 Sep 2011, Stefan Bader wrote: >> This is on 3.0.4 based dom0 and domU with 4.1.1 hypervisor. I tried using the >> default 8139cp and ne2k_pci emulated nic. The 8139cp one at least comes up and >> gets configured via dhcp. And initial pings also get routed and done correctly. >> But slightly higher traffic (like checking for updates) hangs. And after a while >> there are messages about tx timeouts. >> The ne2k_pci type nic almost immediately has those issues and never comes up >> correctly. >> >> I am attaching the dmesg of the guest with apic=debug enabled. I am not sure how >> this should be but both nics get configured with level,low IRQs. Disk emulation >> seems to be ok but that seem to use IO-APIC-edge. And any other IRQs seem to be >> at least not level. > > Does the e1000 emulated card work correctly? Yes, that one seems to work ok. > What happens if you disable interrupt remapping (see patch below)? 8139cp seems to work correctly now (much higher irq stats as well) and e1000 still works. Both then using IOAPIC-fasteoi. > > > diff --git a/arch/x86/pci/xen.c b/arch/x86/pci/xen.c > index 1017c7b..472a58b 100644 > --- a/arch/x86/pci/xen.c > +++ b/arch/x86/pci/xen.c > @@ -354,8 +354,7 @@ int __init pci_xen_init(void) > > int __init pci_xen_hvm_init(void) > { > - if (!xen_feature(XENFEAT_hvm_pirqs)) > - return 0; > + return 0; > > #ifdef CONFIG_ACPI > /* > > >> Btw, what exactly is the difference between xen-pirq-ioapic and IO-APIC? > > xen-pirq-ioapic interrupts are interrupts that have been remapped onto > event channels Ah ok, thanks. > > >> Another problem came up recently though that may just be me doing the wrong >> thing. Normally I boot with xen_emul_unplug=unnecessary as I want the emulated >> devices. xen-blkfront is a module in my case and I thought I once had been able >> to use that by removing the unplug arg and making the blkfront driver load. But >> when I recently tried the module loaded but no disks appeared... Again, not sure >> I just forgot how to do that right or that was different when using a 4.1.0 >> hypervisor still... > > xen_emul_unplug=unnecessary allows the kernel to use PV interfaces on > older hypervisors that didn't support the unplug protocol and had other > ways to cope with multiple drivers accessing the same devices. > You can use xen_emul_unplug=never to prevent any unplug but you won't > get any PV interfaces. Hm, odd. Somehow I thought that I had been using pv interfaces that way when the interrupts for the emulated ide was broken. A bit suboptimal atm, because without any option and a kernel compiled with the platform pci and pv drivers (as modules) booting in HVM mode the kernel decides that having both is no use and unplugs the emulated devices. Which then leaves you with ... none. -Stefan > > _______________________________________________ > Xen-devel mailing list > Xen-devel@lists.xensource.com > http://lists.xensource.com/xen-devel _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel From xen-devel-bounces@lists.xensource.com Wed Sep 21 08:46:21 2011 Return-path: <xen-devel-bounces@lists.xensource.com> Envelope-to: www-data@lists.xensource.com Delivery-date: Wed, 21 Sep 2011 08:46:21 -0700 Received: from localhost ([127.0.0.1] helo=lists.colo.xensource.com) by lists.xensource.com with esmtp (Exim 4.43) id 1R6P09-00069M-41; Wed, 21 Sep 2011 08:46:21 -0700 Received: from mail27.messagelabs.com ([193.109.254.147]) by lists.xensource.com with esmtp (Exim 4.43) id 1R6Ozf-0005x0-Cn for xen-devel@lists.xensource.com; Wed, 21 Sep 2011 08:45:51 -0700 X-Env-Sender: Ian.Campbell@eu.citrix.com X-Msg-Ref: server-5.tower-27.messagelabs.com!1316619928!45819197!1 X-Originating-IP: [62.200.22.115] X-StarScan-Version: 6.4.1; banners=-,-,- X-VirusChecked: Checked Received: (qmail 19398 invoked from network); 21 Sep 2011 15:45:29 -0000 Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115) by server-5.tower-27.messagelabs.com with RC4-SHA encrypted SMTP; 21 Sep 2011 15:45:29 -0000 X-IronPort-AV: E=Sophos;i="4.68,417,1312156800"; d="scan'208";a="7985180" Received: from lonpmailmx01.citrite.net ([10.30.203.162]) by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5; 21 Sep 2011 15:44:56 +0000 Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net (10.30.203.162) with Microsoft SMTP Server id 8.3.137.0; Wed, 21 Sep 2011 16:44:56 +0100 Subject: Re: [Xen-devel] Re: [PATCH RESEND V8 5/7] libxl: Intruduce libxl__strndup. From: Ian Campbell <Ian.Campbell@eu.citrix.com> To: Christoph Egger <Christoph.Egger@amd.com> Date: Wed, 21 Sep 2011 16:44:56 +0100 In-Reply-To: <4E79EDD4.2030401@amd.com> References: <1316609997-26002-1-git-send-email-anthony.perard@citrix.com> <1316609997-26002-6-git-send-email-anthony.perard@citrix.com> <1316612104.3891.188.camel@zakaz.uk.xensource.com> <4E79EDD4.2030401@amd.com> Organization: Citrix Systems, Inc. Content-Type: text/plain; charset="UTF-8" X-Mailer: Evolution 3.0.3- Content-Transfer-Encoding: 7bit Message-ID: <1316619896.3891.219.camel@zakaz.uk.xensource.com> MIME-Version: 1.0 Cc: Anthony Perard <anthony.perard@citrix.com>, Xen Devel <xen-devel@lists.xensource.com>, Stefano Stabellini <Stefano.Stabellini@eu.citrix.com> X-BeenThere: xen-devel@lists.xensource.com X-Mailman-Version: 2.1.5 Precedence: list List-Id: Xen developer discussion <xen-devel.lists.xensource.com> List-Unsubscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe> List-Post: <mailto:xen-devel@lists.xensource.com> List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help> List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=subscribe> Sender: xen-devel-bounces@lists.xensource.com Errors-To: xen-devel-bounces@lists.xensource.com On Wed, 2011-09-21 at 14:59 +0100, Christoph Egger wrote: > On 09/21/11 15:35, Ian Campbell wrote: > > On Wed, 2011-09-21 at 13:59 +0100, Anthony PERARD wrote: > >> Signed-off-by: Anthony PERARD<anthony.perard@citrix.com> > > > > Acked-by: Ian Campbell<ian.campbell@citrix.com> > > > >> --- > >> tools/libxl/libxl_internal.c | 10 ++++++++++ > >> tools/libxl/libxl_internal.h | 1 + > >> 2 files changed, 11 insertions(+), 0 deletions(-) > >> > >> diff --git a/tools/libxl/libxl_internal.c b/tools/libxl/libxl_internal.c > >> index c4d54f9..0fb2315 100644 > >> --- a/tools/libxl/libxl_internal.c > >> +++ b/tools/libxl/libxl_internal.c > >> @@ -159,6 +159,16 @@ char *libxl__strdup(libxl__gc *gc, const char *c) > >> return s; > >> } > >> > >> +char *libxl__strndup(libxl__gc *gc, const char *c, size_t n) > >> +{ > >> + char *s = strndup(c, n); > >> + > >> + if (s) > >> + libxl__ptr_add(gc, s); > >> + > >> + return s; > >> +} > >> + > >> char *libxl__dirname(libxl__gc *gc, const char *s) > >> { > >> char *c; > >> diff --git a/tools/libxl/libxl_internal.h b/tools/libxl/libxl_internal.h > >> index 5d270bb..d873243 100644 > >> --- a/tools/libxl/libxl_internal.h > >> +++ b/tools/libxl/libxl_internal.h > >> @@ -148,6 +148,7 @@ _hidden void *libxl__calloc(libxl__gc *gc, size_t nmemb, size_t size); > >> _hidden void *libxl__realloc(libxl__gc *gc, void *ptr, size_t new_size); > >> _hidden char *libxl__sprintf(libxl__gc *gc, const char *fmt, ...) PRINTF_ATTRIBUTE(2, 3); > >> _hidden char *libxl__strdup(libxl__gc *gc, const char *c); > >> +_hidden char *libxl__strndup(libxl__gc *gc, const char *c, size_t n); > > Will libxl_strdup() go away ? Why should it? Both have their separate uses. > > Christoph > > >> _hidden char *libxl__dirname(libxl__gc *gc, const char *s); > >> > >> _hidden char **libxl__xs_kvs_of_flexarray(libxl__gc *gc, flexarray_t *array, int length); > > > > > > > > _______________________________________________ > > Xen-devel mailing list > > Xen-devel@lists.xensource.com > > http://lists.xensource.com/xen-devel > > > > _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel From xen-devel-bounces@lists.xensource.com Wed Sep 21 08:47:18 2011 Return-path: <xen-devel-bounces@lists.xensource.com> Envelope-to: www-data@lists.xensource.com Delivery-date: Wed, 21 Sep 2011 08:47:18 -0700 Received: from localhost ([127.0.0.1] helo=lists.colo.xensource.com) by lists.xensource.com with esmtp (Exim 4.43) id 1R6P14-0006Wa-9s; Wed, 21 Sep 2011 08:47:18 -0700 Received: from mail216.messagelabs.com ([85.158.143.99]) by lists.xensource.com with esmtp (Exim 4.43) id 1R6P0d-0006Jx-Jr for xen-devel@lists.xensource.com; Wed, 21 Sep 2011 08:46:52 -0700 X-Env-Sender: Ian.Campbell@eu.citrix.com X-Msg-Ref: server-15.tower-216.messagelabs.com!1316620006!18618564!1 X-Originating-IP: [62.200.22.115] X-StarScan-Version: 6.4.1; banners=-,-,- X-VirusChecked: Checked Received: (qmail 11026 invoked from network); 21 Sep 2011 15:46:47 -0000 Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115) by server-15.tower-216.messagelabs.com with RC4-SHA encrypted SMTP; 21 Sep 2011 15:46:47 -0000 X-IronPort-AV: E=Sophos;i="4.68,417,1312156800"; d="scan'208";a="7985254" Received: from lonpmailmx01.citrite.net ([10.30.203.162]) by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5; 21 Sep 2011 15:46:35 +0000 Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net (10.30.203.162) with Microsoft SMTP Server id 8.3.137.0; Wed, 21 Sep 2011 16:46:35 +0100 Subject: Re: [Xen-devel] Re: [PATCH RESEND V8 4/7] libxl: Introduce libxl__realloc. From: Ian Campbell <Ian.Campbell@eu.citrix.com> To: Christoph Egger <Christoph.Egger@amd.com> Date: Wed, 21 Sep 2011 16:46:35 +0100 In-Reply-To: <4E79ED94.1000308@amd.com> References: <1316609997-26002-1-git-send-email-anthony.perard@citrix.com> <1316609997-26002-5-git-send-email-anthony.perard@citrix.com> <1316612077.3891.187.camel@zakaz.uk.xensource.com> <4E79ED94.1000308@amd.com> Organization: Citrix Systems, Inc. Content-Type: text/plain; charset="UTF-8" X-Mailer: Evolution 3.0.3- Content-Transfer-Encoding: 7bit Message-ID: <1316619995.3891.221.camel@zakaz.uk.xensource.com> MIME-Version: 1.0 Cc: Anthony Perard <anthony.perard@citrix.com>, Xen Devel <xen-devel@lists.xensource.com>, Stefano Stabellini <Stefano.Stabellini@eu.citrix.com> X-BeenThere: xen-devel@lists.xensource.com X-Mailman-Version: 2.1.5 Precedence: list List-Id: Xen developer discussion <xen-devel.lists.xensource.com> List-Unsubscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe> List-Post: <mailto:xen-devel@lists.xensource.com> List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help> List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=subscribe> Sender: xen-devel-bounces@lists.xensource.com Errors-To: xen-devel-bounces@lists.xensource.com On Wed, 2011-09-21 at 14:58 +0100, Christoph Egger wrote: > On 09/21/11 15:34, Ian Campbell wrote: > > On Wed, 2011-09-21 at 13:59 +0100, Anthony PERARD wrote: > >> Signed-off-by: Anthony PERARD<anthony.perard@citrix.com> > > > > Acked-by: Ian Campbell<ian.campbell@citrix.com> > > > >> --- > >> tools/libxl/libxl_internal.c | 24 ++++++++++++++++++++++++ > >> tools/libxl/libxl_internal.h | 1 + > >> 2 files changed, 25 insertions(+), 0 deletions(-) > >> > >> diff --git a/tools/libxl/libxl_internal.c b/tools/libxl/libxl_internal.c > >> index e259278..c4d54f9 100644 > >> --- a/tools/libxl/libxl_internal.c > >> +++ b/tools/libxl/libxl_internal.c > >> @@ -102,6 +102,30 @@ void *libxl__calloc(libxl__gc *gc, size_t nmemb, size_t size) > >> return ptr; > >> } > >> > >> +void *libxl__realloc(libxl__gc *gc, void *ptr, size_t new_size) > >> +{ > >> + void *new_ptr = realloc(ptr, new_size); > >> + int i = 0; > >> + > >> + if (new_ptr == NULL&& new_size != 0) { > >> + return NULL; > >> + } > >> + > >> + if (ptr == NULL) { > >> + libxl__ptr_add(gc, new_ptr); > >> + } else if (new_ptr != ptr) { > >> + for (i = 0; i< gc->alloc_maxsize; i++) { > >> + if (gc->alloc_ptrs[i] == ptr) { > >> + gc->alloc_ptrs[i] = new_ptr; > >> + break; > >> + } > >> + } > >> + } > >> + > >> + > >> + return new_ptr; > >> +} > >> + > >> char *libxl__sprintf(libxl__gc *gc, const char *fmt, ...) > >> { > >> char *s; > >> diff --git a/tools/libxl/libxl_internal.h b/tools/libxl/libxl_internal.h > >> index 739e45e..5d270bb 100644 > >> --- a/tools/libxl/libxl_internal.h > >> +++ b/tools/libxl/libxl_internal.h > >> @@ -145,6 +145,7 @@ _hidden int libxl__ptr_add(libxl__gc *gc, void *ptr); > >> _hidden void libxl__free_all(libxl__gc *gc); > >> _hidden void *libxl__zalloc(libxl__gc *gc, int bytes); > >> _hidden void *libxl__calloc(libxl__gc *gc, size_t nmemb, size_t size); > > What is the difference between libxl__zalloc and libxl__calloc? The interface they provide? One of them is effectively a convenience version of the other. Surely you can look in the code and see this as easily as anyone else. > > >> +_hidden void *libxl__realloc(libxl__gc *gc, void *ptr, size_t new_size); > >> _hidden char *libxl__sprintf(libxl__gc *gc, const char *fmt, ...) PRINTF_ATTRIBUTE(2, 3); > >> _hidden char *libxl__strdup(libxl__gc *gc, const char *c); > >> _hidden char *libxl__dirname(libxl__gc *gc, const char *s); > > > > > > > > _______________________________________________ > > Xen-devel mailing list > > Xen-devel@lists.xensource.com > > http://lists.xensource.com/xen-devel > > > > _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel From xen-devel-bounces@lists.xensource.com Wed Sep 21 09:14:10 2011 Return-path: <xen-devel-bounces@lists.xensource.com> Envelope-to: www-data@lists.xensource.com Delivery-date: Wed, 21 Sep 2011 09:14:10 -0700 Received: from localhost ([127.0.0.1] helo=lists.colo.xensource.com) by lists.xensource.com with esmtp (Exim 4.43) id 1R6PR3-00011V-UX; Wed, 21 Sep 2011 09:14:09 -0700 Received: from mail174.messagelabs.com ([85.158.138.51]) by lists.xensource.com with esmtp (Exim 4.43) id 1R6PQa-0000nX-NR for xen-devel@lists.xensource.com; Wed, 21 Sep 2011 09:13:41 -0700 X-Env-Sender: Ian.Jackson@eu.citrix.com X-Msg-Ref: server-10.tower-174.messagelabs.com!1316621617!32249796!1 X-Originating-IP: [62.200.22.115] X-StarScan-Version: 6.4.1; banners=-,-,- X-VirusChecked: Checked Received: (qmail 15982 invoked from network); 21 Sep 2011 16:13:37 -0000 Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115) by server-10.tower-174.messagelabs.com with RC4-SHA encrypted SMTP; 21 Sep 2011 16:13:37 -0000 X-IronPort-AV: E=Sophos;i="4.68,417,1312156800"; d="scan'208";a="7985787" Received: from lonpmailmx01.citrite.net ([10.30.203.162]) by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5; 21 Sep 2011 16:13:37 +0000 Received: from norwich.cam.xci-test.com (10.80.248.129) by smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id 8.3.137.0; Wed, 21 Sep 2011 17:13:37 +0100 Received: from mariner.cam.xci-test.com ([10.80.2.22] helo=mariner.uk.xensource.com ident=Debian-exim) by norwich.cam.xci-test.com with esmtp (Exim 4.72) (envelope-from <Ian.Jackson@eu.citrix.com>) id 1R6PQW-0005MB-QH; Wed, 21 Sep 2011 16:13:36 +0000 Received: from iwj by mariner.uk.xensource.com with local (Exim 4.69) (envelope-from <Ian.Jackson@eu.citrix.com>) id 1R6PQV-0002tp-1b; Wed, 21 Sep 2011 17:13:36 +0100 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Message-ID: <20090.3375.40922.215499@mariner.uk.xensource.com> Date: Wed, 21 Sep 2011 17:13:35 +0100 To: Ian Campbell <Ian.Campbell@citrix.com>, Stefano Stabellini <stefano.stabellini@eu.citrix.com> Subject: Re: [Xen-devel] Re: xl vs. xm, possible bug in xl (fwd) [and 1 more messages] In-Reply-To: <alpine.DEB.2.00.1109091307080.12963@kaball-desktop>, <1315577875.3180.67.camel@cthulhu.hellion.org.uk> References: <j4ar95$8fi$1@dough.gmane.org> <20110908170755.GB16730@dumpdata.com> <j4bgsc$ka$1@dough.gmane.org> <alpine.DEB.2.00.1109091226250.12963@kaball-desktop> <4E69F80A.5060905@gmail.com> <alpine.DEB.2.00.1109091254590.12963@kaball-desktop> <4E6A09F2.4040405@gmail.com> <alpine.DEB.2.00.1109091353470.12963@kaball-desktop> <1315577875.3180.67.camel@cthulhu.hellion.org.uk> <alpine.DEB.2.00.1109091307080.12963@kaball-desktop> X-Mailer: VM 8.0.9 under Emacs 21.4.1 (i486-pc-linux-gnu) From: Ian Jackson <Ian.Jackson@eu.citrix.com> Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>, Keir Fraser <keir@xen.org>, Sven =?iso-8859-1?Q?K=F6hler?= <sven.koehler@gmail.com> X-BeenThere: xen-devel@lists.xensource.com X-Mailman-Version: 2.1.5 Precedence: list List-Id: Xen developer discussion <xen-devel.lists.xensource.com> List-Unsubscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe> List-Post: <mailto:xen-devel@lists.xensource.com> List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help> List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=subscribe> Sender: xen-devel-bounces@lists.xensource.com Errors-To: xen-devel-bounces@lists.xensource.com Stefano Stabellini writes ("Re: [Xen-devel] Re: xl vs. xm, possible bug in xl (fwd)"): > I think I have found the issue: if blktap2 is not enabled xl is going to > start qemu (to provide a disk backend) even if it is not actually needed > because the user wants to use blkback. > > We have a patch upstream to fix this issue but it hasn't been backported > to 4.1: Thanks, I have applied it to 4.1. Ian. _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel From xen-devel-bounces@lists.xensource.com Wed Sep 21 09:32:28 2011 Return-path: <xen-devel-bounces@lists.xensource.com> Envelope-to: www-data@lists.xensource.com Delivery-date: Wed, 21 Sep 2011 09:32:28 -0700 Received: from localhost ([127.0.0.1] helo=lists.colo.xensource.com) by lists.xensource.com with esmtp (Exim 4.43) id 1R6Pim-0001l4-GJ; Wed, 21 Sep 2011 09:32:28 -0700 Received: from mail27.messagelabs.com ([193.109.254.147]) by lists.xensource.com with smtp (Exim 4.43) id 1R6PiD-0001Wy-65 for xen-devel@lists.xensource.com; Wed, 21 Sep 2011 09:31:53 -0700 X-Env-Sender: dgdegra@tycho.nsa.gov X-Msg-Ref: server-15.tower-27.messagelabs.com!1316622700!49716739!1 X-Originating-IP: [63.239.65.39] X-StarScan-Version: 6.4.1; banners=-,-,- X-VirusChecked: Checked Received: (qmail 9906 invoked from network); 21 Sep 2011 16:31:41 -0000 Received: from msux-gh1-uea01.nsa.gov (HELO msux-gh1-uea01.nsa.gov) (63.239.65.39) by server-15.tower-27.messagelabs.com with SMTP; 21 Sep 2011 16:31:41 -0000 Received: from tarius.tycho.ncsc.mil (localhost [127.0.0.1]) by msux-gh1-uea01.nsa.gov (8.12.10/8.12.10) with ESMTP id p8LGVlfV027013; Wed, 21 Sep 2011 16:31:47 GMT Received: from moss-nexus.epoch.ncsc.mil (moss-nexus [144.51.25.48]) by tarius.tycho.ncsc.mil (8.13.1/8.13.1) with ESMTP id p8LGVlKr008398; Wed, 21 Sep 2011 12:31:47 -0400 Message-ID: <4E7A117C.4020903@tycho.nsa.gov> Date: Wed, 21 Sep 2011 12:31:56 -0400 From: Daniel De Graaf <dgdegra@tycho.nsa.gov> Organization: National Security Agency User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:6.0) Gecko/20110816 Thunderbird/6.0 MIME-Version: 1.0 To: Ian Campbell <Ian.Campbell@eu.citrix.com> References: <1313764724-12683-1-git-send-email-dgdegra@tycho.nsa.gov> <1316472208-12104-1-git-send-email-dgdegra@tycho.nsa.gov> <1316472208-12104-4-git-send-email-dgdegra@tycho.nsa.gov> <1316602422.3891.171.camel@zakaz.uk.xensource.com> In-Reply-To: <1316602422.3891.171.camel@zakaz.uk.xensource.com> X-Enigmail-Version: 1.3 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Cc: Stefano Stabellini <Stefano.Stabellini@eu.citrix.com>, "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>, Ian Jackson <Ian.Jackson@eu.citrix.com>, "konrad.wilk@oracle.com" <konrad.wilk@oracle.com> Subject: [Xen-devel] Re: [PATCH 3/3] libvchan: interdomain communications library X-BeenThere: xen-devel@lists.xensource.com X-Mailman-Version: 2.1.5 Precedence: list List-Id: Xen developer discussion <xen-devel.lists.xensource.com> List-Unsubscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe> List-Post: <mailto:xen-devel@lists.xensource.com> List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help> List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=subscribe> Sender: xen-devel-bounces@lists.xensource.com Errors-To: xen-devel-bounces@lists.xensource.com On 09/21/2011 06:53 AM, Ian Campbell wrote: > On Mon, 2011-09-19 at 23:43 +0100, Daniel De Graaf wrote: >> This library implements a bidirectional communication interface between >> applications in different domains, similar to unix sockets. Data can be >> sent using the byte-oriented libvchan_read/libvchan_write or the >> packet-oriented libvchan_recv/libvchan_send. >> >> Channel setup is done using a client-server model; domain IDs and a port >> number must be negotiated prior to initialization. The server allocates >> memory for the shared pages and determines the sizes of the >> communication rings (which may span multiple pages, although the default >> places rings and control within a single page). >> >> With properly sized rings, testing has shown that this interface >> provides speed comparable to pipes within a single Linux domain; it is >> significantly faster than network-based communication. >> >> Signed-off-by: Daniel De Graaf <dgdegra@tycho.nsa.gov> > > I only skimmed this one I had a few minor thoughts below but really I'm > pretty much OK for it to go in (modulo any fallout from comments on > patches 1+2). > > Definite Bonus Points for the doxygen/kernel doc commentary in the > headers, which tool parses them? (a few comments in the code itself seem > to have the "/**" marker but not the rest of the syntax). I think doxygen parses them, but I haven't personally run doxygen to verify that it works as expected. > You changed the library name to libxenvchan but not the path to the > source nor the API names? I suppose backwards compatability with the existing API has already been killed, so there's no reason not to change the names - it does make everything more consistent (and easier to grep for). >> +static int init_gnt_srv(struct libvchan *ctrl) >> +{ >> + int pages_left = ctrl->read.order >= PAGE_SHIFT ? 1 << (ctrl->read.order - PAGE_SHIFT) : 0; > > Here you do >= PAGE_SHIFT but on the out_unmap_left path you do > 11. > > (am I right that left == server and right == client in the libvhan > terminology?) > >From the public/io/libvchan.h header: * Standard consumer/producer interface, one pair per buffer * left is client write, server read * right is client read, server write So the client is on the left, if you assume the writer owns the buffer. >> + if (ctrl->read.order == 10) { >> + ctrl->read.buffer = ((void*)ctrl->ring) + 1024; >> + } else if (ctrl->read.order == 11) { >> + ctrl->read.buffer = ((void*)ctrl->ring) + 2048; >> + } else { >> + ctrl->read.buffer = xc_gntshr_share_pages(ctrl->gntshr, ctrl->other_domain_id, >> + pages_left, ctrl->ring->grants, 1); >> + if (!ctrl->read.buffer) >> + goto out_ring; >> + } > > switch (...read.order)? > > In other places you have MAX_LARGE_RING/MAX_SMALL_RING etc, I think > using SMALL/LARGE_RING_ORDER instead of 10 and 11 seems like a good > idea. > > Similarly using LARGE/SMALL_RING_OFFSET instead of 1024/2048 would help > clarity. > >> + if (ctrl->write.order < 10 || ctrl->write.order > 24) >> + goto out_unmap_ring; > > What is the significance of 2^24? > Actually, this should be 20 to match MAX_RING_SIZE in init.c; that number is derived from 1024 bytes of grant data. An order of 22 will always cause the list of grants to overrun the primary shared page; an order of 21 on both sides will also cause this, and can also cause the grant list to overlap the LARGE_RING area. From testing, the performance gain from larger rings begins to drop off before 2^20 (although this may depend on the size of your L2/L3 cache). Also, gntalloc is restricted to 1024 pages by default (this can be adjusted via sysfs or a module parameter). >> + >> +// find xenstore entry >> + snprintf(buf, sizeof buf, "/local/domain/%d/data/vchan/%s/%d/ring-ref", >> + ctrl->other_domain_id, domid_str, ctrl->device_number); > > I wonder if the base of this path (up to and including "%s/%d"?) ought > to be caller provided? My thinking is that the rendezvous between client > and server is out of band and the path is really an element (or even the > total encoding) of that OOB communication. > > It would also push the selection of xs location to be pushed up into the > application which also defines the protocol. For example I might want to > build a pv protocol with this library which is supported by the > toolstack and therefore want to put my stuff under devices etc or in any > other protocol specific xs location. The wart I previously mentioned wrt > using the "data" directory would then be an application wart (which I > think is ok) rather than baked into the libraries. > > Ian. > Allowing the caller to specify the xenstore path would make the interface more flexible, and also removes the arbitrary port numbers which already seem likely to collide. -- Daniel De Graaf National Security Agency _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel From xen-devel-bounces@lists.xensource.com Wed Sep 21 09:37:59 2011 Return-path: <xen-devel-bounces@lists.xensource.com> Envelope-to: www-data@lists.xensource.com Delivery-date: Wed, 21 Sep 2011 09:37:59 -0700 Received: from localhost ([127.0.0.1] helo=lists.colo.xensource.com) by lists.xensource.com with esmtp (Exim 4.43) id 1R6Po5-0002FF-FA; Wed, 21 Sep 2011 09:37:57 -0700 Received: from mail21.messagelabs.com ([85.158.143.35]) by lists.xensource.com with esmtp (Exim 4.43) id 1R6PnF-000229-Le for xen-devel@lists.xensource.com; Wed, 21 Sep 2011 09:37:06 -0700 X-Env-Sender: Ian.Jackson@eu.citrix.com X-Msg-Ref: server-10.tower-21.messagelabs.com!1316623007!54987517!1 X-Originating-IP: [62.200.22.115] X-StarScan-Version: 6.4.1; banners=-,-,- X-VirusChecked: Checked Received: (qmail 15876 invoked from network); 21 Sep 2011 16:36:48 -0000 Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115) by server-10.tower-21.messagelabs.com with RC4-SHA encrypted SMTP; 21 Sep 2011 16:36:48 -0000 X-IronPort-AV: E=Sophos;i="4.68,417,1312156800"; d="scan'208";a="7986205" Received: from lonpmailmx01.citrite.net ([10.30.203.162]) by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5; 21 Sep 2011 16:37:02 +0000 Received: from woking.xci-test.com (10.80.248.135) by smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id 8.3.137.0; Wed, 21 Sep 2011 17:37:02 +0100 Received: from osstest by woking.xci-test.com with local (Exim 4.69) (envelope-from <ian.jackson@eu.citrix.com>) id 1R6PnB-0004cL-J5; Wed, 21 Sep 2011 17:37:01 +0100 To: xen-devel@lists.xensource.com Message-ID: <osstest-8991-mainreport@xen.org> From: xen.org <ian.jackson@eu.citrix.com> Date: Wed, 21 Sep 2011 17:37:01 +0100 MIME-Version: 1.0 Content-Type: text/plain Cc: ian.jackson@eu.citrix.com Subject: [Xen-devel] [xen-unstable test] 8991: tolerable FAIL - PUSHED X-BeenThere: xen-devel@lists.xensource.com X-Mailman-Version: 2.1.5 Precedence: list List-Id: Xen developer discussion <xen-devel.lists.xensource.com> List-Unsubscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe> List-Post: <mailto:xen-devel@lists.xensource.com> List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help> List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=subscribe> Sender: xen-devel-bounces@lists.xensource.com Errors-To: xen-devel-bounces@lists.xensource.com flight 8991 xen-unstable real [real] http://www.chiark.greenend.org.uk/~xensrcts/logs/8991/ Failures :-/ but no regressions. Tests which did not succeed, but are not blocking, including regressions (tests previously passed) regarded as allowable: test-amd64-amd64-xl-pcipt-intel 1 xen-build-check(1) blocked n/a test-amd64-amd64-xl 1 xen-build-check(1) blocked n/a build-i386-pvops 4 kernel-build fail like 8990 test-amd64-i386-pair 1 xen-build-check(1) blocked n/a test-amd64-i386-xl-multivcpu 1 xen-build-check(1) blocked n/a test-amd64-i386-rhel6hvm-intel 1 xen-build-check(1) blocked n/a test-i386-i386-pv 1 xen-build-check(1) blocked n/a test-amd64-i386-pv 1 xen-build-check(1) blocked n/a test-amd64-amd64-pv 1 xen-build-check(1) blocked n/a test-i386-i386-xl 1 xen-build-check(1) blocked n/a build-amd64-pvops 4 kernel-build fail like 8990 test-amd64-i386-xl 1 xen-build-check(1) blocked n/a test-amd64-i386-xl-credit2 1 xen-build-check(1) blocked n/a test-amd64-i386-rhel6hvm-amd 1 xen-build-check(1) blocked n/a test-amd64-amd64-pair 1 xen-build-check(1) blocked n/a test-i386-i386-pair 1 xen-build-check(1) blocked n/a test-amd64-amd64-win 1 xen-build-check(1) blocked n/a test-amd64-amd64-xl-win 1 xen-build-check(1) blocked n/a test-amd64-i386-win 1 xen-build-check(1) blocked n/a test-i386-i386-win 1 xen-build-check(1) blocked n/a test-amd64-amd64-xl-sedf 1 xen-build-check(1) blocked n/a test-amd64-i386-win-vcpus1 1 xen-build-check(1) blocked n/a test-amd64-i386-xl-win-vcpus1 1 xen-build-check(1) blocked n/a test-i386-i386-xl-win 1 xen-build-check(1) blocked n/a version targeted for testing: xen a422e2a4451e baseline version: xen cd730c698299 ------------------------------------------------------------ People who touched revisions under test: Ian Jackson <ian.jackson@eu.citrix.com> Jan Beulich <jbeulich@suse.com> Keir Fraser <keir@xen.org> Olaf Hering <olaf@aepfle.de> ------------------------------------------------------------ jobs: build-amd64 pass build-i386 pass build-amd64-oldkern pass build-i386-oldkern pass build-amd64-pvops fail build-i386-pvops fail test-amd64-amd64-xl blocked test-amd64-i386-xl blocked test-i386-i386-xl blocked test-amd64-i386-rhel6hvm-amd blocked test-amd64-i386-xl-credit2 blocked test-amd64-amd64-xl-pcipt-intel blocked test-amd64-i386-rhel6hvm-intel blocked test-amd64-i386-xl-multivcpu blocked test-amd64-amd64-pair blocked test-amd64-i386-pair blocked test-i386-i386-pair blocked test-amd64-amd64-pv blocked test-amd64-i386-pv blocked test-i386-i386-pv blocked test-amd64-amd64-xl-sedf blocked test-amd64-i386-win-vcpus1 blocked test-amd64-i386-xl-win-vcpus1 blocked test-amd64-amd64-win blocked test-amd64-i386-win blocked test-i386-i386-win blocked test-amd64-amd64-xl-win blocked test-i386-i386-xl-win blocked ------------------------------------------------------------ sg-report-flight on woking.cam.xci-test.com logs: /home/xc_osstest/logs images: /home/xc_osstest/images Logs, config files, etc. are available at http://www.chiark.greenend.org.uk/~xensrcts/logs Test harness code can be found at http://xenbits.xensource.com/gitweb?p=osstest.git;a=summary Pushing revision : + branch=xen-unstable + revision=a422e2a4451e + . cri-lock-repos ++ . cri-common +++ umask 002 +++ getconfig Repos +++ perl -e ' use Osstest; readconfigonly(); print $c{Repos} or die $!; ' ++ repos=/export/home/osstest/repos ++ repos_lock=/export/home/osstest/repos/lock ++ '[' x '!=' x/export/home/osstest/repos/lock ']' ++ OSSTEST_REPOS_LOCK_LOCKED=/export/home/osstest/repos/lock ++ exec with-lock-ex -w /export/home/osstest/repos/lock ./ap-push xen-unstable a422e2a4451e + branch=xen-unstable + revision=a422e2a4451e + . cri-lock-repos ++ . cri-common +++ umask 002 +++ getconfig Repos +++ perl -e ' use Osstest; readconfigonly(); print $c{Repos} or die $!; ' ++ repos=/export/home/osstest/repos ++ repos_lock=/export/home/osstest/repos/lock ++ '[' x/export/home/osstest/repos/lock '!=' x/export/home/osstest/repos/lock ']' + : xen@xenbits.xensource.com + : xen@xenbits.xensource.com:git/linux-pvops + : master + : tested/2.6.39.x + case "$branch" in + cd /export/home/osstest/repos/xen-unstable.hg + hg push -r a422e2a4451e ssh://xen@xenbits.xensource.com/HG/xen-unstable.hg pushing to ssh://xen@xenbits.xensource.com/HG/xen-unstable.hg searching for changes remote: adding changesets remote: adding manifests remote: adding file changes remote: added 4 changesets with 44 changes to 19 files _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel From xen-devel-bounces@lists.xensource.com Wed Sep 21 09:39:38 2011 Return-path: <xen-devel-bounces@lists.xensource.com> Envelope-to: www-data@lists.xensource.com Delivery-date: Wed, 21 Sep 2011 09:39:38 -0700 Received: from localhost ([127.0.0.1] helo=lists.colo.xensource.com) by lists.xensource.com with esmtp (Exim 4.43) id 1R6Ppi-0002jB-Ei; Wed, 21 Sep 2011 09:39:38 -0700 Received: from mail216.messagelabs.com ([85.158.143.99]) by lists.xensource.com with esmtp (Exim 4.43) id 1R6PoM-0002Jx-VP for xen-devel@lists.xensource.com; Wed, 21 Sep 2011 09:38:15 -0700 X-Env-Sender: tim@xen.org X-Msg-Ref: server-13.tower-216.messagelabs.com!1316623091!19136004!1 X-Originating-IP: [81.29.64.94] X-StarScan-Version: 6.4.1; banners=-,-,- X-VirusChecked: Checked Received: (qmail 20631 invoked from network); 21 Sep 2011 16:38:12 -0000 Received: from ocelot.phlegethon.org (HELO mail.phlegethon.org) (81.29.64.94) by server-13.tower-216.messagelabs.com with DHE-RSA-AES256-SHA encrypted SMTP; 21 Sep 2011 16:38:12 -0000 Received: from tjd by mail.phlegethon.org with local (Exim 4.67 (FreeBSD)) (envelope-from <tim@xen.org>) id 1R6PoI-000GWd-2A; Wed, 21 Sep 2011 16:38:10 +0000 Date: Wed, 21 Sep 2011 17:38:10 +0100 From: Tim Deegan <tim@xen.org> To: AP <apxeng@gmail.com> Subject: Re: [Xen-devel] Testing nested virtualization on Intel CPUs Message-ID: <20110921163810.GA63448@ocelot.phlegethon.org> References: <CAGU+autjPnjevraC5vhX4RAMC2XrqkfKUN_ZuJz1r0r3078=0Q@mail.gmail.com> <20110920175712.GB35343@ocelot.phlegethon.org> <CAGU+autdJ0fXw2w4xmhe1Z7YZe_7H+XVr11k1-yjj9eyWMW1cA@mail.gmail.com> Mime-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline In-Reply-To: <CAGU+autdJ0fXw2w4xmhe1Z7YZe_7H+XVr11k1-yjj9eyWMW1cA@mail.gmail.com> User-Agent: Mutt/1.4.2.1i Cc: xen-devel@lists.xensource.com, Eddie Dong <eddie.dong@intel.com> X-BeenThere: xen-devel@lists.xensource.com X-Mailman-Version: 2.1.5 Precedence: list List-Id: Xen developer discussion <xen-devel.lists.xensource.com> List-Unsubscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe> List-Post: <mailto:xen-devel@lists.xensource.com> List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help> List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=subscribe> Sender: xen-devel-bounces@lists.xensource.com Errors-To: xen-devel-bounces@lists.xensource.com At 22:18 -0700 on 20 Sep (1316557136), AP wrote: > > Yes, booting Xen as a nested guest is very slow at startup, because of > > how Xen relocates the bottom 1MB at boot time. You might find that > > 32-bit Xen boots faster. > > Could please expand a little on why the relocation causes it to slow down? IIRC, the relocation itself is very slow because Xen just copies the low 1MB, which includes the VGA hole, so there are a lot of emulated reads. Tim. _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel From xen-devel-bounces@lists.xensource.com Wed Sep 21 09:53:30 2011 Return-path: <xen-devel-bounces@lists.xensource.com> Envelope-to: www-data@lists.xensource.com Delivery-date: Wed, 21 Sep 2011 09:53:30 -0700 Received: from localhost ([127.0.0.1] helo=lists.colo.xensource.com) by lists.xensource.com with esmtp (Exim 4.43) id 1R6Q38-0003mn-LG; Wed, 21 Sep 2011 09:53:30 -0700 Received: from mail216.messagelabs.com ([85.158.143.99]) by lists.xensource.com with esmtp (Exim 4.43) id 1R6Q2O-0003a0-Ro for xen-devel@lists.xensource.com; Wed, 21 Sep 2011 09:52:45 -0700 X-Env-Sender: alan@lxorguk.ukuu.org.uk X-Msg-Ref: server-5.tower-216.messagelabs.com!1316623927!18569300!1 X-Originating-IP: [81.2.110.250] X-StarScan-Version: 6.4.1; banners=-,-,- X-VirusChecked: Checked Received: (qmail 21395 invoked from network); 21 Sep 2011 16:52:38 -0000 Received: from earthlight.etchedpixels.co.uk (HELO www.etchedpixels.co.uk) (81.2.110.250) by server-5.tower-216.messagelabs.com with DHE-RSA-AES256-SHA encrypted SMTP; 21 Sep 2011 16:52:38 -0000 Received: from localhost.localdomain (localhost.localdomain [127.0.0.1]) by www.etchedpixels.co.uk (8.14.5/8.14.4) with ESMTP id p8LGoeBL029104; Wed, 21 Sep 2011 17:50:40 +0100 Date: Wed, 21 Sep 2011 17:50:39 +0100 From: Alan Cox <alan@lxorguk.ukuu.org.uk> To: Tim Deegan <tim@xen.org> Subject: Re: [Xen-devel] Testing nested virtualization on Intel CPUs Message-ID: <20110921175039.4ddcbb39@lxorguk.ukuu.org.uk> In-Reply-To: <20110921163810.GA63448@ocelot.phlegethon.org> References: <CAGU+autjPnjevraC5vhX4RAMC2XrqkfKUN_ZuJz1r0r3078=0Q@mail.gmail.com> <20110920175712.GB35343@ocelot.phlegethon.org> <CAGU+autdJ0fXw2w4xmhe1Z7YZe_7H+XVr11k1-yjj9eyWMW1cA@mail.gmail.com> <20110921163810.GA63448@ocelot.phlegethon.org> X-Mailer: Claws Mail 3.7.9 (GTK+ 2.24.4; x86_64-redhat-linux-gnu) Face: iVBORw0KGgoAAAANSUhEUgAAADAAAAAwBAMAAAClLOS0AAAAFVBMVEWysKsSBQMIAwIZCwj///8wIhxoRDXH9QHCAAABeUlEQVQ4jaXTvW7DIBAAYCQTzz2hdq+rdg494ZmBeE5KYHZjm/d/hJ6NfzBJpp5kRb5PHJwvMPMk2L9As5Y9AmYRBL+HAyJKeOU5aHRhsAAvORQ+UEgAvgddj/lwAXndw2laEDqA4x6KEBhjYRCg9tBFCOuJFxg2OKegbWjbsRTk8PPhKPD7HcRxB7cqhgBRp9Dcqs+B8v4CQvFdqeot3Kov6hBUn0AJitrzY+sgUuiA8i0r7+B3AfqKcN6t8M6HtqQ+AOoELCikgQSbgabKaJW3kn5lBs47JSGDhhLKDUh1UMipwwinMYPTBuIBjEclSaGZUk9hDlTb5sUTYN2SFFQuPe4Gox1X0FZOufjgBiV1Vls7b+GvK3SU4wfmcGo9rPPQzgIabfj4TYQo15k3bTHX9RIw/kniir5YbtJF4jkFG+dsDK1IgE413zAthU/vR2HVMmFUPIHTvF6jWCpFaGw/A3qWgnbxpSm9MSmY5b3pM1gvNc/gQfwBsGwF0VCtxZgAAAAASUVORK5CYII= Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Cc: Eddie Dong <eddie.dong@intel.com>, xen-devel@lists.xensource.com X-BeenThere: xen-devel@lists.xensource.com X-Mailman-Version: 2.1.5 Precedence: list List-Id: Xen developer discussion <xen-devel.lists.xensource.com> List-Unsubscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe> List-Post: <mailto:xen-devel@lists.xensource.com> List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help> List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=subscribe> Sender: xen-devel-bounces@lists.xensource.com Errors-To: xen-devel-bounces@lists.xensource.com On Wed, 21 Sep 2011 17:38:10 +0100 Tim Deegan <tim@xen.org> wrote: > At 22:18 -0700 on 20 Sep (1316557136), AP wrote: > > > Yes, booting Xen as a nested guest is very slow at startup, because of > > > how Xen relocates the bottom 1MB at boot time. You might find that > > > 32-bit Xen boots faster. > > > > Could please expand a little on why the relocation causes it to slow down? > > IIRC, the relocation itself is very slow because Xen just copies the low > 1MB, which includes the VGA hole, so there are a lot of emulated reads. That seems a bit odd - ISA space reads can have side effects. Alan _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel From xen-devel-bounces@lists.xensource.com Wed Sep 21 10:08:08 2011 Return-path: <xen-devel-bounces@lists.xensource.com> Envelope-to: www-data@lists.xensource.com Delivery-date: Wed, 21 Sep 2011 10:08:08 -0700 Received: from localhost ([127.0.0.1] helo=lists.colo.xensource.com) by lists.xensource.com with esmtp (Exim 4.43) id 1R6QHH-00052b-O2; Wed, 21 Sep 2011 10:08:08 -0700 Received: from mail216.messagelabs.com ([85.158.143.99]) by lists.xensource.com with smtp (Exim 4.43) id 1R6QGj-0004q4-V5 for xen-devel@lists.xensource.com; Wed, 21 Sep 2011 10:07:37 -0700 X-Env-Sender: dgdegra@tycho.nsa.gov X-Msg-Ref: server-3.tower-216.messagelabs.com!1316624850!18097449!1 X-Originating-IP: [63.239.65.40] X-StarScan-Version: 6.4.1; banners=-,-,- X-VirusChecked: Checked Received: (qmail 13857 invoked from network); 21 Sep 2011 17:07:30 -0000 Received: from msux-gh1-uea02.nsa.gov (HELO msux-gh1-uea02.nsa.gov) (63.239.65.40) by server-3.tower-216.messagelabs.com with SMTP; 21 Sep 2011 17:07:30 -0000 Received: from tarius.tycho.ncsc.mil (localhost [127.0.0.1]) by msux-gh1-uea02.nsa.gov (8.12.10/8.12.10) with ESMTP id p8LH7RiF015557; Wed, 21 Sep 2011 17:07:28 GMT Received: from moss-nexus.epoch.ncsc.mil (moss-nexus [144.51.25.48]) by tarius.tycho.ncsc.mil (8.13.1/8.13.1) with ESMTP id p8LH7P01010821; Wed, 21 Sep 2011 13:07:25 -0400 Message-ID: <4E7A19D6.6090805@tycho.nsa.gov> Date: Wed, 21 Sep 2011 13:07:34 -0400 From: Daniel De Graaf <dgdegra@tycho.nsa.gov> Organization: National Security Agency User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:6.0) Gecko/20110816 Thunderbird/6.0 MIME-Version: 1.0 To: Ian Campbell <Ian.Campbell@eu.citrix.com> References: <1313764724-12683-1-git-send-email-dgdegra@tycho.nsa.gov> <1316472208-12104-1-git-send-email-dgdegra@tycho.nsa.gov> <1316472208-12104-2-git-send-email-dgdegra@tycho.nsa.gov> <1316599431.3891.147.camel@zakaz.uk.xensource.com> <4E79FC9A.6040609@tycho.nsa.gov> <1316618733.3891.206.camel@zakaz.uk.xensource.com> In-Reply-To: <1316618733.3891.206.camel@zakaz.uk.xensource.com> X-Enigmail-Version: 1.3 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Cc: Stefano Stabellini <Stefano.Stabellini@eu.citrix.com>, "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>, Ian Jackson <Ian.Jackson@eu.citrix.com>, "konrad.wilk@oracle.com" <konrad.wilk@oracle.com> Subject: [Xen-devel] Re: [PATCH 1/3] libxc: add xc_gnttab_map_grant_ref_notify X-BeenThere: xen-devel@lists.xensource.com X-Mailman-Version: 2.1.5 Precedence: list List-Id: Xen developer discussion <xen-devel.lists.xensource.com> List-Unsubscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe> List-Post: <mailto:xen-devel@lists.xensource.com> List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help> List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=subscribe> Sender: xen-devel-bounces@lists.xensource.com Errors-To: xen-devel-bounces@lists.xensource.com On 09/21/2011 11:25 AM, Ian Campbell wrote: > On Wed, 2011-09-21 at 16:02 +0100, Daniel De Graaf wrote: >> On 09/21/2011 06:03 AM, Ian Campbell wrote: >>> On Mon, 2011-09-19 at 23:43 +0100, Daniel De Graaf wrote: >>>> @@ -116,4 +116,35 @@ struct ioctl_gntdev_set_max_grants { >>>> uint32_t count; >>>> }; >>>> >>>> +/* >>>> + * Sets up an unmap notification within the page, so that the other side can do >>>> + * cleanup if this side crashes. Required to implement cross-domain robust >>>> + * mutexes or close notification on communication channels. >>>> + * >>>> + * Each mapped page only supports one notification; multiple calls referring to >>>> + * the same page overwrite the previous notification. You must clear the >>>> + * notification prior to the IOCTL_GNTALLOC_DEALLOC_GREF if you do not want it >>>> + * to occur. >>>> + */ >>>> +#define IOCTL_GNTDEV_SET_UNMAP_NOTIFY \ >>>> +_IOC(_IOC_NONE, 'G', 7, sizeof(struct ioctl_gntdev_unmap_notify)) >>>> +struct ioctl_gntdev_unmap_notify { >>>> + /* IN parameters */ >>>> + /* Offset in the file descriptor for a byte within the page (same as >>>> + * used in mmap). >>> >>> I'm probably being thick but I don't understand what this means, i.e. >>> what this thing is relative to. >> >> This is an offset that acts like a byte offset in the /dev/xen/gntdev device. >> Conceptually, if /dev/xen/evtchn implemented pwrite() then this offset would >> be the offset you would pass to modify your target byte. >> >> For example, if you use gntdev to map two pages, the first will be at offset >> 0 and the second at 4096; you would pass 4098 here to indicate the third byte >> of the second page. The offsets (0, 4096) are returned by the map-grant ioctls. > > Hmm. I think I was confused because it was an offset into the file > rather than, say, a virtual address. > > When I map a page how do I know what the offset of it is wrt the file > descriptor? DO I just have to remember how many pages I mapped an *= > 4096? You had the offset at the time you mapped it, because that's what you passed in the offset parameter to mmap(). Just don't lose the number :) The xen interfaces do forget the number: for gntdev, they recover it via IOCTL_GNTDEV_GET_OFFSET_FOR_VADDR and for gntalloc, it is not needed because the pages are unhooked as part of the map process so the offset is no longer valid. This technique is now possible for gntdev, but older kernels will fail the unmap ioctl and may crash if you close anyway. >> >>>> If using UNMAP_NOTIFY_CLEAR_BYTE, this is the byte to >>>> + * be cleared. Otherwise, it can be any byte in the page whose >>>> + * notification we are adjusting. >>>> + */ >>>> + uint64_t index; >>>> + /* Action(s) to take on unmap */ >>>> + uint32_t action; >>>> + /* Event channel to notify */ >>>> + uint32_t event_channel_port; >>> >>> evtchn_port_t ? >> >> Using that would require an include dependency on event_channel.h which is >> not exposed as a userspace-visible header. Linux's evtchn.h also does not >> use evtchn_port_t (it uses unsigned int). >> >> Since this is just a direct copy of the header from the linux source tree, >> any changes really need to happen there first. > > OK, that's fine as it is then. > >> >>>> +}; >>>> + >>>> +/* Clear (set to zero) the byte specified by index */ >>>> +#define UNMAP_NOTIFY_CLEAR_BYTE 0x1 >>>> +/* Send an interrupt on the indicated event channel */ >>>> +#define UNMAP_NOTIFY_SEND_EVENT 0x2 >>>> + >>>> #endif /* __LINUX_PUBLIC_GNTDEV_H__ */ >>>> diff --git a/tools/libxc/xc_gnttab.c b/tools/libxc/xc_gnttab.c >>>> index 4f55fce..3d3c63b 100644 >>>> --- a/tools/libxc/xc_gnttab.c >>>> +++ b/tools/libxc/xc_gnttab.c >>>> @@ -18,6 +18,7 @@ >>>> */ >>>> >>>> #include "xc_private.h" >>>> +#include <errno.h> >>>> >>>> int xc_gnttab_op(xc_interface *xch, int cmd, void * op, int op_size, int count) >>>> { >>>> @@ -174,6 +175,28 @@ void *xc_gnttab_map_domain_grant_refs(xc_gnttab *xcg, >>>> count, domid, refs, prot); >>>> } >>>> >>>> +void *xc_gnttab_map_grant_ref_notify(xc_gnttab *xcg, >>>> + uint32_t domid, >>>> + uint32_t ref, >>>> + uint32_t notify_offset, >>>> + evtchn_port_t notify_port, >>>> + int *notify_result) >>>> +{ >>>> + if (xcg->ops->u.gnttab.map_grant_ref_notify) >>>> + return xcg->ops->u.gnttab.map_grant_ref_notify(xcg, xcg->ops_handle, >>>> + domid, ref, notify_offset, notify_port, notify_result); >>>> + else { >>>> + void* area = xcg->ops->u.gnttab.map_grant_ref(xcg, xcg->ops_handle, >>>> + domid, ref, PROT_READ|PROT_WRITE); >>>> + if (area && notify_result) { >>>> + *notify_result = -1; >>>> + errno = ENOSYS; >>>> + } >>>> + return area; >>>> + } >>> >>> I think the new public interface is fine but do we really need a new >>> internal interface here? >>> >>> I think you can just add the notify_* arguments to the existing OSDEP >>> function and have those OS backends which don't implement that feature >>> return ENOSYS if notify_offset != 0 (or ~0 or whatever invalid value >>> works). >>> >>> Why doesn't the *_notify variant take a prot argument? >> >> At least for the byte-clear portion of the notify, the page must be writable >> or the notify will not work. I suppose an event channel alone could be used >> for a read-only mapping, but normally the unmapping of a read-only mapping is >> not an important event - although I guess you could contrive a use for this >> type of notificaiton, so there's no reason not to allow it. > > If you combine this the two functions then returning EINVAL for attempts > to map without PROT_WRITE (or whatever perm is necessary) would be > reasonable IMHO. > The ioctl already prevents you from requesting the impossible, so this should just work. >>> I'd be tempted to do away with notify_result too -- if the caller asked >>> for notification and we fail to give that then we can cleanup and return >>> an error. If they want to try again without the notification then that's >>> up to them. >> >> The source of the error might be unclear, but this would make the interface >> cleaner. >> >>> >>>> +} >>>> + >>>> + >>>> int xc_gnttab_munmap(xc_gnttab *xcg, >>>> void *start_address, >>>> uint32_t count) >>>> diff --git a/tools/libxc/xc_linux_osdep.c b/tools/libxc/xc_linux_osdep.c >>>> index dca6718..3040cb6 100644 >>>> --- a/tools/libxc/xc_linux_osdep.c >>>> +++ b/tools/libxc/xc_linux_osdep.c >>>> @@ -613,6 +613,62 @@ static void *linux_gnttab_map_domain_grant_refs(xc_gnttab *xcg, xc_osdep_handle >>>> return do_gnttab_map_grant_refs(xcg, h, count, &domid, 0, refs, prot); >>>> } >>>> >>>> +static void *linux_gnttab_map_grant_ref_notify(xc_gnttab *xch, xc_osdep_handle h, >>>> + uint32_t domid, uint32_t ref, >>>> + uint32_t notify_offset, >>>> + evtchn_port_t notify_port, >>>> + int *notify_result) >>>> +{ >>>> + int fd = (int)h; >>>> + int rv = 0; >>>> + struct ioctl_gntdev_map_grant_ref map; >>>> + struct ioctl_gntdev_unmap_notify notify; >>>> + void *addr; >>>> + >>>> + map.count = 1; >>>> + map.refs[0].domid = domid; >>>> + map.refs[0].ref = ref; >>>> + >>>> + if ( ioctl(fd, IOCTL_GNTDEV_MAP_GRANT_REF, &map) ) { >>>> + PERROR("xc_gnttab_map_grant_ref: ioctl MAP_GRANT_REF failed"); >>>> + return NULL; >>>> + } >>>> + >>>> + addr = mmap(NULL, XC_PAGE_SIZE, PROT_READ|PROT_WRITE, MAP_SHARED, fd, map.index); >>>> + if ( addr == MAP_FAILED ) >>>> + { >>>> + int saved_errno = errno; >>>> + struct ioctl_gntdev_unmap_grant_ref unmap_grant; >>>> + >>>> + PERROR("xc_gnttab_map_grant_ref: mmap failed"); >>>> + unmap_grant.index = map.index; >>>> + unmap_grant.count = 1; >>>> + ioctl(fd, IOCTL_GNTDEV_UNMAP_GRANT_REF, &unmap_grant); >>>> + errno = saved_errno; >>>> + return NULL; >>>> + } >>> >>> The non-notify variant handles EAGAIN, why doesn't this one need to do >>> so? >> >> The non-notify variant doesn't need to handle EAGAIN anymore (with modern >> kernels, at least... perhaps it should remain for older kernels). Also, >> do_gnttab_map_grant_refs does not handle EAGAIN. > > OK I guess that is fine (although if you combine them as I suggest it > comes back?) > > I hadn't noticed that we have both map_gratn_ref and map_grant_refs, > that seems like an area which could be cleaned up. (not saying you > should, just noticing it) Since I'm already rewriting the osdep layer functions, I think I can replace all 3-4 existing map functions with a single function. It looks like the current 2.6.32.x xen kernels also aren't returning EAGAIN, so I'm unsure as to why this support was added. The commit in question is 20689:fe42b16855aa by Grzegorz Milos (committed by Keir Fraser), but I don't see any discussion on xen-devel for it. It's also unclear why repeating the request every millisecond in an infinite loop is better than letting the caller handle an -EAGAIN. >> >>>> + >>>> + notify.index = map.index; >>>> + notify.action = 0; >>>> + if (notify_offset >= 0) { >>>> + notify.index += notify_offset; >>>> + notify.action |= UNMAP_NOTIFY_CLEAR_BYTE; >>>> + } >>>> + if (notify_port >= 0) { >>>> + notify.event_channel_port = notify_port; >>>> + notify.action |= UNMAP_NOTIFY_SEND_EVENT; >>>> + } >>>> + if (notify.action) >>>> + rv = ioctl(fd, IOCTL_GNTDEV_SET_UNMAP_NOTIFY, ¬ify); >>> >>> Is there a race if the other end (or this process) dies between the MAP >>> ioctl and here? >>> >>> Ian. >>> >> >> Technically it's a race, but it doesn't impact any reasonable use of the >> notification. The local process can't actually be using the shared page >> at this point, and the other side will not be certain that the map has >> actually succeeded until after the function returns (and it is notified >> in some way - libvchan changes the notify byte from 2->1 at this point). >> >> If the domain whose memory we are mapping crashes, this ioctl will succeed >> unless the event channel it refers to has already been invalidated - but >> either way, the notifications are now irrelevant as there is nobody to >> listen to them. > > OK. > > Thanks, > Ian. > >> > > > -- Daniel De Graaf National Security Agency _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel From xen-devel-bounces@lists.xensource.com Wed Sep 21 10:11:37 2011 Return-path: <xen-devel-bounces@lists.xensource.com> Envelope-to: www-data@lists.xensource.com Delivery-date: Wed, 21 Sep 2011 10:11:37 -0700 Received: from localhost ([127.0.0.1] helo=lists.colo.xensource.com) by lists.xensource.com with esmtp (Exim 4.43) id 1R6QKe-0005eU-Sf; Wed, 21 Sep 2011 10:11:36 -0700 Received: from mail174.messagelabs.com ([85.158.138.51]) by lists.xensource.com with esmtp (Exim 4.43) id 1R6QKG-0005RK-7W for xen-devel@lists.xensource.com; Wed, 21 Sep 2011 10:11:12 -0700 X-Env-Sender: konrad@oracle.com X-Msg-Ref: server-6.tower-174.messagelabs.com!1316625067!30122436!1 X-Originating-IP: [148.87.113.117] X-StarScan-Version: 6.4.1; banners=-,-,- X-VirusChecked: Checked Received: (qmail 31709 invoked from network); 21 Sep 2011 17:11:08 -0000 Received: from rcsinet15.oracle.com (HELO rcsinet15.oracle.com) (148.87.113.117) by server-6.tower-174.messagelabs.com with DHE-RSA-AES256-SHA encrypted SMTP; 21 Sep 2011 17:11:08 -0000 Received: from rtcsinet22.oracle.com (rtcsinet22.oracle.com [66.248.204.30]) by rcsinet15.oracle.com (Switch-3.4.4/Switch-3.4.4) with ESMTP id p8LHB3s4013211 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Wed, 21 Sep 2011 17:11:05 GMT Received: from acsmt356.oracle.com (acsmt356.oracle.com [141.146.40.156]) by rtcsinet22.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id p8LHB2qp014025 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 21 Sep 2011 17:11:03 GMT Received: from abhmt113.oracle.com (abhmt113.oracle.com [141.146.116.65]) by acsmt356.oracle.com (8.12.11.20060308/8.12.11) with ESMTP id p8LHAvoR016224; Wed, 21 Sep 2011 12:10:57 -0500 Received: from oracle.com (/209.6.55.207) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Wed, 21 Sep 2011 10:10:57 -0700 Received: by oracle.com (Postfix, from userid 1000) id 7F52E1362; Wed, 21 Sep 2011 13:11:03 -0400 (EDT) Date: Wed, 21 Sep 2011 13:11:03 -0400 From: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com> To: David Vrabel <david.vrabel@citrix.com> Message-ID: <20110921171103.GA2768@phenom.oracle.com> References: <1316089768-22461-1-git-send-email-david.vrabel@citrix.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <1316089768-22461-1-git-send-email-david.vrabel@citrix.com> User-Agent: Mutt/1.5.21 (2010-09-15) X-Source-IP: rtcsinet22.oracle.com [66.248.204.30] X-CT-RefId: str=0001.0A090209.4E7A1AAA.0008,ss=1,re=0.000,fgs=0 Cc: xen-devel@lists.xensource.com Subject: [Xen-devel] Re: xen: memory initialization/balloon fixes (#3) X-BeenThere: xen-devel@lists.xensource.com X-Mailman-Version: 2.1.5 Precedence: list List-Id: Xen developer discussion <xen-devel.lists.xensource.com> List-Unsubscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe> List-Post: <mailto:xen-devel@lists.xensource.com> List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help> List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=subscribe> Sender: xen-devel-bounces@lists.xensource.com Errors-To: xen-devel-bounces@lists.xensource.com On Thu, Sep 15, 2011 at 01:29:21PM +0100, David Vrabel wrote: > This set of patches fixes some bugs in the memory initialization under > Xen and in Xen's memory balloon driver. They can make 100s of MB of > additional RAM available (depending on the system/configuration). > > Patch 1 is already applied. > > Patch 2 fixes a bug in patch 1 and should be queued for 3.1 (and along > with patch 1 considered for 3.0 stable). > > Patch 3 is a bug fix and should be queued for 3.1 and possibly > queued for the 3.0 stable tree. > > Patches 5 & 6 increase the amount of low memory in 32 bit domains > started with < 1 GiB of RAM. Please queue for 3.2 I've queued them up and going to test them this week to make sure there are no regressions. > > Patch 7 releases all pages in the initial allocation with PFNs that > lie within a 1-1 mapping. This seems correct to me as I think that The only thing I remember about this was with dmidecode doing something fishy.. (As in, it wouldn't work when the pages under 1MB were released) (But I can't remember the details about it, so I might be completly wrong). Could you please test that as well? > once the 1-1 mapping is set the MFN of the original page is lost so > it's no longer accessible by the kernel (and it cannot be used by > another domain > > Changes since #2: > > - New patch: xen: avoid adding non-existant memory if the reservation > is unlimited > - Avoid using a hypercall to get the current number of pages in the > ballon driver. Apparently the hypercall won't return the right > value if paging is used. > - Addresses Konrad's review comments. > > David _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel From xen-devel-bounces@lists.xensource.com Wed Sep 21 10:23:52 2011 Return-path: <xen-devel-bounces@lists.xensource.com> Envelope-to: www-data@lists.xensource.com Delivery-date: Wed, 21 Sep 2011 10:23:52 -0700 Received: from localhost ([127.0.0.1] helo=lists.colo.xensource.com) by lists.xensource.com with esmtp (Exim 4.43) id 1R6QWV-0006Uk-Sq; Wed, 21 Sep 2011 10:23:51 -0700 Received: from mail216.messagelabs.com ([85.158.143.99]) by lists.xensource.com with esmtp (Exim 4.43) id 1R6QW6-0006Hc-LS for xen-devel@lists.xensource.com; Wed, 21 Sep 2011 10:23:26 -0700 X-Env-Sender: keir.xen@gmail.com X-Msg-Ref: server-2.tower-216.messagelabs.com!1316625802!18691724!1 X-Originating-IP: [209.85.213.43] X-StarScan-Version: 6.4.1; banners=-,-,- X-VirusChecked: Checked Received: (qmail 15029 invoked from network); 21 Sep 2011 17:23:23 -0000 Received: from mail-yw0-f43.google.com (HELO mail-yw0-f43.google.com) (209.85.213.43) by server-2.tower-216.messagelabs.com with RC4-SHA encrypted SMTP; 21 Sep 2011 17:23:23 -0000 Received: by ywm21 with SMTP id 21so2026994ywm.30 for <xen-devel@lists.xensource.com>; Wed, 21 Sep 2011 10:23:22 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=user-agent:date:subject:from:to:cc:message-id:thread-topic :thread-index:in-reply-to:mime-version:content-type :content-transfer-encoding; bh=2v25S6mDxNM8g6ZczWX639bIOAzvPZ4n+B1KubCDjgE=; b=fsFDub2ER0zpPKMWVPymL7BTj1tXe1tKHhOCHfG8l8yM66D/5GFPYzAu2AyfYwfGNS 7Lwde+8SGwqucVglpheMpEmr5Olk3N5NrcG9ei3y8MC4c4NdMZ9UOMP0xlOCgPGToMFy 0ZLqpfAgwS+xMbQ5IlPcOh7pQdoerz8dZSuWk= Received: by 10.151.157.10 with SMTP id j10mr1363662ybo.68.1316625802314; Wed, 21 Sep 2011 10:23:22 -0700 (PDT) Received: from [192.168.0.189] ([142.103.56.220]) by mx.google.com with ESMTPS id i28sm22889326anm.11.2011.09.21.10.23.20 (version=SSLv3 cipher=OTHER); Wed, 21 Sep 2011 10:23:21 -0700 (PDT) User-Agent: Microsoft-Entourage/12.30.0.110427 Date: Wed, 21 Sep 2011 10:23:16 -0700 Subject: Re: [Xen-devel] Testing nested virtualization on Intel CPUs From: Keir Fraser <keir.xen@gmail.com> To: Alan Cox <alan@lxorguk.ukuu.org.uk>, Tim Deegan <tim@xen.org> Message-ID: <CA9F6B94.21419%keir.xen@gmail.com> Thread-Topic: [Xen-devel] Testing nested virtualization on Intel CPUs Thread-Index: Acx4gyX4ZpgK8pgio0y0PVqvYK6BSA== In-Reply-To: <20110921175039.4ddcbb39@lxorguk.ukuu.org.uk> Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit Cc: xen-devel@lists.xensource.com, Eddie Dong <eddie.dong@intel.com> X-BeenThere: xen-devel@lists.xensource.com X-Mailman-Version: 2.1.5 Precedence: list List-Id: Xen developer discussion <xen-devel.lists.xensource.com> List-Unsubscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe> List-Post: <mailto:xen-devel@lists.xensource.com> List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help> List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=subscribe> Sender: xen-devel-bounces@lists.xensource.com Errors-To: xen-devel-bounces@lists.xensource.com On 21/09/2011 09:50, "Alan Cox" <alan@lxorguk.ukuu.org.uk> wrote: > On Wed, 21 Sep 2011 17:38:10 +0100 > Tim Deegan <tim@xen.org> wrote: > >> At 22:18 -0700 on 20 Sep (1316557136), AP wrote: >>>> Yes, booting Xen as a nested guest is very slow at startup, because of >>>> how Xen relocates the bottom 1MB at boot time. You might find that >>>> 32-bit Xen boots faster. >>> >>> Could please expand a little on why the relocation causes it to slow down? >> >> IIRC, the relocation itself is very slow because Xen just copies the low >> 1MB, which includes the VGA hole, so there are a lot of emulated reads. > > That seems a bit odd - ISA space reads can have side effects. We should probably not do that then. :-) In fact we only do it because the code was more convenient that way. The first thing we do with out relocated copy of the bottom megabyte is zap it with poison bytes. -- Keir > Alan > > _______________________________________________ > Xen-devel mailing list > Xen-devel@lists.xensource.com > http://lists.xensource.com/xen-devel _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel From xen-devel-bounces@lists.xensource.com Wed Sep 21 11:00:14 2011 Return-path: <xen-devel-bounces@lists.xensource.com> Envelope-to: www-data@lists.xensource.com Delivery-date: Wed, 21 Sep 2011 11:00:14 -0700 Received: from localhost ([127.0.0.1] helo=lists.colo.xensource.com) by lists.xensource.com with esmtp (Exim 4.43) id 1R6R5h-0007nz-8z; Wed, 21 Sep 2011 11:00:13 -0700 Received: from mail21.messagelabs.com ([85.158.143.35]) by lists.xensource.com with esmtp (Exim 4.43) id 1R6R3X-0007ZQ-C9; Wed, 21 Sep 2011 10:58:00 -0700 X-Env-Sender: konrad@oracle.com X-Msg-Ref: server-5.tower-21.messagelabs.com!1316627840!49011070!1 X-Originating-IP: [148.87.113.117] X-StarScan-Version: 6.4.1; banners=-,-,- X-VirusChecked: Checked Received: (qmail 27214 invoked from network); 21 Sep 2011 17:57:21 -0000 Received: from rcsinet15.oracle.com (HELO rcsinet15.oracle.com) (148.87.113.117) by server-5.tower-21.messagelabs.com with DHE-RSA-AES256-SHA encrypted SMTP; 21 Sep 2011 17:57:21 -0000 Received: from rtcsinet21.oracle.com (rtcsinet21.oracle.com [66.248.204.29]) by rcsinet15.oracle.com (Switch-3.4.4/Switch-3.4.4) with ESMTP id p8LHvnDJ007952 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Wed, 21 Sep 2011 17:57:51 GMT Received: from acsmt356.oracle.com (acsmt356.oracle.com [141.146.40.156]) by rtcsinet21.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id p8LHvmRw008867 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 21 Sep 2011 17:57:49 GMT Received: from abhmt118.oracle.com (abhmt118.oracle.com [141.146.116.70]) by acsmt356.oracle.com (8.12.11.20060308/8.12.11) with ESMTP id p8LHvhGK021094; Wed, 21 Sep 2011 12:57:43 -0500 Received: from oracle.com (/209.6.55.207) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Wed, 21 Sep 2011 10:57:43 -0700 Received: by oracle.com (Postfix, from userid 1000) id 1201E1362; Wed, 21 Sep 2011 13:57:49 -0400 (EDT) Date: Wed, 21 Sep 2011 13:57:48 -0400 From: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com> To: jinho hwang <hwang.jinho@gmail.com> Subject: Re: [Xen-devel] [Xen-users] XENBUS waiting timeout Message-ID: <20110921175748.GA17357@phenom.oracle.com> References: <CAPQGAnETiDBCC8jS7xiSuNu4ASRTMLXoWAvb5HuAsgjHNj-FCw@mail.gmail.com> <20110915080121.GB4396@phenom.oracle.com> <CAPQGAnFagd-Hy-ZKupFsvjdtbVZ801hrGCVybX2pEL+qLnX6zw@mail.gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <CAPQGAnFagd-Hy-ZKupFsvjdtbVZ801hrGCVybX2pEL+qLnX6zw@mail.gmail.com> User-Agent: Mutt/1.5.21 (2010-09-15) X-Source-IP: rtcsinet21.oracle.com [66.248.204.29] X-CT-RefId: str=0001.0A090201.4E7A25A0.00C3,ss=1,re=0.000,fgs=0 Cc: xen-devel@lists.xensource.com, xen-users@lists.xensource.com X-BeenThere: xen-devel@lists.xensource.com X-Mailman-Version: 2.1.5 Precedence: list List-Id: Xen developer discussion <xen-devel.lists.xensource.com> List-Unsubscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe> List-Post: <mailto:xen-devel@lists.xensource.com> List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help> List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=subscribe> Sender: xen-devel-bounces@lists.xensource.com Errors-To: xen-devel-bounces@lists.xensource.com On Thu, Sep 15, 2011 at 01:17:50PM -0400, jinho hwang wrote: > I'm using Xen 4.0.3 and linux 2.6.32.46 for dom0 and domU as well. From > xenstore-ls, I could see the numbers you mentioned 51713 and 51714 for my > guest, but the log says that the devices for the numbers are not detected as > follows: Ok, is there any messages in dom0 or Xen hypervisor logs? 'xl dmesg' or 'dmesg' that show an error? _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel From xen-devel-bounces@lists.xensource.com Wed Sep 21 11:09:01 2011 Return-path: <xen-devel-bounces@lists.xensource.com> Envelope-to: www-data@lists.xensource.com Delivery-date: Wed, 21 Sep 2011 11:09:01 -0700 Received: from localhost ([127.0.0.1] helo=lists.colo.xensource.com) by lists.xensource.com with esmtp (Exim 4.43) id 1R6REC-0000Zv-3g; Wed, 21 Sep 2011 11:09:00 -0700 Received: from mail174.messagelabs.com ([85.158.138.51]) by lists.xensource.com with esmtp (Exim 4.43) id 1R6R6r-0007z2-G3; Wed, 21 Sep 2011 11:01:49 -0700 X-Env-Sender: hwang.jinho@gmail.com X-Msg-Ref: server-10.tower-174.messagelabs.com!1316628080!32258905!1 X-Originating-IP: [74.125.83.41] X-StarScan-Version: 6.4.1; banners=-,-,- X-VirusChecked: Checked Received: (qmail 25928 invoked from network); 21 Sep 2011 18:01:21 -0000 Received: from mail-gw0-f41.google.com (HELO mail-gw0-f41.google.com) (74.125.83.41) by server-10.tower-174.messagelabs.com with RC4-SHA encrypted SMTP; 21 Sep 2011 18:01:21 -0000 Received: by gwaa12 with SMTP id a12so3027578gwa.28 for <multiple recipients>; Wed, 21 Sep 2011 11:01:20 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=6jfsh0IQ7pAbD9Ef5i96M8dFxRkWhSg7K32OJ8Rsh7k=; b=JIO+dKVRrzjVzMWPgfYIw0DA+6BRz7tGT3SWD/rSodirYyEUV9j0IRyb98jb3Xk8Ht /vHprEbftDAnQ6QnxTJmn9D3uZJdTFsw/bDSjPCYSYHJyDVSSrkdcgMnxOnXfWra5fQW mqaxIKEiLSAQe3281/KEM6PhpT5po+/f6Bius= Received: by 10.150.176.10 with SMTP id y10mr1326668ybe.351.1316628080113; Wed, 21 Sep 2011 11:01:20 -0700 (PDT) MIME-Version: 1.0 Received: by 10.151.154.16 with HTTP; Wed, 21 Sep 2011 11:01:00 -0700 (PDT) In-Reply-To: <20110921175748.GA17357@phenom.oracle.com> References: <CAPQGAnETiDBCC8jS7xiSuNu4ASRTMLXoWAvb5HuAsgjHNj-FCw@mail.gmail.com> <20110915080121.GB4396@phenom.oracle.com> <CAPQGAnFagd-Hy-ZKupFsvjdtbVZ801hrGCVybX2pEL+qLnX6zw@mail.gmail.com> <20110921175748.GA17357@phenom.oracle.com> From: jinho hwang <hwang.jinho@gmail.com> Date: Wed, 21 Sep 2011 14:01:00 -0400 Message-ID: <CAPQGAnHRPcXZBO4nU1kw4YPJGMO0Uq0nQZXsMqx09NTGUrHoLQ@mail.gmail.com> Subject: Re: [Xen-devel] [Xen-users] XENBUS waiting timeout To: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com> Cc: xen-devel@lists.xensource.com, xen-users@lists.xensource.com X-BeenThere: xen-devel@lists.xensource.com X-Mailman-Version: 2.1.5 Precedence: list List-Id: Xen developer discussion <xen-devel.lists.xensource.com> List-Unsubscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe> List-Post: <mailto:xen-devel@lists.xensource.com> List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help> List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=subscribe> Content-Type: multipart/mixed; boundary="===============0478316693==" Sender: xen-devel-bounces@lists.xensource.com Errors-To: xen-devel-bounces@lists.xensource.com --===============0478316693== Content-Type: multipart/alternative; boundary=000e0cd762e204396704ad775dbf --000e0cd762e204396704ad775dbf Content-Type: text/plain; charset=ISO-8859-1 Hi Konrad, Thank you for your replay. I have spent many an hour to solve this problem. It turned out that blktap didn't work for bringing up devices properly. But when I changed it to old style "file", it worked well. And now everything is settled.. I already run many doms in my machine. Thank you, Jinho On Wed, Sep 21, 2011 at 1:57 PM, Konrad Rzeszutek Wilk < konrad.wilk@oracle.com> wrote: > On Thu, Sep 15, 2011 at 01:17:50PM -0400, jinho hwang wrote: > > I'm using Xen 4.0.3 and linux 2.6.32.46 for dom0 and domU as well. From > > xenstore-ls, I could see the numbers you mentioned 51713 and 51714 for my > > guest, but the log says that the devices for the numbers are not detected > as > > follows: > > Ok, is there any messages in dom0 or Xen hypervisor logs? > > 'xl dmesg' or 'dmesg' that show an error? > -- Jinho Hwang PhD Student Department of Computer Science The George Washington University Washington, DC 20052 hwang.jinho@gmail.com (email) 276.336.0971 (Cell) 202.994.4875 (fax) 070.8285.6546 (myLg070) --000e0cd762e204396704ad775dbf Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable <div><br></div>Hi Konrad,=A0<div><br></div><div>Thank you for your replay. = I have spent many an hour to solve this problem. It turned out that blktap = didn't work for bringing up devices properly. But when I changed it to = old style "file", it worked well. And now everything is settled..= I already run many doms in my machine.=A0</div> <div><br></div><div>Thank you,</div><div><br></div><div>Jinho<br><br><div c= lass=3D"gmail_quote">On Wed, Sep 21, 2011 at 1:57 PM, Konrad Rzeszutek Wilk= <span dir=3D"ltr"><<a href=3D"mailto:konrad.wilk@oracle.com">konrad.wil= k@oracle.com</a>></span> wrote:<br> <blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1p= x #ccc solid;padding-left:1ex;"><div class=3D"im">On Thu, Sep 15, 2011 at 0= 1:17:50PM -0400, jinho hwang wrote:<br> > I'm using Xen 4.0.3 and linux 2.6.32.46 for dom0 and domU as well.= From<br> > xenstore-ls, I could see the numbers you mentioned 51713 and 51714 for= my<br> > guest, but the log says that the devices for the numbers are not detec= ted as<br> > follows:<br> <br> </div>Ok, is there any messages in dom0 or Xen hypervisor logs?<br> <br> 'xl dmesg' or 'dmesg' that show an error?<br> </blockquote></div><br><br clear=3D"all"><div><br></div>-- <br>Jinho Hwang<= br>PhD Student<br>Department of Computer Science<br>The George Washington U= niversity<br>Washington, DC 20052<br><a href=3D"mailto:hwang.jinho@gmail.co= m">hwang.jinho@gmail.com</a> (email)<br> 276.336.0971 (Cell)<br>202.994.4875 (fax)<br>070.8285.6546 (myLg070)<br> </div> --000e0cd762e204396704ad775dbf-- --===============0478316693== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel --===============0478316693==-- From xen-devel-bounces@lists.xensource.com Wed Sep 21 11:13:47 2011 Return-path: <xen-devel-bounces@lists.xensource.com> Envelope-to: www-data@lists.xensource.com Delivery-date: Wed, 21 Sep 2011 11:13:47 -0700 Received: from localhost ([127.0.0.1] helo=lists.colo.xensource.com) by lists.xensource.com with esmtp (Exim 4.43) id 1R6RIp-0001fQ-3e; Wed, 21 Sep 2011 11:13:47 -0700 Received: from mail21.messagelabs.com ([85.158.143.35]) by lists.xensource.com with esmtp (Exim 4.43) id 1R6R8o-00085h-1M for xen-devel@lists.xensource.com; Wed, 21 Sep 2011 11:03:27 -0700 X-Env-Sender: konrad@oracle.com X-Msg-Ref: server-9.tower-21.messagelabs.com!1316628156!49295770!1 X-Originating-IP: [141.146.126.227] X-StarScan-Version: 6.4.1; banners=-,-,- X-VirusChecked: Checked Received: (qmail 4979 invoked from network); 21 Sep 2011 18:02:38 -0000 Received: from acsinet15.oracle.com (HELO acsinet15.oracle.com) (141.146.126.227) by server-9.tower-21.messagelabs.com with DHE-RSA-AES256-SHA encrypted SMTP; 21 Sep 2011 18:02:38 -0000 Received: from rtcsinet21.oracle.com (rtcsinet21.oracle.com [66.248.204.29]) by acsinet15.oracle.com (Switch-3.4.4/Switch-3.4.4) with ESMTP id p8LI3FR9002485 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Wed, 21 Sep 2011 18:03:17 GMT Received: from acsmt358.oracle.com (acsmt358.oracle.com [141.146.40.158]) by rtcsinet21.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id p8LI3DQo020217 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 21 Sep 2011 18:03:14 GMT Received: from abhmt118.oracle.com (abhmt118.oracle.com [141.146.116.70]) by acsmt358.oracle.com (8.12.11.20060308/8.12.11) with ESMTP id p8LI37mh028260; Wed, 21 Sep 2011 13:03:07 -0500 Received: from oracle.com (/209.6.55.207) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Wed, 21 Sep 2011 11:03:07 -0700 Received: by oracle.com (Postfix, from userid 1000) id 819A01362; Wed, 21 Sep 2011 14:03:13 -0400 (EDT) Date: Wed, 21 Sep 2011 14:03:13 -0400 From: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com> To: Andy Burns <xen.lists@burns.me.uk> Subject: Re: [Xen-devel] Re: [Xen-users] Continuing BUG:-iness booting Fedora Rawhide 3.1.0-rc's (was Summary: Experiences setting up a debug serial port) Message-ID: <20110921180313.GB17357@phenom.oracle.com> References: <201107231426.56811.jim_burn@bellsouth.net> <1342436.B0x3ddQn4U@dell4550> <20110913085559.GG12984@reaktio.net> <1856036.eYCcuDQrZC@dell4550> <20110914090806.GD25628@phenom.oracle.com> <20110914105711.GA16284@phenom.oracle.com> <CAE1-PRfFwJh1WotLL5GD+L=Vn-zwZctqa+Rhzs2tqMavw1j-WQ@mail.gmail.com> <CAE1-PRdQ37dg6BX+1JGA2mvviNu8t-iAZHVoDKrvg53H_jyztw@mail.gmail.com> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="KsGdsel6WgEHnImy" Content-Disposition: inline In-Reply-To: <CAE1-PRdQ37dg6BX+1JGA2mvviNu8t-iAZHVoDKrvg53H_jyztw@mail.gmail.com> User-Agent: Mutt/1.5.21 (2010-09-15) X-Source-IP: rtcsinet21.oracle.com [66.248.204.29] X-CT-RefId: str=0001.0A090203.4E7A26E5.0234,ss=1,re=0.000,fgs=0 Cc: xen-devel@lists.xensource.com X-BeenThere: xen-devel@lists.xensource.com X-Mailman-Version: 2.1.5 Precedence: list List-Id: Xen developer discussion <xen-devel.lists.xensource.com> List-Unsubscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe> List-Post: <mailto:xen-devel@lists.xensource.com> List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help> List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=subscribe> Sender: xen-devel-bounces@lists.xensource.com Errors-To: xen-devel-bounces@lists.xensource.com --KsGdsel6WgEHnImy Content-Type: text/plain; charset=us-ascii Content-Disposition: inline > [ 0.615589] usbcore: registered new interface driver hub > [ 0.615589] usbcore: registered new device driver usb > [ 0.615948] PCI: Using ACPI for IRQ routing > (XEN) mm.c:4976:d0 Global bit is set to kernel page fffff81b8e > (XEN) mm.c:4976:d0 Global bit is set to kernel page fffff81b8e > (XEN) mm.c:4976:d0 Global bit is set to kernel page fffff81118 > (XEN) mm.c:4976:d0 Global bit is set to kernel page fffff81117 > (XEN) domain_crash_sync called from entry.S > (XEN) Domain 0 (vcpu#0) crashed on cpu#0: > (XEN) ----[ Xen-4.1.1 x86_64 debug=n Not tainted ]---- > (XEN) CPU: 0 > (XEN) RIP: e033:[<ffffffff81118d96>] > (XEN) RFLAGS: 0000000000010282 EM: 0 CONTEXT: pv guest > (XEN) rax: 0000000000000080 rbx: ffff880163985480 rcx: 0000000000000040 > (XEN) rdx: 0040000000000080 rsi: ffff880163985480 rdi: ffff880163985480 > (XEN) rbp: ffff880163dfaff0 rsp: ffff880163dfafd0 r8: 0000001373ffffff > (XEN) r9: ffffffff81b8e7fd r10: 0000ffff00066c0a r11: 0000000080000000 > (XEN) r12: ffffffff81a1cbd0 r13: ffffffff81b8e7fd r14: 0000001000000000 > (XEN) r15: ffffffff81a1cbd0 cr0: 000000008005003b cr4: 00000000000026f0 > (XEN) cr3: 0000000221a05000 cr2: 000000137400002f > (XEN) ds: 0000 es: 0000 fs: 0000 gs: 0000 ss: e02b cs: e033 That is fixed in the latest Linus tree. You might need this patch as well: (also attached) commit e3b73c4a25e9a5705b4ef28b91676caf01f9bc9f Author: David Vrabel <david.vrabel@citrix.com> Date: Tue Sep 13 10:17:32 2011 -0400 xen/e820: if there is no dom0_mem=, don't tweak extra_pages. The patch "xen: use maximum reservation to limit amount of usable RAM" (d312ae878b6aed3912e1acaaf5d0b2a9d08a4f11) breaks machines that do not use 'dom0_mem=' argument with: reserve RAM buffer: 000000133f2e2000 - 000000133fffffff (XEN) mm.c:4976:d0 Global bit is set to kernel page fffff8117e (XEN) domain_crash_sync called from entry.S (XEN) Domain 0 (vcpu#0) crashed on cpu#0: ... The reason being that the last E820 entry is created using the 'extra_pages' (which is based on how many pages have been freed). The mentioned git commit sets the initial value of 'extra_pages' using a hypercall which returns the number of pages (if dom0_mem has been used) or -1 otherwise. If the later we return with MAX_DOMAIN_PAGES as basis for calculation: return min(max_pages, MAX_DOMAIN_PAGES); and use it: extra_limit = xen_get_max_pages(); if (extra_limit >= max_pfn) extra_pages = extra_limit - max_pfn; else extra_pages = 0; which means we end up with extra_pages = 128GB in PFNs (33554432) - 8GB in PFNs (2097152, on this specific box, can be larger or smaller), and then we add that value to the E820 making it: Xen: 00000000ff000000 - 0000000100000000 (reserved) Xen: 0000000100000000 - 000000133f2e2000 (usable) which is clearly wrong. It should look as so: Xen: 00000000ff000000 - 0000000100000000 (reserved) Xen: 0000000100000000 - 000000027fbda000 (usable) Naturally this problem does not present itself if dom0_mem=max:X is used. CC: stable@kernel.org Signed-off-by: David Vrabel <david.vrabel@citrix.com> Signed-off-by: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com> diff --git a/arch/x86/xen/setup.c b/arch/x86/xen/setup.c index ff3dfa1..09688eb 100644 --- a/arch/x86/xen/setup.c +++ b/arch/x86/xen/setup.c @@ -305,10 +305,12 @@ char * __init xen_memory_setup(void) sanitize_e820_map(e820.map, ARRAY_SIZE(e820.map), &e820.nr_map); extra_limit = xen_get_max_pages(); - if (extra_limit >= max_pfn) - extra_pages = extra_limit - max_pfn; - else - extra_pages = 0; + if (max_pfn + extra_pages > extra_limit) { + if (extra_limit > max_pfn) + extra_pages = extra_limit - max_pfn; + else + extra_pages = 0; + } extra_pages += xen_return_unused_memory(xen_start_info->nr_pages, &e820); --KsGdsel6WgEHnImy Content-Type: text/x-diff; charset=us-ascii Content-Disposition: attachment; filename="e3b73c4a25e9a5705b4ef28b91676caf01f9bc9f.patch" commit e3b73c4a25e9a5705b4ef28b91676caf01f9bc9f Author: David Vrabel <david.vrabel@citrix.com> Date: Tue Sep 13 10:17:32 2011 -0400 xen/e820: if there is no dom0_mem=, don't tweak extra_pages. The patch "xen: use maximum reservation to limit amount of usable RAM" (d312ae878b6aed3912e1acaaf5d0b2a9d08a4f11) breaks machines that do not use 'dom0_mem=' argument with: reserve RAM buffer: 000000133f2e2000 - 000000133fffffff (XEN) mm.c:4976:d0 Global bit is set to kernel page fffff8117e (XEN) domain_crash_sync called from entry.S (XEN) Domain 0 (vcpu#0) crashed on cpu#0: ... The reason being that the last E820 entry is created using the 'extra_pages' (which is based on how many pages have been freed). The mentioned git commit sets the initial value of 'extra_pages' using a hypercall which returns the number of pages (if dom0_mem has been used) or -1 otherwise. If the later we return with MAX_DOMAIN_PAGES as basis for calculation: return min(max_pages, MAX_DOMAIN_PAGES); and use it: extra_limit = xen_get_max_pages(); if (extra_limit >= max_pfn) extra_pages = extra_limit - max_pfn; else extra_pages = 0; which means we end up with extra_pages = 128GB in PFNs (33554432) - 8GB in PFNs (2097152, on this specific box, can be larger or smaller), and then we add that value to the E820 making it: Xen: 00000000ff000000 - 0000000100000000 (reserved) Xen: 0000000100000000 - 000000133f2e2000 (usable) which is clearly wrong. It should look as so: Xen: 00000000ff000000 - 0000000100000000 (reserved) Xen: 0000000100000000 - 000000027fbda000 (usable) Naturally this problem does not present itself if dom0_mem=max:X is used. CC: stable@kernel.org Signed-off-by: David Vrabel <david.vrabel@citrix.com> Signed-off-by: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com> diff --git a/arch/x86/xen/setup.c b/arch/x86/xen/setup.c index ff3dfa1..09688eb 100644 --- a/arch/x86/xen/setup.c +++ b/arch/x86/xen/setup.c @@ -305,10 +305,12 @@ char * __init xen_memory_setup(void) sanitize_e820_map(e820.map, ARRAY_SIZE(e820.map), &e820.nr_map); extra_limit = xen_get_max_pages(); - if (extra_limit >= max_pfn) - extra_pages = extra_limit - max_pfn; - else - extra_pages = 0; + if (max_pfn + extra_pages > extra_limit) { + if (extra_limit > max_pfn) + extra_pages = extra_limit - max_pfn; + else + extra_pages = 0; + } extra_pages += xen_return_unused_memory(xen_start_info->nr_pages, &e820); --KsGdsel6WgEHnImy Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel --KsGdsel6WgEHnImy-- From xen-devel-bounces@lists.xensource.com Wed Sep 21 11:14:51 2011 Return-path: <xen-devel-bounces@lists.xensource.com> Envelope-to: www-data@lists.xensource.com Delivery-date: Wed, 21 Sep 2011 11:14:51 -0700 Received: from localhost ([127.0.0.1] helo=lists.colo.xensource.com) by lists.xensource.com with esmtp (Exim 4.43) id 1R6RJr-00022H-5D; Wed, 21 Sep 2011 11:14:51 -0700 Received: from mail174.messagelabs.com ([85.158.138.51]) by lists.xensource.com with esmtp (Exim 4.43) id 1R6RC4-0000BV-Pd for xen-devel@lists.xensource.com; Wed, 21 Sep 2011 11:06:52 -0700 X-Env-Sender: konrad@oracle.com X-Msg-Ref: server-14.tower-174.messagelabs.com!1316628403!32268536!1 X-Originating-IP: [141.146.126.227] X-StarScan-Version: 6.4.1; banners=-,-,- X-VirusChecked: Checked Received: (qmail 3265 invoked from network); 21 Sep 2011 18:06:45 -0000 Received: from acsinet15.oracle.com (HELO acsinet15.oracle.com) (141.146.126.227) by server-14.tower-174.messagelabs.com with DHE-RSA-AES256-SHA encrypted SMTP; 21 Sep 2011 18:06:45 -0000 Received: from rtcsinet22.oracle.com (rtcsinet22.oracle.com [66.248.204.30]) by acsinet15.oracle.com (Switch-3.4.4/Switch-3.4.4) with ESMTP id p8LI6Plw010338 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Wed, 21 Sep 2011 18:06:27 GMT Received: from acsmt358.oracle.com (acsmt358.oracle.com [141.146.40.158]) by rtcsinet22.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id p8LI6Oe1019379 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 21 Sep 2011 18:06:25 GMT Received: from abhmt103.oracle.com (abhmt103.oracle.com [141.146.116.55]) by acsmt358.oracle.com (8.12.11.20060308/8.12.11) with ESMTP id p8LI6IiI031263; Wed, 21 Sep 2011 13:06:19 -0500 Received: from oracle.com (/209.6.55.207) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Wed, 21 Sep 2011 11:06:18 -0700 Received: by oracle.com (Postfix, from userid 1000) id D20781362; Wed, 21 Sep 2011 14:06:24 -0400 (EDT) Date: Wed, 21 Sep 2011 14:06:24 -0400 From: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com> To: Sven =?iso-8859-1?Q?K=F6hler?= <sven.koehler@gmail.com> Subject: Re: [Xen-devel] Re: 3.0.4 and 3.1-rc4 based dom0 won't boot with acpi=off Message-ID: <20110921180624.GD17357@phenom.oracle.com> References: <j4gp1v$oog$1@dough.gmane.org> <20110911002807.GA9989@oracle.com> <4E6C0473.8090905@gmail.com> <20110912150606.GC15778@oracle.com> <4E764607.80703@gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline In-Reply-To: <4E764607.80703@gmail.com> User-Agent: Mutt/1.5.21 (2010-09-15) Content-Transfer-Encoding: quoted-printable X-Source-IP: rtcsinet22.oracle.com [66.248.204.30] X-CT-RefId: str=0001.0A090202.4E7A27B2.0075,ss=1,re=0.000,fgs=0 Cc: xen-devel@lists.xensource.com X-BeenThere: xen-devel@lists.xensource.com X-Mailman-Version: 2.1.5 Precedence: list List-Id: Xen developer discussion <xen-devel.lists.xensource.com> List-Unsubscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe> List-Post: <mailto:xen-devel@lists.xensource.com> List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help> List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=subscribe> Sender: xen-devel-bounces@lists.xensource.com Errors-To: xen-devel-bounces@lists.xensource.com On Sun, Sep 18, 2011 at 09:27:03PM +0200, Sven K=F6hler wrote: > Am 12.09.2011 17:06, schrieb Konrad Rzeszutek Wilk: > > On Sun, Sep 11, 2011 at 02:44:35AM +0200, Sven K=F6hler wrote: > >> Am 11.09.2011 02:28, schrieb Konrad Rzeszutek Wilk: > >>> You might want to try some parameters on the Xen line to alter how > >>> it is suppose to reboot. > >>> > >>> /* > >>> * reboot=3Db[ios] | t[riple] | k[bd] | n[o] [, [w]arm | [c]old] > >> > >> Thanks for the list. > >> I guess, both reboot=3Dbios and reboot=3Db is accepted? > >> BTW: "no" is missing in the list below. acpi is missing in the list > >> above. And actually what's the source for list? > >=20 > > Xen hypervisor source. I just did a quick search for 'reboot=3D' >=20 > I checked the sources of Linux 3.1rc4 and he xen hypervisor (4.1.1). > The code for reboot is almost the same. One tiny difference is that the > code of xen sets the reset flag of the kbd controller 100 times, while > Linux does that only 10 times: >=20 > Xen: > > for ( i =3D 0; i < 100; i++ ) > > { > > kb_wait(); > > udelay(50); > > outb(0xfe,0x64); /* pulse reset low */ > > udelay(50); > > } >=20 > Linux: > > for (i =3D 0; i < 10; i++) { > > kb_wait(); > > udelay(50); > > outb(0xfe, 0x64); /* pulse reset low = */ > > udelay(50); > > } >=20 >=20 > Summing up, both Linux 3.1 and Xen 4.1 both do the following sequence b= y > default: >=20 > ACPI, KBD, ACPI, KBD, TRIPLE, KBD, TRIPLE, KBD, ... >=20 > While each KBD stands for 10 (Linux) or 100 (Xen) times setting the kbd > controller reset flag. I wonder why Xen does the kbd controller reset a > hundred times. Maybe it's a left over from xen 3.x? Could be. >=20 > Would you mind changing it from 100 to 10? Does it fix the problem with this particular board? If so, then that soun= ds like we should do. >=20 >=20 > Now taking a look at Xen 3.4.2, the default reboot sequence is a bit > different. It's >=20 > ACPI, KBD, ACPI, KBD, ACPI, KBD, ACPI, KBD, .... >=20 > No triple fault reset attempts. Ah, could be that we just never had it implemented then. >=20 >=20 >=20 > _______________________________________________ > Xen-devel mailing list > Xen-devel@lists.xensource.com > http://lists.xensource.com/xen-devel _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel From xen-devel-bounces@lists.xensource.com Wed Sep 21 11:16:08 2011 Return-path: <xen-devel-bounces@lists.xensource.com> Envelope-to: www-data@lists.xensource.com Delivery-date: Wed, 21 Sep 2011 11:16:08 -0700 Received: from localhost ([127.0.0.1] helo=lists.colo.xensource.com) by lists.xensource.com with esmtp (Exim 4.43) id 1R6RL6-0002Q6-9M; Wed, 21 Sep 2011 11:16:08 -0700 Received: from mail182.messagelabs.com ([85.158.139.83]) by lists.xensource.com with esmtp (Exim 4.43) id 1R6RDg-0000Tv-C7 for xen-devel@lists.xensource.com; Wed, 21 Sep 2011 11:08:28 -0700 X-Env-Sender: konrad@oracle.com X-Msg-Ref: server-11.tower-182.messagelabs.com!1316628503!19239518!1 X-Originating-IP: [141.146.126.227] X-StarScan-Version: 6.4.1; banners=-,-,- X-VirusChecked: Checked Received: (qmail 560 invoked from network); 21 Sep 2011 18:08:25 -0000 Received: from acsinet15.oracle.com (HELO acsinet15.oracle.com) (141.146.126.227) by server-11.tower-182.messagelabs.com with DHE-RSA-AES256-SHA encrypted SMTP; 21 Sep 2011 18:08:25 -0000 Received: from acsinet22.oracle.com (acsinet22.oracle.com [141.146.126.238]) by acsinet15.oracle.com (Switch-3.4.4/Switch-3.4.4) with ESMTP id p8LI8JCD014135 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Wed, 21 Sep 2011 18:08:21 GMT Received: from acsmt357.oracle.com (acsmt357.oracle.com [141.146.40.157]) by acsinet22.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id p8LI8IBJ006145 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 21 Sep 2011 18:08:19 GMT Received: from abhmt107.oracle.com (abhmt107.oracle.com [141.146.116.59]) by acsmt357.oracle.com (8.12.11.20060308/8.12.11) with ESMTP id p8LI8Dda017255; Wed, 21 Sep 2011 13:08:13 -0500 Received: from oracle.com (/209.6.55.207) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Wed, 21 Sep 2011 11:08:13 -0700 Received: by oracle.com (Postfix, from userid 1000) id D1AEF1362; Wed, 21 Sep 2011 14:08:19 -0400 (EDT) Date: Wed, 21 Sep 2011 14:08:19 -0400 From: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com> To: Andy Burns <xen.lists@burns.me.uk> Subject: Re: [Xen-devel] Re: F16, yum install xen, run grub2 or grubby as needed? Message-ID: <20110921180819.GE17357@phenom.oracle.com> References: <20110915154621.GA21580@phenom.oracle.com> <alpine.LFD.2.02.1109152224170.2506@vega2.dur.ac.uk> <20110916083533.GC884@phenom.oracle.com> <CAE1-PRcO=7dBYxwJCq0L0Q6qcT=Nbnf4d2Sg3f=780MRxpKOaw@mail.gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <CAE1-PRcO=7dBYxwJCq0L0Q6qcT=Nbnf4d2Sg3f=780MRxpKOaw@mail.gmail.com> User-Agent: Mutt/1.5.21 (2010-09-15) X-Source-IP: acsinet22.oracle.com [141.146.126.238] X-Auth-Type: Internal IP X-CT-RefId: str=0001.0A090205.4E7A2815.00B1:SCFMA922111,ss=1,re=-4.000,fgs=0 Cc: xen-devel@lists.xensource.com X-BeenThere: xen-devel@lists.xensource.com X-Mailman-Version: 2.1.5 Precedence: list List-Id: Xen developer discussion <xen-devel.lists.xensource.com> List-Unsubscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe> List-Post: <mailto:xen-devel@lists.xensource.com> List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help> List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=subscribe> Sender: xen-devel-bounces@lists.xensource.com Errors-To: xen-devel-bounces@lists.xensource.com On Sun, Sep 18, 2011 at 08:53:29PM +0100, Andy Burns wrote: > On 16 September 2011 09:35, Konrad Rzeszutek Wilk > <konrad.wilk@oracle.com> wrote: > > > On Thu, Sep 15, 2011 at 10:29:50PM +0100, M A Young wrote: > >> On Thu, 15 Sep 2011, Konrad Rzeszutek Wilk wrote: > >> > >>> realized that I had to manually do: > >>> grub2-mkconfig > /boot/grub2/grub.cfg > > Yes, I've been manually running that too, but the resuling grub.cfg > file from when I manually regenerate it is subtly different from the > grub.cfg generated after automatically installing a new kernel ... > > The one generated by manually running grub2-mkconfig creates a Xen > submenu with all the various kernels under it, whereas after > installing a new kernel, the one generated has all the xen + kernels > in the top level menu. Oh, well, that is kind of convient. So you install new kernel and viola the new kernel boots in the hypervisor kernel? > > >> grub2 creates a > >> set of entries for each of xen-4.1.1.gz and its two symbolic links > >> xen-4.1.gz and xen.gz which is a bit untidy, so perhaps it makes > >> sense to remove the symbolic links. > > I've submitted a bug with a patch to make the /etc/20_linux_xen helper > script ignore the symbol files and symbolic links, if there's no need > for the symbolic links the patch could be even simpler. Could you also send the patch to upstream grub2? So that other distros can benefit as well? > > https://bugzilla.redhat.com/show_bug.cgi?id=738085 > > _______________________________________________ > Xen-devel mailing list > Xen-devel@lists.xensource.com > http://lists.xensource.com/xen-devel _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel From xen-devel-bounces@lists.xensource.com Wed Sep 21 11:17:43 2011 Return-path: <xen-devel-bounces@lists.xensource.com> Envelope-to: www-data@lists.xensource.com Delivery-date: Wed, 21 Sep 2011 11:17:43 -0700 Received: from localhost ([127.0.0.1] helo=lists.colo.xensource.com) by lists.xensource.com with esmtp (Exim 4.43) id 1R6RMd-0002nC-QU; Wed, 21 Sep 2011 11:17:43 -0700 Received: from mail182.messagelabs.com ([85.158.139.83]) by lists.xensource.com with esmtp (Exim 4.43) id 1R6RFR-0000md-Rq for xen-devel@lists.xensource.com; Wed, 21 Sep 2011 11:10:18 -0700 X-Env-Sender: konrad@oracle.com X-Msg-Ref: server-6.tower-182.messagelabs.com!1316628613!19226654!1 X-Originating-IP: [141.146.126.227] X-StarScan-Version: 6.4.1; banners=-,-,- X-VirusChecked: Checked Received: (qmail 3994 invoked from network); 21 Sep 2011 18:10:14 -0000 Received: from acsinet15.oracle.com (HELO acsinet15.oracle.com) (141.146.126.227) by server-6.tower-182.messagelabs.com with DHE-RSA-AES256-SHA encrypted SMTP; 21 Sep 2011 18:10:14 -0000 Received: from acsinet21.oracle.com (acsinet21.oracle.com [141.146.126.237]) by acsinet15.oracle.com (Switch-3.4.4/Switch-3.4.4) with ESMTP id p8LIA3WZ018606 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Wed, 21 Sep 2011 18:10:08 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 p8LI4OiN023043 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 21 Sep 2011 18:04:24 GMT Received: from abhmt115.oracle.com (abhmt115.oracle.com [141.146.116.67]) by acsmt358.oracle.com (8.12.11.20060308/8.12.11) with ESMTP id p8LI4HSg029267; Wed, 21 Sep 2011 13:04:17 -0500 Received: from oracle.com (/209.6.55.207) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Wed, 21 Sep 2011 11:04:17 -0700 Received: by oracle.com (Postfix, from userid 1000) id 907C11362; Wed, 21 Sep 2011 14:04:23 -0400 (EDT) Date: Wed, 21 Sep 2011 14:04:23 -0400 From: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com> To: "Christopher S. Aker" <caker@theshore.net> Subject: Re: [Xen-devel] Re: kernel BUG at mm/swapfile.c:2527! [was 3.0.0 Xen pv guest - BUG: Unable to handle] Message-ID: <20110921180423.GC17357@phenom.oracle.com> References: <4E5BA49D.5060800@theshore.net> <20110829150734.GB24825@dumpdata.com> <1314704744.28989.2.camel@zakaz.uk.xensource.com> <4E5E9CDB.3070706@theshore.net> <20110906171319.GB29839@dumpdata.com> <4E6E2E11.1030602@theshore.net> <20110912161127.GB16100@oracle.com> <4E724ACD.1050207@theshore.net> <4E724F64.5080103@theshore.net> <CEE295A1-B386-4A2A-A16C-9AC29DE174E8@theshore.net> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <CEE295A1-B386-4A2A-A16C-9AC29DE174E8@theshore.net> User-Agent: Mutt/1.5.21 (2010-09-15) X-Source-IP: acsinet21.oracle.com [141.146.126.237] X-Auth-Type: Internal IP X-CT-RefId: str=0001.0A090202.4E7A2882.00F7:SCFMA922111,ss=1,re=-4.000,fgs=0 Cc: Jeremy Fitzhardinge <jeremy@goop.org>, "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>, Ian Campbell <Ian.Campbell@citrix.com>, LKML <linux-kernel@vger.kernel.org> X-BeenThere: xen-devel@lists.xensource.com X-Mailman-Version: 2.1.5 Precedence: list List-Id: Xen developer discussion <xen-devel.lists.xensource.com> List-Unsubscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe> List-Post: <mailto:xen-devel@lists.xensource.com> List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help> List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=subscribe> Sender: xen-devel-bounces@lists.xensource.com Errors-To: xen-devel-bounces@lists.xensource.com On Sun, Sep 18, 2011 at 11:05:33AM -0400, Christopher S. Aker wrote: > We've discovered a way to reproduce this quite easily! Fire up a guest, run eatmem with 1M and enough threads to not OOM. Excellent. Can you also send me your .config to make sure I've the right knobs set? > > http://www.theshore.net/~caker/uml/patches/utils/eatmem.c > > On a 1G guest: ./eatmem 1M 900 > > -Chris _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel From xen-devel-bounces@lists.xensource.com Wed Sep 21 11:18:50 2011 Return-path: <xen-devel-bounces@lists.xensource.com> Envelope-to: www-data@lists.xensource.com Delivery-date: Wed, 21 Sep 2011 11:18:50 -0700 Received: from localhost ([127.0.0.1] helo=lists.colo.xensource.com) by lists.xensource.com with esmtp (Exim 4.43) id 1R6RNi-0003A5-MB; Wed, 21 Sep 2011 11:18:50 -0700 Received: from mail27.messagelabs.com ([193.109.254.147]) by lists.xensource.com with esmtp (Exim 4.43) id 1R6RHC-0001BG-MS; Wed, 21 Sep 2011 11:12:08 -0700 X-Env-Sender: konrad@oracle.com X-Msg-Ref: server-10.tower-27.messagelabs.com!1316628701!36695434!1 X-Originating-IP: [141.146.126.227] X-StarScan-Version: 6.4.1; banners=-,-,- X-VirusChecked: Checked Received: (qmail 26584 invoked from network); 21 Sep 2011 18:11:43 -0000 Received: from acsinet15.oracle.com (HELO acsinet15.oracle.com) (141.146.126.227) by server-10.tower-27.messagelabs.com with DHE-RSA-AES256-SHA encrypted SMTP; 21 Sep 2011 18:11:43 -0000 Received: from acsinet21.oracle.com (acsinet21.oracle.com [141.146.126.237]) by acsinet15.oracle.com (Switch-3.4.4/Switch-3.4.4) with ESMTP id p8LIBwaj022991 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Wed, 21 Sep 2011 18:12:00 GMT Received: from acsmt356.oracle.com (acsmt356.oracle.com [141.146.40.156]) by acsinet21.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id p8LIBw2t011514 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 21 Sep 2011 18:11:58 GMT Received: from abhmt116.oracle.com (abhmt116.oracle.com [141.146.116.68]) by acsmt356.oracle.com (8.12.11.20060308/8.12.11) with ESMTP id p8LIBrNV001185; Wed, 21 Sep 2011 13:11:53 -0500 Received: from oracle.com (/209.6.55.207) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Wed, 21 Sep 2011 11:11:53 -0700 Received: by oracle.com (Postfix, from userid 1000) id 4DC9A1362; Wed, 21 Sep 2011 14:11:59 -0400 (EDT) Date: Wed, 21 Sep 2011 14:11:59 -0400 From: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com> To: jinho hwang <hwang.jinho@gmail.com> Subject: Re: [Xen-devel] DomU kernel panic due to run-init: /sbin/init: No such file or directory Message-ID: <20110921181159.GF17357@phenom.oracle.com> References: <CAPQGAnESzhHjC+UutPk3Qoftx5v==11X1E-p+xjLprGXokj9tg@mail.gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <CAPQGAnESzhHjC+UutPk3Qoftx5v==11X1E-p+xjLprGXokj9tg@mail.gmail.com> User-Agent: Mutt/1.5.21 (2010-09-15) X-Source-IP: acsinet21.oracle.com [141.146.126.237] X-Auth-Type: Internal IP X-CT-RefId: str=0001.0A090205.4E7A28F0.01AF:SCFMA922111,ss=1,re=-6.300,fgs=0 Cc: xen-devel@lists.xensource.com, xen-users@lists.xensource.com X-BeenThere: xen-devel@lists.xensource.com X-Mailman-Version: 2.1.5 Precedence: list List-Id: Xen developer discussion <xen-devel.lists.xensource.com> List-Unsubscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe> List-Post: <mailto:xen-devel@lists.xensource.com> List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help> List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=subscribe> Sender: xen-devel-bounces@lists.xensource.com Errors-To: xen-devel-bounces@lists.xensource.com On Sun, Sep 18, 2011 at 09:54:45PM -0400, jinho hwang wrote: > Hi All, > > I'm using xen 4.0.1, kernel 2.6.32.46, and pygrub to boot. It seems that Is this a new installation? Did you change anything? How did you create the ramdisk/initramdisk? > everything is ok until the last part that run-init is executing. The log > says that run-init: /sbin/init: No such file or directory... and then kernel > panic - not syncing: Attempted to kill init! I'm trying to figure out how to > solve this problem. > I mounted my image and checked the /sbin directory, init was there, but when > I boot up with xm create, /sbin directory shows no init. Weirdly, the > directory contains small number of files including modprobe. > > Please, give me any comment if you have. > > Thank you, > > Jinho > > Here is my log. > --- > Started domain Jinho (id=18) > Reserving virtual address space above 0xf5800000 > Initializing cgroup subsys cpuset > Initializing cgroup subsys cpu > Linux version 2.6.32.46 (root@jinho-Dell-DXP061) (gcc version 4.4.5 > (Ubuntu/Linaro 4.4.5-15ubuntu1) ) #4 SMP Sun Sep 18 17:17:08 EDT 2011 > KERNEL supported cpus: > Intel GenuineIntel > AMD AuthenticAMD > NSC Geode by NSC > Cyrix CyrixInstead > Centaur CentaurHauls > Transmeta GenuineTMx86 > Transmeta TransmetaCPU > UMC UMC UMC UMC > ACPI in unprivileged domain disabled > released 0 pages of unused memory > BIOS-provided physical RAM map: > Xen: 0000000000000000 - 00000000000a0000 (usable) > Xen: 00000000000a0000 - 0000000000100000 (reserved) > Xen: 0000000000100000 - 0000000020800000 (usable) > DMI not present or invalid. > last_pfn = 0x20800 max_arch_pfn = 0x1000000 > init_memory_mapping: 0000000000000000-0000000020800000 > NX (Execute Disable) protection: active > RAMDISK: 00b2b000 - 09b5b000 > 0MB HIGHMEM available. > 520MB LOWMEM available. > mapped low ram: 0 - 20800000 > low ram: 0 - 20800000 > node 0 low ram: 00000000 - 20800000 > node 0 bootmap 00007000 - 0000b100 > (11 early reservations) ==> bootmem [0000000000 - 0020800000] > #0 [0000000000 - 0000001000] BIOS data page ==> [0000000000 - > 0000001000] > #1 [0009bde000 - 0009c30000] XEN PAGETABLES ==> [0009bde000 - > 0009c30000] > #2 [0000001000 - 0000002000] EX TRAMPOLINE ==> [0000001000 - > 0000002000] > #3 [0000006000 - 0000007000] TRAMPOLINE ==> [0000006000 - > 0000007000] > #4 [0000400000 - 00009ba1c8] TEXT DATA BSS ==> [0000400000 - > 00009ba1c8] > #5 [0000b2b000 - 0009b5b000] RAMDISK ==> [0000b2b000 - > 0009b5b000] > #6 [0009b5b000 - 0009bde000] XEN START INFO ==> [0009b5b000 - > 0009bde000] > #7 [0020000000 - 0020800000] XEN EXTRA ==> [0020000000 - > 0020800000] > #8 [00009bb000 - 00009c8000] BRK ==> [00009bb000 - > 00009c8000] > #9 [0000100000 - 00001b1000] PGTABLE ==> [0000100000 - > 00001b1000] > #10 [0000007000 - 000000c000] BOOTMAP ==> [0000007000 - > 000000c000] > Zone PFN ranges: > DMA 0x00000000 -> 0x00001000 > Normal 0x00001000 -> 0x00020800 > HighMem 0x00020800 -> 0x00020800 > Movable zone start PFN for each node > early_node_map[2] active PFN ranges > 0: 0x00000000 -> 0x000000a0 > 0: 0x00000100 -> 0x00020800 > Using APIC driver default > SMP: Allowing 1 CPUs, 0 hotplug CPUs > Local APIC disabled by BIOS -- you can enable it with "lapic" > APIC: disable apic facility > Allocating PCI resources starting at 20800000 (gap: 20800000:df800000) > Booting paravirtualized kernel on Xen > Xen version: 4.0.3-rc3-pre (preserve-AD) > NR_CPUS:8 nr_cpumask_bits:8 nr_cpu_ids:1 nr_node_ids:1 > PERCPU: Embedded 15 pages/cpu @ca045000 s40344 r0 d21096 u65536 > pcpu-alloc: s40344 r0 d21096 u65536 alloc=16*4096 > pcpu-alloc: [0] 0 > Built 1 zonelists in Zone order, mobility grouping on. Total pages: 131984 > Kernel command line: root=/dev/xvda2 ro root=/dev/xvda2 ro > ip=:127.0.255.255::::eth0:dhcp > PID hash table entries: 4096 (order: 2, 16384 bytes) > Dentry cache hash table entries: 131072 (order: 7, 524288 bytes) > Inode-cache hash table entries: 65536 (order: 6, 262144 bytes) > Enabling fast FPU save and restore... done. > Enabling unmasked SIMD FPU exception support... done. > Initializing CPU#0 > Initializing HighMem for node 0 (00000000:00000000) > Memory: 363692k/532480k available (3083k kernel code, 168372k reserved, > 1707k data, 472k init, 0k highmem) > virtual kernel memory layout: > fixmap : 0xf567e000 - 0xf57ff000 (1540 kB) > pkmap : 0xf5200000 - 0xf5400000 (2048 kB) > vmalloc : 0xe1000000 - 0xf51fe000 ( 321 MB) > lowmem : 0xc0000000 - 0xe0800000 ( 520 MB) > .init : 0xc08ae000 - 0xc0924000 ( 472 kB) > .data : 0xc0702f46 - 0xc08add84 (1707 kB) > .text : 0xc0400000 - 0xc0702f46 (3083 kB) > Hierarchical RCU implementation. > NR_IRQS:2304 nr_irqs:512 > Console: colour dummy device 80x25 > console [tty0] enabled > console [hvc0] enabled > installing Xen timer for CPU 0 > Detected 2660.038 MHz processor. > Calibrating delay loop (skipped), value calculated using timer frequency.. > 5320.07 BogoMIPS (lpj=2660038) > Security Framework initialized > SELinux: Initializing. > Mount-cache hash table entries: 512 > Initializing cgroup subsys ns > Initializing cgroup subsys cpuacct > Initializing cgroup subsys devices > CPU: L1 I cache: 32K, L1 D cache: 32K > CPU: L2 cache: 4096K > CPU: Unsupported number of siblings 2 > Performance Events: unsupported p6 CPU model 15 no PMU driver, software > events only. > SMP alternatives: switching to UP code > Freeing SMP alternatives: 14k freed > cpu 0 spinlock event irq 510 > Brought up 1 CPUs > Grant table initialized > Time: 165:165:165 Date: 165/165/65 > NET: Registered protocol family 16 > PCI: setting up Xen PCI frontend stub > bio: create slab <bio-0> at 0 > ACPI: Interpreter disabled. > xen_balloon: Initialising balloon driver with page order 0. > last_pfn = 0x20800 max_arch_pfn = 0x1000000 > vgaarb: loaded > SCSI subsystem initialized > usbcore: registered new interface driver usbfs > usbcore: registered new interface driver hub > usbcore: registered new device driver usb > PCI: System does not support PCI > PCI: System does not support PCI > NetLabel: Initializing > NetLabel: domain hash size = 128 > NetLabel: protocols = UNLABELED CIPSOv4 > NetLabel: unlabeled traffic allowed by default > Switching to clocksource xen > pnp: PnP ACPI: disabled > NET: Registered protocol family 2 > IP route cache hash table entries: 8192 (order: 3, 32768 bytes) > TCP established hash table entries: 32768 (order: 6, 262144 bytes) > TCP bind hash table entries: 32768 (order: 6, 262144 bytes) > TCP: Hash tables configured (established 32768 bind 32768) > TCP reno registered > NET: Registered protocol family 1 > Trying to unpack rootfs image as initramfs... > Freeing initrd memory: 147648k freed > platform rtc_cmos: registered platform RTC device (no PNP device found) > apm: BIOS not found. > audit: initializing netlink socket (disabled) > type=2000 audit(1316396556.247:1): initialized > HugeTLB registered 2 MB page size, pre-allocated 0 pages > VFS: Disk quotas dquot_6.5.2 > Dquot-cache hash table entries: 1024 (order 0, 4096 bytes) > msgmni has been set to 998 > alg: No test for stdrng (krng) > Block layer SCSI generic (bsg) driver version 0.4 loaded (major 252) > io scheduler noop registered > io scheduler anticipatory registered > io scheduler deadline registered > io scheduler cfq registered (default) > pci_hotplug: PCI Hot Plug PCI Core version: 0.5 > acpiphp: ACPI Hot Plug PCI Controller Driver version: 0.5 > isapnp: ISA Plug & Play support disabled > Event-channel device installed. > registering netback > Non-volatile memory driver v1.3 > Linux agpgart interface v0.103 > Serial: 8250/16550 driver, 4 ports, IRQ sharing enabled > brd: module loaded > loop: module loaded > Initialising Xen virtual ethernet driver. > blkfront: xvda2: barriers enabled (tag) > ehci_hcd: USB 2.0 'Enhanced' Host Controller (EHCI) Driver > ohci_hcd: USB 1.1 'Open' Host Controller (OHCI) Driver > uhci_hcd: USB Universal Host Controller Interface driver > PNP: No PS/2 controller found. Probing ports directly. > i8042.c: No controller found. > mice: PS/2 mouse device common for all mice > rtc_cmos rtc_cmos: rtc core: registered rtc_cmos as rtc0 > device-mapper: uevent: version 1.0.3 > device-mapper: ioctl: 4.15.0-ioctl (2009-04-01) initialised: > dm-devel@redhat.com > cpuidle: using governor ladder > cpuidle: using governor menu > usbcore: registered new interface driver hiddev > usbcore: registered new interface driver usbhid > usbhid: v2.6:USB HID core driver > nf_conntrack version 0.5.0 (8192 buckets, 32768 max) > CONFIG_NF_CT_ACCT is deprecated and will be removed soon. Please use > nf_conntrack.acct=1 kernel parameter, acct=1 nf_conntrack module option or > sysctl net.netfilter.nf_conntrack_acct=1 to enable it. > ip_tables: (C) 2000-2006 Netfilter Core Team > TCP cubic registered > Initializing XFRM netlink socket > NET: Registered protocol family 17 > Bridge firewalling registered > Using IPI No-Shortcut mode > registered taskstats version 1 > blkfront: xvda1: barriers enabled (tag) > XENBUS: Device with no driver: device/console/0 > Magic number: 1:252:3141 > Freeing unused kernel memory: 472k freed > Write protecting the kernel text: 3084k > Write protecting the kernel read-only data: 1480k > Loading, please wait... > mount: mounting none on /dev failed: No such device > W: devtmpfs not available, falling back to tmpfs for /dev > Begin: Loading essential drivers ... done. > Begin: Running /scripts/init-premount ... done. > Begin: Mounting root file system ... Begin: Running /scripts/local-top ... > done. > Begin: Running /scripts/local-premount ... done. > kjournald starting. Commit interval 5 seconds > EXT3-fs: mounted filesystem with writeback data mode. > Begin: Running /scripts/local-bottom ... done. > done. > *Begin: Running /scripts/init-bottom ... done. > run-init: /sbin/init: No such file or directory > Kernel panic - not syncing: Attempted to kill init! > Pid: 1, comm: run-init Not tainted 2.6.32.46 #4 > Call Trace: > [<c06fd11c>] ? printk+0xf/0x13 > [<c06fd055>] panic+0x39/0xf1 > [<c043ff7d>] do_exit+0x5c/0x5cf > [<c04405c5>] complete_and_exit+0x0/0x17 > [<c04098a9>] syscall_call+0x7/0xb* > > > -- > Jinho Hwang > PhD Student > Department of Computer Science > The George Washington University > Washington, DC 20052 > hwang.jinho@gmail.com (email) > 276.336.0971 (Cell) > 202.994.4875 (fax) > 070.8285.6546 (myLg070) > _______________________________________________ > Xen-devel mailing list > Xen-devel@lists.xensource.com > http://lists.xensource.com/xen-devel _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel From xen-devel-bounces@lists.xensource.com Wed Sep 21 11:52:10 2011 Return-path: <xen-devel-bounces@lists.xensource.com> Envelope-to: www-data@lists.xensource.com Delivery-date: Wed, 21 Sep 2011 11:52:10 -0700 Received: from localhost ([127.0.0.1] helo=lists.colo.xensource.com) by lists.xensource.com with esmtp (Exim 4.43) id 1R6Rtx-0005B1-H4; Wed, 21 Sep 2011 11:52:09 -0700 Received: from mail182.messagelabs.com ([85.158.139.83]) by lists.xensource.com with esmtp (Exim 4.43) id 1R6Rt6-0004yA-SG for xen-devel@lists.xensource.com; Wed, 21 Sep 2011 11:51:17 -0700 X-Env-Sender: konrad@oracle.com X-Msg-Ref: server-11.tower-182.messagelabs.com!1316631072!19242176!1 X-Originating-IP: [148.87.113.117] X-StarScan-Version: 6.4.1; banners=-,-,- X-VirusChecked: Checked Received: (qmail 22322 invoked from network); 21 Sep 2011 18:51:13 -0000 Received: from rcsinet15.oracle.com (HELO rcsinet15.oracle.com) (148.87.113.117) by server-11.tower-182.messagelabs.com with DHE-RSA-AES256-SHA encrypted SMTP; 21 Sep 2011 18:51:13 -0000 Received: from acsinet21.oracle.com (acsinet21.oracle.com [141.146.126.237]) by rcsinet15.oracle.com (Switch-3.4.4/Switch-3.4.4) with ESMTP id p8LIp3jp028271 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Wed, 21 Sep 2011 18:51:05 GMT Received: from acsmt358.oracle.com (acsmt358.oracle.com [141.146.40.158]) by acsinet21.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id p8LIp2dM019481 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 21 Sep 2011 18:51:03 GMT Received: from abhmt119.oracle.com (abhmt119.oracle.com [141.146.116.71]) by acsmt358.oracle.com (8.12.11.20060308/8.12.11) with ESMTP id p8LIouUi002924; Wed, 21 Sep 2011 13:50:57 -0500 Received: from oracle.com (/209.6.55.207) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Wed, 21 Sep 2011 11:50:56 -0700 Received: by oracle.com (Postfix, from userid 1000) id E49E61362; Wed, 21 Sep 2011 14:51:02 -0400 (EDT) Date: Wed, 21 Sep 2011 14:51:02 -0400 From: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com> To: stefano.stabellini@eu.citrix.com Message-ID: <20110921185102.GJ17357@phenom.oracle.com> References: <1316608670-23167-1-git-send-email-stefano.stabellini@eu.citrix.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <1316608670-23167-1-git-send-email-stefano.stabellini@eu.citrix.com> User-Agent: Mutt/1.5.21 (2010-09-15) X-Source-IP: acsinet21.oracle.com [141.146.126.237] X-Auth-Type: Internal IP X-CT-RefId: str=0001.0A090204.4E7A321A.00C9:SCFMA922111,ss=1,re=-4.000,fgs=0 Cc: Ian.Campbell@eu.citrix.com, jeremy@goop.org, xen-devel@lists.xensource.com Subject: [Xen-devel] Re: [PATCH] xen: change XEN_PLATFORM_PCI to bool default y X-BeenThere: xen-devel@lists.xensource.com X-Mailman-Version: 2.1.5 Precedence: list List-Id: Xen developer discussion <xen-devel.lists.xensource.com> List-Unsubscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe> List-Post: <mailto:xen-devel@lists.xensource.com> List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help> List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=subscribe> Sender: xen-devel-bounces@lists.xensource.com Errors-To: xen-devel-bounces@lists.xensource.com On Wed, Sep 21, 2011 at 01:37:50PM +0100, stefano.stabellini@eu.citrix.com wrote: > From: Stefano Stabellini <stefano.stabellini@eu.citrix.com> > > The xen-platform-pci module is small and for PV on HVM guests is a How small? Does it get removed from memory if it never gets loaded? > requirement for xenbus. Ok, should it then have a depency on XenBus as well? Linus does not like the 'default y' very much. He actually dislikes it quite much as I found when he tore Dan's behind about cleancache. .. so I think making it 'default n' is a better option or perhaps making it depend on some other functionality? Or perhaps just remove the tristate/bool altogether so it gets activated if XEN_PVHVM is set? Or remove the XEN_PLATFORM_PCI config option completly and make the config files that build this driver be CONFIG_XENPVHM dependent? > > Signed-off-by: Stefano Stabellini <stefano.stabellini@eu.citrix.com> > --- > drivers/xen/Kconfig | 4 ++-- > 1 files changed, 2 insertions(+), 2 deletions(-) > > diff --git a/drivers/xen/Kconfig b/drivers/xen/Kconfig > index 5f7ff8e..a64b8e8 100644 > --- a/drivers/xen/Kconfig > +++ b/drivers/xen/Kconfig > @@ -138,9 +138,9 @@ config XEN_GRANT_DEV_ALLOC > or as part of an inter-domain shared memory channel. > > config XEN_PLATFORM_PCI > - tristate "xen platform pci device driver" > + bool "xen platform pci device driver" > depends on XEN_PVHVM && PCI > - default m > + default y > help > Driver for the Xen PCI Platform device: it is responsible for > initializing xenbus and grant_table when running in a Xen HVM > -- > 1.7.2.3 _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel From xen-devel-bounces@lists.xensource.com Wed Sep 21 12:00:09 2011 Return-path: <xen-devel-bounces@lists.xensource.com> Envelope-to: www-data@lists.xensource.com Delivery-date: Wed, 21 Sep 2011 12:00:09 -0700 Received: from localhost ([127.0.0.1] helo=lists.colo.xensource.com) by lists.xensource.com with esmtp (Exim 4.43) id 1R6S1e-0006zq-WF; Wed, 21 Sep 2011 12:00:08 -0700 Received: from mail174.messagelabs.com ([85.158.138.51]) by lists.xensource.com with esmtp (Exim 4.43) id 1R6RzC-0006fa-HD for xen-devel@lists.xensource.com; Wed, 21 Sep 2011 11:57:35 -0700 X-Env-Sender: jeremy@goop.org X-Msg-Ref: server-2.tower-174.messagelabs.com!1316631449!32275294!1 X-Originating-IP: [74.207.240.146] X-StarScan-Version: 6.4.1; banners=-,-,- X-VirusChecked: Checked Received: (qmail 6534 invoked from network); 21 Sep 2011 18:57:31 -0000 Received: from claw.goop.org (HELO claw.goop.org) (74.207.240.146) by server-2.tower-174.messagelabs.com with DHE-RSA-AES256-SHA encrypted SMTP; 21 Sep 2011 18:57:31 -0000 Received: from saboo.goop.org (unknown [IPv6:2001:470:1f05:899:344c:17ff:febf:2ab]) (Authenticated sender: smtp-saboo) by claw.goop.org (Postfix) with ESMTPSA id 89C359440; Wed, 21 Sep 2011 11:57:28 -0700 (PDT) Received: from saboo.goop.org (localhost [IPv6:::1]) by saboo.goop.org (Postfix) with ESMTP id 718D720380; Wed, 21 Sep 2011 11:57:24 -0700 (PDT) Message-ID: <4E7A3394.3090806@goop.org> Date: Wed, 21 Sep 2011 11:57:24 -0700 From: Jeremy Fitzhardinge <jeremy@goop.org> User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:6.0.2) Gecko/20110906 Thunderbird/6.0.2 MIME-Version: 1.0 To: Stefano Stabellini <stefano.stabellini@eu.citrix.com> Subject: Re: [Xen-devel] Re: [PATCH 0/6] xen: don't call vmalloc_sync_all() when mapping foreign pages References: <1316090411-22608-1-git-send-email-david.vrabel@citrix.com> <4E727017.4030001@goop.org> <alpine.DEB.2.00.1109211124050.8700@kaball-desktop> In-Reply-To: <alpine.DEB.2.00.1109211124050.8700@kaball-desktop> X-Enigmail-Version: 1.3.1 Content-Type: text/plain; charset=ISO-8859-15 Content-Transfer-Encoding: 7bit Cc: Andrew Morton <akpm@linux-foundation.org>, "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>, "linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>, Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>, David Vrabel <david.vrabel@citrix.com> X-BeenThere: xen-devel@lists.xensource.com X-Mailman-Version: 2.1.5 Precedence: list List-Id: Xen developer discussion <xen-devel.lists.xensource.com> List-Unsubscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe> List-Post: <mailto:xen-devel@lists.xensource.com> List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help> List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=subscribe> Sender: xen-devel-bounces@lists.xensource.com Errors-To: xen-devel-bounces@lists.xensource.com On 09/21/2011 03:42 AM, Stefano Stabellini wrote: > On Thu, 15 Sep 2011, Jeremy Fitzhardinge wrote: >> This series is relying on regular ram mappings are already synced to all >> tasks, but I'm not sure that's necessarily guaranteed (for example, if >> you hotplug new memory into the domain, the new pages won't be mapped >> into every mm unless they're synced). > the series is using GFP_KERNEL, so this problem shouldn't occur, right? What properties do you think GFP_KERNEL guarantees? J _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel From xen-devel-bounces@lists.xensource.com Wed Sep 21 12:07:31 2011 Return-path: <xen-devel-bounces@lists.xensource.com> Envelope-to: www-data@lists.xensource.com Delivery-date: Wed, 21 Sep 2011 12:07:31 -0700 Received: from localhost ([127.0.0.1] helo=lists.colo.xensource.com) by lists.xensource.com with esmtp (Exim 4.43) id 1R6S8p-0007pr-MH; Wed, 21 Sep 2011 12:07:31 -0700 Received: from mail27.messagelabs.com ([193.109.254.147]) by lists.xensource.com with esmtp (Exim 4.43) id 1R6S1x-00070m-IZ for xen-devel@lists.xensource.com; Wed, 21 Sep 2011 12:00:36 -0700 X-Env-Sender: sven.koehler@gmail.com X-Msg-Ref: server-3.tower-27.messagelabs.com!1316631598!40610325!1 X-Originating-IP: [209.85.161.43] X-StarScan-Version: 6.4.1; banners=-,-,- X-VirusChecked: Checked Received: (qmail 13028 invoked from network); 21 Sep 2011 18:59:59 -0000 Received: from mail-fx0-f43.google.com (HELO mail-fx0-f43.google.com) (209.85.161.43) by server-3.tower-27.messagelabs.com with RC4-SHA encrypted SMTP; 21 Sep 2011 18:59:59 -0000 Received: by fxh19 with SMTP id 19so2446147fxh.30 for <xen-devel@lists.xensource.com>; Wed, 21 Sep 2011 12:00:22 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:x-enigmail-version:content-type; bh=ivbf3iFvtnQJSG7F4hAZ3bZCP2geY0WbQBN2bAgPWlE=; b=nAZM/LGit3ePjEfVOlrdb5qp2rPWsJa0WIe63rmxTFxKnsuin2pQrQAznuCJX3SGms AvWDKd4FA4BQoYn8mNYgnXmsmwPrCd0frNaA9GisSQ9bwMaQyDDthvIydd7tDnYCvs+G AxXeGjNx3QgzE/oz6goABH8JXpbLrXe3Yv1Vw= Received: by 10.223.35.18 with SMTP id n18mr1506254fad.105.1316631621889; Wed, 21 Sep 2011 12:00:21 -0700 (PDT) Received: from [10.1.2.24] (31-18-61-177-dynip.superkabel.de. [31.18.61.177]) by mx.google.com with ESMTPS id b10sm5082518fam.1.2011.09.21.12.00.20 (version=SSLv3 cipher=OTHER); Wed, 21 Sep 2011 12:00:20 -0700 (PDT) Message-ID: <4E7A34D8.1010906@gmail.com> Date: Wed, 21 Sep 2011 21:02:48 +0200 From: =?ISO-8859-1?Q?Sven_K=F6hler?= <sven.koehler@gmail.com> User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:6.0) Gecko/20110918 Thunderbird/6.0 MIME-Version: 1.0 To: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com> Subject: Re: [Xen-devel] Re: 3.0.4 and 3.1-rc4 based dom0 won't boot with acpi=off References: <j4gp1v$oog$1@dough.gmane.org> <20110911002807.GA9989@oracle.com> <4E6C0473.8090905@gmail.com> <20110912150606.GC15778@oracle.com> <4E764607.80703@gmail.com> <20110921180624.GD17357@phenom.oracle.com> In-Reply-To: <20110921180624.GD17357@phenom.oracle.com> X-Enigmail-Version: 1.3 Cc: xen-devel@lists.xensource.com X-BeenThere: xen-devel@lists.xensource.com X-Mailman-Version: 2.1.5 Precedence: list List-Id: Xen developer discussion <xen-devel.lists.xensource.com> List-Unsubscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe> List-Post: <mailto:xen-devel@lists.xensource.com> List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help> List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=subscribe> Content-Type: multipart/mixed; boundary="===============0766099757==" Sender: xen-devel-bounces@lists.xensource.com Errors-To: xen-devel-bounces@lists.xensource.com This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --===============0766099757== Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="------------enig6BDBED3626AB395B1384E088" This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enig6BDBED3626AB395B1384E088 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Am 21.09.2011 20:06, schrieb Konrad Rzeszutek Wilk: > On Sun, Sep 18, 2011 at 09:27:03PM +0200, Sven K=F6hler wrote: >> >> Would you mind changing it from 100 to 10? >=20 > Does it fix the problem with this particular board? If so, then that so= unds > like we should do. I still have to check that. I will let you know. (I was hoping, that being more similar to what Linux 3.x does, would be a sufficient reason.) >> Now taking a look at Xen 3.4.2, the default reboot sequence is a bit >> different. It's >> >> ACPI, KBD, ACPI, KBD, ACPI, KBD, ACPI, KBD, .... >> >> No triple fault reset attempts. >=20 > Ah, could be that we just never had it implemented then. You never had what implemented? TRIPLE reset was implemented. However, by the default it was never used. Regards, Sven --------------enig6BDBED3626AB395B1384E088 Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.17 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAk56NNgACgkQ7Ww7FjRBE4CXZACfZRzHFgwHZ4h7zeA8IFnVvuzi JvUAn3+oggm57pAgG0arR+R6Y2/xxxMb =Mayn -----END PGP SIGNATURE----- --------------enig6BDBED3626AB395B1384E088-- --===============0766099757== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel --===============0766099757==-- From xen-devel-bounces@lists.xensource.com Wed Sep 21 12:13:10 2011 Return-path: <xen-devel-bounces@lists.xensource.com> Envelope-to: www-data@lists.xensource.com Delivery-date: Wed, 21 Sep 2011 12:13:10 -0700 Received: from localhost ([127.0.0.1] helo=lists.colo.xensource.com) by lists.xensource.com with esmtp (Exim 4.43) id 1R6SEI-0000XB-4a; Wed, 21 Sep 2011 12:13:10 -0700 Received: from mail21.messagelabs.com ([85.158.143.35]) by lists.xensource.com with esmtp (Exim 4.43) id 1R6S9b-0007zB-FY for xen-devel@lists.xensource.com; Wed, 21 Sep 2011 12:08:21 -0700 X-Env-Sender: Ian.Campbell@eu.citrix.com X-Msg-Ref: server-7.tower-21.messagelabs.com!1316632066!55739873!1 X-Originating-IP: [62.200.22.115] X-StarScan-Version: 6.4.1; banners=-,-,- X-VirusChecked: Checked Received: (qmail 10484 invoked from network); 21 Sep 2011 19:07:46 -0000 Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115) by server-7.tower-21.messagelabs.com with RC4-SHA encrypted SMTP; 21 Sep 2011 19:07:46 -0000 X-IronPort-AV: E=Sophos;i="4.68,418,1312156800"; d="scan'208";a="7988739" Received: from lonpmailmx01.citrite.net ([10.30.203.162]) by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5; 21 Sep 2011 19:08:16 +0000 Received: from [127.0.0.1] (10.80.16.67) by smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id 8.3.137.0; Wed, 21 Sep 2011 20:08:15 +0100 From: Ian Campbell <Ian.Campbell@eu.citrix.com> To: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com> In-Reply-To: <20110921185102.GJ17357@phenom.oracle.com> References: <1316608670-23167-1-git-send-email-stefano.stabellini@eu.citrix.com> <20110921185102.GJ17357@phenom.oracle.com> Content-Type: text/plain; charset="ISO-8859-1" Organization: Citrix Systems, Inc. Date: Wed, 21 Sep 2011 20:08:15 +0100 Message-ID: <1316632095.5182.33.camel@dagon.hellion.org.uk> MIME-Version: 1.0 X-Mailer: Evolution 2.32.3 Content-Transfer-Encoding: 7bit Cc: "jeremy@goop.org" <jeremy@goop.org>, "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>, Stefano Stabellini <Stefano.Stabellini@eu.citrix.com> Subject: [Xen-devel] Re: [PATCH] xen: change XEN_PLATFORM_PCI to bool default y X-BeenThere: xen-devel@lists.xensource.com X-Mailman-Version: 2.1.5 Precedence: list List-Id: Xen developer discussion <xen-devel.lists.xensource.com> List-Unsubscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe> List-Post: <mailto:xen-devel@lists.xensource.com> List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help> List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=subscribe> Sender: xen-devel-bounces@lists.xensource.com Errors-To: xen-devel-bounces@lists.xensource.com On Wed, 2011-09-21 at 19:51 +0100, Konrad Rzeszutek Wilk wrote: > On Wed, Sep 21, 2011 at 01:37:50PM +0100, stefano.stabellini@eu.citrix.com wrote: > > From: Stefano Stabellini <stefano.stabellini@eu.citrix.com> > > > > The xen-platform-pci module is small and for PV on HVM guests is a > > How small? IIRC it is single digit numbers of kb. > Does it get removed from memory if it never gets loaded? > > > requirement for xenbus. > > Ok, should it then have a depency on XenBus as well? xenbus can't be a module (which is why allowing platform-pci to be is causing problems). > Linus does not like the 'default y' very much. He actually dislikes > it quite much as I found when he tore Dan's behind about cleancache. In particular case the option is gated on a dependency on another Xen option (PVHVM) which doesn't default on. But if you do select PVHVM you certainly want this option, so I think that's ok (why else would 'default y' even exist?) > .. so I think making it 'default n' is a better option or perhaps > making it depend on some other functionality? Or perhaps just remove > the tristate/bool altogether so it gets activated if XEN_PVHVM > is set? > > Or remove the XEN_PLATFORM_PCI config option completly and make the > config files that build this driver be CONFIG_XENPVHM dependent? That would work too. Even better would be to make it an invisible Kconfig symbol which PVHVM just selects. Ian. > > > > > Signed-off-by: Stefano Stabellini <stefano.stabellini@eu.citrix.com> > > --- > > drivers/xen/Kconfig | 4 ++-- > > 1 files changed, 2 insertions(+), 2 deletions(-) > > > > diff --git a/drivers/xen/Kconfig b/drivers/xen/Kconfig > > index 5f7ff8e..a64b8e8 100644 > > --- a/drivers/xen/Kconfig > > +++ b/drivers/xen/Kconfig > > @@ -138,9 +138,9 @@ config XEN_GRANT_DEV_ALLOC > > or as part of an inter-domain shared memory channel. > > > > config XEN_PLATFORM_PCI > > - tristate "xen platform pci device driver" > > + bool "xen platform pci device driver" > > depends on XEN_PVHVM && PCI > > - default m > > + default y > > help > > Driver for the Xen PCI Platform device: it is responsible for > > initializing xenbus and grant_table when running in a Xen HVM > > -- > > 1.7.2.3 _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel From xen-devel-bounces@lists.xensource.com Wed Sep 21 12:31:04 2011 Return-path: <xen-devel-bounces@lists.xensource.com> Envelope-to: www-data@lists.xensource.com Delivery-date: Wed, 21 Sep 2011 12:31:04 -0700 Received: from localhost ([127.0.0.1] helo=lists.colo.xensource.com) by lists.xensource.com with esmtp (Exim 4.43) id 1R6SVc-0001E8-4Z; Wed, 21 Sep 2011 12:31:04 -0700 Received: from mail21.messagelabs.com ([85.158.143.35]) by lists.xensource.com with esmtp (Exim 4.43) id 1R6SV4-00010C-Bz for xen-devel@lists.xensource.com; Wed, 21 Sep 2011 12:30:30 -0700 X-Env-Sender: konrad@oracle.com X-Msg-Ref: server-8.tower-21.messagelabs.com!1316633409!59864176!1 X-Originating-IP: [148.87.113.117] X-StarScan-Version: 6.4.1; banners=-,-,- X-VirusChecked: Checked Received: (qmail 18791 invoked from network); 21 Sep 2011 19:30:11 -0000 Received: from rcsinet15.oracle.com (HELO rcsinet15.oracle.com) (148.87.113.117) by server-8.tower-21.messagelabs.com with DHE-RSA-AES256-SHA encrypted SMTP; 21 Sep 2011 19:30:11 -0000 Received: from rtcsinet22.oracle.com (rtcsinet22.oracle.com [66.248.204.30]) by rcsinet15.oracle.com (Switch-3.4.4/Switch-3.4.4) with ESMTP id p8LJT3q0015450 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Wed, 21 Sep 2011 19:29:05 GMT Received: from acsmt356.oracle.com (acsmt356.oracle.com [141.146.40.156]) by rtcsinet22.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id p8LJT1aT011815 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 21 Sep 2011 19:29:01 GMT Received: from abhmt109.oracle.com (abhmt109.oracle.com [141.146.116.61]) by acsmt356.oracle.com (8.12.11.20060308/8.12.11) with ESMTP id p8LJStJL028991; Wed, 21 Sep 2011 14:28:55 -0500 Received: from oracle.com (/209.6.55.207) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Wed, 21 Sep 2011 12:28:55 -0700 Received: by oracle.com (Postfix, from userid 1000) id D7E081362; Wed, 21 Sep 2011 15:29:00 -0400 (EDT) Date: Wed, 21 Sep 2011 15:29:00 -0400 From: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com> To: Jeremy Fitzhardinge <jeremy@goop.org> Subject: Re: [Xen-devel] RE: [PATCH 5/7] xen/acpi: Domain0 acpi parser related platform hypercall Message-ID: <20110921192859.GA2606@phenom.oracle.com> References: <1314815484-4668-1-git-send-email-konrad.wilk@oracle.com> <1314815484-4668-6-git-send-email-konrad.wilk@oracle.com> <9F57BF860713DF4BA3EFA4F8C6DFEDAC16F3F665@ORSMSX101.amr.corp.intel.com> <4E67A9E7.2020802@goop.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <4E67A9E7.2020802@goop.org> User-Agent: Mutt/1.5.21 (2010-09-15) X-Source-IP: rtcsinet22.oracle.com [66.248.204.30] X-CT-RefId: str=0001.0A090206.4E7A3B04.0035,ss=1,re=0.000,fgs=0 Cc: "Brown, Len" <len.brown@intel.com>, "Tian, Kevin" <kevin.tian@intel.com>, "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>, "keir@xen.org" <keir@xen.org>, "Wang, Shane" <shane.wang@intel.com>, "Cihula, Joseph" <joseph.cihula@intel.com>, "x86@kernel.org" <x86@kernel.org>, "linux-acpi@vger.kernel.org" <linux-acpi@vger.kernel.org>, "tboot-devel@lists.sourceforge.net" <tboot-devel@lists.sourceforge.net>, Fitzhardinge <jeremy.fitzhardinge@citrix.com>, "Yu, Ke" <ke.yu@intel.com>, "hpa@zytor.com" <hpa@zytor.com>, "liang.tang@oracle.com" <liang.tang@oracle.com>, "linux-pm@lists.linux-foundation.org" <linux-pm@lists.linux-foundation.org>, "tglx@linutronix.de" <tglx@linutronix.de> X-BeenThere: xen-devel@lists.xensource.com X-Mailman-Version: 2.1.5 Precedence: list List-Id: Xen developer discussion <xen-devel.lists.xensource.com> List-Unsubscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe> List-Post: <mailto:xen-devel@lists.xensource.com> List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help> List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=subscribe> Sender: xen-devel-bounces@lists.xensource.com Errors-To: xen-devel-bounces@lists.xensource.com On Wed, Sep 07, 2011 at 10:29:11AM -0700, Jeremy Fitzhardinge wrote: > On 09/06/2011 10:50 PM, Cihula, Joseph wrote: > >> From: Konrad Rzeszutek Wilk [mailto:konrad.wilk@oracle.com] > >> Sent: Wednesday, August 31, 2011 11:31 AM > >> > >> From: Yu Ke <ke.yu@intel.com> > >> > >> This patches implements the xen_platform_op hypercall, to pass the parsed ACPI info to hypervisor. > >> > >> Signed-off-by: Yu Ke <ke.yu@intel.com> > >> Signed-off-by: Tian Kevin <kevin.tian@intel.com> > >> Signed-off-by: Jeremy Fitzhardinge <jeremy.fitzhardinge@citrix.com> > >> [v1: Added DEFINE_GUEST.. in appropiate headers] > >> [v2: Ripped out typedefs] > >> Signed-off-by: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com> > >> --- > >> arch/ia64/include/asm/xen/interface.h | 1 + > >> arch/x86/include/asm/xen/interface.h | 1 + > >> include/xen/interface/platform.h | 320 +++++++++++++++++++++++++++++++++ > >> include/xen/interface/xen.h | 1 + > >> 4 files changed, 323 insertions(+), 0 deletions(-) create mode 100644 > >> include/xen/interface/platform.h > >> > >> diff --git a/arch/ia64/include/asm/xen/interface.h b/arch/ia64/include/asm/xen/interface.h > >> index e951e74..1d2427d 100644 > >> --- a/arch/ia64/include/asm/xen/interface.h > >> +++ b/arch/ia64/include/asm/xen/interface.h > >> @@ -76,6 +76,7 @@ DEFINE_GUEST_HANDLE(char); DEFINE_GUEST_HANDLE(int); > >> DEFINE_GUEST_HANDLE(long); DEFINE_GUEST_HANDLE(void); > >> +DEFINE_GUEST_HANDLE(uint64_t); > >> > >> typedef unsigned long xen_pfn_t; > >> DEFINE_GUEST_HANDLE(xen_pfn_t); > >> diff --git a/arch/x86/include/asm/xen/interface.h b/arch/x86/include/asm/xen/interface.h > >> index 5d4922a..a1f2db5 100644 > >> --- a/arch/x86/include/asm/xen/interface.h > >> +++ b/arch/x86/include/asm/xen/interface.h > >> @@ -55,6 +55,7 @@ DEFINE_GUEST_HANDLE(char); DEFINE_GUEST_HANDLE(int); > >> DEFINE_GUEST_HANDLE(long); DEFINE_GUEST_HANDLE(void); > >> +DEFINE_GUEST_HANDLE(uint64_t); > >> #endif > >> > >> #ifndef HYPERVISOR_VIRT_START > >> diff --git a/include/xen/interface/platform.h b/include/xen/interface/platform.h > >> new file mode 100644 > >> index 0000000..c168468 > >> --- /dev/null > >> +++ b/include/xen/interface/platform.h > > Why are you adding so many new hypercalls that aren't being used in this patchset? > > May as well bring in all the platform-related hypercall definitions at > once rather than be piecemeal. Actually, I think making it piecemeal might be easier. As in 1). Not all of the hypercalls are going to be upstreamed. 2). It gives a nice history/idea of what is actually implemented when seaching the code. 3). git annotate can give precise git commits for when an functionality was added. But maybe I am just overthinking it. _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel From xen-devel-bounces@lists.xensource.com Wed Sep 21 12:43:47 2011 Return-path: <xen-devel-bounces@lists.xensource.com> Envelope-to: www-data@lists.xensource.com Delivery-date: Wed, 21 Sep 2011 12:43:47 -0700 Received: from localhost ([127.0.0.1] helo=lists.colo.xensource.com) by lists.xensource.com with esmtp (Exim 4.43) id 1R6Shv-0001ul-IH; Wed, 21 Sep 2011 12:43:47 -0700 Received: from mail27.messagelabs.com ([193.109.254.147]) by lists.xensource.com with esmtp (Exim 4.43) id 1R6ShL-0001hn-0J for xen-devel@lists.xensource.com; Wed, 21 Sep 2011 12:43:11 -0700 X-Env-Sender: burns.me.uk@gmail.com X-Msg-Ref: server-10.tower-27.messagelabs.com!1316634166!36701630!1 X-Originating-IP: [209.85.212.47] X-StarScan-Version: 6.4.1; banners=-,-,- X-VirusChecked: Checked Received: (qmail 25396 invoked from network); 21 Sep 2011 19:42:47 -0000 Received: from mail-vw0-f47.google.com (HELO mail-vw0-f47.google.com) (209.85.212.47) by server-10.tower-27.messagelabs.com with RC4-SHA encrypted SMTP; 21 Sep 2011 19:42:47 -0000 Received: by vwe42 with SMTP id 42so1386254vwe.6 for <xen-devel@lists.xensource.com>; Wed, 21 Sep 2011 12:43:06 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=PE1Xv6w18580SVRu//bmhmAtpUWzyFlH+d0yZuH3Akw=; b=jRNQ2ihb1zVfHXniwCQ8OY5ZEyS5LnBY0V4b79IJ4Ol1YeNOZ7qtvmy3djpPY9YDFM se8upjvWxA5JA6HDIL6pysQXgWBDvMnxCQdfsAcTc9GJhE6r5RmehREXbouiGBD8/hK/ Cmzn0q7aQng0FGRwQOPdz9XssK9nlbL60hEsQ= MIME-Version: 1.0 Received: by 10.52.25.7 with SMTP id y7mr996030vdf.16.1316634186744; Wed, 21 Sep 2011 12:43:06 -0700 (PDT) Received: by 10.52.169.201 with HTTP; Wed, 21 Sep 2011 12:43:06 -0700 (PDT) In-Reply-To: <20110921180313.GB17357@phenom.oracle.com> References: <201107231426.56811.jim_burn@bellsouth.net> <1342436.B0x3ddQn4U@dell4550> <20110913085559.GG12984@reaktio.net> <1856036.eYCcuDQrZC@dell4550> <20110914090806.GD25628@phenom.oracle.com> <20110914105711.GA16284@phenom.oracle.com> <CAE1-PRfFwJh1WotLL5GD+L=Vn-zwZctqa+Rhzs2tqMavw1j-WQ@mail.gmail.com> <CAE1-PRdQ37dg6BX+1JGA2mvviNu8t-iAZHVoDKrvg53H_jyztw@mail.gmail.com> <20110921180313.GB17357@phenom.oracle.com> Date: Wed, 21 Sep 2011 20:43:06 +0100 X-Google-Sender-Auth: Vq32VsDL-nhPFsC64AFQfvJfoHM Message-ID: <CAE1-PRcBZpmX-c8Z-C50g83_S4Y1k+P7aQzzhWEYU4Pwo0LqMQ@mail.gmail.com> Subject: Re: [Xen-devel] Re: [Xen-users] Continuing BUG:-iness booting Fedora Rawhide 3.1.0-rc's (was Summary: Experiences setting up a debug serial port) From: Andy Burns <xen.lists@burns.me.uk> To: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: xen-devel@lists.xensource.com X-BeenThere: xen-devel@lists.xensource.com X-Mailman-Version: 2.1.5 Precedence: list List-Id: Xen developer discussion <xen-devel.lists.xensource.com> List-Unsubscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe> List-Post: <mailto:xen-devel@lists.xensource.com> List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help> List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=subscribe> Sender: xen-devel-bounces@lists.xensource.com Errors-To: xen-devel-bounces@lists.xensource.com On 21 September 2011 19:03, Konrad Rzeszutek Wilk <konrad.wilk@oracle.com> wrote: >> [ =A0 =A00.615589] usbcore: registered new interface driver hub >> [ =A0 =A00.615589] usbcore: registered new device driver usb >> [ =A0 =A00.615948] PCI: Using ACPI for IRQ routing >> (XEN) mm.c:4976:d0 Global bit is set to kernel page fffff81b8e >> (XEN) mm.c:4976:d0 Global bit is set to kernel page fffff81b8e >> (XEN) mm.c:4976:d0 Global bit is set to kernel page fffff81118 >> (XEN) mm.c:4976:d0 Global bit is set to kernel page fffff81117 >> (XEN) domain_crash_sync called from entry.S >> (XEN) Domain 0 (vcpu#0) crashed on cpu#0: >> (XEN) ----[ Xen-4.1.1 =A0x86_64 =A0debug=3Dn =A0Not tainted ]---- >> (XEN) CPU: =A0 =A00 >> (XEN) RIP: =A0 =A0e033:[<ffffffff81118d96>] >> (XEN) RFLAGS: 0000000000010282 =A0 EM: 0 =A0 CONTEXT: pv guest >> (XEN) rax: 0000000000000080 =A0 rbx: ffff880163985480 =A0 rcx: 000000000= 0000040 >> (XEN) rdx: 0040000000000080 =A0 rsi: ffff880163985480 =A0 rdi: ffff88016= 3985480 >> (XEN) rbp: ffff880163dfaff0 =A0 rsp: ffff880163dfafd0 =A0 r8: =A00000001= 373ffffff >> (XEN) r9: =A0ffffffff81b8e7fd =A0 r10: 0000ffff00066c0a =A0 r11: 0000000= 080000000 >> (XEN) r12: ffffffff81a1cbd0 =A0 r13: ffffffff81b8e7fd =A0 r14: 000000100= 0000000 >> (XEN) r15: ffffffff81a1cbd0 =A0 cr0: 000000008005003b =A0 cr4: 000000000= 00026f0 >> (XEN) cr3: 0000000221a05000 =A0 cr2: 000000137400002f >> (XEN) ds: 0000 =A0 es: 0000 =A0 fs: 0000 =A0 gs: 0000 =A0 ss: e02b =A0 c= s: e033 > > That is fixed in the latest Linus tree. You might need this patch as well= : > =A0 =A0xen/e820: if there is no dom0_mem=3D, don't tweak extra_pages. Yep, can confirm that adding a dom0_mem=3D limit prevents the crash, will build an -rc6 kernel with both the mutex patch and the don't tweak extra pages patch later just to double check . _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel From xen-devel-bounces@lists.xensource.com Wed Sep 21 13:06:33 2011 Return-path: <xen-devel-bounces@lists.xensource.com> Envelope-to: www-data@lists.xensource.com Delivery-date: Wed, 21 Sep 2011 13:06:33 -0700 Received: from localhost ([127.0.0.1] helo=lists.colo.xensource.com) by lists.xensource.com with esmtp (Exim 4.43) id 1R6T3v-0002qf-L8; Wed, 21 Sep 2011 13:06:31 -0700 Received: from mail174.messagelabs.com ([85.158.138.51]) by lists.xensource.com with esmtp (Exim 4.43) id 1R6T1e-0002ck-5s for xen-devel@lists.xensource.com; Wed, 21 Sep 2011 13:04:18 -0700 X-Env-Sender: Ian.Jackson@eu.citrix.com X-Msg-Ref: server-6.tower-174.messagelabs.com!1316635446!30133348!1 X-Originating-IP: [62.200.22.115] X-StarScan-Version: 6.4.1; banners=-,-,- X-VirusChecked: Checked Received: (qmail 13795 invoked from network); 21 Sep 2011 20:04:07 -0000 Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115) by server-6.tower-174.messagelabs.com with RC4-SHA encrypted SMTP; 21 Sep 2011 20:04:07 -0000 X-IronPort-AV: E=Sophos;i="4.68,419,1312156800"; d="scan'208";a="7989293" Received: from lonpmailmx01.citrite.net ([10.30.203.162]) by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5; 21 Sep 2011 20:04:06 +0000 Received: from woking.xci-test.com (10.80.248.135) by smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id 8.3.137.0; Wed, 21 Sep 2011 21:04:06 +0100 Received: from osstest by woking.xci-test.com with local (Exim 4.69) (envelope-from <ian.jackson@eu.citrix.com>) id 1R6T1Z-00059I-6t; Wed, 21 Sep 2011 21:04:05 +0100 To: xen-devel@lists.xensource.com Message-ID: <osstest-8992-mainreport@xen.org> From: xen.org <ian.jackson@eu.citrix.com> Date: Wed, 21 Sep 2011 21:04:05 +0100 MIME-Version: 1.0 Content-Type: text/plain Cc: ian.jackson@eu.citrix.com Subject: [Xen-devel] [xen-4.1-testing test] 8992: tolerable FAIL - PUSHED X-BeenThere: xen-devel@lists.xensource.com X-Mailman-Version: 2.1.5 Precedence: list List-Id: Xen developer discussion <xen-devel.lists.xensource.com> List-Unsubscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe> List-Post: <mailto:xen-devel@lists.xensource.com> List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help> List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=subscribe> Sender: xen-devel-bounces@lists.xensource.com Errors-To: xen-devel-bounces@lists.xensource.com flight 8992 xen-4.1-testing real [real] http://www.chiark.greenend.org.uk/~xensrcts/logs/8992/ Failures :-/ but no regressions. Tests which did not succeed, but are not blocking, including regressions (tests previously passed) regarded as allowable: test-amd64-amd64-xl-pcipt-intel 9 guest-start fail never pass test-amd64-i386-rhel6hvm-amd 9 guest-start.2 fail never pass test-amd64-i386-rhel6hvm-intel 9 guest-start.2 fail never pass test-amd64-i386-win 16 leak-check/check fail never pass test-amd64-i386-win-vcpus1 16 leak-check/check fail never pass test-amd64-amd64-xl-win 13 guest-stop fail never pass test-amd64-i386-xl-win-vcpus1 13 guest-stop fail never pass test-amd64-amd64-win 16 leak-check/check fail never pass test-i386-i386-xl-win 13 guest-stop fail never pass test-i386-i386-win 16 leak-check/check fail never pass version targeted for testing: xen 2112db7c68b3 baseline version: xen 7d13e08b5120 ------------------------------------------------------------ People who touched revisions under test: Ian Campbell <ian.campbell@citrix.com> Ian Jackson <ian.jackson@eu.citrix.com> Jan Beulich <jbeulich@suse.com> ------------------------------------------------------------ jobs: build-amd64 pass build-i386 pass build-amd64-oldkern pass build-i386-oldkern pass build-amd64-pvops pass build-i386-pvops pass test-amd64-amd64-xl pass test-amd64-i386-xl pass test-i386-i386-xl pass test-amd64-i386-rhel6hvm-amd fail test-amd64-i386-xl-credit2 pass test-amd64-amd64-xl-pcipt-intel fail test-amd64-i386-rhel6hvm-intel fail test-amd64-i386-xl-multivcpu pass test-amd64-amd64-pair pass test-amd64-i386-pair pass test-i386-i386-pair pass test-amd64-amd64-pv pass test-amd64-i386-pv pass test-i386-i386-pv pass test-amd64-amd64-xl-sedf pass test-amd64-i386-win-vcpus1 fail test-amd64-i386-xl-win-vcpus1 fail test-amd64-amd64-win fail test-amd64-i386-win fail test-i386-i386-win fail test-amd64-amd64-xl-win fail test-i386-i386-xl-win fail ------------------------------------------------------------ sg-report-flight on woking.cam.xci-test.com logs: /home/xc_osstest/logs images: /home/xc_osstest/images Logs, config files, etc. are available at http://www.chiark.greenend.org.uk/~xensrcts/logs Test harness code can be found at http://xenbits.xensource.com/gitweb?p=osstest.git;a=summary Pushing revision : + branch=xen-4.1-testing + revision=2112db7c68b3 + . cri-lock-repos ++ . cri-common +++ umask 002 +++ getconfig Repos +++ perl -e ' use Osstest; readconfigonly(); print $c{Repos} or die $!; ' ++ repos=/export/home/osstest/repos ++ repos_lock=/export/home/osstest/repos/lock ++ '[' x '!=' x/export/home/osstest/repos/lock ']' ++ OSSTEST_REPOS_LOCK_LOCKED=/export/home/osstest/repos/lock ++ exec with-lock-ex -w /export/home/osstest/repos/lock ./ap-push xen-4.1-testing 2112db7c68b3 + branch=xen-4.1-testing + revision=2112db7c68b3 + . cri-lock-repos ++ . cri-common +++ umask 002 +++ getconfig Repos +++ perl -e ' use Osstest; readconfigonly(); print $c{Repos} or die $!; ' ++ repos=/export/home/osstest/repos ++ repos_lock=/export/home/osstest/repos/lock ++ '[' x/export/home/osstest/repos/lock '!=' x/export/home/osstest/repos/lock ']' + : xen@xenbits.xensource.com + : xen@xenbits.xensource.com:git/linux-pvops + : master + : tested/2.6.39.x + case "$branch" in + cd /export/home/osstest/repos/xen-4.1-testing.hg + hg push -r 2112db7c68b3 ssh://xen@xenbits.xensource.com/HG/xen-4.1-testing.hg pushing to ssh://xen@xenbits.xensource.com/HG/xen-4.1-testing.hg searching for changes remote: adding changesets remote: adding manifests remote: adding file changes remote: added 1 changesets with 1 changes to 1 files _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel From xen-devel-bounces@lists.xensource.com Wed Sep 21 13:07:55 2011 Return-path: <xen-devel-bounces@lists.xensource.com> Envelope-to: www-data@lists.xensource.com Delivery-date: Wed, 21 Sep 2011 13:07:55 -0700 Received: from localhost ([127.0.0.1] helo=lists.colo.xensource.com) by lists.xensource.com with esmtp (Exim 4.43) id 1R6T5F-0003Da-V8; Wed, 21 Sep 2011 13:07:54 -0700 Received: from mail182.messagelabs.com ([85.158.139.83]) by lists.xensource.com with esmtp (Exim 4.43) id 1R6T1X-0002c5-Je; Wed, 21 Sep 2011 13:04:20 -0700 X-Env-Sender: konrad@oracle.com X-Msg-Ref: server-10.tower-182.messagelabs.com!1316635438!19224691!1 X-Originating-IP: [148.87.113.117] X-StarScan-Version: 6.4.1; banners=-,-,- X-VirusChecked: Checked Received: (qmail 22965 invoked from network); 21 Sep 2011 20:04:00 -0000 Received: from rcsinet15.oracle.com (HELO rcsinet15.oracle.com) (148.87.113.117) by server-10.tower-182.messagelabs.com with DHE-RSA-AES256-SHA encrypted SMTP; 21 Sep 2011 20:04:00 -0000 Received: from rtcsinet22.oracle.com (rtcsinet22.oracle.com [66.248.204.30]) by rcsinet15.oracle.com (Switch-3.4.4/Switch-3.4.4) with ESMTP id p8LK3qvs020490 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Wed, 21 Sep 2011 20:03:54 GMT Received: from acsmt357.oracle.com (acsmt357.oracle.com [141.146.40.157]) by rtcsinet22.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id p8LK3o5i008063 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 21 Sep 2011 20:03:51 GMT Received: from abhmt120.oracle.com (abhmt120.oracle.com [141.146.116.72]) by acsmt357.oracle.com (8.12.11.20060308/8.12.11) with ESMTP id p8LK3hNA008906; Wed, 21 Sep 2011 15:03:43 -0500 Received: from oracle.com (/209.6.55.207) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Wed, 21 Sep 2011 13:03:43 -0700 Received: by oracle.com (Postfix, from userid 1000) id 1F7FD1434; Wed, 21 Sep 2011 16:03:49 -0400 (EDT) Date: Wed, 21 Sep 2011 16:03:49 -0400 From: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com> To: Jeremy Fitzhardinge <jeremy@goop.org> Subject: Re: [Xen-devel] Re: Virtualization Test Day for F16 and Xen Message-ID: <20110921200348.GA31078@phenom.oracle.com> References: <CAN0j7xqm5BatDtXaurYZWvb-6ibG2V10aQ5Qck+9P7DjciWLwQ@mail.gmail.com> <20110914112552.GP12984@reaktio.net> <20110914142522.GA16956@phenom.oracle.com> <20110914144539.GR12984@reaktio.net> <20110915151041.GA4453@imp.local> <1316126290.5689.3.camel@adam> <20110916084308.GD884@phenom.oracle.com> <4E77A4EC.9080600@goop.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <4E77A4EC.9080600@goop.org> User-Agent: Mutt/1.5.21 (2010-09-15) X-Source-IP: rtcsinet22.oracle.com [66.248.204.30] X-CT-RefId: str=0001.0A090208.4E7A432B.000F,ss=1,re=0.000,fgs=0 Cc: Development discussions related to Fedora <devel@lists.fedoraproject.org>, xen@lists.fedoraproject.org, xen-devel@lists.xensource.com, Stefano Stabellini <stefano.stabellini@eu.citrix.com>, lars.kurth@xen.org, virt@lists.fedoraproject.org, xen-users@lists.xensource.com, Adam Williamson <awilliam@redhat.com> X-BeenThere: xen-devel@lists.xensource.com X-Mailman-Version: 2.1.5 Precedence: list List-Id: Xen developer discussion <xen-devel.lists.xensource.com> List-Unsubscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe> List-Post: <mailto:xen-devel@lists.xensource.com> List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help> List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=subscribe> Sender: xen-devel-bounces@lists.xensource.com Errors-To: xen-devel-bounces@lists.xensource.com > >> So, there's a meta-point here: we currently 'require' Beta releases to > >> boot as guests on Xen hosts: > >> > >> "The release must boot successfully as a virtual guest in a situation > >> where the virtual host is running a supported Xen implementation" > >> > >> I really don't have much knowledge of Xen and haven't followed this > >> discussion closely, but do any currently-known bugs prevent this? If so, > >> please flag them up so they can be considered as Beta blockers...thanks! I filled Bug 740378 - F16: Can't use keyboard when installing F16-Alpha under Xen (regression) as guest which is pretty descripting what is below. Also adding in Jeremy's workaround in it. Besides that, there is also 738085 - Patch to reduce spurious Xen entries in grub menu which has a patch to fix the grub2 menu-thingy.. > > Somehow the xen-kbdfront driver is not included in the initrd image > > (I think) - and we end with anaconda but can't type anything. I've been trying > > to figure out how to inject said module in the install initrd to see if that is > > really the problem but running in roadblocks (like xz 5.1.1alpha or 5.0.3 complains > > about corrupt image, or I've no idea how to make driver disks). > > I saw the same thing and worked around it by booting with "vnc > lang=en_US.UTF-8 keymap=us" which eliminiates the need to enter anything > before it starts X on a vnc server. But it doesn't really address the > original problem. > > I spent last Friday trying to get it to do an HVM install, but that > seemed to be very much a Xen problem. It wouldn't accept keyboard input > or find its emulated devices properly until I added "acpi=off", or set > "acpi=0" in the Xen config. But even then it refused to see my HD > image, even though the BIOS could list it. > > I got stuck at that point, and am now (successfully) doing a PV install > (with the above workaround). _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel From xen-devel-bounces@lists.xensource.com Wed Sep 21 13:22:02 2011 Return-path: <xen-devel-bounces@lists.xensource.com> Envelope-to: www-data@lists.xensource.com Delivery-date: Wed, 21 Sep 2011 13:22:02 -0700 Received: from localhost ([127.0.0.1] helo=lists.colo.xensource.com) by lists.xensource.com with esmtp (Exim 4.43) id 1R6TIv-0004Zv-Kj; Wed, 21 Sep 2011 13:22:01 -0700 Received: from mail182.messagelabs.com ([85.158.139.83]) by lists.xensource.com with esmtp (Exim 4.43) id 1R6TI0-0004NZ-My for xen-devel@lists.xensource.com; Wed, 21 Sep 2011 13:21:08 -0700 X-Env-Sender: konrad@oracle.com X-Msg-Ref: server-7.tower-182.messagelabs.com!1316636459!14235609!1 X-Originating-IP: [141.146.126.227] X-StarScan-Version: 6.4.1; banners=-,-,- X-VirusChecked: Checked Received: (qmail 32495 invoked from network); 21 Sep 2011 20:21:01 -0000 Received: from acsinet15.oracle.com (HELO acsinet15.oracle.com) (141.146.126.227) by server-7.tower-182.messagelabs.com with DHE-RSA-AES256-SHA encrypted SMTP; 21 Sep 2011 20:21:01 -0000 Received: from acsinet22.oracle.com (acsinet22.oracle.com [141.146.126.238]) by acsinet15.oracle.com (Switch-3.4.4/Switch-3.4.4) with ESMTP id p8LKKvb2018271 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Wed, 21 Sep 2011 20:20:58 GMT Received: from acsmt358.oracle.com (acsmt358.oracle.com [141.146.40.158]) by acsinet22.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id p8LKKsAZ022444 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 21 Sep 2011 20:20:56 GMT Received: from abhmt107.oracle.com (abhmt107.oracle.com [141.146.116.59]) by acsmt358.oracle.com (8.12.11.20060308/8.12.11) with ESMTP id p8LKKm3c004987; Wed, 21 Sep 2011 15:20:48 -0500 Received: from oracle.com (/209.6.55.207) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Wed, 21 Sep 2011 13:20:48 -0700 Received: by oracle.com (Postfix, from userid 1000) id 5630F1434; Wed, 21 Sep 2011 16:20:54 -0400 (EDT) Date: Wed, 21 Sep 2011 16:20:54 -0400 From: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com> To: Jan Beulich <JBeulich@suse.com> Message-ID: <20110921202054.GA32405@phenom.oracle.com> References: <4E778D100200007800056B76@nat28.tlf.novell.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <4E778D100200007800056B76@nat28.tlf.novell.com> User-Agent: Mutt/1.5.21 (2010-09-15) X-Source-IP: acsinet22.oracle.com [141.146.126.238] X-Auth-Type: Internal IP X-CT-RefId: str=0001.0A090208.4E7A472B.003C:SCFMA922111,ss=1,re=-6.300,fgs=0 Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com> Subject: [Xen-devel] Re: [PATCH] xen/pciback: miscellaneous adjustments X-BeenThere: xen-devel@lists.xensource.com X-Mailman-Version: 2.1.5 Precedence: list List-Id: Xen developer discussion <xen-devel.lists.xensource.com> List-Unsubscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe> List-Post: <mailto:xen-devel@lists.xensource.com> List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help> List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=subscribe> Sender: xen-devel-bounces@lists.xensource.com Errors-To: xen-devel-bounces@lists.xensource.com On Mon, Sep 19, 2011 at 05:42:24PM +0100, Jan Beulich wrote: > This is a minor bugfix and a set of small cleanups; as it is not clear > whether this needs splitting into pieces (and if so, at what > granularity), I'm submitting this as a single combined patch as a > first try (I'd hope it doesn't need to be one patch per description > line below): > - add a missing return statement to an error path in > kill_domain_by_device() > - use pci_is_enabled() rather than raw atomic_read() > - use resource_size() rather than open coding it I got a patch for that from commit b1d39d366a412f634fe50c1db6cfc751829157d3 Author: Thomas Meyer <thomas@m3y3r.de> Date: Sat Aug 6 11:05:35 2011 +0200 xen/pciback: use resource_size() Use resource_size function on resource object instead of explicit computation. The semantic patch that makes this output is available in scripts/coccinelle/api/resource_size.cocci. More information about semantic patching is available at http://coccinelle.lip6.fr/ Signed-off-by: Thomas Meyer <thomas@m3y3r.de> Signed-off-by: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com> diff --git a/drivers/xen/xen-pciback/conf_space_header.c b/drivers/xen/xen-pciback/conf_space_header.c index da3cbdf..f14b30f 100644 --- a/drivers/xen/xen-pciback/conf_space_header.c +++ b/drivers/xen/xen-pciback/conf_space_header.c @@ -187,7 +187,7 @@ static inline void read_dev_bar(struct pci_dev *dev, bar_info->val = res[pos].start | (res[pos].flags & PCI_REGION_FLAG_MASK); - bar_info->len_val = res[pos].end - res[pos].start + 1; + bar_info->len_val = resource_size(&res[pos]); } static void *bar_init(struct pci_dev *dev, int offset) so will use that instead, and drop that section from your patch. > - remove a bogus attempt to zero-terminate an already zero-terminated > string > - #define DRV_NAME once uniformly in the shared local header > - make DRIVER_ATTR() variables static > - eliminate a pointless use of list_for_each_entry_safe() > - add MODULE_ALIAS() > - a little bit of constification > - adjust a few messages > - remove stray semicolons from inline function definitions Otherwsie they look good to me. > > Signed-off-by: Jan Beulich <jbeulich@suse.com> > > --- > drivers/xen/xen-pciback/conf_space.c | 1 > drivers/xen/xen-pciback/conf_space_header.c | 5 +--- > drivers/xen/xen-pciback/conf_space_quirks.c | 3 -- > drivers/xen/xen-pciback/passthrough.c | 2 - > drivers/xen/xen-pciback/pci_stub.c | 31 +++++++++++----------------- > drivers/xen/xen-pciback/pciback.h | 30 +++++++++++++++++---------- > drivers/xen/xen-pciback/pciback_ops.c | 1 > drivers/xen/xen-pciback/vpci.c | 9 +++----- > drivers/xen/xen-pciback/xenbus.c | 5 +--- > 9 files changed, 42 insertions(+), 45 deletions(-) > > --- 3.1-rc6/drivers/xen/xen-pciback/conf_space.c > +++ 3.1-rc6-xen-pciback-misc/drivers/xen/xen-pciback/conf_space.c > @@ -15,7 +15,6 @@ > #include "conf_space.h" > #include "conf_space_quirks.h" > > -#define DRV_NAME "xen-pciback" > static int permissive; > module_param(permissive, bool, 0644); > > --- 3.1-rc6/drivers/xen/xen-pciback/conf_space_header.c > +++ 3.1-rc6-xen-pciback-misc/drivers/xen/xen-pciback/conf_space_header.c > @@ -15,7 +15,6 @@ struct pci_bar_info { > int which; > }; > > -#define DRV_NAME "xen-pciback" > #define is_enable_cmd(value) ((value)&(PCI_COMMAND_MEMORY|PCI_COMMAND_IO)) > #define is_master_cmd(value) ((value)&PCI_COMMAND_MASTER) > > @@ -25,7 +24,7 @@ static int command_read(struct pci_dev * > int ret; > > ret = xen_pcibk_read_config_word(dev, offset, value, data); > - if (!atomic_read(&dev->enable_cnt)) > + if (!pci_is_enabled(dev)) > return ret; > > for (i = 0; i < PCI_ROM_RESOURCE; i++) { > @@ -187,7 +186,7 @@ static inline void read_dev_bar(struct p > > bar_info->val = res[pos].start | > (res[pos].flags & PCI_REGION_FLAG_MASK); > - bar_info->len_val = res[pos].end - res[pos].start + 1; > + bar_info->len_val = resource_size(res + pos); > } > > static void *bar_init(struct pci_dev *dev, int offset) > --- 3.1-rc6/drivers/xen/xen-pciback/conf_space_quirks.c > +++ 3.1-rc6-xen-pciback-misc/drivers/xen/xen-pciback/conf_space_quirks.c > @@ -12,7 +12,6 @@ > #include "conf_space_quirks.h" > > LIST_HEAD(xen_pcibk_quirks); > -#define DRV_NAME "xen-pciback" > static inline const struct pci_device_id * > match_one_device(const struct pci_device_id *id, const struct pci_dev *dev) > { > @@ -36,7 +35,7 @@ static struct xen_pcibk_config_quirk *xe > goto out; > tmp_quirk = NULL; > printk(KERN_DEBUG DRV_NAME > - ":quirk didn't match any device xen_pciback knows about\n"); > + ": quirk didn't match any device known\n"); > out: > return tmp_quirk; > } > --- 3.1-rc6/drivers/xen/xen-pciback/passthrough.c > +++ 3.1-rc6-xen-pciback-misc/drivers/xen/xen-pciback/passthrough.c > @@ -182,7 +182,7 @@ static int __xen_pcibk_get_pcifront_dev( > return 1; > } > > -struct xen_pcibk_backend xen_pcibk_passthrough_backend = { > +const struct xen_pcibk_backend xen_pcibk_passthrough_backend = { > .name = "passthrough", > .init = __xen_pcibk_init_devices, > .free = __xen_pcibk_release_devices, > --- 3.1-rc6/drivers/xen/xen-pciback/pci_stub.c > +++ 3.1-rc6-xen-pciback-misc/drivers/xen/xen-pciback/pci_stub.c > @@ -21,8 +21,6 @@ > #include "conf_space.h" > #include "conf_space_quirks.h" > > -#define DRV_NAME "xen-pciback" > - > static char *pci_devs_to_hide; > wait_queue_head_t xen_pcibk_aer_wait_queue; > /*Add sem for sync AER handling and xen_pcibk remove/reconfigue ops, > @@ -514,12 +512,14 @@ static void kill_domain_by_device(struct > int err; > char nodename[PCI_NODENAME_MAX]; > > - if (!psdev) > + if (!psdev) { > dev_err(&psdev->dev->dev, > "device is NULL when do AER recovery/kill_domain\n"); > + return; > + } > + > snprintf(nodename, PCI_NODENAME_MAX, "/local/domain/0/backend/pci/%d/0", > psdev->pdev->xdev->otherend_id); > - nodename[strlen(nodename)] = '\0'; > > again: > err = xenbus_transaction_start(&xbt); > @@ -605,7 +605,7 @@ static pci_ers_result_t common_process(s > if (test_bit(_XEN_PCIF_active, > (unsigned long *)&psdev->pdev->sh_info->flags)) { > dev_dbg(&psdev->dev->dev, > - "schedule pci_conf service in xen_pcibk\n"); > + "schedule pci_conf service in " DRV_NAME "\n"); > xen_pcibk_test_and_schedule_op(psdev->pdev); > } > > @@ -995,8 +995,7 @@ out: > err = count; > return err; > } > - > -DRIVER_ATTR(new_slot, S_IWUSR, NULL, pcistub_slot_add); > +static DRIVER_ATTR(new_slot, S_IWUSR, NULL, pcistub_slot_add); > > static ssize_t pcistub_slot_remove(struct device_driver *drv, const char *buf, > size_t count) > @@ -1015,8 +1014,7 @@ out: > err = count; > return err; > } > - > -DRIVER_ATTR(remove_slot, S_IWUSR, NULL, pcistub_slot_remove); > +static DRIVER_ATTR(remove_slot, S_IWUSR, NULL, pcistub_slot_remove); > > static ssize_t pcistub_slot_show(struct device_driver *drv, char *buf) > { > @@ -1039,8 +1037,7 @@ static ssize_t pcistub_slot_show(struct > > return count; > } > - > -DRIVER_ATTR(slots, S_IRUSR, pcistub_slot_show, NULL); > +static DRIVER_ATTR(slots, S_IRUSR, pcistub_slot_show, NULL); > > static ssize_t pcistub_irq_handler_show(struct device_driver *drv, char *buf) > { > @@ -1069,8 +1066,7 @@ static ssize_t pcistub_irq_handler_show( > spin_unlock_irqrestore(&pcistub_devices_lock, flags); > return count; > } > - > -DRIVER_ATTR(irq_handlers, S_IRUSR, pcistub_irq_handler_show, NULL); > +static DRIVER_ATTR(irq_handlers, S_IRUSR, pcistub_irq_handler_show, NULL); > > static ssize_t pcistub_irq_handler_switch(struct device_driver *drv, > const char *buf, > @@ -1106,7 +1102,7 @@ out: > err = count; > return err; > } > -DRIVER_ATTR(irq_handler_state, S_IWUSR, NULL, pcistub_irq_handler_switch); > +static DRIVER_ATTR(irq_handler_state, S_IWUSR, NULL, pcistub_irq_handler_switch); > > static ssize_t pcistub_quirk_add(struct device_driver *drv, const char *buf, > size_t count) > @@ -1170,8 +1166,7 @@ out: > > return count; > } > - > -DRIVER_ATTR(quirks, S_IRUSR | S_IWUSR, pcistub_quirk_show, pcistub_quirk_add); > +static DRIVER_ATTR(quirks, S_IRUSR | S_IWUSR, pcistub_quirk_show, pcistub_quirk_add); > > static ssize_t permissive_add(struct device_driver *drv, const char *buf, > size_t count) > @@ -1236,8 +1231,7 @@ static ssize_t permissive_show(struct de > spin_unlock_irqrestore(&pcistub_devices_lock, flags); > return count; > } > - > -DRIVER_ATTR(permissive, S_IRUSR | S_IWUSR, permissive_show, permissive_add); > +static DRIVER_ATTR(permissive, S_IRUSR | S_IWUSR, permissive_show, permissive_add); > > static void pcistub_exit(void) > { > @@ -1374,3 +1368,4 @@ module_init(xen_pcibk_init); > module_exit(xen_pcibk_cleanup); > > MODULE_LICENSE("Dual BSD/GPL"); > +MODULE_ALIAS("xen-backend:pci"); > --- 3.1-rc6/drivers/xen/xen-pciback/pciback.h > +++ 3.1-rc6-xen-pciback-misc/drivers/xen/xen-pciback/pciback.h > @@ -15,6 +15,8 @@ > #include <linux/atomic.h> > #include <xen/interface/io/pciif.h> > > +#define DRV_NAME "xen-pciback" > + > struct pci_dev_entry { > struct list_head list; > struct pci_dev *dev; > @@ -89,7 +91,7 @@ typedef int (*publish_pci_root_cb) (stru > * passthrough - BDFs are exactly like in the host. > */ > struct xen_pcibk_backend { > - char *name; > + const char *name; > int (*init)(struct xen_pcibk_device *pdev); > void (*free)(struct xen_pcibk_device *pdev); > int (*find)(struct pci_dev *pcidev, struct xen_pcibk_device *pdev, > @@ -104,9 +106,9 @@ struct xen_pcibk_backend { > unsigned int devfn); > }; > > -extern struct xen_pcibk_backend xen_pcibk_vpci_backend; > -extern struct xen_pcibk_backend xen_pcibk_passthrough_backend; > -extern struct xen_pcibk_backend *xen_pcibk_backend; > +extern const struct xen_pcibk_backend xen_pcibk_vpci_backend; > +extern const struct xen_pcibk_backend xen_pcibk_passthrough_backend; > +extern const struct xen_pcibk_backend *xen_pcibk_backend; > > static inline int xen_pcibk_add_pci_dev(struct xen_pcibk_device *pdev, > struct pci_dev *dev, > @@ -116,13 +118,14 @@ static inline int xen_pcibk_add_pci_dev( > if (xen_pcibk_backend && xen_pcibk_backend->add) > return xen_pcibk_backend->add(pdev, dev, devid, publish_cb); > return -1; > -}; > +} > + > static inline void xen_pcibk_release_pci_dev(struct xen_pcibk_device *pdev, > struct pci_dev *dev) > { > if (xen_pcibk_backend && xen_pcibk_backend->free) > return xen_pcibk_backend->release(pdev, dev); > -}; > +} > > static inline struct pci_dev * > xen_pcibk_get_pci_dev(struct xen_pcibk_device *pdev, unsigned int domain, > @@ -131,7 +134,8 @@ xen_pcibk_get_pci_dev(struct xen_pcibk_d > if (xen_pcibk_backend && xen_pcibk_backend->get) > return xen_pcibk_backend->get(pdev, domain, bus, devfn); > return NULL; > -}; > +} > + > /** > * Add for domain0 PCIE-AER handling. Get guest domain/bus/devfn in xen_pcibk > * before sending aer request to pcifront, so that guest could identify > @@ -148,25 +152,29 @@ static inline int xen_pcibk_get_pcifront > return xen_pcibk_backend->find(pcidev, pdev, domain, bus, > devfn); > return -1; > -}; > +} > + > static inline int xen_pcibk_init_devices(struct xen_pcibk_device *pdev) > { > if (xen_pcibk_backend && xen_pcibk_backend->init) > return xen_pcibk_backend->init(pdev); > return -1; > -}; > +} > + > static inline int xen_pcibk_publish_pci_roots(struct xen_pcibk_device *pdev, > publish_pci_root_cb cb) > { > if (xen_pcibk_backend && xen_pcibk_backend->publish) > return xen_pcibk_backend->publish(pdev, cb); > return -1; > -}; > +} > + > static inline void xen_pcibk_release_devices(struct xen_pcibk_device *pdev) > { > if (xen_pcibk_backend && xen_pcibk_backend->free) > return xen_pcibk_backend->free(pdev); > -}; > +} > + > /* Handles events from front-end */ > irqreturn_t xen_pcibk_handle_event(int irq, void *dev_id); > void xen_pcibk_do_op(struct work_struct *data); > --- 3.1-rc6/drivers/xen/xen-pciback/pciback_ops.c > +++ 3.1-rc6-xen-pciback-misc/drivers/xen/xen-pciback/pciback_ops.c > @@ -10,7 +10,6 @@ > #include <linux/sched.h> > #include "pciback.h" > > -#define DRV_NAME "xen-pciback" > int verbose_request; > module_param(verbose_request, int, 0644); > > --- 3.1-rc6/drivers/xen/xen-pciback/vpci.c > +++ 3.1-rc6-xen-pciback-misc/drivers/xen/xen-pciback/vpci.c > @@ -12,7 +12,6 @@ > #include "pciback.h" > > #define PCI_SLOT_MAX 32 > -#define DRV_NAME "xen-pciback" > > struct vpci_dev_data { > /* Access to dev_list must be protected by lock */ > @@ -150,9 +149,9 @@ static void __xen_pcibk_release_pci_dev( > spin_lock_irqsave(&vpci_dev->lock, flags); > > for (slot = 0; slot < PCI_SLOT_MAX; slot++) { > - struct pci_dev_entry *e, *tmp; > - list_for_each_entry_safe(e, tmp, &vpci_dev->dev_list[slot], > - list) { > + struct pci_dev_entry *e; > + > + list_for_each_entry(e, &vpci_dev->dev_list[slot], list) { > if (e->dev == dev) { > list_del(&e->list); > found_dev = e->dev; > @@ -247,7 +246,7 @@ static int __xen_pcibk_get_pcifront_dev( > return found; > } > > -struct xen_pcibk_backend xen_pcibk_vpci_backend = { > +const struct xen_pcibk_backend xen_pcibk_vpci_backend = { > .name = "vpci", > .init = __xen_pcibk_init_devices, > .free = __xen_pcibk_release_devices, > --- 3.1-rc6/drivers/xen/xen-pciback/xenbus.c > +++ 3.1-rc6-xen-pciback-misc/drivers/xen/xen-pciback/xenbus.c > @@ -13,7 +13,6 @@ > #include <asm/xen/pci.h> > #include "pciback.h" > > -#define DRV_NAME "xen-pciback" > #define INVALID_EVTCHN_IRQ (-1) > struct workqueue_struct *xen_pcibk_wq; > > @@ -176,7 +175,7 @@ static int xen_pcibk_attach(struct xen_p > if (magic == NULL || strcmp(magic, XEN_PCI_MAGIC) != 0) { > xenbus_dev_fatal(pdev->xdev, -EFAULT, > "version mismatch (%s/%s) with pcifront - " > - "halting xen_pcibk", > + "halting " DRV_NAME, > magic, XEN_PCI_MAGIC); > goto out; > } > @@ -724,7 +723,7 @@ static struct xenbus_driver xenbus_xen_p > .otherend_changed = xen_pcibk_frontend_changed, > }; > > -struct xen_pcibk_backend *xen_pcibk_backend; > +const struct xen_pcibk_backend *__read_mostly xen_pcibk_backend; > > int __init xen_pcibk_xenbus_register(void) > { > _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel From xen-devel-bounces@lists.xensource.com Wed Sep 21 13:32:30 2011 Return-path: <xen-devel-bounces@lists.xensource.com> Envelope-to: www-data@lists.xensource.com Delivery-date: Wed, 21 Sep 2011 13:32:30 -0700 Received: from localhost ([127.0.0.1] helo=lists.colo.xensource.com) by lists.xensource.com with esmtp (Exim 4.43) id 1R6TT3-00057b-Vx; Wed, 21 Sep 2011 13:32:30 -0700 Received: from mail174.messagelabs.com ([85.158.138.51]) by lists.xensource.com with esmtp (Exim 4.43) id 1R6TSX-0004ut-Gg for xen-devel@lists.xensource.com; Wed, 21 Sep 2011 13:31:57 -0700 X-Env-Sender: konrad@oracle.com X-Msg-Ref: server-10.tower-174.messagelabs.com!1316637112!32267916!1 X-Originating-IP: [148.87.113.117] X-StarScan-Version: 6.4.1; banners=-,-,- X-VirusChecked: Checked Received: (qmail 23443 invoked from network); 21 Sep 2011 20:31:54 -0000 Received: from rcsinet15.oracle.com (HELO rcsinet15.oracle.com) (148.87.113.117) by server-10.tower-174.messagelabs.com with DHE-RSA-AES256-SHA encrypted SMTP; 21 Sep 2011 20:31:54 -0000 Received: from acsinet21.oracle.com (acsinet21.oracle.com [141.146.126.237]) by rcsinet15.oracle.com (Switch-3.4.4/Switch-3.4.4) with ESMTP id p8LKVlaV015243 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Wed, 21 Sep 2011 20:31:49 GMT Received: from acsmt357.oracle.com (acsmt357.oracle.com [141.146.40.157]) by acsinet21.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id p8LKViFV020694 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 21 Sep 2011 20:31:45 GMT Received: from abhmt118.oracle.com (abhmt118.oracle.com [141.146.116.70]) by acsmt357.oracle.com (8.12.11.20060308/8.12.11) with ESMTP id p8LKVciN029363; Wed, 21 Sep 2011 15:31:38 -0500 Received: from oracle.com (/209.6.55.207) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Wed, 21 Sep 2011 13:31:38 -0700 Received: by oracle.com (Postfix, from userid 1000) id EED2B1434; Wed, 21 Sep 2011 16:31:44 -0400 (EDT) Date: Wed, 21 Sep 2011 16:31:44 -0400 From: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com> To: Stefano Stabellini <stefano.stabellini@eu.citrix.com> Subject: Re: [Xen-devel] [PATCH v4 1/2] xen: add an "highmem" parameter to alloc_xenballooned_pages Message-ID: <20110921203144.GA934@phenom.oracle.com> References: <alpine.DEB.2.00.1109081942470.12963@kaball-desktop> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <alpine.DEB.2.00.1109081942470.12963@kaball-desktop> User-Agent: Mutt/1.5.21 (2010-09-15) X-Source-IP: acsinet21.oracle.com [141.146.126.237] X-Auth-Type: Internal IP X-CT-RefId: str=0001.0A090206.4E7A49B5.0139:SCFMA922111,ss=1,re=-4.000,fgs=0 Cc: Jeremy Fitzhardinge <jeremy@goop.org>, xen-devel@lists.xensource.com, linux-kernel@vger.kernel.org X-BeenThere: xen-devel@lists.xensource.com X-Mailman-Version: 2.1.5 Precedence: list List-Id: Xen developer discussion <xen-devel.lists.xensource.com> List-Unsubscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe> List-Post: <mailto:xen-devel@lists.xensource.com> List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help> List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=subscribe> Sender: xen-devel-bounces@lists.xensource.com Errors-To: xen-devel-bounces@lists.xensource.com On Thu, Sep 08, 2011 at 07:45:08PM +0100, Stefano Stabellini wrote: > Add an highmem parameter to alloc_xenballooned_pages, to allow callers to > request lowmem or highmem pages. <grumble grumble> + scripts/checkpatch.pl --no-signoff /tmp/git.patch ERROR: "foo** bar" should be "foo **bar" #467: FILE: include/xen/balloon.h:28: +int alloc_xenballooned_pages(int nr_pages, struct page** pages, total: 1 errors, 0 warnings, 461 lines checked Please fix and repost. > > Signed-off-by: Stefano Stabellini <stefano.stabellini@eu.citrix.com> > --- > drivers/xen/balloon.c | 12 ++++++++---- > drivers/xen/gntdev.c | 2 +- > include/xen/balloon.h | 3 ++- > 3 files changed, 11 insertions(+), 6 deletions(-) > > diff --git a/drivers/xen/balloon.c b/drivers/xen/balloon.c > index 5dfd8f8..7f7d463 100644 > --- a/drivers/xen/balloon.c > +++ b/drivers/xen/balloon.c > @@ -501,20 +501,24 @@ EXPORT_SYMBOL_GPL(balloon_set_new_target); > * alloc_xenballooned_pages - get pages that have been ballooned out > * @nr_pages: Number of pages to get > * @pages: pages returned > + * @highmem: highmem or lowmem pages > * @return 0 on success, error otherwise > */ > -int alloc_xenballooned_pages(int nr_pages, struct page** pages) > +int alloc_xenballooned_pages(int nr_pages, struct page** pages, bool highmem) > { > int pgno = 0; > struct page* page; > mutex_lock(&balloon_mutex); > while (pgno < nr_pages) { > - page = balloon_retrieve(true); > - if (page) { > + page = balloon_retrieve(highmem); > + if (page && PageHighMem(page) == highmem) { > pages[pgno++] = page; > } else { > enum bp_state st; > - st = decrease_reservation(nr_pages - pgno, GFP_HIGHUSER); > + if (page) > + balloon_append(page); > + st = decrease_reservation(nr_pages - pgno, > + highmem ? GFP_HIGHUSER : GFP_USER); > if (st != BP_DONE) > goto out_undo; > } > diff --git a/drivers/xen/gntdev.c b/drivers/xen/gntdev.c > index f914b26..7b9b1d1 100644 > --- a/drivers/xen/gntdev.c > +++ b/drivers/xen/gntdev.c > @@ -123,7 +123,7 @@ static struct grant_map *gntdev_alloc_map(struct gntdev_priv *priv, int count) > NULL == add->pages) > goto err; > > - if (alloc_xenballooned_pages(count, add->pages)) > + if (alloc_xenballooned_pages(count, add->pages, false /* lowmem */)) > goto err; > > for (i = 0; i < count; i++) { > diff --git a/include/xen/balloon.h b/include/xen/balloon.h > index 76f7538..b1a8233 100644 > --- a/include/xen/balloon.h > +++ b/include/xen/balloon.h > @@ -25,7 +25,8 @@ extern struct balloon_stats balloon_stats; > > void balloon_set_new_target(unsigned long target); > > -int alloc_xenballooned_pages(int nr_pages, struct page** pages); > +int alloc_xenballooned_pages(int nr_pages, struct page** pages, > + bool highmem); > void free_xenballooned_pages(int nr_pages, struct page** pages); > > struct sys_device; > -- > 1.7.2.3 > > > _______________________________________________ > Xen-devel mailing list > Xen-devel@lists.xensource.com > http://lists.xensource.com/xen-devel _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel From xen-devel-bounces@lists.xensource.com Wed Sep 21 13:33:49 2011 Return-path: <xen-devel-bounces@lists.xensource.com> Envelope-to: www-data@lists.xensource.com Delivery-date: Wed, 21 Sep 2011 13:33:49 -0700 Received: from localhost ([127.0.0.1] helo=lists.colo.xensource.com) by lists.xensource.com with esmtp (Exim 4.43) id 1R6TUL-0005Up-9j; Wed, 21 Sep 2011 13:33:49 -0700 Received: from mail216.messagelabs.com ([85.158.143.99]) by lists.xensource.com with smtp (Exim 4.43) id 1R6TTR-0005Df-3O for xen-devel@lists.xensource.com; Wed, 21 Sep 2011 13:32:55 -0700 X-Env-Sender: allen.m.kay@intel.com X-Msg-Ref: server-2.tower-216.messagelabs.com!1316637169!18702948!1 X-Originating-IP: [143.182.124.21] X-StarScan-Version: 6.4.1; banners=-,-,- X-VirusChecked: Checked Received: (qmail 20899 invoked from network); 21 Sep 2011 20:32:49 -0000 Received: from mga03.intel.com (HELO mga03.intel.com) (143.182.124.21) by server-2.tower-216.messagelabs.com with SMTP; 21 Sep 2011 20:32:49 -0000 Received: from azsmga002.ch.intel.com ([10.2.17.35]) by azsmga101.ch.intel.com with ESMTP; 21 Sep 2011 13:32:48 -0700 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="4.68,419,1312182000"; d="scan'208";a="19340740" Received: from orsmsx603.amr.corp.intel.com ([10.22.226.49]) by AZSMGA002.ch.intel.com with ESMTP; 21 Sep 2011 13:32:48 -0700 Received: from orsmsx505.amr.corp.intel.com ([10.22.226.208]) by orsmsx603.amr.corp.intel.com ([10.22.226.49]) with mapi; Wed, 21 Sep 2011 13:32:47 -0700 From: "Kay, Allen M" <allen.m.kay@intel.com> To: Jan Beulich <JBeulich@suse.com> Date: Wed, 21 Sep 2011 13:32:45 -0700 Subject: RE: [Xen-devel] RE: Resend: RE: enable_ats_device() call site Thread-Topic: [Xen-devel] RE: Resend: RE: enable_ats_device() call site Thread-Index: Acx4NEit18bux2eoQHOVYeNgufVRBQAaT+Jg Message-ID: <987664A83D2D224EAE907B061CE93D5301EE256A2C@orsmsx505.amr.corp.intel.com> References: <4E79B56C0200007800056F8E@nat28.tlf.novell.com> In-Reply-To: <4E79B56C0200007800056F8E@nat28.tlf.novell.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: Xen Devel <xen-devel@lists.xensource.com> X-BeenThere: xen-devel@lists.xensource.com X-Mailman-Version: 2.1.5 Precedence: list List-Id: Xen developer discussion <xen-devel.lists.xensource.com> List-Unsubscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe> List-Post: <mailto:xen-devel@lists.xensource.com> List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help> List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=subscribe> Sender: xen-devel-bounces@lists.xensource.com Errors-To: xen-devel-bounces@lists.xensource.com Looks good to me. Allen -----Original Message----- From: Jan Beulich [mailto:JBeulich@suse.com]=20 Sent: Wednesday, September 21, 2011 12:59 AM To: Kay, Allen M Cc: Xen Devel Subject: RE: [Xen-devel] RE: Resend: RE: enable_ats_device() call site >>> On 20.09.11 at 20:02, "Kay, Allen M" <allen.m.kay@intel.com> wrote: > I agree that the same problem exists for bus-to-bridge mapping function=20 > pci_scan_device(). By the way, we probably should take the opportunity t= o=20 > give it a proper name that reflects to the true purpose of this function. How about the below (applying only on top of the multi-seg patches, and not yet removing the scanning functions)? Jan --- a/xen/drivers/passthrough/pci.c +++ b/xen/drivers/passthrough/pci.c @@ -129,11 +129,67 @@ static struct pci_dev *alloc_pdev(struct list_add(&pdev->alldevs_list, &pseg->alldevs_list); spin_lock_init(&pdev->msix_table_lock); =20 + /* update bus2bridge */ + switch ( pdev_type(pseg->nr, bus, devfn) ) + { + u8 sec_bus, sub_bus; + + case DEV_TYPE_PCIe_BRIDGE: + break; + + case DEV_TYPE_PCIe2PCI_BRIDGE: + case DEV_TYPE_LEGACY_PCI_BRIDGE: + sec_bus =3D pci_conf_read8(pseg->nr, bus, PCI_SLOT(devfn), + PCI_FUNC(devfn), PCI_SECONDARY_BUS); + sub_bus =3D pci_conf_read8(pseg->nr, bus, PCI_SLOT(devfn), + PCI_FUNC(devfn), PCI_SUBORDINATE_BUS)= ; + + spin_lock(&pseg->bus2bridge_lock); + for ( ; sec_bus <=3D sub_bus; sec_bus++ ) + { + pseg->bus2bridge[sec_bus].map =3D 1; + pseg->bus2bridge[sec_bus].bus =3D bus; + pseg->bus2bridge[sec_bus].devfn =3D devfn; + } + spin_unlock(&pseg->bus2bridge_lock); + break; + + case DEV_TYPE_PCIe_ENDPOINT: + case DEV_TYPE_PCI: + break; + + default: + printk(XENLOG_WARNING "%s: unknown type: %04x:%02x:%02x.%u\n", + __func__, pseg->nr, bus, PCI_SLOT(devfn), PCI_FUNC(devf= n)); + break; + } + return pdev; } =20 -static void free_pdev(struct pci_dev *pdev) +static void free_pdev(struct pci_seg *pseg, struct pci_dev *pdev) { + /* update bus2bridge */ + switch ( pdev_type(pseg->nr, pdev->bus, pdev->devfn) ) + { + u8 dev, func, sec_bus, sub_bus; + + case DEV_TYPE_PCIe2PCI_BRIDGE: + case DEV_TYPE_LEGACY_PCI_BRIDGE: + dev =3D PCI_SLOT(pdev->devfn); + func =3D PCI_FUNC(pdev->devfn); + sec_bus =3D pci_conf_read8(pseg->nr, pdev->bus, dev, func, + PCI_SECONDARY_BUS); + sub_bus =3D pci_conf_read8(pseg->nr, pdev->bus, dev, func, + PCI_SUBORDINATE_BUS); + + spin_lock(&pseg->bus2bridge_lock); + for ( ; sec_bus <=3D sub_bus; sec_bus++ ) + pseg->bus2bridge[sec_bus].map =3D 0; + spin_unlock(&pseg->bus2bridge_lock); + break; + } + list_del(&pdev->alldevs_list); xfree(pdev); } @@ -378,7 +434,7 @@ int pci_remove_device(u16 seg, u8 bus, u if ( pdev->domain ) list_del(&pdev->domain_list); pci_cleanup_msi(pdev); - free_pdev(pdev); + free_pdev(pseg, pdev); printk(XENLOG_DEBUG "PCI remove device %04x:%02x:%02x.%u\n", seg, bus, PCI_SLOT(devfn), PCI_FUNC(devfn)); break; @@ -546,8 +602,6 @@ static int __init _scan_pci_devices(stru { struct pci_dev *pdev; int bus, dev, func; - u8 sec_bus, sub_bus; - int type; =20 for ( bus =3D 0; bus < 256; bus++ ) { @@ -565,41 +619,6 @@ static int __init _scan_pci_devices(stru return -ENOMEM; } =20 - /* build bus2bridge */ - type =3D pdev_type(pseg->nr, bus, PCI_DEVFN(dev, func)); - switch ( type ) - { - case DEV_TYPE_PCIe_BRIDGE: - break; - - case DEV_TYPE_PCIe2PCI_BRIDGE: - case DEV_TYPE_LEGACY_PCI_BRIDGE: - sec_bus =3D pci_conf_read8(pseg->nr, bus, dev, fun= c, - PCI_SECONDARY_BUS); - sub_bus =3D pci_conf_read8(pseg->nr, bus, dev, fun= c, - PCI_SUBORDINATE_BUS); - - spin_lock(&pseg->bus2bridge_lock); - for ( sub_bus &=3D 0xff; sec_bus <=3D sub_bus; sec= _bus++ ) - { - pseg->bus2bridge[sec_bus].map =3D 1; - pseg->bus2bridge[sec_bus].bus =3D bus; - pseg->bus2bridge[sec_bus].devfn =3D - PCI_DEVFN(dev, func); - } - spin_unlock(&pseg->bus2bridge_lock); - break; - - case DEV_TYPE_PCIe_ENDPOINT: - case DEV_TYPE_PCI: - break; - - default: - printk("%s: unknown type: %04x:%02x:%02x.%u\n", - __func__, pseg->nr, bus, dev, func); - return -EINVAL; - } - if ( !func && !(pci_conf_read8(pseg->nr, bus, dev, func, PCI_HEADER_TYPE) & 0x80) ) break; _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel From xen-devel-bounces@lists.xensource.com Wed Sep 21 13:38:35 2011 Return-path: <xen-devel-bounces@lists.xensource.com> Envelope-to: www-data@lists.xensource.com Delivery-date: Wed, 21 Sep 2011 13:38:35 -0700 Received: from localhost ([127.0.0.1] helo=lists.colo.xensource.com) by lists.xensource.com with esmtp (Exim 4.43) id 1R6TYx-00060M-Ay; Wed, 21 Sep 2011 13:38:35 -0700 Received: from mail182.messagelabs.com ([85.158.139.83]) by lists.xensource.com with smtp (Exim 4.43) id 1R6TYO-0005o5-IE for xen-devel@lists.xensource.com; Wed, 21 Sep 2011 13:38:00 -0700 X-Env-Sender: allen.m.kay@intel.com X-Msg-Ref: server-4.tower-182.messagelabs.com!1316637476!19246311!1 X-Originating-IP: [192.55.52.88] X-StarScan-Version: 6.4.1; banners=-,-,- X-VirusChecked: Checked Received: (qmail 30266 invoked from network); 21 Sep 2011 20:37:57 -0000 Received: from mga01.intel.com (HELO mga01.intel.com) (192.55.52.88) by server-4.tower-182.messagelabs.com with SMTP; 21 Sep 2011 20:37:57 -0000 Received: from fmsmga001.fm.intel.com ([10.253.24.23]) by fmsmga101.fm.intel.com with ESMTP; 21 Sep 2011 13:37:56 -0700 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="4.68,419,1312182000"; d="scan'208";a="56372249" Received: from orsmsx602.amr.corp.intel.com ([10.22.226.211]) by fmsmga001.fm.intel.com with ESMTP; 21 Sep 2011 13:37:56 -0700 Received: from orsmsx505.amr.corp.intel.com ([10.22.226.208]) by orsmsx602.amr.corp.intel.com ([10.22.226.211]) with mapi; Wed, 21 Sep 2011 13:37:55 -0700 From: "Kay, Allen M" <allen.m.kay@intel.com> To: Jan Beulich <JBeulich@suse.com>, "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com> Date: Wed, 21 Sep 2011 13:37:54 -0700 Thread-Topic: [PATCH] VT-d: fix off-by-one error in RMRR validation Thread-Index: Acx4TwsP2GZN/VshR328JCBPRydMBAATycGQ Message-ID: <987664A83D2D224EAE907B061CE93D5301EE256A51@orsmsx505.amr.corp.intel.com> References: <4E79E2430200007800057079@nat28.tlf.novell.com> In-Reply-To: <4E79E2430200007800057079@nat28.tlf.novell.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: Subject: [Xen-devel] RE: [PATCH] VT-d: fix off-by-one error in RMRR validation X-BeenThere: xen-devel@lists.xensource.com X-Mailman-Version: 2.1.5 Precedence: list List-Id: Xen developer discussion <xen-devel.lists.xensource.com> List-Unsubscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe> List-Post: <mailto:xen-devel@lists.xensource.com> List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help> List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=subscribe> Sender: xen-devel-bounces@lists.xensource.com Errors-To: xen-devel-bounces@lists.xensource.com Agree, it should not have subtracted 1 here. Good catch. Thanks! Allen -----Original Message----- From: Jan Beulich [mailto:JBeulich@suse.com]=20 Sent: Wednesday, September 21, 2011 4:10 AM To: xen-devel@lists.xensource.com Cc: Kay, Allen M Subject: [PATCH] VT-d: fix off-by-one error in RMRR validation (base_addr,end_addr) is an inclusive range, and hence there shouldn't be a = subtraction of 1 in the second invocation of page_is_ram_type(). For RMRRs covering a single page that actually resulted in the immediately = preceding page to get checked (which could have resulted in a false warning= ). Signed-off-by: Jan Beulich <jbeulich@suse.com> --- a/xen/drivers/passthrough/vtd/dmar.c +++ b/xen/drivers/passthrough/vtd/dmar.c @@ -520,7 +520,7 @@ acpi_parse_one_rmrr(struct acpi_dmar_ent * inform the user */ if ( (!page_is_ram_type(paddr_to_pfn(base_addr), RAM_TYPE_RESERVED)) |= | - (!page_is_ram_type(paddr_to_pfn(end_addr) - 1, RAM_TYPE_RESERVED)= ) ) + (!page_is_ram_type(paddr_to_pfn(end_addr), RAM_TYPE_RESERVED))=20 + ) { dprintk(XENLOG_WARNING VTDPREFIX, " RMRR address range not in reserved memory " _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel From xen-devel-bounces@lists.xensource.com Wed Sep 21 14:07:22 2011 Return-path: <xen-devel-bounces@lists.xensource.com> Envelope-to: www-data@lists.xensource.com Delivery-date: Wed, 21 Sep 2011 14:07:22 -0700 Received: from localhost ([127.0.0.1] helo=lists.colo.xensource.com) by lists.xensource.com with esmtp (Exim 4.43) id 1R6U0o-000709-13; Wed, 21 Sep 2011 14:07:22 -0700 Received: from mail27.messagelabs.com ([193.109.254.147]) by lists.xensource.com with esmtp (Exim 4.43) id 1R6TzF-0006mi-LA for xen-devel@lists.xensource.com; Wed, 21 Sep 2011 14:05:53 -0700 X-Env-Sender: Ian.Jackson@eu.citrix.com X-Msg-Ref: server-6.tower-27.messagelabs.com!1316639122!49936393!1 X-Originating-IP: [62.200.22.115] X-StarScan-Version: 6.4.1; banners=-,-,- X-VirusChecked: Checked Received: (qmail 25071 invoked from network); 21 Sep 2011 21:05:22 -0000 Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115) by server-6.tower-27.messagelabs.com with RC4-SHA encrypted SMTP; 21 Sep 2011 21:05:22 -0000 X-IronPort-AV: E=Sophos;i="4.68,419,1312156800"; d="scan'208";a="7989965" Received: from lonpmailmx01.citrite.net ([10.30.203.162]) by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5; 21 Sep 2011 21:05:30 +0000 Received: from woking.xci-test.com (10.80.248.135) by smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id 8.3.137.0; Wed, 21 Sep 2011 22:05:30 +0100 Received: from osstest by woking.xci-test.com with local (Exim 4.69) (envelope-from <ian.jackson@eu.citrix.com>) id 1R6Tz0-0008Tv-20; Wed, 21 Sep 2011 22:05:30 +0100 To: <xen-devel@lists.xensource.com> Message-ID: <osstest-8993-mainreport@xen.org> From: xen.org <ian.jackson@eu.citrix.com> Date: Wed, 21 Sep 2011 22:05:30 +0100 MIME-Version: 1.0 Content-Type: text/plain Cc: ian.jackson@eu.citrix.com Subject: [Xen-devel] [linux test] 8993: trouble: blocked/broken/fail/pass X-BeenThere: xen-devel@lists.xensource.com X-Mailman-Version: 2.1.5 Precedence: list List-Id: Xen developer discussion <xen-devel.lists.xensource.com> List-Unsubscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe> List-Post: <mailto:xen-devel@lists.xensource.com> List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help> List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=subscribe> Sender: xen-devel-bounces@lists.xensource.com Errors-To: xen-devel-bounces@lists.xensource.com flight 8993 linux real [real] http://www.chiark.greenend.org.uk/~xensrcts/logs/8993/ Failures and problems with tests :-( Tests which did not succeed and are blocking: build-amd64-pvops 1 hosts-allocate broken Tests which did not succeed, but are not blocking, including regressions (tests previously passed) regarded as allowable: test-amd64-amd64-xl 1 xen-build-check(1) blocked n/a test-amd64-amd64-pair 1 xen-build-check(1) blocked n/a test-amd64-i386-rhel6hvm-amd 9 guest-start.2 fail never pass test-amd64-i386-rhel6hvm-intel 9 guest-start.2 fail never pass test-i386-i386-xl-win 13 guest-stop fail never pass test-i386-i386-win 16 leak-check/check fail never pass test-amd64-i386-win-vcpus1 16 leak-check/check fail never pass test-amd64-i386-xl-win-vcpus1 13 guest-stop fail never pass test-amd64-i386-win 16 leak-check/check fail never pass test-amd64-amd64-xl-pcipt-intel 1 xen-build-check(1) blocked n/a test-amd64-amd64-xl-win 1 xen-build-check(1) blocked n/a test-amd64-amd64-pv 1 xen-build-check(1) blocked n/a build-amd64-pvops 2 logs-capture(2) broken never pass test-amd64-amd64-xl-sedf 1 xen-build-check(1) blocked n/a test-amd64-amd64-win 1 xen-build-check(1) blocked n/a version targeted for testing: linux 6bec8b4a4c14095d0b7ce424db9d583c3decae6c baseline version: linux 1c3f03ccc5258887f5f2cafc0836a865834f9205 ------------------------------------------------------------ People who touched revisions under test: Jeremy Fitzhardinge <jeremy.fitzhardinge@citrix.com> ------------------------------------------------------------ jobs: build-amd64 pass build-i386 pass build-amd64-pvops broken build-i386-pvops pass test-amd64-amd64-xl blocked test-amd64-i386-xl pass test-i386-i386-xl pass test-amd64-i386-rhel6hvm-amd fail test-amd64-i386-xl-credit2 pass test-amd64-amd64-xl-pcipt-intel blocked test-amd64-i386-rhel6hvm-intel fail test-amd64-i386-xl-multivcpu pass test-amd64-amd64-pair blocked test-amd64-i386-pair pass test-i386-i386-pair pass test-amd64-amd64-pv blocked test-amd64-i386-pv pass test-i386-i386-pv pass test-amd64-amd64-xl-sedf blocked test-amd64-i386-win-vcpus1 fail test-amd64-i386-xl-win-vcpus1 fail test-amd64-amd64-win blocked test-amd64-i386-win fail test-i386-i386-win fail test-amd64-amd64-xl-win blocked test-i386-i386-xl-win fail ------------------------------------------------------------ sg-report-flight on woking.cam.xci-test.com logs: /home/xc_osstest/logs images: /home/xc_osstest/images Logs, config files, etc. are available at http://www.chiark.greenend.org.uk/~xensrcts/logs Test harness code can be found at http://xenbits.xensource.com/gitweb?p=osstest.git;a=summary Not pushing. ------------------------------------------------------------ commit 6bec8b4a4c14095d0b7ce424db9d583c3decae6c Author: Jeremy Fitzhardinge <jeremy.fitzhardinge@citrix.com> Date: Fri Sep 2 12:23:22 2011 -0700 Revert "xen/apic: Provide an 'apic_xen' to set the override the apic->[read|write] for all cases." This reverts commit c3dd7941354fa96a71f2613e2c7a1b215fa175dc. It prevents the kernel from booting natively on hardware. Conflicts: arch/x86/xen/enlighten.c Signed-off-by: Jeremy Fitzhardinge <jeremy.fitzhardinge@citrix.com> _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel From xen-devel-bounces@lists.xensource.com Wed Sep 21 14:09:26 2011 Return-path: <xen-devel-bounces@lists.xensource.com> Envelope-to: www-data@lists.xensource.com Delivery-date: Wed, 21 Sep 2011 14:09:26 -0700 Received: from localhost ([127.0.0.1] helo=lists.colo.xensource.com) by lists.xensource.com with esmtp (Exim 4.43) id 1R6U2o-0007ON-Fa; Wed, 21 Sep 2011 14:09:26 -0700 Received: from mail216.messagelabs.com ([85.158.143.99]) by lists.xensource.com with esmtp (Exim 4.43) id 1R6U2A-0007Bo-DR for xen-devel@lists.xensource.com; Wed, 21 Sep 2011 14:08:47 -0700 X-Env-Sender: konrad@oracle.com X-Msg-Ref: server-8.tower-216.messagelabs.com!1316639321!17551757!1 X-Originating-IP: [148.87.113.117] X-StarScan-Version: 6.4.1; banners=-,-,- X-VirusChecked: Checked Received: (qmail 24177 invoked from network); 21 Sep 2011 21:08:42 -0000 Received: from rcsinet15.oracle.com (HELO rcsinet15.oracle.com) (148.87.113.117) by server-8.tower-216.messagelabs.com with DHE-RSA-AES256-SHA encrypted SMTP; 21 Sep 2011 21:08:42 -0000 Received: from acsinet22.oracle.com (acsinet22.oracle.com [141.146.126.238]) by rcsinet15.oracle.com (Switch-3.4.4/Switch-3.4.4) with ESMTP id p8LL8cM0021189 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Wed, 21 Sep 2011 21:08:40 GMT Received: from acsmt357.oracle.com (acsmt357.oracle.com [141.146.40.157]) by acsinet22.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id p8LL8cGo026108 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 21 Sep 2011 21:08:38 GMT Received: from abhmt119.oracle.com (abhmt119.oracle.com [141.146.116.71]) by acsmt357.oracle.com (8.12.11.20060308/8.12.11) with ESMTP id p8LL8WuH023774; Wed, 21 Sep 2011 16:08:32 -0500 Received: from oracle.com (/209.6.55.207) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Wed, 21 Sep 2011 14:08:32 -0700 Received: by oracle.com (Postfix, from userid 1000) id D15D01434; Wed, 21 Sep 2011 17:08:38 -0400 (EDT) Date: Wed, 21 Sep 2011 17:08:38 -0400 From: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com> To: Jan Beulich <JBeulich@suse.com> Subject: Re: [Xen-devel] Re: [PATCH] xen/pciback: Use mutexes when working with Xenbus state transitions. Message-ID: <20110921210838.GA1016@phenom.oracle.com> References: <20110916190601.GA31796@phenom.oracle.com> <4E7738E90200007800056A54@nat28.tlf.novell.com> <4E773D440200007800056A6D@nat28.tlf.novell.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <4E773D440200007800056A6D@nat28.tlf.novell.com> User-Agent: Mutt/1.5.21 (2010-09-15) X-Source-IP: acsinet22.oracle.com [141.146.126.238] X-Auth-Type: Internal IP X-CT-RefId: str=0001.0A090201.4E7A5258.010D:SCFMA922111,ss=1,re=-4.000,fgs=0 Cc: xen-devel@lists.xensource.com, linux-kernel@vger.kernel.org X-BeenThere: xen-devel@lists.xensource.com X-Mailman-Version: 2.1.5 Precedence: list List-Id: Xen developer discussion <xen-devel.lists.xensource.com> List-Unsubscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe> List-Post: <mailto:xen-devel@lists.xensource.com> List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help> List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=subscribe> Sender: xen-devel-bounces@lists.xensource.com Errors-To: xen-devel-bounces@lists.xensource.com On Mon, Sep 19, 2011 at 12:01:56PM +0100, Jan Beulich wrote: > >>> On 19.09.11 at 12:43, "Jan Beulich" <JBeulich@suse.com> wrote: > >>>> On 16.09.11 at 21:06, Konrad Rzeszutek Wilk <konrad.wilk@oracle.com> wrote: > > > >> The caller that orchestrates the state changes is xenwatch_thread > >> and it takes a mutex. In our processing of Xenbus states we can take > >> the luxery of going to sleep on a mutex, so lets do that and > > > > This is only the direct conversion of existing spinlock accesses in > > xenbus.c. However, in the course of converting from the legacy > > implementation you stripped a couple more (in xen_pcibk_attach(), > > xen_pcibk_reconfigure(), and xen_pcibk_setup_backend()), and > > Actually, xen_pcibk_attach() has its lock taken in xen_pcibk_do_attach(), > so no change needed there. > > In xen_pcibk_reconfigure() and xen_pcibk_setup_backend() the locking > may be redundant with the one in passthrough.c/vpci.c - is that the > basis upon which you removed the locks taken there? No. I believe the reason was much simpler.. it was b/c of this patch (see below). But for the life of me I don't recall what deadlock we could hit. I think the better choice will be to restore the call-sites of these spinlocks but use mutex instead. So let me post two patches - one for xenbus.c and one for vpci.c to complement "xen/pciback: use mutex rather than spinlock in passthrough backend" you posted and I queued up. commit 3a8d1841ae2dd32452b79284da03eda596f30827 Author: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com> Date: Fri Jul 23 14:35:47 2010 -0400 xen/pciback: Redo spinlock usage. We were using coarse spinlocks that could end up with a deadlock. This patch fixes that and makes the spinlocks much more fine-grained. We also drop be->watchding state spinlocks as they are already guarded by the xenwatch_thread against multiple customers. Signed-off-by: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com> diff --git a/drivers/xen/pciback/xenbus.c b/drivers/xen/pciback/xenbus.c index d448bf5..993b659 100644 --- a/drivers/xen/pciback/xenbus.c +++ b/drivers/xen/pciback/xenbus.c @@ -54,23 +54,29 @@ static void pciback_disconnect(struct pciback_device *pdev) unbind_from_irqhandler(pdev->evtchn_irq, pdev); pdev->evtchn_irq = INVALID_EVTCHN_IRQ; } + spin_unlock(&pdev->dev_lock); /* If the driver domain started an op, make sure we complete it * before releasing the shared memory */ + + /* Note, the workqueue does not use spinlocks at all.*/ flush_workqueue(pciback_wq); + spin_lock(&pdev->dev_lock); if (pdev->sh_info != NULL) { xenbus_unmap_ring_vfree(pdev->xdev, pdev->sh_info); pdev->sh_info = NULL; } - spin_unlock(&pdev->dev_lock); + } static void free_pdev(struct pciback_device *pdev) { - if (pdev->be_watching) + if (pdev->be_watching) { unregister_xenbus_watch(&pdev->be_watch); + pdev->be_watching = 0; + } pciback_disconnect(pdev); @@ -98,7 +104,10 @@ static int pciback_do_attach(struct pciback_device *pdev, int gnt_ref, "Error mapping other domain page in ours."); goto out; } + + spin_lock(&pdev->dev_lock); pdev->sh_info = vaddr; + spin_unlock(&pdev->dev_lock); err = bind_interdomain_evtchn_to_irqhandler( pdev->xdev->otherend_id, remote_evtchn, pciback_handle_event, @@ -108,7 +117,10 @@ static int pciback_do_attach(struct pciback_device *pdev, int gnt_ref, "Error binding event channel to IRQ"); goto out; } + + spin_lock(&pdev->dev_lock); pdev->evtchn_irq = err; + spin_unlock(&pdev->dev_lock); err = 0; dev_dbg(&pdev->xdev->dev, "Attached!\n"); @@ -122,7 +134,6 @@ static int pciback_attach(struct pciback_device *pdev) int gnt_ref, remote_evtchn; char *magic = NULL; - spin_lock(&pdev->dev_lock); /* Make sure we only do this setup once */ if (xenbus_read_driver_state(pdev->xdev->nodename) != @@ -168,7 +179,6 @@ static int pciback_attach(struct pciback_device *pdev) dev_dbg(&pdev->xdev->dev, "Connected? %d\n", err); out: - spin_unlock(&pdev->dev_lock); kfree(magic); @@ -340,7 +350,6 @@ static int pciback_reconfigure(struct pciback_device *pdev) char state_str[64]; char dev_str[64]; - spin_lock(&pdev->dev_lock); dev_dbg(&pdev->xdev->dev, "Reconfiguring device ...\n"); @@ -481,8 +490,6 @@ static int pciback_reconfigure(struct pciback_device *pdev) } out: - spin_unlock(&pdev->dev_lock); - return 0; } @@ -539,8 +546,6 @@ static int pciback_setup_backend(struct pciback_device *pdev) char dev_str[64]; char state_str[64]; - spin_lock(&pdev->dev_lock); - /* It's possible we could get the call to setup twice, so make sure * we're not already connected. */ @@ -621,8 +626,6 @@ static int pciback_setup_backend(struct pciback_device *pdev) "Error switching to initialised state!"); out: - spin_unlock(&pdev->dev_lock); - if (!err) /* see if pcifront is already configured (if not, we'll wait) */ pciback_attach(pdev); @@ -669,6 +672,7 @@ static int pciback_xenbus_probe(struct xenbus_device *dev, pciback_be_watch); if (err) goto out; + pdev->be_watching = 1; /* We need to force a call to our callback here in case @@ -708,8 +712,8 @@ int __init pciback_xenbus_register(void) { pciback_wq = create_workqueue("pciback_workqueue"); if (!pciback_wq) { - printk(KERN_ERR "pciback_xenbus_register: create" - "pciback_workqueue failed\n"); + printk(KERN_ERR "%s: create" + "pciback_workqueue failed\n",__FUNCTION__); return -EFAULT; } return xenbus_register_backend(&xenbus_pciback_driver); _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel From xen-devel-bounces@lists.xensource.com Wed Sep 21 14:11:45 2011 Return-path: <xen-devel-bounces@lists.xensource.com> Envelope-to: www-data@lists.xensource.com Delivery-date: Wed, 21 Sep 2011 14:11:45 -0700 Received: from localhost ([127.0.0.1] helo=lists.colo.xensource.com) by lists.xensource.com with esmtp (Exim 4.43) id 1R6U53-0007mT-1H; Wed, 21 Sep 2011 14:11:45 -0700 Received: from mail27.messagelabs.com ([193.109.254.147]) by lists.xensource.com with esmtp (Exim 4.43) id 1R6U4Q-0007aY-1I for xen-devel@lists.xensource.com; Wed, 21 Sep 2011 14:11:06 -0700 X-Env-Sender: konrad@oracle.com X-Msg-Ref: server-15.tower-27.messagelabs.com!1316639452!49736280!1 X-Originating-IP: [141.146.126.227] X-StarScan-Version: 6.4.1; banners=-,-,- X-VirusChecked: Checked Received: (qmail 31150 invoked from network); 21 Sep 2011 21:10:54 -0000 Received: from acsinet15.oracle.com (HELO acsinet15.oracle.com) (141.146.126.227) by server-15.tower-27.messagelabs.com with DHE-RSA-AES256-SHA encrypted SMTP; 21 Sep 2011 21:10:54 -0000 Received: from acsinet22.oracle.com (acsinet22.oracle.com [141.146.126.238]) by acsinet15.oracle.com (Switch-3.4.4/Switch-3.4.4) with ESMTP id p8LLAtXN019144 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Wed, 21 Sep 2011 21:10:57 GMT Received: from acsmt356.oracle.com (acsmt356.oracle.com [141.146.40.156]) by acsinet22.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id p8LLAsnv000079 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 21 Sep 2011 21:10:55 GMT Received: from abhmt108.oracle.com (abhmt108.oracle.com [141.146.116.60]) by acsmt356.oracle.com (8.12.11.20060308/8.12.11) with ESMTP id p8LLAnpT006688; Wed, 21 Sep 2011 16:10:49 -0500 Received: from oracle.com (/209.6.55.207) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Wed, 21 Sep 2011 14:10:49 -0700 Received: by oracle.com (Postfix, from userid 1000) id AC6B61434; Wed, 21 Sep 2011 17:10:55 -0400 (EDT) Date: Wed, 21 Sep 2011 17:10:55 -0400 From: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com> To: Ian Campbell <Ian.Campbell@eu.citrix.com> Message-ID: <20110921211055.GA30029@phenom.oracle.com> References: <1316608670-23167-1-git-send-email-stefano.stabellini@eu.citrix.com> <20110921185102.GJ17357@phenom.oracle.com> <1316632095.5182.33.camel@dagon.hellion.org.uk> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <1316632095.5182.33.camel@dagon.hellion.org.uk> User-Agent: Mutt/1.5.21 (2010-09-15) X-Source-IP: acsinet22.oracle.com [141.146.126.238] X-Auth-Type: Internal IP X-CT-RefId: str=0001.0A02020A.4E7A52E1.0052:SCFMA922111,ss=1,re=-4.000,fgs=0 Cc: "jeremy@goop.org" <jeremy@goop.org>, "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>, Stefano Stabellini <Stefano.Stabellini@eu.citrix.com> Subject: [Xen-devel] Re: [PATCH] xen: change XEN_PLATFORM_PCI to bool default y X-BeenThere: xen-devel@lists.xensource.com X-Mailman-Version: 2.1.5 Precedence: list List-Id: Xen developer discussion <xen-devel.lists.xensource.com> List-Unsubscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe> List-Post: <mailto:xen-devel@lists.xensource.com> List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help> List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=subscribe> Sender: xen-devel-bounces@lists.xensource.com Errors-To: xen-devel-bounces@lists.xensource.com On Wed, Sep 21, 2011 at 08:08:15PM +0100, Ian Campbell wrote: > On Wed, 2011-09-21 at 19:51 +0100, Konrad Rzeszutek Wilk wrote: > > On Wed, Sep 21, 2011 at 01:37:50PM +0100, stefano.stabellini@eu.citrix.com wrote: > > > From: Stefano Stabellini <stefano.stabellini@eu.citrix.com> > > > > > > The xen-platform-pci module is small and for PV on HVM guests is a > > > > How small? > > IIRC it is single digit numbers of kb. > > > Does it get removed from memory if it never gets loaded? > > > > > requirement for xenbus. > > > > Ok, should it then have a depency on XenBus as well? > > xenbus can't be a module (which is why allowing platform-pci to be is > causing problems). > > > Linus does not like the 'default y' very much. He actually dislikes > > it quite much as I found when he tore Dan's behind about cleancache. > > In particular case the option is gated on a dependency on another Xen > option (PVHVM) which doesn't default on. But if you do select PVHVM you > certainly want this option, so I think that's ok (why else would > 'default y' even exist?) > > > .. so I think making it 'default n' is a better option or perhaps > > making it depend on some other functionality? Or perhaps just remove > > the tristate/bool altogether so it gets activated if XEN_PVHVM > > is set? > > > > Or remove the XEN_PLATFORM_PCI config option completly and make the > > config files that build this driver be CONFIG_XENPVHM dependent? > > That would work too. Even better would be to make it an invisible > Kconfig symbol which PVHVM just selects. <nods> Or that since you can't really do PVHVM without the platform PCI driver. _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel From xen-devel-bounces@lists.xensource.com Wed Sep 21 14:13:36 2011 Return-path: <xen-devel-bounces@lists.xensource.com> Envelope-to: www-data@lists.xensource.com Delivery-date: Wed, 21 Sep 2011 14:13:36 -0700 Received: from localhost ([127.0.0.1] helo=lists.colo.xensource.com) by lists.xensource.com with esmtp (Exim 4.43) id 1R6U6q-0008AH-Am; Wed, 21 Sep 2011 14:13:36 -0700 Received: from mail21.messagelabs.com ([85.158.143.35]) by lists.xensource.com with esmtp (Exim 4.43) id 1R6U6M-0007yR-Ff for xen-devel@lists.xensource.com; Wed, 21 Sep 2011 14:13:06 -0700 X-Env-Sender: konrad@oracle.com X-Msg-Ref: server-13.tower-21.messagelabs.com!1316639576!49820472!1 X-Originating-IP: [141.146.126.227] X-StarScan-Version: 6.4.1; banners=-,-,- X-VirusChecked: Checked Received: (qmail 7600 invoked from network); 21 Sep 2011 21:12:57 -0000 Received: from acsinet15.oracle.com (HELO acsinet15.oracle.com) (141.146.126.227) by server-13.tower-21.messagelabs.com with DHE-RSA-AES256-SHA encrypted SMTP; 21 Sep 2011 21:12:57 -0000 Received: from acsinet21.oracle.com (acsinet21.oracle.com [141.146.126.237]) by acsinet15.oracle.com (Switch-3.4.4/Switch-3.4.4) with ESMTP id p8LLCxvv022980 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Wed, 21 Sep 2011 21:13:01 GMT Received: from acsmt356.oracle.com (acsmt356.oracle.com [141.146.40.156]) by acsinet21.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id p8LLCwQ2009501 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 21 Sep 2011 21:12:59 GMT Received: from abhmt101.oracle.com (abhmt101.oracle.com [141.146.116.53]) by acsmt356.oracle.com (8.12.11.20060308/8.12.11) with ESMTP id p8LLCrAB008125; Wed, 21 Sep 2011 16:12:53 -0500 Received: from oracle.com (/209.6.55.207) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Wed, 21 Sep 2011 14:12:53 -0700 Received: by oracle.com (Postfix, from userid 1000) id EDD4D1434; Wed, 21 Sep 2011 17:12:59 -0400 (EDT) Date: Wed, 21 Sep 2011 17:12:59 -0400 From: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com> To: Jan Beulich <JBeulich@suse.com> Subject: Re: [Xen-devel] Re: [PATCH] xen/pciback: Use mutexes when working with Xenbus state transitions. Message-ID: <20110921211259.GB30029@phenom.oracle.com> References: <20110916190601.GA31796@phenom.oracle.com> <4E7738E90200007800056A54@nat28.tlf.novell.com> <4E773D440200007800056A6D@nat28.tlf.novell.com> <20110921210838.GA1016@phenom.oracle.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20110921210838.GA1016@phenom.oracle.com> User-Agent: Mutt/1.5.21 (2010-09-15) X-Source-IP: acsinet21.oracle.com [141.146.126.237] X-Auth-Type: Internal IP X-CT-RefId: str=0001.0A02020B.4E7A535D.009E:SCFMA922111,ss=1,re=-4.000,fgs=0 Cc: xen-devel@lists.xensource.com, linux-kernel@vger.kernel.org X-BeenThere: xen-devel@lists.xensource.com X-Mailman-Version: 2.1.5 Precedence: list List-Id: Xen developer discussion <xen-devel.lists.xensource.com> List-Unsubscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe> List-Post: <mailto:xen-devel@lists.xensource.com> List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help> List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=subscribe> Sender: xen-devel-bounces@lists.xensource.com Errors-To: xen-devel-bounces@lists.xensource.com On Wed, Sep 21, 2011 at 05:08:38PM -0400, Konrad Rzeszutek Wilk wrote: > On Mon, Sep 19, 2011 at 12:01:56PM +0100, Jan Beulich wrote: > > >>> On 19.09.11 at 12:43, "Jan Beulich" <JBeulich@suse.com> wrote: > > >>>> On 16.09.11 at 21:06, Konrad Rzeszutek Wilk <konrad.wilk@oracle.com> wrote: > > > > > >> The caller that orchestrates the state changes is xenwatch_thread > > >> and it takes a mutex. In our processing of Xenbus states we can take > > >> the luxery of going to sleep on a mutex, so lets do that and > > > > > > This is only the direct conversion of existing spinlock accesses in > > > xenbus.c. However, in the course of converting from the legacy > > > implementation you stripped a couple more (in xen_pcibk_attach(), > > > xen_pcibk_reconfigure(), and xen_pcibk_setup_backend()), and > > > > Actually, xen_pcibk_attach() has its lock taken in xen_pcibk_do_attach(), > > so no change needed there. > > > > In xen_pcibk_reconfigure() and xen_pcibk_setup_backend() the locking > > may be redundant with the one in passthrough.c/vpci.c - is that the > > basis upon which you removed the locks taken there? > > No. I believe the reason was much simpler.. it was b/c of this patch (see below). > But for the life of me I don't recall what deadlock we could hit. You know what.. I think the issue was that I was trying to fix the "sleeping on a spinlock" issue and was moving the spinlocks around to fix it. .. Without realizing I could have just used a mutex. _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel From xen-devel-bounces@lists.xensource.com Wed Sep 21 14:19:20 2011 Return-path: <xen-devel-bounces@lists.xensource.com> Envelope-to: www-data@lists.xensource.com Delivery-date: Wed, 21 Sep 2011 14:19:20 -0700 Received: from localhost ([127.0.0.1] helo=lists.colo.xensource.com) by lists.xensource.com with esmtp (Exim 4.43) id 1R6UCO-0000AB-Cu; Wed, 21 Sep 2011 14:19:20 -0700 Received: from mail27.messagelabs.com ([193.109.254.147]) by lists.xensource.com with smtp (Exim 4.43) id 1R6UBl-0008PA-0A; Wed, 21 Sep 2011 14:18:45 -0700 X-Env-Sender: ms@it-infrastrukturen.org X-Msg-Ref: server-14.tower-27.messagelabs.com!1316639903!37100957!1 X-Originating-IP: [88.198.203.66] X-StarScan-Version: 6.4.1; banners=-,-,- X-VirusChecked: Checked Received: (qmail 3595 invoked from network); 21 Sep 2011 21:18:23 -0000 Received: from srv1.born2b3.net (HELO srv1.born2b3.net) (88.198.203.66) by server-14.tower-27.messagelabs.com with SMTP; 21 Sep 2011 21:18:23 -0000 Received: from [192.168.1.100] (84-73-66-195.dclient.hispeed.ch [84.73.66.195]) by srv1.born2b3.net (Postfix) with ESMTPSA id 82D1BC07FF; Wed, 21 Sep 2011 21:18:36 +0000 (UTC) Message-ID: <4E7A5429.7050105@it-infrastrukturen.org> Date: Wed, 21 Sep 2011 23:16:25 +0200 From: Mark Schneider <ms@it-infrastrukturen.org> User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.1.16) Gecko/20110307 Icedove/3.0.11 MIME-Version: 1.0 To: Jonathan Ludlam <Jonathan.Ludlam@eu.citrix.com> References: <2A06687B-208D-4F90-B98F-5A7EB07A762B@eu.citrix.com> In-Reply-To: <2A06687B-208D-4F90-B98F-5A7EB07A762B@eu.citrix.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: "M. Schneider" <ms@it-infrastrukturen.com>, "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>, "xen-users@lists.xensource.com List" <xen-users@lists.xensource.com> Subject: [Xen-devel] Re: [Xen-users] XCP 1.1 RC - Is there xcp tutorial available? X-BeenThere: xen-devel@lists.xensource.com X-Mailman-Version: 2.1.5 Precedence: list List-Id: Xen developer discussion <xen-devel.lists.xensource.com> List-Unsubscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe> List-Post: <mailto:xen-devel@lists.xensource.com> List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help> List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=subscribe> Sender: xen-devel-bounces@lists.xensource.com Errors-To: xen-devel-bounces@lists.xensource.com Am 21.09.2011 13:02, schrieb Jonathan Ludlam: > Hi all, > > XCP 1.1 Release Candidate is ready to be tested. Changes since Beta: > > * License expiry crept back in. It has now crept out again. > * For OpenStack and others, support for ebtables and other netfilter options have been added to the kernel > * License restrictions (e.g. memory checks) have been removed > * Xapi version override feature has been added back in > > Please give this a good test, and if it's all OK I propose to call this XCP 1.1 final. > > The ISOs are available here: > > http://downloads.xen.org/XCP/50674/index.html > > Cheers, > > Jon > > > _______________________________________________ > Xen-users mailing list > Xen-users@lists.xensource.com > http://lists.xensource.com/xen-users > Thank you for the great software (xcp 1.1 rc). I have just successfully installed it on HP DL385 g7 server with two Opteron 6180SE CPUs, 32GB RAM and local RAID5. Where can I find a tutorial with step-by-step description for creating new HVMs? I have used already some documentation for xen server however I am not sure if it is appropriate. Further more info what can be tested (like PCI pass through, interface bonding, performance tests etc) would make sense. Regards / thank you, Mark -- ms@it-infrastrukturen.org _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel From xen-devel-bounces@lists.xensource.com Wed Sep 21 15:11:38 2011 Return-path: <xen-devel-bounces@lists.xensource.com> Envelope-to: www-data@lists.xensource.com Delivery-date: Wed, 21 Sep 2011 15:11:38 -0700 Received: from localhost ([127.0.0.1] helo=lists.colo.xensource.com) by lists.xensource.com with esmtp (Exim 4.43) id 1R6V0z-0002HL-Ge; Wed, 21 Sep 2011 15:11:37 -0700 Received: from mail182.messagelabs.com ([85.158.139.83]) by lists.xensource.com with smtp (Exim 4.43) id 1R6UzZ-000248-0Y for xen-devel@lists.xensource.com; Wed, 21 Sep 2011 15:10:10 -0700 X-Env-Sender: caker@theshore.net X-Msg-Ref: server-7.tower-182.messagelabs.com!1316643005!14240726!1 X-Originating-IP: [67.18.92.50] X-StarScan-Version: 6.4.1; banners=-,-,- X-VirusChecked: Checked Received: (qmail 21469 invoked from network); 21 Sep 2011 22:10:05 -0000 Received: from ns.theshore.net (HELO www.theshore.net) (67.18.92.50) by server-7.tower-182.messagelabs.com with SMTP; 21 Sep 2011 22:10:05 -0000 Received: from beefcake.linlan (173-161-199-49-Philadelphia.hfc.comcastbusiness.net [173.161.199.49]) by www.theshore.net (8.13.6/8.9.1) with ESMTP id p8LM9uX1024331; Wed, 21 Sep 2011 18:09:56 -0400 Message-ID: <4E7A60B4.2010108@theshore.net> Date: Wed, 21 Sep 2011 18:09:56 -0400 From: "Christopher S. Aker" <caker@theshore.net> User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.6; en-US; rv:1.9.2.22) Gecko/20110902 Lightning/1.0b2 Thunderbird/3.1.14 MIME-Version: 1.0 To: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com> Subject: Re: [Xen-devel] Re: kernel BUG at mm/swapfile.c:2527! [was 3.0.0 Xen pv guest - BUG: Unable to handle] References: <4E5BA49D.5060800@theshore.net> <20110829150734.GB24825@dumpdata.com> <1314704744.28989.2.camel@zakaz.uk.xensource.com> <4E5E9CDB.3070706@theshore.net> <20110906171319.GB29839@dumpdata.com> <4E6E2E11.1030602@theshore.net> <20110912161127.GB16100@oracle.com> <4E724ACD.1050207@theshore.net> <4E724F64.5080103@theshore.net> <CEE295A1-B386-4A2A-A16C-9AC29DE174E8@theshore.net> <20110921180423.GC17357@phenom.oracle.com> In-Reply-To: <20110921180423.GC17357@phenom.oracle.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: Jeremy Fitzhardinge <jeremy@goop.org>, "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>, Ian Campbell <Ian.Campbell@citrix.com>, LKML <linux-kernel@vger.kernel.org> X-BeenThere: xen-devel@lists.xensource.com X-Mailman-Version: 2.1.5 Precedence: list List-Id: Xen developer discussion <xen-devel.lists.xensource.com> List-Unsubscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe> List-Post: <mailto:xen-devel@lists.xensource.com> List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help> List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=subscribe> Sender: xen-devel-bounces@lists.xensource.com Errors-To: xen-devel-bounces@lists.xensource.com On 9/21/11 2:04 PM, Konrad Rzeszutek Wilk wrote: > Excellent. Can you also send me your .config to make sure I've the right > knobs set? Certainly. I included my kernel binary along with its config: http://www.theshore.net/~caker/xen/BUGS/swapfile/ Thanks! -Chris _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel From xen-devel-bounces@lists.xensource.com Wed Sep 21 15:30:44 2011 Return-path: <xen-devel-bounces@lists.xensource.com> Envelope-to: www-data@lists.xensource.com Delivery-date: Wed, 21 Sep 2011 15:30:44 -0700 Received: from localhost ([127.0.0.1] helo=lists.colo.xensource.com) by lists.xensource.com with esmtp (Exim 4.43) id 1R6VJU-0003Y6-NY; Wed, 21 Sep 2011 15:30:44 -0700 Received: from mail21.messagelabs.com ([85.158.143.35]) by lists.xensource.com with esmtp (Exim 4.43) id 1R6VIw-0003M0-Hk for xen-devel@lists.xensource.com; Wed, 21 Sep 2011 15:30:11 -0700 X-Env-Sender: dan.magenheimer@oracle.com X-Msg-Ref: server-2.tower-21.messagelabs.com!1316644204!34998812!1 X-Originating-IP: [141.146.126.227] X-StarScan-Version: 6.4.1; banners=-,-,- X-VirusChecked: Checked Received: (qmail 30180 invoked from network); 21 Sep 2011 22:30:06 -0000 Received: from acsinet15.oracle.com (HELO acsinet15.oracle.com) (141.146.126.227) by server-2.tower-21.messagelabs.com with DHE-RSA-AES256-SHA encrypted SMTP; 21 Sep 2011 22:30:06 -0000 Received: from rtcsinet22.oracle.com (rtcsinet22.oracle.com [66.248.204.30]) by acsinet15.oracle.com (Switch-3.4.4/Switch-3.4.4) with ESMTP id p8LMU1BS017267 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Wed, 21 Sep 2011 22:30:04 GMT Received: from acsmt356.oracle.com (acsmt356.oracle.com [141.146.40.156]) by rtcsinet22.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id p8LMU0Yp029017 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 21 Sep 2011 22:30:01 GMT Received: from abhmt110.oracle.com (abhmt110.oracle.com [141.146.116.62]) by acsmt356.oracle.com (8.12.11.20060308/8.12.11) with ESMTP id p8LMTtqn025909; Wed, 21 Sep 2011 17:29:55 -0500 MIME-Version: 1.0 Message-ID: <039081bd-a6de-46c6-99de-242b76f83eac@default> Date: Wed, 21 Sep 2011 15:29:38 -0700 (PDT) From: Dan Magenheimer <dan.magenheimer@oracle.com> To: David Vrabel <david.vrabel@citrix.com>, xen-devel@lists.xensource.com Subject: RE: [Xen-devel] xen: memory initialization/balloon fixes (#3) References: <1316089768-22461-1-git-send-email-david.vrabel@citrix.com 63997331-e53b-48e5-bf7c-87141aae49d6@default> In-Reply-To: <63997331-e53b-48e5-bf7c-87141aae49d6@default> X-Priority: 3 X-Mailer: Oracle Beehive Extensions for Outlook 2.0.1.4.1.0 (410211) [OL 12.0.6557.5001] Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable X-Source-IP: rtcsinet22.oracle.com [66.248.204.30] X-CT-RefId: str=0001.0A090209.4E7A656C.00A0,ss=1,re=0.000,fgs=0 Cc: Konrad Wilk <konrad.wilk@oracle.com> X-BeenThere: xen-devel@lists.xensource.com X-Mailman-Version: 2.1.5 Precedence: list List-Id: Xen developer discussion <xen-devel.lists.xensource.com> List-Unsubscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe> List-Post: <mailto:xen-devel@lists.xensource.com> List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help> List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=subscribe> Sender: xen-devel-bounces@lists.xensource.com Errors-To: xen-devel-bounces@lists.xensource.com > From: Dan Magenheimer > Sent: Tuesday, September 20, 2011 10:58 AM > To: David Vrabel; xen-devel@lists.xensource.com > Cc: Konrad Wilk > Subject: RE: [Xen-devel] xen: memory initialization/balloon fixes (#3) >=20 > > From: David Vrabel [mailto:david.vrabel@citrix.com] > > Sent: Thursday, September 15, 2011 6:29 AM > > To: xen-devel@lists.xensource.com > > Cc: Konrad Rzeszutek Wilk > > Subject: [Xen-devel] xen: memory initialization/balloon fixes (#3) > > > > This set of patches fixes some bugs in the memory initialization under > > Xen and in Xen's memory balloon driver. They can make 100s of MB of > > additional RAM available (depending on the system/configuration). >=20 > Hi David -- >=20 > Thanks for your patches! I am looking at a memory capacity/ballooning > weirdness that I hoped your patchset might fix, but so far it has not. > I'm wondering if there was an earlier fix that you are building upon > and that I am missing. >=20 > My problem occurs in a PV domU with an upstream-variant kernel based > on 3.0.5. The problem is that the total amount of memory as seen > from inside the guest is always substantially less than the amount > of memory seen from outside the guest. The difference seems to > be fixed within a given boot, but assigning a different vm.cfg mem=3D > changes the amount. (For example, the difference D is about 18MB on > a mem=3D128 boot and about 36MB on a mem=3D1024 boot.) >=20 > Part B of the problem (and the one most important to me) is that > setting /sys/devices/system/xen_memory/xen_memory0/target_kb > to X results in a MemTotal inside the domU (as observed by > "head -1 /proc/meminfo") of X-D. This can be particularly painful > when X is aggressively small as X-D may result in OOMs. > To use kernel function/variable names (and I observed this with > some debugging code), when balloon_set_new_target(X) is called > totalram_pages gets driven to X-D. >=20 > I am using xm, but I don't think this is a toolchain problem because > the problem can be provoked and observed entirely within the guest... > though I suppose it is possible that that the initial "mem=3D" is the > origin of the problem and the balloon driver just perpetuates > the initial difference. (I tried xl... same problem... my > Xen/toolset version is 4.1.2-rc1-pre cset 23102) >=20 > The descriptions in your patchset sound exactly as if you are > attacking the same problem, but I'm not seeing any improved > result. Any thoughts or ideas? Hi David (and Konrad) -- Don't know if you are looking at this or not (or if your patchset was intended to fix this problem or not). Looking into Part B of the problem, it appears that in balloon_init() the initial value of balloon_stats.current_pages may be set incorrectly. I'm finding that (for a PV domain), both nr_pages and max_pfn match mem=3D, but totalram_pages is substantially less. Current_pages should never be higher than the actual number of pages of RAM seen by the kernel, should it? By changing max_pfn to totalram_pages in the initialization of balloon_stats.current_pages in balloon_init(), my problem goes away... almost. With that fix, setting the balloon target to NkB results in totalram_pages (as seen from "head -1 /proc/meminfo") going to (N+6092)kB. The value 6092 appears to be fixed regardless of mem=3D and the fact that the result is off by 6092kB is annoying but, since it is higher rather than lower and it is fixed, it is not nearly as dangerous IMHO. Since I'm not as sure of the RAM-ifications (pun intended) of this change, I'd appreciate any comments you might have. Also, this doesn't fix the large difference between MEM(K) reported by the domain in xentop (which matches mem=3D) and totalram_pages but, though also annoying, that's not such a big problem IMHO. I'm guessing this may be space taken for PV pagetables or something like that, though the amount of RAM that "disappears" on a small-RAM guest (e.g. mem=3D128) is very high (e.g. ~18MB). But for my purposes (selfballooning), this doesn't matter (much) so I don't plan to pursue this right now. Thanks for any feedback! Dan P.S. I also haven't looked at the HVM code in balloon_init. _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel From xen-devel-bounces@lists.xensource.com Wed Sep 21 15:43:24 2011 Return-path: <xen-devel-bounces@lists.xensource.com> Envelope-to: www-data@lists.xensource.com Delivery-date: Wed, 21 Sep 2011 15:43:24 -0700 Received: from localhost ([127.0.0.1] helo=lists.colo.xensource.com) by lists.xensource.com with esmtp (Exim 4.43) id 1R6VVj-0004HG-VM; Wed, 21 Sep 2011 15:43:23 -0700 Received: from mail216.messagelabs.com ([85.158.143.99]) by lists.xensource.com with esmtp (Exim 4.43) id 1R6VUx-00044C-BM for xen-devel@lists.xensource.com; Wed, 21 Sep 2011 15:42:35 -0700 X-Env-Sender: jeremy@goop.org X-Msg-Ref: server-11.tower-216.messagelabs.com!1316644950!11566620!1 X-Originating-IP: [74.207.240.146] X-StarScan-Version: 6.4.1; banners=-,-,- X-VirusChecked: Checked Received: (qmail 12168 invoked from network); 21 Sep 2011 22:42:31 -0000 Received: from claw.goop.org (HELO claw.goop.org) (74.207.240.146) by server-11.tower-216.messagelabs.com with DHE-RSA-AES256-SHA encrypted SMTP; 21 Sep 2011 22:42:31 -0000 Received: from saboo.goop.org (unknown [IPv6:2001:470:1f05:899:5833:5dff:fe9e:bf0d]) (Authenticated sender: smtp-saboo) by claw.goop.org (Postfix) with ESMTPSA id 7ACF6971C; Wed, 21 Sep 2011 15:42:28 -0700 (PDT) Received: from saboo.goop.org (localhost [IPv6:::1]) by saboo.goop.org (Postfix) with ESMTP id E13AF20499; Wed, 21 Sep 2011 15:42:21 -0700 (PDT) Message-ID: <4E7A684D.7030807@goop.org> Date: Wed, 21 Sep 2011 15:42:21 -0700 From: Jeremy Fitzhardinge <jeremy@goop.org> User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:6.0.2) Gecko/20110906 Thunderbird/6.0.2 MIME-Version: 1.0 To: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com> Subject: Re: [Xen-devel] RE: [PATCH 5/7] xen/acpi: Domain0 acpi parser related platform hypercall References: <1314815484-4668-1-git-send-email-konrad.wilk@oracle.com> <1314815484-4668-6-git-send-email-konrad.wilk@oracle.com> <9F57BF860713DF4BA3EFA4F8C6DFEDAC16F3F665@ORSMSX101.amr.corp.intel.com> <4E67A9E7.2020802@goop.org> <20110921192859.GA2606@phenom.oracle.com> In-Reply-To: <20110921192859.GA2606@phenom.oracle.com> X-Enigmail-Version: 1.3.1 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: "Brown, Len" <len.brown@intel.com>, "Tian, Kevin" <kevin.tian@intel.com>, "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>, "keir@xen.org" <keir@xen.org>, "Wang, Shane" <shane.wang@intel.com>, "Cihula, Joseph" <joseph.cihula@intel.com>, "x86@kernel.org" <x86@kernel.org>, "linux-acpi@vger.kernel.org" <linux-acpi@vger.kernel.org>, "tboot-devel@lists.sourceforge.net" <tboot-devel@lists.sourceforge.net>, Fitzhardinge <jeremy.fitzhardinge@citrix.com>, "tglx@linutronix.de" <tglx@linutronix.de>, "Yu, Ke" <ke.yu@intel.com>, "hpa@zytor.com" <hpa@zytor.com>, "liang.tang@oracle.com" <liang.tang@oracle.com>, "linux-pm@lists.linux-foundation.org" <linux-pm@lists.linux-foundation.org> X-BeenThere: xen-devel@lists.xensource.com X-Mailman-Version: 2.1.5 Precedence: list List-Id: Xen developer discussion <xen-devel.lists.xensource.com> List-Unsubscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe> List-Post: <mailto:xen-devel@lists.xensource.com> List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help> List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=subscribe> Sender: xen-devel-bounces@lists.xensource.com Errors-To: xen-devel-bounces@lists.xensource.com On 09/21/2011 12:29 PM, Konrad Rzeszutek Wilk wrote: > On Wed, Sep 07, 2011 at 10:29:11AM -0700, Jeremy Fitzhardinge wrote: >> On 09/06/2011 10:50 PM, Cihula, Joseph wrote: >>>> From: Konrad Rzeszutek Wilk [mailto:konrad.wilk@oracle.com] >>>> Sent: Wednesday, August 31, 2011 11:31 AM >>>> >>>> From: Yu Ke <ke.yu@intel.com> >>>> >>>> This patches implements the xen_platform_op hypercall, to pass the parsed ACPI info to hypervisor. >>>> >>>> Signed-off-by: Yu Ke <ke.yu@intel.com> >>>> Signed-off-by: Tian Kevin <kevin.tian@intel.com> >>>> Signed-off-by: Jeremy Fitzhardinge <jeremy.fitzhardinge@citrix.com> >>>> [v1: Added DEFINE_GUEST.. in appropiate headers] >>>> [v2: Ripped out typedefs] >>>> Signed-off-by: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com> >>>> --- >>>> arch/ia64/include/asm/xen/interface.h | 1 + >>>> arch/x86/include/asm/xen/interface.h | 1 + >>>> include/xen/interface/platform.h | 320 +++++++++++++++++++++++++++++++++ >>>> include/xen/interface/xen.h | 1 + >>>> 4 files changed, 323 insertions(+), 0 deletions(-) create mode 100644 >>>> include/xen/interface/platform.h >>>> >>>> diff --git a/arch/ia64/include/asm/xen/interface.h b/arch/ia64/include/asm/xen/interface.h >>>> index e951e74..1d2427d 100644 >>>> --- a/arch/ia64/include/asm/xen/interface.h >>>> +++ b/arch/ia64/include/asm/xen/interface.h >>>> @@ -76,6 +76,7 @@ DEFINE_GUEST_HANDLE(char); DEFINE_GUEST_HANDLE(int); >>>> DEFINE_GUEST_HANDLE(long); DEFINE_GUEST_HANDLE(void); >>>> +DEFINE_GUEST_HANDLE(uint64_t); >>>> >>>> typedef unsigned long xen_pfn_t; >>>> DEFINE_GUEST_HANDLE(xen_pfn_t); >>>> diff --git a/arch/x86/include/asm/xen/interface.h b/arch/x86/include/asm/xen/interface.h >>>> index 5d4922a..a1f2db5 100644 >>>> --- a/arch/x86/include/asm/xen/interface.h >>>> +++ b/arch/x86/include/asm/xen/interface.h >>>> @@ -55,6 +55,7 @@ DEFINE_GUEST_HANDLE(char); DEFINE_GUEST_HANDLE(int); >>>> DEFINE_GUEST_HANDLE(long); DEFINE_GUEST_HANDLE(void); >>>> +DEFINE_GUEST_HANDLE(uint64_t); >>>> #endif >>>> >>>> #ifndef HYPERVISOR_VIRT_START >>>> diff --git a/include/xen/interface/platform.h b/include/xen/interface/platform.h >>>> new file mode 100644 >>>> index 0000000..c168468 >>>> --- /dev/null >>>> +++ b/include/xen/interface/platform.h >>> Why are you adding so many new hypercalls that aren't being used in this patchset? >> May as well bring in all the platform-related hypercall definitions at >> once rather than be piecemeal. > Actually, I think making it piecemeal might be easier. As in > 1). Not all of the hypercalls are going to be upstreamed. > 2). It gives a nice history/idea of what is actually implemented when > seaching the code. > 3). git annotate can give precise git commits for when an functionality was > added. > > But maybe I am just overthinking it. If platform.h gets put on multiple branches which depend on it, it would be easier to merge if it were the same copy in every branch rather than trying to merge lots of different variants. J _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel From xen-devel-bounces@lists.xensource.com Wed Sep 21 15:44:29 2011 Return-path: <xen-devel-bounces@lists.xensource.com> Envelope-to: www-data@lists.xensource.com Delivery-date: Wed, 21 Sep 2011 15:44:29 -0700 Received: from localhost ([127.0.0.1] helo=lists.colo.xensource.com) by lists.xensource.com with esmtp (Exim 4.43) id 1R6VWn-0004dz-Nr; Wed, 21 Sep 2011 15:44:29 -0700 Received: from mail216.messagelabs.com ([85.158.143.99]) by lists.xensource.com with esmtp (Exim 4.43) id 1R6VVI-00048e-Ax for xen-devel@lists.xensource.com; Wed, 21 Sep 2011 15:42:59 -0700 X-Env-Sender: konrad@oracle.com X-Msg-Ref: server-2.tower-216.messagelabs.com!1316644971!18708609!1 X-Originating-IP: [148.87.113.117] X-StarScan-Version: 6.4.1; banners=-,-,- X-VirusChecked: Checked Received: (qmail 19508 invoked from network); 21 Sep 2011 22:42:53 -0000 Received: from rcsinet15.oracle.com (HELO rcsinet15.oracle.com) (148.87.113.117) by server-2.tower-216.messagelabs.com with DHE-RSA-AES256-SHA encrypted SMTP; 21 Sep 2011 22:42:53 -0000 Received: from acsinet21.oracle.com (acsinet21.oracle.com [141.146.126.237]) by rcsinet15.oracle.com (Switch-3.4.4/Switch-3.4.4) with ESMTP id p8LMgnEE008929 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Wed, 21 Sep 2011 22:42:51 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 p8LMgmJ1000212 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 21 Sep 2011 22:42:49 GMT Received: from abhmt117.oracle.com (abhmt117.oracle.com [141.146.116.69]) by acsmt358.oracle.com (8.12.11.20060308/8.12.11) with ESMTP id p8LMghqX003235; Wed, 21 Sep 2011 17:42:43 -0500 Received: from oracle.com (/209.6.55.207) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Wed, 21 Sep 2011 15:42:42 -0700 Received: by oracle.com (Postfix, from userid 1000) id 3EE7D14EC; Wed, 21 Sep 2011 18:42:49 -0400 (EDT) From: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com> To: jbeulich@suse.com, linux-kernel@vger.kernel.org, xen-devel@lists.xensource.com Date: Wed, 21 Sep 2011 18:42:46 -0400 Message-Id: <1316644966-19386-3-git-send-email-konrad.wilk@oracle.com> X-Mailer: git-send-email 1.7.4.1 In-Reply-To: <1316644966-19386-1-git-send-email-konrad.wilk@oracle.com> References: <1316644966-19386-1-git-send-email-konrad.wilk@oracle.com> X-Source-IP: acsinet21.oracle.com [141.146.126.237] X-Auth-Type: Internal IP X-CT-RefId: str=0001.0A090209.4E7A686B.006F:SCFMA922111,ss=1,re=-4.000,fgs=0 Cc: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com> Subject: [Xen-devel] [PATCH 2/2] xen/pciback: use mutex rather than spinlock in vpci backend X-BeenThere: xen-devel@lists.xensource.com X-Mailman-Version: 2.1.5 Precedence: list List-Id: Xen developer discussion <xen-devel.lists.xensource.com> List-Unsubscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe> List-Post: <mailto:xen-devel@lists.xensource.com> List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help> List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=subscribe> Sender: xen-devel-bounces@lists.xensource.com Errors-To: xen-devel-bounces@lists.xensource.com Similar to the "xen/pciback: use mutex rather than spinlock in passthrough backend" this patch converts the vpci backend to use a mutex instead of a spinlock. Note that the code taking the lock won't ever get called from non-sleepable context Signed-off-by: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com> --- drivers/xen/xen-pciback/vpci.c | 26 +++++++++++--------------- 1 files changed, 11 insertions(+), 15 deletions(-) diff --git a/drivers/xen/xen-pciback/vpci.c b/drivers/xen/xen-pciback/vpci.c index a778552..01222d7 100644 --- a/drivers/xen/xen-pciback/vpci.c +++ b/drivers/xen/xen-pciback/vpci.c @@ -8,7 +8,7 @@ #include <linux/list.h> #include <linux/slab.h> #include <linux/pci.h> -#include <linux/spinlock.h> +#include <linux/mutex.h> #include "pciback.h" #define PCI_SLOT_MAX 32 @@ -16,7 +16,7 @@ struct vpci_dev_data { /* Access to dev_list must be protected by lock */ struct list_head dev_list[PCI_SLOT_MAX]; - spinlock_t lock; + struct mutex lock; }; static inline struct list_head *list_first(struct list_head *head) @@ -32,13 +32,12 @@ static struct pci_dev *__xen_pcibk_get_pci_dev(struct xen_pcibk_device *pdev, struct pci_dev_entry *entry; struct pci_dev *dev = NULL; struct vpci_dev_data *vpci_dev = pdev->pci_dev_data; - unsigned long flags; if (domain != 0 || bus != 0) return NULL; if (PCI_SLOT(devfn) < PCI_SLOT_MAX) { - spin_lock_irqsave(&vpci_dev->lock, flags); + mutex_lock(&vpci_dev->lock); list_for_each_entry(entry, &vpci_dev->dev_list[PCI_SLOT(devfn)], @@ -49,7 +48,7 @@ static struct pci_dev *__xen_pcibk_get_pci_dev(struct xen_pcibk_device *pdev, } } - spin_unlock_irqrestore(&vpci_dev->lock, flags); + mutex_unlock(&vpci_dev->lock); } return dev; } @@ -70,7 +69,6 @@ static int __xen_pcibk_add_pci_dev(struct xen_pcibk_device *pdev, int err = 0, slot, func = -1; struct pci_dev_entry *t, *dev_entry; struct vpci_dev_data *vpci_dev = pdev->pci_dev_data; - unsigned long flags; if ((dev->class >> 24) == PCI_BASE_CLASS_BRIDGE) { err = -EFAULT; @@ -89,7 +87,7 @@ static int __xen_pcibk_add_pci_dev(struct xen_pcibk_device *pdev, dev_entry->dev = dev; - spin_lock_irqsave(&vpci_dev->lock, flags); + mutex_lock(&vpci_dev->lock); /* Keep multi-function devices together on the virtual PCI bus */ for (slot = 0; slot < PCI_SLOT_MAX; slot++) { @@ -128,7 +126,7 @@ static int __xen_pcibk_add_pci_dev(struct xen_pcibk_device *pdev, "No more space on root virtual PCI bus"); unlock: - spin_unlock_irqrestore(&vpci_dev->lock, flags); + mutex_unlock(&vpci_dev->lock); /* Publish this device. */ if (!err) @@ -144,9 +142,8 @@ static void __xen_pcibk_release_pci_dev(struct xen_pcibk_device *pdev, int slot; struct vpci_dev_data *vpci_dev = pdev->pci_dev_data; struct pci_dev *found_dev = NULL; - unsigned long flags; - spin_lock_irqsave(&vpci_dev->lock, flags); + mutex_lock(&vpci_dev->lock); for (slot = 0; slot < PCI_SLOT_MAX; slot++) { struct pci_dev_entry *e; @@ -162,7 +159,7 @@ static void __xen_pcibk_release_pci_dev(struct xen_pcibk_device *pdev, } out: - spin_unlock_irqrestore(&vpci_dev->lock, flags); + mutex_unlock(&vpci_dev->lock); if (found_dev) pcistub_put_pci_dev(found_dev); @@ -177,7 +174,7 @@ static int __xen_pcibk_init_devices(struct xen_pcibk_device *pdev) if (!vpci_dev) return -ENOMEM; - spin_lock_init(&vpci_dev->lock); + mutex_init(&vpci_dev->lock); for (slot = 0; slot < PCI_SLOT_MAX; slot++) INIT_LIST_HEAD(&vpci_dev->dev_list[slot]); @@ -221,10 +218,9 @@ static int __xen_pcibk_get_pcifront_dev(struct pci_dev *pcidev, struct pci_dev_entry *entry; struct pci_dev *dev = NULL; struct vpci_dev_data *vpci_dev = pdev->pci_dev_data; - unsigned long flags; int found = 0, slot; - spin_lock_irqsave(&vpci_dev->lock, flags); + mutex_lock(&vpci_dev->lock); for (slot = 0; slot < PCI_SLOT_MAX; slot++) { list_for_each_entry(entry, &vpci_dev->dev_list[slot], @@ -242,7 +238,7 @@ static int __xen_pcibk_get_pcifront_dev(struct pci_dev *pcidev, } } } - spin_unlock_irqrestore(&vpci_dev->lock, flags); + mutex_lock(&vpci_dev->lock); return found; } -- 1.7.4.1 _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel From xen-devel-bounces@lists.xensource.com Wed Sep 21 15:45:28 2011 Return-path: <xen-devel-bounces@lists.xensource.com> Envelope-to: www-data@lists.xensource.com Delivery-date: Wed, 21 Sep 2011 15:45:28 -0700 Received: from localhost ([127.0.0.1] helo=lists.colo.xensource.com) by lists.xensource.com with esmtp (Exim 4.43) id 1R6VXk-00050q-PQ; Wed, 21 Sep 2011 15:45:28 -0700 Received: from mail27.messagelabs.com ([193.109.254.147]) by lists.xensource.com with esmtp (Exim 4.43) id 1R6VVI-00048f-TB for xen-devel@lists.xensource.com; Wed, 21 Sep 2011 15:42:59 -0700 X-Env-Sender: konrad@oracle.com X-Msg-Ref: server-8.tower-27.messagelabs.com!1316644956!47570739!1 X-Originating-IP: [141.146.126.227] X-StarScan-Version: 6.4.1; banners=-,-,- X-VirusChecked: Checked Received: (qmail 27978 invoked from network); 21 Sep 2011 22:42:37 -0000 Received: from acsinet15.oracle.com (HELO acsinet15.oracle.com) (141.146.126.227) by server-8.tower-27.messagelabs.com with DHE-RSA-AES256-SHA encrypted SMTP; 21 Sep 2011 22:42:37 -0000 Received: from rtcsinet21.oracle.com (rtcsinet21.oracle.com [66.248.204.29]) by acsinet15.oracle.com (Switch-3.4.4/Switch-3.4.4) with ESMTP id p8LMgnsg004758 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Wed, 21 Sep 2011 22:42:51 GMT Received: from acsmt357.oracle.com (acsmt357.oracle.com [141.146.40.157]) by rtcsinet21.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id p8LMgmh3013032 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 21 Sep 2011 22:42:49 GMT Received: from abhmt118.oracle.com (abhmt118.oracle.com [141.146.116.70]) by acsmt357.oracle.com (8.12.11.20060308/8.12.11) with ESMTP id p8LMgg0j019698; Wed, 21 Sep 2011 17:42:42 -0500 Received: from oracle.com (/209.6.55.207) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Wed, 21 Sep 2011 15:42:42 -0700 Received: by oracle.com (Postfix, from userid 1000) id 304E71434; Wed, 21 Sep 2011 18:42:49 -0400 (EDT) From: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com> To: jbeulich@suse.com, linux-kernel@vger.kernel.org, xen-devel@lists.xensource.com Date: Wed, 21 Sep 2011 18:42:44 -0400 Message-Id: <1316644966-19386-1-git-send-email-konrad.wilk@oracle.com> X-Mailer: git-send-email 1.7.4.1 X-Source-IP: rtcsinet21.oracle.com [66.248.204.29] X-CT-RefId: str=0001.0A020206.4E7A686C.002C,ss=1,re=0.000,fgs=0 Cc: Subject: [Xen-devel] [PATCH] xen-pciback patches for 3.2 (s/spinlock/mutex/) X-BeenThere: xen-devel@lists.xensource.com X-Mailman-Version: 2.1.5 Precedence: list List-Id: Xen developer discussion <xen-devel.lists.xensource.com> List-Unsubscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe> List-Post: <mailto:xen-devel@lists.xensource.com> List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help> List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=subscribe> Sender: xen-devel-bounces@lists.xensource.com Errors-To: xen-devel-bounces@lists.xensource.com 402c5e1 xen/pciback: miscellaneous adjustments 04df355 xen/pciback: use mutex rather than spinlock in passthrough backend 5fa9991 xen/pciback: use resource_size() which I've in the stable/drivers.bugfixes on oss.oracle.com (git://oss.oracle.com/git/kwilk/xen.git) I am proposing these two patches. The easier of them: xen/pciback: use mutex rather than spinlock in vpci backend converts the vpci backend to use the same mechanism as the passthrough backend. xen/pciback: Use mutexes when working with Xenbus state transitions. converts the spinlocks that are guarding the Xenbus state changes to be mutexs and moves them out to be in similar locations as in the 2.6.18 tree. _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel From xen-devel-bounces@lists.xensource.com Wed Sep 21 15:46:19 2011 Return-path: <xen-devel-bounces@lists.xensource.com> Envelope-to: www-data@lists.xensource.com Delivery-date: Wed, 21 Sep 2011 15:46:19 -0700 Received: from localhost ([127.0.0.1] helo=lists.colo.xensource.com) by lists.xensource.com with esmtp (Exim 4.43) id 1R6VYZ-0005Na-C1; Wed, 21 Sep 2011 15:46:19 -0700 Received: from mail182.messagelabs.com ([85.158.139.83]) by lists.xensource.com with esmtp (Exim 4.43) id 1R6VVI-00048d-9F for xen-devel@lists.xensource.com; Wed, 21 Sep 2011 15:42:59 -0700 X-Env-Sender: konrad@oracle.com X-Msg-Ref: server-14.tower-182.messagelabs.com!1316644971!19087839!1 X-Originating-IP: [141.146.126.227] X-StarScan-Version: 6.4.1; banners=-,-,- X-VirusChecked: Checked Received: (qmail 6353 invoked from network); 21 Sep 2011 22:42:53 -0000 Received: from acsinet15.oracle.com (HELO acsinet15.oracle.com) (141.146.126.227) by server-14.tower-182.messagelabs.com with DHE-RSA-AES256-SHA encrypted SMTP; 21 Sep 2011 22:42:53 -0000 Received: from acsinet21.oracle.com (acsinet21.oracle.com [141.146.126.237]) by acsinet15.oracle.com (Switch-3.4.4/Switch-3.4.4) with ESMTP id p8LMgnpI004749 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Wed, 21 Sep 2011 22:42:50 GMT Received: from acsmt357.oracle.com (acsmt357.oracle.com [141.146.40.157]) by acsinet21.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id p8LMgmt1000201 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 21 Sep 2011 22:42:48 GMT Received: from abhmt110.oracle.com (abhmt110.oracle.com [141.146.116.62]) by acsmt357.oracle.com (8.12.11.20060308/8.12.11) with ESMTP id p8LMghfo019699; Wed, 21 Sep 2011 17:42:43 -0500 Received: from oracle.com (/209.6.55.207) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Wed, 21 Sep 2011 15:42:42 -0700 Received: by oracle.com (Postfix, from userid 1000) id 375AA1451; Wed, 21 Sep 2011 18:42:49 -0400 (EDT) From: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com> To: jbeulich@suse.com, linux-kernel@vger.kernel.org, xen-devel@lists.xensource.com Date: Wed, 21 Sep 2011 18:42:45 -0400 Message-Id: <1316644966-19386-2-git-send-email-konrad.wilk@oracle.com> X-Mailer: git-send-email 1.7.4.1 In-Reply-To: <1316644966-19386-1-git-send-email-konrad.wilk@oracle.com> References: <1316644966-19386-1-git-send-email-konrad.wilk@oracle.com> X-Source-IP: acsinet21.oracle.com [141.146.126.237] X-Auth-Type: Internal IP X-CT-RefId: str=0001.0A020206.4E7A686B.0013:SCFMA922111,ss=1,re=-4.000,fgs=0 Cc: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com> Subject: [Xen-devel] [PATCH 1/2] xen/pciback: Use mutexes when working with Xenbus state transitions. X-BeenThere: xen-devel@lists.xensource.com X-Mailman-Version: 2.1.5 Precedence: list List-Id: Xen developer discussion <xen-devel.lists.xensource.com> List-Unsubscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe> List-Post: <mailto:xen-devel@lists.xensource.com> List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help> List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=subscribe> Sender: xen-devel-bounces@lists.xensource.com Errors-To: xen-devel-bounces@lists.xensource.com The caller that orchestrates the state changes is xenwatch_thread and it takes a mutex. In our processing of Xenbus states we can take the luxery of going to sleep on a mutex, so lets do that and also fix this bug: BUG: sleeping function called from invalid context at /linux/kernel/mutex.c:271 in_atomic(): 1, irqs_disabled(): 0, pid: 32, name: xenwatch 2 locks held by xenwatch/32: #0: (xenwatch_mutex){......}, at: [<ffffffff813856ab>] xenwatch_thread+0x4b/0x180 #1: (&(&pdev->dev_lock)->rlock){......}, at: [<ffffffff8138f05b>] xen_pcibk_disconnect+0x1b/0x80 Pid: 32, comm: xenwatch Not tainted 3.1.0-rc6-00015-g3ce340d #2 Call Trace: [<ffffffff810892b2>] __might_sleep+0x102/0x130 [<ffffffff8163b90f>] mutex_lock_nested+0x2f/0x50 [<ffffffff81382c1c>] unbind_from_irq+0x2c/0x1b0 [<ffffffff8110da66>] ? free_irq+0x56/0xb0 [<ffffffff81382dbc>] unbind_from_irqhandler+0x1c/0x30 [<ffffffff8138f06b>] xen_pcibk_disconnect+0x2b/0x80 [<ffffffff81390348>] xen_pcibk_frontend_changed+0xe8/0x140 [<ffffffff81387ac2>] xenbus_otherend_changed+0xd2/0x150 [<ffffffff810895c1>] ? get_parent_ip+0x11/0x50 [<ffffffff81387de0>] frontend_changed+0x10/0x20 [<ffffffff81385712>] xenwatch_thread+0xb2/0x180 Signed-off-by: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com> --- drivers/xen/xen-pciback/pciback.h | 2 +- drivers/xen/xen-pciback/xenbus.c | 22 +++++++++------------- 2 files changed, 10 insertions(+), 14 deletions(-) diff --git a/drivers/xen/xen-pciback/pciback.h b/drivers/xen/xen-pciback/pciback.h index d095acd..e9b4011 100644 --- a/drivers/xen/xen-pciback/pciback.h +++ b/drivers/xen/xen-pciback/pciback.h @@ -29,7 +29,7 @@ struct pci_dev_entry { struct xen_pcibk_device { void *pci_dev_data; - spinlock_t dev_lock; + struct mutex dev_lock; struct xenbus_device *xdev; struct xenbus_watch be_watch; u8 be_watching; diff --git a/drivers/xen/xen-pciback/xenbus.c b/drivers/xen/xen-pciback/xenbus.c index 522f2da..474d52e 100644 --- a/drivers/xen/xen-pciback/xenbus.c +++ b/drivers/xen/xen-pciback/xenbus.c @@ -43,7 +43,7 @@ static struct xen_pcibk_device *alloc_pdev(struct xenbus_device *xdev) pdev->xdev = xdev; dev_set_drvdata(&xdev->dev, pdev); - spin_lock_init(&pdev->dev_lock); + mutex_init(&pdev->dev_lock); pdev->sh_info = NULL; pdev->evtchn_irq = INVALID_EVTCHN_IRQ; @@ -61,14 +61,12 @@ out: static void xen_pcibk_disconnect(struct xen_pcibk_device *pdev) { - spin_lock(&pdev->dev_lock); - + mutex_lock(&pdev->dev_lock); /* Ensure the guest can't trigger our handler before removing devices */ if (pdev->evtchn_irq != INVALID_EVTCHN_IRQ) { unbind_from_irqhandler(pdev->evtchn_irq, pdev); pdev->evtchn_irq = INVALID_EVTCHN_IRQ; } - spin_unlock(&pdev->dev_lock); /* If the driver domain started an op, make sure we complete it * before releasing the shared memory */ @@ -76,13 +74,11 @@ static void xen_pcibk_disconnect(struct xen_pcibk_device *pdev) /* Note, the workqueue does not use spinlocks at all.*/ flush_workqueue(xen_pcibk_wq); - spin_lock(&pdev->dev_lock); if (pdev->sh_info != NULL) { xenbus_unmap_ring_vfree(pdev->xdev, pdev->sh_info); pdev->sh_info = NULL; } - spin_unlock(&pdev->dev_lock); - + mutex_unlock(&pdev->dev_lock); } static void free_pdev(struct xen_pcibk_device *pdev) @@ -119,9 +115,7 @@ static int xen_pcibk_do_attach(struct xen_pcibk_device *pdev, int gnt_ref, goto out; } - spin_lock(&pdev->dev_lock); pdev->sh_info = vaddr; - spin_unlock(&pdev->dev_lock); err = bind_interdomain_evtchn_to_irqhandler( pdev->xdev->otherend_id, remote_evtchn, xen_pcibk_handle_event, @@ -131,10 +125,7 @@ static int xen_pcibk_do_attach(struct xen_pcibk_device *pdev, int gnt_ref, "Error binding event channel to IRQ"); goto out; } - - spin_lock(&pdev->dev_lock); pdev->evtchn_irq = err; - spin_unlock(&pdev->dev_lock); err = 0; dev_dbg(&pdev->xdev->dev, "Attached!\n"); @@ -149,6 +140,7 @@ static int xen_pcibk_attach(struct xen_pcibk_device *pdev) char *magic = NULL; + mutex_lock(&pdev->dev_lock); /* Make sure we only do this setup once */ if (xenbus_read_driver_state(pdev->xdev->nodename) != XenbusStateInitialised) @@ -193,6 +185,7 @@ static int xen_pcibk_attach(struct xen_pcibk_device *pdev) dev_dbg(&pdev->xdev->dev, "Connected? %d\n", err); out: + mutex_unlock(&pdev->dev_lock); kfree(magic); @@ -368,6 +361,7 @@ static int xen_pcibk_reconfigure(struct xen_pcibk_device *pdev) dev_dbg(&pdev->xdev->dev, "Reconfiguring device ...\n"); + mutex_lock(&pdev->dev_lock); /* Make sure we only reconfigure once */ if (xenbus_read_driver_state(pdev->xdev->nodename) != XenbusStateReconfiguring) @@ -505,6 +499,7 @@ static int xen_pcibk_reconfigure(struct xen_pcibk_device *pdev) } out: + mutex_unlock(&pdev->dev_lock); return 0; } @@ -561,6 +556,7 @@ static int xen_pcibk_setup_backend(struct xen_pcibk_device *pdev) char dev_str[64]; char state_str[64]; + mutex_lock(&pdev->dev_lock); /* It's possible we could get the call to setup twice, so make sure * we're not already connected. */ @@ -641,10 +637,10 @@ static int xen_pcibk_setup_backend(struct xen_pcibk_device *pdev) "Error switching to initialised state!"); out: + mutex_unlock(&pdev->dev_lock); if (!err) /* see if pcifront is already configured (if not, we'll wait) */ xen_pcibk_attach(pdev); - return err; } -- 1.7.4.1 _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel From xen-devel-bounces@lists.xensource.com Wed Sep 21 15:47:27 2011 Return-path: <xen-devel-bounces@lists.xensource.com> Envelope-to: www-data@lists.xensource.com Delivery-date: Wed, 21 Sep 2011 15:47:27 -0700 Received: from localhost ([127.0.0.1] helo=lists.colo.xensource.com) by lists.xensource.com with esmtp (Exim 4.43) id 1R6VZf-0005pR-AW; Wed, 21 Sep 2011 15:47:27 -0700 Received: from mail174.messagelabs.com ([85.158.138.51]) by lists.xensource.com with esmtp (Exim 4.43) id 1R6VYw-0005W0-GG; Wed, 21 Sep 2011 15:46:45 -0700 X-Env-Sender: jeremy@goop.org X-Msg-Ref: server-7.tower-174.messagelabs.com!1316645197!32254554!1 X-Originating-IP: [74.207.240.146] X-StarScan-Version: 6.4.1; banners=-,-,- X-VirusChecked: Checked Received: (qmail 28442 invoked from network); 21 Sep 2011 22:46:39 -0000 Received: from claw.goop.org (HELO claw.goop.org) (74.207.240.146) by server-7.tower-174.messagelabs.com with DHE-RSA-AES256-SHA encrypted SMTP; 21 Sep 2011 22:46:39 -0000 Received: from saboo.goop.org (unknown [IPv6:2001:470:1f05:899:5833:5dff:fe9e:bf0d]) (Authenticated sender: smtp-saboo) by claw.goop.org (Postfix) with ESMTPSA id CAB889724; Wed, 21 Sep 2011 15:46:36 -0700 (PDT) Received: from saboo.goop.org (localhost [IPv6:::1]) by saboo.goop.org (Postfix) with ESMTP id F0D30201FF; Wed, 21 Sep 2011 15:46:31 -0700 (PDT) Message-ID: <4E7A6947.5090205@goop.org> Date: Wed, 21 Sep 2011 15:46:31 -0700 From: Jeremy Fitzhardinge <jeremy@goop.org> User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:6.0.2) Gecko/20110906 Thunderbird/6.0.2 MIME-Version: 1.0 To: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com> Subject: Re: [Xen-devel] Re: Virtualization Test Day for F16 and Xen References: <CAN0j7xqm5BatDtXaurYZWvb-6ibG2V10aQ5Qck+9P7DjciWLwQ@mail.gmail.com> <20110914112552.GP12984@reaktio.net> <20110914142522.GA16956@phenom.oracle.com> <20110914144539.GR12984@reaktio.net> <20110915151041.GA4453@imp.local> <1316126290.5689.3.camel@adam> <20110916084308.GD884@phenom.oracle.com> <4E77A4EC.9080600@goop.org> <20110921200348.GA31078@phenom.oracle.com> In-Reply-To: <20110921200348.GA31078@phenom.oracle.com> X-Enigmail-Version: 1.3.1 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: Development discussions related to Fedora <devel@lists.fedoraproject.org>, xen@lists.fedoraproject.org, xen-devel@lists.xensource.com, Stefano Stabellini <stefano.stabellini@eu.citrix.com>, lars.kurth@xen.org, virt@lists.fedoraproject.org, xen-users@lists.xensource.com, Adam Williamson <awilliam@redhat.com> X-BeenThere: xen-devel@lists.xensource.com X-Mailman-Version: 2.1.5 Precedence: list List-Id: Xen developer discussion <xen-devel.lists.xensource.com> List-Unsubscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe> List-Post: <mailto:xen-devel@lists.xensource.com> List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help> List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=subscribe> Sender: xen-devel-bounces@lists.xensource.com Errors-To: xen-devel-bounces@lists.xensource.com On 09/21/2011 01:03 PM, Konrad Rzeszutek Wilk wrote: >>>> So, there's a meta-point here: we currently 'require' Beta releases to >>>> boot as guests on Xen hosts: >>>> >>>> "The release must boot successfully as a virtual guest in a situation >>>> where the virtual host is running a supported Xen implementation" >>>> >>>> I really don't have much knowledge of Xen and haven't followed this >>>> discussion closely, but do any currently-known bugs prevent this? If so, >>>> please flag them up so they can be considered as Beta blockers...thanks! > I filled Bug 740378 - F16: Can't use keyboard when installing F16-Alpha under Xen (regression) as guest > which is pretty descripting what is below. > > Also adding in Jeremy's workaround in it. Though I couldn't repro the general problems I was having - I later did a clean F14 install with no problems. So I don't really know what's going on here; I might try another F16 hvm install to see how it goes. But there is a bona-fide bug that F16 doesn't include xen-platform-pci by default in its initramfs, so it ends up unplugging its emulated devices without discovering the PV ones to replace them... > Besides that, there is also > 738085 - Patch to reduce spurious Xen entries in grub menu > > which has a patch to fix the grub2 menu-thingy.. I'd noticed that - though at present I haven't managed to get F16 Xen to boot in an hvm domain (it hangs when setting up interrupts in the nested dom0). J _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel From xen-devel-bounces@lists.xensource.com Wed Sep 21 15:50:28 2011 Return-path: <xen-devel-bounces@lists.xensource.com> Envelope-to: www-data@lists.xensource.com Delivery-date: Wed, 21 Sep 2011 15:50:28 -0700 Received: from localhost ([127.0.0.1] helo=lists.colo.xensource.com) by lists.xensource.com with esmtp (Exim 4.43) id 1R6Vca-0006sv-RZ; Wed, 21 Sep 2011 15:50:28 -0700 Received: from mail182.messagelabs.com ([85.158.139.83]) by lists.xensource.com with esmtp (Exim 4.43) id 1R6VbO-0006Wi-1o for xen-devel@lists.xensource.com; Wed, 21 Sep 2011 15:49:15 -0700 X-Env-Sender: jeremy@goop.org X-Msg-Ref: server-12.tower-182.messagelabs.com!1316645349!19096198!1 X-Originating-IP: [74.207.240.146] X-StarScan-Version: 6.4.1; banners=-,-,- X-VirusChecked: Checked Received: (qmail 26474 invoked from network); 21 Sep 2011 22:49:10 -0000 Received: from claw.goop.org (HELO claw.goop.org) (74.207.240.146) by server-12.tower-182.messagelabs.com with DHE-RSA-AES256-SHA encrypted SMTP; 21 Sep 2011 22:49:10 -0000 Received: from saboo.goop.org (unknown [IPv6:2001:470:1f05:899:5833:5dff:fe9e:bf0d]) (Authenticated sender: smtp-saboo) by claw.goop.org (Postfix) with ESMTPSA id B23C89725; Wed, 21 Sep 2011 15:49:08 -0700 (PDT) Received: from saboo.goop.org (localhost [IPv6:::1]) by saboo.goop.org (Postfix) with ESMTP id B2063201FF; Wed, 21 Sep 2011 15:49:01 -0700 (PDT) Message-ID: <4E7A69DD.1080501@goop.org> Date: Wed, 21 Sep 2011 15:49:01 -0700 From: Jeremy Fitzhardinge <jeremy@goop.org> User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:6.0.2) Gecko/20110906 Thunderbird/6.0.2 MIME-Version: 1.0 To: Ian Campbell <Ian.Campbell@eu.citrix.com> Subject: Re: [Xen-devel] Re: [PATCH] xen: change XEN_PLATFORM_PCI to bool default y References: <1316608670-23167-1-git-send-email-stefano.stabellini@eu.citrix.com> <20110921185102.GJ17357@phenom.oracle.com> <1316632095.5182.33.camel@dagon.hellion.org.uk> In-Reply-To: <1316632095.5182.33.camel@dagon.hellion.org.uk> X-Enigmail-Version: 1.3.1 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>, Stefano Stabellini <Stefano.Stabellini@eu.citrix.com>, Konrad Rzeszutek Wilk <konrad.wilk@oracle.com> X-BeenThere: xen-devel@lists.xensource.com X-Mailman-Version: 2.1.5 Precedence: list List-Id: Xen developer discussion <xen-devel.lists.xensource.com> List-Unsubscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe> List-Post: <mailto:xen-devel@lists.xensource.com> List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help> List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=subscribe> Sender: xen-devel-bounces@lists.xensource.com Errors-To: xen-devel-bounces@lists.xensource.com On 09/21/2011 12:08 PM, Ian Campbell wrote: > On Wed, 2011-09-21 at 19:51 +0100, Konrad Rzeszutek Wilk wrote: >> On Wed, Sep 21, 2011 at 01:37:50PM +0100, stefano.stabellini@eu.citrix.com wrote: >>> From: Stefano Stabellini <stefano.stabellini@eu.citrix.com> >>> >>> The xen-platform-pci module is small and for PV on HVM guests is a >> How small? > IIRC it is single digit numbers of kb. lsmod shows it's about 2.5k. >> Does it get removed from memory if it never gets loaded? Nope. >>> requirement for xenbus. >> Ok, should it then have a depency on XenBus as well? > xenbus can't be a module (which is why allowing platform-pci to be is > causing problems). > >> Linus does not like the 'default y' very much. He actually dislikes >> it quite much as I found when he tore Dan's behind about cleancache. > In particular case the option is gated on a dependency on another Xen > option (PVHVM) which doesn't default on. But if you do select PVHVM you > certainly want this option, so I think that's ok (why else would > 'default y' even exist?) It was default 'm' before, so making it 'y' is just the logical mapping of tristate->bool. >> .. so I think making it 'default n' is a better option or perhaps >> making it depend on some other functionality? Or perhaps just remove >> the tristate/bool altogether so it gets activated if XEN_PVHVM >> is set? >> >> Or remove the XEN_PLATFORM_PCI config option completly and make the >> config files that build this driver be CONFIG_XENPVHM dependent? > That would work too. Even better would be to make it an invisible > Kconfig symbol which PVHVM just selects. Eh, select is pretty nasty. J _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel From xen-users-bounces@lists.xensource.com Wed Sep 21 16:05:04 2011 Return-path: <xen-users-bounces@lists.xensource.com> Envelope-to: www-data@lists.xensource.com Delivery-date: Wed, 21 Sep 2011 16:05:04 -0700 Received: from localhost ([127.0.0.1] helo=lists.colo.xensource.com) by lists.xensource.com with esmtp (Exim 4.43) id 1R6Vqh-0007bG-KF; Wed, 21 Sep 2011 16:05:03 -0700 Received: from mail182.messagelabs.com ([85.158.139.83]) by lists.xensource.com with esmtp (Exim 4.43) id 1R6Vm1-0007Du-74; Wed, 21 Sep 2011 16:00:37 -0700 X-Env-Sender: konrad@oracle.com X-Msg-Ref: server-12.tower-182.messagelabs.com!1316646007!19096612!1 X-Originating-IP: [148.87.113.117] X-StarScan-Version: 6.4.1; banners=-,-,- X-VirusChecked: Checked Received: (qmail 5479 invoked from network); 21 Sep 2011 23:00:08 -0000 Received: from rcsinet15.oracle.com (HELO rcsinet15.oracle.com) (148.87.113.117) by server-12.tower-182.messagelabs.com with DHE-RSA-AES256-SHA encrypted SMTP; 21 Sep 2011 23:00:08 -0000 Received: from acsinet21.oracle.com (acsinet21.oracle.com [141.146.126.237]) by rcsinet15.oracle.com (Switch-3.4.4/Switch-3.4.4) with ESMTP id p8LMxwMp001264 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Wed, 21 Sep 2011 23:00:00 GMT Received: from acsmt357.oracle.com (acsmt357.oracle.com [141.146.40.157]) by acsinet21.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id p8LMxvBD022785 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 21 Sep 2011 22:59:57 GMT Received: from abhmt108.oracle.com (abhmt108.oracle.com [141.146.116.60]) by acsmt357.oracle.com (8.12.11.20060308/8.12.11) with ESMTP id p8LMxpWn028900; Wed, 21 Sep 2011 17:59:51 -0500 Received: from oracle.com (/209.6.55.207) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Wed, 21 Sep 2011 15:59:51 -0700 Received: by oracle.com (Postfix, from userid 1000) id C9CE51434; Wed, 21 Sep 2011 18:59:57 -0400 (EDT) Date: Wed, 21 Sep 2011 18:59:57 -0400 From: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com> To: Jeremy Fitzhardinge <jeremy@goop.org> Message-ID: <20110921225957.GA17396@phenom.oracle.com> References: <CAN0j7xqm5BatDtXaurYZWvb-6ibG2V10aQ5Qck+9P7DjciWLwQ@mail.gmail.com> <20110914112552.GP12984@reaktio.net> <20110914142522.GA16956@phenom.oracle.com> <20110914144539.GR12984@reaktio.net> <20110915151041.GA4453@imp.local> <1316126290.5689.3.camel@adam> <20110916084308.GD884@phenom.oracle.com> <4E77A4EC.9080600@goop.org> <20110921200348.GA31078@phenom.oracle.com> <4E7A6947.5090205@goop.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <4E7A6947.5090205@goop.org> User-Agent: Mutt/1.5.21 (2010-09-15) X-Source-IP: acsinet21.oracle.com [141.146.126.237] X-Auth-Type: Internal IP X-CT-RefId: str=0001.0A090202.4E7A6C71.008B:SCFMA922111,ss=1,re=-4.000,fgs=0 Cc: Development discussions related to Fedora <devel@lists.fedoraproject.org>, xen@lists.fedoraproject.org, xen-devel@lists.xensource.com, Stefano Stabellini <stefano.stabellini@eu.citrix.com>, lars.kurth@xen.org, virt@lists.fedoraproject.org, xen-users@lists.xensource.com, Adam Williamson <awilliam@redhat.com> Subject: [Xen-users] Re: [Xen-devel] Re: Virtualization Test Day for F16 and Xen X-BeenThere: xen-users@lists.xensource.com X-Mailman-Version: 2.1.5 Precedence: list List-Id: Xen user discussion <xen-users.lists.xensource.com> List-Unsubscribe: <http://lists.xensource.com/mailman/listinfo/xen-users>, <mailto:xen-users-request@lists.xensource.com?subject=unsubscribe> List-Post: <mailto:xen-users@lists.xensource.com> List-Help: <mailto:xen-users-request@lists.xensource.com?subject=help> List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-users>, <mailto:xen-users-request@lists.xensource.com?subject=subscribe> Sender: xen-users-bounces@lists.xensource.com Errors-To: xen-users-bounces@lists.xensource.com On Wed, Sep 21, 2011 at 03:46:31PM -0700, Jeremy Fitzhardinge wrote: > On 09/21/2011 01:03 PM, Konrad Rzeszutek Wilk wrote: > >>>> So, there's a meta-point here: we currently 'require' Beta releases to > >>>> boot as guests on Xen hosts: > >>>> > >>>> "The release must boot successfully as a virtual guest in a situation > >>>> where the virtual host is running a supported Xen implementation" > >>>> > >>>> I really don't have much knowledge of Xen and haven't followed this > >>>> discussion closely, but do any currently-known bugs prevent this? If so, > >>>> please flag them up so they can be considered as Beta blockers...thanks! > > I filled Bug 740378 - F16: Can't use keyboard when installing F16-Alpha under Xen (regression) as guest > > which is pretty descripting what is below. > > > > Also adding in Jeremy's workaround in it. > > Though I couldn't repro the general problems I was having - I later did > a clean F14 install with no problems. So I don't really know what's > going on here; I might try another F16 hvm install to see how it goes. > > But there is a bona-fide bug that F16 doesn't include xen-platform-pci > by default in its initramfs, so it ends up unplugging its emulated > devices without discovering the PV ones to replace them... Can you open a BZ at bugzilla.redhat.com please? It might need to be assigned to the kernel team. > > > Besides that, there is also > > 738085 - Patch to reduce spurious Xen entries in grub menu > > > > which has a patch to fix the grub2 menu-thingy.. > > I'd noticed that - though at present I haven't managed to get F16 Xen to > boot in an hvm domain (it hangs when setting up interrupts in the nested > dom0). > > J > > _______________________________________________ > Xen-devel mailing list > Xen-devel@lists.xensource.com > http://lists.xensource.com/xen-devel _______________________________________________ Xen-users mailing list Xen-users@lists.xensource.com http://lists.xensource.com/xen-users From xen-devel-bounces@lists.xensource.com Wed Sep 21 16:08:50 2011 Return-path: <xen-devel-bounces@lists.xensource.com> Envelope-to: www-data@lists.xensource.com Delivery-date: Wed, 21 Sep 2011 16:08:50 -0700 Received: from localhost ([127.0.0.1] helo=lists.colo.xensource.com) by lists.xensource.com with esmtp (Exim 4.43) id 1R6VuM-00005v-MM; Wed, 21 Sep 2011 16:08:50 -0700 Received: from mail21.messagelabs.com ([85.158.143.35]) by lists.xensource.com with esmtp (Exim 4.43) id 1R6Vsb-00081b-JR for xen-devel@lists.xensource.com; Wed, 21 Sep 2011 16:07:03 -0700 X-Env-Sender: jeremy@goop.org X-Msg-Ref: server-14.tower-21.messagelabs.com!1316646408!60476333!1 X-Originating-IP: [74.207.240.146] X-StarScan-Version: 6.4.1; banners=-,-,- X-VirusChecked: Checked Received: (qmail 10965 invoked from network); 21 Sep 2011 23:06:50 -0000 Received: from claw.goop.org (HELO claw.goop.org) (74.207.240.146) by server-14.tower-21.messagelabs.com with DHE-RSA-AES256-SHA encrypted SMTP; 21 Sep 2011 23:06:50 -0000 Received: from saboo.goop.org (unknown [IPv6:2001:470:1f05:899:9cc3:58ff:fe77:896d]) (Authenticated sender: smtp-saboo) by claw.goop.org (Postfix) with ESMTPSA id 17DAA9750; Wed, 21 Sep 2011 16:06:56 -0700 (PDT) Received: from saboo.goop.org (localhost [IPv6:::1]) by saboo.goop.org (Postfix) with ESMTP id 111DA203B1; Wed, 21 Sep 2011 16:06:52 -0700 (PDT) Message-ID: <4E7A6E0C.80503@goop.org> Date: Wed, 21 Sep 2011 16:06:52 -0700 From: Jeremy Fitzhardinge <jeremy@goop.org> User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:6.0.2) Gecko/20110906 Thunderbird/6.0.2 MIME-Version: 1.0 To: Ian Campbell <Ian.Campbell@eu.citrix.com> Subject: Re: [Xen-devel] xl create crash when using stub domains References: <4E729960.2080101@goop.org> <4E793F42.7070803@goop.org> <1316595394.3891.105.camel@zakaz.uk.xensource.com> In-Reply-To: <1316595394.3891.105.camel@zakaz.uk.xensource.com> X-Enigmail-Version: 1.3.1 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>, Ian Jackson <Ian.Jackson@eu.citrix.com>, Stefano Stabellini <Stefano.Stabellini@eu.citrix.com> X-BeenThere: xen-devel@lists.xensource.com X-Mailman-Version: 2.1.5 Precedence: list List-Id: Xen developer discussion <xen-devel.lists.xensource.com> List-Unsubscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe> List-Post: <mailto:xen-devel@lists.xensource.com> List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help> List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=subscribe> Sender: xen-devel-bounces@lists.xensource.com Errors-To: xen-devel-bounces@lists.xensource.com On 09/21/2011 01:56 AM, Ian Campbell wrote: > On Wed, 2011-09-21 at 02:34 +0100, Jeremy Fitzhardinge wrote: >> On 09/15/2011 05:33 PM, Jeremy Fitzhardinge wrote: >>> When I create an HVM domain with stubdom enabled, it crashes at: >>> >>> (gdb) run create -c /etc/xen/f14hv64 vcpus=4 xen_platform_pci=0 'boot="d"' >>> Starting program: /usr/sbin/xl create -c /etc/xen/f14hv64 vcpus=4 xen_platform_pci=0 'boot="d"' >>> [Thread debugging using libthread_db enabled] >>> Parsing config file /etc/xen/f14hv64 >>> xc: info: VIRTUAL MEMORY ARRANGEMENT: >>> Loader: 0000000000100000->000000000017b9ec >>> TOTAL: 0000000000000000->000000003f800000 >>> ENTRY ADDRESS: 0000000000100000 >>> xc: info: PHYSICAL MEMORY ALLOCATION: >>> 4KB PAGES: 0x0000000000000200 >>> 2MB PAGES: 0x00000000000001fb >>> 1GB PAGES: 0x0000000000000000 >>> xc: error: panic: xc_dom_bzimageloader.c:588: xc_dom_probe_bzimage_kernel: kernel is not a bzImage: Invalid kernel > FWIW I don't get this message. It seems unrelated to the issue here but > makes me curious... It's generated by xc_dom_probe_bzimage_kernel() when starting a PV domain with pvgrub or an HVM domain with stubdoms, AFAIKT. Do you not see it, or just not do those things? Seems to me that a "probe" function shouldn't be making obnoxious noise. J _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel From xen-devel-bounces@lists.xensource.com Wed Sep 21 16:32:51 2011 Return-path: <xen-devel-bounces@lists.xensource.com> Envelope-to: www-data@lists.xensource.com Delivery-date: Wed, 21 Sep 2011 16:32:51 -0700 Received: from localhost ([127.0.0.1] helo=lists.colo.xensource.com) by lists.xensource.com with esmtp (Exim 4.43) id 1R6WHb-0001VH-9i; Wed, 21 Sep 2011 16:32:51 -0700 Received: from mail27.messagelabs.com ([193.109.254.147]) by lists.xensource.com with esmtp (Exim 4.43) id 1R6WFS-0000rg-93 for xen-devel@lists.xensource.com; Wed, 21 Sep 2011 16:30:38 -0700 X-Env-Sender: james.harper@bendigoit.com.au X-Msg-Ref: server-2.tower-27.messagelabs.com!1316647807!55925170!1 X-Originating-IP: [203.16.224.4] X-StarScan-Version: 6.4.1; banners=-,-,- X-VirusChecked: Checked Received: (qmail 28770 invoked from network); 21 Sep 2011 23:30:10 -0000 Received: from smtp1.bendigoit.com.au (HELO smtp1.bendigoit.com.au) (203.16.224.4) by server-2.tower-27.messagelabs.com with AES256-SHA encrypted SMTP; 21 Sep 2011 23:30:10 -0000 Received: from mail.bendigoit.com.au ([203.16.207.99]) by smtp1.bendigoit.com.au with esmtp (Exim 4.69) (envelope-from <james.harper@bendigoit.com.au>) id 1R6WFG-0002A4-KR; Thu, 22 Sep 2011 09:30:26 +1000 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable X-MimeOLE: Produced By Microsoft Exchange V6.5 Subject: RE: [Xen-devel] RE: Stability report GPLPV 0.11.0.308 Date: Thu, 22 Sep 2011 09:30:23 +1000 Message-ID: <AEC6C66638C05B468B556EA548C1A77D01E5E008@trantor> In-Reply-To: <4E7728F9.9020208@hfp.de> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Xen-devel] RE: Stability report GPLPV 0.11.0.308 Thread-Index: Acx2wD5ECc3e7muXSmaq0PpNEZ9gQgB9hqiQ References: <4E64A0DF.2070007@hfp.de> <AEC6C66638C05B468B556EA548C1A77D01E5DB8C@trantor> <4E64D569.5030607@hfp.de> <AEC6C66638C05B468B556EA548C1A77D01E5DBBF@trantor> <4E7728F9.9020208@hfp.de> From: "James Harper" <james.harper@bendigoit.com.au> To: "Andreas Kinzler" <ml-xen-devel@hfp.de> X-Really-From-Bendigo-IT: magichashvalue Cc: xen-devel@lists.xensource.com X-BeenThere: xen-devel@lists.xensource.com X-Mailman-Version: 2.1.5 Precedence: list List-Id: Xen developer discussion <xen-devel.lists.xensource.com> List-Unsubscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe> List-Post: <mailto:xen-devel@lists.xensource.com> List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help> List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=subscribe> Sender: xen-devel-bounces@lists.xensource.com Errors-To: xen-devel-bounces@lists.xensource.com > Hello James, >=20 > the torture test of GPLPV 0.11.0.312 failed (as 0.11.0.308 did). What really > puzzles me is that the uptime was 9-10 days for both VMs (as in 0.11.0.308). > One could think that there is something about the uptime of > 9-10 days. There is no noticeable malfunction in dom0 and while the domUs > were running they looked perfectly. Really odd. >=20 I haven't tested it well, but the latest should be a bit more stable. Could you try one of the following from http://www.meadowcourt.org/private: gplpv_Vista2008x64_0.11.0.265.msi gplpv_2000_0.11.0.322_debug.msi gplpv_XP_0.11.0.322_debug.msi gplpv_2003x32_0.11.0.322_debug.msi gplpv_2003x64_0.11.0.322_debug.msi gplpv_Vista2008x32_0.11.0.322_debug.msi gplpv_Vista2008x64_0.11.0.322_debug.msi gplpv_2000_0.11.0.322.msi gplpv_XP_0.11.0.322.msi gplpv_2003x32_0.11.0.322.msi gplpv_2003x64_0.11.0.322.msi gplpv_Vista2008x32_0.11.0.322.msi gplpv_Vista2008x64_0.11.0.322.msi thanks James _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel From xen-devel-bounces@lists.xensource.com Wed Sep 21 16:53:20 2011 Return-path: <xen-devel-bounces@lists.xensource.com> Envelope-to: www-data@lists.xensource.com Delivery-date: Wed, 21 Sep 2011 16:53:20 -0700 Received: from localhost ([127.0.0.1] helo=lists.colo.xensource.com) by lists.xensource.com with esmtp (Exim 4.43) id 1R6WbP-0002Mp-UX; Wed, 21 Sep 2011 16:53:19 -0700 Received: from mail21.messagelabs.com ([85.158.143.35]) by lists.xensource.com with esmtp (Exim 4.43) id 1R6Wac-0002AV-Gt for xen-devel@lists.xensource.com; Wed, 21 Sep 2011 16:52:30 -0700 X-Env-Sender: Ian.Jackson@eu.citrix.com X-Msg-Ref: server-14.tower-21.messagelabs.com!1316649139!60477981!1 X-Originating-IP: [62.200.22.115] X-StarScan-Version: 6.4.1; banners=-,-,- X-VirusChecked: Checked Received: (qmail 12604 invoked from network); 21 Sep 2011 23:52:19 -0000 Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115) by server-14.tower-21.messagelabs.com with RC4-SHA encrypted SMTP; 21 Sep 2011 23:52:19 -0000 X-IronPort-AV: E=Sophos;i="4.68,420,1312156800"; d="scan'208";a="7992088" Received: from lonpmailmx01.citrite.net ([10.30.203.162]) by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5; 21 Sep 2011 23:52:27 +0000 Received: from woking.xci-test.com (10.80.248.135) by smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id 8.3.137.0; Thu, 22 Sep 2011 00:52:27 +0100 Received: from osstest by woking.xci-test.com with local (Exim 4.69) (envelope-from <ian.jackson@eu.citrix.com>) id 1R6WaY-0007Ni-Mi; Thu, 22 Sep 2011 00:52:26 +0100 To: xen-devel@lists.xensource.com Message-ID: <osstest-8994-mainreport@xen.org> From: xen.org <ian.jackson@eu.citrix.com> Date: Thu, 22 Sep 2011 00:52:26 +0100 MIME-Version: 1.0 Content-Type: text/plain Cc: ian.jackson@eu.citrix.com Subject: [Xen-devel] [linux test] 8994: tolerable FAIL X-BeenThere: xen-devel@lists.xensource.com X-Mailman-Version: 2.1.5 Precedence: list List-Id: Xen developer discussion <xen-devel.lists.xensource.com> List-Unsubscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe> List-Post: <mailto:xen-devel@lists.xensource.com> List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help> List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=subscribe> Sender: xen-devel-bounces@lists.xensource.com Errors-To: xen-devel-bounces@lists.xensource.com flight 8994 linux real [real] http://www.chiark.greenend.org.uk/~xensrcts/logs/8994/ Failures :-/ but no regressions. Tests which did not succeed, but are not blocking, including regressions (tests previously passed) regarded as allowable: test-amd64-amd64-xl-pcipt-intel 9 guest-start fail never pass test-amd64-i386-rhel6hvm-amd 9 guest-start.2 fail never pass test-amd64-i386-rhel6hvm-intel 9 guest-start.2 fail never pass test-i386-i386-xl-win 13 guest-stop fail never pass test-i386-i386-win 16 leak-check/check fail never pass test-amd64-amd64-win 16 leak-check/check fail never pass test-amd64-i386-win-vcpus1 16 leak-check/check fail never pass test-amd64-i386-xl-win-vcpus1 13 guest-stop fail never pass test-amd64-i386-win 16 leak-check/check fail never pass test-amd64-amd64-xl-win 13 guest-stop fail never pass version targeted for testing: linux 6bec8b4a4c14095d0b7ce424db9d583c3decae6c baseline version: linux 1c3f03ccc5258887f5f2cafc0836a865834f9205 ------------------------------------------------------------ People who touched revisions under test: Jeremy Fitzhardinge <jeremy.fitzhardinge@citrix.com> ------------------------------------------------------------ jobs: build-amd64 pass build-i386 pass build-amd64-pvops pass build-i386-pvops pass test-amd64-amd64-xl pass test-amd64-i386-xl pass test-i386-i386-xl pass test-amd64-i386-rhel6hvm-amd fail test-amd64-i386-xl-credit2 pass test-amd64-amd64-xl-pcipt-intel fail test-amd64-i386-rhel6hvm-intel fail test-amd64-i386-xl-multivcpu pass test-amd64-amd64-pair pass test-amd64-i386-pair pass test-i386-i386-pair pass test-amd64-amd64-pv pass test-amd64-i386-pv pass test-i386-i386-pv pass test-amd64-amd64-xl-sedf pass test-amd64-i386-win-vcpus1 fail test-amd64-i386-xl-win-vcpus1 fail test-amd64-amd64-win fail test-amd64-i386-win fail test-i386-i386-win fail test-amd64-amd64-xl-win fail test-i386-i386-xl-win fail ------------------------------------------------------------ sg-report-flight on woking.cam.xci-test.com logs: /home/xc_osstest/logs images: /home/xc_osstest/images Logs, config files, etc. are available at http://www.chiark.greenend.org.uk/~xensrcts/logs Test harness code can be found at http://xenbits.xensource.com/gitweb?p=osstest.git;a=summary Pushing revision : + branch=linux + revision=6bec8b4a4c14095d0b7ce424db9d583c3decae6c + . cri-lock-repos ++ . cri-common +++ umask 002 +++ getconfig Repos +++ perl -e ' use Osstest; readconfigonly(); print $c{Repos} or die $!; ' ++ repos=/export/home/osstest/repos ++ repos_lock=/export/home/osstest/repos/lock ++ '[' x '!=' x/export/home/osstest/repos/lock ']' ++ OSSTEST_REPOS_LOCK_LOCKED=/export/home/osstest/repos/lock ++ exec with-lock-ex -w /export/home/osstest/repos/lock ./ap-push linux 6bec8b4a4c14095d0b7ce424db9d583c3decae6c + branch=linux + revision=6bec8b4a4c14095d0b7ce424db9d583c3decae6c + . cri-lock-repos ++ . cri-common +++ umask 002 +++ getconfig Repos +++ perl -e ' use Osstest; readconfigonly(); print $c{Repos} or die $!; ' ++ repos=/export/home/osstest/repos ++ repos_lock=/export/home/osstest/repos/lock ++ '[' x/export/home/osstest/repos/lock '!=' x/export/home/osstest/repos/lock ']' + : xen@xenbits.xensource.com + : xen@xenbits.xensource.com:git/linux-pvops + : master + : tested/2.6.39.x + case "$branch" in + cd /export/home/osstest/repos/xen ./ap-push: line 20: cd: /export/home/osstest/repos/xen: No such file or directory ------------------------------------------------------------ commit 6bec8b4a4c14095d0b7ce424db9d583c3decae6c Author: Jeremy Fitzhardinge <jeremy.fitzhardinge@citrix.com> Date: Fri Sep 2 12:23:22 2011 -0700 Revert "xen/apic: Provide an 'apic_xen' to set the override the apic->[read|write] for all cases." This reverts commit c3dd7941354fa96a71f2613e2c7a1b215fa175dc. It prevents the kernel from booting natively on hardware. Conflicts: arch/x86/xen/enlighten.c Signed-off-by: Jeremy Fitzhardinge <jeremy.fitzhardinge@citrix.com> _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel From xen-devel-bounces@lists.xensource.com Wed Sep 21 17:36:48 2011 Return-path: <xen-devel-bounces@lists.xensource.com> Envelope-to: www-data@lists.xensource.com Delivery-date: Wed, 21 Sep 2011 17:36:48 -0700 Received: from localhost ([127.0.0.1] helo=lists.colo.xensource.com) by lists.xensource.com with esmtp (Exim 4.43) id 1R6XHT-0003V6-TD; Wed, 21 Sep 2011 17:36:47 -0700 Received: from mail21.messagelabs.com ([85.158.143.35]) by lists.xensource.com with esmtp (Exim 4.43) id 1R6XGT-0003EY-V0 for xen-devel@lists.xensource.com; Wed, 21 Sep 2011 17:35:47 -0700 X-Env-Sender: maillists.shan@gmail.com X-Msg-Ref: server-9.tower-21.messagelabs.com!1316651695!49314931!1 X-Originating-IP: [209.85.210.49] X-StarScan-Version: 6.4.1; banners=-,-,- X-VirusChecked: Checked Received: (qmail 28081 invoked from network); 22 Sep 2011 00:34:57 -0000 Received: from mail-pz0-f49.google.com (HELO mail-pz0-f49.google.com) (209.85.210.49) by server-9.tower-21.messagelabs.com with RC4-SHA encrypted SMTP; 22 Sep 2011 00:34:57 -0000 Received: by pzk34 with SMTP id 34so3193622pzk.8 for <xen-devel@lists.xensource.com>; Wed, 21 Sep 2011 17:35:40 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:date:message-id:subject:from:to:content-type; bh=MetpFlUgmEFF1SwTkVWggEuaoYtgkRvbLWcb4FUTHzg=; b=MoL8WYcqm2Uf4nvCaxtLIm73025S7zmGTkT6v8iVJMrVD94NyUqrJwWOFiUIAIwGFU /uAQRvZG+5TZxhKKAzImLZLR52tC6F2F1iDpXsgpo2L3bcgU4RKvpQ/0+X//ELaJ++3o BcBQNHG7cLh1GY1pmKT2yhLu2DGi/B+naUNuM= MIME-Version: 1.0 Received: by 10.68.27.193 with SMTP id v1mr533703pbg.96.1316651740018; Wed, 21 Sep 2011 17:35:40 -0700 (PDT) Received: by 10.142.154.21 with HTTP; Wed, 21 Sep 2011 17:35:39 -0700 (PDT) Date: Thu, 22 Sep 2011 08:35:39 +0800 Message-ID: <CAFQ2Z+fpR1UkxFEAYTD6irBUBeA3c7eJ3x1bXE0jzpdfQtH64w@mail.gmail.com> From: Haitao Shan <maillists.shan@gmail.com> To: Ian Jackson <Ian.Jackson@eu.citrix.com>, Keir Fraser <keir@xen.org>, Jan Beulich <jbeulich@novell.com>, xen-devel@lists.xensource.com Content-Type: multipart/mixed; boundary=bcaec520f5dd41b93d04ad7cdfce Cc: Subject: [Xen-devel] [PATCH] Qemu MSI Cleaning Up X-BeenThere: xen-devel@lists.xensource.com X-Mailman-Version: 2.1.5 Precedence: list List-Id: Xen developer discussion <xen-devel.lists.xensource.com> List-Unsubscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe> List-Post: <mailto:xen-devel@lists.xensource.com> List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help> List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=subscribe> Sender: xen-devel-bounces@lists.xensource.com Errors-To: xen-devel-bounces@lists.xensource.com --bcaec520f5dd41b93d04ad7cdfce Content-Type: text/plain; charset=ISO-8859-1 Hi, Ian, Keir, Jan, This patch does cleaning up of QEMU MSI handling. The fixes are: 1. Changes made to MSI-X table mapping handling to eliminate the small windows in which guest could have access to physical MSI-X table. 2. MSI-X table is mapped as read-only to QEMU, as masking of MSI-X is already in Xen now. 3. For registers that coexists inside the MSI-X table (this could be only PBA I think), value read from physical page would be returned. Could you please have review? Signed-off-by: Shan Haitao <haitao.shan@intel.com> diff --git a/hw/pass-through.c b/hw/pass-through.c index 9c5620d..6ebed64 100644 --- a/hw/pass-through.c +++ b/hw/pass-through.c @@ -92,6 +92,7 @@ #include <unistd.h> #include <sys/ioctl.h> +#include <assert.h> extern int gfx_passthru; int igd_passthru = 0; @@ -1103,6 +1104,7 @@ static void pt_iomem_map(PCIDevice *d, int i, uint32_t e_phys, uint32_t e_size, { struct pt_dev *assigned_device = (struct pt_dev *)d; uint32_t old_ebase = assigned_device->bases[i].e_physbase; + uint32_t msix_last_pfn = 0, bar_last_pfn = 0; int first_map = ( assigned_device->bases[i].e_size == 0 ); int ret = 0; @@ -1118,39 +1120,127 @@ static void pt_iomem_map(PCIDevice *d, int i, uint32_t e_phys, uint32_t e_size, if ( !first_map && old_ebase != -1 ) { - add_msix_mapping(assigned_device, i); - /* Remove old mapping */ - ret = xc_domain_memory_mapping(xc_handle, domid, + if ( has_msix_mapping(assigned_device, i) ) + { + msix_last_pfn = (assigned_device->msix->mmio_base_addr - 1 + + assigned_device->msix->total_entries * 16) >> XC_PAGE_SHIFT; + bar_last_pfn = (old_ebase + e_size - 1) >> XC_PAGE_SHIFT; + + unregister_iomem(assigned_device->msix->mmio_base_addr); + + if ( assigned_device->msix->table_off ) + { + ret = xc_domain_memory_mapping(xc_handle, domid, + old_ebase >> XC_PAGE_SHIFT, + assigned_device->bases[i].access.maddr >> XC_PAGE_SHIFT, + (assigned_device->msix->mmio_base_addr >> XC_PAGE_SHIFT) + - (old_ebase >> XC_PAGE_SHIFT), + DPCI_REMOVE_MAPPING); + if ( ret != 0 ) + { + PT_LOG("Error: remove old mapping failed!\n"); + return; + } + } + if ( msix_last_pfn != bar_last_pfn ) + { + assert(msix_last_pfn < bar_last_pfn); + ret = xc_domain_memory_mapping(xc_handle, domid, + msix_last_pfn + 1, + (assigned_device->bases[i].access.maddr + + assigned_device->msix->table_off + + assigned_device->msix->total_entries * 16 + + XC_PAGE_SIZE -1) >> XC_PAGE_SHIFT, + bar_last_pfn - msix_last_pfn, + DPCI_REMOVE_MAPPING); + if ( ret != 0 ) + { + PT_LOG("Error: remove old mapping failed!\n"); + return; + } + } + } + else + { + /* Remove old mapping */ + ret = xc_domain_memory_mapping(xc_handle, domid, old_ebase >> XC_PAGE_SHIFT, assigned_device->bases[i].access.maddr >> XC_PAGE_SHIFT, (e_size+XC_PAGE_SIZE-1) >> XC_PAGE_SHIFT, DPCI_REMOVE_MAPPING); - if ( ret != 0 ) - { - PT_LOG("Error: remove old mapping failed!\n"); - return; + if ( ret != 0 ) + { + PT_LOG("Error: remove old mapping failed!\n"); + return; + } } } /* map only valid guest address */ if (e_phys != -1) { - /* Create new mapping */ - ret = xc_domain_memory_mapping(xc_handle, domid, + if ( has_msix_mapping(assigned_device, i) ) + { + assigned_device->msix->mmio_base_addr = + assigned_device->bases[i].e_physbase + + assigned_device->msix->table_off; + + msix_last_pfn = (assigned_device->msix->mmio_base_addr - 1 + + assigned_device->msix->total_entries * 16) >> XC_PAGE_SHIFT; + bar_last_pfn = (e_phys + e_size - 1) >> XC_PAGE_SHIFT; + + cpu_register_physical_memory(assigned_device->msix->mmio_base_addr, + (assigned_device->msix->total_entries * 16 + XC_PAGE_SIZE - 1) + & XC_PAGE_MASK, + assigned_device->msix->mmio_index); + + if ( assigned_device->msix->table_off ) + { + ret = xc_domain_memory_mapping(xc_handle, domid, + assigned_device->bases[i].e_physbase >> XC_PAGE_SHIFT, + assigned_device->bases[i].access.maddr >> XC_PAGE_SHIFT, + (assigned_device->msix->mmio_base_addr >> XC_PAGE_SHIFT) + - (assigned_device->bases[i].e_physbase >> XC_PAGE_SHIFT), + DPCI_ADD_MAPPING); + if ( ret != 0 ) + { + PT_LOG("Error: remove old mapping failed!\n"); + return; + } + } + if ( msix_last_pfn != bar_last_pfn ) + { + assert(msix_last_pfn < bar_last_pfn); + ret = xc_domain_memory_mapping(xc_handle, domid, + msix_last_pfn + 1, + (assigned_device->bases[i].access.maddr + + assigned_device->msix->table_off + + assigned_device->msix->total_entries * 16 + + XC_PAGE_SIZE -1) >> XC_PAGE_SHIFT, + bar_last_pfn - msix_last_pfn, + DPCI_ADD_MAPPING); + if ( ret != 0 ) + { + PT_LOG("Error: remove old mapping failed!\n"); + return; + } + } + } + else + { + /* Create new mapping */ + ret = xc_domain_memory_mapping(xc_handle, domid, assigned_device->bases[i].e_physbase >> XC_PAGE_SHIFT, assigned_device->bases[i].access.maddr >> XC_PAGE_SHIFT, (e_size+XC_PAGE_SIZE-1) >> XC_PAGE_SHIFT, DPCI_ADD_MAPPING); - if ( ret != 0 ) - { - PT_LOG("Error: create new mapping failed!\n"); + if ( ret != 0 ) + { + PT_LOG("Error: create new mapping failed!\n"); + } } - ret = remove_msix_mapping(assigned_device, i); - if ( ret != 0 ) - PT_LOG("Error: remove MSI-X mmio mapping failed!\n"); - if ( old_ebase != e_phys && old_ebase != -1 ) pt_msix_update_remap(assigned_device, i); } diff --git a/hw/pt-msi.c b/hw/pt-msi.c index 71fa6f0..0134e62 100644 --- a/hw/pt-msi.c +++ b/hw/pt-msi.c @@ -284,15 +284,6 @@ void pt_disable_msi_translate(struct pt_dev *dev) dev->msi_trans_en = 0; } -/* MSI-X virtulization functions */ -static void mask_physical_msix_entry(struct pt_dev *dev, int entry_nr, int mask) -{ - void *phys_off; - - phys_off = dev->msix->phys_iomem_base + 16 * entry_nr + 12; - *(uint32_t *)phys_off = mask; -} - static int pt_msix_update_one(struct pt_dev *dev, int entry_nr) { struct msix_entry_info *entry = &dev->msix->msix_entry[entry_nr]; @@ -486,7 +477,6 @@ static void pci_msix_writel(void *opaque, target_phys_addr_t addr, uint32_t val) { if ( msix->enabled && !(val & 0x1) ) pt_msix_update_one(dev, entry_nr); - mask_physical_msix_entry(dev, entry_nr, entry->io_mem[3] & 0x1); } } @@ -519,7 +509,11 @@ static uint32_t pci_msix_readl(void *opaque, target_phys_addr_t addr) entry_nr = (addr - msix->mmio_base_addr) / 16; offset = ((addr - msix->mmio_base_addr) % 16) / 4; - return msix->msix_entry[entry_nr].io_mem[offset]; + if ( addr - msix->mmio_base_addr < msix->total_entries * 16 ) + return msix->msix_entry[entry_nr].io_mem[offset]; + else + return *(uint32_t *)(msix->phys_iomem_base + + (addr - msix->mmio_base_addr)); } static CPUReadMemoryFunc *pci_msix_read[] = { @@ -528,39 +522,12 @@ static CPUReadMemoryFunc *pci_msix_read[] = { pci_msix_readl }; -int add_msix_mapping(struct pt_dev *dev, int bar_index) -{ - if ( !(dev->msix && dev->msix->bar_index == bar_index) ) - return 0; - - return xc_domain_memory_mapping(xc_handle, domid, - dev->msix->mmio_base_addr >> XC_PAGE_SHIFT, - (dev->bases[bar_index].access.maddr - + dev->msix->table_off) >> XC_PAGE_SHIFT, - (dev->msix->total_entries * 16 - + XC_PAGE_SIZE -1) >> XC_PAGE_SHIFT, - DPCI_ADD_MAPPING); -} - -int remove_msix_mapping(struct pt_dev *dev, int bar_index) +int has_msix_mapping(struct pt_dev *dev, int bar_index) { if ( !(dev->msix && dev->msix->bar_index == bar_index) ) return 0; - dev->msix->mmio_base_addr = dev->bases[bar_index].e_physbase - + dev->msix->table_off; - - cpu_register_physical_memory(dev->msix->mmio_base_addr, - dev->msix->total_entries * 16, - dev->msix->mmio_index); - - return xc_domain_memory_mapping(xc_handle, domid, - dev->msix->mmio_base_addr >> XC_PAGE_SHIFT, - (dev->bases[bar_index].access.maddr - + dev->msix->table_off) >> XC_PAGE_SHIFT, - (dev->msix->total_entries * 16 - + XC_PAGE_SIZE -1) >> XC_PAGE_SHIFT, - DPCI_REMOVE_MAPPING); + return 1; } int pt_msix_init(struct pt_dev *dev, int pos) @@ -616,7 +583,7 @@ int pt_msix_init(struct pt_dev *dev, int pos) PT_LOG("table_off = %x, total_entries = %d\n", table_off, total_entries); dev->msix->table_offset_adjust = table_off & 0x0fff; dev->msix->phys_iomem_base = mmap(0, total_entries * 16 + dev->msix->table_offset_adjust, - PROT_WRITE | PROT_READ, MAP_SHARED | MAP_LOCKED, + PROT_READ, MAP_SHARED | MAP_LOCKED, fd, dev->msix->table_base + table_off - dev->msix->table_offset_adjust); dev->msix->phys_iomem_base = (void *)((char *)dev->msix->phys_iomem_base + dev->msix->table_offset_adjust); diff --git a/hw/pt-msi.h b/hw/pt-msi.h index 9664f89..2dc1720 100644 --- a/hw/pt-msi.h +++ b/hw/pt-msi.h @@ -107,10 +107,7 @@ void pt_msix_disable(struct pt_dev *dev); int -remove_msix_mapping(struct pt_dev *dev, int bar_index); - -int -add_msix_mapping(struct pt_dev *dev, int bar_index); +has_msix_mapping(struct pt_dev *dev, int bar_index); int pt_msix_init(struct pt_dev *dev, int pos); --bcaec520f5dd41b93d04ad7cdfce Content-Type: application/octet-stream; name="qemu_msi_clean_up.patch" Content-Disposition: attachment; filename="qemu_msi_clean_up.patch" Content-Transfer-Encoding: base64 X-Attachment-Id: f_gsv0fkcq0 ZGlmZiAtLWdpdCBhL2h3L3Bhc3MtdGhyb3VnaC5jIGIvaHcvcGFzcy10aHJvdWdoLmMKaW5kZXgg OWM1NjIwZC4uNmViZWQ2NCAxMDA2NDQKLS0tIGEvaHcvcGFzcy10aHJvdWdoLmMKKysrIGIvaHcv cGFzcy10aHJvdWdoLmMKQEAgLTkyLDYgKzkyLDcgQEAKIAogI2luY2x1ZGUgPHVuaXN0ZC5oPgog I2luY2x1ZGUgPHN5cy9pb2N0bC5oPgorI2luY2x1ZGUgPGFzc2VydC5oPgogCiBleHRlcm4gaW50 IGdmeF9wYXNzdGhydTsKIGludCBpZ2RfcGFzc3RocnUgPSAwOwpAQCAtMTEwMyw2ICsxMTA0LDcg QEAgc3RhdGljIHZvaWQgcHRfaW9tZW1fbWFwKFBDSURldmljZSAqZCwgaW50IGksIHVpbnQzMl90 IGVfcGh5cywgdWludDMyX3QgZV9zaXplLAogewogICAgIHN0cnVjdCBwdF9kZXYgKmFzc2lnbmVk X2RldmljZSAgPSAoc3RydWN0IHB0X2RldiAqKWQ7CiAgICAgdWludDMyX3Qgb2xkX2ViYXNlID0g YXNzaWduZWRfZGV2aWNlLT5iYXNlc1tpXS5lX3BoeXNiYXNlOworICAgIHVpbnQzMl90IG1zaXhf bGFzdF9wZm4gPSAwLCBiYXJfbGFzdF9wZm4gPSAwOwogICAgIGludCBmaXJzdF9tYXAgPSAoIGFz c2lnbmVkX2RldmljZS0+YmFzZXNbaV0uZV9zaXplID09IDAgKTsKICAgICBpbnQgcmV0ID0gMDsK IApAQCAtMTExOCwzOSArMTEyMCwxMjcgQEAgc3RhdGljIHZvaWQgcHRfaW9tZW1fbWFwKFBDSURl dmljZSAqZCwgaW50IGksIHVpbnQzMl90IGVfcGh5cywgdWludDMyX3QgZV9zaXplLAogCiAgICAg aWYgKCAhZmlyc3RfbWFwICYmIG9sZF9lYmFzZSAhPSAtMSApCiAgICAgewotICAgICAgICBhZGRf bXNpeF9tYXBwaW5nKGFzc2lnbmVkX2RldmljZSwgaSk7Ci0gICAgICAgIC8qIFJlbW92ZSBvbGQg bWFwcGluZyAqLwotICAgICAgICByZXQgPSB4Y19kb21haW5fbWVtb3J5X21hcHBpbmcoeGNfaGFu ZGxlLCBkb21pZCwKKyAgICAgICAgaWYgKCBoYXNfbXNpeF9tYXBwaW5nKGFzc2lnbmVkX2Rldmlj ZSwgaSkgKQorICAgICAgICB7CisgICAgICAgICAgICBtc2l4X2xhc3RfcGZuID0gKGFzc2lnbmVk X2RldmljZS0+bXNpeC0+bW1pb19iYXNlX2FkZHIgLSAxICsKKyAgICAgICAgICAgICAgICAgIGFz c2lnbmVkX2RldmljZS0+bXNpeC0+dG90YWxfZW50cmllcyAqIDE2KSA+PiAgWENfUEFHRV9TSElG VDsKKyAgICAgICAgICAgIGJhcl9sYXN0X3BmbiA9IChvbGRfZWJhc2UgKyBlX3NpemUgLSAxKSA+ PiBYQ19QQUdFX1NISUZUOworCisgICAgICAgICAgICB1bnJlZ2lzdGVyX2lvbWVtKGFzc2lnbmVk X2RldmljZS0+bXNpeC0+bW1pb19iYXNlX2FkZHIpOworCisgICAgICAgICAgICBpZiAoIGFzc2ln bmVkX2RldmljZS0+bXNpeC0+dGFibGVfb2ZmICkKKyAgICAgICAgICAgIHsKKwkJICAgICAgICBy ZXQgPSB4Y19kb21haW5fbWVtb3J5X21hcHBpbmcoeGNfaGFuZGxlLCBkb21pZCwKKyAgICAgICAg ICAgICAgICAgICAgb2xkX2ViYXNlID4+IFhDX1BBR0VfU0hJRlQsCisgICAgICAgICAgICAgICAg ICAgIGFzc2lnbmVkX2RldmljZS0+YmFzZXNbaV0uYWNjZXNzLm1hZGRyID4+IFhDX1BBR0VfU0hJ RlQsCisgICAgICAgICAgICAgICAgICAgIChhc3NpZ25lZF9kZXZpY2UtPm1zaXgtPm1taW9fYmFz ZV9hZGRyID4+IFhDX1BBR0VfU0hJRlQpCisgICAgICAgICAgICAgICAgICAgIC0gKG9sZF9lYmFz ZSA+PiBYQ19QQUdFX1NISUZUKSwKKyAgICAgICAgICAgICAgICAgICAgRFBDSV9SRU1PVkVfTUFQ UElORyk7CisgICAgICAgICAgICAgICAgaWYgKCByZXQgIT0gMCApCisgICAgICAgICAgICAgICAg eworICAgICAgICAgICAgICAgICAgICBQVF9MT0coIkVycm9yOiByZW1vdmUgb2xkIG1hcHBpbmcg ZmFpbGVkIVxuIik7CisgICAgICAgICAgICAgICAgICAgIHJldHVybjsKKyAgICAgICAgICAgICAg ICB9CisgICAgICAgICAgICB9CisgICAgICAgICAgICBpZiAoIG1zaXhfbGFzdF9wZm4gIT0gYmFy X2xhc3RfcGZuICkKKyAgICAgICAgICAgIHsKKyAgICAgICAgICAgICAgICBhc3NlcnQobXNpeF9s YXN0X3BmbiA8IGJhcl9sYXN0X3Bmbik7CisJCSAgICAgICAgcmV0ID0geGNfZG9tYWluX21lbW9y eV9tYXBwaW5nKHhjX2hhbmRsZSwgZG9taWQsCisgICAgICAgICAgICAgICAgICAgIG1zaXhfbGFz dF9wZm4gKyAxLAorICAgICAgICAgICAgICAgICAgICAoYXNzaWduZWRfZGV2aWNlLT5iYXNlc1tp XS5hY2Nlc3MubWFkZHIgKworICAgICAgICAgICAgICAgICAgICAgYXNzaWduZWRfZGV2aWNlLT5t c2l4LT50YWJsZV9vZmYgKworICAgICAgICAgICAgICAgICAgICAgYXNzaWduZWRfZGV2aWNlLT5t c2l4LT50b3RhbF9lbnRyaWVzICogMTYgKworICAgICAgICAgICAgICAgICAgICAgWENfUEFHRV9T SVpFIC0xKSA+PiAgWENfUEFHRV9TSElGVCwKKyAgICAgICAgICAgICAgICAgICAgYmFyX2xhc3Rf cGZuIC0gbXNpeF9sYXN0X3BmbiwKKyAgICAgICAgICAgICAgICAgICAgRFBDSV9SRU1PVkVfTUFQ UElORyk7CisgICAgICAgICAgICAgICAgaWYgKCByZXQgIT0gMCApCisgICAgICAgICAgICAgICAg eworICAgICAgICAgICAgICAgICAgICBQVF9MT0coIkVycm9yOiByZW1vdmUgb2xkIG1hcHBpbmcg ZmFpbGVkIVxuIik7CisgICAgICAgICAgICAgICAgICAgIHJldHVybjsKKyAgICAgICAgICAgICAg ICB9CisgICAgICAgICAgICB9CisgICAgICAgIH0KKyAgICAgICAgZWxzZQorICAgICAgICB7CisJ CSAgICAvKiBSZW1vdmUgb2xkIG1hcHBpbmcgKi8KKwkJICAgIHJldCA9IHhjX2RvbWFpbl9tZW1v cnlfbWFwcGluZyh4Y19oYW5kbGUsIGRvbWlkLAogICAgICAgICAgICAgICAgIG9sZF9lYmFzZSA+ PiBYQ19QQUdFX1NISUZULAogICAgICAgICAgICAgICAgIGFzc2lnbmVkX2RldmljZS0+YmFzZXNb aV0uYWNjZXNzLm1hZGRyID4+IFhDX1BBR0VfU0hJRlQsCiAgICAgICAgICAgICAgICAgKGVfc2l6 ZStYQ19QQUdFX1NJWkUtMSkgPj4gWENfUEFHRV9TSElGVCwKICAgICAgICAgICAgICAgICBEUENJ X1JFTU9WRV9NQVBQSU5HKTsKLSAgICAgICAgaWYgKCByZXQgIT0gMCApCi0gICAgICAgIHsKLSAg ICAgICAgICAgIFBUX0xPRygiRXJyb3I6IHJlbW92ZSBvbGQgbWFwcGluZyBmYWlsZWQhXG4iKTsK LSAgICAgICAgICAgIHJldHVybjsKKyAgICAgICAgICAgIGlmICggcmV0ICE9IDAgKQorICAgICAg ICAgICAgeworICAgICAgICAgICAgICAgIFBUX0xPRygiRXJyb3I6IHJlbW92ZSBvbGQgbWFwcGlu ZyBmYWlsZWQhXG4iKTsKKyAgICAgICAgICAgICAgICByZXR1cm47CisgICAgICAgICAgICB9CiAg ICAgICAgIH0KICAgICB9CiAKICAgICAvKiBtYXAgb25seSB2YWxpZCBndWVzdCBhZGRyZXNzICov CiAgICAgaWYgKGVfcGh5cyAhPSAtMSkKICAgICB7Ci0gICAgICAgIC8qIENyZWF0ZSBuZXcgbWFw cGluZyAqLwotICAgICAgICByZXQgPSB4Y19kb21haW5fbWVtb3J5X21hcHBpbmcoeGNfaGFuZGxl LCBkb21pZCwKKyAgICAgICAgaWYgKCBoYXNfbXNpeF9tYXBwaW5nKGFzc2lnbmVkX2RldmljZSwg aSkgKQorCQl7CisgICAgICAgICAgICBhc3NpZ25lZF9kZXZpY2UtPm1zaXgtPm1taW9fYmFzZV9h ZGRyID0KKyAgICAgICAgICAgICAgICBhc3NpZ25lZF9kZXZpY2UtPmJhc2VzW2ldLmVfcGh5c2Jh c2UKKyAgICAgICAgICAgICAgICArIGFzc2lnbmVkX2RldmljZS0+bXNpeC0+dGFibGVfb2ZmOwor CisgICAgICAgICAgICBtc2l4X2xhc3RfcGZuID0gKGFzc2lnbmVkX2RldmljZS0+bXNpeC0+bW1p b19iYXNlX2FkZHIgLSAxICsKKyAgICAgICAgICAgICAgICAgIGFzc2lnbmVkX2RldmljZS0+bXNp eC0+dG90YWxfZW50cmllcyAqIDE2KSA+PiAgWENfUEFHRV9TSElGVDsKKyAgICAgICAgICAgIGJh cl9sYXN0X3BmbiA9IChlX3BoeXMgKyBlX3NpemUgLSAxKSA+PiBYQ19QQUdFX1NISUZUOworCisg ICAgICAgICAgICBjcHVfcmVnaXN0ZXJfcGh5c2ljYWxfbWVtb3J5KGFzc2lnbmVkX2RldmljZS0+ bXNpeC0+bW1pb19iYXNlX2FkZHIsCisgICAgICAgICAgICAgICAgIChhc3NpZ25lZF9kZXZpY2Ut Pm1zaXgtPnRvdGFsX2VudHJpZXMgKiAxNiArIFhDX1BBR0VfU0laRSAtIDEpCisgICAgICAgICAg ICAgICAgICAmIFhDX1BBR0VfTUFTSywKKyAgICAgICAgICAgICAgICAgYXNzaWduZWRfZGV2aWNl LT5tc2l4LT5tbWlvX2luZGV4KTsKKworICAgICAgICAgICAgaWYgKCBhc3NpZ25lZF9kZXZpY2Ut Pm1zaXgtPnRhYmxlX29mZiApCisgICAgICAgICAgICB7CisJCSAgICAgICAgcmV0ID0geGNfZG9t YWluX21lbW9yeV9tYXBwaW5nKHhjX2hhbmRsZSwgZG9taWQsCisgICAgICAgICAgICAgICAgICAg IGFzc2lnbmVkX2RldmljZS0+YmFzZXNbaV0uZV9waHlzYmFzZSA+PiBYQ19QQUdFX1NISUZULAor ICAgICAgICAgICAgICAgICAgICBhc3NpZ25lZF9kZXZpY2UtPmJhc2VzW2ldLmFjY2Vzcy5tYWRk ciA+PiBYQ19QQUdFX1NISUZULAorICAgICAgICAgICAgICAgICAgICAoYXNzaWduZWRfZGV2aWNl LT5tc2l4LT5tbWlvX2Jhc2VfYWRkciA+PiBYQ19QQUdFX1NISUZUKQorICAgICAgICAgICAgICAg ICAgICAtIChhc3NpZ25lZF9kZXZpY2UtPmJhc2VzW2ldLmVfcGh5c2Jhc2UgPj4gWENfUEFHRV9T SElGVCksCisgICAgICAgICAgICAgICAgICAgIERQQ0lfQUREX01BUFBJTkcpOworICAgICAgICAg ICAgICAgIGlmICggcmV0ICE9IDAgKQorICAgICAgICAgICAgICAgIHsKKyAgICAgICAgICAgICAg ICAgICAgUFRfTE9HKCJFcnJvcjogcmVtb3ZlIG9sZCBtYXBwaW5nIGZhaWxlZCFcbiIpOworICAg ICAgICAgICAgICAgICAgICByZXR1cm47CisgICAgICAgICAgICAgICAgfQorICAgICAgICAgICAg fQorICAgICAgICAgICAgaWYgKCBtc2l4X2xhc3RfcGZuICE9IGJhcl9sYXN0X3BmbiApCisgICAg ICAgICAgICB7CisgICAgICAgICAgICAgICAgYXNzZXJ0KG1zaXhfbGFzdF9wZm4gPCBiYXJfbGFz dF9wZm4pOworCQkgICAgICAgIHJldCA9IHhjX2RvbWFpbl9tZW1vcnlfbWFwcGluZyh4Y19oYW5k bGUsIGRvbWlkLAorICAgICAgICAgICAgICAgICAgICBtc2l4X2xhc3RfcGZuICsgMSwKKyAgICAg ICAgICAgICAgICAgICAgKGFzc2lnbmVkX2RldmljZS0+YmFzZXNbaV0uYWNjZXNzLm1hZGRyICsK KyAgICAgICAgICAgICAgICAgICAgIGFzc2lnbmVkX2RldmljZS0+bXNpeC0+dGFibGVfb2ZmICsK KyAgICAgICAgICAgICAgICAgICAgIGFzc2lnbmVkX2RldmljZS0+bXNpeC0+dG90YWxfZW50cmll cyAqIDE2ICsKKyAgICAgICAgICAgICAgICAgICAgIFhDX1BBR0VfU0laRSAtMSkgPj4gIFhDX1BB R0VfU0hJRlQsCisgICAgICAgICAgICAgICAgICAgIGJhcl9sYXN0X3BmbiAtIG1zaXhfbGFzdF9w Zm4sCisgICAgICAgICAgICAgICAgICAgIERQQ0lfQUREX01BUFBJTkcpOworICAgICAgICAgICAg ICAgIGlmICggcmV0ICE9IDAgKQorICAgICAgICAgICAgICAgIHsKKyAgICAgICAgICAgICAgICAg ICAgUFRfTE9HKCJFcnJvcjogcmVtb3ZlIG9sZCBtYXBwaW5nIGZhaWxlZCFcbiIpOworICAgICAg ICAgICAgICAgICAgICByZXR1cm47CisgICAgICAgICAgICAgICAgfQorICAgICAgICAgICAgfQor CQl9CisJCWVsc2UKKyAgICAgICAgeworCQkJLyogQ3JlYXRlIG5ldyBtYXBwaW5nICovCisJCQly ZXQgPSB4Y19kb21haW5fbWVtb3J5X21hcHBpbmcoeGNfaGFuZGxlLCBkb21pZCwKICAgICAgICAg ICAgICAgICBhc3NpZ25lZF9kZXZpY2UtPmJhc2VzW2ldLmVfcGh5c2Jhc2UgPj4gWENfUEFHRV9T SElGVCwKICAgICAgICAgICAgICAgICBhc3NpZ25lZF9kZXZpY2UtPmJhc2VzW2ldLmFjY2Vzcy5t YWRkciA+PiBYQ19QQUdFX1NISUZULAogICAgICAgICAgICAgICAgIChlX3NpemUrWENfUEFHRV9T SVpFLTEpID4+IFhDX1BBR0VfU0hJRlQsCiAgICAgICAgICAgICAgICAgRFBDSV9BRERfTUFQUElO Ryk7CiAKLSAgICAgICAgaWYgKCByZXQgIT0gMCApCi0gICAgICAgIHsKLSAgICAgICAgICAgIFBU X0xPRygiRXJyb3I6IGNyZWF0ZSBuZXcgbWFwcGluZyBmYWlsZWQhXG4iKTsKKyAgICAgICAgICAg IGlmICggcmV0ICE9IDAgKQorICAgICAgICAgICAgeworICAgICAgICAgICAgICAgIFBUX0xPRygi RXJyb3I6IGNyZWF0ZSBuZXcgbWFwcGluZyBmYWlsZWQhXG4iKTsKKyAgICAgICAgICAgIH0KICAg ICAgICAgfQogCi0gICAgICAgIHJldCA9IHJlbW92ZV9tc2l4X21hcHBpbmcoYXNzaWduZWRfZGV2 aWNlLCBpKTsKLSAgICAgICAgaWYgKCByZXQgIT0gMCApCi0gICAgICAgICAgICBQVF9MT0coIkVy cm9yOiByZW1vdmUgTVNJLVggbW1pbyBtYXBwaW5nIGZhaWxlZCFcbiIpOwotCiAgICAgICAgIGlm ICggb2xkX2ViYXNlICE9IGVfcGh5cyAmJiBvbGRfZWJhc2UgIT0gLTEgKQogICAgICAgICAgICAg cHRfbXNpeF91cGRhdGVfcmVtYXAoYXNzaWduZWRfZGV2aWNlLCBpKTsKICAgICB9CmRpZmYgLS1n aXQgYS9ody9wdC1tc2kuYyBiL2h3L3B0LW1zaS5jCmluZGV4IDcxZmE2ZjAuLjAxMzRlNjIgMTAw NjQ0Ci0tLSBhL2h3L3B0LW1zaS5jCisrKyBiL2h3L3B0LW1zaS5jCkBAIC0yODQsMTUgKzI4NCw2 IEBAIHZvaWQgcHRfZGlzYWJsZV9tc2lfdHJhbnNsYXRlKHN0cnVjdCBwdF9kZXYgKmRldikKICAg ICBkZXYtPm1zaV90cmFuc19lbiA9IDA7CiB9CiAKLS8qIE1TSS1YIHZpcnR1bGl6YXRpb24gZnVu Y3Rpb25zICovCi1zdGF0aWMgdm9pZCBtYXNrX3BoeXNpY2FsX21zaXhfZW50cnkoc3RydWN0IHB0 X2RldiAqZGV2LCBpbnQgZW50cnlfbnIsIGludCBtYXNrKQotewotICAgIHZvaWQgKnBoeXNfb2Zm OwotCi0gICAgcGh5c19vZmYgPSBkZXYtPm1zaXgtPnBoeXNfaW9tZW1fYmFzZSArIDE2ICogZW50 cnlfbnIgKyAxMjsKLSAgICAqKHVpbnQzMl90ICopcGh5c19vZmYgPSBtYXNrOwotfQotCiBzdGF0 aWMgaW50IHB0X21zaXhfdXBkYXRlX29uZShzdHJ1Y3QgcHRfZGV2ICpkZXYsIGludCBlbnRyeV9u cikKIHsKICAgICBzdHJ1Y3QgbXNpeF9lbnRyeV9pbmZvICplbnRyeSA9ICZkZXYtPm1zaXgtPm1z aXhfZW50cnlbZW50cnlfbnJdOwpAQCAtNDg2LDcgKzQ3Nyw2IEBAIHN0YXRpYyB2b2lkIHBjaV9t c2l4X3dyaXRlbCh2b2lkICpvcGFxdWUsIHRhcmdldF9waHlzX2FkZHJfdCBhZGRyLCB1aW50MzJf dCB2YWwpCiAgICAgewogICAgICAgICBpZiAoIG1zaXgtPmVuYWJsZWQgJiYgISh2YWwgJiAweDEp ICkKICAgICAgICAgICAgIHB0X21zaXhfdXBkYXRlX29uZShkZXYsIGVudHJ5X25yKTsKLSAgICAg ICAgbWFza19waHlzaWNhbF9tc2l4X2VudHJ5KGRldiwgZW50cnlfbnIsIGVudHJ5LT5pb19tZW1b M10gJiAweDEpOwogICAgIH0KIH0KIApAQCAtNTE5LDcgKzUwOSwxMSBAQCBzdGF0aWMgdWludDMy X3QgcGNpX21zaXhfcmVhZGwodm9pZCAqb3BhcXVlLCB0YXJnZXRfcGh5c19hZGRyX3QgYWRkcikK ICAgICBlbnRyeV9uciA9IChhZGRyIC0gbXNpeC0+bW1pb19iYXNlX2FkZHIpIC8gMTY7CiAgICAg b2Zmc2V0ID0gKChhZGRyIC0gbXNpeC0+bW1pb19iYXNlX2FkZHIpICUgMTYpIC8gNDsKIAotICAg IHJldHVybiBtc2l4LT5tc2l4X2VudHJ5W2VudHJ5X25yXS5pb19tZW1bb2Zmc2V0XTsKKyAgICBp ZiAoIGFkZHIgLSBtc2l4LT5tbWlvX2Jhc2VfYWRkciA8IG1zaXgtPnRvdGFsX2VudHJpZXMgKiAx NiApCisgICAgICAgIHJldHVybiBtc2l4LT5tc2l4X2VudHJ5W2VudHJ5X25yXS5pb19tZW1bb2Zm c2V0XTsKKyAgICBlbHNlCisgICAgICAgIHJldHVybiAqKHVpbnQzMl90ICopKG1zaXgtPnBoeXNf aW9tZW1fYmFzZSArCisgICAgICAgICAgICAgICAgICAgICAgICAgICAgIChhZGRyIC0gbXNpeC0+ bW1pb19iYXNlX2FkZHIpKTsKIH0KIAogc3RhdGljIENQVVJlYWRNZW1vcnlGdW5jICpwY2lfbXNp eF9yZWFkW10gPSB7CkBAIC01MjgsMzkgKzUyMiwxMiBAQCBzdGF0aWMgQ1BVUmVhZE1lbW9yeUZ1 bmMgKnBjaV9tc2l4X3JlYWRbXSA9IHsKICAgICBwY2lfbXNpeF9yZWFkbAogfTsKIAotaW50IGFk ZF9tc2l4X21hcHBpbmcoc3RydWN0IHB0X2RldiAqZGV2LCBpbnQgYmFyX2luZGV4KQotewotICAg IGlmICggIShkZXYtPm1zaXggJiYgZGV2LT5tc2l4LT5iYXJfaW5kZXggPT0gYmFyX2luZGV4KSAp Ci0gICAgICAgIHJldHVybiAwOwotCi0gICAgcmV0dXJuIHhjX2RvbWFpbl9tZW1vcnlfbWFwcGlu Zyh4Y19oYW5kbGUsIGRvbWlkLAotICAgICAgICAgICAgICAgIGRldi0+bXNpeC0+bW1pb19iYXNl X2FkZHIgPj4gWENfUEFHRV9TSElGVCwKLSAgICAgICAgICAgICAgICAoZGV2LT5iYXNlc1tiYXJf aW5kZXhdLmFjY2Vzcy5tYWRkcgotICAgICAgICAgICAgICAgICsgZGV2LT5tc2l4LT50YWJsZV9v ZmYpID4+IFhDX1BBR0VfU0hJRlQsCi0gICAgICAgICAgICAgICAgKGRldi0+bXNpeC0+dG90YWxf ZW50cmllcyAqIDE2Ci0gICAgICAgICAgICAgICAgKyBYQ19QQUdFX1NJWkUgLTEpID4+IFhDX1BB R0VfU0hJRlQsCi0gICAgICAgICAgICAgICAgRFBDSV9BRERfTUFQUElORyk7Ci19Ci0KLWludCBy ZW1vdmVfbXNpeF9tYXBwaW5nKHN0cnVjdCBwdF9kZXYgKmRldiwgaW50IGJhcl9pbmRleCkKK2lu dCBoYXNfbXNpeF9tYXBwaW5nKHN0cnVjdCBwdF9kZXYgKmRldiwgaW50IGJhcl9pbmRleCkKIHsK ICAgICBpZiAoICEoZGV2LT5tc2l4ICYmIGRldi0+bXNpeC0+YmFyX2luZGV4ID09IGJhcl9pbmRl eCkgKQogICAgICAgICByZXR1cm4gMDsKIAotICAgIGRldi0+bXNpeC0+bW1pb19iYXNlX2FkZHIg PSBkZXYtPmJhc2VzW2Jhcl9pbmRleF0uZV9waHlzYmFzZQotICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICArIGRldi0+bXNpeC0+dGFibGVfb2ZmOwotCi0gICAgY3B1X3JlZ2lzdGVyX3Bo eXNpY2FsX21lbW9yeShkZXYtPm1zaXgtPm1taW9fYmFzZV9hZGRyLAotICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgZGV2LT5tc2l4LT50b3RhbF9lbnRyaWVzICogMTYsCi0gICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICBkZXYtPm1zaXgtPm1taW9faW5kZXgpOwotCi0gICAg cmV0dXJuIHhjX2RvbWFpbl9tZW1vcnlfbWFwcGluZyh4Y19oYW5kbGUsIGRvbWlkLAotICAgICAg ICAgICAgICAgIGRldi0+bXNpeC0+bW1pb19iYXNlX2FkZHIgPj4gWENfUEFHRV9TSElGVCwKLSAg ICAgICAgICAgICAgICAoZGV2LT5iYXNlc1tiYXJfaW5kZXhdLmFjY2Vzcy5tYWRkcgotICAgICAg ICAgICAgICAgICsgZGV2LT5tc2l4LT50YWJsZV9vZmYpID4+IFhDX1BBR0VfU0hJRlQsCi0gICAg ICAgICAgICAgICAgKGRldi0+bXNpeC0+dG90YWxfZW50cmllcyAqIDE2Ci0gICAgICAgICAgICAg ICAgKyBYQ19QQUdFX1NJWkUgLTEpID4+IFhDX1BBR0VfU0hJRlQsCi0gICAgICAgICAgICAgICAg RFBDSV9SRU1PVkVfTUFQUElORyk7CisJcmV0dXJuIDE7CiB9CiAKIGludCBwdF9tc2l4X2luaXQo c3RydWN0IHB0X2RldiAqZGV2LCBpbnQgcG9zKQpAQCAtNjE2LDcgKzU4Myw3IEBAIGludCBwdF9t c2l4X2luaXQoc3RydWN0IHB0X2RldiAqZGV2LCBpbnQgcG9zKQogICAgIFBUX0xPRygidGFibGVf b2ZmID0gJXgsIHRvdGFsX2VudHJpZXMgPSAlZFxuIiwgdGFibGVfb2ZmLCB0b3RhbF9lbnRyaWVz KTsKICAgICBkZXYtPm1zaXgtPnRhYmxlX29mZnNldF9hZGp1c3QgPSB0YWJsZV9vZmYgJiAweDBm ZmY7CiAgICAgZGV2LT5tc2l4LT5waHlzX2lvbWVtX2Jhc2UgPSBtbWFwKDAsIHRvdGFsX2VudHJp ZXMgKiAxNiArIGRldi0+bXNpeC0+dGFibGVfb2Zmc2V0X2FkanVzdCwKLSAgICAgICAgICAgICAg ICAgICAgICAgICAgUFJPVF9XUklURSB8IFBST1RfUkVBRCwgTUFQX1NIQVJFRCB8IE1BUF9MT0NL RUQsCisgICAgICAgICAgICAgICAgICAgICAgICAgIFBST1RfUkVBRCwgTUFQX1NIQVJFRCB8IE1B UF9MT0NLRUQsCiAgICAgICAgICAgICAgICAgICAgICAgICAgIGZkLCBkZXYtPm1zaXgtPnRhYmxl X2Jhc2UgKyB0YWJsZV9vZmYgLSBkZXYtPm1zaXgtPnRhYmxlX29mZnNldF9hZGp1c3QpOwogICAg IGRldi0+bXNpeC0+cGh5c19pb21lbV9iYXNlID0gKHZvaWQgKikoKGNoYXIgKilkZXYtPm1zaXgt PnBoeXNfaW9tZW1fYmFzZSArIAogICAgICAgICAgICAgICAgICAgICAgICAgICBkZXYtPm1zaXgt PnRhYmxlX29mZnNldF9hZGp1c3QpOwpkaWZmIC0tZ2l0IGEvaHcvcHQtbXNpLmggYi9ody9wdC1t c2kuaAppbmRleCA5NjY0Zjg5Li4yZGMxNzIwIDEwMDY0NAotLS0gYS9ody9wdC1tc2kuaAorKysg Yi9ody9wdC1tc2kuaApAQCAtMTA3LDEwICsxMDcsNyBAQCB2b2lkCiBwdF9tc2l4X2Rpc2FibGUo c3RydWN0IHB0X2RldiAqZGV2KTsKIAogaW50Ci1yZW1vdmVfbXNpeF9tYXBwaW5nKHN0cnVjdCBw dF9kZXYgKmRldiwgaW50IGJhcl9pbmRleCk7Ci0KLWludAotYWRkX21zaXhfbWFwcGluZyhzdHJ1 Y3QgcHRfZGV2ICpkZXYsIGludCBiYXJfaW5kZXgpOworaGFzX21zaXhfbWFwcGluZyhzdHJ1Y3Qg cHRfZGV2ICpkZXYsIGludCBiYXJfaW5kZXgpOwogCiBpbnQKIHB0X21zaXhfaW5pdChzdHJ1Y3Qg cHRfZGV2ICpkZXYsIGludCBwb3MpOwo= --bcaec520f5dd41b93d04ad7cdfce Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel --bcaec520f5dd41b93d04ad7cdfce-- From xen-devel-bounces@lists.xensource.com Wed Sep 21 18:36:23 2011 Return-path: <xen-devel-bounces@lists.xensource.com> Envelope-to: www-data@lists.xensource.com Delivery-date: Wed, 21 Sep 2011 18:36:23 -0700 Received: from localhost ([127.0.0.1] helo=lists.colo.xensource.com) by lists.xensource.com with esmtp (Exim 4.43) id 1R6YD8-0005oo-UO; Wed, 21 Sep 2011 18:36:22 -0700 Received: from mail182.messagelabs.com ([85.158.139.83]) by lists.xensource.com with esmtp (Exim 4.43) id 1R6YCL-0005Zx-6G for xen-devel@lists.xensource.com; Wed, 21 Sep 2011 18:35:33 -0700 X-Env-Sender: burns.me.uk@gmail.com X-Msg-Ref: server-7.tower-182.messagelabs.com!1316654900!14248131!1 X-Originating-IP: [209.85.212.41] X-StarScan-Version: 6.4.1; banners=-,-,- X-VirusChecked: Checked Received: (qmail 13290 invoked from network); 22 Sep 2011 01:28:21 -0000 Received: from mail-vw0-f41.google.com (HELO mail-vw0-f41.google.com) (209.85.212.41) by server-7.tower-182.messagelabs.com with RC4-SHA encrypted SMTP; 22 Sep 2011 01:28:21 -0000 Received: by vws16 with SMTP id 16so3269621vws.28 for <xen-devel@lists.xensource.com>; Wed, 21 Sep 2011 18:28:20 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:content-type; bh=Xpd3vYU4cg+PvZG3imvneKsYgj+6xfO+PP8bes59sNg=; b=hUja5NvR2VIDXrkH9lo5f7gczk2nElKZy35vsqqSNoM/9rMSLnFpQ41ZyuIKZ2Gy9l 5HfNY3DQ8cH19hNQD5Li6iB2vxjcAjME0sYAsnw3ZdPSw3h/rnwzGgCMiZqWb0M+B3Bo tCoi7IebKqJ4yxo/a/wTCUFMkp4Olbcp2U7PQ= MIME-Version: 1.0 Received: by 10.52.27.201 with SMTP id v9mr1327174vdg.485.1316654900059; Wed, 21 Sep 2011 18:28:20 -0700 (PDT) Received: by 10.52.169.201 with HTTP; Wed, 21 Sep 2011 18:28:20 -0700 (PDT) In-Reply-To: <20110921180819.GE17357@phenom.oracle.com> References: <20110915154621.GA21580@phenom.oracle.com> <alpine.LFD.2.02.1109152224170.2506@vega2.dur.ac.uk> <20110916083533.GC884@phenom.oracle.com> <CAE1-PRcO=7dBYxwJCq0L0Q6qcT=Nbnf4d2Sg3f=780MRxpKOaw@mail.gmail.com> <20110921180819.GE17357@phenom.oracle.com> Date: Thu, 22 Sep 2011 02:28:20 +0100 X-Google-Sender-Auth: Icvq3DVvpAzEpsr8m2CMV4qJvHg Message-ID: <CAE1-PRebWyo3ntFH2NsR2-XTikwLgGtEpzNCq0WoAd2m8WJJ2A@mail.gmail.com> Subject: Re: [Xen-devel] Re: F16, yum install xen, run grub2 or grubby as needed? From: Andy Burns <xen.lists@burns.me.uk> To: xen-devel@lists.xensource.com Content-Type: text/plain; charset=ISO-8859-1 X-BeenThere: xen-devel@lists.xensource.com X-Mailman-Version: 2.1.5 Precedence: list List-Id: Xen developer discussion <xen-devel.lists.xensource.com> List-Unsubscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe> List-Post: <mailto:xen-devel@lists.xensource.com> List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help> List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=subscribe> Sender: xen-devel-bounces@lists.xensource.com Errors-To: xen-devel-bounces@lists.xensource.com On 21 September 2011 19:08, Konrad Rzeszutek Wilk <konrad.wilk@oracle.com> wrote: > Oh, well, that is kind of convient. So you install new kernel and viola the new kernel boots in the hypervisor kernel? The way I achieved that, is to edit /etc/default/grub to include GRUB_DEFAULT="Xen" which matches the submenu created by /etc/grub.d/20_linux_xen so the submenu is the default chosen, and the newest kernel is automatically chosen from the top item of the submenu. I suspect there are still flies in the ointment with that, which was when I started to notice that installing a kernel had messed with the /boot/grub2/grub.cfg file If my server was in the remote data centre rather than the next room, I wouldn't be confident about rebooting it and expecting it to run the right combination of xen+kernel. _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel From xen-devel-bounces@lists.xensource.com Wed Sep 21 18:44:45 2011 Return-path: <xen-devel-bounces@lists.xensource.com> Envelope-to: www-data@lists.xensource.com Delivery-date: Wed, 21 Sep 2011 18:44:45 -0700 Received: from localhost ([127.0.0.1] helo=lists.colo.xensource.com) by lists.xensource.com with esmtp (Exim 4.43) id 1R6YLE-0006It-5K; Wed, 21 Sep 2011 18:44:44 -0700 Received: from mail27.messagelabs.com ([193.109.254.147]) by lists.xensource.com with esmtp (Exim 4.43) id 1R6YKe-00066i-4X for xen-devel@lists.xensource.com; Wed, 21 Sep 2011 18:44:08 -0700 X-Env-Sender: burns.me.uk@gmail.com X-Msg-Ref: server-6.tower-27.messagelabs.com!1316655824!49948326!1 X-Originating-IP: [209.85.212.41] X-StarScan-Version: 6.4.1; banners=-,-,- X-VirusChecked: Checked Received: (qmail 10231 invoked from network); 22 Sep 2011 01:43:45 -0000 Received: from mail-vw0-f41.google.com (HELO mail-vw0-f41.google.com) (209.85.212.41) by server-6.tower-27.messagelabs.com with RC4-SHA encrypted SMTP; 22 Sep 2011 01:43:45 -0000 Received: by vws16 with SMTP id 16so3278892vws.28 for <xen-devel@lists.xensource.com>; Wed, 21 Sep 2011 18:44:04 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:content-type; bh=2EU2YYgjKJJLatL6aQWEDXAqGuP5DT/UMGyEX9Pkde0=; b=xaew2W3vvhhztW61aKWNJ0qzpLkOTsR/H1BxDTVveSbv7q0+v0zOwIl4RtNYvR+K9u 4LWUPQ3w1LrIKyMrYocEPAal1HXHAzV9mnYJxQOChK3WzjWYs8nHiAGxLdf4RNtf9CD9 vMTcMDqmdjg0XIHuXDhYC53SxGtSW1Vpm6/jI= MIME-Version: 1.0 Received: by 10.52.95.145 with SMTP id dk17mr1194276vdb.217.1316654175656; Wed, 21 Sep 2011 18:16:15 -0700 (PDT) Received: by 10.52.169.201 with HTTP; Wed, 21 Sep 2011 18:16:15 -0700 (PDT) In-Reply-To: <20110921180819.GE17357@phenom.oracle.com> References: <20110915154621.GA21580@phenom.oracle.com> <alpine.LFD.2.02.1109152224170.2506@vega2.dur.ac.uk> <20110916083533.GC884@phenom.oracle.com> <CAE1-PRcO=7dBYxwJCq0L0Q6qcT=Nbnf4d2Sg3f=780MRxpKOaw@mail.gmail.com> <20110921180819.GE17357@phenom.oracle.com> Date: Thu, 22 Sep 2011 02:16:15 +0100 X-Google-Sender-Auth: 2ZqFtnF0aeCG-GC-GG-xqTOfwSU Message-ID: <CAE1-PRf3X03sohjhF9+vb0ABTB2HYQLATJqba6aYSFKVxu-t=Q@mail.gmail.com> Subject: Re: [Xen-devel] Re: F16, yum install xen, run grub2 or grubby as needed? From: Andy Burns <xen.lists@burns.me.uk> To: xen-devel@lists.xensource.com Content-Type: text/plain; charset=ISO-8859-1 X-BeenThere: xen-devel@lists.xensource.com X-Mailman-Version: 2.1.5 Precedence: list List-Id: Xen developer discussion <xen-devel.lists.xensource.com> List-Unsubscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe> List-Post: <mailto:xen-devel@lists.xensource.com> List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help> List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=subscribe> Sender: xen-devel-bounces@lists.xensource.com Errors-To: xen-devel-bounces@lists.xensource.com Konrad Rzeszutek Wilk <konrad.wilk@oracle.com> wrote: > Andy Burns wrote: > >> The one generated by manually running grub2-mkconfig creates a Xen >> submenu with all the various kernels under it, whereas after >> installing a new kernel, the one generated has all the xen + kernels >> in the top level menu. > > Oh, well, that is kind of convient. So you install new kernel and viola > the new kernel boots in the hypervisor kernel? No, because the baremetal stanza for the new kernel seems to always be before the xen stanza >> I've submitted a bug with a patch to make the /etc/20_linux_xen helper >> script ignore the symbol files and symbolic links, if there's no need >> for the symbolic links the patch could be even simpler. > > Could you also send the patch to upstream grub2? So that other > distros can benefit as well? Yes, will do ... _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel From xen-devel-bounces@lists.xensource.com Wed Sep 21 19:16:36 2011 Return-path: <xen-devel-bounces@lists.xensource.com> Envelope-to: www-data@lists.xensource.com Delivery-date: Wed, 21 Sep 2011 19:16:36 -0700 Received: from localhost ([127.0.0.1] helo=lists.colo.xensource.com) by lists.xensource.com with esmtp (Exim 4.43) id 1R6Yq3-00078h-OW; Wed, 21 Sep 2011 19:16:35 -0700 Received: from mail21.messagelabs.com ([85.158.143.35]) by lists.xensource.com with esmtp (Exim 4.43) id 1R6Yog-0006vz-WE for xen-devel@lists.xensource.com; Wed, 21 Sep 2011 19:15:11 -0700 X-Env-Sender: burns.me.uk@gmail.com X-Msg-Ref: server-13.tower-21.messagelabs.com!1316657700!49833266!1 X-Originating-IP: [209.85.212.41] X-StarScan-Version: 6.4.1; banners=-,-,- X-VirusChecked: Checked Received: (qmail 7345 invoked from network); 22 Sep 2011 02:15:01 -0000 Received: from mail-vw0-f41.google.com (HELO mail-vw0-f41.google.com) (209.85.212.41) by server-13.tower-21.messagelabs.com with RC4-SHA encrypted SMTP; 22 Sep 2011 02:15:01 -0000 Received: by vws16 with SMTP id 16so3298439vws.28 for <xen-devel@lists.xensource.com>; Wed, 21 Sep 2011 19:15:06 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:content-type; bh=FfIGqccD6DY2c//dCieqlnYN+QvwnPSuQCzvFO0FKbM=; b=PfX3aSrCy2nWLsMy8Iuw5Dv59PIIZeO69tg0QlGTusttKLCY4O5+32WeuzxAP/EPHo rcpuJXEhC6ph6rz7g0Z7DTVxN2pmm1OiZeK1/QEx+LIa5DFvZix3KBaFXI96uajY3yJf 5hheV9gzaKl5P4m6YueCRihjJym2Gx38e2aYo= MIME-Version: 1.0 Received: by 10.52.27.201 with SMTP id v9mr1357754vdg.485.1316657706762; Wed, 21 Sep 2011 19:15:06 -0700 (PDT) Received: by 10.52.169.201 with HTTP; Wed, 21 Sep 2011 19:15:06 -0700 (PDT) In-Reply-To: <20110915081741.GA24888@phenom.oracle.com> References: <20110829190056.GA10763@dumpdata.com> <20110829201554.GA18533@imp.local> <CAE1-PRccUHKwo3bjBGCbO56gn2V51WedQ23ws5xhFYx2FXT_SA@mail.gmail.com> <20110915081741.GA24888@phenom.oracle.com> Date: Thu, 22 Sep 2011 03:15:06 +0100 X-Google-Sender-Auth: FnpGEzuDH43L0_gabxTsFz44CsA Message-ID: <CAE1-PReGqWRcG1UNq1=8iGnjHYoUW5+2CVyeACfHTPijrcF1_w@mail.gmail.com> Subject: Re: [Xen-devel] Fedora Core 16 + Xen From: Andy Burns <xen.lists@burns.me.uk> To: xen-devel <xen-devel@lists.xensource.com> Content-Type: text/plain; charset=ISO-8859-1 X-BeenThere: xen-devel@lists.xensource.com X-Mailman-Version: 2.1.5 Precedence: list List-Id: Xen developer discussion <xen-devel.lists.xensource.com> List-Unsubscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe> List-Post: <mailto:xen-devel@lists.xensource.com> List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help> List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=subscribe> Sender: xen-devel-bounces@lists.xensource.com Errors-To: xen-devel-bounces@lists.xensource.com Konrad Rzeszutek Wilk <konrad.wilk@oracle.com> wrote: >> W. Michael Petullo <mike@flyn.org> wrote: > >> grub2 --class xen: initramfs missing, booting under XEN fails (found on >> Fedora 16) >> https://bugzilla.redhat.com/show_bug.cgi?id=728775 > > It should be in now. Can you retest please? Sorry for the delay replying, yes the updated grub works,I left it gave it my karma a couple of days ago _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel From xen-devel-bounces@lists.xensource.com Wed Sep 21 20:38:13 2011 Return-path: <xen-devel-bounces@lists.xensource.com> Envelope-to: www-data@lists.xensource.com Delivery-date: Wed, 21 Sep 2011 20:38:13 -0700 Received: from localhost ([127.0.0.1] helo=lists.colo.xensource.com) by lists.xensource.com with esmtp (Exim 4.43) id 1R6a73-0001Jm-O1; Wed, 21 Sep 2011 20:38:13 -0700 Received: from mail182.messagelabs.com ([85.158.139.83]) by lists.xensource.com with esmtp (Exim 4.43) id 1R6a6Q-00017E-QF for xen-devel@lists.xensource.com; Wed, 21 Sep 2011 20:37:35 -0700 X-Env-Sender: Ian.Jackson@eu.citrix.com X-Msg-Ref: server-4.tower-182.messagelabs.com!1316662651!19263415!1 X-Originating-IP: [62.200.22.115] X-StarScan-Version: 6.4.1; banners=-,-,- X-VirusChecked: Checked Received: (qmail 28729 invoked from network); 22 Sep 2011 03:37:31 -0000 Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115) by server-4.tower-182.messagelabs.com with RC4-SHA encrypted SMTP; 22 Sep 2011 03:37:31 -0000 X-IronPort-AV: E=Sophos;i="4.68,420,1312156800"; d="scan'208";a="7992940" Received: from lonpmailmx01.citrite.net ([10.30.203.162]) by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5; 22 Sep 2011 03:37:31 +0000 Received: from woking.xci-test.com (10.80.248.135) by smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id 8.3.137.0; Thu, 22 Sep 2011 04:37:31 +0100 Received: from osstest by woking.xci-test.com with local (Exim 4.69) (envelope-from <ian.jackson@eu.citrix.com>) id 1R6a6M-00024S-VS; Thu, 22 Sep 2011 04:37:31 +0100 To: xen-devel@lists.xensource.com Message-ID: <osstest-8995-mainreport@xen.org> From: xen.org <ian.jackson@eu.citrix.com> Date: Thu, 22 Sep 2011 04:37:31 +0100 MIME-Version: 1.0 Content-Type: text/plain Cc: ian.jackson@eu.citrix.com Subject: [Xen-devel] [xen-unstable test] 8995: tolerable FAIL X-BeenThere: xen-devel@lists.xensource.com X-Mailman-Version: 2.1.5 Precedence: list List-Id: Xen developer discussion <xen-devel.lists.xensource.com> List-Unsubscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe> List-Post: <mailto:xen-devel@lists.xensource.com> List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help> List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=subscribe> Sender: xen-devel-bounces@lists.xensource.com Errors-To: xen-devel-bounces@lists.xensource.com flight 8995 xen-unstable real [real] http://www.chiark.greenend.org.uk/~xensrcts/logs/8995/ Failures :-/ but no regressions. Tests which did not succeed, but are not blocking, including regressions (tests previously passed) regarded as allowable: test-amd64-amd64-xl-pcipt-intel 9 guest-start fail never pass test-amd64-amd64-xl-sedf 14 guest-localmigrate/x10 fail blocked in 8991 test-amd64-i386-rhel6hvm-amd 9 guest-start.2 fail never pass test-amd64-i386-rhel6hvm-intel 9 guest-start.2 fail never pass test-i386-i386-xl-win 13 guest-stop fail never pass test-amd64-amd64-win 16 leak-check/check fail never pass test-i386-i386-win 16 leak-check/check fail never pass test-amd64-i386-win-vcpus1 16 leak-check/check fail never pass test-amd64-i386-xl-win-vcpus1 13 guest-stop fail never pass test-amd64-i386-win 16 leak-check/check fail never pass test-amd64-amd64-xl-win 13 guest-stop fail never pass version targeted for testing: xen a422e2a4451e baseline version: xen a422e2a4451e jobs: build-amd64 pass build-i386 pass build-amd64-oldkern pass build-i386-oldkern pass build-amd64-pvops pass build-i386-pvops pass test-amd64-amd64-xl pass test-amd64-i386-xl pass test-i386-i386-xl pass test-amd64-i386-rhel6hvm-amd fail test-amd64-i386-xl-credit2 pass test-amd64-amd64-xl-pcipt-intel fail test-amd64-i386-rhel6hvm-intel fail test-amd64-i386-xl-multivcpu pass test-amd64-amd64-pair pass test-amd64-i386-pair pass test-i386-i386-pair pass test-amd64-amd64-pv pass test-amd64-i386-pv pass test-i386-i386-pv pass test-amd64-amd64-xl-sedf fail test-amd64-i386-win-vcpus1 fail test-amd64-i386-xl-win-vcpus1 fail test-amd64-amd64-win fail test-amd64-i386-win fail test-i386-i386-win fail test-amd64-amd64-xl-win fail test-i386-i386-xl-win fail ------------------------------------------------------------ sg-report-flight on woking.cam.xci-test.com logs: /home/xc_osstest/logs images: /home/xc_osstest/images Logs, config files, etc. are available at http://www.chiark.greenend.org.uk/~xensrcts/logs Test harness code can be found at http://xenbits.xensource.com/gitweb?p=osstest.git;a=summary Published tested tree is already up to date. _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel From xen-devel-bounces@lists.xensource.com Wed Sep 21 22:42:30 2011 Return-path: <xen-devel-bounces@lists.xensource.com> Envelope-to: www-data@lists.xensource.com Delivery-date: Wed, 21 Sep 2011 22:42:30 -0700 Received: from localhost ([127.0.0.1] helo=lists.colo.xensource.com) by lists.xensource.com with esmtp (Exim 4.43) id 1R6c3J-0003z5-4n; Wed, 21 Sep 2011 22:42:29 -0700 Received: from mail216.messagelabs.com ([85.158.143.99]) by lists.xensource.com with esmtp (Exim 4.43) id 1R6c2T-0003mL-HN for xen-devel@lists.xensource.com; Wed, 21 Sep 2011 22:41:37 -0700 X-Env-Sender: evil.dani@gmail.com X-Msg-Ref: server-8.tower-216.messagelabs.com!1316670081!17572199!1 X-Originating-IP: [209.85.161.43] X-StarScan-Version: 6.4.1; banners=-,-,- X-VirusChecked: Checked Received: (qmail 24739 invoked from network); 22 Sep 2011 05:41:21 -0000 Received: from mail-fx0-f43.google.com (HELO mail-fx0-f43.google.com) (209.85.161.43) by server-8.tower-216.messagelabs.com with RC4-SHA encrypted SMTP; 22 Sep 2011 05:41:21 -0000 Received: by fxh19 with SMTP id 19so2914911fxh.30 for <xen-devel@lists.xensource.com>; Wed, 21 Sep 2011 22:41:21 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :content-type:content-transfer-encoding; bh=/Epz7DNKRXt+TfB9qWNhubN9oyStdeudn3WrQXr4AKc=; b=Wcl4UR85+sLUNTWHc0luV0gBMZHJRAf1Jn1rEPw8Qg84JPvlJt4t7kz+yF7uKVIFQX 61rv3oFQhlNJJHhN2cKwl+fDGrNZ+oaOHb7zLMX0MWt9PgXg4fBAndpBX2ONDszort4U dLLnd6noVvnoY5ekjYEZJhVVaUKnm8yKB9txc= MIME-Version: 1.0 Received: by 10.223.52.218 with SMTP id j26mr2433876fag.56.1316670080902; Wed, 21 Sep 2011 22:41:20 -0700 (PDT) Received: by 10.223.97.9 with HTTP; Wed, 21 Sep 2011 22:41:20 -0700 (PDT) In-Reply-To: <CAP2B859vtSK_tC0J6HWB_m6hjHKM18vZ7Qh6ABFejCiEfxs+6g@mail.gmail.com> References: <CAP2B85_rPbB=hZpKJYSPgC59jU=YG6deD4ZkWMmXwtMV4un1mg@mail.gmail.com> <CA9D757C.2119E%keir.xen@gmail.com> <CAP2B85-e64NKts_iC21Bh0OL3X3nUh4jLriYfE2+stHkPfMFWg@mail.gmail.com> <4E793DC4.7080808@goop.org> <CAP2B859vtSK_tC0J6HWB_m6hjHKM18vZ7Qh6ABFejCiEfxs+6g@mail.gmail.com> Date: Thu, 22 Sep 2011 14:41:20 +0900 Message-ID: <CAP2B85-_kMLh0C6NCBpRbUchNYw96drLVJu33EdKV25jJ=p+4g@mail.gmail.com> Subject: [Xen-devel] Sched_op hypercall small questions From: Daniel Castro <evil.dani@gmail.com> To: xen-devel@lists.xensource.com Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable X-BeenThere: xen-devel@lists.xensource.com X-Mailman-Version: 2.1.5 Precedence: list List-Id: Xen developer discussion <xen-devel.lists.xensource.com> List-Unsubscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe> List-Post: <mailto:xen-devel@lists.xensource.com> List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help> List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=subscribe> Sender: xen-devel-bounces@lists.xensource.com Errors-To: xen-devel-bounces@lists.xensource.com On Wed, Sep 21, 2011 at 10:28 AM, Jeremy Fitzhardinge <jeremy@goop.org> wro= te: > On 09/19/2011 11:17 PM, Daniel Castro wrote: >> On Tue, Sep 20, 2011 at 2:41 PM, Keir Fraser <keir.xen@gmail.com> wrote: >>> On 19/09/2011 22:21, "Daniel Castro" <evil.dani@gmail.com> wrote: >>> >>>> Greetings all. >>>> >>>> Some small question regarding schedule poll operation hypercall. >>>> >>>> 1. struct sched_poll poll.timeout is measured in what unit of time? >>>> Secs, ms? ns? >>> It is an absolute system time (rather than a duration), in nanoseconds. >> really an absolute system time? >> >> When the timeout is set and the timeout is reached, the system behaves >> like if the event had been received? i.e the bit is changed? > > You specify the timeout in the the form "wake up by time t". =A0If t is i= n > the past, it times out immediately. > >>>> 2. After issuing the hypercall_sched_op(SCHEDOP_poll, &poll); if no >>>> timeout is used in poll struct how long will I yield the CPU? >>> Until one of the specified event channel ports is pending. >> If the channel port never changes (the event never arrives) then I >> would yield for ever? > > If you have events unmasked and you get an unmasked event, then it will > go into the event handler. My vcpu[0].evntchn_upcall_mask is 0, does this prevents the guest from receiving events? would that also explain why poll hypercall returns immediately? According to Xen's Definitive Guide evntchn_upcall_mask is unset at boot (my case exactly) so if it is 0 from the start and the guest (me) has to change it to 1 in order to receive events. How can I change the flag, I tried changing the value but it does not work like that apparently. Thanks > >>>> 3. If I issue the hypercall and the event never comes is it possible >>>> to to yield the CPU for ever? >>> Yes, if you do not specify a timeout. >> Keir thanks for the answer. >> >> I am trying to read from xenstore, so I have the following: >> I write on my xenstore ring the query I want, then, >> hypercall_event_channel_op(EVTCHNOP_send ... >> If I read the ring inmediatly the answer is not ready so I issue a >> hypercall_sched_op(SCHEDOP_poll, &poll); >> But while I am entering the yield state the answer comes, so the event >> is never seen because it has already been delivered. > > It generally only makes sense to poll on masked events. > >> >> If I use some way to wait (just for very brief instant) after the >> event_channel_op send then, when I check the ring the answer is there; >> And I do not need to yield the CPU. >> >> Should I issue the wait after the send, rather than when I am about to >> read the answer? > > What environment is this in? > > =A0 =A0J > -- +-=3D=3D=3D=3D=3D---------------------------+ | +---------------------------------+ | This space intentionally blank for notetaking. | |=A0=A0 | Daniel Castro,=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 | | |=A0=A0 | Consultant/Programmer.| | |=A0=A0 | U Andes=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0=A0 | +-------------------------------------+ --=20 +-=3D=3D=3D=3D=3D---------------------------+ | +---------------------------------+ | This space intentionally blank for notetaking. | |=A0=A0 | Daniel Castro,=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 | | |=A0=A0 | Consultant/Programmer.| | |=A0=A0 | U Andes=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0=A0 | +-------------------------------------+ _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel From xen-devel-bounces@lists.xensource.com Wed Sep 21 22:57:56 2011 Return-path: <xen-devel-bounces@lists.xensource.com> Envelope-to: www-data@lists.xensource.com Delivery-date: Wed, 21 Sep 2011 22:57:56 -0700 Received: from localhost ([127.0.0.1] helo=lists.colo.xensource.com) by lists.xensource.com with esmtp (Exim 4.43) id 1R6cIE-0004fu-Rf; Wed, 21 Sep 2011 22:57:54 -0700 Received: from mail21.messagelabs.com ([85.158.143.35]) by lists.xensource.com with esmtp (Exim 4.43) id 1R6cHI-0004SI-6k for xen-devel@lists.xensource.com; Wed, 21 Sep 2011 22:56:56 -0700 X-Env-Sender: Ian.Jackson@eu.citrix.com X-Msg-Ref: server-10.tower-21.messagelabs.com!1316670998!55027734!1 X-Originating-IP: [62.200.22.115] X-StarScan-Version: 6.4.1; banners=-,-,- X-VirusChecked: Checked Received: (qmail 3559 invoked from network); 22 Sep 2011 05:56:38 -0000 Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115) by server-10.tower-21.messagelabs.com with RC4-SHA encrypted SMTP; 22 Sep 2011 05:56:38 -0000 X-IronPort-AV: E=Sophos;i="4.68,421,1312156800"; d="scan'208";a="7994757" Received: from lonpmailmx01.citrite.net ([10.30.203.162]) by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5; 22 Sep 2011 05:56:52 +0000 Received: from woking.xci-test.com (10.80.248.135) by smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id 8.3.137.0; Thu, 22 Sep 2011 06:56:52 +0100 Received: from osstest by woking.xci-test.com with local (Exim 4.69) (envelope-from <ian.jackson@eu.citrix.com>) id 1R6cHE-00043e-75; Thu, 22 Sep 2011 06:56:52 +0100 To: xen-devel@lists.xensource.com Message-ID: <osstest-8996-mainreport@xen.org> From: xen.org <ian.jackson@eu.citrix.com> Date: Thu, 22 Sep 2011 06:56:52 +0100 MIME-Version: 1.0 Content-Type: text/plain Cc: ian.jackson@eu.citrix.com Subject: [Xen-devel] [linux test] 8996: tolerable FAIL X-BeenThere: xen-devel@lists.xensource.com X-Mailman-Version: 2.1.5 Precedence: list List-Id: Xen developer discussion <xen-devel.lists.xensource.com> List-Unsubscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe> List-Post: <mailto:xen-devel@lists.xensource.com> List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help> List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=subscribe> Sender: xen-devel-bounces@lists.xensource.com Errors-To: xen-devel-bounces@lists.xensource.com flight 8996 linux real [real] http://www.chiark.greenend.org.uk/~xensrcts/logs/8996/ Failures :-/ but no regressions. Tests which are failing intermittently (not blocking): test-amd64-amd64-xl-sedf 7 debian-install fail pass in 8994 Tests which did not succeed, but are not blocking, including regressions (tests previously passed) regarded as allowable: test-amd64-amd64-xl-pcipt-intel 9 guest-start fail never pass test-amd64-i386-rhel6hvm-amd 9 guest-start.2 fail never pass test-amd64-i386-rhel6hvm-intel 9 guest-start.2 fail never pass test-amd64-amd64-win 16 leak-check/check fail never pass test-i386-i386-win 16 leak-check/check fail never pass test-amd64-i386-win-vcpus1 16 leak-check/check fail never pass test-amd64-i386-xl-win-vcpus1 13 guest-stop fail never pass test-amd64-i386-win 16 leak-check/check fail never pass test-amd64-amd64-xl-win 13 guest-stop fail never pass test-i386-i386-xl-win 13 guest-stop fail never pass version targeted for testing: linux 6bec8b4a4c14095d0b7ce424db9d583c3decae6c baseline version: linux 1c3f03ccc5258887f5f2cafc0836a865834f9205 ------------------------------------------------------------ People who touched revisions under test: Jeremy Fitzhardinge <jeremy.fitzhardinge@citrix.com> ------------------------------------------------------------ jobs: build-amd64 pass build-i386 pass build-amd64-pvops pass build-i386-pvops pass test-amd64-amd64-xl pass test-amd64-i386-xl pass test-i386-i386-xl pass test-amd64-i386-rhel6hvm-amd fail test-amd64-i386-xl-credit2 pass test-amd64-amd64-xl-pcipt-intel fail test-amd64-i386-rhel6hvm-intel fail test-amd64-i386-xl-multivcpu pass test-amd64-amd64-pair pass test-amd64-i386-pair pass test-i386-i386-pair pass test-amd64-amd64-pv pass test-amd64-i386-pv pass test-i386-i386-pv pass test-amd64-amd64-xl-sedf fail test-amd64-i386-win-vcpus1 fail test-amd64-i386-xl-win-vcpus1 fail test-amd64-amd64-win fail test-amd64-i386-win fail test-i386-i386-win fail test-amd64-amd64-xl-win fail test-i386-i386-xl-win fail ------------------------------------------------------------ sg-report-flight on woking.cam.xci-test.com logs: /home/xc_osstest/logs images: /home/xc_osstest/images Logs, config files, etc. are available at http://www.chiark.greenend.org.uk/~xensrcts/logs Test harness code can be found at http://xenbits.xensource.com/gitweb?p=osstest.git;a=summary Pushing revision : + branch=linux + revision=6bec8b4a4c14095d0b7ce424db9d583c3decae6c + . cri-lock-repos ++ . cri-common +++ umask 002 +++ getconfig Repos +++ perl -e ' use Osstest; readconfigonly(); print $c{Repos} or die $!; ' ++ repos=/export/home/osstest/repos ++ repos_lock=/export/home/osstest/repos/lock ++ '[' x '!=' x/export/home/osstest/repos/lock ']' ++ OSSTEST_REPOS_LOCK_LOCKED=/export/home/osstest/repos/lock ++ exec with-lock-ex -w /export/home/osstest/repos/lock ./ap-push linux 6bec8b4a4c14095d0b7ce424db9d583c3decae6c + branch=linux + revision=6bec8b4a4c14095d0b7ce424db9d583c3decae6c + . cri-lock-repos ++ . cri-common +++ umask 002 +++ getconfig Repos +++ perl -e ' use Osstest; readconfigonly(); print $c{Repos} or die $!; ' ++ repos=/export/home/osstest/repos ++ repos_lock=/export/home/osstest/repos/lock ++ '[' x/export/home/osstest/repos/lock '!=' x/export/home/osstest/repos/lock ']' + : xen@xenbits.xensource.com + : xen@xenbits.xensource.com:git/linux-pvops + : master + : tested/2.6.39.x + case "$branch" in + cd /export/home/osstest/repos/xen ./ap-push: line 20: cd: /export/home/osstest/repos/xen: No such file or directory ------------------------------------------------------------ commit 6bec8b4a4c14095d0b7ce424db9d583c3decae6c Author: Jeremy Fitzhardinge <jeremy.fitzhardinge@citrix.com> Date: Fri Sep 2 12:23:22 2011 -0700 Revert "xen/apic: Provide an 'apic_xen' to set the override the apic->[read|write] for all cases." This reverts commit c3dd7941354fa96a71f2613e2c7a1b215fa175dc. It prevents the kernel from booting natively on hardware. Conflicts: arch/x86/xen/enlighten.c Signed-off-by: Jeremy Fitzhardinge <jeremy.fitzhardinge@citrix.com> _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel From xen-devel-bounces@lists.xensource.com Wed Sep 21 23:19:47 2011 Return-path: <xen-devel-bounces@lists.xensource.com> Envelope-to: www-data@lists.xensource.com Delivery-date: Wed, 21 Sep 2011 23:19:47 -0700 Received: from localhost ([127.0.0.1] helo=lists.colo.xensource.com) by lists.xensource.com with esmtp (Exim 4.43) id 1R6cdP-0005OH-3E; Wed, 21 Sep 2011 23:19:47 -0700 Received: from mail27.messagelabs.com ([193.109.254.147]) by lists.xensource.com with esmtp (Exim 4.43) id 1R6cc8-0005BG-AZ for xen-devel@lists.xensource.com; Wed, 21 Sep 2011 23:18:28 -0700 X-Env-Sender: olaf@aepfle.de X-Msg-Ref: server-8.tower-27.messagelabs.com!1316672288!47592726!1 X-Originating-IP: [81.169.146.160] X-StarScan-Version: 6.4.1; banners=-,-,- X-VirusChecked: Checked Received: (qmail 20844 invoked from network); 22 Sep 2011 06:18:08 -0000 Received: from mo-p00-ob.rzone.de (HELO mo-p00-ob.rzone.de) (81.169.146.160) by server-8.tower-27.messagelabs.com with EDH-RSA-DES-CBC3-SHA encrypted SMTP; 22 Sep 2011 06:18:08 -0000 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; t=1316672304; l=423; s=domk; d=aepfle.de; h=In-Reply-To:Content-Type:MIME-Version:References:Subject:Cc:To:From: Date:X-RZG-CLASS-ID:X-RZG-AUTH; bh=mbN8FTiciIpxPQvI11RDSPJdK5M=; b=N7aTgf9YGRwkcLHGRlmFYGI78wTx5sVF2GvaOeC3QyKGfXqSbDQqzn0mcM+Z59pd1So x412MVpcP38iGQhXo14lSvFpWi62QbBCbTOhsoR7QgxB1FJmdi1QV2Onb6s2FRfGLAdZ/ ccvxpTDzt9ehMs5xiZlac+I96+w3fgdJUOg= X-RZG-AUTH: :P2EQZWCpfu+qG7CngxMFH1J+zrwiavkK6tmQaLfmztM8TOFPjDEQEiPVxA== X-RZG-CLASS-ID: mo00 Received: from probook.site (dslb-088-065-122-153.pools.arcor-ip.net [88.65.122.153]) by smtp.strato.de (fruni mo41) (RZmta 26.7) with (EDH-RSA-DES-CBC3-SHA encrypted) ESMTPA id i06db9n8M3TXKz ; Thu, 22 Sep 2011 08:18:16 +0200 (MEST) Received: by probook.site (Postfix, from userid 1000) id 497FE18B65; Thu, 22 Sep 2011 08:18:14 +0200 (CEST) Date: Thu, 22 Sep 2011 08:18:13 +0200 From: Olaf Hering <olaf@aepfle.de> To: stefano.stabellini@eu.citrix.com Subject: Re: [Xen-devel] [PATCH] xen: change XEN_PLATFORM_PCI to bool default y Message-ID: <20110922061812.GA7607@aepfle.de> References: <1316608670-23167-1-git-send-email-stefano.stabellini@eu.citrix.com> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline In-Reply-To: <1316608670-23167-1-git-send-email-stefano.stabellini@eu.citrix.com> User-Agent: Mutt/1.5.21.rev5535 (2011-07-01) Cc: Ian.Campbell@eu.citrix.com, jeremy@goop.org, xen-devel@lists.xensource.com, konrad.wilk@oracle.com X-BeenThere: xen-devel@lists.xensource.com X-Mailman-Version: 2.1.5 Precedence: list List-Id: Xen developer discussion <xen-devel.lists.xensource.com> List-Unsubscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe> List-Post: <mailto:xen-devel@lists.xensource.com> List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help> List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=subscribe> Sender: xen-devel-bounces@lists.xensource.com Errors-To: xen-devel-bounces@lists.xensource.com On Wed, Sep 21, stefano.stabellini@eu.citrix.com wrote: > From: Stefano Stabellini <stefano.stabellini@eu.citrix.com> > > The xen-platform-pci module is small and for PV on HVM guests is a > requirement for xenbus. > > Signed-off-by: Stefano Stabellini <stefano.stabellini@eu.citrix.com> Because it depends on XEN_PVHVM and XEN_PVHVM usage depends on XEN_PLATFORM_PCI: Acked-by: Olaf Hering <olaf@aepfle.de> _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel From xen-devel-bounces@lists.xensource.com Wed Sep 21 23:23:53 2011 Return-path: <xen-devel-bounces@lists.xensource.com> Envelope-to: www-data@lists.xensource.com Delivery-date: Wed, 21 Sep 2011 23:23:53 -0700 Received: from localhost ([127.0.0.1] helo=lists.colo.xensource.com) by lists.xensource.com with esmtp (Exim 4.43) id 1R6chN-0006XX-8G; Wed, 21 Sep 2011 23:23:53 -0700 Received: from mail182.messagelabs.com ([85.158.139.83]) by lists.xensource.com with esmtp (Exim 4.43) id 1R6cer-0005jg-A6 for xen-devel@lists.xensource.com; Wed, 21 Sep 2011 23:21:17 -0700 X-Env-Sender: Ian.Campbell@eu.citrix.com X-Msg-Ref: server-10.tower-182.messagelabs.com!1316672474!19252816!1 X-Originating-IP: [62.200.22.115] X-StarScan-Version: 6.4.1; banners=-,-,- X-VirusChecked: Checked Received: (qmail 25436 invoked from network); 22 Sep 2011 06:21:14 -0000 Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115) by server-10.tower-182.messagelabs.com with RC4-SHA encrypted SMTP; 22 Sep 2011 06:21:14 -0000 X-IronPort-AV: E=Sophos;i="4.68,421,1312156800"; d="scan'208";a="7994994" Received: from lonpmailmx01.citrite.net ([10.30.203.162]) by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5; 22 Sep 2011 06:21:14 +0000 Received: from [127.0.0.1] (10.80.16.67) by smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id 8.3.137.0; Thu, 22 Sep 2011 07:21:13 +0100 Subject: Re: [Xen-devel] Re: [PATCH] xen: change XEN_PLATFORM_PCI to bool default y From: Ian Campbell <Ian.Campbell@eu.citrix.com> To: Jeremy Fitzhardinge <jeremy@goop.org> In-Reply-To: <4E7A69DD.1080501@goop.org> References: <1316608670-23167-1-git-send-email-stefano.stabellini@eu.citrix.com> <20110921185102.GJ17357@phenom.oracle.com> <1316632095.5182.33.camel@dagon.hellion.org.uk> <4E7A69DD.1080501@goop.org> Content-Type: text/plain; charset="ISO-8859-1" Organization: Citrix Systems, Inc. Date: Thu, 22 Sep 2011 07:21:13 +0100 Message-ID: <1316672473.27431.0.camel@dagon.hellion.org.uk> MIME-Version: 1.0 X-Mailer: Evolution 2.32.3 Content-Transfer-Encoding: 7bit Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>, Stefano Stabellini <Stefano.Stabellini@eu.citrix.com>, Konrad Rzeszutek Wilk <konrad.wilk@oracle.com> X-BeenThere: xen-devel@lists.xensource.com X-Mailman-Version: 2.1.5 Precedence: list List-Id: Xen developer discussion <xen-devel.lists.xensource.com> List-Unsubscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe> List-Post: <mailto:xen-devel@lists.xensource.com> List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help> List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=subscribe> Sender: xen-devel-bounces@lists.xensource.com Errors-To: xen-devel-bounces@lists.xensource.com On Wed, 2011-09-21 at 23:49 +0100, Jeremy Fitzhardinge wrote: > > That would work too. Even better would be to make it an invisible > > Kconfig symbol which PVHVM just selects. > > Eh, select is pretty nasty. Select of a non user visible symbol is perfectly fine. It's only when you select something a user can also set that things get nasty. Ian. _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel From xen-devel-bounces@lists.xensource.com Wed Sep 21 23:28:17 2011 Return-path: <xen-devel-bounces@lists.xensource.com> Envelope-to: www-data@lists.xensource.com Delivery-date: Wed, 21 Sep 2011 23:28:17 -0700 Received: from localhost ([127.0.0.1] helo=lists.colo.xensource.com) by lists.xensource.com with esmtp (Exim 4.43) id 1R6cld-0008HA-NW; Wed, 21 Sep 2011 23:28:17 -0700 Received: from mail27.messagelabs.com ([193.109.254.147]) by lists.xensource.com with esmtp (Exim 4.43) id 1R6chT-0006Za-U0 for xen-devel@lists.xensource.com; Wed, 21 Sep 2011 23:24:00 -0700 X-Env-Sender: Ian.Campbell@eu.citrix.com X-Msg-Ref: server-9.tower-27.messagelabs.com!1316672620!45521242!1 X-Originating-IP: [62.200.22.115] X-StarScan-Version: 6.4.1; banners=-,-,- X-VirusChecked: Checked Received: (qmail 12449 invoked from network); 22 Sep 2011 06:23:40 -0000 Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115) by server-9.tower-27.messagelabs.com with RC4-SHA encrypted SMTP; 22 Sep 2011 06:23:40 -0000 X-IronPort-AV: E=Sophos;i="4.68,421,1312156800"; d="scan'208";a="7995036" Received: from lonpmailmx01.citrite.net ([10.30.203.162]) by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5; 22 Sep 2011 06:23:56 +0000 Received: from [127.0.0.1] (10.80.16.67) by smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id 8.3.137.0; Thu, 22 Sep 2011 07:23:56 +0100 Subject: Re: [Xen-devel] xl create crash when using stub domains From: Ian Campbell <Ian.Campbell@eu.citrix.com> To: Jeremy Fitzhardinge <jeremy@goop.org> In-Reply-To: <4E7A6E0C.80503@goop.org> References: <4E729960.2080101@goop.org> <4E793F42.7070803@goop.org> <1316595394.3891.105.camel@zakaz.uk.xensource.com> <4E7A6E0C.80503@goop.org> Content-Type: text/plain; charset="ISO-8859-1" Organization: Citrix Systems, Inc. Date: Thu, 22 Sep 2011 07:23:55 +0100 Message-ID: <1316672635.27431.2.camel@dagon.hellion.org.uk> MIME-Version: 1.0 X-Mailer: Evolution 2.32.3 Content-Transfer-Encoding: 7bit Cc: Ian, "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>, Jackson <Ian.Jackson@eu.citrix.com>, Stefano Stabellini <Stefano.Stabellini@eu.citrix.com> X-BeenThere: xen-devel@lists.xensource.com X-Mailman-Version: 2.1.5 Precedence: list List-Id: Xen developer discussion <xen-devel.lists.xensource.com> List-Unsubscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe> List-Post: <mailto:xen-devel@lists.xensource.com> List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help> List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=subscribe> Sender: xen-devel-bounces@lists.xensource.com Errors-To: xen-devel-bounces@lists.xensource.com On Thu, 2011-09-22 at 00:06 +0100, Jeremy Fitzhardinge wrote: > On 09/21/2011 01:56 AM, Ian Campbell wrote: > > On Wed, 2011-09-21 at 02:34 +0100, Jeremy Fitzhardinge wrote: > >> On 09/15/2011 05:33 PM, Jeremy Fitzhardinge wrote: > >>> When I create an HVM domain with stubdom enabled, it crashes at: > >>> > >>> (gdb) run create -c /etc/xen/f14hv64 vcpus=4 xen_platform_pci=0 'boot="d"' > >>> Starting program: /usr/sbin/xl create -c /etc/xen/f14hv64 vcpus=4 xen_platform_pci=0 'boot="d"' > >>> [Thread debugging using libthread_db enabled] > >>> Parsing config file /etc/xen/f14hv64 > >>> xc: info: VIRTUAL MEMORY ARRANGEMENT: > >>> Loader: 0000000000100000->000000000017b9ec > >>> TOTAL: 0000000000000000->000000003f800000 > >>> ENTRY ADDRESS: 0000000000100000 > >>> xc: info: PHYSICAL MEMORY ALLOCATION: > >>> 4KB PAGES: 0x0000000000000200 > >>> 2MB PAGES: 0x00000000000001fb > >>> 1GB PAGES: 0x0000000000000000 > >>> xc: error: panic: xc_dom_bzimageloader.c:588: xc_dom_probe_bzimage_kernel: kernel is not a bzImage: Invalid kernel > > FWIW I don't get this message. It seems unrelated to the issue here but > > makes me curious... > > It's generated by xc_dom_probe_bzimage_kernel() when starting a PV > domain with pvgrub or an HVM domain with stubdoms, AFAIKT. Do you not > see it, or just not do those things? I didn't think I'd seen it (booting w/ a stubdom) but looking at the code it must have been in there somewhere. > Seems to me that a "probe" > function shouldn't be making obnoxious noise. Full ACK. Ian. _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel From xen-devel-bounces@lists.xensource.com Wed Sep 21 23:31:15 2011 Return-path: <xen-devel-bounces@lists.xensource.com> Envelope-to: www-data@lists.xensource.com Delivery-date: Wed, 21 Sep 2011 23:31:15 -0700 Received: from localhost ([127.0.0.1] helo=lists.colo.xensource.com) by lists.xensource.com with esmtp (Exim 4.43) id 1R6coV-0000E9-3r; Wed, 21 Sep 2011 23:31:15 -0700 Received: from mail182.messagelabs.com ([85.158.139.83]) by lists.xensource.com with esmtp (Exim 4.43) id 1R6cnu-0008TY-Qe for xen-devel@lists.xensource.com; Wed, 21 Sep 2011 23:30:39 -0700 X-Env-Sender: royger@gmail.com X-Msg-Ref: server-11.tower-182.messagelabs.com!1316673033!19274705!1 X-Originating-IP: [209.85.213.171] X-StarScan-Version: 6.4.1; banners=-,-,- X-VirusChecked: Checked Received: (qmail 29232 invoked from network); 22 Sep 2011 06:30:35 -0000 Received: from mail-yx0-f171.google.com (HELO mail-yx0-f171.google.com) (209.85.213.171) by server-11.tower-182.messagelabs.com with RC4-SHA encrypted SMTP; 22 Sep 2011 06:30:35 -0000 Received: by yxt3 with SMTP id 3so2535624yxt.30 for <xen-devel@lists.xensource.com>; Wed, 21 Sep 2011 23:30:33 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type; bh=AmbwXZreA2YoxSHryvGDVf0iCgBYQMUjWTvtWvKP8vA=; b=DmsiehlNGSRfE/cUo+tMmmeZuahVERbYkGkTHF6of3SjYj7whamuO3j1VQyGI4YWaj 7YwPIUyafvQWyKFo+TKwXfklakHr33Pvn9Q9gPOdOUrkRge8bx3TwKiV7auJk1FtN3dm v77BhaEjE143XL0pr9pwVdQwjtbTqk817r2Iw= MIME-Version: 1.0 Received: by 10.68.5.1 with SMTP id o1mr2187772pbo.20.1316673032893; Wed, 21 Sep 2011 23:30:32 -0700 (PDT) Received: by 10.142.154.18 with HTTP; Wed, 21 Sep 2011 23:30:32 -0700 (PDT) In-Reply-To: <CAPLaKK56td_tAULup=NsDZGm+jmvn7Fc=zchjUErpy8CaCvk2g@mail.gmail.com> References: <63e254468d6e8d81baea.1316002763@loki> <4E70B0D7.5040906@amd.com> <CAPLaKK56td_tAULup=NsDZGm+jmvn7Fc=zchjUErpy8CaCvk2g@mail.gmail.com> Date: Thu, 22 Sep 2011 08:30:32 +0200 X-Google-Sender-Auth: wR4fkszt3TddVcBMo3TNzhc9yrA Message-ID: <CAPLaKK5kQxK7av0eCEcpi7Xhj5EQtnVL+EMFSgTioT_jY3-7VQ@mail.gmail.com> Subject: Re: [Xen-devel] [PATCH] libxl: create pci backend only when there are pci devices From: =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= <roger.pau@entel.upc.edu> To: Christoph Egger <Christoph.Egger@amd.com> Content-Type: text/plain; charset=UTF-8 Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com> X-BeenThere: xen-devel@lists.xensource.com X-Mailman-Version: 2.1.5 Precedence: list List-Id: Xen developer discussion <xen-devel.lists.xensource.com> List-Unsubscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe> List-Post: <mailto:xen-devel@lists.xensource.com> List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help> List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=subscribe> Sender: xen-devel-bounces@lists.xensource.com Errors-To: xen-devel-bounces@lists.xensource.com Can this patch be applied? Thanks, Roger. _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel From xen-devel-bounces@lists.xensource.com Wed Sep 21 23:32:24 2011 Return-path: <xen-devel-bounces@lists.xensource.com> Envelope-to: www-data@lists.xensource.com Delivery-date: Wed, 21 Sep 2011 23:32:24 -0700 Received: from localhost ([127.0.0.1] helo=lists.colo.xensource.com) by lists.xensource.com with esmtp (Exim 4.43) id 1R6cpc-0000di-6z; Wed, 21 Sep 2011 23:32:24 -0700 Received: from mail27.messagelabs.com ([193.109.254.147]) by lists.xensource.com with esmtp (Exim 4.43) id 1R6co8-000058-OV for xen-devel@lists.xensource.com; Wed, 21 Sep 2011 23:30:53 -0700 X-Env-Sender: Ian.Campbell@eu.citrix.com X-Msg-Ref: server-4.tower-27.messagelabs.com!1316673031!41255207!1 X-Originating-IP: [62.200.22.115] X-StarScan-Version: 6.4.1; banners=-,-,- X-VirusChecked: Checked Received: (qmail 17822 invoked from network); 22 Sep 2011 06:30:31 -0000 Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115) by server-4.tower-27.messagelabs.com with RC4-SHA encrypted SMTP; 22 Sep 2011 06:30:31 -0000 X-IronPort-AV: E=Sophos;i="4.68,421,1312156800"; d="scan'208";a="7995109" Received: from lonpmailmx01.citrite.net ([10.30.203.162]) by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5; 22 Sep 2011 06:30:49 +0000 Received: from [127.0.0.1] (10.80.16.67) by smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id 8.3.137.0; Thu, 22 Sep 2011 07:30:49 +0100 Subject: Re: [Xen-devel] Sched_op hypercall small questions From: Ian Campbell <Ian.Campbell@citrix.com> To: Daniel Castro <evil.dani@gmail.com> In-Reply-To: <CAP2B85-_kMLh0C6NCBpRbUchNYw96drLVJu33EdKV25jJ=p+4g@mail.gmail.com> References: <CAP2B85_rPbB=hZpKJYSPgC59jU=YG6deD4ZkWMmXwtMV4un1mg@mail.gmail.com> <CA9D757C.2119E%keir.xen@gmail.com> <CAP2B85-e64NKts_iC21Bh0OL3X3nUh4jLriYfE2+stHkPfMFWg@mail.gmail.com> <4E793DC4.7080808@goop.org> <CAP2B859vtSK_tC0J6HWB_m6hjHKM18vZ7Qh6ABFejCiEfxs+6g@mail.gmail.com> <CAP2B85-_kMLh0C6NCBpRbUchNYw96drLVJu33EdKV25jJ=p+4g@mail.gmail.com> Content-Type: text/plain; charset="ISO-8859-1" Organization: Citrix Systems, Inc. Date: Thu, 22 Sep 2011 07:30:48 +0100 Message-ID: <1316673048.27431.7.camel@dagon.hellion.org.uk> MIME-Version: 1.0 X-Mailer: Evolution 2.32.3 Content-Transfer-Encoding: 7bit Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com> X-BeenThere: xen-devel@lists.xensource.com X-Mailman-Version: 2.1.5 Precedence: list List-Id: Xen developer discussion <xen-devel.lists.xensource.com> List-Unsubscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe> List-Post: <mailto:xen-devel@lists.xensource.com> List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help> List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=subscribe> Sender: xen-devel-bounces@lists.xensource.com Errors-To: xen-devel-bounces@lists.xensource.com On Thu, 2011-09-22 at 06:41 +0100, Daniel Castro wrote: > On Wed, Sep 21, 2011 at 10:28 AM, Jeremy Fitzhardinge <jeremy@goop.org> wrote: > > On 09/19/2011 11:17 PM, Daniel Castro wrote: > >> On Tue, Sep 20, 2011 at 2:41 PM, Keir Fraser <keir.xen@gmail.com> wrote: > >>> On 19/09/2011 22:21, "Daniel Castro" <evil.dani@gmail.com> wrote: > >>> > >>>> Greetings all. > >>>> > >>>> Some small question regarding schedule poll operation hypercall. > >>>> > >>>> 1. struct sched_poll poll.timeout is measured in what unit of time? > >>>> Secs, ms? ns? > >>> It is an absolute system time (rather than a duration), in nanoseconds. > >> really an absolute system time? > >> > >> When the timeout is set and the timeout is reached, the system behaves > >> like if the event had been received? i.e the bit is changed? > > > > You specify the timeout in the the form "wake up by time t". If t is in > > the past, it times out immediately. > > > >>>> 2. After issuing the hypercall_sched_op(SCHEDOP_poll, &poll); if no > >>>> timeout is used in poll struct how long will I yield the CPU? > >>> Until one of the specified event channel ports is pending. > >> If the channel port never changes (the event never arrives) then I > >> would yield for ever? > > > > If you have events unmasked and you get an unmasked event, then it will > > go into the event handler. > > My vcpu[0].evntchn_upcall_mask is 0, does this prevents the guest from > receiving events? IIRC it's vice versa: setting it to 1 prevents the guest from receiving events. > would that also explain why poll hypercall returns > immediately? I don't see any reference to the masks in xen/common/schedule.c:do_poll() so I don't think so. > According to Xen's Definitive Guide evntchn_upcall_mask > is unset at boot (my case exactly) so if it is 0 from the start and > the guest (me) has to change it to 1 in order to receive events. I think that's the wrong way round. > How can I change the flag, I tried changing the value but it does not work > like that apparently. evtchn_upcall_mask is the global mask but you may also need to unmask the specific evtchn, which means clearing the relevant bit in evtchn_mask. > > Thanks > > > >>>> 3. If I issue the hypercall and the event never comes is it possible > >>>> to to yield the CPU for ever? > >>> Yes, if you do not specify a timeout. > >> Keir thanks for the answer. > >> > >> I am trying to read from xenstore, so I have the following: > >> I write on my xenstore ring the query I want, then, > >> hypercall_event_channel_op(EVTCHNOP_send ... > >> If I read the ring inmediatly the answer is not ready so I issue a > >> hypercall_sched_op(SCHEDOP_poll, &poll); > >> But while I am entering the yield state the answer comes, so the event > >> is never seen because it has already been delivered. > > > > It generally only makes sense to poll on masked events. > > > >> > >> If I use some way to wait (just for very brief instant) after the > >> event_channel_op send then, when I check the ring the answer is there; > >> And I do not need to yield the CPU. > >> > >> Should I issue the wait after the send, rather than when I am about to > >> read the answer? > > > > What environment is this in? > > > > J > > > > > > -- > +-=====---------------------------+ > | +---------------------------------+ | This space intentionally blank > for notetaking. > | | | Daniel Castro, | > | | | Consultant/Programmer.| > | | | U Andes | > +-------------------------------------+ > > > _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel From xen-devel-bounces@lists.xensource.com Thu Sep 22 00:33:30 2011 Return-path: <xen-devel-bounces@lists.xensource.com> Envelope-to: www-data@lists.xensource.com Delivery-date: Thu, 22 Sep 2011 00:33:30 -0700 Received: from localhost ([127.0.0.1] helo=lists.colo.xensource.com) by lists.xensource.com with esmtp (Exim 4.43) id 1R6dmk-00026o-2m; Thu, 22 Sep 2011 00:33:30 -0700 Received: from mail174.messagelabs.com ([85.158.138.51]) by lists.xensource.com with esmtp (Exim 4.43) id 1R6dlx-0001uS-F5 for Xen-devel@lists.xensource.com; Thu, 22 Sep 2011 00:32:41 -0700 X-Env-Sender: Ian.Campbell@eu.citrix.com X-Msg-Ref: server-9.tower-174.messagelabs.com!1316676758!26279703!1 X-Originating-IP: [62.200.22.115] X-StarScan-Version: 6.4.1; banners=-,-,- X-VirusChecked: Checked Received: (qmail 8340 invoked from network); 22 Sep 2011 07:32:38 -0000 Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115) by server-9.tower-174.messagelabs.com with RC4-SHA encrypted SMTP; 22 Sep 2011 07:32:38 -0000 X-IronPort-AV: E=Sophos;i="4.68,421,1312156800"; d="scan'208";a="7996828" Received: from lonpmailmx01.citrite.net ([10.30.203.162]) by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5; 22 Sep 2011 07:32:37 +0000 Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net (10.30.203.162) with Microsoft SMTP Server id 8.3.137.0; Thu, 22 Sep 2011 08:32:38 +0100 Subject: Re: [Xen-devel] arch_set_info_guest() and cr1 From: Ian Campbell <Ian.Campbell@citrix.com> To: Jeremy Fitzhardinge <jeremy@goop.org> Date: Thu, 22 Sep 2011 08:32:37 +0100 In-Reply-To: <4E45DED5.40602@goop.org> References: <20110811190315.1cc6afab@mantra.us.oracle.com> <CA6A83D7.1F1E6%keir.xen@gmail.com> <20110812150115.6047b8c2@mantra.us.oracle.com> <4E45DED5.40602@goop.org> Organization: Citrix Systems, Inc. Content-Type: text/plain; charset="UTF-8" X-Mailer: Evolution 3.0.3- Content-Transfer-Encoding: 7bit Message-ID: <1316676757.23371.2.camel@zakaz.uk.xensource.com> MIME-Version: 1.0 Cc: "Xen-devel@lists.xensource.com" <Xen-devel@lists.xensource.com>, Keir Fraser <keir.xen@gmail.com> X-BeenThere: xen-devel@lists.xensource.com X-Mailman-Version: 2.1.5 Precedence: list List-Id: Xen developer discussion <xen-devel.lists.xensource.com> List-Unsubscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe> List-Post: <mailto:xen-devel@lists.xensource.com> List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help> List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=subscribe> Sender: xen-devel-bounces@lists.xensource.com Errors-To: xen-devel-bounces@lists.xensource.com (old mail, I know) On Sat, 2011-08-13 at 03:17 +0100, Jeremy Fitzhardinge wrote: > On 08/12/2011 03:01 PM, Mukesh Rathor wrote: > > Ah I see it, during save/restore, it is used. > > Well, I'm trying to keep the option of using PV paging with hybrid, so > > I may need to honor that. But that's phase 2. > > Though it would be nice to re-enable the use of PV writable pagetables > to get access to HAP, and we could do without that. > > Does Xen require that the user pagetable be a proper subset of the > kernel pagetable? If we can assume that and get proper ring protections > in the HVM container, then we can simply ignore the user pagetable (and > would have to if we want to get good syscall performance). IIRC back when I did the (now completely defunct) supervisor mode kernel stuff that was exactly the assumption which was made and it certainly worked in practice (although "require" might be a strong term). Ian. _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel From xen-devel-bounces@lists.xensource.com Thu Sep 22 00:36:25 2011 Return-path: <xen-devel-bounces@lists.xensource.com> Envelope-to: www-data@lists.xensource.com Delivery-date: Thu, 22 Sep 2011 00:36:25 -0700 Received: from localhost ([127.0.0.1] helo=lists.colo.xensource.com) by lists.xensource.com with esmtp (Exim 4.43) id 1R6dpY-0002W5-Po; Thu, 22 Sep 2011 00:36:24 -0700 Received: from mail174.messagelabs.com ([85.158.138.51]) by lists.xensource.com with esmtp (Exim 4.43) id 1R6dp3-0002JT-Sz for xen-devel@lists.xensource.com; Thu, 22 Sep 2011 00:35:54 -0700 X-Env-Sender: JBeulich@suse.com X-Msg-Ref: server-10.tower-174.messagelabs.com!1316676950!32304533!1 X-Originating-IP: [130.57.49.28] X-StarScan-Version: 6.4.1; banners=-,-,- X-VirusChecked: Checked Received: (qmail 5410 invoked from network); 22 Sep 2011 07:35:50 -0000 Received: from nat28.tlf.novell.com (HELO nat28.tlf.novell.com) (130.57.49.28) by server-10.tower-174.messagelabs.com with DHE-RSA-AES256-SHA encrypted SMTP; 22 Sep 2011 07:35:50 -0000 Received: from EMEA1-MTA by nat28.tlf.novell.com with Novell_GroupWise; Thu, 22 Sep 2011 08:35:49 +0100 Message-Id: <4E7B019002000078000573D6@nat28.tlf.novell.com> X-Mailer: Novell GroupWise Internet Agent 8.0.1 Date: Thu, 22 Sep 2011 08:36:16 +0100 From: "Jan Beulich" <JBeulich@suse.com> To: "Haitao Shan" <maillists.shan@gmail.com> References: <CAFQ2Z+fpR1UkxFEAYTD6irBUBeA3c7eJ3x1bXE0jzpdfQtH64w@mail.gmail.com> In-Reply-To: <CAFQ2Z+fpR1UkxFEAYTD6irBUBeA3c7eJ3x1bXE0jzpdfQtH64w@mail.gmail.com> Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: quoted-printable Content-Disposition: inline Cc: Keir Fraser <keir@xen.org>, xen-devel@lists.xensource.com, Ian Jackson <Ian.Jackson@eu.citrix.com> Subject: [Xen-devel] Re: [PATCH] Qemu MSI Cleaning Up X-BeenThere: xen-devel@lists.xensource.com X-Mailman-Version: 2.1.5 Precedence: list List-Id: Xen developer discussion <xen-devel.lists.xensource.com> List-Unsubscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe> List-Post: <mailto:xen-devel@lists.xensource.com> List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help> List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=subscribe> Sender: xen-devel-bounces@lists.xensource.com Errors-To: xen-devel-bounces@lists.xensource.com >>> On 22.09.11 at 02:35, Haitao Shan <maillists.shan@gmail.com> wrote: > Hi, Ian, Keir, Jan, >=20 > This patch does cleaning up of QEMU MSI handling. The fixes are: > 1. Changes made to MSI-X table mapping handling to eliminate the small > windows in which guest could have access to physical MSI-X table. > 2. MSI-X table is mapped as read-only to QEMU, as masking of MSI-X is > already in Xen now. > 3. For registers that coexists inside the MSI-X table (this could be > only PBA I think), value read from physical page would be returned. You should mention that writes to the mask bits get only used for feeding data back into reads with that change (i.e. actually masking an interrupt isn't possible), which ought to be addressed in a subsequent change (no matter that KVM doing so as well appears to be getting away up to now). > Could you please have review? >=20 > Signed-off-by: Shan Haitao <haitao.shan@intel.com> >=20 >=20 > diff --git a/hw/pass-through.c b/hw/pass-through.c > index 9c5620d..6ebed64 100644 > --- a/hw/pass-through.c > +++ b/hw/pass-through.c > @@ -92,6 +92,7 @@ >=20 > #include <unistd.h> > #include <sys/ioctl.h> > +#include <assert.h> >=20 > extern int gfx_passthru; > int igd_passthru =3D 0; > @@ -1103,6 +1104,7 @@ static void pt_iomem_map(PCIDevice *d, int i, > uint32_t e_phys, uint32_t e_size, > { > struct pt_dev *assigned_device =3D (struct pt_dev *)d; > uint32_t old_ebase =3D assigned_device->bases[i].e_physbase; > + uint32_t msix_last_pfn =3D 0, bar_last_pfn =3D 0; > int first_map =3D ( assigned_device->bases[i].e_size =3D=3D 0 ); > int ret =3D 0; >=20 > @@ -1118,39 +1120,127 @@ static void pt_iomem_map(PCIDevice *d, int i, > uint32_t e_phys, uint32_t e_size, >=20 > if ( !first_map && old_ebase !=3D -1 ) > { > - add_msix_mapping(assigned_device, i); > - /* Remove old mapping */ > - ret =3D xc_domain_memory_mapping(xc_handle, domid, > + if ( has_msix_mapping(assigned_device, i) ) > + { > + msix_last_pfn =3D (assigned_device->msix->mmio_base_addr - = 1 + > + assigned_device->msix->total_entries * 16) >> = XC_PAGE_SHIFT; > + bar_last_pfn =3D (old_ebase + e_size - 1) >> XC_PAGE_SHIFT; > + > + unregister_iomem(assigned_device->msix->mmio_base_addr); > + > + if ( assigned_device->msix->table_off ) > + { > + ret =3D xc_domain_memory_mapping(xc_handle, domid, > + old_ebase >> XC_PAGE_SHIFT, > + assigned_device->bases[i].access.maddr >> XC_PAGE_SH= IFT, > + (assigned_device->msix->mmio_base_addr >> XC_PAGE_SH= IFT) > + - (old_ebase >> XC_PAGE_SHIFT), > + DPCI_REMOVE_MAPPING); Proper indentation (and possibly using some more local variables) would certainly help reviewing as well as future readers (also further down). Which also raises the question of what the plans are wrt the upstream qemu variant. Overall the changes look good to me, but I'm hesitant to formally ack it as I'm too unfamiliar with the qemu code. In any case, unless we're concerned about old qemu, we should remove the special treatment of Dom0 by the hypervisor (in allowing it write access to these pages) once the other qemu flavor also got fixed. Jan > + if ( ret !=3D 0 ) > + { > + PT_LOG("Error: remove old mapping failed!\n"); > + return; > + } > + } > + if ( msix_last_pfn !=3D bar_last_pfn ) > + { > + assert(msix_last_pfn < bar_last_pfn); > + ret =3D xc_domain_memory_mapping(xc_handle, domid, > + msix_last_pfn + 1, > + (assigned_device->bases[i].access.maddr + > + assigned_device->msix->table_off + > + assigned_device->msix->total_entries * 16 + > + XC_PAGE_SIZE -1) >> XC_PAGE_SHIFT, > + bar_last_pfn - msix_last_pfn, > + DPCI_REMOVE_MAPPING); > + if ( ret !=3D 0 ) > + { > + PT_LOG("Error: remove old mapping failed!\n"); > + return; > + } > + } > + } > + else > + { > + /* Remove old mapping */ > + ret =3D xc_domain_memory_mapping(xc_handle, domid, > old_ebase >> XC_PAGE_SHIFT, > assigned_device->bases[i].access.maddr >> XC_PAGE_SHIFT,= > (e_size+XC_PAGE_SIZE-1) >> XC_PAGE_SHIFT, > DPCI_REMOVE_MAPPING); > - if ( ret !=3D 0 ) > - { > - PT_LOG("Error: remove old mapping failed!\n"); > - return; > + if ( ret !=3D 0 ) > + { > + PT_LOG("Error: remove old mapping failed!\n"); > + return; > + } > } > } >=20 > /* map only valid guest address */ > if (e_phys !=3D -1) > { > - /* Create new mapping */ > - ret =3D xc_domain_memory_mapping(xc_handle, domid, > + if ( has_msix_mapping(assigned_device, i) ) > + { > + assigned_device->msix->mmio_base_addr =3D > + assigned_device->bases[i].e_physbase > + + assigned_device->msix->table_off; > + > + msix_last_pfn =3D (assigned_device->msix->mmio_base_addr - = 1 + > + assigned_device->msix->total_entries * 16) >> = XC_PAGE_SHIFT; > + bar_last_pfn =3D (e_phys + e_size - 1) >> XC_PAGE_SHIFT; > + > + cpu_register_physical_memory(assigned_device->msix->mmio_bas= e_addr, > + (assigned_device->msix->total_entries * 16 + XC_PAGE_SI= ZE - 1) > + & XC_PAGE_MASK, > + assigned_device->msix->mmio_index); > + > + if ( assigned_device->msix->table_off ) > + { > + ret =3D xc_domain_memory_mapping(xc_handle, domid, > + assigned_device->bases[i].e_physbase >> XC_PAGE_SHIF= T, > + assigned_device->bases[i].access.maddr >> XC_PAGE_SH= IFT, > + (assigned_device->msix->mmio_base_addr >> XC_PAGE_SH= IFT) > + - (assigned_device->bases[i].e_physbase >> = XC_PAGE_SHIFT), > + DPCI_ADD_MAPPING); > + if ( ret !=3D 0 ) > + { > + PT_LOG("Error: remove old mapping failed!\n"); > + return; > + } > + } > + if ( msix_last_pfn !=3D bar_last_pfn ) > + { > + assert(msix_last_pfn < bar_last_pfn); > + ret =3D xc_domain_memory_mapping(xc_handle, domid, > + msix_last_pfn + 1, > + (assigned_device->bases[i].access.maddr + > + assigned_device->msix->table_off + > + assigned_device->msix->total_entries * 16 + > + XC_PAGE_SIZE -1) >> XC_PAGE_SHIFT, > + bar_last_pfn - msix_last_pfn, > + DPCI_ADD_MAPPING); > + if ( ret !=3D 0 ) > + { > + PT_LOG("Error: remove old mapping failed!\n"); > + return; > + } > + } > + } > + else > + { > + /* Create new mapping */ > + ret =3D xc_domain_memory_mapping(xc_handle, domid, > assigned_device->bases[i].e_physbase >> XC_PAGE_SHIFT, > assigned_device->bases[i].access.maddr >> XC_PAGE_SHIFT,= > (e_size+XC_PAGE_SIZE-1) >> XC_PAGE_SHIFT, > DPCI_ADD_MAPPING); >=20 > - if ( ret !=3D 0 ) > - { > - PT_LOG("Error: create new mapping failed!\n"); > + if ( ret !=3D 0 ) > + { > + PT_LOG("Error: create new mapping failed!\n"); > + } > } >=20 > - ret =3D remove_msix_mapping(assigned_device, i); > - if ( ret !=3D 0 ) > - PT_LOG("Error: remove MSI-X mmio mapping failed!\n"); > - > if ( old_ebase !=3D e_phys && old_ebase !=3D -1 ) > pt_msix_update_remap(assigned_device, i); > } > diff --git a/hw/pt-msi.c b/hw/pt-msi.c > index 71fa6f0..0134e62 100644 > --- a/hw/pt-msi.c > +++ b/hw/pt-msi.c > @@ -284,15 +284,6 @@ void pt_disable_msi_translate(struct pt_dev *dev) > dev->msi_trans_en =3D 0; > } >=20 > -/* MSI-X virtulization functions */ > -static void mask_physical_msix_entry(struct pt_dev *dev, int > entry_nr, int mask) > -{ > - void *phys_off; > - > - phys_off =3D dev->msix->phys_iomem_base + 16 * entry_nr + 12; > - *(uint32_t *)phys_off =3D mask; > -} > - > static int pt_msix_update_one(struct pt_dev *dev, int entry_nr) > { > struct msix_entry_info *entry =3D &dev->msix->msix_entry[entry_nr]; > @@ -486,7 +477,6 @@ static void pci_msix_writel(void *opaque, > target_phys_addr_t addr, uint32_t val) > { > if ( msix->enabled && !(val & 0x1) ) > pt_msix_update_one(dev, entry_nr); > - mask_physical_msix_entry(dev, entry_nr, entry->io_mem[3] & = 0x1); > } > } >=20 > @@ -519,7 +509,11 @@ static uint32_t pci_msix_readl(void *opaque, > target_phys_addr_t addr) > entry_nr =3D (addr - msix->mmio_base_addr) / 16; > offset =3D ((addr - msix->mmio_base_addr) % 16) / 4; >=20 > - return msix->msix_entry[entry_nr].io_mem[offset]; > + if ( addr - msix->mmio_base_addr < msix->total_entries * 16 ) > + return msix->msix_entry[entry_nr].io_mem[offset]; > + else > + return *(uint32_t *)(msix->phys_iomem_base + > + (addr - msix->mmio_base_addr)); > } >=20 > static CPUReadMemoryFunc *pci_msix_read[] =3D { > @@ -528,39 +522,12 @@ static CPUReadMemoryFunc *pci_msix_read[] =3D { > pci_msix_readl > }; >=20 > -int add_msix_mapping(struct pt_dev *dev, int bar_index) > -{ > - if ( !(dev->msix && dev->msix->bar_index =3D=3D bar_index) ) > - return 0; > - > - return xc_domain_memory_mapping(xc_handle, domid, > - dev->msix->mmio_base_addr >> XC_PAGE_SHIFT, > - (dev->bases[bar_index].access.maddr > - + dev->msix->table_off) >> XC_PAGE_SHIFT, > - (dev->msix->total_entries * 16 > - + XC_PAGE_SIZE -1) >> XC_PAGE_SHIFT, > - DPCI_ADD_MAPPING); > -} > - > -int remove_msix_mapping(struct pt_dev *dev, int bar_index) > +int has_msix_mapping(struct pt_dev *dev, int bar_index) > { > if ( !(dev->msix && dev->msix->bar_index =3D=3D bar_index) ) > return 0; >=20 > - dev->msix->mmio_base_addr =3D dev->bases[bar_index].e_physbase > - + dev->msix->table_off; > - > - cpu_register_physical_memory(dev->msix->mmio_base_addr, > - dev->msix->total_entries * 16, > - dev->msix->mmio_index); > - > - return xc_domain_memory_mapping(xc_handle, domid, > - dev->msix->mmio_base_addr >> XC_PAGE_SHIFT, > - (dev->bases[bar_index].access.maddr > - + dev->msix->table_off) >> XC_PAGE_SHIFT, > - (dev->msix->total_entries * 16 > - + XC_PAGE_SIZE -1) >> XC_PAGE_SHIFT, > - DPCI_REMOVE_MAPPING); > + return 1; > } >=20 > int pt_msix_init(struct pt_dev *dev, int pos) > @@ -616,7 +583,7 @@ int pt_msix_init(struct pt_dev *dev, int pos) > PT_LOG("table_off =3D %x, total_entries =3D %d\n", table_off,=20 > total_entries); > dev->msix->table_offset_adjust =3D table_off & 0x0fff; > dev->msix->phys_iomem_base =3D mmap(0, total_entries * 16 + > dev->msix->table_offset_adjust, > - PROT_WRITE | PROT_READ, MAP_SHARED | = MAP_LOCKED, > + PROT_READ, MAP_SHARED | MAP_LOCKED, > fd, dev->msix->table_base + table_off - > dev->msix->table_offset_adjust); > dev->msix->phys_iomem_base =3D (void *)((char *)dev->msix->phys_iome= m_base + > dev->msix->table_offset_adjust); > diff --git a/hw/pt-msi.h b/hw/pt-msi.h > index 9664f89..2dc1720 100644 > --- a/hw/pt-msi.h > +++ b/hw/pt-msi.h > @@ -107,10 +107,7 @@ void > pt_msix_disable(struct pt_dev *dev); >=20 > int > -remove_msix_mapping(struct pt_dev *dev, int bar_index); > - > -int > -add_msix_mapping(struct pt_dev *dev, int bar_index); > +has_msix_mapping(struct pt_dev *dev, int bar_index); >=20 > int > pt_msix_init(struct pt_dev *dev, int pos); _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel From xen-devel-bounces@lists.xensource.com Thu Sep 22 00:41:35 2011 Return-path: <xen-devel-bounces@lists.xensource.com> Envelope-to: www-data@lists.xensource.com Delivery-date: Thu, 22 Sep 2011 00:41:35 -0700 Received: from localhost ([127.0.0.1] helo=lists.colo.xensource.com) by lists.xensource.com with esmtp (Exim 4.43) id 1R6duZ-00031w-7O; Thu, 22 Sep 2011 00:41:35 -0700 Received: from mail216.messagelabs.com ([85.158.143.99]) by lists.xensource.com with esmtp (Exim 4.43) id 1R6dtr-0002pA-Jk for xen-devel@lists.xensource.com; Thu, 22 Sep 2011 00:40:51 -0700 X-Env-Sender: Ian.Campbell@eu.citrix.com X-Msg-Ref: server-12.tower-216.messagelabs.com!1316677248!13432539!1 X-Originating-IP: [62.200.22.115] X-StarScan-Version: 6.4.1; banners=-,-,- X-VirusChecked: Checked Received: (qmail 3093 invoked from network); 22 Sep 2011 07:40:48 -0000 Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115) by server-12.tower-216.messagelabs.com with RC4-SHA encrypted SMTP; 22 Sep 2011 07:40:48 -0000 X-IronPort-AV: E=Sophos;i="4.68,421,1312156800"; d="scan'208";a="7997102" Received: from lonpmailmx01.citrite.net ([10.30.203.162]) by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5; 22 Sep 2011 07:40:32 +0000 Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net (10.30.203.162) with Microsoft SMTP Server id 8.3.137.0; Thu, 22 Sep 2011 08:40:32 +0100 Subject: Re: [Xen-devel] Most up to date blktap2 kernel driver From: Ian Campbell <Ian.Campbell@citrix.com> To: Roger Pau =?ISO-8859-1?Q?Monn=E9?= <roger.pau@entel.upc.edu> Date: Thu, 22 Sep 2011 08:40:31 +0100 In-Reply-To: <CAPLaKK7zKP5v_F8kN0CvEQn1bgWMUoL7E2AcYcZOHTsP9hEURg@mail.gmail.com> References: <CAPLaKK7zKP5v_F8kN0CvEQn1bgWMUoL7E2AcYcZOHTsP9hEURg@mail.gmail.com> Organization: Citrix Systems, Inc. Content-Type: text/plain; charset="UTF-8" X-Mailer: Evolution 3.0.3- Content-Transfer-Encoding: 8bit Message-ID: <1316677231.23371.7.camel@zakaz.uk.xensource.com> MIME-Version: 1.0 Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com> X-BeenThere: xen-devel@lists.xensource.com X-Mailman-Version: 2.1.5 Precedence: list List-Id: Xen developer discussion <xen-devel.lists.xensource.com> List-Unsubscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe> List-Post: <mailto:xen-devel@lists.xensource.com> List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help> List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=subscribe> Sender: xen-devel-bounces@lists.xensource.com Errors-To: xen-devel-bounces@lists.xensource.com On Wed, 2011-08-24 at 09:09 +0100, Roger Pau Monné wrote: > Hello, > > I'm trying to port the blktap2 driver to NetBSD using a pure > user-space solution. I was just wondering about this, is your plan to bolt a block frontend onto the existing tapdisk2 process or are you building a thing using a NetBSD library for doing block devices in userspace (I think you are doing the former but either you or Christoph mentioned that library thing at one point too). The former plan would be awesome since it would make this work useful on all platforms and not just NetBSD. As you've no doubt noticed the blktap2 kernel side isn't (and won't be) in Linux upstream either. Ian. > Since blktap is not included in the kernel, I > would like to know where I can find the most up to date version of the > code, I've seen several repositories that contain blktap2 code, like: > > http://xenbits.xen.org/linux-2.6.18-xen.hg > http://xenbits.xensource.com/gitweb/?p=people/dstodden/blktap.git;a=summary > http://xenbits.xensource.com/gitweb/?p=people/dstodden/linux.git;a=summary > (I cannot access the tree of this one, I get a 404 error) > > Whats the best one to fetch to get a current version of the blktap2 code? > > Thanks, Roger. > > _______________________________________________ > Xen-devel mailing list > Xen-devel@lists.xensource.com > http://lists.xensource.com/xen-devel _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel From xen-devel-bounces@lists.xensource.com Thu Sep 22 00:44:02 2011 Return-path: <xen-devel-bounces@lists.xensource.com> Envelope-to: www-data@lists.xensource.com Delivery-date: Thu, 22 Sep 2011 00:44:02 -0700 Received: from localhost ([127.0.0.1] helo=lists.colo.xensource.com) by lists.xensource.com with esmtp (Exim 4.43) id 1R6dww-0003QR-SX; Thu, 22 Sep 2011 00:44:02 -0700 Received: from mail182.messagelabs.com ([85.158.139.83]) by lists.xensource.com with esmtp (Exim 4.43) id 1R6dwT-0003Do-0q for xen-devel@lists.xensource.com; Thu, 22 Sep 2011 00:43:33 -0700 X-Env-Sender: evil.dani@gmail.com X-Msg-Ref: server-12.tower-182.messagelabs.com!1316677409!19125848!1 X-Originating-IP: [209.85.161.43] X-StarScan-Version: 6.4.1; banners=-,-,- X-VirusChecked: Checked Received: (qmail 19973 invoked from network); 22 Sep 2011 07:43:30 -0000 Received: from mail-fx0-f43.google.com (HELO mail-fx0-f43.google.com) (209.85.161.43) by server-12.tower-182.messagelabs.com with RC4-SHA encrypted SMTP; 22 Sep 2011 07:43:30 -0000 Received: by fxh19 with SMTP id 19so3036736fxh.30 for <xen-devel@lists.xensource.com>; Thu, 22 Sep 2011 00:43:29 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; bh=W+SAL0ssgUsoNPed35dLzcREm1vGW3qf5oknOh9MZfA=; b=YxYyx7+5tzULsU0/Alfxj+PvTW1WecxIHa/qvkH+Mk3LLjbfQLzOJMG9NjJ4SYLqU7 aAX86wU3PK+ljI59VTk4nEexkwcel//oAEYN4qB3oigHrXzhILyhbMPr2hNkrfJ0Pu/W WsgyQutqnFWYtM4zdNr1StAHr5VX9fP6yTYOY= MIME-Version: 1.0 Received: by 10.223.100.71 with SMTP id x7mr2578665fan.18.1316677409684; Thu, 22 Sep 2011 00:43:29 -0700 (PDT) Received: by 10.223.97.9 with HTTP; Thu, 22 Sep 2011 00:43:29 -0700 (PDT) In-Reply-To: <1316673048.27431.7.camel@dagon.hellion.org.uk> References: <CAP2B85_rPbB=hZpKJYSPgC59jU=YG6deD4ZkWMmXwtMV4un1mg@mail.gmail.com> <CA9D757C.2119E%keir.xen@gmail.com> <CAP2B85-e64NKts_iC21Bh0OL3X3nUh4jLriYfE2+stHkPfMFWg@mail.gmail.com> <4E793DC4.7080808@goop.org> <CAP2B859vtSK_tC0J6HWB_m6hjHKM18vZ7Qh6ABFejCiEfxs+6g@mail.gmail.com> <CAP2B85-_kMLh0C6NCBpRbUchNYw96drLVJu33EdKV25jJ=p+4g@mail.gmail.com> <1316673048.27431.7.camel@dagon.hellion.org.uk> Date: Thu, 22 Sep 2011 16:43:29 +0900 Message-ID: <CAP2B858_Km8GA0ncNgKyk7u=V3uC9zn5ozwQoirescztW5EKXg@mail.gmail.com> Subject: Re: [Xen-devel] Sched_op hypercall small questions From: Daniel Castro <evil.dani@gmail.com> To: Ian Campbell <Ian.Campbell@citrix.com> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com> X-BeenThere: xen-devel@lists.xensource.com X-Mailman-Version: 2.1.5 Precedence: list List-Id: Xen developer discussion <xen-devel.lists.xensource.com> List-Unsubscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe> List-Post: <mailto:xen-devel@lists.xensource.com> List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help> List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=subscribe> Sender: xen-devel-bounces@lists.xensource.com Errors-To: xen-devel-bounces@lists.xensource.com On Thu, Sep 22, 2011 at 3:30 PM, Ian Campbell <Ian.Campbell@citrix.com> wro= te: > On Thu, 2011-09-22 at 06:41 +0100, Daniel Castro wrote: >> On Wed, Sep 21, 2011 at 10:28 AM, Jeremy Fitzhardinge <jeremy@goop.org> = wrote: >> > On 09/19/2011 11:17 PM, Daniel Castro wrote: >> >> On Tue, Sep 20, 2011 at 2:41 PM, Keir Fraser <keir.xen@gmail.com> wro= te: >> >>> On 19/09/2011 22:21, "Daniel Castro" <evil.dani@gmail.com> wrote: >> >>> >> >>>> Greetings all. >> >>>> >> >>>> Some small question regarding schedule poll operation hypercall. >> >>>> >> >>>> 1. struct sched_poll poll.timeout is measured in what unit of time? >> >>>> Secs, ms? ns? >> >>> It is an absolute system time (rather than a duration), in nanosecon= ds. >> >> really an absolute system time? >> >> >> >> When the timeout is set and the timeout is reached, the system behave= s >> >> like if the event had been received? i.e the bit is changed? >> > >> > You specify the timeout in the the form "wake up by time t". =A0If t i= s in >> > the past, it times out immediately. >> > >> >>>> 2. After issuing the hypercall_sched_op(SCHEDOP_poll, &poll); if no >> >>>> timeout is used in poll struct how long will I yield the CPU? >> >>> Until one of the specified event channel ports is pending. >> >> If the channel port never changes (the event never arrives) then I >> >> would yield for ever? >> > >> > If you have events unmasked and you get an unmasked event, then it wil= l >> > go into the event handler. >> >> My vcpu[0].evntchn_upcall_mask is 0, does this prevents the guest from >> receiving events? > > IIRC it's vice versa: setting it to 1 prevents the guest from receiving > events. > >> would that also explain why poll hypercall returns >> immediately? > > I don't see any reference to the masks in > xen/common/schedule.c:do_poll() so I don't think so. > >> =A0According to Xen's Definitive Guide evntchn_upcall_mask >> is unset at boot (my case exactly) so if it is 0 from the start and >> the guest (me) has to change it to 1 in order to receive events. > > I think that's the wrong way round. > >> How can I change the flag, I tried changing the value but it does not wo= rk >> like that apparently. > > evtchn_upcall_mask is the global mask but you may also need to unmask > the specific evtchn, which means clearing the relevant bit in > evtchn_mask. Thanks for the answer Ian, one question: If I do not manually change the mask bit, then after writing to the ring and the response arrives how can I be sure that xenstore is delivering an event? I am suspecting that xenstore does not use event notification for simple read and write operations. Could I be right? > >> >> Thanks >> > >> >>>> 3. If I issue the hypercall and the event never comes is it possibl= e >> >>>> to to yield the CPU for ever? >> >>> Yes, if you do not specify a timeout. >> >> Keir thanks for the answer. >> >> >> >> I am trying to read from xenstore, so I have the following: >> >> I write on my xenstore ring the query I want, then, >> >> hypercall_event_channel_op(EVTCHNOP_send ... >> >> If I read the ring inmediatly the answer is not ready so I issue a >> >> hypercall_sched_op(SCHEDOP_poll, &poll); >> >> But while I am entering the yield state the answer comes, so the even= t >> >> is never seen because it has already been delivered. >> > >> > It generally only makes sense to poll on masked events. >> > >> >> >> >> If I use some way to wait (just for very brief instant) after the >> >> event_channel_op send then, when I check the ring the answer is there= ; >> >> And I do not need to yield the CPU. >> >> >> >> Should I issue the wait after the send, rather than when I am about t= o >> >> read the answer? >> > >> > What environment is this in? >> > >> > =A0 =A0J >> > >> >> >> >> -- >> +-=3D=3D=3D=3D=3D---------------------------+ >> | +---------------------------------+ | This space intentionally blank >> for notetaking. >> | | =A0 | Daniel Castro, =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0| >> | | =A0 | Consultant/Programmer.| >> | | =A0 | U Andes =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 | >> +-------------------------------------+ >> >> >> > > > --=20 +-=3D=3D=3D=3D=3D---------------------------+ | +---------------------------------+ | This space intentionally blank for notetaking. | |=A0=A0 | Daniel Castro,=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 | | |=A0=A0 | Consultant/Programmer.| | |=A0=A0 | U Andes=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0=A0 | +-------------------------------------+ _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel From xen-devel-bounces@lists.xensource.com Thu Sep 22 01:04:42 2011 Return-path: <xen-devel-bounces@lists.xensource.com> Envelope-to: www-data@lists.xensource.com Delivery-date: Thu, 22 Sep 2011 01:04:42 -0700 Received: from localhost ([127.0.0.1] helo=lists.colo.xensource.com) by lists.xensource.com with esmtp (Exim 4.43) id 1R6eGv-0004Jk-Du; Thu, 22 Sep 2011 01:04:41 -0700 Received: from mail216.messagelabs.com ([85.158.143.99]) by lists.xensource.com with esmtp (Exim 4.43) id 1R6eDD-00044c-Nn for xen-devel@lists.xensource.com; Thu, 22 Sep 2011 01:01:35 -0700 X-Env-Sender: Ian.Campbell@eu.citrix.com X-Msg-Ref: server-11.tower-216.messagelabs.com!1316678448!11599395!1 X-Originating-IP: [62.200.22.115] X-StarScan-Version: 6.4.1; banners=-,-,- X-VirusChecked: Checked Received: (qmail 24359 invoked from network); 22 Sep 2011 08:00:48 -0000 Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115) by server-11.tower-216.messagelabs.com with RC4-SHA encrypted SMTP; 22 Sep 2011 08:00:48 -0000 X-IronPort-AV: E=Sophos;i="4.68,421,1312156800"; d="scan'208";a="7997544" Received: from lonpmailmx01.citrite.net ([10.30.203.162]) by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5; 22 Sep 2011 08:00:23 +0000 Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net (10.30.203.162) with Microsoft SMTP Server id 8.3.137.0; Thu, 22 Sep 2011 09:00:23 +0100 Subject: Re: [Xen-devel] Sched_op hypercall small questions From: Ian Campbell <Ian.Campbell@eu.citrix.com> To: Daniel Castro <evil.dani@gmail.com> Date: Thu, 22 Sep 2011 09:00:23 +0100 In-Reply-To: <CAP2B858_Km8GA0ncNgKyk7u=V3uC9zn5ozwQoirescztW5EKXg@mail.gmail.com> References: <CAP2B85_rPbB=hZpKJYSPgC59jU=YG6deD4ZkWMmXwtMV4un1mg@mail.gmail.com> <CA9D757C.2119E%keir.xen@gmail.com> <CAP2B85-e64NKts_iC21Bh0OL3X3nUh4jLriYfE2+stHkPfMFWg@mail.gmail.com> <4E793DC4.7080808@goop.org> <CAP2B859vtSK_tC0J6HWB_m6hjHKM18vZ7Qh6ABFejCiEfxs+6g@mail.gmail.com> <CAP2B85-_kMLh0C6NCBpRbUchNYw96drLVJu33EdKV25jJ=p+4g@mail.gmail.com> <1316673048.27431.7.camel@dagon.hellion.org.uk> <CAP2B858_Km8GA0ncNgKyk7u=V3uC9zn5ozwQoirescztW5EKXg@mail.gmail.com> Organization: Citrix Systems, Inc. Content-Type: text/plain; charset="UTF-8" X-Mailer: Evolution 3.0.3- Content-Transfer-Encoding: 7bit Message-ID: <1316678423.23371.15.camel@zakaz.uk.xensource.com> MIME-Version: 1.0 Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com> X-BeenThere: xen-devel@lists.xensource.com X-Mailman-Version: 2.1.5 Precedence: list List-Id: Xen developer discussion <xen-devel.lists.xensource.com> List-Unsubscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe> List-Post: <mailto:xen-devel@lists.xensource.com> List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help> List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=subscribe> Sender: xen-devel-bounces@lists.xensource.com Errors-To: xen-devel-bounces@lists.xensource.com On Thu, 2011-09-22 at 08:43 +0100, Daniel Castro wrote: > On Thu, Sep 22, 2011 at 3:30 PM, Ian Campbell <Ian.Campbell@citrix.com> wrote: > Thanks for the answer Ian, one question: If I do not manually change > the mask bit, then after writing to the ring and the response arrives > how can I be sure that xenstore is delivering an event? Add some printfs in the daemon? > I am suspecting that xenstore does not use event notification for simple > read and write operations. Could I be right? I don't think so, how else would it notify the client end that it should look into the ring? In the daemon the do_read() function calls the same common send_reply() as most (all?) other commands. send_reply queues a message on conn->out_list. Later on write_messages() dequeues it and calls the connections write method, which is writechn() in this case (the other case is a local socket connection which uses writefd but isn't relevant here). writechn() has an xc_evtchn_notify() at the end. Ian. > > > > >> > >> Thanks > >> > > >> >>>> 3. If I issue the hypercall and the event never comes is it possible > >> >>>> to to yield the CPU for ever? > >> >>> Yes, if you do not specify a timeout. > >> >> Keir thanks for the answer. > >> >> > >> >> I am trying to read from xenstore, so I have the following: > >> >> I write on my xenstore ring the query I want, then, > >> >> hypercall_event_channel_op(EVTCHNOP_send ... > >> >> If I read the ring inmediatly the answer is not ready so I issue a > >> >> hypercall_sched_op(SCHEDOP_poll, &poll); > >> >> But while I am entering the yield state the answer comes, so the event > >> >> is never seen because it has already been delivered. > >> > > >> > It generally only makes sense to poll on masked events. > >> > > >> >> > >> >> If I use some way to wait (just for very brief instant) after the > >> >> event_channel_op send then, when I check the ring the answer is there; > >> >> And I do not need to yield the CPU. > >> >> > >> >> Should I issue the wait after the send, rather than when I am about to > >> >> read the answer? > >> > > >> > What environment is this in? > >> > > >> > J > >> > > >> > >> > >> > >> -- > >> +-=====---------------------------+ > >> | +---------------------------------+ | This space intentionally blank > >> for notetaking. > >> | | | Daniel Castro, | > >> | | | Consultant/Programmer.| > >> | | | U Andes | > >> +-------------------------------------+ > >> > >> > >> > > > > > > > > > _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel From xen-devel-bounces@lists.xensource.com Thu Sep 22 01:18:14 2011 Return-path: <xen-devel-bounces@lists.xensource.com> Envelope-to: www-data@lists.xensource.com Delivery-date: Thu, 22 Sep 2011 01:18:14 -0700 Received: from localhost ([127.0.0.1] helo=lists.colo.xensource.com) by lists.xensource.com with esmtp (Exim 4.43) id 1R6eU1-0004uQ-B8; Thu, 22 Sep 2011 01:18:13 -0700 Received: from mail21.messagelabs.com ([85.158.143.35]) by lists.xensource.com with esmtp (Exim 4.43) id 1R6eTO-0004hk-V4 for xen-devel@lists.xensource.com; Thu, 22 Sep 2011 01:17:36 -0700 X-Env-Sender: JBeulich@suse.com X-Msg-Ref: server-12.tower-21.messagelabs.com!1316679436!50879572!1 X-Originating-IP: [130.57.49.28] X-StarScan-Version: 6.4.1; banners=-,-,- X-VirusChecked: Checked Received: (qmail 27379 invoked from network); 22 Sep 2011 08:17:16 -0000 Received: from nat28.tlf.novell.com (HELO nat28.tlf.novell.com) (130.57.49.28) by server-12.tower-21.messagelabs.com with DHE-RSA-AES256-SHA encrypted SMTP; 22 Sep 2011 08:17:16 -0000 Received: from EMEA1-MTA by nat28.tlf.novell.com with Novell_GroupWise; Thu, 22 Sep 2011 09:17:31 +0100 Message-Id: <4E7B0B550200007800057401@nat28.tlf.novell.com> X-Mailer: Novell GroupWise Internet Agent 8.0.1 Date: Thu, 22 Sep 2011 09:17:57 +0100 From: "Jan Beulich" <JBeulich@suse.com> To: "Konrad Rzeszutek Wilk" <konrad.wilk@oracle.com> Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: quoted-printable Content-Disposition: inline Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com> Subject: [Xen-devel] [PATCH] Xen/PCI: support multi-segment systems X-BeenThere: xen-devel@lists.xensource.com X-Mailman-Version: 2.1.5 Precedence: list List-Id: Xen developer discussion <xen-devel.lists.xensource.com> List-Unsubscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe> List-Post: <mailto:xen-devel@lists.xensource.com> List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help> List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=subscribe> Sender: xen-devel-bounces@lists.xensource.com Errors-To: xen-devel-bounces@lists.xensource.com Now that the hypercall interface changes are in -unstable, make the kernel side code not ignore the segment (aka domain) number anymore (which results in pretty odd behavior on such systems). Rather, if only the old interfaces are available, don't call them for devices on non-zero segments at all. The one thing I wasn't able to spot was a use of PHYSDEVOP_restore_msi (which would also need to be changed), so if there is some other patch in some tree that would be introducing this it ought to get adjusted to try using PHYSDEVOP_restore_msi_ext first. Signed-off-by: Jan Beulich <jbeulich@suse.com> --- arch/x86/pci/xen.c | 22 ++++++++- drivers/xen/pci.c | 94 +++++++++++++++++++++++++++++++++++= ----- include/xen/interface/physdev.h | 34 ++++++++++++++ 3 files changed, 136 insertions(+), 14 deletions(-) --- 3.1-rc7/arch/x86/pci/xen.c +++ 3.1-rc7-xen-pci-multi-seg/arch/x86/pci/xen.c @@ -248,6 +248,8 @@ error: } =20 #ifdef CONFIG_XEN_DOM0 +static bool __read_mostly pci_seg_supported =3D true; + static int xen_initdom_setup_msi_irqs(struct pci_dev *dev, int nvec, int = type) { int ret =3D 0; @@ -265,10 +267,11 @@ static int xen_initdom_setup_msi_irqs(st =20 memset(&map_irq, 0, sizeof(map_irq)); map_irq.domid =3D domid; - map_irq.type =3D MAP_PIRQ_TYPE_MSI; + map_irq.type =3D MAP_PIRQ_TYPE_MSI_SEG; map_irq.index =3D -1; map_irq.pirq =3D -1; - map_irq.bus =3D dev->bus->number; + map_irq.bus =3D dev->bus->number | + (pci_domain_nr(dev->bus) << 16); map_irq.devfn =3D dev->devfn; =20 if (type =3D=3D PCI_CAP_ID_MSIX) { @@ -285,7 +288,20 @@ static int xen_initdom_setup_msi_irqs(st map_irq.entry_nr =3D msidesc->msi_attrib.entry_nr; } =20 - ret =3D HYPERVISOR_physdev_op(PHYSDEVOP_map_pirq, = &map_irq); + ret =3D -EINVAL; + if (pci_seg_supported) + ret =3D HYPERVISOR_physdev_op(PHYSDEVOP_map_pirq, + &map_irq); + if (ret =3D=3D -EINVAL && !pci_domain_nr(dev->bus)) { + map_irq.type =3D MAP_PIRQ_TYPE_MSI; + map_irq.index =3D -1; + map_irq.pirq =3D -1; + map_irq.bus =3D dev->bus->number; + ret =3D HYPERVISOR_physdev_op(PHYSDEVOP_map_pirq, + &map_irq); + if (ret !=3D -EINVAL) + pci_seg_supported =3D false; + } if (ret) { dev_warn(&dev->dev, "xen map irq failed %d for %d = domain\n", ret, domid); --- 3.1-rc7/drivers/xen/pci.c +++ 3.1-rc7-xen-pci-multi-seg/drivers/xen/pci.c @@ -18,6 +18,7 @@ */ =20 #include <linux/pci.h> +#include <linux/acpi.h> #include <xen/xen.h> #include <xen/interface/physdev.h> #include <xen/interface/xen.h> @@ -26,26 +27,85 @@ #include <asm/xen/hypercall.h> #include "../pci/pci.h" =20 +static bool __read_mostly pci_seg_supported =3D true; + static int xen_add_device(struct device *dev) { int r; struct pci_dev *pci_dev =3D to_pci_dev(dev); +#ifdef CONFIG_PCI_IOV + struct pci_dev *physfn =3D pci_dev->physfn; +#endif + + if (pci_seg_supported) { + struct physdev_pci_device_add add =3D { + .seg =3D pci_domain_nr(pci_dev->bus), + .bus =3D pci_dev->bus->number, + .devfn =3D pci_dev->devfn + }; +#ifdef CONFIG_ACPI + acpi_handle handle; +#endif =20 #ifdef CONFIG_PCI_IOV - if (pci_dev->is_virtfn) { + if (pci_dev->is_virtfn) { + add.flags =3D XEN_PCI_DEV_VIRTFN; + add.physfn.bus =3D physfn->bus->number; + add.physfn.devfn =3D physfn->devfn; + } else +#endif + if (pci_ari_enabled(pci_dev->bus) && PCI_SLOT(pci_dev->devf= n)) + add.flags =3D XEN_PCI_DEV_EXTFN; + +#ifdef CONFIG_ACPI + handle =3D DEVICE_ACPI_HANDLE(&pci_dev->dev); + if (!handle) + handle =3D DEVICE_ACPI_HANDLE(pci_dev->bus->bridge)= ; +#ifdef CONFIG_PCI_IOV + if (!handle && pci_dev->is_virtfn) + handle =3D DEVICE_ACPI_HANDLE(physfn->bus->bridge);= +#endif + if (handle) { + acpi_status status; + + do { + unsigned long long pxm; + + status =3D acpi_evaluate_integer(handle, = "_PXM", + NULL, = &pxm); + if (ACPI_SUCCESS(status)) { + add.optarr[0] =3D pxm; + add.flags |=3D XEN_PCI_DEV_PXM; + break; + } + status =3D acpi_get_parent(handle, = &handle); + } while (ACPI_SUCCESS(status)); + } +#endif /* CONFIG_ACPI */ + + r =3D HYPERVISOR_physdev_op(PHYSDEVOP_pci_device_add, = &add); + if (r !=3D -ENOSYS) + return r; + pci_seg_supported =3D false; + } + + if (pci_domain_nr(pci_dev->bus)) + r =3D -ENOSYS; +#ifdef CONFIG_PCI_IOV + else if (pci_dev->is_virtfn) { struct physdev_manage_pci_ext manage_pci_ext =3D { .bus =3D pci_dev->bus->number, .devfn =3D pci_dev->devfn, .is_virtfn =3D 1, - .physfn.bus =3D pci_dev->physfn->bus->number, - .physfn.devfn =3D pci_dev->physfn->devfn, + .physfn.bus =3D physfn->bus->number, + .physfn.devfn =3D physfn->devfn, }; =20 r =3D HYPERVISOR_physdev_op(PHYSDEVOP_manage_pci_add_ext, &manage_pci_ext); - } else + } #endif - if (pci_ari_enabled(pci_dev->bus) && PCI_SLOT(pci_dev->devfn)) { + else if (pci_ari_enabled(pci_dev->bus) && PCI_SLOT(pci_dev->devfn))= { struct physdev_manage_pci_ext manage_pci_ext =3D { .bus =3D pci_dev->bus->number, .devfn =3D pci_dev->devfn, @@ -71,13 +131,27 @@ static int xen_remove_device(struct devi { int r; struct pci_dev *pci_dev =3D to_pci_dev(dev); - struct physdev_manage_pci manage_pci; =20 - manage_pci.bus =3D pci_dev->bus->number; - manage_pci.devfn =3D pci_dev->devfn; + if (pci_seg_supported) { + struct physdev_pci_device device =3D { + .seg =3D pci_domain_nr(pci_dev->bus), + .bus =3D pci_dev->bus->number, + .devfn =3D pci_dev->devfn + }; =20 - r =3D HYPERVISOR_physdev_op(PHYSDEVOP_manage_pci_remove, - &manage_pci); + r =3D HYPERVISOR_physdev_op(PHYSDEVOP_pci_device_remove, + &device); + } else if (pci_domain_nr(pci_dev->bus)) + r =3D -ENOSYS; + else { + struct physdev_manage_pci manage_pci =3D { + .bus =3D pci_dev->bus->number, + .devfn =3D pci_dev->devfn + }; + + r =3D HYPERVISOR_physdev_op(PHYSDEVOP_manage_pci_remove, + &manage_pci); + } =20 return r; } --- 3.1-rc7/include/xen/interface/physdev.h +++ 3.1-rc7-xen-pci-multi-seg/include/xen/interface/physdev.h @@ -109,6 +109,7 @@ struct physdev_irq { #define MAP_PIRQ_TYPE_MSI 0x0 #define MAP_PIRQ_TYPE_GSI 0x1 #define MAP_PIRQ_TYPE_UNKNOWN 0x2 +#define MAP_PIRQ_TYPE_MSI_SEG 0x3 =20 #define PHYSDEVOP_map_pirq 13 struct physdev_map_pirq { @@ -119,7 +120,7 @@ struct physdev_map_pirq { int index; /* IN or OUT */ int pirq; - /* IN */ + /* IN - high 16 bits hold segment for MAP_PIRQ_TYPE_MSI_SEG */ int bus; /* IN */ int devfn; @@ -198,6 +199,37 @@ struct physdev_get_free_pirq { uint32_t pirq; }; =20 +#define XEN_PCI_DEV_EXTFN 0x1 +#define XEN_PCI_DEV_VIRTFN 0x2 +#define XEN_PCI_DEV_PXM 0x4 + +#define PHYSDEVOP_pci_device_add 25 +struct physdev_pci_device_add { + /* IN */ + uint16_t seg; + uint8_t bus; + uint8_t devfn; + uint32_t flags; + struct { + uint8_t bus; + uint8_t devfn; + } physfn; +#if defined(__STDC_VERSION__) && __STDC_VERSION__ >=3D 199901L + uint32_t optarr[]; +#elif defined(__GNUC__) + uint32_t optarr[0]; +#endif +}; + +#define PHYSDEVOP_pci_device_remove 26 +#define PHYSDEVOP_restore_msi_ext 27 +struct physdev_pci_device { + /* IN */ + uint16_t seg; + uint8_t bus; + uint8_t devfn; +}; + /* * Notify that some PIRQ-bound event channels have been unmasked. * ** This command is obsolete since interface version 0x00030202 and is = ** _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel From xen-devel-bounces@lists.xensource.com Thu Sep 22 01:19:29 2011 Return-path: <xen-devel-bounces@lists.xensource.com> Envelope-to: www-data@lists.xensource.com Delivery-date: Thu, 22 Sep 2011 01:19:29 -0700 Received: from localhost ([127.0.0.1] helo=lists.colo.xensource.com) by lists.xensource.com with esmtp (Exim 4.43) id 1R6eVE-0005Hp-Is; Thu, 22 Sep 2011 01:19:28 -0700 Received: from mail174.messagelabs.com ([85.158.138.51]) by lists.xensource.com with esmtp (Exim 4.43) id 1R6eU6-0004vL-0o for xen-devel@lists.xensource.com; Thu, 22 Sep 2011 01:18:18 -0700 X-Env-Sender: Christoph.Egger@amd.com X-Msg-Ref: server-5.tower-174.messagelabs.com!1316679493!28622325!1 X-Originating-IP: [65.55.88.14] X-StarScan-Version: 6.4.1; banners=-,-,- X-VirusChecked: Checked Received: (qmail 16476 invoked from network); 22 Sep 2011 08:18:14 -0000 Received: from tx2ehsobe004.messaging.microsoft.com (HELO TX2EHSOBE008.bigfish.com) (65.55.88.14) by server-5.tower-174.messagelabs.com with AES128-SHA encrypted SMTP; 22 Sep 2011 08:18:14 -0000 Received: from mail79-tx2-R.bigfish.com (10.9.14.250) by TX2EHSOBE008.bigfish.com (10.9.40.28) with Microsoft SMTP Server id 14.1.225.22; Thu, 22 Sep 2011 08:18:13 +0000 Received: from mail79-tx2 (localhost.localdomain [127.0.0.1]) by mail79-tx2-R.bigfish.com (Postfix) with ESMTP id 4EA1E110091; Thu, 22 Sep 2011 08:18:13 +0000 (UTC) X-SpamScore: -14 X-BigFish: VPS-14(zzbb2dK936eK1432N98dKzz1202hzz8275bhz32i668h839h93fh61h) X-Spam-TCS-SCL: 0:0 X-Forefront-Antispam-Report: CIP:163.181.249.109; KIP:(null); UIP:(null); IPVD:NLI; H:ausb3twp02.amd.com; RD:none; EFVD:NLI Received: from mail79-tx2 (localhost.localdomain [127.0.0.1]) by mail79-tx2 (MessageSwitch) id 1316679493112959_16473; Thu, 22 Sep 2011 08:18:13 +0000 (UTC) Received: from TX2EHSMHS014.bigfish.com (unknown [10.9.14.248]) by mail79-tx2.bigfish.com (Postfix) with ESMTP id 14B801200051; Thu, 22 Sep 2011 08:18:13 +0000 (UTC) Received: from ausb3twp02.amd.com (163.181.249.109) by TX2EHSMHS014.bigfish.com (10.9.99.114) with Microsoft SMTP Server id 14.1.225.22; Thu, 22 Sep 2011 08:18:11 +0000 X-WSS-ID: 0LRX0E6-02-IR1-02 X-M-MSG: Received: from sausexedgep01.amd.com (sausexedgep01-ext.amd.com [163.181.249.72]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by ausb3twp02.amd.com (Axway MailGate 3.8.1) with ESMTP id 28073FCC07D; Thu, 22 Sep 2011 03:18:05 -0500 (CDT) Received: from SAUSEXDAG04.amd.com (163.181.55.4) by sausexedgep01.amd.com (163.181.36.54) with Microsoft SMTP Server (TLS) id 8.3.106.1; Thu, 22 Sep 2011 03:18:23 -0500 Received: from storexhtp01.amd.com (172.24.4.3) by sausexdag04.amd.com (163.181.55.4) with Microsoft SMTP Server (TLS) id 14.1.289.1; Thu, 22 Sep 2011 03:18:08 -0500 Received: from rhodium.osrc.amd.com (165.204.15.173) by storexhtp01.amd.com (172.24.4.3) with Microsoft SMTP Server id 8.3.83.0; Thu, 22 Sep 2011 04:17:19 -0400 Message-ID: <4E7AEF0D.5060304@amd.com> Date: Thu, 22 Sep 2011 10:17:17 +0200 From: Christoph Egger <Christoph.Egger@amd.com> User-Agent: Mozilla/5.0 (X11; U; NetBSD amd64; en-US; rv:1.9.2.17) Gecko/20110523 Lightning/1.0b3pre Thunderbird/3.1.10 MIME-Version: 1.0 To: Ian Campbell <Ian.Campbell@eu.citrix.com> Subject: Re: [Xen-devel] Re: [PATCH RESEND V8 4/7] libxl: Introduce libxl__realloc. References: <1316609997-26002-1-git-send-email-anthony.perard@citrix.com> <1316609997-26002-5-git-send-email-anthony.perard@citrix.com> <1316612077.3891.187.camel@zakaz.uk.xensource.com> <4E79ED94.1000308@amd.com> <1316619995.3891.221.camel@zakaz.uk.xensource.com> In-Reply-To: <1316619995.3891.221.camel@zakaz.uk.xensource.com> Content-Type: text/plain; charset="UTF-8"; format=flowed Content-Transfer-Encoding: 7bit X-OriginatorOrg: amd.com Cc: Anthony Perard <anthony.perard@citrix.com>, Xen Devel <xen-devel@lists.xensource.com>, Stefano Stabellini <Stefano.Stabellini@eu.citrix.com> X-BeenThere: xen-devel@lists.xensource.com X-Mailman-Version: 2.1.5 Precedence: list List-Id: Xen developer discussion <xen-devel.lists.xensource.com> List-Unsubscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe> List-Post: <mailto:xen-devel@lists.xensource.com> List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help> List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=subscribe> Sender: xen-devel-bounces@lists.xensource.com Errors-To: xen-devel-bounces@lists.xensource.com On 09/21/11 17:46, Ian Campbell wrote: > On Wed, 2011-09-21 at 14:58 +0100, Christoph Egger wrote: >> On 09/21/11 15:34, Ian Campbell wrote: >>> On Wed, 2011-09-21 at 13:59 +0100, Anthony PERARD wrote: >>>> Signed-off-by: Anthony PERARD<anthony.perard@citrix.com> >>> >>> Acked-by: Ian Campbell<ian.campbell@citrix.com> >>> >>>> --- >>>> tools/libxl/libxl_internal.c | 24 ++++++++++++++++++++++++ >>>> tools/libxl/libxl_internal.h | 1 + >>>> 2 files changed, 25 insertions(+), 0 deletions(-) >>>> >>>> diff --git a/tools/libxl/libxl_internal.c b/tools/libxl/libxl_internal.c >>>> index e259278..c4d54f9 100644 >>>> --- a/tools/libxl/libxl_internal.c >>>> +++ b/tools/libxl/libxl_internal.c >>>> @@ -102,6 +102,30 @@ void *libxl__calloc(libxl__gc *gc, size_t nmemb, size_t size) >>>> return ptr; >>>> } >>>> >>>> +void *libxl__realloc(libxl__gc *gc, void *ptr, size_t new_size) >>>> +{ >>>> + void *new_ptr = realloc(ptr, new_size); >>>> + int i = 0; >>>> + >>>> + if (new_ptr == NULL&& new_size != 0) { >>>> + return NULL; >>>> + } >>>> + >>>> + if (ptr == NULL) { >>>> + libxl__ptr_add(gc, new_ptr); >>>> + } else if (new_ptr != ptr) { >>>> + for (i = 0; i< gc->alloc_maxsize; i++) { >>>> + if (gc->alloc_ptrs[i] == ptr) { >>>> + gc->alloc_ptrs[i] = new_ptr; >>>> + break; >>>> + } >>>> + } >>>> + } >>>> + >>>> + >>>> + return new_ptr; >>>> +} >>>> + >>>> char *libxl__sprintf(libxl__gc *gc, const char *fmt, ...) >>>> { >>>> char *s; >>>> diff --git a/tools/libxl/libxl_internal.h b/tools/libxl/libxl_internal.h >>>> index 739e45e..5d270bb 100644 >>>> --- a/tools/libxl/libxl_internal.h >>>> +++ b/tools/libxl/libxl_internal.h >>>> @@ -145,6 +145,7 @@ _hidden int libxl__ptr_add(libxl__gc *gc, void *ptr); >>>> _hidden void libxl__free_all(libxl__gc *gc); >>>> _hidden void *libxl__zalloc(libxl__gc *gc, int bytes); >>>> _hidden void *libxl__calloc(libxl__gc *gc, size_t nmemb, size_t size); >> >> What is the difference between libxl__zalloc and libxl__calloc? > > The interface they provide? One of them is effectively a convenience > version of the other. Surely you can look in the code and see this as > easily as anyone else. I prefer a documentation. > >> >>>> +_hidden void *libxl__realloc(libxl__gc *gc, void *ptr, size_t new_size); >>>> _hidden char *libxl__sprintf(libxl__gc *gc, const char *fmt, ...) PRINTF_ATTRIBUTE(2, 3); >>>> _hidden char *libxl__strdup(libxl__gc *gc, const char *c); >>>> _hidden char *libxl__dirname(libxl__gc *gc, const char *s); >>> >>> >>> >>> _______________________________________________ >>> Xen-devel mailing list >>> Xen-devel@lists.xensource.com >>> http://lists.xensource.com/xen-devel >>> >> >> > > > -- ---to satisfy European Law for business letters: Advanced Micro Devices GmbH Einsteinring 24, 85689 Dornach b. Muenchen Geschaeftsfuehrer: Alberto Bozzo, Andrew Bowd Sitz: Dornach, Gemeinde Aschheim, Landkreis Muenchen Registergericht Muenchen, HRB Nr. 43632 _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel From xen-devel-bounces@lists.xensource.com Thu Sep 22 01:20:52 2011 Return-path: <xen-devel-bounces@lists.xensource.com> Envelope-to: www-data@lists.xensource.com Delivery-date: Thu, 22 Sep 2011 01:20:52 -0700 Received: from localhost ([127.0.0.1] helo=lists.colo.xensource.com) by lists.xensource.com with esmtp (Exim 4.43) id 1R6eWZ-0005ju-FY; Thu, 22 Sep 2011 01:20:52 -0700 Received: from mail27.messagelabs.com ([193.109.254.147]) by lists.xensource.com with esmtp (Exim 4.43) id 1R6eUB-0004xR-3i for xen-devel@lists.xensource.com; Thu, 22 Sep 2011 01:18:24 -0700 X-Env-Sender: Ian.Campbell@eu.citrix.com X-Msg-Ref: server-7.tower-27.messagelabs.com!1316679477!49666218!1 X-Originating-IP: [62.200.22.115] X-StarScan-Version: 6.4.1; banners=-,-,- X-VirusChecked: Checked Received: (qmail 13327 invoked from network); 22 Sep 2011 08:17:57 -0000 Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115) by server-7.tower-27.messagelabs.com with RC4-SHA encrypted SMTP; 22 Sep 2011 08:17:57 -0000 X-IronPort-AV: E=Sophos;i="4.68,421,1312156800"; d="scan'208";a="7998093" Received: from lonpmailmx01.citrite.net ([10.30.203.162]) by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5; 22 Sep 2011 08:18:19 +0000 Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net (10.30.203.162) with Microsoft SMTP Server id 8.3.137.0; Thu, 22 Sep 2011 09:18:20 +0100 From: Ian Campbell <Ian.Campbell@eu.citrix.com> To: Daniel De Graaf <dgdegra@tycho.nsa.gov> Date: Thu, 22 Sep 2011 09:18:19 +0100 In-Reply-To: <4E7A117C.4020903@tycho.nsa.gov> References: <1313764724-12683-1-git-send-email-dgdegra@tycho.nsa.gov> <1316472208-12104-1-git-send-email-dgdegra@tycho.nsa.gov> <1316472208-12104-4-git-send-email-dgdegra@tycho.nsa.gov> <1316602422.3891.171.camel@zakaz.uk.xensource.com> <4E7A117C.4020903@tycho.nsa.gov> Organization: Citrix Systems, Inc. Content-Type: text/plain; charset="UTF-8" X-Mailer: Evolution 3.0.3- Content-Transfer-Encoding: 7bit Message-ID: <1316679499.23371.22.camel@zakaz.uk.xensource.com> MIME-Version: 1.0 Cc: Stefano Stabellini <Stefano.Stabellini@eu.citrix.com>, "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>, Ian Jackson <Ian.Jackson@eu.citrix.com>, "konrad.wilk@oracle.com" <konrad.wilk@oracle.com> Subject: [Xen-devel] Re: [PATCH 3/3] libvchan: interdomain communications library X-BeenThere: xen-devel@lists.xensource.com X-Mailman-Version: 2.1.5 Precedence: list List-Id: Xen developer discussion <xen-devel.lists.xensource.com> List-Unsubscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe> List-Post: <mailto:xen-devel@lists.xensource.com> List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help> List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=subscribe> Sender: xen-devel-bounces@lists.xensource.com Errors-To: xen-devel-bounces@lists.xensource.com On Wed, 2011-09-21 at 17:31 +0100, Daniel De Graaf wrote: > On 09/21/2011 06:53 AM, Ian Campbell wrote: > > On Mon, 2011-09-19 at 23:43 +0100, Daniel De Graaf wrote: > >> This library implements a bidirectional communication interface between > >> applications in different domains, similar to unix sockets. Data can be > >> sent using the byte-oriented libvchan_read/libvchan_write or the > >> packet-oriented libvchan_recv/libvchan_send. > >> > >> Channel setup is done using a client-server model; domain IDs and a port > >> number must be negotiated prior to initialization. The server allocates > >> memory for the shared pages and determines the sizes of the > >> communication rings (which may span multiple pages, although the default > >> places rings and control within a single page). > >> > >> With properly sized rings, testing has shown that this interface > >> provides speed comparable to pipes within a single Linux domain; it is > >> significantly faster than network-based communication. > >> > >> Signed-off-by: Daniel De Graaf <dgdegra@tycho.nsa.gov> > > > > I only skimmed this one I had a few minor thoughts below but really I'm > > pretty much OK for it to go in (modulo any fallout from comments on > > patches 1+2). > > > > Definite Bonus Points for the doxygen/kernel doc commentary in the > > headers, which tool parses them? (a few comments in the code itself seem > > to have the "/**" marker but not the rest of the syntax). > > I think doxygen parses them, but I haven't personally run doxygen to > verify that it works as expected. That's ok, just having the comments at all is much appreciated! > >> +static int init_gnt_srv(struct libvchan *ctrl) > >> +{ > >> + int pages_left = ctrl->read.order >= PAGE_SHIFT ? 1 << (ctrl->read.order - PAGE_SHIFT) : 0; > > > > Here you do >= PAGE_SHIFT but on the out_unmap_left path you do > 11. > > > > (am I right that left == server and right == client in the libvhan > > terminology?) > > > > From the public/io/libvchan.h header: > * Standard consumer/producer interface, one pair per buffer > * left is client write, server read > * right is client read, server write > > So the client is on the left, if you assume the writer owns the buffer. Heh, I guess having praised the docs I should read them ;-) > > What is the significance of 2^24? > > > > Actually, this should be 20 to match MAX_RING_SIZE in init.c; OK, then I think MAX_RING_SIZE should be in a header and reused here instead of a hard-coded 20 or 24. > that number > is derived from 1024 bytes of grant data. An order of 22 will always cause > the list of grants to overrun the primary shared page; an order of 21 on > both sides will also cause this, and can also cause the grant list to overlap > the LARGE_RING area. From testing, the performance gain from larger rings > begins to drop off before 2^20 (although this may depend on the size of > your L2/L3 cache). Also, gntalloc is restricted to 1024 pages by default > (this can be adjusted via sysfs or a module parameter). Makes sense. [...] > Allowing the caller to specify the xenstore path would make the interface > more flexible, and also removes the arbitrary port numbers which already > seem likely to collide. Agreed. Ian. _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel From xen-devel-bounces@lists.xensource.com Thu Sep 22 01:33:14 2011 Return-path: <xen-devel-bounces@lists.xensource.com> Envelope-to: www-data@lists.xensource.com Delivery-date: Thu, 22 Sep 2011 01:33:14 -0700 Received: from localhost ([127.0.0.1] helo=lists.colo.xensource.com) by lists.xensource.com with esmtp (Exim 4.43) id 1R6eiY-0006Jo-5l; Thu, 22 Sep 2011 01:33:14 -0700 Received: from mail174.messagelabs.com ([85.158.138.51]) by lists.xensource.com with esmtp (Exim 4.43) id 1R6ehz-00067W-VD for xen-devel@lists.xensource.com; Thu, 22 Sep 2011 01:32:41 -0700 X-Env-Sender: Ian.Campbell@eu.citrix.com X-Msg-Ref: server-4.tower-174.messagelabs.com!1316680356!32338038!1 X-Originating-IP: [62.200.22.115] X-StarScan-Version: 6.4.1; banners=-,-,- X-VirusChecked: Checked Received: (qmail 4545 invoked from network); 22 Sep 2011 08:32:36 -0000 Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115) by server-4.tower-174.messagelabs.com with RC4-SHA encrypted SMTP; 22 Sep 2011 08:32:36 -0000 X-IronPort-AV: E=Sophos;i="4.68,421,1312156800"; d="scan'208";a="7998522" Received: from lonpmailmx01.citrite.net ([10.30.203.162]) by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5; 22 Sep 2011 08:32:36 +0000 Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net (10.30.203.162) with Microsoft SMTP Server id 8.3.137.0; Thu, 22 Sep 2011 09:32:36 +0100 From: Ian Campbell <Ian.Campbell@eu.citrix.com> To: Daniel De Graaf <dgdegra@tycho.nsa.gov> Date: Thu, 22 Sep 2011 09:32:35 +0100 In-Reply-To: <4E7A19D6.6090805@tycho.nsa.gov> References: <1313764724-12683-1-git-send-email-dgdegra@tycho.nsa.gov> <1316472208-12104-1-git-send-email-dgdegra@tycho.nsa.gov> <1316472208-12104-2-git-send-email-dgdegra@tycho.nsa.gov> <1316599431.3891.147.camel@zakaz.uk.xensource.com> <4E79FC9A.6040609@tycho.nsa.gov> <1316618733.3891.206.camel@zakaz.uk.xensource.com> <4E7A19D6.6090805@tycho.nsa.gov> Organization: Citrix Systems, Inc. Content-Type: text/plain; charset="UTF-8" X-Mailer: Evolution 3.0.3- Content-Transfer-Encoding: 7bit Message-ID: <1316680355.23371.35.camel@zakaz.uk.xensource.com> MIME-Version: 1.0 Cc: Stefano Stabellini <Stefano.Stabellini@eu.citrix.com>, "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>, Ian Jackson <Ian.Jackson@eu.citrix.com>, "konrad.wilk@oracle.com" <konrad.wilk@oracle.com> Subject: [Xen-devel] Re: [PATCH 1/3] libxc: add xc_gnttab_map_grant_ref_notify X-BeenThere: xen-devel@lists.xensource.com X-Mailman-Version: 2.1.5 Precedence: list List-Id: Xen developer discussion <xen-devel.lists.xensource.com> List-Unsubscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe> List-Post: <mailto:xen-devel@lists.xensource.com> List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help> List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=subscribe> Sender: xen-devel-bounces@lists.xensource.com Errors-To: xen-devel-bounces@lists.xensource.com On Wed, 2011-09-21 at 18:07 +0100, Daniel De Graaf wrote: > On 09/21/2011 11:25 AM, Ian Campbell wrote: > > When I map a page how do I know what the offset of it is wrt the file > > descriptor? DO I just have to remember how many pages I mapped an *= > > 4096? > > You had the offset at the time you mapped it, because that's what you > passed in the offset parameter to mmap(). Just don't lose the number :) So I guess my followup question is where does the number I pass to mmap come from... /me scrobbles in the code. Aha, so it is an output from the gntdev/gntalloc ioctls. So how about: /* IN parameters */ /* * Offset in the file descriptor for a byte within the page. This offset * is the result of the IOCTL_GNTDEV_MAP_GRANT_REF and is the same as * is used with mmap(). */ > > > >> > >>>> +}; > >>>> + > >>>> +/* Clear (set to zero) the byte specified by index */ > >>>> +#define UNMAP_NOTIFY_CLEAR_BYTE 0x1 > >>>> +/* Send an interrupt on the indicated event channel */ > >>>> +#define UNMAP_NOTIFY_SEND_EVENT 0x2 > >>>> + > >>>> #endif /* __LINUX_PUBLIC_GNTDEV_H__ */ > >>>> diff --git a/tools/libxc/xc_gnttab.c b/tools/libxc/xc_gnttab.c > >>>> index 4f55fce..3d3c63b 100644 > >>>> --- a/tools/libxc/xc_gnttab.c > >>>> +++ b/tools/libxc/xc_gnttab.c > >>>> @@ -18,6 +18,7 @@ > >>>> */ > >>>> > >>>> #include "xc_private.h" > >>>> +#include <errno.h> > >>>> > >>>> int xc_gnttab_op(xc_interface *xch, int cmd, void * op, int op_size, int count) > >>>> { > >>>> @@ -174,6 +175,28 @@ void *xc_gnttab_map_domain_grant_refs(xc_gnttab *xcg, > >>>> count, domid, refs, prot); > >>>> } > >>>> > >>>> +void *xc_gnttab_map_grant_ref_notify(xc_gnttab *xcg, > >>>> + uint32_t domid, > >>>> + uint32_t ref, > >>>> + uint32_t notify_offset, > >>>> + evtchn_port_t notify_port, > >>>> + int *notify_result) > >>>> +{ > >>>> + if (xcg->ops->u.gnttab.map_grant_ref_notify) > >>>> + return xcg->ops->u.gnttab.map_grant_ref_notify(xcg, xcg->ops_handle, > >>>> + domid, ref, notify_offset, notify_port, notify_result); > >>>> + else { > >>>> + void* area = xcg->ops->u.gnttab.map_grant_ref(xcg, xcg->ops_handle, > >>>> + domid, ref, PROT_READ|PROT_WRITE); > >>>> + if (area && notify_result) { > >>>> + *notify_result = -1; > >>>> + errno = ENOSYS; > >>>> + } > >>>> + return area; > >>>> + } > >>> > >>> I think the new public interface is fine but do we really need a new > >>> internal interface here? > >>> > >>> I think you can just add the notify_* arguments to the existing OSDEP > >>> function and have those OS backends which don't implement that feature > >>> return ENOSYS if notify_offset != 0 (or ~0 or whatever invalid value > >>> works). > >>> > >>> Why doesn't the *_notify variant take a prot argument? > >> > >> At least for the byte-clear portion of the notify, the page must be writable > >> or the notify will not work. I suppose an event channel alone could be used > >> for a read-only mapping, but normally the unmapping of a read-only mapping is > >> not an important event - although I guess you could contrive a use for this > >> type of notificaiton, so there's no reason not to allow it. > > > > If you combine this the two functions then returning EINVAL for attempts > > to map without PROT_WRITE (or whatever perm is necessary) would be > > reasonable IMHO. > > > > The ioctl already prevents you from requesting the impossible, so this should > just work. Even better. I see the check in the gntdev driver but not in the gntalloc one, is that right? > > I hadn't noticed that we have both map_gratn_ref and map_grant_refs, > > that seems like an area which could be cleaned up. (not saying you > > should, just noticing it) > > Since I'm already rewriting the osdep layer functions, I think I can replace > all 3-4 existing map functions with a single function. Awesome, thanks! > It looks like the current 2.6.32.x xen kernels also aren't returning EAGAIN, > so I'm unsure as to why this support was added. The commit in question is > 20689:fe42b16855aa by Grzegorz Milos (committed by Keir Fraser), but I don't > see any discussion on xen-devel for it. IIRC it was related to the page sharing patches which can cause grant hypercalls to return EAGAIN if the granted page is swapped or shared. I think this can only happen to backend/dom0 type operations. I think the reason it needs to return to the guest is that the paging daemon may be in the same domain and having the only vcpu block in the hypercall would deadlock. > It's also unclear why repeating the > request every millisecond in an infinite loop is better than letting the > caller handle an -EAGAIN. Yeah, the millisecond thing is pretty gross, something like sched_yield() might be a bit more palatable (if it's portable enough, although sleep could be a fallback if not) I suppose that hiding the EAGAIN handling in the library was just thought to be convenient, compared with changing all the existing users. Ian. _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel From xen-devel-bounces@lists.xensource.com Thu Sep 22 01:40:55 2011 Return-path: <xen-devel-bounces@lists.xensource.com> Envelope-to: www-data@lists.xensource.com Delivery-date: Thu, 22 Sep 2011 01:40:55 -0700 Received: from localhost ([127.0.0.1] helo=lists.colo.xensource.com) by lists.xensource.com with esmtp (Exim 4.43) id 1R6epz-0006mp-Oz; Thu, 22 Sep 2011 01:40:55 -0700 Received: from mail21.messagelabs.com ([85.158.143.35]) by lists.xensource.com with esmtp (Exim 4.43) id 1R6ep8-0006aN-CT for xen-devel@lists.xensource.com; Thu, 22 Sep 2011 01:40:02 -0700 X-Env-Sender: JBeulich@suse.com X-Msg-Ref: server-10.tower-21.messagelabs.com!1316680784!55048837!1 X-Originating-IP: [130.57.49.28] X-StarScan-Version: 6.4.1; banners=-,-,- X-VirusChecked: Checked Received: (qmail 6878 invoked from network); 22 Sep 2011 08:39:44 -0000 Received: from nat28.tlf.novell.com (HELO nat28.tlf.novell.com) (130.57.49.28) by server-10.tower-21.messagelabs.com with DHE-RSA-AES256-SHA encrypted SMTP; 22 Sep 2011 08:39:44 -0000 Received: from EMEA1-MTA by nat28.tlf.novell.com with Novell_GroupWise; Thu, 22 Sep 2011 09:39:58 +0100 Message-Id: <4E7B1098020000780005742E@nat28.tlf.novell.com> X-Mailer: Novell GroupWise Internet Agent 8.0.1 Date: Thu, 22 Sep 2011 09:40:24 +0100 From: "Jan Beulich" <JBeulich@suse.com> To: "Allen M Kay" <allen.m.kay@intel.com> Subject: RE: [Xen-devel] RE: Resend: RE: enable_ats_device() call site References: <4E79B56C0200007800056F8E@nat28.tlf.novell.com> <987664A83D2D224EAE907B061CE93D5301EE256A2C@orsmsx505.amr.corp.intel.com> In-Reply-To: <987664A83D2D224EAE907B061CE93D5301EE256A2C@orsmsx505.amr.corp.intel.com> Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: quoted-printable Content-Disposition: inline Cc: Xen Devel <xen-devel@lists.xensource.com> X-BeenThere: xen-devel@lists.xensource.com X-Mailman-Version: 2.1.5 Precedence: list List-Id: Xen developer discussion <xen-devel.lists.xensource.com> List-Unsubscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe> List-Post: <mailto:xen-devel@lists.xensource.com> List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help> List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=subscribe> Sender: xen-devel-bounces@lists.xensource.com Errors-To: xen-devel-bounces@lists.xensource.com >>> On 21.09.11 at 22:32, "Kay, Allen M" <allen.m.kay@intel.com> wrote: > Looks good to me. On a second thought I'm not sure about the free_pdev() part anymore: When having a bridge behind a bridge, and the downstream one gets removed, wouldn't that mean the upstream one would now be covering the bus range that got orphaned? Which means rather than flushing .map we'd have to copy our parent's entry. Jan > -----Original Message----- > From: Jan Beulich [mailto:JBeulich@suse.com]=20 > Sent: Wednesday, September 21, 2011 12:59 AM > To: Kay, Allen M > Cc: Xen Devel > Subject: RE: [Xen-devel] RE: Resend: RE: enable_ats_device() call site >=20 >>>> On 20.09.11 at 20:02, "Kay, Allen M" <allen.m.kay@intel.com> wrote: >> I agree that the same problem exists for bus-to-bridge mapping = function=20 >> pci_scan_device(). By the way, we probably should take the opportunity = to=20 >> give it a proper name that reflects to the true purpose of this = function. >=20 > How about the below (applying only on top of the multi-seg patches, > and not yet removing the scanning functions)? >=20 > Jan >=20 > --- a/xen/drivers/passthrough/pci.c > +++ b/xen/drivers/passthrough/pci.c > @@ -129,11 +129,67 @@ static struct pci_dev *alloc_pdev(struct > list_add(&pdev->alldevs_list, &pseg->alldevs_list); > spin_lock_init(&pdev->msix_table_lock); > =20 > + /* update bus2bridge */ > + switch ( pdev_type(pseg->nr, bus, devfn) ) > + { > + u8 sec_bus, sub_bus; > + > + case DEV_TYPE_PCIe_BRIDGE: > + break; > + > + case DEV_TYPE_PCIe2PCI_BRIDGE: > + case DEV_TYPE_LEGACY_PCI_BRIDGE: > + sec_bus =3D pci_conf_read8(pseg->nr, bus, PCI_SLOT(devfn), > + PCI_FUNC(devfn), PCI_SECONDARY_BUS)= ; > + sub_bus =3D pci_conf_read8(pseg->nr, bus, PCI_SLOT(devfn), > + PCI_FUNC(devfn), PCI_SUBORDINATE_BU= S); > + > + spin_lock(&pseg->bus2bridge_lock); > + for ( ; sec_bus <=3D sub_bus; sec_bus++ ) > + { > + pseg->bus2bridge[sec_bus].map =3D 1; > + pseg->bus2bridge[sec_bus].bus =3D bus; > + pseg->bus2bridge[sec_bus].devfn =3D devfn; > + } > + spin_unlock(&pseg->bus2bridge_lock); > + break; > + > + case DEV_TYPE_PCIe_ENDPOINT: > + case DEV_TYPE_PCI: > + break; > + > + default: > + printk(XENLOG_WARNING "%s: unknown type: %04x:%02x:%02x.%u\n= ", > + __func__, pseg->nr, bus, PCI_SLOT(devfn),=20 > PCI_FUNC(devfn)); > + break; > + } > + > return pdev; > } > =20 > -static void free_pdev(struct pci_dev *pdev) > +static void free_pdev(struct pci_seg *pseg, struct pci_dev *pdev) > { > + /* update bus2bridge */ > + switch ( pdev_type(pseg->nr, pdev->bus, pdev->devfn) ) > + { > + u8 dev, func, sec_bus, sub_bus; > + > + case DEV_TYPE_PCIe2PCI_BRIDGE: > + case DEV_TYPE_LEGACY_PCI_BRIDGE: > + dev =3D PCI_SLOT(pdev->devfn); > + func =3D PCI_FUNC(pdev->devfn); > + sec_bus =3D pci_conf_read8(pseg->nr, pdev->bus, dev, func, > + PCI_SECONDARY_BUS); > + sub_bus =3D pci_conf_read8(pseg->nr, pdev->bus, dev, func, > + PCI_SUBORDINATE_BUS); > + > + spin_lock(&pseg->bus2bridge_lock); > + for ( ; sec_bus <=3D sub_bus; sec_bus++ ) > + pseg->bus2bridge[sec_bus].map =3D 0; > + spin_unlock(&pseg->bus2bridge_lock); > + break; > + } > + > list_del(&pdev->alldevs_list); > xfree(pdev); > } > @@ -378,7 +434,7 @@ int pci_remove_device(u16 seg, u8 bus, u > if ( pdev->domain ) > list_del(&pdev->domain_list); > pci_cleanup_msi(pdev); > - free_pdev(pdev); > + free_pdev(pseg, pdev); > printk(XENLOG_DEBUG "PCI remove device %04x:%02x:%02x.%u\n",= > seg, bus, PCI_SLOT(devfn), PCI_FUNC(devfn)); > break; > @@ -546,8 +602,6 @@ static int __init _scan_pci_devices(stru > { > struct pci_dev *pdev; > int bus, dev, func; > - u8 sec_bus, sub_bus; > - int type; > =20 > for ( bus =3D 0; bus < 256; bus++ ) > { > @@ -565,41 +619,6 @@ static int __init _scan_pci_devices(stru > return -ENOMEM; > } > =20 > - /* build bus2bridge */ > - type =3D pdev_type(pseg->nr, bus, PCI_DEVFN(dev, = func)); > - switch ( type ) > - { > - case DEV_TYPE_PCIe_BRIDGE: > - break; > - > - case DEV_TYPE_PCIe2PCI_BRIDGE: > - case DEV_TYPE_LEGACY_PCI_BRIDGE: > - sec_bus =3D pci_conf_read8(pseg->nr, bus, dev, = func, > - PCI_SECONDARY_BUS); > - sub_bus =3D pci_conf_read8(pseg->nr, bus, dev, = func, > - PCI_SUBORDINATE_BUS); > - > - spin_lock(&pseg->bus2bridge_lock); > - for ( sub_bus &=3D 0xff; sec_bus <=3D sub_bus; = sec_bus++ ) > - { > - pseg->bus2bridge[sec_bus].map =3D 1; > - pseg->bus2bridge[sec_bus].bus =3D bus; > - pseg->bus2bridge[sec_bus].devfn =3D > - PCI_DEVFN(dev, func); > - } > - spin_unlock(&pseg->bus2bridge_lock); > - break; > - > - case DEV_TYPE_PCIe_ENDPOINT: > - case DEV_TYPE_PCI: > - break; > - > - default: > - printk("%s: unknown type: %04x:%02x:%02x.%u\n", > - __func__, pseg->nr, bus, dev, func); > - return -EINVAL; > - } > - > if ( !func && !(pci_conf_read8(pseg->nr, bus, dev, = func, > PCI_HEADER_TYPE) & 0x80) = ) > break; _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel From xen-devel-bounces@lists.xensource.com Thu Sep 22 01:53:32 2011 Return-path: <xen-devel-bounces@lists.xensource.com> Envelope-to: www-data@lists.xensource.com Delivery-date: Thu, 22 Sep 2011 01:53:32 -0700 Received: from localhost ([127.0.0.1] helo=lists.colo.xensource.com) by lists.xensource.com with esmtp (Exim 4.43) id 1R6f2C-0007VN-3A; Thu, 22 Sep 2011 01:53:32 -0700 Received: from mail21.messagelabs.com ([85.158.143.35]) by lists.xensource.com with esmtp (Exim 4.43) id 1R6f1S-0007Iv-85 for xen-devel@lists.xensource.com; Thu, 22 Sep 2011 01:52:46 -0700 X-Env-Sender: Ian.Campbell@eu.citrix.com X-Msg-Ref: server-11.tower-21.messagelabs.com!1316681545!43528074!1 X-Originating-IP: [62.200.22.115] X-StarScan-Version: 6.4.1; banners=-,-,- X-VirusChecked: Checked Received: (qmail 22906 invoked from network); 22 Sep 2011 08:52:26 -0000 Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115) by server-11.tower-21.messagelabs.com with RC4-SHA encrypted SMTP; 22 Sep 2011 08:52:26 -0000 X-IronPort-AV: E=Sophos;i="4.68,421,1312156800"; d="scan'208";a="7999086" Received: from lonpmailmx01.citrite.net ([10.30.203.162]) by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5; 22 Sep 2011 08:52:43 +0000 Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net (10.30.203.162) with Microsoft SMTP Server id 8.3.137.0; Thu, 22 Sep 2011 09:52:43 +0100 Subject: Re: [Xen-devel] Re: [PATCH RESEND V8 4/7] libxl: Introduce libxl__realloc. From: Ian Campbell <Ian.Campbell@eu.citrix.com> To: Christoph Egger <Christoph.Egger@amd.com> Date: Thu, 22 Sep 2011 09:52:42 +0100 In-Reply-To: <4E7AEF0D.5060304@amd.com> References: <1316609997-26002-1-git-send-email-anthony.perard@citrix.com> <1316609997-26002-5-git-send-email-anthony.perard@citrix.com> <1316612077.3891.187.camel@zakaz.uk.xensource.com> <4E79ED94.1000308@amd.com> <1316619995.3891.221.camel@zakaz.uk.xensource.com> <4E7AEF0D.5060304@amd.com> Organization: Citrix Systems, Inc. Content-Type: text/plain; charset="UTF-8" X-Mailer: Evolution 3.0.3- Content-Transfer-Encoding: 7bit Message-ID: <1316681562.23371.38.camel@zakaz.uk.xensource.com> MIME-Version: 1.0 Cc: Anthony Perard <anthony.perard@citrix.com>, Xen Devel <xen-devel@lists.xensource.com>, Stefano Stabellini <Stefano.Stabellini@eu.citrix.com> X-BeenThere: xen-devel@lists.xensource.com X-Mailman-Version: 2.1.5 Precedence: list List-Id: Xen developer discussion <xen-devel.lists.xensource.com> List-Unsubscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe> List-Post: <mailto:xen-devel@lists.xensource.com> List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help> List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=subscribe> Sender: xen-devel-bounces@lists.xensource.com Errors-To: xen-devel-bounces@lists.xensource.com > >>>> @@ -145,6 +145,7 @@ _hidden int libxl__ptr_add(libxl__gc *gc, void *ptr); > >>>> _hidden void libxl__free_all(libxl__gc *gc); > >>>> _hidden void *libxl__zalloc(libxl__gc *gc, int bytes); > >>>> _hidden void *libxl__calloc(libxl__gc *gc, size_t nmemb, size_t size); > >> > >> What is the difference between libxl__zalloc and libxl__calloc? > > > > The interface they provide? One of them is effectively a convenience > > version of the other. Surely you can look in the code and see this as > > easily as anyone else. > > I prefer a documentation. That's a fair point and somewhere which libxl is sorely lacking. Instead of just complaining back and forth, lets actually do something about it: # HG changeset patch # User Ian Campbell <ian.campbell@citrix.com> # Date 1316681499 -3600 # Node ID 239c88c68fce1289b173c499762c5bbf6308cc03 # Parent 34d7637c88e38beec40da838b943e43089e31ea7 libxl: add comments describing the internal memory allocation helpers Signed-off-by: Ian Campbell <ian.campbell@citrix.com> diff -r 34d7637c88e3 -r 239c88c68fce tools/libxl/libxl_internal.h --- a/tools/libxl/libxl_internal.h Wed Sep 21 17:04:11 2011 +0100 +++ b/tools/libxl/libxl_internal.h Thu Sep 22 09:51:39 2011 +0100 @@ -142,15 +142,40 @@ static inline libxl_ctx *libxl__gc_owner return gc->owner; } -/* memory allocation tracking/helpers */ +/* + * Memory allocation tracking/helpers + * + * See comment "libxl memory management" in libxl.h for a description + * of the framework which these calls belong to. + * + * These functions deal with memory allocations of type (a) and (d) in + * that description. + * + * All pointers returned by these functions are registered for garbage + * collection on exit from the outermost libxl callframe. + */ +/* register @ptr in @gc for free on exit from outermost libxl callframe. */ _hidden int libxl__ptr_add(libxl__gc *gc, void *ptr); +/* if this is the outermost libxl callframe then free all pointers in @gc */ _hidden void libxl__free_all(libxl__gc *gc); +/* allocate and zero @bytes. (similar to a gc'd malloc(3)+memzero()) */ _hidden void *libxl__zalloc(libxl__gc *gc, int bytes); +/* allocate and zero memory for an array of @nmemb members of @size each. + * (similar to a gc'd calloc(3)). */ _hidden void *libxl__calloc(libxl__gc *gc, size_t nmemb, size_t size); +/* change the size of the memory block pointed to by @ptr to @new_size bytes. + * unlike other allocation functions here any additional space between the + * oldsize and @new_size is not initialised (similar to a gc'd realloc(3)). */ _hidden void *libxl__realloc(libxl__gc *gc, void *ptr, size_t new_size); +/* print @fmt into an allocated string large enoughto contain the result. + * (similar to gc'd asprintf(3)). */ _hidden char *libxl__sprintf(libxl__gc *gc, const char *fmt, ...) PRINTF_ATTRIBUTE(2, 3); +/* duplicate the string @c (similar to a gc'd strdup(3)). */ _hidden char *libxl__strdup(libxl__gc *gc, const char *c); +/* duplicate at most @n bytes of string @c (similar to a gc'd strndup(3)). */ _hidden char *libxl__strndup(libxl__gc *gc, const char *c, size_t n); +/* strip the last path component from @s and return as a newly allocated + * string. (similar to a gc'd dirname(3)). */ _hidden char *libxl__dirname(libxl__gc *gc, const char *s); _hidden char **libxl__xs_kvs_of_flexarray(libxl__gc *gc, flexarray_t *array, int length); _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel From xen-devel-bounces@lists.xensource.com Thu Sep 22 02:02:55 2011 Return-path: <xen-devel-bounces@lists.xensource.com> Envelope-to: www-data@lists.xensource.com Delivery-date: Thu, 22 Sep 2011 02:02:55 -0700 Received: from localhost ([127.0.0.1] helo=lists.colo.xensource.com) by lists.xensource.com with esmtp (Exim 4.43) id 1R6fBG-00080t-LF; Thu, 22 Sep 2011 02:02:54 -0700 Received: from mail27.messagelabs.com ([193.109.254.147]) by lists.xensource.com with esmtp (Exim 4.43) id 1R6f8G-0007mf-BZ for xen-devel@lists.xensource.com; Thu, 22 Sep 2011 01:59:52 -0700 X-Env-Sender: royger@gmail.com X-Msg-Ref: server-14.tower-27.messagelabs.com!1316681969!37152405!1 X-Originating-IP: [209.85.213.43] X-StarScan-Version: 6.4.1; banners=-,-,- X-VirusChecked: Checked Received: (qmail 10460 invoked from network); 22 Sep 2011 08:59:30 -0000 Received: from mail-yw0-f43.google.com (HELO mail-yw0-f43.google.com) (209.85.213.43) by server-14.tower-27.messagelabs.com with RC4-SHA encrypted SMTP; 22 Sep 2011 08:59:30 -0000 Received: by ywm21 with SMTP id 21so2726489ywm.30 for <xen-devel@lists.xensource.com>; Thu, 22 Sep 2011 01:59:43 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type; bh=ZHPiS597srmzpHRrI/mhWRn09fLoEAqurkJmjNbk4Pc=; b=cgvatzHiFToabRf/bKnlYnoJO3FvLo0gFAdOh5SAw2FQWgPD73jOQfBhEYGTsqE64k w5m1rsBfIKY4BG6EsqajOqy66VyHbevE3sF0kwbSeDVUZ3fcf3G2UrD9jiK62aAB1150 V7qH3+eEqLKdzsfDjr6oRQzzi+b2/KhHEpyTo= MIME-Version: 1.0 Received: by 10.68.33.130 with SMTP id r2mr2782605pbi.71.1316681983397; Thu, 22 Sep 2011 01:59:43 -0700 (PDT) Received: by 10.142.154.18 with HTTP; Thu, 22 Sep 2011 01:59:43 -0700 (PDT) In-Reply-To: <1316677231.23371.7.camel@zakaz.uk.xensource.com> References: <CAPLaKK7zKP5v_F8kN0CvEQn1bgWMUoL7E2AcYcZOHTsP9hEURg@mail.gmail.com> <1316677231.23371.7.camel@zakaz.uk.xensource.com> Date: Thu, 22 Sep 2011 10:59:43 +0200 X-Google-Sender-Auth: cK6c23zBeczrPraEwUx3LINGeUY Message-ID: <CAPLaKK6GMLd8A--W2Hxknk1GW0KjwNQrECkLcWh+=kw6-vsFHA@mail.gmail.com> Subject: Re: [Xen-devel] Most up to date blktap2 kernel driver From: =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= <roger.pau@entel.upc.edu> To: Ian Campbell <Ian.Campbell@citrix.com> Content-Type: text/plain; charset=UTF-8 Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com> X-BeenThere: xen-devel@lists.xensource.com X-Mailman-Version: 2.1.5 Precedence: list List-Id: Xen developer discussion <xen-devel.lists.xensource.com> List-Unsubscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe> List-Post: <mailto:xen-devel@lists.xensource.com> List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help> List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=subscribe> Sender: xen-devel-bounces@lists.xensource.com Errors-To: xen-devel-bounces@lists.xensource.com > I was just wondering about this, is your plan to bolt a block frontend > onto the existing tapdisk2 process or are you building a thing using a > NetBSD library for doing block devices in userspace (I think you are > doing the former but either you or Christoph mentioned that library > thing at one point too). Well, my first try was to create a user-space implementation of the block devices found in blktap, so there was no need to change the current blktap tools. This is however not possible right now, because the library for implementing block and char devices as user-space daemons doesn't support mmap, and there's no clear way about how to implement this. Correct me if I'm wrong, but the second option would be to directly implement the I/O ring from user-space without using any devices, I haven't had much time to look into this, but I think this is the best way, because it doesn't involve the constant context changes that the implementation explained before has. I hope that looking into qemu disk backend file can provide me with some information about how to do this, possibly using libxc? > The former plan would be awesome since it would make this work useful on > all platforms and not just NetBSD. As you've no doubt noticed the > blktap2 kernel side isn't (and won't be) in Linux upstream either. > > Ian. _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel From xen-devel-bounces@lists.xensource.com Thu Sep 22 02:07:08 2011 Return-path: <xen-devel-bounces@lists.xensource.com> Envelope-to: www-data@lists.xensource.com Delivery-date: Thu, 22 Sep 2011 02:07:08 -0700 Received: from localhost ([127.0.0.1] helo=lists.colo.xensource.com) by lists.xensource.com with esmtp (Exim 4.43) id 1R6fFL-0008Vf-0X; Thu, 22 Sep 2011 02:07:07 -0700 Received: from mail21.messagelabs.com ([85.158.143.35]) by lists.xensource.com with esmtp (Exim 4.43) id 1R6fBG-00080M-9o for xen-devel@lists.xensource.com; Thu, 22 Sep 2011 02:03:04 -0700 X-Env-Sender: yong.zhang0@gmail.com X-Msg-Ref: server-4.tower-21.messagelabs.com!1316682135!61159339!1 X-Originating-IP: [74.125.82.171] X-StarScan-Version: 6.4.1; banners=-,-,- X-VirusChecked: Checked Received: (qmail 30789 invoked from network); 22 Sep 2011 09:02:15 -0000 Received: from mail-wy0-f171.google.com (HELO mail-wy0-f171.google.com) (74.125.82.171) by server-4.tower-21.messagelabs.com with RC4-SHA encrypted SMTP; 22 Sep 2011 09:02:15 -0000 Received: by wyh13 with SMTP id 13so1256786wyh.30 for <xen-devel@lists.xensource.com>; Thu, 22 Sep 2011 02:02:51 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=from:to:cc:subject:date:message-id:x-mailer:in-reply-to:references; bh=Xa/SiGAaWYiznweaLfl116bskA8Wfw846ysOAz/4RTY=; b=iGWHEoxz0D4hVK52C+QY/OsaOP7MrhxWCWcIvxz50NhRnfsy/vTNC6bTzANBEhnAQr YRD9gqxQd6JXYFx3kcVRAPk7q4JSkevMU2UkV7nB6xho3Dp/Z8NynkIbIieEeM+lPoOU fXUgMNlOUtZr1UawLg5V3WKdUEqu6aWcVnNjs= Received: by 10.216.72.65 with SMTP id s43mr1966078wed.40.1316682170879; Thu, 22 Sep 2011 02:02:50 -0700 (PDT) Received: from localhost ([61.148.56.138]) by mx.google.com with ESMTPS id w31sm10548009wbm.12.2011.09.22.02.02.49 (version=TLSv1/SSLv3 cipher=OTHER); Thu, 22 Sep 2011 02:02:50 -0700 (PDT) From: Yong Zhang <yong.zhang0@gmail.com> To: linux-kernel@vger.kernel.org, linux-arch@vger.kernel.org Date: Thu, 22 Sep 2011 16:58:48 +0800 Message-Id: <1316681962-8217-22-git-send-email-yong.zhang0@gmail.com> X-Mailer: git-send-email 1.7.4.1 In-Reply-To: <1316681962-8217-1-git-send-email-yong.zhang0@gmail.com> References: <1316681962-8217-1-git-send-email-yong.zhang0@gmail.com> Cc: xen-devel@lists.xensource.com, "Venkatesh Pallipadi \(Venki\)" <venki@google.com>, Jeremy Fitzhardinge <jeremy.fitzhardinge@citrix.com>, Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>, x86@kernel.org, Paul Gortmaker <paul.gortmaker@windriver.com>, Ralf Baechle <ralf@linux-mips.org>, virtualization@lists.linux-foundation.org, yong.zhang0@gmail.com, Ingo Molnar <mingo@redhat.com>, "H. Peter Anvin" <hpa@zytor.com>, tglx@linutronix.de, Andrew Morton <akpm@linux-foundation.org> Subject: [Xen-devel] [PATCH 21/55] x86: irq: Remove IRQF_DISABLED X-BeenThere: xen-devel@lists.xensource.com X-Mailman-Version: 2.1.5 Precedence: list List-Id: Xen developer discussion <xen-devel.lists.xensource.com> List-Unsubscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe> List-Post: <mailto:xen-devel@lists.xensource.com> List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help> List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=subscribe> Sender: xen-devel-bounces@lists.xensource.com Errors-To: xen-devel-bounces@lists.xensource.com Since commit [e58aa3d2: genirq: Run irq handlers with interrupts disabled], We run all interrupt handlers with interrupts disabled and we even check and yell when an interrupt handler returns with interrupts enabled (see commit [b738a50a: genirq: Warn when handler enables interrupts]). So now this flag is a NOOP and can be removed. Signed-off-by: Yong Zhang <yong.zhang0@gmail.com> --- arch/x86/include/asm/floppy.h | 4 ++-- arch/x86/kernel/hpet.c | 2 +- arch/x86/kernel/time.c | 2 +- arch/x86/xen/smp.c | 8 ++++---- arch/x86/xen/spinlock.c | 2 +- arch/x86/xen/time.c | 5 ++--- 6 files changed, 11 insertions(+), 12 deletions(-) diff --git a/arch/x86/include/asm/floppy.h b/arch/x86/include/asm/floppy.h index dbe82a5..22bf4d6 100644 --- a/arch/x86/include/asm/floppy.h +++ b/arch/x86/include/asm/floppy.h @@ -145,10 +145,10 @@ static int fd_request_irq(void) { if (can_use_virtual_dma) return request_irq(FLOPPY_IRQ, floppy_hardint, - IRQF_DISABLED, "floppy", NULL); + 0, "floppy", NULL); else return request_irq(FLOPPY_IRQ, floppy_interrupt, - IRQF_DISABLED, "floppy", NULL); + 0, "floppy", NULL); } static unsigned long dma_mem_alloc(unsigned long size) diff --git a/arch/x86/kernel/hpet.c b/arch/x86/kernel/hpet.c index b946a9e..5c21a30 100644 --- a/arch/x86/kernel/hpet.c +++ b/arch/x86/kernel/hpet.c @@ -516,7 +516,7 @@ static int hpet_setup_irq(struct hpet_dev *dev) { if (request_irq(dev->irq, hpet_interrupt_handler, - IRQF_TIMER | IRQF_DISABLED | IRQF_NOBALANCING, + IRQF_TIMER | IRQF_NOBALANCING, dev->name, dev)) return -1; diff --git a/arch/x86/kernel/time.c b/arch/x86/kernel/time.c index 25046df..0c3fc9a 100644 --- a/arch/x86/kernel/time.c +++ b/arch/x86/kernel/time.c @@ -55,7 +55,7 @@ EXPORT_SYMBOL(profile_pc); static irqreturn_t timer_interrupt(int irq, void *dev_id); static struct irqaction irq0 = { .handler = timer_interrupt, - .flags = IRQF_DISABLED | IRQF_NOBALANCING | IRQF_IRQPOLL | IRQF_TIMER, + .flags = IRQF_NOBALANCING | IRQF_IRQPOLL | IRQF_TIMER, .name = "timer" }; diff --git a/arch/x86/xen/smp.c b/arch/x86/xen/smp.c index 041d4fe..a375a75 100644 --- a/arch/x86/xen/smp.c +++ b/arch/x86/xen/smp.c @@ -100,7 +100,7 @@ static int xen_smp_intr_init(unsigned int cpu) rc = bind_ipi_to_irqhandler(XEN_RESCHEDULE_VECTOR, cpu, xen_reschedule_interrupt, - IRQF_DISABLED|IRQF_PERCPU|IRQF_NOBALANCING, + IRQF_PERCPU|IRQF_NOBALANCING, resched_name, NULL); if (rc < 0) @@ -111,7 +111,7 @@ static int xen_smp_intr_init(unsigned int cpu) rc = bind_ipi_to_irqhandler(XEN_CALL_FUNCTION_VECTOR, cpu, xen_call_function_interrupt, - IRQF_DISABLED|IRQF_PERCPU|IRQF_NOBALANCING, + IRQF_PERCPU|IRQF_NOBALANCING, callfunc_name, NULL); if (rc < 0) @@ -120,7 +120,7 @@ static int xen_smp_intr_init(unsigned int cpu) debug_name = kasprintf(GFP_KERNEL, "debug%d", cpu); rc = bind_virq_to_irqhandler(VIRQ_DEBUG, cpu, xen_debug_interrupt, - IRQF_DISABLED | IRQF_PERCPU | IRQF_NOBALANCING, + IRQF_PERCPU | IRQF_NOBALANCING, debug_name, NULL); if (rc < 0) goto fail; @@ -130,7 +130,7 @@ static int xen_smp_intr_init(unsigned int cpu) rc = bind_ipi_to_irqhandler(XEN_CALL_FUNCTION_SINGLE_VECTOR, cpu, xen_call_function_single_interrupt, - IRQF_DISABLED|IRQF_PERCPU|IRQF_NOBALANCING, + IRQF_PERCPU|IRQF_NOBALANCING, callfunc_name, NULL); if (rc < 0) diff --git a/arch/x86/xen/spinlock.c b/arch/x86/xen/spinlock.c index cc9b1e1..27882f5 100644 --- a/arch/x86/xen/spinlock.c +++ b/arch/x86/xen/spinlock.c @@ -354,7 +354,7 @@ void __cpuinit xen_init_lock_cpu(int cpu) irq = bind_ipi_to_irqhandler(XEN_SPIN_UNLOCK_VECTOR, cpu, dummy_handler, - IRQF_DISABLED|IRQF_PERCPU|IRQF_NOBALANCING, + IRQF_PERCPU|IRQF_NOBALANCING, name, NULL); diff --git a/arch/x86/xen/time.c b/arch/x86/xen/time.c index 0296a95..9157113 100644 --- a/arch/x86/xen/time.c +++ b/arch/x86/xen/time.c @@ -408,9 +408,8 @@ void xen_setup_timer(int cpu) name = "<timer kasprintf failed>"; irq = bind_virq_to_irqhandler(VIRQ_TIMER, cpu, xen_timer_interrupt, - IRQF_DISABLED|IRQF_PERCPU| - IRQF_NOBALANCING|IRQF_TIMER| - IRQF_FORCE_RESUME, + IRQF_PERCPU|IRQF_NOBALANCING| + IRQF_TIMER|IRQF_FORCE_RESUME, name, NULL); evt = &per_cpu(xen_clock_events, cpu); -- 1.7.4.1 _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel From xen-devel-bounces@lists.xensource.com Thu Sep 22 02:09:07 2011 Return-path: <xen-devel-bounces@lists.xensource.com> Envelope-to: www-data@lists.xensource.com Delivery-date: Thu, 22 Sep 2011 02:09:07 -0700 Received: from localhost ([127.0.0.1] helo=lists.colo.xensource.com) by lists.xensource.com with esmtp (Exim 4.43) id 1R6fHG-0000T2-Jk; Thu, 22 Sep 2011 02:09:06 -0700 Received: from mail216.messagelabs.com ([85.158.143.99]) by lists.xensource.com with esmtp (Exim 4.43) id 1R6fFh-00007X-EI for xen-devel@lists.xensource.com; Thu, 22 Sep 2011 02:07:30 -0700 X-Env-Sender: Ian.Campbell@eu.citrix.com X-Msg-Ref: server-7.tower-216.messagelabs.com!1316682446!19188575!1 X-Originating-IP: [62.200.22.115] X-StarScan-Version: 6.4.1; banners=-,-,- X-VirusChecked: Checked Received: (qmail 6190 invoked from network); 22 Sep 2011 09:07:26 -0000 Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115) by server-7.tower-216.messagelabs.com with RC4-SHA encrypted SMTP; 22 Sep 2011 09:07:26 -0000 X-IronPort-AV: E=Sophos;i="4.68,422,1312156800"; d="scan'208";a="7999582" Received: from lonpmailmx01.citrite.net ([10.30.203.162]) by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5; 22 Sep 2011 09:07:26 +0000 Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net (10.30.203.162) with Microsoft SMTP Server id 8.3.137.0; Thu, 22 Sep 2011 10:07:26 +0100 From: Ian Campbell <Ian.Campbell@eu.citrix.com> To: Jan Beulich <JBeulich@suse.com> Date: Thu, 22 Sep 2011 10:07:25 +0100 In-Reply-To: <4E78A5810200007800056C80@nat28.tlf.novell.com> References: <4E789EB80200007800056C68@nat28.tlf.novell.com> <4E78A5810200007800056C80@nat28.tlf.novell.com> Organization: Citrix Systems, Inc. Content-Type: text/plain; charset="UTF-8" X-Mailer: Evolution 3.0.3- Content-Transfer-Encoding: 7bit Message-ID: <1316682445.23371.42.camel@zakaz.uk.xensource.com> MIME-Version: 1.0 Cc: DongxiaoXu <dongxiao.xu@intel.com>, "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com> Subject: [Xen-devel] Re: netback commit history X-BeenThere: xen-devel@lists.xensource.com X-Mailman-Version: 2.1.5 Precedence: list List-Id: Xen developer discussion <xen-devel.lists.xensource.com> List-Unsubscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe> List-Post: <mailto:xen-devel@lists.xensource.com> List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help> List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=subscribe> Sender: xen-devel-bounces@lists.xensource.com Errors-To: xen-devel-bounces@lists.xensource.com On Tue, 2011-09-20 at 13:38 +0100, Jan Beulich wrote: > >>> On 20.09.11 at 14:10, "Jan Beulich" <JBeulich@suse.com> wrote: > >>>> On 20.09.11 at 13:26, Ian Campbell <Ian.Campbell@eu.citrix.com> wrote: > >> On Tue, 2011-09-20 at 12:04 +0100, Jan Beulich wrote: > >>> One thing I wonder about in this context is whether the > >>> netif_stop_queue() call from xenvif_close() shouldn't happen before > >>> xenvif_down() (not the least for reasons of symmetry with > >>> xenvif_open()). > >> > >> I seem to recall looking at that too, it was the same in the old kernels > >> too and I didn't know why so I avoided touching it (I was doing too much > >> other cleanup at the time to risk it). > > > > After looking further I don't think that would help (though I still think > > it would be more correct), as netif_stop_queue() basically evaluates > > to a set_bit() without any other locks taken. So it's completely > > asynchronous wrt dev_hard_start_xmit() (and its callers, which are > > the ones looking at the bit with HARD_TX_LOCK() carried out). > > Which in turn suggests that the upstream driver isn't safe either: > There's nothing preventing vif->netbk from becoming NULL between > the early check in xenvif_start_xmit() and its actual use in > xen_netbk_queue_tx_skb(). I think vif->netbk needs to be latched > into a local variable, checked against NULL, and passed instead of > vif to xen_netbk_queue_tx_skb(). The xmit function is called with txq->_xmit_lock held. I think we should be calling netif_tx_disable at some point before making vif->netbk == NULL. Need to figure out where (or if we are already doing it indirectly) Ian. _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel From xen-devel-bounces@lists.xensource.com Thu Sep 22 02:10:53 2011 Return-path: <xen-devel-bounces@lists.xensource.com> Envelope-to: www-data@lists.xensource.com Delivery-date: Thu, 22 Sep 2011 02:10:53 -0700 Received: from localhost ([127.0.0.1] helo=lists.colo.xensource.com) by lists.xensource.com with esmtp (Exim 4.43) id 1R6fIy-0000qP-GB; Thu, 22 Sep 2011 02:10:53 -0700 Received: from mail182.messagelabs.com ([85.158.139.83]) by lists.xensource.com with esmtp (Exim 4.43) id 1R6fFi-00007c-89 for xen-devel@lists.xensource.com; Thu, 22 Sep 2011 02:07:31 -0700 X-Env-Sender: yong.zhang0@gmail.com X-Msg-Ref: server-4.tower-182.messagelabs.com!1316682446!19297952!1 X-Originating-IP: [74.125.82.171] X-StarScan-Version: 6.4.1; banners=-,-,- X-VirusChecked: Checked Received: (qmail 8082 invoked from network); 22 Sep 2011 09:07:27 -0000 Received: from mail-wy0-f171.google.com (HELO mail-wy0-f171.google.com) (74.125.82.171) by server-4.tower-182.messagelabs.com with RC4-SHA encrypted SMTP; 22 Sep 2011 09:07:27 -0000 Received: by wyh13 with SMTP id 13so1262196wyh.30 for <xen-devel@lists.xensource.com>; Thu, 22 Sep 2011 02:07:26 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=from:to:cc:subject:date:message-id:x-mailer:in-reply-to:references; bh=AQuRdZrAvBkvJBx4iG4SF18UkQJreKz853MkI0YWMgg=; b=mljtVcqcTr1vlofHcEpiGVPUBZjI523mufyKDaIAWysJAOTDJLkffQyo7eKFnG4pLf FWRHMdMB3I8HxbBt7zOvrFb+AP4zhtUBQKNaw2G4G/9Ip4XqbmKYdJMt+LYpE/efAMq6 Qses4TQ+W4xJCmTPqTxxzZPq4MyZYecok30CU= Received: by 10.227.201.130 with SMTP id fa2mr1904929wbb.13.1316682446837; Thu, 22 Sep 2011 02:07:26 -0700 (PDT) Received: from localhost ([61.148.56.138]) by mx.google.com with ESMTPS id i11sm10534952wbn.25.2011.09.22.02.07.23 (version=TLSv1/SSLv3 cipher=OTHER); Thu, 22 Sep 2011 02:07:24 -0700 (PDT) From: Yong Zhang <yong.zhang0@gmail.com> To: linux-kernel@vger.kernel.org, linux-arch@vger.kernel.org Date: Thu, 22 Sep 2011 16:59:19 +0800 Message-Id: <1316681962-8217-53-git-send-email-yong.zhang0@gmail.com> X-Mailer: git-send-email 1.7.4.1 In-Reply-To: <1316681962-8217-1-git-send-email-yong.zhang0@gmail.com> References: <1316681962-8217-1-git-send-email-yong.zhang0@gmail.com> Cc: Jeremy Fitzhardinge <jeremy.fitzhardinge@citrix.com>, Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>, virtualization@lists.linux-foundation.org, yong.zhang0@gmail.com, xen-devel@lists.xensource.com, tglx@linutronix.de Subject: [Xen-devel] [PATCH 52/55] xen: irq: Remove IRQF_DISABLED X-BeenThere: xen-devel@lists.xensource.com X-Mailman-Version: 2.1.5 Precedence: list List-Id: Xen developer discussion <xen-devel.lists.xensource.com> List-Unsubscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe> List-Post: <mailto:xen-devel@lists.xensource.com> List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help> List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=subscribe> Sender: xen-devel-bounces@lists.xensource.com Errors-To: xen-devel-bounces@lists.xensource.com Since commit [e58aa3d2: genirq: Run irq handlers with interrupts disabled], We run all interrupt handlers with interrupts disabled and we even check and yell when an interrupt handler returns with interrupts enabled (see commit [b738a50a: genirq: Warn when handler enables interrupts]). So now this flag is a NOOP and can be removed. Signed-off-by: Yong Zhang <yong.zhang0@gmail.com> --- drivers/xen/evtchn.c | 2 +- drivers/xen/platform-pci.c | 2 +- 2 files changed, 2 insertions(+), 2 deletions(-) diff --git a/drivers/xen/evtchn.c b/drivers/xen/evtchn.c index dbc13e9..95e2507 100644 --- a/drivers/xen/evtchn.c +++ b/drivers/xen/evtchn.c @@ -265,7 +265,7 @@ static int evtchn_bind_to_user(struct per_user_data *u, int port) set_port_user(port, u); set_port_enabled(port, true); /* start enabled */ - rc = bind_evtchn_to_irqhandler(port, evtchn_interrupt, IRQF_DISABLED, + rc = bind_evtchn_to_irqhandler(port, evtchn_interrupt, 0, u->name, (void *)(unsigned long)port); if (rc >= 0) rc = 0; diff --git a/drivers/xen/platform-pci.c b/drivers/xen/platform-pci.c index 319dd0a..482beff 100644 --- a/drivers/xen/platform-pci.c +++ b/drivers/xen/platform-pci.c @@ -84,7 +84,7 @@ static irqreturn_t do_hvm_evtchn_intr(int irq, void *dev_id) static int xen_allocate_irq(struct pci_dev *pdev) { return request_irq(pdev->irq, do_hvm_evtchn_intr, - IRQF_DISABLED | IRQF_NOBALANCING | IRQF_TRIGGER_RISING, + IRQF_NOBALANCING | IRQF_TRIGGER_RISING, "xen-platform-pci", pdev); } -- 1.7.4.1 _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel From xen-devel-bounces@lists.xensource.com Thu Sep 22 02:12:09 2011 Return-path: <xen-devel-bounces@lists.xensource.com> Envelope-to: www-data@lists.xensource.com Delivery-date: Thu, 22 Sep 2011 02:12:09 -0700 Received: from localhost ([127.0.0.1] helo=lists.colo.xensource.com) by lists.xensource.com with esmtp (Exim 4.43) id 1R6fKD-0001Dm-R4; Thu, 22 Sep 2011 02:12:09 -0700 Received: from mail27.messagelabs.com ([193.109.254.147]) by lists.xensource.com with esmtp (Exim 4.43) id 1R6fFl-00007u-1e for xen-devel@lists.xensource.com; Thu, 22 Sep 2011 02:07:34 -0700 X-Env-Sender: konrad@oracle.com X-Msg-Ref: server-10.tower-27.messagelabs.com!1316682428!36759425!1 X-Originating-IP: [148.87.113.117] X-StarScan-Version: 6.4.1; banners=-,-,- X-VirusChecked: Checked Received: (qmail 21398 invoked from network); 22 Sep 2011 09:07:09 -0000 Received: from rcsinet15.oracle.com (HELO rcsinet15.oracle.com) (148.87.113.117) by server-10.tower-27.messagelabs.com with DHE-RSA-AES256-SHA encrypted SMTP; 22 Sep 2011 09:07:09 -0000 Received: from rtcsinet22.oracle.com (rtcsinet22.oracle.com [66.248.204.30]) by rcsinet15.oracle.com (Switch-3.4.4/Switch-3.4.4) with ESMTP id p8M970g2019201 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Thu, 22 Sep 2011 09:07:03 GMT Received: from acsmt356.oracle.com (acsmt356.oracle.com [141.146.40.156]) by rtcsinet22.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id p8M96t28022050 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 22 Sep 2011 09:06:56 GMT Received: from abhmt112.oracle.com (abhmt112.oracle.com [141.146.116.64]) by acsmt356.oracle.com (8.12.11.20060308/8.12.11) with ESMTP id p8M96nBc027783; Thu, 22 Sep 2011 04:06:49 -0500 Received: from oracle.com (/209.6.55.207) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Thu, 22 Sep 2011 02:06:49 -0700 Received: by oracle.com (Postfix, from userid 1000) id 0363D155E; Thu, 22 Sep 2011 05:06:55 -0400 (EDT) Date: Thu, 22 Sep 2011 05:06:55 -0400 From: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com> To: Jan Beulich <JBeulich@suse.com>, liang tang <liang.tang@oracle.com> Message-ID: <20110922090655.GB25694@phenom.oracle.com> References: <4E7B0B550200007800057401@nat28.tlf.novell.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <4E7B0B550200007800057401@nat28.tlf.novell.com> User-Agent: Mutt/1.5.21 (2010-09-15) X-Source-IP: rtcsinet22.oracle.com [66.248.204.30] X-CT-RefId: str=0001.0A090204.4E7AFACE.00C6,ss=1,re=0.000,fgs=0 Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com> Subject: [Xen-devel] Re: [PATCH] Xen/PCI: support multi-segment systems X-BeenThere: xen-devel@lists.xensource.com X-Mailman-Version: 2.1.5 Precedence: list List-Id: Xen developer discussion <xen-devel.lists.xensource.com> List-Unsubscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe> List-Post: <mailto:xen-devel@lists.xensource.com> List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help> List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=subscribe> Sender: xen-devel-bounces@lists.xensource.com Errors-To: xen-devel-bounces@lists.xensource.com On Thu, Sep 22, 2011 at 09:17:57AM +0100, Jan Beulich wrote: > Now that the hypercall interface changes are in -unstable, make the > kernel side code not ignore the segment (aka domain) number anymore > (which results in pretty odd behavior on such systems). Rather, if > only the old interfaces are available, don't call them for devices on > non-zero segments at all. > > The one thing I wasn't able to spot was a use of PHYSDEVOP_restore_msi > (which would also need to be changed), so if there is some other patch > in some tree that would be introducing this it ought to get adjusted > to try using PHYSDEVOP_restore_msi_ext first. Liang, Can you apply the same logic to the ACPI S3 patches as what Jan did here please? > > Signed-off-by: Jan Beulich <jbeulich@suse.com> > > --- > arch/x86/pci/xen.c | 22 ++++++++- > drivers/xen/pci.c | 94 +++++++++++++++++++++++++++++++++++----- > include/xen/interface/physdev.h | 34 ++++++++++++++ > 3 files changed, 136 insertions(+), 14 deletions(-) > > --- 3.1-rc7/arch/x86/pci/xen.c > +++ 3.1-rc7-xen-pci-multi-seg/arch/x86/pci/xen.c > @@ -248,6 +248,8 @@ error: > } > > #ifdef CONFIG_XEN_DOM0 > +static bool __read_mostly pci_seg_supported = true; > + > static int xen_initdom_setup_msi_irqs(struct pci_dev *dev, int nvec, int type) > { > int ret = 0; > @@ -265,10 +267,11 @@ static int xen_initdom_setup_msi_irqs(st > > memset(&map_irq, 0, sizeof(map_irq)); > map_irq.domid = domid; > - map_irq.type = MAP_PIRQ_TYPE_MSI; > + map_irq.type = MAP_PIRQ_TYPE_MSI_SEG; > map_irq.index = -1; > map_irq.pirq = -1; > - map_irq.bus = dev->bus->number; > + map_irq.bus = dev->bus->number | > + (pci_domain_nr(dev->bus) << 16); > map_irq.devfn = dev->devfn; > > if (type == PCI_CAP_ID_MSIX) { > @@ -285,7 +288,20 @@ static int xen_initdom_setup_msi_irqs(st > map_irq.entry_nr = msidesc->msi_attrib.entry_nr; > } > > - ret = HYPERVISOR_physdev_op(PHYSDEVOP_map_pirq, &map_irq); > + ret = -EINVAL; > + if (pci_seg_supported) > + ret = HYPERVISOR_physdev_op(PHYSDEVOP_map_pirq, > + &map_irq); > + if (ret == -EINVAL && !pci_domain_nr(dev->bus)) { > + map_irq.type = MAP_PIRQ_TYPE_MSI; > + map_irq.index = -1; > + map_irq.pirq = -1; > + map_irq.bus = dev->bus->number; > + ret = HYPERVISOR_physdev_op(PHYSDEVOP_map_pirq, > + &map_irq); > + if (ret != -EINVAL) > + pci_seg_supported = false; > + } > if (ret) { > dev_warn(&dev->dev, "xen map irq failed %d for %d domain\n", > ret, domid); > --- 3.1-rc7/drivers/xen/pci.c > +++ 3.1-rc7-xen-pci-multi-seg/drivers/xen/pci.c > @@ -18,6 +18,7 @@ > */ > > #include <linux/pci.h> > +#include <linux/acpi.h> > #include <xen/xen.h> > #include <xen/interface/physdev.h> > #include <xen/interface/xen.h> > @@ -26,26 +27,85 @@ > #include <asm/xen/hypercall.h> > #include "../pci/pci.h" > > +static bool __read_mostly pci_seg_supported = true; > + > static int xen_add_device(struct device *dev) > { > int r; > struct pci_dev *pci_dev = to_pci_dev(dev); > +#ifdef CONFIG_PCI_IOV > + struct pci_dev *physfn = pci_dev->physfn; > +#endif > + > + if (pci_seg_supported) { > + struct physdev_pci_device_add add = { > + .seg = pci_domain_nr(pci_dev->bus), > + .bus = pci_dev->bus->number, > + .devfn = pci_dev->devfn > + }; > +#ifdef CONFIG_ACPI > + acpi_handle handle; > +#endif > > #ifdef CONFIG_PCI_IOV > - if (pci_dev->is_virtfn) { > + if (pci_dev->is_virtfn) { > + add.flags = XEN_PCI_DEV_VIRTFN; > + add.physfn.bus = physfn->bus->number; > + add.physfn.devfn = physfn->devfn; > + } else > +#endif > + if (pci_ari_enabled(pci_dev->bus) && PCI_SLOT(pci_dev->devfn)) > + add.flags = XEN_PCI_DEV_EXTFN; > + > +#ifdef CONFIG_ACPI > + handle = DEVICE_ACPI_HANDLE(&pci_dev->dev); > + if (!handle) > + handle = DEVICE_ACPI_HANDLE(pci_dev->bus->bridge); > +#ifdef CONFIG_PCI_IOV > + if (!handle && pci_dev->is_virtfn) > + handle = DEVICE_ACPI_HANDLE(physfn->bus->bridge); > +#endif > + if (handle) { > + acpi_status status; > + > + do { > + unsigned long long pxm; > + > + status = acpi_evaluate_integer(handle, "_PXM", > + NULL, &pxm); > + if (ACPI_SUCCESS(status)) { > + add.optarr[0] = pxm; > + add.flags |= XEN_PCI_DEV_PXM; > + break; > + } > + status = acpi_get_parent(handle, &handle); > + } while (ACPI_SUCCESS(status)); > + } > +#endif /* CONFIG_ACPI */ > + > + r = HYPERVISOR_physdev_op(PHYSDEVOP_pci_device_add, &add); > + if (r != -ENOSYS) > + return r; > + pci_seg_supported = false; > + } > + > + if (pci_domain_nr(pci_dev->bus)) > + r = -ENOSYS; > +#ifdef CONFIG_PCI_IOV > + else if (pci_dev->is_virtfn) { > struct physdev_manage_pci_ext manage_pci_ext = { > .bus = pci_dev->bus->number, > .devfn = pci_dev->devfn, > .is_virtfn = 1, > - .physfn.bus = pci_dev->physfn->bus->number, > - .physfn.devfn = pci_dev->physfn->devfn, > + .physfn.bus = physfn->bus->number, > + .physfn.devfn = physfn->devfn, > }; > > r = HYPERVISOR_physdev_op(PHYSDEVOP_manage_pci_add_ext, > &manage_pci_ext); > - } else > + } > #endif > - if (pci_ari_enabled(pci_dev->bus) && PCI_SLOT(pci_dev->devfn)) { > + else if (pci_ari_enabled(pci_dev->bus) && PCI_SLOT(pci_dev->devfn)) { > struct physdev_manage_pci_ext manage_pci_ext = { > .bus = pci_dev->bus->number, > .devfn = pci_dev->devfn, > @@ -71,13 +131,27 @@ static int xen_remove_device(struct devi > { > int r; > struct pci_dev *pci_dev = to_pci_dev(dev); > - struct physdev_manage_pci manage_pci; > > - manage_pci.bus = pci_dev->bus->number; > - manage_pci.devfn = pci_dev->devfn; > + if (pci_seg_supported) { > + struct physdev_pci_device device = { > + .seg = pci_domain_nr(pci_dev->bus), > + .bus = pci_dev->bus->number, > + .devfn = pci_dev->devfn > + }; > > - r = HYPERVISOR_physdev_op(PHYSDEVOP_manage_pci_remove, > - &manage_pci); > + r = HYPERVISOR_physdev_op(PHYSDEVOP_pci_device_remove, > + &device); > + } else if (pci_domain_nr(pci_dev->bus)) > + r = -ENOSYS; > + else { > + struct physdev_manage_pci manage_pci = { > + .bus = pci_dev->bus->number, > + .devfn = pci_dev->devfn > + }; > + > + r = HYPERVISOR_physdev_op(PHYSDEVOP_manage_pci_remove, > + &manage_pci); > + } > > return r; > } > --- 3.1-rc7/include/xen/interface/physdev.h > +++ 3.1-rc7-xen-pci-multi-seg/include/xen/interface/physdev.h > @@ -109,6 +109,7 @@ struct physdev_irq { > #define MAP_PIRQ_TYPE_MSI 0x0 > #define MAP_PIRQ_TYPE_GSI 0x1 > #define MAP_PIRQ_TYPE_UNKNOWN 0x2 > +#define MAP_PIRQ_TYPE_MSI_SEG 0x3 > > #define PHYSDEVOP_map_pirq 13 > struct physdev_map_pirq { > @@ -119,7 +120,7 @@ struct physdev_map_pirq { > int index; > /* IN or OUT */ > int pirq; > - /* IN */ > + /* IN - high 16 bits hold segment for MAP_PIRQ_TYPE_MSI_SEG */ > int bus; > /* IN */ > int devfn; > @@ -198,6 +199,37 @@ struct physdev_get_free_pirq { > uint32_t pirq; > }; > > +#define XEN_PCI_DEV_EXTFN 0x1 > +#define XEN_PCI_DEV_VIRTFN 0x2 > +#define XEN_PCI_DEV_PXM 0x4 > + > +#define PHYSDEVOP_pci_device_add 25 > +struct physdev_pci_device_add { > + /* IN */ > + uint16_t seg; > + uint8_t bus; > + uint8_t devfn; > + uint32_t flags; > + struct { > + uint8_t bus; > + uint8_t devfn; > + } physfn; > +#if defined(__STDC_VERSION__) && __STDC_VERSION__ >= 199901L > + uint32_t optarr[]; > +#elif defined(__GNUC__) > + uint32_t optarr[0]; > +#endif > +}; > + > +#define PHYSDEVOP_pci_device_remove 26 > +#define PHYSDEVOP_restore_msi_ext 27 > +struct physdev_pci_device { > + /* IN */ > + uint16_t seg; > + uint8_t bus; > + uint8_t devfn; > +}; > + > /* > * Notify that some PIRQ-bound event channels have been unmasked. > * ** This command is obsolete since interface version 0x00030202 and is ** > _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel From xen-devel-bounces@lists.xensource.com Thu Sep 22 02:13:19 2011 Return-path: <xen-devel-bounces@lists.xensource.com> Envelope-to: www-data@lists.xensource.com Delivery-date: Thu, 22 Sep 2011 02:13:19 -0700 Received: from localhost ([127.0.0.1] helo=lists.colo.xensource.com) by lists.xensource.com with esmtp (Exim 4.43) id 1R6fLK-0001aw-1o; Thu, 22 Sep 2011 02:13:18 -0700 Received: from mail21.messagelabs.com ([85.158.143.35]) by lists.xensource.com with esmtp (Exim 4.43) id 1R6fJ9-0000rj-Na for xen-devel@lists.xensource.com; Thu, 22 Sep 2011 02:11:04 -0700 X-Env-Sender: Ian.Campbell@eu.citrix.com X-Msg-Ref: server-5.tower-21.messagelabs.com!1316682626!49071505!1 X-Originating-IP: [62.200.22.115] X-StarScan-Version: 6.4.1; banners=-,-,- X-VirusChecked: Checked Received: (qmail 19814 invoked from network); 22 Sep 2011 09:10:26 -0000 Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115) by server-5.tower-21.messagelabs.com with RC4-SHA encrypted SMTP; 22 Sep 2011 09:10:26 -0000 X-IronPort-AV: E=Sophos;i="4.68,422,1312156800"; d="scan'208";a="7999681" Received: from lonpmailmx01.citrite.net ([10.30.203.162]) by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5; 22 Sep 2011 09:10:38 +0000 Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net (10.30.203.162) with Microsoft SMTP Server id 8.3.137.0; Thu, 22 Sep 2011 10:10:38 +0100 Subject: Re: [Xen-devel] Most up to date blktap2 kernel driver From: Ian Campbell <Ian.Campbell@eu.citrix.com> To: Roger Pau =?ISO-8859-1?Q?Monn=E9?= <roger.pau@entel.upc.edu> Date: Thu, 22 Sep 2011 10:10:37 +0100 In-Reply-To: <CAPLaKK6GMLd8A--W2Hxknk1GW0KjwNQrECkLcWh+=kw6-vsFHA@mail.gmail.com> References: <CAPLaKK7zKP5v_F8kN0CvEQn1bgWMUoL7E2AcYcZOHTsP9hEURg@mail.gmail.com> <1316677231.23371.7.camel@zakaz.uk.xensource.com> <CAPLaKK6GMLd8A--W2Hxknk1GW0KjwNQrECkLcWh+=kw6-vsFHA@mail.gmail.com> Organization: Citrix Systems, Inc. Content-Type: text/plain; charset="UTF-8" X-Mailer: Evolution 3.0.3- Content-Transfer-Encoding: 8bit Message-ID: <1316682637.23371.45.camel@zakaz.uk.xensource.com> MIME-Version: 1.0 Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com> X-BeenThere: xen-devel@lists.xensource.com X-Mailman-Version: 2.1.5 Precedence: list List-Id: Xen developer discussion <xen-devel.lists.xensource.com> List-Unsubscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe> List-Post: <mailto:xen-devel@lists.xensource.com> List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help> List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=subscribe> Sender: xen-devel-bounces@lists.xensource.com Errors-To: xen-devel-bounces@lists.xensource.com On Thu, 2011-09-22 at 09:59 +0100, Roger Pau Monné wrote: > > I was just wondering about this, is your plan to bolt a block frontend > > onto the existing tapdisk2 process or are you building a thing using a > > NetBSD library for doing block devices in userspace (I think you are > > doing the former but either you or Christoph mentioned that library > > thing at one point too). > > Well, my first try was to create a user-space implementation of the > block devices found in blktap, so there was no need to change the > current blktap tools. This is however not possible right now, because > the library for implementing block and char devices as user-space > daemons doesn't support mmap, and there's no clear way about how to > implement this. Right. And that would be very OS specific I guess? > Correct me if I'm wrong, but the second option would be to directly > implement the I/O ring from user-space without using any devices, Yes, that is what I was suggesting. I think we generally have consensus that this is the right direction to take blktap. > I haven't had much time to look into this, but I think this is the best > way, because it doesn't involve the constant context changes that the > implementation explained before has. I hope that looking into qemu > disk backend file can provide me with some information about how to do > this, possibly using libxc? Using libxc would be better than using the OS provided interfaces directly since it abstracts out the differences between the ioctls/devices on different OSs. > > > The former plan would be awesome since it would make this work useful on > > all platforms and not just NetBSD. As you've no doubt noticed the > > blktap2 kernel side isn't (and won't be) in Linux upstream either. > > > > Ian. _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel From xen-devel-bounces@lists.xensource.com Thu Sep 22 02:48:53 2011 Return-path: <xen-devel-bounces@lists.xensource.com> Envelope-to: www-data@lists.xensource.com Delivery-date: Thu, 22 Sep 2011 02:48:53 -0700 Received: from localhost ([127.0.0.1] helo=lists.colo.xensource.com) by lists.xensource.com with esmtp (Exim 4.43) id 1R6ftl-0002oT-6K; Thu, 22 Sep 2011 02:48:53 -0700 Received: from mail216.messagelabs.com ([85.158.143.99]) by lists.xensource.com with esmtp (Exim 4.43) id 1R6fsy-0002cd-Hr; Thu, 22 Sep 2011 02:48:04 -0700 X-Env-Sender: pasik@iki.fi X-Msg-Ref: server-10.tower-216.messagelabs.com!1316684880!11110480!1 X-Originating-IP: [192.89.123.25] X-StarScan-Version: 6.4.1; banners=-,-,- X-VirusChecked: Checked Received: (qmail 15399 invoked from network); 22 Sep 2011 09:48:01 -0000 Received: from smtp.tele.fi (HELO smtp.tele.fi) (192.89.123.25) by server-10.tower-216.messagelabs.com with DHE-RSA-AES256-SHA encrypted SMTP; 22 Sep 2011 09:48:01 -0000 X-Originating-Ip: [194.89.68.22] Received: from ydin.reaktio.net (reaktio.net [194.89.68.22]) by smtp.tele.fi (Postfix) with ESMTP id 014B3253C; Thu, 22 Sep 2011 12:47:57 +0300 (EEST) Received: by ydin.reaktio.net (Postfix, from userid 1001) id 9FC01200EA; Thu, 22 Sep 2011 12:47:57 +0300 (EEST) Date: Thu, 22 Sep 2011 12:47:57 +0300 From: Pasi =?iso-8859-1?Q?K=E4rkk=E4inen?= <pasik@iki.fi> To: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com> Subject: Re: [Xen-devel] Re: Virtualization Test Day for F16 and Xen Message-ID: <20110922094757.GB12984@reaktio.net> References: <20110914112552.GP12984@reaktio.net> <20110914142522.GA16956@phenom.oracle.com> <20110914144539.GR12984@reaktio.net> <20110915151041.GA4453@imp.local> <1316126290.5689.3.camel@adam> <20110916084308.GD884@phenom.oracle.com> <4E77A4EC.9080600@goop.org> <20110921200348.GA31078@phenom.oracle.com> <4E7A6947.5090205@goop.org> <20110921225957.GA17396@phenom.oracle.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20110921225957.GA17396@phenom.oracle.com> User-Agent: Mutt/1.5.18 (2008-05-17) Cc: Development discussions related to Fedora <devel@lists.fedoraproject.org>, xen@lists.fedoraproject.org, Jeremy Fitzhardinge <jeremy@goop.org>, xen-devel@lists.xensource.com, Stefano Stabellini <stefano.stabellini@eu.citrix.com>, lars.kurth@xen.org, virt@lists.fedoraproject.org, xen-users@lists.xensource.com, Adam Williamson <awilliam@redhat.com> X-BeenThere: xen-devel@lists.xensource.com X-Mailman-Version: 2.1.5 Precedence: list List-Id: Xen developer discussion <xen-devel.lists.xensource.com> List-Unsubscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe> List-Post: <mailto:xen-devel@lists.xensource.com> List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help> List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=subscribe> Sender: xen-devel-bounces@lists.xensource.com Errors-To: xen-devel-bounces@lists.xensource.com On Wed, Sep 21, 2011 at 06:59:57PM -0400, Konrad Rzeszutek Wilk wrote: > On Wed, Sep 21, 2011 at 03:46:31PM -0700, Jeremy Fitzhardinge wrote: > > On 09/21/2011 01:03 PM, Konrad Rzeszutek Wilk wrote: > > >>>> So, there's a meta-point here: we currently 'require' Beta releases to > > >>>> boot as guests on Xen hosts: > > >>>> > > >>>> "The release must boot successfully as a virtual guest in a situation > > >>>> where the virtual host is running a supported Xen implementation" > > >>>> > > >>>> I really don't have much knowledge of Xen and haven't followed this > > >>>> discussion closely, but do any currently-known bugs prevent this? If so, > > >>>> please flag them up so they can be considered as Beta blockers...thanks! > > > I filled Bug 740378 - F16: Can't use keyboard when installing F16-Alpha under Xen (regression) as guest > > > which is pretty descripting what is below. > > > > > > Also adding in Jeremy's workaround in it. > > > > Though I couldn't repro the general problems I was having - I later did > > a clean F14 install with no problems. So I don't really know what's > > going on here; I might try another F16 hvm install to see how it goes. > > > > But there is a bona-fide bug that F16 doesn't include xen-platform-pci > > by default in its initramfs, so it ends up unplugging its emulated > > devices without discovering the PV ones to replace them... > > Can you open a BZ at bugzilla.redhat.com please? > Also should we change the default xen-platform-pci to =y in upstream Linux .config to avoid having problems with every distro ? -- Pasi > It might need to be assigned to the kernel team. > > > > > Besides that, there is also > > > 738085 - Patch to reduce spurious Xen entries in grub menu > > > > > > which has a patch to fix the grub2 menu-thingy.. > > > > I'd noticed that - though at present I haven't managed to get F16 Xen to > > boot in an hvm domain (it hangs when setting up interrupts in the nested > > dom0). > > > > J > > > > _______________________________________________ > > Xen-devel mailing list > > Xen-devel@lists.xensource.com > > http://lists.xensource.com/xen-devel > > _______________________________________________ > Xen-devel mailing list > Xen-devel@lists.xensource.com > http://lists.xensource.com/xen-devel _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel From xen-devel-bounces@lists.xensource.com Thu Sep 22 02:50:18 2011 Return-path: <xen-devel-bounces@lists.xensource.com> Envelope-to: www-data@lists.xensource.com Delivery-date: Thu, 22 Sep 2011 02:50:18 -0700 Received: from localhost ([127.0.0.1] helo=lists.colo.xensource.com) by lists.xensource.com with esmtp (Exim 4.43) id 1R6fv8-0003CF-GC; Thu, 22 Sep 2011 02:50:18 -0700 Received: from mail21.messagelabs.com ([85.158.143.35]) by lists.xensource.com with smtp (Exim 4.43) id 1R6fuI-0002wA-6U for xen-devel@lists.xensource.com; Thu, 22 Sep 2011 02:49:26 -0700 X-Env-Sender: ml-xen-devel@hfp.de X-Msg-Ref: server-2.tower-21.messagelabs.com!1316684961!35051040!1 X-Originating-IP: [88.205.101.6] X-StarScan-Version: 6.4.1; banners=-,-,- X-VirusChecked: Checked Received: (qmail 11680 invoked from network); 22 Sep 2011 09:49:21 -0000 Received: from rootsrv.hfp.de (HELO rootsrv.hfp.de) (88.205.101.6) by server-2.tower-21.messagelabs.com with SMTP; 22 Sep 2011 09:49:21 -0000 Received: from localhost (localhost [127.0.0.1]) by rootsrv.hfp.de (Postfix) with ESMTP id B92221A5611; Thu, 22 Sep 2011 11:49:21 +0200 (CEST) X-Virus-Scanned: amavisd-new/ClamAV at rootsrv.hfp.de Received: from rootsrv.hfp.de ([127.0.0.1]) by localhost (rootsrv.hfp.de [127.0.0.1]) (amavisd-new, port 10026) with ESMTP id XtxLfwz1szuW; Thu, 22 Sep 2011 11:49:21 +0200 (CEST) Received: from [10.0.0.1] (p5DCB76B3.dip.t-dialin.net [93.203.118.179]) by rootsrv.hfp.de (Postfix) with ESMTPA; Thu, 22 Sep 2011 11:49:21 +0200 (CEST) Message-ID: <4E7B04A4.9070601@hfp.de> Date: Thu, 22 Sep 2011 11:49:24 +0200 From: Andreas Kinzler <ml-xen-devel@hfp.de> User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:6.0.2) Gecko/20110902 Thunderbird/6.0.2 MIME-Version: 1.0 To: James Harper <james.harper@bendigoit.com.au> Subject: Re: [Xen-devel] RE: Stability report GPLPV 0.11.0.308 References: <4E64A0DF.2070007@hfp.de> <AEC6C66638C05B468B556EA548C1A77D01E5DB8C@trantor> <4E64D569.5030607@hfp.de> <AEC6C66638C05B468B556EA548C1A77D01E5DBBF@trantor> <4E7728F9.9020208@hfp.de> <AEC6C66638C05B468B556EA548C1A77D01E5E008@trantor> In-Reply-To: <AEC6C66638C05B468B556EA548C1A77D01E5E008@trantor> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: xen-devel@lists.xensource.com X-BeenThere: xen-devel@lists.xensource.com X-Mailman-Version: 2.1.5 Precedence: list List-Id: Xen developer discussion <xen-devel.lists.xensource.com> List-Unsubscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe> List-Post: <mailto:xen-devel@lists.xensource.com> List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help> List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=subscribe> Sender: xen-devel-bounces@lists.xensource.com Errors-To: xen-devel-bounces@lists.xensource.com Hello James, > I haven't tested it well, but the latest should be a bit more stable. > Could you try one of the following from > http://www.meadowcourt.org/private Gives me an HTTP 403. I'd really prefer to fetch it from your mercurial repo since I don't want to use testsigning and use our real certificate instead. Regards Andreas _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel From xen-devel-bounces@lists.xensource.com Thu Sep 22 03:04:38 2011 Return-path: <xen-devel-bounces@lists.xensource.com> Envelope-to: www-data@lists.xensource.com Delivery-date: Thu, 22 Sep 2011 03:04:38 -0700 Received: from localhost ([127.0.0.1] helo=lists.colo.xensource.com) by lists.xensource.com with esmtp (Exim 4.43) id 1R6g8y-0003mS-5U; Thu, 22 Sep 2011 03:04:37 -0700 Received: from mail182.messagelabs.com ([85.158.139.83]) by lists.xensource.com with esmtp (Exim 4.43) id 1R6g5D-0003XP-PD for xen-devel@lists.xensource.com; Thu, 22 Sep 2011 03:01:28 -0700 X-Env-Sender: evil.dani@gmail.com X-Msg-Ref: server-12.tower-182.messagelabs.com!1316685639!19148486!1 X-Originating-IP: [209.85.161.43] X-StarScan-Version: 6.4.1; banners=-,-,- X-VirusChecked: Checked Received: (qmail 13135 invoked from network); 22 Sep 2011 10:00:39 -0000 Received: from mail-fx0-f43.google.com (HELO mail-fx0-f43.google.com) (209.85.161.43) by server-12.tower-182.messagelabs.com with RC4-SHA encrypted SMTP; 22 Sep 2011 10:00:39 -0000 Received: by fxh19 with SMTP id 19so3257818fxh.30 for <xen-devel@lists.xensource.com>; Thu, 22 Sep 2011 03:00:39 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; bh=XIgzWJDKZauhC0e2Mxowr9PIpx5FOeZzCMwJxxFW/iY=; b=Zq1dzI2qK20l8tDbK3kQ8Y1TO6YjaX5xOfkYMUFCEy2dAVSPfnP4aCuRgAbShsJW2V RoLivcKSdKfxcYqVcyV1WAsv6+tjaLIfmbyJ/LePmy2J/w7lGrh5xab6Q/9n9PYxzsPH PypsonitFKhl58Yp8fmb17TC6tkxumofP6RjE= MIME-Version: 1.0 Received: by 10.223.10.14 with SMTP id n14mr2787178fan.37.1316685639166; Thu, 22 Sep 2011 03:00:39 -0700 (PDT) Received: by 10.223.97.9 with HTTP; Thu, 22 Sep 2011 03:00:39 -0700 (PDT) In-Reply-To: <1316678423.23371.15.camel@zakaz.uk.xensource.com> References: <CAP2B85_rPbB=hZpKJYSPgC59jU=YG6deD4ZkWMmXwtMV4un1mg@mail.gmail.com> <CA9D757C.2119E%keir.xen@gmail.com> <CAP2B85-e64NKts_iC21Bh0OL3X3nUh4jLriYfE2+stHkPfMFWg@mail.gmail.com> <4E793DC4.7080808@goop.org> <CAP2B859vtSK_tC0J6HWB_m6hjHKM18vZ7Qh6ABFejCiEfxs+6g@mail.gmail.com> <CAP2B85-_kMLh0C6NCBpRbUchNYw96drLVJu33EdKV25jJ=p+4g@mail.gmail.com> <1316673048.27431.7.camel@dagon.hellion.org.uk> <CAP2B858_Km8GA0ncNgKyk7u=V3uC9zn5ozwQoirescztW5EKXg@mail.gmail.com> <1316678423.23371.15.camel@zakaz.uk.xensource.com> Date: Thu, 22 Sep 2011 19:00:39 +0900 Message-ID: <CAP2B85-HZuByDfzZDGGopLTEXibVdg4csAgz+s5CSShPb9XhHA@mail.gmail.com> Subject: Re: [Xen-devel] Sched_op hypercall small questions From: Daniel Castro <evil.dani@gmail.com> To: Ian Campbell <Ian.Campbell@eu.citrix.com> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com> X-BeenThere: xen-devel@lists.xensource.com X-Mailman-Version: 2.1.5 Precedence: list List-Id: Xen developer discussion <xen-devel.lists.xensource.com> List-Unsubscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe> List-Post: <mailto:xen-devel@lists.xensource.com> List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help> List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=subscribe> Sender: xen-devel-bounces@lists.xensource.com Errors-To: xen-devel-bounces@lists.xensource.com On Thu, Sep 22, 2011 at 5:00 PM, Ian Campbell <Ian.Campbell@eu.citrix.com> wrote: > On Thu, 2011-09-22 at 08:43 +0100, Daniel Castro wrote: >> On Thu, Sep 22, 2011 at 3:30 PM, Ian Campbell <Ian.Campbell@citrix.com> = wrote: > >> Thanks for the answer Ian, one question: If I do not manually change >> the mask bit, then after writing to the ring and the response arrives >> how can I be sure that xenstore is delivering an event? > > Add some printfs in the daemon? > >> I am suspecting that xenstore does not use event notification for simple >> read and write operations. Could I be right? > > I don't think so, how else would it notify the client end that it should > look into the ring? > > In the daemon the do_read() function calls the same common send_reply() > as most (all?) other commands. send_reply queues a message on > conn->out_list. Later on write_messages() dequeues it and calls the > connections write method, which is writechn() in this case (the other > case is a local socket connection which uses writefd but isn't relevant > here). writechn() has an xc_evtchn_notify() at the end. You are right as usual, using trace in the deamon in function writechn I ge= t: DEBUG notify dom 1 on port 42 Form /usr/lib/xen/bin/lsevtchn I get: 42: VCPU 0: Interdomain (Connected) - Remote Domain 1, Port 2 And from the guest I have: Event is interdomain to dom 0 port 42 So they are interconected and the xenstore deamon is delivering the event. I am going to check the ring waiting function there has to be something I am missing.... thanks, Daniel > > Ian. > >> >> > >> >> >> >> Thanks >> >> > >> >> >>>> 3. If I issue the hypercall and the event never comes is it poss= ible >> >> >>>> to to yield the CPU for ever? >> >> >>> Yes, if you do not specify a timeout. >> >> >> Keir thanks for the answer. >> >> >> >> >> >> I am trying to read from xenstore, so I have the following: >> >> >> I write on my xenstore ring the query I want, then, >> >> >> hypercall_event_channel_op(EVTCHNOP_send ... >> >> >> If I read the ring inmediatly the answer is not ready so I issue a >> >> >> hypercall_sched_op(SCHEDOP_poll, &poll); >> >> >> But while I am entering the yield state the answer comes, so the e= vent >> >> >> is never seen because it has already been delivered. >> >> > >> >> > It generally only makes sense to poll on masked events. >> >> > >> >> >> >> >> >> If I use some way to wait (just for very brief instant) after the >> >> >> event_channel_op send then, when I check the ring the answer is th= ere; >> >> >> And I do not need to yield the CPU. >> >> >> >> >> >> Should I issue the wait after the send, rather than when I am abou= t to >> >> >> read the answer? >> >> > >> >> > What environment is this in? >> >> > >> >> > =A0 =A0J >> >> > >> >> >> >> >> >> >> >> -- >> >> +-=3D=3D=3D=3D=3D---------------------------+ >> >> | +---------------------------------+ | This space intentionally blan= k >> >> for notetaking. >> >> | | =A0 | Daniel Castro, =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0| >> >> | | =A0 | Consultant/Programmer.| >> >> | | =A0 | U Andes =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 | >> >> +-------------------------------------+ >> >> >> >> >> >> >> > >> > >> > >> >> >> > > > --=20 +-=3D=3D=3D=3D=3D---------------------------+ | +---------------------------------+ | This space intentionally blank for notetaking. | |=A0=A0 | Daniel Castro,=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 | | |=A0=A0 | Consultant/Programmer.| | |=A0=A0 | U Andes=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0=A0 | +-------------------------------------+ _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel From xen-devel-bounces@lists.xensource.com Thu Sep 22 03:06:30 2011 Return-path: <xen-devel-bounces@lists.xensource.com> Envelope-to: www-data@lists.xensource.com Delivery-date: Thu, 22 Sep 2011 03:06:30 -0700 Received: from localhost ([127.0.0.1] helo=lists.colo.xensource.com) by lists.xensource.com with esmtp (Exim 4.43) id 1R6gAo-0004A2-Ce; Thu, 22 Sep 2011 03:06:30 -0700 Received: from mail216.messagelabs.com ([85.158.143.99]) by lists.xensource.com with esmtp (Exim 4.43) id 1R6g7d-0003eE-GK for xen-devel@lists.xensource.com; Thu, 22 Sep 2011 03:03:29 -0700 X-Env-Sender: nupurghatnekar@gmail.com X-Msg-Ref: server-8.tower-216.messagelabs.com!1316685666!17605208!1 X-Originating-IP: [74.125.82.171] X-StarScan-Version: 6.4.1; banners=-,-,- X-VirusChecked: Checked Received: (qmail 23054 invoked from network); 22 Sep 2011 10:01:06 -0000 Received: from mail-wy0-f171.google.com (HELO mail-wy0-f171.google.com) (74.125.82.171) by server-8.tower-216.messagelabs.com with RC4-SHA encrypted SMTP; 22 Sep 2011 10:01:06 -0000 Received: by wyh13 with SMTP id 13so1324082wyh.30 for <xen-devel@lists.xensource.com>; Thu, 22 Sep 2011 03:01:04 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:date:message-id:subject:from:to:content-type; bh=jFEh0lkai8dYGARK//ctav+dZuF/AuYY+l6OHzF0Gow=; b=aeO5Tt0ebgoVqacXrdf72vK1sPoAmEviqal8Sh0ctgo6GT+2mCgquq9+IbTJdGlCZK Dd08T/GEn1W9B11OThcFjRNsXvfV3MGr+y/7DpyeN/9QS4+5p9U0gKf/8IiDE6Kkmuut cbjmkaPp1Qyd9EJzV2qlEZ4GM2Za5ZwVBUQ8o= MIME-Version: 1.0 Received: by 10.216.171.72 with SMTP id q50mr1937612wel.76.1316685664498; Thu, 22 Sep 2011 03:01:04 -0700 (PDT) Received: by 10.216.70.202 with HTTP; Thu, 22 Sep 2011 03:01:04 -0700 (PDT) Date: Thu, 22 Sep 2011 15:31:04 +0530 Message-ID: <CAO8_4Vq7Q145GWwW8jG0oOs6TugQvP764njJ3JLtrAZ766tNUw@mail.gmail.com> From: Nupur Ghatnekar <nupurghatnekar@gmail.com> To: xen-devel@lists.xensource.com Subject: [Xen-devel] Virtual File System in XEN X-BeenThere: xen-devel@lists.xensource.com X-Mailman-Version: 2.1.5 Precedence: list List-Id: Xen developer discussion <xen-devel.lists.xensource.com> List-Unsubscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe> List-Post: <mailto:xen-devel@lists.xensource.com> List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help> List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=subscribe> Content-Type: multipart/mixed; boundary="===============2137046369==" Sender: xen-devel-bounces@lists.xensource.com Errors-To: xen-devel-bounces@lists.xensource.com --===============2137046369== Content-Type: multipart/alternative; boundary=0016367b6a1e5034a904ad84c54b --0016367b6a1e5034a904ad84c54b Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable We are an undergraduate group of students. For our final year project, we are planning to implement a Virtual File System in XEN. In a paravirtualised environment, an Userspace Application makes a system call for access to a file, the domU=E2=80=99s kernel traps it and converts = it to an appropriate block number. Now this block number is on the Virtual Hard Disk= . The blktap mechanism is used for block I/O. It involves using XenBus and a daemon in user space of Dom0 which with help of libaio fires the request on Dom0 File System. The current scenario involves multiple translations for getting the actual physical address. Our project intends to reduce the number of translations required during th= e fetching or satisfying of the request. The DomU kernel doesn=E2=80=99t convert the FS request to block and passes = on this to dom0 using a client-server mechanism. We intend to implement it using the 9P protocol.\ 1) The domU kernel=E2=80=99s filesystem component will be a client and the = dom0 will be the server. 2) The domU=E2=80=99s kernel will send the file request to dom0 using the 9= P protocol rather than converting it to appropriate block no. 3) The server in dom0 will authenticate the request, process it and send th= e appropriate replies. By having a virtual file system, the hypervisor will have a better understanding of what the guest domains are doing and hence this can help i= n taking intelligent decisions and thereby have better results in caching, de-duplication and snapshots. Any suggestions for our proposed project would be appreciated. --=20 Nupur Ghatnekar --0016367b6a1e5034a904ad84c54b Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable <p class=3D"MsoNormal" style=3D"text-align:justify"><font class=3D"Apple-st= yle-span" face=3D"'Times New Roman', serif" size=3D"3"><span class= =3D"Apple-style-span" style=3D"line-height: 18px;">We are an undergraduate = group of students. For our final year project, we are planning to implement= a Virtual File System in XEN.</span></font></p> <p class=3D"MsoNormal" style=3D"text-align:justify"><font class=3D"Apple-st= yle-span" face=3D"'Times New Roman', serif" size=3D"3"><span class= =3D"Apple-style-span" style=3D"line-height: 18px;"><br></span></font></p><p= class=3D"MsoNormal" style=3D"text-align:justify"> <span style=3D"font-size:12.0pt; line-height:115%;font-family:"Times New Roman","serif""= >In a paravirtualised environment, an Userspace Application makes a system call for access to a f= ile, the domU=E2=80=99s kernel traps it and converts it to an appropriate block = number. Now this block number is on the Virtual Hard Disk. The blktap mechanism is used= for block I/O. It involves using XenBus and a daemon in user space of Dom0 whic= h with help of libaio fires the request on Dom0 File System. The current scen= ario involves multiple translations for getting the actual physical address.</sp= an></p><p class=3D"MsoNormal" style=3D"text-align:justify"><span style=3D"f= ont-size:12.0pt; line-height:115%;font-family:"Times New Roman","serif""= ><br></span></p> <p class=3D"MsoNormal" style=3D"text-align:justify"><span style=3D"font-siz= e:12.0pt; line-height:115%;font-family:"Times New Roman","serif""= >Our project intends to reduce the number of translations required during the fetching or satisfyin= g of the request.</span></p><p class=3D"MsoNormal" style=3D"text-align:justify">= <span style=3D"font-size:12.0pt; line-height:115%;font-family:"Times New Roman","serif""= >The DomU kernel doesn=E2=80=99t convert the FS request to block and passes on this to dom0 using a client-server mechanism.=C2=A0</span></p><p class= =3D"MsoNormal" style=3D"text-align:justify"><span style=3D"font-size:12.0pt= ; line-height:115%;font-family:"Times New Roman","serif""= ><br></span></p><p class=3D"MsoNormal" style=3D"text-align:justify"><span s= tyle=3D"font-size:12.0pt; line-height:115%;font-family:"Times New Roman","serif""= >We intend to implement it using the 9P protocol.\</span></p><p class=3D"MsoNormal" style=3D"text-alig= n:justify"><span style=3D"font-size:12.0pt; line-height:115%;font-family:"Times New Roman","serif""= >1) The domU kernel=E2=80=99s filesystem component will be a client and the dom0 will be the server.</span></p><p class=3D"MsoNormal" style=3D"= text-align:justify"><span style=3D"font-size:12.0pt; line-height:115%;font-family:"Times New Roman","serif""= >2) The domU=E2=80=99s kernel will send the file request to dom0 using the 9P protocol rather than converting it to appropriate bloc= k no.</span></p><p class=3D"MsoNormal" style=3D"text-align:justify"><span sty= le=3D"font-size:12.0pt; line-height:115%;font-family:"Times New Roman","serif""= >3) The server in dom0 will authenticate the request, process it and send t= he appropriate replies.=C2=A0</span></p><p class=3D"MsoNormal" style=3D"text-a= lign:justify"><span style=3D"font-size:12.0pt; line-height:115%;font-family:"Times New Roman","serif""= ><br></span></p><p class=3D"MsoNormal" style=3D"text-align:justify"><span s= tyle=3D"font-size:12.0pt; line-height:115%;font-family:"Times New Roman","serif""= >By having a virtual file system, the hypervisor will have a better understanding of what the guest domains are doing and hence this c= an help in taking intelligent decisions and thereby have better results in caching, de-duplication and snapshots.</span></p><div><br></div>Any suggest= ions for our proposed project would be appreciated.<br>-- <br><br>Nupur Gha= tnekar<br> --0016367b6a1e5034a904ad84c54b-- --===============2137046369== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel --===============2137046369==-- From xen-devel-bounces@lists.xensource.com Thu Sep 22 03:11:29 2011 Return-path: <xen-devel-bounces@lists.xensource.com> Envelope-to: www-data@lists.xensource.com Delivery-date: Thu, 22 Sep 2011 03:11:29 -0700 Received: from localhost ([127.0.0.1] helo=lists.colo.xensource.com) by lists.xensource.com with esmtp (Exim 4.43) id 1R6gFd-0004ae-0I; Thu, 22 Sep 2011 03:11:29 -0700 Received: from mail216.messagelabs.com ([85.158.143.99]) by lists.xensource.com with esmtp (Exim 4.43) id 1R6gF1-0004OH-BH for xen-devel@lists.xensource.com; Thu, 22 Sep 2011 03:10:51 -0700 X-Env-Sender: james.harper@bendigoit.com.au X-Msg-Ref: server-12.tower-216.messagelabs.com!1316686244!13457555!1 X-Originating-IP: [203.16.207.99] X-StarScan-Version: 6.4.1; banners=-,-,- X-VirusChecked: Checked Received: (qmail 27154 invoked from network); 22 Sep 2011 10:10:48 -0000 Received: from smtp2.bendigoit.com.au (HELO smtp2.bendigoit.com.au) (203.16.207.99) by server-12.tower-216.messagelabs.com with AES256-SHA encrypted SMTP; 22 Sep 2011 10:10:48 -0000 Received: from trantor.int.sbss.com.au ([192.168.200.206] helo=mail.bendigoit.com.au) by smtp2.bendigoit.com.au with esmtp (Exim 4.72) (envelope-from <james.harper@bendigoit.com.au>) id 1R6gEs-0005zb-Mm; Thu, 22 Sep 2011 20:10:42 +1000 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable X-MimeOLE: Produced By Microsoft Exchange V6.5 Subject: RE: [Xen-devel] RE: Stability report GPLPV 0.11.0.308 Date: Thu, 22 Sep 2011 20:10:40 +1000 Message-ID: <AEC6C66638C05B468B556EA548C1A77D01E5E072@trantor> In-Reply-To: <4E7B04A4.9070601@hfp.de> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Xen-devel] RE: Stability report GPLPV 0.11.0.308 Thread-Index: Acx5DPBKgSQQz+BHQWGxMHKmMc22HAAAtIvw References: <4E64A0DF.2070007@hfp.de> <AEC6C66638C05B468B556EA548C1A77D01E5DB8C@trantor> <4E64D569.5030607@hfp.de> <AEC6C66638C05B468B556EA548C1A77D01E5DBBF@trantor> <4E7728F9.9020208@hfp.de> <AEC6C66638C05B468B556EA548C1A77D01E5E008@trantor> <4E7B04A4.9070601@hfp.de> From: "James Harper" <james.harper@bendigoit.com.au> To: "Andreas Kinzler" <ml-xen-devel@hfp.de> X-Really-From-Bendigo-IT: magichashvalue Cc: xen-devel@lists.xensource.com X-BeenThere: xen-devel@lists.xensource.com X-Mailman-Version: 2.1.5 Precedence: list List-Id: Xen developer discussion <xen-devel.lists.xensource.com> List-Unsubscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe> List-Post: <mailto:xen-devel@lists.xensource.com> List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help> List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=subscribe> Sender: xen-devel-bounces@lists.xensource.com Errors-To: xen-devel-bounces@lists.xensource.com > Hello James, >=20 > > I haven't tested it well, but the latest should be a bit more stable. > > Could you try one of the following from > > http://www.meadowcourt.org/private >=20 > Gives me an HTTP 403. You need to append the filename to the url - no browsing on that directory. > I'd really prefer to fetch it from your mercurial repo > since I don't want to use testsigning and use our real certificate instead. My laptop broke and I haven't gotten mercurial set up yet. I'll push it as soon as I can. James _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel From xen-devel-bounces@lists.xensource.com Thu Sep 22 03:13:29 2011 Return-path: <xen-devel-bounces@lists.xensource.com> Envelope-to: www-data@lists.xensource.com Delivery-date: Thu, 22 Sep 2011 03:13:29 -0700 Received: from localhost ([127.0.0.1] helo=lists.colo.xensource.com) by lists.xensource.com with esmtp (Exim 4.43) id 1R6gHZ-0004yd-Jq; Thu, 22 Sep 2011 03:13:29 -0700 Received: from mail216.messagelabs.com ([85.158.143.99]) by lists.xensource.com with esmtp (Exim 4.43) id 1R6gH2-0004mA-KG for xen-devel@lists.xensource.com; Thu, 22 Sep 2011 03:12:58 -0700 X-Env-Sender: dunlapg@gmail.com X-Msg-Ref: server-15.tower-216.messagelabs.com!1316686366!18695935!1 X-Originating-IP: [74.125.82.171] X-StarScan-Version: 6.4.1; banners=-,-,- X-VirusChecked: Checked Received: (qmail 21313 invoked from network); 22 Sep 2011 10:12:46 -0000 Received: from mail-wy0-f171.google.com (HELO mail-wy0-f171.google.com) (74.125.82.171) by server-15.tower-216.messagelabs.com with RC4-SHA encrypted SMTP; 22 Sep 2011 10:12:46 -0000 Received: by wyh13 with SMTP id 13so1336983wyh.30 for <xen-devel@lists.xensource.com>; Thu, 22 Sep 2011 03:12:45 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=kNDGYPXO1NMK8FyMrNh7Ji/71++wBgjo/BwAau0KhxQ=; b=xBg3MU1Ql2eVVyMFu/cgVsgmg35Qi/gyITrat+M5HkqrnDPIb5guawlx98K2Bl2tYv M5RjIJhZvjJAKBJD9R0aIv6NPyNIfT+HpAg2XOtgbYc5IODSgRrzsp0MEm/4KxMAlMfP HDTgifgeA6VyTcIBycJJ1br7LXxn6/FLBOuxA= MIME-Version: 1.0 Received: by 10.216.137.94 with SMTP id x72mr2308258wei.9.1316686365809; Thu, 22 Sep 2011 03:12:45 -0700 (PDT) Received: by 10.216.176.81 with HTTP; Thu, 22 Sep 2011 03:12:45 -0700 (PDT) In-Reply-To: <4E78D0E00200007800056D8D@nat28.tlf.novell.com> References: <4E78D0E00200007800056D8D@nat28.tlf.novell.com> Date: Thu, 22 Sep 2011 11:12:45 +0100 X-Google-Sender-Auth: 2heT5hmT5pH2f6FEhhHuNFjjELI Message-ID: <CAFLBxZZXgu3VXnh_XNqnks3Y2gZ9ev9qz_3DAk9upvsv=vTk8w@mail.gmail.com> Subject: Re: [Xen-devel] [PATCH 3/4] pass struct irq_desc * to all other IRQ accessors From: George Dunlap <dunlapg@umich.edu> To: Jan Beulich <JBeulich@suse.com> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com> X-BeenThere: xen-devel@lists.xensource.com X-Mailman-Version: 2.1.5 Precedence: list List-Id: Xen developer discussion <xen-devel.lists.xensource.com> List-Unsubscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe> List-Post: <mailto:xen-devel@lists.xensource.com> List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help> List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=subscribe> Sender: xen-devel-bounces@lists.xensource.com Errors-To: xen-devel-bounces@lists.xensource.com On Tue, Sep 20, 2011 at 4:44 PM, Jan Beulich <JBeulich@suse.com> wrote: > @@ -2071,7 +2051,7 @@ static void __init check_timer(void) > =A0 =A0 init_8259A(1); > =A0 =A0 /* XEN: Ripped out the legacy missed-tick logic, so below is not = needed. */ > =A0 =A0 /*timer_ack =3D 1;*/ > - =A0 =A0/*enable_8259A_irq(0);*/ > + =A0 =A0/*enable_8259A_irq(irq_to_desc(0));*/ > > =A0 =A0 pin1 =A0=3D find_isa_irq_pin(0, mp_INT); > =A0 =A0 apic1 =3D find_isa_irq_apic(0, mp_INT); Well done. :-) -George _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel From xen-devel-bounces@lists.xensource.com Thu Sep 22 03:27:33 2011 Return-path: <xen-devel-bounces@lists.xensource.com> Envelope-to: www-data@lists.xensource.com Delivery-date: Thu, 22 Sep 2011 03:27:33 -0700 Received: from localhost ([127.0.0.1] helo=lists.colo.xensource.com) by lists.xensource.com with esmtp (Exim 4.43) id 1R6gVB-0005ZY-Cv; Thu, 22 Sep 2011 03:27:33 -0700 Received: from mail174.messagelabs.com ([85.158.138.51]) by lists.xensource.com with esmtp (Exim 4.43) id 1R6gUP-0005NB-LN for xen-devel@lists.xensource.com; Thu, 22 Sep 2011 03:26:46 -0700 X-Env-Sender: konrad@oracle.com X-Msg-Ref: server-3.tower-174.messagelabs.com!1316687201!26283106!1 X-Originating-IP: [141.146.126.227] X-StarScan-Version: 6.4.1; banners=-,-,- X-VirusChecked: Checked Received: (qmail 18262 invoked from network); 22 Sep 2011 10:26:42 -0000 Received: from acsinet15.oracle.com (HELO acsinet15.oracle.com) (141.146.126.227) by server-3.tower-174.messagelabs.com with DHE-RSA-AES256-SHA encrypted SMTP; 22 Sep 2011 10:26:42 -0000 Received: from rtcsinet21.oracle.com (rtcsinet21.oracle.com [66.248.204.29]) by acsinet15.oracle.com (Switch-3.4.4/Switch-3.4.4) with ESMTP id p8MAQagI007740 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Thu, 22 Sep 2011 10:26:38 GMT Received: from acsmt356.oracle.com (acsmt356.oracle.com [141.146.40.156]) by rtcsinet21.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id p8MAQZET005037 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 22 Sep 2011 10:26:35 GMT Received: from abhmt120.oracle.com (abhmt120.oracle.com [141.146.116.72]) by acsmt356.oracle.com (8.12.11.20060308/8.12.11) with ESMTP id p8MAQT43023010; Thu, 22 Sep 2011 05:26:29 -0500 Received: from oracle.com (/209.6.55.207) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Thu, 22 Sep 2011 03:26:29 -0700 Received: by oracle.com (Postfix, from userid 1000) id B4834155E; Thu, 22 Sep 2011 06:26:36 -0400 (EDT) Date: Thu, 22 Sep 2011 06:26:36 -0400 From: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com> To: Nupur Ghatnekar <nupurghatnekar@gmail.com> Subject: Re: [Xen-devel] Virtual File System in XEN Message-ID: <20110922102636.GA28842@phenom.oracle.com> References: <CAO8_4Vq7Q145GWwW8jG0oOs6TugQvP764njJ3JLtrAZ766tNUw@mail.gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline In-Reply-To: <CAO8_4Vq7Q145GWwW8jG0oOs6TugQvP764njJ3JLtrAZ766tNUw@mail.gmail.com> User-Agent: Mutt/1.5.21 (2010-09-15) Content-Transfer-Encoding: quoted-printable X-Source-IP: rtcsinet21.oracle.com [66.248.204.29] X-CT-RefId: str=0001.0A090205.4E7B0D5F.0092,ss=1,re=0.000,fgs=0 Cc: xen-devel@lists.xensource.com X-BeenThere: xen-devel@lists.xensource.com X-Mailman-Version: 2.1.5 Precedence: list List-Id: Xen developer discussion <xen-devel.lists.xensource.com> List-Unsubscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe> List-Post: <mailto:xen-devel@lists.xensource.com> List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help> List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=subscribe> Sender: xen-devel-bounces@lists.xensource.com Errors-To: xen-devel-bounces@lists.xensource.com On Thu, Sep 22, 2011 at 03:31:04PM +0530, Nupur Ghatnekar wrote: > We are an undergraduate group of students. For our final year project, = we > are planning to implement a Virtual File System in XEN. >=20 >=20 > In a paravirtualised environment, an Userspace Application makes a syst= em > call for access to a file, the domU=E2=80=99s kernel traps it and conve= rts it to an > appropriate block number. Now this block number is on the Virtual Hard = Disk. > The blktap mechanism is used for block I/O. It involves using XenBus an= d a The blktap is deprecated for the upstream kernel - so it won't help you m= uch. You might be better of using the QEMU backends, like qcow or such. > daemon in user space of Dom0 which with help of libaio fires the reques= t on > Dom0 File System. The current scenario involves multiple translations f= or > getting the actual physical address. >=20 >=20 > Our project intends to reduce the number of translations required durin= g the > fetching or satisfying of the request. >=20 > The DomU kernel doesn=E2=80=99t convert the FS request to block and pas= ses on this > to dom0 using a client-server mechanism. >=20 >=20 > We intend to implement it using the 9P protocol.\ >=20 > 1) The domU kernel=E2=80=99s filesystem component will be a client and = the dom0 will > be the server. >=20 > 2) The domU=E2=80=99s kernel will send the file request to dom0 using t= he 9P > protocol rather than converting it to appropriate block no. >=20 > 3) The server in dom0 will authenticate the request, process it and sen= d the > appropriate replies. >=20 >=20 > By having a virtual file system, the hypervisor will have a better > understanding of what the guest domains are doing and hence this can he= lp in > taking intelligent decisions and thereby have better results in caching= , > de-duplication and snapshots. >=20 > Any suggestions for our proposed project would be appreciated. > --=20 >=20 > Nupur Ghatnekar > _______________________________________________ > Xen-devel mailing list > Xen-devel@lists.xensource.com > http://lists.xensource.com/xen-devel _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel From xen-devel-bounces@lists.xensource.com Thu Sep 22 03:31:29 2011 Return-path: <xen-devel-bounces@lists.xensource.com> Envelope-to: www-data@lists.xensource.com Delivery-date: Thu, 22 Sep 2011 03:31:29 -0700 Received: from localhost ([127.0.0.1] helo=lists.colo.xensource.com) by lists.xensource.com with esmtp (Exim 4.43) id 1R6gYz-00064Z-AW; Thu, 22 Sep 2011 03:31:29 -0700 Received: from mail182.messagelabs.com ([85.158.139.83]) by lists.xensource.com with esmtp (Exim 4.43) id 1R6gYV-0005sI-Jw for xen-devel@lists.xensource.com; Thu, 22 Sep 2011 03:30:59 -0700 X-Env-Sender: Stefano.Stabellini@eu.citrix.com X-Msg-Ref: server-10.tower-182.messagelabs.com!1316687456!19292475!1 X-Originating-IP: [62.200.22.115] X-StarScan-Version: 6.4.1; banners=-,-,- X-VirusChecked: Checked Received: (qmail 5856 invoked from network); 22 Sep 2011 10:30:56 -0000 Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115) by server-10.tower-182.messagelabs.com with RC4-SHA encrypted SMTP; 22 Sep 2011 10:30:56 -0000 X-IronPort-AV: E=Sophos;i="4.68,422,1312156800"; d="scan'208";a="8002711" Received: from lonpmailmx01.citrite.net ([10.30.203.162]) by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5; 22 Sep 2011 10:30:50 +0000 Received: from kaball.uk.xensource.com (10.80.2.59) by LONPMAILMX01.citrite.net (10.30.203.162) with Microsoft SMTP Server id 8.3.137.0; Thu, 22 Sep 2011 11:30:50 +0100 Date: Thu, 22 Sep 2011 11:30:47 +0100 From: Stefano Stabellini <stefano.stabellini@eu.citrix.com> X-X-Sender: sstabellini@kaball-desktop To: Stefan Bader <stefan.bader@canonical.com> Subject: Re: [Xen-devel] Re: Still struggling with HVM: tx timeouts on emulated nics In-Reply-To: <4E7A0410.7050405@canonical.com> Message-ID: <alpine.DEB.2.00.1109221128120.8700@kaball-desktop> References: <4E79E08D.1090503@canonical.com> <alpine.DEB.2.00.1109211422180.8700@kaball-desktop> <4E7A0410.7050405@canonical.com> User-Agent: Alpine 2.00 (DEB 1167 2008-08-23) MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>, "Stefano@rly59j.srv.mailcontrol.com" <Stefano@rly59j.srv.mailcontrol.com>, Stefano Stabellini <Stefano.Stabellini@eu.citrix.com> X-BeenThere: xen-devel@lists.xensource.com X-Mailman-Version: 2.1.5 Precedence: list List-Id: Xen developer discussion <xen-devel.lists.xensource.com> List-Unsubscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe> List-Post: <mailto:xen-devel@lists.xensource.com> List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help> List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=subscribe> Sender: xen-devel-bounces@lists.xensource.com Errors-To: xen-devel-bounces@lists.xensource.com On Wed, 21 Sep 2011, Stefan Bader wrote: > On 21.09.2011 15:31, Stefano Stabellini wrote: > > On Wed, 21 Sep 2011, Stefan Bader wrote: > >> This is on 3.0.4 based dom0 and domU with 4.1.1 hypervisor. I tried using the > >> default 8139cp and ne2k_pci emulated nic. The 8139cp one at least comes up and > >> gets configured via dhcp. And initial pings also get routed and done correctly. > >> But slightly higher traffic (like checking for updates) hangs. And after a while > >> there are messages about tx timeouts. > >> The ne2k_pci type nic almost immediately has those issues and never comes up > >> correctly. > >> > >> I am attaching the dmesg of the guest with apic=debug enabled. I am not sure how > >> this should be but both nics get configured with level,low IRQs. Disk emulation > >> seems to be ok but that seem to use IO-APIC-edge. And any other IRQs seem to be > >> at least not level. > > > > > Does the e1000 emulated card work correctly? > > Yes, that one seems to work ok. > > > What happens if you disable interrupt remapping (see patch below)? > > 8139cp seems to work correctly now (much higher irq stats as well) and e1000 > still works. Both then using IOAPIC-fasteoi. > That means there must be another subtle bug in Xen in interrupt remapping that only affects 8139p emulation > >> Another problem came up recently though that may just be me doing the wrong > >> thing. Normally I boot with xen_emul_unplug=unnecessary as I want the emulated > >> devices. xen-blkfront is a module in my case and I thought I once had been able > >> to use that by removing the unplug arg and making the blkfront driver load. But > >> when I recently tried the module loaded but no disks appeared... Again, not sure > >> I just forgot how to do that right or that was different when using a 4.1.0 > >> hypervisor still... > > > > xen_emul_unplug=unnecessary allows the kernel to use PV interfaces on > > older hypervisors that didn't support the unplug protocol and had other > > ways to cope with multiple drivers accessing the same devices. > > You can use xen_emul_unplug=never to prevent any unplug but you won't > > get any PV interfaces. > > Hm, odd. Somehow I thought that I had been using pv interfaces that way when the > interrupts for the emulated ide was broken. > A bit suboptimal atm, because without any option and a kernel compiled with the > platform pci and pv drivers (as modules) booting in HVM mode the kernel decides > that having both is no use and unplugs the emulated devices. Which then leaves > you with ... none. In theory you would have the PV frontend modules in the initrd. On the other hand having both can easily cause data corruptions on your drive. _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel From xen-devel-bounces@lists.xensource.com Thu Sep 22 04:08:31 2011 Return-path: <xen-devel-bounces@lists.xensource.com> Envelope-to: www-data@lists.xensource.com Delivery-date: Thu, 22 Sep 2011 04:08:31 -0700 Received: from localhost ([127.0.0.1] helo=lists.colo.xensource.com) by lists.xensource.com with esmtp (Exim 4.43) id 1R6h8o-0000rD-ME; Thu, 22 Sep 2011 04:08:30 -0700 Received: from mail182.messagelabs.com ([85.158.139.83]) by lists.xensource.com with esmtp (Exim 4.43) id 1R6h6Z-0000E2-Ct for xen-devel@lists.xensource.com; Thu, 22 Sep 2011 04:06:13 -0700 X-Env-Sender: konrad@oracle.com X-Msg-Ref: server-4.tower-182.messagelabs.com!1316689566!19320385!1 X-Originating-IP: [148.87.113.117] X-StarScan-Version: 6.4.1; banners=-,-,- X-VirusChecked: Checked Received: (qmail 27715 invoked from network); 22 Sep 2011 11:06:08 -0000 Received: from rcsinet15.oracle.com (HELO rcsinet15.oracle.com) (148.87.113.117) by server-4.tower-182.messagelabs.com with DHE-RSA-AES256-SHA encrypted SMTP; 22 Sep 2011 11:06:08 -0000 Received: from rtcsinet21.oracle.com (rtcsinet21.oracle.com [66.248.204.29]) by rcsinet15.oracle.com (Switch-3.4.4/Switch-3.4.4) with ESMTP id p8MB64Eo028982 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Thu, 22 Sep 2011 11:06:06 GMT Received: from acsmt356.oracle.com (acsmt356.oracle.com [141.146.40.156]) by rtcsinet21.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id p8MB62sx009106 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 22 Sep 2011 11:06:03 GMT Received: from abhmt115.oracle.com (abhmt115.oracle.com [141.146.116.67]) by acsmt356.oracle.com (8.12.11.20060308/8.12.11) with ESMTP id p8MB5v7t019784; Thu, 22 Sep 2011 06:05:57 -0500 Received: from oracle.com (/209.6.55.207) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Thu, 22 Sep 2011 04:05:57 -0700 Received: by oracle.com (Postfix, from userid 1000) id 29930155E; Thu, 22 Sep 2011 07:06:04 -0400 (EDT) Date: Thu, 22 Sep 2011 07:06:04 -0400 From: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com> To: Shaun Reitan <mailinglists@unix-scripts.com> Subject: Re: [Xen-devel] Re: kernel BUG at mm/swapfile.c:2527! Message-ID: <20110922110603.GA7233@phenom.oracle.com> References: <j4thp9$j7d$1@dough.gmane.org> <j4tl2j$cm2$1@dough.gmane.org> <20110916082456.GA884@phenom.oracle.com> <4E7817A4.6070908@unix-scripts.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <4E7817A4.6070908@unix-scripts.com> User-Agent: Mutt/1.5.21 (2010-09-15) X-Source-IP: rtcsinet21.oracle.com [66.248.204.29] X-CT-RefId: str=0001.0A090201.4E7B169E.00F9,ss=1,re=0.000,fgs=0 Cc: xen-devel@lists.xensource.com X-BeenThere: xen-devel@lists.xensource.com X-Mailman-Version: 2.1.5 Precedence: list List-Id: Xen developer discussion <xen-devel.lists.xensource.com> List-Unsubscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe> List-Post: <mailto:xen-devel@lists.xensource.com> List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help> List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=subscribe> Sender: xen-devel-bounces@lists.xensource.com Errors-To: xen-devel-bounces@lists.xensource.com On Mon, Sep 19, 2011 at 09:33:40PM -0700, Shaun Reitan wrote: > On 9/16/2011 1:24 AM, Konrad Rzeszutek Wilk wrote: > >How do I reproduce it? Is the PCI compliance easily available? Is > >there any chance we can get access to the physical box to figure > >out what is happening? > > Konrad, > > did you get my email with the server I setup for you and logins? Yup. Just came back from a conference so getting back to the groove. > > -- > Shaun > > > _______________________________________________ > Xen-devel mailing list > Xen-devel@lists.xensource.com > http://lists.xensource.com/xen-devel _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel From xen-devel-bounces@lists.xensource.com Thu Sep 22 04:10:00 2011 Return-path: <xen-devel-bounces@lists.xensource.com> Envelope-to: www-data@lists.xensource.com Delivery-date: Thu, 22 Sep 2011 04:10:00 -0700 Received: from localhost ([127.0.0.1] helo=lists.colo.xensource.com) by lists.xensource.com with esmtp (Exim 4.43) id 1R6hAF-0001EH-WB; Thu, 22 Sep 2011 04:10:00 -0700 Received: from mail21.messagelabs.com ([85.158.143.35]) by lists.xensource.com with esmtp (Exim 4.43) id 1R6h7Q-0000Si-3L for xen-devel@lists.xensource.com; Thu, 22 Sep 2011 04:07:05 -0700 X-Env-Sender: Stefano.Stabellini@eu.citrix.com X-Msg-Ref: server-15.tower-21.messagelabs.com!1316689622!51549387!1 X-Originating-IP: [62.200.22.115] X-StarScan-Version: 6.4.1; banners=-,-,- X-VirusChecked: Checked Received: (qmail 2788 invoked from network); 22 Sep 2011 11:07:02 -0000 Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115) by server-15.tower-21.messagelabs.com with RC4-SHA encrypted SMTP; 22 Sep 2011 11:07:02 -0000 X-IronPort-AV: E=Sophos;i="4.68,422,1312156800"; d="scan'208";a="8003571" Received: from lonpmailmx01.citrite.net ([10.30.203.162]) by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5; 22 Sep 2011 11:07:01 +0000 Received: from kaball.uk.xensource.com (10.80.2.59) by LONPMAILMX01.citrite.net (10.30.203.162) with Microsoft SMTP Server id 8.3.137.0; Thu, 22 Sep 2011 12:07:01 +0100 Date: Thu, 22 Sep 2011 12:06:58 +0100 From: Stefano Stabellini <stefano.stabellini@eu.citrix.com> X-X-Sender: sstabellini@kaball-desktop To: Jeremy Fitzhardinge <jeremy@goop.org> Subject: Re: [Xen-devel] Re: [PATCH 0/6] xen: don't call vmalloc_sync_all() when mapping foreign pages In-Reply-To: <4E7A3394.3090806@goop.org> Message-ID: <alpine.DEB.2.00.1109221131390.8700@kaball-desktop> References: <1316090411-22608-1-git-send-email-david.vrabel@citrix.com> <4E727017.4030001@goop.org> <alpine.DEB.2.00.1109211124050.8700@kaball-desktop> <4E7A3394.3090806@goop.org> User-Agent: Alpine 2.00 (DEB 1167 2008-08-23) MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>, Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>, Stefano Stabellini <Stefano.Stabellini@eu.citrix.com>, "linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>, David Vrabel <david.vrabel@citrix.com>, Andrew Morton <akpm@linux-foundation.org> X-BeenThere: xen-devel@lists.xensource.com X-Mailman-Version: 2.1.5 Precedence: list List-Id: Xen developer discussion <xen-devel.lists.xensource.com> List-Unsubscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe> List-Post: <mailto:xen-devel@lists.xensource.com> List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help> List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=subscribe> Sender: xen-devel-bounces@lists.xensource.com Errors-To: xen-devel-bounces@lists.xensource.com On Wed, 21 Sep 2011, Jeremy Fitzhardinge wrote: > On 09/21/2011 03:42 AM, Stefano Stabellini wrote: > > On Thu, 15 Sep 2011, Jeremy Fitzhardinge wrote: > >> This series is relying on regular ram mappings are already synced to all > >> tasks, but I'm not sure that's necessarily guaranteed (for example, if > >> you hotplug new memory into the domain, the new pages won't be mapped > >> into every mm unless they're synced). > > the series is using GFP_KERNEL, so this problem shouldn't occur, right? > > What properties do you think GFP_KERNEL guarantees? That the memory is below 4G and always mapped in the kernel 1:1 region. Regarding memory hotplug it looks like that x86_32 is mapping new memory ZONE_HIGHMEM, therefore avoiding any problems with GFP_KERNEL allocations. On the other hand x86_64 is mapping the memory ZONE_NORMAL and calling init_memory_mapping on the new range right away. AFAICT changes to the 1:1 mapping in init_mm are automatically synced across all mm's because the pgd is shared? _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel From xen-devel-bounces@lists.xensource.com Thu Sep 22 04:24:22 2011 Return-path: <xen-devel-bounces@lists.xensource.com> Envelope-to: www-data@lists.xensource.com Delivery-date: Thu, 22 Sep 2011 04:24:22 -0700 Received: from localhost ([127.0.0.1] helo=lists.colo.xensource.com) by lists.xensource.com with esmtp (Exim 4.43) id 1R6hOA-0001rJ-M4; Thu, 22 Sep 2011 04:24:22 -0700 Received: from mail182.messagelabs.com ([85.158.139.83]) by lists.xensource.com with esmtp (Exim 4.43) id 1R6hNQ-0001f4-Ou for xen-devel@lists.xensource.com; Thu, 22 Sep 2011 04:23:37 -0700 X-Env-Sender: Stefano.Stabellini@eu.citrix.com X-Msg-Ref: server-12.tower-182.messagelabs.com!1316690613!19162291!1 X-Originating-IP: [62.200.22.115] X-StarScan-Version: 6.4.1; banners=-,-,- X-VirusChecked: Checked Received: (qmail 21726 invoked from network); 22 Sep 2011 11:23:33 -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; 22 Sep 2011 11:23:33 -0000 X-IronPort-AV: E=Sophos;i="4.68,422,1312156800"; d="scan'208";a="8003986" Received: from lonpmailmx01.citrite.net ([10.30.203.162]) by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5; 22 Sep 2011 11:23:33 +0000 Received: from kaball.uk.xensource.com (10.80.2.59) by LONPMAILMX01.citrite.net (10.30.203.162) with Microsoft SMTP Server id 8.3.137.0; Thu, 22 Sep 2011 12:23:33 +0100 Date: Thu, 22 Sep 2011 12:23:30 +0100 From: Stefano Stabellini <stefano.stabellini@eu.citrix.com> X-X-Sender: sstabellini@kaball-desktop To: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com> In-Reply-To: <20110921211055.GA30029@phenom.oracle.com> Message-ID: <alpine.DEB.2.00.1109221221170.8700@kaball-desktop> References: <1316608670-23167-1-git-send-email-stefano.stabellini@eu.citrix.com> <20110921185102.GJ17357@phenom.oracle.com> <1316632095.5182.33.camel@dagon.hellion.org.uk> <20110921211055.GA30029@phenom.oracle.com> User-Agent: Alpine 2.00 (DEB 1167 2008-08-23) MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Cc: Ian Campbell <Ian.Campbell@eu.citrix.com>, "jeremy@goop.org" <jeremy@goop.org>, "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>, Stefano Stabellini <Stefano.Stabellini@eu.citrix.com> Subject: [Xen-devel] Re: [PATCH] xen: change XEN_PLATFORM_PCI to bool default y X-BeenThere: xen-devel@lists.xensource.com X-Mailman-Version: 2.1.5 Precedence: list List-Id: Xen developer discussion <xen-devel.lists.xensource.com> List-Unsubscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe> List-Post: <mailto:xen-devel@lists.xensource.com> List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help> List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=subscribe> Sender: xen-devel-bounces@lists.xensource.com Errors-To: xen-devel-bounces@lists.xensource.com On Wed, 21 Sep 2011, Konrad Rzeszutek Wilk wrote: > On Wed, Sep 21, 2011 at 08:08:15PM +0100, Ian Campbell wrote: > > On Wed, 2011-09-21 at 19:51 +0100, Konrad Rzeszutek Wilk wrote: > > > On Wed, Sep 21, 2011 at 01:37:50PM +0100, stefano.stabellini@eu.citrix.com wrote: > > > > From: Stefano Stabellini <stefano.stabellini@eu.citrix.com> > > > > > > > > The xen-platform-pci module is small and for PV on HVM guests is a > > > > > > How small? > > > > IIRC it is single digit numbers of kb. > > > > > Does it get removed from memory if it never gets loaded? > > > > > > > requirement for xenbus. > > > > > > Ok, should it then have a depency on XenBus as well? > > > > xenbus can't be a module (which is why allowing platform-pci to be is > > causing problems). > > > > > Linus does not like the 'default y' very much. He actually dislikes > > > it quite much as I found when he tore Dan's behind about cleancache. > > > > In particular case the option is gated on a dependency on another Xen > > option (PVHVM) which doesn't default on. But if you do select PVHVM you > > certainly want this option, so I think that's ok (why else would > > 'default y' even exist?) > > > > > .. so I think making it 'default n' is a better option or perhaps > > > making it depend on some other functionality? Or perhaps just remove > > > the tristate/bool altogether so it gets activated if XEN_PVHVM > > > is set? > > > > > > Or remove the XEN_PLATFORM_PCI config option completly and make the > > > config files that build this driver be CONFIG_XENPVHM dependent? > > > > That would work too. Even better would be to make it an invisible > > Kconfig symbol which PVHVM just selects. > <nods> > Or that since you can't really do PVHVM without the platform PCI driver. > Considering that we all agree that XEN_PLATFORM_PCI is needed for PVHVM, why should we keep around the old XEN_PLATFORM_PCI config option? I think that Konrad's idea of just using CONFIG_XEN_PVHVM to build xen-platform-pci.o is the best one. _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel From xen-devel-bounces@lists.xensource.com Thu Sep 22 04:36:17 2011 Return-path: <xen-devel-bounces@lists.xensource.com> Envelope-to: www-data@lists.xensource.com Delivery-date: Thu, 22 Sep 2011 04:36:17 -0700 Received: from localhost ([127.0.0.1] helo=lists.colo.xensource.com) by lists.xensource.com with esmtp (Exim 4.43) id 1R6hZh-0002Tg-Mt; Thu, 22 Sep 2011 04:36:17 -0700 Received: from mail174.messagelabs.com ([85.158.138.51]) by lists.xensource.com with esmtp (Exim 4.43) id 1R6hZA-0002Gy-2Y for xen-devel@lists.xensource.com; Thu, 22 Sep 2011 04:35:44 -0700 X-Env-Sender: dunlapg@gmail.com X-Msg-Ref: server-5.tower-174.messagelabs.com!1316691340!28656744!1 X-Originating-IP: [74.125.82.171] X-StarScan-Version: 6.4.1; banners=-,-,- X-VirusChecked: Checked Received: (qmail 10800 invoked from network); 22 Sep 2011 11:35:41 -0000 Received: from mail-wy0-f171.google.com (HELO mail-wy0-f171.google.com) (74.125.82.171) by server-5.tower-174.messagelabs.com with RC4-SHA encrypted SMTP; 22 Sep 2011 11:35:41 -0000 Received: by wyh13 with SMTP id 13so1426293wyh.30 for <xen-devel@lists.xensource.com>; Thu, 22 Sep 2011 04:35:40 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=wsqYCwAupotxW7di23MrBVo6Zrs+HjASEIa64hoDUpk=; b=mJ7Jsr0beFAqipNX0wCtTlIKvHc6TX/xbhshBE5T+QEp8wj45idmVTPJUQaqbawRWr zduF+olYOU/t/5sBMHukO+3b+bAvZcL+wZ22up141ypWfsff/1dQMNAEJGwi+Sb2Gdhc gB6LtadGFlvRRCaq/6zFMESHWpIfFF6j1wj2w= MIME-Version: 1.0 Received: by 10.216.15.76 with SMTP id e54mr2375043wee.54.1316691340440; Thu, 22 Sep 2011 04:35:40 -0700 (PDT) Received: by 10.216.176.81 with HTTP; Thu, 22 Sep 2011 04:35:40 -0700 (PDT) In-Reply-To: <CAEAezkUtuuyQomUaCtgyb4vMoVTT9KDaG7GYcy3XN4MbSJDpRQ@mail.gmail.com> References: <CAEAezkW3V_G-q_PP5n45a9gy_ovwJ=sNywvwsa_qYSJn7Cveiw@mail.gmail.com> <CAEAezkUtuuyQomUaCtgyb4vMoVTT9KDaG7GYcy3XN4MbSJDpRQ@mail.gmail.com> Date: Thu, 22 Sep 2011 12:35:40 +0100 X-Google-Sender-Auth: FAOMQtwkU5bcUbJdPGCSdq0gWEY Message-ID: <CAFLBxZYo-ct43aJDnRr7uqZakaoxwRQ2SAu6n0tveLnbCWB2+w@mail.gmail.com> Subject: Re: [Xen-devel] Fwd: [help]: From: George Dunlap <George.Dunlap@eu.citrix.com> To: Pratik shinde <pracshi@gmail.com> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: xen-devel@lists.xensource.com X-BeenThere: xen-devel@lists.xensource.com X-Mailman-Version: 2.1.5 Precedence: list List-Id: Xen developer discussion <xen-devel.lists.xensource.com> List-Unsubscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe> List-Post: <mailto:xen-devel@lists.xensource.com> List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help> List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=subscribe> Sender: xen-devel-bounces@lists.xensource.com Errors-To: xen-devel-bounces@lists.xensource.com On Tue, Sep 20, 2011 at 3:04 AM, Pratik shinde <pracshi@gmail.com> wrote: > =A0=A0=A0 "In xen,Qemu emulates the hardware to guest O.S.so guest kernel= is > unaware of underlying real hardware.So scheduling of processes which gues= t > kernel will do,may not be optimized. In credit scheduler it schedule the > VCPUs according to their weights but process scheduling on VCPU may not b= e > optimized. > My basic idea is scheduling these processes according to real hardware an= d > the scheduling domains accordingly." What do you mean, "the guest kernel is unaware of underlying real hardware"? It's aware of the cpu model given to it, which is the most important thing for scheduling. Do you perhaps mean that the guest kernel is unaware of the actual cpu and cache topology? -George _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel From xen-devel-bounces@lists.xensource.com Thu Sep 22 04:47:43 2011 Return-path: <xen-devel-bounces@lists.xensource.com> Envelope-to: www-data@lists.xensource.com Delivery-date: Thu, 22 Sep 2011 04:47:43 -0700 Received: from localhost ([127.0.0.1] helo=lists.colo.xensource.com) by lists.xensource.com with esmtp (Exim 4.43) id 1R6hkl-00038L-H7; Thu, 22 Sep 2011 04:47:43 -0700 Received: from mail21.messagelabs.com ([85.158.143.35]) by lists.xensource.com with esmtp (Exim 4.43) id 1R6hk8-0002wb-RS for xen-devel@lists.xensource.com; Thu, 22 Sep 2011 04:47:05 -0700 X-Env-Sender: Stefano.Stabellini@eu.citrix.com X-Msg-Ref: server-4.tower-21.messagelabs.com!1316691985!61186643!1 X-Originating-IP: [62.200.22.115] X-StarScan-Version: 6.4.1; banners=-,-,- X-VirusChecked: Checked Received: (qmail 30120 invoked from network); 22 Sep 2011 11:46:26 -0000 Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115) by server-4.tower-21.messagelabs.com with RC4-SHA encrypted SMTP; 22 Sep 2011 11:46:26 -0000 X-IronPort-AV: E=Sophos;i="4.68,423,1312156800"; d="scan'208";a="8004622" Received: from lonpmailmx01.citrite.net ([10.30.203.162]) by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5; 22 Sep 2011 11:47:01 +0000 Received: from kaball.uk.xensource.com (10.80.2.59) by LONPMAILMX01.citrite.net (10.30.203.162) with Microsoft SMTP Server id 8.3.137.0; Thu, 22 Sep 2011 12:47:02 +0100 Date: Thu, 22 Sep 2011 12:46:59 +0100 From: Stefano Stabellini <stefano.stabellini@eu.citrix.com> X-X-Sender: sstabellini@kaball-desktop To: =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= <roger.pau@entel.upc.edu> Subject: Re: [Xen-devel] Most up to date blktap2 kernel driver In-Reply-To: <CAPLaKK6GMLd8A--W2Hxknk1GW0KjwNQrECkLcWh+=kw6-vsFHA@mail.gmail.com> Message-ID: <alpine.DEB.2.00.1109221244280.8700@kaball-desktop> References: <CAPLaKK7zKP5v_F8kN0CvEQn1bgWMUoL7E2AcYcZOHTsP9hEURg@mail.gmail.com> <1316677231.23371.7.camel@zakaz.uk.xensource.com> <CAPLaKK6GMLd8A--W2Hxknk1GW0KjwNQrECkLcWh+=kw6-vsFHA@mail.gmail.com> User-Agent: Alpine 2.00 (DEB 1167 2008-08-23) MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Cc: Ian Campbell <Ian.Campbell@eu.citrix.com>, "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com> X-BeenThere: xen-devel@lists.xensource.com X-Mailman-Version: 2.1.5 Precedence: list List-Id: Xen developer discussion <xen-devel.lists.xensource.com> List-Unsubscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe> List-Post: <mailto:xen-devel@lists.xensource.com> List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help> List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=subscribe> Sender: xen-devel-bounces@lists.xensource.com Errors-To: xen-devel-bounces@lists.xensource.com On Thu, 22 Sep 2011, Roger Pau Monn? wrote: > > I was just wondering about this, is your plan to bolt a block frontend > > onto the existing tapdisk2 process or are you building a thing using a > > NetBSD library for doing block devices in userspace (I think you are > > doing the former but either you or Christoph mentioned that library > > thing at one point too). > > Well, my first try was to create a user-space implementation of the > block devices found in blktap, so there was no need to change the > current blktap tools. This is however not possible right now, because > the library for implementing block and char devices as user-space > daemons doesn't support mmap, and there's no clear way about how to > implement this. > > Correct me if I'm wrong, but the second option would be to directly > implement the I/O ring from user-space without using any devices, I > haven't had much time to look into this, but I think this is the best > way, because it doesn't involve the constant context changes that the > implementation explained before has. I hope that looking into qemu > disk backend file can provide me with some information about how to do > this, possibly using libxc? Give a look at hw/xen_backend.c and hw/xen_disk.c in upstream qemu, they should give you an idea of what you need. You would still need a way to access the grant table from userspace, that on Linux is provided by the gntdev device, I hope there is something similar in NetBSD. _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel From xen-devel-bounces@lists.xensource.com Thu Sep 22 04:48:56 2011 Return-path: <xen-devel-bounces@lists.xensource.com> Envelope-to: www-data@lists.xensource.com Delivery-date: Thu, 22 Sep 2011 04:48:56 -0700 Received: from localhost ([127.0.0.1] helo=lists.colo.xensource.com) by lists.xensource.com with esmtp (Exim 4.43) id 1R6hlw-0003VX-Ay; Thu, 22 Sep 2011 04:48:56 -0700 Received: from mail216.messagelabs.com ([85.158.143.99]) by lists.xensource.com with esmtp (Exim 4.43) id 1R6hl0-0003Dj-8b for xen-devel@lists.xensource.com; Thu, 22 Sep 2011 04:47:58 -0700 X-Env-Sender: Ian.Campbell@eu.citrix.com X-Msg-Ref: server-4.tower-216.messagelabs.com!1316692075!19189717!1 X-Originating-IP: [62.200.22.115] X-StarScan-Version: 6.4.1; banners=-,-,- X-VirusChecked: Checked Received: (qmail 6042 invoked from network); 22 Sep 2011 11:47:55 -0000 Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115) by server-4.tower-216.messagelabs.com with RC4-SHA encrypted SMTP; 22 Sep 2011 11:47:55 -0000 X-IronPort-AV: E=Sophos;i="4.68,423,1312156800"; d="scan'208";a="8004733" Received: from lonpmailmx01.citrite.net ([10.30.203.162]) by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5; 22 Sep 2011 11:47:54 +0000 Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net (10.30.203.162) with Microsoft SMTP Server id 8.3.137.0; Thu, 22 Sep 2011 12:47:55 +0100 Subject: Re: [Xen-devel] Virtual File System in XEN From: Ian Campbell <Ian.Campbell@citrix.com> To: Nupur Ghatnekar <nupurghatnekar@gmail.com> Date: Thu, 22 Sep 2011 12:47:54 +0100 In-Reply-To: <CAO8_4Vq7Q145GWwW8jG0oOs6TugQvP764njJ3JLtrAZ766tNUw@mail.gmail.com> References: <CAO8_4Vq7Q145GWwW8jG0oOs6TugQvP764njJ3JLtrAZ766tNUw@mail.gmail.com> Organization: Citrix Systems, Inc. Content-Type: text/plain; charset="UTF-8" X-Mailer: Evolution 3.0.3- Content-Transfer-Encoding: 8bit Message-ID: <1316692074.23371.60.camel@zakaz.uk.xensource.com> MIME-Version: 1.0 Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com> X-BeenThere: xen-devel@lists.xensource.com X-Mailman-Version: 2.1.5 Precedence: list List-Id: Xen developer discussion <xen-devel.lists.xensource.com> List-Unsubscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe> List-Post: <mailto:xen-devel@lists.xensource.com> List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help> List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=subscribe> Sender: xen-devel-bounces@lists.xensource.com Errors-To: xen-devel-bounces@lists.xensource.com On Thu, 2011-09-22 at 11:01 +0100, Nupur Ghatnekar wrote: > We are an undergraduate group of students. For our final year project, > we are planning to implement a Virtual File System in XEN. > > > In a paravirtualised environment, an Userspace Application makes a > system call for access to a file, the domU’s kernel traps it and > converts it to an appropriate block number. Now this block number is > on the Virtual Hard Disk. The blktap mechanism is used for block I/O. > It involves using XenBus and a daemon in user space of Dom0 which with > help of libaio fires the request on Dom0 File System. Just for completeness actual I/O doesn't go via XenBus but is instead sent as grant references over a shared ring. > The current scenario involves multiple translations for getting the > actual physical address. > > > Our project intends to reduce the number of translations required > during the fetching or satisfying of the request. > > The DomU kernel doesn’t convert the FS request to block and passes on > this to dom0 using a client-server mechanism. > > > We intend to implement it using the 9P protocol.\ > > 1) The domU kernel’s filesystem component will be a client and the > dom0 will be the server. > > 2) The domU’s kernel will send the file request to dom0 using the 9P > protocol rather than converting it to appropriate block no. > > 3) The server in dom0 will authenticate the request, process it and > send the appropriate replies. > > > By having a virtual file system, the hypervisor will have a better > understanding of what the guest domains are doing and hence this can > help in taking intelligent decisions and thereby have better results > in caching, de-duplication and snapshots. > > > > Any suggestions for our proposed project would be appreciated. There has been some work on a 9p driver for virtio recently (see the qemu list), combining that with the virtio-on-xen GSoC project would like a decent approach to implementing this. Ian. > -- > > Nupur Ghatnekar _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel From xen-devel-bounces@lists.xensource.com Thu Sep 22 04:52:31 2011 Return-path: <xen-devel-bounces@lists.xensource.com> Envelope-to: www-data@lists.xensource.com Delivery-date: Thu, 22 Sep 2011 04:52:31 -0700 Received: from localhost ([127.0.0.1] helo=lists.colo.xensource.com) by lists.xensource.com with esmtp (Exim 4.43) id 1R6hpN-0003vQ-CL; Thu, 22 Sep 2011 04:52:29 -0700 Received: from mail182.messagelabs.com ([85.158.139.83]) by lists.xensource.com with esmtp (Exim 4.43) id 1R6EP5-0005Qv-Fi for Xen-devel@lists.xensource.com; Tue, 20 Sep 2011 21:27:30 -0700 X-Env-Sender: pracshi@gmail.com X-Msg-Ref: server-8.tower-182.messagelabs.com!1316579239!19137590!1 X-Originating-IP: [209.85.214.43] X-StarScan-Version: 6.4.1; banners=-,-,- X-VirusChecked: Checked Received: (qmail 19582 invoked from network); 21 Sep 2011 04:27:19 -0000 Received: from mail-bw0-f43.google.com (HELO mail-bw0-f43.google.com) (209.85.214.43) by server-8.tower-182.messagelabs.com with RC4-SHA encrypted SMTP; 21 Sep 2011 04:27:19 -0000 Received: by bkas6 with SMTP id s6so1562600bka.30 for <Xen-devel@lists.xensource.com>; Tue, 20 Sep 2011 21:27:19 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=Pw1kOpxXtyh2bN+nGidEkhxqe2iM0ymSD2tGttq2VD8=; b=w2rvyu0T0lnhF16vNdVwTEIeSeWFRMgZ7o+z/G5MV3kRTjM42rdn+3kkldYwdBTlz/ LEQ3TsF2D3CbyBjQM+fD1fA8R0e6YlTsxvg3SAYuBVg4PWz78+MtpZP841wxwJIPonvZ QJH4WfvV2fsODv6jxfzaTxkWOw2cfXvHQX8r0= MIME-Version: 1.0 Received: by 10.204.143.82 with SMTP id t18mr6158bku.52.1316579238827; Tue, 20 Sep 2011 21:27:18 -0700 (PDT) Received: by 10.205.36.2 with HTTP; Tue, 20 Sep 2011 21:27:18 -0700 (PDT) In-Reply-To: <CAEAezkWkbxv3pbE6RA=20qBXuws4dmUErjj_0itE=mLLRO2-Ug@mail.gmail.com> References: <CAEAezkWkbxv3pbE6RA=20qBXuws4dmUErjj_0itE=mLLRO2-Ug@mail.gmail.com> Date: Tue, 20 Sep 2011 21:27:18 -0700 Message-ID: <CAEAezkVR_sznYHuM3APLhjoLRGpnBpiwGizm5FKAk2hhz=5+-g@mail.gmail.com> From: Pratik shinde <pracshi@gmail.com> To: Xen-devel@lists.xensource.com Content-Type: multipart/mixed; boundary=00151747806cd95b4104ad6bfde0 X-Mailman-Approved-At: Thu, 22 Sep 2011 04:50:55 -0700 Cc: Tim.Deegan@citrix.com Subject: [Xen-devel] An idea for last year project X-BeenThere: xen-devel@lists.xensource.com X-Mailman-Version: 2.1.5 Precedence: list List-Id: Xen developer discussion <xen-devel.lists.xensource.com> List-Unsubscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe> List-Post: <mailto:xen-devel@lists.xensource.com> List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help> List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=subscribe> Sender: xen-devel-bounces@lists.xensource.com Errors-To: xen-devel-bounces@lists.xensource.com --00151747806cd95b4104ad6bfde0 Content-Type: multipart/alternative; boundary=00151747806cd95b3c04ad6bfdde --00151747806cd95b3c04ad6bfdde Content-Type: text/plain; charset=ISO-8859-1 Respected Sir, Thank you for paying attention to my mail. I am an undergraduate student of computer science.I want to do some good project in xen.I read the paper "affinity-aware dynamic pinning scheduling for Virtual machine" (copy is attached).Reading this paper i thought of an following idea.. "In xen,Qemu emulates the hardware to guest O.S.so <http://o.s.so/>guest kernel is unaware of underlying real hardware.So scheduling of processes which guest kernel will do,may not be optimized. In credit scheduler it schedule the VCPUs according to their weights but process scheduling on VCPU may not be optimized. My basic idea is scheduling these processes according to real hardware and the scheduling domains accordingly." Sir,is this idea already implemented in xen? Also,I want to know resource allocation policy used by xen. Sir,can you suggest any improvement to above idea or any good project idea in resource allocation or scheduler or in memory management of xen? Thanking you --00151747806cd95b3c04ad6bfdde Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable <div class=3D"gmail_quote"><br>Respected Sir,=A0 <br>Thank you for paying a= ttention to my mail.<br>I am an undergraduate student of computer science.I= want to do some good project in xen.I read the paper=A0 "affinity-awa= re dynamic pinning scheduling for Virtual machine" (copy is attached).= Reading this paper i thought of an following idea..<br> =A0=A0=A0 "In xen,Qemu emulates the hardware to guest <a href=3D"http:= //o.s.so/" target=3D"_blank">O.S.so</a> guest kernel is unaware of underlyi= ng real hardware.So scheduling of processes which guest kernel will do,may = not be optimized. In credit scheduler it schedule the VCPUs according to th= eir weights but process scheduling on VCPU may not be optimized.<br> My basic idea is scheduling these processes according to real hardware and = the scheduling domains accordingly."<br>=A0 Sir,is this idea already i= mplemented in xen?<br>Also,I want to know resource allocation policy used b= y xen.<br> =A0Sir,can you suggest any improvement to above idea or any good project id= ea in resource allocation or scheduler or in memory management of xen?<br>= =A0 Thanking you </div><br> --00151747806cd95b3c04ad6bfdde-- --00151747806cd95b4104ad6bfde0 Content-Type: application/pdf; name="affinity scheduling.pdf" Content-Disposition: attachment; filename="affinity scheduling.pdf" Content-Transfer-Encoding: base64 X-Attachment-Id: f_gsumeric0 JVBERi0xLjQNJYCEiIyQlJicoKSorLC0uLzAxMjM0NTY3ODk6Ozw9Pj8DQ0xIDAgb2JqDTw8IC9I ZWlnaHQgNDU0IC9CaXRzUGVyQ29tcG9uZW50IDggL1N1YnR5cGUgL0ltYWdlIC9MZW5ndGggMzU2 NTggL0ludGVudCAvUmVsYXRpdmVDb2xvcmltZXRyaWMgL1dpZHRoIDc1NCAvVHlwZSAvWE9iamVj dCAvRmlsdGVyIC9EQ1REZWNvZGUgL0NvbG9yU3BhY2UgMTI0IDAgUg0+Pg1zdHJlYW0K/9j/7gAO QWRvYmUAZIAAAAAB/9sAhAAMCAgICQgMCQkMEQsKCxEVDwwMDxUYExMVExMYFxIUFBQUEhcXGxwe HBsXJCQnJyQkNTMzMzU7Ozs7Ozs7Ozs7AQ0LCw0ODRAODhAUDg8OFBQQEREQFB0UFBUUFB0lGhcX FxcaJSAjHh4eIyAoKCUlKCgyMjAyMjs7Ozs7Ozs7Ozv/wAARCAHGAvIDASIAAhEBAxEB/8QBPwAA AQUBAQEBAQEAAAAAAAAAAwABAgQFBgcICQoLAQABBQEBAQEBAQAAAAAAAAABAAIDBAUGBwgJCgsQ AAEEAQMCBAIFBwYIBQMMMwEAAhEDBCESMQVBUWETInGBMgYUkaGxQiMkFVLBYjM0coLRQwclklPw 4fFjczUWorKDJkSTVGRFwqN0NhfSVeJl8rOEw9N14/NGJ5SkhbSVxNTk9KW1xdXl9VZmdoaWprbG 1ub2N0dXZ3eHl6e3x9fn9xEAAgIBAgQEAwQFBgcHBgU1AQACEQMhMRIEQVFhcSITBTKBkRShsUIj wVLR8DMkYuFygpJDUxVjczTxJQYWorKDByY1wtJEk1SjF2RFVTZ0ZeLys4TD03Xj80aUpIW0lcTU 5PSltcXV5fVWZnaGlqa2xtbm9ic3R1dnd4eXp7fH/9oADAMBAAIRAxEAPwD1VJJJJSkkkklKSSSS UpJJJJSkkkklKSSSSUpJJJJSkkkklKSSSSUpJJJJSkkkklKSSSSUpJJJJSkkkklKSSSSUpJJJJSk kkklKSSSSUpJJJJSkkkklKSSSSUpJJJJSkkkklKSSSSUpJJJJSkkkklKSSSSUpJJJJSkkkklKSSS SUpJJJJSkkkklKSSSSUpJJJJSkkkklKSSSSUpJJJJSkkkklKSSSSUpJJJJSkkkklKSSSSUpJJJJS kkkklKSSSSUpJJJJSkkkklKSSSSUpJJJJSkkkklKSSSSUpJJJJTV6hiX5dAqozLsB4cHG2gVlxAB G0+vXY2NZ4lYfTP2nX9ZrsT9qZGdg4OOHZnrtoAF9xmpjTRTWZbW0udJ7t8V0OTf9nxrcjY+z0mO f6dbS97tona1rQSSewCzfq1gX0dL9bOZsz+oudl5rTEtst/wf/W2wwfBJTiDM65kfVy/62s6hbUR Tbm4/Tgyr7P9nYHPZXZNZsLnVt9zg/Rx00V63qGX1vqePgdPy34OJ9ir6hkZNArdY8ZBLaK63Wss YG+1znHb4R3WZW7Po+qVv1SdhZL+qfZ7en0vFL/s72ODqa8g5AHpNbsIcQXSONSr5x3/AFe6xRli i27pr+nVYL3Y1TrXVPxXONc11Bz9r22HgaR5pKbv1e6hk2ZnVOkZd/2q/pV1bBe4NbY+q6pt1brG 1honUiQBMLbWD9XMS053V+tW0Oxv2rdUaa7W7bfRoqZSx1jTq3cQ5wadROuq3klKSVZ+BQ95e51w LjJDb7mj5Na8AKt0/CquwMa6yy91llTHvP2i4SXNBJ0sSU6SSq/s3H/fv/8AYi//ANKJfs3H/fv/ APYi/wD9KJKbSSq/s3H/AH7/AP2Iv/8ASiX7Nx/37/8A2Iv/APSiSm0kqv7Nx/37/wD2Iv8A/SiX 7Nx/37//AGIv/wDSiSm0kqv7Nx/37/8A2Iv/APSiX7Nx/wB+/wD9iL//AEokptJKr+zcf9+//wBi L/8A0ol+zcf9+/8A9iL/AP0okptJKr+zcf8Afv8A/Yi//wBKJfs3H/fv/wDYi/8A9KJKbSSq/s3H /fv/APYi/wD9KJfs3H/fv/8AYi//ANKJKbSSq/s3H/fv/wDYi/8A9KJfs3H/AH7/AP2Iv/8ASiSm 0kqv7Nx/37//AGIv/wDSiX7Nx/37/wD2Iv8A/SiSm0kqv7Nx/wB+/wD9iL//AEol+zcf9+//ANiL /wD0okptJKr+zcf9+/8A9iL/AP0ol+zcf9+//wBiL/8A0okptJKr+zcf9+//ANiL/wD0ol+zcf8A fv8A/Yi//wBKJKbSSq/s3H/fv/8AYi//ANKJfs3H/fv/APYi/wD9KJKbSSq/s3H/AH7/AP2Iv/8A SiX7Nx/37/8A2Iv/APSiSm0kqv7Nx/37/wD2Iv8A/SiX7Nx/37//AGIv/wDSiSm0kqv7Nx/37/8A 2Iv/APSiX7Nx/wB+/wD9iL//AEokptJKr+zcf9+//wBiL/8A0ol+zcf9+/8A9iL/AP0okptJKr+z cf8Afv8A/Yi//wBKJfs3H/fv/wDYi/8A9KJKbSSq/s3H/fv/APYi/wD9KJfs3H/fv/8AYi//ANKJ KbSSq/s3H/fv/wDYi/8A9KJfs3H/AH7/AP2Iv/8ASiSm0kqv7Nx/37//AGIv/wDSiX7Nx/37/wD2 Iv8A/SiSm0kqv7Nx/wB+/wD9iL//AEol+zcf9+//ANiL/wD0okptJKr+zcf9+/8A9iL/AP0ol+zc f9+//wBiL/8A0okptJKr+zcf9+//ANiL/wD0ol+zcf8Afv8A/Yi//wBKJKbSSq/s3H/fv/8AYi// ANKJfs3H/fv/APYi/wD9KJKbSSq/s3H/AH7/AP2Iv/8ASiX7Nx/37/8A2Iv/APSiSm0kqv7Nx/37 /wD2Iv8A/SiX7Nx/37//AGIv/wDSiSm0kma0NaGiYAgSSTp4k6p0lKSSSSUpJJJJSkkkklKSSSSU pJJJJSkkkklKSSSSUpJJJJSkkkklKSSSSUpJJJJSkkkklKSSSSUpJJJJSkkkklKSSSSUpJJJJSkk kklKSSSSUpVelf8AJeH/AMRV/wBQFaVXpX/JeH/xFX/UBJTaSSSSUpJJJJSkkkklKSSSSUpJJJJS kkkklKSSSSUpJJJJSkkkklKSSSSUpJJJJSkkkklKSSSSUpJJJJSkkkklKSSSSUpJJJJSkkkklKSS SSUpJJJJSkkkklKSSSSUpJJJJSkkkklKSSSSUpJJJJSkkkklKSSSSUpJJJJSkkkklKSSSSUpJJJJ SkkkklKSSSSUpJJJJSkkkklKSSSSUpJJJJSkkkklKSSSSUpJJJJSkkkklKSSSSUpJJJJSkkznNa0 ucQGgSSdAAFQwPrB0PqV7sfp+fj5dzAXOrpsa920EAuhpOmvKSnQSWfZ1/odWf8As2zPx2Z0hv2Z 1rRZJEgbZmSOyN1DqnTemUi/qOVViVOdta+54YC6J2jcdTokptJIOLl4ubQzJxLmZFFglltbg9p+ BajJKUqvSv8AkvD/AOIq/wCoCtKr0r/kvD/4ir/qAkptJJJJKUkkkkpSSSSSlJJJJKUkkkkpSSSS SlJJJJKUkkkkpSSSSSlJJJJKUkkkkpSSSSSlJJJJKUkkkkpSSSSSlJJJJKUkkkkpSSSSSlJJJJKU kkkkpSSSSSlJJJJKUkkkkpSSSSSlJJJJKUkkkkpSSSSSlJJJJKUkkkkpSSSSSlJJJJKUkkkkpSSS SSlJJJJKUkkkkpSSSSSlJJJJKUkkkkpSSSSSlJJJJKUkkkkpSSSSSlJJJJKUkkkkp5z683uZ0zDx fTfbXn9QxcW6tg0cx9m4seSQAyzbsJ81Zx+sZdPUaumdQwa8Sy+m23CfRb6zHMo2b2OmuosPvboA R5q71fpdfVMP7M55qeyyu+i5oBNdtLxZW8A8w5vCq4XRs39oV9T6tlszMrHrfTjCmo0VsbaWGw7X WWkudsGu75JKcHGoqf8A4rMi9wD7sjp9+bdZ3dkPY+91k/vb9fJW+i2WZ/1jx8jNbF+P0bFtrrcQ 412ZT3+uQe5PpNE+Xmjf808tuHZ0arqAZ0G4v3Yop/TtqscXvx67/UDW167R+jkN0B7q71Dol782 nqXSshmFm00nGPqV+rVZSXB7WPY19bvYR7SHaSfFJTT+rrns+sn1lxGs2YtWRjW1EEbd92Mx1oDe 2oDj4yujWf0jpP7OZfZbccnMzbfXy8gt2Bz9rWAMYCdrWtaGtEn4krQSU1n59DHljm3EtMEtoucP k5rCCqvTeoUM6disLbiW01gxRc4aNHBbWQVpqr0r/kvD/wCIq/6gJKV+0sf9y/8A9h7/AP0ml+0s f9y//wBh7/8A0mrSSSmr+0sf9y//ANh7/wD0ml+0sf8Acv8A/Ye//wBJq0kkpq/tLH/cv/8AYe// ANJpftLH/cv/APYe/wD9Jq0kkpq/tLH/AHL/AP2Hv/8ASaX7Sx/3L/8A2Hv/APSatJJKav7Sx/3L /wD2Hv8A/SaX7Sx/3L//AGHv/wDSafN6hi4NRsvfEcMGrjMxA+Syq/rbius2vpexkxvBBPzGijnm xwNSkAWSGHJMXGJIdT9pY/7l/wD7D3/+k0v2lj/uX/8AsPf/AOk0am6q9gspeHsPBHmJRFIxtX9p Y/7l/wD7D3/+k0v2lj/uX/8AsPf/AOk1aSSU1f2lj/uX/wDsPf8A+k0v2lj/ALl//sPf/wCk1aUL bqqazZa8MY3lzjASut1boP2lj/uX/wDsPf8A+k0v2lj/ALl//sPf/wCk02P1Xp+TZ6dN7XP7N1BP wmJVtCMoyFxIPlqmUZRNSBHno1f2lj/uX/8AsPf/AOk0v2lj/uX/APsPf/6TVpJFDV/aWP8AuX/+ w9//AKTS/aWP+5f/AOw9/wD6TVpJJTV/aWP+5f8A+w9//pNL9pY/7l//ALD3/wDpNYvXevZFeQ7E xHemK9LLByXeA+Co4P1gz8a0G6x19RPva/Ux5FVpc5jjPg10NGXRsx5PJKHFpqLEer1H7Sx/3L// AGHv/wDSaX7Sx/3L/wD2Hv8A/SaNXdVa1rq3hweAWwex1RFZBvZrEVu1f2lj/uX/APsPf/6TS/aW P+5f/wCw9/8A6TVpJJTV/aWP+5f/AOw9/wD6TS/aWP8AuX/+w9//AKTVpUs7q+Dgnbe+bDr6bRLv n4ISlGIuRAHimMZSNRBJ8Gf7Sx/3L/8A2Hv/APSaX7Sx/wBy/wD9h7//AEmoYPWMHOdspeRZz6bx Dvl4q6lGUZC4kEeCpRlE1IEHxav7Sx/3L/8A2Hv/APSaX7Sx/wBy/wD9h7//AEmrSSKGr+0sf9y/ /wBh7/8A0ml+0sf9y/8A9h7/AP0mrSSSmr+0sf8Acv8A/Ye//wBJpftLH/cv/wDYe/8A9Jqjn/WX ExLTTWw3vYYfBhoPhOqsdM61i9RljJrtAk1u8PEHuoxnxmXAJDi7MhwZBHjMTw9037Sx/wBy/wD9 h7//AEml+0sf9y//ANh7/wD0mrSSkY2r+0sf9y//ANh7/wD0ml+0sf8Acv8A/Ye//wBJqySAJJge KG7KxmfTuY34uA/igSBuUgE7BF+0sf8Acv8A/Ye//wBJpftLH/cv/wDYe/8A9JoeV1nAx6H2Nvrt e0HbW14JJ8NCuOys/LyrTbda4mZABgD4DsoM3NQx0B6yexZ8PKzyWT6AO4e1/aWP+5f/AOw9/wD6 TS/aWP8AuX/+w9//AKTWF0HrjmP+zZtv6Iia7Hn6JHYk9lvtz8F/0Mip3we0/wAU/FnhkiJA14Hd ZlwTxy4SL8Rsx/aWP+5f/wCw9/8A6TS/aWP+5f8A+w9//pNWG2Vv+g4O+BBUlKxNX9pY/wC5f/7D 3/8ApNL9pY/7l/8A7D3/APpNWlGyxlVbrLHBrGCXOPYBJTX/AGlj/uX/APsPf/6TS/aWP+5f/wCw 9/8A6TWXb9bcVtm2ul72AxvJDfuGq1cHPx86n1aHSBo5p0c0+BUcM2OZ4YyBLJPDkgOKUSAt+0sf 9y//ANh7/wD0ml+0sf8Acv8A/Ye//wBJq0kpGNZrg5ocJgiRIIOviDqnSSSUpJJJJSkkkklKSSSS UpJJJJSkkkklKSSSSUpJJJJSkkkklKSSSSUpJJJJSkkkklKSSSSUpJJJJSkkkklKSSSSUpJJJJSk kkklKSSSSUpJJJJSlV6V/wAl4f8AxFX/AFAVpVelf8l4f/EVf9QElNpJJZ3WuqjpuO1zW7rbSW1z 9EEfvaoSkIgyOwTGJkQB1dFJcN+3OqG0v+0v3DWNNuv8nhbFP1uo9AetU5140dsgMPzJVeHOY5Xd woX6uxZ58pkFcJE7JHp7jd6FJcnk/XDIOlNVdQ8XEvP/AH1ZWT9Yeo3zvyHkHsz2D/owpI5ZT/ms c8njw8MftLHOEMf87lx4/Di4pf4sbe8uysagTfaysfynAflWdf8AWbpVUhr3XEdmN/i6AuPoxOq5 pnHx7Hh358GP852i0cf6n9Vug5NrKG9xO933N0/FP9vmD8xx4fM8cvsFBi9/B+hDLn8QPbh9pRdb 6xX1G9lgHpNqbtaCZMkyTossZDZPbcefkAunZ9TsNjm1F9lzyJfYfaxo8gOXHtr8fMlX1RwHWZAI sArsAo3n2ub6dbtYDSRuJGhQ+64dTOU8spby0jWvZR5rmTXBGGGMTpHWVmjuf2uV03rOdj0jHxH1 7JJDXlsyefpEFaberfWUtBbih4/eFZIP3FT/AOaHTMhhIF2LYDDmB25sjwLh7gqzvqbmUEuws7ae 0hzD/nMJ/Ih90jtHmMkf72q775l3lyuKfjA1+BT/ALc+sQ1dgaDn9FaP+/Jf84usN1fg6f1XhV/s v10w/wCbuOQ0fymv/wDPuqX/ADj+sOJpmYMtH52x7P8ApatS+55f0eYv7Fff8I+fljD7abH/ADoz m/TwuePpD8oWX1Xq2R1GxvqN9JlY0rmdT37LTo+vGI7+fxrK/wCoQ/8ALsVHrOb0rqDxl42RtugC yqwOGg7tMR8lFn5PmuAjjM/6vCNfqGbBz/J8YPDGH9biOn0LmAkEEGCNQQt+jr/W30sFOJ60CPU2 PdujSfaQsfEwnXvax11VbXOdL3WMIAa4idHfd4rtMN+Bi41ePVexzKxAJe0k955UPL8rmiZWZYxd bb0z5+cwSEaEchri30jfTRxvtv1qs+jj7P7AH/VlL0frdb9J+z51j/qF0ItrJgPaSe0hTU/3Y/pZ ch/wqYfvI/RxYx/g283+xvrHb/OZu0dx6j/yNEJf81syz+fzZnnRzvyuC6RJL7pi68UvORV97y9O GPlEPDdU6Vd024McTZU4Sy2IB8R31VbHx7sm5tNLS57jAA/KV3Zsque7GvrE8tY8BzXtH5wnnzHZ AxrcOrDpyaaG1faWNcyqtoDnFw3BukSopfDwZ2JVDt1ZY/EahRFz79HLP1PrjTKIMfuA6/5wUf8A mncyPTzYj+QR+R66NpcWguEOI1AMwfinUv3PB+5+JYvvmf8Af/APN/8ANzqzR7M74+54/Il+x/rI yS3O3f8AXbP4tXSJJfdMfQyHlIq+95OoifOIeb+xfWtn0cjdHHvB/wCqCwMh1z7nuvJN247y7me6 9DWT1L6u42babmPNFrvpkDcD5lsjVQ5+UkYjglKVfoyl+TLg5uIkeOMY3+lGP5vJUPuruY+gkWhw 2Ecz2XQ7/rh+43/wL+9W+m/V3GwrRc95vtbqwkbWg+O2TqtdLBykxE8U5QvpCX5qz81AyHDCM66z j+Tzu/64fuN/8C/vS3/XD9xv/gX966JJT/dv9bl/xv7GH7x/qsX+L/a87v8Arh+43/wL+9M9/wBb 9jpYAIMkelPygro0kPu3+ty/439ifvP+qxf4r5yjYTcp2VW3EJbeTDCDEf6hdNn/AFYxsm43U2Gh zzLxt3NJPgJEKx0vomN04mwE23ER6hEQPIdlUjyWXjAOkQfmB/Jty53FwEjWRHykfm5v7K+s1n0s zZ3/AJ1w/wCoal/zc6s/+dzp/tPd+WF0iSt/dMfUyl5yLU+95OgjHyiHmx9UHOM2Zc/2J/EvRW/V DFH08h5+AA/vW+kiOUwD9D8Sg83nP6f4Bw3fVLA9NwZZb6hHtc4ggH4BoXNZOJkYtpqvYWOHjwfg e6760WOYRW7Y/wDNcRInzCq3ZrxQCB6d7baa7WHWBZaxhI8QQTB/im5ORxzrg9B8F0Oenjvj9Yq9 fDs8/wBH+r7ssG7LDq6I9gGjnHx17LQd9UcA/RttHxLT/wB9C1arn32b69MZsw7vYfFv8kePf4c2 EY8nijERMRI9Sd1sucyykZRkYjoBs8676n1H6GU4fFgP/fgo/wDNbMZ/NZsfJzdPk4rpEkvumD92 vIlP3vP+9fmA83+w/rAz+bzvOPUsH8Cq3UcPr9WI45VxtxxG8B27v3kTyutTOa1zS1wDmuEEHUEF CXKQIIEpix+9omPNzBBMYmj+7q+dLe+qTbftV7hPpenDvDdI2/hK0bfqv0yywvHqVg67GuG38Wkr RxcXHxKhTjsDGDWB3PiSocHJzhkEpEVHt1Zs/NwnjMYg3Lv0TJJJK+0FJJJJKUkkkkpSSSSSlJJJ JKUkkkkpSSSSSlJJJJKUkkkkpSSSSSlJJJJKUkkkkpSSSSSlJJJJKUkkkkpSSSSSlJLJ+tVXUrug ZbOl7/tcMLRU7ZY5jXtdayt3Zzqw4DzXG59P1h62zP8ArM1nUenvxvRp6D033se57XN32X0iZDnG CTpt54lJT6QkmbO0buY1jxTpKUks7rvU7ul9P+00UtyLnXUUV1Pea2l19rKAXPDXkAb54U+nXdas c/8AaeLj4zQB6Zx733Envu301R+KSm8kuZd9aepOwrutUYFVnQqDY71jeRkPpqJa++uoVFhb7S5v v1br3V7P63k/bMfp3R6K8vLvpOU511hqprona173MZa6XuMNG3WD4JKdhJZvRurP6h9poyKRjZ2B aKcqlr/UaHFjbGuY/a2Wua4ESAtJJSlV6V/yXh/8RV/1AVpVelf8l4f/ABFX/UBJTaWN9Z8G3KxG W1AvNBJc0aktdE/dC2UK+g3AMLoq/wAIwcuHhu8PHxTckBOJiTV9V0JmEhICyOj5rY6wOIZqIAny 17rWwfqt1XMrbbY9uPW7gOndHjtC61vS8MZT8g1VnexjA3Y3QtLyXA+e78Eeij0AWNcTV/g2H83x APh4eCdjAgBUYWAPVw+omt7YskDMkynkqRl6OKoAE3VOFjfUrp9cHItsvPgIY37hJ/Fa2N0fpmLH oY1bSOHEbnf5zpKuJJxnI7kojhxx+WIH5qSSSTWRSSSSSlJJJJKUkkkkpBfg4WR/P0V2+b2gn8Qs nN+rnR7HejRj7ch4mWOcGsb++4THwHf8m6ohrQS4AAu1cQNSYjVOjMjYlZPHGW8QfMPJV/VPFdUb zZa6ttttdjWwXBtdj6w4aa6N1H3eCsN+pOE9ofXlvLHCWkBpBB41XSta1ghoDRJMARqTJPzJSa1r BtYA0amAIEkyU45p92Mcri6xBeYP1FrjTMcD/wAWP/JKP/Md7dWZ3u/4uPyWLq0kveyd/wAFfdcP 7v4l5T/mdns/m8/U86OH5HFL/mt1tmlfUIHf32D8i6tJL3p+H2K+64ugI/wi8dkdC+sVRY37f6jt 00sFtu7d3IEQInmUHFxPrMwY78e7+cqaceXg+wgHa3foIHIXZV0MZY+2S6x/LncgdmjwAUWYdLcS vEgurqa1jCT7hsADTIjXTlO949QD9Fv3UXYlIf4Tzf2r67UfzlPqx/Jrd/56KX/OX6w06ZHT+O/p 2N/KSuqaC1oBJcQILjEnzMQnTfcj1hH6aLvYmNss/wDC1eVZ9eIO27CLT3h/8C0KzX9dumO/nKrm H4NI/wCqW+9jHiHtDh4ESq9nSumW/wA5iUuPj6bZ++EuLGf0CPIq4M42yiXnH+DRr+tfQ383lh/l Md/AFSxuudNFgpOZW+t381a50Ed9r90fI/frzKz6s9Ds5xQD4tc5v5HLPd9VOlX3FuP6jKmEiywO kT+4zcDx3Py54I9o/vBBPMCtIHysNzD6pTkYeNW7KYwiqs5NrntDi4tBc1snn949vjxotzcJ2rci ojye0/xXLYn1Ww7KMe3Itsa3JrY9j27doc9oOx0jTU6H5fG4fqRgx7ci0Hz2n+ARlHHfzEfREJ56 +QH/AAne+14n+mr/AM4f3qQvpcJFjSPEELnf+Y+L/wBybP8ANCZ31Gx/zct4+LAf4hN4cf75/wAV dx5/80P8d6T1qv32/eFJwLmkNO0kaOEGPPVcv/zGq/7mO/zB/wCSUT9RROmbA86v/UiXDj/f/wCa r3M/+Z/54dzKzbqMPJ3wzKppssrP5r9jSQ5s/iO34p7epY/q7fXrpqrP6S17miSPzGbj95+XPHL2 /VTbj5GVXlb6aK3Pa/043lgLob7zpp9JW6PqfiNu9HLvs3O/mnMDWtePKd0OHgncGP8Ae/BYMmcn +brbeTsW/WTolX0sprj4MDnf9SCqdv106UzStltp7Q0Af9J0/gjVfVLolf0qnWn+W93/AH3artXR +lU/zeJUCOCWAn73Sm/qh0kV9cwesI+VlwXfXa2w7cXCLj2lxJ/zWt/im/bP1tyf5jC9Idj6bh+N hhdS1jGDaxoaPACApJccBtAfU2r2ch+bMf8ABAi8n9j+umT/ADt/oA/y2s/89AqrZ9XupXVfaMjM 9RpsrqY8l793qWNr3NLo9oLue67OytlrDXYJY76Q4keBhKyquxgY9stDmuA41Y4Pbx4EIjMRsAPI IPKxO8pS0/Sl1eSp+r3XPcyjqBrtr+lWX2MIngjbMgjgov7N+uVP0Mr1I/4Td/58C6h1VbrG2Ee9 khruDB5HwU0jmPYHzChy0RtKQ8pPKer9eKfpM9QDyqPH9TVL9t/Wun+dwN4HJ9J5482OhdWkh7g6 wj+SfYkNss/qbeU/54dRq/pHT4jnVzPj9JpSf9c8a9gbbi2VkEFr63guafES0Lq0DKZVsk0C97jD WloMk/vEgwPNETh+59kkHHmA/nb84BwKfrTj5l+HX6dgubcZAADXzXZW0D3aS5w548Vv0U2Bxuvd uucIgfRaP3W/xPdZ9nRsdt2NZ6TfVdcXXW1N2bQKrdu3b9EB235rQofeHGm8bnNEttA9rh5+DvL7 vITMdOHTRdiExfuG9dPsTpJJKNmUkkkkpSSSSSlJJJJKUkkkkpSSSSSlJJJJKUkkkkpSSSSSlJJJ JKUkkkkpSSSSSlJJJJKUkkkkpSSSSSlJJJJKeY+vtH1qyOkvo6A2l1dlb25TXF4yDq3Z9nLIE8zK y+odJ/xndXwj03LyOmYePca/VyMY5AvY1jmvlk9/b8/Fbv16fk1/VLqT8XKGFeKhsvc4Mj3tlge4 gNLx7AfErgKKf8SlldfrZNpueB6hs+17tx53FrNvPPZJT64BAA5juU6SSSml1fD6fnYgw+oP2VW2 MLCLDS82VuFzNj2Oa7cCydD2WPhGzE+sp6Rh5l2Xhvwn3ZFd9rsg0W+o1tX6Z+549QOd7XOPGi38 rExMyl2Pl015FL/pVWtD2n4tcCFHC6fgdPp9DAxqsWqZ9Olja2z4w0BJTyGPl47P8V1+M9wZkUYF 3T7KZG8ZIa/G9Lb3cbNB4q50io9L+smPi5bzvu6NjU022u9z34j3i4T3d+laSt93R+kuzh1F2Fjn Ob9HKNTDaO2j43Ked07A6jT6GfjVZdUyK7mNsbI7w4FJTi/Vtgt+sH1k6jVYbMbIyaKaiDNZdjY7 K7Szz3na4+XkujQ6KKMallGPWymmsba6q2hrGgdmtbAARElNZ9fUS8mu+lrJ9odS5xA8yLmz9yq9 Nr6ienYpZfS1no17QaXEgbREn1hP3LTVXpX/ACXh/wDEVf8AUBJSvT6p/wByKP8Ath//AKXS9Pqn /cij/th//pdWkklNX0+qf9yKP+2H/wDpdL0+qf8Acij/ALYf/wCl1aSSU1fT6p/3Io/7Yf8A+l0v T6p/3Io/7Yf/AOl1aSSU1fT6p/3Io/7Yf/6XS9Pqn/cij/th/wD6XVpJJTV9Pqn/AHIo/wC2H/8A pdL0+qf9yKP+2H/+l1aSSU1fT6p/3Io/7Yf/AOl0vT6p/wByKP8Ath//AKXVpJJTV9Pqn/cij/th /wD6XS9Pqn/cij/th/8A6XVpJJTV9Pqn/cij/th//pdL0+qf9yKP+2H/APpdWkklNX0+qf8Acij/ ALYf/wCl0vT6p/3Io/7Yf/6XVpJJTV9Pqn/cij/th/8A6XS9Pqn/AHIo/wC2H/8ApdWkklNX0+qf 9yKP+2H/APpdL0+qf9yKP+2H/wDpdWkklNX0+qf9yKP+2H/+l0vT6p/3Io/7Yf8A+l1aSSU1fT6p /wByKP8Ath//AKXS9Pqn/cij/th//pdWkklNX0+qf9yKP+2H/wDpdL0+qf8Acij/ALYf/wCl1aSS U1fT6p/3Io/7Yf8A+l1FtHUWNDWX47Wt0DRQ4AD/ALfVxJJTS+zZ/p+l6uN6QG3Z9ndt28RHrxCn 6fVP+5FH/bD/AP0urSSSmr6fVP8AuRR/2w//ANLpen1T/uRR/wBsP/8AS6tJJKavp9U/7kUf9sP/ APS6Z1PUnNLXX47muEEGhxBB7H9OraSSmm6jqLmGt12OWEbS00OIIOkR66TqOouADr8dwBBE0OOo 1B/n1cSSU1fT6p/3Io/7Yf8A+l0vT6p/3Io/7Yf/AOl1aSSU1fT6p/3Io/7Yf/6XS9Pqn/cij/th /wD6XVpJJTV9Pqn/AHIo/wC2H/8ApdL0+qf9yKP+2H/+l1aSSU1fT6p/3Io/7Yf/AOl0vT6p/wBy KP8Ath//AKXVpJJTV9Pqn/cij/th/wD6XS9Pqn/cij/th/8A6XVpJJTV9Pqn/cij/th//pdL0+qf 9yKP+2H/APpdWkklNX0+qf8Acij/ALYf/wCl0vT6p/3Io/7Yf/6XVpJJTV9Pqn/cij/th/8A6XS9 Pqn/AHIo/wC2H/8ApdWkklLN3bRuILo1IECfISU6SSSlJJJJKUkkkkpSSp3dW6bTb6NuQ1tg0I1M HzI4VtrmvaHMIc1wkOGoIPggJRJIBBreikxkACQRe1hdJJJFCkkkDEy68uo21te1oe5kWMdWZY4s PteAYkaHukpOkmJABJ4GpWR0/wCtPSupPpZiNyntyADVa7EyGVEEbg71X1BkEd5SU7CSz7evdKp6 xV0W27b1C9gsrqLXQQd8e/bsk+m7SZ0R+o9Rw+mYb83Ns9KiuA5wBcZcQ1rWtYC4kkwAAkpspIOF mY+diU5uK7fj5NbbanwRLHjc0w6CNCjJKUkkkkpSSSSSlJJJJKUkkkkpSSSSSlJJJJKaXWWdQf0y 9vTaqL8wgelXlz6JO4Tv266CT8Vw3VMr68dHoZmZ/TOgMxBayu65rLYrFjgwPed0hu4gSAYXcdbb u6Vkzmu6Y1rd7s1m2a2sIc4+8EcCF5vVlfVb6w5VPSs762Z+bRba2MW1hoqtcDLWOf6beSNJ78ap KfVkkwAAAHA4TpKUkkkkpSSSSSlJJJJKUqvSv+S8P/iKv+oCtKr0r/kvD/4ir/qAkptJJIOTbdSG 2MZ6lYn1Wt1fH7zR3juPu8ClJkkP7RR6H2j1G+jt3epPt2+MqONbbcHWOZ6dZj0g7R5H7zh2nsOf HwCpSZJJJJSkkkklKSVfIfkUuFzB6tIEW1Ae8fy2ePm37tdCrM2htLLWH1fV0pazUvPg3/XTujSm wkgU2Oa0/abGC0mSxpENB4aJgn4lI5uEJnIqEc+9v96FKTpKoerdLaJOZQAOSbWf3qDuu9EaJOfj /K1h/IUaPYqpvJLNd9ZOgt5zqdfB0/kVO/609Hov9WvNbdW+BZSNxI7b6zEfFv3a8kQkeh+xNF3k lh3fW7oxAZjZVZsfpveHBjB+86QJ+A5/FWsbrfRRW1n7RpsI5fZa0OJOvcj7kuCXYqoukkgMz8Gz +byKn9va9p/IUYEOEtMg8EJqF0kkklKSQa8kOufQ9vp2tktB4cz95p/L4fdL5GQyhm50uc47WMbq 5zjw1oSpSVJVr+oYmLWHZl1WO6AS17wNfATErIy/rv0HHkV2PyXDtUwx979oREZHYEqovQJLi7Pr 5n5LzX0zp+9/bdusP+ZWB+VQ9P6/dT+k44dZ820x/m/pE/2j+kRHzKeHvo9ndfRQzffYypn7z3Bo +8rAt+tPRem2+nXkjJx3TFdQLzWf5Lvolh8J07acZ9P1AyLn+p1LPL3n6QYC4n+3Yf4K70/6m9IF gufS91LP5tt5O9/8p7RtAHg2Pj4IgYxvIy8k6d2J+uXRMu3ZdbZj4ojc0scXWHwds3Qzy7/DnUq+ tHQLfo5tY/ryz/qwFVyvqv0dlht+xNtof/OVs3B7P5dewgkeLfu8DG36jfV9/wBGuyr+pYT/ANXu QPt/1grTxderqXTrv5nKpsn9yxrvyFWAQRI1B4K5S3/F504/zOVcz+vtd+QNVc/UDLpM4vUtv9gs /Frylww/f+0Iod3tFF7trS4AuIBO0cmOwlcb/wA3Prnj60dS3gcN9az8j2wlt/xiY+gPrNHnS78s OS9sdJx/JVeIexpurvrFtR3MdweONCCDwR3CjbfXW+usybLTDWN1MD6TvgO5XEt639b8PJL7MDc+ 0EvZ6TiHbY98MdyBpP39ksf63dZqc+2zpvq22k7rNrxo0xsboYDfD+KXtHpR+qeF7tJcX/44V7BN vTYnj9IW/lrKI3/GLjn6eE8fB4P/AH0Je1PsjhL2CS5Rn+MPphjfjXt8Y2H8rgjN+v8A0N3LMhnx Y3+Dyh7c/wB0qo9npUlzr/rn9XL63V2W2Naf5DgfEEFvBCli/XHokOrvyw41iW3em8bx5jZo4d+3 h4Ae3LsfsVR7PQJLm6vrd0F9n2nIyiHNn0aBXYdgOku9kF5+4cDuSV314+rwEi57vIVu/iAl7cux +xVF30lzjvr50Eces74M/vcEN3+MHooMCrJd5hjP42BH25/ulVHs9OoWXV1BpsdtDnBgJ4k8Ce0r mD/jD6XJjGvI7TsH/fkG3/GDgWVuY7Be9rhDmOc2CD2OhS9qf7quE9nsFD1a/V9HdNgbuLfATEnw lcf0767G25mEyksba8Mqutfv9MOMe/Qbg34jz8V12Pj147C1suc47rLHauc795xQlAx3URSVJJJN QpJJJJSlGxzm1ucxu9zQS1vEkDQKSSSnmz1r6xyYwNO36K0/9+Q8jrX1g9F+/E9FhBDrBVY0tB7y 4wF1Ci9jXtLHgOa4EOB4IKrnBko/rpNgZ8dj9TF87Wr0vqnV8eg04dH2itpn6D37Se3sIhaN31Sp daXVZBrrJ+gW7iP7W4LYwsKjBoFFAho1JPJPiVWw8pmjMkn266g3bZzc3hMAAPcvoRVOH+2vrH/3 A/8AAbf/ACSPn5PWb/q7fl1Vux+oY36aupst9T0SLDWQ+YFgBat1NzoVcx4pRNnJKfgWnkyxkKGO MPEOHj9Uf1TruK3Bu/UKMIZl+06Pdle3GafEbWPd9yyndV6q76r15NWS5uW/q/2Ztzhuiv8AaBoD SO7dmi3+hfV/B6FTdThOscy+w2H1Xbi0QGsqZoIYxoho7KA+rWCOns6f6lvo15f24Olu71PtH2vb OyNu/TiY791KxNvCwPsmM+j7Rdkl7nONmQ/1HS7kA6Q2eBwO2iwcd3W/qtgdOxsx+NndOrdj4G6m uym5m8tored1lrbNSJ+iumurFtT6i5zRY0tLmEtcJES1w1B81lM+rbH5FV2fnZXUW49gux6Mg1it ljZ2v201V7y2dN8xzykpxOu4eRlfWDqj8ME5uH0/Cy8MAwTbRfk2NZP/AAgBYfIq3kZ9H1hycP7K 8uw8XE/al0EiXXMfXiscI/rvjsWhbtfTaK+qXdUDn+vfTXjvaSNgZU6x7SBEzNhnVVuk/V3p3SKM ynE37c+6y+4vIJBsG3azQQ1oENCSkf1O/wDEn0f/AMJY/wD57athVum4FPTen43T6C51OJUymtzy C4tY0NBcQAJ08FZSUpJJJJSkkkklKSSSSUpJJJJSkkkklKSSSSU4v1z6Tl9Z+rGf03Cdsyb2N9PW JLHts2Tp9Pbt+a5Tq/Vuq/WPpZ+ruN9WcrCzLTWw35FYbj4+1zd1ldvtnbHtI5/BdZ9cWdWs+rPU G9GLm9QNX6EsJD4Dml+wt13Fk7fNcn1369YPV+lN6R9WrMsdedZS3HYGWNsrcyxm/wBZx5AaCHTP mkp9EaCGgEyQOU6YTA3c944lOkpSSq9T6hV07Cty7QX7AAypsbrLHHbXWyfznuIaPNYP1eb1DG+s HVKc/JsyLDi4uTaxzy6tllrsne2lh0a0BoaI5jXVJT1CS4dtGRk/VG/622ZWS3qzsa3qNJbfaKqw 1rraqBQ14qLQwBpluvPKvNvH1l6pi4z7ba+mt6dT1B9dFllBtsyy4V7n1GuzaxtZ0nUnXhJT1SS5 /wCrWU5nU+s9Ddc+9vSrqfQNrnWWCnIpba1rrHyXQ7cBJmF0CSlKr0r/AJLw/wDiKv8AqArSq9K/ 5Lw/+Iq/6gJKbShbbXTW621waxvJKmhvpqseyx7dzqiSySYBPeOJ80lPK9a6H9Yc26zLwbvs2M4i 1mILHseHCPdtYNu4kbufxVWn6vfW+6sW1dX3MdwftF/zB9mhC7hQZTVW99jG7XWkF8cEjSY4nzUg ykCqH2J4njf+aX1pd7n9V9x5/S3H8SEv+aH1mOh6pp3/AElq7VJL3ZeH2K4i8V/zI61/5Z/jZ/el /wAxeqv0s6nLf7bvwLgu1SS92fh9iuIvC5H1Jy6drR1E2W2aV1NY6XEcn6egHcpW/wCL7KFXqHM9 SwRuY2uTH520ueJP3LuNjN5s2jeRtL41gaxPzUkven3/AAVxF4qj/F/jXVNsZ1Ava7uKo4MRBfII 7hHH+LrD0nMsJ7w1q6xrGNLi1oaXHc4gRJiJP3KSXuz7q4i8qP8AF50udci8jvBYP++Kbf8AF/0U GTbku8i9n8KwunSQ9yf7xVZ7vON+ofQRz6zvi/8AuaEKz6n9DNhxcal77RHqWue4trB8YIlx7D5n z6hJL3Jdyqy8zk/UjpDGtfTU+wMEWV7zucP3mnjd5cHyUW/UXoGRWLabMhrHaiHN+EEPYSIXUJJe 5PuVWXkn/wCLvBP83l2t/rBrtfltQD/i7c07qeolp86o/EWLtEkvdn3VxF4v/mZ1+r+Y6pH9qxnH H0ZS/YP14p+h1H1I1/nrHf8Anxq7RJH3ZdaP0VxF4TJx/r3T6Zst9Qh7RTDqnO3n93cJ458pnRM7 pX1y6ll7MzJ+zWhmgc8M9hOu0UAg9p+U9l2teNF7six3qWGWsMQGM/daPPue/wBwUsjHZewAksew 7q7G/Sa7xH+uqPu+EfOk8Xk8rjf4vKJ352Y+1x1cK2hv/Sdun7lsYn1T6BiwW4jbHD860mz8He38 FqsDg0B5DnQNxAgE94EmFJNOSZ3KLLCuqqpgZUxtbBw1oAH3BTSSTEKSSSSUpJJJJSkkkklKUX7g 07AC6DtBMAntJgqSSSkGNjelussd6mRZHqWRHHDWjs0dh/FM7HezI9fHIbvI9es/RcON4jh4/Hg9 iLCSNqUhvx6HzvrY6eZaDKIkgpqv6Z01878Sh06Ga2n+CE7oPRHc4GPp4VtH5Ar6SNnuVOPkfVv6 t11Gy3DraxupI3A66ADaZM9gq1H1O6JYX3X4np+p9CkWP9g8XEP+ke/YfiehSR45dz9qbLzuN9Ve gU2jGyMQOsM+laX2RYBrxvgPHcfMdwLrfqt9X28YVeviXH8pWqkkZyPU/aqy5rfq50JogYNPzaD+ VEHQ+igQMDG08amH8rVeSQ4j3KLao6X0wRGJQI4itn9ya7Br2gY1VNbyYNhYJaO5aNup+P8AsVtJ KypBRh42PX6dbBBncSJLp5Lj3lNj49mO41tduxomtpncw/ujxb4eHw4sJJWpSSSSClJJJJKUkkkk pSSSSSlJJJJKUkkkkpSSSSSlJJJJKUkkkkpSSSSSlJJJJKUkkkkpSSSSSlJJJJKUkkkkpSSSSSli QBJ0AUHW49drWvexltmjWkgOdHh3KzfrV03J6p0DLwsUtF1gY5rXmGPFb22OqcR+bYGlh+K43P8A q11Xq7M/rPVsRmP9YMn0aeh4QvYTjNqc0+oHtc1p90vPJj4wkp9ISTNkNAJkxqU6SnP6x0dvVWY4 OVkYb8W3167MYsB3BrmDcLa7Gn6XhysrpX1d6hh/WbMzr83KycV+NRWx9zqD6rgb97HtqqYYr3At 4579ulSSU8czp3X6fq7b9UmYRe11VmHT1Q2V+gMZ+5jX2N3C3e2s/RDILu8LQyMDO6T1anqfTsV2 fjnCZg5GNW5jLR6Li6mxnquYw6PcHe7wjuuhSSU4/QOn5dN/Uep51YoyeqXNtOOHB5rrqrZRWx7m y0uhkmDGvJ5WwkkkprP6b06x5fZi0ve4y5zq2kk+JJCq9N6b05/TsV78Wlz3U1lzjW0kktEkmFpq r0r/AJLw/wDiKv8AqAkpX7K6X/3Do/7aZ/cl+yul/wDcOj/tpn9ytIWTk0YtD8jIeK6qxLnHskpF +yul/wDcOj/tpn9yX7K6X/3Do/7aZ/cuVb9fLP2mXOqjpx9oZpvAn+cnx8v9667Hy8XJrbbj2tsY 8S0tMyE+eKUK4hutjOMro7I/2V0v/uHR/wBtM/uS/ZXS/wDuHR/20z+5Wkkxc1f2V0v/ALh0f9tM /uS/ZXS/+4dH/bTP7laSSU1f2V0v/uHR/wBtM/uS/ZXS/wDuHR/20z+5WlXpz8O/Itxabmvvo/na wdR/r3So/Yq2P7K6X/3Do/7aZ/cl+yul/wDcOj/tpn9ytJJKav7K6X/3Do/7aZ/cl+yul/8AcOj/ ALaZ/crSSSmr+yul/wDcOj/tpn9yX7K6X/3Do/7aZ/crSSSmr+yul/8AcOj/ALaZ/cl+yul/9w6P +2mf3ItGVj5G/wBCxtnpuLH7TMOHIKKkpq/srpf/AHDo/wC2mf3Jfsrpf/cOj/tpn9ytJJKav7K6 X/3Do/7aZ/cl+yul/wDcOj/tpn9ytJJKav7K6X/3Do/7aZ/cl+yul/8AcOj/ALaZ/crSSSmr+yul /wDcOj/tpn9yX7K6X/3Do/7aZ/crSSSmr+yul/8AcOj/ALaZ/cl+yul/9w6P+2mf3K0kkpq/srpf /cOj/tpn9yX7K6X/ANw6P+2mf3KeRm4eKJyb66R/wjw38pXKfWX63scw4fSrJDhFuQ3w/dZ/enwx ymaA+vRbOcYiyfo9R+yul/8AcOj/ALaZ/cl+yul/9w6P+2mf3Lkvq79cRjVDE6oXOrYIqvA3OAH5 ru5HgVvM+t/1ef8A9q9p8HMsH/fYRlhnE1wk+ICI5YEXYHm3/wBldL/7h0f9tM/uS/ZXS/8AuHR/ 20z+5V2fWPoT+M2kf1nbef60KwzqvTLP5vMof29tjD+QphjIbg/Yu4h3Cv2V0v8A7h0f9tM/uS/Z XS/+4dH/AG0z+5HZdVZ/Nva+f3SD+RTQS1f2V0v/ALh0f9tM/uS/ZXS/+4dH/bTP7lR6/wDWPG6P WGAC3LfqymeB+87wCt9J6tidVxRkY51GllZ+kx3gf4FO4JcPFXp7reKN8N6s/wBldL/7h0f9tM/u S/ZXS/8AuHR/20z+5Wkk1c1f2V0v/uHR/wBtM/uS/ZXS/wDuHR/20z+5WkklNX9ldL/7h0f9tM/u S/ZXS/8AuHR/20z+5WkklNX9ldL/AO4dH/bTP7kv2V0v/uHR/wBtM/uVpJJTV/ZXS/8AuHR/20z+ 5L9ldL/7h0f9tM/uVpJJTV/ZXS/+4dH/AG0z+5L9ldL/AO4dH/bTP7laSSU1f2V0v/uHR/20z+5L 9ldL/wC4dH/bTP7laSSU1f2V0v8A7h0f9tM/uS/ZXS/+4dH/AG0z+5WkklLNa1rQ1oDWtEADQADs E6SSSlJJKFrDZU+sOLC9pbubyJESElM1C1z2sLmN9Rw12AwT8JXLn6jEkk50k6kmqT/58TO+o7WN LnZ4a1okk1QAB/1xScGP9/8A5pYDkzf5n/nh6Q5tX6As9zb3mueNpax9h3A8RsiFOi8X7nsafS/M sP5/iW+Xge641/1TtHpGu/cL7DXVvZsJArfZujcYnZAVin6lsuZubnEEGHtNMOa791w9ROMMf7/4 LRmzE/zX/OD16i+xlbC+xwYxurnOMADzJXLf8xf+73/gX/qRT6/009N+ovV8U3G+Ma5wcREAt+iB JgaJkowA0lxfSmSE8hNSx8A78QL0LM3DsyH4td9b8moA2Ute0vaDwXMBkcJsnqGBiPrrysmqh9x2 1Nte1hcfBocRPCwOq4WJh9Q+rdmNUyqz7Y6s2NADiyzGvc9rncnc5oJnkqPRm9LyLevu6uyh2U3M uryxftMYrR+rA75/Rmkg+Ek95TGV6Z9tTI3va3dO2SBMDcY+A1UMbLxMus24l1eRWCWl9Tg9u5pg iWk6griMHHdkdO+qVGc02VPzMkVstmXY4pyzjh4dqf0W3R3bnutnHodR9bOr1dPFdFlvT8W0At/R m7fk1tsexhbu0aAdQYHKSnonWVtc1jnBrnyGNJALiNTA7qNlrW7mNc31gwvaxxjQdz3ie657reP1 tnRn5+bZRfm9KtZnYxxKn1yyr+er22W2kl9Ze3nul0q2rquR1fr1ThZjWMGFgvaQ5rqaGl9j2x+9 a9w/shJTuYuUXYlFuW6qq61gc5tb9zJ27nbHkN3ADvCB1HrFGL0LK6zilmZTj49mRWa3gssDGl2l jdwgxyuVx8anK6P9RqL276n7N7DwQMG0wfEGNR3XXZ2H01/TLsHJaynBvY6mxoIqbFvsIBEQXF33 pKQdOyev3Wj9oYeLj45bIfTkPufu0gbHY9Qj5qpjfWd1v1lyOiW4wqprcaqMv1J9S1tVWQ6s17RB 2WEjU/RKqlv7J6/0rD6bm5GQzNdaMvEvvflBtTKnOFwdaXvrh4a36UGVSysS+636yZOG3dndO6hR m4o7ufTi47nV/wDXK9zPmkp2frV9ZHdAwxdTjjMyC2y30DYK4ppbvtsJ2uMD2t45cFttduaHcSAf vXC9UyquufV/6w/WGr3YpwrMPpzj3rY3ffYNJG+32/2Au4q/mmf1R+RJTNJJJJSkkkklKSSSSUpJ JJJTk/WnpuV1XoOXg4hb69oY5jXkhr/TsZYanEdrA3YfiuQzPqp1vrVPUeu9TwfR65b6NPR8VtzX fZG1OafU9Rpa36UvPJj4wj/W/N+q2B1nNxM/H6lmZfWcSn7TThe5opqeQwtl7C2S3UDT7zPLV4v+ LoWNI6H15hBEO2ca8+22fuSU+zNkNAJkxqU6SSSlJJJJKUkkkkpSSSSSlKr0r/kvD/4ir/qArSq9 K/5Lw/8AiKv+oCSm0sv6wdFHWMH0BYa7azvqMnaXRw9vf+C1EkYyMSCNwggEUer5Q3pHUXdQ/Zwp d9qBgs8P5U8R5rph/i8aa27s0tsgborls949wK670q/U9XY31CNu+Bu2zMTzCmppczM1w+lijgiL v1PG/wDMTPr/AJjqUDge1zNPk8pf81/rZVrT1Tzj1rR+EFdkkm/eJ9aPmF3sw6WPq8b+zPr3T9DL 9SP+EDv/AD41Ld/jDq5HqDgfzB/JquySS949YQP+Cr2u0pD6vCdQ679cMbGc3Mq+zss9guDIIPgH AkArncXMycPIbk49hZcwyHD+PjK9ZyMenJpfRewWVWCHsdwQue6f9SsTF6g/Iud69DTOPU4f+fOx hS48+MRlcRHwHVjnimSKkT59GjX9b/rGQ137M3tImW12wQe45Tn66dZBg9Mgjyf/AHLsklF7kP8A Nj7WTgn++fseNH126q2TZ0z2j+uPytKb/n7mf+V3/Td/5Bdmkl7mP/ND/GKuCf7/AODxv/jgXMH6 Xp0Tx+kLfy1lU+p/XnLzMV2PjUfZC/R9gfvdt8G+1sLvlV6j03F6liuxspu5h1a4fSa7s5p8U6OT ECD7df4V/ggwyUfX+D5p0nq+X0rKGRjukHSys/RePA/3rra/8YHSyP0mPe099oY4T83tT9E+plOF kPyM4tySxxGOyPbH77ge/l2W4/pPSrPp4dDvjUw/wTsuTDKXymXiNFuOGQDevA6uUz689Cd9J1rP 6zP/ACJKOz63/V5//avafBzLB/32Ed/1b6E/nCqHb2jb/wBTCrv+p/1ef/2l2nxa+wfhuhR/qO0x 9i/9b/VP2thn1j6E/jNpH9Z23n+tCsM6r0yz+bzKH/1bGH8hWQ/6jdCdwLWf1X/+SBVd/wDi/wCl n+byL2/1ix35GNS4cP70h5hV5f3Qfq6vWPrBg9MxfVL23WvH6GphBLj4mOAs3oP1xx8tjqupvZj3 tkiwnaxw8NeCFjdb+pl/Tsc5WJYcmpmtrS2HtH72nI8fBUegfV7I6xfOteIw/pbv++s8T+RTRxYf bJ4r/rf2MZyZOMCvo9nk/XDoFGgyDc4dqmud+MBv4rLyP8YNE7cTDfYTwbHBv4N3/lWpjfU/oGPB +z+s4fnWuLvwkN/BamPh4mMIxqK6R/wbQ38gUV4RtGUvM1+TJWU7kR8hbyP7d+uefph4XoNP0XCs j/pXHal+wfrjn/0zN9Fp+kw2H/qahtXaJJe9XywjH6WVe1fzSkfq8jj/AOL7Hndl5j7CdSK2hn4u 3ofW/qRVXi+t0re6yoe+lx3F48W/yvLuuySQGfJYPFfh0V7MKqnj/q79TqjT9q6tXudYP0eMZG0H 858Rr5dlrP8Aqf8AV5//AGl2nxa+wf8AfoW0khLNMm+IjyKRjgBVA+bzz/qN0J3AtZ/Vf/5IFAf/ AIv+ln6GRe3+sWH8jAuoSSGbJ+8Ve1D90PHv/wAXlJ/m85zfDdWHfkc1R/5jdRr/AJjqUfJzdBxw 4rskkfvGT96/oEezDt+L5b1rpPUem5O3OJsNmrb5Lg/+07WQj9FxfrHT/lHpVLyzVpd7YcO42uPu C9DzcHEz6Dj5dYtqJBg6QR3BGoRq666q211tDGMAa1rRAAHYKQ816a4QT1valnseq7IHTu8d/wA7 frFif07pug/O2WV/idwVij/GDguj7Ri21+Owtf8Al2Lq1XvwMHJn7Rj1Wz3exrvyhR8eM746/ulf wTG0/tDmUfXHoF0A5BqJ7WMcPxAI/FaFHVemZEehl02E9g9s/dMqlf8AVLoF8k4orJ71uc38AY/B Z1/+L/pr9aMi6o+Dtrx+Rp/FKsJ6yj5i1XlHSMvLR6lZPWfrHg9IdXXbNlryJrZy1h5cf4BYX/Mr rOL/AMn9SiONX1f9QXLmOo0Z1GZZXn7vtIPvLzuJ893dSY8EJH5+IdtisnlnEfLwn7X1XGyaMqhm RjvFlVglrh3RV510Kn62sxXWdHDhjWO1k1bSRpLRd+ULS9L/ABh2fSfsjzoH/UpssABI44fU6ro5 SQPRL6DR7NJcZ9m/xg/6X/pVJfs76+u9xyYJ7eo0fkEJvsj/ADkPtT7h/cl9j2aS4z9mfXs6HLie /qD+5M7oP11c0tdnyDoR6z//ACKXtR/zkVe4f3JOj1X65YeDnsxam/aGNdGTY0/R8meJHdb2PkUZ VLL8d4sqsEteOCF5PmYeThZDsfJYa7WHVp/KD3XdfU3pPUMDGfblPcxl8OZin83+WfAnw+9SZsMI wBB1/wCksx5JykQRp+T0aSSSrM6kkkklKSSSSUpRcxj27XtDm6GCJGhkKSSSmJa1xaXAEtMtJHBg iR8ikGtDi4ABzoBdGpA4/KpJJKUh30UZFL6Mitt1NgLbKrGhzXNPIc12hCIkkpHZj49rq3WVMe6h 2+kuaCWOgt3Mn6JgkaKvl9H6Tm315GZhY+TfT/NW21Me5sa+1zgSFcSSUjfj49j6n2VMe+gl1LnN BLHEFhLCfonaSNEhj0C92QK2C97Qx9oaN5Y0ktaXckAuMBESSUsQCCCJB0IKFRiYuNjtxcamunHY C1tNbQ1gB5AY0Ad0ZJJSBuDhMbQxuPU1uJ/RWhjQKvaWfoxHt9pjTsiW01X1uquY22t4h7HgOaR4 EHRTSSU1MDpPS+mhzen4dGGHmXiittcnz2AI9ePRW+yyutjH3uDrnNaAXuADAXkfSO0AaoiSSmu3 p+A3D+wNxqhhbSz7KGNFWw8t9ONseUI4AAgaAJ0klKSSSSUpJJJJSkkkklKSSSSU4H1n6L9V8kM6 l1mxuDfQNlXUG3HHtYNYa2wOE/SOmq47B+tX1lq6g3D+rF931t6ewltj8mk1mvaGjb9s9geTzucP vW79bfqJnde63V1XGzqaBTQKBRkYzMpkhznl227czXd+6nZ9XP8AGHW0Mr+tFTGN0DW4FAA+ADUl PZJJJJKQZmZRhY7si8u2NgQxjrHkngNZWHOcT4AKt0zrmB1R9tWObK78fabsfIqsotaHztd6dzWu gxyreScgUWHFax+QGn0m2uLWF3YOc1riB8iuc6W/Lr+tGUerVNr6rlYTTjfZ3GzHOPQ90tDntY/e H2jduaBxCSnQs+tnRash9DrLSyqz0bcptFrsZlgMFjshrDWCDofdodCrPU+tYHTDU3INj7sifRoo rffa8NEuLa6WudA7mIXNYYrP+Kexw93qdJvssceXWuqse9xPdxeSSfFWegG6z6xVnNg5VfQ8IwJI DrLLfX2btdXMbPwCSnoendSw+pY/2jEeXMDix7XNcx7Hj6THseGua4eBCtLnfq/6w+tH1nb7fs3r 4hriZ9Q4tfqz2/dXRJKUqvSv+S8P/iKv+oCd+Ve15a3DueAYD2mmD5jdaD+Cq9Nyr29OxWjDueBT WA4GmD7RqN1oKSnTSVX7Zkf9wb/86j/0sl9syP8AuDf/AJ1H/pZJTaSVX7Zkf9wb/wDOo/8ASyX2 zI/7g3/51H/pZJTaSVX7Zkf9wb/86j/0sl9syP8AuDf/AJ1H/pZJTaSVX7Zkf9wb/wDOo/8ASyX2 zI/7g3/51H/pZJTaSVX7Zkf9wb/86j/0sl9syP8AuDf/AJ1H/pZJTaSVX7Zkf9wb/wDOo/8ASyX2 zI/7g3/51H/pZJTaSVX7Zkf9wb/86j/0sl9syP8AuDf/AJ1H/pZJTaSVX7Zkf9wb/wDOo/8ASyX2 zI/7g3/51H/pZJTaSVX7Zkf9wb/86j/0sl9syP8AuDf/AJ1H/pZJTaSVX7Zkf9wb/wDOo/8ASyX2 zI/7g3/51H/pZJTaSVX7Zkf9wb/86j/0sl9syP8AuDf/AJ1H/pZJTaUKaKaKxVQxtVYmGMAaBOp0 CB9syP8AuDf/AJ1H/pZL7Zkf9wb/APOo/wDSySm0kqv2zI/7g3/51H/pZL7Zkf8AcG//ADqP/SyS m0kqv2zI/wC4N/8AnUf+lkvtmR/3Bv8A86j/ANLJKbSSq/bMj/uDf/nUf+lkvtmR/wBwb/8AOo/9 LJKbSSq/bMj/ALg3/wCdR/6WS+2ZH/cG/wDzqP8A0skptJKr9syP+4N/+dR/6WS+2ZH/AHBv/wA6 j/0skptJKr9syP8AuDf/AJ1H/pZL7Zkf9wb/APOo/wDSySm0kqv2zI/7g3/51H/pZL7Zkf8AcG// ADqP/SySm0kqv2zI/wC4N/8AnUf+lkvtmR/3Bv8A86j/ANLJKbSSq/bMj/uDf/nUf+lkvtmR/wBw b/8AOo/9LJKbSo9T6L0/qnp/a69xqILXNMOgGS0nwKJ9syP+4N/+dR/6WS+2ZH/cG/8AzqP/AEsi CQbBooIBFHVsV1srY2utoYxgAa1ogADgAKSq/bMj/uDf/nUf+lkvtmR/3Bv/AM6j/wBLIJbSSq/b Mj/uDf8A51H/AKWS+2ZH/cG//Oo/9LJKbSSq/bMj/uDf/nUf+lkvtmR/3Bv/AM6j/wBLJKXyOnYW TfTkX0tstxzNTzyD/FWVV+2ZH/cG/wDzqP8A0sl9syP+4N/+dR/6WSs/Yqm0kqv2zI/7g3/51H/p ZL7Zkf8AcG//ADqP/SySm0kmaSWgkFpIktMSPIxITpKUkkove1jS95DWtBLnHQADklJTJJYp+uP1 bBIOZqNNK7SPvDFC763/AFcsrcwZzqyeHtrtkEag/wA2ncEv3T9iaPZ3Ulz1X126GKXG6+bWSIZX ZD4GhZubpPg7j8Usb639CAdZkZ02WQSxtduxgHDW/o9fM9/wS9uXY/Yqj2ehSWL/AM8vq3/3M/8A A7f/ACCNk/WHBq6UerUH7TiVvY257Tt2Mc5rXvcHx9AO3HyQMZDcEIouokqV3U66+qYvTGsNluVX bcXA6Mrq2Dcfi57QFk4/X8HA6F+0GU3uoOc/GNZebbN7sp2O5zdxJI3ahvhogp6NJVMG7Nycdzsz GODaXOa1gsbYdn5r9zRAPiOx8Vy9b+nD6x4NP1f6hbk5bb3jq9b8q29voNZYH+oy2xzWv9QNgNAI +CSns0lxfXczNw/rXb1CvIuGJ0zFxLcnFD3Cp1F1uRVkPdX9EljYfMT7Vr/WfIuuZjdKxLX1W52+ y22l+x7MahvqWOa4a+52yvT95JTupLK+ql1t/wBWOk3XPdbbZh0OfY8lznONbSS4nUkrVSUpJJJJ SkkkklKSSSSUpJJJJSkkkklKSSSSU5n1j6s7o3RsjqLKxbZVsZUxx2tL7bG0s3Hs3c8T5LnP+cf1 l6f0nr93U34t2d0V9BHpsc2kiyuq59Ylwdw/aD49uy6br93SqOjZdnWS0dOFZGTukgtd7dumskmB HdeX4rPqpVmHK/Z/1mz8dz22totrD8d5rj0nH3tc8NAAbuPCSn19p3NDh3Ep0kklNXPwfttLaxfd ivY7ey7HfseHQW8ODmuEO4c0jyVbp/QqcPKdn35F2fnur9H7VkFm5tc7tjG1MrY0E6mG691ppJKc J31QwnepQMrJb0y6x1t3Sw5n2dznvNjwT6fqhjnGS0Pj5aK31LodWdfTl1ZF2Dm47HVVZOOWbvTe Wl1bm2sexzSWjlvwWkkkpp9L6Xj9MpfXS59tlzzdkZFp3WW2OgF7yABMACAAANAIVxJJJSlV6V/y Xh/8RV/1AVpVelf8l4f/ABFX/UBJTaSSSSUpJJJJSkkkklKSSSSUpJJJJSkkkklKSSSSUpJJJJSk kkklKSSSSUpJJJJSkkkklKSSSSUpJJJJSkkkklKSSSSUpJJJJSkkkklKSSSSUpJJJJSkkkklKSSS SUpJJJJSkkkklKSSSSUpJJJJSkkkklKSSSSUpRsYyxjq7AHMeC1zTwQdCFJJJTi/8zfq3/3D/wDB Lf8Ayahd9Ufq3VW5/wBhc8jhjLLS4k6AD9It1JO45fvH7U2e7z1f1J6I6l/rUbLbJI2WWEVyNA3c 73R4n/YljfVHoLg6u/A221wC4WXbHA8OYfU/Dt+J6FJL3Jdz9qrLi/8AM36t/wDcP/wS3/yats6J 0yrpt3TKqQzEyGvbbXJdIsG10l5JOivpIGUjuSUWXnPqn0zrFDrsvrjQ3MZVVgUEPa8Poxgf0/t+ ibnvLiPIKs3ofVB9XqcM0frDOrjLczez+Z+3nJ3zuj+b90c/NdYkgpHebm02Ooa2y4NJqY9xY1z4 9oc4NdAJ7wVzvUaerdcvwaXdMf077Fl1ZL8y+yp0NqO5zaPQse4mwe07tuh+S6ZJJTinpNl/1h6h fk0h/T8zp9OKS4tIeQ/I9RhbM/RsHIhUfq30XrGNTmWdW9+RXUOnYEvDi7FoDtlriCYfc50u+AXU JJKc36t4mRg/V7puHlM9PIx8Wmq5kh217GNa4S0kHXwWkkkkpSSSSSlJJJJKUkkkkpSSSSSlJJJJ KUkkkkp4v65YX146szN6Th4nT7Oj5DGtbZe54u0DX79HhoLXjTTso05X+NiplbH4nSXtaGtLi6wO dGnItiT8Fu/XDpmb1b6s9Q6fgP8ATysiuKzxuhzXOZ/baC35rk+udX6x9ZOlj6uYX1fz+n5brKQM m1np04/o2McbGW6cBukduElPoqSYSAATJ7lOkpSSSSSlJJJJKUkkkkpSq9K/5Lw/+Iq/6gK0qvSv +S8P/iKv+oCSm0kkkkpSSSSSlJJJJKUkkkkpSSSSSlJJJJKUkkkkpSSSSSlJJJJKUkkkkpSSSSSl JJJJKUkkkkpSSSSSlJJJJKUkkkkpSSSSSlJJJJKUkkkkpSSSSSlJJJJKUkkkkpSSSSSlJJJJKUkk kkpSSSSSlJJJJKUkkkkpSSSSSlJJJJKUkol7A4NLgHOnaCdTHMKSSlJJJJKUkkkkpSSSSSlJJKL3 NY0vedrWglxPYBJTJJCxsmjKorycaxttFrQ+uxhlrmnggqdlldTHWWODGMBLnuMAAckkpKZJKj07 rnRuqPezp2dRlvq1sbTY15A4khp4Rquo4FuZbg1ZNT8zHAddjte02MBgguYDI5CSmwkq+bn4PT6P tGfkV4tAIb6tzwxsngS4hH51CSl0kkklKSSSSUpJJJJSkkkklOH9duoZ/Tfqr1HN6dIyqax6bhy0 Oc1r3if3WkuXCdbwz0ezNpu+tfVPtGNXRfjUOy3B+Sywne2rXVx2kCJjuu6PVsi/63v6C70hhV4A ybGPE2WvfYa4AOmxoGvmqv18vxuk9GHXW4mNkZPTbKvRF9bXHY+xlb2VuiWGDMjwSU9MDIBiJ7Hl OmadzQeJE6p0lNfNGc7Hc3AdWzIMBr7g5zG+JLWlpd8JCyuk9R6qzrWV0XqllOS+jHry6sqhhpBZ Y59ZY+t1lkEFnO5XOv8AXMToPTLOo5cljCGsYIBc952sbud7Wye50Cy/q1m9EysjJfV1LHz+sZ49 TK9F4fsYwbWV1jkV17vmTPdJSD9u/WG3o931nodjN6XUyzIpwXVPNtmNVPvN/qgNc9rd4Hp6cFX8 zqvUMzqNHS+jPqoe/GGbk5V9brQyp52UsbU19UueQ4/S0DfMLAq6pi0/Ua36tWvA66zEt6a3pw/n n27X47HVs+kWO+lu426q9R9m+rHWsc57243T7OlY+HXk2GK2W4bnfo32O0G5tvtk6wUlOx0PqeXl WZ2DnbDm9MubTbZUC2uwPrZcx7WuLi2Wv1EnVay5z6sVV5HVuuddpBOP1O6hmNaZAsqxqW1eoyfz S8ug9/gujSUpVelf8l4f/EVf9QE78W9zy5uZcwEyGNFMDyG6on8VV6bi3u6diuGZcwGmshoFMD2j QbqiUlOmkqv2PI/7nX/5tH/pFL7Hkf8Ac6//ADaP/SKSm0kqv2PI/wC51/8Am0f+kUvseR/3Ov8A 82j/ANIpKbSSq/Y8j/udf/m0f+kUvseR/wBzr/8ANo/9IpKbSSq/Y8j/ALnX/wCbR/6RS+x5H/c6 /wDzaP8A0ikptJKr9jyP+51/+bR/6RS+x5H/AHOv/wA2j/0ikptJKr9jyP8Audf/AJtH/pFL7Hkf 9zr/APNo/wDSKSm0kqv2PI/7nX/5tH/pFL7Hkf8Ac6//ADaP/SKSm0kqv2PI/wC51/8Am0f+kUvs eR/3Ov8A82j/ANIpKbSSq/Y8j/udf/m0f+kUvseR/wBzr/8ANo/9IpKbSSq/Y8j/ALnX/wCbR/6R S+x5H/c6/wDzaP8A0ikptJKr9jyP+51/+bR/6RS+x5H/AHOv/wA2j/0ikptJKr9jyP8Audf/AJtH /pFL7Hkf9zr/APNo/wDSKSm0kqv2PI/7nX/5tH/pFL7Hkf8Ac6//ADaP/SKSm0kqv2PI/wC51/8A m0f+kUvseR/3Ov8A82j/ANIpKbSSq/Y8j/udf/m0f+kUvseR/wBzr/8ANo/9IpKbSSq/Y8j/ALnX /wCbR/6RS+x5H/c6/wDzaP8A0ikptJKr9jyP+51/+bR/6RS+x5H/AHOv/wA2j/0ikptJKr9jyP8A udf/AJtH/pFL7Hkf9zr/APNo/wDSKSm0kqv2PI/7nX/5tH/pFL7Hkf8Ac6//ADaP/SKSm0kqv2PI /wC51/8Am0f+kUvseR/3Ov8A82j/ANIpKbSSq/Y8j/udf/m0f+kUvseR/wBzr/8ANo/9IpKbSSq/ Y8j/ALnX/wCbR/6RS+x5H/c6/wDzaP8A0ikptJKr9jyP+51/+bR/6RS+x5H/AHOv/wA2j/0ikptJ Kr9jyP8Audf/AJtH/pFL7Hkf9zr/APNo/wDSKSm0kqv2PI/7nX/5tH/pFL7Hkf8Ac6//ADaP/SKS m0kqv2PI/wC51/8Am0f+kUvseR/3Ov8A82j/ANIpKbSSq/Y8j/udf/m0f+kUvseR/wBzr/8ANo/9 IpKbSSZoIaASXECC4xJ8zEBOkpShdYKqX2lpcK2l21okmBMAeKmkkp413+MQBxA6eYB0m6D/AOe0 3/jif+a//wAG/wDUS7NJS8eL/Nf88sfBk/zn/ND5bn9d6hm9QGe6w12VmaWtOjB4D+K3av8AGFa2 trbsIWWAQ57bdoJ8dvpmPvV/qH1JxcrqTMml/oY7zORSPH/g+wn8F0VFFONSyihgrqrEMYOAFJPL hMY+ji8NqWQx5AT6q/G3kP8AxxP/ADX/APg3/qJaOV9Zbrfqjn9axKjj341Vjq22e9u+tu6e24Lo lR63039rdIzOmep6P2yl9Pq7d23eI3bZbP3qKUoEemHCe/FbJGMwdZcX0pzLsvrOB1PpbsnJZfj9 UuOPbiisNFTvStvY6qwe4xs2u3TPIhPRkdY6zbnW4Oa3Ax8PIsxcdoqbabLKJZa6/wBT831NAGbT A+lqtDP6T9su6bb6vp/s3I+0Rtnf+isp28jb/OTOqpnoPUsXKyn9J6g3Exs60330WUesWWPAFj6H CysN3xuO4OG7VRr2hX9ZOqZ2H0OzGFVGR1HJvxMoOaXsa+iu8PczUEjfTLfEcq5g9SzcLqnUen9S yDmU4mPVm15Aqi0Msdc11ZroHv2+l7drZ7anVGZ9WsehvSK8aw11dHtfcA4b3Wmyu2txc6R7nOtL ydZKtVdL9PreR1b1Z+0Y1WN6O3j0n2v3bp1n1OI7JKc7N+sjDj0dQwDYcSnKrpz2249tTvSu/R72 i9lboY9zXEjSJVhvUsq/q3UqKi37H07HY1xgEnJsDrSJ/kV7NP5Sv9RwaOo4GRgZAmnKqfVZHMPG 2QqfRuiP6b0uzDuyTl5WQ59mVmOYGGyyz27yxpPDQ1o14CSnJZ1vq9vSvqy/GdUzI6wGtvLmexu7 FfcXNaP3S2QPkuiox7mYLaMyz7fa1pD7HsYz1DMiWN9gWbj/AFb9DG6FR9o3fsKPdsj1YofjcbvZ 9Pd3WrmU33Y7q8e84tpgsua1ryCCHQWvBBBiD5cQdUlPNVZNuR9bsDI6liWdIsbj30YdVhrsOQ5/ pveDZQ97G7GskNJk89ln3Rg9f6r19ogdP6lTXmOA1OJkYuNXbJ8GO2WHyauho6J1C7qGNn9YzWZT 8Avdi1Y9Jx6w+xvpmx4dba5ztpIGsao1XQaQ/q/2h4vp6y8OsqLYDW+gzHLZk7p2T2SU879d46lj 9Wbo7F6LgWucIBBy8iv268g10z/nrs6v5pn9UfkWDj/VL0fqrldAfmOuyM1loyOoPZLn2WjbvLN3 5rQGgbuAFvsbtaG8wAJ+CSmSSSSSlJJJJKUkkkkpSSSSSnA+sv1So67ZRmU5V3Tep4gIx83HMOAd +a9sjc2dYkLJxv8AF7m5GdRlfWTrmR1mvFe2yjELfSq3tmHPbveDz2A+5dqkkpSSSSSlJJJJKWgT Ma8SkQCIIkeBTpJKUkkkkpSq9K/5Lw/+Iq/6gK0qvSv+S8P/AIir/qAkptJJJJKUkkkkpSSSSSlJ JJJKUkkkkpSSSSSlJJJJKUkkkkpSSSSSlJJJJKUkkkkpSSSSSlJJJJKUkkkkpSSSSSlJJJJKUkkk kpSSSSSlJJJJKUkkkkpSSSSSlJJJJKUkkkkpSSSSSlJJJJKUkkkkpSSSSSlJJJJKUkkkkpSSSSSl JJJJKUkkkkpSSSSSlJJJJKUkkkkpSSSSSlJJJJKUkkkkpSSSSSlJJJJKUkkkkpSSSSSlJJJJKUkk kkpSSSYEHgzGhSUuko+pWHhhcN51DZ1+5Jz2Mbue4NaOSTASUySTAggEGQdQQnSUpVelf8l4f/EV f9QFaVXpX/JeH/xFX/UBJTaSSSSUpJJJJSkkkklKSSSSUpJJJJSkkkklKSSSSUpJJJJSkkkklKSS SSUpJJJJSkkkklKSSSSUpJJJJSkkkklKSSSSUpJJJJSkkkklKSSSSUpJJJJSkkkklKSSSSUpJJJJ SkkkklKSSSSUpJJJJSkkkklKSSSSUpJJRsDixwYdryCGu5g9ikpkksA9J68ST9t5/wCFsH/fUv2R 17/ub/4LZ/5FScEf3wt4j+6XcfY1jq2u5sdtb8Q1z/yNU1zlvS+ttfUH5cue8trPqWGHbHOnjwBC J+yOvf8Ac3/wWz/yKXBH98K4j+6XfSWB+yOvf9zf/BbP/IqfUum9Ts+r2RSLvU6hV+nxHhzv5yoi ytpdoSCWwfIpsogDSQKQSelO4gYl9t9RstofjOD3NFdhaSQ1xaHewuEOiQsPpvUB17reLm4znfYc PBZfGoa6/NEtB8662GR/KWQ63Jf9Uqtt9ldr+tekLmu97WnqTq9CZ4bompe5JAEnQBZfT/rHg9R6 lb0/GZbNVLcht72bK7GOe+oGvdDiNzDrEHtKt9P6bhdNoNGHX6VbnGxwkuJe76TiXEmTyVlVf+Lz J/8ATTj/APtxkJKbGR9ZcPH6/T0Kyq31r2Ne3IAaaQbPV2Mcd24F3oujRWurdUp6VhOzLWWXQ5rG U1AOse95DWtaCQO/crnOs9Ot6j1/q9GPAy2dNwr8Nx4bkU35NtJMdt7RPkiUdRp+s2TRk1tIxumY n2q1hH0czJrcxtTtfpVV79w/lBJT0fTM+rqXTsXqFLXNqy6mXMa+A4NsaHAOgkTqrKx/qd/4k+j/ APhLH/8APbVsJKUkkkkpSSSSSlJJJJKUkkkkpSSSSSlJJJJKUkkkkpSSSSSkGZijLxn47rLKW2QH PpdsfE6gPGrZ4ka+BWH9S2V4/TupV1tiunqee1jfBrb3gDVbma7ObjPOAyqzJ09Nl73V1nUbtzmM sI0/krF+rPTvrB092VV1GvD+z5WRkZZfRdY94fkWGzZtsorG0TzPySU4lfSsHI+oeR9Yr6WP61fh 3dS/aBaPXZdsdczZafc1rIDWtn6IhXsZtH1k6zijqlAvxKOlY+YzDvYCz18tzw59lTtzS5ja4b4S VMfV7r1XSLPqzS/GHSbG2UNzC5/2ivGsLv0Qp2FrnNY7YHGzzI7K/mdIz8bqVPVejCl9jMYYV+Lk PdW19bHb6nCxjLNrmEu/N1nySU1/qu5mN1nr/RqGGvDwL6H4zAIrY3IoZY6uvwAcCY7SukWX0Tpe RhuzMzNex+d1K4X5Aqn02bWNqrrYXAFwaxg9xAk9hwtRJTWf1Lp1byyzKpY9phzXWNBB8CCVV6b1 LpzOnYrH5VLXtprDmmxoIIaJBErTVXpX/JeH/wARV/1ASUr9q9L/AO5lH/brP70v2r0v/uZR/wBu s/vVpJJTV/avS/8AuZR/26z+9L9q9L/7mUf9us/vRxY02uqH0mNa4/BxcB/1JU0lNX9q9L/7mUf9 us/vS/avS/8AuZR/26z+9WkklNX9q9L/AO5lH/brP70v2r0v/uZR/wBus/vVpDdfQz6djW/FwCSk P7V6X/3Mo/7dZ/el+1el/wDcyj/t1n96d3U+ns5yK/k4H8irY/Vun+tkbr2gOsBYTIEenW3v5gpw jLsUWO7Y/avS/wDuZR/26z+9L9q9L/7mUf8AbrP70RmXiWfzd1b/AIOB/ijJtJav7V6X/wBzKP8A t1n96X7V6X/3Mo/7dZ/erSSSmr+1el/9zKP+3Wf3pftXpf8A3Mo/7dZ/erSSSmr+1el/9zKP+3Wf 3pftXpf/AHMo/wC3Wf3qyCDqDI408tE6Smr+1el/9zKP+3Wf3pftXpf/AHMo/wC3Wf3q0kkpq/tX pf8A3Mo/7dZ/el+1el/9zKP+3Wf3q0kkpq/tXpf/AHMo/wC3Wf3pftXpf/cyj/t1n96tIOJY63Ep tfq6ytrnfEgEpKR/tXpf/cyj/t1n96X7V6X/ANzKP+3Wf3q0kkpq/tXpf/cyj/t1n96X7V6X/wBz KP8At1n96tJJKav7V6X/ANzKP+3Wf3pftXpf/cyj/t1n96tJJKav7V6X/wBzKP8At1n96X7V6X/3 Mo/7dZ/erDHtsY2xhlrwHNPiDqFJJTV/avS/+5lH/brP70v2r0v/ALmUf9us/vVpJJTV/avS/wDu ZR/26z+9L9q9L/7mUf8AbrP71aSSU1f2r0v/ALmUf9us/vS/avS/+5lH/brP70e2xtVT7X/RraXO jwAkqaSmr+1el/8Acyj/ALdZ/el+1el/9zKP+3Wf3q0kkpq/tXpf/cyj/t1n96X7V6X/ANzKP+3W f3q0kkpq/tXpf/cyj/t1n96X7V6X/wBzKP8At1n96slzW/SIHxVXLy6WVt23MDjZXw4TtNjQ78EQ CVEr/tXpf/cyj/t1n96X7V6X/wBzKP8At1n96O26l30bGu+BBU0FNX9q9L/7mUf9us/vS/avS/8A uZR/26z+9WkklNX9q9L/AO5lH/brP70v2r0v/uZR/wBus/vVpJJTV/avS/8AuZR/26z+9L9q9L/7 mUf9us/vR32NY6trubHbW/ENc/8AI1TSU1f2r0v/ALmUf9us/vS/avS/+5lH/brP71aSSUs1zXND mkOa4SCNQQe4TpJJKUkkkkpSSSSSmLq2OLHOEms7m+Rgt/ISpJJJKUkkkkppdM6P0zpNd1fTqG47 Mi119oaSd1j/AKTvcT4ccBRHQ+ljEbhij9XZkfa2s3v/AJ71ftO+d0/znujj5K+kkpZYtP1N6BTl tzK68j7SzaBY7MynEhh3ta7dedzZ7HRbaSSmu3BxWZ1nUGsjKurZTZZJ1rrLnMbtnboXnsh4XR+m 4FWRVh0ClmZbZfkAEnfZb9NxJJ58uOyuJJKQ4eJj4OJTh4rPTx8djaqWSXbWMG1olxJOnijJJJKU kkkkpSSSSSlJJJJKUkkkkpSSSSSlJJJJKUkkkkpSSSSSlJJJJKUkkkkpSSSSSlKr0r/kvD/4ir/q ArSq9K/5Lw/+Iq/6gJKbSHa68R6LGPPfe4s/IxyIkkpxMvN6tTnPFOKHOdWwO27rBALyDIDI5PPg h/avrLZ9GnZ/ZA/6srbbVF77p+mxjI8NheZ/6aIpOMfuj6reE9y4Ho/Wez6Vmz5sH/UJfsjrtn85 mQPD1H/khb6SXunoIj6K4B3P2uB/zayH/wA7lz/ZLvyuCI36rY4+ne8/AAf3rbSQ92fdXBHs5Lfq 109vJsd8XD+DQo1dB6fY/IYWuArsDWEOMx6bHd/NxWwkl7ku5Vwx7OK/6r4h/m7bG/GHfwCF/wA2 8qv+Yy4+Rb/1JK30kvdn3VwR7OB9g+sVP83kep/bJ/8APgS+0fWan6dfqf2Wu/6hb6SPud4xP0Vw diXA/b3U6v5/Dj+y9n5ZU2fWmk/zmO5v9Vwd+UNW4oPpps/nK2v/AKwB/KlxQ6w+wqqX734OLR9Y sOqotNdhJfY/hsQ97nj87wKTvrTWPoY5PxcB/ArQxMDFbW4ux6w71LYlgnb6jtvbiIhW211s+g0N +AASMsdn0k/VAEu/4OF/zhzn/wA1hz/nO/IAl+0vrDZ9DF2f9bcP+qK30kuOPSATwn94uBu+tNnA 2D/rY/Lql9g+sdn0snZP8sj/AKgLfSS9ztGI+iuDxP2uB+wep2fz2ZPj7nu/LCHj9AybMeu6vK2+ oxrg2CIDhMaFdGo11srrbWwQxgDWjwA0CXuy/kFcAcL9idXb/N5vHHvePyJfsz6wsiMvd/1xx/6p q30kvdl2H2K4B4/a4H2b6zN4t3f2mn8oS3fWpsyNw/61/Bb6SXuf1Y/Yrg8T9rgfa/rKzmjdH8kH /qSl+1evtgOw93/W3/wK30kuMfuBXCf3i89jdV6vXj1Mrwi9jGNax2x5kAQDoiftjrX/AHBP/bdi 2MWp1ONTS4gurY1hI4loARUjON/KFCJ/eLhftjrX/cE/9t2JftjrX/cE/wDbdi3UkOOP7gVwn94u F+2Otf8AcE/9t2JftjrX/cE/9t2LdSS44/uBXCf3i89k9V6vZj2sswixj2Oa92x4gEQTqpftH6w2 fRxds/8ABuH/AFRW1lVOuxrqWkB1jHMBPEuBCKjxxr5QrhP7xcD1frQ/6LNvfisf9Ul9m+sz/pW7 f7TR/wBSFvpJe52jH7FcHiftcD9k9ef9PMgdx6j/AMgCX/N7Of8AzmZP+c78pC30kvdl4D6K4B4u CPqs3l+ST8GR/wB+Ka/6uY1VYd6ryS+tnYaPe1h7ea30xa1whwBEgwfEGQl7s+6uCPZxHfVaj829 w+IB/uUP+bNrP5vLj+yRr8nLfSQ92fdXBHs4H7E6uz+azI8Pe9v5JS+wfWJn0cnd/bJ/6oLfSR92 XUA/RXAPH7XA2/WlnB3j/rZ/Kl9r+stf0qN39kH/AKkrfSS9z+rH7FcP9YuBX1DrFuVjsvxQ2LPa S1zATse3Vx3Dgk8Laqdkkn1q2MEaFjy4z82NT2Veo+p8x6Ty+PGWuZH/AEkRNlIGqACQCOtqSSST UqSSSSUpJJJJSklSPWujNJa7PxgRoQbmTP8AnIGb9Yel04WRdRm41l1dT31V+qw7ntaS1sNdJkoW O64Y5kgcJ18HUSXn3/jg9a/0ON/mWf8ApVdB9X/rVRnYT7ep342Le20sazeK5YGtIdtseTySmjJE mmWfK5YR4iPs1ehSVH9udF/8sMb/ALer/wDJKWX1XBxOm3dUfYLMShjrX2VQ/wBrdSRt5T7DCYyG 4I824ksqn6xYVmdThmq+oZW4YmRZXtpuLQXObW6Zna2RuAkcSllfWLFoyLqKcfJzXYhAyzi1+oKp bvh0lu52381m52o01SQ6qSy7vrH0qrHwsoWOtp6kSMR9TS/edjrQABrJDTHnoidN6zj9QuyMYVXY 2Vi7Tdj5DQx4a/dseNpc1zXbTBB8jBSU6CSrZfUMfDtxqrtwOZb6FTgJbv2ueA49pDTCHd1HG+13 dPDnDIqx/tFhaJ2McXMaZ/eJaYHkkpupLEp+sHTsPpXS77r7shnUWNGNc9k2WuNZtbubWBDnhugA 50WjTlX5WAMimh1F72Esx8obHNcJAbZs3xr4SkptJLB+ruX1SzqfWcPqOQ3JdhXUNrLGCtjfUx67 nBrZJjc4xucT5qhR1rqlP1uyqsm82dKdlN6fXTsaBVa/Gqyan7wA6Hu3t1J1ISU9akuW+vHWOpYe JZR0m842TRjXZ197WNftqpG1jPeHAGyxw7cNcunrJdW1x5IBKSmSSSSSlJJJJKUkkkkpSSSSSlJJ JJKUkkkkpSSSSSlJJLN6p1puDkU4VGNbn52Q19leNRsBFdcB9j33PrY1oLgOeSkp0klR6V1WnqVV pbXZj349no5ONaALK7AA7a7Y5zTo4EEGCFeSUpVelf8AJeH/AMRV/wBQFaVXpX/JeH/xFX/UBJTa VLrPUv2X027O9P1vR2/o52zuc1nMH97wV1Yv1y/8TeZ/1r/z7WhI0CfBfiAlkhE7GQB+1xf/ABxj /wCV3/g//qJdP0bqX7U6bTnen6Prbv0c7o2uczmB+74LySQum6N9Sf2p02nP+2+j6279H6W6Nr3M +l6jf3fBRQnMn978G9zHLYIwBv2td9ZfSn0JJcV/42//AJsf/Af/AFKl/wCNv/5sf/Af/UqfxT/c /Fre1g/z/wD42XtUlxX/AI2//mx/8B/9Spf+Nv8A+bH/AMB/9SpcU/3PxV7WD/P/APjZeh+sPWv2 LhMyvR9ffaKtm7Zy1zpna791c/8A+OMf/K7/AMH/APUSz+sfUjK6djMvxrX573PDDVXSZAIcd3tc /wAI4WR+xes/9wMn/tmz/wAimSnO9q/Fs4cHLGFkieu+sfwt9Uwsn7XhY+UG7PtFTLdkzG9odE/N HXC4v1Ez7cWm12caXWMa41OY4FhIB2H3DjhF/wCY/WRo3qeg41eNPvT+KX7v4tc4cNmswGv7pe1S XFf8yeuN1Z1T3Dj3WD8ZS/5ofWf/AMtf/Bbf7kuKX7pR7OL/AD0f8UvarL619YcLovo/amWv9fds 9INP0Nszuc395c9/zT+trP5rqsE8/prm/kaVi/WLpnWunnH/AGrl/a/V3+j+kss27dm7+cAiZHCE pyA+Uhfi5bFKYHuCe+g0L1H/AI4PRv8AQ5I/s1/+lV068XPC7P8A5o/Wg6u6rqef0tx1+5CGSRvS /Jkz8rijw1P27v5tbe1SXFf8xusO0d1P2nn6Z0+Epf8Aje5L9LOpS3/iyfwNgTuKX7v4sHs4eucf 4hezc9jPpuDZ4kwhuy8Vhh11bT5uA/iuRb/i4YPp9QJ+FUf+jCiN/wAXOKB7s2wnyYB/EpcU/wB3 8Ve3y/8Anif8ApPrJ9b8rpuczHwBj31moPc50vIcXOEex7ewCo4P186pdnY9N9eMym21jLHhr27W ucGuMusIEBZ/XPqpldPy2U4FWRmVOrD3WtrLgHFzht9gI4AVTD+r/VL8yim/DyaqbLGMssNTxta5 wDnS5sCAozKfF1bcMXL+2Njp8x3+x9LHVOmkwMugk8AWM/vU/t2F/wByKv8APb/euaP+LvpkaZN4 Padn/kVD/wAbrC/7mW/5rVJc/wB0fa1ODl/87L/Eepbl4r9GXVujwcD/ABUvXo/0jfvC5N3+LnFI 9ubYD5sB/iFH/wAbij/uc7/tsf8Ak0uKf7v4q9vl/wDPH/EL2LXNcJaQ4eI1XM9Z+uv7L6ldgjD9 b0dv6T1ds7mtfx6bv3vFUnf4t2z7eoEDwNM/+jAuX6x039ldSuwPU9b0dv6Tbtncxr/oy797xTZz mBtw/izcvgwSmRx+7p8vCY/W3tejfXX9qdSpwTh+j6279J6u6NrXP49Nv7viunXkfR+nv6n1KnCr t9F1u6LImNrHP7EeC6f/AJg9Rb7q+pe4ce1w/EPKUJyI24lcxy+CMgOP2tPloy+tvapLiv8AmP1r /wAs/wAbP70v+Zn1hZ/NdUgHn32t/JKdxS/dP2sPs4v88P8AFL2qS4r/AJofWf8A8tf/AAW3+5L/ AJr/AFybozq3tHH6xePw2pcUv3Sr2Mf+ej9hdPK+vPScXKuxbKchz6HureWtZBLDtMTYPBWejfWn p/WMl+NjV3MsYw2E2NaBALW/mvd+8vNs2q6nMyKch/qX12vZa+S7c8OIc6XamT4q79X8TquXmvr6 Td6F4qLnP3Fns3NBEtB7kJgySv8AY2p8niGMkGjXzE6PqqS4r9jfXuvVudvJ0j1if+qal+y/r/8A 9y//AAQf3J/Gf3S1fu8f89j+17VJcV9i/wAYTPa2/cPHfWf+qEpfZf8AGJ/pv+lT/clx/wBWX2K+ 7D/PY/8AGe1WL/zy+rf/AHM/8Dt/8gsT/wBeT/r9lXGDhNlkIqhX94M2Hk4S4uKYlVfzcr+3R9b6 b1npvVPU+w3et6Mep7XNjdMfTa3wKurzD6u/85ZyP2D/ACPtH81/L2fz3z4W16X+Mez6T9kca44/ 6hGOQkfKfoNFmTlIxmQMkAO05er6vapLivsv+MT/AE3/AEqf7kv2b/jAd7jlbSe3qNH/AFIhHj/q yWfdx/nsf+M9qhZWQzFxrsmyTXQx1jw3UwwFxj7lx/7L+vx0OXE9/UH9yBndF+uVeFkWZOdvoZU9 1zPWcZYGkuEbdZCRmf3SkcvCxeWG/Qur/wCOD0b/AEGT/m1/+lVsdH6xi9YxXZWK17GMeayLAAZA a781zv3l5MvQf8X3/I1//hl3/nupNhMk0WbmeWx48fFG7sdXp0kklK0FJJJJKUoXVMupfTZqyxpY 4DQw4QVNJJTy/wD43vRf9Nk/5zP/AEmgZ31B6ZThZFuPZk2X11PfVXLHbntaS1sNrkyV16Sb7cez MOazA/OS+SfsXrP/AHAyf+2bP/IroPq/9S6M/Dfd1NuTi3i0sbXArlga0h22ysnkld2kmjEAe7LP nsko0BweIeX/APG86L/psn/Or/8ASSn1joLMD6mdV6b01luQ+2i4sZ/OWPe5sQ0MaJ44AXSpJ4jE bBgnmyTFSkSHD63j5FmX9X3VVPe2jN33FrSQxv2bIbufH0RJA1VTp+Zd0K/qOHmYmXe7IzbsrDuo pfc21l5FgaXVhwrLCdnvIECeF06SLG8fg9Gz8Gn6s03VOdZTm5OTlBgL20/aKsqza5wEQ11obPcr SGDdd9aepOe22vGyOnY9IyGF1fuFmTuDLWxDmhwOhkLeSSU4HU/q7HQsvFwrb78oFuTiHKvtvIyK CLaYda5zgNzRICj0GvKysTqPWcvGtxsrqhPp41zNttdFLPSqrc3nV25/9pdCkkp5DBwcxvT/AKls fj2B2Jt+1NLHA1RhWs/SCPb7iBr3XV33Noosvc1721NLy2tpe8homGsYC5x8AERJJTyn1f6lu+sX V3uws6mvqV1D8ay7EvrZFeNXW4ve+sBvuYRqns6Lk54+s9BY+izIyqrsC9zSB6tOPjuqtYTG4NtZ +ELqkklPE2Y3VepfVHrnVMvDtq6n1bHeyrCLCbq6qmGuqrbG4lztz4j86F2dQIrYDoQ0fkU0klKS SSSUpJJJJSkkkklKSSSSUpJJJJSkkkklKSSSSUpYFJDPr1lB+jremUGknuK77/UDf6pe2fiFvqj1 Lo3T+p+m7LY71aZ9K6qx9NrA6NwbbS5jwDAkTqkpyvq+yw/Wf6z3B+7HdkYrGNAGljMWv1Pd/aaI 8l0ar4HT8Pp2OMbDrFVQJcRJcXOcZc973Euc5x5c4yVYSU1n2dRDyK6KXMn2l1zmkjzApdH3qr02 zqI6dihlFLmejXtJucCRtESPRMfetNDx6WY9FdDJLKmNY0nmGiBKSkPqdU/7j0f9vv8A/SCXqdU/ 7j0f9vv/APSCtJJKavqdU/7j0f8Ab7//AEgl6nVP+49H/b7/AP0grSSSmr6nVP8AuPR/2+//ANII eRl9Rx6LL341JZUxz3AXumGjcY/QK8h5FLMiiyh8hlrHMcRzDhBhJSH1Oqf9x6P+33/+kEvU6p/3 Ho/7ff8A+kFaSSU1fU6p/wBx6P8At9//AKQS9Tqn/cej/t9//pBWkklNX1Oqf9x6P+33/wDpBL1O qf8Acej/ALff/wCkFaSSU0b8vqNDA9+NSQXsZpe7mxzax/gPFyJ6nVP+49H/AG+//wBII11LLmBj 5AD2P08a3Cwfi1ESU1fU6p/3Ho/7ff8A+kEDJxr8vb9q6fh5Gydnq2F8TzG7HMcLRSSUCRqNHH/Z FP8A5UdP+8f+8yvep1T/ALj0f9vv/wDSCtJJUkyJ3JPm1fU6p/3Ho/7ff/6QQ7MvqNb6mOxqSbnl jYvdyGus1/QeDFeQ7KWWPqe6ZpeXtjxLXV6/J5SQh9Tqn/cej/t9/wD6QS9Tqn/cej/t9/8A6QVp JJTV9Tqn/cej/t9//pBL1Oqf9x6P+33/APpBWkklNX1Oqf8Acej/ALff/wCkEvU6p/3Ho/7ff/6Q VpJJTRdl9Rbeyg41O+xj3g+u6IYWNP8AgP5YRPU6p/3Ho/7ff/6QRnUsdey8zvrY5gHaHlhP/UBE SU1fU6p/3Ho/7ff/AOkEvU6p/wBx6P8At9//AKQVpJJTV9Tqn/cej/t9/wD6QS9Tqn/cej/t9/8A 6QVpJJTV9Tqn/cej/t9//pBDbl9Rde+gY1O+tjHk+u6IeXtH+A/kFXkNtLG3vvE77GNYR2hheR/1 ZSUh9Tqn/cej/t9//pBL1Oqf9x6P+33/APpBWkklNX1Oqf8Acej/ALff/wCkEvU6p/3Ho/7ff/6Q VpJJTV9Tqn/cej/t9/8A6QS9Tqn/AHHo/wC33/8ApBWkklNGvL6jY+1jcakGl4Y6b3clrbNP0Hg9 E9Tqn/cej/t9/wD6QRq6WVvte2ZueHunxDW16fJgRElNX1Oqf9x6P+33/wDpBYn/ADR6f/5V0f8A sXkf+k10qSBAO4tdGc43wyMb7GnI6b0p3S/U+wYNFPrbfU/WbXTtnb9Ol37xV31Oqf8Acej/ALff /wCkFaSRArZBkZG5Ek9y1fU6p/3Ho/7ff/6QQ6MvqN7C9mNSAHvZre7mtzqz/gPFqvIdNLKWFjJI L3v18bHGw/i5JCH1Oqf9x6P+33/+kFF56jYx1dmLjvY8FrmuucQQdCCDjq4kkpx/2RT/AOU/T/vH /vMrOPTlYrDXi4OJQwncWV2lgniYbjjwV9JKgkykdCSfq1fU6p/3Ho/7ff8A+kEvU6p/3Ho/7ff/ AOkFaSSQixb/ALRi05G3b6zG2bZmNwDolFQ8elmPRXQySypjWNJ5hogSiJKUkkkkpSSSSSlJJJJK UkkkkpSSSSSlJJJJKUkkkkpSSSSSlJJJJKUkkkkpSSSSSlJJJJKUkkkkpSSSSSlJJJJKUkkkkpSS SSSlJJJJKUkkkkpSSSSSlJJJJKUkqGJ1zpWbnXdPxMht+Rjs32hkloG51f042khzSCAdFfSUpJJJ JSkkkklKSQ776sel99zttdYLnugmAPIarP6f9Y+mdQyjh1etTkhnqNpyaLcdz2AwXsF7GbgJ7JKd RJJJJSkkkklKSSQMzMowsd2ReXbGwIYx1jyTwGsrDnOJ8AElJ0ln9M65gdUfbVjmyu/H2m7HyKrK LWh87Xenc1roMcrQSUpJJJJSkkkklKSTEgAkmANSSqPSet9N6zVbd0631q6bPSe7a5o3bWvG3eBI LXAgjQpKb6SSSSlJJJJKUkkqXVOsYPSq6n5Zs/WLPSpZVVZc9z9rrIDKWvd9FhPCSm6kqnTup4/U a3W47LmNY7aRfTbQ6YnRt7GEjzVtJSkkkklKSSSSUpJVOpdVwumVMsy3uBtd6dNVbHW22POu2uqo Oe4wJ0Cfp/UaeoUuupruqDXbHMyKbKHzAP0LmsJGvI0SU2kkkklKSSSSUpJJZeb9YsDCyX411WW6 xkSasPJtZqA7SyqpzTz2KSnUSVPpfVcLq2L9rwnOdTvdXL2PrcHVna8FtjWu0IjhXElKSSSSUpJJ JJSklk531o6VhZFuPZ69rsaDkux8e69lUjf+lfTW9rTt1iZhaVF9ORTXkUPbbTa0PrsYZa5rhLXN I5BCSkiSSSSlJJJJKUkkkkpSSSSSlJJJJKUkkkkpSSSSSlJJJJKUkkkkpSSSSSlJJJJKUkkkkpSS SSSlJJJJKUkkkkpSSSSSlJJJJKUkkkkpSSSSSlJJJJKUkkkkpSSSSSlJiARB1BTpklPPYtVVP14v qqY2utnSMdrGMAa0AZGRoAOF0SwKfqk6rqQ6mesdQsydjKnl7seH1VvNgrcG4w0lx4181vpKUkkk kpSSSSSlLn6Gu6v9Zq+qUiMDpdN2PTd/p7rnM9XZ/IrFcT3JPgtfqWCzqOBfgvtsoZkMNbraXbbG h3O1xBg/JZ/TPq4/prqG1dVzbcbGaGMxLPs4q2gbWtirGY6B5FJTspJJJKUkkkkpSFknIFFhxWsf kBp9Jtri1hd2DnNa4gfIoqq5+D9tpbWL7sV7Hb2XY79jw6C3hwc1wh3DmkeSSnD6Q7KZ9asn9sVN q6nlYbDj/Z3GzH+z0WHcA57WP3h9o3S0doXTLM6f0KnDynZ9+Rdn57q/R+1ZBZubXO7YxtTK2NBO phuvdaaSlJJJJKUkkkkp5362dYwMY4vSczLZhVdQLjk3WODB9nqj1GNc4RusLgz4Ensq/wBTeqdJ y+pddqwciq7dmC2plTgZqGPj1bmx+buELqlUwum0YV2ZdU57nZ932i0OIIDvTZVDYA0iscpKbaSS SSlJJJJKUsvrfTM3Ofg3YN9WPkYGQb2m6t1rDNVtBaWssqP+E/eWoqfUen25jWejmZGDZXMWY5Zq DE7mWssYePDRJTU6R1TOt6hl9J6kyoZeGyq31sfcKrK7t4adj5cxwNZkSfitdUOmdHxunOuua+zI y8otOTl3kOts2DawHaGtAb2a0AK+kpSSSSSlJJJJKeX6k7qNv14xqMQVVur6XdZRkXg2Ma599TLf 0TCxxdAZrvGhK0uh9TzMq/qGBntr+19MtZVZbSHNrsFlTL2uDHlxbo+CNxRup9Hrz7acll9uHmY4 c2nKx9m8MfG9hFrHsc120aFqn0zpeP02uxtTn3W3v9XIyLiHWW2QGbnloaOGgQAAElN1JJJJSkkk klKWZ9Yuo3dP6VbbjAOzbdtGEwyQ6+0+nVIGsAmT5Baap5fS8fMzcLMuc8u6e59lNQI9M2Pb6e9w iSWtJ269/gkpXR+m1dK6Zj9PqJcKGBrnn6T3n3Psce7nuJcT4q4kkkpSSSSSlJJJJKeLvb1t2T1d /wBWdl2DkXuGf6haLRkNbXTf9in2OcGMiLYG/vGi6ToD+nWdEwXdLn7B6FYxt07hWGhrQ6dZEaqq /wCrLG5F1uF1DLwKsqw25GNjmr03WO+m8erVY5hf+dtcPHlaeDhY3T8OnBxGenj4zBXUySYa0QNT qUlJ0kkklKSSSSUpJJJJSkkkklKSSSSUpJJJJSkkkklKSSSSUpJJJJSkkkklKSSSSUpJJJJSkkkk lKSSSSUpJJJJSkkkklKSSSSUpJJJJSkkkklKSSSSUpJJJJSkkkklKSSSSUpJJJJSkkkklKSSSSUp JJJJSkkkklKSSSSUpJJJJSkkkklKSSSSUpJJJJSkkkklKSSSSUpJJJJSkkkklKSSSSUpJJJJSkkk klKSSSSUpJJJJSkkkklKSSSSUpJJJJSkkkklKSSSSUpJJJJSkkkklKSSSSUpJJJJSkkkklKSSSSU pJJJJSkkkklKSSSSUpJJJJSkkkklKSSSSUpJJJJSkkkklKSSSSUpJJJJSkkkklKSSSSUpJJJJSkk kklKSSSSUpJJJJSkkkklKSSSSUpJJJJSkkkklKSSSSUpJJJJSkkkklKSSSSUpJJJJSkkkklOQ/62 /Vat7q7Or4bHsJa5rr6wQRoQRuRKvrL0O/MxMKjMrvu6g2x+J6R3ssFU+pFjZb7dp7rkvrR0PorP rv8AVmlnT8VtWW/LOVWKaw20hjXA2DbD4JnVQ+suBbj/AF6+reF0EY/TrBRliiKh6Ve5ljnuFTNg Jgkjz5SU+hpLgK/rL9YsXo/1ow8zKbkdU+r4aac9tTGb23NLmE1QWS3b4ferQ+sHX+l/VTL+tnVL 68pmVRj34GBXWGNoN0NaHWaOfPqNLp8DCSntUlwXRvrR1U9Z6dQc6zq1HUNzcxjsKzFGM/bvY6p5 pZuZPtO5xKn9aeudXwbs/IwvrDjVv6e02DpDMVtpIAlrbrt5c1zvkkp7pUsTrHT83Ozen41u/K6c axls2uGw2guZ7nAAyAeFymT9ZOv9a6h0fpHRr6+lXZ/TWdUy8p1YvLG2Aba6m2e068z2S+ogzh9a /rY3qBrdltfhi19IIY4hloDgHajcNY7JKeuf1Xpleczp1mXSzOtG6vFc9otcNTLWTJ+iVM52GMwY BvrGYa/WGPuHqGudu/ZztnSV539bum3dR+ueZ9gBHV8Dp1HUOnvH7+Pc7dXyPph8Kx0HrlPX/r70 3qtIDftHQj6jBPssbkWNsZrHDgUlPoaS43E+sPV7fqR1jqz7wc7EfmNot2M9oqc4V+3btO3zHxVa 36yfWPIzfqzg4WRVTb1zpvrXWWVh7G2+m291oaIJIDXAN3Aa6pKe7VLqHWOndNuxKc230rM+4Y+M Icd1juGy0GJ81xeNn/X/ADMbrGEzqWLTkdDse05ooBffDPUY3Yf0dYjk7Tz5San1l6ln9X6T9Suo N9OvPys6h7S4E1C4loDi0Gdu7WJSU+mJLh6PrJ13oPWuo9L69ks6pXR06zqtF9dTaHAVkg07G6QY MEmfNZuD9des2Dp/UG5r8x+ZdW3K6S3CsZVVTYY3VZPo+5zOZL4OqSn0pJcV1Tqn1ozPrjlfVvpG bXg1txK8puQ+ptprDXbXhjXD3F5e0e7gDTVdoJgTqe5SUukkkkpSSSSSlJJJJKUkkkkpSSSSSlJJ JJKUkkkkpSSSSSlJJJJKUkkkkpSSSSSlJJJJKUkkkkpSSSSSlJJJJKUkkkkpSSSSSlJJJJKUkkkk pSSSSSlJJJJKUkkkkpSSSSSlJJJJKUkkkkpSSSSSlJJJJKUkkkkpSSSSSlJJJJKUkkkkpSSSSSlJ JJJKUkkkkpSSSSSlJJJJKUkkkkpSSSSSlJJJJKcbqv1d/aPXukdY+0el+yDcfR2bvU9Zob9LcNsR 4FLO+rjcz6zdN6+cgsPTK7qxj7J3m5rmTv3aRu8FspJKeXyfqT67/rG77Zt/5xtpbHpT6Potc2f5 z3zu8loXfVrDyfquz6t5TnWY7MavFNoADv0TWtZYAZAILQ5bCSSnC6V0f6yYd1DczrTcvDxxtFIx W12WANLW+pbvdxz7QJKzb/qLllnV8TE6ocbp3Wn2X30+g19jbbR7otc/6BPIifAjldekkp5LK+o+ UG9KyOk9Ud0/qnSsRmAcwUtsbbSxobDqnuga6jUq79W/qq7oXUOqZz86zOf1U0uebWgPDqg8OJcD B3F+gDQGjRdAkkpx6/q+1n1qs+sfrkuswxhDH26ACwWl+/drxEQs3pH1Cw+kfWvK+sOJkEV5THt+ xbNGvtc17nCzdxI+jtXVJJKeJt/xd5rq+pYFPXLqOj9RfbcMJtTSW226627g4sDvzBE9+86dP1OZ T1PoOeMokdAxDiMr2fzs1ehvLt3t01iCujSSU42F9XfstvWbPtG/9s2GyNkelNfpR9I7vHss2/6h tv6T0Tpxz31nobvUZkV1gPc9oOxzQ5zg3a6Ha7l1aSSnl+l/UuxmZmdQ6/nnrObm4xwi81NoY3Hd 9JgrrJEnxUuk/Vr6wdKZj4NHXN3S8VzfTpdjMN5qaZ9I3b4jtOyYXTJJKcan6uNq+tl/1k+0Euvx BhjG2QAA5ry/fu1+jxC2UkklKSSSSUpJJJJSkkkklKSSSSUpJJJJSkkkklKSSSSUpJJJJSkkkklK SSSSUpJJJJSkkkklKSSSSUpJJJJSkkkklKSSSSUpJJJJSkkkklKSSSSUpJJJJSkkkklKSSSSUpJJ JJSkkkklKSSSSUpJJJJSkkkklKSSSSUpJJJJSkkkklKSSSSUpJJJJSkkkklKSSSSUpJJJJSkkkkl KSSSSUpJJJJSkkkklKSSSSUpJJJJSkkkklKSSSSUpJJJJSkkkklKSSSSUpJJJJSkkkklKSSSSUpJ JJJSkkkklKSSSSUpJJJJSkkkklKSSSSUpJJJJSkkkklKSSSSUpJJJJSkkkklKSSSSUpJJJJSkkkk lKSSSSUpJJJJSkkkklKSSSSUpJJJJSkkkklKSSSSUpJfKqSSn6qSXyqkkp+qkl8qpJKfqpJfKqSS n6qSXyqkkp+qkl8qpJKfqpJfKqSSn6qSXyqkkp+qkl8qpJKfqpJfKqSSn6qSXyqkkp+qkl8qpJKf qpJfKqSSn6qSXyqkkp+qkl8qpJKfqpJfKqSSn6qSXyqkkp+qkl8qpJKfqpJfKqSSn6qSXyqkkp+q kl8qpJKfqpJfKqSSn6qSXyqkkp+qkl8qpJKfqpJfKqSSn6qSXyqkkp+qkl8qpJKfqpJfKqSSn6qS Xyqkkp+qkl8qpJKfqpJfKqSSn6qSXyqkkp+qkl8qpJKfqpJfKqSSn6qSXyqkkp+qkl8qpJKfqpJf KqSSn6qSXyqkkp+qkl8qpJKfqpJfKqSSn6qSXyqkkp+qkl8qpJKfqpJfKqSSn6qSXyqkkp+qkl8q pJKfqpJfKqSSn6qSXyqkkp+qkl8qpJKf/9kKDWVuZHN0cmVhbQ1lbmRvYmoNMiAwIG9iag08PCAv Rm9udEZpbGUzIDExMyAwIFIgL0NoYXJTZXQgKC9BL2YvaS9uL3QveS9oeXBoZW4vYS93L3IvZS9z cGFjZS9EL20vYy9QL2cvUy9oL2QvdS9sL28vVi9NL3MvRi9vbmUvcGVyaW9kL0wvdHdvL0MvYi92 L3ovVC9rL3RocmVlL3AvVS9xL2ZvdXIvZml2ZS9xdW90ZXJpZ2h0L0IvTy9zaXgvUi9FL3NldmVu L2VpZ2h0L0kvbmluZS94KSAvQ2FwSGVpZ2h0IDcxNSAvQXNjZW50IDcxNSAvRmxhZ3MgNCAvSXRh bGljQW5nbGUgMCAvRGVzY2VudCAtMjA5IC9YSGVpZ2h0IDUxOCAvRm9udE5hbWUgL0JOTElDRitB cmlhbE1UIC9Gb250QkJveA1bIC02NjUgLTMyNSAyMDAwIDEwMDYNXSAvVHlwZSAvRm9udERlc2Ny aXB0b3IgL1N0ZW1WIDANPj4NZW5kb2JqDTMgMCBvYmoNWyAvSW5kZXhlZCAxMjQgMCBSIDUyIDEy NiAwIFINXQ1lbmRvYmoNNCAwIG9iag08PCAvRmlsdGVyIC9GbGF0ZURlY29kZSAvTGVuZ3RoIDI2 Mw0+Pg1zdHJlYW0KeJx9UD1vgzAQ3fkVb+iQDoA/MaxJGJiqqB66IkJSKrCbiAz9Sf2XPQOqItFU Psl3fvfuPR8O0SW6QCuGcKSGzGAkQzMgfesY9h7UgnzGBYVhUCtcsLlBTSFWuF7mM8qm6yGugod/ cGnW/K2NqMjBGewppMWS8onFwRVPdAFD3uwQbYQ7oirLEpUb26urx867usfOu1N7bV3Twjvsen87 0tvweRs7d4Ztm3fne3/+Qk3816YLnc/2Y9bO7/XIrtKTVGHymMUmK3SsJBOxSsnZk8gSWsM3LYqq 4CSMuSPLmbx/qegjCeesSCc75CYJnETzv4Ul+1UWSoSe0j5eP1/2d4h+AGAaeYoNZW5kc3RyZWFt DWVuZG9iag01IDAgb2JqDVsgL0luZGV4ZWQgMTI0IDAgUiAwIDEyOCAwIFINXQ1lbmRvYmoNNiAw IG9iag08PCAvRmlsdGVyIC9GbGF0ZURlY29kZSAvTGVuZ3RoIDEwNTMyDT4+DXN0cmVhbQpIiYxX XW/byA5996+YRwmoFc3o+761aXc3F+1NsXXSCyz2QbGcRKg/srac3PbXX/KQIym20xQGLGmGw+Fw yMPDfyZnv39JzN1uYk1MP2tsVCSWPqKyyMvMzFeTsz8Xy7prHxfnm+Vm264W3badm207OTvf5Wa+ m8RYupuvJ+9m9DHbTuIojsvCzOb8lsWZmT1Nzn5zpH52O7E0VspueMtSU1gbWWdmq8lfwX04tVmU BN/DLI+K4CFMHD0W4TSmwa1OzkOX0Gi9XO7CNKY3021E0LShS+m5VslHGdbZb2EJZVhtbmVwLypo RVoMurtW13hNfqd+A/kMp4mNyuA6tGzuJ//AZGQuREcna8xKt67lcahaxbwLFiEZRMN3Ir2XB7ki xxrs5DWHf5vZvycfZrgDdr9439mSnU/uTRMz+3js/CSqyqpyJq+qKKvKLJdbuCTtwRf+M/f8X4fT EluqpwNzw/90nJROhZGmDcuAXRq0fMqgCYteWIY7HBDHy3EJOrFfs3b2O44TwPPBuiZ9S/Z20HEw BG/oggLzRL5SFS2W3BuSa9mFh17IKpz9xSOXZRQXhQ88KKOIwpkaWMfBx3eVIvDYC84FU9ruEefZ 0lu3pz++TjX1B947PUIUupKsslnwTt0lFxe0zYIH8C7nGps+Hd1gVlk+RXzq9px1UZ5UcXp4lutP n8h40k120zYbfn3YkKW7Bf8Zuk5bHbhL0zXJXokY2qzIoyzL8lIztuXru9Orpf8FH3jHzkHAcNiW bAlfLY+s796ElqJiahE+Oi9TkIIukXliN93rWkRJUvGVY82KRxCa3xa8eodgu9sfGHBJb18wNZdY ptm1wWMpcV2Si9iUm1DMp0XbPb+vj+7Fcoqwp6xzee8p+5Kr8oxcmrhEXNXS+ZIq4iy61zcgAryA KMNYG8Y0tL5jcInJtJK+bvFvfpArEiwjY/J+hchENFmw9q8LM69VcrnUF9qTXJiUETtqCjl9zsWG wSToXj3fChbe18CmYeNGJp/8btvnOrDIz+lu+mifj3Z+t0YOehSbcL57NTYpvTNri0oc/hj6wJH4 6/h1r0YRvCAX+e0HRwPGun4MMSERadi6QIORIrDlYqHBKALrIfTx13BUGZlEqG2bJ4GT3hjIGbyy 8P6BUjR9ZikCmvCBM2GQG29b+wCW+QuYjLUIY8T39BhbNIZjF/sYttVLHk1d5BLnCoWWGUMhX+1f pJuelk5BF5aGU773v2VQ7z2P4ECqgRwpkDNvP72fitD1gYpspCITFZ1utoCqOf7vRZr0ZjlCH59L ldTPO931O/lKMsNWR3USThBykio5cXJ4h5M7F/mC6FhDHLiD9R9paXa4NK+YzYxXH5Xn1OoFxFKk ThhAIEsXMNZyTse3FB6upAcBOf03hBSWK+uXOb7vdXi/pFIFqSlxq4oW8fAJMEu1ymQ2/SlLy/PI kUfoo/TGTOFoSfiU81YGWsnkVNElFXTJFV1SQQausCK+1+dSVy22OmBaHVE1HjJJxDQLFWJUzBVg SBcHQRqlwbEJ2HMwgbGp2TOTGu0cDoiqgKx4TV//FUULOcv6VOm0WfYKOtF1u5JeiGu5oudaTV+u pJCOkKTxSeALFEbXAxRo1ejB5GEYwIKHzTAANQpsBDPrAZo8XmTssJJBnvFqXJAN9NzChvPPJHMl 9KVEZhE6XUAHli96lYJLLxAbZ1+rnt5dJbHgLKeuBO7q2ELQmgUzzCOaw38bBVka7IQq4n/DJBF4 FBgI36LUn7P05ys+3E5g9Fa81Gs215+ENHGtZNx/NtuE/Q5rfr0T2jPN/O6QNV9p5Qd8X7D63//g DWenXNSnpU3zV2KKyGzl6Elo4ZI0V5Cufdw2yA/jk/WtRPFnedDVIUm+ftAMuFCx32X+jxCIOhuS Cd8+ueo11bhpgtyUPNzgf5xBBDqjtFUF95KNtSZrjyBG1ouucbp789XuK1FjOo8Qqz6Dhegcom3V o60j5l+92BbAkzn1U7ZnbNSQZIyrsLVCM8BnCi3D6cEk9WtA2UaE6Nb5c6VrWhFeqzB3dSkQumKF 1L+wyjfc31jo1EVTS4YxhqbDqGF/oOeBGbVo9hRSbYHkUue6llqWBNuJrH7Wy/3YDCaQbJtE5sHh ZOE5BN+GtqDHZ7V6tExPu/aWnu5L48LHtS1PEw9/HfSSJmmhjU1907dN6LDIfMlxl2pHidaMjkX9 FRvmqCts8N5hnnu2VavETtpQhlJuHp81p2mBxoRu73/o9VY8uV+hizgnHZ/ZhCtpOhlboXI1amph Hu92Qu9x7XBF+goaen+Qwyvbs7EGuDz0QYLZiskz/uhbMsqLazJnQG/zsB1o7qg9A3R/5xJh2h7F G7wOdLqBxkYk1qMKdYvHXvSZb2IQyPC/BBaPykGmIZGmv4h1SRxR01tqhr5jwpcFl5dfhJlmCMeY GeQV40EW/Of9B535U2R7gcvrgxkN4SLKlLdmwltp5kJo6XsGryz4CBm/OqKYgNRWFzFf7Ze2KtVh jdnJs4ZIv8tOt7mV5+a5PiNrvKaVPimwcY7jAlL0BaT4KdoRRJV5lWi7BLpUKCMqtEUrhD4VwUKn 36DNpEB+YiBOlFYVgP/E61hQJvJnrTq8zr3qAqwUgadyhZaVQkA80apQULKu9c1v7ytDL0ocoJQV UOSt3vhRyLbE7pJ+E2oLHH1G/iSzA5V+1UICYvhUGzpo8zstly/iHPn4Z+6Pi4jArcq8+z2urYBL VOEUUnbSzHH2cSkQrMOg2XocI7CCsYpu1K2McO4OGT9GpqkgAv2P8IwaS9FKXgeds3TWmnV3YhEW Q81LxI7PG5/KX5cVlOQJ4dvBsa80QTkJc0nOw8Jh7S9y67TKotLlmZLFJ8VehvCevt0bZcL0rYRP qOPDZiejnfqUg23E4CCqmCHGRmHKOOsZKcR2WAfZ6xG1NCIiLPJRKGOpbFQY43rQMZBcEcINTssT 9dQnumPGciLSeseUaZTE5HnlNXyRyD8mxZE3+Ek+WoroGxGowxgIgED/FopoOay/oCwrCBUJCQpC RcdJ/QFikXn3Eve3SfVimNicFLokyQ9N9givrZlen/jT7B70yogY8R3LdE2WLkXA9wll3wv0/J1d LNf8XQq6tADPhZ55/hfisCDvlEmuRUr2BGwHhx3L47h9GKLhoM9Bz3AGqUvP9HSOz64NiSigCERj xnl0qRjgHSFHrEfbier3H2nNB48KtGYcuhobLtXw/SYNYymKj5Gg0mu2+S/2eGluI0ctXinu2ofs JmRcEgc3fKnfGZtgd0G75sqBqc6y/zL4gY/DEE/emod8+WPJGy9ldryo87ldoNQGhmmED7ECPNxx ZcPNkJNY4T2UVbjGAltTDdddd4DpNixEM1a3kFvqf/HzPi/9RXxLqQ4lFdNFdtQNeqWFNFRSnFKy NZYuS9onfDV7siNDk9RoN6VNW4t534SpCt/jLfWJeplrvUy1QRh2kLar3qpm/6yh2veidzq6OGjX /HzX939FhCCEJad7PzWTy5Qe5udyJyh3onTzRU8nZeSsZ5nCZ/dIJvMPKC4YMP+nY6Lc8/EFB+zW s++MXelp9YhxC4/eDiS9MTci9Iyd43VEzG9gQSfZR1y2Yi+ijnG6NkCU0d5z/uuO+PeYqMTpKw1Z 7xeXR0QYi6p3jKcf4Cd1127CLFfagc5Kep/2AayBK0zQjnoi6Z/GPRIfYc6d0nYYaAbMh2zf5wkb omqDVo8jqjp13Xy4s99SQzB0O7FODuboVCYlMuIUdxx3TnGQHKz/P+NVstzGkUTv/oo6AhEi3NXV q2+SZ7xEiGHHUJYdMZpDE2gQCGLRkABp6SvmkyfzvazuxkKIFxS6lsysrFzeey9H8+OjRS1N9+D0 iW9DFp1bFC8YUBbq3KGUt2PE8410MRkXLQZN39TLn+XmTkKdSYZUXApGSwfjD7bc8HNqAty1ckKk u0eaY9WGl4LC1xnNTs3so5goikmauSCQK09p/K/oCQjKYCEwiIarsVJI7bgP2nL3fEKg1K8EmRY7 ijDaXgTPWNJEiLxZY1NW2iaEhYDHzNAyImgQUupC/EdgVQaGBwLX0ivl/40G6JvxKQZNQDmJ6svy deU6VIr0q7yge5op6cV/QU32RpBIJQQ56X11Clhbxhm+kDLYQgaDpQWX7IsyHknH7o2G4ZBrbIsN HUm6JQOiDaQzxn1MjLpABZjJDQca6GzPNBpDoSZgZreDglUkabvjvZmQACmVUIIasOWJKNw+11HA mRqe5HV6sYgHgWFZWXoLzx9/l4f/Qx8btXqGsnpYJwuW2b5aa0lIFUdVEhqV+kM2Nrq8YRnGSYff p9ZAWJoN6/2saw+QzWo+KOE4O3O7rt5TGpTApIVD8V5EU6WzYHFGdHYUpmVM3zKpL3unkM6R54VV HnG4n1RMp0mqLbWcgBkKpQI3nOgl8KXJo3vtyEM8stZ4Uu/Jk+G2icwur8ZBW9SOswuIjUdaTjYz zD5Si7OtDQWY0ntseTP22PLMrQuTs5R8Lzrpbn0ggCdFVXp4hUTGPdaE8JDi7M0O7LETzq45p+yX WE2SZa+Eu0FQXBZCauBiCLUHsB6Ifi8TUpCU02DSDZlCRBuRqjySxkiMVobUQQUeIxe4cc8UuiL4 cAjjIe3sOjLZApXdt9akO0VuPVi+66hVY5WYRTf4s0mb5q9EGkEQmEDk0pKXKdAnq4vZHEZXt0ib /cautTNjmHT3SHac+XtKGqA0jOhpPo6wicnlVl0WMsWWSOk75nrD2gBqKYKoL8rMtf14YBxxKC1d MoclYRdn4H9M1DStXxs5gr6KkKalNRRAae2qAlZHW/wubW6GL0HAiF23tmmkRGWoWytUCJq571Pw JElTFHzfiZ4ubCcyVXM8KgC47oaWcvFVGlMQtb+MkZ5brj630WD54zPWAUgX14UJ8bMo33VKH460 98pZcbi/cdNFA/v7m921cMBJedSWQVSWlpfLo4jzSV1Z/EmLzkXexgxXBBrgbkw/2LREqXztudbg Y8UdS3x85QdhcjmQN1GAJ+Z+sA3YLbcsUb/klvKlzZiL+O5MIexdL227De49d6fczff1bNpRgVRN ddLCJLW21Ua7YtvfPLD0Zv70UGfNz1S/57QkRtLbtKOoC7lQZ8XlV0nCJK/KYE3rN0bfDQc3s0Rg KLQWmy7GBDNk59gdYkowpkopZJW9ZM5EiV0MY8u8cH1srk3OMoqPW6nGmbZxQmcN4zgqIc2tjOZW pK8V6WvaZ9GframK5/YQvXHW/XbHSXrs3zTU5t+g7eob2NWndeHSOp0kRa4cQB19Y+XhAwpKPfrX P+3PW1u4ttHdtnoJUNKsREG5qmRYcBCnS6MmgJHhAS6rR/cSVVLu9S0gdUcZC5MBDIWF+dzEP9jS kTY5KNuPpMexMSFf7C0fzeYo/KuNLY/HZfdpZAK8jfGy7+z7i9Wt4fmqO6/FLT8hppNQ1K9ADHyM KpnkmeAGPkZAc7lGo32H/1+sQ+faiq5oegHFBbxBB0lXcPk1EMW7eAJw44rGFnKHT2O7k9bakFqT c7db7l04CtpyuMLqU0TSmWHcvXXgzKA0RX1VOxr83fWzKqmy8qSNlc85o9pDj+V5XX8zetOQZC4t avmXJjkd9kRVnYXyf09DXmVeFgEE/w+vuyV+WhswoaMpQe2XqDY5EKmoIEUVsa8MnbNmMFamfR1f pY61fbOXuSoZ3WKSmt12fpYU+Rc5UQiylkrbyZOk8Mec6Hs16aN8yZS8BScl9KtPYzeAO7OIOo24 rDvA9GCRqLZ9GvmfRVQXZdicIaeqEQQaOnM4BMgEcauOfg32nGA/81UV7QgnydXzoLpKvuGRTJKz rL2BqgVRf3PAU2acfNY81zV8DUgMeMJnjiuEchp3GQ06T5nWE+Mz/+goB5pOs+SflU2QH7nZGSYz PTTGDn7GTsCMfMDqIvvpKA3RIVxrc3u7+Fmy43NvYVZX/rJXQzbJ8rI0ktP+/VliVyiXN8yntT5h Q0Axbjeal9oDmpVNRdrBdXWjJ8D03azg8goFV0UpofFh1EQFrbvD6tI2P9leCNrYJihZdl83lN9O o4Z4eIvDG/zSXzn+s0l7a9KZtWiPFl33WgBYa0MVvr818/u0YWfWr8v6spfl7etQpHUkSVo5WEXY Au459PXbaoeaujmt5WrMaTUXgXlxVCpj32A9oNjtY2SAkZ0etJ6/jBnGQir3jzpvhzajyM2MjMbW xBY3VIBtrJUTNroz5dAH779NOOlL7yeFRKxByz87Xuf2+quRZ9+/jTXB5B8ijdUPTHLZVS+QTJaw je6c4aDctpbb/jW2orWxxJOfzxY8WTWQ59y/0/I/jnBl11VaIQLgoFdmBmIViNuKMLUflE0tkaCq DTnp0dIRNEn9t5EJnZaoj/Ngab62GGHhfhxHpTB7PyaeyAve5REdBjdoH0RwopuSZHhis4uy5Ik9 gioIBj1qBzo5uLhu3+MV4AG37JXp0qJ3+vO4RzgqZKn7NyetpIo1bwDYLsIPX1WTwofK0vInFbu8 U7PGhCGIctXqebWMVDaTuzGbuCHEadRvnl7fslnyznq/rU7McT9hAlUvX2rhDM+ATIIgXW84Me/k CKNLEJxBEFg7pzgyO20vYbSTE8EKn+7Zmt9UzBR5jm3R7qw8ace5z18ZUb4sxdM+M+IBWqtvqiZC F5TvgRp3WHszThPtBDq9gxue9HcZy7GEGzwnjUVz9CsM3uE/L+KkVufstdq1w2j2OLaQkPkdNrm1 tNJi6Fv3XjelWMT1xQly88PHUwH9FdIzfvGvDKkin+QGUaCNbtB/2mT8gS/woDRkaUbBnCtgsHXL 0syjnXNZZdbbYYjqS65xl+H1v+hfxzfHk7R2QVQd+J2HHq0KQpP6dexF4AoqYOMwjC+A2YtRQ/fo v6zM82NY6/YdWLxDtdBC4k+0PX/3/U8ixX2Yfyc6oSAV6c4rjKHMVE8mo+zo5Hs5mR+fFPqhodwf PunwiSIj3lH/ndVfFnrHgZS3UjwnfDU/CSRLQRqOOKOUV8GX+Fw+lmg18UtKBNbm41y/dggE5qvK ad2vj4/7+IEcD6eA2qpgKDzNTc3coycpBGfKTRSUWic9rGmZ4Tq8v2JOAQEKBVbtkwZDK6+1Alwa HdQURA+6nITQqu1zG8E7KAEIrh2PSY3Lc9uH+bX7WbfvqalmgO6koctwgyw4DtaTdzM3+Kq8nLhS L+tUXk+dmld5QV98vL5+Iw5O0Pc0n14AfmmSQn5yTnYtj+dPZW9n+6kESGnUkShJGejW3S/Rdg2J GSYUArkixyX6mgHXytMbGltFNBkh3JTIRoXPt8ZCbyDrGr8gjlJgfgB/+zDkuGjTxwFlXCKNKPfl NDdn1sKVJP6MuzZa5gmiM/IKaG8kz4XJePUAFpoxmYMgcD+6R7CxBsmfKateA6ZUkBdACtojcD+G KNx9pJgfIeZ3fvwhkaNCmw1mZ1Rh2hd2sh33pGZgeTiwHCfjzkuqjnwpvnlNMAosCT4rrI2wDrN1 7fpWCFY4GrQBJxZAP7RLAdXwPUhqaRODxjjv0nAw+QYg51AS+9Ryhb7sIq7JDJoIhJNSwF6zR0Nm FZBcr861uDNkNWeAFVmRn6VR5haps2UdUsOwZHwE/DKozROD+jK2M3zGTTuJrdxoY85oytUs7lWq qdife/c2rri55WYVXMj4PwRBrzbyUkzu7GgLdcez0ZgtTIurSopU0C8aObqoR587QTDtqbXN8Xr/ p7xamtvGkfDdvwJHq8pmiDdw3PVsUls1M8msk8xZlmxZFYlKLCmp7K/ffoESRRkbHSQSYL/Q6P66 +0aYljs1m3bYrLtesJy1d7NmV6pb16QAOKTgMzydmq1HaMnt322AcdWcHcOsjk10Ad6ixmGtL+Xz JfXn2x3fNcREt9jDHlw/BcUzzYif7/D/wycaEiF+ZDjDOASuNcexiKKvTxOKzCRk+NbR2w7e1Oc/ tgLTUmiEBKqkDHhH5sBvUWYIJ1vIQEtWPZ1E2fzJvdb52qqNreYxOckGaC/grnIPhAgU18PUkp6f j2v1sAZOCVoAtN3hgGW86ORE1MVxe4iDi6L2rzsaOLrhkHKinys46yOa3ZLbTtiPAGA885yCyDiF jdQIrgzjFO49AtDWxh7a1nh5hN4QTFlyDJGVphi5XVfgGLsF/q5eZTRcE0Dr0e43HErhZS9PIAsN VUuLwnesboxL5VDGvFrjnfNNyjgQnRxty9muJftRecLa0e+ihYVmQ986Sm447LJ/2z3LW6EE2IHG jUNGyiSKaY/Y57QHN2cieQ4pzfXfy9056I3S3eajPulsbe9vEFDYe4MuwWOKgdDMFKsjw6sVrIIv fObIkAk9b7fgF8WVt7ChgyyFBBI/0OqxCFEbWj/Rv5rxqteAKNnLv6GTx6OYYfvKDHbEsSAxxb7d Ul6+s26mUWW3WPZ1wDTbDU3rFS77UwOun+vTy2DR2mrGwEDZmhylSRdpy91+it0TJix1RFbqSeQC TebTLcw2vKS05kmDzFnL/ouwCbmS74/lDvFQGF88yTZWrknIqHhV2m8b49nDwdCTI2UNFHcPQ5YU 9X+sCGUQ3J8PdWFPYyG+8aZ6t+cWN2K9AdR7f0/9CC24CixJzneuHkCmdoKsCIxrHjXh9QvLSRIs rPZQbKKQzXFz2w9F/HmPsjrqoY8KShrddIhGUkun12sqXrUzjTEpSWqRUj4HVcGncuaDdR2XOKyE x4VVauIdjy6FWOSVmqi2M6w4z33RpO/k2JVAPRckkD4jh6E+vGucShOkAaYsIhliqdoeVXDUNrRI lQp8BoJKHpj6pNZ7yUJWQsSkAQBZyTfLKACBjNAYKXSjpL0laIw0chHpRpZFBAV9xBwgEVMhW8vz kWQpJrqjvLE4TCHtJ8wH+PgiovYkulNC9W0PaGIxi/aPsqWmhfaBLd2V9fRFSMqRVvL8iRkYBdqt tIwCZrY/5IyXjzeFrBz3B5NvxlDkeigKVSzSUF+Sz04GWTTHCYKEAimHDXKnk/YG23PH45HD3kPD 45b61QfmEuY90XUiYk4rlkCDGvYhaaDDRVhOmXDL4tVu+oXW8lX498W8Yw1bnNSQRfSrIlmoCx2M M20v6gczsSnLGZ+TV2rd66bdIn/gc+krvEtVd7exCcFJg/075pfBnpiDCkdCWEwxy2aCjTR8EQXo JhjjHQQPxq2y3jLUmYDdEs+F5RPGKsjodgIFCZvhhFGnAXr/3SlSOUeB2KkjnlCLDW8b6kZvmPJu oNIzhzAgqKAJAEH5YDjc937FKAfbL+M4NX2cVh0HPTeiSBvYc3RbBgdYrm6G76Z/fJm01FIhxtEG 33nikDQceIYaYNwVLgwjc+jL8cue6btuymoeeL0i+cJGPT0874j9Ay8+sYWqWLorukj885JoFyzt YAbEtul1E+VXJil7y01ZJ5L6EzuFg5qTA3XihldKuba56vPkmmB0KH1hX8GpGKwO1XfWF98V1oOj KnG+tn7ryxIWqb7wq8MAN4Plqnyb952BktGodBHqn/j//v39xzIecXkEHaT+z9/+RR/+wzPZaxiZ AQBz3RUROvW21ekw9jVjAERUaNTHZ95YYhkJPYBxZ7xeLo4hazpBHoHBJS02Q5BSAkz8ccWUK1oo gdkCyq+B9dPZbcQEkgyogKasKJRcr/B5SN7bU1B1N+UPYtLIu+hQzmxTnR990I2PKUoF6qgXwdnK 4gi3fuAntbo0/9FXuGnapqNlysAIz7sJNKF4IbigigTflltek3/skRCQ6XF/x89n2Z6yqo6JS6k7 I7hR7/mt2Dxjzlfkgh3M94WELflrR4s5/VePcabamGjP9+LFtR6WELrs2SV3vAmb5YLuC8rPaY/g B1RXux791YY76dvU47rNUgbU3QeQ+GliTemieH9Pmaqk8OypEkgRkaqHzINy5wfl7seEW36sVwQs mNQPk0M5PE3mEm3uF4ZeF+DNW2hVrEtSjNcYJ5SuPDlho4IWGh6TrtdfEZDoy47+MWES3Cv2bqcj AhmDhkB3ZUg7vXhggAbBZttIIRtjM14pnUQ76Z6d0XSUN2+1gpenE6HWhaaNOQZlU9sEm31k2W9x 0sA+dAG3EWQwNDwY0sCom/NGj3yWdANgSeLdqd3frjSTKhghgvVJwTE8vDg1W1/dls2Yjeyur7AL 0hZmo6Pd1dEuqDG817Mftp6v/r7qrt68u/dqse11HxH2ut/cbYO6u79qieb+7k9MmZTUDzwtOPLl soMCk0Gm9mxYQa10MWc/YP79mHnEkmH20Blu+ZjF1Fmg2DtjX7dwzAExorMeHuquxuJaCA6o+mHA Mq2yaPRbqwccszoHzDEQq0O7nqssAC+hNW7o4sc6S2pScjb+usMANprok04DlnWVxWHapTB02LLO YhtvYFoYsGzrLLlpHYDWBSzeNQA52l7gsYAPneMFWoJvfI6xkjdjFsDBGIcO21Q5IuaXNwOOrsqR ML1s1BeYlWwD2BGGh3+os2Q4/Ild9ZNkdJeOecCyq7OkJjuI419PFt9CJ+J8a3799B7wN5kTu6ou 9hpGUuP9rx/eG3gE115wjx5rlXZhyHI7YIFqb/JZWA4OmTMEQSAgLLXx+0nlO8eam2RT9Kes1cS2 EQoszEz2lOulzhWgbGGZP+GqhoWN0CbqMxbuq1wpNNpHhPchVxXhbdZNSGMDV3Umh9U4p8tcmGNj WoelYcj133rVMk3KbXvZsRzEfAwpjiys5yOUO20cdCqXnMtBtsRAAD7kqsOFoaY2nzLVsc9gn2Dd 6Lrq8GewnwxmpKvuQgvI3CYz0lW3EGumw6nvhGte5wrA5e0ou+rngsrpzRkLv1e5vIfhybSX5b/z MLNZly/Lfxeg6Yhu5Ix6FAK2pZT1KAqr6e8ixm4KI131SwaACh4nkkvyHxpinLDshS5MpoH20Ixc WM//BLNYa8a66ueC+SMn3Y7O9X/qMUBo69OIq34urOLpDFzXKyYW8gRevCi9PDwymDnCmkOi/NXP UDJ5GseDp4UOG4bAN28NT5sjfLatsh77Vxb5cXJrzfVGPcB46RL4AJfzxePk1kfQZyw48zZBu4Jf YTdfqy0MooHf10Q+xdcO/4DWRREyI+LFlBZf1cOjEMDqR5EgIjuSrt7R9h53YNu4a9bEPOo9Le7p Xx1UzmHDDyEE/dEmzw7BugwO0ejHs52CxiKCk6V1BnC3dYk98/mPP27AChhJr9VmoqHvA9PoAa5K uDsxUCHRCmvg+TiBNgCOBoMOfNvOJhGez4OP8/2qX9v2IOkGz6OR4mmiHT+Qaim7RcWSZO5k9+fE QoZCMwUy3HWRIAaU5cvAAPXbByG/P2sf7e3pf4U30OssFizYAzcTOuSp00sQau/F59D1vubzaHLA cIQ+P7f92AUhwdFAYcdBuZnj+x7/IKic5sih4Gj0IRYgYPBKrjninp44DLujuOZI+olRfUv0UwnH JG8vR2GOoji+Sd1RGmzmvU5YzdVXMfO7ZA/QW3ewb5BAGKu0wQo5wr+MPKnFkSmTI1/3nwaAyDCL CVre6kQxxH9LWnf/Y7zaltu4Yei7v4KP2plkI5LLvTw2TjrT6WXcxm1f8qLIsqxWF1deJ81f9JN7 cACuV5GUeDSz4g0gCAIHhzRH2z2/iByk23iWy3fy2bO/KWrT1qOlKzm9ZdMVWRUHHXKldNdYeUfp RRE6U/wC2zCFYTJ88UF23ptBta1ZYhZnhTNCkEWPovOeivMtcc9QmQA3/SifRcFI5fThm4C5j6dK jkN/NhDbiPCL4JJ1k3xSTz4UEmueCRIqvTdmr4QSbmy7fIEURT5h3VXRTV6+U4H6UEBMHglxaimD Kn0rzZ189hq+XLYRgftBdDGMUem2HxlhAC3bzjRIBRz/gC2XV/j8XghwHkHjEF0NiuA385TuCVI0 U2y8umcuMNXJxaBuT7a4VoCOoDaH3f1KYAIhwBOXnpaXxGq5Z8Apl++t+6jdvPiEdGyPpbdH3bwV bYADQObEBR5//z2w5/Z5r7w877V0/+jMo8ov8v9hXElhaei9s3mp/mqrso4hDLwYRaqMSLxUlw2T SLoz2bKZbFZzbczWUlKaydrWlcdBfaKeA3envnahiahx0zaeINWvvq+MDgSVDVb3XAAXqAx9Y/nF dj9BMB0J4nmCajkWPA6xEDTEpj4E5SPHBsRYttWBHgnaEmHrvrsFvpZBYGlaEr2rklCOl1Hu9brk My4Sfy+1N9Pep9m+CL5kyuDrfhaIKIN1TfJO1aG6dOVJ/BDDQ1kzM478FoQsDH4DgE38s7yHMire G4kfe69Kg/fSWe919N5Iz/VKDpSAFa1yB6MOLes2e+4S0NmN6rkAsydN4PDOiv7alh+VpRQNWVuF jq/yzIBmZlM/WMjn0He9lIoOrYXGvvvXZlr7r3EMDM/2ts5y5E7SPrKgtyXZKYahZZ5bj5TbD9q5 /MVoPxBYL9nVF9PRwkddOLfdz2gD2kj/FmgC2z6ys7KledGh6Mx6a8HqkpSC/ZmdY2v9Y5yJGaWn 8dsonULrvLxRUpuMDWzo2TjZ7FAG1D4crVEQwoYr+gGNmes/FZVYsxO0FHIkrl2b/Ef9W+iguyp8 S/tFYDmec9ezD7pVFnXvJ5y50p2u3xc6X9IZ9eTtbF5UDQbuzDZ3f2irmT7P2/DP7M7mD+c4R0fh yvQMHsBHgG+bsoq19wOjGliafpXjLbeZKbYE91qoSqsJxfeUCrp7/Uf6RTHfH5C/D+tML7sJICRC yRV1HQidk3CrkW3cL/LBpka0T1zWCO0L3UHIrtHY0UPOGYXd2WPrQPdhZPqmyw+q9vyLiuzUN8Ia Rux07JKFWry7dRXJz4/c7DXbn4X99PmsZokQSDvE/Mkl5Egjt9yQYksqTo6I96F3fbJnJlicvCFX X3ht/vRg3ekwXw4S0yKlyt7wi7h+GVK+RDH+LeV0KyOSp56pPlmhRJ30z4jRLgL7fS3kYuCqdKhU N3Gpl9LoblhHV4UUT4WlMCAkTsPZPP5ZUgz1b7G1gX404zUnZf2OKRkM7liNdTn6UnOZhR0DfLSL U1ZVsYMrhsYgl0xVtnWWIFbzrhs5xL2tmtn00voLHutB8i1k/cMh85xouFd92Stz7ebd8jk+0rQF Qqiq86Fbucrky3AClvW+YqzbZ3JnFE3kysCd/5QgurPUq5QMMoEltgT+CH41oY/AR9ije3londA1 LGUTAe/Jqp9L3GXFWcKxCmgNMCHBf+x3IyMIFBsdb4IPEq0Sbh3FjZpbHiuRdf1KH2LMoS95Uznt 2vbr1NhXIBzdQI15JJrEfXs11+mZ1mu3fXJGv7qVP7W/H50U/C43jw/KudlWTBd7F2L9ZuT53v0u e20LBXcJR8EEqVwTyvLDNUjz5nyZST6cPbnCoXD1ZmDoHwoiHRGI309Fxh+F316fVzRK681Si8Ed huiwdmKF5uZmAK7uoFy5XJAkT/wxJBLkdqp9VDZ2iqjO3qYZEpfjupDx2af8fL3k328x4+CZ1Gmr 55RjdRm4RqraaCwy33MlF/oyhz7c0SrlQNiGKaoX42QcOs6ILWPscV4kALKTaWHKPaNh4yyw4dRr OzerRYgWKQ+y2XrG2rSiWi421T/JOEf5+VsCjtutbjTsTnC8zPOnzbexRP0xbRBwdWeU/3UR8GK9 vV3IscXeTgL3GqZ4mZMn7/sCqdxIHGDsjksW0gTUhM5kdtKciw5Oweqon93TGmRkbJiRs/XTnI7q CvGjKNbaPewm9MwiCZgDmZt9tmI62kq87+HQwJobGtN/Ooa+nmddKtM0WXW85r28lispiWmDxn8u vIq7qmxRT1uHbE5oVG6+uUgplB1CFU+tDvNdi+HNRcQzqcHAeHQ9Gk0xwZbA0ScNp0fHGv682MKe EFHLAJG0CoRc2qI71pWtT41X8179sPHuze7iV/y+doxXlw+1u3wn8DStHR48jXxTjO7d5S+Q/IvG B+ygZqam40ETilYVm4PR9WhUjKkQwPn4qmE8enfxDrb9L8AALCm4QQ1lbmRzdHJlYW0NZW5kb2Jq DTcgMCBvYmoNPDwgL1N1YnR5cGUgL1R5cGUxQyAvRmlsdGVyIC9GbGF0ZURlY29kZSAvTGVuZ3Ro IDEwMDMxDT4+DXN0cmVhbQpo3px5eZQb9ZVuG2hVJcN0EogYdxWpIg4hIfAIkxUIDiRAWGyId7u9 994tdau171KpVIukprXVor20taTe1Iu723ZjvGEbGzAQT/ZMCJnhkGTem5cw8/LmlJzqzHk/tSEh THJm5h39oyP96ta93733u/erWtdyw3Ut69ata//mM5uffPTxu3YMDveanum1bRsZ7tRt2f70juaf n2zceqO68Ykbb1l9Vbl0K3Tld1Sr3PoR+d6Pyk98TLj1XuymluvXrWu96VP9X7j//s9/a/sOh773 tntv6+nt+4/WWtaBTwvU0vKhm1uwdS0bkJavt7Q83NLyzVtbHC0tcEvLYEuLraVlpGVdoGXdX93W ckfLZ2/euO4byIGWQy2dtzIt3HWJlpYO4HJLewu67ol1xXXy9fdev+n6qeuPXv+/rv/9DaEb3mzd rbpJ9VXVCagTCsJ74d9+6MCH3vlw64dv/7DwV9ob191o+mvsr+fbdB+55yPMR9d99Icfe/xj373p 0ZsWb9528798vKim1W/fEril8Tcr6/Pt97cT7UL7ZPsyIqGfQ+u3dtz6vU/0YUdw923QbUc+qf/k pQ1XPzV5+2duf+fThTs+f8dbn3n8Mz/57GOf/cmdY5978HPP3nXvXRvveutu4u43/0fynm33HLxn uXH/1Ztvudq6Gvh9K5Rt/Ju60b/6i9V+VdttbY37G3zjbnUqlGA5ChaJqNeN7B/ZtvVx7OBLh7/T 9f1L00cnxqtwuZqcnkXqxKSxjJVN2kQv2tXvM2vxLp318HbEHrHGLFjcktBnBjd27uwa6YF1PZ7u HqQ7Ozitw3Qzxzxn0YU5Lj2D19PzlaX5+sCUqeaG3RM1uobOTSdKNbxWys8mn3Ok1tNmn8PthQmX nbGgZjOXMuPmtKGsm51fmXl+8szk6eJ0SkyLRW4iDOeVTkgZ+YGaLQSlLJLn8pkClk8XxUm0KFHu NJ5xczYzMkzqbSbMZhy2dtlci+Qkk4enVreqKbstYEN7h1I1C26u+qbnkGlxqlDDCrXJylIp3y1p cvqcfvLwsS0avcFp98NtJtmltKmtFVeVqBE1ct6/AvsusK9cQS7HX05dxFIv5k9Wj1QX61NLJbgI fa3/qS0d98EdXzV+/jPIt1JPVDZh1U3z20/sr2uWdSeNcB7SlPXjtgqw+6+N36iLxqwhqU/qEwP8 QTixNbb5W8gm5hnvFozYYttr6DX0aoa6LbAdemP+1Ysn34RP/bzyq3eQv/O+ZryMGS73nz/wvKbe NdkxDluhurlmKhjhNvnbjXNqR9GdJjiYI4gIiZL+AE3jNB2g/Iib82RITKAr1BI1zhZpyW+nbIwt METbWH/Ay5A07Ydpf9BPIf4oxVMYzQuBBCoIkRiPJzkpN15LZ3LpfCrkGiVC/hDFumkLTFkCdjfi jvo4GvMLCTaJCnxU4HFeiCZSSJqpEosYXQwWR6WCJ+dOuQqmrDtJw3QyERRQUYhyHM5xUV5EUkyS EDEiYRC6OVPMGncKOa7IVWLHxJoginBCiCWSiBgQaA7jaH/Uh/p8QYbEfYzLZTZ4XC6PgwiXYhWh CgvVaDGNZAMpWsAEimoeJQN+CqdAlE6EiFkSWoy3xCxjZkfSnnUWAHDd8gtX1HJQDi4pQTnQrQSU QLccUIJQ223y/Xeqy5PNbpiiKs48lnfaBQvqdDM+L074GI8LccW8Aon5xSSbQ+PxsUgc55J8JIqG w6PBCB4JjDEMYvAb7WbMYTY4B32wBTqdWyiVJ0EhLMtb1HL8B0oc9OZbf6/2kSzoR3fMmyAxn5hi M2gmFUuIeEKMpTJIhk35RCxBemNu1O1lfSTe9qDMXN2kVujf72ldVMn01T2tbW//i/rho2f7XkFn 6snxWXy2MrlYOguXXki8+mNEXmd8a89l7Ez3gWoHqh32WXV4r2G4y7wTNu/wPfUw8gXp4bnN2PnG LWr+xezRcg0uSHmxhOazrC+F510ZQ7IXznTwmx9GPk0/6N6OkX0evd0Nu+wOyoH2j4yfdODmC74f /hI5H70gvIi1yR9p/FQtlnKxJMrzITaOx9koFSbhiCc8tA9Rfgd1h0xBCgtQDONnSdYWGhqFHXJE gobHbGEyRsYYLijAQTFUXkAa512Q8pWNrW2NTbJaTblJH0H5KIL1BOGg2zQ6gCoPqfK5U2ffePuF i4vnK2fgzCxfn0VOOJb7Z7G5/oO5nWhHp0s7iA9qrQeob8OSKjlfmKjk4Xx1SphB56c9+gpe1acG O5Ed5mf2P4ntf/KBLyvQBtjRQKHnZHVr22uNivrc7NHaaXS6SlqLeNGa0GsQA2MirJjParcb3OBD GoOwOwNVK6xvHK+QeSLtFUnBIzjghCluNCADxJDRiBmMOq8G9RDhiBenwx7OLtpEIs6E4QjlH6NQ 31rfUqBvSYTgiawP82WnmePoL6/Uzp3AF45Kpy4gS+ScdRKzTg2Vu7LwS6enTj2PTPomrBVsTtcN Yj3cT5hGcJ3RNGg/CLc1bpSD6sajOyHl4uqm1qflGeWRN+RH3r4CrX76Ftkl/6xV+RnUJndcvUut 3KyIL4We98972lfsc/rqAFwdSPV1I53uAR2g9pFBTy9qNPI5E+5O+OJMBI7Q9Jh/zWMKp5mmxy7B I3kwrzRJL6GLRwTpCF5NjWeLxVJRqqSn4PQUNzOHXLKcOXwc6zj9rfqXksffXi/vVx15E+T2vqv3 qQd6aU833u0+PHKo61DX4D7zLti0i9i2Bfn89EMvb8WGpxfdK+hrZyfOLeP1ldzpc8gF5wnNPLag 6ZEOovv3u7T78eRK+og0k5spTdWq1WqtUEvWUnPCsSggYYVRXlLHMqlIEl2etnWV8FJXYt92ZK+v 16LH9GajdwQ12fiMCzcXnVPEPOxbYGankVpkPn4Mm5AKiXQMbltoRNRpBpgv1zLtQrYaXUDlp1TK 3tX/2XpOJeuv3tGaV2So7ReyX20bIXXDSF96cEKL9cydsr2CXjiRq8/jc3Vp8QSyQMwZ65i90ju3 7fi5uYUpqQrnqkKlgiy46ppJbFJzOL0L3XHQNaTBNUPOvsPICK/PGLCMYXbw7OG9A4Nauw7+taxV uzJE1p+D/blALodUxXIREFVxQqyj9Rppz+N5m6gfRAys2WfDSKtxpGcA/kelS51yxK1mROczWe2Y zTpC9qMDulQFzN8KUT+KTHOTqRqWqhUqtdLf7ThxsDwAt73hUb98ITd3Br989PTZ+Vfg+cvSle8j PzNd2X8eW+k5UNqBbtqt39GNaw4492xFtuT21fux/vqS4zl0+bls/TTu3WbaPbhvcN+Apt/eb+8m O0G/Q/KYfFlN2xwBNzpkSE9Ycd2i5+wV5HRisVTFqsVqahKtlJphFGyZkUQ/nOiLDWoRY3CQ6cRc Xgdpo+G2B/9PY+t/mz5HV69T+3ws8YFrkrFE4g/XJH2JD1Dub/4/7vTG6tJ/eYpkUe4/ThF2jP2T KUKAuf/eFJG7pQaqbpSXVssqZd8N176AXxvL8j+rV0uyo/UQ1OhQOlY7lD3NryXZDjptXYORb1an hjizB/Gxfj+F+WkHa2gScFqC9GErB8Z1yjVpP644GyfXO1WKZ/WYbZ99yOVqpygHM8KCk70SpA1b Y34eJnmWTyDJeD5RxY7/tlUWVQozr5YhuShfrxRb2+RXGs83PqkuVMWpOrLonTVMYcapvuLeBMxr D0d3ocqio6KqSLQnhQu+mKELWf0G1Bcw0QTmJGx+PWp0yK+qfniOS8/j8+nJUnEKLk6JM3XkmGth aAozFwezB8TF5FShUIWVX8tGNVedjNbRS8959DP4tD6r6UGMjNlrxQir3W3ywaRpgN2HOpxjYy7c PeYJE2H4wA3CWGIsMwaPpXPPFtATi7R3Gp/xlO1pE5wxc4C7e1yaIQOmHzro3YL29UWFXrwZ1htX H1AHXAxB+WGGoYJ+lPFHOQ9ePrAvuR99ert7aDe+e7j78PAOWLfd/cyTyP2lR1eewR649A9d8nXo pbPp2nH8eG3xWP2iW1zfs6O/X+OA7ZpefyfacShZ7sV7x3V1+3HYfpw8cwn5vvhS4SRWPDkxN1eG S3NLiePomRW3bgFfGJ7cW3gCzqjcsqWZXPm1W+SP//PclVfw8y9P/PhXyBXXpaGzmPZM15HdJbi8 56HEnahSbiKepz3JP0Xchzl8Nv8IQFwlb2001MLCbGwS/cllw66T+KldlUfuRe41PtKxC9u1d7P+ YXRkICZ0ARy4BnoVUs+UQ2wKz9FJkvcKHs7EDcB5FS3f0brKO8ZVtQLjTeACGTV0IquPQNqQJUBi QR9N+ViY9rhB/5scDV51QX6g1aaydlmHbTaXy0U6WZh16oN9qHKDyk6EowxOR9hYiIOD8VFpEpFH 5DugiUKQTuMpRvDHiZg/ao1pYUl2OVShXr/B6YZ9XiPTiyp3yBnQGPvk3wJXZ6tBOotnmbQv4Um6 RTM/BOeuueoDrmYzASqNi0ycjlJwlAybNU14ugNGisRchI3SA1flBcmkcrujvAcHk5AL8HAAbCp1 RO6Vb4RKuSCTwJNrDsFxImo3IJJscagCfX6Tl4AJr40ZQZUb5ZSq2Yq/AjU06gz6AizMBJgggzJE hHPgfWk9b4vCUZslbEKf3ObR7cO3Dh7Yq9kMj+z07NiCfK3y6Kmnsftf+99d8sfR48sxYR5fEBcy CwVYPgTNR8pcCssJEl9Bk5IiOFQ1KcgCZgPKL+aDY2TEokGUHZCVsPjNNMyYzUEj2tWVHO/Buyva I6YzsPEM8eIryE+k1xfOY68fv1z/OfryKXvvIj5hKPXkdoMNyin3rhVbV+OYeiZciopYNMHxYgzm 0ploBh2XlAWAZQZgmcFFFmDpb2JpGfxvYHlQvqQcfO+w1/7eYbPKBQ67cfL9hxvfgK55EQFeJK55 kUXLf/QiDYJ/nxfKduUSBFTeEUn9Z24NrC1FK7yIZVN5vvaBYP6zwlC1zcgfudqufveuf3K8A9IH 7KDNfBTFgs2JFHI07p0iJT+QbZQ/4gN7IUv6cIoKEC7EJjhzbswtjVNT6JGZJFDO1XK+lpiGE9Ox 5VOI/OP3nEwW3nNyraJubwyoL16q13luvFzM5cScmOaSoJSSqXAalZSgIwPlEkEGyC8WbHAIGSD8 Xsym27rlc1/oHbBYaaZZQvVw8X05zTRzWv4ADEwzLt9fguFamjwgTfT7cqqBZLtilZwiEWHaI0yY phCKpSkGoylP0I465CsSNBLW8SOZkfTARPeaKFvfpJjCP6mddrvXRsG0dSCwB92r6jSEI0DaRZhY gINZMZivIY2vQIuRSkzEYqIopOOgCiqRORDyWUcF+gDd9QbNTbojrtFdQwTU84Qr4uxyDjvt7W2N ycbGW2S+ca519dvvMqPTZ6VG3gtNb+fSBO4X2coy0ngMWoiOcwksB/Iw2URpi0ohVzMK1ci0KttA 7wGCSgE+4KmYH+a8EYsOWX3sPasAsDWrHtAEBmDVC6wGmla/DcnC6rlmj3lBMeXTo0ERz9NpRqRF KuPJm+HVzvfZ0KHmP2PjbqjxxOp0q9Q4r/qjixPNUvE4yqraNUTImBEgcjO0+rkG26p8q1lC8obG 2+pHn+j/8gbk9umvvvwU9tTLP9L+Cv3Fj+qvX8ZfeW3m5+8gvx762eZXsVc3P1z/Mvrlh3Xbnsbl f3erV7aXvqK0IhtsX+/ah+3t3mN6Gt1yoLTSjx940fym3IL8W+mnK+ew4/MnShfRV05aDs3jTU6W 5LPqkJQbzaKvns7NggV5Vjr+ArJEzJonMdOkrjCYgpOD++NbUCXw7txqbgpRY+e1RJpo8g+JBNkx qozXspNgK0cReRdUZAvBfBD+tvy6Ol4tRnJobZwhSniRyNkTJjhpjBt0SCcxaDRgBpPOO4iSvrEx L+4JuyPOCNxsqFX5w+qVl8rffQN5R/vm5tfWov4Seu9GzVOb8E1Pau//LLI5sbN0ACsdmO5Z0tas C7YT9rpmaWhF95zupPm067Tref9KCM5Ce6OHMj21nlr/Uc2F75UuLq+8DCv3NHzqafv4UL4THt+Z fPJB5HbLxkO7sIN9HZZn0C373wXvZwA8eV35jZWz2LH554sX0cVZ0jbdXEKu3iep+6M6wZy2ZPST Q8eVT8jb1p9LHi1Wp+DaVGp+CTlC1M0TmLmmy2sSsKjZHXsUVZj3LwB/AUiDyuh4H5A7oVhsNBaL PhtFxdSzYzlctiivtMqPqVY1jd+r4zOVSB49Ous1VPGKIaXpRDpdA1o9NjK037s5GHg2wLLPMijI duNpMPCCbqD5wWxnabA00d4o78Bz3X1CP7p9v3OgH+8bdHTtR0bixpQZS1ok67h93L5svKC9oJ21 pci8J+0SnLDgijpdyDBhNFswq0nr60IHNHxGhw9nrQV32TNOzFHPww7FJqnCmWgiFoNjUS7Mo3yB 9c3gM2SREUNwMCeN5sFok+YX8cWF/LFTSI2pEOOYd9xZNEsW6XDl6fpDy/vqtnHYk6OlAlJLlEtF rFiaBAJraopyT+AT7qI1Y8gaxIH4IbB4AAqWuQWgpmnl3ta8KjzFjSelZC6TzMXhWKoYnkZ/uhpR faD55wClGN6llLXGjfwTNFEK+HN41p/2iHaw2NgjI2v71L1r+/uzgBLeT2hKEXqU6fDqMGLYBGQ/ bB/s8R9GB3XxJJB0SUeGyHvzVIWdhdl6aLKKyEeblMUnAR/khQm0Ir27gjd3tIQ33jSYhL4W25nQ YZnDNc2CETYunPN+D339TKq6iB+pVadTC3BqnjvzGiKXoAWwbYhYKV1IVJumPNemUBRg4IBGo+Fn w2gpkGVEPywAAiQRN2Vw92HKvasfVzY21re65+hKDklERYHDBL4Qm47AkjLugIqhbDDJJBiRAgzF CPakTh5b/c56SSU7Gy+l65nxXLY9mZD48SgsQW2Nn1+1rt2wkA2xSZwPxgNRGo6tDRgXPeLpxpSb VtcpN8urre5lejKHpKMiz2O8kIrm0ZykiA5VShwNxcGVfIAHq0CMjTKCl/NwzuzB9YUdynXKFeVv GnCrZ5muJoG7gnDtaglNNEeqKp8JMkkw7cHS543SgjHTJe9ZPdF0987Gg/Jdqw+2FlTy5sZ0+pg4 wSXawVBOJuJwXExHJLTp/7rGfGNGXZsrlDOpTCor5rhkLBPJjwEwCAdUzoaCHM6H4myMhqNsmKER OkQHGSxIU4THoXxIuXP9HfLdra4yJSURISaITTClaLV5/SUHNDM66a+4xl3Tg3O75Y8rO9Yr9ygd Zp3V4nC32z12sPQ3n6Y5Q0DXERJkHHNGKQ72c01dx4XjEQ6LxIVUWpIx+bH1cquyMWvm3RG2PUKN AXyZEFhcMZZhA3QQDvg9oeYcX5AgXdjE27P2zPBCz0VlgzywvhmlEVRuLhUKCLgQ4JhmjuhI8xE1 abYNYcotymEFkwdbbdNkMYmkuUSKw7hUGiwfGUmZd6iSYigYx8d9WZKneCptK2nkJ5X6euXzHxyn C5JFpbf9cUjLGyH5i3K4MJ0tp9PtqXQmkeVhLpuK8mhKUlzNpv1HUD8e5QHQtPElvsanhUwykWke qkbnUHlAtbpx9V9bHY15aFp+BGwKO2x9Fnu7w6z1d6FKRdV44ur1rWChPKV8Ua1suLoob1hUtP/e ImtVbaaFqzer5Q2/X1Q29Mja37Uo4LdGXHlUvZrubqRVbW/JZwS1T0gxWbQ+Vzm5gNcgm91L0Cwc CgRGWZRlw5EgHogEuZAAj4qjVUDGd0PHgpNMGvMXPVm7CKcMWq4b3d1NmHW4zuQx6hBPlOCBrufE QBJNiVEeVA8fTWaQ0YnWTDyZSmCJZDZeQGtFypnG0y5u6BDigL4+ssOksWtsZqvXApMu1m5BBsWR ghWzFqq+KbSQj/ISnohPFp6bh/Uxh+jDlNZFtd3FZzy4J0vny0g+nktksURGylQzGX4mdbIAK1+H NF1alxGQ/z1XN6ktKgXdwTlaY+lEREB5LsTG8FggSoV9cIQYG9qDrHZBE/aap0bC/lqNraLnTheX V/CzJ6uX/x75jvOFwUVscbC7cADt2D/8zGH8FK8WcjnQhjOT7iEweoZSh7YhT3v3G7WYxqB3DaN2 R5R34g7BmXRmYbkAFfK5VIqD295qbJAfUzu7nXqHG7YaRnxa9OBAYVmPG5a9z59FzqaO1maw8Xwt OYMWsiwJBB0Zd4ftYXvUG6dhr5BmCmg6EeX4JrBiCql4xkfKWFnXnzyEbu2wHOrEOw9Ztz2GfDO/ 7chh7PDCivUUemwxOz2Hz82MryQvwm3yO151WSW3n2OlVsZNhMAkZMIxBmejAT6UhIOJ0ZkzSCNt gRRkR7wJWDLC/znA7oMqBm2qG928W7+rG+/aZdv6FLJJ2r3QhXXNH7OdRMdLMbGIF8VirlSGv+xT D2hzc6BM5jynX0VezZyaqmPVUjU1gWYz7NrESXkEh+iIW8MWWHFAwyMj7mEUwPVFeUZ9znVcW8fq 2s5cB7plr/VwD95z2Lbl68hjIMgurHNxxfoCempZWpjB6/OFZW7FLa539zhGrC7YZTGAJfVQb35B g2uPuMDkWJBhdbE0LtbQXI71AT1Opjy8PeaL2MI6WOlWRReSU8Vi81XcDxp/q55ToBnoSvhYLIdF c3xS5GE+kQK8kARKRgRqJEGkHEkgK3iwVfCAxJtvmAQeF0BuBETy5+xprKTTJgbRPo3fPozr7Baj Zwh2D9F9BxHdlwbeUp6HtCFrwIcFfJSfZGDaRwS9qM0hF6Uulc317h5UA0zyPNT21m/UfhfrJRAy 4ucojKOS/hw5pHU5QkGH1edkCDhIhSgKATVXcWG6Y2c9r6BvvD5+4hQ+V8/NLiA1f8khYY68KTEU tUUOR54Y6xuzhP1jrrAvysZgNhaMxxAuwscEoGQEMZOC6XIpWEJfOJqZBLvLVHZ+GVnwTznK2Iuq NP/sWBiPjIXDY2PwWHQsziPcaDwUwUbDobEQ+ClEPetB71YVh/rETnT3YZdWg2u0zt5DiI4zZExY xlSwT3gHR6wWvxuWB+SL6rIu0bUH6aZ0Lgdmd9n8RtRgTRSduGXCt3QaWeIns3ksnyuI42i16LOC xK1+SX1qtM7maDhH84QTMXssI4Az9IfIregz+8WCBrcn/ekMkoym+AzGpZOZTG6RvRD4fgg0wSeb b7GQNUbIJCLcn2WEO6GRkCPgxwJ+lmaCMEO4gzYwYwwSZHZFYn7cH2PiQAQG+VB+CpFJaLwKdC8P N4khi2ZTARqsNRRPxNxwzB3R7kWUL0LGZ92jDBYgWD9Fw4zfE7SipEMekVRWTzhG4XSUiQd5mE2E 8hOI/AXofPAIU8T8U56SIw2nHRbOiFqsjM+KW306Q38PLP8UantQvu7qRrWfZAkv4okRoh8jhSSb RlNJIEdxQYgl00iKTfpFTCCJmLep9f0kfk7Rq99lxFQivMaIgWb8ETpCwhH3WPNt2TcgfcjOkliA ZBgwFgKUJ2QB8Q9LkNXd9JaKgo1FaGpsCXi7es2VB9WknyU8f+JKGrgi4OKaK2k2SQqY6CdinrXH Dn78vDLyl1wBqfCMNZH7LrQ/NBT0YAEPS1IMzNBUkEJ9Xi7twl1pkmcicNRPhdfeClFU80EGSSA+ zpfxYb50iZ1CzxzNL9Tx+kL2wo+Qxm6oTd7QzH/7Dt7RGk+LYe7dm8bZCAVuGvaNaUH+74YM1+Kn gGIIwKzPGTSD+G1gVXGFo2vZWotfCOUnEfmzkPwJ5ZHWlDNO0GA5YQNBLMBSIeIaYjZ387EBEfWI 7owvYa1olxRIvmO9DP3fYqGQkvj2HFeK1sbgrLLLBSVHhVCMheNsmKWRwGggGACmPB6TWWn91PrG tibQ9/3BfwDa+wj6Pf+HOpDVu5r5C5AYED0MBfJHe0JWtFltoH6b+QP1+67/IH+NX4J18H75/kan 2qr6z9Lx0HuW/SATABnqmmXQGSbXu5UR/yMyNJSRCtlaBnSGFMuh1YLPmsYTrpihH1F2QvpR1ygL WoKhAP8xfmfQBCxZgI/uSIwEPtLx4B96TAOFimOxSrmYzQntgtQcwBMF0gp0uTt6zZphzVrQx/hB xdI+d8CO+tcazO55r2WBOVCyzQbbCS0Fpug85qt5Cnag9h3WuAk1mRgCyBevzqjppqc947YsnLOZ +BHU5QzSTtxFu0g3wbB2u1YDeOQrfxEvwCREk0m0OxHlAUgbsFAE5qPcjLnZ8UZJZXK+10OsAIMl 6xqHHDuyWDwC9IzfLuIJR2wYaKLNICh3MyiCWWMNyg1Yw99EW/XHPmyyxrWgtkPLa0GRE56CAwTl bAa1r2No826g2+9oPKrW2PXDti7Y2k12dSHbc3vqB7GdSy/oX0eXj4jFWbxerE3nl+H8sri8hJx3 nh44jp3u2lF9HO0bIO0aXH68Qz17MLf5QWQzedBqwAw2g1eLdg6OnzDghhPe868iS7F6ooolKmkp B4S/lAMpn59yDZXxtlhjvTqWFIEcFvhQIA5AakolGOzzDh2yurE5Cpsv5+kAA9qNJlxBB0o0pYEK 9Nu1WmjG2ayqaUS+Fcp6MmQKZFkqBCvoueeKywv48VOlyz9GrjjO9x3D5oZ7pYOo0Ui5zLjJbR4x 98C/tUPKJ3a0yhqjms82H9VOVLzGIj7Vl9n1OPKMd79egxlBPBpUb+EyDtyR9uVYCQ4mR8fnEflr UG0qn0vG4bbGPSDrTsJB2v2E6OFdQOS7nBEHummnad9B/OB+y9MPIU/mds32YD2zi7ZjaLnMpUp4 OVUZn5qDlV2ged43VljSA+L0N2te9YfuWXt2yYekSaTxfUj52OqtasrtALXcp8lOG3D9tHflJeT/ 8Wo2MXKbZRwXgh370G6E6Ibd15KtppCoLS2KQEUc4IA4QA+IQyuQiBpp22wyu9Nsdj5tj2f8Mf6a zYy/Zvwx4/F4vnY3mdlNNk2Upq3UL3FoD73ADZAQSIgDFyQOnuAV4vUkQVy5cLef9+/nfZ/nfX6P n8+99/em+HRv1r2NDQKZ94me4LBmBbUqGpkF8SWkQjJVZjFWdAYKhofUeHRI7cUhXQxHiE0ebfKN zC+SdL/zOBTlWi0JHlpJ0h0Fk1dZM3mCM2oQUlHJU/uTJBT9aXfY8VDLMjUTs2yJ6xBcF7Iz5tqL GujxQI6X/M9kGYPC3rqU/skG8XdkeRb9GupRaqqs1lFVTWhD4jSDJqxsUaexNzfZbJbIZquZDbBt 5bsk3iGnxQ/y7+empM+gPtMi84ASy5UqXq2QYgHbuuqOdojsiDoS3kPL8Xf9VEs3IWOZ7brqEMKt qXyA3TlyJ1NiOuke3gMfbd7/6Qz/8a1Mt9jhvTV4iPwAdCHxubjbCcwRdnMs0CHRp/0t91eoH30r BTPuuflfV6qbXB6Sb54ukmWSplhKRMu/iT9FtrScVcYtxmE7NRTWHEoXGw5b/oAIe72xM0PJlFQV eV5ERZ5TOazKG7ZA1GwlhNnxPvKPxtLhc9E5eCuN56+tUMiN3VBuC2hbMOgdEJtILlukKQEVqLJS gbWh5VUIxhP3IY99HJ+nkLG/4FrZSjrjRq3JFEF8AVnXN60CbuU9MqigTDAUJ9hoYDghETo39+7c Q18aIhH4VIQMwLJ1/r8ZwEkO/PRDEE2Q5fb8Ryu+6tQN1ZbaklmzahZrUdF3Tp5eHaSi8/OvtUdO z7HXLMPRewn1f5NCek7S0TB24ZUho5raUGUgKBWRwp+L7TPR9SXRVz0X2FrbMnHTtDUP6wTxRtK9 MeFqodIR27V2zS63c9E3Tp5a7aWi1ehu9JX4btLLeH5+2jsa9G/oa0H8LIX0d926KaOWrEkS4NVk lZfi3bNRa0mF5agFIOyZBm63fH2UqLtCIeGup1qKV7OrrdLk1dUX4o0XI3tJ6tQ9G7SbFnzaMBwt SJ7+ObLsJYp8RfAIT+jnx1f+GJ9afTn+6tW3ijmWXxMkXmHrKB2d7SFMg9NECxVhRdgCptMb3MR/ +7cvXlwavG2TNSCqoqTgYo1VKxgdXe4hZIPRuRbbKo2v3Y2/HL2y+tkf9o+HY99Zc1sd3U+Wf4FC 3HYyw2TArxOBwJZyW/jGL7c+FB2ppRprrC95sOrWTCPRbDc9LIAxD5Ms3DLFlVuyoViwMHYYq2rw 0SvxX1a3fsBe5UgonOc4mcfUWtOoEhbJaBzGVJUavB4FhasCxmQ9WDi5vtTH9ved4Q3iYDg6DO5H r85fW22FhqfpLceyLBhjtuYmUs9SSGfRxzLquqopaFNtKBKo1qtSBT8XN+IvRaUlbigHHmjrLbjt luVoXcyGelMQ8c5G+IqSVgoyLzI8z8qw0s6raSz+Xir6eH5mqXfyFFKPT8Hdb4yNsN0znVbL1lG9 nbQ1o+dT8Ucnzy5RcwIxInxpOToV/T5+eYUaCKMxCPWJNcWtmb4/BIfsLDvFc7Mr4wvBB71b4/EU HU/d2QyMlD1xhotTZa8PJu1REOLB4KB7p432kNfFNwrpDTS9Qa9fBDn9mpXBrYyeo0COL5AlvFS6 xqZllESO5H02LKH9ol3IA1rJihlczCjXcuBib/1oAz+6/KDwSQ3au9Te9qkQXY7P/w7Wb/86c/ef Z5BE8Q8fPr0SlNr5LCCVnccvF8CmuznJ4OOt27n3qAv05VzubTSXYTc3QUHfsbYSJdkSyAp5qoRT xW3mkoDSyCetB8OjY/Todu/eu2Cs7IvT5MsmPTCyh/0BHob77pGB9pG0cc0thSg54IcjEOjjxE1T fX8MHtB308d4+viN4esWtHdHOGCCIrr88OvRM//7uGD0p9P/h1fg/XZhvrNyY9q59Q6E3BEd4H0q GXchy1K1QiQ8QkMeqSY8Yruyh5lWQ2sRMHAaOqYbqqwTmtKs8XDnGIHFWSpPpUtoHjnu7PfCAbr8 5y/mJyuFbS6zBbbb+R6Jk0EoDLGgazou4Tqm5y+oxsbtBWBJ4q4qEnVR2lUwWW0aKqHq9ZYD+mbg +bjrD/wbXTRE1qtbxeI2GlVPJ6bTC9OQfHuhMMACPzHtuWbHT9iNT9iNg8AkPjFdVzFF0XSFUI26 1QahEThd3O4O/cM+3Nw32UypsA2Fw3RZXhkeONMjcCCM/+MXuixxLFFlpQrzhNNsB3KatfBL0zKa GmboqpKMATUlHpAyxTM4xxTpTRItIe+403B4AJU3E9s3D6HPx8mIEVWCtikmsZ2MGD2yzT/xufnI ttmEPtfrsrbwOQdKEl2l8Wq5VL7KQNv3vNlgcABLLCOyV068y3MvtRzt9BdN9nu7e6LDog5nbl8E J99HLkrbHMxT7I64ngwRHQfIemPH4lyUc6SDd8Fci36GHE5UOSB6cpd1SZe0so0MGqTq0beXlq9f T83VZ6KHK/8WYACzBc9LCg1lbmRzdHJlYW0NZW5kb2JqDTggMCBvYmoNPDwgL0hlaWdodCA0MzUg L0JpdHNQZXJDb21wb25lbnQgOCAvU3VidHlwZSAvSW1hZ2UgL0xlbmd0aCAyNTQxMiAvSW50ZW50 IC9SZWxhdGl2ZUNvbG9yaW1ldHJpYyAvV2lkdGggNjkzIC9UeXBlIC9YT2JqZWN0IC9GaWx0ZXIg L0RDVERlY29kZSAvQ29sb3JTcGFjZSAxMjQgMCBSDT4+DXN0cmVhbQr/2P/uAA5BZG9iZQBkgAAA AAH/2wCEAAwICAgJCAwJCQwRCwoLERUPDAwPFRgTExUTExgXEhQUFBQSFxcbHB4cGxckJCcnJCQ1 MzMzNTs7Ozs7Ozs7OzsBDQsLDQ4NEA4OEBQODw4UFBARERAUHRQUFRQUHSUaFxcXFxolICMeHh4j ICgoJSUoKDIyMDIyOzs7Ozs7Ozs7O//AABEIAbMCtQMBIgACEQEDEQH/xAE/AAABBQEBAQEBAQAA AAAAAAADAAECBAUGBwgJCgsBAAEFAQEBAQEBAAAAAAAAAAEAAgMEBQYHCAkKCxAAAQQBAwIEAgUH BggFAwwzAQACEQMEIRIxBUFRYRMicYEyBhSRobFCIyQVUsFiMzRygtFDByWSU/Dh8WNzNRaisoMm RJNUZEXCo3Q2F9JV4mXys4TD03Xj80YnlKSFtJXE1OT0pbXF1eX1VmZ2hpamtsbW5vY3R1dnd4eX p7fH1+f3EQACAgECBAQDBAUGBwcGBTUBAAIRAyExEgRBUWFxIhMFMoGRFKGxQiPBUtHwMyRi4XKC kkNTFWNzNPElBhaisoMHJjXC0kSTVKMXZEVVNnRl4vKzhMPTdePzRpSkhbSVxNTk9KW1xdXl9VZm doaWprbG1ub2JzdHV2d3h5ent8f/2gAMAwEAAhEDEQA/AOt+rP1Z+rd31b6Vdd0rCtttwsd9lj8e pznOdUwuc5xZJJK0/wDmp9Vv/KfA/wDYan/yCX1U/wDEt0b/AMIY3/nli1UlOV/zU+q3/lPgf+w1 P/kEv+an1W/8p8D/ANhqf/ILVSSU5X/NT6rf+U+B/wCw1P8A5BL/AJqfVb/ynwP/AGGp/wDILVSS U5X/ADU+q3/lPgf+w1P/AJBL/mp9Vv8AynwP/Yan/wAgtVJJTlf81Pqt/wCU+B/7DU/+QS/5qfVb /wAp8D/2Gp/8gtVJJTlf81Pqt/5T4H/sNT/5BL/mp9Vv/KfA/wDYan/yC1UklOV/zU+q3/lPgf8A sNT/AOQS/wCan1W/8p8D/wBhqf8AyC1UDFe97Hl5kiyxo+DXEBJTR/5qfVb/AMp8D/2Gp/8AIJf8 1Pqt/wCU+B/7DU/+QWqkkpyv+an1W/8AKfA/9hqf/IJf81Pqt/5T4H/sNT/5BaqSSnK/5qfVb/yn wP8A2Gp/8gl/zU+q3/lPgf8AsNT/AOQWqkkpyv8Amp9Vv/KfA/8AYan/AMgl/wA1Pqt/5T4H/sNT /wCQWqkkpyv+an1W/wDKfA/9hqf/ACCX/NT6rf8AlPgf+w1P/kFqpJKcr/mp9Vv/ACnwP/Yan/yC X/NT6rf+U+B/7DU/+QWqkkpyv+an1W/8p8D/ANhqf/IJf81Pqt/5T4H/ALDU/wDkFqpJKcr/AJqf Vb/ynwP/AGGp/wDIJf8ANT6rf+U+B/7DU/8AkFqpJKcr/mp9Vv8AynwP/Yan/wAgl/zU+q3/AJT4 H/sNT/5BaqSSnK/5qfVb/wAp8D/2Gp/8gl/zU+q3/lPgf+w1P/kFqpJKcr/mp9Vv/KfA/wDYan/y CX/NT6rf+U+B/wCw1P8A5BaqSSnK/wCan1W/8p8D/wBhqf8AyCX/ADU+q3/lPgf+w1P/AJBaqSSn K/5qfVb/AMp8D/2Gp/8AIJf81Pqt/wCU+B/7DU/+QWqkkpyv+an1W/8AKfA/9hqf/IJf81Pqt/5T 4H/sNT/5BaqSSnK/5qfVb/ynwP8A2Gp/8gl/zU+q3/lPgf8AsNT/AOQWqkkpyv8Amp9Vv/KfA/8A Yan/AMgl/wA1Pqt/5T4H/sNT/wCQWqkkpyv+an1W/wDKfA/9hqf/ACCX/NT6rf8AlPgf+w1P/kFq pJKcr/mp9Vv/ACnwP/Yan/yCX/NT6rf+U+B/7DU/+QWqkkpyv+an1W/8p8D/ANhqf/IJf81Pqt/5 T4H/ALDU/wDkFqpJKcr/AJqfVb/ynwP/AGGp/wDIJf8ANT6rf+U+B/7DU/8AkFqpJKcr/mp9Vv8A ynwP/Yan/wAgl/zU+q3/AJT4H/sNT/5BaqSSnK/5qfVb/wAp8D/2Gp/8gl/zU+q3/lPgf+w1P/kF qpJKcr/mp9Vv/KfA/wDYan/yCX/NT6rf+U+B/wCw1P8A5BaqSSnK/wCan1W/8p8D/wBhqf8AyCX/ ADU+q3/lPgf+w1P/AJBaqSSnK/5qfVb/AMp8D/2Gp/8AIJf81Pqt/wCU+B/7DU/+QWqkkpyv+an1 W/8AKfA/9hqf/IJf81Pqt/5T4H/sNT/5BaqSSnK/5qfVb/ynwP8A2Gp/8gl/zU+q3/lPgf8AsNT/ AOQWqkkpyv8Amp9Vv/KfA/8AYan/AMgl/wA1Pqt/5T4H/sNT/wCQWqkkpyv+an1W/wDKfA/9hqf/ ACCX/NT6rf8AlPgf+w1P/kFqpJKcr/mp9Vv/ACnwP/Yan/yCX/NT6rf+U+B/7DU/+QWqkkpyv+an 1W/8p8D/ANhqf/IJf81Pqt/5T4H/ALDU/wDkFqpJKcr/AJqfVb/ynwP/AGGp/wDIJf8ANT6rf+U+ B/7DU/8AkFqpJKcr/mp9Vv8AynwP/Yan/wAgl/zU+q3/AJT4H/sNT/5BaqSSnK/5qfVb/wAp8D/2 Gp/8gl/zU+q3/lPgf+w1P/kFqpJKcr/mp9Vv/KfA/wDYan/yCX/NT6rf+U+B/wCw1P8A5BaqSSnK /wCan1W/8p8D/wBhqf8AyCX/ADU+q3/lPgf+w1P/AJBaqSSnK/5qfVb/AMp8D/2Gp/8AIJLVSSU5 X1U/8S3Rv/CGN/55YtVZX1U/8S3Rv/CGN/55YtVJSkkkklKWR9ZOq2dNxaPRIZbl3sx2PI3bdwc5 ztvf2tK11ndZ6Y/qFNHpPFV+Lc3Ipc4S3c2RDh4EOKSnHv6zbXjY9ePml/rZgx8nJsrh1DSxz9W+ ZaAJ8UA9b6nZRfRTebfsudXTZlVM3ONDwHOO3xErVq6PnVNyr99FuZnWtsuD2n0g1jdga0cqeH0n N6fj2nFsqOXkW+re57SKzptDWtbwAkpqXdXeMLHqwcs335WS3GN9jQHVz9KWaagKvd1jqmNnP6N6 wsufbWyrJc0SGPBLpaNJ0Vr/AJsW+g+31wOoOyW5gsDf0YsboG7f3YSs+rWTe92bbewdSNjLa3ta fTbs0DYOsFJTZ6Rl5n7QzOm5Vnr/AGbY6u6NpLXjh0LYWb0zpt2NfkZmXY2zKyi3fsBDA1ogBsrS SUwfYxn0jEqthXVCuyXD+et/6tytkA8hV8Jo9OzT/DW/9W5JSX16v3gl69X7wU9rfAJQ3wCSmHr1 fvBL16f3gpQ3wCeG+ASUw9er94JevV+8FPa3wCW1vgElMPXq/eCXr1fvBT2t8Altb4BJTD16v3gl 69X7wU9rfAJbW+ASUw9er94JevV+8FPa3wCW1vgElMPXq/eCXr1fvBT2t8Altb4BJTD16v3gl69X 7wU9rfAJbW+ASUw9er94JevV+8FPa3wCW1vgElMPXq/eCXr1fvBT2t8Altb4BJTD16v3gl69X7wU 9rfAJbW+ASUw9er94JevV+8FPa3wCW1vgElMPXq/eCXr1fvBT2t8Altb4BJTD16v3gl69X7wU9rf AJbW+ASUw9er94JevV+8FPa3wCW1vgElMPXq/eCXr1fvBT2t8Altb4BJTD16v3gl69X7wU9rfAJb W+ASUw9er94JevV+8FPa3wCW1vgElMPXq/eCXr1fvBT2t8Altb4BJTD16v3gl69X7wU9rfAJbW+A SUw9er94JevV+8FPa3wCW1vgElMPXq/eCXr1fvBT2t8Altb4BJTD16v3gl69X7wU9rfAJbW+ASUw 9er94JevV+8FPa3wCW1vgElMPXq/eCXr1fvBT2t8Altb4BJTD16v3gl69X7wU9rfAJbW+ASUw9er 94JevV+8FPa3wCW1vgElMPXq/eCXr1fvBT2t8Altb4BJTD16v3gl69X7wU9rfAJbW+ASUw9er94J evV+8FPa3wCW1vgElMPXq/eCXr1fvBT2t8Altb4BJTD16v3gl69X7wU9rfAJbW+ASUw9er94JevV +8FPa3wCW1vgElMPXq/eCXr1fvBT2t8Altb4BJTD16v3gl69X7wU9rfAJbW+ASUxFtbjAcCVNNA8 E6SlJJJJKcr6qf8AiW6N/wCEMb/zyxaqyvqp/wCJbo3/AIQxv/PLFqpKUkkkkpSSSSSlJJJJKUkk kkpSSSSSlKtg/wA3Z/x1v/VuVlVsH+bs/wCOt/6tySmwqXWXuZ0zIc0lrgwwQrqHkUV5FD6LdWPE OHGhQOyYkCQJ2BfLf2jnf9yLP84r0boL32dKx3PcXOLNSeVz3X/qpjY2EcjAa7dWZe0kulvzW59W 7hb0qkbDWaxtLXT2+KjgCJEHs3eayY8mGMoCqlRdZJJJStFSSSSSlJJJJKUkkkkpSSSSSlJJJJKU kkkkpSSSSSlJJJJKUkkkkpSSSSSlJJJJKUkkkkpSSSSSlJJJJKUkkkkpSSSSSlJJJJKUkkkkpSSS SSlJJJJKUkkkkpSSSSSlJJJJKUkkkkpSSSSSlJJJJKUkkkkpSSSSSlJJJJKUkkkkpSSSSSlJJJJK UkkkkpSSSSSnK+qn/iW6N/4Qxv8Azyxaqyvqp/4lujf+EMb/AM8sWqkpSSSSSlKr1LPp6dh2ZlwJ ZWB7W6lxJ2taPMkq0sj60dOu6j0a3Gob6lm6uwVzt3em9ry2dOYSUxu63l4eA/MzcRjCXV149VV3 que+1wY1ria2Bh3ETyhP+sxxm5VWbi+lmYxqDaKrPUbYb3bKtjy1nLtDI0VGrpPq2Z11nT76unWV Utbhgj1XXVvLjcxu/wBpbp31hV7Pq/1C05PUqqrjaLMZ+PRkvDrXtxrPUdJmG7tYSU7D/rKcVuUz qON6GTjMa8VVv9UWB52t2OLa9Z01CjZ9ZnYZtq6liehkMY2yqqqwWiwOO0NDi1kGfJUOpdL6l1d+ XnMx3UOFdTcem3aHvNb/AFHTBMeGqj1XpvU+s3vz68V+OaK2Cqq4tDnua8PcNHHw7pKdvA6tfdmv wM3GGLktYLWhlnqtcw/ytjNR30WosTBqy8vrTup2478WplApY22N7nEy7RpOgW2kpSrYP83Z/wAd b/1bkZ9TH/SEx5lVcKio12SOLbe5/fd5pKbqZD+z0/un7z/el9np8PxP96SmZAIg6hZWV9YMTCz6 8C2p7DYQBZps147ytL7PV4fif71kdf8Aq+OpVMOORXfWdHGeE2V1puyYuAyqd8J/B2wQdQkqmFhG rGrrvPqWMaA54kTHzR/s9Xh+JTlh0JSpIX2en90/ef70vs9P7p+8/wB6SEqSF9np/dP3n+9L7PT+ 6fvP96SkqSF9np/dP3n+9L7PT+6fvP8AekpKkhfZ6f3T95/vS+z0/un7z/ekpKkhfZ6f3T95/vS+ z0/un7z/AHpKSpIX2en90/ef70vs9P7p+8/3pKSpIX2en90/ef70vs9P7p+8/wB6SkqSF9np/dP3 n+9L7PT+6fvP96SkqSF9np/dP3n+9L7PT+6fvP8AekpKkhfZ6f3T95/vS+z0/un7z/ekpKkhfZ6f 3T95/vS+z0/un7z/AHpKSpIX2en90/ef70vs9P7p+8/3pKSpIX2en90/ef70vs9P7p+8/wB6SkqS F9np/dP3n+9L7PT+6fvP96SkqSF9np/dP3n+9L7PT+6fvP8AekpKkhfZ6f3T95/vS+z0/un7z/ek pKkhfZ6f3T95/vS+z0/un7z/AHpKSpIX2en90/ef70vs9P7v4n+9JSVJC+z0/un7z/el9np/dP3n +9JSVJC+z0/un7z/AHpfZ6fD8T/ekpKkhfZ6fD8T/el9np/dP3n+9JSVJC+z0+H4n+9L7PT+7+J/ vSUlSQvs9Ph+J/vS+z0/un7z/ekpKkhfZ6f3T95/vS+z0+H4n+9JSVJC+z0+H4n+9L7PT4fif70l JUkL7PT+7+J/vS+z0/un7z/ekpKkhfZ6f3T95/vS+z0/u/if70lJUkL7PT4H7z/el9np8PxP96Sk qSF9np/d/E/3pfZ6f3T95/vSUlSQvs9P7p+8/wB6X2en90/ef70lJUkL7PT+6fvP96X2en90/ef7 0lJUkL7PT+6fvP8Ael9np/dP3n+9JSVJDbTW0y0ajzKIkpSSSSSnK+qn/iW6N/4Qxv8Azyxaqyvq p/4lujf+EMb/AM8sWqkpSSSSSlJJJJKUkkkkpSSSSSlJJJJKUq2D/N2f8db/ANW5WVWwf5uz/jrf +rckpspJJJKUmKdJJTymV1TqHS+vsryrC/DuMNngB39y6lpDhI1B4Kr5eDhZMWZVTbPSkgu7KOF1 HAyi6rEsa/0oBA7JoBBOrLOQnGJEaMRUq2biSSScxKSSSSUpJJJJSkkkklKSSSSUpJJJJSkkkklK SSSSUpJJJJSkkkklKSSSSUpJJJJSkkkklKSSSSUpJJJJSkkkklKSSSSUpJJQsc5tbnNG5wBIb4lJ TJJYJ611uf8Akx/3pftrrn/lY/70/wBuXh9oWe4PH7HeQn5NFdjKn2NbZZ9BpOpjwWN+2uuf+Vjx 81yHUM3OvzXX5Jc29jtBxtjsPgpMfLmZOoHlqsnmEQKB+r6akuY6d17rVuGxwwnZEaeqNJjurP7a 65/5WP8AvTDikCRp9oXjJEjr9jvJiQASTAGpKwv211z/AMrH/er+e3JyujXtY015FtLgG9w4jhNl Ejf8EiQO1rUdd6fkXCukve1ztrbgx3pEjsLI2rQkeK5/pPVMFvRKsRr/AE8llJrNEEPD2tM6LJ9H KxvqnjZFL7Ddk21fbbXucSKtx3d9Br2TVz20iJnRUX9Yw2X5NJ3F+J6fqhrS7+d+jELl7W5FHT7S zK9TAtzcYXtpc9xqoJAuh7vdB0VbIFdf7df019hqL8MVvBcT9IBwa46kJKe6qyse2yyqqxr7KjFj AZLSfFVb+tYFGUcRxe61sb9jHODN3G9zR7Z81ldDxcTH+sXVfaWZD3tdWCXatLdSJMcoXWrGYGdb n9NyS3PJY27CLS4W6wI84SU9TI8VW6f1DH6hjjIxydhc5muhlh2n8iwMO3Ht6tlO6q+yrLba37LX ucBsI02huh15Wb03Ffi4PT8yo2tvf1B7H+50em579NvEJKe6kTE6qtn9Qx8Cplt5O19jKhGp3PO1 v4rkMAZ+Rmiy/Jbj57Mx+9rnP3GsPdFYZ9HaWcKvkmq7FqdlPtPWP2pF1cu0Y287Rt+jt9PaQkp9 AkKjT1jEuD9m87LzjGGk+8fDtquWzM+yjD6piWWWDLPUpqYN270nmsgj+TypMORXU7ZvaXdY90SJ advh2SU9rInnVLcOJXEV03VYVfUG2XHKHUdklziPTLyC3adIhAwrq87rlPrWOZbTmPc+x9rgHsEh lYYDt5SU9+kmTpKUkkkkpSSSSSlJJJJKUkkkkpyvqp/4lujf+EMb/wA8sWqsr6qf+Jbo3/hDG/8A PLFqpKUkkkkpSSSSSlJJJJKUqdHUW3Z1+GKrGmgAmxwhjt37pVxUqX9RPUbmW1sGEGg02A+8u7yE lN1JJJJSlWwf5uz/AI63/q3Kyq2D/N2f8db/ANW5JTZSSSSUpJJJJSxAOhXL09Gz8D6wHJw2g4lv 84JiA7n7l1CBmOvZi2PxwHXNaSxp4JHZNIBo9mTHklGwK9Y4TadKFh/Vvrz+pttryAG5FZ+iNNFu IggiwtnAwkYy3C6SSSK1SSSSSlJJJJKUkkkkpSSSSSlJJJJKUkkkkpSSSSSlJJJJKUkkkkpSSSSS lJJJJKUkkkkpSSSSSlJJJJKUkkkkpSSSSSlJJJJKUsrqX1eweoX132Da9p95b+cPArVTIiRibBpB AO4Y11sqY2utoaxohrRwAFNJJBKkkkklMPSrDi/Y3ceXQJT7Ghu0AbfDspJJKYCqtrCxrGhp5aAI +5IVVAQGNjwgdlNJJTHYzdv2jdxujVMa6y4PLQXDh0aqaSSmJrYXBxaC4cOjVN6bIjaIBkCO6mkk ph6Ve/ftG/8AegT96RqrLi4saXHkwJ0U0klMDVW47ixpcdCSBKXps/dHM8d/FTSSUwNdZbtLRHMR 3WUz6s4LXs99jqa7fXZQT7BZMythJJSydJJJSkkkklKSSSSUpJJJJSkkkklOV9VP/Et0b/whjf8A nli1VlfVT/xLdG/8IY3/AJ5YtVJSkkkklKSSSSUpJJJJSlTx8PJqzr8l+U+2m0AV45A2sju34q4k kpSSSSSlKtg/zdn/AB1v/VuVlVsH+bs/463/AKtySmykkkkpSSSSSlJk6SSnKp6J0/Dzn9QYSyx5 JImG686LTa5r2hzSHNOoI1Co9b6f+0On2UAw+JrI/eCyvqdnXOofgZAcH0EhhI7TqPkU2wDVbs3C Z4zMysw0o9npUkkk5hUkkkkpSSSSSlJJJJKUkkkkpSSSSSlJJJJKUkkkkpSSSSSlJJJJKUkkkkpS SSSSlJJJJKUkkkkpSSSSSlJJJJKUouO1pMTAmFJMkp5x/wBbLmvc39nXnaSJAPb5Jv8Andf/AOV1 /wDmn+5dJA8EoHgm1L95m9zF/mv+cXmz9br4P+Tr/wDNP9y5a7rvVza8jKuYC4w3cdPJemFoIiFz 1v1I6ZbY6x1twLySQC2Nf7CbKMzVSZsGfl4k8WOv+d+bmdE+s+bTjObdTfmuLpFgl0Dw4K0f+d13 /ldf/mn+5a3SekY3SqHUUOc9rnbiXwTPyAV2B4IiMqHqY8mXCZEjFp/er8HnP+d13/lbf/mn+5at WfZk9KtyxW6h/pvcGu5BaCr0DwUL6vWospnb6jHMnw3CJTgD1Nsc5wI9MOA+dvK1ZfU8PouH1n7Z ZfvdWMmi2HNc2x2326S0iUC3rGecjOdjZlj82nOFOPhAbmOr3NkObt42k6rXxvq1lfZ8bCzc1t+F iOa5lNVPpF5YZb6jnW2THlCv9N6TXgW5dod6jsu91/0Y27vzeTKLGi6v1C49Oy2dJtrt6lUyW0sc 1z2wRPs8fiqGH1/FowjZXkX5177a6G4t4Dbm22aBh9rY8Vt5GK51bziObjZDoi8Ma7uD7gYkH4rI t+qz8iy3MyMsftF9lNteRXVsrY6gks/RF7pGpmXJKR9W6p1SrI6XtofXZbkOZZjseIeNjiJd4Kbv rdjsrDLKhVlm11Bpse1jQ5okn1HaRCuP6RlZF2HkZmWLbcO02+yrY10tLdobucRz3JVS36qNOQ/L qyA3JN7r63PqFjBuG0sczcNw+BCSl6frXTk11NxaTdl22OqFLXt2g1/SdvEghVej9fyA+xuYywvy OoWY9bHuk1gCdvwELQu6Fk2fZr2ZNdWdiucW2soioh30mmr1J/6Srs+qtjKDGaXZYyjmMyH1gje7 Qh1bXNkfMJKR9U63bbYKscuoON1KrFtcD9NpaHn5HcpVfWI04zHMqtyrMjPvw2Nc5shzHvHOnt9u inX9Vnj1HXZptttzWZz3+mG+5rWt2AB3GiJT9Wm1CgfaCfs+dbn/AEOTa57tn0u2/lJSzfrNNLh9 mcM1uT9j+z7hHqEBwO/w2mVb6J1S3qdFtltH2d1Vrqizdu1ZodQsPr/1eyAHPp3315WcMq8Vs3Or aKwzRm736tWr9WasynCfTkUiitlh+z+z0nuYfzrGbnQZSU7KSSSSlJJJJKUkkkkpSSSSSlJJJJKU kkkkpyvqp/4lujf+EMb/AM8sWlZYyqt1jzDWAknyCzfqp/4lujf+EMb/AM8sWoRI1SU84/61Z15P 7J6Pk5jO1z4prPwL9fwUR9aOsY5nqXQsimr862lzbgB4kNg/grX1i6vb0m3CtcSzCL3DIe1u7gS1 vzKy+l53Xj1HBysrIc6nqjrP1EsAFVQ1Y6eZ8UlPU4eXTmY1eTQSa7RubIIP3FHTAACBoE6Sli4N Bc4wBqSUNmTj2AlljXBolxBBgIXUsZ+X0/Jxq3Bj7q3Ma48AuESYXP41VzPW+rluPRj5duETXk0u LmODYrJfLWuBkykp6avIotn07GvjnaQU7LqrJ2Pa7bzBmFxubl5HS+n5fSn49VGUzEDxk4zi4Oa0 tY4nc1pBT9Za3pdv+TP0YfgPNmw+EbXnz80lPYsuqsJDHtcW8gGYU1y+Nj0YnVej/Yxt9fHd68H6 Q2g7nfNdQkpSrYP83Z/x1v8A1bkZ/q6bA0+O4kfklVcI5Hp2QGfztvc/vu8klN1JCnJ/dZ95/wDI pTk/us+8/wDkUlJUkKcn91n3n/yKU5H7rPvP9ySkqSFOT+6z7z/5FKcn91n3n+5JSRZ3VOq4vSK2 221uIeYlg7+auzkeDPvP9yqdT6e/qOI/GtDAHcOBMg+PCButN10OHiHF8vWm1jZFeTQy+oyywBzT 8UVZnSen39MxhiixtrZlm4kEeXCvzkeDPvP/AJFIbaokAJHhNjolSQpyP3Wfef7kpyf3Wfef/Ioo SpIU5P7rPvP/AJFKcn91n3n/AMikpKkhTk/us+8/+RSnJ/dZ95/8ikpKkhTk/us+8/8AkUpyf3Wf ef8AyKSkqSFOT+6z7z/5FKcn91n3n/yKSkqSFOT+6z7z/wCRSnJ/dZ95/wDIpKSpIU5P7rPvP/kU pyf3Wfef/IpKSpIU5P7rPvP/AJFKcn91n3n/AMikpKkhTk/us+8/+RSnJ/dZ95/8ikpKkhTk/us+ 8/8AkUpyf3Wfef8AyKSkqSFOT+6z7z/5FKcn91n3n/yKSkqSFOT+6z7z/wCRSnJ/dZ95/wDIpKSp IU5P7rPvP/kUpyf3Wfef/IpKSpIU5P7rPvP/AJFKcn91n3n/AMikpKkhTk/us+8/+RSnJ/dZ95/8 ikpKkhTk/us+8/8AkUpyf3Wfef8AyKSkqSFOT+6z7z/5FKcn91n3n/yKSkqSFOT+6z7z/wCRSnJ/ dZ95/wDIpKSpIU5P7rPvP/kUpyf3Wfef/IpKSpIU5P7rPvP/AJFKcn91n3n/AMikpKkhTk/us+8/ +RSnJ/dZ95/8ikpKkhTk/us+8/8AkUpyf3Wfef8AyKSkqSFOT+6z7z/5FKcn91n3n/yKSkqSFOT+ 6z7z/wCRSnJ/dZ95/wDIpKSpIU5P7rPvP/kUpyf3Wfef/IpKSpIU5P7rPvP/AJFKcn91n3n/AMik pKkhTk/us+8/+RSnJ/dZ95/8ikpKkhTk/us+8/8AkUpyf3Wfef8AyKSkqSFOT+6z7z/5FKcn91n3 n/yKSkqSFOT+6z7z/wCRSnJ/dZ95/wDIpKSpIU5P7rPvP9ym3ft98B3eOElMkkkklOV9VP8AxLdG /wDCGN/55YtDIqddRZU15qc9paLG8tJ7hZ/1U/8AEt0b/wAIY3/nli1UlPMPq+t3ThBFPW8Vv5rg K7o+ftcUfF+tvSLLW1Z1b+nZTdBXks2x5NfwsTK+tn1no6nfh5FWPgsbY5uO/JDgx7J9pFgkcLVx Kev9SsYOrU4ORgOHvNfvMfyZSU9Ix7HtD2EOa4SHDUEKSHRRVj1NpqaGVsENaOAAiJKR3VNuqfU+ drwWmDBg+ap0dEwKPVLGuL7m7H2OcS/b+6HHhaCSSnPp6H06kWj0zYb27LHWEvJb+7LuyWL0Tp2K Hiusu9Rnpu3kv9n7vu7LQSSU0MLouBg2erQw7wNrS5xdtb4NngK+kkkpSrYP83Z/x1v/AFblZVbB /m7P+Ot/6tySmwkkgZ2WzDxbMiwEtYJgalIC9FHRPInzSXntn1l6g7qP2wOIAMCr83b4Ltul9Rq6 jiNyK9J0c09ipcmCUACerHDLGZIDdSSSUTIpJJJJTxP1qzsnC61VZTY4bWh2yfbPwV3of1qyuoZ7 MW2trWuB1HkpfWT6uZnUswZFDmhrWbSDzosf6o4zh1steQ19AcC08nsofUJ+BLogYZ8tehnCH2Pf J0ydTOcpJJJJSkkkklKSSSSUpJJJJSkkkklKSSSSUpJJJJSkkkklKSSSSUpJJJJSkkkklKSSSSUp JJJJSkkkklKSSSSUpJJJJSkkkklKSSSSUpJJJJSkkkklKSSSSUpJJJJSkkkklKSSSSUpJJJJSkkk klKSSSSUpJJJJSkkkklKSSSSUpJJJJTlfVT/AMS3Rv8Awhjf+eWLVWV9VP8AxLdG/wDCGN/55YtK 1/p1uftL9oJ2t1JjsElPN9V+s/Tciy3puFhu6xkMJZYxrR6THDkPsfoI8lU+rX1c6vidT+33ZDML GdP+S6HF7NfEu/gqf2b/ABY5WVa/La3DzLHF99WU6zHfucZJIeWj7kfHf/i26LlMy8O6p2U3+abR Y+95J0gNY5ySnt0lXwsoZeLXkit9QsG4MtG14/rN7KwkpSShbu9N+z6W07fjC5jpXVbMemepZOSO o+jZZ9myGbK3Fkk+mdgmB5pKeqSXIu6r1Pp+L0/qV+Q69nUGONtBA2sLqzazZAnSIU2dS6nhV9Oz sjIdezqDHOtpIG1pLPUbsgfJJT1aS5XF6h1OuvpfULcl1repWbLMcgbGh0luyBOkLqklKVbB/m7P +Ot/6tyM95bw1zp8I/iQquFaRXZ+jf8Az1nh++7+UkpuqL2NsYWPAc1wggqHrO/0T/w/8kl6zv8A RP8Aw/8AJJKeI+svRaunZFd1U/Z7nat8D4LsemV49eDSMYBtZaCI81Q+smOc3pVrBU7ez3tJjt81 X+qPUDd030S1zn0HbpHHzIU85GeEG9YGiwxAjkIA0kHokkL1j/on/h/5JL1nf6J/4f8AklAzJUkL 1nf6J/4f+SS9Z3+if+H/AJJJSRcV1dp6R9Z6stmlV5Bd4a6OXY+q7/RP/D/ySwPrhiOy+neq2pwf QdwOnHfumTGl9tWflZAZOE/LP0H6vRMeHtDhwRITrF+rPUzl9Lrlrn2Vex8RyPmtb1nf6J/4f+ST gbALFOBhKUT0NJUkL1nf6J/4f+SS9Z3+if8Ah/5JFalSQvWd/on/AIf+SS9Z3+if+H/kklJUkL1n f6J/4f8AkkvWd/on/h/5JJSVJC9Z3+if+H/kkvWd/on/AIf+SSUlSQvWd/on/h/5JL1nf6J/4f8A kklJUkL1nf6J/wCH/kkvWd/on/h/5JJSVJC9Z3+if+H/AJJL1nf6J/4f+SSUlSQvWd/on/h/5JL1 nf6J/wCH/kklJUkL1nf6J/4f+SS9Z3+if+H/AJJJSVJC9Z3+if8Ah/5JL1nf6J/4f+SSUlSQvWd/ on/h/wCSS9Z3+if+H/kklJUkL1nf6J/4f+SS9Z3+if8Ah/5JJSVJC9Z3+if+H/kkvWd/on/h/wCS SUlSQvWd/on/AIf+SS9Z3+if+H/kklJUkL1nf6J/4f8AkkvWd/on/h/5JJSVJC9Z3+if+H/kkvWd /on/AIf+SSUlSQvWd/on/h/5JL1nf6J/4f8AkklJUkL1nf6J/wCH/kkvWd/on/h/5JJSVJC9Z3+i f+H/AJJL1nf6J/4f+SSUlSQvWd/on/h/5JL1nf6J/wCH/kklJUkL1nf6J/4f+SS9Z3+if+H/AJJJ SVJC9Z3+if8Ah/5JL1nf6J/4f+SSUlSQvWd/on/h/wCSS9Z3+if+H/kklJUkL1nf6J/4f+SS9Z3+ if8Ah/5JJSVJC9Z3+if+H/kkvWd/on/h/wCSSUlSQvWd/on/AIf+SS9Z3+if+H/kklJUkL1nf6J/ 4f8AkkvWd/on/h/5JJSVJC9Z3+if+H/kkvWd/on/AIf+SSUlSQvWd/on/h/5JL1nf6J/4f8AkklJ UkL1nf6J/wCH/klNrtwmC3yPP4JKZJJJJKcr6qf+Jbo3/hDG/wDPLFqLL+qn/iW6N/4Qxv8Azyxa VrXvqe2t/pvcCGviYPjBSU4f1nyWVjGxa+m1dTy8txbTVeG7BtEkuc4FV+iY/WqMxjbeh9PwMZ0+ pbjPG8f2RW2VS6h0Hq9mXi05X1heMgvLsaKGAhzRJ1HktDExurYHUsZuf1x2U28lrMc0sbvIE/Sb wkp6NOkkkpi4EtIaYJGh5WO/oWTmZlOT1TIbcMZtjaa6mbBNrfTc50kz7StpJJTgUfVmwtx6MzJ9 fFwmOZjVhu0w5pYC8zqWtKli/Vy1px68zJ+0Y2E1zMesN2mHDbLzJkhq3UklOFifV2+l2LVflerh 4Di7GqDIdPbe6ddsrdSSSUpVsH+bs/463/q3Kyq2D/N2f8db/wBW5JTZSSSSUxc0PaWnUOEFcd0V x6X9Y7sJ2ldxIb+Vq7Jcj9b6XYudjdRr0MgOI8W6qbAbMoH9MMWUVUh+iXrkkLFvbfj13N1D2h33 oqh20ZbXSSSSUsoX1NuqfU4S14IPzREySni/q1a7pnXMjplphlhO0eY4/BdouO+uGO/D6hjdVpEa gPI8W/7F1eHkNycWu9pkWNDp+KZDQmPZs8yOIQyj9MVL+8E6SZOntZSSSSSlJJJJKUkkkkpSSSSS lJJJJKUkkkkpSSSSSlJJJJKUkkkkpSSSSSlJJJJKUkkkkpSSSSSlJJJJKUkkkkpSSSSSlJJJJKUk kkkpSSSSSlJJJJKUkkkkpSSSSSlJJJJKUkkkkpSSSSSlJJJJKUkkkkpSSSSSlJJJJKUkkkkpyvqp /wCJbo3/AIQxv/PLFpW2Nqqda6drAXGNdAs36qf+Jbo3/hDG/wDPLFqQkp826zkfVLO6rX1C/Kzq SXHexpsaCSNoFf7vyWl9XnfVE9ZpbiOy7s4Amn7U6xwaO5G/hbP1kwsw2YWdhYzcv7HYX2Y2gLgR Eie4VTFd1Xq3WsTLf049Oow9xsssI3v3CNg29klPVJJJJKUkksGn6yi/rt/TK6ZpppfaMidHPrLW uaPhuSU7ySxOldbyMzEOdc2pmOGOsIY/c8BpPI+Shj/WO4uxrMvHFOLnNc7HsDpMNG73DzCSneSW DjfWK+x+JbdjCvDz3lmPZul0/mlzfOFvJKUq2D/N2f8AHW/9W5HdYxn0jEqrhXVCuyXD+et/6tyS m4kh+vV+8EvXp/eCSmay/rJhfbOk3NAl9Y3s+IWj69X7wTPtpc0tLhBEH5oxNSB7G0SFgju4n1Oz fX6b6LjL6Dtjy7LfXGdFtHTPrFdiOMVXEhvhPLV2Hr1fvBSZxU7G0tQsxG40d46JEkP16v3gl69X 7wUTIkSQ/Xq/eCXr1fvBJTR6/gjO6XdVEvA3M+IWX9Sc424VmFYf0mM6AD+6V0JupIguC4tjx0b6 1aGMfIMeUP8A9qZLSQl9Gzh9eLJj6j1x+m73CdCF9P7wT+vT+8E9rJEkP16v3gl69X7wSUkSQ/Xq /eCXr1fvBJSRJD9er94JevV+8ElJEkP16v3gl69X7wSUkSQ/Xq/eCXr1fvBJSRJD9er94JevV+8E lJEkP16v3gl69X7wSUkSQ/Xq/eCXr1fvBJSRJD9er94JevV+8ElJEkP16v3gl69X7wSUkSQ/Xq/e CXr1fvBJSRJD9er94JevV+8ElJEkP16v3gl69X7wSUkSQ/Xq/eCXr1fvBJSRJD9er94JevV+8ElJ EkP16v3gl69X7wSUkSQ/Xq/eCXr1fvBJSRJD9er94JevV+8ElJEkP16v3gl69X7wSUkSQ/Xq/eCX r1fvBJSRJD9er94JevV+8ElJEkP16v3gl69X7wSUkSQ/Xq/eCXr1fvBJSRJD9er94JevV+8ElJEk P16v3gl69X7wSUkSQ/Xq/eCXr1fvBJSRJD9er94JevV+8ElJEkP16v3gl69X7wSUkSQ/Xq/eCm1z XCWmQkpdJJJJTlfVT/xLdG/8IY3/AJ5YtVZX1U/8S3Rv/CGN/wCeWLVSU8r9YMCjExq22uz7an3P tfZjPJczfrBj80dkP6vY/QH5td2H1PJuvZMY19rp+bHQtT6z1/WKzEb+wrqqbAf0xt0Jb/JcQ4Ar l/q4/ow+sVVfUGXv69B22vsbczjxqgD5hJT6EkkkkpHkMssosrrf6b3tLWvidpI5XM4HQOq4HWsW z1GXYlGJZU9waAXOc9joPm6JldUmSU8tb0i/OzmPxsM9NpbVay8mB6hsbDRDZ4OqVXTOp5tXT8LJ oOOzp9bm2Wkgh7tnpt2R2XUpJKeXw+ndTsr6Z0+/HNTOm2b7LyQWvDZDdka6yupSSSUsQDyq+E1v p2aD+et/6tysqtg/zdn/AB1v/VuSU2NrfAJbW+ATpJKW2t8Altb4BOkkp5D64Y7sbMxupVCCCAT5 tMhdRiXV5ONXewAtsaHD5ql9YsIZnSbmAS9g3s+LdVS+pmb6/TjjuPvx3QB/JPCml6sIPXGa+hYh 6chHSb0G1vgEtrfAJJ1CyrbW+AS2t8AnSSUx2t8AuZ+u+BvxK82se/Hd7iP3T/tXToGbjMysW3Hf q2xpafmhIWCGTDPgyRl2P4NXoOa3O6XTfoXxtf8A1hytDa3wC4/6m5L8TOyek3aGS5g826Oj5LsU IG4hPMQ4MkgNj6h5FW1vgEtrfAJ0k5iW2t8Altb4BOkkpba3wCW1vgE6SSltrfAJbW+ATpJKW2t8 Altb4BOkkpba3wCW1vgE6SSltrfAJbW+ATpJKW2t8Altb4BOkkpba3wCW1vgE6SSltrfAJbW+ATp JKW2t8Altb4BOkkpba3wCW1vgE6SSltrfAJbW+ATpJKW2t8Altb4BOkkpba3wCW1vgE6SSltrfAJ bW+ATpJKW2t8Altb4BOkkpba3wCW1vgE6SSltrfAJbW+ATpJKW2t8Altb4BOkkpba3wCW1vgE6SS ltrfAJbW+ATpJKW2t8Altb4BOkkpba3wCW1vgE6SSltrfAJbW+ATpJKW2t8Altb4BOkkpba3wCW1 vgE6SSltrfAJbW+ATpJKW2t8AkABwnSSUpJJJJTlfVT/AMS3Rv8Awhjf+eWLRts9Kp9m1z9gLtrB LjHYBZ31U/8AEt0b/wAIY3/nli1UlPC9e+svRuoCmvqXS+sV1tfDGNpNYe46bTFg3K79X+sdAZn1 9MwejZeBfY0uD7scViB3Lt5K0vrHg9StfiZ/TRXbkYLy8UXHa14cII3diqOI36wdV6viZfUsWjp1 GFuc1jLm3WWOcIiWaBqSnqUkkklKSSWUz6xdPf1i7pDd5ux6jdZbA9MBpaC3dP0huHZJTqpLHx/r Nh3WVh9N1FOQHOxsiwNDLAwSdu1znDQT7gE+L9ZMTIuqYabqK8gOdjX2hoZYG8lu1znD+0Akp10l kY31kxMi6lno3V05LizGyXtaK7HN7NhxcPm0LXSUpVsH+bs/463/AKtysqthfzdn/HW/9W5JTZSS SSUpJJJJTFwBBB4OhXHdKJ6V9aLcM/zV5LW/P3NXZLkfrljvxszG6nVo5pAJ82mQpsBsygf0xTFm FAS/dNvXJ0HFyGZONXkM1ba0OHzCKodmVdJJJJSkydMkp4r6yVu6V1/H6nUIbaZd8W6OHzBXZ1WN srbY3VrwCPgVjfW3p/2zpL3NE2Y59Vny+kPuTfVDqH2vpTa3GbMc7HfDsmDSZH72rZyevBCfXH6J eXR3Ukkk9rKSSSSUpJJJJSkkkklKSSSSUpJJJJSkkkklKSSSSUpJJJJSkkkklKSSSSUpJJJJSkkk klKSSSSUpJJJJSkkkklKSSSSUpJJJJSkkkklKSSSSUpJJJJSkkkklKSSSSUpJJJJSkkkklKSSSSU pJJJJSkkkklKSSSSUpJJJJTlfVT/AMS3Rv8Awhjf+eWLVWV9VP8AxLdG/wDCGN/55YtVJTyn14uw 6z09nUcl2P0+y0jIFbyxztNPo6wO6F0Kj6it6nU7pWX6uZr6bPWe+f7JK0vrPnXUfZsbFxKszKyX OFYvA2NDRucdQVjdA6v1S3OwH5WBh42Pm7xXbUBvDmT7eNDokp7dJJJJSLI9Y0WehHrbT6e7jdGk rjKOk9ap6qyizHr3WYGQ27Ia9zg6yx7HOdJYPcTwPBdwkkp4qyjJ6pgdL6dTRZVfg1u+0l7C0MLa nV7ZOh3HwRGV5HUsfpeDXRZVdg1uGSXsLQxwrNe2TzJXYpJKePw2X5GP0fpwosZkdPs3ZO5ha1oY CPpHQ7l2CSSSmD698e4iPAwquFTNdnvd/O2jn+W5XVWwf5uz/jrf+rckpJ6H8t/3peh/Lf8AeipJ KReh/Lf96Xofy3/eipJKRej/AC3/AHrO+sHTftfSr2Auc9jd7ATOrdVqpEAiOyMZEEEdESFgh5v6 nZP2jp7qHPcH0OgAGPadV0Ho/wAt/wB65DpZ/ZP1ntwzpVcSG/B3uauzUmcVOxtMcQWYj6aO8dEf ofy3/el6H8t/3oqSiZEXofy3/el6H8t/3oqSSkD8Zr2Fhe4hwIInxXHdHnpP1kt6fY4squJDYMeb P7l265H664jqbcfqlWjmODXEeWrSmTG0v3WxypsyxHbKK/wuj1Xoj99/3pej/Lf96F07LbmYVWS3 /CNBPx7qynsBBBIO4R+h/Lf96Xofy3/eipJIReh/Lf8Ael6H8t/3oqSSkXofy3/el6H8t/3oqSSk Xofy3/el6H8t/wB6KkkpF6H8t/3peh/Lf96KkkpF6H8t/wB6Xofy3/eipJKReh/Lf96Xofy3/eip JKReh/Lf96Xofy3/AHoqSSkXofy3/el6H8t/3oqSSkXofy3/AHpeh/Lf96KkkpF6H8t/3peh/Lf9 6KkkpF6H8t/3peh/Lf8AeipJKReh/Lf96Xofy3/eipJKReh/Lf8Ael6H8t/3oqSSkXofy3/el6H8 t/3oqSSkXofy3/el6H8t/wB6KkkpF6H8t/3peh/Lf96KkkpF6H8t/wB6Xofy3/eipJKReh/Lf96X ofy3/eipJKReh/Lf96Xofy3/AHoqSSkXofy3/el6H8t/3oqSSkXofy3/AHpeh/Lf96KkkpF6H8t/ 3peh/Lf96KkkpF6H8t/3peh/Lf8AeipJKReh/Lf96Xofy3/eipJKReh/Lf8Ael6H8t/3oqSSkXof y3/el6H8t/3oqSSkXofy3/eptbtEST5lSSSUpJJJJTlfVT/xLdG/8IY3/nli1VlfVT/xLdG/8IY3 /nli1UlPM9U+sf1YHUG15VzhfgOJ9RrTsDo1YX8T5LL+rv7Gu6821rMyguL7cGjI0pJd9J1SFk9O +tDenZnSq+k1XV35Flzcg2gEh1m8HbHgtLHZ9ZM7qfTXZvTWYePhOLnWNtDz9HbEQElPWpJJJKUk koNsrcSGuBLfpAEGPikpmkhsvoe7ayxrnd2tcCfwTixjnFrXAubyAdQkpmkoCxhcWBwLhy0HUfJT SUpVsH+bs/463/q3Kyq2D/N2f8db/wBW5JTZSSSSUpJJJJSkkkklPJfXPHdTkY3UqtHNIa4jxGrV 0uFkNysSnIbqLGB33hVuvYQzel31AS4N3M/rN1WZ9S831cF+K4+6h2g/klTH1YQeuM19CxD05D2n r9XpEkklCyqSSSSUsqXWcFud06/GPLm+0+BGoV1JIi0xkYkEbg28r9SM0+ld0+3R9LiWg+HddUuJ zQei/WlmQ3205B93h7tCu1aQQCNQdQmYzpX7ujPzURxDIPlyji+vVkkkkntdSSSSSlJJJJKUkkkk pSSSSSlJJJJKUkkkkpSSSSSlJJJklLpJJklLpJk6SlJJJJKUkkkkpSSSSSlJJJJKUkkkkpSSSSSl JJJJKUkkkkpSSSSSlJJJJKUkkkkpSSSSSlJJJJKUkkkkpSSSSSlJJJJKUkkkkpSSSSSnK+qn/iW6 N/4Qxv8Azyxaqyvqp/4lujf+EMb/AM8sWqkpSSSSSlJJJJKWcAQQeDoVyTcc431oxqfs4wa8ii+q j0zIucBu/SRxtAldY9oe0tdqHCCPIrPx+gdNx7xkMbY+1jSyt1ttlmxruRX6jnbfkkpwaXXdBqZg ZGLUMm2i70Muklxc5gc/3y0HhCDGYWL0bNw9MnIqcbnDU2TWXuLvH3LpMfoXTqLvXDX22hpY199t lxa13LW+q50A+SbE6B0vDtFtFTtzQRWHve9rA7kVte4ho+CSnnsWqunE6Fn06ZeVb+ntB9zw8OLt y7NZuN9X+l4uQMimtwcwk1tc97mMLudlbnFrZ8gtJJTB5s02AHxkwquEb/Tshrf563uf33eSuqtg /wA3Z/x1v/VuSUk3ZH7rfvP9yW7I/db95/uRUklIt2R+637z/cluyP3W/ef7kVJJSLdkfut+8/3J bsj91v3n+5FSSUhPrkRtbB8z/cuPwTZ0j6z2Y8AMvJgdofq1dquU+ueM6uzH6jXo6s7XEfeFNgOp gdpimLKNBIfol6ecj91v3n+5Kcj91v3n+5D6flNy8KnIbqLGg/PurChIo0yA2LR7sj91v3n+5Ldk fut+8/3IqSSUW7I/db95/uS3ZH7rfvP9yKkkp5r644NuR08ZO0B+Md0gyY7q39XOo25vS6nANLqx sdJ10+S081tb8S1tglhYdw8oXBfV7r9fSLLm2Ne+iwywNiR95UciIzB/ebeOEsuCUQLljNx+r385 H7rfvP8AclOR+637z/cgdM6jV1LEblVNcxriQA6J0+Eq2n21SCCQdwj3ZH7rfvP9yW7I/db95/uR UkUIt2R+637z/cluyP3W/ef7kVJJSLdkfut+8/3Jbsj91v3n+5FSSUi3ZH7rfvP9yW7I/db95/uR UySke7I/db95/uS3ZH7rfvP9yKmSUj3ZH7rfvP8AclOR+637z/cibglKSkc5H7rfvP8AcluyP3W/ ef7lNzmtEuMDxKoZXXuk4s+rksBH5oMn7ggSBukRkdgT5Nycj91v3n+5Kcj91v3n+5YT/rfXadvT 8S7Kd2IEN+9R+0fW/N/mqqsFh7u9zh9/9yHGOmrJ7Ev0qh/eLe611mzpOO259Qs3u2wHR/BY9X16 9S1lf2WN7g2d3iY8ELq31b63bQ19mU7NtLtauGt8xqsuv6r9bFjCKSzUe6RprymSlO9AabWLDyxx +qYMter6CHZBE7W/ef7k85H7rfvP9y53d9benfSDOoVD5PhGo+uGHu9POqsw7O4eDH3hP4h1082q cEt41Mf1Xc3ZH7rfvP8AclOR+637z/coY2diZTd2Pa20fyTKOnMZBGhFI92R+637z/cluyP3W/ef 7kROkhFuyP3W/ef7kt2R+637z/ciJ0lIt2R+637z/cluyP3W/ef7kVJJSLdkfut+8/3Jbsj91v3n +5FSSUi3ZH7rfvP9yW7I/db95/uREklI92R+637z/cluyP3W/ef7kVJJSLdkfut+8/3Jbsj91v3n +5FSSUi3ZH7rfvP9yW7I/db95/uRUklIt2R+637z/cluyP3W/ef7kVJJSLdkfut+8/3Jbsj91v3n +5FSSUi3ZH7rfvP9yW7I/db95/uRUklIt2R+637z/cluyP3W/ef7kVJJSLdkfut+8/3Jbsj91v3n +5FSSUi3ZH7rfvP9yW7I/db95/uRUySke7I/db95/uS3ZH7rfvP9yIkkpHuyP3W/ef7lNpdHuAB8 lJJJSkkkklOV9VP/ABLdG/8ACGN/55YtVZX1U/8AEt0b/wAIY3/nli1UlKSSSSUpJJJJSkkkySl0 kySSl0kydJSlWwf5uz/jrf8Aq3Kyq2D/ADdn/HW/9W5JTZSSSSUpJJJJSkkkklLKh1vDGZ0y6mJd tJb8RwtBMRIg8FEGiD2QRYI7vN/UrML8OzDefdQ7QeRXSLjcaekfWp9X0acg6fB2v5V2Skzj1cQ2 mOJZiPp4TvE0ukmSUTIumTpJKQ5LC/Hta0S5zCAPiF5v/wA3utf9xLPuXpqUJk4CW7Pg5mWHi4QD xd3kOlYX1rwsNpxjXsBP6taII/J+VXB9Y+q4unUemvAHNlXuH3f7V0aYtB51REa2JRLOJEmcIm+2 hcjG+tfR7ztdb6L/AN2wFv5Vp1ZWPeJqsa8eRlByOk9OyQRdjsfPeNVmW/U/AndiW24j+2xxj7il 6h4qrCesof8AODvJLnP2Z9aML+i5rclg4baIJ/1+Kzur9f8ArHiNrZdUMV5J97YcHfeCgZ1qQUx5 czIEJxlf0e0SXn2J9autnJrDn+sCf5sNaC7y4W/+0/rTk/0fAZSPG10/+RSGQHa05OUyQIEjEX/W eiTFzW8kD4rnf2f9asn+eza6GnkMEn8ik36pus/pmffd5A7R+Uo2eg+1Z7cB82Qf4IJde7qnT6BN uQxvxcFn5P1s6NW0tZd6jiCBsBd/BSp+qfRajJp9R3i8kq/V0zp9IirHrZ8GgJerwCv1A/fl9gfM bsq99z3ix4DnEgbj3K3/AKvN+sWThuZg3Mqp3HdY/wBzp8pldC76qdEc4vdRq4yfc7v81ewOnYnT 6jTis2MJkiSdfmmRxyBsltZucxyhwwhr/WDit+ql2Qd3UuoXXn91p2t/GVfxfq10bGgsxmucPzn+ 8/8ASlaiSeIjs1DmyHTiIHYaD8GLKq6xDGho8AIUkkk5jUknSSUsg5GJjZLdt9TbWns4A/lRkklA kbOBk/U/p7nGzDfZh28g1nSfgf70D0Prb03+atZ1CkcB/wBOPy/iV0ySbwjpoyjPPaVTH9bV56r6 3V1u9PqWLZiP4JI3N++FXu+vWMy1zGY7rGAw14cII8V0t2PTe0ttY14PZwlcFm/Vbqpy7jTR+iLz sggCE2fGBpqz4By+QnjHB/haPWdD67X1dlr21mr0iBBIMytSR4rjui/VTKLLDmWW4rpGwVuifitP /mo4fR6hkD5oxMq1CzLjwCZEclDyv8XfkJLn/wDmvlD6PVLx/r8U3/NnqP5vVrh8p/78jZ/dY+DH /nP+aXoUHKzMbDr9XJsFTJjc7QSVif8AN7q4+j1aw/Fv/mSyvrF0zqWNhB+TnHJZuA2OEfPlK5HQ RNpjixki8orru9K36w9GcQ0ZdZJ0AnxWgCCJHBXk7GkPYWGHBwgnjldlXm/WmpogY17QOzgD+VEj JE1OP2JljwyiJYsgP9409OkucH1h61V/P9NJHdzHT/BSb9caG6X4l9R7kgEfglxBb7E+lHyIehSW LV9buiv0NpYf5bSP4K5V1zpVv83k1n5hLiHdacWQbxP2N5JYOZ9cMHFyXUGqyzZ+ezaWn8Ufpf1l w+pWPY1jqfTEk2EAH7iUegPQ6I4JaitQLLsJlXd1DCb9K9g/tBBf1vpTPpZNY/tBCx3UISO0T9jf SWU76zdEb/2qYfgZQXfW7orf8I53wa4/wS4h3T7OT9yX2O0kuU6x9a8e/CfXhG1lro22bS2PmVzn 7Y6qP+1dpI/lFERlIExjxCOui72gDETmISkaAL6ckuZxvrTkjHrH2G6xwaAX6QT4qR+tPUD9Hprv m6P4IcXgfsUcEx2/xg9KmXMH6z9XPHT2t/rWD+5Dd9Zus/8AcelnxsCWvY/YUeyesoj/AAg9WqWR 1npmLaacjIZXYOWuMHVc676zda/7qN+Lx/5Jc/1PIuy8x+RkFjrHASatW6fenRhkkQIxP1Vw4oAy yTFAfomzb6JidV6fmPLMa9trgJIaZ0VtcJ9T8mijqTha7YbW7W+ZXdpShKBqQ1WGWOVHGSY113XS SSQQpJJJJTlfVT/xLdG/8IY3/nli1VlfVT/xLdG/8IY3/nli1UlKSSSSUpJJJJSxEgjie65A512D 1w11PyGVDGuc5uVP6WxmoNQPhyV1zhuaWzEiJCyW/V9r8urJzch+U7HY9lIfADRYNjjp326JKcSz LzOm4fTOpi+y6zOY45DHOlpLqzYC0dtpRGZGXgU9L6h69lz86tzshj3S0k1mwbR2hauN9WaKzU26 599GM1zMep/DA8bfnoU+J9XKaH0+rc++rGa5mPU/hgcI+eiSnKxbsumnpHUjkWWW9Qt25DHOlkPB Ptb2iF1qx8T6uU49lG699tGI4uxqHcMJ/uWykpg+zb+a53wEqrhXRXZ7H/ztvb+W5XVWwf5uz/jr f+rckpJ6/wDIf/mpev8AyH/5qKkkpF6/8h/+al6/8h/+aipJKRev/If/AJqXr/yH/wCaipJKRev/ ACH/AOal638h/wDmoqZJTx31xso+0491ZLclnLSIMdlr9D+sFPUKBW8EZLBDmATMdwqP1n+rr8hz s/Fl1kfpK/GO4WJ0/C6pg+n1QUOdUx2reDHw8FbEcc8IF+qO38GsZTjkJrQvf+t/If8A5qXrfyH/ AOaqnS+tYfUq5pdtsH0q3aOCvqqQQaIotgEEWCj9f+Q//NS9f+Q//NRUkEovX/kP/wA1L1/5D/8A NRUklIvX/kP/AM1L1/5D/wDNRUklIvX/AJD/APNS9b+Q/wDzUVJJSL1h+4//ADVk9d6QzrDag51l XpEnRkzK2kkCLFLoTlCQlE0Q8rhfVGvEyqsgXWONbg7b6fMfNdN638h/+aiJJCIGwTkyzyEGZshH 638h/wDmpet/If8AcipIrEXr/wAh/wDmpev/ACH/AOaipJKRev8AyH/5qXr/AMh/+aipJKRev/If /mpev/If/moqZJSP1/5D/wDNS9f+Q/8AzUVJJSL1v5D/ALkvX/kP/wA1U+s9Yo6Xjl7zutd/N19y Vj9E+tjbnup6g4McSSyzgfAp4xTlEyA0WHJAHhJ1ek9b+Q//ADUvW/kP/wA1U3/WDo7PpZTPy/kQ XfWrozeLi7+q0lDgn+6U8cf3g6XrfyH/AOal638h/wDmrIP1u6b+Yy158mFQP1qaf5vByH/2YR9q f7qPch3dr1v5D/8ANQMjqeLjFoyCa95hu4clZf8Azg6k/wDmemWnw3aLlOtZOffmudmtdXYPo1n8 0eSkx4DI0SBosnmERYD6KLwRIY8g94UbMyqsTZLR5iFyXQ/271Kn0mZDqcasR6kanyC16/qpjuO7 MyLch3fc6B9ybLHGJIlLbsuE5SFiLYt+s3SKSWutlw7NBJ/BVXfWiy47cDBtuPZzhtC0cfonS8aP Sx2SO5En8VdaxrRDQGjwCbeMbRMvNNTO5A8nnDkfWvLMCpuGzxIkqvmfVzPyqHOvyrLrwJawtIZK 6xJEZSD6QI+SDjBGpJfNsLoubk5n2Z1bmbD+lMfRC6ofVnpgaBtvBjUglbwY0EuAAJ5PinTsnMTk R+j5IhhjG+rz5+rGD2flN+Diou+rOOeL8n56rokkz3Z91/BHt9jy1n1Qofzdd82BAd9SKe19nzr/ ANq7BKEDkJ3o/RcLG0pD6l806n0nJ6dbssa70phlhEAo3Seg5XUdzwXVUj/CAEyfBd/lYmPl0mnI YHsPYqVNFVFTaqmhjGiAApTnBxiHCL/BjjCUchmJF5D/AJkT9K95/sFOPqRWOb3/APbf+1dkkohK ug+xlMpnecvteRb9S62mRkWA+Vf+1Fb9VNnGTcP+thdSkj7kvD7FpF9ZfaXlr/qs59LmjIucY9rX M0n5Lna+i57837H6ThYOdOB4r0tNsbu3QNx0nunw5iUQRobY54YyINl52n6r4wra223Jc4DWCQEQ fVnpg+kMh3xJW+kme7P94ruCPZwx9WujDnHsd8dyI3oHRm8Ybj8QVsJIe5P94/angj2Dlt6R0hv/ AGi+9qpdY+r2Jl0fqtJovZ9GGwD5FdCkiMkwQRIqMIkUQHmPq50D7GftObU43/mMiQ3z+K6P1v5D /uREkJzMzclRiIigj9f+Q/8AzVNrtwmCPI6FSSTVykkkklOV9VP/ABLdG/8ACGN/55YtVZX1U/8A Et0b/wAIY3/nli1UlKSSSSUpJJJJSkkkklKSSSSUpJJJJSlWwf5uz/jrf+rcrKrYP83Z/wAdb/1b klNlJJJJSkkkklKSSSSUpJJJJSyYtbG2BHgpJklOB1T6tB1n2zpjvs+U3WBo0qHTfrI+u37F1dho vGgsOjSuiVLqXScPqVXp5DJI+i8fSHzUgyAjhmLHfqGMwINw08OhbjXBwDmmQdQQnXJizq/1bfFk 5XTp+l3b/cui6f1LE6hSLcZ4cPzm9wfAhCWMjUHij3CYzB0OkuzbSTJ0xepJJJJSkkkklKSSSSUp JJJJSkkkklKSSSSUpJMkkpSSSo9R6zgdObORYN/aturj8kQCTQFoJAFk03lmdS+sHT+nja53q3dq mamfNZRy+vddO3EYcLDPNrtHOHktLpv1cwMEixw9e/k2v1M+SfwRj85s/uj9pWcUpfKNO5cPJ6d1 j6w2farKhjVtb+iDuSq3R/qxlZGWRmMNdNRh8/nHwC7vyCSf95mAYgCI2Hgj2Ikgk2WizofSmCG4 zNPESjN6fgs+jQwf2QrCdQ8Uu5ZOEdgjFFI4Y0fABTDQOBCdJBKyz+q9FxOptaLhD2nR45+C0EkR Ig2DRQQCKIRY2NTi0tppaGsaIACKknQ8SlSSSSSlJJJJKUkkkkpSSSSSlJJJJKUkkkkpSSSSSlJJ JJKUkkkkpSSSSSlJJJJKUkkkkpSSSSSlJJJJKUkkkkpyvqp/4lujf+EMb/zyxaqyvqp/4lujf+EM b/zyxaqSlJJJJKUkkkkpYzBjQ9iuf+29Vxeu1dPdkDMbfj23WNDA01FkbCI7OJjVb7t207Y3QYni Vh9G6V1jBvuvyn4992US6/JG/wBQwPY1oIgNb4JKavSet2DHdbnZlhzWVPsfhW0mn6M/R3tbujyS q6v1TFbgZuZa26jqDHOdSGhvpnZ6jQ1w5001Vu7omb1DMqyOp2VbcdljK2UB2psbsLnF3l2UMb6v ZhGLRn3V242AxzKAwEOdI2AvnuG+CSkGL1XqrW9Nz77m2UdSs2OxwyAwOks2u57Lp1z+J9X82s4e Pk31vw+nOL8cNB9R3Zu+dNJ7LoElMH21s+m9rZ4kgflVXCyKBXZNjR+ltP0h++5XFXwf5uz/AI63 /q3JKSfacf8A0rP84Jfacf8A0rP84IkJQkpH9px/9Kz/ADgl9px/9Kz/ADgiQlCSkf2nH/0rP84J facf/Ss/zgiQlCSkf2nH/wBKz/OCX2nH/wBKz/OCJCUJKR/acf8A0rP84Jfacf8A0rP84IkJQkpH 9px/9Kz/ADgl9px/9Kz/ADgiQlASUiddivaWPsY5p0IJEFc3n9EGLd9u6JkNqtGrqdwg+Q1/BdSk nQmYnT7FsoiW/wBrg9I+tFGU4Y2aBj5Q0M6NJ8itZ2fhMsbW69ge/wCiNw1VHrvRcbqGM94rnJY0 mt7dHSOy4K6zJF36Zz/Vq0G4nc2FNDFDLrE8PgxSySx6SHF4vp/2nH/0rP8AOCX2nH/0rP8AOC5r pn1mzRiM9fCuvIEesxuhA+Suf86qh/OYd7f7KjOGYJFX5MgyxIu3Z+04/wDpWf5wS+04/wDpWf5w WMPrf00fTrub8WKbfrb0c8ue34tKHtT/AHSr3Idw632nH/0rP84JfaMf/Ss/zgs1v1o6IebwPiD/ AHKj1r6141ePs6e8W3WaB44aPHVKOKZIHCVHJEC7eg+04/8ApWf5wS+04/8ApWf5wXK9A+tYaPs/ U36DVlx/I5bDvrR0QcZAd8Af7kZYZxNUT5KjlgRdgOl9px/9Kz/OCX2nH/0rP84LJd9bekDhz3fB pUP+d2Af5um5/wAGIe1P90q9yH7wdn7Tj/6Vn+cEvtOP/pWf5wWL/wA6S7+b6fkP+DUv+cPUX/zf S7v7WiPtT7fiFe5Hu61mfhVFosvY0vMN9w1Khl9V6fiVGy69gHYAgk/ABefdXy87JzXPzA5lrTAr Om0eAWx9WOmV9Ssfk57X3+nAY55JaY7a8qQ8uIxEpS8wGMZjKRjEfa2revdS6s809LaMenh2RYQD HkrfTvq/0zHf9oy7m5eSdS57gQD8JW6ytlbQxjQ1o0DQIAUoUZyaVEcI/H7WQQ6yPEUQvxgIFjAB wNwT/acf/Ss/zgiQlAUa9H9px/8ASs/zgl9px/8ASs/zgiQlCSkf2nH/ANKz/OCX2nH/ANKz/OCJ CUJKR/acf/Ss/wA4Jfacf/Ss/wA4IkJQkpH9px/9Kz/OCX2nH/0rP84IkJQkpH9px/8ASs/zgl9p x/8ASs/zgiQlCSkf2nH/ANKz/OCX2nH/ANKz/OCJCUJKR/acf/Ss/wA4Jfacf/Ss/wA4IkJQkpH9 px/9Kz/OCX2nH/0rP84IkJQkpH9px/8ASs/zgl9px/8ASs/zgiQlCSkf2nH/ANKz/OCX2nH/ANKz /OCJCUJKR/acf/Ss/wA4Jfacf/Ss/wA4IkJQkpH9px/9Kz/OCX2nH/0rP84IkJQkpH9px/8ASs/z gl9px/8ASs/zgiQlCSkf2nH/ANKz/OCX2nH/ANKz/OCJCUJKR/acf/Ss/wA4Jfacf/Ss/wA4IkJQ kpH9px/9Kz/OCX2nH/0rP84IkJQkpH9px/8ASs/zgl9px/8ASs/zgiQlCSkf2nH/ANKz/OCX2nH/ ANKz/OCJCUJKR/acf/Ss/wA4KbXNeNzSHDxGqeAnSUpJJJJTlfVT/wAS3Rv/AAhjf+eWLVWV9VP/ ABLdG/8ACGN/55YtVJSkkkklKSSSSUpJJJJSkkkklKSSSSUpVsH+bs/463/q3Kyq2D/N2f8AHW/9 W5JTZSSSSUpJJJJSkkkklKSSSSUpJJJJSkkkklKSSSSUssrqX1cwOoXsvsGx4Mv2/nDwK1UkYyMT YNIMQdwwqqrqrbVW0NY0Q1o4gKUDwTpIJWLGHlo+5QdjY7vpVMPxaERJKyig13dN6e76WNUfixv9 yzerfVnBzKT6FbaLm/QcwQD5ELaSTozlE2CQgwiRRDyfQvqmWWG7qTAQ0wyo6g+ZXRt6b09v0cWp vwY3+5WUkZ5JTNkojjjEUAjbjY7fo1MHwaAp7GDsE6SZa5UBJOkkly+rdBw+plrrRssafpt5I8Cr 2NjU4tLaKWhlbBAARUkTKRABOg2RwgG61UnSSQSpJJJJSkkkklKSSSSUpJJJJSkkkklKSSSSUpJJ JJSkkkklKSSSSUpJJJJSkkkklKSSSSUpJJJJSkkkklKSSSSUpJJJJSkkkklKSSSSUpJJJJSkkkkl KSSSSU5X1U/8S3Rv/CGN/wCeWLVWV9VP/Et0b/whjf8Anli1UlKSSSSUpJJJJSxMAkCSOyx29ffV 1BmFnYpxjdVZdS/cHgtq1cDHBgrXcdrS6JgEwOSuVw68nqmXk5Wfj3U5V9VmPisc32U1Ed3fvO7p Kb9P1mBdRZk4zqMXMa52NcXA7g0F3ub2kCVLG+snqWY5yMZ1GPmNc7GuLgdwaN3uHaQsp3Tuo9Sw undNsxn45wGOF1ro2lzazU0Mg6zyp14PUM+jpuDbjPx/sFbm3WvjaXBnpt2QdZ5SU6WN9ZDdZjOs xnVYua4sxry4HcR4t7Sttcph4fULquldPsxn1Hptm6+50bCGAhuwjndK6tJSlWwf5uz/AI63/q3I z2bo9xbHgYVfGxnsY8Oc4E2PcNexcSCkptpIXo/y3/el6P8ALf8AekpKkhej/Lf96Xo/y3/ekpKk hej/AC3/AHpej/Lf96SkqSF6P8t/3pej/Lf96SkqSF6P8t/3pej/AC3/AHpKSpIXo/y3/el6P8t/ 3pKSpIXo/wAt/wB6Xo/y3/ekpKkhej/Lf96Xo/y3/ekpKkhej/Lf96Xo/wAt/wB6SkqSF6P8t/3p ej/Lf96SkqSF6P8ALf8Ael6P8t/3pKSpIXo/y3/el6P8t/3pKSpIXo/y3/el6P8ALf8AekpKkhej /Lf96Xo/y3/ekpKkhej/AC3/AHpej/Lf96SkqSF6P8t/3pej/Lf96SkqSF6P8t/3pej/AC3/AHpK SpIXo/y3/el6P8t/3pKSpIXo/wAt/wB6Xo/y3/ekpKkhej/Lf96Xo/y3/ekpKkhej/Lf96Xo/wAt /wB6SkqSF6P8t/3pej/Lf96SkqSF6P8ALf8Ael6P8t/3pKSpIXo/y3/el6P8t/3pKSpIXo/y3/el 6P8ALf8AekpKkhej/Lf96Xo/y3/ekpKkhej/AC3/AHpej/Lf96SkqSF6P8t/3pej/Lf96SkqSF6P 8t/3pej/AC3/AHpKSpIXo/y3/el6P8t/3pKSpIXo/wAt/wB6Xo/y3/ekpKkhej/Lf96Xo/y3/ekp Kkhej/Lf96Xo/wAt/wB6SkqSF6P8t/3pej/Lf96SkqSF6P8ALf8Ael6P8t/3pKSpIXo/y3/eptbt EST5lJTJJJJJTlfVT/xLdG/8IY3/AJ5YtVZX1U/8S3Rv/CGN/wCeWLVSUpJJJJSkkkklKSSSSUpJ JJJSkkkklKSSSSUpJJJJSkklldX627pluPWMWy9t9rKnWiG1s3mB7jyfIJKdVJJJJSkkkySl0lld Z627pZpAxbMgWva11jYaxgcdsuce/kFoX3ejj2XkSK2F+3xgTCSkqSzOj9Sz+o1NyLcamjHsbuYW Xm1+vZzDSwD/ADlpJKXSSSSUpJJZ3VeoZ+DU+7Hwxk1UsNlrjaKzDdSGja6THjHxSU6KSr4OXVm4 dOZVIrvYHtB0MOEqwkpSSSSSlJJLM6v1LO6fW++nDGRj0t32vNorMDkMbtduPxhJTppKoOoVv6b+ 0K2l1Zq9ZrToSI3QgdI6jndQqbkXY1NFFjQ6s13m1+vZzfRrA+9JTpJJJJKUkkkkpSSzOsdTzOnV PyKsQX49TS+17rRWQB2Y3a6T8YV3FyG5WNVkMBa21ge0O5AcJ1SUmSSSSUpJJJJSkll9Y6rmdNqs yWYYvxaG77rDaGOgchjNrtx+JCPldSbR0p/UmsL2Nq9ZtZO0kEbgDzCSm6kqHTMvPy6hbk0U0Me0 OZ6VxuPuE+6aq4V9JSkkkklKSSUXOaxpc4w1okk+ASUySWP0P6ws6xkZlVdDqWYj2tZY50+oHCdw ECAthJSkkkklKSSUXvbWxz3kNa0S4nsAkpkksfoP1gb1p+WGY7qGYr2tY5zpNjHAlr4gRMJ3dXzn 9Wv6fi4tT24wrNltt5rJ9QT7WCl8x8UlOukmExrynSUpJJJJSklT6tn/ALN6bkZ2z1fs7C/052zH bdDo+5Lp+RnZDN+XRVSCAWejcbpnx3VVQkpuJJJJKUkkkkpSSpdX6iem9PtzBX6xqAisu2AkmPpQ 6PuUsC/OurL8umqk6bBTabgQfEuqqhJTbSWQOr513U78LFxansxi0WWW3mtx3CfaxtL5+9aw80lL pJJJKUkkq3UM6np+JZl3yWViYbySeAPMpKbKSpdPys7JaXZWMzHaQCwMt9V2vZ42N2n4Eq6kpSSS SSlJJJJKcr6qf+Jbo3/hDG/88sWqsr6qf+Jbo3/hDG/88sWqkpSSSSSlJJJJKUkkkkpSSSSSlJJJ JKUkkkkpSSSSSlLB+tX2m2nGpx8W7IczIquca2yA1h1+a3kklMKn+pW15aWbhO1wgjyKmkkkpSSS SSnC+tX2mzFqoxsa3Id6rLCa2yAGOkyr7su12yv7Ha+u2pznkwII/McCeSrySSnm8HAsHW6cnBw7 On4ddb25LX+0WOMbQGbjx4rpEkklKSSSSUpc/wDWV+fkPr6dVj3OwrhOXfS3cS3/AEY10ldAkkpB hhgxam11mljWgNrcILQNIIR0kklKSSSSUpc99ZH52TfV05mNe7AeN+XdS3cXAH+ab8e66FJJTnsv O37M3Cs+zijcJAAPb0tpPMLL6bgWDrleVh4lnT8FlLmX12e0WPJBbtYHO+j4rpEklKSSSSUpJJJJ Tg/WXHGZU7GdgX5Liw+hbU6Gh543e4ceYWn0qrKp6dj1ZZDshlbRYR4gK2kkpSSSSSlJJJJKef8A rNijNqfjnAvyLdn6vbW6GB543e4DQ/vBWqX5jMNuFnYrsotx2+u9u3a98Q5gBI1Wskkp57o+DdX1 izKx8azB6eagz0bDG6wH6QZJjRdCkkkpSSSSSlKl1fDyM7Atxca0UWWab3AuEdxAIV1JJTzn1e6Z 1XC6rnuyRUMZ4qbUa2lodsbHtlx4XRpJJKUkkkkpSodawcnqGA/Fx7RS6wjc5wLgWzq3QjlX0klP MdIxes9MzOqZF9Lbq7HVejXQ0t37W7fZucdApdewzmeoMbp1o6g8MFeYIaGx3Lw781dKkkpHjtsZ RWy07rGtAc7xIGqIkkkpSSSSSmtnit2JYyyg5VbhD6GgEuB7Q4hZPQ8K+rqeTk1UWYWA9jWsx7Dq Xjl4buO1b6SSlJJJJKUkkkkpq9RbW7Ee23Hdl1u0dS0Akj4EhYvS6M3CyM7Now7a8OxtYowSRvLx O94aXHaF0iSSnmevYbsz1GYnTrWdQft9PMEMa0iDuLw7sujpa9tTG2Hc8NAc7xIGpU0klKSSSSUp ZX1m6fd1Ho92NQ3fYS1zWTG7Y4O2zpzC1UklPPdEwr6+qW5VWNZg4Rpaw02HV1gP0g3c7jxXQpJJ KUkkkkpSSSSSnK+qn/iW6N/4Qxv/ADyxaqyvqp/4lujf+EMb/wA8sWqkpSSSSSlJJJJKUkkkkpSS SSSlJJJJKUkkkkpSSSSSlJJJJKUkkkkpSSSSSlJJJJKUkkkkpSSSSSlJJJJKUkkkkpSSSSSlJJJJ KUkkkkpSSSSSlJJJJKUkkkkpSS5v65dQy8KrD9O1+Nh23bczKqEurZGnw17pPspxPq7m5bOqXZmN s3syGOa6xgAEhrv70lPSJLB6h9Y/2Vg15L8W7Jxm0NtfkAt0BH5090S/6y0VUYbm49tmVns9SnEa P0m0CSXeEJKdpRDmuEtII8Qufy/rTQ/oXUsupj6cnCY5tlFmj2vI9v3rG643quB9XeiYfTsp9GVl WtFlrTq5z2Gwgz5pKe7USQBJMAckrAxvrM0/VT9r2fz9dZY+vv67fZt+blnfU53U86rq2B1jIfkP Dgw7j9D1GSWt+EpKexkHUJ1g/UvMtyehV13kuvw32YthPJNTiwE/JbySlJJJJKUkkkkpSSSSSlJJ JJKUkkkkpSSSSSlJJJJKUkkkkpSSSSSlJJJJKUkkkkpSSSSSlJJJJKUkkkkpSSSSSlJJJJKUkkkk pyvqp/4lujf+EMb/AM8sWqsr6qf+Jbo3/hDG/wDPLFqpKUkkkkpSSSSSlJJJJKUkkkkpSSSSSlJJ JJKUkkkkpSSSSSlJJJJKUkkkkpSSSSSlJJJJKUkkkkpSSSSSlJJJJKUkkkkpSSSSSlJJJJKUkkkk pSSSSSlJJJJKc3q+ZditYBgvzqLJFza4Jb4e13K5MdEz3dP+sV2JhvxMbPra3DwDG7e0He/aNG7p XfJJKeL61+0LLuldOvwb7ul49TL8sVAH1LWACul2o9oOpT9f6ZdmdTwOt/Zcl+KKHU241LzVfXuO 5p9rh8Ildmkkp4jJ6LQfq11h+Jh5GNdfXuP2l5e+w16jkuhW86q/qmJ9WsrErNtdd9Vtpbw1oZBJ +a6pzWvaWOEtcIIPcFAwMDG6fjNxcVpZSwktbJMSZ03E6JKeRf8AV7qf/Oc4gr/yFZaM5x7eqPzP v1Wt0HEyMTqvW8jIrNVNtwfU88FobyF0KFk49eTRZj2gmu1pY8AlpIcIOoghJTz/ANQ2OPR7sxwg Z2VfkMB/dc87fvAXSoOLjUYmPXjY7BXTS0MrYOABoAjJKUkkkkpSSSSSlJJJJKUkkkkpSSSSSlJJ JJKUkkkkpSSSSSlJJJJKUkkkkpSSSSSlJJJJKUkkkkpSSSSSlJJJJKUkkkkpSSSSSnK+qn/iW6N/ 4Qxv/PLFqr5VSSU/VSS+VUklP1UkvlVJJT9VJL5VSSU/VSS+VUklP1UkvlVJJT9VJL5VSSU/VSS+ VUklP1UkvlVJJT9VJL5VSSU/VSS+VUklP1UkvlVJJT9VJL5VSSU/VSS+VUklP1UkvlVJJT9VJL5V SSU/VSS+VUklP1UkvlVJJT9VJL5VSSU/VSS+VUklP1UkvlVJJT9VJL5VSSU/VSS+VUklP1UkvlVJ JT9VJL5VSSU/VSS+VUklP1UkvlVJJT9VJL5VSSU/VSS+VUklP1UkvlVJJT9VJL5VSSU/VSS+VUkl P1UkvlVJJT9VJL5VSSU/VSS+VUklP1UkvlVJJT9VJL5VSSU/VSS+VUklP1UkvlVJJT9VJL5VSSU/ VSS+VUklP1UkvlVJJT9VJL5VSSU/VSS+VUklP//ZCg1lbmRzdHJlYW0NZW5kb2JqDTkgMCBvYmoN PDwgL0ZpbHRlciAvRmxhdGVEZWNvZGUgL0xlbmd0aCAxMA0+Pg1zdHJlYW0KeJwr5AIAAO4AfA1l bmRzdHJlYW0NZW5kb2JqDTEwIDAgb2JqDTw8IC9MZW5ndGggNA0+Pg1zdHJlYW0Kvc/oCg1lbmRz dHJlYW0NZW5kb2JqDTExIDAgb2JqDTw8IC9IZWlnaHQgOTkgL0JpdHNQZXJDb21wb25lbnQgOCAv TGVuZ3RoIDUzNSAvV2lkdGggNzYgL0NvbG9yU3BhY2UgMzIgMCBSIC9GaWx0ZXIgL0ZsYXRlRGVj b2RlDT4+DXN0cmVhbQpIiexXO1LDQAz1nai4RSpoMhTJLeiofAqoUoaGHARo0HVw7Dir/67sdQZm rIx/sfz0nlb7A1httX9ljWLpT+YA+AIXh0V5AeUjeCGq5JFjMb/uDFc1ehJIMM7L+iKGtUC+ynnN wUIFQM7D3fIaSYGGiE8Ilsei9TBTZEVezJe00VATWu+2NJohmz9Q90b4GC87FWO+nJ5fjlW/i6h0 XI3l+QLu4IU1XStqLHNltCmvdu/9CjRCwtp6TNqYRtd9V8ALaRzcT3B/eIVnOPT38KkG0rXhfBH3 I+VVki/B62xf3bF53MBH//RzxnUTIK0VZPK8SHWMPRpSO546yPfu+g1w94QC+Rpxf8/I2HsvpVn1 peTLbsMSXmZ9KbjCHdukdkzfInt7gYdcffkyzEAhXmqRcV7a8gTRu9k4werLrtVhytq2u9Y+MlCy IdyXEgv0mcgPGUuWA6V5uZNpNKKXMsxJ3eaE5RmbJYE1umkrk+rL5KzD9GB84grxmqGRbgKFw8R1 NMUyBvMpxOMaI5vFHFZz7QaXuoth1bR87lGHRFOdiTUoQvf9E98K3NSkrArtaI2d5PUSajK8VHrJ wxheXSyKazmAKtpKlRK2bhIyqyJPY3SMrolVPx0ZB3vlHg5Ga8vLl6zOxYxOFe78qA7SaRFhz7V6 3fMet5xiJYKde00Acg2QY/IZcFCCyBg5r7baapb9DgBj5IfPDWVuZHN0cmVhbQ1lbmRvYmoNMTIg MCBvYmoNPDwgL0ZpbHRlciAvRmxhdGVEZWNvZGUgL0xlbmd0aCAzMDUNPj4Nc3RyZWFtCmjeVJHJ boMwEIbvfoo5psrBLIUQCSFVRJE4dFGT5k7sIUUqxjLkkLfvjE3T1hLm82y/PSPrZteYfgb55kZ1 wBm63miH03h1CuGMl95AnIDu1byc/K6G1oKk5MNtmnFoTDdCWQr5Ts5pdjdYPfm13ifr6AHkq9Po enOB1TH+OJHhcLX2Cwc0M0RQVaCxE7J+bu1LOyDIP9m/ruPNIiT+HC/XGDVOtlXoWnNBKJOognJL Gxr93yc2IePcqc/WiRAZRfQjzgPnxJn2nO2Yu8B74iKtuLyPKTLPcUrMYszbSpDmUj370QrSZVJQ UHoOKgVlpaySojekLPUYE2chgliUORs24TI5GwrmAoNavaiF+vxYnse9ferqHHXWD813jnvWG7zP 1Y6WW8Sf+BZgAGhklW0KDWVuZHN0cmVhbQ1lbmRvYmoNMTMgMCBvYmoNPDwgL0hlaWdodCAyNjYg L0JpdHNQZXJDb21wb25lbnQgOCAvU3VidHlwZSAvSW1hZ2UgL0xlbmd0aCAyNzYzIC9XaWR0aCA0 MjAgL1R5cGUgL1hPYmplY3QgL0ZpbHRlciAvRmxhdGVEZWNvZGUgL0NvbG9yU3BhY2UgMyAwIFIN Pj4Nc3RyZWFtCmje7JsNf5s2EMaBGUrdjrXzXuqFbGtq1rVLYpzw/T/bdJJs8AtwgLAEfp5fE9e2 gmP9fac76YnnQRAEQRAEQRAEQRAEQRA0N/2EKXBed5gCMIIalLyuxHd/XRS5/F6knhcWhXwUjFxQ sLn/QjSSjO75nySZxdPKi3cRGDlDiRgtHpcVRnGuHwYjhxiJ5EZJjnLdy9KLsyNGH+7u7v64g8zr QydGIrOFLzKWRJI7YYQ4ciPXfYu84EEyErhkrlP3wMgZRvRNVwlJjprBLclqmxKdXIhCdceL5T0w mpbACIwgMAIjaEaMqMa/pJNK/2jk+XPQAEbb7fbw/0SViGczLwp7f53qERmPETUDkHFGos3ywuxy HClGtLfx4xJxZI2R3qQNHv4uUt18Udf177coeHindgVDFWayFwseft8filRHLgmVuJH/1IikuBSf UA9GGkCwyVRIhGr3ItnRlB9yXbaHSePiXXQ2ssLoMOJkJ9FhbfV8bKtrgG1G5e+zZ0R5Sm6q7yIx +XrKNSOR816W9KgaJ547G1mNI3lnSoyuyacPo0OuI0a5Cq0zRnS0GB8xOh15xijYlIUGGA1j5K9z qhkkI12VVTJYQoxiOq9Kda7TUXI88sv+B0pG4VQAucxoL9qsVUBUsstlJXD/WT4UUmWgQ0LXDEu1 bFVHlj9QyXXPynEBRgYYjSTyXeiMOAFIjtYMI4vi6GUq/ZIxRsq7JWsseLecZLT3bnnxV5Hw4d1y M45Uu7F4fF8ygnfLDCIjfEpGSUqFE9e75eikOObMOmJkwLuVH7Yu4d1yNI5op1KXCfBuuZrrSijw bpmDZKZm2Hu3FCN4t1xkxBUYgREYOcfoJs7GHd1Tfau/1DqXe4fdJdKteUzcZHRAJHcs/PUuolv9 RzM35zFx9mxCIVK7SsEmpVtd3d+cx8RVRvtIUjt/SVaJo/l7TM4gOVkzlOuRYpTSevS6okDJZu8x mQaj4/WIkpzeSd9r1h6TicTR8XqUqJpBa/Yek8kw0jrU3iWj2XtMzhBdkU8fRqY0KY/JjTKalMfk RhlNWWA0BUhmvVux7Obh3XKRkfZuBZ8jf53Bu+VoHB3a+CSDd8txRnTL9W5BFrxbKoyk4N0yFkZG YqjCSO2jefBuucso2SOCd8s5Rtq7JbfFdhG8W2YhwRcERmAERmAERg4guiIfMAIjMAIjMILqIaFm ACMwAiMwAiMHEF2RDxiBERiB0fQZKe+WcmvBu2UWklHvlj55hXfLRUb6rFy7teDdcpmRcgLBu2VS R4yGe7cqVODdMhZGRmLoONcptxa8W44yqlQJ8G65xkh7t7RbC94tN+OIJzDqAwl7qmAERmAERmDk AKIr8gEjMAIjMAIjqB4SagYwAiMwAiMwcgDRFfmAERiB0UGL50Iou/xkDO+WfUaKUB2lxeOSzsvh 3TILqVvNEGz2c55QoDQzgnfLCqM2ieyWq5NzeLfc827p6Nq90fEF75bFOPLXWbC5lOgojHKV7zx4 twwi6p7nRGSc+320qEII1VPwbllk5H/6ZZ3rYDmPMVl0w7tlmZGY+ZflSXiwBUbjM2qpvcFoFEgd a4ayh+2DCIyuwahlLwiMnGA0SGAERrNE1IMPdbDUnoKRs4yoB0pr+iMwcoNRsEkTMJoAo/gFjK4H qXvNkFDtnfd7OTAazOitV37VihaknltBYDSYEQvRIIHRpbnvwIiJKKZch/VoOKDq/DeNPBnHwCTa IzCyyIgTSf46bXqSygl4t8ZjxEt2YUMcJXKvFd6t0RjxEDXlOt3awrvFxdS5ZvCY61HWHGIpvFsc R1Zl7jt4t6qIGrxbSV7PqPScwLs1Thyxkl1jrvsW7d1a8G6Nwmj4ekRRo6sEeLdaJ746/00jT8YN 3WkIJT14t0Zk1I4ofv0VPWzz1Os5HYkRI4rAyC6j8bdU586o2znPWP1ReLK5A0bXZtQeSWBkmREj 2YXapYr1yA4jznoERtz5bB/I5Nm5P0Kus80I65HzjOBncJ4R+qPhhJjzfsyTzZ17fgRG5hk1T3sP fx0YmWbUMu3w17kQR83R0cNfB0acee9WMzQiOuE+GJO/Ft3tDXu3+jFqnPYe/rpmxV8fljPzbvXL X4wEdhjfUjIcvf5wRIvH9yWjmXi3ejNqjo4tt+8x3R8lKZlM5uXdqq7ZLUPr1pgW79ZFQ1add6sc 2+DdalCYH4xAM/JuVeaodWQ5vv0Tb6c/kn8+psqEGXm3+jFqT0zW+qM9lBl5t/oyaptOa/0RMZqX d6tvzdCawCrjr9ofteiGGLUnsHL8dfsjMHK+PwIj9/ujOTKqrtlvW6az0znPxf6o+fVv7vyoxxlb awIrx7vaH90Ao5ZPfHW8s/3RzBm1feKr453tjybCaNvP8/HWY68d6I8sMWqdIvRHDjBirx0e+iPD jEz1J+iPRuLE70/QH1ljxO5PPPRHlhjx+xP0R/ZyHbc/mUN/FMuDI4veLa53atuvP5lBfxR8jvx1 ZtO71Y+Ruf5kGv1Rktn0bnH7k+1I/ckk+iOCYs27VdefXHJZ1awdF4bWrTFDXv/O5Ot/6B5GamWy 4d0avT+ZRX9E+U3Kindr9P7Em0F/lOSV/12/Zhi9P5lBf7R4lq4ta96t0fsTnB/VvJWjz2YrJV5/ crv9kUuMjOV4nB91ZWSoP7np/mhkRqbOb3B+ZJRRXX9ycWRlPPojO4w8y/2J7dd39vzIof4E50cM Rpb7E/RHNW+lSy5Gf2SdkWeqP0F/NCIj9Efoj670+uiP0B+ZYtQ9x6M/uvZ61D3Hoz8yhojp3bqU Yx3vT+bTHzG8Wwb6k5bPHPojDqMm75bt/uTm+yNr3q0b1c89OQ32bt2NMNL6UOu/6pEGe7fAaHRG g71bYDQqo3rv1kf+RT6OMNL6UOu/KgRBEARBEARBEARBEARBEDS6khNfSr1itZ1ueKjnr09252vH KSsNd2zOGkmHBAXvF6B3xZ4sgwo291+YLxt8jvx1xhv6l8cdKt751wceo0/8+UmyLpMQ8nAuHpfS JGKB0pcOHw3+e2dfdvH43jgjmk2+/HXKvqr7jNhjY3ZW8pI0eGDnOmZSkgmM+wuQr8DjXtYKok6M OqQQf817OyLPMBlJ9rzppFkPmTzZYSTe/u4Nn7wlRp0CnfnpTOgjz16JmRddfIv45NkwadnqlkWv zyhhIwqzLqM7xBHzovSeYm4GYyeHuEt0GpQsaJkfzmf2ULoqu/bmMgoL/kVD9tLVITK6FP8QBEEQ BEEQBEEQBEEQBEEQBEEQBEHX0uK54WQ61r6GxXM64CpQXwUbMpcUf7IYPa0kiCKtsReB0VhKXpa8 OFI2GMFoF4GRDUbfyUi4ePqtyMgZIqhQhIln4qL4/roiX0e2B/G9SIlRKOJJ4KOfKbKEfkRfRV9A XQwyx2gX0XyLG7nsiMd+iASmTISGv35dxaWdZ/F8v3l5V2EkfiYpsmCTq6sUqb6AvBhkkBGFTyqT Vaz+ZEFaonLKc+IrLN1RgkBY/FNllNGNv95F9F/xpS+AzDciI7X8iBsRG5oRmdjyAyMRWf81MVIX AKPxGIVqFRHpLSxycUfmupQY7BlR3UCZTT51xEhmTH0BMBqPkUx2u0jUDBQtiSjMn1Z0Z3WII7KD 555+qspIlg/7C4ARBEEQBEEQBEEQBEEQBEHH+l+AAQCscX+KCg1lbmRzdHJlYW0NZW5kb2JqDTE0 IDAgb2JqDTw8IC9GaWx0ZXIgL0ZsYXRlRGVjb2RlIC9MZW5ndGggODANPj4Nc3RyZWFtCnicUwjk KuQqVLAwUABBIyAyN1AwMVBIzlXQj8g0U3DJVwjkcgrhAnIMzRQsFELSuAzBSg0VjA2AKk0VQnK5 NIxMLDRDsrhcQ7gCuQDFLREEDWVuZHN0cmVhbQ1lbmRvYmoNMTUgMCBvYmoNWyAvSW5kZXhlZCAx MjQgMCBSIDAgMTAgMCBSDV0NZW5kb2JqDTE2IDAgb2JqDTw8IC9Dcm9wQm94DVsgMCAwIDYxMiA3 OTINXSAvQmxlZWRCb3gNWyAwIDAgNjEyIDc5Mg1dIC9NZWRpYUJveA1bIDAgMCA2MTIgNzkyDV0g L1JvdGF0ZSAwIC9UcmltQm94DVsgMCAwIDYxMiA3OTINXSAvVGh1bWIgMTIwIDAgUiAvUmVzb3Vy Y2VzDTw8IC9Gb250DTw8IC9GMSA2NyAwIFIgL0YyIDcyIDAgUiAvRjMgNTIgMCBSIC9GNCA1NyAw IFIgL0Y1IDYyIDAgUiAvWGkxNyAxMTcgMCBSDT4+IC9Qcm9jU2V0DVsgL1BERiAvVGV4dCAvSW1h Z2VCIC9JbWFnZUMgL0ltYWdlSQ1dIC9FeHRHU3RhdGUNPDwgL0dTMSA0MiAwIFINPj4gL1hPYmpl Y3QNPDwgL1hpNyAxMjMgMCBSDT4+DT4+IC9BcnRCb3gNWyAwIDAgNjEyIDc5Mg1dIC9QYXJlbnQg MzcgMCBSIC9Db250ZW50cw1bIDc5IDAgUiAxMTQgMCBSIDc0IDAgUg1dIC9UeXBlIC9QYWdlDT4+ DWVuZG9iag0xNyAwIG9iag08PCAvVHlwZSAvRW5jb2RpbmcgL0RpZmZlcmVuY2VzDVsgMiAvZzI5 OSAzMiAvc3BhY2UgMzggL2FtcGVyc2FuZCA0MCAvcGFyZW5sZWZ0IC9wYXJlbnJpZ2h0IC9hc3Rl cmlzayAvcGx1cyAvY29tbWEgL2h5cGhlbiAvcGVyaW9kIC9zbGFzaCAvemVybyAvb25lIC90d28g L3RocmVlIC9mb3VyIC9maXZlIC9zaXggL3NldmVuIC9laWdodCAvbmluZSAvY29sb24gL3NlbWlj b2xvbiA2MSAvZXF1YWwgL2dyZWF0ZXIgNjUgL0EgL0IgL0MgL0QgL0UgL0YgL0cgL0ggL0kgL0og L0sgL0wgL00gL04gL08gL1AgL1EgL1IgL1MgL1QgL1UgL1YgL1cgL1ggL1kgL1ogL2JyYWNrZXRs ZWZ0IDkzIC9icmFja2V0cmlnaHQgOTUgL3VuZGVyc2NvcmUgOTcgL2EgL2IgL2MgL2QgL2UgL2Yg L2cgL2ggL2kgL2ogL2sgL2wgL20gL24gL28gL3AgL3EgL3IgL3MgL3QgL3UgL3YgL3cgL3ggL3kg L3ogL2JyYWNlbGVmdCAvYmFyIC9icmFjZXJpZ2h0IDEzMSAvZWxsaXBzaXMgMTMzIC9lbmRhc2gg MTQxIC9xdW90ZWRibGxlZnQgL3F1b3RlZGJscmlnaHQgMTQ0IC9xdW90ZXJpZ2h0DV0NPj4NZW5k b2JqDTE4IDAgb2JqDTw8IC9IZWlnaHQgNTI5IC9CaXRzUGVyQ29tcG9uZW50IDggL1N1YnR5cGUg L0ltYWdlIC9MZW5ndGggNTM5MzIgL0ludGVudCAvUmVsYXRpdmVDb2xvcmltZXRyaWMgL1dpZHRo IDkxMyAvVHlwZSAvWE9iamVjdCAvRmlsdGVyIC9EQ1REZWNvZGUgL0NvbG9yU3BhY2UgMTI0IDAg Ug0+Pg1zdHJlYW0K/9j/7gAOQWRvYmUAZIAAAAAB/9sAhAAMCAgICQgMCQkMEQsKCxEVDwwMDxUY ExMVExMYFxIUFBQUEhcXGxweHBsXJCQnJyQkNTMzMzU7Ozs7Ozs7Ozs7AQ0LCw0ODRAODhAUDg8O FBQQEREQFB0UFBUUFB0lGhcXFxcaJSAjHh4eIyAoKCUlKCgyMjAyMjs7Ozs7Ozs7Ozv/wAARCAIR A5EDASIAAhEBAxEB/8QBPwAAAQUBAQEBAQEAAAAAAAAAAwABAgQFBgcICQoLAQABBQEBAQEBAQAA AAAAAAABAAIDBAUGBwgJCgsQAAEEAQMCBAIFBwYIBQMMMwEAAhEDBCESMQVBUWETInGBMgYUkaGx QiMkFVLBYjM0coLRQwclklPw4fFjczUWorKDJkSTVGRFwqN0NhfSVeJl8rOEw9N14/NGJ5SkhbSV xNTk9KW1xdXl9VZmdoaWprbG1ub2N0dXZ3eHl6e3x9fn9xEAAgIBAgQEAwQFBgcHBgU1AQACEQMh MRIEQVFhcSITBTKBkRShsUIjwVLR8DMkYuFygpJDUxVjczTxJQYWorKDByY1wtJEk1SjF2RFVTZ0 ZeLys4TD03Xj80aUpIW0lcTU5PSltcXV5fVWZnaGlqa2xtbm9ic3R1dnd4eXp7fH/9oADAMBAAIR AxEAPwD1VJJJJSkkkklKSSSSUpJJJJSkkkklKSSSSUpJJJJSkkkklKSSSSUpJJJJSkkkklKSSSSU pJJJJSkkkklKSSSSUpJJJJSkkkklKSSSSUpJJJJSkkkklKSSSSUpJJJJSkkkklKSSSSUpJJJJSkk kklKSSSSUpJJJJSkkkklKSSSSUpJJJJSkkkklKSSSSUpJJJJSkkkklKSSSSUpJJJJSkkkklKSSSS UpJJJJSkkkklKSSSSUpJJJJSkkkklKSSSSUpJJJJSkkkklKSSSSUpJJJJSkkkklKSSSSUpJJJJSk kkklKSSSSUpJJJJSkkkklKSSSSUpJJJJSkkkklKSSSSUpJJJJSkkkklNfPszasV78CluRlaCuux/ pskmJc+HQBzoFg09b+sWB1rB6b12jFfT1Te3GycI2RXaxvqGuxt2p0Bhwj4BdI97K2Oe9waxoLnO cYAA1JJK5jpzH/WXrtH1hc1zOldNa9nSQ6Wm6ywbLckt/c26MnzKSnU6rZ9ZjeKejVYjKw3c/KzH PcN2vsbTTBPGpLhz3Qfq71+7qWLmftGgYeZ0y9+PmMa7dXLAH72O52lpnVWeudaq6Ritf6bsjLyH elhYler7rSJDR4AcuPACxm/V/J6f9TOs02kZHVep0ZeRmOYTtdkX1OGyvd+a3RrUlMWdf+tuV0x3 X8HDxD03Y66nBsdZ9qupbJa8Wt9jHPb7g3Yfiuk6dnUdRwMfPxyTTlVttrnQ7XjcJWX9W7aW/Unp tjo9NnTaS/sPbS3d+RL6iscz6n9IDxBOMw/Jw3D8Ckp3UklXtZnF5NN1TGdmvqc8/wCcLWfkSU2E lQpf1S2y9nrUD0LBXPovMyxlk/z+n04RfT6p/wByKP8Ath//AKXSU2klV9Pqn/cij/th/wD6XS9P qn/cij/th/8A6XSU2klV9Pqn/cij/th//pdL0+qf9yKP+2H/APpdJTaSVX0+qf8Acij/ALYf/wCl 0vT6p/3Io/7Yf/6XSU2klV9Pqn/cij/th/8A6XS9Pqn/AHIo/wC2H/8ApdJTaSVX0+qf9yKP+2H/ APpdL0+qf9yKP+2H/wDpdJTaSVX0+qf9yKP+2H/+l0vT6p/3Io/7Yf8A+l0lNpJVfT6p/wByKP8A th//AKXS9Pqn/cij/th//pdJTaSVX0+qf9yKP+2H/wDpdL0+qf8Acij/ALYf/wCl0lNpJVfT6p/3 Io/7Yf8A+l0vT6p/3Io/7Yf/AOl0lNpJVfT6p/3Io/7Yf/6XS9Pqn/cij/th/wD6XSU2klV9Pqn/ AHIo/wC2H/8ApdL0+qf9yKP+2H/+l0lNpJVfT6p/3Io/7Yf/AOl0vT6p/wByKP8Ath//AKXSU2kl V9Pqn/cij/th/wD6XS9Pqn/cij/th/8A6XSU2klV9Pqn/cij/th//pdL0+qf9yKP+2H/APpdJTaS VX0+qf8Acij/ALYf/wCl0vT6p/3Io/7Yf/6XSU2klV9Pqn/cij/th/8A6XS9Pqn/AHIo/wC2H/8A pdJTaSVX0+qf9yKP+2H/APpdL0+qf9yKP+2H/wDpdJTaSVX0+qf9yKP+2H/+l0vT6p/3Io/7Yf8A +l0lNpJVfT6p/wByKP8Ath//AKXS9Pqn/cij/th//pdJTaSVX0+qf9yKP+2H/wDpdL0+qf8Acij/ ALYf/wCl0lNpJVfT6p/3Io/7Yf8A+l0vT6p/3Io/7Yf/AOl0lNpJVfT6p/3Io/7Yf/6XS9Pqn/ci j/th/wD6XSU2klV9Pqn/AHIo/wC2H/8ApdL0+qf9yKP+2H/+l0lNpJVfT6p/3Io/7Yf/AOl0vT6p /wByKP8Ath//AKXSU2klV9Pqn/cij/th/wD6XS9Pqn/cij/th/8A6XSU2klV9Pqn/cij/th//pdL 0+qf9yKP+2H/APpdJTaSVX0+qf8Acij/ALYf/wCl0vT6p/3Io/7Yf/6XSU2klV9Pqn/cij/th/8A 6XS9Pqn/AHIo/wC2H/8ApdJTaSVX0+qf9yKP+2H/APpdL0+qf9yKP+2H/wDpdJTaSVX0+qf9yKP+ 2H/+l0vT6p/3Io/7Yf8A+l0lNpJVfT6p/wByKP8Ath//AKXS9Pqn/cij/th//pdJTaSVX0+qf9yK P+2H/wDpdL0+qf8Acij/ALYf/wCl0lNpJVfT6p/3Io/7Yf8A+l0vT6p/3Io/7Yf/AOl0lNpJVfT6 p/3Io/7Yf/6XS9Pqn/cij/th/wD6XSU2klV9Pqn/AHIo/wC2H/8ApdL0+qf9yKP+2H/+l0lNpJVf T6p/3Io/7Yf/AOl0vT6p/wByKP8Ath//AKXSU2klV9Pqn/cij/th/wD6XS9Pqn/cij/th/8A6XSU 2klV9Pqn/cij/th//pdL0+qf9yKP+2H/APpdJTaSVX0+qf8Acij/ALYf/wCl0vT6p/3Io/7Yf/6X SU2klV9Pqn/cij/th/8A6XS9Pqn/AHIo/wC2H/8ApdJTaSVX0+qf9yKP+2H/APpdL0+qf9yKP+2H /wDpdJTaSVX0+qf9yKP+2H/+l0vT6p/3Io/7Yf8A+l0lNpJVfT6p/wByKP8Ath//AKXS9Pqn/cij /th//pdJTaSVX0+qf9yKP+2H/wDpdL0+qf8Acij/ALYf/wCl0lNpJVfT6p/3Io/7Yf8A+l0vT6p/ 3Io/7Yf/AOl0lNpJVfT6p/3Io/7Yf/6XS9Pqn/cij/th/wD6XSU2klV9Pqn/AHIo/wC2H/8ApdWW 7to3EF0akCBPkJKSl0kkklKSSSSUpJJJJSkkkklKSSSSUpJJJJTn9e6Lj9d6Xd0vJtupov2+o+hw Y+GkO2y5rhBjXRUsb6sX49tTx1vqdjKXNIpe+j03BpnY4Nx2naeNCt1JJThdT+qdPUOrt6w3qGbh 5TKfs7Psz6w0MJ3OgW1WQXHmFd6X0mzp/q+r1DL6gLYEZbq3BkT9D06q+Z1laCSSnnP+ZGCGOxGZ mYzpL3FzulNsaMeDqawdnqhhP5u+PlouhrrZVW2utoYxgDWNAgADQABSSSUpJJJJTVw/6Rnf8e3/ AM8Uq0quH/SM7/j2/wDnilWklKSSSSUpJJJJSkkkklKSSSSUpJJJJSklm9R+sHTenXDGudZbklof 9nxqrMiwMJI3uZS15a3Tkq1hZuNn47cnGcXVuke5rmOBGha5jw1zSPAhJTYSSSSUpJU7epUVdUxu mOa43ZVVtzHCNobSa2uDtZk+oI0Ts6phnFdl2POPQ2w1F+QDV7t/pD+cj6T9G+PZJTbSSWTX9Zul W5f2Wo32A2Gn7SzHudj+oDsLPtAZ6ch2n0uUlOskkqdnUqK+q09LLXetfRZkNeI2BtTq2OB1mZsH ZJTcSSSSUpJVep59XTenZPULmufViVPue1kFxbW0uIbJAnRWK3iyttjdA8BwnmCJSUySVTqvUael 9Nyeo3tc+rErda9rILiGiSGyQFP7ZV9qrxdtm+2t1rXBjiwNaQDueBtB93EpKbCSSSSlJJJJKUkk kkpSSSSSlJJJJKUkkkkpSSSSSlJJJJKUkkkkpSSSSSlJJJJKUkkkkpSSSSSlJJJJKUkkkkpSSSSS lJJJJKUkkkkpSSSSSlJJJJKUkkkkpSSSSSlJJJJKUkkkkpSSSSSlJJJJKUkkkkpSSSSSlJJJJKUk kkkpSSSSSlJJJJKUkkkkpSSSSSlJJJJKUkkkkpSSSSSlJJJJKUkkkkpSSSSSmvn4VefivxbX2V12 RvdS81vgGS0Pb7hPBhcjd0nB6B9b+iUdCFmMc4XjqGM1z312U11yLrd7ne7fHu5K6T6w9cxegdIv 6rlhz6qAIYwSXOcdrW+Uk8rnPq11z6ufbHZ2d1fGy+vdTLKnCsnbW0n9Hi0Aj6ILufzjqkpsW0Y3 1l+t3Uum9Ra+3p/RKcdv2QuIpsuygbvUsa0+/a1oDZ4MoeFkD6s9Q69g1F9nTcHCZ1PEx3OL/SAb Y2yqsvdoyava3spOysP6ufXLqmb1Oz7NhdcpxnU5VmlQuxmvqdUX8NdthwnlNj4v/OTN69n0bm9P zsBvTMPIILfVEWmy1gcPoTZDT3SUh6d9VMLqn1Zp6vlOtf13NxvtbepCx4uqsub6rBU5rvYxu6A0 aQui+q/UbuqfV7p3UL4N2RjsfaQIBfEOMeZXPdJ+tnTsH6r4/S7nOb1zCxm4Z6XtP2k31sFbWtr7 h0A7uI1XQ/Vjp13S/q907p98etj47GWgagPiXCfIpKdRJJV7cKm15e91oJ7MutYP81jwElMcP+kZ 3/Ht/wDPFKtLMxen0OvzAXXe24ARfcP8DUdYs157qz+zcf8Afv8A/Yi//wBKJKbSSFRjV0bthsO6 J9Sx9nHh6jnR8kVJSkkkklOB1rq/XsTM9HAwDfSGg+r6b7JJ/wCLIiFQ/wCcX1t/8rP/AAC7/wAk uuSUscsQADjifFjMJEk8ZDwvUvrL191D8XLx24gubG707K3x3273fJFxPrT9ZLag3HxG5IrAa6xt VjySBy4sdElb3U/qzhdTyjk5F1wdtDQ1jmhoA8JYSidJ6Bi9JssfjW2uFoAc2wtLdOD7WN1Upy4e D5Bxb1WjH7eXi+Y136uJ/wA4vrb/AOVn/gF3/kle6N1jr+XminPwDTSQSbfTsr2kCR/OEzK6BJRS yxII9uI8WQY5Ag8ZLzX1PNr876yXZLQ3KPVbKye5prqpGPPP5mqsfWO7ObndGxcPIdijNyrKr3sA JLBj3PPOk+3Q9ijZv1bx8jOf1DFysnpuZcGtyLcRzQLQ3RvqV2ssYXAaB23d2mEQdBxQ/CsdbfZZ gXPya32Wb3PssY+p3qF4OkWGA2I+GiiZHJzLLa+q0/VxludbjY+F9puspsJybDbY+qsOyN7XgM2O 41OmqFfm9epw/sD334/23qdeHhZtoYb241jPWe50bm7mlr62kjwmVu9S6LVnX1Zld92FnUMdXVlY 5bvFby1z2Oba17HAlo5b8FG7oVOT077Dm5F+UfUZc3Je5rbW21lrmPYa2Ma3a5oMBsJKclvT3YH1 x6XWMm/IpODmbG5D/Vc0h+Nu/SO97t2n0iVmdVfkdR+pFt+TkWmyvqXpgh0S1vUm0sDvHa0CF02J 9XqqM+jqV+XkZmbj120i64s9zLSxxBZXWxo2+nptA5Mykfq3089Gv6M91jsbIssuc7cBY19lxydz HNAgseZb8ElOhi4/2altXqWXbZ99rtzzJnU6Lmzb1H6n0sZYK8z6vi8MFs7MjGbkWbWhzSNtrGvf EyDHiuiw8azGxm0W5FuW9s7r7tge6TOvpMrbpwICzP8AmtS91deVn5mZh0vZZVhX2NdWHVuD2bni sWv2uaDD3nzlJSJpv6x13qeJZk3Y+N0s49ddeO81F1ljBkOse9urhDmtDTpoZBlVs7Cvs+tXSsU5 doczpuSLshu1ttgbZig6taA0uPJaB5QtXN6BXkZ56hj5eRgZNjG1ZD8csi2usuLGvbbXYNNxgiCi 19Gxq83FzQ+11uHjPxK9798sea3Fz3Pl7nfohruSU867rGd0fpXXqhdZlO6ZlVY2Fdf+lsAyWY+z eSW+p6brvzjJHJV3GZ1PH6nhOxRn20Wvc3qP21zXM2Gs7bWS87HB7WiGaanRaTvq/wBOsb1Ou8Ou q6w7dl1uOn80yiGbQ0j2sHeZSwOkX4lwss6nl5dbNK6bjVsAiNTXUx7o/lOKSnlc2rM6p9SOpdeu zsll2Zi5Noxtw9BlIFgbj+iRtnbo530p7xot6vLyW/WLpmG2wjGs6bda+rsXsfjNa75B5Su+p+Fb j5WF9qyq+nZgt34LHsFTX3lzn2MJrL/pOLg0u2z2VvP6FVlnGtqyLsPKw2munKoLN+x+0PY4WMew h20ctSU8/wBcy8m/o31zpusL68YGuhp4Y04lNhA/tOJWw7LyW/Wfp+G2wjGs6fkWvq7F7LMdrXfI PKkfqt084XU8I23mvrH9KeXhzwfSZSXMc5p1IZOs6+Wiuu6Xju6nR1Iuf62NRZjMbI2Flrq3uJET M1jukp5R1nVLfqr1Drjuo5Dcvp785+KGODawMa64NZYyIsBDdp3duIOq0+p53q9VxsfNyLsXBfh/ aP1Vz2uN29v846pu5oA+gN0O9wIMLQH1ewh0XK6Lvt+zZn2j1Hy31B9qc+yzadsaGwxosrqnSnO6 4Lb6cwYbcNlFGT0+19Vhe173OZkehYx7oBBZpt1ckp0fqqM79j12Z7rn32PsLTkSLDUHubS57D9B zqw1xbA17DhbCy+gM6k3Gu+3eoGuvecRl5a65tEANFrmOcCSQSO8ETqtRJSkkkklKSQLsSq9we91 gIEey2ysfdW9oUP2bj/v3/8AsRf/AOlElNpJVf2bj/v3/wDsRf8A+lEv2bj/AL9//sRf/wClElNp JVf2bj/v3/8AsRf/AOlEv2bj/v3/APsRf/6USU2klV/ZuP8Av3/+xF//AKUS/ZuP+/f/AOxF/wD6 USU2klV/ZuP+/f8A+xF//pRL9m4/79//ALEX/wDpRJTaSVX9m4/79/8A7EX/APpRL9m4/wC/f/7E X/8ApRJTaSVX9m4/79//ALEX/wDpRL9m4/79/wD7EX/+lElNpJVf2bj/AL9//sRf/wClEv2bj/v3 /wDsRf8A+lElNpJVf2bj/v3/APsRf/6US/ZuP+/f/wCxF/8A6USU2klV/ZuP+/f/AOxF/wD6US/Z uP8Av3/+xF//AKUSU2klV/ZuP+/f/wCxF/8A6US/ZuP+/f8A+xF//pRJTaSVX9m4/wC/f/7EX/8A pRL9m4/79/8A7EX/APpRJTaSVX9m4/79/wD7EX/+lEv2bj/v3/8AsRf/AOlElNpJVf2bj/v3/wDs Rf8A+lEv2bj/AL9//sRf/wClElNpJVf2bj/v3/8AsRf/AOlEv2bj/v3/APsRf/6USU2klV/ZuP8A v3/+xF//AKUS/ZuP+/f/AOxF/wD6USU2klV/ZuP+/f8A+xF//pRL9m4/79//ALEX/wDpRJTaSVX9 m4/79/8A7EX/APpRL9m4/wC/f/7EX/8ApRJTaSVX9m4/79//ALEX/wDpRL9m4/79/wD7EX/+lElN pJVf2bj/AL9//sRf/wClEv2bj/v3/wDsRf8A+lElNpJVf2bj/v3/APsRf/6US/ZuP+/f/wCxF/8A 6USU2klV/ZuP+/f/AOxF/wD6US/ZuP8Av3/+xF//AKUSU2klV/ZuP+/f/wCxF/8A6US/ZuP+/f8A +xF//pRJTaSVX9m4/wC/f/7EX/8ApRL9m4/79/8A7EX/APpRJTaSVX9m4/79/wD7EX/+lEv2bj/v 3/8AsRf/AOlElNpJVf2bj/v3/wDsRf8A+lEv2bj/AL9//sRf/wClElNpJVf2bj/v3/8AsRf/AOlE v2bj/v3/APsRf/6USU2klV/ZuP8Av3/+xF//AKUS/ZuP+/f/AOxF/wD6USU2klV/ZuP+/f8A+xF/ /pRL9m4/79//ALEX/wDpRJTxX1o6n1GnruTVTlXVVs9PaxljmtE1sJ0aR3KX1X6n1G7ruNVdlXW1 v9Tcx9jnNMVvI0cT3Cr/AFsxPs/W7WscXttaxzQXOe4e0MhxfJmW+PCt/V/6v9Tq6vRZlY9lVDd+ 94cWESxwHuYQRqoRDIZXRq7+luocuAcuIkx4zjrbXi4XvElV/ZuP+/f/AOxF/wD6UVlrQ1oaJgCB JJOniTqpnLXSSSSUpJJJJSkkkklKSSSSUpJJJJSkkkklKSSVLA6z0rqV+Tj4GVXk24Za3JbWd2wu 3QCRp+aUlNwgEQRI8CnVDqfXOl9KLG51+yy2TXSxr7bXAEAltVTXvIE6mFPpnVundWoOR0+9uRW1 2x+2Q5jgJLHscA5rhPDhKSm3tbO6BPE906xb/rl9WMfKdi257Gvrd6dlm15pY8aFll4aamO8nOWy CCJGoKSl0kkklNXD/pGd/wAe3/zxSrSq4f8ASM7/AI9v/nilWklKSSSSUpJJJJSkkkklKSSSSUpJ JJJSkkkklKSSSSUpJJJJSkkkklKSSSSUpJJJJSkkkklKSSSSUpJJJJSkkkklKSSSSUpJJJJSkkkk lKSSSSUpJJJJSkkkklKSSSSUpJJJJSkkkklKSSSSUpJJJJSkkkklKSSSSUpJJJJSkkkklKSSSSUp JJJJSkkkklKSSSSUpJJJJSkkkklKSSSSUpJJJJSkkkklKSSSSUpJJJJSkkkklKSSSSUpJJJJSlGy xlVbrLDtYwFznHsAJJUli/WjMbTg/Z/9NLrB/wAFWNzx/aMM+aRXQjxSA+3y6vNdOa/rX1pbdaJa H+vYD2az6LT8Pa0rv1yv1FxHejk9Qs1fc7Y0nwHucfmSPuXVJ0xVR7BEpcUiemw8h+zspJJJNQpJ JJJSkkkklKSSSSUpJJJJSkkkklKSSSSUiysanLx342Q3fTYIe2SJHhp4rlfqtj0Y311+tePj1tpp qHTW11MAa1rRjugNaNAupy7b6cay3HoOVcwSyhrmsLz4B1hDR8yuR6K36zY31o6t1PI6HbXj9Zdh tB+0YxNLaKzU9zw20k8z7UlJuuZFvRfrZT1amr9onOxRiWdPpG7MaK7C8XUt4cyXw+YjmVX6XmR0 n6z/AFqx3trzcqp9xwpM4zsXHLamXNO0iwxuf+U8q/fi9Z6X9Zs3rGNhO6ri9Qooq2V2VstodTuG 1rbixpY7du+lM9lPp/RcrNz+rdR6njNw6uq49eJ9j3Ne/wBNjXhz7iyWbnepEAnTukpf6vdOxLfq HhYb62mrL6ex1wI0c6+v1LHO8y5xMqx9Sb7Mj6pdJttcXPONWC4mSdo26k/BZWE3624PRWfV2vpo svoq+yUdU9WsY3phuxlzmbvVkN/N28941XSdH6bX0rpWJ02pxezEpZUHnQu2iC75nVJTcVe3Npqe WPbaSO7KbXj/ADmMIVhJJTmYvUKG35hLbvdcCIouP+BqGsV6cd1Z/aWP+5f/AOw9/wD6TSw/6Rnf 8e3/AM8Uq0kpFRk137tgsG2J9St9fPh6jWz8kVJJJSkkkklKSVfIz8HGcG5ORVQ4iQ2x7WEj+0Qh /tno/wD3Oxv+3Wf+SQsd1whI6iJP0biS4/q/1zy8bqFtGCMe/GZt2W+58y1rj7mWAaEwjdB+t92b lvq6k7HxqRWXNsk1y4OaNs2PI4JTfcjdMx5PMIcdaVxeP2PVJKn+2ej/APc7G/7dZ/5JEx8/ByXF mNk1XOAktre1xA+DSU6x3YTCQ1MSPo2ElzNFfV+qdY6wxnV8nCqwciumimlmO5oDsem0k+tQ9x9z z3QrfrB1JnRvrJj3WVt6t0Kuwi+oCHNfT6+Pd6btwaSDBGokfJFa9WkuVsv6x0fJ6O93ULup1dUy GYt+PeygOaH1vs9Wt1NdMbNnumdPNdJmWXVYl9uPX6t1dbnVVfvPAJa35lJSZJc59WH359NHUx1q 3Nc9n65huZS2tlhHurDG1ttrLHdnOPmr+R9YcSnIupqpyMsYp25dmPX6jaTs9Ta6DucdpGjA46pK dRJc0/rFmJ9aupUFmRlj7HiPow6BvM7sne5oe5rGzAkkjstOv6wdMs6U3qoscMZzvTAc1ws9Xf6P pemRu37/AG7Y5SU6SSzsPreNk5D8S2q3CyWVm70cloaXVB2w2Nc1zmkAxOsiRMSsHrf1pry+l02Y LMvHrvzMRuLmFjq67mHIq37HtO4Nc2fpgbhxISU9ekqtXUMa3qF/Tmk/aMauu2wEabbS8Mg/9bKx uudXbk9KpyMC2ysN6rjYtjgSwksy2U2t0OrTBHmkp6NJZteZSOr51Rvte/Hx6bX4xDfTY1xth7DG 4udsMyeyrU/W7plzcS5leR9jzjW2nNNZFAst2+nW507gSXRMbZ0mUlO2kszP69j4d1tLcfIyn47B bk/Z694qY4OLS6XN3E7Posl3kreBm1Z+HVmUgim9ofWXRq06tcNpIgjUJKbCSSSSlJJJJKUkkkkp Bdl1UODHtsJIn2VWWD762OCh+0sf9y//ANh7/wD0mrSSSmr+0sf9y/8A9h7/AP0ml+0sf9y//wBh 7/8A0mrSSSmr+0sf9y//ANh7/wD0ml+0sf8Acv8A/Ye//wBJq0kkpq/tLH/cv/8AYe//ANJpftLH /cv/APYe/wD9Jq0kkpq/tLH/AHL/AP2Hv/8ASaX7Sx/3L/8A2Hv/APSatJJKav7Sx/3L/wD2Hv8A /SaX7Sx/3L//AGHv/wDSatJJKav7Sx/3L/8A2Hv/APSaX7Sx/wBy/wD9h7//AEmrSSSmr+0sf9y/ /wBh7/8A0ml+0sf9y/8A9h7/AP0mrSSSmr+0sf8Acv8A/Ye//wBJpftLH/cv/wDYe/8A9Jq0kkpq /tLH/cv/APYe/wD9JpftLH/cv/8AYe//ANJq0kkpq/tLH/cv/wDYe/8A9JpftLH/AHL/AP2Hv/8A SatJJKav7Sx/3L//AGHv/wDSaX7Sx/3L/wD2Hv8A/SatJJKav7Sx/wBy/wD9h7//AEml+0sf9y// ANh7/wD0mrSSSmr+0sf9y/8A9h7/AP0ml+0sf9y//wBh7/8A0mrSSSmr+0sf9y//ANh7/wD0ml+0 sf8Acv8A/Ye//wBJq0kkpq/tLH/cv/8AYe//ANJpftLH/cv/APYe/wD9Jq0kkpq/tLH/AHL/AP2H v/8ASaX7Sx/3L/8A2Hv/APSatJJKav7Sx/3L/wD2Hv8A/SaX7Sx/3L//AGHv/wDSatJJKav7Sx/3 L/8A2Hv/APSaX7Sx/wBy/wD9h7//AEmrSSSmr+0sf9y//wBh7/8A0ml+0sf9y/8A9h7/AP0mrSSS mr+0sf8Acv8A/Ye//wBJpftLH/cv/wDYe/8A9Jq0kkpq/tLH/cv/APYe/wD9JpftLH/cv/8AYe// ANJq0kkpq/tLH/cv/wDYe/8A9JpftLH/AHL/AP2Hv/8ASatJJKav7Sx/3L//AGHv/wDSaX7Sx/3L /wD2Hv8A/SatJJKav7Sx/wBy/wD9h7//AEml+0sf9y//ANh7/wD0mrSSSmr+0sf9y/8A9h7/AP0m l+0sf9y//wBh7/8A0mrSSSmr+0sf9y//ANh7/wD0ml+0sf8Acv8A/Ye//wBJq0kkpq/tLH/cv/8A Ye//ANJpftLH/cv/APYe/wD9Jq0kkpq/tLH/AHL/AP2Hv/8ASa436y9TblvsNe6LnCqqWub+hqMu PuA+nb/1K7DquTZjYTzT/SLSKccf8JYdrfu5XG4NFfUfrJTRX78XDhrD410fnf236/NOxxEpgH5Y jjl5BffBilMfNL0Q8y9R0i3HwOm4+LsvDq2Df+r3fTPud/g/Eq5+0sf9y/8A9h7/AP0mrSSBJJJP XVjAoADo1f2lj/uX/wDsPf8A+k1Za4OaHCYIkSCDr4g6p0kEqSSSSUpJJJJSkkkklKSSSSUpJJJJ SkkkklKSQsrI+zY77/TfdsEiuobnuPADQsP6ufWHqPVOr9X6dn4bMJ/TPsxbW1/qOjJY62LHD27g AJ26eZ5SU9CksfqvWcyvqNHR+lUV5GfdWb7X3OLaqKAdnqP2AucXO0a0RMHUQrHT39Zqqtd1p2KR W0Obdi+o0Ee4v3V27tu0Aa7jPkkp0ElyTOv/AFtyumO6/g4eIem7HXU4NjrPtV1LZLXi1vsY57fc G7D8V0nTs6jqOBj5+OSacqtttc6Ha8bhKSmykkkkpq4f9Izv+Pb/AOeKVaVXD/pGd/x7f/PFKtJK UkkkkpSSSSSnNyuh4+Rl2ZYttqstDRZs9NwOwQ3S2t8fJD/5v1/9y7v83H/9ILWSQ4QyDLMAC9tN nzvr3ReoM6te3Hx8jJq9m24VE7vY2damNbodNArH1Y6Jmv6hYMqrIxKxS6LDWGy7cz2/pq3NXeJJ ntC7tsHnpnHwcI24bcn/AJv1/wDcu7/Nx/8A0gp43QsejLqyzdbbbSHCsO9NoG8bXfzVbJ08VppJ /CGv706IvfTYPLYfUT0vrvW2X4WbZ9ryqrMd9OLdZW9v2aiv+dazYPc0jUoGT0jOf0P60dStxXV9 Q63S/Zht/SWiurH9Cis+nuBedTDZ1MarsEkWNyekfV7pfT205FVDvtLa4Ft9ll1jNwG9rHXveWAx qBCmOl14F1/U6X5uVdtsf9lOTZYxxPu2V1XWek09m8QtNJJTyF7Kup/WDpuf0jAyMTMovP7SzLcd +MDjem8Pqe6wM9UuftiN0cqx07Lv6Hf1LCycPKyLMjMvy8OzHqdY25l59UN9QeyssJ2fpHN4nhdO kkpxcKi9v1s6nkOqe2mzDw212lpDXOa7JLmh3BLdwmFhu6V1N3RWPZTeH4fW8jMsx2TXbZQci9pN c7Z9tnqN/ejTldskkp5duFgdZryji/tBuU7DyMWrJy2X1CsXhrXBv2hrJMgHQdlUzcrMzfq9h9Mr 6blV5mLb08ZdRpeGV+lfSX7LNu2wDb+ZOmphdmkkp52+2zpf1oys27Hvux+oYuPTS/HqfdFtL7i5 j/TB2SLBBdp5rMZg9RP1dbW/FtZeeui91O0lwr/aHql+g1bt927iNeF2qSSnAbjZP/OPrN3pP9K3 AxWVWbTtc5pytzWu4JG4SPNZ78HN/wCYXR8QY9v2mr9mepRsd6jfTuodZuZEjaASfBdekkp47Lsz v2/1dmDVlmu70Ksi7Abj2Bp9L6Vn2h7HNuAd2DvZt0ldF0J/TndIxWdMn7HQwUVNdO5op/RFjt2u 5pbBlQf0LFOVflU234tmWQckU2lrXuaAwOLTIDtoAlsFW8PDx8HFrxMVmymoQxpJcfEkucSSSdST qUlJ0kkklKSSSSUpJJJJSkkkklKSSSSUpJJJJSkkkklKSSSSUpJJJJSkkkklKSSSSUpJJJJSkkkk lKSSSSUpJJJJSkkkklKSSSSUpJJJJSkkkklKSSSSUpJJJJSkkkklKSSSSUpJJJJSkkkklKSSSSUp JJJJSkkkklKSSSSUpJJJJSkkkLJyK8bHsyLTFdTS9x8miUlAWaDz/wBZc8sssLDphs2sj/uRe0if +t1bnfNB+omFtpyM5w1eRVWfJvud+JCyOuXWGttdn865xsuH/DW7bHj/AK2zYz712vRsL7D0zHxi IcxgL/67vc78SpIDhwmXXKaH92Kc5/WRxjbFGz/el/K26kkko0KSSSSUpJJJJSkkkklKSSSSUpJJ JJSkkkklKSSSSUpcp9Xf/F39bv8A2m/+27l0uXjuycayht1mObBAupIFjfNpc1wn4hYOD9Sa8LqV vU6ur9SdkZLqnZW+yki70RtY2yMcabdNISU07cHKzfr11GmvPu6ePsOK6ccV+o9gfcPpXV2QA7wC DkO6syv6z/V23Ks6mxnTDdh22tYLgb6rq/Se6sMa6SyQdq6Hq31ex+pZVOezIvwc/Ga6uvLxnBr/ AE3GXVva9r2ObOsFvKn0joOF0r7Q+o2ZGVmOD8vLyHb7rS0bW73QBDRoGgADsElNT6t20t+pPTbH R6bOm0l/Ye2lu78iX1FY5n1P6QHiCcZh+ThuH4FB/wCZGCGOxGZmYzpL3FzulNsaMeDqawdnqhhP 5u+PlouhrrZVW2utoYxgDWNAgADQABJTJV7WZxeTTdUxnZr6nPP+cLWfkVhJJTmYtfUfXzNt9IIu G4mlxk+jVx+mEaKz6fVP+5FH/bD/AP0ulh/0jO/49v8A54pVpJSKhuU3d9osrs42+mwsjxndY+UV JJJSkkkklKSSSSUpJJJJSkkkklKSSSSUpJJJJSkkkklKSSSSUpJJJJSkkkklKSSSSUpJJJJSkkkk lKSSSSUpJJJJSC5mY5wNFtdbI1D63PM/FtrPyKHp9U/7kUf9sP8A/S6tJJKavp9U/wC5FH/bD/8A 0ul6fVP+5FH/AGw//wBLq0kkpq+n1T/uRR/2w/8A9Lpen1T/ALkUf9sP/wDS6tJJKavp9U/7kUf9 sP8A/S6Xp9U/7kUf9sP/APS6tJJKavp9U/7kUf8AbD//AEul6fVP+5FH/bD/AP0urSSSmr6fVP8A uRR/2w//ANLpen1T/uRR/wBsP/8AS6tJJKavp9U/7kUf9sP/APS6Xp9U/wC5FH/bD/8A0urSSSmr 6fVP+5FH/bD/AP0ul6fVP+5FH/bD/wD0urSSSmr6fVP+5FH/AGw//wBLpen1T/uRR/2w/wD9Lq0k kpq+n1T/ALkUf9sP/wDS6Xp9U/7kUf8AbD//AEurSSSmr6fVP+5FH/bD/wD0ul6fVP8AuRR/2w// ANLq0kkpq+n1T/uRR/2w/wD9Lpen1T/uRR/2w/8A9Lq0kkpq+n1T/uRR/wBsP/8AS6Xp9U/7kUf9 sP8A/S6tJJKavp9U/wC5FH/bD/8A0ul6fVP+5FH/AGw//wBLq0kkpq+n1T/uRR/2w/8A9Lpen1T/ ALkUf9sP/wDS6tJJKavp9U/7kUf9sP8A/S6Xp9U/7kUf9sP/APS6tJJKavp9U/7kUf8AbD//AEul 6fVP+5FH/bD/AP0urSSSmr6fVP8AuRR/2w//ANLpen1T/uRR/wBsP/8AS6tJJKavp9U/7kUf9sP/ APS6Xp9U/wC5FH/bD/8A0urSSSmr6fVP+5FH/bD/AP0ul6fVP+5FH/bD/wD0urSSSmr6fVP+5FH/ AGw//wBLpen1T/uRR/2w/wD9Lq0kkpq+n1T/ALkUf9sP/wDS6Xp9U/7kUf8AbD//AEurSSSmr6fV P+5FH/bD/wD0ul6fVP8AuRR/2w//ANLq0kkpq+n1T/uRR/2w/wD9Lpen1T/uRR/2w/8A9Lq0kkpq +n1T/uRR/wBsP/8AS6Xp9U/7kUf9sP8A/S6tJJKavp9U/wC5FH/bD/8A0ul6fVP+5FH/AGw//wBL q0kkpq+n1T/uRR/2w/8A9Lpen1T/ALkUf9sP/wDS6tJJKavp9U/7kUf9sP8A/S6yeu3ZrGsxrbqn sDTkXNbU4eykgtaf0xne/a2F0C5W7JbkZNua/wB1InJI8aMUltDf+uXS75ISs1Eby0ZcIFmcvlgL cqjEyc76wVYj3tdZQTZc8tJbvk22bm7tfednIXa+n1T/ALkUf9sP/wDS65/6kYzn/aupW6vtd6bX Hv8AnvPzJC6pT56BEBtjAj9erWxky4sh3yEyavp9U/7kUf8AbD//AEul6fVP+5FH/bD/AP0urSSh ZGr6fVP+5FH/AGw//wBLqy3dtG4gujUgQJ8hJTpJKUkkkkpSSSSSlJJJJKUkkkkpSS5vqvVPrlZm 3YfQulVCqqAOo51u2pztJDKa/edO/wDqaTXf41qnb3s6PkMBl1TTc0kdw1xgD5pKexSWb0LqPU8/ Fe7qnTn9Lyq3bXUue21rhyHMsZoQtJJSkkLKrvtx3149voWuENt2h23zDToSuT+p9D8T62/WjCOR dkto+wEWZDy95c+l73uPYS48AAeGiSnsUli/WPLyXijovT3+nn9TJb6o5px2x9ov+IadrP5RCzPq zljpX1X6tkuL7q+mZPUHMD3F7zXjvftbueZPtbGpSU9akuJ6d9VMLqn1Zp6vlOtf13NxvtbepCx4 uqsub6rBU5rvYxu6A0aQui+q/UbuqfV7p3UL4N2RjsfaQIBfEOMeZSU6iSSSSmrh/wBIzv8Aj2/+ eKVaVXD/AKRnf8e3/wA8Uq0kpSSSSSlJJJJKUkkkkpSSSSSlJJJJKUkkkkpSSSSSlJJJJKUkkkkp SSSSSlJJJJKUkkkkpSSSSSlJJJJKUkkkkpSSSSSlJJJJKUkkkkpSSSSSlJJJJKUkkkkpSSSSSlJJ JJKUkkkkpSSSSSlJJJJKUkkkkpSSSSSlJJJJKUkkkkpSSSSSlJJJJKUkkkkpSSSSSlJJJJKUkkkk pSSSSSlJJJJKUkkkkpSSSSSlJJJJKUkkkkpSSSSSnz/q31l62zOzMVmTtpbbbU1oYzRoc5sbts8e azP2rnOptx3PBruZWxw2tHtpj0wNoGgWl1ToGZZ1jKDH1k25IDdXc5BfY1p9vLWjc7yQuldHs/5x V4FpZZ6D5ucwkthnuI1A7+1M5cT94SIJjA8R8AHR5qWAcrKA4IzyRAjQ1JL3HRcL7D0vHxiIe1gN n9d3ud+JV5JJSEkkk9TbmgUAB0UkkkglSSSSSlJJJJKUkkkkpSSSSSlJJJJKcn61VdSu6Bls6Xv+ 1wwtFTtljmNe11rK3dnOrDgPNcbn0/WHrbM/6zNZ1Hp78b0aeg9N97Hue1zd9l9ImQ5xgk6beeJX QZf1Y6/i5N2b9X+tW1Oue+52DnD18YudJ2tP062z+7KD/wA7frF0k7PrJ0Sw1CGnqHTT9opM8udU YsY0eaSnrWztG7mNY8U6o9H630vreGM3pd4yMfdsLgCC1wAcWua4Agw4K8kpDl5eNhY1mXl2CnHp G6yx3DR4lcN9XPrP9Xz9d/rFaM6os6k7p9eE6dLXNpNbgz4OMLv0klPOXdE+sVfW8zquBnYg+1tr ra3Ix7LHV1VDStrmXsEb3Odx3WT9VundXz+idcwcrIoONl39Rxi2qpzLBdZY9j7A91jhs1MN2/Nd ykkp4rpP1s6dg/VfH6Xc5zeuYWM3DPS9p+0m+tgra1tfcOgHdxGq6H6sdOu6X9XundPvj1sfHYy0 DUB8S4T5Fae1s7oE8T3TpKUq9uBg3PNl2NVY88vexrjp5kKwkkpzMXpvTnX5gdi0kMuAaDW3QejU 6Bp4lWf2V0v/ALh0f9tM/uSw/wCkZ3/Ht/8APFKtJKav7K6X/wBw6P8Atpn9yX7K6X/3Do/7aZ/c rSSSmr+yul/9w6P+2mf3Jfsrpf8A3Do/7aZ/crSSSmr+yul/9w6P+2mf3Jfsrpf/AHDo/wC2mf3K 0kkpq/srpf8A3Do/7aZ/cl+yul/9w6P+2mf3K0kkpq/srpf/AHDo/wC2mf3Jfsrpf/cOj/tpn9yt JJKav7K6X/3Do/7aZ/cl+yul/wDcOj/tpn9ytJJKav7K6X/3Do/7aZ/cl+yul/8AcOj/ALaZ/crS SSmr+yul/wDcOj/tpn9yX7K6X/3Do/7aZ/crSSSmr+yul/8AcOj/ALaZ/cl+yul/9w6P+2mf3K0k kpq/srpf/cOj/tpn9yX7K6X/ANw6P+2mf3K0kkpq/srpf/cOj/tpn9yX7K6X/wBw6P8Atpn9ytJJ Kav7K6X/ANw6P+2mf3Jfsrpf/cOj/tpn9ytJJKav7K6X/wBw6P8Atpn9yX7K6X/3Do/7aZ/crSSS mr+yul/9w6P+2mf3Jfsrpf8A3Do/7aZ/crSSSmr+yul/9w6P+2mf3Jfsrpf/AHDo/wC2mf3K0kkp q/srpf8A3Do/7aZ/cl+yul/9w6P+2mf3K0kkpq/srpf/AHDo/wC2mf3Jfsrpf/cOj/tpn9ytJJKa v7K6X/3Do/7aZ/cl+yul/wDcOj/tpn9ytJJKav7K6X/3Do/7aZ/cl+yul/8AcOj/ALaZ/crSSSmr +yul/wDcOj/tpn9yX7K6X/3Do/7aZ/crSSSmr+yul/8AcOj/ALaZ/cl+yul/9w6P+2mf3K0kkpq/ srpf/cOj/tpn9yX7K6X/ANw6P+2mf3K0kkpq/srpf/cOj/tpn9yX7K6X/wBw6P8Atpn9ytJJKav7 K6X/ANw6P+2mf3Jfsrpf/cOj/tpn9ytJJKav7K6X/wBw6P8Atpn9yX7K6X/3Do/7aZ/crSSSmr+y ul/9w6P+2mf3Jfsrpf8A3Do/7aZ/crSSSmr+yul/9w6P+2mf3Jfsrpf/AHDo/wC2mf3K0kkpq/sr pf8A3Do/7aZ/cl+yul/9w6P+2mf3K0kkpq/srpf/AHDo/wC2mf3Jfsrpf/cOj/tpn9ytJJKav7K6 X/3Do/7aZ/cl+yul/wDcOj/tpn9ytJJKav7K6X/3Do/7aZ/cl+yul/8AcOj/ALaZ/crSSSmr+yul /wDcOj/tpn9yX7K6X/3Do/7aZ/crSSSmr+yul/8AcOj/ALaZ/cl+yul/9w6P+2mf3K0kkpq/srpf /cOj/tpn9yX7K6X/ANw6P+2mf3K0kkpq/srpf/cOj/tpn9yX7K6X/wBw6P8Atpn9ytJJKav7K6X/ ANw6P+2mf3Jfsrpf/cOj/tpn9ytJJKav7K6X/wBw6P8Atpn9yX7K6X/3Do/7aZ/crSSSmr+yul/9 w6P+2mf3Jfsrpf8A3Do/7aZ/crSSSmr+yul/9w6P+2mf3Jfsrpf/AHDo/wC2mf3K0kkpq/srpf8A 3Do/7aZ/cl+yul/9w6P+2mf3K0kkpq/srpf/AHDo/wC2mf3Jfsrpf/cOj/tpn9ytJJKav7K6X/3D o/7aZ/cl+yul/wDcOj/tpn9ytJJKav7K6X/3Do/7aZ/cov6b0mtjnvxKA1gLnE1s0A1PZXFm9dsB xG4m7acx4pcfCvV9zvlW0oE0F0I8UgO/5OHh0YINmfkY9Qqx6X5VjCxsb8gzTXEfm1tGniVH6m9M oyWZOblUstDnenW17QWg/ScQCPMKn1rPjAZjs9r855y72+FZ0or+TGgrb+peZVb0w4gAbZjOO4eI eS4O/grEIGHLGX+cIv8AusefIJ8zw9MYIA8err/srpf/AHDo/wC2mf3Jfsrpf/cOj/tpn9ytJKBc 1f2V0v8A7h0f9tM/uS/ZXS/+4dH/AG0z+5WkklNX9ldL/wC4dH/bTP7lZa1rWhrQGtaIAGgAHYJ0 klKSSSSUpJJJJSkkkklKSSSSU8J9euqfXHB6vR+zcizB6MaAbsyvFblBt0vn1Bte9o2gagIHSD9d Orsbd03644eWzRzmNxqtwB1h7PTa9vzhbH1q+vdHQc5nS6McZPULahe0XX1YtAYXFnuuvcBPtOi5 GzpHTOudTb1Xrf1g6P0q1hJZX0i6plpmINmQ5wJcIjgpKfVa6aat/pVtr9R29+0AbnEAbnRyYCmk kkphbbVTW6257a62Aue9xAaAO5JWZ0X6z9J65kZmP0577Dg+n6r3MLGuFwc6tzC6C5pDZn7lp21V XVmu5jbK3RLHCQYM6grl/q7p9evrcB/5rf8A23ckp1uq/WCjp14xm4mXn5Jb6hpw6TYQ3XVz3FrG /RMS6SjdF630/reIcvAeXMY91Vtb2llldjfpMsY7Vrgj52didPxLc3MsbTj0NLrLHGAAFyeBT1HC +qX1i63c04uX1NuX1Gmkth9LTSfRDx+/DQXeaSnRt+vPSmNsyGY2Zd02hzmXdTqoLsZpYS1+s+o5 rSPpNYR5roa7GW1tsrcHseA5jhqCCJBCw/q5RS76kdOpcB6VnTag8Hj30gvn7yl9RXOf9T+kF2p+ zMHyAgfgElO8kkq9uTdW8tZi22gfnsNQB/z7Gn8ElMcP+kZ3/Ht/88Uq0szFyrxfmEYdzt1wJANO n6GoQZt+eis/bMj/ALg3/wCdR/6WSU2klV+2ZH/cG/8AzqP/AEsl9syP+4N/+dR/6WSU2klV+2ZH /cG//Oo/9LJfbMj/ALg3/wCdR/6WSU2klV+2ZH/cG/8AzqP/AEsl9syP+4N/+dR/6WSU2klV+2ZH /cG//Oo/9LJfbMj/ALg3/wCdR/6WSU2klV+2ZH/cG/8AzqP/AEsl9syP+4N/+dR/6WSU2klV+2ZH /cG//Oo/9LJfbMj/ALg3/wCdR/6WSU2klV+2ZH/cG/8AzqP/AEsl9syP+4N/+dR/6WSU2klV+2ZH /cG//Oo/9LJfbMj/ALg3/wCdR/6WSU2klV+2ZH/cG/8AzqP/AEsl9syP+4N/+dR/6WSU2klV+2ZH /cG//Oo/9LJfbMj/ALg3/wCdR/6WSU2klV+2ZH/cG/8AzqP/AEsl9syP+4N/+dR/6WSU2klV+2ZH /cG//Oo/9LJfbMj/ALg3/wCdR/6WSU2klV+2ZH/cG/8AzqP/AEsl9syP+4N/+dR/6WSU2klV+2ZH /cG//Oo/9LJfbMj/ALg3/wCdR/6WSU2klV+2ZH/cG/8AzqP/AEsl9syP+4N/+dR/6WSU2klV+2ZH /cG//Oo/9LJfbMj/ALg3/wCdR/6WSU2klV+2ZH/cG/8AzqP/AEsl9syP+4N/+dR/6WSU2klV+2ZH /cG//Oo/9LJfbMj/ALg3/wCdR/6WSU2klV+2ZH/cG/8AzqP/AEsl9syP+4N/+dR/6WSU2klV+2ZH /cG//Oo/9LJfbMj/ALg3/wCdR/6WSU2klV+2ZH/cG/8AzqP/AEsl9syP+4N/+dR/6WSU2klV+2ZH /cG//Oo/9LJfbMj/ALg3/wCdR/6WSU2klV+2ZH/cG/8AzqP/AEsl9syP+4N/+dR/6WSU2klV+2ZH /cG//Oo/9LJfbMj/ALg3/wCdR/6WSU2klV+2ZH/cG/8AzqP/AEsl9syP+4N/+dR/6WSU2klV+2ZH /cG//Oo/9LJfbMj/ALg3/wCdR/6WSU2klV+2ZH/cG/8AzqP/AEsl9syP+4N/+dR/6WSU2klV+2ZH /cG//Oo/9LJfbMj/ALg3/wCdR/6WSU2klV+2ZH/cG/8AzqP/AEsl9syP+4N/+dR/6WSU2klV+2ZH /cG//Oo/9LJfbMj/ALg3/wCdR/6WSU2klV+2ZH/cG/8AzqP/AEsl9syP+4N/+dR/6WSU2klV+2ZH /cG//Oo/9LJfbMj/ALg3/wCdR/6WSU2klV+2ZH/cG/8AzqP/AEsl9syP+4N/+dR/6WSU2klV+2ZH /cG//Oo/9LJfbMj/ALg3/wCdR/6WSU2klV+2ZH/cG/8AzqP/AEsl9syP+4N/+dR/6WSU2klV+2ZH /cG//Oo/9LJfbMj/ALg3/wCdR/6WSU2klV+2ZH/cG/8AzqP/AEsl9syP+4N/+dR/6WSU2klV+2ZH /cG//Oo/9LJfbMj/ALg3/wCdR/6WSU2klV+2ZH/cG/8AzqP/AEsl9syP+4N/+dR/6WSU2klV+2ZH /cG//Oo/9LJfbMj/ALg3/wCdR/6WSU2klV+2ZH/cG/8AzqP/AEsl9syP+4N/+dR/6WSU2klV+2ZH /cG//Oo/9LJfbMj/ALg3/wCdR/6WSU2lz3WHOzOoHGYeA3DYR2fkfpL3f2aW/itS3qFtVb7bMK9r K2lz3F1OgAkn+eXLW9Qux6rcuyp7Lgx5DiWQMjM94Ojp9lIAGnxhDhMpRgP0iy4iIRnlP6A/H+Wi 1GNR1v6027WD7HR9IDhzawGN/wA4/gusxOldPwrDZi0Nqe4bS5vMTMfgsP6pY92FgG/7JbY/KIcH tNQGwfR+na0+J4W79syP+4N/+dR/6WU+eZ4uCJPDAcP2NXFHTiI9Ujxfa2klV+2ZH/cG/wDzqP8A 0sl9syP+4N/+dR/6WULK2klV+2ZH/cG//Oo/9LJfbMj/ALg3/wCdR/6WSU2klV+2ZH/cG/8AzqP/ AEsrLSS0EgtJElpiR5GJCSl0kkklKSSSSUpJJJJSkkkklPGfWPrP1Gr6pZX9aOnmu+mKqsvJxXWV 2MjePSsY18gbj81Tyeof4nMave9nT3gmAKqDY6fhWwq99bep/XPpjc3Mpr6Seh47Wua7L9Y2kQ0E Oa1waSXmGgeSxcnM+vPR8NnVsjpPQcKq59fr3elY11RtLWNfeWWdiQ0kTHwSU9z0PrlPW6LMnHx8 iihj9lb8ms1eqIDt9bXalusStJJJJSHLOWMaw4Ta3ZMfom3Fzay7+U5gcQPgFy3Sej/XHD+sPUer XM6aWdWdjfaWMuvJrZjs9I+nNA3EtM6rr0klPMfWLo/1j6h1nFyMZuFk9MxGiyvDy7La5yZ0teK6 rA7YPog99VqYDOt5FWRT12nEZVY3YwYlllm4ODg8P9WuuNIiFppJKeTx+i/W7E6YPq/j34n2BjPs 9PUnF/2llEbQPQ2bDY0aA747x2XSdPwaOnYGPgYwIoxa201zqdrBtE+eisJJKUkkkkpq4f8ASM7/ AI9v/nilWlVw/wCkZ3/Ht/8APFKtJKUkkkkpSSSSSlJJJJKUkkkkpSSSSSlJJJJKUkkkkpSSSSSl JJJJKUkkkkpSSSSSlJJJJKUkkkkpSSSSSlJJJJKUkkkkpSSSSSlJJJJKUkkkkpSSSSSlJJJJKUkk kkpSSSSSlJJJJKUkkkkpSSSSSlJJJJKUkkkkpSSSSSlJJJJKUkkkkpSSSSSlJJJJKUkkkkpSSSSS lJJJJKUkkkkpSSSSSlJJJJKUkkkkpSSSSSlJJJJKczr1jfs1eI4wMp+20+FLB6tx/wA1sfNcnler 1POxentkOveci8D8113v/wDA6g0LX+sGUx+ReXn9HU0Yoj+UPXyY/wCtta35oX1MxX5GRldXvEue 4sYe0u9zyPwCkwaGeU/oDhj/AHinmNMePD1yHjl/d/t/Y9XXWyqttVY2sYA1oHYAQApJJKNCkkkk lKSSSSUpJJJJSkkkklKSSSSUpJJJJSkkkklNDrvTMHqvSMrp/UDsxL6yLXyG7NvuD5doNpAOq4ej oVPV8R1Wf9cT1P6v41ldd1IayvcQ5vpV2ZG8kyY17nzXYfWzpuV1T6v5mFiQb7AxzWOMB/pvbY6p xkaWBpYfiuD39Vz29b6Jg/VzKwR1h9FdfqVCrHxq6qqqLHF2jTBYS3bykp9SAAAA4HCdM0Q0AmYE SnSUiyrL6sd78er17gP0dW4N3HzceAue+rHV+uZfXuu9M6u6lzunfZDU3HaQxv2it9rmhzvc6NBJ +4cLplyn1d/8Xf1u/wDab/7buSU2M7P6r1Lr93Q+k5bMCvApZbn5QrbbcH3Emqqttksb7Wlzi4HQ iPFLpPWs3EyuqdM67cy5/SqmZTc5rRV6mM9rjusYDtD2ljt0QEHorDj/AF9+sjLSA7NpwMigTqWV 1vpcY8nBVOpY9nU+t/WirEh7h0ZuESOPXsbkPawkd4cJSUkx7vrj1Doo+sWNn1UPtqdk4nSvQa6k 1QX1sttP6Xe5sSWuAnsuk6P1KvqvSsTqVbSxmXUy0MOpbuElvyWV9Xs/Fr+omBmPe0UY/Tq/UcSN o9KoNeD82o31Jotx/ql0mq1pa8Y1ZLToRuG4T96SnbSSVe3GuseXMyragfzGCogf59bj+KSmOH/S M7/j2/8AnilWlmYuLeb8wDMubtuAJAp1/Q1GTNXy0Vn7Hkf9zr/82j/0ikptJKr9jyP+51/+bR/6 RS+x5H/c6/8AzaP/AEikptJKr9jyP+51/wDm0f8ApFL7Hkf9zr/82j/0ikptJKr9jyP+51/+bR/6 RS+x5H/c6/8AzaP/AEikptJKr9jyP+51/wDm0f8ApFL7Hkf9zr/82j/0ikptJKr9jyP+51/+bR/6 RS+x5H/c6/8AzaP/AEikptJKr9jyP+51/wDm0f8ApFL7Hkf9zr/82j/0ikptJKr9jyP+51/+bR/6 RS+x5H/c6/8AzaP/AEikptJKr9jyP+51/wDm0f8ApFL7Hkf9zr/82j/0ikptJKr9jyP+51/+bR/6 RS+x5H/c6/8AzaP/AEikptJKr9jyP+51/wDm0f8ApFL7Hkf9zr/82j/0ikptJKr9jyP+51/+bR/6 RS+x5H/c6/8AzaP/AEikptJKr9jyP+51/wDm0f8ApFL7Hkf9zr/82j/0ikptJKr9jyP+51/+bR/6 RS+x5H/c6/8AzaP/AEikptJKr9jyP+51/wDm0f8ApFL7Hkf9zr/82j/0ikptJKr9jyP+51/+bR/6 RS+x5H/c6/8AzaP/AEikptJKr9jyP+51/wDm0f8ApFL7Hkf9zr/82j/0ikptJKr9jyP+51/+bR/6 RS+x5H/c6/8AzaP/AEikptJKr9jyP+51/wDm0f8ApFL7Hkf9zr/82j/0ikptJKr9jyP+51/+bR/6 RS+x5H/c6/8AzaP/AEikptJKr9jyP+51/wDm0f8ApFL7Hkf9zr/82j/0ikptJKr9jyP+51/+bR/6 RS+x5H/c6/8AzaP/AEikptJKr9jyP+51/wDm0f8ApFL7Hkf9zr/82j/0ikptJKr9jyP+51/+bR/6 RS+x5H/c6/8AzaP/AEikptJKr9jyP+51/wDm0f8ApFL7Hkf9zr/82j/0ikptJKr9jyP+51/+bR/6 RS+x5H/c6/8AzaP/AEikptJKr9jyP+51/wDm0f8ApFL7Hkf9zr/82j/0ikptJKr9jyP+51/+bR/6 RS+x5H/c6/8AzaP/AEikptJKr9jyP+51/wDm0f8ApFL7Hkf9zr/82j/0ikptJKr9jyP+51/+bR/6 RS+x5H/c6/8AzaP/AEikptJKr9jyP+51/wDm0f8ApFL7Hkf9zr/82j/0ikptJKr9jyP+51/+bR/6 RS+x5H/c6/8AzaP/AEikptJKr9jyP+51/wDm0f8ApFL7Hkf9zr/82j/0ikptJKr9jyP+51/+bR/6 RS+x5H/c6/8AzaP/AEikptJKr9jyP+51/wDm0f8ApFL7Hkf9zr/82j/0ikptJKr9jyP+51/+bR/6 RS+x5H/c6/8AzaP/AEikptJKr9jyP+51/wDm0f8ApFL7Hkf9zr/82j/0ikptJKr9jyP+51/+bR/6 RS+x5H/c6/8AzaP/AEikptJKr9jyP+51/wDm0f8ApFL7Hkf9zr/82j/0ikptJKr9jyP+51/+bR/6 RS+x5H/c6/8AzaP/AEikptJKr9jyP+51/wDm0f8ApFL7Hkf9zr/82j/0ikptJKr9jyP+51/+bR/6 RS+x5H/c6/8AzaP/AEikptIeRezHosvsMMqaXuPk0SUH7Hkf9zr/APNo/wDSKzOuVvZVVjW5lz67 3F14Ip0ppHq2H21DwA+aBNBdCPFID7fLq8v1i657qsTU3uG+5o1/S5BFz2/KWNHwXddKwW9P6fRi N5rb7yO7jq4/euM+rmHd1frD8u2xzfSJudaNpO9xlv0mlvOvHZdp9jyP+51/+bR/6RU0/Rjhj8OO Xmf4BZKXHlnPpfBHyG9eZbSSq/Y8j/udf/m0f+kUvseR/wBzr/8ANo/9IqJLaSVX7Hkf9zr/APNo /wDSKX2PI/7nX/5tH/pFJTaSVX7Hkf8Ac6//ADaP/SKX2PI/7nX/AObR/wCkUlNpJVfseR/3Ov8A 82j/ANIqy0ENAJLiBBcYk+ZiAkpdJJJJSkkkklKSSSSUpJJJJTk/WvqeV0roGXnYkevUGBr3Auaz e9lbrXATIrDt5+C5J3W+qdK6P9YW2dZ+3ZmBZjfYslwr/SOsqpuNbK2yC17nFsDWO67H6x9Uwekd Ey+odQr9XFpZFlUbt+8itrIOnuc4BecY9GF0LKr691T6l/YMAWMc7KGUcj0N7hsf9ncSNHEdhHZJ T6w0ktBIgkahOmBBAI4PCdJSHLxKM3GsxcgF1No2vDXOYY8n1lrh8isbG+o31ZxMsZmPj2syA5jz Z9qySXOr+hv3XEOjwct9JJTndV6B0rqz6rM2pxuon0r6rH02tB5aLKXMdB8JhG6b0vA6XjDFwKRT VJcQCS5zjy97nEuc49yTKJmZ+DgVevnZFWLTMepc9tbZP8p5AU8fJx8qlt+Nay+l4lllbg9rge4c 2QUlOQ76m/Vx2S7IOIffZ6z6PUs+zmznecff6Uzr9HnXlbXGgVWzq3SqsxuBZmUMzH6sxnWsFp54 rLtx48FbSUpJJJJTVw/6Rnf8e3/zxSrSq4f9Izv+Pb/54pVpJSkkkklKSSSSUpJJJJSkkkklKSSS SUpJJJJSkkkklKSSSSUpJJJJSkkkklKSSSSUpJJJJSkkkklKSSSSUpJJJJSkkkklKSSSSUpJJJJS kkkklKSSSSUpJJJJSkkkklKSSSSUpJJJJSkkkklKSSSSUpJJJJSkkkklKSSSSUpJJJJSkkkklKSS SSUpJJJJSkkkklKSSSSUpJJJJSkkkklKSSSSUpJJJJSkkkklKSSSSUpcd9as73ZJaeduFV8BF2Q7 /qGrq8vIZi4tuTZ9Cljnn+yJhcL9ns6n1rG6c6SKdck/8I8+tkH4ydnyRhESnEH5fml5BkieCE8g 3rhj/eP8g9N9U+n/AGLpLHuEW5P6V/jB+gPu1W0mAAAAEAaABOjORlIyPUsUY8IAHRSSSSalSSSS SlJJJJKUkkkkpSSSSSlJJJJKUkkkkpSSSSSnN+sOA/qnSMrpdT6W3ZdewC8FzNpI3EtY5ruOCDod Vw2f0P60Z5b9Xs/63YNzyWEYD6qfUf6RFjA5m3c/6MwZnutj6w3dY6L9Z39bw+k29Xbl4LcOh1AL n02se+zbYACRW/cCT5LDyvqTkYn1NOZZim/635mTVkjJa0vtrvsva86skNDWTu7Skp7n6u4f1hxM e1nXuoM6lc54NVjKm1bWxq0hjWg6rWTNnaN3Ma/FOkpSSSSSnj/rDdj9I+tVHWesUjI6VdjNxKLY 9Q49/qFx/QauPqggbmAnTVC6Hc3C6X9Y/rT09ja+nZbXZnT8NpaGj7PQd1hayQx1zmyRyO+qs5Vm R0v63ZXVOo4mRmYV2PTX07Ix6XZH2ct3evWWV7ntL3Q7dtg8JumdJPUcvrtzcWzA6T1fHZQym1pq dZY5j2XX+joWS1wGsEwkpj0b6s9IzvqPTXk41dt3UsQZWRkOaDa6/IZ6ptLzruDnaeC1/qhmX531 X6Zl5Di+63GYbHnlzgNpcfjCxOndX6lgfV+roLul5b+s4tAw62tqccd5Yz02W/ao9P041Os9oldH 0Dph6T0TB6a5we7EoZW9w4LgPcR80lOgq9ufg0vNd2TVW8cse9rTr5EqwkkpzMXqXTm35hdlUgPu BaTY3UejU2Rr4hWf2r0v/uZR/wBus/vSw/6Rnf8AHt/88Uq0kpq/tXpf/cyj/t1n96X7V6X/ANzK P+3Wf3q0kkpq/tXpf/cyj/t1n96X7V6X/wBzKP8At1n96tJJKav7V6X/ANzKP+3Wf3pftXpf/cyj /t1n96tJJKav7V6X/wBzKP8At1n96X7V6X/3Mo/7dZ/erSSSmr+1el/9zKP+3Wf3pftXpf8A3Mo/ 7dZ/erSSSmr+1el/9zKP+3Wf3pftXpf/AHMo/wC3Wf3q0kkpq/tXpf8A3Mo/7dZ/el+1el/9zKP+ 3Wf3q0kkpq/tXpf/AHMo/wC3Wf3pftXpf/cyj/t1n96tJJKav7V6X/3Mo/7dZ/el+1el/wDcyj/t 1n96tJJKav7V6X/3Mo/7dZ/el+1el/8Acyj/ALdZ/erSSSmr+1el/wDcyj/t1n96X7V6X/3Mo/7d Z/erSSSmr+1el/8Acyj/ALdZ/el+1el/9zKP+3Wf3q0kkpq/tXpf/cyj/t1n96X7V6X/ANzKP+3W f3q0kkpq/tXpf/cyj/t1n96X7V6X/wBzKP8At1n96tJJKav7V6X/ANzKP+3Wf3pftXpf/cyj/t1n 96tJJKav7V6X/wBzKP8At1n96X7V6X/3Mo/7dZ/erSSSmr+1el/9zKP+3Wf3pftXpf8A3Mo/7dZ/ ei35ONjM9TJtZSwmA6xwaJ8JdCB+2ekHQZ2P/wBus/8AJIWFwjI6gE+QZftXpf8A3Mo/7dZ/el+1 el/9zKP+3Wf3q0kitav7V6X/ANzKP+3Wf3pftXpf/cyj/t1n96tJJKav7V6X/wBzKP8At1n96X7V 6X/3Mo/7dZ/erSSSmr+1el/9zKP+3Wf3pftXpf8A3Mo/7dZ/erSSSmr+1el/9zKP+3Wf3pftXpf/ AHMo/wC3Wf3q0kkpq/tXpf8A3Mo/7dZ/el+1el/9zKP+3Wf3q0kkpq/tXpf/AHMo/wC3Wf3pftXp f/cyj/t1n96tJJKav7V6X/3Mo/7dZ/el+1el/wDcyj/t1n96tJJKav7V6X/3Mo/7dZ/el+1el/8A cyj/ALdZ/erSSSmr+1el/wDcyj/t1n96X7V6X/3Mo/7dZ/erSSSmr+1el/8Acyj/ALdZ/el+1el/ 9zKP+3Wf3q0kkpq/tXpf/cyj/t1n96X7V6X/ANzKP+3Wf3q0kkpq/tXpf/cyj/t1n96X7V6X/wBz KP8At1n96tJJKav7V6X/ANzKP+3Wf3pftXpf/cyj/t1n96tJJKav7V6X/wBzKP8At1n96X7V6X/3 Mo/7dZ/erSSSmr+1el/9zKP+3Wf3pftXpf8A3Mo/7dZ/erSSSmr+1el/9zKP+3Wf3pftXpf/AHMo /wC3Wf3q0kkpq/tXpf8A3Mo/7dZ/el+1el/9zKP+3Wf3q0kkpq/tXpf/AHMo/wC3Wf3pftXpf/cy j/t1n96tJJKav7V6X/3Mo/7dZ/el+1el/wDcyj/t1n96tJJKav7V6X/3Mo/7dZ/el+1el/8Acyj/ ALdZ/erSSSmr+1el/wDcyj/t1n96X7V6X/3Mo/7dZ/erSSSmr+1el/8Acyj/ALdZ/el+1el/9zKP +3Wf3q0kkpq/tXpf/cyj/t1n96X7V6X/ANzKP+3Wf3q0qufmtw6Q7abLrDsopHL3ngfDuT2CSQCT Q3L5nZ1TqdzCy3Lvex3LXWPIMa8Erf8AqTfiVZGbkZdzK7SGBr7XgE7i5z/pHXUCVzl2Oabn1B7L fTO31GElpj90kBdj9Q8V1eNlZJexzbnMaGtJ3NNe+d0gc7xEKKGPLGpkERPV0ubz8ucc8cZRMxXp G+4d/wDavS/+5lH/AG6z+9L9q9L/AO5lH/brP71aSUrmNX9q9L/7mUf9us/vS/avS/8AuZR/26z+ 9WkklNX9q9L/AO5lH/brP70v2r0v/uZR/wBus/vVpJJTV/avS/8AuZR/26z+9L9q9L/7mUf9us/v VpJJTV/avS/+5lH/AG6z+9WWua5oc0hzXCQRqCD3CdJJSkkkklKSSSSUpJJJJSkkkklKSSSSUpJJ JJSkkkklKSWX1brgwcnHwMbGszuoZYc6rGrLWgVsgPttseQGMBcB3PgCi9NzOpXss/aeCOnvrAIL bm3VuB3TteAx3tjWWjnSUlN9JcufrjnvxH9WxOjW5HRKt7jlC1jb31sJDrasYj3M0kS8Ejsujxcm jMxqsrHeLKL2NsqeOC1w3NP3JKSpJJJKauH/AEjO/wCPb/54pVpVcP8ApGd/x7f/ADxSrSSlJJJJ KUkkkkpSSSSSlJJJJKUkkkkpSSSSSlJJJJKUkkkkpSSSSSlJJJJKUkkkkpSSSSSlJJJJKUkkkkpS SSSSlJJJJKeb+vn/ACRT/wCGW/8AUWLhDwu96/bV1C1uF6fr1UWAbASPUyS0hlQLYgMa4ueeyz+o fVbEw2UMaz1H3Vur3kuj7Q39IzSeHgFn3d1BkiZEkOpyuaOPHGE74pWR5PZJIOJk15eLVk1/QtaH AeE9j8EZTuYQQSD0UkkkkhSSSSSlJJJJKUkkkkpSSSSSlJJJJKUkkkkpSSSSSlJJJJKUkkkkpSSS SSlJJJJKUkkkkpSSSSSlJJJJKUkkkkpSSSSSlJJJJKUkkkkpSSSSSlJJJJKUkkmc5rWlziGtaJJO gACSkeTk04tD8i922usS4/wHiSuM671S8mx9ntybQay2f5ms6+i3+W4a2Ht9FaPUOouzLRc13p01 NNmOXDRjBocuxv4VN7nVZnQum/tnqJyLGEYGMdGuMlxncGuPcuPucU7FATJlL+bhv4nsyZJezERj /PZNv6o7t/6ufVfGswvtXUqvUffDqqyS3azsTtI1cuhwemYPTw8YdQqFkF8FxmOPpE+Ksp0Z5ZTJ smj+j0YYwjGtNe/VSSSSYuUkkkkpSSSSSlJJJJKUkkkkpSSSSSlJJJJKUkkkkpSSSSSlJJJJKUkk kkpSSSSSnj7ausZH166i3p19GI9mBitN19Tr3bC+50MYLKx9LmSo5fU+tjD+snROoPrvy8Tpr8jE y8VjqnPbbVa0bq9z9r2vZpDlsdV6DlZHU6usdLzPsHUK6jj2F9YuqtqJ3htjNzDLXatIcp9I6B9i tzMzNyHZ/UOo7RlXuaGM2MBayqqoEhjG7j3JPclJSL6tir/mV0wH+b/ZtO//ALZbuUfqJu/5n9I3 TP2ZnPh2/BVa/ql1WnDPRqOsOr6IQWNp9EHJbSeaW5O+I7TsmPvXR4uNRiY1WLjsFdFDG11MHDWs G1o+4JKSqva/ODyKaans7Ofa5h/zRU/8qsJJKczFs6j6+ZtopJNw3A3OEH0auP0JnRWfU6p/3Ho/ 7ff/AOkEsP8ApGd/x7f/ADxSrSSmr6nVP+49H/b7/wD0gl6nVP8AuPR/2+//ANIK0kkpq+p1T/uP R/2+/wD9IJep1T/uPR/2+/8A9IK0kkpq+p1T/uPR/wBvv/8ASCXqdU/7j0f9vv8A/SCtJJKavqdU /wC49H/b7/8A0gl6nVP+49H/AG+//wBIK0kkpq+p1T/uPR/2+/8A9IJep1T/ALj0f9vv/wDSCtJJ KavqdU/7j0f9vv8A/SCXqdU/7j0f9vv/APSCtJJKavqdU/7j0f8Ab7//AEgl6nVP+49H/b7/AP0g rSSSmr6nVP8AuPR/2+//ANIJep1T/uPR/wBvv/8ASCtJJKavqdU/7j0f9vv/APSCXqdU/wC49H/b 7/8A0grSSSmr6nVP+49H/b7/AP0gl6nVP+49H/b7/wD0grSSSmr6nVP+49H/AG+//wBIJep1T/uP R/2+/wD9IK0kkpq+p1T/ALj0f9vv/wDSCXqdU/7j0f8Ab7//AEgrSSSmr6nVP+49H/b7/wD0gl6n VP8AuPR/2+//ANIK0kkpq+p1T/uPR/2+/wD9IJep1T/uPR/2+/8A9IK0kkpq+p1T/uPR/wBvv/8A SCXqdU/7j0f9vv8A/SCtJJKavqdU/wC49H/b7/8A0gqPU+pdRx2CltdFd94dsf6rnCtrRLrXg0t9 rVp5WTTiY78i47a6xLj3+A8z2WDi413VM6x+UIaC05Y5AA91WIP6v0rPPRNkeg3LLigDc5fLH8WX RcPOa1maMestLNuM221wc1rjL7HfoTLrT7ifDRXuo0dTzMR9Ho0MeYdW8XOJa9p3McP0A4IWmkiA KpbLJIz4+oOjz3Qs7NJfj101RbOTUx1rm7Q9xbawRU76NgM+ErX9Tqn/AHHo/wC33/8ApBY2aD03 qhvbpW132tv/ABdkV5bfkdti6IEESNQeChHt2X5wLExtMX9Wt6nVP+49H/b7/wD0gl6nVP8AuPR/ 2+//ANIK0knMLV9Tqn/cej/t9/8A6QS9Tqn/AHHo/wC33/8ApBWkklNX1Oqf9x6P+33/APpBL1Oq f9x6P+33/wDpBWkklNX1Oqf9x6P+33/+kEvU6p/3Ho/7ff8A+kFaSSU1fU6p/wBx6P8At9//AKQS 9Tqn/cej/t9//pBWkklNX1Oqf9x6P+33/wDpBL1Oqf8Acej/ALff/wCkFaSSU1fU6p/3Ho/7ff8A +kEvU6p/3Ho/7ff/AOkFaSSU1fU6p/3Ho/7ff/6QS9Tqn/cej/t9/wD6QVpJJTV9Tqn/AHHo/wC3 3/8ApBL1Oqf9x6P+33/+kFaSSU1fU6p/3Ho/7ff/AOkEvU6p/wBx6P8At9//AKQVpJJTV9Tqn/ce j/t9/wD6QS9Tqn/cej/t9/8A6QVpJJTV9Tqn/cej/t9//pBL1Oqf9x6P+33/APpBWkklNX1Oqf8A cej/ALff/wCkEvU6p/3Ho/7ff/6QVpcf/jB/7QDt+m/9FJspcIJZMGL3ckYXw8V677C3pvU6p/3H o/7ff/6QS9Tqn/cej/t9/wD6QXmfS7GU9Tw7bHBjGX1ue46ANDwST8l6pXZXawWVPbYx2rXNIIPw IQhPivSmTmeW9kxHFxcXWqa/qdU/7j0f9vv/APSCXqdU/wC49H/b7/8A0grSSe12r6nVP+49H/b7 /wD0gl6nVP8AuPR/2+//ANIK0kkpq+p1T/uPR/2+/wD9IJep1T/uPR/2+/8A9IK0kkpq+p1T/uPR /wBvv/8ASCXqdU/7j0f9vv8A/SCtJJKavqdU/wC49H/b7/8A0gl6nVP+49H/AG+//wBIK0q3Uc+n p2HZmXhzq6o3BgBd7nBoiSO5SSASQBqSaC3qdU/7j0f9vv8A/SCXqdU/7j0f9vv/APSCxf8An50j /Q5P+az/ANKLVw+t9NysRmWLm0ssmG3Oaxw2kt1G4+CaJxOxZJYMsBcoEdEvqdU/7j0f9vv/APSC XqdU/wC49H/b7/8A0ghO690Zpj7ZS4+DHB//AFEqr1HruIenZX2Z1xt9Gz03sqt9rthIdv2QI8ZR 4h3CBhyEgcMtfBv+p1T/ALj0f9vv/wDSCxOp9Rzcx4xGUVvqFvpOrZa4+u8amsO9JvsZzZ90rkP2 x1c/9rsj/t1//klpdN6qzA6Nba15f1Cx7sfHLiT6VQDXuLQfo6u+/wCCbAnLIQiN2zk5cctA5pyE uHYDukzTmZmUOi0bH5D7Jy7mOLmveB47W7WVjQN7Lq+nYmb0/ErxaMajbWNXeu+XOPLj+g7qn9VO inAxfteQ39byBJnlrDqG/E8lb6sZZAAY4fLD8T3c+HFInJP5p/gOgavqdU/7j0f9vv8A/SCXqdU/ 7j0f9vv/APSCtJKJe1fU6p/3Ho/7ff8A+kEvU6p/3Ho/7ff/AOkFaSSU1fU6p/3Ho/7ff/6QS9Tq n/cej/t9/wD6QVpJJTV9Tqn/AHHo/wC33/8ApBL1Oqf9x6P+33/+kFaSSU1fU6p/3Ho/7ff/AOkE vU6p/wBx6P8At9//AKQVpJJTV9Tqn/cej/t9/wD6QVlu7aNwAdGoBkT5GAnSSUpJJJJSkkkklKSS SSUpJJJJSkkkklKSSSSUpJJJJSklk/WHqGTjY1WH0+D1PqL/AEMQHUMnWy938mpku89B3Wf9Wup3 431e6jmdSybMsdMyM1r77ILzVivcBO0DXa3sElPTJLjMPpfWuqfV9nXz1fMp6tlUHLxmVv24tYe0 2VVfZo2PaGkAlwJPK6P6v9TPVuiYPUnNDH5VLLHtHAcR7gPmkp0EkkklNXD/AKRnf8e3/wA8Uq0q uH/SM7/j2/8AnilWklKSSSSUpJJJJSkkkklKSSSSUpJJJJSkkkklKSSSSUpJJJJSkkkklKSSSSUp JJJJSkkkklKSSSSUpJJJJSklT6h1fp/TfT+22+l6s7Pa507Yn6DT4rH6l9a+l3VNxsPJINx223Bj wWMj3bZaJc7hqaZAbkMkMOSdERlR/So0z6hl25+YyrGhzWPLMUHVr7m/Tvd4sp7eLltYeJVh47Me qSG8uOrnOOrnOPiTqqfRsA0V/abWenda0NZV/oqW/QqH5XeJWmlEdTuU5ZjSEflj+JUkkknMTm9d o3Ygymt3vwz6hZ+9URtuZ82EpdDu3YhxXO3vxHekH/vVwHUv/tMIWiQCCCJB0IK53AJ6b1MY7jDG u+yO863TbiPPw91aadJA92aHrxyh1j6h/L+W70aSSScwqSSSSUpJJJJSkkkklKSSSSUpJJJJSkkk klKSSSSUpJJcT9YvrF1nC6zkY2NkenTXs2t2MPLGuOrmk8lNlIRFllw4ZZpGMSAQL1e2SXJfVLrv Veo9RsozL/VrbS54GxjYcHMH5jR+8utRjISFhGbFLFPgkQTV6KSSSRY1JJLK6n1ltPqUYrm+pX/P 3u1rpniY+k8/msCBIG66EJTNAJ+odTZifoqwLcpwLm1TtDWjmyx35jB4rCHQndeubl5dtnotBm8e 31JiBTW4HZW3sTq5Xun9Hdkfp81rhS8h/o2a2WuHFmSf+pYNAtzjQJtcW+3Zm9wYdMZ9fWX8Hnq/ qP0uqxttd+S2yshzHbq9HAyD/NpWdJ6jhPN2N7u5txIpsPnZju/Q2fKCuiSR4I9NFv3nKfmPH4Sc LF69kh5qvrGS5v0hUDXe3+vjWe7/ADCVbs+sPRq6PXsyWtZuDC2Hbw4gmHVgbhx3Ct5WDiZjAzJq baB9Ekag+LXDUfJcp9cel/ZcKq4XOtZ6oY1toD7Gy15gXfT26cGUJGUQTuvxxw5ZxiQYEno7X/O7 6vf9y/8AwO3/AMgtheQHhd8K/rC8hzzljyD8Rp/6LCE2GQm7H2MvMcnDHw8M6u74z+T0KDl5ePhY 78nJf6dNcbnQTEkNGjQTyVifZeuvILjlCOxyaB/1FCz+v4vVW9JvsyRaKmlkh+SLBq9oE1tpbOv8 pOM6BNFhhy4M4gzjqQPSRf0dn/nd9Xv+5f8A4Hb/AOQVk9d6VtaWXi1z2hza6g6x5BEj2MBcPmF5 evQuj9Gqs6XiuuvueyymtxpY70matBgikMLv7RTYZJS6Bn5jlcOEAky1NdP4M8n6wurMNobQTwcu xtZPwqZ6lh/zVkdey+p5XSr3WGw4/sLttHo1RvbHuvd6rtfABdTjdPwcQfq1FdR7lrQCfi7kqwnG JIIJYI5scJAxx3RB1/kafIJC7T6t9G+09Ix8j1/S375DaaS7R7m/zllbnHhdWkhHEAbJtlzc8ckR ER4Nbu+L9jmt6K0CDm5ZHgLAzn/imsQ8v6vYl2JfWw2Pvsre2t919rgHOEAkF5HPktZQuuqoqddc 4MrYJc52gAT+EHSmr70wb4iK17Pnuf8AVTN6fQbsrJxmN12je/c4gTDR6epVn6odD+2ZP23IbONj u9oPD3jgfAclVvrF1kdWzA6uRjUjbSDyZ+k+PNdt0N2K7pOMcQbadg9vcOH0p890qf2BggJi+OWn kCtnzuTmSccjHgiRLbUkN9JJJQoUkkkkpSSSSSlJJJJKUkkkkpSSSSSlJJJJKUkkkkpSSSSSlJJJ JKUkkkkpSSSSSlJJJJKUkkkkp5i/E+s9P1iyuqUYeLm1urZRhGzJdUaqh77Bs9Cz3Pf9IzwG+Cy/ q5T1nqX1f6/063Hppqy7epVttZabHDIte9hZ6fptG0Fx927XwXdodGNj47XNx6mUte91jxW0NBe8 7nOO3kuOpKSnmOhfWDpmL9RcTIuvYx2Fhsx7aif0guqYKjVs+lvLhELT+qGFfgfVjpmJkNLLqsas WMPLXEbi0/CYVo9D6K7O/aJwMY507vtRqZ6sxE79u6YV5JSlXtxrrHlzMq2oH8xgqIH+fW4/irCS SnMxcW835gGZc3bcASBTr+hqMmavlorP2PI/7nX/AObR/wCkUsP+kZ3/AB7f/PFKtJKav2PI/wC5 1/8Am0f+kUvseR/3Ov8A82j/ANIq0kkpq/Y8j/udf/m0f+kUvseR/wBzr/8ANo/9Iq0kkpq/Y8j/ ALnX/wCbR/6RS+x5H/c6/wDzaP8A0irSSSmr9jyP+51/+bR/6RS+x5H/AHOv/wA2j/0irSSSmr9j yP8Audf/AJtH/pFL7Hkf9zr/APNo/wDSKtJJKav2PI/7nX/5tH/pFL7Hkf8Ac6//ADaP/SKtJJKa v2PI/wC51/8Am0f+kUvseR/3Ov8A82j/ANIq0kkpq/Y8j/udf/m0f+kUvseR/wBzr/8ANo/9Iq0k kpq/Y8j/ALnX/wCbR/6RS+x5H/c6/wDzaP8A0irSSSmr9jyP+51/+bR/6RS+x5H/AHOv/wA2j/0i rSSSmr9jyP8Audf/AJtH/pFL7Hkf9zr/APNo/wDSKtJJKav2PI/7nX/5tH/pFL7Hkf8Ac6//ADaP /SKtJJKav2PI/wC51/8Am0f+kUvseR/3Ov8A82j/ANIq0kkpq/Y8j/udf/m0f+kUvseR/wBzr/8A No/9Iq0kkp4r69U2VHB332Xz6seoGCI9Pj02M/Fc/wBKaXdUw2hxaXZFQ3CJEvbqNwI+8Lserub1 PObSxjLfTc7Hxt7Q4G1wHrWEH82lv/SWtjdF6VjNqFeLTvpDdtpraXy3h26JnzUJgZTJBdCHMjDg jjkCZES/FJ9jyP8Audf/AJtH/pFL7Hkf9zr/APNo/wDSKtJKZz2r9jyP+51/+bR/6RS+x5H/AHOv /wA2j/0irSSSmr9jyP8Audf/AJtH/pFZHXOm2h1V5yrS20jHte4VjbJ3Uu9tbdG2x56roUHMxq8v FtxrPo2tLSe4ngj4ISFhfjnwzB+1pdOGTmYdd7s29lhBbazbR7bGna9v8z2cFZ+x5H/c6/8AzaP/ AEiszoWTYzJfRdo/IBc4eGRTFV4/te14+K3UomwnLDhmR03DV+x5H/c6/wDzaP8A0il9jyP+51/+ bR/6RVpJFjav2PI/7nX/AObR/wCkUvseR/3Ov/zaP/SKtJJKav2PI/7nX/5tH/pFL7Hkf9zr/wDN o/8ASKtJJKav2PI/7nX/AObR/wCkUvseR/3Ov/zaP/SKskgCToByV5DzqeUyc+GtLts8ty3v8Xq4 eGul7vqv2PI/7nX/AObR/wCkUvseR/3Ov/zaP/SK5r6m9QGN022t1F9o9cu31VmxolrBENl3bwW+ OvdJmH5ApJ7XNdV/58a1GMwQDssyYJwnKIBlwncBN9jyP+51/wDm0f8ApFL7Hkf9zr/82j/0ii05 eLfrRdXb/UcHfkKxMr66dLxsm3GfVe59L3VuLWsiWnaYmweCJkBuVkMWSZIjEkjd1vseR/3Ov/za P/SKhbS+it1t3Ubq62CXPcKAAPiaVm1/W3Hy6rHYVDwao32ZJbXUwOmC5zXOJ40AElQqw+odSsbf Y47QZZkXshrf/C+MdB/Xs18kOMHbVf7Eh/OegDvuxyepZZcwYuXeyt59lltdTn2f8RQ2kPd/WMBZ mV9UOsZ2Q/LNjW+qQYybC63QAe8117e3A44XW4fTsXELnVgvuf8Azl9h3WO/rOP5OFaQMOL5l0eY 9o/qgB0s7l4nF+pPVarC919Dfb7S0uJmRw4sG34haDq+vYdYZ62VWBzZFeawx/YZaP8ANK6ZJIQA 20VLmpzNzAl9HmsXquXYdr8i3II5OIaHuH9aiyllg+4qt1P60HCvbVRdk5ALA55d6VJa4kjaWPxS ey6bKwMLLEZNDLY4LgNw+DuQuM+tXRcpvUaxhUZORT6LdYsuDTuf7A47o+EoTMwNCycvHl8k6lHh 0Ol6fayq+tGdnX14tb8iv1SQ7YarHkbT7WbaK9pJ/OnRbnTvq7ZWyq3JyHstqJdTUwVubXu7kurI fZ4vhc79V+m9Ro67i23Yl1VbfU3PfW9rRNbwJLhHK79LHctZd1c2YYyMeKhEizRtq/Y8j/udf/m0 f+kUvseR/wBzr/8ANo/9Iq0kpGm1fseR/wBzr/8ANo/9IpfY8j/udf8A5tH/AKRVpJJTV+x5H/c6 /wDzaP8A0ihZHShksFeTk2XMB3BtleO4TxMOoPir6SSgSNQ5H/Nrp/l/2xi/+86u/Y8j/udf/m0f +kVaSSoJMidyT5tX7Hkf9zr/APNo/wDSKhd0119Zqvyrba3fSY9lDmmDOoNCupJIcj/m10/y/wC2 MX/3nVtmBbWxrGZlzGMAa1rW0AADQAAUq4klQSZSO5J82r9jyP8Audf/AJtH/pFL7Hkf9zr/APNo /wDSKtJJIav2PI/7nX/5tH/pFL7Hkf8Ac6//ADaP/SKtKt1DqGL07GdkZL9rBoB3cf3WjuUQCTQ1 JUSALKDKH2Oh2Rk9RurqYJLiKPuH6HUrlg7qv1nyjj122Dp9TpL7A0QPF3ptYHO8AiV1dS+tmZ6t s0dOqOgHA8m/vP8AE9l1+JiY+FQ3HxmCupnAH5T4lT6YR+9l/CP9rDrl8Mf4y/scVv1K6U0Aepcf Mln/AKTV7D6K3BqNOLlX1VklxaBUdT/WqPgtJJQmc5byJ8yyCERsAPo1fseR/wBzr/8ANo/9IpfY 8j/udf8A5tH/AKRVpJNXNX7Hkf8Ac6//ADaP/SKX2PI/7nX/AObR/wCkVaSSU1fseR/3Ov8A82j/ ANIpfY8j/udf/m0f+kVaSSU1fseR/wBzr/8ANo/9IpfY8j/udf8A5tH/AKRVpJJTV+x5H/c6/wDz aP8A0il9jyP+51/+bR/6RVpJJTV+x5H/AHOv/wA2j/0il9jyP+51/wDm0f8ApFWkklNX7Hkf9zr/ APNo/wDSKstBDQCS4gQXGJPmYgJ0klKSSSSUpJJJJSkkkklKSSSSUpJJJJSkkkklKSSSSU18zqGB gV+rnZNOJXxvvsbW2fi8gItdtd1bbKntsreJa9pBaR5EKpk9G6Rk5X27MxKb8hjPTFtzA8tZrIbv kNncZhcr9V8j9mfVv6xdTwKy3ptN+Zk9KqJ9hqqr3TXzDHPaYSU9bZ1bpVWY3AszKGZj9WYzrWC0 88Vl248eCtrkOjfVnpGd9R6a8nGrtu6liDKyMhzQbXX5DPVNpeddwc7TwWv9UMy/O+q/TMvIcX3W 4zDY88ucBtLj8YSU7CSSr25+DS813ZNVbxyx72tOvkSkpjh/0jO/49v/AJ4pVpZmL1Lpzb8wuyqQ H3AtJsbqPRqbI18QrP7V6X/3Mo/7dZ/ekptJKr+1el/9zKP+3Wf3pftXpf8A3Mo/7dZ/ekptJKr+ 1el/9zKP+3Wf3pftXpf/AHMo/wC3Wf3pKbSSq/tXpf8A3Mo/7dZ/el+1el/9zKP+3Wf3pKbSSq/t Xpf/AHMo/wC3Wf3pftXpf/cyj/t1n96Sm0kqv7V6X/3Mo/7dZ/el+1el/wDcyj/t1n96Sm0kqv7V 6X/3Mo/7dZ/el+1el/8Acyj/ALdZ/ekptJKr+1el/wDcyj/t1n96X7V6X/3Mo/7dZ/ekptJKr+1e l/8Acyj/ALdZ/el+1el/9zKP+3Wf3pKbSSq/tXpf/cyj/t1n96X7V6X/ANzKP+3Wf3pKbSSq/tXp f/cyj/t1n96X7V6X/wBzKP8At1n96Sm0kqv7V6X/ANzKP+3Wf3pftXpf/cyj/t1n96Sm0kqv7V6X /wBzKP8At1n96X7V6X/3Mo/7dZ/ekptJKr+1el/9zKP+3Wf3pftXpf8A3Mo/7dZ/ekptKh1fMfj0 Cqlwbk5BLKnHhgAl9rvJjdUQ9W6WBJzKNP8AhGf3rnzm4nVM7ddkV103j37ntbtxmO9tWp+lc4S4 fupsj0G5ZcMASZS+WOpdToOGxtf23aWte0V4jXfSbQDO4/yrD73LXVQdU6WBAy6ABwPUZ/en/avS /wDuZR/26z+9EChSyczORkW0kqv7V6X/ANzKP+3Wf3pftXpf/cyj/t1n96K1tJKr+1el/wDcyj/t 1n96X7V6X/3Mo/7dZ/ekptJKr+1el/8Acyj/ALdZ/el+1el/9zKP+3Wf3pKcjq9T8TqH2ikSbIya gO91Ai1n/XKSfuW9Vay6pltZ3MsaHMPiCJCyusZvTrsJzqszH+0Y5F9E2s+nXqBz+cPb80HonWem V0WYzsqmuup27H32Nb+itHqNZqeWSWkeSZdSruzmJyYhIAkw9J8neSVT9q9LOozKP+3Wf3p/2r0v /uZR/wBus/vT2BtJKr+1el/9zKP+3Wf3pftXpf8A3Mo/7dZ/ekptIGXm4+HV6t7toJ2taNXOceGs aNSSs/O+seDSRVjXVX3uEgmxoqYP3rH/AMBqVl4tlGdeci/PZWDIdkPe1lrh3ZRWT+hZ5/SKaZdB qWWGLTimeGP4lsZGRndVuOO2uWt5xZhjPA5djeT/AME35qFf1C6YGNFl97nge4tLGgnyBY6PvWvj 5nRMWltGPkY9dbeGtsZ/5LlF/avS/wDuZR/26z+9LgB+bVd94nHTEeCPh1aWH9Vej4lRr9M3EuLv VsI9QSAIDmBmmiMeiUARTkZNDf3W3Oc3/Nt3hH/avS/+5lH/AG6z+9L9q9L/AO5lH/brP70eEdlh zZCbMifNzbvq2X6+tVaexvxqnO/z6vScuD6hWac/JqO2a7rGnbIbo4j27iTHzXp37V6X/wBzKP8A t1n96qPH1Xse6ywYD3vJc5zvRJJOpJJTJ4720Z+X5w4yeMcQrSqDz/1Dxce67Lutra+yn0vSLhO0 u9SSPPRdqs/HyPq/i7vstuJRvjd6bq2THE7Y8Ub9q9L/AO5lH/brP706EeGNMPMZfdyGeoBqgeja SVX9q9L/AO5lH/brP70v2r0v/uZR/wBus/vTmJtJKr+1el/9zKP+3Wf3pftXpf8A3Mo/7dZ/ekpt JKr+1el/9zKP+3Wf3pftXpf/AHMo/wC3Wf3pKbSSq/tXpf8A3Mo/7dZ/el+1el/9zKP+3Wf3pKbS Sq/tXpf/AHMo/wC3Wf3pftXpf/cyj/t1n96Sm0kqv7V6X/3Mo/7dZ/el+1el/wDcyj/t1n96Sm0k qv7V6X/3Mo/7dZ/el+1el/8Acyj/ALdZ/ekptJKr+1el/wDcyj/t1n96X7V6X/3Mo/7dZ/ekptJK r+1el/8Acyj/ALdZ/el+1el/9zKP+3Wf3pKbSSq/tXpf/cyj/t1n96X7V6X/ANzKP+3Wf3pKbSSq Hq3Smgk5lED/AIRn965/qv12Y3dT0xm93HrvHt/st5PzT4Y5zPpH16LZzjHcut1X6xYPS7PRu3Ot NZsa1o51hrSe0rAwun9Q+s+X9v6gTXhNMVsGkj91n8XLnbsq7JvdkZD/AFbXmXOd3j+C9FwetdKt w6bBfTQCwfoS9rdkabdpI4VicfYgDEeqWhl28mCEvdkQflGoj3827TTVRU2mlgrrYIa1ugARFV/a vS/+5lH/AG6z+9L9q9L/AO5lH/brP71UbLaSVX9q9L/7mUf9us/vS/avS/8AuZR/26z+9JTaSVX9 q9L/AO5lH/brP70v2r0v/uZR/wBus/vSU2klV/avS/8AuZR/26z+9L9q9L/7mUf9us/vSU2klV/a vS/+5lH/AG6z+9L9q9L/AO5lH/brP70lNpJVf2r0v/uZR/26z+9L9q9L/wC5lH/brP70lNpJVf2r 0v8A7mUf9us/vS/avS/+5lH/AG6z+9JTaSVX9q9L/wC5lH/brP70v2r0v/uZR/26z+9JTaSVX9q9 L/7mUf8AbrP71Za5rmhzSHNcJBGoIPcJKXSSSSUpJJJJSkkkklKSSSSUpJJJJSkkkklKSSSSU8j9 b+o5ludV0U4meOl2V+rnZmFj2XGxs7RisdUDs3cvPMad1pYluB1rpOV0ijCysDF+znG2ZGPZjN9O xjq9te8NnaPDhbiSSnjOndX6lgfV+roLul5b+s4tAw62tqccd5Yz02W/ao9P041Os9oldH0Dph6T 0TB6a5we7EoZW9w4LgPcR81oJJKUkkkkpq4f9Izv+Pb/AOeKVaVXD/pGd/x7f/PFKtJKUkkkkpSS SSSlJJJJKUkkkkpSSSSSlJJJJKUkkkkpSSSjZZXWwvscGMbq5ziAB8SUlMkl5V1WxlvVMy1jg9j7 7XMcNQWl5gj5Lf8AqLm4uNZl132tqNvpemHmASPUkAnSdVEMtyqvrbdyciYYjkEuIgA8PD3+r2yS SSlaSkkkklKSSSSUpJJAzcuvDxX5DwXBg9rBy5x0a0ebjokkAkgDcuZ17MaR9i1dWALMsN5c0nbX QP5VrtPhKvdLw34uOTdByrz6mQ4cbj+aP5LR7QszpOI/Jy3ZGQQ8Y9hfY7s/KIh0fyaW+xvnKj1n 6242ITj4IGTlfRkasafl9I+QSx45ZJaC2TPkjjgIXtrLxLq9U6nj9NxH5FrhuAPpMJ1e7s0Lnvqv 9Ym7rMTqFsOtebKrXnTc4y5pPbXUIWL9WeqdWec3q97qnP8AosIl8f1dAweSsv8AqJjlpDMt4d2J aCPyhWhHBGJhKVyO5A28mkTllISjGgOh6vUpLjKeo9a+rVrcbPYcjCJhjgZEf8G8/wDUldTgdSw+ o0+tiWB7fzm8OafBw7KGeIx1+aJ2kNmWGQS02l1iW0kkko16kkkklOP9bv8AxPZf/W//AD6xecL1 nLxMfNx342Sz1KbI3NkiYIcNWkHkLN/5o/V7/uJ/4Jb/AOTUWTGZGxWze5Tm8eHGYyEiTK9K7Of0 7M6xX0/GbWbfTFNfpg4he2A1ugfXcCR5wj/trqjfphonUb8TKZ8RpvW9TTXRSyioba6mhjG6mGtE AaqaeInuwSzRJJMBqfAfseW6h17Js6fk1OONFlLwIN7HwWkGBZSBOviuJgL1nNx/tWHfi7tnr1vr 3RMb2lsxp4rlf/G/P/c//wAB/wDUqjyQkSOra5XmcMIyB/V2fE39gbf1T6XTb0rGysg+q0Oe6mkg BjXB7m7yB9N2nJ47LpVT6R0/9mdOqwvU9X0t36SNs7nOfxJ8fFXFJEVEDwaefJx5JG7HEeHytSSS ScxKSSSSUpJJJJSkkkklKSSSSUpJJJJSkkkklKSSSSUpJJJJSkkOm+m9hfS8WNDi0luurTBCqZnX OlYUjIyWB45Y07nf5rZKIjImgCT2QSALJFN9JctlfXiou9Pp+K+550a6zTXya2SVm9S6n9anY32n KLsLHc4NaGj0iSdYH+E4Cmjy0zV1C+5/YxnPAbXKuz2GJ1LFzL8iilxL8V+yye58R5TIVteU0Od6 zQLjTvIa6wE6Ankxquo/5r/WKv8AmepxHH6S1v5JTsnLxiR6+G9rC2GaUh8l12L1yS5H9jfXKr6G fvjj9K8/9W1Rtr+u+LW6114NdTS5zi6o6ASfphM9kHbJD7V3unrCT1ptqBc0vaCwBzwSJDTME+A0 KwOq/XHExyacBv2q/gO/wYPy1d8vvXIvy8jqGWHZuQW+u5rbrY0DRAktbtGi73pX1e6b0wB1TPUv 73v1d/Z7N+SfLFDFRncydojQfatjknksQ9IG5O/2OBT0PrvXbG5HVrXUUctrIh0fya+G/E6rpend IwOms24tQa46OsOr3fFyupKKeWUtPlj+6NAyRxxjrvLud1JJJKNepJJJJSkkkklKSSSSUpJJJJSk kkklKSSSSUpJJJJSkkkklKSSSSUpJJJJSkkkklKSSSSUpJJJJSkkkklKSSSSUpJJJJSkxIAJJgDU kp1mfWc2j6tdWNO4WjCyPTLJ3bvSft2xrMpKco/XHPfiP6tidGtyOiVb3HKFrG3vrYSHW1YxHuZp Il4JHZdHi5NGZjVZWO8WUXsbZU8cFrhuafuWR9WxV/zK6YD/ADf7Np3/APbLdyj9RN3/ADP6Rumf szOfDt+CSneSSVe1+cHkU01PZ2c+1zD/AJoqf+VJTHD/AKRnf8e3/wA8Uot+TjYzPUybWUsJgOsc GifCXQqOLZ1H18zbRSSbhuBucIPo1cfoTOiyPrq/Md0ukX1V1s+0Ngssc8zss7OqZ+VCRoE9mTDA TyRgTXEad39s9H/7nY3/AG6z/wAkrbHsexr2ODmOALXAyCDwQV5Eupwv+fX2Oj7LP2b02ej/AEf6 G0bPpa8eKZDIZE6NnmOTjjAImNT+lo9soW3U0Vm257aq2/Se8hrROmpK48W/X42upBPqMa17hGNo HFwaf+iVW6v/AM8f2fb+0/6H7fV/mP3m7f5v3fSjhPJoE1sGGGASlGPuQ1IGh11ev/bPR/8Audjf 9us/8krVV1N9Ytpe22t30XsIc0xpoQvI1v8AS8f6229PqPT3Pbh+70tr62fnO3cnd9KeUzHkMjR0 0Z+Y5KOOAkJ9a9VB9AQczI+y4l+SW7/QrfZtmJ2NLon5LjD0365uubQ/ItY97XPb+sEaNLQ76B/l hDy+gfWZuLfdlZBdVXW6ywOuc6Q0EnTWdFIRoaI/H+DWjCHEASdSNqP7W7/44B/7gf8Ag3/qJdJ0 jqH7S6fVm+n6Xq7vZO6NrnM5geC8skLd6X0Pr2VgsysG8NpeXBrG2uYRDiDIGnKixSlKRBI266N3 m+Ww48YMQYHiqxr0PcvoSS4azpX1xoNbftVhNrtjGjIcdQ1z/wA4xw0ojcL691mWvsdGmttbv+rK mrxH4/waPADtL7aH7Xd/53fV7/uX/wCB2/8AkEev6wdHsx/tDMlpr3FgEODi4AGGsI3HnsF5iOFr 9Hwuv341j+lsiovLH2MNbHzAlu9xDwIPYwocc5Tlw+keejc5jlMOHGZkzNHz/IPV5fXsguFVFYx3 O+h6wL7nf1MWv3/5xCFX0rqOc8W5MtjUWZcWvHmzHZ+hZ85KyacX649Or/Q1tpa5zWlwGOXOc9wY 3c7VxknurX/rwP8AX7MrP3a98uP/ABmj97EdMeKY8THVtX/UvpG51+Rk3gvdL3ufW0Fzz/xfclGo +qWLiV2NxMm5ptgPbaK7a3ATo+ssAPK5jq/UevknB6pbqwh5rAr0MS2TUPPhXsDqH1zz6jZh2erW w7CYoBkD+WAU48kBES4oDxvT7Vn+kcpPDcz4UDt4On9n6r0vWoOrqHegG/H/ALWO8+pX/YcVbxfr C1zN2VX+jGjsnHJtqH9cAepX/aase236+U1PusO2utpe8/q5gNEk6IF/TPrlkWi+yqL28XVmit/+ fWWuKb92I2y4/LiX/eoT/nMU/wC9GOr0dv1p6BS8sfltJAB9jXvGon6TGkI2B13pXUbnU4d/q2Nb vLdj2+0ECfe0eK856nXm151rM8bcobfUA292tI/m/bwj9C/bP2x/7H/pPpnf/N/Q3Nn+d05hVvcl x8JrQ1o3jyWL2fcjKVmIkOI0Nfo+nJLjDV9fyZl2v8rH/vQq6vrzfW2+t9jmWtD2H1KhIcJGkhS1 4hp+2P3o/aHoer/WXA6Tktxsiu173sFgNYaRBJb+c9v7qweofWzGzchhqbZUyps0F7W6Wu9ptcGu P822do8VidZq6tVltHVi45BrBbuc152S6NWkjmVHouGM7qlGK5oeHlxLS4sB2tc6Nwa8jjwUXH+s ESfTxAGuzejy0I4DliLmISkLOl07LMvqnWWN6Z0is4+BUNrnEwSO5tePHmB+K6Lo31awelgWEevl d7nDj+oO35VYx683GqbTj4mNVW36LW3PA/8APCejL6jewvZjUgB72a3u5rc6s/4DxarU8unBAcEO w6+bkjHrxzPHM9T+xvJKr6nVP+49H/b7/wD0gl6nVP8AuPR/2+//ANIKJkTX0U5FTqb2Cyt4hzHC QVy2f9Wc7pt32/oVjvbqaZlwHgJ+mPI/iuj9Tqn/AHHo/wC33/8ApBDry+o2PtY3GpBpeGOm93Ja 2zT9B4PT4ZJQ22O4OxWzhGW+/Qjdy+jfW3HynDG6gBjZQO3cdGOPz+ifit9ltT3PYx4c6sgPaDJa SNwn5Fc59ZemC/EtzcnHootqbPrV3OLj2DS30AHTx/Fcx03qPU8S3ZgW7LLy1hB2kE8Nn1AQOVMM McsTKHo8DtfmxHLLGRGfq8Rv9j6akuR/9eB/r9mUBb9fDa6kH9IxrXuH6voHFwaf+iUz2P8AWY/8 Zd739Sf+K9ioCys2GoOHqNAcWTqAZAMfJcjbb9fKa322O211gue4/ZtABJKxGdb6q3MdnNvIyrG7 HP2t1bpptLdvbwTo8qZXU4n+6b1RLmAKuMh5in0xJcgD9fyAQZB1BH2ZRFv18NrqQf0jGte4fq+g cXBp/wCiU32P9Zj/AMZPvf1J/wCK9ioG2oWNqLgLHguaydSGxJA8pXJk/X8CTx/6DLCs611V+YzN svJyqRtY8NboNdIA2906PLGV1OJr9035IlnA3jIeYp9MSXHU3fXu+pl1Tt9djQ5jh9n1BSNv18Fr aSf0j2ue0fq+oaWhx/6QTfY/1mP/ABk+9/Un/ivYodl9NTq22PDXWu2Vgn6ToJgfcuV/9eB/r9mW Fn9U6vdks+23br8R52QGDa4HWPTEHUJ0OWMj88T/AHTaJZ6HyyH94U+lpLi8TJ+uvUKG349u6l0w /wDQN1BjiA5Tsp+u4dXXZftNztjDur5DXP8AzR4NKacFGjkgPqkZr2hP7HsUHLzMbDqFuS8V1lwY HHxcYC5f9mfXV/tOXtHj6kf9SJWF1W3qbb3YedlOyDS7Uby5odHn3CdDlxI1xxPfhWyzmIvgI830 tJcF0rD+sHVqHuxuoua2shrq7LrQQI0MNDhCsZH1c+sdVYdZnhzXPZXAttOtjm1jlvi5A4IxNSyA EeC4ZZEWIE/V7VV8/NpwMSzLunZUJgck8AD4lcmfqh18iDmVkHkepZ/5BY3Uun5eBknFus9Z7QC7 YXFoJ1j3AdkYYISlQyX1oDotnlnEWYV9X0erKx7aWXtePTtaHtJMaESouz8Fv0smps8S9o/ivPek dFt6nc+lhDHsbvh5LZEwYhjvFat31Ofj0W33Q5tTXPcGXQYaNxicdKeLFAkSmf8AFTHJkkLEB9r1 DutdHbzm0fKxp/IVVyvrP0emix9eQy2xrTsrbJ3O7DQLLb9S6xzVu+OSf4YoVTqP1Szd7Bg4jWtA l7hfvknt+kbXEfBKEMBIHFL60AqUswF8I+mpdLD+ufT/ALHW7NLhlRFjGNJEjuO2qjb9e+nj+ax7 n/1trfyFyodJ+rXU8fLDsvBqvqc0gi2xu0HkO9u8/gujqw7Kf5rp2HXH7ryPyY6OT2Iy0BneuktE Q96Q1Ij01Grhn67ZlxjE6fu7D3Of+DWhV836zfWVtW63HGJXZLWvNbmnUdjYV1GPldRvx6r68akM tY17QbnAgOEiYoQszCuzdn2vBxrvTnZuvfpMT/gPJNjlxAj9UK87KTjyEfzhvyp4fpdWVnXt6bXl HHquJcWku2F0fut0JIC6nD+pPTKYdkvfku7gnY37m6/irNfRq6rG219NxGvYQ5jhc+QRqD/MK/6n VP8AuPR/2+//ANII5eZMj6CYjqrHgA+cCR6M8XBw8Ru3FpZSO+xoBPxPJR1Roy+o3sL2Y1IAe9mt 7ua3OrP+A8WonqdU/wC49H/b7/8A0gq5JOp1ZgK2bSSq+p1T/uPR/wBvv/8ASCXqdU/7j0f9vv8A /SCSm0g5eLTmY78a8E1WRuAJaTBnkfBV68vqNj7WNxqQaXhjpvdyWts0/QeD0T1Oqf8Acej/ALff /wCkEgaNhTQ/5pdD/wBC7/Pd/etaqplNTKmTsraGtkkmAIGpQPU6p/3Ho/7ff/6QS9Tqn/cej/t9 /wD6QTpTlL5iT5oEYjYAeTaSVFuX1F176BjU762MeT67oh5e0f4D+QUT1Oqf9x6P+33/APpBNS2k lV9Tqn/cej/t9/8A6QS9Tqn/AHHo/wC33/8ApBJTaSVF2X1Ft7KDjU77GPeD67ohhY0/4D+WET1O qf8Acej/ALff/wCkElNpJVfU6p/3Ho/7ff8A+kEvU6p/3Ho/7ff/AOkElNpJUbMvqNb6mOxqSbnl jYvdyGus1/QeDET1Oqf9x6P+33/+kElNpJVfU6p/3Ho/7ff/AOkEvU6p/wBx6P8At9//AKQSU2kl Rvy+o0MD341JBexml7ubHNrH+A8XInqdU/7j0f8Ab7//AEgkptJKr6nVP+49H/b7/wD0gl6nVP8A uPR/2+//ANIJKbSSo5GX1HHosvfjUllTHPcBe6YaNxj9Aiep1T/uPR/2+/8A9IJKbSSq+p1T/uPR /wBvv/8ASCXqdU/7j0f9vv8A/SCSm0kqvqdU/wC49H/b7/8A0gi4t/2jFpyNu31mNs2zMbgHRKSk qSSSSlJJJJKUkkkkpSSSSSlJJJJKUkkkkpSSSSSlKL2te0seNzXAhwPcFSSSU8vX9Uuq04Z6NR1h 1fRCCxtPog5LaTzS3J3xHadkx966PFxqMTGqxcdgrooY2upg4a1g2tH3BFSSUpJJJJSGil1duS9x BF1ge2OwFddevzYoZ/TsPqNLaMyv1a2uDw3c5vuAImWEHgqykkkEg2CQR1Dj/wDNH6vf9xP/AAS3 /wAmtWmmuimuioba6mhjG6mGtEAa+SmkgABsAEyyTl80pSr942hZS5uZbeSNtldbAO8sdY4/9WEs zDx83HfjZLPUpsjc2SJghw1aQeQjJIoBIIINEOP/AM0fq9/3E/8ABLf/ACa0sPDx8LHZjYzPTprn a2SYklx1cSeSjJICIGwAXSyZJCpTlIeJJQvpc7MqvBG2uuxhHeXurcP+oKLzoU6SKxh6NP7jfuCk GhohoAHgE6SSkN9LrLcZ7SAKbC909wa7K9Pm9GSSSU4//NH6vf8AcT/wS3/yavYHTcLp1TqcOv0q 3O3ubuc73EAT7yfBWkkBEDYAL5ZckhUpykOxkShy6XX1NY0gEWVP18K7GWH8GoySSKxzMj6t9Fyb n3345fbYS57vUsEk/B6PgdJ6f07f9jq9L1Y3+5zp2zH03HxVxJOM5kUZEjtei0QiDYAvvSHNpdkY d9DCA62t7Gk8S5paJRkkk1c5uX9XOjZuQ/Jycf1LrI3u32NmAGjRrgOApYHQuldOuN+HR6VpaWF2 97vaSDEOcR2Wgkhwi7oL/dycPDxy4dq4jVeSkHCpdj4dFDyC6qtjHEcS1oaYRkkVjQz+h9L6ja27 Mo9Wxrdgdue32gkx7XDxUMT6udGw8hmTjY/p3VzsfveYkFp0LiOCtJJGymztakHEpdRU5jiCTZa/ TwssfYPwcjJIIUkkkkpSDRS6u3Je4gi6wPbHYCuuvX5sRkklNfNwMXPp9DLZ6lUh23c5uo/qEeKo f81Ogf8AcX/wSz/ya10k4TmBQkR5FaYROpAPmFgIEITKXNzLbyRtsrrYB3ljrHH/AKsIySauRZWL Rl0Px8hu+qzR7QS2YM8tIKzf+afQP+4v/gln/k1rpJwnKOkZEeRQYxO4B8wwpqroqZTUNtdbQxgk mABAEnVQZS5uZbeSNtldbAO8sdY4/wDVhGSTUsLa2W1uqsEseC1w4kEQeFm/81+hf9xB/nP/APJL VSThOUdiR5FBjE7gHzRYuLRiUNx8duypk7WyTEmTzPimfS52ZVeCNtddjCO8vdW4f9QUZJNJvUpU s7/m90Q/9o6/x/vWikiJEbEjyQQDuAUGJhYuFWasWsVMJ3FreJiJ/BPfS6y3Ge0gCmwvdPcGuyvT 5vRkkCSdTqkCtlKq/pXS7HufZh0Pe4kuc6phJJ5JJCtJIgkbGkEA7ocfDw8Xd9moro3xu9NjWTHE 7QEsul19TWNIBFlT9fCuxlh/BqMkgSTulSSSSSlIObS7Iw76GEB1tb2NJ4lzS0SjJJKUkkkkpSSS SSkOFS7Hw6KHkF1VbGOI4lrQ0wjJJJKUkkkkpDiUuoqcxxBJstfp4WWPsH4ORkkklKSSSSUhopdX bkvcQRdYHtjsBXXXr82IySSSlJJJJKQspc3MtvJG2yutgHeWOscf+rCMkkkpSSSSSkL6XOzKrwRt rrsYR3l7q3D/AKgoySSSlJJJJKQ30ustxntIApsL3T3Brsr0+b0ZJJJSkkkklIcul19TWNIBFlT9 fCuxlh/BqMkkkpSSSSSkObS7Iw76GEB1tb2NJ4lzS0SjJJJKUkkkkpSDhUux8Oih5BdVWxjiOJa0 NMIySSlJJJJKUkkkkpSSSSSlJJJJKUkkkkpSSSSSlJJJJKUkkkkpSSSSSlJJJJKUqXVesdN6Pi/a +o3topkMaTJc551DGNbLnOMcAK6ud+s9d+P1HpPWRjWZuL099wyaKW73s9ZjWtyG1z7vT2kaCYcY SUt/z66XG77J1H0/9J9iv2/H6C2OmdV6f1bFGX0+4X0klpIBaWuHLXtcA5rh4ELA/wDHO+pQf6Rz ni4O2Gk4+Rv3TG2PS5lH+rRtzOrdV6zXjWYeBmihlDLmmt9r6RYLLzU4At3BzWgnUwkp6NJJY/1s 6d1HqPRbaem5N2LlsLba3Y9hpe/YZdV6jfo7xpPikp2FWOfijqDeml/62+l2Q2uD/Nsc2tzt0R9J 40XNU/UX1amWf84frAze0O2PzYcJHBHp8hS6P9WMnpH1sbkjMz+o4r+n21uyM+71tlhupc2th2ti Q0lJT1iZzmtaXOIa1okk6AAJ1i/XLDys36sdQxsRrrLn1g+kzR1jGua+ypp11ewFvzSU2cD6x9A6 jecfA6jjZN4BPpVWtc6ByQAdVZyM/Fx8nFxLn7bs1z2Y7YJ3OrY61wkCBDWk6rLv+qf1cz8GljMJ mLsY04t9DfQvp0lpY9m17SPD71jg9fb9Zug9P6pS/JOHbk2N6rU39DbUca2tptj+btkgEcHskp7R RssrqYbLHBjG6uc4gAfElSVXqnTcbqvT8jp2Vu9DKYa7Nhh0HwKSlftTpn/cuj/txn96D0vrvTeq NccW1u5tttPpuc3eTS91bnNa1xlp2yPJcv8A83undDEdW6Jh9T6e3jqONiM9Zje32jGY0l3m+v8A zQrX1D6T0F2E7quJh43q/bMz7NlsraHCo3WsZseBO3YYHkkp65MSAJOgHJTqp1fFuzOlZuHj2Gq7 Jx7aqrRoWvexzWu0jglJTT6Z9bfq31XKtxOn9QqyL6ZL2NJGjeXNLgA8DxbIQ8D649B6hmMw8a5+ +4ubj2vqsZVcWfSFNrmhj+Ox1XMdROT1/pGH9W+ndIyMLNxmtFl99TqacUUt2vay1pG/1f5v2HVp JV3J67h9XPTeg9Oxb8fqONl4tuRjOpewYldDxZYX2bdkbWFjdp90pKe1SSSSU5tXXsCzor+uEurw K2WWl7gCTXUXDe0MLpDg2W+Sy6vrq5pot6j0jO6dg5L2MrzL2sLGmzRnrNY9zqwXECSOTqs3qfTu vYPQM76t19Od1Hp11d1fT8nFfWH1MfLq67qbXM/myYBaTIHYqx1DL+sn1j6Y7pDOi29PbmtFWZl5 dlYZWx0C01sY5znuidugSU9gkmaNrQOYEap0lOB1T68fVvpWZZhZeS716Gh2QKqrLRUHceo6trg1 atfU8K/p56li2tyMX0za2yohwc1okx5rP+r3TL+n5PWGX1DZlZr8qnIkE2Mua1212s/o3S0eUKh1 f6v5vThlZ/1ZrbOVW8ZvSZFdV5cCPVrPFdo+EO7pKeg6dm1dR6fi9QpDm1ZdNd9bXwHBtjQ8B0Ei YKsrO+ruNfifV/pmJkM9O/Hw6KrWGDteytrXN000IWikpyuo/Wr6u9LyTidQz6cbIADjXYYMHg8L My/8Y31VouxWU51F7Mi307ntfHpM2Pf6h9pkbmhvzWh1P6vtycv9pYGQ7B6mGhhuAD67Wt+jXfS7 RzRPIhw7FY+Zd1TJ6x0XDz+mOpvx802vyqG+piWVjHvbua/6TNXD2vA8p5SU9RgZ+H1HEZm4Nzcj Gtn07WatO0lhj4EEKwmAAEAQPAJ0lOb1n6x9E6Eyp/VstmKLztqDpc50RMNYHGBOp4CFnfWnomFR jXuvOQ3NBditxmOvfY0CXPa2oOO0dyqPWLz0j6yV9ZyMXIy8S3D+yMdjVOudRY2x1jiWMkgWhwEg fmiVi9Ky2fV/Ny/rH1jAt6f0/qoLsYCt9jsRrXEll1de70/Xn1DDdHSDqkp7XpvUsLqmGzNwbPVo skB0FpBadrmua6C0giCCrSwPqi6y+rqXUfTfTjdQzn34ldrSx3pBldW8sdBbvdW53wMrfSUguzMa i+jHtfF2U5zaGAE7ixpsd9EGAAOSs/q/1p6T0jJZh5Drbcyxnqtxsep91npg7d7m1tMCfFC+sONm 15fT+tYOOc23pzrWXYzSBY+jIa0WGrcQ0va5jTBPErDxvrV07H+sudnW42e2vNxcZjA7Dv3tsodd vr27O4sB00SU9V0jrPTus4xyun2+rWx7qrAWuY9ljfpMex4DmkeYV5c79WhlZfVeqdafiW9Pxc4U V0U3t2W2ei14dkPr/N3bw0TrDV0SSkeRkUY1D8jJsbTTUC6y15DWtaOS5x0Cq9O670bqpe3pudRl ur1e2mxr3AHuQDKzfrpgPzun4jDS7JxKs7HtzsZoLjZjh2142gEkNLg8jvEIvUvqj0nL234dbem9 RoE42ditFdjCPoh22A9ni12iSnTOfijqDeml/wCtvpdkNrg61sc2tzt0R9J40Vhch0i7rV/1yrb1 bDdTfh9MuptyqwTjXOffQ5j6n9twaZadQuvSUhy8vGwsazLy7BTj0jdZY7ho8Ssb/n79Tv8Ay2x/ 84/3LYzMPGzsW3Dy6xdj3tLLa3cOae2iw/sfWehCcVrut9Nb/wBp7C37bU3wqtdtbc0eDyHfyjwk pn0H679C63b9mpyam5j7bq6sYP3Oeypz9tg9o0exu9dAsD6l1n9k23PofQbs3Mtrbcw12BlmRY5k teARoVvpKYve2tjnvO1rQXOJ4AGpKwOn/Xfo2dYAa8nDpsDn42Vl0upova1vqF1NjtD7ROsGFr9U wW9R6ZmdPc4sbmUWUF45AtYWT8pXI5+B9ZvrF06j6uZfTW9Nx6g37XnvfXaxxoj0hj1tk+94BO4C GyElOxg/W+vKyMdtvTsvEw81+zCzrmtFVjjqyQHF7N4Ht3DVdAuPyMzrXWrcLo1vR8jBfjZWNfm5 btn2VrMd4u/QWB3v3urDQI0nVdgkpSzauvYFnRX9cJdXgVsstL3AEmuouG9oYXSHBst8lpLh+p9O 69g9Azvq3X053UenXV3V9PycV9YfUx8urruptcz+bJgFpMgdikp0qvrq5pot6j0jO6dg5L2MrzL2 sLGmzRnrNY9zqwXECSOTqumXH9Qy/rJ9Y+mO6QzotvT25rRVmZeXZWGVsdAtNbGOc57onboF17Rt aBzAjVJS6wOqfXj6t9KzLMLLyXevQ0OyBVVZaKg7j1HVtcGrfWL9XumX9PyesMvqGzKzX5VORIJs Zc1rtrtZ/Rulo8oSU6FfU8K/p56li2tyMX0za2yohwc1okx5p+nZtXUen4vUKQ5tWXTXfW18BwbY 0PAdBImCuf6v9X83pwys/wCrNbZyq3jN6TIrqvLgR6tZ4rtHwh3dbH1dxr8T6v8ATMTIZ6d+Ph0V WsMHa9lbWubppoQkp0VldR+tX1d6XknE6hn042QAHGuwwYPB4Wqsfqf1fbk5f7SwMh2D1MNDDcAH 12tb9Gu+l2jmieRDh2KSnPy/8Y31VouxWU51F7Mi307ntfHpM2Pf6h9pkbmhvzXQYGfh9RxGZuDc 3IxrZ9O1mrTtJYY+BBC5fMu6pk9Y6Lh5/THU34+abX5VDfUxLKxj3t3Nf9Jmrh7XgeU8rrwABAED wCSl1k9b+smH0e2jHfRlZuVkBzq8bCpdfZsYWh9jmtiGguC1lz3Vq+qdP643rXT8F3U2X4ow8iit 7GWM9N77a3t9XaCD6jg7XwSUyv8ArhhFmMOl49/VMjKa54xqGhr62VnY83eqWCva72w7WVpdI6rR 1XD+01Mspc1zqrqLhtsrsYYcx411C5bBq670HJy/rFmdMdl2dZh+bhYAZZdjOr9tLW/RNoLPpwfp agarb+q2Pmtqz8/NodiW9Ty3ZLcV5BfXWGV0Vh+0kbnCrcfCYSU7aqZPUaMfNxMFwc6/NNnphsaN qbve90kHaJA0nUhW1j9e6f1C63D6n0oVuz+nPeW03Hay2q1u22reA7YTDXAxyElMOq/WU4XUB0zC 6fk9TzRUL7WUBrWV1ucWtL7LHNbLoMDyVnonXMfrFd2yq3FycWz0srEyG7La3xubIBIIc0y0gwQu do6p13G69l9QP1dzYzseip9bX0O22Y7rdQ8W7S0ts/Ba31exOqv6hn9a6rQ3Ctzm01U4bXixzKqN 5abXt9pe51h44CSneVXqfU8HpOFbn9QuFGNSJfY6e+gAA1JPYBWli/WnpuRn42E7HrGQ7CzqMp+O SALGMJa9vuIEhrtwnuAkpbpP1y+r/V8o4eJkFuVtD20XVvpe5p7sFrW7vkr7uqUN6uzpBa717Md+ UH6bNlb2VEHWZmwdlDrHROn9ZxvQza9xad1NzfbbU8fRsqeNWuHiFh9IwPrHV9a2WdVY3IxsTp9u NV1NpA9cvupe31KuWvDWHdGhSU9Wg5eXjYWNZl5dgpx6Russdw0eJRkDMw8bOxbcPLrF2Pe0strd w5p7aJKcf/n79Tv/AC2x/wDOP9yboP136F1u37NTk1NzH23V1Ywfuc9lTn7bB7Ro9jd6h9j6z0IT itd1vprf+09hb9tqb4VWu2tuaPB5Dv5R4RPqXWf2Tbc+h9Buzcy2ttzDXYGWZFjmS14BGhSU76i9 7a2Oe87WtBc4ngAakqSq9UwW9R6ZmdPc4sbmUWUF45AtYWT8pSU5HT/rv0bOsANeTh02Bz8bKy6X U0Xta31C6mx2h9onWDCfB+t9eVkY7benZeJh5r9mFnXNaKrHHVkgOL2bwPbuGqx8/A+s31i6dR9X Mvprem49Qb9rz3vrtY40R6Qx62yfe8AncBDZCsZGZ1rrVuF0a3o+RgvxsrGvzct2z7K1mO8XfoLA 7373VhoEaTqkp7BJJJJTm1dewLOiv64S6vArZZaXuAJNdRcN7QwukODZb5LLq+urmmi3qPSM7p2D kvYyvMvawsabNGes1j3OrBcQJI5Oqzep9O69g9Azvq3X053UenXV3V9PycV9YfUx8urruptcz+bJ gFpMgdirHUMv6yfWPpjukM6Lb09ua0VZmXl2VhlbHQLTWxjnOe6J26BJT2CSZo2tA5gRqnSU4HVP rx9W+lZlmFl5LvXoaHZAqqstFQdx6jq2uDVq19Twr+nnqWLa3IxfTNrbKiHBzWiTHms/6vdMv6fk 9YZfUNmVmvyqciQTYy5rXbXaz+jdLR5QqHV/q/m9OGVn/Vmts5Vbxm9JkV1XlwI9Ws8V2j4Q7ukp 6Dp2bV1Hp+L1CkObVl0131tfAcG2NDwHQSJgqys76u41+J9X+mYmQz078fDoqtYYO17K2tc3TTQh aKSlJJJJKUkkkkpSSSSSlJJJJKUkkkkpSSSSSlJJJJKUkkkkpSSSSSlJJJJKUkkkkpSSSSSlJJJJ KUkkkkpSSSSSlJJJJKUkkkkpSZrWtENAaPAac6p0klKSSSSUpJJJJSkkkklPJN/xiY9jrBj9C61k MqsfU6ynED2bq3FjgHNt7EKj1/8Axg5TOjZb8Po3WcHJFZNWXkYYbVW7957nPcAPkuxxun42Lk5O RQCx2Y4WXtH0TYGhm+P3iAJ+CXU+nY3VMC/p+WCcfJbstDTtO0+BSU2kkkklPKO6t9cOoZedf0Sr C/Z/T8h2MynJ9T1sh9J23w9h2s1lrZHPkqlOZ9dOsYrvrL0zNpxcCHvw+k20td61VZcA6276TXWR IjjTzXV4XTacK/Ltpc/bm2+u+pxlrbC0NcWeG7aCfNDPSaauju6T09xwqfSdTS5nuNYcCJbvPInS UlJel59fUum4nUa2ljMumu9rXcgWND4PwlWkHDxacLEow6Btpx621Vt8GsAa38AjJKcnp+fk39e6 th3O21Ygxxj0+3VtlZe63jd7nkt1Me3TusXp+H9Y+vY9/VW9cu6e59+RXiYtVVRqqbTa+hosbY1x sJNe4691t9W+ruL1LIZmsuuweoVN9NmZiv2WbJ3bHghzHtns4GOyyqPqTmVMto/5wZ4xr7H221Ve jUS6w7rPeyuW7iZO2ElOv9W+p39U6PTlZTWtyQ6ynIFf0DbRY6mxzJ12lzJHktNVundPxOmYNOBh M9LGx2hlTJJgDxJ5JVlJTg9c+sGfidSx+kdHwR1HqF1ZyLGvsFVdVAOze98O+k7QCEulfWe27Lb0 zreE7pHU3yaa3uFlNwH+hvaA1zo128q9Z0qeu09Yqt2ObjvxciqJFjC4WVmZEFjpj4lE6r0nB6ti HEzWb6yQ5jmktex7dW2VvGrXNPBCSmv0TqeRn3dUZcGgYOc/Fq2AiWNqpsBdJOs2Faixvqx0TK6N Rm15eb+0LsvLfkuvLAx0FldYa4N03RXqVspKc/P6qcPqfTMH0t46lZbWbN0bPSpffMQZnZCzOtdW +sdnVf2N9W6MY30UtyMvKzi/0WNsc5tdbW1e8udsJniFZ+sfQs7qr8G/p3UP2Zl4Fj7Kr/Rbkfzl bqnDY9zW/RcVD6vdB6r03MzM7qnVf2rkZjKa9/2dmPtbQbSBFbiD/OnskpN0Hq2dlnIweq014/Vc HZ9oZS4uqe2wTXbUXe7a6CIOoIWus3D6bZT1rqHU7bGuOWyimqto+hXQHn3eLnPscfhC0klNHrHW umdEw/t3VLvs+MHBnqbXv9zuBFbXHt4LC/8AHS+on/ln/wCAZH/pFdB1TpuP1TBtwsmfTtGj2mHM c07mWMd2c1wBBVipr66WNtf6j2NAfZG3cQNXR2lJTzfRvrv03r31iHT+j3tycNmHZkXP9Oxjxa22 pjR+lDNNrz2XTqiemVv61X1j1DvrxX4orEbS2yyu0un/AK2rySnO+sPVj0bo+T1FtfrvpDRVSNN9 ljm1Vtnze4LFbl/4wOnNZmdQx8PqWNtnJxcEPZkM/wCK9V2yzb4aE9l0PVOnYvVOnZHT8sE4+TWa 7IMEA9wfEcrLd9c/qniRj39Yx321DY9xe1xLm6Eu2aSkphZ9YGZmf9X39LyA/B6jdkMvAAlwrx7b AxwcNzXNe3UaFdCuYwOlfVjqvXKfrF0fNa+zGc911GLY00vttrdV6ltY4ftdzoSunSUjvdYyix9T d9jWOLGeLgNB8yuS6V9ZPrd1Vr242L0xmTTAycO2+9l9JPa2s0SPI8HsV2K5f6w9T+pNt4rz+p04 nUsaRVk02huTS7ycyfm10g9wkprdBzvrnd1nqVV9WG+irMqbktN9rvSaaaXObjg1wRtO6DHuJ+K7 Fcx9Tbunvs6g+nrNHWMnLubfY6oNY8NbXXQ0vra7mGakACey6dJSlyOGz6z/AFlxm9Wo6v8AsrBy Wudh4uPQx79m6K33W3SZIEkNA5XXLher1YPR81+NR9bj0XGsc623pxFVrm+pqfRc+X1AmTGvlCSk vT+pfWbpnRaOu5+a3qmAGg9SpfU1l1O0+nc+mymA9rHCdrmzHeV2gIIkagrmMK36o9V6H/zX6V1K qyn0BjiuuxpuNYjfo7UkjkgLpwAAAOBwkpdcuHfWH6wZeU/B6kOk9Nw8i3EDaqW232vp9ljnPulr Bv4Ab2XULnuofVjqD8y3L6L1i7pP2p4sy6RXXfW9wG0uY236DnACSNPJJTmdOP1yxcTKzB1JvVXd PvuqyMG+pjDYyp0g03VbS17qyDDgRK63BzKM/Cx87HO6jKrZdUTodr2hzdPgVSwOj4/S+j24Lb3n eLbMjMtIL3WXFz7LnaBvJlWekUYmN0rDx8F4txKqK2Y9gIcHVtYAx24aGRrKSm2uZy7vrJ1Trmbi 9Iz6unY3SfSZY2ygXm+22sXEOl7Sxga9uo1mV0ywus/VqnPynZVXUcrpduQwUZBxbGsFrRO2Q9ro cJMObqkpy+nZXXvrW7Iuqz3dGp6e92I+vFFVxflV/wA89zrA79GD9AQCRqt76t9Rv6j0irIyYOSx 9tF7miGusosfQ57R2DiyVi9S6L03pLsWjpfXG/Vuy1jKBSTU4Xsr9rYZkH+c1jeNfGV0PSOm4/Su m0dPxi59VDY3vMve5xLnvee7nuJcfNJTcWSc/J/50jpznbMUYPrsZ7f0lht2O5G79G0Dgx7tey1l idfxug5uRi4udljC6kNz8C6u0U5DSdHekfzge7SCD3CSmg2jrfXeq9Uczq13TcXp2QMTHx8dlclz aq7XW2Osa/duNug8lo/VjOz8jHysPqVjb83pmQ7EuyWN2NthrLWWbB9Ellg3DxlZ9f1M6hVffdX9 Yc5n2stdeWtoDnOa0Vh24Vc7QBMLb6P0fC6NhDDww8sL3WWWWOL7LLHnc+yx7tXOcUlN5Yf1i6p1 XHyMDpfRWUnqHUXWFtmTuNVdNAa615DILj72gDzW4qeZ06nKycPJc91d+FYbKnMMSHNLHscDy1wK Snmbc/665mZ/zbFuN0/qLGHKv6pQw21/Zi4Mp9Om7h73bg6Tpt05Wr9Xc7q32rN6N1mxmTm4DarG 5lbBW26q8P2uNY0a4OrcCBp4K5nXdD6Zk/tXqF9OHdbW3GF99grDmNc6xrBvcAYLiUumYeL9qyur 0ZAy/wBpemWWsLSwVVN21src2ZbJc6fEpKdFYX1wyc+jp2Kzp+ScPIyc7FxvtDWteWtutFbjteCD yt1Z/Wen0Z1FByLvQrw8mnML9AP1d4tAcXaAGNUlOQ7rP1o6KQ3rPT/2nhjQ9Q6aCbBqADbiO93f UsceFsdJ690jrNRt6blMyA36bAYsYfB9boc0/EKg769fU9jtp6vjSPB4I+8SFd6eOg5156z037Nk XWMNLsyja5zmyHFjns8wNCkp0VT6xk5mJ0zJycDH+15VTC6nHE+9w/N0VxJJTyXTOvfW7qtByMCn pNzGnZY0ZF4ex45ZYx1Acxw7hwlL6nZv1syQ85zMZ+EMvMZbd61r7mltto2VtdXBY142tk/R+5bH U/q9i5twzcex/T+pNEMzsaBZA/Nsa4FljfJ4PlCj0LCHRMSvAzcuu7My8jIua4D0vUfa9+Q8V1lz j7QSeUlOuqvVM5vTum5fUHtL24dFl7mjkipheQPuVpRsrZbW6uwBzHgtc08EEQQkp4y/q31q+r/S m9f6vl4/Usa5rDZhV1No9B1wArFVxf72h5Adv7azorLmfWLov2Lqef1V2aMnIpozcI11ilv2l4qH oFoDh6bnDkmQjYv1M6WzKqGTnZPUcfDDhi9PybWvqq3N2TtDQ5xaw7W7yY+Ki36snEy8R/Uut3X9 Lxb6j0/AyBW0C4Etoa+6N9sOI2A6yBykp6hJJJJTxXRc367u6ceq49lHWKbLskfYLox7mim+ylra r2gtMhn57fmtfp/1y6TlZAwswWdK6gSR9kzm+k5xBI/RvPssGmm1y0Oi9Mr6V05mFVYbWNfbZvMA k3WvuI08C+FXuyfqv119nSbrsPqNjJ9TEL67XtLTDjskkFp+5JTrJJJJKcnpPVr8t3VzkNaG9OzL MerYCCa2VVW+6SfdLyufwz9fMzAr+stfU6GV31fa6uiGhpqNLm72VnJ0s3Fsaxz5K/m/UPGys3Ky 6ur9VwvtthtuoxMkVVF5a1hOwVnkNHK129Nqw+gjpVF7qasfF+zV5L9rnsYxnpiw6BsgCeISUn6d nVdR6fjZ9MirLqZcwHkNsaHCfvVlVOlUYeP0vDowXCzDqorZj2NO4OrawBjg7vLdZVtJSkkkklKS SSSUpJJJJSkkkklKSSSSUpJJJJSkkkklKSSSSUpJJJJSkkkklKSSSSUpJJJJSkkkklKSSSSUpJJJ JSkkkklKSSSSUpJJJJSkkkklKSSSSUpJJJJSkkkklKSSSSUpJJJJSkkkklKSSSSUpJJJJTzf1m6n 9acTqWBi9FZgijND2G7OFxaLm+5tc0HTc0GJHbnhA/8AXp/+aH/2cXUvrrsAFjQ8AhwDgDqNQdfB SSU8x9Rf2hs63+0/R+2/tSz1/s270t3oY30PU90fFdOosrrZuLGhu87nQAJce581JJTzX1tblZmf 0fozcq3Bw+oW3fab8d2yxxpr9WuhrwPbv9xn+TCE7pHWvq2XZnSMrJ6thA7sjpeW8227e5xbXahw 52Oncumux6L9hurbYaniyvcAdr28ObPBCIkp5b6s9TwuqfWbreZhWC2l+PgA9nNcPtO5j2nVrm9w V1Kr4/T8HGyMjJx8euq/LLXZNrGhrrC2Q0vI5iSrCSnB+uOa7BwcHI9c41beo4Yvt3+m0VG5vqb3 SPbt+lOkLM6q7ov1v67hdGGdXm9Krx78vLx8S8FtljH011NtdS7dA9QuAkarqsvCw86g4+bRXlUE gmq5jbGEjg7XghAwuh9F6fab8Dp+LiXFpYbKKa63FpIJbuY0GNElON0fp2P9XfrE3ovTN7emZeJZ lNxXvdYKbara2F1ZsLnAWC3UTyF06CMPGGW7NFY+1PrFLrvzvTaS5rPhLiUZJTi/XKjKyPqxn1Yr XWPcxvqV16vfSHtN9bAPzn1BzQq3TvrD9Q6sStmHm9PxKg0AUufXQ5o/ddXZtcD4yFvZGTj4tL8j KtZRRWJstscGMaPFznQAufy83/Fxm3G/Nv6Lk3EQbLn4tjo/rPJKSmo3N6LnfW3ptn1dfVffWLf2 pfibTX9mNbtjbns9pPq7dvfntK7Bc7j/AFj+r1PUOm9H6G/CvZmvsY5mHbVFTaqX3B3p0zodm3su iSU1OrV5lvSsyvAdszH0WtxnntaWOFZ4PDoXN/VnrP1HwekY2NXdidNuqra3Ix8osx722gQ8Wi3a 4unv3XWW2V01vtscGV1tLnuPAaBJK4rI+tH1b6n6ef1P6u33dNcSKuq5OHXbUGf6Q7tz2sMcwkpL 1fqP1fz+pdLb0G2jK6yzLqc2zDLHlmOHD7V6r69PT9OdD3iNV2aw7cvpPRcDCv6Ri4/2XPysfHZ9 mDK69uTYGeo302w6N0+a3ElKXE/VTqP1Z6XhOxer3Y2F11lth6k7L202W3F7nOtD7du5j+WkaQu2 XJZf1m+q/VQW5PScnqddL3MD3dPfkVh7CWO2u2OboZGiSmv9bOrfVfO6c6npeRjZvXHOb+yxhuZZ eMmf0bmurJ2gfnSYjldo2do3cxrHiuH6d9aeiYHV8jFweh34mMKKrWjG6dZXcbHusa82MYweyGt2 mPFdykpS47Iw/rrlfWDOxaevnp2MNt2Cz7FRe11TtHN9R+125jtCD2g/DsVzeR9bctubktxOkX5n S8B7qszqFVlftewA2CugnfZsmHbdZBEJKaOd9XvryMLIL/rX6rRU/dWOnY43DaZbIdIlb31WY+v6 sdIrsaWPZg4zXNcIIIqYCCCst/1q6rl+vmdC6dX1DpGKSHZJvDH3Fmtn2Zu1wcG8akSV0WJlUZuJ TmY7t9GRW22p3i14Dmn7ikpMuQyPq90vrv1q6pX16r7V6NFA6fS5z2tbRY0+q9m0t95tDgSONF16 oYnU2ZXVM/BZWB+zvSY+2dS+1nqlu3bwGlpmdZ8klPPdC+qHT8hmfb1/F+3XjIsxsezNbvc3Eo/Q 0bHP/ea3cXDkklaf1JdYfq3i73utra65mNY4yXY7bbG45J7/AKINVIfWH6zdQbk5HSej0ZXTarLa azfkCu3I9FxreWN2Oa0F7XAbit3o3UMXqXTMfNxGGqmxsClw2urc0lj63NHBY4FpCSm6uX6r0zp/ VPrnj4nUMevKx3dKyCa7GhwkZGPqPA+YXULE659YsTpObjYzMO7qHU8prvSoxWB1gqafc9znFoay fPlJTT/5t9d6Q42fVzqbn441/ZnUi6+r8321Xz6tY0P7w1Wx0fN6hmYrn9RwXdPya3mt1Re2xroA PqVvZy0zpOqrdE+tGB1e1+J6d2D1CobrMDLZ6V4bMb2tk7m+YVjpPVT1G3qFZq9L9n5bsSd27ftr qt38CP5yISU6C5X649UwekdV+r/Ueo2+hiUZGR6tu1z4341rG+1gc7Vzh2XVKnl9UoxM7BwbGuNn UX2V1ObG0Gqt1x3yR+azskp5XpV31Z+uf1mzs0BnVcTBxcerGZfW41sfa+91xFV7QNx2M921af1e x6MDr/WemYDBV0+luNc2hmjKr7m2eqxg4bLWsdtHjPdE659ZM/Ez29K6L0x/V+oemL76xY2iuqok taX22DbucQYb81a6B1ZnUq7xbiO6d1Gh4bnYj9pc17mhzXb2aPa5v0XJKdVc59eamv6VjPyK3X9N pzKLep0saXl2M0mfY0Eua2zY53kCujQMzOwsCn7RnZFWLTIb6tz21sk8Dc8gJKcij6x/UhtIbT1H ptdUQGC2lmnhsJH5FR6LkdMy/rdfkfV8sfgfZC3qV2PHoPyd7PQgt0dYGb5I7RPZFvv/AMWeRa67 Is6Hda/V9ljsRzieNXOklW+nfWPpGT1lnRekvxsigYlmS63FtY9rCyyusVllUgT6k8pKdxUutV9T s6VlM6TaKOoGs/ZbHAOAeNRIeHDXjUK6q3UeoYvTMG/PzH+nj4zDZa6J0HgByUlPK9O6V9ec/Cpy 2/Wt1XqtBdVZ03HD2O4cx3v5adFEdI+suJ9aOg29U6wesUC7JhoxK8cVk4to3l1RPMxqrtH19xN1 Tup9Ozuk4uQAas3LqDaNT7RY9rnbCe25a+d1b7L1HpeE2sWN6nZbX6m6NgrpffIEHdOyElOiqvVT ljpeYcGPtnoW/Zp49XYfT/6UK0oXWsopsuf9Cppe6OYaJKSnjOh/Ub6sZ3QsHPobdV1C2pt/7SbY 5uUL3j9I5ztxG4OkFpkIPWupdTxndL6J1xpflHquCcPPY2K8mtl7CS7bpXa0fSbweQtej699KupZ bj4XUrKbBurfXhXOa4HWWlrYIKD0v67U9Q6nk4V2BlhteVXViu+yWjYH11ndkFwIrIc86mPbBSU9 Wkkkkp8vb9duhdP+pmf0b7c6jrDft7GVNrt3B9l97mRY1m0GHDXdot/6w/Vv6v8ARvq1bm9Nw6cX N6dWyzCyq2BtxuaWioGwe95sdDSCTMq1R9dLbHHMs6XdX9X95YzrHqVuaQHGv1XUg721SPp+GvCE /wCtPUbaD1Z/Sq3/AFca8EZL7R63oh0fahSWbdg+kPdMapKerbO0btDGo806bnUJ0lPHZGH9dcr6 wZ2LT189OxhtuwWfYqL2uqdo5vqP2u3MdoQe0H4NnfV768jCyC/61+q0VP3Vjp2ONw2mWyHSJVr/ AJ5ZVWdnsyOlX2dNwcg4rs7F/TFrmsZYTZQ0bwIeNWytrpXW+k9ZxxkdMyq8qvvsPubImHsMOade CElIfqsx9f1Y6RXY0sezBxmua4QQRUwEEFaiSSSlJJJJKUkkkkpSSSSSlJJJJKUkkkkpSSSSSlJJ JJKUkkkkpSSSSSlJJJJKUkkkkpSSSSSlJJJJKUkkkkpSSSSSlJJJJKUkkkkpSSSSSlJJJJKUkkkk pSSSSSlJJJJKUkkkkpSSSSSlJJJJKUkkkkpSSSSSlJJJJKUkkkkpSSSSSlJJJJKUkkkkpSSSSSmt 1Lp+L1PAv6flt34+Sw12N40PceY7LK6d9Tug0YVNOb0vp+RkVtDH3jFpG/boHkemIJGp81vJJKcF 31S6XT1fpvUem4mLgnBfa670aWVusbZS+kNmto4L51W8kkkpr9Qw68/AycG3+by6bKHxztsaWH8C g9GxsrG6RiYedsfkUUsptNf0HFg2bgIbG4CYhXkklPI9R+qGdVmYg6LbXX0s5+Pm5mDbO2s02C1z 8Ut+jvjVh0niF1ySSSlLFy/q4GZL+odFvPTM+zW3aN2Pcf8Ah8eQ0n+W2Hea2kklPOdEp63Z9Ys7 P6rhtxJxMfHa6uwW1WOrsve51Z9r4h4+k0Lo0kklKXK5HSfrZiWZuH0SzErweoXPvGVcXm7Hde7d ftrALX+4lzNRqV1SSSnkB07609Cwj0PoWLTndPe1zMTKyLyx2MHgki5ha42NDySNvbRdJ0rAZ03p eJ05ji9uHTXQHnk+m0Mn5wraSSlLC6j0vrNHU39W6FbSbMhjK8vBytwqt9OdljLK5LHgOg+0giOI W6uZ6v8AWfr2J1x3SOmdC/aLm0tyG2nLrx9zCdri1trNdrtDB8PEJKanS6Pr5gYtuBj4OBUx111t V1mQ97axfY64jYyppdtc8xwuh6D0o9I6VTgvtORa0vsvvI277bXutsft7S5x0WJ/zi+vf/zo/wDw yx//ACKufUbJy8v6s4+RmFxyH25XqB7/AFHNIybm7N/faBtCSnfWVZ0q8fWarrNJaa34jsPKY76U Nf61LmaHglwI058lqrnOtP63n9fp6N03NPS6KsX7Zk5La22PsLnmplTPUBaNu2XfJJTo9a6Hi9Xq r3udj5eO71MTNqgW0vHdpPIPdp0IVT6p9M6v0+nqDusOpflZma/J348hhaa6qgdrtWk+nMLFpwPr F17NyekdS6vfi19E9OuzJ6eRj2ZN1rfWbY+N20Nrcz2jTdPktz6rZWdZTm4Gfb9pv6XlOxftRABt Zsrure8DQO22Qfgkp21g/WbpnXMvI6bm9DdijL6dbZZtzTZ6ZFtT6T/Mgu4f5LeWJ1nMsxeudEFl 3o4N1l9dh3Fodea/0DHQYII3mHdwO6SkX1d6d9ZKep5/UuvnCN2XVj01NwTbtAoNxO71hOvq+Kt4 PT8mvr/U+pXBrKsmvGoxwDJc2kWOc93hLrYA8B5rKzemft3605eHn5OTXh4OJjvx8ai51LXuvfdv tf6Za5xb6QA1Vj6tG3D6p1Xof2qzOxcH0baLb3+pZV64eXY77OXbNm5s6w5JT0SzfrB0XG650u3p +RA3w+p5aHBljDuY/a6QYPIOhGi0li/WrN6lj4WNj9LeKMzqGVXiV5Tm720h4c51hadDAZAnuQkp lT9U/q36TPW6N071do9TZjVbd0axLOFDE+q+BgfWBnVen4+Ph0jEsxrKaKm1Fz32V2B52ADQVwsX Mx/rVTnY31cs6w+6rq3qWDqLa2U5NNWO0etWw1+2Xueza6JGvkr3Rac/onXW9Ctzr+p4eTiPyse3 LdvvrfVYyt7C+Bua4WgjwhJT06zPrH0l3WOiZXTq3iu21rXUvcJaLa3NtrLhrI3tErTWP9br8nH+ rubfjPdU6trXWWMLmubSHt9dzXM9wcKtxBCSnT9P18b08utjvUYBdV9Jkke5vuGoXMUfVTqWD17p bsO9tnQcCy+5lFxJuoNtNlIqqd+dXL9AdWqz9ZXO6g7ouDj5VlGB1PJLb8jFs2OexlFt7K22N1Ae 5msFV6sFv1c+sXTMXAy8i3G6p6tV+BkXOvDfSrdc3Ir9Quc2CNjux3BJT1aYgEEESDoQU6rdTyzg 9Ny81rDacWmy4Vt1LjW0v2j4wkpy7fq9fgWPyvq5cMN7yX2dPsl2HaeTDBrS4/vV/NpTfVijqgye r5nUsT7FZmZTHsq3tsBDKKai5rmctLmGJAPksvp/T/rvfgY3WKuu13ZOQwZBwX0s+yObY3e2ptjP eAAfpiVLqH1lfm4uHSBZ0/qmP1TBpz8LcQ9ofc1phzY31WDg8EJKewSSSSU8d/zd+s/2IfVptuLX 0CTU7KBeco4ZJPobCNocW+zfu415TZnTPrbbgO+qzceizpljBj/td10PbjSG7XUFpcbRXpMwTqhM 6j9bR1F+B1DqlHSr32OGI27D31Wsk7PSyBc1jn7eWGHeXdRx8D63H615tbesY4yRg4zrLfsctcw2 ZGxoZ62had2s90lPcAAAAcDQJ0kklOT0Lp2Tg3dWfeABm578mmDP6N1VNYnwMsKF1P6odG6hecxt bsHqPLc/Dd6N88e5zNH8fnArOq6dlfWbMzcjN6jmYmLh5duJRgYln2cFtXs9S5zPe4v+kNQIhUul dH6njYWbldK6vlWZfTsnIqFWTab8a9tLy5tb22SWHadhcwiCkp7TGqspxqqbLXX2Vsax9z4DnuaI L3bYEu50RVV6Xn19S6ZidQraWMy6a72tdyBY0Pg/CVaSUpJJJJSkkkklKSSSSUpJJJJSkkkklKSS SSUpJJJJSkkkklKSSSSUpJJJJSkkkklKSSSSUpJJJJSkkkklKSSSSUpJJJJSkkkklKSSSSUpJJJJ SkkkklKSSSSUpJJJJSkkkklKSSSSUpJJJJSkkkklKSSSSUpJJJJSkkkklKSSSSUpJJJJSkkkklKS SSSUpJJJJSkkkklKSSSSUpJJJJSkkkklKSSSSUpJJJJSkkkklKQrMXHtvqyHsBuo3elZ3buEOHwK KkkpSDiYmNhUDHxaxVS0ucGN4l7jY8/NziUZJJSlXswMWzNpz3M/WqGPrrsBIOyyC5pjkS0HVWEk lI2UUssstZW1tlxBteAA5xaNrdx7wNEHA6dj9Prsro3H1rX32vedznWWHc4k/gPAK0kkpSr52Bhd QxX4mdSzJx7I31WAOaYMjQ+BVhJJTzR/xf8AQRaLWWZtZDdgDcy/6EzskvLo8pWx0no3TOjYxxun UCitzi98Euc955e97iXOPmSrqSSlKvnYGLn0ehlM31h7LG6kEPrcHsc1zYIIcJVhY/1s6d1HqPRb aem5N2LlsLba3Y9hpe/YZdV6jfo7xpPikp1HUUvtZc+trrag4V2EAuaHRu2ntMaqiB01n1hMvcep 34ktYZLRj1WAO26bRL7BPc/JYdP1F9Wpln/OH6wM3tDtj82HCRwR6fIUuj/VjJ6R9bG5IzM/qOK/ p9tbsjPu9bZYbqXNrYdrYkNJSU9YovLAxxeQGAHcXcR3mVJYv1yw8rN+rHUMbEa6y59YPpM0dYxr mvsqaddXsBb80lOJR0L/ABe9XyTR0vNa20O9VuNgZjmNDm/n10sftHxaFr4PRvq50HqNHpteepdR 3005F77L7XBjDc5nqWF20bWE9lK/6p/VzPwaWMwmYuxjTi30N9C+nSWlj2bXtI8PvWOD19v1m6D0 /qlL8k4duTY3qtTf0NtRxra2m2P5u2SARweySntFC01ip5tgVhp3l3G2NZ8oU1W6ixz+n5TGAue6 mwNaNSSWmAElIcQ9K6b0et+PayvpdFIfVaX7qxTG5pDyT7Y414WFj9T+of1y6njPouZldR6Y9uRj EtspsGw7ht3tZvaCJI1WIzqd/Ufq/wBG+rV3QeqsNb+nU5ll+IW45ZRZT62524+yGHlvxXU/WmgO HSjj1zmM6hjDHexsljN36fUD2s9HfPb5wkp3kkkklPN9W+tP1Ytff0m+uzquw+nk4+PjvymtdwWv LGubuB7TIWf9W836t4XV7BXkZ9ORmsrxsajqddrAG1F721VW3sk6vMBzyfBR6P8AWPpn1R6ZX0n6 wtuwL8ex7DlOpssqySXOcL22VNsk2DUg6gpus/WnpH1p6Tf0n6vtt6ll5JFdNrabWVU2SHNufbYx oZ6f0p58ElPbpJmghoBMkDUp0lPEfWdv1T/a7wczqGP1V2x2ZT0d1pe8NHs+0Mpa9olp5MOhWenf WD6q4OC3o4qzOmY1m6sWZdF9Qc60nc519jfpOLuXHlQx+s4f1TyuqM67VdRTlZlmVV1MVPtqtruI LGOfUHlrqvoQ7sBCfL+vn1Y6vhZOD0xt3WbrqzX9kqxriHF4LQHmytrWjzKSnqsTGoxMWnFxmhlF FbaqmjgMYA1o+4Iyo9DxcnD6NgYmY/1MnHx6qr3yXS9jA1x3HU6jlXklKSSSSUpJJJJSkkkklKSS SSUpJJJJSkkkklKSSSSUpJJJJSkkkklKSSSSUpJJJJSkkkklKSSSSUpJJJJSkkkklKSSSSUpJJJJ SkkkklKSSSSUpJJJJSkkkklKSSSSUpJJJJSkkkklKSSSSUpJJJJSkkkklKSSSSUpJJJJSkkkklKS SSSUpJJJJSkkkklKSSSSUpJJJJSkkkklKSSSSUpJJJJSkkkklKSSSSUpJJJJSkkkklKSSSSUpJJJ JSkkkklKSSSSUpJJJJSkkkklKSSSSUpJJJJSkkkklKSSSSUpJJJJSkkkklPLW/4zvqPVY+qzqUPr cWuHoZBggweKlR6x/jW+q9XTMmzpOc2/qDWE41VlF4a5/YGa2D8V1XT+l1dPuynY7iKMu31/Q/NZ Y4fpCzwDz7iPGT3Tdb6XX1jpWV0y15qZlsNbrGgEgHuJSU3kkkklPL3/AFo69kZ2bT0Ho7eoYvTr DRdfZkNo33M/nK6gWunbwSe6vYP1lx+oYOW+pj8bqGFW52Rg5Ddttbg0kbm/nMMaOboVa6X0r9m3 57q7d1GdkHKZURHpvsaBaAZ4c4buOSVW+sP1br6uz18a44PVK2OrozqxJDXiHV2NOj2O8D8Qkpt9 DzbeodF6fn3houy8Wm+wMBDQ6ytr3bQSdJKvKn0jBPTek4XTy/1Dh49WObAI3ekxrN0axMK4kpSS SSSlJJJJKUkkkkpSSSSSlJJJJKUkkkkpSSSSSlJJJJKUkkkkpSSSSSlJJJJKUkkkkpSSSSSlJJJJ KUkkkkpSSSSSlJJJJKUkkkkpSSSSSlJJJJKUkkkkpSSSSSlJJJJKUkkkkpSSSSSlJJJJKUkkkkpS SSSSlJJJJKUkkkkpSSSSSlJJJJKUkkkkpSSSSSlJJJJKUkkkkpSSSSSlJJJJKUkkkkpSSSSSlJJJ JKUkkkkpSSSSSlJJJJKUkkkkpSSSSSlJJJJKUkkkkpSSSSSlJJJJKUkkkkpSSSSSlJJJJKUkkkkp SSSSSlJJJJKUkkkkpSSSSSlJJJJKUkkkkpSSSSSlJJJJKUkkkkpSSSSSlJJJJKUkkkkpSSSSSlJJ JJKUkkkkpSSSSSlJJJJKUkkkkpSSSSSlJJJJKUkkkkpSSSSSlJJJJKUkkkkpSSSSSlJJJJKUkkkk pSSSSSlJJJJKUkkkkpSSSSSlJJJJKUuE+rn176pnfWWzpnUqqGYV2Tl4mDZU14f6uJseWv3OcNa3 j5ru15PRiXu+rHWuq4k/a+ifWHI6hVBiRUKvUafLYSfkkp3frz9eur9CznU9Koouowq6rOoPuBJB vftqrZteIJDSdQuo6t9ZOi9HeyvqGT6dtgLm1MY+2zaOXbKWvcG+cQvNut4+Rk/4vM7r2TWRm9fz q8kt0Lm0h/p49UgCQ1vHxWp1R9/TPr31TJz+r2dEx86ij7HlejXbW9rGhr6d19b2tIcCYHKSnub+ vdHo6YOrW5dYwHgFl7TuDt2gDA2S4nwAlAb9augO6bZ1T7WG4lL/AErHPY9jxZpFfpPaLNxkQNsn suVf0r6r0/U3Crf1S2rCrzTk4HVPSLBXkBz3NdsDAwMndEgNOkdlXbns639Xnu+suf6DMDqLf2X1 6ilzGWPqZNd7mFu2DqJ0bOgSU9kz61fV93TbOqHMbXh0P9K2y1r6y1+h2Orsa14JBECNU/RvrR0D rtdlnS8xmQKRNohzHNHi5tjWujTmFx1f1v8ArDX9XbMu30cttPUWYtfWjQ4VfZyNcw0+3dt/kwNf JVPtDM/61dbsZceq12/Vy9otYz7O20b2tIrdBBHbcJ/BJT2lX14+qt17aK+oML7HBlRLXhtjidsV PLQ1+untJRupfWz6v9LyvsmbmCu8AOe1rH2bAYh1rq2uFY15eQuI+qubj5F31b/avUm1NwKg3p2P 9kuo9S22ptQY7Jtlj4BIGyNyEzbgdV+seD1vrb+jjOyrbPTsoqtryce0e0tsvqeTDTt2g6JKfUa7 GWMbZW4PY8BzHNMgg6ggrjPq99YvrT9ZA/qWA/Aowq8n0ndPtbY7IFTXDebHtfDbC2S0bYXR/V7G x8LoGDj4tj78eqhgpssaWPcyJbLHAEGOy84+sGV9WsrNZm/Uz7Tj/Wx1zC7Foqup3bnA2DIa5rWA fvawe6Snuv2s7H+sufTl9UoGHjYTck4HpFtlTGkb73XHRw5kDjTQd7XTfrT9Xuq5BxunZ9OTeGl5 rYZO0cn8VzFmXXgf4yerdQygTRi9DNtxaCdGvrcQPjtKy/q11Pp3X6OuZFOS131r6xi3tox2Mtb9 moazZXSy1zA3mCS06lJT3GP9b/q5lZ46fRmtfkOca2e14re8csZcW+m53k10q31rqLeldIzOpOG4 YlL7Q3xLWkhvzK826I3ped0vpHSuodetqyMS6nZ0c4tbbasit2jQW0+rydXTxyu2+v1Nl31N6syt xa4Y5eS2J2sIe4a9iGwUlOTlfWLrXRv8W+N111rczqVtdFzrMhvtP2hzXRtr9P6LXQFbx+u/WPB+ s2F0LrLcXKZ1Kux9N+G2xjqzUC53qsse/wBp7ELL+vWQzL/xWVZNc7LqcN7QeQHGswYVDp9nSLfr R0vI+olmTkbrDX1i237Q+j7MNpIe7KE74nZHdJT32L17pGXiZWZRktdj4L7K8uwgt9N1OtgeHgEb Vh9Q/wAY3Q8PqXS8ZtrH4nUa3XW5b3Or9GvZvpcWOZJ9TjsuZ+ttWd0vrvUPq/gMc2j64mh1NjQC 2u42CvK9o7OZJcfP7tX63v6f9X/rB9U83Jb6HScBuTQ+0Mc5jAaWsqaQxrj20CSnqOpfWjoXS/S+ 25Qa69nqVVsZZa8sid+ylj3BvmRCpfWrqmT/AM07+s9AymF9DW5VVrYdXZWxwNjT5Fk/7Fy+fe/A +u/Uc3L6vZ0XE6lj47sHL9BlldlbWAOq3X1vDCHCdojzWmMbpvT/APFn1NnT8p2XhPx8t1V72elJ s3j2s2tAbuPtgR4JKev6fmU5+Dj51BmrKqZdWf5NjQ4c/FWFkfVGqyn6rdJqtBbY3Do3NcIIOxpg g+C10lKSSSSUpJJJJSkkkklKSSSSUpJJJJSkkkklKSSSSUpJJJJSkkkklKSSSSUpJJJJSkkkklKS SSSUpJJJJSkkkklKSSSSUpJJJJSkkkklKSSSSUpJJJJSkkkklKSSSSUpJJJJSkkkklKSSSSUpJJJ JSkkkklKSSSSUpJJJJSkkkklKSSSSUpJJJJSkkkklKSSSSUpJJJJSkkkklKSSSSUpJJJJSkkkklK SSSSUpJJJJSkkkklKSSSSUpJJJJSkkkklKSSSSUpJJJJSkxa1whwBHgU6SSliARBEjwS2tjbAjiO ydJJS0CNsacR2hVeq9Mx+qdMyOm5Bc2jKrdU81mHAOES3QjT4K2kkp5hn1Jda/Bb1PqmT1DE6ZYy 7ExXspraH1DbWXuqra9+0ea6YtaYJAMcSnSSUpNtbO6BJ5PdOkkpSSSSSltrZ3QJ8e6jdVXfS+m1 ofXa0se08FrhBH3KaSSnP6F0hnRelUdLrusyKsYFtdlsb9skhp2gD2zAWgkkkpycr6vU5f1iw+u3 3Pc7p9T68bGgbGvskPtnkktMeC1SARBEhOkkpYta4Q4AjwKzuv8AQ8fr3TXdMynvZjWPrfc1mhe2 tws2T2BLRwtJJJSzQGgNaIAEAeSdJJJSkkkklKSSSSUpJJJJSkkkklKSSSSUpJJJJSkkkklKSSSS UpJJJJSkkkklKSSSSUpJJJJSkkkklKSSSSUpJJJJSkkkklKSSSSUpJJJJSkkkklKSSSSUpJJJJSk kkklKSSSSUpJJJJSkkkklKSSSSUpJJJJSkkkklKSSSSUpJJJJSkkkklKSSSSUpJJJJSkkkklKSSS SUpJJJJSkkkklKSSSSUpJJJJSkkkklKSSSSUpJJJJSkkkklKSSSSUpJJJJSkkkklKSSSSUpJJJJS kkkklKSSSSUpJJJJSkkkklKSSSSUpJJJJSkkkklKSSSSUpJJJJSkkkklKSSSSUpJJJJSkkkklKSS SSUpJJJJSkkkklKSSSSUpJJJJSkkkklKSSSSUpJJJJSkkkklKSSSSUpJJJJSkkkklKSSSSUpJJJJ SkkkklKSSSSUpJJJJSkl8qpJKfqpJfKqSSn6qSXyqkkp+qkl8qpJKfqpJfKqSSn6qSXyqkkp+qkl 8qpJKfqpJfKqSSn6qSXyqkkp+qkl8qpJKfqpJfKqSSn6qSXyqkkp+qkl8qpJKfqpJfKqSSn6qSXy qkkp+qkl8qpJKfqpJfKqSSn6qSXyqkkp+qkl8qpJKfqpJfKqSSn6qSXyqkkp+qkl8qpJKfqpJfKq SSn6qSXyqkkp+qkl8qpJKfqpJfKqSSn6qSXyqkkp+qkl8qpJKfqpJfKqSSn6qSXyqkkp+qkl8qpJ KfqpJfKqSSn6qSXyqkkp+qkl8qpJKfqpJfKqSSn6qSXyqkkp+qkl8qpJKfqpJfKqSSn6qSXyqkkp +qkl8qpJKfqpJfKqSSn6qSXyqkkp+qkl8qpJKfqpJfKqSSn6qSXyqkkp+qkl8qpJKfqpJfKqSSn6 qSXyqkkp+qkl8qpJKfqpJfKqSSn6qSXyqkkp+qkl8qpJKfqpJfKqSSn6qSXyqkkp+qkl8qpJKfqp JfKqSSn6qSXyqkkp+qkl8qpJKf/ZCg1lbmRzdHJlYW0NZW5kb2JqDTE5IDAgb2JqDTw8IC9GaWx0 ZXIgL0ZsYXRlRGVjb2RlIC9MZW5ndGggMTANPj4Nc3RyZWFtCnicK+QCAADuAHwNZW5kc3RyZWFt DWVuZG9iag0yMCAwIG9iag08PCAvU0EgdHJ1ZSAvVHlwZSAvRXh0R1N0YXRlIC9TTSAwLjAyDT4+ DWVuZG9iag0yMSAwIG9iag08PCAvQ3JvcEJveA1bIDAgMCA2MTIgNzkyDV0gL0JsZWVkQm94DVsg MCAwIDYxMiA3OTINXSAvTWVkaWFCb3gNWyAwIDAgNjEyIDc5Mg1dIC9Sb3RhdGUgMCAvVHJpbUJv eA1bIDAgMCA2MTIgNzkyDV0gL1RodW1iIDMzIDAgUiAvUmVzb3VyY2VzDTw8IC9Qcm9jU2V0DVsg L1BERiAvVGV4dCAvSW1hZ2VCIC9JbWFnZUMgL0ltYWdlSQ1dIC9FeHRHU3RhdGUNPDwgL0dTMyA0 MiAwIFIgL0dTNSA0NyAwIFINPj4gL0ZvbnQNPDwgL0YxIDY3IDAgUiAvRjIgNzIgMCBSIC9GNCA1 NyAwIFIgL0Y1IDYyIDAgUiAvWGkxNiAxMTcgMCBSDT4+IC9Db2xvclNwYWNlDTw8IC9DczYgMTI0 IDAgUg0+PiAvWE9iamVjdA08PCAvWGk2IDEyMyAwIFIgL0ltMjAgMTggMCBSIC9JbTE3IDggMCBS IC9JbTE5IDIzIDAgUiAvSW0xOCAxMyAwIFINPj4NPj4gL0FydEJveA1bIDAgMCA2MTIgNzkyDV0g L1BhcmVudCAzNyAwIFIgL0NvbnRlbnRzDVsgMTkgMCBSIDI4IDAgUiAxNCAwIFINXSAvVHlwZSAv UGFnZQ0+Pg1lbmRvYmoNMjIgMCBvYmoNPDwgL0ZvbnRGaWxlMyA3IDAgUiAvQ2hhclNldCAoL3Nw YWNlL1ovaC9pL0wvY29tbWEvWS91L2UvYi9uL0IvYS9IL3kvby9nL00vVC9kL3YvbC9wL20vdC9m L2h5cGhlbi9jL3Ivcy9wYXJlbmxlZnQvVi9wYXJlbnJpZ2h0L3BlcmlvZC96L1gvYnJhY2tldGxl ZnQvZml2ZS9icmFja2V0cmlnaHQvSy90d28vdy9uaW5lL0MvUC9VL2svQS9vbmUvdGhyZWUvTy9T L0QvSS94L2ZvdXIvVy9zaXgvc2V2ZW4vY29sb24vemVyby9zZW1pY29sb24vRS9HL04vUi9zbGFz aC9xL2VpZ2h0L0YvcXVvdGVyaWdodC9xdW90ZWRibGxlZnQvcXVvdGVkYmxyaWdodC9nMjk5L2Vx dWFsL2FzdGVyaXNrL3BsdXMvZW5kYXNoL2ovZ3JlYXRlci9icmFjZWxlZnQvdW5kZXJzY29yZS9i cmFjZXJpZ2h0L2Jhci9lbGxpcHNpcy9hbXBlcnNhbmQvSi9RKSAvQ2FwSGVpZ2h0IDY2MiAvQXNj ZW50IDY5NCAvRmxhZ3MgNCAvSXRhbGljQW5nbGUgMCAvRGVzY2VudCAtMjE1IC9YSGVpZ2h0IDQ0 NyAvRm9udE5hbWUgL0JOTElERytUaW1lc05ld1JvbWFuUFNNVCAvRm9udEJCb3gNWyAtNTY4IC0z MDcgMjAwMCAxMDA3DV0gL1R5cGUgL0ZvbnREZXNjcmlwdG9yIC9TdGVtViAwDT4+DWVuZG9iag0y MyAwIG9iag08PCAvSGVpZ2h0IDM0NyAvQml0c1BlckNvbXBvbmVudCA4IC9TdWJ0eXBlIC9JbWFn ZSAvTGVuZ3RoIDMzNTQ4IC9JbnRlbnQgL1JlbGF0aXZlQ29sb3JpbWV0cmljIC9XaWR0aCA1ODYg L1R5cGUgL1hPYmplY3QgL0ZpbHRlciAvRENURGVjb2RlIC9Db2xvclNwYWNlIDEyNCAwIFINPj4N c3RyZWFtCv/Y/+4ADkFkb2JlAGSAAAAAAf/bAIQADAgICAkIDAkJDBELCgsRFQ8MDA8VGBMTFRMT GBcSFBQUFBIXFxscHhwbFyQkJyckJDUzMzM1Ozs7Ozs7Ozs7OwENCwsNDg0QDg4QFA4PDhQUEBER EBQdFBQVFBQdJRoXFxcXGiUgIx4eHiMgKCglJSgoMjIwMjI7Ozs7Ozs7Ozs7/8AAEQgBWwJKAwEi AAIRAQMRAf/EAT8AAAEFAQEBAQEBAAAAAAAAAAMAAQIEBQYHCAkKCwEAAQUBAQEBAQEAAAAAAAAA AQACAwQFBgcICQoLEAABBAEDAgQCBQcGCAUDDDMBAAIRAwQhEjEFQVFhEyJxgTIGFJGhsUIjJBVS wWIzNHKC0UMHJZJT8OHxY3M1FqKygyZEk1RkRcKjdDYX0lXiZfKzhMPTdePzRieUpIW0lcTU5PSl tcXV5fVWZnaGlqa2xtbm9jdHV2d3h5ent8fX5/cRAAICAQIEBAMEBQYHBwYFNQEAAhEDITESBEFR YXEiEwUygZEUobFCI8FS0fAzJGLhcoKSQ1MVY3M08SUGFqKygwcmNcLSRJNUoxdkRVU2dGXi8rOE w9N14/NGlKSFtJXE1OT0pbXF1eX1VmZ2hpamtsbW5vYnN0dXZ3eHl6e3x//aAAwDAQACEQMRAD8A 9VSSSSUpJJJJSkkkklKSSSSUpJRssZW0OedoJa0HzcQ1o+ZKkkpSSSSSlJJJJKUkkkkpSSSSSlJJ JJKUkkkkpSSSSSlJJJJKUkkkkpSSSSSlJJJJKUkkkkpSSSSSlJJJJKUkkkkpSSSSSlJJJJKUkkkk pSSSSSlJJJJKUkkkkpSSSSSlJJJJKUkkkkpSSSSSlJJJJKUkkkkpSSSSSlJJJJKUkkkkpSSSSSlJ JJJKUkkkkpSSSYzGnPZJTg129UxOv4eDZnuzxlVXW5dLqqmMpa3b6dlXpsD2tLzsAe90+OhVZnXs +36wVPbZt6NZVl+lVtbNn2T0g6/dBdBc9waAYIE91Z6T0Dq2FffZl52PmfbHE5lpxbK8ixsEMYLf tbmsawGGgMgfEkpq/qZ0yjPwcrGsyK6MCuypmK7JybGEP2Bob6l5DWtDNWxDu/CGunkftN/knSz5 tTB6l1kU9F6tfmG+nrNjG3YTq6211NyGOtq9FzGNslkAHe506rq1g4P1ayKDg0ZOaL+n9Kdvwcdt Rrslocyr17fVcLPTY6BtY3XUreTjWtdzX93oCjX8NfNzep5+CKxUcmoWMvo3ML27hturLpE9gNVY /avS/wDuZR/26z+9LqX9HZ/x+P8A+f61aQU1f2r0v/uZR/26z+9L9q9L/wC5lH/brP71aSSUwqtq uYLKXtsrdw9hDgY00IU0kklKSQ35FNdtdL3htt0+mw8u2iXR8ERJSkkLJycfEx35OS8VU1Dc97uA ELB6ji57Xux/UBrMPZdVZRYJ4JrvYx8HsYhJTaSSVfJzasa7GpeHF2U91dZaJALWPtO7XwYeElNh JVqOoYt9worc4XGpt/pvY+twreS1pc2xrSDLTodUPE6xgZmTZjY73usq3AuNdja3bHbH+na9gZZt dodrjCX8vs3U3UlXyc2rGtxarA4uzLTTWWxAcK7LpdJGkVlWElKSQM7MqwcO/MtDnV47HWPDYLiG iTEkIwMiUlLpKph9Tx8sxW2wHffXLmHbOPYaXy9ssEuHtBMkduVbSV+xSrP6l05jix+VS17SQ5ps aCCOQRKspJKav7V6X/3Mo/7dZ/el+1el/wDcyj/t1n96tJJKav7V6X/3Mo/7dZ/el+1el/8Acyj/ ALdZ/erSSSmr+1el/wDcyj/t1n96X7V6X/3Mo/7dZ/erSSSmr+1el/8Acyj/ALdZ/el+1el/9zKP +3Wf3q0kkpq/tXpf/cyj/t1n96X7V6X/ANzKP+3Wf3q0kkpq/tXpf/cyj/t1n96X7V6X/wBzKP8A t1n96tJJKav7V6X/ANzKP+3Wf3pftXpf/cyj/t1n96tJJKav7V6X/wBzKP8At1n96X7V6X/3Mo/7 dZ/erSSSmr+1el/9zKP+3Wf3pftXpf8A3Mo/7dZ/erSSSmr+1el/9zKP+3Wf3pftXpf/AHMo/wC3 Wf3q0kkpq/tXpf8A3Mo/7dZ/el+1el/9zKP+3Wf3q0kkpq/tXpf/AHMo/wC3Wf3pftXpf/cyj/t1 n96tJJKav7V6X/3Mo/7dZ/el+1el/wDcyj/t1n96tJJKav7V6X/3Mo/7dZ/el+1el/8Acyj/ALdZ /erSSSmr+1el/wDcyj/t1n96X7V6X/3Mo/7dZ/erSSSmr+1el/8Acyj/ALdZ/el+1el/9zKP+3Wf 3q0kkpq/tXpf/cyj/t1n96X7V6X/ANzKP+3Wf3q0kkpq/tXpf/cyj/t1n96X7V6X/wBzKP8At1n9 6tJJKav7V6X/ANzKP+3Wf3pftXpf/cyj/t1n96tJJKav7V6X/wBzKP8At1n96X7V6X/3Mo/7dZ/e rSSSmr+1el/9zKP+3Wf3olOZh5Di3HvrucBJDHtcQPH2lGSSUpJJJJSkkkklKSSTEwJ8ElOZjder uzasO7DycM5LXuxLMhrGttFcF0NZY6xh2mYsa0psfr9dubViX4mThnJa92LbkNY1torguhrbHPYd p3RY1phZnS+oftTrgz87HzMY0iynp2Lbh5TAxp/nL7rXVCrfYGw0btG+Z0HhZZ611V+TmUZmI5rL cbpuNZiZLBWHgizIuudUKg94HtG72jzOg1rQXoTX5J0s3pqB/F08T60YeTkY9f2fIpx85zmYObY1 gpvcwF0M22Osbua0ubvY2QNOy2Vx/TmZd+F9X+j/AGTIqyOk2VHOfbVZXUwYtbqvZa9oZbvdG3Y4 6arsE4ga1rRIB7juj+Fkdj2avUv6Oz/j8f8A8/1q0s3qeNcaw/7VaGm+iGAVbRN1YEfo507SVY+x 5H/c6/8AzaP/AEigptJKr9jyP+51/wDm0f8ApFL7Hkf9zr/82j/0ikpPbWLan1uJAe0tJaYIBEaF c/8A8xuk/wCmyP8AOZ/6TXQVMcxga57rXDl79oJ+OxrR+CmnRyTj8pq1soRl8wt4HN+qXU25VjcL Ge/GBit77KtxA7/Sbz8Fs1/Ufpbq2ue/JY4gFzC+swSNRIrjRdKkpJczkIAuq7LBggCdLvu89kfV kYnTH1dML77W30ZTarngB5x7G2+mCGgN3RE+MKefiZHXDgtzemOqxKMv1LqMl1Ly5govZueyqyxh bve0RuM9xC3klEZEkk62b17/AMgyAAChpoY/Q/77yb/q/kf85znW05L2NurfiZOP9i9OqprGt9J7 rmtymtkO3NrJaQfMpYXQ8mvrFGQ/porvpy8m3J6pvrJvrtbcKuHmx23c1sPaNv5shdYkh0rwI+1J 6+P8v2vK9F+r7sHqHTMvI6c197enU41uS0Ul1F1TSHFzi8PO5p2As3eeia/pvWbDn4/Tse7p9F9O QLK7bmPosuefZZi7Hvsq3Sd2jBrO3curSSOv/O/5xtN635fg81+xMXLowKK+iN6dh1Zpty8N7cdr XN+z2173NxrLGPBc5rYOp7iFnZ/1YzLMTCxrMa67BxnZbBh4/wBjscwPuLsd4Z1AOq2tq9o2kObM eK7ZJI/y/JHbwFfjbx3WugZWSLGHpz+ovswK6MLJvsp9TGtYH7/Uc54hz5bLq53HQ6K5lYPVft2V TXhuspyc7EzBlepWGNrpGMyxpaX+pvHpE/RiO86LpUkb1vxv8eJVaV4V+x5LK6F1SzGya20S6zH6 zWwb2CXZl7bMcfS/PaJ8u8Kv9YOm0dHws99OPVj4OScHc0hhpfa213rG5lltLDubtDy97Q796V2q SHQDt/G0k39sj9ZPP/UhmA3oc4Nba2WX2vs9NlTKy9ztzvS+z2317B9FsWOiImQugSVZ+Le5xcMy 5gJJDQKYHkN1RKJNoH7S2UlV+x5H/c6//No/9IpfY8j/ALnX/wCbR/6RQU2klV+x5H/c6/8AzaP/ AEil9jyP+51/+bR/6RSU2klV+x5H/c6//No/9IpfY8j/ALnX/wCbR/6RSU2klV+x5H/c6/8AzaP/ AEil9jyP+51/+bR/6RSU2klV+x5H/c6//No/9IpfY8j/ALnX/wCbR/6RSU2klTfjW1sL7OoXMY0S 5zhQAAO5JpXO/wDPDAn+kZ8ePp4v/kUDIDc0vhiyZL4ImVb09ckqv2PI/wC51/8Am0f+kUvseR/3 Ov8A82j/ANIorG0kqv2PI/7nX/5tH/pFL7Hkf9zr/wDNo/8ASKSm0kqv2PI/7nX/AObR/wCkUvse R/3Ov/zaP/SKSm0kqv2PI/7nX/5tH/pFL7Hkf9zr/wDNo/8ASKSm0kqv2PI/7nX/AObR/wCkUvse R/3Ov/zaP/SKSm0kqv2PI/7nX/5tH/pFL7Hkf9zr/wDNo/8ASKSm0kqv2PI/7nX/AObR/wCkUvse R/3Ov/zaP/SKSm0kqv2PI/7nX/5tH/pFL7Hkf9zr/wDNo/8ASKSm0kqv2PI/7nX/AObR/wCkUvse R/3Ov/zaP/SKSm0kqv2PI/7nX/5tH/pFL7Hkf9zr/wDNo/8ASKSm0kqv2PI/7nX/AObR/wCkUvse R/3Ov/zaP/SKSm0kqv2PI/7nX/5tH/pFL7Hkf9zr/wDNo/8ASKSm0kqv2PI/7nX/AObR/wCkUvse R/3Ov/zaP/SKSm0kqv2PI/7nX/5tH/pFL7Hkf9zr/wDNo/8ASKSm0kqv2PI/7nX/AObR/wCkUSmi 2pxL8iy8ERteKwB5/o62FJSZJJJJSkkkklKSSSSU1cbqvS8vItxcXMovyaJ9amqxj3sg7TvY0ktg 6apU9V6XkZdmFRmUW5dMm3GZYx1rNpg7mNO4QT3Cw62t6n1KvI6TW2vp/Rab6ce9jQ1lt9jfTNdO 3/B17dSNC7QcFZlQYfq99UziAHP3tdWW/S3mi37UTH8qd/n5oXpf93/nEgH8E1qR/e/5ounr6eq9 LyMuzCozKLcumTbjMsY61m0wdzGncIJ7hWlxWCMc9G+p5qAOX61ZBb9OTTZ9rJjznfPddqnEVY/d Jj511/FF7eI4vtvT8Gr1L+js/wCPx/8Az/WrSzepvzvTAFNRrF9G1xtduP6avbLfS0k86qx6nVP+ 49H/AG+//wBIIKbSSq+p1T/uPR/2+/8A9IJep1T/ALj0f9vv/wDSCSm0khbLLsd1d4FbrGua8VuJ gGR7X7WnjyWWPqtggAbyY7mjEJ+ZOMgSegtfGMT80uH6Wkv+tHQqLn0W5O2ypxY9vp2GHNMESGEL SptrvpZdUd1drQ9juJa4SDquAzPql1s5d5oxt9Jseanb6my3cdp2hzQNO0BdHhfVbHGHQLztuFbB a30cV0O2jcNzsdxOvckpkZTJNxbGXDy8YxMctk77S/AbOxm5uPgYz8rJc5tLIDi1jrHS4hjQGVtc 4kkxoFTb9Yukuxr8n1LGtxS1t9T6bm3tNhArnHdWLffPt9uvZVc3ohxemZDMBj8m2yzHs9EejXIp tY8hjWimsGAeeVVzum9U6q/KzPsr8B9jMXHoY51Lr4qyBfZa7Y62n2g+wSe+msJ4vq1pAA6G9vr3 d3A6lh9RqfZiucRW812MsY+qxjwA7a+u5rHtMEHUcKGJ1jAzMmzGx3vdZVuBca7G1u2O2P8ATtew Ms2u0O1xhAo6G7HY70eoZTb7rvXysmKDZcQ1tYa8OoLGtDWgexrVkX9N6zYc/H6dj3dPovpyBZXb cx9Flzz7LMXY99lW6Tu0YNZ27kf4fjS3+P4PR5ObVjW4tVgcXZlpprLYgOFdl0ukjSKyrC5r9iYu XRgUV9Eb07DqzTbl4b247Wub9ntr3ubjWWMeC5zWwdT3ELOz/qxmWYmFjWY112DjOy2DDx/sdjmB 9xdjvDOoB1W1tXtG0hzZjxSKu3l+Nl6/OzKsHDvzLQ51eOx1jw2C4hokxJCMDIlcf1roGVkixh6c /qL7MCujCyb7KfUxrWB+/wBRzniHPlsurncdDormVg9V+3ZVNeG6ynJzsTMGV6lYY2ukYzLGlpf6 m8ekT9GI7zojWteNX9a/tV0+lu1h9Tx8sxW2wHffXLmHbOPYaXy9ssEuHtBMkduVbXJZXQuqWY2T W2iXWY/Wa2DewS7MvbZjj6X57RPl3hV/rB02jo+Fnvpx6sfByTg7mkMNL7W2u9Y3MstpYdzdoeXv aHfvSgdh46fUmkka6d5fYHtUlz/1IZgN6HODW2tll9r7PTZUysvc7c70vs9t9ewfRbFjoiJkLoES KQP2lSSSrPs6iHEMopLJO0m5wJHaR6Jj70FNlJVfU6p/3Ho/7ff/AOkEvU6p/wBx6P8At9//AKQS U2klV9Tqn/cej/t9/wD6QS9Tqn/cej/t9/8A6QSU2klV9Tqn/cej/t9//pBL1Oqf9x6P+33/APpB JTaSVX1Oqf8Acej/ALff/wCkEvU6p/3Ho/7ff/6QSU2klV9Tqn/cej/t9/8A6QTOu6kxpc6igNaJ JN79AP8ArCSmj1ax+Vl19PqMQWl3cbzLhP8AxbWl/wAdq5LN+qfUcLZ61lJa8E72ucQNsTMsHDSX fAFdN0c9QvyLs/0Ki50gB9rmwbA2w/4J3DPTZ/ZR+sjOswi+7Hp2UEWOi5x9gltg/mRyxzgo5REh ZbmPPLDMY41Wgl5uykszp+R1SzDqJppe5gNb3G5wJfWTW+R6J/Oae6s+p1T/ALj0f9vv/wDSCkDU IokdjTaSVX1Oqf8Acej/ALff/wCkEvU6p/3Ho/7ff/6QSQ2klV9Tqn/cej/t9/8A6QS9Tqn/AHHo /wC33/8ApBJTaSVX1Oqf9x6P+33/APpBL1Oqf9x6P+33/wDpBJTaSVX1Oqf9x6P+33/+kEvU6p/3 Ho/7ff8A+kElNpJVfU6p/wBx6P8At9//AKQS9Tqn/cej/t9//pBJTaSVX1Oqf9x6P+33/wDpBL1O qf8Acej/ALff/wCkElNpJVfU6p/3Ho/7ff8A+kEvU6p/3Ho/7ff/AOkElNpJVfU6p/3Ho/7ff/6Q S9Tqn/cej/t9/wD6QSU2klV9Tqn/AHHo/wC33/8ApBL1Oqf9x6P+33/+kElNpJVfU6p/3Ho/7ff/ AOkEvU6p/wBx6P8At9//AKQSU2klV9Tqn/cej/t9/wD6QS9Tqn/cej/t9/8A6QSU2klV9Tqn/cej /t9//pBL1Oqf9x6P+33/APpBJTaSVX1Oqf8Acej/ALff/wCkEvU6p/3Ho/7ff/6QSU2klV9Tqn/c ej/t9/8A6QRKXZjnH7RVXW2NCyxzzPwdWxJSZJJJJSkkkklKTEAiDqDyE6SSnOxvq79X8S9uTi9M xMfIZJZdVRWx7SRBhzWghHx+ldLxsqzMxsOinKvn1siutjbH7juO97QHOk66rL6Tl9bd9YeoYfU7 qnVMopvx6KGw2sWWXMg2OAe9xbWCSYE8BY3SPrLnXdUqosz3X5VZyndWwH11MpoZTuA+zWNra+wh +1v036TugpX+RP0G6iN/MD6nUPW4/Sul42VZmY2HRTlXz62RXWxtj9x3He9oDnSddVaXKYPUusin ovVr8w309ZsY27CdXW2upuQx1tXouYxtksgA73OnVdWjVadjw12I6fiq/wARxef8qavUv6Oz/j8f /wA/1q0s3qefgisVHJqFjL6NzC9u4bbqy6RPYDVWP2r0v/uZR/26z+9BTaSVX9q9L/7mUf8AbrP7 0v2r0v8A7mUf9us/vSU2klV/avS/+5lH/brP70v2r0v/ALmUf9us/vSU2klV/avS/wDuZR/26z+9 L9q9L/7mUf8AbrP70lNpJVf2r0v/ALmUf9us/vS/avS/+5lH/brP70lNpJVf2r0v/uZR/wBus/vS /avS/wDuZR/26z+9JTaSVX9q9L/7mUf9us/vS/avS/8AuZR/26z+9JTaSVX9q9L/AO5lH/brP70v 2r0v/uZR/wBus/vSU2klV/avS/8AuZR/26z+9L9q9L/7mUf9us/vSU2klV/avS/+5lH/AG6z+9L9 q9L/AO5lH/brP70lNpJVf2r0v/uZR/26z+9L9q9L/wC5lH/brP70lNpJVf2r0v8A7mUf9us/vS/a vS/+5lH/AG6z+9JTaSVX9q9L/wC5lH/brP70v2r0v/uZR/26z+9JTaSVX9q9L/7mUf8AbrP70v2r 0v8A7mUf9us/vSU2klV/avS/+5lH/brP70v2r0v/ALmUf9us/vSU2ln9bubXgOrcYF59Nx/kQXWn 5VtcUb9q9L/7mUf9us/vWR1PqGBl9Qox/tNRpbAe7e3b7yXv1n9yvb/bQlt5smIXME7R9R+jr9Mp dThViwbbXzbaPB9h3uHyJhHuqbdTZS/6NjSx3wcIKB+1el/9zKP+3Wf3pftXpf8A3Mo/7dZ/ejWl LDImRl1u2l9XbXGi2qz6bXNefi9oD/8AwVr1rrnsDPwMfq+Q37TUKrN8P3t2/Sbe3WfG9/3LX/av S/8AuZR/26z+9Njt5L83z2NpASDaSVX9q9L/AO5lH/brP70v2r0v/uZR/wBus/vTmNtJKr+1el/9 zKP+3Wf3pftXpf8A3Mo/7dZ/ekptJKr+1el/9zKP+3Wf3pftXpf/AHMo/wC3Wf3pKbSSq/tXpf8A 3Mo/7dZ/el+1el/9zKP+3Wf3pKbSSq/tXpf/AHMo/wC3Wf3pftXpf/cyj/t1n96Sm0kqv7V6X/3M o/7dZ/el+1el/wDcyj/t1n96Sm0kqv7V6X/3Mo/7dZ/el+1el/8Acyj/ALdZ/ekptJKr+1el/wDc yj/t1n96X7V6X/3Mo/7dZ/ekptJKr+1el/8Acyj/ALdZ/el+1el/9zKP+3Wf3pKbSSq/tXpf/cyj /t1n96X7V6X/ANzKP+3Wf3pKbSSq/tXpf/cyj/t1n96X7V6X/wBzKP8At1n96Sm0kqv7V6X/ANzK P+3Wf3pftXpf/cyj/t1n96Sm0kqv7V6X/wBzKP8At1n96X7V6X/3Mo/7dZ/ekptJKr+1el/9zKP+ 3Wf3olOZh5Di3HvrucBJDHtcQPH2lJSZJJJJSkkkklKSSSSU4lPRurN61f1K7Ox31ZNTceyhmM9j vSrNjmbbDlOh36TU7fkFXxPqpkVt6di5WZXf0/pDt2JUzHNVxhjqmerd6zw72vO7axu4/crfS+vv 6h1XMwHYVuJXisZZVbf7XWte+yvcKo3MbNZjdqR2Cfp3WM3qJGXTi1M6Q4u2ZVl5Fz2Mkeo2htLm 7XOGk2AxrHZLSvCr18Em7Pfb7R/BBg/VrIoODRk5ov6f0p2/Bx21GuyWhzKvXt9Vws9NjoG1jddS t5YGH9Zsm5+DdfginpvVXlmFktt32SWl9Ruq9NoYLGtMQ93YFb6Ov46+fj4o6/T8PBq9S/o7P+Px /wDz/WrSq9S/o7P+Px//AD/WrSClJJJJKUkkkkpSSSSSlJJJJKUkkkkpSSSSSlJJJJKUkkkkpSSS SSlJJJJKUkkkkpSSSSSlJJKFt1NFZtue2qtv0nvIa0TpqSkpmkszI+sXSaiG15DMixwJDKnsOg5l 7nNYPmUH/nF4Y/8A05/I0ocQ7sgw5Drwn66Ojk9RwMQ7crIqpdG4Ne9rXEeIaTJWZ0EjMuu6huD5 JaC0gw+zbY8SP3WCtn9lYXXcDq/XM9uRjYh2sqbXMlo0c53N7apPu7Ld+qXTszp3Tracyv0rHXOe G7mu9pYxsywkchMEiZbaDqzyxwx4SeMe5KrjYsO2kkkpGo42b+g67j28Cz05/wDBKXfjYxbKxvrG CxtGSBrXv/6AGSPxoC2AQQCNQeE0bkMuTWGOXgY/YukkknMSkkkklKSSSSUpJJJJSkkkklKSSSSU pJJJJSkkkklKSSSSUpJJJJSkkkklKSSSSUpQtuporNtz21Vt+k95DWidNSVNZH1rY6zoORWwF9jz U1jGiS4+qzQAclAmgT2C7HHinGJNcRAvzb1PU+nZFgqoyqbbHcMZY1zjGvAKsrz/AOqmBnM61iZD 8a1tEPPquY4Mh1bwDuIjWV6AhCRkLIpl5nDHFMRjLi0tSSSScwKXM9Yp+s1t7nN6/idBoabHUVto Ze99NYaXWWvyXMALeSGtho5JXTLhPrFZ1Z94Z9YukZF/T6XWMbm9Hc20W0WOa/0b8exptYwtrHqO a4ajTlDr/HZI/l3el6AesGj9ezcXquM5jXYvUMdvpvtn6RfW0vr+DmO+S1lh/VDM+rl/SvR+r2S3 IxKX2OLQNjmG177INWyssbJO32jRbicd1oeexv2k76z5WVb0vIqxMnHqxm3ufjFoNT7nF7msyHP2 kPEQ2fILI6Z9VMiodOw/2azCyMFz25nWGmofaKQx9Qrb6Vhud6gc3SxoAjyC7NmVjPvsxmWsdkVB rraQ4F7Q76Jc2ZAMaJjl4jcpuG66sZT2GxuOXD1CwGC4MndE902tK/keq6zqfL8qeb6f03rD8fov SsjEONV0V7HXZjn1uruGOx1VfoNZY6z3yHHe1sBdUqtPVel5GXZhUZlFuXTJtxmWMdazaYO5jTuE E9wrSdd6/vHi8yev4Ir8Bw+Qc3qeFSaxZut3OvokC60N911YMN3wOdI4Vj9m4/79/wD7EX/+lEup f0dn/H4//n+tWkFNX9m4/wC/f/7EX/8ApRL9m4/79/8A7EX/APpRWkklNX9m4/79/wD7EX/+lEv2 bj/v3/8AsRf/AOlFaSSU1f2bj/v3/wDsRf8A+lEv2bj/AL9//sRf/wClFaSSU1f2bj/v3/8AsRf/ AOlEv2bj/v3/APsRf/6UVpJJTV/ZuP8Av3/+xF//AKUS/ZuP+/f/AOxF/wD6UVpJJTV/ZuP+/f8A +xF//pRL9m4/79//ALEX/wDpRWkklNX9m4/79/8A7EX/APpRL9m4/wC/f/7EX/8ApRWkklNX9m4/ 79//ALEX/wDpRL9m4/79/wD7EX/+lFaSSU1f2bj/AL9//sRf/wClEv2bj/v3/wDsRf8A+lFaSSU1 f2bj/v3/APsRf/6US/ZuP+/f/wCxF/8A6UVpJJTV/ZuP+/f/AOxF/wD6US/ZuP8Av3/+xF//AKUV pJJTV/ZuP+/f/wCxF/8A6US/ZuP+/f8A+xF//pRWkklNX9m4/wC/f/7EX/8ApRZn1k6aw9HuZQbX 3PdW2tj77HBzjYzTbY8tK3VjdYc7JzKMBhI43EdnWBzZ/s1NsPxhNlsR30ZMP85E/uni+x5z6ufV 3qJ6hi5eRQ5uGdzvVbYGmCx2wjY8P+lHC7L9m4/79/8A7EX/APpRWWtaxoY0Q1oAAHYBOlCIiKCc +eWafFIAUKFdmr+zcf8Afv8A/Yi//wBKJfs3H/fv/wDYi/8A9KK0knMTV/ZuP+/f/wCxF/8A6US/ ZuP+/f8A+xF//pRWkklOR1fpuOMPfuuIZZWXbrrXe0va1/0nn8wlT6XhU3dOx3vff6nptFkX3Abm ja7QWeIVzPpORg5FA5sqe0fEtMKr0G71sN5HAtc4fC6MgfhYm/pfRl3w/wB2X4Fsfs3H/fv/APYi /wD9KJfs3H/fv/8AYi//ANKK0knMTV/ZuP8Av3/+xF//AKUS/ZuP+/f/AOxF/wD6UVpJJTV/ZuP+ /f8A+xF//pRL9m4/79//ALEX/wDpRWkklNX9m4/79/8A7EX/APpRL9m4/wC/f/7EX/8ApRWkklNX 9m4/79//ALEX/wDpRL9m4/79/wD7EX/+lFaSSU1f2bj/AL9//sRf/wClEv2bj/v3/wDsRf8A+lFa SSU1f2bj/v3/APsRf/6US/ZuP+/f/wCxF/8A6UVpJJTV/ZuP+/f/AOxF/wD6US/ZuP8Av3/+xF// AKUVpJJTV/ZuP+/f/wCxF/8A6US/ZuP+/f8A+xF//pRWkklNX9m4/wC/f/7EX/8ApRL9m4/79/8A 7EX/APpRWkklNX9m4/79/wD7EX/+lEv2bj/v3/8AsRf/AOlFaSSU1f2bj/v3/wDsRf8A+lEv2bj/ AL9//sRf/wClFaSSU1f2bj/v3/8AsRf/AOlFj5uJXl9RrwqX3bGGHk3Wuh2hscNzz9Bh2/F/ktrO yvsuM6xo3WGG1MP5z3aNH38+SyMfIq6X0q7qtx3usEUToXgklp/668l58j5IUZERHVkgRCMsh6aD zdNnTsMDZW+6Ge3a3Iu0gcaWaaI1OJVQ4uY6wkiPfbZYPusc4Lmvqpd1VuZacqm00Zs3es5pDd/0 t08Q4fwXVqTJDglw3fkwwnxC6pSSSSYuUvNfrzVl9N6rldRu6/kDGsZW+rpOL1B2Hktktq/Q0+ne LAYn83uvSl5v9YOkDH6/mdUtxPrFTkZjtrb+hWV21WVMawNLoa2ys6atdpPBKH6Q+v8AvJGx+j1v 1TxsavpNeTXVmMvvkXXdUaBnvDHvDPtDgJdtn2T+attYX1Sszj09tV2Pm14tYmjI6ra1+baXEud6 tbAdgbMCXT5LdTpblaHmul4OF0z609UbiU7Guw6L7Q2Xvssfbkue5znEue4+ZWLi5xs+sODmWU5V fU86nNc9luJkV+mXChuPSC+po21tHucDt3SZ1XX1fV/oNOUMynpuJXlBxeMhlFbbNx5dvDd0mVcd RQ+5l7q2uuqDm12FoLmh8bg13ImBKbWgHgR9trr9V+IP2CtXjsEY56N9TzUAcv1qyC36cmmz7WTH nO+e67VVcfpXS8bKszMbDopyr59bIrrY2x+47jve0BzpOuqtJxN2e5MvK+n4IrbwHD+Zv8XN6m/O 9MAU1GsX0bXG124/pq9st9LSTzqrHqdU/wC49H/b7/8A0gl1L+js/wCPx/8Az/WrSCmr6nVP+49H /b7/AP0gl6nVP+49H/b7/wD0grSSSmr6nVP+49H/AG+//wBIJep1T/uPR/2+/wD9IK0kkpq+p1T/ ALj0f9vv/wDSCXqdU/7j0f8Ab7//AEgrSSSmr6nVP+49H/b7/wD0gl6nVP8AuPR/2+//ANIK0kkp q+p1T/uPR/2+/wD9IJep1T/uPR/2+/8A9IK0kkpq+p1T/uPR/wBvv/8ASCXqdU/7j0f9vv8A/SCt JJKavqdU/wC49H/b7/8A0gl6nVP+49H/AG+//wBIK0kkpq+p1T/uPR/2+/8A9IJep1T/ALj0f9vv /wDSCtJJKavqdU/7j0f9vv8A/SCXqdU/7j0f9vv/APSCtJJKavqdU/7j0f8Ab7//AEgl6nVP+49H /b7/AP0grSSSmr6nVP8AuPR/2+//ANIJep1T/uPR/wBvv/8ASCtJJKavqdU/7j0f9vv/APSCXqdU /wC49H/b7/8A0grSSSmr6nVP+49H/b7/AP0gsjpj8/Kzrs5tNTuS3da4AeoGbYIqPFbGn+15rV6r aa8GwNdtfbFTHeBsOzd/ZmVHo1QrwGPDdvrk27fBrvoN/ss2hNOpA7assfTjlL948I/ak9Tqn/ce j/t9/wD6QS9Tqn/cej/t9/8A6QVpJOYmr6nVP+49H/b7/wD0gl6nVP8AuPR/2+//ANIK0kkpq+p1 T/uPR/2+/wD9IJep1T/uPR/2+/8A9IK0kkpq+p1T/uPR/wBvv/8ASCyOiPz6bsjGZTUdkaOtc0fo 3Po0io9qx8oXQrFo/Q/WG1v5tu+P7bKnt/Gt6adwWXHrHJHw4v8AFdD1Oqf9x6P+33/+kEvU6p/3 Ho/7ff8A+kFaSTmJq+p1T/uPR/2+/wD9IJep1T/uPR/2+/8A9IK0kkpq+p1T/uPR/wBvv/8ASCXq dU/7j0f9vv8A/SCtJJKavqdU/wC49H/b7/8A0gl6nVP+49H/AG+//wBIK0kkpq+p1T/uPR/2+/8A 9IJep1T/ALj0f9vv/wDSCtJJKavqdU/7j0f9vv8A/SCXqdU/7j0f9vv/APSCtJJKavqdU/7j0f8A b7//AEgl6nVP+49H/b7/AP0grSSSmr6nVP8AuPR/2+//ANIJep1T/uPR/wBvv/8ASCtJJKavqdU/ 7j0f9vv/APSCXqdU/wC49H/b7/8A0grSSSmr6nVP+49H/b7/AP0gl6nVP+49H/b7/wD0grSSSmr6 nVP+49H/AG+//wBIJep1T/uPR/2+/wD9IK0kkpq+p1T/ALj0f9vv/wDSCXqdU/7j0f8Ab7//AEgr SzepdbwcWmxleVT9qB9NrC9steTEvbMgN5KBIG66MJSNRFudmWdQ6lntxG1VBtW5rttro02+q7d6 Q/Nd6Y05J8NKTzlfWPqba66q/sHTz7qxYRW90xo/051j93hLJyH4+FXiYUvz+rBoZr7m45nZJ/ef JcfMldH0jptXTMGvFr1I1sf+888lS4/RD3D88/l8B3W5yJzGIfJi+bxPZkH9TAgY9AA4Hrv/APSC LS7Mc4/aKq62xoWWOeZ+Dq2IySjUpJJJJSlxX1h6/wDXLpPVK6PW6JjYWY+37JdmOvr2srAd+mfu awOMjRq7Vcb/AIyM77Jj9P8AtIqb04378my/GbltJYWhtW17Xhm9rnndE6aIHp9iR1+37Hb+qnVc vq/QsfqGb6P2i02B5xt3pHZY+sFm8uJBDeZWusj6q3vyOhY9xr9Kpxs+zM9MVfq4seMf9G0NDZq2 9lrp0tz0Wjbu870dnUaPrP1KjMzrMwOxqL2sIDKq99mQ3bVUJDQGtaJJJPcoUPwOv104OTlZbqMa 6/qzbrn3Mhwmj2Odsre57TtbW1vtnSIWhR0B9PVbOqftPLstta2uypwxvTNbC9zGe3Ga6Gl513T4 kqPSfq2elvcaupZd1Vlj7b6rhjOFr3/SdZY3Gba7/P7AcaJutaaGiPt2XaWTvrE15buPgPzKsT6v 9a+15FmR1WysZ1dlr30vblVut2spc411+m4DbsaNNDyV2Kx8L6sYmJdju+0ZF+Pguc7BxLTWaqC6 W+zZW17trXFrd7nQFsJxrWtBZIHYdkfwo+J7ub1PPwRWKjk1Cxl9G5he3cNt1ZdInsBqrH7V6X/3 Mo/7dZ/el1L+js/4/H/8/wBatIKav7V6X/3Mo/7dZ/el+1el/wDcyj/t1n96tJJKav7V6X/3Mo/7 dZ/el+1el/8Acyj/ALdZ/erSSSmr+1el/wDcyj/t1n96X7V6X/3Mo/7dZ/erSSSmr+1el/8Acyj/ ALdZ/el+1el/9zKP+3Wf3q0kkpq/tXpf/cyj/t1n96X7V6X/ANzKP+3Wf3q0kkpq/tXpf/cyj/t1 n96X7V6X/wBzKP8At1n96tJJKav7V6X/ANzKP+3Wf3pftXpf/cyj/t1n96tJJKav7V6X/wBzKP8A t1n96X7V6X/3Mo/7dZ/erSSSmr+1el/9zKP+3Wf3pftXpf8A3Mo/7dZ/erSSSmr+1el/9zKP+3Wf 3pftXpf/AHMo/wC3Wf3q0kkpq/tXpf8A3Mo/7dZ/el+1el/9zKP+3Wf3q0kkpq/tXpf/AHMo/wC3 Wf3pftXpf/cyj/t1n96tJJKef611HBybaMWvJqLDO9wsbANn6HmezHPP3LVHVOlAADLoAGgHqM/v VHB/W+sXZPLKtxb+NFf/AFFh/tLZTY9T3ZcugjD90a+Zav7V6X/3Mo/7dZ/el+1el/8Acyj/ALdZ /erSScxNX9q9L/7mUf8AbrP70v2r0v8A7mUf9us/vVpJJTV/avS/+5lH/brP70v2r0v/ALmUf9us /vVpJJTV/avS/wDuZR/26z+9ZHUOoYLOrY2TXk1Ob7Nxa9pA2udVrB/dyCfl5LoVk/WKpz8at7Pp tc5gPm9jgz/wTYhLZkw/OAdpWC3P2r0v/uZR/wBus/vS/avS/wDuZR/26z+9GotbdTXc36NjQ9vw cJREWM6NX9q9L/7mUf8AbrP70v2r0v8A7mUf9us/vVpJJTV/avS/+5lH/brP70v2r0v/ALmUf9us /vVpJJTV/avS/wDuZR/26z+9L9q9L/7mUf8AbrP71aSSU1f2r0v/ALmUf9us/vS/avS/+5lH/brP 71aSSU1f2r0v/uZR/wBus/vS/avS/wDuZR/26z+9WkklNX9q9L/7mUf9us/vS/avS/8AuZR/26z+ 9WkklNX9q9L/AO5lH/brP70v2r0v/uZR/wBus/vVpJJTV/avS/8AuZR/26z+9L9q9L/7mUf9us/v VpJJTV/avS/+5lH/AG6z+9L9q9L/AO5lH/brP71aSSU1f2r0v/uZR/26z+9L9q9L/wC5lH/brP71 aSSU1f2r0v8A7mUf9us/vXmnVXts6nmWVndW++1zXDUEOe4gg+a9B63m+lV9lrn1Lh79phwYTthp /eefa37+y5HIry+pX7MKg5NGK73lg9jnmN0ce2GhrR+6AjHD70qJ4Yx1lJnx8weWgZgcUsmkY+W5 dP6p14VLf2jn5VQyXNFVLH2NDmVtAZwTpoI+HxXS/tXpf/cyj/t1n96PS7dTW7YapaD6Z0LdPo6e CmjKRJ16aDyDXHU9yZHzLV/avS/+5lH/AG6z+9EpzMPIcW499dzgJIY9riB4+0oySalSSSSSlLjP 8ZPVcrpOP0/NF+RRhMvm8Yj2ssfYC11bH7i0urLRZuAPguzXI/XbAuzrsXKxX9Je3pXqHMq6u4ml ovDG1l7GggfR0Lo8u6B6eaR+wux9Vb8rJ6Hj5eSXbso2X1B7/UcKbbH2UNc4EzFbm91rLmvqNgdb 6f0v7Nnv6fZhR6mC/p7rHAttc+15JsAbt9w2bNIXSp0tzS0ON036wuzup5uFZh24lWHWy2u6/wBr rWOdZWX+lG5jZqMbtSOwQMX60X2HCyMnCFHTOpuLcPKFu+zVrrKjdV6bQwWMaSIe7sCoVV9Ru+sW bdd0zJqw8zFrxBe5+MQDW68ueWsyHP2kWCIbPkFVxekdWyMHpPRMrEONR0ot9fMc+tzLW01vpr9B tdhs9+4OO9rYHmm61fXT8zxfhS41Z7f2CvxtvYf1mybn4N1+CKem9VeWYWS23fZJaX1G6r02hgsa 0xD3dgVvrlen9N6w/H6L0rIxDjVdFex12Y59bq7hjsdVX6DWWOs98hx3tbAXVJxrWu5rxj0JR/DX zavUv6Oz/j8f/wA/1q0s3qeFSaxZut3OvokC60N911YMN3wOdI4Vj9m4/wC/f/7EX/8ApRBTaSVX 9m4/79//ALEX/wDpRL9m4/79/wD7EX/+lElNpJVf2bj/AL9//sRf/wClEv2bj/v3/wDsRf8A+lEl NpJVf2bj/v3/APsRf/6US/ZuP+/f/wCxF/8A6USU2klV/ZuP+/f/AOxF/wD6US/ZuP8Av3/+xF// AKUSU2klV/ZuP+/f/wCxF/8A6US/ZuP+/f8A+xF//pRJTaSVX9m4/wC/f/7EX/8ApRL9m4/79/8A 7EX/APpRJTaSVX9m4/79/wD7EX/+lEv2bj/v3/8AsRf/AOlElNpJVf2bj/v3/wDsRf8A+lEv2bj/ AL9//sRf/wClElNpJVf2bj/v3/8AsRf/AOlEv2bj/v3/APsRf/6USU2klV/ZuP8Av3/+xF//AKUS /ZuP+/f/AOxF/wD6USU2klV/ZuP+/f8A+xF//pRL9m4/79//ALEX/wDpRJTaVbqOQ7Hw7bK/52Nl Q8bHnYwf5xCb9m4/79//ALEX/wDpRefdX6j1AdQyscZV3o032NrYbHOADHOa36RJ0CbOQiPNn5bA cs6FenU29z0KhtWF6jdW3GWHxraBXWf7TWh3zWksrpWDTZ0vDsc+7c+ipxi+4CSwHQCyArf7Nx/3 7/8A2Iv/APSiI2DHkJM5X3LaSVX9m4/79/8A7EX/APpRL9m4/wC/f/7EX/8ApRFY2klV/ZuP+/f/ AOxF/wD6US/ZuP8Av3/+xF//AKUSU2klV/ZuP+/f/wCxF/8A6US/ZuP+/f8A+xF//pRJTaXPfXe6 6npNTqnurJyGSWkg6Ne8ajwc0Fa/7Nx/37//AGIv/wDSiY9NxiILryD/AN2L/wD0ohIWCO6/FPgn GdcXCbp576h5OTczMrttfZXSKRU17i4NH6QQ2eOAusXPdEwqW3ZGI91oNcQG3Wt+g59B+i8fm1tP zWv+zcf9+/8A9iL/AP0ohAVEBfzR4s0iBV1+TaSVX9m4/wC/f/7EX/8ApRL9m4/79/8A7EX/APpR OYW0kqv7Nx/37/8A2Iv/APSiX7Nx/wB+/wD9iL//AEokptJKr+zcf9+//wBiL/8A0ol+zcf9+/8A 9iL/AP0okptJKr+zcf8Afv8A/Yi//wBKJfs3H/fv/wDYi/8A9KJKbSSq/s3H/fv/APYi/wD9KJfs 3H/fv/8AYi//ANKJKbSSq/s3H/fv/wDYi/8A9KJfs3H/AH7/AP2Iv/8ASiSm0kqv7Nx/37//AGIv /wDSiX7Nx/37/wD2Iv8A/SiSm0kqv7Nx/wB+/wD9iL//AEol+zcf9+//ANiL/wD0okptJKr+zcf9 +/8A9iL/AP0ol+zcf9+//wBiL/8A0okptIWTkV41D77J2sHA1JJ0a1o8SdAhfs3H/fv/APYi/wD9 KLlvrFl1tsFOK+57t2yhputfLwdrrAC8/RPsb4nd4JUSQBqToF0ADZlpGOsj4Icu/M6lnnCx4dk3 uPqvBlrNNroP7rG+0fM/nLr+m9Po6diMxaB7WfSd3c48uPxWZ0L6tU4WKH5Bf9rsE2Gux7IB/M/R ubMLT/ZuP+/f/wCxF/8A6UT5EADHHYak/vS7rCTORnIVekR+7HoG0kqv7Nx/37//AGIv/wDSiX7N x/37/wD2Iv8A/SiYltJKr+zcf9+//wBiL/8A0oiU4lVDi5jrCSI99tlg+6xzgkpMkkkkpS5nqX1K r6l1o5uTmOd0y22vJyelGtpZbfSz0mOdYTOzaBLIgrpkkut9ld/Fz+hdJZ0bplfT2PD21useC1ux o9Sx1u1rJdta3dAErQSSSUpVKOr9KyMuzCx83Huy6p9XHrtY61u07XbmNcXCDyrL3BrHOPDQSY50 Xn/TPt9TOh32Ct/S7HX/ALDZUf1lll9Vrqjl6bXRXu3bODzu5QvfwH+8mv5fm9xT1XpeRl2YVGZR bl0ybcZljHWs2mDuY07hBPcK0uKwRjno31PNQBy/WrILfpyabPtZMec757rtU4irH7pMfOuv4ovb xHF9t6fg1epf0dn/AB+P/wCf61aWb1N+d6YApqNYvo2uNrtx/TV7Zb6WknnVWPU6p/3Ho/7ff/6Q QU2klV9Tqn/cej/t9/8A6QS9Tqn/AHHo/wC33/8ApBJTaSVX1Oqf9x6P+33/APpBL1Oqf9x6P+33 /wDpBJTaSVX1Oqf9x6P+33/+kEvU6p/3Ho/7ff8A+kElNpJVfU6p/wBx6P8At9//AKQS9Tqn/cej /t9//pBJTaSVX1Oqf9x6P+33/wDpBL1Oqf8Acej/ALff/wCkElNpJVfU6p/3Ho/7ff8A+kEvU6p/ 3Ho/7ff/AOkElNpJVfU6p/3Ho/7ff/6QS9Tqn/cej/t9/wD6QSU2klV9Tqn/AHHo/wC33/8ApBL1 Oqf9x6P+33/+kElNpJVfU6p/3Ho/7ff/AOkEvU6p/wBx6P8At9//AKQSU2klV9Tqn/cej/t9/wD6 QS9Tqn/cej/t9/8A6QSU2klV9Tqn/cej/t9//pBL1Oqf9x6P+33/APpBJSe66uil91p211tLnHwA Elc50/6vdP6jfkZmbjyXvcS3e8fpHOL7PouH0JDPiCrHVsvqNtleAymkWOcxxAtc4Ekn02umpvBb vP8AJb5q/jV9QxseuivHo21iJN75J7k/oOSdSmkCR12DNGUscLiTGU+xr0huU010UsoqG2upoYxu phrRAGqmqvqdU/7j0f8Ab7//AEgl6nVP+49H/b7/AP0gnMLaSVX1Oqf9x6P+33/+kEvU6p/3Ho/7 ff8A+kElNpJVfU6p/wBx6P8At9//AKQS9Tqn/cej/t9//pBJTaSVX1Oqf9x6P+33/wDpBL1Oqf8A cej/ALff/wCkElNpJVfU6p/3Ho/7ff8A+kEvU6p/3Ho/7ff/AOkElOeP1b6w+Db/AP0az/yWN+K2 lz3W359N2PmPpqb6c/Rtc6fTLcjvU38yt4+a1vU6p/3Ho/7ff/6QTY7keLLk1jjl3jw/4rbSVX1O qf8Acej/ALff/wCkEvU6p/3Ho/7ff/6QTmJtJKr6nVP+49H/AG+//wBIJep1T/uPR/2+/wD9IJKb SSq+p1T/ALj0f9vv/wDSCXqdU/7j0f8Ab7//AEgkptJKr6nVP+49H/b7/wD0gl6nVP8AuPR/2+// ANIJKbSSq+p1T/uPR/2+/wD9IJep1T/uPR/2+/8A9IJKbSSq+p1T/uPR/wBvv/8ASCXqdU/7j0f9 vv8A/SCSm0kqvqdU/wC49H/b7/8A0gl6nVP+49H/AG+//wBIJKbSSq+p1T/uPR/2+/8A9IJep1T/ ALj0f9vv/wDSCSm0kqvqdU/7j0f9vv8A/SChbk9QqrdbZTjtYwFznG98ADUn+YSU879f2ud9i2gu DBa58CYBNTQXeGuir/UbpjLci7OurMUbW0Ej2lzt24jzaB+KFmvz+udVGEGtY9xFlg3EhjWt9rHH ZpsBPb6Tiuh6P0rO6SyxlLK7GWkHa+90AjuIxxykMYH6wyIkflj/AFdmefMEY/uwiJRHzSvaV8VO 2kqvqdU/7j0f9vv/APSCXqdU/wC49H/b7/8A0gkwNpJVfU6p/wBx6P8At9//AKQS9Tqn/cej/t9/ /pBJTaSVX1Oqf9x6P+33/wDpBEpdmOcftFVdbY0LLHPM/B1bElJkkkklKSSSSUpJJJJSlSx+jdHx cp2ZjYONRlWbt+RXUxljtxl0va0OMnlXHHa0mJgTAXF9G6xuqxOr9Sp6j9o6hvdj3m4/Yi9zHOZQ 3GpyIADW7QX1akTMwhdWew/Pp9U1b1eP0rpeNlWZmNh0U5V8+tkV1sbY/cdx3vaA50nXVWlx2A/M qxPq/wBa+15FmR1WysZ1dlr30vblVut2spc411+m4DbsaNNDyV2KcRVj908J8x/vov8AEcX0P+81 epf0dn/H4/8A5/rVpZvU82kVivbbubfRJFNpb7bqyYdsg8aRyrH7Sx/3L/8A2Hv/APSaCm0kqv7S x/3L/wD2Hv8A/SaX7Sx/3L//AGHv/wDSaSm0kqv7Sx/3L/8A2Hv/APSaX7Sx/wBy/wD9h7//AEmk ptJKr+0sf9y//wBh7/8A0ml+0sf9y/8A9h7/AP0mkptJKr+0sf8Acv8A/Ye//wBJpftLH/cv/wDY e/8A9JpKbSSq/tLH/cv/APYe/wD9JpftLH/cv/8AYe//ANJpKbSSq/tLH/cv/wDYe/8A9JpftLH/ AHL/AP2Hv/8ASaSm0kqv7Sx/3L//AGHv/wDSaX7Sx/3L/wD2Hv8A/SaSm0kqv7Sx/wBy/wD9h7// AEml+0sf9y//ANh7/wD0mkptJKr+0sf9y/8A9h7/AP0ml+0sf9y//wBh7/8A0mkptJKr+0sf9y// ANh7/wD0ml+0sf8Acv8A/Ye//wBJpKbSDl5LMWh1zgXRAawcucTDWt8ydFVyOvdLxdpybH0b52+p VayY5jcwLJv6pj9ZzRVjusfi0mHOrrscQHD3P9jSQSPY3+0fBAmvNkx4zLUioDUlv9Gxn22P6heQ 9zyfTcOCTG948vaGt/kjzWuqbc/FY0MZXe1rQA0DHuAAHb+bUv2lj/uX/wDsPf8A+k0gKC2cuKV/ YPBtJKr+0sf9y/8A9h7/AP0ml+0sf9y//wBh7/8A0mitbSSq/tLH/cv/APYe/wD9JpftLH/cv/8A Ye//ANJpKbSSq/tLH/cv/wDYe/8A9JpftLH/AHL/AP2Hv/8ASaSm0kqv7Sx/3L//AGHv/wDSaX7S x/3L/wD2Hv8A/SaSm0kqv7Sx/wBy/wD9h7//AEml+0sf9y//ANh7/wD0mkpD1utr8EvcJbS9j3f1 J22f9BzkXpVjrOnUF+tjWBln9ev2P/6TVDIzMXIx7aHsv22scx36vfw4R/o1n9B6nWKLK7W27w4W ENptdrY0Gz6LD/hd6b+l5hlGuI/1ZX9C7ySq/tLH/cv/APYe/wD9JpftLH/cv/8AYe//ANJpzE2k lV/aWP8AuX/+w9//AKTS/aWP+5f/AOw9/wD6TSU2klV/aWP+5f8A+w9//pNL9pY/7l//ALD3/wDp NJTaSVX9pY/7l/8A7D3/APpNL9pY/wC5f/7D3/8ApNJTaSVX9pY/7l//ALD3/wDpNL9pY/7l/wD7 D3/+k0lNpJVf2lj/ALl//sPf/wCk0v2lj/uX/wDsPf8A+k0lNpJVf2lj/uX/APsPf/6TS/aWP+5f /wCw9/8A6TSU2klV/aWP+5f/AOw9/wD6TS/aWP8AuX/+w9//AKTSU2lg/WXqbaa3UtMiqH2DsX/S rZ+G93kAPzlczet42NQ54ZabSD6THU2sBIE8uYNABJ8lyeVuz82nDm13qO9TId6b9+wmS/YG7vf9 LiI2jsjCPHIR6byPaI3Xg+3A5CLO0B3kXc+p3TnVYr+o3Sb8wy0nU7J8/wB46rolTZn4lbG1srva xgDWtGPfAA0A/m1L9pY/7l//ALD3/wDpNGcuKRO3Ydh0Y4ihrqdye56tpJVf2lj/ALl//sPf/wCk 0v2lj/uX/wDsPf8A+k01LaSVX9pY/wC5f/7D3/8ApNL9pY/7l/8A7D3/APpNJTaSVX9pY/7l/wD7 D3/+k0SnLqvcWsbYCBPvqsrH32NaElJkkkklKSSSSUpJJJJSli4n1Wwsa2j9PfdiYb3WYeDYazRS 9+73M21tsdtD3Bu97on4LaWL/wA5K3fWAdIZTupDLTZmb9BbSK3vrDNpna21smedEtL+h/BTLC+r GJiXY7vtGRfj4LnOwcS01mqgulvs2Vte7a1xa3e50BbCwMP6zZNz8G6/BFPTeqvLMLJbbvsktL6j dV6bQwWNaYh7uwK30tf5d/HxV1/ls1epf0dn/H4//n+tWlV6l/R2f8fj/wDn+tWklKSSSSUpJJJJ SkkkklKSSSSUpJJJJSkkkklKSSSSUpJJJJSkkkklKSSQMzLZiUGxw3OJ211jQueeGj+PgNUkgEmh 1eY+vddl9mDVQx1tjfU3NYC4j1CwMmP3i0wifUbDzMX7b9poso3+ls9RjmTHqTG4DxWl0jEffaep ZB3l5Lqj2JI2mwT+bHtZ/J15cthRiFy42zPPw4fu4ANby8btSSSSkaqkkkklKSSSSUpJJJJSkkkk lKSSSSUpYuD+rdbvo4bbvA+ZGQz8bbPuW0sXq/6t1LGzOB7S4/8AFu2u/wDA7nn5Jsuh7MuHUyj+ 9E159HaSSSTmJSSSYkASdAElKJABJMAclcb9but3F+M3AvtpYA8usreWB/0YIDSHFvME6HstbKyb erXjExP6Ny5x1a4fvv8A5H7rfz/6vOtiYlOJXsrBJcZfY7Vz3fvOKYbkKBod2xjMcMhOY4pfufxe W+rfWupMwH2X7sqoWkG20vMe1unq+8D+1A8102J1HGy/awllsbjU+A6P3hBIcPNpIVpZuX0Si334 xFFgO4NAOzd+9DS0sd/KYQfiiAQN7ROePJIkx9u+o1DpJLyv9s9X/wC52RP/ABr/APyS7v8A5xCr TKo9M9/eK/8A26GOmxyA+C/NyeTHVESu9tNnZSXOdY+tZxsRluFWHWusDT6u1zdsOP8AgrOdPFVO kfXPJyMh7M6uoVhhc01kVndLRzfaG9/ij7kbpYOUymBnWg8dXrlWu6n07HsNV+VTVY3lj7GtcJ14 JWcetZt+mJizPDofZ/1LWV/+CLlOudO61kdUvufh3vc/bLmVEt0Y0aembG9v3ilKdDQWuw8txSIy SENL3FvoVV1N1YtpsbZU76L2EOaY00I0WX1vqeGOm5tNdnq2mmxpbV7tpLSJeRo35lZ3Q/q863pd BzC6p3vml9TS5vvdEi9rwJ5+iFt0dIwqS1xabXM1YbDuDT4tZ9BvyCNyI2qwtMcWOZ9Rnwy2Arbx fMsO2qnLousaH112Mc9n7zQ4Ej5hd19VcW2xt/WMoTkZziW+VYPb4n8AFV61lO6z1eroVDttFb92 S8HktEuaP6o/H4LqK62VVtqrG1jAGtaOAAIAUscfs46v1ZKJ8I/2rOY5n7zkEuHhjisb3ciySSST GNSSSSSlJJJJKUkkkkpSSSSSlJJJJKUkkkkpi8PLHBjtjyCGuiYPYx3XJ0fVnr2P1Dptb8rHycPH pyq8i9uO6t5OQa3PL5yny+1wJ3AQDOmoXXLOw+v9KzcluLj2uNr2ufSX1W1stawgOdTZYxrLQJGr CdNUKv8Al4JutezjdP6b1h+P0XpWRiHGq6K9jrsxz63V3DHY6qv0GssdZ75Djva2AuqWbjfWLo+V ltw6bybbC9tTnV2MqsdUYsbTc9grsLfBjitJOu9f3jxX3J6or8BXkHN6nhUmsWbrdzr6JAutDfdd WDDd8DnSOFY/ZuP+/f8A+xF//pRLqX9HZ/x+P/5/rVpBTV/ZuP8Av3/+xF//AKUS/ZuP+/f/AOxF /wD6UVpJJTV/ZuP+/f8A+xF//pRL9m4/79//ALEX/wDpRWkklNX9m4/79/8A7EX/APpRL9m4/wC/ f/7EX/8ApRWkklNX9m4/79//ALEX/wDpRL9m4/79/wD7EX/+lFaSSU1f2bj/AL9//sRf/wClEv2b j/v3/wDsRf8A+lFaSSU1f2bj/v3/APsRf/6US/ZuP+/f/wCxF/8A6UVpJJTV/ZuP+/f/AOxF/wD6 US/ZuP8Av3/+xF//AKUVpJJTV/ZuP+/f/wCxF/8A6US/ZuP+/f8A+xF//pRWkklNX9m4/wC/f/7E X/8ApRL9m4/79/8A7EX/APpRWlm9a6lRj4OVWy6Mr0bCxlcl7TtMOhurQPEoE0LXRiZSER1SX4mD j1OuutvZWwS5xyL/AP0osrG6d+1Ml1l3rNxayWljrrHdoNQJedT/AIT/ADR3XKYOdn5nUcOjIy77 GPvrEG15jc4NJEnQweV6XVVXTW2qpoZWwQ1o0AATIy4/INjLi+70L4py69g1x03GAgOvAH/di/8A 9KJ/2bj/AL9//sRf/wClFaSUjVav7Nx/37//AGIv/wDSiX7Nx/37/wD2Iv8A/SitJJKav7Nx/wB+ /wD9iL//AEol+zcf9+//ANiL/wD0orSSSmr+zcf9+/8A9iL/AP0ol+zcf9+//wBiL/8A0orSSSmr +zcf9+//ANiL/wD0ol+zcf8Afv8A/Yi//wBKK0kkpq/s3H/fv/8AYi//ANKJfs3H/fv/APYi/wD9 KK0kkpq/s3H/AH7/AP2Iv/8ASiX7Nx/37/8A2Iv/APSitJJKav7Nx/37/wD2Iv8A/Sio9Y6XjHCN pdcRSQ5+66136M+y36Tz/g3OWwovY2xjmPEteC1w8QdCgRYpdCXDIHsXO6diVX4VT7H3+qAWWxkX fzjDsf8A4T94FWf2bj/v3/8AsRf/AOlFldL6hjYF9+Bm5FdTmQ6bHtb7m/ozyR9Noa/5lbrHsexr 2ODmOALXAyCDwQUomwuywMZHTQ6g9NXPz8WnFwcnJY64voqfY0HIvgljS4T+l8lyWD1XP6vmVdPc A1t+4OHrZEEBjid2+58jSY78Sui6lY/q9h6djk+g4EPeODHtc8x+Yw/R/ed5AqXTvql07p2ZXmU2 3Osq3bQ9zS33NLDO1gPBTJcUiK+Xqz4jix45e4P1hBMNNuzcxui4ePXta64uMGx/r2tLnAAbnbXg dkX9m4/79/8A7EX/APpRWklI1SSTZav7Nx/37/8A2Iv/APSiX7Nx/wB+/wD9iL//AEorSSSGr+zc f9+//wBiL/8A0ol+zcf9+/8A9iL/AP0orSSSnIzvqx0zNrDHm5ha4O3Ntc46AiP0u8d/BD6f9Uum 4F5uqtyHOLSzWzZoSDzSKz28VtpIcIu61ZBmyCJhxHhPRq/s3H/fv/8AYi//ANKJfs3H/fv/APYi /wD9KK0kixtX9m4/79//ALEX/wDpRZH1gyKOn0tx8Z978/I9tDBfcSJ03R6n3K91rrmP0uoCPVyr NKaByT4nwCqdB6Ne253Vuqe/Pu1a0/4MH+MfcFLCIA457foj94/wY5SJPBHfqeyDp31Prp9HJvyL RlNIfZ6btok/SbuHu8iZW3+zcf8Afv8A/Yi//wBKK0kmTnKZuRtdGEYigKav7Nx/37//AGIv/wDS iX7Nx/37/wD2Iv8A/SitJJq5q/s3H/fv/wDYi/8A9KJfs3H/AH7/AP2Iv/8ASitJJKav7Nx/37// AGIv/wDSiX7Nx/37/wD2Iv8A/SitJJKav7Nx/wB+/wD9iL//AEoiU4lVDi5jrCSI99tlg+6xzgjJ JKUkkkkpSSSSSlJJJJKWJAEnQDkrkcbrfTPrH1n1sfPx2MxGX0dNx/Vr+0XXPaWWXGqd4Y1ohgOp 1dxC69JAi7B6gj7U3X2g/Y8R03Kxcvp/1Z6VjObb1Hp9tRzcdsGzH+z1PqvNzea/d7deZXbpJJxN 2f3iZHzP+8itvAcI8h/vub1Nmd6YIuqFZvo2tNTtw/TV7Zd6usHnRWPT6p/3Io/7Yf8A+l0upf0d n/H4/wD5/rVpBTV9Pqn/AHIo/wC2H/8ApdL0+qf9yKP+2H/+l1aSSU1fT6p/3Io/7Yf/AOl0vT6p /wByKP8Ath//AKXVpJJTV9Pqn/cij/th/wD6XS9Pqn/cij/th/8A6XVpJJTV9Pqn/cij/th//pdL 0+qf9yKP+2H/APpdWkklNX0+qf8Acij/ALYf/wCl0vT6p/3Io/7Yf/6XVpJJTV9Pqn/cij/th/8A 6XS9Pqn/AHIo/wC2H/8ApdWkklNX0+qf9yKP+2H/APpdL0+qf9yKP+2H/wDpdPn9Rw+nUi/Ms9Kt zgwOhzvcQTENBPZUR9aOkWhwxbDfY0bi0NcwAcbnPtDWga+KBkBuV8cWSQuMSR3rT7W45nUmgudk 44aNSTS8AD/t9cd1f60dYp6jdVi5jHUt27HV1MDTLWkkeoHnk/vLoBj9R6s4PyD6WNMgEe3+xW8S 4/yrBHg3ur7ei9Kj9Ji1XPP0rbmix7j4ue8ElNkJSGh4fFmxHFhleQDISK4dwPtcPpNXX+sYbMrJ zGehZuDQQ4H2uLdW0OpB47n5K/R9X7ahDrqbgDuDH0EMB8fTZc1hPmRK16aaaKxVQxtVbfosYA1o kzoApoiPfUsc80iTw+iJOkY6NT0+p/8Acij/ALYf/wCl0/p9U/7kUf8AbD//AEurSScxNX0+qf8A cij/ALYf/wCl0vT6p/3Io/7Yf/6XVpJJTV9Pqn/cij/th/8A6XS9Pqn/AHIo/wC2H/8ApdWkklNX 0+qf9yKP+2H/APpdL0+qf9yKP+2H/wDpdWkklNX0+qf9yKP+2H/+l0vT6p/3Io/7Yf8A+l1aSSU1 fT6p/wByKP8Ath//AKXS9Pqn/cij/th//pdWkklNX0+qf9yKP+2H/wDpdL0+qf8Acij/ALYf/wCl 1aSSU1fT6p/3Io/7Yf8A+l0vT6p/3Io/7Yf/AOl1aSSU1fT6p/3Io/7Yf/6XS9Pqn/cij/th/wD6 XVpJJT599Y+mdWt6zk2DHtvDtn6Wml+wxWwafT445Wth39bycCjApDGNbVXWYrsDgGgAtss3ANEc 7fd4BdWkmDHRJvdsy5rihCBgP1YAib7CnNw+m52Gxza76C55lzjQ6TGjW6XgANGgCsen1T/uRR/2 w/8A9Lq0kntckk2dy1fT6p/3Io/7Yf8A+l0vT6p/3Io/7Yf/AOl1aQ776sel99zttdbS57vABJCH 0+qf9yKP+2H/APpdL0+qf9yKP+2H/wDpdRu6v0uipttuVW1jgHN9wkgiQQ0arKu+ueBv9PCouy7O wa3aD98u/wCinxxTltErTkiNyHX9Pqn/AHIo/wC2H/8ApdL0+qf9yKP+2H/+l1yOT9b+pfb2Wij0 GUBzH4riTJPO/Ruojw0WqPrH1uoTkdHsc067qy4iPk1yeeXyCttfELBmgb308HZ9Pqn/AHIo/wC2 H/8ApdL0+qf9yKP+2H/+l1jH66UVj9NhZFbhyCB/GFTwfrT1vN30YmIy++XODiYDWE+0Ee36PEyg OXyUSQBXcp96F1d+QekLOpgEnIoAGpJof/6XXN9a+tGTSfs+HlVXPDgX21VFoG0zAc614dPfRWv2 F1vqZB6zm7Kefs1H5DoG/lWrj9A6NRUKm4lTwPzrGB7j8XPBKMfbgQZH3D2jt9qDxzFAcA7ndyOh dGusDOsuyq8jJyBu3W1us2HggEWs1HHHwW76fVP+5FH/AGw//wBLo9NNNFYqorbVWOGMAa0T5BTU c5mUifs8AvhERAH2+bV9Pqn/AHIo/wC2H/8ApdL0+qf9yKP+2H/+l1aSTVzV9Pqn/cij/th//pdL 0+qf9yKP+2H/APpdWkklNX0+qf8Acij/ALYf/wCl0vT6p/3Io/7Yf/6XVpJJTV9Pqn/cij/th/8A 6XS9Pqn/AHIo/wC2H/8ApdWkklNX0+qf9yKP+2H/APpdEpbmNcftFtdjY0DK3MM/F1j0ZJJSkkkk lKSSSSUpJJJJSkPIsNVFloG41sc4N8YEwiJiARB1B5CBujWhSNxbx+A/MqxPq/1r7XkWZHVbKxnV 2WvfS9uVW63aylzjXX6bgNuxo00PJXYrHwvqxiYl2O77RkX4+C5zsHEtNZqoLpb7NlbXu2tcWt3u dAWwnGta0Fkgdh2R/Cj4nu5vU82kVivbbubfRJFNpb7bqyYdsg8aRyqnX/rE/p+Gy7DrJsdYGH16 bWN2lrjy4M108VsZNHr1hk7YfXZMT/NvbZHz2oef07D6jS2jMr9Wtrg8N3Ob7gCJlhB4KbK6Nbr8 ZiJxMxxRB1Dz3RvrfmZQtGVhWZBZt2nCqLondO/c/TjRaI+srS4sHTOobwAS30BIBmDG/vBVvp/R um9Nc9+FUajYAH+97pA40e4qy2jblWZE/wA4xle2ONhsdM+e9KIoDisnwP8AYuyzgZk44AQ0oG7/ AALyPUvrr1KnNsqoxm01s2wzJrcLdWg+4CyO+nktGv61ZH2Wu9/S8pwNYfZY1hFfElzXa+1aGX9X OjZuQ/Jycf1LrI3u32NmAGjRrgOArLsGr9nuwKf0dRqNLOXbWlu0fSMmPihEEE2bHRfkyYTCAhjq QHrP8NXBz/rL1M4eQ1nScqia3gXkPbs0Pvn09NvPK57pHW+rs6hU71sjM+l+r7n27va78zdrHK9F uprvpfTaN1drSx7dRLXCCNFn4v1b6LiZDMnGx/TurMseH2GJEd3QkY2QbquycfMQhCcfbsyG9uaf rF1QuDPseQx5Bc1pw3OJAif+1LOJCwfrRn5uYcb7VTbSGb9nq0mkGdkxL3zx8l3zqN2VXkT/ADbH 17Y53mt0z5bEHP6VgdRDBmV+qK5LBuc2J5+g4eCJhGQomQvrv+GizFzBxzExCBrp8p/xtfyeP+rX U+oYmFZXjUXXVm0umvHN7Z2s03Ntrg6LWb9Z+rES3pV94BIkVPZq07SNPU7rcwenYfT6nVYdfp1u duLdznaxE+8nwRMaj0Kyyd0vssmI/nHusj5bkhGMRQJNdT/BU8/uSMpQiL6Df/GfPP8And9YeftX y9Ov/wAguit+sXV9knDyKZIA/VXHVx2gb3Xdz/JV9/1U+r73uecQS4kmHvaJPgGuAC0b8cXVNr3b Q19b55/m3tsj57UIwreRl+H8V+bmISr28UYVe4/hTw3Wr+sZ+LF+LltbU/1CbWewABwn2V1gc95+ KD9VrBjdQfkWYluY1lZDRRX6rmvLmkO1iNAdV3+Vi0ZlDsbIbvqfG5slswZ5aQeyrYPROmdPuN2H T6Vjm7Sd73aEgxDnEdlII4NzGXF010+rCeZ5jh9uMoiB3qNH6NUfWRpcWDpufvABLfQ1AMwY394K q9S+t32ZjAzCyKbXOBjJr9MFgPv2+469lvNo25VmRP8AOMZXtjjYbHTPnvVXO6J0zqFwuzKfVsa3 aDve3QEmIa4Dunwliv1QNeBYJRyV6Za+IarPrKyxgfX07Pexwlrm0SCD3BD0mfWRr2h7Om57mOAL XCiQQeCDvWni4tGHQ3Gx27KmTtbJdEmeXEnuljY4oxasbduFVba93E7RtnyQMoXpDTzSBOtZfg4F P1yZZn2UfZL3VQBVWxgN28fT3M3f6wrh+sjWlod03PBeYaDRyYLoHv8AAItP1a6JRcy+rHLba3B7 HepYYIMg6vV+6j1bKHzHoPNkRzLH1x/00ZyxacMDt1NIjHJ+lIfRx8r60sx6H2O6fmVEAhjrqtjN 35oc7d4qHT/rX9oxWOdg5V1rRttdj1b693kdy187p2H1CptWZX6lbXbg3c5usRPsI8VHA6VgdODx h1ekLY3jc507Zj6bj4pcWLh+Q8V99FcOTi+YcLRH1ka4uDem55LDDgKODAdB9/gVTzPrkyjKpr+y 31MBJyGXMDLNpHt2Dd89V0FNHpWXvmfXeLIjiGMrj/oKlk/V3o+Xe/IyKDZbYZc71LBMCOA8BKEs V+qBrwNqlHJXpkPqgd9ZWMYXv6dntY0FznGiAANSSd6d31ka1pc7pvUGtaJJNEAAf2lo24jH4L8J hLGOqNLTq4gFuwcmTHxU76Ksil9Fw3V2Ate0EiQeRLSChxQv5NPNNT/e/B57A+uAyLbmOxL7juLq W47A9wr4943cq4frI0ODD03P3kEhvoakCJMb+0hWMPoHScK9uRi0ena2QHb3nkQdHOIVx1G7KryJ /m2Pr2xzvNbpny2Izliv0wNeJpEY5K9Uhfg4XU/rYcfHPp4eTRe/Sp2TVsZoRu/O10R6PrRXfU22 vp+dYx3Dq6Q5pI0MODtdVez+j9O6i5jsyo2msEM972xPOjHBFwsHFwKfQxWenVJdt3OdqfNxJSMs XCKgeLz0Vw5OI+ocLm/85dwmrpme8SQT6OktO0jRx4IhUP8Anmf2j6X2W30o9M0bR63q7vCflC6T Go9CssndL7LJiP5x7rI+W5Uj9XejG31jjD1N2/dufO6Zn6SUJYteKB8KKpRyacMvtazvrM9gl/S8 1oJAk1Rq47QPmSh5H1qsorNr+l5bGNGr7WFjQToJMFbWTR69YZO2H12TE/zb22R89qbKxMbMq9HJ rFtcg7XcSEBLHesNPMpMZ1pL8HnOm/W7Mux9pwbczIr+m+ke3UnbIa0xojn60dQ3FjejZJsaAS07 gQDME/ozzBWxidMwMJ7n4tDaXOEOLe4RW0bcqzIn+cYyvbHGw2OmfPenSnis1j08SUCGStZ/g8l1 D64dRa+qsYbsKyt4ssZYSS9v7pDmNgFWD9autuq9dnSneht3eoQ8t287t20CF0duDhXPNluPVY88 uexrjp5kJX4ldmHbiVgVMsrdWNoENDgRo0R4pHJjoVjF+JKBCdm5n7Hmn/WH61RI6bsaB7nOqtMe f0ln4vVvrI7LtdWXMflEF26pzmgtEDa0NeRppwu8SSGaIBHtx1UcRJHrlo8iT9Y7Xiu/qTq3OBIb XjXTAiSIx2HSVWz+j9StY0fbcnL3T6jbaclrRERA2Pldk6jdlV5E/wA2x9e2Od5rdM+WxFQGeYNg RHlEJOKJGpJ+peQ6N0Pp1NbndTxrLrg72EVZBbtju30wOVv42Z02qvbi02MrBIivGtAlp2ke2vsV oIWNR6FZZO6X2WTEfzj3WR8tybPJKZuR+nRdGEYigGuc3CJk02knk/Zrv/Sad3VMRglwuaJABNFw 1cdoH833JVxCyaPXrDJ2w+uyYn+be2yPntTFzVyMrAyaXUZFN1lT43MOPfBgyP8ABoOLX0XDsNuL i21WEbS5uPfMHt/N+S1UkeIgUCa7IoXdatMdUxC4sAu3gAlvoXSAZgx6feCpftLH/cv/APYe/wD9 JoraNuVZkT/OMZXtjjYbHTPnvRUEtX9pY/7l/wD7D3/+k1FnVMR7Q9gucxwBa4UXEEHgg+mriFi0 fZ8WnHnd6LG17oidoDZhJSL9pY/7l/8A7D3/APpNRPVMRpaHC4F5hoNF2pgugfo/AK4hXUerZQ+Y 9B5siOZY+uP+mkpF+0sf9y//ANh7/wD0ml+0sf8Acv8A/Ye//wBJq0kkppjqmI4uDRcSww4Ci7Qw HQf0fgVL9pY/7l//ALD3/wDpNFpo9Ky98z67xZEcQxlcf9BFSU039UxGNL3i5rGglzjRcAAOST6a l+0sf9y//wBh7/8A0mi5VH2jFux52+sx1e6JjcC2YRUlNX9pY/7l/wD7D3/+k1KnOout9Ju9thaX BtldlcgEAkeo1sxuCsITqN2VXkT/ADbH17Y53mt0z5bElJUkkklKSSSSUpJJJJSkkkklKSSSSUpJ JJJSkkkklOTd9aOjVZl2C2y3IycaPtFeLj35Pp7pgWHGqsDTpwSrnTep4HVMRmb0+9uRj2fRezx7 hwMFpHcHULPb0frGHk5Dul9RqqxMh7rvsuVjeuK7bHOssdXZVfjuh5dMO3R2VnonSrem0WjJynZ2 Zk2etlZLmNr3v2trG2uv2tAawCEhtr2/FR307/g6KDl5WPhYtuXku9OihjrLXwTDWiXGGgk/JD6l 07E6pgXdPzWCzHyG7HtMfEETOoOoWZf9SfqvdhPxD03FY59ZrOTXj0MuBI2+o1zagA7voEkitPxd wEEAjgrP6n9YOkdJtZTn3muyxjrQ1tdlm2thAdZZ6THbGDd9J0BaAEAAdtFTHTtvWT1RtkepjjGt qLZnY82Vua+dI3ukRrp4JdR21/JA2130SM6jg2XUU1XNsflVOyKCz3NfU0sBe17ZbH6RvdWVjYn1 apwut/tLFudXi+lbW3p+0emyy59b7LKj+aHenq3iZOkmdlLoO+v5q6uPd9cfqpRW6x/WMIhnIZfW 93yYxxcfkFpYuXiZtDcnDuryaHzsuqcHsMGDDmkgwQsLqv1azfsN2H0TIZVjZPtswckudSwEgl2O 4bnVR+5BZ4BvK6NLorq5/Ves09MdSx1F+Vdfvc2nGaHvFdQ3WWEOc32tkcakkAAlVsH61dNz8yvH x2XOoyHPrxc8sH2a6ypu+xlb926QJ5aAdpgmEbq/S8vMsoyMDM+w5VAsr9U1C4Gu4APG0ubDg5rX NM8jUFVOn/VizBycRrc59vTOnufZiYb2A2NssYa5fful7Wh79o2j6XJgJDxUdtHeVC3rnTKcc5Dr S6sXOxgGV2WPdcwlrq6662Oe8gtP0QeCr6wsz6vZxyarum51eNXTkvzG1X45vDbbGvZYGFl1BDH+ o5xBkydCOEuqun8u38adXCz8XPp9fFeXMDixwc11b2uby19dga9jh4OEp83NxcDEtzcywU41DS+2 x3AaPhqfgFS6JTVS7Ob9o+1ZrsndnvDDUwXGqqGsYd0NFeyPc7zMpfWZmI7oeS7MyBh0VBlxyHN3 hjqnttYSwQX+5o9o54SPTyH4qG9eK9H1k6LkYuVlV5EV4LS/LY9ljLamxvl9D2tsEgSPbr2WkCCA RwVxv1jz/qt1vH9EdSdg572Ox/tTaLd1TLXei+rLY5g9Nj3H6NpbrBGuq7Jo2tA8BCPS/ort+P7G nm9b6L0+0U9Qz8bEtc3e2u+6utxbMbgHuBiQh9O+sPQuqXWUdOz6Mq6qd9dVjXOgRLgAdW+4e4aI HVKen25b7W5bun9Sw8f1nZTJAbQS+PXDv0dlctd7Xcalu06qr9Ucv1G5jMixpzMi92XtFN+OHVPa yttjK8utjoO3WNwHG4oR1vyJ/HRUtK8wPw/3nolz4+ufT3bGsxsp9uS6On0hjd2W3cWmzHmwN2Db uJeWw2CdCJ6BcP06rByM6jGw+vTl4HqU9Ga7Gcyr02PLb6/eWNy4aAwmtwgCdDql1pXQl67pvUKO pYVeZjhzWWSCyxu17HNJY9j2nhzXAgomRl4+M6llz9rsmz0aRBO55a58aA/mtJVL6u1UU9LZVTkH Mc2y4X5Lm7C+/wBV/wBods/N/S7oAU+rsxrTiU2Xuxsp984NrW7iLmMe8iCCINYeHTGncGEjvp3/ AAV38L/Dv+1ZvX+lOzPsYtd6nqGj1DVaKTaOahkFnol86bd0zpytFcXhfZ3ZrejZfV6bqmZ7rjVR h20NdlNs+1/ZxlWW21Ha8yWD39pXaJdAe/8ABR3I7OXnfWbofT8w4eZlCm5oY6wljzXWLCW1+tcG muvcRpvcFeZmY1mVZhsfN9LGW2Mg6MsLwwzEaljlWx+lspzuoZDnCynqPpusocwGHMZ6LpdPua5r W6R4+KodE6TidM6zn14+W+0Oox/TwntP6vSHXljWWfnMLi7a380COISHj/LwUepHg7dttVNT7rnt rqraX2WPIa1rWiS5xOgACyrPrj9U6g0u6xhHc4MG2+t+rjAnY4wPEnQLUyG47se1uUGOx3McLhZB YWEe7fu0iOZXIYtuN1K/FxuidTF+Dj205rsPObc3IZTW7f6mNZc0WW1nj3AjweBDUhv4aX4DqVHa +uv29HsKbqr6mXUPbbVY0PrsYQ5rmkSHNcNCCqXVes09MdSx1F+Vdfvc2nGaHvFdQ3WWEOc32tkc akkAAlW8TKozMWrLxnb6MhjbKnwRLXDc0w4AjTxWP9ZTjVWYuS7rGP0XKaLa67cn0yH12BvqNa21 9fua4McDOhGoISOn9qgkwfrV03PzK8fHZc6jIc+vFzywfZrrKm77GVv3bpAnloB2mCYWyuO6GOhH quLgYP1gozcXpxdbhdODmPt9SytzSftAefVaxpsO1rZE6nQLsUT0U0LeudMpxzkOtLqxc7GAZXZY 91zCWurrrrY57yC0/RB4KPhZ+Ln0+vivLmBxY4Oa6t7XN5a+uwNexw8HCVyvWLsXEz2fY+omluNm G81np+RnVsyrmurdU23FLGt3+qSWOJduPbhb/QKaW412UzKbm25txuyLmN9NvqBraSxtUuLNgrDd riXA86oDUX/K9FHQ0P5btzNzcXAxLc3MsFONQ0vtsdwGj4an4BU6PrJ0XIxcrKryIrwWl+Wx7LGW 1NjfL6HtbYJAke3Xsn+sOPj5HSL2ZOQ3ErZst+0PAc1jqnttYXNJbuG5o0nVYfXLegfWFr8NuVf0 zqPp+iMu3EvpAryJZ6Npyaq2OZafotLtXfR9wSG/8vtTppend60EEAjgp0zRtaB4CFy31qweg29T xb8p2P8AtN1fp1VZmOMnHfWH7Wi6WO9Eb7Ia8Ob7jru+il1A7lA213p6eu6m0vFT2vNbiywNIO1w AJa6ODrwprjvqGeiPyOoux8LGwuoevYWspY0fq8tqmi5tbPUp9St0FuniAV2BSOwPcAq6kdiR9jk n62dA2WvGVPovFRa2uwue5z3VN9FgZutBe0iaw4aHwWhhZuLn4tWZh2C7HvbursbwQfjqPMFcc7C yOn19N6lkZ/S6qOkA0dKfbbsqyGWS13qXPb+jf6TRGzdrJMjRdP9X8S3F6VU262u6651mTbZR/NF +Q917vSnlgL/AGnuEhsVHdvWXU1Fgse1hsdsrDiBucQTtbPJgIA6r0t2cenNzKDnN1OILGesBG7+ bndxrwq3XmUtxasy3Jpw3YFzb67skhtO6HVbXkubG5thaD2OuvCwMGq++yjpORkdMpNmYeq1/Z8s 35L2uuOW0V1uppkHj1J+j2SGprx/l+1R0F/y6/2fa9kqw6n012aenty6TnNG52KLG+sBG6TXO7gz wrK5HpFP1a6q/qnS334+VlM6hfkDYXV5db5B9Qb2se11ROxr2SIA17JDevAn8ldL8QHq2XU2OsZW 9r3VO2WtaQS10B210cGHAqayPq90vqXTxnHqV9eVblZPqsurBaXMbVVS02NiA8+nLtunh4K51Xpm J1bAt6fmN3UXAbgIkFpD2mHAtMOAMEEHuCEj08h/aob/AFbD7qWPZW97W2WkithIBcQNx2jvA1U1 xQ+qmLT1rpuLldL6bditdcftbKaKn2gVO2suxto3PB1muW94Zwu040CSmlm9a6ZgZNOLl3+ndka1 t2ucANzaw57mtLWAucGguIBOij0/r3Sep324+FkC22kFzhte0OaHOr31ue0Cxm5pG5kiVh/Wna3q f2VuTj0jrGKMPK9ZtjnV1C3aLW7GPrG713MHqFo3RqeFH6rWtyeqtqGVjW19HxHYmI2hljHW1utD DcfUrYzaPQa39EXN3TrwEo6/878P5BR0/D8f5F65VMjq/SsXGZl5Obj0Y1piu+y1jK3EyYa9zgDw rTiA0k8ASfguK6HfZmXYV/1du6f1TF6XRdjViy+3HvbXa5gZ6lP2e5zHN9GNx+nzAS60npb2ldld tbbK3B9bwHMe0yCDqCCOQVDKy8XDodk5d1ePRXG+61wYxsmBLnEAalVui9Pf03pzMWx7X2B1ljyw bWA22OtLGAzDW7oHkgddwm5junNL6d1ObXc2m90Nt2Nfua0QZc1pL2iOW/NLrXiAgdfAE/Y3mZ2C /HrymZFTsa0tFV7XtNbi87GBrwYO5xgI65PqXSsC3qrMTomdiY2S/Joyep9LL2y8U2V3m5tTDuZb DdTthwPu7FdYl0vx/BXWlJJJJKUkkkkpSSSSSlJJJJKUkkkkpSSSSSlJJJJKUkkkkpSSSSSlJJJJ KUkkkkpSSSSSlJJJJKUsb/mh9W3ZeVl3dPxsizMf6tgupqsh8Q4tLmbvdydefmtlJJTR6X0bp/SR kNwKm0VZVvrOpY1rK2u2MrhjWNaAIZPxUuq9P/aOC/F3+k4ursZZG4NfU9trCWyJG5gkSriSXbwr 8NlOXn9Ax8vH6lU1/p2dWY2vIsLQ6Gtb6ftHt/N8TytMAAADgaJ0klOR1voVnUWXnGyBi25WO7Ev L6/VrfU7dEsD63bmbnbSH9zIKlgdKzWZrM/qWWzKyKaXY9AppNDAx5Y57nNdbcXOca2/nAeS1Ukh p/L+XdR1/l/LsssrH+ruM3odXRsl3rVUCKLWj07GbXE0vY4E7bKxHvHfVayxMb6lfVbHa9p6Zi3B 9jrAbsel5bvO7Y13pztB4mfuS/l9ikv1Yxq8XpIoZlnPLb8n1Ml1fpF1hvsNgLOPa+Rpoeyj9ZW4 DMbHzMzNu6f9kva6i7Ha2yw22NdQ1ja30379wsOgZKudK6XidJwxhYY2UNfZYxkABvqvdaWtDQ0B oLoA8E3UunfbjiPbZ6VmFkMyWEt3g7Q5jmkSPpMe4A9jqkdx5j7Oqv3v8L63/FxqB0S7oeOzG6gb carqFT7brGTcch2SLfSsrrbV6T3WuAMsEA6hdMsbrH1ap6jl0ZlNzsO+u2mzJLGhzciuixtzK7W6 agt9ruW69jC2Uen+ET+A1V1+jznUOn/U1+X1DrXUqce04oZRnHIpZY0Pa1r2Eb63OL9tjQNh10Gp AR/q7jfVsZOZl9DrbjOeK6MrFZT9m2Or3vaXUOrre1zhZy4aiIU7vq1Vbm25P23JbVfkVZduGPQN TraRWGGXUG0D9E3h6u0YHpdTyuoF4ccmumoVhsbRSbDJO47iTZ4BAbfT+X42os+pY1GX07Kxch/p 0X02V2vkDax7S1zpOmgK5jK6z9Ws7o2Obc21rsXayjrdWHkV013NPomxlzqnUhjne1wL9pGhMLqs zFpzcS7DvBNORW6qwAwdrwWug/ArGd0n6ztw3YjeuVNqBMZLsJpyRWHTt3C4Uk7fbPo/KUDsb2Nf h49E9vAn8XT6NhtwekYWEy0ZDcaiupt4EB4Y0N3gAu555VL6y29Eoqx7upZD8PI9TZg34+85PqPg bamVNe6yTEsLXNOm4FXejNwmdIwm9PebMJtFYxnumXVho2OMhpkjyWZ9aX42M/CzPt7un57HurxX Modl+o122y6p2PW0vc0tq1LS0jxTpn1G/wB7fYojt9Gr9WuoCzrefVm5TH5t9dBprdRfh22VVCxv qGjKYzuYOwuHw4XUrmcQnOzum9Uzes052NY5w6ZRhY/pUuv9O7e97zbkPkV7xG5oEeK6ZI/j1QPD bd47Iv6fX1DI6VV1B92LTlNzcvDxsHIyrq7XW/adhycbexgNrJ2uZuiRK2/q8/ByKsrqOBltzMbq N5yGlg2hn6OussIJkO9kukAyeFj3dQwulZmY3D+s3Tsal1j7LcHMbXc6q5znvu2GrJx7Pc4/Rdug 8eC0/qmMN3T7MnH6m3rNuVZ6uVmsDGg27GNDfTq0rhjW+06+KEdv8H86/gmW/wBf5H8XQ6p09nUc J+I55qLix7LGgEtfW9ttboOhhzRosjqPSbR03q2V1fPr35OKKbMinHeyuqmr1H7hT61rnOBscZ3e EBX/AKyN6a/oeWzqlbrsR7Nj6mAOe5ziG1trB/PLyNvmuWy2fUZ2Jbg2dELLaqizqV1WHjNvwgT6 XrXOYNrSfpg1h2g3AbUhvSe3a3u2/REGdOVzX1kxXPz/AEWZeFjDrOOMC5uU/bdta8ndjVkEWu23 OG0xrtOvC6VoAaANQBosPqXRcXP6rlG91Dxk9P8AszmWQ62oeo9zbGsP5ridTI1aPkDvte+nfQ6f VEdt6+X8x+W7V+rlD7OoN/XMHJo6NjOwKG4Tw+yHvb7shgEVENpaNonXcfJdM4gNJPAEn4LnuiYf R39Rx8ro2TiX4+BhHBs+yva9xLnsez1BXIAGxxEmZJXQWNLmOaOXAgfNGd13NS366n891DfsNPpp t9Hi+h32Zl2Ff9Xbun9Uxel0XY1Ysvtx7212uYGepT9nucxzfRjcfp8wF1HRenv6b05mLY9r7A6y x5YNrAbbHWljAZhrd0DyWNg9G+r2fg4nTL7se/q/SKK6H34V23JofW30ztsqLbWDdOh08QtvpTDX hNqOa7qPpuez7S/YXna5zdrzUGtLmRtOnI11RPUXfY9wo/y8Cg63h15dnTQ59QdRmMuZTcQBYWMs kNEGXNBL26ct7crH/YvQmXnpeBkYbeoDqNfUbKWuY2+trHts2traXO+h7ewgrX63h2ZNvT34+XTh 5WPkGzH9es2tscaba3MDG20uJ2uLtHdllM6b08CnpFeZhXdZpzx1HI2ltdwLrfXte2ndbYCa3bNT 9HuhHceY/OOv0pUtv8H/AL7+L1K5W7F+quPiHpn1lysAZDci/KqFt7araxfe+9jq3udXYx0Eathd Uuexul9Z6Vn51vT8bAy6c6w3G659mNk7nOe4steyjIFrW7oZ9GBoknp9Q6PRMYY+EBX1CzqeNYd+ Nfc5trhW4CG+swD1BOocZPmUXqvTMTq2Bb0/MbuouA3ARILSHtMOBaYcAYIIPcEKh9VunP6fiZFN z8X7Q+82X42A3Zj0PLK/0VbCZEgB5mJLphXur49eT0zJpsyX4LDWScuuw1Oq2+71N7XNgNiTrwlL 7dAf5H9qBv8AX+Wjyzvqni4vUcM53Sumv6ZierZkdSFNFILPTcGjJpLWt3B2u5vt7wzhdoIgRx2h cvd0LoPUuhZDqeq22UvpfXZnN6hlXY7XBsPe5j8t7C0clrnfFdQ0Q0AGYA1RKPHvf02eZ+s9EZZa c3Bw6usYwwL/ALZYGWbWvJ3Y7He2x225w2mNdp14RukdMzsTqeNXnXYorwMN+L0+ugkW217699tl bmtDNrWViGSJJ1EgK5f0VmR1t+dkV05GLbh/ZH12jcW/pC8hrXNLS2wO939Ucql0voduJ1xt2LlV 3dJw6LsanGLi63HssdS807tZraK5aHatmOIgR6f4X7a/P8Uy6/4P7P4fg9BYJrcJiWkSeOFzDuk/ Vqv6v9Kd1rIxqbcbHqpxuq13ihwcK4Bx8oOrdB1IEwfBdO9u5jm8bgRPxXF9Jv6TiPxrc7qdGdX0 ak4GJXXhXMscbXNo31h1lxuLvRLJqbH0kO42uj9lp6fy6vWdNosowqqn5b8+ASzKs2b3sJlm41hr XQ2BMa8oHV+m5Wa/Duw8ivGvwbjcx1tRuY6a7KS0sbbSeLJ+khfVWuhnQ8f7NZXZjvNtlBpJNba7 LXvZW2WsI2NO2NoiIQfrbkdNp6fS3qHUX9KF2RWynIY+6sF+p2WOx31kMc0GZcAOZCdLf6oGx8js hs6BXi9Oxq7Lcf7S3qLM23Mc30Jssv3v9MONp3PDvSALtRpK6JYFn1a6Zm0Y9+HmZL2NtoyarXZm TlVPbVYy76FmQ6twcGwDrHK30ulf1jp9AP2K634ftJUkkkgpSSSSSlJJJJKUkkkkpSSSSSlJJJJK UkkkkpSSSSSlJJJJKUkkkkpSSSSSlJJJJKUkkkkpSSSSSlJJJJKUkkkkpSSSSSlJJJJKUkkkkpSS SSSlJJJJKYXU1ZFL6LmCyq1pZYxwkOa4Q4EeYWNjfUr6rY+KzGPTMS7Y3aLrcel1hHbc4ViSPHnx 1W4klX4qa/T8Krp+Bj4FBc6rFqZTWXwXFrGhomABOnghZXTvX6lhdQbZsfhi1jmFu4PZcGyAZG0h zGmfl3V1JImzfVTjX/Vql3W8bq2Nc7HbVa6/JxWtBrutNT6W29tj4s1cPpCJ4C2UkkldbcXqHQ8l rcm7ot4xrskO9fFu3OxbXPBl20a1PJM72cnVzXLR6ZjWYnTcTEsINmPTXU8t1BLGhpiY00VlJIaW O9fht+ajqb8/x/3mp1XAPUMCzFbaaLHbX1XAB2yytwsrftOh2vaDCxbfqn1C1uTu6q4P6n7eqkUj bZXIAbjtNh9GK5rmXaGTrqulSS8VLAAAAcBYnX+jZuY3Ls6eaXW52I7Bvrvc6sbffse2xjbCNvqO luz3eIhbiy+o9Dbn59OU/Kyaqq2Ortx6cjIpa+dWO/V7qoc09yDI+UA6pBrbw/AtfAxc39r05XUv suLkVYj6KcXFtdabGb63PsJsrpO1hAAaGmJ51W2snF+ruPidWq6jRfe706LaHVZF9+TPqOqfua7I ts2x6fAGvyWsUTqPt08yfzQBX4fk8jjYP1dp6IzHyOoYWNndHe5jep0XVh9Fznu2vsc6IdZ/hGO0 cZBlbX1YxMnE6PWzKtpyLrbLsg3YxJpcL7X3tczd2h/+0qn036o4mO3pT8iul1/SmWsDmsn1N5O2 wuIb7tS46H3E/FaHQemu6X0xmG7YNtlr2srnYxtlr7W1skDRodA0R7/yCjr9rDreHbkPwLaMunDy MbIL6DfWbWWOdVbV6ewW0kna8nR3ZZTOndOaKOkMzcK3rVWeOoZG0tqu3Ot+0WuZTutsk1nZqfo9 4W51TBsy2UWUOazJw7hkUGwFzC4NdW5rgCD7mPcJ7c6xCxcTonXH1sxMyrDx8dueeoG+m6y62fXO T6Ya/HpEknaX7vo9kI7jzB+wj+X0VLbvpX/S/j+L065t+F0JvUeoHM6zaXNIyLMYdRyKTjMIG7c2 vKaGskgiWiJ8IXSLnm/VLFt/pddLyzqVnUGWbNzniw79lkhsEGG99Gj4Bdf2/Uf76un12+hbf1ew MHFqysjp+X9txc+/167fVdkRFddJb677LHP1r5ny7KX1lwxm9FvxjZVXvNZH2h22pxbYxwrsOvts I2HTul0XCrxLup+m+oi/MdcaaTIrLq6tHjTa90byP5SP1nGqyum3MtubjNZtuF9kFlbqXNua94Lm gta5gJ1GiROgPhH8v2KG/wBT+bgfWjpfTrnXYvTc7D6Z1zqNPoPx7XtYMqt4NbRZU07nOb+Y8NkR HEhdW0Q0A9gAuNFGd1HC6taLel/s3qj91/Uact1wpbXVXS9wHoNYS0V7hNg2nuV2Q4EGfNHoFHcf V5r609K6FdmY+dmXYNWeW+jRV1JtVlN7WmfT23e4EF+jqyDrqHDRS+qvSMXp12U+/p2L0zqGTda+ mmn0i/7OBU0+m6sNca9+vA5EgFXLumY2T9YLci8Y+TU7BGPfj2w57Gusc4H0yCNlo3B0/ujntn9C wMc9abldK6jjZ3RsPHtoporsFtmO+51L/S3tLgawKvaHGW8cRAjp9RL6a/tr8VS1+hj9dP2W9OuR HQesYX2LMttwGN6Ax1WB6hc1llTz6b3X2uYTS70w0Dbu90kyDC69ebde6T9Wel0ZPT8Q9HyHPOwU 5L8SnNxnOIPttft9RoHawh/8p3CQ3/l/Lqr9Evc9DwMjA6ayjKcx+S99l2QagRX6l9jrntr3a7QX wJUOsUNN2Bn23VUY3Tr35GRZc7Y0MNFtP0jpzYOSFdxMXDxMdlGFTXj4zZNdVLWsYNx3Ha1gA1Jl UPrFj+pi05fqU1/s69uXGU706HbA5sWWQ7ZG7cHQYIGiROt+P2KGt9bEvrf8XOwMD6s5HUPtH1Z6 lVjZDXC3Kx+n31vptbLWu9bGBfWJGm9oDp7rplyGF9l6rY92Nn9Ot6o/Pq6h6OJktv8ARrqFVNux zWNe4vrYQZaB7oXXo9B+X0H+8rqVJJJIKUkkkkpSSSSSlJJJJKUkkkkpSSSSSlJJJJKUkkkkpSSS SSlJJJJKUkkkkpSSSSSlJJJJKUkkkkpSSSSSlJJJJKUkkkkpSSSSSlJJJJKUkkkkpSSSSSlJJJJK UkkkkpSSSSSlJJJJKUkkkkpSSSSSlJJJJKUkkkkpSSSSSlLG/wCbVL8vKyL8zNsZkP8AUqqZmZdQ qke5rfSyGt2zqBtEfCI2UklOd0fo1fSjmCq2y1mXf649V77Ht/R11bTbc+x7/wCbmSfJL6wdNs6p 0m/Cq2b7CxwbbPpv9N7bPTs2gna/btOnBWikl28K/DZTzv1i+q783GyrOjOqweoZdRoyCQRTfW5p ZtuDB9Jk+x8SOOCQuhaIaAewATpJK7eDg9X+r2fnZObZjZtWPT1HFZh5NdlDrXbGG3Wt7ciqCRae WlW6+kNp6zTm49dVNFWG7Fc1g2ud72OqaWhsbaw07de/C00khp+P4iv2qOu/8qr+AUuXw+jdf6V0 /J6Vh4fS8rHs3Cu+51lBsDmBu7LpZRcLXn847xuHguoWJjfVXHra8ZGZnZBNjnVu+3ZrCGOMtY7b kwdvEgDRLv4ik3+bY+rmG3B6RVituqvNbrd7scRS15se59Vbdztra3HYBOkKv9bsKrK6ULLbsSlu JYLx+0QHYb3AOrazIBc32kv0PYwdeFc6L0tvScH7E2x1zRbdYHvLi6LrX2w5z3Pc4jfEk68qHWum WdQGEWCtwxMuvJfVbOx7WBzTwHat3bm6fSA+KR1I8xr213+iBpf+F9f99x8irqHWLOm5uSOlY2BR cy2vOpvdlWud6jNleNa6mhrBaW7HaukGIXVLneqfVex2RXd0d9eJVblUZHUcVwIqt9K1lxtYGfQt 9kExDvzuAR0SPT/COn2aq/gFJJJIKUkkkkpSSSSSlJJJJKUkkkkpSSSSSlJJJJKUkkkkpSSSSSlJ JJJKUkkkkpSSSSSlJJJJKUkkkkpSSSSSlLNwvrH0bPtzacXJD39NJGYC17Nm0uadXtbuEsOrZWkv PbPqh191rvQrFVfUczLx+pkvZP2C+4XssbD/AKUBwA1Pu4S1uu4Ovj0TpV+I+zq9r0nrHTus4Yze m2+vjlxZvLHs9zeRtsa134K6vOb/AKn9XsLa8nFut6d9qz3nExjhuePXeDRcG5u6r6EjkPb27rTy Pq/1NnWem5WJi2ZIqx6se6/PdRaa62NdL22g+tVkAnV1Ycx0z2S6A960+iO47X+BezSXnVP1a67X 00YB6Ux2C3Ka4g1dPdnPrFT/AH2eqX4r3NeQ31HDeRJhY32duHlYXTfrHWDZiU4VbqizHvvGy+1z WY3qZFbtrgWtf6VdkjTQ6IgagdzEfaNfsUdj5E/YafXlR6j1rp3TX115djhZcHOrrqrsueWs+m/Z Sx7g1s6uIhcz0H6tZuL9YHdQ6hVlnKF+Q8ZtbsMY9lVs+m20jbluAbADHSGkCNFofW7peVmGm/p+ Lku6jSx4xM7DvrodU8lp2XC57Q6pxAkQ7voh0ie+47K6kdti7WJnty7cittNtbcd7WC2xu2u0Oa1 ++l0nc33RPirS8+6n9Wut5Lc+vN6a3qH2/JxHXZFX2cvbXXQxmRZjjIsr2Oc5pYOCAZVln1Yy3fW T7dk42Y2pt2PZgW4zsINoprY1v2e11h9drWncHNqcWuB7ojevL8hf5o6X5mvyerzerYuFmYeHYHu vz3PbU1gBhtTDZY98kQ1o/EhV+mfWfovVbmUYV73WW1m6kWU3UiytpDXOrddWwPAJ/NlUOttdX9b Oi5Dh+iupzMVruwue1ljB8XNrdC53pf1M6lbi4uHl4l2E1mDkY3ULsm9l7HF8Op+ytbdca9lgDzA YNO6aDoSex/C/wCA+1cR+z8ev5/Y97mdQw8E44yrPTOXc3Ho0c7da8Etb7QYnadTorK8z6d0LP67 0nF+sGfhs6jm259FttUVuNmHjVnHLWHIcxsPdL4JErXf9Ws2z61WdRy6ct7PtFNuDk4rsMNqqY1r TTY66MhrQd25tR2uB8U6taPf8KH8Stv8vxs/weo6Z1XG6k3INAex2JfZi312ABzbKzrwSIcCHDyK urnfqoDbm9ezGfzGR1FzaT2d6NddNjh/baR8l0SHSJ7xiftFp6nwlIfYVJJJJKUkkkkpSSSSSlJJ JJKUkkkkpSSSSSlJJJJKUkkkkpSSSSSlJJJJKUkkkkpSSSSSlJJJJKUkkkkpSSSSSlJJJJKUkkkk pSSSSSlJJJJKUkkkkpSSSSSlJJJJKUkkkkpSSSSSlJJJJKUkkkkpSSSSSlJJJJKUkkkkpSSSSSlJ JJJKUkkkkpSSSSSlJJJJKUkkkkpSSSSSlJJJJKUkkkkpSSSSSlJJJJKUkkkkpSSSSSlJJJJKUkkk kpSSSSSlJJJJKUkkkkpSSSSSlJJJJKUkkkkpSSSSSlJJJJKf/9kKDWVuZHN0cmVhbQ1lbmRvYmoN MjQgMCBvYmoNPDwgL0ZpbHRlciAvRmxhdGVEZWNvZGUgL0xlbmd0aCA4MA0+Pg1zdHJlYW0KeJxT COQq5CpUsDBQAEEjIDI3UDAxUEjOVdCPyDRVcMlXCORyCuECcgxNFSwUQtK4DMFKDRWMDYAqTRVC crk0jEzMNUOyuFxDuAK5AMTJEQENZW5kc3RyZWFtDWVuZG9iag0yNSAwIG9iag08PCAvTGFzdENo YXIgMTMxIC9TdWJ0eXBlIC9UeXBlMSAvRm9udERlc2NyaXB0b3IgMTEwIDAgUiAvQmFzZUZvbnQg L0JOTElMSCtDYW1icmlhTWF0aCAvRW5jb2RpbmcgMTA0IDAgUiAvV2lkdGhzDVsgMTMyNiAzNTkg NTM5IDU5NyAzMTYgNzA4IDYyOCA2MjMgNTg3IDQ4MyA1MzYgNjMzIDYyNSA2MzAgNDYwIDczMiA2 OTIgNjIwIDY4OSAzMTcgNTgwIDMxNiA0OTYgNTQ3IDc0NyA3ODUgNzEyIDc3MSA2MDcgNTA3IDIy MCA3NDkgNTk1IDcyOCA2MzcgNjI1IDUyOSA2NzYgNDE1IDQxNSA1MzIgNzQ3IDIwNSA2NTggNjU4 IDY1OCA1NTQgNTU0IDU1NCA2NTggNjU4IDY1OCA2NTggNjU4IDY1OCA2NTggNjU4IDY1OCA3NDkg NzQ3IDc0OSA2NTggNjU4IDYyMyA2NTggNTYzIDY2MiA1NzUgNjU4IDYxMSA2ODcgMzI0IDY1OCA2 NTggNTM3IDgxNSA2ODEgNjUzIDU2OCA2NTggNjIxIDQ5NiA1OTMgNjQ4IDYwNCA2NTggNjU4IDY1 OCA2NTggNjU4IDY1OCA2NTggNjU4IDM3MSA2NTggNDg4IDU0NyA0NDEgNTU1IDQ4OCAzMDMgNDk0 IDU1MiAyNzggMjY2IDY1OCAyNzEgNjU4IDU1OCA1MzEgNTU2IDU0NyA2NTggNDMwIDMzOCA1NTIg NTA0IDc3NCA0ODMgNTA0IDY1OCAzODcgMzE2IDM4NyA2NTggNjU4IDY1OCA2NTggNjU4IDc1Mg1d IC9GaXJzdENoYXIgMiAvVHlwZSAvRm9udCAvVG9Vbmljb2RlIDk4IDAgUg0+Pg1lbmRvYmoNMjYg MCBvYmoNPDwgL0Nyb3BCb3gNWyAwIDAgNjEyIDc5Mg1dIC9CbGVlZEJveA1bIDAgMCA2MTIgNzky DV0gL01lZGlhQm94DVsgMCAwIDYxMiA3OTINXSAvUm90YXRlIDAgL1RyaW1Cb3gNWyAwIDAgNjEy IDc5Mg1dIC9UaHVtYiA2OCAwIFIgL1Jlc291cmNlcw08PCAvRm9udA08PCAvRjEgNjcgMCBSIC9G MiA3MiAwIFIgL0Y0IDU3IDAgUiAvRjUgNjIgMCBSIC9YaTE1IDExNyAwIFIgL0Y3IDU4IDAgUg0+ PiAvUHJvY1NldA1bIC9QREYgL1RleHQgL0ltYWdlQiAvSW1hZ2VDIC9JbWFnZUkNXSAvRXh0R1N0 YXRlDTw8IC9HUzEgNDIgMCBSIC9HUzIgNDcgMCBSDT4+IC9YT2JqZWN0DTw8IC9YaTUgMTIzIDAg Ug0+Pg0+PiAvQXJ0Qm94DVsgMCAwIDYxMiA3OTINXSAvUGFyZW50IDM3IDAgUiAvQ29udGVudHMN WyAyOSAwIFIgNjMgMCBSIDI0IDAgUg1dIC9UeXBlIC9QYWdlDT4+DWVuZG9iag0yNyAwIG9iag08 PCAvRmlsdGVyIC9GbGF0ZURlY29kZSAvTGVuZ3RoIDMzNg0+Pg1zdHJlYW0KSIm0UluVQkEMqwUs YKEWsICFWLgWsBALWMBCLGABC9lkPGz/eqZN85iZ1M5ghjOacbvdWcxyVrPuI3aAAQcauLPcIYYc auiuakcYcaSRgzTeMcYca+wCFzpYWc60e6eFXe5q1z2bDlhwoYXLIo/EkkstXVKZFVZcaeVwzOoa a661dilXQ0iHZWi5Cnop0MHKsiuofYqAAFdfzqYjQYGu3LDIowgJctSHVGZhwoJdM2pWtmNH9Lve VFLAQjosXat6ONiBDpbrXJ/Tp0S6RkZfzqaTKMfXyA2LPNKiXZubCjpbo13X6x26WjvcEKoQRSpp N5PyQIEL7UbUafROy0ksRkZfzqaT7fMbfPL2SdQnM59UfHz3cdbHOx93fPT7KPTR4MPSh4fPJR8s n2mf/na73e/3x+PxfD6v63q9Xu/3+/P5fL/f3+/nf6u/AQAQcatjDWVuZHN0cmVhbQ1lbmRvYmoN MjggMCBvYmoNPDwgL0ZpbHRlciAvRmxhdGVEZWNvZGUgL0xlbmd0aCA3ODczDT4+DXN0cmVhbQpI icxXS3MbuRG+81fgOFO1HA/ewHGt2KmkslnHlpNDKocxSUlT5kNLUtY6vz5fN0BqhqIhKrmkWMXB o79Go9/4bfLmj5+0uN1NpGjxk0I2Loi2Cd4YMVtN3nxcLLt9/21xtVlutv1qsd/2M7HtJ2+udk7M dpOWcbvZevL2GpPr7aRtWu3E9ePkzXsFhtc3E4mlkPjzyBrhpWykEteryT+rXR2q+0UtbcV/c9HX 0lVrsafPXT1VBhs6VqLGaMvzjilumV5saP2G/oRUgb9vv9cmVPt6GhJPOkLwdJPotGy9OkPqmPSn eipVJR5rrY4CgMt2IMtz4f4lrv88eXdNepjimtLiejNoQ4WoSB24sNHi+i/n1OFibGwM1iWNXOF8 26jqQz31+HzGWQ0usEvT+xr8FY6d6kDfuSDy6n6ZFzpIpfH9DvEByyhxWBbzRWY/6/NSJjlMvx0I BG6sIwabOoDTMu8vkgANpsz5fYInogNEXI2mizm4S4PR/iBHPnWWuN0dCR/qqcPg6bQ28WGRYBoG D9UNLUKNrGxpPOv6jIpDaFrvD063IdtCk7Dighxgy0O4+qa2cC2e7cjGYrAgeAX0Pi/M+b8nBmnh NtHVnsyg9JFMk8jK5mMW5Hkz2l/QX/+N9vsDB60rsSKK7ms6jjj+nf6hUvgEBp9r02bx+P+R5v1+ Rqg7Xj51x6OCdDyrIN3EEOGozrvGWoskwGq6IWZkQ7JDqH57gO0j3UqTIdklQPCdjhc9j284Jvc8 ftwk2a8ouj583onE6YGjl4fpv88qxvCWEcT6Lp+qZYr89VGKPisqRSAWv9Bw8yQq0z/x2Kbg9hQZ yWiafJ6in/6W2YjJMnzc0LlyFLdPQSzPRvFRg84iA2qlkwb7fFk6jXILp67VMTOJqw9Y/FwfpE45 5oEvLEjdoH5gylFS6onB8onLH9gzXDX9hMGMEtIgb80fmDJJcstS/ICEU9n2h8EVTTmRHVWAkZXS x6QC9vRuTf+Copx8nLyAVmsKvTAMlv0iBwa7ETt0jhnNCekQgd1yCmM1str3RLVKBH12lcQIZDmw WQZm13PorwWduhoE922ywZRdh47NbsNSYj5PHtPt2NmfqcglHbWtPihJxrKSjGqUVsonJT1Skk/X xGe5TAdhKJYkMAbdPH3Flzxfdol4zbkxZZTEwuDT1Irhz52Z5VNJJiVUcI1WwkQk4xz1z7OHybeT NlV2mSp7bDIfHjikbSOM98fS/p6iCvaGrTk2JRsWQrmmlmcD7Vxykq1pxnzfHoG/HTuXqWki7GAE y6udj5E6mFZ4UjaQUx9lAxfeLib/mKyp87HDzucAn47x3OhcfcqNzqerv3JJD+KRZJbU8LxGXGAU N0nnXEOiKbKRStQQ3A3BzyFE2EY3gqyLEDiJdq0JI8i8DImNtr71I8hjEaLhTlChHUH6MiQ2EXeR rxDMuEbiLnoE2Zch6DK8kWML3RUh1iKdaTdWsihDQiOtceoV13cSdcPbV1jSeSCMfIVYDirG39j2 n4oQNAQ6RjO+yXUREtB3BkqJQ8jHIiS21J2dCPauDEFT3Eo9NuTPJYhqdeOtt2Md/1KESAVDahku V7JCm+vjqYd9KUIU2f7UwxZlCDVqr3EXFBvI5dqxJWdlSGi0jCeWLAaLMgZyRT1W2KoIQU00+vSU Yt5TiK/o9DghbYsIB6dszYkhv5Yh/GQ4UdiT7f92rCEAH1+745qIUtF4JTQyqD3nPGeqq2yM8YYK xA/qrKe7C41+Abbx8oVS65vzVbZNJ5hzJ0i4sAko5ieHPIn+39fd/6Xecu08auV5MURGCEnmi5IO +qT0JBxCHso1ivKU8WNIOUtrUiG9By6HoDXUsg1jSLl6GIv+XMNQl59i0aTGdnzIbRnhG6NiGN/+ hYrT4ipocoeIcoF2yAYK3fErLo/OU7dxfJNiypGe1NX6sbcUE64MbeMllfTLLx/Qallrx6dsyhAk ChSPEeKmXAdVEy2c8hVyRTQ0UY6N8utLldPCx8Y3uS9DIootzHK5ihWeMa227SucmCqn8tqOrVIu 6cjFzrfSjSAfynUQfaZVTl6uY4VuFs2ZCa8QzCC8tJSv8HxlKbzGpi9XdPSyQfswhpQrpyV9Ba0u 92LlLCAmjvU1HUEaZLl49hmEDsJ49oKWOqlo/ZkW6vwLylKMWmtOoeXItni4amjlFPVC960gpg/x FFXUv6SeopVen6LKLxBvGmVa9exe5SSH9CPVmbPKT0p0LM4Y605RRSehLGSCa+0pqthhobNo8Lbw zzS/eykZ4QnnnqGGrdn53uoHHVVwDfogE5rwQjMVmlrKSvxf9EFPrdzzxsY3anif8gtP6yYqvD6G iHLAILep1qowRLzQ0Vh0tWYEmL/UnLigtRwiyh6IzGbV+IjyLRweXfDZkeVfCF68udAD+CHiWzlw VdNGO75GuTYj1L12anTGCy1D20Q8a+MQUW4ZgmmgWqMulwoREj2S5BDxp5camWBRM4eIYvnDO7NR Vo6u8bacB8ipYnv5NVSL7BtiHF3jSxGBl5BWwV7sVUrSvZU2F8eGUg4+Ag1f7IdKy0Z7VPEholhA lPYNcpAaKbdYPJRBTownZxQLh7LwdemdujhkuRmxYRQcxXqBDgwNNTqL8xY/Zn1pc9pXAQmX8746 /2ZERKOqUgo8tsFTdGF4BYKPodyv6Su+1KiKsDyvrrEa8Z3VSmP1Lk9X3TaPvu5ErUx112EeMP82 RItOPNZoixxauykYmGqOHbS+2JptmPJA3zZcfphnl4lvidgwn1VeSqB1Yn9bTx3tXmWeH9KFPteY uXEPRhUHj8yDpjzXEvRl+lxvZQ2oqQKhpaB+EA1CCp9NbdCEVg9rOshXc1FrVXX392l52UNLiKGq 26dvv8E+vmuWz6PUM13DGhOfSDO6uq5p7WOifMeTn9POL+nD1P0uTzoyBL7777WlhfseGtHV4eSl WKTR78ypqyl+qtX9kqnynshy3aSPOFGUQiQc1CPL+sEcLaWUOWZ2pJdQsWgqXzsk2RR8B6onGxPJ ZkzCAqnqYZdIxeohLSz3fVqZsvz7A6eQODF2kRZZMQqllvZ+qhUdJn4lrSm83mhxkSjWPFndpxPE Pi/vEumepRR5lsXoD0TJ15lBx4SZjte7B944Cnm4Gt/0IG2+Tzrme5bh1ACHkL7UT1FOnKYuMT+j TFutRW18dddDPsSJCdUdy7gjj/1ee6hhVutY3W1pdcMLjPs3AToa7WnE+A3h1z/VriX/I+ZzAog9 je8WtSN/JMJH3DVRI4sYMg2OyAetiLij4fbrrg5gdUMkWybnzVM1tKgTrAcZtbnQI4Nv8KpU6lC2 KVv8klLQW1I2Gttum9PFIuU0kXPbJu2vVnmwzttEDUfgCczN2SrtsC1PCO/TpOOTt/zfJbLlcpEH sET2ZVcdhOkOvNJ0l2S+SaLkAxO7RvycNpdDdv0Yz2vdgYLDwZGReH53VIDxLPhA76mmHDIlvaiS 4tHkFBXv4dz/obxqmtvGkeg9v4JHqsqiCQIgyOsm8VYOs5PdJDNbNZUDI9E2K7LklSl7nF+/rz9A kZIlJweJJIBuNBrdr19bGxQJ2r/vW64nVkGdDETDmgqOA4nWPRcMNlKGOD7jai4gNmVAsVKiALAq 0quEzsr51ypJABC03gAXG32JMqo46bViWU7FkCbvRBlqCEHknF1k0U7w6OI22rXcUdFhW1ifHCtu fsObJ2qYaI5HamTnvSE0efMs6vZ38EqTRakhl+PRaOFu5qUVxDi+HGtQpQDPZRIMXaEvrVwPLgeh CsPg8WsBAPE9/nFDFTyLFH4irOCVKxpbUYYnDAhrvqs1r9/NohBnuyhhfTvW8vYj/r9QHNfwKpKZ yijNiviSVfUk38SdvzNKof8ExrwXFMIMI8wtC8lOp2CzdmdRc++Vsq4zXzvwcPYKbf0CNBL28T/O A3hL+H0riE8mTSCVAPFluQs+zjta/HFmc/gCqz7R50JhFHsu6Q9Fx4q3BckZvhO2SdCX3k4nbe29 JO3pc1foDUIRvCbrtQZ7fLaLfohueT5K7La6APHgKGq5fgUKClkW02AxpHEzTdWYfW9V0UcZ/kKA Bj27CArdkF4/9KU5NGnDqbYW1P32PKPTpcl2n6cLLGTgOUjOI8eVRY3cYt8Byl7zXSgz741VoNut iQuybxYtDlnJWSvJd2ZbMIlp3zNxMex/p+OdPm9mQVCCCV6U6uP0hqfX+pVNg56tJoPrDGhA9vIL mtHMAZxx7Ny90CzOGVP0yMZLurjCcG29vDLSQEx1Wo9DwFE+8dTFhdor3biCpaZObwAEUs6YZyJR amSwGW38P5ga6iJBd5bMQ20oUbftmz/frN9cvn0ok7ef3uS836e3/2KaXiVPZC1gbjs66tHdIJrB 0Nkq7ZPeHzjpBRCoPTawdir397mOzOV5ViFtJhJnm1eX40atgafHIme7V2eKzIf84Dxnm1FnkM21 tfVEZH1WBLGU13k9Fbk5K0LF3ObeTETa8yLU81o7PX5yXgQ9ZA3cHktszko4lwVrq+m1XJ8XIYfl rvwFuxD8weZuusuH8yKgbMZOj/LbWYmyQFrW9dRf/zgvUmdFHvJfOUowWeWqfHqUb+dF4LAqePcL d1/R6XMbfiEoqxqG1VX9CwmGLAYUV+bnE8znJrMht9Pj350VwaPw9PKzKelR3EJw5dRh2/MiNRxG nG4s8v2sSIHTGxfCicv/97REXF4VL+I6lTbEDxhi+VL8XF45EVOhvYir0bxqeSmzI8i9vPJHgrCz qiaCR02fi6WYsIbNPt7fWkTKRM1/ZiX4ZYsKX1NfRGQTXAn/vYwtkz/5ueH/7fcXymhWhspNHHVU NGyOjIMCr4xx4LZE+SvEKqhIZKigb8sdE2ehzDx8Q6QvuWcCrHNzlXtmlne/GpgwDzCF5k8hgEKv dyzBeps9Nacm0Y8J+EpYOZbynI2WmBd7vlK8YFxZDvzZnCTQJZVn50OG1sT7mBNz7lMXxPLwaFc6 0MqAkLNyWNfrk3ooRzx3XnKXeqvruO0lfwnv3Cu4xi06vks3jN01a31btIlMXYM6QfwPIpklsJcf Scec0YHT0hrZOyrpd42+rTo17sdgbRwR5WsWzIj7kNbPh0YfxnWlYR38SYIpPnU+q41TftlrY0Y3 vaRA63ik29D7WsaxYbpCABryvAsUgYbtcByB/O6UYaa87AKUNBUJhJLnoNUoSRseBkPHBtuoyaIz oWClVu2lnWR+h9+Kv7YSttwkVjyXfCKp9+/o/4q6mItZkacvpaEJ8MJ5F1lQ4dpQnErYDc2sBPtu 351yfj3OYkbKKkqqZuhrk2vp1wpRYrNa0iXE3BoS7Lvkz5KTkjOMRSU/7+8PEpqbw34Yk4Zw2J8C B7DxFykozNeELX+UpjLuuhs++yGTl7zjUfY6DS9TmPCK8wCOVVkXMcBuueWCdj50zUmJFekTdVQF zAbDoFhBbtLBUArTQWRm8MUo50mk3erEg8gmqqNTlf0td2uZSZcYsgFDlMkF/mmTQbxd60ufLGT/ OCALo74btmaH3fFBseoyxk7ZjI2LS6dq9DRZ8kGHyYiEL9/oHjseI2eALuGLxgb7eN+L49JVaI6D kiiEmvoVBEXZ9VVdxoKyZTxh19KOS9QwOkSRizGoe2lSUNTQbFF8hYttSUtWq+TbrCCbW1mdAC9U Bz8IQ9HAxE++ibTfiEzSi9DtsL3o+O8M/UgRrVnrbMI4IEu2UwldmRHWYuGHfmSg6kTOSGDxysVO ng+JmrLf5ASAelBkdC6xRL3iXzRteVkVfgSnI9SCMYC5piO8Wu9hkxFOcJDR9W4Etzf8n1A2/0Er ftsD6hPh2mYPnN/5v9PEZ1lb6DLeHpeGBBiLJCvO+Z4RW4QWzzNv0jni0YhNLLreo3nXd4+kQU50 DA1eHVeUr5QeW1WZB8FRaHiiLPGcOl5j3+NM9IWMd/s5STnCJvpCclkENfmEBhN1OUs/zyxxFC7o dqS1Vw23GPA00TZAWco9+DZp1rpMNhBQEOFAa5GOXnLaM7kCHnjBrzgZ90FcFrzqKLhCZJ3o2F5y EqifDQFO9Ohp2D2fcbBMaqAHt2rlczv9TATCuZyMpuiT6yie+vkojxZH2y9tYH0gQsu6FkRs8dmo pD46XoRINsPHQgtYD6Lgac2a0dFGEY57PDfyiNslzb0M3CPasFG3kJ2bXp6drl/r+gdEMj4v4lF2 Mr2IPpHT66ojnwfNaJfXxU8wzlDUZQKymfm8IAG6A+xL2N8Rv6QEDVwV6H8lQ60UtTmP9fRR4cb4 QTEh4MYVopHHUiYvWeBOlOxkbCVKuvnM5lwoVVvQ6lPG/bgI5Qy9QaohGXkxE1zTT2Q1PdYquJDt p9o2dKeVnqv7obp1426YlcWXEh3NK/r5seUcHW3Aox1fW5H+UI/MT0Cwqd3r8CvXhWSuK2YnDL+R t1aKmAxZPUUZpSYGfidsXI8AWhCOgXPdzYgBEAleMFPd42AvoNrg0MTwBbp73izhtZIzipeEuc88 14+48h0KKLvNjsbdUdwad5pgVTZ3iXVF5kqwATkzG4F8SpUYM2WXvByDODa3hSzG5swveUFFVLxK P9KaL3TGRI9NoUpH+IC3y9/3jFpLnMQJUUXw2k5ZP81PtGVcWFLdu+IEJqugTbTrZrYQEn9YXAqn EeG9+4kUrq0pCEqz2gavlOcDU+JLSsb0dw5Wskl4+LfNDsYEbE4cm/1ITFsJMozseBT9Zp3Kgsi3 6Tx0DuZ6OKzS7c80fcvjrXYN/Ar5683wwdFpcSd39N7QrOh6Zo+KxsVY1ZxuA8t29AfTykKUbtUE uO6bGPiggYXJ5SmKY0JuXk2wKrfwJSDFmdL4UaxJUCWHVOdOWxW8dqP3nmm/wRhDf60RypqYVXR8 +8Jc6DQCaGgcKTcWs0r3kERFYbeGq0/aNSvZ5Z4TYDXK2+Pozzg0P49NPs68YmDVZ2KsMrbAW463 Olbqp1k8UeRluI8udqdg0wHnLvBqyfqvNHa/Xy0JvKEM29Mv3F01BiBBMganEUJ17Rii9pmaiGfJ Atmj58QTjzHOHziJ6rWJRzjixqXi8Ul3AIozG0xRij8IHQRSGWnaPaBUeo+Mo/zWCzY+7FmuomRJ EMUNnJx4xdY1pKMbs93+8FJfO7sbnf3wqErSgLOxBTh95grdoKsimb0mxTtKVGXVlP4RLYiCczRQ uq+4RtArTz8TfU8UkK4Vw7GYJRggcERI3PJoy1j+T4bSuWI+pT+rQnWr0k8C7rId91Fx+2Q5iDyy M+iT7WxnEcKQqclf5iviU/wXDeHvzcNMcW3JM6fwpdQShva0OtmfMr4UAWQ85FZ82Egt5Yu+u9sN Nfkoqz1Xleb/jFfbcuO4EX3XV+DRqoq5JIgL+ZiaTVLzMNnd8u5mq1zzwLFlWxnqEl3s8t/n9AUg Kcn2zJRFstFoNBqN06elJg9lTyr6STnjzGILT2eti6/VYXbhhc7/3FkX0SV4h1I09XZxf+y5m8iM m1hPK7Q0cJLK11/UrGalLP7GHPiVf98rfD+CSdZGY4MtShcbxeqVFKl7nDKi9sAH9qrHrkUYXNYM OTKqNYaS6B+s9zNH9p8Jg88rE+rMkY30rJ/KEqXHQVwwnGjiz1Yq1uaZ9VRjvLK4suOqvDk+siEZ 3x4HX085U3znsnJsPLo06126q5zX4oo5JQjxXYKwHe11yg6IsQ/SdAPHDIFK/q0l01eOzXzVZUwO i0y+RyzqOt0yWdnINRTbp/cuFXYX7Jt57HG7nQvAtWk00IUR3FIHwfePmHnfa6NBLK24QMzSVXfR fswk5AiQ9WVZt1oj/vzy5ZpO8puUA6ZdxFyZdu33dCrUJVHkfkFdoPL9IGUWPzuJCGHDilW2g5QV nhVjK8YL5heUvxzPz/Sqls1WKm7UyQ8EbqMlxHo3j2rmDm8LrFqIR58F5C/Ep/Iu9zL2g9y0sXCN 9dpyCogQ0gOXcLeQXiC0+N4TjDjpHVQDRxQ4gdFWcQpD4JDEILm029yGivY1mVErW/nagEoWTjEp D6qqOSzV4kqfacVvr9Rr4uWu05Gd+pBWe6XGj4+Ah9MCj0A79pgeg7+ysQ1Lt/y7oKMa2U3rZJdE eXBct3yWporwZVvVbx5DbZG8Fuu0oSqbhBH41rQoqCbxJ+cDgTfSV+CcAItFqmH+dVzsD2B8eP3l pgD5Y3Hg4lrjxleOhrYXzT/LY6km7+VzwaDEcNDQ2t08yMK0SKe6++80agm5SCmJX8RLmZJWW4iB vFqUMZqXdnNklU4qVy/beTvHY/kD3ZmGucSx1k2oc5Xi40zneycZllJ8yZdgPbkSRrP0RFXKseVZ Od3MvB0lL2f13VOnObXOi4iCJlHSpx6N0vJFxHmdfKEEkcnaOFMPOn2ZttRzpSfkGl853UTWvnxR Tlw7JVzR+Y/Rl8Netei9qli1EnaNEMBrpy90n7zCjcXbAh0Is2f2II2b9PmEo/CcqB7PZM1wx/ek X4us3emTN+3RH1HIAnKVvnod5PPxuAPN8JHGzCP89I5MrfWY8Zp8X6Z1XufsO6FzZHcucPvwNtFr 2yL6AEg+idatLSeMmCmwcuEwptnKjd+hxjYE+6NXpWqqom5ddIkdwzBu+KFjSktN5jV1bUqDEwWm FugbdzyjbpI7JQ6SsukN4XNLNBpsZ0yRlUc7btaO+Ou1kZWOq8mEGus8Daw7a7MD3EMemMebFY/z D7dq5w3bGa7YRGfaKrwP2lVoiyZaBRNKQ+IxC0leChaAtSq4rtNDQoAyruI04W5O0uOO80ZKJttZ E6PzxH+67ZbSjqR0J8s8qdOvA3+lsRP7Zrk2fFUsQXw1UtxxXeD+jb+PMpys9vo0N19+NXukN5nY J+XFSl8KrpZQ+/sFkK4zSPsPgulRAVybGognbVT4UsUraVdSiyPAxDUJ26oVlGsB5Zjn8jUetI76 7HX2cq2CR+mCHtIaLOxUa6VPNcZ4HBmQBn++Jz9u9aXW51epXTopmdzLp9lOjCx0E4vUox2mK99r rybXUMc2Y2G2lHhbTWXi5EjQ9/KJ+LZKZbNq2jexwFlfmcpFwH1VKxZwmaYo+yD0gNpeIqi/Mhj9 IayETgnQsOJfIrnmJU1JhNZMLUU+SO4Ur7lxEWTj6bSKmDIvGxre8STiHXSggUtbowz+Xro0Skt/ 9aKs/nyxN1Cy9Hrx30dJ9DCtqXAnvGsaxeqEblYhi78JmXZzuW0KWGt8HoxQiA5pQLwT28B+lzyl Y5hajiwx7hVz4v23SKr2ymLGV8E40u3mFcMgmzd/zYeV6FtZwgPpixtLRj+xzQDdLxU8KXOrDKAT vLS1AjCPPRD+H06i6Hz4mBSEOjSmwumUlkmEdh7EgWWVbi5tLoBDq4QEROCcqU8qRPs5WlfUHE+N HN5W7Ns9zneJC31FzaXcdC0gn4YYDNVpKcUhlSJ3XlwoQvxJJ/k3PgeufKK41IrUnCZVXcc3YU+i AAD2ZSgrZaTddzk6rvFVOIk3Lr4Z+d71F4LDHzk4zAaEO0BwHBJK3OcpfW9GZdYMrxsKnrxec5KO QycN2dWKpYflMz0WZ+xDqoBijvP+R/iHrwM+y6JtasomigtjI0rnnAqO4LtV0u2p9C12WuEKqbLt 1e84DamXjmaqAbPSIsygahNdtAykDWMsI4fjK5kb2DT+nGyyDdGWZnFYgWGrUxWzvjBf1+6TjgBd 8gTJSkrfJ+4nM4/ioOpcpJiV/fgCUoQbMP1gSVsCjCzfbjcDz2ROuWSO+WhomMcehEoxvk4paadQ HJEr2Fc1MrDK9BTZie9O8J03CWCWRfjyQP4nXr7wHxKqIIZCS53yaYLrVndcUi69m1WohRXhewRy 1m2IsuffqWy2fIUJ8hbyuZt+GkFXzqnRUJ2Hei7nLd9REk4/V0l3K88FDm4w9CBKqpukK1lZF12r 9C4ZELdWOmm9ZIuHExuAxZLUbnnU8m+giBJ20YCIIv9OZY2w86/zloeqlreagv+/WUAQfdk4tCxo E2sbarOaWaRT27YTaT+ShrrBQYk0GxgLn2b/ma1h3VqLc3RyetRgkR5SFv/Etrc1JtytZj99XlXR /LyZ/Yb/P33aB/PphogNmqyyiJF+fV2bm0//nlXmv7Sqy6v6Ut1ugUrZQa++DFJasKqz2y7vOwmf ZjcUEl/EkoZq9IZtCklbgT/FibQfSV3ELSlrsZ0MjIVDSAKosYbE1YWzcNcXoWzUdlOOQtKkkEDF ZpuBVcgpC1txIu1HUjKHW5ScsnlXSagbDhqLKiDrmpBtl6GZSPuR1LYBK3qxnQyMhcOG0faElANo G2nDiIFNtptmtOF2tOFWbUYE0WenvC6fpP1ISuacupoNjIWyYVQuSGrjca1CS4bRtRTBNVnSZ0mI VNMjJGnWuWSYlbZM6Ze2jNPgsDuciqzggF6yX1um/dJ45WG8xi3C/mACvZS5pvkNgH23gOu/zf4v wAAMbMouDWVuZHN0cmVhbQ1lbmRvYmoNMjkgMCBvYmoNPDwgL0ZpbHRlciAvRmxhdGVEZWNvZGUg L0xlbmd0aCAxMA0+Pg1zdHJlYW0KeJwr5AIAAO4AfA1lbmRzdHJlYW0NZW5kb2JqDTMwIDAgb2Jq DTw8IC9IZWlnaHQgOTYgL0JpdHNQZXJDb21wb25lbnQgOCAvU3VidHlwZSAvSW1hZ2UgL0xlbmd0 aCA0MiAvV2lkdGggMTUyIC9UeXBlIC9YT2JqZWN0IC9GaWx0ZXIgL0ZsYXRlRGVjb2RlIC9Db2xv clNwYWNlIDEyMiAwIFINPj4Nc3RyZWFtCmje7MExAQAAAMKg9U9tDQ+gAAAAAAAAAAAAAAAAAAC+ TAABBgA5AAABCg1lbmRzdHJlYW0NZW5kb2JqDTMxIDAgb2JqDTw8IC9Dcm9wQm94DVsgMCAwIDYx MiA3OTINXSAvQmxlZWRCb3gNWyAwIDAgNjEyIDc5Mg1dIC9NZWRpYUJveA1bIDAgMCA2MTIgNzky DV0gL1JvdGF0ZSAwIC9UcmltQm94DVsgMCAwIDYxMiA3OTINXSAvVGh1bWIgNzggMCBSIC9SZXNv dXJjZXMNPDwgL0ZvbnQNPDwgL0YxIDY3IDAgUiAvRjIgNzIgMCBSIC9GNCA1NyAwIFIgL1hpMTQg MTE3IDAgUiAvRjUgNjIgMCBSIC9GNiAyNSAwIFINPj4gL1Byb2NTZXQNWyAvUERGIC9UZXh0IC9J bWFnZUIgL0ltYWdlQyAvSW1hZ2VJDV0gL0V4dEdTdGF0ZQ08PCAvR1MzIDQyIDAgUiAvR1M1IDQ3 IDAgUg0+PiAvWE9iamVjdA08PCAvWGk0IDEyMyAwIFINPj4NPj4gL0FydEJveA1bIDAgMCA2MTIg NzkyDV0gL1BhcmVudCAzNyAwIFIgL0NvbnRlbnRzDVsgMzkgMCBSIDczIDAgUiAzNCAwIFINXSAv VHlwZSAvUGFnZQ0+Pg1lbmRvYmoNMzIgMCBvYmoNWyAvSW5kZXhlZCAvRGV2aWNlUkdCIDI1NSAy NyAwIFINXQ1lbmRvYmoNMzMgMCBvYmoNPDwgL0hlaWdodCA5OSAvQml0c1BlckNvbXBvbmVudCA4 IC9MZW5ndGggNzkzIC9XaWR0aCA3NiAvQ29sb3JTcGFjZSAzMiAwIFIgL0ZpbHRlciAvRmxhdGVE ZWNvZGUNPj4Nc3RyZWFtCkiJ7FexctswDFXHTPWUL/DmrdefaJZMVTukHqTrF2TpadPEjN66OZM3 eol/Ip2iLsHvlLJICQQBUrSbu/bOT0fKEmDgAQQpEuCCC/4rFFGICuDa2/GCydOxx0wmXjC9xz+k GJlwnMJwgwJ5doJYvrw3xNm5ULWq5MbzYgfMKNxFHSVtTXkZ1b/BirNVcy9lRHg1Ei8ps7166x7K tm1Rg8pXrdSd2HoFX51xNCEWcR2qY6zpv4+qutHAXLm8YqpVoP4T/dbA8hoESK1sV06Gx/Fg77cA 2y7kVVsrvxlebL6aLdWYeOmB0xZC+LweJ3YPnkbAi0NiHIFme1R9EniRwdHGd78ErTTDC1X1fF4a a2Dfoi2OF6MxAqk20DXmtus6LCO8fMdsfY34uicyeba6GctYXpuh/sjLuGWSWVgUrXmJ8wxbg29t Wzktn2X2qhktxZiMQ60iV6+APgSZps8DP0Yn0YjUTqWcM/K9Gzvw/SXX+xxefVdGZEzs6Af1fXPF zu7FwEvOZ5BTzOvl4NtSOQGCzckb8KJQmbYqkVdiGeR8f4fnq7/Eqy5YXtdHWaYt1T8SXgvbT7yo RT4O47u4IbwWG4CNG8cMHH1PvN4HvOJBUl5Dvq7dmw3Aqfky7VPZspfKjDG5/7JnjDnfophvRWOk JxkuXxg/IrIEkutqRu4j2lbqMsYo8EU7x2cOeBsZMSZ3Meisy5xtPVsz6ms+L4BX0OvlZ/qxgxP2 E8fe7HG+CLJg5LzHuO9XIsuIsQb8IYvtRtNQ4BnDu8QPjpc0rwNee/DhNtHw4uULcGlI+Tqg5/uA cxbE+npI1Bew9TWisffOjOUvGMdRmNncOI6wx77dzpPxfFhblte9uYbKMuN40CHnORh5taY0lua+ IrIIqVi+oN3r/W7VLt91xe1Sa8XF6FvlecU4z4RKyaSyHyaEp1+Z84XYbIw5Z4CZarMh2nIBIYIg OcQJ4LZZcnz55CdX4SpBbFHm/uQ7N08kBETFp3SqMwgM2S7J69STbLQSC9ZZ+CHNC1L2NVPzvK3O BRf8g/gzAP18rgUNZW5kc3RyZWFtDWVuZG9iag0zNCAwIG9iag08PCAvRmlsdGVyIC9GbGF0ZURl Y29kZSAvTGVuZ3RoIDgwDT4+DXN0cmVhbQp4nFMI5CrkKlSwMFAAQSMgMjdQMDFQSM5V0I/INFFw yVcI5HIK4QJyDE0ULBRC0rgMwUoNFYwNgCpNFUJyuTSMTMw0Q7K4XEO4ArkAxGUQ/g1lbmRzdHJl YW0NZW5kb2JqDTM1IDAgb2JqDTw8IC9IZWlnaHQgOTUgL0JpdHNQZXJDb21wb25lbnQgOCAvU3Vi dHlwZSAvSW1hZ2UgL0xlbmd0aCA0MCAvV2lkdGggMTUxIC9UeXBlIC9YT2JqZWN0IC9GaWx0ZXIg L0ZsYXRlRGVjb2RlIC9Db2xvclNwYWNlIDE1IDAgUg0+Pg1zdHJlYW0KaN7swTEBAAAAwqD1T20N D6AAAAAAAAAAAAAAAAAAgFsTYAA4CQABCg1lbmRzdHJlYW0NZW5kb2JqDTM2IDAgb2JqDTw8IC9D cm9wQm94DVsgMCAwIDYxMiA3OTINXSAvQmxlZWRCb3gNWyAwIDAgNjEyIDc5Mg1dIC9NZWRpYUJv eA1bIDAgMCA2MTIgNzkyDV0gL1JvdGF0ZSAwIC9UcmltQm94DVsgMCAwIDYxMiA3OTINXSAvVGh1 bWIgODggMCBSIC9SZXNvdXJjZXMNPDwgL1Byb2NTZXQNWyAvUERGIC9UZXh0IC9JbWFnZUIgL0lt YWdlQyAvSW1hZ2VJDV0gL0V4dEdTdGF0ZQ08PCAvR1MxIDQyIDAgUiAvR1MyIDQ3IDAgUg0+PiAv Rm9udA08PCAvRjEgNjcgMCBSIC9GMiA3MiAwIFIgL1hpMTMgMTE3IDAgUiAvRjUgNjIgMCBSIC9G NiAyNSAwIFIgL0Y0IDU3IDAgUg0+PiAvQ29sb3JTcGFjZQ08PCAvQ3M2IDEyNCAwIFINPj4gL1hP YmplY3QNPDwgL1hpMyAxMjMgMCBSDT4+DT4+IC9BcnRCb3gNWyAwIDAgNjEyIDc5Mg1dIC9QYXJl bnQgMzcgMCBSIC9Db250ZW50cw1bIDQ5IDAgUiA4MyAwIFIgNDQgMCBSDV0gL1R5cGUgL1BhZ2UN Pj4NZW5kb2JqDTM3IDAgb2JqDTw8IC9Db3VudCA4IC9UeXBlIC9QYWdlcyAvS2lkcw1bIDEyNyAw IFIgNDYgMCBSIDQxIDAgUiAzNiAwIFIgMzEgMCBSIDI2IDAgUiAyMSAwIFIgMTYgMCBSDV0NPj4N ZW5kb2JqDTM4IDAgb2JqDTw8IC9TdWJ0eXBlIC9UeXBlMUMgL0ZpbHRlciAvRmxhdGVEZWNvZGUg L0xlbmd0aCAxOTgxDT4+DXN0cmVhbQpo3sxWTYzcSBXuWZKZIopmBUpDYkd2LoC0IJD2kpUQlywb YBUtSPyIRUhsYCfKKDPRTE9P/7ttt+1ylbtcVbbbbvffdM9kMpPdIECR4LRacVjEigPisGdOnBAX pJW6l54VlLs30iKBuOKy6mDpe/Vefd/7nldy557JraysPHvjlVsv33zpiy/e3tr8aWEz+3R1Jl/M z65e/MzZzvwHV8+9/Y9b5//87N8/1bl6If507pmVlfX8V25+93vVnY1rL1x7fePOU6R4VnKfz93I fT13M/fN3Ldy3869mruQHXJvZeuZ65+4c6563lh7EbzwyS9d+Gxx8sHF/IcXZxsfXFw7e/7sL/nZ W9N/nr21dnP2tTzsW6mRGInWqQUgrJVpUTZMDxuqiVu4hVrIRg52EEQYY4SRh4Dntl1Hgm2XIMUl mGAFE+IR2SOkTWSfEp+rjAY0FKtDOz6gnYQk8unE1lI11YJKUTI8E5kKNl3LsR3xtlzgmgbWZGvV gtiFqutih5j+85dFeOIpInyber5HxQ4ob3O5ExLCVU58n0n0vT7p0TS4kgZJ1InjJOzyPuB9OjyQ hmgA+8qX53/MexwzRDF1fUgAgZDYsu14HlSh52IkHux6EHjQg7ZkE4e4CoG+SxFFDHMPeDzwQjnk y2OZ71NKfUY4IIwEoRR63OPK+vrt2TfeFkd51BNHYR+LozAiWJ6zaWl6d5X6hPgqFZvvEypWhm/z QAraGd5jYgmY5yNfADFB8vzu9EfT9seB9N+A4ceB4o4QeQr87aptI2irNkRWUzp7d61JrRAqMAxR KE/fWfWzaKqfpZIFZIQBwpe5BB5T1n84e276bv4UPXDGijMxh1pP61Xj/RCE+ztsS67VMKqrNdRw Nai5TceEhmNB13UhWlyk69nWQiXiIsVGsEhNVAY8X/Aos8DnkRrxmHeDbpDyAQd8MPLH8miAYVdN 3diOrKgVGKwJaNNv1KTNV9Y2t5Czo+44xVZFr+iNhlkBZhWWClKJVcKaEtYTLdVTY9A6cIAzmqAj +eQ4SI7UB8nh4GACfrImJOtjxccLRnnoRUJGTF7QKWQqGGHSV6e5fLlYqVcNYFQrcF/eLYeppjZ6 9uhISmmXxwpPwiiJkjANhhSwwYF/KP9pdf3aTPpbfkGDYEMUuuQBy66DnIwEyzZtw9YdTeSm1VFF rlRp2FAbYTMxe0bfGsJDACfo+FR6J/7N5JHyxuRR/4l8MEQwVXuw68S2uBIngAAGAeIyY5RTlXIS pUI7TPKY6A261ADOZM5c5rBWIBbXmcF02qTiJjWiyfd3YKugFsxSo1KuVhq75hYwtuCd16QNttm5 r3TudwvD8qA8bhybwHhwCh/L/T6hPbVPU9blqeAsDuIg5IwxTkW7L5aQUFuICLCnChLdcG/2/elB /pH70H6o2Mf6YeOgPir39xKQ7G0Hm/K9bcfYVXeN/Xq1VClpu61tYG7DzQ3pdX63s63E273CqHxQ PmycmsA8eRP+Up6MfTpSR3RIe0zkwjosYoHIwF+8IEuESsQXiYha24wt2oopghPPV4R/LPtxyQpG lmoj09VdXei3jgCqV3BJ3i2ysKpWo0Zi9PSeNYBjAMf48IE0/fVqFFIeqCGnnVSav/cgT0QmfBgM on7cjbtp3I9A2B+ysfzkkb43Vsd7nU3vNlj/zuzl2Y/zHLnUkedXVk1q+rpIVtdJUy4UXbukluyq 0Wg2NL1mlUGr7O4XpH1aDRpK0Ii0WNd1U7PqwKq7tbKkMS3UlajZNfuWabWs7LVbsOVkZm0AZHqm IdVYI2wooZY0B+bAmFjHQnTHb6BfyL96zKIT9SQ6TEa9YZoOogPQGbGDsXTgDu2+YvXMbjPW4kZU 4VVepvtkvsovV4nGzBAYEex0pdiPaKSwkIVB0LG7zkAocjjEI/n4iIUTdRKO4n6vn3aHInQ0ZocP pT7uCQ92e1ZX74I/rPKPlOtHiZR4HcSV+aX5S3lkOEZWiWnrIqKhobq8XYyGwmIG1tEjKfW7rKvQ bmbxYScWFg940qN9+c0jqzZQh7WouC01sWBTeTL/a941RSRxP5pTF9HqJbwnb2zzZF8tJcZgIoUk JIHih36QFcLD7IlEU0/Pu5dPvDEcmKBvRo2KZGATmso6nL06/Xn+MTqBhwo8bI2bA31YT8sxiMsF fl8u7jl6Ud3Ti9XiHpj217JZlQku8zwkvM/JJo7dtmTLaYuJ4whzFJPUw9jDwBMbkj68tiZMOxt1 Ymhkjcy8YDF02pEchW0xdALh0JlPL5VOCPWl6e/XDk8nk3Ef9MbjcCwPUuR0VWEVVmhEBm+yOmAN v1yQ5sl/jh5m0YP/Ev1/FV0oOM09tdDcKxV2wO/WRNdhsqhZNJmPhOXLBDpte1Gzq0JXlKk+rdlr Iyyd3fr/q/m56fG0lZ9emt4+T5nPqSSQiCjIX5LoWG1TtuyMRFGQtywIe4sNf25+/fIXptcXA5xc ye4hG8auQMrEsQXQtNqeLdiHHsIAYQ8hSaiDuso0P//Z/Or83nnkYjf7KH5UFIqXGQdRuyN3okXG jBAm/gKo/5Hn0fenNy6/P7+xnK1XFs4vIJR7gezxqB3LsQAKzyJcgBYjLiuJITHf2+3VaenS7CT/ LwEGABbdDS4KDWVuZHN0cmVhbQ1lbmRvYmoNMzkgMCBvYmoNPDwgL0ZpbHRlciAvRmxhdGVEZWNv ZGUgL0xlbmd0aCAxMA0+Pg1zdHJlYW0KeJwr5AIAAO4AfA1lbmRzdHJlYW0NZW5kb2JqDTQwIDAg b2JqDTw8IC9IZWlnaHQgMTE3IC9CaXRzUGVyQ29tcG9uZW50IDggL1N1YnR5cGUgL0ltYWdlIC9M ZW5ndGggNDUgL1dpZHRoIDE3MiAvVHlwZSAvWE9iamVjdCAvRmlsdGVyIC9GbGF0ZURlY29kZSAv Q29sb3JTcGFjZSA1IDAgUg0+Pg1zdHJlYW0KaN7swQEBAAAAgiD/r25IQAEAAAAAAAAAAAAAAAAA AAAAAADwbgIMAE6cAAEKDWVuZHN0cmVhbQ1lbmRvYmoNNDEgMCBvYmoNPDwgL0Nyb3BCb3gNWyAw IDAgNjEyIDc5Mg1dIC9CbGVlZEJveA1bIDAgMCA2MTIgNzkyDV0gL01lZGlhQm94DVsgMCAwIDYx MiA3OTINXSAvUm90YXRlIDAgL1RyaW1Cb3gNWyAwIDAgNjEyIDc5Mg1dIC9UaHVtYiAxMTIgMCBS IC9SZXNvdXJjZXMNPDwgL1Byb2NTZXQNWyAvUERGIC9UZXh0IC9JbWFnZUIgL0ltYWdlQyAvSW1h Z2VJDV0gL0V4dEdTdGF0ZQ08PCAvR1M4IDIwIDAgUiAvR1MyIDQ3IDAgUiAvR1MxIDQyIDAgUg0+ PiAvRm9udA08PCAvRjEgNjcgMCBSIC9GMiA3MiAwIFIgL1hpMTIgMTE3IDAgUiAvRjQgNTcgMCBS IC9GNSA2MiAwIFIgL0Y2IDI1IDAgUg0+PiAvQ29sb3JTcGFjZQ08PCAvQ3M2IDEyNCAwIFINPj4g L1hPYmplY3QNPDwgL0ltNSAzNSAwIFIgL0ltNCAzMCAwIFIgL0ltMiA2MCAwIFIgL0ltMyA2NSAw IFIgL1hpMiAxMjMgMCBSIC9JbTEwIDcwIDAgUiAvSW0xMSA3NSAwIFIgL0ltMTIgODAgMCBSIC9J bTEzIDg1IDAgUiAvSW0xNCA5MCAwIFIgL0ltMTUgOTUgMCBSIC9JbTE2IDEwMCAwIFIgL0ltOSA1 NSAwIFIgL0ltOCA1MCAwIFIgL0ltNyA0NSAwIFIgL0ltNiA0MCAwIFINPj4NPj4gL0FydEJveA1b IDAgMCA2MTIgNzkyDV0gL1BhcmVudCAzNyAwIFIgL0NvbnRlbnRzDVsgNjkgMCBSIDEwNiAwIFIg NjQgMCBSDV0gL1R5cGUgL1BhZ2UNPj4NZW5kb2JqDTQyIDAgb2JqDTw8IC9TQSBmYWxzZSAvVHlw ZSAvRXh0R1N0YXRlIC9TTSAwLjAyDT4+DWVuZG9iag00MyAwIG9iag08PCAvRmlsdGVyIC9GbGF0 ZURlY29kZSAvTGVuZ3RoIDI3Mg0+Pg1zdHJlYW0KaN5UkU1PxCAQhu/8ijmu2QNtV1sPpIlZNenB j9jVOwvT2sRSQumh/94B6qokMA/MOwwz8GNz35jBA391k2rRQzcY7XCeFqcQztgPBvIC9KD8tour GqUFTsHtOnscG9NNIATjb+ScvVthdxfH/rHaZ1fAX5xGN5gedqf8/YMO2sXaLxzReMigrkFjx/jx SdpnOSLwP9G/rtNqEYq4z7dnTBpnKxU6aXoEUWQ1iOq2BjT6v49VKeLcqU/pWFJmGRkmrm8ik2Gi zCOTIT4kPgROmjJqMPEDcUhGTIZRzu32/CdXSi3KikRlUhInZfKFh4ZeXkpXi3PUldjwWHWodzB4 +RM72VBemOxbgAEAU5WGoAoNZW5kc3RyZWFtDWVuZG9iag00NCAwIG9iag08PCAvRmlsdGVyIC9G bGF0ZURlY29kZSAvTGVuZ3RoIDgwDT4+DXN0cmVhbQp4nFMI5CrkKlSwMFAAQSMgMjdQMDFQSM5V 0I/INFZwyVcI5HIK4QJyDI0VLBRC0rgMwUoNFYwNgCpNFUJyuTSMTEw1Q7K4XEO4ArkAxAEQ+w1l bmRzdHJlYW0NZW5kb2JqDTQ1IDAgb2JqDTw8IC9IZWlnaHQgOTMgL0JpdHNQZXJDb21wb25lbnQg OCAvU3VidHlwZSAvSW1hZ2UgL0xlbmd0aCA0MCAvV2lkdGggMTQ4IC9UeXBlIC9YT2JqZWN0IC9G aWx0ZXIgL0ZsYXRlRGVjb2RlIC9Db2xvclNwYWNlIDEyMiAwIFINPj4Nc3RyZWFtCmje7MExAQAA AMKg9U9tCj+gAAAAAAAAAAAAAAAAAHiZAAMANcQAAQoNZW5kc3RyZWFtDWVuZG9iag00NiAwIG9i ag08PCAvQ3JvcEJveA1bIDAgMCA2MTIgNzkyDV0gL0JsZWVkQm94DVsgMCAwIDYxMiA3OTINXSAv TWVkaWFCb3gNWyAwIDAgNjEyIDc5Mg1dIC9Sb3RhdGUgMCAvVHJpbUJveA1bIDAgMCA2MTIgNzky DV0gL1RodW1iIDExIDAgUiAvUmVzb3VyY2VzDTw8IC9Qcm9jU2V0DVsgL1BERiAvVGV4dCAvSW1h Z2VCIC9JbWFnZUMgL0ltYWdlSQ1dIC9FeHRHU3RhdGUNPDwgL0dTMyA0MiAwIFIgL0dTNSA0NyAw IFINPj4gL0ZvbnQNPDwgL0YxIDY3IDAgUiAvRjIgNzIgMCBSIC9YaTExIDExNyAwIFIgL0Y0IDU3 IDAgUiAvRjUgNjIgMCBSDT4+IC9Db2xvclNwYWNlDTw8IC9DczYgMTI0IDAgUg0+PiAvWE9iamVj dA08PCAvSW0xIDEgMCBSIC9YaTEgMTIzIDAgUg0+Pg0+PiAvQXJ0Qm94DVsgMCAwIDYxMiA3OTIN XSAvUGFyZW50IDM3IDAgUiAvQ29udGVudHMNWyA1OSAwIFIgNiAwIFIgNTQgMCBSDV0gL1R5cGUg L1BhZ2UNPj4NZW5kb2JqDTQ3IDAgb2JqDTw8IC9TQSB0cnVlIC9UeXBlIC9FeHRHU3RhdGUNPj4N ZW5kb2JqDTQ4IDAgb2JqDTw8IC9UeXBlIC9FbmNvZGluZyAvRGlmZmVyZW5jZXMNWyAzMiAvc3Bh Y2UgNjkgL0UgOTcgL2EgOTkgL2MgMTAxIC9lIDEwMyAvZyAvaCAxMTAgL24gMTIwIC94DV0NPj4N ZW5kb2JqDTQ5IDAgb2JqDTw8IC9GaWx0ZXIgL0ZsYXRlRGVjb2RlIC9MZW5ndGggMTANPj4Nc3Ry ZWFtCnicK+QCAADuAHwNZW5kc3RyZWFtDWVuZG9iag01MCAwIG9iag08PCAvSGVpZ2h0IDk2IC9C aXRzUGVyQ29tcG9uZW50IDggL1N1YnR5cGUgL0ltYWdlIC9MZW5ndGggNDAgL1dpZHRoIDE1MSAv VHlwZSAvWE9iamVjdCAvRmlsdGVyIC9GbGF0ZURlY29kZSAvQ29sb3JTcGFjZSAxMjIgMCBSDT4+ DXN0cmVhbQpo3uzBMQEAAADCoPVPbQZ/oAAAAAAAAAAAAAAAAAAAPhNgADigAAEKDWVuZHN0cmVh bQ1lbmRvYmoNNTEgMCBvYmoNPDwgL1N1YnR5cGUgL1R5cGUxQyAvRmlsdGVyIC9GbGF0ZURlY29k ZSAvTGVuZ3RoIDk0MTYNPj4Nc3RyZWFtCmjefHlnlCPlmW4PIE3h0BjbsqUqXAUGbLBZAw4sa2Mb MMyQPDNMDj2hp7O6FVqhFUuqUgVJjVJJKpVyTp27p7snZzKMhxx81gav1767Xod7fM76lGbV95z7 lQYW9uzee/RXVfWG532e5/2+dV3XXdO1bt26mx/e9NTjj2789vYRzYBx04Blq07Tq92y7e8eN/WO jfT9fHvnPy3kc4rWTZ/7yhrbfvE//v0/YjLx8zeI3/2C+NiN8Zu+/fUvdl2zbl33N+7esG27TT9w 8z039w8M/j9f17UO/LquX9f1+Wu6bry266uyrluu77pL1vV9WdfDqi6oq+sLXV1f6Vr3mZu77lh3 1zX3XHuf7MHrn5Rtk/Wqol1dj4CQu1RdSNeermTXv3aJ6+5ad/6aW64JXfvza3973fXX/aPMIftf cuP630Cj1z90/e8+U/zswc995nPvff5c9/03KG8ofWHLF35/Y/CLd3/p81+iv7zly5cU7FdGvvqd r55TDqk2qH4Lv3vTZ296/Wta9C70Q+yJm4dvueOW4tfHbr391sXbxm577/bT33jkG7//5tt3LN6x duemO3vv/G3rH658+StXZGv+/yNbn2n9TdEaWfv92oi8++Zuo6gUFP+Y/uepP6PTf1764NTrSxdP n3nxOJFVtlXf/tYdW26H9t5v/Ltb4QPRA8mDaGZr44kjD2VjysEPrG+9DIOn97dGFD9yfldzJzp2 58D9+zYMbN+7Z/OBhFMpqv74x7+8+Ffo9AeVP/w7fJw+5jqO2p/VX+p/x+5RLv59/meb4O6b2zde dzQzWy5PQeVmYqoBZ9kkmUATBBHBERfBkiTmIVk3DtMBOsiiAV+EjVFRKsIGfFCQDbAM7Gbcbhfq tFtwIwF1G0+IIYXlCZnIyQuXZN03n3pHIT3vgvGIO06iHl5gk0hKiMTjGM9HhBScZAUPj8ZJt/Q9 N+shsW7RceWzil0HDj2m/h6kfRB/8CH4p6ntzWF0uLFgX0VqpQhfwGazM43pI0unp54vXoaKlxOX LsHv4he18+i8bjjbi/QOODXDmPgAo0jbo+ND8PfNbdmhNobq7xvdPDAMuXA7bUEstljWiTmzdHUO fk34dfVPaP6dwouFk8WThel8GkoX8tE8Ush67Gmsu4VeuV/R/of9nE0WzqWCMSQR89FRjGNCHgKm J5lJBvV6XbQRbcvWUGKA0BNOFU2SFM5QPpt/fJK2KcWwPJIbC1ojHk5FcV5egFORcnwGFe9tHZd1 t74hKhUWOW0FsREQYTczeqT9I/nf/vCbD159a/VUczWzBPHVSK0Jr+Dz2iba1A6nepHBEbdpFBs1 GdX23iylPDa1WDqBzNaJiSJWnOB1I3Cv67ChH915f/vaNtR+oP1NyCZ+uL5b9Im/UzScBUvSCCWN nG4M7ieHrCPoiNVo1yJudzBMYO6QI2ZJTAhujglCIYoKeBA36aU8GEV5SQJ2Rd0pEsWL0/QKcvxo orSCrZRnpisrUHlFWFmGFz0z9hpqr40XRlIXS0vVch0qNRLNKXje3TSW0bJpLNGPjGlJqx4bt5p1 9oEcqzzemCktIuU8Zc9iGXtsYhwewTU6A9o/8rTxATeEr5/1T1ENB9Tduu0Kqthq3j68c//Ont5t Y09CY084H38M3p06UO9H++vL1vPI8xfqF89gZy5WL78Pn3Uua6fQKe1wuhcxa2nnMLZ86cSFc6vn Vi40nk1C+fV72F5K7YLa97ajinCCDwpIvUxO5LH8RFzbDz/ieEq9Hd0xOqwfQEwWvmDD7AVPfR6+ XP7g5F/QrJCK8SGoW7y+lVYU5MVmLp+JQdFMM3wMEe+Vt3+59u4RW2v9ldtl2fav13e39rQ2KypT wswCvOCc0dTRurY/2YPsPewYG8XUY47BQ7ApYuJNaMKU1zSHH1TvHtEPQ/ohfGgQPpQdnFWjo7PH HOeRF84UjixjK8uFE+fhKbrpnELxKdP06NyF/FKl0oTaA2cUnjxbKMHNeDmXR3O5cryJTFdIK8jK Gh9Xw8PkqFWPWvU6y7B7eNkwh9eh37UzirQmqtPBQ64xwzg6Pj7mGkSGtImiGTOXiOY8fExYqS6h 1SOLzdOFIwcbQ+kxkPjdGcXzpYvz50+cO7lycfoSNP1q+tIv4HP4Cd0R9Ii+L78L2bpTt303tnub 4fEfwweT/bURVF1bsp8GRBAIJbBEKMMVeF3P2OHh4eGhfs1BowHXkiM05Fh/JrIan0tC4r2AVbwE 4XchepPUAFvB0zwCv5N5deYCen56ob6ElAukNYdlLXH9EPyw6f7930HtbpwifYCSxI2tBxXkxyzE e1CST7ApJJWI8DzGxz9iIVJiIYn1cEJioa+3//afzEV8wlyJSJzH4nwk8QlzEZ8wl1HcAD51lTDB Yzz5Xz/VeSz16U91HmvftXZGsZArCjGulM3mhSIkFLliCVBxSqLiDjW63SzpwcjOm5kAE2IkKmai nk+omGFgwktSBEoRZueIBUzJiy2xtV/h3MmUySyeUCWcNs6MaEdw/QC2Z+jwvrEt0NgW584eeDim z02gE7kiWUZKtXi2iTWzR5ZOvQAxGp/RBk9w9iSBuoU8U0WOHU3WwaTX51ZrL0D155MvvAi/iD+n O49qLxxe3tGAGjs2pTYiP/zxRO/PsId7tz7d9xDU95Dlh/fBP8w9tPgYurjx7O7Lg9DgL96yvY/8 5Z8bF9/H3r944a3m7yGtfPB7Ox7bsB/av+HHpvuQDU9kpjdjW2Z6TqhfgtQvOV57F/5V7v2ld9Gl d88+9+oytPzqG4X3kBcuuAynsdOGpaF6D1Tfl9y9DX7avd24AzXt1PaPmCCjWus2IQQVjtIYHfXG eVgIZiJ5NFxInii9/Zy4S9lW9CsEF2efgNWeXtsulNTYNSbwM5stOOScsNBWxOnikoANk2y2CDfi S/mTaO3VmbOLS1CtWklWkWyKcQlAs6It5soPFWvY2sLQXp3a5lTZnGbKOMkC3t8NeN8awMOeqIqK SVHEgrFwHA3F+XS6cPlflOJWuefvfQM+k5dQsThQDQbyuOzsBOKWszaZmAKPywy2YITEiDAVpXnI G/XxSTgWyIaq6JnWaVm7e+0BRfuHcnGbmJaBUMQfXFEpqlkvHcdidIR0wy7WSI6gbWjtG66DpI5y qQDsaBfj8dqBNDEgRK/82dVQpI4txmaEWraeLZWzU1B2KjYzCzfJ+kQVnaiOFg6lL6VPlZrTUHM6 PbcEV6mKs4Q6SqbsqAAlx4a4fqTtkdM2WSTyDIeI3zUrwrk0oNJjMx5rEStYeUA6Bx2Dai2qVe9x bkQ8zmcCExgxqAikk4EE8uwyYapiVbMw2gfvtBzuG0PH+g44dyEWXTAyBAr8ypWHQIFxp4dkfJCP of0UQrlDURuW7huKjSIbNlr6N2KP9e/c0b8R6t9ofeRncE/iYOkwWuqdHls1QabVU8QF5KVzyfox 7Gh9eXXhOcgkH+tVjw1NQJbhw+R+ZPPe/NIANnDEevZV+JXky7WX0Zl3jj337Ao0c+xc5nmkVPDR OSzHpD0CIRBxnHNyzpAtaA3uUObkp8VRIOHrxLulwmd8ncKHSRds8xo9o1LhbycOEzoPrqI9HsrF flL4Wflrz0ZTx7ETqdXS0tSRqWY9X8lVs7PpFSi9El09Cp91nRw/hhqODc8eKkDFg4/z9yLtYTkD cME6FG9etA4uYouD+a0/gTe6NwPkG3eqe/s02okh5wHgIg7uY0EB8UCIwpgAG/JFIG94MhKGY5Fi YhYVb2uFZYFGOZBDJPx++8p6xbOLPiaNFakskXBCMXcYt8PkpMvvRHPyFfH7sjW99GVefhVbcTrs ccF2tpPi+rXb3b2klCLj8XwaW62o/BXx5zKbXLNtpL/fDJkGdhNPIZvlJmcwzGIUx3JRmA+nuBx6 SbTLfiGfKfi9gCu9MSbigTgqROCw02dnLGhB/ppIgffgQzaDFYdcFjV9EHlK/u5VzLd6rkCK41N+ XxLLsRmP4IYSnbl2Tdq9FlTq0I9ka0kp/Gpm0gf64+PYMANFmCDtgW2sgQQ5yNduc/cS+qs5fNQm Q8e6CXIuNxw0h4F183DeWAJOREqJGfRFcVD2O/lChSWSWJLgHBbY7XewUqiviwwIdaLfMm51Q26r hulHvi9/T8xIKLnyNACyBww6ALK3A2SaCHEOLDNwKNaDPLkJ123Beif6dUNDQ8NADHdBxt3u7Vvh Q/yh4iG0eGhm5KgeGj/6nOsNZKoZ4upYPbogHM+fFh9QCqvxGhePJXk+EYG4RD5URSJ5WbshZ62y pHy6xHpSEiMAy4p7rcCs7mv/REOaGadP5XM6Jh3IY3tKx4GdPO648BL8r7UPz76H/tulD0/+FTlz xG1oYg1DSjcKE5NWn7FT0IEO5I+3GgphOVHnU9FEIp7moEgiEywhgLPaqU65s1K541fLHe6UW4KM ugMZVy+p/++QEePycG40OBGmPi53KlKKN9GXxBGZ+LL86fZBlwS1j2mM6jwntSkGqFJ6ruOwWfBc MlLip1DxM627E0uJeiKjivJCPBPtxFhGOBBjTuLY/wESdtYAYN3Tvl/WflkOhH1zVeEJMWFvBGIj fi4Gx7kiP4eK61u3Csf5qVhSFU0m+HQMivCZYKHzZu5q9v7Om6PeT2VvuJr9be6+zp7AkASFA7DZ /PpOFiWQhQ4QiyekArTXKrTqiuePz1QjoWwiE89w6WghUg6Hc0rAA6xN8IPSMiqODQEDQPtoFtgb fMI2Zmy7248qz4g/EY7y9WhCxfF8PBX9KDypOcGro1z5FFtZAVuN/f/6IshjuaGg6eoYsHEwBlwR jMFl0S4i7aGMgXcEaVXYE/CQwIt4SA/qoRyM2S+J4AKYINmogUtaMatgaGpPtO8XOWW3uK9VELco bHKX2dTvMHpIld1uxS0U5NYNMD3IE3KLKxhhMfC1KKCJSD5eR4HR/lbyRLzOxVXxFB9PchCXLIam kRBIqiR1MxQG+lPNXKWoCKAoJxhvtcTCdxD9hJ4Em5mHpEBeH29mLbe8u6UXN135toK11Xx5b5xV 8QxPJvD2rWsepXuIMJME5MSN9Cji6mjyOGjRSHAicpUP4klYiJT5eQlo37m0tiAryFtIa6F9zdqX nXuIUcqponAP8G4Q7bJ6DR+9oiHJuluut4bjbswTkaophLPREire0Lo/sRxvxFNSfnwizIWKwfkQ lGvfvX7ta2uLT7QWAeG9It7QCXd6suRNU6oUncIFSxtZG1W6B0kDCbIjmU8vn4PgcxqwfFIfL5/Z SCU2jYqfbd0j6tYuylJysIceSyzxNWlKEkIsHf1okiUsj0ghh8PPhJEyqGusQ/1uoG4GEuDlmrUv tfe3Eh02+BMQwB7zwbHDfb2Hh/doNkGazc5NPwcWcyg7iGYGa5o5IMVzR4mzyJuvF1cuY79YufDC yi+hlV8W330TXiaPWBdR66K+MZKH8up+/iCycw9h7sFEeq+iMiL0H4A3u57UP4qOb1Bv7T8wNqwx aJ2QU6elNcieodyCETPOu1dOwq+mX596G62+WD81vTi9MF2fzkCZ6ZnYLHJqwT5Skcya+C0Q57S/ 6I1TEMAI2GedzJjrANpet9bt2ImrcbfK7TIyw4jUqSQonfoqq0hsBFwkVxOW0YviNhlx6gg7hZw5 zheOYqv5mVppGirOJGZn4VX7wsgU2hzZnd6ItNNy8YEDish0LVRClqdIa+EjNzRGjTm0qF1rNnfS GKWHEbMmEgdup+pU1BLpZB6JJfxsElvE656sF/Jlc/48srwQz85is9laNTsN5WbiM3Nwk244ayhe H1vYe3LvybFZvAi5inSpBNcS5WIBLRQb/ByyOu8y1LCaIQkMlnvSOWlBs/Kzoh7IlMdBETQLsTTl 9yAM+0yAxfwBMmyN6RO2KAm2f7s9aEN2HHCoR7Bhtb1vP6yN6tLjaNxRNM6oL29c6UnrId4asZjh EUJj1qPjZrWrF9k/mGpoMV0DXzgOZwL5YAW1y3e0JwF49/1Ly6HIyfk5oZbOp3OFdCUO8ZWZyDKy JG/ftDaK95AaMDU0mBoPA1G45T+nZlGiEbNcbwtHgR2OsjyYmths9jwqqlrDsgvy4w3Wk8DS7qjN BFt8JmYcKNUF8RHZGieX4Pll0PZFf9nL09BVCDu9khQ91p4gh2mDH1d5zX6LBd5XPLQygA6uXLBe Rp4/JZSPYMvlZiM/l58vvlD54B0xoUwsxCsxISbE40BpI4lcsNoh1UEQ5JS/4OUpFU9JOuuk1c49 KFAsot814BhUOQccGuuEzWy2GYAvGNcyI8juPqE6hmmqzqkFOBPMhfNoMBVrJo+9LT6jjM/GS3Eh lkzEhIgQKQYbAQ7w/qxcgvBPnIrW9a3w0vnGfC6rymWzyRxYTIVQJhAB/9kL6L04mfJGaVWMCVEe mPJTLIHSTtu4rr8ttP+mXGrdHJ4LFcIxFZeMdQwDXwg1PhJuUOucvJxlSbCeezgXDpN+q1+H7lg7 LZOo8i6nQvywxe9Y48HfxH9q8TNnStO8oMoVMqlkNBVNR7KdKHbLvba8P+mN0aooqLcH9vjcLI4y uNNgHm4Ptt9WJsXuxL9F34y+EV4McKE8MIKxSCzKRUOgqhKrS+HkwVvm/WUmQaoSZAS3sc+wNNwO rSkXxSvhU7GppKAShDI32/lzACTemCywPPizh3NaYcLv8JvRrVLkwCbGAAIqk1lfnIGAZrIU0EyK pVDHuE59+PBttyoPiPfLqKY3F4OjQS7MoWGOC8dCUCiaDlylQk+nxUVKcKkEPDWU2XK+vU3Z3t7e uX//kGbcqbKTJkbnkyRPD3jDFMJD3qCKjLKxOMwFuVAE5fhccXpa/I54r/Jk+0ey+FjY4gFySXlo 1O2xsvrOzihxjjFgC7kjKneEBEsfFacyVNm9QNW82b3iY0rxp+LDy0dnm+W0qpKqx2ciUrmNAOT3 tX6kcOyhS0QG51Vx3BYxI0MDLn0ftmvk0IGRrZB6m33Hbngkrs9bUWu+TNaQeiOWaWDLpaNHTl4k BpXUuM/igPEQ+CpKc3GfgGRzsQzY4NL5Sn7WLiidGreVoiCW9fp9iM8fCPkxf8gfjsChQCgQRoXj fxA/lLWVvYqEm7Po4eDPdI9u3QDt7jk43oc4nFzSjbmSTLYEH02dapxHGxdmlhfrUL5a4ctIIcO4 pW36q1fuUdjWB1OJQBRJJfxMDIsAgwOaxZjc/Wj7mwB3g2dO204hq8dSzWPYsebCSvMc1DybPn8O XiZmzWW0YtYJI4jBxLhNmNk9btaM/kn8vbL9pbWnFMLR4ny9ClUbjWQTyWcpewpL2aNGDbyH2G3e i07sGR/STEATWi2pQ0y6eG4M6/5tCxI/p9CodSYwti6DgTEg6nE+D7xMnqzPwmeSZ+pn0PJKfWa6 BJVnZhIzSC7po3mM84YYGvZNeid9qN/HMjRN0SztZyEfOwn8GhmiogxKR2M+HkkmuASPCSkuW4BL npw9jaZt+ugwcqDHqenBejSD/bp9kG4fvncPfDA5XBtHx2sLrhPIkQU+P48BZpqaW4a6wRL3A6lw 2SQoXCLuZ6JYxBsEIVB+wutCfYTXydj2t3+gdGVwAY9CUdwRtiJDfbj+ILZ9+OCBke2Qeod91154 kNcUzKi5WCHqAB98fgpbbZw6c+5t6yYlOcYabLAzTAB8UFzMGwf4iGeBpuXy1fyMnVfax1wWmoa8 Xt+kD/H7A0EJH5OhEByPFKXz7gdb/yRrl9dWFA9v3z/Yh9g+hkS+Ar9cvXT6NfS10yfnTiCFLONK YimwxVng7fondzyEdv9WLIujimcLq7XmDFSqJmp1OE9l7Sk0ZTeAUvX04LoD2H7dYJ9mD6TZ7dyz Dx4S1BUNqqksOE8hb7y99P4vMTJ1UK2eMJMqj9nEGhHtOF+YwCaKZKUJ84FUMINejp5LLCahjeK3 FPNLC7k5JJP0eoCVpMJgFTWRpgkDajGMmQ/bxlx9nr1M7vXGuaUFqPsBkWz9TFF5O3MiVsgs5RqF HJRMZ6N5JMr5fWEs5A94vbDPz3op1Ev7aRamQjTHoEyn+UI8HIth0Vg4LsBpOulMokncyhkRk5F2 GrBx3Gg2au0T9jFrP651W0mCBCuDG2yP7gm/BqFHZX+U39X+zcRPXQdYXEWqCYPb7rbhLqcH8jhw Lw40PRD0Yf7gZDAEh0KhSASNciGwxETB6sChEYYOdQ736c7hPlAtV4TkKdSdyjJ5ZGoqUZzGjtQX z8y9XT1bfav2hxfEMeVb8vgMUAKkdY/CyTtjTiCCDkvQgGzcYRs8jB0esvTuh3X8eNGEFkx15zx9 2KZ3uMDS7mRwF4zHXGkCPWw04B4GJ90ujxPyOFkch21RR8qOph0V1ywJeWYX2WXkxCqXXMKWhGYu X4IKJb5Sh0tUwZFF7dnh9E7hrpLSGME5JgIxnI/jYECwUQ7NpqrJOf5S+GxucQ5anMstHYUzvgyT Q38lT52RtR9pKxX0uGfCbSccuMsOPmW3szbEZI1lHJgjQxWq8LJwpLqILlZncktINU8701jaKd1I ED4rbUAfbL+hWKDLnqQbEgjO7YINdovagTrUfVQPsuMwX9Bi1hSZK8G5aD6ZQ1P5QqYu/HrirDvv hbrFGwG5WdfzAVlQiAc46SYJjCmQR2k33Ny+b+152dvyqf8drwvVdFl1+s3GSpyfXmzUKkkomhTC PBKL+L0RLOwNsgzY4y2UEX2yvVvm6qfHnbA77IlSKB2LexNIQghHwQDFMqlcIV9I5/isk1c6xh1W Ow6xXhaQt9cfDHVwEQ7DoXAyVgWr3EEZPxWpFeECm3EnUIHAOQcyOuLUDmHD2r1bnrpXvKmlUwK0 P33lOumkG8yE61NXe0nhowNyIQmn2ITnvx6qt2XtPpB6uJQG9BSPSmlIvE7DHsZMDqEb2+Myj847 4ZbSiFEoFeO9SSRfiGVLWKNUbRRn7QmlXW+32J0Qy7B+FvF5A2E/5uuoTzicilbQv4p/kYHodl65 5r9dPKY+Fd2nLx5dH5/D39geBOQZC3CBcAAKcBGw7nzUHCZMU7CPnSCG0HbX2medu+1qm11lt5qo ccTreyYAGC4wKf2CylAwFAmhMeAaYjCAJAMEn6ZCJEJ6vDTVmS8SVIxISDFl2AIAeHb+CHZkbvq5 0i/FL7YeVwKWg658RxEAi2xGCEo07mM5jOvoHzNJ+ynU1dP+AVjZ3pOfER+6/PxUW1l6MGkBHkO6 akjnoqkclk81mvPHgVZb9Tar3QWxFONjEIbmkgzGJN0r9jeIFc8sXT66pOTjxexsNZvM8jkOrJ/h Sse4qSUHmJWn+Ek/+PZk2B/0QUFfwOeDvT6aoVCrsX9g067tPUrxay2TVHDkqmJnEoEYkuT9n0QM ijaItr+2dkhGDLJGN0yA1no6rU0g2Swn5LFKrjHVPOpMK+1ax4QThxiG8TOgrAGATV94ErSWC+di TUk4fiUtmadbdyvCYB3NC8GrDeKwKBuiJZ1l/QzqPnxP+3XZW/LpPxWei+VyS5XlmdXplVqjIEDA SIcTCBf2e8NYmA0ywHexE+Qo+t32Kdk78sr7tVcap1ffPfH8qRUolU1H00gk4mfD0qiB9jPPgLAA d1sACHa175U5e6hRJ0hH8klUZ+CEZDgGvEQ0my6U86VUNpZ08EqnySkNHEOxvo5bktQw7A8BvEbL yRX0JXGLLFoM5fNwhc12rntcYOD0esKsw/b07Xh02x1LYrcyVgsXMnCWSRHS3TwecSAWG0vYMI1t TDt62DJu6NfufkXUK7vPAkKO2HIhWYCPBkJgxiTsRDrVoVkziPx77RcBvZR/lZhJTWfrqulzU0cb c825eqWWgmIpiV447iq9hIDJxlkroJcnAL24B2i9RC8fuUKvgKQynJDDarn6VHMVEItNZ59wuiAv cIVexO+TXKEvJBFLJJyKVQCxHJLxM1wtD+eZNCEAYnFydmRUjWuHsWHd3s1P3PuKOK7sbt3fuk3R 0A2nDiGHDuK6/ZKaDwDjo9+H79sHH0gNNnSotrGIH0OOHU81TmAnGgtLtVNQ7WTy9Cn4BL6ga6J3 tBcVG/oOjexHjBbpgt+RpSrT8GuF11ZeR19fPjZ3CqnkKQcgdIfk+R6xbDi8Ee0+3/oBICbJN/EI H/OzEjFJh3WMz07p0fYNaz919xIGwqMiPROMpmPR7Z17GXsgBFTz6smgN+LnonAsnIlW0QXxixlP ikl6VT4h7c8g77+2+M4L2PPvNN9+E14kpybKaNliSGgRrY6y6zCdY1QzfHhGvE75aNuvSF+onZpf hlbm5wsLSCZN4wIm4JxVD4+yo4QaJdRuncuAG50TdqvdZsdtQMBsNtaOjOiEigXrbt3S+onCsYOu uHPOhCoBjIQJMLhL34/tHe47qNkBaXY4d++Fx2La7Diqz1RdM0i5Gs/VsMXq8rGjrzzWZpXksMdI ERRBUm6W8ln8o52FxiVl7MCDYRJjQuxHGUejcDScBRmL35Ouou5sOxSGnaOH+tWQ2WAiLIgDl+7P iCSTq8AvlV49DuzdsdW5ZSSfoYG9S3YO6ftdBwy70O6ZZ1u3KEJZAYii1IOOdwUaJx3fDQPgPid7 V555ORCNlVKLKh7IY7I4c7YJTHeuKCTjYQj4GvBkKDTpC2FBf9DLwEFgsCMsxAJIx5CUEE1HsUSB K5RgAex/HBoFxEwg9gnCrMd6+ndtfPrO10WPsv2AXtY9I/65tUnh9LgpHGHdoagDs3NE2AtkweMJ EMiQhjCbMJOZGB+F7WF7zI7Gbfnx5khzOK+PW6EIEQLKY6HtThzFcQttQEbH+aINsxbJef8ZyCbX tL8HFud0LBFNIVxcuvAgputsBTk6n6w1sUY9NTULF5mSq4K6y/r5QycdWTLF8hAb9yd4OMMlBUAD QoYrINUiaclK196jwYNQTj4lfuv/MmpuP05UcRwPiS2jD/tEk6GTzGiiL6KJL8ZE4c0HDTERY+Qi glQtlL23S9vZdjqXM7cuO+10zkxn2067ddvusnShlMAuZi9xowYwMRASfUIfQIj/AJmS0cQzID4a M8k8njkz53e+3893zs8XY21wPTT86fjpeDqeHs2e5OU0/kvwTa8X4E7KE3SYKXKmQAqwrFQQu5fK DtV2FpeXVjM2njid8dmdYwVZ9PHAx8aCL8GW3rRXyPvulcDtIDwfeC942cWRGL+GmJeNJN9NHkwP 704NJ06NRkejiQTNYRzNyBwBZK2gUHIxr5fCNuxUVslt941Adc04Xw9XFBuYpAk45MDppMhMUWP0 +PjEV1UeP3e+UYeIKSHUIFEs+itaUDVV8UEhd5I85O0JTB8C0Xg4q+fKHMlbc3KN6PaclctU/8L6 zR8ext/OHJTPYDKdz3K+5ZREP2b5qlUtlWtUy1k49/VlpownT+VSsoKyrIxU62mWndH897WNpbk1 8nd3IzB0rz2gQoWqjZytMQemIdU+VPN2QS+CPvhPt3p9w9i63l9fuLjQqy3DNqZXC7Xas8N7ji3l CFZ41jfDI/ZlEftWOYMHYUEVVJ5UciDL0RIfjx0/ALjEeOS4fFfdVjvyJlgDPbEN2nzLo0Zx/yzg FVSU3mferzPl/GL+6m7JfY79LbXtvXgaR96LZoiymO3/n7U5mNRj9juGt0PzKKwZdI+5D7reA1R0 9fpi99K13je9jYvfLq01etYSmrFWdfzOLwREluAvByuoCFZE0YcVUfPbDYpSSTIlKKEtqWIFpI1i OMvHUzEyduDYBx+9HxvsQOCyNngLQcCsBc9CYsFRBKRbgpU1kppsnZjfC+jpscnIBLKrDOvzm6oQ ilg0AFVmOf0pIIlPnsn5PgPFf5Cy0YC1eWq5c+X7rfvNVysfGzksVa7wDcKu+qjTbXe6zf60iecS mTSdxYAAVFS6sqYrlKJLVanzhbsXX9podZsOZlqWDgndUuUapUJjxiBsqwgtStc1OBe2FFOApAG4 IkPwIK8CKicz/DSTYZgsm/l8P57bFJYlGzisk3GwoXvOYI8PIlrdRjjbrEocSomcMaIfXvRu4tnk 1MTIcCKRpNFmUBUln/ezsE+KBVVXoWqgu4YVFHlW9Ls7OJ7iEE3nwvy/BG8RzrxRbVGtSu/ixnd3 7t74efP21q0LW84KVl8xz3XCTbnGIydFxMA8qbEneImG4Ao8GqIEoGSqllpStTyG4ifaPfKMlJdJ VIbpzOTkiakYHY8eHo+mEklXxOV1ZUWpKTVQ5xrYUPeqeyNUD5oNq2JCdJVMDRFxfXaZcF8Keg+9 RwHGvbNzFWkAHRTOCFkgiECQhDymCsmZGOG9HHQfuo8CtvfjzqGEGxl8GfpfXYZgVvrPLkM6xSR4 P2v/8Xh/6M8X/joSWA0Onn98JDDkvj7YF7oqXwAdrs02U7UxzBmDsUj4w+zRkSgZHYnRUUIAswWR EhDD5MqYcyZtThMspwiAEtDWZMNZg53jSabREVeIft9q9KnFaqfRarfb88vOJcy5BK9cC9+a2j7W J0dbEecT2LuLu0cRSwW8yeDQ2bPBgbrLfRz6W4ABAGK+fiEKDWVuZHN0cmVhbQ1lbmRvYmoNNTIg MCBvYmoNPDwgL0xhc3RDaGFyIDE0NCAvU3VidHlwZSAvVHlwZTEgL0ZvbnREZXNjcmlwdG9yIDY2 IDAgUiAvQmFzZUZvbnQgL0JOTElFRytUaW1lc05ld1JvbWFuUFMtSXRhbGljTVQgL0VuY29kaW5n IDYxIDAgUiAvV2lkdGhzDVsgMjUwIDc3OCA3NzggNzc4IDc3OCA3NzggNzc4IDc3OCAzMzMgMzMz IDc3OCA3NzggMjUwIDMzMyAyNTAgMjc4IDUwMCA1MDAgNTAwIDUwMCA3NzggNTAwIDUwMCA1MDAg NTAwIDUwMCAzMzMgMzMzIDc3OCA3NzggNzc4IDc3OCA5MjAgNjExIDYxMSA2NjcgNzIyIDYxMSA2 MTEgNzIyIDcyMiAzMzMgNzc4IDY2NyA1NTYgODMzIDY2NyA3MjIgNjExIDc3OCA3NzggNTAwIDU1 NiA3MjIgNjExIDgzMyA2MTEgNzc4IDc3OCA3NzggNzc4IDc3OCA3NzggNzc4IDc3OCA1MDAgNTAw IDQ0NCA1MDAgNDQ0IDI3OCA1MDAgNTAwIDI3OCAyNzggNDQ0IDI3OCA3MjIgNTAwIDUwMCA1MDAg NTAwIDM4OSAzODkgMjc4IDUwMCA0NDQgNjY3IDQ0NCA0NDQgMzg5IDc3OCA3NzggNzc4IDc3OCA3 NzggNzc4IDc3OCA3NzggNzc4IDc3OCA3NzggNzc4IDc3OCA3NzggNzc4IDc3OCA3NzggNzc4IDc3 OCA3NzggNzc4IDMzMw1dIC9GaXJzdENoYXIgMzIgL1R5cGUgL0ZvbnQgL1RvVW5pY29kZSA1NiAw IFINPj4NZW5kb2JqDTUzIDAgb2JqDTw8IC9Gb250RmlsZTMgMzggMCBSIC9DaGFyU2V0ICgvc3Bh Y2UvRS94L2MvaC9hL24vZy9lKSAvQ2FwSGVpZ2h0IDAgL0FzY2VudCAwIC9GbGFncyA0IC9JdGFs aWNBbmdsZSAwIC9EZXNjZW50IC0xNzcgL1hIZWlnaHQgNDY2IC9Gb250TmFtZSAvQk5MSkZFK0Nh bGlicmkgL0ZvbnRCQm94DVsgLTQ3NiAtMTk0IDEyMTQgOTUyDV0gL1R5cGUgL0ZvbnREZXNjcmlw dG9yIC9TdGVtViAwDT4+DWVuZG9iag01NCAwIG9iag08PCAvRmlsdGVyIC9GbGF0ZURlY29kZSAv TGVuZ3RoIDc5DT4+DXN0cmVhbQp4nFMI5CrkKlSwMFAAQSMgMjdQMDFQSM5V0I/INFRwyVcI5HIK 4QJxDBUsFELSuAzBSg0VjA2AKk0VQnK5NIxMjDVDsrhcQ7gCuQDDORD1DWVuZHN0cmVhbQ1lbmRv YmoNNTUgMCBvYmoNPDwgL0hlaWdodCA5NSAvQml0c1BlckNvbXBvbmVudCA4IC9TdWJ0eXBlIC9J bWFnZSAvTGVuZ3RoIDQwIC9XaWR0aCAxNDkgL1R5cGUgL1hPYmplY3QgL0ZpbHRlciAvRmxhdGVE ZWNvZGUgL0NvbG9yU3BhY2UgMTUgMCBSDT4+DXN0cmVhbQpo3uzBAQ0AAADCoPdPbQ8HFAAAAAAA AAAAAAAAAABcmwADADdLAAEKDWVuZHN0cmVhbQ1lbmRvYmoNNTYgMCBvYmoNPDwgL0ZpbHRlciAv RmxhdGVEZWNvZGUgL0xlbmd0aCAyOTcNPj4Nc3RyZWFtCmjeVJFNb4QgEIbv/Io5brMH/OxqQkxa myYe+pHutnfE0ZpUJOge9t93ALttTYDhnXlgfOF189DocQX+amd1xBX6UXcWl/lsFUKLw6ghTqAb 1brt/KwmaYATfLwsK06N7mcQgvE3Si6rvcDuzn/7x3Qf3QB/sR3aUQ+wO8XvHyQcz8Z84YR6hQiq CjrsGa+fpHmWEwL/Q/+mTheDkPh9vLUxd7gYqdBKPSCIJKpAlDSh7v7nWBKItlef0rJQGUW0MA+Q EJcVI26rOPzUB1wkhSsqA1UQlSiK0zQINQlp7oTWCxQzkblzs4Bk7qLMJfNwc3ZPQu7wvPACxUzc xhQfpBcoDv2EDtwvOdevJqmzteSffxrvj3Nm1Hh9PTMbZ4Qb7FuAAQBDv49bCg1lbmRzdHJlYW0N ZW5kb2JqDTU3IDAgb2JqDTw8IC9MYXN0Q2hhciAxNDQgL1N1YnR5cGUgL1R5cGUxIC9Gb250RGVz Y3JpcHRvciA4NiAwIFIgL0Jhc2VGb250IC9CTkxJRUgrVGltZXNOZXdSb21hblBTLUJvbGRNVCAv RW5jb2RpbmcgODEgMCBSIC9XaWR0aHMNWyAyNTAgNzc4IDc3OCA3NzggNzc4IDc3OCA3NzggNzc4 IDc3OCA3NzggNzc4IDc3OCA3NzggMzMzIDI1MCA3NzggNTAwIDUwMCA1MDAgNTAwIDUwMCA1MDAg NTAwIDUwMCA1MDAgNTAwIDMzMyA3NzggNzc4IDc3OCA3NzggNzc4IDc3OCA3MjIgNjY3IDcyMiA3 MjIgNjY3IDYxMSA3NzggNzc4IDM4OSA3NzggNzc4IDY2NyA5NDQgNzIyIDc3OCA2MTEgNzc4IDcy MiA1NTYgNjY3IDcyMiA3MjIgMTAwMCA3MjIgNzIyIDc3OCA3NzggNzc4IDc3OCA3NzggNzc4IDc3 OCA1MDAgNzc4IDQ0NCA1NTYgNDQ0IDMzMyA1MDAgNTU2IDI3OCAzMzMgNTU2IDI3OCA4MzMgNTU2 IDUwMCA1NTYgNzc4IDQ0NCAzODkgMzMzIDU1NiA1MDAgNzIyIDUwMCA1MDAgNzc4IDc3OCA3Nzgg Nzc4IDc3OCA3NzggNzc4IDc3OCA3NzggNzc4IDc3OCA3NzggNzc4IDc3OCA3NzggNzc4IDc3OCA3 NzggNzc4IDc3OCA3NzggNzc4IDMzMw1dIC9GaXJzdENoYXIgMzIgL1R5cGUgL0ZvbnQgL1RvVW5p Y29kZSA3NiAwIFINPj4NZW5kb2JqDTU4IDAgb2JqDTw8IC9MYXN0Q2hhciAxMjAgL1N1YnR5cGUg L1R5cGUxIC9Gb250RGVzY3JpcHRvciA1MyAwIFIgL0Jhc2VGb250IC9CTkxKRkUrQ2FsaWJyaSAv RW5jb2RpbmcgNDggMCBSIC9XaWR0aHMNWyAyMjYgNTA3IDUwNyA1MDcgNTA3IDUwNyA1MDcgNTA3 IDUwNyA1MDcgNTA3IDUwNyA1MDcgNTA3IDUwNyA1MDcgNTA3IDUwNyA1MDcgNTA3IDUwNyA1MDcg NTA3IDUwNyA1MDcgNTA3IDUwNyA1MDcgNTA3IDUwNyA1MDcgNTA3IDUwNyA1MDcgNTA3IDUwNyA1 MDcgNDg4IDUwNyA1MDcgNTA3IDUwNyA1MDcgNTA3IDUwNyA1MDcgNTA3IDUwNyA1MDcgNTA3IDUw NyA1MDcgNTA3IDUwNyA1MDcgNTA3IDUwNyA1MDcgNTA3IDUwNyA1MDcgNTA3IDUwNyA1MDcgNTA3 IDQ3OSA1MDcgNDIzIDUwNyA0OTggNTA3IDQ3MSA1MjUgNTA3IDUwNyA1MDcgNTA3IDUwNyA1MjUg NTA3IDUwNyA1MDcgNTA3IDUwNyA1MDcgNTA3IDUwNyA1MDcgNDMzDV0gL0ZpcnN0Q2hhciAzMiAv VHlwZSAvRm9udCAvVG9Vbmljb2RlIDQzIDAgUg0+Pg1lbmRvYmoNNTkgMCBvYmoNPDwgL0ZpbHRl ciAvRmxhdGVEZWNvZGUgL0xlbmd0aCAxMA0+Pg1zdHJlYW0KeJwr5AIAAO4AfA1lbmRzdHJlYW0N ZW5kb2JqDTYwIDAgb2JqDTw8IC9IZWlnaHQgMTE3IC9CaXRzUGVyQ29tcG9uZW50IDggL1N1YnR5 cGUgL0ltYWdlIC9MZW5ndGggNDUgL1dpZHRoIDE3NCAvVHlwZSAvWE9iamVjdCAvRmlsdGVyIC9G bGF0ZURlY29kZSAvQ29sb3JTcGFjZSA1IDAgUg0+Pg1zdHJlYW0KaN7swQEBAAAAgiD/r25IQAEA AAAAAAAAAAAAAAAAAAAAAADAiwkwAE+GAAEKDWVuZHN0cmVhbQ1lbmRvYmoNNjEgMCBvYmoNPDwg L1R5cGUgL0VuY29kaW5nIC9EaWZmZXJlbmNlcw1bIDMyIC9zcGFjZSA0MCAvcGFyZW5sZWZ0IC9w YXJlbnJpZ2h0IDQ0IC9jb21tYSAvaHlwaGVuIC9wZXJpb2QgL3NsYXNoIC96ZXJvIC9vbmUgL3R3 byAvdGhyZWUgNTMgL2ZpdmUgL3NpeCAvc2V2ZW4gL2VpZ2h0IC9uaW5lIC9jb2xvbiAvc2VtaWNv bG9uIDY0IC9hdCAvQSAvQiAvQyAvRCAvRSAvRiAvRyAvSCAvSSA3NSAvSyAvTCAvTSAvTiAvTyAv UCA4MyAvUyAvVCAvVSAvViAvVyAvWCA5NyAvYSAvYiAvYyAvZCAvZSAvZiAvZyAvaCAvaSAvaiAv ayAvbCAvbSAvbiAvbyAvcCAvcSAvciAvcyAvdCAvdSAvdiAvdyAveCAveSAveiAxNDQgL3F1b3Rl cmlnaHQNXQ0+Pg1lbmRvYmoNNjIgMCBvYmoNPDwgL0xhc3RDaGFyIDMyIC9TdWJ0eXBlIC9UeXBl MSAvRm9udERlc2NyaXB0b3IgMTA3IDAgUiAvQmFzZUZvbnQgL0JOTElFSStBcmlhbC1Cb2xkTVQg L0VuY29kaW5nIDEwMSAwIFIgL1dpZHRocw1bIDI3OA1dIC9GaXJzdENoYXIgMzIgL1R5cGUgL0Zv bnQgL1RvVW5pY29kZSA5NiAwIFINPj4NZW5kb2JqDTYzIDAgb2JqDTw8IC9GaWx0ZXIgL0ZsYXRl RGVjb2RlIC9MZW5ndGggMTE2MDcNPj4Nc3RyZWFtCkiJlFdLc9tGEr7zV8wRqDJhzBPAIYfIdmRv 2bHWkjepTVIuGqQkrilSIfWID3va8+5v3q+7Z0CCL8tWmZhX9/S7v3l+eq7V1WqgVYk/rXTR6KYO qiysLvFtbwaluhqcXOBzsRyURamNungcPP/J4PTF5UBjqRZiHoVQGKcqrQs6eDP4LSvyoTbZIjcu u6Wfu3xoTfaJhvN8iN9Rrn12kw/rbEIj9UOuQ6b+m+sqG98OV3mdtbR+zYcntDmm+X3eZDOimtKS sLoirv+j3Wc5LlX5H+rib4NXF6TAEPJBwItWRo7UgJTOqou3e9XwdDw0TeGb2odOGVNmqxZCXbMe kxxSfpryeMyC/wB9oQXL8yvJ8woLIfv50zkJ+4J+Xq+XX36k8Vvww9yV2Qfi8eklnTo7fwYmuq9F SQqULPtBkeu6KKsq2f8/ffrkwcPkVSi896HedN+Y/fcpOiOsneGz8f1s23fjWzooh23TO/xp1599 FgVz2FL5mLjBF6V1CLo92iZPt0fovS28NlHbf++Qa2/Z5IiUYGPM6OZ4zDhTGGsTz3FeFxUSAGFR WAS+fFf5sMKnpTBqMJiwESAMhgrxZOz6kCLjL9PBHGJ1W7cyA/eAzzyeWcGIuDOx+cwSzCiaCoSs uowS0e+Swq5wmUoC5SVW+1IZGk4T8yumU/+Q8y+iPmcy/Sg3R2aULqzARccwh0TVvpgutKX0PJKU 3lHwNkEFCxm1rqPPOZw4QMfrmKI44ySExo85Z2pKy7Sy5NOLWJRSCI9ouFwzUv+iiLwnfnxKSb1R /ZQ4Es+UP+pHupBXiYBJn8nOhnBcBEWRKQ0vv27lrin35u7aMLopdFNGu9xtZSr8juG9lEqW+U7q J9/q6lhEEW02Jbx8WC7OeyZgNdTvWc8Q6YxPZ7AnujPh77ncvoihnO5ha4/HwuqKl3bEfgmLneH/ 8EmFbG2MsipCqJtYus8POyrdLj7GeMlirYOC+8o0TgO7kHQrv6dQ+SYgsCsfy3KP8vlPLrZTI6QG aiiPSuxiEfHF1k1vQeS3iYKltrtJt1P8pXvvXFeJ7TYoz3KtqdiQOS5zzTUGvW8pztbkOs0VB326 5WOTHE59hYb4MIL76+x+BAtKFcoW811TfQNE+OCK6jus5Xxh1tYi7+g+1a65GjbXBuG2uUpq/C2P nDtkuiBht+byCuCjCNlfufH43JIRqcTCdA3mUzJWwUasC7IaLc7vEHLaYXlGFRIt8CwORvKBKZHc LrsUqkU8vWRqJJ+mGr7bvLSIH4zRTzG5RTOMJn9PJVwDZoGR5u5DXzX5i/SxcQ2lX0OhsmhIBghK IUOzOcG8GtPRLK5zE7sWLXXsZpoqNrF6HKUFIVe3aDKM75iWAokHl7y84N9EcRPbpZa2B+K768SM L30T5Txhsnei146tjIttqKy+2YVKU2OAbtqsoeHJjEHgKELBYUPJY6ihyrChXHF1xL+8sOQD6jXK yTlnkMFIAwUEag42UHPg+gwCLkbXzEEJC9pbqD+5mt1HJB3vxnjINmnk+sWSCflStbhUb/jIjjxS 2H+NyUx0cgQ6M0HpuZ/vMZ72XqxnAo2i+fRe+0GqBpniKSeqoLWYb8TyUvco8atMwfHus/I0brwm 5/rsn7wvwMJTuZHdB/jWZxOJCZ99RVOl7bu4/UhOJ5BALFQbVxdMlGgYWHmBLp7wEN93HXdH3TGO qYAwMnTFCfNQb41i3N8mPdqcP4l8UiQM5AUD+cMRWNqwt7FFw7kGYextiHG3Su5i1AJvPWyMJel4 KMHBsMidMg1FwocfefiOf2HVYPc5t4qpYUx1qMc55eqqgM9NrB9R3QoGY5NWYuAq2rtil9nksqoD uUjVCvFcd3A2osmqy+sq+uBFPDyJxaaSmlVRMtFnGPe9xFKVOcVqTufyfSnHFnyXlK8qG03Trark DeSgJmw9jQc6IShRRC0G2dwJd6Dt2qvGhKfVFWCEoimbKjYTSy/ZgvR1hNEKmlqaom6gUHzNK0Mt Bu+s5QMdmApCga8Z05FFne23wvUjcn8rdVTZTK+VmifBD+6nm9Q7/ZSNcbCJbpKeSN0EKm3xc41u CefkpJDLvuRAIhQVu8Fa1jFYja+roy1PW00dm80d70SS5vReIRcbdq2l15U6vZ+s7rht48b35+Jw tJ1K/F6y25F0Lxc5P4Zu4tlRLpGzfe5jx2GYnktlSoFRXJv19xY5v592DFpHbeumOfo65eoRApwL WBVcmWDei5z6gnQDAvjvKXzO6WeIHU9xhAig4EsjAuloLK9Gbe7opYh1eVZpZJQmaIKVm9F0zfRj 7gCVpyv+EJ7JZjM+1fIT4G7CLw4FMzVZnVtHj0uQvWDcn+ipHlNbxK6m+Sk/8Pbnmrb6CU2IrYER XpKlFWt8oJTht9o7+nlGyaZqGp6SOie0jfcI5us0+8KLI8rAec79V9TE/liePNi/lVemJn/6QC30 jo5dT/IAhT5zpk5pZXyFmI+hMJ/QCr9IHinXJaG/KElzbM15DzwsYXQu8pi3JAqTHgaEpan08XIE C9UB4MY5XeDt4hux0GUEU30MtgG5JDrUtEOAkzWCpAOtTIV+LhN8vFsfbe+4ueosATsKFjkttz0K 0EvbuJyYcRRKVU/8Eygt5cAocRjLfO/ZUfwKrE0UH+XK4gj0cZqhjz2UgtQmjQ0oOZijqRLQJJP+ EjtkB0FmEUNMGOu0CcR0aOZaji3ZaunYRI0ZikzjoUueXebVJi6azOPgrmMWoRK/UvwG/llcxkF7 ny5a9gHMmpe8CYXfSISbpt3IT3DdmgPNRjdbCWy1tU+LSgsQFKwPMW8/C/yTq9PNrUwT7LrpINyX VQRvapas1UkZLT9ONs/RJeq1Nlz86uxirSx/5f6+31CmOh6mqDvegjrVZMtA9/vAaMorcq+8vMLG oSnfc9O7ldJOu33wUnsrgWprZ77ZK8TKgHQwcsLocq/lmyIqs/JAtKS7JbgkWtq0G5vFKK62TMkR xZ11vS5fDsaKqucwgSq+caxi2WnJelW3/sCzaZq23eiKN+SZACne9Ki2hBrz5phvSDgPiqRBd6Mz mD1LLoEZ1DtR8kw+csluh45mL0v7jZdlZ3ZAktq6EOvDbPqZzIIaz4B0JOAhQeWv1E+g0/0KWcjO 4c84Z+RC78eVAFh1cytspq0cuTayMWS2GpgKn4InEfr+RtFPW+u1P/DrCI+W22iEYiyp6rRALy3Q i3EhKcoDXcLHRlkAEZseC+n9airkEv0inhxFvS6+hVx3YB28GHrc1R7wqg9RA4Tgn+8xOOkY/DnQ cloNAaOMtY1C1hnbBNXegHcFKBmg47BqAGWdWk4Gvwzmg+en50ZdrTriRDvsEZ8ykKvVI8kJ8ZZ7 xKsPCAYKs5fCIW2aSvftPdmk2yHxSFJTNn0jzo+ToDkGApWbJO1RkmCoZcIImyTXx0kQe3XZ6B7J zVGSCpkZtm8ZHSWpUa1ruKVHsjxOAqRuwlZQfzlK0pD6je8H2uo4Cd6Xld3SRR0jMWVZoKKYqkfy /jgJ+hCity/Yw1ESNBwkddM8PcaMbpACof4OIwM7FaiJVn+HYAbArtFbukyPklC/r1xpv0MX1Azb VHXfyI9HSZCVpa29PuDKv3cVAxg0MCEPKMuQZFoXFX1RNTYfPgefukBvFJvu/6RXy3LcthLd5yu4 FKsshgAfIJe2yqlkocQV69ZNVZLFSDPSTHkeqtEovvLX39MPkADIke2KFiOyCZxuNBoHp7uCBgpx 1J30CHtuF9Y7euYm5igNzYR26d6y83qhB22V0BJVhXNg+kYvrqsFNbsn+llRY/JwIKF4ZK5/oZ4v vSsN6xIiRWfqOU+G1FddNuAZ3MY12Na3sQy9ZDfZrzl1QvC6U9fNzK083CTTYwbGtChnSVjV9dr6 cFPK7euR29rNgu5l3FQTofV6umzpaBHYCslXhytfquycZnslI4gP/xiMM9JZTb5qE9Fqi1iVqaLH 151+YEk/KqTTGMlr9x0US8c2iERqEss6gxHAZVUHtm1gc0XpWsS9DSePxvUP9/OomF60bWzdRtZv QKbhpjsDXc8hxyGH88/FbHtsaZKJwbadz850wYJqsMeuTGENjj+iiHFHY4ARzE+R+wqsMUGGtUn8 bUNriD0iJNjocanRTbDJSrG4CDuwBigBQoId7ECAPW5WAH12W9MK0Iy8Is30NApp4Lg4N0ccYHIS 79SnKKH/TKT04YpYCD+Vucg+3jB1/E5U8p4f315Pqbb0NFi7dpYG+47Ir4M36PC26jvt0N6C+Y5H 5r6XvG5TiT6sgVs/M09OaBEsV2gJJmgGhqUu4mLzZTXh7TEzl6/AgkrrsiybNOLrVc48DfADeaDO 0FLw5fwVdBYf29Iyfhz2u1wai464ja6Iz8TZGzIsT+Rw/b1UhxJDfaakNFi3iZXK0UaHPDDG1IHU m5Q6Bts2ohPvayasCXUEsCNLBLgRn3iMmHoi5PHgh8gjSYTQEaEM2BH5hNjBwQ+wA5IIsGNC8Sgx +YTYwdEPsEeWCKAjPgm3daSeKCOvU8eEJxrIpcx2EHGN1xbvqSA/4ChcXeW2mTlgTgQLJEHnRpE0 Sw5Q41AFoCLbuaIxTaNH4bfHFd3v0LcX1x+yaxyMgk8CCKtDr+bwdtTvdBTxepmGIToTD1XLDAiN U50Nwlnqu6xroMErU0kQt6v8sqezWJNPLHrNj6zU+Jge+f1T9sSc8EyjEWPtSEfi5E7VHOukdqRN pNXUs8KLlF1X9QbJRwVa13vhfbPO2XFbA//SsFwCVeTdOaY7L+7IB+in8hvcdbrDvz4T22CdYLZb elxNoEvjsat5au5AzdZiY12JLXZ1o23TPMlfnkcClXSud20a5M2G6HK3ot/v5cXSgNcnvDhYI17U sxbzYmCMeNG2FhUU8+JoC3gx8DUTVsqLIexAgSFuQJYjRsirCfLAahHywIARdMCWAXbArDH2yGoh 9siAIXbIliNKyKwx9shrIfZAgSF0QJbxtnpeTTLyOi/KlZ6SY1fgMNtaW6JfrnEI36X1LTQEuK7s m/k+saMC77nSTUOVznAfc6YQdLn7JXW5R36+o59/wLvFHPMq8YJS55mul7Nk4IsZ3YXK5ulpwTz2 MN9/4qEeiPSc0sOYBug1x+DbO9FhH18TZdo8elY8xwWszNhDHP/NUZvBhe8KtXu8zzu0iiv/+RWK PEM+4N7SNn26pI+PuSP+7fDjwL4smL+PhKhYG5OS0GjdJlYq7IiEQmNMQrVDISUkNNi2ETF5XzNh TUgogB1JKMCNmKkxKQlNkEcSCpFHEgqhI2pqTEpCKXZAQgF2QEIBdkxNjUlJKMUOSCjAHkkogI6Y KdzWkcSijHyFhHBOLNXrjz85jLq5/6Gn9o3m8IOpSly6Gcq08Grh/f/ypgRpmBrixZBaMA6KpnI4 5T2xS1v03124aNZal5aXt22TksMhjcorMKblNcKGRTACp6UhKGmBjthhEYzYYRGM2GlpCEpaRiN2 WAQjdlAEI3RSGYKRFtGIPKYK25n2WKNtO5/76Sa9ghqkLsCNrU1Pwn8bA3hjsoMRtOeCCHlgjWBX ZyrAIxufoxB5PPQhdGT18cUIUdQzKFHdJdjz1VjO5noOZRfWUoAdW4e4I4Qw7jmUqKYT7PlKT0/F iD3dyaBSA+zY6iOMEcK451DC85JAzx6i9Lz9C+QguvmV8D4WZW1aJ5yoz5cWstG0oEhjC+e6WCHC Vckt748/WWHoiWZE8uHfQr6ozvuZdN6GpMTDOvuQk6KAUDpyW3dPzc2BfuR9R58W1Fbu+f2OHqXN vOJh3Js+PtPjiR43NEHGPkijhJ8r+lmzkbG2NHIrYqbq/XB+zv6S+Ciuq6u/8uxPR5P/ZhHHQT/R 54muEtULyYQOkDRjkgVQV1naDgLLsKxqNBcQoIT2xDqUFwALRwQBvOTnozzrmBWZTjLrcJ/JExsH DJ9dAXnQiS/hdxZyO0F5pMkrToG4usfAi4M87zQkj3YnScOMzPug6/QSSf0UOF1qQCQSEeVU/BpV 2JYErUrsWQU/JI7EtkMdmiFxFmUsstdcPK4oBjzcneIPb/BK/7ONCGWM2OqIZ0TZ4v/w5QHaGau5 UqgPgvAfVBSZvaccKzAX3t8qL/FxCTe1JTceS+w+mM+CcWAHRx3yifJWX9yy0a9nr7hL/a8zN/rZ m09rBXmT7fTTSgLzrweUaeDsRdYWdzpV1ZpXOxzcgX1vkfwOS+/rVpuBY7TIxRBbN5+nmv5TikxH KVrsNfEZHaoxYTz+6xlrLpY++Vvv+kUWO2z2ysPcFd703xW7e0Z4lnZqhf6MA73Rob+zq/f69lY+ XuvmTzpEp+xXt9VXCtin0DVgcWtVp95SxI47xcLprlc4Xvy61tcdqAevC/l3VOsnGZRBz54OApOd FOiJ4nXIYslWmejhdEymgx7ldSUdowxdemzKs4Lfq4+dzt+p3feYL3lDcNkxdrNYyrAiu0nDgAB0 wszJHI3sWd62XDuVruYpr3lRyVYI8V5qq/AttdyiHpvSdZ5IwPpH4f7nHNy1R3l1WB3Ht9zAKzLA tFjrfSGj9yf6lN3R80EmbvKWriHQLF9DYn1Cei6y25e8b2lHYF+Ltye5BwHyJWdmJ+NhcJVJZJyl BQ14yZ2V26fITTWpSmXUztej6eeyQNexRR4y09iic8bqRfSeyHsZ3J635Ph5vIn5NpX7mu/Q40Iu UUzQm5QvVrx+68185dM43P4sBHAD02cOyN/CPP43vDwGF/Z1TgPSy5hOp+v96XTfyG+1Kaq67/Rw 7jZ3ed0K8ZhWyNTg9TJ3+L2VF5Qscc5eh9zJ61pfd1TCxI3WBjif5PUp4wX8KUCdGP8WxsmSKeom O2kMMlXOO92xOD58zxB50oGvgiD8XEwp/VCc1uZ82Ede4SEes/kigxYKv9FQ9nqniK7SbPCXJcNM WbNVkWRc/Y2saXt0Ya7Sw8qE1iqT1MIaLR0aME0rhEYHqS9aZRYOjIynjQ7aq53pZJy7Vygmvjum tJaSQ+62ecmwPIIpCgMX/uGzAK107Hb8shDTEWnyvwuGUngdV2S/8LcTf8vUaRzXialwWM1Gxoxr EYe5HUakuTcVp56yjpvUcqr5oamR8r7otfSzf/E3uDSyk9klguTGC22GraRzaDq1Uata+XautBPr NrG6vi0trBGAN3L3ol6908vAqyfIeO3QlPHiw6Q1aIB4KD9wmrg0eaSZpFcpp6x6phxHoDSbH2i7 66xvi9qh2VJfLWsPLMKgoC0dJUiUqkSlMLuD6SpVV471LI047GUkqq4bx2TLg5r18wG4LKYMW+8U /3B4iqbpaLzi1yMyQfGzn/6PH+Z5SeKpOhamJnCogNBhJNeyP0Jve15cXeSWGKL0/9/If2onOBWK y4NPcXoWPqC9X64OVrtP1a183epsv9q0CynroQlRMurkzoz3rjUkfTNSwKa3jezeH9o0Qb/vc2N4 /T0IyBiWRY0a0M621GHBjODq5uJ0xwSzJgst2VKuLUnhy6qUx2cMVKhHBjkoKt+j1rtdMsQzj9jz 72mzFZggos8UZ5Hj9nyHT7W0LeJHvC95mECy+Q0NFkdr/WZajY99ylhe2YLRJAZc/RpfsJY7Hhvg MIKfIIuh21+mbGQdE+qqKy/xrPXqxhpzdqtcV9ga0/xW9SI6C2o2LL1kVfF/1quuuW0dh/4VPsoz iVYSKYl67O3HbGfauZm93d6Hvfug2oqtie14Y6tp+usXOAAp2Y7TzOy+iCIJgiAI4hwwXNmE2mtm vz90nINQuCaYreGIqtBHV4fDKBFi647FZBkKX3oZDba8FtrKY8EWLNsap2ZkY8shO83eL6XSEMfe Kt2xjbjnBEwtPdi6MjW/Bs10+25WK4XnjXsgPVtW4xik1jI0Erow/0djft91W5X/fKN1wiEuxPkP WM8BX060q55lHPXiRKzcaKubXpn9AE5C9YLh2GiP543yyam5oTuHEao/HElMujq3VLprbdVGUXEX bDlNGXmpDCYr8+pFZqk+r5omLRtfVoG/XCtFuc5AAIjyVXGUi12nZVUVqtzAZCqtbqtY3RI/Sbms 5WeDFaP2LGWSPdXWxklzWOlYtzHHWy/DlqNI2PxE0rx8kskeRhZ8x1elo1EqTqTpzNNuJCyXfOt9 mtV1COldp+Uia+cIuKXHVpO9jYail2jDS2tRUm51dD4jJpF06XMFFWf8Z0ygfNE0vHdVV2lZlpUS g4/bw0k1JGWKTz6iiEFZhVkpYub8u0KthCLv4Q5ifyUfed1v3PlrZv7FbfNvTPUsizLQYAVlJd0P lZQZYn8BediDstKMprGMiJ9x9EBkGp+/zNHDNVREkKzlzIzMwly0EfracIokpsrwvtkJgZFxCatc CD3KJKcFB0bJadByI81HWWRupboYoCkIz2UtE/yymoyrIcyubTFWK2qA6AhmGC2nfmB0p7TF1ROR XrbZ6PD2+ABXUgY0iSoyol9t6J5JJKWGV1WWr0okVBGVeV4re/yD31sp7wmhRO+JL9zT90F73fw7 +qY9njfv8exKOi1WzzG6kg4gfaJSU0IpibffSoH0UQc/ixm/iV5NzdB9L0OdmNDq6FrbIW5meTos gvPKmD0mAw+6YTzKXna+hfruIRp55ucikrxC/Swk75KfXZEWtmBKKNFM2xRMxOiqhPpwuxA3PPL1 ejApS8MHbcV6ep/s73H6lpDIw2IPiyHTbfUnLDa65ZyP7qOubjGQ80oLKzATNKg8Uwfg41kK42P/ 7QPVL+YLFUlCl6gJB6Z8GOCpZCVZYk90fKLl5dlyekbeHy0/yyVWiUmWVfUlK+gM3h2p+cesVGxn 1M85XQ9CotZcK1h1VR0mKb4X5g0WbVsS4Z8nvDxiAfBO/Vxg6AMkwmjFtkJtOw0MmxGxzFJN8AS4 86MY32hvd/yA4is8j+a3x8900YdnYDSq56IqrlvQ+avJ82GAL5MY9AjDUuOsTOJ+5p2ou6E+NdeQ dyF3zMWacRNVN2gbNuu3OrDUV37mSb3liqj3LzNZWXhTEikq6kiKcGgGYb5iMceO8W7D6wb342tX vgOCyuR9wDcKdT+YCdhMmUADLsiq5aKsXEOdBC0HHUbE1PyOCjaHmdWjDPUqsY6tMHqoCXuIFVt8 DUM77/Qd3S7IPOns8TNpvHsF0MJxnn8qLn3Ycd9InTIwp8dxEjtO/eiSTfugf3eQNiGFf2WvO8ng TmOo0qNSGl+JVNfqwFwH9iJ/sgsHJDFWhKlTP7lg2YPGHTsseYgrMKfqdtLrVFK1H1RPMOq7nJfU O97miZG8kiio4vm1O8S9bYa9T2mOxKyt8lfGLNG8wrpKcWHHZQPnI8fchYLolgkZcwsct0o2V7Mi S8AK2Es531PhdJIjUJgI+EMUcLUKGH6com6LAajvl/gfiOeoXAvIBfNRwT3XMQ1TQ3F23I15Sp60 MHmtUD3ZmpniXuotkt5gDVWlTGnOfacPvnB5/YrIdQy9ZeVSosuFkvUPmp5n+kxRfO2ZQpEv10/M 5CxIFYkp4tEZguAwQ1251a7RZD9najaqE+U7kT2go4LwThw0a5BUKgqCAWR9RoSZfjMDoozpfqN2 BC29jG9FC1g35lsMzGV2FYycTydVRScWP1d3ZCUzcSEs/jJjEedSnnTW1nmoMukeVygv7vlih+UK RQI6G60Bqku1CH43Ego5UIb6d5OCQ0ZExawoQN9J51rqEt3GQO8P/nTQO0iFQi9Zli64zzmlorCM KhlGecksF6W0oNFiBvqfuI5hlkLG/KmS1QuYZL1tXh2ijoqLPC8Ulg4RiiLezAVwApDshkOAKIBB NVljWhU6gYAwvAwQMQM9Ean2BGgEUzqIskt/zLXE7XYHLV3NLWTuAwaKoQqpx+Yi5VoFJ5fcRuU8 +Sgrzj3pQj1YVM2vU6U4ksHXN17fOp+Ko+TbrKGr3sJwLgQbufgcZZXKtGv9MTvM3+s8YX6DaotT P9dV11LbfVmpus5oepUePbI8SFHkUWetmg66AU9KydLGVaaNk3SYnJ0rRjSiAHOhvReZR9UbTKKI OEua1xPEKfJfxGPRpI1vGnJjTpVCVdtAPGd8Wx5ZkN7iwIG/xa/xht/G7ztkbRn7fGMOJLwiYUKg bmbxoPjd7VmWwAeowo/njy+YeI/vm8+UdAtgLvUO+K5klwVL9wpH4UPxm4hB/Cd788aXALdwxSsB N6N4dCVzSgki4JkPwMcQoYjV/wR84d8cAJoGeAl3HAClAnPmGPIo3AXoNvcjpIpi5KNvrKQVXKVS LgGY9wtFBNLjOYd6XdIukPssV4skweCgmLyESec5yunLqp28rEuucE2Z+sKV4om3SpIik1roQK/1 gwOVribkDFQoiA3ajiwNqSuytHarfwshjO9E5w3Htz0uIpgWRiuYrxf82wcqthQF/yNljKXS/4s0 OurzM81f4IVZ84sr8ZSGM5spVrxvmXtIRMTYmLAv8DSODyGEE55IrFwjV6JrjKwxfiK98+R+j8QW AlUE5mNYP4QglBlE4U9kuSOamIKd8viX0ydxQlOx16B012nom56p0jPeK8V9RPTKl/1XF2nt80oh AkyqTEKlaT6EijZD3UkMrhTSN1a9nYSGqWQ4lRqXSIGrpaqdSm05NphuNELmzgSEQpbBkJ9h+F60 30pjCCo8bOBvC+vAVctE17Nj5EfbTbtei84rId2q8dDqsHDRoPNZzdc1bD/LH4WmVJ8VrywgXZWn RdnkWsXMhXBQsHAeS708MM5VxKzipL5xyqcLHIEqyE+FGafZfp9EoRSr37DVhRivCt/J/400kkgK SSTnWsSQhQoN2q51z36rA0ttzcw2KMq4w2HjtSAs5Gb4PYFpHsYdsOFFnM6aV1aGzjVpbevaik+/ vmV8vfknnskxVHv59DOvQLkUyJrh3F6xdY+VPCiAvb8DYEvFJumAV0222dPtCTemJ7k/aB7gDVpg lbxlz84KmzBY74ljRUkoRf8ePJ4F2PvgMmLxM87K9b27+tUs2xHVKnJ2HNzF108VghQGyNlMt+Ty EuNmYFRFnfDfFf7IEyVdpMhSqUP1GxhckywBBRIknOgpmS0HDtNGsgaw3DahCuk4OMnTiIgEHIID G5IS3TGx2kAwVz1zRQWZPPDE9GIU5bl7TRVni8oZVxCBtFWtj/PvuIhHqdH4zr5L5Rb41tXMcRTE G9Qbk/iSSzd/zJn4rY7nB63WEAYWHJyudjMLsUFRWctgOyGBEjFfj8KunaG6CDE5DeqpHL/l/Bws aq0siqr6FScefcRQT2KKG5SXqWYTuKIt8Kab5D9SlQ7SdJxgcsE9lBCQWVN2LcHTmendUhXGjP5I m7kLCmp80dlJQz5Om6hzKYMML2tVQmxQxzicvumgeGItJrQiEZTMw26YpFh3bMMjJTbqrlSoJ55R TfoIyrXaFvbcgwXzhuaTaCu0exFDssZfxGtxfEbZssn9KXKM4GCGHYVXQQCThMmDtgwckprn98CZ MTcj+Qe5dntANTUm+idGS48cgOP+2Z+oXgXEEv1jejd92ESh5SHMBOt08w5oYcQwDgSfmCDyoGpD 2x6bRRpYo1FNwbaf4dhy3Uhb6TMVQGH1BeQ2u+x+olKVsU2R2uq/jFfJjuNGD36VOtpAWrBUWo/J ZAbIoZEG5p+Zs1rehPaWttyd5CnyyD/5kSxJXtpzsFwLi2SxuHysUvX7jgXCC1LxzQd2RyoaD3jn d6DEPZef4f4Rt+DAEDIxMvIh5kccc89K3ujyfsq32OpsIaJdI0QbIzrCvEEW4zHE128nWegAwEXJ se4xp3OqRSBbQJgpvtzbyMTXcnqny42dEgPsl9yu4JIEM2K+3MOlzxtI5d7yQ6OX5BlpXg1KFQGx RrCkOFqmjQ81EwQedyvyQz/rQdslLbc7WqKAPrFvmNa1um6YT0Fkp8utnbN/F+At+O+BHjuAucDc aPcyfXfGLWjl5NzubL7E131S5V7DJVoEKQu6nU+41H9s3LyKPDW1fmDcRAyW9DBQjItgshikO+eT UQyT97SWD5AQbXczjnQJcRdq+iCgDSRewENjIWeNfK6cuHY8285sIFGnIQWFZLSSkwf87c9hbYDU ON0nv2x2nj/YxKnYmix51dQJhWNW5TTKKKnNkpn68Z/cHh6mgARU/nePPHziD0yznaJvRFuZ+8nr fppyFCVcjp65A1ww1t41/F1vGXPWPHx94T2H5T0PKZdjD9xotDty++lATI4NXOy5kibs4AJGOIT5 7BK81ji34vEae5fuVqgJYl/cR+vid5SFqGOikgZjHJFXCrG11wcr5AUKdZNCA7SAF/REMjvpDC5E kLMTJynE64rJy3hfqkHBlR1zEwGH8xplNDVX5GEzltupAD0SlltdH1NLDzuYDxmPhbbG2Tg1lI39 pN5cYLcyD7jhXhL1KfVJlRYuMWQKtB3lYhNGj6RhTpYsozyQQLfcKF293ZP/RECZ2F+BmrIZ9tej s4spVYecAVHZSyGLpzP6bzcbzQG8WU957YCxfPWwyXFL0W6gOuv1F2hP106oSgwxWW7kfhUFSA9c RfVZK7neXrULYi+dXeM9S4p7NucsQi1pLkbX5EM8v7BLpvq8ZEKUo1TfP5WKQWQFbiWemmrruTYa d1gg//fHliDf2wtgbVub0EaYLtyq5t6JhgcDxWI7bHeq0rvYZqFT3Q0XGKgBrcan9leMpo3YLIvv QayY8kCcW2uB6C0RAVaPSlGn5DYK05P+b/jBpURhjgdOrJz3c3bZZGJUe8zeZc9Id7oppO5stzNF hm9SqjFaO4vI6eUo4C3tSgtcyYl4BrzJRDFBGS4qzl6Ks1uZ7C+OvjeZ/KdpEeJ3euSk/1s98ww5 ajnjy/AQ1zjPKwYfbj9WnKQ0mgG/laGkcfvppiWCSVoqRKXkh0m75YuQRyczQwg0JZxExJvWtM/p flwFtziy4vErsay7llOP8G/CaUwx2vD7imQwf1XxtIUdwjAlkgJ7BMtyTNothLbErxVdsMZdW8o9 23nNV9w6s1oXVzdrHayUlISK48xrHmgIavNT8i1i5J8kBf7mHCewqWRXY4dmtfUuRkRvFpNGf4qF +dS0ksodOOXsVojLMf9X1wkOeIBfKIb4RRj+Ttd/mhaTh6+wr6+GJwEAS8EjBK+Pt0nA8vWWRyVp ch8giNGKIvKVH1YsqULkHQmXe/pQTisGDyxOth56HR5avA4FeLLEc74DE7Wd+pwHIJQSIw4k4twG EzjbC4+OfENhBEfp6oHXQoq4riJSL+BRT3QDzdjXzmwUp8XHwZbkFLIFj7T5lOI5NA1X2ivXQCCJ 5yOo6pdpObTbd/5+wvvT4BsbRzYGt1Ob9YEFTm58ytVLxrJQoJVzbfcPAOeBo2vATmL5wgxWJqr4 jjGyNPJZPFP8OIdPI3yW4uq9Y+7g9O7TEwn7ptnBS3dLJCdJBX+dQCtfdu9oykHxP0QQmB/Vc3xi wWkRSgksRDDCaj8MWUHT7A9veIdAcGIxwnAQububoZPnd0ySUpuSVPnIPYJjut72Jxa5fZbWI/Hm JRYfcQgk8SB6V5DV8z4EcBPxkQa5dy97V8Kgk4w81sfgjARGvQkrP6WhdJ/JJTjrAXEyy0Oiie9k Guo8/KyIMzHc9090Q0IxT9+mADUMH2JFvIwMHRvg+2N0BeSw7Ji08B/nOO4IU3qnJCa0X2ZFLIK/ IpsBPZD9KgEOk0XzRmOH0j/ZzUl6PvmMyd/NtBKkMKl3K6rsfiZgcQhLGCgSWS3MarS40uhOFhvX AQhMBCROjkuiXMjSxe2szY39vcicEdDI06SQWz2TYhXbLuWS8QBsk2r5QaV7xfwFX0QEIkQO4CJ/ wI0e4QK/0QU92teHSk+CPyMnzyiOYsvNsa4Z4UFSwphcuMsZ9zIQOO/V2C+VKU4cIV4WWnzlwIqJ 7FKSAi79IhPT+TLNPrZdXOVRkSal1xgW7GgPFGWCHTNA/cyAbsatDJYP7KEZK0zoLgPCpLosML8W IJgB72YTY7gCelgTJ0qodqRW0rnwO0ZoQUgOOqj+MBc3Xu6Ufi30t5ixXNeEu9DjGjom2mbRKuGb XE5n97DpxwHObhuXWZQkM691c9sXPnxqCh3KeZLMkP4k2yDZbF3byc4Gx5B8Ok1mr4J3kBqBJesB hGVYqvmQ6n1YZJ4fKaDZ0qT25VaA8Lq7gKPiYpb3iuw+voJRCh/lVVlp/ZQ30TYw10YnR/uTajeS o4VI4T+pdhAMEXZOh5y/Isn/oVfM8ezWowb+zRtWpbXNtb/qBS0Cea2KHIXAfaakJ9LWwokI4lSS M05wHsSCEzW2xuFloQePoqaTXEgjSoPq/0F5OzQXIccrBk80HVa+vN8GwOJ5EqXULA0b2wQxYu1m IvJQOElVUkPyfbCf9m+ESDVYEgQLd55bnQs/Za5/te6txARh3WE9RTYpg4g9ZsbPPWMqi50urpXU KSNTZi7GDwIkbxDdj4VrwhXqbqSrK8H7Si1Xl07Tn3TpjNhVRRXwMadlihx+W35Z1Bt0lxx5TiZH II9jTY3PVsEJA6DhJgAB4ECPUSgIT1OAYKZ7ljhnWP+AAsYvivDl6vP9ESeX0p2KQiUb1uYdmKz7 E1+Zl0iZ6wHUoYIqaEFPDsIrHWl2u7zAQGR/X+SZxnwNcAyBc2j4mRn/LU3pYHOFsvYL8HDoT1Ei jz12BaIFlt056RLdF6osGK7OW1iwKZXZmRJfAsC+fqwSYP5j2H3S8Aps9lYoituNFcxCPlpmmaKw R840Hhg1kizd/9XksJ6SInkvU5T0dbrV/ruQZUewOGUySeU00D+j3IJJLdQbTDYijLFNZOhNltaI WGlymcfziGXXbXRjN6Zr5PSLnqKH2LTjGwmCl6WdkTFOuCH4aGZJi4G4uey206pns5rGBbidp8y0 sgfJq48fhEV5n2snA8BQRhWXz3iGYOCZIoaEhoSQqZ+zmZGTIpQ05KZb3eOUw6WWkmplf7XuIT16 GlCoMr89viYOIIfJ9oNNZ3xr8DXJhIv8cPenpOq6q8MFuSwWdNBI7YJdG65IGZZIKrnkzc4xvgeV uCNJKkq08SyNyjhOtEj9YKRiTVuAMdd7uUtYw/OF5AkGMP9KH9oOgY6gnU3dN3nhFEVD2sfCSNyI 36BtnQOLiRvXFxYZASW6Yn63rORV4hNXUa2iuqJlRUDQSeHGErOlQouAW9xhz6+ZK1jaBBQj0KOd jlFN364xk+CwXvANAJmgLJVn8KTpdHCGybp1rcOOPI8EzBdhLgcUh9kJk9YGHGiq9WoJMtKWkTXj BmjW30pUQ/uYR+cFalDOBwj1Jm7PyzjxroyjIi+8N8BEj34Q76gEduO9OQQoAH7n7Sf+PJDzfOVB M/IbIj9t4Dio4SvK0upJN+jg8a+9/wKA77i4owtoG3jbjnHG5p9pxu+6PfDOoH94m6JwW2DAnMa6 t9D/BRgAEWogNw1lbmRzdHJlYW0NZW5kb2JqDTY0IDAgb2JqDTw8IC9GaWx0ZXIgL0ZsYXRlRGVj b2RlIC9MZW5ndGggODANPj4Nc3RyZWFtCnicUwjkKuQqVLAwUABBIyAyN1AwMVBIzlXQj8g0UnDJ VwjkcgrhAnIMjRQsFELSuAzBSg0VjA2AKk0VQnK5NIxMTDRDsrhcQ7gCuQDDnRD4DWVuZHN0cmVh bQ1lbmRvYmoNNjUgMCBvYmoNPDwgL0hlaWdodCA5MyAvQml0c1BlckNvbXBvbmVudCA4IC9TdWJ0 eXBlIC9JbWFnZSAvTGVuZ3RoIDQwIC9XaWR0aCAxNDkgL1R5cGUgL1hPYmplY3QgL0ZpbHRlciAv RmxhdGVEZWNvZGUgL0NvbG9yU3BhY2UgMTIyIDAgUg0+Pg1zdHJlYW0KaN7swQENAAAAwqD3T20O N6AAAAAAAAAAAAAAAAAAuDQBBgA2IQABCg1lbmRzdHJlYW0NZW5kb2JqDTY2IDAgb2JqDTw8IC9G b250RmlsZTMgNTEgMCBSIC9DaGFyU2V0ICgvc3BhY2UvUy9jL2gvby9sL2YvQy9tL3AvdS90L2Uv ci9pL24vY29tbWEvQi9qL2cvSy95L0wvYS9iL04vdy9rL1QvSC9VL3Yvcy96L2F0L3BlcmlvZC9k L29uZS9uaW5lL2VpZ2h0L3NpeC9WL2h5cGhlbi9jb2xvbi9HL08vUC9wYXJlbmxlZnQvcGFyZW5y aWdodC9zZW1pY29sb24vTS9BL0QvVy9xdW90ZXJpZ2h0L3EvRi9JL1gveC90aHJlZS9FL3plcm8v dHdvL3NldmVuL3NsYXNoL2ZpdmUpIC9DYXBIZWlnaHQgNjYyIC9Bc2NlbnQgNjk5IC9GbGFncyA3 MCAvSXRhbGljQW5nbGUgLTE1IC9EZXNjZW50IC0yMTUgL1hIZWlnaHQgNDQxIC9Gb250TmFtZSAv Qk5MSUVHK1RpbWVzTmV3Um9tYW5QUy1JdGFsaWNNVCAvRm9udEJCb3gNWyAtNDk4IC0zMDcgMTEy MCAxMDIzDV0gL1R5cGUgL0ZvbnREZXNjcmlwdG9yIC9TdGVtViAwDT4+DWVuZG9iag02NyAwIG9i ag08PCAvTGFzdENoYXIgMTQ0IC9TdWJ0eXBlIC9UeXBlMSAvRm9udERlc2NyaXB0b3IgMiAwIFIg L0Jhc2VGb250IC9CTkxJQ0YrQXJpYWxNVCAvRW5jb2RpbmcgMTI1IDAgUiAvV2lkdGhzDVsgMjc4 IDc1MCA3NTAgNzUwIDc1MCA3NTAgNzUwIDc1MCA3NTAgNzUwIDc1MCA3NTAgNzUwIDMzMyAyNzgg NzUwIDc1MCA1NTYgNTU2IDU1NiA1NTYgNTU2IDU1NiA1NTYgNTU2IDU1NiA3NTAgNzUwIDc1MCA3 NTAgNzUwIDc1MCA3NTAgNjY3IDY2NyA3MjIgNzIyIDY2NyA2MTEgNzUwIDc1MCAyNzggNzUwIDc1 MCA1NTYgODMzIDc1MCA3NzggNjY3IDc1MCA3MjIgNjY3IDYxMSA3MjIgNjY3IDc1MCA3NTAgNzUw IDc1MCA3NTAgNzUwIDc1MCA3NTAgNzUwIDc1MCA1NTYgNTU2IDUwMCA1NTYgNTU2IDI3OCA1NTYg NTU2IDIyMiA3NTAgNTAwIDIyMiA4MzMgNTU2IDU1NiA1NTYgNTU2IDMzMyA1MDAgMjc4IDU1NiA1 MDAgNzIyIDUwMCA1MDAgNTAwIDc1MCA3NTAgNzUwIDc1MCA3NTAgNzUwIDc1MCA3NTAgNzUwIDc1 MCA3NTAgNzUwIDc1MCA3NTAgNzUwIDc1MCA3NTAgNzUwIDc1MCA3NTAgNzUwIDIyMg1dIC9GaXJz dENoYXIgMzIgL1R5cGUgL0ZvbnQgL1RvVW5pY29kZSAxMTkgMCBSDT4+DWVuZG9iag02OCAwIG9i ag08PCAvSGVpZ2h0IDk5IC9CaXRzUGVyQ29tcG9uZW50IDggL0xlbmd0aCA0NjEgL1dpZHRoIDc2 IC9Db2xvclNwYWNlIDMyIDAgUiAvRmlsdGVyIC9GbGF0ZURlY29kZQ0+Pg1zdHJlYW0KSInsV0kO AyEM4/8fzHcqdcoSEmdhoFLVyQWGgmObtURPPPFjUVg4P4891e77eVEvLV68YSlVjhfKBb067JcT cB4VXh5Ny/mTGj0JzsyEoXZLmE1yeSF66bTOQJxpLRmVDtlqtN/QLC/oKe/qLSAdpo5L8xIbp9t2 T/OdwOtB+uVt/S5Jcw7l7atm0dpFjXZXuHzUn9QrRUVoxRmNNNlfPwAvEwv4gPuKEcAEL/+GMGkl eSEjJNZ8pMg3k3kCf2fdGxqNXqrA6/Pk+eW+pRIaA8mKeFgWfQ9tv0p7Oom1XWMMy+BFkNewGay0 OdIxIb7GON7UrumfAWHWBcmlFi0fz5CZxxGhgg971sCSl/ERjb1hzPphyY4cVuNYlyl1uvg5ZWlU 5lHyeiuf/Yo82k/4xUdH5lHh1fziRIn7GMSSvPj6ymvkDVGNlPQ+pVH3S8kb1Tjybnx0jfzSXfEr wsv1a2s0YV19//eg90S0gFEab6xOYLV2+AbY6oZQQUN1WnCLGics3CHi12kTxlxKxhWNwbfJUaGC CmOn89LFfPFd6PW864aFlSF2FZ9KqfVivVdR4usSqwT62hSzFFHZDmh9eIbXE0/8U7wGAB5o55sN ZW5kc3RyZWFtDWVuZG9iag02OSAwIG9iag08PCAvRmlsdGVyIC9GbGF0ZURlY29kZSAvTGVuZ3Ro IDEwDT4+DXN0cmVhbQp4nCvkAgAA7gB8DWVuZHN0cmVhbQ1lbmRvYmoNNzAgMCBvYmoNPDwgL0hl aWdodCAxMTggL0JpdHNQZXJDb21wb25lbnQgOCAvU3VidHlwZSAvSW1hZ2UgL0xlbmd0aCA0NiAv V2lkdGggMTczIC9UeXBlIC9YT2JqZWN0IC9GaWx0ZXIgL0ZsYXRlRGVjb2RlIC9Db2xvclNwYWNl IDUgMCBSDT4+DXN0cmVhbQpo3uzBgQAAAADDoPlT3+AEVQEAAAAAAAAAAAAAAAAAAAAAAAAA3wQY AE++AAEKDWVuZHN0cmVhbQ1lbmRvYmoNNzEgMCBvYmoNPDwgL1N1YnR5cGUgL1R5cGUxQyAvRmls dGVyIC9GbGF0ZURlY29kZSAvTGVuZ3RoIDc2MDINPj4Nc3RyZWFtCmjelHl5dBxnla8c6K5vQiIg Mx3kqlDl5DGcMJAHHJZkGEggECdOHDuxnXi3Y8taWlKrtfRaXb3V1t2Kuru6qnqrrl7V6ta+WnJs S3FsiJ3FySSPDNsMhMcjjwkMD+bMg2pTGs77WglbBs6D4/9k1Xfv/X33/n6/+2lLy7uva9myZQt+ 766dO+574KP7zJaO4V0dzj1Wy4n+R/beca+179TD+5q/cWsDu8HUuOWGmzcu6VduQV75VcqgXf9e 7SPv0+55v3zLh267qeW6LVtaP/Tx7Xv3uQc6tn1i26mOzj9xWssW+K+ldUvL+69vuc3Y8nctLR9r bbm3peUrN7bsRVpAy5brt7XcseUT13/JuKPlodYTLe03DiFiS8vdMNOWrS23wA9ObLlhS8eWb183 ct3su+541z+96z/f/U2Dz/Bj41HkU8hV0P9XN/1V9Xrb9d95T/4G7IaXb7znxvXWR1v/9b2Z97ne 98/vF25Cbrrw1/LffMRkMpVufvjmqx842Ta69b9vzaOH0V9in7zlzlte/eBRHOB54gRxbtvd29Rb P33rz25L36ZpyLW/vvmaYSP0nwYk1/iFqdG18cZGl7F145Ot+ve057UZk774YW2x+YN/1G4yeTyM y4baJVfOg3tyBaaMVQpSLkfkclKhjFaYgieH5zwuyYbZXYzHQ7Q27m3UTdSZobmeGhjv6cqcwjq7 fANmwjw4dIo8BJy7gju+jD4uHsgexFOdaYtiL1gqtnESeMbrzDRWHxczY8RYppQvlPMVZSI1Bwpf k59/Cf164GX7c7j+no07TJEOxupzgwDt5z0Y5Y9LNEFLrMJXADsdfuFNVPti9GfxCVyYkIrpFJCk VDyL5TN8QCbSHskSOwZGnaMP6ABt1V64dpdJD+vvkklDcqyYULGkHOYlQuISXIwBMWbU1Yfq/4ac iAyEAjjvZ2g/B1i/M2zF3KT27yplHHLFxQDhF1k5lAbhVGT8NNpYQlob+7W9JrcxYKcpluVYmg+E QThoG+nG9P9m1K7TWr7++swVMPZU+swqOsZUqRruqdtLAzmgWPukHuzIScrSRXRZBo6SO/Nc23pt qfo0NjkesJWIki1lNaNHfIeHDuFDh+79qH6DfhsINFCkVVvURNNUZ+7kMbSfHiZduIt0BIcxa39m vJforboVPgqEYDAawLx+PhAgAkHeR6EO2VPw4a7xZfqr2Osvj51fJ9bXqs++gp4OzjrruLPWX+nM T6jlYqYCshWxUkUXqBlLHa9bOrNHsWMnvQOdRJe1r922D+Z5fnpp7Cw2UQ26CkTRlRweQF28K+DC g06/l6K99GCwMwBI5Ir37OBUB2itarebNEa/XUO125/7+a7GPY8Y9Zc37jFojJYz6Tn9MaR1Rvuu KZ95UsZ+8HV317PE17omjj6KWmmby4m7XLbgAOb3R+NBwiuQSWemt2zP+gQg+Hwx329qDPB+L+pO kkUv7pxYCV7Enj6bLK0QK6WZycoSqCyllk+jLw49c3AV333h03X93fHqS21a1rim3WTQXzC2aqHG r007Og4c6H4IdD3k3v4l9EDySOEJvPhErXfWBuxzC4HT2OJcsjhDzBSr9fw8yC/Iy2fQ58m1nnl8 vudk/iDmsIdZB0GH/RwVTK/nYOjibH1ivjI/dq5wWQFZ5DMj97ge7ABhfdQ0VgjYs0S5O/XwJ9HH uG6/GycDXprCKF8iHSQo1T9JrwB6JXTmKbQ0OhN7Ck+VVCGDtWqi16QNX/t7wwZhPKyfMBSM6Vou n0+CbO20+AymfdCoP7DxlKG1cXfjQVNhTK5PoSvkvHkCnzQfUnZiD+4nzR1EZ4/r1HHULPYrg7gy NNtz4dRhu3nIMQAcg8HebvRI/tR8D947v+55CXvlYn7hNLG8UDz7DLpIz7oncPdkz/SR2aXCRCk/ BnTbeRM5To+NoRWpqCh4TilIZWysQJNZIm+Xe06gw2E758Q5J+32kwdnzJNkFWgf2EBMFmbYA4sm nbQN83gFmSK8sl9hS4Aphsan0LFYRSjjQjmRE9NxUZST8vcfXd098hBo1fJrpquL6xdmXgAzL6ov v4peDJ5zrOLOFeu0uQzK5s7UKazLHHSaiR7noNXdBdxddPtxdKd6aKYL75pZca9jOSUazxLZuCqW kvRR6qS9y95tgczfOXzU9ZgfeJE3Yt8uvbQEQlrINOxKlb2EYzbwwhvoxcRCpoBn5YyYwzLJECsR ii/tkKwgc0Dc+whqHekNd+EBB8n7sSbDXtfYY/JQjNMOSdWZo3CPUoSkWi5KOYXIKVKxjJaZogeC RjklO2Z3Mh6KGNFf+8uJ+HJj/y9Msl3wj4ZBlBvlODQYYlgeZ4Pu0CDmI7XXVKMz6kkEklTGPWO7 oDON5TbaqAc3qvYDLrPHs5XyuILDIUBqAypijtnjtAAomc3mUSWel0v4xFWDRhn1vnnTv2uOn+oO Q2u88WLj46ZKNT0xhU7RdXcNd9WGin1ZkOl9TPwipv8P0jhZCvMpIsVJbDwIBDpq60I3vox0RWw8 jYdohgnwgAs4whaM1H6IvPn14tIasTxTPL2OnnMvdU7ig8Xj+Z3KZeV0oVIF+kWt13R+LhQsEeWg 6k25QNqVGO5H+7lhvwv3u0jKHgQBu5k/gmmGx03jwQKZGQaZocRAHzrADQXsuN/hIe1++Ds2bhAj fXEZSokcyqpoFdG6kfVFPliFQF675drnTBF4gQwLGIYOBTHGlUhbiOL+Q8mj2M7dnr69xN6+Y8d7 9oCePZ7dO9Hdyt7Jx/GJx1dPXrSC/ksveF/FLp6T1WViOb9UX1gCX0M6jnX2mV3A3d1Bn8AOnkhX +yBHDy9Qa4BaYy9eRp9LXiqt4bnF6tTsGBibW0ivYGtnPL1LxFJv7Uh2NyhopLH1svb8zatT0XiR eEpaTE/lppR6qVIdGy9OK8tAWRJXz6EvU1f6LuKWZ44tP1IDpcMPpT6P6Wtk2ZhXwmzzGkQ2ToMY HXWY0Y0diHnEEWZxPsAwQQ5wQSrswuyksWFoaKYZb32g1A5qBzL3fxa9zfmFUwfxzv6Trn2YxxcV aIKLh+JhEYQTI7k62sgil5b4YIVojWtvXjOY1mfDXJ6YCo5RqkN1ZM3yYZj/gY2nYR4llaczTcGl 4wEwyo66LM08eiKOMAPz4Biah4L7Vh6NV4yTWqfBbfQ8OnC8A+Laecj7MNZudHljAkMwAieGJRCW IuUFVNuFTI+FmByh0oonPZwZlvriHTDmz1xG/oD/lGsADLr6fCcwn1Yxtu7XfghzfGY+wheJObpG FewFR6pHOAaK2p6NS38Sqz+ao/ZT1W50UzFoCoIJRgzLICRHSrOodryAzE0FnTWi7lRPJnYCVfs+ aQx1M/0+p8/hodw0oF3DoX7MpY1D2UGufQZ2HOtimx3HsnSYxjjYcVDH0zaJgjo+aIn1Yts+Zd5+ H3Hf9u47b0f3pg5WjuH57mrftHXKumA/TQJy5QL9ArZ2TpDPEmeTZ7IrBaB9EKmOKrEEnkhD8hRk QY1Vo0DVv0GqSC4T5tJEioVVQuvDRskBVP8g4uZI3hMCYZKMUNjR9lSlhzCXh+eo84A6z156Eb0g Pp1Zx7PrY4vTdVCfWcmuYRfOe3rOEKs9M4fKzTq9xla9pv1ENf0RWBo7kJloKSbhQkqUJAGIaSVW wMqq/tO/GPYmao1fNp43nV+arGQSWTEfrzRLS5FIfSQfEUMgy4pBH0qSdrMV10f0wwatHZkdLcXf jh6H0dVYBVP175IlpACDJzdpKkaD+O8FDzF4KMAyzFvBnZiD1H6gGofcsQS0G7C2ULO2kdIcqu1A xorax/Q9hskOZcCHMmEOki/He8P2CKTUf1MRl1tIkcRw1lrvWdG92lNtkD81jTJR+z2nyAFywOGy +YHP1s91Y/uMva7RGEP4BXYzQnITvX/4PfRkiF4qB9GbUPVf/GXoNV43VjXK0KrNaqvXPmrSK2Tp t59LDDTCb9d/J2IZIcNoyMP7WYajg6yfB7zPCxuDIzWnauyzC0kvQaXoTEgFEfHJ4gza6ES01MZP DCmjJjV+btjw/zaDP4Twp6rD6Nrsj0Bis8Lwn+yPIlZS9ZJR37Gxw9B6OQsTJpHiiBJO8Sku7c+6 s2TbhhnpZgcpL055h5hOqCQB1YPYnWLGTZBZenyxiVxj78a6QW2sGadjZSGDCxlJTibkRCFej8Ou sZLIwuh4MOcCKW9ioB3VFxH9O42PQ4wQDW980/TAjp6//wj6qfEvPv0Q/rmr/9quvQfT3vOjle9f JdZerL72Ovp/ev5lx0v4jqufmbot9JH4XX0PPAi0N2dNVXfJkjsO1CekHZ9Gv8Q84jmKe47ae/od wGOzMmbsYEdh0Uq0X3R+TzOgP868Nr6OPz91buoKNjNJu6ES7W/cq101nUstlGqToDaVWVhFn3as nJzFZ0/cr34M01f+TH11hvsgKm+oiMURE97u2yTg5UhlHtV2It+4GJemCH2b9pJpdTpgKze3jq6D 6KFAp8OGD9v7/KcwjnlyNEBoy0iTrO7QWkwXXhj/xv+EdX8X1v3Sjjtn/hb70J09O3YQDzzYc9ft 6GerXzq/C197+OqpfybH9swfP28B/ecuUVewpTOJzBoxiYQp34gPO9yeKkMhLNlmqNXX0s8vXngR 6Lc0dpuqhzN334rqLc7PtT+Gd1o7XAexQ6c2obrkfF0zom9mXqtdwJ+bfmryMvbcWcvuKSja2gva JZNm1i8ZtI680T1KCd4ULXrzjrr+Kc3etpycVspFMDedP72GLvvnbJP48KSl2JkCqc5HEv+A6c/9 AZY03J2idojlfRBL+3/F8kd/gKUM+GSkDLHcjVzQvmV6ZtE/PEZUhtOdB9Fuzuqz4z6Hm7LTgLGZ Q8cwq7ZibN3WOAwpP+Tk/TycKp6DlM94hJSdsCfdoicOBKcj5sAeOeTqPEWc6nQdexztE63ZQTw7 VByuOcadq4PP9a86Jt2qT/WlvbIXSFSc8qCDAZvdiTsd/cFO7Mjx/MJJ4uSC9aL3VUDqMdWYyEpJ OQFEWY7JWDITZnNEPVBh8jwIFYqREvbSpeLyKrG6XD73VXTVtzQwiw/MPD5/99LeWneBSjkUSgkq gE2FMwpaSZYKKp4vjssz2OoyaV4gFnrGjsn7QNHIa4PQGs43qeX+AiKu5RfqNVAozshnsPMbsvG/ MMI7hLTJCL9TDHkdmSo3laocyHvT7ow7bUmehDJzP7RDlWuoqV6IcCkiyYuMAIk7GB3uQPVvIXvl J9QePN87ObDqANTUGeZrcIdR6svE0kR1OjUHkrPCV7+NagJSixbiKTyhyKm0BOkmF89jWVV3k8Za KcRmm+fSog8kfDGHBdUryH3cQZ8V91tdtiEP8AxamC6sbzCRcRKODJWjC4AuhJauoNq3kMXoWFzG 40lRTCaAIOdj45iq6j+GSTeYTQqrFMI8PD8kcgIDEmyUDqJMJBD24yE/Pezp0j+gn23Tb9W+S83R 5Yi0NSyNiAk0CZcgARdThfgEllT1V0jjeDjPygE5UOio7dQcG9W2nFFzNuK1K8WlbG5roVzKVCG/ wal949qVzbjjI/mQzACZjQd8aHAkGA7ikQDrDFj0Fn2hTb9Re9ngXWIqIipGxbiAxwUhLsZALJmL NqXy6yRSUppDkuSStOSTfOnBbEdte9ttuqjfrH3D4FlmammYpiQmcElUYpVRSK7L8KOI0kzTr/SU 92nWjcU21ag92PiKdtfGVwx5o9beOFM4l6xG41sTaUmWIC8n45nRZt6XG081Fkyzp0tVScqm01Ja APFN06DqIagD2UgoSci8yCVYIDBRhkbd7r6u4/j9d92lvdf8tCEijIgiKm/mk5Ay8Lucqv8LaVQi 6ZAUknmJkQPxUM5WO6l9QY+26W36p08dtvTZqa2k3870N3chUUUc3tEoS1Bxf4KRAAu/k9GsUp1c xH+uvfcn+m2FgZRLCG6NhkZ5DqVDLMvhDOcJDTZl/5sqQkaphC/pk+11y1n9QW2sDRYlbt7FRKTE pxggcXGWRj3eHstBXL9BP6zfoFkNg+d9k2k0EU9ICVwQszBz2Jevkk0DHcwQ6WDZPLVX+4S+2KZv /WMaayYbiNppdHtjYvC3Ggu9MrSmn0a0D2nc3PPjC7ns1nRSTZRimx3yUtrkV4rcONxNhZRK5FNq PjdGpdv8NBR/LBQajYWJcDQcjyTAiDCSKaHafchaZIrP4myJLA7lQWHILB+HWzcXgKYxMEi6HcDl oG02lBS9WT/uy6pcESvkEqk0kU4lsjk0w2V8WZxO8nIClQQRVipnVaGMZdJNM5Zkf2PG7Gb0KPLh ow92WqzAYqX6utFB2aGSOKmW6XHszHp17atEbEh2Kz5w54smrz8uM0QgzUOWyifUTB4vjE9WlypA /xjicrhoEq7lVk37pon1ekIebNghZt3EcME14VsC3iX29Cp6QVpUq7iaykoKlpJCjERAdqGizliP ZE/7gC+T4wpYXkmkoFjAQgrohLdmreBj1s70Eewr+6x72omeI+S+h9GH8vsWjuJH59dsz2Hzs81n o2mYS/k0lWpzOkmvlwGt27Qa7AUHUs5Gmi+RoURTx2PsqLMb1QnEVXIrpARk0hW3Y+a+oLOfsDht /eQpQJ5injiI7srur53A988+NfgsVikKyTyRh7xcqYMvI9pjCwYVcY/64qzACCEpnIQerWlUGxVE /+DGOdOxoQG7FfMFYgnY25lAkakBuh5aeRa9EF8Sq7hUTebTSQAJLJbG5iZsR8cIiFvjusYnTYvm 9sJRbO9h+zEoL8ccu+5BH87ur8M85p4e/EdsaS5ZmiQmS7X56jqZanNbSacnAAIeN+/CegeyNRvR P+c5F34OaHFj+J/cXzUvAv2QfotJRdaTy4UJiHtGUrG0HOZE2OcyJbhAwhnr2o82X1MuNu4wnd/+ LPJ9JB9LJyRIMlJcxqREhBeIeCgKB5Af4Uc4PEKPcGE0KASTNGwwaFCxYk54q/HSsC2CqkvBFZdF bMcePeLpMxPmPrL9CGpDeh46/CIyqr9qGIp44EyFGY6DzjlEe8MOqPplFbGOuBLBNGSBcGEKHdFe hRbR2+gx7Tni6ekiOnvcHcdQc9JSGMSLg1OOM54Oz4CbdADSTjtsaGcJSjbexziCAT8I+DkfhXpE SvHiincsMMsAZnYhdBq7tCblVohaqpJTK0CtSNUaesY93VnClcEj4nbssyMGJxUXm2/goWQKzQqp ZBJPJtNxBRtZKI6MYtWamJkiprLVfH4M5Mfk+gxaCOWZPM5lAllPDvzgon6HMdPTl7BgzzxmUhxi +6Pofs7sc+NuH0m7MDcl532EL8/NrKGXE8uZAl7I5OQCVlAYKkm8uuE15UMZVoYOiYtyNOrwkYN+ 3D/YzR3FHu8SMy7ClQ0qOVSVs4UkNPLl2Az2rXORcJ5o3Tb3lnsPZ6CsggQTs3ejGx1Id9jBszgT 8HKuJmV64KYU8yW4NOClCNwptAiSLWdyGRnI6Uw8jclSmBcJkRcYyA6x4OhwJ6o/gfSEHRwDD/Gz nrcPcUbhIZCv5XAZbmfbkQvhBbaMs2VfwamCnGNY6sfsdj4AtTtgcw0NAi2PtG6Y3rj2IRNFsW4H 6hBJhcIpRWVLWCkvKgqhKKJaQktsnoLNQ7lFB1xlWIoivqIfhmWVRxReCgKRjjt7UL0IM3KyLB4M UJxjBGYUVRE7NKVMEmYUapb1a6TZ0Dc243lZt/MP4hXV38UrwnhZ2CJuEa5ObpbyEtvfihdRoOsB IhP3OtCRQYM+h0R1YGCi9lgXHnWO+jjUHw7yHM5yXJjFaC4mcASfiEhpNPqkMCriwpNCHFVCKVbE RTYY92M+Px8IEsEgXPJQW9JZIHFPYYJZxpan5cIYMZZXq9IUEEqxmTNow4K0bpv5c64z8NZNsBLg 5BC8ie8hE/X/rW81ZJ2il0X5cCgUwkM8Ewlu7m0IOeoVAylGHJx/4kW9Rftk2/r66srEeFbaqkiq UGj6iRPQT4Sz0DkBcVM56TDNB3Eu6KPsjltva4NLJLzH4mZu8E44iW7eiaMX3bD8/+6kcRXq4N0L jaPvLEtPv7Ms/9sNlmz64dI0qo0g6piaVyBjplKxTLNLueZflmCXBkE8MDp4EtUPIgMjZKTJKjzL 8iwXDPtG3kLIAatmmg0fLs00j1KKWUVJgWQ2K2Sx5G8ano4FNo9qbx7VG3ZykNv8Pva3MMd8Aic3 qanZ8LuRtdD82w3vygLFNST2YoNDrG+YGPYNOQb7g3VPyZkBWfgf/digjQ84CHtzEqzgOXi3c38O CJ6mu/EnmkHhlM02M18aGy/WMel3MxpszqgNuvLjzZThJsXClMnfm9HNznh7Rp8Jz/EFnBvzlZw5 oLqG4IwO2biAnXD4bW7bELiMtL7ZuNXUcdi1Zwe6s7B34TB+eOHC8CvYqxfHn1kmZlZzl15En6JP uxdxcnFwwlwEJXNnsh3bcWD4UAeh7Z0wNRUl4QQJR6xjH3pHeCdrwUNOxuMLACboD3kxyptIBwh/ msmHK4CfjEzPoS9Fn44v4LEFqZpOg0w6m8hh2VSYlSGhaUrcFChXuCo2N5Us1omJYmlCWQTKorh6 Fl1ll70LOLXgmBgogZLVkjJj1iGWGibIgIf02MAV/bF3sMaGE2LkYplmh/KbHaqoiI2KxhmCiXOJ 5lYkRXJjqHYPkneqVI4BB7T/ZTpXqo3NYCU16EoThX758c+j9zD7yQHc5ffSbqzXUlyyNqV7fvNG c5FUOBFKhISmt4oxo54BVE8g7aFhNoiztI93Nm9mdNM4xJh4Myp0jtBGpwtoDfm/yKIwl5zGxWIy l0k190govvH4SCRGREckLg1lPqNwKqZkEukkkUoLahkt8rlACk8FqIQbc9gZykbYPQN9liPgP5Dm Q+GzDbOJ8fNsKAIgFYxwGMfGBJpI22yJIexot7cftqvV39uN9qb6SwO44p4eXOuetZVJOQCSfsHn QX28PxjE6WDzr8O24VRpiBgqOaepVUAaJf0ug2pURVlKYTExEk4S3vkJSK/1cTFdISoZtZAZA5lq olpF60yVquBUua9+ZPrwdH8lmGkOEnT6KSEly7gsp+MZrFRiyBIB3W5v8ShQjaz2CUOTww9fM5js 7UPd/b39vd19J/sBeUV/EjkUtcQCuODMuItwVyxWmQns8urU8+MElTL0up0eB8bxUUjJrBCCpAzC 4ohaQ7U5reU85L3PwxHUVv7IDIYR96CH9NGAo+G2iDFMVGAJTuBF6O+aj2iQPq7qu9751Q7k8Vin 6MBFR9ZVpGA2ZWYcq1UTqTJRSpcL5XGwS9v1Tsn8FSTDnM+kfUz7Vf5MdlyWt0IUhGzzlfUjJFIY yYRFtknBTBB10xbyCXy3fvsXtXsM3lmmsrkEShIuJJIxBS5rPIlkw83nxaRfGcg/oX1c/2VzD0rB 403ar7OnU9W3j1eax99CIvmRdCjBgQQXo31wqfIwNvwR/a4Hte0GeozPSagYS8TjuBBPx/JNTfCS iBJOhSRWZCVPcljwtz2ob38A/nawzqkCmogJCQEmk4o2k/GQiMqn4UKapnI9+QNaq/56W9WovVf7 oXaT/kPo6P5D+4WpPFuowB0onU8UmwE+CwNEkuEEDxKhGMeilHdosAt3D3S9zCgheSS2Fc6IIKBC NB6N4YuyQdUFOGwjWTgUmUDBMn74O/qH2zr2de8f6HX7tvpdTs4OBe9+FaGCozGe4KN8PCyAsDCS kFBhVIiJeDQuZXKVmbW25S8Zkk7BS6NsJMRDsQz5IpvsCzdTz6g/TotU1j47cOFz2kfbWjX3HhN5 iOrzeQFNMzyD8aEo3Nsi8YiUQct8LpjEU0GfQGKkl/NBnvNzHhdql905D06pZaaGzdaztTKRK1Qv zHwfXs2P2irPKrPJpJx6+2o+2nx9zUKgQfPF0Y+6gt2ug/jjOvEF7QGDZ4GuplEpLiYSuCikYrkm cnBPV/gMvPiUP9dX3q/drv+orTk1lsZ9pvp89vRZdDE46SzjJedwyorZXIyHJDwk47ajTtGdhY4o q7Jw+03HBJmIxWOjUSwajTQZJzwa4lErM0AO4uSg1dHpAQ7kkroyXl8ArU8+aWyE/wZ6gP8nwAAF YCNbCg1lbmRzdHJlYW0NZW5kb2JqDTcyIDAgb2JqDTw8IC9MYXN0Q2hhciAxNDQgL1N1YnR5cGUg L1R5cGUxIC9Gb250RGVzY3JpcHRvciAyMiAwIFIgL0Jhc2VGb250IC9CTkxJREcrVGltZXNOZXdS b21hblBTTVQgL0VuY29kaW5nIDE3IDAgUiAvV2lkdGhzDVsgNTc4IDc3OCA3NzggNzc4IDc3OCA3 NzggNzc4IDc3OCA3NzggNzc4IDc3OCA3NzggNzc4IDc3OCA3NzggNzc4IDc3OCA3NzggNzc4IDc3 OCA3NzggNzc4IDc3OCA3NzggNzc4IDc3OCA3NzggNzc4IDc3OCA3NzggMjUwIDc3OCA3NzggNzc4 IDc3OCA3NzggNzc4IDc3OCAzMzMgMzMzIDUwMCA1NjQgMjUwIDMzMyAyNTAgMjc4IDUwMCA1MDAg NTAwIDUwMCA1MDAgNTAwIDUwMCA1MDAgNTAwIDUwMCAyNzggMjc4IDc3OCA1NjQgNTY0IDc3OCA3 NzggNzIyIDY2NyA2NjcgNzIyIDYxMSA1NTYgNzIyIDcyMiAzMzMgMzg5IDcyMiA2MTEgODg5IDcy MiA3MjIgNTU2IDcyMiA2NjcgNTU2IDYxMSA3MjIgNzIyIDk0NCA3MjIgNzIyIDYxMSAzMzMgNzc4 IDMzMyA3NzggNTAwIDc3OCA0NDQgNTAwIDQ0NCA1MDAgNDQ0IDMzMyA1MDAgNTAwIDI3OCAyNzgg NTAwIDI3OCA3NzggNTAwIDUwMCA1MDAgNTAwIDMzMyAzODkgMjc4IDUwMCA1MDAgNzIyIDUwMCA1 MDAgNDQ0IDQ4MCAyMDAgNDgwIDc3OCA3NzggNzc4IDc3OCA3NzggMTAwMCA3NzggNTAwIDc3OCA3 NzggNzc4IDc3OCA3NzggNzc4IDc3OCA0NDQgNDQ0IDc3OCAzMzMNXSAvRmlyc3RDaGFyIDIgL1R5 cGUgL0ZvbnQgL1RvVW5pY29kZSAxMiAwIFINPj4NZW5kb2JqDTczIDAgb2JqDTw8IC9GaWx0ZXIg L0ZsYXRlRGVjb2RlIC9MZW5ndGggMTExMTgNPj4Nc3RyZWFtCkiJ5FfLcttGFt3zK3oJTJkw+gGg e5loxp5JZeEpSZ6k4ixoEqIYk5RCUda4aj4inzznPgA+RFEqV7SQY5fYD9x333v79Ou3p95MbwbW lPhvjS0aZ21jyiI2IZjxYlCa6eD7Mwxnq0FZeGfN2d3g9RsH4rOLgS2LMgovz6pgGmsL68zZYvBL ts5tnV3mQxeyUW6rbGlO3uUxO8+9y17l1mXmjqZCMcuHMRvnPmWXhuc39M0w41zWMbvKQWn493Zl cuchWD/R3+2CVtf0eU0zlsPUS/Mh+0iTDzlxQQNMW7KELStbUsb0K15/YXX5r+bsh8E/zjgQRelr igG8rBtz9uOhGNQpFb6q6yBhWPRWTGjWklL2qMiH1mbmXxdskli9awtvLsUtNr8lgpVE4IKtew+/ N2E11+LZciNjwmQa0m1XyI2SXHj9pj58ns7GIpQh7nu0E5IhSJsy4d+hcDiHZCp9RGaUROi8Jsf/ 9sJaVpU5Gw8eEeaL5GJ9L8Qn7873XBs/ZlewRfK2co/Y5Vx63KxQF6khWXtmfShRMfuxAoMIRIVt TuCBinK1K8p0QPQrHHCJ0z+hc4X3BxK1jF1EXVNpzgZ/OGeL0pJhdWyK6CsNxV0eyqLKZvO5+Yjk wpRyF4NBetmqoFrh7bW51o1ZHiKG7vsyjxuuiW4aSWTe+7wjt2MzqvlS120emu3PJOCy1+gChqkI 6nbNCWt+h2LAcC7izOhCqDBYZi23pKqg9Ze8Ih6zHt0I9ycluFEpK13firDl7ucid0x17zCcHgaK gQ/jwTNo6sJb39RyCN+REU61RIm4Q6OAsU7dlZ6C5QpOu87AKGFzmfjhOtYlvAYRaOrsQrb0S8dn 9qTP2DXmQeCvr2Q1n42FjAPWfZ2pso0Moh2xYbolhOs7EaO6Ta+MGaaye6m2xmykpuogVMuehwWv dyxZd35/uqGkdAeORE7EBXf8QOpQNKlvEOvRJ+q0M27NHMWp9O+UrSkl6BT0AxmASFxxZ+a+/1/6 aUE6psmt3D9wQm4Fzvu+3vg86l1FJIilMr0SsPzbG+4BLHc0xsnz8TEhthd8LmSQXkC8pFx9Utuw 8WDjoxC50tamrlC+1kcrIfqnFM4V19edtIT2cyv10pXPKy2U2VoKj6t6pjVnOqe3u4zSKcktS0c+ JBmIhFKSGslsr6GsmbbTqM1MBODK5c3fRPqtDDf6TTSOOmlqqMbVMyEbo8M9tcwwU/658quRV7v9 Y6LEe7w9FS+LPOw3F7pTrB4ZsFvX5+3xA6PrL1mvTeYMuQLkBd2cGsNGT2NrfZdbTimQfcm9pwKn j7LTIqaJsFhHLpxjw4uxEk1uAXsq5D+nQGZO/8AYikTKcLFTJIisnYgcs+DxCpJlh0ODo46d+AcK 2jrf36z3L1Rb1B7lvB+C0VrqSCrNoHmE/ZbB0p94kfqyCLiytWd02I2hrLd89Nkd4T+/q+P1m6BA wIlYx4AS0qNICsRUZmHPMIIQ1T5nnQiKbzHfK/XQdJeS9YLs76nHbUT+bIT8Pa+Lhm7WCsPwdIzW 3nCjbuAhzemYncNktpya75haN6ZXhHgLalyOKNHa8Lu+XBxI6FosC97VR98cNVp8MBXQURm2k7mo OSsBYCUvi5ozs6gleTCOzalscD2GrGfLYUHNbuCsiGGpX6YsDtCL2Im7xvhH18+4ZBYqfCRCeta5 7n+hcg7UUtQIoRtfseiO+1rHOcvemKwekKVxYyk3H8hcbzxgh+539qYrEHnIHc9jl2pTARBWNlZa JALhvFz5jbYueoRBX5MtpP2iWVzneryBqWL/228JI1/zDULHYIDSiIlUjKzQBphnxCn2ifdaIWDH G8UajeIV333tGGc5rVTVivm52HdcMCqrFZ7fRcStDC2dtO9px92uqLkSyRdi7f1M7oBfZd3j3Vmi 3lRoTbXV6/Q9nbrLTli9Q+nx8pwMBliT7koga6mTaauUBcqPaefrjojyLMKvoaCsYS04j79tej6D tZKlj5ama+3Y/czsIqSjnBjuyzeiSr4t9FsrikxnWjsdqW1rpZjtSG5Ne5HjDYJoClk77ggh3zX7 MI4ijPIXHJea9DhekQATpLMdxIZJnuVT47/B9YKABHh5J0AOUzOjZ5bO3ygsI6bp7Yo3W/puArUG yJjztyuRO2E4Wtjso6znRIppUnljmhI/SAwvRqqMKWrcgGtmNB9FS7vhFZtvaWPFpPxtQnfEgUD1 92Osq6dmIoCdTRXhC4rU9wI9oXjGmictQ+0bfY2uJXbeMQ2coaplINxiiiCyW+TKG001ArW32F4p F6iqXI5B3ngUR9q4uyHAgcnlSNA9KXh/QgF5d84Q9+eCjbCGQlnRkyNbTojqIZSQwhN7IIBC3fim r0ZYgeclPy75aZmZnwRND0NW0mOlh/HUmDK8Fxj068MqO/hI4JfAkx8Kr0iVmfN8NJFYxs0jwfeP ju23QuxeCrlke3y4lKy3jyQI8FpyNIIYjU0rqUtfKBiTgsuuOIDxLmSfK0kKZLt2NGVP2YWrV7Ja b8uw+ipYaKr0mrQIVlu6qHJlpjV4JU9XLaStGmdIikQ2112J82lg+p6nJ8z4jufn97Jpgwgfio/F Pe1iVBw4YSWk/rqlk1lJ+eTq34R7wxc8mLL9EkYzbqCgSBY/sbJmNR1Yj9somJAA0YI1gFTRASU1 Raq8WbWDi8Hvg9dvTyszvcFRAuM1bCEOOqXoeT5ewP63kJ7QMeGG+QF/v7Fk3D5DEh2BGgitNd4M SXZk2aeDf/eySzPdwa5ARaWvWD4eRXgUWlQQWViVHqPG4uTdOR5dx/yLuJBLz/45dKyD/h3xa88n SKuqinxq4Jt7wCf15Z4LCY+wCChOLri62bgwO35EEYlQh10f/Ff7QOLqyn6tEzZG9LQDTiyOOuFQ 5Kn505wgcWTNVzrhkJvJx/tOLHsnYI3UorEVAHLtTKipqdVizn0PiXgBVaEmRjxR8HQzgB+um9MA 7kG3BLxGQOb9OkGcNyLAoXZQlmU3GQ+GFgHrP8wHuKAcHNU1HoEFQKLK6FaigXhlzQbMuyXbpmIQ cJGPaLMn88HF3xDAg2ciAbF16kISwqEz+qUukrMgKlJAwf5amskmSJXGCHBrSIakfqWjxIk34EZq NFC8AS/x6mQpQwpAQ/Z1MwmVjf2GxArWdhudxE7QZi2jBEx2ROV8syPGqkQJm41bYbvkxDtYOUFy FmcCoXrbvaes274PbOHosjzAHYqYfElBR09rYhQBPxf2WM4CNaLMXlbKVs+ashwRW8VvKGXjTsp2 up83iT01XPtAEh/LXk+Z6DV7fyrKA9nrAi4JoGZqLy+u4T5D9ko8QkoaEVtWh7L3xWXqn5iXziNE eGJSc03lk/PSUTq7hrtqg8D7vqu6Y3mJHhKq6oUl5jMgga3E5JDgxvl2uuqzAYE+V9FDU3oICBzL VY+zSBsEcKiH2pRwns1fB7Ueufw5FBXoJBhN8C+0fT4fNo0IUVkpNm2efK0nnIltelCa+mvdH0tJ gWAvLCW/4l5/Ukoew6MvICWf7UaXlKwVaboHUhIBLUu678cPZWfsQWfos/PQ5W5LV5Su6iDWt5+d O5d79AUubx9RxRGhRzhcKhDNVTv4z2B5MIU5XsF2EXN/eVBaHszCZKESuFKQ6UN5bJHrlMY/HhDw f+6rbcdx44i+5yv4SAIWze4m2c282XsBDBjZdXbXRoB90YyoGWF1y4zkwQL5iHxyTl2aokhKM2sg QJx5GJHNqurq6qpTp8AWqipEilqaMqax6afxxA2VTe4rA/kX9D1cTpHzwT90JVGGvCop94venwGb CMInLiuC8Tnyw9pqWvKXs76AmDuXuMbmjX+GqpS5r6liAvK1Slweykaf4WxDhSdvuD2H84q48blp uF7lAfdNH1x8n53pzM7tzfpbzeL+xbMIT4eyqD091iTAX6bG2Keq5ZzwD5tXlT7zfz6m4QR2qHaR nuE4lqs7PslBoRoXZmdqszOLs/5es+iAHPR+cGdNyIvy/+vG6EiuQaVeu7D/4cuZbKIm5IZcKDA7 4AsDx6vdZrPbJoRBfQgCRCCUUwhkYcU7D8rmwFuqBgESS+9X2227OLfU76iAPmPjbPgn66h/YAQ5 66iTLZMCUjSVhsSj8v+cLfO/NogANYNjxhYQs0uDCLrlpVZpStuQOsLfxHHkH+fjyPTFUF97CZWB DkS5lYXYy+DS92+RJ8nH5V+aHClPovxga1x0YGIV1Jsxf3WemAOeDAL9ERvmJeUfTvj9WzNl1QAw qqZBUqIqKfjeiO23q2xGxZreHTNb5y59wLvFeyuvyN1eJIrEo5JrGJx5pimR7qFxw9snchCBfhBm U7Br8DJIffOTqQisxI2p8xV0irFShbg3qIO+3sezGx6q1BZjUijPt7q/rhJQxjST9lXaqyoQ9Ajs 5fOMNZCELvjzoyyuqgRLKGj9N/gVcJTCGnOmsryqggv1lUcavXyXBm0o0CjaV7m9pmIxBISiAnXp qxyuq+DyLVL95UG2BVK6qQc3ubuqYip087p6ecCoyZkKQf4GvyywxBFc9VU+XFfx1LrLc8f+fVUF w6tr6kvx+iXCiKlKhRFL4PF0gqShxRoTBcxVgV6k9u6zmWvyMm0f4sMy83mNIIN3pN3id9kMByjT 5CkzSHzkE3bG6x4SFZBO5feyvMtm6D/pYzYjnTaZQ9uReFwRMcKoCr8r/dzq50SMLfl/1DmoUHRp Ljbispq8g8kyr85MMv5FFx7F/0SMy0Zr/RZ/dyLzpO79NZthICpH+MYhRxNh4DZo6ROIpxHHXBQw wWnQP5PzTfo5yzNj0/0K26WgZVlIX73Hv0+Zs2mCgwV4Ykt6hAAuytIxTQVH8NQTfaL/K5JnpXt8 d+mW5cWAbrE9mVjw+mDLuZiAqG7JNh/52zlhLCh/YmeI9HF4duRFUVA/cQ68wDeFzq+H1abNSp/m mTVjw42lDqHRRUZPNR+NqiXQxhSiQc0aXPQNvMXP54zfcpwYTXDPL6sMFIcDgxTxdHp0U5e+4o/v 5eVTVhpKl8Muc44fROleleB4oOVJpSf5XR3u+WuyViO6jlZcamfm/XVZheLylwxndGnUnS/kN5/M PnTgy+Ex1Dlr08Xnli6ekm72B7IOObHuvrElzhZeS3oGOGWWCFqa3GQxASUt2VSCe7KlZOvnjDN5 TtYkNyUtP6fsXJRZiD/0r5fUkqeDoIxjQUloLKZDh0nIg2fpBHPP7u/3beYaNcvVOMjHskaLi0lu LlV4RfVgAyhaY62P8V7EWPOpdnSA3I6PsOnOekeLD/OukLtih9roNn6lcMfAGy1evhjWZYO/Z1Ec 9wTxr8hehYsenGylwGegzkEiL45dqv6XFb31aCOe8ZHCcdxeAKGpqJuC2t3Lol4T9Q+ug9a2n+XH U9LEhAc25iEdQeqgDqYgdUrtVBOswYuPmWolv0t6xzo5ynUA+hNWWXJe/0A7Dy6FHR0Co+lAMQhE coBqf/0a8OQC6E1kaDTmKZw1Akmmqy1eOxLgmHRzI78q8qBfk50sLwlnjQChESA0AoRYbGWXf/K3 I/+frx/HAEZHKGTcqacZi6nppxydYzRL+UJiMjF00ARRojJhA14VhRbov4YBrioN8DVbaAZ17e3Q Hwyqo+M941agAQrAdMUrZnd25NVFfmcwbZaNc83QvfxC/4bVMlytZ+4lDbyzJRh/De7YtVvCeSAP Wm2gRlvipgNnEfFALh/NKsJpa7l8sHLPKy1xFGrBNRpwoASqKX0KkJUsRNVojoUXeE1upMrwCgJH rdNyZrIIamm1lCbEGyV3+B5E+lFYzU6aXN+FRwE8KtQD05JRanWxeqYTcKsxGG4tkNSVxijf2ZGr ybtf3/Cuf2dPiGIylYU7PxE2vP4ZQm84kobKbJQGlZa/KWsTKWe4zDn5yizea1vb7sqI0BpCJK5p 3JwsgN1TTScsATwFiwp5c+X7LbHtCQPzLbNzQ5dFp+i2bDsFXp8/qFzL0HMES7cEJ+0iIQWm/g2z 8yaNosmXNhoDlhMamTRud5dkjdJ3o2pzfVvIzmL35uzTunNXz9N+NxH3sot7+WznQ8QdT60Vrl8r RSemOGjFyeT2Xlxq4xQUJ5QFzySdmMw18eNg3IkD06Eb46hPIb9uT/NOf+KCID64wJYKEpwDwWX/ 9yL5SQekOx3iuqHs0E1HPJb9pGqv5fPPb+KMNziverRVBy7gUOnsJfbGMTWNx100XktqM9cRB1X0 NavgjqDAkep7K+AhrRfvjBnri4Aj0DB/mMSE1Zr+r4mrF+lccKWHa3dkmrGPUr3G3eGdAZFnsDmL bnQHWhFgGieZU4ipjHshyJiA6Dde6ZUUCc0YYLnp4oi0cTRGrLb64Q635rtEcXItWLjd8Qe+ZKfp 5QifaHUpSkcibTVr3bYqqT9zVYj7fyV24InUyvpKf2X7KDVnLw8DGQJnLEePc8IUuPJbm8z3exR3 5WQDEhJkIWK8zDzeFYlcTFOXygm+YWo6Rda7HJkWqi60HWFFXDlJiPqdcUEMEQkvM6dbMoU7kXFi hEL5hIsO2Oaj5Ev8ynZkvySSZvnhzzwlJMtuuFp3/HJ3Yq190eN+oPEwqEJrnwkIGFRZ2TJSyAEH Ps2M/MTjnMyFeymXE+2X5zs57HFDQjdZNCSBTjrOzGF5PPHiE83WKCqj7zh/onMpzzQSzjL0R624 V913ejdZklZh3/ryemyqIm9s02iybBhxjuzfLTH9ex0tZwY96MdWzjWTic/RaDgjFk4yskydNLoH XfAREeRgfNEgdhe8kEDslsioGSMbvb/n508oACNWqf+xNwKIEpfkhJBr3YLUdsmNjCh72ZhuzlsZ WxYTyOUlTq4mBvvcYGiCTwy1hSIQn6GICYJ4aXT4obqNeOLpgChrH3HMI6VlQevcpyJPlE/eGZg8 zV6hwyev3MDTzbB6m4jeUrR/EKVX+hWXYNkI9zKnvQxa2273bulrZqnNJXetfjswl/GUbX0Pbr+M PdeFMeHUoBZlWcdJ72I44WkIPs4PnzJGv7+9ZrYJ6+CblSA6/zLn5E1x+z/K2rt3Hz6q9MVBwTST dUBc02EcTQwFqq5q7Ue/UbOTZio5u9mfuvCG/28PlNLAcVNIi9a+SeIInfZ1qSTm7RuaDGjGOHTj wR1pjKaK+e/dlCBdfU5y8u2BbXARxOmiZ43o+CAANjzfkOUiijIPEFLad1htZJxg32UumSIePd7B C3uJXIOCIL6wOp2Fc1jDgnrg2DbjmYoRXt9H1Rpphs6ST9QTJ2bTpsprW40Pddvi1tB3gQ7kIlep 9G9kM/CBeTyNMNTiZlpQzCyJV0pBeVVY639zkRQWmvoXJ50u9o3Lq7qstQZOQyKBWGAICzIhLuSK qSPoLNgPH13XYBpl4ie8D4R9MMKS/JrtsFgrvDHhK5uvj6AFNBrZaOaenOFrhSlK6FYguKOyj7zl KBqKBrauXkAOOR7BAjustbFjY9zz7DWV+wpuMrq9YopEh809H5cWwfv5QQnio3xNDsrOGPnYTGSQ KnFgTjeXRXmJEqq6VAs/8bavRe1n8e0NKyQbFX0Y7HFuobNeCl1k0Tx5l5nAX89OS7fEFs/poPkP 8dW2I0VyRH+l/FaFh6LynmmEpfUYxEor7WjN8oSEmrnAyEPPaGYavAKe9gf8yT4RkVXdde0eePBL V9clIyPjcs4JCVsBjRm9QmOQLnQmuFScfhzUofasjx6TDGrcVOANBdQ7bYqgFB5Yn0MvULdTNFwt 6BPRL90gUWwBQNBNJpz74awxLE+pvtVZ0VbWak1/VywM2ZyU+TtBFcJXBzUgCLm6vFrtDEd/mxZC JuUoaJcWGX4bBJAW+rFDDRIZqk7lJ+RNkZKINWMHEpO6l+/bl0hxErWM+1vmysQDBX92/eky/1tn A7JQ5q0HbRR5nwviY37xIX9IapIsruSTbudNu+M9qQVZe73uFrHCO87+nnD1pSzC/stPRfnR06H+ bklmPqAxoqFVsN1IAgG3obHgsfNZz5Gqpk3uWbaxSBQ1yqITkkahDi6uZW3RikgrOlsWrUjkycPT LEwTa1esfNUq0phl/w29ZA2T9aPoRV74B5fS5wyTpCbvtv+vWq+SfHy/9ZLlMDjfWHTuZ/iV3f13 xcFj1TrJFXvCF3ztdJO1yeeq5cqrq7rSu/wDLZ/YAv+xdbJKWVwtZkaVgUGIlJlU1VpNArHRTe1N aiwEEo6ijM148Mu5qD83NZmSpScvPFDp1cXYpEEludSkock3jTFjojdZlhvPnPHkhZ4xS+joko5D s2CoJskAEWrTwrvIcINEMZxe8OWaf2/zK2Z+XI8zAJ/I7e+ZSLK9c7YnwTCtodaEGPwonLC6yh9d FWfXsvhjfrK6bP3JVml6InP3H1b5xX1RKdLnl3kJfVgeDRvQa78tI2hdQfn5XGzT6zQFrUU6ysUz Eki1Lr9U2sfal68rHVRNs5kGP3vEA0BaE4APC8DXyfMu/MdgdURaMGAqL+ZV322lI6d55F4wtW19 Iw1Fa49eV8pIXhTcp7wo7Tgxy37YpgGY9/zQh/kBssS7oR9/Uh9Lrhivvtsv62rNbvkMi18H2OBZ NA5XYS8X8nlcCn6+iybXO1QRtObCzqMwcPR2Y/Bt1K+mkxomdrJ8tmmtp5Q0Kg3s1oXgi6qHQNlV 92xN22jJJjR03yYCY3dNDcKRVB36xXEzUhA2ny3YRSiyKQClB9sTqcXynZDI/ZCDdlhFWIQ4eQyG OoNhJHCjDtfRz8I2tBt6h8DDhSaDIUOa7kOaFkiLgj08SlBBa3IQq5lN+Z6gM/LoQ1/DWYQiQ51u b2lQEdigYcXRn/Mz4uxIL/PS1vB5t7jd4k4+mMn5MrHYgI4IRKSDQ+/JPNcL1uDs8v3mZsTNuaqN b/Se1DuMmeKA7/jHBZ5V+GSs6mNW9TLd0eO7NqgifWRQiCXRyWQ4aoio/SVgEtWh9rVJQbWnWyNF KDYSXYo1FyTOe9Y5r6FOjk/w8zuJaZJTtajBlzKIdp+fUtFy5R4NCCgy/6AUlE0HpMwQaUcImoGT wj8o+LIYZm9bDoM8gmao4BFebSc6eFwuhjseG9s2U/20k5lxYC00GGCTGA1LFbzfcqabgowJE9Gj qILe3XwfPBniiJ2zjYpUdeDQpMUadQ3Gyt7eRxgRtEygmOmmg02nCU1KKS1m1BlgROC4hhrjqI/T lLY1NbZgERyFaa0fnRGrLZiwmHO01eEHvKBhSKsYdr14NnSh8Vk9L/Ugl7eCkjFdeRfFVwK8UdKn 1JNxTCaKdpkoa5q6vJtUTxbFoGXrlt7/+hVzgoZqP2RnP9p5s9hRJlgSEr0NRxHLSKr6+DAn6gNN Pjb2bAKTdFMW/5DpB7R1yeR5VgWZve6O5IOrzKmkzvsBCzL1EGFF5ZbVBNVzwzprxwUCJf8Mwjgq SHLchMMQCrZ68RzqYCH4sUpyxCa7DhyN9qwbVBsX80hfBtvbVB8Nd50WvTib70f+T5G6avrEQ8RK spx11cGy1jXQfCYa8Tg8WNa6JmA9NdrszqNWx2VQYt9msLVJbn/ROsgf5GJg8gjix1rmfWZ9HhLl 78M1LqGTj073txhmZRAZyNHQb+fL3a/nz+NG5TeSpq00bkj1sCrxeh4ROT2YxoKi0TO78pglB7Vs Xx6TXv60oidX/M2GnpyzDCGR/BMvOZb7i+vbOcBpRLnt0SOoHqc8gVjfveL1Me9zwnpoPNFNdbvh eLkUSV6O492V1byYNCImyRXdDkaz58sTgQtqUnNkPRhU4SB4Y2x0HkxeXBOQ3srUQXi64pOeAjc/ UNTHO6YDBTl0L3oRk9VwSw5m4GDqiWAOaIhwCBZ0F4RBGHXUnebk9hz5ER1ngp3oAFwpxhRA+MQR 7U4PzmUHtQK8bfqGvwxFZCNcg8QAEBajpRNrYTScx0wUfDuHHp/sDZElmsQ6iJ0co/+Mhkff1klc PJZxioqOfWiD9ewHasDr2jZmYHGhAOZ5zEA1q/4pL2eAaP50qSEFvevLY4aOv6P+VXlzy6BzfZox JhIi2Sbj0rW8fYpPzWhYkD7k/ptuv8QpcgQK1mT/nzyaDexSTDE1WdukkbmH9ZUHSsPCDB1IG4Tc WRDkSqTyRHt5wxXjdvjhA4NIHcq74h0UWG1K+V1X4JKyuCHJhobO9/IrX5wV7/4o2tf3FSQsbHxo H7zHFWgIZMIoZIUYeJ+rzXllFNm+vsjfFD8dz9HqHNORBZOM7x3m0ZMRDFI/GZUBV/p6MuFiyxAM du3880VFVPWmHDi3t5OsrjGQ2KG9ZdYnaNB0Mlf7qTQzMeouy1FPZhjSweWD5KD8BV0TdB3LV0iR Ll/+9rzyuP4LscfDl79WSJcuf0HkcPvPStNHmDIfJ9yu5eVZhUkPT19XJEmIwkF35QTYTUppzX08 fyztQmppQTeThWu9l6xvj9Xywng2mnICvEI9vePEzQTDL3EI4GgQ2DdV8RsVyHmlXMlCaHO7fkoU PY04jVShn5xiBXUYfTXNMTb+OO7ARt/Y96COijQpzqIOkCbuIM8S6pArOXefGQtiKWARy3ughKEK 6x5wrXZwEjOcRIET08FJbOFEd3ASvwNOrI+11gmD7q6XYwGnOoWql2fRACuhgcjZsfeZhl2MZKt8 vatsU0Myr6/vBWZBmuV6fX6WR7fZUWMWE2NtGud7mwISpwoydQdxnRidLUvHB2ksqqIjsOdXdxVK 6ZwR8ucqlRcVUe0IKw+UHqpO4nl/lz2I6fMgqevvB0xAI/UJ77sFTBv/f4AJFZ30wqkOwcuMdzun ehBeukZ0+NaHTQ8vR6WnLKPj7n6HTawo+uRYms+tZUmclfkidhqKHZS+buFutYb+S9Ap3wWhFmIl JRcGRh+GoYFZI6djnMxxNQIF84ZzINR0eKv2cJYJrlbK9Q0+hn4Gh4H/GHEhlBsBYqrmIr8sWGn/ Cpmny9cCr8/lCzAe3b2pvkwkybSDSzD7FZcjx9B9RnUC6QZCXrHApCE34c/b/OCU3DRwWm43+Yp5 B4Lf10TC/MEVYycpVNKVp/f59i1ZNs2u5T5SPWhSstph6jM6Dv1/UG1Ym2rUPVGFmqqNebLCIGCt 7N3iZPWU0jPkjFbVLCeC4dY6lPv2JHdVJF3jRde83aw/0pWqBEyM0rhd0V9+CfpNJd++ozdX8gyS 6A3Shcs539xyRb09pf83myOOUPGJFpzSNjcbOsKQqbat30xi99Z7q1Dpug3HGdeRFEM5TUmLnY/S 8lH5odkheg56XaS3BQu3OLYZiEwVHNfYFP9Bl/J2ea8jUEcEIoI7lEf3oqgUEp72Q05MNEbsunFY WZk0coJz4kij9EBrCYZdpBhAozWxg2GqiLOzUR4WUxBqpxIhRM/UvgzYOtAS1aHdMAFOT8bfpbrb axt/ryj61lLs7SGRhx6Nve0PjHxO2c7205EXzZ2p0If5JIBsbAPwDr7V7t/GanKP6IMNKglrm7aO nlAiH1WkXU8qQgP063rNjc09PkG0sdOZh6jAWNvGGDXct2Bc9YyraiINEwLGJEvgmCM7M734yVpI 2QCDrOw/nucElGqNjl4eLBpFPZHbqzMIEiXg+x/t1dfjuG3E3/MphCZtpcNZlUiKlIDcQ3H30ocA B1zSBOgWC63tXRuwvYZXvssi14/Qfub+ZobUP8ve3btkgbXI4XBmOBzO/Aa1qYjvE43EAeRIJY0a SYRBEddr+QYyNwtFHG08+yc//yjTenOUwTLyDLdUtsHwd9wSvm+FGnmlnvvgpYfvMqGHB6W8KtUT efTRbx67IQv9UJ4LDE15cC6iKBh1SeWu7Uhf1QQ4KioCwCpcC/C5p7PnXDM0FhcyXQvrzlPvhBo1 QvZ7gAeoDjYi6ODFe56laPE7H/2Oq3hxlaBPYpbznVKANC576oiWYq+gZvGP6ZRyVIaxlmd1Stqq aazBl9m1SvZSqySKRcj3uIuC8OOfvv3uz3/59q+vrqjjqumdSjOUcTNUSi9USSvkXtAKcVtxwWw4 oG2F8ulOCEllYPMLG6FS3N5ZsD/JIwJRLvQ4iupC34YxfG5T5eUWx6K6UWlUbUF8oBzModVcc+Bv 13d4rHg6ZVw3WNBxfUOEDY0R36Owg96ieAYkQlI0jtDhUP3biXscXSE6QyOYKqCKX08gnrroP5OX HAWs2VfnMy3dBciONkDycE/MC/G6oyP0T/JMvG4YXfQVT+P1fqd7EbBn6LRQJ1PrWsD+e0Bere1Y 7LMgLxlVvBBwuTQo+xrAxXivr/65gEuusqf+S6CuIeWIb2u+GuoWsGMo6llQV+eckqebjTOutzql 8sHKvtz1QDND9c9tMk60fx3UtbA5UhVqij6HdSm32raKG1/GL70vllmqFJ2fP93fXiG72vhHggw2 XjFcMpx4U+pZ8eYaxl02bupNSzUevhnBWzbe3siXk7H1sAuwwO9lzGapVAK9WFwI6Xwvk58I8FlO +MTiv8ESL8Cr4SwA6kKm0W7I1QR9H6etSdQY6wWYp7zzlDnrPEdxp4A3SpeVAeW9pX7hJ6pDkfQL R3LOll7LTRLaB4F7yImznBwKRJbb8XO81LGI5iJPMx3SwT9uSRKw1ufRcZ7EWQbQ0Fng/KHAp15l TmlNmTINR9+P8UoxnQ8t4QvW5YP485tEWRO/ObkHehnAoPib9ISrKH/jKZAwVxQhwX0+U/cvCsMb KPEM9cCyqaJ/2SiTASNyZ/eEUZ2ICx0VYIwq83xg01VyHk9lxfkUXhkXKQ2JVeXsEFJphlSXAVVM HDf4f0wKy5N6TvH84gJsVJEqVxUn1lwOOKM5ASukjdJMF2A32eUazWBE6VACJgHxGACVBGD7yoY1 5/ydodyrThln/JOnbc+meeQ9k6GxVDnKdlVZ75r/9PdXVNBpEw/QGKWUw3PSK6i/Zc5FdqRTVeWV ihh1lVmOZna+/UajcylKAorWIYUCMuYRUVWa2TKzPepmRK3Q2hZM7UsI1NU3t2dkF4SFzJC6GVGf lo03lZb2nGw7KXto91DCtN0q55Zr5JOOOvZJ56nTk1+S3dnSlz2kOj2W3acOfTKUHU4/lD3tqVOv fo3svoXTpyHZSGsUjRymMkSvADxSuWiGbkpTbkOo9vMcPXQafTp9PjqLVMZ1SUoiktQO/1FDiYrw A2U74+JoD2qX/I6YLfBPUCGeYTAnKs8WfhP2R5IMmfwRTAwl8vh1MjOCUUSYJMu5JNX9sqUfWBLh p7SM1w9JN6mjW5JJgIZBlPW716xqFxFSKgV0TTVRWpyCBKAFsuQoYlPJBRnCWYVqnZcVMGRZ2BbJ U8sYz1frZKaR+OIlzpe6eAk0QfaAEniuEkZOmo6tkHHoDAqAlhmR11EhHPBVyxbVOJGuMFqwyE7i PIH5rUBFAkkBA8zxpodk5sgs2dJ4W65lCmgFiK2ByoV8x3sOXkIduJfhCDe8vgnk65vH69qfex4F IV5jFHbfiyGThRcF32ZV6/tp1EbOdwqlJXfQhB4k987nu17Rz5rbWo41QqsSNuQwiTVyVRmno3Dj wn3kQKfdW9o9KuOmV8ZxYTVtkzhbsAa+gLx9D4Zkgn27prEXRdw1r40E5lPdTO7xlsvd5DvtnAHw 7Codyhx7ny4Uv/ukkksixOxpNNrxqOHTRsS0bonyi7mLOYBgPHN1IcXvGZQj9onD9vzrZWC0689Z REkn/IgN8/0RvtIZCcHKY6K1Z6q3XjP9zsVqLBu6LTUOm2GDcd41BcGkXPmi/iPdzoobigMnlQdc r8zv6UY21GDIfa5pSMvRA4cOztNwumlo4Z5bHldwSmP66tCJOd5xquSGTsi8f8+/Ne1nITxdRGzI r1iED4R7TZStsGj2McVMMChNcn0aLVkZ4LktL2cwjQ8SPJxjdOpM5Ty2fvd+BhVpEX+YJxYf+AVo kd4SzRaydpTPhvMPXbFL+bqZ8w4Hwid6mCdQ0pfgzkpYCutBqOR2Jj9QVsf8RkTWgTwQhbaUV3d+ +ssymMPTf/7wg0h5HX2SQTAoaOns5A2jxERNKxcFZZ+Rl0qN3iKHeKWc1h5bHxKOCVMiGeGHL3YB h1Ju1JxG6H45UNaJyeJdI/kDDIdbKrJ1wpUMXBwKEmssMGIJvLTitcVxk1jjN/MiIoVri0HgQ/hK lpY0jtYS/tozsB6IRFfS0PrhOCdhrO5I6g68eSJJubZyuqcrpzgJAN1lRVn5fCV1yvk3j8GRk6mT PIPvOqEStfMzSiaaspZM73naCmm8DAYW2lcwJ6XIyVkDi+wEbqBP0NkaQ3UR4tYD5l0rjstv1Kz8 ttqzNWyqv1AhBd6gwZuyDKfjzDqyab318z3Pg2OWgbwMzmgmbsSHbVb47Jjm6IUu30hWpUZZ7eRG 6FQ4JmJJQIMRbzD6EzrF2qzQNCQ/W+9nJMN/wTCi52ygia3//hsHsZLKie3nZSQuM3TLmXwsrbwT je/lM/PbPwQ70Nt1ZrQ7mefovxsfDEZKFwkVjNh4jfdsS/Rlx/QCzxejpx9A5dIqM5VPEr36ggwf 3Tzy60aWwOzWB1LpiwC/Whne9WqPrzGUIB4YeedFS6Qac73YE/16wdNbAeJSTygB3CaDAsg/959o 6QEVG3eWM7LMR8h5srJoSpslAr7UpuoOyGejpNKec9LQY2sEzw+BqzsjJdDrBbF1R7J0JLyaN7jF OPotUeVEoiJr+JqUrc70Pd56Z4BFFbpZtj7dMa71+IRg+jJ6E/33HYVrRWGKrozD1GD6QaiwGFhw 5TdKGCkaroOwu6QCR9TyZyf8BavCQbFCr4v4/ve6O9f/BRgAR8/sIQ1lbmRzdHJlYW0NZW5kb2Jq DTc0IDAgb2JqDTw8IC9GaWx0ZXIgL0ZsYXRlRGVjb2RlIC9MZW5ndGggODANPj4Nc3RyZWFtCnic UwjkKuQqVLAwUABBIyAyN1AwMVBIzlXQj8g0V3DJVwjkcgrhAnIMzRUsFELSuAzBSg0VjA2AKk0V QnK5NIxMLDVDsrhcQ7gCuQDFkREHDWVuZHN0cmVhbQ1lbmRvYmoNNzUgMCBvYmoNPDwgL0hlaWdo dCA5NCAvQml0c1BlckNvbXBvbmVudCA4IC9TdWJ0eXBlIC9JbWFnZSAvTGVuZ3RoIDM5IC9XaWR0 aCAxNDggL1R5cGUgL1hPYmplY3QgL0ZpbHRlciAvRmxhdGVEZWNvZGUgL0NvbG9yU3BhY2UgMTIy IDAgUg0+Pg1zdHJlYW0KaN7swQEBAAAAgiD/r25IQAEAAAAAAAAAAAAAAADwZAIMADZYAAEKDWVu ZHN0cmVhbQ1lbmRvYmoNNzYgMCBvYmoNPDwgL0ZpbHRlciAvRmxhdGVEZWNvZGUgL0xlbmd0aCAy OTcNPj4Nc3RyZWFtCmjeVFHLbsMgELzzFXtMlQN+NVYkFKlNVMmHPlSnuRNYu5ZqjLB98N93ATdt LcEOuzuzeODH6lSZbgL+5gZV4wRNZ7TDcZidQrhi2xlIM9CdmtZT2FUvLXAi18s4YV+ZZgAhGH+n 4ji5BTYP4ds+FdvkDvir0+g608LmnH5cKFHP1n5hj2aCBA4H0NgwfnyW9kX2CPwP+7d0XixCFs7p eo1B42ilQidNiyCy5ABiTxsa/b/Gisi4NupTOhY7k4QCE8U+YApM7NKAKbAgRI0p5UlvZe5+dKKs yLRvwqh2IlbuWbkMiTzIe8mijDO8bnElfL8OffRDc8JlvBFhJsrMJ2IH4Tg+DvR/5s2/eaVm58jG 8ELBJm9QZ/D2iHaw3g+/2LcAAwCC45C0Cg1lbmRzdHJlYW0NZW5kb2JqDTc3IDAgb2JqDTw8IC9G aWx0ZXIgL0ZsYXRlRGVjb2RlIC9MZW5ndGggMTEzNQ0+Pg1zdHJlYW0KSImUVlmPIzUQfs+v8KMt TUz7atvLE4tACBHBQ3aENNqHkEkyLXKM0jk0/HrqcCfdCTsjEqltl6vKX532k4xaGSuF+iqmv45+ mo4+T0em0lUSFfx55mzWOTubhLVG19nXUUw3o6eh1Hc/e2HEdDkylmWtcCbqWAtbWVRDIlb3ZSox /Q0Ew52grXVKA8EPz3JOJz8QmaixqeXuoMZRNmps5WmmbCWv691WAcONZls03zrBwSxX2tn/ZbuJ la79xfaxqaQZSt4b7ywa35ccHAZwKhCZ0ySL6fm/3ZHRHX0lfy5UkNtP4geBXvgMWKzcKxtkgxtL ZbwUv58WQHdMP8GUN88wi0MUYzw9MQxrGMV7rgtZG3sBEuVWjZ2VDxCGChRbL2cXothhWF5hvcBQ MXGsxkm2tHMkwh4Jc2ICaI+TyUWXw+gCXysalTqdc+WMfKE5nkTSK1oucIfPXFI+dFwJuWD2TN+z 8gmIqHjfk7vzSRUy/kqAjK3RN0Yb7zDZ73yDaRKgtIyPOuQUavbRGZRrj4YkXWPK4gDArNc1++ug TACOjrbgJW11tCK9ApcMOT0sWxW17zSLV+YBy6qr4ImJZbXmoYivyiieTP0VegiiFdNbTC6x0v7B YsbjLblAKZbv+GzxN+9ivTrY3fLyubNhbC3CL9zLIvRItk3g68hOJz9ByIyu7yuppLCxjuL0zfC4 Wlcxdik8BTdryieDBkDKgQcpKZNsTjhr1kRG3wNDBsTIBPxoGuxvO1GrM5QBZu4cWWZrFnxGJkFS kJpRbmac2BBeFq1w/QDGQRI2rfKljPZXSC2XEejZcR1gTSCt+QuJfI5YMgNXFKb/oaSQCaDGx1uX 2Trkb7rK2whNAHwTQqhLG2bkW4AwW8Fngeo3pJkh0XmCECxLKcL00PnWR/IquCIxzM2s5wUy/HvS cMFNUgncyh5loU3xOnqVcsnexMENooC6KBK+ROIub0Lpfd6ES4Wb90vcOF1Bd3fsF9SrA8YGvmwU TBBPgPELGAbDA/czDBusSuET40thXPCS8g/G9QwNYDoO4syKruzYaCjWocdVDrjZPbHOwtRROzA7 3t2TAdzDXxlMGaBjoLamIJoV5E0R3F70EUIxGx5TsNx5Pvvu8rPh495aW7xLK6ODMTGz548qU/Mw 2CV4AWX3pgKuIdGQQG71YAku1opbEs7flHPXfWbWtyAtYRzTBfBBdsDlmOB9lbLr7mnFl0uWW3HC S6fBHN8f+OqjS8hgNwZig7N/FCUw8LeUqQfceVlcOwJNWy5zED/ukTpHgesOtAHreX8vnncqQsmg XjqLAGxbFWpMFOA+zlXt5Eu5t6kMUcejcpX8EYl/4PoLCtw/L/svB3haFveY/H4IY9Kxyqn031/4 ZCzdEyPEKV/1K3wPXC7+HT/xrOMrnxlXSORr/oC95cAvxQsra8bHxZw6VpRtKwaPB3oWRLisco+y 4D5FeFKPhor4iDV939Cf5bnyOGnFEQ8oDbffb8W/AgwATEx7fA1lbmRzdHJlYW0NZW5kb2JqDTc4 IDAgb2JqDTw8IC9IZWlnaHQgOTkgL0JpdHNQZXJDb21wb25lbnQgOCAvTGVuZ3RoIDUzNyAvV2lk dGggNzYgL0NvbG9yU3BhY2UgMzIgMCBSIC9GaWx0ZXIgL0ZsYXRlRGVjb2RlDT4+DXN0cmVhbQpI ieyXC3KDMAxEdf/j9DDxdToBYyRLqw846XQGT0NCcLVv1zYOrT3taf+qEe1/22u044utw3RNtIRA S3SyuIDeITt973FBeruW6zFT64rfQgYmGLEMGjsePedvztORKNDV0dI8QSbBksfzjbq4cVly2cE0 TsHyaKyHzCvBdfHy1NnIvDHgUq1GMvF9gZFVSyR1KPsmdqrx0TbRGUSys5DCLnnMXzangslljrhV C9S8zqVPxoAhtg/nZVhFXE4EOKt6XrFHFCgBj2u4rMGBXFpLrYMTXxy1cMD1Pn9t//+zHV+qFnJv 11rIFXS2gVAt4pvqtMFWufroq6PJFdwq/Vo1rsbciaPNxcmMWroi7uxzjey5R87FTce1luXF5wSp OTFN3qBWSTjksj93rmKtfV8/bsx84K/lBbnGrBJv5vKMhGtru7MlJ3ZcS9ZTXIqOjL3Dv52Pzsja 5+aXHCRlw9gfYa1oVJff77PrEXm8wgXzojOvBsHUb4C8cPXy3LkgJSzqe0X5d47PhRfFF+Y90hZP ekEtG/0iV9AqXPopbfaY50LeBNcp1h9EHS5n3Jfm5ff2x1E+yAS//8mspTa/seqh0FwqYxIRqVp5 Bzdkj1odYZ4aN8UaT9VaCjCJux7Zfj9ubKvChORDE/Zs7LWfu1yK7RaytuBHUuBKaLEEsh4XyhY9 1lSwWp1LTZ8VbZXBpz3t79vvALVOL/MNZW5kc3RyZWFtDWVuZG9iag03OSAwIG9iag08PCAvRmls dGVyIC9GbGF0ZURlY29kZSAvTGVuZ3RoIDEwDT4+DXN0cmVhbQp4nCvkAgAA7gB8DWVuZHN0cmVh bQ1lbmRvYmoNODAgMCBvYmoNPDwgL0hlaWdodCA5NyAvQml0c1BlckNvbXBvbmVudCA4IC9TdWJ0 eXBlIC9JbWFnZSAvTGVuZ3RoIDQwIC9XaWR0aCAxNTEgL1R5cGUgL1hPYmplY3QgL0ZpbHRlciAv RmxhdGVEZWNvZGUgL0NvbG9yU3BhY2UgMTIyIDAgUg0+Pg1zdHJlYW0KaN7swQENAAAAwqD3T20P BxQAAAAAAAAAAAAAAAAAwIUJMAA5NwABCg1lbmRzdHJlYW0NZW5kb2JqDTgxIDAgb2JqDTw8IC9U eXBlIC9FbmNvZGluZyAvRGlmZmVyZW5jZXMNWyAzMiAvc3BhY2UgNDUgL2h5cGhlbiAvcGVyaW9k IDQ4IC96ZXJvIC9vbmUgL3R3byAvdGhyZWUgL2ZvdXIgL2ZpdmUgL3NpeCAvc2V2ZW4gL2VpZ2h0 IC9uaW5lIC9jb2xvbiA2NSAvQSAvQiAvQyAvRCAvRSAvRiAvRyA3MyAvSSA3NSAvSyAvTCAvTSAv TiAvTyAvUCAvUSAvUiAvUyAvVCAvVSAvViAvVyAvWCAvWSA5NyAvYSA5OSAvYyAvZCAvZSAvZiAv ZyAvaCAvaSAvaiAvayAvbCAvbSAvbiAvbyAvcCAxMTQgL3IgL3MgL3QgL3UgL3YgL3cgL3ggL3kg MTQ0IC9xdW90ZXJpZ2h0DV0NPj4NZW5kb2JqDTgyIDAgb2JqDTw8IC9GaWx0ZXIgL0ZsYXRlRGVj b2RlIC9MZW5ndGggMTM5OQ0+Pg1zdHJlYW0KSImUV1lv4zYQfs+v4CMJ1IJ4iKReu+1DiwZYIO62 QNEHxZYTIz4CS0aa/vrORdmOd5MtDIjXzDfD4Vye/3rz8/zmx/lNreaLm7pyLqr5y42tqzqrGn48 8zZVyUflm7ZKNtRAtL35S6+NjXpnZi7oJX1pY2Fsozv8jGaW9d7AwYGOB5O1WhnnzzfVp8+w/bvx Xs/uaf8okAoXhNHhB7mfBuOd/sHMrNPqBedrPBpBWmX1I/ExBk1H1IdgzlQlxN74VhRY4XmP+h5O l2DSBzy6lBNFijJ/q/lkvaquc8MmrGvfvGvDkCvb2ujYhiOIqBoEhSs0oIfzMKjNHoTCpFvyqO5l vemYYScMC14KX2VcjdRvlEvBt237Va1cW7XJW6e8j1WMrU2s1xxxo+iF9qGlkncrex72BjAKDKNQ kOIRrEqDGq9wkEc983Fnavg+82ZvMnwP9OVHE2jAbCIdMcgD03emrfClaAHvYwOc/SsSliK/G0xA GUoUEvU2YGCiezGuOV2iUr/wuaAqlFgOxQYLPhrX+zekZzafgXFt49kjbIiebA8zmPz2bdcAVWxI yfMTOLquR3f3MIAfghoJ1AB0WC57OR/MLMGw4H0wkm9hBIM4ZLsHe56Y/mTaHuye0IeItAgoLBs6 3cjqSKtBViOtDiK6m3ZnzlVuet7xUaB7eshPpEPRrF+CIJ+RTV3qPnEtIX4jacL4/XQ3EgsOgYAr A3Z7e6frd3ASmcG14d3ItKC7i65l83+5vVUdmihCRC2NtRhYC9QIQ6xDXTAi17KxkvWr8RiXapT9 R0FAS/iq1QURMhCGbz8MBQE4gj9D2K9UJ0fqkgs8ocXdYTGhL4+gWYO0693DV3zRsQ18rN27Nqhd ZeuAyQxtwO/rIEJzleGL5nfykE7vabfQoC7goA6S0MwlGCGWEpzv8O2chNIdvhX4yWIUrrWMjLVj Kk/B7NgxnXh+phfOk+M79ElvUTJLKGoVyHuC7EW8uCTIVkXjFRGsSMvCtJtAUFbR8hVDPekZCbbT lUWvsiwKFJFXJcJPJSJPCcF+MyOECDPXwptmF/g9thRgnnOQl6yaNNUEz5nISypMnLa83vIhGDHU ZzzrhQnpbK0E8xJLQY61gCh7TEqp1GvR5VAARqYqgD3jq07IZUDDnqAEeXzFDI8p6I2MPQ9Fhtyl w+RLDDu6a5ayMwlRYye3f4I3xs6D7n4VF1PV9nVsPs7R/CKprepYt1MTlLgcc53+cjtIKVZ3vYlU oSMHt42cLmjcGyrfEx+myYBJrykNC9MJGhg3STJxlAYmQkym1AIMLOgIUZFxeS2JWwPqyWhrZWyS VEWUJ3RPpEtGYmET3sOEh4cQTPG0WvLZteeXSpi+w++baKNyEVTzubFi5S12DHqDNZiiIOjdaDJ5 q2ZvIF+QBgT9wGr1E/Zrn/EzAzewmDAyxQ45KVV0DzpnqHFZb9aECrMH7FMh5ZH3wT72WBo9FFMb tH53iNgTDncBRXSDjMYl7lw4IiZRIV37H8Y1ZYQodrG5/cAu4PYuTtmZ6knIPN3g+4Gi1Gqj0DVt DMUuQLKi/IovDgePxEqtr+rx9B/aeJZt7pBD5t53SyxEzCJLZ44mwmnpDYkXwFjskTY23D2zNvgn gOn2W2LcM9FBPcs2U8pA93k+4VZY8rT6A+c9vcd1tStmTf/D4QLkTJ8aqXyoSoMNZU8tCoy7UVpM xXk+cJ4P1KQ4GDtecs2AU/gDg21O4jIRqcRFXZifpJktKQ/vgYGcdRHIcIuCt5aRYXYCo2Lh7srW UjpoJE96cUm/oI57I1hHljHIDU4ipLMVGWusyzBN36nbZfzTW3ycXPkVPBRSGy2FvfpPgAEApbIi 8g1lbmRzdHJlYW0NZW5kb2JqDTgzIDAgb2JqDTw8IC9GaWx0ZXIgL0ZsYXRlRGVjb2RlIC9MZW5n dGggMTQ5NDUNPj4Nc3RyZWFtCkiJnFfbbhvJEX3nV/TjjFdq9/0SwA+JkCwSZBdGJDsPURDINGXT kESZotd2Vvu0yH/nVPcMOdNzoWwQ4Ny6q6rrcurUx8XzH88le/ewkEzgJ5nkKhit2KngwkkhY2TL 28Xzf6xurnbrX1Znm5vNdn272m3XS7ZdL56fPTi2fFiItP1hebf40wUeLraL539REHdxvZCQFLL0 dCeF5sYwLxzXJP7idvGv6lIIVf+bXfxt8ecLEuF4dGlPupEicoUdhkuX16+7iwcapOSuUPCiu4EO h9OxiyXMdBNmSs+1tS4Ugh5fdyUJklEYqyy332KtCrx0x2NPB4wNpIduVIiRVn2ecbCWMMCUhj+r Q3VeS1fdbGqtqh37YXAQQXLJOcqwi7/P+MYpbnw0PqmwTgY1Hsbk6Ggb47PUgTBvuQtG+TIlqtdn 9SmiYKuXuCpcXxVukXrofoX0Ktz/01/LfdkgZSQZVOyHphAkScAhg3ImC/nwsS9E0mmWCzkuRTrD dQzWMBc1D8aqsPeQPqmlUlzSvRnEYDKsSkkuykR5VuyfCZpSji6DurNlrmX3FF7RgjvT8yqdZPQE FHT4by5FlQ58YErN2CDtfZv3WpNAxX1wY0nkPVc+4Mb5wJVG7LJQ9gP77iwPkVuJVCKRxodo5nJ8 PsXhNqcbUR3rcoLn9H5ScmescD5F8ttzW2pUkwwaEgw34pDb94UQH/e5PSImInltREY7Z7l3xja2 fDipva8+TmKXnoctY3lsXGQmIOt/ePH9AZUQHRArl0MaZJyFrfmQoqydj8L0DP7mgCrgm5mLaDJF zeEVyjpQvRUxXd8P/DQVT2QE1wijKQNapoUIh1geK3DLB7HkOZq4pHjiumPsssKHiBaJthkAAjW6 VxHkBChmHw8XMxRo68ci4xxKLAXGGgqyaQz454q9XdWnKIFYXdcR+LuuT4HDsbrDW7JhVUu8Zef1 KdxS3TRfN2ntrnlitTLVVfPwkFeyvGQvhu1aybfNdVULkvzQSpYd7cv0tOJ4NEnBaHofwXYh0G60 d+Whz6ZJlQL6StqgOiD8oR9xZVPODtSBYJnWwQ2/+hUBjH19WGvMaDPBiVWpWRb91apR1Yhf6Ks+ eZpS4/lApxroHD+v1Qmaukp/f6Jan13cVvcHYI2rLVxbjRDJvI+pYLODBDcjcSk0BE+Ep6sk6Zih nCqKHPrDeX7rrp8u62iIIGBTd++wbedSlSCISF3kih9t2uTV6FDOTkfuxB6O39ZKo2QCVRTAP2P/ il4+UDNgO6rB9+lbesuW9J+WpQU7lu6v6Y/drt/RdZuWX9FCVCf230H+u7KddID/eNFRO9FSg5kU 9hddQMbqP7iN1U8AiGq0Xw+bAgKqU2sYJZ8wUuU5oJkK/Dwaq5y/ZGYTsh1cBNQfxs7a/fGn4UY7 sMHUSA8iz16+GiZ0/1zIGbSn7sHWZQHa+YNYTxy4o/UkORnIGqpPtQaavicc3cN0QEZQFgzaSTOT SCVDzlHl1GSOBouTUp9NDT/pXVIP0EmdJsi/hgH51Tr9A+NhUKS8o+8nbLXLGwjnfcU+AC6RuFd3 DAdAr6ze1KlztPLWlPsWpUD/qy/pQn2GWlfFrhodrSZ2lhYg4zwlnKfOBCXNvuXqPl3JAqxd84ke A1R2oy314ASYKqV1oQ05Tv2KHPxiUEWuETtTQB5dc0zsr3QaQ6eJ1bGckuh8QCMMbbHJiKf1ESky xMp0afsI+ibUgmsc14t08KqnuGwmKowqRvMj6txV/DsCYymVTQAVgBlKkBmqmHiTX20cMQa0zfVs eTyrIZ+EEPF4RYGPoFWPQ05YmhcwuPb98tuweBpCKrzRCYXmaH3AmVxqGR2ZrPZwA3Lx7i3qBfml UFGpQnC3ouylr7ka6A1wm1hh82FFCE908jr95+zH+5f586tMMk+o0vh08Td1Pz5QWmp0znvmBE07 vjX8M1VXU6RNbQ87yBNyHx3ehaBkKf+xl/unaiRkgrsjMCklmnN0wZbSWe1MQijCxZBRckctM6Mm CLDNL+8+3dKiN3V+66otPI7769RvD3UPNJOStgAhqgvyu+zJIi3pLmlpZcjGkBKHKB7Cy1nHUWAw Amhmo8TUsme64Dx+cobzdDcyKiA9tPQkC041FO7vG+OwHf82hD0n+sYpjmBM+ABLAo1zc1Pc6YQI B/iO1J+6ZgwmuCizFVrKI3UrAgFc9kybPVpEVIBJ48vNDXtDHEJSdRoab5rrlzQNNQ/LfPmUh6gV TXkSXY2e2CZvv+s97dI4ROzOpMEpQeI2LzlLF4CaT6CW7HjIT5xdZNnv82XdCGg+U4ZW64e85aRW cgwXRLB7QmV7zHU6G6kzUuOy3nLv9hTwUkjBvhCs8wTsQEDc3OPOwh5bUYI5njo2Zik70m5SOZRJ IqEDqnTLfr6U49p4yxEpIbKJe/vkGTxFfUZZ0g/+A0OlcJhLlPNV/+uRZuhUypWOYfdPs8ybgVmv izYq9AhFlhh6Yl/jSZnqLjTlIlIr/jzUHnUWcjCAwQLFvlLbTA1EGkqmj2im+0c1ynRHwqWM6Br4 dXYiM2lL6YvySCaPp5NNq+VplgIS97BPBmNWySfw3CPEksg/slDj6eWTIC4CbSH4AAdfPz4txjJt IZPCdJSlH+NYhttC58k4xg9ZFtHCjs5vhnRpExHqKu9jetOLDUHtAM4dwh7gfouBxao9LPTLooc5 SC07mqTeAO8L92kidAQt53QeXG82RJ4CxiJQcQSZ3rHX8yjTnnssddOAN3f48R5EaSxEOnfAs5pM lVzTw/HO8SZ7O2c9rxUmphs0ElGBQOiAHlEyOtVhXFOzI/iCjUH00oIPmgB8neMhfG4BNgd4tNYU ZQgqSkYnm7K9IN70nqg89SBQpAcKQsXut+ndiohdfpV40V16u+uuTPzrsPgTCdwlTrVN/1dp8Q29 zhr+S8vy293h7eYujYdgaLoR2jEtSe5YdL3pPJzkLbtiOdv80tnW+ZBVv2Wba7a3rbWQlRAW2tlB 6NAMnYRqcw7W4Mre+BbMAGVE9ZHZVMkG2URd3uVxIn0EUdAK122aC0IeH2BhvmRqQD4FvmDxed68 zF/fj+75RDQCR1rlPdus5nPWvq7pvxHX7l/nx7v0jdV6sKARxe5XtbUdY7O0TT7B22Z7aF9c5wvb rW9bASm06X/d+iHz8T+gkZc8R3RGHxvt/IwCDPWJ3GB4tId2gqI0XZl9DCACiy3ktrx8Odf40IKp rUBBUz8vxgpymB2gBYSw1L5psjUd5iVUkXNZwsy0FBLqHGwoZQzbEqUlMsLoGBui3jsk6JbuubYk chhqhSI3CYCHDEqNSJk2WIHPPcFnk4GVqKgczyPOI1nj8CdN5EJroqMK04SyLW15LJyP0SvG0elL WppNQ+t6jEBtr57xPfrpvOsHSuiAjZEjFhbiaT5QOSpjISHY8r4PYNNhciZVwiFOz2oiX8AbsDy0 7FqDz1c79gObKFExH8WYsqiXCT9Pn00JR1kzUZfTbVMK3tfxbMBhXOIwk4YSVVE9R/zx9Y9HRgqF YVBMm9v0/BnvE4Xpe/+yOrusGbusauOpCRDUot9e1jQbln1qzyg+L5Clo/nrAK6G8t5EInmmyd4T agsmwbwCyFuZkJ1uwWKGgZbI/DgPw4qLiGJhJoD5C6vC0ViDCGKVCablOU+LdQbjpGY+1POJGQme OlKOR1siQ/7PebXtxo0c0V/hI5lIBPvCbnIBB1hIeVhgAxjw5Ukvk9F4PBt5ZGjGNoJsnvLjOXVp ineNLEBDsq/V1VV1zmnt6w02tupvdEeq1eNG3wxv09RJCb5UGIHnvjKt+NoPC+Nccaxape9LMBXg i8Y3QytFjCgxt4vEfOSjNlAJ87GlxJjl5JURY+a5eVWLJvEx4po7bv7HiJtDZLaqMr2ZWYdKcGtB wzOPw0WkgF7ZH1cFymebX8j1DYu7vl9w7Ju5A43OYSnbBn6YHKFq0oUbOsxUVVnny9GtFIUBXc24 QODtcDhQU7tEn8bAIQHMHnkNltugkd8ZMtjPls651ZClKuTIH7iW0Dj3MhBEh8iGqaa0c8nG7nMa 1aDdq1UWoUSFhvdO5kcjrNmh5DX4PTKxjcJgXX7eSSdzVUcyg/iU0uIotPi5mWluf7iu8kke2ZfD Xt6edP5Ghp8POvBYtKWHMpDlki1Cmq8KogV5pnOObO49//4UIltIwdZ4lIK+RxDXNf4D/uMKPAfM GNzKXWWrV2JeNBxM/c0J9AjwMka8EwmRiSZrrXA0oTU2rusyjzHECr0Pyt94J1xYrffoe/e4+V44 iQXufsJ1uHyzl94df2Vb+XqUkSfSWrjBwuh9O7lvl+67fV6Hx+jOB/7Q8UfuL/mes3HVNmQzHdbX 9KaHNUsgTyzXo2AEF6ggMqQV1/AxSVxEToDJ/PmI0PH5FRrpKzvDFw70I99l0vOdf3cFbAgUsNzZ DZLmjS55r80Zs5Vj+rqVnQAcAU6+5nCuQSm5lSWsf17xnrsD1Ks8k7mHozbs9Zl1LX2jOeV8Z9EX fe5kl0kUdTXXmvUAgjZtUbo9ljHGhygupd3yw/nbBrSY07cOnK5kHff9MrnL14jZQKKNMhPcvnKx ipdo2ciqwWOFhJa3a2IjNgwqtIN/lZptmrIR2lFRQV3VY1VYZxyVo+TvG/HnxxfplyGR5CsWLBeI KspwO9xj2YkteT5zLeP9i5rKrWsq0Pl6uPOiqPopTVUT7SMU7W+xAqYogER2lyJkRRy6sh0f5JW6 ishlO7T0AqrdBL67JYtfRhlEZ5kSyfel1V9RhaZlITSd71cUImmpapQ8N8TEqMzdvP0w8Y2tZ6ih 97Ra/2yH+weqjTWq1niFJgWdDXGWI9ZsyuCc0I9U/VohEHckI9nC72CKwBtA7WzQLSN2Q9lq/HCb EQUkrr2mP11DZLZqw8zs9XBHAAUPr49WAPMwK0UxUCI71KzqmalMypSpvbgXFd6v+oD0bTIhnQB5 nt/vGJN8LuDnGV4D0P6a8Yfx0gv0+g630M5Xk0YdiqqDrskcWfAT/2Zfuhny3OvuT/rcaPs5DZDZ R+1OEIq391fZJtl8L4svhcVSPtRA9TYiEftuuZBIxpoo5Nr9rIRjVQ6vQvijHRPiBPckEeoE96ad 54uZg+SwzBklJxnO6ZpKQ+SNGYsRYpGaiTZaaXnizs2+ayC+yETPCmk4syhgSZAEASY1+aZjEY0I AHm7pTlvgRegTw0BBxEnkKyeEbg1kKYmf+hm7fFfQi7k2a804VT46nmlgJUm1cWn6lKZdYpJDgLt D7GpnDjo3bYIygwtRy2Ru/tvD/p94O/jPuPi4/KvBVM3bdZBJwn17OMNeD9eUEKZvUFYXTOte5RZ WeqX8WnUQUcddRkaBGquk75or1iWibkbbTzt+POUoXzz0u9kDRksY5MRh6ExyfjMy8wSqUZTnXwi EsE8Qn41Cca67lFBG+xq1SOHe0Bn3bHASwEmMvK52j5TmVl8qUpbO5o+Q/So1nkGbmGI/4HH6/wG gVbjEmxd5R9egnBbYYlQajqZBdPx2lhGjsl0KvbdQWzH+RbOYsC4Zs5iILS8Hxzm6gYXRLFkfPvy MVDkKt8/yZTrzl0CzbMxusvtj2HWfqCfHdn/v8JaoDudIzR0jujyaWjU7Qz3AO/W06TY+POmqFHK sApswDLXFiShGVLl0X21cXpftLJtoKXouKgRxq4ed+6o1hqizf2j/ncK2Kmi29j0mPISVCBRa2Yf vUUzFaoN455VLG3y7UZfzvpkIG4EiBuuLqjTCuGNKEw7hZyYLKxN1FRvwnxJxWjCG+dqiM2YXLal 621QbfhxYuCA9CHooEeGYkj2EDjg8aFga07yle3l+VjwCRjuwcCADHIEtNb5WRfMfuPWW5nyu0z5 Ox0ax/oh637WBXYFZQBqn8yEh6CUVMkAxO61/Z/6/bCR1dL+eqadPDKAK6+exj/pMF3uX/IgaoVG 3RNltp74u19QjX+hoCZ3w7KosUC4khODr0jGgrhYh3+/TFxAhSlGbSzdMw+leSA8Nt5VrlrTpG0s 7WD/IRe/7lEWxwn8UoCbykIogQsNVsU9NwgpxI6wEtCC4/2J37NPxAQe6eeJcIygthEQh78bRV7k RCP4SYBIwWC9QGdak8bek/Nwhfj9N5Ol3+j19veCo8gobAPUT9k0j41mSeWemcdilkALoqKQxkhl 6weJrjaXZDT57qgvypANE9+Wz8j9FNWmI+Cgbt0EomUYmb53HNv5R0p6Q/FhpDzy5wfZVYZsnvpT XDJpowYc9Hk+pKX3ulhi4UYXElPPOr47kmi4p8HQeXtO8kVEJPLQibfrTubUydt2Wa9Vts1cVZXR tEbV3nsxC3X8Kb18Kqiuk/F13jVesQ21SM9zNyn7uhuM+8Rfw7lyczU5sMLjqM1b+dxlWxmehn3l r41WInFTrV6vxSVpB3I3DUKsNgxFvOJZh/5QgNqlHRG2gzPdH3T+eab4EBK9HMAOWGAbXGsblc1t iNsf+VLv6RU8nWp6m1+/w8sW9ZEiwRIjRS/xak5LE3QSiDWGHCjBTlS+fhG5MuR3wSlmGxvUyBDN apnsAgDspfQOf6nMOfOmMBbRD2nn56vwsFa2qPUk1wxxDoW2UWRap050tWjNRc3HNIht0rWy60Uo cOtHFCQg0hI8akptO+W6UvhDheGAS939dsTenO/qGdsw9moDz8t+usAbuNGaS9yIo9dhsDlmDmBm 0W16A71t/zLaccVNAKvWDibDQ4A6A6gzcdlTxjA4rhnMRcmu3rgBG8RVD7bPb+6K6bX/WD4CUhKh ZVwYHWPo+DFzr5jQDs23F/nb1AFwvOzwZUMDuK9pquZn/I0Es6v2XuLuZmL5691tqwa5N3b3qzmW dbGcXMDFHMvWxLiHJylGJP0FZ1iINxfsMPqyu/w7IBmLTfA1cTbjmoQFpmmX4LUmqWohk9oABSqL /3rKbt9ek6PebUG4Eh+LwrG+0c9DR8yO9Lln8kUcISoz+94xuwN/89RT9kXn0e9eeV+jU4j7Sc+j IAtjCCGq0516DSce02OFZKmSQvo+EfZXQ0LpzFQgNa4DzuSttjJL0GmoCHhKyZoYCznry2FPnM3h JIg3mAC2jKOo1fTxKP1H7ie14ak1e9jJoBPRpu6R6dTPuhp/6NSbtBGxiyiczLFuxFY6L3sn62wL H3mZmbHf+PeBjTv0d9jzb1lYNvB9sqRiS6B76GDcRXzqoBZf6fBJHIYOQtZLu60hXU1NiTp07Two jdIzOE4w78s6zNd3UI/IlHOycawYx3lXmfu3S7YEBvrJlnYmq7crWd0ONy4X8zg2NqVxOx+YYOYt ZbFtyxBbr5zuH6SKJCOOnACsmz4jN5BkSIWHLneuCp/3Mt6Zy1KesvErvWobZpxoC2HbQyH3UcUX 96sh1MlZzAk7oxM0NQ1ctcpp0/kNeE3dVMoRhZo7JeES3FGTx6kwQkCn7kfuPhIbp2CWUdvNMUvT QL8dDoMLET5PecSD4RjXaG7EVAUPx4x5ukuDdzI4LTTcVlfCUEsZnm2TeVtZ7XPaPvvE41P34UFf vg2tLNWK959H23HOUrWUfdW2s/Zm42HTO5GkLn1sE4efhZbuTqoArmkbvRPa1QMbyLshqTeEkWqz IHUKISIHJBihCbv/c15tu20jSfQ9X9GPEhAx7Au7yQF2gESzs9h9SLzjSRYL5EWRKFkbWTIsOU7+ Ip88py5N6up4A8Mi2Zfq6urTp07d64zcvKB40WhpRq1JrebPm4na2QlF6XDeZhxIOXhcmDyTpWyC 8q18isd7eqYuaqRmKJsiXeSpH0qBEujIQd3TRdhXdAPz62nV9bRCAqXXPrBbexaftR8SNny+B/s5 EXq5pAqiRZ4QOYlp/HBndHykl0Yey1g+ZtSmr+nUcabNmZyTtU/0HWdeyuVlhMQEt6AoKYNmHBUQ 24dbLmvvdgd6ZJRIdxGRfaIGcqymO5PZb9bLnV6N7Dqa3R6IkSQ8ue74VbQMW6ZeFkaGV57zuSqF ckyYR7eZfZXisxtC2zRFupSUDzOifwanxhggxcEHVVOq7uyTxpa2Qx83E1mWt7NH81uzn3xmqhBD H+N+03fDLlA54KHUiRRxG3XWYchrsbof8bQXb1nyKOYHieiU3oKqwRQqjs/FsCS6Ohn5a2adwCwc NfEEHGWtJAeSCplcg5ArTieP2/C4e7XBDKiUyPMovGJgrC9XRGcBIMBXpawWJPHYgVJpyOzaW5ys dMFHcQAhDTTxG8lKJUmYab/qvKW27Dq/ZYD4m/fcmo3Mz8upH0/v7qcvbncAsQQdU43KJ7B/rHJF t4SVRuoF3CC0bLTeIFDddrXGaRXSyZyF4fc9ucI1xB7cZYrZxxSlIEa/3u4scswb+n337vpPmTM5 pI3/9352BBaaovQUEY4D+/D2t7/zGn9c4g26CV957Sm8oK+7HXttTgJ1vAv6lq4HJsX1hD+Ytnpy OLxmmSEr5bOjmkyY7vQu1l1lVkssnA1PY8JDtLDs4FjIdanlutR0XVDvCopryiWOnkYlUp3vC17m QyQjBq4bdI0v84SfEg8Onjlfn/OxJsDaEumzRN51Hv/hCR1RRdIRFqVD6NIuzUO+dulj6Y9Ln8qd K31sbIrGsTd6gz4O/4YdVoPy+CC803MI4ckUbhuHNN/YA6sIcwAC3jK6NrTZx5fS9EjiDUi5o+Ov pe8L2kIzyIllOKqEpUq9lb/I1TmtNDNtl2W+NjE9fSC4NqgzoTWsq/YvECJolefgcx0Hv1JU8ncY lAYJ6cuStX2gfPQUGi5GCqK2ifXx2mfuQJKNVS6ljg/OFoERsKgSJJS1vqhsIPokmwrvlOGdBN5S eORyJGV4p06Ko0nquO7zaAIp8KS5IanSTiiYKMnYIvVMIaPLXAlRsaNVE25nbwFi5sC+Dm7XO23R Bjg40Zad+U3aruQxOj0MhAbasWl+SKaWUpAtLajEpUpidw2emiLJEhId5S68zh5WojmI/Ba0SeQ6 8ggZhwrdlRCooyzLBCdU6jhvYv4XyFY2JI17liciaGjkbsjwlwTTEHeyWuG1xhrXziEtdLAYT8ON s45EMhpW2S126KX0sF9L6tnRz01eTSz6M6raVkoBLkiBcrHqy4GswS5NqjSOS9EKyDb3+tJKIads TO6UhSZcXzI068Gcf82M9kZMTLClVoKNy3DGS2e8NZ94CkOTojEKRPisdriVV2xlKZ30c2yOoiGG CBo+3OczKycwBzi1wTVlYJ4rBS/XSRZqKpimPKz+auJJgGE9M4dmLlV+Fbg61VXsLT3P9+SoPjv2 3T3P95Qo5xz7TsC07inU2ZRRZ+vL5Zyra5NqpFlwu6yg3IUzN3ctQyODRrC1OWi7VYBMBD57sFrw uAzZO8HlMda471Hg3HagNHs+MJ12AxmU4oHRWzAVY90M5prKZ7TXmUL5EvP8pZpbdc/yxLc+sFZC ZkYIV0qIkkUaapDWp7ciFqA8JOTeyUUfRVckn84G3VtwbhUBh2RZr2dNMx8GlLT3sl3k7pt2GEHs hh/rFTVNiGfuF/Tb0jiQWAXm8iyTA7mOQVshKpDTrBvIbYKXbJsZC9QIrcYfPASRi0EIEdGFjLjZ kN1HeuUBynqTIYsL/KiNSVa5BAG2x3POoLNTp0/mFo5SJK6IDSRH01UsdJKUXeS4u8PWenEvfVLX lHlReJQqFrj7geazxOX0R/JWcuTguxhgPAtCMKUZiF1G8WDXmULwppthIzMZnVqoSkun/zlrwZWW rcwoy+A2X+LPV78H5QAnsXAaCBMTC08OQSAr5cAf2SDmrU6mo8bEBd+fflQylaXvZGCMl7wgMR8O zLxBii2YPx0VucvpkNXetTwBMHrQ6UDWINOuF78gKOXg+jtdwXAZGTbEJ/Wy9yDVWGcZ/5+WpXAV RPpoXoPG2SlAcKsbPT4eIKc0NdcMpA5Fw1EUOqCrM+iPmQUetvUdckDf52jeCDL0EqlRgc4dusRS Kw1tDwZBCqGI0UVC/jQOTcffz7kjxN8R1U3NeYljMmMmbAbfcGML3UzRCEM3StiNkmAj9Mn78GC/ OxYKDUsLnspf6+NWNkgEb7UkhAGKKJ7fcfKWokSdMuFeJ2xlxM5MJ7r4aqUv2gUvANicguj4XkvH lTz+yVbV+IZ/s/He6B237/Tr4WAUgKgr9WvQzu3pvagVkI0UR5ejH6rCV8nqxdhNtkSGn5kuJ/Oh t6B2ouT1EhjafWNeXComMJBHbGjEPX/fsoDdLTc0cG2GtUyXTh53q2pXhDBawfuJqA2vY4y/opf3 ys5el6FdDr7u2Ct63bEp3A6W2yKUva7yQI3rYuhqakWaOqNuc85DpeB+EB8PYPkqKoO/5iVWLL23 silcLMphj0POvg2TsHci7T9TQytSnmU9Q8SpCodYrTtZP2pYtUvjRlaYCTdv5kbWHaMO5eHyOZ9L DbDmObkeoN9vHJMxj920tNic33XClFaT11aLjVDrVNZnRBQb8qw6wZbebxd/EDfs09vglOlmXLdM 6Wy5DJnxL8T/QSGiaVhHL/YqHv4xXNLMhxpNbGqu/FVrvcTKYUdb+kap3+x18dBNX0jdUhcL6J0U d1zDhTy8YL3xbijhRcO0d+M1zmkstkVXnNJgVHw1dfpBnNCQGqfwIlIIqBeJsGKud2J33aPyHukZ SUTo4BeMTJamEB923XmWmF3p3Jl0Em6rIin1RZEQRVSdGbqlVt2zpBVvJ/r9mWRBLGIuUjsfW9Yp RRSlgueVfL5Xn6fiTt5cfrZsfytj7zrPPWXotX7OeMnEzEytZGeR/T4H06pLQvZiFkoOVQ5qm8Kl 0mtZJ2e+h4cR54LbDsCLHkn7IEL3mnoWWuSMCEUfCCTjK6DmPcPlv3gruMsancIM8buIX7L+0JsX zHlc/TfU+HFojqG8b4Q4hO+U1IYH0I2K6qGLJ6xI4XDNRaxKjGq8hdRkKqwJGzUvyd7odq/x/Z34 GEjKG1rJD11w3tr6TnzmxN2oAv9A96oPkw5Z91GY8dX/NMzf881xmJbCdbS4WD7klyo3P4NhLmTU MlU/iFKKoMcqqJ6ZcALUJMq0vcxptEuh7kwKZWbbKP8IMUJ8bYf5dd2n1J1pj1oe+HXBRRC/viT5 ivOg8kmcmFLavcmmwYdsY9KndlmKvVkuxL26T+3D+kyEfNbi/jLrSYxiKHDZSisxIr9Q6C5Xq1x7 WGImvvxI9pznC8rvNY0iuvHdoIX0mZ2O1gfxFE66H4eYJ2qfSvNkSCvqx42OaeVT4sGxLkh4W1pW +7QR19cX+wLYGvrbTl94JL5kvQkRboTaNNAPTTIoKGw09+2L+YuSQ4Kh58sncFlyEja8RpjwEZSI +AU8U5Vv317wbeGI3c7MBMN7lJ8Oc6GTK5fz8Xhze7tZmw/jq/fmj4e1+fdD+9CebiZU4E6UWLQZ 5CucYyzKcHE3pw5UJeQOioKAosfGXHwduG6bpjnvfUikIRLwEkBYHvlS8XK1XK/b2eiC9yWVEwbb tfipKzmVQKdSmSrgLCtvLEpCRBTln49eNvLqH9fOLLYvXo230YyvdWPX47cwCPkHOJt/4f9/R7bC qa3rg6CEovJ/kV8lO24jSfSur+BRHFic3JdjTwEGejCHMrzDnoNatclWqexapjB/0Z/cLzJJiWuS cvdMt6pgmMUUIzKWfBHx0sXLKL1ynIrC2ESoWoO6G1ueCGL5ko4BhriXwa4mg90YoogYFhl1DSAX 4MTkGpC8d22ddg09j2PEplwbExl1zWEC24M9w1wHepOejYmMeaYYXEJhdlzbn+d3ICc0wgzoK4RS mSYSBRCsrnv9JuFr2FKKFB2qLpOF9jq+4oFhvZqFBREXn23igsvYfYIi+q0MHbh8Wc0WaBVaVOvN bIFS87v1AlvRKu5RruL2UI3LaHpTLaNT5TYsK/dnkL/42+zVSNy7GH80xD83QvJ/M7sCPl4NF7rk QBYukUaWrTd0rZ7u3adOnqF7aoHu6bUrd/hY8ASwlAUbt3YcWMeZ9AFY1aM+8ggnw0o5xOyGYEU8 jAjWigDGWBJjCiNYWQd2rzBgwn4f0iDzrvDY85mBrBb10ffnFswCE020MEah+ylYGwOaxrhUlu27 GesBmmK+8MRkMC6smwC0Yz2GFtT64j76GKdBjWgUo2knKXQ3CrW+HXA9EdzHiQnETcMYQAnDEybm seZ/AGP1uI8+xgMxhhQwI38fxhgxWVVhbGBgOtz1DJ9O949zYMbst8dmT+xPIs7RoWl9YRFwmvf3 XXEFTPKphL9M7xPnYklo1WL/xLCJYjD4b5adPZGwU7eACmSBmQ2NyxTIiIcZv+9ffTNSCrLyDHhY A2YSFpwFvCTqEPrXM61BKIzf/bLZ/aKNwM3T4JdKq/vLXuv9bJvK7SCIjzutKRgLUdge0jcCYqEL q2WH6A2AWAPy0IqDqEZ44KotFKccvN5J40ehcDB6RA4eK26zSbIwLCXVC9dDoq96C0sZU2gnM60s 8oOT9YXDGXEB7Mns9nx20RLRXZHXwRyj7XqTictYobzJNNKkfXnHo0byZZfLXtcUuBSNd9j1OIo+ 18ZERl2DIiOuBddw3nvX1knXNGMpt5Kfx1zSTBVM2oNdKiGQcmtMZNQ1YQuhZNe1L323H2sLjgIn q0SJn2xnb99+unF/QglTf3hmrZfqnkeWyoyeTCCUlQVXgqoSeDPCpGlqlW9SM2zCDehY8z2As3rc Rx/jVEwph6D5j2BKWUfkaT/Qk5gC/ZdSPj9M1eI++hgn9ylGVG8AUtiO4R745l/phsUE7krMy6ph 9bFF6oeOSAsGhOBPGFyNK08q+icSaQJiWpjC42ZA0Qvuh0HWjzCNm5xzvhyJFqwtORKrHFMZK/eE R2ISYbXonykB26EOnU35odaWhBsjEqvT01JzBr1nR/R7wj76EMchxUjZjJD61LTUzBRa79i9HhmW McnPjYh1w/7Enl33qqCW4mUpfDXJ2IdefClNRg4gYz+a7b9Csttsvxv780OZUqYw2nWZ2SRippRH D2NdYjaANmtASWw5M9x+ZsBnWyhOyXi9k8aPAsRF6BE5eK64zSbJwrCUBGyuh0TrEJEGDILBYW6w uSnLw1iqDGfoidOu1YeDH5Tw+LYQhYZHm5ktBP5Wq/jRFtruVxr5wIJVLy2o9vrBpcke/3jTdcjU js75wso/PRF9bvx/8+B5wXASSoIjWpVumCgpOEs7euFgHIQhvuLJqZzjyhfc+SwKc144GbpFfEHJ 0wdVrRc6UNqoUi6q3cplsFNqsfCvM197ohi+I9SjsPsobCMKe3gUrh6Fa0bheqNoH4bUolBohJMP Qx1yGGooDPlDYcihw+iLouPxpMT/zzzuVIEgknFAFfwxif+9+GlXQTeKXgLw1wkgMchpRAgKRqF/ 2ZL0ndxcX99ss/Y8R89Ucuh6goku4YdSoC9C+fKOc7rebs/PujsN8QJQBiPBRlrb/Hy2Oe9ssmBo RtJmb4CYgnGFt8fZ31+COmVvLmbIUdw7vEiwJGtwdGEV9ny5zhfcFXZ++ZDjROX8FmuB9Xlc4khy pF3NsxolYZmFdwZ7LCyaoVfZ7fns/WwLD4RzYZ78E/+/kH+wc0uREqDhGe4mgc/hcMOb1HRgDZdO GuypLW9kwbnlTZWbtIovpDZGNVSukyrWFt4rOsmayrekilOFkNLyhsoyrYJ5rI1uOnabVPFEVx2T DZV1WoV4I/NNx+5SKgq3H8YU5vvkJCtctBhKvxnLNqnCkTHoNQGZpVUMKBN3zdP/JakC1soFazl2 nlZxhVFEaesq90kVSRljLcce0yoeyEflTvcL3QlXDi0PUNEYKpa1rKSPRYMuG+vtAceiMQOktk3H VkkVo1GUXtsDIGZ5wL6bXsfAfaFs28qIij+0waBB9zSYZJI141CRQk5PsmbUYAw/oMHQPLLae32A Y1xDxeqmyllSRWAEeMMOqGON+yYYj1fT+6uWRJKE5tM7n8blFpFIf0D4kjLGvTtABVXpPdfTi1Jr AJnrVktK51jjvsV5K2HNHIOXgAiDUvRNAK8Z4RMEgPBgo/67DhvptnVZGNtRTI5oxcNJgQa2tE7T WiSrlW9rvU23aty8vDC8rZXuV8Iiqh5bydmrZDg2aoxNrYe0Fp2c1B2tdBNWBF3JOh6m41KgbF6y znl9T3dvsGUptDksLu3olHcnt9NKzyOj4KHynfNK27IMHiInh9mydCkwUre1irSWK4AM0dHaZ/5V vAZg3EfWzdHGA+kWkXR36k+yQKmEiju9z4Ukfg1SvaLXm1yK+fU3el2CfevAwQ1JgH+T2D09rmo/ 3uV4XYdPD1HNze/XN7k2gBWJZWHPC3pk70j4BBKn9PI2V2yeXa8v6dstfl2G3ddBYRsU8gV++IVe g7X7x7wyHB6lheadiFFwIRks3EB4dUvqJCPcQeiaID0rLHfAXdlTYPX2PJcerZA8IkfvyTTChS+r 3Mj51Tn9Gr4/0GMTXcOX22xJqlv6NXzPXudSzX8Nr3gUHFmCcNgLOyJVVze5ciBplLUsmNtmL2m1 JkFciKwghyhfkiRxExLzN2TlKpoMzmbr/bZkbHtDelmrtYbUSN57BdpnxKK3e7u/CSyqOLdbIMPh UELMeDvPgRMcrZufnOLxNphf05dt0CpxA8+uwjrKB9Ub+rSiT2HP8FtW2+U2WozbfH8ImvTEQTyS QLVhyHYQarnRQkZVJgKEOh2+CW3ZuBj+BzJZ5As1Z9g6BHSZu1g496ECsgDS5Yp++VrJ3AckZ42a UbasmftlEIlVVKuRn6F9hv8bfGEwigegAIWbqkyyr7EgFjxWwTdarmMtXHYtVqW7CRssz/oSI6zb lQofqRWQch74YnnjoU03y305hhwEsy8oY9lJ9HvnzBk91rmf38dErFrOhu8PObchBTKG/HmO508k /jkv01vYeaN3BOF4GH195uPuDHmQAdYKyrmumlzsfd3T6isfkNKJnUUpzAtufcxWrQIC4s+yUAIX oTXUcbtALF/Iz1/vKNxG/YX3UOrby3pVaEo4593auG1ZDVu+xgn8irz+gzb9nGfX9CWU7WVof0Hy flfgdx3YLGoFxVAsEwCkBY0gic7sZTmB3p2QidO3IQMfcT7AOwt94CKCHg/4H6ZHjygPoo/00zKc 2V32LQYS2k94hGKxwNWCGudCIEM/3Q3sRshYlxsBT4WmFFR+dNuJL8MXkycNbijaVXAg4GmMgwck t6Ae5vAMdv18Gf8EPIYlw5PgjT9fozziVvTrOnwrBa/qm1yVBtbx22XUK0VOwp/TuOXbuFW2vIgy 5Z+4dXRsff9fjCS8vAB4EBHwk4OI1vzYbKKdbPmfqH5T7nKW5SS/qseyQnXVXDyPS+AwyKzr8d5F cy/QDENsA11diQkYtMIbvBFmtTIVefuN/WrpceM4wnf+ijmSgWfcj+rX0RAgxIEOCiTFNowc1rtc iwrJtVcrC/n3+aqrh5whh0NSayjJLgVo2d3TVV2Pr15t6vhtDuDkVmhxtVxC3yDadRPUOueTjKud HLNoS/y0kw8l4e7c/MBVvMol4L6ba6TctdnooZL2I59u+qHSH22pdngfCNKDFS9bxCRuNq3SYpGP aB1ghzoAa4FrTSyBIIGyfYMHLHBEe4s/0enq4/XEYg6laCoTdXYKMK8wx2rbGATK/XxyO/kdhClF OICFqXFBYW7l9fUKn3wM1Wfw8Y3SvqpNBG+IC0aY5WpmpDKjN+iAVSbDs21+/vYlSfdLjQt4nj9j GSOheLE9NCTzkLCUsBev38EfowoBd4TcxQqRyPFlCjF+0Z5mhVKwxxUaUMG4RjEpVPCUtiosxlUI BBOGx6uAUcZi9SgVMNjoOKDCalyFlBrvHq8CKeSK4B+lAinbeB/2VVhvVPh9oiXSgLqAlgGXHZoW FIEsy75+fHmFtyiw+DCRgqnQPaSyxl+TquuJ7BDAFvVn2W4pcxRqjVjWHOdlcT2pMfM52+6Xk9o3 AYAu+5qZQcDCZLOVJ0BdDkSC5WYv0hVesLc8AmNPbv8CEw57Q6yRYPFsj+Bd6nrnZ8ggmpP11T9V dbM1TLRiGA388dvUbuQnm4a3LB78utzswRMtm3CooTRBLbVZFfP4zYHYh1UrBy3HltN2L7/FRHwi Ty63ByJoYViM5LORWK/l5H2G23CgEBDPgeKRULnHkI4JMOvmeCRZrnZD2c4ApCk5WDoh8ahUxrmf Gj0GUxMbC5HPgyn9L6OUBkEq9j8NqmwTY1O4QPUIVG3MOXUYqqMYxWBAWG4wqgYwSloDm5I6krtg 1BWLUCkviXSkC0YPF+2IasPp1KXTMUrKN5EcY9Rz29zBqB3DKHKGuyC0i1CT/W/MBaFHEGoTWtL4 JQi1/LxuEfrjcKUv48+XNaRPEaNiETTyl570WKEPCSZLR3rSATpMbSjzQ82oGUqiFnOmpspQwNDX FnpMXPgbPf+FPzYYdTzAseB5AXWCMtiBlN8ru/yN0enaDTRQ7BK1WY2lsSyRd1FkIo1QyVJpyxjZ ChI3kuAqJIhZkoDRsm638hF+Uclut+CfXBans9y6oxu/BpQJ4RKa2IpxKH4BWoBYVV7s2URAWNY+ l6nriewSvuhKbmtuylj9sgCWeh/qLknd51Z3H6rb19XRsRA6aaW8F62iOa2NwUEyop3JnmeJyoZ/ SPTjLaTVvhKCmhWhkN+XlajY+VTIC1m7a3m2e3mwbsUQNff9peGTyihoYcITcRerBI1EKx1CbzT6 Ks6xPefYHefYE51DnpPJ0/KO6BSMH/bOz+qrB9JjfDVcT1LIVw1qGoXSKr24W63u1hWXo241QlNF RldvXw3yQc+h0EagZ8I1TqeZ1evFej2/2WPFpTMdYEUh8HQQOCYSGivySXh9f7Oc9zn1ezEXde6N lTmSy59CL3akC3OIQRJrcKW+dGEHuzCNjsLYiBxyoAnTjVHofIZhn1sIWyYGDd+UeWGoGbNWoymW eYGewbhQIGrB32t+xmdKtHcuNDqYzclyc2KSbwyL1hLtHWxpfpish+GfzUygyoZGnrHHsvZzhL6h xqCL5gFE63QY+weAbwL8QmUO8fCIaaGvDkA/Bk7PaOFbfzxl7Iv9/4sREIOBnbO9FfeXlwgYigCb fE7+1pkvyf6wLipAzv7c9bg2BGwnBIYdBF9QBN/BFCUuUagsET4wljVmNYZChlDCEkxgMEnAdkZn Km0buL66n09uD4iQO8PtkxCm8QicmvloNJhgpNkFYKQyoyxAJsOrgwalCF1YBgA0tA0g2/PDxhyD GsAEMWYFgjy8r8HXjiCRyYhZEUDIbkcCSOzFkOtbbjlRnfX7U8yIhOqgOpsxIcdszLgYNaNDs4xc PG7HE5DgEFqK5w1mZLilPh8JjmcWO6DCalwFS8De4zUAm2T94zSwnOr3FVgPFDdKuvEKlncOAvun X9xGZo9sC+RoJ9aIdBk+DtUfTpcaVuAOLFh3bgdGEenO5OLjFSIkth3YT40eAylGQk/mAlIBKVvD arIXkB4BqU05lQ6DdBSd1vI4tkXn0HzgCDEQJWkY/7zRKbYIWgqKcep8cPozwOn/f8HJRdrylIMM mtTp4HSErJpSSZ02dcBpx8CJZBFVvIBTwAlrhOR9vKDzCDqROglm/AJ0InUmm1p0/jhY2J2Bn6y7 dJ+MzmyL4Myl+zyKTkxD5O2R7hOjoOLEej3IwQPXCfbca0DNIE7hJGtz3rCMtWeNU7aFs0GsoUMb t88dp+oQ1GzjuAmNDSpOOj2VAqKOfEml5FXcpNIhiJL3wDGnUkKRe96FXmzhkxgjeJd6CFXPEJwD U45DD8TVBkmUTDh9OvIar0XGpUtNMmpb4oemI/aFNZI6ldHPHpfWUJB2XOmdCn8El8+k9WRc8sCC fMmBew4so23TpXZmC8vuXDTsFgccKfhzMF+IJ9BNpAjTG8uKvtngOyRcg8YK6JNhV65XAbFBvau1 gSHZCY32rnP1AOfaJBiTY0R1/zkfCbYdfOnvg7FFDgYJBohPjUEVQWGJQAh85WDD+/nkFoax8LrX HBY+I301cS4UMl+w356YhPzKodQS7R1saX6YrIeNnoWyHL4sVrB0NEmz3Nnpy3bJeHPG40B11gIu lZ+D+sNwCVAFcibTKFc6yO9vlvMKSDsGFzxktLIZLYl0pAG0/InuP+Rq6PXtS7inens7SbB2pssL 9pPC7JXdgPtZu1781Awq4oYFC+j09vNEoyEOOHoFrnqIq+XZLiTEJvzG/CFc5vxyMat1mv76aWb8 9B5rO53zErbefVP73JCr/CD2UZTNKwuXMByYeSvzm64vEGum8pCkDknD8gxdgZdBw8Om/xv+f+C3 8Mq9NGT7r3DA9l5505XSFMpX+5QwJmEK8D3iRZd4n4Qjzpu+Vg+jJEAkKZX6r3waJ0HQkaK+Vldj JLgNFFqrTxeMVEDBTMmdrj5HivYq9V+5GydhIyuyPZL1KIkxDUyg+iTVOImDX84TzGpWH1mkS3I7 TkJcBjWdIZhlIwfVf2U5SkIwskNcnqELoQ9JwZ2BF6e51bN9VW7GSZCsMB2eo71HzVI86HRJfhkn 4aSxK9i4LsFgICMdz7BxcJwdlT/jlai4N9xxyziQkWCSj323XI9ScLJI2vahPx8n4c4TGDvdLU7B LQgwd7pbHJKFtsH1X7kfJcFPsE6b03HskCxSIN93/r9GSQxbLFA43WJOJpedXLn1ZK7EXE9jqadO a65vm+K8l68tVogOKqz+OtN+evd5RnE6/2M+syYXUT/9ZlYTPGPQKE0XtzOrp9XDHX/Of6rV3fYq 6q2dVv9gRi9mcfp6Vofpuxmp6Uc+qhby89uCKdbrWR2ZgqY31Qx+ApCxfqgyv3WH3wOfL1b56jcz o8rJ+3KFQh83UC6UVkIjgQ+VUB2a4Llaa3LIDhFDQTZBlu/hil8Vhf5gWa4eFncz54tMIp/YId/P e5GuGtJ6dfVvpq5m6Lzk8vU1v/Cp2A0XKya+kusfmVJ0y5c/8748veB7Zf2Szxe/8pVPeLXrAOLD Jltqt/MxbbdleagZ6H62pkHZ4OaqzC/fZf4f5e0XWZfXefMOj0OwmrHAIEksPDB0lY8KgXxY5w93 ZXefd5/Wa9yMavrLMhPMZ3ViCIEMkNh9CFi0vnze+1jeuhXGdyuR6e4/hFfNToNAEL77FBzl0rgg ZetVPZhoUlP1Ti1G0oVWgZj6FD6yM9/MUrDYXmADy+7sfD8zNLhLUHloEt344BA+1CGVOjnN7KmE kaZtSv9F3jEJiqxSMhNWQBPMDZYhTspYlQLhJwWQNXi0EvS86GYqJUTJXCm6NDNpFBZ+IaoUcbR+ 0Qobajp1xh09v+EF7/nlLWYotRIl9ZYnFhJQx/hopHvX9ETmRHKMmcT0n6deU294k1I5SwJ+uWY3 mD/XwZbfEEQJ85+GS77IMTF0SOYOJyYEExLIOGLUJXFMo000Oq90yr+fw8CyoumJDND41Pg89oDs LGiq+gv+YLV3klaIQLz7oAsrNhecrBBhXK5deqkZEUczTMOjlnYBA0xjOdATbfCuyoJL6OiNlbDR XONZyuriIJyessv7CsYEufTQcExZ+qrC9684SMpkMVN9Fiwe5mwNzNBgud8LU9Y0OWfQK9k5Jup9 SVLTc/YTQ2umGjsMssSGvNouPKJUE8Wd+5t/c0XlNLB2kiRxZH1boA56KcbdKtusihZVqGfAPHRq 0d56x1nQNlCTwwrfkO2gpAj2C0KEZP1DlWUyqC0OVSiX8tDjHZXTeEZfBNt9BcYHsBeHgErxmh0T b9BdnK6NKbW0sbEqjDJb4xB/xYGiLRFsaBNXwPdQ8a76nYBPhrYAfC0EfaELraLuh9wyyyTtg3aA a70ItBRrwhBI1aE9dFdJQi3vB5x5PPsVYADZFpqBDWVuZHN0cmVhbQ1lbmRvYmoNODQgMCBvYmoN PDwgL0ZvbnRGaWxlMiA4OSAwIFIgL0NhcEhlaWdodCA2OTkgL0FzY2VudCA2OTMgL0ZsYWdzIDMy IC9JdGFsaWNBbmdsZSAwIC9EZXNjZW50IC0yMTUgL0ZvbnROYW1lIC9OWklFV1grVGltZXNOZXdS b21hblBTTVQgL0ZvbnRCQm94DVsgLTU2OCAtMzA2IDIwMDAgMTAwNg1dIC9UeXBlIC9Gb250RGVz Y3JpcHRvciAvU3RlbVYgODANPj4NZW5kb2JqDTg1IDAgb2JqDTw8IC9IZWlnaHQgOTYgL0JpdHNQ ZXJDb21wb25lbnQgOCAvU3VidHlwZSAvSW1hZ2UgL0xlbmd0aCA0MCAvV2lkdGggMTUwIC9UeXBl IC9YT2JqZWN0IC9GaWx0ZXIgL0ZsYXRlRGVjb2RlIC9Db2xvclNwYWNlIDE1IDAgUg0+Pg1zdHJl YW0KaN7swQENAAAAwqD3T20PBxQAAAAAAAAAAAAAAAAA8GYCDAA4QAABCg1lbmRzdHJlYW0NZW5k b2JqDTg2IDAgb2JqDTw8IC9Gb250RmlsZTMgNzEgMCBSIC9DaGFyU2V0ICgvc3BhY2UvQS9CL1Mv VC9SL0Mvb25lL3BlcmlvZC9JL24vdC9yL28vZC91L2MvaS90d28vTS92L2EvWC9lL2NvbG9uL2Yv Ty93L2gvbC90aHJlZS9nL3MvZm91ci95L1AvVS9oeXBoZW4vbS9wL0cvRC9GL2svTC9WL3F1b3Rl cmlnaHQvUS9qL1kvemVyby9maXZlL0UveC9zaXgvVy9zZXZlbi9laWdodC9LL04vbmluZSkgL0Nh cEhlaWdodCA2NjIgL0FzY2VudCA2NjIgL0ZsYWdzIDQgL0l0YWxpY0FuZ2xlIDAgL0Rlc2NlbnQg LTIxNSAvWEhlaWdodCA0NTYgL0ZvbnROYW1lIC9CTkxJRUgrVGltZXNOZXdSb21hblBTLUJvbGRN VCAvRm9udEJCb3gNWyAtNTU4IC0zMDcgMjAwMCAxMDI2DV0gL1R5cGUgL0ZvbnREZXNjcmlwdG9y IC9TdGVtViAwDT4+DWVuZG9iag04NyAwIG9iag08PCAvRmlsdGVyIC9GbGF0ZURlY29kZSAvTGVu Z3RoIDEzOTkNPj4Nc3RyZWFtCkiJjBfJbts49O6v4FEEIkFcREnHxp1DB1OMgTi5TOegSootxJEN L8m0Xz9vo6MmbloEIam386308s/ZH8vZ9XKW5lmeV2rZzvLM2Votn2cmM94ZtfxrZgBZqRz++ORM mZW2qK3yVcgs0DzO/kkWe506m2y1CUmry6SH/8NBp9YzjNEH9SXRaZXcfF580XhQByReE7LXVdKd NnQe4DyurnRqbKI+LlJimpKWSYdiT7gAi8+ZhbArBAKvzRN1BBGBTVC0fsWFoQ2tzId4/a9aTl1i ioJ9YmpfnJ3yC5+UPgtVVQR2y1ddZQWYC+IK1GrdZBcwuqaGXc3BngIOC52WsN2CUQg+kYzINGzi 4bscmjNK9i0xjOg82DMQj2Kup6bciyomjRb0GnHqwPpbJl1HJMXG4nEYBbYi9ivR8MwGiwrVNmLP Dgx0SHh6pY2w6rh+BZjGIZcIYC4+v+f34DITSmPZ7/MFRPVWQzKoBnPn/l5DJg54HCkpB0mDKvmm PeThlggUQdZE0WuDtsCJgCTmAFIfcFE6yhjVHXx/xnRHeINcY6d2SLCX/Ifl6ay/Y8FMqD4AE9r6 SZEBRLu/kIlW/GCt/akjXFC+MFnwRahe0q8Sh1vJDwuVg8HHOuF9gLCTXwSKPDEqlqMCgJ3g5TsK bfso9okYexIWVaiooxGiHRFRTgJ2+UpJtOHqrfqPmJSWa8MkqRDeMLQ9U8cktTFJzxdqm43YEPcD 5mt1qe49ezsvJ3X/82aIfvcYG2cd+12shySCAIOFnu32ySeyGxINIxOwVMASD+VYZoGKMYhjPZeR l2r0XI0+OQumixbILBf1yUqBADNVfse8c9EqRlBjCVKv4UXkWbOaiGjERCFuJkQRJRY+kPlvvJlX gb1pTR5+3UXRmRYE5aasYxKT8b0OeEf+GLDlgzZq+LAf0DtB2j25kt28F/yJv0feMpwNZGtqi+TD RpgOxFVg9ulSfG0pSqhZUTHzLAIi0dhql/9AiowdkqBS2qL4gXAjA+UeLBSGYPhNIWzLQZPjmftu ziSL2wid9s/JZDfu3dYBe17lrmCvPzY7bJ9Qr2C4JbsNmo0t9bilbU69C6C3Guavalqkg8UlhN8T R4fH4QI30h2RY004rHOQcY84WAzyOO5Z0IG/6QLCJWKIZqLiEaU0JGsgMHFCkP2F2vZ1zMZQv+uO HFKhqGp531zrGkoLWjesEPqQ1WSahb0TVOoRKkh8fuAu9QOH3RbqFQ4bYYvsLTRMA1PIwQCDKwpU xCiYFqnxcHqaGLARXVuC7SJJp7A2wT0IZdyeJi/IeYhE/Q5UuBJOo+BWRKmiXczYnC+H1ilsIFCI U8ymiQL4Bv3V28SLfTR34T1fu9pnuSt9yb5+hnTicoAagbppOa/X0N6Sx54/Gt5GoTkwi8LwZzix pwJ67bGg9vJJs/thYMoooCMOEFNNxNzzBp2ORoXH2W89QsTEYbNRsTgKajusHto7HcRYBSFyZqJN rN8MLO670HWZtqT/b1Z3Yil7Xb0uax5Tjt1b2NJJYzVV/V5ndZXNSkhqeZ32/2HuQANzMnUcvQVK qChMWpf0Iz/dHPd4J/lYwCmS0JXLZBR+oTtGefI4dTRUGuGNMB7qDueShS0V9A1DZagDaycIfD+W Mr4dNxUEr2SXJ4pjt5fnO+F0LWm6vsCi+RTY8kLPlKGV2/A7v4fQt6XJrAuFiVNLejmogZfmUQ77 +ADAdkXDl8ANzc4xIrX8ThCSVAYgkXJyvkgaVvw9MPXIX3E2byieInD+I6cI7Ej3INrUgQd9e1E5 0540jySiOOtlwhW/AuT62LdpLgu/CD8Or8ifotXiJLJI57Gkokphx2ip/wUYABJ7LL0NZW5kc3Ry ZWFtDWVuZG9iag04OCAwIG9iag08PCAvSGVpZ2h0IDk5IC9CaXRzUGVyQ29tcG9uZW50IDggL0xl bmd0aCA1NTAgL1dpZHRoIDc2IC9Db2xvclNwYWNlIDMyIDAgUiAvRmlsdGVyIC9GbGF0ZURlY29k ZQ0+Pg1zdHJlYW0KSInsV9FyhDAI5P+/xaf7mON3anuaAGEhRKczncq0Z6rcsrshMWV+4om/G0Te PRhuPoun5+i3ecUQVwlJaWp48uKEy8iLzLA/9UyH0Nedjst+1LEvf3G6XXnsYkVm3NBlltd0iwV5 3S9FVYwYYV23dkKjSxho5IPvkMqiJ2z/A6zBhPPWWg8HX0LOp7xYyfP90mbUKCcmRbzUh7KejkUq /6zR2l703vYvb7S9v7E2ov26/+6jXIJSU+GVQB3z2C4CE+3nx9PUUP5pvw37dXaCXZutTLtndVR5 SWrg74Ebbn5rNvT+3NajMF4HWDmovR+AiDeBNF/WsC/MWEeB1wzW9XB3y7CBMNS4apwcM7ggUjap ujrE+mbAYnzQHB2AOqZ8mcRSGmYBoxRU2M3PKk7y0YW8auid2uZs1vu4WWM9swoaFqyzXsw7XDmL vsjLJiAsvSGvLru+4ZtquPsSXkCjn+Ut8du2ybSs/6CqUSf4xo3EErjbogCZsrA8Y43xllTBypl/ ftoyMIc7U5apf4J57O+FK/NYwUrkffTIC1nRIa2medRozkLh/1bc8s8Ng176sLuqURWbm0coU+SS M/LLIjyZNoyWoyMs8aIqr0ms8Qy2GHklJw8sSYSX1Rz2GLDwPTiYWNlQXWMKZgFeiotcvkUsjXtH VwcBGTm89DOT7WCNE52U5T6PGkANCieRsnNAn6fR7sGTGkVqmvDEE/80vgYAMpo+Mw1lbmRzdHJl YW0NZW5kb2JqDTg5IDAgb2JqDTw8IC9GaWx0ZXIgL0ZsYXRlRGVjb2RlIC9MZW5ndGggMTg3OTMg L0xlbmd0aDEgMzc4MjANPj4Nc3RyZWFtCnic7L13fFRV+j/+nHPuvTOTmcmUlEmfO5nMpEx6JRDJ DZBQQgk9QSOhSHdJaAqCiQWBAIINO8SCIqAkoQVwJbqWRUVw7YIQFRVLlHWxIMnM9zl3Jgjs7sfd 7+/z++f7Yob3eU6/5z7nOU+5MxmAAEAQNAADecr1k2q/Umb1xprtALZZUxYtkP+R+vEtABERAJpX p9VOv/4vT8XiCHsHgJQ1fc7iaSNufjUHwB0KkPzyjOsmTT1ydextACM+xDnyZ2CF9QfrzwAVZiwn zLh+wY0t/cJfx3IuQFTSnLlTJhHtyS0As67Bcur1k26sNRLzcwC3r8T+cu2862pP9br3SSxjH1MI 1rEAYoCvG/QKljBnKANBnwBAYrCgwdabST1ZR+4mj5Fmcpz4aBV9jR6inzDCGNMxJ7uZNbI17DH2 lmAQRgjXCBOFe4T7hUeFJ4SdwgHhI+Fr8S/iN+JZySBFS3aptzRW6pS8ccvjzskmOUyOk+Nlt5wu Z8o5cm+5SO4rD5DnyvXyk/LT8naH6AhxhDviHW5HumOM41rHfY4t8TReijfFW+PD4qPi7fHJ8Z74 QfGT4q9zUqfZ6XCBi7oMLrMr1BXhinEluFJdua4i1xxXg+t210rXGtc9rsdc212trv2u510vu95w HXF95PrSXeRW3P3cNe4p7mnu2afF0xGne5+hZ7LO0/Py+fzzRef7ni85P+B8y/mvzvu6JncXd//o 7fJ1+Xycs9CkcqeJ7CCHyW/InVeROx8yuMCd25E7d7InBCIECyOFa4X1wgbhIeFx4TmhTfhQOC02 i0fFMwHuOCRFqpHOxDXENckGOUS2yTJyJwW5ky0XBrgzC7nzBHJn6yXcGe242rH+AncsyJ3I+LgA d2rip6rckf8NdyoucGe9q8m19QJ3XkfufIjc6X2BO9e5Z50mKnfIGeE8OR97PuV8L+SOcr7/+bLz 75zv6rq2uy9yp4Fzx/c5Cth9vlD6Ov0zy/Adp28CeE0oWXeTG8hsMq+rCcszuex5Pd4Ub7I3CbNL YQksgjkwA4ZCX4Cuo11vdHV0/a3rCARen1cDfHbcn+9Yjrjv06s7bu849+mWjhuwtBexHtHYsezT hSdnnVzcsf/z1I47T245ueHEhhOPn1gNcOIpPvak7UTdiYlYyjyhnMg5kXC87Hjp8aLjhcfzj+cc zzyefDz+ePTx0OPk2PfHvj12+tgXxz7jo469euzgsReO4VWOvXJs87Edx0qP9TtWcizhWPwxx7G4 qPao36I+Nb8AICI0j2oe0TyseUjzoH+10tdSX3GtCGwKP2ckCi550df9uKT8Lv2tp8wGXdqfKRfl r0EJaxP+BiB8h9d+RGwS8eSLzRf3F1EPibv8+HcvcSOH2BQoPfLve/7TyAXiogv5ef9jz8pLVyZu l26Vtl7ShcETcDssZ9fCBvgS7oA7YTU8Cs/Ak2CGRmTdbXAPnIG/w1q4H1bCS3AcfoCNsBX+AT/C WXgcNe5f4VV4FibDFFgPU+F1uA5eg0PwFrwBb8Jh+AqmwdtwBI7CczAdvoe74F34G7yDMvc1fAur YBbMhNlwPUrhn6AJ5kId1MI8mA8LYQHK5g1wGm5EKV0MN8EylNe98BjUw82o92+Bb+A72Ec2kPsJ JYwIRITz0EUeIA+Sh8jD0A1eIhEN0YKPPEIeJRvJJtQbjxEdCSJ6YiCPkyfgZ/iFPEk2k6fI02QL eYZsJdvIdvIseQ71SzNpIa1kJ/wK75FGsprsIrvJHrKXtBEjCSb7yH5iImZiIVbogE9JCAklB8jz JIyEkzXkz+QFcpC0kxfJS8RGImAHNJNIEkX+Ql4m0ajrY0kceYW8CufgN/gMPid2IhMHiSevkb+S Q+R18gZ5E/XbW8RJEoiLuMkRcpS8Tf5G3iHvwn6SSJJIMkmBU/AFeQ/eh5PwEXwMx+AEfACfkB/I GfJ3tB0/kn+Qs+Rn8gv5lZwjvxEPOU+6SDfxklS0K0AJpZRRgYpUohqqpToaRNKonhqokQZTEzVT C7XSEBpK0mkYDScZJJPaaASNpFE0msbQWBpH7VSma6iDxpMskk2dJIcmUBd100SaRJNpCvXQlXSV aBYtdC29k66j6+ld9G56D72X3kc34Pt++gB9kD5EH6aP0EfpRrqJ/sBuYbex5WwFW8XWsnXsHnYf e5A9ihZvM3uGbWPPsh2she1m+9if2YvsFXaIHaZn2NvsPfYR+4R9yr5gX7NO9gP7O/07/ZH+g56l P9Gf6S/0V7GXWCj2pufob/Q87aLd1Et9aDcIo2g7BPodE8UkMVXsIxaJfUUF+/YTB4hl4iBxiDhc HCWOEycwu3itOFmcJs4S/yTOExexRHGJeLPYIN4q3i7eIa4UG8U14p3ievFu8V5xg/iA+JD4CPPw Ey4+KW4Rt6Pt2SXuEfeLB8SDaKVfE98Qj4hvszTxHfED8Zh4UvycZYlfid+KP4j/EH8Rz4s+iUka SS+ZJIsUItnYt1KkFIt2S0bLFS8lSG4pSUqRUqV0KZPlSdlSrtQLLX5ftGr9pAFMK5VKZdJAaZA0 WBoilUtDpWHScGmEVCGNlEZJo6Ux6BuMk8ZLlVKVNAFbru7hDQtiembw80a6Bi3kVGmGNFN4Utgs PCU8LWwRnhG2CtuE7cKzaFV3CM1Ci9CK3scuYbewR9iLdnafsB99keeFPwsvCAeFduFF4SXhL8LL wivCq8Jrwl+FQ8LrwhvCm8Jh4S3hiHBUeFv4m/CO8K7wnvC+8AFa6Y+Ej4VjwnHhE+GEcFLoED4V PhM+F04JXwhfCl8Jp4WvhW+Eb4XvhE7he+EH4Yzwd+FH4R/CWeEn8jk5Jfws/CL8KpwTfhPOQwu0 0kaSC7thD/yFfAE7YRe8DLfCi7CCDWcj2ChWwUaysWwcG88q2Wg2Bn4iX9F24WZ4Hh6ETtR2m+Fu UgzrSAlZRO5CW3oPuQHayFLSSb4X6oR5wi3CfFbFJrCr0SpUC7cLC4UbhOXCIuEOYbGwQlgprBIa hdXCGuFG4V5hrXCnsA49krtUn+Rh4RH02zai9/aA8KCwTNgkNAmPoafyhLRAWijdgJ7NCXqSdtBP 6Wf0c3qKfkG/pF+hdF6F0jhaHCOOZXYmMweLR5mcIk4Vr0M5HSFWiCNRSieKNeIklNxycag4DGXt ZfEV8VWUtzfFw+JbKLvz0YIsRCmeK9aKdSyRJbFkloLSfJO4VFyGkrwK5XkFyvNqlO965mGpKNV3 sTSWzjJYJsti2SyH5aKUnhV/En9Gif1O7BS/Rzk1o6Ra+TVRTuOkWSirs6U57Fv2DeI7lMsSlMz+ KOkd4qfiZyi9ySjDiSjDHrFMypSyUKZdKM9pKMV9pCLpKpbH8tk/2Fm03xL4HWd8EYoJvczQYSMT REmj1QXpDcZgk9liDQkNC7dFREZFx8TG2WVHvDPB5U5MSk7xpKalZ2RmZefk5uUX9Crs3afoqr7F Skm//gNKywYOGjykfOiw4SMqRo4aPWbsuPGVVROuvqb62ok1k2DylKnXTZs+Y+as2XOu/9Pc2rp5 8xcsXHTDjYuX3LR02c31Dbfcetvty+9YsXJV4+o1a+9ct/6uu++5974N9z/w4EMPP/Loxk1Njz3+ xJObn3p6yzNbt7Htzz63o7mldeeu3Xv2tu3bf+D5P79wsP3Fl/7y8iuvvvbXQ6+/8ebht44chbf/ 9s67773/wYcffXzs+CcnTl6JFK5EClcihSuRwpVI4UqkcCVSuBIpXIkUrkQKVyKFyyMF8U7EULAj Yti9EA3g+xRxCnHaO8TXJc4Gp3eWr4Pxp/LPBgDgQpu2CRLgDMnCvWyHIfAUlEAF3AsD0SLtgGBY TN4AAZwwALaAi9gxAikDG1qSB1GnXoN26AvU7klQDidQzydAKdqmcCj0fY1pOaz07cNeQdAfLdt+ MoeMhgzMD6KpxINXXudrBxsk+Q77PsTSo6irE3wtMAhzX4IFEtGK3QVWtH6v+7pwpQloP59Gufoa HFADq4VcodE3G/qg5L5HyjE3DBaLH+p2o5W8C55Am9LuO+n7Cl4QCFrbepTolbjiVmin6aw/ehQy uOEqGA6TsPUm+AitUxZTfIm+fr4HsfZp+BE186tMg+vwwGCYiLb9MeTG+2hRfkLbmIfWchu+3ybf i/yTk3K0xUvQ4j6K3Hsa7f0+1PZZaAtsyC0bJMNYbFuHJ6UVz9dRUk6quOVjm8VMb7Ev1Bfm+wp9 9xSoxBVuwpN3Cs6STOyDV2DxbIEQJywQs7tvwTucCo+gl/A2ruME8v0n+JWk4PtTejOt9433bfF9 gWvRgh16wUiYgJ4C9w4ex119Cc/038l5tGA30yPCKyjHZ3x3I2/d0A/XPgJ7j8a5V+MutUIbvt/H u7Sgxc0ivchwMopMx5hiA9r1j8hHaAsdtI5+w5rZG+y4kC+Kvt44UzjE4XWdMB69ljnofayEu/F+ t8ArcAgtvpuk4R29j+N/pn3oAHw/QY/QE2jF1gld4h3eDu+33vO+RozvBqDcVSI3tyIXfkBPQUY7 PovMJ5/jytfTXSyYmTGKyWMlbAxqlZXsXvZXjPTmobb9WByMJ3qbZpL3T963feW+24FHxxKuKxFS IRcKUH6moTTNxvXVqh7UUvSQGtGbuwvX2gTb8L4Polf2HnyCXtNZAuhvZJKZePXrUeqWkzvx/SD6 Pi+iX3KIfIp+A74pBjhoyfNpMe1Py+h0uhzf99Kj9H16msWwKayeNeB7I9vDPhJAEASfmI3vQag3 npbe0CRpBmkma9/s6uxO6a7qPuEFb5T3au8G74ver3zjfItx/S5Ig3Rc6Qpc5YMog5vxvRUlcQ96 lG9ybwbX+iN6dyL3otAbSkHfJYsUk4FkML6HkZH4Hovv8WQCvieRyWQGvutJA7mV3EZuJ2vJfeqb +4Sb0b/bo3pw+/H9HjlJviTfkB/REwL0g2zotyTSDFqId9qfDqQj6Ch8T6dz8V1L59FFuENP0510 H32fhTAX6sJJrA49k+fYS+xddk6gQqqQIRQJ44Tpwm1o1d5GO3ZetIul4gz0AF7CeDMX7e0s6QFp h3Ra6tJImgrNZM1Szbsan9aF2uo1vO/dl/jlGdIRMl8MFW6kJ/FcRLBacQUZixyT6Bg2ByOQv4nT yBkmk49JI5vJZvueYGX0VzaXjKMHSTz6Kr3ZNFiDvu82tCBn6VdCGBlDvyZJwl1kL53L+lNJjQfe EcKE28TTGP18AL3pMtJOX0H/6zbfn6G3uJGcFDfSt0EWOmgInMRTvYLej4PeojPpaqgUcsXzMBP5 /ox4I/K7L11JUti7wkb4gjnpP9AL3YBa4zAZIiTQa2kh2YYat5vEQSdBD5/cBwr6y5+QNiBkC3ua DKUG3K1maiQFGHMcZg7yLguCKr5G4qZhpIKeoWPZ89JRlkcIaom/wRL0+TNRdnpeXowfpsG9NBF1 Wilqk3dINkRgzFICZ73Pc40tfiiuRjl7jKXCKMiEavoG9Maz8QW+KzHuyYb9KIMrIZM+AEt9DWQq 6v1hqD8p2vtZkEH0qC1tuLZ6tBfhNB51IcazGB0EYcTTH8rJ93ADkfFktUOSwFvWCKWomWpQ/67G 91SoxtIjcLe0W3wHRhAbRo+ydyNK+XG4Fm3O53j9KCjC9U2Ax4RUXLWMmrkORzziHQQKvu+ANwjF GKg3RuqzoEIYhJp3g28W3uFMtFFD0SYegpm++6E/7t0o322+1TDR95jvGoy5Rvu2oP5d5GuFfFgh VtFxokfIRR17iLyM9ugYWY16exB8jPrIhbHKN/jGeBb6igegUfgAdWexb43vPQhDfsQjhyajFT2F 8dr3yLdBrB1yvMNpi6+M1aKFOgkjfU/77CQIZvjmoOZ9HjZrRNQ9DRAnbkbZBaXf2DFKcd+rivr0 LuxVkJ+Xm5OdlZmRnpbqSUlOSnS7EpzxDtkeFxsTHRUZYQsPDbFazKZgo0EfpNNqJFFglEBqqbOs Rm521zQLbuegQWm87JyEFZMuqqhplrGq7NI+zXKN2k2+tKeCPadd1lPx91Qu9CRmuQiK0lLlUqfc fHiAU24jE0ZWYn7tAGeV3Nyp5oep+fVq3oh5hwMHyKURMwbIzaRGLm0uWzSjsbRmAE7Xog/q7+x/ XVBaKrQE6TGrx1yzzVnbQmx9iZqhttLeLRS0RlxUc5RzQGlzpHMAX0Ezc5VOmtpcMbKydEC0w1GV ltpM+k9xTm4GZ79mk0ftAv3VyzRL/Zs16mXkmfxuYLXcktreuKbNDJNrPIapzqmTrqlsZpOq+DUs HrzugGbbklMRvxdxcmv/yhUXt0azxtKImTIvNjaukJubRlZe3OrgaVUVztFMXWU1jWV44TXIwvLR Ml6LLq+qbCbL8YIyvw9+T/67u85ZymtqZsnNOmc/54zGWTW4MVGNzTBqsaM1KkrZ5+uAqFK5cUyl 09FcHO2smjQgpiUUGkct3hmpyJGXtqSltpgtfra2BJsCGYPx4sx1F9rUnNqd58pHXeAr4StyDkZx aJanyLiSSifeUy+eXNcLGqf0wm74qiI4qnkq7sfMZl3/mkZzb6w38/HNosvslBt/Atx/Z+d3l9ZM CtRILvNPwLNcSi4IGrb35Js9nuaUFC4gmv64o7jGvmo5Ly11URttdtaaZSTIPqhA3k6q6p2BzHc4 +PaublNgMhaaG0ZW+ssyTI5uBSXDU9VMa3hLe09L2Fje0tDTcmF4jRPleJf6qD6sWeu+8M9kDg8p ndG7mYT/D83X+dvLRzvLR06olEsbawK8LR9zScnf3utCWyBH/A3I8GbBhZwa7ETRGzWhklfgP9FV 5iydWTMIjxqusTmkfyWLplX+HI1m6lQov9dcmJkXKg18LsElqfI/tU2jRQFWa4hc1myuGeRPq4Ic jv9wUJvvDB+lkt+HBe6pubfn0nKfS8qXLM/QyHDBgpuWj5nQ2Bh0SVsZKqvGxjKnXNZY0zipzdcw 2SmbnY37MHStbKwtrenZ/jbf/tXRzWVrqvAmZpDeKNoU+rU4ycqRLQpZOXpC5T4zgLxyTGUrJbR/ Tb+qlgRsq9wno35Waymv5ZW8IPMC2jc8Fa1Uq/aP3qcANKitglqhlqe0EVDrtD11BKa0UX+duaeO Yp3gr1PUOv7imqL/mMqLZUA9WFVp3LJTEoOeSozIn1VqYFgLJQfoC+j7aujBVhCFNvrCLgZBGp7Z TSBSK4kHsZ0CI8mgI7PJtRDhMf9c1F003Hy2aFh3ERRj3tyFSVamw+KwuDAhMQJ0yay9S+FPEWWh Ha81xzeVPSi+gHYrFfLIupaYgjZyn1IVMjM/MSqjYKVtTcaqTLF3bnnuxNxpqYttiyIXpi7KXJy3 StwQ+6z0rGZH6I6wF3NezTsn/pYXEhRJFG2iWxQER15aZIQgh4dlu9KEPHekKJCQ8LAIQ2LwQXIX hNFIMEEw2QSJZMouk8kgkufJdhDIFHCQB3fFx9uN6Det5UeNrN25I5SEtpH1Snj2Z00xJCYKCohc oBTUFHQUCAXBchtLVHRGcNQ4ah3M0UatrSmf6drIN4rBjO7FRAyhBIjM348OMkEWIXeqh53tPFut cqq67ufqYVjoNHciv8ynOjsx7cbSKYu10FpYaLHxlPCCjRdaJL6D+yDSd2anzprrxqOgGDEjmjHJ 4wl48FWVldl/sZKSnpWUHBsXpM/MysiiUnpc9mSSpE+ZDFmxaZMhzp6elhyUiFWJegOYi8xFHjUh Hk/KLfiCumpS7QnJCQ+3WdyJ7rzc/IK8nLBwGxadbneiJTw8LFTShDnzsEAskhQWGh6SX5CP3oY7 cU6qfsN9n5bn7d2qjOoV+0SicfXqrnVv71eufXwymTx1UuWz5Um9SkY8SoavujuYDlo9e+j1N7WF XHONGKzp631v0z3BXqH56aWNfzM3NAjOJBZF3jZMHz64vmu9McJZp/RbNIdHZaNJA63E6JhBsSJT sSF2an69iCym0MwYUDOpQC2/njSRo0TCsDN3NzQIYyZwGe2uxvuEjE5MszL5PTrCHKOp2H2e2u7n M9/lO0Xmoh+pB48SA4qkZ4pO6Z2nU4rzJurIJt0OHdUtN8xawueqm+fx4NZ1ZmW6sjlDnPGcUwQy lJL09JKSl9Q0PUPh8zLfKdpXvBNXPErRgfiGfXo++uVcfIyUhVKKy8ZTqEdP2K6EyiyT1bBa1sQ6 mMQOkGfpG0Ibmdtykl+VSwzKS3HRCjHds8z8clamh2DgRvt6wyrIt+Kdv40Tt/LPeYf4TrO94gww QwLsb52kRXdKahXFME6Mxqg2YlKsuihwK26quGvcTe4Ot+C28OpgLrf1sA6DWhEiXftJ3O/S26nK 7TB+2/zGUdKGkgRnQnwCxvUYLlBJ44qJjo2Oi2ZSiNvk0rsjIm2RVHIIlslgl6Imk9BgzIUbMJdA 5MkkWouJ1Rw2GSKDMOECTHiSoiIl5ZaQXGtBfk62LdwSSpHDie4Csy08JxulzZKbiLLpjNdIdMia BRNqHln68Mp3Jr90y/UvlxbW5S+IS89MKEzuPSBvUC7deJqMGFWy6RXvju+8e+774sVfvKdb7ps0 bzspPP3w/EzHVaO9j+AenUH1JyHHwuF+JVSJqIloiuiIECBCiaCLMDigwSUhGM+XoMZrQj+dqXkt 5p24wb+CicyEcKwB8qMSTEwmqsOoWqc1UAb7yS/YfbBiDQ42KZa8TFO9ab2pySSYIm37aQI5FWCu p2gYHn5zkbq7eOyJpRB+6uwiP3k8WRhNkbrqEFeOJRQPZZgjry/N4wzg93+GDHGEFF3jpTW9woM0 rihXP+G1x86vmNcrjrpcNDZrCT1+b4ocZ+dymIr3uA3vMY7MUG7VROgLbRExV+VGKJhE8sQUFx6e rCnSDNY8o5EU+WphgvZq24SI2doFlgXWR/SPBj9o2a7fHnxIPGT7a8RHto8iOuRzwjlbWBiJFSLF 6LDI8EhbbIRGZ9NH6GNzIwdGrrKtkzURkZTaoiINkZKRRVJRwsAjLFQTIhjbcBk6nRJqKG7QEV0b y0HFKUatiySbIndE0sj9LAcZt3YnoYa4NrJWMYL02YiQiSFzQ+pDhJA2olFCuA2MAlmRG2RWIzfJ VI48QM7hOTMSRQmdSOfSerqOHqRH6En6AxrOSPt+cufv8nyqqDOgiXsUcWd3dV1RcXedX93uXacj B3VHdBSq66o8qJlRFVtVpVxIzf4uu5ZFro3E9qrgohVmcdnLwXgkSd28atwxFGLwEObIA0DV6IyX NM58FGZ+85KGahzZ+fkFbNvErg50ROWNf5q6ye2KPPLw5k8yhzx1ri+ZPGd8WRQRveddpB954Jlb nlpYt+/Vd9dPn/74bu+ZXuasNK4J8ZSPw/3MJkP3QZCvo9VQqGvztStFhsISXWlQmb48XjiiI8nJ vZKV3JrcI7kdub8EaSCXlOjqnUvStybsS9iffij9pPOk61j6N/FfuwyDtcltZM3OpCQztNFTO49m ksw2lrubieZwEt5GNu2OVTwZubFtpP9OszE56QCZAaGgo58r+grcA7pe3QPcyZ3NBmLgplNfkdaQ RtenNaXRNKzfPVFTj/feRr9QgpRc0pTbnktzUe/13auEHAyhIZE5XOGcvrBB6u50Vted5ckp9C9Q 9Xg65xV3VndaCzP8Oig/PSPOHWQSpHiH05HgcDkESXQFu91BqFwyhLTJJM6EOYceLV6QLl3KnEzs xliubfw2z9Nj9vgZmwd1Hk9IvqpzcJ/C1c1yqKqdV4Wr2idP1T1up5OfQ76zmhm9W25/Yny//csa au/2frtqSoYjMspyo82VMu1+Z5Tds2G4PGLToFtqHp4hDFl136wRE+7dmLXnpuZbtgxIjE3VisWS fuOcEeW9YpNK4oKuvX3E9PqnuA5Hf5Htw90NAiN8oCSFG4kJSo2KiSkmkmIgYRpUuITpRIkIBr0R BINRkAxGPFUxilWjDdVotFomaCSDFtCpMR4gj6BPpyebFKNIJJ1WkrSiYDAIB8hgPC9aMk3R63Qm RjaxHYyyNvKLEkGK1eNlIjWorzpMzCQpGqKJDL7oDNUVqTtUhAcIs1+aufdXXJjB/Qlzp7l7XpGl 0KIemBXpHgHtFc+aTCbUaPPQyaibR8KcFqfFkUdykBC2b8/m7pfowj9t9iaQs3d6HyLTGtitXWvo Y90Tuf6ajPK+WByKrlqc0v9JgVir4mbG1Yv1Un3sGmFtrCaP5jnGsrHyeMfsmEXi4pgVtDGqMeYJ tkXX5OxwmsBJ1K84oS+jDUXLyzirLLIDTa4gO6KiY5gmQhCxdtNOWXaE7EdNEsFCFOQp+QzoZw4H +nP7SV+IJgN3N2iauByTn1COnURx1jipEw/IuT1m2uQgDj6JopMVc5OZmiPjuQ/4tcqxU9Wo5s3V nDuqaJ/i3h/qnuJOVaBR63Mts0Kb7hGRXcALfkWjGOeReXSefCu5ld4qS6hxuKJBPYOhk6KfLcy1 To2rFWtjxeoqUk00Do3AJViSNAHPBBVPQHhRdhMJWzzcO6OK6B5ePv72kfMXL5mb7oxKzCgftrBl 4+rrnyeCOHTrnsSNK9tm72lILBidHeMxO3Jb6m96r3eahpq4dFbiXrSgdEZAEnQpKQt1i4JuCL5V 95Hra5ckMbKMLRGWhC+3CUXaJElkzsikSInJE7VEi7pjj+wmbrcJnbO1OyNA5M7JTpORIHMVvkeK VR8FKUoKVVJqUppSOlKElEg/37EJQswhckhmiBKyPqQpRBMSmfy7i9JVPaz7VMBHUVUFKnTkanXn PGQj+Z2Xu/RStERVFqL+SI1x6ayxMXExVLK4jG6Xzokawhw9GRzBmEsIck8mMVZ5MsQbMIEeH4Ur DVVlkLBgpunR69xHseRaE/JzCPeLeziOyp9tuP3pJ2YnrL9r9ZvTl765etILdxPTr7O737QOLMsZ PH7VymXu8eIMl3HE46+tmtLRvHXN1mt2ktg9ZJC3snvAitE1n/bLePKBbb/JeAqG+k6xzXgK9PDi PhB8HTtDovuKbb4OxYOZSC0RWYquHyjGGmOT8XVyiH5IPqQdRmQp0RMwKkZGMUxqI/coUYyGMkYF ZhSVgXniZ0RCIn1GUMzbyIN7mvREH2kQ99PTwOhXigEEs6AIFUKTIArP0y/BEOC7mYuxP7rhFtRj 7vT4/dMVwcteDgivboG4QLpdvF0SAoKLFnIe8hE9cHRfHejGaRLfoh94i2rJfd7VdZljcmLFoe7f XhBeiU6v0fPIdCnKWyPKWyS4IYcsUfZXEaLLseekJM7NWRLfoG8wNEQ1RN/qanA35jwTsTnqaddO w66ove4Dia8EvaL/wBiugSAiGWmULjHcaItyGV3B5WQNuc24PPgZCO4DvUk5RuGDkyaSqxOvyZkF s8hMOt09K3FGzk1kaeKi1KU564R1YoOmQXur5VbrutB14Q8IG7T3WjZYHw5/yv1s4rM5bcIe7df6 bwxfB3+d+HV2ssaoS+wNhaRXtjhAC4aoREFNzDbVF5fENE5CjLElOtTrOpR8jkzMm1EXmyFPyaNK Xk1eU15HnpDnfB4bGJ6BFDwDQZk2xbbexmyRufvJ9wHFwt3zs6pS6Tx11u+hc4EntkJVyLM9GXHx lnBBG+ZyiE50xzWxk0lqKMaE6Va0iPECmsg47o57wjFEzLCk+UU9IOvcPnJlU8d3zR1QJzwKDLf5 Yx81THTlB2SdS36IGhgGrCVZ9Vj1m888+dc525oLh37c8uKccYtJ1o3KomnTGvKy8kdXrL1+zq3u gXTb7U3jbj/YOm/oxtkrh0+rW/fG4knzJ7S8P2fZiJk3LBqROyPD+1XZ5ppbHl4yflDhLNRBI/Ek bEGZsGE0b1Bybkr8SPwg/qNEYYawWFymXaK7wXCjcXHIDfJq7W0hQTrtumTaRysmRjgSI0QW5xJA I+7HwD+CKLsSK9CyoWZSdBmuuS70nCGOb0+wiDpqzS6bDYwRXANFEdNesJqtspVZ28h1qI2SleSG ZKYk1yQ3JXckC8mE6zAHdlOCDgbRoMikS/yZTr9D0+3X+sUB5WQ+i1ul6n3VtfSH8NEJWovBbXbF uJ1uu9ExGWJNPGzSYk7Wx2HsZMEkXue6WCXxjVJtgi0vP99a4Nf8BQFnhqJ2InyD/DukqqY5t3a8 nfxo/bo3p9306tM33H3i1cdeoDnWfouHVd1RVTIx/eYYF11IEnZc98ne1tXPNG47/5l38S2z6L5b h0/69Mamje/cMC4V9dEQ36eiSZwNCYQq/XRxGSSDZrAM+wbTg3FPmJ6w7jHtteq1cSTchkbhprAb w9eyxvBH2Yao7ewA0xlYsEBjB7EqJmZozZaEaFQ94m4aTch+aGPle+SHxKQYRtroyd0WT7OZmNtY ye51xk1GamxjGUpGqI5ux1iaZJu377AQu6XYQi1RCpoXXZEcQUwR9ggagQacjo0Y7Jo6Rd0GT/U8 NZL9eV4dHpk6PCvd6F+e/bK487uzncTMT9EhdQ/ksGjJgCGVW+8Od0nRujQwhGGijRTTSJDNmMY5 Ty7m+zy0BiFOlcE0LNSqRqo2SXDK/HhYE/g+5GQX5BcIb9vtfb98bMXHyxZ1PnD764vt07xnDnh3 7GvcQ4r/fM+6FGt0aJRenO3NObJnlffdk23eH9fXbQndveW3/V1vkDEHBoWHRGdyG4yxp8j9oXCU OKZU6aP1sXeY7zO/ZxYXmReFrjA/EPJg2KHoQ7HvmrURFmtobBzThJEVUSvjaJJWskcD6l17tNHh tDki7UnBwUYamRQeDtqYohFW4hfzTKtiFa1tvhN7OA+tg508vOhbnIc+j+wktU7uVzGnwyaFhNCx NgMGvpjyrjZU6QazmY6V1EopildKG+MnBfbAg/Fut5riiZjn+VndFP+pQFgKC3nYi3sQExVnCjO7 Qt1xpphxJCoMk1iLfRyJDokc18N+bojryLzqupw8zl41NEbn3CEL1jAzuu+JyHWwmAEddWfOuITw mMRhOTSJZJKrXtz+onfhsfpxp0m2960zE+a7Chzz2Zx6OdXV6H3hHe8XL7w7OYaUERuJJANiuQea AiDsQo7nkHylWMmbHnNDzMOZz0RszzyQ2ZGnHRdZK9Vq6rX1ugapQbNOu06nS7BHxzriXfZoj8Op VThDtI7gYLsuWqvhrHTwGo2DUrsUrYkxR1PiDDaZYnNgsycd0sw8aKLvKI7UVA8K1ObY6NMxMbFa 3XatVtpezCMp0Jg1IzQM5/pSqVDnWpS+PdVjT8vAoXOitsvRSvTJaBY9uiKvFk0JywOzulVmdVfM 6laZ410J6lYlqJUJ6lYlbMzt2EdWqOadb5O6V3hmqjvPVp/qxu2q7izyP7r8Dp1+JF70abuLUKEV dRdxNWbu/A7MP3lIgAaeYlQTi4OfAHT31RDKwZ9o5KhPdApyMFTm+/f7BvKzhDmynaQsSMyVXK7g YOuosd73zUm9vpw/I7NvSdLC899mZnpkW1TCmEwhzJQYlpOddJ1Iu0870xd4k6bEOJO8JRMSbXJG 32Xe7S6bWZnC6m6JS3J5P5hdEca/vg05eJBu5N99gheVuQ51hxwK54BDScqLdEyyTM3X2qOpIz7C Hm11xEfao4nDqbNHWxxOq4VSoo2IpJyjkVrOvEiBD42M19VqG7QdWubTkkxthbZGyyZq27VHtUwr 8G5alcfaNt+vu/hYzHiVWFU4Jsm1jgZHh4NlOiocNQ7W7jjqoJOO46HBY6KeG091Xd28wOFRHxZ5 VOby1BXm+P0E+FkYxh+RhVlQ3aPuoTd2H8gc444wBtlTMzNpadZod6QxSPZkulyuLHkJmzPdEWmN UPNd96p5rmUGoX6/EfW7AaKhRcm637pF80zQM2bhBrJYs4Ks1Aj9tcYkYGFJki6iyM4yGAVmZvwx psJENjiWy3lUcZ4cq8TSWEuRWSfrqEln11Hd4JiASuaHf5i5zvOzXwv0PF3MJtH8KWKUO8QdbLCk YQAQkUZCNZgLFzFnDjKmkUiKiVUblgY2ARPPRcbQcwupriYyP/oOnhbkc61kUR8hWi3mRDftJFpy m3eJ91vvae9txw/+sudPq+68fufBc6v+hNp3rvdd7xveGRjsFpH+b7YMXrHF+7x3186VJIWUkGu2 reS8GeA7JYjinSg9abS8haq+rjtDlaJkKULVeapcBHQhyLHhQbw2XC+3+c4qFquVjpUNXAZktTfW /qqox1CO4CPkmP3sM4j1te/RYSnWbm1jnynmEEUXTMeGhILLpdOkpjLIQI4Vf+LpzECQDPXe2z/x vGxu5/nDKBzRAT98lBVHoQPBGB8aUxtLlNga3Ba7HqfRh6M+kMaGC2azxFcYyqmMAosp5S2ynJGe rPZRb04aK0kZ6XjWMzyHPSrByx72ePgGflJdfRj9G1th8Sd4/eh9kOFr3zlwYG4Gl4Z+nvTcmoyl wlKxUWjI2JHRnqFRMhoyKGSEp4R5xopjtWM8GzSaQRoiZxQEDQwaF/SA8HRKU4amPeOMh8oyyI79 vg7QY8xTWiSPkK+VpwXNkZfIm2CTvFWzT/Nqit6tDUk0lFjjQgaExSaGl8TExQ6w4zC9kBqmcs2e SlJT7UxvB73DgB75dMUaVhPeEL4jnNnD14fT8G+TKyRc686k9FxO92Jk1D+9f33Aeg3r7J7HP8jh Lx70zMNbttgKzeoTW/ATVYSj3B5Bm+hya5Nl8AiYJGlcMkkRU+Ue74Fbr174Uv1rgi6Ex1NVhTG0 6rxZ0Wfwu2yaRP/jXzzfNtGZZ0mn6snmLjZ9rX/DkA0dv/5l8QiTHBHlMRJLmskRHp2m955Jl4qm ZFSWXt085+rpZVedf+UVMnDYM48OijI7a89/8tjAGIuz7hD5cEBt4YgZf339A9SHV6FYm1Ciw8hd fnneBzbfz0osl85Qg/qNf54lqh4jksGAqaHN96OqyDDzzS5ehZnPdvF+mHl/F5dkzJzYzccYxD+j SGsRGghBadaHhCo6PnkYVmSgFGd3mjt7pBilCcX4ZfOrF8lwYoiVC2aoKp4hOAxAQ1SpJJRXEVVi +aLO7OJlzJzdxat4zV7ez2CwhQfklV8Ar6pKKe5G9N71tnbbGYyt+N4Xl+VyqvQu7JNLbK3GqfkV NqLYKmw1tloMwJqwo8aQHKcZEk+S46REZ2iisSQkLnQALkkjBQFJMBoC0xhUJZjXJ3e9gVQYSI2h 1rDe0GQ4YxANreGtT6hBNP9Eqajbr9MvPPlHi1lHuJyQeVVVRBUAVPLZqpEMiAW5KTJ3oLe4OD0q 2B4RlWQhFvHO8yXjesUmJEQVjWXKwwP5bnNbZwGQMtkOGM/eCegqW5XCVVCVavFsFnVrLWOHZvpZ Rsdm8g3l28drFBPf40yP2suTVVDW06uspxevURy8V1nJwBK1X4kqKCWqoJQMDeVXG9ozDjM/q1Iy tGcCzPymRPK+Q4P4NEM96nCPOtxTwD/11POKAjMfhuV3FT0fVxDDJ8byN4qddy2gartqmQss6hwW dQ4LatjT/jnkzIDGfck/h5yiauM238eKnneVaaC9C2WUa+jwyIzs0kFcA8sDx4xVeJ+MsWTE2Llj 68eyseOkgVkRrlS9pihV1Kg2LCMjg+tBz2Fzdzt/BWRaFbp/zgZEHVOUd49KX0XKLXuP5Bfh9Di7 XiNqxowdp4nIGmhRJd4iqypb9khczD1qnaegRC2VqKWSoXgf3+z1K/HKAu548Go1w3th5ke1taCg Evfge7VyaM8JwsyvauvQoVWVgYNjuZCaceUq8BZAvefDxcX8mSZKb7OxfEzlQSjznYZSRAYi03d6 d1REZERERC//qypaicnVHK36IZw1oIhX1Rir81GHra8islZOjotoo1274guS47Iwo+jjhybHDRwS b0mOs7Wx4F1OT3JcZhsz7nKWJMeVYUbp6xybOKxkTNzYAdrkgmFKYXKSFjSugePG841xpRqC9BpJ EDUDy7IyI2xBVTZbFIadjkyZ1MrN/MMLkqeYCpLTPQm9MgtIbUFzAS3gdeHDxpckDB1qH1YxjDYM Wz+MwjDzMDoMz/We0PDcYTWVVW10wk7HU/URbWTqco9nOMaZ3E9Dp9h8FjPdp/ykaHjpdQO+xEPO X8Xqv2H8+W9RT/zf86mf361DExIaj4650eV0JxgcMSTYFB/sikGVYC7yx53zoNqDtgO1A/8Qnj/m 9afhqtenqgs16Ay41fGSRmP7XY9cqNZImku1S2KP1SEVU61pM3LGLQ2bfmf54DpHuDEo/ypvUUgf hy1IiE4clzd7KKVhvcu8WUML9aIjdUR+3ui0yKxyb5/i7CidJi4qJtFEQj30u6kmd8rUiTeWl4/t vdS7aJwcbk9IsJmdlgrSWJuu5A3Se7zl16ZjZUKCZRTWZSmxqQXesAn50QkJ0X3GkmvvT3VEmhJq 0e8q9Z1i+1CTmSCWGgK6LAbNk2ppVP/JoMY2BrNej2mUwFUOb+QZJYRXCmo3webS6s0u8J9Y9YQe Vg8k91p6Hl7ydt4vig+O5gchSghVLU6owaxaFrNqVgRVP/GsIMQZDPY4flbUI8KPN56RgGsbrZRa G8LI0+F7wl8hh3Qvx36kk6xfBZFButLw8WHLyRrdKtNH0Rq7kp0n2PvjcdhkJ6+GHYqiip0M1vas xipwo+Kx6otHCEQRyFGeVgg1Qq2wXmgWJOE7g4KNimGTgRr6x/UvV32Xeei7VHNbU96cNLq8uWLk hBZD3OAWuzB41ITKP4PB1w4Cwu5r50ezf+XzEMWyQYBQlv21+evoi4ootVW/++r5JNbqCnZTV4w7 yCW5LaZQGWJJlEzCdZiL0GAuxGiWSTTDJExvkyFSxOQSf5177PMIt4N1aPf6VyqWhXShtCRoSfAS 643hCyMWxmirqwIfeehizJbCaEQYMr1FX8hnqsJDkO3/2CPwSBI9fv4c0hp4Dknh6M2zFx2pP7Jk +rI3R+fN7rfp1kk3zxzIdmxcseOmrobNq5+9+dwNJcUbl/7Ve6LpL2fX1HCrSVHWutm94KKZAUkL T1StpjbgCunlpIDl6ApYlriA5TilhKiWJUrtGGVVrZTVr3TVzG+q+cPM2d28ozWBu/s2tDDBES5J LwdHSLGpwXoNBojtu3kEoA0C9PHRsy62Fhaikv3Ob1MO+40I9/kvcpTGaxSMPGsx6AzSy/qI4ASX DWf1T6knWtVXCvL7Sqr3JEepnlOUakyiglQ5t2q1blmrhgCS33q4rdzb412s3HzzJp5R7YPVmui+ 2D5gwi2Dah487VxYis2HzYf5U060jPyIKXkkkSt8ObEmsTaxOVHI1RfYe8uD7INkMUobMiIuItHp GBHnSnRqE0mJJk47QNa7YrVtpFQJCUJPPjJSvZ/gIH2QXu9QHflgaCbERGrJJnKECKSN/llxWSOj EqzWipD1IbQBk+YQ5v8cqTmkPeRoiBRS437J79pf0Nn8iwDo36tfyFAfSqkfafKVX/DNUOrN0TEm S4wpKgbMlmhzbAyoeln9ZKja0+Ow+T121aN3q26bJo8/9+BPPbCUmMemoLduTwz2fp+2aGnpsLrU mIJBpKSq2HN9eeEEdm/3e5tUP/2lhn5VaxrIgyXZ0cTV/XBDRf5QqhleQF3AUB9+Kh7FGN2EkWgJ yVBci6yLbPUZ9dlL8sSB2VVJY1Ores1MmpY2s9fCsNrM2qzlGfoRWrSb/RVD1sSsuVn1WSyrMKdv GxunhMrxDkdOiZzrmgGF5kK5MLNQKGxjYzCoLQOWXmbKsedk5BTnCDlqZUSZVpf5QFa+nB//ADiI o42kKdGCp8WUb8/PyC/OF/K/NMSUNaFCahfOCILQxpyKMbSswlCDWqmhn/+LWdWd3dWd5rN++D++ wIyanFWfKZn51+KqM06pTO9N7H5VE+cOV5VNlAvVzQKwk5gFxKbDXKQGc6huFpBYhkmYPmIBRIuY XKZuUOGoD6WyBWtYKBWc8QmUP6i1xQv8+a2Qk51gzculCbbAQ11N4DONAhvuJeTlQs+HqgUsaCcZ c/B573Ntbd4dzx8kY1qf8L7+3DaSu2ULydv2nPf1A6GJCY/+aVRDclzSnvv+stC1+uxfvedIxMfp Vw2PNJjD9eLsvd5t+9q8zx04QEa17SNj9161xXvomS3eN7dvx1meIQVb2r2nb1g4oNBz54h3Dz0e 8gZh+9qJyRCltcT4f+aDAURvPbd7oqnoJ22kVv2jjcc/j32J033v7U46v6B7jRm0wVjUYX//D4Pw n8VweEthvBnOL/C6zb//YEjgJTVKhfz7of4fD1GxFU6xAbBcAHAh5khbYZBUCOWkDkZi2xhEOtbf JdyGGhPgT1gejfQuWggM64cgziBSEaMRMmIyohIxFLEUMRL7NiPu5HP0gK2FazTXwiTxNTCL4yAe MQTzTuFzSBHmgwPzg3gZr5fDYiEF8/HYlqyJxb6v+b7g7dgvXu03DsfNhwZs74tlPcKqWYsi8hqY ECFYH4XzbOFrRlrOXuT36vsB84twHYMxfx5pGa51ANKhWD8C81chjDimiBb6pmDegvmrkDcWzBsQ pTjuHB+D/Y24xqnYHoplyvvidY1Io3lfnDOZfUCiyUPwGPsAWoQxEIrtwSrwvvk999wTXz9f079B GV/fxfCvTwVfK/19bf8EehmuYznqXt0SuNdH6GGoZU2+HzHvlEKhlEPzAcTh/X2HKBSm4lGM9Z3G NQ4Wd0EelrWICBV8zkfgDnYWFGzzSBtQbqZCX5qFDXm+3+hNECu5YCDeL/IbEnHtVVz2UBYSsN9o dfxUiBO+gCjMKxwo9V9e4BPyBve+HGl/5Pv3WvB14hz9OXCefYgXcbwNr5/BecD3nYzzbsO+X2Pb DYj5KCORCBu2r1ZlGMfw8XidEn4N/z6AWZVBBJc9RHYPAvvTA30PVP5vVRGOsCEKEPy6GxAHEMMR 9/I+OG849o/DddzMZYbLJpcPLhuq/KM8qTLL93E+8obLmP/MbKbTYCUiFJEqAdwRQAr2Vc8L30e+ Zn4W+NxctrjM9FBsd/vlnvzA75PL1EXUKaaq11bPIJeti2gyl31OmaLeQzJth3wus35e91B1DaX8 PPIz0UN71sPPp3pGkLLZEMJ5x/e9h/bw4gJtAhe2DRU/goFCFoxnr6D8X4P5CqQFyJ+N6hn8QbgP TtHlQDXtkIp7yc/ug5fRBzg075FZOF878tItHIYHVfoejRfeI6K4zfe1uI3e7EdP/mJ6OUi7v41T jovb/tv6/xvQ98VtMA3z34jv+XzCe3A3txKab0kmQu6hWN+KaECkaD3kAe1s0qYZC2aUm7OIuYIC vUUFCgT054Qw9dy5sH4szp0hzIY+OI6RdljFxsLj0jbIZe/hPuK16PtwGwefH2ntBTm6XOb+WZZU 2iOv/4LyM2DsoeqZKvSdUM9Voe+keiYLfV4/hUJuG7h+Vu0DqLrZ0iOvF+TyUXCzny6Sz8vk9CL5 7IPjzJfL5UU0mNOAbTH2nFMcE85tDb9/VT+OU8+TquewrbWn/+X0wvit0Ea3+o6pevgwTOg514gs hAvb/xLQI6iHcb+5zVzru0a6wXcNG+K7Bu9zj7QC6Y++nTTR13LBprogO6DLonpsKeeTeBhiLthR F4wI6DMXt6fCFrThfjsaotrPryBC/FHVbdnqevk55GcwA/VeItrxn32/CVb4E1uFLgueS16PMjKS twlaCGOfos4dAgvYRt877C5VB5UyL1QxD55hHIs8ixApxIgDoBzHgDof74OU1/H1SwLKJ9cFg7CM e9Wjl/neS7+BEZEofo/6aBz22areq0vV4w9AAueDOnYh2hWcS+MBq0DBE+jjUsdcj/6Cyg/UgRfx ImCb+/I5pVGqzJrUMTm+37RWKOQQn4J8vL5LvdYg6K0tBLc4zve96ldYYTh7DTLZILBjPkqV+xVo o5LRXg5C+4hgnyO8KJtmf1m11Sr1nVPtfb1qzw1iBoxX/QneJkGclAzpHIIT22ogjT2F88xFufoN 88/5fKp/8AlY+LWxvizgn3A/garn5W0cdwjS+Bnja1DtDV/PQyhvR8DObaLmceRhED+DhCC/YwJ2 0IplinTdRVgfqIvxU+KgH8E4tW0MdNAX6A76gm829wPZxzCRPYn7twMcbALa71fQNvZBGz4EeXUU KtlbmI/H+o2IRej7LQCTYIKpGEgPp9nYVovjDuMcj2M7xx045jjS5+Aq9jrMZO3oH3zGfQRwCAuR ViMGQH+yHWbTczBbykeb3Mf3qDo/xwLf1SoeR7v5WWBsAOpae/Cv1rwYfbt/sV51rRevk6/xX6yP z8HnVcdhH0HAiA98xxEuP/WOpGthG6KJfox9h8FissW3nzwCZeQLxCMBPAuDVNqCGIlnLI8sRaQL ebAXcQvmU5G+gNjhL8NDiGOI5Tj3i0h3SuoPJBCg/VCekWLdRsQDiDd62i4Gv9a/qr8YYrRv/yXl 3WhrEOQs3sPZS9vUa94C+Xi9fOEq334O9jXaEIRUD6GaRRDKErE+DsddVhajUc/thoQ/Ws8fgRyB TJWHfij/yT3+p+Bnl9vn/635/lPg/tYjqtU1fI/6WJUhCCbv+44jHUfeR7u9EHUpAstpWA7p4WfP PmH9PWr9ZfuHsoJhqu+Xy+svL1++r39Upjth4sXokYML8nA39OUQirE/4vKy9hD05ZBewbZX/rks PP0HmIA+ykN8TSiDif9clkZAIgdNwLVG8TF45hAXykdQryJ4X3W8Ee0lQj27CLoLbTHiQnse6nzE RXzN53xlD/nbe/anZ18u3x9cnyK8hZiA/uxbkIl0NNKSHnpBvgP64hKZH+mX9wtlrku+uKzP72fi 97OBZ+Xfzfn/EvDsvI54DfHq/9/XIoCyijAjVB+1D8bgeeh7juOParrfBOgKRRqCdgFPXlcH5t/F /GT+K5WY34t1DyBdiRRVTZcX631oRxjSjUIU+u8AKxE4h7fWP7b7Z8QN/jm6DwCc/zCABf7xXWsQ ZdiGnlnXLsQWxHOIATimZ567sFyH9C9YHuifqwvz3Z8iViDKEff7aVcjgrfr8BofcH/kX8Sh/6v0 38Uf/ykNxBlFPfSfYoj/hvb5j+glMUfP/v8R7Ykl/gVV+RBYv3TRev5djHMJRfnRXQz0pZ3cp+R+ NPdluf/M/ccLlMdtg1QaEpinh5q4DeS+M/dfxRz1eSOPgTwXxYOlPXbjYt1KzsJGhBkRHaCzsc85 jHXeQttkQp36E97fkxyqbeN2DYHrPaK2v+87yPsgPYzlWKQ/9di0Ht36Tzr2D2za/3b5v7WR/xc2 NTuAiZfh39X3oFcAgzkut8X/Lf7Idv9f2/J/Y6MvttP/X8s9dr4Hf+SX/pMf8AflP5rvvy1f7nf8 1+XL/JKe8uX4p/bLZa/Hn4nCGLgHl527/xY8thB2/+7796zh8nN84bz1xAj1aFMvAuqBJLRZyYjH UV9kImIRVsTdWHeztguytc9CNpZ3I/ZgXSfSqbwN6Sb+6xL0Z183lm/Fslk4rPatDGDqH8nz5XLL /XPVP0SeqXpwPV8/ZCD6IKyIFsT1PXvNY0+89lf0eQAe5woTfD8JbyEu8wH/kOZBHeJZLJuwbAp8 YLTo34M+98dg6IewGsTfAERU7/y30zRtALoNAEHoSxhy0QRgv+AnAcxYb+37nyEE+4alAIR3XYqI uH+NyN7/+4gx/M+IxXuNb/XDFfevkfjS/ztIfvkKruAKruAKruAKruAKruAKruAKruAKruAKruAK ruAKruAK/h8C4X9ZBD9CESwCDVAwQwb/9F183RQCDOh+GONrZ5/uLC3NVtqQetJV2pqUnL2PN7RG xWT/mX1Kt0Mi/0tVdrI1PFptOdHar18gk9/Ln9mZkpZ9siSInYAfEJSdYCchyT9qZ1J69pkSI1YQ djOYCAE7NLFPoBlBQWEf70xwZ286yN7E9tfZIZiqDjvUarRk44Svsb1gBTvbw3YHWnbvDLZkQ8l8 thZvsB3To4gOxBmEAHPZ01CPWIfYgRDAhKkdkYEYwWvYNrYN17kZx5swzUDMRaxDCDCGbcX62Txl W9gsiMexa9i9EIZ0NbtHpU8ijUL6ONbHIX0My5xuCpQfRsrbHwrUP4jlcKQPBOj9WB+NdIP638DZ 2X2B8iK2UB23IECb2PzWOLu5JA7bZUQmgmHuXszdi6y7l/85GqaE3cbmqFdqQZqN9Ho/RXYta3U4 1T1attMWmd2ELF2GrF+GnFuGnFvG/w6ZLe3ps9TfJ40txT5Lsc9S7LMUuZLJ5uP15vMvnmBqRsgI hnyfj3yfr/4s/HzsPx/78/rbMV2PaOIldgPyMRlXtYrNak2yo5BN31moZBcfYNOQ1QqbtjMyNnvd 7yVdEBdEpMEBauJ9r1Nbr9upM/Da63ZGxfop9ppdEsymwE0ICqGYJiByEQMQApvSmpBh38+Gw/Va UILt9bSe1Qv1opA5gFgPsmyo0AKKpJWlQRF2SLZPLCIFNbpaXYOO8Z9RytQpugqdOJfVs3WM8Z9e KmYj2EQmtvnaWzW9c/jfhw+Ueues1zfpm/Xt+qN6sVlql45KHdIZSZSlTEmRKqQaqVZqkNZLTZJu vbReQ2v0tfoGPTPrZX2mXtFX6EW7hjSVLGeT+bHF1IyoRaxHCMjjiVgvs2sRE3E3JiIrruXfXsUU sGRGHMV8B1IRSybsZ8J+Jqw1Ya0J+P88YVJbKhA1iNpAq3ShpWcM73+GtyD4l/+DsTYYeduB6Rme QwzBkhFLRiwZsddR2oUrNGMqIyoQTK3rQKDUYNrTlhlor0FIavsZtU9Pm8LH0i5lUmJ7MmlOJk3J ZH0yUYqKS7KVeEysVutE50TXxKSJm4W5zrmuuUlzNwsjnCNcI5JGbBaKncWu4qTizUKGM8OVkZSx WbA77S57kn2zsG7ojqEHhx4ZKkwcOndo/VBWwH83ptWTma3SeBenu1sjo7ILTCV96A68nYmYbkKc RDCwY5qBKEbMRQh0B6Z2+izWPou1z8IIxESEiCOe5eoFU3ugjddvUtt4jrfTS9oZ3vj21t45I0qG oMqdiNiEYDj3dmzfrvb253ao9c2Ydqj1IwL9m9R6O6Y9YxgquAmqmpuAx28CFCMmImoRIhxh4+Ek AmfG1I6oRexACGwCvsez8fRZfG+n21mqYswKs0N4OABYLVpziZkaUAaMZIuaPqCmq9S0WE0TlOAh xp+HGF8YYrxjiDERMzQJSrDhXjV1KPoS464S44gSY3KJEWezgQOMNExNJZ6Sb9V0uJqmKqEO4zmH 8R8O498dxkcdxjqH8SoHHxeDZ9dIQ9VUz1OyQU2HqKlb0duNr9qN4+3GAruxxEg2Erw69FPTODWN 5in5cZdpgAl0B8iPMABnIq1FyfY2CiohvtaiEiTe1qKBSLpbizYi+a216B778+QcUU0a+bk14ZS9 JIycJYMFXv5HgP6dDIZtSM8gnY70KSgiLqRPthbdwvs/geMfwvLjEK/l/R+DCnXcJjJYrX80MO6R 1tTJeNWHW1MX41UfglT1qve3pp7C2ntaU1chubs1dQ6Sda0uvsBZrUUp9hILmQ4JlPedAi7KVzI0 cMVBOPMcpAP9g0tbU/moAfwCbaR/qzMLSSJf5fPECRXq5eytTvUmY8GpThEDTnXR0eBSaTAxqYs3 QrxKta3OW3AWaZfrlP2XogP8xuEnYmrdaP/8eby/cVj8jAxu3WZ/ex9nV6v9SGobce2xv+U8YH8l oY2Ma7W3p7ZpseFgahslu+0tyORm7EvJHvuO1On2Z51q62YntuJWbypKsz/snGB/0IXlVvstqc/z ZcD1eMfjsLkqta99aNE2e5mrjWCzUoQXU4LsvZ3z7IVY3auNDN65zZ6V0MaXkolzbNtjT8Erup3q UsYW7Kd5oCELlVTNAs1kzTjNSE0fTY4mTSNrYjUxmlCtVWvWBmsN2iCtVitpBS3VgjZU/dVo/jff oZL6p9+SwFNBzZup+uMX/j8Sp0RL8ew0h7ByWj66H2m2lkP5mH7NBZ7yNo1vVHMvT3mztuLqyhZC 7qzCUjNd2UZgTCUKKK9aHs3/k7N9QEjG8rXRnC5dvraqipQ3t0+B8sly88+j8T6CRk5oFp39IiB8 UXFEsbWvpbBswL9IagLpRX/FH3Hxn/R7ImKbN5SPrmzeGlvVnM0zvtiq8uaB/L9H20fr6NzSAfto LSdVlfvIElpXOorXkyUDqi50g3hai92giBPebSfE824QT3aq3Yaq3VBM40sHtMTH+zu9RAbzTig+ L6mdpvvnSsBL4FwVnGA3GgcJ6lwJNI53Q3nwT2a6eDIDEJM6mckA6mQxvFOLy4VdUl28S0uBCzu0 uArU5m2/Nztd/uVUgUu9jotUqdch5Pc+Sf4+KAWBPlSLfTz/m6/r+v0XncnOScenTuH/SV2Ns/Q6 RE3z6v/T1vW7tg2E0ZMVl5D0h5tCEXixT9DlMBSHQCFHq59dBKXUHaQSqBXFJZlSOF3HuNCpU4b+ AR4KplukGErxkqFblwzdSrZuXTp069T3SSYl4EPve+h70j0h3UmavnuzbxVvdzudcu9isXrdveFu tk+cjooLexQUe3bQKdNsiZyRnNpBybLweVxmzig4TZ00tNMgmU3HfnTF6/2llz9e0tmYOvPJaxot kSOSp+QVkVdEXlNnWnlFzzwjehqXq8xL/J2aZ431NcyHYbubeHdbrx9Wk2O7ax215ysMn611kRTX ba+4AZDUc3suSZidJN2kZQgXknW03W3PjU8LqYX0bdtjglnhQXC5KaVygtYCMddWlcsxabuDqHhM i6bJQoaFMwySqjyGXjQ/dlpn8lw2DuVYHsuJPJFNrROkN874OW+85Id8zI/5hJ/wayTsxJ8dOeG/ uakxmowcLQwqTw3GRru5VtQYDBRQ2wkt/NjlLDNpaRMT8Q5gA5vAAGiyr4jfgZ/AH2CFvUP8AHwE ZpQxe2YvtA4CckwEvXQssz+7v9V/8AWcvqp58KLm8EnN0u1b4NNHm2vuLfx4G2yO+A34AfwC/gJN s2/2q851PWoTxZQwcPlUWKSqLqJEbgiq7Ei3O1dCMAINcDyBqo7f1XHPDKUZbgUeCAgHVVlFp2ni /wf+A3dO2VsNZW5kc3RyZWFtDWVuZG9iag05MCAwIG9iag08PCAvSGVpZ2h0IDExNyAvQml0c1Bl ckNvbXBvbmVudCA4IC9TdWJ0eXBlIC9JbWFnZSAvTGVuZ3RoIDQ2IC9XaWR0aCAxNzMgL1R5cGUg L1hPYmplY3QgL0ZpbHRlciAvRmxhdGVEZWNvZGUgL0NvbG9yU3BhY2UgNSAwIFINPj4Nc3RyZWFt Cmje7MExAQAAAMKg9U9tDB+gAAAAAAAAAAAAAAAAAAAAAAAAAOBgAgwATxEAAQoNZW5kc3RyZWFt DWVuZG9iag05MSAwIG9iag08PCAvU3VidHlwZSAvVHlwZTFDIC9GaWx0ZXIgL0ZsYXRlRGVjb2Rl IC9MZW5ndGggMTI1DT4+DXN0cmVhbQpo3mJkYGFkYGRkFHHy8/F09dR2LMpMzNF1ys9J8Q0BiUv+ kOYR/SHDI/aX4w+PDPuFX22sTwX7vvMLMTAxMvJJ6bsFh1QWpCoYKKSkpqHoZQApkJT52fSTVewn 65+Ov6zss398Ff2R8efpnww2vu+r+Lq72QACDABqxSi8Cg1lbmRzdHJlYW0NZW5kb2JqDTkyIDAg b2JqDTw8IC9GaWx0ZXIgL0ZsYXRlRGVjb2RlIC9MZW5ndGggMTUzMw0+Pg1zdHJlYW0KSImMF9lu 20bw3V+xj1zAIrgnycfWKFAUDRqgSl/iPDASTRKhZEEmbShf37mWkmLngADuzs6xM7Nzaf3XzR/r m9/XN0VeFJVX6w3uQlGq9cuNyY13av33jYGzShXw411weV3Z0gJY59552K13Nx+zO13lPnuvTYTl g/YFLOqoVybkMWu1dQA/MfZROwvLzIdA4wqg2TAIpB6WW9XwZi8itoxWBNbZxNj++gKFpybbNQzu G1Kqa7UzsO5a7csLkSJDPbA+olbSWe1E6O4bxEkHtEI1Yo564VXIxxExbL/+pNaLl9nBtvSLf833 HFzbStVlXhtrS3Zv32gTUAXrs60CZ/hs0KsKXFplX3JtbKZ+0wwqIkVXCH2LMGLmEVkmUDe7BWOA Z4MoOn1E+nmLJ5GBHR4f5gmXAU/3nfpojLYx+8R37LfqT/ANa9IhT39tMtjjKjL3O0ZWMXcVxBMb +R50bM92PoBDWRWGSSG+mGBSvkXN1N2Fxng6awyRRXE86sgrH429JW8ZZHB6VUC8fMKXM5m6z8gc VOPuXqvufDXdup2bxV30OWkP7p5YLfh8gUCrITgVubgX57s6+9Yr4BaMBpNHeuC3/UNZVvq8iiU6 ER3UHA4YWU5iseSYddnhiCHosoEC32VTy6t6ZvyAkX7mmjTKmBnXjIL9mpiHR4xwJ3lScihNLVNt mKgnEUBRnrUYZe2E78RicohM0m4knonl9NcWzITr2DoWfnaaYc+oFSR3bZ3HTVH4UKnNDj0Kj1iY UEoFqyty6SqYvCjfTDFnQGsf0c9Vncfoisj+fYZ6gd5agY0lVaaa3MXwTNhGoDGRfU0nUzp5JMK9 QArCqRkT1xXJCzvmid2opl5ubNUTY3ohb3TJ70foIYnumEqxtAf6XkqZrxTZyoopdhENSaVTihUG 9yKlY6kHWpJooRXFE8sG06k8e2hxwHX0W+k1AbPgB63m4pnKCohMlDqxw/Rq8LPREZQaIGyyvWQa 5ixtnzCXHzFFZwTJXGAA0jMaar/1THRUW5LzgAB80E8AHum7p4xW/yHPO/w8QWxnXEl2SNCgyP1J lzZlPwtF8XJ86QWKWF+zH4wP9Y97woUnYsyjqY20BUj8FdYKMKGGCvaZvuh3C2ftTjbwTDEX3+Cz Vohst0qbgoLbLgIUS4AIQUD4Hq+kPgsFvm2NMWU8yr7PZCdMs4AbjRW2T2TNohKYBFfcCeI9c32Q 4/laWNMJ3N6qZBTruFvUd1jCj2Ldia15VXaj1IjLLvwTh4cAJaUsnYQeFcnIo0WU0SLKaBGlZHou chAgnMeRpxqZcSIVu5gdGTVMVCeRuGX0pIszbQ4WgcB7TfcJxBU18ov2cidV0piuVoNcLQvfKeoq oU3qcp+I3CeiVIbFCmh7xDUOX1mnRhBDEoMlbqChJ77hdPa5c292ugtPe5eHMtpaJh5QIpJRUCYh w9REezVQpz/g/ngmQQNoAuP6Z9BUSGGIr4qGUhpJIa4mmldGmp/QGrCF2h3bQBcNk0wyVTYl/yZx 3TfXMsOeDgj32vogxS4N1t+3H3xZBI8MaD+/TeA2HbLdZ14pRnBCquDL7xigXMEDBRznCCmnR5Gw jNSoLcA98Q5CzJBCwMojniU1uiAVkIQCaVFgy2yiFYQwzcxTv9wJ+QD4Se4UlVYUxaPIeOalJVHj 6wIZpFG4WKROYeqfpKuFDlQGJ+k6cBfzVKcCDekrnMwP1+BrKk5yOZ4UNTpPxSxKEwSqLQ7UwZ0Z joKhsoV/EVKCJcGpOQOHOrTkjMSzabmNeppCIOC2/F/HZF1DVY21pn8sn5mClZ+E7YV1bNuk9hsd x0n9K8wvtF4XVYA/eTbAiM7uJO1xDpDWgsPdq4gvU1uz2MzeiHgLM3LpjFW+xlusl4j/R9Nfuxlm HWzX+IWEK7m6G2wDo6amo/jvD+33TDcx1BMEUcxz+IHAhqd8BiAw41n8QgnFJeDl8NeKqUjcE2s0 sICOtZAbG9HlX6Y5Mf8O/zViQ5r4BsqyTL1LppGEUbQdVuA79b8AAwBGFF3NDWVuZHN0cmVhbQ1l bmRvYmoNOTMgMCBvYmoNPDwgL1N1YnR5cGUgL1R5cGUxQyAvRmlsdGVyIC9GbGF0ZURlY29kZSAv TGVuZ3RoIDExMzI4DT4+DXN0cmVhbQpo3qx5CZQc1ZVlSSgzgsVpA05cFSFHCIMMtpFZtCAwBiEa cINsCYSEQAKtVaVS7bnvGfuSyiW23PfMWlVV2gUCCWFkwIAFmDY0bnuGPuOl3WaaYbp9piPlKNzz IyVsc7pn6578p6KiKiPiv//fe/fd+2JBx6KFHQsWLLh67ffW/eW673zjvp2Duxx9O7+707XX/Pf1 rXuvsLfWXnHN4t9/e/E/71x8+YrFVyyz6O9+vnX5F1o3X6ktXr30qo4bFyywXv4FO4Jdd+Oy21Z9 a839D61/7Imnd+8ddHiCUVqIS+lCdWz64LGTr/y4d/nK5ct7b1296jbzcAc43HZH7/JVt93ee8cq 8P8Vq28zD6vNwwpwuOOO3pUrzEvBBbeuXgH+v7p9+8qV5p+3mH+ah/YlK8xLVt1qfrvKPFthnt3e u3L1rb3Ll9+xunflqlt6V94Bvlq1alXvypXgybev6l2+4tb2A8w7lpt3rDAPy82nrGjPYZ4tX33z Axsf8490L1m9ZE93z59vUccCMDouXdBxxYKOKxd2fHlhx1c6Oq5f2HHjwo5lizqWL+pY09Gx9tKO 73Z0rL+k4zFrx7aFHf6OBfzSBVcuAdv2jQW3LLxr4b0d9y18cOG6RY8u2t6x89KBjqFLnNbgQraj 42ngmY6fd3yw4CsLuhcQC04tfGjhyUt2XBK8RLnk4KLli16zxKx/AVmhv4e3wv/l0h9clrn87stb V/zz596xbf78TZ9//vM//EL9yuGrPnf1gqtLX9xkf+2a179085ekL/2ua2FXChHQvsUPLz715dCX 57EU/sSSa5a8sOS1a0eula794CsPX3fpdcp1les/d/3q61+5/m+XXrN0z9KPvtp7w903/OBG9Wv3 ff3qr//6G1tu2nXTu8vcy3627DffVG+++uZNN398y4ZbPLcuuu3y5Xct/6cVZ1euW/nG2/p/1il7 EtL2q3EZiytJOSmnlJSiKLKiaulMIZ/NpbNaRs3IaTmdSifScDIdz2SRvJjlMhifpdOkSqoRJSjB qaA36Ubdbp524y7GQ/lIeN3zUDKd1FJqSpUUGXwUcAonFS2eQasFNpzBMxHJ50SiMVKgMJHkaZ7i adYcDEMzdDRCEeA3xdE8KzACE2PhGLufZRACIjfZ73rnZ5Cx2cDtrXdb8Py70Pyd5xfYP/lma+D8 NyHbvNVm3Kd7W2X74Xd/cPr9sciRzpscax/bshrestpxg3EZYlw2dsOZ1diZ1e9u+tCRPdK5Zmzj 6Z734N73fL/VrYi+sPJ3h97FzGds2GvvuXfjk2sc2e7OD8fefenMB/CZD8Y+1i9D9MscH2/5ANvy wdqzN41Fujvfd7z85KG18KG1lVuMhYhh9S3rvRez6beeX6XL9nNGRT/4gHHQqDykV4y5H+tzwEj7 Od1iTzrjTgfiFL1CEBOCbJiJ0NFoOBgcH+ycbjSrpUqpkq2oZVitpGoNpC40+Dpm6209+J/sh1+t /EKHEH2R/4O9Z7GzfZsn7kMHhpjICD4Sdnl8w76hUC+5HSZ2cI+vR4xFpdsPbsQem3tx+B30J2en Xz2MG83W1fbUIWVaG9PGspVCHs4Vy0oDHauR3hJe9uT2pZ+C09uk9WuQr5FrfU9h23xDrt3oroGx 0z7c+wL5N/8DOZk4njoEzNF/0zpu/0H8mcQBbMRq+IzFte6pSqNQzXRlKgUpjWqKwKZwiU2QEWR+ CeQWAzyJCSRL0xzFEnxQCAmjYm8M7tU/OQQ5PIl4CA8lIkkySaboFCezsqCKaVjQYoUyAmZb/jf2 qdMnX379zcNHxycKpUIpV8oVs8V0QckrBTmfzMOpQrxYQs6EjgxMYOMDT+XWo8ODPL0X76N7wnv8 8LJXobdrx2dfQ5tVjijhRTIbUnyw6kt5HEhIDPEhjA+xAQqMsNfvCrqHB3p2bn+yb6er17nXtze8 F3a1vgqp+nWWXVY2yBMCA2KXZXmWowVShEUqEguiNn35+dV++3vQ/IQeaIEfCwjSj4265QHoQlTo 9h/Nf/Qw1PrI2G4/N//RQ1D7Dj1l/zG4Tq9b1kKtCSMwD34s90K22dbvr2lCoRQhUSqt0Gk2z+aY CjNu3Nk63vltq7F9/nCkLzIa8XeFfUHSL8BOfU8T8iZDMqnBpMblqwjI3WQOS2TlstosnerUfdby ulQwFU5GuhKRRJRAoiLFMxjPgHWABUWBX2AndE/rfftvjLctxg6rbaT1rfO32ZOO4fgQumFLeGgH vmO4f5f7cdi9mfjeA4hxSe32ZzZiG0+8PvwBeuRQIjWDz6QOyAc0WMefhMh+whkNEIFwNMDAdMDN j6B7h7INB+5s+OeiJ+HISfalHyFvqGcLz2KFk9W58Tpcn5jOzKKNisAU8SKdj2aD2UDapQzDp3XU 2q8NyY4kbPuJHo3bzz6TlGbxWXlKG8tNF8ertbHmZPlQ7jicPaGcPou8xDwfOYqFj3pnR8ZHJvZV 9+Tg/O4nlO+iRp/TWuAygszLgsSluCSbpBMkHCfjARcyfyfkjgViJCYSIs1zwL88yzMCyYd4sDH6 184vtMcrtXgDPXWc9B3E57wTA5WdcGVHetNfIvvEQX4Y44cZB+2mXFFvOBD2hyJ+0k/6GDcH8x6H MII6fPF4BLeFXj1/i90J/ZkdbJK7YAcRD7btcMb8YhTYAfKFYdgw6+VgZ2sLlNbvsTxpZd1cgCf4 KEdwBEuyFAMuoThSgAXSjETjG/rB31kLWZFTcJVXGImUSSmU8sHP6eufsnJeLsiBqwHm8jBPR8Uw ep2u6d+05tIxMY1roirInMLJjExLNLg1KkWlsBSET+k3Wm21VkNfY6/Gi/EMFgcFImlivCxLsqSl Mim4aTzhhMp8jlUZhZGJZARORhKeIWQI2kuO+gNY0DdM7UF7B80ocIAoiJyEoyeZs2+AKHgpb0ZB bXaiATfGD2QOoeM1gQGpyhQuRoE2BExArH3agDychFPDQ/FB9JEnwsM78J3D+3a7NsPux6NmTC6q 3X5iI/bocTMmp8eTcgNvKHWtnjvY3XkkbbH9Q+ut1gn7RKKSyGLJjKQpoFblpLIEbN/phKpsllNY mZPoJAknibhvCDHWGE19DdTYX0xksEQmqaakpCyBuikn06mCueZd/++u1He1czvFpFgwBBkMNZaG xfT+Yh3Rd+rAGGgk5hOimEBwNMMyXIT1gyDUdzahSJICUWtOI6TMIYK7Ywq4O6bF8hXEBkrPHrDE Rtw0ON42OAUMloHBmVT+P2gwC0zmUuatognRsXQMGGzb3J6xub9kblEazCinJDBj8j+yRa2HQbRv AdHODHEuLsyHuChHgkFzLPhwJkWgBUqEY2Q0FkaNq6023X1eAIll3GE1NsyPGGtaIxZj7WfSnU1x if/zUh8wl0qChf4bS9UfhM7Gvh97EYt9XzwoVmHNqj84H7W8bNU3tXwW1Sr6Yn3iFjj2ROyJJxFj PTT6qRMphmPYi07c/r+ZoHUndMFziUzij55TwD4Cz9n+Tu8xF7js//OiPobO7T8XexOLnROfE8dg 1SpHlPbIekrD+tj8ts7XWs9am/E/ulcyh+neiwF1n+ne9EWDksCkBB0n4QSxHxi0FNoa3xzfgCU2 xHcnfDBjpct0kS7QBbIUrcC2N1rdB+zHx2eONV6EGy9mzr2P/BX5mvc05n1h8PCecXh899bsI+hj WyMju/Bdw/17zNrzOLHuPmSDvCW3E8vuKPc1RhrDk96ZCBydOcgcRX9wKjd+AjdeaK21K4fS07mx /Hi5UsvD+dqYPIXOTpOeMXzMXdlX2Abnt6kb/gJ5hNkS3Y5Fd/j2OVywyzlI9KIbd46/OIgPvRh+ /2Pk2eQxGXAet75HP2YXK5P7D6Mz00l1Gp9SxnL1Uq1Uqmcn4MyEfGAOedV/snsKm+p5tHAPanCf 9dL/VZbta0LBFJGkTWCQOAXcqolZWMzEClWkxS2KF5vxGbReFbgyXuaLdC6aI9Ih1QcrvpRrGOlh hyIuLOL2B50UTDoHuR50o9V2QC/oz9qL2Zio4qqoCApAd5VWoyqR8eWcz9zRmfFeHL5cANbRpjWY jKYohZSpNJWlskQ50tz+887ATLARLoQLgaxXhVPQ6fLhZvMAPDaTPfIs8orvmZ5JbLL70fy/c927 LkZnkr0QnRKAwwyAw1ipieh3Qn+l/8J+eIolanidLAbTXjjjkUYHkCHeQXkwyhsNhohQNMiA5OL9 bnEIfUx/xhovN+NTqG3ZWf0mu4FAgTdfpc6gM1MpeQIfVxqZSr5SKFQyTTjdlKfmkGlmItLAog1/ 1VV2lfdVd1X3lkaLgZw/HynQRZguchXAxqVKuoili7lMSYXVEmDogFAKTAEvsjkiE8wGNbdqVqlO 615tUHYm4KTLGXegO7qZ0D58X9jhCYzAgRF6oAdxSK6MB8t4it66v+Gf9h3xH/VOBaqhSjgfVAOw Fkx5nEg3OeTxYl7vENmNDrtSagD3q+EsUSJKVJ2dgm3JmRZnP22Vx+WaUlJKal7TVE2T00kg23KJ AvravGD17g+JgM+QoimqWB58AKcBwMmIlAmeTt1pRlw0yQDizUo8qPt/HnHC61A5J/Iargkqq5pE FIg/Jai6ASU7pd89P261vdJ67mI9zfypnsrterrZCVXYvEnnL9TTBJEw6+kr0G6xn3NhvJP2EoFo EPBDGqb9Xt6FOj1JKYAH5bAayUazVImpwWydH59B9I+g/1XJLnIZEGkyD7icOZg4BSeoeGAUMd6D dqb61GFMHcm5Kt6ytxGapGB6apY71o6DJt5UqulStpTJF7KlbEWrKWOwPJY8cBCx5TNthpbjM7zK qCzIhagSUT3qkH7H/InOH1n17a0jmel0Xc13qTk1rcqqkknlUhcsqvFFVqNgjUqFfQi3n49xGBdj RRaLMSIrMu3BGkvml3Ya1tZXuCJfEHNdQjaWzSDZRDqlYClFkoGKTmWShSTchGzGcAsyLrO/PA89 CtmW6j+/Rkea1rBZjS/ki8RLoiKqoP5rgAak95tJczf0DHeArGNkLVzwZuC0b1TqR90ekffgHs7D emkPMxrtD8IP/whSJ7LVQg6owaoyDsg3T+bxPJUOA4Uke5MjfcgAtIy7P7TNAW8bdfZsRdySN+3H 0oFCuAJQplLjxtDJCTnbxMeyE7XJKVXspP7WHuQCZAAjg+Gwn4BJv5d1o8FwIkXghEQqTAam00Kh gswVx2ZL2GzptPZmHLbt0O8+v94+bDUu5yyjUEnMtnmRBDwLfMuAGkcBmg5gfr97AJmfhObouekm UadrfBdXr4tj6DOH0+UD+EylMVk8BJcOqye/j5xhng0fxCKHfOOOMlx2DGp7UZ9fYIN4kA3SADRI n9/lgkXrqkWFZF7OYHI2nc2ZQ8tJsJwrJCvo4cngvjJe6de2PoQ8TG7z9mP9nqHgHrCceDKCR4BA I1VCZTQ2zaX5rFiAxYJYHQM07Gv6f23ts6cABIwACCC9AAK8jiF/D+zrpnY+idxd2jCzC9s9+7zn NbRUSCTzODBByssFJafm0rl0Pl+qDM90etzeoA+Erc/DuVCXT9KA7Vo0RxapIlPlG7DQEMcmkWek w+lpLD2dr5cLcL5UVRtoMS9waTzDabQWbfdsPPDr/2h1yW7JBUTU3tbnWk/YfapfDgC48PsSbnR3 L+Xvx/v9o8NtG8mnNyN3Fx6Z2oXtmjru/T5aLSeVEl6Si1oxU8iUirW6Inay37JMW3VIsoxB/lT0 AruQBAW4TQP4HcvsL48hrTeGQPRecCkoC+Bb6UKyApeCVDV7BPG2T43fLQrGIqLZKRAonga8l6ZI kqIYCqgbigf6RqSisRDaO1Kc9eP+GerU68gbmVP1WWy2fqB0Ai3kRCGDZ4Q0pzEardIScE0qkgzB iWDc60BsS1s36ZDd43IHPSRMepzcCNrvUPNe3FsI1+hxmBrnZ48gmv5DKPYsf4ieYCaJRrgcLvvz rjSccQ1L+9CdPaYf+4EfAz2wv4fe8STy7dKGOeDHuTPet9CxRkqp4TWlopVy5WylVKvDxmn9SXvq hcyR6gQ8URvPz6H1MhvN47loOqC4FLc0FN8L24xj+plWr92Az1jH4tVEAUsUkzkpncpIqiwrQGCp yYudtEKGpzXcRGLZC5/+lTXpdydG0SGHwLpxN+MlfCFfMOQj3ZSbGRL2xkJiVKQB1rMiL4DBi+0R 42M0+AJ2vGqcMiUv2PMYAarCRcnLXpS8+rYmFE4SZllOguJglmVNzJjFwWTCp3QYsn2j5TftXmOV nK6kCx11CIzZEPSRwUggHAlQXpjycM5hZFAeyTqxnKvka0ZGvH4/GYIJgBF+JJgKaVFMA2hfYB0R XzgcgCMBxudFXJIvE8LSoUK0SlaoBjsBivvktDiDnjwi5+fw2dxYpdyES01tYhoZ42tkGaPKwbwn A2fcw9Je1LjU6g7EkwROJs2WEszJopZFKtnyWAVjqg1hAv3h8/mpGXx2qnj8+0hVqHAljC3TOTKT kjp/zVuMt0h7rdhMH0DLRZ4yETETVr1mzwisJhgL8mFMAJKEJhiCpAgGZqNhIYAOODN1UMDq1Mwx 5Kg2Xaxir8yvsv/EWimIfBbP8hrQ1QqotRcin6IQLxsgwhgRChIeUAQ9Dn4Q3dar5F24Kx+tTSOl VFHNY1o+myuBolxtxCZQW7f+AIDJIeufckr5I0wmmORnYXLZZzoawkX3EnzYdO8m4N4UmTRFKCdf 0AQXZKTp3vVQPpVTcpgCIBHMn8lqQOBL6WwihzbKLJHDc4Tql1xwypXYtwMxvngxjkQQR2AGjjNn EyghcnEirxSVGYmVeVUwda5YnUT0ddBErC6UML7MFdgsk6PSpEZoUTmcglPhYNKPBkICF8LDXIgO kWHC6x91AKy2Gef+4fxX7Tf9+kPIWPLJV+36Y01rIBWVGJmROVXIwEImVgFP/8dByLDwYIvyQkZQ wbwyC0gOkyDiUTge2R/wIkYf5AJGE4AfmUYDamRafsFom/HTvzdn+dWHkGistw9aDav5rDKfFRRe 4YHMAVkBtpowma3fgRj/AjlELx/ChCAXZUiGomiSIZgQqLOlHZ0nsjOFRqVZAQE1AWsT0uGToED8 pO1I8ORLTUcW2/XOBMfkxXr3GXAEnvTHwjECJKoI6BvgchzLMTzBBS9ucLC9BTTYAvHTLbD1t6pN +wXZ/imxFi/2GUr19v6LdaHc3n8G7D+dJjRSjcgRydz/BNj/oMCG8BB7cf8DTieT6JR/Zvl0N/5d O+sEDoP+LYc9BBVBEc6CiNNAxOVzWTUrwVImm8yhuXRMUHGgXQAIyYBRtvsQVDIKRijug+P+uMf1 pxgUzGAHk34ag9H2pJBtQ+uKqn22PD5ZPgyXD2vPvYS873+l9xh2vHdz9QGA7ZR/X7v++UxsJ5/e hHy7vOHQbmz3wRe9b6Mnj2qVGdx4qrXAPlebLh9DGzU6BGRYuOBMD8CZfmn3NmRUdPAmsWU8pJ/y R8IhEqCcnwO1dbB8yIO7D5Fn3kLeSJ+uzWG2Pj0s2vlqXWwC4qJVDuAHyk2TuBQBcXkJ+Wn41SFg 2NCu6iY0EhVFAo+CZUTYKAMGGaWCIa/3X/tCbg8QPyCGEkyCjZsy/EJr83bIFwvFTOFlNn3Nni8j mK1NwuwcbwXhY+J8W3a2lVs7SjL7C3Xkn6AiU2YrPLxZ/6E9l8gBB0nAQTnzo+VNllRMltH3jjxs XP0wubXNcgYBPXL7E3IYj0hRlUyTGSYvlGC+KI4dQGw7Wjnje/Zo0pR75ny8GfUmXbgoOl6E9ql9 g76MV/FLXZLPm3Ci27spfx++z9d2ja+HemoTck9+wxRwDaAmL6G1Skqp4GW1lC5kitlisVSFjbsg 9/6gWdfaASiwZrKAdGn3uPVtADlaiP0C2wAhSoEvaZCygG6QbbZB8hRgGyQRC3+Gbbyeeb4+h83V ZwDbKBdENovnuIyZNVElnArAqWDcOQgSe0Xr8tZ2+4DiSHkTcMLriXvQnn6OGMGHSU8o7IVDPsY5 Cni0LxPE0sF8uEyUo43odORguBnN0YB7kwoJy2QyHEDCYpQjMZZk2q9O2u4So0Qsig46lVwAD+Qj NWoa3rrU2mTH2HFQIsfHxUl0vJmU6ng9VVGLYEOyea0Eq2WpPobUuSpZwIhiOO/P+nOjuX35fXlX JqJFVEpj0jCbFrIFpKaWClksW6wBOVAuCGbhaq8yTahB1Qc/DxBYKrdW2n9iNK2bM3uqTsxROxA5 gdZrUhqwn3S91Ki7JzoJIsoQLMwRESGChqPJFIVTEg3IP5PmCkIFFsvi+AFEH9Rve8G4Tb/iAYgf ElxCiA+CMCc5kgb4SbJhDjjM1n2otd5e5XIs0JIAahKmloz7hxFjHbRD6tecWNqV91cIOFptstNo c0zJj+HN3Hh9YgpwVKHNURf9iaMCKARKVwCE4I8cVf+FsQTIPUFrJxBIHyHJJ/kECwYDUihOxYGU Mx6GgkKYiWIsyMAwGFEqyoH1RcUo6gslFcA1FEoFOiDD5YUqLFRjU0cQPWHgkG2lBliSE8oKaQHA Fy+bPXlKCWgOvWt+QefLVv0O/Q9aTS0q2S4lowCFKwPylwPiz3jYCVXbDXUY8AYiglBAy5sMmYuw oRsMsnOVvp8HMlXUusR0TNMQLaEkJSwpXWz4Js32K2TT17UY0f6mVb9WN9SaUpDSXVJaUiSzkZeU klJCTmoJMNvdZvs+yyk0rDJJMBsJaCEB8JSP8tGVBt25pGWzPGg1rpq33a0nhJzwp3lzSU2RMVnJ SRVTBm9q7ybAaokzFytRckB16Zcaf+h826p/sXWJxbZE3wyglNE4jVdgQRUVFSnm0uMprGlsdELK hUaVqb4pDVCvgu93xnWdS42rQn4iQpFdIFdpiqNBoBAmuN/ehCJxCoAJzAI00RA1LidlLCmDJSrv f9T5zo0yLQE87AKQyDBIIEKOCJhT3wLuAgAVyUSy4WKwblyif73zv+tfKDeKxVymK5fOKm1JvwI4 TtRAyYdlLsEywAVAnWA8zQJlsu5bnbaVrfv08/YL7vvX3qtc8J4KvBcGtxKCWZ+4KBf5mhHtXKGL f+Y99VPvySmzeQ70f9Gcf2s7cMy6Z+4lJZNKUHPqi+cXdYaHok7CF/VTYYqkKZo13+gwVIxECToh sTgrg83NwTu+buXrVbGMTjaVbA2v5iqV0hgYs+VjgOZsf0532WdiDaYQgoth1e9CCN5F78WYPn5g BLm/8viRPuxI38uB90U4d5ixbu3JNUfxkbHIiVeRRnJSnsOU2WQzj0zSjWAJC5a9ObcGa1BdreaK ZbhYVuuTSF5oMnMYOytMNpCXc8cmxrDm+OHsKVQ5ErHeIz4a6O6Du/t8TzyIjKQGlb2Y2pdyRREX 7Q+GsVDYRffHYJu+BVClNX+49q8B+GzXf6uX7ANxpxLKw8ECU64j2WRDPYipc6kDE8jbvhe657Du uUdK9yTgSLdqff5w1DmOTzjyuzYiLn6Y7cOYfYIzhIyorqIfKwUqkToFU5Cb9kUCfjjop93DSDjp VPoweV9qyI1sCO8ccWDO0Z7INpTuyVnfT7xSOjIHH5mrnHkHmeAP0Acxek5oZJG6UinmsUK+qR6I A5NX6TbdYjcsH+kWSL/2mj87+W/gxHbe9fvg4kU5+3Nz3t0NvLGrsEm5Hz6nn1hsdD9lPX/THy7/ ZM0fVli2Ll50GBrTf2+5zxq+JbDBOwKPeociPegnv7Sev/T8by2vQvM/Pz9jsRlBnQZ81XWT5RfW +oeWp40LnRSeHa3F8iCVuhQuSYaQEO9g9mF3Gb9jBphR2tdFe6kQRZAESYM8AlAtBlF/NJ5kcGKH hc/kY0X02JxSmMKnio16ebo8nT+WfgG2bdE/1Bfabzfeteg3WaWmOxFO0XIXI/PpPACCsjyG6Ve2 XuxXn+73ZX2qWcb93oQX3bYjNNiN7xkabL9C3kJs2og8me6ujmAj1YnIIXRyMl0FM9WmpiePwgf1 2+3cCOOivbSPDoAADwMGao5oFFhLMCQwlyREEnWHtCKFkyV+fBZ5TjlZeA4rnqwemgBqe3w6P4uO AbWdwdOE7HMgHsHNOzGb0uLO32pPtd9qP/5U1LED3+Ho6R3YNrDN+Vjgu7B/Hf3YVuQ7xcdn9mJ7 Z57zv4a+9SOt9Bo+rWOWbdbgQNAZ9AcDgYifgRm/h3cAhpBt+PFAkzr0AvJG5u36e1jjvelXj56E Tx49Xj+JzjZpfwEv+NWh5G5QPKf0zoH0sOxIdYGg/r3Nvmax8R0Q1fplrfXnF9vL7R5GGkCnyrZb roQaVUKKV/Upo9oA/KI+NP/xsFU/NP+w8dL8cstI61+gvE5ZHrVyI5ybDXABNtJ+I0ybr5sonhRh gQjFvKjxnlWvtBZaDkMGpX9isR1pnrfY9fAnFstfW/WJ8xbLndZ7jfstxgHr9/T7Lfr6+QP26/Vn LLrHapvVb9R/ak9MpJpyXa5p5Uwhk89mc2peLUpVoNSq4/FZVN/2trHNunkHFwUEkBjyuUado4FB sg8m+7idjyMDiUF5BJNGVGfak3bnvaVAyV+KVKgKVWObALQak0DY63veNnZZdw2kVCB/FV8uXAwV iSrTZBr8hDgNt25422oT3jp/if1B/ZfGk8YHD+ofGKPGLx9s3XL+EgjUkwP6UbuOn+s/a1x5W15f ZnnIWjCWGVf9qv8xfclDxpKHZjbpV/0yZCyznLOG9WX6lctnXrLYNrXiLc6u3zP/iBOqAxmkthu3 ozuQ+bugHsHJEBhLBGgHA4pMfxMakH0ZNg8DOtuYQVqCvhQar9FB4N1goS/3OGx7pvXONXIznABc WumiFcAECjzgArHx3tbxzrVW4835I76BsJsMd5GgioH6AeKYjHHOTn2rVW5a9kmB4iQAs7xcxOSS VsnVJ0516v3W5DpLPBQPR5E+zkWGMSoSZrwiuOto6227ZA3vd8X3YfH++IgH0YxbLcZGq+3gi+dv sbPOogCKOdWl0hIQSqlQwp/wzMyf6Dxn1d9sHakeAnI015XOapoqq5IKKIDU7ARu5JyWWbYYHEH+ J61WHtxGdcZnOpW8M4AoTJdKu2W33AOFQKEFWkK5YaCQQIJjEhInsWPHciRZh2Xdq2t1OfJKWt3S SrIuO5Il24lJYouEQMJwmKMpR4fpAC1t6cEUCnQ6T5l1O30rh3RKmdJ2hnkjzf6z73vv2+/7fr/f ex/lt3ksBG1xGe2j/NDKeVLfAei6U6Lxyng6jE1OZJkkwaQisSgrnH9nhNclC+2LgQz1GeFblNPu dFJuO015bH7Eb7ONU/igOlGGyVJyzT+FLYQPxZaI+FLqMHeQO5SfLU5PTpUmS2kkXa6yU3iz7DIL iRNTMX0wcWrgWzBxWE1IxmhVEwp80xZKs53crhkYVDyu2DrabV6PWNa5u7f8S+pO5plQgSyEq/Fm tjIgPRBvgjVsPVwMpWXhdCgunLSHO1fVMSbZ2X0P3H12POmPemRRT8hhxfQ+Da0gJPwF7ZvAp2gZ fE0UH9wV3o4P7HZbhkm5VaXT7tEqjINUH0LtpAeGsO5kf2WEGCnP2Vr4XDOagcouW6/UGsqaVKcb NY05EIde61HiGkM0S5EU5yk3sMXoEvckkX2yOF+tItVO4UrH/Z4oGfWGXSEH45gwBXUQUi5u1zvf lRtPwgIhYzsrNPg17mFCzl/jHnL3u7bJnFs9wwED4hE799uWjMf5b7bPk/LXiT/3FgXFD5SDVMDm t928cpbUPewd89kh1escvXqFK3YogighzMBtsMibg/bPinwGK4QqbJ04BHpii/HFaEsWa4XrExzC ilObM5u5zeCSlZukkG12tXPQ2aUwdHYqlBAussPhCOSb0NlMBMbKJ+C6L9wOhCi4pNUVyb54STvF T8wybJ2ssdPxSgqOwlS5WinVco18MzMfX0DiC+GDh7HD9H6qQVAzhqq6oMmr0goWiSr7Q1vw3u1o kMvsTePLLbN8hqwPZR+7D3vcs43aQdi3G/rU/epdCtWgCTEN9jp7cLUpGHSSktqZ9aZ8rBAgjMOC Gf+r9W6DLrQEHRM0I/NMeMP+MOKLjEfjWGRvNBglgvAvyAbZiQSTqoNLpYHi9N4GfqIV5RbIA1y9 Wp5DSnOJg0ewqq/ozhPuvD1rSVmSYzFdBIlo94R24fxF/B/RV8ERUbA4GSzgizMuU57Mm+MjA9iI T+MaJdyj9jGL2Wo22HUuxK1V+PpxyUfgmlPnoJCaQmZg9GnccmIzb6CVHo1fJ/ONBsaMWE9mV22E UNcOUSfwpw6y2VmymdlXKTVLs7ml1HPLYFHK1iMwm0JpSHnZEEymyGoyMUIyPfT5oDP4BF/dxz/v 6nMMUxqZTWs26G0INaqm5fiQJpYzk6ace2oO44K5CY5gskwulH8BVAUrJWglFYZRJOiWcCeKUh0r j4nPfBEJXwWPQBqkv1r0nrj0gYjftGJDXQPePTpMxxqSFsKa4tyTeKUYScKqkKyWZpojU1LDqMXq cCNuByzGuItmIj5SuHlPYVyozM4QPwOviM5wqdQqlxI8ZvHp4GYkTvAxOBelx3xGE6aPmJM2gkpm 6QJeLrIpgW1XirUZ9ZR0bNS6asQhGPEwES80EjhjBJzTnhesnAutQJeNswEZ6w/7GS8itHc4Mde4 PUAJ6Wr3O7W8SGqKm1kzRF+z6cuJVb0Wn5wmp4u1Rn0JmQbf/aqI1dvgVtTV51XoP+/sVMfZxf/s 7Cz0Q4MAZ0M/qAQ/eDt+iKz6IeRFmI4f3OPO8c6Zjc1nRiTXtCUARdVqrUFHIZRWTStxpV4oq7aM p9LEShOToTzxyVvp6WPksenqE8exprNiyBJZgyq6C+8fcJl3k0NmhbZTwXdT/Yi9nx4cwnpS/VUV MVKdt7aEs7lcg5zhZqozswi/ARxCG7UZroHn0h5HjIzbQ1YDpnSNmk2EyaylhuHGhnf5tuHZZ8uL tQYi2dG+62107rncb4UO4i7zr+THieNDm6bvxu/pVqzfTQ6uN93AizG+i7uxsZHY2Dg28jr+xjOd bt3r2y+iby2s4deHST4gBuuZJ/7wCzy4wqNrd34ANvhJMC7mNwT6r74FP9N0vNpU2nPqcvAg2tpf PvEG9pr66e4m0ei+h/s+3gxNRmNELJZhJ4Wr815d16Q3TcdcSNQVHhvC+B7XVbfxl2B3lXuOyImj 8teNfwogga5hn97jIGinxa3zQA7UW+7SRqxROo7QCX+xgU10/TnyZqm1HxkB16I88pN1POojwN+6 ADr+0sP82djKnfyFqHKfdfEFuP2XngcXRAj+7133TmzJKPZBPJO0f/Mq2loqvfwu9qr5afk8VJo7 8j34hh2GPgWp6LNsvBvjh7ouim1aBgj2+7k3XztOqJoiXnz7husvw/gLf3knWEsT/M53wM6u95mT 5dYSwveBy9Dng4dD0wQzFS+mswiXyUeLeK1kVeZIThnb2Y3xVzz0Y/5cmpCA+9tvgxT6A/OD8n6i b3jz2AP4A1smn4CwvmBZfg9rr7tl5cGu75RvaW0iulsn1e/jvzs5daxFto6V3/wAa+9c2yXhQAB8 A93jG/XYCNpmdCg9qz0VyrApTgtE0QfR/eWuFzOv198l6u+Un84VkVIul8zj6YTbzJKL74ujJjNj wuVKhx7q6lFNr+Zezb3GddSjCC02fWp8y/iU8ZihYcwiWYOOVeF6Y+f6mh6jNGMlhZTLFWIFPMs5 DHBzY5WN9TVIfU32tvWY5Oa2oz2EXinWr+3lz72XvwXyATc43/SBehlZVg/Wt+FKuVA0CiOidD7D JvCZ+o6bYJG4sXB5kj9LKCKbujHF0a7D06JgNpgvYocDC/4mcRyc9xa4/CPwI2S1e/nn6E+F7mW7 0L1c4B9bgT/h8UP+otPhGAZHKqgAfB6GXsU9fyQQjUeC0SjWQT2IexNxJvXX9pj0DTGXCPhZEia8 J+wOuUNUsHN5q1NgS+ID4HbRCise5H8oaom5+cxUMgtHIgkBMJllCviL4ktWtLTSq/daZV6rz+mF CsgrtAn6XLBqeiAE90GVRZz6ejuPRiCahE+jSaiDJhEmehpNThNAX3QV362dymslAlaBKMn5K6V8 RtwAV7KdKWQhyGvCp+f4JyL1fB73PpvDbwt8KdnqgUrAOEExUEF4In5BUe9NdhrvJtKh7AJ4SAqy 4n7+fmEKv13m68zhc3v+bQ4TJGx0ROaGc2Sw2N640A2aZDKhPCJptS8HL6LP5xan6rNIbTZ76CiW 83PeLOHJ0hlHypmkEpaoNWqMjEGE0Y8wQzivFH9VtOd0ADTBtdIT4lTidBOyl/WwdMQZFtqPrYyp eKk02heTx1UI+LYwJSM0ycncUGbRUU/Mk/ClodLK+nP2E1LvPnfJmXVxVNqSQPi18+gymBMF87lg Di9y44EUmQok/HFf3Bf1RqAVGGp0yM24VhuUKBs27N5jUREWld6ghpgyMujZiktm/2+i2r5HfAjc KtoqtqntY04LHHYnVH5OjwPKXrs1YMT5y8TLYFb0oTibDAQiZCQQ9sC1hFxBsxo7KD4MHhb1iu1a u4mCwsFu9urwNeITICYCN3Q6tmG2BCK+sBcOJ2ODEm8sOALFUhNcJZKsmwdXo0oem3bXPU2vzDs7 E6jhiweiHGRx3FQpX0fy9fjsQodUFiCppPIWzpzT5fcUB6u6SSqPUDl6soKVIsVEnojns5lCAklM lsNTeDHnp6Ej6YRD6AcLrdqcBucp4ipWG5KFNOoJJd67q6OQLGq9SYUYlS75AKYL62NGIm5ImqC2 txQsZfOUuWDJ2NK2uI21IKw1ZDZgOyi5VkfoNHJ7Lz6giudNpKng2reASd4D1VPnozt0pw9rui0P IeZ17o2PY/dxPc1BYnfziOkVfOlQoniQPFjcP9tYmlmqPMMtI7nl6LNHsZMdgJmTP557EH9sq123 gwQDKyJUd4fykYE+pG+wz7Adv2P30Y8PRo6kTpDJE7mnSkul1tRcrYJU6o3kLP76/JYr7rPfrbuD lDwyHUTb3xMfAY/CL+tQOXQOIxxWh1249LB7ER9lDuhx/mzxX9rq/61SfHlQIZK9e8Xg5Dfbv0b/ IcAAH+LWZAoNZW5kc3RyZWFtDWVuZG9iag05NCAwIG9iag08PCAvRm9udEZpbGUyIDk5IDAgUiAv Q2FwSGVpZ2h0IDY5OSAvQXNjZW50IDY5MyAvRmxhZ3MgMzIgL0l0YWxpY0FuZ2xlIDAgL0Rlc2Nl bnQgLTIxNSAvRm9udE5hbWUgL1ZIWFlQRStUaW1lc05ld1JvbWFuUFNNVCAvRm9udEJCb3gNWyAt NTY4IC0zMDYgMjAwMCAxMDA2DV0gL1R5cGUgL0ZvbnREZXNjcmlwdG9yIC9TdGVtViA4MA0+Pg1l bmRvYmoNOTUgMCBvYmoNPDwgL0hlaWdodCAzMCAvQml0c1BlckNvbXBvbmVudCA4IC9TdWJ0eXBl IC9JbWFnZSAvTGVuZ3RoIDE3IC9JbnRlbnQgL1JlbGF0aXZlQ29sb3JpbWV0cmljIC9XaWR0aCAz IC9UeXBlIC9YT2JqZWN0IC9GaWx0ZXIgL0ZsYXRlRGVjb2RlIC9Db2xvclNwYWNlIDEyNCAwIFIN Pj4Nc3RyZWFtCmje+v9/FCAAQIABAGN3DQIKDWVuZHN0cmVhbQ1lbmRvYmoNOTYgMCBvYmoNPDwg L0ZpbHRlciAvRmxhdGVEZWNvZGUgL0xlbmd0aCAyMTgNPj4Nc3RyZWFtCmjeVFDBasMwDL37K3Ts 6MFOYLcQGB2FHNqNpdvdtZXMsMhGcQ75+9lu1m0CSUhPDz1JHrrnjlwE+cre9BhhcGQZZ7+wQbji 6AiqGqwzcatKNJMOIBO5X+eIU0eDh6YR8i2Bc+QVdk/F9sfHvXoA+cIW2dEIu0v1/pEa/RLCF05I ERS0LVgchDycdDjrCUH+Yf9ClzUg1KWuNhne4hy0QdY0IjS1am8Byf7HfhjXwXxqFrdJpVISaXbr ZlY+7K7DLMxJYrm+SMjLHeH9QcGHvCu7+BZgAGRea64KDWVuZHN0cmVhbQ1lbmRvYmoNOTcgMCBv YmoNPDwgL0ZpbHRlciAvRmxhdGVEZWNvZGUgL0xlbmd0aCAxNDQ4DT4+DXN0cmVhbQpIiYxXWW/b RhB+16/YRy5gMdrltXxs3QZoG6MBqhoBkjxQ1GEilGRIZFz31+ebgzIlO4ZhgJrZOXd2Ls//nPw+ n/w6n8zi2SzkZl4T5IvUzB8mLnZpYuYfJg5nwczwJ1CWxGXpg/FlGZd56sC9nXyOqrUNcR6tG+tT /O4aRjvBHq1P8GOanU08ce0P1ucAttbRTzVmbuwM3z0fKf+VebAZMa6YZu6Z2AuxM5CDSj47iEJl r8ZnS0aMnJmjHIpC5VDfV0pjvaJ2LRSzHUuJJmXu1VQ6u9TQ7cVPY7+a+VnIEw35LCk45D+LdAhx mvpCAt2wD0lEMUiidrUlk0m02jHOMUwkQgmHMpEg0g8fyc9GzsySsccxX8VHakU01KJVKG0r2KMR /Cic8kRwpG0vCHh8CkIQOI2+rSgdwClODoLCcRChb62gommp3p5H0HlfnFLVvZqrRR6XfuZzCeFi pLrlCwqsAajVv5i9/UWv25pGQ/1q5EVT1wi2V72nuzccFB+ZWmyMGdYioy+0Gi7djVWxkk8r9dTc Cu2GafJF8EfP/WLkJO0Qj7cVep7FSRmCl+BdH2xAAUxDtGxwF9wbIMopIEsA3ZGDQu5bojNMMrF1 uPffgHpCzYqo/xH1XnkSj3wDtB0s7Lh+CCL9ZrkaqPvdkbi7QXfVnUyZ7uRGJb79BoaP1s2i6TgK Uy5BCUVWujcmEoBQ5InW4j+kH9eG7TsCV7ZAxAH09Glht2HijtANO7MXsgQO33t1HN/Dmn+Y47A9 mmsGhLYkNlEmcog4bnhm+8Sn1qcsEsbWF9alqHZW0NlB6NiNeMH6UraEMnlbtqTItywlborQdzJb HSQSeLeeH5IrgR94eQI5e6rTg+9JhpnXdCVGzfVHgv8FOEXZumix7zlFlobfvyL+b0O6XHG+PdhU bUte7HtmNZep4PwbMyBBLBKfBu3GfIvuLNHX+hyCcZHsNpqWSPosMi3fsOLLGzvFd1FxsVS7mhhY GPWCwr18i1eeIEdjwVT2xrsyTpyb6Wg+U/HufWpwwfUEF2ZRbzKcYJjneiUXX5j8AKHsUihP0H/P 5J7Nt6Sk1HnBYMHujmX/wFvFJWUqPWuH7aAAul/2tSWga/a750n57r0XzWWsuhnIyhjv5IKPXf4T z4KTpE6LMrw0eSmS8Bo/6t+c+qyjQnMZ/FkJiumJJu6ABny/U6t1A63dC3ovLFtIpk+SO1XUqSJl XsuP2fYi1aqUsjVTNlQLUWUOTz7RqekUqG1asMvMBYNJSSEVdPBuo8KPNIId9WSWHdyrFsqu5xhe 4TKa3oW3LYwuy2JfhEwf5Sg1g9w/cPeh8I1xnpDsL7sji5bgbbOUnk+9QzkC7zIcBRrQdMPA15Ij otH6yZq/y6Q5mWJFveX2Q4Oeop1G24pCyG8uq6H6wT6yM+ZLBKFbAm/o88XaxKFu/eyF/oIq45xz aZ6+tu0hinGRFU7H7fyOXw4z1dSYm1O0H3ZbzmSv5rLhvplgU5T2ioQDDTOw2Snz0U4L5pKNVzVU A6M05YEZMQqnXXxgFtG+4uxIKTtZstHf/8WNSlHhHoi6zxuSJU/5UPbo+g5Ws/TE1J6JbETro3VF LCEX63qdvlZ8iNOzyA9D3oehxbtQvpqoyPm0CLnT/2wk+8ynlcxS5I75TF06oy79lT5XFnb/ur3B +bSMPB0pEZJXuA4S4vbmgXcSGfWshtYFEgkxCeG4HGlkITIpw7m2ePkSyUXnSDSa5jVtQlb2C96G aOJMh6VjcVoFOs1bzMXnrXDIyjes0sEX6LgefmT50Fs3B5l2fDVa9FsuOplq/K+PbLBaR1yMphnV coXmThKcGrko2Y7KfsMqWN1TpR2xeiNGpIsoNDPGNjDyDbe4iGYsMyVltOAD4mvZyk4DC3D1NImp B4trvHIgXuaHAAMAqtZNJQ1lbmRzdHJlYW0NZW5kb2JqDTk4IDAgb2JqDTw8IC9GaWx0ZXIgL0Zs YXRlRGVjb2RlIC9MZW5ndGggMzUyDT4+DXN0cmVhbQpo3lRSTW+DMAy951f42KkHIEDoJIS0dqvU wz60drtDMB3SCFGgh/772QnqNiSI85z3no0T7Q6PB9PPEL25UR9xhq43rcNpvDiN0OC5N5BIaHs9 Lzv/1UNtISLy8TrNOBxMN0JZiuidktPsrrB68M96r9bxHUSvrkXXmzOsTsnHJwHHi7XfOKCZIYaq ghY7Ee2ea/tSDwjRH/Zv6nS1CNLvk6WMscXJ1hpdbc4IpYwrKDdpBWja/zmRB0bT6a/aiXAyjmkR ZZb4mBZR5p2P8z3FSvtY7ShmUSJJVQnSXlToxyyiwaOUGz51H6Q3RJMNA0FHbglI2TeVHkjZPOVk igFgp4ydsjyUlDJQMBBEKSaAKXloIGNKznq5CpVLrpw7UnUon9tSbFCEPtUTAQW7FEG0YJeCKy3a AGyXLkNb/DN53rfx6ItzNDl/KfxkeCa9wdu9saPlEfArfgQYAPiJqL4KDWVuZHN0cmVhbQ1lbmRv YmoNOTkgMCBvYmoNPDwgL0ZpbHRlciAvRmxhdGVEZWNvZGUgL0xlbmd0aCAyMjA3MiAvTGVuZ3Ro MSA0MzA2NA0+Pg1zdHJlYW0KeJzsvHd81EX+Pz4z77I1u+/dzfb23mzLZpPsphcCeUMKJZQgLQEi oQgIeiRRsZxKLIiASuziqeBZD70jIGCwRkU9Cwee5fSQ4ondKOehp0Ky39fMbhC87+f7+Px+f9++ mffMe9p75jXPV5t5B4QRQlrUjTgkLzx/fsdnyrJqyHkcIfuyhSsvlP+V//erEHI4EFK9srhjyfkv PeyFFv4jCIlFS867dLG45OmXEIpkIzRq1NJz5i/aN8d7DUKLpkMf5Ushw/yt+Qd4vgGeQ0vPv/CS bWNsr8NzL0Ku3PNWLJyPVz/wD4SufB+e88+ff0lHFpb+hNBGHurLHV3ndBytvO1BeA4hZLRAHpcJ HkTHjXQKPEFK34h4HdTBHnhQQemVeBXegG/B9+Ne/CFOkVbyKnmNHOQwx3EaLshdya3jbuDu5/7C 6/kp/Fx+Hn8rfyd/L/8A/wT/NP8B/4XwkvClcFzUi27RL1aLM8QBcci32veTbJStsk/OkSNyoZyU S+RquUYeJdfLK+RV8oPyI/LjASFgCdgCOYFIoDAwPXB24PbAozkkR8wx5phzrDmuHH9OLCeeMy5n fs45QRKUgoEwCpOwPiyFs8OOsCccCueHS8M14fPC3eFrw9eHbwjfGr4//Hh4e/ip8DPhPeE3wvvC H4Q/jdRElMiYSHtkYWRxZPnnwueOz6uPkWNFJ8gJ+UT5iZoTo06MPlF/YtuJz06kTi4YrB38buhk 6mQqRSmLNjPqbMZb8V78M1DnFaDO+xw6RZ1rgTo3cQ/wmDfwU/mz+R7+Dv5u/vf8n/g+/n3+c6FX 2C8cy1AnICpiu3jM1+3bLOtli2yXZaBOHlCnWK7KUGcZUOcBoM6WM6gzLTAn0HOKOiagjjPHl6FO e84iRh35f6BO8ynq9IQ3h7ecos7rQJ33gTrVp6hzTmTZ55hRBx/jT+AT3hN5JyqBOsqJuhONJ94+ cfLk2YOjgDrdlDqpjwFgt6eyyevkWS6R+pC8idCQEZB1C74YL8ddJzfD87kUe0Pxobyh2FAuJC9H l6GV6Dy0FE1EoxA6uf/kGyePnPzryX0o8/u4DaF/fJhOH1kN4faP5hy59shPHz165GJ4ehJCD4R1 R6746KLDyw5feuSpj/OP3HT40cN3HLrj0O8PrUfo0MO07WH7oc5D8+ApeUg5VHIo9GHjhw0f1nxY 9WH5hyUfJj+MfZjzofvD7A/xgW8OfHXg8wOfHPgHbXXglQPPH3juALzlwMsHHjqw9UDDgTEHRh8I Hcg5EDjgc/W7fnZ9JD2HkABBda/qHtXvVHerNqZHK34hjhJuFBC3kPIZdqEzfuT1dDjj+R3y8/Az N+7M+pxyWnouIKyP/ytC/Nfw7nuEzQJwvtB7en0B5JCwIx3+p59wHw3C5szTPf9zzf9oeaGw8lS6 6/9Zs+XMkQmPi1eLW86owqEH0LVoNXc2ugN9iq5DN6H16F70B/QgktA6IN016FZ0DP0T3YjuRNej F9GH6Ft0H9qC/oW+Q8fR70Hi/hm9gv6IFqCFqActQq+jc9Cr6DX0F/QGehPtRZ+hxegttA/tR39C S9A36Gb0Dvorehsw9wX6Cq1Fy9C5aDk6H1D4G7QZrUCdqAN1oQvQRehCwObF6HN0CaD0UvRbdAXg 9Ul0P1qFrgS5fxX6En2NduM78J2YYA7zWEAn0El8F96I78a/Q4NoCItYhdUohe/B9+L78CaQG/dj DdZiHdbj3+MH0A/o3/hB/BB+GD+CH8V/wFvwY/hx/Ef8J5AvvXgb3o6fQD+id/E6vB7vwDvxLvwk 7sNZ2IB346ewEUvYhM3oCPoIW3A2fho/g63Yhm/Az+Ln8PO4H7+AX8R27EBbUS92Yhd+Ce/BbpD1 XuzDL+NX0E/oZ/QP9DH2YxkHcA5+Ff8Zv4Zfx2/gN0G+/QUHcQiHcQTvw/vxW/iv+G38DnoKR3Eu juE8dBR9gt9F76HD6AP0d3QAHUJ/Qwfxt/gY/ifoju/wv/Bx/AP+N/4R/4R/xnF8Ap/Eg3gI54Ne QQQTQjjCE4GIREXUREO0uIDoiJ5kEQMxEomYiJlYSDYuJFZiwwmcJHbiIE7iIm7iIV7iI34ikxtI gOTgIlxMgriEhEiYREiU5JIYySNxcj1ZK0iCidxIbiIbSA+5mdxCbiW3kdvJHXDdSe4iG8nd5Hfk HnIvuY9sIt9yV3HXcKu5Ndxa7kZuA3crdzu3kbsXNN5D3B+4x7g/clu5bdxObjf3LPcC9zL3GreX HOPe4t7lPuAOch9xn3BfcAPct9w/yT/Jd+Rf5Dj5nvxA/k1+FCqFKqGa/ER+JifISTJIhkgK9Abm COgOnnzNCUKukC+MEGqEUYICdccI9UKjME6YIEwWzhJmCrM5v3C2sEBYLCwTfiN0CSu5qHCZcKXQ LVwtXCtcJ1wvrBNuEG4SeoRbhNuEO4S7hLuFe7g45XDhQeFR4XHQPTuEXcJTwtPC86ClXxXeEPYJ b3EFwtvC34QDwmHhY65I+Ez4SvhW+Jfwb+GEkBI5USXqRKNoEi2inftKdIpe0FsyaK4cMSRGxFwx T8wXC8UkVyYWi6ViJWj8UaDVxoj1nFpsEBvFseI4cbw4QWwSJ4qTxMniFLFZnCqeJU4Tp4NtMFOc JbaIreJsKJkzTBtOy+k4fZo24lzQkIvEpeK5/IP8Q/zD/CP8o/wf+C38Y/zj/B9Bq27le/lt/Haw PnbwO/ld/JOgZ3fzT4Et8gz/LP8c/zzfz7/Av8i/xO/hX+Zf4V/l/8y/xr/Ov8G/ye/l/8Lv4/fz b/F/5d/m3+Hf5d/j/wZa+gP+7/wB/kP+IH+IP8wf4T/i/8F/zB/lP+E/5T/jP+e/4L/kv+K/5gf4 b/hv+WP8P/nv+H/xx/nv8cf4KP8D/2/+R/4n/mf+BNqGtpN1uBTtRLvQS/gT9ATagfagq9ELaA03 mZvCncU1c1O5GdxMbhbXwk3jpqPv8Wekn78SPYM2ogGQdg+hW3At2oBH45X4ZtClt+KLUR++HA/g b/hOvou/ir+Aa+Vmc3NAK7Tx1/IX8Rfzq/mV/HX8pfwa/np+Lb+OX8/fwF/C38bfyN/EbwCL5GZm k/yOvwfstvvAeruL38hfwW/iN/P3g6XygHiheJF4MVg2h8hhcoR8RP5BPiZHySfkU/IZoHMkoHGa MF2Ywfk5mQtwOYDJhcIi4RzA6RShWZgKKJ0ntAvzAblNwkRhEmBtj/Cy8Arg7U1hr/AXwO4FoEEu AhSvEDqETi7K5XIxLg/Q/FvhcuEKQPJawPMawPN6wPcqLs7lA6pv5gq4Qi7BJbkirpgr4UoBpceF 74UfALFfCwPCN4BTCZBqpu8EnPrEZYDV5eJ53FfclxC+BlyOBmTWAdKPCB8J/wD0xgDDUcBwXGgU k2IRYDoMeC4AFI8Qa8SRXBlXzv2LOw76W0Rpwxl+mMCN/ErRQSHHC6JKrdHq9FkGo2QyW7KtNrvD 6XJ7vD6/HMgJhsKRaG4sL55fUJhIFhWXlJaVV1RWVY+oGTmqVhk9pq6+oXHsuPETmiZOmjyleepZ 06bPmDmrpXX2nLltZ89rn48WLFx0zuIlS89dtvy883+zoqOz64ILL1p58SWXXvbby6+4clX3VVdf c+3q69Zcv3bd+htuvGlDz8233Hrb7XfcedfGu393z733bdp8/+8fePChhx959A9bHuMe/+OftvZu 2/7Ejp27nuzb/dTTzzz73PP9L7z40p6XX3n1z6+9/sabe/+ybz96669vv/Pue397/4O/H/jw4KHD //UU/usp/NdT+K+n8F9P4b+ewn89hf96Cv/1FP7rKfzXU/i1pyDcBGEi8kPwcLchN0KpjyAchfD5 0ITUSWE5Cg4tSx3h6K78HzMBoTDotE0ohI7hIljLfjQBPYxGo2Z0GxoLGmkrMqBL8RuIR0FUjx5F YewHD6QR2UGTbASZOhf00Ccg3XNREzoEcj6EGkA32VBV6gu4N6HrU7uhlhbVgWZ7Cp+Hp6EEpMeR fByHN29I9SM7yk3tTb0PT/eCrA6ltqFxkPoUmVAUtNjNyAza7/XUSRhpCPTnI4CrL1AAtaP1fCm/ LrUcjQDkvoubIDUJXSq8r9kJWvJm9ADolP7U4dRn6Dkeg7ZdBYi+Hka8HfWTQq4OLAoZRdBINBnN h9Lfog9AOxVxSiqaGpPaCLmPoO9AMr/CqWAccTQezQPdfj9Q4z3QKN+DbiwDbfkYXG/hb4T3YWxN oIsvA417L1DvEdD3u0HaF4EusAO17CiGZkDZBuCU7cBf+3ETbqWaj3tISA7VprJT1tRnYLvnoRYY 4SbgvKPoOE5CHXgDl8NdyPv4C4XiwatghovQPWAlvAXjOAR0/x79iPPg+ohcSValZqUeTX0CY1Ej P6pEU9FssBSodfB7WNUXgaf/iU+ABruS7ONfBhwfS90CtI2gMTD2KVB7GvS9HlZpO+qD6z2YpQk0 bhGuxJPxWXgJ+BR3gF7/AH8AujBAOsmXXC/3BvchXy4IqWroyYZ88N4gmgVWy3lgfVyPboH5Pope Rq+Bxo/gApjRe9D+BzKC1MP1ANlHDoEW28CfFK4bOjL01dCJ1Drw7+oBdy1AzS1AhW/BUpBBjy/D F+CPYeQ9ZAdn4CTwYsq40dx0kCrXc7dxfwZPrwuk7d+F8cDRj6nmD/1m6K1UU+paRL1jEcYVRfmo FFUAfhYDmpbD+DqYBXU5WEjrwJq7Gca6GT0G834erLJ30UGwmo5jBPZGEp8Lbz8fULca3wTXRrB9 XgC75DX8EdgNcBFwcECTl5NaUkcayRKyGq7byH7yHvmc83ALuVVcN1z3cbu4D3jE83xKKIZrHMiN R8Q3VLmqcaoF6jdPDgzmDbYOHhpCQ66hOUN3DL0w9FlqZupSGH8YFaBCGOkaGOVGwOBDcG0BJO4C i/JNas3AWL8D606gVhRYQ3lguxThWjwWj4drEp4K1wy4ZuHZcM3HC/BSuFbhbnw1vgZfi2/Et7OL 2oQPgX23i1lwT8H1Lj6MP8Vf4u/AEkJgB9nBbomSBKmCmdaRsWQKOQuuJWQFXB2ki6yEFXqEPEF2 k/c4CxcGWTif6wTL5E/ci9w73E884fP5BF/Dz+SX8NeAVnsL9NgJwS80CEvBAngR/M1S0LfLxLvE reLn4kmVqGpWLVBdrnpHlVKHQVq9CvPeeYZdnhD34QuEbP4Schj4wsF1CGvwDKCYSKZz54EH8ldh MT7GyfjveB13Lrc89QDXSH7kVuCZ5HmcA7ZKNbcY3QC272OgQY6Tz3grnk6+wLn8zfhJsoKrIyLz B97mrfw1wufg/fwNVZMrcD95Geyva1LPomrhPnxYuI+8hWT+CLGgw8DVa8id0Ogv5FyyHrXwpcIJ dC7Q/Q/CJUDvUeR6nMe9w9+HPuGC5F9ghd4BUmMvnsCHyNmkCj8GEncQ+9AABgsf344UsJcP4j6E 8aPcI3gi0cNq9ZIsXAE+x14ugN/htKiVjhFHiBU3k2NkBveMuJ8rwxikxF/RZWDzJwE7w78h8B8W o9tIFGRaA0iTt3ExcoDPMhodH3qGSmzhfWE94Ox+Lh+dhZKojbyBqoE3PoGrBfyeYvQUYPB6lCR3 octT3XgRyP1JID8J6PtlKIF1IC3tMLZVoC9sJAdkIfiz4B1oweOpQ034G3QxloGz+lEuT0tu4BtA MrWD/F0P1yLUBk/3oFvEncLbaAq2g/coD90HKP8QnQ0652N4vwvVwPhmo/v5fBi1DJK5E1rcMzQO KXBdh97ABHygavDUl6FmfhxI3jtSy2CG54KOmgg68TV0bupOVAdrd1bqmtR6NC91f2ou+FzTUo+C /F2Z2o7K0RqhlcwU4nwpyNjX8B7QRwfwepDb49DfQR6FwVf5Ei7wZ9Eo4Wm0jv8byM7a1A2pd5EV 6JEDFFoAWvQo+GvfAN3Gcf2oZGgy2ZZq5DpAQx1GU1OPpPxYi5amzgPJ+wx6SCWA7OlGPuEhwC5S xsyYrtSOGlkzorqqsqK8rLSkuCiZKCzIj+fFcqORcCiYE5D9Pq/H7XI67LZsi9kkGQ1Zep1Wo1aJ As8RjPIbgo3tcm+kvZePBMeNK6DPwfmQMf+0jPZeGbIaz6zTK7ezavKZNRWoufhXNZV0TeVUTSzJ NaimIF9uCMq9e+uDch+ePbUF0jfWB1vl3gGWnsTSPSydBelAABrIDY6l9XIvbpcbehtXLl3X0F4P 3W3TaeuCdedoC/LRNq0OkjpI9dqDHduwfRRmCWJvqN5GkDoLBtXrCtY39DqD9XQEvVy4Yf6i3uap LQ317kCgtSC/F9ctDC7oRcExvcY4q4Lq2Gt6xbpeFXuNfC6dDVovb8vvX3dDn4QWtMf1i4KL5s9t 6eXmt9J3mOLw3vpe+2VHHb88QufmupY1p5e6uXUNjnNl+rhu3Rq5d/PUltNLA/Te2gp99JJwY/u6 RnjxDUDCpmkyvIusbm3pxavhhTKdB51TenbnBBtoTvsyuVcTHBNcum5ZOyyMa10vOuvSwHaXS9md OoJcDfK66S3BQG+tO9g6v96zLRutO+vSJ5yK7DyzpCB/m2RKk3WbwZhJ6LNOT5xzqoylWHWaajrr FF0xHVFwPMChV14ow0hagjCnSno7pxKtW1gJ1eDXiqFV7yJYj3N7NXXt66RqyJdo+14hLAXldd8j WP/gwNdn5szP5Ihh6XtEkxQlp4AG5cPp3ni8Ny+PAkRVBysKYxzFnssK8lf2kd5ghyRDBORDzUDb +a3VCSB+IECXd32fghbAQ2/31Jb0s4wWuLcjJRFv7SXttKR/uMQ6g5Z0D5ecat4eBBzvYFv11l51 5NQ/o2SzNCyt7sW2/0fxOenypmnBpqmzW+SGde0Z2jZNP+MpXV55qiyTwukCIHgvHwZKjQ8C9M6a 3UIz4J8Qbgw2nNs+DlgNxthrqWvh3KQ1nSJujnUF+J17qmf60KKnffFhkeF/UZ9KDQBmOVhu7JXa x6XvrdpA4H/ZqC91jLZi0S/NMnPqrY6f+TzijOczhqdfx8GA+Qhpmj573TrtGWWNIKzWrWsMyo3r 2tfN70t1LwjKUnDdbnBdW9Z1NLQPL39f6qn17t7GG1phEktxNUCboDHbgvj6qdsUfP202S27JYTk 66e3bCeY1LWPad0WgrKW3TLIZ5ZLaC7NpA8yfQD9BlyxnahZffduBaFuVsqzDPa8sA8jlqcezsNo YR9J50nDeQTy+HSewvLoj0qKuuktp2OAMVZrAdXsBHvAUvEIdK9ShSZtI/hp8hzYviry/HYk8H3k uR0c0qpoYidGTrUoPA/lBHE4hjR4OT4bOeLSDzWDNZOl4zWTBmtQLaSlk3ArSgZMAVMYbtjDo5My 139SobuIMt8Pg8+HFz4mLEU+vFS5WuXQVdkdnpGlDgVuTnoz+my2mKpGNV71B5WoyHP42eo59tmO 5eoLTRea79Hda9hoelz3uOE14TX7nx0f2D9wHJF/4n+yW63YyzsFt9Vpc9q9DpXGrnPovKXOsc61 9g2yyuEkxO5y6p1iFuckgghq0JqtsvBZfTAMjUbJ1td2a7CmjytR9JLg2uDEm5xbncT5FFcCM77x CUz0vj58o5KFxH9MscyzrLCssvCWPqxSLHRFXEhW5G6Za5c3y0R2Po1/AqpmYUXJngem7iqygTwP zsth8i0so9P/FLgFGMgHlGubdLRmYLLU1vlD26TjbQPSAJBxYLCts6Z2sHObSJfvyQ0a/Lxmn4ag ts7W+FGT2V5lMldhCFVESlfZcYXzRieUtxpq1kjCFXsMe4qSuLOrDbXheDyO4pgLlCFUVhoJ5oiq YHl5STGdvKgiqkBxeXkF99i8k0dALMr3/WbRpkjYue93Dx1MTnj4p1F4wXmzGl1YGDoRxmPwXX+4 6uGLOne/8k7PkiW/3zl0rFIqKoCpT0h9JBiF5SiEiTJG40vgBElwCf8dxo2+B4wPmHcZnzTr1D5s s+MruN9aL7HdyK2z3cvd4Xqce5rT6DkDT7zjwC0TEmrJFHKDWSjsJG6Mn0J9XNMu+W4h18PhPnJ4 J6hCCUt93OidG7I2ZZGsPi6hJLI15HGwdXGx9PhWE/abak3E5FIiOKKpkR3Y6PA7iEOflUVmOMaH Fy1kFI+3dU2iFP+hq3PSwPFOIPhg5/G245/WDnx9fABLA8cHpNeKknWXKrLVLepVYVdEF7GFRbem AOmtcFM7hQKstWcBE8XjlL7wu+oq3NmGujrbsCUYoVQm1myzraS4vMIu8kE5GikrNYdKiu2QVVFe wb/l94/69P41f79i5cBd175+qX/x0LGnh7buXrcL1z5764Y8szvbpROWD5Xs27V26J3DfUPf9XQ+ mr3z0Z+fOvkGnv70OJvFnaR+ah5YuzuEiagElyu1StkSz8We3yX/4Hg8+XTySJl6prND7FCtUq/S dIvdqg3qDRpNyO/2BnLCfnc8EFQrkkRmqAMGg1/jVqv6Uv1KgOaoAoT4RbfKI7kJDhqMRm8Jeihe iAqkAlLQR95WAvn5cZjeQ1735x6PV615XK0WH69VrVIRpJJUU1Qc9PWp0sz6Wln4eH7cX5CApue5 Hpfdivuwm3NPay7rKNtcxpUhSbRYyAxJbzTSO10nKScc0tO2IZYZctHM0H2lR3bjNUzgALVrBukN VrBt4Hjb0cEf4m1tAzWMc6SvpcEaiIbaaiBhrkqANKKcIg18jaTv4zgTx+NF4KngNmwK0PUoMQUj UVi2gCnbZiuhqwZ5wDJ0scrLTKXRSDBYFqArCynw5vMujJaK4bDBYD5rxtB7Um7lpxcsTY4anXvR ia+Sybhsd4WmJ3mrMWotKc49RyCDnwcLLxzKXegJ5g6Nnh21y4lRVww9HrZLykKu8ypfbnjob8ub rfRQEZWAWL6E7sihF5QVAbZCAYVSIKDkljkD802LytV+NwnkOPxucyDH6XfjQFDjd5sCQbOJEKwG MUcp6lRT4jl52tSZo+lQd6uPqLmUGifVzep2NTdP3a/er+bUPK2mZjRW96V+3EHbQmJI8TJwzJc7 At2BIwEuGWgOtAe4/sD+AJn/IbBRW2cXcBL82jo7u0D60wUB+tfWxBlx6T1sTVOQETBNQmswRyVa Tdl2G3ACuWTw6eT0iCNL689PJklD0bSIM0srx5PhcLhIvow7b0nAaXaw9MnbWJpSqDv1ES+AtKkk sxSn+fZ8bMRGouOQkc9FMSE+BU8hGlN1H25U9pdXlrs4Nz/PMc85zzXPLQpZggHl9VfzF+ouzLrQ sNLY4evwdyQ6kmvV1+nWZK0xXGtcE3+Uf7REMmeVZJVmlXlLvKXeMirQCnjZJ/tjsYKSUeCR1/JJ Z9KX9CcDI0tHlo3LGpc3XTcza5Y0MzYz7vVjP3GX+Mvc5dMd053TXa3Fc0vmls4tm1s+u8LA6XQx i84dC+rk6hGxZHWXucuyNnSX6q7ExuSjif7cF/JeifdXH6vOnqyudKMVxL0V78MEr8IZeahkld1d 5HF7V/jdPt9TXppT6rw7Ow+orzdk6/WGuD7PwEc0LBKDeBAhMbeIC+ZSOYkVX04pxn6Qjn04qEgJ 0/MmctiEZdNW02ETZ+oja570P+6LS1QPQgX/pkL8fOG3halCrlAZW6YU7oMHDhXKhcnC/kK+8Bnc iKpwIzi3aU3WFu8Eydp1nKqvrsGuqkQcWHKglrImVVqY3tYYCuOGK6Q9DiQNS1uWasNSJ6SZ3C0P JVWW3IguX1OCYsZICQ5Z4KZKwqO2QF+CdPr8eFTKK8FGQywvbA6WIHVCLMEgjaUaqSZ9w8NiGaRy W12LolmoW5y1RFoY59ta20A1xlEnagPrU9HrHMYqPmmsKoEAXcRbsSlYSECEWylMfSDpxGBONJJW naYSHwH5AJo0GglFQKqXp4U61aFhc9vjc5deHx/1xXPrm759ZkSp/yWX06sKh10tO8+74uaK6ujQ g7dOPPLH8y6ttLsCWpDv8TWbz141dVRJ0xWLz79t6t2HNUItqM+3brm5/drZxYvzfS9deMP0W94u c/oTFPmjQNr3MtnwT6V6Np5NZntn+5bj5WS5d7lPnQjUBqYE7hLudD8qPOxWEez12fxuKZAD0sEY CKocQeQnklEd6CP9ikWD40ixG2rNRuiuGW1FPOojuYpLrWECWcNkr4YJZE2O3eaP+6h+MNAWyCf5 5vk2+3jfUyQX2VJfKzoqK2xMiNig9yfkRW1pQX0cKL8b+VL923VltIPtOmMpEDh+VEpL8ONsZZCi K4MwXPQpEyODIEiw9BrVxJiaMZa0hA5S2VFSckqyUHkCy2Lh7zdGdBb/kunPuyNTEoMvJGeGbA/M yy2doIpIwsShF6eHqitOHL/CnxcOl8pdvN5gOW8uHkW/jBqfGuDWcltRMRrJjd9GqDWlyLVM5tYq lBZWt6owrNbpyIwwo0cY6UvAIVF0ZjOZUWKjVeD50A5KBEgcV6yUdiWsbkmVisWqgkJKP1kDTQpL kI+P5SdL9YoGOtUrXi+9m6BI35d6R/HRSno9v8qBHSzXwWo4pLBPVZPPowRw1B6Qu6DcKMT3Jgap JfhOfC9OwAODfX//wXh8j/TOXiqI3coKnWddCTFPK8dm2V/VXfuoZpeWM8fNV6ArSq5D63Xry0Sv 2VYt1XbX8hrPRGGi2CA35EysVmrXetVag0pGOeNxk3a8bnxZU0Vd9fiRs3RLdKs112qv1Rmn266x EX/tvFrSri5BpTWFsYLSp7Eb6ZE+1b9LU6XP1VXp6dxd1WWSvllPFLi16zmZRSv1vL7G0Zd6X4np qqY45jlWOLiEYxXYbFf6wdaDGSdrlBoC0+4o6AYbogzo1sc1KiZeV9hfgAvaw6gkS68vLQXCn4QV EGeUPI2XoBAK0zcaqlDYH+4O94R5JXwsTLrDOCzRSuGnSR24PFZApL/K2oeXKD53oqpIpRiqZFWz qlvFSSp8TIWbVVhVN6ruN2nx1tnVFQeDcSAuDYLW66JWSI2Uvn5oA+V3fPBomzTQWTvQBfIvbqqi deLxRNpC387pMdjnIAip8V7F5NzYshGeoGCpqCyvJKJGrVUTMZAj5xCxTFclI5PX4kFmi9Gf5cE5 wRFClQdVqktlXFaqM3skDzbkwK1arPEgZgxRkceEXzyel5d3FUi+LtyJOkHUgZxr2V5rxm2tuC2O ukDo7SiCmQIij2yXWLTLUFUhw9z7Up9v19PoiKLTVTlkcM0geCjaXboqLSxlRS6NtRBrIdZArGFC 8/RfK8wzLKpAaoJ8BAOqgvkdoPft2ek8JjPB/WLWFrW/rDQ/aoI2IHQhi4y9MVQ+ct5vfbE3vp41 rTYcIYlIONG76bLJIzxmrd0o6a01HYuLqvGd+VPqZ1ZOvPZ8k/PqZXVF9ZfMDK1dnJOTX11YXFow syfmHxNfPfTaNSOyVVk1lXfU34rbapz57VXj5lF52pg6yk0Azg/g77ereTzM+8QlMvtTZDJQZPwr 2sJGjao90BEgAQDzTsr0AS9w6w5LNpkBidd3UWngLeKAPYH14m21ewYwZca94Im5t5mDlAUuyCso RcG6rLZye9YsgXgs0/lpwjRxuqrF3eJRLRFWCt2oO7DD/bK8Xz6CPhE0FXgsnumY4ZkXbHe0e1Y6 ujzrzDdZekw9jofxg2Rr8An8An5V9arzC/VRz5fycewQyQTzLPN6/3q5O3gsqDLJ+JnUESRD8MNi Iy+izJOUArgdzDqCAlJAZoZdR6AnsDnQG6D23ZHAsUBWYLH3MBhWr9rCGhVM7/3t2VU0UirNVTBJ XeBNvx5P0W/QE31CQkmkoHbUgXpQL+pHR5CGZhC05QLXNS7S7MKbXNjVh/WK+ZiIkSiJspgUFVEQ 63LqdpOb08YD9cXaujoHO9uOdnZRsyEerx0Y6GRsd9Sc5iFFO8270HuBl7vVi6kvDFxUWVmJK6nr 1Ya7ELAbBTeSHFVuwOwuS5UgSVWYKh6Jorp/m5QGK463tuJOLALsSFkpYt5wWslH00jNTuOSmxB+ /5p7Psd4x5o/FeWP8Jl0weCoRSOn3r92weSKUjx350tYPPw+NmyYFElErCv9vgkL7n/wRF3hpTD7 +tRRsFNvAvVaQJoy2IokmEUfEx0MVOo0wBjYkOy1aZkG1clUiZgonmQ9BZrMakPujwqDpOygLWTP U9w/kJcKWXjy+s193D8UyaJoDGSGJRuFYeHy8zmmLWoPxgcSEHBGOxwE3dDPwAn6wZ2h7VlmaIVk HcfRpp4OL1a87V7i9eugG50N2ECcYeOp9IQRZtNYBucB7oSWyHKiMMbqsMmJM0QxUWiiKmpv3JTW VP1743FqDh5sa9tbOwCmYO1BeL97N0qk+p8YO7Y0QVlkTLywtD1xOX+5sI7vTmxN9CdUSqI7QVDC lmeNzxBmqKfH71CpxqmwnKjQjtXO1N7FP5K3OaHqTxyLE1lGcuApQLsOJFhDjTxFPlterD1Pvkze hDbJW1S7Va/k6SJqS1Q/2uyz1Fu9Udtoj89b74dmOj7fyqjmz8f5+X5O50e6gF6mysFsbbd127ba OL+tx0ZsX8WaRRjrE7mFpTR+cmyZWFdYtyq9twAaYrCrDcwX+qNbOV0wZZO9Svp+4CT+HqUjJv1d kTivjoYj6piM4jzcclVhGecJ+fLwvsJVV6G2SopwwHcn7upsA9kKkjUtRM0gREGwUrxGwyUZUWoX gmUmarxmMExereuecMeRH1+6dIpRdrjiWdhUYAzY3AW6oWOFYs3CREvDnN7z5ixpHHni5Zfx2El/ uHecSwp2nDh4/1iPKdj5Gn6/vqNqytI/v/43QPREkJfTuF6UjbzcFRlE56pt2VakNwIEkYFFBiYw DdakgrAMooEgJNHDvlQ/k5U0oZhMJkghnTtsUtE9A0J3H3bQ1iomXaGeiu9LvcdaQOL1Jyk38EU6 HRMM1PoBBFFUtYHnT2F9MN6f2NtPRW0azV5rN9oM4oiTmXTi0oNIvzG91xGiEJZUsqpXxSFVOyj9 zSpedQv/e347z9FXqWBqlBMjFM7Z2X4fzJMmYbYAezpbiAw2mmUw+H1plIPd1Z+G/f69MNa2PeAU FbOxwkgp3MFnnedoc7aj9uz3OMEpe0DFeqpsiqfKT0elrZtQqvZTFeFnEMstZdnT8gpL3aJT02I5 2zbPPtsxx6XCnEZUadR6wTpeXEtuENfo10mrvQ+Qxxw7Le+QD4x/l46Tf3EWc7uqXd0Bs1ureUH1 Z+MxFWg6Vda1hNNQPhGBTyaUaxrJWM0U/3QyXbOAdJG1lrXOjZYHNQ9q+9Q7Nb3aV8ln5Ij+uDZb vV+FkWq/inTSmNKuB4jWqxJVV/DZKGmz0qFazFXmedZV1k3Ww1beanW/zWNYwf2gQHhqXlho9L4y zlxFaTzXjemKqN5U23LdVUYbXmFbZdtg42zHs7O76WZFj5ok1RvUh9WcpFbUMBN1r/qIWlRvMVh5 tJbiistXzEmDYmg2cMggGWQDd8yADXQkGqCloc5X15TmTDDfJg121khgnLVBNAA2Gt0yogwKvNZl giUCO2mFFeykON3IBn+2s6uKuR+VlaizDde17BARJqSzlRl29Mesqd1IBW/TBav0SkFVFgQ11Ti5 Vap0RGXEdnf6yZ0uyzxp00/a9JOGPSkGTZVVclY5ZVNVFgQmCs6wsFpbWy2iPbO3mNZgZqrBwoFI 2kv9O160aM3s1QV+6+t3PfTVP3fd/crgGvyoIDkXlk+7hox488ILF16SvfYjjD/4Cqve2FLdEqpU rgJ7aApC3GXCDShO1BnuDhcwfVWgULVTwHwiN3hlBhGrDTGsps/YDLT+UjFTBjWYGeszJWUQqXrS gE7SqkNhnx0hY8zYh93bzaIaJWoH+qX+2r0D0kBaKYFK6pf2SK/Qaw/bPcow8m5kZG0QNFW8MTEE PaljmDEiFikHYkIZmQ3jfUXHuJHlw/Pfn6RFBkNB/rAKOkhv8Pq9e+m+BGXHUevljdaNEa6eq9eP c67mVuuFu3mcKFgV6BF7VJvUmzT3SfeZegs0kghyal7evDjxqA07fOpbcvAOn6qPUyv+oG+T73kf 8ZlCYTuON4PjksyLmU2iWqWVAOB9+KwnNoCz0kd+2I7z4n1YUrJyY9hsNEm3GI04RMH6RHt7KYur q9NxbW06DhWxWLF5AqU9BkwhPs/QYeg37DeIBmf+U5zIqTLbL2lQThoA6DKvpAaiT9uOdjF/uqZm sKumdhC8kgTdnwP9Yw5Hs22RsDUStuV6UDQ75MEZrUNVDd3LBiPpNHeb7oQGy0rAfGf2O7OY0gYT WO3WEit+2BMeNW3wYCx3jHP79padnee2VJf67CUT/P5IoeL5mps4+HB3Tn4olFu/gMweV7P2uYvq Cyp9ZYHzLZaiJe+NGUfPoUYONXIHwCYfgcajVu5O5WqzrfnOyMZyDhVIc8jKvJXTCMoTC8Wz1st8 bcWUOSsqLop0zNnAbxCusV/r2FC2btQ1DRuarptyu/12x8YpffxuYYd9h+O10tea+ufsn3NkzrE5 bpdsLZHKssv9c4RH1BPKa93IxpUHJriRs+6XryI0Fku2Rg0OozlMfXsz6KEwXY5sfS2NwfnX1W4K bw0/H+bCffi+nS3x7gAG1+CQkkXrmjcFtgaeD3CBTBsWQ5MA1FUcPRPwBHreNEGBrAn5lHUmNGfj 7D6sViwr1HiVGhIm6EZdJm6sw3V9XJGid07QJpy42dntJM5nyV+RCMw1CdVAkVZUOafiqfn5xknP cUnQdz64V6FJXFLxS0m8IrkhuSnJJR1Uvyb1lCWSZVWFXPd0PJ3OLQu4FRKv75CyWeIQ86OnU6dP mwWMND3sz8W5DIN2V+mGXDwltyO3P3d/Lp9roDWh6PgOyvKQ+EYxU4GRe5E8JzlHmbMZaC7MoU09 On3pHMOGOxpxI/PAG4tkGzbaOmz7QNj3pb5TTGwPSU8NAxsbo62PPKtYNtbi2qIk18yRZg4jTuII R0np9JayGHrl6OupmUwTT9I5cufOnvMUvgT8Ou22tY54/If0NnUX+OUsMRDvOirFO39gD/EuKv3j ndJRsN3aukAiZZTC4KdURdRKA3SfG6yMLonWh8qgJXbsCxwOENATXccHwCiL05zw4TDkdFHGy5zQ nTqlG/b3L2uaVd0QKvN47Q4sRMLFRSVFpUWcODoyJVIYzovMDE/3YM8Inwc1lU2S0RhcK6ORQq0H NRdM8qCz4tNlXO9o9OAZ0VkePHOWt9oN1d0j0MSiCTJumlBWrpA6me4T8jUePDkx1YOmxabKqMFe 50FMgwzvjWZuw2dX6V8eMP5VbNugjSq7TqbaFG2hBBgtk8x0n+DYNnNmh3R45xP0DjtGBT0UzPhQ zIW3s4uVULeKbgPAxVrh9MYq20SNRrB4+hM8l02fvXfzNe0vxg2cKHDG+MWVex6qH5vvDyQ9HX8Z 2bZi2T0nXljdpDOVqeaVxquwdcKi+tLmiQsaSoZ+TCSrFz2747GS0rs/wpNjt7Zev0cRRI3dpRXE cR3du7IjVdkmWcVzgiar46zOhbfMKi53OMJjNAv9Rf7g2WTNysvumzWm67JNs8ecvKqkJZwMjVo1 rtRm40HpoywQTv8Cb66cbMjoRm+lQhlX0pq0TBFqHSH67GDboA56lkJ5wkH3UpiH5zBQkDoiVFv6 aUYkUFoWLcABXq8nMwKsj0CBg/ZR0Jf6eQfNhcQPO2hBwTCPQeJrxciUMuuvAIMXNloLqtYMIQwh F0IUlYLiNZYpGmhbVo6iJm8+rwJYJxLUFwSt+/XXAMqMP8iMVmnPK8XSnng6Zy84iHtO8w1bSs2U JcvYHd4YLYVOaZemqJapXy1TuVqmlrUOluVgWQ6W5XBUVuAAyw6w7ADLDsBsjjFpA4nvdtACSJx8 kpYVFFRWZLQ2U9qZ9F5qdMEswI3cm95Hw3SHM1Gp5JVpK9vBbjaGjZHuyp5Kvreyv3J/JRcXcXNl e2UHzVIqsax2xHymPs6omHIKYr7ohBxtzCdNCAZivkgfZ1AKg2XRwtGlvrJ6LEfLEZslmFUmk6R1 OkKaHi3u1WKjtkO7SbtPy2upkAoXoECo0F/QXNBe0FHAdxf0FJDeAkwPTPsL9hfwBe0VD6+iG+LU oKSW5WA6pseVcMFcakxVVcwxTB+egajIdnkEtRh2RzyC04NVapfKS9Uz3d1jZ81d9PSykxqD2MSO 89l2GrBcRlezU7f0mQVzDSE3c5aZ8RjxpBVXj57c4bYYtEllaJRVKdZy/vpk0bIJ1qrGoeqRwWyH 0e+yJgzYLNw0uOCyhplzlS1Dz8ySHZ5QKBqRJuP6O85OlE4Z8pxd6A+FLNrKmdzItPdId9Vr4KYC ftGhHJLZVd+NQqAIvBTO5iwG96wA28kIOCiyAxYHpwENwmQ5JI4w4GuoF8jOIvpSf9lFa2uyHMMS HxL/2JFhtyPD7PbeTsZtMt0OsU8JrAisAjWcswJ4uF3EIrNkmddOOxBzRAtYg++BUN/bJh1sy+yQ pHfR9wJLgMyM008pTnFClsx4IMDutJ8dTU2ZxOjR6YTirKgQZyh0q2uzSOhLEZIDOSoLnd4Pioe2 1GhCwSzGD1mEwj6L8QOdWZofHJTxGf9AzpNpFgoFT+OBtI8JYz+4t3ZveqM5wwrOnhBuD3WEekKb Q8dCghxqDhGF3kJUYRYXl7K4sjodFyTTcTDMYqXQ6SoFBrFMyMmK+czAFlHnaNkXqNc79ZYemEoV Qjl6lcWs7dFgTRXVwdvrymikGGvLuOV6fZYzK+RQ4lUOtudfXl3a48DNDtzu6HD0ODY7jjkEx/bg 9gcYO9BhD1AeANU7kDZTQfPS0/oMM7Ap0f06cNlwF2A9s1FH9YjlFK4zR/QZXMfyRozIy6sZcaWz aPRQXV2hW6PyuTy5Bpwt3EQLavLyRgwFBuWZVQBkV80MPP/2fNlpDHUAQkYCao2AWiu+eRizdlgy htlsPfurR+bzsFNzLFIRjfVUdFEwQeJLJrX1w7DUU/BSNELi0E7aRi88C+JZDUGFLABQnSWbyehs K2RQ2Vx8yiVKr/Me6hWdJomjFoa8bLYBZ4FmCKky3lDaD2J7cnRQaSDp04qDJdJA0uvttjOEaS3b h6PYebLH3m8/ZufszAFpLKWxUl01ohTbt2ctKm+2Y8XebG+3d9h77Juhokof86km5OCYT4wGs6NZ oy2+7HoYkkrUIhzK0me6SR//lI0o7dHjZj1u13foe/Sb9cf0gn677TQopEVibc0viw9mCPNJ2Nqf ud7Dy/1bZ+nYodraQpfB73DlmrBJuOnE6JmVXra2nPK7sWmJhJEJITEJnsUs7u2MBre3Mg3eyvxa u4ktrWnGxOSwrk3SBaXLR3MUI13jZJzVihdVNA7XahyuRXOUAK3VOHrsaFZvNAPKaAaU0ROz6dsm DrebOKzbJw53AImfFSetO1FLu5kYZ83jrHm8gp050owKiTaroGeF7OS1wkM7rmCGBa1aQVg5+w6k wsT6MLE+TPSAJ92HnMzsKb+Y7kPOY/vN4DMrOlpVJpnyk4BRugdtcyaKG8ZRoSqPnT5DoXUSM/CU GStmrJrBzZgpji1yhPN1qpp8QcXO/BPU1GhrAyk62E9/w7YGBd1/JjNQpzbqHinO4leY5D21EaDU QPfQu04lqKbPmKlyFI01McSbZLYpLceZYRFnefGK0expNHsaPRHm8eWT6W3qlgpqmtHsirSNxhLf sdKKipaJVAPRzInDHASJH1npxImtLRnGMZ26SzByFmAKiM15b20t9SEAvb1ZTdNbnkeNqc9RA4QE hGTq850uh9MBBlH61+pWPKWq/a3f2rhugHgrtWDiWbinFQwVOeZz9JGTO3IqYr4iSCi6nIkx39gJ OaaYzw62yo5gPOZL9nFZO4KjY75GSCijgjOik0ZP982oV8cqJilVsVw1UoXHzpxFFyacr9fqVCIv qMY2FiUddm2r3e6STKFAUsYdcq9M5D5cphgrYoXxUGWyAndU9FaQCppnmzRrdGjiRP+k5kmke1LP JIImSZPIJODrXdm20kntLa19ZPYTAbBy+vCi1fH45OPU36qZJNFtNGrrHE1HNZMbzqmn5/v0V8v+ TQJa1dZkPg+pQqesoGE7KCekN2aFg5GQPuDBBmOOIXy6HQRmUByzjQqweJgZ9H8xhirKM98gUWtI Zf9FjpzKVp1mJZ2hTUpw8yJzwdKSmZdbl9zUNL4zYMvSlo8cqrGMCNi1vDs6s2z5REKs1Y1DRROr dEIgf0p52bQCZ1HT0IjaYhfTPFEjzo6TrxcZI3mL5l3S1DSj+vKhlTNlGxhNdiloasbrOgqVsnG6 +FATs6RCIdNZkFekePMrhqyzy92hkHvEDHz2nfmBjJbSgy/yb5BkJeSUJCtjkizJHI0idjeojbYg FQmF9CnoDcXUTCRlvvhi8kBtYy5L5ssNdtZkGxZPtuFPGmzUq4/Q6jbkZY29rCMv68IbYx5LjDkj Mco87ICLMg+tGhsWcjEq27S0RQx5SChJBYmmSKFHV0XFWc+BQpQg5KR9GEUTMoaKVa58wmRJIsEc Fgk8F9OZXku8/zT5IVEBIqUdl1/ExtkJG9vxYHsKRSzNBlCU7t8YUjPtqWaSQs2khtrGjrRsLMum plk2W1kp8rKaXpbhZYVeNlF26jUsLmJUmNAasVhZ6f/WgQGzrboMPBh1GeX/ZFlzWXtZR1lPmVDA Y4Wlu+Gpt0zsLdtfRnrLcDtk9JdxXrUt5jOmnZlYzBeakKOO+QwTgt6YL5h2ZoqieaOTvqJ6DwoW l7AZh4JBo9GgtdtCqh417lVjo7pDvUm9T82rqTPjjpV4Q3n+WHOsPdYR47tjPbHeGIdiUozE2KY6 MHysvTTt0MT/9w6N2eHkRD7s5OweLIgOwTXMxvQTrU74R09wmT/zP3ozwJGnZ/5iBJTgpvtvaTpP thl0RWOGRliUEi0/etLFK3UGyojZjUXgyWT4cODFppk1lw9dOsvvZH6McQq++IrOq4e8bTYvcNrY RXj6Q+NclM8ICO2j3G7gMyPyEn2G0zxgBjKLjm1y69lZl16iHwfpXTzlHVpIE4qFZvKsGm8Pq3VS GKU1Y/qzgLSL8cuBlYaW03ou2thNMeXisxnisvUSs+AkZr7xzA6gSZ736fXpgyemiii4QBeh4a3t BnO3FT9i22V7Gb+m2eP9QCOaP9PicZoG2yzranyDZq3xA7fKrxSX8ezAaZMfv2J9zUUUPx6vHh6N maeLHjfraqcAFHm8n96b+Xa+g+/he3mR/1pPNzEV/SY90Z86a6HfyVBnN97Umzutqbd56uxtet/4 bX5+/FmzW56lXwYhHoI/1U9VYF3LM8jFFSMeZXPFX0hfuE97BO3QmpkQ/TAQe81hQ4SEPRFtWIyY jNky8mKXjG0aSDlUkLJkSTJ2c3Cz6uwycgpwSx/5n/qxL2MAa4A6XNeimC4iF4mXaS8zXGa+xHaR 4yKPuq21Lf1toMYjmarcEKx080uX3vyibgjb/s5sbZWX2+kOeLY5s4lF0P4rl6/ct2rfZUuueHNa 2fIxm66ef+W5Y7mt963Z+tuT3Q+t/+OVP108uva+y/88dGjzS8dvaAenI/XT0ATuKcBaFFWRnAzW YiPY92fF2jwa0S0WustkcSKZi1mYDLbI7PMzme4XDdtrTO6yTwiymGHH5cbNvEF00eMYO3U5wPwo DBvKW0VVlElhxKQwwoBOkLBguQ0wgctUciItaPv7pVdAsCbO+GJgNypOndxJgVispZhkx/5a7Yhq GB3DrYXJSIuc1gEiHdQ3ipsZazLUyhUNUYSdBhiMjo6GDoCudK2Uloz41Inq/syRapyi+krtCIrW Kmm8NEdaa+Kvy8cj8mtHNOXPyV9mWpZ/gfpS06X516ofUn2h/kmTlRzRUtJael4pr4zACTWXGzNb wKxyXpdjAeMqGkTRwJSoD9UTczyX4wulckxHQlR0TE6HobjIr+3RknZtt3arltN+JRML/R7ALcvN 9FOg7gCmn9CkP5sRAu3VLzZlnBn68TlIRfohCxWH1Ku1n/JqOYNE7Z/0nxgkylRZ6nBpRB9JhstU xTJOZMGtRFMu4yJdofyrPzFge7MAQS5cYh0+hklvsUaHDZgS22n7PEJaYNJPJTOGDsGuyNgNU9bN 7by+Y8uE8txie1XTkOysiFqsUtDnCONSjeH8aYtGTZ2rtCQTIa6q671L55937TsDv1tlNRYMfXF2 iS8cxjZd0SJuQWvSYVg1tGVFsLpl8uLdf+2c7DCj9F4peRKwnIt3Dn8lkMeQLPrtpigzIaIOP844 XKf7J/5h68M/bDf4KWbY2YCfuU9+Zmj4mV/CKmKJc9icTwO4HSgCcDZMia6Iropy0VyVQ88BpPZS P2QAvJD/sB3o/o505kZnkHYXgbYrNKs0RAMdOEQYKYOzifkZdIw/Mzj7qd9GBTNNsJNGvz8v9ovK h/7ZSWPbKU3vVlaAkW0sJsVGhSjGq3mVkofn5WE/xSKz6q8LRqPy6IgvWo+0ujxTtixh3kH/LKlK 0mN9K8chFdjt80SsiFgs9OfhPGQK+f1+GXfLPTJBsgR2fL+8Xxbk9tjDp75bTFviXUc705ss0kDX QJspbXFXodM2W7pAC4N4s5YPfxE1bBvbT20hVpzufE+84NKKcaWh4Cyr2VqQtGSNGTUUb8xxaoWs oMsf1WIrt/Uvf6nLj5Y3ZMfOHho/MQoqNmRjVu/CzSM9VM0CXrJT/yQ1/AvIjQeHz529ihmW2ctO n3V6ZmLqrRYsWFjSwkBgGd5jt1DUMHFIxRCzfi06db7Rls3TA2f63yHW7h3cvzcxsCez/gdBniXi e093L5329KkTu1tPS7vBZ2aWnWs44aReNNuA6dBhndGNredm4/HZmL1O8WAR3q1zY4GJP4GZiwJD kGBJG8giGynDDiR+Zt6lxeL1nGYusq9Hagf3t7X1S3ulPW3DO2EgDty7URYMYLS+ah6eR0itd6Np o/N56/O2PufnTtUmL17rwlP0U7Lm6edlfe8AW8vqiDo4m9XhdHGY3rLdmzFnTWZGyyUJwaK+jA7a ts962PqtlbOek+1+E+n68NdKvgzAK0x4e73EizDmeSGU3WzB3RaMLJKl19Jv2W85YhEt7Z7H1g4L v8H0R7Ft7M/ZAIBgGA4epbCTBqDoKAboIQhmYAl21ARSrYvtZJdYg6Zs9mVDCfvKKUJPnMvp0RGe 8N57JbmBUaZosLu+sCXv5ooLCuwx/oWhtxsH/9Q6Kpa7YGHJvIVkacB27rjIORRVBKy3Qe42FCbJ DKpsUeYlqTObeDo5N7PnkZElsi+jQ48qFqY6Xayiy8z2V8zDcDMPa1tIHGebzebQsHI1OMKiTjY4 RG++Qaei33PspMpVrUWJg3H6zQEwXK008HVmnzm9/UG/xztNBs1SpT904dRanaxzGEJhO/Sa7lKH 1WyXT5ve5WP7frKL7fm5mHhyaZnlaFarIzJDniym9z0iZrpPSauYh/eWaYJhz2yORk7f2YCbxDwq euunQKwFEDIhBrKUfcVUhqPUVZGj7dGOaG+UL9VV+Kvlcf5xsuBSW6ZQ3RqY4gtHg+ooHq3yqetl Xdir7sMNikWLwmGnk83HoNVpdboA+8jOgHoxNuIOvAnvwzxmBytmpws81GZLj4V0w63XwlHQyRnY AegiL646U8bRP5wcrAH0UV9kIO2PSMxtPCXlQOtKbo/R5DG6PEgyuSWvBzFXhH5uh9viw1uN6a/p hnEIMk9VFsigE56iZdxCY8DmjxqGvilYeXnDpM58T8U4PLq1Nn5+U9Vs7rbBdzexb+he7B7TekM3 3ji62I3Dg7/rbi6fSFSTK0iYevJDjdxxwGjxKZsvW6OJ53HokiiOes1iNjsfyQYzbZeJJU00SViS 0GQxSxZDchsS6bdxA/Gv4apN7G1j5tsv/oVPE0febBO5rBgXI7OIxOBl9B3G7OwShEpLMk4EmIBt e2C1D7btZ0YXcGiv1DQdbHZ36kfkTB1DLjCEtVJm6+oxDT0dNsRvjxFLaaFtUfk1wmqRaDSCWe1U uzTxbFdEEzKHXJF4JS43l7nHmpdqlmrPdS52LXQvzb9Efan2UufFrgvdl+Sv1a513oXu0tzpuiP+ NNpf+okY1GjU8Xh+Xp4Wq4kPW5zZPgvKL/Yhs9bkM0fUstPlSuZps6FCfjwe0qizgXLQJM+l4bXq fIidWo1aHbSYzRgjMcq+rYLRRhPBKq+x1G53Oen3Fu4NWnxYe4waeR3ab8HIu6JWM0UzT8NprgC4 GhRv/D2jjI3yJtDcG+bl40R+bT7Jd5aU/oFud9GtrrauSUfbOo8OHm+jX4wNZra4Jg0ejafhd+ov n9Tpv3xaYyh0xCGm2teBpAEs9f/nXSWpa9Q16S3wOP0r3tZWC/3rOXpabrEway5C/55OFEE/Y/G0 7+opPitwhB6mR/X4MWtBQeDwXpNKnRPHeeFch8Y5tL5869QREyuSgapcrW9saPTQk8aAU7KXcLeF o95ow1Ax/jmWa9bossJh3hEw1J78zerr6/PzSmzGUa2byBP+wqBe0qP0fzHMIeTe8tPOecaa72HJ 2X8Y8/uPvS/SePe7O3NPXDh4g4TUBnjUQP30f0pM/0vewFADmiWhExcORaRf/rPizE9cJ1bRv01P /8fFLGxBR7l6tJpHKAzhPHELGidWoSbciaZC2XQIhZB/M38NyHuEfgPP0yC+mVQhDvInQDgGIR/C NAgyhAUQWiBMhHA5hKlQtxfCTbSP4cDdiOaqzkbzhVeRJMxEORAmQDrIf4zy+AtQANLj6DO8r4Tz ojxI50BZTOWFuq+mPqHlUC+H1ZsJ7S5A3VA+Cp51EMyqG5EbYiMEC+S7oJ9H6ZghbuJeoHNNfQvp lTCO8ZA+AXEjjLUe4omQPwXSIyFkQZsaUpVaCGkTpEcCbUyQ1kNogHY/0TZQPwvGuAjKs+GZ0Lrw 3iyI3bQu9Bnj/obd+G50P/c3tI2fjrKh3MACzJvOeXhOdPx0TP9DaKTjOz2kx8cCHSv5ZWz/Eciv wjlcCVurqzJzvYfsRR3c5tR3kA6K2aiBBtXfkA/m9zWEKn4Rcqq8qc9hjOOFHagMntUQHCzQPu9B 13HHkQJlcfEOwM0iNIoUQUFZ6mfyW+QVw2gszBfojaIw9laKPcBCCOpNY+0XIR//CXJBWqEBUP/p KToBbWDtmyCuA7p/o0apAeijjgboZzeEF6C9Hd6foDSg645nDj0Gdb+AsoshXAAYcUKwQ/l6hmFo Q9vDe0bTd6TXAUkMgxAo9iAUD4fM+gwH3XBg9N/Cgg2CHUIFBPreOyA8DWEyhNtoHejXBvV9MI4r KWYoNik+KDYY/gFPDLN0HS8A2lCMpXnmIbIYXQ8hG0K+iNB1mZAHdRm/0HWkY6a8QPum2KKYGY6h PJLGPf6WzpNi6rQ4KOSzdzMepNg6LY5R7NOYU9gcYqQflVPMpmk9HLMxNFB+pDwxHA+Ph/In4xGI ueXIQmlH1304HqbFqXgzCkPZROEDNJYvQrO4lwH/cyHdDHEF0Oc+xoPf8rejo2Q1Iqp+lA9rSXl3 46/iu2hQvYuXQX/9QMsIvxdtZPG7JId/FwvCY6kvhMfIlekwnD49/nXA/ekyGtNwetn/1/z/P4G8 JzyGFkP6S+HdVIp/F91CtYTqK5yEIA/HkL8dQjeEPHUc36VejvtUM5AEuDkOYQWvoGpBQRU8WKO8 lfFdGPJnQN8JfjkaAe043I/WcjPQ78XHUCn3LqwjvIu8h66hgfYPcccpHP0ac/+JJRYP4/X/ElMe yBqOGU9VpQ4xvqpKHWY8WZUaSseoiuoGKp+ZfkBMNpuG8XoKl/eiCPf9afj8FU5Pw+cIaCf9Gpen xQYaZ3RL1jCfQhsb1TV0/kw+zmT8xOQclG0frv/r+FT7LaiPbEkdYHJ4L5o9zNcQiiCEofyljBwB OQzrTXXmjam54sWpudyE1FyY5y5xDcTfpZ4g0dS2Uzo1jIozssw1rEspnYS9yHNKj4bRlIw8C1N9 yj8KOjytRy1Mf36GHMJ3TLYVs/FSPqQ8mAC5FwU9/kPqZ96MfsOtBZMF+JLmA0am0jJejazcRyBz J6ALuftSb3M3MxnUwA2hVi4OPAxtgWYOgSCPUI+aoA1i/dE6ENM8On6RB3xSWTAOnmGthuUyXXvx Z5QFISp8A/JoJtTZwuYaZnL8LhSidGBtLwK9An2p4sjMExTP1AmzNueDvcDoATLwNFpkdPMo2qd4 FsOskbUpSf2sNqMqGoSHUTm8P8zeNQ5Vq6tQRJiZ+obZFWY0mXsVJblxyA9pF8P9GtBRMdCX40A/ QuA+hjAE2JTSz0xXszj1E9P3q5g+1wsJNIvZE7RMRD4xhgpp4INQ1o4KuIehnxWAq58h/adUitkH B5GJvhvyGzP2CbUTCOOXt6Dda6iA8hgdA9M3dDx3A972IT/ViarfAw21lAcxBnp7MnrQDM8E4g2n hZ5M3v9p72yAm7quPH7uu0+yjJAlDKEOxjxLssCO5NgR5SOxgiUjQ0De2ASWWG5a2RgnTUjGZmXT SRdi2C7ZpC2FDWySkgS7NFCmxrX8BMQYNnjbSTthG2Bnd7K7WTaQNJ2d/SzNB510Dd7/vZKMLcwY WnZmZ0eC3znv3HPux7vvvnvvA/tpdkIzu/KPtFb61tBF5U2lT3lzZIPYB/L3KMJfx/XrIztvwPr9 FtbGCqzhK9FX56ien8GxA+n7wCbs/drJqlppPf8QcV742pDvHZSxH37Bs8hzHvpHdD8/TY/zIewP PhR7BLKrHdBfBkFayg7TBuVz2mBciDW5YuQ1Wb6gfeRLkv1YNz9M5k0i25piojY/jb3dBO2VbR3b TtHGCdonyhDlynyIUVWyEo2cB66EvrpK2UE9oFt5D7F/QE+zQyOD7FVaxn4JXk3SSw9I3Q9W4R5b wDaDu9UF9AbYhmMP9JugL2HTXvBPYDvK/ivouFG+nJWRUoXxDI20feBl8Ncp31hEXROlj8WQPzI4 zj6KtQawT3EOn473yTq30ULUt1C9f2RQwP8VawgwdtKMrE00g89D+hzkS7MN+ZjnjlLRZO2ZDHaW ymUfJvDfzDneLOLeFevz7SrvZsH17QRflm34L8zHcgxRDnt35Dz0WvYu1u0OzKUAdins6an+TF0n pO+W6WnXD2MFj6kjv0lPT7fTr+tkthKnyFhS42B0PLxASwRqJeJBum16m5YIjG/B99b1tvqDSWjA HmWvaBPG4LzrbWMtzRMoRWjrLJEH9xwYtc9iXgUiVua3YL0E8t4FyhGsxWDUvwBzPhjTrwtFv/K9 CX/q+qSuS/r1Qfv86hnQgP3sGSqHXg0dSOnR8Z2cL8aN+VWJ8T5qi7nkl2kx1+6Ja/cG7pUblfn/ Cdw7p8HPwE//t+tihLEKbEDuUSvwDL4Ae8+14p9qrvycaHgG9HSsC7jzhi/i+O9wvE58Qw6O30Da y9DPQWOqGb6K9BGsIxx6nzoL+3ei5wDKuNqWyHvlMvhaoowrJ4j++x+StCfyD38bLIMPO7PhI+AQ +BEIIk+qnD+HvRH6J7CXJ8oaxvGVD8CfgRB4KaGHvwmEPxt1/L3Yj0zwHHpb9Y2eP25WJ58zfCl9 3TPEreiKm9LjnjlS138ynXqWmEDLfki23zimPTd6xhmnMX6yx4K9tFPsKcU+Wuxlxf5Z7B9HtXhu e0Dq6clyUtoq1kCxdxb7V8N8+e+N4hnIPeZ5sDq1boydW9mntA/YQH5Sb0DM53jWOYO1yYo59TOc 3+sCubaJdQ2gvWel/92RUyIG+h3YBdCfpda01Nx63Rw7yZp2u+1bXSN/hzXVmySSxo3SUyxOskKQ vhbfKpOt3b/zWn6DNXrsOv372ql1PsVk+9Lr9gGT2JOVd6t2+r7jlu20fUnKTuc6f/rYS+1nZuEZ OEXafXeriGcL9ei1vX+qDen38ej9lnpG6MSaOgbMA8VYs0rAfswX5aAA5IIXkPaMaZi8pl7ywj4K jiHtP6HXCx90F9uBye3yyBXYfwLbpr4jY+uTrJ9sPKePW7E/l/tD9JmcB3eJ9lMZqAC5oB88lbrW 4tkTdf+LcpJIPOeqDSOfqWdA2h5wUr2ANoJe2FbY1uR/GG26/SjLfn/wFC0xvDAe45GbIxt7GLG8 3So5VxNMewTbqLuJ8nKIZqFe7S4iRwORy3aNuf9B5MZ4KZtDdA/2PV9cm2DhswkW4/m+Yut4lizJ kCFDhgwZMmTIkCFDhgwZMmTIkCFDhgwZMmT4PwETv1lEH5OPNlEWKWSjMvG/74bT1unESRmkNSND /IN4dbXXPwDtvltqvbjEe1w49FmzvX/JP1AO0zzx5gp+QZ+ZLz3v61VVyYOFixMH8btKvRcCU/j7 9Cug8Pf5BSpO5IoX3+29FLAggfFnyMoYadTN/5liQCE/fy9eNNfbdYr/HP7T/G1aL7O9rVumeVHg z/gblEsaP8aPJj1H4znTvBSI8h04wSHIc+AiuARUauU/oE6wE/QBlayQGigDtSKF9/AetPMA8lsh y0Ar2AlUWsN/iPQNQvJD/AlyIO+3+R66A/pbfLfUr0PPgt6P9DnQ34MtdFfSfgVa+Pcm078Leyb0 y0n9EtLzoV+ELfRfJO1NvEPma0/qbh7V52i2wBz4C0E54Djag6M96Lo94tfRIBn/Bn9S1tQP7YV+ KqHRXVt0u1Neoy3xL9zp7UaXbkHXb0HPbUHPbRHvJeGbUzGbEzGlfDNiNiNmM2I2o1fKeRT1RcUP nkDaQCHg6Pco+l2kxyCHwDmZ/qeQu0C3sPjX0I8laNXz/Am9WMMgeyx+r99beYI/iq7280fjdxZ4 d16zsqeIgQidk9RWEdsivS3x7KkitSU+qyChEbUhkMOb6Y+BQjMgi8AXQRCovFkvKtMG+YP0lIn8 OVqn0sk71U6DWh5kuae4l+pMhCGZy0vJh4ASLeJjixqz27K3ZnNbdmF2ebY/uy7b0Mo7+U7ONV7G K3ktj3CDeBdk1n3zxe9ZLjfeN3+XudscMw+Zz5kNMeOQ8ZzxovGS0ZD46pc6Y6OxzbjVuMvYbcwW 71lXGs1t5q1mbjMXmsvNfnOd2aBlse7Adr5O3LaQNtAGdgEVfRxBeiH/CojgakTQFV8RP70KSbBs 4ByOL0IbYFkRZ0WcFalWpFpJfOutVXrqQCNoS3qNo55UHhF/SXiA+OH/HKTmoG8vQl4SR2AlLAss CywLos4pw2ihDbIQ1AEu0y4CjBrIlK886W8ERum/JGNSPr/Iqwz7m+YNlbBYCesuYbtKmN9XGfD6 HRC5ubkRZ8QVKY4cUFudra7W4tYDaq2z1lVbXHtArXRWuiqLKw+oZc4yV1lx2QFVc2ourVg7oO6s 6as5VXO2Ro3UtNZ01vBF4n2NurvcK7XDJfRR/c5Z3kXWQIXSh9OJQHaBC4CTBlkGKkErUJU+SE3p RWovUnupFkSAATl6xfQCqSV9Ir1L+sSR8Cvj/Bwnfli/b35tYCWm3AjoAhxlH4b/sIxOHPXJ9Bjk RZlem4zvlukaZCoPxwTXIKe5Btx+DVQJIqANGOgsf5guAJQMqYE20AdU3oA/D/OHlV78Oawc5h6/ 5Z47NJo5k4hyp5lsAZsyFWPAwg5J+bKUz0tZKWWRP2el5fJKy5srLc+utMzDgVJMATj2SGn3mwOW IwFLbcBSErCgtC+QnSzKHVIahWT/LuWDUnr8M+yWz+2WT+yWX9str9ktG+2W++0i32zcuxZlhpRm IdmLUq6Ucq7frFl+qlke1iyLNEvAwvYx1E5VUs6RMl9I9vERa9BK2SfYxxRESUz3lWgDCknFRnRf AOqq7lsOdUX37YP6re7brZ1knzO5pLHLetFHWuAO9ilboQr7k6T+NVtBPdCXoB+DPkg+5oJ+Xfdt E/HfR/69sPeTwyTiv0d1Ml8XWyHTX0vme1X3rEOtr+iep1HrXvLIWl/SPR8hdbfueR7qBd3zJNRO 3SUa+ITuu0sLTBNfD6eI2GZyKaIlNckaH0DJT0IvT2Su1j0iV1BUMMCW6s57oOaJVp5kTqqT1Wm6 U55kATllEbPJKRudTy6pc5hVNt5CDqlNunMbSjEecX2k/cZ3Qpw4fcas+j7tFydxfmthfshW6D3a 3xwX3aVrZz0DzHVMO+M8ob1VNMDW6tqQZ8AExynPgMKOav3o5BhiFXZM6/M8pvU6pfeAE15c6i5f qfaKs0H7rgu2rm3znBTNoKdwxmvhDnuWaDW+Hm2Za4DB7fehMv8U7T7nH2n3InnxAFsR79HuKRoQ TSlHGT3HtLtQ41ynbMofLhpUFlAW6/B7stqz1mWtzVqVVZE1P6s0qzCrIGt21gxTrslmyjFNNU0x mUxGk2pSTGSaId6I7pbvfTHKX/02qkKq8timyFd3JH5JXGEmBfdObDoPKaHVVSyWG6LQmqrYIndo IGvkodhidyhmqvtSfT9j3wnDiinPDTBaU48BKpK258dyxddPMla2fUe+0Ju37wiHWSg21EyhdYWx y6txHlNWNcQMzqo8mrmpMq8yd8m0e5cFJxCNSTnmhfl57rGfvILYi6HV9bEfFoRjXnEwUhAOxZav Lnyk/riyUWmtDh5X2oQK1x9nX1c2Vj8k0tnXg+HRMHIobQgjn1AiLE4OEUYOFpdhNTIMw9RRHex3 OBJBP2YrRBCGz49l0GOJsopQBcqqEwphyhwqkmUVKXNEGMZDojDr2MKmErPKwqxTSRY2WwT1u1wI 8bhESP8iFwL6XYuku+ea2+lKNCdMLlmPi4VlPYxdiylOxGAUJGMUE2Lct/PTUnULwSzedH59c3WL s7rRWd0CGmPf2vTVvNjWdYWF/evPC0dhjM9tXNf8VaGbWmLnnS3B2HpnsLC/qXkCd7NwNzmD/dRc vaa+v9nfEtSb/E3VzqZgOH6wc2loXF3Pj9a1tHOCwjpFYUtFXQdDE7hDwn1Q1BUSdYVEXQf9B2Vd oYeqWKiuvt9EVeGljyR0XDFPwf3QmG8PV820tS2RN0eFPe+Z/EGVsGyZ3eHYVGdVzAKEqzRQGhAu 8TNlcOUg2Zp05T1TYc8fZIeSLhuSpzmryE151Y8HR/9Go9F2QUeHG7K9I0+mteOmta8OxZataqiP +WK+6pi/MRiWLzfqSH6W1vttp3xnfUqrr9O309fl6/MZOjrCSM495TjrUCKOVkenY6ejy9HnMArH I/XH/L4ux68cvAOjibXjUx2UdXZA468w2zui4kOoIAoS1bk73EvrAw5q5uKL7DnkdOAE88FqYKCf QP4t+AX4BKj0Dcjd4PsgLlJ4KS+tzns8KGoMu8Wkk8e98fIF3sUD0E2PJvTqhoSufjChfQFvHrRe OX9KwIqNN6NByNPgPfBv4LfAwL3cKwvvSIzacJSibobmi7cRtgsRdbfL74hiorvbo243ReWbopDQ HpXvzx4/7olFOwhdgQsChSCZGhXZOoS+Fvg/xssarA1lbmRzdHJlYW0NZW5kb2JqDTEwMCAwIG9i ag08PCAvSGVpZ2h0IDk1IC9CaXRzUGVyQ29tcG9uZW50IDggL1N1YnR5cGUgL0ltYWdlIC9MZW5n dGggNDAgL1dpZHRoIDE1MCAvVHlwZSAvWE9iamVjdCAvRmlsdGVyIC9GbGF0ZURlY29kZSAvQ29s b3JTcGFjZSAxNSAwIFINPj4Nc3RyZWFtCmje7MExAQAAAMKg9U9tB2+gAAAAAAAAAAAAAAAAAIDf BBgAN6oAAQoNZW5kc3RyZWFtDWVuZG9iag0xMDEgMCBvYmoNPDwgL1R5cGUgL0VuY29kaW5nIC9E aWZmZXJlbmNlcw1bIDMyIC9zcGFjZQ1dDT4+DWVuZG9iag0xMDIgMCBvYmoNPDwgL1N1YmplY3Qg KDJuZCBJRUVFIEludGVybmF0aW9uYWwgQ29uZmVyZW5jZSBvbiBDbG91ZCBDb21wdXRpbmcgVGVj aG5vbG9neSBhbmQgU2NpZW5jZSkgL01vZERhdGUgKEQ6MjAxMTAyMDEwNzU5NDYtMDUnKSAvQXV0 aG9yIChaaGkgTGksIFl1ZWJpbiBCYWksIEh1aXlvbmcgWmhhbmcsIFlhbyBNYSkgL1RpdGxlIChB ZmZpbml0eS1Bd2FyZSBEeW5hbWljIFBpbm5pbmcgU2NoZWR1bGluZyBmb3IgVmlydHVhbCBNYWNo aW5lcykgL0tleXdvcmRzICgpIC9Qcm9kdWNlciAoaVRleHRTaGFycCA0LjAuNyBcKGJhc2VkIG9u IGlUZXh0IDIuMC43XCkpIC9DcmVhdGlvbkRhdGUgKEQ6MjAxMDExMDIxODU3MTMtMDcnMDAnKQ0+ Pg1lbmRvYmoNMTAzIDAgb2JqDTw8IC9GaWx0ZXIgL0ZsYXRlRGVjb2RlIC9MZW5ndGggMTQ3MQ0+ Pg1zdHJlYW0KSImMV82O2zYQvu9T8CgCWUGkKIlqT0nTBi0adIF120PTg9byX2NLjiVtsG+RR+7M N5QsZzduYcDSkMPhzDe/Wvxy8+Pi5s3iJoltYq1afL4xSZx4ldBP3jIXJ4n1Xrk8iQufZ0YtDjd/ RUt966OqaVptXdQzoSp+3fMr/rAjbL02ebQ6Mx2PJ00M+N+BY5KyYlYV9lt+4DC42kYRX2yjdg1Z 2qZE/HDHDL8Tp2J2XNPx8YHJpTYZC82I/W+1GA2+JeMSTxYvyXZjMrE9Ni4l+369goIrY5u7JBcU SA+Ts0KaBNroRHfTQ610HvvoMWyuwvPE+vroKZDq3UBqxX7a70RIP+7/Jvz3sqzYrp0uaKWZrXTt QS6VO9USj0o4unErXBCrxZaQBIadgieq46Qeo37JLwqMZDPpJwJGLSzhxjd68JBJxSXWc6izzPgA tfHli1CncVlaQjot4tJnWSZIV2vN8tc7iYBmB7IX6kmzJrdYqvD/WWf5RJy0+EG9lRdhb2bsB9kI wpfYV3dC7WbcjU4tLwm1EUrdg5JTW1lbgaixMcjS/qtTndz50rFhrx3Ik3aC8ddwOoEzTfPiPyJ3 hNPmscvTkL0fIp2a2EUAxEV37GgHAF10j39Wy5Fa/L7Ce433Af9sCynsyBgmP2ihYvWnvKxEIGU7 yB0EHOQy5LAB8E4cSGs9HOYokXhVtQ9suIv+CYKWPaHFjN+JQPXmJAy7Wp4bCso0zsWDjvyExybc 2G8v1bqAU5BMsjKdkLxeAkiR0pk8lIBurDkHzQWxlzSlioTSpzacZdVRPfATfOD4rF04hr9GvaPT w8TT6cBHRYArgGUsm1r9wYLfM/n+FWWllRqYSnmUu1E5maMeqPaZsLVRgkjV8IHyhYgKMJTl/4yn hJA0JTeNMT0lOZGa8Gv0dMuQaI9sxMsJjUAd8ADPFup6iq7UcrxwdRup43iCGR5JcXa3j+QW/iOv l4inCB4myczUV3yGIfzYoZswAwI2Wre8wBBBBTAGj1kOPiIh+KUIydL8xQYZAElLE/syL4oAyEM7 9KFLuXmPqtC71lNTa3aTEk8TP8g2uBv+/l690bcF5c2J7ZCT/EYQUCaXEnIN/224XEdqOErUKGnR j6G5ZtScgcml/401V43zVGsKl9pzzCO8t4jWepg6f1CMffNKc3y+JdY7vvb2Xk5MMc5VbgIBaRJC uhsjWAGG7Xk4EEBmYEopCbNIoB6k2x/PqjRyH0S2wO8r803hs6vm5z721LmCb4cmCG/OxojwBvmY 0aQiSpxV/dKNA8ogx2Z2q08Dxp5BDtVP/Giqg55XEsTqfi9xQvuxgPWT5EfK/ftZThuJXEuJetW8 rIhTW7rg3X7LzdWQl6m0GqQhPQb8o5WaSJbaOdvqlbZgRyU3aBpErcUpO1DhdCePXrZQInGgmC1K yTZSsol+r0s0DSwuw6Z0IYO8d9HrGvrUc0VX3Xil2CKNz1ANZabX3LiYVK0ICtq+lP42S+z1BkFo eltYlTqa6pKi9AInqlgrGTOOwRwMHQKxDnRqxc3TSHzE3IsJOEy966m8H86LfUhDzmkkSrPZn6ft aVzm7Vk1CcGz0FNCcuBV4Ftf5vFOehZtPD2bomeNw9j0WyEmoKSkCX0+OAGFZyGuxqHAh2oc+sau 1aG6qV0XLCNi3429AH1iyayf0DZJX54HohW3B2q13AqCcF5V5+7guDt4RGD0URqD3LDCfbz3oPkD hkGpBWYCuX1eNMTsPPtm4RCzrY2L6aNJ0n8GvpS5Ch8pHwF5i8lgP00G9UZ8018WT6h+tZXwobMX wdlK4xs/yMI31azyhmLtaRK89LIfZyNzdWZPDQ2VNLOHyL8fewTp8rzaq+X05Xf+aJSkqKQJv+YV VNCfQctX4SOLgxzOHZOE2osB69xB0ZI6ZFw8NSJAd5xAxC31rGUp+KO5ADs0S/WvAAMADMtYpw1l bmRzdHJlYW0NZW5kb2JqDTEwNCAwIG9iag08PCAvVHlwZSAvRW5jb2RpbmcgL0RpZmZlcmVuY2Vz DVsgMiAvZzM1MzMgL2cxODYyIC9nMTg2OSAvZzE4MjkgL2czNjI3IC9nOTYzIC9nMTQ4MiAvZzE0 ODggL2cxNDg0IC9nMTQ5OSAvZzU0MiAvZzE4MjcgL2cxODQ4IC9nMTgzMyAvZzE4NTUgL2cxODQw IC9nMTgzMCAvZzE4NDIgL2cxODQ3IC9nMTg2MSAvZzE4NTYgL2cxODY0IC9nMTg1NyAvZzU4MSAv ZzMzOTggL2c1NjAgL2c1OTYgL2cxNjY2IC9nNTU5IC9nNTc2IC9zcGFjZSAvZzM0MTAgL2cxODQ2 IC9nMTgzNCAvZzE4NDQgL2cxODMxIC9nMTg0NSAvZzE4NDEgL3BhcmVubGVmdCAvcGFyZW5yaWdo dCAvZzE4MzggL3BsdXMgL2NvbW1hIDQ4IC96ZXJvIC9vbmUgL3R3byA2MCAvbGVzcyAvZXF1YWwg L2dyZWF0ZXIgNjUgL0EgNjcgL0MgL0QgL0UgNzEgL0cgL0ggL0kgNzYgL0wgL00gL04gL08gL1Ag ODIgL1IgL1MgL1QgL1UgL1YgOTUgL3VuZGVyc2NvcmUgOTcgL2EgL2IgL2MgL2QgL2UgL2YgL2cg L2ggL2kgL2ogMTA4IC9sIDExMCAvbiAvbyAvcCAvcSAxMTUgL3MgL3QgL3UgL3YgL3cgL3ggL3kg MTIzIC9icmFjZWxlZnQgL2JhciAvYnJhY2VyaWdodCAxMzEgL2VsbGlwc2lzDV0NPj4NZW5kb2Jq DTEwNSAwIG9iag08PCAvSGVpZ2h0IDIyNSAvQml0c1BlckNvbXBvbmVudCA4IC9TdWJ0eXBlIC9J bWFnZSAvTGVuZ3RoIDI1Njk2IC9XaWR0aCAzNzIgL0NvbG9yU3BhY2UgL0RldmljZUdyYXkgL0Zp bHRlciAvRENURGVjb2RlIC9UeXBlIC9YT2JqZWN0DT4+DXN0cmVhbQr/2P/gABBKRklGAAECAQEs ASwAAP/hDOFFeGlmAABNTQAqAAAACAAHARIAAwAAAAEAAQAAARoABQAAAAEAAABiARsABQAAAAEA AABqASgAAwAAAAEAAgAAATEAAgAAABQAAAByATIAAgAAABQAAACGh2kABAAAAAEAAACcAAAAyAAA ASwAAAABAAABLAAAAAFBZG9iZSBQaG90b3Nob3AgNy4wADIwMDc6MDM6MTUgMTU6MDk6MzEAAAAA A6ABAAMAAAAB//8AAKACAAQAAAABAAABdKADAAQAAAABAAAA4QAAAAAAAAAGAQMAAwAAAAEABgAA ARoABQAAAAEAAAEWARsABQAAAAEAAAEeASgAAwAAAAEAAgAAAgEABAAAAAEAAAEmAgIABAAAAAEA AAuzAAAAAAAAAEgAAAABAAAASAAAAAH/2P/gABBKRklGAAECAQBIAEgAAP/tAAxBZG9iZV9DTQAD /+4ADkFkb2JlAGSAAAAAAf/bAIQADAgICAkIDAkJDBELCgsRFQ8MDA8VGBMTFRMTGBEMDAwMDAwR DAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAENCwsNDg0QDg4QFA4ODhQUDg4ODhQRDAwMDAwR EQwMDAwMDBEMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwM/8AAEQgATQCAAwEiAAIRAQMRAf/d AAQACP/EAT8AAAEFAQEBAQEBAAAAAAAAAAMAAQIEBQYHCAkKCwEAAQUBAQEBAQEAAAAAAAAAAQAC AwQFBgcICQoLEAABBAEDAgQCBQcGCAUDDDMBAAIRAwQhEjEFQVFhEyJxgTIGFJGhsUIjJBVSwWIz NHKC0UMHJZJT8OHxY3M1FqKygyZEk1RkRcKjdDYX0lXiZfKzhMPTdePzRieUpIW0lcTU5PSltcXV 5fVWZnaGlqa2xtbm9jdHV2d3h5ent8fX5/cRAAICAQIEBAMEBQYHBwYFNQEAAhEDITESBEFRYXEi EwUygZEUobFCI8FS0fAzJGLhcoKSQ1MVY3M08SUGFqKygwcmNcLSRJNUoxdkRVU2dGXi8rOEw9N1 4/NGlKSFtJXE1OT0pbXF1eX1VmZ2hpamtsbW5vYnN0dXZ3eHl6e3x//aAAwDAQACEQMRAD8A9Sqq qoqZTSxtVVTQyutgDWta0bWMYxvtaxrVNJJJSkkkklKSSUXPYyC9wbJDRJiSfotSUySVazqfTarT TZl0stB2mt1jQ4E/m7S7clf1Lp2O815GVTS9upZZY1pAP8lzklNlJV78/BxyG5GTVS5w3NFj2tJH 7w3FGrsrtrbZU4PreA5r2kEEHhzXBJTJJJJJSkkkklKSSSSU/wD/0PVUlnZeZkPyH4mG5lXpNDsr Ks1bXv8A5uqtm5jX5L/p+93p0s2Ps9T1GVrIx8s39V+yOyMvHc2s2OyLrq53SzYxuNWLMDbsf/o0 lPUJLPxMy9mQ3DzHMtNjS7Fyq/a20N/na3s3P9PIr+l7XbLq/wBLV/N21VVuq/XD6t9HyhidRzW0 5G0PdWGvsLGkhrX3egy30Gu3t/nvTSU7KxfrSAaOnSJjqWGf/BmonVvrX9X+jurZ1DLFb7azcytj H2u9Mf4d1eMy57KdP51/6ND6n1b6s24WBl52ZWMO/Irsw8gPIqNtW7Ir33M/Rsa30X7/AF3en/g0 lOT0jFusvznM6PiZlZ6nk7sq2xrbP533P9M41rv0X5n6b/B/mIgxr7es9cdX0jE6kPtlYNuRY1jh +pYH6La/GyPY36X0/wDCKgep/wCL/Iry+o09cy8er1t19dOVl0g23Hf+gwmGuyz1nb3/AKvS9XMq 76nZTWdc/a+TiUdXsht1GXkY1Lra6xUXWsrdVXj2NoxWsf8AaG1fzaSk+dRbZ9aMsU9Mxuo7cDD0 yHhmz9N1KPT3UZP0/wA76H0F0eIwsxaWGpuOWsaDRWQWMMa1Vua2vcxn0foLmMOz6pfWa1+X07qe UbsWium91GRk4zzVXvspfewmi2/b69v6d3+kWni9b6Fh/Vuvq4zHv6TWwRmX+rY8gv8ARa6z1Wuy nu9Z2z3MSU7KS5TO+vnT8H63noWTayvFrxg6y3ZY6z7VY9gpxGCsH/tPZ630HrRy/rn9WcLOdgZW eyvIrc1lvtea63PnYzIymMdjY7vb/hrq0lO0ksnqn1r+r/SLrMfqWazGuqqbe5jw6TW5xqY6vax3 rO3td+iq32rUre2xjbGzteA4bgWmDr7mPDXs/quSUySSSSU//9Hoetln2qkZ0/YzmW/bOY3bmejv 2/8Amt9D0v8AgvU9NTYzoh+sWQ2wY37M9D2j2ejO2n+b/wAHv+n9D3rduqe9w6p0s15VWTW11tBI 9O9kbqL6bvcxt2w+x/8ANX1fo7P8FbVjMwMhub9s/WDluMOoOGz0yNG+nu9X7I1vt/nPtX/XUlNb oE+oRi7vswzavskzExkev/I3/s3+f/sKf1PfhjO+truoOrGQOo3HJNxbIww39V9b1P8AtK2n1dm/ 9FsXR4WJkWXtzc1jKnsaW42Kw7m0h38691kN9XItj6bW7Kq/0VX+GtvF1H6r/V7qmS3L6h0+jJyG x+le0biB9Ftn+lb/ACbElOH9VrGv+u/1ode5jsh/2R+O4EHdjGt3pGn/AIPb6XrbP8IuWqqpu6Ng 0hgs6VZ9cWswa3AOpdiOL2hlLD+jdjOf63/B/wA4vRep/VX6u9W9H9oYFNxx2hlJjYWsb9GkOq2O 9Fv+h/mlZd0jpb6MbHOLV6GDYy7EqDQG1WVz6VlTG+1jq9ySnnxRQ/8AxousfW1z6+jNfW8tBLXH IfUXtd+a/wBJ3p7v9GuWY3FGD05uQKxjD61XB7bNorDZt0cH+zavTRgYQzz1EUs+2mr0DkR7/S3e r6W79z1Peue+sX1XryD0qjp2DU7Er6mMvqFRDNhY5tjcmyyu3+e9Tf8AQ2vSU0+qlh/xjUDFI9Vv Sb/t2zn05/QC3b/wvp/T/kLEzL6G/wCJShrrGNda2muoFwG54ym2OrZ+89rKrX7P+DsXb14f1Y+q PT8jMrpp6biCHZFrRq6PoNJ99tvuf+hq/wC21i9H6T9Q8/Lya6eiPxMi6tz7K8vFtpaaiQx1mMLh 9mo3bv8AtP6VqSmx/wDnT/8AaD/7uLnfq10/q/Uvqp1XAszcCmuy/Lb1UZVD3312lx9TIybzk1M9 Zmz1arbaf0Xps/0a287qX+L3ruVifbqRe1lv2fCzn02147rGk/q1OcGV49vuY7bX6noIv1lb9Q6e qss6vgMzOqOZ6zmVY777PSZ7TkZVdDXNdTW1v0sn8z+okppdM6fTV9fem417mZrsH6uVelkEBwNj L/Q+1VF2/a6xjn+/d/hF3SxcLP8Aq3kdYxvsbWnqOR01t+PY2tzT9gc9pqbuc1jWV+r/AID+cUKP rr9X8jKqorus9PItOPjZhpsGLbcC5noY+a5n2e1+5j9vv2Wf4NJTupLlelfXH7Z9ZerdOtZb9mxT QzCazFv3ya7Lct2V+jc6r3s/Qer6Hq1/zHqrYp+sPSL+iHr9d89NFbrTftcPawubZ+jj1NzXsczZ tSU//9L1OutlbG11tDGMAaxoEAAaNa0KSSSSlJJJJKUkkkkpSSSSSnC+ueH0TP6KcPrWW3p9N1jB RkueGbbxL6drn+x30X7mu/we/wCh/OLlrOp/WI39T+q7+pVfWIZPSMm6nIx6213V2bDVVVY3Gc+r 9Lu9v+F320/9c9ByMbHyqXUZNTL6XiH1WND2uHg5j5a5Cwel9M6c17On4lGG2wgvbRWyoOI4LxU1 m5JT5z1PqnScv/FJi9Pwra7M26rFxqsNhDrnZDLafXY2hk2+o/ZbZ9H3/wDXFsdHzcLpf16+sI6v dXi35NGHbjW5DgwPqrp9PI9K63a12y1v6T3f4L/gl1jOj9JrzT1CvCx2ZzpLsptTBaSRtdN4b6vu /rKWd0rpnUQ1vUMOjMbWSWC+tloaTzt9Vr9qSniurWN6t9ass9KsF7s36rXjDsrd9J1lzm1bXfm+ 9YuBgnqv1VwsXJ+t+PiYUVV/s9+Jjttpurc3bRv9WrL9Wu5v89/OX1/pn/o7V6mMTEbe3JbTWL2V +i24NG8Vzu9Ftkb/AEt3+DQP2L0f7b+0PsGN9und9q9FnrTG3d6+31d23+Ukp57oWTjVfX361VW2 srsuPTxUxzgHPIxzPptd9P6X5q5zKo2vy/8AF+wjbmdZreykaFvTrW/tS447nf8AcZ+O5r16Pb0v pl+ZXnXYlFuZSAKsl9bHWsAJLRXc5vqM27nfnLJxOhZl31rv+sXUW0M9Go4fTqave4V7tzsvIuc1 n6xb9FlVfspos9NJT//T9VSSSSUpJJJJSkkkklKSSSSUpJJJJSkkkklKSSSSUpJJJJT/AP/Z/+0R BFBob3Rvc2hvcCAzLjAAOEJJTQQEAAAAAAAHHAIAAAIAAgA4QklNBCUAAAAAABBGDPKJJrhW2rCc AaGwp5B3OEJJTQPtAAAAAAAQASwAAAABAAEBLAAAAAEAAThCSU0EJgAAAAAADgAAAAAAAAAAAAA/ gAAAOEJJTQQNAAAAAAAEAAAAHjhCSU0EGQAAAAAABAAAAB44QklNA/MAAAAAAAkAAAAAAAAAAAEA OEJJTQQKAAAAAAABAAA4QklNJxAAAAAAAAoAAQAAAAAAAAABOEJJTQP0AAAAAAASADUAAAABAC0A AAAGAAAAAAABOEJJTQP3AAAAAAAcAAD/////////////////////////////A+gAADhCSU0ECAAA AAAAEAAAAAEAAAJAAAACQAAAAAA4QklNBB4AAAAAAAQAAAAAOEJJTQQaAAAAAANFAAAABgAAAAAA AAAAAAAA4QAAAXQAAAAIAFMAdABtAHAAQwBTAF8AMwAAAAEAAAAAAAAAAAAAAAAAAAAAAAAAAQAA AAAAAAAAAAABdAAAAOEAAAAAAAAAAAAAAAAAAAAAAQAAAAAAAAAAAAAAAAAAAAAAAAAQAAAAAQAA AAAAAG51bGwAAAACAAAABmJvdW5kc09iamMAAAABAAAAAAAAUmN0MQAAAAQAAAAAVG9wIGxvbmcA AAAAAAAAAExlZnRsb25nAAAAAAAAAABCdG9tbG9uZwAAAOEAAAAAUmdodGxvbmcAAAF0AAAABnNs aWNlc1ZsTHMAAAABT2JqYwAAAAEAAAAAAAVzbGljZQAAABIAAAAHc2xpY2VJRGxvbmcAAAAAAAAA B2dyb3VwSURsb25nAAAAAAAAAAZvcmlnaW5lbnVtAAAADEVTbGljZU9yaWdpbgAAAA1hdXRvR2Vu ZXJhdGVkAAAAAFR5cGVlbnVtAAAACkVTbGljZVR5cGUAAAAASW1nIAAAAAZib3VuZHNPYmpjAAAA AQAAAAAAAFJjdDEAAAAEAAAAAFRvcCBsb25nAAAAAAAAAABMZWZ0bG9uZwAAAAAAAAAAQnRvbWxv bmcAAADhAAAAAFJnaHRsb25nAAABdAAAAAN1cmxURVhUAAAAAQAAAAAAAG51bGxURVhUAAAAAQAA AAAAAE1zZ2VURVhUAAAAAQAAAAAABmFsdFRhZ1RFWFQAAAABAAAAAAAOY2VsbFRleHRJc0hUTUxi b29sAQAAAAhjZWxsVGV4dFRFWFQAAAABAAAAAAAJaG9yekFsaWduZW51bQAAAA9FU2xpY2VIb3J6 QWxpZ24AAAAHZGVmYXVsdAAAAAl2ZXJ0QWxpZ25lbnVtAAAAD0VTbGljZVZlcnRBbGlnbgAAAAdk ZWZhdWx0AAAAC2JnQ29sb3JUeXBlZW51bQAAABFFU2xpY2VCR0NvbG9yVHlwZQAAAABOb25lAAAA CXRvcE91dHNldGxvbmcAAAAAAAAACmxlZnRPdXRzZXRsb25nAAAAAAAAAAxib3R0b21PdXRzZXRs b25nAAAAAAAAAAtyaWdodE91dHNldGxvbmcAAAAAADhCSU0EEQAAAAAAAQEAOEJJTQQUAAAAAAAE AAAAAjhCSU0EDAAAAAALzwAAAAEAAACAAAAATQAAAYAAAHOAAAALswAYAAH/2P/gABBKRklGAAEC AQBIAEgAAP/tAAxBZG9iZV9DTQAD/+4ADkFkb2JlAGSAAAAAAf/bAIQADAgICAkIDAkJDBELCgsR FQ8MDA8VGBMTFRMTGBEMDAwMDAwRDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAENCwsNDg0Q Dg4QFA4ODhQUDg4ODhQRDAwMDAwREQwMDAwMDBEMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwM /8AAEQgATQCAAwEiAAIRAQMRAf/dAAQACP/EAT8AAAEFAQEBAQEBAAAAAAAAAAMAAQIEBQYHCAkK CwEAAQUBAQEBAQEAAAAAAAAAAQACAwQFBgcICQoLEAABBAEDAgQCBQcGCAUDDDMBAAIRAwQhEjEF QVFhEyJxgTIGFJGhsUIjJBVSwWIzNHKC0UMHJZJT8OHxY3M1FqKygyZEk1RkRcKjdDYX0lXiZfKz hMPTdePzRieUpIW0lcTU5PSltcXV5fVWZnaGlqa2xtbm9jdHV2d3h5ent8fX5/cRAAICAQIEBAME BQYHBwYFNQEAAhEDITESBEFRYXEiEwUygZEUobFCI8FS0fAzJGLhcoKSQ1MVY3M08SUGFqKygwcm NcLSRJNUoxdkRVU2dGXi8rOEw9N14/NGlKSFtJXE1OT0pbXF1eX1VmZ2hpamtsbW5vYnN0dXZ3eH l6e3x//aAAwDAQACEQMRAD8A9SqqqoqZTSxtVVTQyutgDWta0bWMYxvtaxrVNJJJSkkkklKSSUXP YyC9wbJDRJiSfotSUySVazqfTarTTZl0stB2mt1jQ4E/m7S7clf1Lp2O815GVTS9upZZY1pAP8lz klNlJV78/BxyG5GTVS5w3NFj2tJH7w3FGrsrtrbZU4PreA5r2kEEHhzXBJTJJJJJSkkkklKSSSSU /wD/0PVUlnZeZkPyH4mG5lXpNDsrKs1bXv8A5uqtm5jX5L/p+93p0s2Ps9T1GVrIx8s39V+yOyMv Hc2s2OyLrq53SzYxuNWLMDbsf/o0lPUJLPxMy9mQ3DzHMtNjS7Fyq/a20N/na3s3P9PIr+l7XbLq /wBLV/N21VVuq/XD6t9HyhidRzW05G0PdWGvsLGkhrX3egy30Gu3t/nvTSU7KxfrSAaOnSJjqWGf /BmonVvrX9X+jurZ1DLFb7azcytjH2u9Mf4d1eMy57KdP51/6ND6n1b6s24WBl52ZWMO/Irsw8gP IqNtW7Ir33M/Rsa30X7/AF3en/g0lOT0jFusvznM6PiZlZ6nk7sq2xrbP533P9M41rv0X5n6b/B/ mIgxr7es9cdX0jE6kPtlYNuRY1jh+pYH6La/GyPY36X0/wDCKgep/wCL/Iry+o09cy8er1t19dOV l0g23Hf+gwmGuyz1nb3/AKvS9XMq76nZTWdc/a+TiUdXsht1GXkY1Lra6xUXWsrdVXj2NoxWsf8A aG1fzaSk+dRbZ9aMsU9Mxuo7cDD0yHhmz9N1KPT3UZP0/wA76H0F0eIwsxaWGpuOWsaDRWQWMMa1 Vua2vcxn0foLmMOz6pfWa1+X07qeUbsWium91GRk4zzVXvspfewmi2/b69v6d3+kWni9b6Fh/Vuv q4zHv6TWwRmX+rY8gv8ARa6z1Wuynu9Z2z3MSU7KS5TO+vnT8H63noWTayvFrxg6y3ZY6z7VY9gp xGCsH/tPZ630HrRy/rn9WcLOdgZWeyvIrc1lvtea63PnYzIymMdjY7vb/hrq0lO0ksnqn1r+r/SL rMfqWazGuqqbe5jw6TW5xqY6vax3rO3td+iq32rUre2xjbGzteA4bgWmDr7mPDXs/quSUySSSSU/ /9Hoetln2qkZ0/YzmW/bOY3bmejv2/8Amt9D0v8AgvU9NTYzoh+sWQ2wY37M9D2j2ejO2n+b/wAH v+n9D3rduqe9w6p0s15VWTW11tBI9O9kbqL6bvcxt2w+x/8ANX1fo7P8FbVjMwMhub9s/WDluMOo OGz0yNG+nu9X7I1vt/nPtX/XUlNboE+oRi7vswzavskzExkev/I3/s3+f/sKf1PfhjO+truoOrGQ Oo3HJNxbIww39V9b1P8AtK2n1dm/9FsXR4WJkWXtzc1jKnsaW42Kw7m0h38691kN9XItj6bW7Kq/ 0VX+GtvF1H6r/V7qmS3L6h0+jJyGx+le0biB9Ftn+lb/ACbElOH9VrGv+u/1ode5jsh/2R+O4EHd jGt3pGn/AIPb6XrbP8IuWqqpu6Ng0hgs6VZ9cWswa3AOpdiOL2hlLD+jdjOf63/B/wA4vRep/VX6 u9W9H9oYFNxx2hlJjYWsb9GkOq2O9Fv+h/mlZd0jpb6MbHOLV6GDYy7EqDQG1WVz6VlTG+1jq9yS nnxRQ/8AxousfW1z6+jNfW8tBLXHIfUXtd+a/wBJ3p7v9GuWY3FGD05uQKxjD61XB7bNorDZt0cH +zavTRgYQzz1EUs+2mr0DkR7/S3er6W79z1Peue+sX1XryD0qjp2DU7Er6mMvqFRDNhY5tjcmyyu 3+e9Tf8AQ2vSU0+qlh/xjUDFI9VvSb/t2zn05/QC3b/wvp/T/kLEzL6G/wCJShrrGNda2muoFwG5 4ym2OrZ+89rKrX7P+DsXb14f1Y+qPT8jMrpp6biCHZFrRq6PoNJ99tvuf+hq/wC21i9H6T9Q8/Ly a6eiPxMi6tz7K8vFtpaaiQx1mMLh9mo3bv8AtP6VqSmx/wDnT/8AaD/7uLnfq10/q/Uvqp1XAszc Cmuy/Lb1UZVD3312lx9TIybzk1M9Zmz1arbaf0Xps/0a287qX+L3ruVifbqRe1lv2fCzn02147rG k/q1OcGV49vuY7bX6noIv1lb9Q6eqss6vgMzOqOZ6zmVY777PSZ7TkZVdDXNdTW1v0sn8z+okppd M6fTV9fem417mZrsH6uVelkEBwNjL/Q+1VF2/a6xjn+/d/hF3SxcLP8Aq3kdYxvsbWnqOR01t+PY 2tzT9gc9pqbuc1jWV+r/AID+cUKPrr9X8jKqorus9PItOPjZhpsGLbcC5noY+a5n2e1+5j9vv2Wf 4NJTupLlelfXH7Z9ZerdOtZb9mxTQzCazFv3ya7Lct2V+jc6r3s/Qer6Hq1/zHqrYp+sPSL+iHr9 d89NFbrTftcPawubZ+jj1NzXsczZtSU//9L1OutlbG11tDGMAaxoEAAaNa0KSSSSlJJJJKUkkkkp SSSSSnC+ueH0TP6KcPrWW3p9N1jBRkueGbbxL6drn+x30X7mu/we/wCh/OLlrOp/WI39T+q7+pVf WIZPSMm6nIx6213V2bDVVVY3Gc+r9Lu9v+F320/9c9ByMbHyqXUZNTL6XiH1WND2uHg5j5a5Cwel 9M6c17On4lGG2wgvbRWyoOI4LxU1m5JT5z1PqnScv/FJi9Pwra7M26rFxqsNhDrnZDLafXY2hk2+ o/ZbZ9H3/wDXFsdHzcLpf16+sI6vdXi35NGHbjW5DgwPqrp9PI9K63a12y1v6T3f4L/gl1jOj9Jr zT1CvCx2ZzpLsptTBaSRtdN4b6vu/rKWd0rpnUQ1vUMOjMbWSWC+tloaTzt9Vr9qSniurWN6t9as s9KsF7s36rXjDsrd9J1lzm1bXfm+9YuBgnqv1VwsXJ+t+PiYUVV/s9+Jjttpurc3bRv9WrL9Wu5v 89/OX1/pn/o7V6mMTEbe3JbTWL2V+i24NG8Vzu9Ftkb/AEt3+DQP2L0f7b+0PsGN9und9q9FnrTG 3d6+31d23+Ukp57oWTjVfX361VW2srsuPTxUxzgHPIxzPptd9P6X5q5zKo2vy/8AF+wjbmdZreyk aFvTrW/tS447nf8AcZ+O5r16Pb0vpl+ZXnXYlFuZSAKsl9bHWsAJLRXc5vqM27nfnLJxOhZl31rv +sXUW0M9Go4fTqave4V7tzsvIuc1n6xb9FlVfspos9NJT//T9VSSSSUpJJJJSkkkklKSSSSUpJJJ JSkkkklKSSSSUpJJJJT/AP/ZADhCSU0EIQAAAAAAVQAAAAEBAAAADwBBAGQAbwBiAGUAIABQAGgA bwB0AG8AcwBoAG8AcAAAABMAQQBkAG8AYgBlACAAUABoAG8AdABvAHMAaABvAHAAIAA3AC4AMAAA AAEAOEJJTQQGAAAAAAAHAAYAAQABAQD/4RJIaHR0cDovL25zLmFkb2JlLmNvbS94YXAvMS4wLwA8 P3hwYWNrZXQgYmVnaW49J++7vycgaWQ9J1c1TTBNcENlaGlIenJlU3pOVGN6a2M5ZCc/Pgo8P2Fk b2JlLXhhcC1maWx0ZXJzIGVzYz0iQ1IiPz4KPHg6eGFwbWV0YSB4bWxuczp4PSdhZG9iZTpuczpt ZXRhLycgeDp4YXB0az0nWE1QIHRvb2xraXQgMi44LjItMzMsIGZyYW1ld29yayAxLjUnPgo8cmRm OlJERiB4bWxuczpyZGY9J2h0dHA6Ly93d3cudzMub3JnLzE5OTkvMDIvMjItcmRmLXN5bnRheC1u cyMnIHhtbG5zOmlYPSdodHRwOi8vbnMuYWRvYmUuY29tL2lYLzEuMC8nPgoKIDxyZGY6RGVzY3Jp cHRpb24gYWJvdXQ9J3V1aWQ6NjBhZGY5ZmEtZDM0MS0xMWRiLThhNmYtOGI4Mzg4ZTlmMDVjJwog IHhtbG5zOnhhcE1NPSdodHRwOi8vbnMuYWRvYmUuY29tL3hhcC8xLjAvbW0vJz4KICA8eGFwTU06 RG9jdW1lbnRJRD5hZG9iZTpkb2NpZDpwaG90b3Nob3A6NjBhZGY5ZjQtZDM0MS0xMWRiLThhNmYt OGI4Mzg4ZTlmMDVjPC94YXBNTTpEb2N1bWVudElEPgogPC9yZGY6RGVzY3JpcHRpb24+Cgo8L3Jk ZjpSREY+CjwveDp4YXBtZXRhPgogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAKICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIAogICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAKICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIAog ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgCiAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAKICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgIAogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAKICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIAogICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAKICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIAogICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgCiAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAKICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgIAogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg CiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAKICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIAogICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAKICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIAogICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgCiAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAKICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgIAogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgCiAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAKICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgIAogICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAKICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIAogICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgCiAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAKICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgIAogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgCiAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAKICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgIAogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAKPD94cGFja2V0IGVuZD0ndyc/Pv/uAA5BZG9iZQBkAAAAAAD/2wBDAAICAgIC AgICAgIDAgICAwQDAgIDBAUEBAQEBAUGBQUFBQUFBgYHBwgHBwYJCQoKCQkMDAwMDAwMDAwMDAwM DAz/wAALCADhAXQBAREA/90ABAAv/8QAewABAAIDAAMBAQAAAAAAAAAAAAgJBgcKAQQFAwIQAAAG AQMCAwQEBgoJDw0AAAABAgMEBQYRBwghEjETCUFRIhRhcTIVgSO0FnY4kaGx0UIzsyQXN1JicpJU lHUYGYLCc5PTNHSEJZW1JjZWV6Ky0lNE1IVmhpZHdzn/2gAIAQEAAD8Av8AAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAf/Qv8AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAf/Rv8AAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAf/Sv8AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAf/Tv8AAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAf/Uv8AAAAAAAAAAEeNrOSOG7tbn7vbVUFbaQ77Zqa1ByOXMaQiO8t3UiOOpKlGZdP4REMR5 K8xdtuLtlhtTnNNkFxOzlElVIxRQ/m1GcU0EtKk9yT1PvLQi1EdP9Ktsp/4Z7nf/AG87/wCkNk7R eoRtbvJuHj229BgmeVNrka3URLC3pnI0Ns2m1OH5rpmfaRknTX3jf3IvkLhfGbb8tyM8iWU2j+8Y 1Z5NWyT7/nSjMkH2mpJafD16iG5eqvspoRltnucaVESkqLH3dDI/Ay+L2j36v1R9mbW0q6pjbbcp p+1mR4TDrtA4htK5DiWkqUo1dCI1amLCsyyyuwjD8jzW2becq8ZrJFrPaYT3vKZjNm6skJ6aq0Lo Qrdg+rJsVZRGZ0DbzciZEkJ1Zkx6JTratPHtWhZpPT6DHtH6q+yuhn/Rlud0Iz/7Pu+z/VCwPa/c Gr3VwDFtw6WBPrKrK4SZ0KBZsnHltIUpSe15o+qT+EZ6AAAAAAAAAAAAA//Vv8AAAAAAAAAAFUnC n9c/nv8ApDA/14882T05kcBz6H/1jseiiIy8G/Ej1IWpfJxP8FZ/vE/vDyiNHQolIjtoWXgpKEkZ fh0FZHq2dOLEf9NaH+XMWKYhHjuYniy3I7S1Kp4Jmo0J/wAHR9AyH5OJ4/KskZHqXwJ/eGouRf8A ULvH+h9x+SOCNfpoNMvcMdoTdZbcNLE4iNSUn/7W79AnicOJ/grP94n94fuhKUJJCEkhKehJSWhF 9RD+gAAAAAAAAAAAAH//1r/AAAAAAAAAABVJwp/XP57/AKQwP9eMP9RtzOmuSXC53bJitk7gItLQ 8Sj3BmUBcz8V2lJMupI018Bsv709WD/uxs5/jb/743FsTO56SNwGG+QNJt1B25+RkHIkY2+65P8A nC08gkpUenafXuGnPVvNwuKjXlaG7+edF5fd4d3nK01/CPm0lp6qJUlL914zs6db93xfkDXKfJRs +Uns7i1+126a6dNRm2HWXqcry7F0Ztjm07OGrtIxZW9XyXlSk15rL5g2SM+qyRr2/SJb8iv6hd4t f+59xr/ijgqE4ZWHqDs8btuW9kqLbKZtwlmSVDIvX3m7FReevzPPSk+37fdpp7BJ9dr6sPYvtxjZ zu0Pt0lv+P4T0FkOJKyReL48vMW4rWWKrox5I1BMzjJnG2nzyZM+poJevb9AyEAAAAAAAAAAAAB/ /9e/wAAAAAAAAAAVScKf1z+e/wCkMD/XjzzZIz5k8BySRmf5x2OhF9TYtaAVgerZ+qxH/TWh/lzF jmHEZYjixGWhlUQdSP8A4OgZGNM8i/6hd4/0PuPyRwRw9MwjLhhtFqWmrM4y/wAbdE9QAAAAAAAA AAAAAB//0L/BjGV5ljOEVblxlFuxUwUakhTqvjdURa9jSC1UtR+4iEWHeQG5+4bzkPZrbh9cFS1N t5RaFoz0P7Wqu1tPT2Gagc245O27K597u5Bx0kpNx2NFJXY2RdT7lJShJERD0IFByWrmV2OIbq0m 4sWKoydjG4hwjURam2ZqJSSP6O4h92n5MXWMz4tJvRgk3EJDi/JO+ZQpcVa/7Ik9dS9pmhR/UJXV NxV3sCPaU1gxaV0pPdHmRlk42oj9xp9vvLxIfSAAAAABEbY3jJN2f3t5BbuSMvavWN7bJifFpERD YXXkzr8C3TWonDPXxIkjCeXvELLeR+WbVZnhe7Ktqr/a1Ux2rs2YRyn/AD5Ro7XWlE4jsNJJ09vi NG/5kHMo+v8An+ZJ/wA3q/3cZntzxA5V4lnuI5Nk/Na/zLHaKyal3WKvwlIbsI6D+OOtXnGRErwP UjEguYnG+Zyl2jLbKDlqMLkJuYNsm4cinLL+ZqNXZ5ZLR1Mz6HqIjt8G+YrLTLDPPnI2mI7aGWGk 1yiJLbaSShJF5/gRFoPK+D3Mo0mRc/ckJWpaf8nq95H7HyMWOZlg83L9qch27k3Rpscgxt6ikZC4 33n5z8Y2FSVN6lrqo+4y1FXuF+nbyi29xirw7DOb9xjWN06FJr6aBVqajsmtXcvsT55mWqj16mMo Lg/zJ9vPzJP+b1f7uJ/7DYDm+2W2dHh+4m4srdXK65ySqfmsxs2npKXnVONpNJqUf4tJkktT9g3E A/GRIjxGHZMp9uNGYSa3pDqiQhCS8TUpRkRF9Yw7HNytvcvt7KhxTN6PJbmnbS9a1tXOYlux0LUa UqdSytXaRmWhajNwAAAAAAAAAB//0bxNxM8ptt8Us8qu1/zeCjSNFSZeZIfV0bZQXtNRiKe3+11/ vlbJ3T3jUpyilES8TxFtxaWks92pGpJeCNC+tfifQbuz/e3b3ZuTX4xYwpbUhcEpFbV1kQzbJlKj QlJGnRCepeAhnupyUyfcSHKoKeGeLYtK+CU33d06U3/YOrLohB+1KfH3jfvDFttvBcoJtCUJ+/XO iS0L+KQJUZFjVFllVIpcjq49tWSi0diyEkoiP2KSfilRewyPUhCa2q8q4qZK1eUD0m92bu5SSua5 z8a7CWvxPppooi+yr+EXRXUTgorusySnrr2mlJm1dqwiRCko8FIWWpfhLwMh9YevLlxIEd2XOktQ 4rJdz0l9aW20F71KUZEQwGq3f2qvbH7optxccs7Q1GkoEayjOOmovYSSXqZ/UNi6lpr7B/LjjbSF uuuJabbI1LcWZJSki8TMz6EMLTuXt2qxOoTnVAqzI9DgFYxvN193Z36jNULQ4lK0KJaFlqhaT1Iy PwMjIeTMiLUz0L3mPSiWlbPdkswbCNNehKJExph1DimlH1JKySZ9p/QY+Jb5xhmPy2a+9yuop50l RJYhzJrDDqjPwIkLWRjJmnW3m0PMuJdadSSm3UGSkqSfUjIy6GRj4F9l+K4s2l7JckrKBtZkSF2E pqPrr4aeYpOo+nW2tZcxG59RYxrSE6WrUuI6h5tX1LQZkY/SZPg17Xnz5rEFn/1shxLaf2VGRD1q y7p7qvTa1FrEs6tfd22MV5DrB9hmStHEGaehl16j5MXOsKnWC6mFl1NLtGz0XXszmFvEfu7ErNX7 Qyofi/Ijxm1PSX247KOq3XVEhJfWZmRD0qq6qL2O5KpbSLbRWXlx3ZMN5DzaXWz0Wg1IMy7k+0vY Pp6kXiPnNW9S9OXWM2cV6xbQbrkBDyFPJQR6Go2yM1EWp6amQhB6lVmuv4b7u/LyPJdkx4cVXas0 q7XZTZGXwmR9SFf3otVkKPZ7/wBoTbbLjaaSGhzonRPluuGX4T6i+5DrbmpIcSsy8SSZHp+wPVsL OuqYrs61nx62EyWr0uU6llpJF11NazIiGIUm6O22STPu7H88oLmf7IcOwjuun9SErMzGeD1Js+DW xnZljNYgxGUmp6TIcS02gi6malKMiIeG7CA7BRZtzWF1rjRPonpcSbJtGXcSyc17e3TrrroMex/P cIyyZNr8Yy2oyCdWlrYRK+YzJcZIz7dVpbUoyLXp1GWgAAAAA//Ssh3DYXvJyDodvu5cjEcAaTOy OORn5S3zIlrJWnTUiNLZe4zMbO3R5CYftY63jVZC+/8AIIqEoVSQjS21DbItEk8vwT08El1GgH+W L1xLaQ/tJAuJ6y7I7RmUl80666JLy1K0/aEdty8ik5VmM27l4x+Z0h9hlpWP9nlm15aeizTon7X1 DZ2zm8+RbX41cQqnBJOUQJM9cyZbNE55bCjQkjbUaEn4EWo2W1zRs1GhS8CZU0Z/F2Sz16eJFqnx Eh8R3DwHf/FLqiJJsvSoyo9zjsvtKQySy0J1BfwkkfUlF7Rq7jXZ2uIZNnWx92+cksSeOXj8hR+M ZxWhpSXu6kovrEocxy2iwLFchzTKJya3HsXr37K4mr8G2I6DWs/pPQtCL2mOX7c3e/kZ6ie9TOAb euWNdido65+auAxpS4tfDq2laKsrl1rt7zMjJR69NdEpIbjzT0dN38LxNzLMD3HrMwzKnZOWrGY0 d2teeWgu40QpZOak5/Y92mpi2vgxhW8e2XHen/zgMzsbjIpSHLQqy6UTkigrySZphvyVGa3VJSnv Uaj+HXQhTByM5Wb5c1d74Ozey06yx3DrG0focPxyumLiHbeUs/PsrJ9oyMmkoQa+0j0Sj3mY3HI9 FnN2scO1h74w3s+Qx5xQVQ30Q1SCLu8opRO+cRGfQlGX0jT/ABQ5h7ycUd5v6Ht8LaysMDK8Rj2a 0+QPuSJOOyTX5Lc2I+53KNjU0mpOvaaD7i6kL2uXlbIyTjBvCVJdzaeajF5VnT3dVIWw+hyKj5hp bbrRkrRXZoeh9SMcyfGrf3kFgkfN8D2Oj2uS59vpHhQ25rSnpthEeb1NyUx3moicUlZpN1w9EF1E ob30qOWeT4zYbjZlmlRf52uKufIxayny5tg6pKTX5Pzxn5ZOmRaERfDr01GpePXPffjYXCMy2zok zM7k5IhMPb9Ns67NlUFoZmwomGld63kn4Ez7FpLTpqN5VPpmcvuQdKvczeHctmqym8bVOg45lL8q bN1X8SUyENqJqL3f2CS+H2jTfCvePdLjVyjxva6dazWMdtsqVhW4WDSZDj0FuQbhslJjpWZkhba9 FJUn7SehiyT1lIchGzu111FsJkNUXLvk5LUaQ6yh5qVHWRpcJtSSPQ0kZaitHYpXLfkXt7iXGPYl ybje3WCrlry7KY0lyDDcenuqeUc+YjRZ9iVdqGGz1PxMZtvD6XnITY7Dpm6VFl0bPnsdaObfxMeX MiW8ZlBdzkiMpS9XvLL4jIj7tOpCXnphc3smy+8Tx63dyN7JLCXFXN2wzCevukvtspI3a6Q4ehuL Sn4m1H10I0mNk+sXbXFZs1tc3VXNhUIn5epmemDJdjee38so+x3y1J7iI+pEftGyPSTIi4iwT6mp WW3prUZmZmfmoLUzPqZiYHKGdOrOOu9VhWTpFZYQ8QtHYVhFcNp9lxMdRpW2tOhpUR+BkKR/R8sL O15BbnTbi2n3U5eCtmubYynZTpmuwbNWq3VKProNl+ptxh3Lad3M5Ir3XX/R221Vsntj5krtcUky Y17O/wAjoo+4vh1EHeG3FHdHkxG3Ak7b7vL2rTiMmHGt2mnJbapypLanELP5ZaNSQRafELztjNvI /AzjvnuT7zbly86nwn5F9k2SyZD7pKQ0gmokKIiStaiNWmhEXitQpUYtOS3qbb5TMebyKbj+Il3T ZNSl51ukxumJfa15zTRpKRJWXQu7qpWvgkht7ez0mc92Uwax3N2o3HmZzcYk0c6zoYsddbYnGbLV 16C8w4Zm42Wquw/Ei6dRJP0wObOUbh2T/H/dm/dyO6YgKsNuMumKI5UuKx/HQZKz0NbjZfElR9TI jIxinrM1l1Ck7NXsLIraHTX7NlTXOPx5rzMKQuOSH2nXGULJKlaOGnUy8BDnEs25YcutudruL+zV fZsYttVSJgZrdMzlw4s1S1q8lyzmEZGlptr4G2SMzV1MyFvXpz8M8h4r45nljuGzVq3BzKwQz59W 8b7LVXFSXlIS4oiP43FKWovqFlQAAAAAP//TsE2YyFVVim/W8DiSftn5T7kZxX1LeSX1arT+wIVy JUyxkyLCa8qZaWrxvzJCz1U6+8fU1H9Z/sC1zZPaKh25xiC78q1Mye0ZbkXVytJKcU4tOvltmfVK Ea6ERCDHJr+ujIv+BQf5IST4bpSvBMpQtJLQd65qhRakerSNehjBeVW01JQx4242OQ01ypk1EXJo TJdrK/NLtbkJQXRKiV0PTx1EWcCyeVhWbY1k0NxTaoM1puYST08yM6okOIV7y0MTTyo0Y7yr28vo X4tjOalUeWSfBfwKSRn+wQ1V6rOaTcU4kZFWQHDaczm4rsfkOF/g77huOp/1SW9BCz0YcRiv5Rvp nTiNZNbEqsfgK/sG3O+Q6RfWaUi/kQ+565vN2/4m7x3la6tiwk051kV9H2kHOWlhRkfs+FRimv0e sTgWvIfMsilMpekYThjbdatfU23LJ7tcWn6TSgy1+kdKug5lfV4wuBR8mKa+iMIZPP8ADGn7QkFp 5j8F1ccnFfSaNC1Fpe0+ZWWd+mbDyK4kHKs17W2cKXIUeprOCw/FSZn7+1otRV76OiEK5FZCpSEq UjAj7FGRGadX2iPQ/ZqOl17+Jd/uFfuDk24Ox48nnNty3JYbkIRlt46hDiSURLbVLUhREftSZakf sMdZo5Ns+Iv9JHbFp/8AmyN+UIFqvrH/AKveB/p1C/kXR970gEILi5ZqJCUrXmdsbiyIiNRkaCI1 H7dC94tPlMNyo0mM6kltSGltOIMtSNK0mkyMvpIxx67eOJ265r42iGXyjGL7yvwYzaPh7I7k9bZI Ii06dq9NBcF6zB67O7RmXgeZK/JVDbPpKfqi1/6WXv8ALIEteV36tW+X6GW35OsUi+jd/XzuZ+gj P/SCBZx6n/6mu5n+y135UgQz9Fv/AHjyA/ylT/k6xvj1fcgdrOMlLQtL7SyvM6yNIRr9pqKl2UZH 7/iaSK8vTq5b7IcW6jdL+lJV23d5lZQXKpVTX/OJOHFYNJk4rzEGk+9R9BZG96tnER9l1lb+YGh5 CkKI6PoZKLQ9fx4o+4v5BHgc1tsL/G1riVFpuPLVTEpJIWVdYvOG02tBdEn2K0NPsFpvrPlrimwn u+/rb8mZEhfScx2nquItDeQYTbNrlt9cTb+cRF5kh1mUuM13K8TJDbZEkvYLMAAAAAAB/9SeO0lP Kstot+MBjoNV7XyH0FD0/GKUlCkEWn0m0ZCG7a1pQy4lB+YwpC/JV0PuaMjNJkfgepaC5rbnMKbO MQpryllIkMuR225TRGXew+hJE404XiSkn7xXDya/rpyP/gUH+SEleGn/AGHyn/Lzn8kgfly+zGtj 4jAwZmW09dXM1iRLhpUSnGYjB95uLIvs9xkRFr4iBVHUSshv6KigtqelW9jHYaQnx6uEaj+oiLUT qzpH3jya2dx6KrzVYtWG/N7epoSlClan9ZaDRnq5Y7NuOKZ20RhTzeKZTVWU80Fr2MGpbKln7iI3 C1MRl9F7Ia9D+/uJreSm1ckVNwwwZ/EuOppbKlEXuSoiI/rF74hZ6heJ2GY8Qt4q6sbW9Lg1iLNL KC7lKTDdQ6siL+5IzFQPo8ZPCrOQ2b0D76G38wwtp6vQo9DcVXvka0p95kleo6URzX+sPkVfYcis HpY7qVycUwhSrUiP+LVMkrcbJXuM0p1FjGxVBPxz0vIMCyjriy3ts7maphwtFEiWiS+2ZkfvQsj/ AAitj0c/1icj/QI/yhodLb38S7/cK/cHJ5wX/Xp27/Sm/wD3ZY6xxyb5/wD/ANI7b/8Adcb8oQLV PWP/AFe8D/TqF/IujIPSBIy4tTz06HmVvp/fIFp77qGGXnnFdrbKFLWo/YSSMzMcfeDNHuFzhozh fzpvI96X5cdbfxkthmetfeWniXajXUW9esx02d2kL/5zV+SqG2PSTMv80WB16llt7r/tqBLXleZF xq3zNRkkiwy26mehf73WKRvRt/r43M/QRn/pBAs49T/9TXcz/Za78qQIZ+i3/vHkD/lKn/J1je3q /Y87Z8ZqK+aQaixTM62TIURa6NSkOxT1P2fE4kQz9Lrj7sJvxju7zW7m31bnF5jVxAKpXOcfSuPD kRjMyQTLrfQ1pPqevUWr/wCjy4Yf+AVB/t07/wB5H28a4LcS8OyGmyvGdk6WoyHHpTc2mtGXZprY kNHqhxJKkKSZkfvIxX76z3/ZTYT/AC9bfkzIlD6Vv6mG33+U7z/pF4WKAAAAAAD/1bJZUpOzvJlb 7qiYxbdhgjeWro23KUokrMzPoWjpEr6lGPx3c4rSrm6mZNt1LjRXLV1T9rj00zQz5quqnI7iSPt7 j8UmWg1niO0HJXAZj8zEmG6lcg/52yicy5HfMuhG40su0z9x6ajTW6is2Vm9h/SKcf8AO4o8cp5R uzy/L7fxX8X8Oug2RsyjfZ3HLlnaZ2K3TKnqKzW6pgnUyjQnU0G6RmXw6DzL45b6X1rJsriujyrG xc75trMsEOLUfvWZEZ6F7CISY2g2BqdqG5GcZvPj2WR17DrrchvUolewlJms2+7qpZkXVR/gGNbC pkbjbtbibyuRTbpVn90Y2twviNKTIlGn6kEWv1iQ28m19JvRtfm+1+QqU1VZpVP1z0lv7bK3E/in k/ShZEr8A5caadv/AOm5yBclzqZsrGG0utkKltufcuUUhuEslR5Ohdqj7SURkfc2vootBP8Azj1o quTiLzG3G0E2BnMtg22pl/NYcrYTyi08ztj/AIx8kn1Ii7dfaJc8ANwOQu+uzmXO8ksbVLxzIHn0 Yjlk1lMKRcV85KkyGjgkRdrLeujbhkXcR+3TUU4bxbObxenfyHodxccilOxmstpFjtxlvlOLrZkF 81JeqrE0F+Kc8tZoNJn16LRqLAV+tHtz+aHzLez+Qfn0cfQqhUuL92FJ7dNfnNe42+7r9ju0Ffmx +ye7/qE8gbTcTMozzuG2Ny1M3TzJKVR4TMNrq3UVxmXxr8tJNkSfsp1Uo9R0bb+VVfQ8a906WqjI hVdRgtlDrojZaIaYYgrbbQkvclJEQoa9HJaFciskSlRGosCPUvqkNajpde/iXf7hX7g5OeCzrZ86 tu0Esu48pvtE/wCNmOsscmefuo/0ktqXd1PeuMen/GEELWPWQ1/zesEIvE85haf7S6KuuLnK/fzi Ji0LJ6rFFZbsDmVvKJ6vmoUmL95MGSJRRJzZK+Wf6Fq24Xarx0EguQXq45TuZg1lhO0+EObZOX8d US8y2fNamzW47qe11uC20hKULURmXerXQvAtRtD0s+GeQV9+xyS3NoJFJEr4q4+01HPQbcl05Cfx 1q42rRSUqSfa13ERnqavcJb+qhs7l26vHWLZ4VTPX9vtxeM38ypipNyS5AS2puUplsiM1qQkyUaS 66EengKp+DPqDMcWKK82+zDFZeX7e21k5bV8iqcbTYVkt5JJkINl00k42s0kempKSY23vVzN3k5/ XUbjhxvwSZj+K5EZOZE7MdIpsyOyZLUqwfbM2ocRKklqWpqWrQtfYNX+mHl9ptpy7ewyXj9jYPZT X2GJ5EzBjqfXWSYb/mJfkkn+LZQ6ypC1q0IiURi73njttkm63FfdTEsRgLtciVBbn1lW31ckKhOp eU22ReKjSk+0vafQUJcCOZ2O8Scjz+JnWN2NvjGbojHNVWpT9410+ASmzS5HdUjuSoj0MtSNJkLu 9vd3dmPUe2Z3cw+FSWsDFEulQ2KbRLbUtLrrJPxpjKW1L7DQstU6nrqkUUR3OSfpq75vS3YPkIfN UUpMltblDllOhzVBk8noh0i6+JLbVr00FiLfrU4B9xJdd2SyD85/K+OAiyiHC83TrpIMu7t1/tNR mvCLlby35Lb1XmRZHgsWJx/fhOxzcYYOLEqpKD7o/wAtLeLzJrq/Bwi+EvH4dBhfrQLSjE9gzWfb /wAvW3X/AIsyJQ+lWpK+F+3xpPUvvO96/wDxF4WLAAAAAAD/1rpN49roG6mIyaZxSYlzDM5OPW2n xR5SS6dS69qvBRfvDTmy+9UqvmK2m3XSdBmGPkmJBs5jmjc5CfhQk1q0+PTTQ9dFF9IzTeDfCx25 ntUNHhFjk1rMhfNxrBCVFBb1UaSJxaSUozLTXQiFcl+jM8ovLTIrqosZNrcPnImOpiPJTqfRKEF2 9EpLoRDPNqc63A2ntpM2qxmfaVVn2lcUTzDzaXTR9lxtfYfY4kj0100MvEWP7d7ixc9xV3KHqebi rMZ95iXEtUk0tHkkRqXqehdnXoYjDuTuHd765EW0W1Ti14ypxKcyzFpJm15ZK+JCVdC8stPHX4j6 F0EusIw+pwLF6jFaVBpg1TJNpcV9pxfitxWntUepmMrHwb/FsZyyImBlOO1mSQUKNaIVpEZltJUZ aakh5Ky10+ga5qOO+w1BOVZU2zmG109au85bVNDJwlEeuqT8o+0/qG4UIQ2hLbaEttoSSW0JLQkk XQiIi6FoPn29LT5BAeq76qh3VZJIikV05huQwvTqXc24lST/AAkNEFxH4xlbfff9BWG/eXf5nnfd bHZ3a66+V2+X/wCSN8VNNUUMFmro6qHTVkfX5evgsNx2Ea+Pa22SUl+Ah7cqLGmx34kyO3KiyUKb kRnkkttxCi0UlSVEZGRl4kYx2lwfDMbkqmY7iVNQy1t+SuVXwY8Zw29dew1tISfb08NRlGnTQ/b4 jEYG32CVU9u1rMKoq60ZWpxmxi18Zp9C169ykuIbJRGep6nqMvGHubfYG9Zqu3cKonblT5SlWy66 Mck3y8HTdNvv7+n2tdRV36x36veB/p1C/kXR73pL09TfcTLarvKuJc1kjMrb5ivnMokML+JH2m3C Uk/2BYNV8fdi6SzeuajZ/Dq60fV3uTmKaGhzu111SZNfCevu0G3koShKUISSUIIkpSRaERF0IiIh 5MtSMvEj8SMR1y/iRxnz22VeZZsnitrbOGZuz/kUsOOGZ6mpzyPLJZmfiatTG0MF2w262xr/ALq2 8wmlw2AaSS4xUw2oxuEXUvMUhJKXp71GY9mi29wbF8gybKscxKppMkzN1t/KruFFbZkz3GkkhCpD iEkazIi9vifU+ozIaMy3jNx9zy0++su2cxO8tjUa3LJ+tYS84pR6mpxaEpNZmftVqNlYnhGHYHWl UYVi1TidYXbrAqYjMRpRpLQjUlpKSUentPqPfvccx/J4R1uS0VfkFeZ9xwLKM1KZM9NNTbeSpP7Q 1RA4z8equwO1gbKYXGsFGavmE00QzIz8TIjbMi/AQ3NCgw62KxBr4jMCFFSSI0OO2lpptJeCUIQR ERfUQ+bd4vjWTIjt5Hj9bftxFGuKixitSiaUotFGgnUq7TPT2D26mmqKCC3WUdXEpq1k1KZgQWUR 2UGs+5RpbbJKS1M9T6D6QAPWmSmYEOVOkq7I8Jlb76iLXRDaTUo/2CFXmzfqZ02/nIDENmdvtq7O JTX788p+X3UpthxuPAjOvKcaiNksz7lIJOilF4i0wAAB/9e/wam3Q2aw7dWATV9FONaxk6V1/GIk yWT8SLX+Ekj9h/g0EeGInJvZsijxSY3WxCHqllhRmctDKfskRnosjIvrH2WOW8SEkmcn2wyOnnJ6 OtIYNxPd7SIzSQ/ORyrsLfWNg20t/czXPhZXIaNtvvPw10T4fhHyV7c7/wC9Km/6Sb1rBsPkrJx7 Ga89HjQX8BRJPrr/AGxiVuD7f4tt3TopMVrG6+KWipDpdXX1kWne6vxM/wBoZoAAAAAAAAAr39Rj j3uZyQ2pw3Cdr4MKXcQsrj2U52wklGYZjNNOJNalGRmfVRdCLUZbwJ475vxn2SewDP5tbNvpV9Ot VHVrU6y23JNPak1rSnU+h69BNsBXVyR9SzYvj5kdpgzUey3FzimIit6mkJv5aE6Za+VJlrV2JWkv tJLUy9vURAp/Wzxdc9lOQ7HW0GqcXocqJYsuuEjXxJC0IJR/QRiynjRzE2g5UxrstuH7ONcY0hpy /obWIuO/HQ+Zk2vuLubUSjI9NFfgEl7q6qMcqbG9vrKPT0tRHXKs7SW4lphhlpPctxxajIkkRF4m Kq9w/WF444nZTK7FaLJNwW4jymUXEJluJCfNJ6GplyQolLT7j7S1H3tqfVs417h3dVQ5BFvNtpNu +mNHs7lptdch1fRJOymVGlsjPpqotC9otDjSY8yOxLiPtyosltLsaSysnG3G1lqlaFpMyURkepGQ +ff39Li1LaZHkdpGpKKljOS7a2mOJaYjsNF3LW4tWhEREKldx/WO2LxixlQMHwzIs/jRXja+/iJq vhPdp6d7Jvn3qSfsM0lqNo7FeqZx93jyKmw+3i2+2mSXzqY1Sm7QhUGRIWeiGkzGjNBKWZ6J7iLU xJ3kryl234s45j+S7js2siJk05dfVMVMb5lxTzbfmK7i7kkRaGPf408jMU5P7eyNyMNqLKnpWreX UNx7RKEPrXE7O5ztQaiIj7/DXUZVvRvhtrsBhUvPd0MiaoKOOomYyNPMky31fZYisJ+JxZ+4vDxP QhVrdetRs5DtflKjarKrOvSvQ5z7sWK4pOv2iZUozLp7zE1ONfO7Ynk5YPY5iNjMx3No7JyDw6+a KNLeaSWqlxjJRoeJPt7T1Lx00H68uuXO1fGyljUG4R2xWO4VRZs48ddF+YSTiWjaLzT7k9pd6y6j nJ4W71YPx75B45utuN86eM09bcRnVV7PzD5Pz2TbZ0bM06lqfU9eg6FtjvUI2P5BXuRUO39fk8h3 FKKXkN7Lk1poZZiRC1UWqVqM1r8EJ/hGMf2f9SjYbe7d/H9oMMg5A1ZZImYmvu7SKmJFU/EbU6bJ EpZrNSyQenTxFhY0dyC5BYDxrwL+kXcVyYVGqxj1jLNez8xJckSSWaCQ3qkzIiQZmfsEK/8AS3cY fu772+7c0+7fmvkfnPudXZ8x5fm+Xr5n2uz4tPcP/9C/wAHruxYr56vRmnj960JV+6Q/tqOwyWjL LbRe5CST+4P1AAAAAAAAAAAAGkuSWW2+B7B7u5hQOmxdUGL2MqskJ6m28TJpQ4X0pM9SHNF6de0+ Cb8clquj3YSnIayJSzMoOlluapt7NDiTP5jU9XST3m4pPt9vQdNWRcftkssojxrINq8ZsaU2fl0w VVzCSQ3ppohSEEpOhe0jHwNgeM+0/GmpyWl2rpXKmDlVqu1sfPdVIcJZpJKGUuL1V5bZFohJn0FQ 3rA8grReQYrx1oLV2LRw68sk3IisKNPzS3VdtfEdMvFBElTpp8DM06+AkfwN4F7R0WzmKbk7qYTA zTcXP4Ddq6Vw2UiPWwpJd8aNGYV8CT8syUpWmpmf0DVfqPcENtKfbK2322fxiNh1vhpIdzXG61tL cCyrXHEtrfNnXtQ6waiVqkviTrr4D6/pGcjLDJcdyTjvlE1UyVg0f76wGa+4pby6p93tkRDNRnqU d1STR1+yvTwIaG9XLkfZXWdVvHqgs3WMUw6G1c5/HjrNKZtjII1RYzxFp3JZb+LtPoalCXPCj08d nsf2oxXPd4MKh5zuRmta1Zzo9wnz4lWxKT3sxI8c/gI0tqLvUZamrX6BuCs9NbjfQb441vPjlK/S sY6tU1G3rSiXTOWRdWJhNL1NBtH1JCT7TPQ9BGz1mv6rtl/0ulfkY2d6Ra0t8UJjjiiShvNLxS1H 7CI2jMzFQnJzc3K+aPLtvGKOc6VI9kqMG20hKWa48SM0+bUmwJs9E9zhpW4Z6a6ERDoS274R8a9v sBiYEztZR3sc4iWLu3tYqJU2e8aNHXnn3CNXco9T6aaewc8vNbY+Tw05GwXNr50ylo32G8u2vnE8 pT8B5h3+cQ0uEfcpCFF0JR9UnoYvqtML2k5acccJ3g3Mweqy+5LBH7aokSUqUmJLdhKW8bWhlpo6 jUvdoKFvTv20wXdzk5R4TuRjUTLcWlUF5KepppGpk3oyEmy5oky6o16Dpk2o477L7Hqu17Wbf1eH LyNLaLpcJsyOQhrXsSs1GfQu4+g5i+SmMWHEbmpdWWPJNmLiWUws7xNJHprAmuFIcZLt9hdziB1f YtkMDLcax/KqpfmVmSV0WzgL8dWpTSXUftKFCXrGbu/P5rt3s5FeP5LFK97J8gQk/GRKI22EmXt7 W0GZfWMk/wAz8v8ARZ/Nfdpf0k939L/mdifN87t7vlddde37u/F6a+I//9G/wAAAAAAAAAAAAAAA GNZlidLneKZHhmRxzl0WUV0istY5HoamJLZtr7T9hkR6kfvHLzvXwI5M8bcy++9vqe7zDGaeYqTh e4WHKcOyhtkozaKQ0yZPMuoT8KjIjSr6R4xr1GObG2NgxFyLLlX6Yy0odpM1oyaccJHQ0KfbQw73 Hp46i6vhbz0xTlamwxS0oVYPutQQym2mOeb58OZF7iQqVAf6KUlKjIlJUXcnX2+Iod9Q6fKs+Ze9 5znDc+UsKuCzr/BjtQmCQkvwGY6rttmmGNusBYjERRmccqkMEXh2JiNEn9oaq5cxm5fGLfZh5JKb VhlqoyPw1QwpRftkOfX0o5DjfL3F0IMyTKxO7Q99JJjoWWv4UkNB8tpD+Q8w96fvFZuqmbhs169T 1ImUPMNJT9RJHX7SR24dNUxGUklqNDYabSXQiShtJFp+wPpimb1mv6rtl/0ulfkYyT0xX34vBvO5 MUzTJj3eVuMKLxJaWSNJl+EUGbL2u5VbuZht5tHFfst1ollIlYjFjxkzXnJalOG52x3PhcPtNWpG LND319Xbr/1VyUv/AKQhfvCPO9mE8/8AkTOorTd3aPLMln4xGkRqSQxQNQfKbkdXEqJjQl6mReIv F4lYxl+GcEqHF85o52OZHTYjcx5lNYtGzIYSSJBtpWhXUvhMjIUwelT+uLjf6M5H/wCYkdSgow9Y /ZVmRX7d78V0ZJLhuLxLMVpLQ3I8rVyE4rT+xWS06/SQmJ6Z+8Bbl8VMYiWssnLza11/F7xazLUm oXxxXFfQbCklr/aijfciVY81Odk6nrlOP1WbZiiggrTrozQU6+2Q4Rp8CNtpRkfvMdV/5qUf5pfm T8g1+bv3X9z/AHdp+L+U8nyPL093Z0H/0r/AAAAAAAAAAAAAAAAfLurqpxyosr6+sWKmlp47ku0s 5SybZYYaLuW44s+hJSRamY/KgyGiyqogZBjNxDv6OzaS/XW0B5EiO+2otSUhxszSZfhGmeSe3m2O cbMblRNyamtVRt0E+VKupDDXnQ1MMKcRJaeUnuQtCkkZGRjnI9MRi4k8yNul0q1rYiVF47dPF/Cr vI7EmvT2KcNGn0jO/Vl2xm4fybVmaGTTTbuY/GmQpBF8P3hUoKLJb1L29nlr/CL3OGu6dZvBxr2o yyBJbekxqONT3jCD1VHn1raYzzSy9h/ASvqMhr71D90qDbPivuUzZzmmrrO69eN4pWKWROy5U0yQ 52J11Mm2jUtRl4aFr4iqP0f9r7a73ty3dJTDiMc2+x9ynRPNJ+W9ZWhoImCUZdTQwhSlaeGqdfER 69STbW52z5bZ7apjLZg7gHEzHF5Zp0bdcT2pfQg/aaHmtD92o6V+O+61DvZsxt9uNj0xuVGvaiP8 +0hWqo01lBNyo7heKVtupUkyP6/aM0yjcfA8KtcWossyysx+5zab924lWTX0tP2ErTu8phB9VHp+ AVOes1/Vbsv+l0r8jGx/SVitTuI9pCfLuYmZhfsPJ8dUOeWlX7RilaG3P4dc0oruSRHmoe0+euSJ Pak+52inuLNElsi8S8h3u6e4x1w47kVJltFU5NjdnHuKK8itzKqzirJxp5l5JKQtKkmZHqRj52ZZ 1hu3tQm+znJq7FKZySxCbsrOQiO0qRJWTbLSVLMtVLUZEREPw3AUlzb7N1oUS0rx6yNCk9SMjiOa GQ5mvSrcbRzHxdK1ElT2N5Ghoj/hKJolaF+AjMdS4jTy+2gb3y467nbfJQarOZVLn48pP2k2MD+c xjL61I7fwigDgzv01tJtZzCpLOSdZNnYMdvTMqWbbh2rHfXLYbLx7yN4j6deg3B6Ouz8q93UzPeK xZWdZgFOVDVSFFqh20szJ6Sep/wm20l1/th0aj//07/AAAAAAAAAAAAAAAAaL5I7QWm++zeZbWVO ZycElZVGJhV5GaS9qgj7lMOoMyM23dCSvtMj08BRW3wm9RfjM8+nZHMpFpSPH8bWIW5tsLPXXuVW WBEkj95pIevbbN+qxyChfmHuDKyGNiU5aG7Vm9mQ6uvcQk9e6SmKXmPJLxNJEZH7hadwe4MUfFOo schyGyjZbu7kzPy91kUZK0Q4UIldyIMBCyJRI1IjWsy1UfuIiG8uT/GbBeUW28zB8uaKHaRDVLw3 LGUEcqpsCToh9o+mqVaETiDPRSenuMqNGeIXqOcWbW2j7KW0+yprZRKlWGFzmlxZhp6JcerZpEaH NPaSfwj2YvB/n7ymyaps9/cgk0dfVaMM3uXzG33ocdw9Xfka2J8JLP3npqfiYvp2C2IwbjntnSbY 4FGcKsrO5+xtZJkqXYznur8uSsiLVaz9hdEpIkl0Iap5hcRMQ5YYIzUWEksdzzG/MkYJmiU96ojy y+NiQgurkd3QiWnxL7SepdaZKjh56k/HGwta7Z22mJqbJxK5MnErhn5GUvw81UKbp2L959pGNibe enHy23r3EodxOT25EqhaqZjElyc7aHYZD5bCycS1ANojYh6qSXxF1Lx0MTz9Qzi3uhyM262uxPav 5CdPwy4XLsXryb5Cls/KkwhanTSZrWZlqo9PHqNg+n9sJuFxy2Je2+3Lar2ciXkllaJRWyfmmfIl eWaD8wiLrqk+gxrmzwNxjlNCjZXjk6Nhe8dM0mPAyl1tSothETr/ADOwQ2RqUktdULIu5Ph1IVUU XF31POPvzOK7WT7qNjrjxraaxm7jyKxRmf8AGNx5fVnu8TIkkNjU/p381eR11U2vKLdp+ox+K4Rr iz7A7WwZbI/iOJEZ0itOGXQlKPUhfXjOH1+NYTS4ImTLuaqmqWqb5qydN+TIYaZJnV9zQu5Skl1M c6e6np58rdg91nc146sTMopoFi9PwXJqGU0zc1yHjUfy8mM7oSu1KzQZlqlafEWDcIq31B5O40/I +T9i+3t19yOQ4lLZLhtSTnd6VNPojRE666EZKUs/qIWpGRGRkZakfQyMch/NfYDJ+O+8mWOZAutY otwbq3v8Nh18onHfu1T/AH6yGU6eURqVokj8THQH6cO0kvaTirgkW2jpj32aG9lNujtMlpOyMnGU L1LUzS0SRO4f/9S/wAAAAAAAAAAAAAAAAeNAHkB40HkAAB4+roPIAAAPGg0jvbyL2g49UjV1upl8 bHimturp6rRTs2epoi7kRmEEalnqZF7i16mOdLHIue+pFzTayV+ldj4ZCnw37uOrVTFLitc93MsP L+z58oy6pLqajP2EOpWLHjw40eJFaTHixW0MxmEFolDaCJKUpL2ERFoQ/cf/1b/AAAAAAAAAAAAA AAAAAAAAAAAAAAABGvkrxX2v5TY/j1BuRHltpxmyKxq7WtcJiYglJNDzBPaGZNulp3EXuI/EhnOz 2xm1Ww2Nni21WHwsUrHTQueqOnWRLcQntJ2S8rVbitPaoxtsB//Wv8AAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAf/Xv8AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAf/Qv8AAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAf/Rv8AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAf/Sv8AAAAAAAAAAAAAAAAAAAAAAAAAAAAAA Af/Tv8AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAf/ZDWVuZHN0cmVhbQ1lbmRvYmoNMTA2IDAgb2Jq DTw8IC9GaWx0ZXIgL0ZsYXRlRGVjb2RlIC9MZW5ndGggMjYxOTMNPj4Nc3RyZWFtCkiJnFfbbtzI EX2fr+hHEvDQ7OY9b4qRNRys4MVq4jxk80BxKIkw57IzHBnyPyTfnKpT1eRcNBIQG+Kwi9XV1aer q079Ofv4+c6ax/3Mmpj+W2OjMrFxauKoLNLUNKvZx9/bvh665/bTpt/sulU77LrG7LrZx0/73DT7 WYyp+2Y9++uCBovdbB5HcVyaRTOjF7Ky+DH7+Isj64uHmSVRKYvhLc8jl5rC2sg6s1jN/hV8Cedl sA7LwIRzmwfPIT06Gu7CeeKCgd4O9FeH8yroocEff+KtxpNVOrxteC6b+kBDF5jPh3bPX83XOxO6 NHiiCfSz53cSJFFF2rwKJpr9gV1pwsQGT/xm6rAIIGMjT5PmjmWdLs7PlzC1gXkIvQ/sexIYmUaL kW5a+nX/bRZ/n/1twfAxcgSHIFcmBUNHyKSJWfx6AV2WEsyuJAyrKsqqMssFwAdsarPDGit4aTYP 5odgmMJTIMnPlvyN6fu2hYuiUHsFr7tZq8O0uch6OPcCsnnCxxfezZaPpYUDYqphgdjrxydhI3bF AqAveCk+eJ71vPku/izJlKNjMeLtRueJ1sO0x/ISx7MIfA09l1Co52UZxUXhw+/b7W1EixIm/6TT bunPLOlBxxiYo+CQczYNfeKo2CmYRYDAmuIDooaGGosKLL23HFfHAgMVCposMJ94S7/zOIHNOQl/ hILqqQtY4J4eL/xC3n8Q78/hsFmmeGQ2uwZIkhAMeZFHWZblpQByH5ZRxneOnrRkWtCvGXh3FHVB yydDx5fR8cX0XOmIjo+HFHUUMVkwqq9lL0fzmw1Mr1UwjAbwM4r55CGhmIELgrPIxIQRV/3S/C1o /EK1t/TIIZ/SyxLafNijvYXXfm2xs62NBveyxRPEEX/+IrsiHy+yvXaTBfo84zeXCPQ11l0zYlEu iKQUBmlMP2YrQw6IOOI8kzgaNiIl3TRKxbXxx+jUru8JKqirTbPTNQ4iXgOinC66i48mPqlW14QU BjyGtsF97/wqcjBY/+nU9bNVdcIQYo2LPJhUPhG6ivGLX4POJUlEBSu5wG6z3W4QrRUyEf9yDrH0 e1iroOPTneScwSLO2xs/4/JM/R2KK/r3bnqWQ80oaqwtKnGMTyiot5QSBkabvUMRw0mXwSMqH6kM qFB6x2lMBz5q82GLIXxiIOVhujUUHji5bKYJKzZGZXwTZrkEFAU+p4nF8SppoeocPhc2IKTsknI2 PvMNi3NUHEuXeD3g2YeUqHWFV5K1zRJBNsUBAlZbvQ1r6iKXOFcorDWuZ6IZI5E49MLmzwO/srzz CoMkp0Ive+KTUjKmN4KXUC8jye883mDUtMgLSaA/Rn8bzgxJME6mwC6C5YFKXsb226VB4fTrrfB9 paNWJi912GEl7/9wqtTr8CVMuHJ+QA5LzsPVpnnyboji6lAGKSwRDoGy9Qjptg4nEHTw2qs84pvc +SPQ2pMpTbvlO1ZitnguQFI1sHY6ETky4+tcNW3Y49CDDyTBPCxoukelGzGMzBeknISilzWOTlJI hhm8Kd3cd9X3wXD22TsDHQFi7WdcTfhZnF+rsIDbVpEtq6TyBVaTIqfBB1oi9cl8N6VPzqYfTCcv PmPSHTvKusn/k3V1CvF6VYYdXd+s5Gv9nckKC8bJIvezvZgKw3HdibR8fMGmHny1cMlY03ShwRea ix2gzmCKl9WisoPNpbf5ep621VXuh4OIiyjPiyrTcssews1A02g3vHDCNJ2vw7l8Ps6sACHoIKJ4 LoM/AnosQe/wqe56TYfMxMUU692FPlEikw9qQrhgwu8RJ1v3R0jVl0kk1w2AZ9AAkZ1+H/pqgFOm q3eZWQHFWzBkVc65IrPHmTSQK0sxX8llpPRF/tiz5B2z9Y+/pNrdOTFPNlOTEY9MlUQmEfoMdzb1 V5qanU/NK+4Fj2dfHK/VakEHXUh7eeEATectHlm5BalhTp9JRs0ilCtHP5vlpg8tMvzjCzduKXKU jbglcrjtn+qtzjmoqFWD16KPF2bfnPp2Bn+eR9TrZTmZ8L0Het3dSA3qHtHyE2d9VLzzwLevpZb9 +zNucHjkmHnSltS9VrIRTxttQlC9hU5wE4dcwiTBbPRKEC36LbSFLAcDB45yNDakMb/svgoFocqL dws62tiMimSaxv64tmg25YQYZap1WpNiqdn42oS5lAeMev01N0tq2nB41C7hzFltvzd0OeecxH+7 oWs1r7h4jvVmUnwUpRqDnQyW8iMKOjB+4X2IokEoF0oAxFjCxcv8B3PEVQqqTFmKkxKmHKQ4kh5E aSOr6GiPypQH/yU77nq/mzqJuzervnVVTi/Eem0VpwL4auwnVxpI9JB+8wUZCJulreNB/enU9BKw 9y/IQp8P7V7b2a93kbSi34jLAEVtWQ9IX/OKjqvko3rdIE4q+MbnZLNXGGPqubjLy2vZzSW0uYwP oeIeTMKqinBVchdx8PLoGc8O3IKDmkct0KaRNKwPEG78ZOIyJQDBjC3VUscBm9GgV6E31+BjPZyJ xdRaTdG1KvhQu7Us95n8izj5xuIK5RlWgtBbMl9lfCc/pql18r1ugOealWrX2y1vqZy2NJx4Qtcb Zm7Ek+gyqemFTso0eRtvS4sUuVXAucOQa2wlabrUM8bdJGNuVvf6rZExyMHEt4ZQLj501qJy8Jpu GhCWbGSlVldqxi/GFR3XvhFLdd+r5lIUza1ngjESTFocuT8uf7qbG5miFpanK7ajX/n0c3l/C9/v 5lwP3gKYaEuSpb5q8EXhZvUWKY3fqB+gWlaBNwnnJj8qWjnm9pbvG/166fPpcCkm6BKSUAeGmxHU CR4NqrmRiWYvumpHBnxFKLkgMbNuDwPUTMFC7XWOze257LIFtetNaErB/K93VOnwlTMSS77d3kbj bq+QQDd1QfbNljKt6AJPLeXipGSmWl/RxBoQsWPB8INzpFCxoUY9FtonBfqcNko93gmRS7QEQ7Wv PRvUap95bgc5lmnbaRLCla6tZGiIQTapWHPJ5k/0+AtIwClCVXa1TRE4SmJBcVU6z5/ITt0IF2fK S86vJ3TmTFuUDPBhYW1BDyQam+uExfa4/osJ1BMQaCcTCMKq6bkYQWW4QbLhkfuNzVDoM/JiZwkw zsIhs1fTluy2oDtbFonSj6vuE6HvT/Y6AeOj5ahdADTmnZ2mE/lnZoaaUAg8x5FkUJIKaTDgn2Mx Lc/bL6VdMEdR20nsrervwu1KWfIMGZsWbwOT28jlaZUIMK8RSelYdVvPY7BqE9WOUamkEhtbjmG6 m5CCw+L1mxfknA6/dkH8EZjPIUgHIKjExkDFk37Qgl3cmmvMyubvRFBKfFLoF9g8UhMTIAn2Unhh gM6QUqGSoEd6afmFdlwKkw3usU+AxWzIPCP4Qs+QPI1COM2hWgojDn6GhcqGUQYit+bHB/Fnj6kN feTCJhAAXnN7+w8E7FZsF0LbkMUvOb7NFJjcuasUTJChgHYujjWEnilBCN9ihoXuUnlNAtLDX2sd 9V7tp5cMXrKB4lqnS1T50RJVhaQot07rdzma9d/Fxg9R4vp0ovWo45abjhLwFUK1VGHtl+lWKvEm eh23/gNYwOTuYIYnfdUvl3FXWU9xrX23hxKgXR5VKeU6f1dpCIATysg1Rmsd7XsM+Wy5GotqpyMK mRS6GQqrsEqIWogG1ftBvyj62fjJ2zffbiisVFIJmeAfc3sTEu+sziimBFTiS7Zzb/Yw+f8Yr5bd yJEceN+vyKMKsNVKKfXam7d3emFggTHQ092XuahLKltwvdZW9cB/v2SQlFQvey6lUiaTyUyRwQj6 XGWSBhfosgNpGG3ZX5hTZJpamaZWZpxr0OG1Pt+Ep8lnJST7S8zwten1sRuZp9i77+L+Th7c1L3w POzCuQTxJMb8VemmnnS20wGz7h57AP1ZdJ3xRl3wm45/lV0f5MFBs41mPGMXFOnyOIr9QhRkJRuU fuKjx21AyX3q36WeIaFUJi2lhfx9wYKB0n/HxbcCdAyMGHRo+t8BW57xeNnaUE73z+Ov3EQVw1gm 0cSz2++EWgCxeAHcEWTi4ug9XviU+Tb3sop3kzY97sYwbk5o5VbXcwRXo8zqC/oyT7X4cv8+Hc9q +hCkd2oVmBQnzaVIBzpX98ofLI304VrJqnFgydmWaloYKpKaHJAd5samgXJrtTHbTlzYDiwix8Sj WebMqWKdwWw6PmV0o29ut1IvNj+54a2fRYymKm4Mz2h67XR/1mkGoXS8Z8rUkLJHlFdl0Z7dOFWz FH9ylY/IfVfkn+RPLve95N7ZoC9SLEEbwSOPdpZBWTp98WDt9jt63p1whN3Kid1oQY74U9LLbik5 dMvkQWgI1rTTHjRCrAN2sqaHs7343MkYC5WUCdosEEr6LeDHc0VngNsPI70idChT/cdKR+6wIMjI Ui3jBuoEP71ytgGk182YLIPdXMFs0G+NhjlIOqHHoFMyMPEyJ8x/z7TkMHkBT2vB3fG3AUPt17K9 qA38zHZu+4lsPorgQhDuiJqGC0xubDBJGYp3G8x0Uzl1fJ9UhVwVl0fGILqi85VScoSoht2xtRJr RNtG4Xn9N5vOMLUuNIER33WrNVVXqdU1dSaD9Knb6MDYsbDJ6F2aBEnH+ewNNZNWW5u2Edv8F946 613D+UbnVz2Sl+IqOZQbDtTMqzqozMTOte7s9YREMcYBJwYr/MoRvLRkbwf0kdhYmLTcPWOkp+ub nLdm1YzO8Tm4rNnO3hr1ehpUfK0UfR0unZlpS5H4wmVZiMuirFUq/BBxIsw7Fd6ixbYHL8NfKBcp puFpqh7Hny+6WsKfF5Us7+jG1AIV1c802uAgKuGJF5Ce1Lrix/8ODffILSQFcOAN4xcIhM/zvwtB 3B5Cnge5gs8P5Pwb3ArQrVZTEwfGghQAG98WE5reX2IduQ6AWTBPeAZZEHSi2ZeZ4V7IxnbiEC1l WLBdHXOcWXA/37Df4XVhtEIbQBVdTYbwQUPzxCLpnxKI1YR0uP7NkYCtzgXszYJF3RH4cY784sXN mofHtW43pokbPzZlOTB37WZwfeZueu+lwUqztCyUqGKE8mOBq8SqoytJwwdUKiGbJCmCtfZUAFCI XdCBverbcNpJjsPux7CcZNK8laXXW5lsh6uQCpr5b1p1LfkxNqAFeMb8xihHLrRV2IlXbNAPFGAW 1xdyR9lQUld5Xdcm/6qr+g8XmFYEaGnqs+kCYzraet3JPwa8YN+S/zYyLt2mQCeONXQfBwQfB6Bm ULErp4j1HGxMh4PXQcYbGEPUEF+UKX1TixcMHvCrISJz2PJedtzK/o6Blm8db9T4q8mLBLUze565 GT9ELJ+Cw+3kFfWAyzjIn87pWj3khRY2foIPuUKWkUpIyzIOlL5ayNyTqMBuGWWokZTC14W9swbi HKBOw/dHbUXIEzps1KHhoOVHXevggoDHV9bREHwd7aEldFGDrqSb0NEyaVcRLFeLWptjNPP9zFG9 SoT9WGdk4vYYFCk6uqyjFu/x+VXV2u19WlyrcLmiIo+rsk6VvP+h3JfpMj02+trJK0fmuasT551N hZklIXUMaRh4AWEzGrq9q3Gjxq28foIg8dFfLIuw2NcSA6yG453csiEyy25tzwYiqOK5O43wM8Lg u5tFYw7tGDgVS6w9CVQxsakLe/P0Wl/f1P1VOptzxb8DrCn9IyZbebn2Exo4kTnjfYctROxEMJV9 Opleybp75aif1Oh3NTJ2ulx2uk4fTI/Zq/vRuY0aNSC0uNJ8vtiN5QCWyUaP2LY/Cn6rvBmJKXHJ hC2dn05orO1gjPwgLjo51AVSk1Qf3C6lU5UVWTlqBKFlRByMpQgusahcMusAC9lS/Y80RPlErlYr PX3KCEc/G4wmqE5YYJQCSeKFiEqqXeM/XPTCakCfYI938KE1WuIvIUN4p5+DRDFSLvCZPOH3G2xw nd/XlX//dlgv+VBrT1JKbcS8Vyq9fJJPuGyMZNPtVBMTn7KBqqM9LGmZ/JVlJ167rQxLhnrNUB/9 LmbOCL1lqI/04cxDs2dwLWak3yxIJJHzYhQFbdtpMConzlp5PorO/P2bIhwq6yzUdlMhiXPtY7ko rRydLh/vYz7TtJhCeza7R+6cufC+OEfnzYXw4U3W64phkcyXJ1gOQ7fRLTZMkWYr3+Q1BhvFKhlf ihNdNXXlo9MEmcoikl+I0ry2Eqzw9ZW8rMSkR1i2jWgcNu1fNdKrPCrJrnYmufykitMyTbQz0UcF 5xiUORlPAekY2VQC0tEr45B7DUyldeCnUg2xNxqkr4Poq9jqONSnLETwh8P+9CU4KrPVP6iHIviU Inee6J6R5YyhJomyk/X/paX56dKCsjU9Wn12b9l4b3lxJYCy4Auce7lb5HSEh4Xnw99zew3RP7mV EeD8a3FbxyyXqKPRFbWPPYy3jwTQ3YLH3Fd5buSWGoZlwrCB5Srm/0PU359f0kxppZnEmmqsJx+7 KEiCOE80jcJHxD9EGTGWbifJBUHkHk01DeghR0po1ARBJdYt24Hfb8SKldUDQ+03OAOjPhYDKgT6 UZT4C6IEiIzhY2GSXcDkVL+Zz/yHhDUhqeA8sbGcBEYx0oKKCzRwK7olJKOuA0FoTUTmdi1BIZ/J prmX0XxegMeRtNqajypqHfoJ4zGd5KteG40seYcB9kerHCdyVkSeQbqOZLC10ZQfVOb36nD3IvOI V/4r2sDleaKUIxZf7elyNfyvLC1PgIqlAk8mkqEU8VEqbmXRRgq8pLOFkh5POt7J4laoFX7XIDSd 2L0oDdNNBGzJBuBWEsAAV8pIx4mcV7NdNYhf8ujhWLYy+8aCxzZ3EuODPO4xeMPqq4xsoychWktZ L29O3xp5qLOfsqvtdKUuQ5a+f9lEoPI8L6pJtppoRTOIHB0oOkzFgUKjELi/pYKrop+eznhKKDSG PADIkksVQRVDAiUwOByHQlSDaWLFspeJAP95XDAGMZdlXPvCLIEj8rEwFDZ5lcHhxjXocLa0Q8dg MSjtQKxsKcFmQadM0G7kjfk3b3PjHmSR7bBDEKAvhWyYMVqefwGTCCROR1DwF1GBtEud2l1kqfI1 TpBME7+UNqw5l2kKlsAqpvKDPHudtkXuzwhOkHIZecTsnwsMIvUydHDMUnYf+VZf7UK5uigLPnUp hTXOxVBltN0PGe5k2GlUT+oQRTcLDjirLvQh/M6NaM61/VPi0C0tOqfhreThxiNWcHNGmhWhM8/9 9T2Ito9B/S73vqznwi1A4hSjtCFG4b4zOw0kRDku7sF4/cbhFMi0EuxFlr/oMs61ArlWKLcpkNfI Tj79H9MG/Vb/rqhJFxqBOdpgaaPuxVF/FCuvZsrmlma1x7iFdDjy17V4vbFY7o5P51aLah6DDL5P Ct5J/BGGkjKuqzoLE+Zr1wXADI2WsoEN8Iny1wtwKu/TFi0sAOOKWcPAqUcOoG7A/SRhOF3o3tNE L12AbCIcjNiRGvIalMoZD8HgfgEOMwuc40JAAqfulGecXhsl3XtQXVOmFEV9dkNgNnP6MpsTkD42 vsR1elYXxnOas+KpFcny/DqO5z4uqsoXx3H+3B2Yn3hmZbe+5urwnosjEynIuMbjqx4vzDkysBKk Z0l0K60ZR/g/xRi5f8PBAxj3LZa+gpcsn7BUukZOWPOCSaqpeXP0ErG7JQWU1qQ96Hh5kRE4LDcn yZvWfNbbIonrsrh04oy6QlkU1LlKTymehFo712+/NAstSYRtDv0GWfh/xqtlt60kh+7zFXcpA52L ej+WQQMDZDGAMUl6r5YdW2hbdltKz/Tfz+GjHrKcdLyw7qnLInlZLPKQq2LPspAvs0y7MIlpJ0aq l56xJPJm1nPpSGsduSnl8SJXybhQB23ypydx8bVnrzPBlNKamik/LKMjOqmikBaKMUfnNyRCWcHQ v1B556+lIghyCza7sq8o6KX/3l5hdNgcn+Xtk2w+6MsbWd2jMLq+eCeL63cGugtPPaW4D/AUA5VJ zr4xmL0xhMkXYrIpq35aWH9mBPQ4olLmfRf105WKvzYGZvudMdB7v5Ywa/qMClf5BFHoKHKVbkzA jwCcvsUPUdW6uTssT18pVhD6tOP39yJGl8gZ3vXeeqh6EVVvBxQsiTPgIjIep9IjQxfW/lR86BDL vPsiPr5loXHuu7GpHJuhBZ+YkR088hb5RIuH/eEOTBKUj1LO0astJ6RDbeS8FPn/XkXOUXn1wmt/ vHE/2vUQt5y6dZlyS3JonXpsH47L9YvMTcKn2ermeFw+8gjHr77SI78X0ccrdRWlslDN5P5jk4oT 9cOGa9YAxkeVXYSOC2241xFSedjzUHyLt49K9lmehVj1V1ZzRCSn/VxyeZhsrt6R2C9X4S0epqzY ++R/ooBQ40tIwWpLTMrEhBmh1gu5Ik4qo5MuyxzGfcA3MpqV4PhNmxSb+JPOhu+JCz8wx6eqyHAh grPZbR+YKvFrZamonJMfH8SPa/n5qOPhclLxJx3jtoqfT2rmWxsnVc8rtb+qItX7RRy/ZFupDxpO Q0od+4chNbi0nhogh3TLJFqoBPNHI7yR2d3+RP2LuOzTmRRzYJZgXs+0yEtt1lXAtPnfScXlbeOM 32T1cNjT4Dus3Z1Jn7ZH4dF/yDJRNXr7UXcLGf+XyBDN4SGx8DDHEi/nzqhapxxXlPFgETd/yQ6V bBvbt2v3XrVLrmlz8fVvk2CT448HjnEqsdLRZc1zZgFM1YSXnW4HCeZGzechDV5SZfMfevZMNnWK ZSXS0bczLXR0L6qwAXD9MNHh5d/ELZRxo8TccTViMlMG8Vh2whx3xBPulc/qDDKTaGhmOrSn3adv XLMc3SR3MTcE79yP54UpVBmkokYbNYFvyPubM17u5euEsWv1cuGM92PWXD6/dve5+cgez0HGNSny uD9ofcQGuh4eXJSrMTBHaDu5sdxIuIseIUfuNA8Cex4WLoql05mVh9CfyyBQAZN9VgoD9YEODx3g yJaen9jFA68fW42HI78/aDmH6PL16YXFiKFjEQStbv78xkt7EhC1e21NeLzjFnKihXs1iWykpMTy NZv5QsmzbY3MMuGX1G6qTrzwN5/BpJudCdyR8HpLvpy03XDDPCxs5fe/3+g1WhiRWOlN5jfihkse o3NZW4yUZNyZgz5wp0lIW2jbSB3HLdy311Rz4PZvIvVBfrT+J67/ge7V/Ba3jivSzS3XkbRp0lvq PXwuDB/09/ZmwYXtFpdPouZWpHdt9/7M5kE6mF+1HKBw8rLc1IV0tYajle+Nnm1K1J7tavyHOIa4 Gm+KlzgeiVVGoQr4vWV0QxQ+UselnwdmVJEpfKQjp8U7+eF++CzPsvdFwF438cjQNf6yyGwRdbaA gsdzwQNFh2r9qa/jy7va5auINfUv6veRYkyb8nCKBZuAqv/rfPvN7XHy6LI/ZI1qMv4fogqeH031 VaLKfS5rx5QJD/BJfl509XErtOe01xcHISGPCm8Y7pkrQYPtQOmSvMdoST/cBHVQxe+1/HwUkZNq bMRqJwru1ZEzfUJ4HpqhwA7TEoY1R4PIZ1kcm9Fbx6dyx8400sx+vL8cS3D5beQR6odxxQBQS67a RD6hRO2ocN1zReEaxjSSChTx6ruF5s3N7e5K6qbMn5vbIy4mGiOq0bTzREIN45ppSRV2Mb3cS3X2 NJehgJTNr9f494UbzqGpS+rNkaros3hz2CvZd8Sa8G+9sm66vX++s/LVyB9MhaCEPmOmQ2/YPSJC OYFSL/itGV0FNSQEG0Dt39Gex3coTqYmPD70x9XZtAC4TMAjfwFC8Qp275Dp1SrCtrpa1yXr6mpu OhTQFuvWYJzYac8iBBRzU04olzpM2cJS3RhwcEMa/M74rkkR7cORJ+QF22vPIkXTYG4KnFuJV3dz GAyj9cMccHa1S+d1qOFn3lPRi5speY5rzoXdXU1yr6FFDrB23CefwgXGyMAwwTkEeoI2RILRNYxJ AAGqZcLd94QbZusZrj62b0lxtaafdkP0PYlCbuV72rNKwXZxXQMKHiz32OUAKhOHPWDnuzRQsP3Q G+J9iDnf3IfxrFLofLlHH6jUOGUhZiw3fS9w9M0fQtn002qI96W14AqwvfasUgl1okeo5NUZO+xV jA2uDHvAZcSzemIiPfMV8b4Etq/xbM8qlVY34gkU5nhag7yYA2oNZUDziKEfIe1Q9mJksVnvWwNN EN2rlKEmrsWEyS7y0fnpgtNCGJEliKLS1TUoeynpNLgdNMGwlhFeVG7k3BRfi6If5wDTQg6hbwCs I8Qdyl5KvlZe5LmJhdXWETTAYPJsteIYw2TVY6cbGwAjVw+qmwxrIidDlv20wBUrFEvvLTUlhk4h XwKCLI7gcoXp772keFQo3llVjlLp+XWlbwFBYFTYE9wv3BXsiKo60BSKheScvLc4V5S7mFWcig97 y+JIg5QXZGqq9B7pBwj6aLPAjNNJiIIVcSygzoPxZCfvSyWYRTyjVjmFLJ5h3c/vcf4Mk0KkNsHY xQPtr1082oWkZkQEv0ljASdn5ciwD4nCWDxNhOoMwQpszf1TaAV0HLPXw9mKhFb0gXbQWXZ7iicP LJofPmjyQVeGSjTBks9wRFwmN5CRzs5eUIqisAiOkXBqR4Shj3CpoauwCyiVqWqjpETYVfXbIFmB fYszvEQhdDjXpMcY0eDQzbxnr8HOkNiurHakSUWa0UoIIgEuQFCyDM0thoZ1Q/LnEhERIZzVBDgI YYeuqIkbcPi4iSnydzuEEgwObCUGuRUOTtJdMrHdIgOd9BOq3MqC+0SCYDlyKR3jEGO7ppztlhuM 3HKcA2H+cC0DirkwoN+43FYezlY8fRhgCgy5MgCGoIj3o31brwu83RILG/J0UdPQ1mFzAHwG1HV2 YKzwFktcoOsDsn52gLiUyZMDRLWGuCMlXVVDzbhB3rowGx8rvAPQ9O8FLIhfnqwbkEY7GQe2dZJH 3XF+aOtQHajEZctkfyzQBqA8Yg8UvR3Gq5S+bhztuIzIA1FRapo6apaRdmdhHwssbzh9my6k0Rz0 grs5xxw41i4NFHrMO1C7xfItHXbHAotbvoBNEyV4GXYzLpmZwp2pBHRpIKq+qmkgtZwpU+dYjwWW RwsZsQZKc6wTSMwca1DJWppnhMqI9UBqGZw1WzdZHgssj4QdsU6Uo3FYjtSCyrAMnEasgaLtpzaQ Wo6UnnO0xwLLY/4Z0Y6UnVO0Ma2mOdrAvvSrBeRGtAdSy4GSs06WxwLLe9D0Hj+gLIVMLHui+3FY BjYj2qj3VKtV00BqGXW2nEV7LLA8+syINhXlOdqo13WONnAuzTNCaUR7ILXsKD3TZHkssDwa1Khk jvKzTqUEfaG6YRk4jGgDedPPbaBWyCg952iPBZZHSx/Rpv4/R9sS8ZqiTRwi1y5t0I96tAdquY3o +8lwx5zZ6OQ9eIkb5LCKI63DaG9tJApGbPqBdSAWcT3qVLE7hCjuUWrfgRtWxv1Fq40jtsiAfsaJ SQT1TUPcK+JyoEkSHd29A4SLgD57vCOOgedAcsQe5JnESg7jVdV3hWZcE0VfIteRS5UpQ0Y7J4n/ 010tybHsKnDuVfQGfKL0Kam0jLsGR7xRe/D2P7mZQCIdO+6oK9UCEoQQsCN5Jr8niFfGjr0b6jwM Aj7s7/rg5yjcxvoP0Gu3bSZ1293Bww4/0DQtEwpQi+0zBHfvBe8DorSiieB5okXiDIKGF4jdSqCv j8AFvg+ODbE7sCsC6GiRE9QnTRZ25S1NcoTC4yklxaIiEyViFBhv/ijbokNXgwZgxSeD3dOcd86y hrB0hgVZgjjYYXT0l81eBZ5F6wge8oL/NHptfQR6j8b1+/GThZ9saG5ov0geQWS/f8FlJiYp83IV m1cWrNqUtLDVCfj31wfaxdXzn9E54fFtQ4VYHLTYr34hM6fNSTd6SLzmOb96/mqc81/Ncrit2nbF PHj5vMgGAZwQW0p/5wKYjRXvEN+8nzgE3j81vL0nHcPPEuy/90oqKRfnvPV7IWR+a7GuDd09b9G0 SHzvlYKX4t56cM1/r4TUbz2yNdepOVYOPSiQPJjfK/+ph+8Kag8uZ0GMkLpUzAeza+FtC7wbsUDY 0KAV3svisNi/9fFZadpzjIVmEwIgai1gtwEh4T2qtvvMcsdolQs29bg2lpuy0hrgE8LkQjh9M5ny +bPBwT0J+JW+xoI733mBQqCxh+mpDnDUO40RujGjAsirETw3uq1caSEcfZ8LFojQpjCFrR3G4KIw B1Mdwt+ndtySPMaJmnvN4xixUFfuMJjaAUp9DutYuO6R7AixT9w3jEOMhX2Ie4HBCW2KXFhTXI2J Yh4sdSLhxT7C8HMfIRbqnTsIm5sydYud0TYFeCcNAj/8UU8UBxgL+wD3ggXBdClAYWcHMHgowMFS wf/7tJjIqDOP0e6o1d+5QOtl2rWwEe4nDoH3Tw08gmlFeauMha1ChfLnwn/p8M57oquAsT4LlUaT Gwve5VbHzxLGtIiFu/VjAf3ErFMLyxqMudZh5K+FB93TFomFrZQieB232b+JsotFYqHIXkYawUPn eZn1+LYnh6jMEQ8RUVv7xfpsaGbKyjeLXftV924WrpGaAtkYgR1XdXv69l1AHV1SaAAaz9r2+sA7 P7Y9YD4U2o1e9GqpKZDJoQvHZXB78R27VrzNrmFhTri3vRvRqnXbAx41dwM915ImIZPj5Yt46jt2 4ebveN683Ec8B2fXI56BkQ+ej6xyo//CyPT5HGf6E1+RVY1tD1y4rCAiI8ZeeOcChAau8Bb5tZAi //v45+P/H8U6k/LqHGDYdk+0Oki+r++Py/KLUZzGgj0SzwSxKuybyiz57TEQGji72A1v6KPpsO8v 6rUvGzGsNzL4qR6K0p9nQ/X1kZA2P3dHdVmnWdc0qrj7E204ueKTvR29LaWEYAJXmpAGQ8CYSE/w DQPBGTmwAiA5JB6frjgATfrulzjC6GP7SRfDgH29+VU7PcJHL/IzgWtNSHlJGI9QFHRlIfgCeujM sycCbi4LRDgELVQh9Uq+IIA2y4i3hrbecwKftyUFPmZmRQLXnJCaJGF8pCmou4UgDjCWNlbOgU3O C0RgBC1oIfUKtrCu2vX90dGXNA95rzYcXK/e/lgFo7C+Xa8QTWq7kZGaYJ2l0nmjri7tzBprnp8F 9+sjoUXMhV5Hoc0aiDuIZt9p3xVvLf/HR8tMSRDXUNDuYUj4RXRFQTxrrhMHrEs7s1qb92fpNrmS mSKp11Gzs5x+f4yCKjaMOz47R6bX4IyhA0vguhPSriSMkTQF+SzgTv7m1Jb1RqXfAnC+Aybn0AIX Uq/jARgoC5EvrIWRL/icli+TQ2KI69s1C9GothsdqQnmMhDMR8eAqq0AMxMmQYRG0MIWUq+kCwKs EN4VoNV82jLmz4V+le8ZPmrVsSWIkiVoxSwknHxoCvKyEeQBS+YMwFVvRUAggiNocQupVzIGAxSJ yJkHLXXkDD6b5Qw+7syZBEFe0MiHhFfo0BTkZSPIA95XbmUp0vElCAOCZjykXskYTwRKRbmN/EJ7 2f3Zxue42bng46k6uQSuOyHtSsIYSZOeobChd6haQxlbOXA9UiIQBgTNeEi9kjEK/8V64XlTrmmt pr2h+F6WOeV6MOTk25AoHo7E9qpIyh8c6dPjJFt6nYDLtXejPmUGbSQ7ws4iJF+bP/YU1I/yuC8F HW33To7f1RKJX73pMDcKG4mNgaScnfTJF9mSL8D92rtZr7K9SCQ7ws4iJF+bP/ZUFJTIqlIbhgF3 Bc/9bW1OqShf9rBWjJU4AlQ2XoN7DhMfOHgjcPu/07qd56mGBlj9sTmU6OYE96ei9SRq0I9xYboc D7dYlefeGy0/H5dFBdaU6IKJpOIj/ooP8Lye3AyimbMbRXwSW3wk+dox4Z5lsUImo7oiRu2y6QDD Ki5U4fSz2Icu3CghZGPhSCvMnpgT1cY3neYchQv/oIhTFkFDiXX0ZXbudfzZrc13QSGq9a3Ebvad mDEFRTjwPCQ8zEn0jegSWV5MFvhha4Axafm/F/+9nmmS18BUiVMoEQocGZqUdtuf/WlEo77+jtL2 vFRKfG88bYB4nwsPtCgWaASvu2cwAmY0jr/pYAonpPIdELf+PvFVXZzKyp/nbtuWQ+duXPR/uuLC p2fb01qQ3eNwlRdona4ip9lnmHokC1K++slObEMjuT2dqD9YqIi6cUX9B2xjGWy4w/x3ydVyWeta W7dzWI+ru3z7BVcru0ClSiUX5Eb8z8Dwus2yoVPfgQzn3udCawokQLlXBjLgDmT+n5Fq7fUjbp6J d0fu0UKxajSxAwvFTovhQ8Q50BYVAQdfVrga/HH8NnxBuTYjg8EDqLSNWOftvPfCtAoXsjBbHZpq h18qkoHfVqvY1eR+77gZjOexG3VhEuElrHKz4kXhhbEayff3IZwGbnR33IxL5ZtntZhY7hFepruO 2L4jxnqPO9kUBr5N6IdK3WEpaCZQYCMsQAOZFmERyrDsBQuLZMNNqc6wyHbGBQujHwIegVSXUOZi IdiEcDA9/eJeJH1r288LTes1tp/AXdsJWllSLJR294LxCtEgLcXby7C8vcSFPAQKX5TtpJB8dBwu hmS4eLpEWsifNtLFhew/EhywZH4DXJneArK5MRlJztlKaXono+kdmiFmb4YDD3RtO1YJFctYiFCH cBzD6RB4QeU+wYf1qKV7DwYlVDGHALMoMQRkcmMykpzTlVK5FyblHODc+Qm0ysw4JYooBvYQh6AH //ADdPAqHIk5h1VEuQV46wzx3TMrBWRuY5IJMecplXJKFuUVcO8ZAXblGRyBiJxDj6oLebhPF0CF xXGmR2P+udMfgPpIDgA1IhQKyNjGZCI5J+kq5Y/syZ/Z/pSdgUCt9AxMoghbYI9pCHq0Ty9Ap7Ex lU83K/JOvnvaE+oQ4MnkE5C9jclGcs5USuVXmJRbgE/LzYPFNJNvowheYI9sCHrMDz9Ap1tLLbc6 Ors10y3A8ZSAAHcJjfEtawlJRUJOUxrlkwzKKeA7IQBHAQUnUYQusMfV5TzgpxNgw/K106/hWUiP AFqmH0DN9BOQtY3JRXLO01XKJdmTS8DsqxQAFMydfhtF5AJ7VEPQw316ATooWrVsp9iT9e3WZd23 Q/Zzl85eQAY3NrdCLtwKpXJMNuUY8NoJ2Fgqn9SUKMIX2GMbgh710xMQGkeP9v3BMerIQM5XmYEA Q+cf3+mWILlIyHlKo7ySQXllE+fe7W2vNCUKM4GdQgg6t9MNPGssXk96hblgrJJeAfbMQoB2KQUE 9vMv7M2By6lxcKX5FIfNfInR/+88BLqv3ZolCjuBnUQIOr3TE9RLdFw7DfFzZCGEp3Zi8tk56N8Z REGLsMtE8F1d1nW3lc8ULkRuZanM5EsQz5RDf6ZcyCv6wf3r45PBvNOVz4Hneve9n3RbD+8nRyc9 vAKytjGpSM5ZSqk8kk25BFzH3o3mZ6VTG/1LebXk1nbjwLlXcccN+OHoLy0ja3hIRvYgnf0DXVUk Jdkv6UbDgK9KRyIpiqSKrsexGeEbzbz7JFwI2mTFMaFNwNHQeI5hQd25HHyVtAo5g2XvqaGUqlIk taec6BCOVmG1ou8drzsbiSRUQQLYR8xYnacmKlpUwqdoc11VulbS5t6blhdMVFWeml80rcpBT6Vw ZO4jQ8vKfhR3WC1D34tQx4/QEpwtDm6c5JElOF8xh63y+uYVrsbljKpGFsekmwYiM3ECPPQlmNjY TlDug6zNdcwOZOkiA/bBU6NOwAmA7SmCHXfo0FRXsIDrey793u0Qsm01sev+uCdmzrae2QPPt24Q FJ095ky+P/GGcHNz6nupOneftrw1nXo81ZePLnHDpS+IBWx9vb557Tii438KL5K7Kz4+Llz6PJ5B 67LG8YzByzPnu1xxdjuM4PMJ0/5xT+Rs+yUOR17zqDNo+2VOfI+z2Ob7ZB4wFVwLoayDYjDwpHu2 wp2oZCCNYynsc4ZcPEQWx+Bj8CkCt3ItCBlSLSkniPrk2uk1oiAfG/CSSUADl/cjK0HKj4HSjEwf 3ZOP2VaQe102LCDMPRZGaYD94TbjrPnF22sWA5COYpXdLcjJobh3r2TWy6e3feOYGxYu2wmWcg0j ZDNq4KdwQr8KjFt4Xwih9Xo4KOhAHu7A2QfnPjjs4KL4DPsXNyVWmABlDltvsDNTfAfKWX2FJAEs dB2CH4R97aUw64FslIDHygwSAKBXPwOvBTxhVwlsk0OBJre1unwlezrYVqyijEEVyavR8cTPtz/e fnv78w178YeKNlk9cVFoMAeu6Cc4wYt/f/184wpQb4Q0WJ/+fzjCs9DUdqLkzm8oVjKyqvnTPrzH F4exzaa/w1j8SMIf//pfVpuxOCSu4R0/rZos2MOSbeNLB5mHitw5U0UYnTMFaqg1sXLJ3+e8RCGf 70fJfl5+eI8vDq9tKl9bpnuD78nljQ3tAd6mfvHUUWInj4Ob1755wyYd3j6ihqqni7A/uqveTGHH o/p+rl8w6QGj7cyF7/C655qOKD93KEJ8pOeyjjgnmeif4ottjH0mFajWrfJoJII5eW1jv6LrIM/c UswHocFNCvWEI/+t7zw4v8RmY/bhRssgJ/i7jHrHUw8KYpUGwyVdxrtKwYiJ/cjMg3Nuvn5C+K84 ycfvtvEX2JPHyMi/INO0zyw7/ulgJPk410LJYs6RtiFM8YtCzAuDO1Gvz0nNEHcdh3i7x5SCM9qO qF5cP+3cqpLEHxuDQa8ZGEVtwsU5ME4FbMtBMdovKKdxVH2DoYlnrmP8GCi8PCrfcz0dq1nNfvLr 379j2V2NkK2Y/j89U8sOKg1hT2do9SfODTDTOi8O3snaj0+6CK8v7eLCLsSBPT4DufnYw6OhLVk/ 1hOi9TjmdhSRebd8NAGPdlbba+6CAmnfwvPaTFuMfdUC9+tbApI4X0+pc9mtj4yxhz1EpE4uKZD2 4Yar1Yw99lVoA9J2DluEPK+nGwWmtSu6UEWPK4Fa3RcSSPuGKp0FrI99FXq448/C7u7yZyUPuvxZ SRfCHqJ5/BlI+8hpvFLE2FexndseAiolHX0NfdXtT+DV4/t7KyAG0sd6TCS5TiaBl/Y+7LEaWKRc kaG0gajrSttjasi1xUmebF8laBno4pnPI47X0Iw+ZJa8h/eGJgwUhzmLJ6wt2WMlmWsRK2Svbehb qUSz2sqKKmDIVkL/+dgmxUwyPCBWc6AUQmEXrEJ2sPI1MMXKbY7gwSziuPHsXb5Dt4PYNyyx6FVw v2VcKFvL4VjE2fc6nss2U5Rz7tDk8KgGvU8jX7p9YouDrbXcsLV1qc+47dkv/RkF8MlbP2ABPQx1 Do9+ZGPW43Mw5cmFTR3WKOZvkugMP5Z5q+9KbkGUK0K/5Y4IcGjLa13398JGFl0fCqWCoEhYN+cg ZjpuCKmcFcQDWl4ZQlEhGW7kw+VRIbbQ7KjYnFjLw7EQDl8+UI0KWbOYNsJ8soKnH0XKS8CmWLJ0 cmj5Jek28XFPlKz1DW0UUCLxAyyIbIeW1rLWJiy32XHFBsC6akg7yLWjQpS5Lu1nQutx22keYcgy O4trR6lqo13aMcEmNjYApjlD2kGuHfXwWfnSfia0HuUjpyMMfeHTLu28vzEv7Zh4+rbvPSPRVgpp B7l2xOJALB7tZ0LrUUTScWQmO16X9jTxQudLOybG5XnANvc9HuTa8dbVL54/E1qPenh5HjB98TyC 9YvjkQBtWweUj9s3cM0dt1AuxRtzcRf32eEGztEvraj6fV1a8dYff7Psh9I9Np2o3XHW8so4inmZ VRvpXdiBsmqg2GSlEhOAbHYp61Tek6Vg6ZSHi8LLhYxtaHxBGlJRMkN414PCzF+sDPgVIs9Hf4f7 BCjgY0ibUQNwHbNXsOObahNAo0CSaoJOgfb2oG51WIxgB+9jTetnnJOWCSF91FHxhQ0EgYVjdig2 xkkfMxYIJbiKzAbK8LD2Y/wggE20g9CE+JhqMrm+CGZTnPEwkXPpFdlfR6qCvve/f+39IKTkanEi R2Yp6lw6Y3t/haY/QQIDvmp2HhDj2fw4No7T2AMaOlnU+WiCOL9IJnl3jW3bUFACPWy4mHu44s7h KH7bNlYcqGOzL1Vf+qTsole/iQTwqOllBIfpro5vMmLnQ4q1ZlKU9kRuMnl3iGi1QQwmHJrUso6l kGfqIEEGN6Ypgh/Mls0cMrpO0HdEAm7f0McbC25xhFKceOS0mCllMtSzopAcsAMVMAeMxUYqMi3G rfgqIJJcNWIb0rkmAaCCXJpwgjW0j3oBG5NdBjHgk9IQtjo4R/EJY+q1zZggbExAE0VIJrcVcWLw oTYzBGsPEy/IA/hyTuANDa5d09/gOPE1IYGELW91pONFZ2tPvEfdzteQgoTDkx0PPuE0vxA6ER09 Jj404S7WBsDeJb/WL9CP4xPQVqtvN1xEbIdfJkMhdBkyU2fKO2zCVl/tB7HQiXNG8IQbLHzCRxZA B9Gmn9uD6Oqe3P2GeQe/TFjQ3Vjy/IZdlwfAtsTjw+304PEzfEmTn7fihPT8vE3jxJdw6F9M+WVi b/nj7be3P9+SMhPUYE5xujLZ9CLVP98eWjSZ4eBN1gTWhGT+6+cb93zyCXzUt/D/ByeRItNG9kKe z7ZaPZCt2V/5itpmdmS3mH+Q/3kt+XYIsCw+lQOtFZL656cbypgfsgnRiXB84NmpOpZG2mNr+gL1 h1Gj1cgwRpdkaCwHaCQjabfBd5NiuzfwbjIgdcYur4ugKWvI1MRG0VpVDBdH5D8p+cYNTOiGVOgb ZEnIcXtdgdu88H46AJGL7T40wQ6o0la/wkYonVpPc/Hma/TBUa48UWYkxjk3MKkbcn/skB0uyM0N DW4voLlOJ5vucB05gLsjoFzlu17bXhiAAJHhINTFYwLDpqAgyd5RsYFJ3pCSYofsCUluumlwwwH6 ioUALZU4fAB3TEA5zXe93FpoJ/XqMrwyoc3lGE5yzxd7k+ybY2xyA1FlLJcxIcatDgVudyHzi/OB ZKQVJw/gXgkoj9mm1zYW6rt6JOxFpYPtuBHcGZ6EV2U1ErsAz2zI10Qe05NSEHDNVxWpInhYGFnh oTepLBZbRh6JgooMgLw5VU2zgYdkaBV2sYApiUagmla0QpWEhcSpoxjDHrZtMpYdVFJjVZsYD8g7 7PMvoD2t2ULyMTsVQBm8/kb6dZ8XFqI5QLFH+4Ni/hlw88jAyANcUiPHEipTaIA2ODKf0Lj9lT9n p5DJ1VpiU/vxH/arZNeN44ru+RVc2gFI1dQ1bC0PiJABsQh4YXgREFKihM+C9ZQY+fucc4fqJvlk ZZGdBEGPfbqrbt1769xphXmRtZSjfakdokD2UQP75rrLrq0h0y704R0/07DZ8q9Yrk7FAlV0h3am oWnY+pW6rjsNUe40zM69bHAtw02zIcIdqGga51+nBbLzyh5ZWzE2IvwSjH8g5qyGmYukQTbR4WzB cFZIepn2SqnKjR503ENbbXzgV11bmkx/qRmPSJ3MCVG4U4rI7TgUqGI6A2oLyY5TI1gKFaRBHzKS Ye5jZ493bEShiVMlyNTWuoRMYrMLcV2CqbANw7fFIk26fiid7GpoNevttQ80k2AcyAkhyPwJz0Gu wgshgkoR45/Nc2KYOogYb7MlGsUNvrRtcBYbeBOpaD1R8YU4DYcApbmYCfQMg3K+bRLFrkzQlN7a tCiR6tMgoJjdIubhmk2iAz9txVTF96mWJtMt8hPdosyInRaihYu1TNdMZI4zrF61jervrR1aY/u0 Cl0fM5ibhVLYs69lXazVRDrw81ZMbXyfaupC3S470s1KOl+6D5DH67yqFZn3DKtrbaM6fWOHNjqt TLNYPdq0Cp00/SCIkWHi9NFPckQtbIMqaLLcGD/JrQHOk3aR01ycXpnIfGZYHar71NNb7aXH3BCP ffY0BeE6aYc4nqyzZz9pQqphe1RDlebG2EluC+pYnytZ/CbdJlD5BuVo2yQqbTXnhISmeExDDiDJ JicchjT8CgFScWMc+Gkrpiq+T7V0oW6Rn+kmAac4uQgUSpqSJrJzDKsStlHV21rCgSshe0re7iwA B1Razc01cjyDG8hQ9BWZsxuyPDoVJIKcZHDkC/AYL2Kq8r0wlSJBYxwkTMNzrq4OKG9MysWEIyL4 fakCW59ZmcuVS8z9nDhY9VEYoFoIXJ7UEKTyPswSKMWq0rt8ZhmBYeyI5OMiMEe3Oy9KGPm6DA0T 3Me1T7gWKkUW59yy+Egw/o4iFzNxUx/1LOWYLQRhxZUYVCcURtT6PTHc5mZDQ4qsv7CzL9sXS9ft lAbY6jxMke6mLv7VzdCdW6Omkbj+UNtqJHxfVhM7XF6miRhBljwPVbQauH6lvutORbVsrLNDL9sX qedpHTm5lNWXClf75nc3QTdvDdLFWZrt2ocYyKEXbMT8R+dwRmts2UdRQgQZF0d2tgSfaIgCCKJf DxFB14m6sSUeO85hrzM/gnZBeRYbD8nSvpLSbaEKMS4SACEiaGFzEsQSUazVlfCoHA+iHLpIXVym n+KQASEkN7XL+BCTehEdZ5G54doNmpFk2n1g0uhtyMCFx1o5ezFdDJ+4JtCZaEJxiu2QScol2czl Z9jMBagjoCwdNjiKEAd2gEM53Hbtp8bn3evdX3a8hRqTiCOxcQ81p2X/yKENOYKdGWgCOSke2Sd3 XHjfv3uF3b/scMf4x5EOd2prF6SXM6qVfIKYIN7BwaoXyn6SLneLJW8oBqrUF4j0SjL+ASWaBMhZ DzDiEogWWRrQaBsKtgyPkQ5IeoLhhns2IUB9+AGR/XLSrTw+QSZqpalG1GQtFTdEy+wRl2I6KHb9 VIgqP08wy/R4M9o0W1EdvrQ3pZQ+2jkmw87RA9xH60tb4htE0sHZEUTsesA8mqEmLgvtHvudhe3T tRz5K9RyBnx1wvPp192zbwu4cnq9K8cl4Qb4mY/gTWWg7jNGj9PD7scv/vjq4e27/3z50/70YvfN 6TdJmighCfMGahNZihtjHwqH3tIUi1lphaZQ4EM0HfWapo6dpsAbmi7xiqbDCJj05oNQGpWZ9xK6 AWep9Mi1ZyOpwNaF9xRAkvT4fyRpQrJeSWo33scWUZsPUI+71x+6YfprQyh57U8QmDzKAxLwLXbv hu3TtZwnCXVPIbQuA7Pu5NDXbx7/ORm0TVVRx8eO9UiE5ABKQ8Q2/A76GXQrJZaVFSxv1Zxhj+jo FlN7PslfFKkaxrrJ8GWDWym+dPOoq2jnTV7lpLBRVjVC+x4Wvx55ND0Y8C3dwlULXf0EvtcKKV2/ pKoQFYobW5pQpfta/EVt2F7ZxpSCAO31SVNyHdOUlKcYwhLnGQanBrZ6KmiCPuJg8ne0O/yhC6UR T9JtiVK+c0dXDq4I5Y57/HuCc2WgV1+WPZoieE3KI+zAv5VhicNZUi/wWXJtSM3xWFY/GB7S6a/r h2T6y5Q1JNfRkPkkO3ydynMpilDqo46XAfkVWbIxCNHz5Cy/nPA81HlO5CAZ4eOHDfHE5QbRLvS0 Lr6Bvti8PDh2DXEaH9HgF7AFnVlAmwmLftvJuUqWLK1pL8nA7siM9FwfhWVjLAFCN9kelGlCNXSd YVhR48THSD12cNoA+jNtmhUuHPOQxJqUGUdDmmFBHIawAZNdbg5wDdLjG+QcKKkwY4oYG8gmVTHn KHTtmLQSOtYkAPxhGZM5zLAqd9nZWlXcxKhJeoRae97Y/VSklhZkXqUjS6//iyMPJl96Xz/qJq+j lR+e77OEMHJb9Oci1QAW6ReMJJ0uNQgiMvJFAgbayFysv2e5Oo50Ai8buCzan8xHTrjRIQ5cKLjl Yc8I7ECBguTPRZ8hEfkoWYAGKd7TYhqPWSMlaffhsWLrDYgErheEPNAlVwEG1PJbrG5YcZI45Am5 u/OuPHze+v7D9zgDohW9xhgksw60JO0j9+hEsadtpGwDBc+tzjhRZETlPXKhklgFGL2D8369SI+D FevgE9ZHY4LCyZEoWhh/goyeCrNVDP1F/U/GpQ/cpvh673fA9WMilXHe3KDE/sFi7wZ6ZB6uQvNw FZuH6+C8u8+SkwxypeMDzn7Am3hMy/oGPEXuSanPNwW+kfS5IMbGCqFzJh3tBQgvVeyyvsCciC7V 5S0xImkhHOxEx5CAlr2i+/Q3EFFp41j31C6ldcqcWA+lDH9TZXyEDEvi2zeIyxjnG/fGEgo0XDaY V8o7v/XXZffD7mf4MeO0WLPExWhs0QqLN+7D31zmm2VBuA/Nqbrr/s26S+XThRF5oHRUq8CSSPva WN9c5hv6qC7md266e7Hu+eF3Kv7mCh52d5d0e4dXdzwv3Vlw2d2x5IZENzRbL31DPLv0uceudMqc eFLvhgaX3T1Rbol0TbXznS/mFUSMq0WC+oA8nzBC0cYc1El5SBZ89vuHtP/6LYLL//1yZxmDLB8L ctjGVnvjVNu+yUhq9BjmWGoaFiS8/cpmwnFlvL5Zjd/cyp0Lb118rer5M78/FX6jbpTk/E5HbNyT ghH1ioyq2fmd7/iNZaHFK37fpsnbVLp948n2Nhlfp+snU/qG8nWpV0l+fVPwZplvXFueyyFoxdCs qYeu7fmc5D+dIKgyNWoQkPxFmgAcIKzLiwdBeSoItin94Qka3VJt+8bJeEvWazqfn6L8fd6/qQ0a BFfF47a2XFef8xMV6nMMfCoxsIjPvBCMojHQgsZAjB4Dy3UMPPvuZdr/7XGdEUW+2xll0/PHun/+ ErMi5Nv/l8//xNkR4fArtr7A/3/YxMhhBRMspxUWp8DBiZNR6Zybij9jDqoyjymUuVAoZhgqZ0xL KkHmOiAVbejs85+MhgmRmB0fKD25EEd6BOcpwarBxaEoZ2J8Cvz77qW6qG9ddGAJ7BzPYoA69ND3 ry5/ff/m36+ev728fffm4dX7d2/O+3dv1HXnx50KfDz/vPvqBHB6h4E1ItZPf9g9+7ZA5un1rh7L MvRsPNboMxaYNMqxI6mdHnY/fvHdv149vt//+eU+ffnT/vRi980Jt++q5ZKOkTxqDTvkysOxLw2V Gr+jcKgcSCcDuth9BZsz4QjMomGdQZFy1vH0mJBWdHYVBxLaZAuf9xEnGscR7RvUX7Ch6VUqGGCt 3LtC9uKdF6gz7gqXYxyKoVtmVLR9AseTgFr1OiMlKVblLjtbq4qbGDVJj1Brzxu7g5D1tRSE6chG C9SRRS/5Y478L/tV0yu3bUX3+hVaOosRRJEixa1TI4BRNIs3u8CLQnDhFJoUjZP27/fcL5Kixmiy fg+G5/HcGV6S9577dVP9TCk7Kkc5QFeUqDdFuDCyBgjnbI1qEulq+k3AyWRShXFagxtFA0YZl3CU /N3ZdT4qPBq4rokvUJZI5egJFeLAlRQnXFbW6OZmUsiIPw5ZQ6PDubzbwqO8mB6PwrbQVzdEMJKP /F4Ba6DfM1pBzchWSlJGOyxmqFhMRCd4pEox3snCe2v7b/uxBEQK4kY3w6DwIyIm/R8/GlF01UZK GyjnOBGkRCU/0g+FxKJA6T0b76sjLQ4qTimIJ22pTBBYOOL4FsqfmbsCgfJpbEK2W5RL3/Am23o0 H/DvDYiKvXEgh/5NI7GDFpi3U2TeTqF5O8fmxZ3eb6DQ1vRpnrS5ranHnkaRZnzxKH+ZaqjW44qt Hpuk1uMqkXpsOq3a2qm1HvuIhJdzU49xNopIrdk+SYEpOgu27qRKbESyPN5IfJ42bvZEYhaxQaxi awZ7m1mnsCSSJzQLISEJB6r2sGcGL30+SY9GSk0g8h9Lq4bn0laDdifUjqetaRB9QliErWn2TFL6 Qdt0EVwaxN4tj+HquN6xZ9dXMtQe8UqgnmBnClYyNKRUMpQ96uqis+BCyo4ex3AlUEewjoL7xR6l T3dIrdYkovOEEnpkUqv7bE1i7Ael/mUPptfml1MAisQoqJLgysTiw4x2N9tAU1kuE0/7eJuBegO1 EjNhZ+Luqvsb718776mcNcNRoDEE1FyVe9Eb79OF9/gZZsWO9+e02qfeVmLJuUveXXp/WgKaUIhr PBWFKpkhcUVit6Vz5yU1GDdLqxaF9j1vReEtOCJvlODwk9soONBVbsJPv1pwbM+Coy0Bjyf06inY SpSkPYk7mu/PQuFaJ7paIsHRFpu+FnXVan9S0d5i47XHxgq/1MKRgxSOJUpsOGexkc+xUcZP1mvx 4PjH33+N4/cvGEOhV/+/fP83GksRHv/F1o/4/08dRmkQ2iJPQrhLoKFzpKkLboePg63pvVJGGPLI KRQRjKt6RJpo4JGRigOrVrTbaMlTJ9nLG76JNVWJITmCZjXGcoPDIF9O1diA+WV4KYa5mWVujWne 34c4BWIM/QjL6OCs4KfkQKKcEc7reH8MP737y68//+fzr+N3n8b7x+HDnXa6aRnvf32qAAGO1BCh gsIMPhMd/3r8/edfiop/V6dt25TB0oTn+40uNlPMoo7jbw40pmYklTx+3dVLs06ueD6m29kGWdhi QdW3gZcBzLOq2QjCI5lTATS7gkBPp995XBkb0uSWzUAGR9nbArF59Y7jDx51DV4nx+5eF2qLcXIi L9IIYAj9iY6xjOV2h0G5uaiRJ+kRAvbm4TNz9B9cF8yQASHjo2NLIj//EUve7ACmUjksU9Kfp1lM ywjcmpMiXJvejQRha5SWSBfUb8IU+ZYK8TrYXjRgDvIzXYiUK9jZj0v58mhwmh0/tyyXaUFZUYhz V9K/bV7XOHoFuwdG/HHIWpgiuy1E6vPJFKh2cBxSD8I4wKOywxAroS0CV5wZ2WqIeUp+HRaLVCzW okPAd7UjH28m3i8OaJ3zxNPpHDIpiJ/dTA/kEEydo3P1c64hVPzMEI827iHvFk7y2oJJkJL5MChM p/0aAqpZ40Oc7GONl4rznMXJtqQeYTOIYxPnw2WzNY7eFuFbWlR4KEIupA9ScPJzbgxhloA3clKX z8nJXgOiTlxOWNPFjaI1xh5aLBu2NETRXDNUY/q9dYr4129h0gK+4LGoR1gFii+V4I2bQ8qNReIT Zh0u8mHa6BoFR85xVKRE0hZsk2jBVp2lYOuptWAHB23JNQU7OHRvue4Jywy3hqKzYmtgqqTMXJL5 W0EEoXMd3MQeZa4zWFrIs71KG7FQCFEipCpPjXKgLgKMMclRJNQhrpxYbNdVUnepftjPr5n7PCQ2 qF8cSm8RHEVQW0PdchGULdYqdrZ/DBfv9N7r/Fs9bhw4hgtLehZ1PKser7Y1j5vE/Gk6Kzbm9Rw4 hgtLehZ1PNsv9jAfoMug0UlaRUw43JxBqTboPlur6OZ+juqfRiZeJx4MmjATiXGtlehAg47YJVfm HeOyzEPt421C6g3UStSEvYm7m+5vBH81BKfaNNdZiKhHFAyLkCz6QnDXE5x+t+iYZwTvEmWXShuB pdo+E59S9bNs3hI+hmT5XUPEJBESXyR2Uzp2dluDaZZh65yf8pbiX1EEgFmLRQB+sgTuANIsPPRr iYDlWQS0Cf3xhEgd11qBkbEn65nO+xPKX7N+VxhI0BWOvq6cK8/+pDq9xcCriQG4fqsxQC0PZ+og MeBciQF/jgEbFUWxPcfzrMiDEA+XkYcPHBJoBBxp0IFm+C7YGmNNZBIKpMkrygwhmKYy/Fg00MBG xUNUK9p1sFvoVTeKNW/4RtoXU2JIjqDxiLHc4DDIl1M1Nt99GV7Kg2/24lvz5Pf3IYIJWbZgGZ2O OcT7DM+mdbw/hp/e/fD756+/jT++jO67T+P94/DhDi+YbgrZ2SVECmbYwLactjXhJfibA012Gb/J 49ddrTzTsLclnXbnrBBvWRLPiGswYJZWSOMlpQuYimhWYJ7ynBR6h2usI/KJTwby5Nh6CrFdzmen uAbTYGqQZtY1jcsKtxQQQC8eIAWbHxTK3UWLPEpPELA3T5+bEbeYEonJIy+SKd3q/4gtb3YAk6E9 7GgOAzNgH73RFOnJ8FnUNTJ7pLjXbwKYwjlZYETULqNowFDhIh2mi5096KPho8E0ddAdynKZluAM 4syVdFM/JWscmzn7EOKPQ9bCEdlt5K7PJhOg0CwLZQMEYPBOdxhiJbRF4DptW2RrIVrBih6LNSoW S9EhqFqFqjg+F6/2hm+d8m0PW7CkIP51Mz1wym6Gkj/p4DaO2jA6R5Eg5fBhkPmtRhbmz7ao/k1N xApOKYh/bakUEVjI4xBvhVhO+leG8mk0QwZbsrLsuZPF4mwFdcVoLpLNhkTh3jhYssRNg7THNZe2 QXxro/jWhfHVwesMz8XEJWXGRdEYZNQ5rrsiAZsz1UJfJCGDe1T5ULxiSg1GXLClTEJ9zxy5u4Ak z1kkPKSwZEkscX47SZAmE3dgGdUkau1FYqGbgHaorMQ7wnJXw/uAmMc5VXJAghKLdtMkK8y1knmh 06FSVEzJi1WYgFo1crWVilaCFogSu0rMjNz45aXB1DuRV3tDW1MQcBrNgdSwxUCd2bqGybsiOEyw rmgiV2kEZc9VUjepdpjUcwOEBpFa55XJVQRHEVCz4hdzlc/PJGWTNn69+R+FKtVBRgQxdsVq7J47 x3BlV8++Mz+rz6tpzecmMZeazoqNsR0LjuFKk55GZ6LtF2sUHzged6TtQwdP98Ib121jE8++tH2h H336OHoMnQGPk8BnDU7prCMipY+p/Vtxd4nNc/y+kfV1kBUoKlfBp9BQdUartBaqrj1V+3fBeyBP Cq59qUosK7YStO+R/yx0zzkoRy3xCm6fLpL69uqUqwF7A5+vur+x+5WwG73RGiwVL2BcYC6GuDHV lmT8Thd642fexxO9+4LeF/1WYm1B3zacG4unzUcj8S5YOzJvJwnu4IrALkviuK0NdlwU9stz3hL8 qwkBKJotBPzktsDN6qp8ytlC4NKM9Pn88YRFPdNaiXGxo+qZy/szvl9zflcXJALOlaMrLOfKsz+p Tm8R8GoiYF5qEchBIiBvwsJUm5x4DgHHe5y8eFn0NSv9mr54DN5PfotYHlRpAlrqeSR3hm2kcLA1 AiHSBRUuYXLMc8MRfXkaVcOCiRcWUtWKdhyoy2O4LXiPN3wj7YspMSRH7INiucFhkC+namb+tw9f hpfy4Ju9+NY8+f19AMfXLFuwjG5l0/hAf8O0wRv3x/DTux9+//z1t/HHl/GX7z6N94/DhzvazJij W8YZd1432Altp1/W8SvchkYT7vGgBnS7gCjFDT0Ca/z1f8RX2Y4dxw1911fcR9tAd2phbY+BDAMO bEDBKM6zMJmRFGgBFBtC/j6HZFV19XKXkRIFgn2LPd1cD0+RD88eZUYtpWS1O2FBMUCMfOVjKPXD XFKrizndPcc3qdjT51oo0RqkUPU4iQWughnOnIS/ViVwDSET8mCDPOAj2oDRFU6+gEPRJRLw84+f Hk43xYrCZFh/arD8med17lsHC5ARWukLo+Uaga98QpejwqAzBMPsUm4sLX8YrKcL0YpW0h7U4wQL 0Wqw7XhTYUGyMJnB9VEj/QXM8Or+zcNNwRI6EDzuMy5VV2pR8X+LebBG2wmFQDtJXg3eL8H9674G Bc+NMH4toVvJgF8VIRQqIuGSQwDGWZZcYl5mGShj2ST+q/WZJYtGrZLR1/goDjN5N5lmE+RFo1C1 ITUTkBxeuX9WHbByQaprfKbYsa0SB1aPYKHqgsrNPVFRfe/6W2RqfYmaPWuS+q3vFmXjeqyGqpJq qJroWVoe15faJ6KrHrQwgFQ30Y0HYdYW9UZuVTPjaa1H/v94FZ0EXAJJvtjZQn5iJ0aHUcIK4ihL 6hOn9SrxyHfeF8Uq8QX1bYgnCkFqtPTUaGt7rWgH3YngLsXKX8XEWfoy2mELWuF+3Edq1NjLzwcx B4e5JQkFUQ5PpyCenUosawoqZziIXw7J/09IyK84yBr39RzESgYO8l9PQaaUgYJsyf9XCmL7y0vs 2xdRUAg7+UspyByClIdryzPttjNvAijPpd6vaOiW+Ue/M/jiG9NQwFidrL3EQ0NH+QzwNd5RD8/n Qn2dXJbFVhBTz9jxXBMxekNM1GTogFzk75XYtjK4R2QznJp6sfS+v2pWakhWt/raRmwAGaLlOZie FiygE3zrDj52K352OezFGhkaIrmViDWv5cW0hJnBy0MUCeNR+hp+Twu/pw6hQ+QAeqHkSubn5smR jrGUyRqEzYqc5jNFm7mBU0mEWLC1Eba6JZ9gQiJ1Us6SdM6NygiYZd38qsy0FmL7AB8zS7gsYS1H yXd/VcWmCb/cXdWO6da9vGOB2PetYir2AjKFZhpe3z1oHzyeySqhDw2jrrjZ1aTOJ/wbMnp4t0N/ tFGoB9dFSKiMZNglDoUiJ4phLDhAjj/3O9CCsQWTeQ4A90YMLZsJF0np4t1ZEPrgwbsFSCMgIxNa ZYPCgtGlm2dfUuWru1X/+YD+wqLCaqzrfPj+GboBjMWeMEKD+Gtkhkdef9joiELmlAC+RcOkKqYe HA6230u90X44GyQZZNZ6kDp7F0tO7mKQ7JzmcxdlSWgLUWOsXwWJ61f9GoKUu30TJBmMVYkThYT5 sA4T8U1NyxAmhZvCJJQmGzy9rZYG3IMvTN6FybMnMK3FRN0O4rwaJvAQwZ5SS1Muh6kT2Y1hBsub bQE5sXuoUswXwpzUP1Bt3pcz2AxS4zjTnJ3bOLkUdFpCTftQA4841kuoIdIqWzEskV6qZ9fF/Qgj GCnwduXdQjnhBfwGvvtwjyUfx0vbcd/Um6wJmFEFwBMPq3tR6Z29GI4H1yr8SbiZyODe8Pl2f0qf IlxCr8jgyEdrhax5ChIxswKLl+/1VRc4zxZXh4hy6eH2zaPoc3+dH4Q5y3bT7e4egFJNI36p40rE npNy0NzQXsS6kvQ+X44yRFdRZ2gWHFviERqCwah7/0wnaGgUEIvjvFVlWgS2JS9KJrxe6VXiuFWF pkS1t3yp4Xb/sUfaA/dHNcTgwzXM5GsNnYnse7EYDeROJ6xqmxqKyneLwHe6bQ9wF+4fwNtY6rqR 8lYE1IoQ/6Qf7mSHwDXV/dR3AcDMEbucc/AccYzFCuw84wZAIJkY6OQcqAJiFA7fLJoeniIJ7V1J Rk5FNpNirOQyGa7XkgztGTO0D7vHgQm4aSULGtxsnIo+D68ndPdaxC+ywDlINJMbVFlEQcWtH8Qg nxsZNflB5rL0N3KZwULrB5Gy+tMeZD8o5VzlVQT1AS4Tl2MH4yAyKquosGSBbMUlBLCzwJOBCdEU pgJUA1Suh1xK3x8fNyOAx7UBLTGCB2t5QorEQI/SuSnTeoYvvuMMUoqLdGCAZwHETzEI692gH5eV lU2H1QdwYZeO1BNvRV79b1PdFf+jtI0N6n+gRTrccyKqn9VA8DcZSMIsWjyr3BPPqOfuyFzFoT2a HuGk2syMCK3jKHOBWSLX6j4xZS2YkHLlBpg6wTUstcO9YJDcALr+oNk04/EojDUjaJcHnelzCrIW RszZeZWpcxEuhLKVdUg047ETVhtIPN5mJ9QZe9JbSS4aXyLz093oOuEtQBq7FYKvrpOW15FusSNP Y08QxGemSwzQUautYhFKOeoCBJDERqzDMJAXlqlp+HKqSqemVU12USN+sx0hDyycjQIf8AWQunKI dm9pG4NXqI6JWgWxzs3UVQMAumA2o2MIh256DoOWcGp6qgK5YZrtTeDT7tW7igyoxU6JyygUHXBx jOh7H0iHUqCfL0XZKl/8fPr11YdXrx8+Datlz0TEPRrZJtg+x2uQAcM6uZpllgGPOGmLKpa5DIA5 HMBdxmzKCOYh3+RUU7+sqRNrsVbhwwZ86gZgXZZcn9xZ8IgFF1V/vAE9bL0qR2hlTqkLUzN1ISCP Kw+7WJQMJsyEbh+S+t21NRmmW+NP4sb5jggZ7Q8bEZx4JaReBTlMPT4znK8UyPlWoOTPFMjVAul5 cL8fNYZDmFICsANgypMvOF1genf/5uEff7w7g1KsEIHH0IhxVEBjT/yvR00YTZSA9YRhyXhxqJ0w TmGawTLnucDgU+xX7W8YbLA7rCXT3zL964mAR7qYQEoBc3lijnE81lLZZzCJIVHmlV0YBzuZfZVl or7fZDZmkQenfo1/2ny5Ubyxu2Ct5ZnjzbxeAV9lvMEZ5bKI9SY8j9WCj4WDGBv5ClpZG3W9BNO4 4LwS63I+n25ZWnp+4TTohevknAJTtMaqyimHbjsrBnurt5wG5aZ63PsbL8ODsxMK5jZxscSQD/hi yXY7twAWO+5Kj2FKBYrJo3OQCGmx356/+FvvrjNfYf1MCfAgjwyEXL/89eOHt79/HFvzCrs76LEl HIDfgyYd3QSlzuW3QsnlppfZu5fjttIIlZfEVM7ekzv0vrvcWPxCYQaY5TwHU26NBCmyymb1+NS2 GGj8QixLJdr5yTALYLmCvl3h7McX0xWYFc8jftrCrN4Bbz+8ProEMPRmsBPBV29cG8xBsOufYVrh JaHGJ0c/l0D1VminhImJB3PMdtZjQWvPUd8c7eVmZvLIzlgdJGPfCscs4zqIAKP+vOtyMzT5MBdT 9g+6rB9sxKbuuHF4EZDGcRiGy7WJQaZb6nMVz+xlmeowhPp8ba4jY3gMwijNJkPG7LlPBC59in0v SMZ2G2sHzm0FRlYoMRCvtZBO6GVRzmvBIt0w2fGOED2Pn5rFZA4mu422JvOiENvQxdN7uVAqrKeo LCPIpHIlLM6h1xzW49TjNMP5v1gpPY9hHId0ZiGBD4Z7NswOUUqX//nx8S2uk39Prz6/+vQwMgUS CSext3w+1AUO9WQyPMeAw8GIutOPD78/3F+/ncjmuRCvoxy5DwF+7UK3BX6mC7fTYXFENSYuVUwn mTpQW1wozuqOd9P4gpEgAgMT68GYq9ML/+oQsJtefOGtjakxzTbFZWCTMJTa63Gqzii1tfMFnEhI rmUrFhMvZqudm6/djpxr7k7L8mqOi8xdl6BGSN42wLz4eUTJn35yiP3lIwZ1qymUQwhhjid4Ord7 6LTDFhSilTCaBDZvcfUg3S9/gUp7pBIXKDq/wB+PVQVJKkE1//T2ewT83es/vnfxu084++8e+Hhy 84jCU0I3RpnICwicuIJ/f/YBHricJY1/wX//ZPfg8idOyr1mBluUyVplOXlUGMG1Fno5RmY4gv9w Xi09biNH+K/wKAIzNPvd3CCHxRgGfDAwwdo+BVjQksajWI/JSGPHyeaUP56vqpoUxdcIexHFZnVV V/VXVV8NNoDJIc1BbdtNj91NA/lA417EfNDKr+flwTCsjh35elY+4mK99+Es/zwvD4fLwHmf5Jez 8qAUypRoEFf6i9QBVjrqN3PiNM1pp008y5/m5QHGskIiXRdOi4lOGR39le5ahS7tutGcPw6AHAJ4 4Fn+ZVYe3K9EMO2Vt2V1BfJ1oX/eXdBFVAvV0X+YlQehsZXznet6mJV3NMEa3ZE/zsvDXxXK6trw e1U4W1bmSrSh7SD+lbXXxicYcFzg4Sy/mpcnTlzGeO39RvR+pEzH3+28fCwUisPV6YJyVxJ7Osvv 5+UD5MtuNfk6J4/ejXKqjLoSD5i9Cl2FbrrP4tkpqibRXlvdHLol6L/u5ONuVp4YjFXhWjw4g4HJ O9e53x+z8hY9PUbrr8wvZwMGhlDFa+Pj6H4v9H9r5f+WmlJqZW/eWemtqbNyX6WpKzPGgsrLdlug i5YLPWhsb965wXZDk+DF9otWT53eNK2+xBw0cQpwDPDgrpq3Oajt4j5XKDeL29+WecDzMQd38Lgg esF4mmtQ9gWG1OwDzgzKhtiyxEpEkkDWc4VOQ6yLD5MYzKArGYymYIFRjvN+nysHRWDcqO/K4yj4 B+6hDeqZ0YvsmEccDItL+nzKbyN9jjiRtki5W/ze5AqCP0h8TULZE8mDtJhKxL7TDyvJkhHaVuds FLqytzByn6MCICT4u8yxU4R4F4WE7WLv/ispG9xGFPcVGgrzLoXMGiMtjAviRgb9UIfY3MuBTv8C 26cndhj+E+vyyHp84K/yvjuyi3fnFRZe5XQ+nOyUscAyt4Fc6H4n9VuS2aTY4eNXrGVfSNnP3EHv Qx4vrNWy4d+k42Ib3c2JFjpGMvrZ8faVeAGsFLkuR4hqCpjR1SgbbOOkQWPAlxvG+xF6YZGvOtIJ zq8BB1dMVtPriU+24V8AHRdO/tNbluKbBI8v+MEXo3iPle81i8qGI6tGaMVhvhIs/DhmYqRzJNq6 b1/JLj2PRznHiVH5M7eIyYGCnb29vx3m0SsxQbPSxvmURAJZ4HQSskWuxjDbVhDjW9SqUdgia3Xw RVDU8WRAgGYqEjl4CIMFdBApa+n1dIM7pwLxQ94JCPS6q7+tcyOlg6Aqy49pM0GIPj2ICMGIas32 AC2R61ES/JoRwuqjnCA9Xvggu5wkn2TraXMApgvBrByPRYFIPShfmIakjo767h1SG9ND6pR/z9lO wW58HHfjlBw41bKwzZr0IakX+bj7Is8UoSaOWdqbQpF9loPfsdX7/BbUePFJYpt8yvjqH2RboyZp 2XFostVBduzqjVjrhSXbtLqgane41LVGQRkGDSDyLYjsK6jFhOl9NC2dxyF8ChtVY0QJWM2pz2RA NDnrqVO1zmKdigk9f5XlpWw6vdQUKCTrlqoY/txkm6SfvJK9PYPr9P3sbIoEJSlvSNrTt10jtKfT HS8OsG4O3/pCqp/Zg82lbrAAIzGOw6qonJFoahXMfCMxJE5lFDMqhHwlUf0Cm2EBfNJJDFkDETPA aFlwPwAjMDgujJlzqaK1F964o86LN1Gzfk4fgUd6f+BfoPGWdN4lG/fy+on8C9R8SQjVztLqnt9g xJPa9Uo0iPqf8vJW9kNNxOM2af1NVpftmbmiOdKyac78VRRs0qGP6QQTvbl0qilzqppvzhrRjT6Y lO9b7m7cV6X7dhpfLUHkpnIbJEkZtYzZRVafMgFHEqQ90mpPmx30uoU0yPfYxr0+ExnuomznBqGE NNVSWc06DTrbUY3rMgEuFr1TyKmX3NX2eRyGCHNDQybdlQRGK1yBdZVtgAcG7ySrHKGAn9T0aHkv r8TXqrPUKgkz/YMfQUQUL/beKVS0DFdouZatu8beXU567+UjfCajAAbvaVWmvQc5art3KWLgg/hN MslceqM0Eiu8UySXsv2xd0CuJ5u0EbWHRKkR0nOz3TZSE/wxlK9V0TKAZFsnUX/EZdbEGIU1Wko1 4SCpdHthYS2pPHFdXGy+C1vGypbJtkCyJp8Wyw6+Wl7Z5X2i/nQYkkDLBaDd3dnJhHTD37aJppAw 66A2t8ieO7iv5ZT8sqcfSYLJelnqVC8n46YqX5jSlL4ZLrlWNNWlKSHLRwHjNr2nSlmn15W8Muvj hUO3nrVSomP90CmarYHmz7opYsu08BMI7hevMxcspGS9eeen5yoVLVwMMbn4uavKF5Vncf5jjCsA NBXROpL05hKROgQyPjCDVoqRhS0lRv7X/6CVGYxOn3uYNrqsqoq09Iw7OOovjaseF3N61LrHnekL 6zdXWw3oKj2remDVjZrFHtMz+78bvjbX83po15amqPR0qAnGnu+2vw941Up2elvqVGf/6Pk7vhc8 MaCmd61ewkGEM4vqrJEcEcQwjpyup5eYYEwnGjlOP3BWxX7g/js1CGoXCeiloFyPo9yCuMfg1SUC qR5F5CZNWph59uf57JTKEka8NHF0x8XsKFNipDIEuQfukp/vSMn9J5LPHs4TJYvsOLMH1du5TqZq SsC5VKWa5OBApoIqzHm2vYPReTBR3lLq+KrQE1hSTScP3EgmQ2lMJGjwERJCCNJBhjYpjIkALtZ9 h1Vo/S3nfQ2oF+xh19AfryWNCZEeU34OExTk/9LCFMxKH9R8XACsoJEMXXUZDT9qcSSs1HlIEFvx L1p8TEA5nNGSdaFG3Y16pkobXxooedCmBNC0bRSI6DjEQJglKuYzDWSfm4NEMfPMn6bIhQ2pl/gw w+0M6gZKtKt8k+Sp03+jk6zzSnjDE5NN6Zb8vV6dV77wwrbDeZlZ8MYhnxViehQvGqad7WohJYln P7VG1+BWSWvGlLnlK/OpOQ9VhwvSpaG0vPT+9bR0IHeAE/iqtaPdtH8Fk+hzIK6eD5CQ9wuPukPm 05ZNY6ouQRgvNlQzgGBfNkX+1SI3yURey3cFcw5FqGdvhosEXyDbrHs1eFrFV1K35JJGlpuKRkkj 8NpumQmvhMH2w1m1Dk76ZkHztSWXOhYokAgWhlelMXeoavE7/lZI9Q8I6OL9wJAeoQiYaqlCdkPw NIiBb4IQ5iFkvVC0ThSo94FhSkIVlFobIvIF3Xqk0fREZJw+cKbTn/QkGo4HpSAOx9nZ7prEpG1m yNQJxzFJ+aUMtJtzAzyD8i+S3r9etmMeVcbg6v8cXImguLGTzODVak5RhAcUqxLxfwy7cLoua7Sf vy4dCxpPyL7t9GEK8FImCr/YbtOf9WoEuu4K7PoAwq97hgS8ILEMXzwBYLrZ3z+87zf8kaJXOia2 l4H4Z3+jTnEo3XzhA750LwzZDpMF+q3FbOTLdPvoLDxoTnc5afBAn9czXQ5XrlVRqapM5iQnCNuc D22pSM3vT/cVg9BXWtmqb/AKuhclxIoHpim+F5LflZ0PsYmRCwOdIsG8YKSh1n9kvlcEyXDD6cWv NL3KmNtZvGm2yTArMy5af71N79tMdqT1z/ktid9xFeFiaUo8gTZPnzf7pHgih6dbNgITraIQdZya yV2HakY5MB/QNp7ziIUPporVhe1HZCxmke9MksD66imUgmf41LetmYapMjgs23HpvKfNjoo1hheq fdvNUhgRVceEVKZQ/2q4Gn9/oZ8TEyT+Khx/Q9V9IfRqQ3/3qcjiWuyCuVv2JLRNqCXJsY1VV5BX HiRXWM1ObHyk/9KBO4bk8P2oVImdl4aDMhWLCrUytEX6kFuFUCtxX/jfY+OkJT5qCF1HEstqeTzQ 2oF+tlve/wMx+oUry/lQ/x8AVIxMcA1lbmRzdHJlYW0NZW5kb2JqDTEwNyAwIG9iag08PCAvRm9u dEZpbGUzIDkxIDAgUiAvQ2hhclNldCAoL3NwYWNlKSAvQ2FwSGVpZ2h0IDAgL0FzY2VudCAwIC9G bGFncyA0IC9JdGFsaWNBbmdsZSAwIC9EZXNjZW50IDAgL0ZvbnROYW1lIC9CTkxJRUkrQXJpYWwt Qm9sZE1UIC9Gb250QkJveA1bIC02MjggLTM3NiAyMDAwIDEwMTANXSAvVHlwZSAvRm9udERlc2Ny aXB0b3IgL1N0ZW1WIDANPj4NZW5kb2JqDTEwOCAwIG9iag08PCAvUGFnZUxheW91dCAvU2luZ2xl UGFnZSAvVmlld2VyUHJlZmVyZW5jZXMNPDwgL0NlbnRlcldpbmRvdyB0cnVlIC9EaXNwbGF5RG9j VGl0bGUgdHJ1ZQ0+PiAvUGFnZXMgMzcgMCBSIC9PcGVuQWN0aW9uDTw8IC9EDVsgMTI3IDAgUiAv Rml0SCAxMDAwMA1dIC9TIC9Hb1RvDT4+IC9UeXBlIC9DYXRhbG9nDT4+DWVuZG9iag0xMDkgMCBv YmoNPDwgL0ZpbHRlciAvRmxhdGVEZWNvZGUgL0xlbmd0aCAxNTMzDT4+DXN0cmVhbQpIiYxXS4/b NhC++1fMkQTWiihSEtVemgRNg77bOO2h6UEry7a6srT1yjbcX995ULLX2RrFAhaHnMfH4ccZrolM BovvZ6/eWTCwWM1MAjH+4SfzkYMsM1GRwGI7+0PBh2rT9y302hSRUSs9T6JCwVudodTreYzS9nE/ 1DvtcQbVm7qr6js9N7QEb/S8wG+tLa42fzXdWhzBd+yhPsH35X0vxuWg/4TFt7OvF7M3ixm6juPY w6Ka4cjQ6DiLCfcZrjUmip8DZl+JOkFPWJPIK/gRQyUMIVHDUTuSEHoS46JoP8CirjZd3/brk0D3 AboPds37slvDx6451GLyxL/NcAL4HLWbUDtCbSLjngPPi8ghboc+nOBum3/QY6Y2zVeUoUxViCOL HAfKGEWmBJtT9/uyjMK4Xu7HYdWNCnB/ug9+bujSMlAi1PFyD1dJTgoXFdkzsE3bEtpcbU6M0ioO lgfQlkHnDDpXEtFeALFnIHYCbRVsy1PZm8Jnwdt6WzbtpNdvz5k2Ag4w3SYvUkAeJHnsc6i2YQcV /RyR40ngOB6HFyse2Ri3ZLNpS2fff0/eSTHNkVlplNnUevIeA01kmJd5XiDtHOzq2e+z7gzJRaZI rKMBMiEVq8gWHo6EDXm6Q1gmwLLEXLbkEcMyeZT4a1i/3IQ1Ui/hC/Pqnbu+2caZyGaQ+jxKw1V5 jQw3KVL8g55n+Floh5T+9fXbBVzRobqoFVd5zDiFaZ5GeXYNmYwRkzdyHVyaFuE6mII59rKvzEXO xy5k4DedOKodGo8ar6uhsjHsy1ZGeGv4W2qb0ELTy6ADXahHLivBpmfhELwtRa1+kkUoebWTIqYT LBcr0VzVOqHaVQ2NTBzCBGxD5K5c65RqWh1m6i6AQUdONUG6SkuSZWNpsC/lInV8mjhIseKmRRx4 SoBVTXtSB/lwlAq3R/BlnYSWgy9xRLnhzJAGDvFGYYVYkOKG5Jo9DOysvHTzyMaeMyi7UlVNuiAC rd2PoTiVCiggZUqtVjx7YTuw6WfVMi+EHsY4ocd/ZgIp7OxIswcmb4HB5Nstn+T0ejmFlUhPdVjf HXhiEp9gt++6yXo9Hr07ewzcGIK8CccbHJdbPc+5t+UkP8pqG5TLYRVG2JFYb3uHBU6UHrhMXmAX jXUIyOkLS3uO1opCG0BeX7DQJXOHF30klbnNqgTbsklNKsmkKHLo1PGgZ5FvADbCDUsl/+5EZcnC UafZ9UoN40DHZ5ficH+pWPE98iqC95c6wWct5MbRHafj0ARxEFD7C0ytTEkpGCcHDt/Ikrjmi+hf YKAf+7Vz7n9eSuOxotvchH4YejWeIz6g1BDEHb2PHL01aHYpn73Gcz2393pq8wl1eBhtj9pSew62 c/pYJtel0QGpl03SuArB1xhig922FT+j6u7pC5mAvnvmY+Iea/XboPVNQH1GyzsbwcJPH2T9DgLu jSigPh7AlIlzlGsGjycQ2+x2DYjxiPMkySXxA3HTjRWsZIEp5/COxSw4fg/J0k6WagjTFesEH5qR LrUckueE8lQtcxKjP48DJ51wcjQqL03xoUzSzyJ91CF5koRPigjpqMPR52XVOZ3OJ60t1j71pQSf dt3LNvAYcFmqOe8k5r3Kzp+n2iBpbybYFWlk09hbSfCKt2hVL5+tJhri7i2lnqdqOnn7LCNWMmKJ 6ySVrYjSMq00a3zRbdibNEhyhKw9K/W82ImK2A8yxzuzkj981MgLwaofeFF+KWHkk/iYkjcJVQd4 NaAN9mDOuZWcW8m5leOxL3A0vGLi213KeaxqSWELSeC5fzLpeNO8VWIaUSZ0T3qQ4Mn2/KEZhMbA GJb0Y2ncNPeafQF3dhD3rDH5G+5wg4GyU0QWW3oHUFZCb4aW1w7c2NvPWrQ8pfF1bf3tbeeY75je 4uGZ4qn+eCoE1CINlT/qZparGAGa839f/NriSj33bAUNoVp39I8cPq4Gxkj0UysqjuQxcWIO0kF4 tiTbh4tZdtit+DlErrbkjlU5QN8BWfSXPjYl54udsJIEx3TAvwIMAIK3Vl0NZW5kc3RyZWFtDWVu ZG9iag0xMTAgMCBvYmoNPDwgL0ZvbnRGaWxlMyA5MyAwIFIgL0NoYXJTZXQgKC9WL2kvZXF1YWwv YnJhY2VsZWZ0L29uZS9jb21tYS90d28vZWxsaXBzaXMvYmFyL2JyYWNlcmlnaHQvQy9QL1UvdW5k ZXJzY29yZS9NL0kvcC9qL3EvZzM1MzMvcGFyZW5sZWZ0L2cxODYyL2cxODY5L2cxODI5L2czNjI3 L2c5NjMvZzE0ODIvc3BhY2UveC9nMTQ4OC9nMTQ4NC95L2cxNDk5L1MvbC9vL3QvZzU0Mi9jL04v QS9HL3BhcmVucmlnaHQvZzE4MjcvZzE4NDgvZzE4MzMvZzE4NTUvRC9kL2Uvdi9nMTg0MC9nMTgz MC9nMTg0Mi9nMTg0Ny9nMTg2MS9nMTg1Ni9nMTg2NC9nMTg1Ny9nNTgxL2dyZWF0ZXIvemVyby9n MzM5OC9nNTYwL2c1OTYvdS9nMTY2Ni9wbHVzL2c1NTkvZzU3Ni9oL2Evcy9iL24vZy9mL2czNDEw L1QvSC9SL0UvTy9ML3cvbGVzcy9nMTg0Ni9nMTgzNC9nMTg0NC9nMTgzMS9nMTg0NS9nMTg0MS9n MTgzOCkgL0NhcEhlaWdodCA2NjcgL0FzY2VudCA2OTggL0ZsYWdzIDQgL0l0YWxpY0FuZ2xlIDAg L0Rlc2NlbnQgLTIxNyAvWEhlaWdodCA0NjYgL0ZvbnROYW1lIC9CTkxJTEgrQ2FtYnJpYU1hdGgg L0ZvbnRCQm94DVsgLTc4IC02NjkgMTIzOCAxMjQwDV0gL1R5cGUgL0ZvbnREZXNjcmlwdG9yIC9T dGVtViAwDT4+DWVuZG9iag0xMTEgMCBvYmoNPDwgL1N1YnR5cGUgL1RydWVUeXBlIC9Gb250RGVz Y3JpcHRvciA5NCAwIFIgL0Jhc2VGb250IC9WSFhZUEUrVGltZXNOZXdSb21hblBTTVQgL0VuY29k aW5nIC9XaW5BbnNpRW5jb2RpbmcgL1dpZHRocw1bIDI1MCAwIDAgMCAwIDAgMCAwIDAgMCAwIDAg MCAwIDAgMCAwIDAgNTAwIDAgMCAwIDAgMCAwIDAgMCAwIDAgMCAwIDAgMCAwIDAgNjY2IDAgNjEw IDAgMCAwIDMzMyAwIDAgMCAwIDAgMCAwIDAgMCA1NTYgNjEwIDAgMCAwIDAgMCAwIDAgMCAwIDAg MCAwIDQ0MyAwIDQ0MyA1MDAgNDQzIDMzMyA1MDAgNTAwIDI3NyAwIDAgMjc3IDc3NyA1MDAgNTAw IDUwMCAwIDMzMyAwIDI3NyA1MDAgMCAwIDAgNTAwDV0gL0ZpcnN0Q2hhciAzMiAvVHlwZSAvRm9u dCAvTGFzdENoYXIgMTIxDT4+DWVuZG9iag0xMTIgMCBvYmoNPDwgL0hlaWdodCA5OSAvQml0c1Bl ckNvbXBvbmVudCA4IC9MZW5ndGggNTg5IC9XaWR0aCA3NiAvQ29sb3JTcGFjZSAzMiAwIFIgL0Zp bHRlciAvRmxhdGVEZWNvZGUNPj4Nc3RyZWFtCkiJ7FddcoMgEN47tWdx+kTP0slD7FnQh0wu0pfI dYoY5WeXhSWJnc64mWCi5PsTkBhz1FH/q4ArdN0kn18oi1MW66qwmAcT6yrk9czCsnfRtavHRl1Y JCmcxXraoBAp58lYWem4x2FUs5qGMdFgcT0tJ8ujybBEtIX5hvMu9733jn/LeFz6SIV7BjxAaFmB IG9cTpuflClZ/VqW9xgojmlzXalwW2ljJxX3Ucb0mC5M3AU1uva6nitihWPJYV0BLAaMAN3g2tG4 b4bBCkDWxBxWDwN0XX8dTDf2ZrjOWMYehxSrXFYSzIbmdnBtP3uEGo8osN567MewtefG5SjDKnPV F9yC39601v6bhinVVXh2aFAAJ3Wyb9CTnkKsgfF4hzYxFlEKlIJLoqvs0ekCq+tbJXC8LiJNy+7r Yk2C+lTzW8GU6sqHtXqc4leY14/QI1foPiZSwg+GWsRnRQOVCEu7Yp0TrPM6yuqwltExd7DTRcM8 eeB9k0XrqsrL6YK3D6/rq9njptSf1rVY4bhfOi0NuC36Zj99DlV5rNyEFjtkGDK8jE9DLCQyW62V bpVw9n4VMuSihC1mt2rZ2CmsXFYvyIZike3v/V5OILAcR0VQL6hWXZS8ItZy3N1nlhR5JFeMBo8R 3i42ZbqoDjGWyVyrI2sXznfdc+xs4GVKLoxH4qCGD8MljiKrGWOFaogNlJQ2npPRGcNM2O0Pk8yj BwxXenRznhwtsuEnVp5M8kwJyBYzKNDtTyGK40ke+byakY866qg/qd8BAFzOtsANZW5kc3RyZWFt DWVuZG9iag0xMTMgMCBvYmoNPDwgL1N1YnR5cGUgL1R5cGUxQyAvRmlsdGVyIC9GbGF0ZURlY29k ZSAvTGVuZ3RoIDQ4MjQNPj4Nc3RyZWFtCmjeNFd5dBvlvZUhkoYmKBAqPWeGM5OW13JKkwJ12rym NA0kJARngSxeE1teZG3Wvu+L5S0Ex5Zt7fu+23JkW7bj2MFOAmSDtGxtINCUltO+B33n8TLyG+Wc N0rL0R+jmXO+mfv9fvfe3/2qCOseIlRVVW186fDBA3v2/fRFMbut+9DxyqMtJWgDtfTkBtr9bdgn T5Lf+z8z8U8b0UcfQ3/0+NiT32duIjxUVUWhPrvv2HGVkLHluS2djK7vVhOq8B+BUkXYBBB+SCQ8 QyBsqyI8V0WoWUd4CSAc3EgACFXrt+APnwdeJB4gHKw6UnV0XRvA3WglEHbgeAibCU8SfkKoITQT PqgarMo99IOHPnr4ew9/sS6w7kPiIIlKGiLFSYukd0gfkilkO/lbQPdI3SOsR5Ye+ep7K+u3r09u eGqDf8MXj5559KNH/4tCo/yQEqPc28jY+NVjpx5zPc54vLBp/abtm0Sbsk9seuKFJzrRp9aItDVi eeA+kewu/S+1xCp/WWaRKNinFCyGrqBc6l0sUkPG79FjtG+efppMKQFrHdSjJG23iNvF6eLQBU1S 4Jfk2HjKnfNn/XF/wA+UV++SKehP71DH3Q63y+1yZVNLs1eXi9OxVCzlT9higD0+Ek+AK4qFjjyc 7zju2w/tP65idSDtLGl97ytfmquLjlw0AkciWccMdC5jkESQiMTOZ4EcHVPYBQu66hp21TZ2MJhC rrBbydVzLcp++Rk5UOLfIVFQ4iy1a3pJ+S703qXgzBxSnA0tvwPOG/LSFCxNcfz08Ywr7PdEAE9k NJEEM+aUOg6rEuIQxwN4OKzRDuhYs4bDQBhcySnja3c11dYZZyYUBAKhuC0HZeNGeRAJym0iDtih 5fEUsJLHNnVB/X1vnOlFzLuI1nBgyAOdy+qFUSQmcnA6QLqOxefDfAFL1waxeLagBJEE1ROmxRpD 9ciRcHOBAVBKz9LQ3/7n7WdKnXvI2B/LncSd6FXst2RMhg5TURn6IRHD242um8E3tqy6Bv3h3cSl IpKf961cA2/KV+gz8Ay9LngIOtmi5dGRPHqCiObvYChpX3ndZwZHwOsJOjY7QpGRBDQ3qePHkDjf 2dEI1mnb+FyYy2dq2iAmzxYS47g0WUvxWQuOK9RUYOK49q1tp6aYp9xHod1HhMdbkIaDoqcxBMQe C9XMnYBPzF8WfgDN5McDWSTrjyV9ecA3NT5drIBqx0G1NwZfgzicHi0P6daIJHLumVujK+68eyqY iAUAVzAyGodySb04jDi1NvEo60/WasuKbIaZBrAR7DY1Ecs6z+H9r0COChydjWCDvl3Ig3kirpYB iSRWlxSROlUBfRzQx3vxXs458/E4TCn9YO1haktD26HO3Z0vdu+S/1r+gnHf6WPAl6ThW7br3ivh z3Ofzf6xeLt4bW4BuFnu2EGmfIR+TJV2GzpPgoeC9TNtcNvMqvwW9P5qoDCDzEwHl94GZ415aRqW pjmhVmfOGfN5wjiBxhIZcEk5y5iEJxiN3oPQoUYVqwvpYipb60H2GM8jhr2SmHJS12pkyyTdAPoI OksNBOO2LJSJG2U4j2Q2IRfsNgrlclguExpZEEtgC8gQedAYz4BJWzQYhGXYZWoslnMWoJmcThhH 4gInqw1s07GFQlgorJBKKB5xSBCpQ+U1hgFDqDccAQuOXCwGU9D1OWp3bk6zAi3POeNTyFQiUfBf BPwXx3//V/Cu6YZiDlbM83OdESDCoDtOQa/WyVrpCL1F/vpL4Mv+owU6TC8syi9DE5kxTxJJeUNB bxzoOdPXD3b1Mc0suIdlFOjleoVarTAAerm0VwhxRWNeBaLw6uKWczss1dZjgdYJfOdj6KdUvoit 64Da2c6EEBHGdZNF8IKzkEjD6UTWPQXl01q8zzGeo6PS506RAKZc+Zr2CcojohdJn2H4hUDCimt0 4lMkLH6fjlO8dIbqLjrnxudtnZ7G0OEPsaZqbIBEuYJ+TZvLnx1NI6nRqD3gCri9QWcCcCasqSxY MEw88AF2gO7IeiIBdwzwxEYTqYoPKJOwMikKcZyAi9NqPQFhwft00t/WNlDRp0hLEwOWABKweAw2 FWBTjcgloLhXblDDerXKKOkB+lS8gTYIe5a0Yx26k1TM9feEkUiPT+dQAE6lVSICpX1ysxo2qQx6 nVlrVllk/cCgQXa6G8L24Z5FLo2jZGp3V4u2DqK320I4iYKCrLoIqObMy2+D89Y51yzsKkZzk1Eg NjnneAtamDJI8B1KwwxP/VfBauV19oWmCWCy6Yh3L1R7VMevQ+r57W2CYwD/uO7V3eB+R23kNThy ZLJlgQt0L7yr+Rj64F1/YQm5UJi47P9ka7haf0R8iskDcCzoXdosXr8Mkh2N28PusDsQ9Mf8cXfW MQ04pkfOXwSvmleUi7ByUVBgpPgRlqd9HLDy6UPHIeyN70r2DGml0GeKIjl9UhhuById9td3gyd6 T+kZsIGh4smkGo3MIDIDZmFX/0kI24b3rbRGu1OuRQdKyJ0yggpLO++UnffpZMpZ9GUa+gn65zvY n1FJqfpOWVF5is+k12hr9K2V/yUP7Q727dqGBzeoHN1JK90jox3le8TPSSij9Hdi+e9/WaNjT5Cx 3eU+VYOB0SPa3BM25jTz2G9KZ6uxH+KoKehv/4zuosaOFVqWuQBn+YrmJvTOJVdiGbmYnJ5JrAKJ Vde134O3dFcFq7BgpWO2Lg2k6o64D0A//hX7lVqk9hXuz7D14CHnkdgxGKWWfkqdO78augEtTBsk eSQvSXB8rQA+fRpeB5+V7j3VCDeeek28F3r59cj5U8jJRenNL8B74Y8X5nDao7tpaBE9SP7H+4Fp XLTTvqUr4IQlrU3CuoQyJPFI3HwbcwQYFjPfbIaw0HclryXNJAf7XUjE4te5ZIBLPirige16rkgK S8WtxsMQdqhCNfQlGnoLfYgc9p4eHEdc/c5el9lpdmu8Uo80xInT/4b9pBr9Hgl7DK0X50VpYWSz 3q60i+03xy6EMlkgk3PPXACnTBOKDKxI43JxAA5O00gthL3/AMjjVFROWp4yynAByOxCNijtlekV sF6p0krwdos5/a0Q1oq3+/N/UCNdWf6sElDOXjRfgy7MjfnOIQVfOhrIAMGsbSIP5k1ZRRJWJHjh Np/AUefe5dnlafaoPIDSYw5EwYQjEg3AgVjBdgl6q2CQxpGE1M0ebvmLtXpw2piXZWSZ7kg7PtY7 To7VQc2tPZpOpEPNkyi6ATnXxOkCOaN8jxD2iCLSrCqmm9Ne117TzBh8lqQhoHNoAIfaqpCBMotc r4J1SoVWYASMAm4fE+rosjq5CMcl8WpDmpAp2T/x857qM80OegQf5mfRe7S1DajxTvnqDtR4fwO5 Iu8ZdIX6vPYwPnC7eU2al6EO9qhbgAjcipAhARiTvcV3wdLzW8s/J+8eO+Jthb2tKc60FJDOvGW4 Ab33liM2g0xHEznPNOCeHr10Cyz9fCsZF8xGGprBHfEZEnai7NF2GjqNnZuNE4Yp7TR2uOSp/ncS msSdklLaSfsryei3BPqDwEBgcOk2iD5CnjodG3DBvWGzX+/WuxUOwThgEzCHW6GWzl4DG2HrRWqV VCXT83q6vjBUj026on7cGP1J6zQ0mzUpgohHNypmDrzRYwDZhnrTnh52v6hP1S+1yM1KvVKvVRvk gFHRKxGDdBczJYQFqVndKpTNjNiSSNKe8mXiQ+Jh+ZgSkKBKamcf36SEDSKlQqgFtCKehQ2xRKMu NaJym31h0HXWOWqHRx32MZfVNRIdmRi+OrZgSztwt3r6GrUhtyB+G3p7OXx+FpldCL53F8z35YwZ 2JTWxZVhVUjiFeAc5fNGuNDRZunJLgQdq7lP/5RcKG2lZuIZTx7KZzRcfPZwHY37wQO6RgEH5gg4 agbU3BUqChB1rKf4Dviu83w8A1O2oPe/osqlfCMborPcKXySpfWL74PvORfjKTgdm3AXoUTErA4g fpVLNMr63FFtWpIWmHEgwTzlPAa1tpnkDKRLzueq2gBlm7npOLg9eGDmJHxqZlV6C1pZ8GSmkHw2 Mjd2+Rf26t5WLVcqx3OYAne6GsxG1gYVHjG+GYnA2g3RGUYpC2HLRFx1G6BuM5+sB+vGT/raYV9H lJvD2ZPLGwvQ1YXohQxygIz1lLZR07G0uxKp1Jw4EuM46/eCtfpmYTfcLeRoOiEGx53BSZnRLV4H bzoWo2k8Sz30J6paKjRzoVamK8lH+CnNzMAqUPo30vgbo8PgF7LrrfPwfOux8D5oz+uS5hakpVm2 fzu4I/hq8SR8cvaK9CPoynlXAt9TIlZwLj9nr9Z3qYRSNYC9hn6G55pKwitOqNlxxCuzcc+2Atg0 aajomojHgIrD76GV6r+5+eMFcmo4YLfBNpt3JAa5vYMDXsTxMXGEJxwSQwyeRSdHZDqd0iwDetUD IhZ4/Df7PynXkynfYi9QBflF3TvQ0uy4L4dM+KNRdxbwZEdXb4Ol4ztryYsdjZFDUEuHUYpTXiqq dEXVZm5pBPf4Dk/Vww3n3hLdglYXQsUp5Oggo08NW3haGQ5fI+vuacc/PeqWI2q7yT8Q/aW9+vQx b1teCFwqfYAXOoMXeiqr4SaQONfZXIvz6kGhBWxNJQM9YE5Kv3gD59V8LIVHtZ/R0AlyYTg9HoLH Qh48sgCOUNgahXIxk8KH+BRj3FYQu30XvU2+0DtliMGGqDwgcAEuAWeUAR1skDS3I6itpjIAy1T0 Z6Uy9Zuap8l3y2VqyV1TdpNx4uJfaCe/fRl9EfM+CFN89A9oE35YwEgkrBNjEktbv1u+tUK3f81S fFWQPD88MRaBxyMuXwBnXyBkDUOZkEnpRFwKK78TxL68i14kX7TnwxE4HE7ZJ6CAp8/sQlwmm2FY C4xohsQsEPvjXbREvqybFcThhKDTWQ8dOME73I6YEuqg2A24JVx8IyxejxavjEam0IiB379QAf7P ytxwFmMhOBxL2yehsL/P6EG8JrvWqgasqiEhE8Ru3kV/Rz43mBhww30Rc1Dv1XsVLpENsIn4I93Q nuOCowzkgwfv++Yy9WTxsvR30FzBFsCJGUgk/FOAPz++dAP8VHq1Bedzy+uhPVDtCWVnC1J3Srh3 K1gTfKV4Cr6B/jc1k5hwz0KzExpOAklwXE214H5tIx83DD5T3YqLxJ3BRZLR4gq67lpMZCqNxZqp 6AjZpfRpQ3rAEI72JqBzeVtoEpkIxjK+acA3Mz6/DC6ai+ppWF0Q4UcMIMTutLVAHL5Fj58W9XKF UgTc/PX9djK6sfQtNZfIeCbxvKzhxCoibjoAvqxrqHiWkP1PEacfuNL56+AN54VEDhexEoew1v7C y+SLzIZYLdTOMMpxustF3RW6t5tw4/hl6JXZJrhpdln8DhSPjjjw4e3wuR0+ABslY5oSSs3gzpGH pjJqFk5olrN+H/jqA+fgCrkaBtTJ8eDOwced40bFCivOgcXQbTQ0TJ4czo6n4RG/ze2yAzaXd8QH BQK9hiCSuk30dfPG+JBc2WtQI2qjUqxgAn940KMtX6eogtwF3U2oMGF1ppGMEz+yRwFPdCyWBJOW iM4P6/wKl8QmHqc7D3noNtGoeUg7Yhy1jAGW8f5xG+gdc3scsMOTsJ6DstEeLS4hrU1+VvgF7qpZ U0zn1/qlbp4NsHczRzogoWjAIkUkFpVZZ1LptRqTAp9dfXIpKB6ROOSwQ+FTRwwRw6zummbekDQ5 egCPcUyjAGUmpVIDqxW8HlzU3WM+GSLz6mJ9ue266vHjwfYJwQMXE3xI1ZvePGtBLMN9wwOjwIB1 0B0B0dW7N2vQA+SaOiL2/Vf3X8OWyHVn2VY1bNXYdV4TYPJE+tKQLzg0HEEMHxMHNfrTZgjvJQ0X NJYkt/RxzBLYJNWopDpALxVbRJBQZnWoELXD4O0NAQPuwdQciJ6rwT4gM94UDqnhEdGYzK52qPza qBEwxOK9KTxaJC6fQ3ZV3KFIQxtLbuLzJAzA3tcxjByLEM8Sxpwhgz2MXq3eRkIbym5iJT+O0L4t PeWv+Qy7SvwLCd2BL/oF6Xlsmf+06OvfoBfxN/wKW1UfMLNO927moev+A10iPkdCn6ss3oISaSiC NkUY97DtxHskfAgE0b3oEHEL6RcYxaDWK7XyzWaXwacN/grdWI0RSOhebAg7igUra9djXdR42Orw IwGnN+BK2APuqeAq2lCKVNeQsIexFR3D0GnCE1BBf06XxwjocgV1Y9nbbx60DPZtNrDMsl6zxWAy G3oBi1EzoIB06qFhJTK+k2gJ+Po9EGVLSUL7COsls7sGBzqQi2+jOfRT4qXyr/eiXeR45sybkwh2 u7yRuOeBSxLWqqinhfi5TtOj1RtVlgCrOukI+p1RYNw3nJ4Bb2/7EZnyxhuk0vL3S/9D/X8BBgAY gbbFCg1lbmRzdHJlYW0NZW5kb2JqDTExNCAwIG9iag08PCAvRmlsdGVyIC9GbGF0ZURlY29kZSAv TGVuZ3RoIDEzMTE2DT4+DXN0cmVhbQpIiYxXWY/bRhJ+n1/RjyRg0exuno/OOA6862ANWMkGSPLA kagDljiCjpm1f/1WfVVNUhrJkxlA7KPurvPtL1+sWR7urEnp3xqblGmdliZN8rLOMjPb3qVmeffT lD7T/V2apC4z0xktLEFNn+/efnCENl3cWbqrhApWeWZKaxPrzHR792f0HOdFtFrHtohmsa+jlYld JsvHOKuibsG/uF+e4tJF+zYussgc4yyNVrT2kTnE3hGKHBDi/LRhGFzuD8yAwIkACIL+HnfNmCtd kRhEY4klwHZtXJXRHiIAeb9liIZ/OiCCn4n/NtN/3f08hT2SlLSEKdK6qtkWpG3mzfTTNVsUdZ3k dZUXYo6Hb6LdKp6QbG3sPAvsk5pMQAJ1OF6wvo/8s8d+2zDccY2jzsQlgc8YvNnxyfE0gLZ8PE9i VxCM+TP2NsriKvo7hmEcHYJWxz8NYeTR5hsb8DtEmYs8dJzY6MikxnLu+LcdeC2Y+lhMiCTkJ7C8 y4KK5wYMvpTZAva7YraqStKyDF70uGDXMHhQcYeW32j/xI8mSzPyqYMYkJYbxoB3zfGqcKt17yyd eRAKhEoPTj6zGjxg/xVOooCiHPNnjba8Ejc8KgsXTQiGDDcIIm54rr1o7ov6luZlkeR5XlSi+W4T TypmnBMjWi1EJPbxeEK/Wz40OMCV+SNmfUikzjzxAZQVWEh6Ai1QNaI37i5hQbED9REUKCT0uk7i 7P4zcfsIvn9F999Y51lPvuWfA3veZ5Epp1ca22JCOttcfSHNrb1lkiJPUp+x17BJPsJBESy+pu+B hEoKki1NID0OTzFR50QjsGQ7ijLWUL7stgQdSPwVKxyCsYyacDGPKwIzn5xEhY9mjVKYMWTBAQLA VjG3F4wO8aQcPq1IpTtD+WdiswRvaRnarF9TCl/l/YpS/EKsy74XUfkGvBOUExWJRgYJVeMX75SF pOfYNa+/U+6T3Dr1XObiEk6sdULusiMx6D7sn/DbknpO0qGv6K41jWLNcfNEOLRpOiLmS17p9RLX LcwG/2dqC+G0URhy9AS5CaQDRi1nZHbCmwV6s14CslFB3+RK1Erdy7TuOVHeQXOfsQ2gd5lcYH4i pPwSqfAJfge8F1UmdTX/qdnTurzBv4T9x6TuH7sZZb6K/JVdhpzgQHp7fmQq9NFjZ67lpNwXP6zs RZFQCBZkL69p+WMnhXclKZAzxCHWErxrOPx3SB77N5IyniVzcxKd4/MkJUIyBqoJYxqgcr3StIPj M9gqEqAdEEYpC6dS83FoRgnzhVOHOpQWr5Rx8n9XF6agfTkUc9KY9Nnil2XgLuJJDjvslrAE8vYK B+SwtZjnRKc5jFZBdyfL71g2DHYMp1zLqP5AxYW5x+IzKuxvwdj7gfoBN48nOiq5a5oErg/fTA9G 8XWiq7wUrkHah0dhurpastyN/KzGyanTcUPJRh3Q14CLTMLzGVSVdagO8JjLsmZQWX6LfUoty4RC 10YPuD6JR8zF8ZpA5CuooLR1c/Gzpudy7JsAQV6ihB/lHo3LROvTSzlutH7O3kiCwRhVmZRDFT8w BzRao9ZoRSJL5ySN3bA8wSwWfe0ZILqpZo5r6lCS2LI7saDTcbeWlXp6iAPJDTkcqRtaSHK6NXpF YSPNpwH68ZKSrCE9h7NVWZ6Y1HrgIKe3C7y3nDZ+ZDPqfNxQ5rVYzVAB+zLLvT/XEVrutWZTP+JQ Tj9IzVyf1cyLmrfR7zeplW8C7rPgaoGmZjKUVK6Goajv5LZBrcii/VntJz8bmoHbbcL2ZWeAxuMB nJR/kPZZ24Z2qOm3RpEb/SQlOZ9mJi+oFehLc3C13h8n5BDynntaHalHpGfewCu+98MHQ7PnjFr8 OeMYwZSguYnNfvcmdohSxp+zA5u5dOpIYzx0jGg3jC/TCZxMXM2MYgWpbw1/pYknvTSOzUpN67a+ lda95wLO/uR9sM5ZKGEoox92lBQVrO7HobPw5S0WEFNAGrPFQsc9XHPwihKYnzhOPbyEp7nqbJjT kZB7F8K5p5/PMbI+W65ZxJWQWHcD9BH2Mkcx6UUoppUTb7E2d69WPDFNZpPa2kpj8oGSZAK1KXpQ nChqWKdJRZ+lfNqYOzVKXdxHrRS0xQ4vtuTYyBI2GagZpSp4R6X5zJEQ8OS3U1rml1N7CHDmP1/I oxiTEj8M8fuvv745O6oDpyD3o2yf5DNooWJMbMmEX2Yyr2Nrzqvr0SZWo7Ll61SNpsME+cM7DmfP xZs/H3WkoKJTcVeG332A1WTiJbtEgQYShI+Qrig3H4QUJ8ky6jGwC5nSwxmFNL2m15znufuVbOij 8G1hrzx6fyboRAX9EpiB3OpcorkCnfQbSMI7+WAJ/a4MFnUoqUXdO6X9sVdSa1sVZZ33laKgNoH6 DMog0sjXoVI4Xkq/zz0QtcFWh4g64LVoL+YB5hEwXdj+MQbqT+8BtO956fn6qKTNlyATefpIqDNW J/1uFKkV4EA1Me/HvHcK3ULNToHmEGQdtstBC+/HAl9p6Jx7ve0Vc6f07FmR2zDYXfRzo9Zqwb4q /RO6qmbUf00quemQxxGqAB9171tcvUOmq6KPb2KeGt7rdvIlPmvtwRyvrH1ctzSH2yAyiUhvGNpu /rlsWlh3d7OawiBZTYnCkVnEIDvhbnTKOEHJcMjBUl/YjDj+ToL2PS55YsmPtBgaz5E5Apjjcjnq I8O0s+3NO/TcUGsj0FkYltAjhxksD/rrqEX8FchfzX1WS0ftyx92GlmVJT71hRfbfG0R/jZqd2v4 qNVUZpEQSGlJFBb5DzJgN5fLh7PDTRNwZ610fVRA/9uid8h7qJ1yDN/AAC1fzVUZWdMirupor2Br BWv11ohACxFED48KFJACz3DeLoOWPRkhIMQC2rVwzLJ/mP2y0iVlZW31Ihz7mer1OJDp5sxxZbAa X/djEgDMth+5vkrgj52YnEawxP0D6dH1eZAV6U0/Ei0Lmzgao7SIznvddgigvc43OrjNB1+n8sZZ A34+MsvIGkbjBFmL9UDNe4ARLsZEagSBvcTSjIfasXG1Fw3sMEWpuAly2HQc/76+FmAaX69EV1Yn pS84P7FV2v+RNSaUQNA2MGeZVaK2O7IfUsbg+JNhQzycVKkRgiWXLfj27FGPkKfEp0FLzqihLbnd nUjOcD60xXwAx+fQon7iK06Ei6CiKVACzGQRo3byIfcW5BjUnE0ASqWZ3IxvTiJNwT3FVUuFgbLy 5asFTKxGEelsVmm/EGaz3Y7U8TbJojCTzfoBD9sjJslwKbNgmMR0fEuoWmFyDOfShFKnM5oGY3RC /bgoTJTACTw2OsuGwU8v5fn4YntDCPA+BtJNwG+pf2z0MJypGNJ9Z0hsXIHLkYqB7ro3gHz5fRMe E1+8RSFvUadV8eqwJW/hqKXxuffjtyikoc36rShEc5RBK1qwu1SQgM1RSCtaRLNVgJvrxUm/m3Wn V0s9kRReSEuWRT0mvwZPsrI96XcjUGids14capkDWZ7/RjeP2G1VfNkdddeGZr4I9C4bDlfm/9CT 2RmsrzT+d+IeuYqR41FzsB/ORCjkrZQ+nR7zzJCTbAIsiEFQPn/CyVqR98roqPsTbhvdbcw2LGec MKnnHBi1YvlcCnAe6S5QaoN8ptXFYiRR4D+jRVYweCB73OgVkeV4ooYgt0zmZW1l2779kBmqq4s7 qi0wLA+3xlMnVxZizCq5wPxESPklUkFl3p3hvchQ9JzMFsvS32Be4mHHdN7d//v/nFddd9s2Ev0r fNpDnmNrCYAEiX1Lm6Rpmro+cbbJrrsPtCRLjm3Kx7acur+iP3nnzgwoipQ/Yj9YBDAzGAAzd+5w albpwW+fP7x5/dOvdJHomd4cfOJ2gkB0tBeVSGXzRahlKytbhYluxh84KzGzyspen8h0oGZ3SUHA dNjbCerVfjFhjogXRNnHKuIIo3MeEYpwJXG+p4C5G8bSmgHNgnwRKaNqzaOVjqKpW9XHi9PPLDm5 T+KcuISVGqYPqH7SuNExSVFK1J0Hq5ZWSti80BW0XhZWp2L8TOejxXaqH/PkrUqu1u0MVT3vubbZ IFmdAnzqUdbmubauRe2N5q+ziJvx3VfEioM3+tRoHwOfNKh/KLY5U13uF5J1mwEoiY9dU/XEzE+Z MUwhedhQgaeEDHxBhgkmy0/AfsAwvZEJisBcvipP/RQbb6JxfrhbdUDcmasDfO9CvZnf8mbRV91M Xb5QT96JJ1FoIUJL+RlHrrdye3mwFrc3vjRPsFdZt4lZG0Mj0O902VJclYgO1PEKcba4R8Gg4N2I 3cWPTujqUr/iSgtktLgIym4K8do7WvH4PETIlmw6fjWqRVbovCSD+MAEMxvYXYq9M91GzUc9tCsp RZz6Hp24ViP8zpIq/d02PsqmB3rMlczj3dn33ehHkZkXYXdolvTeoYwNmyXMepURdeR/uflv5lPq NYTG9o0/AKiU36VGefgeQO3pjQHVMcg9jKI95Y9zIplyrYxw1ygYFeAAHZkphnnMNKYS8w8iJ+qM RuGx+d/oiv/51uzS9PAqD35LfweCG80DV5tHENxTV+md27YmWGfw/Nx1UvTgjJShdwJgTOINWtOZ /jYc2pv5PS46pPpKMr4zddBTkBaX7QlM7EWpjZbgzuueFgRuOskfGPQ6wX+r4DX3Iosov2rPBYp5 pRYHRSOKCOzMuKbs8Ht8waG74PoJmIZHG5iW2w1aC0J6Jx4ErXUBbNHiUCdS2EIaBS4ZAwHTKoES O1g3ehvUOX3huwhaowhYkyjYop/g9/qR+4rARTk+eEj/Bew1Aj2b1bh9/F236GIhP42Gb/VM8Wyi CHdrsGzUuyj6Tb2LY36XjbPJ9EoPuR5XSBvwp/dvbLUb6HOqwhugp9slVgSijn5lOZ+tucI4rSwV B4CT+kKXd4qK6KQmOXGOmJJq62yrNnV4oYaiwRkbbETlVifnMpQ1eiKKMhcn233x6ETsyc2AA1nD QpQxsCoOLuV3xYbUkdvhiVhkQV3FloMDl3Ye9VJMqWHJr2pMVkz3CAIy7gGws4FIelEXtTzGIbV+ 2Im6iikdnlsi6nIzI76n7QIbUxEElSD/qDO6xf8lSbBo4lh7hnUqfT7qZUaOJVIs00KmYXURWmVG J+njgo1PeaP2dKDKX7ApToo7GCe/4wAwhxJrrW663rY6qjhlvK36ifJpazspKlNpRzbPTJ3+SQ8j X1N8rfGFfBNuhPaQJtqEJVr8u8MRZA2NllEJ/LtkPRW1cmeeHhte/5GiKv/+5s0f2SOJxxXOcR+i NXhnfaHiMgkWBWZwpL0uogSIrEQf8QS6Q2q8uvWrRlNS41+zgfVSYz3lDFaNCNFGDxRiZSwej7Dr xj2Vc1cYde/YjguynvPxqjyws4OgdoU5PKswDwxS++ZQt4QGUiAnH7JScZMU0/ked7JSwbQYyBhZ csTdrVFiR5O/aGVnnrixeqO7LLkRQi04X1/qWqM7qcpeNHX4fNtlNF0bHKEzcaAacYu7r6qzutWP 5Kg7+EIjZ9mdeJRveR0Tzj1Ro21ZTUqTu1Jr9JLDD9WqZpLPrPiM6yunTNkbJv/JmJGT146GX0W4 VQtn50BbcGluOZOj9dXVSgxcI3Qj+0ZzGBXRMi5EJjlS4dNt4eQjezaXPQnRtWPhN9ec+JT13bzM tINh0UQWVfEGRKJOz2UrHXW42jtzEvdfynhOJSx2Pa4nNg77Luqfgr6C0p8CX9nSu2y/MOk9gPVq jliUHiZlJlpJoKYrmVPeM44D3wGA5vDOMmVyQzFAJHjgAkEhbuJvsl6m1PbmaRhjA2LskXQ2FM+1 s/XQ9l4Gj22ODUwuI1RrDiYmI3yz/CTyIAH/Kka/fRRuQ3o15ibCWF8Ef3RHgT6ILE2q4HN17th9 PwhWSLqBnTGBqzraYJ/AwMoWI3s/Euev0qUQuMi3hC+BRXG9oMrxGYlXSd3YTOOOsUotKIzIZDSh Mk3L2ec7G9G0LC+ynA3tM3lLIBoImKkubSxtiV7o5Fo9+5DhQJ3swFKjujOhh5Djc7azRrzZ0YwU XTPiuEA/gnXxrS3qsbVKjz/QdXhuPUqqvtIIFIQg6HcLosuUegV9JO8YqwvOSFJAj+JzGgvjL5jY 0r1Jk1OAqti+/izuIFey0WM4x0LyVlWZiBbKggvtOgptEArtHwrJfZg+F0pwKmor9iOuEV+jm/Td bmr7VofruEn0Kvk1zkyXaLLgT8sW4/bDmLYusiLUkMcQLt4/njyUeDmuOPdZxQyMWTzDdE5ndjXN FXgQopcvRrZA7ZqQie1Nt5EtjOlel6b1Y9hGIWJrJj/b5ve0BDJuWTo24tpKBlrBOSmbtpaC56WQ QIdpHgkZmTV0+fSfEY9+GTClqLpd5eY7MM+EalKVVVCfj4sXYt7AztglF4kfU8CnQW9g8JBDk+kV 0x7id7YgtLi6akDehWdZK+yJxyspCHvgEyT/cZL8fJ8RU2KyuKWxF21+mRAu7qOoLEU52moXncxr 2XeiZg+isW/zDLYphSw4HIEzNk86CzOiHKZWRgrepweYkQB2nHO0mM7AZTS8w+mC3x7pvgMLXcTC qnwOEJoaFbkwsbbsM3daMgWVolJMnCKJ02h1AmxO+j5tTmoRw4/gjEv/iuJRLi6sWrWf/ENXEmFO USGuNxeqwYArhMf0DMVxsjqVrZMmiXNa+aLrd1yLep4aVpyuWlDyCl7FzaL1Gas0DN67DjGq7Mb0 Eu9Bjmcq2q2s4p2fzNtpxm++vMz4jZtrRGEAIfUc87txb5LbJ6GP8J2xabCnQl/yN3VJROqIXdWP dLuMgdWj/M4TxHI4be+z6XMFA2vpUxkD3cPdrTXK4V0u6xNVeBnSmdrSrVMZq0yo1bPj8gVIF+zQ zI4E7Lh+7Z8Autr4ob1DxiSvFIRe6IeMS7IkhpcM88hPXga8gKkJPfB636wWOiLjgVpGSQXlgu+s LVZ3Es0+ne5F2V+YWvRceNupSWpFGtB50+16tPFeJt6pLWaQHmnNJmcZk5duy0+Z73v7TrwdnDl6 caZnjc50u78StZ4Z2RxkqNiIDQPd1v04z80TqCnBVHKpD5W82seMG8+JFqnkICtywWwM1wsQXhqe NESBUQPm15kJUpxE4ees8H0Dh6IBeskljZnxLe7BgCBVrGswmTTtTITp/LxrZ+SzEmr5UVunsvOZ 2JrL2oWMZuJdZ+DL1jEI7lyebrZDSqtLFI5GrIWeI7qjyiQrsa4ODJ/BmOIZ2Bmvv6DrNwG8jNEM jQHIdM4xboXc5kJtC4TWxdlfGVPhRn5uz1aZq0BrJxlz4OQhMNgJq9RzTiq3w5Oj38Bej/B84JUh tbilPHcvJZclnSIQex1uNCSX7uXk0jO5LJhcupQAPJLL3g4vBF5bU9kwaJUI6tTzY//9wFsHajAG dp6Vx4+AbzB+ZJOAB5zsG24RnehXCV3NWkJGntfcucwKjIBW+L3PSqTSXMO81bBv5udoeIu+Hucv 3+t7nWtFiQr+xtKaB8n7ziKPF+qL7jqf32gOr9u49F4VxrWpKDpyWDwBc/J0hqt5rST8PSErsmq1 ovbTocCAA4GHfsgqLQuVNqn4NfTrFJExJpyvtBhgeKPmzplkluk+WE/RLfMrbKQB/06MG+1pnfa0 pSxX2tNiuNbetsm4VlzoNF86ulsHJjdd8s5FZ6TV8ZwrGbaZym5RMJ5sttYJMhx2GFhkqEzJqTi1 4lE8AIE9IaD/P+dV09w2jkTv+RU8klWxTHwQIHNLJVvjTSozrkk2u4e5KLJsOZFllT7sin/F/OTp 190gRdKy17kIAtBoNMDGe6/zU13zB9OUH3+u0v1/iNiYihCJKsPa0D+REXNoOohcC8BFCNZp/wYQ NcU8RRtzaE+cK7LSNOUjcSRFY5rn9CZFOQnBVmYYUCc4SbCQ4rRl3ozSs1VOzVOQSJfmYh3icAtA IrRjyRkpv41IjAZSEyVFfjXnBqlnJRsIKejwNbIPhobXyW854U9jnoE/0oXmiUfUEIrGJgaFv/iL 8Nd3M6ZPRr7n8K7vZLGTMncHxG/ytfD8myIArU5Pr2eCW0uZngjJ6+C2AOhM9qBR8vBD2sm8qLmo 5d5eHJ7KLgsZXM9E66ifU3ASMs/6HmQZjt5kJ5RQdU0VDDanzIjZ7Kb/FU5CnNTNIwzkCL0iypIs UgBlbU36BvXLvoFDyUgwGIeOxnkBfj76GRzp1SaUduRnAZSyAC+6mjrfraX/hu7Y8g05Gk3t/f09 fQrC/JqxEK3az5SyZ9IdWl2IOEjDUx1O1ntpf0hDu3nstmEghBMepodj6gOfUxmGlXxU7i607Esh 38rOa40vLV5p/4aYDbNs9O2IUc91nU+OvMkjagS5UJeBIDU0BMneVykXml/IhRBIaAwcjV5kmciW ge0onnFSxHFg/y4qz4zC9d9uXoBJltk7kAfwnOlts5bp1C2MaFyXNG7oXFARaG1nOxOrvUzeQESA B+LBnmI/yUah8MqlkOm51HJqg3q1GTrSrRa9raZFbCP+ISGRMKVfynom+P/I9tvCt/5I28fHxTrd t0tE+fTnryN/P73l30CGe5SUVP7MQZLZFL+rCzkdSWVkosPbJJPFLUYv+HfJI/z3iiSbwwUbtd6C XmfKuaz8aGZNcFvpf162GvNtSyn1I2x/cIpIiBoiiJKTmCQlEdkwk48nMVVwoW4I0AaOHpGMsZWM 8ckspiZ6YqGhx08stmJ+zkASc1Y/Ln/HzzuS5AbFRiqUABWRWZy1E+ajVL0NjYuwi8AQypVIWYKH qCIqtu29Is9hC7ciQSMlH3ubbdOAyMuYr5bqIU1c3d4lp6Lcoqq/qMI1ihTtXCQzyEqO8TQFu9Gz Qwi6/Lu6Te5mesTkNm2rsa550bUOzmTPtIXF6+NroMqlZo42XLQ9gmmcWJV7Mq8qAvfSQ3l2eWV+ Ja/6jkbFmjHp2ZqnxN5BWvUdvi0wAy0bUGRxndvkD1AR/LgiF1XQK9m/CnRYqFNNR5fsOat44bWM zmQdwLXs1qvz9X4nVnOad6HzpWZ7gYq/cmjoJpft1JMVk78KmZPPQzLnXsLXYCYoO/kUmOzOZMZH Sh5mvWFdcqpx6qRttyMkPZ4Sx/nSVKStgydfIfheStiXpURTgy/7jsZQU/mmaRLa1NVzaVF7a4dO 30JqVnn2Gz/7ShOjyu/wNlFjXvO7qbggRHt7h1dH7yL/QbYVTF4zdJAT1ID856N62xcl/dKzNOWB 7w0KB17m0GZnGsOfZBfUjprvuqy1+1j0t5mJ3YIgi47X+V8VvWVfB0eUoNYs6iqGSd60tf+zgLPx bYe6rbZqZU5njySC9aRZA4Eb3XmlwP67Qg7XVRCtjJs1I1NJ7f67YtG1TnB9BmzCxWAg+534kiRd MgBVHjhcfdfxdgDlBPtx6GZvZXnrj+ycmHEAU9W5F8n/3VwdtZGcqz7lB/xZO2m7QTjJy09UQ7Yd nqRozvqHucI9oOw5ETdpq3nn3SG6S5m+lbOl0Ru9u4Oj85lmaflYbYakNp3Xz1nVRz6no+cSKBpb oybkr3n2swiOaHc9Bz2HfHMHqAv59fZW/kCoBdy5r9se67rAkpxU2XXBxL2DvAss2FqL3X4DwEuj W5Z4If8KhRdwZdCFm91etpqy0VL86OSDOJKpXW+KAoSzFZgQusFSKKlzJjucS/cdKs+AF8ddPfJ2 J1HdiNetuEOVNJKadLuNbRJKJb3pG8E/9yhUtReO6oZsvV44KUsi7vPCG1ZDBmqG3nYFrt/s/i4L h7/xuNRV1H0cIAPhfuMoFQbbvqaj55ktkfBlFPaYAFGaIzq0MU8kUdWAlF1VHXKDexE3RBPtyNEj 3GBaYjDPEIMl0RqGHt/KGS/4+TDv095G4dIksBYlwdJB7NAFlV5cqyFjSE1/hCVo5ae92v7ofFsR CSwBlD24MOCV26n+uUt/0m6vwSSGge0w2BSEQn6SO4ZZrdbTqC7hNpFaF1Ny0Ub98cAVNUKPKki6 a0khr0ZwY6qOq0vzLOJ4521W1fXEdgTyGaqHIQIN0Z6r+IXX/Jj5aU8EEAin2XQupptLaP+Ahx8Z i6y83tAtn8lLn3MP9WvVmayXuF6CD91Zluyu1d2KCk4MZ9rXzYh3rWPQKWVPXsSd/VR2W4p/sXgQ 59JZXRUe8EfFEOQQcTYfb1k42Voj6R1IYx+9BJd425R1H4GO3nukbxjStb9T3l7yJyee3ipP7nRg 3lGRBdN8UspBqgRw0OJaLZWQ50pt244STTnkKMROUSXcLJ+CzJoKnaoh7dmP/Oy8sGX+7mtxwthv HWI0FPjfKK/ykpIkr4/j5RHI8BRzqE0ZB7v1kLL+NYyU6yeWicEDwTqQ9C8DSRttGDoaXy9qOz6w rZ86MYOkwWMdeHyPmgM8tGG4cEzzUuZidIWaJgKeiFRj/o2GGzUuqU2Lb7Zc7TpUu7Bfqd3r7INO JIeXlzSEojYtnRERR4AWL9iyrhv5mXBQ9KjpCXajO1bRne8lZ6vjd4toWSx0J9vp9F58pwCW1zr+ wJGk4V0aHoQyUgclYLEFRmOr55R1RVVPVlVu4n0ZonyGL4VgFwuQmcDOQrBlJc0tP1mvHAMJxMNX 0vwErQM6YNRAYdadzUZ62XsFQfVAXzqONt3p5PxC1tKdMzSe6vgfovgmTCq+nV4x5rWLxVcKNfsi EDg43krDG57oZ1GxkPvAhNaO7/UYq+kSkgkxiOCzZSkWYTLGz8Oql17tk5+E3kjpS9McPtrqZY/W BcLqgaMxkfqWRcNzb9YCpPr+3oJYfP6pQDq8x2V6pSrP3OOFqjxTlVeq8kJVyYKpyjMP+sSDdLXS ZP+V2TnPfmNypIU7cSCjJOdFK9MjyZlsvXADsoBTA5SmSt2TrjFo9tLMxD8kO7pXuu2jBxt9zJMW 3UGD1ZEvGkwg9KRraEKrPu6A68h+Fj8Np6uhmGzgOjJHXun8A+0ug7tuEInIwk1VFXNFGTA6YeZo Y0UsJttctV/ctWl4wphhFTNGsTf0UDzJWY29clqsLfhWKZz1myIAzU5P73FDLu8ay0jJWIcP60T9 OLp8B0yd8LU7kRzt5OmddKkAkUwBIj6I5VQazQ+wQTqgyeSI9PbrugkZPoVrYja7eeXqOGkqEih0 BMoXE0qX3byqSIA0pj+6HIySo9LQaN9DGl28umy3PUn7nhxsXGbtfTsuHfpXW6HI1WuVO52Mk4uw 7VhKxYpyKkPEzlp/iBHhRRgR/MDJWO+FVPg0z8CDsd7Zgbv3EHus3Jr8DrIt5hfyTCEDY76QMZQL lsCU7Zac30uemEhmfwHF54s5z2fiVDqXeDviZCWNPCT5f6crULhU+V4D0MEd924zWQDnVZVn/6PU Vt8rifSMtwOp5WsxgjSt0nkk9lt+xBruWDOnOwzPKeYYKCmyqvRUqVRRddE5H58FMYeGh+9EL/NB CcTm2WLKkpTuTbU1w0LJEhLLy0i1Fd9o84iQbHnpeMpxZL6mxC1r0xOT8YU510D29h2NlIxLeVc2 /rnEc877ocPPLGL4tEL6ytKsIz4QeqIeWs23gKhughRE5ErN1Fyp0e1GUQlSWXFvJ7OZOllLMTWn 71MxjbGtGukSrSeJXFglbElWwGi7k+l/eK+i7bZxI/orfCTPkVQCIAiwb5tsTpJuduMTZTdp3xRJ ltTYtGtLdtOv2E/u3JkBJZO2FeWcVg8iAQwGw8HMnTtLPTCb3RcVKM2MChbK17KlnhMvt0JX1Nxs I/KqNiOZfJbdiT16pGrQE3ayNmNqdKGnDeO0S/b6eKQGOD00E+8MdRns9Euwolo7tZo6Ne7MaglS sZfHy0wlr7gutz2xrT5llfyqV+n4js4KVP6kGmBg+GPsfmNaXEpLyJqjehFDzoy06VedTFYvkhlJ +qGR3d5Pb+FhTjMx7Hc1ZcoNSU3cyFSH61Y1lN0TegOPFOom/kcyk2+CCnFsXLSHiRlPS0wf7UDR gDAylj2XjdR0hr6WKeUXlbiPReXBCphQBxT/hlsKoBr6LQYtrP5UeEPyL4lHqDzP3BQVpVuiSEQh 6GbHCH4iaB6ETpXcFugaCfxmEOF50TvDZItjF0ySPhRV1APeQMXgLAPiQXvkLLqifDzImipRaBeq I/1WaJz3WeWria+bJu6LpBVCKlHna071sWNcQVxyCiMDlJtys9GyPMV8DeJ6LomepFEtwFkvBQH/ qgD3kTvK/XISn9M8Pb4i9pk+r7hRpcOugWtQcTVfqnAy7babyLp9bFNGYJRmbhJoynCXTrxQaFYD O0NACfiDRFU6YlAgTDjIjWdgSjyOrqFJ/HXZokMNXMEbopJsIrgoz+ripawt2y1ch/ykbA5DO5CV fPvGehijWeYezY8aZHJo0Bl6UuYVnh5Xc+4mPRDFYH5KqO3zV4R7Pv8NlcxTl0OA5vPPspEiAmtt i/6BXqQrpfmPSxByT15tZWXD6OWl7/VcD3yepF8WDY7nOZU/V3nVoxbqqGVJCosBYqWu6Amc8Agf 54ETD/yQGhlkoTQz1N1M4IQhY3kWEiPxVlJO8B29D4eQ2JwGibH2pqfndEQMZXQ9Jf9DQKRLAUr9 X1Fx0sNFJIbtEqP0R2Ax2rIhNxsmE7FOsEgJB/sR4beENRahN6MxIn+igUncnnNFlzeSFysRWjJ3 8IR+FWSo0jsOcF5sWbFu2MpDl3QbsawAQdWWqdBalTN7+LI7L2B3ro8lKFmnIZur1TKrozWfrBZn 6RSeZJ1M5eLeAFWmx6sDVOWFiBCM8rN/EE9uWnni8gcMA1D6XUiql1QSWntvQoLSOzRGDCuwMzKK 5u0l4luwk5FzSDYRCxwe1ffBZnzk9DOUMTqSqlctDKpBnKJDmp5xu/SOO7n33AFNeWbMveBnFnrL 7/RfIYJHJ+NY5eKk9LFp+oah6QKG1SNOqH2Krg6Se6wE1OCvYoPGwCiqu7yLs+4k1HPUN2WuIepl wgPYs+VJsBeMi6GvaHCDxjXqJFs3x3q0Jpqmr/HvO+a8DRxCNbbJv+iYAlZesheFxdXMVGAzYpLe oFaNK3peoTiYPMmvZJh93slLJ/4PtDwGjYEckL2TiQ3TnIahmEhAQyeRsbgcyuYm/4oAmcR8nAy4 nxURcW4tmw3Z7As/Zqo6bU3ftFCT5izF9tpHSKQPiUSS54+gpWuMz1zkyhm0dIKTGeInczSKIV/T 8R58ZbEjolVjasN9SOCqjUAcE0QQnzkHqgSu+syEHLOcuyR9I8tbHTJ9w8QF429g/sYvaUEInO0O Wuo8h3Oy8hs4luuGSXuSTTonzIz7pOtBZj6HGxXx1thYG/rO+rgGg6EsrbVrNAgNpNsU/9+Qn4Rg Nr++uqUAZHgz+e6yILDJ3mOhHSQnoPPJvOQLC2SDqY3aQJQtv74G9VL1bNICJCy/ksNxxm67l6BC NAibugub+sAdj+dhpIivCbP6pozYzdqheu1Q8TQFaL6M/F7sesbBVeerpdwgzZloaBJt7xgRg72i I3ZP6JokHU93uU/WnyriJulOQ2jQc+3RzZyGbs4a01c0QDci9g1+XbTVRyDOwrd9tURijH42WjYE T8m9zRiuWqFMc++DxRt0HDUKKCZHBTeFVM646es0vCzQv6nQv5PUjIgh9C44zaYTnf7AwhswKRJu lyKlByWh6Vym18uFaN2JdReyjWMP7aZam70Fm6ryv+i8flLWyanYnTzT9A3aqEqSbQL6efjpetSA WpeVup9KTOInTyWZD1SPXEXuL01U91+mU6TH5ZZ3LfaCFOG5lNlMRYmC19J8stBWxzfEoOUirekb ytFSdzH8LJOJgeKkagaG/vHq1Z8UKsi1QKlyQodRoXerTDB9lSNKZ6L0JbgE/8WiKmkWAXJdoNIR LVtBhJsCbhEyA+BB80C1yshOh+r4GBeZ03X4EJ9KV19XhDTUrboSEHyQrva0dK3AFXuKBhdgveuQ 8DnKxplqvfd9ja85wVK9cvmV1EKqlGkm+zQB3cTbzyq8ay+4dDktf448O+bSJkDnUFFAFpwUZgcG QnG2P2ax0wkpqPsFLry0f9HbcLdMR6JkBz4Q65e9/a3Ob3U+SwelDYtiX7b3YuCm5aH9TwP1U4lY 156C0RKE1FX94OLdiRcPGO0pGrJQ27FQH49dvIOensbXE3YIkcR3aOGEEzqmgiB/zDEduGT28yR7 vWO/7CcLZEra2Wl6sVaxJP6Nck9JIgRanR5l/ZmF6KWwIVceaPxA7IDHfN4vyca0bYU6Q8sIt2Zv 3vlW5e7TOTfgpeGx/Ild/sRjBDT4miod4qUqo5II4XBR4y8SD2yFCMb8Xztho1EJXxQymHYgji3X Dx5KIMf8WhKQ1u+SzkRLY57WtiqsvDTmFyqQBP+DtNtbtZCz3oL9W/SF5CbSe50MTHqZFccEAnuj 0jHtXF86067ajFu4JLnjk5I5yU4yq4I9Y9E/7w5IegRi+pQXdCTdj7FWwvzxCrO/nxLCNRiM8k1S T+yS/n/F6ZYqODc3b2X0igXSv4OV2fQbOC8ug4mwfIDBh+Hz4BanH08Xihc55UZk52uZTXu2+gTT xfJWzt+RD/x++lZGHCLnuuNKFKlg9ht/hconrfeFRJMKfZXVdDbYi0EizUQVmFLfw7YjfNLeukQ5 nqSkDHU2UsZRkRI/w8NO2ynQeHkYLhYbfDCVgtlWXjba54j7nHx6gNthfDfeqthSZlWrLo4GZMEc awQqMqepIrHVh6YTYWAzKNakPxt1/ZcFCbqerURgKU0mhwSVCOokxoArR5SB1wN/fTkBCNkfLiE2 cIF+UEGqH6ggD/UMCwhgTgpIbb+rgDxU+DdyEq0gcxlb3gFbOPBshUQZMcjQwieO2iT2hiGr4dAc ZS8kOgH3NVZ/KixQ4YvuBXpj/mIzShJIjzTdqtgCkUFZSIXqTON+xofuBZI+NUV0vZHTkskrUbNO hg88VvnkseC/q1bYupo0IaJHhcuIgpCPPOKITvDIa4vneWHp/wrpsp+8xFcGeml11xzmyWZMU6PB 8pcUdPQ/Jp9VePsGbPI5mlUHecoXWx48qQiQ+z36GG5v32cbQLjxuSrcsMJkxlbFdrKYjLrIOvvm Bc5b8y5kdsU2l2KqmlDT/2SIPA9bTVsd6yN8SdkTStrS8+wZgLsWoKRmZs6QUef6QPWrFXWox1lx AhOxZ3hNaDtsw8rSC9t/BgnlmqmGNqU1UYz5XS5qyj54xd8O5PZScXz+uWCvZH/KsIQVPq+5iMB1 PGx3M3kRguwl8j/yF3lhGeiACFR7Yi/5qCvVcq7Tuo8d1I3klshZA6CS5usInAZiYOaR7x+hgcps iQ/L6wmPAKxmAInPo6H4loKaLtvHQzj0p8Ghb6rQV9S/bHO0e6pcaPpa3qBvRGAZlCdOD2pBEF/5 ekfk1enUP7EofvkFW3jyBt9CaQlKaCRb+PapEM7pgvL1PYvyFPoSB8RyUc9DTcrX2RnuEvfaUByT Ply8DA8MYnVLcAD3CAMwZa2XXlonCfk8tsWK8M9arqGhEk9MUfRqAgOHx6wI9H8BzK908AU8heaW IkEwRFFTA4Yg876wSODsj/9yXm27jdtA9Ff0aAOJVyQlXvJWJIstii7aArtt2jfXdmIjsWRsbKfo V/STO1dKkR17kzxEEj03kjNnzvBzxavfMG2IMeMXVERVk1lbdzL/9j1uX/zUsksEUCpvOM09L636 kVFlSfwS3eMdQ8QlB6BRfdvuWF/3x94khAUtzlmiuGEdXnzpdtaXf5owSB22G0zJTBoUg07xX74X 6MrRV1hVlKG/ji2SqJvr/6gBAD8Z43c4QQMJjMO5+ndwf84fcZnpU+ZV4ZBXvc6qQgJW5TtWFfVx SadN7MqxjXdQLD6jEqgylnEfVPzbQMXHOg0NHRkvQx4vwzmAqW0yQ4s/j3HveTq6JuYTkKPYmqgx jk8BCx4fD7I8lWWeOwEU9rpSAJywzFyegFKJXfDdfCJywjbYMgxqnXjT89w57sY3uJXP4lVEhsHs 1KSOAWryPm8PWJxF1a9EJ8Bsu+/tlJSHJyDh5l0dkreQyVs4B3AJb8sk6mre8E3ctTzOMDFCDzj2 EplyQqYCkKmNhKxiooUkyQl3C8LFAhEjGof0aEn1nlWAl+n28VS3IrWUxQVZLG75mUX3rLyiUUSD UN0d/ziVMDKJCxKf2s6excladqHLGrHa1aNBZh2Gp/8q0/s+UOO7iEDUbZ3s++geiXV0zyCOFFt+ LklaVAvibp64myfu5om7eeZuFXM3PyKu5pmreeVqXkgYuPoi9mZLkVixs9n0Ubxfk1UJqVEKKmqy MflqKJj30rQaysMFBwPh4BBf0LQ607Q3kjS+nlBOTIzO9vE0vA1P4c8MDR3BU5/x1J/DU29LN7T4 A95vJXgF18BY5QVG4KxbaTPNhYrg8fwkYoySyNAIoTzDDkhDJXh8aZ9E8kIl/xx4/AKZA1xmzPzm 0pdyw1WOgTC1Z4ERuedco1Hn8CQu9QA5TzxDLEzF4Jqyq/tusum8QgHMZe/FH9nVsJCR43PiwSmf RtGEjKIwNXGDSgjzX8B54ugZe3gcTRcNpDgk5WgzNvC/RZoQiQhPLBYTXCL2e5QAPgV3SuQXV5E8 oGwjOk+y3sh6sRHLcBQB1qHoY+dBFtfIMyLBIarOWGNxNa4smvgFby4Cd+OoRGm5mM6fkNuBxIoN NBS9ojSGsRSd4pZtSDDNeYJwatqUE63SJMQAwwid6J4vveuMW/neaeN9lD5brOVFf5gtV5S2ge7f 5V5KO9EP/mkvSD901jZrWXkpvxVXkEiVOdaPZeboodfRFlAhPlpX2eG2f//4EaMEUgtTTgnbmKRR /TpCvjbD4uRaJeuG5l+CI39t8J0Gqns5IMfjW4FMdeQuCfacIukhPT2JpMkaDMPVE1OXJvWRNL4J SWNZl2Fo6DDxMpCmczgKGJ+G9m6QCRCoJQaoerTbYOZxdiVCL4fkEviFTq+fSIlOEPOnHs0bIlEL 0qCh9YItyknDajMnkQKIsLqD1glVCJhXs87DlN4Rea1QXRAQ4VvyyR6azyzSXMGi+Y7ucgrdXOnq wmBZW++Erf8mSN0SnGqPWAsqt81KusRWV7QLuIoZC8+r94rDegxHIHrT6xakfceY3+r3AejP5EUV i42KtqKrATzKcyUmuoBy4K3KDPqaGp8tcbMxCudhWcgG0290G222GshWHB6Z67SQT+Ij3wlS1Cp5 z3fyIyAwEkYYpeDuuUaBj9KLiUHyVKVKzDSQoyT9G2dSzWS8C1TkwrbV0equA4xwx2OrIKkKUwI4 VtGGfnmnt5W3dc4MDb1S3ieq2pWxroZmllRrXMZbqpENrVwhaTU45cAP/P+Zav6Zquu5Bwb7Nek9 a6lzYUOtE1xiO7BgaYYfLYuyPUxGb0btfDejauYguKY/kBzXMK/88yFv2NC+TAH5E2PyBSaIS6GY rXPy2Ikz/vBaAPtNTCkWAUCuK+LuLP8fAFBpUscNZW5kc3RyZWFtDWVuZG9iag0xMTUgMCBvYmoN PDwgL0ZpbHRlciAvRmxhdGVEZWNvZGUgL0xlbmd0aCA4NDMNPj4Nc3RyZWFtCkiJlJdRbxQ5DMff 51PkcVdiUttxnPgRdEfR6ZDu1NWdAPHA9UpBokWUqyq+/Tm7C2wCsmbUh0l35pfY8d92cnZ+geH6 84QB7A8DxqoqEmaOXCtyuLyZIFxPT3b22N1NZ0/tm7B7O2GKSgdoP1KKHAqUmCnsbqZXm8fb12H3 2/Trbvr0bfYZIhbNgWLRCsfJi9GCFOaiGJXD3dX093Q7nZ1f0KllR3Tu2PMJYtIaHpqB2AxcYZch 9DMEwZhSoXbc21PuR6RE4FR5BYIYBVQ64r1P5CgWlB65dRHiCBVttHwVKvYYXfnPRRJFFar9hn1x EYbIAKlfZfaRHFHVNHCKvHGRTLHWVLRDHlxE2oPSmlVKi6Rgv8qdj5Rou8apQ65cpHK02FPpkOAj NUqug2G/uIhWCyWkFaEkEMvBJCtkSaZksLDU5ZtMZIlPMOzYjYukHJlTwuXip6SRaqZ+lUsXYbEd U1gRF8pgoQTt4/KHi4jVPxkN830RjqawQfx+XErLl4q4AqloO4a1rDCsWiLTOsM0xSKjYdcekqyK o4yGuXFJkKNqpb5aXrhIq8lgay0XTKJkOya1z5d3LpKsMybEurxcJFOyYB4M+9dFuEbKOtTkexfJ YhVmyLAPLmFCZh3tcvWSTMi5pFyX6yWV1pHK4IqvFxOyIA5lzNeLCdma/lCS3a6fFCwpQXrko49Y FU88VD63vTBwxFyqLveF7UPTPvdx+ctFsMSUadgxN5RMaD2ch1D6vpDEAtK74h5H2LLFKtlgl6tj tmxRlDUNidk+VB02zNU+Z7SGhIMq/bDkbMUiUe/LcxeRdhbNg/u+L4UtXQR5eRXjSlFYhx1zqxjb +d4aeOEVetHWKoau52Z+htYpRGh5qcx2Em99srfrs4+oSX/Mlu+R/PPb9cXgs6d0uDOp+bKfZD9I IEG0NdyRPrkuQc3tfjSjJTRUwnbtsSnbG7A5L+3+A9YVdw/TcWpsZ7gmgCAlRzvF7+d+uZ0RLDoz 2n6nsgm/7394v8WyeWRD3IQX91c2KJt/Dh/Z6HaLuglP7H82+bR3e/b4/bP77UzHL79sk1oRmxkP 0HU4WfCAHn7/utabj+H5ttqr1Mt/7xdocyz8L8AAmnL5BA1lbmRzdHJlYW0NZW5kb2JqDTExNiAw IG9iag08PCAvTGVuZ3RoIDQNPj4Nc3RyZWFtCtvk8goNZW5kc3RyZWFtDWVuZG9iag0xMTcgMCBv YmoNPDwgL1N1YnR5cGUgL1RydWVUeXBlIC9Gb250RGVzY3JpcHRvciA4NCAwIFIgL0Jhc2VGb250 IC9OWklFV1grVGltZXNOZXdSb21hblBTTVQgL0VuY29kaW5nDTw8IC9UeXBlIC9FbmNvZGluZyAv RGlmZmVyZW5jZXMNWyAzMiAvc3BhY2UgMzYgL2RvbGxhciA0NSAvaHlwaGVuIC9wZXJpb2QgL3Ns YXNoIC96ZXJvIC9vbmUgL3R3byAvdGhyZWUgL2ZvdXIgL2ZpdmUgL3NpeCAvc2V2ZW4gL2VpZ2h0 IC9uaW5lIDY3IC9DIC9EIC9FIDczIC9JIDc5IC9PIDEwMCAvZCAxMDggL2wgL20gMTExIC9vIDEx NyAvdSAxNjkgL2NvcHlyaWdodA1dDT4+IC9XaWR0aHMNWyAyNTAgMCAwIDAgNTAwIDAgMCAwIDAg MCAwIDAgMCAzMzMgMjUwIDI3NyA1MDAgNTAwIDUwMCA1MDAgNTAwIDUwMCA1MDAgNTAwIDUwMCA1 MDAgMCAwIDAgMCAwIDAgMCAwIDAgNjY2IDcyMiA2MTAgMCAwIDAgMzMzIDAgMCAwIDAgMCA3MjIg MCAwIDAgMCAwIDAgMCAwIDAgMCAwIDAgMCAwIDAgMCAwIDAgMCAwIDUwMCAwIDAgMCAwIDAgMCAw IDI3NyA3NzcgMCA1MDAgMCAwIDAgMCAwIDUwMCAwIDAgMCAwIDAgMCAwIDAgMCAwIDAgMCAwIDAg MCAwIDAgMCAwIDAgMCAwIDAgMCAwIDAgMCAwIDAgMCAwIDAgMCAwIDAgMCAwIDAgMCAwIDAgMCAw IDAgMCAwIDAgMCAwIDAgMCA3NTkNXSAvRmlyc3RDaGFyIDMyIC9UeXBlIC9Gb250IC9MYXN0Q2hh ciAxNjkNPj4NZW5kb2JqDTExOCAwIG9iag08PCAvRmlsdGVyIC9GbGF0ZURlY29kZSAvTiAzIC9M ZW5ndGggMjU5OCAvQWx0ZXJuYXRlIC9EZXZpY2VSR0INPj4Nc3RyZWFtCmjenJZ3VFTXFofPvXd6 oc0w0hl6ky4wgPQuIB0EURhmBhjKAMMMTWyIqEBEEREBRZCggAGjoUisiGIhKKhgD0gQUGIwiqio ZEbWSnx5ee/l5ffHvd/aZ+9z99l7n7UuACRPHy4vBZYCIJkn4Ad6ONNXhUfQsf0ABniAAaYAMFnp qb5B7sFAJC83F3q6yAn8i94MAUj8vmXo6U+ng/9P0qxUvgAAyF/E5mxOOkvE+SJOyhSkiu0zIqbG JIoZRomZL0pQxHJijlvkpZ99FtlRzOxkHlvE4pxT2clsMfeIeHuGkCNixEfEBRlcTqaIb4tYM0mY zBXxW3FsMoeZDgCKJLYLOKx4EZuImMQPDnQR8XIAcKS4LzjmCxZwsgTiQ7mkpGbzuXHxArouS49u am3NoHtyMpM4AoGhP5OVyOSz6S4pyalMXjYAi2f+LBlxbemiIluaWltaGpoZmX5RqP+6+Dcl7u0i vQr43DOI1veH7a/8UuoAYMyKarPrD1vMfgA6tgIgd/8Pm+YhACRFfWu/8cV5aOJ5iRcIUm2MjTMz M424HJaRuKC/6386/A198T0j8Xa/l4fuyollCpMEdHHdWClJKUI+PT2VyeLQDf88xP848K/zWBrI ieXwOTxRRKhoyri8OFG7eWyugJvCo3N5/6mJ/zDsT1qca5Eo9Z8ANcoISN2gAuTnPoCiEAESeVDc 9d/75oMPBeKbF6Y6sTj3nwX9+65wifiRzo37HOcSGExnCfkZi2viawnQgAAkARXIAxWgAXSBITAD VsAWOAI3sAL4gWAQDtYCFogHyYAPMkEu2AwKQBHYBfaCSlAD6kEjaAEnQAc4DS6Ay+A6uAnugAdg BIyD52AGvAHzEARhITJEgeQhVUgLMoDMIAZkD7lBPlAgFA5FQ3EQDxJCudAWqAgqhSqhWqgR+hY6 BV2ArkID0D1oFJqCfoXewwhMgqmwMqwNG8MM2An2hoPhNXAcnAbnwPnwTrgCroOPwe3wBfg6fAce gZ/DswhAiAgNUUMMEQbigvghEUgswkc2IIVIOVKHtCBdSC9yCxlBppF3KAyKgqKjDFG2KE9UCIqF SkNtQBWjKlFHUe2oHtQt1ChqBvUJTUYroQ3QNmgv9Cp0HDoTXYAuRzeg29CX0HfQ4+g3GAyGhtHB WGE8MeGYBMw6TDHmAKYVcx4zgBnDzGKxWHmsAdYO64dlYgXYAux+7DHsOewgdhz7FkfEqeLMcO64 CBwPl4crxzXhzuIGcRO4ebwUXgtvg/fDs/HZ+BJ8Pb4LfwM/jp8nSBN0CHaEYEICYTOhgtBCuER4 SHhFJBLVidbEACKXuIlYQTxOvEIcJb4jyZD0SS6kSJKQtJN0hHSedI/0ikwma5MdyRFkAXknuZF8 kfyY/FaCImEk4SXBltgoUSXRLjEo8UISL6kl6SS5VjJHslzypOQNyWkpvJS2lIsUU2qDVJXUKalh qVlpirSptJ90snSxdJP0VelJGayMtoybDFsmX+awzEWZMQpC0aC4UFiULZR6yiXKOBVD1aF6UROo RdRvqP3UGVkZ2WWyobJZslWyZ2RHaAhNm+ZFS6KV0E7QhmjvlygvcVrCWbJjScuSwSVzcopyjnIc uUK5Vrk7cu/l6fJu8onyu+U75B8poBT0FQIUMhUOKlxSmFakKtoqshQLFU8o3leClfSVApXWKR1W 6lOaVVZR9lBOVd6vfFF5WoWm4qiSoFKmclZlSpWiaq/KVS1TPaf6jC5Ld6In0SvoPfQZNSU1TzWh Wq1av9q8uo56iHqeeqv6Iw2CBkMjVqNMo1tjRlNV01czV7NZ874WXouhFa+1T6tXa05bRztMe5t2 h/akjpyOl06OTrPOQ12yroNumm6d7m09jB5DL1HvgN5NfVjfQj9ev0r/hgFsYGnANThgMLAUvdR6 KW9p3dJhQ5Khk2GGYbPhqBHNyMcoz6jD6IWxpnGE8W7jXuNPJhYmSSb1Jg9MZUxXmOaZdpn+aqZv xjKrMrttTjZ3N99o3mn+cpnBMs6yg8vuWlAsfC22WXRbfLS0suRbtlhOWWlaRVtVWw0zqAx/RjHj ijXa2tl6o/Vp63c2ljYCmxM2v9ga2ibaNtlOLtdZzllev3zMTt2OaVdrN2JPt4+2P2Q/4qDmwHSo c3jiqOHIdmxwnHDSc0pwOub0wtnEme/c5jznYuOy3uW8K+Lq4Vro2u8m4xbiVun22F3dPc692X3G w8Jjncd5T7Snt+duz2EvZS+WV6PXzAqrFetX9HiTvIO8K72f+Oj78H26fGHfFb57fB+u1FrJW9nh B/y8/Pb4PfLX8U/z/z4AE+AfUBXwNNA0MDewN4gSFBXUFPQm2Dm4JPhBiG6IMKQ7VDI0MrQxdC7M Naw0bGSV8ar1q66HK4RzwzsjsBGhEQ0Rs6vdVu9dPR5pEVkQObRGZ03WmqtrFdYmrT0TJRnFjDoZ jY4Oi26K/sD0Y9YxZ2O8YqpjZlgurH2s52xHdhl7imPHKeVMxNrFlsZOxtnF7YmbineIL4+f5rpw K7kvEzwTahLmEv0SjyQuJIUltSbjkqOTT/FkeIm8nhSVlKyUgVSD1ILUkTSbtL1pM3xvfkM6lL4m vVNAFf1M9Ql1hVuFoxn2GVUZbzNDM09mSWfxsvqy9bN3ZE/kuOd8vQ61jrWuO1ctd3Pu6Hqn9bUb oA0xG7o3amzM3zi+yWPT0c2EzYmbf8gzySvNe70lbEtXvnL+pvyxrR5bmwskCvgFw9tst9VsR23n bu/fYb5j/45PhezCa0UmReVFH4pZxde+Mv2q4quFnbE7+0ssSw7uwuzi7Rra7bD7aKl0aU7p2B7f Pe1l9LLCstd7o/ZeLV9WXrOPsE+4b6TCp6Jzv+b+Xfs/VMZX3qlyrmqtVqreUT13gH1g8KDjwZYa 5ZqimveHuIfu1nrUttdp15UfxhzOOPy0PrS+92vG140NCg1FDR+P8I6MHA082tNo1djYpNRU0gw3 C5unjkUeu/mN6zedLYYtta201qLj4Ljw+LNvo78dOuF9ovsk42TLd1rfVbdR2grbofbs9pmO+I6R zvDOgVMrTnV32Xa1fW/0/ZHTaqerzsieKTlLOJt/duFczrnZ86nnpy/EXRjrjup+cHHVxds9AT39 l7wvXbnsfvlir1PvuSt2V05ftbl66hrjWsd1y+vtfRZ9bT9Y/NDWb9nffsPqRudN65tdA8sHzg46 DF645Xrr8m2v29fvrLwzMBQydHc4cnjkLvvu5L2key/vZ9yff7DpIfph4SOpR+WPlR7X/aj3Y+uI 5ciZUdfRvidBTx6Mscae/5T+04fx/Kfkp+UTqhONk2aTp6fcp24+W/1s/Hnq8/npgp+lf65+ofvi u18cf+mbWTUz/pL/cuHX4lfyr468Xva6e9Z/9vGb5Dfzc4Vv5d8efcd41/s+7P3EfOYH7IeKj3of uz55f3q4kLyw8JsAAwD3hPP7Cg1lbmRzdHJlYW0NZW5kb2JqDTExOSAwIG9iag08PCAvRmlsdGVy IC9GbGF0ZURlY29kZSAvTGVuZ3RoIDMwNQ0+Pg1zdHJlYW0KaN5UUctuwyAQvPMVe0yVA37FbSQU qXUUyYc+1CS9E1i7lmqMsH3I33cBN22RgGF2Z7Ts8qre16abgL+5QR1xgqYz2uE4zE4hXLDtDKQZ 6E5NyyucqpcWOImP13HCvjbNAEIw/k7BcXJXWD2GtT6k6+QO+KvT6DrTwuqUnj+IOM7WfmGPZoIE djvQ2DBePUv7InsE/kf9GzpdLUIW3ulSxqBxtFKhk6ZFEFmyA7GlA43+H2N5VFwa9Skdi5lJQhcT xTZgulgQUzAlTB5L9sOPNlqJTPskjA57UuUp4TzaECZLTxRl9A2E8oSOROWJhvAmVlEciNhknogS wkyU3qOMpqX3KC+E72UknpYCY0n+v34ktw6q2TlqbphbaJ5vW2fwNlo7WN8lv9m3AAMAlgGVtAoN ZW5kc3RyZWFtDWVuZG9iag0xMjAgMCBvYmoNPDwgL0hlaWdodCA5OSAvQml0c1BlckNvbXBvbmVu dCA4IC9MZW5ndGggNDMxIC9XaWR0aCA3NiAvQ29sb3JTcGFjZSAzMiAwIFIgL0ZpbHRlciAvRmxh dGVEZWNvZGUNPj4Nc3RyZWFtCkiJ7FdbjoMwDMwP9z+er1NVW4JjZvyApKtK+GO3pdN5hQAVeeaZ n5rmjgP4qi/rIjBuuQawmFeIy/dlCN/vZEkpH16S1ekrnwfL/ocYWKQaU01WAreViMq1dPtKYFZX g1YeChu+uEw4i7B1vBaT90WrT4Ezsnrp9gNiM8b8wMv1PlLGcwVAO60510LORiKuuhYmE/7tbZ5D c23vka0Pl4Vn9SC+mZmYESQNoV5B12UrXGgPyGl7TRIbdR3osKJqb5dl9ff1uyGjsnjxlsa7OnE5 yEb3NjlRjiozyjen0FczK6hewXUPZGlhEaBcwhyW8oD1y/ny7h0MXqjrc+z4O2wlzEUzFnRvTzvO O7A7oC+P6/jmIr9INvnsC67Va31FS6g8WW9pLra35QyJuU6A8BGRay7oFidMQFea2sXw4wHzJeZ/ hzuFWkaWsbFzwqlAy6154M0ZL/weigAV2QkRfEBZwHDFFxPma5YJ7Csr1D9hSHs8zijs89kZj/79 uwdOuB88Z4y5cCMEQMvAvpa05Z6r2JcDdQCWLg2clDFL30El47dln3nmmV+Y1wD85xuADWVuZHN0 cmVhbQ1lbmRvYmoNMTIxIDAgb2JqDTw8IC9IZWlnaHQgOTkgL0JpdHNQZXJDb21wb25lbnQgOCAv TGVuZ3RoIDM2NyAvV2lkdGggNzYgL0NvbG9yU3BhY2UgMzIgMCBSIC9GaWx0ZXIgL0ZsYXRlRGVj b2RlDT4+DXN0cmVhbQpIiexXSRbCMAjt/S/IdVz4MhAgDCHaalj4Wkv4g5AagBMnHhdXKPbX+r/g zbFZJKz7vv0iIeV+L6sT941Yt+7vm9akBQz6a1VDT1F8CFs1MGOHYR3eSzmdRqDfBzW+l0GxfLZX tOf0MwIryxwS6I0XLIFXCFapxatPNRSKoUwq7trWX3FYwBc4gZNrkVBTdUO3hCpBJU5qkSWcX8sa W22urE9jzC8etqLg1HgDsvJmGjU7LLBQRaA5YvYvBUxNxfYQ23aFkdeaRsP70bN/IzCnxvFFmt73 84womGG20SY/zPq6xq46kFHI0cj8Nltne15LEOfkBXgv1H/HzLBprERHenIt8k9YAENN4ycuCCCp pBcrvxW/uARfvV8PdCabJnyU1n2DTgY+CpCezwErSNK5gx+zGAe11jzhorWkEwFbC3BCCnH5bKUq sMAqx51cMPOy3vfEV7wgYYfGgTrQWqX8hS+AST1x4vnxGgDMbLcbDWVuZHN0cmVhbQ1lbmRvYmoN MTIyIDAgb2JqDVsgL0luZGV4ZWQgMTI0IDAgUiAwIDExNiAwIFINXQ1lbmRvYmoNMTIzIDAgb2Jq DTw8IC9IZWlnaHQgMjAgL0JpdHNQZXJDb21wb25lbnQgMiAvU3VidHlwZSAvSW1hZ2UgL0xlbmd0 aCAxMiAvTWFzaw1bIDIgMg1dIC9XaWR0aCAyMCAvQ29sb3JTcGFjZQ1bIC9JbmRleGVkIC9EZXZp Y2VSR0IgMyAoAAAA////////AAAAKQ1dIC9GaWx0ZXIgL0ZsYXRlRGVjb2RlIC9UeXBlIC9YT2Jq ZWN0DT4+DXN0cmVhbQp4nAsNpT0AAI2AITUNZW5kc3RyZWFtDWVuZG9iag0xMjQgMCBvYmoNWyAv SUNDQmFzZWQgMTE4IDAgUg1dDWVuZG9iag0xMjUgMCBvYmoNPDwgL1R5cGUgL0VuY29kaW5nIC9E aWZmZXJlbmNlcw1bIDMyIC9zcGFjZSA0NSAvaHlwaGVuIC9wZXJpb2QgNDkgL29uZSAvdHdvIC90 aHJlZSAvZm91ciAvZml2ZSAvc2l4IC9zZXZlbiAvZWlnaHQgL25pbmUgNjUgL0EgL0IgL0MgL0Qg L0UgL0YgNzMgL0kgNzYgL0wgL00gNzkgL08gL1AgODIgL1IgL1MgL1QgL1UgL1YgOTcgL2EgL2Ig L2MgL2QgL2UgL2YgL2cgL2ggL2kgMTA3IC9rIC9sIC9tIC9uIC9vIC9wIC9xIC9yIC9zIC90IC91 IC92IC93IC94IC95IC96IDE0NCAvcXVvdGVyaWdodA1dDT4+DWVuZG9iag0xMjYgMCBvYmoNPDwg L0ZpbHRlciAvRmxhdGVEZWNvZGUgL0xlbmd0aCAxMTINPj4Nc3RyZWFtCmjeHIvBDQQxDAKpywXx viqyXxQpJaSDyO/tw8V4ySELy4bptqo7u6pLnfRRdsUL5D/IziSTOOfsvddac05Vq0qVEqVQePA8 zxiD2TThwBDBkI0IAqEKZRggL3GFcAXewO8F0yXgdv34BBgAxENO3woNZW5kc3RyZWFtDWVuZG9i ag0xMjcgMCBvYmoNPDwgL0Nyb3BCb3gNWyAwIDAgNjEyIDc5Mg1dIC9CbGVlZEJveA1bIDAgMCA2 MTIgNzkyDV0gL01lZGlhQm94DVsgMCAwIDYxMiA3OTINXSAvUm90YXRlIDAgL1RyaW1Cb3gNWyAw IDAgNjEyIDc5Mg1dIC9UaHVtYiAxMjEgMCBSIC9SZXNvdXJjZXMNPDwgL0ZvbnQNPDwgL0YxIDY3 IDAgUiAvRjIgNzIgMCBSIC9GMyA1MiAwIFIgL0Y0IDU3IDAgUiAvRjUgNjIgMCBSIC9YaTggMTE3 IDAgUiAvWGk5IDExMSAwIFINPj4gL1Byb2NTZXQNWyAvUERGIC9UZXh0IC9JbWFnZUIgL0ltYWdl QyAvSW1hZ2VJDV0gL0V4dEdTdGF0ZQ08PCAvR1MxIDQyIDAgUiAvR1MyIDQ3IDAgUg0+PiAvWE9i amVjdA08PCAvWGkxMCAxMDUgMCBSIC9YaTAgMTIzIDAgUg0+Pg0+PiAvQXJ0Qm94DVsgMCAwIDYx MiA3OTINXSAvUGFyZW50IDM3IDAgUiAvQ29udGVudHMNWyA5IDAgUiAxMTUgMCBSIDEwOSAwIFIg MTAzIDAgUiA5NyAwIFIgOTIgMCBSIDg3IDAgUiA4MiAwIFIgNzcgMCBSIDQgMCBSDV0gL1R5cGUg L1BhZ2UNPj4NZW5kb2JqDTEyOCAwIG9iag08PCAvTGVuZ3RoIDQNPj4Nc3RyZWFtCv///woNZW5k c3RyZWFtDWVuZG9iaiB4cmVmDTAgMTI5DTAwMDAwMDAwMDAgNjU1MzUgZg0KMDAwMDAwMDA0NCAw MDAwMCBuDQowMDAwMDM1ODk4IDAwMDAwIG4NCjAwMDAwMzYyNzcgMDAwMDAgbg0KMDAwMDAzNjMy NCAwMDAwMCBuDQowMDAwMDM2NjU5IDAwMDAwIG4NCjAwMDAwMzY3MDUgMDAwMDAgbg0KMDAwMDA0 NzMxMSAwMDAwMCBuDQowMDAwMDU3NDMzIDAwMDAwIG4NCjAwMDAwODMwNDEgMDAwMDAgbg0KMDAw MDA4MzEyMiAwMDAwMCBuDQowMDAwMDgzMTc2IDAwMDAwIG4NCjAwMDAwODM4NDQgMDAwMDAgbg0K MDAwMDA4NDIyMiAwMDAwMCBuDQowMDAwMDg3MTUxIDAwMDAwIG4NCjAwMDAwODczMDMgMDAwMDAg bg0KMDAwMDA4NzM0OSAwMDAwMCBuDQowMDAwMDg3Nzg4IDAwMDAwIG4NCjAwMDAwODgzNTQgMDAw MDAgbg0KMDAwMDE0MjQ4MyAwMDAwMCBuDQowMDAwMTQyNTY1IDAwMDAwIG4NCjAwMDAxNDI2MjIg MDAwMDAgbg0KMDAwMDE0MzE0MiAwMDAwMCBuDQowMDAwMTQzNzUzIDAwMDAwIG4NCjAwMDAxNzc0 OTggMDAwMDAgbg0KMDAwMDE3NzY1MCAwMDAwMCBuDQowMDAwMTc4MzUwIDAwMDAwIG4NCjAwMDAx Nzg3OTkgMDAwMDAgbg0KMDAwMDE3OTIwOCAwMDAwMCBuDQowMDAwMTg3MTU1IDAwMDAwIG4NCjAw MDAxODcyMzcgMDAwMDAgbg0KMDAwMDE4NzQ0NCAwMDAwMCBuDQowMDAwMTg3ODkzIDAwMDAwIG4N CjAwMDAxODc5NDQgMDAwMDAgbg0KMDAwMDE4ODg3MCAwMDAwMCBuDQowMDAwMTg5MDIyIDAwMDAw IG4NCjAwMDAxODkyMjYgMDAwMDAgbg0KMDAwMDE4OTcwNiAwMDAwMCBuDQowMDAwMTg5ODE3IDAw MDAwIG4NCjAwMDAxOTE4ODkgMDAwMDAgbg0KMDAwMDE5MTk3MSAwMDAwMCBuDQowMDAwMTkyMTgw IDAwMDAwIG4NCjAwMDAxOTI4NjIgMDAwMDAgbg0KMDAwMDE5MjkyMCAwMDAwMCBuDQowMDAwMTkz MjY1IDAwMDAwIG4NCjAwMDAxOTM0MTcgMDAwMDAgbg0KMDAwMDE5MzYyMiAwMDAwMCBuDQowMDAw MTk0MTAxIDAwMDAwIG4NCjAwMDAxOTQxNDkgMDAwMDAgbg0KMDAwMDE5NDI2MyAwMDAwMCBuDQow MDAwMTk0MzQ1IDAwMDAwIG4NCjAwMDAxOTQ1NTAgMDAwMDAgbg0KMDAwMDIwNDA1NyAwMDAwMCBu DQowMDAwMjA0NzAwIDAwMDAwIG4NCjAwMDAyMDQ5MzggMDAwMDAgbg0KMDAwMDIwNTA4OSAwMDAw MCBuDQowMDAwMjA1MjkzIDAwMDAwIG4NCjAwMDAyMDU2NjMgMDAwMDAgbg0KMDAwMDIwNjMwNSAw MDAwMCBuDQowMDAwMjA2ODM1IDAwMDAwIG4NCjAwMDAyMDY5MTcgMDAwMDAgbg0KMDAwMDIwNzEy NiAwMDAwMCBuDQowMDAwMjA3NDk4IDAwMDAwIG4NCjAwMDAyMDc2ODIgMDAwMDAgbg0KMDAwMDIx OTM2NCAwMDAwMCBuDQowMDAwMjE5NTE2IDAwMDAwIG4NCjAwMDAyMTk3MjEgMDAwMDAgbg0KMDAw MDIyMDE4NCAwMDAwMCBuDQowMDAwMjIwODExIDAwMDAwIG4NCjAwMDAyMjE0MDUgMDAwMDAgbg0K MDAwMDIyMTQ4NyAwMDAwMCBuDQowMDAwMjIxNjk3IDAwMDAwIG4NCjAwMDAyMjkzOTAgMDAwMDAg bg0KMDAwMDIzMDE0NiAwMDAwMCBuDQowMDAwMjQxMzM5IDAwMDAwIG4NCjAwMDAyNDE0OTEgMDAw MDAgbg0KMDAwMDI0MTY5NSAwMDAwMCBuDQowMDAwMjQyMDY1IDAwMDAwIG4NCjAwMDAyNDMyNzQg MDAwMDAgbg0KMDAwMDI0Mzk0NCAwMDAwMCBuDQowMDAwMjQ0MDI2IDAwMDAwIG4NCjAwMDAyNDQy MzEgMDAwMDAgbg0KMDAwMDI0NDU1OCAwMDAwMCBuDQowMDAwMjQ2MDMxIDAwMDAwIG4NCjAwMDAy NjEwNTEgMDAwMDAgbg0KMDAwMDI2MTI1OSAwMDAwMCBuDQowMDAwMjYxNDYzIDAwMDAwIG4NCjAw MDAyNjE4NzggMDAwMDAgbg0KMDAwMDI2MzM1MSAwMDAwMCBuDQowMDAwMjY0MDM0IDAwMDAwIG4N CjAwMDAyODI5MTcgMDAwMDAgbg0KMDAwMDI4MzEyNyAwMDAwMCBuDQowMDAwMjgzMzQyIDAwMDAw IG4NCjAwMDAyODQ5NDkgMDAwMDAgbg0KMDAwMDI5NjM2OSAwMDAwMCBuDQowMDAwMjk2NTc3IDAw MDAwIG4NCjAwMDAyOTY3ODcgMDAwMDAgbg0KMDAwMDI5NzA3OCAwMDAwMCBuDQowMDAwMjk4NjAw IDAwMDAwIG4NCjAwMDAyOTkwMjUgMDAwMDAgbg0KMDAwMDMyMTE4NyAwMDAwMCBuDQowMDAwMzIx MzkyIDAwMDAwIG4NCjAwMDAzMjE0NTggMDAwMDAgbg0KMDAwMDMyMTgzMSAwMDAwMCBuDQowMDAw MzIzMzc3IDAwMDAwIG4NCjAwMDAzMjM5ODkgMDAwMDAgbg0KMDAwMDM0OTg1NyAwMDAwMCBuDQow MDAwMzc2MTI2IDAwMDAwIG4NCjAwMDAzNzYzMzkgMDAwMDAgbg0KMDAwMDM3NjUzNSAwMDAwMCBu DQowMDAwMzc4MTQzIDAwMDAwIG4NCjAwMDAzNzg3ODIgMDAwMDAgbg0KMDAwMDM3OTE5MCAwMDAw MCBuDQowMDAwMzc5OTEzIDAwMDAwIG4NCjAwMDAzODQ4MjkgMDAwMDAgbg0KMDAwMDM5ODAyMSAw MDAwMCBuDQowMDAwMzk4OTM4IDAwMDAwIG4NCjAwMDAzOTg5OTMgMDAwMDAgbg0KMDAwMDM5OTcw MCAwMDAwMCBuDQowMDAwNDAyNDAwIDAwMDAwIG4NCjAwMDA0MDI3NzkgMDAwMDAgbg0KMDAwMDQw MzM0NCAwMDAwMCBuDQowMDAwNDAzODQ1IDAwMDAwIG4NCjAwMDA0MDM4OTMgMDAwMDAgbg0KMDAw MDQwNDExNyAwMDAwMCBuDQowMDAwNDA0MTU2IDAwMDAwIG4NCjAwMDA0MDQ0NTkgMDAwMDAgbg0K MDAwMDQwNDY0NSAwMDAwMCBuDQowMDAwNDA1MTcyIDAwMDAwIG4NCnRyYWlsZXINDTw8IC9Sb290 IDEwOCAwIFIgL1NpemUgMTI5IC9JRA1bIDw4ZTFhNmM4MTY2ZDhjMWFhMjg3YmZjOGJkODAzYmVk OD4gPDZiZDJlODgxN2Q4YmUzN2M2N2M4MDBiMTFlZmZlOGU4Pg1dIC9JbmZvIDEwMiAwIFINPj4N c3RhcnR4cmVmDTQwNTIyNw0lJUVPRgoN --00151747806cd95b4104ad6bfde0 Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel --00151747806cd95b4104ad6bfde0-- From xen-devel-bounces@lists.xensource.com Thu Sep 22 04:54:24 2011 Return-path: <xen-devel-bounces@lists.xensource.com> Envelope-to: www-data@lists.xensource.com Delivery-date: Thu, 22 Sep 2011 04:54:24 -0700 Received: from localhost ([127.0.0.1] helo=lists.colo.xensource.com) by lists.xensource.com with esmtp (Exim 4.43) id 1R6hrE-0004J5-3p; Thu, 22 Sep 2011 04:54:24 -0700 Received: from mail21.messagelabs.com ([85.158.143.35]) by lists.xensource.com with esmtp (Exim 4.43) id 1R6OQ9-0002MK-1f for xen-devel@lists.xensource.com; Wed, 21 Sep 2011 08:09:09 -0700 X-Env-Sender: konrad@oracle.com X-Msg-Ref: server-7.tower-21.messagelabs.com!1316617714!55719558!1 X-Originating-IP: [148.87.113.117] X-StarScan-Version: 6.4.1; banners=-,-,- X-VirusChecked: Checked Received: (qmail 1657 invoked from network); 21 Sep 2011 15:08:35 -0000 Received: from rcsinet15.oracle.com (HELO rcsinet15.oracle.com) (148.87.113.117) by server-7.tower-21.messagelabs.com with DHE-RSA-AES256-SHA encrypted SMTP; 21 Sep 2011 15:08:35 -0000 Received: from rtcsinet22.oracle.com (rtcsinet22.oracle.com [66.248.204.30]) by rcsinet15.oracle.com (Switch-3.4.4/Switch-3.4.4) with ESMTP id p8LF8x0P009614 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Wed, 21 Sep 2011 15:09:01 GMT Received: from acsmt357.oracle.com (acsmt357.oracle.com [141.146.40.157]) by rtcsinet22.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id p8LF8wci000761 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 21 Sep 2011 15:08:59 GMT Received: from abhmt114.oracle.com (abhmt114.oracle.com [141.146.116.66]) by acsmt357.oracle.com (8.12.11.20060308/8.12.11) with ESMTP id p8LF8q5S027834; Wed, 21 Sep 2011 10:08:53 -0500 Received: from oracle.com (/209.6.55.207) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Wed, 21 Sep 2011 08:08:52 -0700 Received: by oracle.com (Postfix, from userid 1000) id EA2441362; Wed, 21 Sep 2011 11:08:58 -0400 (EDT) Date: Wed, 21 Sep 2011 11:08:58 -0400 From: Konrad Rzeszutek <konrad@konrad-lan> To: David Vrabel <david.vrabel@citrix.com> Message-ID: <20110921150858.GE541@phenom.oracle.com> References: <1316089768-22461-1-git-send-email-david.vrabel@citrix.com> <1316089768-22461-3-git-send-email-david.vrabel@citrix.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <1316089768-22461-3-git-send-email-david.vrabel@citrix.com> User-Agent: Mutt/1.5.21 (2010-09-15) X-Source-IP: rtcsinet22.oracle.com [66.248.204.30] X-CT-RefId: str=0001.0A090204.4E79FE0E.0030,ss=1,re=0.000,fgs=0 X-Mailman-Approved-At: Thu, 22 Sep 2011 04:51:41 -0700 Cc: xen-devel@lists.xensource.com, Konrad Rzeszutek Wilk <konrad.wilk@oracle.com> Subject: [Xen-devel] Re: [PATCH 2/7] xen: avoid adding non-existant memory if the reservation is unlimited X-BeenThere: xen-devel@lists.xensource.com X-Mailman-Version: 2.1.5 Precedence: list List-Id: Xen developer discussion <xen-devel.lists.xensource.com> List-Unsubscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe> List-Post: <mailto:xen-devel@lists.xensource.com> List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help> List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=subscribe> Sender: xen-devel-bounces@lists.xensource.com Errors-To: xen-devel-bounces@lists.xensource.com On Thu, Sep 15, 2011 at 01:29:23PM +0100, David Vrabel wrote: > From: David Vrabel <david.vrabel@citrix.com> > > If the domain's reservation is unlimited, too many pages are added to > the balloon memory region. Correctly check the limit so the number of > extra pages is not increased in this case. and this one is in 3.1 too. Albeit with a more verbose description. Look in git commit: e3b73c4a25e9a5705b4ef28b91676caf01f9bc9f > > Signed-off-by: David Vrabel <david.vrabel@citrix.com> > --- > arch/x86/xen/setup.c | 10 ++++++---- > 1 files changed, 6 insertions(+), 4 deletions(-) > > diff --git a/arch/x86/xen/setup.c b/arch/x86/xen/setup.c > index c3b8d44..46d6d21 100644 > --- a/arch/x86/xen/setup.c > +++ b/arch/x86/xen/setup.c > @@ -306,10 +306,12 @@ char * __init xen_memory_setup(void) > sanitize_e820_map(e820.map, ARRAY_SIZE(e820.map), &e820.nr_map); > > extra_limit = xen_get_max_pages(); > - if (extra_limit >= max_pfn) > - extra_pages = extra_limit - max_pfn; > - else > - extra_pages = 0; > + if (max_pfn + extra_pages > extra_limit) { > + if (extra_limit > max_pfn) > + extra_pages = extra_limit - max_pfn; > + else > + extra_pages = 0; > + } > > extra_pages += xen_return_unused_memory(xen_start_info->nr_pages, &e820); > > -- > 1.7.2.5 _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel From xen-devel-bounces@lists.xensource.com Thu Sep 22 05:02:42 2011 Return-path: <xen-devel-bounces@lists.xensource.com> Envelope-to: www-data@lists.xensource.com Delivery-date: Thu, 22 Sep 2011 05:02:42 -0700 Received: from localhost ([127.0.0.1] helo=lists.colo.xensource.com) by lists.xensource.com with esmtp (Exim 4.43) id 1R6hzG-0005Y8-6D; Thu, 22 Sep 2011 05:02:42 -0700 Received: from mail174.messagelabs.com ([85.158.138.51]) by lists.xensource.com with smtp (Exim 4.43) id 1R6hvo-0005In-3q for xen-devel@lists.xensource.com; Thu, 22 Sep 2011 05:00:05 -0700 X-Env-Sender: stefan.bader@canonical.com X-Msg-Ref: server-15.tower-174.messagelabs.com!1316692740!26010219!1 X-Originating-IP: [91.189.89.112] X-StarScan-Version: 6.4.1; banners=-,-,- X-VirusChecked: Checked Received: (qmail 28641 invoked from network); 22 Sep 2011 11:59:00 -0000 Received: from youngberry.canonical.com (HELO youngberry.canonical.com) (91.189.89.112) by server-15.tower-174.messagelabs.com with SMTP; 22 Sep 2011 11:59:00 -0000 Received: from p5b2e3716.dip.t-dialin.net ([91.46.55.22] helo=[192.168.2.5]) by youngberry.canonical.com with esmtpsa (TLS1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.71) (envelope-from <stefan.bader@canonical.com>) id 1R6hvf-0002sA-Mg; Thu, 22 Sep 2011 11:58:59 +0000 Message-ID: <4E7B2301.1050004@canonical.com> Date: Thu, 22 Sep 2011 13:58:57 +0200 From: Stefan Bader <stefan.bader@canonical.com> User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.2.21) Gecko/20110831 Lightning/1.0b2 Thunderbird/3.1.13 MIME-Version: 1.0 To: Stefano Stabellini <stefano.stabellini@eu.citrix.com> Subject: Re: [Xen-devel] Re: Still struggling with HVM: tx timeouts on emulated nics References: <4E79E08D.1090503@canonical.com> <alpine.DEB.2.00.1109211422180.8700@kaball-desktop> <4E7A0410.7050405@canonical.com> <alpine.DEB.2.00.1109221128120.8700@kaball-desktop> In-Reply-To: <alpine.DEB.2.00.1109221128120.8700@kaball-desktop> X-Enigmail-Version: 1.1.2 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>, "Stefano@rly59j.srv.mailcontrol.com" <Stefano@rly59j.srv.mailcontrol.com> X-BeenThere: xen-devel@lists.xensource.com X-Mailman-Version: 2.1.5 Precedence: list List-Id: Xen developer discussion <xen-devel.lists.xensource.com> List-Unsubscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe> List-Post: <mailto:xen-devel@lists.xensource.com> List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help> List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=subscribe> Sender: xen-devel-bounces@lists.xensource.com Errors-To: xen-devel-bounces@lists.xensource.com On 22.09.2011 12:30, Stefano Stabellini wrote: > On Wed, 21 Sep 2011, Stefan Bader wrote: >> On 21.09.2011 15:31, Stefano Stabellini wrote: >>> On Wed, 21 Sep 2011, Stefan Bader wrote: >>>> This is on 3.0.4 based dom0 and domU with 4.1.1 hypervisor. I tried using the >>>> default 8139cp and ne2k_pci emulated nic. The 8139cp one at least comes up and >>>> gets configured via dhcp. And initial pings also get routed and done correctly. >>>> But slightly higher traffic (like checking for updates) hangs. And after a while >>>> there are messages about tx timeouts. >>>> The ne2k_pci type nic almost immediately has those issues and never comes up >>>> correctly. >>>> >>>> I am attaching the dmesg of the guest with apic=debug enabled. I am not sure how >>>> this should be but both nics get configured with level,low IRQs. Disk emulation >>>> seems to be ok but that seem to use IO-APIC-edge. And any other IRQs seem to be >>>> at least not level. >>> >> >>> Does the e1000 emulated card work correctly? >> >> Yes, that one seems to work ok. >> >>> What happens if you disable interrupt remapping (see patch below)? >> >> 8139cp seems to work correctly now (much higher irq stats as well) and e1000 >> still works. Both then using IOAPIC-fasteoi. >> > > That means there must be another subtle bug in Xen in interrupt > remapping that only affects 8139p emulation > Right, or to be complete: - e1000: ok - 8139cp: unstable (setup is possible) - ne2k_pci: not working (tx problems from the beginning) The behaviour feels a bit like interrupts may get lost if occurring at a higher rate. Why this affects various drivers differently is a bit weird. > >>>> Another problem came up recently though that may just be me doing the wrong >>>> thing. Normally I boot with xen_emul_unplug=unnecessary as I want the emulated >>>> devices. xen-blkfront is a module in my case and I thought I once had been able >>>> to use that by removing the unplug arg and making the blkfront driver load. But >>>> when I recently tried the module loaded but no disks appeared... Again, not sure >>>> I just forgot how to do that right or that was different when using a 4.1.0 >>>> hypervisor still... >>> >>> xen_emul_unplug=unnecessary allows the kernel to use PV interfaces on >>> older hypervisors that didn't support the unplug protocol and had other >>> ways to cope with multiple drivers accessing the same devices. >>> You can use xen_emul_unplug=never to prevent any unplug but you won't >>> get any PV interfaces. >> >> Hm, odd. Somehow I thought that I had been using pv interfaces that way when the >> interrupts for the emulated ide was broken. >> A bit suboptimal atm, because without any option and a kernel compiled with the >> platform pci and pv drivers (as modules) booting in HVM mode the kernel decides >> that having both is no use and unplugs the emulated devices. Which then leaves >> you with ... none. > > In theory you would have the PV frontend modules in the initrd. > On the other hand having both can easily cause data corruptions on your > drive. They _are_ in the initrd. And the boot rightfully drops to a maintenance shell right now (without any argument and the emulated devices unplugged). And "modprobe xen-blkfront" loads the module but it does _not_ detect any pv device. -Stefan _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel From xen-devel-bounces@lists.xensource.com Thu Sep 22 05:05:36 2011 Return-path: <xen-devel-bounces@lists.xensource.com> Envelope-to: www-data@lists.xensource.com Delivery-date: Thu, 22 Sep 2011 05:05:36 -0700 Received: from localhost ([127.0.0.1] helo=lists.colo.xensource.com) by lists.xensource.com with esmtp (Exim 4.43) id 1R6i23-0005ww-GA; Thu, 22 Sep 2011 05:05:35 -0700 Received: from mail21.messagelabs.com ([85.158.143.35]) by lists.xensource.com with esmtp (Exim 4.43) id 1R6hzB-0005Xb-Ez for xen-devel@lists.xensource.com; Thu, 22 Sep 2011 05:02:39 -0700 X-Env-Sender: royger@gmail.com X-Msg-Ref: server-7.tower-21.messagelabs.com!1316692922!55823575!2 X-Originating-IP: [74.125.82.171] X-StarScan-Version: 6.4.1; banners=-,-,- X-VirusChecked: Checked Received: (qmail 29145 invoked from network); 22 Sep 2011 12:02:04 -0000 Received: from mail-wy0-f171.google.com (HELO mail-wy0-f171.google.com) (74.125.82.171) by server-7.tower-21.messagelabs.com with RC4-SHA encrypted SMTP; 22 Sep 2011 12:02:04 -0000 Received: by mail-wy0-f171.google.com with SMTP id 13so1456438wyh.30 for <xen-devel@lists.xensource.com>; Thu, 22 Sep 2011 05:02:34 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=sender:content-type:mime-version:content-transfer-encoding:subject :x-mercurial-node:message-id:in-reply-to:references:user-agent:date :from:to; bh=Y9agv2DDvWnfTknlp1kFer4N759bYwV1TA6mQHIZfbk=; b=hPamvIkYR01zUm6f+Z28xU9AT9B5El73bhVWB2aeP3yNY/44zymeBJ5zizHWjIhkoO U6zGT8D69T6h9jODMSf5oINwwBg1EXlso2+3aSPpjTvy8U0Io4plMjekBnqv9MDSYXW9 VCswHBkpwkrwxIfkrXNNsoD/VaLht83AMjTFw= Received: by 10.216.209.212 with SMTP id s62mr2067602weo.67.1316692954486; Thu, 22 Sep 2011 05:02:34 -0700 (PDT) Received: from [127.0.0.1] (monk.upc.es. [147.83.39.235]) by mx.google.com with ESMTPS id es10sm5404859wbb.4.2011.09.22.05.02.32 (version=TLSv1/SSLv3 cipher=OTHER); Thu, 22 Sep 2011 05:02:33 -0700 (PDT) Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Mercurial-Node: 1d3830f8a7306088b49d5732b5e88a73c2bc0315 Message-Id: <1d3830f8a7306088b49d.1316692869@loki> In-Reply-To: <patchbomb.1316692867@loki> References: <patchbomb.1316692867@loki> User-Agent: Mercurial-patchbomb/1.8.4 Date: Thu, 22 Sep 2011 14:01:09 +0200 From: Roger Pau Monne <roger.pau@entel.upc.edu> To: xen-devel@lists.xensource.com Subject: [Xen-devel] [PATCH 2 of 6] hotplug: set hotplug-status to disconnected at removal X-BeenThere: xen-devel@lists.xensource.com X-Mailman-Version: 2.1.5 Precedence: list List-Id: Xen developer discussion <xen-devel.lists.xensource.com> List-Unsubscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe> List-Post: <mailto:xen-devel@lists.xensource.com> List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help> List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=subscribe> Sender: xen-devel-bounces@lists.xensource.com Errors-To: xen-devel-bounces@lists.xensource.com # HG changeset patch # User Roger Pau Monne <roger.pau@entel.upc.edu> # Date 1316692482 -7200 # Node ID 1d3830f8a7306088b49d5732b5e88a73c2bc0315 # Parent 576c0ce336acb501cbba245dc801f06edc391479 hotplug: set hotplug-status to disconnected at removal Set the hotplug-status attribute of xenstore to disconnected when the hotplug block script has finished disconnecting the device Signed-off-by: Roger Pau Monne <roger.pau@entel.upc.edu> diff -r 576c0ce336ac -r 1d3830f8a730 tools/hotplug/Linux/block --- a/tools/hotplug/Linux/block Thu Sep 22 13:54:35 2011 +0200 +++ b/tools/hotplug/Linux/block Thu Sep 22 13:54:42 2011 +0200 @@ -321,6 +321,7 @@ mount it read-write in a guest domain." remove) case $t in phy) + xenstore_write "$XENBUS_PATH/hotplug-status" "disconnected" exit 0 ;; @@ -329,6 +330,7 @@ mount it read-write in a guest domain." node=$(xenstore_read "$XENBUS_PATH/node") losetup -d "$node" release_lock "block" + xenstore_write "$XENBUS_PATH/hotplug-status" "disconnected" exit 0 ;; diff -r 576c0ce336ac -r 1d3830f8a730 tools/hotplug/NetBSD/block --- a/tools/hotplug/NetBSD/block Thu Sep 22 13:54:35 2011 +0200 +++ b/tools/hotplug/NetBSD/block Thu Sep 22 13:54:42 2011 +0200 @@ -38,6 +38,7 @@ 6) echo "unknown type $xtype" >&2 ;; esac + xenstore-write $xpath/hotplug-status disconnected xenstore-rm $xpath exit 0 ;; _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel From xen-devel-bounces@lists.xensource.com Thu Sep 22 05:07:25 2011 Return-path: <xen-devel-bounces@lists.xensource.com> Envelope-to: www-data@lists.xensource.com Delivery-date: Thu, 22 Sep 2011 05:07:25 -0700 Received: from localhost ([127.0.0.1] helo=lists.colo.xensource.com) by lists.xensource.com with esmtp (Exim 4.43) id 1R6i3p-0006KS-1U; Thu, 22 Sep 2011 05:07:25 -0700 Received: from mail21.messagelabs.com ([85.158.143.35]) by lists.xensource.com with esmtp (Exim 4.43) id 1R6hzA-0005XW-Iy for xen-devel@lists.xensource.com; Thu, 22 Sep 2011 05:02:39 -0700 X-Env-Sender: royger@gmail.com X-Msg-Ref: server-7.tower-21.messagelabs.com!1316692922!55823575!1 X-Originating-IP: [74.125.82.171] X-StarScan-Version: 6.4.1; banners=-,-,- X-VirusChecked: Checked Received: (qmail 29058 invoked from network); 22 Sep 2011 12:02:02 -0000 Received: from mail-wy0-f171.google.com (HELO mail-wy0-f171.google.com) (74.125.82.171) by server-7.tower-21.messagelabs.com with RC4-SHA encrypted SMTP; 22 Sep 2011 12:02:02 -0000 Received: by wyh13 with SMTP id 13so1456438wyh.30 for <xen-devel@lists.xensource.com>; Thu, 22 Sep 2011 05:02:32 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=sender:content-type:mime-version:content-transfer-encoding:subject :x-mercurial-node:message-id:in-reply-to:references:user-agent:date :from:to; bh=U/LL8JJHEiEL3lWB+u4/VMSW3bgk9D+tKMKsMvIXoLk=; b=SdtxZZ0XZ8q7+aT30A3+tlQ9cday2cHKyZQw4k8YOAQOC+KpRdsXfbgDaVDJSXowE9 CvPivCIUWFE3krQnZSHnBEJmMmO1jzNYsX+1STBOxR9iZxIPFeDGX9YgQFvCNP/XL26X ySUvDngnN49+lH23BXDXdOC1wUrBpDKiFOEsw= Received: by 10.227.154.19 with SMTP id m19mr535867wbw.2.1316692952554; Thu, 22 Sep 2011 05:02:32 -0700 (PDT) Received: from [127.0.0.1] (monk.upc.es. [147.83.39.235]) by mx.google.com with ESMTPS id es10sm5404859wbb.4.2011.09.22.05.02.30 (version=TLSv1/SSLv3 cipher=OTHER); Thu, 22 Sep 2011 05:02:31 -0700 (PDT) Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Mercurial-Node: 576c0ce336acb501cbba245dc801f06edc391479 Message-Id: <576c0ce336acb501cbba.1316692868@loki> In-Reply-To: <patchbomb.1316692867@loki> References: <patchbomb.1316692867@loki> User-Agent: Mercurial-patchbomb/1.8.4 Date: Thu, 22 Sep 2011 14:01:08 +0200 From: Roger Pau Monne <roger.pau@entel.upc.edu> To: xen-devel@lists.xensource.com Subject: [Xen-devel] [PATCH 1 of 6] xenbackendd: fix incorrect usage of pidfile X-BeenThere: xen-devel@lists.xensource.com X-Mailman-Version: 2.1.5 Precedence: list List-Id: Xen developer discussion <xen-devel.lists.xensource.com> List-Unsubscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe> List-Post: <mailto:xen-devel@lists.xensource.com> List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help> List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=subscribe> Sender: xen-devel-bounces@lists.xensource.com Errors-To: xen-devel-bounces@lists.xensource.com # HG changeset patch # User Roger Pau Monne <roger.pau@entel.upc.edu> # Date 1316692475 -7200 # Node ID 576c0ce336acb501cbba245dc801f06edc391479 # Parent a422e2a4451e16dc791b293f41966b842fa4781d xenbackendd: fix incorrect usage of pidfile Fix xenbackendd ignoring the pidfile passed through the command line. Signed-off-by: Roger Pau Monne <roger.pau@entel.upc.edu> diff -r a422e2a4451e -r 576c0ce336ac tools/xenbackendd/xenbackendd.c --- a/tools/xenbackendd/xenbackendd.c Sun Sep 18 00:26:52 2011 +0100 +++ b/tools/xenbackendd/xenbackendd.c Thu Sep 22 13:54:35 2011 +0200 @@ -169,7 +169,7 @@ main(int argc, char * const argv[]) log_file = optarg; break; case 'p': - pidfile = pidfile; + pidfile = optarg; case 's': vbd_script = optarg; break; _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel From xen-devel-bounces@lists.xensource.com Thu Sep 22 05:09:11 2011 Return-path: <xen-devel-bounces@lists.xensource.com> Envelope-to: www-data@lists.xensource.com Delivery-date: Thu, 22 Sep 2011 05:09:11 -0700 Received: from localhost ([127.0.0.1] helo=lists.colo.xensource.com) by lists.xensource.com with esmtp (Exim 4.43) id 1R6i5V-0006hu-M6; Thu, 22 Sep 2011 05:09:09 -0700 Received: from mail21.messagelabs.com ([85.158.143.35]) by lists.xensource.com with esmtp (Exim 4.43) id 1R6hzD-0005Y0-DW for xen-devel@lists.xensource.com; Thu, 22 Sep 2011 05:02:40 -0700 X-Env-Sender: royger@gmail.com X-Msg-Ref: server-7.tower-21.messagelabs.com!1316692922!55823575!3 X-Originating-IP: [74.125.82.171] X-StarScan-Version: 6.4.1; banners=-,-,- X-VirusChecked: Checked Received: (qmail 29234 invoked from network); 22 Sep 2011 12:02:06 -0000 Received: from mail-wy0-f171.google.com (HELO mail-wy0-f171.google.com) (74.125.82.171) by server-7.tower-21.messagelabs.com with RC4-SHA encrypted SMTP; 22 Sep 2011 12:02:06 -0000 Received: by mail-wy0-f171.google.com with SMTP id 13so1456438wyh.30 for <xen-devel@lists.xensource.com>; Thu, 22 Sep 2011 05:02:36 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=sender:content-type:mime-version:content-transfer-encoding:subject :x-mercurial-node:message-id:in-reply-to:references:user-agent:date :from:to; bh=dv1ozdESa6eXODof0vWWoSABpPC4QbCbGDaqmY3oIm8=; b=pBJYIRUtj4rIOGgdSb7M9RVp4w6T9rgOzf0p1ajzRd4YsbNAZK1xNbNRF+CUYxjj7z hQwR6703VFGGz01Nrpy7APW/pUV1Fg/XkIcLTGfi6vmlDqmLIWL74bO+zpLTRvvaJRVf eyt+lDZ1m41Ncjh+VGd4jftI/tDRzLEfMwcZM= Received: by 10.227.138.78 with SMTP id z14mr2092796wbt.17.1316692956415; Thu, 22 Sep 2011 05:02:36 -0700 (PDT) Received: from [127.0.0.1] (monk.upc.es. [147.83.39.235]) by mx.google.com with ESMTPS id es10sm5404859wbb.4.2011.09.22.05.02.34 (version=TLSv1/SSLv3 cipher=OTHER); Thu, 22 Sep 2011 05:02:35 -0700 (PDT) Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Mercurial-Node: 2d77cbdc816bc943e9e69ecca34ae7157079045a Message-Id: <2d77cbdc816bc943e9e6.1316692870@loki> In-Reply-To: <patchbomb.1316692867@loki> References: <patchbomb.1316692867@loki> User-Agent: Mercurial-patchbomb/1.8.4 Date: Thu, 22 Sep 2011 14:01:10 +0200 From: Roger Pau Monne <roger.pau@entel.upc.edu> To: xen-devel@lists.xensource.com Subject: [Xen-devel] [PATCH 3 of 6] xenbackendd: pass type of block device to hotplug script X-BeenThere: xen-devel@lists.xensource.com X-Mailman-Version: 2.1.5 Precedence: list List-Id: Xen developer discussion <xen-devel.lists.xensource.com> List-Unsubscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe> List-Post: <mailto:xen-devel@lists.xensource.com> List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help> List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=subscribe> Sender: xen-devel-bounces@lists.xensource.com Errors-To: xen-devel-bounces@lists.xensource.com # HG changeset patch # User Roger Pau Monne <roger.pau@entel.upc.edu> # Date 1316692489 -7200 # Node ID 2d77cbdc816bc943e9e69ecca34ae7157079045a # Parent 1d3830f8a7306088b49d5732b5e88a73c2bc0315 xenbackendd: pass type of block device to hotplug script Pass the type of block device to attach to the block script instead of reading it from xenstore, since new Xen versions don't make a difference between a block device or an image. Signed-off-by: Roger Pau Monne <roger.pau@entel.upc.edu> diff -r 1d3830f8a730 -r 2d77cbdc816b tools/hotplug/NetBSD/block --- a/tools/hotplug/NetBSD/block Thu Sep 22 13:54:42 2011 +0200 +++ b/tools/hotplug/NetBSD/block Thu Sep 22 13:54:49 2011 +0200 @@ -19,7 +19,7 @@ error() { xpath=$1 xstatus=$2 -xtype=$(xenstore-read "$xpath/type") +xtype=$3 xparams=$(xenstore-read "$xpath/params") case $xstatus in diff -r 1d3830f8a730 -r 2d77cbdc816b tools/xenbackendd/xenbackendd.c --- a/tools/xenbackendd/xenbackendd.c Thu Sep 22 13:54:42 2011 +0200 +++ b/tools/xenbackendd/xenbackendd.c Thu Sep 22 13:54:49 2011 +0200 @@ -89,15 +89,15 @@ dodebug(const char *fmt, ...) } static void -doexec(const char *cmd, const char *arg1, const char *arg2) +doexec(const char *cmd, const char *arg1, const char *arg2, const char *arg3) { - dodebug("exec %s %s %s", cmd, arg1, arg2); + dodebug("exec %s %s %s %s", cmd, arg1, arg2, arg3); switch(vfork()) { case -1: dolog(LOG_ERR, "can't vfork: %s", strerror(errno)); break; case 0: - execl(cmd, cmd, arg1, arg2, NULL); + execl(cmd, cmd, arg1, arg2, arg3, NULL); dolog(LOG_ERR, "can't exec %s: %s", cmd, strerror(errno)); exit(EXIT_FAILURE); /* NOTREACHED */ @@ -145,11 +145,14 @@ xen_setup(void) int main(int argc, char * const argv[]) { + struct stat stab; char **vec; unsigned int num; char *s; int state; char *sstate; + char *stype; + char *params; char *p; char buf[80]; int type; @@ -297,11 +300,38 @@ main(int argc, char * const argv[]) strerror(errno)); goto next2; } - doexec(s, vec[XS_WATCH_PATH], sstate); + doexec(s, vec[XS_WATCH_PATH], sstate, NULL); break; case DEVTYPE_VBD: - doexec(vbd_script, vec[XS_WATCH_PATH], sstate); + /* check if given file is a block device or a raw image */ + snprintf(buf, sizeof(buf), "%s/params", vec[XS_WATCH_PATH]); + params = xs_read(xs, XBT_NULL, buf, 0); + if(params == NULL) { + dolog(LOG_ERR, + "Failed to read %s (%s)", buf, strerror(errno)); + goto next2; + } + if (stat(params, &stab) < 0) { + dolog(LOG_ERR, + "Failed to get info about %s (%s)", params, + strerror(errno)); + goto next3; + } + stype = NULL; + if (S_ISBLK(stab.st_mode)) + stype = "phy"; + if (S_ISREG(stab.st_mode)) + stype = "file"; + if (stype == NULL) { + dolog(LOG_ERR, + "Failed to attach %s (not a block device or raw image)", + params, strerror(errno)); + goto next3; + } + doexec(vbd_script, vec[XS_WATCH_PATH], sstate, stype); +next3: + free(params); break; default: _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel From xen-devel-bounces@lists.xensource.com Thu Sep 22 05:10:29 2011 Return-path: <xen-devel-bounces@lists.xensource.com> Envelope-to: www-data@lists.xensource.com Delivery-date: Thu, 22 Sep 2011 05:10:29 -0700 Received: from localhost ([127.0.0.1] helo=lists.colo.xensource.com) by lists.xensource.com with esmtp (Exim 4.43) id 1R6i6n-00074g-M3; Thu, 22 Sep 2011 05:10:29 -0700 Received: from mail182.messagelabs.com ([85.158.139.83]) by lists.xensource.com with esmtp (Exim 4.43) id 1R6hz8-0005XP-Ao for xen-devel@lists.xensource.com; Thu, 22 Sep 2011 05:02:36 -0700 X-Env-Sender: royger@gmail.com X-Msg-Ref: server-4.tower-182.messagelabs.com!1316692950!19329112!1 X-Originating-IP: [74.125.82.43] X-StarScan-Version: 6.4.1; banners=-,-,- X-VirusChecked: Checked Received: (qmail 656 invoked from network); 22 Sep 2011 12:02:31 -0000 Received: from mail-ww0-f43.google.com (HELO mail-ww0-f43.google.com) (74.125.82.43) by server-4.tower-182.messagelabs.com with RC4-SHA encrypted SMTP; 22 Sep 2011 12:02:31 -0000 Received: by wwf27 with SMTP id 27so1751239wwf.24 for <xen-devel@lists.xensource.com>; Thu, 22 Sep 2011 05:02:30 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=sender:content-type:mime-version:content-transfer-encoding:subject :message-id:user-agent:date:from:to; bh=4TOlxDAsK+VJGKK67KLdCqFjERcoxS3TjOV3WtAVGxU=; b=bak25GxbamyDsKkj6KGkDGBmZrFLBPIUtq8mlBHotU6sCG2/xIC2TdPv5RgOQh18bp Tjln5y9ZVCb2Mz4wupbN2c/ThAwXru3rDrY27yPNCqiUxXWd3bo2ahwd5lX5QYKhccSp OA1kMKbUpnjQOfec+2yk+I1dBmJb/8X4avbGE= Received: by 10.216.172.10 with SMTP id s10mr2024413wel.85.1316692950727; Thu, 22 Sep 2011 05:02:30 -0700 (PDT) Received: from [127.0.0.1] (monk.upc.es. [147.83.39.235]) by mx.google.com with ESMTPS id es10sm5404859wbb.4.2011.09.22.05.02.28 (version=TLSv1/SSLv3 cipher=OTHER); Thu, 22 Sep 2011 05:02:29 -0700 (PDT) Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Message-Id: <patchbomb.1316692867@loki> User-Agent: Mercurial-patchbomb/1.8.4 Date: Thu, 22 Sep 2011 14:01:07 +0200 From: Roger Pau Monne <roger.pau@entel.upc.edu> To: xen-devel@lists.xensource.com Subject: [Xen-devel] [PATCH 0 of 6] Add NetBSD support for libxl X-BeenThere: xen-devel@lists.xensource.com X-Mailman-Version: 2.1.5 Precedence: list List-Id: Xen developer discussion <xen-devel.lists.xensource.com> List-Unsubscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe> List-Post: <mailto:xen-devel@lists.xensource.com> List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help> List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=subscribe> Sender: xen-devel-bounces@lists.xensource.com Errors-To: xen-devel-bounces@lists.xensource.com This serie of patches adds support for NetBSD in libxl and fixes a pair of bugs found on the process. All patches can be applied individually without breaking the build of xen. _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel From xen-devel-bounces@lists.xensource.com Thu Sep 22 05:11:25 2011 Return-path: <xen-devel-bounces@lists.xensource.com> Envelope-to: www-data@lists.xensource.com Delivery-date: Thu, 22 Sep 2011 05:11:25 -0700 Received: from localhost ([127.0.0.1] helo=lists.colo.xensource.com) by lists.xensource.com with esmtp (Exim 4.43) id 1R6i7h-0007RT-5H; Thu, 22 Sep 2011 05:11:25 -0700 Received: from mail21.messagelabs.com ([85.158.143.35]) by lists.xensource.com with esmtp (Exim 4.43) id 1R6hzF-0005YG-9F for xen-devel@lists.xensource.com; Thu, 22 Sep 2011 05:02:42 -0700 X-Env-Sender: royger@gmail.com X-Msg-Ref: server-7.tower-21.messagelabs.com!1316692922!55823575!4 X-Originating-IP: [74.125.82.171] X-StarScan-Version: 6.4.1; banners=-,-,- X-VirusChecked: Checked Received: (qmail 29335 invoked from network); 22 Sep 2011 12:02:07 -0000 Received: from mail-wy0-f171.google.com (HELO mail-wy0-f171.google.com) (74.125.82.171) by server-7.tower-21.messagelabs.com with RC4-SHA encrypted SMTP; 22 Sep 2011 12:02:07 -0000 Received: by mail-wy0-f171.google.com with SMTP id 13so1456438wyh.30 for <xen-devel@lists.xensource.com>; Thu, 22 Sep 2011 05:02:38 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=sender:content-type:mime-version:content-transfer-encoding:subject :x-mercurial-node:message-id:in-reply-to:references:user-agent:date :from:to; bh=W8nLcmjvjzMMU9XJjG2V7OqqfcgHWwzGLvBKzhqyCYE=; b=PwxwDUkzEjT0tN0pKQQea/PKuCbhwewa6ujP8glSMaHxI9kvXV6Mpf621qVAwrcVVq Zm8tF7N7j+VFht9VQgx0D71QqxXgoCsEtP0e/CtYUWrCDoMLCQbXZyCXxtYofmI0B7xM A00OBVcq8pGSdBAXb62jDPzs9SVQLGQ4pzXmI= Received: by 10.216.230.130 with SMTP id j2mr1994654weq.26.1316692958262; Thu, 22 Sep 2011 05:02:38 -0700 (PDT) Received: from [127.0.0.1] (monk.upc.es. [147.83.39.235]) by mx.google.com with ESMTPS id es10sm5404859wbb.4.2011.09.22.05.02.36 (version=TLSv1/SSLv3 cipher=OTHER); Thu, 22 Sep 2011 05:02:37 -0700 (PDT) Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Mercurial-Node: d5cca9e3b5d3576073a543d0305e8f0d9dc9beeb Message-Id: <d5cca9e3b5d3576073a5.1316692871@loki> In-Reply-To: <patchbomb.1316692867@loki> References: <patchbomb.1316692867@loki> User-Agent: Mercurial-patchbomb/1.8.4 Date: Thu, 22 Sep 2011 14:01:11 +0200 From: Roger Pau Monne <roger.pau@entel.upc.edu> To: xen-devel@lists.xensource.com Subject: [Xen-devel] [PATCH 4 of 6] libxl: fix for libxl not waiting for devices to disconnect X-BeenThere: xen-devel@lists.xensource.com X-Mailman-Version: 2.1.5 Precedence: list List-Id: Xen developer discussion <xen-devel.lists.xensource.com> List-Unsubscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe> List-Post: <mailto:xen-devel@lists.xensource.com> List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help> List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=subscribe> Sender: xen-devel-bounces@lists.xensource.com Errors-To: xen-devel-bounces@lists.xensource.com # HG changeset patch # User Roger Pau Monne <roger.pau@entel.upc.edu> # Date 1316692495 -7200 # Node ID d5cca9e3b5d3576073a543d0305e8f0d9dc9beeb # Parent 2d77cbdc816bc943e9e69ecca34ae7157079045a libxl: fix for libxl not waiting for devices to disconnect libxl was ignoring the timeout and the number of devices to wait before destroying them. Signed-off-by: Roger Pau Monne <roger.pau@entel.upc.edu> diff -r 2d77cbdc816b -r d5cca9e3b5d3 tools/libxl/libxl_device.c --- a/tools/libxl/libxl_device.c Thu Sep 22 13:54:49 2011 +0200 +++ b/tools/libxl/libxl_device.c Thu Sep 22 13:54:55 2011 +0200 @@ -422,6 +422,9 @@ static int wait_for_dev_destroy(libxl__g } free(l1); } + } else { + /* timeout reached */ + rc = 0; } return rc; } @@ -482,7 +485,7 @@ int libxl__devices_destroy(libxl__gc *gc tv.tv_usec = 0; while (n_watches > 0) { if (wait_for_dev_destroy(gc, &tv)) { - break; + continue; } else { n_watches--; } _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel From xen-devel-bounces@lists.xensource.com Thu Sep 22 05:12:14 2011 Return-path: <xen-devel-bounces@lists.xensource.com> Envelope-to: www-data@lists.xensource.com Delivery-date: Thu, 22 Sep 2011 05:12:14 -0700 Received: from localhost ([127.0.0.1] helo=lists.colo.xensource.com) by lists.xensource.com with esmtp (Exim 4.43) id 1R6i8T-0007o5-Tp; Thu, 22 Sep 2011 05:12:13 -0700 Received: from mail182.messagelabs.com ([85.158.139.83]) by lists.xensource.com with esmtp (Exim 4.43) id 1R6hzH-0005YV-8v for xen-devel@lists.xensource.com; Thu, 22 Sep 2011 05:02:43 -0700 X-Env-Sender: royger@gmail.com X-Msg-Ref: server-4.tower-182.messagelabs.com!1316692950!19329112!2 X-Originating-IP: [74.125.82.43] X-StarScan-Version: 6.4.1; banners=-,-,- X-VirusChecked: Checked Received: (qmail 1241 invoked from network); 22 Sep 2011 12:02:40 -0000 Received: from mail-ww0-f43.google.com (HELO mail-ww0-f43.google.com) (74.125.82.43) by server-4.tower-182.messagelabs.com with RC4-SHA encrypted SMTP; 22 Sep 2011 12:02:40 -0000 Received: by mail-ww0-f43.google.com with SMTP id 27so1751239wwf.24 for <xen-devel@lists.xensource.com>; Thu, 22 Sep 2011 05:02:40 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=sender:content-type:mime-version:content-transfer-encoding:subject :x-mercurial-node:message-id:in-reply-to:references:user-agent:date :from:to; bh=tg0cwG+u6FHOfMhskWMz5C81OJI5wjlJ2BtChWI3Ydg=; b=eXPPvwJxWsTd+yM2dt2g2F+Xq+oHK/Kt250vR2J0xOj8gDY/fyyDg0CsvejfxTJhaU ffgqmywXtCBZxocZvAUtId6PKxQ6Dfulof7eS3InAyMm5xiv7yjuaxjcBn7Jac3WMCFB 1Ap6lJkeUaTfGncvdbEEW9t3eJ++KpOkP+XRg= Received: by 10.227.127.145 with SMTP id g17mr518292wbs.38.1316692960157; Thu, 22 Sep 2011 05:02:40 -0700 (PDT) Received: from [127.0.0.1] (monk.upc.es. [147.83.39.235]) by mx.google.com with ESMTPS id es10sm5404859wbb.4.2011.09.22.05.02.38 (version=TLSv1/SSLv3 cipher=OTHER); Thu, 22 Sep 2011 05:02:39 -0700 (PDT) Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Mercurial-Node: a5c9a6083bef9d4789a0194389db234740cd6005 Message-Id: <a5c9a6083bef9d4789a0.1316692872@loki> In-Reply-To: <patchbomb.1316692867@loki> References: <patchbomb.1316692867@loki> User-Agent: Mercurial-patchbomb/1.8.4 Date: Thu, 22 Sep 2011 14:01:12 +0200 From: Roger Pau Monne <roger.pau@entel.upc.edu> To: xen-devel@lists.xensource.com Subject: [Xen-devel] [PATCH 5 of 6] libxl: add support for NetBSD to use disk images as a PHY backend X-BeenThere: xen-devel@lists.xensource.com X-Mailman-Version: 2.1.5 Precedence: list List-Id: Xen developer discussion <xen-devel.lists.xensource.com> List-Unsubscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe> List-Post: <mailto:xen-devel@lists.xensource.com> List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help> List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=subscribe> Sender: xen-devel-bounces@lists.xensource.com Errors-To: xen-devel-bounces@lists.xensource.com # HG changeset patch # User Roger Pau Monne <roger.pau@entel.upc.edu> # Date 1316692503 -7200 # Node ID a5c9a6083bef9d4789a0194389db234740cd6005 # Parent d5cca9e3b5d3576073a543d0305e8f0d9dc9beeb libxl: add support for NetBSD to use disk images as a PHY backend Add a NetBSD special case to use images as PHY disk devices, which can be attached using the regular block hotplug script. Signed-off-by: Roger Pau Monne <roger.pau@entel.upc.edu> diff -r d5cca9e3b5d3 -r a5c9a6083bef tools/libxl/libxl_device.c --- a/tools/libxl/libxl_device.c Thu Sep 22 13:54:55 2011 +0200 +++ b/tools/libxl/libxl_device.c Thu Sep 22 13:55:03 2011 +0200 @@ -136,15 +136,20 @@ static int disk_try_backend(disk_try_bac a->disk->format == LIBXL_DISK_FORMAT_EMPTY)) { goto bad_format; } - if (a->disk->format != LIBXL_DISK_FORMAT_EMPTY && - !S_ISBLK(a->stab.st_mode)) { - LIBXL__LOG(ctx, LIBXL__LOG_DEBUG, "Disk vdev=%s, backend phy" - " unsuitable as phys path not a block device", - a->disk->vdev); - return 0; - } - - return backend; + if (S_ISBLK(a->stab.st_mode)) + return backend; +#ifdef HAVE_PHY_BACKEND_FILE_SUPPORT + if (S_ISREG(a->stab.st_mode)) + return backend; + LIBXL__LOG(ctx, LIBXL__LOG_DEBUG, "Disk vdev=%s, backend phy" + " unsuitable as phys path not a block device or" + " raw image", a->disk->vdev); +#else + LIBXL__LOG(ctx, LIBXL__LOG_DEBUG, "Disk vdev=%s, backend phy" + " unsuitable as phys path not a block device", + a->disk->vdev); +#endif + return 0; case LIBXL_DISK_BACKEND_TAP: if (!libxl__blktap_enabled(a->gc)) { diff -r d5cca9e3b5d3 -r a5c9a6083bef tools/libxl/libxl_osdeps.h --- a/tools/libxl/libxl_osdeps.h Thu Sep 22 13:54:55 2011 +0200 +++ b/tools/libxl/libxl_osdeps.h Thu Sep 22 13:55:03 2011 +0200 @@ -25,6 +25,7 @@ #if defined(__NetBSD__) || defined(__OpenBSD__) #include <util.h> +#define HAVE_PHY_BACKEND_FILE_SUPPORT #elif defined(__linux__) #include <pty.h> #elif defined(__sun__) _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel From xen-devel-bounces@lists.xensource.com Thu Sep 22 05:13:05 2011 Return-path: <xen-devel-bounces@lists.xensource.com> Envelope-to: www-data@lists.xensource.com Delivery-date: Thu, 22 Sep 2011 05:13:05 -0700 Received: from localhost ([127.0.0.1] helo=lists.colo.xensource.com) by lists.xensource.com with esmtp (Exim 4.43) id 1R6i9J-0008At-0R; Thu, 22 Sep 2011 05:13:05 -0700 Received: from mail182.messagelabs.com ([85.158.139.83]) by lists.xensource.com with esmtp (Exim 4.43) id 1R6hzJ-0005Ym-0O for xen-devel@lists.xensource.com; Thu, 22 Sep 2011 05:02:46 -0700 X-Env-Sender: royger@gmail.com X-Msg-Ref: server-4.tower-182.messagelabs.com!1316692950!19329112!3 X-Originating-IP: [74.125.82.43] X-StarScan-Version: 6.4.1; banners=-,-,- X-VirusChecked: Checked Received: (qmail 1417 invoked from network); 22 Sep 2011 12:02:42 -0000 Received: from mail-ww0-f43.google.com (HELO mail-ww0-f43.google.com) (74.125.82.43) by server-4.tower-182.messagelabs.com with RC4-SHA encrypted SMTP; 22 Sep 2011 12:02:42 -0000 Received: by mail-ww0-f43.google.com with SMTP id 27so1751239wwf.24 for <xen-devel@lists.xensource.com>; Thu, 22 Sep 2011 05:02:42 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=sender:content-type:mime-version:content-transfer-encoding:subject :x-mercurial-node:message-id:in-reply-to:references:user-agent:date :from:to; bh=WpQaHuwAh7ObUKQTL+CEP3TmhldSSe1crrT/A4tQhRA=; b=WCmDoEOsDrqwZi3HasBAaTbWHqWwRkfUfiDaIDGQqcwhD2sGidDTzrpRLjvyg/+Oaz Y88j8RTUbtPravb107RAlBVDfPBjKAzeOD7m4oV3DE7UKxfgiT2oKZWreeMVogO/2+MO jKr6CPZxHazeHV8MV2Vb3qbt7F3mS+FsNvVOo= Received: by 10.227.27.90 with SMTP id h26mr2123890wbc.102.1316692961997; Thu, 22 Sep 2011 05:02:41 -0700 (PDT) Received: from [127.0.0.1] (monk.upc.es. [147.83.39.235]) by mx.google.com with ESMTPS id es10sm5404859wbb.4.2011.09.22.05.02.40 (version=TLSv1/SSLv3 cipher=OTHER); Thu, 22 Sep 2011 05:02:41 -0700 (PDT) Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Mercurial-Node: 9e9c68768676b0e1c9c76599e00d0922c6184602 Message-Id: <9e9c68768676b0e1c9c7.1316692873@loki> In-Reply-To: <patchbomb.1316692867@loki> References: <patchbomb.1316692867@loki> User-Agent: Mercurial-patchbomb/1.8.4 Date: Thu, 22 Sep 2011 14:01:13 +0200 From: Roger Pau Monne <roger.pau@entel.upc.edu> To: xen-devel@lists.xensource.com Subject: [Xen-devel] [PATCH 6 of 6] libxl: use hotplug-status to synchronize the destruction of block devices X-BeenThere: xen-devel@lists.xensource.com X-Mailman-Version: 2.1.5 Precedence: list List-Id: Xen developer discussion <xen-devel.lists.xensource.com> List-Unsubscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe> List-Post: <mailto:xen-devel@lists.xensource.com> List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help> List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=subscribe> Sender: xen-devel-bounces@lists.xensource.com Errors-To: xen-devel-bounces@lists.xensource.com # HG changeset patch # User Roger Pau Monne <roger.pau@entel.upc.edu> # Date 1316692512 -7200 # Node ID 9e9c68768676b0e1c9c76599e00d0922c6184602 # Parent a5c9a6083bef9d4789a0194389db234740cd6005 libxl: use hotplug-status to synchronize the destruction of block devices Use hotplug-status to synchronize the destruction of vbd devices instead of state, which did not reflect when the hotplug script had been executed. Signed-off-by: Roger Pau Monne <roger.pau@entel.upc.edu> diff -r a5c9a6083bef -r 9e9c68768676 tools/libxl/libxl_device.c --- a/tools/libxl/libxl_device.c Thu Sep 22 13:55:03 2011 +0200 +++ b/tools/libxl/libxl_device.c Thu Sep 22 13:55:12 2011 +0200 @@ -371,14 +371,26 @@ int libxl__device_destroy(libxl__gc *gc, libxl_ctx *ctx = libxl__gc_owner(gc); xs_transaction_t t; char *state_path = libxl__sprintf(gc, "%s/state", be_path); + char *hotplug_path = libxl__sprintf(gc, "%s/hotplug-status", be_path); char *state = libxl__xs_read(gc, XBT_NULL, state_path); + char *hotplug = libxl__xs_read(gc, XBT_NULL, hotplug_path); int rc = 0; if (!state) goto out; - if (atoi(state) != 4) { - xs_rm(ctx->xsh, XBT_NULL, be_path); - goto out; + + if (!strstr(be_path, string_of_kinds[DEVICE_VBD])) { + if (atoi(state) != 4) { + xs_rm(ctx->xsh, XBT_NULL, be_path); + goto out; + } + } else { + if (!hotplug) + goto out; + if (!strcmp(hotplug, "disconnected")) { + xs_rm(ctx->xsh, XBT_NULL, be_path); + goto out; + } } retry_transaction: @@ -394,8 +406,13 @@ retry_transaction: } } if (!force) { - xs_watch(ctx->xsh, state_path, be_path); - rc = 1; + if (strstr(be_path, string_of_kinds[DEVICE_VBD])) { + xs_watch(ctx->xsh, hotplug_path, be_path); + rc = 1; + } else { + xs_watch(ctx->xsh, state_path, be_path); + rc = 1; + } } else { xs_rm(ctx->xsh, XBT_NULL, be_path); } @@ -410,6 +427,7 @@ static int wait_for_dev_destroy(libxl__g unsigned int n; fd_set rfds; char **l1 = NULL; + char *state, *hotplug; rc = 1; nfds = xs_fileno(ctx->xsh) + 1; @@ -418,12 +436,26 @@ static int wait_for_dev_destroy(libxl__g if (select(nfds, &rfds, NULL, NULL, tv) > 0) { l1 = xs_read_watch(ctx->xsh, &n); if (l1 != NULL) { - char *state = libxl__xs_read(gc, XBT_NULL, l1[XS_WATCH_PATH]); - if (!state || atoi(state) == 6) { - xs_unwatch(ctx->xsh, l1[0], l1[1]); - xs_rm(ctx->xsh, XBT_NULL, l1[XS_WATCH_TOKEN]); - LIBXL__LOG(ctx, LIBXL__LOG_DEBUG, "Destroyed device backend at %s", l1[XS_WATCH_TOKEN]); - rc = 0; + if (strstr(l1[XS_WATCH_PATH], "hotplug-status")) { + hotplug = libxl__xs_read(gc, XBT_NULL, l1[XS_WATCH_PATH]); + if (!hotplug || !strcmp(hotplug, "disconnected")) { + xs_unwatch(ctx->xsh, l1[0], l1[1]); + xs_rm(ctx->xsh, XBT_NULL, l1[XS_WATCH_TOKEN]); + LIBXL__LOG(ctx, LIBXL__LOG_DEBUG, + "Destroyed device backend at %s hotplug-status: %s", + l1[XS_WATCH_TOKEN], hotplug); + rc = 0; + } + } else { + state = libxl__xs_read(gc, XBT_NULL, l1[XS_WATCH_PATH]); + if (!state || atoi(state) == 6) { + xs_unwatch(ctx->xsh, l1[0], l1[1]); + xs_rm(ctx->xsh, XBT_NULL, l1[XS_WATCH_TOKEN]); + LIBXL__LOG(ctx, LIBXL__LOG_DEBUG, + "Destroyed device backend at %s", + l1[XS_WATCH_TOKEN]); + rc = 0; + } } free(l1); } _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel From xen-devel-bounces@lists.xensource.com Thu Sep 22 05:14:03 2011 Return-path: <xen-devel-bounces@lists.xensource.com> Envelope-to: www-data@lists.xensource.com Delivery-date: Thu, 22 Sep 2011 05:14:03 -0700 Received: from localhost ([127.0.0.1] helo=lists.colo.xensource.com) by lists.xensource.com with esmtp (Exim 4.43) id 1R6iAF-0000BQ-5y; Thu, 22 Sep 2011 05:14:03 -0700 Received: from mail21.messagelabs.com ([85.158.143.35]) by lists.xensource.com with esmtp (Exim 4.43) id 1R6i3P-0006Dt-De for xen-devel@lists.xensource.com; Thu, 22 Sep 2011 05:07:02 -0700 X-Env-Sender: JBeulich@suse.com X-Msg-Ref: server-13.tower-21.messagelabs.com!1316693210!49900789!1 X-Originating-IP: [130.57.49.28] X-StarScan-Version: 6.4.1; banners=-,-,- X-VirusChecked: Checked Received: (qmail 17464 invoked from network); 22 Sep 2011 12:06:50 -0000 Received: from nat28.tlf.novell.com (HELO nat28.tlf.novell.com) (130.57.49.28) by server-13.tower-21.messagelabs.com with DHE-RSA-AES256-SHA encrypted SMTP; 22 Sep 2011 12:06:50 -0000 Received: from EMEA1-MTA by nat28.tlf.novell.com with Novell_GroupWise; Thu, 22 Sep 2011 13:06:55 +0100 Message-Id: <4E7B41190200007800057508@nat28.tlf.novell.com> X-Mailer: Novell GroupWise Internet Agent 8.0.1 Date: Thu, 22 Sep 2011 13:07:21 +0100 From: "Jan Beulich" <JBeulich@suse.com> To: "George Dunlap" <George.Dunlap@eu.citrix.com> Subject: Re: [Xen-devel] Xen 4 TSC problems References: <AANLkTik3Ng6TpQANfPNJ2M=86WYLHVt7_MuBuVfJ1CG_@mail.gmail.com> <CAFLBxZZiGxef5CkH9r+VZeB4h7LPA0nJddumwDRovZaL4zOuvA@mail.gmail.com> <5224b434-5371-404d-8fed-2665e73dacce@default> <CAFLBxZZ3nP5EbtL=Ne-W4DcSWtKGh1XDOs-EhVua7ujmi9Y2Jw@mail.gmail.com> In-Reply-To: <CAFLBxZZ3nP5EbtL=Ne-W4DcSWtKGh1XDOs-EhVua7ujmi9Y2Jw@mail.gmail.com> Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: quoted-printable Content-Disposition: inline Cc: jeremy@goop.org, xen-devel@lists.xensource.com, Keir Fraser <keir@xen.org>, Konrad Wilk <konrad.wilk@oracle.com>, Dan Magenheimer <dan.magenheimer@oracle.com>, Philippe Simonet <philippe.simonet@bluewin.ch> X-BeenThere: xen-devel@lists.xensource.com X-Mailman-Version: 2.1.5 Precedence: list List-Id: Xen developer discussion <xen-devel.lists.xensource.com> List-Unsubscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe> List-Post: <mailto:xen-devel@lists.xensource.com> List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help> List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=subscribe> Sender: xen-devel-bounces@lists.xensource.com Errors-To: xen-devel-bounces@lists.xensource.com >>> On 19.09.11 at 12:39, George Dunlap <George.Dunlap@eu.citrix.com> = wrote: > The comment at the top of init_xen_time() is correct now, but from the > time it was first written through 4.1 is was just plain wrong -- it > said init_xen_time() happened after all cpus were up, which has never > been true. Not really - CPUs got booted by that time originally (pre-4.0, which is what the old comment said), but not onlined. Prior to the use of smp_call_function() for the TSC reliability check I assume only CPU feature flags got looked at, which was available at that point prior to Keir's re-work of the SMP boot process. Jan _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel From xen-devel-bounces@lists.xensource.com Thu Sep 22 05:16:07 2011 Return-path: <xen-devel-bounces@lists.xensource.com> Envelope-to: www-data@lists.xensource.com Delivery-date: Thu, 22 Sep 2011 05:16:07 -0700 Received: from localhost ([127.0.0.1] helo=lists.colo.xensource.com) by lists.xensource.com with esmtp (Exim 4.43) id 1R6iCF-0000a7-HF; Thu, 22 Sep 2011 05:16:07 -0700 Received: from mail182.messagelabs.com ([85.158.139.83]) by lists.xensource.com with esmtp (Exim 4.43) id 1R6iBa-0000Nj-VK for xen-devel@lists.xensource.com; Thu, 22 Sep 2011 05:15:28 -0700 X-Env-Sender: javier.manzano@edu.uah.es X-Msg-Ref: server-10.tower-182.messagelabs.com!1316693722!19310390!1 X-Originating-IP: [216.139.236.26] X-StarScan-Version: 6.4.1; banners=-,-,- X-VirusChecked: Checked Received: (qmail 20252 invoked from network); 22 Sep 2011 12:15:23 -0000 Received: from sam.nabble.com (HELO sam.nabble.com) (216.139.236.26) by server-10.tower-182.messagelabs.com with AES256-SHA encrypted SMTP; 22 Sep 2011 12:15:23 -0000 Received: from [192.168.236.26] (helo=sam.nabble.com) by sam.nabble.com with esmtp (Exim 4.72) (envelope-from <javier.manzano@edu.uah.es>) id 1R6iBW-0005Lp-1A for xen-devel@lists.xensource.com; Thu, 22 Sep 2011 05:15:22 -0700 Date: Thu, 22 Sep 2011 05:15:22 -0700 (PDT) From: JavMV <javier.manzano@edu.uah.es> To: xen-devel@lists.xensource.com Message-ID: <1316693722029-4829929.post@n5.nabble.com> In-Reply-To: <1316618006.67296.YahooMailNeo@web29818.mail.ird.yahoo.com> References: <1315405372.87224.YahooMailNeo@web29801.mail.ird.yahoo.com> <1315405921936-4778727.post@n5.nabble.com> <1316612652132-4826391.post@n5.nabble.com> <1316613404292-4826432.post@n5.nabble.com> <1316614084705-4826479.post@n5.nabble.com> <1316615526442-4826582.post@n5.nabble.com> <1316616001843-4826614.post@n5.nabble.com> <1316616472579-4826635.post@n5.nabble.com> <1316616757871-4826655.post@n5.nabble.com> <1316618006.67296.YahooMailNeo@web29818.mail.ird.yahoo.com> Subject: Re: Re : Re : Re : Re : [Xen-devel] Re: Patches for VGA-Passthrough XEN 4.2 unstable MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-BeenThere: xen-devel@lists.xensource.com X-Mailman-Version: 2.1.5 Precedence: list List-Id: Xen developer discussion <xen-devel.lists.xensource.com> List-Unsubscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe> List-Post: <mailto:xen-devel@lists.xensource.com> List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help> List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=subscribe> Sender: xen-devel-bounces@lists.xensource.com Errors-To: xen-devel-bounces@lists.xensource.com Hi again, I didn't answer you before because I'm having troubles to enable IO virtualisation on XEN, I don't know why because it works for me on the past, maybe I should try a full and clean installation from the start instead of keep using my actual installation which can run xen but starting it manually (due to errors)... Well I have enabled the next BIOS options: XD Technology <Enable> VT Technology <Enable> Intel(R) VT for Directed I/O (VT-d) <Enable> So I think everything is OK but " # xm dmesg " show these lines: (XEN) [VT-D]dmar.c:456: Non-existent device (0:2.1) is reported in this DRHD\047s scope! (XEN) [VT-D]dmar.c:479: The DRHD is invalid due to there are devices under its scope are not PCI discoverable! Pls try option iommu=force or iommu=workaround_bios_bug if you really want VT-d (XEN) Failed to parse ACPI DMAR. * Disabling VT-d.* (XEN) Table is not found! (XEN) Using ACPI (MADT) for SMP configuration information ... * (XEN) I/O virtualisation disabled* ... (XEN) HVM: ASIDs disabled. *(XEN) HVM: VMX enabled* ... I have tryed adding the options iommu=1, iommu=force or iommu=workaround_bios_bug in grub menu entry: multiboot /boot/xen-4.2-unstable.gz placeholder module /boot/vmlinuz-2.6.32.45 placeholder root=UUID=..... ro *iommu=force* module /boot/intrd.img-2.6.32.45 I don't know what is wrong now, this is frustrating (I/O) VT-d works for the same computer on the past, could this problem be caused by the mixed installations? I will try to reinstall everything after format the computer but I will wait if you know how to fix this issue without reinstall everything again. Javier ----- JavMV -- View this message in context: http://xen.1045712.n5.nabble.com/Patches-for-VGA-Passthrough-XEN-4-2-unstable-tp4406265p4829929.html Sent from the Xen - Dev mailing list archive at Nabble.com. _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel From xen-devel-bounces@lists.xensource.com Thu Sep 22 05:30:23 2011 Return-path: <xen-devel-bounces@lists.xensource.com> Envelope-to: www-data@lists.xensource.com Delivery-date: Thu, 22 Sep 2011 05:30:23 -0700 Received: from localhost ([127.0.0.1] helo=lists.colo.xensource.com) by lists.xensource.com with esmtp (Exim 4.43) id 1R6iQ2-00019q-Q2; Thu, 22 Sep 2011 05:30:22 -0700 Received: from mail182.messagelabs.com ([85.158.139.83]) by lists.xensource.com with esmtp (Exim 4.43) id 1R6iPR-0000xU-QF for xen-devel@lists.xensource.com; Thu, 22 Sep 2011 05:29:46 -0700 X-Env-Sender: david.vrabel@citrix.com X-Msg-Ref: server-10.tower-182.messagelabs.com!1316694581!19312438!1 X-Originating-IP: [66.165.176.63] X-StarScan-Version: 6.4.1; banners=-,-,- X-VirusChecked: Checked Received: (qmail 29273 invoked from network); 22 Sep 2011 12:29:42 -0000 Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63) by server-10.tower-182.messagelabs.com with RC4-SHA encrypted SMTP; 22 Sep 2011 12:29:42 -0000 X-IronPort-AV: E=Sophos;i="4.68,423,1312171200"; d="scan'208";a="164278472" Received: from ftlpmailmx02.citrite.net ([10.13.107.66]) by FTLPIPO02.CITRIX.COM with ESMTP/TLS/RC4-MD5; 22 Sep 2011 08:29:40 -0400 Received: from [10.80.2.76] (10.80.2.76) by FTLPMAILMX02.citrite.net (10.13.107.66) with Microsoft SMTP Server id 8.3.137.0; Thu, 22 Sep 2011 08:29:40 -0400 Message-ID: <4E7B2ADA.7000605@citrix.com> Date: Thu, 22 Sep 2011 13:32:26 +0100 From: David Vrabel <david.vrabel@citrix.com> User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.1.16) Gecko/20110818 Icedove/3.0.11 MIME-Version: 1.0 To: Dan Magenheimer <dan.magenheimer@oracle.com> Subject: Re: [Xen-devel] xen: memory initialization/balloon fixes (#3) References: <1316089768-22461-1-git-send-email-david.vrabel@citrix.com> <63997331-e53b-48e5-bf7c-87141aae49d6@default> In-Reply-To: <63997331-e53b-48e5-bf7c-87141aae49d6@default> Content-Type: text/plain; charset="ISO-8859-1" Content-Transfer-Encoding: 7bit Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>, Wilk <konrad.wilk@oracle.com>, Konrad X-BeenThere: xen-devel@lists.xensource.com X-Mailman-Version: 2.1.5 Precedence: list List-Id: Xen developer discussion <xen-devel.lists.xensource.com> List-Unsubscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe> List-Post: <mailto:xen-devel@lists.xensource.com> List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help> List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=subscribe> Sender: xen-devel-bounces@lists.xensource.com Errors-To: xen-devel-bounces@lists.xensource.com On 20/09/11 17:57, Dan Magenheimer wrote: > > Thanks for your patches! I am looking at a memory capacity/ballooning > weirdness that I hoped your patchset might fix, but so far it has not. > I'm wondering if there was an earlier fix that you are building upon > and that I am missing. > > My problem occurs in a PV domU with an upstream-variant kernel based > on 3.0.5. The problem is that the total amount of memory as seen > from inside the guest is always substantially less than the amount > of memory seen from outside the guest. The difference seems to > be fixed within a given boot, but assigning a different vm.cfg mem= > changes the amount. (For example, the difference D is about 18MB on > a mem=128 boot and about 36MB on a mem=1024 boot.) I don't see the problem? The MemTotal value /proc/meminfo doesn't include some pages reserved by the kernel which is why it's less than the maximum reservation of the domain. > Part B of the problem (and the one most important to me) is that > setting /sys/devices/system/xen_memory/xen_memory0/target_kb > to X results in a MemTotal inside the domU (as observed by > "head -1 /proc/meminfo") of X-D. This can be particularly painful > when X is aggressively small as X-D may result in OOMs. > To use kernel function/variable names (and I observed this with > some debugging code), when balloon_set_new_target(X) is called > totalram_pages gets driven to X-D. Again, this looks like the correct behavior to me. David _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel From xen-devel-bounces@lists.xensource.com Thu Sep 22 05:46:43 2011 Return-path: <xen-devel-bounces@lists.xensource.com> Envelope-to: www-data@lists.xensource.com Delivery-date: Thu, 22 Sep 2011 05:46:43 -0700 Received: from localhost ([127.0.0.1] helo=lists.colo.xensource.com) by lists.xensource.com with esmtp (Exim 4.43) id 1R6ifr-0001rp-8G; Thu, 22 Sep 2011 05:46:43 -0700 Received: from mail216.messagelabs.com ([85.158.143.99]) by lists.xensource.com with esmtp (Exim 4.43) id 1R6if1-0001fK-DO for xen-devel@lists.xensource.com; Thu, 22 Sep 2011 05:45:51 -0700 X-Env-Sender: komkon555@freenet.de X-Msg-Ref: server-4.tower-216.messagelabs.com!1316695547!19198116!1 X-Originating-IP: [216.139.236.26] X-StarScan-Version: 6.4.1; banners=-,-,- X-VirusChecked: Checked Received: (qmail 14976 invoked from network); 22 Sep 2011 12:45:48 -0000 Received: from sam.nabble.com (HELO sam.nabble.com) (216.139.236.26) by server-4.tower-216.messagelabs.com with AES256-SHA encrypted SMTP; 22 Sep 2011 12:45:48 -0000 Received: from [192.168.236.26] (helo=sam.nabble.com) by sam.nabble.com with esmtp (Exim 4.72) (envelope-from <komkon555@freenet.de>) id 1R6iew-0007xl-Aq for xen-devel@lists.xensource.com; Thu, 22 Sep 2011 05:45:46 -0700 Date: Thu, 22 Sep 2011 05:45:46 -0700 (PDT) From: komkon555 <komkon555@freenet.de> To: xen-devel@lists.xensource.com Message-ID: <1316695546329-4830015.post@n5.nabble.com> In-Reply-To: <1316693722029-4829929.post@n5.nabble.com> References: <1315405921936-4778727.post@n5.nabble.com> <1316612652132-4826391.post@n5.nabble.com> <1316613404292-4826432.post@n5.nabble.com> <1316614084705-4826479.post@n5.nabble.com> <1316615526442-4826582.post@n5.nabble.com> <1316616001843-4826614.post@n5.nabble.com> <1316616472579-4826635.post@n5.nabble.com> <1316616757871-4826655.post@n5.nabble.com> <1316618006.67296.YahooMailNeo@web29818.mail.ird.yahoo.com> <1316693722029-4829929.post@n5.nabble.com> Subject: Re: Re : Re : Re : Re : [Xen-devel] Re: Patches for VGA-Passthrough XEN 4.2 unstable MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-BeenThere: xen-devel@lists.xensource.com X-Mailman-Version: 2.1.5 Precedence: list List-Id: Xen developer discussion <xen-devel.lists.xensource.com> List-Unsubscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe> List-Post: <mailto:xen-devel@lists.xensource.com> List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help> List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=subscribe> Sender: xen-devel-bounces@lists.xensource.com Errors-To: xen-devel-bounces@lists.xensource.com JavMV, what about your BIOS setup? Is vt-d (iommu) enabled in BIOS? Best regards Kom. -- View this message in context: http://xen.1045712.n5.nabble.com/Patches-for-VGA-Passthrough-XEN-4-2-unstable-tp4406265p4830015.html Sent from the Xen - Dev mailing list archive at Nabble.com. _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel From xen-devel-bounces@lists.xensource.com Thu Sep 22 05:53:46 2011 Return-path: <xen-devel-bounces@lists.xensource.com> Envelope-to: www-data@lists.xensource.com Delivery-date: Thu, 22 Sep 2011 05:53:46 -0700 Received: from localhost ([127.0.0.1] helo=lists.colo.xensource.com) by lists.xensource.com with esmtp (Exim 4.43) id 1R6img-0002T1-FO; Thu, 22 Sep 2011 05:53:46 -0700 Received: from mail174.messagelabs.com ([85.158.138.51]) by lists.xensource.com with esmtp (Exim 4.43) id 1R6imB-0002Gk-R9 for xen-devel@lists.xensource.com; Thu, 22 Sep 2011 05:53:17 -0700 X-Env-Sender: konrad@oracle.com X-Msg-Ref: server-6.tower-174.messagelabs.com!1316695991!30223181!1 X-Originating-IP: [148.87.113.117] X-StarScan-Version: 6.4.1; banners=-,-,- X-VirusChecked: Checked Received: (qmail 11773 invoked from network); 22 Sep 2011 12:53:12 -0000 Received: from rcsinet15.oracle.com (HELO rcsinet15.oracle.com) (148.87.113.117) by server-6.tower-174.messagelabs.com with DHE-RSA-AES256-SHA encrypted SMTP; 22 Sep 2011 12:53:12 -0000 Received: from rtcsinet21.oracle.com (rtcsinet21.oracle.com [66.248.204.29]) by rcsinet15.oracle.com (Switch-3.4.4/Switch-3.4.4) with ESMTP id p8MCpiRB029492 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Thu, 22 Sep 2011 12:51:46 GMT Received: from acsmt357.oracle.com (acsmt357.oracle.com [141.146.40.157]) by rtcsinet21.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id p8MCpgxj006297 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 22 Sep 2011 12:51:43 GMT Received: from abhmt119.oracle.com (abhmt119.oracle.com [141.146.116.71]) by acsmt357.oracle.com (8.12.11.20060308/8.12.11) with ESMTP id p8MCpavJ019308; Thu, 22 Sep 2011 07:51:36 -0500 Received: from oracle.com (/209.6.55.207) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Thu, 22 Sep 2011 05:51:36 -0700 Received: by oracle.com (Postfix, from userid 1000) id 8B9BE1364; Thu, 22 Sep 2011 08:51:42 -0400 (EDT) Date: Thu, 22 Sep 2011 08:51:42 -0400 From: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com> To: "Cihula, Joseph" <joseph.cihula@intel.com>, liang tang <liang.tang@oracle.com> Subject: Re: [Xen-devel] RE: [PATCH 5/7] xen/acpi: Domain0 acpi parser related platform hypercall Message-ID: <20110922125142.GA10761@phenom.oracle.com> References: <1314815484-4668-1-git-send-email-konrad.wilk@oracle.com> <1314815484-4668-6-git-send-email-konrad.wilk@oracle.com> <9F57BF860713DF4BA3EFA4F8C6DFEDAC16F3F665@ORSMSX101.amr.corp.intel.com> <4E67A9E7.2020802@goop.org> <9F57BF860713DF4BA3EFA4F8C6DFEDAC16F40F0B@ORSMSX101.amr.corp.intel.com> <20110907190659.GH7074@dumpdata.com> <20110908133847.GC27132@dumpdata.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20110908133847.GC27132@dumpdata.com> User-Agent: Mutt/1.5.21 (2010-09-15) X-Source-IP: rtcsinet21.oracle.com [66.248.204.29] X-CT-RefId: str=0001.0A090209.4E7B2F64.013B,ss=1,re=0.000,fgs=0 Cc: "Brown, Len" <len.brown@intel.com>, "Tian, Kevin" <kevin.tian@intel.com>, "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>, "keir@xen.org" <keir@xen.org>, "x86@kernel.org" <x86@kernel.org>, Jeremy Fitzhardinge <jeremy@goop.org>, "linux-acpi@vger.kernel.org" <linux-acpi@vger.kernel.org>, "tboot-devel@lists.sourceforge.net" <tboot-devel@lists.sourceforge.net>, Fitzhardinge <jeremy.fitzhardinge@citrix.com>, "liang.tang@oracle.com" <liang.tang@oracle.com>, "Yu, Ke" <ke.yu@intel.com>, "hpa@zytor.com" <hpa@zytor.com>, "tglx@linutronix.de" <tglx@linutronix.de>, "linux-pm@lists.linux-foundation.org" <linux-pm@lists.linux-foundation.org>, "Wei, Gang" <gang.wei@intel.com> X-BeenThere: xen-devel@lists.xensource.com X-Mailman-Version: 2.1.5 Precedence: list List-Id: Xen developer discussion <xen-devel.lists.xensource.com> List-Unsubscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe> List-Post: <mailto:xen-devel@lists.xensource.com> List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help> List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=subscribe> Sender: xen-devel-bounces@lists.xensource.com Errors-To: xen-devel-bounces@lists.xensource.com On Thu, Sep 08, 2011 at 09:38:48AM -0400, Konrad Rzeszutek Wilk wrote: > On Wed, Sep 07, 2011 at 03:06:59PM -0400, Konrad Rzeszutek Wilk wrote: > > > > >> +#define XENPF_enter_acpi_sleep 51 > > > > >> +struct xenpf_enter_acpi_sleep { > > > > >> + /* IN variables */ > > > > >> + uint16_t pm1a_cnt_val; /* PM1a control value. */ > > > > >> + uint16_t pm1b_cnt_val; /* PM1b control value. */ > > > > > These are uint32_t in native Linux--why truncate in the API and not at use? > > > > > > > > Does ACPI define them as 32 or 16 bit? > > > > > > The spec indicates that the length is variable and could be up to 32 bits (AFAICT). And Linux uses 32b, which your other patch is truncating for this call. > > > > Yikes! Well, looks like we need to fix the Xen ABI too. Lets get that fixed > > and also address all the other comments (thanks for looking at it) you pointed > > out. > > So read up the ACPI spec and it says that the minimum is 2 bytes and does not > say anything about the maximum. The list of what the bits do stops at 16-bits > (the last two are reserved) so I think we are actually OK. Perhaps a better way of doing this is in the hypercall (in the Linux kernel) check if the other 16-bits have any value. And if so WARN (with an appropiate message to email xen-devel) and also bail out on making the hypercall. That way we can find out about this. > > Albeit if the spec starts using more of them - then yes we will need to revist > this Xen ABI and potentially add a new call. > > _______________________________________________ > Xen-devel mailing list > Xen-devel@lists.xensource.com > http://lists.xensource.com/xen-devel _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel From xen-devel-bounces@lists.xensource.com Thu Sep 22 05:56:25 2011 Return-path: <xen-devel-bounces@lists.xensource.com> Envelope-to: www-data@lists.xensource.com Delivery-date: Thu, 22 Sep 2011 05:56:25 -0700 Received: from localhost ([127.0.0.1] helo=lists.colo.xensource.com) by lists.xensource.com with esmtp (Exim 4.43) id 1R6ipF-0002sI-GU; Thu, 22 Sep 2011 05:56:25 -0700 Received: from mail182.messagelabs.com ([85.158.139.83]) by lists.xensource.com with esmtp (Exim 4.43) id 1R6iop-0002g2-FI for xen-devel@lists.xensource.com; Thu, 22 Sep 2011 05:55:59 -0700 X-Env-Sender: javier.manzano@edu.uah.es X-Msg-Ref: server-14.tower-182.messagelabs.com!1316696155!19172188!1 X-Originating-IP: [216.139.236.26] X-StarScan-Version: 6.4.1; banners=-,-,- X-VirusChecked: Checked Received: (qmail 23302 invoked from network); 22 Sep 2011 12:55:56 -0000 Received: from sam.nabble.com (HELO sam.nabble.com) (216.139.236.26) by server-14.tower-182.messagelabs.com with AES256-SHA encrypted SMTP; 22 Sep 2011 12:55:56 -0000 Received: from [192.168.236.26] (helo=sam.nabble.com) by sam.nabble.com with esmtp (Exim 4.72) (envelope-from <javier.manzano@edu.uah.es>) id 1R6iok-0000OJ-PO for xen-devel@lists.xensource.com; Thu, 22 Sep 2011 05:55:54 -0700 Date: Thu, 22 Sep 2011 05:55:54 -0700 (PDT) From: JavMV <javier.manzano@edu.uah.es> To: xen-devel@lists.xensource.com Message-ID: <1316696154780-4830056.post@n5.nabble.com> In-Reply-To: <1316695546329-4830015.post@n5.nabble.com> References: <1316612652132-4826391.post@n5.nabble.com> <1316613404292-4826432.post@n5.nabble.com> <1316614084705-4826479.post@n5.nabble.com> <1316615526442-4826582.post@n5.nabble.com> <1316616001843-4826614.post@n5.nabble.com> <1316616472579-4826635.post@n5.nabble.com> <1316616757871-4826655.post@n5.nabble.com> <1316618006.67296.YahooMailNeo@web29818.mail.ird.yahoo.com> <1316693722029-4829929.post@n5.nabble.com> <1316695546329-4830015.post@n5.nabble.com> Subject: Re: Re : Re : Re : Re : [Xen-devel] Re: Patches for VGA-Passthrough XEN 4.2 unstable MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-BeenThere: xen-devel@lists.xensource.com X-Mailman-Version: 2.1.5 Precedence: list List-Id: Xen developer discussion <xen-devel.lists.xensource.com> List-Unsubscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe> List-Post: <mailto:xen-devel@lists.xensource.com> List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help> List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=subscribe> Sender: xen-devel-bounces@lists.xensource.com Errors-To: xen-devel-bounces@lists.xensource.com Well I think that vt-d(iommu) is the same feature than the next one: Intel(R) VT for Directed I/O (VT-d) <Enable> An extract from wikipedia tell us this: Intel has published a specification for IOMMU technology as Virtualization Technology for Directed I/O, abbreviated VT-d So I have already enabled the necessary options (and there isn't any other option in my BIOS related with this), besides with the same options enabled in BIOS I was able to use passthrough in the past ----- JavMV -- View this message in context: http://xen.1045712.n5.nabble.com/Patches-for-VGA-Passthrough-XEN-4-2-unstable-tp4406265p4830056.html Sent from the Xen - Dev mailing list archive at Nabble.com. _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel From xen-devel-bounces@lists.xensource.com Thu Sep 22 06:07:44 2011 Return-path: <xen-devel-bounces@lists.xensource.com> Envelope-to: www-data@lists.xensource.com Delivery-date: Thu, 22 Sep 2011 06:07:44 -0700 Received: from localhost ([127.0.0.1] helo=lists.colo.xensource.com) by lists.xensource.com with esmtp (Exim 4.43) id 1R6j0C-0003SZ-BF; Thu, 22 Sep 2011 06:07:44 -0700 Received: from mail27.messagelabs.com ([193.109.254.147]) by lists.xensource.com with esmtp (Exim 4.43) id 1R6iye-0003FS-HH for xen-devel@lists.xensource.com; Thu, 22 Sep 2011 06:06:13 -0700 X-Env-Sender: david.vrabel@citrix.com X-Msg-Ref: server-10.tower-27.messagelabs.com!1316696743!36804282!1 X-Originating-IP: [66.165.176.63] X-StarScan-Version: 6.4.1; banners=-,-,- X-VirusChecked: Checked Received: (qmail 1399 invoked from network); 22 Sep 2011 13:05:45 -0000 Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63) by server-10.tower-27.messagelabs.com with RC4-SHA encrypted SMTP; 22 Sep 2011 13:05:45 -0000 X-IronPort-AV: E=Sophos;i="4.68,423,1312171200"; d="scan'208";a="164283518" Received: from ftlpmailmx01.citrite.net ([10.13.107.65]) by FTLPIPO02.CITRIX.COM with ESMTP/TLS/RC4-MD5; 22 Sep 2011 09:06:03 -0400 Received: from [10.80.2.76] (10.80.2.76) by FTLPMAILMX01.citrite.net (10.13.107.65) with Microsoft SMTP Server id 8.3.137.0; Thu, 22 Sep 2011 09:06:03 -0400 Message-ID: <4E7B3361.6020604@citrix.com> Date: Thu, 22 Sep 2011 14:08:49 +0100 From: David Vrabel <david.vrabel@citrix.com> User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.1.16) Gecko/20110818 Icedove/3.0.11 MIME-Version: 1.0 To: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com> References: <1316089768-22461-1-git-send-email-david.vrabel@citrix.com> <20110921171103.GA2768@phenom.oracle.com> In-Reply-To: <20110921171103.GA2768@phenom.oracle.com> Content-Type: text/plain; charset="ISO-8859-1" Content-Transfer-Encoding: 7bit Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com> Subject: [Xen-devel] Re: xen: memory initialization/balloon fixes (#3) X-BeenThere: xen-devel@lists.xensource.com X-Mailman-Version: 2.1.5 Precedence: list List-Id: Xen developer discussion <xen-devel.lists.xensource.com> List-Unsubscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe> List-Post: <mailto:xen-devel@lists.xensource.com> List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help> List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=subscribe> Sender: xen-devel-bounces@lists.xensource.com Errors-To: xen-devel-bounces@lists.xensource.com On 21/09/11 18:11, Konrad Rzeszutek Wilk wrote: > On Thu, Sep 15, 2011 at 01:29:21PM +0100, David Vrabel wrote: >> >> Patch 7 releases all pages in the initial allocation with PFNs that >> lie within a 1-1 mapping. This seems correct to me as I think that > > The only thing I remember about this was with dmidecode doing something > fishy.. (As in, it wouldn't work when the pages under 1MB were released) > (But I can't remember the details about it, so I might be completly > wrong). > > Could you please test that as well? dmidecode works on the two test boxes I had to hand. >> once the 1-1 mapping is set the MFN of the original page is lost so >> it's no longer accessible by the kernel (and it cannot be used by >> another domain David _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel From xen-devel-bounces@lists.xensource.com Thu Sep 22 06:09:15 2011 Return-path: <xen-devel-bounces@lists.xensource.com> Envelope-to: www-data@lists.xensource.com Delivery-date: Thu, 22 Sep 2011 06:09:15 -0700 Received: from localhost ([127.0.0.1] helo=lists.colo.xensource.com) by lists.xensource.com with esmtp (Exim 4.43) id 1R6j1f-0003vY-0D; Thu, 22 Sep 2011 06:09:15 -0700 Received: from mail21.messagelabs.com ([85.158.143.35]) by lists.xensource.com with esmtp (Exim 4.43) id 1R6iyw-0003Fd-6Y; Thu, 22 Sep 2011 06:06:27 -0700 X-Env-Sender: konrad@oracle.com X-Msg-Ref: server-3.tower-21.messagelabs.com!1316696792!52554083!1 X-Originating-IP: [148.87.113.117] X-StarScan-Version: 6.4.1; banners=-,-,- X-VirusChecked: Checked Received: (qmail 25974 invoked from network); 22 Sep 2011 13:06:34 -0000 Received: from rcsinet15.oracle.com (HELO rcsinet15.oracle.com) (148.87.113.117) by server-3.tower-21.messagelabs.com with DHE-RSA-AES256-SHA encrypted SMTP; 22 Sep 2011 13:06:34 -0000 Received: from rtcsinet21.oracle.com (rtcsinet21.oracle.com [66.248.204.29]) by rcsinet15.oracle.com (Switch-3.4.4/Switch-3.4.4) with ESMTP id p8MD6Ihg026465 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Thu, 22 Sep 2011 13:06:20 GMT Received: from acsmt358.oracle.com (acsmt358.oracle.com [141.146.40.158]) by rtcsinet21.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id p8MD6Hvk005153 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 22 Sep 2011 13:06:18 GMT Received: from abhmt103.oracle.com (abhmt103.oracle.com [141.146.116.55]) by acsmt358.oracle.com (8.12.11.20060308/8.12.11) with ESMTP id p8MD6C9l015642; Thu, 22 Sep 2011 08:06:12 -0500 Received: from oracle.com (/209.6.55.207) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Thu, 22 Sep 2011 06:06:11 -0700 Received: by oracle.com (Postfix, from userid 1000) id AE43B1364; Thu, 22 Sep 2011 09:06:18 -0400 (EDT) Date: Thu, 22 Sep 2011 09:06:18 -0400 From: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com> To: xen-devel@lists.xensource.com, xen-users@lists.xensource.com Message-ID: <20110922130618.GA13238@phenom.oracle.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.5.21 (2010-09-15) X-Source-IP: rtcsinet21.oracle.com [66.248.204.29] X-CT-RefId: str=0001.0A090201.4E7B32CC.0165,ss=1,re=0.000,fgs=0 Cc: Subject: [Xen-devel] Xen document day (Oct 12 or 26) X-BeenThere: xen-devel@lists.xensource.com X-Mailman-Version: 2.1.5 Precedence: list List-Id: Xen developer discussion <xen-devel.lists.xensource.com> List-Unsubscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe> List-Post: <mailto:xen-devel@lists.xensource.com> List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help> List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=subscribe> Sender: xen-devel-bounces@lists.xensource.com Errors-To: xen-devel-bounces@lists.xensource.com Part of what we brainstormed at Xen Hackathon was what we could do make Xen easier. And the one thing that seemed to surface up was making the docs better - either be the Wiki or the three .pdfs that get created/shipped with Xen. One thought was to come up with a Documention Day - where volunteers would try to fix up some portion of the documentation that they feel they have a good grasp of knowledge off and are willing to change (and also look to be incorrect) What do you guys think of Oct 12th or Oct 26 as a day for this? And then the next question - what page/pdf section interests you? http://bits.xensource.com/Xen/docs/user.pdf http://www.rites.uic.edu/~solworth/xenInterfaceManual.pdf [the one on Xen.org is an older version] Or Wiki pages: http://wiki.xensource.com/xenwiki/ http://wiki.xensource.com/xenwiki/XenDom0Kernels http://wiki.xensource.com/xenwiki/XenSerialConsole http://wiki.xensource.com/xenwiki/XenParavirtOps http://wiki.xensource.com/xenwiki/XenCommonProblems http://wiki.xensource.com/xenwiki/Consulting http://wiki.xensource.com/xenwiki/Consultants http://wiki.xensource.com/xenwiki/VpsHostingWithXen http://wiki.xen.org/xenwiki/XenPCIpassthrough http://wiki.xen.org/xenwiki/VTdHowTo _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel From xen-devel-bounces@lists.xensource.com Thu Sep 22 06:24:24 2011 Return-path: <xen-devel-bounces@lists.xensource.com> Envelope-to: www-data@lists.xensource.com Delivery-date: Thu, 22 Sep 2011 06:24:24 -0700 Received: from localhost ([127.0.0.1] helo=lists.colo.xensource.com) by lists.xensource.com with esmtp (Exim 4.43) id 1R6jGK-00058s-QO; Thu, 22 Sep 2011 06:24:24 -0700 Received: from mail216.messagelabs.com ([85.158.143.99]) by lists.xensource.com with esmtp (Exim 4.43) id 1R6jFi-0004wj-H1 for xen-devel@lists.xensource.com; Thu, 22 Sep 2011 06:23:46 -0700 X-Env-Sender: Ian.Campbell@eu.citrix.com X-Msg-Ref: server-14.tower-216.messagelabs.com!1316697823!19234392!1 X-Originating-IP: [62.200.22.115] X-StarScan-Version: 6.4.1; banners=-,-,- X-VirusChecked: Checked Received: (qmail 23088 invoked from network); 22 Sep 2011 13:23:43 -0000 Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115) by server-14.tower-216.messagelabs.com with RC4-SHA encrypted SMTP; 22 Sep 2011 13:23:43 -0000 X-IronPort-AV: E=Sophos;i="4.68,423,1312156800"; d="scan'208";a="8007852" Received: from lonpmailmx01.citrite.net ([10.30.203.162]) by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5; 22 Sep 2011 13:23:43 +0000 Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net (10.30.203.162) with Microsoft SMTP Server id 8.3.137.0; Thu, 22 Sep 2011 14:23:43 +0100 Subject: Re: [Xen-devel] [PATCH 1 of 6] xenbackendd: fix incorrect usage of pidfile From: Ian Campbell <Ian.Campbell@citrix.com> To: Roger Pau Monne <roger.pau@entel.upc.edu> Date: Thu, 22 Sep 2011 14:23:42 +0100 In-Reply-To: <576c0ce336acb501cbba.1316692868@loki> References: <patchbomb.1316692867@loki> <576c0ce336acb501cbba.1316692868@loki> Organization: Citrix Systems, Inc. Content-Type: text/plain; charset="UTF-8" X-Mailer: Evolution 3.0.3- Content-Transfer-Encoding: 7bit Message-ID: <1316697823.23371.62.camel@zakaz.uk.xensource.com> MIME-Version: 1.0 Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com> X-BeenThere: xen-devel@lists.xensource.com X-Mailman-Version: 2.1.5 Precedence: list List-Id: Xen developer discussion <xen-devel.lists.xensource.com> List-Unsubscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe> List-Post: <mailto:xen-devel@lists.xensource.com> List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help> List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=subscribe> Sender: xen-devel-bounces@lists.xensource.com Errors-To: xen-devel-bounces@lists.xensource.com On Thu, 2011-09-22 at 13:01 +0100, Roger Pau Monne wrote: > # HG changeset patch > # User Roger Pau Monne <roger.pau@entel.upc.edu> > # Date 1316692475 -7200 > # Node ID 576c0ce336acb501cbba245dc801f06edc391479 > # Parent a422e2a4451e16dc791b293f41966b842fa4781d > xenbackendd: fix incorrect usage of pidfile > > Fix xenbackendd ignoring the pidfile passed through the command line. > > Signed-off-by: Roger Pau Monne <roger.pau@entel.upc.edu> Acked-by: Ian Campbell <ian.campbell@citrix.com> > > diff -r a422e2a4451e -r 576c0ce336ac tools/xenbackendd/xenbackendd.c > --- a/tools/xenbackendd/xenbackendd.c Sun Sep 18 00:26:52 2011 +0100 > +++ b/tools/xenbackendd/xenbackendd.c Thu Sep 22 13:54:35 2011 +0200 > @@ -169,7 +169,7 @@ main(int argc, char * const argv[]) > log_file = optarg; > break; > case 'p': > - pidfile = pidfile; > + pidfile = optarg; > case 's': > vbd_script = optarg; > break; > > _______________________________________________ > Xen-devel mailing list > Xen-devel@lists.xensource.com > http://lists.xensource.com/xen-devel _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel From xen-devel-bounces@lists.xensource.com Thu Sep 22 06:28:44 2011 Return-path: <xen-devel-bounces@lists.xensource.com> Envelope-to: www-data@lists.xensource.com Delivery-date: Thu, 22 Sep 2011 06:28:44 -0700 Received: from localhost ([127.0.0.1] helo=lists.colo.xensource.com) by lists.xensource.com with esmtp (Exim 4.43) id 1R6jKW-0005Ym-9N; Thu, 22 Sep 2011 06:28:44 -0700 Received: from mail216.messagelabs.com ([85.158.143.99]) by lists.xensource.com with esmtp (Exim 4.43) id 1R6jK6-0005N7-Vs for xen-devel@lists.xensource.com; Thu, 22 Sep 2011 06:28:19 -0700 X-Env-Sender: Ian.Campbell@eu.citrix.com X-Msg-Ref: server-6.tower-216.messagelabs.com!1316698095!17960401!1 X-Originating-IP: [62.200.22.115] X-StarScan-Version: 6.4.1; banners=-,-,- X-VirusChecked: Checked Received: (qmail 6490 invoked from network); 22 Sep 2011 13:28:16 -0000 Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115) by server-6.tower-216.messagelabs.com with RC4-SHA encrypted SMTP; 22 Sep 2011 13:28:16 -0000 X-IronPort-AV: E=Sophos;i="4.68,423,1312156800"; d="scan'208";a="8007988" Received: from lonpmailmx01.citrite.net ([10.30.203.162]) by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5; 22 Sep 2011 13:28:15 +0000 Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net (10.30.203.162) with Microsoft SMTP Server id 8.3.137.0; Thu, 22 Sep 2011 14:28:15 +0100 Subject: Re: [Xen-devel] [PATCH 2 of 6] hotplug: set hotplug-status to disconnected at removal From: Ian Campbell <Ian.Campbell@citrix.com> To: Roger Pau Monne <roger.pau@entel.upc.edu> Date: Thu, 22 Sep 2011 14:28:15 +0100 In-Reply-To: <1d3830f8a7306088b49d.1316692869@loki> References: <patchbomb.1316692867@loki> <1d3830f8a7306088b49d.1316692869@loki> Organization: Citrix Systems, Inc. Content-Type: text/plain; charset="UTF-8" X-Mailer: Evolution 3.0.3- Content-Transfer-Encoding: 7bit Message-ID: <1316698095.23371.65.camel@zakaz.uk.xensource.com> MIME-Version: 1.0 Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com> X-BeenThere: xen-devel@lists.xensource.com X-Mailman-Version: 2.1.5 Precedence: list List-Id: Xen developer discussion <xen-devel.lists.xensource.com> List-Unsubscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe> List-Post: <mailto:xen-devel@lists.xensource.com> List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help> List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=subscribe> Sender: xen-devel-bounces@lists.xensource.com Errors-To: xen-devel-bounces@lists.xensource.com On Thu, 2011-09-22 at 13:01 +0100, Roger Pau Monne wrote: > # HG changeset patch > # User Roger Pau Monne <roger.pau@entel.upc.edu> > # Date 1316692482 -7200 > # Node ID 1d3830f8a7306088b49d5732b5e88a73c2bc0315 > # Parent 576c0ce336acb501cbba245dc801f06edc391479 > hotplug: set hotplug-status to disconnected at removal > > Set the hotplug-status attribute of xenstore to disconnected when the hotplug block script has finished disconnecting the device > > Signed-off-by: Roger Pau Monne <roger.pau@entel.upc.edu> Whitespace looks a bit screwed up. (Fair enough it already was but lets not make things worse. So: Acked-by: Ian Campbell <ian.campbell@citrix.com> but with the proviso that the following is subsequently applied too: 8<------------------------------------------------------------------ Subject: hotplug: s/^I/ / in block hotplug script Signed-off-by: Ian Campbell <ian.campbell@citrix.com> diff -r e077264006c5 tools/hotplug/Linux/block --- a/tools/hotplug/Linux/block Thu Sep 22 14:25:59 2011 +0100 +++ b/tools/hotplug/Linux/block Thu Sep 22 14:26:41 2011 +0100 @@ -239,10 +239,10 @@ case "$command" in claim_lock "block" check_device_sharing "$dev" "$mode" - write_dev "$dev" + write_dev "$dev" release_lock "block" - exit 0 - ;; + exit 0 + ;; file) # Canonicalise the file, for sharing check comparison, and the mode @@ -254,7 +254,7 @@ case "$command" in claim_lock "block" # Avoid a race with the remove if the path has been deleted, or - # otherwise changed from "InitWait" state e.g. due to a timeout + # otherwise changed from "InitWait" state e.g. due to a timeout xenbus_state=$(xenstore_read_default "$XENBUS_PATH/state" 'unknown') if [ "$xenbus_state" != '2' ] then @@ -308,35 +308,35 @@ mount it read-write in a guest domain." write_dev "$loopdev" release_lock "block" exit 0 - ;; + ;; "") claim_lock "block" success release_lock "block" - ;; + ;; esac ;; remove) case $t in phy) - xenstore_write "$XENBUS_PATH/hotplug-status" "disconnected" - exit 0 - ;; + xenstore_write "$XENBUS_PATH/hotplug-status" "disconnected" + exit 0 + ;; file) claim_lock "block" node=$(xenstore_read "$XENBUS_PATH/node") - losetup -d "$node" + losetup -d "$node" release_lock "block" - xenstore_write "$XENBUS_PATH/hotplug-status" "disconnected" - exit 0 - ;; + xenstore_write "$XENBUS_PATH/hotplug-status" "disconnected" + exit 0 + ;; "") exit 0 - ;; + ;; esac ;; _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel From xen-devel-bounces@lists.xensource.com Thu Sep 22 06:33:32 2011 Return-path: <xen-devel-bounces@lists.xensource.com> Envelope-to: www-data@lists.xensource.com Delivery-date: Thu, 22 Sep 2011 06:33:32 -0700 Received: from localhost ([127.0.0.1] helo=lists.colo.xensource.com) by lists.xensource.com with esmtp (Exim 4.43) id 1R6jP9-00066Q-G6; Thu, 22 Sep 2011 06:33:32 -0700 Received: from mail27.messagelabs.com ([193.109.254.147]) by lists.xensource.com with esmtp (Exim 4.43) id 1R6jOg-0005p7-Vr for xen-devel@lists.xensource.com; Thu, 22 Sep 2011 06:33:03 -0700 X-Env-Sender: Ian.Campbell@eu.citrix.com X-Msg-Ref: server-13.tower-27.messagelabs.com!1316698367!41113070!1 X-Originating-IP: [62.200.22.115] X-StarScan-Version: 6.4.1; banners=-,-,- X-VirusChecked: Checked Received: (qmail 13503 invoked from network); 22 Sep 2011 13:32:48 -0000 Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115) by server-13.tower-27.messagelabs.com with RC4-SHA encrypted SMTP; 22 Sep 2011 13:32:48 -0000 X-IronPort-AV: E=Sophos;i="4.68,423,1312156800"; d="scan'208";a="8008204" Received: from lonpmailmx01.citrite.net ([10.30.203.162]) by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5; 22 Sep 2011 13:32:59 +0000 Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net (10.30.203.162) with Microsoft SMTP Server id 8.3.137.0; Thu, 22 Sep 2011 14:32:59 +0100 Subject: Re: [Xen-devel] [PATCH 4 of 6] libxl: fix for libxl not waiting for devices to disconnect From: Ian Campbell <Ian.Campbell@citrix.com> To: Roger Pau Monne <roger.pau@entel.upc.edu> Date: Thu, 22 Sep 2011 14:32:59 +0100 In-Reply-To: <d5cca9e3b5d3576073a5.1316692871@loki> References: <patchbomb.1316692867@loki> <d5cca9e3b5d3576073a5.1316692871@loki> Organization: Citrix Systems, Inc. Content-Type: text/plain; charset="UTF-8" X-Mailer: Evolution 3.0.3- Content-Transfer-Encoding: 7bit Message-ID: <1316698379.23371.68.camel@zakaz.uk.xensource.com> MIME-Version: 1.0 Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com> X-BeenThere: xen-devel@lists.xensource.com X-Mailman-Version: 2.1.5 Precedence: list List-Id: Xen developer discussion <xen-devel.lists.xensource.com> List-Unsubscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe> List-Post: <mailto:xen-devel@lists.xensource.com> List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help> List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=subscribe> Sender: xen-devel-bounces@lists.xensource.com Errors-To: xen-devel-bounces@lists.xensource.com On Thu, 2011-09-22 at 13:01 +0100, Roger Pau Monne wrote: > # HG changeset patch > # User Roger Pau Monne <roger.pau@entel.upc.edu> > # Date 1316692495 -7200 > # Node ID d5cca9e3b5d3576073a543d0305e8f0d9dc9beeb > # Parent 2d77cbdc816bc943e9e69ecca34ae7157079045a > libxl: fix for libxl not waiting for devices to disconnect > > libxl was ignoring the timeout and the number of devices to wait before destroying them. > > Signed-off-by: Roger Pau Monne <roger.pau@entel.upc.edu> Acked-by: Ian Campbell <ian.campbell@citrix.com> Although I think it would read more naturally to set rc = 0 initially and set it to 1 on success, IYSWIM. > > diff -r 2d77cbdc816b -r d5cca9e3b5d3 tools/libxl/libxl_device.c > --- a/tools/libxl/libxl_device.c Thu Sep 22 13:54:49 2011 +0200 > +++ b/tools/libxl/libxl_device.c Thu Sep 22 13:54:55 2011 +0200 > @@ -422,6 +422,9 @@ static int wait_for_dev_destroy(libxl__g > } > free(l1); > } > + } else { > + /* timeout reached */ > + rc = 0; > } > return rc; > } > @@ -482,7 +485,7 @@ int libxl__devices_destroy(libxl__gc *gc > tv.tv_usec = 0; > while (n_watches > 0) { > if (wait_for_dev_destroy(gc, &tv)) { > - break; > + continue; > } else { > n_watches--; > } > > _______________________________________________ > Xen-devel mailing list > Xen-devel@lists.xensource.com > http://lists.xensource.com/xen-devel _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel From xen-devel-bounces@lists.xensource.com Thu Sep 22 06:35:58 2011 Return-path: <xen-devel-bounces@lists.xensource.com> Envelope-to: www-data@lists.xensource.com Delivery-date: Thu, 22 Sep 2011 06:35:58 -0700 Received: from localhost ([127.0.0.1] helo=lists.colo.xensource.com) by lists.xensource.com with esmtp (Exim 4.43) id 1R6jRW-0006b7-Nk; Thu, 22 Sep 2011 06:35:58 -0700 Received: from mail216.messagelabs.com ([85.158.143.99]) by lists.xensource.com with esmtp (Exim 4.43) id 1R6jQu-0006PF-1N for xen-devel@lists.xensource.com; Thu, 22 Sep 2011 06:35:20 -0700 X-Env-Sender: Ian.Campbell@eu.citrix.com X-Msg-Ref: server-13.tower-216.messagelabs.com!1316698517!19243128!1 X-Originating-IP: [62.200.22.115] X-StarScan-Version: 6.4.1; banners=-,-,- X-VirusChecked: Checked Received: (qmail 13507 invoked from network); 22 Sep 2011 13:35:17 -0000 Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115) by server-13.tower-216.messagelabs.com with RC4-SHA encrypted SMTP; 22 Sep 2011 13:35:17 -0000 X-IronPort-AV: E=Sophos;i="4.68,423,1312156800"; d="scan'208";a="8008261" Received: from lonpmailmx01.citrite.net ([10.30.203.162]) by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5; 22 Sep 2011 13:35:16 +0000 Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net (10.30.203.162) with Microsoft SMTP Server id 8.3.137.0; Thu, 22 Sep 2011 14:35:16 +0100 Subject: Re: [Xen-devel] [PATCH 3 of 6] xenbackendd: pass type of block device to hotplug script From: Ian Campbell <Ian.Campbell@citrix.com> To: Roger Pau Monne <roger.pau@entel.upc.edu> Date: Thu, 22 Sep 2011 14:35:16 +0100 In-Reply-To: <2d77cbdc816bc943e9e6.1316692870@loki> References: <patchbomb.1316692867@loki> <2d77cbdc816bc943e9e6.1316692870@loki> Organization: Citrix Systems, Inc. Content-Type: text/plain; charset="UTF-8" X-Mailer: Evolution 3.0.3- Content-Transfer-Encoding: 7bit Message-ID: <1316698516.23371.70.camel@zakaz.uk.xensource.com> MIME-Version: 1.0 Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com> X-BeenThere: xen-devel@lists.xensource.com X-Mailman-Version: 2.1.5 Precedence: list List-Id: Xen developer discussion <xen-devel.lists.xensource.com> List-Unsubscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe> List-Post: <mailto:xen-devel@lists.xensource.com> List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help> List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=subscribe> Sender: xen-devel-bounces@lists.xensource.com Errors-To: xen-devel-bounces@lists.xensource.com On Thu, 2011-09-22 at 13:01 +0100, Roger Pau Monne wrote: > # HG changeset patch > # User Roger Pau Monne <roger.pau@entel.upc.edu> > # Date 1316692489 -7200 > # Node ID 2d77cbdc816bc943e9e69ecca34ae7157079045a > # Parent 1d3830f8a7306088b49d5732b5e88a73c2bc0315 > xenbackendd: pass type of block device to hotplug script > > Pass the type of block device to attach to the block script instead of reading it from xenstore, since new Xen versions don't make a difference between a block device or an image. > > Signed-off-by: Roger Pau Monne <roger.pau@entel.upc.edu> I've not got any problem with this one, but I don't think my ACK is worth much since it's NetBSD and I'm not really qualified, neverless: Acked-by: Ian Campbell <ian.campbell@citrix.com> > > diff -r 1d3830f8a730 -r 2d77cbdc816b tools/hotplug/NetBSD/block > --- a/tools/hotplug/NetBSD/block Thu Sep 22 13:54:42 2011 +0200 > +++ b/tools/hotplug/NetBSD/block Thu Sep 22 13:54:49 2011 +0200 > @@ -19,7 +19,7 @@ error() { > > xpath=$1 > xstatus=$2 > -xtype=$(xenstore-read "$xpath/type") > +xtype=$3 > xparams=$(xenstore-read "$xpath/params") > > case $xstatus in > diff -r 1d3830f8a730 -r 2d77cbdc816b tools/xenbackendd/xenbackendd.c > --- a/tools/xenbackendd/xenbackendd.c Thu Sep 22 13:54:42 2011 +0200 > +++ b/tools/xenbackendd/xenbackendd.c Thu Sep 22 13:54:49 2011 +0200 > @@ -89,15 +89,15 @@ dodebug(const char *fmt, ...) > } > > static void > -doexec(const char *cmd, const char *arg1, const char *arg2) > +doexec(const char *cmd, const char *arg1, const char *arg2, const char *arg3) > { > - dodebug("exec %s %s %s", cmd, arg1, arg2); > + dodebug("exec %s %s %s %s", cmd, arg1, arg2, arg3); > switch(vfork()) { > case -1: > dolog(LOG_ERR, "can't vfork: %s", strerror(errno)); > break; > case 0: > - execl(cmd, cmd, arg1, arg2, NULL); > + execl(cmd, cmd, arg1, arg2, arg3, NULL); > dolog(LOG_ERR, "can't exec %s: %s", cmd, strerror(errno)); > exit(EXIT_FAILURE); > /* NOTREACHED */ > @@ -145,11 +145,14 @@ xen_setup(void) > int > main(int argc, char * const argv[]) > { > + struct stat stab; > char **vec; > unsigned int num; > char *s; > int state; > char *sstate; > + char *stype; > + char *params; > char *p; > char buf[80]; > int type; > @@ -297,11 +300,38 @@ main(int argc, char * const argv[]) > strerror(errno)); > goto next2; > } > - doexec(s, vec[XS_WATCH_PATH], sstate); > + doexec(s, vec[XS_WATCH_PATH], sstate, NULL); > break; > > case DEVTYPE_VBD: > - doexec(vbd_script, vec[XS_WATCH_PATH], sstate); > + /* check if given file is a block device or a raw image */ > + snprintf(buf, sizeof(buf), "%s/params", vec[XS_WATCH_PATH]); > + params = xs_read(xs, XBT_NULL, buf, 0); > + if(params == NULL) { > + dolog(LOG_ERR, > + "Failed to read %s (%s)", buf, strerror(errno)); > + goto next2; > + } > + if (stat(params, &stab) < 0) { > + dolog(LOG_ERR, > + "Failed to get info about %s (%s)", params, > + strerror(errno)); > + goto next3; > + } > + stype = NULL; > + if (S_ISBLK(stab.st_mode)) > + stype = "phy"; > + if (S_ISREG(stab.st_mode)) > + stype = "file"; > + if (stype == NULL) { > + dolog(LOG_ERR, > + "Failed to attach %s (not a block device or raw image)", > + params, strerror(errno)); > + goto next3; > + } > + doexec(vbd_script, vec[XS_WATCH_PATH], sstate, stype); > +next3: > + free(params); > break; > > default: > > _______________________________________________ > Xen-devel mailing list > Xen-devel@lists.xensource.com > http://lists.xensource.com/xen-devel _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel From xen-devel-bounces@lists.xensource.com Thu Sep 22 06:37:34 2011 Return-path: <xen-devel-bounces@lists.xensource.com> Envelope-to: www-data@lists.xensource.com Delivery-date: Thu, 22 Sep 2011 06:37:34 -0700 Received: from localhost ([127.0.0.1] helo=lists.colo.xensource.com) by lists.xensource.com with esmtp (Exim 4.43) id 1R6jT4-0006ye-IM; Thu, 22 Sep 2011 06:37:34 -0700 Received: from mail216.messagelabs.com ([85.158.143.99]) by lists.xensource.com with esmtp (Exim 4.43) id 1R6jSf-0006n2-7T for xen-devel@lists.xensource.com; Thu, 22 Sep 2011 06:37:09 -0700 X-Env-Sender: Ian.Campbell@eu.citrix.com X-Msg-Ref: server-6.tower-216.messagelabs.com!1316698626!17961848!1 X-Originating-IP: [62.200.22.115] X-StarScan-Version: 6.4.1; banners=-,-,- X-VirusChecked: Checked Received: (qmail 29700 invoked from network); 22 Sep 2011 13:37:06 -0000 Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115) by server-6.tower-216.messagelabs.com with RC4-SHA encrypted SMTP; 22 Sep 2011 13:37:06 -0000 X-IronPort-AV: E=Sophos;i="4.68,423,1312156800"; d="scan'208";a="8008446" Received: from lonpmailmx01.citrite.net ([10.30.203.162]) by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5; 22 Sep 2011 13:37:06 +0000 Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net (10.30.203.162) with Microsoft SMTP Server id 8.3.137.0; Thu, 22 Sep 2011 14:37:05 +0100 Subject: Re: [Xen-devel] [PATCH 5 of 6] libxl: add support for NetBSD to use disk images as a PHY backend From: Ian Campbell <Ian.Campbell@citrix.com> To: Roger Pau Monne <roger.pau@entel.upc.edu> Date: Thu, 22 Sep 2011 14:37:05 +0100 In-Reply-To: <a5c9a6083bef9d4789a0.1316692872@loki> References: <patchbomb.1316692867@loki> <a5c9a6083bef9d4789a0.1316692872@loki> Organization: Citrix Systems, Inc. Content-Type: text/plain; charset="UTF-8" X-Mailer: Evolution 3.0.3- Content-Transfer-Encoding: 7bit Message-ID: <1316698625.23371.71.camel@zakaz.uk.xensource.com> MIME-Version: 1.0 Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com> X-BeenThere: xen-devel@lists.xensource.com X-Mailman-Version: 2.1.5 Precedence: list List-Id: Xen developer discussion <xen-devel.lists.xensource.com> List-Unsubscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe> List-Post: <mailto:xen-devel@lists.xensource.com> List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help> List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=subscribe> Sender: xen-devel-bounces@lists.xensource.com Errors-To: xen-devel-bounces@lists.xensource.com On Thu, 2011-09-22 at 13:01 +0100, Roger Pau Monne wrote: > # HG changeset patch > # User Roger Pau Monne <roger.pau@entel.upc.edu> > # Date 1316692503 -7200 > # Node ID a5c9a6083bef9d4789a0194389db234740cd6005 > # Parent d5cca9e3b5d3576073a543d0305e8f0d9dc9beeb > libxl: add support for NetBSD to use disk images as a PHY backend > > Add a NetBSD special case to use images as PHY disk devices, which can be attached using the regular block hotplug script. > > Signed-off-by: Roger Pau Monne <roger.pau@entel.upc.edu> Acked-by: Ian Campbell <ian.campbell@citrix.com> I think the "return 0"s in this function ought to be LIBXL_DISK_BACKEND_UNKNOWN for clarity but that's a pre-existing problem. > > diff -r d5cca9e3b5d3 -r a5c9a6083bef tools/libxl/libxl_device.c > --- a/tools/libxl/libxl_device.c Thu Sep 22 13:54:55 2011 +0200 > +++ b/tools/libxl/libxl_device.c Thu Sep 22 13:55:03 2011 +0200 > @@ -136,15 +136,20 @@ static int disk_try_backend(disk_try_bac > a->disk->format == LIBXL_DISK_FORMAT_EMPTY)) { > goto bad_format; > } > - if (a->disk->format != LIBXL_DISK_FORMAT_EMPTY && > - !S_ISBLK(a->stab.st_mode)) { > - LIBXL__LOG(ctx, LIBXL__LOG_DEBUG, "Disk vdev=%s, backend phy" > - " unsuitable as phys path not a block device", > - a->disk->vdev); > - return 0; > - } > - > - return backend; > + if (S_ISBLK(a->stab.st_mode)) > + return backend; > +#ifdef HAVE_PHY_BACKEND_FILE_SUPPORT > + if (S_ISREG(a->stab.st_mode)) > + return backend; > + LIBXL__LOG(ctx, LIBXL__LOG_DEBUG, "Disk vdev=%s, backend phy" > + " unsuitable as phys path not a block device or" > + " raw image", a->disk->vdev); > +#else > + LIBXL__LOG(ctx, LIBXL__LOG_DEBUG, "Disk vdev=%s, backend phy" > + " unsuitable as phys path not a block device", > + a->disk->vdev); > +#endif > + return 0; > > case LIBXL_DISK_BACKEND_TAP: > if (!libxl__blktap_enabled(a->gc)) { > diff -r d5cca9e3b5d3 -r a5c9a6083bef tools/libxl/libxl_osdeps.h > --- a/tools/libxl/libxl_osdeps.h Thu Sep 22 13:54:55 2011 +0200 > +++ b/tools/libxl/libxl_osdeps.h Thu Sep 22 13:55:03 2011 +0200 > @@ -25,6 +25,7 @@ > > #if defined(__NetBSD__) || defined(__OpenBSD__) > #include <util.h> > +#define HAVE_PHY_BACKEND_FILE_SUPPORT > #elif defined(__linux__) > #include <pty.h> > #elif defined(__sun__) > > _______________________________________________ > Xen-devel mailing list > Xen-devel@lists.xensource.com > http://lists.xensource.com/xen-devel _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel From xen-devel-bounces@lists.xensource.com Thu Sep 22 06:45:41 2011 Return-path: <xen-devel-bounces@lists.xensource.com> Envelope-to: www-data@lists.xensource.com Delivery-date: Thu, 22 Sep 2011 06:45:41 -0700 Received: from localhost ([127.0.0.1] helo=lists.colo.xensource.com) by lists.xensource.com with esmtp (Exim 4.43) id 1R6jav-0007Ru-Qx; Thu, 22 Sep 2011 06:45:41 -0700 Received: from mail27.messagelabs.com ([193.109.254.147]) by lists.xensource.com with esmtp (Exim 4.43) id 1R6jaE-0007Fd-Sv for xen-devel@lists.xensource.com; Thu, 22 Sep 2011 06:44:59 -0700 X-Env-Sender: Ian.Campbell@eu.citrix.com X-Msg-Ref: server-14.tower-27.messagelabs.com!1316699081!37208809!1 X-Originating-IP: [62.200.22.115] X-StarScan-Version: 6.4.1; banners=-,-,- X-VirusChecked: Checked Received: (qmail 28225 invoked from network); 22 Sep 2011 13:44:41 -0000 Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115) by server-14.tower-27.messagelabs.com with RC4-SHA encrypted SMTP; 22 Sep 2011 13:44:41 -0000 X-IronPort-AV: E=Sophos;i="4.68,423,1312156800"; d="scan'208";a="8008858" Received: from lonpmailmx01.citrite.net ([10.30.203.162]) by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5; 22 Sep 2011 13:44:55 +0000 Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net (10.30.203.162) with Microsoft SMTP Server id 8.3.137.0; Thu, 22 Sep 2011 14:44:55 +0100 Subject: Re: [Xen-devel] [PATCH 6 of 6] libxl: use hotplug-status to synchronize the destruction of block devices From: Ian Campbell <Ian.Campbell@citrix.com> To: Roger Pau Monne <roger.pau@entel.upc.edu> Date: Thu, 22 Sep 2011 14:44:55 +0100 In-Reply-To: <9e9c68768676b0e1c9c7.1316692873@loki> References: <patchbomb.1316692867@loki> <9e9c68768676b0e1c9c7.1316692873@loki> Organization: Citrix Systems, Inc. Content-Type: text/plain; charset="UTF-8" X-Mailer: Evolution 3.0.3- Content-Transfer-Encoding: 7bit Message-ID: <1316699095.23371.76.camel@zakaz.uk.xensource.com> MIME-Version: 1.0 Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com> X-BeenThere: xen-devel@lists.xensource.com X-Mailman-Version: 2.1.5 Precedence: list List-Id: Xen developer discussion <xen-devel.lists.xensource.com> List-Unsubscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe> List-Post: <mailto:xen-devel@lists.xensource.com> List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help> List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=subscribe> Sender: xen-devel-bounces@lists.xensource.com Errors-To: xen-devel-bounces@lists.xensource.com On Thu, 2011-09-22 at 13:01 +0100, Roger Pau Monne wrote: > # HG changeset patch > # User Roger Pau Monne <roger.pau@entel.upc.edu> > # Date 1316692512 -7200 > # Node ID 9e9c68768676b0e1c9c76599e00d0922c6184602 > # Parent a5c9a6083bef9d4789a0194389db234740cd6005 > libxl: use hotplug-status to synchronize the destruction of block devices > > Use hotplug-status to synchronize the destruction of vbd devices instead of state, which did not reflect when the hotplug script had been executed. > > Signed-off-by: Roger Pau Monne <roger.pau@entel.upc.edu> I wonder if we can remove the hard coding of the VBD special case somehow? For example an ops struct in an array mapping DEVICE_* to int (*watch_for_disconnect)(relevant arguments) int (*has_disconnected)(relevant arguments) which would have two implementations, one checking state and the other hotplug-status. That leaves the change in wait_for_dev_destroy which unfortunately doesn't have the context to do much else than what you've done. Perhaps that's ok as is until I can finish of the patch series I have which fixes that aspect. I suppose a function pointer could be encoded in the XS_WATCH_TOKEN and sscanf'd back out again... > > diff -r a5c9a6083bef -r 9e9c68768676 tools/libxl/libxl_device.c > --- a/tools/libxl/libxl_device.c Thu Sep 22 13:55:03 2011 +0200 > +++ b/tools/libxl/libxl_device.c Thu Sep 22 13:55:12 2011 +0200 > @@ -371,14 +371,26 @@ int libxl__device_destroy(libxl__gc *gc, > libxl_ctx *ctx = libxl__gc_owner(gc); > xs_transaction_t t; > char *state_path = libxl__sprintf(gc, "%s/state", be_path); > + char *hotplug_path = libxl__sprintf(gc, "%s/hotplug-status", be_path); > char *state = libxl__xs_read(gc, XBT_NULL, state_path); > + char *hotplug = libxl__xs_read(gc, XBT_NULL, hotplug_path); > int rc = 0; > > if (!state) > goto out; > - if (atoi(state) != 4) { > - xs_rm(ctx->xsh, XBT_NULL, be_path); > - goto out; > + > + if (!strstr(be_path, string_of_kinds[DEVICE_VBD])) { > + if (atoi(state) != 4) { > + xs_rm(ctx->xsh, XBT_NULL, be_path); > + goto out; > + } > + } else { > + if (!hotplug) > + goto out; > + if (!strcmp(hotplug, "disconnected")) { > + xs_rm(ctx->xsh, XBT_NULL, be_path); > + goto out; > + } > } > > retry_transaction: > @@ -394,8 +406,13 @@ retry_transaction: > } > } > if (!force) { > - xs_watch(ctx->xsh, state_path, be_path); > - rc = 1; > + if (strstr(be_path, string_of_kinds[DEVICE_VBD])) { > + xs_watch(ctx->xsh, hotplug_path, be_path); > + rc = 1; > + } else { > + xs_watch(ctx->xsh, state_path, be_path); > + rc = 1; > + } > } else { > xs_rm(ctx->xsh, XBT_NULL, be_path); > } > @@ -410,6 +427,7 @@ static int wait_for_dev_destroy(libxl__g > unsigned int n; > fd_set rfds; > char **l1 = NULL; > + char *state, *hotplug; > > rc = 1; > nfds = xs_fileno(ctx->xsh) + 1; > @@ -418,12 +436,26 @@ static int wait_for_dev_destroy(libxl__g > if (select(nfds, &rfds, NULL, NULL, tv) > 0) { > l1 = xs_read_watch(ctx->xsh, &n); > if (l1 != NULL) { > - char *state = libxl__xs_read(gc, XBT_NULL, l1[XS_WATCH_PATH]); > - if (!state || atoi(state) == 6) { > - xs_unwatch(ctx->xsh, l1[0], l1[1]); > - xs_rm(ctx->xsh, XBT_NULL, l1[XS_WATCH_TOKEN]); > - LIBXL__LOG(ctx, LIBXL__LOG_DEBUG, "Destroyed device backend at %s", l1[XS_WATCH_TOKEN]); > - rc = 0; > + if (strstr(l1[XS_WATCH_PATH], "hotplug-status")) { > + hotplug = libxl__xs_read(gc, XBT_NULL, l1[XS_WATCH_PATH]); > + if (!hotplug || !strcmp(hotplug, "disconnected")) { > + xs_unwatch(ctx->xsh, l1[0], l1[1]); > + xs_rm(ctx->xsh, XBT_NULL, l1[XS_WATCH_TOKEN]); > + LIBXL__LOG(ctx, LIBXL__LOG_DEBUG, > + "Destroyed device backend at %s hotplug-status: %s", > + l1[XS_WATCH_TOKEN], hotplug); > + rc = 0; > + } > + } else { > + state = libxl__xs_read(gc, XBT_NULL, l1[XS_WATCH_PATH]); > + if (!state || atoi(state) == 6) { > + xs_unwatch(ctx->xsh, l1[0], l1[1]); > + xs_rm(ctx->xsh, XBT_NULL, l1[XS_WATCH_TOKEN]); > + LIBXL__LOG(ctx, LIBXL__LOG_DEBUG, > + "Destroyed device backend at %s", > + l1[XS_WATCH_TOKEN]); > + rc = 0; > + } > } > free(l1); > } > > _______________________________________________ > Xen-devel mailing list > Xen-devel@lists.xensource.com > http://lists.xensource.com/xen-devel _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel From xen-devel-bounces@lists.xensource.com Thu Sep 22 06:58:05 2011 Return-path: <xen-devel-bounces@lists.xensource.com> Envelope-to: www-data@lists.xensource.com Delivery-date: Thu, 22 Sep 2011 06:58:05 -0700 Received: from localhost ([127.0.0.1] helo=lists.colo.xensource.com) by lists.xensource.com with esmtp (Exim 4.43) id 1R6jmv-00086x-5x; Thu, 22 Sep 2011 06:58:05 -0700 Received: from mail174.messagelabs.com ([85.158.138.51]) by lists.xensource.com with esmtp (Exim 4.43) id 1R6jlt-0007sI-Cv for xen-devel@lists.xensource.com; Thu, 22 Sep 2011 06:57:01 -0700 X-Env-Sender: Ian.Jackson@eu.citrix.com X-Msg-Ref: server-3.tower-174.messagelabs.com!1316699817!26317605!1 X-Originating-IP: [62.200.22.115] X-StarScan-Version: 6.4.1; banners=-,-,- X-VirusChecked: Checked Received: (qmail 18309 invoked from network); 22 Sep 2011 13:56:58 -0000 Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115) by server-3.tower-174.messagelabs.com with RC4-SHA encrypted SMTP; 22 Sep 2011 13:56:58 -0000 X-IronPort-AV: E=Sophos;i="4.68,423,1312156800"; d="scan'208";a="8009296" Received: from lonpmailmx01.citrite.net ([10.30.203.162]) by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5; 22 Sep 2011 13:56:57 +0000 Received: from woking.xci-test.com (10.80.248.135) by smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id 8.3.137.0; Thu, 22 Sep 2011 14:56:57 +0100 Received: from osstest by woking.xci-test.com with local (Exim 4.69) (envelope-from <ian.jackson@eu.citrix.com>) id 1R6jlp-0006L4-Bo; Thu, 22 Sep 2011 14:56:57 +0100 To: xen-devel@lists.xensource.com Message-ID: <osstest-8997-mainreport@xen.org> From: xen.org <ian.jackson@eu.citrix.com> Date: Thu, 22 Sep 2011 14:56:57 +0100 MIME-Version: 1.0 Content-Type: text/plain Cc: ian.jackson@eu.citrix.com Subject: [Xen-devel] [linux test] 8997: tolerable FAIL X-BeenThere: xen-devel@lists.xensource.com X-Mailman-Version: 2.1.5 Precedence: list List-Id: Xen developer discussion <xen-devel.lists.xensource.com> List-Unsubscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe> List-Post: <mailto:xen-devel@lists.xensource.com> List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help> List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=subscribe> Sender: xen-devel-bounces@lists.xensource.com Errors-To: xen-devel-bounces@lists.xensource.com flight 8997 linux real [real] http://www.chiark.greenend.org.uk/~xensrcts/logs/8997/ Failures :-/ but no regressions. Tests which are failing intermittently (not blocking): test-amd64-amd64-xl-sedf 10 guest-saverestore fail pass in 8994 Tests which did not succeed, but are not blocking, including regressions (tests previously passed) regarded as allowable: test-amd64-amd64-xl-pcipt-intel 9 guest-start fail never pass test-amd64-i386-rhel6hvm-amd 9 guest-start.2 fail never pass test-amd64-i386-rhel6hvm-intel 9 guest-start.2 fail never pass test-i386-i386-win 16 leak-check/check fail never pass test-amd64-i386-win-vcpus1 16 leak-check/check fail never pass test-amd64-i386-xl-win-vcpus1 13 guest-stop fail never pass test-amd64-amd64-win 16 leak-check/check fail never pass test-amd64-i386-win 16 leak-check/check fail never pass test-amd64-amd64-xl-win 13 guest-stop fail never pass test-i386-i386-xl-win 13 guest-stop fail never pass version targeted for testing: linux 6bec8b4a4c14095d0b7ce424db9d583c3decae6c baseline version: linux 1c3f03ccc5258887f5f2cafc0836a865834f9205 ------------------------------------------------------------ People who touched revisions under test: Jeremy Fitzhardinge <jeremy.fitzhardinge@citrix.com> ------------------------------------------------------------ jobs: build-amd64 pass build-i386 pass build-amd64-pvops pass build-i386-pvops pass test-amd64-amd64-xl pass test-amd64-i386-xl pass test-i386-i386-xl pass test-amd64-i386-rhel6hvm-amd fail test-amd64-i386-xl-credit2 pass test-amd64-amd64-xl-pcipt-intel fail test-amd64-i386-rhel6hvm-intel fail test-amd64-i386-xl-multivcpu pass test-amd64-amd64-pair pass test-amd64-i386-pair pass test-i386-i386-pair pass test-amd64-amd64-pv pass test-amd64-i386-pv pass test-i386-i386-pv pass test-amd64-amd64-xl-sedf fail test-amd64-i386-win-vcpus1 fail test-amd64-i386-xl-win-vcpus1 fail test-amd64-amd64-win fail test-amd64-i386-win fail test-i386-i386-win fail test-amd64-amd64-xl-win fail test-i386-i386-xl-win fail ------------------------------------------------------------ sg-report-flight on woking.cam.xci-test.com logs: /home/xc_osstest/logs images: /home/xc_osstest/images Logs, config files, etc. are available at http://www.chiark.greenend.org.uk/~xensrcts/logs Test harness code can be found at http://xenbits.xensource.com/gitweb?p=osstest.git;a=summary Pushing revision : + branch=linux + revision=6bec8b4a4c14095d0b7ce424db9d583c3decae6c + . cri-lock-repos ++ . cri-common +++ umask 002 +++ getconfig Repos +++ perl -e ' use Osstest; readconfigonly(); print $c{Repos} or die $!; ' ++ repos=/export/home/osstest/repos ++ repos_lock=/export/home/osstest/repos/lock ++ '[' x '!=' x/export/home/osstest/repos/lock ']' ++ OSSTEST_REPOS_LOCK_LOCKED=/export/home/osstest/repos/lock ++ exec with-lock-ex -w /export/home/osstest/repos/lock ./ap-push linux 6bec8b4a4c14095d0b7ce424db9d583c3decae6c + branch=linux + revision=6bec8b4a4c14095d0b7ce424db9d583c3decae6c + . cri-lock-repos ++ . cri-common +++ umask 002 +++ getconfig Repos +++ perl -e ' use Osstest; readconfigonly(); print $c{Repos} or die $!; ' ++ repos=/export/home/osstest/repos ++ repos_lock=/export/home/osstest/repos/lock ++ '[' x/export/home/osstest/repos/lock '!=' x/export/home/osstest/repos/lock ']' + : xen@xenbits.xensource.com + : xen@xenbits.xensource.com:git/linux-pvops + : master + : tested/2.6.39.x + case "$branch" in + cd /export/home/osstest/repos/xen ./ap-push: line 20: cd: /export/home/osstest/repos/xen: No such file or directory ------------------------------------------------------------ commit 6bec8b4a4c14095d0b7ce424db9d583c3decae6c Author: Jeremy Fitzhardinge <jeremy.fitzhardinge@citrix.com> Date: Fri Sep 2 12:23:22 2011 -0700 Revert "xen/apic: Provide an 'apic_xen' to set the override the apic->[read|write] for all cases." This reverts commit c3dd7941354fa96a71f2613e2c7a1b215fa175dc. It prevents the kernel from booting natively on hardware. Conflicts: arch/x86/xen/enlighten.c Signed-off-by: Jeremy Fitzhardinge <jeremy.fitzhardinge@citrix.com> _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel From xen-devel-bounces@lists.xensource.com Thu Sep 22 07:10:10 2011 Return-path: <xen-devel-bounces@lists.xensource.com> Envelope-to: www-data@lists.xensource.com Delivery-date: Thu, 22 Sep 2011 07:10:10 -0700 Received: from localhost ([127.0.0.1] helo=lists.colo.xensource.com) by lists.xensource.com with esmtp (Exim 4.43) id 1R6jyc-0000Dn-Cm; Thu, 22 Sep 2011 07:10:10 -0700 Received: from mail182.messagelabs.com ([85.158.139.83]) by lists.xensource.com with esmtp (Exim 4.43) id 1R6jx1-0008Rm-Nj for xen-devel@lists.xensource.com; Thu, 22 Sep 2011 07:08:33 -0700 X-Env-Sender: Christoph.Egger@amd.com X-Msg-Ref: server-7.tower-182.messagelabs.com!1316700507!14344518!1 X-Originating-IP: [65.55.88.12] X-StarScan-Version: 6.4.1; banners=-,-,- X-VirusChecked: Checked Received: (qmail 16158 invoked from network); 22 Sep 2011 14:08:28 -0000 Received: from tx2ehsobe002.messaging.microsoft.com (HELO TX2EHSOBE004.bigfish.com) (65.55.88.12) by server-7.tower-182.messagelabs.com with AES128-SHA encrypted SMTP; 22 Sep 2011 14:08:28 -0000 Received: from mail138-tx2-R.bigfish.com (10.9.14.246) by TX2EHSOBE004.bigfish.com (10.9.40.24) with Microsoft SMTP Server id 14.1.225.22; Thu, 22 Sep 2011 14:08:27 +0000 Received: from mail138-tx2 (localhost.localdomain [127.0.0.1]) by mail138-tx2-R.bigfish.com (Postfix) with ESMTP id DA3321F016F; Thu, 22 Sep 2011 14:08:26 +0000 (UTC) X-SpamScore: -14 X-BigFish: VPS-14(zzbb2dK936eK1432N98dKzz1202hzz8275bhz32i668h839h93fh61h) X-Spam-TCS-SCL: 0:0 X-Forefront-Antispam-Report: CIP:163.181.249.108; KIP:(null); UIP:(null); IPVD:NLI; H:ausb3twp01.amd.com; RD:none; EFVD:NLI Received: from mail138-tx2 (localhost.localdomain [127.0.0.1]) by mail138-tx2 (MessageSwitch) id 1316700497902036_6702; Thu, 22 Sep 2011 14:08:17 +0000 (UTC) Received: from TX2EHSMHS035.bigfish.com (unknown [10.9.14.253]) by mail138-tx2.bigfish.com (Postfix) with ESMTP id 591A4127004F; Thu, 22 Sep 2011 14:08:17 +0000 (UTC) Received: from ausb3twp01.amd.com (163.181.249.108) by TX2EHSMHS035.bigfish.com (10.9.99.135) with Microsoft SMTP Server id 14.1.225.22; Thu, 22 Sep 2011 14:06:54 +0000 X-WSS-ID: 0LRXGJD-01-BTV-02 X-M-MSG: Received: from sausexedgep01.amd.com (sausexedgep01-ext.amd.com [163.181.249.72]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by ausb3twp01.amd.com (Axway MailGate 3.8.1) with ESMTP id 27F1910282B4; Thu, 22 Sep 2011 09:06:49 -0500 (CDT) Received: from SAUSEXDAG01.amd.com (163.181.55.1) by sausexedgep01.amd.com (163.181.36.54) with Microsoft SMTP Server (TLS) id 8.3.106.1; Thu, 22 Sep 2011 09:07:07 -0500 Received: from storexhtp02.amd.com (172.24.4.4) by sausexdag01.amd.com (163.181.55.1) with Microsoft SMTP Server (TLS) id 14.1.289.1; Thu, 22 Sep 2011 09:06:52 -0500 Received: from rhodium.osrc.amd.com (165.204.15.173) by storexhtp02.amd.com (172.24.4.4) with Microsoft SMTP Server id 8.3.83.0; Thu, 22 Sep 2011 10:06:48 -0400 Message-ID: <4E7B40F7.8090201@amd.com> Date: Thu, 22 Sep 2011 16:06:47 +0200 From: Christoph Egger <Christoph.Egger@amd.com> User-Agent: Mozilla/5.0 (X11; U; NetBSD amd64; en-US; rv:1.9.2.17) Gecko/20110523 Lightning/1.0b3pre Thunderbird/3.1.10 MIME-Version: 1.0 To: Ian Campbell <Ian.Campbell@citrix.com> Subject: Re: [Xen-devel] [PATCH 1 of 6] xenbackendd: fix incorrect usage of pidfile References: <patchbomb.1316692867@loki> <576c0ce336acb501cbba.1316692868@loki> <1316697823.23371.62.camel@zakaz.uk.xensource.com> In-Reply-To: <1316697823.23371.62.camel@zakaz.uk.xensource.com> Content-Type: text/plain; charset="UTF-8"; format=flowed Content-Transfer-Encoding: 7bit X-OriginatorOrg: amd.com Cc: Roger Pau Monne <roger.pau@entel.upc.edu>, "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com> X-BeenThere: xen-devel@lists.xensource.com X-Mailman-Version: 2.1.5 Precedence: list List-Id: Xen developer discussion <xen-devel.lists.xensource.com> List-Unsubscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe> List-Post: <mailto:xen-devel@lists.xensource.com> List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help> List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=subscribe> Sender: xen-devel-bounces@lists.xensource.com Errors-To: xen-devel-bounces@lists.xensource.com On 09/22/11 15:23, Ian Campbell wrote: > On Thu, 2011-09-22 at 13:01 +0100, Roger Pau Monne wrote: >> # HG changeset patch >> # User Roger Pau Monne<roger.pau@entel.upc.edu> >> # Date 1316692475 -7200 >> # Node ID 576c0ce336acb501cbba245dc801f06edc391479 >> # Parent a422e2a4451e16dc791b293f41966b842fa4781d >> xenbackendd: fix incorrect usage of pidfile >> >> Fix xenbackendd ignoring the pidfile passed through the command line. >> >> Signed-off-by: Roger Pau Monne<roger.pau@entel.upc.edu> > > Acked-by: Ian Campbell<ian.campbell@citrix.com> Acked-by: Christoph Egger <Christoph.Egger@amd.com> > >> >> diff -r a422e2a4451e -r 576c0ce336ac tools/xenbackendd/xenbackendd.c >> --- a/tools/xenbackendd/xenbackendd.c Sun Sep 18 00:26:52 2011 +0100 >> +++ b/tools/xenbackendd/xenbackendd.c Thu Sep 22 13:54:35 2011 +0200 >> @@ -169,7 +169,7 @@ main(int argc, char * const argv[]) >> log_file = optarg; >> break; >> case 'p': >> - pidfile = pidfile; >> + pidfile = optarg; >> case 's': >> vbd_script = optarg; >> break; >> -- ---to satisfy European Law for business letters: Advanced Micro Devices GmbH Einsteinring 24, 85689 Dornach b. Muenchen Geschaeftsfuehrer: Alberto Bozzo, Andrew Bowd Sitz: Dornach, Gemeinde Aschheim, Landkreis Muenchen Registergericht Muenchen, HRB Nr. 43632 _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel From xen-devel-bounces@lists.xensource.com Thu Sep 22 07:11:43 2011 Return-path: <xen-devel-bounces@lists.xensource.com> Envelope-to: www-data@lists.xensource.com Delivery-date: Thu, 22 Sep 2011 07:11:43 -0700 Received: from localhost ([127.0.0.1] helo=lists.colo.xensource.com) by lists.xensource.com with esmtp (Exim 4.43) id 1R6k07-0000bV-5z; Thu, 22 Sep 2011 07:11:43 -0700 Received: from mail182.messagelabs.com ([85.158.139.83]) by lists.xensource.com with esmtp (Exim 4.43) id 1R6jxN-0008S2-13 for xen-devel@lists.xensource.com; Thu, 22 Sep 2011 07:08:57 -0700 X-Env-Sender: Christoph.Egger@amd.com X-Msg-Ref: server-5.tower-182.messagelabs.com!1316700530!14371120!1 X-Originating-IP: [213.199.154.208] X-StarScan-Version: 6.4.1; banners=-,-,- X-VirusChecked: Checked Received: (qmail 7074 invoked from network); 22 Sep 2011 14:08:50 -0000 Received: from am1ehsobe005.messaging.microsoft.com (HELO AM1EHSOBE005.bigfish.com) (213.199.154.208) by server-5.tower-182.messagelabs.com with AES128-SHA encrypted SMTP; 22 Sep 2011 14:08:50 -0000 Received: from mail7-am1-R.bigfish.com (10.3.201.251) by AM1EHSOBE005.bigfish.com (10.3.204.25) with Microsoft SMTP Server id 14.1.225.22; Thu, 22 Sep 2011 14:08:49 +0000 Received: from mail7-am1 (localhost.localdomain [127.0.0.1]) by mail7-am1-R.bigfish.com (Postfix) with ESMTP id DE2C8107038F; Thu, 22 Sep 2011 14:08:49 +0000 (UTC) X-SpamScore: -14 X-BigFish: VPS-14(zzbb2dK936eK1432N98dKzz1202hzz8275bhz32i668h839h93fh) X-Forefront-Antispam-Report: CIP:163.181.249.108; KIP:(null); UIP:(null); IPVD:NLI; H:ausb3twp01.amd.com; RD:none; EFVD:NLI Received: from mail7-am1 (localhost.localdomain [127.0.0.1]) by mail7-am1 (MessageSwitch) id 1316700525281221_24757; Thu, 22 Sep 2011 14:08:45 +0000 (UTC) Received: from AM1EHSMHS003.bigfish.com (unknown [10.3.201.247]) by mail7-am1.bigfish.com (Postfix) with ESMTP id 3E85E398050; Thu, 22 Sep 2011 14:08:45 +0000 (UTC) Received: from ausb3twp01.amd.com (163.181.249.108) by AM1EHSMHS003.bigfish.com (10.3.207.103) with Microsoft SMTP Server id 14.1.225.22; Thu, 22 Sep 2011 14:08:09 +0000 X-WSS-ID: 0LRXGLF-01-BZW-02 X-M-MSG: Received: from sausexedgep02.amd.com (sausexedgep02-ext.amd.com [163.181.249.73]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by ausb3twp01.amd.com (Axway MailGate 3.8.1) with ESMTP id 20A5910282A6; Thu, 22 Sep 2011 09:08:02 -0500 (CDT) Received: from SAUSEXDAG04.amd.com (163.181.55.4) by sausexedgep02.amd.com (163.181.36.59) with Microsoft SMTP Server (TLS) id 8.3.106.1; Thu, 22 Sep 2011 09:08:21 -0500 Received: from storexhtp02.amd.com (172.24.4.4) by sausexdag04.amd.com (163.181.55.4) with Microsoft SMTP Server (TLS) id 14.1.289.1; Thu, 22 Sep 2011 09:08:06 -0500 Received: from rhodium.osrc.amd.com (165.204.15.173) by storexhtp02.amd.com (172.24.4.4) with Microsoft SMTP Server id 8.3.83.0; Thu, 22 Sep 2011 10:07:50 -0400 Message-ID: <4E7B4135.2030209@amd.com> Date: Thu, 22 Sep 2011 16:07:49 +0200 From: Christoph Egger <Christoph.Egger@amd.com> User-Agent: Mozilla/5.0 (X11; U; NetBSD amd64; en-US; rv:1.9.2.17) Gecko/20110523 Lightning/1.0b3pre Thunderbird/3.1.10 MIME-Version: 1.0 To: Ian Campbell <Ian.Campbell@citrix.com> Subject: Re: [Xen-devel] [PATCH 3 of 6] xenbackendd: pass type of block device to hotplug script References: <patchbomb.1316692867@loki> <2d77cbdc816bc943e9e6.1316692870@loki> <1316698516.23371.70.camel@zakaz.uk.xensource.com> In-Reply-To: <1316698516.23371.70.camel@zakaz.uk.xensource.com> Content-Type: text/plain; charset="UTF-8"; format=flowed Content-Transfer-Encoding: 7bit X-OriginatorOrg: amd.com Cc: Roger Pau Monne <roger.pau@entel.upc.edu>, "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com> X-BeenThere: xen-devel@lists.xensource.com X-Mailman-Version: 2.1.5 Precedence: list List-Id: Xen developer discussion <xen-devel.lists.xensource.com> List-Unsubscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe> List-Post: <mailto:xen-devel@lists.xensource.com> List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help> List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=subscribe> Sender: xen-devel-bounces@lists.xensource.com Errors-To: xen-devel-bounces@lists.xensource.com On 09/22/11 15:35, Ian Campbell wrote: > On Thu, 2011-09-22 at 13:01 +0100, Roger Pau Monne wrote: >> # HG changeset patch >> # User Roger Pau Monne<roger.pau@entel.upc.edu> >> # Date 1316692489 -7200 >> # Node ID 2d77cbdc816bc943e9e69ecca34ae7157079045a >> # Parent 1d3830f8a7306088b49d5732b5e88a73c2bc0315 >> xenbackendd: pass type of block device to hotplug script >> >> Pass the type of block device to attach to the block script instead of reading it from xenstore, since new Xen versions don't make a difference between a block device or an image. >> >> Signed-off-by: Roger Pau Monne<roger.pau@entel.upc.edu> > > I've not got any problem with this one, but I don't think my ACK is > worth much since it's NetBSD and I'm not really qualified, neverless: > > Acked-by: Ian Campbell<ian.campbell@citrix.com> Acked-by: Christoph Egger <Christoph.Egger@amd.com> >> >> diff -r 1d3830f8a730 -r 2d77cbdc816b tools/hotplug/NetBSD/block >> --- a/tools/hotplug/NetBSD/block Thu Sep 22 13:54:42 2011 +0200 >> +++ b/tools/hotplug/NetBSD/block Thu Sep 22 13:54:49 2011 +0200 >> @@ -19,7 +19,7 @@ error() { >> >> xpath=$1 >> xstatus=$2 >> -xtype=$(xenstore-read "$xpath/type") >> +xtype=$3 >> xparams=$(xenstore-read "$xpath/params") >> >> case $xstatus in >> diff -r 1d3830f8a730 -r 2d77cbdc816b tools/xenbackendd/xenbackendd.c >> --- a/tools/xenbackendd/xenbackendd.c Thu Sep 22 13:54:42 2011 +0200 >> +++ b/tools/xenbackendd/xenbackendd.c Thu Sep 22 13:54:49 2011 +0200 >> @@ -89,15 +89,15 @@ dodebug(const char *fmt, ...) >> } >> >> static void >> -doexec(const char *cmd, const char *arg1, const char *arg2) >> +doexec(const char *cmd, const char *arg1, const char *arg2, const char *arg3) >> { >> - dodebug("exec %s %s %s", cmd, arg1, arg2); >> + dodebug("exec %s %s %s %s", cmd, arg1, arg2, arg3); >> switch(vfork()) { >> case -1: >> dolog(LOG_ERR, "can't vfork: %s", strerror(errno)); >> break; >> case 0: >> - execl(cmd, cmd, arg1, arg2, NULL); >> + execl(cmd, cmd, arg1, arg2, arg3, NULL); >> dolog(LOG_ERR, "can't exec %s: %s", cmd, strerror(errno)); >> exit(EXIT_FAILURE); >> /* NOTREACHED */ >> @@ -145,11 +145,14 @@ xen_setup(void) >> int >> main(int argc, char * const argv[]) >> { >> + struct stat stab; >> char **vec; >> unsigned int num; >> char *s; >> int state; >> char *sstate; >> + char *stype; >> + char *params; >> char *p; >> char buf[80]; >> int type; >> @@ -297,11 +300,38 @@ main(int argc, char * const argv[]) >> strerror(errno)); >> goto next2; >> } >> - doexec(s, vec[XS_WATCH_PATH], sstate); >> + doexec(s, vec[XS_WATCH_PATH], sstate, NULL); >> break; >> >> case DEVTYPE_VBD: >> - doexec(vbd_script, vec[XS_WATCH_PATH], sstate); >> + /* check if given file is a block device or a raw image */ >> + snprintf(buf, sizeof(buf), "%s/params", vec[XS_WATCH_PATH]); >> + params = xs_read(xs, XBT_NULL, buf, 0); >> + if(params == NULL) { >> + dolog(LOG_ERR, >> + "Failed to read %s (%s)", buf, strerror(errno)); >> + goto next2; >> + } >> + if (stat(params,&stab)< 0) { >> + dolog(LOG_ERR, >> + "Failed to get info about %s (%s)", params, >> + strerror(errno)); >> + goto next3; >> + } >> + stype = NULL; >> + if (S_ISBLK(stab.st_mode)) >> + stype = "phy"; >> + if (S_ISREG(stab.st_mode)) >> + stype = "file"; >> + if (stype == NULL) { >> + dolog(LOG_ERR, >> + "Failed to attach %s (not a block device or raw image)", >> + params, strerror(errno)); >> + goto next3; >> + } >> + doexec(vbd_script, vec[XS_WATCH_PATH], sstate, stype); >> +next3: >> + free(params); >> break; >> >> default: >> -- ---to satisfy European Law for business letters: Advanced Micro Devices GmbH Einsteinring 24, 85689 Dornach b. Muenchen Geschaeftsfuehrer: Alberto Bozzo, Andrew Bowd Sitz: Dornach, Gemeinde Aschheim, Landkreis Muenchen Registergericht Muenchen, HRB Nr. 43632 _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel From xen-devel-bounces@lists.xensource.com Thu Sep 22 07:16:01 2011 Return-path: <xen-devel-bounces@lists.xensource.com> Envelope-to: www-data@lists.xensource.com Delivery-date: Thu, 22 Sep 2011 07:16:01 -0700 Received: from localhost ([127.0.0.1] helo=lists.colo.xensource.com) by lists.xensource.com with esmtp (Exim 4.43) id 1R6k4H-00011G-NU; Thu, 22 Sep 2011 07:16:01 -0700 Received: from mail21.messagelabs.com ([85.158.143.35]) by lists.xensource.com with esmtp (Exim 4.43) id 1R6k3i-0000pM-F5 for xen-devel@lists.xensource.com; Thu, 22 Sep 2011 07:15:26 -0700 X-Env-Sender: anthony.perard@gmail.com X-Msg-Ref: server-11.tower-21.messagelabs.com!1316700905!43583475!1 X-Originating-IP: [209.85.216.171] X-StarScan-Version: 6.4.1; banners=-,-,- X-VirusChecked: Checked Received: (qmail 5161 invoked from network); 22 Sep 2011 14:15:06 -0000 Received: from mail-qy0-f171.google.com (HELO mail-qy0-f171.google.com) (209.85.216.171) by server-11.tower-21.messagelabs.com with RC4-SHA encrypted SMTP; 22 Sep 2011 14:15:06 -0000 Received: by qyk29 with SMTP id 29so6119159qyk.9 for <xen-devel@lists.xensource.com>; Thu, 22 Sep 2011 07:15:22 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:sender:in-reply-to:references:from:date :x-google-sender-auth:message-id:subject:to:cc:content-type :content-transfer-encoding; bh=mbi8oX7aCicnsznTBwcsdk0aYqd/PsKPDIrRDkrdfbI=; b=BS55aHkDLkqT17KfYrhSLCNmPvBdtGbF1jddzp0s2xzeU7CFR2w5/ZJVaDCizvvFJi dr9J8xV13XAjvF3ADVqLPnImCOk3fdLctHCZHXYVPd9FFI7Vk5qk3n3UAkG1iahQsayX oWlbFf4nHcIuc2QNw3aFJy5MkdWWHkQjxQp4c= Received: by 10.224.218.138 with SMTP id hq10mr1821261qab.120.1316700922118; Thu, 22 Sep 2011 07:15:22 -0700 (PDT) MIME-Version: 1.0 Received: by 10.224.190.131 with HTTP; Thu, 22 Sep 2011 07:14:52 -0700 (PDT) In-Reply-To: <1316602822.3891.173.camel@zakaz.uk.xensource.com> References: <alpine.DEB.2.00.1109211051270.8700@kaball-desktop> <1316598917-21515-4-git-send-email-stefano.stabellini@eu.citrix.com> <1316602822.3891.173.camel@zakaz.uk.xensource.com> From: Anthony PERARD <anthony.perard@citrix.com> Date: Thu, 22 Sep 2011 15:14:52 +0100 X-Google-Sender-Auth: BcxDylqRtGSSuNacmq5q-9QHetE Message-ID: <CAJJyHjLkLTCAykvpDKw1FYQqquWu74xzotyXfZidtE_7KaSxTA@mail.gmail.com> Subject: Re: [Xen-devel] Re: [PATCH v5 4/4] Clone and build Seabios by default To: Ian Campbell <Ian.Campbell@eu.citrix.com> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Cc: Anthony PERARD <anthony.perard@citrix.com>, "keir@xen.org" <keir@xen.org>, "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>, Ian Jackson <Ian.Jackson@eu.citrix.com>, "stefano.stabellini@eu.citrix.com" <stefano.stabellini@eu.citrix.com> X-BeenThere: xen-devel@lists.xensource.com X-Mailman-Version: 2.1.5 Precedence: list List-Id: Xen developer discussion <xen-devel.lists.xensource.com> List-Unsubscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe> List-Post: <mailto:xen-devel@lists.xensource.com> List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help> List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=subscribe> Sender: xen-devel-bounces@lists.xensource.com Errors-To: xen-devel-bounces@lists.xensource.com On Wed, Sep 21, 2011 at 12:00, Ian Campbell <Ian.Campbell@eu.citrix.com> wr= ote: > On Wed, 2011-09-21 at 10:55 +0100, stefano.stabellini@eu.citrix.com > wrote: >> Signed-off-by: Stefano Stabellini <stefano.stabellini@eu.citrix.com> >> >> diff -r 9832a4edea7f .hgignore >> --- a/.hgignore =C2=A0 =C2=A0 =C2=A0 Thu Sep 15 14:25:11 2011 +0000 >> +++ b/.hgignore =C2=A0 =C2=A0 =C2=A0 Thu Sep 15 14:37:33 2011 +0000 >> @@ -295,6 +295,8 @@ >> =C2=A0^tools/qemu-xen-traditional-dir$ >> =C2=A0^tools/qemu-xen-dir-remote >> =C2=A0^tools/qemu-xen-dir$ >> +^tools/tools/firmware/seabios-dir-remote >> +^tools/tools/firmware/seabios-dir$ >> =C2=A0^tools/ocaml/.*/.*\.annot$ >> =C2=A0^tools/ocaml/.*/.*\.cmx?a$ >> =C2=A0^tools/ocaml/.*/META$ >> diff -r 9832a4edea7f Config.mk >> --- a/Config.mk =C2=A0 =C2=A0 =C2=A0 Thu Sep 15 14:25:11 2011 +0000 >> +++ b/Config.mk =C2=A0 =C2=A0 =C2=A0 Thu Sep 15 14:37:33 2011 +0000 >> @@ -199,6 +199,8 @@ else >> =C2=A0QEMU_UPSTREAM_URL ?=3D git://xenbits.xensource.com/qemu-upstream-u= nstable.git >> =C2=A0endif >> =C2=A0QEMU_UPSTREAM_TAG ?=3D 6dd84c71dff047f9e492d67e7c99928d09202760 >> +SEABIOS_UPSTREAM_URL ?=3D git://git.qemu.org/seabios.git > > I use git://git.seabios.org/seabios.git but I don't suppose there is > much distinction? > > More importantly does anyone know of an http mirror? I found this one: http://git.qemu.org/git/seabios.git --=20 Anthony PERARD _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel From xen-devel-bounces@lists.xensource.com Thu Sep 22 07:16:49 2011 Return-path: <xen-devel-bounces@lists.xensource.com> Envelope-to: www-data@lists.xensource.com Delivery-date: Thu, 22 Sep 2011 07:16:49 -0700 Received: from localhost ([127.0.0.1] helo=lists.colo.xensource.com) by lists.xensource.com with esmtp (Exim 4.43) id 1R6k53-0001OL-7l; Thu, 22 Sep 2011 07:16:49 -0700 Received: from mail174.messagelabs.com ([85.158.138.51]) by lists.xensource.com with esmtp (Exim 4.43) id 1R6k3m-0000pU-Ke for xen-devel@lists.xensource.com; Thu, 22 Sep 2011 07:15:31 -0700 X-Env-Sender: olaf@aepfle.de X-Msg-Ref: server-2.tower-174.messagelabs.com!1316700927!32385550!1 X-Originating-IP: [81.169.146.162] X-StarScan-Version: 6.4.1; banners=-,-,- X-VirusChecked: Checked Received: (qmail 26873 invoked from network); 22 Sep 2011 14:15:27 -0000 Received: from mo-p00-ob.rzone.de (HELO mo-p00-ob.rzone.de) (81.169.146.162) by server-2.tower-174.messagelabs.com with EDH-RSA-DES-CBC3-SHA encrypted SMTP; 22 Sep 2011 14:15:27 -0000 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; t=1316700927; l=701; s=domk; d=aepfle.de; h=References:In-Reply-To:Date:Subject:Cc:To:From:X-RZG-CLASS-ID: X-RZG-AUTH; bh=EyRrzv9A6J8KNLoTF+Ss3Zbk/Yc=; b=AbeWdYgToWqniMCm2uw6UTj6rDOJyLAYQilqVgGt9KwtFLqMK69u2xiygrAQI3Bhvjd bC9VUeuE+FCe3od8ywhloKvgFCQ59sksdyk4jWKYogaNFhylclG9yvG2CGtaMxJKgB16y XaZhs5NY8fHhnev2Z529kIYJuzvONS6OANI= X-RZG-AUTH: :P2EQZWCpfu+qG7CngxMFH1J+zrwiavkK6tmQaLfmztM8TOFPjDEQEiPVxA== X-RZG-CLASS-ID: mo00 Received: from probook.site (dslb-088-065-122-153.pools.arcor-ip.net [88.65.122.153]) by post.strato.de (mrclete mo38) (RZmta 26.7) with (EDH-RSA-DES-CBC3-SHA encrypted) ESMTPA id j02e2bn8MD1a2S ; Thu, 22 Sep 2011 16:15:18 +0200 (MEST) Received: by probook.site (Postfix, from userid 1000) id E79B918B65; Thu, 22 Sep 2011 16:15:17 +0200 (CEST) From: Olaf Hering <olaf@aepfle.de> To: linux-kernel@vger.kernel.org, Jeremy Fitzhardinge <jeremy@goop.org>, Konrad <konrad.wilk@oracle.com> Date: Thu, 22 Sep 2011 16:14:48 +0200 Message-Id: <1316700889-3518-2-git-send-email-olaf@aepfle.de> X-Mailer: git-send-email 1.7.3.4 In-Reply-To: <1316700889-3518-1-git-send-email-olaf@aepfle.de> References: <1316700889-3518-1-git-send-email-olaf@aepfle.de> Cc: xen-devel@lists.xensource.com Subject: [Xen-devel] [PATCH 1/2] xen/pv-on-hvm kexec: update xs_wire.h:xsd_sockmsg_type from xen-unstable X-BeenThere: xen-devel@lists.xensource.com X-Mailman-Version: 2.1.5 Precedence: list List-Id: Xen developer discussion <xen-devel.lists.xensource.com> List-Unsubscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe> List-Post: <mailto:xen-devel@lists.xensource.com> List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help> List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=subscribe> Sender: xen-devel-bounces@lists.xensource.com Errors-To: xen-devel-bounces@lists.xensource.com Update include/xen/interface/io/xs_wire.h from xen-unstable. Now entries in xsd_sockmsg_type were added. Signed-off-by: Olaf Hering <olaf@aepfle.de> --- include/xen/interface/io/xs_wire.h | 5 ++++- 1 files changed, 4 insertions(+), 1 deletions(-) diff --git a/include/xen/interface/io/xs_wire.h b/include/xen/interface/io/xs_wire.h index 99fcffb..f6f07aa 100644 --- a/include/xen/interface/io/xs_wire.h +++ b/include/xen/interface/io/xs_wire.h @@ -26,7 +26,10 @@ enum xsd_sockmsg_type XS_SET_PERMS, XS_WATCH_EVENT, XS_ERROR, - XS_IS_DOMAIN_INTRODUCED + XS_IS_DOMAIN_INTRODUCED, + XS_RESUME, + XS_SET_TARGET, + XS_RESTRICT }; #define XS_WRITE_NONE "NONE" -- 1.7.3.4 _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel From xen-devel-bounces@lists.xensource.com Thu Sep 22 07:17:58 2011 Return-path: <xen-devel-bounces@lists.xensource.com> Envelope-to: www-data@lists.xensource.com Delivery-date: Thu, 22 Sep 2011 07:17:58 -0700 Received: from localhost ([127.0.0.1] helo=lists.colo.xensource.com) by lists.xensource.com with esmtp (Exim 4.43) id 1R6k69-0001lX-St; Thu, 22 Sep 2011 07:17:57 -0700 Received: from mail27.messagelabs.com ([193.109.254.147]) by lists.xensource.com with esmtp (Exim 4.43) id 1R6k3m-0000pV-Ne for xen-devel@lists.xensource.com; Thu, 22 Sep 2011 07:15:31 -0700 X-Env-Sender: olaf@aepfle.de X-Msg-Ref: server-15.tower-27.messagelabs.com!1316700918!49849473!1 X-Originating-IP: [81.169.146.161] X-StarScan-Version: 6.4.1; banners=-,-,- X-VirusChecked: Checked Received: (qmail 16831 invoked from network); 22 Sep 2011 14:15:19 -0000 Received: from mo-p00-ob.rzone.de (HELO mo-p00-ob.rzone.de) (81.169.146.161) by server-15.tower-27.messagelabs.com with EDH-RSA-DES-CBC3-SHA encrypted SMTP; 22 Sep 2011 14:15:19 -0000 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; t=1316700927; l=790; s=domk; d=aepfle.de; h=Date:Subject:Cc:To:From:X-RZG-CLASS-ID:X-RZG-AUTH; bh=DLoRY5M/6Olqm2doBKUstujgT+U=; b=e98LbZZJ5Y9KWZ3VuhoVPngg3avjSQ4+4UPzMktSY09N+PTH8hupBIYDBjRXvJHyCHt KCFk8qQwncN4GUtyh4Tja1RrXUhUEKwV19WMEejU4yqZx9OWFY2zE7Sf1eQuBcpVpsvcN TAEJp8rQxfFLuU6ueTw75hhNolmMdVWPTho= X-RZG-AUTH: :P2EQZWCpfu+qG7CngxMFH1J+zrwiavkK6tmQaLfmztM8TOFPjDEQEiPVxA== X-RZG-CLASS-ID: mo00 Received: from probook.site (dslb-088-065-122-153.pools.arcor-ip.net [88.65.122.153]) by smtp.strato.de (fruni mo22) (RZmta 26.7) with (EDH-RSA-DES-CBC3-SHA encrypted) ESMTPA id R05f49n8MCrhQf ; Thu, 22 Sep 2011 16:15:03 +0200 (MEST) Received: by probook.site (Postfix, from userid 1000) id BF81718B65; Thu, 22 Sep 2011 16:15:02 +0200 (CEST) From: Olaf Hering <olaf@aepfle.de> To: linux-kernel@vger.kernel.org, Jeremy Fitzhardinge <jeremy@goop.org>, Konrad <konrad.wilk@oracle.com> Date: Thu, 22 Sep 2011 16:14:47 +0200 Message-Id: <1316700889-3518-1-git-send-email-olaf@aepfle.de> X-Mailer: git-send-email 1.7.3.4 Cc: xen-devel@lists.xensource.com Subject: [Xen-devel] [PATCH 0/2] reset xenstore watches to fix kexec in Xen PVonHVM guests X-BeenThere: xen-devel@lists.xensource.com X-Mailman-Version: 2.1.5 Precedence: list List-Id: Xen developer discussion <xen-devel.lists.xensource.com> List-Unsubscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe> List-Post: <mailto:xen-devel@lists.xensource.com> List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help> List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=subscribe> Sender: xen-devel-bounces@lists.xensource.com Errors-To: xen-devel-bounces@lists.xensource.com The following series improves kexec in a Xen PVonHVM guest. It is available via git: git://github.com/olafhering/linux.git xen-kexec-XS_RESET_WATCHES-3.0 A new xenstored command XS_RESET_WATCHES has been added in xen-unstable.hg changeset 23839:42a45baf037d. The command removes all watches and transactions for the guest. The following patches make use of the new command to wipe all existing watches during startup. Olaf Olaf Hering (2): xen/pv-on-hvm kexec: update xs_wire.h:xsd_sockmsg_type from xen-unstable xen/pv-on-hvm kexec: add xs_reset_watches to shutdown watches from old kernel drivers/xen/xenbus/xenbus_xs.c | 13 +++++++++++++ include/xen/interface/io/xs_wire.h | 6 +++++- 2 files changed, 18 insertions(+), 1 deletions(-) -- 1.7.3.4 _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel From xen-devel-bounces@lists.xensource.com Thu Sep 22 07:19:30 2011 Return-path: <xen-devel-bounces@lists.xensource.com> Envelope-to: www-data@lists.xensource.com Delivery-date: Thu, 22 Sep 2011 07:19:30 -0700 Received: from localhost ([127.0.0.1] helo=lists.colo.xensource.com) by lists.xensource.com with esmtp (Exim 4.43) id 1R6k7d-0002Eq-UW; Thu, 22 Sep 2011 07:19:30 -0700 Received: from mail216.messagelabs.com ([85.158.143.99]) by lists.xensource.com with esmtp (Exim 4.43) id 1R6k47-0000xA-HP for xen-devel@lists.xensource.com; Thu, 22 Sep 2011 07:15:51 -0700 X-Env-Sender: olaf@aepfle.de X-Msg-Ref: server-13.tower-216.messagelabs.com!1316700948!19250428!1 X-Originating-IP: [81.169.146.161] X-StarScan-Version: 6.4.1; banners=-,-,- X-VirusChecked: Checked Received: (qmail 18316 invoked from network); 22 Sep 2011 14:15:48 -0000 Received: from mo-p00-ob.rzone.de (HELO mo-p00-ob.rzone.de) (81.169.146.161) by server-13.tower-216.messagelabs.com with EDH-RSA-DES-CBC3-SHA encrypted SMTP; 22 Sep 2011 14:15:48 -0000 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; t=1316700948; l=2745; s=domk; d=aepfle.de; h=References:In-Reply-To:Date:Subject:Cc:To:From:X-RZG-CLASS-ID: X-RZG-AUTH; bh=W8ynzMdCv+aXmy7YBzDCfVlvvQY=; b=XyE+k7jpwBgqL8nF3ou0ppfdB1q8O6G77+yLJLk8cdkiLATel3AxmJ+nerImTjuCwRT xiY2B+Yk2UnJssXdObDkn4z1qZebdgt5NvnHaad/YHURy0nZcQDGXXBzK1OEiR401SByw vn88tUCThSCUrZpUgivkByjjfgf2Ux9IkAg= X-RZG-AUTH: :P2EQZWCpfu+qG7CngxMFH1J+zrwiavkK6tmQaLfmztM8TOFPjDEQEiPVxA== X-RZG-CLASS-ID: mo00 Received: from probook.site (dslb-088-065-122-153.pools.arcor-ip.net [88.65.122.153]) by post.strato.de (mrclete mo15) (RZmta 26.7) with (EDH-RSA-DES-CBC3-SHA encrypted) ESMTPA id U02156n8MDlvBX ; Thu, 22 Sep 2011 16:15:22 +0200 (MEST) Received: by probook.site (Postfix, from userid 1000) id F2B5718B65; Thu, 22 Sep 2011 16:15:21 +0200 (CEST) From: Olaf Hering <olaf@aepfle.de> To: linux-kernel@vger.kernel.org, Jeremy Fitzhardinge <jeremy@goop.org>, Konrad <konrad.wilk@oracle.com> Date: Thu, 22 Sep 2011 16:14:49 +0200 Message-Id: <1316700889-3518-3-git-send-email-olaf@aepfle.de> X-Mailer: git-send-email 1.7.3.4 In-Reply-To: <1316700889-3518-1-git-send-email-olaf@aepfle.de> References: <1316700889-3518-1-git-send-email-olaf@aepfle.de> Cc: xen-devel@lists.xensource.com Subject: [Xen-devel] [PATCH 2/2] xen/pv-on-hvm kexec: add xs_reset_watches to shutdown watches from old kernel X-BeenThere: xen-devel@lists.xensource.com X-Mailman-Version: 2.1.5 Precedence: list List-Id: Xen developer discussion <xen-devel.lists.xensource.com> List-Unsubscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe> List-Post: <mailto:xen-devel@lists.xensource.com> List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help> List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=subscribe> Sender: xen-devel-bounces@lists.xensource.com Errors-To: xen-devel-bounces@lists.xensource.com Add new xs_reset_watches function to shutdown watches from old kernel after kexec boot. The old kernel does not unregister all watches in the shutdown path. They are still active, the double registration can not be detected by the new kernel. When the watches fire, unexpected events will arrive and the xenwatch thread will crash (jumps to NULL). An orderly reboot of a hvm guest will destroy the entire guest with all its resources (including the watches) before it is rebuilt from scratch, so the missing unregister is not an issue in that case. With this change the xenstored is instructed to wipe all active watches for the guest. However, a patch for xenstored is required so that it accepts the XS_RESET_WATCHES request from a client (see changeset 23839:42a45baf037d in xen-unstable.hg). Without the patch for xenstored the registration of watches will fail and some features of a PVonHVM guest are not available. The guest is still able to boot, but repeated kexec boots will fail. v5: - use xs_single instead of passing a dummy string to xs_talkv v4: - ignore -EEXIST in xs_reset_watches v3: - use XS_RESET_WATCHES instead of XS_INTRODUCE v2: - move all code which deals with XS_INTRODUCE into xs_introduce() (based on feedback from Ian Campbell) - remove casts from kvec assignment Signed-off-by: Olaf Hering <olaf@aepfle.de> --- drivers/xen/xenbus/xenbus_xs.c | 13 +++++++++++++ include/xen/interface/io/xs_wire.h | 3 ++- 2 files changed, 15 insertions(+), 1 deletions(-) diff --git a/drivers/xen/xenbus/xenbus_xs.c b/drivers/xen/xenbus/xenbus_xs.c index 5534690..01bdb98 100644 --- a/drivers/xen/xenbus/xenbus_xs.c +++ b/drivers/xen/xenbus/xenbus_xs.c @@ -620,6 +620,15 @@ static struct xenbus_watch *find_watch(const char *token) return NULL; } +static void xs_reset_watches(void) +{ + int err; + + err = xs_error(xs_single(XBT_NIL, XS_RESET_WATCHES, "", NULL)); + if (err && err != -EEXIST) + printk(KERN_WARNING "xs_reset_watches failed: %d\n", err); +} + /* Register callback to watch this node. */ int register_xenbus_watch(struct xenbus_watch *watch) { @@ -897,5 +906,9 @@ int xs_init(void) if (IS_ERR(task)) return PTR_ERR(task); + /* shutdown watches for kexec boot */ + if (xen_hvm_domain()) + xs_reset_watches(); + return 0; } diff --git a/include/xen/interface/io/xs_wire.h b/include/xen/interface/io/xs_wire.h index f6f07aa..f0b6890 100644 --- a/include/xen/interface/io/xs_wire.h +++ b/include/xen/interface/io/xs_wire.h @@ -29,7 +29,8 @@ enum xsd_sockmsg_type XS_IS_DOMAIN_INTRODUCED, XS_RESUME, XS_SET_TARGET, - XS_RESTRICT + XS_RESTRICT, + XS_RESET_WATCHES }; #define XS_WRITE_NONE "NONE" -- 1.7.3.4 _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel From xen-devel-bounces@lists.xensource.com Thu Sep 22 07:33:56 2011 Return-path: <xen-devel-bounces@lists.xensource.com> Envelope-to: www-data@lists.xensource.com Delivery-date: Thu, 22 Sep 2011 07:33:56 -0700 Received: from localhost ([127.0.0.1] helo=lists.colo.xensource.com) by lists.xensource.com with esmtp (Exim 4.43) id 1R6kLc-00031E-Fc; Thu, 22 Sep 2011 07:33:56 -0700 Received: from mail216.messagelabs.com ([85.158.143.99]) by lists.xensource.com with smtp (Exim 4.43) id 1R6kKh-0002fJ-NT for xen-devel@lists.xensource.com; Thu, 22 Sep 2011 07:33:02 -0700 X-Env-Sender: stefan.bader@canonical.com X-Msg-Ref: server-2.tower-216.messagelabs.com!1316701976!18804841!1 X-Originating-IP: [91.189.89.112] X-StarScan-Version: 6.4.1; banners=-,-,- X-VirusChecked: Checked Received: (qmail 32298 invoked from network); 22 Sep 2011 14:32:56 -0000 Received: from youngberry.canonical.com (HELO youngberry.canonical.com) (91.189.89.112) by server-2.tower-216.messagelabs.com with SMTP; 22 Sep 2011 14:32:56 -0000 Received: from p5b2e42b8.dip.t-dialin.net ([91.46.66.184] helo=[192.168.2.5]) by youngberry.canonical.com with esmtpsa (TLS1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.71) (envelope-from <stefan.bader@canonical.com>) id 1R6kKe-0002U3-6J for xen-devel@lists.xensource.com; Thu, 22 Sep 2011 14:32:56 +0000 Message-ID: <4E7B4716.1050108@canonical.com> Date: Thu, 22 Sep 2011 16:32:54 +0200 From: Stefan Bader <stefan.bader@canonical.com> User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.2.21) Gecko/20110831 Lightning/1.0b2 Thunderbird/3.1.13 MIME-Version: 1.0 To: xen-devel@lists.xensource.com Subject: Re: [Xen-devel] Re: Still struggling with HVM: tx timeouts on emulated nics References: <4E79E08D.1090503@canonical.com> <alpine.DEB.2.00.1109211422180.8700@kaball-desktop> <4E7A0410.7050405@canonical.com> <alpine.DEB.2.00.1109221128120.8700@kaball-desktop> <4E7B2301.1050004@canonical.com> In-Reply-To: <4E7B2301.1050004@canonical.com> X-Enigmail-Version: 1.1.2 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-BeenThere: xen-devel@lists.xensource.com X-Mailman-Version: 2.1.5 Precedence: list List-Id: Xen developer discussion <xen-devel.lists.xensource.com> List-Unsubscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe> List-Post: <mailto:xen-devel@lists.xensource.com> List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help> List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=subscribe> Sender: xen-devel-bounces@lists.xensource.com Errors-To: xen-devel-bounces@lists.xensource.com On 22.09.2011 13:58, Stefan Bader wrote: > On 22.09.2011 12:30, Stefano Stabellini wrote: >> On Wed, 21 Sep 2011, Stefan Bader wrote: >>> On 21.09.2011 15:31, Stefano Stabellini wrote: >>>> On Wed, 21 Sep 2011, Stefan Bader wrote: >>>>> This is on 3.0.4 based dom0 and domU with 4.1.1 hypervisor. I tried using the >>>>> default 8139cp and ne2k_pci emulated nic. The 8139cp one at least comes up and >>>>> gets configured via dhcp. And initial pings also get routed and done correctly. >>>>> But slightly higher traffic (like checking for updates) hangs. And after a while >>>>> there are messages about tx timeouts. >>>>> The ne2k_pci type nic almost immediately has those issues and never comes up >>>>> correctly. >>>>> >>>>> I am attaching the dmesg of the guest with apic=debug enabled. I am not sure how >>>>> this should be but both nics get configured with level,low IRQs. Disk emulation >>>>> seems to be ok but that seem to use IO-APIC-edge. And any other IRQs seem to be >>>>> at least not level. >>>> >>> >>>> Does the e1000 emulated card work correctly? >>> >>> Yes, that one seems to work ok. >>> >>>> What happens if you disable interrupt remapping (see patch below)? >>> >>> 8139cp seems to work correctly now (much higher irq stats as well) and e1000 >>> still works. Both then using IOAPIC-fasteoi. >>> >> >> That means there must be another subtle bug in Xen in interrupt >> remapping that only affects 8139p emulation >> > Right, or to be complete: > - e1000: ok > - 8139cp: unstable (setup is possible) > - ne2k_pci: not working (tx problems from the beginning) > > The behaviour feels a bit like interrupts may get lost if occurring at a higher > rate. Why this affects various drivers differently is a bit weird. >> This is mainly speculating... Quite a while back there was this patch to events: commit dffe2e1e1a1ddb566a76266136c312801c66dcf7 Author: Jeremy Fitzhardinge <jeremy.fitzhardinge@citrix.com> Date: Fri Aug 20 19:10:01 2010 -0700 xen: handle events as edge-triggered The commit message stated that Xen events are logically edge triggered. So PV events were changed to be handled as edge interrupts. Would that not mean that for xen-pirq-apic being using events this would apply the same and those should be apic-edge instead of level? >>>>> Another problem came up recently though that may just be me doing the wrong >>>>> thing. Normally I boot with xen_emul_unplug=unnecessary as I want the emulated >>>>> devices. xen-blkfront is a module in my case and I thought I once had been able >>>>> to use that by removing the unplug arg and making the blkfront driver load. But >>>>> when I recently tried the module loaded but no disks appeared... Again, not sure >>>>> I just forgot how to do that right or that was different when using a 4.1.0 >>>>> hypervisor still... >>>> >>>> xen_emul_unplug=unnecessary allows the kernel to use PV interfaces on >>>> older hypervisors that didn't support the unplug protocol and had other >>>> ways to cope with multiple drivers accessing the same devices. >>>> You can use xen_emul_unplug=never to prevent any unplug but you won't >>>> get any PV interfaces. >>> >>> Hm, odd. Somehow I thought that I had been using pv interfaces that way when the >>> interrupts for the emulated ide was broken. >>> A bit suboptimal atm, because without any option and a kernel compiled with the >>> platform pci and pv drivers (as modules) booting in HVM mode the kernel decides >>> that having both is no use and unplugs the emulated devices. Which then leaves >>> you with ... none. >> >> In theory you would have the PV frontend modules in the initrd. >> On the other hand having both can easily cause data corruptions on your >> drive. > > They _are_ in the initrd. And the boot rightfully drops to a maintenance shell > right now (without any argument and the emulated devices unplugged). And > "modprobe xen-blkfront" loads the module but it does _not_ detect any pv device. > > -Stefan > > _______________________________________________ > Xen-devel mailing list > Xen-devel@lists.xensource.com > http://lists.xensource.com/xen-devel _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel From xen-devel-bounces@lists.xensource.com Thu Sep 22 08:17:39 2011 Return-path: <xen-devel-bounces@lists.xensource.com> Envelope-to: www-data@lists.xensource.com Delivery-date: Thu, 22 Sep 2011 08:17:39 -0700 Received: from localhost ([127.0.0.1] helo=lists.colo.xensource.com) by lists.xensource.com with esmtp (Exim 4.43) id 1R6l1v-0004lk-6Z; Thu, 22 Sep 2011 08:17:39 -0700 Received: from mail182.messagelabs.com ([85.158.139.83]) by lists.xensource.com with esmtp (Exim 4.43) id 1R6l0o-0004ZC-58 for xen-devel@lists.xensource.com; Thu, 22 Sep 2011 08:16:31 -0700 X-Env-Sender: JBeulich@suse.com X-Msg-Ref: server-15.tower-182.messagelabs.com!1316704586!18356747!1 X-Originating-IP: [130.57.49.28] X-StarScan-Version: 6.4.1; banners=-,-,- X-VirusChecked: Checked Received: (qmail 479 invoked from network); 22 Sep 2011 15:16:26 -0000 Received: from nat28.tlf.novell.com (HELO nat28.tlf.novell.com) (130.57.49.28) by server-15.tower-182.messagelabs.com with DHE-RSA-AES256-SHA encrypted SMTP; 22 Sep 2011 15:16:26 -0000 Received: from EMEA1-MTA by nat28.tlf.novell.com with Novell_GroupWise; Thu, 22 Sep 2011 16:16:26 +0100 Message-Id: <4E7B6D8402000078000575EC@nat28.tlf.novell.com> X-Mailer: Novell GroupWise Internet Agent 8.0.1 Date: Thu, 22 Sep 2011 16:16:52 +0100 From: "Jan Beulich" <JBeulich@suse.com> To: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com> Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="=__Part78574074.0__=" Cc: lasse.collin@tukaani.org Subject: [Xen-devel] [PATCH] XZ decompressor: Fix decoding of empty LZMA2 streams X-BeenThere: xen-devel@lists.xensource.com X-Mailman-Version: 2.1.5 Precedence: list List-Id: Xen developer discussion <xen-devel.lists.xensource.com> List-Unsubscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe> List-Post: <mailto:xen-devel@lists.xensource.com> List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help> List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=subscribe> Sender: xen-devel-bounces@lists.xensource.com Errors-To: xen-devel-bounces@lists.xensource.com This is a MIME message. If you are reading this text, you may want to consider changing to a mail reader or gateway that understands how to properly handle MIME multipart messages. --=__Part78574074.0__= Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: quoted-printable Content-Disposition: inline From: Lasse Collin <lasse.collin@tukaani.org> The old code considered valid empty LZMA2 streams to be corrupt. Note that a typical empty .xz file has no LZMA2 data at all, and thus most .xz files having no uncompressed data are handled correctly even without this fix. Signed-off-by: Lasse Collin <lasse.collin@tukaani.org> Signed-off-by: Jan Beulich <jbeulich@suse.com> --- a/xen/common/xz/dec_lzma2.c +++ b/xen/common/xz/dec_lzma2.c @@ -969,6 +969,9 @@ XZ_EXTERN enum xz_ret INIT xz_dec_lzma2_ */ tmp =3D b->in[b->in_pos++]; =20 + if (tmp =3D=3D 0x00) + return XZ_STREAM_END; + if (tmp >=3D 0xE0 || tmp =3D=3D 0x01) { s->lzma2.need_props =3D true; s->lzma2.need_dict_reset =3D false; @@ -1001,9 +1004,6 @@ XZ_EXTERN enum xz_ret INIT xz_dec_lzma2_ lzma_reset(s); } } else { - if (tmp =3D=3D 0x00) - return XZ_STREAM_END; - if (tmp > 0x02) return XZ_DATA_ERROR; =20 --=__Part78574074.0__= Content-Type: text/plain; name="xz-decode-empty.patch" Content-Transfer-Encoding: quoted-printable Content-Disposition: attachment; filename="xz-decode-empty.patch" From: Lasse Collin <lasse.collin@tukaani.org>=0ASubject: XZ decompressor: = Fix decoding of empty LZMA2 streams=0A=0AThe old code considered valid = empty LZMA2 streams to be corrupt.=0ANote that a typical empty .xz file = has no LZMA2 data at all,=0Aand thus most .xz files having no uncompressed = data are handled=0Acorrectly even without this fix.=0A=0ASigned-off-by: = Lasse Collin <lasse.collin@tukaani.org>=0ASigned-off-by: Jan Beulich = <jbeulich@suse.com>=0A=0A--- a/xen/common/xz/dec_lzma2.c=0A+++ b/xen/common= /xz/dec_lzma2.c=0A@@ -969,6 +969,9 @@ XZ_EXTERN enum xz_ret INIT xz_dec_lzm= a2_=0A */=0A tmp =3D b->in[b->in_pos++];= =0A =0A+ if (tmp =3D=3D 0x00)=0A+ = return XZ_STREAM_END;=0A+=0A if (tmp >=3D 0xE0 = || tmp =3D=3D 0x01) {=0A s->lzma2.need_props= =3D true;=0A s->lzma2.need_dict_reset =3D = false;=0A@@ -1001,9 +1004,6 @@ XZ_EXTERN enum xz_ret INIT xz_dec_lzma2_=0A = lzma_reset(s);=0A = }=0A } else {=0A- = if (tmp =3D=3D 0x00)=0A- return = XZ_STREAM_END;=0A-=0A if (tmp > 0x02)=0A = return XZ_DATA_ERROR;=0A =0A --=__Part78574074.0__= Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel --=__Part78574074.0__=-- From xen-devel-bounces@lists.xensource.com Thu Sep 22 08:19:02 2011 Return-path: <xen-devel-bounces@lists.xensource.com> Envelope-to: www-data@lists.xensource.com Delivery-date: Thu, 22 Sep 2011 08:19:02 -0700 Received: from localhost ([127.0.0.1] helo=lists.colo.xensource.com) by lists.xensource.com with esmtp (Exim 4.43) id 1R6l3F-000595-Uu; Thu, 22 Sep 2011 08:19:01 -0700 Received: from mail182.messagelabs.com ([85.158.139.83]) by lists.xensource.com with esmtp (Exim 4.43) id 1R6l1Z-0004g3-8j for xen-devel@lists.xensource.com; Thu, 22 Sep 2011 08:17:18 -0700 X-Env-Sender: JBeulich@suse.com X-Msg-Ref: server-15.tower-182.messagelabs.com!1316704633!18356926!1 X-Originating-IP: [130.57.49.28] X-StarScan-Version: 6.4.1; banners=-,-,- X-VirusChecked: Checked Received: (qmail 3324 invoked from network); 22 Sep 2011 15:17:14 -0000 Received: from nat28.tlf.novell.com (HELO nat28.tlf.novell.com) (130.57.49.28) by server-15.tower-182.messagelabs.com with DHE-RSA-AES256-SHA encrypted SMTP; 22 Sep 2011 15:17:14 -0000 Received: from EMEA1-MTA by nat28.tlf.novell.com with Novell_GroupWise; Thu, 22 Sep 2011 16:17:13 +0100 Message-Id: <4E7B6DB302000078000575F0@nat28.tlf.novell.com> X-Mailer: Novell GroupWise Internet Agent 8.0.1 Date: Thu, 22 Sep 2011 16:17:39 +0100 From: "Jan Beulich" <JBeulich@suse.com> To: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com> Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="=__Part8FA0B783.0__=" Cc: lasse.collin@tukaani.org Subject: [Xen-devel] [PATCH] XZ: Fix incorrect XZ_BUF_ERROR X-BeenThere: xen-devel@lists.xensource.com X-Mailman-Version: 2.1.5 Precedence: list List-Id: Xen developer discussion <xen-devel.lists.xensource.com> List-Unsubscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe> List-Post: <mailto:xen-devel@lists.xensource.com> List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help> List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=subscribe> Sender: xen-devel-bounces@lists.xensource.com Errors-To: xen-devel-bounces@lists.xensource.com This is a MIME message. If you are reading this text, you may want to consider changing to a mail reader or gateway that understands how to properly handle MIME multipart messages. --=__Part8FA0B783.0__= Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: quoted-printable Content-Disposition: inline From: Lasse Collin <lasse.collin@tukaani.org> xz_dec_run() could incorrectly return XZ_BUF_ERROR if all of the following was true: - The caller knows how many bytes of output to expect and only provides that much output space. - When the last output bytes are decoded, the caller-provided input buffer ends right before the LZMA2 end of payload marker. So LZMA2 won't provide more output anymore, but it won't know it yet and thus won't return XZ_STREAM_END yet. - A BCJ filter is in use and it hasn't left any unfiltered bytes in the temp buffer. This can happen with any BCJ filter, but in practice it's more likely with filters other than the x86 BCJ. This fixes <https://bugzilla.redhat.com/show_bug.cgi?id=3D735408> where Squashfs thinks that a valid file system is corrupt. This also fixes a similar bug in single-call mode where the uncompressed size of a block using BCJ + LZMA2 was 0 bytes and caller provided no output space. Many empty .xz files don't contain any blocks and thus don't trigger this bug. This also tweaks a closely related detail: xz_dec_bcj_run() could call xz_dec_lzma2_run() to decode into temp buffer when it was known to be useless. This was harmless although it wasted a minuscule number of CPU cycles. Signed-off-by: Lasse Collin <lasse.collin@tukaani.org> Signed-off-by: Jan Beulich <jbeulich@suse.com> --- a/xen/common/xz/dec_bcj.c +++ b/xen/common/xz/dec_bcj.c @@ -441,8 +441,12 @@ XZ_EXTERN enum xz_ret INIT xz_dec_bcj_ru * next filter in the chain. Apply the BCJ filter on the new data * in the output buffer. If everything cannot be filtered, copy it * to temp and rewind the output buffer position accordingly. + * + * This needs to be always run when temp.size =3D=3D 0 to handle a = special + * case where the output buffer is full and the next filter has no + * more output coming but hasn't returned XZ_STREAM_END yet. */ - if (s->temp.size < b->out_size - b->out_pos) { + if (s->temp.size < b->out_size - b->out_pos || s->temp.size =3D=3D = 0) { out_start =3D b->out_pos; memcpy(b->out + b->out_pos, s->temp.buf, s->temp.size); b->out_pos +=3D s->temp.size; @@ -465,16 +469,25 @@ XZ_EXTERN enum xz_ret INIT xz_dec_bcj_ru s->temp.size =3D b->out_pos - out_start; b->out_pos -=3D s->temp.size; memcpy(s->temp.buf, b->out + b->out_pos, s->temp.size); + + /* + * If there wasn't enough input to the next filter to fill + * the output buffer with unfiltered data, there's no = point + * to try decoding more data to temp. + */ + if (b->out_pos + s->temp.size < b->out_size) + return XZ_OK; } =20 /* - * If we have unfiltered data in temp, try to fill by decoding = more - * data from the next filter. Apply the BCJ filter on temp. Then = we - * hopefully can fill the actual output buffer by copying filtered - * data from temp. A mix of filtered and unfiltered data may be = left - * in temp; it will be taken care on the next call to this = function. + * We have unfiltered data in temp. If the output buffer isn't = full + * yet, try to fill the temp buffer by decoding more data from the + * next filter. Apply the BCJ filter on temp. Then we hopefully = can + * fill the actual output buffer by copying filtered data from = temp. + * A mix of filtered and unfiltered data may be left in temp; it = will + * be taken care on the next call to this function. */ - if (s->temp.size > 0) { + if (b->out_pos < b->out_size) { /* Make b->out{,_pos,_size} temporarily point to s->temp. = */ s->out =3D b->out; s->out_pos =3D b->out_pos; --=__Part8FA0B783.0__= Content-Type: text/plain; name="xz-fix-incorrect-xz_buf_error.patch" Content-Transfer-Encoding: quoted-printable Content-Disposition: attachment; filename="xz-fix-incorrect-xz_buf_error.patch" From: Lasse Collin <lasse.collin@tukaani.org>=0ASubject: XZ: Fix incorrect = XZ_BUF_ERROR=0A=0Axz_dec_run() could incorrectly return XZ_BUF_ERROR if = all of the=0Afollowing was true:=0A=0A - The caller knows how many bytes = of output to expect and only provides=0A that much output space.=0A=0A - = When the last output bytes are decoded, the caller-provided input=0A = buffer ends right before the LZMA2 end of payload marker. So LZMA2=0A = won't provide more output anymore, but it won't know it yet and thus=0A = won't return XZ_STREAM_END yet.=0A=0A - A BCJ filter is in use and it = hasn't left any unfiltered bytes in the=0A temp buffer. This can happen = with any BCJ filter, but in practice=0A it's more likely with filters = other than the x86 BCJ.=0A=0AThis fixes <https://bugzilla.redhat.com/show_b= ug.cgi?id=3D735408> where=0ASquashfs thinks that a valid file system is = corrupt.=0A=0AThis also fixes a similar bug in single-call mode where the = uncompressed=0Asize of a block using BCJ + LZMA2 was 0 bytes and caller = provided no=0Aoutput space. Many empty .xz files don't contain any blocks = and thus=0Adon't trigger this bug.=0A=0AThis also tweaks a closely related = detail: xz_dec_bcj_run() could call=0Axz_dec_lzma2_run() to decode into = temp buffer when it was known to be=0Auseless. This was harmless although = it wasted a minuscule number of CPU=0Acycles.=0A=0ASigned-off-by: Lasse = Collin <lasse.collin@tukaani.org>=0ASigned-off-by: Jan Beulich <jbeulich@su= se.com>=0A=0A--- a/xen/common/xz/dec_bcj.c=0A+++ b/xen/common/xz/dec_bcj.c= =0A@@ -441,8 +441,12 @@ XZ_EXTERN enum xz_ret INIT xz_dec_bcj_ru=0A * = next filter in the chain. Apply the BCJ filter on the new data=0A * = in the output buffer. If everything cannot be filtered, copy it=0A * = to temp and rewind the output buffer position accordingly.=0A+ *=0A+ * = This needs to be always run when temp.size =3D=3D 0 to handle a special=0A+= * case where the output buffer is full and the next filter has = no=0A+ * more output coming but hasn't returned XZ_STREAM_END yet.=0A = */=0A- if (s->temp.size < b->out_size - b->out_pos) {=0A+ if = (s->temp.size < b->out_size - b->out_pos || s->temp.size =3D=3D 0) {=0A = out_start =3D b->out_pos;=0A memcpy(b->out + b->out_pos,= s->temp.buf, s->temp.size);=0A b->out_pos +=3D s->temp.siz= e;=0A@@ -465,16 +469,25 @@ XZ_EXTERN enum xz_ret INIT xz_dec_bcj_ru=0A = s->temp.size =3D b->out_pos - out_start;=0A b->out_pos -=3D = s->temp.size;=0A memcpy(s->temp.buf, b->out + b->out_pos, = s->temp.size);=0A+=0A+ /*=0A+ * If there wasn't enough = input to the next filter to fill=0A+ * the output buffer with = unfiltered data, there's no point=0A+ * to try decoding more = data to temp.=0A+ */=0A+ if (b->out_pos + s->temp.si= ze < b->out_size)=0A+ return XZ_OK;=0A }=0A =0A = /*=0A- * If we have unfiltered data in temp, try to fill by decoding = more=0A- * data from the next filter. Apply the BCJ filter on = temp. Then we=0A- * hopefully can fill the actual output buffer by = copying filtered=0A- * data from temp. A mix of filtered and unfiltered= data may be left=0A- * in temp; it will be taken care on the next call = to this function.=0A+ * We have unfiltered data in temp. If the output = buffer isn't full=0A+ * yet, try to fill the temp buffer by decoding = more data from the=0A+ * next filter. Apply the BCJ filter on temp. Then = we hopefully can=0A+ * fill the actual output buffer by copying = filtered data from temp.=0A+ * A mix of filtered and unfiltered data = may be left in temp; it will=0A+ * be taken care on the next call = to this function.=0A */=0A- if (s->temp.size > 0) {=0A+ if = (b->out_pos < b->out_size) {=0A /* Make b->out{,_pos,_size}= temporarily point to s->temp. */=0A s->out =3D b->out;=0A = s->out_pos =3D b->out_pos;=0A --=__Part8FA0B783.0__= Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel --=__Part8FA0B783.0__=-- From xen-devel-bounces@lists.xensource.com Thu Sep 22 08:20:33 2011 Return-path: <xen-devel-bounces@lists.xensource.com> Envelope-to: www-data@lists.xensource.com Delivery-date: Thu, 22 Sep 2011 08:20:33 -0700 Received: from localhost ([127.0.0.1] helo=lists.colo.xensource.com) by lists.xensource.com with esmtp (Exim 4.43) id 1R6l4j-0005cp-OY; Thu, 22 Sep 2011 08:20:33 -0700 Received: from mail182.messagelabs.com ([85.158.139.83]) by lists.xensource.com with esmtp (Exim 4.43) id 1R6l2x-00056g-Sq for xen-devel@lists.xensource.com; Thu, 22 Sep 2011 08:18:46 -0700 X-Env-Sender: JBeulich@suse.com X-Msg-Ref: server-10.tower-182.messagelabs.com!1316704720!19349441!1 X-Originating-IP: [130.57.49.28] X-StarScan-Version: 6.4.1; banners=-,-,- X-VirusChecked: Checked Received: (qmail 28989 invoked from network); 22 Sep 2011 15:18:40 -0000 Received: from nat28.tlf.novell.com (HELO nat28.tlf.novell.com) (130.57.49.28) by server-10.tower-182.messagelabs.com with DHE-RSA-AES256-SHA encrypted SMTP; 22 Sep 2011 15:18:40 -0000 Received: from EMEA1-MTA by nat28.tlf.novell.com with Novell_GroupWise; Thu, 22 Sep 2011 16:18:40 +0100 Message-Id: <4E7B6E0B0200007800057603@nat28.tlf.novell.com> X-Mailer: Novell GroupWise Internet Agent 8.0.1 Date: Thu, 22 Sep 2011 16:19:07 +0100 From: "Jan Beulich" <JBeulich@suse.com> To: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com> Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="=__PartF7D8CFFB.1__=" Cc: herrmann.der.user@googlemail.com, Thomas Renninger <trenn@suse.de> Subject: [Xen-devel] [PATCH] x86: ucode-amd: Don't warn when no ucode is available for a CPU revision X-BeenThere: xen-devel@lists.xensource.com X-Mailman-Version: 2.1.5 Precedence: list List-Id: Xen developer discussion <xen-devel.lists.xensource.com> List-Unsubscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe> List-Post: <mailto:xen-devel@lists.xensource.com> List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help> List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=subscribe> Sender: xen-devel-bounces@lists.xensource.com Errors-To: xen-devel-bounces@lists.xensource.com This is a MIME message. If you are reading this text, you may want to consider changing to a mail reader or gateway that understands how to properly handle MIME multipart messages. --=__PartF7D8CFFB.1__= Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: quoted-printable Content-Disposition: inline This patch originally comes from the Linus mainline kernel (2.6.33), find below the patch details: From: Andreas Herrmann <herrmann.der.user@googlemail.com> There is no point in warning when there is no ucode available for a specific CPU revision. Currently the container-file, which provides the AMD ucode patches for OS load, contains only a few ucode patches. It's already clearly indicated by the printed patch_level whenever new ucode was available and an update happened. So the warning message is of no help but rather annoying on systems with many CPUs. Signed-off-by: Thomas Renninger <trenn@suse.de> Signed-off-by: Jan Beulich <jbeulich@suse.com> --- a/xen/arch/x86/microcode_amd.c +++ b/xen/arch/x86/microcode_amd.c @@ -96,11 +96,7 @@ static int microcode_fits(void *mc, int=20 } =20 if ( !equiv_cpu_id ) - { - printk(KERN_ERR "microcode: CPU%d cpu_id " - "not found in equivalent cpu table\n", cpu); - return -EINVAL; - } + return 0; =20 if ( (mc_header->processor_rev_id) !=3D equiv_cpu_id ) { --=__PartF7D8CFFB.1__= Content-Type: text/plain; name="x86-microcode-amd-silent.patch" Content-Transfer-Encoding: quoted-printable Content-Disposition: attachment; filename="x86-microcode-amd-silent.patch" This patch originally comes from the Linus mainline kernel (2.6.33),=0Afind= below the patch details:=0A=0AFrom: Andreas Herrmann <herrmann.der.user@go= oglemail.com>=0ASubject: x86: ucode-amd: Don't warn when no ucode is = available for a CPU revision=0A=0AThere is no point in warning when there = is no ucode available=0Afor a specific CPU revision. Currently the = container-file, which=0Aprovides the AMD ucode patches for OS load, = contains only a few=0Aucode patches.=0A=0AIt's already clearly indicated = by the printed patch_level=0Awhenever new ucode was available and an = update happened. So the=0Awarning message is of no help but rather = annoying on systems=0Awith many CPUs.=0A=0ASigned-off-by: Thomas Renninger = <trenn@suse.de>=0ASigned-off-by: Jan Beulich <jbeulich@suse.com>=0A=0A--- = a/xen/arch/x86/microcode_amd.c=0A+++ b/xen/arch/x86/microcode_amd.c=0A@@ = -96,11 +96,7 @@ static int microcode_fits(void *mc, int =0A }=0A =0A = if ( !equiv_cpu_id )=0A- {=0A- printk(KERN_ERR "microcode: = CPU%d cpu_id "=0A- "not found in equivalent cpu table\n", = cpu);=0A- return -EINVAL;=0A- }=0A+ return 0;=0A =0A = if ( (mc_header->processor_rev_id) !=3D equiv_cpu_id )=0A {=0A --=__PartF7D8CFFB.1__= Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel --=__PartF7D8CFFB.1__=-- From xen-devel-bounces@lists.xensource.com Thu Sep 22 09:33:42 2011 Return-path: <xen-devel-bounces@lists.xensource.com> Envelope-to: www-data@lists.xensource.com Delivery-date: Thu, 22 Sep 2011 09:33:42 -0700 Received: from localhost ([127.0.0.1] helo=lists.colo.xensource.com) by lists.xensource.com with esmtp (Exim 4.43) id 1R6mDW-0007PD-Ke; Thu, 22 Sep 2011 09:33:42 -0700 Received: from mail21.messagelabs.com ([85.158.143.35]) by lists.xensource.com with esmtp (Exim 4.43) id 1R6mCg-0007Bi-5C; Thu, 22 Sep 2011 09:32:50 -0700 X-Env-Sender: dunlapg@gmail.com X-Msg-Ref: server-12.tower-21.messagelabs.com!1316709151!50959715!1 X-Originating-IP: [74.125.82.43] X-StarScan-Version: 6.4.1; banners=-,-,- X-VirusChecked: Checked Received: (qmail 9812 invoked from network); 22 Sep 2011 16:32:31 -0000 Received: from mail-ww0-f43.google.com (HELO mail-ww0-f43.google.com) (74.125.82.43) by server-12.tower-21.messagelabs.com with RC4-SHA encrypted SMTP; 22 Sep 2011 16:32:31 -0000 Received: by wwf27 with SMTP id 27so2052930wwf.24 for <multiple recipients>; Thu, 22 Sep 2011 09:32:46 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type; bh=NiHIzUI/6zNLBbfyIiTQzwoh1xm+e1Krq5T5IYisNGE=; b=GAKCjKSc1jC7dv49i9BV60PjD/xdQmCUHsAhWwIV+RNRE5TFO60mWDT5DM89pIRi9V o6oe8RDp/mfQTV0EvKG+hTdsSCHDSGG04TwI9Asj7ZvUh8QQXZ4melObY3PuNcKiev5G tZEU2N+3CfIA5sZUADyh3++yoFn7eV+tnCXBE= MIME-Version: 1.0 Received: by 10.216.137.94 with SMTP id x72mr2817789wei.9.1316709166512; Thu, 22 Sep 2011 09:32:46 -0700 (PDT) Received: by 10.216.176.81 with HTTP; Thu, 22 Sep 2011 09:32:46 -0700 (PDT) In-Reply-To: <20110922130618.GA13238@phenom.oracle.com> References: <20110922130618.GA13238@phenom.oracle.com> Date: Thu, 22 Sep 2011 17:32:46 +0100 X-Google-Sender-Auth: pdEXCPi5HCCh9af6TmJVrFtUyvk Message-ID: <CAFLBxZaAaXTUtW5+VkxPnr_MR0fbW+d1Mzu4y0x=gEOaX9e0OQ@mail.gmail.com> Subject: Re: [Xen-devel] Xen document day (Oct 12 or 26) From: George Dunlap <George.Dunlap@eu.citrix.com> To: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com> Content-Type: text/plain; charset=ISO-8859-1 Cc: xen-devel@lists.xensource.com, xen-users@lists.xensource.com X-BeenThere: xen-devel@lists.xensource.com X-Mailman-Version: 2.1.5 Precedence: list List-Id: Xen developer discussion <xen-devel.lists.xensource.com> List-Unsubscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe> List-Post: <mailto:xen-devel@lists.xensource.com> List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help> List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=subscribe> Sender: xen-devel-bounces@lists.xensource.com Errors-To: xen-devel-bounces@lists.xensource.com Another thing that needs to be done is to write man pages for xl, and update the man pages for xm to indicate that it is deprecated. We also discussed the idea of moving some of the documentation and the HOWTOs into the xen.hg/docs folder, preferrably in a nice language like Markdown, so that we can enforce changes in documentation with changes code. I propose using Markdown, if no one has a better idea. :-) -George On Thu, Sep 22, 2011 at 2:06 PM, Konrad Rzeszutek Wilk <konrad.wilk@oracle.com> wrote: > Part of what we brainstormed at Xen Hackathon was what we could do make Xen easier. > > And the one thing that seemed to surface up was making the docs better - either > be the Wiki or the three .pdfs that get created/shipped with Xen. > > One thought was to come up with a Documention Day - where volunteers would try to > fix up some portion of the documentation that they feel they have > a good grasp of knowledge off and are willing to change (and also look > to be incorrect) > > What do you guys think of Oct 12th or Oct 26 as a day for this? > > And then the next question - what page/pdf section interests you? > > http://bits.xensource.com/Xen/docs/user.pdf > http://www.rites.uic.edu/~solworth/xenInterfaceManual.pdf [the one on Xen.org is an older version] > > Or Wiki pages: > http://wiki.xensource.com/xenwiki/ > > http://wiki.xensource.com/xenwiki/XenDom0Kernels > http://wiki.xensource.com/xenwiki/XenSerialConsole > http://wiki.xensource.com/xenwiki/XenParavirtOps > http://wiki.xensource.com/xenwiki/XenCommonProblems > > http://wiki.xensource.com/xenwiki/Consulting > http://wiki.xensource.com/xenwiki/Consultants > http://wiki.xensource.com/xenwiki/VpsHostingWithXen > > http://wiki.xen.org/xenwiki/XenPCIpassthrough > http://wiki.xen.org/xenwiki/VTdHowTo > > _______________________________________________ > Xen-devel mailing list > Xen-devel@lists.xensource.com > http://lists.xensource.com/xen-devel > _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel From xen-devel-bounces@lists.xensource.com Thu Sep 22 09:44:08 2011 Return-path: <xen-devel-bounces@lists.xensource.com> Envelope-to: www-data@lists.xensource.com Delivery-date: Thu, 22 Sep 2011 09:44:08 -0700 Received: from localhost ([127.0.0.1] helo=lists.colo.xensource.com) by lists.xensource.com with esmtp (Exim 4.43) id 1R6mNc-0000vU-HF; Thu, 22 Sep 2011 09:44:08 -0700 Received: from mail21.messagelabs.com ([85.158.143.35]) by lists.xensource.com with esmtp (Exim 4.43) id 1R6mN6-0000j9-PF for xen-devel@lists.xensource.com; Thu, 22 Sep 2011 09:43:37 -0700 X-Env-Sender: Ian.Jackson@eu.citrix.com X-Msg-Ref: server-15.tower-21.messagelabs.com!1316709815!51603400!1 X-Originating-IP: [62.200.22.115] X-StarScan-Version: 6.4.1; banners=-,-,- X-VirusChecked: Checked Received: (qmail 2065 invoked from network); 22 Sep 2011 16:43:35 -0000 Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115) by server-15.tower-21.messagelabs.com with RC4-SHA encrypted SMTP; 22 Sep 2011 16:43:35 -0000 X-IronPort-AV: E=Sophos;i="4.68,424,1312156800"; d="scan'208";a="8014227" Received: from lonpmailmx01.citrite.net ([10.30.203.162]) by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5; 22 Sep 2011 16:43:33 +0000 Received: from woking.xci-test.com (10.80.248.135) by smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id 8.3.137.0; Thu, 22 Sep 2011 17:43:33 +0100 Received: from osstest by woking.xci-test.com with local (Exim 4.69) (envelope-from <ian.jackson@eu.citrix.com>) id 1R6mN3-0006Uv-2c; Thu, 22 Sep 2011 17:43:33 +0100 To: xen-devel@lists.xensource.com Message-ID: <osstest-8998-mainreport@xen.org> From: xen.org <ian.jackson@eu.citrix.com> Date: Thu, 22 Sep 2011 17:43:33 +0100 MIME-Version: 1.0 Content-Type: text/plain Cc: ian.jackson@eu.citrix.com Subject: [Xen-devel] [linux test] 8998: tolerable FAIL X-BeenThere: xen-devel@lists.xensource.com X-Mailman-Version: 2.1.5 Precedence: list List-Id: Xen developer discussion <xen-devel.lists.xensource.com> List-Unsubscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe> List-Post: <mailto:xen-devel@lists.xensource.com> List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help> List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=subscribe> Sender: xen-devel-bounces@lists.xensource.com Errors-To: xen-devel-bounces@lists.xensource.com flight 8998 linux real [real] http://www.chiark.greenend.org.uk/~xensrcts/logs/8998/ Failures :-/ but no regressions. Tests which did not succeed, but are not blocking, including regressions (tests previously passed) regarded as allowable: test-amd64-amd64-xl-pcipt-intel 9 guest-start fail never pass test-amd64-i386-rhel6hvm-amd 9 guest-start.2 fail never pass test-amd64-i386-rhel6hvm-intel 9 guest-start.2 fail never pass test-i386-i386-win 16 leak-check/check fail never pass test-amd64-i386-win-vcpus1 16 leak-check/check fail never pass test-amd64-i386-xl-win-vcpus1 13 guest-stop fail never pass test-amd64-amd64-win 16 leak-check/check fail never pass test-amd64-i386-win 16 leak-check/check fail never pass test-amd64-amd64-xl-win 13 guest-stop fail never pass test-i386-i386-xl-win 13 guest-stop fail never pass version targeted for testing: linux 6bec8b4a4c14095d0b7ce424db9d583c3decae6c baseline version: linux 1c3f03ccc5258887f5f2cafc0836a865834f9205 ------------------------------------------------------------ People who touched revisions under test: Jeremy Fitzhardinge <jeremy.fitzhardinge@citrix.com> ------------------------------------------------------------ jobs: build-amd64 pass build-i386 pass build-amd64-pvops pass build-i386-pvops pass test-amd64-amd64-xl pass test-amd64-i386-xl pass test-i386-i386-xl pass test-amd64-i386-rhel6hvm-amd fail test-amd64-i386-xl-credit2 pass test-amd64-amd64-xl-pcipt-intel fail test-amd64-i386-rhel6hvm-intel fail test-amd64-i386-xl-multivcpu pass test-amd64-amd64-pair pass test-amd64-i386-pair pass test-i386-i386-pair pass test-amd64-amd64-pv pass test-amd64-i386-pv pass test-i386-i386-pv pass test-amd64-amd64-xl-sedf pass test-amd64-i386-win-vcpus1 fail test-amd64-i386-xl-win-vcpus1 fail test-amd64-amd64-win fail test-amd64-i386-win fail test-i386-i386-win fail test-amd64-amd64-xl-win fail test-i386-i386-xl-win fail ------------------------------------------------------------ sg-report-flight on woking.cam.xci-test.com logs: /home/xc_osstest/logs images: /home/xc_osstest/images Logs, config files, etc. are available at http://www.chiark.greenend.org.uk/~xensrcts/logs Test harness code can be found at http://xenbits.xensource.com/gitweb?p=osstest.git;a=summary Pushing revision : + branch=linux + revision=6bec8b4a4c14095d0b7ce424db9d583c3decae6c + . cri-lock-repos ++ . cri-common +++ umask 002 +++ getconfig Repos +++ perl -e ' use Osstest; readconfigonly(); print $c{Repos} or die $!; ' ++ repos=/export/home/osstest/repos ++ repos_lock=/export/home/osstest/repos/lock ++ '[' x '!=' x/export/home/osstest/repos/lock ']' ++ OSSTEST_REPOS_LOCK_LOCKED=/export/home/osstest/repos/lock ++ exec with-lock-ex -w /export/home/osstest/repos/lock ./ap-push linux 6bec8b4a4c14095d0b7ce424db9d583c3decae6c + branch=linux + revision=6bec8b4a4c14095d0b7ce424db9d583c3decae6c + . cri-lock-repos ++ . cri-common +++ umask 002 +++ getconfig Repos +++ perl -e ' use Osstest; readconfigonly(); print $c{Repos} or die $!; ' ++ repos=/export/home/osstest/repos ++ repos_lock=/export/home/osstest/repos/lock ++ '[' x/export/home/osstest/repos/lock '!=' x/export/home/osstest/repos/lock ']' + : xen@xenbits.xensource.com + : xen@xenbits.xensource.com:git/linux-pvops + : master + : tested/2.6.39.x + case "$branch" in + cd /export/home/osstest/repos/xen ./ap-push: line 20: cd: /export/home/osstest/repos/xen: No such file or directory ------------------------------------------------------------ commit 6bec8b4a4c14095d0b7ce424db9d583c3decae6c Author: Jeremy Fitzhardinge <jeremy.fitzhardinge@citrix.com> Date: Fri Sep 2 12:23:22 2011 -0700 Revert "xen/apic: Provide an 'apic_xen' to set the override the apic->[read|write] for all cases." This reverts commit c3dd7941354fa96a71f2613e2c7a1b215fa175dc. It prevents the kernel from booting natively on hardware. Conflicts: arch/x86/xen/enlighten.c Signed-off-by: Jeremy Fitzhardinge <jeremy.fitzhardinge@citrix.com> _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel From xen-devel-bounces@lists.xensource.com Thu Sep 22 10:05:17 2011 Return-path: <xen-devel-bounces@lists.xensource.com> Envelope-to: www-data@lists.xensource.com Delivery-date: Thu, 22 Sep 2011 10:05:17 -0700 Received: from localhost ([127.0.0.1] helo=lists.colo.xensource.com) by lists.xensource.com with esmtp (Exim 4.43) id 1R6mi5-0001kc-5z; Thu, 22 Sep 2011 10:05:17 -0700 Received: from mail27.messagelabs.com ([193.109.254.147]) by lists.xensource.com with esmtp (Exim 4.43) id 1R6mgF-0001Wx-5G for xen-devel@lists.xensource.com; Thu, 22 Sep 2011 10:03:35 -0700 X-Env-Sender: Ian.Jackson@eu.citrix.com X-Msg-Ref: server-10.tower-27.messagelabs.com!1316710979!36846618!1 X-Originating-IP: [62.200.22.115] X-StarScan-Version: 6.4.1; banners=-,-,- X-VirusChecked: Checked Received: (qmail 12546 invoked from network); 22 Sep 2011 17:02:59 -0000 Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115) by server-10.tower-27.messagelabs.com with RC4-SHA encrypted SMTP; 22 Sep 2011 17:02:59 -0000 X-IronPort-AV: E=Sophos;i="4.68,424,1312156800"; d="scan'208";a="8015072" Received: from lonpmailmx01.citrite.net ([10.30.203.162]) by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5; 22 Sep 2011 17:03:19 +0000 Received: from norwich.cam.xci-test.com (10.80.248.129) by smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id 8.3.137.0; Thu, 22 Sep 2011 18:03:19 +0100 Received: from mariner.cam.xci-test.com ([10.80.2.22] helo=mariner.uk.xensource.com ident=Debian-exim) by norwich.cam.xci-test.com with esmtp (Exim 4.72) (envelope-from <Ian.Jackson@eu.citrix.com>) id 1R6mgB-0003nv-3B; Thu, 22 Sep 2011 17:03:19 +0000 Received: from iwj by mariner.uk.xensource.com with local (Exim 4.69) (envelope-from <Ian.Jackson@eu.citrix.com>) id 1R6mgB-0003oy-2J; Thu, 22 Sep 2011 18:03:19 +0100 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Message-ID: <20091.27223.64595.454672@mariner.uk.xensource.com> Date: Thu, 22 Sep 2011 18:03:19 +0100 To: Jeremy Fitzhardinge <jeremy@goop.org> In-Reply-To: <4E6E99DA.5060804@goop.org> References: <4E6E99DA.5060804@goop.org> X-Mailer: VM 8.0.9 under Emacs 21.4.1 (i486-pc-linux-gnu) From: Ian Jackson <Ian.Jackson@eu.citrix.com> Cc: Lars Kurth <lars.kurth@citrix.com>, "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com> Subject: [Xen-devel] Re: Xen.org gpg public keys on xen.org X-BeenThere: xen-devel@lists.xensource.com X-Mailman-Version: 2.1.5 Precedence: list List-Id: Xen developer discussion <xen-devel.lists.xensource.com> List-Unsubscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe> List-Post: <mailto:xen-devel@lists.xensource.com> List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help> List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=subscribe> Sender: xen-devel-bounces@lists.xensource.com Errors-To: xen-devel-bounces@lists.xensource.com Jeremy Fitzhardinge writes ("Xen.org gpg public keys on xen.org"): > Did we ever end up publishing the Xen.org gpg keys on the xen.org > website? I couldn't find them from a quick look; there's no sign of > "pgp@xen.org" or 79BAD9D8. These should be on the website, indeed. I have uploaded them to the keyservers in the meantime (as I reported on irc last night). Ian. _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel From xen-devel-bounces@lists.xensource.com Thu Sep 22 10:08:18 2011 Return-path: <xen-devel-bounces@lists.xensource.com> Envelope-to: www-data@lists.xensource.com Delivery-date: Thu, 22 Sep 2011 10:08:18 -0700 Received: from localhost ([127.0.0.1] helo=lists.colo.xensource.com) by lists.xensource.com with esmtp (Exim 4.43) id 1R6mkz-0002AZ-Vc; Thu, 22 Sep 2011 10:08:18 -0700 Received: from mail21.messagelabs.com ([85.158.143.35]) by lists.xensource.com with esmtp (Exim 4.43) id 1R6mkE-0001xl-62 for xen-devel@lists.xensource.com; Thu, 22 Sep 2011 10:07:35 -0700 X-Env-Sender: dan.magenheimer@oracle.com X-Msg-Ref: server-9.tower-21.messagelabs.com!1316711200!49433773!1 X-Originating-IP: [148.87.113.117] X-StarScan-Version: 6.4.1; banners=-,-,- X-VirusChecked: Checked Received: (qmail 22756 invoked from network); 22 Sep 2011 17:06:42 -0000 Received: from rcsinet15.oracle.com (HELO rcsinet15.oracle.com) (148.87.113.117) by server-9.tower-21.messagelabs.com with DHE-RSA-AES256-SHA encrypted SMTP; 22 Sep 2011 17:06:42 -0000 Received: from acsinet22.oracle.com (acsinet22.oracle.com [141.146.126.238]) by rcsinet15.oracle.com (Switch-3.4.4/Switch-3.4.4) with ESMTP id p8MH7Lcf025928 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Thu, 22 Sep 2011 17:07:22 GMT Received: from acsmt358.oracle.com (acsmt358.oracle.com [141.146.40.158]) by acsinet22.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id p8MH7KRI005320 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 22 Sep 2011 17:07:20 GMT Received: from abhmt110.oracle.com (abhmt110.oracle.com [141.146.116.62]) by acsmt358.oracle.com (8.12.11.20060308/8.12.11) with ESMTP id p8MH7E0P029636; Thu, 22 Sep 2011 12:07:14 -0500 MIME-Version: 1.0 Message-ID: <df22e0b8-15d8-4cb1-a9d9-d3565aa5f9b7@default> Date: Thu, 22 Sep 2011 10:06:55 -0700 (PDT) From: Dan Magenheimer <dan.magenheimer@oracle.com> To: David Vrabel <david.vrabel@citrix.com> Subject: RE: [Xen-devel] xen: memory initialization/balloon fixes (#3) References: <1316089768-22461-1-git-send-email-david.vrabel@citrix.com> <63997331-e53b-48e5-bf7c-87141aae49d6@default 4E7B2ADA.7000605@citrix.com> In-Reply-To: <4E7B2ADA.7000605@citrix.com> X-Priority: 3 X-Mailer: Oracle Beehive Extensions for Outlook 2.0.1.4.1.0 (410211) [OL 12.0.6557.5001] Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable X-Source-IP: acsinet22.oracle.com [141.146.126.238] X-Auth-Type: Internal IP X-CT-RefId: str=0001.0A090204.4E7B6B4B.00E5:SCFMA922111,ss=1,re=-4.000,fgs=0 Cc: jeremy@goop.org, xen-devel@lists.xensource.com, JBeulich@novell.com, Konrad Wilk <konrad.wilk@oracle.com> X-BeenThere: xen-devel@lists.xensource.com X-Mailman-Version: 2.1.5 Precedence: list List-Id: Xen developer discussion <xen-devel.lists.xensource.com> List-Unsubscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe> List-Post: <mailto:xen-devel@lists.xensource.com> List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help> List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=subscribe> Sender: xen-devel-bounces@lists.xensource.com Errors-To: xen-devel-bounces@lists.xensource.com > From: David Vrabel [mailto:david.vrabel@citrix.com] > Sent: Thursday, September 22, 2011 6:32 AM > To: Dan Magenheimer > Cc: xen-devel@lists.xensource.com; Konrad Wilk > Subject: Re: [Xen-devel] xen: memory initialization/balloon fixes (#3) >=20 > On 20/09/11 17:57, Dan Magenheimer wrote: > > > > Thanks for your patches! I am looking at a memory capacity/ballooning > > weirdness that I hoped your patchset might fix, but so far it has not. > > I'm wondering if there was an earlier fix that you are building upon > > and that I am missing. > > > > My problem occurs in a PV domU with an upstream-variant kernel based > > on 3.0.5. The problem is that the total amount of memory as seen > > from inside the guest is always substantially less than the amount > > of memory seen from outside the guest. The difference seems to > > be fixed within a given boot, but assigning a different vm.cfg mem=3D > > changes the amount. (For example, the difference D is about 18MB on > > a mem=3D128 boot and about 36MB on a mem=3D1024 boot.) >=20 > I don't see the problem? Hi David -- Sorry, just to clarify, are you saying you are seeing the same behavior and don't consider it a problem, or that you are not seeing the same difference? > The MemTotal value /proc/meminfo doesn't include some pages reserved by > the kernel which is why it's less than the maximum reservation of the > domain. I'm aware of that... "some" has been a fixed size of a few megabytes in Xen for a long time. I am seeing 30-60MB or more. If you are never seeing a difference more than a few MB, maybe I've misapplied your patches (as they didn't apply cleanly and I had to do some manual patching). =20 > > Part B of the problem (and the one most important to me) is that > > setting /sys/devices/system/xen_memory/xen_memory0/target_kb > > to X results in a MemTotal inside the domU (as observed by > > "head -1 /proc/meminfo") of X-D. This can be particularly painful > > when X is aggressively small as X-D may result in OOMs. > > To use kernel function/variable names (and I observed this with > > some debugging code), when balloon_set_new_target(X) is called > > totalram_pages gets driven to X-D. >=20 > Again, this looks like the correct behavior to me. Hmmm... so if a user (or automated tool) uses the Xen-defined API (i.e. /sys/devices/system/xen_memory/xen_memory0/target_kb) to use the Xen balloon driver to attempt to reduce memory usage to 100MB, and the Xen balloon driver instead reduces it to some random number somewhere between 40MB and 90MB, which may or may not cause OOMs, you consider this correct behavior? (Cc'ing a couple of ballooning old-timers to ensure I am not misunderstanding the intended API.) Thanks, Dan _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel From xen-devel-bounces@lists.xensource.com Thu Sep 22 10:41:14 2011 Return-path: <xen-devel-bounces@lists.xensource.com> Envelope-to: www-data@lists.xensource.com Delivery-date: Thu, 22 Sep 2011 10:41:14 -0700 Received: from localhost ([127.0.0.1] helo=lists.colo.xensource.com) by lists.xensource.com with esmtp (Exim 4.43) id 1R6nGr-00037D-Bu; Thu, 22 Sep 2011 10:41:13 -0700 Received: from mail182.messagelabs.com ([85.158.139.83]) by lists.xensource.com with esmtp (Exim 4.43) id 1R6nG1-0002uf-NM; Thu, 22 Sep 2011 10:40:22 -0700 X-Env-Sender: konrad@oracle.com X-Msg-Ref: server-12.tower-182.messagelabs.com!1316713216!19222360!1 X-Originating-IP: [148.87.113.117] X-StarScan-Version: 6.4.1; banners=-,-,- X-VirusChecked: Checked Received: (qmail 4495 invoked from network); 22 Sep 2011 17:40:18 -0000 Received: from rcsinet15.oracle.com (HELO rcsinet15.oracle.com) (148.87.113.117) by server-12.tower-182.messagelabs.com with DHE-RSA-AES256-SHA encrypted SMTP; 22 Sep 2011 17:40:18 -0000 Received: from acsinet21.oracle.com (acsinet21.oracle.com [141.146.126.237]) by rcsinet15.oracle.com (Switch-3.4.4/Switch-3.4.4) with ESMTP id p8MHe1KA031078 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Thu, 22 Sep 2011 17:40:03 GMT Received: from acsmt356.oracle.com (acsmt356.oracle.com [141.146.40.156]) by acsinet21.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id p8MHe1SD020326 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 22 Sep 2011 17:40:01 GMT Received: from abhmt115.oracle.com (abhmt115.oracle.com [141.146.116.67]) by acsmt356.oracle.com (8.12.11.20060308/8.12.11) with ESMTP id p8MHdtjk023126; Thu, 22 Sep 2011 12:39:55 -0500 Received: from oracle.com (/209.6.55.207) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Thu, 22 Sep 2011 10:39:55 -0700 Received: by oracle.com (Postfix, from userid 1000) id ACA2B1364; Thu, 22 Sep 2011 13:40:02 -0400 (EDT) Date: Thu, 22 Sep 2011 13:40:02 -0400 From: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com> To: George Dunlap <George.Dunlap@eu.citrix.com> Subject: Re: [Xen-devel] Xen document day (Oct 12 or 26) Message-ID: <20110922174002.GA1205@phenom.oracle.com> References: <20110922130618.GA13238@phenom.oracle.com> <CAFLBxZaAaXTUtW5+VkxPnr_MR0fbW+d1Mzu4y0x=gEOaX9e0OQ@mail.gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <CAFLBxZaAaXTUtW5+VkxPnr_MR0fbW+d1Mzu4y0x=gEOaX9e0OQ@mail.gmail.com> User-Agent: Mutt/1.5.21 (2010-09-15) X-Source-IP: acsinet21.oracle.com [141.146.126.237] X-Auth-Type: Internal IP X-CT-RefId: str=0001.0A090206.4E7B72FC.00E7:SCFMA922111,ss=1,re=-4.000,fgs=0 Cc: xen-devel@lists.xensource.com, xen-users@lists.xensource.com X-BeenThere: xen-devel@lists.xensource.com X-Mailman-Version: 2.1.5 Precedence: list List-Id: Xen developer discussion <xen-devel.lists.xensource.com> List-Unsubscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe> List-Post: <mailto:xen-devel@lists.xensource.com> List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help> List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=subscribe> Sender: xen-devel-bounces@lists.xensource.com Errors-To: xen-devel-bounces@lists.xensource.com On Thu, Sep 22, 2011 at 05:32:46PM +0100, George Dunlap wrote: > Another thing that needs to be done is to write man pages for xl, and > update the man pages for xm to indicate that it is deprecated. So: 1). PDF/section 2). Wiki 3). man page for xl/xm 4). HOWTO, docs in xen.hg/docs 5). Convert said HOWTO, docs in Markdown. Who wants to do what? I created a sign up sheet: https://docs.google.com/spreadsheet/ccc?key=0Aj5ukWh4htwMdEFLVWpjRmx3VXdETDExNlByamd4Rmc&hl=en_US in case folks want to get an idea of who is doing what and not step on each toes. > > We also discussed the idea of moving some of the documentation and the > HOWTOs into the xen.hg/docs folder, preferrably in a nice language > like Markdown, so that we can enforce changes in documentation with > changes code. I propose using Markdown, if no one has a better idea. Which pretty much looks like writting normal text files per http://en.wikipedia.org/wiki/Markdown description. > :-) > > -George > > On Thu, Sep 22, 2011 at 2:06 PM, Konrad Rzeszutek Wilk > <konrad.wilk@oracle.com> wrote: > > Part of what we brainstormed at Xen Hackathon was what we could do make Xen easier. > > > > And the one thing that seemed to surface up was making the docs better - either > > be the Wiki or the three .pdfs that get created/shipped with Xen. > > > > One thought was to come up with a Documention Day - where volunteers would try to > > fix up some portion of the documentation that they feel they have > > a good grasp of knowledge off and are willing to change (and also look > > to be incorrect) > > > > What do you guys think of Oct 12th or Oct 26 as a day for this? > > > > And then the next question - what page/pdf section interests you? > > > > http://bits.xensource.com/Xen/docs/user.pdf > > http://www.rites.uic.edu/~solworth/xenInterfaceManual.pdf [the one on Xen.org is an older version] > > > > Or Wiki pages: > > http://wiki.xensource.com/xenwiki/ > > > > http://wiki.xensource.com/xenwiki/XenDom0Kernels > > http://wiki.xensource.com/xenwiki/XenSerialConsole > > http://wiki.xensource.com/xenwiki/XenParavirtOps > > http://wiki.xensource.com/xenwiki/XenCommonProblems > > > > http://wiki.xensource.com/xenwiki/Consulting > > http://wiki.xensource.com/xenwiki/Consultants > > http://wiki.xensource.com/xenwiki/VpsHostingWithXen > > > > http://wiki.xen.org/xenwiki/XenPCIpassthrough > > http://wiki.xen.org/xenwiki/VTdHowTo > > > > _______________________________________________ > > Xen-devel mailing list > > Xen-devel@lists.xensource.com > > http://lists.xensource.com/xen-devel > > > > _______________________________________________ > Xen-devel mailing list > Xen-devel@lists.xensource.com > http://lists.xensource.com/xen-devel _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel From xen-devel-bounces@lists.xensource.com Thu Sep 22 10:44:32 2011 Return-path: <xen-devel-bounces@lists.xensource.com> Envelope-to: www-data@lists.xensource.com Delivery-date: Thu, 22 Sep 2011 10:44:32 -0700 Received: from localhost ([127.0.0.1] helo=lists.colo.xensource.com) by lists.xensource.com with esmtp (Exim 4.43) id 1R6nK3-0004Ak-Vu; Thu, 22 Sep 2011 10:44:32 -0700 Received: from mail216.messagelabs.com ([85.158.143.99]) by lists.xensource.com with esmtp (Exim 4.43) id 1R6nGo-000364-Lf for xen-devel@lists.xensource.com; Thu, 22 Sep 2011 10:41:11 -0700 X-Env-Sender: javier.manzano@edu.uah.es X-Msg-Ref: server-12.tower-216.messagelabs.com!1316713266!13524309!1 X-Originating-IP: [216.139.236.26] X-StarScan-Version: 6.4.1; banners=-,-,- X-VirusChecked: Checked Received: (qmail 2893 invoked from network); 22 Sep 2011 17:41:07 -0000 Received: from sam.nabble.com (HELO sam.nabble.com) (216.139.236.26) by server-12.tower-216.messagelabs.com with AES256-SHA encrypted SMTP; 22 Sep 2011 17:41:07 -0000 Received: from [192.168.236.26] (helo=sam.nabble.com) by sam.nabble.com with esmtp (Exim 4.72) (envelope-from <javier.manzano@edu.uah.es>) id 1R6nGj-0004cU-UC for xen-devel@lists.xensource.com; Thu, 22 Sep 2011 10:41:05 -0700 Date: Thu, 22 Sep 2011 10:41:05 -0700 (PDT) From: JavMV <javier.manzano@edu.uah.es> To: xen-devel@lists.xensource.com Message-ID: <1316713265930-4830942.post@n5.nabble.com> In-Reply-To: <1316696154780-4830056.post@n5.nabble.com> References: <1316613404292-4826432.post@n5.nabble.com> <1316614084705-4826479.post@n5.nabble.com> <1316615526442-4826582.post@n5.nabble.com> <1316616001843-4826614.post@n5.nabble.com> <1316616472579-4826635.post@n5.nabble.com> <1316616757871-4826655.post@n5.nabble.com> <1316618006.67296.YahooMailNeo@web29818.mail.ird.yahoo.com> <1316693722029-4829929.post@n5.nabble.com> <1316695546329-4830015.post@n5.nabble.com> <1316696154780-4830056.post@n5.nabble.com> Subject: Re: Re : Re : Re : Re : [Xen-devel] Re: Patches for VGA-Passthrough XEN 4.2 unstable MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-BeenThere: xen-devel@lists.xensource.com X-Mailman-Version: 2.1.5 Precedence: list List-Id: Xen developer discussion <xen-devel.lists.xensource.com> List-Unsubscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe> List-Post: <mailto:xen-devel@lists.xensource.com> List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help> List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=subscribe> Sender: xen-devel-bounces@lists.xensource.com Errors-To: xen-devel-bounces@lists.xensource.com I have done a full reinstall this time clean install without errors and the problem persists, so I'm thinking that the problem is maybe the version of Dom0 kernel, maybe next versions are better or have more patches applied... what do you think? I will try to install xen like the first time: #aptitude install xen-linux-system-2.6.32-5-xen-686 (para 32bits) y #aptitude install xen-linux-system-2.6.32-5-xen-amd64 (para amd64). ----- JavMV -- View this message in context: http://xen.1045712.n5.nabble.com/Patches-for-VGA-Passthrough-XEN-4-2-unstable-tp4406265p4830942.html Sent from the Xen - Dev mailing list archive at Nabble.com. _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel From xen-devel-bounces@lists.xensource.com Thu Sep 22 10:45:39 2011 Return-path: <xen-devel-bounces@lists.xensource.com> Envelope-to: www-data@lists.xensource.com Delivery-date: Thu, 22 Sep 2011 10:45:39 -0700 Received: from localhost ([127.0.0.1] helo=lists.colo.xensource.com) by lists.xensource.com with esmtp (Exim 4.43) id 1R6nL9-0004Xt-8K; Thu, 22 Sep 2011 10:45:39 -0700 Received: from mail27.messagelabs.com ([193.109.254.147]) by lists.xensource.com with esmtp (Exim 4.43) id 1R6nK8-0004BF-5x for xen-devel@lists.xensource.com; Thu, 22 Sep 2011 10:44:36 -0700 X-Env-Sender: Stefano.Stabellini@eu.citrix.com X-Msg-Ref: server-4.tower-27.messagelabs.com!1316713454!41371900!1 X-Originating-IP: [62.200.22.115] X-StarScan-Version: 6.4.1; banners=-,-,- X-VirusChecked: Checked Received: (qmail 31601 invoked from network); 22 Sep 2011 17:44:14 -0000 Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115) by server-4.tower-27.messagelabs.com with RC4-SHA encrypted SMTP; 22 Sep 2011 17:44:14 -0000 X-IronPort-AV: E=Sophos;i="4.68,424,1312156800"; d="scan'208";a="8015716" Received: from lonpmailmx01.citrite.net ([10.30.203.162]) by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5; 22 Sep 2011 17:44:32 +0000 Received: from kaball.uk.xensource.com (10.80.2.59) by LONPMAILMX01.citrite.net (10.30.203.162) with Microsoft SMTP Server id 8.3.137.0; Thu, 22 Sep 2011 18:44:32 +0100 Date: Thu, 22 Sep 2011 18:44:31 +0100 From: Stefano Stabellini <stefano.stabellini@eu.citrix.com> X-X-Sender: sstabellini@kaball-desktop To: Stefan Bader <stefan.bader@canonical.com> Subject: Re: [Xen-devel] Re: Still struggling with HVM: tx timeouts on emulated nics In-Reply-To: <4E7B4768.8060103@canonical.com> Message-ID: <alpine.DEB.2.00.1109221838370.8700@kaball-desktop> References: <4E7B4768.8060103@canonical.com> User-Agent: Alpine 2.00 (DEB 1167 2008-08-23) MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Cc: xen-devel@lists.xensource.com, Stefano Stabellini <Stefano.Stabellini@eu.citrix.com> X-BeenThere: xen-devel@lists.xensource.com X-Mailman-Version: 2.1.5 Precedence: list List-Id: Xen developer discussion <xen-devel.lists.xensource.com> List-Unsubscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe> List-Post: <mailto:xen-devel@lists.xensource.com> List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help> List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=subscribe> Sender: xen-devel-bounces@lists.xensource.com Errors-To: xen-devel-bounces@lists.xensource.com On Thu, 22 Sep 2011, Stefan Bader wrote: > On 22.09.2011 13:58, Stefan Bader wrote: > > On 22.09.2011 12:30, Stefano Stabellini wrote: > >> On Wed, 21 Sep 2011, Stefan Bader wrote: > >>> On 21.09.2011 15:31, Stefano Stabellini wrote: > >>>> On Wed, 21 Sep 2011, Stefan Bader wrote: > >>>>> This is on 3.0.4 based dom0 and domU with 4.1.1 hypervisor. I tried using the > >>>>> default 8139cp and ne2k_pci emulated nic. The 8139cp one at least comes up and > >>>>> gets configured via dhcp. And initial pings also get routed and done correctly. > >>>>> But slightly higher traffic (like checking for updates) hangs. And after a while > >>>>> there are messages about tx timeouts. > >>>>> The ne2k_pci type nic almost immediately has those issues and never comes up > >>>>> correctly. > >>>>> > >>>>> I am attaching the dmesg of the guest with apic=debug enabled. I am not sure how > >>>>> this should be but both nics get configured with level,low IRQs. Disk emulation > >>>>> seems to be ok but that seem to use IO-APIC-edge. And any other IRQs seem to be > >>>>> at least not level. > >>>> > >>> > >>>> Does the e1000 emulated card work correctly? > >>> > >>> Yes, that one seems to work ok. > >>> > >>>> What happens if you disable interrupt remapping (see patch below)? > >>> > >>> 8139cp seems to work correctly now (much higher irq stats as well) and e1000 > >>> still works. Both then using IOAPIC-fasteoi. > >>> > >> > >> That means there must be another subtle bug in Xen in interrupt > >> remapping that only affects 8139p emulation > >> > > Right, or to be complete: > > - e1000: ok > > - 8139cp: unstable (setup is possible) > > - ne2k_pci: not working (tx problems from the beginning) > > > > The behaviour feels a bit like interrupts may get lost if occurring at a higher > > rate. Why this affects various drivers differently is a bit weird. > >> > > This is mainly speculating... Quite a while back there was this patch to events: > > commit dffe2e1e1a1ddb566a76266136c312801c66dcf7 > Author: Jeremy Fitzhardinge <jeremy.fitzhardinge@citrix.com> > Date: Fri Aug 20 19:10:01 2010 -0700 > > xen: handle events as edge-triggered > > The commit message stated that Xen events are logically edge triggered. So PV > events were changed to be handled as edge interrupts. Would that not mean that > for xen-pirq-apic being using events this would apply the same and those should > be apic-edge instead of level? That commit is referring to the internal way Linux handles these event, that look like normal interrupt to the Linux irq subsystem. It is not related to the way actual events are delivered from Xen to Linux, so it shouldn't matter here. I would add lots of printk's in: xen/arch/x86/hvm/irq.c:__hvm_pci_intx_assert xen/arch/x86/hvm/irq.c:assert_irq xen/arch/x86/hvm/irq.c:assert_gsi to find out why xen is not injecting those interrupts _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel From xen-devel-bounces@lists.xensource.com Thu Sep 22 11:12:32 2011 Return-path: <xen-devel-bounces@lists.xensource.com> Envelope-to: www-data@lists.xensource.com Delivery-date: Thu, 22 Sep 2011 11:12:32 -0700 Received: from localhost ([127.0.0.1] helo=lists.colo.xensource.com) by lists.xensource.com with esmtp (Exim 4.43) id 1R6nlA-00068k-OM; Thu, 22 Sep 2011 11:12:32 -0700 Received: from mail27.messagelabs.com ([193.109.254.147]) by lists.xensource.com with smtp (Exim 4.43) id 1R6nhh-0005F9-87 for xen-devel@lists.xensource.com; Thu, 22 Sep 2011 11:09:05 -0700 X-Env-Sender: dgdegra@tycho.nsa.gov X-Msg-Ref: server-6.tower-27.messagelabs.com!1316714914!50084335!1 X-Originating-IP: [63.239.65.39] X-StarScan-Version: 6.4.1; banners=-,-,- X-VirusChecked: Checked Received: (qmail 1710 invoked from network); 22 Sep 2011 18:08:34 -0000 Received: from msux-gh1-uea01.nsa.gov (HELO msux-gh1-uea01.nsa.gov) (63.239.65.39) by server-6.tower-27.messagelabs.com with SMTP; 22 Sep 2011 18:08:34 -0000 Received: from tarius.tycho.ncsc.mil (localhost [127.0.0.1]) by msux-gh1-uea01.nsa.gov (8.12.10/8.12.10) with ESMTP id p8MI8orj001701; Thu, 22 Sep 2011 18:08:51 GMT Received: from moss-nexus.epoch.ncsc.mil (moss-nexus [144.51.25.48]) by tarius.tycho.ncsc.mil (8.13.1/8.13.1) with ESMTP id p8MI8oTh024486; Thu, 22 Sep 2011 14:08:50 -0400 Message-ID: <4E7B79BC.3090703@tycho.nsa.gov> Date: Thu, 22 Sep 2011 14:09:00 -0400 From: Daniel De Graaf <dgdegra@tycho.nsa.gov> Organization: National Security Agency User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:6.0) Gecko/20110816 Thunderbird/6.0 MIME-Version: 1.0 To: Ian Campbell <Ian.Campbell@eu.citrix.com> References: <1313764724-12683-1-git-send-email-dgdegra@tycho.nsa.gov> <1316472208-12104-1-git-send-email-dgdegra@tycho.nsa.gov> <1316472208-12104-2-git-send-email-dgdegra@tycho.nsa.gov> <1316599431.3891.147.camel@zakaz.uk.xensource.com> <4E79FC9A.6040609@tycho.nsa.gov> <1316618733.3891.206.camel@zakaz.uk.xensource.com> <4E7A19D6.6090805@tycho.nsa.gov> <1316680355.23371.35.camel@zakaz.uk.xensource.com> In-Reply-To: <1316680355.23371.35.camel@zakaz.uk.xensource.com> X-Enigmail-Version: 1.3 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Cc: Stefano Stabellini <Stefano.Stabellini@eu.citrix.com>, "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>, Ian Jackson <Ian.Jackson@eu.citrix.com>, "konrad.wilk@oracle.com" <konrad.wilk@oracle.com> Subject: [Xen-devel] Re: [PATCH 1/3] libxc: add xc_gnttab_map_grant_ref_notify X-BeenThere: xen-devel@lists.xensource.com X-Mailman-Version: 2.1.5 Precedence: list List-Id: Xen developer discussion <xen-devel.lists.xensource.com> List-Unsubscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe> List-Post: <mailto:xen-devel@lists.xensource.com> List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help> List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=subscribe> Sender: xen-devel-bounces@lists.xensource.com Errors-To: xen-devel-bounces@lists.xensource.com On 09/22/2011 04:32 AM, Ian Campbell wrote: > On Wed, 2011-09-21 at 18:07 +0100, Daniel De Graaf wrote: >> On 09/21/2011 11:25 AM, Ian Campbell wrote: > >>> When I map a page how do I know what the offset of it is wrt the file >>> descriptor? DO I just have to remember how many pages I mapped an *= >>> 4096? >> >> You had the offset at the time you mapped it, because that's what you >> passed in the offset parameter to mmap(). Just don't lose the number :) > > So I guess my followup question is where does the number I pass to mmap > come from... > > /me scrobbles in the code. > > Aha, so it is an output from the gntdev/gntalloc ioctls. So how about: > > /* IN parameters */ > /* > * Offset in the file descriptor for a byte within the page. This offset > * is the result of the IOCTL_GNTDEV_MAP_GRANT_REF and is the same as > * is used with mmap(). > */ > Sounds good. >>>>>> +}; >>>>>> + >>>>>> +/* Clear (set to zero) the byte specified by index */ >>>>>> +#define UNMAP_NOTIFY_CLEAR_BYTE 0x1 >>>>>> +/* Send an interrupt on the indicated event channel */ >>>>>> +#define UNMAP_NOTIFY_SEND_EVENT 0x2 >>>>>> + >>>>>> #endif /* __LINUX_PUBLIC_GNTDEV_H__ */ >>>>>> diff --git a/tools/libxc/xc_gnttab.c b/tools/libxc/xc_gnttab.c >>>>>> index 4f55fce..3d3c63b 100644 >>>>>> --- a/tools/libxc/xc_gnttab.c >>>>>> +++ b/tools/libxc/xc_gnttab.c >>>>>> @@ -18,6 +18,7 @@ >>>>>> */ >>>>>> >>>>>> #include "xc_private.h" >>>>>> +#include <errno.h> >>>>>> >>>>>> int xc_gnttab_op(xc_interface *xch, int cmd, void * op, int op_size, int count) >>>>>> { >>>>>> @@ -174,6 +175,28 @@ void *xc_gnttab_map_domain_grant_refs(xc_gnttab *xcg, >>>>>> count, domid, refs, prot); >>>>>> } >>>>>> >>>>>> +void *xc_gnttab_map_grant_ref_notify(xc_gnttab *xcg, >>>>>> + uint32_t domid, >>>>>> + uint32_t ref, >>>>>> + uint32_t notify_offset, >>>>>> + evtchn_port_t notify_port, >>>>>> + int *notify_result) >>>>>> +{ >>>>>> + if (xcg->ops->u.gnttab.map_grant_ref_notify) >>>>>> + return xcg->ops->u.gnttab.map_grant_ref_notify(xcg, xcg->ops_handle, >>>>>> + domid, ref, notify_offset, notify_port, notify_result); >>>>>> + else { >>>>>> + void* area = xcg->ops->u.gnttab.map_grant_ref(xcg, xcg->ops_handle, >>>>>> + domid, ref, PROT_READ|PROT_WRITE); >>>>>> + if (area && notify_result) { >>>>>> + *notify_result = -1; >>>>>> + errno = ENOSYS; >>>>>> + } >>>>>> + return area; >>>>>> + } >>>>> >>>>> I think the new public interface is fine but do we really need a new >>>>> internal interface here? >>>>> >>>>> I think you can just add the notify_* arguments to the existing OSDEP >>>>> function and have those OS backends which don't implement that feature >>>>> return ENOSYS if notify_offset != 0 (or ~0 or whatever invalid value >>>>> works). >>>>> >>>>> Why doesn't the *_notify variant take a prot argument? >>>> >>>> At least for the byte-clear portion of the notify, the page must be writable >>>> or the notify will not work. I suppose an event channel alone could be used >>>> for a read-only mapping, but normally the unmapping of a read-only mapping is >>>> not an important event - although I guess you could contrive a use for this >>>> type of notificaiton, so there's no reason not to allow it. >>> >>> If you combine this the two functions then returning EINVAL for attempts >>> to map without PROT_WRITE (or whatever perm is necessary) would be >>> reasonable IMHO. >>> >> >> The ioctl already prevents you from requesting the impossible, so this should >> just work. > > Even better. I see the check in the gntdev driver but not in the > gntalloc one, is that right? > Yes. The unmap notification will always work in gntalloc because the shared page is owned locally, and is always writable there; read-only refers to the mapping domain's ability to write. > >>> I hadn't noticed that we have both map_gratn_ref and map_grant_refs, >>> that seems like an area which could be cleaned up. (not saying you >>> should, just noticing it) >> >> Since I'm already rewriting the osdep layer functions, I think I can replace >> all 3-4 existing map functions with a single function. > > Awesome, thanks! > >> It looks like the current 2.6.32.x xen kernels also aren't returning EAGAIN, >> so I'm unsure as to why this support was added. The commit in question is >> 20689:fe42b16855aa by Grzegorz Milos (committed by Keir Fraser), but I don't >> see any discussion on xen-devel for it. > > IIRC it was related to the page sharing patches which can cause grant > hypercalls to return EAGAIN if the granted page is swapped or shared. I > think this can only happen to backend/dom0 type operations. > > I think the reason it needs to return to the guest is that the paging > daemon may be in the same domain and having the only vcpu block in the > hypercall would deadlock. > >> It's also unclear why repeating the >> request every millisecond in an infinite loop is better than letting the >> caller handle an -EAGAIN. > > Yeah, the millisecond thing is pretty gross, something like > sched_yield() might be a bit more palatable (if it's portable enough, > although sleep could be a fallback if not) > > I suppose that hiding the EAGAIN handling in the library was just > thought to be convenient, compared with changing all the existing users. > > Ian. > It sounds to me like this is best solved in the kernel, although it would still have to invoke some kind of yield operation since I assume the kernel can't tell when the hypercall will not block (ideally you would be able to put the invoking process to sleep pending the cross-domain page fault). For now, it sounds like the best solution is to keep the usleep-based loop in for all gntdev invocations. Using sched_yield will cause the CPU to spin while the page is pending from disk or possibly while waiting for dom0 to be scheduled (assuming a domU-domU vchan). -- Daniel De Graaf National Security Agency _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel From xen-devel-bounces@lists.xensource.com Thu Sep 22 11:27:58 2011 Return-path: <xen-devel-bounces@lists.xensource.com> Envelope-to: www-data@lists.xensource.com Delivery-date: Thu, 22 Sep 2011 11:27:58 -0700 Received: from localhost ([127.0.0.1] helo=lists.colo.xensource.com) by lists.xensource.com with esmtp (Exim 4.43) id 1R6o05-0006ue-CM; Thu, 22 Sep 2011 11:27:57 -0700 Received: from mail27.messagelabs.com ([193.109.254.147]) by lists.xensource.com with esmtp (Exim 4.43) id 1R6nzK-0006ij-JT for xen-devel@lists.xensource.com; Thu, 22 Sep 2011 11:27:10 -0700 X-Env-Sender: pasik@iki.fi X-Msg-Ref: server-12.tower-27.messagelabs.com!1316716011!43546149!1 X-Originating-IP: [192.89.123.25] X-StarScan-Version: 6.4.1; banners=-,-,- X-VirusChecked: Checked Received: (qmail 13853 invoked from network); 22 Sep 2011 18:26:52 -0000 Received: from smtp.tele.fi (HELO smtp.tele.fi) (192.89.123.25) by server-12.tower-27.messagelabs.com with DHE-RSA-AES256-SHA encrypted SMTP; 22 Sep 2011 18:26:52 -0000 X-Originating-Ip: [194.89.68.22] Received: from ydin.reaktio.net (reaktio.net [194.89.68.22]) by smtp.tele.fi (Postfix) with ESMTP id 7F1C72B4A; Thu, 22 Sep 2011 21:27:05 +0300 (EEST) Received: by ydin.reaktio.net (Postfix, from userid 1001) id 730D2200EA; Thu, 22 Sep 2011 21:27:05 +0300 (EEST) Date: Thu, 22 Sep 2011 21:27:05 +0300 From: Pasi =?iso-8859-1?Q?K=E4rkk=E4inen?= <pasik@iki.fi> To: JavMV <javier.manzano@edu.uah.es> Subject: Re: Re : Re : Re : Re : [Xen-devel] Re: Patches for VGA-Passthrough XEN 4.2 unstable Message-ID: <20110922182705.GE12984@reaktio.net> References: <1315405921936-4778727.post@n5.nabble.com> <1316612652132-4826391.post@n5.nabble.com> <1316613404292-4826432.post@n5.nabble.com> <1316614084705-4826479.post@n5.nabble.com> <1316615526442-4826582.post@n5.nabble.com> <1316616001843-4826614.post@n5.nabble.com> <1316616472579-4826635.post@n5.nabble.com> <1316616757871-4826655.post@n5.nabble.com> <1316618006.67296.YahooMailNeo@web29818.mail.ird.yahoo.com> <1316693722029-4829929.post@n5.nabble.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <1316693722029-4829929.post@n5.nabble.com> User-Agent: Mutt/1.5.18 (2008-05-17) Cc: xen-devel@lists.xensource.com X-BeenThere: xen-devel@lists.xensource.com X-Mailman-Version: 2.1.5 Precedence: list List-Id: Xen developer discussion <xen-devel.lists.xensource.com> List-Unsubscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe> List-Post: <mailto:xen-devel@lists.xensource.com> List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help> List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=subscribe> Sender: xen-devel-bounces@lists.xensource.com Errors-To: xen-devel-bounces@lists.xensource.com On Thu, Sep 22, 2011 at 05:15:22AM -0700, JavMV wrote: > Hi again, I didn't answer you before because I'm having troubles to enable IO > virtualisation on XEN, I don't know why because it works for me on the past, > maybe I should try a full and clean installation from the start instead of > keep using my actual installation which can run xen but starting it manually > (due to errors)... > > Well I have enabled the next BIOS options: > XD Technology <Enable> > VT Technology <Enable> > Intel(R) VT for Directed I/O (VT-d) <Enable> > > So I think everything is OK but " # xm dmesg " show these lines: > > (XEN) [VT-D]dmar.c:456: Non-existent device (0:2.1) is reported in this > DRHD\047s scope! > (XEN) [VT-D]dmar.c:479: The DRHD is invalid due to there are devices > under its scope are not PCI > discoverable! Pls try option iommu=force or iommu=workaround_bios_bug if > you really want VT-d > (XEN) Failed to parse ACPI DMAR. * Disabling VT-d.* > (XEN) Table is not found! > (XEN) Using ACPI (MADT) for SMP configuration information > ... > * (XEN) I/O virtualisation disabled* > ... So this looks like a broken BIOS. Are you running the latest BIOS version? Which motherboard is that? -- Pasi > (XEN) HVM: ASIDs disabled. > *(XEN) HVM: VMX enabled* > ... > > I have tryed adding the options iommu=1, iommu=force or > iommu=workaround_bios_bug in grub menu entry: > > multiboot /boot/xen-4.2-unstable.gz placeholder > module /boot/vmlinuz-2.6.32.45 placeholder root=UUID=..... ro > *iommu=force* > module /boot/intrd.img-2.6.32.45 > > I don't know what is wrong now, this is frustrating (I/O) VT-d works for the > same computer on the past, could this problem be caused by the mixed > installations? I will try to reinstall everything after format the computer > but I will wait if you know how to fix this issue without reinstall > everything again. > > Javier > > > > > ----- > JavMV > -- > View this message in context: http://xen.1045712.n5.nabble.com/Patches-for-VGA-Passthrough-XEN-4-2-unstable-tp4406265p4829929.html > Sent from the Xen - Dev mailing list archive at Nabble.com. > > _______________________________________________ > Xen-devel mailing list > Xen-devel@lists.xensource.com > http://lists.xensource.com/xen-devel _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel From xen-devel-bounces@lists.xensource.com Thu Sep 22 11:31:46 2011 Return-path: <xen-devel-bounces@lists.xensource.com> Envelope-to: www-data@lists.xensource.com Delivery-date: Thu, 22 Sep 2011 11:31:46 -0700 Received: from localhost ([127.0.0.1] helo=lists.colo.xensource.com) by lists.xensource.com with esmtp (Exim 4.43) id 1R6o3m-0007L4-0c; Thu, 22 Sep 2011 11:31:46 -0700 Received: from mail174.messagelabs.com ([85.158.138.51]) by lists.xensource.com with esmtp (Exim 4.43) id 1R6o38-000786-Jz for Xen-devel@lists.xensource.com; Thu, 22 Sep 2011 11:31:07 -0700 X-Env-Sender: mukesh.rathor@oracle.com X-Msg-Ref: server-4.tower-174.messagelabs.com!1316716261!32429887!1 X-Originating-IP: [148.87.113.117] X-StarScan-Version: 6.4.1; banners=-,-,- X-VirusChecked: Checked Received: (qmail 18343 invoked from network); 22 Sep 2011 18:31:03 -0000 Received: from rcsinet15.oracle.com (HELO rcsinet15.oracle.com) (148.87.113.117) by server-4.tower-174.messagelabs.com with DHE-RSA-AES256-SHA encrypted SMTP; 22 Sep 2011 18:31:03 -0000 Received: from rtcsinet21.oracle.com (rtcsinet21.oracle.com [66.248.204.29]) by rcsinet15.oracle.com (Switch-3.4.4/Switch-3.4.4) with ESMTP id p8MIUued019987 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Thu, 22 Sep 2011 18:30:58 GMT Received: from acsmt356.oracle.com (acsmt356.oracle.com [141.146.40.156]) by rtcsinet21.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id p8MIUtc1026426 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 22 Sep 2011 18:30:56 GMT Received: from abhmt120.oracle.com (abhmt120.oracle.com [141.146.116.72]) by acsmt356.oracle.com (8.12.11.20060308/8.12.11) with ESMTP id p8MIUopK031537; Thu, 22 Sep 2011 13:30:50 -0500 Received: from mantra.us.oracle.com (/130.35.68.95) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Thu, 22 Sep 2011 11:30:49 -0700 Date: Thu, 22 Sep 2011 11:30:48 -0700 From: Mukesh Rathor <mukesh.rathor@oracle.com> To: "Xen-devel@lists.xensource.com" <Xen-devel@lists.xensource.com> Message-ID: <20110922113048.2d02f126@mantra.us.oracle.com> Organization: Oracle Corporation X-Mailer: Claws Mail 3.7.6 (GTK+ 2.18.9; x86_64-redhat-linux-gnu) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-Source-IP: rtcsinet21.oracle.com [66.248.204.29] X-CT-RefId: str=0001.0A090208.4E7B7EE3.001A,ss=1,re=0.000,fgs=0 Cc: stefano.stabellini@eu.citrix.com Subject: [Xen-devel] parse_config_data()... X-BeenThere: xen-devel@lists.xensource.com X-Mailman-Version: 2.1.5 Precedence: list List-Id: Xen developer discussion <xen-devel.lists.xensource.com> List-Unsubscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe> List-Post: <mailto:xen-devel@lists.xensource.com> List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help> List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=subscribe> Sender: xen-devel-bounces@lists.xensource.com Errors-To: xen-devel-bounces@lists.xensource.com Hi Stefano, In parse_config_data(): init_create_info(c_info); <--- sets hvm and hap to 1, then:. c_info->hvm = 0; if (!xlu_cfg_get_string (config, "builder", &buf) && !strncmp(buf, "hvm", strlen(buf))) c_info->hvm = 1; if (!xlu_cfg_get_long (config, "hap", &l)) <-------- already 1 c_info->hap = l; <--- letter 'el' no big deal, but just confusing for someone reading the code... thanks, Mukesh _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel From xen-devel-bounces@lists.xensource.com Thu Sep 22 11:38:35 2011 Return-path: <xen-devel-bounces@lists.xensource.com> Envelope-to: www-data@lists.xensource.com Delivery-date: Thu, 22 Sep 2011 11:38:35 -0700 Received: from localhost ([127.0.0.1] helo=lists.colo.xensource.com) by lists.xensource.com with esmtp (Exim 4.43) id 1R6oAN-0007qK-41; Thu, 22 Sep 2011 11:38:35 -0700 Received: from mail216.messagelabs.com ([85.158.143.99]) by lists.xensource.com with esmtp (Exim 4.43) id 1R6o9k-0007e0-2n for xen-devel@lists.xensource.com; Thu, 22 Sep 2011 11:37:56 -0700 X-Env-Sender: konrad@oracle.com X-Msg-Ref: server-10.tower-216.messagelabs.com!1316716671!11183337!1 X-Originating-IP: [148.87.113.117] X-StarScan-Version: 6.4.1; banners=-,-,- X-VirusChecked: Checked Received: (qmail 7897 invoked from network); 22 Sep 2011 18:37:52 -0000 Received: from rcsinet15.oracle.com (HELO rcsinet15.oracle.com) (148.87.113.117) by server-10.tower-216.messagelabs.com with DHE-RSA-AES256-SHA encrypted SMTP; 22 Sep 2011 18:37:52 -0000 Received: from acsinet21.oracle.com (acsinet21.oracle.com [141.146.126.237]) by rcsinet15.oracle.com (Switch-3.4.4/Switch-3.4.4) with ESMTP id p8MIbfo0005806 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Thu, 22 Sep 2011 18:37:47 GMT Received: from acsmt357.oracle.com (acsmt357.oracle.com [141.146.40.157]) by acsinet21.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id p8MIWWVM002248 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 22 Sep 2011 18:32:32 GMT Received: from abhmt108.oracle.com (abhmt108.oracle.com [141.146.116.60]) by acsmt357.oracle.com (8.12.11.20060308/8.12.11) with ESMTP id p8MIWPqh016082; Thu, 22 Sep 2011 13:32:25 -0500 Received: from oracle.com (/209.6.55.207) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Thu, 22 Sep 2011 11:32:25 -0700 Received: by oracle.com (Postfix, from userid 1000) id 348CA1364; Thu, 22 Sep 2011 14:32:32 -0400 (EDT) Date: Thu, 22 Sep 2011 14:32:32 -0400 From: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com> To: "Christopher S. Aker" <caker@theshore.net>, Shaun R <mailinglists@unix-scripts.com>, Jeremy Fitzhardinge <jeremy@goop.org> Subject: Re: [Xen-devel] Re: kernel BUG at mm/swapfile.c:2527! [was 3.0.0 Xen pv guest - BUG: Unable to handle] Message-ID: <20110922183232.GA23825@phenom.oracle.com> References: <9CAEB881-07FE-437C-8A6B-DB7B690CEABE@linode.com> <4E5BA49D.5060800@theshore.net> <20110829150734.GB24825@dumpdata.com> <1314704744.28989.2.camel@zakaz.uk.xensource.com> <4E5E9CDB.3070706@theshore.net> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="WIyZ46R2i8wDzkSu" Content-Disposition: inline In-Reply-To: <4E5E9CDB.3070706@theshore.net> User-Agent: Mutt/1.5.21 (2010-09-15) X-Source-IP: acsinet21.oracle.com [141.146.126.237] X-Auth-Type: Internal IP X-CT-RefId: str=0001.0A090201.4E7B807C.00C7:SCFMA922111,ss=1,re=-4.000,fgs=0 Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>, Ian Campbell <Ian.Campbell@citrix.com>, LKML <linux-kernel@vger.kernel.org> X-BeenThere: xen-devel@lists.xensource.com X-Mailman-Version: 2.1.5 Precedence: list List-Id: Xen developer discussion <xen-devel.lists.xensource.com> List-Unsubscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe> List-Post: <mailto:xen-devel@lists.xensource.com> List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help> List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=subscribe> Sender: xen-devel-bounces@lists.xensource.com Errors-To: xen-devel-bounces@lists.xensource.com --WIyZ46R2i8wDzkSu Content-Type: text/plain; charset=us-ascii Content-Disposition: inline > >I'd bet the dereference corresponds to the "*map" in that same place but > >Peter can you convert that address to a line of code please? > > root@build:/build/xen/domU/i386/3.0.0-linode35-debug# gdb vmlinux > GNU gdb (GDB) 7.1-ubuntu (...snip...) > Reading symbols from > /build/xen/domU/i386/3.0.0-linode35-debug/vmlinux...done. > (gdb) list *0xc01ab854 > 0xc01ab854 is in swap_count_continued (mm/swapfile.c:2493). > 2488 > 2489 if (count == (SWAP_MAP_MAX | COUNT_CONTINUED)) { /* > incrementing */ > 2490 /* > 2491 * Think of how you add 1 to 999 > 2492 */ > 2493 while (*map == (SWAP_CONT_MAX | COUNT_CONTINUED)) { > 2494 kunmap_atomic(map, KM_USER0); > 2495 page = list_entry(page->lru.next, > struct page, lru); > 2496 BUG_ON(page == head); > 2497 map = kmap_atomic(page, KM_USER0) + offset; > (gdb) > > >map came from a kmap_atomic() not far before this point so it appears > >that it is mapping the wrong page (so *map != 0) and/or mapping a > >non-existent page (leading to the fault). First of thanks to Jeremy for help on this one, and Shaun R for lending me one of his boxes with a environment to easily test it. The problem looks that in copy_page_range we turn lazy mode on, and then in swap_entry_free we call swap_count_continued which ends up in: map = kmap_atomic(page, KM_USER0) + offset; and then later on touching *map. Basically we are forking a process and copying the pages that are also "swap" pages. We don't need to access the user pages immediately, but we do for the swap pages as we need proper reference counting. Well, since we are running in batched mode we don't actually set up the PTE mappings and the kmap_atomic is not done synchronously and ends up trying to dereference a page that has not been set. Looking at kmap_atomic_prot_pfn, it uses 'arch_flush_lazy_mmu_mode' and sprinkling that in kmap_atomic_prot and __kunmap_atomic seems to make the problem go away. This is the patch that looks to be doing the trick. Please double check if it fixes in your guys setup. diff --git a/arch/x86/mm/highmem_32.c b/arch/x86/mm/highmem_32.c index b499626..f4f29b1 100644 --- a/arch/x86/mm/highmem_32.c +++ b/arch/x86/mm/highmem_32.c @@ -45,6 +45,7 @@ void *kmap_atomic_prot(struct page *page, pgprot_t prot) vaddr = __fix_to_virt(FIX_KMAP_BEGIN + idx); BUG_ON(!pte_none(*(kmap_pte-idx))); set_pte(kmap_pte-idx, mk_pte(page, prot)); + arch_flush_lazy_mmu_mode(); return (void *)vaddr; } @@ -88,6 +89,7 @@ void __kunmap_atomic(void *kvaddr) */ kpte_clear_flush(kmap_pte-idx, vaddr); kmap_atomic_idx_pop(); + arch_flush_lazy_mmu_mode(); } #ifdef CONFIG_DEBUG_HIGHMEM else { --WIyZ46R2i8wDzkSu Content-Type: text/x-diff; charset=us-ascii Content-Disposition: attachment; filename="flush.patch" diff --git a/arch/x86/mm/highmem_32.c b/arch/x86/mm/highmem_32.c index b499626..f4f29b1 100644 --- a/arch/x86/mm/highmem_32.c +++ b/arch/x86/mm/highmem_32.c @@ -45,6 +45,7 @@ void *kmap_atomic_prot(struct page *page, pgprot_t prot) vaddr = __fix_to_virt(FIX_KMAP_BEGIN + idx); BUG_ON(!pte_none(*(kmap_pte-idx))); set_pte(kmap_pte-idx, mk_pte(page, prot)); + arch_flush_lazy_mmu_mode(); return (void *)vaddr; } @@ -88,6 +89,7 @@ void __kunmap_atomic(void *kvaddr) */ kpte_clear_flush(kmap_pte-idx, vaddr); kmap_atomic_idx_pop(); + arch_flush_lazy_mmu_mode(); } #ifdef CONFIG_DEBUG_HIGHMEM else { --WIyZ46R2i8wDzkSu Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel --WIyZ46R2i8wDzkSu-- From xen-devel-bounces@lists.xensource.com Thu Sep 22 12:05:08 2011 Return-path: <xen-devel-bounces@lists.xensource.com> Envelope-to: www-data@lists.xensource.com Delivery-date: Thu, 22 Sep 2011 12:05:08 -0700 Received: from localhost ([127.0.0.1] helo=lists.colo.xensource.com) by lists.xensource.com with esmtp (Exim 4.43) id 1R6oa4-0001Io-2E; Thu, 22 Sep 2011 12:05:08 -0700 Received: from mail182.messagelabs.com ([85.158.139.83]) by lists.xensource.com with esmtp (Exim 4.43) id 1R6oW6-0000ts-Hc for xen-devel@lists.xensource.com; Thu, 22 Sep 2011 12:01:16 -0700 X-Env-Sender: konrad@oracle.com X-Msg-Ref: server-11.tower-182.messagelabs.com!1316718056!19389174!1 X-Originating-IP: [141.146.126.227] X-StarScan-Version: 6.4.1; banners=-,-,- X-VirusChecked: Checked Received: (qmail 18362 invoked from network); 22 Sep 2011 19:00:58 -0000 Received: from acsinet15.oracle.com (HELO acsinet15.oracle.com) (141.146.126.227) by server-11.tower-182.messagelabs.com with DHE-RSA-AES256-SHA encrypted SMTP; 22 Sep 2011 19:00:58 -0000 Received: from rtcsinet21.oracle.com (rtcsinet21.oracle.com [66.248.204.29]) by acsinet15.oracle.com (Switch-3.4.4/Switch-3.4.4) with ESMTP id p8MJ0OR5004057 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Thu, 22 Sep 2011 19:00:26 GMT Received: from acsmt358.oracle.com (acsmt358.oracle.com [141.146.40.158]) by rtcsinet21.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id p8MJ0Luj014168 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 22 Sep 2011 19:00:22 GMT Received: from abhmt105.oracle.com (abhmt105.oracle.com [141.146.116.57]) by acsmt358.oracle.com (8.12.11.20060308/8.12.11) with ESMTP id p8MJ0FXk021657; Thu, 22 Sep 2011 14:00:15 -0500 Received: from oracle.com (/209.6.55.207) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Thu, 22 Sep 2011 12:00:15 -0700 Received: by oracle.com (Postfix, from userid 1000) id 9A2471364; Thu, 22 Sep 2011 15:00:18 -0400 (EDT) Date: Thu, 22 Sep 2011 15:00:18 -0400 From: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com> To: Ian Campbell <ijc@hellion.org.uk> Subject: Re: [Xen-devel] Re: Bug#642154: BUG: unable to handle kernel paging request at ffff8803bb6ad000 Message-ID: <20110922190018.GA16678@phenom.oracle.com> References: <20110919210045.3256.61939.reportbug@xen-dom0.xen.irush.su> <20110919212211.GB6343@elie> <CA+rvmvK8G5hNq4wOkPdcDMufYS9bD559zvexMqG9gy=m7dkU_A@mail.gmail.com> <1316524835.4122.8.camel@deadeye> <1316526058.3891.65.camel@zakaz.uk.xensource.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <1316526058.3891.65.camel@zakaz.uk.xensource.com> User-Agent: Mutt/1.5.21 (2010-09-15) X-Source-IP: rtcsinet21.oracle.com [66.248.204.29] X-CT-RefId: str=0001.0A090209.4E7B85CB.0144,ss=1,re=0.000,fgs=0 Cc: Jonathan Nieder <jrnieder@gmail.com>, 642154@bugs.debian.org, xen-devel <xen-devel@lists.xensource.com>, Ben Hutchings <ben@decadent.org.uk> X-BeenThere: xen-devel@lists.xensource.com X-Mailman-Version: 2.1.5 Precedence: list List-Id: Xen developer discussion <xen-devel.lists.xensource.com> List-Unsubscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe> List-Post: <mailto:xen-devel@lists.xensource.com> List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help> List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=subscribe> Sender: xen-devel-bounces@lists.xensource.com Errors-To: xen-devel-bounces@lists.xensource.com > There's been some similar looking threads on xen-devel recently but I > haven't paid attention to the details, list & Konrad CC'd. Full log is > at http://bugs.debian.org/642154. Does xsave=0 make a difference? _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel From xen-devel-bounces@lists.xensource.com Thu Sep 22 12:10:34 2011 Return-path: <xen-devel-bounces@lists.xensource.com> Envelope-to: www-data@lists.xensource.com Delivery-date: Thu, 22 Sep 2011 12:10:34 -0700 Received: from localhost ([127.0.0.1] helo=lists.colo.xensource.com) by lists.xensource.com with esmtp (Exim 4.43) id 1R6ofJ-0001mx-2a; Thu, 22 Sep 2011 12:10:33 -0700 Received: from mail216.messagelabs.com ([85.158.143.99]) by lists.xensource.com with esmtp (Exim 4.43) id 1R6odu-0001aN-Q8; Thu, 22 Sep 2011 12:09:07 -0700 X-Env-Sender: konrad@oracle.com X-Msg-Ref: server-15.tower-216.messagelabs.com!1316718541!18762062!1 X-Originating-IP: [148.87.113.117] X-StarScan-Version: 6.4.1; banners=-,-,- X-VirusChecked: Checked Received: (qmail 2399 invoked from network); 22 Sep 2011 19:09:03 -0000 Received: from rcsinet15.oracle.com (HELO rcsinet15.oracle.com) (148.87.113.117) by server-15.tower-216.messagelabs.com with DHE-RSA-AES256-SHA encrypted SMTP; 22 Sep 2011 19:09:03 -0000 Received: from rtcsinet21.oracle.com (rtcsinet21.oracle.com [66.248.204.29]) by rcsinet15.oracle.com (Switch-3.4.4/Switch-3.4.4) with ESMTP id p8MJ8jk6002028 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Thu, 22 Sep 2011 19:08:47 GMT Received: from acsmt356.oracle.com (acsmt356.oracle.com [141.146.40.156]) by rtcsinet21.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id p8MJ8fHu028938 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 22 Sep 2011 19:08:42 GMT Received: from abhmt120.oracle.com (abhmt120.oracle.com [141.146.116.72]) by acsmt356.oracle.com (8.12.11.20060308/8.12.11) with ESMTP id p8MJ8amM028064; Thu, 22 Sep 2011 14:08:36 -0500 Received: from oracle.com (/209.6.55.207) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Thu, 22 Sep 2011 12:08:35 -0700 Received: by oracle.com (Postfix, from userid 1000) id 7F2B51364; Thu, 22 Sep 2011 15:08:41 -0400 (EDT) Date: Thu, 22 Sep 2011 15:08:41 -0400 From: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com> To: Pasi =?iso-8859-1?Q?K=E4rkk=E4inen?= <pasik@iki.fi> Subject: Re: [Xen-devel] Re: Virtualization Test Day for F16 and Xen Message-ID: <20110922190841.GB16678@phenom.oracle.com> References: <20110914142522.GA16956@phenom.oracle.com> <20110914144539.GR12984@reaktio.net> <20110915151041.GA4453@imp.local> <1316126290.5689.3.camel@adam> <20110916084308.GD884@phenom.oracle.com> <4E77A4EC.9080600@goop.org> <20110921200348.GA31078@phenom.oracle.com> <4E7A6947.5090205@goop.org> <20110921225957.GA17396@phenom.oracle.com> <20110922094757.GB12984@reaktio.net> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline In-Reply-To: <20110922094757.GB12984@reaktio.net> User-Agent: Mutt/1.5.21 (2010-09-15) Content-Transfer-Encoding: quoted-printable X-Source-IP: rtcsinet21.oracle.com [66.248.204.29] X-CT-RefId: str=0001.0A090205.4E7B87C0.00B1,ss=1,re=0.000,fgs=0 Cc: Development discussions related to Fedora <devel@lists.fedoraproject.org>, xen@lists.fedoraproject.org, Jeremy Fitzhardinge <jeremy@goop.org>, xen-devel@lists.xensource.com, Stefano Stabellini <stefano.stabellini@eu.citrix.com>, lars.kurth@xen.org, virt@lists.fedoraproject.org, xen-users@lists.xensource.com, Adam Williamson <awilliam@redhat.com> X-BeenThere: xen-devel@lists.xensource.com X-Mailman-Version: 2.1.5 Precedence: list List-Id: Xen developer discussion <xen-devel.lists.xensource.com> List-Unsubscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe> List-Post: <mailto:xen-devel@lists.xensource.com> List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help> List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=subscribe> Sender: xen-devel-bounces@lists.xensource.com Errors-To: xen-devel-bounces@lists.xensource.com On Thu, Sep 22, 2011 at 12:47:57PM +0300, Pasi K=E4rkk=E4inen wrote: > On Wed, Sep 21, 2011 at 06:59:57PM -0400, Konrad Rzeszutek Wilk wrote: > > On Wed, Sep 21, 2011 at 03:46:31PM -0700, Jeremy Fitzhardinge wrote: > > > On 09/21/2011 01:03 PM, Konrad Rzeszutek Wilk wrote: > > > >>>> So, there's a meta-point here: we currently 'require' Beta rel= eases to > > > >>>> boot as guests on Xen hosts: > > > >>>> > > > >>>> "The release must boot successfully as a virtual guest in a si= tuation > > > >>>> where the virtual host is running a supported Xen implementati= on" > > > >>>> > > > >>>> I really don't have much knowledge of Xen and haven't followed= this > > > >>>> discussion closely, but do any currently-known bugs prevent th= is? If so, > > > >>>> please flag them up so they can be considered as Beta blockers= ...thanks! > > > > I filled Bug 740378 - F16: Can't use keyboard when installing F16= -Alpha under Xen (regression) as guest > > > > which is pretty descripting what is below. > > > > > > > > Also adding in Jeremy's workaround in it. > > >=20 > > > Though I couldn't repro the general problems I was having - I later= did > > > a clean F14 install with no problems. So I don't really know what'= s > > > going on here; I might try another F16 hvm install to see how it go= es. > > >=20 > > > But there is a bona-fide bug that F16 doesn't include xen-platform-= pci > > > by default in its initramfs, so it ends up unplugging its emulated > > > devices without discovering the PV ones to replace them... > >=20 > > Can you open a BZ at bugzilla.redhat.com please? > >=20 >=20 > Also should we change the default xen-platform-pci to =3Dy in upstream = Linux > .config to avoid having problems with every distro ? Or some form of it. Stefano is working to provide a patch that will latch on CONFIG_PVONHVM and make that work. _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel From xen-devel-bounces@lists.xensource.com Thu Sep 22 12:16:05 2011 Return-path: <xen-devel-bounces@lists.xensource.com> Envelope-to: www-data@lists.xensource.com Delivery-date: Thu, 22 Sep 2011 12:16:05 -0700 Received: from localhost ([127.0.0.1] helo=lists.colo.xensource.com) by lists.xensource.com with esmtp (Exim 4.43) id 1R6oke-0002Et-TL; Thu, 22 Sep 2011 12:16:04 -0700 Received: from mail21.messagelabs.com ([85.158.143.35]) by lists.xensource.com with esmtp (Exim 4.43) id 1R6ok7-00022T-4s; Thu, 22 Sep 2011 12:15:31 -0700 X-Env-Sender: pasik@iki.fi X-Msg-Ref: server-9.tower-21.messagelabs.com!1316718882!49442359!1 X-Originating-IP: [192.89.123.25] X-StarScan-Version: 6.4.1; banners=-,-,- X-VirusChecked: Checked Received: (qmail 9157 invoked from network); 22 Sep 2011 19:14:43 -0000 Received: from smtp.tele.fi (HELO smtp.tele.fi) (192.89.123.25) by server-9.tower-21.messagelabs.com with DHE-RSA-AES256-SHA encrypted SMTP; 22 Sep 2011 19:14:43 -0000 X-Originating-Ip: [194.89.68.22] Received: from ydin.reaktio.net (reaktio.net [194.89.68.22]) by smtp.tele.fi (Postfix) with ESMTP id 07FCB1803; Thu, 22 Sep 2011 22:14:54 +0300 (EEST) Received: by ydin.reaktio.net (Postfix, from userid 1001) id 98894200EA; Thu, 22 Sep 2011 22:14:54 +0300 (EEST) Date: Thu, 22 Sep 2011 22:14:54 +0300 From: Pasi =?iso-8859-1?Q?K=E4rkk=E4inen?= <pasik@iki.fi> To: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com> Subject: Re: [Xen-devel] Re: Virtualization Test Day for F16 and Xen Message-ID: <20110922191454.GF12984@reaktio.net> References: <20110914144539.GR12984@reaktio.net> <20110915151041.GA4453@imp.local> <1316126290.5689.3.camel@adam> <20110916084308.GD884@phenom.oracle.com> <4E77A4EC.9080600@goop.org> <20110921200348.GA31078@phenom.oracle.com> <4E7A6947.5090205@goop.org> <20110921225957.GA17396@phenom.oracle.com> <20110922094757.GB12984@reaktio.net> <20110922190841.GB16678@phenom.oracle.com> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <20110922190841.GB16678@phenom.oracle.com> User-Agent: Mutt/1.5.18 (2008-05-17) Cc: Development discussions related to Fedora <devel@lists.fedoraproject.org>, xen@lists.fedoraproject.org, Jeremy Fitzhardinge <jeremy@goop.org>, xen-devel@lists.xensource.com, Stefano Stabellini <stefano.stabellini@eu.citrix.com>, lars.kurth@xen.org, virt@lists.fedoraproject.org, xen-users@lists.xensource.com, Adam Williamson <awilliam@redhat.com> X-BeenThere: xen-devel@lists.xensource.com X-Mailman-Version: 2.1.5 Precedence: list List-Id: Xen developer discussion <xen-devel.lists.xensource.com> List-Unsubscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe> List-Post: <mailto:xen-devel@lists.xensource.com> List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help> List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=subscribe> Sender: xen-devel-bounces@lists.xensource.com Errors-To: xen-devel-bounces@lists.xensource.com On Thu, Sep 22, 2011 at 03:08:41PM -0400, Konrad Rzeszutek Wilk wrote: > On Thu, Sep 22, 2011 at 12:47:57PM +0300, Pasi Kärkkäinen wrote: > > On Wed, Sep 21, 2011 at 06:59:57PM -0400, Konrad Rzeszutek Wilk wrote: > > > On Wed, Sep 21, 2011 at 03:46:31PM -0700, Jeremy Fitzhardinge wrote: > > > > On 09/21/2011 01:03 PM, Konrad Rzeszutek Wilk wrote: > > > > >>>> So, there's a meta-point here: we currently 'require' Beta releases to > > > > >>>> boot as guests on Xen hosts: > > > > >>>> > > > > >>>> "The release must boot successfully as a virtual guest in a situation > > > > >>>> where the virtual host is running a supported Xen implementation" > > > > >>>> > > > > >>>> I really don't have much knowledge of Xen and haven't followed this > > > > >>>> discussion closely, but do any currently-known bugs prevent this? If so, > > > > >>>> please flag them up so they can be considered as Beta blockers...thanks! > > > > > I filled Bug 740378 - F16: Can't use keyboard when installing F16-Alpha under Xen (regression) as guest > > > > > which is pretty descripting what is below. > > > > > > > > > > Also adding in Jeremy's workaround in it. > > > > > > > > Though I couldn't repro the general problems I was having - I later did > > > > a clean F14 install with no problems. So I don't really know what's > > > > going on here; I might try another F16 hvm install to see how it goes. > > > > > > > > But there is a bona-fide bug that F16 doesn't include xen-platform-pci > > > > by default in its initramfs, so it ends up unplugging its emulated > > > > devices without discovering the PV ones to replace them... > > > > > > Can you open a BZ at bugzilla.redhat.com please? > > > > > > > Also should we change the default xen-platform-pci to =y in upstream Linux > > .config to avoid having problems with every distro ? > > Or some form of it. Stefano is working to provide a patch that will latch > on CONFIG_PVONHVM and make that work. > Ok, great! -- Pasi _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel From xen-devel-bounces@lists.xensource.com Thu Sep 22 12:36:00 2011 Return-path: <xen-devel-bounces@lists.xensource.com> Envelope-to: www-data@lists.xensource.com Delivery-date: Thu, 22 Sep 2011 12:36:00 -0700 Received: from localhost ([127.0.0.1] helo=lists.colo.xensource.com) by lists.xensource.com with esmtp (Exim 4.43) id 1R6p3v-00030I-PM; Thu, 22 Sep 2011 12:35:59 -0700 Received: from mail182.messagelabs.com ([85.158.139.83]) by lists.xensource.com with esmtp (Exim 4.43) id 1R6p3A-0002oN-3D for xen-devel@lists.xensource.com; Thu, 22 Sep 2011 12:35:12 -0700 X-Env-Sender: jeremy@goop.org X-Msg-Ref: server-5.tower-182.messagelabs.com!1316720107!14409864!1 X-Originating-IP: [74.207.240.146] X-StarScan-Version: 6.4.1; banners=-,-,- X-VirusChecked: Checked Received: (qmail 32232 invoked from network); 22 Sep 2011 19:35:08 -0000 Received: from claw.goop.org (HELO claw.goop.org) (74.207.240.146) by server-5.tower-182.messagelabs.com with DHE-RSA-AES256-SHA encrypted SMTP; 22 Sep 2011 19:35:08 -0000 Received: from saboo.goop.org (unknown [IPv6:2001:470:1f05:899:186e:d2ff:fef6:9488]) (Authenticated sender: smtp-saboo) by claw.goop.org (Postfix) with ESMTPSA id 9DD1CA35B; Thu, 22 Sep 2011 12:35:06 -0700 (PDT) Received: from saboo.goop.org (localhost [IPv6:::1]) by saboo.goop.org (Postfix) with ESMTP id B00A02025D; Thu, 22 Sep 2011 12:35:04 -0700 (PDT) Message-ID: <4E7B8DE8.1070809@goop.org> Date: Thu, 22 Sep 2011 12:35:04 -0700 From: Jeremy Fitzhardinge <jeremy@goop.org> User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:6.0.2) Gecko/20110906 Thunderbird/6.0.2 MIME-Version: 1.0 To: Ian Campbell <Ian.Campbell@eu.citrix.com> Subject: Re: [Xen-devel] Re: [PATCH] xen: change XEN_PLATFORM_PCI to bool default y References: <1316608670-23167-1-git-send-email-stefano.stabellini@eu.citrix.com> <20110921185102.GJ17357@phenom.oracle.com> <1316632095.5182.33.camel@dagon.hellion.org.uk> <4E7A69DD.1080501@goop.org> <1316672473.27431.0.camel@dagon.hellion.org.uk> In-Reply-To: <1316672473.27431.0.camel@dagon.hellion.org.uk> X-Enigmail-Version: 1.3.2 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>, Stefano Stabellini <Stefano.Stabellini@eu.citrix.com>, Konrad Rzeszutek Wilk <konrad.wilk@oracle.com> X-BeenThere: xen-devel@lists.xensource.com X-Mailman-Version: 2.1.5 Precedence: list List-Id: Xen developer discussion <xen-devel.lists.xensource.com> List-Unsubscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe> List-Post: <mailto:xen-devel@lists.xensource.com> List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help> List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=subscribe> Sender: xen-devel-bounces@lists.xensource.com Errors-To: xen-devel-bounces@lists.xensource.com On 09/21/2011 11:21 PM, Ian Campbell wrote: > On Wed, 2011-09-21 at 23:49 +0100, Jeremy Fitzhardinge wrote: >>> That would work too. Even better would be to make it an invisible >>> Kconfig symbol which PVHVM just selects. >> Eh, select is pretty nasty. > Select of a non user visible symbol is perfectly fine. It's only when > you select something a user can also set that things get nasty. It doesn't matter if its user-visible. If the selected symbol acquires other dependencies, the selection won't set them. J _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel From xen-devel-bounces@lists.xensource.com Thu Sep 22 13:05:38 2011 Return-path: <xen-devel-bounces@lists.xensource.com> Envelope-to: www-data@lists.xensource.com Delivery-date: Thu, 22 Sep 2011 13:05:38 -0700 Received: from localhost ([127.0.0.1] helo=lists.colo.xensource.com) by lists.xensource.com with esmtp (Exim 4.43) id 1R6pWc-0004dc-HT; Thu, 22 Sep 2011 13:05:38 -0700 Received: from mail174.messagelabs.com ([85.158.138.51]) by lists.xensource.com with smtp (Exim 4.43) id 1R6pTo-0004Lg-8Q for xen-devel@lists.xensource.com; Thu, 22 Sep 2011 13:03:30 -0700 X-Env-Sender: caker@theshore.net X-Msg-Ref: server-11.tower-174.messagelabs.com!1316721760!32406670!1 X-Originating-IP: [67.18.92.50] X-StarScan-Version: 6.4.1; banners=-,-,- X-VirusChecked: Checked Received: (qmail 19102 invoked from network); 22 Sep 2011 20:02:40 -0000 Received: from ns.theshore.net (HELO www.theshore.net) (67.18.92.50) by server-11.tower-174.messagelabs.com with SMTP; 22 Sep 2011 20:02:40 -0000 Received: from beefcake.linlan (173-161-199-49-Philadelphia.hfc.comcastbusiness.net [173.161.199.49]) by www.theshore.net (8.13.6/8.9.1) with ESMTP id p8MK2Z32010626; Thu, 22 Sep 2011 16:02:35 -0400 Message-ID: <4E7B945B.1020608@theshore.net> Date: Thu, 22 Sep 2011 16:02:35 -0400 From: "Christopher S. Aker" <caker@theshore.net> User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.6; en-US; rv:1.9.2.22) Gecko/20110902 Lightning/1.0b2 Thunderbird/3.1.14 MIME-Version: 1.0 To: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com> Subject: Re: [Xen-devel] Re: kernel BUG at mm/swapfile.c:2527! [was 3.0.0 Xen pv guest - BUG: Unable to handle] References: <9CAEB881-07FE-437C-8A6B-DB7B690CEABE@linode.com> <4E5BA49D.5060800@theshore.net> <20110829150734.GB24825@dumpdata.com> <1314704744.28989.2.camel@zakaz.uk.xensource.com> <4E5E9CDB.3070706@theshore.net> <20110922183232.GA23825@phenom.oracle.com> In-Reply-To: <20110922183232.GA23825@phenom.oracle.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>, Jeremy Fitzhardinge <jeremy@goop.org>, Shaun R <mailinglists@unix-scripts.com>, Ian Campbell <Ian.Campbell@citrix.com>, LKML <linux-kernel@vger.kernel.org> X-BeenThere: xen-devel@lists.xensource.com X-Mailman-Version: 2.1.5 Precedence: list List-Id: Xen developer discussion <xen-devel.lists.xensource.com> List-Unsubscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe> List-Post: <mailto:xen-devel@lists.xensource.com> List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help> List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=subscribe> Sender: xen-devel-bounces@lists.xensource.com Errors-To: xen-devel-bounces@lists.xensource.com On 9/22/11 2:32 PM, Konrad Rzeszutek Wilk wrote: > This is the patch that looks to be doing the trick. Please double check > if it fixes in your guys setup. So far it's looking good. Before I was able to BUG it within 2 or 3 minutes. This patched kernel has held up for the past hour and counting. Nice work, and many thanks! -Chris _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel From xen-devel-bounces@lists.xensource.com Thu Sep 22 13:07:04 2011 Return-path: <xen-devel-bounces@lists.xensource.com> Envelope-to: www-data@lists.xensource.com Delivery-date: Thu, 22 Sep 2011 13:07:04 -0700 Received: from localhost ([127.0.0.1] helo=lists.colo.xensource.com) by lists.xensource.com with esmtp (Exim 4.43) id 1R6pY0-00051C-Dm; Thu, 22 Sep 2011 13:07:04 -0700 Received: from mail27.messagelabs.com ([193.109.254.147]) by lists.xensource.com with esmtp (Exim 4.43) id 1R6pUd-0004Pw-PM for xen-devel@lists.xensource.com; Thu, 22 Sep 2011 13:03:38 -0700 X-Env-Sender: Ian.Jackson@eu.citrix.com X-Msg-Ref: server-10.tower-27.messagelabs.com!1316721792!36859320!1 X-Originating-IP: [62.200.22.115] X-StarScan-Version: 6.4.1; banners=-,-,- X-VirusChecked: Checked Received: (qmail 27530 invoked from network); 22 Sep 2011 20:03:12 -0000 Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115) by server-10.tower-27.messagelabs.com with RC4-SHA encrypted SMTP; 22 Sep 2011 20:03:12 -0000 X-IronPort-AV: E=Sophos;i="4.68,425,1312156800"; d="scan'208";a="8017543" Received: from lonpmailmx01.citrite.net ([10.30.203.162]) by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5; 22 Sep 2011 20:03:32 +0000 Received: from woking.xci-test.com (10.80.248.135) by smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id 8.3.137.0; Thu, 22 Sep 2011 21:03:32 +0100 Received: from osstest by woking.xci-test.com with local (Exim 4.69) (envelope-from <ian.jackson@eu.citrix.com>) id 1R6pUa-0000AR-0O; Thu, 22 Sep 2011 21:03:32 +0100 To: xen-devel@lists.xensource.com Message-ID: <osstest-8999-mainreport@xen.org> From: xen.org <ian.jackson@eu.citrix.com> Date: Thu, 22 Sep 2011 21:03:32 +0100 MIME-Version: 1.0 Content-Type: text/plain Cc: ian.jackson@eu.citrix.com Subject: [Xen-devel] [linux test] 8999: tolerable FAIL X-BeenThere: xen-devel@lists.xensource.com X-Mailman-Version: 2.1.5 Precedence: list List-Id: Xen developer discussion <xen-devel.lists.xensource.com> List-Unsubscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe> List-Post: <mailto:xen-devel@lists.xensource.com> List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help> List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=subscribe> Sender: xen-devel-bounces@lists.xensource.com Errors-To: xen-devel-bounces@lists.xensource.com flight 8999 linux real [real] http://www.chiark.greenend.org.uk/~xensrcts/logs/8999/ Failures :-/ but no regressions. Tests which are failing intermittently (not blocking): test-amd64-amd64-xl-sedf 14 guest-localmigrate/x10 fail pass in 8998 Tests which did not succeed, but are not blocking, including regressions (tests previously passed) regarded as allowable: test-amd64-amd64-xl-pcipt-intel 9 guest-start fail never pass test-amd64-i386-rhel6hvm-amd 9 guest-start.2 fail never pass test-amd64-i386-rhel6hvm-intel 9 guest-start.2 fail never pass test-amd64-i386-win-vcpus1 16 leak-check/check fail never pass test-amd64-i386-xl-win-vcpus1 13 guest-stop fail never pass test-amd64-amd64-win 16 leak-check/check fail never pass test-amd64-amd64-xl-win 13 guest-stop fail never pass test-i386-i386-xl-win 13 guest-stop fail never pass test-i386-i386-win 14 guest-start.2 fail like 8764 test-amd64-i386-win 16 leak-check/check fail never pass test-i386-i386-win 16 leak-check/check fail in 8998 never pass version targeted for testing: linux 6bec8b4a4c14095d0b7ce424db9d583c3decae6c baseline version: linux 1c3f03ccc5258887f5f2cafc0836a865834f9205 ------------------------------------------------------------ People who touched revisions under test: Jeremy Fitzhardinge <jeremy.fitzhardinge@citrix.com> ------------------------------------------------------------ jobs: build-amd64 pass build-i386 pass build-amd64-pvops pass build-i386-pvops pass test-amd64-amd64-xl pass test-amd64-i386-xl pass test-i386-i386-xl pass test-amd64-i386-rhel6hvm-amd fail test-amd64-i386-xl-credit2 pass test-amd64-amd64-xl-pcipt-intel fail test-amd64-i386-rhel6hvm-intel fail test-amd64-i386-xl-multivcpu pass test-amd64-amd64-pair pass test-amd64-i386-pair pass test-i386-i386-pair pass test-amd64-amd64-pv pass test-amd64-i386-pv pass test-i386-i386-pv pass test-amd64-amd64-xl-sedf fail test-amd64-i386-win-vcpus1 fail test-amd64-i386-xl-win-vcpus1 fail test-amd64-amd64-win fail test-amd64-i386-win fail test-i386-i386-win fail test-amd64-amd64-xl-win fail test-i386-i386-xl-win fail ------------------------------------------------------------ sg-report-flight on woking.cam.xci-test.com logs: /home/xc_osstest/logs images: /home/xc_osstest/images Logs, config files, etc. are available at http://www.chiark.greenend.org.uk/~xensrcts/logs Test harness code can be found at http://xenbits.xensource.com/gitweb?p=osstest.git;a=summary Pushing revision : + branch=linux + revision=6bec8b4a4c14095d0b7ce424db9d583c3decae6c + . cri-lock-repos ++ . cri-common +++ umask 002 +++ getconfig Repos +++ perl -e ' use Osstest; readconfigonly(); print $c{Repos} or die $!; ' ++ repos=/export/home/osstest/repos ++ repos_lock=/export/home/osstest/repos/lock ++ '[' x '!=' x/export/home/osstest/repos/lock ']' ++ OSSTEST_REPOS_LOCK_LOCKED=/export/home/osstest/repos/lock ++ exec with-lock-ex -w /export/home/osstest/repos/lock ./ap-push linux 6bec8b4a4c14095d0b7ce424db9d583c3decae6c + branch=linux + revision=6bec8b4a4c14095d0b7ce424db9d583c3decae6c + . cri-lock-repos ++ . cri-common +++ umask 002 +++ getconfig Repos +++ perl -e ' use Osstest; readconfigonly(); print $c{Repos} or die $!; ' ++ repos=/export/home/osstest/repos ++ repos_lock=/export/home/osstest/repos/lock ++ '[' x/export/home/osstest/repos/lock '!=' x/export/home/osstest/repos/lock ']' + : xen@xenbits.xensource.com + : xen@xenbits.xensource.com:git/linux-pvops + : master + : tested/2.6.39.x + case "$branch" in + cd /export/home/osstest/repos/xen ./ap-push: line 20: cd: /export/home/osstest/repos/xen: No such file or directory ------------------------------------------------------------ commit 6bec8b4a4c14095d0b7ce424db9d583c3decae6c Author: Jeremy Fitzhardinge <jeremy.fitzhardinge@citrix.com> Date: Fri Sep 2 12:23:22 2011 -0700 Revert "xen/apic: Provide an 'apic_xen' to set the override the apic->[read|write] for all cases." This reverts commit c3dd7941354fa96a71f2613e2c7a1b215fa175dc. It prevents the kernel from booting natively on hardware. Conflicts: arch/x86/xen/enlighten.c Signed-off-by: Jeremy Fitzhardinge <jeremy.fitzhardinge@citrix.com> _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel From xen-devel-bounces@lists.xensource.com Thu Sep 22 13:16:27 2011 Return-path: <xen-devel-bounces@lists.xensource.com> Envelope-to: www-data@lists.xensource.com Delivery-date: Thu, 22 Sep 2011 13:16:27 -0700 Received: from localhost ([127.0.0.1] helo=lists.colo.xensource.com) by lists.xensource.com with esmtp (Exim 4.43) id 1R6ph4-00069q-Uh; Thu, 22 Sep 2011 13:16:26 -0700 Received: from mail21.messagelabs.com ([85.158.143.35]) by lists.xensource.com with esmtp (Exim 4.43) id 1R6pge-0005xa-UK for xen-devel@lists.xensource.com; Thu, 22 Sep 2011 13:16:01 -0700 X-Env-Sender: burns.me.uk@gmail.com X-Msg-Ref: server-11.tower-21.messagelabs.com!1316722539!43619283!1 X-Originating-IP: [209.85.220.171] X-StarScan-Version: 6.4.1; banners=-,-,- X-VirusChecked: Checked Received: (qmail 11491 invoked from network); 22 Sep 2011 20:15:40 -0000 Received: from mail-vx0-f171.google.com (HELO mail-vx0-f171.google.com) (209.85.220.171) by server-11.tower-21.messagelabs.com with RC4-SHA encrypted SMTP; 22 Sep 2011 20:15:40 -0000 Received: by vcbfk12 with SMTP id fk12so1076606vcb.30 for <xen-devel@lists.xensource.com>; Thu, 22 Sep 2011 13:15:56 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:content-type :content-transfer-encoding; bh=rQwl+aPO9gIeFE9KdXOO6ZL0qPxa6ohWyHF2VcIiySU=; b=b5LJYiL+2WCvIGRgZcLifL/utfEI4bHjuZ3eR9fO8OpAL38GMtY7xdxhPl0BcrBxpW zshw3UTHkh/NNg85sVARqXGlVzKVq9VUVcBKKYfJJnLQ2iYUL472tQfNeLW/9yEm6hhD U3kfcoUkAR9ZO9zH70VtTYweAA/vXwku++Wdg= MIME-Version: 1.0 Received: by 10.52.72.193 with SMTP id f1mr2289136vdv.284.1316722556710; Thu, 22 Sep 2011 13:15:56 -0700 (PDT) Received: by 10.52.169.201 with HTTP; Thu, 22 Sep 2011 13:15:56 -0700 (PDT) In-Reply-To: <CAE1-PRcBZpmX-c8Z-C50g83_S4Y1k+P7aQzzhWEYU4Pwo0LqMQ@mail.gmail.com> References: <201107231426.56811.jim_burn@bellsouth.net> <1342436.B0x3ddQn4U@dell4550> <20110913085559.GG12984@reaktio.net> <1856036.eYCcuDQrZC@dell4550> <20110914090806.GD25628@phenom.oracle.com> <20110914105711.GA16284@phenom.oracle.com> <CAE1-PRfFwJh1WotLL5GD+L=Vn-zwZctqa+Rhzs2tqMavw1j-WQ@mail.gmail.com> <CAE1-PRdQ37dg6BX+1JGA2mvviNu8t-iAZHVoDKrvg53H_jyztw@mail.gmail.com> <20110921180313.GB17357@phenom.oracle.com> <CAE1-PRcBZpmX-c8Z-C50g83_S4Y1k+P7aQzzhWEYU4Pwo0LqMQ@mail.gmail.com> Date: Thu, 22 Sep 2011 21:15:56 +0100 X-Google-Sender-Auth: 4yAFxTj0XZKbmKC6NAzV8iVXeEQ Message-ID: <CAE1-PRfXEypFFZCD5agaq-RvwSWcgp=QAct3BbaQUngUjjEF-w@mail.gmail.com> Subject: Re: [Xen-devel] Re: [Xen-users] Continuing BUG:-iness booting Fedora Rawhide 3.1.0-rc's (was Summary: Experiences setting up a debug serial port) From: Andy Burns <xen.lists@burns.me.uk> To: xen-devel@lists.xensource.com Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable X-BeenThere: xen-devel@lists.xensource.com X-Mailman-Version: 2.1.5 Precedence: list List-Id: Xen developer discussion <xen-devel.lists.xensource.com> List-Unsubscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe> List-Post: <mailto:xen-devel@lists.xensource.com> List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help> List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=subscribe> Sender: xen-devel-bounces@lists.xensource.com Errors-To: xen-devel-bounces@lists.xensource.com On 21 September 2011 20:43, Andy Burns <xen.lists@burns.me.uk> wrote: > Yep, can confirm that adding a dom0_mem=3D limit prevents the crash, > will build an -rc6 =A0kernel with both the mutex patch and the don't > tweak extra pages patch later Oh look, 3.1.0-rc7 beat me to it, just tested from koji and it boots fine as dom0 and baremetal. _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel From xen-devel-bounces@lists.xensource.com Thu Sep 22 13:23:07 2011 Return-path: <xen-devel-bounces@lists.xensource.com> Envelope-to: www-data@lists.xensource.com Delivery-date: Thu, 22 Sep 2011 13:23:07 -0700 Received: from localhost ([127.0.0.1] helo=lists.colo.xensource.com) by lists.xensource.com with esmtp (Exim 4.43) id 1R6pnX-0006cK-3b; Thu, 22 Sep 2011 13:23:07 -0700 Received: from mail216.messagelabs.com ([85.158.143.99]) by lists.xensource.com with esmtp (Exim 4.43) id 1R6pmY-0006Pn-Gn for xen-devel@lists.xensource.com; Thu, 22 Sep 2011 13:22:06 -0700 X-Env-Sender: konrad@oracle.com X-Msg-Ref: server-14.tower-216.messagelabs.com!1316722921!19276939!1 X-Originating-IP: [148.87.113.117] X-StarScan-Version: 6.4.1; banners=-,-,- X-VirusChecked: Checked Received: (qmail 7999 invoked from network); 22 Sep 2011 20:22:03 -0000 Received: from rcsinet15.oracle.com (HELO rcsinet15.oracle.com) (148.87.113.117) by server-14.tower-216.messagelabs.com with DHE-RSA-AES256-SHA encrypted SMTP; 22 Sep 2011 20:22:03 -0000 Received: from acsinet22.oracle.com (acsinet22.oracle.com [141.146.126.238]) by rcsinet15.oracle.com (Switch-3.4.4/Switch-3.4.4) with ESMTP id p8MKLvlb008951 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Thu, 22 Sep 2011 20:21:59 GMT Received: from acsmt357.oracle.com (acsmt357.oracle.com [141.146.40.157]) by acsinet22.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id p8MKLuAq014852 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 22 Sep 2011 20:21:57 GMT Received: from abhmt109.oracle.com (abhmt109.oracle.com [141.146.116.61]) by acsmt357.oracle.com (8.12.11.20060308/8.12.11) with ESMTP id p8MKLp5R000555; Thu, 22 Sep 2011 15:21:51 -0500 Received: from oracle.com (/209.6.55.207) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Thu, 22 Sep 2011 13:21:51 -0700 Received: by oracle.com (Postfix, from userid 1000) id AF40F1364; Thu, 22 Sep 2011 16:21:58 -0400 (EDT) Date: Thu, 22 Sep 2011 16:21:58 -0400 From: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com> To: Andy Burns <xen.lists@burns.me.uk> Subject: Re: [Xen-devel] Re: [Xen-users] Continuing BUG:-iness booting Fedora Rawhide 3.1.0-rc's (was Summary: Experiences setting up a debug serial port) Message-ID: <20110922202158.GA13381@phenom.oracle.com> References: <1342436.B0x3ddQn4U@dell4550> <20110913085559.GG12984@reaktio.net> <1856036.eYCcuDQrZC@dell4550> <20110914090806.GD25628@phenom.oracle.com> <20110914105711.GA16284@phenom.oracle.com> <CAE1-PRfFwJh1WotLL5GD+L=Vn-zwZctqa+Rhzs2tqMavw1j-WQ@mail.gmail.com> <CAE1-PRdQ37dg6BX+1JGA2mvviNu8t-iAZHVoDKrvg53H_jyztw@mail.gmail.com> <20110921180313.GB17357@phenom.oracle.com> <CAE1-PRcBZpmX-c8Z-C50g83_S4Y1k+P7aQzzhWEYU4Pwo0LqMQ@mail.gmail.com> <CAE1-PRfXEypFFZCD5agaq-RvwSWcgp=QAct3BbaQUngUjjEF-w@mail.gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline In-Reply-To: <CAE1-PRfXEypFFZCD5agaq-RvwSWcgp=QAct3BbaQUngUjjEF-w@mail.gmail.com> User-Agent: Mutt/1.5.21 (2010-09-15) Content-Transfer-Encoding: quoted-printable X-Source-IP: acsinet22.oracle.com [141.146.126.238] X-Auth-Type: Internal IP X-CT-RefId: str=0001.0A090205.4E7B98E7.00CE:SCFMA922111,ss=1,re=-4.000,fgs=0 Cc: xen-devel@lists.xensource.com X-BeenThere: xen-devel@lists.xensource.com X-Mailman-Version: 2.1.5 Precedence: list List-Id: Xen developer discussion <xen-devel.lists.xensource.com> List-Unsubscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe> List-Post: <mailto:xen-devel@lists.xensource.com> List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help> List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=subscribe> Sender: xen-devel-bounces@lists.xensource.com Errors-To: xen-devel-bounces@lists.xensource.com On Thu, Sep 22, 2011 at 09:15:56PM +0100, Andy Burns wrote: > On 21 September 2011 20:43, Andy Burns <xen.lists@burns.me.uk> wrote: >=20 > > Yep, can confirm that adding a dom0_mem=3D limit prevents the crash, > > will build an -rc6 =A0kernel with both the mutex patch and the don't > > tweak extra pages patch later >=20 > Oh look, 3.1.0-rc7 beat me to it, just tested from koji and it boots > fine as dom0 and baremetal. Great! Thanks for testing and confirming! _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel From xen-devel-bounces@lists.xensource.com Thu Sep 22 13:44:57 2011 Return-path: <xen-devel-bounces@lists.xensource.com> Envelope-to: www-data@lists.xensource.com Delivery-date: Thu, 22 Sep 2011 13:44:57 -0700 Received: from localhost ([127.0.0.1] helo=lists.colo.xensource.com) by lists.xensource.com with esmtp (Exim 4.43) id 1R6q8f-0007Ti-Bn; Thu, 22 Sep 2011 13:44:57 -0700 Received: from mail174.messagelabs.com ([85.158.138.51]) by lists.xensource.com with esmtp (Exim 4.43) id 1R6q80-0007Hb-2V; Thu, 22 Sep 2011 13:44:16 -0700 X-Env-Sender: pasik@iki.fi X-Msg-Ref: server-6.tower-174.messagelabs.com!1316724252!30276377!1 X-Originating-IP: [192.89.123.25] X-StarScan-Version: 6.4.1; banners=-,-,- X-VirusChecked: Checked Received: (qmail 14549 invoked from network); 22 Sep 2011 20:44:12 -0000 Received: from smtp.tele.fi (HELO smtp.tele.fi) (192.89.123.25) by server-6.tower-174.messagelabs.com with DHE-RSA-AES256-SHA encrypted SMTP; 22 Sep 2011 20:44:12 -0000 X-Originating-Ip: [194.89.68.22] Received: from ydin.reaktio.net (reaktio.net [194.89.68.22]) by smtp.tele.fi (Postfix) with ESMTP id 9D420261F; Thu, 22 Sep 2011 23:44:09 +0300 (EEST) Received: by ydin.reaktio.net (Postfix, from userid 1001) id 60756200EA; Thu, 22 Sep 2011 23:44:09 +0300 (EEST) Date: Thu, 22 Sep 2011 23:44:09 +0300 From: Pasi =?iso-8859-1?Q?K=E4rkk=E4inen?= <pasik@iki.fi> To: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com> Subject: Re: [Xen-devel] Re: Virtualization Test Day for F16 and Xen Message-ID: <20110922204409.GG12984@reaktio.net> References: <CAN0j7xqm5BatDtXaurYZWvb-6ibG2V10aQ5Qck+9P7DjciWLwQ@mail.gmail.com> <20110914112552.GP12984@reaktio.net> <20110914142522.GA16956@phenom.oracle.com> <20110914144539.GR12984@reaktio.net> <20110915151041.GA4453@imp.local> <1316126290.5689.3.camel@adam> <20110916084308.GD884@phenom.oracle.com> <4E77A4EC.9080600@goop.org> <20110921200348.GA31078@phenom.oracle.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20110921200348.GA31078@phenom.oracle.com> User-Agent: Mutt/1.5.18 (2008-05-17) Cc: Development discussions related to Fedora <devel@lists.fedoraproject.org>, xen@lists.fedoraproject.org, Jeremy Fitzhardinge <jeremy@goop.org>, xen-devel@lists.xensource.com, Stefano Stabellini <stefano.stabellini@eu.citrix.com>, lars.kurth@xen.org, virt@lists.fedoraproject.org, xen-users@lists.xensource.com, Adam Williamson <awilliam@redhat.com> X-BeenThere: xen-devel@lists.xensource.com X-Mailman-Version: 2.1.5 Precedence: list List-Id: Xen developer discussion <xen-devel.lists.xensource.com> List-Unsubscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe> List-Post: <mailto:xen-devel@lists.xensource.com> List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help> List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=subscribe> Sender: xen-devel-bounces@lists.xensource.com Errors-To: xen-devel-bounces@lists.xensource.com On Wed, Sep 21, 2011 at 04:03:49PM -0400, Konrad Rzeszutek Wilk wrote: > > >> So, there's a meta-point here: we currently 'require' Beta releases to > > >> boot as guests on Xen hosts: > > >> > > >> "The release must boot successfully as a virtual guest in a situation > > >> where the virtual host is running a supported Xen implementation" > > >> > > >> I really don't have much knowledge of Xen and haven't followed this > > >> discussion closely, but do any currently-known bugs prevent this? If so, > > >> please flag them up so they can be considered as Beta blockers...thanks! > > I filled Bug 740378 - F16: Can't use keyboard when installing F16-Alpha under Xen (regression) as guest > which is pretty descripting what is below. > > Also adding in Jeremy's workaround in it. > > Besides that, there is also > 738085 - Patch to reduce spurious Xen entries in grub menu > > which has a patch to fix the grub2 menu-thingy.. > I also filed the F16 Xen pvfb problem on rhel5 dom0: "Fedora 16 beta Xen pvfb graphical console does not work on rhel5 dom0": https://bugzilla.redhat.com/show_bug.cgi?id=740657 -- Pasi _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel From xen-devel-bounces@lists.xensource.com Thu Sep 22 14:21:10 2011 Return-path: <xen-devel-bounces@lists.xensource.com> Envelope-to: www-data@lists.xensource.com Delivery-date: Thu, 22 Sep 2011 14:21:10 -0700 Received: from localhost ([127.0.0.1] helo=lists.colo.xensource.com) by lists.xensource.com with esmtp (Exim 4.43) id 1R6qhg-00007b-So; Thu, 22 Sep 2011 14:21:09 -0700 Received: from mail21.messagelabs.com ([85.158.143.35]) by lists.xensource.com with esmtp (Exim 4.43) id 1R6qgg-0008Ms-8Y for xen-devel@lists.xensource.com; Thu, 22 Sep 2011 14:20:09 -0700 X-Env-Sender: jeremy@goop.org X-Msg-Ref: server-14.tower-21.messagelabs.com!1316726393!60614555!1 X-Originating-IP: [74.207.240.146] X-StarScan-Version: 6.4.1; banners=-,-,- X-VirusChecked: Checked Received: (qmail 2891 invoked from network); 22 Sep 2011 21:19:54 -0000 Received: from claw.goop.org (HELO claw.goop.org) (74.207.240.146) by server-14.tower-21.messagelabs.com with DHE-RSA-AES256-SHA encrypted SMTP; 22 Sep 2011 21:19:54 -0000 Received: from saboo.goop.org (unknown [IPv6:2001:470:1f05:899:186e:d2ff:fef6:9488]) (Authenticated sender: smtp-saboo) by claw.goop.org (Postfix) with ESMTPSA id B0B07A40B; Thu, 22 Sep 2011 14:20:00 -0700 (PDT) Received: from saboo.goop.org (localhost [IPv6:::1]) by saboo.goop.org (Postfix) with ESMTP id 6919620505; Thu, 22 Sep 2011 14:19:51 -0700 (PDT) Message-ID: <4E7BA677.9090907@goop.org> Date: Thu, 22 Sep 2011 14:19:51 -0700 From: Jeremy Fitzhardinge <jeremy@goop.org> User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:6.0.2) Gecko/20110906 Thunderbird/6.0.2 MIME-Version: 1.0 To: Stefano Stabellini <stefano.stabellini@eu.citrix.com> Subject: Re: [Xen-devel] Re: [PATCH 0/6] xen: don't call vmalloc_sync_all() when mapping foreign pages References: <1316090411-22608-1-git-send-email-david.vrabel@citrix.com> <4E727017.4030001@goop.org> <alpine.DEB.2.00.1109211124050.8700@kaball-desktop> <4E7A3394.3090806@goop.org> <alpine.DEB.2.00.1109221131390.8700@kaball-desktop> In-Reply-To: <alpine.DEB.2.00.1109221131390.8700@kaball-desktop> X-Enigmail-Version: 1.3.2 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: Andrew Morton <akpm@linux-foundation.org>, "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>, "linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>, Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>, David Vrabel <david.vrabel@citrix.com> X-BeenThere: xen-devel@lists.xensource.com X-Mailman-Version: 2.1.5 Precedence: list List-Id: Xen developer discussion <xen-devel.lists.xensource.com> List-Unsubscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe> List-Post: <mailto:xen-devel@lists.xensource.com> List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help> List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=subscribe> Sender: xen-devel-bounces@lists.xensource.com Errors-To: xen-devel-bounces@lists.xensource.com On 09/22/2011 04:06 AM, Stefano Stabellini wrote: > On Wed, 21 Sep 2011, Jeremy Fitzhardinge wrote: >> On 09/21/2011 03:42 AM, Stefano Stabellini wrote: >>> On Thu, 15 Sep 2011, Jeremy Fitzhardinge wrote: >>>> This series is relying on regular ram mappings are already synced to all >>>> tasks, but I'm not sure that's necessarily guaranteed (for example, if >>>> you hotplug new memory into the domain, the new pages won't be mapped >>>> into every mm unless they're synced). >>> the series is using GFP_KERNEL, so this problem shouldn't occur, right? >> What properties do you think GFP_KERNEL guarantees? > That the memory is below 4G and always mapped in the kernel 1:1 region. Hm, but that's not quite the same thing as "mapped into every pagetable". Lowmem pages always have a kernel virtual address, and its always OK to touch them at any point in kernel code[*] because one can rely on the fault handler to create mappings as needed - but that doesn't mean they're necessarily mapped by present ptes in the current pagetable. [*] - except NMI handlers > Regarding memory hotplug it looks like that x86_32 is mapping new memory > ZONE_HIGHMEM, therefore avoiding any problems with GFP_KERNEL allocations. > On the other hand x86_64 is mapping the memory ZONE_NORMAL and calling > init_memory_mapping on the new range right away. AFAICT changes to > the 1:1 mapping in init_mm are automatically synced across all mm's > because the pgd is shared? TBH I'm not sure. vmalloc_sync_one/all does seem to do *something* on 64-bit, but I was never completely sure what regions of the address space were already shared. I *think* it might be that the pgd and pud are not shared, but the pmd down is, so if you add a new pmd you need to sync it into all the puds (and puds into pgds if you add a new one of those). But I'd be happier pretending that vmalloc_sync_* just doesn't exist, and deal with it at the hypercall level - in the short term, by just making sure that the callers touch all those pages before passing them into the hypercall. J _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel From xen-devel-bounces@lists.xensource.com Thu Sep 22 14:49:42 2011 Return-path: <xen-devel-bounces@lists.xensource.com> Envelope-to: www-data@lists.xensource.com Delivery-date: Thu, 22 Sep 2011 14:49:42 -0700 Received: from localhost ([127.0.0.1] helo=lists.colo.xensource.com) by lists.xensource.com with esmtp (Exim 4.43) id 1R6r9K-00017u-LK; Thu, 22 Sep 2011 14:49:42 -0700 Received: from mail182.messagelabs.com ([85.158.139.83]) by lists.xensource.com with esmtp (Exim 4.43) id 1R6r8X-0000v8-E3 for xen-devel@lists.xensource.com; Thu, 22 Sep 2011 14:48:54 -0700 X-Env-Sender: Ian.Jackson@eu.citrix.com X-Msg-Ref: server-10.tower-182.messagelabs.com!1316728130!19379984!1 X-Originating-IP: [62.200.22.115] X-StarScan-Version: 6.4.1; banners=-,-,- X-VirusChecked: Checked Received: (qmail 28547 invoked from network); 22 Sep 2011 21:48:50 -0000 Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115) by server-10.tower-182.messagelabs.com with RC4-SHA encrypted SMTP; 22 Sep 2011 21:48:50 -0000 X-IronPort-AV: E=Sophos;i="4.68,425,1312156800"; d="scan'208";a="8018234" Received: from lonpmailmx01.citrite.net ([10.30.203.162]) by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5; 22 Sep 2011 21:48:50 +0000 Received: from woking.xci-test.com (10.80.248.135) by smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id 8.3.137.0; Thu, 22 Sep 2011 22:48:49 +0100 Received: from osstest by woking.xci-test.com with local (Exim 4.69) (envelope-from <ian.jackson@eu.citrix.com>) id 1R6r8T-0001Zj-Kg; Thu, 22 Sep 2011 22:48:49 +0100 To: xen-devel@lists.xensource.com Message-ID: <osstest-9000-mainreport@xen.org> From: xen.org <ian.jackson@eu.citrix.com> Date: Thu, 22 Sep 2011 22:48:49 +0100 MIME-Version: 1.0 Content-Type: text/plain Cc: ian.jackson@eu.citrix.com Subject: [Xen-devel] [xen-unstable test] 9000: regressions - FAIL X-BeenThere: xen-devel@lists.xensource.com X-Mailman-Version: 2.1.5 Precedence: list List-Id: Xen developer discussion <xen-devel.lists.xensource.com> List-Unsubscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe> List-Post: <mailto:xen-devel@lists.xensource.com> List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help> List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=subscribe> Sender: xen-devel-bounces@lists.xensource.com Errors-To: xen-devel-bounces@lists.xensource.com flight 9000 xen-unstable real [real] http://www.chiark.greenend.org.uk/~xensrcts/logs/9000/ Regressions :-( Tests which did not succeed and are blocking: test-amd64-amd64-pv 5 xen-boot fail REGR. vs. 8995 test-amd64-i386-rhel6hvm-amd 5 xen-boot fail REGR. vs. 8995 test-i386-i386-pv 5 xen-boot fail REGR. vs. 8995 test-amd64-i386-xl-multivcpu 5 xen-boot fail REGR. vs. 8995 test-amd64-i386-xl-win-vcpus1 5 xen-boot fail REGR. vs. 8995 test-i386-i386-win 5 xen-boot fail REGR. vs. 8995 test-i386-i386-pair 8 xen-boot/dst_host fail REGR. vs. 8995 test-i386-i386-pair 7 xen-boot/src_host fail REGR. vs. 8995 test-amd64-i386-win-vcpus1 5 xen-boot fail REGR. vs. 8995 test-amd64-amd64-xl-win 5 xen-boot fail REGR. vs. 8995 Tests which did not succeed, but are not blocking, including regressions (tests previously passed) regarded as allowable: test-amd64-amd64-xl-pcipt-intel 9 guest-start fail never pass test-amd64-i386-rhel6hvm-intel 9 guest-start.2 fail never pass test-i386-i386-xl-win 13 guest-stop fail never pass test-amd64-amd64-win 16 leak-check/check fail never pass test-amd64-i386-win 16 leak-check/check fail never pass version targeted for testing: xen cc339ab1d917 baseline version: xen a422e2a4451e ------------------------------------------------------------ People who touched revisions under test: Andreas Herrmann <herrmann.der.user@googlemail.com> Ian Campbell <ian.campbell@citrix.com> Ian Jackson <ian.jackson@eu.citrix.com> Jan Beulich <jbeulich@suse.com> Lasse Collin <lasse.collin@tukaani.org> Olaf Hering <olaf@aepfle.de> Thomas Renninger <trenn@suse.de> ------------------------------------------------------------ jobs: build-amd64 pass build-i386 pass build-amd64-oldkern pass build-i386-oldkern pass build-amd64-pvops pass build-i386-pvops pass test-amd64-amd64-xl pass test-amd64-i386-xl pass test-i386-i386-xl pass test-amd64-i386-rhel6hvm-amd fail test-amd64-i386-xl-credit2 pass test-amd64-amd64-xl-pcipt-intel fail test-amd64-i386-rhel6hvm-intel fail test-amd64-i386-xl-multivcpu fail test-amd64-amd64-pair pass test-amd64-i386-pair pass test-i386-i386-pair fail test-amd64-amd64-pv fail test-amd64-i386-pv pass test-i386-i386-pv fail test-amd64-amd64-xl-sedf pass test-amd64-i386-win-vcpus1 fail test-amd64-i386-xl-win-vcpus1 fail test-amd64-amd64-win fail test-amd64-i386-win fail test-i386-i386-win fail test-amd64-amd64-xl-win fail test-i386-i386-xl-win fail ------------------------------------------------------------ sg-report-flight on woking.cam.xci-test.com logs: /home/xc_osstest/logs images: /home/xc_osstest/images Logs, config files, etc. are available at http://www.chiark.greenend.org.uk/~xensrcts/logs Test harness code can be found at http://xenbits.xensource.com/gitweb?p=osstest.git;a=summary Not pushing. ------------------------------------------------------------ changeset: 23872:cc339ab1d917 tag: tip user: Ian Campbell <ian.campbell@citrix.com> date: Thu Sep 22 18:37:06 2011 +0100 tools: fix install of lomount $(BIN) went away in 23124:e3d4c34b14a3. Also there are no *.so, *.a or *.rpm built in here Signed-off-by: Ian Campbell <ian.campbell@citrix.com> changeset: 23871:503ee256fecf user: Jan Beulich <jbeulich@suse.com> date: Thu Sep 22 18:35:30 2011 +0100 x86: ucode-amd: Don't warn when no ucode is available for a CPU revision This patch originally comes from the Linus mainline kernel (2.6.33), find below the patch details: From: Andreas Herrmann <herrmann.der.user@googlemail.com> There is no point in warning when there is no ucode available for a specific CPU revision. Currently the container-file, which provides the AMD ucode patches for OS load, contains only a few ucode patches. It's already clearly indicated by the printed patch_level whenever new ucode was available and an update happened. So the warning message is of no help but rather annoying on systems with many CPUs. Signed-off-by: Thomas Renninger <trenn@suse.de> Signed-off-by: Jan Beulich <jbeulich@suse.com> changeset: 23870:5c97b02f48fc user: Jan Beulich <jbeulich@suse.com> date: Thu Sep 22 18:34:27 2011 +0100 XZ: Fix incorrect XZ_BUF_ERROR From: Lasse Collin <lasse.collin@tukaani.org> xz_dec_run() could incorrectly return XZ_BUF_ERROR if all of the following was true: - The caller knows how many bytes of output to expect and only provides that much output space. - When the last output bytes are decoded, the caller-provided input buffer ends right before the LZMA2 end of payload marker. So LZMA2 won't provide more output anymore, but it won't know it yet and thus won't return XZ_STREAM_END yet. - A BCJ filter is in use and it hasn't left any unfiltered bytes in the temp buffer. This can happen with any BCJ filter, but in practice it's more likely with filters other than the x86 BCJ. This fixes <https://bugzilla.redhat.com/show_bug.cgi?id=3D735408> where Squashfs thinks that a valid file system is corrupt. This also fixes a similar bug in single-call mode where the uncompressed size of a block using BCJ + LZMA2 was 0 bytes and caller provided no output space. Many empty .xz files don't contain any blocks and thus don't trigger this bug. This also tweaks a closely related detail: xz_dec_bcj_run() could call xz_dec_lzma2_run() to decode into temp buffer when it was known to be useless. This was harmless although it wasted a minuscule number of CPU cycles. Signed-off-by: Lasse Collin <lasse.collin@tukaani.org> Signed-off-by: Jan Beulich <jbeulich@suse.com> changeset: 23869:db1ea4b127cd user: Jan Beulich <jbeulich@suse.com> date: Thu Sep 22 18:33:48 2011 +0100 XZ decompressor: Fix decoding of empty LZMA2 streams From: Lasse Collin <lasse.collin@tukaani.org> The old code considered valid empty LZMA2 streams to be corrupt. Note that a typical empty .xz file has no LZMA2 data at all, and thus most .xz files having no uncompressed data are handled correctly even without this fix. Signed-off-by: Lasse Collin <lasse.collin@tukaani.org> Signed-off-by: Jan Beulich <jbeulich@suse.com> changeset: 23868:28147fd781af user: Jan Beulich <jbeulich@suse.com> date: Thu Sep 22 18:32:34 2011 +0100 VT-d: fix off-by-one error in RMRR validation (base_addr,end_addr) is an inclusive range, and hence there shouldn't be a subtraction of 1 in the second invocation of page_is_ram_type(). For RMRRs covering a single page that actually resulted in the immediately preceding page to get checked (which could have resulted in a false warning). Signed-off-by: Jan Beulich <jbeulich@suse.com> changeset: 23867:571b6e90dfb4 user: Jan Beulich <jbeulich@suse.com> date: Thu Sep 22 18:31:44 2011 +0100 VT-d: eliminate a mis-use of pcidevs_lock dma_pte_clear_one() shouldn't acquire this global lock for the purpose of processing a per-domain list. Furthermore the function a few lines earlier has a comment stating that acquiring pcidevs_lock isn't necessary here (whether that's really correct is another question). Use the domain's mappin_lock instead to protect the mapped_rmrrs list. Fold domain_rmrr_mapped() into its sole caller so that the otherwise implicit dependency on pcidevs_lock there becomes more obvious (see the comment there). Signed-off-by: Jan Beulich <jbeulich@suse.com> changeset: 23866:47ec1d405af9 user: Jan Beulich <jbeulich@suse.com> date: Thu Sep 22 18:31:02 2011 +0100 x86: IO-APIC code has no dependency on PCI The IRQ handling code requires pcidevs_lock to be held only for MSI interrupts. As the handling of which was now fully moved into msi.c (i.e. while applying fine without, the patch needs to be applied after the one titled "x86: split MSI IRQ chip"), io_apic.c now also doesn't need to include PCI headers anymore. Signed-off-by: Jan Beulich <jbeulich@suse.com> changeset: 23865:d6e01c7853cf user: Jan Beulich <jbeulich@suse.com> date: Thu Sep 22 18:29:19 2011 +0100 PCI multi-seg: config space accessor adjustments Signed-off-by: Jan Beulich <jbeulich@suse.com> changeset: 23864:314b147d524d user: Jan Beulich <jbeulich@suse.com> date: Thu Sep 22 18:28:38 2011 +0100 PCI multi-seg: Pass-through adjustments Signed-off-by: Jan Beulich <jbeulich@suse.com> changeset: 23863:9e0259239822 user: Jan Beulich <jbeulich@suse.com> date: Thu Sep 22 18:28:03 2011 +0100 PCI multi-seg: AMD-IOMMU specific adjustments There are two places here where it is entirely unclear to me where the necessary PCI segment number should be taken from (as IVMD descriptors don't have such, only IVHD ones do). AMD confirmed that for the time being it is acceptable to imply that only segment 0 exists. Signed-off-by: Jan Beulich <jbeulich@suse.com> changeset: 23862:85418e168527 user: Jan Beulich <jbeulich@suse.com> date: Thu Sep 22 18:27:26 2011 +0100 PCI multi-seg: VT-d specific adjustments Signed-off-by: Jan Beulich <jbeulich@suse.com> changeset: 23861:ec7c81fbe0de user: Jan Beulich <jbeulich@suse.com> date: Thu Sep 22 18:26:54 2011 +0100 PCI multi-seg: adjust domctl interface Again, a couple of directly related functions at once get adjusted to account for the segment number. Signed-off-by: Jan Beulich <jbeulich@suse.com> changeset: 23860:a422e2a4451e user: Jan Beulich <jbeulich@suse.com> date: Sun Sep 18 00:26:52 2011 +0100 x86: split MSI IRQ chip With the .end() accessor having become optional and noting that several of the accessors' behavior really depends on the result of msi_maskable_irq(), the splits the MSI IRQ chip type into two - one for the maskable ones, and the other for the (MSI only) non-maskable ones. At once the implementation of those methods gets moved from io_apic.c to msi.c. Signed-off-by: Jan Beulich <jbeulich@suse.com> ======================================== commit cd776ee9408ff127f934a707c1a339ee600bc127 Author: Ian Jackson <ian.jackson@eu.citrix.com> Date: Tue Jun 28 13:50:53 2011 +0100 qemu-char.c: fix incorrect CONFIG_STUBDOM handling qemu-char.c:1123:7: warning: "CONFIG_STUBDOM" is not defined [-Wundef] Signed-off-by: Olaf Hering <olaf@aepfle.de> Acked-by: Ian Jackson <ian.jackson@eu.citrix.com> _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel From xen-devel-bounces@lists.xensource.com Thu Sep 22 14:54:39 2011 Return-path: <xen-devel-bounces@lists.xensource.com> Envelope-to: www-data@lists.xensource.com Delivery-date: Thu, 22 Sep 2011 14:54:39 -0700 Received: from localhost ([127.0.0.1] helo=lists.colo.xensource.com) by lists.xensource.com with esmtp (Exim 4.43) id 1R6rE6-0001ZU-WA; Thu, 22 Sep 2011 14:54:39 -0700 Received: from mail27.messagelabs.com ([193.109.254.147]) by lists.xensource.com with esmtp (Exim 4.43) id 1R6rDd-0001NZ-Fh for xen-devel@lists.xensource.com; Thu, 22 Sep 2011 14:54:09 -0700 X-Env-Sender: javier.manzano@edu.uah.es X-Msg-Ref: server-14.tower-27.messagelabs.com!1316728430!37263633!1 X-Originating-IP: [216.139.236.26] X-StarScan-Version: 6.4.1; banners=-,-,- X-VirusChecked: Checked Received: (qmail 1850 invoked from network); 22 Sep 2011 21:53:51 -0000 Received: from sam.nabble.com (HELO sam.nabble.com) (216.139.236.26) by server-14.tower-27.messagelabs.com with AES256-SHA encrypted SMTP; 22 Sep 2011 21:53:51 -0000 Received: from [192.168.236.26] (helo=sam.nabble.com) by sam.nabble.com with esmtp (Exim 4.72) (envelope-from <javier.manzano@edu.uah.es>) id 1R6rDY-0000qc-Qi for xen-devel@lists.xensource.com; Thu, 22 Sep 2011 14:54:04 -0700 Date: Thu, 22 Sep 2011 14:54:04 -0700 (PDT) From: JavMV <javier.manzano@edu.uah.es> To: xen-devel@lists.xensource.com Message-ID: <1316728444821-4831624.post@n5.nabble.com> In-Reply-To: <20110922182705.GE12984@reaktio.net> References: <1316612652132-4826391.post@n5.nabble.com> <1316613404292-4826432.post@n5.nabble.com> <1316614084705-4826479.post@n5.nabble.com> <1316615526442-4826582.post@n5.nabble.com> <1316616001843-4826614.post@n5.nabble.com> <1316616472579-4826635.post@n5.nabble.com> <1316616757871-4826655.post@n5.nabble.com> <1316618006.67296.YahooMailNeo@web29818.mail.ird.yahoo.com> <1316693722029-4829929.post@n5.nabble.com> <20110922182705.GE12984@reaktio.net> Subject: Re: Re : Re : Re : Re : [Xen-devel] Re: Patches for VGA-Passthrough XEN 4.2 unstable MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-BeenThere: xen-devel@lists.xensource.com X-Mailman-Version: 2.1.5 Precedence: list List-Id: Xen developer discussion <xen-devel.lists.xensource.com> List-Unsubscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe> List-Post: <mailto:xen-devel@lists.xensource.com> List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help> List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=subscribe> Sender: xen-devel-bounces@lists.xensource.com Errors-To: xen-devel-bounces@lists.xensource.com I will try to upgrade the BIOS tomorrow, now I haven't got access to the computer. Thanks passi, you are everywhere! XD ----- JavMV -- View this message in context: http://xen.1045712.n5.nabble.com/Patches-for-VGA-Passthrough-XEN-4-2-unstable-tp4406265p4831624.html Sent from the Xen - Dev mailing list archive at Nabble.com. _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel From xen-devel-bounces@lists.xensource.com Thu Sep 22 15:16:15 2011 Return-path: <xen-devel-bounces@lists.xensource.com> Envelope-to: www-data@lists.xensource.com Delivery-date: Thu, 22 Sep 2011 15:16:15 -0700 Received: from localhost ([127.0.0.1] helo=lists.colo.xensource.com) by lists.xensource.com with esmtp (Exim 4.43) id 1R6rYz-0002GS-VB; Thu, 22 Sep 2011 15:16:14 -0700 Received: from mail182.messagelabs.com ([85.158.139.83]) by lists.xensource.com with smtp (Exim 4.43) id 1R6rXR-00022e-Tc for xen-devel@lists.xensource.com; Thu, 22 Sep 2011 15:14:53 -0700 X-Env-Sender: dgdegra@tycho.nsa.gov X-Msg-Ref: server-12.tower-182.messagelabs.com!1316729674!19237457!1 X-Originating-IP: [63.239.65.40] X-StarScan-Version: 6.4.1; banners=-,-,- X-VirusChecked: Checked Received: (qmail 6227 invoked from network); 22 Sep 2011 22:14:34 -0000 Received: from msux-gh1-uea02.nsa.gov (HELO msux-gh1-uea02.nsa.gov) (63.239.65.40) by server-12.tower-182.messagelabs.com with SMTP; 22 Sep 2011 22:14:34 -0000 Received: from tarius.tycho.ncsc.mil (localhost [127.0.0.1]) by msux-gh1-uea02.nsa.gov (8.12.10/8.12.10) with ESMTP id p8MMEV1f029467; Thu, 22 Sep 2011 22:14:31 GMT Received: from moss-nexus.epoch.ncsc.mil (moss-nexus [144.51.25.48]) by tarius.tycho.ncsc.mil (8.13.1/8.13.1) with ESMTP id p8MMEVaq005750; Thu, 22 Sep 2011 18:14:31 -0400 From: Daniel De Graaf <dgdegra@tycho.nsa.gov> To: xen-devel@lists.xensource.com Date: Thu, 22 Sep 2011 18:14:22 -0400 Message-Id: <1316729665-15004-1-git-send-email-dgdegra@tycho.nsa.gov> X-Mailer: git-send-email 1.7.6.2 In-Reply-To: <1313764724-12683-1-git-send-email-dgdegra@tycho.nsa.gov> References: <1313764724-12683-1-git-send-email-dgdegra@tycho.nsa.gov> Cc: Ian.Campbell@eu.citrix.com, Stefano.Stabellini@eu.citrix.com, Ian.Jackson@eu.citrix.com, konrad.wilk@oracle.com Subject: [Xen-devel] [PATCH v6 0/3] libxenvchan: interdomain communications library X-BeenThere: xen-devel@lists.xensource.com X-Mailman-Version: 2.1.5 Precedence: list List-Id: Xen developer discussion <xen-devel.lists.xensource.com> List-Unsubscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe> List-Post: <mailto:xen-devel@lists.xensource.com> List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help> List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=subscribe> Sender: xen-devel-bounces@lists.xensource.com Errors-To: xen-devel-bounces@lists.xensource.com Changes since v5: - Unify gntdev osdep interface - Eliminate notify_result and revert mapping if notify ioctl fails - Rename functions and structures to libxenvchan - Use application-specified xenstore path for ring/event data - Enforce maximum ring size of 2^20 bytes on client - Change to LGPL 2.1 [PATCH 1/3] libxc: add xc_gnttab_map_grant_ref_notify [PATCH 2/3] libxc: add xc_gntshr_* functions [PATCH 3/3] libvchan: interdomain communications library _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel From xen-devel-bounces@lists.xensource.com Thu Sep 22 15:17:27 2011 Return-path: <xen-devel-bounces@lists.xensource.com> Envelope-to: www-data@lists.xensource.com Delivery-date: Thu, 22 Sep 2011 15:17:27 -0700 Received: from localhost ([127.0.0.1] helo=lists.colo.xensource.com) by lists.xensource.com with esmtp (Exim 4.43) id 1R6raB-0002dQ-12; Thu, 22 Sep 2011 15:17:27 -0700 Received: from mail27.messagelabs.com ([193.109.254.147]) by lists.xensource.com with smtp (Exim 4.43) id 1R6rXR-00022c-S1 for xen-devel@lists.xensource.com; Thu, 22 Sep 2011 15:14:54 -0700 X-Env-Sender: dgdegra@tycho.nsa.gov X-Msg-Ref: server-7.tower-27.messagelabs.com!1316729650!49782210!1 X-Originating-IP: [63.239.65.39] X-StarScan-Version: 6.4.1; banners=-,-,- X-VirusChecked: Checked Received: (qmail 31951 invoked from network); 22 Sep 2011 22:14:11 -0000 Received: from msux-gh1-uea01.nsa.gov (HELO msux-gh1-uea01.nsa.gov) (63.239.65.39) by server-7.tower-27.messagelabs.com with SMTP; 22 Sep 2011 22:14:11 -0000 Received: from tarius.tycho.ncsc.mil (localhost [127.0.0.1]) by msux-gh1-uea01.nsa.gov (8.12.10/8.12.10) with ESMTP id p8MMEV1V010121; Thu, 22 Sep 2011 22:14:31 GMT Received: from moss-nexus.epoch.ncsc.mil (moss-nexus [144.51.25.48]) by tarius.tycho.ncsc.mil (8.13.1/8.13.1) with ESMTP id p8MMEVas005750; Thu, 22 Sep 2011 18:14:31 -0400 From: Daniel De Graaf <dgdegra@tycho.nsa.gov> To: xen-devel@lists.xensource.com Date: Thu, 22 Sep 2011 18:14:24 -0400 Message-Id: <1316729665-15004-3-git-send-email-dgdegra@tycho.nsa.gov> X-Mailer: git-send-email 1.7.6.2 In-Reply-To: <1316729665-15004-1-git-send-email-dgdegra@tycho.nsa.gov> References: <1313764724-12683-1-git-send-email-dgdegra@tycho.nsa.gov> <1316729665-15004-1-git-send-email-dgdegra@tycho.nsa.gov> Cc: Ian.Campbell@eu.citrix.com, Daniel De Graaf <dgdegra@tycho.nsa.gov>, Stefano.Stabellini@eu.citrix.com, Ian.Jackson@eu.citrix.com, konrad.wilk@oracle.com Subject: [Xen-devel] [PATCH 2/3] libxc: add xc_gntshr_* functions X-BeenThere: xen-devel@lists.xensource.com X-Mailman-Version: 2.1.5 Precedence: list List-Id: Xen developer discussion <xen-devel.lists.xensource.com> List-Unsubscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe> List-Post: <mailto:xen-devel@lists.xensource.com> List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help> List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=subscribe> Sender: xen-devel-bounces@lists.xensource.com Errors-To: xen-devel-bounces@lists.xensource.com These functions and the xc_gntshr device (/dev/xen/gntalloc on linux) allow applications to create pages shared with other domains. Signed-off-by: Daniel De Graaf <dgdegra@tycho.nsa.gov> --- tools/include/xen-sys/Linux/gntalloc.h | 82 +++++++++++++++++++++++++ tools/libxc/xc_gnttab.c | 27 ++++++++ tools/libxc/xc_linux_osdep.c | 102 ++++++++++++++++++++++++++++++++ tools/libxc/xc_private.c | 13 ++++ tools/libxc/xenctrl.h | 48 +++++++++++++++ tools/libxc/xenctrlosdep.h | 10 +++ 6 files changed, 282 insertions(+), 0 deletions(-) create mode 100644 tools/include/xen-sys/Linux/gntalloc.h diff --git a/tools/include/xen-sys/Linux/gntalloc.h b/tools/include/xen-sys/Linux/gntalloc.h new file mode 100644 index 0000000..76bd580 --- /dev/null +++ b/tools/include/xen-sys/Linux/gntalloc.h @@ -0,0 +1,82 @@ +/****************************************************************************** + * gntalloc.h + * + * Interface to /dev/xen/gntalloc. + * + * Author: Daniel De Graaf <dgdegra@tycho.nsa.gov> + * + * This file is in the public domain. + */ + +#ifndef __LINUX_PUBLIC_GNTALLOC_H__ +#define __LINUX_PUBLIC_GNTALLOC_H__ + +/* + * Allocates a new page and creates a new grant reference. + */ +#define IOCTL_GNTALLOC_ALLOC_GREF \ +_IOC(_IOC_NONE, 'G', 5, sizeof(struct ioctl_gntalloc_alloc_gref)) +struct ioctl_gntalloc_alloc_gref { + /* IN parameters */ + /* The ID of the domain to be given access to the grants. */ + uint16_t domid; + /* Flags for this mapping */ + uint16_t flags; + /* Number of pages to map */ + uint32_t count; + /* OUT parameters */ + /* The offset to be used on a subsequent call to mmap(). */ + uint64_t index; + /* The grant references of the newly created grant, one per page */ + /* Variable size, depending on count */ + uint32_t gref_ids[1]; +}; + +#define GNTALLOC_FLAG_WRITABLE 1 + +/* + * Deallocates the grant reference, allowing the associated page to be freed if + * no other domains are using it. + */ +#define IOCTL_GNTALLOC_DEALLOC_GREF \ +_IOC(_IOC_NONE, 'G', 6, sizeof(struct ioctl_gntalloc_dealloc_gref)) +struct ioctl_gntalloc_dealloc_gref { + /* IN parameters */ + /* The offset returned in the map operation */ + uint64_t index; + /* Number of references to unmap */ + uint32_t count; +}; + +/* + * Sets up an unmap notification within the page, so that the other side can do + * cleanup if this side crashes. Required to implement cross-domain robust + * mutexes or close notification on communication channels. + * + * Each mapped page only supports one notification; multiple calls referring to + * the same page overwrite the previous notification. You must clear the + * notification prior to the IOCTL_GNTALLOC_DEALLOC_GREF if you do not want it + * to occur. + */ +#define IOCTL_GNTALLOC_SET_UNMAP_NOTIFY \ +_IOC(_IOC_NONE, 'G', 7, sizeof(struct ioctl_gntalloc_unmap_notify)) +struct ioctl_gntalloc_unmap_notify { + /* IN parameters */ + /* Offset in the file descriptor for a byte within the page (same as + * used in mmap). If using UNMAP_NOTIFY_CLEAR_BYTE, this is the byte to + * be cleared. Otherwise, it can be any byte in the page whose + * notification we are adjusting. + */ + uint64_t index; + /* Action(s) to take on unmap */ + uint32_t action; + /* Event channel to notify */ + uint32_t event_channel_port; +}; + +/* Clear (set to zero) the byte specified by index */ +#define UNMAP_NOTIFY_CLEAR_BYTE 0x1 +/* Send an interrupt on the indicated event channel */ +#define UNMAP_NOTIFY_SEND_EVENT 0x2 + +#endif /* __LINUX_PUBLIC_GNTALLOC_H__ */ diff --git a/tools/libxc/xc_gnttab.c b/tools/libxc/xc_gnttab.c index 033cc5c..cb5995f 100644 --- a/tools/libxc/xc_gnttab.c +++ b/tools/libxc/xc_gnttab.c @@ -203,6 +203,33 @@ int xc_gnttab_set_max_grants(xc_gnttab *xcg, uint32_t count) return xcg->ops->u.gnttab.set_max_grants(xcg, xcg->ops_handle, count); } +void *xc_gntshr_share_pages(xc_gntshr *xcg, uint32_t domid, + int count, uint32_t *refs, int writable) +{ + return xcg->ops->u.gntshr.share_pages(xcg, xcg->ops_handle, domid, + count, refs, writable, -1, -1); +} + +void *xc_gntshr_share_page_notify(xc_gntshr *xcg, uint32_t domid, + uint32_t *ref, int writable, + uint32_t notify_offset, + evtchn_port_t notify_port) +{ + return xcg->ops->u.gntshr.share_pages(xcg, xcg->ops_handle, + domid, 1, ref, writable, notify_offset, notify_port); +} + +/* + * Unmaps the @count pages starting at @start_address, which were mapped by a + * call to xc_gntshr_share_*. Never logs. + */ +int xc_gntshr_munmap(xc_gntshr *xcg, void *start_address, uint32_t count) +{ + return xcg->ops->u.gntshr.munmap(xcg, xcg->ops_handle, + start_address, count); +} + + /* * Local variables: * mode: C diff --git a/tools/libxc/xc_linux_osdep.c b/tools/libxc/xc_linux_osdep.c index f760421..04059b8 100644 --- a/tools/libxc/xc_linux_osdep.c +++ b/tools/libxc/xc_linux_osdep.c @@ -34,6 +34,7 @@ #include <xen/memory.h> #include <xen/sys/evtchn.h> #include <xen/sys/gntdev.h> +#include <xen/sys/gntalloc.h> #include "xenctrl.h" #include "xenctrlosdep.h" @@ -656,6 +657,105 @@ static struct xc_osdep_ops linux_gnttab_ops = { }, }; +static xc_osdep_handle linux_gntshr_open(xc_gntshr *xcg) +{ + int fd = open(DEVXEN "gntalloc", O_RDWR); + + if ( fd == -1 ) + return XC_OSDEP_OPEN_ERROR; + + return (xc_osdep_handle)fd; +} + +static int linux_gntshr_close(xc_gntshr *xcg, xc_osdep_handle h) +{ + int fd = (int)h; + return close(fd); +} + +static void *linux_gntshr_share_pages(xc_gntshr *xch, xc_osdep_handle h, + uint32_t domid, int count, + uint32_t *refs, int writable, + uint32_t notify_offset, + evtchn_port_t notify_port) +{ + struct ioctl_gntalloc_alloc_gref *gref_info = NULL; + struct ioctl_gntalloc_unmap_notify notify; + struct ioctl_gntalloc_dealloc_gref gref_drop; + int fd = (int)h; + int err; + void *area = NULL; + gref_info = malloc(sizeof(*gref_info) + count * sizeof(uint32_t)); + if (!gref_info) + return NULL; + gref_info->domid = domid; + gref_info->flags = writable ? GNTALLOC_FLAG_WRITABLE : 0; + gref_info->count = count; + + err = ioctl(fd, IOCTL_GNTALLOC_ALLOC_GREF, gref_info); + if (err) { + PERROR("linux_gntshr_share_pages: ioctl failed"); + goto out; + } + + area = mmap(NULL, count * XC_PAGE_SIZE, PROT_READ | PROT_WRITE, + MAP_SHARED, fd, gref_info->index); + + if (area == MAP_FAILED) { + area = NULL; + PERROR("linux_gntshr_share_pages: mmap failed"); + goto out_remove_fdmap; + } + + notify.index = gref_info->index; + notify.action = 0; + if (notify_offset >= 0) { + notify.index += notify_offset; + notify.action |= UNMAP_NOTIFY_CLEAR_BYTE; + } + if (notify_port >= 0) { + notify.event_channel_port = notify_port; + notify.action |= UNMAP_NOTIFY_SEND_EVENT; + } + if (notify.action) + err = ioctl(fd, IOCTL_GNTALLOC_SET_UNMAP_NOTIFY, ¬ify); + if (err) { + PERROR("linux_gntshr_share_page_notify: ioctl SET_UNMAP_NOTIFY failed"); + munmap(area, count * XC_PAGE_SIZE); + area = NULL; + } + + memcpy(refs, gref_info->gref_ids, count * sizeof(uint32_t)); + + out_remove_fdmap: + /* Removing the mapping from the file descriptor does not cause the pages to + * be deallocated until the mapping is removed. + */ + gref_drop.index = gref_info->index; + gref_drop.count = count; + ioctl(fd, IOCTL_GNTALLOC_DEALLOC_GREF, &gref_drop); + out: + free(gref_info); + return area; +} + +static int linux_gntshr_munmap(xc_gntshr *xcg, xc_osdep_handle h, + void *start_address, uint32_t count) +{ + return munmap(start_address, count); +} + +static struct xc_osdep_ops linux_gntshr_ops = { + .open = &linux_gntshr_open, + .close = &linux_gntshr_close, + + .u.gntshr = { + .share_pages = &linux_gntshr_share_pages, + .munmap = &linux_gntshr_munmap, + }, +}; + + static struct xc_osdep_ops *linux_osdep_init(xc_interface *xch, enum xc_osdep_type type) { switch ( type ) @@ -666,6 +766,8 @@ static struct xc_osdep_ops *linux_osdep_init(xc_interface *xch, enum xc_osdep_ty return &linux_evtchn_ops; case XC_OSDEP_GNTTAB: return &linux_gnttab_ops; + case XC_OSDEP_GNTSHR: + return &linux_gntshr_ops; default: return NULL; } diff --git a/tools/libxc/xc_private.c b/tools/libxc/xc_private.c index 09c8f23..09a91e7 100644 --- a/tools/libxc/xc_private.c +++ b/tools/libxc/xc_private.c @@ -258,6 +258,19 @@ int xc_gnttab_close(xc_gnttab *xcg) return xc_interface_close_common(xcg); } +xc_gntshr *xc_gntshr_open(xentoollog_logger *logger, + unsigned open_flags) +{ + return xc_interface_open_common(logger, NULL, open_flags, + XC_OSDEP_GNTSHR); +} + +int xc_gntshr_close(xc_gntshr *xcg) +{ + return xc_interface_close_common(xcg); +} + + static pthread_key_t errbuf_pkey; static pthread_once_t errbuf_pkey_once = PTHREAD_ONCE_INIT; diff --git a/tools/libxc/xenctrl.h b/tools/libxc/xenctrl.h index 6f3165d..72a7f2d 100644 --- a/tools/libxc/xenctrl.h +++ b/tools/libxc/xenctrl.h @@ -115,6 +115,7 @@ typedef struct xc_interface_core xc_interface; typedef struct xc_interface_core xc_evtchn; typedef struct xc_interface_core xc_gnttab; +typedef struct xc_interface_core xc_gntshr; typedef enum xc_error_code xc_error_code; @@ -1402,6 +1403,53 @@ grant_entry_v1_t *xc_gnttab_map_table_v1(xc_interface *xch, int domid, int *gnt_ grant_entry_v2_t *xc_gnttab_map_table_v2(xc_interface *xch, int domid, int *gnt_num); /* Sometimes these don't set errno [fixme], and sometimes they don't log. */ +/* + * Return an fd onto the grant sharing driver. Logs errors. + */ +xc_gntshr *xc_gntshr_open(xentoollog_logger *logger, + unsigned open_flags); + +/* + * Close a handle previously allocated with xc_gntshr_open(). + * Never logs errors. + */ +int xc_gntshr_close(xc_gntshr *xcg); + +/* + * Creates and shares pages with another domain. + * + * @parm xcg a handle to an open grant sharing instance + * @parm domid the domain to share memory with + * @parm count the number of pages to share + * @parm refs the grant references of the pages (output) + * @parm writable true if the other domain can write to the pages + * @return local mapping of the pages + */ +void *xc_gntshr_share_pages(xc_gntshr *xcg, uint32_t domid, + int count, uint32_t *refs, int writable); + +/* + * Creates and shares a page with another domain, with unmap notification. + * + * @parm xcg a handle to an open grant sharing instance + * @parm domid the domain to share memory with + * @parm refs the grant reference of the pages (output) + * @parm writable true if the other domain can write to the page + * @parm notify_offset The byte offset in the page to use for unmap + * notification; -1 for none. + * @parm notify_port The event channel port to use for unmap notify, or -1 + * @return local mapping of the page + */ +void *xc_gntshr_share_page_notify(xc_gntshr *xcg, uint32_t domid, + uint32_t *ref, int writable, + uint32_t notify_offset, + evtchn_port_t notify_port); +/* + * Unmaps the @count pages starting at @start_address, which were mapped by a + * call to xc_gntshr_share_*. Never logs. + */ +int xc_gntshr_munmap(xc_gntshr *xcg, void *start_address, uint32_t count); + int xc_physdev_map_pirq(xc_interface *xch, int domid, int index, diff --git a/tools/libxc/xenctrlosdep.h b/tools/libxc/xenctrlosdep.h index 1c6317e..a36c4aa 100644 --- a/tools/libxc/xenctrlosdep.h +++ b/tools/libxc/xenctrlosdep.h @@ -54,6 +54,7 @@ enum xc_osdep_type { XC_OSDEP_PRIVCMD, XC_OSDEP_EVTCHN, XC_OSDEP_GNTTAB, + XC_OSDEP_GNTSHR, }; /* Opaque handle internal to the backend */ @@ -116,6 +117,15 @@ struct xc_osdep_ops uint32_t count); int (*set_max_grants)(xc_gnttab *xcg, xc_osdep_handle h, uint32_t count); } gnttab; + struct { + void *(*share_pages)(xc_gntshr *xcg, xc_osdep_handle h, + uint32_t domid, int count, + uint32_t *refs, int writable, + uint32_t notify_offset, + evtchn_port_t notify_port); + int (*munmap)(xc_gntshr *xcg, xc_osdep_handle h, + void *start_address, uint32_t count); + } gntshr; } u; }; typedef struct xc_osdep_ops xc_osdep_ops; -- 1.7.6.2 _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel From xen-devel-bounces@lists.xensource.com Thu Sep 22 15:18:25 2011 Return-path: <xen-devel-bounces@lists.xensource.com> Envelope-to: www-data@lists.xensource.com Delivery-date: Thu, 22 Sep 2011 15:18:25 -0700 Received: from localhost ([127.0.0.1] helo=lists.colo.xensource.com) by lists.xensource.com with esmtp (Exim 4.43) id 1R6rb7-000309-7z; Thu, 22 Sep 2011 15:18:25 -0700 Received: from mail174.messagelabs.com ([85.158.138.51]) by lists.xensource.com with smtp (Exim 4.43) id 1R6rXS-00022g-13 for xen-devel@lists.xensource.com; Thu, 22 Sep 2011 15:14:54 -0700 X-Env-Sender: dgdegra@tycho.nsa.gov X-Msg-Ref: server-9.tower-174.messagelabs.com!1316729674!26393239!1 X-Originating-IP: [63.239.65.39] X-StarScan-Version: 6.4.1; banners=-,-,- X-VirusChecked: Checked Received: (qmail 6665 invoked from network); 22 Sep 2011 22:14:34 -0000 Received: from msux-gh1-uea01.nsa.gov (HELO msux-gh1-uea01.nsa.gov) (63.239.65.39) by server-9.tower-174.messagelabs.com with SMTP; 22 Sep 2011 22:14:34 -0000 Received: from tarius.tycho.ncsc.mil (localhost [127.0.0.1]) by msux-gh1-uea01.nsa.gov (8.12.10/8.12.10) with ESMTP id p8MMEV1V010122; Thu, 22 Sep 2011 22:14:31 GMT Received: from moss-nexus.epoch.ncsc.mil (moss-nexus [144.51.25.48]) by tarius.tycho.ncsc.mil (8.13.1/8.13.1) with ESMTP id p8MMEVat005750; Thu, 22 Sep 2011 18:14:31 -0400 From: Daniel De Graaf <dgdegra@tycho.nsa.gov> To: xen-devel@lists.xensource.com Date: Thu, 22 Sep 2011 18:14:25 -0400 Message-Id: <1316729665-15004-4-git-send-email-dgdegra@tycho.nsa.gov> X-Mailer: git-send-email 1.7.6.2 In-Reply-To: <1316729665-15004-1-git-send-email-dgdegra@tycho.nsa.gov> References: <1313764724-12683-1-git-send-email-dgdegra@tycho.nsa.gov> <1316729665-15004-1-git-send-email-dgdegra@tycho.nsa.gov> Cc: Ian.Campbell@eu.citrix.com, Daniel De Graaf <dgdegra@tycho.nsa.gov>, Stefano.Stabellini@eu.citrix.com, Ian.Jackson@eu.citrix.com, konrad.wilk@oracle.com Subject: [Xen-devel] [PATCH 3/3] libvchan: interdomain communications library X-BeenThere: xen-devel@lists.xensource.com X-Mailman-Version: 2.1.5 Precedence: list List-Id: Xen developer discussion <xen-devel.lists.xensource.com> List-Unsubscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe> List-Post: <mailto:xen-devel@lists.xensource.com> List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help> List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=subscribe> Sender: xen-devel-bounces@lists.xensource.com Errors-To: xen-devel-bounces@lists.xensource.com This library implements a bidirectional communication interface between applications in different domains, similar to unix sockets. Data can be sent using the byte-oriented libvchan_read/libvchan_write or the packet-oriented libvchan_recv/libvchan_send. Channel setup is done using a client-server model; domain IDs and a port number must be negotiated prior to initialization. The server allocates memory for the shared pages and determines the sizes of the communication rings (which may span multiple pages, although the default places rings and control within a single page). With properly sized rings, testing has shown that this interface provides speed comparable to pipes within a single Linux domain; it is significantly faster than network-based communication. Signed-off-by: Daniel De Graaf <dgdegra@tycho.nsa.gov> --- tools/Makefile | 1 + tools/Rules.mk | 5 + tools/libvchan/Makefile | 59 +++++ tools/libvchan/init.c | 409 +++++++++++++++++++++++++++++++++++ tools/libvchan/io.c | 375 ++++++++++++++++++++++++++++++++ tools/libvchan/libxenvchan.h | 169 +++++++++++++++ tools/libvchan/node-select.c | 162 ++++++++++++++ tools/libvchan/node.c | 169 +++++++++++++++ xen/include/public/io/libxenvchan.h | 97 +++++++++ 9 files changed, 1446 insertions(+), 0 deletions(-) create mode 100644 tools/libvchan/Makefile create mode 100644 tools/libvchan/init.c create mode 100644 tools/libvchan/io.c create mode 100644 tools/libvchan/libxenvchan.h create mode 100644 tools/libvchan/node-select.c create mode 100644 tools/libvchan/node.c create mode 100644 xen/include/public/io/libxenvchan.h diff --git a/tools/Makefile b/tools/Makefile index df6270c..9389e1f 100644 --- a/tools/Makefile +++ b/tools/Makefile @@ -27,6 +27,7 @@ SUBDIRS-$(CONFIG_NetBSD) += blktap2 SUBDIRS-$(CONFIG_NetBSD) += xenbackendd SUBDIRS-y += libfsimage SUBDIRS-$(LIBXENAPI_BINDINGS) += libxen +SUBDIRS-y += libvchan # do not recurse in to a dir we are about to delete ifneq "$(MAKECMDGOALS)" "distclean" diff --git a/tools/Rules.mk b/tools/Rules.mk index 0d048af..49125f5 100644 --- a/tools/Rules.mk +++ b/tools/Rules.mk @@ -14,6 +14,7 @@ XEN_XENLIGHT = $(XEN_ROOT)/tools/libxl XEN_XENSTORE = $(XEN_ROOT)/tools/xenstore XEN_LIBXENSTAT = $(XEN_ROOT)/tools/xenstat/libxenstat/src XEN_BLKTAP2 = $(XEN_ROOT)/tools/blktap2 +XEN_LIBVCHAN = $(XEN_ROOT)/tools/libvchan CFLAGS_xeninclude = -I$(XEN_INCLUDE) @@ -33,6 +34,10 @@ CFLAGS_libxenstat = -I$(XEN_LIBXENSTAT) LDLIBS_libxenstat = $(SHLIB_libxenctrl) $(SHLIB_libxenstore) -L$(XEN_LIBXENSTAT) -lxenstat SHLIB_libxenstat = -Wl,-rpath-link=$(XEN_LIBXENSTAT) +CFLAGS_libxenvchan = -I$(XEN_LIBVCHAN) +LDLIBS_libxenvchan = $(SHLIB_libxenctrl) $(SHLIB_libxenstore) -L$(XEN_LIBVCHAN) -lxenvchan +SHLIB_libxenvchan = -Wl,-rpath-link=$(XEN_LIBVCHAN) + ifeq ($(CONFIG_Linux),y) LIBXL_BLKTAP = y else diff --git a/tools/libvchan/Makefile b/tools/libvchan/Makefile new file mode 100644 index 0000000..daf3593 --- /dev/null +++ b/tools/libvchan/Makefile @@ -0,0 +1,59 @@ +# +# tools/libvchan/Makefile +# + +XEN_ROOT = $(CURDIR)/../.. +include $(XEN_ROOT)/tools/Rules.mk + +LIBVCHAN_OBJS = init.o io.o +NODE_OBJS = node.o +NODE2_OBJS = node-select.o + +LIBVCHAN_PIC_OBJS = $(patsubst %.o,%.opic,$(LIBVCHAN_OBJS)) +LIBVCHAN_LIBS = $(LDLIBS_libxenstore) $(LDLIBS_libxenctrl) +$(LIBVCHAN_OBJS) $(LIBVCHAN_PIC_OBJS): CFLAGS += $(CFLAGS_libxenstore) $(CFLAGS_libxenctrl) +$(NODE_OBJS) $(NODE2_OBJS): CFLAGS += $(CFLAGS_libxenctrl) + +MAJOR = 1.0 +MINOR = 0 + +CFLAGS += -I../include -I. + +.PHONY: all +all: libxenvchan.so vchan-node1 vchan-node2 libxenvchan.a + +libxenvchan.so: libxenvchan.so.$(MAJOR) + ln -sf $< $@ + +libxenvchan.so.$(MAJOR): libxenvchan.so.$(MAJOR).$(MINOR) + ln -sf $< $@ + +libxenvchan.so.$(MAJOR).$(MINOR): $(LIBVCHAN_PIC_OBJS) + $(CC) $(LDFLAGS) -Wl,$(SONAME_LDFLAG) -Wl,libxenvchan.so.$(MAJOR) $(SHLIB_LDFLAGS) -o $@ $^ $(LIBVCHAN_LIBS) + +libxenvchan.a: $(LIBVCHAN_OBJS) + $(AR) rcs libxenvchan.a $^ + +vchan-node1: $(NODE_OBJS) libxenvchan.so + $(CC) $(LDFLAGS) -o $@ $(NODE_OBJS) $(LDLIBS_libxenvchan) + +vchan-node2: $(NODE2_OBJS) libxenvchan.so + $(CC) $(LDFLAGS) -o $@ $(NODE2_OBJS) $(LDLIBS_libxenvchan) + +.PHONY: install +install: all + $(INSTALL_DIR) $(DESTDIR)$(LIBDIR) + $(INSTALL_DIR) $(DESTDIR)$(INCLUDEDIR) + $(INSTALL_PROG) libxenvchan.so.$(MAJOR).$(MINOR) $(DESTDIR)$(LIBDIR) + ln -sf libxenvchan.so.$(MAJOR).$(MINOR) $(DESTDIR)$(LIBDIR)/libxenvchan.so.$(MAJOR) + ln -sf libxenvchan.so.$(MAJOR) $(DESTDIR)$(LIBDIR)/libxenvchan.so + $(INSTALL_DATA) libxenvchan.h $(DESTDIR)$(INCLUDEDIR) + $(INSTALL_DATA) libxenvchan.a $(DESTDIR)$(LIBDIR) + +.PHONY: clean +clean: + $(RM) -f *.o *.so* *.a vchan-node1 vchan-node2 $(DEPS) + +distclean: clean + +-include $(DEPS) diff --git a/tools/libvchan/init.c b/tools/libvchan/init.c new file mode 100644 index 0000000..becf71d --- /dev/null +++ b/tools/libvchan/init.c @@ -0,0 +1,409 @@ +/** + * @file + * @section AUTHORS + * + * Copyright (C) 2010 Rafal Wojtczuk <rafal@invisiblethingslab.com> + * + * Authors: + * Rafal Wojtczuk <rafal@invisiblethingslab.com> + * Daniel De Graaf <dgdegra@tycho.nsa.gov> + * + * @section LICENSE + * + * This library is free software; you can redistribute it and/or + * modify it under the terms of the GNU Lesser General Public + * License as published by the Free Software Foundation; either + * version 2.1 of the License, or (at your option) any later version. + * + * This library is distributed in the hope that it will be useful, + * but WITHOUT ANY WARRANTY; without even the implied warranty of + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU + * Lesser General Public License for more details. + * + * You should have received a copy of the GNU Lesser General Public + * License along with this library; if not, write to the Free Software + * Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston, MA 02110-1301 USA + * + * @section DESCRIPTION + * + * This file contains the setup code used to establish the ring buffer. + */ + +#include <sys/types.h> +#include <sys/mman.h> +#include <sys/ioctl.h> +#include <sys/user.h> +#include <stdlib.h> +#include <stdio.h> +#include <stdint.h> +#include <string.h> +#include <unistd.h> +#include <fcntl.h> + +#include <xs.h> +#include <xen/sys/evtchn.h> +#include <xen/sys/gntalloc.h> +#include <xen/sys/gntdev.h> +#include <libxenvchan.h> + +#ifndef PAGE_SHIFT +#define PAGE_SHIFT 12 +#endif + +#ifndef PAGE_SIZE +#define PAGE_SIZE 4096 +#endif + +#define SMALL_RING_SHIFT 10 +#define LARGE_RING_SHIFT 11 + +#define MAX_SMALL_RING (1 << SMALL_RING_SHIFT) +#define SMALL_RING_OFFSET 1024 +#define MAX_LARGE_RING (1 << LARGE_RING_SHIFT) +#define LARGE_RING_OFFSET 2048 + +// if you go over this size, you'll have too many grants to fit in the shared page. +#define MAX_RING_SHIFT 20 +#define MAX_RING_SIZE (1 << MAX_RING_SHIFT) + +#ifndef offsetof +#define offsetof(TYPE, MEMBER) ((size_t) &((TYPE *)0)->MEMBER) +#endif + +#define max(a,b) ((a > b) ? a : b) + +static int init_gnt_srv(struct libxenvchan *ctrl, int domain) +{ + int pages_left = ctrl->read.order >= PAGE_SHIFT ? 1 << (ctrl->read.order - PAGE_SHIFT) : 0; + int pages_right = ctrl->write.order >= PAGE_SHIFT ? 1 << (ctrl->write.order - PAGE_SHIFT) : 0; + uint32_t ring_ref = -1; + void *ring; + + ring = xc_gntshr_share_page_notify(ctrl->gntshr, domain, + &ring_ref, 1, offsetof(struct vchan_interface, srv_live), + ctrl->event_port); + + if (!ring) + goto out; + + memset(ring, 0, PAGE_SIZE); + + ctrl->ring = ring; + ctrl->read.shr = &ctrl->ring->left; + ctrl->write.shr = &ctrl->ring->right; + ctrl->ring->left_order = ctrl->read.order; + ctrl->ring->right_order = ctrl->write.order; + ctrl->ring->cli_live = 2; + ctrl->ring->srv_live = 1; + ctrl->ring->cli_notify = VCHAN_NOTIFY_WRITE; + + switch (ctrl->read.order) { + case SMALL_RING_SHIFT: + ctrl->read.buffer = ((void*)ctrl->ring) + SMALL_RING_OFFSET; + break; + case LARGE_RING_SHIFT: + ctrl->read.buffer = ((void*)ctrl->ring) + LARGE_RING_OFFSET; + break; + default: + ctrl->read.buffer = xc_gntshr_share_pages(ctrl->gntshr, domain, + pages_left, ctrl->ring->grants, 1); + if (!ctrl->read.buffer) + goto out_ring; + } + + switch (ctrl->write.order) { + case SMALL_RING_SHIFT: + ctrl->write.buffer = ((void*)ctrl->ring) + SMALL_RING_OFFSET; + break; + case LARGE_RING_SHIFT: + ctrl->write.buffer = ((void*)ctrl->ring) + LARGE_RING_OFFSET; + break; + default: + ctrl->write.buffer = xc_gntshr_share_pages(ctrl->gntshr, domain, + pages_right, ctrl->ring->grants + pages_left, 1); + if (!ctrl->write.buffer) + goto out_unmap_left; + } + +out: + return ring_ref; +out_unmap_left: + if (pages_left) + xc_gntshr_munmap(ctrl->gntshr, ctrl->read.buffer, pages_left * PAGE_SIZE); +out_ring: + xc_gntshr_munmap(ctrl->gntshr, ring, PAGE_SIZE); + ring_ref = -1; + ctrl->ring = NULL; + ctrl->write.order = ctrl->read.order = 0; + goto out; +} + +static int init_gnt_cli(struct libxenvchan *ctrl, int domain, uint32_t ring_ref) +{ + int rv = -1; + uint32_t *grants; + + ctrl->ring = xc_gnttab_map_grant_ref_notify(ctrl->gnttab, + domain, ring_ref, PROT_READ|PROT_WRITE, + offsetof(struct vchan_interface, cli_live), ctrl->event_port); + + if (!ctrl->ring) + goto out; + + ctrl->write.order = ctrl->ring->left_order; + ctrl->read.order = ctrl->ring->right_order; + ctrl->write.shr = &ctrl->ring->left; + ctrl->read.shr = &ctrl->ring->right; + if (ctrl->write.order < SMALL_RING_SHIFT || ctrl->write.order > MAX_RING_SHIFT) + goto out_unmap_ring; + if (ctrl->read.order < SMALL_RING_SHIFT || ctrl->read.order > MAX_RING_SHIFT) + goto out_unmap_ring; + if (ctrl->read.order == ctrl->write.order && ctrl->read.order < PAGE_SHIFT) + goto out_unmap_ring; + + grants = ctrl->ring->grants; + + switch (ctrl->write.order) { + case SMALL_RING_SHIFT: + ctrl->write.buffer = ((void*)ctrl->ring) + SMALL_RING_OFFSET; + break; + case LARGE_RING_SHIFT: + ctrl->write.buffer = ((void*)ctrl->ring) + LARGE_RING_OFFSET; + break; + default: + { + int pages_left = 1 << (ctrl->write.order - PAGE_SHIFT); + ctrl->write.buffer = xc_gnttab_map_domain_grant_refs(ctrl->gnttab, + pages_left, domain, grants, PROT_READ|PROT_WRITE); + if (!ctrl->write.buffer) + goto out_unmap_ring; + grants += pages_left; + } + } + + switch (ctrl->read.order) { + case SMALL_RING_SHIFT: + ctrl->read.buffer = ((void*)ctrl->ring) + SMALL_RING_OFFSET; + break; + case LARGE_RING_SHIFT: + ctrl->read.buffer = ((void*)ctrl->ring) + LARGE_RING_OFFSET; + break; + default: + { + int pages_right = 1 << (ctrl->read.order - PAGE_SHIFT); + ctrl->read.buffer = xc_gnttab_map_domain_grant_refs(ctrl->gnttab, + pages_right, domain, grants, PROT_READ); + if (!ctrl->read.buffer) + goto out_unmap_left; + } + } + + rv = 0; + out: + return rv; + out_unmap_left: + if (ctrl->write.order >= PAGE_SHIFT) + xc_gnttab_munmap(ctrl->gnttab, ctrl->write.buffer, + 1 << ctrl->write.order); + out_unmap_ring: + xc_gnttab_munmap(ctrl->gnttab, ctrl->ring, PAGE_SIZE); + ctrl->ring = 0; + ctrl->write.order = ctrl->read.order = 0; + rv = -1; + goto out; +} + +static int init_evt_srv(struct libxenvchan *ctrl, int domain, xentoollog_logger *logger) +{ + ctrl->event = xc_evtchn_open(logger, 0); + if (!ctrl->event) + return -1; + ctrl->event_port = xc_evtchn_bind_unbound_port(ctrl->event, domain); + if (ctrl->event_port < 0) + return -1; + if (xc_evtchn_unmask(ctrl->event, ctrl->event_port)) + return -1; + return 0; +} + +static int init_xs_srv(struct libxenvchan *ctrl, int domain, const char* xs_base, int ring_ref) +{ + int ret = -1; + struct xs_handle *xs; + struct xs_permissions perms[2]; + char buf[64]; + char ref[16]; + char* domid_str = NULL; + xs = xs_domain_open(); + if (!xs) + goto fail; + domid_str = xs_read(xs, 0, "domid", NULL); + if (!domid_str) + goto fail_xs_open; + + // owner domain is us + perms[0].id = atoi(domid_str); + // permissions for domains not listed = none + perms[0].perms = XS_PERM_NONE; + // other domains + perms[1].id = domain; + perms[1].perms = XS_PERM_READ; + + snprintf(ref, sizeof ref, "%d", ring_ref); + snprintf(buf, sizeof buf, "%s/ring-ref", xs_base); + if (!xs_write(xs, 0, buf, ref, strlen(ref))) + goto fail_xs_open; + if (!xs_set_permissions(xs, 0, buf, perms, 2)) + goto fail_xs_open; + + snprintf(ref, sizeof ref, "%d", ctrl->event_port); + snprintf(buf, sizeof buf, "%s/event-channel", xs_base); + if (!xs_write(xs, 0, buf, ref, strlen(ref))) + goto fail_xs_open; + if (!xs_set_permissions(xs, 0, buf, perms, 2)) + goto fail_xs_open; + + ret = 0; + fail_xs_open: + free(domid_str); + xs_daemon_close(xs); + fail: + return ret; +} + +static int min_order(size_t siz) +{ + int rv = PAGE_SHIFT; + while (siz > (1 << rv)) + rv++; + return rv; +} + +struct libxenvchan *libxenvchan_server_init(xentoollog_logger *logger, int domain, const char* xs_path, size_t left_min, size_t right_min) +{ + struct libxenvchan *ctrl; + int ring_ref; + if (left_min > MAX_RING_SIZE || right_min > MAX_RING_SIZE) + return 0; + + ctrl = malloc(sizeof(*ctrl)); + if (!ctrl) + return 0; + + ctrl->ring = NULL; + ctrl->event = NULL; + ctrl->is_server = 1; + ctrl->server_persist = 0; + + ctrl->read.order = min_order(left_min); + ctrl->write.order = min_order(right_min); + + // if we can avoid allocating extra pages by using in-page rings, do so + if (left_min <= MAX_SMALL_RING && right_min <= MAX_LARGE_RING) { + ctrl->read.order = SMALL_RING_SHIFT; + ctrl->write.order = LARGE_RING_SHIFT; + } else if (left_min <= MAX_LARGE_RING && right_min <= MAX_SMALL_RING) { + ctrl->read.order = LARGE_RING_SHIFT; + ctrl->write.order = SMALL_RING_SHIFT; + } else if (left_min <= MAX_LARGE_RING) { + ctrl->read.order = LARGE_RING_SHIFT; + } else if (right_min <= MAX_LARGE_RING) { + ctrl->write.order = LARGE_RING_SHIFT; + } + + ctrl->gntshr = xc_gntshr_open(logger, 0); + if (!ctrl->gntshr) + goto out; + + if (init_evt_srv(ctrl, domain, logger)) + goto out; + ring_ref = init_gnt_srv(ctrl, domain); + if (ring_ref < 0) + goto out; + if (init_xs_srv(ctrl, domain, xs_path, ring_ref)) + goto out; + return ctrl; +out: + libxenvchan_close(ctrl); + return 0; +} + +static int init_evt_cli(struct libxenvchan *ctrl, int domain, xentoollog_logger *logger) +{ + ctrl->event = xc_evtchn_open(logger, 0); + if (!ctrl->event) + return -1; + ctrl->event_port = xc_evtchn_bind_interdomain(ctrl->event, + domain, ctrl->event_port); + if (ctrl->event_port < 0) + return -1; + xc_evtchn_unmask(ctrl->event, ctrl->event_port); + return 0; +} + + +struct libxenvchan *libxenvchan_client_init(xentoollog_logger *logger, int domain, const char* xs_path) +{ + struct libxenvchan *ctrl = malloc(sizeof(struct libxenvchan)); + struct xs_handle *xs = NULL; + char buf[64]; + char *ref; + int ring_ref; + unsigned int len; + + if (!ctrl) + return 0; + ctrl->ring = NULL; + ctrl->event = NULL; + ctrl->gnttab = NULL; + ctrl->write.order = ctrl->read.order = 0; + ctrl->is_server = 0; + + xs = xs_daemon_open(); + if (!xs) + xs = xs_domain_open(); + if (!xs) + goto fail; + +// find xenstore entry + snprintf(buf, sizeof buf, "%s/ring-ref", xs_path); + ref = xs_read(xs, 0, buf, &len); + if (!ref) + goto fail; + ring_ref = atoi(ref); + free(ref); + if (!ring_ref) + goto fail; + snprintf(buf, sizeof buf, "%s/event-channel", xs_path); + ref = xs_read(xs, 0, buf, &len); + if (!ref) + goto fail; + ctrl->event_port = atoi(ref); + free(ref); + if (!ctrl->event_port) + goto fail; + + ctrl->gnttab = xc_gnttab_open(logger, 0); + if (!ctrl->gnttab) + goto out; + +// set up event channel + if (init_evt_cli(ctrl, domain, logger)) + goto fail; + +// set up shared page(s) + if (init_gnt_cli(ctrl, domain, ring_ref)) + goto fail; + + ctrl->ring->cli_live = 1; + ctrl->ring->srv_notify = VCHAN_NOTIFY_WRITE; + + out: + if (xs) + xs_daemon_close(xs); + return ctrl; + fail: + libxenvchan_close(ctrl); + ctrl = NULL; + goto out; +} diff --git a/tools/libvchan/io.c b/tools/libvchan/io.c new file mode 100644 index 0000000..7023add --- /dev/null +++ b/tools/libvchan/io.c @@ -0,0 +1,375 @@ +/** + * @file + * @section AUTHORS + * + * Copyright (C) 2010 Rafal Wojtczuk <rafal@invisiblethingslab.com> + * + * Authors: + * Rafal Wojtczuk <rafal@invisiblethingslab.com> + * Daniel De Graaf <dgdegra@tycho.nsa.gov> + * + * @section LICENSE + * + * This library is free software; you can redistribute it and/or + * modify it under the terms of the GNU Lesser General Public + * License as published by the Free Software Foundation; either + * version 2.1 of the License, or (at your option) any later version. + * + * This library is distributed in the hope that it will be useful, + * but WITHOUT ANY WARRANTY; without even the implied warranty of + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU + * Lesser General Public License for more details. + * + * You should have received a copy of the GNU Lesser General Public + * License along with this library; if not, write to the Free Software + * Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston, MA 02110-1301 USA + * + * @section DESCRIPTION + * + * This file contains the communications interface built on the ring buffer. + */ + +#include <sys/types.h> +#include <sys/mman.h> +#include <sys/ioctl.h> +#include <sys/uio.h> +#include <stdlib.h> +#include <stdint.h> +#include <string.h> +#include <unistd.h> + +#include <xenctrl.h> +#include <libxenvchan.h> + +#ifndef PAGE_SHIFT +#define PAGE_SHIFT 12 +#endif + +#ifndef PAGE_SIZE +#define PAGE_SIZE 4096 +#endif + +// allow vchan data to be easily observed in strace by doing a +// writev() to FD -1 with the data being read/written. +#ifndef VCHAN_DEBUG +#define VCHAN_DEBUG 0 +#endif + +#define barrier() asm volatile("" ::: "memory") + + +static inline uint32_t rd_prod(struct libxenvchan *ctrl) +{ + return ctrl->read.shr->prod; +} + +static inline uint32_t* _rd_cons(struct libxenvchan *ctrl) +{ + return &ctrl->read.shr->cons; +} +#define rd_cons(x) (*_rd_cons(x)) + +static inline uint32_t* _wr_prod(struct libxenvchan *ctrl) +{ + return &ctrl->write.shr->prod; +} +#define wr_prod(x) (*_wr_prod(x)) + +static inline uint32_t wr_cons(struct libxenvchan *ctrl) +{ + return ctrl->write.shr->cons; +} + +static inline const void* rd_ring(struct libxenvchan *ctrl) +{ + return ctrl->read.buffer; +} + +static inline void* wr_ring(struct libxenvchan *ctrl) +{ + return ctrl->write.buffer; +} + +static inline uint32_t wr_ring_size(struct libxenvchan *ctrl) +{ + return (1 << ctrl->write.order); +} + +static inline uint32_t rd_ring_size(struct libxenvchan *ctrl) +{ + return (1 << ctrl->read.order); +} + +static inline void request_notify(struct libxenvchan *ctrl, uint8_t bit) +{ + uint8_t *notify = ctrl->is_server ? &ctrl->ring->cli_notify : &ctrl->ring->srv_notify; + __sync_or_and_fetch(notify, bit); +} + +static inline int send_notify(struct libxenvchan *ctrl, uint8_t bit) +{ + uint8_t *notify = ctrl->is_server ? &ctrl->ring->srv_notify : &ctrl->ring->cli_notify; + uint8_t prev = __sync_fetch_and_and(notify, ~bit); + if (prev & bit) + return xc_evtchn_notify(ctrl->event, ctrl->event_port); + else + return 0; +} + +/** + * Get the amount of buffer space available and enable notifications if needed. + */ +static inline int fast_get_data_ready(struct libxenvchan *ctrl, size_t request) +{ + int ready = rd_prod(ctrl) - rd_cons(ctrl); + if (ready >= request) + return ready; + /* We plan to consume all data; please tell us if you send more */ + request_notify(ctrl, VCHAN_NOTIFY_WRITE); + /* + * If the writer moved rd_prod after our read but before request, we + * will not get notified even though the actual amount of data ready is + * above request. Reread rd_prod to cover this case. + */ + return rd_prod(ctrl) - rd_cons(ctrl); +} + +int libxenvchan_data_ready(struct libxenvchan *ctrl) +{ + /* Since this value is being used outside libxenvchan, request notification + * when it changes + */ + request_notify(ctrl, VCHAN_NOTIFY_WRITE); + return rd_prod(ctrl) - rd_cons(ctrl); +} + +/** + * Get the amount of buffer space available and enable notifications if needed. + */ +static inline int fast_get_buffer_space(struct libxenvchan *ctrl, size_t request) +{ + int ready = wr_ring_size(ctrl) - (wr_prod(ctrl) - wr_cons(ctrl)); + if (ready >= request) + return ready; + /* We plan to fill the buffer; please tell us when you've read it */ + request_notify(ctrl, VCHAN_NOTIFY_READ); + /* + * If the reader moved wr_cons after our read but before request, we + * will not get notified even though the actual amount of buffer space + * is above request. Reread wr_cons to cover this case. + */ + return wr_ring_size(ctrl) - (wr_prod(ctrl) - wr_cons(ctrl)); +} + +int libxenvchan_buffer_space(struct libxenvchan *ctrl) +{ + /* Since this value is being used outside libxenvchan, request notification + * when it changes + */ + request_notify(ctrl, VCHAN_NOTIFY_READ); + return wr_ring_size(ctrl) - (wr_prod(ctrl) - wr_cons(ctrl)); +} + +int libxenvchan_wait(struct libxenvchan *ctrl) +{ + int ret = xc_evtchn_pending(ctrl->event); + if (ret < 0) + return -1; + xc_evtchn_unmask(ctrl->event, ret); + return 0; +} + +/** + * returns -1 on error, or size on success + */ +static int do_send(struct libxenvchan *ctrl, const void *data, size_t size) +{ + int real_idx = wr_prod(ctrl) & (wr_ring_size(ctrl) - 1); + int avail_contig = wr_ring_size(ctrl) - real_idx; + if (VCHAN_DEBUG) { + char metainfo[32]; + struct iovec iov[2]; + iov[0].iov_base = metainfo; + iov[0].iov_len = snprintf(metainfo, 32, "vchan@%p wr", ctrl); + iov[1].iov_base = (void *)data; + iov[1].iov_len = size; + writev(-1, iov, 2); + } + if (avail_contig > size) + avail_contig = size; + memcpy(wr_ring(ctrl) + real_idx, data, avail_contig); + if (avail_contig < size) + { + // we rolled across the end of the ring + memcpy(wr_ring(ctrl), data + avail_contig, size - avail_contig); + } + barrier(); // data must be in the ring prior to increment + wr_prod(ctrl) += size; + barrier(); // increment must happen prior to notify + if (send_notify(ctrl, VCHAN_NOTIFY_WRITE)) + return -1; + return size; +} + +/** + * returns 0 if no buffer space is available, -1 on error, or size on success + */ +int libxenvchan_send(struct libxenvchan *ctrl, const void *data, size_t size) +{ + int avail; + while (1) { + if (!libxenvchan_is_open(ctrl)) + return -1; + avail = fast_get_buffer_space(ctrl, size); + if (size <= avail) + return do_send(ctrl, data, size); + if (!ctrl->blocking) + return 0; + if (size > wr_ring_size(ctrl)) + return -1; + if (libxenvchan_wait(ctrl)) + return -1; + } +} + +int libxenvchan_write(struct libxenvchan *ctrl, const void *data, size_t size) +{ + int avail; + if (!libxenvchan_is_open(ctrl)) + return -1; + if (ctrl->blocking) { + size_t pos = 0; + while (1) { + avail = fast_get_buffer_space(ctrl, size - pos); + if (pos + avail > size) + avail = size - pos; + if (avail) + pos += do_send(ctrl, data + pos, avail); + if (pos == size) + return pos; + if (libxenvchan_wait(ctrl)) + return -1; + if (!libxenvchan_is_open(ctrl)) + return -1; + } + } else { + avail = fast_get_buffer_space(ctrl, size); + if (size > avail) + size = avail; + if (size == 0) + return 0; + return do_send(ctrl, data, size); + } +} + +static int do_recv(struct libxenvchan *ctrl, void *data, size_t size) +{ + int real_idx = rd_cons(ctrl) & (rd_ring_size(ctrl) - 1); + int avail_contig = rd_ring_size(ctrl) - real_idx; + if (avail_contig > size) + avail_contig = size; + barrier(); // data read must happen after rd_cons read + memcpy(data, rd_ring(ctrl) + real_idx, avail_contig); + if (avail_contig < size) + { + // we rolled across the end of the ring + memcpy(data + avail_contig, rd_ring(ctrl), size - avail_contig); + } + rd_cons(ctrl) += size; + if (VCHAN_DEBUG) { + char metainfo[32]; + struct iovec iov[2]; + iov[0].iov_base = metainfo; + iov[0].iov_len = snprintf(metainfo, 32, "vchan@%p rd", ctrl); + iov[1].iov_base = data; + iov[1].iov_len = size; + writev(-1, iov, 2); + } + barrier(); // consumption must happen prior to notify of newly freed space + if (send_notify(ctrl, VCHAN_NOTIFY_READ)) + return -1; + return size; +} + +/** + * reads exactly size bytes from the vchan. + * returns 0 if insufficient data is available, -1 on error, or size on success + */ +int libxenvchan_recv(struct libxenvchan *ctrl, void *data, size_t size) +{ + while (1) { + int avail = fast_get_data_ready(ctrl, size); + if (size <= avail) + return do_recv(ctrl, data, size); + if (!libxenvchan_is_open(ctrl)) + return -1; + if (!ctrl->blocking) + return 0; + if (size > rd_ring_size(ctrl)) + return -1; + if (libxenvchan_wait(ctrl)) + return -1; + } +} + +int libxenvchan_read(struct libxenvchan *ctrl, void *data, size_t size) +{ + while (1) { + int avail = fast_get_data_ready(ctrl, size); + if (avail && size > avail) + size = avail; + if (avail) + return do_recv(ctrl, data, size); + if (!libxenvchan_is_open(ctrl)) + return -1; + if (!ctrl->blocking) + return 0; + if (libxenvchan_wait(ctrl)) + return -1; + } +} + +int libxenvchan_is_open(struct libxenvchan* ctrl) +{ + if (ctrl->is_server) + return ctrl->server_persist ? 1 : ctrl->ring->cli_live; + else + return ctrl->ring->srv_live; +} + +int libxenvchan_fd_for_select(struct libxenvchan *ctrl) +{ + return xc_evtchn_fd(ctrl->event); +} + +void libxenvchan_close(struct libxenvchan *ctrl) +{ + if (!ctrl) + return; + if (ctrl->read.order >= PAGE_SHIFT) + munmap(ctrl->read.buffer, 1 << ctrl->read.order); + if (ctrl->write.order >= PAGE_SHIFT) + munmap(ctrl->write.buffer, 1 << ctrl->write.order); + if (ctrl->ring) { + if (ctrl->is_server) { + ctrl->ring->srv_live = 0; + xc_gntshr_munmap(ctrl->gntshr, ctrl->ring, PAGE_SIZE); + } else { + ctrl->ring->cli_live = 0; + xc_gnttab_munmap(ctrl->gnttab, ctrl->ring, PAGE_SIZE); + } + } + if (ctrl->event) { + if (ctrl->event_port >= 0 && ctrl->ring) + xc_evtchn_notify(ctrl->event, ctrl->event_port); + xc_evtchn_close(ctrl->event); + } + if (ctrl->is_server) { + if (ctrl->gntshr) + xc_gntshr_close(ctrl->gntshr); + } else { + if (ctrl->gnttab) + xc_gnttab_close(ctrl->gnttab); + } + free(ctrl); +} diff --git a/tools/libvchan/libxenvchan.h b/tools/libvchan/libxenvchan.h new file mode 100644 index 0000000..6365d36 --- /dev/null +++ b/tools/libvchan/libxenvchan.h @@ -0,0 +1,169 @@ +/** + * @file + * @section AUTHORS + * + * Copyright (C) 2010 Rafal Wojtczuk <rafal@invisiblethingslab.com> + * + * Authors: + * Rafal Wojtczuk <rafal@invisiblethingslab.com> + * Daniel De Graaf <dgdegra@tycho.nsa.gov> + * + * @section LICENSE + * + * This library is free software; you can redistribute it and/or + * modify it under the terms of the GNU Lesser General Public + * License as published by the Free Software Foundation; either + * version 2.1 of the License, or (at your option) any later version. + * + * This library is distributed in the hope that it will be useful, + * but WITHOUT ANY WARRANTY; without even the implied warranty of + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU + * Lesser General Public License for more details. + * + * You should have received a copy of the GNU Lesser General Public + * License along with this library; if not, write to the Free Software + * Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston, MA 02110-1301 USA + * + * @section DESCRIPTION + * + * Originally borrowed from the Qubes OS Project, http://www.qubes-os.org, + * this code has been substantially rewritten to use the gntdev and gntalloc + * devices instead of raw MFNs and map_foreign_range. + * + * This is a library for inter-domain communication. A standard Xen ring + * buffer is used, with a datagram-based interface built on top. The grant + * reference and event channels are shared in XenStore under the path + * /local/domain/<srv-id>/data/vchan/<cli-id>/<port>/{ring-ref,event-channel} + * + * The ring.h macros define an asymmetric interface to a shared data structure + * that assumes all rings reside in a single contiguous memory space. This is + * not suitable for vchan because the interface to the ring is symmetric except + * for the setup. Unlike the producer-consumer rings defined in ring.h, the + * size of the rings used in vchan are determined at execution time instead of + * compile time, so the macros in ring.h cannot be used to access the rings. + */ + +#include <xen/io/libxenvchan.h> +#include <xen/sys/evtchn.h> +#include <xenctrl.h> + +struct libxenvchan_ring { + /* Pointer into the shared page. Offsets into buffer. */ + struct ring_shared* shr; + /* ring data; may be its own shared page(s) depending on order */ + void* buffer; + /** + * The size of the ring is (1 << order); offsets wrap around when they + * exceed this. This copy is required because we can't trust the order + * in the shared page to remain constant. + */ + int order; +}; + +/** + * struct libxenvchan: control structure passed to all library calls + */ +struct libxenvchan { + /* Mapping handle for shared ring page */ + union { + xc_gntshr *gntshr; /* for server */ + xc_gnttab *gnttab; /* for client */ + }; + /* Pointer to shared ring page */ + struct vchan_interface *ring; + /* event channel interface */ + xc_evtchn *event; + uint32_t event_port; + /* informative flags: are we acting as server? */ + int is_server:1; + /* true if server remains active when client closes (allows reconnection) */ + int server_persist:1; + /* true if operations should block instead of returning 0 */ + int blocking:1; + /* communication rings */ + struct libxenvchan_ring read, write; +}; + +/** + * Set up a vchan, including granting pages + * @param logger Logger for libxc errors + * @param domain The peer domain that will be connecting + * @param xs_path Base xenstore path for storing ring/event data + * @param send_min The minimum size (in bytes) of the send ring (left) + * @param recv_min The minimum size (in bytes) of the receive ring (right) + * @return The structure, or NULL in case of an error + */ +struct libxenvchan *libxenvchan_server_init(xentoollog_logger *logger, int domain, const char* xs_path, size_t read_min, size_t write_min); +/** + * Connect to an existing vchan. Note: you can reconnect to an existing vchan + * safely, however no locking is performed, so you must prevent multiple clients + * from connecting to a single server. + * + * @param logger Logger for libxc errors + * @param domain The peer domain to connect to + * @param xs_path Base xenstore path for storing ring/event data + * @return The structure, or NULL in case of an error + */ +struct libxenvchan *libxenvchan_client_init(xentoollog_logger *logger, int domain, const char* xs_path); +/** + * Close a vchan. This deallocates the vchan and attempts to free its + * resources. The other side is notified of the close, but can still read any + * data pending prior to the close. + */ +void libxenvchan_close(struct libxenvchan *ctrl); + +/** + * Packet-based receive: always reads exactly $size bytes. + * @param ctrl The vchan control structure + * @param data Buffer for data that was read + * @param size Size of the buffer and amount of data to read + * @return -1 on error, 0 if nonblocking and insufficient data is available, or $size + */ +int libxenvchan_recv(struct libxenvchan *ctrl, void *data, size_t size); +/** + * Stream-based receive: reads as much data as possible. + * @param ctrl The vchan control structure + * @param data Buffer for data that was read + * @param size Size of the buffer + * @return -1 on error, otherwise the amount of data read (which may be zero if + * the vchan is nonblocking) + */ +int libxenvchan_read(struct libxenvchan *ctrl, void *data, size_t size); +/** + * Packet-based send: send entire buffer if possible + * @param ctrl The vchan control structure + * @param data Buffer for data to send + * @param size Size of the buffer and amount of data to send + * @return -1 on error, 0 if nonblocking and insufficient space is available, or $size + */ +int libxenvchan_send(struct libxenvchan *ctrl, const void *data, size_t size); +/** + * Stream-based send: send as much data as possible. + * @param ctrl The vchan control structure + * @param data Buffer for data to send + * @param size Size of the buffer + * @return -1 on error, otherwise the amount of data sent (which may be zero if + * the vchan is nonblocking) + */ +int libxenvchan_write(struct libxenvchan *ctrl, const void *data, size_t size); +/** + * Waits for reads or writes to unblock, or for a close + */ +int libxenvchan_wait(struct libxenvchan *ctrl); +/** + * Returns the event file descriptor for this vchan. When this FD is readable, + * libxenvchan_wait() will not block, and the state of the vchan has changed since + * the last invocation of libxenvchan_wait(). + */ +int libxenvchan_fd_for_select(struct libxenvchan *ctrl); +/** + * Query the state of the vchan shared page: + * return 0 when one side has called libxenvchan_close() or crashed + * return 1 when both sides are open + * return 2 [server only] when no client has yet connected + */ +int libxenvchan_is_open(struct libxenvchan* ctrl); +/** Amount of data ready to read, in bytes */ +int libxenvchan_data_ready(struct libxenvchan *ctrl); +/** Amount of data it is possible to send without blocking */ +int libxenvchan_buffer_space(struct libxenvchan *ctrl); diff --git a/tools/libvchan/node-select.c b/tools/libvchan/node-select.c new file mode 100644 index 0000000..6c6c19e --- /dev/null +++ b/tools/libvchan/node-select.c @@ -0,0 +1,162 @@ +/** + * @file + * @section AUTHORS + * + * Copyright (C) 2010 Rafal Wojtczuk <rafal@invisiblethingslab.com> + * + * Authors: + * Rafal Wojtczuk <rafal@invisiblethingslab.com> + * Daniel De Graaf <dgdegra@tycho.nsa.gov> + * + * @section LICENSE + * + * This program is free software; you can redistribute it and/or + * modify it under the terms of the GNU Lesser General Public + * License as published by the Free Software Foundation; either + * version 2.1 of the License, or (at your option) any later version. + * + * This program is distributed in the hope that it will be useful, + * but WITHOUT ANY WARRANTY; without even the implied warranty of + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU + * Lesser General Public License for more details. + * + * You should have received a copy of the GNU Lesser General Public + * License along with this program; if not, write to the Free Software + * Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston, MA 02110-1301 USA + * + * @section DESCRIPTION + * + * This is a test program for libxenvchan. Communications are bidirectional, + * with either server (grant offeror) or client able to read and write. + */ + +#include <stdlib.h> +#include <stdio.h> +#include <string.h> +#include <unistd.h> +#include <fcntl.h> +#include <errno.h> + +#include <libxenvchan.h> + +void usage(char** argv) +{ + fprintf(stderr, "usage:\n" + "\t%s [client|server] domainid nodepath [rbufsiz wbufsiz]\n", + argv[0]); + exit(1); +} + +#define BUFSIZE 5000 +char inbuf[BUFSIZE]; +char outbuf[BUFSIZE]; +int insiz = 0; +int outsiz = 0; +struct libxenvchan *ctrl = 0; + +void vchan_wr() { + if (!insiz) + return; + int ret = libxenvchan_write(ctrl, inbuf, insiz); + if (ret < 0) { + fprintf(stderr, "vchan write failed\n"); + exit(1); + } + if (ret > 0) { + insiz -= ret; + memmove(inbuf, inbuf + ret, insiz); + } +} + +void stdout_wr() { + if (!outsiz) + return; + int ret = write(1, outbuf, outsiz); + if (ret < 0 && errno != EAGAIN) + exit(1); + if (ret > 0) { + outsiz -= ret; + memmove(outbuf, outbuf + ret, outsiz); + } +} + +/** + Simple libxenvchan application, both client and server. + Both sides may write and read, both from the libxenvchan and from + stdin/stdout (just like netcat). +*/ + +int main(int argc, char **argv) +{ + int ret; + int libxenvchan_fd; + if (argc < 4 || argv[3][0] != '/') + usage(argv); + if (!strcmp(argv[1], "server")) { + int rsiz = argc > 4 ? atoi(argv[4]) : 0; + int wsiz = argc > 5 ? atoi(argv[5]) : 0; + ctrl = libxenvchan_server_init(NULL, atoi(argv[2]), argv[3], rsiz, wsiz); + } else if (!strcmp(argv[1], "client")) + ctrl = libxenvchan_client_init(NULL, atoi(argv[2]), argv[3]); + else + usage(argv); + if (!ctrl) { + perror("libxenvchan_*_init"); + exit(1); + } + + fcntl(0, F_SETFL, O_NONBLOCK); + fcntl(1, F_SETFL, O_NONBLOCK); + + libxenvchan_fd = libxenvchan_fd_for_select(ctrl); + for (;;) { + fd_set rfds; + fd_set wfds; + FD_ZERO(&rfds); + FD_ZERO(&wfds); + if (insiz != BUFSIZE) + FD_SET(0, &rfds); + if (outsiz) + FD_SET(1, &wfds); + FD_SET(libxenvchan_fd, &rfds); + ret = select(libxenvchan_fd + 1, &rfds, &wfds, NULL, NULL); + if (ret < 0) { + perror("select"); + exit(1); + } + if (FD_ISSET(0, &rfds)) { + ret = read(0, inbuf + insiz, BUFSIZE - insiz); + if (ret < 0 && errno != EAGAIN) + exit(1); + if (ret == 0) { + while (insiz) { + vchan_wr(); + libxenvchan_wait(ctrl); + } + return 0; + } + if (ret) + insiz += ret; + vchan_wr(); + } + if (FD_ISSET(libxenvchan_fd, &rfds)) { + libxenvchan_wait(ctrl); + vchan_wr(); + } + if (FD_ISSET(1, &wfds)) + stdout_wr(); + while (libxenvchan_data_ready(ctrl) && outsiz < BUFSIZE) { + ret = libxenvchan_read(ctrl, outbuf + outsiz, BUFSIZE - outsiz); + if (ret < 0) + exit(1); + outsiz += ret; + stdout_wr(); + } + if (!libxenvchan_is_open(ctrl)) { + fcntl(1, F_SETFL, 0); + while (outsiz) + stdout_wr(); + return 0; + } + } +} diff --git a/tools/libvchan/node.c b/tools/libvchan/node.c new file mode 100644 index 0000000..cab8368 --- /dev/null +++ b/tools/libvchan/node.c @@ -0,0 +1,169 @@ +/** + * @file + * @section AUTHORS + * + * Copyright (C) 2010 Rafal Wojtczuk <rafal@invisiblethingslab.com> + * + * Authors: + * Rafal Wojtczuk <rafal@invisiblethingslab.com> + * Daniel De Graaf <dgdegra@tycho.nsa.gov> + * + * @section LICENSE + * + * This program is free software; you can redistribute it and/or + * modify it under the terms of the GNU Lesser General Public + * License as published by the Free Software Foundation; either + * version 2.1 of the License, or (at your option) any later version. + * + * This program is distributed in the hope that it will be useful, + * but WITHOUT ANY WARRANTY; without even the implied warranty of + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU + * Lesser General Public License for more details. + * + * You should have received a copy of the GNU Lesser General Public + * License along with this program; if not, write to the Free Software + * Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston, MA 02110-1301 USA + * + * @section DESCRIPTION + * + * This is a test program for libxenvchan. Communications are in one direction, + * either server (grant offeror) to client or vice versa. + */ + +#include <stdlib.h> +#include <stdio.h> +#include <string.h> +#include <unistd.h> +#include <time.h> + +#include <libxenvchan.h> + +int libxenvchan_write_all(struct libxenvchan *ctrl, char *buf, int size) +{ + int written = 0; + int ret; + while (written < size) { + ret = libxenvchan_write(ctrl, buf + written, size - written); + if (ret <= 0) { + perror("write"); + exit(1); + } + written += ret; + } + return size; +} + +int write_all(int fd, char *buf, int size) +{ + int written = 0; + int ret; + while (written < size) { + ret = write(fd, buf + written, size - written); + if (ret <= 0) { + perror("write"); + exit(1); + } + written += ret; + } + return size; +} + +void usage(char** argv) +{ + fprintf(stderr, "usage:\n" + "%s [client|server] [read|write] domid nodepath\n", argv[0]); + exit(1); +} + +#define BUFSIZE 5000 +char buf[BUFSIZE]; +void reader(struct libxenvchan *ctrl) +{ + int size; + for (;;) { + size = rand() % (BUFSIZE - 1) + 1; + size = libxenvchan_read(ctrl, buf, size); + fprintf(stderr, "#"); + if (size < 0) { + perror("read vchan"); + libxenvchan_close(ctrl); + exit(1); + } + size = write_all(1, buf, size); + if (size < 0) { + perror("stdout write"); + exit(1); + } + if (size == 0) { + perror("write size=0?\n"); + exit(1); + } + } +} + +void writer(struct libxenvchan *ctrl) +{ + int size; + for (;;) { + size = rand() % (BUFSIZE - 1) + 1; + size = read(0, buf, size); + if (size < 0) { + perror("read stdin"); + libxenvchan_close(ctrl); + exit(1); + } + if (size == 0) + break; + size = libxenvchan_write_all(ctrl, buf, size); + fprintf(stderr, "#"); + if (size < 0) { + perror("vchan write"); + exit(1); + } + if (size == 0) { + perror("write size=0?\n"); + exit(1); + } + } +} + + +/** + Simple libxenvchan application, both client and server. + One side does writing, the other side does reading; both from + standard input/output fds. +*/ +int main(int argc, char **argv) +{ + int seed = time(0); + struct libxenvchan *ctrl = 0; + int wr = 0; + if (argc < 4) + usage(argv); + if (!strcmp(argv[2], "read")) + wr = 0; + else if (!strcmp(argv[2], "write")) + wr = 1; + else + usage(argv); + if (!strcmp(argv[1], "server")) + ctrl = libxenvchan_server_init(NULL, atoi(argv[3]), argv[4], 0, 0); + else if (!strcmp(argv[1], "client")) + ctrl = libxenvchan_client_init(NULL, atoi(argv[3]), argv[4]); + else + usage(argv); + if (!ctrl) { + perror("libxenvchan_*_init"); + exit(1); + } + ctrl->blocking = 1; + + srand(seed); + fprintf(stderr, "seed=%d\n", seed); + if (wr) + writer(ctrl); + else + reader(ctrl); + libxenvchan_close(ctrl); + return 0; +} diff --git a/xen/include/public/io/libxenvchan.h b/xen/include/public/io/libxenvchan.h new file mode 100644 index 0000000..5c3d3d4 --- /dev/null +++ b/xen/include/public/io/libxenvchan.h @@ -0,0 +1,97 @@ +/** + * @file + * @section AUTHORS + * + * Copyright (C) 2010 Rafal Wojtczuk <rafal@invisiblethingslab.com> + * + * Authors: + * Rafal Wojtczuk <rafal@invisiblethingslab.com> + * Daniel De Graaf <dgdegra@tycho.nsa.gov> + * + * @section LICENSE + * + * This library is free software; you can redistribute it and/or + * modify it under the terms of the GNU Lesser General Public + * License as published by the Free Software Foundation; either + * version 2.1 of the License, or (at your option) any later version. + * + * This library is distributed in the hope that it will be useful, + * but WITHOUT ANY WARRANTY; without even the implied warranty of + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU + * Lesser General Public License for more details. + * + * You should have received a copy of the GNU Lesser General Public + * License along with this library; if not, write to the Free Software + * Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston, MA 02110-1301 USA + * + * @section DESCRIPTION + * + * Originally borrowed from the Qubes OS Project, http://www.qubes-os.org, + * this code has been substantially rewritten to use the gntdev and gntalloc + * devices instead of raw MFNs and map_foreign_range. + * + * This is a library for inter-domain communication. A standard Xen ring + * buffer is used, with a datagram-based interface built on top. The grant + * reference and event channels are shared in XenStore under a user-specified + * path. + * + * The ring.h macros define an asymmetric interface to a shared data structure + * that assumes all rings reside in a single contiguous memory space. This is + * not suitable for vchan because the interface to the ring is symmetric except + * for the setup. Unlike the producer-consumer rings defined in ring.h, the + * size of the rings used in vchan are determined at execution time instead of + * compile time, so the macros in ring.h cannot be used to access the rings. + */ + +#include <stdint.h> +#include <sys/types.h> + +struct ring_shared { + uint32_t cons, prod; +}; + +#define VCHAN_NOTIFY_WRITE 0x1 +#define VCHAN_NOTIFY_READ 0x2 + +/** + * vchan_interface: primary shared data structure + */ +struct vchan_interface { + /** + * Standard consumer/producer interface, one pair per buffer + * left is client write, server read + * right is client read, server write + */ + struct ring_shared left, right; + /** + * size of the rings, which determines their location + * 10 - at offset 1024 in ring's page + * 11 - at offset 2048 in ring's page + * 12+ - uses 2^(N-12) grants to describe the multi-page ring + * These should remain constant once the page is shared. + * Only one of the two orders can be 10 (or 11). + */ + uint16_t left_order, right_order; + /** + * Shutdown detection: + * 0: client (or server) has exited + * 1: client (or server) is connected + * 2: client has not yet connected + */ + uint8_t cli_live, srv_live; + /** + * Notification bits: + * VCHAN_NOTIFY_WRITE: send notify when data is written + * VCHAN_NOTIFY_READ: send notify when data is read (consumed) + * cli_notify is used for the client to inform the server of its action + */ + uint8_t cli_notify, srv_notify; + /** + * Grant list: ordering is left, right. Must not extend into actual ring + * or grow beyond the end of the initial shared page. + * These should remain constant once the page is shared, to allow + * for possible remapping by a client that restarts. + */ + uint32_t grants[0]; +}; + -- 1.7.6.2 _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel From xen-devel-bounces@lists.xensource.com Thu Sep 22 15:19:26 2011 Return-path: <xen-devel-bounces@lists.xensource.com> Envelope-to: www-data@lists.xensource.com Delivery-date: Thu, 22 Sep 2011 15:19:26 -0700 Received: from localhost ([127.0.0.1] helo=lists.colo.xensource.com) by lists.xensource.com with esmtp (Exim 4.43) id 1R6rc6-0003NG-Mw; Thu, 22 Sep 2011 15:19:26 -0700 Received: from mail21.messagelabs.com ([85.158.143.35]) by lists.xensource.com with smtp (Exim 4.43) id 1R6rXR-00022d-S2 for xen-devel@lists.xensource.com; Thu, 22 Sep 2011 15:14:54 -0700 X-Env-Sender: dgdegra@tycho.nsa.gov X-Msg-Ref: server-14.tower-21.messagelabs.com!1316729665!60617171!1 X-Originating-IP: [63.239.65.39] X-StarScan-Version: 6.4.1; banners=-,-,- X-VirusChecked: Checked Received: (qmail 21519 invoked from network); 22 Sep 2011 22:14:25 -0000 Received: from msux-gh1-uea01.nsa.gov (HELO msux-gh1-uea01.nsa.gov) (63.239.65.39) by server-14.tower-21.messagelabs.com with SMTP; 22 Sep 2011 22:14:25 -0000 Received: from tarius.tycho.ncsc.mil (localhost [127.0.0.1]) by msux-gh1-uea01.nsa.gov (8.12.10/8.12.10) with ESMTP id p8MMEV1V010120; Thu, 22 Sep 2011 22:14:31 GMT Received: from moss-nexus.epoch.ncsc.mil (moss-nexus [144.51.25.48]) by tarius.tycho.ncsc.mil (8.13.1/8.13.1) with ESMTP id p8MMEVar005750; Thu, 22 Sep 2011 18:14:31 -0400 From: Daniel De Graaf <dgdegra@tycho.nsa.gov> To: xen-devel@lists.xensource.com Date: Thu, 22 Sep 2011 18:14:23 -0400 Message-Id: <1316729665-15004-2-git-send-email-dgdegra@tycho.nsa.gov> X-Mailer: git-send-email 1.7.6.2 In-Reply-To: <1316729665-15004-1-git-send-email-dgdegra@tycho.nsa.gov> References: <1313764724-12683-1-git-send-email-dgdegra@tycho.nsa.gov> <1316729665-15004-1-git-send-email-dgdegra@tycho.nsa.gov> Cc: Ian.Campbell@eu.citrix.com, Daniel De Graaf <dgdegra@tycho.nsa.gov>, Stefano.Stabellini@eu.citrix.com, Ian.Jackson@eu.citrix.com, konrad.wilk@oracle.com Subject: [Xen-devel] [PATCH 1/3] libxc: add xc_gnttab_map_grant_ref_notify X-BeenThere: xen-devel@lists.xensource.com X-Mailman-Version: 2.1.5 Precedence: list List-Id: Xen developer discussion <xen-devel.lists.xensource.com> List-Unsubscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe> List-Post: <mailto:xen-devel@lists.xensource.com> List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help> List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=subscribe> Sender: xen-devel-bounces@lists.xensource.com Errors-To: xen-devel-bounces@lists.xensource.com Normally, when a userspace process mapping a grant crashes, the domain providing the reference receives no indication that its peer has crashed, possibly leading to unexpected freezes or timeouts. This function provides a notification of the unmap by signalling an event channel and/or clearing a specific byte in the page. This also unifies the 3 very similar grant-mapping osdep interfaces into a single function instead of introducing yet another minor variation. Signed-off-by: Daniel De Graaf <dgdegra@tycho.nsa.gov> --- tools/include/xen-sys/Linux/gntdev.h | 33 ++++++++++- tools/libxc/xc_gnttab.c | 26 ++++++-- tools/libxc/xc_linux_osdep.c | 112 +++++++++++++++------------------ tools/libxc/xc_minios.c | 54 +++++------------ tools/libxc/xenctrl.h | 23 +++++++ tools/libxc/xenctrlosdep.h | 20 ++---- tools/libxl/libxlu_cfg_l.c | 102 ++++++++++++++----------------- tools/libxl/libxlu_cfg_l.h | 32 +++------ 8 files changed, 204 insertions(+), 198 deletions(-) diff --git a/tools/include/xen-sys/Linux/gntdev.h b/tools/include/xen-sys/Linux/gntdev.h index 8bd1467..caf6fb4 100644 --- a/tools/include/xen-sys/Linux/gntdev.h +++ b/tools/include/xen-sys/Linux/gntdev.h @@ -66,7 +66,7 @@ struct ioctl_gntdev_map_grant_ref { * before this ioctl is called, or an error will result. */ #define IOCTL_GNTDEV_UNMAP_GRANT_REF \ -_IOC(_IOC_NONE, 'G', 1, sizeof(struct ioctl_gntdev_unmap_grant_ref)) +_IOC(_IOC_NONE, 'G', 1, sizeof(struct ioctl_gntdev_unmap_grant_ref)) struct ioctl_gntdev_unmap_grant_ref { /* IN parameters */ /* The offset was returned by the corresponding map operation. */ @@ -116,4 +116,35 @@ struct ioctl_gntdev_set_max_grants { uint32_t count; }; +/* + * Sets up an unmap notification within the page, so that the other side can do + * cleanup if this side crashes. Required to implement cross-domain robust + * mutexes or close notification on communication channels. + * + * Each mapped page only supports one notification; multiple calls referring to + * the same page overwrite the previous notification. You must clear the + * notification prior to the IOCTL_GNTALLOC_DEALLOC_GREF if you do not want it + * to occur. + */ +#define IOCTL_GNTDEV_SET_UNMAP_NOTIFY \ +_IOC(_IOC_NONE, 'G', 7, sizeof(struct ioctl_gntdev_unmap_notify)) +struct ioctl_gntdev_unmap_notify { + /* IN parameters */ + /* Offset in the file descriptor for a byte within the page. This offset + * is the result of the IOCTL_GNTDEV_MAP_GRANT_REF and is the same as + * is used with mmap(). If using UNMAP_NOTIFY_CLEAR_BYTE, this is the byte + * within the page to be cleared. + */ + uint64_t index; + /* Action(s) to take on unmap */ + uint32_t action; + /* Event channel to notify */ + uint32_t event_channel_port; +}; + +/* Clear (set to zero) the byte specified by index */ +#define UNMAP_NOTIFY_CLEAR_BYTE 0x1 +/* Send an interrupt on the indicated event channel */ +#define UNMAP_NOTIFY_SEND_EVENT 0x2 + #endif /* __LINUX_PUBLIC_GNTDEV_H__ */ diff --git a/tools/libxc/xc_gnttab.c b/tools/libxc/xc_gnttab.c index 4f55fce..033cc5c 100644 --- a/tools/libxc/xc_gnttab.c +++ b/tools/libxc/xc_gnttab.c @@ -18,6 +18,7 @@ */ #include "xc_private.h" +#include <errno.h> int xc_gnttab_op(xc_interface *xch, int cmd, void * op, int op_size, int count) { @@ -150,8 +151,8 @@ void *xc_gnttab_map_grant_ref(xc_gnttab *xcg, uint32_t ref, int prot) { - return xcg->ops->u.gnttab.map_grant_ref(xcg, xcg->ops_handle, - domid, ref, prot); + return xcg->ops->u.gnttab.grant_map(xcg, xcg->ops_handle, 1, 0, prot, + &domid, &ref, -1, -1); } void *xc_gnttab_map_grant_refs(xc_gnttab *xcg, @@ -160,8 +161,8 @@ void *xc_gnttab_map_grant_refs(xc_gnttab *xcg, uint32_t *refs, int prot) { - return xcg->ops->u.gnttab.map_grant_refs(xcg, xcg->ops_handle, - count, domids, refs, prot); + return xcg->ops->u.gnttab.grant_map(xcg, xcg->ops_handle, count, 0, + prot, domids, refs, -1, -1); } void *xc_gnttab_map_domain_grant_refs(xc_gnttab *xcg, @@ -170,10 +171,23 @@ void *xc_gnttab_map_domain_grant_refs(xc_gnttab *xcg, uint32_t *refs, int prot) { - return xcg->ops->u.gnttab.map_domain_grant_refs(xcg, xcg->ops_handle, - count, domid, refs, prot); + return xcg->ops->u.gnttab.grant_map(xcg, xcg->ops_handle, count, + XC_GRANT_MAP_SINGLE_DOMAIN, + prot, &domid, refs, -1, -1); } +void *xc_gnttab_map_grant_ref_notify(xc_gnttab *xcg, + uint32_t domid, + uint32_t ref, + int prot, + uint32_t notify_offset, + evtchn_port_t notify_port) +{ + return xcg->ops->u.gnttab.grant_map(xcg, xcg->ops_handle, 1, 0, prot, + &domid, &ref, notify_offset, notify_port); +} + + int xc_gnttab_munmap(xc_gnttab *xcg, void *start_address, uint32_t count) diff --git a/tools/libxc/xc_linux_osdep.c b/tools/libxc/xc_linux_osdep.c index dca6718..f760421 100644 --- a/tools/libxc/xc_linux_osdep.c +++ b/tools/libxc/xc_linux_osdep.c @@ -509,56 +509,21 @@ static int linux_gnttab_close(xc_gnttab *xcg, xc_osdep_handle h) return close(fd); } -static void *linux_gnttab_map_grant_ref(xc_gnttab *xch, xc_osdep_handle h, - uint32_t domid, uint32_t ref, int prot) -{ - int fd = (int)h; - struct ioctl_gntdev_map_grant_ref map; - void *addr; - - map.count = 1; - map.refs[0].domid = domid; - map.refs[0].ref = ref; - - if ( ioctl(fd, IOCTL_GNTDEV_MAP_GRANT_REF, &map) ) { - PERROR("xc_gnttab_map_grant_ref: ioctl MAP_GRANT_REF failed"); - return NULL; - } - -mmap_again: - addr = mmap(NULL, XC_PAGE_SIZE, prot, MAP_SHARED, fd, map.index); - if ( addr == MAP_FAILED ) - { - int saved_errno = errno; - struct ioctl_gntdev_unmap_grant_ref unmap_grant; - - if(saved_errno == EAGAIN) - { - usleep(1000); - goto mmap_again; - } - /* Unmap the driver slots used to store the grant information. */ - PERROR("xc_gnttab_map_grant_ref: mmap failed"); - unmap_grant.index = map.index; - unmap_grant.count = 1; - ioctl(fd, IOCTL_GNTDEV_UNMAP_GRANT_REF, &unmap_grant); - errno = saved_errno; - return NULL; - } - - return addr; -} - -static void *do_gnttab_map_grant_refs(xc_gnttab *xch, xc_osdep_handle h, - uint32_t count, - uint32_t *domids, int domids_stride, - uint32_t *refs, int prot) +static void *linux_gnttab_grant_map(xc_gnttab *xch, xc_osdep_handle h, + uint32_t count, int flags, int prot, + uint32_t *domids, uint32_t *refs, + uint32_t notify_offset, + evtchn_port_t notify_port) { int fd = (int)h; struct ioctl_gntdev_map_grant_ref *map; void *addr = NULL; + int domids_stride = 1; int i; + if (flags & XC_GRANT_MAP_SINGLE_DOMAIN) + domids_stride = 0; + map = malloc(sizeof(*map) + (count - 1) * sizeof(struct ioctl_gntdev_map_grant_ref)); if ( map == NULL ) @@ -573,13 +538,52 @@ static void *do_gnttab_map_grant_refs(xc_gnttab *xch, xc_osdep_handle h, map->count = count; if ( ioctl(fd, IOCTL_GNTDEV_MAP_GRANT_REF, map) ) { - PERROR("xc_gnttab_map_grant_refs: ioctl MAP_GRANT_REF failed"); + PERROR("linux_gnttab_grant_map: ioctl MAP_GRANT_REF failed"); goto out; } + retry: addr = mmap(NULL, XC_PAGE_SIZE * count, prot, MAP_SHARED, fd, map->index); - if ( addr == MAP_FAILED ) + + if (addr == MAP_FAILED && errno == EAGAIN) + { + /* + * The grant hypercall can return EAGAIN if the granted page is + * swapped out. Since the paging daemon may be in the same domain, the + * hypercall cannot block without causing a deadlock. + * + * Because there are no notificaitons when the page is swapped in, wait + * a bit before retrying, and hope that the page will arrive eventually. + */ + usleep(1000); + goto retry; + } + + if (addr != MAP_FAILED) + { + int rv = 0; + struct ioctl_gntdev_unmap_notify notify; + notify.index = map->index; + notify.action = 0; + if (notify_offset >= 0 && notify_offset < XC_PAGE_SIZE * count) { + notify.index += notify_offset; + notify.action |= UNMAP_NOTIFY_CLEAR_BYTE; + } + if (notify_port != -1) { + notify.event_channel_port = notify_port; + notify.action |= UNMAP_NOTIFY_SEND_EVENT; + } + if (notify.action) + rv = ioctl(fd, IOCTL_GNTDEV_SET_UNMAP_NOTIFY, ¬ify); + if (rv) { + PERROR("linux_gnttab_grant_map: ioctl SET_UNMAP_NOTIFY failed"); + munmap(addr, count * XC_PAGE_SIZE); + addr = MAP_FAILED; + } + } + + if (addr == MAP_FAILED) { int saved_errno = errno; struct ioctl_gntdev_unmap_grant_ref unmap_grant; @@ -599,19 +603,7 @@ static void *do_gnttab_map_grant_refs(xc_gnttab *xch, xc_osdep_handle h, return addr; } -static void *linux_gnttab_map_grant_refs(xc_gnttab *xcg, xc_osdep_handle h, - uint32_t count, uint32_t *domids, - uint32_t *refs, int prot) -{ - return do_gnttab_map_grant_refs(xcg, h, count, domids, 1, refs, prot); -} -static void *linux_gnttab_map_domain_grant_refs(xc_gnttab *xcg, xc_osdep_handle h, - uint32_t count, - uint32_t domid, uint32_t *refs, int prot) -{ - return do_gnttab_map_grant_refs(xcg, h, count, &domid, 0, refs, prot); -} static int linux_gnttab_munmap(xc_gnttab *xcg, xc_osdep_handle h, void *start_address, uint32_t count) @@ -659,9 +651,7 @@ static struct xc_osdep_ops linux_gnttab_ops = { .close = &linux_gnttab_close, .u.gnttab = { - .map_grant_ref = &linux_gnttab_map_grant_ref, - .map_grant_refs = &linux_gnttab_map_grant_refs, - .map_domain_grant_refs = &linux_gnttab_map_domain_grant_refs, + .grant_map = &linux_gnttab_grant_map, .munmap = &linux_gnttab_munmap, }, }; diff --git a/tools/libxc/xc_minios.c b/tools/libxc/xc_minios.c index 3b366eb..ff9c0d8 100644 --- a/tools/libxc/xc_minios.c +++ b/tools/libxc/xc_minios.c @@ -458,45 +458,23 @@ void minios_gnttab_close_fd(int fd) files[fd].type = FTYPE_NONE; } -static void *minios_gnttab_map_grant_ref(xc_gnttab *xcg, xc_osdep_handle h, - uint32_t domid, - uint32_t ref, - int prot) -{ - int fd = (int)h; - return gntmap_map_grant_refs(&files[fd].gntmap, - 1, - &domid, 0, - &ref, - prot & PROT_WRITE); -} - -static void *minios_gnttab_map_grant_refs(xc_gnttab *xcg, xc_osdep_handle h, - uint32_t count, - uint32_t *domids, - uint32_t *refs, - int prot) -{ - int fd = (int)h; - return gntmap_map_grant_refs(&files[fd].gntmap, - count, - domids, 1, - refs, - prot & PROT_WRITE); -} - -static void *minios_gnttab_map_domain_grant_refs(xc_gnttab *xcg, xc_osdep_handle h, - uint32_t count, - uint32_t domid, - uint32_t *refs, - int prot) +static void *minios_gnttab_grant_map(xc_gnttab *xcg, xc_osdep_handle h, + uint32_t count, int flags, int prot, + uint32_t *domids, uint32_t *refs, + uint32_t notify_offset, + evtchn_port_t notify_port) { int fd = (int)h; + int stride = 1; + if (flags & XC_GRANT_MAP_SINGLE_DOMAIN) + stride = 0; + if (notify_offset != -1 || notify_port != -1) { + errno = ENOSYS; + return NULL; + } return gntmap_map_grant_refs(&files[fd].gntmap, - count, - &domid, 0, - refs, - prot & PROT_WRITE); + count, domids, stride, + refs, prot & PROT_WRITE); } static int minios_gnttab_munmap(xc_gnttab *xcg, xc_osdep_handle h, @@ -534,9 +512,7 @@ static struct xc_osdep_ops minios_gnttab_ops = { .close = &minios_gnttab_close, .u.gnttab = { - .map_grant_ref = &minios_gnttab_map_grant_ref, - .map_grant_refs = &minios_gnttab_map_grant_refs, - .map_domain_grant_refs = &minios_gnttab_map_domain_grant_refs, + .grant_map = &minios_gnttab_grant_map, .munmap = &minios_gnttab_munmap, .set_max_grants = &minios_gnttab_set_max_grants, }, diff --git a/tools/libxc/xenctrl.h b/tools/libxc/xenctrl.h index 1b82ee0..6f3165d 100644 --- a/tools/libxc/xenctrl.h +++ b/tools/libxc/xenctrl.h @@ -1348,6 +1348,29 @@ void *xc_gnttab_map_domain_grant_refs(xc_gnttab *xcg, uint32_t *refs, int prot); +/** + * Memory maps a grant reference from one domain to a local address range. + * Mappings should be unmapped with xc_gnttab_munmap. If notify_offset or + * notify_port are not -1, this version will attempt to set up an unmap + * notification at the given offset and event channel. When the page is + * unmapped, the byte at the given offset will be zeroed and a wakeup will be + * sent to the given event channel. Logs errors. + * + * @parm xcg a handle on an open grant table interface + * @parm domid the domain to map memory from + * @parm ref the grant reference ID to map + * @parm prot same flag as in mmap() + * @parm notify_offset The byte offset in the page to use for unmap + * notification; -1 for none. + * @parm notify_port The event channel port to use for unmap notify, or -1 + */ +void *xc_gnttab_map_grant_ref_notify(xc_gnttab *xcg, + uint32_t domid, + uint32_t ref, + int prot, + uint32_t notify_offset, + evtchn_port_t notify_port); + /* * Unmaps the @count pages starting at @start_address, which were mapped by a * call to xc_gnttab_map_grant_ref or xc_gnttab_map_grant_refs. Never logs. diff --git a/tools/libxc/xenctrlosdep.h b/tools/libxc/xenctrlosdep.h index bfe46e0..1c6317e 100644 --- a/tools/libxc/xenctrlosdep.h +++ b/tools/libxc/xenctrlosdep.h @@ -105,20 +105,12 @@ struct xc_osdep_ops int (*unmask)(xc_evtchn *xce, xc_osdep_handle h, evtchn_port_t port); } evtchn; struct { - void *(*map_grant_ref)(xc_gnttab *xcg, xc_osdep_handle h, - uint32_t domid, - uint32_t ref, - int prot); - void *(*map_grant_refs)(xc_gnttab *xcg, xc_osdep_handle h, - uint32_t count, - uint32_t *domids, - uint32_t *refs, - int prot); - void *(*map_domain_grant_refs)(xc_gnttab *xcg, xc_osdep_handle h, - uint32_t count, - uint32_t domid, - uint32_t *refs, - int prot); +#define XC_GRANT_MAP_SINGLE_DOMAIN 0x1 + void *(*grant_map)(xc_gnttab *xcg, xc_osdep_handle h, + uint32_t count, int flags, int prot, + uint32_t *domids, uint32_t *refs, + uint32_t notify_offset, + evtchn_port_t notify_port); int (*munmap)(xc_gnttab *xcg, xc_osdep_handle h, void *start_address, uint32_t count); diff --git a/tools/libxl/libxlu_cfg_l.c b/tools/libxl/libxlu_cfg_l.c index 8448bef..2ffb958 100644 --- a/tools/libxl/libxlu_cfg_l.c +++ b/tools/libxl/libxlu_cfg_l.c @@ -34,7 +34,7 @@ #if defined (__STDC_VERSION__) && __STDC_VERSION__ >= 199901L /* C99 says to define __STDC_LIMIT_MACROS before including stdint.h, - * if you want the limit (max/min) macros for int types. + * if you want the limit (max/min) macros for int types. */ #ifndef __STDC_LIMIT_MACROS #define __STDC_LIMIT_MACROS 1 @@ -51,9 +51,10 @@ typedef uint32_t flex_uint32_t; typedef signed char flex_int8_t; typedef short int flex_int16_t; typedef int flex_int32_t; -typedef unsigned char flex_uint8_t; +typedef unsigned char flex_uint8_t; typedef unsigned short int flex_uint16_t; typedef unsigned int flex_uint32_t; +#endif /* ! C99 */ /* Limits of integral types. */ #ifndef INT8_MIN @@ -84,8 +85,6 @@ typedef unsigned int flex_uint32_t; #define UINT32_MAX (4294967295U) #endif -#endif /* ! C99 */ - #endif /* ! FLEXINT_H */ #ifdef __cplusplus @@ -159,15 +158,7 @@ typedef void* yyscan_t; /* Size of default input buffer. */ #ifndef YY_BUF_SIZE -#ifdef __ia64__ -/* On IA-64, the buffer size is 16k, not 8k. - * Moreover, YY_BUF_SIZE is 2*YY_READ_BUF_SIZE in the general case. - * Ditto for the __ia64__ case accordingly. - */ -#define YY_BUF_SIZE 32768 -#else #define YY_BUF_SIZE 16384 -#endif /* __ia64__ */ #endif /* The state buf must be large enough to hold one state per character in the main buffer. @@ -185,7 +176,7 @@ typedef struct yy_buffer_state *YY_BUFFER_STATE; /* Note: We specifically omit the test for yy_rule_can_match_eol because it requires * access to the local variable yy_act. Since yyless() is a macro, it would break - * existing scanners that call yyless() from OUTSIDE xlu__cfg_yylex. + * existing scanners that call yyless() from OUTSIDE xlu__cfg_yylex. * One obvious solution it to make yy_act a global. I tried that, and saw * a 5% performance hit in a non-yylineno scanner, because yy_act is * normally declared as a register variable-- so it is not worth it. @@ -197,7 +188,7 @@ typedef struct yy_buffer_state *YY_BUFFER_STATE; if ( yytext[yyl] == '\n' )\ --yylineno;\ }while(0) - + /* Return all but the first "n" matched characters back to the input stream. */ #define yyless(n) \ do \ @@ -259,7 +250,7 @@ struct yy_buffer_state int yy_bs_lineno; /**< The line count. */ int yy_bs_column; /**< The column count. */ - + /* Whether to try to fill the input buffer when we reach the * end of it. */ @@ -514,7 +505,7 @@ int xlu__cfg_yyget_column(yyscan_t yyscanner); void xlu__cfg_yyset_column(int column_no, yyscan_t yyscanner); -#line 518 "libxlu_cfg_l.c" +#line 509 "libxlu_cfg_l.c" #define INITIAL 0 #define lexerr 1 @@ -574,9 +565,9 @@ static int yy_init_globals (yyscan_t yyscanner ); /* This must go here because YYSTYPE and YYLTYPE are included * from bison output in section 1.*/ # define yylval yyg->yylval_r - + # define yylloc yyg->yylloc_r - + int xlu__cfg_yylex_init (yyscan_t* scanner); int xlu__cfg_yylex_init_extra (YY_EXTRA_TYPE user_defined,yyscan_t* scanner); @@ -610,14 +601,18 @@ int xlu__cfg_yyget_lineno (yyscan_t yyscanner ); void xlu__cfg_yyset_lineno (int line_number ,yyscan_t yyscanner ); +int xlu__cfg_yyget_column (yyscan_t yyscanner ); + +void xlu__cfg_yyset_column (int column_no ,yyscan_t yyscanner ); + YYSTYPE * xlu__cfg_yyget_lval (yyscan_t yyscanner ); void xlu__cfg_yyset_lval (YYSTYPE * yylval_param ,yyscan_t yyscanner ); YYLTYPE *xlu__cfg_yyget_lloc (yyscan_t yyscanner ); - + void xlu__cfg_yyset_lloc (YYLTYPE * yylloc_param ,yyscan_t yyscanner ); - + /* Macros after this point can all be overridden by user definitions in * section 1. */ @@ -650,12 +645,7 @@ static int input (yyscan_t yyscanner ); /* Amount of stuff to slurp up with each read. */ #ifndef YY_READ_BUF_SIZE -#ifdef __ia64__ -/* On IA-64, the buffer size is 16k, not 8k */ -#define YY_READ_BUF_SIZE 16384 -#else #define YY_READ_BUF_SIZE 8192 -#endif /* __ia64__ */ #endif /* Copy whatever the last rule matched to the standard output. */ @@ -674,7 +664,7 @@ static int input (yyscan_t yyscanner ); if ( YY_CURRENT_BUFFER_LVALUE->yy_is_interactive ) \ { \ int c = '*'; \ - size_t n; \ + unsigned n; \ for ( n = 0; n < max_size && \ (c = getc( yyin )) != EOF && c != '\n'; ++n ) \ buf[n] = (char) c; \ @@ -762,7 +752,7 @@ YY_DECL #line 53 "libxlu_cfg_l.l" -#line 766 "libxlu_cfg_l.c" +#line 756 "libxlu_cfg_l.c" yylval = yylval_param; @@ -845,7 +835,7 @@ yy_find_action: int yyl; for ( yyl = yyg->yy_more_len; yyl < yyleng; ++yyl ) if ( yytext[yyl] == '\n' ) - + do{ yylineno++; yycolumn=0; }while(0) @@ -971,7 +961,7 @@ YY_RULE_SETUP #line 104 "libxlu_cfg_l.l" YY_FATAL_ERROR( "flex scanner jammed" ); YY_BREAK -#line 975 "libxlu_cfg_l.c" +#line 965 "libxlu_cfg_l.c" case YY_STATE_EOF(INITIAL): case YY_STATE_EOF(lexerr): yyterminate(); @@ -1377,7 +1367,7 @@ static int yy_get_next_buffer (yyscan_t yyscanner) yyg->yy_hold_char = *++yyg->yy_c_buf_p; if ( c == '\n' ) - + do{ yylineno++; yycolumn=0; }while(0) @@ -1460,7 +1450,7 @@ static void xlu__cfg_yy_load_buffer_state (yyscan_t yyscanner) YY_BUFFER_STATE xlu__cfg_yy_create_buffer (FILE * file, int size , yyscan_t yyscanner) { YY_BUFFER_STATE b; - + b = (YY_BUFFER_STATE) xlu__cfg_yyalloc(sizeof( struct yy_buffer_state ) ,yyscanner ); if ( ! b ) YY_FATAL_ERROR( "out of dynamic memory in xlu__cfg_yy_create_buffer()" ); @@ -1504,7 +1494,7 @@ static void xlu__cfg_yy_load_buffer_state (yyscan_t yyscanner) #ifndef __cplusplus extern int isatty (int ); #endif /* __cplusplus */ - + /* Initializes or reinitializes a buffer. * This function is sometimes called more than once on the same buffer, * such as during a xlu__cfg_yyrestart() or at EOF. @@ -1530,7 +1520,7 @@ extern int isatty (int ); } b->yy_is_interactive = file ? (isatty( fileno(file) ) > 0) : 0; - + errno = oerrno; } @@ -1636,9 +1626,9 @@ static void xlu__cfg_yyensure_buffer_stack (yyscan_t yyscanner) , yyscanner); if ( ! yyg->yy_buffer_stack ) YY_FATAL_ERROR( "out of dynamic memory in xlu__cfg_yyensure_buffer_stack()" ); - + memset(yyg->yy_buffer_stack, 0, num_to_alloc * sizeof(struct yy_buffer_state*)); - + yyg->yy_buffer_stack_max = num_to_alloc; yyg->yy_buffer_stack_top = 0; return; @@ -1667,12 +1657,12 @@ static void xlu__cfg_yyensure_buffer_stack (yyscan_t yyscanner) * @param base the character buffer * @param size the size in bytes of the character buffer * @param yyscanner The scanner object. - * @return the newly allocated buffer state object. + * @return the newly allocated buffer state object. */ YY_BUFFER_STATE xlu__cfg_yy_scan_buffer (char * base, yy_size_t size , yyscan_t yyscanner) { YY_BUFFER_STATE b; - + if ( size < 2 || base[size-2] != YY_END_OF_BUFFER_CHAR || base[size-1] != YY_END_OF_BUFFER_CHAR ) @@ -1708,14 +1698,14 @@ YY_BUFFER_STATE xlu__cfg_yy_scan_buffer (char * base, yy_size_t size , yyscan_ */ YY_BUFFER_STATE xlu__cfg_yy_scan_string (yyconst char * yystr , yyscan_t yyscanner) { - + return xlu__cfg_yy_scan_bytes(yystr,strlen(yystr) ,yyscanner); } /** Setup the input buffer state to scan the given bytes. The next call to xlu__cfg_yylex() will * scan from a @e copy of @a bytes. - * @param yybytes the byte buffer to scan - * @param _yybytes_len the number of bytes in the buffer pointed to by @a bytes. + * @param bytes the byte buffer to scan + * @param len the number of bytes in the buffer pointed to by @a bytes. * @param yyscanner The scanner object. * @return the newly allocated buffer state object. */ @@ -1725,7 +1715,7 @@ YY_BUFFER_STATE xlu__cfg_yy_scan_bytes (yyconst char * yybytes, int _yybytes_l char *buf; yy_size_t n; int i; - + /* Get memory for full buffer, including space for trailing EOB's. */ n = _yybytes_len + 2; buf = (char *) xlu__cfg_yyalloc(n ,yyscanner ); @@ -1793,10 +1783,10 @@ YY_EXTRA_TYPE xlu__cfg_yyget_extra (yyscan_t yyscanner) int xlu__cfg_yyget_lineno (yyscan_t yyscanner) { struct yyguts_t * yyg = (struct yyguts_t*)yyscanner; - + if (! YY_CURRENT_BUFFER) return 0; - + return yylineno; } @@ -1806,10 +1796,10 @@ int xlu__cfg_yyget_lineno (yyscan_t yyscanner) int xlu__cfg_yyget_column (yyscan_t yyscanner) { struct yyguts_t * yyg = (struct yyguts_t*)yyscanner; - + if (! YY_CURRENT_BUFFER) return 0; - + return yycolumn; } @@ -1870,8 +1860,8 @@ void xlu__cfg_yyset_lineno (int line_number , yyscan_t yyscanner) /* lineno is only valid if an input buffer exists. */ if (! YY_CURRENT_BUFFER ) - yy_fatal_error( "xlu__cfg_yyset_lineno called with no buffer" , yyscanner); - + yy_fatal_error( "xlu__cfg_yyset_lineno called with no buffer" , yyscanner); + yylineno = line_number; } @@ -1885,8 +1875,8 @@ void xlu__cfg_yyset_column (int column_no , yyscan_t yyscanner) /* column is only valid if an input buffer exists. */ if (! YY_CURRENT_BUFFER ) - yy_fatal_error( "xlu__cfg_yyset_column called with no buffer" , yyscanner); - + yy_fatal_error( "xlu__cfg_yyset_column called with no buffer" , yyscanner); + yycolumn = column_no; } @@ -1939,13 +1929,13 @@ YYLTYPE *xlu__cfg_yyget_lloc (yyscan_t yyscanner) struct yyguts_t * yyg = (struct yyguts_t*)yyscanner; return yylloc; } - + void xlu__cfg_yyset_lloc (YYLTYPE * yylloc_param , yyscan_t yyscanner) { struct yyguts_t * yyg = (struct yyguts_t*)yyscanner; yylloc = yylloc_param; } - + /* User-visible API */ /* xlu__cfg_yylex_init is special because it creates the scanner itself, so it is @@ -1993,20 +1983,20 @@ int xlu__cfg_yylex_init_extra(YY_EXTRA_TYPE yy_user_defined,yyscan_t* ptr_yy_glo errno = EINVAL; return 1; } - + *ptr_yy_globals = (yyscan_t) xlu__cfg_yyalloc ( sizeof( struct yyguts_t ), &dummy_yyguts ); - + if (*ptr_yy_globals == NULL){ errno = ENOMEM; return 1; } - + /* By setting to 0xAA, we expose bugs in yy_init_globals. Leave at 0x00 for releases. */ memset(*ptr_yy_globals,0x00,sizeof(struct yyguts_t)); - + xlu__cfg_yyset_extra (yy_user_defined, *ptr_yy_globals); - + return yy_init_globals ( *ptr_yy_globals ); } diff --git a/tools/libxl/libxlu_cfg_l.h b/tools/libxl/libxlu_cfg_l.h index 327c3a4..2066764 100644 --- a/tools/libxl/libxlu_cfg_l.h +++ b/tools/libxl/libxlu_cfg_l.h @@ -38,7 +38,7 @@ #if defined (__STDC_VERSION__) && __STDC_VERSION__ >= 199901L /* C99 says to define __STDC_LIMIT_MACROS before including stdint.h, - * if you want the limit (max/min) macros for int types. + * if you want the limit (max/min) macros for int types. */ #ifndef __STDC_LIMIT_MACROS #define __STDC_LIMIT_MACROS 1 @@ -55,9 +55,10 @@ typedef uint32_t flex_uint32_t; typedef signed char flex_int8_t; typedef short int flex_int16_t; typedef int flex_int32_t; -typedef unsigned char flex_uint8_t; +typedef unsigned char flex_uint8_t; typedef unsigned short int flex_uint16_t; typedef unsigned int flex_uint32_t; +#endif /* ! C99 */ /* Limits of integral types. */ #ifndef INT8_MIN @@ -88,8 +89,6 @@ typedef unsigned int flex_uint32_t; #define UINT32_MAX (4294967295U) #endif -#endif /* ! C99 */ - #endif /* ! FLEXINT_H */ #ifdef __cplusplus @@ -132,15 +131,7 @@ typedef void* yyscan_t; /* Size of default input buffer. */ #ifndef YY_BUF_SIZE -#ifdef __ia64__ -/* On IA-64, the buffer size is 16k, not 8k. - * Moreover, YY_BUF_SIZE is 2*YY_READ_BUF_SIZE in the general case. - * Ditto for the __ia64__ case accordingly. - */ -#define YY_BUF_SIZE 32768 -#else #define YY_BUF_SIZE 16384 -#endif /* __ia64__ */ #endif #ifndef YY_TYPEDEF_YY_BUFFER_STATE @@ -193,7 +184,7 @@ struct yy_buffer_state int yy_bs_lineno; /**< The line count. */ int yy_bs_column; /**< The column count. */ - + /* Whether to try to fill the input buffer when we reach the * end of it. */ @@ -276,14 +267,18 @@ int xlu__cfg_yyget_lineno (yyscan_t yyscanner ); void xlu__cfg_yyset_lineno (int line_number ,yyscan_t yyscanner ); +int xlu__cfg_yyget_column (yyscan_t yyscanner ); + +void xlu__cfg_yyset_column (int column_no ,yyscan_t yyscanner ); + YYSTYPE * xlu__cfg_yyget_lval (yyscan_t yyscanner ); void xlu__cfg_yyset_lval (YYSTYPE * yylval_param ,yyscan_t yyscanner ); YYLTYPE *xlu__cfg_yyget_lloc (yyscan_t yyscanner ); - + void xlu__cfg_yyset_lloc (YYLTYPE * yylloc_param ,yyscan_t yyscanner ); - + /* Macros after this point can all be overridden by user definitions in * section 1. */ @@ -310,12 +305,7 @@ static int yy_flex_strlen (yyconst char * ,yyscan_t yyscanner); /* Amount of stuff to slurp up with each read. */ #ifndef YY_READ_BUF_SIZE -#ifdef __ia64__ -/* On IA-64, the buffer size is 16k, not 8k */ -#define YY_READ_BUF_SIZE 16384 -#else #define YY_READ_BUF_SIZE 8192 -#endif /* __ia64__ */ #endif /* Number of entries by which start-condition stack grows. */ @@ -352,6 +342,6 @@ extern int xlu__cfg_yylex \ #line 104 "libxlu_cfg_l.l" -#line 356 "libxlu_cfg_l.h" +#line 346 "libxlu_cfg_l.h" #undef xlu__cfg_yyIN_HEADER #endif /* xlu__cfg_yyHEADER_H */ -- 1.7.6.2 _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel From xen-devel-bounces@lists.xensource.com Thu Sep 22 15:35:52 2011 Return-path: <xen-devel-bounces@lists.xensource.com> Envelope-to: www-data@lists.xensource.com Delivery-date: Thu, 22 Sep 2011 15:35:52 -0700 Received: from localhost ([127.0.0.1] helo=lists.colo.xensource.com) by lists.xensource.com with esmtp (Exim 4.43) id 1R6rs0-0004Xz-0A; Thu, 22 Sep 2011 15:35:52 -0700 Received: from mail27.messagelabs.com ([193.109.254.147]) by lists.xensource.com with esmtp (Exim 4.43) id 1R6rrA-0004FK-HO for xen-devel@lists.xensource.com; Thu, 22 Sep 2011 15:35:01 -0700 X-Env-Sender: dan.magenheimer@oracle.com X-Msg-Ref: server-7.tower-27.messagelabs.com!1316730873!49783147!1 X-Originating-IP: [141.146.126.227] X-StarScan-Version: 6.4.1; banners=-,-,- X-VirusChecked: Checked Received: (qmail 20008 invoked from network); 22 Sep 2011 22:34:34 -0000 Received: from acsinet15.oracle.com (HELO acsinet15.oracle.com) (141.146.126.227) by server-7.tower-27.messagelabs.com with DHE-RSA-AES256-SHA encrypted SMTP; 22 Sep 2011 22:34:34 -0000 Received: from rtcsinet21.oracle.com (rtcsinet21.oracle.com [66.248.204.29]) by acsinet15.oracle.com (Switch-3.4.4/Switch-3.4.4) with ESMTP id p8MMYpOW006342 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Thu, 22 Sep 2011 22:34:53 GMT Received: from acsmt357.oracle.com (acsmt357.oracle.com [141.146.40.157]) by rtcsinet21.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id p8MMYntl003999 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 22 Sep 2011 22:34:50 GMT Received: from abhmt110.oracle.com (abhmt110.oracle.com [141.146.116.62]) by acsmt357.oracle.com (8.12.11.20060308/8.12.11) with ESMTP id p8MMYgWd025694; Thu, 22 Sep 2011 17:34:42 -0500 MIME-Version: 1.0 Message-ID: <8af71cad-415d-42d4-8a2e-e4efd7e36fd4@default> Date: Thu, 22 Sep 2011 15:34:18 -0700 (PDT) From: Dan Magenheimer <dan.magenheimer@oracle.com> To: Dan Magenheimer <dan.magenheimer@oracle.com>, David Vrabel <david.vrabel@citrix.com> Subject: RE: [Xen-devel] xen: memory initialization/balloon fixes (#3) References: <1316089768-22461-1-git-send-email-david.vrabel@citrix.com> <63997331-e53b-48e5-bf7c-87141aae49d6@default 4E7B2ADA.7000605@citrix.com df22e0b8-15d8-4cb1-a9d9-d3565aa5f9b7@default> In-Reply-To: <df22e0b8-15d8-4cb1-a9d9-d3565aa5f9b7@default> X-Priority: 3 X-Mailer: Oracle Beehive Extensions for Outlook 2.0.1.4.1.0 (410211) [OL 12.0.6557.5001] Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable X-Source-IP: rtcsinet21.oracle.com [66.248.204.29] X-CT-RefId: str=0001.0A020201.4E7BB80D.00C5,ss=1,re=0.000,fgs=0 Cc: jeremy@goop.org, xen-devel@lists.xensource.com, JBeulich@novell.com, Konrad Wilk <konrad.wilk@oracle.com> X-BeenThere: xen-devel@lists.xensource.com X-Mailman-Version: 2.1.5 Precedence: list List-Id: Xen developer discussion <xen-devel.lists.xensource.com> List-Unsubscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe> List-Post: <mailto:xen-devel@lists.xensource.com> List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help> List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=subscribe> Sender: xen-devel-bounces@lists.xensource.com Errors-To: xen-devel-bounces@lists.xensource.com > From: Dan Magenheimer > Subject: RE: [Xen-devel] xen: memory initialization/balloon fixes (#3) >=20 > > From: David Vrabel [mailto:david.vrabel@citrix.com] > > Subject: Re: [Xen-devel] xen: memory initialization/balloon fixes (#3) > > > > On 20/09/11 17:57, Dan Magenheimer wrote: > > > > > > > > > My problem occurs in a PV domU with an upstream-variant kernel based > > > on 3.0.5. The problem is that the total amount of memory as seen > > > from inside the guest is always substantially less than the amount > > > of memory seen from outside the guest. The difference seems to > > > be fixed within a given boot, but assigning a different vm.cfg mem=3D > > > changes the amount. (For example, the difference D is about 18MB on > > > a mem=3D128 boot and about 36MB on a mem=3D1024 boot.) > > > > I don't see the problem? >=20 > Hi David -- >=20 > Sorry, just to clarify, are you saying you are seeing the same > behavior and don't consider it a problem, or that you are not > seeing the same difference? > > > The MemTotal value /proc/meminfo doesn't include some pages reserved by > > the kernel which is why it's less than the maximum reservation of the > > domain. >=20 > I'm aware of that... "some" has been a fixed size of a few megabytes > in Xen for a long time. I am seeing 30-60MB or more. Never mind on this part. After further debugging, I can see that this difference is due to normal uses of memory by the kernel for XEN PAGETABLES and RAMDISK etc. It's unfortunate that the difference is so large, but I guess that's in part due to the desire to use the same kernel binary for native and virtualized. I don't remember it being nearly so high for older PV kernels, but I guess it's progress! :-} > > > Part B of the problem (and the one most important to me) is that > > > setting /sys/devices/system/xen_memory/xen_memory0/target_kb > > > to X results in a MemTotal inside the domU (as observed by > > > "head -1 /proc/meminfo") of X-D. This can be particularly painful > > > when X is aggressively small as X-D may result in OOMs. > > > To use kernel function/variable names (and I observed this with > > > some debugging code), when balloon_set_new_target(X) is called > > > totalram_pages gets driven to X-D. > > > > Again, this looks like the correct behavior to me. >=20 > Hmmm... so if a user (or automated tool) uses the Xen-defined > API (i.e. /sys/devices/system/xen_memory/xen_memory0/target_kb) > to use the Xen balloon driver to attempt to reduce memory usage > to 100MB, and the Xen balloon driver instead reduces it to > some random number somewhere between 40MB and 90MB, which > may or may not cause OOMs, you consider this correct behavior? I still think this is a bug but apparently orthogonal to your patchset. So sorry to bother you. Dan _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel From xen-devel-bounces@lists.xensource.com Thu Sep 22 15:52:31 2011 Return-path: <xen-devel-bounces@lists.xensource.com> Envelope-to: www-data@lists.xensource.com Delivery-date: Thu, 22 Sep 2011 15:52:31 -0700 Received: from localhost ([127.0.0.1] helo=lists.colo.xensource.com) by lists.xensource.com with esmtp (Exim 4.43) id 1R6s87-000592-IJ; Thu, 22 Sep 2011 15:52:31 -0700 Received: from mail174.messagelabs.com ([85.158.138.51]) by lists.xensource.com with esmtp (Exim 4.43) id 1R6s7S-0004wo-V4 for xen-devel@lists.xensource.com; Thu, 22 Sep 2011 15:51:51 -0700 X-Env-Sender: jeremy@goop.org X-Msg-Ref: server-4.tower-174.messagelabs.com!1316731906!32444084!1 X-Originating-IP: [74.207.240.146] X-StarScan-Version: 6.4.1; banners=-,-,- X-VirusChecked: Checked Received: (qmail 30623 invoked from network); 22 Sep 2011 22:51:47 -0000 Received: from claw.goop.org (HELO claw.goop.org) (74.207.240.146) by server-4.tower-174.messagelabs.com with DHE-RSA-AES256-SHA encrypted SMTP; 22 Sep 2011 22:51:47 -0000 Received: from saboo.goop.org (unknown [IPv6:2001:470:1f05:899:186e:d2ff:fef6:9488]) (Authenticated sender: smtp-saboo) by claw.goop.org (Postfix) with ESMTPSA id A5935A4C2; Thu, 22 Sep 2011 15:51:45 -0700 (PDT) Received: from saboo.goop.org (localhost [IPv6:::1]) by saboo.goop.org (Postfix) with ESMTP id 625CE20381; Thu, 22 Sep 2011 15:51:44 -0700 (PDT) Message-ID: <4E7BBC00.1050602@goop.org> Date: Thu, 22 Sep 2011 15:51:44 -0700 From: Jeremy Fitzhardinge <jeremy@goop.org> User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:6.0.2) Gecko/20110906 Thunderbird/6.0.2 MIME-Version: 1.0 To: Dan Magenheimer <dan.magenheimer@oracle.com> Subject: Re: [Xen-devel] xen: memory initialization/balloon fixes (#3) References: <1316089768-22461-1-git-send-email-david.vrabel@citrix.com> <63997331-e53b-48e5-bf7c-87141aae49d6@default 4E7B2ADA.7000605@citrix.com df22e0b8-15d8-4cb1-a9d9-d3565aa5f9b7@default> <8af71cad-415d-42d4-8a2e-e4efd7e36fd4@default> In-Reply-To: <8af71cad-415d-42d4-8a2e-e4efd7e36fd4@default> X-Enigmail-Version: 1.3.2 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: xen-devel@lists.xensource.com, David Vrabel <david.vrabel@citrix.com>, JBeulich@novell.com, Konrad Wilk <konrad.wilk@oracle.com> X-BeenThere: xen-devel@lists.xensource.com X-Mailman-Version: 2.1.5 Precedence: list List-Id: Xen developer discussion <xen-devel.lists.xensource.com> List-Unsubscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe> List-Post: <mailto:xen-devel@lists.xensource.com> List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help> List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=subscribe> Sender: xen-devel-bounces@lists.xensource.com Errors-To: xen-devel-bounces@lists.xensource.com On 09/22/2011 03:34 PM, Dan Magenheimer wrote: >> I'm aware of that... "some" has been a fixed size of a few megabytes >> in Xen for a long time. I am seeing 30-60MB or more. > Never mind on this part. After further debugging, I can see > that this difference is due to normal uses of memory by the > kernel for XEN PAGETABLES and RAMDISK etc. It's unfortunate > that the difference is so large, but I guess that's in part due > to the desire to use the same kernel binary for native and > virtualized. I don't remember it being nearly so high for > older PV kernels, but I guess it's progress! :-} I don't think the Xen parts allocate/reserves lots of memory unnecessarily, so it shouldn't be too different from the 2.6.18-xen kernels. They do reserve various chunks of memory, but for things like RAMDISK I think they get released again (and anyway, I don't think that's going to be anywhere near 30MB, let alone 60). I'm not very confident in those /proc/meminfo numbers - they may count memory as "reserved" if its in a reserved region even if the pages themselves have been released to the kernel pool. >>>> Part B of the problem (and the one most important to me) is that >>>> setting /sys/devices/system/xen_memory/xen_memory0/target_kb >>>> to X results in a MemTotal inside the domU (as observed by >>>> "head -1 /proc/meminfo") of X-D. This can be particularly painful >>>> when X is aggressively small as X-D may result in OOMs. >>>> To use kernel function/variable names (and I observed this with >>>> some debugging code), when balloon_set_new_target(X) is called >>>> totalram_pages gets driven to X-D. >>> Again, this looks like the correct behavior to me. >> Hmmm... so if a user (or automated tool) uses the Xen-defined >> API (i.e. /sys/devices/system/xen_memory/xen_memory0/target_kb) >> to use the Xen balloon driver to attempt to reduce memory usage >> to 100MB, and the Xen balloon driver instead reduces it to >> some random number somewhere between 40MB and 90MB, which >> may or may not cause OOMs, you consider this correct behavior? > I still think this is a bug but apparently orthogonal to > your patchset. So sorry to bother you. If you ask for 100MB, it should never try to make the domain smaller than that; if it does, it suggests the number is being misparsed or something. J _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel From xen-devel-bounces@lists.xensource.com Thu Sep 22 16:08:45 2011 Return-path: <xen-devel-bounces@lists.xensource.com> Envelope-to: www-data@lists.xensource.com Delivery-date: Thu, 22 Sep 2011 16:08:45 -0700 Received: from localhost ([127.0.0.1] helo=lists.colo.xensource.com) by lists.xensource.com with esmtp (Exim 4.43) id 1R6sNp-0006PE-IE; Thu, 22 Sep 2011 16:08:45 -0700 Received: from mail174.messagelabs.com ([85.158.138.51]) by lists.xensource.com with esmtp (Exim 4.43) id 1R6sJf-0005VO-Kw for xen-devel@lists.xensource.com; Thu, 22 Sep 2011 16:04:42 -0700 X-Env-Sender: Ian.Jackson@eu.citrix.com X-Msg-Ref: server-7.tower-174.messagelabs.com!1316732664!32399293!1 X-Originating-IP: [62.200.22.115] X-StarScan-Version: 6.4.1; banners=-,-,- X-VirusChecked: Checked Received: (qmail 7459 invoked from network); 22 Sep 2011 23:04:24 -0000 Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115) by server-7.tower-174.messagelabs.com with RC4-SHA encrypted SMTP; 22 Sep 2011 23:04:24 -0000 X-IronPort-AV: E=Sophos;i="4.68,426,1312156800"; d="scan'208";a="8018927" Received: from lonpmailmx01.citrite.net ([10.30.203.162]) by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5; 22 Sep 2011 23:04:24 +0000 Received: from woking.xci-test.com (10.80.248.135) by smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id 8.3.137.0; Fri, 23 Sep 2011 00:04:24 +0100 Received: from osstest by woking.xci-test.com with local (Exim 4.69) (envelope-from <ian.jackson@eu.citrix.com>) id 1R6sJb-0001by-Vu; Fri, 23 Sep 2011 00:04:24 +0100 To: xen-devel@lists.xensource.com Message-ID: <osstest-9001-mainreport@xen.org> From: xen.org <ian.jackson@eu.citrix.com> Date: Fri, 23 Sep 2011 00:04:23 +0100 MIME-Version: 1.0 Content-Type: text/plain Cc: ian.jackson@eu.citrix.com Subject: [Xen-devel] [linux test] 9001: tolerable FAIL X-BeenThere: xen-devel@lists.xensource.com X-Mailman-Version: 2.1.5 Precedence: list List-Id: Xen developer discussion <xen-devel.lists.xensource.com> List-Unsubscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe> List-Post: <mailto:xen-devel@lists.xensource.com> List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help> List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=subscribe> Sender: xen-devel-bounces@lists.xensource.com Errors-To: xen-devel-bounces@lists.xensource.com flight 9001 linux real [real] http://www.chiark.greenend.org.uk/~xensrcts/logs/9001/ Failures :-/ but no regressions. Tests which did not succeed, but are not blocking, including regressions (tests previously passed) regarded as allowable: test-amd64-amd64-xl-pcipt-intel 9 guest-start fail never pass test-amd64-i386-rhel6hvm-amd 9 guest-start.2 fail never pass test-amd64-i386-rhel6hvm-intel 9 guest-start.2 fail never pass test-amd64-i386-win-vcpus1 16 leak-check/check fail never pass test-amd64-i386-xl-win-vcpus1 13 guest-stop fail never pass test-amd64-amd64-win 16 leak-check/check fail never pass test-amd64-amd64-xl-win 13 guest-stop fail never pass test-i386-i386-xl-win 13 guest-stop fail never pass test-i386-i386-win 16 leak-check/check fail never pass test-amd64-i386-win 16 leak-check/check fail never pass version targeted for testing: linux 6bec8b4a4c14095d0b7ce424db9d583c3decae6c baseline version: linux 1c3f03ccc5258887f5f2cafc0836a865834f9205 ------------------------------------------------------------ People who touched revisions under test: Jeremy Fitzhardinge <jeremy.fitzhardinge@citrix.com> ------------------------------------------------------------ jobs: build-amd64 pass build-i386 pass build-amd64-pvops pass build-i386-pvops pass test-amd64-amd64-xl pass test-amd64-i386-xl pass test-i386-i386-xl pass test-amd64-i386-rhel6hvm-amd fail test-amd64-i386-xl-credit2 pass test-amd64-amd64-xl-pcipt-intel fail test-amd64-i386-rhel6hvm-intel fail test-amd64-i386-xl-multivcpu pass test-amd64-amd64-pair pass test-amd64-i386-pair pass test-i386-i386-pair pass test-amd64-amd64-pv pass test-amd64-i386-pv pass test-i386-i386-pv pass test-amd64-amd64-xl-sedf pass test-amd64-i386-win-vcpus1 fail test-amd64-i386-xl-win-vcpus1 fail test-amd64-amd64-win fail test-amd64-i386-win fail test-i386-i386-win fail test-amd64-amd64-xl-win fail test-i386-i386-xl-win fail ------------------------------------------------------------ sg-report-flight on woking.cam.xci-test.com logs: /home/xc_osstest/logs images: /home/xc_osstest/images Logs, config files, etc. are available at http://www.chiark.greenend.org.uk/~xensrcts/logs Test harness code can be found at http://xenbits.xensource.com/gitweb?p=osstest.git;a=summary Pushing revision : + branch=linux + revision=6bec8b4a4c14095d0b7ce424db9d583c3decae6c + . cri-lock-repos ++ . cri-common +++ umask 002 +++ getconfig Repos +++ perl -e ' use Osstest; readconfigonly(); print $c{Repos} or die $!; ' ++ repos=/export/home/osstest/repos ++ repos_lock=/export/home/osstest/repos/lock ++ '[' x '!=' x/export/home/osstest/repos/lock ']' ++ OSSTEST_REPOS_LOCK_LOCKED=/export/home/osstest/repos/lock ++ exec with-lock-ex -w /export/home/osstest/repos/lock ./ap-push linux 6bec8b4a4c14095d0b7ce424db9d583c3decae6c + branch=linux + revision=6bec8b4a4c14095d0b7ce424db9d583c3decae6c + . cri-lock-repos ++ . cri-common +++ umask 002 +++ getconfig Repos +++ perl -e ' use Osstest; readconfigonly(); print $c{Repos} or die $!; ' ++ repos=/export/home/osstest/repos ++ repos_lock=/export/home/osstest/repos/lock ++ '[' x/export/home/osstest/repos/lock '!=' x/export/home/osstest/repos/lock ']' + : xen@xenbits.xensource.com + : xen@xenbits.xensource.com:git/linux-pvops + : master + : tested/2.6.39.x + case "$branch" in + cd /export/home/osstest/repos/xen ./ap-push: line 20: cd: /export/home/osstest/repos/xen: No such file or directory ------------------------------------------------------------ commit 6bec8b4a4c14095d0b7ce424db9d583c3decae6c Author: Jeremy Fitzhardinge <jeremy.fitzhardinge@citrix.com> Date: Fri Sep 2 12:23:22 2011 -0700 Revert "xen/apic: Provide an 'apic_xen' to set the override the apic->[read|write] for all cases." This reverts commit c3dd7941354fa96a71f2613e2c7a1b215fa175dc. It prevents the kernel from booting natively on hardware. Conflicts: arch/x86/xen/enlighten.c Signed-off-by: Jeremy Fitzhardinge <jeremy.fitzhardinge@citrix.com> _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel From xen-devel-bounces@lists.xensource.com Thu Sep 22 16:32:14 2011 Return-path: <xen-devel-bounces@lists.xensource.com> Envelope-to: www-data@lists.xensource.com Delivery-date: Thu, 22 Sep 2011 16:32:14 -0700 Received: from localhost ([127.0.0.1] helo=lists.colo.xensource.com) by lists.xensource.com with esmtp (Exim 4.43) id 1R6skX-0007JN-T3; Thu, 22 Sep 2011 16:32:13 -0700 Received: from mail27.messagelabs.com ([193.109.254.147]) by lists.xensource.com with esmtp (Exim 4.43) id 1R6sjm-00076a-So for Xen-devel@lists.xensource.com; Thu, 22 Sep 2011 16:31:27 -0700 X-Env-Sender: jeremy@goop.org X-Msg-Ref: server-10.tower-27.messagelabs.com!1316734261!36869968!1 X-Originating-IP: [74.207.240.146] X-StarScan-Version: 6.4.1; banners=-,-,- X-VirusChecked: Checked Received: (qmail 26911 invoked from network); 22 Sep 2011 23:31:03 -0000 Received: from claw.goop.org (HELO claw.goop.org) (74.207.240.146) by server-10.tower-27.messagelabs.com with DHE-RSA-AES256-SHA encrypted SMTP; 22 Sep 2011 23:31:03 -0000 Received: from saboo.goop.org (unknown [IPv6:2001:470:1f05:899:c0d2:d0ff:fee4:4bd]) (Authenticated sender: smtp-saboo) by claw.goop.org (Postfix) with ESMTPSA id 90698A50A; Thu, 22 Sep 2011 16:31:21 -0700 (PDT) Received: from saboo.goop.org (localhost [IPv6:::1]) by saboo.goop.org (Postfix) with ESMTP id 042FA20212; Thu, 22 Sep 2011 16:31:18 -0700 (PDT) Message-ID: <4E7BC546.9030607@goop.org> Date: Thu, 22 Sep 2011 16:31:18 -0700 From: Jeremy Fitzhardinge <jeremy@goop.org> User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:6.0.2) Gecko/20110906 Thunderbird/6.0.2 MIME-Version: 1.0 To: Ian Campbell <Ian.Campbell@citrix.com> Subject: Re: [Xen-devel] arch_set_info_guest() and cr1 References: <20110811190315.1cc6afab@mantra.us.oracle.com> <CA6A83D7.1F1E6%keir.xen@gmail.com> <20110812150115.6047b8c2@mantra.us.oracle.com> <4E45DED5.40602@goop.org> <1316676757.23371.2.camel@zakaz.uk.xensource.com> In-Reply-To: <1316676757.23371.2.camel@zakaz.uk.xensource.com> X-Enigmail-Version: 1.3.2 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Cc: "Xen-devel@lists.xensource.com" <Xen-devel@lists.xensource.com>, Tim Deegan <tim@xen.org>, Keir Fraser <keir.xen@gmail.com> X-BeenThere: xen-devel@lists.xensource.com X-Mailman-Version: 2.1.5 Precedence: list List-Id: Xen developer discussion <xen-devel.lists.xensource.com> List-Unsubscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe> List-Post: <mailto:xen-devel@lists.xensource.com> List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help> List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=subscribe> Sender: xen-devel-bounces@lists.xensource.com Errors-To: xen-devel-bounces@lists.xensource.com On 09/22/2011 12:32 AM, Ian Campbell wrote: > (old mail, I know) > > On Sat, 2011-08-13 at 03:17 +0100, Jeremy Fitzhardinge wrote: >> On 08/12/2011 03:01 PM, Mukesh Rathor wrote: >>> Ah I see it, during save/restore, it is used. >>> Well, I'm trying to keep the option of using PV paging with hybrid, so >>> I may need to honor that. But that's phase 2. >> Though it would be nice to re-enable the use of PV writable pagetables >> to get access to HAP, and we could do without that. >> >> Does Xen require that the user pagetable be a proper subset of the >> kernel pagetable? If we can assume that and get proper ring protections >> in the HVM container, then we can simply ignore the user pagetable (and >> would have to if we want to get good syscall performance). > IIRC back when I did the (now completely defunct) supervisor mode kernel > stuff that was exactly the assumption which was made and it certainly > worked in practice (although "require" might be a strong term). Well, I guess we could add ELF notes to allow a guest to say "I really need separate non-intersecting user/kernel pagetables" if they really need it. Or repurpose auto_translated_physmap to also mean "no separate user/kernel pagetables required". Has that ever been supported for 64-bit PV guests? My memory of the chronology is that it died as a feature at about the time that 64-bit support went in. J _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel From xen-devel-bounces@lists.xensource.com Thu Sep 22 16:47:22 2011 Return-path: <xen-devel-bounces@lists.xensource.com> Envelope-to: www-data@lists.xensource.com Delivery-date: Thu, 22 Sep 2011 16:47:22 -0700 Received: from localhost ([127.0.0.1] helo=lists.colo.xensource.com) by lists.xensource.com with esmtp (Exim 4.43) id 1R6szB-0000EK-TY; Thu, 22 Sep 2011 16:47:21 -0700 Received: from mail216.messagelabs.com ([85.158.143.99]) by lists.xensource.com with esmtp (Exim 4.43) id 1R6syf-0008TE-C8 for xen-devel@lists.xensource.com; Thu, 22 Sep 2011 16:46:50 -0700 X-Env-Sender: dan.magenheimer@oracle.com X-Msg-Ref: server-15.tower-216.messagelabs.com!1316735204!18775063!1 X-Originating-IP: [141.146.126.227] X-StarScan-Version: 6.4.1; banners=-,-,- X-VirusChecked: Checked Received: (qmail 25416 invoked from network); 22 Sep 2011 23:46:45 -0000 Received: from acsinet15.oracle.com (HELO acsinet15.oracle.com) (141.146.126.227) by server-15.tower-216.messagelabs.com with DHE-RSA-AES256-SHA encrypted SMTP; 22 Sep 2011 23:46:45 -0000 Received: from acsinet21.oracle.com (acsinet21.oracle.com [141.146.126.237]) by acsinet15.oracle.com (Switch-3.4.4/Switch-3.4.4) with ESMTP id p8MNkdIq023227 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Thu, 22 Sep 2011 23:46:41 GMT Received: from acsmt357.oracle.com (acsmt357.oracle.com [141.146.40.157]) by acsinet21.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id p8MNkdmZ017038 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 22 Sep 2011 23:46:39 GMT Received: from abhmt110.oracle.com (abhmt110.oracle.com [141.146.116.62]) by acsmt357.oracle.com (8.12.11.20060308/8.12.11) with ESMTP id p8MNkW9d007148; Thu, 22 Sep 2011 18:46:32 -0500 MIME-Version: 1.0 Message-ID: <005ea591-cfb5-4ca0-9c9c-df2bbae88172@default> Date: Thu, 22 Sep 2011 16:46:14 -0700 (PDT) From: Dan Magenheimer <dan.magenheimer@oracle.com> To: Jeremy Fitzhardinge <jeremy@goop.org> Subject: RE: [Xen-devel] xen: memory initialization/balloon fixes (#3) References: <1316089768-22461-1-git-send-email-david.vrabel@citrix.com> <63997331-e53b-48e5-bf7c-87141aae49d6@default> <4E7B2ADA.7000605@citrix.com> <df22e0b8-15d8-4cb1-a9d9-d3565aa5f9b7@default> <8af71cad-415d-42d4-8a2e-e4efd7e36fd4@default 4E7BBC00.1050602@goop.org> In-Reply-To: <4E7BBC00.1050602@goop.org> X-Priority: 3 X-Mailer: Oracle Beehive Extensions for Outlook 2.0.1.4.1.0 (410211) [OL 12.0.6557.5001] Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable X-Source-IP: acsinet21.oracle.com [141.146.126.237] X-Auth-Type: Internal IP X-CT-RefId: str=0001.0A090208.4E7BC8E1.00B2:SCFMA922111,ss=1,re=-4.000,fgs=0 Cc: xen-devel@lists.xensource.com, David Vrabel <david.vrabel@citrix.com>, JBeulich@novell.com, Konrad Wilk <konrad.wilk@oracle.com> X-BeenThere: xen-devel@lists.xensource.com X-Mailman-Version: 2.1.5 Precedence: list List-Id: Xen developer discussion <xen-devel.lists.xensource.com> List-Unsubscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe> List-Post: <mailto:xen-devel@lists.xensource.com> List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help> List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=subscribe> Sender: xen-devel-bounces@lists.xensource.com Errors-To: xen-devel-bounces@lists.xensource.com > From: Jeremy Fitzhardinge [mailto:jeremy@goop.org] >=20 > On 09/22/2011 03:34 PM, Dan Magenheimer wrote: > >> I'm aware of that... "some" has been a fixed size of a few megabytes > >> in Xen for a long time. I am seeing 30-60MB or more. > > Never mind on this part. After further debugging, I can see > > that this difference is due to normal uses of memory by the > > kernel for XEN PAGETABLES and RAMDISK etc. It's unfortunate > > that the difference is so large, but I guess that's in part due > > to the desire to use the same kernel binary for native and > > virtualized. I don't remember it being nearly so high for > > older PV kernels, but I guess it's progress! :-} >=20 > I don't think the Xen parts allocate/reserves lots of memory > unnecessarily, so it shouldn't be too different from the 2.6.18-xen > kernels. They do reserve various chunks of memory, but for things like > RAMDISK I think they get released again (and anyway, I don't think > that's going to be anywhere near 30MB, let alone 60). I'm not very > confident in those /proc/meminfo numbers - they may count memory as > "reserved" if its in a reserved region even if the pages themselves have > been released to the kernel pool. No, the first line of /proc/meminfo is precisely "totalram_pages". =20 > >>>> Part B of the problem (and the one most important to me) is that > >>>> setting /sys/devices/system/xen_memory/xen_memory0/target_kb > >>>> to X results in a MemTotal inside the domU (as observed by > >>>> "head -1 /proc/meminfo") of X-D. This can be particularly painful > >>>> when X is aggressively small as X-D may result in OOMs. > >>>> To use kernel function/variable names (and I observed this with > >>>> some debugging code), when balloon_set_new_target(X) is called > >>>> totalram_pages gets driven to X-D. > >>> Again, this looks like the correct behavior to me. > >> Hmmm... so if a user (or automated tool) uses the Xen-defined > >> API (i.e. /sys/devices/system/xen_memory/xen_memory0/target_kb) > >> to use the Xen balloon driver to attempt to reduce memory usage > >> to 100MB, and the Xen balloon driver instead reduces it to > >> some random number somewhere between 40MB and 90MB, which > >> may or may not cause OOMs, you consider this correct behavior? > > I still think this is a bug but apparently orthogonal to > > your patchset. So sorry to bother you. >=20 > If you ask for 100MB, it should never try to make the domain smaller > than that; if it does, it suggests the number is being misparsed or > something. OK then balloon_stats.current_pages can never be larger than totalram_pages= . Which means that balloon_stats.current_pages must always grow and shrink when totalram_pages does (which is true now only in the balloon driver code). Which means, I think: balloon_stats.current_pages is just plain wrong! It doesn't need to exist! If we replace every instance in balloon.c with totalram_pages, I think everything just works. Will run some tests tomorrow. Dan P.S. Not sure about Daniel's hotplug stuff though.... _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel From xen-devel-bounces@lists.xensource.com Thu Sep 22 19:02:46 2011 Return-path: <xen-devel-bounces@lists.xensource.com> Envelope-to: www-data@lists.xensource.com Delivery-date: Thu, 22 Sep 2011 19:02:46 -0700 Received: from localhost ([127.0.0.1] helo=lists.colo.xensource.com) by lists.xensource.com with esmtp (Exim 4.43) id 1R6v6E-0003tE-8x; Thu, 22 Sep 2011 19:02:46 -0700 Received: from mail174.messagelabs.com ([85.158.138.51]) by lists.xensource.com with esmtp (Exim 4.43) id 1R6v5P-0003gy-Ss for Xen-devel@lists.xensource.com; Thu, 22 Sep 2011 19:01:56 -0700 X-Env-Sender: mukesh.rathor@oracle.com X-Msg-Ref: server-8.tower-174.messagelabs.com!1316743311!18745904!1 X-Originating-IP: [141.146.126.227] X-StarScan-Version: 6.4.1; banners=-,-,- X-VirusChecked: Checked Received: (qmail 29247 invoked from network); 23 Sep 2011 02:01:52 -0000 Received: from acsinet15.oracle.com (HELO acsinet15.oracle.com) (141.146.126.227) by server-8.tower-174.messagelabs.com with DHE-RSA-AES256-SHA encrypted SMTP; 23 Sep 2011 02:01:52 -0000 Received: from rtcsinet21.oracle.com (rtcsinet21.oracle.com [66.248.204.29]) by acsinet15.oracle.com (Switch-3.4.4/Switch-3.4.4) with ESMTP id p8N21iuN031903 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Fri, 23 Sep 2011 02:01:47 GMT Received: from acsmt358.oracle.com (acsmt358.oracle.com [141.146.40.158]) by rtcsinet21.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id p8N21hhT029006 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 23 Sep 2011 02:01:44 GMT Received: from abhmt118.oracle.com (abhmt118.oracle.com [141.146.116.70]) by acsmt358.oracle.com (8.12.11.20060308/8.12.11) with ESMTP id p8N21cQa029037; Thu, 22 Sep 2011 21:01:38 -0500 Received: from mantra.us.oracle.com (/130.35.68.95) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Thu, 22 Sep 2011 19:01:36 -0700 Date: Thu, 22 Sep 2011 19:01:35 -0700 From: Mukesh Rathor <mukesh.rathor@oracle.com> To: Mukesh Rathor <mukesh.rathor@oracle.com> Subject: Re: [Xen-devel] parse_config_data()... Message-ID: <20110922190135.44aedd25@mantra.us.oracle.com> In-Reply-To: <20110922113048.2d02f126@mantra.us.oracle.com> References: <20110922113048.2d02f126@mantra.us.oracle.com> Organization: Oracle Corporation X-Mailer: Claws Mail 3.7.6 (GTK+ 2.18.9; x86_64-redhat-linux-gnu) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-Source-IP: rtcsinet21.oracle.com [66.248.204.29] X-CT-RefId: str=0001.0A090208.4E7BE88B.00CB,ss=1,re=0.000,fgs=0 Cc: "Xen-devel@lists.xensource.com" <Xen-devel@lists.xensource.com>, stefano.stabellini@eu.citrix.com X-BeenThere: xen-devel@lists.xensource.com X-Mailman-Version: 2.1.5 Precedence: list List-Id: Xen developer discussion <xen-devel.lists.xensource.com> List-Unsubscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe> List-Post: <mailto:xen-devel@lists.xensource.com> List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help> List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=subscribe> Sender: xen-devel-bounces@lists.xensource.com Errors-To: xen-devel-bounces@lists.xensource.com On Thu, 22 Sep 2011 11:30:48 -0700 Mukesh Rathor <mukesh.rathor@oracle.com> wrote: > Hi Stefano, > > In parse_config_data(): > > init_create_info(c_info); <--- sets hvm and hap to 1, then:. > > c_info->hvm = 0; > if (!xlu_cfg_get_string (config, "builder", &buf) && > !strncmp(buf, "hvm", strlen(buf))) > c_info->hvm = 1; > > if (!xlu_cfg_get_long (config, "hap", &l)) <-------- already 1 > c_info->hap = l; <--- letter 'el' > > > no big deal, but just confusing for someone reading the code... > > thanks, > Mukesh > > > > > _______________________________________________ > Xen-devel mailing list > Xen-devel@lists.xensource.com > http://lists.xensource.com/xen-devel Never mind, my bad... thanks, Mukesh _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel From xen-devel-bounces@lists.xensource.com Thu Sep 22 20:59:46 2011 Return-path: <xen-devel-bounces@lists.xensource.com> Envelope-to: www-data@lists.xensource.com Delivery-date: Thu, 22 Sep 2011 20:59:46 -0700 Received: from localhost ([127.0.0.1] helo=lists.colo.xensource.com) by lists.xensource.com with esmtp (Exim 4.43) id 1R6wvR-0007KD-Jj; Thu, 22 Sep 2011 20:59:45 -0700 Received: from mail27.messagelabs.com ([193.109.254.147]) by lists.xensource.com with esmtp (Exim 4.43) id 1R6wsr-0006gp-BT for xen-devel@lists.xensource.com; Thu, 22 Sep 2011 20:57:07 -0700 X-Env-Sender: Ian.Jackson@eu.citrix.com X-Msg-Ref: server-2.tower-27.messagelabs.com!1316750197!56095545!1 X-Originating-IP: [62.200.22.115] X-StarScan-Version: 6.4.1; banners=-,-,- X-VirusChecked: Checked Received: (qmail 21384 invoked from network); 23 Sep 2011 03:56:37 -0000 Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115) by server-2.tower-27.messagelabs.com with RC4-SHA encrypted SMTP; 23 Sep 2011 03:56:37 -0000 X-IronPort-AV: E=Sophos;i="4.68,427,1312156800"; d="scan'208";a="8019859" Received: from lonpmailmx01.citrite.net ([10.30.203.162]) by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5; 23 Sep 2011 03:57:02 +0000 Received: from woking.xci-test.com (10.80.248.135) by smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id 8.3.137.0; Fri, 23 Sep 2011 04:57:02 +0100 Received: from osstest by woking.xci-test.com with local (Exim 4.69) (envelope-from <ian.jackson@eu.citrix.com>) id 1R6wsn-0004hO-SM; Fri, 23 Sep 2011 04:57:01 +0100 To: xen-devel@lists.xensource.com Message-ID: <osstest-9005-mainreport@xen.org> From: xen.org <ian.jackson@eu.citrix.com> Date: Fri, 23 Sep 2011 04:57:01 +0100 MIME-Version: 1.0 Content-Type: text/plain Cc: ian.jackson@eu.citrix.com Subject: [Xen-devel] [xen-unstable test] 9005: regressions - FAIL X-BeenThere: xen-devel@lists.xensource.com X-Mailman-Version: 2.1.5 Precedence: list List-Id: Xen developer discussion <xen-devel.lists.xensource.com> List-Unsubscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe> List-Post: <mailto:xen-devel@lists.xensource.com> List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help> List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=subscribe> Sender: xen-devel-bounces@lists.xensource.com Errors-To: xen-devel-bounces@lists.xensource.com flight 9005 xen-unstable real [real] http://www.chiark.greenend.org.uk/~xensrcts/logs/9005/ Regressions :-( Tests which did not succeed and are blocking: test-amd64-i386-rhel6hvm-amd 5 xen-boot fail REGR. vs. 8995 test-i386-i386-pv 5 xen-boot fail REGR. vs. 8995 test-amd64-amd64-xl-win 5 xen-boot fail REGR. vs. 8995 Tests which are failing intermittently (not blocking): test-amd64-amd64-xl 5 xen-boot fail pass in 9000 test-amd64-i386-pv 5 xen-boot fail pass in 9000 test-amd64-i386-xl-credit2 5 xen-boot fail pass in 9000 test-amd64-i386-pair 8 xen-boot/dst_host fail pass in 9000 test-amd64-i386-pair 7 xen-boot/src_host fail pass in 9000 test-amd64-amd64-pair 8 xen-boot/dst_host fail pass in 9000 test-amd64-amd64-pair 7 xen-boot/src_host fail pass in 9000 test-amd64-amd64-pv 5 xen-boot fail in 9000 pass in 9005 test-amd64-i386-xl-multivcpu 5 xen-boot fail in 9000 pass in 9005 test-amd64-i386-xl-win-vcpus1 5 xen-boot fail in 9000 pass in 9005 test-i386-i386-win 5 xen-boot fail in 9000 pass in 9005 test-i386-i386-pair 8 xen-boot/dst_host fail in 9000 pass in 9005 test-i386-i386-pair 7 xen-boot/src_host fail in 9000 pass in 9005 test-amd64-i386-win-vcpus1 5 xen-boot fail in 9000 pass in 9005 Tests which did not succeed, but are not blocking, including regressions (tests previously passed) regarded as allowable: test-amd64-amd64-xl-pcipt-intel 9 guest-start fail never pass test-amd64-i386-rhel6hvm-intel 9 guest-start.2 fail never pass test-amd64-i386-xl-win-vcpus1 13 guest-stop fail never pass test-i386-i386-win 16 leak-check/check fail never pass test-i386-i386-xl-win 13 guest-stop fail never pass test-amd64-amd64-win 16 leak-check/check fail never pass test-amd64-i386-win-vcpus1 16 leak-check/check fail never pass test-amd64-i386-win 16 leak-check/check fail never pass version targeted for testing: xen cc339ab1d917 baseline version: xen a422e2a4451e ------------------------------------------------------------ People who touched revisions under test: Andreas Herrmann <herrmann.der.user@googlemail.com> Ian Campbell <ian.campbell@citrix.com> Ian Jackson <ian.jackson@eu.citrix.com> Jan Beulich <jbeulich@suse.com> Lasse Collin <lasse.collin@tukaani.org> Olaf Hering <olaf@aepfle.de> Thomas Renninger <trenn@suse.de> ------------------------------------------------------------ jobs: build-amd64 pass build-i386 pass build-amd64-oldkern pass build-i386-oldkern pass build-amd64-pvops pass build-i386-pvops pass test-amd64-amd64-xl fail test-amd64-i386-xl pass test-i386-i386-xl pass test-amd64-i386-rhel6hvm-amd fail test-amd64-i386-xl-credit2 fail test-amd64-amd64-xl-pcipt-intel fail test-amd64-i386-rhel6hvm-intel fail test-amd64-i386-xl-multivcpu pass test-amd64-amd64-pair fail test-amd64-i386-pair fail test-i386-i386-pair pass test-amd64-amd64-pv pass test-amd64-i386-pv fail test-i386-i386-pv fail test-amd64-amd64-xl-sedf pass test-amd64-i386-win-vcpus1 fail test-amd64-i386-xl-win-vcpus1 fail test-amd64-amd64-win fail test-amd64-i386-win fail test-i386-i386-win fail test-amd64-amd64-xl-win fail test-i386-i386-xl-win fail ------------------------------------------------------------ sg-report-flight on woking.cam.xci-test.com logs: /home/xc_osstest/logs images: /home/xc_osstest/images Logs, config files, etc. are available at http://www.chiark.greenend.org.uk/~xensrcts/logs Test harness code can be found at http://xenbits.xensource.com/gitweb?p=osstest.git;a=summary Not pushing. ------------------------------------------------------------ changeset: 23872:cc339ab1d917 tag: tip user: Ian Campbell <ian.campbell@citrix.com> date: Thu Sep 22 18:37:06 2011 +0100 tools: fix install of lomount $(BIN) went away in 23124:e3d4c34b14a3. Also there are no *.so, *.a or *.rpm built in here Signed-off-by: Ian Campbell <ian.campbell@citrix.com> changeset: 23871:503ee256fecf user: Jan Beulich <jbeulich@suse.com> date: Thu Sep 22 18:35:30 2011 +0100 x86: ucode-amd: Don't warn when no ucode is available for a CPU revision This patch originally comes from the Linus mainline kernel (2.6.33), find below the patch details: From: Andreas Herrmann <herrmann.der.user@googlemail.com> There is no point in warning when there is no ucode available for a specific CPU revision. Currently the container-file, which provides the AMD ucode patches for OS load, contains only a few ucode patches. It's already clearly indicated by the printed patch_level whenever new ucode was available and an update happened. So the warning message is of no help but rather annoying on systems with many CPUs. Signed-off-by: Thomas Renninger <trenn@suse.de> Signed-off-by: Jan Beulich <jbeulich@suse.com> changeset: 23870:5c97b02f48fc user: Jan Beulich <jbeulich@suse.com> date: Thu Sep 22 18:34:27 2011 +0100 XZ: Fix incorrect XZ_BUF_ERROR From: Lasse Collin <lasse.collin@tukaani.org> xz_dec_run() could incorrectly return XZ_BUF_ERROR if all of the following was true: - The caller knows how many bytes of output to expect and only provides that much output space. - When the last output bytes are decoded, the caller-provided input buffer ends right before the LZMA2 end of payload marker. So LZMA2 won't provide more output anymore, but it won't know it yet and thus won't return XZ_STREAM_END yet. - A BCJ filter is in use and it hasn't left any unfiltered bytes in the temp buffer. This can happen with any BCJ filter, but in practice it's more likely with filters other than the x86 BCJ. This fixes <https://bugzilla.redhat.com/show_bug.cgi?id=3D735408> where Squashfs thinks that a valid file system is corrupt. This also fixes a similar bug in single-call mode where the uncompressed size of a block using BCJ + LZMA2 was 0 bytes and caller provided no output space. Many empty .xz files don't contain any blocks and thus don't trigger this bug. This also tweaks a closely related detail: xz_dec_bcj_run() could call xz_dec_lzma2_run() to decode into temp buffer when it was known to be useless. This was harmless although it wasted a minuscule number of CPU cycles. Signed-off-by: Lasse Collin <lasse.collin@tukaani.org> Signed-off-by: Jan Beulich <jbeulich@suse.com> changeset: 23869:db1ea4b127cd user: Jan Beulich <jbeulich@suse.com> date: Thu Sep 22 18:33:48 2011 +0100 XZ decompressor: Fix decoding of empty LZMA2 streams From: Lasse Collin <lasse.collin@tukaani.org> The old code considered valid empty LZMA2 streams to be corrupt. Note that a typical empty .xz file has no LZMA2 data at all, and thus most .xz files having no uncompressed data are handled correctly even without this fix. Signed-off-by: Lasse Collin <lasse.collin@tukaani.org> Signed-off-by: Jan Beulich <jbeulich@suse.com> changeset: 23868:28147fd781af user: Jan Beulich <jbeulich@suse.com> date: Thu Sep 22 18:32:34 2011 +0100 VT-d: fix off-by-one error in RMRR validation (base_addr,end_addr) is an inclusive range, and hence there shouldn't be a subtraction of 1 in the second invocation of page_is_ram_type(). For RMRRs covering a single page that actually resulted in the immediately preceding page to get checked (which could have resulted in a false warning). Signed-off-by: Jan Beulich <jbeulich@suse.com> changeset: 23867:571b6e90dfb4 user: Jan Beulich <jbeulich@suse.com> date: Thu Sep 22 18:31:44 2011 +0100 VT-d: eliminate a mis-use of pcidevs_lock dma_pte_clear_one() shouldn't acquire this global lock for the purpose of processing a per-domain list. Furthermore the function a few lines earlier has a comment stating that acquiring pcidevs_lock isn't necessary here (whether that's really correct is another question). Use the domain's mappin_lock instead to protect the mapped_rmrrs list. Fold domain_rmrr_mapped() into its sole caller so that the otherwise implicit dependency on pcidevs_lock there becomes more obvious (see the comment there). Signed-off-by: Jan Beulich <jbeulich@suse.com> changeset: 23866:47ec1d405af9 user: Jan Beulich <jbeulich@suse.com> date: Thu Sep 22 18:31:02 2011 +0100 x86: IO-APIC code has no dependency on PCI The IRQ handling code requires pcidevs_lock to be held only for MSI interrupts. As the handling of which was now fully moved into msi.c (i.e. while applying fine without, the patch needs to be applied after the one titled "x86: split MSI IRQ chip"), io_apic.c now also doesn't need to include PCI headers anymore. Signed-off-by: Jan Beulich <jbeulich@suse.com> changeset: 23865:d6e01c7853cf user: Jan Beulich <jbeulich@suse.com> date: Thu Sep 22 18:29:19 2011 +0100 PCI multi-seg: config space accessor adjustments Signed-off-by: Jan Beulich <jbeulich@suse.com> changeset: 23864:314b147d524d user: Jan Beulich <jbeulich@suse.com> date: Thu Sep 22 18:28:38 2011 +0100 PCI multi-seg: Pass-through adjustments Signed-off-by: Jan Beulich <jbeulich@suse.com> changeset: 23863:9e0259239822 user: Jan Beulich <jbeulich@suse.com> date: Thu Sep 22 18:28:03 2011 +0100 PCI multi-seg: AMD-IOMMU specific adjustments There are two places here where it is entirely unclear to me where the necessary PCI segment number should be taken from (as IVMD descriptors don't have such, only IVHD ones do). AMD confirmed that for the time being it is acceptable to imply that only segment 0 exists. Signed-off-by: Jan Beulich <jbeulich@suse.com> changeset: 23862:85418e168527 user: Jan Beulich <jbeulich@suse.com> date: Thu Sep 22 18:27:26 2011 +0100 PCI multi-seg: VT-d specific adjustments Signed-off-by: Jan Beulich <jbeulich@suse.com> changeset: 23861:ec7c81fbe0de user: Jan Beulich <jbeulich@suse.com> date: Thu Sep 22 18:26:54 2011 +0100 PCI multi-seg: adjust domctl interface Again, a couple of directly related functions at once get adjusted to account for the segment number. Signed-off-by: Jan Beulich <jbeulich@suse.com> changeset: 23860:a422e2a4451e user: Jan Beulich <jbeulich@suse.com> date: Sun Sep 18 00:26:52 2011 +0100 x86: split MSI IRQ chip With the .end() accessor having become optional and noting that several of the accessors' behavior really depends on the result of msi_maskable_irq(), the splits the MSI IRQ chip type into two - one for the maskable ones, and the other for the (MSI only) non-maskable ones. At once the implementation of those methods gets moved from io_apic.c to msi.c. Signed-off-by: Jan Beulich <jbeulich@suse.com> ======================================== commit cd776ee9408ff127f934a707c1a339ee600bc127 Author: Ian Jackson <ian.jackson@eu.citrix.com> Date: Tue Jun 28 13:50:53 2011 +0100 qemu-char.c: fix incorrect CONFIG_STUBDOM handling qemu-char.c:1123:7: warning: "CONFIG_STUBDOM" is not defined [-Wundef] Signed-off-by: Olaf Hering <olaf@aepfle.de> Acked-by: Ian Jackson <ian.jackson@eu.citrix.com> _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel From xen-devel-bounces@lists.xensource.com Thu Sep 22 21:23:39 2011 Return-path: <xen-devel-bounces@lists.xensource.com> Envelope-to: www-data@lists.xensource.com Delivery-date: Thu, 22 Sep 2011 21:23:39 -0700 Received: from localhost ([127.0.0.1] helo=lists.colo.xensource.com) by lists.xensource.com with esmtp (Exim 4.43) id 1R6xIZ-00083W-Or; Thu, 22 Sep 2011 21:23:39 -0700 Received: from mail182.messagelabs.com ([85.158.139.83]) by lists.xensource.com with smtp (Exim 4.43) id 1R6xHh-0007r3-SQ for Xen-devel@lists.xensource.com; Thu, 22 Sep 2011 21:22:46 -0700 X-Env-Sender: sfr@canb.auug.org.au X-Msg-Ref: server-4.tower-182.messagelabs.com!1316751761!19417697!1 X-Originating-IP: [203.10.76.15] X-StarScan-Version: 6.4.1; banners=-,-,- X-VirusChecked: Checked Received: (qmail 13796 invoked from network); 23 Sep 2011 04:22:41 -0000 Received: from calzone.tip.net.au (HELO calzone.tip.net.au) (203.10.76.15) by server-4.tower-182.messagelabs.com with SMTP; 23 Sep 2011 04:22:41 -0000 Received: from canb.auug.org.au (ibmaus65.lnk.telstra.net [165.228.126.9]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by calzone.tip.net.au (Postfix) with ESMTPSA id F234A12843F; Fri, 23 Sep 2011 14:22:35 +1000 (EST) Date: Fri, 23 Sep 2011 14:22:33 +1000 From: Stephen Rothwell <sfr@canb.auug.org.au> To: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com> Message-Id: <20110923142233.316b994baac3adffcf4afdbc@canb.auug.org.au> X-Mailer: Sylpheed 3.2.0beta3 (GTK+ 2.24.6; i486-pc-linux-gnu) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Cc: Fitzhardinge <jeremy@goop.org>, linux-next@vger.kernel.org, Jeremy, linux-kernel@vger.kernel.org, Xen Devel <Xen-devel@lists.xensource.com> Subject: [Xen-devel] linux-next: manual merge of the xen-two tree with the xen tree X-BeenThere: xen-devel@lists.xensource.com X-Mailman-Version: 2.1.5 Precedence: list List-Id: Xen developer discussion <xen-devel.lists.xensource.com> List-Unsubscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe> List-Post: <mailto:xen-devel@lists.xensource.com> List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help> List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=subscribe> Sender: xen-devel-bounces@lists.xensource.com Errors-To: xen-devel-bounces@lists.xensource.com Hi Konrad, Today's linux-next merge of the xen-two tree got a conflict in arch/x86/xen/Kconfig between commit 430bdcaf0b96 ("xen: add CPU microcode update driver") from the xen tree and commit 10fe570fc167 ("Revert "xen/debug: WARN_ON when identity PFN has no _PAGE_IOMAP flag set."") from the xen-two tree. Just context changes. I fixed it up (see below) and can carry the fix as necessary. [Jeremy: the xen patch is missing a new-line at the end of the file ...] -- Cheers, Stephen Rothwell sfr@canb.auug.org.au diff --cc arch/x86/xen/Kconfig index c5d7ccb,ae559fe..0000000 --- a/arch/x86/xen/Kconfig +++ b/arch/x86/xen/Kconfig @@@ -49,15 -49,3 +49,7 @@@ config XEN_DEBUG_F help Enable statistics output and various tuning options in debugfs. Enabling this option may incur a significant performance overhead. + - config XEN_DEBUG - bool "Enable Xen debug checks" - depends on XEN - default n - help - Enable various WARN_ON checks in the Xen MMU code. - Enabling this option WILL incur a significant performance overhead. - +config MICROCODE_XEN + def_bool y - depends on XEN_DOM0 && MICROCODE ++ depends on XEN_DOM0 && MICROCODE _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel From xen-devel-bounces@lists.xensource.com Thu Sep 22 22:04:29 2011 Return-path: <xen-devel-bounces@lists.xensource.com> Envelope-to: www-data@lists.xensource.com Delivery-date: Thu, 22 Sep 2011 22:04:29 -0700 Received: from localhost ([127.0.0.1] helo=lists.colo.xensource.com) by lists.xensource.com with esmtp (Exim 4.43) id 1R6xw3-0000sH-TM; Thu, 22 Sep 2011 22:04:28 -0700 Received: from mail182.messagelabs.com ([85.158.139.83]) by lists.xensource.com with smtp (Exim 4.43) id 1R6xrL-0000bm-PV for xen-devel@lists.xensource.com; Thu, 22 Sep 2011 22:00:10 -0700 X-Env-Sender: victor_ling12@yahoo.com X-Msg-Ref: server-13.tower-182.messagelabs.com!1316753970!19254238!1 X-Originating-IP: [98.139.91.77] X-StarScan-Version: 6.4.1; banners=-,-,- X-VirusChecked: Checked Received: (qmail 1308 invoked from network); 23 Sep 2011 04:59:30 -0000 Received: from nm7.bullet.mail.sp2.yahoo.com (HELO nm7.bullet.mail.sp2.yahoo.com) (98.139.91.77) by server-13.tower-182.messagelabs.com with SMTP; 23 Sep 2011 04:59:30 -0000 Received: from [98.139.91.69] by nm7.bullet.mail.sp2.yahoo.com with NNFMP; 23 Sep 2011 04:59:29 -0000 Received: from [98.139.91.35] by tm9.bullet.mail.sp2.yahoo.com with NNFMP; 23 Sep 2011 04:59:29 -0000 Received: from [127.0.0.1] by omp1035.mail.sp2.yahoo.com with NNFMP; 23 Sep 2011 04:59:29 -0000 X-Yahoo-Newman-Property: ymail-3 X-Yahoo-Newman-Id: 793218.82076.bm@omp1035.mail.sp2.yahoo.com Received: (qmail 58959 invoked by uid 60001); 23 Sep 2011 04:59:29 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s1024; t=1316753969; bh=9KTgRIKL+zzGGpIk1Xvy4uiM/KXenK3/lGfCwLAPC5A=; h=X-YMail-OSG:Received:X-Mailer:Message-ID:Date:From:Subject:To:MIME-Version:Content-Type; b=GGmKPYPY4k6dZpOCSrnCwutSOoybuVr+L81MyilmIbyGPUytrO5FU9itCM/77rgnnvXb3GPMzotgINRWcqkPVjnxteT+Y9xHS8dVY6c0az0GVmMz5Fp+5NDCrM5CB8tZ0eDyF6PkoK/Id1hoUM/0UCW5jzfZKmbEeGrsbVdjcyE= DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com; h=X-YMail-OSG:Received:X-Mailer:Message-ID:Date:From:Subject:To:MIME-Version:Content-Type; b=gt6UPLheBuvzp9v5gXEO0SvIVnTtzxTjLcQockPCJhvd6uocKQL/iy90z8dj6f2xDKZTSxah+W5D5/f7lTgO/lUWzyPiTujCsBCeCdDuqcrNYcWAYV6RH8QZ4NfApF+TEH8TKAuBLP+hO5dP2Pz4RyhK2hlldbTwQHWWS1ZUkGs=; X-YMail-OSG: 7ZQpe0YVM1l9vm8QFDjT3ZSmeJK7Rjrh8S9bpnseaW3kBQb pzD29whPBrQi93SpCtqGYadRAxIOeYnXYceYkLc2dARFsyQNuljzeaBi0Bff CfYxFA95JJj0rPjkAchCkDnEY6Dy4Ylw_QCCmX9eTk47jLPtSIK44O_vYPvX qo5MzaXSXkfW4wY.LFLnlLRsxpy6WLtuboWWgTVCh0fECIiQG4eB1JcK6YxG rmoTo8alILGO6RY7ncMaA_wsMkuyZNkz8Ts6YHd7IBHEF99K93dBkmyxcacf 5JClK3ST4rv7.M6NjHYi7zm3KF33eTHl_5OV15CLC9ihbaQqQtd9gV3Gvb8x V0RDpxU06Eun04UOzZvw.RyP1wiSkcpeK1ShizGukO3XHK6hNxXA- Received: from [174.62.74.113] by web114216.mail.gq1.yahoo.com via HTTP; Thu, 22 Sep 2011 21:59:28 PDT X-Mailer: YahooMailClassic/14.0.5 YahooMailWebService/0.8.113.315625 Message-ID: <1316753968.53802.YahooMailClassic@web114216.mail.gq1.yahoo.com> Date: Thu, 22 Sep 2011 21:59:28 -0700 (PDT) From: Victor Ling <victor_ling12@yahoo.com> To: xen-devel@lists.xensource.com MIME-Version: 1.0 Subject: [Xen-devel] Fw: [Xen-users] DomU kernel panic X-BeenThere: xen-devel@lists.xensource.com X-Mailman-Version: 2.1.5 Precedence: list List-Id: Xen developer discussion <xen-devel.lists.xensource.com> List-Unsubscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe> List-Post: <mailto:xen-devel@lists.xensource.com> List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help> List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=subscribe> Content-Type: multipart/mixed; boundary="===============1927591266==" Sender: xen-devel-bounces@lists.xensource.com Errors-To: xen-devel-bounces@lists.xensource.com --===============1927591266== Content-Type: multipart/alternative; boundary="-712257664-1891239261-1316753968=:53802" ---712257664-1891239261-1316753968=:53802 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable Please help if you have any idea. Thanks. --- On Fri, 9/23/11, Victor Ling <victor_ling12@yahoo.com> wrote: From: Victor Ling <victor_ling12@yahoo.com> Subject: [Xen-users] DomU kernel panic To: "xen-users@lists.xensource.com" <xen-users@lists.xensource.com> Date: Friday, September 23, 2011, 1:14 AM I also got DomU kernel panic problem, please help me on this problem.The fo= llowing is the detail info: Thanks. Vic ------------------------------------------- Config file:kernel=A0 =3D "/boot/vmlinuz-xen" ramdisk =3D "/boot/initrd-xen" memory =3D 512 vcpus =3D '2' pci =3D ['02:00.0'] name =3D "xen-vm1" root =3D '/dev/xvda1 ro' disk =3D [ =A0=A0=A0=A0=A0=A0=A0=A0 'file:/home/domains/nvidia/XenGuest1.img,xvda1,w', =A0=A0=A0=A0=A0=A0=A0 ] on_poweroff =3D 'destroy' on_reboot =3D 'restart' on_crash =3D 'restart' ---------------------------------------- /etc/fstab linux:/etc # more=0A fstab /dev/xvda1=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 /=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0= =A0=A0=A0=A0=A0=A0=A0=A0 ext3=A0=A0=A0=A0=A0=A0 defaults=A0=A0=A0=A0=A0=A0= =A0=A0=A0=A0=A0=A0=A0 1 1 /dev/xvda2=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 none=A0=A0=A0=A0=A0=A0=A0=A0=A0= =A0=A0=A0=A0=A0=A0 swap=A0=A0=A0=A0=A0=A0 sw=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0= =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 0 0 proc=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 /proc=A0=A0=A0=A0=A0= =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 proc=A0=A0=A0=A0=A0=A0=0A defaults=A0=A0=A0= =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 0 0 sysfs=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 /sys=A0=A0=A0=A0=A0=A0= =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 sysfs=A0=A0=A0=A0=A0 noauto=A0=A0=A0=A0=A0= =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 0 0 debugfs=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 /sys/kernel/debug=A0=A0=A0 d= ebugfs=A0=A0=A0 noauto=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 0 0 usbfs=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 /proc/bus/usb=A0=A0=A0= =A0=A0=A0=A0 usbfs=A0=A0=A0=A0=A0 noauto=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0= =A0=A0=A0=A0=0A 0 0 devpts=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 /dev/pts=A0=A0=A0=A0=A0=A0= =A0=A0=A0=A0=A0=A0 devpts=A0=A0=A0=A0 mode=3D0620,gid=3D5=A0=A0=A0=A0=A0=A0= 0 0 ---------------------------------------------------------------------------= ------- Trace:Started domain xen-vm1 (id=3D4) [=A0=A0=A0 0.000000] Initializing cgroup subsys cpuset [=A0=A0=A0 0.000000] Initializing cgroup subsys cpu [=A0=A0=A0 0.000000] Linux version 2.6.32.12-0.7-xen (geeko@buildhost) (gcc= version 4. 3.4 [gcc-4_3-branch revision 152973] (SUSE Linux) ) #1 SMP 2010-05-20 11:14= :20 + 0200 [=A0=A0=A0 0.000000] Command line: root=3D/dev/xvda1 ro=20 [=A0=A0=A0 0.000000] KERNEL supported cpus: [=A0=A0=A0 0.000000]=A0=A0 Intel GenuineIntel [=A0=A0=A0 0.000000]=A0=A0 AMD=0A AuthenticAMD [=A0=A0=A0 0.000000]=A0=A0 Centaur CentaurHauls [=A0=A0=A0 0.000000] Xen-provided physical RAM map: [=A0=A0=A0 0.000000]=A0 Xen: 0000000000000000 - 0000000020800000 (usable) [=A0=A0=A0 0.000000] last_pfn =3D 0x20800 max_arch_pfn =3D 0x80000000 [=A0=A0=A0 0.000000] init_memory_mapping: 0000000000000000-0000000020800000 [=A0=A0=A0 0.000000] RAMDISK: 00765000 - 01599000 [=A0=A0=A0 0.000000] ACPI in unprivileged domain disabled . . .[=A0=A0=A0 1.111385] Uniform Multi-Platform E-IDE driver [=A0=A0=A0 1.166266] BIOS EDD facility v0.16 2004-Jun-25, 0 devices found [=A0=A0=A0 1.166275] EDD information not available. [=A0=A0=A0 1.181202] netfront: Initialising virtual ethernet driver. [=A0=A0=A0 1.295585] xen-vbd: registered block device major 202 [=A0=A0=A0 1.295611] blkfront: xvda1:=0A barriers enabled [=A0=A0=A0 1.391963] udevd version 128 started [=A0=A0=A0 1.563846] kjournald starting.=A0 Commit interval 15 seconds [=A0=A0=A0 1.563842] EXT3-fs: mounted filesystem with ordered data mode. [=A0=A0 11.900565] Kernel panic - not syncing: Attempted to kill init! [=A0=A0 11.900575] Pid: 1, comm: run-init Not tainted 2.6.32.12-0.7-xen #1 [=A0=A0 11.900578] Call Trace: [=A0=A0 11.900592]=A0 [<ffffffff80009af5>] dump_trace+0x65/0x180 [=A0=A0 11.900600]=A0 [<ffffffff8034f056>] dump_stack+0x69/0x73 [=A0=A0 11.900608]=A0 [<ffffffff8034f0d8>] panic+0x78/0x195 [=A0=A0 11.900614]=A0 [<ffffffff800419c9>] forget_original_parent+0x359/0x3= 60 [=A0=A0 11.900621]=A0 [<ffffffff800419e0>] exit_notify+0x10/0x1d0 [=A0=A0 11.900625]=A0 [<ffffffff80041d10>]=0A do_exit+0x170/0x340 [=A0=A0 11.900631]=A0 [<ffffffff8004226f>] do_group_exit+0x3f/0xf0 [=A0=A0 11.900637]=A0 [<ffffffff80042332>] sys_exit_group+0x12/0x20 [=A0=A0 11.900642]=A0 [<ffffffff80007458>] system_call_fastpath+0x16/0x1b [=A0=A0 11.900652]=A0 [<00007f999cdd6418>] 0x7f999cdd6418 -----Inline Attachment Follows----- _______________________________________________ Xen-users mailing list Xen-users@lists.xensource.com http://lists.xensource.com/xen-users ---712257664-1891239261-1316753968=:53802 Content-Type: text/html; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable <table cellspacing=3D"0" cellpadding=3D"0" border=3D"0" ><tr><td valign=3D"= top" style=3D"font: inherit;">Please help if you have any idea.<br><br>Than= ks.<br><br>--- On <b>Fri, 9/23/11, Victor Ling <i><victor_ling12@yahoo.c= om></i></b> wrote:<br><blockquote style=3D"border-left: 2px solid rgb(16= , 16, 255); margin-left: 5px; padding-left: 5px;"><br>From: Victor Ling <= ;victor_ling12@yahoo.com><br>Subject: [Xen-users] DomU kernel panic<br>T= o: "xen-users@lists.xensource.com" <xen-users@lists.xensource.com><br= >Date: Friday, September 23, 2011, 1:14 AM<br><br><div id=3D"yiv3671035"><d= iv style=3D"color:#000;background-color:#fff;font-family:times new roman, n= ew york, times, serif;font-size:12pt;"><div>I also got DomU kernel panic pr= oblem, please help me on this problem.</div><div>The following is the detai= l info:</div><div><br></div><div>Thanks.</div><div><br></div><div>Vic<br></= div><div>-------------------------------------------<br></div><div>Config file:</div>kernel  =3D "/boot/vmlinuz-xen"<br>ramdisk =3D "/boot/init= rd-xen"<br>memory =3D 512<br>vcpus =3D '2'<br>pci =3D ['02:00.0']<br>name = =3D "xen-vm1"<br>root =3D '/dev/xvda1 ro'<br>disk =3D [<br>  &nbs= p;      'file:/home/domains/nvidia/XenGuest1.img,x= vda1,w',<br>        ]<br><br>on_poweroff= =3D 'destroy'<br>on_reboot =3D 'restart'<br>on_crash =3D 'restart'<br><br>= ----------------------------------------<br><br>/etc/fstab<br>linux:/etc # = more=0A fstab<br>/dev/xvda1        =     /         &= nbsp;         ext3   = ;    defaults        = ;      1 1<br>/dev/xvda2    &n= bsp;       none     =            swap &nbs= p;     sw       &nbs= p;             = 0 0<br>proc          &nbs= p;      /proc      &= nbsp;         proc   = ;   =0A defaults       &n= bsp;      0 0<br>sysfs    &nbs= p;           /sys &n= bsp;            = ;   sysfs      noauto   &= nbsp;            0 0= <br>debugfs          &nbs= p;   /sys/kernel/debug    debugfs   = ; noauto           &= nbsp;    0 0<br>usbfs      &nb= sp;         /proc/bus/usb &nbs= p;      usbfs      noauto=             &nb= sp;  =0A 0 0<br>devpts       &= nbsp;       /dev/pts    &= nbsp;        devpts   &nb= sp; mode=3D0620,gid=3D5       0 0<br><br>----= ---------------------------------------------------------------------------= ---<br><br><br>Trace:Started domain xen-vm1 (id=3D4)<br>[   = 0.000000] Initializing cgroup subsys cpuset<br>[    0.00000= 0] Initializing cgroup subsys cpu<br>[    0.000000] Linux ve= rsion 2.6.32.12-0.7-xen (geeko@buildhost) (gcc version 4.<br>3.4 [gcc-4_3-b= ranch revision 152973] (SUSE Linux) ) #1 SMP 2010-05-20 11:14:20 +<br>0200<= br>[    0.000000] Command line: root=3D/dev/xvda1 ro <br>[&n= bsp;   0.000000] KERNEL supported cpus:<br>[    0.= 000000]   Intel GenuineIntel<br>[    0.000000]&nbs= p;  AMD=0A AuthenticAMD<br>[    0.000000]   C= entaur CentaurHauls<br>[    0.000000] Xen-provided physical = RAM map:<br>[    0.000000]  Xen: 0000000000000000 - 000= 0000020800000 (usable)<br>[    0.000000] last_pfn =3D 0x2080= 0 max_arch_pfn =3D 0x80000000<br>[    0.000000] init_memory_= mapping: 0000000000000000-0000000020800000<br>[    0.000000]= RAMDISK: 00765000 - 01599000<br>[    0.000000] ACPI in unpr= ivileged domain disabled<br>.<br>.<br>.[    1.111385] Unifor= m Multi-Platform E-IDE driver<br>[    1.166266] BIOS EDD fac= ility v0.16 2004-Jun-25, 0 devices found<br>[    1.166275] E= DD information not available.<br>[    1.181202] netfront: In= itialising virtual ethernet driver.<br>[    1.295585] xen-vb= d: registered block device major 202<br>[    1.295611] blkfr= ont: xvda1:=0A barriers enabled<br>[    1.391963] udevd vers= ion 128 started<br>[    1.563846] kjournald starting.  = Commit interval 15 seconds<br>[    1.563842] EXT3-fs: mounte= d filesystem with ordered data mode.<br>[   11.900565] Kernel pan= ic - not syncing: Attempted to kill init!<br>[   11.900575] Pid: = 1, comm: run-init Not tainted 2.6.32.12-0.7-xen #1<br>[   11.9005= 78] Call Trace:<br>[   11.900592]  [<ffffffff80009af5>= ] dump_trace+0x65/0x180<br>[   11.900600]  [<ffffffff8034= f056>] dump_stack+0x69/0x73<br>[   11.900608]  [<fffff= fff8034f0d8>] panic+0x78/0x195<br>[   11.900614]  [<ff= ffffff800419c9>] forget_original_parent+0x359/0x360<br>[   11.= 900621]  [<ffffffff800419e0>] exit_notify+0x10/0x1d0<br>[ &= nbsp; 11.900625]  [<ffffffff80041d10>]=0A do_exit+0x170/0x340<br= >[   11.900631]  [<ffffffff8004226f>] do_group_exit+0x= 3f/0xf0<br>[   11.900637]  [<ffffffff80042332>] sys_ex= it_group+0x12/0x20<br>[   11.900642]  [<ffffffff80007458&= gt;] system_call_fastpath+0x16/0x1b<br>[   11.900652]  [<= 00007f999cdd6418>] 0x7f999cdd6418<br><br><br><br><br><br><br><div><br></= div></div></div><br>-----Inline Attachment Follows-----<br><br><div class= =3D"plainMail">_______________________________________________<br>Xen-users= mailing list<br><a ymailto=3D"mailto:Xen-users@lists.xensource.com" href= =3D"/mc/compose?to=3DXen-users@lists.xensource.com">Xen-users@lists.xensour= ce.com</a><br><a href=3D"http://lists.xensource.com/xen-users" target=3D"_b= lank">http://lists.xensource.com/xen-users</a></div></blockquote></td></tr>= </table> ---712257664-1891239261-1316753968=:53802-- --===============1927591266== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel --===============1927591266==-- From xen-devel-bounces@lists.xensource.com Thu Sep 22 22:31:29 2011 Return-path: <xen-devel-bounces@lists.xensource.com> Envelope-to: www-data@lists.xensource.com Delivery-date: Thu, 22 Sep 2011 22:31:29 -0700 Received: from localhost ([127.0.0.1] helo=lists.colo.xensource.com) by lists.xensource.com with esmtp (Exim 4.43) id 1R6yMD-00034G-Og; Thu, 22 Sep 2011 22:31:29 -0700 Received: from mail27.messagelabs.com ([193.109.254.147]) by lists.xensource.com with esmtp (Exim 4.43) id 1R6yLU-0002ra-09 for Xen-devel@lists.xensource.com; Thu, 22 Sep 2011 22:30:45 -0700 X-Env-Sender: Ian.Campbell@eu.citrix.com X-Msg-Ref: server-9.tower-27.messagelabs.com!1316755823!45674929!1 X-Originating-IP: [62.200.22.115] X-StarScan-Version: 6.4.1; banners=-,-,- X-VirusChecked: Checked Received: (qmail 29982 invoked from network); 23 Sep 2011 05:30:24 -0000 Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115) by server-9.tower-27.messagelabs.com with RC4-SHA encrypted SMTP; 23 Sep 2011 05:30:24 -0000 X-IronPort-AV: E=Sophos;i="4.68,427,1312156800"; d="scan'208";a="8020358" Received: from lonpmailmx01.citrite.net ([10.30.203.162]) by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5; 23 Sep 2011 05:30:19 +0000 Received: from [127.0.0.1] (10.80.16.67) by smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id 8.3.137.0; Fri, 23 Sep 2011 06:30:19 +0100 Subject: Re: [Xen-devel] arch_set_info_guest() and cr1 From: Ian Campbell <Ian.Campbell@eu.citrix.com> To: Jeremy Fitzhardinge <jeremy@goop.org> In-Reply-To: <4E7BC546.9030607@goop.org> References: <20110811190315.1cc6afab@mantra.us.oracle.com> <CA6A83D7.1F1E6%keir.xen@gmail.com> <20110812150115.6047b8c2@mantra.us.oracle.com> <4E45DED5.40602@goop.org> <1316676757.23371.2.camel@zakaz.uk.xensource.com> <4E7BC546.9030607@goop.org> Content-Type: text/plain; charset="ISO-8859-1" Organization: Citrix Systems, Inc. Date: Fri, 23 Sep 2011 06:30:18 +0100 Message-ID: <1316755818.27431.12.camel@dagon.hellion.org.uk> MIME-Version: 1.0 X-Mailer: Evolution 2.32.3 Content-Transfer-Encoding: 7bit Cc: Keir, "Xen-devel@lists.xensource.com" <Xen-devel@lists.xensource.com>, Tim Deegan <tim@xen.org>, Fraser <keir.xen@gmail.com> X-BeenThere: xen-devel@lists.xensource.com X-Mailman-Version: 2.1.5 Precedence: list List-Id: Xen developer discussion <xen-devel.lists.xensource.com> List-Unsubscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe> List-Post: <mailto:xen-devel@lists.xensource.com> List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help> List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=subscribe> Sender: xen-devel-bounces@lists.xensource.com Errors-To: xen-devel-bounces@lists.xensource.com On Fri, 2011-09-23 at 00:31 +0100, Jeremy Fitzhardinge wrote: > On 09/22/2011 12:32 AM, Ian Campbell wrote: > > (old mail, I know) > > > > On Sat, 2011-08-13 at 03:17 +0100, Jeremy Fitzhardinge wrote: > >> On 08/12/2011 03:01 PM, Mukesh Rathor wrote: > >>> Ah I see it, during save/restore, it is used. > >>> Well, I'm trying to keep the option of using PV paging with hybrid, so > >>> I may need to honor that. But that's phase 2. > >> Though it would be nice to re-enable the use of PV writable pagetables > >> to get access to HAP, and we could do without that. > >> > >> Does Xen require that the user pagetable be a proper subset of the > >> kernel pagetable? If we can assume that and get proper ring protections > >> in the HVM container, then we can simply ignore the user pagetable (and > >> would have to if we want to get good syscall performance). > > IIRC back when I did the (now completely defunct) supervisor mode kernel > > stuff that was exactly the assumption which was made and it certainly > > worked in practice (although "require" might be a strong term). > > Well, I guess we could add ELF notes to allow a guest to say "I really > need separate non-intersecting user/kernel pagetables" if they really > need it. Or repurpose auto_translated_physmap to also mean "no separate > user/kernel pagetables required". IIRC that's effectively one of the things which auto_translated_physmap implies. > Has that ever been supported for 64-bit PV guests? In the classic patches, yes, but not in the pvops ones AFAIK. > My memory of the chronology is that it died as a > feature at about the time that 64-bit support went in. > > J _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel From xen-devel-bounces@lists.xensource.com Thu Sep 22 22:38:19 2011 Return-path: <xen-devel-bounces@lists.xensource.com> Envelope-to: www-data@lists.xensource.com Delivery-date: Thu, 22 Sep 2011 22:38:19 -0700 Received: from localhost ([127.0.0.1] helo=lists.colo.xensource.com) by lists.xensource.com with esmtp (Exim 4.43) id 1R6ySp-0003jl-Bv; Thu, 22 Sep 2011 22:38:19 -0700 Received: from mail216.messagelabs.com ([85.158.143.99]) by lists.xensource.com with esmtp (Exim 4.43) id 1R6yS3-0003XA-Bl for xen-devel@lists.xensource.com; Thu, 22 Sep 2011 22:37:31 -0700 X-Env-Sender: Ian.Jackson@eu.citrix.com X-Msg-Ref: server-6.tower-216.messagelabs.com!1316756248!18028779!1 X-Originating-IP: [62.200.22.115] X-StarScan-Version: 6.4.1; banners=-,-,- X-VirusChecked: Checked Received: (qmail 19210 invoked from network); 23 Sep 2011 05:37:28 -0000 Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115) by server-6.tower-216.messagelabs.com with RC4-SHA encrypted SMTP; 23 Sep 2011 05:37:28 -0000 X-IronPort-AV: E=Sophos;i="4.68,427,1312156800"; d="scan'208";a="8020393" Received: from lonpmailmx01.citrite.net ([10.30.203.162]) by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5; 23 Sep 2011 05:37:27 +0000 Received: from woking.xci-test.com (10.80.248.135) by smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id 8.3.137.0; Fri, 23 Sep 2011 06:37:28 +0100 Received: from osstest by woking.xci-test.com with local (Exim 4.69) (envelope-from <ian.jackson@eu.citrix.com>) id 1R6yRz-0002TN-LY; Fri, 23 Sep 2011 06:37:27 +0100 To: xen-devel@lists.xensource.com Message-ID: <osstest-9006-mainreport@xen.org> From: xen.org <ian.jackson@eu.citrix.com> Date: Fri, 23 Sep 2011 06:37:27 +0100 MIME-Version: 1.0 Content-Type: text/plain Cc: ian.jackson@eu.citrix.com Subject: [Xen-devel] [linux test] 9006: tolerable FAIL X-BeenThere: xen-devel@lists.xensource.com X-Mailman-Version: 2.1.5 Precedence: list List-Id: Xen developer discussion <xen-devel.lists.xensource.com> List-Unsubscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe> List-Post: <mailto:xen-devel@lists.xensource.com> List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help> List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=subscribe> Sender: xen-devel-bounces@lists.xensource.com Errors-To: xen-devel-bounces@lists.xensource.com flight 9006 linux real [real] http://www.chiark.greenend.org.uk/~xensrcts/logs/9006/ Failures :-/ but no regressions. Tests which did not succeed, but are not blocking, including regressions (tests previously passed) regarded as allowable: test-amd64-amd64-xl-pcipt-intel 9 guest-start fail never pass test-amd64-i386-rhel6hvm-amd 9 guest-start.2 fail never pass test-amd64-i386-rhel6hvm-intel 9 guest-start.2 fail never pass test-amd64-i386-win-vcpus1 16 leak-check/check fail never pass test-amd64-i386-xl-win-vcpus1 13 guest-stop fail never pass test-amd64-amd64-win 16 leak-check/check fail never pass test-amd64-amd64-xl-win 13 guest-stop fail never pass test-i386-i386-xl-win 13 guest-stop fail never pass test-i386-i386-win 16 leak-check/check fail never pass test-amd64-i386-win 16 leak-check/check fail never pass version targeted for testing: linux 6bec8b4a4c14095d0b7ce424db9d583c3decae6c baseline version: linux 1c3f03ccc5258887f5f2cafc0836a865834f9205 ------------------------------------------------------------ People who touched revisions under test: Jeremy Fitzhardinge <jeremy.fitzhardinge@citrix.com> ------------------------------------------------------------ jobs: build-amd64 pass build-i386 pass build-amd64-pvops pass build-i386-pvops pass test-amd64-amd64-xl pass test-amd64-i386-xl pass test-i386-i386-xl pass test-amd64-i386-rhel6hvm-amd fail test-amd64-i386-xl-credit2 pass test-amd64-amd64-xl-pcipt-intel fail test-amd64-i386-rhel6hvm-intel fail test-amd64-i386-xl-multivcpu pass test-amd64-amd64-pair pass test-amd64-i386-pair pass test-i386-i386-pair pass test-amd64-amd64-pv pass test-amd64-i386-pv pass test-i386-i386-pv pass test-amd64-amd64-xl-sedf pass test-amd64-i386-win-vcpus1 fail test-amd64-i386-xl-win-vcpus1 fail test-amd64-amd64-win fail test-amd64-i386-win fail test-i386-i386-win fail test-amd64-amd64-xl-win fail test-i386-i386-xl-win fail ------------------------------------------------------------ sg-report-flight on woking.cam.xci-test.com logs: /home/xc_osstest/logs images: /home/xc_osstest/images Logs, config files, etc. are available at http://www.chiark.greenend.org.uk/~xensrcts/logs Test harness code can be found at http://xenbits.xensource.com/gitweb?p=osstest.git;a=summary Pushing revision : + branch=linux + revision=6bec8b4a4c14095d0b7ce424db9d583c3decae6c + . cri-lock-repos ++ . cri-common +++ umask 002 +++ getconfig Repos +++ perl -e ' use Osstest; readconfigonly(); print $c{Repos} or die $!; ' ++ repos=/export/home/osstest/repos ++ repos_lock=/export/home/osstest/repos/lock ++ '[' x '!=' x/export/home/osstest/repos/lock ']' ++ OSSTEST_REPOS_LOCK_LOCKED=/export/home/osstest/repos/lock ++ exec with-lock-ex -w /export/home/osstest/repos/lock ./ap-push linux 6bec8b4a4c14095d0b7ce424db9d583c3decae6c + branch=linux + revision=6bec8b4a4c14095d0b7ce424db9d583c3decae6c + . cri-lock-repos ++ . cri-common +++ umask 002 +++ getconfig Repos +++ perl -e ' use Osstest; readconfigonly(); print $c{Repos} or die $!; ' ++ repos=/export/home/osstest/repos ++ repos_lock=/export/home/osstest/repos/lock ++ '[' x/export/home/osstest/repos/lock '!=' x/export/home/osstest/repos/lock ']' + : xen@xenbits.xensource.com + : xen@xenbits.xensource.com:git/linux-pvops + : master + : tested/2.6.39.x + case "$branch" in + cd /export/home/osstest/repos/xen ./ap-push: line 20: cd: /export/home/osstest/repos/xen: No such file or directory ------------------------------------------------------------ commit 6bec8b4a4c14095d0b7ce424db9d583c3decae6c Author: Jeremy Fitzhardinge <jeremy.fitzhardinge@citrix.com> Date: Fri Sep 2 12:23:22 2011 -0700 Revert "xen/apic: Provide an 'apic_xen' to set the override the apic->[read|write] for all cases." This reverts commit c3dd7941354fa96a71f2613e2c7a1b215fa175dc. It prevents the kernel from booting natively on hardware. Conflicts: arch/x86/xen/enlighten.c Signed-off-by: Jeremy Fitzhardinge <jeremy.fitzhardinge@citrix.com> _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel From xen-devel-bounces@lists.xensource.com Thu Sep 22 23:56:55 2011 Return-path: <xen-devel-bounces@lists.xensource.com> Envelope-to: www-data@lists.xensource.com Delivery-date: Thu, 22 Sep 2011 23:56:55 -0700 Received: from localhost ([127.0.0.1] helo=lists.colo.xensource.com) by lists.xensource.com with esmtp (Exim 4.43) id 1R6zgs-0005bY-Ug; Thu, 22 Sep 2011 23:56:54 -0700 Received: from mail216.messagelabs.com ([85.158.143.99]) by lists.xensource.com with esmtp (Exim 4.43) id 1R6zfg-0005Of-OW for xen-devel@lists.xensource.com; Thu, 22 Sep 2011 23:55:41 -0700 X-Env-Sender: JBeulich@suse.com X-Msg-Ref: server-7.tower-216.messagelabs.com!1316760937!19307952!1 X-Originating-IP: [130.57.49.28] X-StarScan-Version: 6.4.1; banners=-,-,- X-VirusChecked: Checked Received: (qmail 25135 invoked from network); 23 Sep 2011 06:55:37 -0000 Received: from nat28.tlf.novell.com (HELO nat28.tlf.novell.com) (130.57.49.28) by server-7.tower-216.messagelabs.com with DHE-RSA-AES256-SHA encrypted SMTP; 23 Sep 2011 06:55:37 -0000 Received: from EMEA1-MTA by nat28.tlf.novell.com with Novell_GroupWise; Fri, 23 Sep 2011 07:55:36 +0100 Message-Id: <4E7C49A402000078000577A6@nat28.tlf.novell.com> X-Mailer: Novell GroupWise Internet Agent 8.0.1 Date: Fri, 23 Sep 2011 07:56:04 +0100 From: "Jan Beulich" <JBeulich@suse.com> To: "Ian Campbell" <Ian.Campbell@eu.citrix.com>, "Jeremy Fitzhardinge" <jeremy@goop.org> Subject: Re: [Xen-devel] Re: [PATCH] xen: change XEN_PLATFORM_PCI to bool default y References: <1316608670-23167-1-git-send-email-stefano.stabellini@eu.citrix.com> <20110921185102.GJ17357@phenom.oracle.com> <1316632095.5182.33.camel@dagon.hellion.org.uk> <4E7A69DD.1080501@goop.org> <1316672473.27431.0.camel@dagon.hellion.org.uk> <4E7B8DE8.1070809@goop.org> In-Reply-To: <4E7B8DE8.1070809@goop.org> Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: quoted-printable Content-Disposition: inline Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>, Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>, Stefano Stabellini <Stefano.Stabellini@eu.citrix.com> X-BeenThere: xen-devel@lists.xensource.com X-Mailman-Version: 2.1.5 Precedence: list List-Id: Xen developer discussion <xen-devel.lists.xensource.com> List-Unsubscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe> List-Post: <mailto:xen-devel@lists.xensource.com> List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help> List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=subscribe> Sender: xen-devel-bounces@lists.xensource.com Errors-To: xen-devel-bounces@lists.xensource.com >>> On 22.09.11 at 21:35, Jeremy Fitzhardinge <jeremy@goop.org> wrote: > On 09/21/2011 11:21 PM, Ian Campbell wrote: >> On Wed, 2011-09-21 at 23:49 +0100, Jeremy Fitzhardinge wrote: >>>> That would work too. Even better would be to make it an invisible >>>> Kconfig symbol which PVHVM just selects. >>> Eh, select is pretty nasty. >> Select of a non user visible symbol is perfectly fine. It's only when >> you select something a user can also set that things get nasty. >=20 > It doesn't matter if its user-visible. If the selected symbol acquires > other dependencies, the selection won't set them. Despite there being numerous contrary examples in the tree: Either one wants a select-only symbol (then putting dependencies on it is wrong) or one wants an automatic symbol (then selecting it is very likely wrong). Which all boils down to the bogus mixing of normal (forward) and reverse dependencies (using the kconfig source/doc wording). Jan _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel From xen-devel-bounces@lists.xensource.com Fri Sep 23 00:04:15 2011 Return-path: <xen-devel-bounces@lists.xensource.com> Envelope-to: www-data@lists.xensource.com Delivery-date: Fri, 23 Sep 2011 00:04:15 -0700 Received: from localhost ([127.0.0.1] helo=lists.colo.xensource.com) by lists.xensource.com with esmtp (Exim 4.43) id 1R6znz-00065v-JA; Fri, 23 Sep 2011 00:04:15 -0700 Received: from mail21.messagelabs.com ([85.158.143.35]) by lists.xensource.com with esmtp (Exim 4.43) id 1R6zkK-0005qs-Ea for xen-devel@lists.xensource.com; Fri, 23 Sep 2011 00:00:57 -0700 X-Env-Sender: vase@selfip.ru X-Msg-Ref: server-4.tower-21.messagelabs.com!1316761188!61284950!1 X-Originating-IP: [74.125.82.43] X-StarScan-Version: 6.4.1; banners=-,-,- X-VirusChecked: Checked Received: (qmail 24548 invoked from network); 23 Sep 2011 06:59:48 -0000 Received: from mail-ww0-f43.google.com (HELO mail-ww0-f43.google.com) (74.125.82.43) by server-4.tower-21.messagelabs.com with RC4-SHA encrypted SMTP; 23 Sep 2011 06:59:48 -0000 Received: by wwf27 with SMTP id 27so2620018wwf.24 for <xen-devel@lists.xensource.com>; Fri, 23 Sep 2011 00:00:24 -0700 (PDT) MIME-Version: 1.0 Received: by 10.216.179.77 with SMTP id g55mr4669002wem.31.1316761223845; Fri, 23 Sep 2011 00:00:23 -0700 (PDT) Received: by 10.216.4.69 with HTTP; Fri, 23 Sep 2011 00:00:23 -0700 (PDT) X-Originating-IP: [85.143.161.18] Date: Fri, 23 Sep 2011 11:00:23 +0400 X-Google-Sender-Auth: IdtO0DDA2nMyilz3H9VmjsdsGMU Message-ID: <CACaajQvBtiNitzzeEoYXhRoV7eUHXqEL5BQ_59oQqswtHhkz1g@mail.gmail.com> From: Vasiliy Tolstov <v.tolstov@selfip.ru> To: xen-devel@lists.xensource.com Subject: [Xen-devel] xl usage and live migration X-BeenThere: xen-devel@lists.xensource.com X-Mailman-Version: 2.1.5 Precedence: list List-Id: Xen developer discussion <xen-devel.lists.xensource.com> List-Unsubscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe> List-Post: <mailto:xen-devel@lists.xensource.com> List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help> List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=subscribe> Content-Type: multipart/mixed; boundary="===============0891868461==" Sender: xen-devel-bounces@lists.xensource.com Errors-To: xen-devel-bounces@lists.xensource.com --===============0891868461== Content-Type: multipart/alternative; boundary=0016e65680d200575004ad965d1c --0016e65680d200575004ad965d1c Content-Type: text/plain; charset=UTF-8 Hello. We try to move from xm to xl usage. And have one question - if we use xm and xend domain create on destination via xmlrpc interface. But if we use xl and not run xend, how migration process worked in this case? (migration guide says that before using xl we need stop xend and disable it start..) Thanks! -- Vasiliy Tolstov, Clodo.ru e-mail: v.tolstov@selfip.ru jabber: vase@selfip.ru --0016e65680d200575004ad965d1c Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Hello. We try to move from xm to xl usage. And have one question - if we us= e xm and xend domain create on destination via xmlrpc interface.<div>But if= we use xl and not run xend, how migration process worked in this case? (mi= gration guide says that before using xl we need stop xend and disable it st= art..)</div> <div>Thanks!<br clear=3D"all"><div><br></div>-- <br><span style=3D"border-c= ollapse:collapse;color:rgb(136, 136, 136);font-family:arial, sans-serif;fon= t-size:13px"><div><div>Vasiliy Tolstov,</div><div>Clodo.ru</div><div>e-mail= : <a href=3D"mailto:v.tolstov@selfip.ru" target=3D"_blank">v.tolstov@selfip= .ru</a></div> <div>jabber: <a href=3D"mailto:vase@selfip.ru" target=3D"_blank">vase@selfi= p.ru</a></div></div></span><br> </div> --0016e65680d200575004ad965d1c-- --===============0891868461== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel --===============0891868461==-- From xen-devel-bounces@lists.xensource.com Fri Sep 23 00:06:05 2011 Return-path: <xen-devel-bounces@lists.xensource.com> Envelope-to: www-data@lists.xensource.com Delivery-date: Fri, 23 Sep 2011 00:06:05 -0700 Received: from localhost ([127.0.0.1] helo=lists.colo.xensource.com) by lists.xensource.com with esmtp (Exim 4.43) id 1R6zpl-0006Tj-Np; Fri, 23 Sep 2011 00:06:05 -0700 Received: from mail216.messagelabs.com ([85.158.143.99]) by lists.xensource.com with esmtp (Exim 4.43) id 1R6znn-00063h-K1 for xen-devel@lists.xensource.com; Fri, 23 Sep 2011 00:04:09 -0700 X-Env-Sender: JBeulich@suse.com X-Msg-Ref: server-7.tower-216.messagelabs.com!1316761439!19308610!1 X-Originating-IP: [130.57.49.28] X-StarScan-Version: 6.4.1; banners=-,-,- X-VirusChecked: Checked Received: (qmail 4495 invoked from network); 23 Sep 2011 07:04:00 -0000 Received: from nat28.tlf.novell.com (HELO nat28.tlf.novell.com) (130.57.49.28) by server-7.tower-216.messagelabs.com with DHE-RSA-AES256-SHA encrypted SMTP; 23 Sep 2011 07:04:00 -0000 Received: from EMEA1-MTA by nat28.tlf.novell.com with Novell_GroupWise; Fri, 23 Sep 2011 08:03:59 +0100 Message-Id: <4E7C4B9902000078000577B4@nat28.tlf.novell.com> X-Mailer: Novell GroupWise Internet Agent 8.0.1 Date: Fri, 23 Sep 2011 08:04:24 +0100 From: "Jan Beulich" <JBeulich@suse.com> To: <ian.jackson@eu.citrix.com>,<xen-devel@lists.xensource.com> Subject: Re: [Xen-devel] [xen-unstable test] 9005: regressions - FAIL References: <osstest-9005-mainreport@xen.org> In-Reply-To: <osstest-9005-mainreport@xen.org> Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: quoted-printable Content-Disposition: inline Cc: X-BeenThere: xen-devel@lists.xensource.com X-Mailman-Version: 2.1.5 Precedence: list List-Id: Xen developer discussion <xen-devel.lists.xensource.com> List-Unsubscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe> List-Post: <mailto:xen-devel@lists.xensource.com> List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help> List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=subscribe> Sender: xen-devel-bounces@lists.xensource.com Errors-To: xen-devel-bounces@lists.xensource.com >>> On 23.09.11 at 05:57, xen.org <ian.jackson@eu.citrix.com> wrote: > flight 9005 xen-unstable real [real] > http://www.chiark.greenend.org.uk/~xensrcts/logs/9005/=20 >=20 > Regressions :-( >=20 > Tests which did not succeed and are blocking: > test-amd64-i386-rhel6hvm-amd 5 xen-boot fail REGR. = vs. 8995 > test-i386-i386-pv 5 xen-boot fail REGR. = vs. 8995 > test-amd64-amd64-xl-win 5 xen-boot fail REGR. = vs. 8995 These must be caused by 23863:9e0259239822, failing only on AMD IOMMU capable systems; looking into it. Jan > Tests which are failing intermittently (not blocking): > test-amd64-amd64-xl 5 xen-boot fail pass = in 9000 > test-amd64-i386-pv 5 xen-boot fail pass = in 9000 > test-amd64-i386-xl-credit2 5 xen-boot fail pass = in 9000 > test-amd64-i386-pair 8 xen-boot/dst_host fail pass = in 9000 > test-amd64-i386-pair 7 xen-boot/src_host fail pass = in 9000 > test-amd64-amd64-pair 8 xen-boot/dst_host fail pass = in 9000 > test-amd64-amd64-pair 7 xen-boot/src_host fail pass = in 9000 > test-amd64-amd64-pv 5 xen-boot fail in 9000 pass = in 9005 > test-amd64-i386-xl-multivcpu 5 xen-boot fail in 9000 pass = in 9005 > test-amd64-i386-xl-win-vcpus1 5 xen-boot fail in 9000 pass = in 9005 > test-i386-i386-win 5 xen-boot fail in 9000 pass = in 9005 > test-i386-i386-pair 8 xen-boot/dst_host fail in 9000 pass = in 9005 > test-i386-i386-pair 7 xen-boot/src_host fail in 9000 pass = in 9005 > test-amd64-i386-win-vcpus1 5 xen-boot fail in 9000 pass = in 9005 >=20 > Tests which did not succeed, but are not blocking, > including regressions (tests previously passed) regarded as allowable: > test-amd64-amd64-xl-pcipt-intel 9 guest-start fail = never pass > test-amd64-i386-rhel6hvm-intel 9 guest-start.2 fail = never pass > test-amd64-i386-xl-win-vcpus1 13 guest-stop fail = never pass > test-i386-i386-win 16 leak-check/check fail = never pass > test-i386-i386-xl-win 13 guest-stop fail = never pass > test-amd64-amd64-win 16 leak-check/check fail = never pass > test-amd64-i386-win-vcpus1 16 leak-check/check fail = never pass > test-amd64-i386-win 16 leak-check/check fail = never pass >=20 > version targeted for testing: > xen cc339ab1d917 > baseline version: > xen a422e2a4451e >=20 > ------------------------------------------------------------ > People who touched revisions under test: > Andreas Herrmann <herrmann.der.user@googlemail.com> > Ian Campbell <ian.campbell@citrix.com> > Ian Jackson <ian.jackson@eu.citrix.com> > Jan Beulich <jbeulich@suse.com> > Lasse Collin <lasse.collin@tukaani.org> > Olaf Hering <olaf@aepfle.de> > Thomas Renninger <trenn@suse.de> > ------------------------------------------------------------ >=20 > jobs: > build-amd64 pass =20 > build-i386 pass =20 > build-amd64-oldkern pass =20 > build-i386-oldkern pass =20 > build-amd64-pvops pass =20 > build-i386-pvops pass =20 > test-amd64-amd64-xl fail =20 > test-amd64-i386-xl pass =20 > test-i386-i386-xl pass =20 > test-amd64-i386-rhel6hvm-amd fail =20 > test-amd64-i386-xl-credit2 fail =20 > test-amd64-amd64-xl-pcipt-intel fail =20 > test-amd64-i386-rhel6hvm-intel fail =20 > test-amd64-i386-xl-multivcpu pass =20 > test-amd64-amd64-pair fail =20 > test-amd64-i386-pair fail =20 > test-i386-i386-pair pass =20 > test-amd64-amd64-pv pass =20 > test-amd64-i386-pv fail =20 > test-i386-i386-pv fail =20 > test-amd64-amd64-xl-sedf pass =20 > test-amd64-i386-win-vcpus1 fail =20 > test-amd64-i386-xl-win-vcpus1 fail =20 > test-amd64-amd64-win fail =20 > test-amd64-i386-win fail =20 > test-i386-i386-win fail =20 > test-amd64-amd64-xl-win fail =20 > test-i386-i386-xl-win fail =20 >=20 >=20 > ------------------------------------------------------------ > sg-report-flight on woking.cam.xci-test.com > logs: /home/xc_osstest/logs > images: /home/xc_osstest/images >=20 > Logs, config files, etc. are available at > http://www.chiark.greenend.org.uk/~xensrcts/logs=20 >=20 > Test harness code can be found at > http://xenbits.xensource.com/gitweb?p=3Dosstest.git;a=3Dsummary=20 >=20 >=20 > Not pushing. >=20 > ------------------------------------------------------------ > changeset: 23872:cc339ab1d917 > tag: tip > user: Ian Campbell <ian.campbell@citrix.com> > date: Thu Sep 22 18:37:06 2011 +0100 > =20 > tools: fix install of lomount > =20 > $(BIN) went away in 23124:e3d4c34b14a3. > =20 > Also there are no *.so, *.a or *.rpm built in here > =20 > Signed-off-by: Ian Campbell <ian.campbell@citrix.com> > =20 > =20 > changeset: 23871:503ee256fecf > user: Jan Beulich <jbeulich@suse.com> > date: Thu Sep 22 18:35:30 2011 +0100 > =20 > x86: ucode-amd: Don't warn when no ucode is available for a CPU = revision > =20 > This patch originally comes from the Linus mainline kernel (2.6.33), > find below the patch details: > =20 > From: Andreas Herrmann <herrmann.der.user@googlemail.com> > =20 > There is no point in warning when there is no ucode available > for a specific CPU revision. Currently the container-file, which > provides the AMD ucode patches for OS load, contains only a few > ucode patches. > =20 > It's already clearly indicated by the printed patch_level > whenever new ucode was available and an update happened. So the > warning message is of no help but rather annoying on systems > with many CPUs. > =20 > Signed-off-by: Thomas Renninger <trenn@suse.de> > Signed-off-by: Jan Beulich <jbeulich@suse.com> > =20 > =20 > changeset: 23870:5c97b02f48fc > user: Jan Beulich <jbeulich@suse.com> > date: Thu Sep 22 18:34:27 2011 +0100 > =20 > XZ: Fix incorrect XZ_BUF_ERROR > =20 > From: Lasse Collin <lasse.collin@tukaani.org> > =20 > xz_dec_run() could incorrectly return XZ_BUF_ERROR if all of the > following was true: > =20 > - The caller knows how many bytes of output to expect and only > provides > that much output space. > =20 > - When the last output bytes are decoded, the caller-provided input > buffer ends right before the LZMA2 end of payload marker. So = LZMA2 > won't provide more output anymore, but it won't know it yet and > thus > won't return XZ_STREAM_END yet. > =20 > - A BCJ filter is in use and it hasn't left any unfiltered bytes in > the > temp buffer. This can happen with any BCJ filter, but in = practice > it's more likely with filters other than the x86 BCJ. > =20 > This fixes <https://bugzilla.redhat.com/show_bug.cgi?id=3D3D735408> > where Squashfs thinks that a valid file system is corrupt. > =20 > This also fixes a similar bug in single-call mode where the > uncompressed size of a block using BCJ + LZMA2 was 0 bytes and = caller > provided no output space. Many empty .xz files don't contain any > blocks and thus don't trigger this bug. > =20 > This also tweaks a closely related detail: xz_dec_bcj_run() could = call > xz_dec_lzma2_run() to decode into temp buffer when it was known to = be > useless. This was harmless although it wasted a minuscule number of > CPU cycles. > =20 > Signed-off-by: Lasse Collin <lasse.collin@tukaani.org> > Signed-off-by: Jan Beulich <jbeulich@suse.com> > =20 > =20 > changeset: 23869:db1ea4b127cd > user: Jan Beulich <jbeulich@suse.com> > date: Thu Sep 22 18:33:48 2011 +0100 > =20 > XZ decompressor: Fix decoding of empty LZMA2 streams > =20 > From: Lasse Collin <lasse.collin@tukaani.org> > =20 > The old code considered valid empty LZMA2 streams to be corrupt. > Note that a typical empty .xz file has no LZMA2 data at all, > and thus most .xz files having no uncompressed data are handled > correctly even without this fix. > =20 > Signed-off-by: Lasse Collin <lasse.collin@tukaani.org> > Signed-off-by: Jan Beulich <jbeulich@suse.com> > =20 > =20 > changeset: 23868:28147fd781af > user: Jan Beulich <jbeulich@suse.com> > date: Thu Sep 22 18:32:34 2011 +0100 > =20 > VT-d: fix off-by-one error in RMRR validation > =20 > (base_addr,end_addr) is an inclusive range, and hence there = shouldn't > be a subtraction of 1 in the second invocation of page_is_ram_type().= > For RMRRs covering a single page that actually resulted in the > immediately preceding page to get checked (which could have resulted > in a false warning). > =20 > Signed-off-by: Jan Beulich <jbeulich@suse.com> > =20 > =20 > changeset: 23867:571b6e90dfb4 > user: Jan Beulich <jbeulich@suse.com> > date: Thu Sep 22 18:31:44 2011 +0100 > =20 > VT-d: eliminate a mis-use of pcidevs_lock > =20 > dma_pte_clear_one() shouldn't acquire this global lock for the = purpose > of processing a per-domain list. Furthermore the function a few = lines > earlier has a comment stating that acquiring pcidevs_lock isn't > necessary here (whether that's really correct is another question). > =20 > Use the domain's mappin_lock instead to protect the mapped_rmrrs = list. > Fold domain_rmrr_mapped() into its sole caller so that the otherwise > implicit dependency on pcidevs_lock there becomes more obvious (see > the comment there). > =20 > Signed-off-by: Jan Beulich <jbeulich@suse.com> > =20 > =20 > changeset: 23866:47ec1d405af9 > user: Jan Beulich <jbeulich@suse.com> > date: Thu Sep 22 18:31:02 2011 +0100 > =20 > x86: IO-APIC code has no dependency on PCI > =20 > The IRQ handling code requires pcidevs_lock to be held only for MSI > interrupts. > =20 > As the handling of which was now fully moved into msi.c (i.e. while > applying fine without, the patch needs to be applied after the one > titled "x86: split MSI IRQ chip"), io_apic.c now also doesn't need = to > include PCI headers anymore. > =20 > Signed-off-by: Jan Beulich <jbeulich@suse.com> > =20 > =20 > changeset: 23865:d6e01c7853cf > user: Jan Beulich <jbeulich@suse.com> > date: Thu Sep 22 18:29:19 2011 +0100 > =20 > PCI multi-seg: config space accessor adjustments > =20 > Signed-off-by: Jan Beulich <jbeulich@suse.com> > =20 > =20 > changeset: 23864:314b147d524d > user: Jan Beulich <jbeulich@suse.com> > date: Thu Sep 22 18:28:38 2011 +0100 > =20 > PCI multi-seg: Pass-through adjustments > =20 > Signed-off-by: Jan Beulich <jbeulich@suse.com> > =20 > =20 > changeset: 23863:9e0259239822 > user: Jan Beulich <jbeulich@suse.com> > date: Thu Sep 22 18:28:03 2011 +0100 > =20 > PCI multi-seg: AMD-IOMMU specific adjustments > =20 > There are two places here where it is entirely unclear to me where = the > necessary PCI segment number should be taken from (as IVMD descriptor= s > don't have such, only IVHD ones do). AMD confirmed that for the time > being it is acceptable to imply that only segment 0 exists. > =20 > Signed-off-by: Jan Beulich <jbeulich@suse.com> > =20 > =20 > changeset: 23862:85418e168527 > user: Jan Beulich <jbeulich@suse.com> > date: Thu Sep 22 18:27:26 2011 +0100 > =20 > PCI multi-seg: VT-d specific adjustments > =20 > Signed-off-by: Jan Beulich <jbeulich@suse.com> > =20 > =20 > changeset: 23861:ec7c81fbe0de > user: Jan Beulich <jbeulich@suse.com> > date: Thu Sep 22 18:26:54 2011 +0100 > =20 > PCI multi-seg: adjust domctl interface > =20 > Again, a couple of directly related functions at once get adjusted = to > account for the segment number. > =20 > Signed-off-by: Jan Beulich <jbeulich@suse.com> > =20 > =20 > changeset: 23860:a422e2a4451e > user: Jan Beulich <jbeulich@suse.com> > date: Sun Sep 18 00:26:52 2011 +0100 > =20 > x86: split MSI IRQ chip > =20 > With the .end() accessor having become optional and noting that > several of the accessors' behavior really depends on the result of > msi_maskable_irq(), the splits the MSI IRQ chip type into two - one > for the maskable ones, and the other for the (MSI only) non-maskable > ones. > =20 > At once the implementation of those methods gets moved from = io_apic.c > to msi.c. > =20 > Signed-off-by: Jan Beulich <jbeulich@suse.com> > =20 > =20 > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > commit cd776ee9408ff127f934a707c1a339ee600bc127 > Author: Ian Jackson <ian.jackson@eu.citrix.com> > Date: Tue Jun 28 13:50:53 2011 +0100 >=20 > qemu-char.c: fix incorrect CONFIG_STUBDOM handling > =20 > qemu-char.c:1123:7: warning: "CONFIG_STUBDOM" is not defined = [-Wundef] > =20 > Signed-off-by: Olaf Hering <olaf@aepfle.de> > Acked-by: Ian Jackson <ian.jackson@eu.citrix.com> >=20 > _______________________________________________ > Xen-devel mailing list > Xen-devel@lists.xensource.com=20 > http://lists.xensource.com/xen-devel=20 _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel From xen-devel-bounces@lists.xensource.com Fri Sep 23 00:20:44 2011 Return-path: <xen-devel-bounces@lists.xensource.com> Envelope-to: www-data@lists.xensource.com Delivery-date: Fri, 23 Sep 2011 00:20:44 -0700 Received: from localhost ([127.0.0.1] helo=lists.colo.xensource.com) by lists.xensource.com with esmtp (Exim 4.43) id 1R703w-00078i-HJ; Fri, 23 Sep 2011 00:20:44 -0700 Received: from mail182.messagelabs.com ([85.158.139.83]) by lists.xensource.com with esmtp (Exim 4.43) id 1R703A-0006wI-IN for xen-devel@lists.xensource.com; Fri, 23 Sep 2011 00:19:57 -0700 X-Env-Sender: Ian.Campbell@eu.citrix.com X-Msg-Ref: server-10.tower-182.messagelabs.com!1316762393!19412345!1 X-Originating-IP: [62.200.22.115] X-StarScan-Version: 6.4.1; banners=-,-,- X-VirusChecked: Checked Received: (qmail 4255 invoked from network); 23 Sep 2011 07:19:53 -0000 Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115) by server-10.tower-182.messagelabs.com with RC4-SHA encrypted SMTP; 23 Sep 2011 07:19:53 -0000 X-IronPort-AV: E=Sophos;i="4.68,427,1312156800"; d="scan'208";a="8021542" Received: from lonpmailmx01.citrite.net ([10.30.203.162]) by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5; 23 Sep 2011 07:19:52 +0000 Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net (10.30.203.162) with Microsoft SMTP Server id 8.3.137.0; Fri, 23 Sep 2011 08:19:52 +0100 Subject: Re: [Xen-devel] xl usage and live migration From: Ian Campbell <Ian.Campbell@citrix.com> To: Vasiliy Tolstov <v.tolstov@selfip.ru> Date: Fri, 23 Sep 2011 08:19:52 +0100 In-Reply-To: <CACaajQvBtiNitzzeEoYXhRoV7eUHXqEL5BQ_59oQqswtHhkz1g@mail.gmail.com> References: <CACaajQvBtiNitzzeEoYXhRoV7eUHXqEL5BQ_59oQqswtHhkz1g@mail.gmail.com> Organization: Citrix Systems, Inc. Content-Type: text/plain; charset="UTF-8" X-Mailer: Evolution 3.0.3- Content-Transfer-Encoding: 7bit Message-ID: <1316762392.23371.83.camel@zakaz.uk.xensource.com> MIME-Version: 1.0 Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com> X-BeenThere: xen-devel@lists.xensource.com X-Mailman-Version: 2.1.5 Precedence: list List-Id: Xen developer discussion <xen-devel.lists.xensource.com> List-Unsubscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe> List-Post: <mailto:xen-devel@lists.xensource.com> List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help> List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=subscribe> Sender: xen-devel-bounces@lists.xensource.com Errors-To: xen-devel-bounces@lists.xensource.com On Fri, 2011-09-23 at 08:00 +0100, Vasiliy Tolstov wrote: > Hello. We try to move from xm to xl usage. And have one question - if > we use xm and xend domain create on destination via xmlrpc interface. > But if we use xl and not run xend, how migration process worked in > this case? (migration guide says that before using xl we need stop > xend and disable it start..) xl migrates over an ssh connection. running "xl migrate $DOM $HOST" will internally run (roughly) "ssh $HOST xl migrate-receive". You can control the precise command with the -s option (see "xl migrate -h"). Ian. _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel From xen-devel-bounces@lists.xensource.com Fri Sep 23 00:25:14 2011 Return-path: <xen-devel-bounces@lists.xensource.com> Envelope-to: www-data@lists.xensource.com Delivery-date: Fri, 23 Sep 2011 00:25:14 -0700 Received: from localhost ([127.0.0.1] helo=lists.colo.xensource.com) by lists.xensource.com with esmtp (Exim 4.43) id 1R708I-0007Z8-3t; Fri, 23 Sep 2011 00:25:14 -0700 Received: from mail182.messagelabs.com ([85.158.139.83]) by lists.xensource.com with esmtp (Exim 4.43) id 1R707m-0007Mp-Sl for xen-devel@lists.xensource.com; Fri, 23 Sep 2011 00:24:43 -0700 X-Env-Sender: JBeulich@suse.com X-Msg-Ref: server-8.tower-182.messagelabs.com!1316762679!19439868!1 X-Originating-IP: [130.57.49.28] X-StarScan-Version: 6.4.1; banners=-,-,- X-VirusChecked: Checked Received: (qmail 6546 invoked from network); 23 Sep 2011 07:24:39 -0000 Received: from nat28.tlf.novell.com (HELO nat28.tlf.novell.com) (130.57.49.28) by server-8.tower-182.messagelabs.com with DHE-RSA-AES256-SHA encrypted SMTP; 23 Sep 2011 07:24:39 -0000 Received: from EMEA1-MTA by nat28.tlf.novell.com with Novell_GroupWise; Fri, 23 Sep 2011 08:24:39 +0100 Message-Id: <4E7C507202000078000577D6@nat28.tlf.novell.com> X-Mailer: Novell GroupWise Internet Agent 8.0.1 Date: Fri, 23 Sep 2011 08:25:06 +0100 From: "Jan Beulich" <JBeulich@suse.com> To: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com> Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="=__Part2C031342.0__=" Subject: [Xen-devel] [PATCH] AMD-IOMMU: fix initialization order (after 23863:9e0259239822) X-BeenThere: xen-devel@lists.xensource.com X-Mailman-Version: 2.1.5 Precedence: list List-Id: Xen developer discussion <xen-devel.lists.xensource.com> List-Unsubscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe> List-Post: <mailto:xen-devel@lists.xensource.com> List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help> List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=subscribe> Sender: xen-devel-bounces@lists.xensource.com Errors-To: xen-devel-bounces@lists.xensource.com This is a MIME message. If you are reading this text, you may want to consider changing to a mail reader or gateway that understands how to properly handle MIME multipart messages. --=__Part2C031342.0__= Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: quoted-printable Content-Disposition: inline That original patch caused alloc_ivrs_mappings() to be called too early, so things get moved back to where they were, just converting the single call there to a loop over all IOMMUs. Signed-off-by: Jan Beulich <jbeulich@suse.com> --- a/xen/drivers/passthrough/amd/iommu_detect.c +++ b/xen/drivers/passthrough/amd/iommu_detect.c @@ -121,10 +121,6 @@ int __init amd_iommu_detect_one_acpi(voi spin_lock_init(&iommu->lock); =20 iommu->seg =3D ivhd_block->pci_segment; - if (alloc_ivrs_mappings(ivhd_block->pci_segment)) { - xfree(iommu); - return -ENOMEM; - } iommu->bdf =3D ivhd_block->header.dev_id; iommu->cap_offset =3D ivhd_block->cap_offset; iommu->mmio_base_phys =3D ivhd_block->mmio_base; --- a/xen/drivers/passthrough/amd/iommu_init.c +++ b/xen/drivers/passthrough/amd/iommu_init.c @@ -769,7 +769,7 @@ int iterate_ivrs_entries(int (*handler)( return rc; } =20 -int __init alloc_ivrs_mappings(u16 seg) +static int __init alloc_ivrs_mappings(u16 seg) { struct ivrs_mappings *ivrs_mappings; int bdf; @@ -881,8 +881,9 @@ int __init amd_iommu_init(void) goto error_out; =20 radix_tree_init(&ivrs_maps); - if ( alloc_ivrs_mappings(0) !=3D 0 ) - goto error_out; + for_each_amd_iommu ( iommu ) + if ( alloc_ivrs_mappings(iommu->seg) !=3D 0 ) + goto error_out; =20 if ( amd_iommu_update_ivrs_mapping_acpi() !=3D 0 ) goto error_out; --- a/xen/include/asm-x86/amd-iommu.h +++ b/xen/include/asm-x86/amd-iommu.h @@ -103,7 +103,6 @@ struct ivrs_mappings { =20 extern unsigned short ivrs_bdf_entries; =20 -int alloc_ivrs_mappings(u16 seg); struct ivrs_mappings *get_ivrs_mappings(u16 seg); int iterate_ivrs_mappings(int (*)(u16 seg, struct ivrs_mappings *)); int iterate_ivrs_entries(int (*)(u16 seg, struct ivrs_mappings *)); --=__Part2C031342.0__= Content-Type: text/plain; name="pci-multi-seg-amd-iommu-fix.patch" Content-Transfer-Encoding: quoted-printable Content-Disposition: attachment; filename="pci-multi-seg-amd-iommu-fix.patch" That original patch caused alloc_ivrs_mappings() to be called too=0Aearly, = so things get moved back to where they were, just converting=0Athe single = call there to a loop over all IOMMUs.=0A=0ASigned-off-by: Jan Beulich = <jbeulich@suse.com>=0A=0A--- a/xen/drivers/passthrough/amd/iommu_detect.c= =0A+++ b/xen/drivers/passthrough/amd/iommu_detect.c=0A@@ -121,10 +121,6 @@ = int __init amd_iommu_detect_one_acpi(voi=0A spin_lock_init(&iommu->lock= );=0A =0A iommu->seg =3D ivhd_block->pci_segment;=0A- if (alloc_ivrs= _mappings(ivhd_block->pci_segment)) {=0A- xfree(iommu);=0A- = return -ENOMEM;=0A- }=0A iommu->bdf =3D ivhd_block->header.dev_id;= =0A iommu->cap_offset =3D ivhd_block->cap_offset;=0A iommu->mmio_ba= se_phys =3D ivhd_block->mmio_base;=0A--- a/xen/drivers/passthrough/amd/iomm= u_init.c=0A+++ b/xen/drivers/passthrough/amd/iommu_init.c=0A@@ -769,7 = +769,7 @@ int iterate_ivrs_entries(int (*handler)(=0A return rc;=0A = }=0A =0A-int __init alloc_ivrs_mappings(u16 seg)=0A+static int __init = alloc_ivrs_mappings(u16 seg)=0A {=0A struct ivrs_mappings *ivrs_mapping= s;=0A int bdf;=0A@@ -881,8 +881,9 @@ int __init amd_iommu_init(void)=0A= goto error_out;=0A =0A radix_tree_init(&ivrs_maps);=0A- if = ( alloc_ivrs_mappings(0) !=3D 0 )=0A- goto error_out;=0A+ = for_each_amd_iommu ( iommu )=0A+ if ( alloc_ivrs_mappings(iommu->seg= ) !=3D 0 )=0A+ goto error_out;=0A =0A if ( amd_iommu_update_= ivrs_mapping_acpi() !=3D 0 )=0A goto error_out;=0A--- a/xen/include= /asm-x86/amd-iommu.h=0A+++ b/xen/include/asm-x86/amd-iommu.h=0A@@ -103,7 = +103,6 @@ struct ivrs_mappings {=0A =0A extern unsigned short ivrs_bdf_entr= ies;=0A =0A-int alloc_ivrs_mappings(u16 seg);=0A struct ivrs_mappings = *get_ivrs_mappings(u16 seg);=0A int iterate_ivrs_mappings(int (*)(u16 seg, = struct ivrs_mappings *));=0A int iterate_ivrs_entries(int (*)(u16 seg, = struct ivrs_mappings *));=0A --=__Part2C031342.0__= Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel --=__Part2C031342.0__=-- From xen-devel-bounces@lists.xensource.com Fri Sep 23 00:40:48 2011 Return-path: <xen-devel-bounces@lists.xensource.com> Envelope-to: www-data@lists.xensource.com Delivery-date: Fri, 23 Sep 2011 00:40:48 -0700 Received: from localhost ([127.0.0.1] helo=lists.colo.xensource.com) by lists.xensource.com with esmtp (Exim 4.43) id 1R70NM-0008NL-HB; Fri, 23 Sep 2011 00:40:48 -0700 Received: from mail182.messagelabs.com ([85.158.139.83]) by lists.xensource.com with smtp (Exim 4.43) id 1R70MU-0008Ac-UT for xen-devel@lists.xensource.com; Fri, 23 Sep 2011 00:39:55 -0700 X-Env-Sender: andreas.olsowski@leuphana.de X-Msg-Ref: server-13.tower-182.messagelabs.com!1316763591!19270607!1 X-Originating-IP: [193.174.46.71] X-StarScan-Version: 6.4.1; banners=-,-,- X-VirusChecked: Checked Received: (qmail 2889 invoked from network); 23 Sep 2011 07:39:51 -0000 Received: from mailhost.leuphana.de (HELO leuphana.de) (193.174.46.71) by server-13.tower-182.messagelabs.com with SMTP; 23 Sep 2011 07:39:51 -0000 Received: from [141.39.215.216] (account aolsowsk@leuphana.de [141.39.215.216] verified) by leuphana.de (CommuniGate Pro SMTP 5.4.1e) with ESMTPSA id 45249797 for xen-devel@lists.xensource.com; Fri, 23 Sep 2011 09:39:51 +0200 Message-ID: <4E7C37BD.2000706@leuphana.de> Date: Fri, 23 Sep 2011 09:39:41 +0200 From: Andreas Olsowski <andreas.olsowski@leuphana.de> User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.2.21) Gecko/20110831 Icedove/3.1.13 MIME-Version: 1.0 To: xen-devel@lists.xensource.com Subject: Re: [Xen-devel] pv guests die after failed migration References: <4E786015.80603@leuphana.de> <1316546879.5182.26.camel@dagon.hellion.org.uk> In-Reply-To: <1316546879.5182.26.camel@dagon.hellion.org.uk> X-BeenThere: xen-devel@lists.xensource.com X-Mailman-Version: 2.1.5 Precedence: list List-Id: Xen developer discussion <xen-devel.lists.xensource.com> List-Unsubscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe> List-Post: <mailto:xen-devel@lists.xensource.com> List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help> List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=subscribe> Content-Type: multipart/mixed; boundary="===============0930202198==" Sender: xen-devel-bounces@lists.xensource.com Errors-To: xen-devel-bounces@lists.xensource.com This is a cryptographically signed message in MIME format. --===============0930202198== Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha1; boundary="------------ms070509090707000808080808" This is a cryptographically signed message in MIME format. --------------ms070509090707000808080808 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: quoted-printable Here is the full procedure: Preparations: root@xenturio1:/var/log/xen# dmsetup ls |grep thiswillfail xen--data-thiswillfail--swap (252, 236) xen--data-thiswillfail--root (252, 235) root@xenturio2:/var/log/xen# dmsetup ls |grep thiswillfail >Server 2 does not have the logical volumes activated. root@xenturio1:/usr/src/linux-2.6-xen# xl create=20 /mnt/vmctrl/xenconfig/thiswillfail.sxp Parsing config file /mnt/vmctrl/xenconfig/thiswillfail.sxp Daemon running with PID 6722 >it is in fact running with pid 6723: root@xenturio1:/usr/src/linux-2.6-xen# ps auxww |grep "xl create" root 6723 0.0 0.0 35616 972 ? Ssl 09:14 0:00 xl=20 create /mnt/vmctrl/xenconfig/thiswillfail.sxp >Lets check the logfiles root@xenturio1:/var/log/xen# cat xen-hotplug.log RTNETLINK answers: Operation not supported RTNETLINK answers: Operation not supported >stupid netlink again, no matter what stuff i load into the kernel that >still pops up ... annoying ... anyway, its a non-issue in this case root@xenturio1:/var/log/xen# cat xl-thiswillfail.log Waiting for domain thiswillfail (domid 5) to die [pid 6723] >Lets not make it wait any longer ;) root@xenturio1:/usr/src/linux-2.6-xen# xl -vvv migrate thiswillfail=20 xenturio2 migration target: Ready to receive domain. Saving to migration stream new xl format (info 0x0/0x0/380) Loading new save file incoming migration stream (new xl fmt info=20 0x0/0x0/380) Savefile contains xl domain config xc: detail: Had 0 unexplained entries in p2m table xc: Saving memory: iter 0 (last sent 0 skipped 0): 133120/133120 100% xc: detail: delta 9499ms, dom0 88%, target 2%, sent 451Mb/s, dirtied=20 1Mb/s 324 pages xc: Saving memory: iter 1 (last sent 130760 skipped 312): 133120/133120=20 100% xc: detail: delta 23ms, dom0 91%, target 0%, sent 455Mb/s, dirtied=20 48Mb/s 34 pages xc: Saving memory: iter 2 (last sent 320 skipped 4): 133120/133120 100% xc: detail: Start last iteration libxl: debug: libxl_dom.c:384:libxl__domain_suspend_common_callback=20 issuing PV suspend request via XenBus control node libxl: debug: libxl_dom.c:389:libxl__domain_suspend_common_callback wait = for the guest to acknowledge suspend request libxl: debug: libxl_dom.c:434:libxl__domain_suspend_common_callback=20 guest acknowledged suspend request libxl: debug: libxl_dom.c:438:libxl__domain_suspend_common_callback wait = for the guest to suspend libxl: debug: libxl_dom.c:450:libxl__domain_suspend_common_callback=20 guest has suspended xc: detail: SUSPEND shinfo 0007fafc xc: detail: delta 206ms, dom0 2%, target 0%, sent 4Mb/s, dirtied 24Mb/s=20 154 pages xc: Saving memory: iter 3 (last sent 30 skipped 4): 133120/133120 100% xc: detail: delta 3ms, dom0 0%, target 0%, sent 1682Mb/s, dirtied=20 1682Mb/s 154 pages xc: detail: Total pages sent=3D 131264 (0.99x) xc: detail: (of which 0 were fixups) xc: detail: All memory is saved xc: detail: Save exit rc=3D0 libxl: error: libxl.c:900:validate_virtual_disk failed to stat=20 /dev/xen-data/thiswillfail-root: No such file or directory cannot add disk 0 to domain: -6 migration target: Domain creation failed (code -3). libxl: error: libxl_utils.c:408:libxl_read_exactly file/stream truncated = reading ready message from migration receiver stream libxl: info: libxl_exec.c:72:libxl_report_child_exitstatus migration=20 target process [6837] exited with error status 3 Migration failed, resuming at sender. >Now see if it really is resumed at sender: root@xenturio1:/usr/src/linux-2.6-xen# xl console thiswillfail PM: freeze of devices complete after 0.207 msecs PM: late freeze of devices complete after 0.058 msecs ------------[ cut here ]------------ kernel BUG at drivers/xen/events.c:1466! invalid opcode: 0000 [#1] SMP CPU 0 Modules linked in: Pid: 6, comm: migration/0 Not tainted 3.0.4-xenU #6 RIP: e030:[<ffffffff8140d574>] [<ffffffff8140d574>]=20 xen_irq_resume+0x224/0x370 RSP: e02b:ffff88001f9fbce0 EFLAGS: 00010082 RAX: ffffffffffffffef RBX: 0000000000000000 RCX: 0000000000000000 RDX: ffff88001f809ea8 RSI: ffff88001f9fbd00 RDI: 0000000000000001 RBP: 0000000000000010 R08: ffffffff81859a00 R09: 0000000000000000 R10: 0000000000000000 R11: 09f911029d74e35b R12: 0000000000000000 R13: 000000000000f0a0 R14: 0000000000000000 R15: ffff88001f9fbd00 FS: 00007ff28f8c8700(0000) GS:ffff88001fec6000(0000) knlGS:0000000000000= 000 CS: e033 DS: 0000 ES: 0000 CR0: 000000008005003b CR2: 00007fff02056048 CR3: 000000001e4d8000 CR4: 0000000000002660 DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 DR3: 0000000000000000 DR6: 00000000ffff0ff0 DR7: 0000000000000400 Process migration/0 (pid: 6, threadinfo ffff88001f9fa000, task=20 ffff88001f9f7170) Stack: ffff88001f9fbd34 ffff88001f9fbd54 0000000000000003 000000000000f100 0000000000000000 0000000000000003 0000000000000000 0000000000000003 ffff88001fa6ddb0 ffffffff8140aa20 ffffffff81859a08 0000000000000000 Call Trace: [<ffffffff8140aa20>] ? gnttab_map+0x100/0x130 [<ffffffff815c2765>] ? _raw_spin_lock+0x5/0x10 [<ffffffff81083e01>] ? cpu_stopper_thread+0x101/0x190 [<ffffffff8140e1f5>] ? xen_suspend+0x75/0xa0 [<ffffffff81083f1b>] ? stop_machine_cpu_stop+0x8b/0xd0 [<ffffffff81083e90>] ? cpu_stopper_thread+0x190/0x190 [<ffffffff81083dd0>] ? cpu_stopper_thread+0xd0/0x190 [<ffffffff815c0870>] ? schedule+0x270/0x6c0 [<ffffffff81083d00>] ? copy_pid_ns+0x2a0/0x2a0 [<ffffffff81065846>] ? kthread+0x96/0xa0 [<ffffffff815c4024>] ? kernel_thread_helper+0x4/0x10 [<ffffffff815c3436>] ? int_ret_from_sys_call+0x7/0x1b [<ffffffff815c2be1>] ? retint_restore_args+0x5/0x6 [<ffffffff815c4020>] ? gs_change+0x13/0x13 Code: e8 f2 e9 ff ff 8b 44 24 10 44 89 e6 89 c7 e8 64 e8 ff ff ff c3 83=20 fb 04 0f 84 95 fe ff ff 4a 8b 14 f5 20 95 85 81 e9 68 ff ff ff <0f> 0b=20 eb fe 0f 0b eb fe 48 8b 1d fd 00 42 00 4c 8d 6c 24 20 eb RIP [<ffffffff8140d574>] xen_irq_resume+0x224/0x370 RSP <ffff88001f9fbce0> ---[ end trace 82e2e97d58b5f835 ]--- > And here are the new versions of /var/log/xen root@xenturio1:/var/log/xen# cat xl-thiswillfail.log Waiting for domain thiswillfail (domid 5) to die [pid 6723] Domain 5 is dead Done. Exiting now >target servers /var/log/xen remains empty And that, was 3.0.4-xenU, same goes for 2.6.39-xenU. > Please can you provide full logs from /var/log/xen on both ends. Runni= ng > "xl -vvv migrate" will also produce more stuff on stdout, some of whic= h > may be useful. > > Also please capture the complete guest log in case it is an issue ther= e. I am not quite sure what you mean by "guest log". When you reply to this i should be much quicker to respond, had a hell=20 of a week and didnt really get to check my list-mail until yesterday=20 evening. I guess anyone with 2 machines running xen should easily be able to=20 reproduce this problem. --------------ms070509090707000808080808 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIU3TCC BCEwggMJoAMCAQICAgDHMA0GCSqGSIb3DQEBBQUAMHExCzAJBgNVBAYTAkRFMRwwGgYDVQQK ExNEZXV0c2NoZSBUZWxla29tIEFHMR8wHQYDVQQLExZULVRlbGVTZWMgVHJ1c3QgQ2VudGVy MSMwIQYDVQQDExpEZXV0c2NoZSBUZWxla29tIFJvb3QgQ0EgMjAeFw0wNjEyMTkxMDI5MDBa Fw0xOTA2MzAyMzU5MDBaMFoxCzAJBgNVBAYTAkRFMRMwEQYDVQQKEwpERk4tVmVyZWluMRAw DgYDVQQLEwdERk4tUEtJMSQwIgYDVQQDExtERk4tVmVyZWluIFBDQSBHbG9iYWwgLSBHMDEw ggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQDpm8NnhfkNrvWNVMOWUDU9YuluTO2U 1wBblSJ01CDrNI/W7MAxBAuZgeKmFNJSoCgjhIt0iQReW+DieMF4yxbLKDU5ey2QRdDtoAB6 fL9KDhsAw4bpXCsxEXsM84IkQ4wcOItqaACa7txPeKvSxhObdq3u3ibo7wGvdA/BCaL2a869 080UME/15eOkyGKbghoDJzANAmVgTe3RCSMqljVYJ9N2xnG2kB3E7f81hn1vM7PbD8URwoqD oZRdQWvY0hD1TP3KUazZve+Sg7va64sWVlZDz+HVEz2mHycwzUlU28kTNJpxdcVs6qcLmPkh nSevPqM5OUhqjK3JmfvDEvK9AgMBAAGjgdkwgdYwcAYDVR0fBGkwZzBloGOgYYZfaHR0cDov L3BraS50ZWxlc2VjLmRlL2NnaS1iaW4vc2VydmljZS9hZl9Eb3dubG9hZEFSTC5jcmw/LWNy bF9mb3JtYXQ9WF81MDkmLWlzc3Vlcj1EVF9ST09UX0NBXzIwHQYDVR0OBBYEFEm3xs/oPR9/ 6kR7Eyn38QpwPt5kMB8GA1UdIwQYMBaAFDHDeRu69VPXF+CJei0XbAqzK50zMA4GA1UdDwEB /wQEAwIBBjASBgNVHRMBAf8ECDAGAQH/AgECMA0GCSqGSIb3DQEBBQUAA4IBAQA74Vp3wEgX 3KkY7IGvWonwvSiSpspZGBJw7Cjy565/lizn8l0ZMfYTK3S9vYCyufdnyTmieTvhERHua3iR M347XyYndVNljjNj7s9zw7CSI0khUHUjoR8Y4pSFPT8z6XcgjaK95qGFKUD2P3MyWA0Ja6ba hWzAP7uNZmRWJE6uDT8yNQFb6YyC2XJZT7GGhfF0hVblw/hc843uR7NTBXDn5U2KaYMo4RMJ hp5eyOpYHgwf+aTUWgRo/Sg+iwK2WLX2oSw3VwBnqyNojWOl75lrXP1LVvarQIc01BGSbOyH xQoLBzNytG8MHVQs2FHHzL8w00Ny8TK/jM5JY6gA9/IcMIIFXjCCBEagAwIBAgIEC8pR1jAN BgkqhkiG9w0BAQUFADBaMQswCQYDVQQGEwJERTETMBEGA1UEChMKREZOLVZlcmVpbjEQMA4G A1UECxMHREZOLVBLSTEkMCIGA1UEAxMbREZOLVZlcmVpbiBQQ0EgR2xvYmFsIC0gRzAxMB4X DTA4MDIwNzA5NTAwMFoXDTE5MDYzMDAwMDAwMFowgdMxCzAJBgNVBAYTAkRFMRYwFAYDVQQI Ew1OaWVkZXJzYWNoc2VuMRIwEAYDVQQHEwlMdWVuZWJ1cmcxKDAmBgNVBAoTH0xldXBoYW5h IFVuaXZlcnNpdGFldCBMdWVuZWJ1cmcxIjAgBgNVBAsTGVJlY2hlbi0gdW5kIE1lZGllbnpl bnRydW0xKzApBgNVBAMTIkxldXBoYW5hIFVuaXZlcnNpdGFldCBMdWVuZWJ1cmcgQ0ExHTAb BgkqhkiG9w0BCQEWDmNhQGxldXBoYW5hLmRlMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIB CgKCAQEAqJ+JpHih32+icKiQ2IkbhmFLjAcnK0vrnyOKbn7+1xywhvL3zkraqhQlrqEltTDy 711vIEadOVfhIx8xZYYJ/zg1OCwKUxNbIbjcsIFiOKNbWxI3/yMOsaZpXsCLW7GfHLlLADW1 Cv2gUAdnjJUATcUF3a25Bgr9Lbv+GI+3bY9ydMkGnhFYSL96LLqLxAXzGXL/MAM5t/xK8cc8 +6+mWxHAqO+85Jn+UvS1khVTtZfACrYZKFnAsVHOMM/WRugohq4ue6Jfp65exMM7HKWNPrKn UV0hotcInKFBYywcZrIa2r/6m63nOxl1gHrewxiFWEBvpgMkQ+a7PHhXsMkPdQIDAQABo4IB sDCCAawwEgYDVR0TAQH/BAgwBgEB/wIBATALBgNVHQ8EBAMCAQYwHQYDVR0OBBYEFPThaBk7 GUPHATbRNGKW8/UDoQeMMB8GA1UdIwQYMBaAFEm3xs/oPR9/6kR7Eyn38QpwPt5kMBkGA1Ud EQQSMBCBDmNhQGxldXBoYW5hLmRlMIGIBgNVHR8EgYAwfjA9oDugOYY3aHR0cDovL2NkcDEu cGNhLmRmbi5kZS9nbG9iYWwtcm9vdC1jYS9wdWIvY3JsL2NhY3JsLmNybDA9oDugOYY3aHR0 cDovL2NkcDIucGNhLmRmbi5kZS9nbG9iYWwtcm9vdC1jYS9wdWIvY3JsL2NhY3JsLmNybDCB ogYIKwYBBQUHAQEEgZUwgZIwRwYIKwYBBQUHMAKGO2h0dHA6Ly9jZHAxLnBjYS5kZm4uZGUv Z2xvYmFsLXJvb3QtY2EvcHViL2NhY2VydC9jYWNlcnQuY3J0MEcGCCsGAQUFBzAChjtodHRw Oi8vY2RwMi5wY2EuZGZuLmRlL2dsb2JhbC1yb290LWNhL3B1Yi9jYWNlcnQvY2FjZXJ0LmNy dDANBgkqhkiG9w0BAQUFAAOCAQEAmSFLUEnTM1zmNRfF4TTDRB53iHmBY0OYTlaPJvXXy4f7 jc1Dpz00HiVyFohY9gqo+jbIAm5avSCmhbL9glEWubE/BNZz9l9lyTCMMxFES0TCiC6W86Ev o9E4C5IEqxZAOlvRyM3w3u8ItBO9cG190/XMi1Ouk3iBfwRVvFINy9Favq+/8HWFwkFrphpy 6JR90AbbjtE7b7owcMxusgFtPi8A1uyc3cpR21f51K7qgmGbsyXso+U9c/8Fak0IM0qQTN7p GPmI1lfJ0x1r/QusHVYSFojAT2vQamfGeCNVELg/gH4tlTGkDbHW5QhInkASQv4obBYewNfR rLG4wgPz5TCCBacwggSPoAMCAQICBBDuKTAwDQYJKoZIhvcNAQEFBQAwgdMxCzAJBgNVBAYT AkRFMRYwFAYDVQQIEw1OaWVkZXJzYWNoc2VuMRIwEAYDVQQHEwlMdWVuZWJ1cmcxKDAmBgNV BAoTH0xldXBoYW5hIFVuaXZlcnNpdGFldCBMdWVuZWJ1cmcxIjAgBgNVBAsTGVJlY2hlbi0g dW5kIE1lZGllbnplbnRydW0xKzApBgNVBAMTIkxldXBoYW5hIFVuaXZlcnNpdGFldCBMdWVu ZWJ1cmcgQ0ExHTAbBgkqhkiG9w0BCQEWDmNhQGxldXBoYW5hLmRlMB4XDTEwMTEwMTExNTky OVoXDTEzMTAzMTExNTkyOVowajELMAkGA1UEBhMCREUxKDAmBgNVBAoTH0xldXBoYW5hIFVu aXZlcnNpdGFldCBMdWVuZWJ1cmcxFjAUBgNVBAsTDVJlY2hlbnplbnRydW0xGTAXBgNVBAMT EEFuZHJlYXMgT2xzb3dza2kwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQDBzfnZ 7pbsecrmresa6JNTMmgoBFpwyr7k7U5O+j7QlFvMlePF/Tz7TeULaEevf7H68IiA/6oGZQvg NReD/64PYXxbKfsJydY6W1K+jq2karofhW5bk5p210DEQv4qyV6M+aJRKxW0Hp32OeLk5QUH 9T2780PELXGn222r+NCSmBKLP0MHsUa6CFI+jRqztB60v+wc9TD6crMEB37ddckq7mS3QWk1 m2/68bmCsHWRLTpWn9hT4S8eBSL/3YLR9DF8kfWl0wEgy8/tJY1nz5IlSI3S2v1ys7rwXBAp YHRpeHM/WNNNV4kiH09g2vlxFebQN0xTyoO1+PX6iPeAh0NbAgMBAAGjggHpMIIB5TAJBgNV HRMEAjAAMAsGA1UdDwQEAwIF4DApBgNVHSUEIjAgBggrBgEFBQcDAgYIKwYBBQUHAwQGCisG AQQBgjcUAgIwHQYDVR0OBBYEFMrca499fLnPczMLjRm2Nck06YCyMB8GA1UdIwQYMBaAFPTh aBk7GUPHATbRNGKW8/UDoQeMMCcGA1UdEQQgMB6BHGFuZHJlYXMub2xzb3dza2lAbGV1cGhh bmEuZGUwgY0GA1UdHwSBhTCBgjA/oD2gO4Y5aHR0cDovL2NkcDEucGNhLmRmbi5kZS91bmkt bHVlbmVidXJnLWNhL3B1Yi9jcmwvY2FjcmwuY3JsMD+gPaA7hjlodHRwOi8vY2RwMi5wY2Eu ZGZuLmRlL3VuaS1sdWVuZWJ1cmctY2EvcHViL2NybC9jYWNybC5jcmwwgaYGCCsGAQUFBwEB BIGZMIGWMEkGCCsGAQUFBzAChj1odHRwOi8vY2RwMS5wY2EuZGZuLmRlL3VuaS1sdWVuZWJ1 cmctY2EvcHViL2NhY2VydC9jYWNlcnQuY3J0MEkGCCsGAQUFBzAChj1odHRwOi8vY2RwMi5w Y2EuZGZuLmRlL3VuaS1sdWVuZWJ1cmctY2EvcHViL2NhY2VydC9jYWNlcnQuY3J0MA0GCSqG SIb3DQEBBQUAA4IBAQANa3ZG/UAmpRcAXqOFOKXBfzN9vZilIdAUxSaXzN9gmXBNptDEcLfD ccoA228Qc0BSdpvqMdE/21ahqE6oYI1CTfqbuYdoi/cmGoXo6+MdKCKxAD9LokkHdZFhr8re NrsVkqxyY++Cek777HKZWn1Ft9864LA6vDar3K/sUHlBNxO6VhVzt09NQIFrA50lCkNd6iCG 7Hji624SI49aWjzysBOBdcP68tzSYM+nJLod1NZ3S/W3v+IlPlMeu1JZ5hRnzoTC5qHKKdoQ kwSmQmv8/uXD46TXutmLXxH3SyBUIM4ks6RN8+VbJ9+61nOQjtazZzvgz9cnYquQC9Dm2s+q MIIFpzCCBI+gAwIBAgIEEO4pMDANBgkqhkiG9w0BAQUFADCB0zELMAkGA1UEBhMCREUxFjAU BgNVBAgTDU5pZWRlcnNhY2hzZW4xEjAQBgNVBAcTCUx1ZW5lYnVyZzEoMCYGA1UEChMfTGV1 cGhhbmEgVW5pdmVyc2l0YWV0IEx1ZW5lYnVyZzEiMCAGA1UECxMZUmVjaGVuLSB1bmQgTWVk aWVuemVudHJ1bTErMCkGA1UEAxMiTGV1cGhhbmEgVW5pdmVyc2l0YWV0IEx1ZW5lYnVyZyBD QTEdMBsGCSqGSIb3DQEJARYOY2FAbGV1cGhhbmEuZGUwHhcNMTAxMTAxMTE1OTI5WhcNMTMx MDMxMTE1OTI5WjBqMQswCQYDVQQGEwJERTEoMCYGA1UEChMfTGV1cGhhbmEgVW5pdmVyc2l0 YWV0IEx1ZW5lYnVyZzEWMBQGA1UECxMNUmVjaGVuemVudHJ1bTEZMBcGA1UEAxMQQW5kcmVh cyBPbHNvd3NraTCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAMHN+dnulux5yuat 6xrok1MyaCgEWnDKvuTtTk76PtCUW8yV48X9PPtN5QtoR69/sfrwiID/qgZlC+A1F4P/rg9h fFsp+wnJ1jpbUr6OraRquh+FbluTmnbXQMRC/irJXoz5olErFbQenfY54uTlBQf1PbvzQ8Qt cafbbav40JKYEos/QwexRroIUj6NGrO0HrS/7Bz1MPpyswQHft11ySruZLdBaTWbb/rxuYKw dZEtOlaf2FPhLx4FIv/dgtH0MXyR9aXTASDLz+0ljWfPkiVIjdLa/XKzuvBcEClgdGl4cz9Y 001XiSIfT2Da+XEV5tA3TFPKg7X49fqI94CHQ1sCAwEAAaOCAekwggHlMAkGA1UdEwQCMAAw CwYDVR0PBAQDAgXgMCkGA1UdJQQiMCAGCCsGAQUFBwMCBggrBgEFBQcDBAYKKwYBBAGCNxQC AjAdBgNVHQ4EFgQUytxrj318uc9zMwuNGbY1yTTpgLIwHwYDVR0jBBgwFoAU9OFoGTsZQ8cB NtE0Ypbz9QOhB4wwJwYDVR0RBCAwHoEcYW5kcmVhcy5vbHNvd3NraUBsZXVwaGFuYS5kZTCB jQYDVR0fBIGFMIGCMD+gPaA7hjlodHRwOi8vY2RwMS5wY2EuZGZuLmRlL3VuaS1sdWVuZWJ1 cmctY2EvcHViL2NybC9jYWNybC5jcmwwP6A9oDuGOWh0dHA6Ly9jZHAyLnBjYS5kZm4uZGUv dW5pLWx1ZW5lYnVyZy1jYS9wdWIvY3JsL2NhY3JsLmNybDCBpgYIKwYBBQUHAQEEgZkwgZYw SQYIKwYBBQUHMAKGPWh0dHA6Ly9jZHAxLnBjYS5kZm4uZGUvdW5pLWx1ZW5lYnVyZy1jYS9w dWIvY2FjZXJ0L2NhY2VydC5jcnQwSQYIKwYBBQUHMAKGPWh0dHA6Ly9jZHAyLnBjYS5kZm4u ZGUvdW5pLWx1ZW5lYnVyZy1jYS9wdWIvY2FjZXJ0L2NhY2VydC5jcnQwDQYJKoZIhvcNAQEF BQADggEBAA1rdkb9QCalFwBeo4U4pcF/M329mKUh0BTFJpfM32CZcE2m0MRwt8NxygDbbxBz QFJ2m+ox0T/bVqGoTqhgjUJN+pu5h2iL9yYahejr4x0oIrEAP0uiSQd1kWGvyt42uxWSrHJj 74J6TvvscplafUW33zrgsDq8Nqvcr+xQeUE3E7pWFXO3T01AgWsDnSUKQ13qIIbseOLrbhIj j1paPPKwE4F1w/ry3NJgz6ckuh3U1ndL9be/4iU+Ux67UlnmFGfOhMLmocop2hCTBKZCa/z+ 5cPjpNe62YtfEfdLIFQgziSzpE3z5Vsn37rWc5CO1rNnO+DP1ydiq5AL0Obaz6oxggSoMIIE pAIBATCB3DCB0zELMAkGA1UEBhMCREUxFjAUBgNVBAgTDU5pZWRlcnNhY2hzZW4xEjAQBgNV BAcTCUx1ZW5lYnVyZzEoMCYGA1UEChMfTGV1cGhhbmEgVW5pdmVyc2l0YWV0IEx1ZW5lYnVy ZzEiMCAGA1UECxMZUmVjaGVuLSB1bmQgTWVkaWVuemVudHJ1bTErMCkGA1UEAxMiTGV1cGhh bmEgVW5pdmVyc2l0YWV0IEx1ZW5lYnVyZyBDQTEdMBsGCSqGSIb3DQEJARYOY2FAbGV1cGhh bmEuZGUCBBDuKTAwCQYFKw4DAhoFAKCCAqAwGAYJKoZIhvcNAQkDMQsGCSqGSIb3DQEHATAc BgkqhkiG9w0BCQUxDxcNMTEwOTIzMDczOTQxWjAjBgkqhkiG9w0BCQQxFgQUmgy6gxyDh6RK ipra9S1ECn8KHWUwXwYJKoZIhvcNAQkPMVIwUDALBglghkgBZQMEAQIwCgYIKoZIhvcNAwcw DgYIKoZIhvcNAwICAgCAMA0GCCqGSIb3DQMCAgFAMAcGBSsOAwIHMA0GCCqGSIb3DQMCAgEo MIHtBgkrBgEEAYI3EAQxgd8wgdwwgdMxCzAJBgNVBAYTAkRFMRYwFAYDVQQIEw1OaWVkZXJz YWNoc2VuMRIwEAYDVQQHEwlMdWVuZWJ1cmcxKDAmBgNVBAoTH0xldXBoYW5hIFVuaXZlcnNp dGFldCBMdWVuZWJ1cmcxIjAgBgNVBAsTGVJlY2hlbi0gdW5kIE1lZGllbnplbnRydW0xKzAp BgNVBAMTIkxldXBoYW5hIFVuaXZlcnNpdGFldCBMdWVuZWJ1cmcgQ0ExHTAbBgkqhkiG9w0B CQEWDmNhQGxldXBoYW5hLmRlAgQQ7ikwMIHvBgsqhkiG9w0BCRACCzGB36CB3DCB0zELMAkG A1UEBhMCREUxFjAUBgNVBAgTDU5pZWRlcnNhY2hzZW4xEjAQBgNVBAcTCUx1ZW5lYnVyZzEo MCYGA1UEChMfTGV1cGhhbmEgVW5pdmVyc2l0YWV0IEx1ZW5lYnVyZzEiMCAGA1UECxMZUmVj aGVuLSB1bmQgTWVkaWVuemVudHJ1bTErMCkGA1UEAxMiTGV1cGhhbmEgVW5pdmVyc2l0YWV0 IEx1ZW5lYnVyZyBDQTEdMBsGCSqGSIb3DQEJARYOY2FAbGV1cGhhbmEuZGUCBBDuKTAwDQYJ KoZIhvcNAQEBBQAEggEAcYet8PLAeJdxcpSYgWPf1I4f550mDuHfvC/BA8dRRJoFajAYU02C oCKIoOcJWHXcnyGHGBO0g9twFw7LVJmaQrmAYDRal1Gw0Lt1Ej2GGycs0BtTBOeXnyQ6Z18x vLyXn+dRLPJbCsY0j4H8HMqEMaorPWklQ/nnUNqOlHfLuS4xpyMc1vea9f2AdGVGwyBIJE3E +4E/SzG50rODWJh0vtR25+kzYgKDiKU5hg92atNjfbJup6CutmTxscGygY5tvL6sSNg/eKwg 13gRJ47RRgFTC0ymfxdGp9tstnY8sWfnQowlfSpTFVnwCFRszIlPff2oe4Zs56MX7vGVUKfc yQAAAAAAAA== --------------ms070509090707000808080808-- --===============0930202198== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel --===============0930202198==-- From xen-devel-bounces@lists.xensource.com Fri Sep 23 00:41:49 2011 Return-path: <xen-devel-bounces@lists.xensource.com> Envelope-to: www-data@lists.xensource.com Delivery-date: Fri, 23 Sep 2011 00:41:49 -0700 Received: from localhost ([127.0.0.1] helo=lists.colo.xensource.com) by lists.xensource.com with esmtp (Exim 4.43) id 1R70OL-0000IO-C3; Fri, 23 Sep 2011 00:41:49 -0700 Received: from mail21.messagelabs.com ([85.158.143.35]) by lists.xensource.com with smtp (Exim 4.43) id 1R70Mt-0008FN-W3 for xen-devel@lists.xensource.com; Fri, 23 Sep 2011 00:40:21 -0700 X-Env-Sender: andreas.olsowski@leuphana.de X-Msg-Ref: server-9.tower-21.messagelabs.com!1316763571!49485789!1 X-Originating-IP: [193.174.46.71] X-StarScan-Version: 6.4.1; banners=-,-,- X-VirusChecked: Checked Received: (qmail 31178 invoked from network); 23 Sep 2011 07:39:31 -0000 Received: from mailhost.leuphana.de (HELO leuphana.de) (193.174.46.71) by server-9.tower-21.messagelabs.com with SMTP; 23 Sep 2011 07:39:31 -0000 Received: from [141.39.215.216] (account aolsowsk@leuphana.de [141.39.215.216] verified) by leuphana.de (CommuniGate Pro SMTP 5.4.1e) with ESMTPSA id 45249806 for xen-devel@lists.xensource.com; Fri, 23 Sep 2011 09:40:16 +0200 Message-ID: <4E7C37D6.7050109@leuphana.de> Date: Fri, 23 Sep 2011 09:40:06 +0200 From: Andreas Olsowski <andreas.olsowski@leuphana.de> User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.2.21) Gecko/20110831 Icedove/3.1.13 MIME-Version: 1.0 To: xen-devel@lists.xensource.com Subject: Re: [Xen-devel] XL: pv guests dont reboot after migration (xen4.1.2-rc2-pre) References: <4E785FDD.40209@leuphana.de> <1316546621.5182.23.camel@dagon.hellion.org.uk> In-Reply-To: <1316546621.5182.23.camel@dagon.hellion.org.uk> X-BeenThere: xen-devel@lists.xensource.com X-Mailman-Version: 2.1.5 Precedence: list List-Id: Xen developer discussion <xen-devel.lists.xensource.com> List-Unsubscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe> List-Post: <mailto:xen-devel@lists.xensource.com> List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help> List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=subscribe> Content-Type: multipart/mixed; boundary="===============0511730532==" Sender: xen-devel-bounces@lists.xensource.com Errors-To: xen-devel-bounces@lists.xensource.com This is a cryptographically signed message in MIME format. --===============0511730532== Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha1; boundary="------------ms000208030402070200060404" This is a cryptographically signed message in MIME format. --------------ms000208030402070200060404 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: quoted-printable On 09/20/2011 09:23 PM, Ian Campbell wrote: > On Tue, 2011-09-20 at 10:41 +0100, Andreas Olsowski wrote: >> A pv guest will not reboot after migration, the guest itself does >> everything right, including the shutdown, but xl does not recreate th= e >> guest, it just shuts it down. > > After the migrate but before the shutdown is there an xl process > associated with the guest? Yes, xl migrate-receive is running, but check this out: root@xenturio1:/var/log/xen# cat xl-thiswillfail.log Waiting for domain thiswillfail (domid 7) to die [pid 7475] root@xenturio1:/usr/src/linux-2.6-xen# xl -vvv migrate thiswillfail=20 xenturio2 migration target: Ready to receive domain. Saving to migration stream new xl format (info 0x0/0x0/380) Loading new save file incoming migration stream (new xl fmt info=20 0x0/0x0/380) Savefile contains xl domain config xc: detail: Had 0 unexplained entries in p2m table xc: Saving memory: iter 0 (last sent 0 skipped 0): 133120/133120 100% xc: detail: delta 9519ms, dom0 94%, target 1%, sent 449Mb/s, dirtied=20 1Mb/s 533 pages xc: Saving memory: iter 1 (last sent 130565 skipped 507): 133120/133120=20 100% xc: detail: delta 39ms, dom0 92%, target 2%, sent 447Mb/s, dirtied=20 28Mb/s 34 pages xc: Saving memory: iter 2 (last sent 533 skipped 0): 133120/133120 100% xc: detail: Start last iteration libxl: debug: libxl_dom.c:384:libxl__domain_suspend_common_callback=20 issuing PV suspend request via XenBus control node libxl: debug: libxl_dom.c:389:libxl__domain_suspend_common_callback wait = for the guest to acknowledge suspend request libxl: debug: libxl_dom.c:434:libxl__domain_suspend_common_callback=20 guest acknowledged suspend request libxl: debug: libxl_dom.c:438:libxl__domain_suspend_common_callback wait = for the guest to suspend libxl: debug: libxl_dom.c:450:libxl__domain_suspend_common_callback=20 guest has suspended xc: detail: SUSPEND shinfo 0007fafc xc: detail: delta 205ms, dom0 3%, target 0%, sent 5Mb/s, dirtied 25Mb/s=20 160 pages xc: Saving memory: iter 3 (last sent 34 skipped 0): 133120/133120 100% xc: detail: delta 3ms, dom0 0%, target 0%, sent 1747Mb/s, dirtied=20 1747Mb/s 160 pages xc: detail: Total pages sent=3D 131292 (0.99x) xc: detail: (of which 0 were fixups) xc: detail: All memory is saved xc: detail: Save exit rc=3D0 migration target: Transfer complete, requesting permission to start domai= n. migration sender: Target has acknowledged transfer. migration sender: Giving target permission to start. migration target: Got permission, starting domain. migration target: Domain started successsfully. migration sender: Target reports successful startup. Migration successful. root@xenturio1:/var/log/xen# cat xl-thiswillfail.log Waiting for domain thiswillfail (domid 7) to die [pid 7475] Domain 7 is dead Done. Exiting now root@xenturio2:/var/log/xen# cat xl-thiswillfail--incoming.log Waiting for domain thiswillfail--incoming (domid 10) to die [pid 5162] root@xenturio2:/var/log/xen# ps auxww |grep -v grep |grep "migrate-rec" root 5162 0.0 0.0 36128 1592 ? Ssl 09:30 0:00 xl=20 migrate-receive root@xenturio2:/var/log/xen# xl console thiswillfail PM: early restore of devices complete after 0.071 msecs PM: restore of devices complete after 14.727 msecs Setting capacity to 10485760 Setting capacity to 2097152 root@thiswillfail:~# init 6 INIT: Switching to runlevel: 6 INIT: Sending processes the TERM signal Using makefile-style concurrent boot in runlevel 6. Asking all remaining processes to terminate...done. All processes ended within 1 seconds....done. Stopping enhanced syslogd: rsyslogd. Saving the system clock. Cannot access the Hardware Clock via any known method. Use the --debug option to see the details of our search for an access=20 method. Deconfiguring network interfaces...Internet Systems Consortium DHCP=20 Client 4.1.1-P1 Copyright 2004-2010 Internet Systems Consortium. All rights reserved. For info, please visit https://www.isc.org/software/dhcp/ Listening on LPF/eth0/00:16:3e:7e:38:fb Sending on LPF/eth0/00:16:3e:7e:38:fb Sending on Socket/fallback DHCPRELEASE on eth0 to 10.19.46.16 port 67 done. Cleaning up ifupdown.... Deactivating swap...done. Will now restart. md: stopping all md devices. Restarting system. root@xenturio2:/var/log/xen# xl list Name ID Mem VCPUs State=20 Time(s) Domain-0 0 4661 8 r-----=20 77471.3 root@xenturio2:/var/log/xen# ps auxww |grep -v grep |grep xl root@xenturio2:/var/log/xen# cat xl-thiswillfail--incoming.log Waiting for domain thiswillfail--incoming (domid 10) to die [pid 5162] Domain 10 is dead Action for shutdown reason code 1 is restart Domain 10 needs to be cleaned up: destroying the domain Done. Rebooting now xc: error: 0-length read: Internal error xc: error: read_exact_timed failed (read rc: 0, errno: 0): Internal error= xc: error: read: p2m_size (0 =3D Success): Internal error ###### # domU config root@xenturio2:/var/log/xen# cat /mnt/vmctrl/xenconfig/thiswillfail.sxp # generated using xen-tool kernel =3D "/boot/vmlinuz-3.0-xenU" ramdisk =3D "/boot/initrd.img-3.0-xenU" name =3D "thiswillfail" memory =3D "512" vcpus =3D "2" vif =3D [ 'bridge=3Dvlanbr27','mac=3Dfe:ff:00:1b:00:06,bridge=3Dmgmtbr27'= ] disk =3D [=20 'phy:/dev/xen-data/thiswillfail-root,xvda1,w','phy:/dev/xen-data/thiswill= fail-swap,xvda2,w'=20 ] root =3D "/dev/xvda1" extra =3D "xencons=3Dhvc0 console=3Dhvc0" This again goes for 2.3.39-xenU and 3.0.4-xenU. I guess the core of the problem is somewhere around this: >xc: error: 0-length read: Internal error >xc: error: read_exact_timed failed (read rc: 0, errno: 0): Internal err= or >xc: error: read: p2m_size (0 =3D Success): Internal error with best regards andreas --------------ms000208030402070200060404 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIU3TCC BCEwggMJoAMCAQICAgDHMA0GCSqGSIb3DQEBBQUAMHExCzAJBgNVBAYTAkRFMRwwGgYDVQQK ExNEZXV0c2NoZSBUZWxla29tIEFHMR8wHQYDVQQLExZULVRlbGVTZWMgVHJ1c3QgQ2VudGVy MSMwIQYDVQQDExpEZXV0c2NoZSBUZWxla29tIFJvb3QgQ0EgMjAeFw0wNjEyMTkxMDI5MDBa Fw0xOTA2MzAyMzU5MDBaMFoxCzAJBgNVBAYTAkRFMRMwEQYDVQQKEwpERk4tVmVyZWluMRAw DgYDVQQLEwdERk4tUEtJMSQwIgYDVQQDExtERk4tVmVyZWluIFBDQSBHbG9iYWwgLSBHMDEw ggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQDpm8NnhfkNrvWNVMOWUDU9YuluTO2U 1wBblSJ01CDrNI/W7MAxBAuZgeKmFNJSoCgjhIt0iQReW+DieMF4yxbLKDU5ey2QRdDtoAB6 fL9KDhsAw4bpXCsxEXsM84IkQ4wcOItqaACa7txPeKvSxhObdq3u3ibo7wGvdA/BCaL2a869 080UME/15eOkyGKbghoDJzANAmVgTe3RCSMqljVYJ9N2xnG2kB3E7f81hn1vM7PbD8URwoqD oZRdQWvY0hD1TP3KUazZve+Sg7va64sWVlZDz+HVEz2mHycwzUlU28kTNJpxdcVs6qcLmPkh nSevPqM5OUhqjK3JmfvDEvK9AgMBAAGjgdkwgdYwcAYDVR0fBGkwZzBloGOgYYZfaHR0cDov L3BraS50ZWxlc2VjLmRlL2NnaS1iaW4vc2VydmljZS9hZl9Eb3dubG9hZEFSTC5jcmw/LWNy bF9mb3JtYXQ9WF81MDkmLWlzc3Vlcj1EVF9ST09UX0NBXzIwHQYDVR0OBBYEFEm3xs/oPR9/ 6kR7Eyn38QpwPt5kMB8GA1UdIwQYMBaAFDHDeRu69VPXF+CJei0XbAqzK50zMA4GA1UdDwEB /wQEAwIBBjASBgNVHRMBAf8ECDAGAQH/AgECMA0GCSqGSIb3DQEBBQUAA4IBAQA74Vp3wEgX 3KkY7IGvWonwvSiSpspZGBJw7Cjy565/lizn8l0ZMfYTK3S9vYCyufdnyTmieTvhERHua3iR M347XyYndVNljjNj7s9zw7CSI0khUHUjoR8Y4pSFPT8z6XcgjaK95qGFKUD2P3MyWA0Ja6ba hWzAP7uNZmRWJE6uDT8yNQFb6YyC2XJZT7GGhfF0hVblw/hc843uR7NTBXDn5U2KaYMo4RMJ hp5eyOpYHgwf+aTUWgRo/Sg+iwK2WLX2oSw3VwBnqyNojWOl75lrXP1LVvarQIc01BGSbOyH xQoLBzNytG8MHVQs2FHHzL8w00Ny8TK/jM5JY6gA9/IcMIIFXjCCBEagAwIBAgIEC8pR1jAN BgkqhkiG9w0BAQUFADBaMQswCQYDVQQGEwJERTETMBEGA1UEChMKREZOLVZlcmVpbjEQMA4G A1UECxMHREZOLVBLSTEkMCIGA1UEAxMbREZOLVZlcmVpbiBQQ0EgR2xvYmFsIC0gRzAxMB4X DTA4MDIwNzA5NTAwMFoXDTE5MDYzMDAwMDAwMFowgdMxCzAJBgNVBAYTAkRFMRYwFAYDVQQI Ew1OaWVkZXJzYWNoc2VuMRIwEAYDVQQHEwlMdWVuZWJ1cmcxKDAmBgNVBAoTH0xldXBoYW5h IFVuaXZlcnNpdGFldCBMdWVuZWJ1cmcxIjAgBgNVBAsTGVJlY2hlbi0gdW5kIE1lZGllbnpl bnRydW0xKzApBgNVBAMTIkxldXBoYW5hIFVuaXZlcnNpdGFldCBMdWVuZWJ1cmcgQ0ExHTAb BgkqhkiG9w0BCQEWDmNhQGxldXBoYW5hLmRlMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIB CgKCAQEAqJ+JpHih32+icKiQ2IkbhmFLjAcnK0vrnyOKbn7+1xywhvL3zkraqhQlrqEltTDy 711vIEadOVfhIx8xZYYJ/zg1OCwKUxNbIbjcsIFiOKNbWxI3/yMOsaZpXsCLW7GfHLlLADW1 Cv2gUAdnjJUATcUF3a25Bgr9Lbv+GI+3bY9ydMkGnhFYSL96LLqLxAXzGXL/MAM5t/xK8cc8 +6+mWxHAqO+85Jn+UvS1khVTtZfACrYZKFnAsVHOMM/WRugohq4ue6Jfp65exMM7HKWNPrKn UV0hotcInKFBYywcZrIa2r/6m63nOxl1gHrewxiFWEBvpgMkQ+a7PHhXsMkPdQIDAQABo4IB sDCCAawwEgYDVR0TAQH/BAgwBgEB/wIBATALBgNVHQ8EBAMCAQYwHQYDVR0OBBYEFPThaBk7 GUPHATbRNGKW8/UDoQeMMB8GA1UdIwQYMBaAFEm3xs/oPR9/6kR7Eyn38QpwPt5kMBkGA1Ud EQQSMBCBDmNhQGxldXBoYW5hLmRlMIGIBgNVHR8EgYAwfjA9oDugOYY3aHR0cDovL2NkcDEu cGNhLmRmbi5kZS9nbG9iYWwtcm9vdC1jYS9wdWIvY3JsL2NhY3JsLmNybDA9oDugOYY3aHR0 cDovL2NkcDIucGNhLmRmbi5kZS9nbG9iYWwtcm9vdC1jYS9wdWIvY3JsL2NhY3JsLmNybDCB ogYIKwYBBQUHAQEEgZUwgZIwRwYIKwYBBQUHMAKGO2h0dHA6Ly9jZHAxLnBjYS5kZm4uZGUv Z2xvYmFsLXJvb3QtY2EvcHViL2NhY2VydC9jYWNlcnQuY3J0MEcGCCsGAQUFBzAChjtodHRw Oi8vY2RwMi5wY2EuZGZuLmRlL2dsb2JhbC1yb290LWNhL3B1Yi9jYWNlcnQvY2FjZXJ0LmNy dDANBgkqhkiG9w0BAQUFAAOCAQEAmSFLUEnTM1zmNRfF4TTDRB53iHmBY0OYTlaPJvXXy4f7 jc1Dpz00HiVyFohY9gqo+jbIAm5avSCmhbL9glEWubE/BNZz9l9lyTCMMxFES0TCiC6W86Ev o9E4C5IEqxZAOlvRyM3w3u8ItBO9cG190/XMi1Ouk3iBfwRVvFINy9Favq+/8HWFwkFrphpy 6JR90AbbjtE7b7owcMxusgFtPi8A1uyc3cpR21f51K7qgmGbsyXso+U9c/8Fak0IM0qQTN7p GPmI1lfJ0x1r/QusHVYSFojAT2vQamfGeCNVELg/gH4tlTGkDbHW5QhInkASQv4obBYewNfR rLG4wgPz5TCCBacwggSPoAMCAQICBBDuKTAwDQYJKoZIhvcNAQEFBQAwgdMxCzAJBgNVBAYT AkRFMRYwFAYDVQQIEw1OaWVkZXJzYWNoc2VuMRIwEAYDVQQHEwlMdWVuZWJ1cmcxKDAmBgNV BAoTH0xldXBoYW5hIFVuaXZlcnNpdGFldCBMdWVuZWJ1cmcxIjAgBgNVBAsTGVJlY2hlbi0g dW5kIE1lZGllbnplbnRydW0xKzApBgNVBAMTIkxldXBoYW5hIFVuaXZlcnNpdGFldCBMdWVu ZWJ1cmcgQ0ExHTAbBgkqhkiG9w0BCQEWDmNhQGxldXBoYW5hLmRlMB4XDTEwMTEwMTExNTky OVoXDTEzMTAzMTExNTkyOVowajELMAkGA1UEBhMCREUxKDAmBgNVBAoTH0xldXBoYW5hIFVu aXZlcnNpdGFldCBMdWVuZWJ1cmcxFjAUBgNVBAsTDVJlY2hlbnplbnRydW0xGTAXBgNVBAMT EEFuZHJlYXMgT2xzb3dza2kwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQDBzfnZ 7pbsecrmresa6JNTMmgoBFpwyr7k7U5O+j7QlFvMlePF/Tz7TeULaEevf7H68IiA/6oGZQvg NReD/64PYXxbKfsJydY6W1K+jq2karofhW5bk5p210DEQv4qyV6M+aJRKxW0Hp32OeLk5QUH 9T2780PELXGn222r+NCSmBKLP0MHsUa6CFI+jRqztB60v+wc9TD6crMEB37ddckq7mS3QWk1 m2/68bmCsHWRLTpWn9hT4S8eBSL/3YLR9DF8kfWl0wEgy8/tJY1nz5IlSI3S2v1ys7rwXBAp YHRpeHM/WNNNV4kiH09g2vlxFebQN0xTyoO1+PX6iPeAh0NbAgMBAAGjggHpMIIB5TAJBgNV HRMEAjAAMAsGA1UdDwQEAwIF4DApBgNVHSUEIjAgBggrBgEFBQcDAgYIKwYBBQUHAwQGCisG AQQBgjcUAgIwHQYDVR0OBBYEFMrca499fLnPczMLjRm2Nck06YCyMB8GA1UdIwQYMBaAFPTh aBk7GUPHATbRNGKW8/UDoQeMMCcGA1UdEQQgMB6BHGFuZHJlYXMub2xzb3dza2lAbGV1cGhh bmEuZGUwgY0GA1UdHwSBhTCBgjA/oD2gO4Y5aHR0cDovL2NkcDEucGNhLmRmbi5kZS91bmkt bHVlbmVidXJnLWNhL3B1Yi9jcmwvY2FjcmwuY3JsMD+gPaA7hjlodHRwOi8vY2RwMi5wY2Eu ZGZuLmRlL3VuaS1sdWVuZWJ1cmctY2EvcHViL2NybC9jYWNybC5jcmwwgaYGCCsGAQUFBwEB BIGZMIGWMEkGCCsGAQUFBzAChj1odHRwOi8vY2RwMS5wY2EuZGZuLmRlL3VuaS1sdWVuZWJ1 cmctY2EvcHViL2NhY2VydC9jYWNlcnQuY3J0MEkGCCsGAQUFBzAChj1odHRwOi8vY2RwMi5w Y2EuZGZuLmRlL3VuaS1sdWVuZWJ1cmctY2EvcHViL2NhY2VydC9jYWNlcnQuY3J0MA0GCSqG SIb3DQEBBQUAA4IBAQANa3ZG/UAmpRcAXqOFOKXBfzN9vZilIdAUxSaXzN9gmXBNptDEcLfD ccoA228Qc0BSdpvqMdE/21ahqE6oYI1CTfqbuYdoi/cmGoXo6+MdKCKxAD9LokkHdZFhr8re NrsVkqxyY++Cek777HKZWn1Ft9864LA6vDar3K/sUHlBNxO6VhVzt09NQIFrA50lCkNd6iCG 7Hji624SI49aWjzysBOBdcP68tzSYM+nJLod1NZ3S/W3v+IlPlMeu1JZ5hRnzoTC5qHKKdoQ kwSmQmv8/uXD46TXutmLXxH3SyBUIM4ks6RN8+VbJ9+61nOQjtazZzvgz9cnYquQC9Dm2s+q MIIFpzCCBI+gAwIBAgIEEO4pMDANBgkqhkiG9w0BAQUFADCB0zELMAkGA1UEBhMCREUxFjAU BgNVBAgTDU5pZWRlcnNhY2hzZW4xEjAQBgNVBAcTCUx1ZW5lYnVyZzEoMCYGA1UEChMfTGV1 cGhhbmEgVW5pdmVyc2l0YWV0IEx1ZW5lYnVyZzEiMCAGA1UECxMZUmVjaGVuLSB1bmQgTWVk aWVuemVudHJ1bTErMCkGA1UEAxMiTGV1cGhhbmEgVW5pdmVyc2l0YWV0IEx1ZW5lYnVyZyBD QTEdMBsGCSqGSIb3DQEJARYOY2FAbGV1cGhhbmEuZGUwHhcNMTAxMTAxMTE1OTI5WhcNMTMx MDMxMTE1OTI5WjBqMQswCQYDVQQGEwJERTEoMCYGA1UEChMfTGV1cGhhbmEgVW5pdmVyc2l0 YWV0IEx1ZW5lYnVyZzEWMBQGA1UECxMNUmVjaGVuemVudHJ1bTEZMBcGA1UEAxMQQW5kcmVh cyBPbHNvd3NraTCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAMHN+dnulux5yuat 6xrok1MyaCgEWnDKvuTtTk76PtCUW8yV48X9PPtN5QtoR69/sfrwiID/qgZlC+A1F4P/rg9h fFsp+wnJ1jpbUr6OraRquh+FbluTmnbXQMRC/irJXoz5olErFbQenfY54uTlBQf1PbvzQ8Qt cafbbav40JKYEos/QwexRroIUj6NGrO0HrS/7Bz1MPpyswQHft11ySruZLdBaTWbb/rxuYKw dZEtOlaf2FPhLx4FIv/dgtH0MXyR9aXTASDLz+0ljWfPkiVIjdLa/XKzuvBcEClgdGl4cz9Y 001XiSIfT2Da+XEV5tA3TFPKg7X49fqI94CHQ1sCAwEAAaOCAekwggHlMAkGA1UdEwQCMAAw CwYDVR0PBAQDAgXgMCkGA1UdJQQiMCAGCCsGAQUFBwMCBggrBgEFBQcDBAYKKwYBBAGCNxQC AjAdBgNVHQ4EFgQUytxrj318uc9zMwuNGbY1yTTpgLIwHwYDVR0jBBgwFoAU9OFoGTsZQ8cB NtE0Ypbz9QOhB4wwJwYDVR0RBCAwHoEcYW5kcmVhcy5vbHNvd3NraUBsZXVwaGFuYS5kZTCB jQYDVR0fBIGFMIGCMD+gPaA7hjlodHRwOi8vY2RwMS5wY2EuZGZuLmRlL3VuaS1sdWVuZWJ1 cmctY2EvcHViL2NybC9jYWNybC5jcmwwP6A9oDuGOWh0dHA6Ly9jZHAyLnBjYS5kZm4uZGUv dW5pLWx1ZW5lYnVyZy1jYS9wdWIvY3JsL2NhY3JsLmNybDCBpgYIKwYBBQUHAQEEgZkwgZYw SQYIKwYBBQUHMAKGPWh0dHA6Ly9jZHAxLnBjYS5kZm4uZGUvdW5pLWx1ZW5lYnVyZy1jYS9w dWIvY2FjZXJ0L2NhY2VydC5jcnQwSQYIKwYBBQUHMAKGPWh0dHA6Ly9jZHAyLnBjYS5kZm4u ZGUvdW5pLWx1ZW5lYnVyZy1jYS9wdWIvY2FjZXJ0L2NhY2VydC5jcnQwDQYJKoZIhvcNAQEF BQADggEBAA1rdkb9QCalFwBeo4U4pcF/M329mKUh0BTFJpfM32CZcE2m0MRwt8NxygDbbxBz QFJ2m+ox0T/bVqGoTqhgjUJN+pu5h2iL9yYahejr4x0oIrEAP0uiSQd1kWGvyt42uxWSrHJj 74J6TvvscplafUW33zrgsDq8Nqvcr+xQeUE3E7pWFXO3T01AgWsDnSUKQ13qIIbseOLrbhIj j1paPPKwE4F1w/ry3NJgz6ckuh3U1ndL9be/4iU+Ux67UlnmFGfOhMLmocop2hCTBKZCa/z+ 5cPjpNe62YtfEfdLIFQgziSzpE3z5Vsn37rWc5CO1rNnO+DP1ydiq5AL0Obaz6oxggSoMIIE pAIBATCB3DCB0zELMAkGA1UEBhMCREUxFjAUBgNVBAgTDU5pZWRlcnNhY2hzZW4xEjAQBgNV BAcTCUx1ZW5lYnVyZzEoMCYGA1UEChMfTGV1cGhhbmEgVW5pdmVyc2l0YWV0IEx1ZW5lYnVy ZzEiMCAGA1UECxMZUmVjaGVuLSB1bmQgTWVkaWVuemVudHJ1bTErMCkGA1UEAxMiTGV1cGhh bmEgVW5pdmVyc2l0YWV0IEx1ZW5lYnVyZyBDQTEdMBsGCSqGSIb3DQEJARYOY2FAbGV1cGhh bmEuZGUCBBDuKTAwCQYFKw4DAhoFAKCCAqAwGAYJKoZIhvcNAQkDMQsGCSqGSIb3DQEHATAc BgkqhkiG9w0BCQUxDxcNMTEwOTIzMDc0MDA2WjAjBgkqhkiG9w0BCQQxFgQUwah+bKv71lFM kApkwFU+UnvJhkYwXwYJKoZIhvcNAQkPMVIwUDALBglghkgBZQMEAQIwCgYIKoZIhvcNAwcw DgYIKoZIhvcNAwICAgCAMA0GCCqGSIb3DQMCAgFAMAcGBSsOAwIHMA0GCCqGSIb3DQMCAgEo MIHtBgkrBgEEAYI3EAQxgd8wgdwwgdMxCzAJBgNVBAYTAkRFMRYwFAYDVQQIEw1OaWVkZXJz YWNoc2VuMRIwEAYDVQQHEwlMdWVuZWJ1cmcxKDAmBgNVBAoTH0xldXBoYW5hIFVuaXZlcnNp dGFldCBMdWVuZWJ1cmcxIjAgBgNVBAsTGVJlY2hlbi0gdW5kIE1lZGllbnplbnRydW0xKzAp BgNVBAMTIkxldXBoYW5hIFVuaXZlcnNpdGFldCBMdWVuZWJ1cmcgQ0ExHTAbBgkqhkiG9w0B CQEWDmNhQGxldXBoYW5hLmRlAgQQ7ikwMIHvBgsqhkiG9w0BCRACCzGB36CB3DCB0zELMAkG A1UEBhMCREUxFjAUBgNVBAgTDU5pZWRlcnNhY2hzZW4xEjAQBgNVBAcTCUx1ZW5lYnVyZzEo MCYGA1UEChMfTGV1cGhhbmEgVW5pdmVyc2l0YWV0IEx1ZW5lYnVyZzEiMCAGA1UECxMZUmVj aGVuLSB1bmQgTWVkaWVuemVudHJ1bTErMCkGA1UEAxMiTGV1cGhhbmEgVW5pdmVyc2l0YWV0 IEx1ZW5lYnVyZyBDQTEdMBsGCSqGSIb3DQEJARYOY2FAbGV1cGhhbmEuZGUCBBDuKTAwDQYJ KoZIhvcNAQEBBQAEggEAlEaKkQIJ4RdjkkvhzPFRglnZebLJ9eWgDIQLtRIfDQ7YU6keEZ3u u+evfEzFVyPm67g/HTNRmuOXkMuds+UaVnwWzbW4Uv026hsiJ4QtyhxSUgal3wxqlu347uIK 1hT1ZH4iI5jk43zM93ruedsWF19Wv3eTQD1mj5pE2LnntWi/r+vbygnCUMXpK/LipRqw+M3K AtgzMVYoaIvLSL6tNbPwuZAk2gLeWBIg7uQQ5ZlWgqWXGF59FATqpphcOknb6Ulo+TI7935+ DJGbdMYILf1r/j9oiu9PIpj4wcWjT7Zicp4J3NuLCc2Q/z9dx3VHG6sw15fL4Aqbu0JdcbEq wgAAAAAAAA== --------------ms000208030402070200060404-- --===============0511730532== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel --===============0511730532==-- From xen-devel-bounces@lists.xensource.com Fri Sep 23 00:48:12 2011 Return-path: <xen-devel-bounces@lists.xensource.com> Envelope-to: www-data@lists.xensource.com Delivery-date: Fri, 23 Sep 2011 00:48:12 -0700 Received: from localhost ([127.0.0.1] helo=lists.colo.xensource.com) by lists.xensource.com with esmtp (Exim 4.43) id 1R70UW-0000qL-Ep; Fri, 23 Sep 2011 00:48:12 -0700 Received: from mail174.messagelabs.com ([85.158.138.51]) by lists.xensource.com with esmtp (Exim 4.43) id 1R70Tp-0000e0-9b for xen-devel@lists.xensource.com; Fri, 23 Sep 2011 00:47:29 -0700 X-Env-Sender: Ian.Campbell@eu.citrix.com X-Msg-Ref: server-5.tower-174.messagelabs.com!1316764045!28762205!1 X-Originating-IP: [62.200.22.115] X-StarScan-Version: 6.4.1; banners=-,-,- X-VirusChecked: Checked Received: (qmail 9535 invoked from network); 23 Sep 2011 07:47:26 -0000 Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115) by server-5.tower-174.messagelabs.com with RC4-SHA encrypted SMTP; 23 Sep 2011 07:47:26 -0000 X-IronPort-AV: E=Sophos;i="4.68,428,1312156800"; d="scan'208";a="8022091" Received: from lonpmailmx01.citrite.net ([10.30.203.162]) by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5; 23 Sep 2011 07:47:25 +0000 Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net (10.30.203.162) with Microsoft SMTP Server id 8.3.137.0; Fri, 23 Sep 2011 08:47:25 +0100 Subject: Re: [Xen-devel] pv guests die after failed migration From: Ian Campbell <Ian.Campbell@citrix.com> To: Andreas Olsowski <andreas.olsowski@leuphana.de> Date: Fri, 23 Sep 2011 08:47:25 +0100 In-Reply-To: <4E7C37BD.2000706@leuphana.de> References: <4E786015.80603@leuphana.de> <1316546879.5182.26.camel@dagon.hellion.org.uk> <4E7C37BD.2000706@leuphana.de> Organization: Citrix Systems, Inc. Content-Type: text/plain; charset="UTF-8" X-Mailer: Evolution 3.0.3- Content-Transfer-Encoding: 7bit Message-ID: <1316764045.23371.100.camel@zakaz.uk.xensource.com> MIME-Version: 1.0 Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com> X-BeenThere: xen-devel@lists.xensource.com X-Mailman-Version: 2.1.5 Precedence: list List-Id: Xen developer discussion <xen-devel.lists.xensource.com> List-Unsubscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe> List-Post: <mailto:xen-devel@lists.xensource.com> List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help> List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=subscribe> Sender: xen-devel-bounces@lists.xensource.com Errors-To: xen-devel-bounces@lists.xensource.com On Fri, 2011-09-23 at 08:39 +0100, Andreas Olsowski wrote: > Here is the full procedure: [...] Thanks, I should be able to figure out a repro with this, although I may not get to it straight away. > root@xenturio1:/usr/src/linux-2.6-xen# xl console thiswillfail > PM: freeze of devices complete after 0.207 msecs > PM: late freeze of devices complete after 0.058 msecs > ------------[ cut here ]------------ > kernel BUG at drivers/xen/events.c:1466! > invalid opcode: 0000 [#1] SMP > CPU 0 > Modules linked in: > > Pid: 6, comm: migration/0 Not tainted 3.0.4-xenU #6 > RIP: e030:[<ffffffff8140d574>] [<ffffffff8140d574>] > xen_irq_resume+0x224/0x370 > RSP: e02b:ffff88001f9fbce0 EFLAGS: 00010082 > RAX: ffffffffffffffef RBX: 0000000000000000 RCX: 0000000000000000 > RDX: ffff88001f809ea8 RSI: ffff88001f9fbd00 RDI: 0000000000000001 > RBP: 0000000000000010 R08: ffffffff81859a00 R09: 0000000000000000 > R10: 0000000000000000 R11: 09f911029d74e35b R12: 0000000000000000 > R13: 000000000000f0a0 R14: 0000000000000000 R15: ffff88001f9fbd00 > FS: 00007ff28f8c8700(0000) GS:ffff88001fec6000(0000) knlGS:0000000000000000 > CS: e033 DS: 0000 ES: 0000 CR0: 000000008005003b > CR2: 00007fff02056048 CR3: 000000001e4d8000 CR4: 0000000000002660 > DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 > DR3: 0000000000000000 DR6: 00000000ffff0ff0 DR7: 0000000000000400 > Process migration/0 (pid: 6, threadinfo ffff88001f9fa000, task > ffff88001f9f7170) > Stack: > ffff88001f9fbd34 ffff88001f9fbd54 0000000000000003 000000000000f100 > 0000000000000000 0000000000000003 0000000000000000 0000000000000003 > ffff88001fa6ddb0 ffffffff8140aa20 ffffffff81859a08 0000000000000000 > Call Trace: > [<ffffffff8140aa20>] ? gnttab_map+0x100/0x130 > [<ffffffff815c2765>] ? _raw_spin_lock+0x5/0x10 > [<ffffffff81083e01>] ? cpu_stopper_thread+0x101/0x190 > [<ffffffff8140e1f5>] ? xen_suspend+0x75/0xa0 > [<ffffffff81083f1b>] ? stop_machine_cpu_stop+0x8b/0xd0 > [<ffffffff81083e90>] ? cpu_stopper_thread+0x190/0x190 > [<ffffffff81083dd0>] ? cpu_stopper_thread+0xd0/0x190 > [<ffffffff815c0870>] ? schedule+0x270/0x6c0 > [<ffffffff81083d00>] ? copy_pid_ns+0x2a0/0x2a0 > [<ffffffff81065846>] ? kthread+0x96/0xa0 > [<ffffffff815c4024>] ? kernel_thread_helper+0x4/0x10 > [<ffffffff815c3436>] ? int_ret_from_sys_call+0x7/0x1b > [<ffffffff815c2be1>] ? retint_restore_args+0x5/0x6 > [<ffffffff815c4020>] ? gs_change+0x13/0x13 > Code: e8 f2 e9 ff ff 8b 44 24 10 44 89 e6 89 c7 e8 64 e8 ff ff ff c3 83 > fb 04 0f 84 95 fe ff ff 4a 8b 14 f5 20 95 85 81 e9 68 ff ff ff <0f> 0b > eb fe 0f 0b eb fe 48 8b 1d fd 00 42 00 4c 8d 6c 24 20 eb > RIP [<ffffffff8140d574>] xen_irq_resume+0x224/0x370 > RSP <ffff88001f9fbce0> > ---[ end trace 82e2e97d58b5f835 ]--- This seems to be taking the non-cancelled resume path, does this patch help at all: diff -r d7b14b76f1eb tools/libxl/libxl.c --- a/tools/libxl/libxl.c Thu Sep 22 14:26:08 2011 +0100 +++ b/tools/libxl/libxl.c Fri Sep 23 08:45:28 2011 +0100 @@ -246,7 +246,7 @@ int libxl_domain_resume(libxl_ctx *ctx, rc = ERROR_NI; goto out; } - if (xc_domain_resume(ctx->xch, domid, 0)) { + if (xc_domain_resume(ctx->xch, domid, 1)) { LIBXL__LOG_ERRNO(ctx, LIBXL__LOG_ERROR, "xc_domain_resume failed for domain %u", domid); I don't think that's a solution but if this patch works then it may indicate a problem with xc_domain_resume_any. [...] > I am not quite sure what you mean by "guest log". The guest console log, which you provided above, thanks. Ian. _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel From xen-devel-bounces@lists.xensource.com Fri Sep 23 01:03:19 2011 Return-path: <xen-devel-bounces@lists.xensource.com> Envelope-to: www-data@lists.xensource.com Delivery-date: Fri, 23 Sep 2011 01:03:19 -0700 Received: from localhost ([127.0.0.1] helo=lists.colo.xensource.com) by lists.xensource.com with esmtp (Exim 4.43) id 1R70j6-00027M-9d; Fri, 23 Sep 2011 01:03:16 -0700 Received: from mail216.messagelabs.com ([85.158.143.99]) by lists.xensource.com with esmtp (Exim 4.43) id 1R70gy-0001ie-RZ for xen-devel@lists.xensource.com; Fri, 23 Sep 2011 01:01:11 -0700 X-Env-Sender: Ian.Campbell@eu.citrix.com X-Msg-Ref: server-4.tower-216.messagelabs.com!1316764860!19289417!1 X-Originating-IP: [62.200.22.115] X-StarScan-Version: 6.4.1; banners=-,-,- X-VirusChecked: Checked Received: (qmail 8086 invoked from network); 23 Sep 2011 08:01:01 -0000 Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115) by server-4.tower-216.messagelabs.com with RC4-SHA encrypted SMTP; 23 Sep 2011 08:01:01 -0000 X-IronPort-AV: E=Sophos;i="4.68,428,1312156800"; d="scan'208";a="8022368" Received: from lonpmailmx01.citrite.net ([10.30.203.162]) by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5; 23 Sep 2011 08:00:45 +0000 Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net (10.30.203.162) with Microsoft SMTP Server id 8.3.137.0; Fri, 23 Sep 2011 09:00:44 +0100 Subject: Re: [Xen-devel] XL: pv guests dont reboot after migration (xen4.1.2-rc2-pre) From: Ian Campbell <Ian.Campbell@citrix.com> To: Andreas Olsowski <andreas.olsowski@leuphana.de> Date: Fri, 23 Sep 2011 09:00:43 +0100 In-Reply-To: <4E7C37D6.7050109@leuphana.de> References: <4E785FDD.40209@leuphana.de> <1316546621.5182.23.camel@dagon.hellion.org.uk> <4E7C37D6.7050109@leuphana.de> Organization: Citrix Systems, Inc. Content-Type: text/plain; charset="UTF-8" X-Mailer: Evolution 3.0.3- Content-Transfer-Encoding: 7bit Message-ID: <1316764843.23371.103.camel@zakaz.uk.xensource.com> MIME-Version: 1.0 Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com> X-BeenThere: xen-devel@lists.xensource.com X-Mailman-Version: 2.1.5 Precedence: list List-Id: Xen developer discussion <xen-devel.lists.xensource.com> List-Unsubscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe> List-Post: <mailto:xen-devel@lists.xensource.com> List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help> List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=subscribe> Sender: xen-devel-bounces@lists.xensource.com Errors-To: xen-devel-bounces@lists.xensource.com On Fri, 2011-09-23 at 08:38 +0100, Andreas Olsowski wrote: I guess the core of the problem is somewhere around this: > >xc: error: 0-length read: Internal error > >xc: error: read_exact_timed failed (read rc: 0, errno: 0): Internal error > >xc: error: read: p2m_size (0 = Success): Internal error > It smells like on reboot it is trying to receive another incoming migration, instead of restarting the domain it already has. This (untested) might help: diff -r d7b14b76f1eb tools/libxl/xl_cmdimpl.c --- a/tools/libxl/xl_cmdimpl.c Thu Sep 22 14:26:08 2011 +0100 +++ b/tools/libxl/xl_cmdimpl.c Fri Sep 23 08:59:36 2011 +0100 @@ -1516,6 +1516,11 @@ start: ret = libxl_domain_create_restore(ctx, &d_config, cb, &child_console_pid, &domid, restore_fd); + /* + * On subsequent reboot etc we should create the domain, not + * restore/migrate-receive it again. + */ + restore_file = NULL; }else{ ret = libxl_domain_create_new(ctx, &d_config, cb, &child_console_pid, &domid); Ian. _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel From xen-devel-bounces@lists.xensource.com Fri Sep 23 01:09:31 2011 Return-path: <xen-devel-bounces@lists.xensource.com> Envelope-to: www-data@lists.xensource.com Delivery-date: Fri, 23 Sep 2011 01:09:31 -0700 Received: from localhost ([127.0.0.1] helo=lists.colo.xensource.com) by lists.xensource.com with esmtp (Exim 4.43) id 1R70p7-0002YX-9Z; Fri, 23 Sep 2011 01:09:29 -0700 Received: from mail174.messagelabs.com ([85.158.138.51]) by lists.xensource.com with esmtp (Exim 4.43) id 1R70o1-0002MG-5R for xen-devel@lists.xensource.com; Fri, 23 Sep 2011 01:08:23 -0700 X-Env-Sender: royger@gmail.com X-Msg-Ref: server-14.tower-174.messagelabs.com!1316765297!32459683!1 X-Originating-IP: [209.85.213.171] X-StarScan-Version: 6.4.1; banners=-,-,- X-VirusChecked: Checked Received: (qmail 26866 invoked from network); 23 Sep 2011 08:08:18 -0000 Received: from mail-yx0-f171.google.com (HELO mail-yx0-f171.google.com) (209.85.213.171) by server-14.tower-174.messagelabs.com with RC4-SHA encrypted SMTP; 23 Sep 2011 08:08:18 -0000 Received: by yxt3 with SMTP id 3so3800434yxt.30 for <xen-devel@lists.xensource.com>; Fri, 23 Sep 2011 01:08:16 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=IfE0nnkHXCwD6d7U0Xvaaocm7owMS23O6klNwdeNr+I=; b=qb2GxawPbWETvDDiYXOXeJ7ZSlP/SN9blxiU05UouvcYfJvtUvnQCLAcC5i21BKeBI I7O8ovR//MciBfsOIqngJYkmamV4TS/Ouz0AuTgkN5QDnt43u/rV7msdNW8xU29glDGF lOpmfgvBYX+M9AETaF27FyY/LoIe2QCpn3Luw= MIME-Version: 1.0 Received: by 10.68.36.232 with SMTP id t8mr8837817pbj.54.1316765296460; Fri, 23 Sep 2011 01:08:16 -0700 (PDT) Received: by 10.142.154.18 with HTTP; Fri, 23 Sep 2011 01:08:16 -0700 (PDT) In-Reply-To: <1316699095.23371.76.camel@zakaz.uk.xensource.com> References: <patchbomb.1316692867@loki> <9e9c68768676b0e1c9c7.1316692873@loki> <1316699095.23371.76.camel@zakaz.uk.xensource.com> Date: Fri, 23 Sep 2011 10:08:16 +0200 X-Google-Sender-Auth: 15qgUDb0pax1k-gOnVhw5seiWpw Message-ID: <CAPLaKK4MagTBFX8TcemdJdb4MzE2gY2OyCovc5u2nExnARTXgg@mail.gmail.com> Subject: Re: [Xen-devel] [PATCH 6 of 6] libxl: use hotplug-status to synchronize the destruction of block devices From: =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= <roger.pau@entel.upc.edu> To: Ian Campbell <Ian.Campbell@citrix.com> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com> X-BeenThere: xen-devel@lists.xensource.com X-Mailman-Version: 2.1.5 Precedence: list List-Id: Xen developer discussion <xen-devel.lists.xensource.com> List-Unsubscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe> List-Post: <mailto:xen-devel@lists.xensource.com> List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help> List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=subscribe> Sender: xen-devel-bounces@lists.xensource.com Errors-To: xen-devel-bounces@lists.xensource.com > I wonder if we can remove the hard coding of the VBD special case > somehow? For example an ops struct in an array mapping DEVICE_* to > =C2=A0 =C2=A0 =C2=A0 =C2=A0int (*watch_for_disconnect)(relevant arguments= ) > =C2=A0 =C2=A0 =C2=A0 =C2=A0int (*has_disconnected)(relevant arguments) > which would have two implementations, one checking state and the other > hotplug-status. This would certainly make the code much cleaner and easy to understand. > That leaves the change in wait_for_dev_destroy which unfortunately > doesn't have the context to do much else than what you've done. Perhaps > that's ok as is until I can finish of the patch series I have which > fixes that aspect. I suppose a function pointer could be encoded in the > XS_WATCH_TOKEN and sscanf'd back out again... This patch it's the best way I came up with to fix the issue without modifying the structure of the code much. If you have any other ideas, I'm glad to try to implement them. Anyway, I will try to implement something similar to what you exposed above and post a patch. Regards, Roger. _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel From xen-devel-bounces@lists.xensource.com Fri Sep 23 01:26:50 2011 Return-path: <xen-devel-bounces@lists.xensource.com> Envelope-to: www-data@lists.xensource.com Delivery-date: Fri, 23 Sep 2011 01:26:50 -0700 Received: from localhost ([127.0.0.1] helo=lists.colo.xensource.com) by lists.xensource.com with esmtp (Exim 4.43) id 1R715u-0003Bl-5S; Fri, 23 Sep 2011 01:26:50 -0700 Received: from mail21.messagelabs.com ([85.158.143.35]) by lists.xensource.com with esmtp (Exim 4.43) id 1R7156-0002zD-6W for xen-devel@lists.xensource.com; Fri, 23 Sep 2011 01:26:00 -0700 X-Env-Sender: olaf@aepfle.de X-Msg-Ref: server-13.tower-21.messagelabs.com!1316766350!50007473!1 X-Originating-IP: [81.169.146.162] X-StarScan-Version: 6.4.1; banners=-,-,- X-VirusChecked: Checked Received: (qmail 20479 invoked from network); 23 Sep 2011 08:25:51 -0000 Received: from mo-p00-ob.rzone.de (HELO mo-p00-ob.rzone.de) (81.169.146.162) by server-13.tower-21.messagelabs.com with DHE-RSA-AES256-SHA encrypted SMTP; 23 Sep 2011 08:25:51 -0000 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; t=1316766356; l=351; s=domk; d=aepfle.de; h=In-Reply-To:Content-Type:MIME-Version:References:Subject:Cc:To:From: Date:X-RZG-CLASS-ID:X-RZG-AUTH; bh=Zx1qs/kZN3Z4AyQs1sLoZ+42GoM=; b=FXEcVHatbMV0MkQ17W+m0AZKMMTjV4cj0U2uUoHGEmG5gT1jL3kqyKLPyTkM2VX7yVv Y7DjurO7Gg9GCO3hPbfNsr+Oq+RDbKsTE2M5p8cDe1qnF/U6OcBQSw+p2KmuPV2DeEgIb ELZuSm+QAIE1xY0TpI6jxQqydQm80JocshY= X-RZG-AUTH: :P2EQZWCpfu+qG7CngxMFH1J+zrwiavkK6tmQaLfmwtM48/lq3s7jFtE= X-RZG-CLASS-ID: mo00 Received: from probook.site (dslb-084-057-077-084.pools.arcor-ip.net [84.57.77.84]) by smtp.strato.de (jimi mo34) (RZmta 26.7) with (DHE-RSA-AES256-SHA encrypted) ESMTPA id j00d63n8N7iumR ; Fri, 23 Sep 2011 10:25:34 +0200 (MEST) Received: by probook.site (Postfix, from userid 1000) id 1E31418B65; Fri, 23 Sep 2011 10:25:34 +0200 (CEST) Date: Fri, 23 Sep 2011 10:25:33 +0200 From: Olaf Hering <olaf@aepfle.de> To: Victor Ling <victor_ling12@yahoo.com> Subject: Re: [Xen-devel] Fw: [Xen-users] DomU kernel panic Message-ID: <20110923082533.GA23525@aepfle.de> References: <1316753968.53802.YahooMailClassic@web114216.mail.gq1.yahoo.com> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline In-Reply-To: <1316753968.53802.YahooMailClassic@web114216.mail.gq1.yahoo.com> User-Agent: Mutt/1.5.21.rev5535 (2011-07-01) Cc: xen-devel@lists.xensource.com X-BeenThere: xen-devel@lists.xensource.com X-Mailman-Version: 2.1.5 Precedence: list List-Id: Xen developer discussion <xen-devel.lists.xensource.com> List-Unsubscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe> List-Post: <mailto:xen-devel@lists.xensource.com> List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help> List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=subscribe> Sender: xen-devel-bounces@lists.xensource.com Errors-To: xen-devel-bounces@lists.xensource.com On Thu, Sep 22, Victor Ling wrote: > Please help if you have any idea. > [ 0.000000] Linux version 2.6.32.12-0.7-xen (geeko@buildhost) (gcc This is the kernel shipped with the SLES11SP1 media. Please enable the update channels in yast/zypper and run the online update to receive all available kernel/xen updates for dom0 and domU. Olaf _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel From xen-devel-bounces@lists.xensource.com Fri Sep 23 02:17:22 2011 Return-path: <xen-devel-bounces@lists.xensource.com> Envelope-to: www-data@lists.xensource.com Delivery-date: Fri, 23 Sep 2011 02:17:22 -0700 Received: from localhost ([127.0.0.1] helo=lists.colo.xensource.com) by lists.xensource.com with esmtp (Exim 4.43) id 1R71so-0004b6-Hm; Fri, 23 Sep 2011 02:17:22 -0700 Received: from mail27.messagelabs.com ([193.109.254.147]) by lists.xensource.com with smtp (Exim 4.43) id 1R71rW-0004Ne-85 for xen-devel@lists.xensource.com; Fri, 23 Sep 2011 02:16:05 -0700 X-Env-Sender: andreas.olsowski@leuphana.de X-Msg-Ref: server-13.tower-27.messagelabs.com!1316769346!41219987!1 X-Originating-IP: [193.174.46.71] X-StarScan-Version: 6.4.1; banners=-,-,- X-VirusChecked: Checked Received: (qmail 8965 invoked from network); 23 Sep 2011 09:15:46 -0000 Received: from mailhost.leuphana.de (HELO leuphana.de) (193.174.46.71) by server-13.tower-27.messagelabs.com with SMTP; 23 Sep 2011 09:15:46 -0000 Received: from [141.39.215.216] (account aolsowsk@leuphana.de [141.39.215.216] verified) by leuphana.de (CommuniGate Pro SMTP 5.4.1e) with ESMTPSA id 45252541; Fri, 23 Sep 2011 11:15:57 +0200 Message-ID: <4E7C4E44.70508@leuphana.de> Date: Fri, 23 Sep 2011 11:15:48 +0200 From: Andreas Olsowski <andreas.olsowski@leuphana.de> User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.2.21) Gecko/20110831 Icedove/3.1.13 MIME-Version: 1.0 To: Ian Campbell <Ian.Campbell@citrix.com> Subject: Re: [Xen-devel] pv guests die after failed migration References: <4E786015.80603@leuphana.de> <1316546879.5182.26.camel@dagon.hellion.org.uk> <4E7C37BD.2000706@leuphana.de> <1316764045.23371.100.camel@zakaz.uk.xensource.com> In-Reply-To: <1316764045.23371.100.camel@zakaz.uk.xensource.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com> X-BeenThere: xen-devel@lists.xensource.com X-Mailman-Version: 2.1.5 Precedence: list List-Id: Xen developer discussion <xen-devel.lists.xensource.com> List-Unsubscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe> List-Post: <mailto:xen-devel@lists.xensource.com> List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help> List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=subscribe> Sender: xen-devel-bounces@lists.xensource.com Errors-To: xen-devel-bounces@lists.xensource.com On 09/23/2011 09:47 AM, Ian Campbell wrote: > This seems to be taking the non-cancelled resume path, does this patch > help at all: > > diff -r d7b14b76f1eb tools/libxl/libxl.c > --- a/tools/libxl/libxl.c Thu Sep 22 14:26:08 2011 +0100 > +++ b/tools/libxl/libxl.c Fri Sep 23 08:45:28 2011 +0100 > @@ -246,7 +246,7 @@ int libxl_domain_resume(libxl_ctx *ctx, > rc = ERROR_NI; > goto out; > } > - if (xc_domain_resume(ctx->xch, domid, 0)) { > + if (xc_domain_resume(ctx->xch, domid, 1)) { > LIBXL__LOG_ERRNO(ctx, LIBXL__LOG_ERROR, > "xc_domain_resume failed for domain %u", > domid); > > I don't think that's a solution but if this patch works then it may > indicate a problem with xc_domain_resume_any. > For the curent xen-4.1-testing.hg the patch had to be modified to a different position: --- a/tools/libxl/libxl.c Thu Sep 22 14:26:08 2011 +0100 +++ b/tools/libxl/libxl.c Fri Sep 23 08:45:28 2011 +0100 @@ -229,7 +229,7 @@ rc = ERROR_NI; goto out; } - if (xc_domain_resume(ctx->xch, domid, 0)) { + if (xc_domain_resume(ctx->xch, domid, 1)) { LIBXL__LOG_ERRNO(ctx, LIBXL__LOG_ERROR, "xc_domain_resume failed for domain %u", domid); I did a clean/make/install after that, compilation worked fine. I then tested the migration towards an unsuitable target again and it did what you thought it could do. The guest resumes correctly at sender ############### root@xenturio1:~# xl -vvv migrate thishopefullywontfail xenturio2 Saving to migration stream new xl format (info 0x0/0x0/407) migration target: Ready to receive domain. Loading new save file incoming migration stream (new xl fmt info 0x0/0x0/407) Savefile contains xl domain config xc: detail: Had 0 unexplained entries in p2m table xc: Saving memory: iter 0 (last sent 0 skipped 0): 133120/133120 100% xc: detail: delta 9529ms, dom0 93%, target 1%, sent 449Mb/s, dirtied 1Mb/s 502 pages xc: Saving memory: iter 1 (last sent 130592 skipped 480): 133120/133120 100% xc: detail: delta 37ms, dom0 91%, target 2%, sent 444Mb/s, dirtied 30Mb/s 34 pages xc: Saving memory: iter 2 (last sent 502 skipped 0): 133120/133120 100% xc: detail: Start last iteration libxl: debug: libxl_dom.c:384:libxl__domain_suspend_common_callback issuing PV suspend request via XenBus control node libxl: debug: libxl_dom.c:389:libxl__domain_suspend_common_callback wait for the guest to acknowledge suspend request libxl: debug: libxl_dom.c:434:libxl__domain_suspend_common_callback guest acknowledged suspend request libxl: debug: libxl_dom.c:438:libxl__domain_suspend_common_callback wait for the guest to suspend libxl: debug: libxl_dom.c:450:libxl__domain_suspend_common_callback guest has suspended xc: detail: SUSPEND shinfo 0007fafc xc: detail: delta 204ms, dom0 3%, target 0%, sent 4Mb/s, dirtied 25Mb/s 156 pages xc: Saving memory: iter 3 (last sent 30 skipped 4): 133120/133120 100% xc: detail: delta 3ms, dom0 0%, target 0%, sent 1703Mb/s, dirtied 1703Mb/s 156 pages xc: detail: Total pages sent= 131280 (0.99x) xc: detail: (of which 0 were fixups) xc: detail: All memory is saved xc: detail: Save exit rc=0 libxl: error: libxl.c:900:validate_virtual_disk failed to stat /dev/xen-data/thishopefullywontfail-root: No such file or directory cannot add disk 0 to domain: -6 migration target: Domain creation failed (code -3). libxl: error: libxl_utils.c:408:libxl_read_exactly file/stream truncated reading ready message from migration receiver stream libxl: info: libxl_exec.c:72:libxl_report_child_exitstatus migration target process [16608] exited with error status 3 Migration failed, resuming at sender. root@xenturio1:~# xl console thishopefullywontfail PM: freeze of devices complete after 0.197 msecs PM: late freeze of devices complete after 0.067 msecs PM: early thaw of devices complete after 0.074 msecs PM: thaw of devices complete after 0.077 msecs root@thishopefullywontfail:~# ##################### So that works There is no mention of the migration failing in the guest log though, maybe when a final patch is made it should log that failing migration? with best regards andreas _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel From xen-devel-bounces@lists.xensource.com Fri Sep 23 02:18:45 2011 Return-path: <xen-devel-bounces@lists.xensource.com> Envelope-to: www-data@lists.xensource.com Delivery-date: Fri, 23 Sep 2011 02:18:45 -0700 Received: from localhost ([127.0.0.1] helo=lists.colo.xensource.com) by lists.xensource.com with esmtp (Exim 4.43) id 1R71u9-0004y8-Ea; Fri, 23 Sep 2011 02:18:45 -0700 Received: from mail27.messagelabs.com ([193.109.254.147]) by lists.xensource.com with smtp (Exim 4.43) id 1R71rW-0004Ng-OC for xen-devel@lists.xensource.com; Fri, 23 Sep 2011 02:16:05 -0700 X-Env-Sender: andreas.olsowski@leuphana.de X-Msg-Ref: server-15.tower-27.messagelabs.com!1316769350!49947892!1 X-Originating-IP: [193.174.46.71] X-StarScan-Version: 6.4.1; banners=-,-,- X-VirusChecked: Checked Received: (qmail 11761 invoked from network); 23 Sep 2011 09:15:50 -0000 Received: from mailhost.leuphana.de (HELO leuphana.de) (193.174.46.71) by server-15.tower-27.messagelabs.com with SMTP; 23 Sep 2011 09:15:50 -0000 Received: from [141.39.215.216] (account aolsowsk@leuphana.de [141.39.215.216] verified) by leuphana.de (CommuniGate Pro SMTP 5.4.1e) with ESMTPSA id 45252537; Fri, 23 Sep 2011 11:15:58 +0200 Message-ID: <4E7C4E45.5080509@leuphana.de> Date: Fri, 23 Sep 2011 11:15:49 +0200 From: Andreas Olsowski <andreas.olsowski@leuphana.de> User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.2.21) Gecko/20110831 Icedove/3.1.13 MIME-Version: 1.0 To: Ian Campbell <Ian.Campbell@citrix.com> Subject: Re: [Xen-devel] XL: pv guests dont reboot after migration (xen4.1.2-rc2-pre) References: <4E785FDD.40209@leuphana.de> <1316546621.5182.23.camel@dagon.hellion.org.uk> <4E7C37D6.7050109@leuphana.de> <1316764843.23371.103.camel@zakaz.uk.xensource.com> In-Reply-To: <1316764843.23371.103.camel@zakaz.uk.xensource.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com> X-BeenThere: xen-devel@lists.xensource.com X-Mailman-Version: 2.1.5 Precedence: list List-Id: Xen developer discussion <xen-devel.lists.xensource.com> List-Unsubscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe> List-Post: <mailto:xen-devel@lists.xensource.com> List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help> List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=subscribe> Sender: xen-devel-bounces@lists.xensource.com Errors-To: xen-devel-bounces@lists.xensource.com On 09/23/2011 10:00 AM, Ian Campbell wrote: > It smells like on reboot it is trying to receive another incoming > migration, instead of restarting the domain it already has. > > This (untested) might help: > > diff -r d7b14b76f1eb tools/libxl/xl_cmdimpl.c > --- a/tools/libxl/xl_cmdimpl.c Thu Sep 22 14:26:08 2011 +0100 > +++ b/tools/libxl/xl_cmdimpl.c Fri Sep 23 08:59:36 2011 +0100 > @@ -1516,6 +1516,11 @@ start: > ret = libxl_domain_create_restore(ctx,&d_config, > cb,&child_console_pid, > &domid, restore_fd); > + /* > + * On subsequent reboot etc we should create the domain, not > + * restore/migrate-receive it again. > + */ > + restore_file = NULL; > }else{ > ret = libxl_domain_create_new(ctx,&d_config, > cb,&child_console_pid,&domid); > > Ian. Patching works. root@xenturio2:/usr/src/xen-4.1-testing.hg# patch -p1 < ../xl-migration-reboot.ian.patch patching file tools/libxl/xl_cmdimpl.c Hunk #1 succeeded at 1520 with fuzz 2 (offset 4 lines). Compilation (clean/make/install) worked fine too. The patch did what you intended for it to do, the guest reboots: ############## root@xenturio2:/usr/src/xen-4.1-testing.hg# xl console thishopefullywontfail PM: early restore of devices complete after 0.068 msecs PM: restore of devices complete after 13.033 msecs Setting capacity to 10485760 Setting capacity to 2097152 root@thishopefullywontfail:~# init 6 INIT: Switching to runlevel: 6 INIT: Sending processes the TERM signal ... usual shutdown ... Restarting system. root@xenturio2:/usr/src/xen-4.1-testing.hg# xl list Name ID Mem VCPUs State Time(s) Domain-0 0 4661 8 r----- 78258.3 thishopefullywontfail 14 512 2 -b---- 2.6 root@xenturio2:/usr/src/xen-4.1-testing.hg# xl console thishopefullywontfail Linux version 3.0.4-xenU (root@xenturio1) (gcc version 4.4.5 (Debian 4.4.5-8) ) #6 SMP Wed Aug 31 17:04:24 CEST 2011 ... usual bootup .... root@thishopefullywontfail:~# ##################### Here is the output of the log: root@xenturio2:/var/log/xen# cat xl-thishopefullywontfail--incoming.log Waiting for domain thishopefullywontfail--incoming (domid 13) to die [pid 14668] Domain 13 is dead Action for shutdown reason code 1 is restart Domain 13 needs to be cleaned up: destroying the domain Done. Rebooting now Waiting for domain thishopefullywontfail (domid 14) to die [pid 14668] with best regards andreas _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel From xen-devel-bounces@lists.xensource.com Fri Sep 23 03:26:18 2011 Return-path: <xen-devel-bounces@lists.xensource.com> Envelope-to: www-data@lists.xensource.com Delivery-date: Fri, 23 Sep 2011 03:26:18 -0700 Received: from localhost ([127.0.0.1] helo=lists.colo.xensource.com) by lists.xensource.com with esmtp (Exim 4.43) id 1R72xU-0006dT-EJ; Fri, 23 Sep 2011 03:26:17 -0700 Received: from mail182.messagelabs.com ([85.158.139.83]) by lists.xensource.com with esmtp (Exim 4.43) id 1R72wO-0006QF-Bh for Xen-devel@lists.xensource.com; Fri, 23 Sep 2011 03:25:08 -0700 X-Env-Sender: Stefano.Stabellini@eu.citrix.com X-Msg-Ref: server-11.tower-182.messagelabs.com!1316773505!19461575!1 X-Originating-IP: [62.200.22.115] X-StarScan-Version: 6.4.1; banners=-,-,- X-VirusChecked: Checked Received: (qmail 19211 invoked from network); 23 Sep 2011 10:25:05 -0000 Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115) by server-11.tower-182.messagelabs.com with RC4-SHA encrypted SMTP; 23 Sep 2011 10:25:05 -0000 X-IronPort-AV: E=Sophos;i="4.68,428,1312156800"; d="scan'208";a="8025916" Received: from lonpmailmx01.citrite.net ([10.30.203.162]) by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5; 23 Sep 2011 10:25:05 +0000 Received: from kaball.uk.xensource.com (10.80.2.59) by LONPMAILMX01.citrite.net (10.30.203.162) with Microsoft SMTP Server id 8.3.137.0; Fri, 23 Sep 2011 11:25:05 +0100 Date: Fri, 23 Sep 2011 11:25:08 +0100 From: Stefano Stabellini <stefano.stabellini@eu.citrix.com> X-X-Sender: sstabellini@kaball-desktop To: Mukesh Rathor <mukesh.rathor@oracle.com> Subject: Re: [Xen-devel] parse_config_data()... In-Reply-To: <20110922190135.44aedd25@mantra.us.oracle.com> Message-ID: <alpine.DEB.2.00.1109231124140.8700@kaball-desktop> References: <20110922113048.2d02f126@mantra.us.oracle.com> <20110922190135.44aedd25@mantra.us.oracle.com> User-Agent: Alpine 2.00 (DEB 1167 2008-08-23) MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Cc: "Xen-devel@lists.xensource.com" <Xen-devel@lists.xensource.com>, Stabellini <Stefano.Stabellini@eu.citrix.com>, Stefano X-BeenThere: xen-devel@lists.xensource.com X-Mailman-Version: 2.1.5 Precedence: list List-Id: Xen developer discussion <xen-devel.lists.xensource.com> List-Unsubscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe> List-Post: <mailto:xen-devel@lists.xensource.com> List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help> List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=subscribe> Sender: xen-devel-bounces@lists.xensource.com Errors-To: xen-devel-bounces@lists.xensource.com On Fri, 23 Sep 2011, Mukesh Rathor wrote: > On Thu, 22 Sep 2011 11:30:48 -0700 > Mukesh Rathor <mukesh.rathor@oracle.com> wrote: > > > Hi Stefano, > > > > In parse_config_data(): > > > > init_create_info(c_info); <--- sets hvm and hap to 1, then:. > > > > c_info->hvm = 0; > > if (!xlu_cfg_get_string (config, "builder", &buf) && > > !strncmp(buf, "hvm", strlen(buf))) > > c_info->hvm = 1; > > > > if (!xlu_cfg_get_long (config, "hap", &l)) <-------- already 1 > > c_info->hap = l; <--- letter 'el' > > > > > > no big deal, but just confusing for someone reading the code... > > > > thanks, > > Mukesh > > Never mind, my bad... thanks, Mukesh > no problems :-) _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel From xen-devel-bounces@lists.xensource.com Fri Sep 23 03:30:31 2011 Return-path: <xen-devel-bounces@lists.xensource.com> Envelope-to: www-data@lists.xensource.com Delivery-date: Fri, 23 Sep 2011 03:30:31 -0700 Received: from localhost ([127.0.0.1] helo=lists.colo.xensource.com) by lists.xensource.com with esmtp (Exim 4.43) id 1R731b-0007As-54; Fri, 23 Sep 2011 03:30:31 -0700 Received: from mail21.messagelabs.com ([85.158.143.35]) by lists.xensource.com with smtp (Exim 4.43) id 1R730r-0006y5-8r for xen-devel@lists.xensource.com; Fri, 23 Sep 2011 03:29:45 -0700 X-Env-Sender: anthony@overnetdata.com X-Msg-Ref: server-6.tower-21.messagelabs.com!1316773762!39361869!1 X-Originating-IP: [81.137.131.225] X-StarScan-Version: 6.4.1; banners=-,-,- X-VirusChecked: Checked Received: (qmail 29286 invoked from network); 23 Sep 2011 10:29:22 -0000 Received: from host81-137-131-225.in-addr.btopenworld.com (HELO zimbra.overnetdata.com) (81.137.131.225) by server-6.tower-21.messagelabs.com with SMTP; 23 Sep 2011 10:29:22 -0000 Received: from localhost (localhost.localdomain [127.0.0.1]) by zimbra.overnetdata.com (Postfix) with ESMTP id D3B2B161880; Fri, 23 Sep 2011 11:29:34 +0100 (BST) X-Virus-Scanned: amavisd-new at overnetdata.com Received: from zimbra.overnetdata.com ([127.0.0.1]) by localhost (zimbra.overnetdata.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MhyNKApLAhYz; Fri, 23 Sep 2011 11:29:33 +0100 (BST) Received: from [192.168.1.63] (unknown [192.168.1.63]) by zimbra.overnetdata.com (Postfix) with ESMTPSA id 8D7CB16187F; Fri, 23 Sep 2011 11:29:33 +0100 (BST) Message-ID: <4E7C5F8B.6050509@overnetdata.com> Date: Fri, 23 Sep 2011 11:29:31 +0100 From: Anthony Wright <anthony@overnetdata.com> User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:6.0.2) Gecko/20110902 Thunderbird/6.0.2 MIME-Version: 1.0 To: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>, "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com> X-Enigmail-Version: 1.3.2 Content-Type: multipart/mixed; boundary="------------080206040505060108020703" Cc: Subject: [Xen-devel] Getting mm.c errors from xl dmesg on certain hardware X-BeenThere: xen-devel@lists.xensource.com X-Mailman-Version: 2.1.5 Precedence: list List-Id: Xen developer discussion <xen-devel.lists.xensource.com> List-Unsubscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe> List-Post: <mailto:xen-devel@lists.xensource.com> List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help> List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=subscribe> Sender: xen-devel-bounces@lists.xensource.com Errors-To: xen-devel-bounces@lists.xensource.com This is a multi-part message in MIME format. --------------080206040505060108020703 Content-Type: multipart/alternative; boundary="------------050007020003000209050007" --------------050007020003000209050007 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Konrad Rzeszutek Wilk wrote: >> (XEN) mm.c:907:d0 Error getting mfn 3a09c (pfn 55555555) from L1 entry 000000003a09c023 for l1e_owner=0, pg_owner=0 >> (XEN) mm.c:907:d0 Error getting mfn 3a09d (pfn 55555555) from L1 entry 000000003a09d023 for l1e_owner=0, pg_owner=0 >> (XEN) mm.c:907:d0 Error getting mfn 3a09e (pfn 55555555) from L1 entry 000000003a09e023 for l1e_owner=0, pg_owner=0 >> (XEN) mm.c:907:d0 Error getting mfn 3a09f (pfn 55555555) from L1 entry 000000003a09f023 for l1e_owner=0, pg_owner=0 >> (XEN) traps.c:2388:d0 Domain attempted WRMSR c0010004 from 0x0000ab23d6d622da to 0x000000000000abcd. > Do they show up during bootup? As in do you see those _when_ you launch your guests? > To figure out this particular issue you should try using 'console_to_ring' (so that > dom0 output and Xen output are mingled togehter) and also post this under a new subject > to not confuse this email thread. The messages show up during the initial dom0 boot, before any domUs are loaded. I've attached a second xl dmesg log which is similar to the first, but the numbers in the error messages are different. The messages are hardware dependant as I don't get them on another system with different hardware configuration but with identical software. The motherboard is a ASUS M2N68 AM PLUS, with 4GB of RAM. If I remove one of the sticks of ram to take it down to 2GB, the mm.c errors are no longer displayed, but I still get the traps.c message. --------------050007020003000209050007 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit <html> <head> <meta http-equiv="content-type" content="text/html; charset=ISO-8859-1"> </head> <body bgcolor="#FFFFFF" text="#000000"> <pre wrap="">Konrad Rzeszutek Wilk wrote:</pre> <blockquote type="cite"> <div class="moz-text-plain" wrap="true" graphical-quote="true" style="font-family: -moz-fixed; font-size: 14px;" lang="x-western"> <blockquote type="cite" style="color: #000000;"> <pre wrap="">(XEN) mm.c:907:d0 Error getting mfn 3a09c (pfn 55555555) from L1 entry 000000003a09c023 for l1e_owner=0, pg_owner=0 (XEN) mm.c:907:d0 Error getting mfn 3a09d (pfn 55555555) from L1 entry 000000003a09d023 for l1e_owner=0, pg_owner=0 (XEN) mm.c:907:d0 Error getting mfn 3a09e (pfn 55555555) from L1 entry 000000003a09e023 for l1e_owner=0, pg_owner=0 (XEN) mm.c:907:d0 Error getting mfn 3a09f (pfn 55555555) from L1 entry 000000003a09f023 for l1e_owner=0, pg_owner=0 (XEN) traps.c:2388:d0 Domain attempted WRMSR c0010004 from 0x0000ab23d6d622da to 0x000000000000abcd. </pre> </blockquote> <pre wrap="">Do they show up during bootup? As in do you see those <span class="moz-txt-underscore"><span class="moz-txt-tag">_</span>when<span class="moz-txt-tag">_</span></span> you launch your guests? To figure out this particular issue you should try using 'console_to_ring' (so that dom0 output and Xen output are mingled togehter) and also post this under a new subject to not confuse this email thread. </pre> </div> </blockquote> The messages show up during the initial dom0 boot, before any domUs are loaded. I've attached a second xl dmesg log which is similar to the first, but the numbers in the error messages are different.<br> <br> The messages are hardware dependant as I don't get them on another system with different hardware configuration but with identical software.<br> <br> The motherboard is a ASUS M2N68 AM PLUS, with 4GB of RAM. If I remove one of the sticks of ram to take it down to 2GB, the mm.c errors are no longer displayed, but I still get the traps.c message.<br> <br> </body> </html> --------------050007020003000209050007-- --------------080206040505060108020703 Content-Type: text/plain; name="mm-errors-xl-dmesg.log" Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename="mm-errors-xl-dmesg.log" __ __ _ _ _ _ \ \/ /___ _ __ | || | / | / | \ // _ \ '_ \ | || |_ | | | | / \ __/ | | | |__ _|| |_| | /_/\_\___|_| |_| |_|(_)_(_)_| (XEN) Xen version 4.1.1 (@[unknown]) (gcc version 4.4.3 (GCC) ) Wed Sep 21 08:25:36 GMT 2011 (XEN) Latest ChangeSet: unavailable (XEN) Bootloader: GNU GRUB 0.97 (XEN) Command line: console_to_ring (XEN) Video information: (XEN) VGA is text mode 80x25, font 8x16 (XEN) VBE/DDC methods: none; EDID transfer time: 0 seconds (XEN) EDID info not retrieved because no DDC retrieval method detected (XEN) Disc information: (XEN) Found 2 MBR signatures (XEN) Found 2 EDD information structures (XEN) Xen-e820 RAM map: (XEN) 0000000000000000 - 000000000009b400 (usable) (XEN) 000000000009b400 - 00000000000a0000 (reserved) (XEN) 00000000000e2000 - 0000000000100000 (reserved) (XEN) 0000000000100000 - 00000000aff90000 (usable) (XEN) 00000000aff90000 - 00000000aff9e000 (ACPI data) (XEN) 00000000aff9e000 - 00000000affe0000 (ACPI NVS) (XEN) 00000000affe0000 - 00000000affee000 (reserved) (XEN) 00000000afff0000 - 00000000b0000000 (reserved) (XEN) 00000000fec00000 - 00000000fec01000 (reserved) (XEN) 00000000fee00000 - 00000000fef00000 (reserved) (XEN) 00000000fff00000 - 0000000100000000 (reserved) (XEN) 0000000100000000 - 0000000140000000 (usable) (XEN) System RAM: 3839MB (3931308kB) (XEN) ACPI: RSDP 000FB5D0, 0014 (r0 ACPIAM) (XEN) ACPI: RSDT AFF90000, 0038 (r1 032210 RSDT1037 20100322 MSFT 97) (XEN) ACPI: FACP AFF90200, 0084 (r2 032210 FACP1037 20100322 MSFT 97) (XEN) ACPI: DSDT AFF90460, 7307 (r1 A1270 A1270000 0 INTL 20060113) (XEN) ACPI: FACS AFF9E000, 0040 (XEN) ACPI: APIC AFF90390, 0090 (r1 032210 APIC1037 20100322 MSFT 97) (XEN) ACPI: MCFG AFF90420, 003C (r1 032210 OEMMCFG 20100322 MSFT 97) (XEN) ACPI: OEMB AFF9E040, 0071 (r1 032210 OEMB1037 20100322 MSFT 97) (XEN) ACPI: HPET AFF97770, 0038 (r1 032210 OEMHPET0 20100322 MSFT 97) (XEN) Xen heap: 9MB (9788kB) (XEN) Domain heap initialised (XEN) Processor #0 0:6 APIC version 16 (XEN) Processor #1 0:6 APIC version 16 (XEN) IOAPIC[0]: apic_id 2, version 17, address 0xfec00000, GSI 0-23 (XEN) Enabling APIC mode: Flat. Using 1 I/O APICs (XEN) Table is not found! (XEN) Using scheduler: SMP Credit Scheduler (credit) (XEN) Detected 3013.763 MHz processor. (XEN) AMD-Vi: IOMMU not found! (XEN) I/O virtualisation disabled (XEN) ENABLING IO-APIC IRQs (XEN) -> Using new ACK method (XEN) Platform timer is 25.000MHz HPET (XEN) Allocated console ring of 16 KiB. (XEN) CPU0: AMD SVM Extension is disabled in BIOS. (XEN) SVM: failed to initialise. (XEN) Brought up 2 CPUs (XEN) *** LOADING DOMAIN 0 *** (XEN) Xen kernel: 32-bit, PAE, lsb (XEN) Dom0 kernel: 32-bit, PAE, lsb, paddr 0x1000000 -> 0x1b38000 (XEN) PHYSICAL MEMORY ARRANGEMENT: (XEN) Dom0 alloc.: 0000000138000000->000000013c000000 (920701 pages to be allocated) (XEN) Init. ramdisk: 000000013f6ef000->000000013ffffca4 (XEN) VIRTUAL MEMORY ARRANGEMENT: (XEN) Loaded kernel: c1000000->c1b38000 (XEN) Init. ramdisk: c1b38000->c2448ca4 (XEN) Phys-Mach map: c2449000->c27de638 (XEN) Start info: c27df000->c27df47c (XEN) Page tables: c27e0000->c27fb000 (XEN) Boot stack: c27fb000->c27fc000 (XEN) TOTAL: c0000000->c2c00000 (XEN) ENTRY ADDRESS: c173e000 (XEN) Dom0 has maximum 2 VCPUs (XEN) Scrubbing Free RAM: .done. (XEN) Xen trace buffers: disabled (XEN) Std. Loglevel: Errors and warnings (XEN) Guest Loglevel: Nothing (Rate-limited: Errors and warnings) (XEN) Xen is relinquishing VGA console. (XEN) *** Serial input -> DOM0 (type 'CTRL-a' three times to switch input to Xen) (XEN) Freed 188kB init memory. mapping kernel into physical memory Xen: setup ISA identity maps about to get started... (XEN) mm.c:907:d0 Error getting mfn 3809c (pfn b602c) from L1 entry 000000003809c023 for l1e_owner=0, pg_owner=0 (XEN) mm.c:907:d0 Error getting mfn 3809d (pfn b602d) from L1 entry 000000003809d023 for l1e_owner=0, pg_owner=0 (XEN) mm.c:907:d0 Error getting mfn 3809e (pfn b602e) from L1 entry 000000003809e023 for l1e_owner=0, pg_owner=0 (XEN) mm.c:907:d0 Error getting mfn 3809f (pfn b602f) from L1 entry 000000003809f023 for l1e_owner=0, pg_owner=0 (XEN) traps.c:2388:d0 Domain attempted WRMSR c0010004 from 0x00009b27fe9726ca to 0x000000000000abcd. --------------080206040505060108020703 Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel --------------080206040505060108020703-- From xen-devel-bounces@lists.xensource.com Fri Sep 23 03:35:16 2011 Return-path: <xen-devel-bounces@lists.xensource.com> Envelope-to: www-data@lists.xensource.com Delivery-date: Fri, 23 Sep 2011 03:35:16 -0700 Received: from localhost ([127.0.0.1] helo=lists.colo.xensource.com) by lists.xensource.com with esmtp (Exim 4.43) id 1R736B-0007t8-TK; Fri, 23 Sep 2011 03:35:15 -0700 Received: from mail21.messagelabs.com ([85.158.143.35]) by lists.xensource.com with smtp (Exim 4.43) id 1R735X-0007gd-9K for xen-devel@lists.xensource.com; Fri, 23 Sep 2011 03:34:35 -0700 X-Env-Sender: anthony@overnetdata.com X-Msg-Ref: server-3.tower-21.messagelabs.com!1316774083!52672366!1 X-Originating-IP: [81.137.131.225] X-StarScan-Version: 6.4.1; banners=-,-,- X-VirusChecked: Checked Received: (qmail 13911 invoked from network); 23 Sep 2011 10:34:43 -0000 Received: from host81-137-131-225.in-addr.btopenworld.com (HELO zimbra.overnetdata.com) (81.137.131.225) by server-3.tower-21.messagelabs.com with SMTP; 23 Sep 2011 10:34:43 -0000 Received: from localhost (localhost.localdomain [127.0.0.1]) by zimbra.overnetdata.com (Postfix) with ESMTP id AE44216187F for <xen-devel@lists.xensource.com>; Fri, 23 Sep 2011 11:34:31 +0100 (BST) X-Virus-Scanned: amavisd-new at overnetdata.com Received: from zimbra.overnetdata.com ([127.0.0.1]) by localhost (zimbra.overnetdata.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id H9p19QWuTUa0 for <xen-devel@lists.xensource.com>; Fri, 23 Sep 2011 11:34:27 +0100 (BST) Received: from [192.168.1.63] (unknown [192.168.1.63]) by zimbra.overnetdata.com (Postfix) with ESMTPSA id B2D031616D8 for <xen-devel@lists.xensource.com>; Fri, 23 Sep 2011 11:34:27 +0100 (BST) Message-ID: <4E7C60B1.3000901@overnetdata.com> Date: Fri, 23 Sep 2011 11:34:25 +0100 From: Anthony Wright <anthony@overnetdata.com> User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:6.0.2) Gecko/20110902 Thunderbird/6.0.2 MIME-Version: 1.0 To: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com> X-Enigmail-Version: 1.3.2 Content-Type: multipart/mixed; boundary="------------060608050008000100080607" Subject: [Xen-devel] Getting IOAPIC errors in xl dmesg on old hardware X-BeenThere: xen-devel@lists.xensource.com X-Mailman-Version: 2.1.5 Precedence: list List-Id: Xen developer discussion <xen-devel.lists.xensource.com> List-Unsubscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe> List-Post: <mailto:xen-devel@lists.xensource.com> List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help> List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=subscribe> Sender: xen-devel-bounces@lists.xensource.com Errors-To: xen-devel-bounces@lists.xensource.com This is a multi-part message in MIME format. --------------060608050008000100080607 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit I am getting a series of IOAPIC errors in xl dmesg on a Dell OptiPlex GX100 machine (bought in 2000). I also get an error from traps.c which is very similar to the one in the 'Getting mm.c errors from xl dmesg on certain hardware' thread. This happens during system startup with no DomUs running. I have attached the xl dmesg log. --------------060608050008000100080607 Content-Type: text/plain; name="dell-optiplex-gx100-xl-dmesg.log" Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename="dell-optiplex-gx100-xl-dmesg.log" __ __ _ _ _ _ \ \/ /___ _ __ | || | / | / | \ // _ \ '_ \ | || |_ | | | | / \ __/ | | | |__ _|| |_| | /_/\_\___|_| |_| |_|(_)_(_)_| (XEN) Xen version 4.1.1 (@[unknown]) (gcc version 4.4.3 (GCC) ) Wed Sep 21 08:25:36 GMT 2011 (XEN) Latest ChangeSet: unavailable (XEN) Bootloader: GNU GRUB 0.97 (XEN) Command line: (XEN) Video information: (XEN) VGA is text mode 80x25, font 8x16 (XEN) VBE/DDC methods: V2; EDID transfer time: 1 seconds (XEN) Disc information: (XEN) Found 0 MBR signatures (XEN) Found 0 EDD information structures (XEN) Xen-e820 RAM map: (XEN) 0000000000000000 - 00000000000a0000 (usable) (XEN) 00000000000f0000 - 0000000000100000 (reserved) (XEN) 0000000000100000 - 000000001feae000 (usable) (XEN) 000000001feae000 - 0000000020000000 (reserved) (XEN) 00000000ffb00000 - 0000000100000000 (reserved) (XEN) System RAM: 510MB (522552kB) (XEN) ACPI: RSDP 000FD790, 0014 (r0 DELL ) (XEN) ACPI: RSDT 000FD7A4, 0028 (r1 DELL GX100 7 ASL 61) (XEN) ACPI: FACP 000FD7CC, 0074 (r1 DELL GX100 7 ASL 61) (XEN) ACPI: DSDT FFFE5000, 1801 (r1 DELL dt_ex 1000 MSFT 100000B) (XEN) ACPI: FACS 1FEAE000, 0040 (XEN) Xen heap: 9MB (9784kB) (XEN) Domain heap initialised (XEN) Table is not found! (XEN) Local APIC disabled by BIOS -- you can enable it with "lapic" (XEN) Using scheduler: SMP Credit Scheduler (credit) (XEN) Detected 595.063 MHz processor. (XEN) I/O virtualisation disabled (XEN) TSC only partially writable (XEN) Platform timer is 3.579MHz ACPI PM Timer (XEN) Allocated console ring of 16 KiB. (XEN) Brought up 1 CPUs (XEN) xenoprof: Initialization failed. No APIC (XEN) *** LOADING DOMAIN 0 *** (XEN) Xen kernel: 32-bit, PAE, lsb (XEN) Dom0 kernel: 32-bit, PAE, lsb, paddr 0x1000000 -> 0x1b38000 (XEN) PHYSICAL MEMORY ARRANGEMENT: (XEN) Dom0 alloc.: 000000001c000000->000000001e000000 (107972 pages to be allocated) (XEN) Init. ramdisk: 000000001f4ef000->000000001fdffca4 (XEN) VIRTUAL MEMORY ARRANGEMENT: (XEN) Loaded kernel: c1000000->c1b38000 (XEN) Init. ramdisk: c1b38000->c2448ca4 (XEN) Phys-Mach map: c2449000->c24bcb54 (XEN) Start info: c24bd000->c24bd47c (XEN) Page tables: c24be000->c24d7000 (XEN) Boot stack: c24d7000->c24d8000 (XEN) TOTAL: c0000000->c2800000 (XEN) ENTRY ADDRESS: c173e000 (XEN) Dom0 has maximum 1 VCPUs (XEN) Scrubbing Free RAM: done. (XEN) Xen trace buffers: disabled (XEN) Std. Loglevel: Errors and warnings (XEN) Guest Loglevel: Nothing (Rate-limited: Errors and warnings) (XEN) Xen is relinquishing VGA console. (XEN) *** Serial input -> DOM0 (type 'CTRL-a' three times to switch input to Xen) (XEN) Freed 188kB init memory. (XEN) traps.c:2388:d0 Domain attempted WRMSR 000000c1 from 0x0000000000000000 to 0x000000000000abcd. (XEN) ERROR: Unable to locate IOAPIC for GSI 13 (XEN) No IOAPIC for GSI 13 (XEN) ERROR: Unable to locate IOAPIC for GSI 8 (XEN) No IOAPIC for GSI 8 (XEN) ERROR: Unable to locate IOAPIC for GSI 6 (XEN) No IOAPIC for GSI 6 (XEN) ERROR: Unable to locate IOAPIC for GSI 1 (XEN) No IOAPIC for GSI 1 (XEN) ERROR: Unable to locate IOAPIC for GSI 12 (XEN) No IOAPIC for GSI 12 (XEN) ERROR: Unable to locate IOAPIC for GSI 4 (XEN) No IOAPIC for GSI 4 (XEN) ERROR: Unable to locate IOAPIC for GSI 3 (XEN) No IOAPIC for GSI 3 (XEN) ERROR: Unable to locate IOAPIC for GSI 7 (XEN) No IOAPIC for GSI 7 (XEN) ERROR: Unable to locate IOAPIC for GSI 11 (XEN) No IOAPIC for GSI 11 (XEN) ERROR: Unable to locate IOAPIC for GSI 10 (XEN) No IOAPIC for GSI 10 (XEN) ERROR: Unable to locate IOAPIC for GSI 5 (XEN) No IOAPIC for GSI 5 (XEN) ERROR: Unable to locate IOAPIC for GSI 5 (XEN) No IOAPIC for GSI 5 --------------060608050008000100080607 Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel --------------060608050008000100080607-- From xen-devel-bounces@lists.xensource.com Fri Sep 23 03:43:34 2011 Return-path: <xen-devel-bounces@lists.xensource.com> Envelope-to: www-data@lists.xensource.com Delivery-date: Fri, 23 Sep 2011 03:43:34 -0700 Received: from localhost ([127.0.0.1] helo=lists.colo.xensource.com) by lists.xensource.com with esmtp (Exim 4.43) id 1R73EE-0008Mx-0J; Fri, 23 Sep 2011 03:43:34 -0700 Received: from mail216.messagelabs.com ([85.158.143.99]) by lists.xensource.com with esmtp (Exim 4.43) id 1R73Db-0008AU-Sb for xen-devel@lists.xensource.com; Fri, 23 Sep 2011 03:42:56 -0700 X-Env-Sender: david.vrabel@citrix.com X-Msg-Ref: server-2.tower-216.messagelabs.com!1316774571!18902536!1 X-Originating-IP: [66.165.176.63] X-StarScan-Version: 6.4.1; banners=-,-,- X-VirusChecked: Checked Received: (qmail 15309 invoked from network); 23 Sep 2011 10:42:52 -0000 Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63) by server-2.tower-216.messagelabs.com with RC4-SHA encrypted SMTP; 23 Sep 2011 10:42:52 -0000 X-IronPort-AV: E=Sophos;i="4.68,428,1312171200"; d="scan'208";a="164422882" Received: from ftlpmailmx02.citrite.net ([10.13.107.66]) by FTLPIPO02.CITRIX.COM with ESMTP/TLS/RC4-MD5; 23 Sep 2011 06:42:51 -0400 Received: from [10.80.2.76] (10.80.2.76) by FTLPMAILMX02.citrite.net (10.13.107.66) with Microsoft SMTP Server id 8.3.137.0; Fri, 23 Sep 2011 06:42:51 -0400 Message-ID: <4E7C6344.3000401@citrix.com> Date: Fri, 23 Sep 2011 11:45:24 +0100 From: David Vrabel <david.vrabel@citrix.com> User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.1.16) Gecko/20110818 Icedove/3.0.11 MIME-Version: 1.0 To: Dan Magenheimer <dan.magenheimer@oracle.com> Subject: Re: [Xen-devel] xen: memory initialization/balloon fixes (#3) References: <1316089768-22461-1-git-send-email-david.vrabel@citrix.com> <63997331-e53b-48e5-bf7c-87141aae49d6@default> <4E7B2ADA.7000605@citrix.com> <df22e0b8-15d8-4cb1-a9d9-d3565aa5f9b7@default> <8af71cad-415d-42d4-8a2e-e4efd7e36fd4@default 4E7BBC00.1050602@goop.org> <005ea591-cfb5-4ca0-9c9c-df2bbae88172@default> In-Reply-To: <005ea591-cfb5-4ca0-9c9c-df2bbae88172@default> Content-Type: text/plain; charset="ISO-8859-1" Content-Transfer-Encoding: 7bit Cc: Jeremy Fitzhardinge <jeremy@goop.org>, "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>, "JBeulich@novell.com" <JBeulich@novell.com>, Konrad Wilk <konrad.wilk@oracle.com> X-BeenThere: xen-devel@lists.xensource.com X-Mailman-Version: 2.1.5 Precedence: list List-Id: Xen developer discussion <xen-devel.lists.xensource.com> List-Unsubscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe> List-Post: <mailto:xen-devel@lists.xensource.com> List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help> List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=subscribe> Sender: xen-devel-bounces@lists.xensource.com Errors-To: xen-devel-bounces@lists.xensource.com On 23/09/11 00:46, Dan Magenheimer wrote: >> From: Jeremy Fitzhardinge [mailto:jeremy@goop.org] >> >> On 09/22/2011 03:34 PM, Dan Magenheimer wrote: >>>> I'm aware of that... "some" has been a fixed size of a few megabytes >>>> in Xen for a long time. I am seeing 30-60MB or more. >>> Never mind on this part. After further debugging, I can see >>> that this difference is due to normal uses of memory by the >>> kernel for XEN PAGETABLES and RAMDISK etc. It's unfortunate >>> that the difference is so large, but I guess that's in part due >>> to the desire to use the same kernel binary for native and >>> virtualized. I don't remember it being nearly so high for >>> older PV kernels, but I guess it's progress! :-} >> >> I don't think the Xen parts allocate/reserves lots of memory >> unnecessarily, so it shouldn't be too different from the 2.6.18-xen >> kernels. They do reserve various chunks of memory, but for things like >> RAMDISK I think they get released again (and anyway, I don't think >> that's going to be anywhere near 30MB, let alone 60). I'm not very >> confident in those /proc/meminfo numbers - they may count memory as >> "reserved" if its in a reserved region even if the pages themselves have >> been released to the kernel pool. > > No, the first line of /proc/meminfo is precisely "totalram_pages". I think most of the increase in reserved memory compared to classic Xen kernels is the change to using the generic SWIOTLB. This is up to 64 MiB. >>>>>> Part B of the problem (and the one most important to me) is that >>>>>> setting /sys/devices/system/xen_memory/xen_memory0/target_kb >>>>>> to X results in a MemTotal inside the domU (as observed by >>>>>> "head -1 /proc/meminfo") of X-D. This can be particularly painful >>>>>> when X is aggressively small as X-D may result in OOMs. >>>>>> To use kernel function/variable names (and I observed this with >>>>>> some debugging code), when balloon_set_new_target(X) is called >>>>>> totalram_pages gets driven to X-D. >>>>> Again, this looks like the correct behavior to me. >>>> Hmmm... so if a user (or automated tool) uses the Xen-defined >>>> API (i.e. /sys/devices/system/xen_memory/xen_memory0/target_kb) >>>> to use the Xen balloon driver to attempt to reduce memory usage >>>> to 100MB, and the Xen balloon driver instead reduces it to >>>> some random number somewhere between 40MB and 90MB, which >>>> may or may not cause OOMs, you consider this correct behavior? >>> I still think this is a bug but apparently orthogonal to >>> your patchset. So sorry to bother you. >> >> If you ask for 100MB, it should never try to make the domain smaller >> than that; if it does, it suggests the number is being misparsed or >> something. > > OK then balloon_stats.current_pages can never be larger than totalram_pages. > Which means that balloon_stats.current_pages must always grow > and shrink when totalram_pages does (which is true now only in > the balloon driver code). Which means, I think: > > balloon_stats.current_pages is just plain wrong! It doesn't need to > exist! If we replace every instance in balloon.c with totalram_pages, > I think everything just works. Will run some tests tomorrow. No. balloon_stats.current_pages is the amount of pages used by the domain from Xen's point of view (and must be equal to the amount report by xl top). It is not what the guest kernel thinks is the number of usable pages. Because totalram_pages doesn't include some reserved pages balloon_stats.current_pages will necessarily always be greater. If you're attempting to make the domain self-balloon I don't see why you're even interested in the total number of pages. Surely it's the number of free pages that's useful? e.g., a basic self-ballooning algorithm would be something like. delta = free_pages - emergency_reserve - spare reservation_target -= delta Where: free_pages is the current number of free pages emergency_reserve is the amount of pages the kernel reserves for satisfying important allocations when memory is low. This is approximately (initial_maximum_reservation / 32). spare is some extra number of pages to provide a buffer when the memory usage increases. David _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel From xen-devel-bounces@lists.xensource.com Fri Sep 23 03:46:05 2011 Return-path: <xen-devel-bounces@lists.xensource.com> Envelope-to: www-data@lists.xensource.com Delivery-date: Fri, 23 Sep 2011 03:46:05 -0700 Received: from localhost ([127.0.0.1] helo=lists.colo.xensource.com) by lists.xensource.com with esmtp (Exim 4.43) id 1R73Ge-0000K5-PE; Fri, 23 Sep 2011 03:46:05 -0700 Received: from mail21.messagelabs.com ([85.158.143.35]) by lists.xensource.com with esmtp (Exim 4.43) id 1R73GC-00007e-Fx for xen-devel@lists.xensource.com; Fri, 23 Sep 2011 03:45:36 -0700 X-Env-Sender: JBeulich@suse.com X-Msg-Ref: server-13.tower-21.messagelabs.com!1316774727!50030261!1 X-Originating-IP: [130.57.49.28] X-StarScan-Version: 6.4.1; banners=-,-,- X-VirusChecked: Checked Received: (qmail 10394 invoked from network); 23 Sep 2011 10:45:27 -0000 Received: from nat28.tlf.novell.com (HELO nat28.tlf.novell.com) (130.57.49.28) by server-13.tower-21.messagelabs.com with DHE-RSA-AES256-SHA encrypted SMTP; 23 Sep 2011 10:45:27 -0000 Received: from EMEA1-MTA by nat28.tlf.novell.com with Novell_GroupWise; Fri, 23 Sep 2011 11:45:33 +0100 Message-Id: <4E7C7F890200007800057892@nat28.tlf.novell.com> X-Mailer: Novell GroupWise Internet Agent 8.0.1 Date: Fri, 23 Sep 2011 11:46:01 +0100 From: "Jan Beulich" <JBeulich@suse.com> To: "Anthony Wright" <anthony@overnetdata.com> Subject: Re: [Xen-devel] Getting mm.c errors from xl dmesg on certain hardware References: <4E7C5F8B.6050509@overnetdata.com> In-Reply-To: <4E7C5F8B.6050509@overnetdata.com> Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: quoted-printable Content-Disposition: inline Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>, Konrad Rzeszutek Wilk <konrad.wilk@oracle.com> X-BeenThere: xen-devel@lists.xensource.com X-Mailman-Version: 2.1.5 Precedence: list List-Id: Xen developer discussion <xen-devel.lists.xensource.com> List-Unsubscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe> List-Post: <mailto:xen-devel@lists.xensource.com> List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help> List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=subscribe> Sender: xen-devel-bounces@lists.xensource.com Errors-To: xen-devel-bounces@lists.xensource.com >>> On 23.09.11 at 12:29, Anthony Wright <anthony@overnetdata.com> wrote: > Konrad Rzeszutek Wilk wrote: >=20 >>> (XEN) mm.c:907:d0 Error getting mfn 3a09c (pfn 55555555) from L1 = entry=20 > 000000003a09c023 for l1e_owner=3D0, pg_owner=3D0 >>> (XEN) mm.c:907:d0 Error getting mfn 3a09d (pfn 55555555) from L1 = entry=20 > 000000003a09d023 for l1e_owner=3D0, pg_owner=3D0 >>> (XEN) mm.c:907:d0 Error getting mfn 3a09e (pfn 55555555) from L1 = entry=20 > 000000003a09e023 for l1e_owner=3D0, pg_owner=3D0 >>> (XEN) mm.c:907:d0 Error getting mfn 3a09f (pfn 55555555) from L1 = entry=20 > 000000003a09f023 for l1e_owner=3D0, pg_owner=3D0 >>> (XEN) traps.c:2388:d0 Domain attempted WRMSR c0010004 from=20 > 0x0000ab23d6d622da to 0x000000000000abcd. >> Do they show up during bootup? As in do you see those _when_ you launch = your=20 > guests? >> To figure out this particular issue you should try using 'console_to_rin= g'=20 > (so that >> dom0 output and Xen output are mingled togehter) and also post this = under a=20 > new subject >> to not confuse this email thread. > The messages show up during the initial dom0 boot, before any domUs are > loaded. I've attached a second xl dmesg log which is similar to the > first, but the numbers in the error messages are different. >=20 > The messages are hardware dependant as I don't get them on another > system with different hardware configuration but with identical = software. >=20 > The motherboard is a ASUS M2N68 AM PLUS, with 4GB of RAM. If I remove > one of the sticks of ram to take it down to 2GB, the mm.c errors are no > longer displayed, but I still get the traps.c message. Would seem most likely to be I/O memory that doesn't get marked properly when creating the page table entries, thus causing an unintended phys->mach translation. If there are no kernel messages associated with this, you will want to put some register/stack dumping code in to determine what component in the kernel is causing this. Jan _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel From xen-devel-bounces@lists.xensource.com Fri Sep 23 03:49:12 2011 Return-path: <xen-devel-bounces@lists.xensource.com> Envelope-to: www-data@lists.xensource.com Delivery-date: Fri, 23 Sep 2011 03:49:12 -0700 Received: from localhost ([127.0.0.1] helo=lists.colo.xensource.com) by lists.xensource.com with esmtp (Exim 4.43) id 1R73Jg-0000jj-Gf; Fri, 23 Sep 2011 03:49:12 -0700 Received: from mail21.messagelabs.com ([85.158.143.35]) by lists.xensource.com with esmtp (Exim 4.43) id 1R73J7-0000XD-LU for xen-devel@lists.xensource.com; Fri, 23 Sep 2011 03:48:38 -0700 X-Env-Sender: JBeulich@suse.com X-Msg-Ref: server-4.tower-21.messagelabs.com!1316774878!61321216!1 X-Originating-IP: [130.57.49.28] X-StarScan-Version: 6.4.1; banners=-,-,- X-VirusChecked: Checked Received: (qmail 30087 invoked from network); 23 Sep 2011 10:47:58 -0000 Received: from nat28.tlf.novell.com (HELO nat28.tlf.novell.com) (130.57.49.28) by server-4.tower-21.messagelabs.com with DHE-RSA-AES256-SHA encrypted SMTP; 23 Sep 2011 10:47:58 -0000 Received: from EMEA1-MTA by nat28.tlf.novell.com with Novell_GroupWise; Fri, 23 Sep 2011 11:48:34 +0100 Message-Id: <4E7C803E02000078000578A3@nat28.tlf.novell.com> X-Mailer: Novell GroupWise Internet Agent 8.0.1 Date: Fri, 23 Sep 2011 11:49:02 +0100 From: "Jan Beulich" <JBeulich@suse.com> To: "Anthony Wright" <anthony@overnetdata.com> Subject: Re: [Xen-devel] Getting IOAPIC errors in xl dmesg on old hardware References: <4E7C60B1.3000901@overnetdata.com> In-Reply-To: <4E7C60B1.3000901@overnetdata.com> Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: quoted-printable Content-Disposition: inline Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com> X-BeenThere: xen-devel@lists.xensource.com X-Mailman-Version: 2.1.5 Precedence: list List-Id: Xen developer discussion <xen-devel.lists.xensource.com> List-Unsubscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe> List-Post: <mailto:xen-devel@lists.xensource.com> List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help> List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=subscribe> Sender: xen-devel-bounces@lists.xensource.com Errors-To: xen-devel-bounces@lists.xensource.com >>> On 23.09.11 at 12:34, Anthony Wright <anthony@overnetdata.com> wrote: > I am getting a series of IOAPIC errors in xl dmesg on a Dell OptiPlex > GX100 machine (bought in 2000). I also get an error from traps.c which > is very similar to the one in the 'Getting mm.c errors from xl dmesg on > certain hardware' thread. This happens during system startup with no > DomUs running. I have attached the xl dmesg log. Seems like the kernel is trying to use IO-APIC despite the LAPIC being unavailable. Is this with a pv-ops kernel or a forward port one? Which version? Also, did you try following what this message (XEN) Local APIC disabled by BIOS -- you can enable it with "lapic" is suggesting? Jan _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel From xen-devel-bounces@lists.xensource.com Fri Sep 23 03:54:05 2011 Return-path: <xen-devel-bounces@lists.xensource.com> Envelope-to: www-data@lists.xensource.com Delivery-date: Fri, 23 Sep 2011 03:54:05 -0700 Received: from localhost ([127.0.0.1] helo=lists.colo.xensource.com) by lists.xensource.com with esmtp (Exim 4.43) id 1R73OP-0001AS-16; Fri, 23 Sep 2011 03:54:05 -0700 Received: from mail216.messagelabs.com ([85.158.143.99]) by lists.xensource.com with esmtp (Exim 4.43) id 1R73Nv-0000y9-3y for xen-devel@lists.xensource.com; Fri, 23 Sep 2011 03:53:35 -0700 X-Env-Sender: Stefano.Stabellini@eu.citrix.com X-Msg-Ref: server-9.tower-216.messagelabs.com!1316775212!19357263!1 X-Originating-IP: [62.200.22.115] X-StarScan-Version: 6.4.1; banners=-,-,- X-VirusChecked: Checked Received: (qmail 19132 invoked from network); 23 Sep 2011 10:53:32 -0000 Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115) by server-9.tower-216.messagelabs.com with RC4-SHA encrypted SMTP; 23 Sep 2011 10:53:32 -0000 X-IronPort-AV: E=Sophos;i="4.68,428,1312156800"; d="scan'208";a="8026626" Received: from lonpmailmx01.citrite.net ([10.30.203.162]) by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5; 23 Sep 2011 10:53:31 +0000 Received: from kaball.uk.xensource.com (10.80.2.59) by LONPMAILMX01.citrite.net (10.30.203.162) with Microsoft SMTP Server id 8.3.137.0; Fri, 23 Sep 2011 11:53:32 +0100 Date: Fri, 23 Sep 2011 11:53:35 +0100 From: Stefano Stabellini <stefano.stabellini@eu.citrix.com> X-X-Sender: sstabellini@kaball-desktop To: Jeremy Fitzhardinge <jeremy@goop.org> Subject: Re: [Xen-devel] Re: [PATCH 0/6] xen: don't call vmalloc_sync_all() when mapping foreign pages In-Reply-To: <4E7BA677.9090907@goop.org> Message-ID: <alpine.DEB.2.00.1109231146510.8700@kaball-desktop> References: <1316090411-22608-1-git-send-email-david.vrabel@citrix.com> <4E727017.4030001@goop.org> <alpine.DEB.2.00.1109211124050.8700@kaball-desktop> <4E7A3394.3090806@goop.org> <alpine.DEB.2.00.1109221131390.8700@kaball-desktop> <4E7BA677.9090907@goop.org> User-Agent: Alpine 2.00 (DEB 1167 2008-08-23) MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>, Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>, Stefano Stabellini <Stefano.Stabellini@eu.citrix.com>, "linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>, David Vrabel <david.vrabel@citrix.com>, Andrew Morton <akpm@linux-foundation.org> X-BeenThere: xen-devel@lists.xensource.com X-Mailman-Version: 2.1.5 Precedence: list List-Id: Xen developer discussion <xen-devel.lists.xensource.com> List-Unsubscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe> List-Post: <mailto:xen-devel@lists.xensource.com> List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help> List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=subscribe> Sender: xen-devel-bounces@lists.xensource.com Errors-To: xen-devel-bounces@lists.xensource.com On Thu, 22 Sep 2011, Jeremy Fitzhardinge wrote: > On 09/22/2011 04:06 AM, Stefano Stabellini wrote: > > On Wed, 21 Sep 2011, Jeremy Fitzhardinge wrote: > >> On 09/21/2011 03:42 AM, Stefano Stabellini wrote: > >>> On Thu, 15 Sep 2011, Jeremy Fitzhardinge wrote: > >>>> This series is relying on regular ram mappings are already synced to all > >>>> tasks, but I'm not sure that's necessarily guaranteed (for example, if > >>>> you hotplug new memory into the domain, the new pages won't be mapped > >>>> into every mm unless they're synced). > >>> the series is using GFP_KERNEL, so this problem shouldn't occur, right? > >> What properties do you think GFP_KERNEL guarantees? > > That the memory is below 4G and always mapped in the kernel 1:1 region. > > Hm, but that's not quite the same thing as "mapped into every > pagetable". Lowmem pages always have a kernel virtual address, and its > always OK to touch them at any point in kernel code[*] because one can > rely on the fault handler to create mappings as needed - but that > doesn't mean they're necessarily mapped by present ptes in the current > pagetable. > > [*] - except NMI handlers Is that really true? I quickly went through the fault handler and I couldn't see anything related to the kernel 1:1 region. > > Regarding memory hotplug it looks like that x86_32 is mapping new memory > > ZONE_HIGHMEM, therefore avoiding any problems with GFP_KERNEL allocations. > > On the other hand x86_64 is mapping the memory ZONE_NORMAL and calling > > init_memory_mapping on the new range right away. AFAICT changes to > > the 1:1 mapping in init_mm are automatically synced across all mm's > > because the pgd is shared? > > TBH I'm not sure. vmalloc_sync_one/all does seem to do *something* on > 64-bit, but I was never completely sure what regions of the address > space were already shared. I *think* it might be that the pgd and pud > are not shared, but the pmd down is, so if you add a new pmd you need to > sync it into all the puds (and puds into pgds if you add a new one of > those). > > But I'd be happier pretending that vmalloc_sync_* just doesn't exist, > and deal with it at the hypercall level - in the short term, by just > making sure that the callers touch all those pages before passing them > into the hypercall. That would certainly be an improvement over what we have now. However I am worried about the gntdev stuff: if I am right and the 1:1 mapping is guaranteed to be sync'ed, then it is OK and we can use alloc_xenballooned_pages everywhere, otherwise we should fix or remove alloc_xenballooned_pages from gntdev too. _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel From xen-devel-bounces@lists.xensource.com Fri Sep 23 04:17:14 2011 Return-path: <xen-devel-bounces@lists.xensource.com> Envelope-to: www-data@lists.xensource.com Delivery-date: Fri, 23 Sep 2011 04:17:14 -0700 Received: from localhost ([127.0.0.1] helo=lists.colo.xensource.com) by lists.xensource.com with esmtp (Exim 4.43) id 1R73ko-00023U-3Y; Fri, 23 Sep 2011 04:17:14 -0700 Received: from mail21.messagelabs.com ([85.158.143.35]) by lists.xensource.com with esmtp (Exim 4.43) id 1R73jx-0001r3-3F for xen-devel@lists.xensource.com; Fri, 23 Sep 2011 04:16:21 -0700 X-Env-Sender: david.vrabel@citrix.com X-Msg-Ref: server-13.tower-21.messagelabs.com!1316776570!50035802!1 X-Originating-IP: [66.165.176.63] X-StarScan-Version: 6.4.1; banners=-,-,- X-VirusChecked: Checked Received: (qmail 10716 invoked from network); 23 Sep 2011 11:16:11 -0000 Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63) by server-13.tower-21.messagelabs.com with RC4-SHA encrypted SMTP; 23 Sep 2011 11:16:11 -0000 X-IronPort-AV: E=Sophos;i="4.68,429,1312171200"; d="scan'208";a="164425892" Received: from ftlpmailmx01.citrite.net ([10.13.107.65]) by FTLPIPO02.CITRIX.COM with ESMTP/TLS/RC4-MD5; 23 Sep 2011 07:16:16 -0400 Received: from [10.80.2.76] (10.80.2.76) by FTLPMAILMX01.citrite.net (10.13.107.65) with Microsoft SMTP Server id 8.3.137.0; Fri, 23 Sep 2011 07:16:15 -0400 Message-ID: <4E7C6B18.7030100@citrix.com> Date: Fri, 23 Sep 2011 12:18:48 +0100 From: David Vrabel <david.vrabel@citrix.com> User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.1.16) Gecko/20110818 Icedove/3.0.11 MIME-Version: 1.0 To: Jeremy Fitzhardinge <jeremy@goop.org> Subject: Re: [Xen-devel] Re: [PATCH 0/6] xen: don't call vmalloc_sync_all() when mapping foreign pages References: <1316090411-22608-1-git-send-email-david.vrabel@citrix.com> <4E727017.4030001@goop.org> <alpine.DEB.2.00.1109211124050.8700@kaball-desktop> <4E7A3394.3090806@goop.org> <alpine.DEB.2.00.1109221131390.8700@kaball-desktop> <4E7BA677.9090907@goop.org> In-Reply-To: <4E7BA677.9090907@goop.org> Content-Type: text/plain; charset="ISO-8859-1" Content-Transfer-Encoding: 7bit Cc: Andrew Morton <akpm@linux-foundation.org>, "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>, "linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>, Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>, Stefano Stabellini <Stefano.Stabellini@eu.citrix.com> X-BeenThere: xen-devel@lists.xensource.com X-Mailman-Version: 2.1.5 Precedence: list List-Id: Xen developer discussion <xen-devel.lists.xensource.com> List-Unsubscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe> List-Post: <mailto:xen-devel@lists.xensource.com> List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help> List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=subscribe> Sender: xen-devel-bounces@lists.xensource.com Errors-To: xen-devel-bounces@lists.xensource.com On 22/09/11 22:19, Jeremy Fitzhardinge wrote: > > But I'd be happier pretending that vmalloc_sync_* just doesn't exist, > and deal with it at the hypercall level - in the short term, by just > making sure that the callers touch all those pages before passing them > into the hypercall. I don't think you can access the pages at the addresses allocated with alloc_vm_area() because the pages don't exist yet and there's a check of pte_present() in vmalloc_fault() and I think an Oops will be reported. David _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel From xen-devel-bounces@lists.xensource.com Fri Sep 23 04:20:18 2011 Return-path: <xen-devel-bounces@lists.xensource.com> Envelope-to: www-data@lists.xensource.com Delivery-date: Fri, 23 Sep 2011 04:20:18 -0700 Received: from localhost ([127.0.0.1] helo=lists.colo.xensource.com) by lists.xensource.com with esmtp (Exim 4.43) id 1R73nm-0002Sg-0F; Fri, 23 Sep 2011 04:20:18 -0700 Received: from mail21.messagelabs.com ([85.158.143.35]) by lists.xensource.com with esmtp (Exim 4.43) id 1R73mf-0002G6-3Z for xen-devel@lists.xensource.com; Fri, 23 Sep 2011 04:19:09 -0700 X-Env-Sender: Stefano.Stabellini@eu.citrix.com X-Msg-Ref: server-12.tower-21.messagelabs.com!1316776729!51050697!1 X-Originating-IP: [66.165.176.63] X-StarScan-Version: 6.4.1; banners=-,-,- X-VirusChecked: Checked Received: (qmail 26493 invoked from network); 23 Sep 2011 11:18:50 -0000 Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63) by server-12.tower-21.messagelabs.com with RC4-SHA encrypted SMTP; 23 Sep 2011 11:18:50 -0000 X-IronPort-AV: E=Sophos;i="4.68,429,1312171200"; d="scan'208";a="164426117" Received: from ftlpmailmx02.citrite.net ([10.13.107.66]) by FTLPIPO02.CITRIX.COM with ESMTP/TLS/RC4-MD5; 23 Sep 2011 07:19:04 -0400 Received: from smtp01.ad.xensource.com (10.219.128.104) by smtprelay.citrix.com (10.13.107.66) with Microsoft SMTP Server id 8.3.137.0; Fri, 23 Sep 2011 07:19:04 -0400 Received: from localhost.localdomain (kaball.uk.xensource.com [10.80.2.59]) by smtp01.ad.xensource.com (8.13.1/8.13.1) with ESMTP id p8NBIutD030871; Fri, 23 Sep 2011 04:18:57 -0700 From: <stefano.stabellini@eu.citrix.com> To: konrad.wilk@oracle.com Date: Fri, 23 Sep 2011 12:19:13 +0100 Message-ID: <1316776753-10168-1-git-send-email-stefano.stabellini@eu.citrix.com> X-Mailer: git-send-email 1.7.0.4 MIME-Version: 1.0 Content-Type: text/plain Cc: Ian.Campbell@eu.citrix.com, jeremy@goop.org, xen-devel@lists.xensource.com, Stefano Stabellini <stefano.stabellini@eu.citrix.com>, Stefano.Stabellini@eu.citrix.com Subject: [Xen-devel] [PATCH] xen: remove XEN_PLATFORM_PCI config option X-BeenThere: xen-devel@lists.xensource.com X-Mailman-Version: 2.1.5 Precedence: list List-Id: Xen developer discussion <xen-devel.lists.xensource.com> List-Unsubscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe> List-Post: <mailto:xen-devel@lists.xensource.com> List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help> List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=subscribe> Sender: xen-devel-bounces@lists.xensource.com Errors-To: xen-devel-bounces@lists.xensource.com From: Stefano Stabellini <stefano.stabellini@eu.citrix.com> Xen PVHVM needs xen-platform-pci, on the other hand xen-platform-pci is useless in any other cases. Therefore remove the XEN_PLATFORM_PCI config option and compile xen-platform-pci built-in if XEN_PVHVM is selected. Signed-off-by: Stefano Stabellini <stefano.stabellini@eu.citrix.com> --- drivers/xen/Kconfig | 10 ---------- drivers/xen/Makefile | 2 +- 2 files changed, 1 insertions(+), 11 deletions(-) diff --git a/drivers/xen/Kconfig b/drivers/xen/Kconfig index 5f7ff8e..8795480 100644 --- a/drivers/xen/Kconfig +++ b/drivers/xen/Kconfig @@ -137,16 +137,6 @@ config XEN_GRANT_DEV_ALLOC to other domains. This can be used to implement frontend drivers or as part of an inter-domain shared memory channel. -config XEN_PLATFORM_PCI - tristate "xen platform pci device driver" - depends on XEN_PVHVM && PCI - default m - help - Driver for the Xen PCI Platform device: it is responsible for - initializing xenbus and grant_table when running in a Xen HVM - domain. As a consequence this driver is required to run any Xen PV - frontend on Xen HVM. - config SWIOTLB_XEN def_bool y depends on PCI diff --git a/drivers/xen/Makefile b/drivers/xen/Makefile index 72bbb27..d8dc26a 100644 --- a/drivers/xen/Makefile +++ b/drivers/xen/Makefile @@ -14,7 +14,7 @@ obj-$(CONFIG_XEN_GNTDEV) += xen-gntdev.o obj-$(CONFIG_XEN_GRANT_DEV_ALLOC) += xen-gntalloc.o obj-$(CONFIG_XENFS) += xenfs/ obj-$(CONFIG_XEN_SYS_HYPERVISOR) += sys-hypervisor.o -obj-$(CONFIG_XEN_PLATFORM_PCI) += xen-platform-pci.o +obj-$(CONFIG_XEN_PVHVM) += xen-platform-pci.o obj-$(CONFIG_XEN_TMEM) += tmem.o obj-$(CONFIG_SWIOTLB_XEN) += swiotlb-xen.o obj-$(CONFIG_XEN_DOM0) += pci.o -- 1.7.2.3 _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel From xen-devel-bounces@lists.xensource.com Fri Sep 23 04:23:03 2011 Return-path: <xen-devel-bounces@lists.xensource.com> Envelope-to: www-data@lists.xensource.com Delivery-date: Fri, 23 Sep 2011 04:23:03 -0700 Received: from localhost ([127.0.0.1] helo=lists.colo.xensource.com) by lists.xensource.com with esmtp (Exim 4.43) id 1R73qR-0002wc-Hq; Fri, 23 Sep 2011 04:23:03 -0700 Received: from mail182.messagelabs.com ([85.158.139.83]) by lists.xensource.com with smtp (Exim 4.43) id 1R73pc-0002k7-ND for xen-devel@lists.xensource.com; Fri, 23 Sep 2011 04:22:13 -0700 X-Env-Sender: anthony@overnetdata.com X-Msg-Ref: server-6.tower-182.messagelabs.com!1316776928!18265808!1 X-Originating-IP: [81.137.131.225] X-StarScan-Version: 6.4.1; banners=-,-,- X-VirusChecked: Checked Received: (qmail 31748 invoked from network); 23 Sep 2011 11:22:08 -0000 Received: from host81-137-131-225.in-addr.btopenworld.com (HELO zimbra.overnetdata.com) (81.137.131.225) by server-6.tower-182.messagelabs.com with SMTP; 23 Sep 2011 11:22:08 -0000 Received: from localhost (localhost.localdomain [127.0.0.1]) by zimbra.overnetdata.com (Postfix) with ESMTP id 5E316161880 for <xen-devel@lists.xensource.com>; Fri, 23 Sep 2011 12:22:08 +0100 (BST) X-Virus-Scanned: amavisd-new at overnetdata.com Received: from zimbra.overnetdata.com ([127.0.0.1]) by localhost (zimbra.overnetdata.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QtcnXIoFqKem for <xen-devel@lists.xensource.com>; Fri, 23 Sep 2011 12:22:06 +0100 (BST) Received: from [192.168.1.63] (unknown [192.168.1.63]) by zimbra.overnetdata.com (Postfix) with ESMTPSA id 6B0A116187F for <xen-devel@lists.xensource.com>; Fri, 23 Sep 2011 12:22:06 +0100 (BST) Message-ID: <4E7C6BDC.8070005@overnetdata.com> Date: Fri, 23 Sep 2011 12:22:04 +0100 From: Anthony Wright <anthony@overnetdata.com> User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:6.0.2) Gecko/20110902 Thunderbird/6.0.2 MIME-Version: 1.0 To: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com> X-Enigmail-Version: 1.3.2 Content-Type: multipart/mixed; boundary="------------080306070905060602030106" Subject: [Xen-devel] dmidecode doesn't work under xen 4.1.1 on certain hardware X-BeenThere: xen-devel@lists.xensource.com X-Mailman-Version: 2.1.5 Precedence: list List-Id: Xen developer discussion <xen-devel.lists.xensource.com> List-Unsubscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe> List-Post: <mailto:xen-devel@lists.xensource.com> List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help> List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=subscribe> Sender: xen-devel-bounces@lists.xensource.com Errors-To: xen-devel-bounces@lists.xensource.com This is a multi-part message in MIME format. --------------080306070905060602030106 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit I have a xen 4.1.1 with a 3.0.4 linux kernel running on a Supermicro Supermicro X8DTL-iF motherboard with 16GB of RAM. If I run the 3.0.4 kernel on the bare metal dmidecode works fine. If I run it under xen dmidecode fails to work. On other systems with different hardware but identical software dmidecode works correctly under xen. On this hardware with xen 3.4.1 & linux 2.6.18, dmidecode works correctly under xen. The error message suggests to me that the bios data is partially available as it gets the number of structures correct, but is corrupted fairly early on. There are no DomUs running on the system. I have attached a good and a bad dmidecode output log. --------------080306070905060602030106 Content-Type: text/plain; name="supermicro-dmidecode-good.log" Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename="supermicro-dmidecode-good.log" # dmidecode 2.11 SMBIOS 2.6 present. 70 structures occupying 2851 bytes. Table at 0x00099C00. Handle 0x0000, DMI type 0, 24 bytes BIOS Information Vendor: American Megatrends Inc. Version: 2.0c Release Date: 01/05/11 Address: 0xF0000 Runtime Size: 64 kB ROM Size: 4096 kB Characteristics: ISA is supported PCI is supported PNP is supported BIOS is upgradeable BIOS shadowing is allowed ESCD support is available Boot from CD is supported Selectable boot is supported BIOS ROM is socketed EDD is supported 5.25"/1.2 MB floppy services are supported (int 13h) 3.5"/720 kB floppy services are supported (int 13h) 3.5"/2.88 MB floppy services are supported (int 13h) Print screen service is supported (int 5h) 8042 keyboard services are supported (int 9h) Serial services are supported (int 14h) Printer services are supported (int 17h) CGA/mono video services are supported (int 10h) ACPI is supported USB legacy is supported LS-120 boot is supported ATAPI Zip drive boot is supported BIOS boot specification is supported Targeted content distribution is supported BIOS Revision: 8.16 Handle 0x0001, DMI type 1, 27 bytes System Information Manufacturer: Supermicro Product Name: X8DTL Version: 1234567890 Serial Number: 1234567890 UUID: 49434D53-0200-9038-2500-389025002DD8 Wake-up Type: Power Switch SKU Number: To Be Filled By O.E.M. Family: Server Handle 0x0002, DMI type 2, 15 bytes Base Board Information Manufacturer: Supermicro Product Name: X8DTL Version: 1234567890 Serial Number: VM14S72123 Asset Tag: To Be Filled By O.E.M. Features: Board is a hosting board Board is replaceable Location In Chassis: To Be Filled By O.E.M. Chassis Handle: 0x0003 Type: Motherboard Contained Object Handles: 0 Handle 0x0003, DMI type 3, 21 bytes Chassis Information Manufacturer: Supermicro Type: Main Server Chassis Lock: Not Present Version: 1234567890 Serial Number: 1234567890 Asset Tag: To Be Filled By O.E.M. Boot-up State: Safe Power Supply State: Safe Thermal State: Safe Security Status: None OEM Information: 0x00000000 Height: Unspecified Number Of Power Cords: 1 Contained Elements: 0 Handle 0x0004, DMI type 4, 42 bytes Processor Information Socket Designation: CPU 1 Type: Central Processor Family: Xeon Manufacturer: Intel ID: A5 06 01 00 FF FB EB BF Signature: Type 0, Family 6, Model 26, Stepping 5 Flags: FPU (Floating-point unit on-chip) VME (Virtual mode extension) DE (Debugging extension) PSE (Page size extension) TSC (Time stamp counter) MSR (Model specific registers) PAE (Physical address extension) MCE (Machine check exception) CX8 (CMPXCHG8 instruction supported) APIC (On-chip APIC hardware supported) SEP (Fast system call) MTRR (Memory type range registers) PGE (Page global enable) MCA (Machine check architecture) CMOV (Conditional move instruction supported) PAT (Page attribute table) PSE-36 (36-bit page size extension) CLFSH (CLFLUSH instruction supported) DS (Debug store) ACPI (ACPI supported) MMX (MMX technology supported) FXSR (FXSAVE and FXSTOR instructions supported) SSE (Streaming SIMD extensions) SSE2 (Streaming SIMD extensions 2) SS (Self-snoop) HTT (Multi-threading) TM (Thermal monitor supported) PBE (Pending break enabled) Version: Intel(R) Xeon(R) CPU E5507 @ 2.27GHz Voltage: Unknown External Clock: 133 MHz Max Speed: 2266 MHz Current Speed: 2266 MHz Status: Populated, Enabled Upgrade: Other L1 Cache Handle: 0x0005 L2 Cache Handle: 0x0006 L3 Cache Handle: 0x0007 Serial Number: To Be Filled By O.E.M. Asset Tag: To Be Filled By O.E.M. Part Number: To Be Filled By O.E.M. Core Count: 4 Core Enabled: 4 Thread Count: 4 Characteristics: 64-bit capable Handle 0x0005, DMI type 7, 19 bytes Cache Information Socket Designation: L1-Cache Configuration: Enabled, Not Socketed, Level 1 Operational Mode: Write Through Location: Internal Installed Size: 256 kB Maximum Size: 256 kB Supported SRAM Types: Other Installed SRAM Type: Other Speed: Unknown Error Correction Type: Parity System Type: Instruction Associativity: 4-way Set-associative Handle 0x0006, DMI type 7, 19 bytes Cache Information Socket Designation: L2-Cache Configuration: Enabled, Not Socketed, Level 2 Operational Mode: Write Through Location: Internal Installed Size: 1024 kB Maximum Size: 1024 kB Supported SRAM Types: Other Installed SRAM Type: Other Speed: Unknown Error Correction Type: Single-bit ECC System Type: Unified Associativity: 8-way Set-associative Handle 0x0007, DMI type 7, 19 bytes Cache Information Socket Designation: L3-Cache Configuration: Enabled, Not Socketed, Level 3 Operational Mode: Write Back Location: Internal Installed Size: 4096 kB Maximum Size: 4096 kB Supported SRAM Types: Other Installed SRAM Type: Other Speed: Unknown Error Correction Type: Single-bit ECC System Type: Unified Associativity: 16-way Set-associative Handle 0x0008, DMI type 4, 42 bytes Processor Information Socket Designation: CPU 2 Type: Central Processor Family: Xeon Manufacturer: ID: 00 00 00 00 00 00 00 00 Signature: Type 0, Family 0, Model 0, Stepping 0 Flags: None Version: Voltage: 3.3 V 2.9 V External Clock: Unknown Max Speed: 2000 MHz Current Speed: Unknown Status: Unpopulated Upgrade: Other L1 Cache Handle: 0x0009 L2 Cache Handle: 0x000A L3 Cache Handle: 0x000B Serial Number: To Be Filled By O.E.M. Asset Tag: To Be Filled By O.E.M. Part Number: To Be Filled By O.E.M. Characteristics: None Handle 0x0009, DMI type 7, 19 bytes Cache Information Socket Designation: L1-Cache Configuration: Disabled, Not Socketed, Level 1 Operational Mode: Unknown Location: Internal Installed Size: 0 kB Maximum Size: 0 kB Supported SRAM Types: Unknown Installed SRAM Type: Unknown Speed: Unknown Error Correction Type: Unknown System Type: Unknown Associativity: Unknown Handle 0x000A, DMI type 7, 19 bytes Cache Information Socket Designation: L2-Cache Configuration: Disabled, Not Socketed, Level 2 Operational Mode: Unknown Location: Internal Installed Size: 0 kB Maximum Size: 0 kB Supported SRAM Types: Unknown Installed SRAM Type: Unknown Speed: Unknown Error Correction Type: Unknown System Type: Unknown Associativity: Unknown Handle 0x000B, DMI type 7, 19 bytes Cache Information Socket Designation: L3-Cache Configuration: Disabled, Not Socketed, Level 3 Operational Mode: Unknown Location: Internal Installed Size: 0 kB Maximum Size: 0 kB Supported SRAM Types: Unknown Installed SRAM Type: Unknown Speed: Unknown Error Correction Type: Unknown System Type: Unknown Associativity: Unknown Handle 0x000C, DMI type 8, 9 bytes Port Connector Information Internal Reference Designator: J1A1 Internal Connector Type: None External Reference Designator: PS2Mouse External Connector Type: PS/2 Port Type: Mouse Port Handle 0x000D, DMI type 8, 9 bytes Port Connector Information Internal Reference Designator: J1A1 Internal Connector Type: None External Reference Designator: Keyboard External Connector Type: PS/2 Port Type: Keyboard Port Handle 0x000E, DMI type 8, 9 bytes Port Connector Information Internal Reference Designator: J2A2 Internal Connector Type: None External Reference Designator: USB1 External Connector Type: Access Bus (USB) Port Type: USB Handle 0x000F, DMI type 8, 9 bytes Port Connector Information Internal Reference Designator: J2A2 Internal Connector Type: None External Reference Designator: USB2 External Connector Type: Access Bus (USB) Port Type: USB Handle 0x0010, DMI type 8, 9 bytes Port Connector Information Internal Reference Designator: J4A1 Internal Connector Type: None External Reference Designator: LPT 1 External Connector Type: DB-25 male Port Type: Parallel Port ECP/EPP Handle 0x0011, DMI type 8, 9 bytes Port Connector Information Internal Reference Designator: J2A1 Internal Connector Type: None External Reference Designator: COM A External Connector Type: DB-9 male Port Type: Serial Port 16550A Compatible Handle 0x0012, DMI type 8, 9 bytes Port Connector Information Internal Reference Designator: J6A1 Internal Connector Type: None External Reference Designator: Audio Mic In External Connector Type: Mini Jack (headphones) Port Type: Audio Port Handle 0x0013, DMI type 8, 9 bytes Port Connector Information Internal Reference Designator: J6A1 Internal Connector Type: None External Reference Designator: Audio Line In External Connector Type: Mini Jack (headphones) Port Type: Audio Port Handle 0x0014, DMI type 8, 9 bytes Port Connector Information Internal Reference Designator: J6B1 - AUX IN Internal Connector Type: On Board Sound Input From CD-ROM External Reference Designator: Not Specified External Connector Type: None Port Type: Audio Port Handle 0x0015, DMI type 8, 9 bytes Port Connector Information Internal Reference Designator: J6B2 - CDIN Internal Connector Type: On Board Sound Input From CD-ROM External Reference Designator: Not Specified External Connector Type: None Port Type: Audio Port Handle 0x0016, DMI type 8, 9 bytes Port Connector Information Internal Reference Designator: J6J2 - PRI IDE Internal Connector Type: On Board IDE External Reference Designator: Not Specified External Connector Type: None Port Type: Other Handle 0x0017, DMI type 8, 9 bytes Port Connector Information Internal Reference Designator: J6J1 - SEC IDE Internal Connector Type: On Board IDE External Reference Designator: Not Specified External Connector Type: None Port Type: Other Handle 0x0018, DMI type 8, 9 bytes Port Connector Information Internal Reference Designator: J4J1 - FLOPPY Internal Connector Type: On Board Floppy External Reference Designator: Not Specified External Connector Type: None Port Type: Other Handle 0x0019, DMI type 8, 9 bytes Port Connector Information Internal Reference Designator: J9H1 - FRONT PNL Internal Connector Type: 9 Pin Dual Inline (pin 10 cut) External Reference Designator: Not Specified External Connector Type: None Port Type: Other Handle 0x001A, DMI type 8, 9 bytes Port Connector Information Internal Reference Designator: J1B1 - CHASSIS REAR FAN Internal Connector Type: Other External Reference Designator: Not Specified External Connector Type: None Port Type: Other Handle 0x001B, DMI type 8, 9 bytes Port Connector Information Internal Reference Designator: J2F1 - CPU FAN Internal Connector Type: Other External Reference Designator: Not Specified External Connector Type: None Port Type: Other Handle 0x001C, DMI type 8, 9 bytes Port Connector Information Internal Reference Designator: J8B4 - FRONT FAN Internal Connector Type: Other External Reference Designator: Not Specified External Connector Type: None Port Type: Other Handle 0x001D, DMI type 8, 9 bytes Port Connector Information Internal Reference Designator: J9G2 - FNT USB Internal Connector Type: Other External Reference Designator: Not Specified External Connector Type: None Port Type: Other Handle 0x001E, DMI type 8, 9 bytes Port Connector Information Internal Reference Designator: J6C3 - FP AUD Internal Connector Type: Other External Reference Designator: Not Specified External Connector Type: None Port Type: Other Handle 0x001F, DMI type 8, 9 bytes Port Connector Information Internal Reference Designator: J9G1 - CONFIG Internal Connector Type: Other External Reference Designator: Not Specified External Connector Type: None Port Type: Other Handle 0x0020, DMI type 8, 9 bytes Port Connector Information Internal Reference Designator: J8C1 - SCSI LED Internal Connector Type: Other External Reference Designator: Not Specified External Connector Type: None Port Type: Other Handle 0x0021, DMI type 8, 9 bytes Port Connector Information Internal Reference Designator: J9J2 - INTRUDER Internal Connector Type: Other External Reference Designator: Not Specified External Connector Type: None Port Type: Other Handle 0x0022, DMI type 8, 9 bytes Port Connector Information Internal Reference Designator: J9G4 - ITP Internal Connector Type: Other External Reference Designator: Not Specified External Connector Type: None Port Type: Other Handle 0x0023, DMI type 8, 9 bytes Port Connector Information Internal Reference Designator: J2H1 - MAIN POWER Internal Connector Type: Other External Reference Designator: Not Specified External Connector Type: None Port Type: Other Handle 0x0024, DMI type 9, 17 bytes System Slot Information Designation: PCI1 Type: 32-bit PCI Current Usage: Available Length: Short ID: 1 Characteristics: 3.3 V is provided Opening is shared PME signal is supported Handle 0x0025, DMI type 9, 17 bytes System Slot Information Designation: PCI2 Type: 32-bit PCI Current Usage: Available Length: Short ID: 2 Characteristics: 3.3 V is provided Opening is shared PME signal is supported Handle 0x0026, DMI type 9, 17 bytes System Slot Information Designation: PCIE3 Type: x4 PCI Express x8 Current Usage: Available Length: Long ID: 3 Characteristics: 3.3 V is provided Opening is shared PME signal is supported Handle 0x0027, DMI type 9, 17 bytes System Slot Information Designation: PCIE4 Type: x8 PCI Express x8 Current Usage: Available Length: Short ID: 4 Characteristics: 3.3 V is provided Opening is shared PME signal is supported Handle 0x0028, DMI type 9, 17 bytes System Slot Information Designation: PCIE5 Type: x4 PCI Express x8 Current Usage: Available Length: Long ID: 5 Characteristics: 3.3 V is provided Opening is shared PME signal is supported Handle 0x0029, DMI type 9, 17 bytes System Slot Information Designation: PCIE6 Type: x8 PCI Express x16 Current Usage: Available Length: Long ID: 6 Characteristics: 3.3 V is provided Opening is shared PME signal is supported Handle 0x002A, DMI type 11, 5 bytes OEM Strings String 1: Intel Nehalem/Tylersburg/ICH10 String 2: Supermicro motherboard-X8 Series Handle 0x002B, DMI type 13, 22 bytes BIOS Language Information Language Description Format: Long Installable Languages: 1 en|US|iso8859-1 Currently Installed Language: en|US|iso8859-1 Handle 0x002C, DMI type 15, 55 bytes System Event Log Area Length: 1008 bytes Header Start Offset: 0x0810 Data Start Offset: 0x0810 Access Method: General-purpose non-volatile data functions Access Address: 0x0001 Status: Valid, Not Full Change Token: 0x00000000 Header Format: No Header Supported Log Type Descriptors: 15 Descriptor 1: OEM-specific Data Format 1: Multiple-event handle Descriptor 2: OEM-specific Data Format 2: Multiple-event handle Descriptor 3: Single-bit ECC memory error Data Format 3: Multiple-event handle Descriptor 4: Multi-bit ECC memory error Data Format 4: Multiple-event handle Descriptor 5: Parity memory error Data Format 5: Multiple-event Descriptor 6: I/O channel block Data Format 6: Multiple-event Descriptor 7: POST error Data Format 7: POST results bitmap Descriptor 8: PCI parity error Data Format 8: Multiple-event handle Descriptor 9: PCI system error Data Format 9: Multiple-event handle Descriptor 10: System limit exceeded Data Format 10: Multiple-event system management Descriptor 11: OEM-specific Data Format 11: POST results bitmap Descriptor 12: OEM-specific Data Format 12: Multiple-event handle Descriptor 13: OEM-specific Data Format 13: Multiple-event handle Descriptor 14: OEM-specific Data Format 14: Multiple-event handle Descriptor 15: OEM-specific Data Format 15: Multiple-event handle Handle 0x002D, DMI type 16, 15 bytes Physical Memory Array Location: System Board Or Motherboard Use: System Memory Error Correction Type: Multi-bit ECC Maximum Capacity: 96 GB Error Information Handle: Not Provided Number Of Devices: 3 Handle 0x002E, DMI type 19, 15 bytes Memory Array Mapped Address Starting Address: 0x00000000000 Ending Address: 0x003FFFFFFFF Range Size: 16 GB Physical Array Handle: 0x002D Partition Width: 3 Handle 0x002F, DMI type 17, 28 bytes Memory Device Array Handle: 0x002D Error Information Handle: Not Provided Total Width: 72 bits Data Width: 64 bits Size: No Module Installed Form Factor: DIMM Set: None Locator: P2_DIMM1A Bank Locator: BANK Type: Other Type Detail: Other Speed: Unknown Manufacturer: Manufacturer00 Serial Number: SerNum00 Asset Tag: AssetTagNum0 Part Number: ModulePartNumber00 Rank: Unknown Handle 0x0030, DMI type 20, 19 bytes Memory Device Mapped Address Starting Address: 0x00000000000 Ending Address: 0x001FFFFFFFF Range Size: 8 GB Physical Device Handle: 0x002F Memory Array Mapped Address Handle: 0x002E Partition Row Position: 1 Interleave Position: Unknown Interleaved Data Depth: 2 Handle 0x0031, DMI type 17, 28 bytes Memory Device Array Handle: 0x002D Error Information Handle: Not Provided Total Width: 72 bits Data Width: 64 bits Size: No Module Installed Form Factor: DIMM Set: None Locator: P2_DIMM2A Bank Locator: BANK Type: Other Type Detail: Other Speed: Unknown Manufacturer: Manufacturer01 Serial Number: SerNum01 Asset Tag: AssetTagNum1 Part Number: ModulePartNumber01 Rank: Unknown Handle 0x0032, DMI type 20, 19 bytes Memory Device Mapped Address Starting Address: 0x00000000000 Ending Address: 0x000000003FF Range Size: 1 kB Physical Device Handle: 0x0031 Memory Array Mapped Address Handle: 0x002E Partition Row Position: 1 Interleave Position: Unknown Interleaved Data Depth: 2 Handle 0x0033, DMI type 17, 28 bytes Memory Device Array Handle: 0x002D Error Information Handle: Not Provided Total Width: 72 bits Data Width: 64 bits Size: No Module Installed Form Factor: DIMM Set: None Locator: P2_DIMM3A Bank Locator: BANK Type: Other Type Detail: Other Speed: Unknown Manufacturer: Manufacturer02 Serial Number: SerNum02 Asset Tag: AssetTagNum2 Part Number: ModulePartNumber02 Rank: Unknown Handle 0x0034, DMI type 20, 19 bytes Memory Device Mapped Address Starting Address: 0x00000000000 Ending Address: 0x000000003FF Range Size: 1 kB Physical Device Handle: 0x0033 Memory Array Mapped Address Handle: 0x002E Partition Row Position: 1 Interleave Position: Unknown Interleaved Data Depth: 2 Handle 0x0035, DMI type 16, 15 bytes Physical Memory Array Location: System Board Or Motherboard Use: System Memory Error Correction Type: Multi-bit ECC Maximum Capacity: 96 GB Error Information Handle: Not Provided Number Of Devices: 3 Handle 0x0036, DMI type 19, 15 bytes Memory Array Mapped Address Starting Address: 0x00000000000 Ending Address: 0x000000003FF Range Size: 1 kB Physical Array Handle: 0x0035 Partition Width: 3 Handle 0x0037, DMI type 17, 28 bytes Memory Device Array Handle: 0x0035 Error Information Handle: Not Provided Total Width: 72 bits Data Width: 64 bits Size: 8192 MB Form Factor: DIMM Set: None Locator: P1_DIMM1A Bank Locator: BANK Type: Other Type Detail: Other Speed: 800 MHz Manufacturer: Samsung Serial Number: 3F088E82 Asset Tag: AssetTagNum3 Part Number: M393B1K70CH0-CH9 Rank: Unknown Handle 0x0038, DMI type 20, 19 bytes Memory Device Mapped Address Starting Address: 0x00200000000 Ending Address: 0x003FFFFFFFF Range Size: 8 GB Physical Device Handle: 0x0037 Memory Array Mapped Address Handle: 0x0036 Partition Row Position: 1 Interleave Position: Unknown Interleaved Data Depth: 2 Handle 0x0039, DMI type 17, 28 bytes Memory Device Array Handle: 0x0035 Error Information Handle: Not Provided Total Width: 72 bits Data Width: 64 bits Size: 8192 MB Form Factor: DIMM Set: None Locator: P1_DIMM2A Bank Locator: BANK Type: Other Type Detail: Other Speed: 800 MHz Manufacturer: Samsung Serial Number: 54088E82 Asset Tag: AssetTagNum4 Part Number: M393B1K70CH0-CH9 Rank: Unknown Handle 0x003A, DMI type 20, 19 bytes Memory Device Mapped Address Starting Address: 0x00000000000 Ending Address: 0x000000003FF Range Size: 1 kB Physical Device Handle: 0x0039 Memory Array Mapped Address Handle: 0x0036 Partition Row Position: 1 Interleave Position: Unknown Interleaved Data Depth: 2 Handle 0x003B, DMI type 17, 28 bytes Memory Device Array Handle: 0x0035 Error Information Handle: Not Provided Total Width: 72 bits Data Width: 64 bits Size: No Module Installed Form Factor: DIMM Set: None Locator: P1_DIMM3A Bank Locator: BANK Type: Other Type Detail: Other Speed: Unknown Manufacturer: Manufacturer05 Serial Number: SerNum05 Asset Tag: AssetTagNum5 Part Number: ModulePartNumber05 Rank: Unknown Handle 0x003C, DMI type 20, 19 bytes Memory Device Mapped Address Starting Address: 0x00000000000 Ending Address: 0x000000003FF Range Size: 1 kB Physical Device Handle: 0x003B Memory Array Mapped Address Handle: 0x0036 Partition Row Position: 1 Interleave Position: Unknown Interleaved Data Depth: 2 Handle 0x003D, DMI type 16, 15 bytes Physical Memory Array Location: System Board Or Motherboard Use: Flash Memory Error Correction Type: None Maximum Capacity: 4 MB Error Information Handle: Not Provided Number Of Devices: 1 Handle 0x003E, DMI type 19, 15 bytes Memory Array Mapped Address Starting Address: 0x00000000000 Ending Address: 0x000003FFFFF Range Size: 4 MB Physical Array Handle: 0x003D Partition Width: 1 Handle 0x003F, DMI type 17, 28 bytes Memory Device Array Handle: 0x003D Error Information Handle: Not Provided Total Width: 8 bits Data Width: 8 bits Size: 4096 kB Form Factor: Other Set: None Locator: BIOS Bank Locator: ROM0 Type: Flash Type Detail: Non-Volatile Speed: 33 MHz Manufacturer: ATMEL Serial Number: Asset Tag: Part Number: 26DF321 Rank: Unknown Handle 0x0040, DMI type 20, 19 bytes Memory Device Mapped Address Starting Address: 0x000FFC00000 Ending Address: 0x000FFFFFFFF Range Size: 4 MB Physical Device Handle: 0x003F Memory Array Mapped Address Handle: 0x003E Partition Row Position: <OUT OF SPEC> Handle 0x0041, DMI type 32, 20 bytes System Boot Information Status: No errors detected Handle 0x0042, DMI type 38, 18 bytes IPMI Device Information Interface Type: KCS (Keyboard Control Style) Specification Version: 2.0 I2C Slave Address: 0x00 NV Storage Device: Not Present Base Address: 0x0000000000000CA2 (I/O) Register Spacing: Successive Byte Boundaries Handle 0x0043, DMI type 41, 11 bytes Onboard Device Reference Designation: To Be Filled By O.E.M. Type: Video Status: Enabled Type Instance: 0 Handle 0x0044, DMI type 41, 11 bytes Onboard Device Reference Designation: To Be Filled By O.E.M. Type: SCSI Controller Status: Disabled Type Instance: 0 Handle 0x0045, DMI type 127, 4 bytes End Of Table --------------080306070905060602030106 Content-Type: text/plain; name="supermicro-dmidecode-failed.log" Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename="supermicro-dmidecode-failed.log" # dmidecode 2.11 SMBIOS 2.6 present. 70 structures occupying 2851 bytes. Table at 0x00099C00. Invalid entry length (0). DMI table is broken! Stop. --------------080306070905060602030106 Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel --------------080306070905060602030106-- From xen-devel-bounces@lists.xensource.com Fri Sep 23 04:35:12 2011 Return-path: <xen-devel-bounces@lists.xensource.com> Envelope-to: www-data@lists.xensource.com Delivery-date: Fri, 23 Sep 2011 04:35:12 -0700 Received: from localhost ([127.0.0.1] helo=lists.colo.xensource.com) by lists.xensource.com with esmtp (Exim 4.43) id 1R742A-0003gt-EW; Fri, 23 Sep 2011 04:35:10 -0700 Received: from mail182.messagelabs.com ([85.158.139.83]) by lists.xensource.com with esmtp (Exim 4.43) id 1R741L-0003UT-NC for xen-devel@lists.xensource.com; Fri, 23 Sep 2011 04:34:20 -0700 X-Env-Sender: javier.manzano@edu.uah.es X-Msg-Ref: server-5.tower-182.messagelabs.com!1316777655!14491086!1 X-Originating-IP: [216.139.236.26] X-StarScan-Version: 6.4.1; banners=-,-,- X-VirusChecked: Checked Received: (qmail 13146 invoked from network); 23 Sep 2011 11:34:16 -0000 Received: from sam.nabble.com (HELO sam.nabble.com) (216.139.236.26) by server-5.tower-182.messagelabs.com with AES256-SHA encrypted SMTP; 23 Sep 2011 11:34:16 -0000 Received: from [192.168.236.26] (helo=sam.nabble.com) by sam.nabble.com with esmtp (Exim 4.72) (envelope-from <javier.manzano@edu.uah.es>) id 1R741G-00027p-JV for xen-devel@lists.xensource.com; Fri, 23 Sep 2011 04:34:14 -0700 Date: Fri, 23 Sep 2011 04:34:14 -0700 (PDT) From: JavMV <javier.manzano@edu.uah.es> To: xen-devel@lists.xensource.com Message-ID: <1316777654598-4833174.post@n5.nabble.com> In-Reply-To: <1316728444821-4831624.post@n5.nabble.com> References: <1316613404292-4826432.post@n5.nabble.com> <1316614084705-4826479.post@n5.nabble.com> <1316615526442-4826582.post@n5.nabble.com> <1316616001843-4826614.post@n5.nabble.com> <1316616472579-4826635.post@n5.nabble.com> <1316616757871-4826655.post@n5.nabble.com> <1316618006.67296.YahooMailNeo@web29818.mail.ird.yahoo.com> <1316693722029-4829929.post@n5.nabble.com> <20110922182705.GE12984@reaktio.net> <1316728444821-4831624.post@n5.nabble.com> Subject: Re: Re : Re : Re : Re : [Xen-devel] Re: Patches for VGA-Passthrough XEN 4.2 unstable MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-BeenThere: xen-devel@lists.xensource.com X-Mailman-Version: 2.1.5 Precedence: list List-Id: Xen developer discussion <xen-devel.lists.xensource.com> List-Unsubscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe> List-Post: <mailto:xen-devel@lists.xensource.com> List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help> List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=subscribe> Sender: xen-devel-bounces@lists.xensource.com Errors-To: xen-devel-bounces@lists.xensource.com Hello, I have update my BIOS trying to fix the problem, my Board is an Intel DQ35MP, the previous version of my BIOS was 0882 (date 2008), now I have the version 1143 (the latest version available, it is from 2010). With all of these changes the problem persist but I found another "idiot" thing ^^ look at this lines: multiboot /boot/xen-4.2-unstable.gz placeholder module /boot/vmlinuz-2.6.32.45 placeholder root=UUID=..... ro iommu=force module /boot/intrd.img-2.6.32.45 The option iommu=force is in wrong place! This is because I configure it using /etc/default/grub, well the option must be in the first line with /boot/xen so I modified manually while grub menu show up (by pressing 'E') *Now I have VT-d enabled! * I will write later I hope telling you I finally did vga-passthru XD ----- JavMV -- View this message in context: http://xen.1045712.n5.nabble.com/Patches-for-VGA-Passthrough-XEN-4-2-unstable-tp4406265p4833174.html Sent from the Xen - Dev mailing list archive at Nabble.com. _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel From xen-devel-bounces@lists.xensource.com Fri Sep 23 05:00:17 2011 Return-path: <xen-devel-bounces@lists.xensource.com> Envelope-to: www-data@lists.xensource.com Delivery-date: Fri, 23 Sep 2011 05:00:17 -0700 Received: from localhost ([127.0.0.1] helo=lists.colo.xensource.com) by lists.xensource.com with esmtp (Exim 4.43) id 1R74QS-00057z-0g; Fri, 23 Sep 2011 05:00:16 -0700 Received: from mail21.messagelabs.com ([85.158.143.35]) by lists.xensource.com with esmtp (Exim 4.43) id 1R74Nm-0004t7-9g for xen-devel@lists.xensource.com; Fri, 23 Sep 2011 04:57:30 -0700 X-Env-Sender: royger@gmail.com X-Msg-Ref: server-7.tower-21.messagelabs.com!1316779016!55966008!1 X-Originating-IP: [74.125.82.43] X-StarScan-Version: 6.4.1; banners=-,-,- X-VirusChecked: Checked Received: (qmail 1602 invoked from network); 23 Sep 2011 11:56:56 -0000 Received: from mail-ww0-f43.google.com (HELO mail-ww0-f43.google.com) (74.125.82.43) by server-7.tower-21.messagelabs.com with RC4-SHA encrypted SMTP; 23 Sep 2011 11:56:56 -0000 Received: by wwf27 with SMTP id 27so2934885wwf.24 for <xen-devel@lists.xensource.com>; Fri, 23 Sep 2011 04:57:26 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=sender:content-type:mime-version:content-transfer-encoding:subject :x-mercurial-node:message-id:user-agent:date:from:to; bh=dMW4jqO+BAGbiHGLqcbc7/yLdXwgrg2coTdx8GmVhNA=; b=BtE0zNtxPjSFv3jzUKWViH7YJYe/O5lvw8gihT+jbUalaID2JpgXVmGIEZshG555YI 5ywQ2M62yjpySTanhyPy20hIQDusFATfx3Uts5uZgk0+V9m+2jhBrlYW76v8cASDRFNK yP1xui1853gtsgXVQtAY9s/eBg+z1XU0pK6rw= Received: by 10.216.158.76 with SMTP id p54mr4899201wek.86.1316779046594; Fri, 23 Sep 2011 04:57:26 -0700 (PDT) Received: from [127.0.0.1] (monk.upc.es. [147.83.39.235]) by mx.google.com with ESMTPS id l18sm12372767wbo.23.2011.09.23.04.57.24 (version=TLSv1/SSLv3 cipher=OTHER); Fri, 23 Sep 2011 04:57:25 -0700 (PDT) Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Mercurial-Node: 1d42b1b355c231e794a56dfadf3ee450346e3516 Message-Id: <1d42b1b355c231e794a5.1316778942@loki> User-Agent: Mercurial-patchbomb/1.8.4 Date: Fri, 23 Sep 2011 13:55:42 +0200 From: Roger Pau Monne <roger.pau@entel.upc.edu> To: xen-devel@lists.xensource.com Subject: [Xen-devel] [PATCH] libxl: add custom disconnect functions for different device types X-BeenThere: xen-devel@lists.xensource.com X-Mailman-Version: 2.1.5 Precedence: list List-Id: Xen developer discussion <xen-devel.lists.xensource.com> List-Unsubscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe> List-Post: <mailto:xen-devel@lists.xensource.com> List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help> List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=subscribe> Sender: xen-devel-bounces@lists.xensource.com Errors-To: xen-devel-bounces@lists.xensource.com # HG changeset patch # User Roger Pau Monne <roger.pau@entel.upc.edu> # Date 1316778937 -7200 # Node ID 1d42b1b355c231e794a56dfadf3ee450346e3516 # Parent 0ab9f548890e5e58122f73aa1c4164fd6e319b1c libxl: add custom disconnect functions for different device types. This patch creates a new struct, called libxl__disconnect that can be used to assign different functions that will be called to check if the device is disconnected and to add it to the shutdown watch. Added a helper function to get the libxl__device_kind from a be_path. The only device that has a different shutdown mechanism right now is vbd. diff -r 0ab9f548890e -r 1d42b1b355c2 tools/libxl/libxl_device.c --- a/tools/libxl/libxl_device.c Fri Sep 23 13:31:51 2011 +0200 +++ b/tools/libxl/libxl_device.c Fri Sep 23 13:55:37 2011 +0200 @@ -38,6 +38,27 @@ static const char *string_of_kinds[] = { [DEVICE_CONSOLE] = "console", }; +static const libxl__disconnect disconnect_vbd = { + .watch_for_disconnect = libxl__watch_for_disconnect_vbd, + .has_disconnected = libxl__has_disconnected_vbd, +}; + +static const libxl__disconnect disconnect_generic = { + .watch_for_disconnect = libxl__watch_for_disconnect_generic, + .has_disconnected = libxl__has_disconnected_generic, +}; + +static const libxl__disconnect *disconnect_ops[] = { + [DEVICE_UNKNOWN] = &disconnect_generic, + [DEVICE_VIF] = &disconnect_generic, + [DEVICE_VBD] = &disconnect_vbd, + [DEVICE_QDISK] = &disconnect_generic, + [DEVICE_PCI] = &disconnect_generic, + [DEVICE_VFB] = &disconnect_generic, + [DEVICE_VKBD] = &disconnect_generic, + [DEVICE_CONSOLE] = &disconnect_generic, +}; + char *libxl__device_frontend_path(libxl__gc *gc, libxl__device *device) { char *dom_path = libxl__xs_get_dompath(gc, device->domid); @@ -59,6 +80,18 @@ char *libxl__device_backend_path(libxl__ device->domid, device->devid); } +libxl__device_kinds libxl__device_identify(char *be_path) +{ + int len = sizeof(string_of_kinds)/sizeof(char *); + + for (int j = 1; j < len; j++) { + if (strstr(be_path, string_of_kinds[j])) + return j; + } + + return DEVICE_UNKNOWN; +} + int libxl__device_generic_add(libxl__gc *gc, libxl__device *device, char **bents, char **fents) { @@ -371,15 +404,11 @@ int libxl__device_destroy(libxl__gc *gc, libxl_ctx *ctx = libxl__gc_owner(gc); xs_transaction_t t; char *state_path = libxl__sprintf(gc, "%s/state", be_path); - char *state = libxl__xs_read(gc, XBT_NULL, state_path); + libxl__device_kinds device_type = libxl__device_identify(be_path); int rc = 0; - if (!state) + if (disconnect_ops[device_type]->has_disconnected(gc, be_path)) goto out; - if (atoi(state) != 4) { - xs_rm(ctx->xsh, XBT_NULL, be_path); - goto out; - } retry_transaction: t = xs_transaction_start(ctx->xsh); @@ -394,7 +423,7 @@ retry_transaction: } } if (!force) { - xs_watch(ctx->xsh, state_path, be_path); + disconnect_ops[device_type]->watch_for_disconnect(gc, be_path); rc = 1; } else { xs_rm(ctx->xsh, XBT_NULL, be_path); @@ -410,6 +439,7 @@ static int wait_for_dev_destroy(libxl__g unsigned int n; fd_set rfds; char **l1 = NULL; + libxl__device_kinds device_type; rc = 1; nfds = xs_fileno(ctx->xsh) + 1; @@ -418,11 +448,9 @@ static int wait_for_dev_destroy(libxl__g if (select(nfds, &rfds, NULL, NULL, tv) > 0) { l1 = xs_read_watch(ctx->xsh, &n); if (l1 != NULL) { - char *state = libxl__xs_read(gc, XBT_NULL, l1[XS_WATCH_PATH]); - if (!state || atoi(state) == 6) { + device_type = libxl__device_identify(l1[XS_WATCH_TOKEN]); + if (disconnect_ops[device_type]->has_disconnected(gc, l1[XS_WATCH_TOKEN])) { xs_unwatch(ctx->xsh, l1[0], l1[1]); - xs_rm(ctx->xsh, XBT_NULL, l1[XS_WATCH_TOKEN]); - LIBXL__LOG(ctx, LIBXL__LOG_DEBUG, "Destroyed device backend at %s", l1[XS_WATCH_TOKEN]); rc = 0; } free(l1); @@ -528,6 +556,62 @@ out: return rc; } +int libxl__watch_for_disconnect_vbd(libxl__gc *gc, char *be_path) +{ + libxl_ctx *ctx = libxl__gc_owner(gc); + char *hotplug_path = libxl__sprintf(gc, "%s/hotplug-status", be_path); + + xs_watch(ctx->xsh, hotplug_path, be_path); + + return 1; +} + +int libxl__has_disconnected_vbd(libxl__gc *gc, char *be_path) +{ + libxl_ctx *ctx = libxl__gc_owner(gc); + char *hotplug_path = libxl__sprintf(gc, "%s/hotplug-status", be_path); + char *hotplug = libxl__xs_read(gc, XBT_NULL, hotplug_path); + int rc = 0; + + if (!hotplug || !strcmp(hotplug, "disconnected")) { + xs_rm(ctx->xsh, XBT_NULL, be_path); + LIBXL__LOG(ctx, LIBXL__LOG_DEBUG, + "Destroyed device backend at %s", + be_path); + rc = 1; + } + + return rc; +} + +int libxl__watch_for_disconnect_generic(libxl__gc *gc, char *be_path) +{ + libxl_ctx *ctx = libxl__gc_owner(gc); + char *state_path = libxl__sprintf(gc, "%s/state", be_path); + + xs_watch(ctx->xsh, state_path, be_path); + + return 1; +} + +int libxl__has_disconnected_generic(libxl__gc *gc, char *be_path) +{ + libxl_ctx *ctx = libxl__gc_owner(gc); + char *state_path = libxl__sprintf(gc, "%s/state", be_path); + char *state = libxl__xs_read(gc, XBT_NULL, state_path); + int rc = 0; + + if (!state || atoi(state) != 4) { + xs_rm(ctx->xsh, XBT_NULL, be_path); + LIBXL__LOG(ctx, LIBXL__LOG_DEBUG, + "Destroyed device backend at %s", + be_path); + rc = 1; + } + + return rc; +} + int libxl__wait_for_device_model(libxl__gc *gc, uint32_t domid, char *state, libxl__device_model_starting *starting, diff -r 0ab9f548890e -r 1d42b1b355c2 tools/libxl/libxl_internal.h --- a/tools/libxl/libxl_internal.h Fri Sep 23 13:31:51 2011 +0200 +++ b/tools/libxl/libxl_internal.h Fri Sep 23 13:55:37 2011 +0200 @@ -95,7 +95,8 @@ struct libxl__ctx { }; typedef enum { - DEVICE_VIF = 1, + DEVICE_UNKNOWN = 0, + DEVICE_VIF, DEVICE_VBD, DEVICE_QDISK, DEVICE_PCI, @@ -206,6 +207,12 @@ _hidden int libxl__domain_save_device_mo _hidden void libxl__userdata_destroyall(libxl__gc *gc, uint32_t domid); /* from xl_device */ + +typedef struct { + int (*watch_for_disconnect)(libxl__gc *gc, char *be_path); + int (*has_disconnected)(libxl__gc *gc, char *be_path); +} libxl__disconnect; + _hidden char *libxl__device_disk_string_of_backend(libxl_disk_backend backend); _hidden char *libxl__device_disk_string_of_format(libxl_disk_format format); _hidden int libxl__device_disk_set_backend(libxl__gc*, libxl_device_disk*); @@ -226,6 +233,11 @@ _hidden int libxl__device_del(libxl__gc _hidden int libxl__device_destroy(libxl__gc *gc, char *be_path, int force); _hidden int libxl__devices_destroy(libxl__gc *gc, uint32_t domid, int force); _hidden int libxl__wait_for_backend(libxl__gc *gc, char *be_path, char *state); +_hidden int libxl__watch_for_disconnect_vbd(libxl__gc *gc, char *be_path); +_hidden int libxl__has_disconnected_vbd(libxl__gc *gc, char *be_path); +_hidden int libxl__watch_for_disconnect_generic(libxl__gc *gc, char *be_path); +_hidden int libxl__has_disconnected_generic(libxl__gc *gc, char *be_path); +_hidden libxl__device_kinds libxl__device_identify(char *be_path); /* from libxl_pci */ _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel From xen-devel-bounces@lists.xensource.com Fri Sep 23 05:08:13 2011 Return-path: <xen-devel-bounces@lists.xensource.com> Envelope-to: www-data@lists.xensource.com Delivery-date: Fri, 23 Sep 2011 05:08:13 -0700 Received: from localhost ([127.0.0.1] helo=lists.colo.xensource.com) by lists.xensource.com with esmtp (Exim 4.43) id 1R74Y8-0005gY-He; Fri, 23 Sep 2011 05:08:12 -0700 Received: from mail27.messagelabs.com ([193.109.254.147]) by lists.xensource.com with smtp (Exim 4.43) id 1R74VW-0005ST-Bo for xen-devel@lists.xensource.com; Fri, 23 Sep 2011 05:05:32 -0700 X-Env-Sender: anthony@overnetdata.com X-Msg-Ref: server-10.tower-27.messagelabs.com!1316779498!36947382!1 X-Originating-IP: [81.137.131.225] X-StarScan-Version: 6.4.1; banners=-,-,- X-VirusChecked: Checked Received: (qmail 21423 invoked from network); 23 Sep 2011 12:05:02 -0000 Received: from host81-137-131-225.in-addr.btopenworld.com (HELO zimbra.overnetdata.com) (81.137.131.225) by server-10.tower-27.messagelabs.com with SMTP; 23 Sep 2011 12:05:02 -0000 Received: from localhost (localhost.localdomain [127.0.0.1]) by zimbra.overnetdata.com (Postfix) with ESMTP id 4810516187F; Fri, 23 Sep 2011 13:04:49 +0100 (BST) X-Virus-Scanned: amavisd-new at overnetdata.com Received: from zimbra.overnetdata.com ([127.0.0.1]) by localhost (zimbra.overnetdata.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KYM7VU2CjdaT; Fri, 23 Sep 2011 13:04:30 +0100 (BST) Received: from [192.168.1.60] (unknown [192.168.1.60]) by zimbra.overnetdata.com (Postfix) with ESMTPSA id 0468F1616D8; Fri, 23 Sep 2011 13:04:29 +0100 (BST) Message-ID: <4E7C75CB.3010509@overnetdata.com> Date: Fri, 23 Sep 2011 13:04:27 +0100 From: Anthony Wright <anthony@overnetdata.com> User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:6.0.2) Gecko/20110902 Thunderbird/6.0.2 MIME-Version: 1.0 To: Jan Beulich <JBeulich@suse.com> Subject: Re: [Xen-devel] Getting IOAPIC errors in xl dmesg on old hardware References: <4E7C60B1.3000901@overnetdata.com> <4E7C803E02000078000578A3@nat28.tlf.novell.com> In-Reply-To: <4E7C803E02000078000578A3@nat28.tlf.novell.com> X-Enigmail-Version: 1.3.2 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com> X-BeenThere: xen-devel@lists.xensource.com X-Mailman-Version: 2.1.5 Precedence: list List-Id: Xen developer discussion <xen-devel.lists.xensource.com> List-Unsubscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe> List-Post: <mailto:xen-devel@lists.xensource.com> List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help> List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=subscribe> Sender: xen-devel-bounces@lists.xensource.com Errors-To: xen-devel-bounces@lists.xensource.com On 23/09/2011 11:49, Jan Beulich wrote: >>>> On 23.09.11 at 12:34, Anthony Wright <anthony@overnetdata.com> wrote: >> I am getting a series of IOAPIC errors in xl dmesg on a Dell OptiPlex >> GX100 machine (bought in 2000). I also get an error from traps.c which >> is very similar to the one in the 'Getting mm.c errors from xl dmesg on >> certain hardware' thread. This happens during system startup with no >> DomUs running. I have attached the xl dmesg log. > Seems like the kernel is trying to use IO-APIC despite the LAPIC being > unavailable. Is this with a pv-ops kernel or a forward port one? Which > version? Sorry - this is xen 4.1.1 with vanilla linux 3.0.4 > Also, did you try following what this message > > (XEN) Local APIC disabled by BIOS -- you can enable it with "lapic" I tried putting lapic on the xen command line, and while I got a message in dmesg saying it had been disabled in the bios, but then re-enabled, the IOAPIC errors were still present. _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel From xen-devel-bounces@lists.xensource.com Fri Sep 23 05:10:02 2011 Return-path: <xen-devel-bounces@lists.xensource.com> Envelope-to: www-data@lists.xensource.com Delivery-date: Fri, 23 Sep 2011 05:10:02 -0700 Received: from localhost ([127.0.0.1] helo=lists.colo.xensource.com) by lists.xensource.com with esmtp (Exim 4.43) id 1R74Zs-00063v-LL; Fri, 23 Sep 2011 05:10:00 -0700 Received: from mail27.messagelabs.com ([193.109.254.147]) by lists.xensource.com with esmtp (Exim 4.43) id 1R74X9-0005UM-6h for xen-devel@lists.xensource.com; Fri, 23 Sep 2011 05:07:12 -0700 X-Env-Sender: Stefano.Stabellini@eu.citrix.com X-Msg-Ref: server-10.tower-27.messagelabs.com!1316779607!36947654!1 X-Originating-IP: [62.200.22.115] X-StarScan-Version: 6.4.1; banners=-,-,- X-VirusChecked: Checked Received: (qmail 26130 invoked from network); 23 Sep 2011 12:06:47 -0000 Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115) by server-10.tower-27.messagelabs.com with RC4-SHA encrypted SMTP; 23 Sep 2011 12:06:47 -0000 X-IronPort-AV: E=Sophos;i="4.68,430,1312156800"; d="scan'208";a="8028410" Received: from lonpmailmx01.citrite.net ([10.30.203.162]) by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5; 23 Sep 2011 12:07:08 +0000 Received: from kaball.uk.xensource.com (10.80.2.59) by LONPMAILMX01.citrite.net (10.30.203.162) with Microsoft SMTP Server id 8.3.137.0; Fri, 23 Sep 2011 13:07:08 +0100 Date: Fri, 23 Sep 2011 13:07:11 +0100 From: Stefano Stabellini <stefano.stabellini@eu.citrix.com> X-X-Sender: sstabellini@kaball-desktop To: Juergen Gross <juergen.gross@ts.fujitsu.com> Subject: Re: [Xen-devel] [PATCH v5 1/4] Introduce git-checkout.sh In-Reply-To: <4E79BB11.5040005@ts.fujitsu.com> Message-ID: <alpine.DEB.2.00.1109231220390.8700@kaball-desktop> References: <alpine.DEB.2.00.1109211051270.8700@kaball-desktop> <1316598917-21515-1-git-send-email-stefano.stabellini@eu.citrix.com> <4E79BB11.5040005@ts.fujitsu.com> User-Agent: Alpine 2.00 (DEB 1167 2008-08-23) MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Cc: Ian Campbell <Ian.Campbell@eu.citrix.com>, "keir@xen.org" <keir@xen.org>, "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>, Ian Jackson <Ian.Jackson@eu.citrix.com>, Stefano Stabellini <Stefano.Stabellini@eu.citrix.com> X-BeenThere: xen-devel@lists.xensource.com X-Mailman-Version: 2.1.5 Precedence: list List-Id: Xen developer discussion <xen-devel.lists.xensource.com> List-Unsubscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe> List-Post: <mailto:xen-devel@lists.xensource.com> List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help> List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=subscribe> Sender: xen-devel-bounces@lists.xensource.com Errors-To: xen-devel-bounces@lists.xensource.com On Wed, 21 Sep 2011, Juergen Gross wrote: > On 09/21/2011 11:55 AM, stefano.stabellini@eu.citrix.com wrote: > > Introduce a script to perform git checkout on an external git tree; use > > git-checkout.sh in ioemu-dir-find. > > > > Signed-off-by: Stefano Stabellini<stefano.stabellini@eu.citrix.com> > > > > diff --git a/.hgignore b/.hgignore > > --- a/.hgignore > > +++ b/.hgignore > > @@ -291,7 +291,7 @@ > > ^tools/xm-test/lib/XmTestLib/config.py$ > > ^tools/xm-test/lib/XmTestReport/xmtest.py$ > > ^tools/xm-test/tests/.*\.test$ > > -^tools/ioemu-remote > > +^tools/ioemu-dir-remote > > ^tools/ioemu-dir$ > > ^tools/ocaml/.*/.*\.annot$ > > ^tools/ocaml/.*/.*\.cmx?a$ > > diff --git a/scripts/git-checkout.sh b/scripts/git-checkout.sh > > new file mode 100755 > > --- /dev/null > > +++ b/scripts/git-checkout.sh > > @@ -0,0 +1,21 @@ > > +#!/bin/sh > > + > > +TREE=$1 > > +TAG=$2 > > +DIR=$3 > > + > > + > > +if test \! -d $DIR-remote; then > > + rm -rf $DIR-remote $DIR-remote.tmp; > > + mkdir $DIR-remote.tmp; rmdir $DIR-remote.tmp; > > + git clone $TREE $DIR-remote.tmp; > > + if test "$TAG" ; then > > + cd $DIR-remote.tmp > > + git branch -D dummy>/dev/null 2>&1 ||: > > + git checkout -b dummy $TAG > > Can't you use $GIT here? > This would enable using GIT="socksify git" (e.g. behind a firewall). > Yes, I have made the change. _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel From xen-devel-bounces@lists.xensource.com Fri Sep 23 05:11:58 2011 Return-path: <xen-devel-bounces@lists.xensource.com> Envelope-to: www-data@lists.xensource.com Delivery-date: Fri, 23 Sep 2011 05:11:58 -0700 Received: from localhost ([127.0.0.1] helo=lists.colo.xensource.com) by lists.xensource.com with esmtp (Exim 4.43) id 1R74bl-0006Rv-Bp; Fri, 23 Sep 2011 05:11:57 -0700 Received: from mail216.messagelabs.com ([85.158.143.99]) by lists.xensource.com with esmtp (Exim 4.43) id 1R74Xk-0005bZ-4s for xen-devel@lists.xensource.com; Fri, 23 Sep 2011 05:07:49 -0700 X-Env-Sender: Stefano.Stabellini@eu.citrix.com X-Msg-Ref: server-2.tower-216.messagelabs.com!1316779665!18915249!1 X-Originating-IP: [62.200.22.115] X-StarScan-Version: 6.4.1; banners=-,-,- X-VirusChecked: Checked Received: (qmail 1177 invoked from network); 23 Sep 2011 12:07:45 -0000 Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115) by server-2.tower-216.messagelabs.com with RC4-SHA encrypted SMTP; 23 Sep 2011 12:07:45 -0000 X-IronPort-AV: E=Sophos;i="4.68,430,1312156800"; d="scan'208";a="8028428" Received: from lonpmailmx01.citrite.net ([10.30.203.162]) by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5; 23 Sep 2011 12:07:45 +0000 Received: from kaball.uk.xensource.com (10.80.2.59) by LONPMAILMX01.citrite.net (10.30.203.162) with Microsoft SMTP Server id 8.3.137.0; Fri, 23 Sep 2011 13:07:45 +0100 Date: Fri, 23 Sep 2011 13:07:48 +0100 From: Stefano Stabellini <stefano.stabellini@eu.citrix.com> X-X-Sender: sstabellini@kaball-desktop To: Christoph Egger <Christoph.Egger@amd.com> Subject: Re: [Xen-devel] [PATCH v5 3/4] Clone and build upstream Qemu by default In-Reply-To: <4E79B802.8050401@amd.com> Message-ID: <alpine.DEB.2.00.1109231221400.8700@kaball-desktop> References: <alpine.DEB.2.00.1109211051270.8700@kaball-desktop> <1316598917-21515-3-git-send-email-stefano.stabellini@eu.citrix.com> <4E79B802.8050401@amd.com> User-Agent: Alpine 2.00 (DEB 1167 2008-08-23) MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Cc: Ian Campbell <Ian.Campbell@eu.citrix.com>, "keir@xen.org" <keir@xen.org>, "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>, Ian Jackson <Ian.Jackson@eu.citrix.com>, Stefano Stabellini <Stefano.Stabellini@eu.citrix.com> X-BeenThere: xen-devel@lists.xensource.com X-Mailman-Version: 2.1.5 Precedence: list List-Id: Xen developer discussion <xen-devel.lists.xensource.com> List-Unsubscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe> List-Post: <mailto:xen-devel@lists.xensource.com> List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help> List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=subscribe> Sender: xen-devel-bounces@lists.xensource.com Errors-To: xen-devel-bounces@lists.xensource.com On Wed, 21 Sep 2011, Christoph Egger wrote: > On 09/21/11 11:55, stefano.stabellini@eu.citrix.com wrote: > > Signed-off-by: Stefano Stabellini<stefano.stabellini@eu.citrix.com> > > > > diff -r 51795795b213 .hgignore > > --- a/.hgignore Wed Sep 21 09:48:34 2011 +0000 > > +++ b/.hgignore Wed Sep 21 09:48:52 2011 +0000 > > @@ -293,6 +293,8 @@ > > ^tools/xm-test/tests/.*\.test$ > > ^tools/qemu-xen-traditional-dir-remote > > ^tools/qemu-xen-traditional-dir$ > > +^tools/qemu-xen-dir-remote > > +^tools/qemu-xen-dir$ > > ^tools/ocaml/.*/.*\.annot$ > > ^tools/ocaml/.*/.*\.cmx?a$ > > ^tools/ocaml/.*/META$ > > diff -r 51795795b213 Config.mk > > --- a/Config.mk Wed Sep 21 09:48:34 2011 +0000 > > +++ b/Config.mk Wed Sep 21 09:48:52 2011 +0000 > > @@ -192,6 +192,13 @@ else > > QEMU_REMOTE=git://xenbits.xensource.com/qemu-xen-unstable.git > > endif > > > > +ifeq ($(GIT_HTTP),y) > > +QEMU_UPSTREAM_URL ?= http://xenbits.xensource.com/git-http/qemu-upstream-unstable.git > > +else > > +QEMU_UPSTREAM_URL ?= git://xenbits.xensource.com/qemu-upstream-unstable.git > > +endif > > +QEMU_UPSTREAM_TAG ?= 6dd84c71dff047f9e492d67e7c99928d09202760 > > + > > # Specify which qemu-dm to use. This may be `ioemu' to use the old > > # Mercurial in-tree version, or a local directory, or a git URL. > > # CONFIG_QEMU ?= `pwd`/$(XEN_ROOT)/../qemu-xen.git > > diff -r 51795795b213 Makefile > > --- a/Makefile Wed Sep 21 09:48:34 2011 +0000 > > +++ b/Makefile Wed Sep 21 09:48:52 2011 +0000 > > @@ -70,7 +70,7 @@ install-tools: > > $(MAKE) -C tools install > > > > ifeq ($(CONFIG_IOEMU),y) > > -install-tools: tools/qemu-xen-traditional-dir > > +install-tools: tools/qemu-xen-traditional-dir tools/qemu-xen-dir > > endif > > > > .PHONY: install-kernels > > @@ -91,6 +91,9 @@ tools/qemu-xen-traditional-dir: > > tools/qemu-xen-traditional-dir-force-update: > > $(MAKE) -C tools qemu-xen-traditional-dir-force-update > > > > +tools/qemu-xen-dir: > > + $(MAKE) -C tools qemu-xen-dir-find > > + > > .PHONY: install-docs > > install-docs: > > sh ./docs/check_pkgs&& $(MAKE) -C docs install || true > > diff -r 51795795b213 tools/Makefile > > --- a/tools/Makefile Wed Sep 21 09:48:34 2011 +0000 > > +++ b/tools/Makefile Wed Sep 21 09:48:52 2011 +0000 > > @@ -31,6 +31,7 @@ SUBDIRS-$(LIBXENAPI_BINDINGS) += libxen > > # do not recurse in to a dir we are about to delete > > ifneq "$(MAKECMDGOALS)" "distclean" > > SUBDIRS-$(CONFIG_IOEMU) += qemu-xen-traditional-dir > > +SUBDIRS-$(CONFIG_IOEMU) += qemu-xen-dir > > endif > > > > SUBDIRS-y += xenpmd > > @@ -71,6 +72,7 @@ clean: subdirs-clean > > .PHONY: distclean > > distclean: subdirs-distclean > > rm -rf qemu-xen-traditional-dir qemu-xen-traditional-dir-remote > > + rm -rf qemu-xen-dir qemu-xen-dir-remote > > > > ifneq ($(XEN_COMPILE_ARCH),$(XEN_TARGET_ARCH)) > > IOEMU_CONFIGURE_CROSS ?= --cpu=$(XEN_TARGET_ARCH) \ > > @@ -95,6 +97,24 @@ qemu-xen-traditional-dir-find: > > cd qemu-xen-traditional-dir; \ > > $(QEMU_ROOT)/xen-setup $(IOEMU_CONFIGURE_CROSS) > > > > +qemu-xen-dir-find: > > + if test -d $(QEMU_UPSTREAM_URL) ; then \ > > + ln -sf $(QEMU_UPSTREAM_URL) qemu-xen-dir; \ > > + else \ > > + $(XEN_ROOT)/scripts/git-checkout.sh $(QEMU_UPSTREAM_URL) $(QEMU_UPSTREAM_TAG) qemu-xen-dir ; \ > > + fi > > + cd qemu-xen-dir; \ > > + ./configure --enable-xen --target-list=i386-softmmu \ > > + --source-path=$$ROOT \ > > + --extra-cflags="-I$(XEN_ROOT)/tools/include \ > > + -I$(XEN_ROOT)/tools/libxc \ > > + -I$(XEN_ROOT)/tools/xenstore" \ > > + --extra-ldflags="-L$(XEN_ROOT)/tools/libxc \ > > + -L$(XEN_ROOT)/tools/libxenstore" \ > > + --bindir=/usr/lib/xen/bin \ > > This doesn't work on NetBSD and also breaks installations into > non-default directories. Please use --bindir=$(LIBEXEC) OK, I'll do. _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel From xen-devel-bounces@lists.xensource.com Fri Sep 23 05:13:48 2011 Return-path: <xen-devel-bounces@lists.xensource.com> Envelope-to: www-data@lists.xensource.com Delivery-date: Fri, 23 Sep 2011 05:13:48 -0700 Received: from localhost ([127.0.0.1] helo=lists.colo.xensource.com) by lists.xensource.com with esmtp (Exim 4.43) id 1R74dY-0006qH-9s; Fri, 23 Sep 2011 05:13:48 -0700 Received: from mail27.messagelabs.com ([193.109.254.147]) by lists.xensource.com with esmtp (Exim 4.43) id 1R74YW-0005lW-Gu for xen-devel@lists.xensource.com; Fri, 23 Sep 2011 05:08:37 -0700 X-Env-Sender: Stefano.Stabellini@eu.citrix.com X-Msg-Ref: server-6.tower-27.messagelabs.com!1316779690!50179316!1 X-Originating-IP: [62.200.22.115] X-StarScan-Version: 6.4.1; banners=-,-,- X-VirusChecked: Checked Received: (qmail 5209 invoked from network); 23 Sep 2011 12:08:10 -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; 23 Sep 2011 12:08:10 -0000 X-IronPort-AV: E=Sophos;i="4.68,430,1312156800"; d="scan'208";a="8028456" Received: from lonpmailmx01.citrite.net ([10.30.203.162]) by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5; 23 Sep 2011 12:08:29 +0000 Received: from kaball.uk.xensource.com (10.80.2.59) by LONPMAILMX01.citrite.net (10.30.203.162) with Microsoft SMTP Server id 8.3.137.0; Fri, 23 Sep 2011 13:08:29 +0100 Date: Fri, 23 Sep 2011 13:08:33 +0100 From: Stefano Stabellini <stefano.stabellini@eu.citrix.com> X-X-Sender: sstabellini@kaball-desktop To: Ian Campbell <Ian.Campbell@eu.citrix.com> In-Reply-To: <1316610361.3891.181.camel@zakaz.uk.xensource.com> Message-ID: <alpine.DEB.2.00.1109231224120.8700@kaball-desktop> References: <alpine.DEB.2.00.1109211051270.8700@kaball-desktop> <1316598917-21515-3-git-send-email-stefano.stabellini@eu.citrix.com> <1316610361.3891.181.camel@zakaz.uk.xensource.com> User-Agent: Alpine 2.00 (DEB 1167 2008-08-23) MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Cc: Ian Jackson <Ian.Jackson@eu.citrix.com>, "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>, "keir@xen.org" <keir@xen.org>, Stefano Stabellini <Stefano.Stabellini@eu.citrix.com> Subject: [Xen-devel] Re: [PATCH v5 3/4] Clone and build upstream Qemu by default X-BeenThere: xen-devel@lists.xensource.com X-Mailman-Version: 2.1.5 Precedence: list List-Id: Xen developer discussion <xen-devel.lists.xensource.com> List-Unsubscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe> List-Post: <mailto:xen-devel@lists.xensource.com> List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help> List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=subscribe> Sender: xen-devel-bounces@lists.xensource.com Errors-To: xen-devel-bounces@lists.xensource.com On Wed, 21 Sep 2011, Ian Campbell wrote: > We should have this extra patch along with this change I guess.... > Thanks, patch appended to the series. _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel From xen-devel-bounces@lists.xensource.com Fri Sep 23 05:15:04 2011 Return-path: <xen-devel-bounces@lists.xensource.com> Envelope-to: www-data@lists.xensource.com Delivery-date: Fri, 23 Sep 2011 05:15:04 -0700 Received: from localhost ([127.0.0.1] helo=lists.colo.xensource.com) by lists.xensource.com with esmtp (Exim 4.43) id 1R74el-0007DE-Gd; Fri, 23 Sep 2011 05:15:04 -0700 Received: from mail216.messagelabs.com ([85.158.143.99]) by lists.xensource.com with esmtp (Exim 4.43) id 1R74Yz-0005rQ-QX for xen-devel@lists.xensource.com; Fri, 23 Sep 2011 05:09:06 -0700 X-Env-Sender: Stefano.Stabellini@eu.citrix.com X-Msg-Ref: server-2.tower-216.messagelabs.com!1316779742!18915460!1 X-Originating-IP: [62.200.22.115] X-StarScan-Version: 6.4.1; banners=-,-,- X-VirusChecked: Checked Received: (qmail 5078 invoked from network); 23 Sep 2011 12:09:02 -0000 Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115) by server-2.tower-216.messagelabs.com with RC4-SHA encrypted SMTP; 23 Sep 2011 12:09:02 -0000 X-IronPort-AV: E=Sophos;i="4.68,430,1312156800"; d="scan'208";a="8028472" Received: from lonpmailmx01.citrite.net ([10.30.203.162]) by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5; 23 Sep 2011 12:09:02 +0000 Received: from kaball.uk.xensource.com (10.80.2.59) by LONPMAILMX01.citrite.net (10.30.203.162) with Microsoft SMTP Server id 8.3.137.0; Fri, 23 Sep 2011 13:09:02 +0100 Date: Fri, 23 Sep 2011 13:09:06 +0100 From: Stefano Stabellini <stefano.stabellini@eu.citrix.com> X-X-Sender: sstabellini@kaball-desktop To: Anthony PERARD <anthony.perard@citrix.com> Subject: Re: [Xen-devel] Re: [PATCH v5 4/4] Clone and build Seabios by default In-Reply-To: <CAJJyHjLkLTCAykvpDKw1FYQqquWu74xzotyXfZidtE_7KaSxTA@mail.gmail.com> Message-ID: <alpine.DEB.2.00.1109231226550.8700@kaball-desktop> References: <alpine.DEB.2.00.1109211051270.8700@kaball-desktop> <1316598917-21515-4-git-send-email-stefano.stabellini@eu.citrix.com> <1316602822.3891.173.camel@zakaz.uk.xensource.com> <CAJJyHjLkLTCAykvpDKw1FYQqquWu74xzotyXfZidtE_7KaSxTA@mail.gmail.com> User-Agent: Alpine 2.00 (DEB 1167 2008-08-23) MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Cc: Ian Campbell <Ian.Campbell@eu.citrix.com>, "keir@xen.org" <keir@xen.org>, "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>, Ian Jackson <Ian.Jackson@eu.citrix.com>, Stefano Stabellini <Stefano.Stabellini@eu.citrix.com> X-BeenThere: xen-devel@lists.xensource.com X-Mailman-Version: 2.1.5 Precedence: list List-Id: Xen developer discussion <xen-devel.lists.xensource.com> List-Unsubscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe> List-Post: <mailto:xen-devel@lists.xensource.com> List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help> List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=subscribe> Sender: xen-devel-bounces@lists.xensource.com Errors-To: xen-devel-bounces@lists.xensource.com On Thu, 22 Sep 2011, Anthony PERARD wrote: > On Wed, Sep 21, 2011 at 12:00, Ian Campbell <Ian.Campbell@eu.citrix.com> wrote: > > On Wed, 2011-09-21 at 10:55 +0100, stefano.stabellini@eu.citrix.com > > wrote: > >> Signed-off-by: Stefano Stabellini <stefano.stabellini@eu.citrix.com> > >> > >> diff -r 9832a4edea7f .hgignore > >> --- a/.hgignore Thu Sep 15 14:25:11 2011 +0000 > >> +++ b/.hgignore Thu Sep 15 14:37:33 2011 +0000 > >> @@ -295,6 +295,8 @@ > >> ^tools/qemu-xen-traditional-dir$ > >> ^tools/qemu-xen-dir-remote > >> ^tools/qemu-xen-dir$ > >> +^tools/tools/firmware/seabios-dir-remote > >> +^tools/tools/firmware/seabios-dir$ > >> ^tools/ocaml/.*/.*\.annot$ > >> ^tools/ocaml/.*/.*\.cmx?a$ > >> ^tools/ocaml/.*/META$ > >> diff -r 9832a4edea7f Config.mk > >> --- a/Config.mk Thu Sep 15 14:25:11 2011 +0000 > >> +++ b/Config.mk Thu Sep 15 14:37:33 2011 +0000 > >> @@ -199,6 +199,8 @@ else > >> QEMU_UPSTREAM_URL ?= git://xenbits.xensource.com/qemu-upstream-unstable.git > >> endif > >> QEMU_UPSTREAM_TAG ?= 6dd84c71dff047f9e492d67e7c99928d09202760 > >> +SEABIOS_UPSTREAM_URL ?= git://git.qemu.org/seabios.git > > > > I use git://git.seabios.org/seabios.git but I don't suppose there is > > much distinction? > > > > More importantly does anyone know of an http mirror? > > I found this one: > http://git.qemu.org/git/seabios.git Good, I am going to add it. _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel From xen-devel-bounces@lists.xensource.com Fri Sep 23 05:16:22 2011 Return-path: <xen-devel-bounces@lists.xensource.com> Envelope-to: www-data@lists.xensource.com Delivery-date: Fri, 23 Sep 2011 05:16:22 -0700 Received: from localhost ([127.0.0.1] helo=lists.colo.xensource.com) by lists.xensource.com with esmtp (Exim 4.43) id 1R74g2-0007b1-6b; Fri, 23 Sep 2011 05:16:22 -0700 Received: from mail182.messagelabs.com ([85.158.139.83]) by lists.xensource.com with esmtp (Exim 4.43) id 1R74Zl-00062R-7H for xen-devel@lists.xensource.com; Fri, 23 Sep 2011 05:09:55 -0700 X-Env-Sender: Stefano.Stabellini@eu.citrix.com X-Msg-Ref: server-7.tower-182.messagelabs.com!1316779790!14468344!1 X-Originating-IP: [62.200.22.115] X-StarScan-Version: 6.4.1; banners=-,-,- X-VirusChecked: Checked Received: (qmail 6753 invoked from network); 23 Sep 2011 12:09:50 -0000 Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115) by server-7.tower-182.messagelabs.com with RC4-SHA encrypted SMTP; 23 Sep 2011 12:09:50 -0000 X-IronPort-AV: E=Sophos;i="4.68,430,1312156800"; d="scan'208";a="8028498" Received: from lonpmailmx01.citrite.net ([10.30.203.162]) by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5; 23 Sep 2011 12:09:50 +0000 Received: from kaball.uk.xensource.com (10.80.2.59) by LONPMAILMX01.citrite.net (10.30.203.162) with Microsoft SMTP Server id 8.3.137.0; Fri, 23 Sep 2011 13:09:50 +0100 Date: Fri, 23 Sep 2011 13:09:53 +0100 From: Stefano Stabellini <Stefano.Stabellini@eu.citrix.com> X-X-Sender: sstabellini@kaball-desktop To: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com> Message-ID: <alpine.DEB.2.00.1109231302370.8700@kaball-desktop> User-Agent: Alpine 2.00 (DEB 1167 2008-08-23) MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Cc: Ian Campbell <Ian.Campbell@eu.citrix.com>, Keir Fraser <keir@xen.org>, Stefano Stabellini <Stefano.Stabellini@eu.citrix.com> Subject: [Xen-devel] [PATCH v6 0/5] build upstream qemu and seabios by default X-BeenThere: xen-devel@lists.xensource.com X-Mailman-Version: 2.1.5 Precedence: list List-Id: Xen developer discussion <xen-devel.lists.xensource.com> List-Unsubscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe> List-Post: <mailto:xen-devel@lists.xensource.com> List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help> List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=subscribe> Sender: xen-devel-bounces@lists.xensource.com Errors-To: xen-devel-bounces@lists.xensource.com Hi all, this is the sixth version of the patch series to introduce upstream qemu and seabios in the xen-unstable build system. Changes to v5: - use $GIT in git-checkout.sh; - add an http mirror for seabios; - use $(LIBEXEC) to configure upstream qemu; - append a patch for libxenlight to find the upstream qemu binary under $(LIBEXEC). Changes to v4: - remove an obsolete comment; - use /bin/sh to execute git-checkout.sh rathen than /bin/bash. Changes to v3: - reduce the scope of git-checkout.sh, now it only does what the name says; calling "configure" is responsibility of the caller. As a result of this change, the build still works when the user specifies a local directory in the CONFIG_QEMU environmental variable; - use a more official qemu repository hosted on xenbits; - use a changeset as QEMU_UPSTREAM_TAG rather than a branch name. Changes to v2: - move tools/git-checkout.sh to scripts/git-checkout.sh; - use git-checkout.sh for seabios; - improve seabios integration with tools/firmware make system; - add qemu-xen-traditional, qemu-xen and seabios dir entries to .hgignore. Changes to v1: - always build upstream qemu and seabios, rather than introducing them as an option. Cheers, Stefano _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel From xen-devel-bounces@lists.xensource.com Fri Sep 23 05:17:20 2011 Return-path: <xen-devel-bounces@lists.xensource.com> Envelope-to: www-data@lists.xensource.com Delivery-date: Fri, 23 Sep 2011 05:17:20 -0700 Received: from localhost ([127.0.0.1] helo=lists.colo.xensource.com) by lists.xensource.com with esmtp (Exim 4.43) id 1R74gy-0007xj-3Q; Fri, 23 Sep 2011 05:17:20 -0700 Received: from mail21.messagelabs.com ([85.158.143.35]) by lists.xensource.com with esmtp (Exim 4.43) id 1R74b2-0006Kr-Sc for xen-devel@lists.xensource.com; Fri, 23 Sep 2011 05:11:14 -0700 X-Env-Sender: Stefano.Stabellini@eu.citrix.com X-Msg-Ref: server-13.tower-21.messagelabs.com!1316779862!50043784!1 X-Originating-IP: [66.165.176.63] X-StarScan-Version: 6.4.1; banners=-,-,- X-VirusChecked: Checked Received: (qmail 5891 invoked from network); 23 Sep 2011 12:11:03 -0000 Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63) by server-13.tower-21.messagelabs.com with RC4-SHA encrypted SMTP; 23 Sep 2011 12:11:03 -0000 X-IronPort-AV: E=Sophos;i="4.68,430,1312171200"; d="scan'208";a="164430746" Received: from ftlpmailmx02.citrite.net ([10.13.107.66]) by FTLPIPO02.CITRIX.COM with ESMTP/TLS/RC4-MD5; 23 Sep 2011 08:11:08 -0400 Received: from smtp01.ad.xensource.com (10.219.128.104) by smtprelay.citrix.com (10.13.107.66) with Microsoft SMTP Server id 8.3.137.0; Fri, 23 Sep 2011 08:11:08 -0400 Received: from localhost.localdomain (kaball.uk.xensource.com [10.80.2.59]) by smtp01.ad.xensource.com (8.13.1/8.13.1) with ESMTP id p8NCB0tB030988; Fri, 23 Sep 2011 05:11:01 -0700 From: <stefano.stabellini@eu.citrix.com> To: xen-devel@lists.xensource.com Date: Fri, 23 Sep 2011 13:11:14 +0100 Message-ID: <1316779878-10950-1-git-send-email-stefano.stabellini@eu.citrix.com> X-Mailer: git-send-email 1.7.0.4 In-Reply-To: <alpine.DEB.2.00.1109231302370.8700@kaball-desktop> References: <alpine.DEB.2.00.1109231302370.8700@kaball-desktop> MIME-Version: 1.0 Content-Type: text/plain Cc: Ian.Campbell@eu.citrix.com, Ian.Jackson@eu.citrix.com, Stefano Stabellini <stefano.stabellini@eu.citrix.com>, keir@xen.org, Stefano.Stabellini@eu.citrix.com Subject: [Xen-devel] [PATCH v6 1/5] Introduce git-checkout.sh X-BeenThere: xen-devel@lists.xensource.com X-Mailman-Version: 2.1.5 Precedence: list List-Id: Xen developer discussion <xen-devel.lists.xensource.com> List-Unsubscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe> List-Post: <mailto:xen-devel@lists.xensource.com> List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help> List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=subscribe> Sender: xen-devel-bounces@lists.xensource.com Errors-To: xen-devel-bounces@lists.xensource.com Introduce a script to perform git checkout on an external git tree; use git-checkout.sh in ioemu-dir-find. Signed-off-by: Stefano Stabellini <stefano.stabellini@eu.citrix.com> diff --git a/.hgignore b/.hgignore --- a/.hgignore +++ b/.hgignore @@ -291,7 +291,7 @@ ^tools/xm-test/lib/XmTestLib/config.py$ ^tools/xm-test/lib/XmTestReport/xmtest.py$ ^tools/xm-test/tests/.*\.test$ -^tools/ioemu-remote +^tools/ioemu-dir-remote ^tools/ioemu-dir$ ^tools/ocaml/.*/.*\.annot$ ^tools/ocaml/.*/.*\.cmx?a$ diff --git a/scripts/git-checkout.sh b/scripts/git-checkout.sh new file mode 100755 --- /dev/null +++ b/scripts/git-checkout.sh @@ -0,0 +1,21 @@ +#!/bin/sh + +TREE=$1 +TAG=$2 +DIR=$3 + + +if test \! -d $DIR-remote; then + rm -rf $DIR-remote $DIR-remote.tmp; + mkdir $DIR-remote.tmp; rmdir $DIR-remote.tmp; + $GIT clone $TREE $DIR-remote.tmp; + if test "$TAG" ; then + cd $DIR-remote.tmp + $GIT branch -D dummy >/dev/null 2>&1 ||: + $GIT checkout -b dummy $TAG + cd .. + fi + mv $DIR-remote.tmp $DIR-remote +fi +rm -f $DIR +ln -sf $DIR-remote $DIR diff --git a/tools/Makefile b/tools/Makefile --- a/tools/Makefile +++ b/tools/Makefile @@ -70,7 +70,7 @@ clean: subdirs-clean .PHONY: distclean distclean: subdirs-distclean - rm -rf ioemu-dir ioemu-remote + rm -rf ioemu-dir ioemu-dir-remote ifneq ($(XEN_COMPILE_ARCH),$(XEN_TARGET_ARCH)) IOEMU_CONFIGURE_CROSS ?= --cpu=$(XEN_TARGET_ARCH) \ @@ -88,20 +88,8 @@ ioemu-dir-find: if test -d $(CONFIG_QEMU); then \ mkdir -p ioemu-dir; \ else \ - if [ ! -d ioemu-remote ]; then \ - rm -rf ioemu-remote ioemu-remote.tmp; \ - mkdir ioemu-remote.tmp; rmdir ioemu-remote.tmp; \ - $(GIT) clone $(CONFIG_QEMU) ioemu-remote.tmp; \ - if [ "$(QEMU_TAG)" ]; then \ - cd ioemu-remote.tmp; \ - $(GIT) branch -D dummy >/dev/null 2>&1 ||:; \ - $(GIT) checkout -b dummy $(QEMU_TAG); \ - cd ..; \ - fi; \ - mv ioemu-remote.tmp ioemu-remote; \ - fi; \ - rm -f ioemu-dir; \ - ln -sf ioemu-remote ioemu-dir; \ + export GIT=$(GIT); \ + $(XEN_ROOT)/scripts/git-checkout.sh $(CONFIG_QEMU) $(QEMU_TAG) ioemu-dir; \ fi set -e; \ $(buildmakevars2shellvars); \ @@ -112,7 +100,7 @@ ioemu-dir-find: ioemu-dir-force-update: set -ex; \ if [ "$(QEMU_TAG)" ]; then \ - cd ioemu-remote; \ + cd ioemu-dir-remote; \ $(GIT) fetch origin; \ $(GIT) reset --hard $(QEMU_TAG); \ fi _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel From xen-devel-bounces@lists.xensource.com Fri Sep 23 05:18:30 2011 Return-path: <xen-devel-bounces@lists.xensource.com> Envelope-to: www-data@lists.xensource.com Delivery-date: Fri, 23 Sep 2011 05:18:30 -0700 Received: from localhost ([127.0.0.1] helo=lists.colo.xensource.com) by lists.xensource.com with esmtp (Exim 4.43) id 1R74i6-0008Kp-89; Fri, 23 Sep 2011 05:18:30 -0700 Received: from mail182.messagelabs.com ([85.158.139.83]) by lists.xensource.com with esmtp (Exim 4.43) id 1R74b3-0006LB-M6 for xen-devel@lists.xensource.com; Fri, 23 Sep 2011 05:11:15 -0700 X-Env-Sender: Stefano.Stabellini@eu.citrix.com X-Msg-Ref: server-11.tower-182.messagelabs.com!1316779869!19478254!1 X-Originating-IP: [66.165.176.89] X-StarScan-Version: 6.4.1; banners=-,-,- X-VirusChecked: Checked Received: (qmail 17428 invoked from network); 23 Sep 2011 12:11:10 -0000 Received: from smtp.citrix.com (HELO SMTP.CITRIX.COM) (66.165.176.89) by server-11.tower-182.messagelabs.com with RC4-SHA encrypted SMTP; 23 Sep 2011 12:11:10 -0000 X-IronPort-AV: E=Sophos;i="4.68,430,1312171200"; d="scan'208";a="17641609" Received: from ftlpmailmx02.citrite.net ([10.13.107.66]) by FTLPIPO01.CITRIX.COM with ESMTP/TLS/RC4-MD5; 23 Sep 2011 08:11:08 -0400 Received: from smtp01.ad.xensource.com (10.219.128.104) by smtprelay.citrix.com (10.13.107.66) with Microsoft SMTP Server id 8.3.137.0; Fri, 23 Sep 2011 08:11:08 -0400 Received: from localhost.localdomain (kaball.uk.xensource.com [10.80.2.59]) by smtp01.ad.xensource.com (8.13.1/8.13.1) with ESMTP id p8NCB0tF030988; Fri, 23 Sep 2011 05:11:07 -0700 From: <stefano.stabellini@eu.citrix.com> To: xen-devel@lists.xensource.com Date: Fri, 23 Sep 2011 13:11:18 +0100 Message-ID: <1316779878-10950-5-git-send-email-stefano.stabellini@eu.citrix.com> X-Mailer: git-send-email 1.7.0.4 In-Reply-To: <alpine.DEB.2.00.1109231302370.8700@kaball-desktop> References: <alpine.DEB.2.00.1109231302370.8700@kaball-desktop> MIME-Version: 1.0 Content-Type: text/plain Cc: Ian.Campbell@eu.citrix.com, Ian.Jackson@eu.citrix.com, keir@xen.org, Ian Campbell <ian.campbell@citrix.com>, Stefano.Stabellini@eu.citrix.com Subject: [Xen-devel] [PATCH v6 5/5] libxl: use new qemu at the location where xen-unstable installs it X-BeenThere: xen-devel@lists.xensource.com X-Mailman-Version: 2.1.5 Precedence: list List-Id: Xen developer discussion <xen-devel.lists.xensource.com> List-Unsubscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe> List-Post: <mailto:xen-devel@lists.xensource.com> List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help> List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=subscribe> Sender: xen-devel-bounces@lists.xensource.com Errors-To: xen-devel-bounces@lists.xensource.com From: Ian Campbell <ian.campbell@citrix.com> Signed-off-by: Ian Campbell <ian.campbell@citrix.com> diff -r 75f27929ad92 tools/libxl/libxl_dm.c --- a/tools/libxl/libxl_dm.c Fri Sep 23 11:22:23 2011 +0000 +++ b/tools/libxl/libxl_dm.c Fri Sep 23 11:22:39 2011 +0000 @@ -55,7 +55,7 @@ const char *libxl__domain_device_model(l dm = libxl__abs_path(gc, "qemu-dm", libxl_libexec_path()); break; case LIBXL_DEVICE_MODEL_VERSION_QEMU_XEN: - dm = libxl__strdup(gc, "/usr/bin/qemu"); + dm = libxl__abs_path(gc, "qemu", libxl_libexec_path()); break; default: LIBXL__LOG(ctx, LIBXL__LOG_ERROR, _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel From xen-devel-bounces@lists.xensource.com Fri Sep 23 05:19:40 2011 Return-path: <xen-devel-bounces@lists.xensource.com> Envelope-to: www-data@lists.xensource.com Delivery-date: Fri, 23 Sep 2011 05:19:40 -0700 Received: from localhost ([127.0.0.1] helo=lists.colo.xensource.com) by lists.xensource.com with esmtp (Exim 4.43) id 1R74jE-0000GJ-Jc; Fri, 23 Sep 2011 05:19:40 -0700 Received: from mail21.messagelabs.com ([85.158.143.35]) by lists.xensource.com with esmtp (Exim 4.43) id 1R74b8-0006M4-8w for xen-devel@lists.xensource.com; Fri, 23 Sep 2011 05:11:19 -0700 X-Env-Sender: Stefano.Stabellini@eu.citrix.com X-Msg-Ref: server-13.tower-21.messagelabs.com!1316779862!50043784!2 X-Originating-IP: [66.165.176.63] X-StarScan-Version: 6.4.1; banners=-,-,- X-VirusChecked: Checked Received: (qmail 6069 invoked from network); 23 Sep 2011 12:11:08 -0000 Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63) by server-13.tower-21.messagelabs.com with RC4-SHA encrypted SMTP; 23 Sep 2011 12:11:08 -0000 X-IronPort-AV: E=Sophos;i="4.68,430,1312171200"; d="scan'208";a="164430759" Received: from ftlpmailmx02.citrite.net ([10.13.107.66]) by FTLPIPO02.CITRIX.COM with ESMTP/TLS/RC4-MD5; 23 Sep 2011 08:11:14 -0400 Received: from smtp01.ad.xensource.com (10.219.128.104) by smtprelay.citrix.com (10.13.107.66) with Microsoft SMTP Server id 8.3.137.0; Fri, 23 Sep 2011 08:11:14 -0400 Received: from localhost.localdomain (kaball.uk.xensource.com [10.80.2.59]) by smtp01.ad.xensource.com (8.13.1/8.13.1) with ESMTP id p8NCB0tC030988; Fri, 23 Sep 2011 05:11:02 -0700 From: <stefano.stabellini@eu.citrix.com> To: xen-devel@lists.xensource.com Date: Fri, 23 Sep 2011 13:11:15 +0100 Message-ID: <1316779878-10950-2-git-send-email-stefano.stabellini@eu.citrix.com> X-Mailer: git-send-email 1.7.0.4 In-Reply-To: <alpine.DEB.2.00.1109231302370.8700@kaball-desktop> References: <alpine.DEB.2.00.1109231302370.8700@kaball-desktop> MIME-Version: 1.0 Content-Type: text/plain Cc: Ian.Campbell@eu.citrix.com, Ian.Jackson@eu.citrix.com, Stefano Stabellini <stefano.stabellini@eu.citrix.com>, keir@xen.org, Stefano.Stabellini@eu.citrix.com Subject: [Xen-devel] [PATCH v6 2/5] Rename ioemu-dir as qemu-xen-traditional-dir X-BeenThere: xen-devel@lists.xensource.com X-Mailman-Version: 2.1.5 Precedence: list List-Id: Xen developer discussion <xen-devel.lists.xensource.com> List-Unsubscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe> List-Post: <mailto:xen-devel@lists.xensource.com> List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help> List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=subscribe> Sender: xen-devel-bounces@lists.xensource.com Errors-To: xen-devel-bounces@lists.xensource.com Signed-off-by: Stefano Stabellini <stefano.stabellini@eu.citrix.com> diff -r 9d2f56b25845 .hgignore --- a/.hgignore Fri Sep 23 11:35:23 2011 +0000 +++ b/.hgignore Fri Sep 23 11:36:44 2011 +0000 @@ -291,8 +291,8 @@ ^tools/xm-test/lib/XmTestLib/config.py$ ^tools/xm-test/lib/XmTestReport/xmtest.py$ ^tools/xm-test/tests/.*\.test$ -^tools/ioemu-dir-remote -^tools/ioemu-dir$ +^tools/qemu-xen-traditional-dir-remote +^tools/qemu-xen-traditional-dir$ ^tools/ocaml/.*/.*\.annot$ ^tools/ocaml/.*/.*\.cmx?a$ ^tools/ocaml/.*/META$ diff -r 9d2f56b25845 Makefile --- a/Makefile Fri Sep 23 11:35:23 2011 +0000 +++ b/Makefile Fri Sep 23 11:36:44 2011 +0000 @@ -70,7 +70,7 @@ install-tools: $(MAKE) -C tools install ifeq ($(CONFIG_IOEMU),y) -install-tools: tools/ioemu-dir +install-tools: tools/qemu-xen-traditional-dir endif .PHONY: install-kernels @@ -78,18 +78,18 @@ install-kernels: for i in $(XKERNELS) ; do $(MAKE) $$i-install || exit 1; done .PHONY: install-stubdom -install-stubdom: tools/ioemu-dir install-tools +install-stubdom: tools/qemu-xen-traditional-dir install-tools $(MAKE) -C stubdom install ifeq (x86_64,$(XEN_TARGET_ARCH)) XEN_TARGET_ARCH=x86_32 $(MAKE) -C stubdom install-grub endif -tools/ioemu-dir: - $(MAKE) -C tools ioemu-dir-find +tools/qemu-xen-traditional-dir: + $(MAKE) -C tools qemu-xen-traditional-dir-find -.PHONY: tools/ioemu-dir-force-update -tools/ioemu-dir-force-update: - $(MAKE) -C tools ioemu-dir-force-update +.PHONY: tools/qemu-xen-traditional-dir-force-update +tools/qemu-xen-traditional-dir-force-update: + $(MAKE) -C tools qemu-xen-traditional-dir-force-update .PHONY: install-docs install-docs: diff -r 9d2f56b25845 stubdom/Makefile --- a/stubdom/Makefile Fri Sep 23 11:35:23 2011 +0000 +++ b/stubdom/Makefile Fri Sep 23 11:36:44 2011 +0000 @@ -218,15 +218,15 @@ cross-ocaml: $(OCAML_STAMPFILE) QEMU_ROOT := $(shell if [ -d "$(CONFIG_QEMU)" ]; then echo "$(CONFIG_QEMU)"; else echo .; fi) ifeq ($(QEMU_ROOT),.) -$(XEN_ROOT)/tools/ioemu-dir: - $(CROSS_MAKE) -C $(XEN_ROOT)/tools ioemu-dir-find +$(XEN_ROOT)/tools/qemu-xen-traditional-dir: + $(CROSS_MAKE) -C $(XEN_ROOT)/tools qemu-xen-traditional-dir-find -ioemu/linkfarm.stamp: $(XEN_ROOT)/tools/ioemu-dir +ioemu/linkfarm.stamp: $(XEN_ROOT)/tools/qemu-xen-traditional-dir mkdir -p ioemu set -e; \ $(buildmakevars2shellvars); \ cd ioemu; \ - src="$$XEN_ROOT/tools/ioemu-dir"; export src; \ + src="$$XEN_ROOT/tools/qemu-xen-traditional-dir"; export src; \ (cd $$src && find * -type d -print) | xargs mkdir -p; \ (cd $$src && find * ! -type l -type f $(addprefix ! -name , \ '*.[oda1]' 'config-*' config.mak qemu-dm qemu-img-xen \ diff -r 9d2f56b25845 tools/Makefile --- a/tools/Makefile Fri Sep 23 11:35:23 2011 +0000 +++ b/tools/Makefile Fri Sep 23 11:36:44 2011 +0000 @@ -30,7 +30,7 @@ SUBDIRS-$(LIBXENAPI_BINDINGS) += libxen # do not recurse in to a dir we are about to delete ifneq "$(MAKECMDGOALS)" "distclean" -SUBDIRS-$(CONFIG_IOEMU) += ioemu-dir +SUBDIRS-$(CONFIG_IOEMU) += qemu-xen-traditional-dir endif SUBDIRS-y += xenpmd @@ -70,7 +70,7 @@ clean: subdirs-clean .PHONY: distclean distclean: subdirs-distclean - rm -rf ioemu-dir ioemu-dir-remote + rm -rf qemu-xen-traditional-dir qemu-xen-traditional-dir-remote ifneq ($(XEN_COMPILE_ARCH),$(XEN_TARGET_ARCH)) IOEMU_CONFIGURE_CROSS ?= --cpu=$(XEN_TARGET_ARCH) \ @@ -83,34 +83,34 @@ ifneq ($(QEMU_ROOT),.) export QEMU_ROOT endif -ioemu-dir-find: +qemu-xen-traditional-dir-find: set -ex; \ if test -d $(CONFIG_QEMU); then \ - mkdir -p ioemu-dir; \ + mkdir -p qemu-xen-traditional-dir; \ else \ export GIT=$(GIT); \ - $(XEN_ROOT)/scripts/git-checkout.sh $(CONFIG_QEMU) $(QEMU_TAG) ioemu-dir; \ + $(XEN_ROOT)/scripts/git-checkout.sh $(CONFIG_QEMU) $(QEMU_TAG) qemu-xen-traditional-dir; \ fi set -e; \ $(buildmakevars2shellvars); \ - cd ioemu-dir; \ + cd qemu-xen-traditional-dir; \ $(QEMU_ROOT)/xen-setup $(IOEMU_CONFIGURE_CROSS) -.PHONY: ioemu-dir-force-update -ioemu-dir-force-update: +.PHONY: qemu-xen-traditional-dir-force-update +qemu-xen-traditional-dir-force-update: set -ex; \ if [ "$(QEMU_TAG)" ]; then \ - cd ioemu-dir-remote; \ + cd qemu-xen-traditional-dir-remote; \ $(GIT) fetch origin; \ $(GIT) reset --hard $(QEMU_TAG); \ fi -subdir-all-ioemu-dir subdir-install-ioemu-dir: ioemu-dir-find +subdir-all-qemu-xen-traditional-dir subdir-install-qemu-xen-traditional-dir: qemu-xen-traditional-dir-find -subdir-clean-ioemu-dir: - set -e; if test -d ioemu-dir/.; then \ +subdir-clean-qemu-xen-traditional-dir: + set -e; if test -d qemu-xen-traditional-dir/.; then \ $(buildmakevars2shellvars); \ - $(MAKE) -C ioemu-dir clean; \ + $(MAKE) -C qemu-xen-traditional-dir clean; \ fi subdir-clean-debugger/gdbsx subdir-distclean-debugger/gdbsx: .phony _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel From xen-devel-bounces@lists.xensource.com Fri Sep 23 05:21:03 2011 Return-path: <xen-devel-bounces@lists.xensource.com> Envelope-to: www-data@lists.xensource.com Delivery-date: Fri, 23 Sep 2011 05:21:03 -0700 Received: from localhost ([127.0.0.1] helo=lists.colo.xensource.com) by lists.xensource.com with esmtp (Exim 4.43) id 1R74kZ-0000ec-9j; Fri, 23 Sep 2011 05:21:03 -0700 Received: from mail27.messagelabs.com ([193.109.254.147]) by lists.xensource.com with esmtp (Exim 4.43) id 1R74bA-0006MK-H8 for xen-devel@lists.xensource.com; Fri, 23 Sep 2011 05:11:20 -0700 X-Env-Sender: Stefano.Stabellini@eu.citrix.com X-Msg-Ref: server-8.tower-27.messagelabs.com!1316779859!47806899!1 X-Originating-IP: [66.165.176.89] X-StarScan-Version: 6.4.1; banners=-,-,- X-VirusChecked: Checked Received: (qmail 22874 invoked from network); 23 Sep 2011 12:11:01 -0000 Received: from smtp.citrix.com (HELO SMTP.CITRIX.COM) (66.165.176.89) by server-8.tower-27.messagelabs.com with RC4-SHA encrypted SMTP; 23 Sep 2011 12:11:01 -0000 X-IronPort-AV: E=Sophos;i="4.68,430,1312171200"; d="scan'208";a="17641615" Received: from ftlpmailmx02.citrite.net ([10.13.107.66]) by FTLPIPO01.CITRIX.COM with ESMTP/TLS/RC4-MD5; 23 Sep 2011 08:11:15 -0400 Received: from smtp01.ad.xensource.com (10.219.128.104) by smtprelay.citrix.com (10.13.107.66) with Microsoft SMTP Server id 8.3.137.0; Fri, 23 Sep 2011 08:11:15 -0400 Received: from localhost.localdomain (kaball.uk.xensource.com [10.80.2.59]) by smtp01.ad.xensource.com (8.13.1/8.13.1) with ESMTP id p8NCB0tD030988; Fri, 23 Sep 2011 05:11:04 -0700 From: <stefano.stabellini@eu.citrix.com> To: xen-devel@lists.xensource.com Date: Fri, 23 Sep 2011 13:11:16 +0100 Message-ID: <1316779878-10950-3-git-send-email-stefano.stabellini@eu.citrix.com> X-Mailer: git-send-email 1.7.0.4 In-Reply-To: <alpine.DEB.2.00.1109231302370.8700@kaball-desktop> References: <alpine.DEB.2.00.1109231302370.8700@kaball-desktop> MIME-Version: 1.0 Content-Type: text/plain Cc: Ian.Campbell@eu.citrix.com, Ian.Jackson@eu.citrix.com, Stefano Stabellini <stefano.stabellini@eu.citrix.com>, keir@xen.org, Stefano.Stabellini@eu.citrix.com Subject: [Xen-devel] [PATCH v6 3/5] Clone and build upstream Qemu by default X-BeenThere: xen-devel@lists.xensource.com X-Mailman-Version: 2.1.5 Precedence: list List-Id: Xen developer discussion <xen-devel.lists.xensource.com> List-Unsubscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe> List-Post: <mailto:xen-devel@lists.xensource.com> List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help> List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=subscribe> Sender: xen-devel-bounces@lists.xensource.com Errors-To: xen-devel-bounces@lists.xensource.com Signed-off-by: Stefano Stabellini <stefano.stabellini@eu.citrix.com> diff -r 5553e17faa80 .hgignore --- a/.hgignore Fri Sep 23 11:36:44 2011 +0000 +++ b/.hgignore Fri Sep 23 11:37:08 2011 +0000 @@ -293,6 +293,8 @@ ^tools/xm-test/tests/.*\.test$ ^tools/qemu-xen-traditional-dir-remote ^tools/qemu-xen-traditional-dir$ +^tools/qemu-xen-dir-remote +^tools/qemu-xen-dir$ ^tools/ocaml/.*/.*\.annot$ ^tools/ocaml/.*/.*\.cmx?a$ ^tools/ocaml/.*/META$ diff -r 5553e17faa80 Config.mk --- a/Config.mk Fri Sep 23 11:36:44 2011 +0000 +++ b/Config.mk Fri Sep 23 11:37:08 2011 +0000 @@ -192,6 +192,13 @@ else QEMU_REMOTE=git://xenbits.xensource.com/qemu-xen-unstable.git endif +ifeq ($(GIT_HTTP),y) +QEMU_UPSTREAM_URL ?= http://xenbits.xensource.com/git-http/qemu-upstream-unstable.git +else +QEMU_UPSTREAM_URL ?= git://xenbits.xensource.com/qemu-upstream-unstable.git +endif +QEMU_UPSTREAM_TAG ?= 6dd84c71dff047f9e492d67e7c99928d09202760 + # Specify which qemu-dm to use. This may be `ioemu' to use the old # Mercurial in-tree version, or a local directory, or a git URL. # CONFIG_QEMU ?= `pwd`/$(XEN_ROOT)/../qemu-xen.git diff -r 5553e17faa80 Makefile --- a/Makefile Fri Sep 23 11:36:44 2011 +0000 +++ b/Makefile Fri Sep 23 11:37:08 2011 +0000 @@ -70,7 +70,7 @@ install-tools: $(MAKE) -C tools install ifeq ($(CONFIG_IOEMU),y) -install-tools: tools/qemu-xen-traditional-dir +install-tools: tools/qemu-xen-traditional-dir tools/qemu-xen-dir endif .PHONY: install-kernels @@ -91,6 +91,9 @@ tools/qemu-xen-traditional-dir: tools/qemu-xen-traditional-dir-force-update: $(MAKE) -C tools qemu-xen-traditional-dir-force-update +tools/qemu-xen-dir: + $(MAKE) -C tools qemu-xen-dir-find + .PHONY: install-docs install-docs: sh ./docs/check_pkgs && $(MAKE) -C docs install || true diff -r 5553e17faa80 tools/Makefile --- a/tools/Makefile Fri Sep 23 11:36:44 2011 +0000 +++ b/tools/Makefile Fri Sep 23 11:37:08 2011 +0000 @@ -31,6 +31,7 @@ SUBDIRS-$(LIBXENAPI_BINDINGS) += libxen # do not recurse in to a dir we are about to delete ifneq "$(MAKECMDGOALS)" "distclean" SUBDIRS-$(CONFIG_IOEMU) += qemu-xen-traditional-dir +SUBDIRS-$(CONFIG_IOEMU) += qemu-xen-dir endif SUBDIRS-y += xenpmd @@ -71,6 +72,7 @@ clean: subdirs-clean .PHONY: distclean distclean: subdirs-distclean rm -rf qemu-xen-traditional-dir qemu-xen-traditional-dir-remote + rm -rf qemu-xen-dir qemu-xen-dir-remote ifneq ($(XEN_COMPILE_ARCH),$(XEN_TARGET_ARCH)) IOEMU_CONFIGURE_CROSS ?= --cpu=$(XEN_TARGET_ARCH) \ @@ -96,6 +98,25 @@ qemu-xen-traditional-dir-find: cd qemu-xen-traditional-dir; \ $(QEMU_ROOT)/xen-setup $(IOEMU_CONFIGURE_CROSS) +qemu-xen-dir-find: + if test -d $(QEMU_UPSTREAM_URL) ; then \ + ln -sf $(QEMU_UPSTREAM_URL) qemu-xen-dir; \ + else \ + export GIT=$(GIT); \ + $(XEN_ROOT)/scripts/git-checkout.sh $(QEMU_UPSTREAM_URL) $(QEMU_UPSTREAM_TAG) qemu-xen-dir ; \ + fi + cd qemu-xen-dir; \ + ./configure --enable-xen --target-list=i386-softmmu \ + --source-path=$$ROOT \ + --extra-cflags="-I$(XEN_ROOT)/tools/include \ + -I$(XEN_ROOT)/tools/libxc \ + -I$(XEN_ROOT)/tools/xenstore" \ + --extra-ldflags="-L$(XEN_ROOT)/tools/libxc \ + -L$(XEN_ROOT)/tools/libxenstore" \ + --bindir=$(LIBEXEC) \ + --disable-kvm \ + $(IOEMU_CONFIGURE_CROSS) + .PHONY: qemu-xen-traditional-dir-force-update qemu-xen-traditional-dir-force-update: set -ex; \ @@ -113,6 +134,14 @@ subdir-clean-qemu-xen-traditional-dir: $(MAKE) -C qemu-xen-traditional-dir clean; \ fi +subdir-all-qemu-xen-dir subdir-install-qemu-xen-dir: qemu-xen-dir-find + +subdir-clean-qemu-xen-dir: + set -e; if test -d qemu-xen-dir/.; then \ + $(buildmakevars2shellvars); \ + $(MAKE) -C qemu-xen-dir clean; \ + fi + subdir-clean-debugger/gdbsx subdir-distclean-debugger/gdbsx: .phony $(MAKE) -C debugger/gdbsx clean _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel From xen-devel-bounces@lists.xensource.com Fri Sep 23 05:22:12 2011 Return-path: <xen-devel-bounces@lists.xensource.com> Envelope-to: www-data@lists.xensource.com Delivery-date: Fri, 23 Sep 2011 05:22:12 -0700 Received: from localhost ([127.0.0.1] helo=lists.colo.xensource.com) by lists.xensource.com with esmtp (Exim 4.43) id 1R74lg-00011L-1l; Fri, 23 Sep 2011 05:22:12 -0700 Received: from mail27.messagelabs.com ([193.109.254.147]) by lists.xensource.com with esmtp (Exim 4.43) id 1R74bB-0006MO-4A for xen-devel@lists.xensource.com; Fri, 23 Sep 2011 05:11:23 -0700 X-Env-Sender: Stefano.Stabellini@eu.citrix.com X-Msg-Ref: server-8.tower-27.messagelabs.com!1316779859!47806899!2 X-Originating-IP: [66.165.176.89] X-StarScan-Version: 6.4.1; banners=-,-,- X-VirusChecked: Checked Received: (qmail 22891 invoked from network); 23 Sep 2011 12:11:01 -0000 Received: from smtp.citrix.com (HELO SMTP.CITRIX.COM) (66.165.176.89) by server-8.tower-27.messagelabs.com with RC4-SHA encrypted SMTP; 23 Sep 2011 12:11:01 -0000 X-IronPort-AV: E=Sophos;i="4.68,430,1312171200"; d="scan'208";a="17641616" Received: from ftlpmailmx02.citrite.net ([10.13.107.66]) by FTLPIPO01.CITRIX.COM with ESMTP/TLS/RC4-MD5; 23 Sep 2011 08:11:17 -0400 Received: from smtp01.ad.xensource.com (10.219.128.104) by smtprelay.citrix.com (10.13.107.66) with Microsoft SMTP Server id 8.3.137.0; Fri, 23 Sep 2011 08:11:17 -0400 Received: from localhost.localdomain (kaball.uk.xensource.com [10.80.2.59]) by smtp01.ad.xensource.com (8.13.1/8.13.1) with ESMTP id p8NCB0tE030988; Fri, 23 Sep 2011 05:11:05 -0700 From: <stefano.stabellini@eu.citrix.com> To: xen-devel@lists.xensource.com Date: Fri, 23 Sep 2011 13:11:17 +0100 Message-ID: <1316779878-10950-4-git-send-email-stefano.stabellini@eu.citrix.com> X-Mailer: git-send-email 1.7.0.4 In-Reply-To: <alpine.DEB.2.00.1109231302370.8700@kaball-desktop> References: <alpine.DEB.2.00.1109231302370.8700@kaball-desktop> MIME-Version: 1.0 Content-Type: text/plain Cc: Ian.Campbell@eu.citrix.com, Ian.Jackson@eu.citrix.com, Stefano Stabellini <stefano.stabellini@eu.citrix.com>, keir@xen.org, Stefano.Stabellini@eu.citrix.com Subject: [Xen-devel] [PATCH v6 4/5] Clone and build Seabios by default X-BeenThere: xen-devel@lists.xensource.com X-Mailman-Version: 2.1.5 Precedence: list List-Id: Xen developer discussion <xen-devel.lists.xensource.com> List-Unsubscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe> List-Post: <mailto:xen-devel@lists.xensource.com> List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help> List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=subscribe> Sender: xen-devel-bounces@lists.xensource.com Errors-To: xen-devel-bounces@lists.xensource.com Signed-off-by: Stefano Stabellini <stefano.stabellini@eu.citrix.com> diff -r 294b63f68602 .hgignore --- a/.hgignore Fri Sep 23 11:37:09 2011 +0000 +++ b/.hgignore Fri Sep 23 11:51:06 2011 +0000 @@ -295,6 +295,8 @@ ^tools/qemu-xen-traditional-dir$ ^tools/qemu-xen-dir-remote ^tools/qemu-xen-dir$ +^tools/tools/firmware/seabios-dir-remote +^tools/tools/firmware/seabios-dir$ ^tools/ocaml/.*/.*\.annot$ ^tools/ocaml/.*/.*\.cmx?a$ ^tools/ocaml/.*/META$ diff -r 294b63f68602 Config.mk --- a/Config.mk Fri Sep 23 11:37:09 2011 +0000 +++ b/Config.mk Fri Sep 23 11:51:06 2011 +0000 @@ -194,10 +194,13 @@ endif ifeq ($(GIT_HTTP),y) QEMU_UPSTREAM_URL ?= http://xenbits.xensource.com/git-http/qemu-upstream-unstable.git +SEABIOS_UPSTREAM_URL ?= http://git.qemu.org/git/seabios.git else QEMU_UPSTREAM_URL ?= git://xenbits.xensource.com/qemu-upstream-unstable.git +SEABIOS_UPSTREAM_URL ?= git://git.qemu.org/seabios.git endif QEMU_UPSTREAM_TAG ?= 6dd84c71dff047f9e492d67e7c99928d09202760 +SEABIOS_UPSTREAM_TAG ?= 7fc039e9c262b4199fab497f3e12f4e425c37560 # Specify which qemu-dm to use. This may be `ioemu' to use the old # Mercurial in-tree version, or a local directory, or a git URL. @@ -211,15 +214,6 @@ QEMU_TAG ?= cd776ee9408ff127f934a707c1a3 # Short answer -- do not enable this unless you know what you are # doing and are prepared for some pain. -# SeaBIOS integration is a work in progress. Before enabling this -# option you must clone git://git.qemu.org/seabios.git/, possibly add -# some development patches and then build it yourself before pointing -# this variable to it (using an absolute path). -# -# Note that using SeaBIOS requires the use the upstream qemu as the -# device model. -SEABIOS_DIR ?= - # Optional components XENSTAT_XENTOP ?= y VTPM_TOOLS ?= n diff -r 294b63f68602 tools/firmware/Makefile --- a/tools/firmware/Makefile Fri Sep 23 11:37:09 2011 +0000 +++ b/tools/firmware/Makefile Fri Sep 23 11:51:06 2011 +0000 @@ -6,13 +6,18 @@ TARGET := hvmloader/hvmloader INST_DIR := $(DESTDIR)$(XENFIRMWAREDIR) SUBDIRS := +SUBDIRS += seabios-dir SUBDIRS += rombios SUBDIRS += vgabios SUBDIRS += etherboot SUBDIRS += hvmloader +seabios-dir: + GIT=$(GIT) $(XEN_ROOT)/scripts/git-checkout.sh $(SEABIOS_UPSTREAM_URL) $(SEABIOS_UPSTREAM_TAG) seabios-dir + cp seabios-config seabios-dir/.config; + .PHONY: all -all: +all: seabios-dir @set -e; if [ $$((`( bcc -v 2>&1 | grep version || echo 0.0.0 ) | cut -d' ' -f 3 | awk -F. '{ printf "0x%02x%02x%02x", $$1, $$2, $$3}'`)) -lt $$((0x00100e)) ] ; then \ echo "==========================================================================="; \ echo "Require dev86 rpm or bin86 & bcc debs version >= 0.16.14 to build firmware!"; \ @@ -35,4 +40,7 @@ clean: subdirs-clean distclean: subdirs-distclean subdir-distclean-etherboot: .phony - $(MAKE) -C etherboot distclean \ No newline at end of file + $(MAKE) -C etherboot distclean + +subdir-distclean-seabios-dir: .phony + rm -rf seabios-dir seabios-dir-remote diff -r 294b63f68602 tools/firmware/hvmloader/Makefile --- a/tools/firmware/hvmloader/Makefile Fri Sep 23 11:37:09 2011 +0000 +++ b/tools/firmware/hvmloader/Makefile Fri Sep 23 11:51:06 2011 +0000 @@ -44,6 +44,7 @@ CFLAGS += -DENABLE_ROMBIOS ROMBIOS_ROM := $(ROMBIOS_DIR)/BIOS-bochs-latest endif +SEABIOS_DIR := ../seabios-dir ifneq ($(SEABIOS_DIR),) OBJS += seabios.o CFLAGS += -DENABLE_SEABIOS diff -r 294b63f68602 tools/firmware/seabios-config --- /dev/null Thu Jan 01 00:00:00 1970 +0000 +++ b/tools/firmware/seabios-config Fri Sep 23 11:51:06 2011 +0000 @@ -0,0 +1,73 @@ +# +# Automatically generated make config: don't edit +# SeaBIOS Configuration +# Wed Sep 7 13:03:21 2011 +# + +# +# General Features +# +# CONFIG_COREBOOT is not set +CONFIG_XEN=y +CONFIG_THREADS=y +# CONFIG_THREAD_OPTIONROMS is not set +CONFIG_RELOCATE_INIT=y +CONFIG_BOOTMENU=y +# CONFIG_BOOTSPLASH is not set +CONFIG_BOOTORDER=y + +# +# Hardware support +# +CONFIG_ATA=y +CONFIG_ATA_DMA=y +CONFIG_ATA_PIO32=y +CONFIG_AHCI=y +CONFIG_VIRTIO_BLK=y +CONFIG_FLOPPY=y +CONFIG_PS2PORT=y +CONFIG_USB=y +CONFIG_USB_UHCI=y +CONFIG_USB_OHCI=y +CONFIG_USB_EHCI=y +CONFIG_USB_MSC=y +CONFIG_USB_HUB=y +CONFIG_USB_KEYBOARD=y +CONFIG_USB_MOUSE=y +CONFIG_SERIAL=y +CONFIG_LPT=y +# CONFIG_USE_SMM is not set +CONFIG_MTRR_INIT=y + +# +# BIOS interfaces +# +CONFIG_DRIVES=y +CONFIG_CDROM_BOOT=y +CONFIG_CDROM_EMU=y +CONFIG_PCIBIOS=y +CONFIG_APMBIOS=y +CONFIG_PNPBIOS=y +CONFIG_OPTIONROMS=y +# CONFIG_OPTIONROMS_DEPLOYED is not set +CONFIG_PMM=y +CONFIG_BOOT=y +CONFIG_KEYBOARD=y +CONFIG_KBD_CALL_INT15_4F=y +CONFIG_MOUSE=y +CONFIG_S3_RESUME=y +# CONFIG_DISABLE_A20 is not set + +# +# BIOS Tables +# +CONFIG_PIRTABLE=y +CONFIG_MPTABLE=y +CONFIG_SMBIOS=y +CONFIG_ACPI=y + +# +# Debugging +# +CONFIG_DEBUG_LEVEL=1 +# CONFIG_DEBUG_SERIAL is not set _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel From xen-devel-bounces@lists.xensource.com Fri Sep 23 05:36:06 2011 Return-path: <xen-devel-bounces@lists.xensource.com> Envelope-to: www-data@lists.xensource.com Delivery-date: Fri, 23 Sep 2011 05:36:06 -0700 Received: from localhost ([127.0.0.1] helo=lists.colo.xensource.com) by lists.xensource.com with esmtp (Exim 4.43) id 1R74z7-0003E8-37; Fri, 23 Sep 2011 05:36:05 -0700 Received: from mail21.messagelabs.com ([85.158.143.35]) by lists.xensource.com with smtp (Exim 4.43) id 1R74yU-00030l-Aj for xen-devel@lists.xensource.com; Fri, 23 Sep 2011 05:35:26 -0700 X-Env-Sender: anthony@overnetdata.com X-Msg-Ref: server-4.tower-21.messagelabs.com!1316781286!61337653!1 X-Originating-IP: [81.137.131.225] X-StarScan-Version: 6.4.1; banners=-,-,- X-VirusChecked: Checked Received: (qmail 25355 invoked from network); 23 Sep 2011 12:34:47 -0000 Received: from host81-137-131-225.in-addr.btopenworld.com (HELO zimbra.overnetdata.com) (81.137.131.225) by server-4.tower-21.messagelabs.com with SMTP; 23 Sep 2011 12:34:47 -0000 Received: from localhost (localhost.localdomain [127.0.0.1]) by zimbra.overnetdata.com (Postfix) with ESMTP id 7418816187F; Fri, 23 Sep 2011 13:35:13 +0100 (BST) X-Virus-Scanned: amavisd-new at overnetdata.com Received: from zimbra.overnetdata.com ([127.0.0.1]) by localhost (zimbra.overnetdata.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VAkbLrSuM2D5; Fri, 23 Sep 2011 13:35:03 +0100 (BST) Received: from [192.168.1.60] (unknown [192.168.1.60]) by zimbra.overnetdata.com (Postfix) with ESMTPSA id 5290A1616D8; Fri, 23 Sep 2011 13:35:03 +0100 (BST) Message-ID: <4E7C7CF5.1090907@overnetdata.com> Date: Fri, 23 Sep 2011 13:35:01 +0100 From: Anthony Wright <anthony@overnetdata.com> User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:6.0.2) Gecko/20110902 Thunderbird/6.0.2 MIME-Version: 1.0 To: Ian Campbell <Ian.Campbell@eu.citrix.com> Subject: Re: [Xen-devel] Kernel bug from 3.0 (was phy disks and vifs timing out in DomU) References: <4E31820C.5030200@overnetdata.com> <1311870512.24408.153.camel@cthulhu.hellion.org.uk> <4E3266DE.9000606@overnetdata.com> <20110803152841.GA2860@dumpdata.com> <4E4E3957.1040007@overnetdata.com> <20110819125615.GA26558@dumpdata.com> <4E56B132.9050708@overnetdata.com> <20110826142606.GA25511@dumpdata.com> <20110826144438.GA24836@dumpdata.com> <4E5E6843.7050206@citrix.com> <20110831170711.GB13642@dumpdata.com> <1314862972.28989.74.camel@zakaz.uk.xensource.com> <4E5FC197.7040004@goop.org> <1314904905.19389.28.camel@dagon.hellion.org.uk> <4E5FEC71.4090504@goop.org> <1314947875.28989.155.camel@zakaz.uk.xensource.com> <4E613BEF.30908@goop.org> <1315045639.19389.1683.camel@dagon.hellion.org.uk> In-Reply-To: <1315045639.19389.1683.camel@dagon.hellion.org.uk> X-Enigmail-Version: 1.3.2 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: Jeremy Fitzhardinge <jeremy@goop.org>, "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>, Keir Fraser <keir@xen.org>, Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>, David Vrabel <david.vrabel@citrix.com>, Todd Deshane <todd.deshane@xen.org> X-BeenThere: xen-devel@lists.xensource.com X-Mailman-Version: 2.1.5 Precedence: list List-Id: Xen developer discussion <xen-devel.lists.xensource.com> List-Unsubscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe> List-Post: <mailto:xen-devel@lists.xensource.com> List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help> List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=subscribe> Sender: xen-devel-bounces@lists.xensource.com Errors-To: xen-devel-bounces@lists.xensource.com On 03/09/2011 11:27, Ian Campbell wrote: > On Fri, 2011-09-02 at 21:26 +0100, Jeremy Fitzhardinge wrote: >> On 09/02/2011 12:17 AM, Ian Campbell wrote: >>> On Thu, 2011-09-01 at 21:34 +0100, Jeremy Fitzhardinge wrote: >>>> On 09/01/2011 12:21 PM, Ian Campbell wrote: >>>>> On Thu, 2011-09-01 at 18:32 +0100, Jeremy Fitzhardinge wrote: >>>>>> On 09/01/2011 12:42 AM, Ian Campbell wrote: >>>>>>> On Wed, 2011-08-31 at 18:07 +0100, Konrad Rzeszutek Wilk wrote: >>>>>>>> On Wed, Aug 31, 2011 at 05:58:43PM +0100, David Vrabel wrote: >>>>>>>>> On 26/08/11 15:44, Konrad Rzeszutek Wilk wrote: >>>>>>>>>> So while I am still looking at the hypervisor code to figure out why >>>>>>>>>> it would give me [when trying to map a grant page]: >>>>>>>>>> >>>>>>>>>> (XEN) mm.c:3846:d0 Could not find L1 PTE for address fbb42000 >>>>>>>>> It is failing in guest_map_l1e() because the page for the vmalloc'd >>>>>>>>> virtual address PTEs is not present. >>>>>>>>> >>>>>>>>> The test that fails is: >>>>>>>>> >>>>>>>>> (l2e_get_flags(l2e) & (_PAGE_PRESENT | _PAGE_PSE)) != _PAGE_PRESENT >>>>>>>>> >>>>>>>>> I think this is because the GNTTABOP_map_grant_ref hypercall is done >>>>>>>>> when task->active_mm != &init_mm and alloc_vm_area() only adds PTEs into >>>>>>>>> init_mm so when Xen looks in the page tables it doesn't find the entries >>>>>>>>> because they're not there yet. >>>>>>>>> >>>>>>>>> Putting a call to vmalloc_sync_all() after create_vm_area() and before >>>>>>>>> the hypercall makes it work for me. Classic Xen kernels used to have >>>>>>>>> such a call. >>>>>>>> That sounds quite reasonable. >>>>>>> I was wondering why upstream was missing the vmalloc_sync_all() in >>>>>>> alloc_vm_area() since the out-of-tree kernels did have it and the >>>>>>> function was added by us. I found this: >>>>>>> http://git.kernel.org/?p=linux/kernel/git/torvalds/linux.git;a=commitdiff;h=ef691947d8a3d479e67652312783aedcf629320a >>>>>>> >>>>>>> commit ef691947d8a3d479e67652312783aedcf629320a >>>>>>> Author: Jeremy Fitzhardinge <jeremy.fitzhardinge@citrix.com> >>>>>>> Date: Wed Dec 1 15:45:48 2010 -0800 >>>>>>> >>>>>>> vmalloc: remove vmalloc_sync_all() from alloc_vm_area() >>>>>>> >>>>>>> There's no need for it: it will get faulted into the current pagetable >>>>>>> as needed. >>>>>>> >>>>>>> Signed-off-by: Jeremy Fitzhardinge <jeremy.fitzhardinge@citrix.com> >>>>>>> >>>>>>> The flaw in the reasoning here is that you cannot take a kernel fault >>>>>>> while processing a hypercall, so hypercall arguments must have been >>>>>>> faulted in beforehand and that is what the sync_all was for. >>>>>> That's a good point. (Maybe Xen should have generated pagefaults when >>>>>> hypercall arg pointers are bad...) >>>>> I think it would be a bit tricky to do in practice, you'd either have to >>>>> support recursive hypercalls in the middle of other hypercalls (because >>>>> the page fault handler is surely going to want to do some) or proper >>>>> hypercall restart (so you can fully return to guest context to handle >>>>> the fault then retry) or something along those and complexifying up the >>>>> hypervisor one way or another. Probably not impossible if you were >>>>> building something form the ground up, but not trivial. >>>> Well, Xen already has the continuation machinery for dealing with >>>> hypercall restart, so that could be reused. >>> That requires special support beyond just calling the continuation in >>> each hypercall (often extending into the ABI) for pickling progress and >>> picking it up again, only a small number of (usually long running) >>> hypercalls have that support today. It also uses the guest context to >>> store the state which perhaps isn't helpful if you want to return to the >>> guest, although I suppose building a nested frame would work. >> I guess it depends on how many hypercalls do work before touching guest >> memory, but any hypercall should be like that anyway, or at least be >> able to wind back work done if a later read EFAULTs. >> >> I was vaguely speculating about a scheme on the lines of: >> >> 1. In copy_to/from_user, if we touch a bad address, save it in a >> per-vcpu "bad_guest_addr" >> 2. when returning to the guest, if the errno is EFAULT and >> bad_guest_addr is set, then generate a memory fault frame with cr2 = >> bad_guest_addr, and with the exception return restarting the hypercall >> >> Perhaps there should be a EFAULT_RETRY error return to trigger this >> behaviour, rather than doing it for all EFAULTs, so the faulting >> behaviour can be added incrementally. > The kernel uses -ERESTARTSSYS for something similar, doesn't it? > > Does this scheme work if the hypercall causing the exception was itself > runnnig in an exception handler? I guess it depends on the architecture > +OSes handling of nested faults. > >> Maybe this is a lost cause for x86, but perhaps its worth considering >> for new ports? > Certainly worth thinking about. > >>> The guys doing paging and sharing etc looked into this and came to the >>> conclusion that it would be intractably difficult to do this fully -- >>> hence we now have the ability to sleep in hypercalls, which works >>> because the pager/sharer is in a different domain/vcpu. >> Hmm. Were they looking at injecting faults back into the guest, or >> forwarding "missing page" events off to another domain? > Sharing and swapping are transparent to the domain, another domain runs > the swapper/unshare process (actually, unshare might be in the h/v > itself, not sure). > >>>> And accesses to guest >>>> memory are already special events which must be checked so that EFAULT >>>> can be returned. If, rather than failing with EFAULT Xen set up a >>>> pagefault exception for the guest CPU with the return set up to retry >>>> the hypercall, it should all work... >>>> >>>> Of course, if the guest isn't expecting that - or its buggy - then it >>>> could end up in an infinite loop. But maybe a flag (set a high bit in >>>> the hypercall number?), or a feature, or something? Might be worthwhile >>>> if it saves guests having to do something expensive (like a >>>> vmalloc_sync_all), even if they have to also deal with old hypervisors. >>> The vmalloc_sync_all is a pretty event even on Xen though, isn't it? >> Looks like an important word is missing there. But its very expensive, >> if that's what you're saying. > Oops. "rare" was the missing word. Is there any progress on an official patch for this? I have my own unofficial patch which places a vmalloc_sync_all() after every alloc_vm_area() call and it works, but from the thread it sounds like there should be a more sophisticated solution to the problem. _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel From xen-devel-bounces@lists.xensource.com Fri Sep 23 05:39:22 2011 Return-path: <xen-devel-bounces@lists.xensource.com> Envelope-to: www-data@lists.xensource.com Delivery-date: Fri, 23 Sep 2011 05:39:22 -0700 Received: from localhost ([127.0.0.1] helo=lists.colo.xensource.com) by lists.xensource.com with esmtp (Exim 4.43) id 1R752I-0004HK-PX; Fri, 23 Sep 2011 05:39:22 -0700 Received: from mail27.messagelabs.com ([193.109.254.147]) by lists.xensource.com with esmtp (Exim 4.43) id 1R74zZ-0003Mh-Lu for xen-devel@lists.xensource.com; Fri, 23 Sep 2011 05:36:35 -0700 X-Env-Sender: Paul.Durrant@citrix.com X-Msg-Ref: server-12.tower-27.messagelabs.com!1316781373!43644345!1 X-Originating-IP: [66.165.176.89] X-StarScan-Version: 6.4.1; banners=-,-,- X-VirusChecked: Checked Received: (qmail 1496 invoked from network); 23 Sep 2011 12:36:14 -0000 Received: from smtp.citrix.com (HELO SMTP.CITRIX.COM) (66.165.176.89) by server-12.tower-27.messagelabs.com with RC4-SHA encrypted SMTP; 23 Sep 2011 12:36:14 -0000 X-IronPort-AV: E=Sophos;i="4.68,430,1312171200"; d="scan'208";a="17642135" Received: from ftlpmailmx02.citrite.net ([10.13.107.66]) by FTLPIPO01.CITRIX.COM with ESMTP/TLS/RC4-MD5; 23 Sep 2011 08:36:28 -0400 Received: from localhost.localdomain (10.80.16.52) by smtprelay.citrix.com (10.13.107.66) with Microsoft SMTP Server id 8.3.137.0; Fri, 23 Sep 2011 08:36:28 -0400 Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Mercurial-Node: 55a9ffe0ca81b9b4183626f81fa54343d378704f Message-ID: <55a9ffe0ca81b9b41836.1316781366@localhost.localdomain> User-Agent: Mercurial-patchbomb/1.6.4 Date: Fri, 23 Sep 2011 13:36:06 +0100 From: Paul Durrant <paul.durrant@citrix.com> To: xen-devel@lists.xensource.com Subject: [Xen-devel] [PATCH] Add save/restore support for viridian APIC assist pfn X-BeenThere: xen-devel@lists.xensource.com X-Mailman-Version: 2.1.5 Precedence: list List-Id: Xen developer discussion <xen-devel.lists.xensource.com> List-Unsubscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe> List-Post: <mailto:xen-devel@lists.xensource.com> List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help> List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=subscribe> Sender: xen-devel-bounces@lists.xensource.com Errors-To: xen-devel-bounces@lists.xensource.com # HG changeset patch # User Paul Durrant <paul.durrant@citrix.com> # Date 1316781326 -3600 # Node ID 55a9ffe0ca81b9b4183626f81fa54343d378704f # Parent cc339ab1d91789ed6ff4d3d9abc1bae2e90ac294 Add save/restore support for viridian APIC assist pfn. c/s 17b754cab7b0 introduced a per-VCPU viridian structure to store the APIC assist pfn. This patch adds support for save and restore of that value. Signed-off-by: Paul Durrant <paul.durrant@citrix.com> diff -r cc339ab1d917 -r 55a9ffe0ca81 tools/misc/xen-hvmctx.c --- a/tools/misc/xen-hvmctx.c Thu Sep 22 18:37:06 2011 +0100 +++ b/tools/misc/xen-hvmctx.c Fri Sep 23 13:35:26 2011 +0100 @@ -366,15 +366,23 @@ static void dump_mtrr(void) (unsigned long long) p.msr_mtrr_fixed[i]); } -static void dump_viridian(void) +static void dump_viridian_domain(void) { - HVM_SAVE_TYPE(VIRIDIAN) p; + HVM_SAVE_TYPE(VIRIDIAN_DOMAIN) p; READ(p); - printf(" VIRIDIAN: hypercall gpa 0x%llx, guest ID 0x%llx\n", + printf(" VIRIDIAN_DOMAIN: hypercall gpa 0x%llx, guest_os_id 0x%llx\n", (unsigned long long) p.hypercall_gpa, (unsigned long long) p.guest_os_id); } +static void dump_viridian_vcpu(void) +{ + HVM_SAVE_TYPE(VIRIDIAN_VCPU) p; + READ(p); + printf(" VIRIDIAN_VCPU: apic_assist 0x%llx\n", + (unsigned long long) p.apic_assist); +} + int main(int argc, char **argv) { int entry, domid; @@ -439,7 +447,8 @@ int main(int argc, char **argv) case HVM_SAVE_CODE(HPET): dump_hpet(); break; case HVM_SAVE_CODE(PMTIMER): dump_pmtimer(); break; case HVM_SAVE_CODE(MTRR): dump_mtrr(); break; - case HVM_SAVE_CODE(VIRIDIAN): dump_viridian(); break; + case HVM_SAVE_CODE(VIRIDIAN_DOMAIN): dump_viridian_domain(); break; + case HVM_SAVE_CODE(VIRIDIAN_VCPU): dump_viridian_vcpu(); break; case HVM_SAVE_CODE(END): break; default: printf(" ** Don't understand type %u: skipping\n", diff -r cc339ab1d917 -r 55a9ffe0ca81 xen/arch/x86/hvm/viridian.c --- a/xen/arch/x86/hvm/viridian.c Thu Sep 22 18:37:06 2011 +0100 +++ b/xen/arch/x86/hvm/viridian.c Fri Sep 23 13:35:26 2011 +0100 @@ -172,10 +172,10 @@ void initialize_apic_assist(struct vcpu uint8_t *p; /* - * We don't support the APIC assist page, and that fact is reflected in - * our CPUID flags. However, Newer versions of Windows have a bug which - * means that they don't recognise that, and tries to use the page - * anyway. We therefore have to fake up just enough to keep windows happy. + * We don't yet make use of the APIC assist page but by setting + * the CPUID3A_MSR_APIC_ACCESS bit in CPUID leaf 40000003 we are duty + * bound to support the MSR. We therefore do just enough to keep windows + * happy. * * See http://msdn.microsoft.com/en-us/library/ff538657%28VS.85%29.aspx for * details of how Windows uses the page. @@ -387,9 +387,9 @@ out: return HVM_HCALL_completed; } -static int viridian_save_cpu_ctxt(struct domain *d, hvm_domain_context_t *h) +static int viridian_save_domain_ctxt(struct domain *d, hvm_domain_context_t *h) { - struct hvm_viridian_context ctxt; + struct hvm_viridian_domain_context ctxt; if ( !is_viridian_domain(d) ) return 0; @@ -397,14 +397,14 @@ static int viridian_save_cpu_ctxt(struct ctxt.hypercall_gpa = d->arch.hvm_domain.viridian.hypercall_gpa.raw; ctxt.guest_os_id = d->arch.hvm_domain.viridian.guest_os_id.raw; - return (hvm_save_entry(VIRIDIAN, 0, h, &ctxt) != 0); + return (hvm_save_entry(VIRIDIAN_DOMAIN, 0, h, &ctxt) != 0); } -static int viridian_load_cpu_ctxt(struct domain *d, hvm_domain_context_t *h) +static int viridian_load_domain_ctxt(struct domain *d, hvm_domain_context_t *h) { - struct hvm_viridian_context ctxt; + struct hvm_viridian_domain_context ctxt; - if ( hvm_load_entry(VIRIDIAN, h, &ctxt) != 0 ) + if ( hvm_load_entry(VIRIDIAN_DOMAIN, h, &ctxt) != 0 ) return -EINVAL; d->arch.hvm_domain.viridian.hypercall_gpa.raw = ctxt.hypercall_gpa; @@ -413,5 +413,48 @@ static int viridian_load_cpu_ctxt(struct return 0; } -HVM_REGISTER_SAVE_RESTORE(VIRIDIAN, viridian_save_cpu_ctxt, - viridian_load_cpu_ctxt, 1, HVMSR_PER_DOM); +HVM_REGISTER_SAVE_RESTORE(VIRIDIAN_DOMAIN, viridian_save_domain_ctxt, + viridian_load_domain_ctxt, 1, HVMSR_PER_DOM); + +static int viridian_save_vcpu_ctxt(struct domain *d, hvm_domain_context_t *h) +{ + struct vcpu *v; + + if ( !is_viridian_domain(d) ) + return 0; + + for_each_vcpu( d, v ) { + struct hvm_viridian_vcpu_context ctxt; + + ctxt.apic_assist = v->arch.hvm_vcpu.viridian.apic_assist.raw; + + if ( hvm_save_entry(VIRIDIAN_VCPU, v->vcpu_id, h, &ctxt) != 0 ) + return 1; + } + + return 0; +} + +static int viridian_load_vcpu_ctxt(struct domain *d, hvm_domain_context_t *h) +{ + int vcpuid; + struct vcpu *v; + struct hvm_viridian_vcpu_context ctxt; + + vcpuid = hvm_load_instance(h); + if ( vcpuid >= d->max_vcpus || (v = d->vcpu[vcpuid]) == NULL ) + { + gdprintk(XENLOG_ERR, "HVM restore: domain has no vcpu %u\n", vcpuid); + return -EINVAL; + } + + if ( hvm_load_entry(VIRIDIAN_VCPU, h, &ctxt) != 0 ) + return -EINVAL; + + v->arch.hvm_vcpu.viridian.apic_assist.raw = ctxt.apic_assist; + + return 0; +} + +HVM_REGISTER_SAVE_RESTORE(VIRIDIAN_VCPU, viridian_save_vcpu_ctxt, + viridian_load_vcpu_ctxt, 1, HVMSR_PER_VCPU); diff -r cc339ab1d917 -r 55a9ffe0ca81 xen/include/public/arch-x86/hvm/save.h --- a/xen/include/public/arch-x86/hvm/save.h Thu Sep 22 18:37:06 2011 +0100 +++ b/xen/include/public/arch-x86/hvm/save.h Fri Sep 23 13:35:26 2011 +0100 @@ -547,18 +547,6 @@ struct hvm_hw_mtrr { DECLARE_HVM_SAVE_TYPE(MTRR, 14, struct hvm_hw_mtrr); /* - * Viridian hypervisor context. - */ - -struct hvm_viridian_context { - uint64_t hypercall_gpa; - uint64_t guest_os_id; -}; - -DECLARE_HVM_SAVE_TYPE(VIRIDIAN, 15, struct hvm_viridian_context); - - -/* * The save area of XSAVE/XRSTOR. */ @@ -580,9 +568,26 @@ struct hvm_hw_cpu_xsave { #define CPU_XSAVE_CODE 16 +/* + * Viridian hypervisor context. + */ + +struct hvm_viridian_domain_context { + uint64_t hypercall_gpa; + uint64_t guest_os_id; +}; + +DECLARE_HVM_SAVE_TYPE(VIRIDIAN_DOMAIN, 15, struct hvm_viridian_domain_context); + +struct hvm_viridian_vcpu_context { + uint64_t apic_assist; +}; + +DECLARE_HVM_SAVE_TYPE(VIRIDIAN_VCPU, 17, struct hvm_viridian_vcpu_context); + /* * Largest type-code in use */ -#define HVM_SAVE_CODE_MAX 16 +#define HVM_SAVE_CODE_MAX 17 #endif /* __XEN_PUBLIC_HVM_SAVE_X86_H__ */ _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel From xen-devel-bounces@lists.xensource.com Fri Sep 23 05:48:45 2011 Return-path: <xen-devel-bounces@lists.xensource.com> Envelope-to: www-data@lists.xensource.com Delivery-date: Fri, 23 Sep 2011 05:48:45 -0700 Received: from localhost ([127.0.0.1] helo=lists.colo.xensource.com) by lists.xensource.com with esmtp (Exim 4.43) id 1R75BM-0005X1-Sm; Fri, 23 Sep 2011 05:48:44 -0700 Received: from mail21.messagelabs.com ([85.158.143.35]) by lists.xensource.com with esmtp (Exim 4.43) id 1R759V-0004wg-EU for xen-devel@lists.xensource.com; Fri, 23 Sep 2011 05:46:49 -0700 X-Env-Sender: david.vrabel@citrix.com X-Msg-Ref: server-12.tower-21.messagelabs.com!1316781989!51064394!1 X-Originating-IP: [66.165.176.89] X-StarScan-Version: 6.4.1; banners=-,-,- X-VirusChecked: Checked Received: (qmail 25456 invoked from network); 23 Sep 2011 12:46:30 -0000 Received: from smtp.citrix.com (HELO SMTP.CITRIX.COM) (66.165.176.89) by server-12.tower-21.messagelabs.com with RC4-SHA encrypted SMTP; 23 Sep 2011 12:46:30 -0000 X-IronPort-AV: E=Sophos;i="4.68,430,1312171200"; d="scan'208";a="17642342" Received: from ftlpmailmx02.citrite.net ([10.13.107.66]) by FTLPIPO01.CITRIX.COM with ESMTP/TLS/RC4-MD5; 23 Sep 2011 08:46:44 -0400 Received: from [10.80.2.76] (10.80.2.76) by FTLPMAILMX02.citrite.net (10.13.107.66) with Microsoft SMTP Server id 8.3.137.0; Fri, 23 Sep 2011 08:46:44 -0400 Message-ID: <4E7C804C.1060904@citrix.com> Date: Fri, 23 Sep 2011 13:49:16 +0100 From: David Vrabel <david.vrabel@citrix.com> User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.1.16) Gecko/20110818 Icedove/3.0.11 MIME-Version: 1.0 To: Anthony Wright <anthony@overnetdata.com> Subject: Re: [Xen-devel] Kernel bug from 3.0 (was phy disks and vifs timing out in DomU) References: <4E31820C.5030200@overnetdata.com> <1311870512.24408.153.camel@cthulhu.hellion.org.uk> <4E3266DE.9000606@overnetdata.com> <20110803152841.GA2860@dumpdata.com> <4E4E3957.1040007@overnetdata.com> <20110819125615.GA26558@dumpdata.com> <4E56B132.9050708@overnetdata.com> <20110826142606.GA25511@dumpdata.com> <20110826144438.GA24836@dumpdata.com> <4E5E6843.7050206@citrix.com> <20110831170711.GB13642@dumpdata.com> <1314862972.28989.74.camel@zakaz.uk.xensource.com> <4E5FC197.7040004@goop.org> <1314904905.19389.28.camel@dagon.hellion.org.uk> <4E5FEC71.4090504@goop.org> <1314947875.28989.155.camel@zakaz.uk.xensource.com> <4E613BEF.30908@goop.org> <1315045639.19389.1683.camel@dagon.hellion.org.uk> <4E7C7CF5.1090907@overnetdata.com> In-Reply-To: <4E7C7CF5.1090907@overnetdata.com> Content-Type: text/plain; charset="ISO-8859-1" Content-Transfer-Encoding: 7bit Cc: Jeremy Fitzhardinge <jeremy@goop.org>, "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>, Keir Fraser <keir@xen.org>, Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>, Ian Campbell <Ian.Campbell@eu.citrix.com>, Todd, Deshane <todd.deshane@xen.org> X-BeenThere: xen-devel@lists.xensource.com X-Mailman-Version: 2.1.5 Precedence: list List-Id: Xen developer discussion <xen-devel.lists.xensource.com> List-Unsubscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe> List-Post: <mailto:xen-devel@lists.xensource.com> List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help> List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=subscribe> Sender: xen-devel-bounces@lists.xensource.com Errors-To: xen-devel-bounces@lists.xensource.com On 23/09/11 13:35, Anthony Wright wrote: > > Is there any progress on an official patch for this [unsync'd vmalloc > address space bug]? I have my own unofficial patch which places a > vmalloc_sync_all() after every alloc_vm_area() call and it works, but > from the thread it sounds like there should be a more sophisticated > solution to the problem. The simple patch (re-adding the vmalloc_sync_all()) has been applied to 3.1-rc7 and should be in the next 3.0-stable release. I'm still working on a more elegant fix. David _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel From xen-devel-bounces@lists.xensource.com Fri Sep 23 06:30:39 2011 Return-path: <xen-devel-bounces@lists.xensource.com> Envelope-to: www-data@lists.xensource.com Delivery-date: Fri, 23 Sep 2011 06:30:39 -0700 Received: from localhost ([127.0.0.1] helo=lists.colo.xensource.com) by lists.xensource.com with esmtp (Exim 4.43) id 1R75pu-0006h3-SH; Fri, 23 Sep 2011 06:30:38 -0700 Received: from mail174.messagelabs.com ([85.158.138.51]) by lists.xensource.com with esmtp (Exim 4.43) id 1R75ov-0006UO-8l for xen-devel@lists.xensource.com; Fri, 23 Sep 2011 06:29:39 -0700 X-Env-Sender: Ian.Jackson@eu.citrix.com X-Msg-Ref: server-2.tower-174.messagelabs.com!1316784573!32516700!1 X-Originating-IP: [62.200.22.115] X-StarScan-Version: 6.4.1; banners=-,-,- X-VirusChecked: Checked Received: (qmail 9318 invoked from network); 23 Sep 2011 13:29:33 -0000 Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115) by server-2.tower-174.messagelabs.com with RC4-SHA encrypted SMTP; 23 Sep 2011 13:29:33 -0000 X-IronPort-AV: E=Sophos;i="4.68,430,1312156800"; d="scan'208";a="8030565" Received: from lonpmailmx01.citrite.net ([10.30.203.162]) by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5; 23 Sep 2011 13:29:33 +0000 Received: from woking.xci-test.com (10.80.248.135) by smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id 8.3.137.0; Fri, 23 Sep 2011 14:29:33 +0100 Received: from osstest by woking.xci-test.com with local (Exim 4.69) (envelope-from <ian.jackson@eu.citrix.com>) id 1R75or-0000jK-4C; Fri, 23 Sep 2011 14:29:33 +0100 To: <xen-devel@lists.xensource.com> Message-ID: <osstest-9043-mainreport@xen.org> From: xen.org <ian.jackson@eu.citrix.com> Date: Fri, 23 Sep 2011 14:29:33 +0100 MIME-Version: 1.0 Content-Type: text/plain Cc: ian.jackson@eu.citrix.com Subject: [Xen-devel] [xen-unstable test] 9043: regressions - FAIL X-BeenThere: xen-devel@lists.xensource.com X-Mailman-Version: 2.1.5 Precedence: list List-Id: Xen developer discussion <xen-devel.lists.xensource.com> List-Unsubscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe> List-Post: <mailto:xen-devel@lists.xensource.com> List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help> List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=subscribe> Sender: xen-devel-bounces@lists.xensource.com Errors-To: xen-devel-bounces@lists.xensource.com flight 9043 xen-unstable real [real] http://www.chiark.greenend.org.uk/~xensrcts/logs/9043/ Regressions :-( Tests which did not succeed and are blocking: test-amd64-i386-rhel6hvm-amd 5 xen-boot fail REGR. vs. 8995 test-amd64-amd64-xl-win 5 xen-boot fail REGR. vs. 8995 Tests which are failing intermittently (not blocking): test-amd64-i386-xl-multivcpu 5 xen-boot fail pass in 9005 test-amd64-i386-xl-credit2 5 xen-boot fail pass in 9000 test-i386-i386-xl 5 xen-boot fail pass in 9005 test-i386-i386-win 5 xen-boot fail pass in 9005 test-amd64-amd64-win 5 xen-boot fail pass in 9005 test-amd64-i386-win-vcpus1 5 xen-boot fail pass in 9005 test-amd64-i386-win 5 xen-boot fail pass in 9005 test-amd64-amd64-xl 5 xen-boot fail in 9005 pass in 9043 test-amd64-i386-pv 5 xen-boot fail in 9005 pass in 9043 test-i386-i386-pv 5 xen-boot fail in 9005 pass in 9043 test-amd64-i386-pair 8 xen-boot/dst_host fail in 9005 pass in 9043 test-amd64-i386-pair 7 xen-boot/src_host fail in 9005 pass in 9043 test-amd64-amd64-pair 8 xen-boot/dst_host fail in 9005 pass in 9043 test-amd64-amd64-pair 7 xen-boot/src_host fail in 9005 pass in 9043 test-amd64-amd64-pv 5 xen-boot fail in 9000 pass in 9043 test-amd64-i386-xl-win-vcpus1 5 xen-boot fail in 9000 pass in 9043 test-i386-i386-pair 8 xen-boot/dst_host fail in 9000 pass in 9043 test-i386-i386-pair 7 xen-boot/src_host fail in 9000 pass in 9043 Tests which did not succeed, but are not blocking, including regressions (tests previously passed) regarded as allowable: test-amd64-amd64-xl-pcipt-intel 9 guest-start fail never pass test-amd64-amd64-xl-sedf 14 guest-localmigrate/x10 fail like 8995 test-amd64-i386-rhel6hvm-intel 9 guest-start.2 fail never pass test-amd64-i386-xl-win-vcpus1 13 guest-stop fail never pass test-i386-i386-xl-win 13 guest-stop fail never pass test-i386-i386-win 16 leak-check/check fail in 9005 never pass test-amd64-amd64-win 16 leak-check/check fail in 9005 never pass test-amd64-i386-win-vcpus1 16 leak-check/check fail in 9005 never pass test-amd64-i386-win 16 leak-check/check fail in 9005 never pass version targeted for testing: xen cc339ab1d917 baseline version: xen a422e2a4451e ------------------------------------------------------------ People who touched revisions under test: Andreas Herrmann <herrmann.der.user@googlemail.com> Ian Campbell <ian.campbell@citrix.com> Ian Jackson <ian.jackson@eu.citrix.com> Jan Beulich <jbeulich@suse.com> Lasse Collin <lasse.collin@tukaani.org> Olaf Hering <olaf@aepfle.de> Thomas Renninger <trenn@suse.de> ------------------------------------------------------------ jobs: build-amd64 pass build-i386 pass build-amd64-oldkern pass build-i386-oldkern pass build-amd64-pvops pass build-i386-pvops pass test-amd64-amd64-xl pass test-amd64-i386-xl pass test-i386-i386-xl fail test-amd64-i386-rhel6hvm-amd fail test-amd64-i386-xl-credit2 fail test-amd64-amd64-xl-pcipt-intel fail test-amd64-i386-rhel6hvm-intel fail test-amd64-i386-xl-multivcpu fail test-amd64-amd64-pair pass test-amd64-i386-pair pass test-i386-i386-pair pass test-amd64-amd64-pv pass test-amd64-i386-pv pass test-i386-i386-pv pass test-amd64-amd64-xl-sedf fail test-amd64-i386-win-vcpus1 fail test-amd64-i386-xl-win-vcpus1 fail test-amd64-amd64-win fail test-amd64-i386-win fail test-i386-i386-win fail test-amd64-amd64-xl-win fail test-i386-i386-xl-win fail ------------------------------------------------------------ sg-report-flight on woking.cam.xci-test.com logs: /home/xc_osstest/logs images: /home/xc_osstest/images Logs, config files, etc. are available at http://www.chiark.greenend.org.uk/~xensrcts/logs Test harness code can be found at http://xenbits.xensource.com/gitweb?p=osstest.git;a=summary Not pushing. ------------------------------------------------------------ changeset: 23872:cc339ab1d917 tag: tip user: Ian Campbell <ian.campbell@citrix.com> date: Thu Sep 22 18:37:06 2011 +0100 tools: fix install of lomount $(BIN) went away in 23124:e3d4c34b14a3. Also there are no *.so, *.a or *.rpm built in here Signed-off-by: Ian Campbell <ian.campbell@citrix.com> changeset: 23871:503ee256fecf user: Jan Beulich <jbeulich@suse.com> date: Thu Sep 22 18:35:30 2011 +0100 x86: ucode-amd: Don't warn when no ucode is available for a CPU revision This patch originally comes from the Linus mainline kernel (2.6.33), find below the patch details: From: Andreas Herrmann <herrmann.der.user@googlemail.com> There is no point in warning when there is no ucode available for a specific CPU revision. Currently the container-file, which provides the AMD ucode patches for OS load, contains only a few ucode patches. It's already clearly indicated by the printed patch_level whenever new ucode was available and an update happened. So the warning message is of no help but rather annoying on systems with many CPUs. Signed-off-by: Thomas Renninger <trenn@suse.de> Signed-off-by: Jan Beulich <jbeulich@suse.com> changeset: 23870:5c97b02f48fc user: Jan Beulich <jbeulich@suse.com> date: Thu Sep 22 18:34:27 2011 +0100 XZ: Fix incorrect XZ_BUF_ERROR From: Lasse Collin <lasse.collin@tukaani.org> xz_dec_run() could incorrectly return XZ_BUF_ERROR if all of the following was true: - The caller knows how many bytes of output to expect and only provides that much output space. - When the last output bytes are decoded, the caller-provided input buffer ends right before the LZMA2 end of payload marker. So LZMA2 won't provide more output anymore, but it won't know it yet and thus won't return XZ_STREAM_END yet. - A BCJ filter is in use and it hasn't left any unfiltered bytes in the temp buffer. This can happen with any BCJ filter, but in practice it's more likely with filters other than the x86 BCJ. This fixes <https://bugzilla.redhat.com/show_bug.cgi?id=3D735408> where Squashfs thinks that a valid file system is corrupt. This also fixes a similar bug in single-call mode where the uncompressed size of a block using BCJ + LZMA2 was 0 bytes and caller provided no output space. Many empty .xz files don't contain any blocks and thus don't trigger this bug. This also tweaks a closely related detail: xz_dec_bcj_run() could call xz_dec_lzma2_run() to decode into temp buffer when it was known to be useless. This was harmless although it wasted a minuscule number of CPU cycles. Signed-off-by: Lasse Collin <lasse.collin@tukaani.org> Signed-off-by: Jan Beulich <jbeulich@suse.com> changeset: 23869:db1ea4b127cd user: Jan Beulich <jbeulich@suse.com> date: Thu Sep 22 18:33:48 2011 +0100 XZ decompressor: Fix decoding of empty LZMA2 streams From: Lasse Collin <lasse.collin@tukaani.org> The old code considered valid empty LZMA2 streams to be corrupt. Note that a typical empty .xz file has no LZMA2 data at all, and thus most .xz files having no uncompressed data are handled correctly even without this fix. Signed-off-by: Lasse Collin <lasse.collin@tukaani.org> Signed-off-by: Jan Beulich <jbeulich@suse.com> changeset: 23868:28147fd781af user: Jan Beulich <jbeulich@suse.com> date: Thu Sep 22 18:32:34 2011 +0100 VT-d: fix off-by-one error in RMRR validation (base_addr,end_addr) is an inclusive range, and hence there shouldn't be a subtraction of 1 in the second invocation of page_is_ram_type(). For RMRRs covering a single page that actually resulted in the immediately preceding page to get checked (which could have resulted in a false warning). Signed-off-by: Jan Beulich <jbeulich@suse.com> changeset: 23867:571b6e90dfb4 user: Jan Beulich <jbeulich@suse.com> date: Thu Sep 22 18:31:44 2011 +0100 VT-d: eliminate a mis-use of pcidevs_lock dma_pte_clear_one() shouldn't acquire this global lock for the purpose of processing a per-domain list. Furthermore the function a few lines earlier has a comment stating that acquiring pcidevs_lock isn't necessary here (whether that's really correct is another question). Use the domain's mappin_lock instead to protect the mapped_rmrrs list. Fold domain_rmrr_mapped() into its sole caller so that the otherwise implicit dependency on pcidevs_lock there becomes more obvious (see the comment there). Signed-off-by: Jan Beulich <jbeulich@suse.com> changeset: 23866:47ec1d405af9 user: Jan Beulich <jbeulich@suse.com> date: Thu Sep 22 18:31:02 2011 +0100 x86: IO-APIC code has no dependency on PCI The IRQ handling code requires pcidevs_lock to be held only for MSI interrupts. As the handling of which was now fully moved into msi.c (i.e. while applying fine without, the patch needs to be applied after the one titled "x86: split MSI IRQ chip"), io_apic.c now also doesn't need to include PCI headers anymore. Signed-off-by: Jan Beulich <jbeulich@suse.com> changeset: 23865:d6e01c7853cf user: Jan Beulich <jbeulich@suse.com> date: Thu Sep 22 18:29:19 2011 +0100 PCI multi-seg: config space accessor adjustments Signed-off-by: Jan Beulich <jbeulich@suse.com> changeset: 23864:314b147d524d user: Jan Beulich <jbeulich@suse.com> date: Thu Sep 22 18:28:38 2011 +0100 PCI multi-seg: Pass-through adjustments Signed-off-by: Jan Beulich <jbeulich@suse.com> changeset: 23863:9e0259239822 user: Jan Beulich <jbeulich@suse.com> date: Thu Sep 22 18:28:03 2011 +0100 PCI multi-seg: AMD-IOMMU specific adjustments There are two places here where it is entirely unclear to me where the necessary PCI segment number should be taken from (as IVMD descriptors don't have such, only IVHD ones do). AMD confirmed that for the time being it is acceptable to imply that only segment 0 exists. Signed-off-by: Jan Beulich <jbeulich@suse.com> changeset: 23862:85418e168527 user: Jan Beulich <jbeulich@suse.com> date: Thu Sep 22 18:27:26 2011 +0100 PCI multi-seg: VT-d specific adjustments Signed-off-by: Jan Beulich <jbeulich@suse.com> changeset: 23861:ec7c81fbe0de user: Jan Beulich <jbeulich@suse.com> date: Thu Sep 22 18:26:54 2011 +0100 PCI multi-seg: adjust domctl interface Again, a couple of directly related functions at once get adjusted to account for the segment number. Signed-off-by: Jan Beulich <jbeulich@suse.com> changeset: 23860:a422e2a4451e user: Jan Beulich <jbeulich@suse.com> date: Sun Sep 18 00:26:52 2011 +0100 x86: split MSI IRQ chip With the .end() accessor having become optional and noting that several of the accessors' behavior really depends on the result of msi_maskable_irq(), the splits the MSI IRQ chip type into two - one for the maskable ones, and the other for the (MSI only) non-maskable ones. At once the implementation of those methods gets moved from io_apic.c to msi.c. Signed-off-by: Jan Beulich <jbeulich@suse.com> ======================================== commit cd776ee9408ff127f934a707c1a339ee600bc127 Author: Ian Jackson <ian.jackson@eu.citrix.com> Date: Tue Jun 28 13:50:53 2011 +0100 qemu-char.c: fix incorrect CONFIG_STUBDOM handling qemu-char.c:1123:7: warning: "CONFIG_STUBDOM" is not defined [-Wundef] Signed-off-by: Olaf Hering <olaf@aepfle.de> Acked-by: Ian Jackson <ian.jackson@eu.citrix.com> _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel From xen-devel-bounces@lists.xensource.com Fri Sep 23 06:31:49 2011 Return-path: <xen-devel-bounces@lists.xensource.com> Envelope-to: www-data@lists.xensource.com Delivery-date: Fri, 23 Sep 2011 06:31:49 -0700 Received: from localhost ([127.0.0.1] helo=lists.colo.xensource.com) by lists.xensource.com with esmtp (Exim 4.43) id 1R75r3-00074g-Ng; Fri, 23 Sep 2011 06:31:49 -0700 Received: from mail174.messagelabs.com ([85.158.138.51]) by lists.xensource.com with esmtp (Exim 4.43) id 1R75p7-0006VM-Pz for xen-devel@lists.xensource.com; Fri, 23 Sep 2011 06:29:51 -0700 X-Env-Sender: konrad@oracle.com X-Msg-Ref: server-10.tower-174.messagelabs.com!1316784585!32499849!1 X-Originating-IP: [148.87.113.117] X-StarScan-Version: 6.4.1; banners=-,-,- X-VirusChecked: Checked Received: (qmail 5359 invoked from network); 23 Sep 2011 13:29:46 -0000 Received: from rcsinet15.oracle.com (HELO rcsinet15.oracle.com) (148.87.113.117) by server-10.tower-174.messagelabs.com with DHE-RSA-AES256-SHA encrypted SMTP; 23 Sep 2011 13:29:46 -0000 Received: from rtcsinet22.oracle.com (rtcsinet22.oracle.com [66.248.204.30]) by rcsinet15.oracle.com (Switch-3.4.4/Switch-3.4.4) with ESMTP id p8NDTgkw008153 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Fri, 23 Sep 2011 13:29:44 GMT Received: from acsmt357.oracle.com (acsmt357.oracle.com [141.146.40.157]) by rtcsinet22.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id p8NDTemk002011 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 23 Sep 2011 13:29:41 GMT Received: from abhmt109.oracle.com (abhmt109.oracle.com [141.146.116.61]) by acsmt357.oracle.com (8.12.11.20060308/8.12.11) with ESMTP id p8NDTZoh023138; Fri, 23 Sep 2011 08:29:35 -0500 Received: from oracle.com (/209.6.55.207) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Fri, 23 Sep 2011 06:29:35 -0700 Received: by oracle.com (Postfix, from userid 1000) id CCB2D1566; Fri, 23 Sep 2011 09:29:40 -0400 (EDT) Date: Fri, 23 Sep 2011 09:29:40 -0400 From: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com> To: Anthony Wright <anthony@overnetdata.com> Subject: Re: [Xen-devel] Getting mm.c errors from xl dmesg on certain hardware Message-ID: <20110923132940.GB19579@phenom.oracle.com> References: <4E7C5F8B.6050509@overnetdata.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <4E7C5F8B.6050509@overnetdata.com> User-Agent: Mutt/1.5.21 (2010-09-15) X-Source-IP: rtcsinet22.oracle.com [66.248.204.30] X-CT-RefId: str=0001.0A090209.4E7C89C8.015B,ss=1,re=0.000,fgs=0 Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com> X-BeenThere: xen-devel@lists.xensource.com X-Mailman-Version: 2.1.5 Precedence: list List-Id: Xen developer discussion <xen-devel.lists.xensource.com> List-Unsubscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe> List-Post: <mailto:xen-devel@lists.xensource.com> List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help> List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=subscribe> Sender: xen-devel-bounces@lists.xensource.com Errors-To: xen-devel-bounces@lists.xensource.com On Fri, Sep 23, 2011 at 11:29:31AM +0100, Anthony Wright wrote: > Konrad Rzeszutek Wilk wrote: > > >> (XEN) mm.c:907:d0 Error getting mfn 3a09c (pfn 55555555) from L1 entry 000000003a09c023 for l1e_owner=0, pg_owner=0 > >> (XEN) mm.c:907:d0 Error getting mfn 3a09d (pfn 55555555) from L1 entry 000000003a09d023 for l1e_owner=0, pg_owner=0 > >> (XEN) mm.c:907:d0 Error getting mfn 3a09e (pfn 55555555) from L1 entry 000000003a09e023 for l1e_owner=0, pg_owner=0 > >> (XEN) mm.c:907:d0 Error getting mfn 3a09f (pfn 55555555) from L1 entry 000000003a09f023 for l1e_owner=0, pg_owner=0 > >> (XEN) traps.c:2388:d0 Domain attempted WRMSR c0010004 from 0x0000ab23d6d622da to 0x000000000000abcd. > > Do they show up during bootup? As in do you see those _when_ you launch your guests? > > To figure out this particular issue you should try using 'console_to_ring' (so that > > dom0 output and Xen output are mingled togehter) and also post this under a new subject > > to not confuse this email thread. > The messages show up during the initial dom0 boot, before any domUs are > loaded. I've attached a second xl dmesg log which is similar to the > first, but the numbers in the error messages are different. > > The messages are hardware dependant as I don't get them on another > system with different hardware configuration but with identical software. > > The motherboard is a ASUS M2N68 AM PLUS, with 4GB of RAM. If I remove > one of the sticks of ram to take it down to 2GB, the mm.c errors are no > longer displayed, but I still get the traps.c message. > Um, you might want to include 'loglevel=9 console=hvc0 initcall_debug' on your Linux line so the output from Linux kernel gets intermingled with the Xen. > mapping kernel into physical memory > Xen: setup ISA identity maps > about to get started... > (XEN) mm.c:907:d0 Error getting mfn 3809c (pfn b602c) from L1 entry 000000003809c023 for l1e_owner=0, pg_owner=0 > (XEN) mm.c:907:d0 Error getting mfn 3809d (pfn b602d) from L1 entry 000000003809d023 for l1e_owner=0, pg_owner=0 > (XEN) mm.c:907:d0 Error getting mfn 3809e (pfn b602e) from L1 entry 000000003809e023 for l1e_owner=0, pg_owner=0 > (XEN) mm.c:907:d0 Error getting mfn 3809f (pfn b602f) from L1 entry 000000003809f023 for l1e_owner=0, pg_owner=0 > (XEN) traps.c:2388:d0 Domain attempted WRMSR c0010004 from 0x00009b27fe9726ca to 0x000000000000abcd. _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel From xen-devel-bounces@lists.xensource.com Fri Sep 23 06:33:02 2011 Return-path: <xen-devel-bounces@lists.xensource.com> Envelope-to: www-data@lists.xensource.com Delivery-date: Fri, 23 Sep 2011 06:33:02 -0700 Received: from localhost ([127.0.0.1] helo=lists.colo.xensource.com) by lists.xensource.com with esmtp (Exim 4.43) id 1R75sD-0007Rs-91; Fri, 23 Sep 2011 06:33:01 -0700 Received: from mail216.messagelabs.com ([85.158.143.99]) by lists.xensource.com with esmtp (Exim 4.43) id 1R75qv-00072F-MV for xen-devel@lists.xensource.com; Fri, 23 Sep 2011 06:31:42 -0700 X-Env-Sender: konrad@oracle.com X-Msg-Ref: server-6.tower-216.messagelabs.com!1316784697!18096329!1 X-Originating-IP: [148.87.113.117] X-StarScan-Version: 6.4.1; banners=-,-,- X-VirusChecked: Checked Received: (qmail 3895 invoked from network); 23 Sep 2011 13:31:38 -0000 Received: from rcsinet15.oracle.com (HELO rcsinet15.oracle.com) (148.87.113.117) by server-6.tower-216.messagelabs.com with DHE-RSA-AES256-SHA encrypted SMTP; 23 Sep 2011 13:31:38 -0000 Received: from acsinet22.oracle.com (acsinet22.oracle.com [141.146.126.238]) by rcsinet15.oracle.com (Switch-3.4.4/Switch-3.4.4) with ESMTP id p8NDVTgK011329 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Fri, 23 Sep 2011 13:31:34 GMT Received: from acsmt356.oracle.com (acsmt356.oracle.com [141.146.40.156]) by acsinet22.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id p8NDSEgJ007459 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 23 Sep 2011 13:28:14 GMT Received: from abhmt102.oracle.com (abhmt102.oracle.com [141.146.116.54]) by acsmt356.oracle.com (8.12.11.20060308/8.12.11) with ESMTP id p8NDS93w009204; Fri, 23 Sep 2011 08:28:09 -0500 Received: from oracle.com (/209.6.55.207) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Fri, 23 Sep 2011 06:28:08 -0700 Received: by oracle.com (Postfix, from userid 1000) id 247FB1566; Fri, 23 Sep 2011 09:28:14 -0400 (EDT) Date: Fri, 23 Sep 2011 09:28:14 -0400 From: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com> To: David Vrabel <david.vrabel@citrix.com> Subject: Re: [Xen-devel] xen: memory initialization/balloon fixes (#3) Message-ID: <20110923132813.GA19579@phenom.oracle.com> References: <1316089768-22461-1-git-send-email-david.vrabel@citrix.com> <63997331-e53b-48e5-bf7c-87141aae49d6@default> <4E7B2ADA.7000605@citrix.com> <df22e0b8-15d8-4cb1-a9d9-d3565aa5f9b7@default> <8af71cad-415d-42d4-8a2e-e4efd7e36fd4@default4E7BBC00.1050602@goop.org> <005ea591-cfb5-4ca0-9c9c-df2bbae88172@default> <4E7C6344.3000401@citrix.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <4E7C6344.3000401@citrix.com> User-Agent: Mutt/1.5.21 (2010-09-15) X-Source-IP: acsinet22.oracle.com [141.146.126.238] X-Auth-Type: Internal IP X-CT-RefId: str=0001.0A090209.4E7C8A36.0271:SCFMA922111,ss=1,re=-4.000,fgs=0 Cc: Dan Magenheimer <dan.magenheimer@oracle.com>, "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>, Jeremy Fitzhardinge <jeremy@goop.org>, "JBeulich@novell.com" <JBeulich@novell.com> X-BeenThere: xen-devel@lists.xensource.com X-Mailman-Version: 2.1.5 Precedence: list List-Id: Xen developer discussion <xen-devel.lists.xensource.com> List-Unsubscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe> List-Post: <mailto:xen-devel@lists.xensource.com> List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help> List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=subscribe> Sender: xen-devel-bounces@lists.xensource.com Errors-To: xen-devel-bounces@lists.xensource.com > > No, the first line of /proc/meminfo is precisely "totalram_pages". > > I think most of the increase in reserved memory compared to classic Xen > kernels is the change to using the generic SWIOTLB. This is up to 64 MiB. Which should be disabled by default on domU... Well, unless your guest has more than 4GB than it gets enabled. _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel From xen-devel-bounces@lists.xensource.com Fri Sep 23 06:34:28 2011 Return-path: <xen-devel-bounces@lists.xensource.com> Envelope-to: www-data@lists.xensource.com Delivery-date: Fri, 23 Sep 2011 06:34:28 -0700 Received: from localhost ([127.0.0.1] helo=lists.colo.xensource.com) by lists.xensource.com with esmtp (Exim 4.43) id 1R75tb-0007pf-8h; Fri, 23 Sep 2011 06:34:27 -0700 Received: from mail216.messagelabs.com ([85.158.143.99]) by lists.xensource.com with esmtp (Exim 4.43) id 1R75t0-0007d2-9m for xen-devel@lists.xensource.com; Fri, 23 Sep 2011 06:33:51 -0700 X-Env-Sender: konrad@oracle.com X-Msg-Ref: server-3.tower-216.messagelabs.com!1316784825!18336555!1 X-Originating-IP: [148.87.113.117] X-StarScan-Version: 6.4.1; banners=-,-,- X-VirusChecked: Checked Received: (qmail 31786 invoked from network); 23 Sep 2011 13:33:47 -0000 Received: from rcsinet15.oracle.com (HELO rcsinet15.oracle.com) (148.87.113.117) by server-3.tower-216.messagelabs.com with DHE-RSA-AES256-SHA encrypted SMTP; 23 Sep 2011 13:33:47 -0000 Received: from rtcsinet21.oracle.com (rtcsinet21.oracle.com [66.248.204.29]) by rcsinet15.oracle.com (Switch-3.4.4/Switch-3.4.4) with ESMTP id p8NDXhcp015596 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Fri, 23 Sep 2011 13:33:45 GMT Received: from acsmt358.oracle.com (acsmt358.oracle.com [141.146.40.158]) by rtcsinet21.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id p8NDXgLD013303 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 23 Sep 2011 13:33:42 GMT Received: from abhmt117.oracle.com (abhmt117.oracle.com [141.146.116.69]) by acsmt358.oracle.com (8.12.11.20060308/8.12.11) with ESMTP id p8NDXaRT011485; Fri, 23 Sep 2011 08:33:37 -0500 Received: from oracle.com (/209.6.55.207) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Fri, 23 Sep 2011 06:33:36 -0700 Received: by oracle.com (Postfix, from userid 1000) id B562E1566; Fri, 23 Sep 2011 09:33:41 -0400 (EDT) Date: Fri, 23 Sep 2011 09:33:41 -0400 From: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com> To: Anthony Wright <anthony@overnetdata.com> Subject: Re: [Xen-devel] Getting IOAPIC errors in xl dmesg on old hardware Message-ID: <20110923133341.GD19579@phenom.oracle.com> References: <4E7C60B1.3000901@overnetdata.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <4E7C60B1.3000901@overnetdata.com> User-Agent: Mutt/1.5.21 (2010-09-15) X-Source-IP: rtcsinet21.oracle.com [66.248.204.29] X-CT-RefId: str=0001.0A090202.4E7C8AB9.00D6,ss=1,re=0.000,fgs=0 Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com> X-BeenThere: xen-devel@lists.xensource.com X-Mailman-Version: 2.1.5 Precedence: list List-Id: Xen developer discussion <xen-devel.lists.xensource.com> List-Unsubscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe> List-Post: <mailto:xen-devel@lists.xensource.com> List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help> List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=subscribe> Sender: xen-devel-bounces@lists.xensource.com Errors-To: xen-devel-bounces@lists.xensource.com On Fri, Sep 23, 2011 at 11:34:25AM +0100, Anthony Wright wrote: > I am getting a series of IOAPIC errors in xl dmesg on a Dell OptiPlex > GX100 machine (bought in 2000). I also get an error from traps.c which > is very similar to the one in the 'Getting mm.c errors from xl dmesg on > certain hardware' thread. This happens during system startup with no > DomUs running. I have attached the xl dmesg log. > __ __ _ _ _ _ > \ \/ /___ _ __ | || | / | / | > \ // _ \ '_ \ | || |_ | | | | > / \ __/ | | | |__ _|| |_| | > /_/\_\___|_| |_| |_|(_)_(_)_| > > (XEN) Xen version 4.1.1 (@[unknown]) (gcc version 4.4.3 (GCC) ) Wed Sep 21 08:25:36 GMT 2011 > (XEN) Latest ChangeSet: unavailable > (XEN) Bootloader: GNU GRUB 0.97 > (XEN) Command line: > (XEN) Video information: > (XEN) VGA is text mode 80x25, font 8x16 > (XEN) VBE/DDC methods: V2; EDID transfer time: 1 seconds > (XEN) Disc information: > (XEN) Found 0 MBR signatures > (XEN) Found 0 EDD information structures > (XEN) Xen-e820 RAM map: > (XEN) 0000000000000000 - 00000000000a0000 (usable) > (XEN) 00000000000f0000 - 0000000000100000 (reserved) > (XEN) 0000000000100000 - 000000001feae000 (usable) > (XEN) 000000001feae000 - 0000000020000000 (reserved) > (XEN) 00000000ffb00000 - 0000000100000000 (reserved) > (XEN) System RAM: 510MB (522552kB) Is that right? 512MB? _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel From xen-devel-bounces@lists.xensource.com Fri Sep 23 06:39:54 2011 Return-path: <xen-devel-bounces@lists.xensource.com> Envelope-to: www-data@lists.xensource.com Delivery-date: Fri, 23 Sep 2011 06:39:54 -0700 Received: from localhost ([127.0.0.1] helo=lists.colo.xensource.com) by lists.xensource.com with esmtp (Exim 4.43) id 1R75yr-0008OL-Gs; Fri, 23 Sep 2011 06:39:53 -0700 Received: from mail216.messagelabs.com ([85.158.143.99]) by lists.xensource.com with esmtp (Exim 4.43) id 1R75yG-0008Bz-Rk for xen-devel@lists.xensource.com; Fri, 23 Sep 2011 06:39:19 -0700 X-Env-Sender: konrad@oracle.com X-Msg-Ref: server-8.tower-216.messagelabs.com!1316785134!17759401!1 X-Originating-IP: [148.87.113.117] X-StarScan-Version: 6.4.1; banners=-,-,- X-VirusChecked: Checked Received: (qmail 18549 invoked from network); 23 Sep 2011 13:38:55 -0000 Received: from rcsinet15.oracle.com (HELO rcsinet15.oracle.com) (148.87.113.117) by server-8.tower-216.messagelabs.com with DHE-RSA-AES256-SHA encrypted SMTP; 23 Sep 2011 13:38:55 -0000 Received: from rtcsinet21.oracle.com (rtcsinet21.oracle.com [66.248.204.29]) by rcsinet15.oracle.com (Switch-3.4.4/Switch-3.4.4) with ESMTP id p8NDckWN026532 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Fri, 23 Sep 2011 13:38:49 GMT Received: from acsmt356.oracle.com (acsmt356.oracle.com [141.146.40.156]) by rtcsinet21.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id p8NDcjJ3022486 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 23 Sep 2011 13:38:46 GMT Received: from abhmt108.oracle.com (abhmt108.oracle.com [141.146.116.60]) by acsmt356.oracle.com (8.12.11.20060308/8.12.11) with ESMTP id p8NDccgn017431; Fri, 23 Sep 2011 08:38:40 -0500 Received: from oracle.com (/209.6.55.207) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Fri, 23 Sep 2011 06:38:38 -0700 Received: by oracle.com (Postfix, from userid 1000) id 72B781566; Fri, 23 Sep 2011 09:38:43 -0400 (EDT) Date: Fri, 23 Sep 2011 09:38:43 -0400 From: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com> To: Jeremy Fitzhardinge <jeremy@goop.org>, xen-devel@lists.xensource.com Message-ID: <20110923133843.GA17381@phenom.oracle.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.5.21 (2010-09-15) X-Source-IP: rtcsinet21.oracle.com [66.248.204.29] X-CT-RefId: str=0001.0A090206.4E7C8BEC.009B,ss=1,re=0.000,fgs=0 Cc: Subject: [Xen-devel] platform.h in both our trees. X-BeenThere: xen-devel@lists.xensource.com X-Mailman-Version: 2.1.5 Precedence: list List-Id: Xen developer discussion <xen-devel.lists.xensource.com> List-Unsubscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe> List-Post: <mailto:xen-devel@lists.xensource.com> List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help> List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=subscribe> Sender: xen-devel-bounces@lists.xensource.com Errors-To: xen-devel-bounces@lists.xensource.com Hey Jeremy, In one of my trees (devel/acpi-s3.v3) I went through and ran cleanpatch against all of the patches and fixed the platform.h space issues. Also I removed most of the typedefs. Anyhow I was wondering if you could re-base some of your trees to use that? git commit 3e17f59456fbf5a97ae477fda61018be0947dd7e _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel From xen-devel-bounces@lists.xensource.com Fri Sep 23 06:41:10 2011 Return-path: <xen-devel-bounces@lists.xensource.com> Envelope-to: www-data@lists.xensource.com Delivery-date: Fri, 23 Sep 2011 06:41:10 -0700 Received: from localhost ([127.0.0.1] helo=lists.colo.xensource.com) by lists.xensource.com with esmtp (Exim 4.43) id 1R7605-0000LI-LX; Fri, 23 Sep 2011 06:41:09 -0700 Received: from mail216.messagelabs.com ([85.158.143.99]) by lists.xensource.com with smtp (Exim 4.43) id 1R75yT-0008EO-5q for xen-devel@lists.xensource.com; Fri, 23 Sep 2011 06:39:30 -0700 X-Env-Sender: anthony@overnetdata.com X-Msg-Ref: server-10.tower-216.messagelabs.com!1316785165!11282218!1 X-Originating-IP: [81.137.131.225] X-StarScan-Version: 6.4.1; banners=-,-,- X-VirusChecked: Checked Received: (qmail 5584 invoked from network); 23 Sep 2011 13:39:25 -0000 Received: from host81-137-131-225.in-addr.btopenworld.com (HELO zimbra.overnetdata.com) (81.137.131.225) by server-10.tower-216.messagelabs.com with SMTP; 23 Sep 2011 13:39:25 -0000 Received: from localhost (localhost.localdomain [127.0.0.1]) by zimbra.overnetdata.com (Postfix) with ESMTP id 6503816187F; Fri, 23 Sep 2011 14:39:25 +0100 (BST) X-Virus-Scanned: amavisd-new at overnetdata.com Received: from zimbra.overnetdata.com ([127.0.0.1]) by localhost (zimbra.overnetdata.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jjx8D3YNnRgf; Fri, 23 Sep 2011 14:39:14 +0100 (BST) Received: from [192.168.1.60] (unknown [192.168.1.60]) by zimbra.overnetdata.com (Postfix) with ESMTPSA id 5058D1616D8; Fri, 23 Sep 2011 14:39:14 +0100 (BST) Message-ID: <4E7C8C00.2050806@overnetdata.com> Date: Fri, 23 Sep 2011 14:39:12 +0100 From: Anthony Wright <anthony@overnetdata.com> User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:6.0.2) Gecko/20110902 Thunderbird/6.0.2 MIME-Version: 1.0 To: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com> Subject: Re: [Xen-devel] Getting IOAPIC errors in xl dmesg on old hardware References: <4E7C60B1.3000901@overnetdata.com> <20110923133341.GD19579@phenom.oracle.com> In-Reply-To: <20110923133341.GD19579@phenom.oracle.com> X-Enigmail-Version: 1.3.2 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com> X-BeenThere: xen-devel@lists.xensource.com X-Mailman-Version: 2.1.5 Precedence: list List-Id: Xen developer discussion <xen-devel.lists.xensource.com> List-Unsubscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe> List-Post: <mailto:xen-devel@lists.xensource.com> List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help> List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=subscribe> Sender: xen-devel-bounces@lists.xensource.com Errors-To: xen-devel-bounces@lists.xensource.com On 23/09/2011 14:33, Konrad Rzeszutek Wilk wrote: > On Fri, Sep 23, 2011 at 11:34:25AM +0100, Anthony Wright wrote: >> I am getting a series of IOAPIC errors in xl dmesg on a Dell OptiPlex >> GX100 machine (bought in 2000). I also get an error from traps.c which >> is very similar to the one in the 'Getting mm.c errors from xl dmesg on >> certain hardware' thread. This happens during system startup with no >> DomUs running. I have attached the xl dmesg log. >> __ __ _ _ _ _ >> \ \/ /___ _ __ | || | / | / | >> \ // _ \ '_ \ | || |_ | | | | >> / \ __/ | | | |__ _|| |_| | >> /_/\_\___|_| |_| |_|(_)_(_)_| >> >> (XEN) Xen version 4.1.1 (@[unknown]) (gcc version 4.4.3 (GCC) ) Wed Sep 21 08:25:36 GMT 2011 >> (XEN) Latest ChangeSet: unavailable >> (XEN) Bootloader: GNU GRUB 0.97 >> (XEN) Command line: >> (XEN) Video information: >> (XEN) VGA is text mode 80x25, font 8x16 >> (XEN) VBE/DDC methods: V2; EDID transfer time: 1 seconds >> (XEN) Disc information: >> (XEN) Found 0 MBR signatures >> (XEN) Found 0 EDD information structures >> (XEN) Xen-e820 RAM map: >> (XEN) 0000000000000000 - 00000000000a0000 (usable) >> (XEN) 00000000000f0000 - 0000000000100000 (reserved) >> (XEN) 0000000000100000 - 000000001feae000 (usable) >> (XEN) 000000001feae000 - 0000000020000000 (reserved) >> (XEN) 00000000ffb00000 - 0000000100000000 (reserved) >> (XEN) System RAM: 510MB (522552kB) > Is that right? 512MB? Yup 512MB 3.4.1 with 2.6.18 works fine on it. 4.4.1 with 3.0.4 also seems to work fine, though it does seem to use an awful lot of ram (something I'm going to have a closer look at shortly). It's just that I get these error messages in 'xl dmesg', and wondered whether I can safely ignore them, or whether they're indicative of a more serious problem. _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel From xen-devel-bounces@lists.xensource.com Fri Sep 23 06:50:23 2011 Return-path: <xen-devel-bounces@lists.xensource.com> Envelope-to: www-data@lists.xensource.com Delivery-date: Fri, 23 Sep 2011 06:50:23 -0700 Received: from localhost ([127.0.0.1] helo=lists.colo.xensource.com) by lists.xensource.com with esmtp (Exim 4.43) id 1R7691-00011q-Fi; Fri, 23 Sep 2011 06:50:23 -0700 Received: from mail27.messagelabs.com ([193.109.254.147]) by lists.xensource.com with esmtp (Exim 4.43) id 1R768D-0000ot-DV for xen-devel@lists.xensource.com; Fri, 23 Sep 2011 06:49:33 -0700 X-Env-Sender: konrad@oracle.com X-Msg-Ref: server-14.tower-27.messagelabs.com!1316785754!37360416!1 X-Originating-IP: [141.146.126.227] X-StarScan-Version: 6.4.1; banners=-,-,- X-VirusChecked: Checked Received: (qmail 31581 invoked from network); 23 Sep 2011 13:49:15 -0000 Received: from acsinet15.oracle.com (HELO acsinet15.oracle.com) (141.146.126.227) by server-14.tower-27.messagelabs.com with DHE-RSA-AES256-SHA encrypted SMTP; 23 Sep 2011 13:49:15 -0000 Received: from rtcsinet22.oracle.com (rtcsinet22.oracle.com [66.248.204.30]) by acsinet15.oracle.com (Switch-3.4.4/Switch-3.4.4) with ESMTP id p8NDnAu4029266 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Fri, 23 Sep 2011 13:49:28 GMT Received: from acsmt356.oracle.com (acsmt356.oracle.com [141.146.40.156]) by rtcsinet22.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id p8NDW0IR006736 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 23 Sep 2011 13:32:01 GMT Received: from abhmt109.oracle.com (abhmt109.oracle.com [141.146.116.61]) by acsmt356.oracle.com (8.12.11.20060308/8.12.11) with ESMTP id p8NDVtf3012290; Fri, 23 Sep 2011 08:31:55 -0500 Received: from oracle.com (/209.6.55.207) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Fri, 23 Sep 2011 06:31:55 -0700 Received: by oracle.com (Postfix, from userid 1000) id 011ED1566; Fri, 23 Sep 2011 09:32:00 -0400 (EDT) Date: Fri, 23 Sep 2011 09:32:00 -0400 From: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com> To: Anthony Wright <anthony@overnetdata.com> Subject: Re: [Xen-devel] dmidecode doesn't work under xen 4.1.1 on certain hardware Message-ID: <20110923133200.GC19579@phenom.oracle.com> References: <4E7C6BDC.8070005@overnetdata.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <4E7C6BDC.8070005@overnetdata.com> User-Agent: Mutt/1.5.21 (2010-09-15) X-Source-IP: rtcsinet22.oracle.com [66.248.204.30] X-CT-RefId: str=0001.0A020206.4E7C8E68.01DD,ss=1,re=0.000,fgs=0 Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com> X-BeenThere: xen-devel@lists.xensource.com X-Mailman-Version: 2.1.5 Precedence: list List-Id: Xen developer discussion <xen-devel.lists.xensource.com> List-Unsubscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe> List-Post: <mailto:xen-devel@lists.xensource.com> List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help> List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=subscribe> Sender: xen-devel-bounces@lists.xensource.com Errors-To: xen-devel-bounces@lists.xensource.com On Fri, Sep 23, 2011 at 12:22:04PM +0100, Anthony Wright wrote: > I have a xen 4.1.1 with a 3.0.4 linux kernel running on a Supermicro > Supermicro X8DTL-iF motherboard with 16GB of RAM. > > If I run the 3.0.4 kernel on the bare metal dmidecode works fine. If I Can you attach the beginning of the kernel bootup log? It should have some entry about 1-1 mappings. Make sure to run Linux with "debug loglevel=8" _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel From xen-devel-bounces@lists.xensource.com Fri Sep 23 06:59:21 2011 Return-path: <xen-devel-bounces@lists.xensource.com> Envelope-to: www-data@lists.xensource.com Delivery-date: Fri, 23 Sep 2011 06:59:21 -0700 Received: from localhost ([127.0.0.1] helo=lists.colo.xensource.com) by lists.xensource.com with esmtp (Exim 4.43) id 1R76Hf-0002D9-O0; Fri, 23 Sep 2011 06:59:19 -0700 Received: from mail182.messagelabs.com ([85.158.139.83]) by lists.xensource.com with esmtp (Exim 4.43) id 1R76Dp-0001Ib-50 for xen-devel@lists.xensource.com; Fri, 23 Sep 2011 06:55:22 -0700 X-Env-Sender: Stefano.Stabellini@eu.citrix.com X-Msg-Ref: server-3.tower-182.messagelabs.com!1316786117!16698251!1 X-Originating-IP: [62.200.22.115] X-StarScan-Version: 6.4.1; banners=-,-,- X-VirusChecked: Checked Received: (qmail 9583 invoked from network); 23 Sep 2011 13:55:18 -0000 Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115) by server-3.tower-182.messagelabs.com with RC4-SHA encrypted SMTP; 23 Sep 2011 13:55:18 -0000 X-IronPort-AV: E=Sophos;i="4.68,430,1312156800"; d="scan'208";a="8031315" Received: from lonpmailmx01.citrite.net ([10.30.203.162]) by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5; 23 Sep 2011 13:55:14 +0000 Received: from kaball.uk.xensource.com (10.80.2.59) by LONPMAILMX01.citrite.net (10.30.203.162) with Microsoft SMTP Server id 8.3.137.0; Fri, 23 Sep 2011 14:55:15 +0100 Date: Fri, 23 Sep 2011 14:55:09 +0100 From: Stefano Stabellini <stefano.stabellini@eu.citrix.com> X-X-Sender: sstabellini@kaball-desktop To: "konrad.wilk@oracle.com" <konrad.wilk@oracle.com> In-Reply-To: <20110921145853.GA541@phenom.oracle.com> Message-ID: <alpine.DEB.2.00.1109231412220.8700@kaball-desktop> References: <alpine.DEB.2.00.1109081944150.12963@kaball-desktop> <20110921145853.GA541@phenom.oracle.com> User-Agent: Alpine 2.00 (DEB 1167 2008-08-23) MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Cc: Jeremy Fitzhardinge <jeremy@goop.org>, "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>, "linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>, Stefano Stabellini <Stefano.Stabellini@eu.citrix.com> Subject: [Xen-devel] Re: [PATCH v4 2/2] xen: modify kernel mappings corresponding to granted pages X-BeenThere: xen-devel@lists.xensource.com X-Mailman-Version: 2.1.5 Precedence: list List-Id: Xen developer discussion <xen-devel.lists.xensource.com> List-Unsubscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe> List-Post: <mailto:xen-devel@lists.xensource.com> List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help> List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=subscribe> Sender: xen-devel-bounces@lists.xensource.com Errors-To: xen-devel-bounces@lists.xensource.com On Wed, 21 Sep 2011, konrad.wilk@oracle.com wrote: > On Thu, Sep 08, 2011 at 07:45:29PM +0100, Stefano Stabellini wrote: > > If we want to use granted pages for AIO, changing the mappings of a user > > vma and the corresponding p2m is not enough, we also need to update the > > kernel mappings accordingly. > > Please add:" > > But only for pages that are created for user usages through /dev/xen/gntdev. > As in, pages that have been in use by the kernel and use the P2M will not need > this special mapping." > > Just so that it is quite clear when in a year somebody wants to debug > this code and wants to figure out if this patch causes issues. > > .. more comments below. OK, even though in the future it might happen that the kernel starts accessing pages through the 1:1 even for internal usage. Right now the only case in which this happens is on the user AIO code path but it doesn't mean that the problem is always going to be limited to pages used for user AIO. > > In order to avoid the complexity of dealing with highmem, we allocated > > the pages lowmem. > > We issue a HYPERVISOR_grant_table_op right away in > > m2p_add_override and we remove the mappings using another > > HYPERVISOR_grant_table_op in m2p_remove_override. > > Considering that m2p_add_override and m2p_remove_override are called > > once per page we use multicalls and hypercall batching. > > > > Use the kmap_op pointer directly as argument to do the mapping as it is > > guaranteed to be present up until the unmapping is done. > > Before issuing any unmapping multicalls, we need to make sure that the > > mapping has already being done, because we need the kmap->handle to be > > set correctly. > > > > Signed-off-by: Stefano Stabellini <stefano.stabellini@eu.citrix.com> > > --- > > arch/x86/include/asm/xen/page.h | 5 ++- > > arch/x86/xen/p2m.c | 68 +++++++++++++++++++++++++++++------ > > drivers/block/xen-blkback/blkback.c | 2 +- > > drivers/xen/gntdev.c | 27 +++++++++++++- > > drivers/xen/grant-table.c | 6 ++-- > > include/xen/grant_table.h | 1 + > > 6 files changed, 92 insertions(+), 17 deletions(-) > > > > diff --git a/arch/x86/include/asm/xen/page.h b/arch/x86/include/asm/xen/page.h > > index 7ff4669..0ce1884 100644 > > --- a/arch/x86/include/asm/xen/page.h > > +++ b/arch/x86/include/asm/xen/page.h > > @@ -12,6 +12,7 @@ > > #include <asm/pgtable.h> > > > > #include <xen/interface/xen.h> > > +#include <xen/grant_table.h> > > #include <xen/features.h> > > > > /* Xen machine address */ > > @@ -31,8 +32,10 @@ typedef struct xpaddr { > > #define INVALID_P2M_ENTRY (~0UL) > > #define FOREIGN_FRAME_BIT (1UL<<(BITS_PER_LONG-1)) > > #define IDENTITY_FRAME_BIT (1UL<<(BITS_PER_LONG-2)) > > +#define GRANT_FRAME_BIT (1UL<<(BITS_PER_LONG-3)) > > #define FOREIGN_FRAME(m) ((m) | FOREIGN_FRAME_BIT) > > #define IDENTITY_FRAME(m) ((m) | IDENTITY_FRAME_BIT) > > +#define GRANT_FRAME(m) ((m) | GRANT_FRAME_BIT) > > > > /* Maximum amount of memory we can handle in a domain in pages */ > > #define MAX_DOMAIN_PAGES \ > > @@ -48,7 +51,7 @@ extern unsigned long set_phys_range_identity(unsigned long pfn_s, > > unsigned long pfn_e); > > > > extern int m2p_add_override(unsigned long mfn, struct page *page, > > - bool clear_pte); > > + struct gnttab_map_grant_ref *kmap_op); > > extern int m2p_remove_override(struct page *page, bool clear_pte); > > extern struct page *m2p_find_override(unsigned long mfn); > > extern unsigned long m2p_find_override_pfn(unsigned long mfn, unsigned long pfn); > > diff --git a/arch/x86/xen/p2m.c b/arch/x86/xen/p2m.c > > index 58efeb9..23f8465 100644 > > --- a/arch/x86/xen/p2m.c > > +++ b/arch/x86/xen/p2m.c > > @@ -161,7 +161,9 @@ > > #include <asm/xen/page.h> > > #include <asm/xen/hypercall.h> > > #include <asm/xen/hypervisor.h> > > +#include <xen/grant_table.h> > > > > +#include "multicalls.h" > > #include "xen-ops.h" > > > > static void __init m2p_override_init(void); > > @@ -676,7 +678,8 @@ static unsigned long mfn_hash(unsigned long mfn) > > } > > > > /* Add an MFN override for a particular page */ > > -int m2p_add_override(unsigned long mfn, struct page *page, bool clear_pte) > > +int m2p_add_override(unsigned long mfn, struct page *page, > > + struct gnttab_map_grant_ref *kmap_op) > > { > > unsigned long flags; > > unsigned long pfn; > > @@ -699,9 +702,20 @@ int m2p_add_override(unsigned long mfn, struct page *page, bool clear_pte) > > if (unlikely(!set_phys_to_machine(pfn, FOREIGN_FRAME(mfn)))) > > return -ENOMEM; > > > > - if (clear_pte && !PageHighMem(page)) > > - /* Just zap old mapping for now */ > > - pte_clear(&init_mm, address, ptep); > > + if (kmap_op != NULL) { > > + if (!PageHighMem(page)) { > > + struct multicall_space mcs = xen_mc_entry(sizeof(*kmap_op)); > > + > > + MULTI_grant_table_op(mcs.mc, > > + GNTTABOP_map_grant_ref, kmap_op, 1); > > + > > + xen_mc_issue(PARAVIRT_LAZY_MMU); > > + } > > + page->private |= GRANT_FRAME_BIT; > > + /* let's use dev_bus_addr to record the old mfn instead */ > > + kmap_op->dev_bus_addr = page->index; > > + page->index = (unsigned long) kmap_op; > > + } > > spin_lock_irqsave(&m2p_override_lock, flags); > > list_add(&page->lru, &m2p_overrides[mfn_hash(mfn)]); > > spin_unlock_irqrestore(&m2p_override_lock, flags); > > @@ -735,13 +749,45 @@ int m2p_remove_override(struct page *page, bool clear_pte) > > spin_lock_irqsave(&m2p_override_lock, flags); > > list_del(&page->lru); > > spin_unlock_irqrestore(&m2p_override_lock, flags); > > - set_phys_to_machine(pfn, page->index); > > > > - if (clear_pte && !PageHighMem(page)) > > - set_pte_at(&init_mm, address, ptep, > > - pfn_pte(pfn, PAGE_KERNEL)); > > - /* No tlb flush necessary because the caller already > > - * left the pte unmapped. */ > > + if (clear_pte) { > > + struct gnttab_map_grant_ref *map_op = > > + (struct gnttab_map_grant_ref *) page->index; > > + set_phys_to_machine(pfn, map_op->dev_bus_addr); > > + if (!PageHighMem(page)) { > > + struct multicall_space mcs; > > + struct gnttab_unmap_grant_ref *unmap_op; > > + > > + /* > > + * Has the grant_op mapping multicall being issued? If not, > > + * make sure it is called now. > > + */ > > + if (map_op->handle == -1) > > + xen_mc_flush(); > > How do you trigger this case? The mapping looks to be set by "gntdev_add_map" > which is happening right after in gntdev_alloc_map.. > > If it had failed from the gntdev_alloc_map to gntdev_add_map this page would > have never been used in the m2p as we would not have provided the proper > op.index value to the user. Which mean that the user could not have mmaped > and gotten to this code. The problem is that all the grant table mappings are done through multicalls now, and we are not really sure when the multicall is going to be actually issued. It might be that we queued all the m2p grant table hypercalls in a multicall, then m2p_remove_override gets called before the multicall has actually been issued. In this case handle is going to -1 because it hasn't been modified yet. This is the case we are trying to handle here. > > + if (map_op->handle == -1) { > > The other one I can understand, but this one I am baffled by. How > would the xen_mc_flush trigger the handle to be set to -1? > > Is the hypercall writting that value in the op.handle after it has completed? Yes. The hypercall might return -1 in the handle in case of errors. > Also, we might want to document somwhere -1 now that I think of it. > It does not look like that is a value that is defined anywhere. It is already documented in the hypercall interface in include/xen/interface/grant_table.h > > + printk(KERN_WARNING "m2p_remove_override: pfn %lx mfn %lx, " > > + "failed to modify kernel mappings", pfn, mfn); > > + return -1; > > + } > > + > > + mcs = xen_mc_entry(sizeof(struct gnttab_unmap_grant_ref)); > > + unmap_op = mcs.args; > > + unmap_op->host_addr = map_op->host_addr; > > + unmap_op->handle = map_op->handle; > > + unmap_op->dev_bus_addr = 0; > > + > > + MULTI_grant_table_op(mcs.mc, > > + GNTTABOP_unmap_grant_ref, unmap_op, 1); > > + > > + xen_mc_issue(PARAVIRT_LAZY_MMU); > > + > > + set_pte_at(&init_mm, address, ptep, > > + pfn_pte(pfn, PAGE_KERNEL)); > > + __flush_tlb_single(address); > > + map_op->host_addr = 0; > > I am not sure that is neccesseray? When we are done, err, when we end > up calling here that means the region has been unmapped or > IOCTL_GNTDEV_UNMAP_GRANT_REF called right? Yes. > And when we do end up here, then the a whole bunch of those pages > get free-ed? Don't they? Right. However considering that map_op is a parameter passed by the caller, it makes sense to set it back to a consistent state, no matter if the caller is just going to free map_op right after. > > + } > > + } else > > + set_phys_to_machine(pfn, page->index); > > > > return 0; > > } > > @@ -758,7 +804,7 @@ struct page *m2p_find_override(unsigned long mfn) > > spin_lock_irqsave(&m2p_override_lock, flags); > > > > list_for_each_entry(p, bucket, lru) { > > - if (p->private == mfn) { > > + if ((p->private & (~GRANT_FRAME_BIT)) == mfn) { > > ret = p; > > break; > > } > > diff --git a/drivers/block/xen-blkback/blkback.c b/drivers/block/xen-blkback/blkback.c > > index 2330a9a..1540792 100644 > > --- a/drivers/block/xen-blkback/blkback.c > > +++ b/drivers/block/xen-blkback/blkback.c > > @@ -396,7 +396,7 @@ static int xen_blkbk_map(struct blkif_request *req, > > continue; > > > > ret = m2p_add_override(PFN_DOWN(map[i].dev_bus_addr), > > - blkbk->pending_page(pending_req, i), false); > > + blkbk->pending_page(pending_req, i), NULL); > > if (ret) { > > pr_alert(DRV_PFX "Failed to install M2P override for %lx (ret: %d)\n", > > (unsigned long)map[i].dev_bus_addr, ret); > > diff --git a/drivers/xen/gntdev.c b/drivers/xen/gntdev.c > > index 7b9b1d1..bfe1271 100644 > > --- a/drivers/xen/gntdev.c > > +++ b/drivers/xen/gntdev.c > > @@ -83,6 +83,7 @@ struct grant_map { > > struct ioctl_gntdev_grant_ref *grants; > > struct gnttab_map_grant_ref *map_ops; > > struct gnttab_unmap_grant_ref *unmap_ops; > > + struct gnttab_map_grant_ref *kmap_ops; > > struct page **pages; > > }; > > > > @@ -116,10 +117,12 @@ static struct grant_map *gntdev_alloc_map(struct gntdev_priv *priv, int count) > > add->grants = kzalloc(sizeof(add->grants[0]) * count, GFP_KERNEL); > > add->map_ops = kzalloc(sizeof(add->map_ops[0]) * count, GFP_KERNEL); > > add->unmap_ops = kzalloc(sizeof(add->unmap_ops[0]) * count, GFP_KERNEL); > > + add->kmap_ops = kzalloc(sizeof(add->kmap_ops[0]) * count, GFP_KERNEL); > > add->pages = kzalloc(sizeof(add->pages[0]) * count, GFP_KERNEL); > > if (NULL == add->grants || > > NULL == add->map_ops || > > NULL == add->unmap_ops || > > + NULL == add->kmap_ops || > > NULL == add->pages) > > goto err; > > > > @@ -129,6 +132,7 @@ static struct grant_map *gntdev_alloc_map(struct gntdev_priv *priv, int count) > > for (i = 0; i < count; i++) { > > add->map_ops[i].handle = -1; > > add->unmap_ops[i].handle = -1; > > + add->kmap_ops[i].handle = -1; > > } > > > > add->index = 0; > > @@ -142,6 +146,7 @@ err: > > kfree(add->grants); > > kfree(add->map_ops); > > kfree(add->unmap_ops); > > + kfree(add->kmap_ops); > > kfree(add); > > return NULL; > > } > > @@ -243,10 +248,30 @@ static int map_grant_pages(struct grant_map *map) > > gnttab_set_unmap_op(&map->unmap_ops[i], addr, > > map->flags, -1 /* handle */); > > } > > + } else { > > + for (i = 0; i < map->count; i++) { > > + unsigned level; > > + unsigned long address = (unsigned long) > > + pfn_to_kaddr(page_to_pfn(map->pages[i])); > > + pte_t *ptep; > > + u64 pte_maddr = 0; > > + if (!PageHighMem(map->pages[i])) { > > + ptep = lookup_address(address, &level); > > + pte_maddr = > > + arbitrary_virt_to_machine(ptep).maddr; > > + } > > And it looks like having kmap->ops.host_addr = 0 is valid > so that is good on the chance it is high map... but that begs > the question whether we should the hypercall at all? > As in, can we do anything with the grants if there is no PTE > or MFN associated with it - just the handle? Does Xen do something > special - like a relaxed "oh ok, we can handle that later on" ? map->pages[i] cannot be highmap pages anymore, thanks to the previous patch that changes alloc_xenballooned_pages. We could even remove the if (!PageHighMem(map->pages[i])) at this point... > > + gnttab_set_map_op(&map->kmap_ops[i], pte_maddr, > > + map->flags | > > + GNTMAP_host_map | > > + GNTMAP_contains_pte, > > + map->grants[i].ref, > > + map->grants[i].domid); > > + } > > So, on startup.. (before this function is called) the > find_grant_ptes is called which pretty much does the exact thing for > each virtual address. Except its flags are GNTMAP_application_map > instead of GNTMAP_host_map. > > It even uses the same type structure.. It fills out map_ops[i] one. > > Can we use that instead of adding a new structure? Do you mean moving this code inside find_grant_ptes? I don't think that can be done because find_grant_ptes is called on a range of virtual addresses while this is called on an array of struct pages. It is true that the current implementation of alloc_xenballooned_pages is going to return a consecutive set of pages but it might not always be the case. _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel From xen-devel-bounces@lists.xensource.com Fri Sep 23 07:03:27 2011 Return-path: <xen-devel-bounces@lists.xensource.com> Envelope-to: www-data@lists.xensource.com Delivery-date: Fri, 23 Sep 2011 07:03:27 -0700 Received: from localhost ([127.0.0.1] helo=lists.colo.xensource.com) by lists.xensource.com with esmtp (Exim 4.43) id 1R76Le-0002d0-6O; Fri, 23 Sep 2011 07:03:26 -0700 Received: from mail27.messagelabs.com ([193.109.254.147]) by lists.xensource.com with esmtp (Exim 4.43) id 1R76Ib-0002Kt-5I for xen-devel@lists.xensource.com; Fri, 23 Sep 2011 07:00:25 -0700 X-Env-Sender: javier.manzano@edu.uah.es X-Msg-Ref: server-14.tower-27.messagelabs.com!1316786398!37362202!1 X-Originating-IP: [216.139.236.26] X-StarScan-Version: 6.4.1; banners=-,-,- X-VirusChecked: Checked Received: (qmail 32179 invoked from network); 23 Sep 2011 13:59:59 -0000 Received: from sam.nabble.com (HELO sam.nabble.com) (216.139.236.26) by server-14.tower-27.messagelabs.com with AES256-SHA encrypted SMTP; 23 Sep 2011 13:59:59 -0000 Received: from [192.168.236.26] (helo=sam.nabble.com) by sam.nabble.com with esmtp (Exim 4.72) (envelope-from <javier.manzano@edu.uah.es>) id 1R76IW-0006dF-E3 for xen-devel@lists.xensource.com; Fri, 23 Sep 2011 07:00:12 -0700 Date: Fri, 23 Sep 2011 07:00:12 -0700 (PDT) From: JavMV <javier.manzano@edu.uah.es> To: xen-devel@lists.xensource.com Message-ID: <1316786412428-4833637.post@n5.nabble.com> In-Reply-To: <1316777654598-4833174.post@n5.nabble.com> References: <1316614084705-4826479.post@n5.nabble.com> <1316615526442-4826582.post@n5.nabble.com> <1316616001843-4826614.post@n5.nabble.com> <1316616472579-4826635.post@n5.nabble.com> <1316616757871-4826655.post@n5.nabble.com> <1316618006.67296.YahooMailNeo@web29818.mail.ird.yahoo.com> <1316693722029-4829929.post@n5.nabble.com> <20110922182705.GE12984@reaktio.net> <1316728444821-4831624.post@n5.nabble.com> <1316777654598-4833174.post@n5.nabble.com> Subject: Re: Re : Re : Re : Re : [Xen-devel] Re: Patches for VGA-Passthrough XEN 4.2 unstable MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-BeenThere: xen-devel@lists.xensource.com X-Mailman-Version: 2.1.5 Precedence: list List-Id: Xen developer discussion <xen-devel.lists.xensource.com> List-Unsubscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe> List-Post: <mailto:xen-devel@lists.xensource.com> List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help> List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=subscribe> Sender: xen-devel-bounces@lists.xensource.com Errors-To: xen-devel-bounces@lists.xensource.com Hi again, ... do you wanna hear a funny story? Well here it is, The Vt-d features doesn't work if I use the changeset 23799 (David's patches are for this one), but Vt-d features works if I use changeset 23350 but in this changeset there is a bug related with VNC viewer which shows a white screen all time instead of guest screen ( http://bugzilla.xensource.com/bugzilla/show_bug.cgi?id=1766 http://bugzilla.xensource.com/bugzilla/show_bug.cgi?id=1766 ). So I must use a changeset lower than 23799 (*because this have some changes that provokes VT-d (iommu) fails on my computer*) but I need a changeset that have already fixed the VNC bug (greater than 23350) in order to have access to the winxp guest, and then I will need luck to patch them with one of the adaptations (mine or David's) otherwise I will have to adapt them again. So now, do you know where I can find a list with all the changesets and their respective changes applied? Best regards Javier ----- JavMV -- View this message in context: http://xen.1045712.n5.nabble.com/Patches-for-VGA-Passthrough-XEN-4-2-unstable-tp4406265p4833637.html Sent from the Xen - Dev mailing list archive at Nabble.com. _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel From xen-devel-bounces@lists.xensource.com Fri Sep 23 07:35:56 2011 Return-path: <xen-devel-bounces@lists.xensource.com> Envelope-to: www-data@lists.xensource.com Delivery-date: Fri, 23 Sep 2011 07:35:56 -0700 Received: from localhost ([127.0.0.1] helo=lists.colo.xensource.com) by lists.xensource.com with esmtp (Exim 4.43) id 1R76r6-0003lC-Io; Fri, 23 Sep 2011 07:35:56 -0700 Received: from mail21.messagelabs.com ([85.158.143.35]) by lists.xensource.com with esmtp (Exim 4.43) id 1R76qE-0003YE-RY for xen-devel@lists.xensource.com; Fri, 23 Sep 2011 07:35:03 -0700 X-Env-Sender: olaf@aepfle.de X-Msg-Ref: server-10.tower-21.messagelabs.com!1316788484!55248735!1 X-Originating-IP: [81.169.146.161] X-StarScan-Version: 6.4.1; banners=-,-,- X-VirusChecked: Checked Received: (qmail 12679 invoked from network); 23 Sep 2011 14:34:45 -0000 Received: from mo-p00-ob.rzone.de (HELO mo-p00-ob.rzone.de) (81.169.146.161) by server-10.tower-21.messagelabs.com with EDH-RSA-DES-CBC3-SHA encrypted SMTP; 23 Sep 2011 14:34:45 -0000 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; t=1316788499; l=6098; s=domk; d=aepfle.de; h=In-Reply-To:Content-Type:MIME-Version:References:Subject:Cc:To:From: Date:X-RZG-CLASS-ID:X-RZG-AUTH; bh=p1gMkixLd9P9EZPADQuonvGKBdc=; b=jsUjVo9+d53yrOZzfZ1Vm8hesSnjoFj4e9O/bIU5fR1xZysDjbT2riTYSoT5TQ5XLae CiPizw2mRRiP0KopC7SPpy4H6EQ2FxMUSvDWCXke4zMdjsGRSGK6bEVcmztbFwKD+cLIW BBrdKoheuGtPqxAwCYip29JTXoCywpom1kM= X-RZG-AUTH: :P2EQZWCpfu+qG7CngxMFH1J+zrwiavkK6tmQaLfmwtM48/lq3s7jFtE= X-RZG-CLASS-ID: mo00 Received: from probook.site (dslb-084-057-077-084.pools.arcor-ip.net [84.57.77.84]) by smtp.strato.de (klopstock mo53) (RZmta 26.7) with (EDH-RSA-DES-CBC3-SHA encrypted) ESMTPA id 201120n8NDYOb9 ; Fri, 23 Sep 2011 16:34:55 +0200 (MEST) Received: by probook.site (Postfix, from userid 1000) id A97A618B65; Fri, 23 Sep 2011 16:34:54 +0200 (CEST) Date: Fri, 23 Sep 2011 16:34:54 +0200 From: Olaf Hering <olaf@aepfle.de> To: Hongkaixing <hongkaixing@huawei.com>, Tim Deegan <tim@xen.org>, George Dunlap <george.dunlap@eu.citrix.com> Message-ID: <20110923143454.GA14701@aepfle.de> References: <E0AF011477D2AE458DC8801E0E570709014BD2BF@szxeml528-mbs.china.huawei.com> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline In-Reply-To: <E0AF011477D2AE458DC8801E0E570709014BD2BF@szxeml528-mbs.china.huawei.com> User-Agent: Mutt/1.5.21.rev5535 (2011-07-01) Cc: YangXiaowei <xiaowei.yang@huawei.com>, xen-devel@lists.xensource.com, "Eric Li\(Zhentao\)" <lizhentao@huawei.com>, Yanqiangjun <yanqiangjun@huawei.com> Subject: [Xen-devel] Re: Some problems about xenpaging X-BeenThere: xen-devel@lists.xensource.com X-Mailman-Version: 2.1.5 Precedence: list List-Id: Xen developer discussion <xen-devel.lists.xensource.com> List-Unsubscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe> List-Post: <mailto:xen-devel@lists.xensource.com> List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help> List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=subscribe> Sender: xen-devel-bounces@lists.xensource.com Errors-To: xen-devel-bounces@lists.xensource.com On Fri, Sep 23, Hongkaixing wrote: > Hi, Olaf Hello Hongkaixing, thanks for the feedback and the patches! > we have tested the xenpaging feature and found some problems. > (1) the test case like this : when we start a VM with POD enable, the xenpaging is started at the same time. > this case will cause many problems ,finally, we fixed the BUG, the patch is attached below. The changes for p2m_pod_decrease_reservation() and p2m_mem_paging_nominate() look ok to me, but I will leave the final word to Tim and George. If I understand the current logic in p2m_mem_paging_nominate() correctly, if a gfn is p2m_populate_on_demand, then gfn_to_mfn() will turn the gfn into p2m_ram_rw and let xenpaging write it to disk. That does not look correct. With your change the gfn will not be nominated because its not backed by RAM anyway. The locking in the p2m_mem_paging_nominate(), p2m_mem_paging_evict() and p2m_mem_paging_populate() can be improved. Using gfn_to_mfn_query() inside the p2m_lock looks correct to me. Even p2m_mem_paging_resume() could use the query variant and forward the type to p2m_ram_rw only if the p2mt was p2m_ram_paging_in_start. Please send proper patches for xen-unstable as described in the MAINTAINERS file. > (2) there is a very serious problem. we have observed many VM crash examples, the error code is not always the same. > we guess there exists conflict between xenpaging and memory mapping. > for instance, if the Dom0 map the DomU's memory to its own space , then the memory of DomainU is paged out, when the Domain0 access this memory area, a panic is caused. > And I really do not know whether the qemu device can perceive the memory modified by xenpaging? The issue is that gfn_to_mfn() returns the p2m_ram_paging* types and expects the caller to retry until the gfn is accessible, instead of calling p2m_mem_paging_populate() and going to sleep until the page is available. Thats still on my list of things to do. Olaf > here is the patch to solve the pod problem > 1) fix the p2m_pod_decrease_reservation() function, take care of the paging type > --- ./origin/xen/arch/x86/mm/p2m.c 2011-09-05 20:39:30.000000000 +0800 > +++ ./b/xen/arch/x86/mm/p2m.c 2011-09-23 23:46:19.000000000 +0800 > @@ -675,6 +675,23 @@ > BUG_ON(p2md->pod.entry_count < 0); > pod--; > } > + else if ( steal_for_cache && p2m_is_paging(t) ) > + { > + struct page_info *page; > + /* alloc a new page to compensate the pod list */ > + page = alloc_domheap_page(d, 0); > + if ( unlikely(page == NULL) ) > + { > + goto out_entry_check; > + } > + set_p2m_entry(d, gpfn + i, _mfn(INVALID_MFN), 0, p2m_invalid); > + p2m_mem_paging_drop_page(d, gpfn+i); > + p2m_pod_cache_add(d, page, 0); > + steal_for_cache = ( p2md->pod.entry_count > p2md->pod.count ); > + nonpod--; > + ram--; > + } > + /* for other ram types */ > else if ( steal_for_cache && p2m_is_ram(t) ) > { > struct page_info *page; > > 2) fix the race between POD and xenpaging > situation can be described as the follow > > xenpaging POD > > mfn = gfn_to_mfn() mfn = gfn_to_mfn() > check p2m type check p2mt > p2m_lock > change p2m type > p2m_unlock > add to pod list > p2m_lock() > change p2m type > p2m_unlock > put_page() > > the result is a page is added to the pod list,and then it's removed from the list by put_page. > my suggestion is to extend the range of the p2m lock to contain the p2m check. > > in p2m_mem_paging_nominate() function > @@ -2532,7 +2561,8 @@ > mfn_t mfn; > int ret; > > - mfn = gfn_to_mfn(d, gfn, &p2mt); > + p2m_lock(d->arch.p2m); > + mfn = gfn_to_mfn_query(d, gfn, &p2mt); > > /* Check if mfn is valid */ > ret = -EINVAL; > @@ -2580,13 +2610,12 @@ > goto out; > > /* Fix p2m entry */ > - p2m_lock(d->arch.p2m); > set_p2m_entry(d, gfn, mfn, 0, p2m_ram_paging_out); > - p2m_unlock(d->arch.p2m); > > ret = 0; > > out: > + p2m_unlock(d->arch.p2m); > return ret; > } > in > @@ -2595,34 +2624,39 @@ > struct page_info *page; > p2m_type_t p2mt; > mfn_t mfn; > - > + int ret; > + p2m_lock(d->arch.p2m); > /* Get mfn */ > - mfn = gfn_to_mfn(d, gfn, &p2mt); > + mfn = gfn_to_mfn_query(d, gfn, &p2mt); > + > + ret = -EINVAL; > if ( unlikely(!mfn_valid(mfn)) ) > - return -EINVAL; > + goto out; > > if (p2mt != p2m_ram_paging_out) > { > printk("p2m_mem_paging_evict type %d\n", p2mt); > - return -EINVAL; > + goto out; > } > /* Get the page so it doesn't get modified under Xen's feet */ > page = mfn_to_page(mfn); > if ( unlikely(!get_page(page, d)) ) > - return -EINVAL; > + goto out; > > /* Decrement guest domain's ref count of the page */ > if ( test_and_clear_bit(_PGC_allocated, &page->count_info) ) > put_page(page); > > /* Remove mapping from p2m table */ > - p2m_lock(d->arch.p2m); > set_p2m_entry(d, gfn, _mfn(PAGING_MFN), 0, p2m_ram_paged); > - p2m_unlock(d->arch.p2m); > > /* Put the page back so it gets freed */ > put_page(page); > + > + ret = 0; > > +out: > + p2m_unlock(d->arch.p2m); > return 0; > } > > 3) fix the vmx_load_pdptrs() function in vmx.c > in this situation the page directory table is paged out. > Although using mdelay() is a bad idea, it's better than making the xen crash > > void vmx_load_pdptrs(struct vcpu *v) > { > unsigned long cr3 = v->arch.hvm_vcpu.guest_cr[3], mfn; > uint64_t *guest_pdptrs; > p2m_type_t p2mt; > char *p; > unsigned int try_count = 0; > /* EPT needs to load PDPTRS into VMCS for PAE. */ > if ( !hvm_pae_enabled(v) || (v->arch.hvm_vcpu.guest_efer & EFER_LMA) ) > return; > if ( cr3 & 0x1fUL ) > goto crash; > mfn = mfn_x(gfn_to_mfn(v->domain, cr3 >> PAGE_SHIFT, &p2mt)); > if ( !p2m_is_ram(p2mt) ) > goto crash; > + if( p2m_is_paging(p2mt)) > + { > + p2m_mem_paging_populate(v->domain, cr3 >> PAGE_SHIFT); > + do > + { > + mdelay(1); > + try_count ++; > + if ( try_count > 65535 ) > + { > + goto crash; > + } > + mfn = mfn_x(gfn_to_mfn(v->domain, cr3 >> PAGE_SHIFT, &p2mt)); > + }while( !mfn_valid(mfn)); > + } > + > p = map_domain_page(mfn); _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel From xen-devel-bounces@lists.xensource.com Fri Sep 23 07:43:14 2011 Return-path: <xen-devel-bounces@lists.xensource.com> Envelope-to: www-data@lists.xensource.com Delivery-date: Fri, 23 Sep 2011 07:43:14 -0700 Received: from localhost ([127.0.0.1] helo=lists.colo.xensource.com) by lists.xensource.com with esmtp (Exim 4.43) id 1R76y9-0004Pg-D3; Fri, 23 Sep 2011 07:43:13 -0700 Received: from mail182.messagelabs.com ([85.158.139.83]) by lists.xensource.com with esmtp (Exim 4.43) id 1R76xg-0004Cy-NQ for xen-devel@lists.xensource.com; Fri, 23 Sep 2011 07:42:45 -0700 X-Env-Sender: jeremy@goop.org X-Msg-Ref: server-14.tower-182.messagelabs.com!1316788959!19336112!1 X-Originating-IP: [74.207.240.146] X-StarScan-Version: 6.4.1; banners=-,-,- X-VirusChecked: Checked Received: (qmail 6752 invoked from network); 23 Sep 2011 14:42:41 -0000 Received: from claw.goop.org (HELO claw.goop.org) (74.207.240.146) by server-14.tower-182.messagelabs.com with DHE-RSA-AES256-SHA encrypted SMTP; 23 Sep 2011 14:42:41 -0000 Received: from saboo.goop.org (unknown [IPv6:2001:470:1f05:899:f2de:f1ff:fe5c:34ed]) (Authenticated sender: smtp-saboo) by claw.goop.org (Postfix) with ESMTPSA id 2F2C990D4; Fri, 23 Sep 2011 07:42:39 -0700 (PDT) Received: from saboo.goop.org (localhost [IPv6:::1]) by saboo.goop.org (Postfix) with ESMTP id 4444F20C4B; Fri, 23 Sep 2011 07:42:37 -0700 (PDT) Message-ID: <4E7C9ADD.6010209@goop.org> Date: Fri, 23 Sep 2011 07:42:37 -0700 From: Jeremy Fitzhardinge <jeremy@goop.org> User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:6.0.2) Gecko/20110906 Thunderbird/6.0.2 MIME-Version: 1.0 To: stefano.stabellini@eu.citrix.com References: <1316776753-10168-1-git-send-email-stefano.stabellini@eu.citrix.com> In-Reply-To: <1316776753-10168-1-git-send-email-stefano.stabellini@eu.citrix.com> X-Enigmail-Version: 1.3.2 Content-Type: text/plain; charset=ISO-8859-15 Content-Transfer-Encoding: 7bit Cc: Ian.Campbell@eu.citrix.com, xen-devel@lists.xensource.com, konrad.wilk@oracle.com Subject: [Xen-devel] Re: [PATCH] xen: remove XEN_PLATFORM_PCI config option X-BeenThere: xen-devel@lists.xensource.com X-Mailman-Version: 2.1.5 Precedence: list List-Id: Xen developer discussion <xen-devel.lists.xensource.com> List-Unsubscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe> List-Post: <mailto:xen-devel@lists.xensource.com> List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help> List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=subscribe> Sender: xen-devel-bounces@lists.xensource.com Errors-To: xen-devel-bounces@lists.xensource.com On 09/23/2011 04:19 AM, stefano.stabellini@eu.citrix.com wrote: > From: Stefano Stabellini <stefano.stabellini@eu.citrix.com> > > Xen PVHVM needs xen-platform-pci, on the other hand xen-platform-pci is > useless in any other cases. > Therefore remove the XEN_PLATFORM_PCI config option and compile > xen-platform-pci built-in if XEN_PVHVM is selected. What happens if you disable CONFIG_PCI? I think XEN_PLATFORM_PCI still needs to exist, but just not user-visible. J _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel From xen-devel-bounces@lists.xensource.com Fri Sep 23 07:44:41 2011 Return-path: <xen-devel-bounces@lists.xensource.com> Envelope-to: www-data@lists.xensource.com Delivery-date: Fri, 23 Sep 2011 07:44:41 -0700 Received: from localhost ([127.0.0.1] helo=lists.colo.xensource.com) by lists.xensource.com with esmtp (Exim 4.43) id 1R76zZ-0004mY-Nh; Fri, 23 Sep 2011 07:44:41 -0700 Received: from mail21.messagelabs.com ([85.158.143.35]) by lists.xensource.com with smtp (Exim 4.43) id 1R76yL-0004TC-Gb for xen-devel@lists.xensource.com; Fri, 23 Sep 2011 07:43:27 -0700 X-Env-Sender: anthony@overnetdata.com X-Msg-Ref: server-7.tower-21.messagelabs.com!1316788967!55991153!1 X-Originating-IP: [81.137.131.225] X-StarScan-Version: 6.4.1; banners=-,-,- X-VirusChecked: Checked Received: (qmail 1177 invoked from network); 23 Sep 2011 14:42:47 -0000 Received: from host81-137-131-225.in-addr.btopenworld.com (HELO zimbra.overnetdata.com) (81.137.131.225) by server-7.tower-21.messagelabs.com with SMTP; 23 Sep 2011 14:42:47 -0000 Received: from localhost (localhost.localdomain [127.0.0.1]) by zimbra.overnetdata.com (Postfix) with ESMTP id 5E53B16187F; Fri, 23 Sep 2011 15:43:05 +0100 (BST) X-Virus-Scanned: amavisd-new at overnetdata.com Received: from zimbra.overnetdata.com ([127.0.0.1]) by localhost (zimbra.overnetdata.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ojCs4LOiV3lN; Fri, 23 Sep 2011 15:42:57 +0100 (BST) Received: from [192.168.1.60] (unknown [192.168.1.60]) by zimbra.overnetdata.com (Postfix) with ESMTPSA id 384B2161A1D; Fri, 23 Sep 2011 15:42:57 +0100 (BST) Message-ID: <4E7C9AEF.602@overnetdata.com> Date: Fri, 23 Sep 2011 15:42:55 +0100 From: Anthony Wright <anthony@overnetdata.com> User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:6.0.2) Gecko/20110902 Thunderbird/6.0.2 MIME-Version: 1.0 To: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com> Subject: Re: [Xen-devel] Getting mm.c errors from xl dmesg on certain hardware References: <4E7C5F8B.6050509@overnetdata.com> <20110923132940.GB19579@phenom.oracle.com> In-Reply-To: <20110923132940.GB19579@phenom.oracle.com> X-Enigmail-Version: 1.3.2 Content-Type: multipart/mixed; boundary="------------080100020007070504090806" Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com> X-BeenThere: xen-devel@lists.xensource.com X-Mailman-Version: 2.1.5 Precedence: list List-Id: Xen developer discussion <xen-devel.lists.xensource.com> List-Unsubscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe> List-Post: <mailto:xen-devel@lists.xensource.com> List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help> List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=subscribe> Sender: xen-devel-bounces@lists.xensource.com Errors-To: xen-devel-bounces@lists.xensource.com This is a multi-part message in MIME format. --------------080100020007070504090806 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit On 23/09/2011 14:29, Konrad Rzeszutek Wilk wrote: > On Fri, Sep 23, 2011 at 11:29:31AM +0100, Anthony Wright wrote: >> Konrad Rzeszutek Wilk wrote: >> >>>> (XEN) mm.c:907:d0 Error getting mfn 3a09c (pfn 55555555) from L1 entry 000000003a09c023 for l1e_owner=0, pg_owner=0 >>>> (XEN) mm.c:907:d0 Error getting mfn 3a09d (pfn 55555555) from L1 entry 000000003a09d023 for l1e_owner=0, pg_owner=0 >>>> (XEN) mm.c:907:d0 Error getting mfn 3a09e (pfn 55555555) from L1 entry 000000003a09e023 for l1e_owner=0, pg_owner=0 >>>> (XEN) mm.c:907:d0 Error getting mfn 3a09f (pfn 55555555) from L1 entry 000000003a09f023 for l1e_owner=0, pg_owner=0 >>>> (XEN) traps.c:2388:d0 Domain attempted WRMSR c0010004 from 0x0000ab23d6d622da to 0x000000000000abcd. >>> Do they show up during bootup? As in do you see those _when_ you launch your guests? >>> To figure out this particular issue you should try using 'console_to_ring' (so that >>> dom0 output and Xen output are mingled togehter) and also post this under a new subject >>> to not confuse this email thread. >> The messages show up during the initial dom0 boot, before any domUs are >> loaded. I've attached a second xl dmesg log which is similar to the >> first, but the numbers in the error messages are different. >> >> The messages are hardware dependant as I don't get them on another >> system with different hardware configuration but with identical software. >> >> The motherboard is a ASUS M2N68 AM PLUS, with 4GB of RAM. If I remove >> one of the sticks of ram to take it down to 2GB, the mm.c errors are no >> longer displayed, but I still get the traps.c message. >> > Um, you might want to include 'loglevel=9 console=hvc0 initcall_debug' on your Linux line > so the output from Linux kernel gets intermingled with the Xen. > >> mapping kernel into physical memory >> Xen: setup ISA identity maps >> about to get started... >> (XEN) mm.c:907:d0 Error getting mfn 3809c (pfn b602c) from L1 entry 000000003809c023 for l1e_owner=0, pg_owner=0 >> (XEN) mm.c:907:d0 Error getting mfn 3809d (pfn b602d) from L1 entry 000000003809d023 for l1e_owner=0, pg_owner=0 >> (XEN) mm.c:907:d0 Error getting mfn 3809e (pfn b602e) from L1 entry 000000003809e023 for l1e_owner=0, pg_owner=0 >> (XEN) mm.c:907:d0 Error getting mfn 3809f (pfn b602f) from L1 entry 000000003809f023 for l1e_owner=0, pg_owner=0 >> (XEN) traps.c:2388:d0 Domain attempted WRMSR c0010004 from 0x00009b27fe9726ca to 0x000000000000abcd. I ran with 'console_to_ring conring_size=65536' on the xen command line & 'debug loglevel=9 console=hvc0 initcall_debug' on the kernel command line. The output is attached. --------------080100020007070504090806 Content-Type: text/plain; name="mm-xl-dmesg-full.log" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="mm-xl-dmesg-full.log" IF9fICBfXyAgICAgICAgICAgIF8gIF8gICAgXyAgIF8gCiBcIFwvIC9fX18gXyBfXyAgIHwg fHwgfCAgLyB8IC8gfAogIFwgIC8vIF8gXCAnXyBcICB8IHx8IHxfIHwgfCB8IHwKICAvICBc ICBfXy8gfCB8IHwgfF9fICAgX3x8IHxffCB8CiAvXy9cX1xfX198X3wgfF98ICAgIHxffChf KV8oXylffAogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAKKFhFTikgWGVuIHZl cnNpb24gNC4xLjEgKEBbdW5rbm93bl0pIChnY2MgdmVyc2lvbiA0LjQuMyAoR0NDKSApIFdl ZCBTZXAgMjEgMDg6MjU6MzYgR01UIDIwMTEKKFhFTikgTGF0ZXN0IENoYW5nZVNldDogdW5h dmFpbGFibGUKKFhFTikgQm9vdGxvYWRlcjogR05VIEdSVUIgMC45NwooWEVOKSBDb21tYW5k IGxpbmU6IGNvbnNvbGVfdG9fcmluZyBjb25yaW5nX3NpemU9NjU1MzYKKFhFTikgVmlkZW8g aW5mb3JtYXRpb246CihYRU4pICBWR0EgaXMgdGV4dCBtb2RlIDgweDI1LCBmb250IDh4MTYK KFhFTikgIFZCRS9EREMgbWV0aG9kczogbm9uZTsgRURJRCB0cmFuc2ZlciB0aW1lOiAwIHNl Y29uZHMKKFhFTikgIEVESUQgaW5mbyBub3QgcmV0cmlldmVkIGJlY2F1c2Ugbm8gRERDIHJl dHJpZXZhbCBtZXRob2QgZGV0ZWN0ZWQKKFhFTikgRGlzYyBpbmZvcm1hdGlvbjoKKFhFTikg IEZvdW5kIDIgTUJSIHNpZ25hdHVyZXMKKFhFTikgIEZvdW5kIDIgRUREIGluZm9ybWF0aW9u IHN0cnVjdHVyZXMKKFhFTikgWGVuLWU4MjAgUkFNIG1hcDoKKFhFTikgIDAwMDAwMDAwMDAw MDAwMDAgLSAwMDAwMDAwMDAwMDliNDAwICh1c2FibGUpCihYRU4pICAwMDAwMDAwMDAwMDli NDAwIC0gMDAwMDAwMDAwMDBhMDAwMCAocmVzZXJ2ZWQpCihYRU4pICAwMDAwMDAwMDAwMGUy MDAwIC0gMDAwMDAwMDAwMDEwMDAwMCAocmVzZXJ2ZWQpCihYRU4pICAwMDAwMDAwMDAwMTAw MDAwIC0gMDAwMDAwMDBhZmY5MDAwMCAodXNhYmxlKQooWEVOKSAgMDAwMDAwMDBhZmY5MDAw MCAtIDAwMDAwMDAwYWZmOWUwMDAgKEFDUEkgZGF0YSkKKFhFTikgIDAwMDAwMDAwYWZmOWUw MDAgLSAwMDAwMDAwMGFmZmUwMDAwIChBQ1BJIE5WUykKKFhFTikgIDAwMDAwMDAwYWZmZTAw MDAgLSAwMDAwMDAwMGFmZmVlMDAwIChyZXNlcnZlZCkKKFhFTikgIDAwMDAwMDAwYWZmZjAw MDAgLSAwMDAwMDAwMGIwMDAwMDAwIChyZXNlcnZlZCkKKFhFTikgIDAwMDAwMDAwZmVjMDAw MDAgLSAwMDAwMDAwMGZlYzAxMDAwIChyZXNlcnZlZCkKKFhFTikgIDAwMDAwMDAwZmVlMDAw MDAgLSAwMDAwMDAwMGZlZjAwMDAwIChyZXNlcnZlZCkKKFhFTikgIDAwMDAwMDAwZmZmMDAw MDAgLSAwMDAwMDAwMTAwMDAwMDAwIChyZXNlcnZlZCkKKFhFTikgIDAwMDAwMDAxMDAwMDAw MDAgLSAwMDAwMDAwMTQwMDAwMDAwICh1c2FibGUpCihYRU4pIFN5c3RlbSBSQU06IDM4MzlN QiAoMzkzMTMwOGtCKQooWEVOKSBBQ1BJOiBSU0RQIDAwMEZCNUQwLCAwMDE0IChyMCBBQ1BJ QU0pCihYRU4pIEFDUEk6IFJTRFQgQUZGOTAwMDAsIDAwMzggKHIxIDAzMjIxMCBSU0RUMTAz NyAyMDEwMDMyMiBNU0ZUICAgICAgIDk3KQooWEVOKSBBQ1BJOiBGQUNQIEFGRjkwMjAwLCAw MDg0IChyMiAwMzIyMTAgRkFDUDEwMzcgMjAxMDAzMjIgTVNGVCAgICAgICA5NykKKFhFTikg QUNQSTogRFNEVCBBRkY5MDQ2MCwgNzMwNyAocjEgIEExMjcwIEExMjcwMDAwICAgICAgICAw IElOVEwgMjAwNjAxMTMpCihYRU4pIEFDUEk6IEZBQ1MgQUZGOUUwMDAsIDAwNDAKKFhFTikg QUNQSTogQVBJQyBBRkY5MDM5MCwgMDA5MCAocjEgMDMyMjEwIEFQSUMxMDM3IDIwMTAwMzIy IE1TRlQgICAgICAgOTcpCihYRU4pIEFDUEk6IE1DRkcgQUZGOTA0MjAsIDAwM0MgKHIxIDAz MjIxMCBPRU1NQ0ZHICAyMDEwMDMyMiBNU0ZUICAgICAgIDk3KQooWEVOKSBBQ1BJOiBPRU1C IEFGRjlFMDQwLCAwMDcxIChyMSAwMzIyMTAgT0VNQjEwMzcgMjAxMDAzMjIgTVNGVCAgICAg ICA5NykKKFhFTikgQUNQSTogSFBFVCBBRkY5Nzc3MCwgMDAzOCAocjEgMDMyMjEwIE9FTUhQ RVQwIDIwMTAwMzIyIE1TRlQgICAgICAgOTcpCihYRU4pIFhlbiBoZWFwOiA5TUIgKDk3ODhr QikKKFhFTikgRG9tYWluIGhlYXAgaW5pdGlhbGlzZWQKKFhFTikgUHJvY2Vzc29yICMwIDA6 NiBBUElDIHZlcnNpb24gMTYKKFhFTikgUHJvY2Vzc29yICMxIDA6NiBBUElDIHZlcnNpb24g MTYKKFhFTikgSU9BUElDWzBdOiBhcGljX2lkIDIsIHZlcnNpb24gMTcsIGFkZHJlc3MgMHhm ZWMwMDAwMCwgR1NJIDAtMjMKKFhFTikgRW5hYmxpbmcgQVBJQyBtb2RlOiAgRmxhdC4gIFVz aW5nIDEgSS9PIEFQSUNzCihYRU4pIFRhYmxlIGlzIG5vdCBmb3VuZCEKKFhFTikgVXNpbmcg c2NoZWR1bGVyOiBTTVAgQ3JlZGl0IFNjaGVkdWxlciAoY3JlZGl0KQooWEVOKSBEZXRlY3Rl ZCAzMDEzLjc1MSBNSHogcHJvY2Vzc29yLgooWEVOKSBBTUQtVmk6IElPTU1VIG5vdCBmb3Vu ZCEKKFhFTikgSS9PIHZpcnR1YWxpc2F0aW9uIGRpc2FibGVkCihYRU4pIEVOQUJMSU5HIElP LUFQSUMgSVJRcwooWEVOKSAgLT4gVXNpbmcgbmV3IEFDSyBtZXRob2QKKFhFTikgUGxhdGZv cm0gdGltZXIgaXMgMjUuMDAwTUh6IEhQRVQKKFhFTikgQWxsb2NhdGVkIGNvbnNvbGUgcmlu ZyBvZiA0MDk2IEtpQi4KKFhFTikgQ1BVMDogQU1EIFNWTSBFeHRlbnNpb24gaXMgZGlzYWJs ZWQgaW4gQklPUy4KKFhFTikgU1ZNOiBmYWlsZWQgdG8gaW5pdGlhbGlzZS4KKFhFTikgQnJv dWdodCB1cCAyIENQVXMKKFhFTikgKioqIExPQURJTkcgRE9NQUlOIDAgKioqCihYRU4pICBY ZW4gIGtlcm5lbDogMzItYml0LCBQQUUsIGxzYgooWEVOKSAgRG9tMCBrZXJuZWw6IDMyLWJp dCwgUEFFLCBsc2IsIHBhZGRyIDB4MTAwMDAwMCAtPiAweDFiMzgwMDAKKFhFTikgUEhZU0lD QUwgTUVNT1JZIEFSUkFOR0VNRU5UOgooWEVOKSAgRG9tMCBhbGxvYy46ICAgMDAwMDAwMDEz ODAwMDAwMC0+MDAwMDAwMDEzYzAwMDAwMCAoOTIwNzAxIHBhZ2VzIHRvIGJlIGFsbG9jYXRl ZCkKKFhFTikgIEluaXQuIHJhbWRpc2s6IDAwMDAwMDAxM2Y2ZWYwMDAtPjAwMDAwMDAxM2Zm ZmZjYTQKKFhFTikgVklSVFVBTCBNRU1PUlkgQVJSQU5HRU1FTlQ6CihYRU4pICBMb2FkZWQg a2VybmVsOiBjMTAwMDAwMC0+YzFiMzgwMDAKKFhFTikgIEluaXQuIHJhbWRpc2s6IGMxYjM4 MDAwLT5jMjQ0OGNhNAooWEVOKSAgUGh5cy1NYWNoIG1hcDogYzI0NDkwMDAtPmMyN2RlNjM4 CihYRU4pICBTdGFydCBpbmZvOiAgICBjMjdkZjAwMC0+YzI3ZGY0N2MKKFhFTikgIFBhZ2Ug dGFibGVzOiAgIGMyN2UwMDAwLT5jMjdmYjAwMAooWEVOKSAgQm9vdCBzdGFjazogICAgYzI3 ZmIwMDAtPmMyN2ZjMDAwCihYRU4pICBUT1RBTDogICAgICAgICBjMDAwMDAwMC0+YzJjMDAw MDAKKFhFTikgIEVOVFJZIEFERFJFU1M6IGMxNzNlMDAwCihYRU4pIERvbTAgaGFzIG1heGlt dW0gMiBWQ1BVcwooWEVOKSBTY3J1YmJpbmcgRnJlZSBSQU06IC5kb25lLgooWEVOKSBYZW4g dHJhY2UgYnVmZmVyczogZGlzYWJsZWQKKFhFTikgU3RkLiBMb2dsZXZlbDogRXJyb3JzIGFu ZCB3YXJuaW5ncwooWEVOKSBHdWVzdCBMb2dsZXZlbDogTm90aGluZyAoUmF0ZS1saW1pdGVk OiBFcnJvcnMgYW5kIHdhcm5pbmdzKQooWEVOKSBYZW4gaXMgcmVsaW5xdWlzaGluZyBWR0Eg Y29uc29sZS4KKFhFTikgKioqIFNlcmlhbCBpbnB1dCAtPiBET00wICh0eXBlICdDVFJMLWEn IHRocmVlIHRpbWVzIHRvIHN3aXRjaCBpbnB1dCB0byBYZW4pCihYRU4pIEZyZWVkIDE4OGtC IGluaXQgbWVtb3J5LgptYXBwaW5nIGtlcm5lbCBpbnRvIHBoeXNpY2FsIG1lbW9yeQpYZW46 IHNldHVwIElTQSBpZGVudGl0eSBtYXBzCmFib3V0IHRvIGdldCBzdGFydGVkLi4uCihYRU4p IG1tLmM6OTA3OmQwIEVycm9yIGdldHRpbmcgbWZuIDM4MDljIChwZm4gYjYwMmMpIGZyb20g TDEgZW50cnkgMDAwMDAwMDAzODA5YzAyMyBmb3IgbDFlX293bmVyPTAsIHBnX293bmVyPTAK KFhFTikgbW0uYzo5MDc6ZDAgRXJyb3IgZ2V0dGluZyBtZm4gMzgwOWQgKHBmbiBiNjAyZCkg ZnJvbSBMMSBlbnRyeSAwMDAwMDAwMDM4MDlkMDIzIGZvciBsMWVfb3duZXI9MCwgcGdfb3du ZXI9MAooWEVOKSBtbS5jOjkwNzpkMCBFcnJvciBnZXR0aW5nIG1mbiAzODA5ZSAocGZuIGI2 MDJlKSBmcm9tIEwxIGVudHJ5IDAwMDAwMDAwMzgwOWUwMjMgZm9yIGwxZV9vd25lcj0wLCBw Z19vd25lcj0wCihYRU4pIG1tLmM6OTA3OmQwIEVycm9yIGdldHRpbmcgbWZuIDM4MDlmIChw Zm4gYjYwMmYpIGZyb20gTDEgZW50cnkgMDAwMDAwMDAzODA5ZjAyMyBmb3IgbDFlX293bmVy PTAsIHBnX293bmVyPTAKWyAgICAwLjAwMDAwMF0gUmVzZXJ2aW5nIHZpcnR1YWwgYWRkcmVz cyBzcGFjZSBhYm92ZSAweGY1ODAwMDAwDQpbICAgIDAuMDAwMDAwXSBJbml0aWFsaXppbmcg Y2dyb3VwIHN1YnN5cyBjcHVzZXQNClsgICAgMC4wMDAwMDBdIEluaXRpYWxpemluZyBjZ3Jv dXAgc3Vic3lzIGNwdQ0KWyAgICAwLjAwMDAwMF0gTGludXggdmVyc2lvbiAzLjAuNCAocm9v dEBsaW51eC1rcnEwKSAoZ2NjIHZlcnNpb24gNC40LjMgKEdDQykgKSAjMSBTTVAgVGh1IFNl cCAyMiAxMjozMjoyNSBHTVQgMjAxMQ0KWyAgICAwLjAwMDAwMF0gS0VSTkVMIHN1cHBvcnRl ZCBjcHVzOg0KWyAgICAwLjAwMDAwMF0gICBJbnRlbCBHZW51aW5lSW50ZWwNClsgICAgMC4w MDAwMDBdICAgQU1EIEF1dGhlbnRpY0FNRA0KWyAgICAwLjAwMDAwMF0gICBOU0MgR2VvZGUg YnkgTlNDDQpbICAgIDAuMDAwMDAwXSAgIEN5cml4IEN5cml4SW5zdGVhZA0KWyAgICAwLjAw MDAwMF0gICBDZW50YXVyIENlbnRhdXJIYXVscw0KWyAgICAwLjAwMDAwMF0gICBUcmFuc21l dGEgR2VudWluZVRNeDg2DQpbICAgIDAuMDAwMDAwXSAgIFRyYW5zbWV0YSBUcmFuc21ldGFD UFUNClsgICAgMC4wMDAwMDBdICAgVU1DIFVNQyBVTUMgVU1DDQpbICAgIDAuMDAwMDAwXSB4 ZW5fcmVsZWFzZV9jaHVuazogbG9va2luZyBhdCBhcmVhIHBmbiBhZmZlZS1hZmZmMDogMiBw YWdlcyBmcmVlZA0KWyAgICAwLjAwMDAwMF0geGVuX3JlbGVhc2VfY2h1bms6IGxvb2tpbmcg YXQgYXJlYSBwZm4gYjAwMDAtZTU1OGU6IDIxODUxMCBwYWdlcyBmcmVlZA0KWyAgICAwLjAw MDAwMF0gcmVsZWFzZWQgMjE4NTEyIHBhZ2VzIG9mIHVudXNlZCBtZW1vcnkNClsgICAgMC4w MDAwMDBdIDEtMSBtYXBwaW5nIG9uIDljLT4xMDANClsgICAgMC4wMDAwMDBdIDEtMSBtYXBw aW5nIG9uIGFmZjkwLT4xMDAwMDANClsgICAgMC4wMDAwMDBdIFNldCAzMjc4OTIgcGFnZShz KSB0byAxLTEgbWFwcGluZy4NClsgICAgMC4wMDAwMDBdIEJJT1MtcHJvdmlkZWQgcGh5c2lj YWwgUkFNIG1hcDoNClsgICAgMC4wMDAwMDBdICBYZW46IDAwMDAwMDAwMDAwMDAwMDAgLSAw MDAwMDAwMDAwMDliMDAwICh1c2FibGUpDQpbICAgIDAuMDAwMDAwXSAgWGVuOiAwMDAwMDAw MDAwMDliNDAwIC0gMDAwMDAwMDAwMDEwMDAwMCAocmVzZXJ2ZWQpDQpbICAgIDAuMDAwMDAw XSAgWGVuOiAwMDAwMDAwMDAwMTAwMDAwIC0gMDAwMDAwMDBhZmY5MDAwMCAodXNhYmxlKQ0K WyAgICAwLjAwMDAwMF0gIFhlbjogMDAwMDAwMDBhZmY5MDAwMCAtIDAwMDAwMDAwYWZmOWUw MDAgKEFDUEkgZGF0YSkNClsgICAgMC4wMDAwMDBdICBYZW46IDAwMDAwMDAwYWZmOWUwMDAg LSAwMDAwMDAwMGFmZmUwMDAwIChBQ1BJIE5WUykNClsgICAgMC4wMDAwMDBdICBYZW46IDAw MDAwMDAwYWZmZTAwMDAgLSAwMDAwMDAwMGFmZmVlMDAwIChyZXNlcnZlZCkNClsgICAgMC4w MDAwMDBdICBYZW46IDAwMDAwMDAwYWZmZjAwMDAgLSAwMDAwMDAwMGIwMDAwMDAwIChyZXNl cnZlZCkNClsgICAgMC4wMDAwMDBdICBYZW46IDAwMDAwMDAwZmVjMDAwMDAgLSAwMDAwMDAw MGZlYzAxMDAwIChyZXNlcnZlZCkNClsgICAgMC4wMDAwMDBdICBYZW46IDAwMDAwMDAwZmVl MDAwMDAgLSAwMDAwMDAwMGZlZjAwMDAwIChyZXNlcnZlZCkNClsgICAgMC4wMDAwMDBdICBY ZW46IDAwMDAwMDAwZmZmMDAwMDAgLSAwMDAwMDAwMTAwMDAwMDAwIChyZXNlcnZlZCkNClsg ICAgMC4wMDAwMDBdICBYZW46IDAwMDAwMDAxMDAwMDAwMDAgLSAwMDAwMDAwMTc1NTkwMDAw ICh1c2FibGUpDQpbICAgIDAuMDAwMDAwXSBOWCAoRXhlY3V0ZSBEaXNhYmxlKSBwcm90ZWN0 aW9uOiBhY3RpdmUNClsgICAgMC4wMDAwMDBdIERNSSBwcmVzZW50Lg0KWyAgICAwLjAwMDAw MF0gRE1JOiBTeXN0ZW0gbWFudWZhY3R1cmVyIFN5c3RlbSBQcm9kdWN0IE5hbWUvTTJONjgt QU0gUGx1cywgQklPUyAxNDAyICAgIDAzLzIyLzIwMTANClsgICAgMC4wMDAwMDBdIGU4MjAg dXBkYXRlIHJhbmdlOiAwMDAwMDAwMDAwMDAwMDAwIC0gMDAwMDAwMDAwMDAxMDAwMCAodXNh YmxlKSA9PT4gKHJlc2VydmVkKQ0KWyAgICAwLjAwMDAwMF0gZTgyMCByZW1vdmUgcmFuZ2U6 IDAwMDAwMDAwMDAwYTAwMDAgLSAwMDAwMDAwMDAwMTAwMDAwICh1c2FibGUpDQpbICAgIDAu MDAwMDAwXSBsYXN0X3BmbiA9IDB4MTc1NTkwIG1heF9hcmNoX3BmbiA9IDB4MTAwMDAwMA0K WyAgICAwLjAwMDAwMF0gZm91bmQgU01QIE1QLXRhYmxlIGF0IFtjMDBmZjc4MF0gZmY3ODAN ClsgICAgMC4wMDAwMDBdIGluaXRpYWwgbWVtb3J5IG1hcHBlZCA6IDAgLSAwMzNmZjAwMA0K WyAgICAwLjAwMDAwMF0gQmFzZSBtZW1vcnkgdHJhbXBvbGluZSBhdCBbYzAwOTcwMDBdIDk3 MDAwIHNpemUgMTYzODQNClsgICAgMC4wMDAwMDBdIGluaXRfbWVtb3J5X21hcHBpbmc6IDAw MDAwMDAwMDAwMDAwMDAtMDAwMDAwMDAyZDNmZTAwMA0KWyAgICAwLjAwMDAwMF0gIDAwMDAw MDAwMDAgLSAwMDJkM2ZlMDAwIHBhZ2UgNGsNClsgICAgMC4wMDAwMDBdIGtlcm5lbCBkaXJl Y3QgbWFwcGluZyB0YWJsZXMgdXAgdG8gMmQzZmUwMDAgQCAzMjkyMDAwLTMzZmYwMDANClsg ICAgMC4wMDAwMDBdIHhlbjogc2V0dGluZyBSVyB0aGUgcmFuZ2UgMzNlMjAwMCAtIDMzZmYw MDANClsgICAgMC4wMDAwMDBdIFJBTURJU0s6IDAxYjM4MDAwIC0gMDI0NDkwMDANClsgICAg MC4wMDAwMDBdIEFDUEk6IFJTRFAgMDAwZmI1ZDAgMDAwMTQgKHYwMCBBQ1BJQU0pDQpbICAg IDAuMDAwMDAwXSBBQ1BJOiBSU0RUIGFmZjkwMDAwIDAwMDM4ICh2MDEgMDMyMjEwIFJTRFQx MDM3IDIwMTAwMzIyIE1TRlQgMDAwMDAwOTcpDQpbICAgIDAuMDAwMDAwXSBBQ1BJOiBGQUNQ IGFmZjkwMjAwIDAwMDg0ICh2MDIgMDMyMjEwIEZBQ1AxMDM3IDIwMTAwMzIyIE1TRlQgMDAw MDAwOTcpDQpbICAgIDAuMDAwMDAwXSBBQ1BJOiBEU0RUIGFmZjkwNDYwIDA3MzA3ICh2MDEg IEExMjcwIEExMjcwMDAwIDAwMDAwMDAwIElOVEwgMjAwNjAxMTMpDQpbICAgIDAuMDAwMDAw XSBBQ1BJOiBGQUNTIGFmZjllMDAwIDAwMDQwDQpbICAgIDAuMDAwMDAwXSBBQ1BJOiBBUElD IGFmZjkwMzkwIDAwMDkwICh2MDEgMDMyMjEwIEFQSUMxMDM3IDIwMTAwMzIyIE1TRlQgMDAw MDAwOTcpDQpbICAgIDAuMDAwMDAwXSBBQ1BJOiBNQ0ZHIGFmZjkwNDIwIDAwMDNDICh2MDEg MDMyMjEwIE9FTU1DRkcgIDIwMTAwMzIyIE1TRlQgMDAwMDAwOTcpDQpbICAgIDAuMDAwMDAw XSBBQ1BJOiBPRU1CIGFmZjllMDQwIDAwMDcxICh2MDEgMDMyMjEwIE9FTUIxMDM3IDIwMTAw MzIyIE1TRlQgMDAwMDAwOTcpDQpbICAgIDAuMDAwMDAwXSBBQ1BJOiBIUEVUIGFmZjk3Nzcw IDAwMDM4ICh2MDEgMDMyMjEwIE9FTUhQRVQwIDIwMTAwMzIyIE1TRlQgMDAwMDAwOTcpDQpb ICAgIDAuMDAwMDAwXSBBQ1BJOiBMb2NhbCBBUElDIGFkZHJlc3MgMHhmZWUwMDAwMA0KWyAg ICAwLjAwMDAwMF0gNTI0OU1CIEhJR0hNRU0gYXZhaWxhYmxlLg0KWyAgICAwLjAwMDAwMF0g NzIzTUIgTE9XTUVNIGF2YWlsYWJsZS4NClsgICAgMC4wMDAwMDBdICAgbWFwcGVkIGxvdyBy YW06IDAgLSAyZDNmZTAwMA0KWyAgICAwLjAwMDAwMF0gICBsb3cgcmFtOiAwIC0gMmQzZmUw MDANClsgICAgMC4wMDAwMDBdIFpvbmUgUEZOIHJhbmdlczoNClsgICAgMC4wMDAwMDBdICAg RE1BICAgICAgMHgwMDAwMDAxMCAtPiAweDAwMDAxMDAwDQpbICAgIDAuMDAwMDAwXSAgIE5v cm1hbCAgIDB4MDAwMDEwMDAgLT4gMHgwMDAyZDNmZQ0KWyAgICAwLjAwMDAwMF0gICBIaWdo TWVtICAweDAwMDJkM2ZlIC0+IDB4MDAxNzU1OTANClsgICAgMC4wMDAwMDBdIE1vdmFibGUg em9uZSBzdGFydCBQRk4gZm9yIGVhY2ggbm9kZQ0KWyAgICAwLjAwMDAwMF0gZWFybHlfbm9k ZV9tYXBbM10gYWN0aXZlIFBGTiByYW5nZXMNClsgICAgMC4wMDAwMDBdICAgICAwOiAweDAw MDAwMDEwIC0+IDB4MDAwMDAwOWINClsgICAgMC4wMDAwMDBdICAgICAwOiAweDAwMDAwMTAw IC0+IDB4MDAwYWZmOTANClsgICAgMC4wMDAwMDBdICAgICAwOiAweDAwMTAwMDAwIC0+IDB4 MDAxNzU1OTANClsgICAgMC4wMDAwMDBdIE9uIG5vZGUgMCB0b3RhbHBhZ2VzOiAxMjAxMzIz DQpbICAgIDAuMDAwMDAwXSBmcmVlX2FyZWFfaW5pdF9ub2RlOiBub2RlIDAsIHBnZGF0IGMx NzMzYjQwLCBub2RlX21lbV9tYXAgZWE1NGQyMDANClsgICAgMC4wMDAwMDBdICAgRE1BIHpv bmU6IDMyIHBhZ2VzIHVzZWQgZm9yIG1lbW1hcA0KWyAgICAwLjAwMDAwMF0gICBETUEgem9u ZTogMCBwYWdlcyByZXNlcnZlZA0KWyAgICAwLjAwMDAwMF0gICBETUEgem9uZTogMzk0NyBw YWdlcywgTElGTyBiYXRjaDowDQpbICAgIDAuMDAwMDAwXSAgIE5vcm1hbCB6b25lOiAxNDE2 IHBhZ2VzIHVzZWQgZm9yIG1lbW1hcA0KWyAgICAwLjAwMDAwMF0gICBOb3JtYWwgem9uZTog MTc5ODMwIHBhZ2VzLCBMSUZPIGJhdGNoOjMxDQpbICAgIDAuMDAwMDAwXSAgIEhpZ2hNZW0g em9uZTogMTA1MDAgcGFnZXMgdXNlZCBmb3IgbWVtbWFwDQpbICAgIDAuMDAwMDAwXSAgIEhp Z2hNZW0gem9uZTogMTAwNTU5OCBwYWdlcywgTElGTyBiYXRjaDozMQ0KWyAgICAwLjAwMDAw MF0gVXNpbmcgQVBJQyBkcml2ZXIgZGVmYXVsdA0KWyAgICAwLjAwMDAwMF0gQUNQSTogUE0t VGltZXIgSU8gUG9ydDogMHg1MDgNClsgICAgMC4wMDAwMDBdIEFDUEk6IExvY2FsIEFQSUMg YWRkcmVzcyAweGZlZTAwMDAwDQpbICAgIDAuMDAwMDAwXSBBQ1BJOiBMQVBJQyAoYWNwaV9p ZFsweDAxXSBsYXBpY19pZFsweDAwXSBlbmFibGVkKQ0KWyAgICAwLjAwMDAwMF0gQklPUyBi dWc6IEFQSUMgdmVyc2lvbiBpcyAwIGZvciBDUFUgMC8weDAsIGZpeGluZyB1cCB0byAweDEw DQpbICAgIDAuMDAwMDAwXSBBQ1BJOiBMQVBJQyAoYWNwaV9pZFsweDAyXSBsYXBpY19pZFsw eDAxXSBlbmFibGVkKQ0KWyAgICAwLjAwMDAwMF0gQUNQSTogTEFQSUMgKGFjcGlfaWRbMHgw M10gbGFwaWNfaWRbMHg4Ml0gZGlzYWJsZWQpDQpbICAgIDAuMDAwMDAwXSBBQ1BJOiBMQVBJ QyAoYWNwaV9pZFsweDA0XSBsYXBpY19pZFsweDgzXSBkaXNhYmxlZCkNClsgICAgMC4wMDAw MDBdIEFDUEk6IExBUElDIChhY3BpX2lkWzB4MDVdIGxhcGljX2lkWzB4ODRdIGRpc2FibGVk KQ0KWyAgICAwLjAwMDAwMF0gQUNQSTogTEFQSUMgKGFjcGlfaWRbMHgwNl0gbGFwaWNfaWRb MHg4NV0gZGlzYWJsZWQpDQpbICAgIDAuMDAwMDAwXSBBQ1BJOiBJT0FQSUMgKGlkWzB4MDJd IGFkZHJlc3NbMHhmZWMwMDAwMF0gZ3NpX2Jhc2VbMF0pDQpbICAgIDAuMDAwMDAwXSBJT0FQ SUNbMF06IGFwaWNfaWQgMiwgdmVyc2lvbiAyNTUsIGFkZHJlc3MgMHhmZWMwMDAwMCwgR1NJ IDAtMjU1DQpbICAgIDAuMDAwMDAwXSBBQ1BJOiBJTlRfU1JDX09WUiAoYnVzIDAgYnVzX2ly cSAwIGdsb2JhbF9pcnEgMiBkZmwgZGZsKQ0KWyAgICAwLjAwMDAwMF0gQUNQSTogSU5UX1NS Q19PVlIgKGJ1cyAwIGJ1c19pcnEgOSBnbG9iYWxfaXJxIDkgaGlnaCBsZXZlbCkNClsgICAg MC4wMDAwMDBdIEFDUEk6IElOVF9TUkNfT1ZSIChidXMgMCBidXNfaXJxIDE0IGdsb2JhbF9p cnEgMTQgaGlnaCBlZGdlKQ0KWyAgICAwLjAwMDAwMF0gQUNQSTogSU5UX1NSQ19PVlIgKGJ1 cyAwIGJ1c19pcnEgMTUgZ2xvYmFsX2lycSAxNSBoaWdoIGVkZ2UpDQpbICAgIDAuMDAwMDAw XSBBQ1BJOiBJUlEwIHVzZWQgYnkgb3ZlcnJpZGUuDQpbICAgIDAuMDAwMDAwXSBBQ1BJOiBJ UlEyIHVzZWQgYnkgb3ZlcnJpZGUuDQpbICAgIDAuMDAwMDAwXSBBQ1BJOiBJUlE5IHVzZWQg Ynkgb3ZlcnJpZGUuDQpbICAgIDAuMDAwMDAwXSBBQ1BJOiBJUlExNCB1c2VkIGJ5IG92ZXJy aWRlLg0KWyAgICAwLjAwMDAwMF0gQUNQSTogSVJRMTUgdXNlZCBieSBvdmVycmlkZS4NClsg ICAgMC4wMDAwMDBdIFVzaW5nIEFDUEkgKE1BRFQpIGZvciBTTVAgY29uZmlndXJhdGlvbiBp bmZvcm1hdGlvbg0KWyAgICAwLjAwMDAwMF0gQUNQSTogSFBFVCBpZDogMHgxMGRlODIwMSBi YXNlOiAweGZlZDAwMDAwDQpbICAgIDAuMDAwMDAwXSBTTVA6IEFsbG93aW5nIDYgQ1BVcywg NCBob3RwbHVnIENQVXMNClsgICAgMC4wMDAwMDBdIG5yX2lycXNfZ3NpOiAyNzINClsgICAg MC4wMDAwMDBdIFBNOiBSZWdpc3RlcmVkIG5vc2F2ZSBtZW1vcnk6IDAwMDAwMDAwMDAwOWIw MDAgLSAwMDAwMDAwMDAwMDljMDAwDQpbICAgIDAuMDAwMDAwXSBQTTogUmVnaXN0ZXJlZCBu b3NhdmUgbWVtb3J5OiAwMDAwMDAwMDAwMDljMDAwIC0gMDAwMDAwMDAwMDEwMDAwMA0KWyAg ICAwLjAwMDAwMF0gQWxsb2NhdGluZyBQQ0kgcmVzb3VyY2VzIHN0YXJ0aW5nIGF0IGIwMDAw MDAwIChnYXA6IGIwMDAwMDAwOjRlYzAwMDAwKQ0KWyAgICAwLjAwMDAwMF0gQm9vdGluZyBw YXJhdmlydHVhbGl6ZWQga2VybmVsIG9uIFhlbg0KWyAgICAwLjAwMDAwMF0gWGVuIHZlcnNp b246IDQuMS4xIChwcmVzZXJ2ZS1BRCkNClsgICAgMC4wMDAwMDBdIHNldHVwX3BlcmNwdTog TlJfQ1BVUzo4IG5yX2NwdW1hc2tfYml0czo4IG5yX2NwdV9pZHM6NiBucl9ub2RlX2lkczox DQpbICAgIDAuMDAwMDAwXSBQRVJDUFU6IEVtYmVkZGVkIDEyIHBhZ2VzL2NwdSBAZWE0ZjMw MDAgczI4MzUyIHIwIGQyMDgwMCB1NDkxNTINClsgICAgMC4wMDAwMDBdIHBjcHUtYWxsb2M6 IHMyODM1MiByMCBkMjA4MDAgdTQ5MTUyIGFsbG9jPTEyKjQwOTYNClsgICAgMC4wMDAwMDBd IHBjcHUtYWxsb2M6IFswXSAwIFswXSAxIFswXSAyIFswXSAzIFswXSA0IFswXSA1IA0KWyAg ICAwLjAwMDAwMF0gQnVpbHQgMSB6b25lbGlzdHMgaW4gWm9uZSBvcmRlciwgbW9iaWxpdHkg Z3JvdXBpbmcgb24uICBUb3RhbCBwYWdlczogMTE4OTM3NQ0KWyAgICAwLjAwMDAwMF0gS2Vy bmVsIGNvbW1hbmQgbGluZTogYm9vdF9tZWRpYT1sb29wLWRpc2sgYm9vdF92b2x1bWU9Ii9k ZXYvc2Q/MSIgYm9vdF92b2x1bWVfaWQ9NTllMDY5MTAzYzkyNjE5MSBib290X21vZGU9c2V0 dXAtYXV0b21hdGljIGRlYnVnIGxvZ2xldmVsPTkgY29uc29sZT1odmMwIGluaXRjYWxsX2Rl YnVnDQpbICAgIDAuMDAwMDAwXSBQSUQgaGFzaCB0YWJsZSBlbnRyaWVzOiA0MDk2IChvcmRl cjogMiwgMTYzODQgYnl0ZXMpDQpbICAgIDAuMDAwMDAwXSBEZW50cnkgY2FjaGUgaGFzaCB0 YWJsZSBlbnRyaWVzOiAxMzEwNzIgKG9yZGVyOiA3LCA1MjQyODggYnl0ZXMpDQpbICAgIDAu MDAwMDAwXSBJbm9kZS1jYWNoZSBoYXNoIHRhYmxlIGVudHJpZXM6IDY1NTM2IChvcmRlcjog NiwgMjYyMTQ0IGJ5dGVzKQ0KWyAgICAwLjAwMDAwMF0gSW5pdGlhbGl6aW5nIENQVSMwDQpb ICAgIDAuMDAwMDAwXSBhbGxvY2F0ZWQgMjQ0Njc0NTYgYnl0ZXMgb2YgcGFnZV9jZ3JvdXAN ClsgICAgMC4wMDAwMDBdIHBsZWFzZSB0cnkgJ2Nncm91cF9kaXNhYmxlPW1lbW9yeScgb3B0 aW9uIGlmIHlvdSBkb24ndCB3YW50IG1lbW9yeSBjZ3JvdXBzDQpbICAgIDAuMDAwMDAwXSBQ bGFjaW5nIDY0TUIgc29mdHdhcmUgSU8gVExCIGJldHdlZW4gZTRjZDkwMDAgLSBlOGNkOTAw MA0KWyAgICAwLjAwMDAwMF0gc29mdHdhcmUgSU8gVExCIGF0IHBoeXMgMHgyNGNkOTAwMCAt IDB4MjhjZDkwMDANClsgICAgMC4wMDAwMDBdIEluaXRpYWxpemluZyBIaWdoTWVtIGZvciBu b2RlIDAgKDAwMDJkM2ZlOjAwMTc1NTkwKQ0KWyAgICAwLjAwMDAwMF0gTWVtb3J5OiAyNzIw NDE2ay82MTE2OTI4ayBhdmFpbGFibGUgKDUwNzdrIGtlcm5lbCBjb2RlLCAxNjIyNTJrIHJl c2VydmVkLCAyMzM0ayBkYXRhLCA2NzZrIGluaXQsIDIxNDE3NjhrIGhpZ2htZW0pDQpbICAg IDAuMDAwMDAwXSB2aXJ0dWFsIGtlcm5lbCBtZW1vcnkgbGF5b3V0Og0KWyAgICAwLjAwMDAw MF0gICAgIGZpeG1hcCAgOiAweGY1NzE2MDAwIC0gMHhmNTdmZjAwMCAgICggOTMyIGtCKQ0K WyAgICAwLjAwMDAwMF0gICAgIHBrbWFwICAgOiAweGY1NDAwMDAwIC0gMHhmNTYwMDAwMCAg ICgyMDQ4IGtCKQ0KWyAgICAwLjAwMDAwMF0gICAgIHZtYWxsb2MgOiAweGVkYmZlMDAwIC0g MHhmNTNmZTAwMCAgICggMTIwIE1CKQ0KWyAgICAwLjAwMDAwMF0gICAgIGxvd21lbSAgOiAw eGMwMDAwMDAwIC0gMHhlZDNmZTAwMCAgICggNzIzIE1CKQ0KWyAgICAwLjAwMDAwMF0gICAg ICAgLmluaXQgOiAweGMxNzNlMDAwIC0gMHhjMTdlNzAwMCAgICggNjc2IGtCKQ0KWyAgICAw LjAwMDAwMF0gICAgICAgLmRhdGEgOiAweGMxNGY1NjIwIC0gMHhjMTczZDE4MCAgICgyMzM0 IGtCKQ0KWyAgICAwLjAwMDAwMF0gICAgICAgLnRleHQgOiAweGMxMDAwMDAwIC0gMHhjMTRm NTYyMCAgICg1MDc3IGtCKQ0KWyAgICAwLjAwMDAwMF0gU0xVQjogR2Vuc2xhYnM9MTUsIEhX YWxpZ249NjQsIE9yZGVyPTAtMywgTWluT2JqZWN0cz0wLCBDUFVzPTYsIE5vZGVzPTENClsg ICAgMC4wMDAwMDBdIEhpZXJhcmNoaWNhbCBSQ1UgaW1wbGVtZW50YXRpb24uDQpbICAgIDAu MDAwMDAwXSAJUkNVIGR5bnRpY2staWRsZSBncmFjZS1wZXJpb2QgYWNjZWxlcmF0aW9uIGlz IGVuYWJsZWQuDQpbICAgIDAuMDAwMDAwXSBOUl9JUlFTOjIzMDQgbnJfaXJxczoxNTM2IDE2 DQpbICAgIDAuMDAwMDAwXSBDUFUgMCBpcnFzdGFja3MsIGhhcmQ9ZTQ4MTgwMDAgc29mdD1l NDgxYTAwMA0KWyAgICAwLjAwMDAwMF0geGVuOiBzY2kgb3ZlcnJpZGU6IGdsb2JhbF9pcnE9 OSB0cmlnZ2VyPTAgcG9sYXJpdHk9MA0KWyAgICAwLjAwMDAwMF0geGVuOiByZWdpc3Rlcmlu ZyBnc2kgOSB0cmlnZ2VyaW5nIDAgcG9sYXJpdHkgMA0KWyAgICAwLjAwMDAwMF0geGVuOiAt LT4gcGlycT05IC0+IGlycT05IChnc2k9OSkNClsgICAgMC4wMDAwMDBdIHhlbjogYWNwaSBz Y2kgOQ0KWyAgICAwLjAwMDAwMF0geGVuOiAtLT4gcGlycT0xIC0+IGlycT0xIChnc2k9MSkN ClsgICAgMC4wMDAwMDBdIHhlbjogLS0+IHBpcnE9MiAtPiBpcnE9MiAoZ3NpPTIpDQpbICAg IDAuMDAwMDAwXSB4ZW46IC0tPiBwaXJxPTMgLT4gaXJxPTMgKGdzaT0zKQ0KWyAgICAwLjAw MDAwMF0geGVuOiAtLT4gcGlycT00IC0+IGlycT00IChnc2k9NCkNClsgICAgMC4wMDAwMDBd IHhlbjogLS0+IHBpcnE9NSAtPiBpcnE9NSAoZ3NpPTUpDQpbICAgIDAuMDAwMDAwXSB4ZW46 IC0tPiBwaXJxPTYgLT4gaXJxPTYgKGdzaT02KQ0KWyAgICAwLjAwMDAwMF0geGVuOiAtLT4g cGlycT03IC0+IGlycT03IChnc2k9NykNClsgICAgMC4wMDAwMDBdIHhlbjogLS0+IHBpcnE9 OCAtPiBpcnE9OCAoZ3NpPTgpDQpbICAgIDAuMDAwMDAwXSB4ZW5fbWFwX3BpcnFfZ3NpOiBy ZXR1cm5pbmcgaXJxIDkgZm9yIGdzaSA5DQpbICAgIDAuMDAwMDAwXSB4ZW46IC0tPiBwaXJx PTkgLT4gaXJxPTkgKGdzaT05KQ0KWyAgICAwLjAwMDAwMF0geGVuOiAtLT4gcGlycT0xMCAt PiBpcnE9MTAgKGdzaT0xMCkNClsgICAgMC4wMDAwMDBdIHhlbjogLS0+IHBpcnE9MTEgLT4g aXJxPTExIChnc2k9MTEpDQpbICAgIDAuMDAwMDAwXSB4ZW46IC0tPiBwaXJxPTEyIC0+IGly cT0xMiAoZ3NpPTEyKQ0KWyAgICAwLjAwMDAwMF0geGVuOiAtLT4gcGlycT0xMyAtPiBpcnE9 MTMgKGdzaT0xMykNClsgICAgMC4wMDAwMDBdIHhlbjogLS0+IHBpcnE9MTQgLT4gaXJxPTE0 IChnc2k9MTQpDQpbICAgIDAuMDAwMDAwXSB4ZW46IC0tPiBwaXJxPTE1IC0+IGlycT0xNSAo Z3NpPTE1KQ0KWyAgICAwLjAwMDAwMF0gQ29uc29sZTogY29sb3VyIFZHQSsgODB4MjUNClsg ICAgMC4wMDAwMDBdIGNvbnNvbGUgW2h2YzBdIGVuYWJsZWQNClsgICAgMC4wMDAwMDBdIFhl bjogdXNpbmcgdmNwdW9wIHRpbWVyIGludGVyZmFjZQ0KWyAgICAwLjAwMDAwMF0gaW5zdGFs bGluZyBYZW4gdGltZXIgZm9yIENQVSAwDQpbICAgIDAuMDAwMDAwXSBEZXRlY3RlZCAzMDEz Ljc1MCBNSHogcHJvY2Vzc29yLg0KWyAgICAwLjAwNDAwMF0gQ2FsaWJyYXRpbmcgZGVsYXkg bG9vcCAoc2tpcHBlZCksIHZhbHVlIGNhbGN1bGF0ZWQgdXNpbmcgdGltZXIgZnJlcXVlbmN5 Li4gNjAyNy41MCBCb2dvTUlQUyAobHBqPTEyMDU1MDAwKQ0KWyAgICAwLjAwNDAwMF0gcGlk X21heDogZGVmYXVsdDogMzI3NjggbWluaW11bTogMzAxDQpbICAgIDAuMDA0MDAwXSBNb3Vu dC1jYWNoZSBoYXNoIHRhYmxlIGVudHJpZXM6IDUxMg0KWyAgICAwLjAwNDAwMF0gSW5pdGlh bGl6aW5nIGNncm91cCBzdWJzeXMgY3B1YWNjdA0KWyAgICAwLjAwNDAwMF0gSW5pdGlhbGl6 aW5nIGNncm91cCBzdWJzeXMgbWVtb3J5DQpbICAgIDAuMDA0MDAwXSBJbml0aWFsaXppbmcg Y2dyb3VwIHN1YnN5cyBkZXZpY2VzDQpbICAgIDAuMDA0MDAwXSBJbml0aWFsaXppbmcgY2dy b3VwIHN1YnN5cyBmcmVlemVyDQpbICAgIDAuMDA0MDAwXSBJbml0aWFsaXppbmcgY2dyb3Vw IHN1YnN5cyBuZXRfY2xzDQpbICAgIDAuMDA0MDAwXSBJbml0aWFsaXppbmcgY2dyb3VwIHN1 YnN5cyBibGtpbw0KWyAgICAwLjAwNDAwMF0gQ1BVOiBQaHlzaWNhbCBQcm9jZXNzb3IgSUQ6 IDANClsgICAgMC4wMDQwMDBdIENQVTogUHJvY2Vzc29yIENvcmUgSUQ6IDANClsgICAgMC4w MDQwMDBdIEFDUEk6IENvcmUgcmV2aXNpb24gMjAxMTA0MTMNClsgICAgMC4wMTIwMDBdIGZ0 cmFjZTogYWxsb2NhdGluZyAyMTMyMCBlbnRyaWVzIGluIDQyIHBhZ2VzDQpbICAgIDAuMDE2 MTA2XSBjcHUgMCBzcGlubG9jayBldmVudCBpcnEgMjczDQpbICAgIDAuMDE2MTU0XSBjYWxs aW5nICB0cmFjZV9pbml0X2ZsYWdzX3N5c19leGl0KzB4MC8weDExIEAgMQ0KWyAgICAwLjAx NjE2Nl0gaW5pdGNhbGwgdHJhY2VfaW5pdF9mbGFnc19zeXNfZXhpdCsweDAvMHgxMSByZXR1 cm5lZCAwIGFmdGVyIDAgdXNlY3MNClsgICAgMC4wMTYxODBdIGNhbGxpbmcgIHRyYWNlX2lu aXRfZmxhZ3Nfc3lzX2VudGVyKzB4MC8weDExIEAgMQ0KWyAgICAwLjAxNjE5Ml0gaW5pdGNh bGwgdHJhY2VfaW5pdF9mbGFnc19zeXNfZW50ZXIrMHgwLzB4MTEgcmV0dXJuZWQgMCBhZnRl ciAwIHVzZWNzDQpbICAgIDAuMDE2MjA2XSBjYWxsaW5nICBpbml0X2h3X3BlcmZfZXZlbnRz KzB4MC8weGVmOCBAIDENClsgICAgMC4wMTYyMTVdIFBlcmZvcm1hbmNlIEV2ZW50czogKFhF TikgdHJhcHMuYzoyMzg4OmQwIERvbWFpbiBhdHRlbXB0ZWQgV1JNU1IgYzAwMTAwMDQgZnJv bSAweDAwMDA5YjI3ZjY5NzIyZGEgdG8gMHgwMDAwMDAwMDAwMDBhYmNkLgpCcm9rZW4gUE1V IGhhcmR3YXJlIGRldGVjdGVkLCB1c2luZyBzb2Z0d2FyZSBldmVudHMgb25seS4NClsgICAg MC4wMTYyNDVdIGluaXRjYWxsIGluaXRfaHdfcGVyZl9ldmVudHMrMHgwLzB4ZWY4IHJldHVy bmVkIDAgYWZ0ZXIgMCB1c2Vjcw0KWyAgICAwLjAxNjI1OF0gY2FsbGluZyAgbWlncmF0aW9u X2luaXQrMHgwLzB4NWIgQCAxDQpbICAgIDAuMDE2MjcxXSBpbml0Y2FsbCBtaWdyYXRpb25f aW5pdCsweDAvMHg1YiByZXR1cm5lZCAwIGFmdGVyIDAgdXNlY3MNClsgICAgMC4wMTYyODNd IGNhbGxpbmcgIHNwYXduX2tzb2Z0aXJxZCsweDAvMHg0NSBAIDENClsgICAgMC4wMTYzMjBd IGluaXRjYWxsIHNwYXduX2tzb2Z0aXJxZCsweDAvMHg0NSByZXR1cm5lZCAwIGFmdGVyIDAg dXNlY3MNClsgICAgMC4wMTYzMzNdIGNhbGxpbmcgIGluaXRfd29ya3F1ZXVlcysweDAvMHgy ODcgQCAxDQpbICAgIDAuMDE2NDA5XSBpbml0Y2FsbCBpbml0X3dvcmtxdWV1ZXMrMHgwLzB4 Mjg3IHJldHVybmVkIDAgYWZ0ZXIgMCB1c2Vjcw0KWyAgICAwLjAxNjQyMl0gY2FsbGluZyAg Y3B1X3N0b3BfaW5pdCsweDAvMHg4MyBAIDENClsgICAgMC4wMTY0NTldIGluaXRjYWxsIGNw dV9zdG9wX2luaXQrMHgwLzB4ODMgcmV0dXJuZWQgMCBhZnRlciAwIHVzZWNzDQpbICAgIDAu MDE2NDcyXSBjYWxsaW5nICByY3Vfc2NoZWR1bGVyX3JlYWxseV9zdGFydGVkKzB4MC8weDEx IEAgMQ0KWyAgICAwLjAxNjQ4NV0gaW5pdGNhbGwgcmN1X3NjaGVkdWxlcl9yZWFsbHlfc3Rh cnRlZCsweDAvMHgxMSByZXR1cm5lZCAwIGFmdGVyIDAgdXNlY3MNClsgICAgMC4wMTY0OTld IGNhbGxpbmcgIHJlbGF5X2luaXQrMHgwLzB4MTEgQCAxDQpbICAgIDAuMDE2NTA5XSBpbml0 Y2FsbCByZWxheV9pbml0KzB4MC8weDExIHJldHVybmVkIDAgYWZ0ZXIgMCB1c2Vjcw0KWyAg ICAwLjAxNjUyMV0gY2FsbGluZyAgdHJhY2VyX2FsbG9jX2J1ZmZlcnMrMHgwLzB4MThiIEAg MQ0KWyAgICAwLjAxNjU4MV0gaW5pdGNhbGwgdHJhY2VyX2FsbG9jX2J1ZmZlcnMrMHgwLzB4 MThiIHJldHVybmVkIDAgYWZ0ZXIgMCB1c2Vjcw0KWyAgICAwLjAxNjU5NV0gY2FsbGluZyAg aW5pdF90cmFjZV9wcmludGsrMHgwLzB4ZiBAIDENClsgICAgMC4wMTY2MDZdIGluaXRjYWxs IGluaXRfdHJhY2VfcHJpbnRrKzB4MC8weGYgcmV0dXJuZWQgMCBhZnRlciAwIHVzZWNzDQpb ICAgIDAuMDE2Njg2XSBDUFUgMSBpcnFzdGFja3MsIGhhcmQ9ZTQ4YjAwMDAgc29mdD1lNDhi MjAwMA0KWyAgICAwLjAxNjY5OF0gaW5zdGFsbGluZyBYZW4gdGltZXIgZm9yIENQVSAxDQpb ICAgIDAuMDE2NzE1XSBjcHUgMSBzcGlubG9jayBldmVudCBpcnEgMjc5DQpbICAgIDAuMDA0 MDAwXSBJbml0aWFsaXppbmcgQ1BVIzENClsgICAgMC4wMTY4NTldIEJyb3VnaHQgdXAgMiBD UFVzDQpbICAgIDAuMDE2OTQ5XSBkZXZ0bXBmczogaW5pdGlhbGl6ZWQNClsgICAgMC4wMTY5 NDldIGNhbGxpbmcgIGluaXRfbW1hcF9taW5fYWRkcisweDAvMHgxMSBAIDENClsgICAgMC4w MTY5NDldIGluaXRjYWxsIGluaXRfbW1hcF9taW5fYWRkcisweDAvMHgxMSByZXR1cm5lZCAw IGFmdGVyIDAgdXNlY3MNClsgICAgMC4wMTY5NDldIGNhbGxpbmcgIGluaXRfY3B1ZnJlcV90 cmFuc2l0aW9uX25vdGlmaWVyX2xpc3QrMHgwLzB4MTggQCAxDQpbICAgIDAuMDE2OTQ5XSBp bml0Y2FsbCBpbml0X2NwdWZyZXFfdHJhbnNpdGlvbl9ub3RpZmllcl9saXN0KzB4MC8weDE4 IHJldHVybmVkIDAgYWZ0ZXIgMCB1c2Vjcw0KWyAgICAwLjAxNjk0OV0gY2FsbGluZyAgbmV0 X25zX2luaXQrMHgwLzB4ZWQgQCAxDQpbICAgIDAuMDE2OTQ5XSBpbml0Y2FsbCBuZXRfbnNf aW5pdCsweDAvMHhlZCByZXR1cm5lZCAwIGFmdGVyIDAgdXNlY3MNClsgICAgMC4wMTY5NDld IGNhbGxpbmcgIGU4MjBfbWFya19udnNfbWVtb3J5KzB4MC8weDMzIEAgMQ0KWyAgICAwLjAx Njk0OV0gUE06IFJlZ2lzdGVyaW5nIEFDUEkgTlZTIHJlZ2lvbiBhdCBhZmY5ZTAwMCAoMjcw MzM2IGJ5dGVzKQ0KWyAgICAwLjAxNjk0OV0gaW5pdGNhbGwgZTgyMF9tYXJrX252c19tZW1v cnkrMHgwLzB4MzMgcmV0dXJuZWQgMCBhZnRlciAwIHVzZWNzDQpbICAgIDAuMDE2OTQ5XSBj YWxsaW5nICBjcHVmcmVxX3RzYysweDAvMHgyNiBAIDENClsgICAgMC4wMTY5NDldIGluaXRj YWxsIGNwdWZyZXFfdHNjKzB4MC8weDI2IHJldHVybmVkIDAgYWZ0ZXIgMCB1c2Vjcw0KWyAg ICAwLjAxNjk0OV0gY2FsbGluZyAgcGNpX3JlYm9vdF9pbml0KzB4MC8weDExIEAgMQ0KWyAg ICAwLjAxNjk0OV0gaW5pdGNhbGwgcGNpX3JlYm9vdF9pbml0KzB4MC8weDExIHJldHVybmVk IDAgYWZ0ZXIgMCB1c2Vjcw0KWyAgICAwLjAxNjk0OV0gY2FsbGluZyAgcmVib290X2luaXQr MHgwLzB4MTEgQCAxDQpbICAgIDAuMDE2OTQ5XSBpbml0Y2FsbCByZWJvb3RfaW5pdCsweDAv MHgxMSByZXR1cm5lZCAwIGFmdGVyIDAgdXNlY3MNClsgICAgMC4wMTY5NDldIGNhbGxpbmcg IGluaXRfbGFwaWNfc3lzZnMrMHgwLzB4MWIgQCAxDQpbICAgIDAuMDE2OTQ5XSBpbml0Y2Fs bCBpbml0X2xhcGljX3N5c2ZzKzB4MC8weDFiIHJldHVybmVkIDAgYWZ0ZXIgMCB1c2Vjcw0K WyAgICAwLjAxNjk0OV0gY2FsbGluZyAgaW5pdF9zbXBfZmx1c2grMHgwLzB4MmMgQCAxDQpb ICAgIDAuMDE2OTQ5XSBpbml0Y2FsbCBpbml0X3NtcF9mbHVzaCsweDAvMHgyYyByZXR1cm5l ZCAwIGFmdGVyIDAgdXNlY3MNClsgICAgMC4wMTY5NDldIGNhbGxpbmcgIGFsbG9jX2Zyb3pl bl9jcHVzKzB4MC8weDEwIEAgMQ0KWyAgICAwLjAxNjk0OV0gaW5pdGNhbGwgYWxsb2NfZnJv emVuX2NwdXMrMHgwLzB4MTAgcmV0dXJuZWQgMCBhZnRlciAwIHVzZWNzDQpbICAgIDAuMDE2 OTQ5XSBjYWxsaW5nICBzeXNjdGxfaW5pdCsweDAvMHgyOSBAIDENClsgICAgMC4wMTY5NDld IGluaXRjYWxsIHN5c2N0bF9pbml0KzB4MC8weDI5IHJldHVybmVkIDAgYWZ0ZXIgMCB1c2Vj cw0KWyAgICAwLjAxNjk0OV0gY2FsbGluZyAga3N5c2ZzX2luaXQrMHgwLzB4NzQgQCAxDQpb ICAgIDAuMDE2OTQ5XSBpbml0Y2FsbCBrc3lzZnNfaW5pdCsweDAvMHg3NCByZXR1cm5lZCAw IGFmdGVyIDAgdXNlY3MNClsgICAgMC4wMTY5NDldIGNhbGxpbmcgIGluaXRfamlmZmllc19j bG9ja3NvdXJjZSsweDAvMHhmIEAgMQ0KWyAgICAwLjAxNjk0OV0gaW5pdGNhbGwgaW5pdF9q aWZmaWVzX2Nsb2Nrc291cmNlKzB4MC8weGYgcmV0dXJuZWQgMCBhZnRlciAwIHVzZWNzDQpb ICAgIDAuMDE2OTQ5XSBjYWxsaW5nICBwbV9pbml0KzB4MC8weDYxIEAgMQ0KWyAgICAwLjAx Njk0OV0gaW5pdGNhbGwgcG1faW5pdCsweDAvMHg2MSByZXR1cm5lZCAwIGFmdGVyIDAgdXNl Y3MNClsgICAgMC4wMTY5NDldIGNhbGxpbmcgIHBtX2Rpc2tfaW5pdCsweDAvMHgxNCBAIDEN ClsgICAgMC4wMTY5NDldIGluaXRjYWxsIHBtX2Rpc2tfaW5pdCsweDAvMHgxNCByZXR1cm5l ZCAwIGFmdGVyIDAgdXNlY3MNClsgICAgMC4wMTY5NDldIGNhbGxpbmcgIHN3c3VzcF9oZWFk ZXJfaW5pdCsweDAvMHgzMCBAIDENClsgICAgMC4wMTY5NDldIGluaXRjYWxsIHN3c3VzcF9o ZWFkZXJfaW5pdCsweDAvMHgzMCByZXR1cm5lZCAwIGFmdGVyIDAgdXNlY3MNClsgICAgMC4w MTY5NDldIGNhbGxpbmcgIGluaXRfZnRyYWNlX3N5c2NhbGxzKzB4MC8weDZmIEAgMQ0KWyAg ICAwLjAxNzA1Ml0gaW5pdGNhbGwgaW5pdF9mdHJhY2Vfc3lzY2FsbHMrMHgwLzB4NmYgcmV0 dXJuZWQgMCBhZnRlciAwIHVzZWNzDQpbICAgIDAuMDE3MDY0XSBjYWxsaW5nICBpbml0X3pl cm9fcGZuKzB4MC8weDE0IEAgMQ0KWyAgICAwLjAxNzA3NV0gaW5pdGNhbGwgaW5pdF96ZXJv X3BmbisweDAvMHgxNCByZXR1cm5lZCAwIGFmdGVyIDAgdXNlY3MNClsgICAgMC4wMTcwODdd IGNhbGxpbmcgIGZzbm90aWZ5X2luaXQrMHgwLzB4MjQgQCAxDQpbICAgIDAuMDE3MDk4XSBp bml0Y2FsbCBmc25vdGlmeV9pbml0KzB4MC8weDI0IHJldHVybmVkIDAgYWZ0ZXIgMCB1c2Vj cw0KWyAgICAwLjAxNzExMF0gY2FsbGluZyAgZmlsZWxvY2tfaW5pdCsweDAvMHgyZiBAIDEN ClsgICAgMC4wMTcxMjNdIGluaXRjYWxsIGZpbGVsb2NrX2luaXQrMHgwLzB4MmYgcmV0dXJu ZWQgMCBhZnRlciAwIHVzZWNzDQpbICAgIDAuMDE3MTM1XSBjYWxsaW5nICBpbml0X3Njcmlw dF9iaW5mbXQrMHgwLzB4MTEgQCAxDQpbICAgIDAuMDE3MTQ1XSBpbml0Y2FsbCBpbml0X3Nj cmlwdF9iaW5mbXQrMHgwLzB4MTEgcmV0dXJuZWQgMCBhZnRlciAwIHVzZWNzDQpbICAgIDAu MDE3MTU3XSBjYWxsaW5nICBpbml0X2VsZl9iaW5mbXQrMHgwLzB4MTEgQCAxDQpbICAgIDAu MDE3MTY3XSBpbml0Y2FsbCBpbml0X2VsZl9iaW5mbXQrMHgwLzB4MTEgcmV0dXJuZWQgMCBh ZnRlciAwIHVzZWNzDQpbICAgIDAuMDE3MTc5XSBjYWxsaW5nICBkZWJ1Z2ZzX2luaXQrMHgw LzB4NGEgQCAxDQpbICAgIDAuMDE3MTkyXSBpbml0Y2FsbCBkZWJ1Z2ZzX2luaXQrMHgwLzB4 NGEgcmV0dXJuZWQgMCBhZnRlciAwIHVzZWNzDQpbICAgIDAuMDE3MjA0XSBjYWxsaW5nICBz ZWN1cml0eWZzX2luaXQrMHgwLzB4NDEgQCAxDQpbICAgIDAuMDE3MjE2XSBpbml0Y2FsbCBz ZWN1cml0eWZzX2luaXQrMHgwLzB4NDEgcmV0dXJuZWQgMCBhZnRlciAwIHVzZWNzDQpbICAg IDAuMDE3MjI4XSBjYWxsaW5nICByYW5kb20zMl9pbml0KzB4MC8weGE4IEAgMQ0KWyAgICAw LjAxNzIzOV0gaW5pdGNhbGwgcmFuZG9tMzJfaW5pdCsweDAvMHhhOCByZXR1cm5lZCAwIGFm dGVyIDAgdXNlY3MNClsgICAgMC4wMTcyNTFdIGNhbGxpbmcgIHNmaV9zeXNmc19pbml0KzB4 MC8weGJlIEAgMQ0KWyAgICAwLjAxNzI2MV0gaW5pdGNhbGwgc2ZpX3N5c2ZzX2luaXQrMHgw LzB4YmUgcmV0dXJuZWQgMCBhZnRlciAwIHVzZWNzDQpbICAgIDAuMDE3Mjc1XSBjYWxsaW5n ICB2aXJ0aW9faW5pdCsweDAvMHgzMCBAIDENClsgICAgMC4wMTcyOTBdIGluaXRjYWxsIHZp cnRpb19pbml0KzB4MC8weDMwIHJldHVybmVkIDAgYWZ0ZXIgMCB1c2Vjcw0KWyAgICAwLjAx NzMwMl0gY2FsbGluZyAgX19nbnR0YWJfaW5pdCsweDAvMHgyMSBAIDENClsgICAgMC4wMTcz MjZdIEdyYW50IHRhYmxlIGluaXRpYWxpemVkDQpbICAgIDAuMDE3MzM1XSBpbml0Y2FsbCBf X2dudHRhYl9pbml0KzB4MC8weDIxIHJldHVybmVkIDAgYWZ0ZXIgMCB1c2Vjcw0KWyAgICAw LjAxNzM0N10gY2FsbGluZyAgcmVndWxhdG9yX2luaXQrMHgwLzB4NWUgQCAxDQpbICAgIDAu MDE3Mzk3XSBwcmludF9jb25zdHJhaW50czogZHVtbXk6IA0KWyAgICAwLjAxNzQxMV0gaW5p dGNhbGwgcmVndWxhdG9yX2luaXQrMHgwLzB4NWUgcmV0dXJuZWQgMCBhZnRlciAwIHVzZWNz DQpbICAgIDAuMDE3NDI1XSBjYWxsaW5nICBlYXJseV9yZXN1bWVfaW5pdCsweDAvMHgxYjAg QCAxDQpbICAgIDAuMDE3NDc1XSBUaW1lOiAxNDozNDoyNCAgRGF0ZTogMDkvMjMvMTENClsg ICAgMC4wMTc0ODRdIGluaXRjYWxsIGVhcmx5X3Jlc3VtZV9pbml0KzB4MC8weDFiMCByZXR1 cm5lZCAwIGFmdGVyIDAgdXNlY3MNClsgICAgMC4wMTc0OTZdIGNhbGxpbmcgIGNwdWZyZXFf Y29yZV9pbml0KzB4MC8weDg0IEAgMQ0KWyAgICAwLjAxNzUwOF0gaW5pdGNhbGwgY3B1ZnJl cV9jb3JlX2luaXQrMHgwLzB4ODQgcmV0dXJuZWQgMCBhZnRlciAwIHVzZWNzDQpbICAgIDAu MDE3NTIwXSBjYWxsaW5nICBjcHVpZGxlX2luaXQrMHgwLzB4MzIgQCAxDQpbICAgIDAuMDE3 NTMzXSBpbml0Y2FsbCBjcHVpZGxlX2luaXQrMHgwLzB4MzIgcmV0dXJuZWQgMCBhZnRlciAw IHVzZWNzDQpbICAgIDAuMDE3NTQ1XSBjYWxsaW5nICBzb2NrX2luaXQrMHgwLzB4NzggQCAx DQpbICAgIDAuMDE3NTc2XSBpbml0Y2FsbCBzb2NrX2luaXQrMHgwLzB4NzggcmV0dXJuZWQg MCBhZnRlciAwIHVzZWNzDQpbICAgIDAuMDE3NTg4XSBjYWxsaW5nICBuZXRfaW51c2VfaW5p dCsweDAvMHgyNCBAIDENClsgICAgMC4wMTc2MDBdIGluaXRjYWxsIG5ldF9pbnVzZV9pbml0 KzB4MC8weDI0IHJldHVybmVkIDAgYWZ0ZXIgMCB1c2Vjcw0KWyAgICAwLjAxNzYxMl0gY2Fs bGluZyAgbmV0cG9sbF9pbml0KzB4MC8weDJmIEAgMQ0KWyAgICAwLjAxNzYyMl0gaW5pdGNh bGwgbmV0cG9sbF9pbml0KzB4MC8weDJmIHJldHVybmVkIDAgYWZ0ZXIgMCB1c2Vjcw0KWyAg ICAwLjAxNzYzNF0gY2FsbGluZyAgbmV0bGlua19wcm90b19pbml0KzB4MC8weDE3YiBAIDEN ClsgICAgMC4wMTc2NDddIE5FVDogUmVnaXN0ZXJlZCBwcm90b2NvbCBmYW1pbHkgMTYNClsg ICAgMC4wMTc2NjRdIGluaXRjYWxsIG5ldGxpbmtfcHJvdG9faW5pdCsweDAvMHgxN2IgcmV0 dXJuZWQgMCBhZnRlciAwIHVzZWNzDQpbICAgIDAuMDE3Njc2XSBjYWxsaW5nICBiZGlfY2xh c3NfaW5pdCsweDAvMHg0MCBAIDENClsgICAgMC4wMTc2OTFdIGluaXRjYWxsIGJkaV9jbGFz c19pbml0KzB4MC8weDQwIHJldHVybmVkIDAgYWZ0ZXIgMCB1c2Vjcw0KWyAgICAwLjAxNzcw M10gY2FsbGluZyAga29iamVjdF91ZXZlbnRfaW5pdCsweDAvMHgxZSBAIDENClsgICAgMC4w MTc3MTVdIGluaXRjYWxsIGtvYmplY3RfdWV2ZW50X2luaXQrMHgwLzB4MWUgcmV0dXJuZWQg MCBhZnRlciAwIHVzZWNzDQpbICAgIDAuMDE3NzI2XSBjYWxsaW5nICBncGlvbGliX3N5c2Zz X2luaXQrMHgwLzB4NjYgQCAxDQpbICAgIDAuMDE3NzQ0XSBpbml0Y2FsbCBncGlvbGliX3N5 c2ZzX2luaXQrMHgwLzB4NjYgcmV0dXJuZWQgMCBhZnRlciAwIHVzZWNzDQpbICAgIDAuMDE3 NzU1XSBjYWxsaW5nICBwY2lidXNfY2xhc3NfaW5pdCsweDAvMHgxNCBAIDENClsgICAgMC4w MTc3NjldIGluaXRjYWxsIHBjaWJ1c19jbGFzc19pbml0KzB4MC8weDE0IHJldHVybmVkIDAg YWZ0ZXIgMCB1c2Vjcw0KWyAgICAwLjAxNzc4MV0gY2FsbGluZyAgcGNpX2RyaXZlcl9pbml0 KzB4MC8weGYgQCAxDQpbICAgIDAuMDE3Nzk3XSBpbml0Y2FsbCBwY2lfZHJpdmVyX2luaXQr MHgwLzB4ZiByZXR1cm5lZCAwIGFmdGVyIDAgdXNlY3MNClsgICAgMC4wMTc4MDldIGNhbGxp bmcgIGJhY2tsaWdodF9jbGFzc19pbml0KzB4MC8weDUzIEAgMQ0KWyAgICAwLjAxNzgyNF0g aW5pdGNhbGwgYmFja2xpZ2h0X2NsYXNzX2luaXQrMHgwLzB4NTMgcmV0dXJuZWQgMCBhZnRl ciAwIHVzZWNzDQpbICAgIDAuMDE3ODM3XSBjYWxsaW5nICB2aWRlb19vdXRwdXRfY2xhc3Nf aW5pdCsweDAvMHgxNCBAIDENClsgICAgMC4wMTc4NTBdIGluaXRjYWxsIHZpZGVvX291dHB1 dF9jbGFzc19pbml0KzB4MC8weDE0IHJldHVybmVkIDAgYWZ0ZXIgMCB1c2Vjcw0KWyAgICAw LjAxNzg2NF0gY2FsbGluZyAgeGVuYnVzX2luaXQrMHgwLzB4MjUwIEAgMQ0KWyAgICAwLjAx NzkxN10gaW5pdGNhbGwgeGVuYnVzX2luaXQrMHgwLzB4MjUwIHJldHVybmVkIDAgYWZ0ZXIg MCB1c2Vjcw0KWyAgICAwLjAxNzkxN10gY2FsbGluZyAgdHR5X2NsYXNzX2luaXQrMHgwLzB4 MmYgQCAxDQpbICAgIDAuMDE3OTE3XSBpbml0Y2FsbCB0dHlfY2xhc3NfaW5pdCsweDAvMHgy ZiByZXR1cm5lZCAwIGFmdGVyIDAgdXNlY3MNClsgICAgMC4wMTc5MTddIGNhbGxpbmcgIHZ0 Y29uc29sZV9jbGFzc19pbml0KzB4MC8weGMyIEAgMQ0KWyAgICAwLjAxNzkxN10gaW5pdGNh bGwgdnRjb25zb2xlX2NsYXNzX2luaXQrMHgwLzB4YzIgcmV0dXJuZWQgMCBhZnRlciAwIHVz ZWNzDQpbICAgIDAuMDE3OTE3XSBjYWxsaW5nICB3YWtldXBfc291cmNlc19kZWJ1Z2ZzX2lu aXQrMHgwLzB4MmYgQCAxDQpbICAgIDAuMDE3OTE3XSBpbml0Y2FsbCB3YWtldXBfc291cmNl c19kZWJ1Z2ZzX2luaXQrMHgwLzB4MmYgcmV0dXJuZWQgMCBhZnRlciAwIHVzZWNzDQpbICAg IDAuMDE3OTE3XSBjYWxsaW5nICBpMmNfaW5pdCsweDAvMHg1NyBAIDENClsgICAgMC4wMTc5 MTddIGluaXRjYWxsIGkyY19pbml0KzB4MC8weDU3IHJldHVybmVkIDAgYWZ0ZXIgMCB1c2Vj cw0KWyAgICAwLjAxNzkxN10gY2FsbGluZyAgZWlzYV9pbml0KzB4MC8weDI5IEAgMQ0KWyAg ICAwLjAxNzkxN10gRUlTQSBidXMgcmVnaXN0ZXJlZA0KWyAgICAwLjAxNzkxN10gaW5pdGNh bGwgZWlzYV9pbml0KzB4MC8weDI5IHJldHVybmVkIDAgYWZ0ZXIgMCB1c2Vjcw0KWyAgICAw LjAxNzkxN10gY2FsbGluZyAgYW1kX3Bvc3Rjb3JlX2luaXQrMHgwLzB4MTM5IEAgMQ0KWyAg ICAwLjAxNzkxN10gbm9kZSAwIGxpbmsgMDogaW8gcG9ydCBbNTAwMCwgZmZmZmZmXQ0KWyAg ICAwLjAxNzkxN10gVE9NOiAwMDAwMDAwMGMwMDAwMDAwIGFrYSAzMDcyTQ0KWyAgICAwLjAx NzkxN10gRmFtIDEwaCBtbWNvbmYgW2UwMDAwMDAwLCBlZmZmZmZmZl0NClsgICAgMC4wMTc5 MTddIG5vZGUgMCBsaW5rIDA6IG1taW8gW2UwMDAwMDAwLCBlZmZmZmZmZl0gPT0+IG5vbmUN ClsgICAgMC4wMTc5MTddIG5vZGUgMCBsaW5rIDA6IG1taW8gW2EwMDAwLCBiZmZmZl0NClsg ICAgMC4wMTc5MTddIG5vZGUgMCBsaW5rIDA6IG1taW8gW2MwMDAwMDAwLCBmZTBiZmZmZl0g PT0+IFtjMDAwMDAwMCwgZGZmZmZmZmZdIGFuZCBbZjAwMDAwMDAsIGZlMGJmZmZmXQ0KWyAg ICAwLjAxNzkxN10gVE9NMjogMDAwMDAwMDE0MDAwMDAwMCBha2EgNTEyME0NClsgICAgMC4w MTc5MTddIGJ1czogWzAwLCAwN10gb24gbm9kZSAwIGxpbmsgMA0KWyAgICAwLjAxNzkxN10g YnVzOiAwMCBpbmRleCAwIFtpbyAgMHgwMDAwLTB4ZmZmZl0NClsgICAgMC4wMTc5MTddIGJ1 czogMDAgaW5kZXggMSBbbWVtIDB4MDAwYTAwMDAtMHgwMDBiZmZmZl0NClsgICAgMC4wMTc5 MTddIGJ1czogMDAgaW5kZXggMiBbbWVtIDB4YzAwMDAwMDAtMHhkZmZmZmZmZl0NClsgICAg MC4wMTc5MTddIGJ1czogMDAgaW5kZXggMyBbbWVtIDB4ZjAwMDAwMDAtMHhmZmZmZmZmZl0N ClsgICAgMC4wMTc5MTddIGJ1czogMDAgaW5kZXggNCBbbWVtIDB4MTQwMDAwMDAwLTB4ZmNm ZmZmZmZmZl0NClsgICAgMC4wMTc5MTddIEV4dGVuZGVkIENvbmZpZyBTcGFjZSBlbmFibGVk IG9uIDEgbm9kZXMNClsgICAgMC4wMTc5MTddIGluaXRjYWxsIGFtZF9wb3N0Y29yZV9pbml0 KzB4MC8weDEzOSByZXR1cm5lZCAwIGFmdGVyIDAgdXNlY3MNClsgICAgMC4wMTc5MTddIGNh bGxpbmcgIGFyY2hfa2RlYnVnZnNfaW5pdCsweDAvMHgxZSBAIDENClsgICAgMC4wMTc5MTdd IGluaXRjYWxsIGFyY2hfa2RlYnVnZnNfaW5pdCsweDAvMHgxZSByZXR1cm5lZCAwIGFmdGVy IDAgdXNlY3MNClsgICAgMC4wMTc5MTddIGNhbGxpbmcgIGluaXRfcGl0X2Nsb2Nrc291cmNl KzB4MC8weDM2IEAgMQ0KWyAgICAwLjAxNzkxN10gaW5pdGNhbGwgaW5pdF9waXRfY2xvY2tz b3VyY2UrMHgwLzB4MzYgcmV0dXJuZWQgMCBhZnRlciAwIHVzZWNzDQpbICAgIDAuMDE3OTE3 XSBjYWxsaW5nICBjb25maWd1cmVfdHJhbXBvbGluZXMrMHgwLzB4MWYgQCAxDQpbICAgIDAu MDE3OTE3XSBpbml0Y2FsbCBjb25maWd1cmVfdHJhbXBvbGluZXMrMHgwLzB4MWYgcmV0dXJu ZWQgMCBhZnRlciAwIHVzZWNzDQpbICAgIDAuMDE3OTE3XSBjYWxsaW5nICBtdHJyX2lmX2lu aXQrMHgwLzB4NTYgQCAxDQpbICAgIDAuMDE3OTE3XSBpbml0Y2FsbCBtdHJyX2lmX2luaXQr MHgwLzB4NTYgcmV0dXJuZWQgLTE5IGFmdGVyIDAgdXNlY3MNClsgICAgMC4wMTc5MTddIGNh bGxpbmcgIGZmaF9jc3RhdGVfaW5pdCsweDAvMHgyNyBAIDENClsgICAgMC4wMTc5MTddIGlu aXRjYWxsIGZmaF9jc3RhdGVfaW5pdCsweDAvMHgyNyByZXR1cm5lZCAtMSBhZnRlciAwIHVz ZWNzDQpbICAgIDAuMDE3OTE3XSBpbml0Y2FsbCBmZmhfY3N0YXRlX2luaXQrMHgwLzB4Mjcg cmV0dXJuZWQgd2l0aCBlcnJvciBjb2RlIC0xIA0KWyAgICAwLjAxNzkxN10gY2FsbGluZyAg a2R1bXBfYnVmX3BhZ2VfaW5pdCsweDAvMHg0MSBAIDENClsgICAgMC4wMTc5MTddIGluaXRj YWxsIGtkdW1wX2J1Zl9wYWdlX2luaXQrMHgwLzB4NDEgcmV0dXJuZWQgMCBhZnRlciAwIHVz ZWNzDQpbICAgIDAuMDE3OTE3XSBjYWxsaW5nICBhY3BpX3BjaV9pbml0KzB4MC8weDViIEAg MQ0KWyAgICAwLjAxNzkxN10gQUNQSTogYnVzIHR5cGUgcGNpIHJlZ2lzdGVyZWQNClsgICAg MC4wMTc5MTddIGluaXRjYWxsIGFjcGlfcGNpX2luaXQrMHgwLzB4NWIgcmV0dXJuZWQgMCBh ZnRlciAwIHVzZWNzDQpbICAgIDAuMDE3OTE3XSBjYWxsaW5nICBkbWFfYnVzX2luaXQrMHgw LzB4MzIgQCAxDQpbICAgIDAuMDE3OTE3XSBpbml0Y2FsbCBkbWFfYnVzX2luaXQrMHgwLzB4 MzIgcmV0dXJuZWQgMCBhZnRlciAwIHVzZWNzDQpbICAgIDAuMDE3OTE3XSBjYWxsaW5nICBk bWFfY2hhbm5lbF90YWJsZV9pbml0KzB4MC8weGU4IEAgMQ0KWyAgICAwLjAxNzkxN10gaW5p dGNhbGwgZG1hX2NoYW5uZWxfdGFibGVfaW5pdCsweDAvMHhlOCByZXR1cm5lZCAwIGFmdGVy IDAgdXNlY3MNClsgICAgMC4wMTc5MTddIGNhbGxpbmcgIHNldHVwX3ZjcHVfaG90cGx1Z19l dmVudCsweDAvMHgxZiBAIDENClsgICAgMC4wMTc5MTddIGluaXRjYWxsIHNldHVwX3ZjcHVf aG90cGx1Z19ldmVudCsweDAvMHgxZiByZXR1cm5lZCAwIGFmdGVyIDAgdXNlY3MNClsgICAg MC4wMTc5MTddIGNhbGxpbmcgIHJlZ2lzdGVyX3hlbl9wY2lfbm90aWZpZXIrMHgwLzB4MmMg QCAxDQpbICAgIDAuMDE3OTE3XSBpbml0Y2FsbCByZWdpc3Rlcl94ZW5fcGNpX25vdGlmaWVy KzB4MC8weDJjIHJldHVybmVkIDAgYWZ0ZXIgMCB1c2Vjcw0KWyAgICAwLjAxNzkxN10gY2Fs bGluZyAgZG1pX2lkX2luaXQrMHgwLzB4MmFkIEAgMQ0KWyAgICAwLjAxNzkxN10gaW5pdGNh bGwgZG1pX2lkX2luaXQrMHgwLzB4MmFkIHJldHVybmVkIDAgYWZ0ZXIgMCB1c2Vjcw0KWyAg ICAwLjAxNzkxN10gY2FsbGluZyAgcGNpX2FyY2hfaW5pdCsweDAvMHg2NSBAIDENClsgICAg MC4wMTc5MTddIFBDSTogTU1DT05GSUcgZm9yIGRvbWFpbiAwMDAwIFtidXMgMDAtZmZdIGF0 IFttZW0gMHhlMDAwMDAwMC0weGVmZmZmZmZmXSAoYmFzZSAweGUwMDAwMDAwKQ0KWyAgICAw LjAxNzkxN10gUENJOiBub3QgdXNpbmcgTU1DT05GSUcNClsgICAgMC4wMjAxMTRdIFBDSSA6 IFBDSSBCSU9TIGFlcmEgaXMgcncgYW5kIHguIFVzZSBwY2k9bm9iaW9zIGlmIHlvdSB3YW50 IGl0IE5YLg0KWyAgICAwLjAyMDI2N10gUENJOiBQQ0kgQklPUyByZXZpc2lvbiAzLjAwIGVu dHJ5IGF0IDB4ZjAwMzEsIGxhc3QgYnVzPTQNClsgICAgMC4wMjAyNzhdIFBDSTogVXNpbmcg Y29uZmlndXJhdGlvbiB0eXBlIDEgZm9yIGJhc2UgYWNjZXNzDQpbICAgIDAuMDIwMjg3XSBQ Q0k6IFVzaW5nIGNvbmZpZ3VyYXRpb24gdHlwZSAxIGZvciBleHRlbmRlZCBhY2Nlc3MNClsg ICAgMC4wMjAzMDddIGluaXRjYWxsIHBjaV9hcmNoX2luaXQrMHgwLzB4NjUgcmV0dXJuZWQg MCBhZnRlciAzOTA2IHVzZWNzDQpbICAgIDAuMDIwMzE4XSBjYWxsaW5nICB0b3BvbG9neV9p bml0KzB4MC8weDM2IEAgMQ0KWyAgICAwLjAyMDMzN10gaW5pdGNhbGwgdG9wb2xvZ3lfaW5p dCsweDAvMHgzNiByZXR1cm5lZCAwIGFmdGVyIDAgdXNlY3MNClsgICAgMC4wMjAzNDldIGNh bGxpbmcgIG10cnJfaW5pdF9maW5pYWxpemUrMHgwLzB4MzAgQCAxDQpbICAgIDAuMDIwMzYw XSBpbml0Y2FsbCBtdHJyX2luaXRfZmluaWFsaXplKzB4MC8weDMwIHJldHVybmVkIDAgYWZ0 ZXIgMCB1c2Vjcw0KWyAgICAwLjAyMDM3Ml0gY2FsbGluZyAgbWNhX2luaXQrMHgwLzB4MmU0 IEAgMQ0KWyAgICAwLjAyMDM4Nl0gaW5pdGNhbGwgbWNhX2luaXQrMHgwLzB4MmU0IHJldHVy bmVkIC0xOSBhZnRlciAwIHVzZWNzDQpbICAgIDAuMDIwMzk4XSBjYWxsaW5nICBwYXJhbV9z eXNmc19pbml0KzB4MC8weDE2NiBAIDENClsgICAgMC4wMjA5MzNdIGluaXRjYWxsIHBhcmFt X3N5c2ZzX2luaXQrMHgwLzB4MTY2IHJldHVybmVkIDAgYWZ0ZXIgMCB1c2Vjcw0KWyAgICAw LjAyMDk0NV0gY2FsbGluZyAgcG1fc3lzcnFfaW5pdCsweDAvMHgyMCBAIDENClsgICAgMC4w MjA5NTZdIGluaXRjYWxsIHBtX3N5c3JxX2luaXQrMHgwLzB4MjAgcmV0dXJuZWQgMCBhZnRl ciAwIHVzZWNzDQpbICAgIDAuMDIwOTY4XSBjYWxsaW5nICBkZWZhdWx0X2JkaV9pbml0KzB4 MC8weGFjIEAgMQ0KWyAgICAwLjAyMDk5N10gaW5pdGNhbGwgZGVmYXVsdF9iZGlfaW5pdCsw eDAvMHhhYyByZXR1cm5lZCAwIGFmdGVyIDAgdXNlY3MNClsgICAgMC4wMjA5OTddIGNhbGxp bmcgIGluaXRfYmlvKzB4MC8weDEwMCBAIDENClsgICAgMC4wMjA5OTddIGJpbzogY3JlYXRl IHNsYWIgPGJpby0wPiBhdCAwDQpbICAgIDAuMDIwOTk3XSBpbml0Y2FsbCBpbml0X2Jpbysw eDAvMHgxMDAgcmV0dXJuZWQgMCBhZnRlciAwIHVzZWNzDQpbICAgIDAuMDIwOTk3XSBjYWxs aW5nICBmc25vdGlmeV9ub3RpZmljYXRpb25faW5pdCsweDAvMHg5YyBAIDENClsgICAgMC4w MjA5OTddIGluaXRjYWxsIGZzbm90aWZ5X25vdGlmaWNhdGlvbl9pbml0KzB4MC8weDljIHJl dHVybmVkIDAgYWZ0ZXIgMCB1c2Vjcw0KWyAgICAwLjAyMDk5N10gY2FsbGluZyAgY3J5cHRv bWdyX2luaXQrMHgwLzB4ZiBAIDENClsgICAgMC4wMjA5OTddIGluaXRjYWxsIGNyeXB0b21n cl9pbml0KzB4MC8weGYgcmV0dXJuZWQgMCBhZnRlciAwIHVzZWNzDQpbICAgIDAuMDIwOTk3 XSBjYWxsaW5nICBibGtfc2V0dGluZ3NfaW5pdCsweDAvMHgyMSBAIDENClsgICAgMC4wMjA5 OTddIGluaXRjYWxsIGJsa19zZXR0aW5nc19pbml0KzB4MC8weDIxIHJldHVybmVkIDAgYWZ0 ZXIgMCB1c2Vjcw0KWyAgICAwLjAyMDk5N10gY2FsbGluZyAgYmxrX2lvY19pbml0KzB4MC8w eDJmIEAgMQ0KWyAgICAwLjAyMDk5N10gaW5pdGNhbGwgYmxrX2lvY19pbml0KzB4MC8weDJm IHJldHVybmVkIDAgYWZ0ZXIgMCB1c2Vjcw0KWyAgICAwLjAyMDk5N10gY2FsbGluZyAgYmxr X3NvZnRpcnFfaW5pdCsweDAvMHg1NCBAIDENClsgICAgMC4wMjA5OTddIGluaXRjYWxsIGJs a19zb2Z0aXJxX2luaXQrMHgwLzB4NTQgcmV0dXJuZWQgMCBhZnRlciAwIHVzZWNzDQpbICAg IDAuMDIwOTk3XSBjYWxsaW5nICBibGtfaW9wb2xsX3NldHVwKzB4MC8weDU0IEAgMQ0KWyAg ICAwLjAyMDk5N10gaW5pdGNhbGwgYmxrX2lvcG9sbF9zZXR1cCsweDAvMHg1NCByZXR1cm5l ZCAwIGFmdGVyIDAgdXNlY3MNClsgICAgMC4wMjA5OTddIGNhbGxpbmcgIGdlbmhkX2Rldmlj ZV9pbml0KzB4MC8weDYxIEAgMQ0KWyAgICAwLjAyMDk5N10gaW5pdGNhbGwgZ2VuaGRfZGV2 aWNlX2luaXQrMHgwLzB4NjEgcmV0dXJuZWQgMCBhZnRlciAwIHVzZWNzDQpbICAgIDAuMDIw OTk3XSBjYWxsaW5nICBibGtfZGV2X2ludGVncml0eV9pbml0KzB4MC8weDJmIEAgMQ0KWyAg ICAwLjAyMDk5N10gaW5pdGNhbGwgYmxrX2Rldl9pbnRlZ3JpdHlfaW5pdCsweDAvMHgyZiBy ZXR1cm5lZCAwIGFmdGVyIDAgdXNlY3MNClsgICAgMC4wMjA5OTddIGNhbGxpbmcgIGdwaW9s aWJfZGVidWdmc19pbml0KzB4MC8weDJhIEAgMQ0KWyAgICAwLjAyMDk5N10gaW5pdGNhbGwg Z3Bpb2xpYl9kZWJ1Z2ZzX2luaXQrMHgwLzB4MmEgcmV0dXJuZWQgMCBhZnRlciAwIHVzZWNz DQpbICAgIDAuMDIwOTk3XSBjYWxsaW5nICBzdG1wZV9ncGlvX2luaXQrMHgwLzB4ZiBAIDEN ClsgICAgMC4wMjA5OTddIGluaXRjYWxsIHN0bXBlX2dwaW9faW5pdCsweDAvMHhmIHJldHVy bmVkIDAgYWZ0ZXIgMCB1c2Vjcw0KWyAgICAwLjAyMDk5N10gY2FsbGluZyAgdGMzNTg5eF9n cGlvX2luaXQrMHgwLzB4ZiBAIDENClsgICAgMC4wMjA5OTddIGluaXRjYWxsIHRjMzU4OXhf Z3Bpb19pbml0KzB4MC8weGYgcmV0dXJuZWQgMCBhZnRlciAwIHVzZWNzDQpbICAgIDAuMDIw OTk3XSBjYWxsaW5nICBzeDE1MHhfaW5pdCsweDAvMHgxMSBAIDENClsgICAgMC4wMjA5OTdd IGluaXRjYWxsIHN4MTUweF9pbml0KzB4MC8weDExIHJldHVybmVkIDAgYWZ0ZXIgMCB1c2Vj cw0KWyAgICAwLjAyMDk5N10gY2FsbGluZyAgcGNpX3Nsb3RfaW5pdCsweDAvMHg1MCBAIDEN ClsgICAgMC4wMjA5OTddIGluaXRjYWxsIHBjaV9zbG90X2luaXQrMHgwLzB4NTAgcmV0dXJu ZWQgMCBhZnRlciAwIHVzZWNzDQpbICAgIDAuMDIwOTk3XSBjYWxsaW5nICBhY3BpX2luaXQr MHgwLzB4MjcyIEAgMQ0KWyAgICAwLjAyNDI0MF0gQUNQSTogRUM6IExvb2sgdXAgRUMgaW4g RFNEVA0KWyAgICAwLjAyODAyM10gQUNQSTogRXhlY3V0ZWQgMSBibG9ja3Mgb2YgbW9kdWxl LWxldmVsIGV4ZWN1dGFibGUgQU1MIGNvZGUNClsgICAgMC4wMzIwMDFdIEFDUEk6IEludGVy cHJldGVyIGVuYWJsZWQNClsgICAgMC4wMzIwMDFdIEFDUEk6IChzdXBwb3J0cyBTMCBTMSBT MyBTNCBTNSkNClsgICAgMC4wMzIwMDFdIEFDUEk6IFVzaW5nIElPQVBJQyBmb3IgaW50ZXJy dXB0IHJvdXRpbmcNClsgICAgMC4wMzIwMjddIFBDSTogTU1DT05GSUcgZm9yIGRvbWFpbiAw MDAwIFtidXMgMDAtZmZdIGF0IFttZW0gMHhlMDAwMDAwMC0weGVmZmZmZmZmXSAoYmFzZSAw eGUwMDAwMDAwKQ0KWyAgICAwLjAzMzgzOF0gUENJOiBNTUNPTkZJRyBhdCBbbWVtIDB4ZTAw MDAwMDAtMHhlZmZmZmZmZl0gcmVzZXJ2ZWQgaW4gQUNQSSBtb3RoZXJib2FyZCByZXNvdXJj ZXMNClsgICAgMC4wMzM4NTNdIFBDSTogVXNpbmcgTU1DT05GSUcgZm9yIGV4dGVuZGVkIGNv bmZpZyBzcGFjZQ0KWyAgICAwLjA0MTIxNV0gaW5pdGNhbGwgYWNwaV9pbml0KzB4MC8weDI3 MiByZXR1cm5lZCAwIGFmdGVyIDE5NTMyIHVzZWNzDQpbICAgIDAuMDQxMjI5XSBjYWxsaW5n ICBkb2NrX2luaXQrMHgwLzB4YjMgQCAxDQpbICAgIDAuMDQxNDQ3XSBBQ1BJOiBObyBkb2Nr IGRldmljZXMgZm91bmQuDQpbICAgIDAuMDQxNDU2XSBpbml0Y2FsbCBkb2NrX2luaXQrMHgw LzB4YjMgcmV0dXJuZWQgMCBhZnRlciAwIHVzZWNzDQpbICAgIDAuMDQxNDY4XSBjYWxsaW5n ICBhY3BpX3BjaV9yb290X2luaXQrMHgwLzB4MmYgQCAxDQpbICAgIDAuMDQxNDc3XSBIRVNU OiBUYWJsZSBub3QgZm91bmQuDQpbICAgIDAuMDQxNDg2XSBQQ0k6IFVzaW5nIGhvc3QgYnJp ZGdlIHdpbmRvd3MgZnJvbSBBQ1BJOyBpZiBuZWNlc3NhcnksIHVzZSAicGNpPW5vY3JzIiBh bmQgcmVwb3J0IGEgYnVnDQpbICAgIDAuMDQxNzMyXSBBQ1BJOiBQQ0kgUm9vdCBCcmlkZ2Ug W1BDSTBdIChkb21haW4gMDAwMCBbYnVzIDAwLWZmXSkNClsgICAgMC4wNDE5NDRdIHBjaV9y b290IFBOUDBBMDM6MDA6IGhvc3QgYnJpZGdlIHdpbmRvdyBbaW8gIDB4MDAwMC0weDBjZjdd DQpbICAgIDAuMDQxOTU3XSBwY2lfcm9vdCBQTlAwQTAzOjAwOiBob3N0IGJyaWRnZSB3aW5k b3cgW2lvICAweDBkMDAtMHhmZmZmXQ0KWyAgICAwLjA0MTk2OF0gcGNpX3Jvb3QgUE5QMEEw MzowMDogaG9zdCBicmlkZ2Ugd2luZG93IFttZW0gMHgwMDBhMDAwMC0weDAwMGJmZmZmXQ0K WyAgICAwLjA0MTk4Ml0gcGNpX3Jvb3QgUE5QMEEwMzowMDogaG9zdCBicmlkZ2Ugd2luZG93 IFttZW0gMHgwMDBkMDAwMC0weDAwMGRmZmZmXQ0KWyAgICAwLjA0MTk5NV0gcGNpX3Jvb3Qg UE5QMEEwMzowMDogaG9zdCBicmlkZ2Ugd2luZG93IFttZW0gMHhiMDAwMDAwMC0weGRmZmZm ZmZmXQ0KWyAgICAwLjA0MjAwN10gcGNpX3Jvb3QgUE5QMEEwMzowMDogaG9zdCBicmlkZ2Ug d2luZG93IFttZW0gMHhmMDAwMDAwMC0weGZlZDQ0ZmZmXQ0KWyAgICAwLjA0MjA0OV0gcGNp IDAwMDA6MDA6MDAuMDogWzEwZGU6MDNlMl0gdHlwZSAwIGNsYXNzIDB4MDAwNTAwDQpbICAg IDAuMDQyMjc2XSBwY2kgMDAwMDowMDowMS4wOiBbMTBkZTowM2UxXSB0eXBlIDAgY2xhc3Mg MHgwMDA2MDENClsgICAgMC4wNDIzMDBdIHBjaSAwMDAwOjAwOjAxLjA6IHJlZyAxMDogW2lv ICAweDA5MDAtMHgwOWZmXQ0KWyAgICAwLjA0MjM4M10gcGNpIDAwMDA6MDA6MDEuMTogWzEw ZGU6MDNlYl0gdHlwZSAwIGNsYXNzIDB4MDAwYzA1DQpbICAgIDAuMDQyNDE0XSBwY2kgMDAw MDowMDowMS4xOiByZWcgMTA6IFtpbyAgMHgwZTAwLTB4MGUzZl0NClsgICAgMC4wNDI0NThd IHBjaSAwMDAwOjAwOjAxLjE6IHJlZyAyMDogW2lvICAweDA2MDAtMHgwNjNmXQ0KWyAgICAw LjA0MjQ3N10gcGNpIDAwMDA6MDA6MDEuMTogcmVnIDI0OiBbaW8gIDB4MDcwMC0weDA3M2Zd DQpbICAgIDAuMDQyNTIxXSBwY2kgMDAwMDowMDowMS4xOiBQTUUjIHN1cHBvcnRlZCBmcm9t IEQzaG90IEQzY29sZA0KWyAgICAwLjA0MjUzOF0gcGNpIDAwMDA6MDA6MDEuMTogUE1FIyBk aXNhYmxlZA0KWyAgICAwLjA0MjU2MF0gcGNpIDAwMDA6MDA6MDEuMjogWzEwZGU6MDNmNV0g dHlwZSAwIGNsYXNzIDB4MDAwNTAwDQpbICAgIDAuMDQyNjYyXSBwY2kgMDAwMDowMDowMi4w OiBbMTBkZTowM2YxXSB0eXBlIDAgY2xhc3MgMHgwMDBjMDMNClsgICAgMC4wNDI2OTFdIHBj aSAwMDAwOjAwOjAyLjA6IHJlZyAxMDogW21lbSAweGRmZmZiMDAwLTB4ZGZmZmJmZmZdDQpb ICAgIDAuMDQyNzczXSBwY2kgMDAwMDowMDowMi4wOiBzdXBwb3J0cyBEMSBEMg0KWyAgICAw LjA0Mjc4M10gcGNpIDAwMDA6MDA6MDIuMDogUE1FIyBzdXBwb3J0ZWQgZnJvbSBEMCBEMSBE MiBEM2hvdCBEM2NvbGQNClsgICAgMC4wNDI3OTddIHBjaSAwMDAwOjAwOjAyLjA6IFBNRSMg ZGlzYWJsZWQNClsgICAgMC4wNDI4MjRdIHBjaSAwMDAwOjAwOjAyLjE6IFsxMGRlOjAzZjJd IHR5cGUgMCBjbGFzcyAweDAwMGMwMw0KWyAgICAwLjA0Mjg1Nl0gcGNpIDAwMDA6MDA6MDIu MTogcmVnIDEwOiBbbWVtIDB4ZGZmZmFjMDAtMHhkZmZmYWNmZl0NClsgICAgMC4wNDI5NDZd IHBjaSAwMDAwOjAwOjAyLjE6IHN1cHBvcnRzIEQxIEQyDQpbICAgIDAuMDQyOTU2XSBwY2kg MDAwMDowMDowMi4xOiBQTUUjIHN1cHBvcnRlZCBmcm9tIEQwIEQxIEQyIEQzaG90IEQzY29s ZA0KWyAgICAwLjA0Mjk3MF0gcGNpIDAwMDA6MDA6MDIuMTogUE1FIyBkaXNhYmxlZA0KWyAg ICAwLjA0MzAxMF0gcGNpIDAwMDA6MDA6MDQuMDogWzEwZGU6MDNmM10gdHlwZSAxIGNsYXNz IDB4MDAwNjA0DQpbICAgIDAuMDQzMTA3XSBwY2kgMDAwMDowMDowNS4wOiBbMTBkZTowM2Yw XSB0eXBlIDAgY2xhc3MgMHgwMDA0MDMNClsgICAgMC4wNDMxNDBdIHBjaSAwMDAwOjAwOjA1 LjA6IHJlZyAxMDogW21lbSAweGRmZmY0MDAwLTB4ZGZmZjdmZmZdDQpbICAgIDAuMDQzMjMz XSBwY2kgMDAwMDowMDowNS4wOiBQTUUjIHN1cHBvcnRlZCBmcm9tIEQzaG90IEQzY29sZA0K WyAgICAwLjA0MzI0N10gcGNpIDAwMDA6MDA6MDUuMDogUE1FIyBkaXNhYmxlZA0KWyAgICAw LjA0MzI4N10gcGNpIDAwMDA6MDA6MDYuMDogWzEwZGU6MDNlY10gdHlwZSAwIGNsYXNzIDB4 MDAwMTAxDQpbICAgIDAuMDQzMzQ5XSBwY2kgMDAwMDowMDowNi4wOiByZWcgMjA6IFtpbyAg MHhmZmEwLTB4ZmZhZl0NClsgICAgMC4wNDM0MTddIHBjaSAwMDAwOjAwOjA3LjA6IFsxMGRl OjAzZWZdIHR5cGUgMCBjbGFzcyAweDAwMDY4MA0KWyAgICAwLjA0MzQ0OV0gcGNpIDAwMDA6 MDA6MDcuMDogcmVnIDEwOiBbbWVtIDB4ZGZmZjkwMDAtMHhkZmZmOWZmZl0NClsgICAgMC4w NDM0NjhdIHBjaSAwMDAwOjAwOjA3LjA6IHJlZyAxNDogW2lvICAweGU0ODAtMHhlNDg3XQ0K WyAgICAwLjA0MzU0Nl0gcGNpIDAwMDA6MDA6MDcuMDogc3VwcG9ydHMgRDEgRDINClsgICAg MC4wNDM1NTZdIHBjaSAwMDAwOjAwOjA3LjA6IFBNRSMgc3VwcG9ydGVkIGZyb20gRDAgRDEg RDIgRDNob3QgRDNjb2xkDQpbICAgIDAuMDQzNTcxXSBwY2kgMDAwMDowMDowNy4wOiBQTUUj IGRpc2FibGVkDQpbICAgIDAuMDQzNjA0XSBwY2kgMDAwMDowMDowOC4wOiBbMTBkZTowM2Y2 XSB0eXBlIDAgY2xhc3MgMHgwMDAxMDENClsgICAgMC4wNDM2MzVdIHBjaSAwMDAwOjAwOjA4 LjA6IHJlZyAxMDogW2lvICAweGU0MDAtMHhlNDA3XQ0KWyAgICAwLjA0MzY1Ml0gcGNpIDAw MDA6MDA6MDguMDogcmVnIDE0OiBbaW8gIDB4ZTA4MC0weGUwODNdDQpbICAgIDAuMDQzNjcw XSBwY2kgMDAwMDowMDowOC4wOiByZWcgMTg6IFtpbyAgMHhlMDAwLTB4ZTAwN10NClsgICAg MC4wNDM2ODhdIHBjaSAwMDAwOjAwOjA4LjA6IHJlZyAxYzogW2lvICAweGRjMDAtMHhkYzAz XQ0KWyAgICAwLjA0MzcwNV0gcGNpIDAwMDA6MDA6MDguMDogcmVnIDIwOiBbaW8gIDB4ZDg4 MC0weGQ4OGZdDQpbICAgIDAuMDQzNzIzXSBwY2kgMDAwMDowMDowOC4wOiByZWcgMjQ6IFtt ZW0gMHhkZmZmODAwMC0weGRmZmY4ZmZmXQ0KWyAgICAwLjA0Mzc5Nl0gcGNpIDAwMDA6MDA6 MDguMTogWzEwZGU6MDNmNl0gdHlwZSAwIGNsYXNzIDB4MDAwMTAxDQpbICAgIDAuMDQzODI4 XSBwY2kgMDAwMDowMDowOC4xOiByZWcgMTA6IFtpbyAgMHhkODAwLTB4ZDgwN10NClsgICAg MC4wNDM4NDZdIHBjaSAwMDAwOjAwOjA4LjE6IHJlZyAxNDogW2lvICAweGQ0ODAtMHhkNDgz XQ0KWyAgICAwLjA0Mzg2M10gcGNpIDAwMDA6MDA6MDguMTogcmVnIDE4OiBbaW8gIDB4ZDQw MC0weGQ0MDddDQpbICAgIDAuMDQzODgxXSBwY2kgMDAwMDowMDowOC4xOiByZWcgMWM6IFtp byAgMHhkMDgwLTB4ZDA4M10NClsgICAgMC4wNDM4OThdIHBjaSAwMDAwOjAwOjA4LjE6IHJl ZyAyMDogW2lvICAweGQwMDAtMHhkMDBmXQ0KWyAgICAwLjA0MzkxNl0gcGNpIDAwMDA6MDA6 MDguMTogcmVnIDI0OiBbbWVtIDB4ZGZmZWYwMDAtMHhkZmZlZmZmZl0NClsgICAgMC4wNDM5 OThdIHBjaSAwMDAwOjAwOjA5LjA6IFsxMGRlOjAzZThdIHR5cGUgMSBjbGFzcyAweDAwMDYw NA0KWyAgICAwLjA0NDAzNF0gcGNpIDAwMDA6MDA6MDkuMDogUE1FIyBzdXBwb3J0ZWQgZnJv bSBEMCBEMSBEMiBEM2hvdCBEM2NvbGQNClsgICAgMC4wNDQwNDhdIHBjaSAwMDAwOjAwOjA5 LjA6IFBNRSMgZGlzYWJsZWQNClsgICAgMC4wNDQwOTBdIHBjaSAwMDAwOjAwOjBiLjA6IFsx MGRlOjAzZTldIHR5cGUgMSBjbGFzcyAweDAwMDYwNA0KWyAgICAwLjA0NDE2OV0gcGNpIDAw MDA6MDA6MGIuMDogUE1FIyBzdXBwb3J0ZWQgZnJvbSBEMCBEMSBEMiBEM2hvdCBEM2NvbGQN ClsgICAgMC4wNDQxODJdIHBjaSAwMDAwOjAwOjBiLjA6IFBNRSMgZGlzYWJsZWQNClsgICAg MC4wNDQyMjJdIHBjaSAwMDAwOjAwOjBjLjA6IFsxMGRlOjAzZTldIHR5cGUgMSBjbGFzcyAw eDAwMDYwNA0KWyAgICAwLjA0NDMwMF0gcGNpIDAwMDA6MDA6MGMuMDogUE1FIyBzdXBwb3J0 ZWQgZnJvbSBEMCBEMSBEMiBEM2hvdCBEM2NvbGQNClsgICAgMC4wNDQzMTRdIHBjaSAwMDAw OjAwOjBjLjA6IFBNRSMgZGlzYWJsZWQNClsgICAgMC4wNDQzNDhdIHBjaSAwMDAwOjAwOjBk LjA6IFsxMGRlOjAzZDZdIHR5cGUgMCBjbGFzcyAweDAwMDMwMA0KWyAgICAwLjA0NDM3Nl0g cGNpIDAwMDA6MDA6MGQuMDogcmVnIDEwOiBbbWVtIDB4ZGUwMDAwMDAtMHhkZWZmZmZmZl0N ClsgICAgMC4wNDQzOTldIHBjaSAwMDAwOjAwOjBkLjA6IHJlZyAxNDogW21lbSAweGMwMDAw MDAwLTB4Y2ZmZmZmZmYgNjRiaXQgcHJlZl0NClsgICAgMC4wNDQ0MjRdIHBjaSAwMDAwOjAw OjBkLjA6IHJlZyAxYzogW21lbSAweGRkMDAwMDAwLTB4ZGRmZmZmZmYgNjRiaXRdDQpbICAg IDAuMDQ0NDUwXSBwY2kgMDAwMDowMDowZC4wOiByZWcgMzA6IFttZW0gMHhkZmZjMDAwMC0w eGRmZmRmZmZmIHByZWZdDQpbICAgIDAuMDQ0NTE0XSBwY2kgMDAwMDowMDoxOC4wOiBbMTAy MjoxMjAwXSB0eXBlIDAgY2xhc3MgMHgwMDA2MDANClsgICAgMC4wNDQ1ODJdIHBjaSAwMDAw OjAwOjE4LjE6IFsxMDIyOjEyMDFdIHR5cGUgMCBjbGFzcyAweDAwMDYwMA0KWyAgICAwLjA0 NDYzOV0gcGNpIDAwMDA6MDA6MTguMjogWzEwMjI6MTIwMl0gdHlwZSAwIGNsYXNzIDB4MDAw NjAwDQpbICAgIDAuMDQ0Njk3XSBwY2kgMDAwMDowMDoxOC4zOiBbMTAyMjoxMjAzXSB0eXBl IDAgY2xhc3MgMHgwMDA2MDANClsgICAgMC4wNDQ3NjVdIHBjaSAwMDAwOjAwOjE4LjQ6IFsx MDIyOjEyMDRdIHR5cGUgMCBjbGFzcyAweDAwMDYwMA0KWyAgICAwLjA0NDkxN10gcGNpIDAw MDA6MDA6MDQuMDogUENJIGJyaWRnZSB0byBbYnVzIDAxLTAxXSAoc3VidHJhY3RpdmUgZGVj b2RlKQ0KWyAgICAwLjA0NDkzM10gcGNpIDAwMDA6MDA6MDQuMDogICBicmlkZ2Ugd2luZG93 IFtpbyAgMHhmMDAwLTB4MDAwMF0gKGRpc2FibGVkKQ0KWyAgICAwLjA0NDk0OF0gcGNpIDAw MDA6MDA6MDQuMDogICBicmlkZ2Ugd2luZG93IFttZW0gMHhmZmYwMDAwMC0weDAwMGZmZmZm XSAoZGlzYWJsZWQpDQpbICAgIDAuMDQ0OTY0XSBwY2kgMDAwMDowMDowNC4wOiAgIGJyaWRn ZSB3aW5kb3cgW21lbSAweGZmZjAwMDAwLTB4MDAwZmZmZmYgcHJlZl0gKGRpc2FibGVkKQ0K WyAgICAwLjA0NDk3N10gcGNpIDAwMDA6MDA6MDQuMDogICBicmlkZ2Ugd2luZG93IFtpbyAg MHgwMDAwLTB4MGNmN10gKHN1YnRyYWN0aXZlIGRlY29kZSkNClsgICAgMC4wNDQ5OTFdIHBj aSAwMDAwOjAwOjA0LjA6ICAgYnJpZGdlIHdpbmRvdyBbaW8gIDB4MGQwMC0weGZmZmZdIChz dWJ0cmFjdGl2ZSBkZWNvZGUpDQpbICAgIDAuMDQ1MDA0XSBwY2kgMDAwMDowMDowNC4wOiAg IGJyaWRnZSB3aW5kb3cgW21lbSAweDAwMGEwMDAwLTB4MDAwYmZmZmZdIChzdWJ0cmFjdGl2 ZSBkZWNvZGUpDQpbICAgIDAuMDQ1MDE5XSBwY2kgMDAwMDowMDowNC4wOiAgIGJyaWRnZSB3 aW5kb3cgW21lbSAweDAwMGQwMDAwLTB4MDAwZGZmZmZdIChzdWJ0cmFjdGl2ZSBkZWNvZGUp DQpbICAgIDAuMDQ1MDM0XSBwY2kgMDAwMDowMDowNC4wOiAgIGJyaWRnZSB3aW5kb3cgW21l bSAweGIwMDAwMDAwLTB4ZGZmZmZmZmZdIChzdWJ0cmFjdGl2ZSBkZWNvZGUpDQpbICAgIDAu MDQ1MDQ5XSBwY2kgMDAwMDowMDowNC4wOiAgIGJyaWRnZSB3aW5kb3cgW21lbSAweGYwMDAw MDAwLTB4ZmVkNDRmZmZdIChzdWJ0cmFjdGl2ZSBkZWNvZGUpDQpbICAgIDAuMDQ1MTIzXSBw Y2kgMDAwMDowMDowOS4wOiBQQ0kgYnJpZGdlIHRvIFtidXMgMDItMDJdDQpbICAgIDAuMDQ1 MTM3XSBwY2kgMDAwMDowMDowOS4wOiAgIGJyaWRnZSB3aW5kb3cgW2lvICAweGYwMDAtMHgw MDAwXSAoZGlzYWJsZWQpDQpbICAgIDAuMDQ1MTUzXSBwY2kgMDAwMDowMDowOS4wOiAgIGJy aWRnZSB3aW5kb3cgW21lbSAweGZmZjAwMDAwLTB4MDAwZmZmZmZdIChkaXNhYmxlZCkNClsg ICAgMC4wNDUxNzBdIHBjaSAwMDAwOjAwOjA5LjA6ICAgYnJpZGdlIHdpbmRvdyBbbWVtIDB4 ZmZmMDAwMDAtMHgwMDBmZmZmZiBwcmVmXSAoZGlzYWJsZWQpDQpbICAgIDAuMDQ1MjQyXSBw Y2kgMDAwMDowMDowYi4wOiBQQ0kgYnJpZGdlIHRvIFtidXMgMDMtMDNdDQpbICAgIDAuMDQ1 MjU2XSBwY2kgMDAwMDowMDowYi4wOiAgIGJyaWRnZSB3aW5kb3cgW2lvICAweGYwMDAtMHgw MDAwXSAoZGlzYWJsZWQpDQpbICAgIDAuMDQ1MjcyXSBwY2kgMDAwMDowMDowYi4wOiAgIGJy aWRnZSB3aW5kb3cgW21lbSAweGZmZjAwMDAwLTB4MDAwZmZmZmZdIChkaXNhYmxlZCkNClsg ICAgMC4wNDUyODldIHBjaSAwMDAwOjAwOjBiLjA6ICAgYnJpZGdlIHdpbmRvdyBbbWVtIDB4 ZmZmMDAwMDAtMHgwMDBmZmZmZiBwcmVmXSAoZGlzYWJsZWQpDQpbICAgIDAuMDQ1MzYxXSBw Y2kgMDAwMDowMDowYy4wOiBQQ0kgYnJpZGdlIHRvIFtidXMgMDQtMDRdDQpbICAgIDAuMDQ1 Mzc1XSBwY2kgMDAwMDowMDowYy4wOiAgIGJyaWRnZSB3aW5kb3cgW2lvICAweGYwMDAtMHgw MDAwXSAoZGlzYWJsZWQpDQpbICAgIDAuMDQ1MzkxXSBwY2kgMDAwMDowMDowYy4wOiAgIGJy aWRnZSB3aW5kb3cgW21lbSAweGZmZjAwMDAwLTB4MDAwZmZmZmZdIChkaXNhYmxlZCkNClsg ICAgMC4wNDU0MDhdIHBjaSAwMDAwOjAwOjBjLjA6ICAgYnJpZGdlIHdpbmRvdyBbbWVtIDB4 ZmZmMDAwMDAtMHgwMDBmZmZmZiBwcmVmXSAoZGlzYWJsZWQpDQpbICAgIDAuMDQ1NDQwXSBw Y2lfYnVzIDAwMDA6MDA6IG9uIE5VTUEgbm9kZSAwDQpbICAgIDAuMDQ1NDUwXSBBQ1BJOiBQ Q0kgSW50ZXJydXB0IFJvdXRpbmcgVGFibGUgW1xfU0JfLlBDSTAuX1BSVF0NClsgICAgMC4w NDU1NzldIEFDUEk6IFBDSSBJbnRlcnJ1cHQgUm91dGluZyBUYWJsZSBbXF9TQl8uUENJMC5Q MFAxLl9QUlRdDQpbICAgIDAuMDQ1NjM5XSBBQ1BJOiBQQ0kgSW50ZXJydXB0IFJvdXRpbmcg VGFibGUgW1xfU0JfLlBDSTAuQlIxMC5fUFJUXQ0KWyAgICAwLjA0NTY4MV0gQUNQSTogUENJ IEludGVycnVwdCBSb3V0aW5nIFRhYmxlIFtcX1NCXy5QQ0kwLkJSMTEuX1BSVF0NClsgICAg MC4wNDU3MjVdIEFDUEk6IFBDSSBJbnRlcnJ1cHQgUm91dGluZyBUYWJsZSBbXF9TQl8uUENJ MC5CUjEyLl9QUlRdDQpbICAgIDAuMDQ1ODg4XSAgcGNpMDAwMDowMDogUmVxdWVzdGluZyBB Q1BJIF9PU0MgY29udHJvbCAoMHgxZCkNClsgICAgMC4wNDYwOTZdICBwY2kwMDAwOjAwOiBB Q1BJIF9PU0MgcmVxdWVzdCBmYWlsZWQgKEFFX1NVUFBPUlQpLCByZXR1cm5lZCBjb250cm9s IG1hc2s6IDB4MGMNClsgICAgMC4wNDYxMTBdIEFDUEkgX09TQyBjb250cm9sIGZvciBQQ0ll IG5vdCBncmFudGVkLCBkaXNhYmxpbmcgQVNQTQ0KWyAgICAwLjA1MjMyN10gaW5pdGNhbGwg YWNwaV9wY2lfcm9vdF9pbml0KzB4MC8weDJmIHJldHVybmVkIDAgYWZ0ZXIgMTE3MTkgdXNl Y3MNClsgICAgMC4wNTIzNDJdIGNhbGxpbmcgIGFjcGlfcGNpX2xpbmtfaW5pdCsweDAvMHgz ZiBAIDENClsgICAgMC4wNTI0NTFdIEFDUEk6IFBDSSBJbnRlcnJ1cHQgTGluayBbTE5LQV0g KElSUXMgMTYgMTcgMTggMTkpICowLCBkaXNhYmxlZC4NClsgICAgMC4wNTI1OTBdIEFDUEk6 IFBDSSBJbnRlcnJ1cHQgTGluayBbTE5LQl0gKElSUXMgMTYgMTcgMTggMTkpICowLCBkaXNh YmxlZC4NClsgICAgMC4wNTI3MjZdIEFDUEk6IFBDSSBJbnRlcnJ1cHQgTGluayBbTE5LQ10g KElSUXMgMTYgMTcgMTggMTkpICowLCBkaXNhYmxlZC4NClsgICAgMC4wNTI4NjJdIEFDUEk6 IFBDSSBJbnRlcnJ1cHQgTGluayBbTE5LRF0gKElSUXMgMTYgMTcgMTggMTkpICowLCBkaXNh YmxlZC4NClsgICAgMC4wNTI5OThdIEFDUEk6IFBDSSBJbnRlcnJ1cHQgTGluayBbTE5FQV0g KElSUXMgMTYgMTcgMTggMTkpICowLCBkaXNhYmxlZC4NClsgICAgMC4wNTMxMzRdIEFDUEk6 IFBDSSBJbnRlcnJ1cHQgTGluayBbTE5FQl0gKElSUXMgMTYgMTcgMTggMTkpICowLCBkaXNh YmxlZC4NClsgICAgMC4wNTMyNjldIEFDUEk6IFBDSSBJbnRlcnJ1cHQgTGluayBbTE5FQ10g KElSUXMgMTYgMTcgMTggMTkpICowLCBkaXNhYmxlZC4NClsgICAgMC4wNTM0MDZdIEFDUEk6 IFBDSSBJbnRlcnJ1cHQgTGluayBbTE5FRF0gKElSUXMgMTYgMTcgMTggMTkpICowLCBkaXNh YmxlZC4NClsgICAgMC4wNTM1NDVdIEFDUEk6IFBDSSBJbnRlcnJ1cHQgTGluayBbTFVCMF0g KElSUXMgMjAgMjEgMjIgMjMpICo1DQpbICAgIDAuMDUzNjgxXSBBQ1BJOiBQQ0kgSW50ZXJy dXB0IExpbmsgW0xVQjJdIChJUlFzIDIwIDIxIDIyIDIzKSAqMTENClsgICAgMC4wNTM4MTdd IEFDUEk6IFBDSSBJbnRlcnJ1cHQgTGluayBbTE1BQ10gKElSUXMgMjAgMjEgMjIgMjMpICo1 DQpbICAgIDAuMDUzOTU1XSBBQ1BJOiBQQ0kgSW50ZXJydXB0IExpbmsgW0xBWkFdIChJUlFz IDIwIDIxIDIyIDIzKSAqMTANClsgICAgMC4wNTQwOTJdIEFDUEk6IFBDSSBJbnRlcnJ1cHQg TGluayBbTE1DOV0gKElSUXMgMjAgMjEgMjIgMjMpICoxMQ0KWyAgICAwLjA1NDIyOV0gQUNQ STogUENJIEludGVycnVwdCBMaW5rIFtMU01CXSAoSVJRcyAyMCAyMSAyMiAyMykgKjEwDQpb ICAgIDAuMDU0MzYzXSBBQ1BJOiBQQ0kgSW50ZXJydXB0IExpbmsgW0xQTVVdIChJUlFzIDIw IDIxIDIyIDIzKSAqMCwgZGlzYWJsZWQuDQpbICAgIDAuMDU0NTAzXSBBQ1BJOiBQQ0kgSW50 ZXJydXB0IExpbmsgW0xTQTBdIChJUlFzIDIwIDIxIDIyIDIzKSAqMTENClsgICAgMC4wNTQ2 MzldIEFDUEk6IFBDSSBJbnRlcnJ1cHQgTGluayBbTFNBMV0gKElSUXMgMjAgMjEgMjIgMjMp ICoxMQ0KWyAgICAwLjA1NDc4Nl0gQUNQSTogUENJIEludGVycnVwdCBMaW5rIFtMQVRBXSAo SVJRcyAyMCAyMSAyMiAyMykgKjAsIGRpc2FibGVkLg0KWyAgICAwLjA1NDg0Ml0gaW5pdGNh bGwgYWNwaV9wY2lfbGlua19pbml0KzB4MC8weDNmIHJldHVybmVkIDAgYWZ0ZXIgMCB1c2Vj cw0KWyAgICAwLjA1NDg1NF0gY2FsbGluZyAgcG5wX2luaXQrMHgwLzB4ZiBAIDENClsgICAg MC4wNTQ4NzBdIGluaXRjYWxsIHBucF9pbml0KzB4MC8weGYgcmV0dXJuZWQgMCBhZnRlciAw IHVzZWNzDQpbICAgIDAuMDU0ODgzXSBjYWxsaW5nICB4ZW5fc2V0dXBfc2h1dGRvd25fZXZl bnQrMHgwLzB4MzAgQCAxDQpbICAgIDAuMDU0ODk0XSBpbml0Y2FsbCB4ZW5fc2V0dXBfc2h1 dGRvd25fZXZlbnQrMHgwLzB4MzAgcmV0dXJuZWQgMCBhZnRlciAwIHVzZWNzDQpbICAgIDAu MDU0OTA4XSBjYWxsaW5nICBiYWxsb29uX2luaXQrMHgwLzB4MTZiIEAgMQ0KWyAgICAwLjA1 NDkxN10geGVuL2JhbGxvb246IEluaXRpYWxpc2luZyBiYWxsb29uIGRyaXZlci4NClsgICAg MC4wNTQ5MjddIGxhc3RfcGZuID0gMHgxNzU1OTAgbWF4X2FyY2hfcGZuID0gMHgxMDAwMDAw DQpbICAgIDAuMDYwMzY3XSBpbml0Y2FsbCBiYWxsb29uX2luaXQrMHgwLzB4MTZiIHJldHVy bmVkIDAgYWZ0ZXIgNzgxMiB1c2Vjcw0KWyAgICAwLjA2MDM4OV0gY2FsbGluZyAgeGVuYnVz X3Byb2JlX2JhY2tlbmRfaW5pdCsweDAvMHgyMyBAIDENClsgICAgMC4wNjA0MjVdIGluaXRj YWxsIHhlbmJ1c19wcm9iZV9iYWNrZW5kX2luaXQrMHgwLzB4MjMgcmV0dXJuZWQgMCBhZnRl ciAwIHVzZWNzDQpbICAgIDAuMDYwNDQwXSBjYWxsaW5nICB4ZW5idXNfcHJvYmVfZnJvbnRl bmRfaW5pdCsweDAvMHgyMyBAIDENClsgICAgMC4wNjA0NjRdIGluaXRjYWxsIHhlbmJ1c19w cm9iZV9mcm9udGVuZF9pbml0KzB4MC8weDIzIHJldHVybmVkIDAgYWZ0ZXIgMCB1c2Vjcw0K WyAgICAwLjA2MDQ3OF0gY2FsbGluZyAgYmFsbG9vbl9pbml0KzB4MC8weGU1IEAgMQ0KWyAg ICAwLjA2MDQ4N10geGVuLWJhbGxvb246IEluaXRpYWxpc2luZyBiYWxsb29uIGRyaXZlci4N ClsgICAgMC4wNjA1MTFdIGluaXRjYWxsIGJhbGxvb25faW5pdCsweDAvMHhlNSByZXR1cm5l ZCAwIGFmdGVyIDAgdXNlY3MNClsgICAgMC4wNjA1MjRdIGNhbGxpbmcgIHBtODYwN19yZWd1 bGF0b3JfaW5pdCsweDAvMHhmIEAgMQ0KWyAgICAwLjA2MDU0NF0gaW5pdGNhbGwgcG04NjA3 X3JlZ3VsYXRvcl9pbml0KzB4MC8weGYgcmV0dXJuZWQgMCBhZnRlciAwIHVzZWNzDQpbICAg IDAuMDYwNTU2XSBjYWxsaW5nICBhYjg1MDBfcmVndWxhdG9yX2luaXQrMHgwLzB4MmUgQCAx DQpbICAgIDAuMDYwNTcyXSBpbml0Y2FsbCBhYjg1MDBfcmVndWxhdG9yX2luaXQrMHgwLzB4 MmUgcmV0dXJuZWQgMCBhZnRlciAwIHVzZWNzDQpbICAgIDAuMDYwNTg2XSBjYWxsaW5nICBt aXNjX2luaXQrMHgwLzB4YWQgQCAxDQpbICAgIDAuMDYwNjA3XSBpbml0Y2FsbCBtaXNjX2lu aXQrMHgwLzB4YWQgcmV0dXJuZWQgMCBhZnRlciAwIHVzZWNzDQpbICAgIDAuMDYwNjE5XSBj YWxsaW5nICB2Z2FfYXJiX2RldmljZV9pbml0KzB4MC8weGNjIEAgMQ0KWyAgICAwLjA2MDY4 NV0gdmdhYXJiOiBkZXZpY2UgYWRkZWQ6IFBDSTowMDAwOjAwOjBkLjAsZGVjb2Rlcz1pbytt ZW0sb3ducz1pbyttZW0sbG9ja3M9bm9uZQ0KWyAgICAwLjA2MDcwMl0gdmdhYXJiOiBsb2Fk ZWQNClsgICAgMC4wNjA3MDhdIHZnYWFyYjogYnJpZGdlIGNvbnRyb2wgcG9zc2libGUgMDAw MDowMDowZC4wDQpbICAgIDAuMDYwNzE4XSBpbml0Y2FsbCB2Z2FfYXJiX2RldmljZV9pbml0 KzB4MC8weGNjIHJldHVybmVkIDAgYWZ0ZXIgMCB1c2Vjcw0KWyAgICAwLjA2MDczMV0gY2Fs bGluZyAgY25faW5pdCsweDAvMHg5OCBAIDENClsgICAgMC4wNjA3NDhdIGluaXRjYWxsIGNu X2luaXQrMHgwLzB4OTggcmV0dXJuZWQgMCBhZnRlciAwIHVzZWNzDQpbICAgIDAuMDYwNzYw XSBjYWxsaW5nICBwbTg2MHhfaTJjX2luaXQrMHgwLzB4MzAgQCAxDQpbICAgIDAuMDYwNzc3 XSBpbml0Y2FsbCBwbTg2MHhfaTJjX2luaXQrMHgwLzB4MzAgcmV0dXJuZWQgMCBhZnRlciAw IHVzZWNzDQpbICAgIDAuMDYwNzg5XSBjYWxsaW5nICBzdG1wZV9pbml0KzB4MC8weDExIEAg MQ0KWyAgICAwLjA2MDgwNF0gaW5pdGNhbGwgc3RtcGVfaW5pdCsweDAvMHgxMSByZXR1cm5l ZCAwIGFmdGVyIDAgdXNlY3MNClsgICAgMC4wNjA4MTZdIGNhbGxpbmcgIHRjMzU4OXhfaW5p dCsweDAvMHgxMSBAIDENClsgICAgMC4wNjA4MzFdIGluaXRjYWxsIHRjMzU4OXhfaW5pdCsw eDAvMHgxMSByZXR1cm5lZCAwIGFmdGVyIDAgdXNlY3MNClsgICAgMC4wNjA4NDJdIGNhbGxp bmcgIHdtODMxeF9pMmNfaW5pdCsweDAvMHgzMCBAIDENClsgICAgMC4wNjA4NThdIGluaXRj YWxsIHdtODMxeF9pMmNfaW5pdCsweDAvMHgzMCByZXR1cm5lZCAwIGFmdGVyIDAgdXNlY3MN ClsgICAgMC4wNjA4NzBdIGNhbGxpbmcgIHdtODM1MF9pMmNfaW5pdCsweDAvMHgxMSBAIDEN ClsgICAgMC4wNjA4ODVdIGluaXRjYWxsIHdtODM1MF9pMmNfaW5pdCsweDAvMHgxMSByZXR1 cm5lZCAwIGFmdGVyIDAgdXNlY3MNClsgICAgMC4wNjA4OTZdIGNhbGxpbmcgIGRhOTAzeF9p bml0KzB4MC8weDExIEAgMQ0KWyAgICAwLjA2MDkxMV0gaW5pdGNhbGwgZGE5MDN4X2luaXQr MHgwLzB4MTEgcmV0dXJuZWQgMCBhZnRlciAwIHVzZWNzDQpbICAgIDAuMDYwOTIzXSBjYWxs aW5nICBtYXg4OTI1X2kyY19pbml0KzB4MC8weDMwIEAgMQ0KWyAgICAwLjA2MDkzOF0gaW5p dGNhbGwgbWF4ODkyNV9pMmNfaW5pdCsweDAvMHgzMCByZXR1cm5lZCAwIGFmdGVyIDAgdXNl Y3MNClsgICAgMC4wNjA5NTBdIGNhbGxpbmcgIG1heDg5OThfaTJjX2luaXQrMHgwLzB4MTEg QCAxDQpbICAgIDAuMDYwOTY1XSBpbml0Y2FsbCBtYXg4OTk4X2kyY19pbml0KzB4MC8weDEx IHJldHVybmVkIDAgYWZ0ZXIgMCB1c2Vjcw0KWyAgICAwLjA2MDk3N10gY2FsbGluZyAgYWIz MTAwX2kyY19pbml0KzB4MC8weDExIEAgMQ0KWyAgICAwLjA2MDk5Ml0gaW5pdGNhbGwgYWIz MTAwX2kyY19pbml0KzB4MC8weDExIHJldHVybmVkIDAgYWZ0ZXIgMCB1c2Vjcw0KWyAgICAw LjA2MTAwNF0gY2FsbGluZyAgYWIzNTUwX2kyY19pbml0KzB4MC8weDExIEAgMQ0KWyAgICAw LjA2MTAxOV0gaW5pdGNhbGwgYWIzNTUwX2kyY19pbml0KzB4MC8weDExIHJldHVybmVkIDAg YWZ0ZXIgMCB1c2Vjcw0KWyAgICAwLjA2MTAzMV0gY2FsbGluZyAgYWI4NTAwX3N5c2N0cmxf aW5pdCsweDAvMHhmIEAgMQ0KWyAgICAwLjA2MTA0N10gaW5pdGNhbGwgYWI4NTAwX3N5c2N0 cmxfaW5pdCsweDAvMHhmIHJldHVybmVkIDAgYWZ0ZXIgMCB1c2Vjcw0KWyAgICAwLjA2MTA1 OF0gY2FsbGluZyAgYWI4NTAwX2RlYnVnX2luaXQrMHgwLzB4ZiBAIDENClsgICAgMC4wNjEw NzNdIGluaXRjYWxsIGFiODUwMF9kZWJ1Z19pbml0KzB4MC8weGYgcmV0dXJuZWQgMCBhZnRl ciAwIHVzZWNzDQpbICAgIDAuMDYxMDg1XSBjYWxsaW5nICB0cHM2NTg2eF9pbml0KzB4MC8w eDExIEAgMQ0KWyAgICAwLjA2MTEwM10gaW5pdGNhbGwgdHBzNjU4NnhfaW5pdCsweDAvMHgx MSByZXR1cm5lZCAwIGFmdGVyIDAgdXNlY3MNClsgICAgMC4wNjExMTVdIGNhbGxpbmcgIGlu aXRfc2NzaSsweDAvMHg5MCBAIDENClsgICAgMC4wNjExOThdIFNDU0kgc3Vic3lzdGVtIGlu aXRpYWxpemVkDQpbICAgIDAuMDYxMjA3XSBpbml0Y2FsbCBpbml0X3Njc2krMHgwLzB4OTAg cmV0dXJuZWQgMCBhZnRlciAwIHVzZWNzDQpbICAgIDAuMDYxMjE5XSBjYWxsaW5nICBhdGFf aW5pdCsweDAvMHgyOTAgQCAxDQpbICAgIDAuMDYxMjkxXSBsaWJhdGEgdmVyc2lvbiAzLjAw IGxvYWRlZC4NClsgICAgMC4wNjEyOTFdIGluaXRjYWxsIGF0YV9pbml0KzB4MC8weDI5MCBy ZXR1cm5lZCAwIGFmdGVyIDAgdXNlY3MNClsgICAgMC4wNjEyOTFdIGNhbGxpbmcgIHBoeV9p bml0KzB4MC8weDJhIEAgMQ0KWyAgICAwLjA2MTI5MV0gaW5pdGNhbGwgcGh5X2luaXQrMHgw LzB4MmEgcmV0dXJuZWQgMCBhZnRlciAwIHVzZWNzDQpbICAgIDAuMDYxMjkxXSBjYWxsaW5n ICB1c2JfaW5pdCsweDAvMHgxNDIgQCAxDQpbICAgIDAuMDYxMjkxXSB1c2Jjb3JlOiByZWdp c3RlcmVkIG5ldyBpbnRlcmZhY2UgZHJpdmVyIHVzYmZzDQpbICAgIDAuMDYxMjkxXSB1c2Jj b3JlOiByZWdpc3RlcmVkIG5ldyBpbnRlcmZhY2UgZHJpdmVyIGh1Yg0KWyAgICAwLjA2MTI5 MV0gdXNiY29yZTogcmVnaXN0ZXJlZCBuZXcgZGV2aWNlIGRyaXZlciB1c2INClsgICAgMC4w NjEyOTFdIGluaXRjYWxsIHVzYl9pbml0KzB4MC8weDE0MiByZXR1cm5lZCAwIGFmdGVyIDAg dXNlY3MNClsgICAgMC4wNjEyOTFdIGNhbGxpbmcgIHNlcmlvX2luaXQrMHgwLzB4MmUgQCAx DQpbICAgIDAuMDYxMjkxXSBpbml0Y2FsbCBzZXJpb19pbml0KzB4MC8weDJlIHJldHVybmVk IDAgYWZ0ZXIgMCB1c2Vjcw0KWyAgICAwLjA2MTI5MV0gY2FsbGluZyAgaW5wdXRfaW5pdCsw eDAvMHhmZCBAIDENClsgICAgMC4wNjEyOTFdIGluaXRjYWxsIGlucHV0X2luaXQrMHgwLzB4 ZmQgcmV0dXJuZWQgMCBhZnRlciAwIHVzZWNzDQpbICAgIDAuMDYxMjkxXSBjYWxsaW5nICBy dGNfaW5pdCsweDAvMHg2NCBAIDENClsgICAgMC4wNjEyOTFdIGluaXRjYWxsIHJ0Y19pbml0 KzB4MC8weDY0IHJldHVybmVkIDAgYWZ0ZXIgMCB1c2Vjcw0KWyAgICAwLjA2MTI5MV0gY2Fs bGluZyAgcG93ZXJfc3VwcGx5X2NsYXNzX2luaXQrMHgwLzB4MzkgQCAxDQpbICAgIDAuMDYx MjkxXSBpbml0Y2FsbCBwb3dlcl9zdXBwbHlfY2xhc3NfaW5pdCsweDAvMHgzOSByZXR1cm5l ZCAwIGFmdGVyIDAgdXNlY3MNClsgICAgMC4wNjEyOTFdIGNhbGxpbmcgIGh3bW9uX2luaXQr MHgwLzB4ZTMgQCAxDQpbICAgIDAuMDYxMjkxXSBpbml0Y2FsbCBod21vbl9pbml0KzB4MC8w eGUzIHJldHVybmVkIDAgYWZ0ZXIgMCB1c2Vjcw0KWyAgICAwLjA2MTI5MV0gY2FsbGluZyAg bWRfaW5pdCsweDAvMHgxNTIgQCAxDQpbICAgIDAuMDYxMjkxXSBpbml0Y2FsbCBtZF9pbml0 KzB4MC8weDE1MiByZXR1cm5lZCAwIGFmdGVyIDAgdXNlY3MNClsgICAgMC4wNjEyOTFdIGNh bGxpbmcgIGxlZHNfaW5pdCsweDAvMHgzZCBAIDENClsgICAgMC4wNjEyOTFdIGluaXRjYWxs IGxlZHNfaW5pdCsweDAvMHgzZCByZXR1cm5lZCAwIGFmdGVyIDAgdXNlY3MNClsgICAgMC4w NjEyOTFdIGNhbGxpbmcgIHBjaV9zdWJzeXNfaW5pdCsweDAvMHg0OCBAIDENClsgICAgMC4w NjEyOTFdIFBDSTogVXNpbmcgQUNQSSBmb3IgSVJRIHJvdXRpbmcNClsgICAgMC4wNjEyOTFd IFBDSTogcGNpX2NhY2hlX2xpbmVfc2l6ZSBzZXQgdG8gNjQgYnl0ZXMNClsgICAgMC4wNjEy OTFdIHJlc2VydmUgUkFNIGJ1ZmZlcjogMDAwMDAwMDAwMDA5YjAwMCAtIDAwMDAwMDAwMDAw OWZmZmYgDQpbICAgIDAuMDYxMjkxXSByZXNlcnZlIFJBTSBidWZmZXI6IDAwMDAwMDAwYWZm OTAwMDAgLSAwMDAwMDAwMGFmZmZmZmZmIA0KWyAgICAwLjA2MTI5MV0gcmVzZXJ2ZSBSQU0g YnVmZmVyOiAwMDAwMDAwMTc1NTkwMDAwIC0gMDAwMDAwMDE3N2ZmZmZmZiANClsgICAgMC4w NjEyOTFdIGluaXRjYWxsIHBjaV9zdWJzeXNfaW5pdCsweDAvMHg0OCByZXR1cm5lZCAwIGFm dGVyIDAgdXNlY3MNClsgICAgMC4wNjEyOTFdIGNhbGxpbmcgIHByb3RvX2luaXQrMHgwLzB4 ZiBAIDENClsgICAgMC4wNjEyOTFdIGluaXRjYWxsIHByb3RvX2luaXQrMHgwLzB4ZiByZXR1 cm5lZCAwIGFmdGVyIDAgdXNlY3MNClsgICAgMC4wNjEyOTFdIGNhbGxpbmcgIG5ldF9kZXZf aW5pdCsweDAvMHgxNjEgQCAxDQpbICAgIDAuMDYxMjkxXSBpbml0Y2FsbCBuZXRfZGV2X2lu aXQrMHgwLzB4MTYxIHJldHVybmVkIDAgYWZ0ZXIgMCB1c2Vjcw0KWyAgICAwLjA2MTI5MV0g Y2FsbGluZyAgbmVpZ2hfaW5pdCsweDAvMHg3YyBAIDENClsgICAgMC4wNjEyOTFdIGluaXRj YWxsIG5laWdoX2luaXQrMHgwLzB4N2MgcmV0dXJuZWQgMCBhZnRlciAwIHVzZWNzDQpbICAg IDAuMDYxMjkxXSBjYWxsaW5nICBmaWJfcnVsZXNfaW5pdCsweDAvMHhhNCBAIDENClsgICAg MC4wNjEyOTFdIGluaXRjYWxsIGZpYl9ydWxlc19pbml0KzB4MC8weGE0IHJldHVybmVkIDAg YWZ0ZXIgMCB1c2Vjcw0KWyAgICAwLjA2MTI5MV0gY2FsbGluZyAgcGt0c2NoZWRfaW5pdCsw eDAvMHhlNiBAIDENClsgICAgMC4wNjEyOTFdIGluaXRjYWxsIHBrdHNjaGVkX2luaXQrMHgw LzB4ZTYgcmV0dXJuZWQgMCBhZnRlciAwIHVzZWNzDQpbICAgIDAuMDYxMjkxXSBjYWxsaW5n ICB0Y19maWx0ZXJfaW5pdCsweDAvMHg1MiBAIDENClsgICAgMC4wNjEyOTFdIGluaXRjYWxs IHRjX2ZpbHRlcl9pbml0KzB4MC8weDUyIHJldHVybmVkIDAgYWZ0ZXIgMCB1c2Vjcw0KWyAg ICAwLjA2MTI5MV0gY2FsbGluZyAgdGNfYWN0aW9uX2luaXQrMHgwLzB4NTIgQCAxDQpbICAg IDAuMDYxMjkxXSBpbml0Y2FsbCB0Y19hY3Rpb25faW5pdCsweDAvMHg1MiByZXR1cm5lZCAw IGFmdGVyIDAgdXNlY3MNClsgICAgMC4wNjEyOTFdIGNhbGxpbmcgIGdlbmxfaW5pdCsweDAv MHg3NiBAIDENClsgICAgMC4wNjEyOTFdIGluaXRjYWxsIGdlbmxfaW5pdCsweDAvMHg3NiBy ZXR1cm5lZCAwIGFmdGVyIDAgdXNlY3MNClsgICAgMC4wNjEyOTFdIGNhbGxpbmcgIHN5c2N0 bF9pbml0KzB4MC8weDNiIEAgMQ0KWyAgICAwLjA2MTI5MV0gaW5pdGNhbGwgc3lzY3RsX2lu aXQrMHgwLzB4M2IgcmV0dXJuZWQgMCBhZnRlciAwIHVzZWNzDQpbICAgIDAuMDYxMjkxXSBj YWxsaW5nICBhYjg1MDBfZ3BhZGNfaW5pdCsweDAvMHhmIEAgMQ0KWyAgICAwLjA2MTI5MV0g aW5pdGNhbGwgYWI4NTAwX2dwYWRjX2luaXQrMHgwLzB4ZiByZXR1cm5lZCAwIGFmdGVyIDAg dXNlY3MNClsgICAgMC4wNjEyOTFdIGNhbGxpbmcgIHByaW50X0lDcysweDAvMHg0ZWUgQCAx DQpbICAgIDAuMDYxMjkxXSBpbml0Y2FsbCBwcmludF9JQ3MrMHgwLzB4NGVlIHJldHVybmVk IDAgYWZ0ZXIgMCB1c2Vjcw0KWyAgICAwLjA2MTI5MV0gY2FsbGluZyAgaHBldF9sYXRlX2lu aXQrMHgwLzB4ZGMgQCAxDQpbICAgIDAuMDYxMjkxXSBpbml0Y2FsbCBocGV0X2xhdGVfaW5p dCsweDAvMHhkYyByZXR1cm5lZCAtMTkgYWZ0ZXIgMCB1c2Vjcw0KWyAgICAwLjA2MTI5MV0g Y2FsbGluZyAgaW5pdF9hbWRfbmJzKzB4MC8weGJhIEAgMQ0KWyAgICAwLjA2MTI5MV0gaW5p dGNhbGwgaW5pdF9hbWRfbmJzKzB4MC8weGJhIHJldHVybmVkIDAgYWZ0ZXIgMCB1c2Vjcw0K WyAgICAwLjA2MTI5MV0gY2FsbGluZyAgY2xvY2tzb3VyY2VfZG9uZV9ib290aW5nKzB4MC8w eDRmIEAgMQ0KWyAgICAwLjA2MTI5MV0gU3dpdGNoaW5nIHRvIGNsb2Nrc291cmNlIHhlbg0K WyAgICAwLjA2MTI5MV0gaW5pdGNhbGwgY2xvY2tzb3VyY2VfZG9uZV9ib290aW5nKzB4MC8w eDRmIHJldHVybmVkIDAgYWZ0ZXIgMyB1c2Vjcw0KWyAgICAwLjA2MTI5MV0gY2FsbGluZyAg ZnRyYWNlX2luaXRfZGVidWdmcysweDAvMHgyMWIgQCAxDQpbICAgIDAuMDYxMjkxXSBpbml0 Y2FsbCBmdHJhY2VfaW5pdF9kZWJ1Z2ZzKzB4MC8weDIxYiByZXR1cm5lZCAwIGFmdGVyIDE5 IHVzZWNzDQpbICAgIDAuMDYxMjkxXSBjYWxsaW5nICByYl9pbml0X2RlYnVnZnMrMHgwLzB4 MmYgQCAxDQpbICAgIDAuMDYxMjkxXSBpbml0Y2FsbCByYl9pbml0X2RlYnVnZnMrMHgwLzB4 MmYgcmV0dXJuZWQgMCBhZnRlciAxIHVzZWNzDQpbICAgIDAuMDYxMjkxXSBjYWxsaW5nICB0 cmFjZXJfaW5pdF9kZWJ1Z2ZzKzB4MC8weDM2NyBAIDENClsgICAgMC4wNjEyOTFdIGluaXRj YWxsIHRyYWNlcl9pbml0X2RlYnVnZnMrMHgwLzB4MzY3IHJldHVybmVkIDAgYWZ0ZXIgNDUg dXNlY3MNClsgICAgMC4wNjEyOTFdIGNhbGxpbmcgIGluaXRfdHJhY2VfcHJpbnRrX2Z1bmN0 aW9uX2V4cG9ydCsweDAvMHgzMyBAIDENClsgICAgMC4wNjEyOTFdIGluaXRjYWxsIGluaXRf dHJhY2VfcHJpbnRrX2Z1bmN0aW9uX2V4cG9ydCsweDAvMHgzMyByZXR1cm5lZCAwIGFmdGVy IDEgdXNlY3MNClsgICAgMC4wNjEyOTFdIGNhbGxpbmcgIGV2ZW50X3RyYWNlX2luaXQrMHgw LzB4MmE4IEAgMQ0KWyAgICAwLjA2MTUwOF0gU3dpdGNoZWQgdG8gTk9IeiBtb2RlIG9uIENQ VSAjMQ0KWyAgICAwLjA2MTY1Ml0gU3dpdGNoZWQgdG8gTk9IeiBtb2RlIG9uIENQVSAjMA0K WyAgICAwLjA2NTAwMV0gaW5pdGNhbGwgZXZlbnRfdHJhY2VfaW5pdCsweDAvMHgyYTggcmV0 dXJuZWQgMCBhZnRlciA0Njg2IHVzZWNzDQpbICAgIDAuMDY1MDI0XSBjYWxsaW5nICBpbml0 X3BpcGVfZnMrMHgwLzB4M2QgQCAxDQpbICAgIDAuMDY1MDUxXSBpbml0Y2FsbCBpbml0X3Bp cGVfZnMrMHgwLzB4M2QgcmV0dXJuZWQgMCBhZnRlciAxNiB1c2Vjcw0KWyAgICAwLjA2NTA2 M10gY2FsbGluZyAgZXZlbnRwb2xsX2luaXQrMHgwLzB4ZWYgQCAxDQpbICAgIDAuMDY1MDg0 XSBpbml0Y2FsbCBldmVudHBvbGxfaW5pdCsweDAvMHhlZiByZXR1cm5lZCAwIGFmdGVyIDEw IHVzZWNzDQpbICAgIDAuMDY1MDk3XSBjYWxsaW5nICBhbm9uX2lub2RlX2luaXQrMHgwLzB4 MTAwIEAgMQ0KWyAgICAwLjA2NTExNF0gaW5pdGNhbGwgYW5vbl9pbm9kZV9pbml0KzB4MC8w eDEwMCByZXR1cm5lZCAwIGFmdGVyIDYgdXNlY3MNClsgICAgMC4wNjUxMjZdIGNhbGxpbmcg IGJsa19zY3NpX2lvY3RsX2luaXQrMHgwLzB4Mjg4IEAgMQ0KWyAgICAwLjA2NTEzN10gaW5p dGNhbGwgYmxrX3Njc2lfaW9jdGxfaW5pdCsweDAvMHgyODggcmV0dXJuZWQgMCBhZnRlciAw IHVzZWNzDQpbICAgIDAuMDY1MTQ5XSBjYWxsaW5nICBhY3BpX2V2ZW50X2luaXQrMHgwLzB4 NzkgQCAxDQpbICAgIDAuMDY1MTcyXSBpbml0Y2FsbCBhY3BpX2V2ZW50X2luaXQrMHgwLzB4 NzkgcmV0dXJuZWQgMCBhZnRlciAxMSB1c2Vjcw0KWyAgICAwLjA2NTE4NF0gY2FsbGluZyAg cG5wX3N5c3RlbV9pbml0KzB4MC8weGYgQCAxDQpbICAgIDAuMDY1MjExXSBpbml0Y2FsbCBw bnBfc3lzdGVtX2luaXQrMHgwLzB4ZiByZXR1cm5lZCAwIGFmdGVyIDE2IHVzZWNzDQpbICAg IDAuMDY1MjI0XSBjYWxsaW5nICBwbnBhY3BpX2luaXQrMHgwLzB4ODggQCAxDQpbICAgIDAu MDY1MjMzXSBwbnA6IFBuUCBBQ1BJIGluaXQNClsgICAgMC4wNjUyNTRdIEFDUEk6IGJ1cyB0 eXBlIHBucCByZWdpc3RlcmVkDQpbICAgIDAuMDY1NDA3XSBwbnAgMDA6MDA6IFtidXMgMDAt ZmZdDQpbICAgIDAuMDY1NDE3XSBwbnAgMDA6MDA6IFtpbyAgMHgwY2Y4LTB4MGNmZl0NClsg ICAgMC4wNjU0MjZdIHBucCAwMDowMDogW2lvICAweDAwMDAtMHgwY2Y3IHdpbmRvd10NClsg ICAgMC4wNjU0MzZdIHBucCAwMDowMDogW2lvICAweDBkMDAtMHhmZmZmIHdpbmRvd10NClsg ICAgMC4wNjU0NDZdIHBucCAwMDowMDogW21lbSAweDAwMGEwMDAwLTB4MDAwYmZmZmYgd2lu ZG93XQ0KWyAgICAwLjA2NTQ1Nl0gcG5wIDAwOjAwOiBbbWVtIDB4MDAwZDAwMDAtMHgwMDBk ZmZmZiB3aW5kb3ddDQpbICAgIDAuMDY1NDY2XSBwbnAgMDA6MDA6IFttZW0gMHhiMDAwMDAw MC0weGRmZmZmZmZmIHdpbmRvd10NClsgICAgMC4wNjU0NzZdIHBucCAwMDowMDogW21lbSAw eGYwMDAwMDAwLTB4ZmVkNDRmZmYgd2luZG93XQ0KWyAgICAwLjA2NTU2MV0gcG5wIDAwOjAw OiBQbHVnIGFuZCBQbGF5IEFDUEkgZGV2aWNlLCBJRHMgUE5QMGEwMyAoYWN0aXZlKQ0KWyAg ICAwLjA2NTYwNV0gcG5wIDAwOjAxOiBbZG1hIDRdDQpbICAgIDAuMDY1NjE0XSBwbnAgMDA6 MDE6IFtpbyAgMHgwMDAwLTB4MDAwZl0NClsgICAgMC4wNjU2MjJdIHBucCAwMDowMTogW2lv ICAweDAwODEtMHgwMDgzXQ0KWyAgICAwLjA2NTYzMF0gcG5wIDAwOjAxOiBbaW8gIDB4MDA4 N10NClsgICAgMC4wNjU2MzhdIHBucCAwMDowMTogW2lvICAweDAwODktMHgwMDhiXQ0KWyAg ICAwLjA2NTY0Nl0gcG5wIDAwOjAxOiBbaW8gIDB4MDA4Zl0NClsgICAgMC4wNjU2NTRdIHBu cCAwMDowMTogW2lvICAweDAwYzAtMHgwMGRmXQ0KWyAgICAwLjA2NTY4M10gcG5wIDAwOjAx OiBQbHVnIGFuZCBQbGF5IEFDUEkgZGV2aWNlLCBJRHMgUE5QMDIwMCAoYWN0aXZlKQ0KWyAg ICAwLjA2NTcwOF0gcG5wIDAwOjAyOiBbaW8gIDB4MDA3MC0weDAwNzFdDQpbICAgIDAuMDY1 NzE4XSB4ZW46IHJlZ2lzdGVyaW5nIGdzaSA4IHRyaWdnZXJpbmcgMSBwb2xhcml0eSAwDQpb ICAgIDAuMDY1NzI5XSB4ZW5fbWFwX3BpcnFfZ3NpOiByZXR1cm5pbmcgaXJxIDggZm9yIGdz aSA4DQpbICAgIDAuMDY1NzM4XSB4ZW46IC0tPiBwaXJxPTggLT4gaXJxPTggKGdzaT04KQ0K WyAgICAwLjA2NTc2MF0gcG5wIDAwOjAyOiBbaXJxIDhdDQpbICAgIDAuMDY1NzkyXSBwbnAg MDA6MDI6IFBsdWcgYW5kIFBsYXkgQUNQSSBkZXZpY2UsIElEcyBQTlAwYjAwIChhY3RpdmUp DQpbICAgIDAuMDY1ODEyXSBwbnAgMDA6MDM6IFtpbyAgMHgwMDYxXQ0KWyAgICAwLjA2NTgz OV0gcG5wIDAwOjAzOiBQbHVnIGFuZCBQbGF5IEFDUEkgZGV2aWNlLCBJRHMgUE5QMDgwMCAo YWN0aXZlKQ0KWyAgICAwLjA2NTg2M10gcG5wIDAwOjA0OiBbaW8gIDB4MDBmMC0weDAwZmZd DQpbICAgIDAuMDY1ODcyXSB4ZW46IHJlZ2lzdGVyaW5nIGdzaSAxMyB0cmlnZ2VyaW5nIDEg cG9sYXJpdHkgMA0KWyAgICAwLjA2NTg4Ml0geGVuX21hcF9waXJxX2dzaTogcmV0dXJuaW5n IGlycSAxMyBmb3IgZ3NpIDEzDQpbICAgIDAuMDY1ODkxXSB4ZW46IC0tPiBwaXJxPTEzIC0+ IGlycT0xMyAoZ3NpPTEzKQ0KWyAgICAwLjA2NTkwNl0gcG5wIDAwOjA0OiBbaXJxIDEzXQ0K WyAgICAwLjA2NTkzNV0gcG5wIDAwOjA0OiBQbHVnIGFuZCBQbGF5IEFDUEkgZGV2aWNlLCBJ RHMgUE5QMGMwNCAoYWN0aXZlKQ0KWyAgICAwLjA2NjkwMl0gcG5wIDAwOjA1OiBbaW8gIDB4 MDM3OC0weDAzN2ZdDQpbICAgIDAuMDY2OTExXSB4ZW46IHJlZ2lzdGVyaW5nIGdzaSA3IHRy aWdnZXJpbmcgMSBwb2xhcml0eSAwDQpbICAgIDAuMDY2OTIxXSB4ZW5fbWFwX3BpcnFfZ3Np OiByZXR1cm5pbmcgaXJxIDcgZm9yIGdzaSA3DQpbICAgIDAuMDY2OTMwXSB4ZW46IC0tPiBw aXJxPTcgLT4gaXJxPTcgKGdzaT03KQ0KWyAgICAwLjA2Njk0NV0gcG5wIDAwOjA1OiBbaXJx IDddDQpbICAgIDAuMDY2OTUzXSBwbnAgMDA6MDU6IFtkbWEgMCBkaXNhYmxlZF0NClsgICAg MC4wNjcyMDddIHBucCAwMDowNTogUGx1ZyBhbmQgUGxheSBBQ1BJIGRldmljZSwgSURzIFBO UDA0MDAgKGFjdGl2ZSkNClsgICAgMC4wNjc3ODVdIHBucCAwMDowNjogW21lbSAweDAwMGQw MDAwLTB4MDAwZDNmZmYgd2luZG93XQ0KWyAgICAwLjA2Nzc5Nl0gcG5wIDAwOjA2OiBbbWVt IDB4MDAwZDQwMDAtMHgwMDBkN2ZmZiB3aW5kb3ddDQpbICAgIDAuMDY3ODA2XSBwbnAgMDA6 MDY6IFttZW0gMHgwMDBkZTAwMC0weDAwMGRmZmZmIHdpbmRvd10NClsgICAgMC4wNjc4MTZd IHBucCAwMDowNjogW2lvICAweDAwMTAtMHgwMDFmXQ0KWyAgICAwLjA2NzgyNV0gcG5wIDAw OjA2OiBbaW8gIDB4MDAyMi0weDAwM2ZdDQpbICAgIDAuMDY3ODMzXSBwbnAgMDA6MDY6IFtp byAgMHgwMDQ0LTB4MDA0ZF0NClsgICAgMC4wNjc4NDFdIHBucCAwMDowNjogW2lvICAweDAw NTAtMHgwMDVmXQ0KWyAgICAwLjA2Nzg0OV0gcG5wIDAwOjA2OiBbaW8gIDB4MDA2Mi0weDAw NjNdDQpbICAgIDAuMDY3ODU3XSBwbnAgMDA6MDY6IFtpbyAgMHgwMDY1LTB4MDA2Zl0NClsg ICAgMC4wNjc4NjVdIHBucCAwMDowNjogW2lvICAweDAwNzItMHgwMDdmXQ0KWyAgICAwLjA2 Nzg3M10gcG5wIDAwOjA2OiBbaW8gIDB4MDA4MF0NClsgICAgMC4wNjc4ODFdIHBucCAwMDow NjogW2lvICAweDAwODQtMHgwMDg2XQ0KWyAgICAwLjA2Nzg4OV0gcG5wIDAwOjA2OiBbaW8g IDB4MDA4OF0NClsgICAgMC4wNjc4OTddIHBucCAwMDowNjogW2lvICAweDAwOGMtMHgwMDhl XQ0KWyAgICAwLjA2NzkwNV0gcG5wIDAwOjA2OiBbaW8gIDB4MDA5MC0weDAwOWZdDQpbICAg IDAuMDY3OTE0XSBwbnAgMDA6MDY6IFtpbyAgMHgwMGEyLTB4MDBiZl0NClsgICAgMC4wNjc5 MjJdIHBucCAwMDowNjogW2lvICAweDAwZTAtMHgwMGVmXQ0KWyAgICAwLjA2NzkzMF0gcG5w IDAwOjA2OiBbaW8gIDB4MDRkMC0weDA0ZDFdDQpbICAgIDAuMDY3OTM4XSBwbnAgMDA6MDY6 IFtpbyAgMHgwODAwLTB4MDgwZl0NClsgICAgMC4wNjc5NDZdIHBucCAwMDowNjogW2lvICAw eDA1MDAtMHgwNTdmXQ0KWyAgICAwLjA2Nzk1NF0gcG5wIDAwOjA2OiBbaW8gIDB4MDU4MC0w eDA1ZmZdDQpbICAgIDAuMDY3OTYyXSBwbnAgMDA6MDY6IFtpbyAgMHgwODAwLTB4MDg3Zl0N ClsgICAgMC4wNjc5NzBdIHBucCAwMDowNjogW2lvICAweDA4ODAtMHgwOGZmXQ0KWyAgICAw LjA2Nzk3OF0gcG5wIDAwOjA2OiBbaW8gIDB4MGQwMC0weDBkN2ZdDQpbICAgIDAuMDY3OTg3 XSBwbnAgMDA6MDY6IFtpbyAgMHgwZDgwLTB4MGRmZl0NClsgICAgMC4wNjc5OTVdIHBucCAw MDowNjogW2lvICAweDA5MDAtMHgwOTdmXQ0KWyAgICAwLjA2ODAwM10gcG5wIDAwOjA2OiBb aW8gIDB4MDk4MC0weDA5ZmZdDQpbICAgIDAuMDY4MDExXSBwbnAgMDA6MDY6IFtpbyAgMHgx MTAwLTB4MTE3Zl0NClsgICAgMC4wNjgwMTldIHBucCAwMDowNjogW2lvICAweDExODAtMHgx MWZmXQ0KWyAgICAwLjA2ODAyOF0gcG5wIDAwOjA2OiBbbWVtIDB4ZmVjODAwMDAtMHgxZmQ5 M2ZmZmZdDQpbICAgIDAuMDY4MDM4XSBwbnAgMDA6MDY6IFttZW0gMHhmZWZlMDAwMC0weGZl ZmUwMWZmXQ0KWyAgICAwLjA2ODA0N10gcG5wIDAwOjA2OiBbbWVtIDB4ZmVmZTEwMDAtMHhm ZWZlMWZmZl0NClsgICAgMC4wNjgwNThdIHBucCAwMDowNjogW21lbSAweGZlZTAxMDAwLTB4 ZmVlZmZmZmZdDQpbICAgIDAuMDY4MDY4XSBwbnAgMDA6MDY6IGRpc2FibGluZyBbaW8gIDB4 MDkwMC0weDA5N2ZdIGJlY2F1c2UgaXQgb3ZlcmxhcHMgMDAwMDowMDowMS4wIEJBUiAwIFtp byAgMHgwOTAwLTB4MDlmZl0NClsgICAgMC4wNjgwNjhdIHBucCAwMDowNjogZGlzYWJsaW5n IFtpbyAgMHgwOTgwLTB4MDlmZl0gYmVjYXVzZSBpdCBvdmVybGFwcyAwMDAwOjAwOjAxLjAg QkFSIDAgW2lvICAweDA5MDAtMHgwOWZmXQ0KWyAgICAwLjA2ODE3N10gc3lzdGVtIDAwOjA2 OiBbaW8gIDB4MDRkMC0weDA0ZDFdIGhhcyBiZWVuIHJlc2VydmVkDQpbICAgIDAuMDY4MTkw XSBzeXN0ZW0gMDA6MDY6IFtpbyAgMHgwODAwLTB4MDgwZl0gaGFzIGJlZW4gcmVzZXJ2ZWQN ClsgICAgMC4wNjgyMDJdIHN5c3RlbSAwMDowNjogW2lvICAweDA1MDAtMHgwNTdmXSBoYXMg YmVlbiByZXNlcnZlZA0KWyAgICAwLjA2ODIxNF0gc3lzdGVtIDAwOjA2OiBbaW8gIDB4MDU4 MC0weDA1ZmZdIGhhcyBiZWVuIHJlc2VydmVkDQpbICAgIDAuMDY4MjI2XSBzeXN0ZW0gMDA6 MDY6IFtpbyAgMHgwODAwLTB4MDg3Zl0gY291bGQgbm90IGJlIHJlc2VydmVkDQpbICAgIDAu MDY4MjM4XSBzeXN0ZW0gMDA6MDY6IFtpbyAgMHgwODgwLTB4MDhmZl0gaGFzIGJlZW4gcmVz ZXJ2ZWQNClsgICAgMC4wNjgyNTBdIHN5c3RlbSAwMDowNjogW2lvICAweDBkMDAtMHgwZDdm XSBoYXMgYmVlbiByZXNlcnZlZA0KWyAgICAwLjA2ODI2Ml0gc3lzdGVtIDAwOjA2OiBbaW8g IDB4MGQ4MC0weDBkZmZdIGhhcyBiZWVuIHJlc2VydmVkDQpbICAgIDAuMDY4Mjc0XSBzeXN0 ZW0gMDA6MDY6IFtpbyAgMHgxMTAwLTB4MTE3Zl0gaGFzIGJlZW4gcmVzZXJ2ZWQNClsgICAg MC4wNjgyODVdIHN5c3RlbSAwMDowNjogW2lvICAweDExODAtMHgxMWZmXSBoYXMgYmVlbiBy ZXNlcnZlZA0KWyAgICAwLjA2ODI5OF0gc3lzdGVtIDAwOjA2OiBbbWVtIDB4MDAwZDAwMDAt MHgwMDBkM2ZmZiB3aW5kb3ddIGNvdWxkIG5vdCBiZSByZXNlcnZlZA0KWyAgICAwLjA2ODMx Ml0gc3lzdGVtIDAwOjA2OiBbbWVtIDB4MDAwZDQwMDAtMHgwMDBkN2ZmZiB3aW5kb3ddIGNv dWxkIG5vdCBiZSByZXNlcnZlZA0KWyAgICAwLjA2ODMyNV0gc3lzdGVtIDAwOjA2OiBbbWVt IDB4MDAwZGUwMDAtMHgwMDBkZmZmZiB3aW5kb3ddIGNvdWxkIG5vdCBiZSByZXNlcnZlZA0K WyAgICAwLjA2ODMzOV0gc3lzdGVtIDAwOjA2OiBbbWVtIDB4ZmVjODAwMDAtMHgxZmQ5M2Zm ZmZdIGNvdWxkIG5vdCBiZSByZXNlcnZlZA0KWyAgICAwLjA2ODM1M10gc3lzdGVtIDAwOjA2 OiBbbWVtIDB4ZmVmZTAwMDAtMHhmZWZlMDFmZl0gaGFzIGJlZW4gcmVzZXJ2ZWQNClsgICAg MC4wNjgzNjVdIHN5c3RlbSAwMDowNjogW21lbSAweGZlZmUxMDAwLTB4ZmVmZTFmZmZdIGhh cyBiZWVuIHJlc2VydmVkDQpbICAgIDAuMDY4Mzc4XSBzeXN0ZW0gMDA6MDY6IFttZW0gMHhm ZWUwMTAwMC0weGZlZWZmZmZmXSBoYXMgYmVlbiByZXNlcnZlZA0KWyAgICAwLjA2ODM5MF0g c3lzdGVtIDAwOjA2OiBQbHVnIGFuZCBQbGF5IEFDUEkgZGV2aWNlLCBJRHMgUE5QMGMwMiAo YWN0aXZlKQ0KWyAgICAwLjA2ODQ4MF0gcG5wIDAwOjA3OiBbbWVtIDB4ZmVkMDAwMDAtMHhm ZWQwMGZmZl0NClsgICAgMC4wNjg1MTRdIHBucCAwMDowNzogUGx1ZyBhbmQgUGxheSBBQ1BJ IGRldmljZSwgSURzIFBOUDAxMDMgKGFjdGl2ZSkNClsgICAgMC4wNjg2MDldIHBucCAwMDow ODogW21lbSAweGZlYzAwMDAwLTB4ZmVjMDBmZmZdDQpbICAgIDAuMDY4NjIwXSBwbnAgMDA6 MDg6IFttZW0gMHhmZWUwMDAwMC0weGZlZTAwZmZmXQ0KWyAgICAwLjA2ODYyOV0gcG5wIDAw OjA4OiBbbWVtIDB4YjAwMDAwMDAtMHhiZmZmZmZmZl0NClsgICAgMC4wNjg2NzVdIHN5c3Rl bSAwMDowODogW21lbSAweGZlYzAwMDAwLTB4ZmVjMDBmZmZdIGNvdWxkIG5vdCBiZSByZXNl cnZlZA0KWyAgICAwLjA2ODY4OF0gc3lzdGVtIDAwOjA4OiBbbWVtIDB4ZmVlMDAwMDAtMHhm ZWUwMGZmZl0gaGFzIGJlZW4gcmVzZXJ2ZWQNClsgICAgMC4wNjg3MDJdIHN5c3RlbSAwMDow ODogW21lbSAweGIwMDAwMDAwLTB4YmZmZmZmZmZdIGhhcyBiZWVuIHJlc2VydmVkDQpbICAg IDAuMDY4NzE0XSBzeXN0ZW0gMDA6MDg6IFBsdWcgYW5kIFBsYXkgQUNQSSBkZXZpY2UsIElE cyBQTlAwYzAyIChhY3RpdmUpDQpbICAgIDAuMDY4NzUyXSBwbnAgMDA6MDk6IFtpbyAgMHgw MDYwXQ0KWyAgICAwLjA2ODc2MF0gcG5wIDAwOjA5OiBbaW8gIDB4MDA2NF0NClsgICAgMC4w Njg3NjhdIHhlbjogcmVnaXN0ZXJpbmcgZ3NpIDEgdHJpZ2dlcmluZyAxIHBvbGFyaXR5IDAN ClsgICAgMC4wNjg3NzhdIHhlbl9tYXBfcGlycV9nc2k6IHJldHVybmluZyBpcnEgMSBmb3Ig Z3NpIDENClsgICAgMC4wNjg3ODddIHhlbjogLS0+IHBpcnE9MSAtPiBpcnE9MSAoZ3NpPTEp DQpbICAgIDAuMDY4ODAyXSBwbnAgMDA6MDk6IFtpcnEgMV0NClsgICAgMC4wNjg4MzldIHBu cCAwMDowOTogUGx1ZyBhbmQgUGxheSBBQ1BJIGRldmljZSwgSURzIFBOUDAzMDMgUE5QMDMw YiAoYWN0aXZlKQ0KWyAgICAwLjA2OTA3NF0gcG5wIDAwOjBhOiBbaW8gIDB4MDAwMC0weGZm ZmZmZmZmZmZmZmZmZmYgZGlzYWJsZWRdDQpbICAgIDAuMDY5MDg2XSBwbnAgMDA6MGE6IFtp byAgMHgwMjMwLTB4MDIzZl0NClsgICAgMC4wNjkwOTRdIHBucCAwMDowYTogW2lvICAweDAy OTAtMHgwMjlmXQ0KWyAgICAwLjA2OTEwM10gcG5wIDAwOjBhOiBbaW8gIDB4MGEwMC0weDBh MGZdDQpbICAgIDAuMDY5MTExXSBwbnAgMDA6MGE6IFtpbyAgMHgwYTEwLTB4MGExZl0NClsg ICAgMC4wNjkxNTddIHN5c3RlbSAwMDowYTogW2lvICAweDAyMzAtMHgwMjNmXSBoYXMgYmVl biByZXNlcnZlZA0KWyAgICAwLjA2OTE2OV0gc3lzdGVtIDAwOjBhOiBbaW8gIDB4MDI5MC0w eDAyOWZdIGhhcyBiZWVuIHJlc2VydmVkDQpbICAgIDAuMDY5MTgxXSBzeXN0ZW0gMDA6MGE6 IFtpbyAgMHgwYTAwLTB4MGEwZl0gaGFzIGJlZW4gcmVzZXJ2ZWQNClsgICAgMC4wNjkxOTNd IHN5c3RlbSAwMDowYTogW2lvICAweDBhMTAtMHgwYTFmXSBoYXMgYmVlbiByZXNlcnZlZA0K WyAgICAwLjA2OTIwNl0gc3lzdGVtIDAwOjBhOiBQbHVnIGFuZCBQbGF5IEFDUEkgZGV2aWNl LCBJRHMgUE5QMGMwMiAoYWN0aXZlKQ0KWyAgICAwLjA2OTcyMF0gcG5wIDAwOjBiOiBbaW8g IDB4MDNmOC0weDAzZmZdDQpbICAgIDAuMDY5NzI5XSB4ZW46IHJlZ2lzdGVyaW5nIGdzaSA0 IHRyaWdnZXJpbmcgMSBwb2xhcml0eSAwDQpbICAgIDAuMDY5NzM5XSB4ZW5fbWFwX3BpcnFf Z3NpOiByZXR1cm5pbmcgaXJxIDQgZm9yIGdzaSA0DQpbICAgIDAuMDY5NzQ4XSB4ZW46IC0t PiBwaXJxPTQgLT4gaXJxPTQgKGdzaT00KQ0KWyAgICAwLjA2OTc2M10gcG5wIDAwOjBiOiBb aXJxIDRdDQpbICAgIDAuMDY5NzcxXSBwbnAgMDA6MGI6IFtkbWEgMCBkaXNhYmxlZF0NClsg ICAgMC4wNjk4MzNdIHBucCAwMDowYjogUGx1ZyBhbmQgUGxheSBBQ1BJIGRldmljZSwgSURz IFBOUDA1MDEgKGFjdGl2ZSkNClsgICAgMC4wNjk5MTFdIHBucCAwMDowYzogW21lbSAweGUw MDAwMDAwLTB4ZWZmZmZmZmZdDQpbICAgIDAuMDY5OTU5XSBzeXN0ZW0gMDA6MGM6IFttZW0g MHhlMDAwMDAwMC0weGVmZmZmZmZmXSBoYXMgYmVlbiByZXNlcnZlZA0KWyAgICAwLjA2OTk3 Ml0gc3lzdGVtIDAwOjBjOiBQbHVnIGFuZCBQbGF5IEFDUEkgZGV2aWNlLCBJRHMgUE5QMGMw MiAoYWN0aXZlKQ0KWyAgICAwLjA3MDIwN10gcG5wIDAwOjBkOiBbbWVtIDB4MDAwMDAwMDAt MHgwMDA5ZmZmZl0NClsgICAgMC4wNzAyMThdIHBucCAwMDowZDogW21lbSAweDAwMGMwMDAw LTB4MDAwY2ZmZmZdDQpbICAgIDAuMDcwMjI4XSBwbnAgMDA6MGQ6IFttZW0gMHgwMDBlMDAw MC0weDAwMGZmZmZmXQ0KWyAgICAwLjA3MDIzOF0gcG5wIDAwOjBkOiBbbWVtIDB4MDAxMDAw MDAtMHhhZmZmZmZmZl0NClsgICAgMC4wNzAyNDddIHBucCAwMDowZDogW21lbSAweGZlZDQ1 MDAwLTB4ZmZmZmZmZmZdDQpbICAgIDAuMDcwMzA4XSBzeXN0ZW0gMDA6MGQ6IFttZW0gMHgw MDAwMDAwMC0weDAwMDlmZmZmXSBjb3VsZCBub3QgYmUgcmVzZXJ2ZWQNClsgICAgMC4wNzAz MjBdIHN5c3RlbSAwMDowZDogW21lbSAweDAwMGMwMDAwLTB4MDAwY2ZmZmZdIGNvdWxkIG5v dCBiZSByZXNlcnZlZA0KWyAgICAwLjA3MDMzMl0gc3lzdGVtIDAwOjBkOiBbbWVtIDB4MDAw ZTAwMDAtMHgwMDBmZmZmZl0gY291bGQgbm90IGJlIHJlc2VydmVkDQpbICAgIDAuMDcwMzQ0 XSBzeXN0ZW0gMDA6MGQ6IFttZW0gMHgwMDEwMDAwMC0weGFmZmZmZmZmXSBjb3VsZCBub3Qg YmUgcmVzZXJ2ZWQNClsgICAgMC4wNzAzNTZdIHN5c3RlbSAwMDowZDogW21lbSAweGZlZDQ1 MDAwLTB4ZmZmZmZmZmZdIGNvdWxkIG5vdCBiZSByZXNlcnZlZA0KWyAgICAwLjA3MDM2OV0g c3lzdGVtIDAwOjBkOiBQbHVnIGFuZCBQbGF5IEFDUEkgZGV2aWNlLCBJRHMgUE5QMGMwMSAo YWN0aXZlKQ0KWyAgICAwLjA3MDcyMl0gcG5wOiBQblAgQUNQSTogZm91bmQgMTQgZGV2aWNl cw0KWyAgICAwLjA3MDczMV0gQUNQSTogQUNQSSBidXMgdHlwZSBwbnAgdW5yZWdpc3RlcmVk DQpbICAgIDAuMDcwNzQyXSBpbml0Y2FsbCBwbnBhY3BpX2luaXQrMHgwLzB4ODggcmV0dXJu ZWQgMCBhZnRlciA1Mzc4IHVzZWNzDQpbICAgIDAuMDcwNzU0XSBjYWxsaW5nICBwbnBiaW9z X2luaXQrMHgwLzB4MzlmIEAgMQ0KWyAgICAwLjA3MDc2NF0gUG5QQklPUzogRGlzYWJsZWQN ClsgICAgMC4wNzA3NzNdIGluaXRjYWxsIHBucGJpb3NfaW5pdCsweDAvMHgzOWYgcmV0dXJu ZWQgLTE5IGFmdGVyIDggdXNlY3MNClsgICAgMC4wNzA3ODZdIGNhbGxpbmcgIGNocl9kZXZf aW5pdCsweDAvMHhjOSBAIDENClsgICAgMC4wNzE3MjJdIGluaXRjYWxsIGNocl9kZXZfaW5p dCsweDAvMHhjOSByZXR1cm5lZCAwIGFmdGVyIDkwMyB1c2Vjcw0KWyAgICAwLjA3MTczNV0g Y2FsbGluZyAgZmlybXdhcmVfY2xhc3NfaW5pdCsweDAvMHgxNCBAIDENClsgICAgMC4wNzE3 NTJdIGluaXRjYWxsIGZpcm13YXJlX2NsYXNzX2luaXQrMHgwLzB4MTQgcmV0dXJuZWQgMCBh ZnRlciA1IHVzZWNzDQpbICAgIDAuMDcxNzY0XSBjYWxsaW5nICB0aGVybWFsX2luaXQrMHgw LzB4NWYgQCAxDQpbICAgIDAuMDcxNzgxXSBpbml0Y2FsbCB0aGVybWFsX2luaXQrMHgwLzB4 NWYgcmV0dXJuZWQgMCBhZnRlciA2IHVzZWNzDQpbICAgIDAuMDcxNzkzXSBjYWxsaW5nICBj cHVmcmVxX2dvdl9wZXJmb3JtYW5jZV9pbml0KzB4MC8weGYgQCAxDQpbICAgIDAuMDcxODA3 XSBpbml0Y2FsbCBjcHVmcmVxX2dvdl9wZXJmb3JtYW5jZV9pbml0KzB4MC8weGYgcmV0dXJu ZWQgMCBhZnRlciAwIHVzZWNzDQpbICAgIDAuMDcxODIxXSBjYWxsaW5nICBpbml0X2FjcGlf cG1fY2xvY2tzb3VyY2UrMHgwLzB4MThkIEAgMQ0KWyAgICAwLjA3NDE4Nl0gUE0tVGltZXIg ZmFpbGVkIGNvbnNpc3RlbmN5IGNoZWNrICAoMHgweGZmZmZmZikgLSBhYm9ydGluZy4NClsg ICAgMC4wNzQxOTldIGluaXRjYWxsIGluaXRfYWNwaV9wbV9jbG9ja3NvdXJjZSsweDAvMHgx OGQgcmV0dXJuZWQgLTE5IGFmdGVyIDIzMTEgdXNlY3MNClsgICAgMC4wNzQyMTJdIGNhbGxp bmcgIHBjaWJpb3NfYXNzaWduX3Jlc291cmNlcysweDAvMHg4NiBAIDENClsgICAgMC4wNzQy MzJdIFBDSTogbWF4IGJ1cyBkZXB0aDogMSBwY2lfdHJ5X251bTogMg0KWyAgICAwLjA3NDI3 MV0gcGNpIDAwMDA6MDA6MDQuMDogUENJIGJyaWRnZSB0byBbYnVzIDAxLTAxXQ0KWyAgICAw LjA3NDI4MV0gcGNpIDAwMDA6MDA6MDQuMDogICBicmlkZ2Ugd2luZG93IFtpbyAgZGlzYWJs ZWRdDQpbICAgIDAuMDc0Mjk2XSBwY2kgMDAwMDowMDowNC4wOiAgIGJyaWRnZSB3aW5kb3cg W21lbSBkaXNhYmxlZF0NClsgICAgMC4wNzQzMDldIHBjaSAwMDAwOjAwOjA0LjA6ICAgYnJp ZGdlIHdpbmRvdyBbbWVtIHByZWYgZGlzYWJsZWRdDQpbICAgIDAuMDc0MzI2XSBwY2kgMDAw MDowMDowOS4wOiBQQ0kgYnJpZGdlIHRvIFtidXMgMDItMDJdDQpbICAgIDAuMDc0MzM1XSBw Y2kgMDAwMDowMDowOS4wOiAgIGJyaWRnZSB3aW5kb3cgW2lvICBkaXNhYmxlZF0NClsgICAg MC4wNzQzNDldIHBjaSAwMDAwOjAwOjA5LjA6ICAgYnJpZGdlIHdpbmRvdyBbbWVtIGRpc2Fi bGVkXQ0KWyAgICAwLjA3NDM2M10gcGNpIDAwMDA6MDA6MDkuMDogICBicmlkZ2Ugd2luZG93 IFttZW0gcHJlZiBkaXNhYmxlZF0NClsgICAgMC4wNzQzNzhdIHBjaSAwMDAwOjAwOjBiLjA6 IFBDSSBicmlkZ2UgdG8gW2J1cyAwMy0wM10NClsgICAgMC4wNzQzODhdIHBjaSAwMDAwOjAw OjBiLjA6ICAgYnJpZGdlIHdpbmRvdyBbaW8gIGRpc2FibGVkXQ0KWyAgICAwLjA3NDQwMl0g cGNpIDAwMDA6MDA6MGIuMDogICBicmlkZ2Ugd2luZG93IFttZW0gZGlzYWJsZWRdDQpbICAg IDAuMDc0NDE1XSBwY2kgMDAwMDowMDowYi4wOiAgIGJyaWRnZSB3aW5kb3cgW21lbSBwcmVm IGRpc2FibGVkXQ0KWyAgICAwLjA3NDQzMV0gcGNpIDAwMDA6MDA6MGMuMDogUENJIGJyaWRn ZSB0byBbYnVzIDA0LTA0XQ0KWyAgICAwLjA3NDQ0MF0gcGNpIDAwMDA6MDA6MGMuMDogICBi cmlkZ2Ugd2luZG93IFtpbyAgZGlzYWJsZWRdDQpbICAgIDAuMDc0NDU0XSBwY2kgMDAwMDow MDowYy4wOiAgIGJyaWRnZSB3aW5kb3cgW21lbSBkaXNhYmxlZF0NClsgICAgMC4wNzQ0Njdd IHBjaSAwMDAwOjAwOjBjLjA6ICAgYnJpZGdlIHdpbmRvdyBbbWVtIHByZWYgZGlzYWJsZWRd DQpbICAgIDAuMDc0NDkxXSBwY2kgMDAwMDowMDowNC4wOiBzZXR0aW5nIGxhdGVuY3kgdGlt ZXIgdG8gNjQNClsgICAgMC4wNzQ1MDhdIHBjaSAwMDAwOjAwOjA5LjA6IHNldHRpbmcgbGF0 ZW5jeSB0aW1lciB0byA2NA0KWyAgICAwLjA3NDUyNV0gcGNpIDAwMDA6MDA6MGIuMDogc2V0 dGluZyBsYXRlbmN5IHRpbWVyIHRvIDY0DQpbICAgIDAuMDc0NTQxXSBwY2kgMDAwMDowMDow Yy4wOiBzZXR0aW5nIGxhdGVuY3kgdGltZXIgdG8gNjQNClsgICAgMC4wNzQ1NTJdIHBjaV9i dXMgMDAwMDowMDogcmVzb3VyY2UgNCBbaW8gIDB4MDAwMC0weDBjZjddDQpbICAgIDAuMDc0 NTYyXSBwY2lfYnVzIDAwMDA6MDA6IHJlc291cmNlIDUgW2lvICAweDBkMDAtMHhmZmZmXQ0K WyAgICAwLjA3NDU3Ml0gcGNpX2J1cyAwMDAwOjAwOiByZXNvdXJjZSA2IFttZW0gMHgwMDBh MDAwMC0weDAwMGJmZmZmXQ0KWyAgICAwLjA3NDU4NF0gcGNpX2J1cyAwMDAwOjAwOiByZXNv dXJjZSA3IFttZW0gMHgwMDBkMDAwMC0weDAwMGRmZmZmXQ0KWyAgICAwLjA3NDU5NV0gcGNp X2J1cyAwMDAwOjAwOiByZXNvdXJjZSA4IFttZW0gMHhiMDAwMDAwMC0weGRmZmZmZmZmXQ0K WyAgICAwLjA3NDYwN10gcGNpX2J1cyAwMDAwOjAwOiByZXNvdXJjZSA5IFttZW0gMHhmMDAw MDAwMC0weGZlZDQ0ZmZmXQ0KWyAgICAwLjA3NDYxOV0gcGNpX2J1cyAwMDAwOjAxOiByZXNv dXJjZSA0IFtpbyAgMHgwMDAwLTB4MGNmN10NClsgICAgMC4wNzQ2MjhdIHBjaV9idXMgMDAw MDowMTogcmVzb3VyY2UgNSBbaW8gIDB4MGQwMC0weGZmZmZdDQpbICAgIDAuMDc0NjM4XSBw Y2lfYnVzIDAwMDA6MDE6IHJlc291cmNlIDYgW21lbSAweDAwMGEwMDAwLTB4MDAwYmZmZmZd DQpbICAgIDAuMDc0NjUwXSBwY2lfYnVzIDAwMDA6MDE6IHJlc291cmNlIDcgW21lbSAweDAw MGQwMDAwLTB4MDAwZGZmZmZdDQpbICAgIDAuMDc0NjYxXSBwY2lfYnVzIDAwMDA6MDE6IHJl c291cmNlIDggW21lbSAweGIwMDAwMDAwLTB4ZGZmZmZmZmZdDQpbICAgIDAuMDc0NjczXSBw Y2lfYnVzIDAwMDA6MDE6IHJlc291cmNlIDkgW21lbSAweGYwMDAwMDAwLTB4ZmVkNDRmZmZd DQpbICAgIDAuMDc0Njg2XSBpbml0Y2FsbCBwY2liaW9zX2Fzc2lnbl9yZXNvdXJjZXMrMHgw LzB4ODYgcmV0dXJuZWQgMCBhZnRlciA0NTEgdXNlY3MNClsgICAgMC4wNzQ2OTldIGNhbGxp bmcgIHN5c2N0bF9jb3JlX2luaXQrMHgwLzB4MmQgQCAxDQpbICAgIDAuMDc0NzIzXSBpbml0 Y2FsbCBzeXNjdGxfY29yZV9pbml0KzB4MC8weDJkIHJldHVybmVkIDAgYWZ0ZXIgMTQgdXNl Y3MNClsgICAgMC4wNzQ3MzZdIGNhbGxpbmcgIGluZXRfaW5pdCsweDAvMHgyNDMgQCAxDQpb ICAgIDAuMDc0NzYwXSBORVQ6IFJlZ2lzdGVyZWQgcHJvdG9jb2wgZmFtaWx5IDINClsgICAg MC4wNzQ4MjNdIElQIHJvdXRlIGNhY2hlIGhhc2ggdGFibGUgZW50cmllczogMzI3NjggKG9y ZGVyOiA1LCAxMzEwNzIgYnl0ZXMpDQpbICAgIDAuMDc1MDM4XSBUQ1AgZXN0YWJsaXNoZWQg aGFzaCB0YWJsZSBlbnRyaWVzOiAxMzEwNzIgKG9yZGVyOiA4LCAxMDQ4NTc2IGJ5dGVzKQ0K WyAgICAwLjA3NTQ2OV0gVENQIGJpbmQgaGFzaCB0YWJsZSBlbnRyaWVzOiA2NTUzNiAob3Jk ZXI6IDcsIDUyNDI4OCBieXRlcykNClsgICAgMC4wNzU2OTRdIFRDUDogSGFzaCB0YWJsZXMg Y29uZmlndXJlZCAoZXN0YWJsaXNoZWQgMTMxMDcyIGJpbmQgNjU1MzYpDQpbICAgIDAuMDc1 NzA2XSBUQ1AgcmVubyByZWdpc3RlcmVkDQpbICAgIDAuMDc1NzE2XSBVRFAgaGFzaCB0YWJs ZSBlbnRyaWVzOiA1MTIgKG9yZGVyOiAyLCAxNjM4NCBieXRlcykNClsgICAgMC4wNzU3Mzdd IFVEUC1MaXRlIGhhc2ggdGFibGUgZW50cmllczogNTEyIChvcmRlcjogMiwgMTYzODQgYnl0 ZXMpDQpbICAgIDAuMDc1ODQ0XSBpbml0Y2FsbCBpbmV0X2luaXQrMHgwLzB4MjQzIHJldHVy bmVkIDAgYWZ0ZXIgMTA2OCB1c2Vjcw0KWyAgICAwLjA3NTg1OF0gY2FsbGluZyAgYWZfdW5p eF9pbml0KzB4MC8weDRkIEAgMQ0KWyAgICAwLjA3NTg2OV0gTkVUOiBSZWdpc3RlcmVkIHBy b3RvY29sIGZhbWlseSAxDQpbICAgIDAuMDc1ODg1XSBpbml0Y2FsbCBhZl91bml4X2luaXQr MHgwLzB4NGQgcmV0dXJuZWQgMCBhZnRlciAxNiB1c2Vjcw0KWyAgICAwLjA3NTg5OF0gY2Fs bGluZyAgcGNpX2FwcGx5X2ZpbmFsX3F1aXJrcysweDAvMHgxMDYgQCAxDQpbICAgIDAuNjU2 MjQ0XSBwY2kgMDAwMDowMDowMC4wOiBGb3VuZCBlbmFibGVkIEhUIE1TSSBNYXBwaW5nDQpb ICAgIDAuNjU2MzQ2XSBwY2kgMDAwMDowMDowMC4wOiBGb3VuZCBlbmFibGVkIEhUIE1TSSBN YXBwaW5nDQpbICAgIDAuNjU2NDYyXSBwY2kgMDAwMDowMDowMC4wOiBGb3VuZCBlbmFibGVk IEhUIE1TSSBNYXBwaW5nDQpbICAgIDAuNjU2NTc4XSBwY2kgMDAwMDowMDowMC4wOiBGb3Vu ZCBlbmFibGVkIEhUIE1TSSBNYXBwaW5nDQpbICAgIDAuNjU2Njk0XSBwY2kgMDAwMDowMDow MC4wOiBGb3VuZCBlbmFibGVkIEhUIE1TSSBNYXBwaW5nDQpbICAgIDAuNjU2ODI2XSBwY2kg MDAwMDowMDowMC4wOiBGb3VuZCBlbmFibGVkIEhUIE1TSSBNYXBwaW5nDQpbICAgIDAuNjU2 OTczXSBwY2kgMDAwMDowMDowMC4wOiBGb3VuZCBlbmFibGVkIEhUIE1TSSBNYXBwaW5nDQpb ICAgIDAuNjU3MTMzXSBwY2kgMDAwMDowMDowMC4wOiBGb3VuZCBlbmFibGVkIEhUIE1TSSBN YXBwaW5nDQpbICAgIDAuNjU3MTUzXSBwY2kgMDAwMDowMDowZC4wOiBCb290IHZpZGVvIGRl dmljZQ0KWyAgICAwLjY1NzE3NF0gUENJOiBDTFMgNjQgYnl0ZXMsIGRlZmF1bHQgNjQNClsg ICAgMC42NTcxODZdIGluaXRjYWxsIHBjaV9hcHBseV9maW5hbF9xdWlya3MrMHgwLzB4MTA2 IHJldHVybmVkIDAgYWZ0ZXIgNTY3NjUwIHVzZWNzDQpbICAgIDAuNjU3MjAzXSBjYWxsaW5n ICBwb3B1bGF0ZV9yb290ZnMrMHgwLzB4MjRiIEAgMQ0KWyAgICAwLjY1NzI1Nl0gVHJ5aW5n IHRvIHVucGFjayByb290ZnMgaW1hZ2UgYXMgaW5pdHJhbWZzLi4uDQpbICAgIDIuMTA4NDc5 XSBGcmVlaW5nIGluaXRyZCBtZW1vcnk6IDkyODRrIGZyZWVkDQpbICAgIDIuMTExNzY3XSBp bml0Y2FsbCBwb3B1bGF0ZV9yb290ZnMrMHgwLzB4MjRiIHJldHVybmVkIDAgYWZ0ZXIgMTQy MDQ1NSB1c2Vjcw0KWyAgICAyLjExMTc4OV0gY2FsbGluZyAgcGNpX2lvbW11X2luaXQrMHgw LzB4MzQgQCAxDQpbICAgIDIuMTExODAxXSBpbml0Y2FsbCBwY2lfaW9tbXVfaW5pdCsweDAv MHgzNCByZXR1cm5lZCAwIGFmdGVyIDAgdXNlY3MNClsgICAgMi4xMTE4MTJdIGNhbGxpbmcg IGk4MjU5QV9pbml0X29wcysweDAvMHgxZCBAIDENClsgICAgMi4xMTE4MjRdIGluaXRjYWxs IGk4MjU5QV9pbml0X29wcysweDAvMHgxZCByZXR1cm5lZCAwIGFmdGVyIDEgdXNlY3MNClsg ICAgMi4xMTE4MzVdIGNhbGxpbmcgIHNiZl9pbml0KzB4MC8weGU0IEAgMQ0KWyAgICAyLjEx MTg0NF0gaW5pdGNhbGwgc2JmX2luaXQrMHgwLzB4ZTQgcmV0dXJuZWQgMCBhZnRlciAwIHVz ZWNzDQpbICAgIDIuMTExODU2XSBjYWxsaW5nICBpbml0X3RzY19jbG9ja3NvdXJjZSsweDAv MHg1OCBAIDENClsgICAgMi4xMTE4NzhdIGluaXRjYWxsIGluaXRfdHNjX2Nsb2Nrc291cmNl KzB4MC8weDU4IHJldHVybmVkIDAgYWZ0ZXIgMTEgdXNlY3MNClsgICAgMi4xMTE4OTJdIGNh bGxpbmcgIGFkZF9ydGNfY21vcysweDAvMHg3ZCBAIDENClsgICAgMi4xMTE5MDRdIGluaXRj YWxsIGFkZF9ydGNfY21vcysweDAvMHg3ZCByZXR1cm5lZCAwIGFmdGVyIDIgdXNlY3MNClsg ICAgMi4xMTE5MTZdIGNhbGxpbmcgIGk4MjM3QV9pbml0X29wcysweDAvMHgxMSBAIDENClsg ICAgMi4xMTE5OTNdIGluaXRjYWxsIGk4MjM3QV9pbml0X29wcysweDAvMHgxMSByZXR1cm5l ZCAwIGFmdGVyIDY0IHVzZWNzDQpbICAgIDIuMTEyMDA3XSBjYWxsaW5nICBjYWNoZV9zeXNm c19pbml0KzB4MC8weDRmIEAgMQ0KWyAgICAyLjExMjE4MF0gaW5pdGNhbGwgY2FjaGVfc3lz ZnNfaW5pdCsweDAvMHg0ZiByZXR1cm5lZCAwIGFmdGVyIDE1NyB1c2Vjcw0KWyAgICAyLjEx MjE5M10gY2FsbGluZyAgbWNoZWNrX2luaXRfZGV2aWNlKzB4MC8weGZlIEAgMQ0KWyAgICAy LjExMjIwNF0gaW5pdGNhbGwgbWNoZWNrX2luaXRfZGV2aWNlKzB4MC8weGZlIHJldHVybmVk IC01IGFmdGVyIDAgdXNlY3MNClsgICAgMi4xMTIyMTZdIGluaXRjYWxsIG1jaGVja19pbml0 X2RldmljZSsweDAvMHhmZSByZXR1cm5lZCB3aXRoIGVycm9yIGNvZGUgLTUgDQpbICAgIDIu MTEyMjMwXSBjYWxsaW5nICB0aHJlc2hvbGRfaW5pdF9kZXZpY2UrMHgwLzB4NzEgQCAxDQpb ICAgIDIuMTEyMjQxXSBpbml0Y2FsbCB0aHJlc2hvbGRfaW5pdF9kZXZpY2UrMHgwLzB4NzEg cmV0dXJuZWQgMCBhZnRlciAwIHVzZWNzDQpbICAgIDIuMTEyMjU1XSBjYWxsaW5nICB0aGVy bWFsX3Rocm90dGxlX2luaXRfZGV2aWNlKzB4MC8weDc3IEAgMQ0KWyAgICAyLjExMjI2N10g aW5pdGNhbGwgdGhlcm1hbF90aHJvdHRsZV9pbml0X2RldmljZSsweDAvMHg3NyByZXR1cm5l ZCAwIGFmdGVyIDAgdXNlY3MNClsgICAgMi4xMTIyODBdIGNhbGxpbmcgIGlvYXBpY19pbml0 X29wcysweDAvMHgxMSBAIDENClsgICAgMi4xMTIyOTFdIGluaXRjYWxsIGlvYXBpY19pbml0 X29wcysweDAvMHgxMSByZXR1cm5lZCAwIGFmdGVyIDAgdXNlY3MNClsgICAgMi4xMTIzMDJd IGNhbGxpbmcgIGFkZF9wY3Nwa3IrMHgwLzB4NDMgQCAxDQpbICAgIDIuMTEyMzM1XSBpbml0 Y2FsbCBhZGRfcGNzcGtyKzB4MC8weDQzIHJldHVybmVkIDAgYWZ0ZXIgMjIgdXNlY3MNClsg ICAgMi4xMTIzNDldIGNhbGxpbmcgIHN0YXJ0X3BlcmlvZGljX2NoZWNrX2Zvcl9jb3JydXB0 aW9uKzB4MC8weDUwIEAgMQ0KWyAgICAyLjExMjM2Ml0gaW5pdGNhbGwgc3RhcnRfcGVyaW9k aWNfY2hlY2tfZm9yX2NvcnJ1cHRpb24rMHgwLzB4NTAgcmV0dXJuZWQgMCBhZnRlciAwIHVz ZWNzDQpbICAgIDIuMTEyMzc2XSBjYWxsaW5nICBjcmMzMmNfaW50ZWxfbW9kX2luaXQrMHgw LzB4MjIgQCAxDQpbICAgIDIuMTEyMzg3XSBpbml0Y2FsbCBjcmMzMmNfaW50ZWxfbW9kX2lu aXQrMHgwLzB4MjIgcmV0dXJuZWQgLTE5IGFmdGVyIDAgdXNlY3MNClsgICAgMi4xMTI0MDBd IGNhbGxpbmcgIGluaXRfc2NoZWRfZGVidWdfcHJvY2ZzKzB4MC8weDMwIEAgMQ0KWyAgICAy LjExMjQxNl0gaW5pdGNhbGwgaW5pdF9zY2hlZF9kZWJ1Z19wcm9jZnMrMHgwLzB4MzAgcmV0 dXJuZWQgMCBhZnRlciA1IHVzZWNzDQpbICAgIDIuMTEyNDI5XSBjYWxsaW5nICBwcm9jX3Nj aGVkc3RhdF9pbml0KzB4MC8weDI3IEAgMQ0KWyAgICAyLjExMjQ0Ml0gaW5pdGNhbGwgcHJv Y19zY2hlZHN0YXRfaW5pdCsweDAvMHgyNyByZXR1cm5lZCAwIGFmdGVyIDEgdXNlY3MNClsg ICAgMi4xMTI0NTRdIGNhbGxpbmcgIHByb2NfZXhlY2RvbWFpbnNfaW5pdCsweDAvMHgyNyBA IDENClsgICAgMi4xMTI0NjZdIGluaXRjYWxsIHByb2NfZXhlY2RvbWFpbnNfaW5pdCsweDAv MHgyNyByZXR1cm5lZCAwIGFmdGVyIDEgdXNlY3MNClsgICAgMi4xMTI0NzldIGNhbGxpbmcg IGlvcmVzb3VyY2VzX2luaXQrMHgwLzB4NDQgQCAxDQpbICAgIDIuMTEyNDkyXSBpbml0Y2Fs bCBpb3Jlc291cmNlc19pbml0KzB4MC8weDQ0IHJldHVybmVkIDAgYWZ0ZXIgMiB1c2Vjcw0K WyAgICAyLjExMjUwNF0gY2FsbGluZyAgdWlkX2NhY2hlX2luaXQrMHgwLzB4OGEgQCAxDQpb ICAgIDIuMTEyNTIxXSBpbml0Y2FsbCB1aWRfY2FjaGVfaW5pdCsweDAvMHg4YSByZXR1cm5l ZCAwIGFmdGVyIDYgdXNlY3MNClsgICAgMi4xMTI1MzNdIGNhbGxpbmcgIGluaXRfcG9zaXhf dGltZXJzKzB4MC8weDFjYiBAIDENClsgICAgMi4xMTI1NTRdIGluaXRjYWxsIGluaXRfcG9z aXhfdGltZXJzKzB4MC8weDFjYiByZXR1cm5lZCAwIGFmdGVyIDEwIHVzZWNzDQpbICAgIDIu MTEyNTY2XSBjYWxsaW5nICBpbml0X3Bvc2l4X2NwdV90aW1lcnMrMHgwLzB4OWIgQCAxDQpb ICAgIDIuMTEyNTc3XSBpbml0Y2FsbCBpbml0X3Bvc2l4X2NwdV90aW1lcnMrMHgwLzB4OWIg cmV0dXJuZWQgMCBhZnRlciAwIHVzZWNzDQpbICAgIDIuMTEyNTkxXSBjYWxsaW5nICBuc3By b3h5X2NhY2hlX2luaXQrMHgwLzB4MzIgQCAxDQpbICAgIDIuMTEyNjAyXSBpbml0Y2FsbCBu c3Byb3h5X2NhY2hlX2luaXQrMHgwLzB4MzIgcmV0dXJuZWQgMCBhZnRlciAxIHVzZWNzDQpb ICAgIDIuMTEyNjE0XSBjYWxsaW5nICB0aW1la2VlcGluZ19pbml0X29wcysweDAvMHgxMSBA IDENClsgICAgMi4xMTI2MjVdIGluaXRjYWxsIHRpbWVrZWVwaW5nX2luaXRfb3BzKzB4MC8w eDExIHJldHVybmVkIDAgYWZ0ZXIgMCB1c2Vjcw0KWyAgICAyLjExMjYzN10gY2FsbGluZyAg aW5pdF9jbG9ja3NvdXJjZV9zeXNmcysweDAvMHg0MyBAIDENClsgICAgMi4xMTI2NTddIGlu aXRjYWxsIGluaXRfY2xvY2tzb3VyY2Vfc3lzZnMrMHgwLzB4NDMgcmV0dXJuZWQgMCBhZnRl ciA5IHVzZWNzDQpbICAgIDIuMTEyNjcxXSBjYWxsaW5nICBpbml0X3RpbWVyX2xpc3RfcHJv Y2ZzKzB4MC8weDMwIEAgMQ0KWyAgICAyLjExMjY4NF0gaW5pdGNhbGwgaW5pdF90aW1lcl9s aXN0X3Byb2NmcysweDAvMHgzMCByZXR1cm5lZCAwIGFmdGVyIDEgdXNlY3MNClsgICAgMi4x MTI2OTddIGNhbGxpbmcgIGFsYXJtdGltZXJfaW5pdCsweDAvMHgxMzYgQCAxDQpbICAgIDIu MTEyNzI4XSBpbml0Y2FsbCBhbGFybXRpbWVyX2luaXQrMHgwLzB4MTM2IHJldHVybmVkIDAg YWZ0ZXIgMjAgdXNlY3MNClsgICAgMi4xMTI3NDFdIGNhbGxpbmcgIGluaXRfdHN0YXRzX3By b2NmcysweDAvMHgzMCBAIDENClsgICAgMi4xMTI3NTRdIGluaXRjYWxsIGluaXRfdHN0YXRz X3Byb2NmcysweDAvMHgzMCByZXR1cm5lZCAwIGFmdGVyIDIgdXNlY3MNClsgICAgMi4xMTI3 NjZdIGNhbGxpbmcgIGZ1dGV4X2luaXQrMHgwLzB4NWEgQCAxDQpbICAgIDIuMTEyNzgxXSBp bml0Y2FsbCBmdXRleF9pbml0KzB4MC8weDVhIHJldHVybmVkIDAgYWZ0ZXIgNCB1c2Vjcw0K WyAgICAyLjExMjc5Ml0gY2FsbGluZyAgcHJvY19kbWFfaW5pdCsweDAvMHgyNyBAIDENClsg ICAgMi4xMTI4MDRdIGluaXRjYWxsIHByb2NfZG1hX2luaXQrMHgwLzB4MjcgcmV0dXJuZWQg MCBhZnRlciAxIHVzZWNzDQpbICAgIDIuMTEyODE2XSBjYWxsaW5nICBwcm9jX21vZHVsZXNf aW5pdCsweDAvMHgyNyBAIDENClsgICAgMi4xMTI4MjldIGluaXRjYWxsIHByb2NfbW9kdWxl c19pbml0KzB4MC8weDI3IHJldHVybmVkIDAgYWZ0ZXIgMSB1c2Vjcw0KWyAgICAyLjExMjg0 MV0gY2FsbGluZyAga2FsbHN5bXNfaW5pdCsweDAvMHgyYSBAIDENClsgICAgMi4xMTI4NTNd IGluaXRjYWxsIGthbGxzeW1zX2luaXQrMHgwLzB4MmEgcmV0dXJuZWQgMCBhZnRlciAxIHVz ZWNzDQpbICAgIDIuMTEyODY1XSBjYWxsaW5nICBzbmFwc2hvdF9kZXZpY2VfaW5pdCsweDAv MHhmIEAgMQ0KWyAgICAyLjExMjkyMF0gaW5pdGNhbGwgc25hcHNob3RfZGV2aWNlX2luaXQr MHgwLzB4ZiByZXR1cm5lZCAwIGFmdGVyIDQzIHVzZWNzDQpbICAgIDIuMTEyOTMyXSBjYWxs aW5nICBjcmFzaF9zYXZlX3ZtY29yZWluZm9faW5pdCsweDAvMHg0YjQgQCAxDQpbICAgIDIu MTEyOTU5XSBpbml0Y2FsbCBjcmFzaF9zYXZlX3ZtY29yZWluZm9faW5pdCsweDAvMHg0YjQg cmV0dXJuZWQgMCBhZnRlciAxNCB1c2Vjcw0KWyAgICAyLjExMjk3M10gY2FsbGluZyAgY3Jh c2hfbm90ZXNfbWVtb3J5X2luaXQrMHgwLzB4MzUgQCAxDQpbICAgIDIuMTEyOTg2XSBpbml0 Y2FsbCBjcmFzaF9ub3Rlc19tZW1vcnlfaW5pdCsweDAvMHgzNSByZXR1cm5lZCAwIGFmdGVy IDIgdXNlY3MNClsgICAgMi4xMTMwMDBdIGNhbGxpbmcgIHVzZXJfbmFtZXNwYWNlc19pbml0 KzB4MC8weDMyIEAgMQ0KWyAgICAyLjExMzAxNF0gaW5pdGNhbGwgdXNlcl9uYW1lc3BhY2Vz X2luaXQrMHgwLzB4MzIgcmV0dXJuZWQgMCBhZnRlciAzIHVzZWNzDQpbICAgIDIuMTEzMDI2 XSBjYWxsaW5nICBwaWRfbmFtZXNwYWNlc19pbml0KzB4MC8weDMyIEAgMQ0KWyAgICAyLjEx MzAzN10gaW5pdGNhbGwgcGlkX25hbWVzcGFjZXNfaW5pdCsweDAvMHgzMiByZXR1cm5lZCAw IGFmdGVyIDAgdXNlY3MNClsgICAgMi4xMTMwNDldIGNhbGxpbmcgIGlrY29uZmlnX2luaXQr MHgwLzB4NDMgQCAxDQpbICAgIDIuMTEzMDYyXSBpbml0Y2FsbCBpa2NvbmZpZ19pbml0KzB4 MC8weDQzIHJldHVybmVkIDAgYWZ0ZXIgMSB1c2Vjcw0KWyAgICAyLjExMzA3NF0gY2FsbGlu ZyAgYXVkaXRfaW5pdCsweDAvMHgxMmMgQCAxDQpbICAgIDIuMTEzMDg0XSBhdWRpdDogaW5p dGlhbGl6aW5nIG5ldGxpbmsgc29ja2V0IChkaXNhYmxlZCkNClsgICAgMi4xMTMxMDNdIHR5 cGU9MjAwMCBhdWRpdCgxMzE2Nzg4NDY3LjQzOToxKTogaW5pdGlhbGl6ZWQNClsgICAgMi4x MTMxMTVdIGluaXRjYWxsIGF1ZGl0X2luaXQrMHgwLzB4MTJjIHJldHVybmVkIDAgYWZ0ZXIg MjkgdXNlY3MNClsgICAgMi4xMTMxMjddIGNhbGxpbmcgIGF1ZGl0X3dhdGNoX2luaXQrMHgw LzB4MzEgQCAxDQpbICAgIDIuMTEzMTM4XSBpbml0Y2FsbCBhdWRpdF93YXRjaF9pbml0KzB4 MC8weDMxIHJldHVybmVkIDAgYWZ0ZXIgMCB1c2Vjcw0KWyAgICAyLjExMzE1MF0gY2FsbGlu ZyAgYXVkaXRfdHJlZV9pbml0KzB4MC8weDNiIEAgMQ0KWyAgICAyLjExMzE2MV0gaW5pdGNh bGwgYXVkaXRfdHJlZV9pbml0KzB4MC8weDNiIHJldHVybmVkIDAgYWZ0ZXIgMCB1c2Vjcw0K WyAgICAyLjExMzE3M10gY2FsbGluZyAgaHVuZ190YXNrX2luaXQrMHgwLzB4NTYgQCAxDQpb ICAgIDIuMTEzMjYwXSBpbml0Y2FsbCBodW5nX3Rhc2tfaW5pdCsweDAvMHg1NiByZXR1cm5l ZCAwIGFmdGVyIDczIHVzZWNzDQpbICAgIDIuMTEzMjczXSBjYWxsaW5nICB1dHNuYW1lX3N5 c2N0bF9pbml0KzB4MC8weDExIEAgMQ0KWyAgICAyLjExMzMwMF0gaW5pdGNhbGwgdXRzbmFt ZV9zeXNjdGxfaW5pdCsweDAvMHgxMSByZXR1cm5lZCAwIGFmdGVyIDE1IHVzZWNzDQpbICAg IDIuMTEzMzEzXSBjYWxsaW5nICBpbml0X3RyYWNlcG9pbnRzKzB4MC8weDIwIEAgMQ0KWyAg ICAyLjExMzMyNF0gaW5pdGNhbGwgaW5pdF90cmFjZXBvaW50cysweDAvMHgyMCByZXR1cm5l ZCAwIGFmdGVyIDAgdXNlY3MNClsgICAgMi4xMTMzMzZdIGNhbGxpbmcgIGluaXRfbHN0YXRz X3Byb2NmcysweDAvMHgyYSBAIDENClsgICAgMi4xMTMzNDhdIGluaXRjYWxsIGluaXRfbHN0 YXRzX3Byb2NmcysweDAvMHgyYSByZXR1cm5lZCAwIGFmdGVyIDEgdXNlY3MNClsgICAgMi4x MTMzNjBdIGNhbGxpbmcgIGZ0cmFjZV9tb2RfY21kX2luaXQrMHgwLzB4ZiBAIDENClsgICAg Mi4xMTMzNzBdIGluaXRjYWxsIGZ0cmFjZV9tb2RfY21kX2luaXQrMHgwLzB4ZiByZXR1cm5l ZCAwIGFmdGVyIDAgdXNlY3MNClsgICAgMi4xMTMzODJdIGNhbGxpbmcgIGluaXRfZXZlbnRz KzB4MC8weDVmIEAgMQ0KWyAgICAyLjExMzM5N10gaW5pdGNhbGwgaW5pdF9ldmVudHMrMHgw LzB4NWYgcmV0dXJuZWQgMCBhZnRlciA0IHVzZWNzDQpbICAgIDIuMTEzNDA4XSBjYWxsaW5n ICBpbml0X2Z1bmN0aW9uX3RyYWNlKzB4MC8weDM1IEAgMQ0KWyAgICAyLjExMzQyMF0gaW5p dGNhbGwgaW5pdF9mdW5jdGlvbl90cmFjZSsweDAvMHgzNSByZXR1cm5lZCAwIGFmdGVyIDEg dXNlY3MNClsgICAgMi4xMTM0MzJdIGNhbGxpbmcgIGluaXRfd2FrZXVwX3RyYWNlcisweDAv MHgxZCBAIDENClsgICAgMi4xMTM0NDNdIGluaXRjYWxsIGluaXRfd2FrZXVwX3RyYWNlcisw eDAvMHgxZCByZXR1cm5lZCAwIGFmdGVyIDAgdXNlY3MNClsgICAgMi4xMTM0NTRdIGNhbGxp bmcgIHN0YWNrX3RyYWNlX2luaXQrMHgwLzB4NjggQCAxDQpbICAgIDIuMTEzNDcwXSBpbml0 Y2FsbCBzdGFja190cmFjZV9pbml0KzB4MC8weDY4IHJldHVybmVkIDAgYWZ0ZXIgNSB1c2Vj cw0KWyAgICAyLjExMzQ4Ml0gY2FsbGluZyAgaW5pdF9tbWlvX3RyYWNlKzB4MC8weGYgQCAx DQpbICAgIDIuMTEzNDkzXSBpbml0Y2FsbCBpbml0X21taW9fdHJhY2UrMHgwLzB4ZiByZXR1 cm5lZCAwIGFmdGVyIDAgdXNlY3MNClsgICAgMi4xMTM1MDVdIGNhbGxpbmcgIGluaXRfZ3Jh cGhfdHJhY2UrMHgwLzB4NmUgQCAxDQpbICAgIDIuMTEzNTE3XSBpbml0Y2FsbCBpbml0X2dy YXBoX3RyYWNlKzB4MC8weDZlIHJldHVybmVkIDAgYWZ0ZXIgMiB1c2Vjcw0KWyAgICAyLjEx MzUyOF0gY2FsbGluZyAgaW5pdF9ibGtfdHJhY2VyKzB4MC8weDU2IEAgMQ0KWyAgICAyLjEx MzU0MF0gaW5pdGNhbGwgaW5pdF9ibGtfdHJhY2VyKzB4MC8weDU2IHJldHVybmVkIDAgYWZ0 ZXIgMSB1c2Vjcw0KWyAgICAyLjExMzU1Ml0gY2FsbGluZyAgcGVyZl9ldmVudF9zeXNmc19p bml0KzB4MC8weDhmIEAgMQ0KWyAgICAyLjExMzU5OV0gaW5pdGNhbGwgcGVyZl9ldmVudF9z eXNmc19pbml0KzB4MC8weDhmIHJldHVybmVkIDAgYWZ0ZXIgMzUgdXNlY3MNClsgICAgMi4x MTM2MTRdIGNhbGxpbmcgIGluaXRfcGVyX3pvbmVfd21hcmtfbWluKzB4MC8weDc3IEAgMQ0K WyAgICAyLjExNjA1NV0gaW5pdGNhbGwgaW5pdF9wZXJfem9uZV93bWFya19taW4rMHgwLzB4 NzcgcmV0dXJuZWQgMCBhZnRlciA0MzQzIHVzZWNzDQpbICAgIDIuMTE2MDU1XSBjYWxsaW5n ICBrc3dhcGRfaW5pdCsweDAvMHgxZCBAIDENClsgICAgMi4xMTgyNzBdIGluaXRjYWxsIGtz d2FwZF9pbml0KzB4MC8weDFkIHJldHVybmVkIDAgYWZ0ZXIgMTU5IHVzZWNzDQpbICAgIDIu MTE4Mjg0XSBjYWxsaW5nICBleHRmcmFnX2RlYnVnX2luaXQrMHgwLzB4NzIgQCAxDQpbICAg IDIuMTE4MzA0XSBpbml0Y2FsbCBleHRmcmFnX2RlYnVnX2luaXQrMHgwLzB4NzIgcmV0dXJu ZWQgMCBhZnRlciA4IHVzZWNzDQpbICAgIDIuMTE4MzE2XSBjYWxsaW5nICBzZXR1cF92bXN0 YXQrMHgwLzB4Y2EgQCAxDQpbICAgIDIuMTE4MzQxXSBpbml0Y2FsbCBzZXR1cF92bXN0YXQr MHgwLzB4Y2EgcmV0dXJuZWQgMCBhZnRlciAxNCB1c2Vjcw0KWyAgICAyLjExODM1M10gY2Fs bGluZyAgbW1fc3lzZnNfaW5pdCsweDAvMHgyMiBAIDENClsgICAgMi4xMTgzNjldIGluaXRj YWxsIG1tX3N5c2ZzX2luaXQrMHgwLzB4MjIgcmV0dXJuZWQgMCBhZnRlciA0IHVzZWNzDQpb ICAgIDIuMTE4MzgxXSBjYWxsaW5nICBwcm9jX3ZtYWxsb2NfaW5pdCsweDAvMHgyYSBAIDEN ClsgICAgMi4xMTgzOTNdIGluaXRjYWxsIHByb2Nfdm1hbGxvY19pbml0KzB4MC8weDJhIHJl dHVybmVkIDAgYWZ0ZXIgMSB1c2Vjcw0KWyAgICAyLjExODQwNV0gY2FsbGluZyAgaW5pdF9l bWVyZ2VuY3lfcG9vbCsweDAvMHg3ZSBAIDENClsgICAgMi4xMTg0MzZdIGhpZ2htZW0gYm91 bmNlIHBvb2wgc2l6ZTogNjQgcGFnZXMNClsgICAgMi4xMTg0NDddIGluaXRjYWxsIGluaXRf ZW1lcmdlbmN5X3Bvb2wrMHgwLzB4N2UgcmV0dXJuZWQgMCBhZnRlciAzMCB1c2Vjcw0KWyAg ICAyLjExODQ1OV0gY2FsbGluZyAgcHJvY3N3YXBzX2luaXQrMHgwLzB4MjcgQCAxDQpbICAg IDIuMTE4NDcxXSBpbml0Y2FsbCBwcm9jc3dhcHNfaW5pdCsweDAvMHgyNyByZXR1cm5lZCAw IGFmdGVyIDEgdXNlY3MNClsgICAgMi4xMTg0ODNdIGNhbGxpbmcgIGh1Z2V0bGJfaW5pdCsw eDAvMHgzMjEgQCAxDQpbICAgIDIuMTE4NDk0XSBIdWdlVExCIHJlZ2lzdGVyZWQgMiBNQiBw YWdlIHNpemUsIHByZS1hbGxvY2F0ZWQgMCBwYWdlcw0KWyAgICAyLjExODUxMV0gaW5pdGNh bGwgaHVnZXRsYl9pbml0KzB4MC8weDMyMSByZXR1cm5lZCAwIGFmdGVyIDE3IHVzZWNzDQpb ICAgIDIuMTE4NTIzXSBjYWxsaW5nICBrc21faW5pdCsweDAvMHgxNWMgQCAxDQpbICAgIDIu MTE4NjE1XSBpbml0Y2FsbCBrc21faW5pdCsweDAvMHgxNWMgcmV0dXJuZWQgMCBhZnRlciA4 MCB1c2Vjcw0KWyAgICAyLjExODYyOV0gY2FsbGluZyAgc2xhYl9wcm9jX2luaXQrMHgwLzB4 MmEgQCAxDQpbICAgIDIuMTE4NjQxXSBpbml0Y2FsbCBzbGFiX3Byb2NfaW5pdCsweDAvMHgy YSByZXR1cm5lZCAwIGFmdGVyIDIgdXNlY3MNClsgICAgMi4xMTg2NTNdIGNhbGxpbmcgIHNs YWJfc3lzZnNfaW5pdCsweDAvMHhkZiBAIDENClsgICAgMi4xMTk3MjVdIGluaXRjYWxsIHNs YWJfc3lzZnNfaW5pdCsweDAvMHhkZiByZXR1cm5lZCAwIGFmdGVyIDEwMzYgdXNlY3MNClsg ICAgMi4xMTk3MzddIGNhbGxpbmcgIGZjbnRsX2luaXQrMHgwLzB4MmYgQCAxDQpbICAgIDIu MTE5NzUyXSBpbml0Y2FsbCBmY250bF9pbml0KzB4MC8weDJmIHJldHVybmVkIDAgYWZ0ZXIg NCB1c2Vjcw0KWyAgICAyLjExOTc2NF0gY2FsbGluZyAgcHJvY19maWxlc3lzdGVtc19pbml0 KzB4MC8weDI3IEAgMQ0KWyAgICAyLjExOTc3N10gaW5pdGNhbGwgcHJvY19maWxlc3lzdGVt c19pbml0KzB4MC8weDI3IHJldHVybmVkIDAgYWZ0ZXIgMiB1c2Vjcw0KWyAgICAyLjExOTc5 MV0gY2FsbGluZyAgZnNub3RpZnlfbWFya19pbml0KzB4MC8weDQ2IEAgMQ0KWyAgICAyLjEx OTg2OF0gaW5pdGNhbGwgZnNub3RpZnlfbWFya19pbml0KzB4MC8weDQ2IHJldHVybmVkIDAg YWZ0ZXIgNjQgdXNlY3MNClsgICAgMi4xMTk4ODBdIGNhbGxpbmcgIGRub3RpZnlfaW5pdCsw eDAvMHg3YyBAIDENClsgICAgMi4xMTk4OThdIGluaXRjYWxsIGRub3RpZnlfaW5pdCsweDAv MHg3YyByZXR1cm5lZCAwIGFmdGVyIDcgdXNlY3MNClsgICAgMi4xMTk5MTBdIGNhbGxpbmcg IGlub3RpZnlfdXNlcl9zZXR1cCsweDAvMHg3OCBAIDENClsgICAgMi4xMTk5MjhdIGluaXRj YWxsIGlub3RpZnlfdXNlcl9zZXR1cCsweDAvMHg3OCByZXR1cm5lZCAwIGFmdGVyIDYgdXNl Y3MNClsgICAgMi4xMTk5NDBdIGNhbGxpbmcgIGFpb19zZXR1cCsweDAvMHg4NyBAIDENClsg ICAgMi4xMTk5NjBdIGluaXRjYWxsIGFpb19zZXR1cCsweDAvMHg4NyByZXR1cm5lZCAwIGFm dGVyIDEwIHVzZWNzDQpbICAgIDIuMTE5OTcyXSBjYWxsaW5nICBwcm9jX2xvY2tzX2luaXQr MHgwLzB4MjcgQCAxDQpbICAgIDIuMTE5OTg0XSBpbml0Y2FsbCBwcm9jX2xvY2tzX2luaXQr MHgwLzB4MjcgcmV0dXJuZWQgMCBhZnRlciAyIHVzZWNzDQpbICAgIDIuMTE5OTk2XSBjYWxs aW5nICBpbml0X21iY2FjaGUrMHgwLzB4MTEgQCAxDQpbICAgIDIuMTIwMDA4XSBpbml0Y2Fs bCBpbml0X21iY2FjaGUrMHgwLzB4MTEgcmV0dXJuZWQgMCBhZnRlciAxIHVzZWNzDQpbICAg IDIuMTIwMDIwXSBjYWxsaW5nICBwcm9jX2NtZGxpbmVfaW5pdCsweDAvMHgyNyBAIDENClsg ICAgMi4xMjAwMzJdIGluaXRjYWxsIHByb2NfY21kbGluZV9pbml0KzB4MC8weDI3IHJldHVy bmVkIDAgYWZ0ZXIgMiB1c2Vjcw0KWyAgICAyLjEyMDA0NF0gY2FsbGluZyAgcHJvY19jb25z b2xlc19pbml0KzB4MC8weDI3IEAgMQ0KWyAgICAyLjEyMDA2MV0gaW5pdGNhbGwgcHJvY19j b25zb2xlc19pbml0KzB4MC8weDI3IHJldHVybmVkIDAgYWZ0ZXIgMSB1c2Vjcw0KWyAgICAy LjEyMDA3M10gY2FsbGluZyAgcHJvY19jcHVpbmZvX2luaXQrMHgwLzB4MjcgQCAxDQpbICAg IDIuMTIwMDg1XSBpbml0Y2FsbCBwcm9jX2NwdWluZm9faW5pdCsweDAvMHgyNyByZXR1cm5l ZCAwIGFmdGVyIDEgdXNlY3MNClsgICAgMi4xMjAwOTddIGNhbGxpbmcgIHByb2NfZGV2aWNl c19pbml0KzB4MC8weDI3IEAgMQ0KWyAgICAyLjEyMDExMF0gaW5pdGNhbGwgcHJvY19kZXZp Y2VzX2luaXQrMHgwLzB4MjcgcmV0dXJuZWQgMCBhZnRlciAxIHVzZWNzDQpbICAgIDIuMTIw MTIyXSBjYWxsaW5nICBwcm9jX2ludGVycnVwdHNfaW5pdCsweDAvMHgyNyBAIDENClsgICAg Mi4xMjAxMzRdIGluaXRjYWxsIHByb2NfaW50ZXJydXB0c19pbml0KzB4MC8weDI3IHJldHVy bmVkIDAgYWZ0ZXIgMSB1c2Vjcw0KWyAgICAyLjEyMDE0Nl0gY2FsbGluZyAgcHJvY19sb2Fk YXZnX2luaXQrMHgwLzB4MjcgQCAxDQpbICAgIDIuMTIwMTU4XSBpbml0Y2FsbCBwcm9jX2xv YWRhdmdfaW5pdCsweDAvMHgyNyByZXR1cm5lZCAwIGFmdGVyIDEgdXNlY3MNClsgICAgMi4x MjAxNjldIGNhbGxpbmcgIHByb2NfbWVtaW5mb19pbml0KzB4MC8weDI3IEAgMQ0KWyAgICAy LjEyMDE4MV0gaW5pdGNhbGwgcHJvY19tZW1pbmZvX2luaXQrMHgwLzB4MjcgcmV0dXJuZWQg MCBhZnRlciAxIHVzZWNzDQpbICAgIDIuMTIwMTkzXSBjYWxsaW5nICBwcm9jX3N0YXRfaW5p dCsweDAvMHgyNyBAIDENClsgICAgMi4xMjAyMDRdIGluaXRjYWxsIHByb2Nfc3RhdF9pbml0 KzB4MC8weDI3IHJldHVybmVkIDAgYWZ0ZXIgMSB1c2Vjcw0KWyAgICAyLjEyMDIxNl0gY2Fs bGluZyAgcHJvY191cHRpbWVfaW5pdCsweDAvMHgyNyBAIDENClsgICAgMi4xMjAyMjhdIGlu aXRjYWxsIHByb2NfdXB0aW1lX2luaXQrMHgwLzB4MjcgcmV0dXJuZWQgMCBhZnRlciAxIHVz ZWNzDQpbICAgIDIuMTIwMjQwXSBjYWxsaW5nICBwcm9jX3ZlcnNpb25faW5pdCsweDAvMHgy NyBAIDENClsgICAgMi4xMjAyNTFdIGluaXRjYWxsIHByb2NfdmVyc2lvbl9pbml0KzB4MC8w eDI3IHJldHVybmVkIDAgYWZ0ZXIgMSB1c2Vjcw0KWyAgICAyLjEyMDI2M10gY2FsbGluZyAg cHJvY19zb2Z0aXJxc19pbml0KzB4MC8weDI3IEAgMQ0KWyAgICAyLjEyMDI3NV0gaW5pdGNh bGwgcHJvY19zb2Z0aXJxc19pbml0KzB4MC8weDI3IHJldHVybmVkIDAgYWZ0ZXIgMSB1c2Vj cw0KWyAgICAyLjEyMDI4N10gY2FsbGluZyAgcHJvY19rY29yZV9pbml0KzB4MC8weGFlIEAg MQ0KWyAgICAyLjEyMDI5OV0gaW5pdGNhbGwgcHJvY19rY29yZV9pbml0KzB4MC8weGFlIHJl dHVybmVkIDAgYWZ0ZXIgMiB1c2Vjcw0KWyAgICAyLjEyMDMxMV0gY2FsbGluZyAgdm1jb3Jl X2luaXQrMHgwLzB4MzdjIEAgMQ0KWyAgICAyLjEyMDMyMV0gaW5pdGNhbGwgdm1jb3JlX2lu aXQrMHgwLzB4MzdjIHJldHVybmVkIDAgYWZ0ZXIgMCB1c2Vjcw0KWyAgICAyLjEyMDMzM10g Y2FsbGluZyAgcHJvY19rbXNnX2luaXQrMHgwLzB4MmEgQCAxDQpbICAgIDIuMTIwMzQ1XSBp bml0Y2FsbCBwcm9jX2ttc2dfaW5pdCsweDAvMHgyYSByZXR1cm5lZCAwIGFmdGVyIDEgdXNl Y3MNClsgICAgMi4xMjAzNTddIGNhbGxpbmcgIHByb2NfcGFnZV9pbml0KzB4MC8weDRhIEAg MQ0KWyAgICAyLjEyMDM2OV0gaW5pdGNhbGwgcHJvY19wYWdlX2luaXQrMHgwLzB4NGEgcmV0 dXJuZWQgMCBhZnRlciAyIHVzZWNzDQpbICAgIDIuMTIwMzgxXSBjYWxsaW5nICBpbml0X2Rl dnB0c19mcysweDAvMHgzZCBAIDENClsgICAgMi4xMjA0MDJdIGluaXRjYWxsIGluaXRfZGV2 cHRzX2ZzKzB4MC8weDNkIHJldHVybmVkIDAgYWZ0ZXIgMTAgdXNlY3MNClsgICAgMi4xMjA0 MTRdIGNhbGxpbmcgIGluaXRfZXh0M19mcysweDAvMHg2YSBAIDENClsgICAgMi4xMjA0ODFd IGluaXRjYWxsIGluaXRfZXh0M19mcysweDAvMHg2YSByZXR1cm5lZCAwIGFmdGVyIDU1IHVz ZWNzDQpbICAgIDIuMTIwNDk0XSBjYWxsaW5nICBpbml0X2V4dDJfZnMrMHgwLzB4NmEgQCAx DQpbICAgIDIuMTIwNTI2XSBpbml0Y2FsbCBpbml0X2V4dDJfZnMrMHgwLzB4NmEgcmV0dXJu ZWQgMCBhZnRlciAyMSB1c2Vjcw0KWyAgICAyLjEyMDUzOF0gY2FsbGluZyAgZXh0NF9pbml0 X2ZzKzB4MC8weDFiYSBAIDENClsgICAgMi4xMjA2NzddIGluaXRjYWxsIGV4dDRfaW5pdF9m cysweDAvMHgxYmEgcmV0dXJuZWQgMCBhZnRlciAxMjUgdXNlY3MNClsgICAgMi4xMjA2OTBd IGNhbGxpbmcgIGpvdXJuYWxfaW5pdCsweDAvMHhhMyBAIDENClsgICAgMi4xMjA3NjNdIGlu aXRjYWxsIGpvdXJuYWxfaW5pdCsweDAvMHhhMyByZXR1cm5lZCAwIGFmdGVyIDYxIHVzZWNz DQpbICAgIDIuMTIwNzc2XSBjYWxsaW5nICBqb3VybmFsX2luaXQrMHgwLzB4MTA0IEAgMQ0K WyAgICAyLjEyMDgyMV0gaW5pdGNhbGwgam91cm5hbF9pbml0KzB4MC8weDEwNCByZXR1cm5l ZCAwIGFmdGVyIDMzIHVzZWNzDQpbICAgIDIuMTIwODMzXSBjYWxsaW5nICBpbml0X3NxdWFz aGZzX2ZzKzB4MC8weDY0IEAgMQ0KWyAgICAyLjEyMDg2Ml0gc3F1YXNoZnM6IHZlcnNpb24g NC4wICgyMDA5LzAxLzMxKSBQaGlsbGlwIExvdWdoZXINClsgICAgMi4xMjA4NzRdIGluaXRj YWxsIGluaXRfc3F1YXNoZnNfZnMrMHgwLzB4NjQgcmV0dXJuZWQgMCBhZnRlciAyOSB1c2Vj cw0KWyAgICAyLjEyMDg4Nl0gY2FsbGluZyAgaW5pdF9yYW1mc19mcysweDAvMHhmIEAgMQ0K WyAgICAyLjEyMDg5OF0gaW5pdGNhbGwgaW5pdF9yYW1mc19mcysweDAvMHhmIHJldHVybmVk IDAgYWZ0ZXIgMCB1c2Vjcw0KWyAgICAyLjEyMDkwOV0gY2FsbGluZyAgaW5pdF9odWdldGxi ZnNfZnMrMHgwLzB4OGIgQCAxDQpbICAgIDIuMTIwOTU0XSBpbml0Y2FsbCBpbml0X2h1Z2V0 bGJmc19mcysweDAvMHg4YiByZXR1cm5lZCAwIGFmdGVyIDMzIHVzZWNzDQpbICAgIDIuMTIw OTY2XSBjYWxsaW5nICBpbml0X2ZhdF9mcysweDAvMHg0YyBAIDENClsgICAgMi4xMjEwMTFd IGluaXRjYWxsIGluaXRfZmF0X2ZzKzB4MC8weDRjIHJldHVybmVkIDAgYWZ0ZXIgMzMgdXNl Y3MNClsgICAgMi4xMjEwMjNdIGNhbGxpbmcgIGluaXRfdmZhdF9mcysweDAvMHhmIEAgMQ0K WyAgICAyLjEyMTAzNV0gaW5pdGNhbGwgaW5pdF92ZmF0X2ZzKzB4MC8weGYgcmV0dXJuZWQg MCBhZnRlciAxIHVzZWNzDQpbICAgIDIuMTIxMDQ3XSBjYWxsaW5nICBpbml0X21zZG9zX2Zz KzB4MC8weGYgQCAxDQpbICAgIDIuMTIxMDU4XSBpbml0Y2FsbCBpbml0X21zZG9zX2ZzKzB4 MC8weGYgcmV0dXJuZWQgMCBhZnRlciAwIHVzZWNzDQpbICAgIDIuMTIxMDcwXSBjYWxsaW5n ICBpbml0X2lzbzk2NjBfZnMrMHgwLzB4NmEgQCAxDQpbICAgIDIuMTIxMTI5XSBpbml0Y2Fs bCBpbml0X2lzbzk2NjBfZnMrMHgwLzB4NmEgcmV0dXJuZWQgMCBhZnRlciA0NyB1c2Vjcw0K WyAgICAyLjEyMTE0Ml0gY2FsbGluZyAgaW5pdF9wc3RvcmVfZnMrMHgwLzB4ZiBAIDENClsg ICAgMi4xMjExNTRdIGluaXRjYWxsIGluaXRfcHN0b3JlX2ZzKzB4MC8weGYgcmV0dXJuZWQg MCBhZnRlciAxIHVzZWNzDQpbICAgIDIuMTIxMTY2XSBjYWxsaW5nICBpcGNfaW5pdCsweDAv MHgyMCBAIDENClsgICAgMi4xMjExNzZdIG1zZ21uaSBoYXMgYmVlbiBzZXQgdG8gMTE0OA0K WyAgICAyLjEyMTE4OV0gaW5pdGNhbGwgaXBjX2luaXQrMHgwLzB4MjAgcmV0dXJuZWQgMCBh ZnRlciAxMyB1c2Vjcw0KWyAgICAyLjEyMTIwMV0gY2FsbGluZyAgaXBjX3N5c2N0bF9pbml0 KzB4MC8weDExIEAgMQ0KWyAgICAyLjEyMTIzMV0gaW5pdGNhbGwgaXBjX3N5c2N0bF9pbml0 KzB4MC8weDExIHJldHVybmVkIDAgYWZ0ZXIgMTkgdXNlY3MNClsgICAgMi4xMjEyNDNdIGNh bGxpbmcgIGluaXRfbXF1ZXVlX2ZzKzB4MC8weDlmIEAgMQ0KWyAgICAyLjEyMTI5Ml0gaW5p dGNhbGwgaW5pdF9tcXVldWVfZnMrMHgwLzB4OWYgcmV0dXJuZWQgMCBhZnRlciAzNiB1c2Vj cw0KWyAgICAyLjEyMTMwNV0gY2FsbGluZyAgY3J5cHRvX3dxX2luaXQrMHgwLzB4MzggQCAx DQpbICAgIDIuMTIxMzgwXSBpbml0Y2FsbCBjcnlwdG9fd3FfaW5pdCsweDAvMHgzOCByZXR1 cm5lZCAwIGFmdGVyIDYyIHVzZWNzDQpbICAgIDIuMTIxMzkzXSBjYWxsaW5nICBjcnlwdG9f YWxnYXBpX2luaXQrMHgwLzB4YyBAIDENClsgICAgMi4xMjE0MDZdIGluaXRjYWxsIGNyeXB0 b19hbGdhcGlfaW5pdCsweDAvMHhjIHJldHVybmVkIDAgYWZ0ZXIgMiB1c2Vjcw0KWyAgICAy LjEyMTQxOV0gY2FsbGluZyAgc2tjaXBoZXJfbW9kdWxlX2luaXQrMHgwLzB4MmUgQCAxDQpb ICAgIDIuMTIxNDMwXSBpbml0Y2FsbCBza2NpcGhlcl9tb2R1bGVfaW5pdCsweDAvMHgyZSBy ZXR1cm5lZCAwIGFmdGVyIDAgdXNlY3MNClsgICAgMi4xMjE0NDFdIGNhbGxpbmcgIGNoYWlu aXZfbW9kdWxlX2luaXQrMHgwLzB4ZiBAIDENClsgICAgMi4xMjE0NTJdIGluaXRjYWxsIGNo YWluaXZfbW9kdWxlX2luaXQrMHgwLzB4ZiByZXR1cm5lZCAwIGFmdGVyIDEgdXNlY3MNClsg ICAgMi4xMjE0NjRdIGNhbGxpbmcgIGVzZXFpdl9tb2R1bGVfaW5pdCsweDAvMHhmIEAgMQ0K WyAgICAyLjEyMTQ3NF0gaW5pdGNhbGwgZXNlcWl2X21vZHVsZV9pbml0KzB4MC8weGYgcmV0 dXJuZWQgMCBhZnRlciAwIHVzZWNzDQpbICAgIDIuMTIxNDg1XSBjYWxsaW5nICBobWFjX21v ZHVsZV9pbml0KzB4MC8weGYgQCAxDQpbICAgIDIuMTIxNDk2XSBpbml0Y2FsbCBobWFjX21v ZHVsZV9pbml0KzB4MC8weGYgcmV0dXJuZWQgMCBhZnRlciAwIHVzZWNzDQpbICAgIDIuMTIx NTA3XSBjYWxsaW5nICBtZDVfbW9kX2luaXQrMHgwLzB4ZiBAIDENClsgICAgMi4xMjE1OTdd IGluaXRjYWxsIG1kNV9tb2RfaW5pdCsweDAvMHhmIHJldHVybmVkIDAgYWZ0ZXIgNzcgdXNl Y3MNClsgICAgMi4xMjE2MDldIGNhbGxpbmcgIHNoYTFfZ2VuZXJpY19tb2RfaW5pdCsweDAv MHhmIEAgMQ0KWyAgICAyLjEyMTY2NV0gaW5pdGNhbGwgc2hhMV9nZW5lcmljX21vZF9pbml0 KzB4MC8weGYgcmV0dXJuZWQgMCBhZnRlciA0NCB1c2Vjcw0KWyAgICAyLjEyMTY3OV0gY2Fs bGluZyAgY3J5cHRvX2VjYl9tb2R1bGVfaW5pdCsweDAvMHhmIEAgMQ0KWyAgICAyLjEyMTY5 MF0gaW5pdGNhbGwgY3J5cHRvX2VjYl9tb2R1bGVfaW5pdCsweDAvMHhmIHJldHVybmVkIDAg YWZ0ZXIgMCB1c2Vjcw0KWyAgICAyLjEyMTcwM10gY2FsbGluZyAgY3J5cHRvX2NiY19tb2R1 bGVfaW5pdCsweDAvMHhmIEAgMQ0KWyAgICAyLjEyMTcxNF0gaW5pdGNhbGwgY3J5cHRvX2Ni Y19tb2R1bGVfaW5pdCsweDAvMHhmIHJldHVybmVkIDAgYWZ0ZXIgMCB1c2Vjcw0KWyAgICAy LjEyMTcyN10gY2FsbGluZyAgY3JjMzJjX21vZF9pbml0KzB4MC8weGYgQCAxDQpbICAgIDIu MTIxODE0XSBpbml0Y2FsbCBjcmMzMmNfbW9kX2luaXQrMHgwLzB4ZiByZXR1cm5lZCAwIGFm dGVyIDc0IHVzZWNzDQpbICAgIDIuMTIxODI2XSBjYWxsaW5nICBrcm5nX21vZF9pbml0KzB4 MC8weGYgQCAxDQpbICAgIDIuMTIxODgyXSBpbml0Y2FsbCBrcm5nX21vZF9pbml0KzB4MC8w eGYgcmV0dXJuZWQgMCBhZnRlciA0NCB1c2Vjcw0KWyAgICAyLjEyMTg5NV0gY2FsbGluZyAg cHJvY19nZW5oZF9pbml0KzB4MC8weDQ0IEAgMQ0KWyAgICAyLjEyMTkwOF0gaW5pdGNhbGwg cHJvY19nZW5oZF9pbml0KzB4MC8weDQ0IHJldHVybmVkIDAgYWZ0ZXIgMyB1c2Vjcw0KWyAg ICAyLjEyMTkyMF0gY2FsbGluZyAgYnNnX2luaXQrMHgwLzB4MTE5IEAgMQ0KWyAgICAyLjEy MTk2MV0gQmxvY2sgbGF5ZXIgU0NTSSBnZW5lcmljIChic2cpIGRyaXZlciB2ZXJzaW9uIDAu NCBsb2FkZWQgKG1ham9yIDI1MykNClsgICAgMi4xMjE5NzRdIGluaXRjYWxsIGJzZ19pbml0 KzB4MC8weDExOSByZXR1cm5lZCAwIGFmdGVyIDQ0IHVzZWNzDQpbICAgIDIuMTIxOTg2XSBj YWxsaW5nICBpbml0X2Nncm91cF9ibGtpbysweDAvMHhmIEAgMQ0KWyAgICAyLjEyMTk5N10g aW5pdGNhbGwgaW5pdF9jZ3JvdXBfYmxraW8rMHgwLzB4ZiByZXR1cm5lZCAwIGFmdGVyIDAg dXNlY3MNClsgICAgMi4xMjIwMDhdIGNhbGxpbmcgIHRocm90bF9pbml0KzB4MC8weDQ5IEAg MQ0KWyAgICAyLjEyMjA4Nl0gaW5pdGNhbGwgdGhyb3RsX2luaXQrMHgwLzB4NDkgcmV0dXJu ZWQgMCBhZnRlciA2NiB1c2Vjcw0KWyAgICAyLjEyMjA5OF0gY2FsbGluZyAgbm9vcF9pbml0 KzB4MC8weDExIEAgMQ0KWyAgICAyLjEyMjEwN10gaW8gc2NoZWR1bGVyIG5vb3AgcmVnaXN0 ZXJlZA0KWyAgICAyLjEyMjExNV0gaW5pdGNhbGwgbm9vcF9pbml0KzB4MC8weDExIHJldHVy bmVkIDAgYWZ0ZXIgOCB1c2Vjcw0KWyAgICAyLjEyMjEyN10gY2FsbGluZyAgZGVhZGxpbmVf aW5pdCsweDAvMHgxMSBAIDENClsgICAgMi4xMjIxMzddIGlvIHNjaGVkdWxlciBkZWFkbGlu ZSByZWdpc3RlcmVkDQpbICAgIDIuMTIyMTQ3XSBpbml0Y2FsbCBkZWFkbGluZV9pbml0KzB4 MC8weDExIHJldHVybmVkIDAgYWZ0ZXIgOSB1c2Vjcw0KWyAgICAyLjEyMjE1OF0gY2FsbGlu ZyAgY2ZxX2luaXQrMHgwLzB4YmIgQCAxDQpbICAgIDIuMTIyMTc1XSBpbyBzY2hlZHVsZXIg Y2ZxIHJlZ2lzdGVyZWQgKGRlZmF1bHQpDQpbICAgIDIuMTIyMTg1XSBpbml0Y2FsbCBjZnFf aW5pdCsweDAvMHhiYiByZXR1cm5lZCAwIGFmdGVyIDE4IHVzZWNzDQpbICAgIDIuMTIyMTk3 XSBjYWxsaW5nICBsaWJjcmMzMmNfbW9kX2luaXQrMHgwLzB4MjUgQCAxDQpbICAgIDIuMTIy MjA5XSBpbml0Y2FsbCBsaWJjcmMzMmNfbW9kX2luaXQrMHgwLzB4MjUgcmV0dXJuZWQgMCBh ZnRlciAyIHVzZWNzDQpbICAgIDIuMTIyMjIxXSBjYWxsaW5nICBwZXJjcHVfY291bnRlcl9z dGFydHVwKzB4MC8weDJlIEAgMQ0KWyAgICAyLjEyMjIzMl0gaW5pdGNhbGwgcGVyY3B1X2Nv dW50ZXJfc3RhcnR1cCsweDAvMHgyZSByZXR1cm5lZCAwIGFmdGVyIDAgdXNlY3MNClsgICAg Mi4xMjIyNDVdIGNhbGxpbmcgIGF1ZGl0X2NsYXNzZXNfaW5pdCsweDAvMHg0ZiBAIDENClsg ICAgMi4xMjIyNTddIGluaXRjYWxsIGF1ZGl0X2NsYXNzZXNfaW5pdCsweDAvMHg0ZiByZXR1 cm5lZCAwIGFmdGVyIDEgdXNlY3MNClsgICAgMi4xMjIyNjhdIGNhbGxpbmcgIGxud19ncGlv X2luaXQrMHgwLzB4M2EgQCAxDQpbICAgIDIuMTIyMzA1XSBpbml0Y2FsbCBsbndfZ3Bpb19p bml0KzB4MC8weDNhIHJldHVybmVkIDAgYWZ0ZXIgMjUgdXNlY3MNClsgICAgMi4xMjIzMTdd IGNhbGxpbmcgIHRpbWJncGlvX2luaXQrMHgwLzB4ZiBAIDENClsgICAgMi4xMjIzMzNdIGlu aXRjYWxsIHRpbWJncGlvX2luaXQrMHgwLzB4ZiByZXR1cm5lZCAwIGFmdGVyIDUgdXNlY3MN ClsgICAgMi4xMjIzNDRdIGNhbGxpbmcgIHBjaV9wcm9jX2luaXQrMHgwLzB4NjQgQCAxDQpb ICAgIDIuMTIyMzkyXSBpbml0Y2FsbCBwY2lfcHJvY19pbml0KzB4MC8weDY0IHJldHVybmVk IDAgYWZ0ZXIgMzYgdXNlY3MNClsgICAgMi4xMjI0MDRdIGNhbGxpbmcgIHBjaWVfcG9ydGRy dl9pbml0KzB4MC8weDZmIEAgMQ0KWyAgICAyLjEyMjQ0OV0gcGNpZXBvcnQgMDAwMDowMDow OS4wOiBzZXR0aW5nIGxhdGVuY3kgdGltZXIgdG8gNjQNClsgICAgMi4xMjI1ODddIHBjaWVw b3J0IDAwMDA6MDA6MGIuMDogc2V0dGluZyBsYXRlbmN5IHRpbWVyIHRvIDY0DQpbICAgIDIu MTIyNzA5XSBwY2llcG9ydCAwMDAwOjAwOjBjLjA6IHNldHRpbmcgbGF0ZW5jeSB0aW1lciB0 byA2NA0KWyAgICAyLjEyMjgyNV0gaW5pdGNhbGwgcGNpZV9wb3J0ZHJ2X2luaXQrMHgwLzB4 NmYgcmV0dXJuZWQgMCBhZnRlciA0MDEgdXNlY3MNClsgICAgMi4xMjI4MzhdIGNhbGxpbmcg IGFlcl9zZXJ2aWNlX2luaXQrMHgwLzB4MjggQCAxDQpbICAgIDIuMTIyODU0XSBpbml0Y2Fs bCBhZXJfc2VydmljZV9pbml0KzB4MC8weDI4IHJldHVybmVkIDAgYWZ0ZXIgNSB1c2Vjcw0K WyAgICAyLjEyMjg2Nl0gY2FsbGluZyAgcGNpZV9wbWVfc2VydmljZV9pbml0KzB4MC8weGYg QCAxDQpbICAgIDIuMTIyODgyXSBpbml0Y2FsbCBwY2llX3BtZV9zZXJ2aWNlX2luaXQrMHgw LzB4ZiByZXR1cm5lZCAwIGFmdGVyIDUgdXNlY3MNClsgICAgMi4xMjI4OTRdIGNhbGxpbmcg IGlvYXBpY19pbml0KzB4MC8weDE2IEAgMQ0KWyAgICAyLjEyMjkxMl0gaW5pdGNhbGwgaW9h cGljX2luaXQrMHgwLzB4MTYgcmV0dXJuZWQgMCBhZnRlciA4IHVzZWNzDQpbICAgIDIuMTIy OTI0XSBjYWxsaW5nICBwY2lfaG90cGx1Z19pbml0KzB4MC8weDRkIEAgMQ0KWyAgICAyLjEy MjkzNF0gcGNpX2hvdHBsdWc6IFBDSSBIb3QgUGx1ZyBQQ0kgQ29yZSB2ZXJzaW9uOiAwLjUN ClsgICAgMi4xMjI5NDRdIGluaXRjYWxsIHBjaV9ob3RwbHVnX2luaXQrMHgwLzB4NGQgcmV0 dXJuZWQgMCBhZnRlciA5IHVzZWNzDQpbICAgIDIuMTIyOTU2XSBjYWxsaW5nICBwY2llZF9p bml0KzB4MC8weGYxIEAgMQ0KWyAgICAyLjEyMjk4M10gcGNpZWhwOiBQQ0kgRXhwcmVzcyBI b3QgUGx1ZyBDb250cm9sbGVyIERyaXZlciB2ZXJzaW9uOiAwLjQNClsgICAgMi4xMjI5OTZd IGluaXRjYWxsIHBjaWVkX2luaXQrMHgwLzB4ZjEgcmV0dXJuZWQgMCBhZnRlciAyOSB1c2Vj cw0KWyAgICAyLjEyMzAwOF0gY2FsbGluZyAgaW50ZWxfaWRsZV9pbml0KzB4MC8weDM3NyBA IDENClsgICAgMi4xMjMwMThdIGluaXRjYWxsIGludGVsX2lkbGVfaW5pdCsweDAvMHgzNzcg cmV0dXJuZWQgLTE5IGFmdGVyIDAgdXNlY3MNClsgICAgMi4xMjMwMzFdIGNhbGxpbmcgIGFj cGlfcmVzZXJ2ZV9yZXNvdXJjZXMrMHgwLzB4YzggQCAxDQpbICAgIDIuMTIzMDQ0XSBpbml0 Y2FsbCBhY3BpX3Jlc2VydmVfcmVzb3VyY2VzKzB4MC8weGM4IHJldHVybmVkIDAgYWZ0ZXIg MyB1c2Vjcw0KWyAgICAyLjEyMzA1OF0gY2FsbGluZyAgaXJxcm91dGVyX2luaXRfb3BzKzB4 MC8weDIzIEAgMQ0KWyAgICAyLjEyMzA2OV0gaW5pdGNhbGwgaXJxcm91dGVyX2luaXRfb3Bz KzB4MC8weDIzIHJldHVybmVkIDAgYWZ0ZXIgMCB1c2Vjcw0KWyAgICAyLjEyMzA4MV0gY2Fs bGluZyAgYWNwaV9hY19pbml0KzB4MC8weDNkIEAgMQ0KWyAgICAyLjEyMzExNV0gaW5pdGNh bGwgYWNwaV9hY19pbml0KzB4MC8weDNkIHJldHVybmVkIDAgYWZ0ZXIgMjMgdXNlY3MNClsg ICAgMi4xMjMxMjhdIGNhbGxpbmcgIGFjcGlfYnV0dG9uX2luaXQrMHgwLzB4ZiBAIDENClsg ICAgMi4xMjMxNzddIGlucHV0OiBQb3dlciBCdXR0b24gYXMgL2RldmljZXMvTE5YU1lTVE06 MDAvZGV2aWNlOjAwL1BOUDBDMEM6MDAvaW5wdXQvaW5wdXQwDQpbICAgIDIuMTIzMTkzXSBB Q1BJOiBQb3dlciBCdXR0b24gW1BXUkJdDQpbICAgIDIuMTIzMjMxXSBpbnB1dDogUG93ZXIg QnV0dG9uIGFzIC9kZXZpY2VzL0xOWFNZU1RNOjAwL0xOWFBXUkJOOjAwL2lucHV0L2lucHV0 MQ0KWyAgICAyLjEyMzI0NV0gQUNQSTogUG93ZXIgQnV0dG9uIFtQV1JGXQ0KWyAgICAyLjEy MzI3Ml0gaW5pdGNhbGwgYWNwaV9idXR0b25faW5pdCsweDAvMHhmIHJldHVybmVkIDAgYWZ0 ZXIgMTMwIHVzZWNzDQpbICAgIDIuMTIzMjg0XSBjYWxsaW5nICBhY3BpX2Zhbl9pbml0KzB4 MC8weDE1IEAgMQ0KWyAgICAyLjEyMzMwN10gaW5pdGNhbGwgYWNwaV9mYW5faW5pdCsweDAv MHgxNSByZXR1cm5lZCAwIGFmdGVyIDEyIHVzZWNzDQpbICAgIDIuMTIzMzIwXSBjYWxsaW5n ICBhY3BpX3BjaV9zbG90X2luaXQrMHgwLzB4MWIgQCAxDQpbICAgIDIuMTIzNDgwXSBpbml0 Y2FsbCBhY3BpX3BjaV9zbG90X2luaXQrMHgwLzB4MWIgcmV0dXJuZWQgMCBhZnRlciAxNDUg dXNlY3MNClsgICAgMi4xMjM0OTNdIGNhbGxpbmcgIGFjcGlfcHJvY2Vzc29yX2luaXQrMHgw LzB4ZDAgQCAxDQpbICAgIDIuMTIzNTAzXSBBQ1BJOiBhY3BpX2lkbGUgcmVnaXN0ZXJlZCB3 aXRoIGNwdWlkbGUNClsgICAgMi4xMjM2NDNdIGluaXRjYWxsIGFjcGlfcHJvY2Vzc29yX2lu aXQrMHgwLzB4ZDAgcmV0dXJuZWQgMCBhZnRlciAxMzUgdXNlY3MNClsgICAgMi4xMjM2NThd IGNhbGxpbmcgIGFjcGlfY29udGFpbmVyX2luaXQrMHgwLzB4NGQgQCAxDQpbICAgIDIuMTI1 ODYyXSBpbml0Y2FsbCBhY3BpX2NvbnRhaW5lcl9pbml0KzB4MC8weDRkIHJldHVybmVkIDAg YWZ0ZXIgMjE0MSB1c2Vjcw0KWyAgICAyLjEyNTg3N10gY2FsbGluZyAgYWNwaV90aGVybWFs X2luaXQrMHgwLzB4M2UgQCAxDQpbICAgIDIuMTI1OTAyXSBpbml0Y2FsbCBhY3BpX3RoZXJt YWxfaW5pdCsweDAvMHgzZSByZXR1cm5lZCAwIGFmdGVyIDEzIHVzZWNzDQpbICAgIDIuMTI1 OTE0XSBjYWxsaW5nICBhY3BpX2JhdHRlcnlfaW5pdCsweDAvMHgxMyBAIDENClsgICAgMi4x MjU5MjldIGluaXRjYWxsIGFjcGlfYmF0dGVyeV9pbml0KzB4MC8weDEzIHJldHVybmVkIDAg YWZ0ZXIgNCB1c2Vjcw0KWyAgICAyLjEyNTk0MV0gY2FsbGluZyAgYWNwaV9zbWJfaGNfaW5p dCsweDAvMHgxNSBAIDENClsgICAgMi4xMjU5ODldIGluaXRjYWxsIGFjcGlfc21iX2hjX2lu aXQrMHgwLzB4MTUgcmV0dXJuZWQgMCBhZnRlciAzNiB1c2Vjcw0KWyAgICAyLjEyNjAwMl0g Y2FsbGluZyAgYWNwaV9zYnNfaW5pdCsweDAvMHg0NiBAIDENClsgICAgMi4xMjYwMjZdIGlu aXRjYWxsIGFjcGlfc2JzX2luaXQrMHgwLzB4NDYgcmV0dXJuZWQgMCBhZnRlciAxMiB1c2Vj cw0KWyAgICAyLjEyNjAzOV0gY2FsbGluZyAgZXJzdF9pbml0KzB4MC8weDJjNCBAIDENClsg ICAgMi4xMjYwNDhdIEVSU1Q6IFRhYmxlIGlzIG5vdCBmb3VuZCENClsgICAgMi4xMjYwNTdd IGluaXRjYWxsIGVyc3RfaW5pdCsweDAvMHgyYzQgcmV0dXJuZWQgMCBhZnRlciA3IHVzZWNz DQpbICAgIDIuMTI2MDY5XSBjYWxsaW5nICBwbnBiaW9zX3RocmVhZF9pbml0KzB4MC8weDVl IEAgMQ0KWyAgICAyLjEyNjEwMl0gY2FsbGluZyAgMV9hY3BpX2JhdHRlcnlfaW5pdF9hc3lu YysweDAvMHgzNCBAIDUNClsgICAgMi4xMjYxMjddIGluaXRjYWxsIDFfYWNwaV9iYXR0ZXJ5 X2luaXRfYXN5bmMrMHgwLzB4MzQgcmV0dXJuZWQgMCBhZnRlciAxMyB1c2Vjcw0KWyAgICAy LjEyNjE1MF0gaW5pdGNhbGwgcG5wYmlvc190aHJlYWRfaW5pdCsweDAvMHg1ZSByZXR1cm5l ZCAwIGFmdGVyIDY4IHVzZWNzDQpbICAgIDIuMTI2MTYzXSBjYWxsaW5nICBpc2FwbnBfaW5p dCsweDAvMHg2NDIgQCAxDQpbICAgIDIuMTI2MTgwXSBpc2FwbnA6IFNjYW5uaW5nIGZvciBQ blAgY2FyZHMuLi4NClsgICAgMi40ODA3NjBdIGlzYXBucDogTm8gUGx1ZyAmIFBsYXkgZGV2 aWNlIGZvdW5kDQpbICAgIDIuNDgwNzcyXSBpbml0Y2FsbCBpc2FwbnBfaW5pdCsweDAvMHg2 NDIgcmV0dXJuZWQgMCBhZnRlciAzNDYyODcgdXNlY3MNClsgICAgMi40ODA3ODRdIGNhbGxp bmcgIHZpcnRpb19wY2lfaW5pdCsweDAvMHgxNiBAIDENClsgICAgMi40ODA4MDddIGluaXRj YWxsIHZpcnRpb19wY2lfaW5pdCsweDAvMHgxNiByZXR1cm5lZCAwIGFmdGVyIDEyIHVzZWNz DQpbICAgIDIuNDgwODIwXSBjYWxsaW5nICB4ZW5idXNfcHJvYmVfaW5pdGNhbGwrMHgwLzB4 MzggQCAxDQpbICAgIDIuNDgwODMxXSBpbml0Y2FsbCB4ZW5idXNfcHJvYmVfaW5pdGNhbGwr MHgwLzB4MzggcmV0dXJuZWQgMCBhZnRlciAwIHVzZWNzDQpbICAgIDIuNDgwODQ0XSBjYWxs aW5nICB4ZW5fdG1lbV9pbml0KzB4MC8weDcgQCAxDQpbICAgIDIuNDgwODU1XSBpbml0Y2Fs bCB4ZW5fdG1lbV9pbml0KzB4MC8weDcgcmV0dXJuZWQgMCBhZnRlciAwIHVzZWNzDQpbICAg IDIuNDgwODY3XSBjYWxsaW5nICBldnRjaG5faW5pdCsweDAvMHg2OSBAIDENClsgICAgMi40 ODA5MTldIEV2ZW50LWNoYW5uZWwgZGV2aWNlIGluc3RhbGxlZC4NClsgICAgMi40ODA5Mjld IGluaXRjYWxsIGV2dGNobl9pbml0KzB4MC8weDY5IHJldHVybmVkIDAgYWZ0ZXIgNDkgdXNl Y3MNClsgICAgMi40ODA5NDFdIGNhbGxpbmcgIGdudGRldl9pbml0KzB4MC8weDQ1IEAgMQ0K WyAgICAyLjQ4MDk2Nl0gaW5pdGNhbGwgZ250ZGV2X2luaXQrMHgwLzB4NDUgcmV0dXJuZWQg MCBhZnRlciAxNCB1c2Vjcw0KWyAgICAyLjQ4MDk3OF0gY2FsbGluZyAgZ250YWxsb2NfaW5p dCsweDAvMHgzNyBAIDENClsgICAgMi40ODEwMDNdIGluaXRjYWxsIGdudGFsbG9jX2luaXQr MHgwLzB4MzcgcmV0dXJuZWQgMCBhZnRlciAxMyB1c2Vjcw0KWyAgICAyLjQ4MTAxNV0gY2Fs bGluZyAgeGVuZnNfaW5pdCsweDAvMHgyYiBAIDENClsgICAgMi40ODEwMjhdIGluaXRjYWxs IHhlbmZzX2luaXQrMHgwLzB4MmIgcmV0dXJuZWQgMCBhZnRlciAxIHVzZWNzDQpbICAgIDIu NDgxMDQwXSBjYWxsaW5nICBoeXBlcnZpc29yX3N1YnN5c19pbml0KzB4MC8weDIxIEAgMQ0K WyAgICAyLjQ4MTA1MV0gaW5pdGNhbGwgaHlwZXJ2aXNvcl9zdWJzeXNfaW5pdCsweDAvMHgy MSByZXR1cm5lZCAwIGFmdGVyIDAgdXNlY3MNClsgICAgMi40ODEwNjRdIGNhbGxpbmcgIGh5 cGVyX3N5c2ZzX2luaXQrMHgwLzB4YzQgQCAxDQpbICAgIDIuNDgxMDgxXSBpbml0Y2FsbCBo eXBlcl9zeXNmc19pbml0KzB4MC8weGM0IHJldHVybmVkIDAgYWZ0ZXIgNSB1c2Vjcw0KWyAg ICAyLjQ4MTA5M10gY2FsbGluZyAgcGxhdGZvcm1fcGNpX21vZHVsZV9pbml0KzB4MC8weDI0 IEAgMQ0KWyAgICAyLjQ4MTEwNF0gaW5pdGNhbGwgcGxhdGZvcm1fcGNpX21vZHVsZV9pbml0 KzB4MC8weDI0IHJldHVybmVkIC0xOSBhZnRlciAwIHVzZWNzDQpbICAgIDIuNDgxMTE3XSBj YWxsaW5nICBwdHlfaW5pdCsweDAvMHgyYmQgQCAxDQpbICAgIDIuNDgxMTY1XSBpbml0Y2Fs bCBwdHlfaW5pdCsweDAvMHgyYmQgcmV0dXJuZWQgMCBhZnRlciAzNyB1c2Vjcw0KWyAgICAy LjQ4MTE3N10gY2FsbGluZyAgc3lzcnFfaW5pdCsweDAvMHg3YSBAIDENClsgICAgMi40ODEx OTFdIGluaXRjYWxsIHN5c3JxX2luaXQrMHgwLzB4N2EgcmV0dXJuZWQgMCBhZnRlciAzIHVz ZWNzDQpbICAgIDIuNDgxMjAzXSBjYWxsaW5nICB4ZW5faHZjX2luaXQrMHgwLzB4MTE1IEAg MQ0KWyAgICAyLjQ4MTM5N10gaW5pdGNhbGwgeGVuX2h2Y19pbml0KzB4MC8weDExNSByZXR1 cm5lZCAwIGFmdGVyIDE3OSB1c2Vjcw0KWyAgICAyLjQ4MTQxMF0gY2FsbGluZyAgc2VyaWFs ODI1MF9pbml0KzB4MC8weDE1NCBAIDENClsgICAgMi40ODE0MjBdIFNlcmlhbDogODI1MC8x NjU1MCBkcml2ZXIsIDMyIHBvcnRzLCBJUlEgc2hhcmluZyBlbmFibGVkDQpbICAgIDIuNDg1 MjgwXSBzZXJpYWw4MjUwOiB0dHlTMCBhdCBJL08gMHgzZjggKGlycSA9IDQpIGlzIGEgMTY1 NTBBDQpbICAgIDIuNjI0MTYwXSBpbml0Y2FsbCBzZXJpYWw4MjUwX2luaXQrMHgwLzB4MTU0 IHJldHVybmVkIDAgYWZ0ZXIgMTM5Mzg5IHVzZWNzDQpbICAgIDIuNjI0MTg0XSBjYWxsaW5n ICBzZXJpYWw4MjUwX3BucF9pbml0KzB4MC8weGYgQCAxDQpbICAgIDIuNjI4MDk3XSAwMDow YjogdHR5UzAgYXQgSS9PIDB4M2Y4IChpcnEgPSA0KSBpcyBhIDE2NTUwQQ0KWyAgICAyLjY0 ODE1OF0gaW5pdGNhbGwgc2VyaWFsODI1MF9wbnBfaW5pdCsweDAvMHhmIHJldHVybmVkIDAg YWZ0ZXIgMjMzOTcgdXNlY3MNClsgICAgMi42NDgxODJdIGNhbGxpbmcgIHNlcmlhbDgyNTBf cGNpX2luaXQrMHgwLzB4MTYgQCAxDQpbICAgIDIuNjQ4MjI1XSBpbml0Y2FsbCBzZXJpYWw4 MjUwX3BjaV9pbml0KzB4MC8weDE2IHJldHVybmVkIDAgYWZ0ZXIgMzEgdXNlY3MNClsgICAg Mi42NDgyMzhdIGNhbGxpbmcgIGluaXRfa2dkYm9jKzB4MC8weDE1IEAgMQ0KWyAgICAyLjY0 ODI1MF0gaW5pdGNhbGwgaW5pdF9rZ2Rib2MrMHgwLzB4MTUgcmV0dXJuZWQgMCBhZnRlciAy IHVzZWNzDQpbICAgIDIuNjQ4MjYzXSBjYWxsaW5nICByYW5kX2luaXRpYWxpemUrMHgwLzB4 MzAgQCAxDQpbICAgIDIuNjQ4Mjg4XSBpbml0Y2FsbCByYW5kX2luaXRpYWxpemUrMHgwLzB4 MzAgcmV0dXJuZWQgMCBhZnRlciAxNSB1c2Vjcw0KWyAgICAyLjY0ODMwMF0gY2FsbGluZyAg dHR5cHJpbnRrX2luaXQrMHgwLzB4MTJkIEAgMQ0KWyAgICAyLjY0ODM3N10gaW5pdGNhbGwg dHR5cHJpbnRrX2luaXQrMHgwLzB4MTJkIHJldHVybmVkIDAgYWZ0ZXIgNjUgdXNlY3MNClsg ICAgMi42NDgzODldIGNhbGxpbmcgIGhwZXRfaW5pdCsweDAvMHg1NyBAIDENClsgICAgMi42 NDg1MjVdIGhwZXRfYWNwaV9hZGQ6IG5vIGFkZHJlc3Mgb3IgaXJxcyBpbiBfQ1JTDQpbICAg IDIuNjQ4NTU0XSBpbml0Y2FsbCBocGV0X2luaXQrMHgwLzB4NTcgcmV0dXJuZWQgMCBhZnRl ciAxNTIgdXNlY3MNClsgICAgMi42NDg1NjZdIGNhbGxpbmcgIGFncF9pbml0KzB4MC8weDJm IEAgMQ0KWyAgICAyLjY0ODU3NF0gTGludXggYWdwZ2FydCBpbnRlcmZhY2UgdjAuMTAzDQpb ICAgIDIuNjQ4NTgyXSBpbml0Y2FsbCBhZ3BfaW5pdCsweDAvMHgyZiByZXR1cm5lZCAwIGFm dGVyIDcgdXNlY3MNClsgICAgMi42NDg1OTRdIGNhbGxpbmcgIGFncF9hbWRrN19pbml0KzB4 MC8weDI0IEAgMQ0KWyAgICAyLjY0ODYxM10gaW5pdGNhbGwgYWdwX2FtZGs3X2luaXQrMHgw LzB4MjQgcmV0dXJuZWQgMCBhZnRlciA5IHVzZWNzDQpbICAgIDIuNjQ4NjI1XSBjYWxsaW5n ICBhZ3BfYW1kNjRfbW9kX2luaXQrMHgwLzB4YSBAIDENClsgICAgMi42NDg4MzddIGluaXRj YWxsIGFncF9hbWQ2NF9tb2RfaW5pdCsweDAvMHhhIHJldHVybmVkIC0xOSBhZnRlciAxOTcg dXNlY3MNClsgICAgMi42NDg4NTFdIGNhbGxpbmcgIGFncF9pbnRlbF9pbml0KzB4MC8weDI0 IEAgMQ0KWyAgICAyLjY0ODg3NF0gaW5pdGNhbGwgYWdwX2ludGVsX2luaXQrMHgwLzB4MjQg cmV0dXJuZWQgMCBhZnRlciAxMiB1c2Vjcw0KWyAgICAyLjY0ODg4Nl0gY2FsbGluZyAgYWdw X252aWRpYV9pbml0KzB4MC8weDI0IEAgMQ0KWyAgICAyLjY0ODkwNF0gaW5pdGNhbGwgYWdw X252aWRpYV9pbml0KzB4MC8weDI0IHJldHVybmVkIDAgYWZ0ZXIgOCB1c2Vjcw0KWyAgICAy LjY0ODkxNl0gY2FsbGluZyAgYWdwX3ZpYV9pbml0KzB4MC8weDI0IEAgMQ0KWyAgICAyLjY0 ODkzN10gaW5pdGNhbGwgYWdwX3ZpYV9pbml0KzB4MC8weDI0IHJldHVybmVkIDAgYWZ0ZXIg MTEgdXNlY3MNClsgICAgMi42NDg5NDldIGNhbGxpbmcgIGNuX3Byb2NfaW5pdCsweDAvMHgz MyBAIDENClsgICAgMi42NDg5NjBdIGluaXRjYWxsIGNuX3Byb2NfaW5pdCsweDAvMHgzMyBy ZXR1cm5lZCAwIGFmdGVyIDEgdXNlY3MNClsgICAgMi42NDg5NzJdIGNhbGxpbmcgIGlzYV9i dXNfaW5pdCsweDAvMHgzMyBAIDENClsgICAgMi42NDg5OTddIGluaXRjYWxsIGlzYV9idXNf aW5pdCsweDAvMHgzMyByZXR1cm5lZCAwIGFmdGVyIDE0IHVzZWNzDQpbICAgIDIuNjQ5MDEw XSBjYWxsaW5nICB0b3BvbG9neV9zeXNmc19pbml0KzB4MC8weDRjIEAgMQ0KWyAgICAyLjY0 OTAzMl0gaW5pdGNhbGwgdG9wb2xvZ3lfc3lzZnNfaW5pdCsweDAvMHg0YyByZXR1cm5lZCAw IGFmdGVyIDExIHVzZWNzDQpbICAgIDIuNjQ5MDQzXSBjYWxsaW5nICBicmRfaW5pdCsweDAv MHgxOGEgQCAxDQpbICAgIDIuNjQ5Nzk2XSBicmQ6IG1vZHVsZSBsb2FkZWQNClsgICAgMi42 NDk4MDVdIGluaXRjYWxsIGJyZF9pbml0KzB4MC8weDE4YSByZXR1cm5lZCAwIGFmdGVyIDcz NSB1c2Vjcw0KWyAgICAyLjY0OTgxN10gY2FsbGluZyAgbG9vcF9pbml0KzB4MC8weDFhNCBA IDENClsgICAgMi42NTAxOTVdIGxvb3A6IG1vZHVsZSBsb2FkZWQNClsgICAgMi42NTAyMDVd IGluaXRjYWxsIGxvb3BfaW5pdCsweDAvMHgxYTQgcmV0dXJuZWQgMCBhZnRlciAzNjggdXNl Y3MNClsgICAgMi42NTAyMTZdIGNhbGxpbmcgIHBrdF9pbml0KzB4MC8weDFhMiBAIDENClsg ICAgMi42NTAyNjJdIGluaXRjYWxsIHBrdF9pbml0KzB4MC8weDFhMiByZXR1cm5lZCAwIGFm dGVyIDM2IHVzZWNzDQpbICAgIDIuNjUwMjc0XSBjYWxsaW5nICBpbml0KzB4MC8weDc5IEAg MQ0KWyAgICAyLjY1MDI5NF0gaW5pdGNhbGwgaW5pdCsweDAvMHg3OSByZXR1cm5lZCAwIGFm dGVyIDExIHVzZWNzDQpbICAgIDIuNjUwMzA2XSBjYWxsaW5nICBodGNwbGRfY29yZV9pbml0 KzB4MC8weDI0IEAgMQ0KWyAgICAyLjY1MDMzNF0gaW5pdGNhbGwgaHRjcGxkX2NvcmVfaW5p dCsweDAvMHgyNCByZXR1cm5lZCAtMTkgYWZ0ZXIgMTggdXNlY3MNClsgICAgMi42NTAzNDZd IGNhbGxpbmcgIHdtODk5NF9pMmNfaW5pdCsweDAvMHgzMCBAIDENClsgICAgMi42NTAzNjJd IGluaXRjYWxsIHdtODk5NF9pMmNfaW5pdCsweDAvMHgzMCByZXR1cm5lZCAwIGFmdGVyIDUg dXNlY3MNClsgICAgMi42NTAzNzRdIGNhbGxpbmcgIGFkcDU1MjBfaW5pdCsweDAvMHgxMSBA IDENClsgICAgMi42NTAzODldIGluaXRjYWxsIGFkcDU1MjBfaW5pdCsweDAvMHgxMSByZXR1 cm5lZCAwIGFmdGVyIDUgdXNlY3MNClsgICAgMi42NTA0MDFdIGNhbGxpbmcgIG1hY19oaWRf aW5pdCsweDAvMHgxYyBAIDENClsgICAgMi42NTA0MThdIGluaXRjYWxsIG1hY19oaWRfaW5p dCsweDAvMHgxYyByZXR1cm5lZCAwIGFmdGVyIDYgdXNlY3MNClsgICAgMi42NTA0MzBdIGNh bGxpbmcgIHNwaV90cmFuc3BvcnRfaW5pdCsweDAvMHg3NSBAIDENClsgICAgMi42NTA0NTJd IGluaXRjYWxsIHNwaV90cmFuc3BvcnRfaW5pdCsweDAvMHg3NSByZXR1cm5lZCAwIGFmdGVy IDExIHVzZWNzDQpbICAgIDIuNjUwNDY0XSBjYWxsaW5nICBzY3NpX2RoX2luaXQrMHgwLzB4 NGMgQCAxDQpbICAgIDIuNjUwNDc1XSBpbml0Y2FsbCBzY3NpX2RoX2luaXQrMHgwLzB4NGMg cmV0dXJuZWQgMCBhZnRlciAwIHVzZWNzDQpbICAgIDIuNjUwNDg3XSBjYWxsaW5nICBzeW0y X2luaXQrMHgwLzB4ZTQgQCAxDQpbICAgIDIuNjUwNTA4XSBpbml0Y2FsbCBzeW0yX2luaXQr MHgwLzB4ZTQgcmV0dXJuZWQgMCBhZnRlciAxMiB1c2Vjcw0KWyAgICAyLjY1MDUyMF0gY2Fs bGluZyAgaW5pdF9zZCsweDAvMHgxNGIgQCAxDQpbICAgIDIuNjUwNTYxXSBpbml0Y2FsbCBp bml0X3NkKzB4MC8weDE0YiByZXR1cm5lZCAwIGFmdGVyIDMxIHVzZWNzDQpbICAgIDIuNjUw NTczXSBjYWxsaW5nICBpbml0X3NyKzB4MC8weDNkIEAgMQ0KWyAgICAyLjY1MDU4N10gaW5p dGNhbGwgaW5pdF9zcisweDAvMHgzZCByZXR1cm5lZCAwIGFmdGVyIDUgdXNlY3MNClsgICAg Mi42NTA1OTldIGNhbGxpbmcgIGluaXRfc2crMHgwLzB4MTExIEAgMQ0KWyAgICAyLjY1MDYy MV0gaW5pdGNhbGwgaW5pdF9zZysweDAvMHgxMTEgcmV0dXJuZWQgMCBhZnRlciAxMyB1c2Vj cw0KWyAgICAyLjY1MDYzM10gY2FsbGluZyAgYWRtYV9hdGFfaW5pdCsweDAvMHgxNiBAIDEN ClsgICAgMi42NTA2NTRdIGluaXRjYWxsIGFkbWFfYXRhX2luaXQrMHgwLzB4MTYgcmV0dXJu ZWQgMCBhZnRlciAxMCB1c2Vjcw0KWyAgICAyLjY1MDY2Nl0gY2FsbGluZyAgcGlpeF9pbml0 KzB4MC8weDI0IEAgMQ0KWyAgICAyLjY1MDY5MF0gaW5pdGNhbGwgcGlpeF9pbml0KzB4MC8w eDI0IHJldHVybmVkIDAgYWZ0ZXIgMTUgdXNlY3MNClsgICAgMi42NTA3MDJdIGNhbGxpbmcg IHNpc19pbml0KzB4MC8weDE2IEAgMQ0KWyAgICAyLjY1MDcyM10gaW5pdGNhbGwgc2lzX2lu aXQrMHgwLzB4MTYgcmV0dXJuZWQgMCBhZnRlciAxMiB1c2Vjcw0KWyAgICAyLjY1MDczNV0g Y2FsbGluZyAgcGFjcGlfaW5pdCsweDAvMHgxNiBAIDENClsgICAgMi42NTA3ODhdIHBhdGFf YWNwaSAwMDAwOjAwOjA2LjA6IHNldHRpbmcgbGF0ZW5jeSB0aW1lciB0byA2NA0KWyAgICAy LjY1MTAwM10gQUNQSTogUENJIEludGVycnVwdCBMaW5rIFtMU0EwXSBlbmFibGVkIGF0IElS USAyMw0KWyAgICAyLjY1MTAxNl0geGVuOiByZWdpc3RlcmluZyBnc2kgMjMgdHJpZ2dlcmlu ZyAwIHBvbGFyaXR5IDENClsgICAgMi42NTEwMzVdIHhlbjogLS0+IHBpcnE9MjMgLT4gaXJx PTIzIChnc2k9MjMpDQpbICAgIDIuNjUxMDU1XSBwYXRhX2FjcGkgMDAwMDowMDowOC4wOiBQ Q0kgSU5UIEEgLT4gTGlua1tMU0EwXSAtPiBHU0kgMjMgKGxldmVsLCBsb3cpIC0+IElSUSAy Mw0KWyAgICAyLjY1MTA4OV0gcGF0YV9hY3BpIDAwMDA6MDA6MDguMDogc2V0dGluZyBsYXRl bmN5IHRpbWVyIHRvIDY0DQpbICAgIDIuNjUxMTA5XSBwYXRhX2FjcGkgMDAwMDowMDowOC4w OiBQQ0kgSU5UIEEgZGlzYWJsZWQNClsgICAgMi42NTEyODldIEFDUEk6IFBDSSBJbnRlcnJ1 cHQgTGluayBbTFNBMV0gZW5hYmxlZCBhdCBJUlEgMjINClsgICAgMi42NTEzMDFdIHhlbjog cmVnaXN0ZXJpbmcgZ3NpIDIyIHRyaWdnZXJpbmcgMCBwb2xhcml0eSAxDQpbICAgIDIuNjUx MzE1XSB4ZW46IC0tPiBwaXJxPTIyIC0+IGlycT0yMiAoZ3NpPTIyKQ0KWyAgICAyLjY1MTMy OV0gcGF0YV9hY3BpIDAwMDA6MDA6MDguMTogUENJIElOVCBCIC0+IExpbmtbTFNBMV0gLT4g R1NJIDIyIChsZXZlbCwgbG93KSAtPiBJUlEgMjINClsgICAgMi42NTEzNjBdIHBhdGFfYWNw aSAwMDAwOjAwOjA4LjE6IHNldHRpbmcgbGF0ZW5jeSB0aW1lciB0byA2NA0KWyAgICAyLjY1 MTM3OV0gcGF0YV9hY3BpIDAwMDA6MDA6MDguMTogUENJIElOVCBCIGRpc2FibGVkDQpbICAg IDIuNjUxNDAxXSBpbml0Y2FsbCBwYWNwaV9pbml0KzB4MC8weDE2IHJldHVybmVkIDAgYWZ0 ZXIgNjM5IHVzZWNzDQpbICAgIDIuNjUxNDEzXSBjYWxsaW5nICBhdGFfZ2VuZXJpY19pbml0 KzB4MC8weDE2IEAgMQ0KWyAgICAyLjY1MTQ0NV0gaW5pdGNhbGwgYXRhX2dlbmVyaWNfaW5p dCsweDAvMHgxNiByZXR1cm5lZCAwIGFmdGVyIDIxIHVzZWNzDQpbICAgIDIuNjUxNDU3XSBj YWxsaW5nICBtYXJ2ZWxsX2luaXQrMHgwLzB4NGMgQCAxDQpbICAgIDIuNjUxNTA0XSBpbml0 Y2FsbCBtYXJ2ZWxsX2luaXQrMHgwLzB4NGMgcmV0dXJuZWQgMCBhZnRlciAzNiB1c2Vjcw0K WyAgICAyLjY1MTUxNl0gY2FsbGluZyAgZGF2aWNvbV9pbml0KzB4MC8weDRkIEAgMQ0KWyAg ICAyLjY1MTUzOV0gaW5pdGNhbGwgZGF2aWNvbV9pbml0KzB4MC8weDRkIHJldHVybmVkIDAg YWZ0ZXIgMTIgdXNlY3MNClsgICAgMi42NTE1NTFdIGNhbGxpbmcgIGNpY2FkYV9pbml0KzB4 MC8weDMzIEAgMQ0KWyAgICAyLjY1MTU3MF0gaW5pdGNhbGwgY2ljYWRhX2luaXQrMHgwLzB4 MzMgcmV0dXJuZWQgMCBhZnRlciA4IHVzZWNzDQpbICAgIDIuNjUxNTgyXSBjYWxsaW5nICBs eHRfaW5pdCsweDAvMHg0ZCBAIDENClsgICAgMi42NTE2MDVdIGluaXRjYWxsIGx4dF9pbml0 KzB4MC8weDRkIHJldHVybmVkIDAgYWZ0ZXIgMTMgdXNlY3MNClsgICAgMi42NTE2MTZdIGNh bGxpbmcgIHFzNjYxMl9pbml0KzB4MC8weGYgQCAxDQpbICAgIDIuNjUxNjMyXSBpbml0Y2Fs bCBxczY2MTJfaW5pdCsweDAvMHhmIHJldHVybmVkIDAgYWZ0ZXIgNSB1c2Vjcw0KWyAgICAy LjY1MTY0NF0gY2FsbGluZyAgc21zY19pbml0KzB4MC8weDgxIEAgMQ0KWyAgICAyLjY1MTY3 NF0gaW5pdGNhbGwgc21zY19pbml0KzB4MC8weDgxIHJldHVybmVkIDAgYWZ0ZXIgMjAgdXNl Y3MNClsgICAgMi42NTE2ODZdIGNhbGxpbmcgIHZzYzgyeHhfaW5pdCsweDAvMHgzMyBAIDEN ClsgICAgMi42NTE3MDVdIGluaXRjYWxsIHZzYzgyeHhfaW5pdCsweDAvMHgzMyByZXR1cm5l ZCAwIGFmdGVyIDkgdXNlY3MNClsgICAgMi42NTE3MTddIGNhbGxpbmcgIGJyb2FkY29tX2lu aXQrMHgwLzB4MTM1IEAgMQ0KWyAgICAyLjY1MTc3OF0gaW5pdGNhbGwgYnJvYWRjb21faW5p dCsweDAvMHgxMzUgcmV0dXJuZWQgMCBhZnRlciA0OSB1c2Vjcw0KWyAgICAyLjY1MTc5MF0g Y2FsbGluZyAgaWNwbHVzX2luaXQrMHgwLzB4MjQgQCAxDQpbICAgIDIuNjUxODExXSBpbml0 Y2FsbCBpY3BsdXNfaW5pdCsweDAvMHgyNCByZXR1cm5lZCAwIGFmdGVyIDEwIHVzZWNzDQpb ICAgIDIuNjUxODIzXSBjYWxsaW5nICByZWFsdGVrX2luaXQrMHgwLzB4ZiBAIDENClsgICAg Mi42NTE4MzldIGluaXRjYWxsIHJlYWx0ZWtfaW5pdCsweDAvMHhmIHJldHVybmVkIDAgYWZ0 ZXIgNSB1c2Vjcw0KWyAgICAyLjY1MTg1MF0gY2FsbGluZyAgZXQxMDExY19pbml0KzB4MC8w eGYgQCAxDQpbICAgIDIuNjUxODY2XSBpbml0Y2FsbCBldDEwMTFjX2luaXQrMHgwLzB4ZiBy ZXR1cm5lZCAwIGFmdGVyIDUgdXNlY3MNClsgICAgMi42NTE4NzhdIGNhbGxpbmcgIGZpeGVk X21kaW9fYnVzX2luaXQrMHgwLzB4ZjMgQCAxDQpbICAgIDIuNjUxOTEyXSBGaXhlZCBNRElP IEJ1czogcHJvYmVkDQpbICAgIDIuNjUxOTIxXSBpbml0Y2FsbCBmaXhlZF9tZGlvX2J1c19p bml0KzB4MC8weGYzIHJldHVybmVkIDAgYWZ0ZXIgMzIgdXNlY3MNClsgICAgMi42NTE5MzNd IGNhbGxpbmcgIG1kaW9fZ3Bpb19pbml0KzB4MC8weGYgQCAxDQpbICAgIDIuNjUxOTQ5XSBp bml0Y2FsbCBtZGlvX2dwaW9faW5pdCsweDAvMHhmIHJldHVybmVkIDAgYWZ0ZXIgNiB1c2Vj cw0KWyAgICAyLjY1MTk2MV0gY2FsbGluZyAgbnNfaW5pdCsweDAvMHhmIEAgMQ0KWyAgICAy LjY1MTk3NV0gaW5pdGNhbGwgbnNfaW5pdCsweDAvMHhmIHJldHVybmVkIDAgYWZ0ZXIgNSB1 c2Vjcw0KWyAgICAyLjY1MTk4N10gY2FsbGluZyAgc3RlMTBYcF9pbml0KzB4MC8weDFkIEAg MQ0KWyAgICAyLjY1MjAwNl0gaW5pdGNhbGwgc3RlMTBYcF9pbml0KzB4MC8weDFkIHJldHVy bmVkIDAgYWZ0ZXIgOSB1c2Vjcw0KWyAgICAyLjY1MjAxOF0gY2FsbGluZyAgbmV0X29sZGRl dnNfaW5pdCsweDAvMHg4NCBAIDENClsgICAgMi42NTIwMzJdIGluaXRjYWxsIG5ldF9vbGRk ZXZzX2luaXQrMHgwLzB4ODQgcmV0dXJuZWQgMCBhZnRlciAzIHVzZWNzDQpbICAgIDIuNjUy MDQ0XSBjYWxsaW5nICBwcHBfaW5pdCsweDAvMHhlNSBAIDENClsgICAgMi42NTIwNTJdIFBQ UCBnZW5lcmljIGRyaXZlciB2ZXJzaW9uIDIuNC4yDQpbICAgIDIuNjUyMTA2XSBpbml0Y2Fs bCBwcHBfaW5pdCsweDAvMHhlNSByZXR1cm5lZCAwIGFmdGVyIDUxIHVzZWNzDQpbICAgIDIu NjUyMTE4XSBjYWxsaW5nICBuZXRpZl9pbml0KzB4MC8weDVmIEAgMQ0KWyAgICAyLjY1MjEy OV0gaW5pdGNhbGwgbmV0aWZfaW5pdCsweDAvMHg1ZiByZXR1cm5lZCAwIGFmdGVyIDAgdXNl Y3MNClsgICAgMi42NTIxNDFdIGNhbGxpbmcgIG5ldGJhY2tfaW5pdCsweDAvMHgxZmEgQCAx DQpbICAgIDIuNjUyMzc4XSBpbml0Y2FsbCBuZXRiYWNrX2luaXQrMHgwLzB4MWZhIHJldHVy bmVkIDAgYWZ0ZXIgMjIwIHVzZWNzDQpbICAgIDIuNjUyMzkxXSBjYWxsaW5nICB0dW5faW5p dCsweDAvMHg4YiBAIDENClsgICAgMi42NTIzOTldIHR1bjogVW5pdmVyc2FsIFRVTi9UQVAg ZGV2aWNlIGRyaXZlciwgMS42DQpbICAgIDIuNjUyNDA5XSB0dW46IChDKSAxOTk5LTIwMDQg TWF4IEtyYXNueWFuc2t5IDxtYXhrQHF1YWxjb21tLmNvbT4NClsgICAgMi42NTI0NDVdIGlu aXRjYWxsIHR1bl9pbml0KzB4MC8weDhiIHJldHVybmVkIDAgYWZ0ZXIgNDMgdXNlY3MNClsg ICAgMi42NTI0NTddIGNhbGxpbmcgIGluaXQrMHgwLzB4ZiBAIDENClsgICAgMi42NTI0NzFd IGluaXRjYWxsIGluaXQrMHgwLzB4ZiByZXR1cm5lZCAwIGFmdGVyIDUgdXNlY3MNClsgICAg Mi42NTI0ODJdIGNhbGxpbmcgIGNkcm9tX2luaXQrMHgwLzB4YyBAIDENClsgICAgMi42NTI1 MDJdIGluaXRjYWxsIGNkcm9tX2luaXQrMHgwLzB4YyByZXR1cm5lZCAwIGFmdGVyIDExIHVz ZWNzDQpbICAgIDIuNjUyNTE0XSBjYWxsaW5nICBtb25faW5pdCsweDAvMHhlMiBAIDENClsg ICAgMi42NTI1NTBdIGluaXRjYWxsIG1vbl9pbml0KzB4MC8weGUyIHJldHVybmVkIDAgYWZ0 ZXIgMjYgdXNlY3MNClsgICAgMi42NTI1NjNdIGNhbGxpbmcgIGVoY2lfaGNkX2luaXQrMHgw LzB4NmYgQCAxDQpbICAgIDIuNjUyNTczXSBlaGNpX2hjZDogVVNCIDIuMCAnRW5oYW5jZWQn IEhvc3QgQ29udHJvbGxlciAoRUhDSSkgRHJpdmVyDQpbICAgIDIuNjUyNzU4XSBBQ1BJOiBQ Q0kgSW50ZXJydXB0IExpbmsgW0xVQjJdIGVuYWJsZWQgYXQgSVJRIDIxDQpbICAgIDIuNjUy NzcwXSB4ZW46IHJlZ2lzdGVyaW5nIGdzaSAyMSB0cmlnZ2VyaW5nIDAgcG9sYXJpdHkgMQ0K WyAgICAyLjY1Mjc4NF0geGVuOiAtLT4gcGlycT0yMSAtPiBpcnE9MjEgKGdzaT0yMSkNClsg ICAgMi42NTI3OTldIGVoY2lfaGNkIDAwMDA6MDA6MDIuMTogUENJIElOVCBCIC0+IExpbmtb TFVCMl0gLT4gR1NJIDIxIChsZXZlbCwgbG93KSAtPiBJUlEgMjENClsgICAgMi42NTI4MjVd IGVoY2lfaGNkIDAwMDA6MDA6MDIuMTogc2V0dGluZyBsYXRlbmN5IHRpbWVyIHRvIDY0DQpb ICAgIDIuNjUyODM4XSBlaGNpX2hjZCAwMDAwOjAwOjAyLjE6IEVIQ0kgSG9zdCBDb250cm9s bGVyDQpbICAgIDIuNjUyODcxXSBlaGNpX2hjZCAwMDAwOjAwOjAyLjE6IG5ldyBVU0IgYnVz IHJlZ2lzdGVyZWQsIGFzc2lnbmVkIGJ1cyBudW1iZXIgMQ0KWyAgICAyLjY1MjkzM10gZWhj aV9oY2QgMDAwMDowMDowMi4xOiBkZWJ1ZyBwb3J0IDENClsgICAgMi42NTI5NTJdIGVoY2lf aGNkIDAwMDA6MDA6MDIuMTogY2FjaGUgbGluZSBzaXplIG9mIDY0IGlzIG5vdCBzdXBwb3J0 ZWQNClsgICAgMi42NTI5OTFdIGVoY2lfaGNkIDAwMDA6MDA6MDIuMTogaXJxIDIxLCBpbyBt ZW0gMHhkZmZmYWMwMA0KWyAgICAyLjY2NDExNl0gZWhjaV9oY2QgMDAwMDowMDowMi4xOiBV U0IgMi4wIHN0YXJ0ZWQsIEVIQ0kgMS4wMA0KWyAgICAyLjY2NDMwMF0gaHViIDEtMDoxLjA6 IFVTQiBodWIgZm91bmQNClsgICAgMi42NjQzMTJdIGh1YiAxLTA6MS4wOiAxMCBwb3J0cyBk ZXRlY3RlZA0KWyAgICAyLjY2NDM5Ml0gaW5pdGNhbGwgZWhjaV9oY2RfaW5pdCsweDAvMHg2 ZiByZXR1cm5lZCAwIGFmdGVyIDExNTM4IHVzZWNzDQpbICAgIDIuNjY0NDA1XSBjYWxsaW5n ICBvaGNpX2hjZF9tb2RfaW5pdCsweDAvMHg1MSBAIDENClsgICAgMi42NjQ0MTVdIG9oY2lf aGNkOiBVU0IgMS4xICdPcGVuJyBIb3N0IENvbnRyb2xsZXIgKE9IQ0kpIERyaXZlcg0KWyAg ICAyLjY2NDY0Ml0gQUNQSTogUENJIEludGVycnVwdCBMaW5rIFtMVUIwXSBlbmFibGVkIGF0 IElSUSAyMA0KWyAgICAyLjY2NDY1NF0geGVuOiByZWdpc3RlcmluZyBnc2kgMjAgdHJpZ2dl cmluZyAwIHBvbGFyaXR5IDENClsgICAgMi42NjQ2NzVdIHhlbjogLS0+IHBpcnE9MjAgLT4g aXJxPTIwIChnc2k9MjApDQpbICAgIDIuNjY0Njk0XSBvaGNpX2hjZCAwMDAwOjAwOjAyLjA6 IFBDSSBJTlQgQSAtPiBMaW5rW0xVQjBdIC0+IEdTSSAyMCAobGV2ZWwsIGxvdykgLT4gSVJR IDIwDQpbICAgIDIuNjY0NzMwXSBvaGNpX2hjZCAwMDAwOjAwOjAyLjA6IHNldHRpbmcgbGF0 ZW5jeSB0aW1lciB0byA2NA0KWyAgICAyLjY2NDc0NF0gb2hjaV9oY2QgMDAwMDowMDowMi4w OiBPSENJIEhvc3QgQ29udHJvbGxlcg0KWyAgICAyLjY2NDc4M10gb2hjaV9oY2QgMDAwMDow MDowMi4wOiBuZXcgVVNCIGJ1cyByZWdpc3RlcmVkLCBhc3NpZ25lZCBidXMgbnVtYmVyIDIN ClsgICAgMi42NjQ4NTJdIG9oY2lfaGNkIDAwMDA6MDA6MDIuMDogaXJxIDIwLCBpbyBtZW0g MHhkZmZmYjAwMA0KWyAgICAyLjcyMjI0Nl0gaHViIDItMDoxLjA6IFVTQiBodWIgZm91bmQN ClsgICAgMi43MjIyNjZdIGh1YiAyLTA6MS4wOiAxMCBwb3J0cyBkZXRlY3RlZA0KWyAgICAy LjcyMjM1Ml0gaW5pdGNhbGwgb2hjaV9oY2RfbW9kX2luaXQrMHgwLzB4NTEgcmV0dXJuZWQg MCBhZnRlciA1NjU3NSB1c2Vjcw0KWyAgICAyLjcyMjM2Nl0gY2FsbGluZyAgdWhjaV9oY2Rf aW5pdCsweDAvMHhiOCBAIDENClsgICAgMi43MjIzNzddIHVoY2lfaGNkOiBVU0IgVW5pdmVy c2FsIEhvc3QgQ29udHJvbGxlciBJbnRlcmZhY2UgZHJpdmVyDQpbICAgIDIuNzIyNDMxXSBp bml0Y2FsbCB1aGNpX2hjZF9pbml0KzB4MC8weGI4IHJldHVybmVkIDAgYWZ0ZXIgNTMgdXNl Y3MNClsgICAgMi43MjI0NDRdIGNhbGxpbmcgIGk4MDQyX2luaXQrMHgwLzB4MzllIEAgMQ0K WyAgICAyLjcyMjQ4OV0gaTgwNDI6IFBOUDogUFMvMiBDb250cm9sbGVyIFtQTlAwMzAzOlBT MktdIGF0IDB4NjAsMHg2NCBpcnEgMQ0KWyAgICAyLjcyMjUwMV0gaTgwNDI6IFBOUDogUFMv MiBhcHBlYXJzIHRvIGhhdmUgQVVYIHBvcnQgZGlzYWJsZWQsIGlmIHRoaXMgaXMgaW5jb3Jy ZWN0IHBsZWFzZSBib290IHdpdGggaTgwNDIubm9wbnANClsgICAgMi43MjI2ODldIHNlcmlv OiBpODA0MiBLQkQgcG9ydCBhdCAweDYwLDB4NjQgaXJxIDENClsgICAgMi43MjI3MzRdIGlu aXRjYWxsIGk4MDQyX2luaXQrMHgwLzB4MzllIHJldHVybmVkIDAgYWZ0ZXIgMjc0IHVzZWNz DQpbICAgIDIuNzIyNzQ3XSBjYWxsaW5nICBtb3VzZWRldl9pbml0KzB4MC8weDdmIEAgMQ0K WyAgICAyLjcyMjc5OV0gbW91c2VkZXY6IFBTLzIgbW91c2UgZGV2aWNlIGNvbW1vbiBmb3Ig YWxsIG1pY2UNClsgICAgMi43MjI4MTFdIGluaXRjYWxsIG1vdXNlZGV2X2luaXQrMHgwLzB4 N2YgcmV0dXJuZWQgMCBhZnRlciA1MiB1c2Vjcw0KWyAgICAyLjcyMjgyM10gY2FsbGluZyAg ZXZkZXZfaW5pdCsweDAvMHhmIEAgMQ0KWyAgICAyLjcyMjg2M10gaW5pdGNhbGwgZXZkZXZf aW5pdCsweDAvMHhmIHJldHVybmVkIDAgYWZ0ZXIgMzAgdXNlY3MNClsgICAgMi43MjI4NzVd IGNhbGxpbmcgIGF0a2JkX2luaXQrMHgwLzB4MjAgQCAxDQpbICAgIDIuNzIyODk5XSBpbml0 Y2FsbCBhdGtiZF9pbml0KzB4MC8weDIwIHJldHVybmVkIDAgYWZ0ZXIgMTMgdXNlY3MNClsg ICAgMi43MjI5MTFdIGNhbGxpbmcgIHVpbnB1dF9pbml0KzB4MC8weGYgQCAxDQpbICAgIDIu NzIyOTUyXSBpbml0Y2FsbCB1aW5wdXRfaW5pdCsweDAvMHhmIHJldHVybmVkIDAgYWZ0ZXIg MzAgdXNlY3MNClsgICAgMi43MjI5NjVdIGNhbGxpbmcgIGNtb3NfaW5pdCsweDAvMHg1ZSBA IDENClsgICAgMi43MjMwMDBdIHJ0Y19jbW9zIDAwOjAyOiBSVEMgY2FuIHdha2UgZnJvbSBT NA0KWyAgICAyLjcyMzE0OF0gcnRjX2Ntb3MgMDA6MDI6IHJ0YyBjb3JlOiByZWdpc3RlcmVk IHJ0Y19jbW9zIGFzIHJ0YzANClsgICAgMi43MjMyMDFdIHJ0YzA6IGFsYXJtcyB1cCB0byBv bmUgeWVhciwgeTNrLCAxMTQgYnl0ZXMgbnZyYW0NClsgICAgMi43MjMyMjNdIGluaXRjYWxs IGNtb3NfaW5pdCsweDAvMHg1ZSByZXR1cm5lZCAwIGFmdGVyIDI0MyB1c2Vjcw0KWyAgICAy LjcyMzIzNV0gY2FsbGluZyAgZG1faW5pdCsweDAvMHgzZiBAIDENClsgICAgMi43MjMyODld IGRldmljZS1tYXBwZXI6IHVldmVudDogdmVyc2lvbiAxLjAuMw0KWyAgICAyLjcyMzM0OF0g ZGV2aWNlLW1hcHBlcjogaW9jdGw6IDQuMjAuMC1pb2N0bCAoMjAxMS0wMi0wMikgaW5pdGlh bGlzZWQ6IGRtLWRldmVsQHJlZGhhdC5jb20NClsgICAgMi43MjMzNjRdIGluaXRjYWxsIGRt X2luaXQrMHgwLzB4M2YgcmV0dXJuZWQgMCBhZnRlciAxMTcgdXNlY3MNClsgICAgMi43MjMz NzZdIGNhbGxpbmcgIGRtX211bHRpcGF0aF9pbml0KzB4MC8weDEzMyBAIDENClsgICAgMi43 MjM1MThdIGRldmljZS1tYXBwZXI6IG11bHRpcGF0aDogdmVyc2lvbiAxLjMuMCBsb2FkZWQN ClsgICAgMi43MjM1MzFdIGluaXRjYWxsIGRtX211bHRpcGF0aF9pbml0KzB4MC8weDEzMyBy ZXR1cm5lZCAwIGFmdGVyIDE0MCB1c2Vjcw0KWyAgICAyLjcyMzU0M10gY2FsbGluZyAgZG1f cnJfaW5pdCsweDAvMHgzYSBAIDENClsgICAgMi43MjM1NTNdIGRldmljZS1tYXBwZXI6IG11 bHRpcGF0aCByb3VuZC1yb2JpbjogdmVyc2lvbiAxLjAuMCBsb2FkZWQNClsgICAgMi43MjM1 NjVdIGluaXRjYWxsIGRtX3JyX2luaXQrMHgwLzB4M2EgcmV0dXJuZWQgMCBhZnRlciAxMSB1 c2Vjcw0KWyAgICAyLjcyMzU3N10gY2FsbGluZyAgZG1fc25hcHNob3RfaW5pdCsweDAvMHgx ZmQgQCAxDQpbICAgIDIuNzIzNjA1XSBpbml0Y2FsbCBkbV9zbmFwc2hvdF9pbml0KzB4MC8w eDFmZCByZXR1cm5lZCAwIGFmdGVyIDE2IHVzZWNzDQpbICAgIDIuNzIzNjE3XSBjYWxsaW5n ICBkbV9taXJyb3JfaW5pdCsweDAvMHg3NyBAIDENClsgICAgMi43MjM2NTRdIGluaXRjYWxs IGRtX21pcnJvcl9pbml0KzB4MC8weDc3IHJldHVybmVkIDAgYWZ0ZXIgMjUgdXNlY3MNClsg ICAgMi43MjM2NjZdIGNhbGxpbmcgIGRtX2RpcnR5X2xvZ19pbml0KzB4MC8weDRkIEAgMQ0K WyAgICAyLjcyMzY3N10gaW5pdGNhbGwgZG1fZGlydHlfbG9nX2luaXQrMHgwLzB4NGQgcmV0 dXJuZWQgMCBhZnRlciAwIHVzZWNzDQpbICAgIDIuNzIzNjg5XSBjYWxsaW5nICBwY2lfZWlz YV9pbml0X21vZHVsZSsweDAvMHgxNiBAIDENClsgICAgMi43MjM3MTBdIGluaXRjYWxsIHBj aV9laXNhX2luaXRfbW9kdWxlKzB4MC8weDE2IHJldHVybmVkIDAgYWZ0ZXIgOSB1c2Vjcw0K WyAgICAyLjcyMzcyMl0gY2FsbGluZyAgdmlydHVhbF9laXNhX3Jvb3RfaW5pdCsweDAvMHg0 ZCBAIDENClsgICAgMi43MjM3NDRdIEVJU0E6IFByb2JpbmcgYnVzIDAgYXQgZWlzYS4wDQpb ICAgIDIuNzIzNzUyXSBFSVNBOiBDYW5ub3QgYWxsb2NhdGUgcmVzb3VyY2UgZm9yIG1haW5i b2FyZA0KWyAgICAyLjcyMzc2Ml0gQ2Fubm90IGFsbG9jYXRlIHJlc291cmNlIGZvciBFSVNB IHNsb3QgMQ0KWyAgICAyLjcyMzc3MV0gQ2Fubm90IGFsbG9jYXRlIHJlc291cmNlIGZvciBF SVNBIHNsb3QgMg0KWyAgICAyLjcyMzc4MV0gQ2Fubm90IGFsbG9jYXRlIHJlc291cmNlIGZv ciBFSVNBIHNsb3QgMw0KWyAgICAyLjcyMzc5MF0gQ2Fubm90IGFsbG9jYXRlIHJlc291cmNl IGZvciBFSVNBIHNsb3QgNA0KWyAgICAyLjcyMzgwMF0gQ2Fubm90IGFsbG9jYXRlIHJlc291 cmNlIGZvciBFSVNBIHNsb3QgNQ0KWyAgICAyLjcyMzgwOV0gQ2Fubm90IGFsbG9jYXRlIHJl c291cmNlIGZvciBFSVNBIHNsb3QgNg0KWyAgICAyLjcyMzgxOV0gQ2Fubm90IGFsbG9jYXRl IHJlc291cmNlIGZvciBFSVNBIHNsb3QgNw0KWyAgICAyLjcyMzgyOF0gQ2Fubm90IGFsbG9j YXRlIHJlc291cmNlIGZvciBFSVNBIHNsb3QgOA0KWyAgICAyLjcyMzgzN10gRUlTQTogRGV0 ZWN0ZWQgMCBjYXJkcy4NClsgICAgMi43MjM4NDZdIGluaXRjYWxsIHZpcnR1YWxfZWlzYV9y b290X2luaXQrMHgwLzB4NGQgcmV0dXJuZWQgMCBhZnRlciAxMTAgdXNlY3MNClsgICAgMi43 MjM4NjBdIGNhbGxpbmcgIGNwdWZyZXFfc3RhdHNfaW5pdCsweDAvMHg4NCBAIDENClsgICAg Mi43MjM4NzNdIGluaXRjYWxsIGNwdWZyZXFfc3RhdHNfaW5pdCsweDAvMHg4NCByZXR1cm5l ZCAwIGFmdGVyIDIgdXNlY3MNClsgICAgMi43MjM4ODVdIGNhbGxpbmcgIGNwdWZyZXFfZ292 X3Bvd2Vyc2F2ZV9pbml0KzB4MC8weGYgQCAxDQpbICAgIDIuNzIzODk2XSBpbml0Y2FsbCBj cHVmcmVxX2dvdl9wb3dlcnNhdmVfaW5pdCsweDAvMHhmIHJldHVybmVkIDAgYWZ0ZXIgMCB1 c2Vjcw0KWyAgICAyLjcyMzkxMF0gY2FsbGluZyAgY3B1ZnJlcV9nb3ZfdXNlcnNwYWNlX2lu aXQrMHgwLzB4ZiBAIDENClsgICAgMi43MjM5MjFdIGluaXRjYWxsIGNwdWZyZXFfZ292X3Vz ZXJzcGFjZV9pbml0KzB4MC8weGYgcmV0dXJuZWQgMCBhZnRlciAwIHVzZWNzDQpbICAgIDIu NzIzOTM0XSBjYWxsaW5nICBjcHVmcmVxX2dvdl9kYnNfaW5pdCsweDAvMHg1YiBAIDENClsg ICAgMi43MjM5NDZdIGluaXRjYWxsIGNwdWZyZXFfZ292X2Ric19pbml0KzB4MC8weDViIHJl dHVybmVkIDAgYWZ0ZXIgMCB1c2Vjcw0KWyAgICAyLjcyMzk1OF0gY2FsbGluZyAgY3B1ZnJl cV9nb3ZfZGJzX2luaXQrMHgwLzB4ZiBAIDENClsgICAgMi43MjM5NjldIGluaXRjYWxsIGNw dWZyZXFfZ292X2Ric19pbml0KzB4MC8weGYgcmV0dXJuZWQgMCBhZnRlciAwIHVzZWNzDQpb ICAgIDIuNzIzOTgxXSBjYWxsaW5nICBwb3dlcm5vd19rNl9pbml0KzB4MC8weGIxIEAgMQ0K WyAgICAyLjcyMzk5MV0gaW5pdGNhbGwgcG93ZXJub3dfazZfaW5pdCsweDAvMHhiMSByZXR1 cm5lZCAtMTkgYWZ0ZXIgMCB1c2Vjcw0KWyAgICAyLjcyNDAwM10gY2FsbGluZyAgbG9uZ3J1 bl9pbml0KzB4MC8weDJlIEAgMQ0KWyAgICAyLjcyNDAxNF0gaW5pdGNhbGwgbG9uZ3J1bl9p bml0KzB4MC8weDJlIHJldHVybmVkIC0xOSBhZnRlciAwIHVzZWNzDQpbICAgIDIuNzI0MDI2 XSBjYWxsaW5nICBjcHVmcmVxX2d4X2luaXQrMHgwLzB4MTBhIEAgMQ0KWyAgICAyLjcyNDAz Nl0gaW5pdGNhbGwgY3B1ZnJlcV9neF9pbml0KzB4MC8weDEwYSByZXR1cm5lZCAtMTkgYWZ0 ZXIgMCB1c2Vjcw0KWyAgICAyLjcyNDA0OF0gY2FsbGluZyAgc3BlZWRzdGVwX2luaXQrMHgw LzB4MWE4IEAgMQ0KWyAgICAyLjcyNDA2NF0gaW5pdGNhbGwgc3BlZWRzdGVwX2luaXQrMHgw LzB4MWE4IHJldHVybmVkIC0xOSBhZnRlciAwIHVzZWNzDQpbICAgIDIuNzI0MDc2XSBjYWxs aW5nICBzcGVlZHN0ZXBfaW5pdCsweDAvMHhiMCBAIDENClsgICAgMi43MjQwODddIGluaXRj YWxsIHNwZWVkc3RlcF9pbml0KzB4MC8weGIwIHJldHVybmVkIC0xOSBhZnRlciAwIHVzZWNz DQpbICAgIDIuNzI0MTAwXSBjYWxsaW5nICBuZm9yY2UyX2luaXQrMHgwLzB4NmYgQCAxDQpb ICAgIDIuNzI0MTExXSBjcHVmcmVxLW5mb3JjZTI6IE5vIG5Gb3JjZTIgY2hpcHNldC4NClsg ICAgMi43MjQxMjJdIGluaXRjYWxsIG5mb3JjZTJfaW5pdCsweDAvMHg2ZiByZXR1cm5lZCAt MTkgYWZ0ZXIgMTEgdXNlY3MNClsgICAgMi43MjQxMzNdIGNhbGxpbmcgIGluaXRfbGFkZGVy KzB4MC8weGYgQCAxDQpbICAgIDIuNzI0MTQzXSBjcHVpZGxlOiB1c2luZyBnb3Zlcm5vciBs YWRkZXINClsgICAgMi43MjQxNTJdIGluaXRjYWxsIGluaXRfbGFkZGVyKzB4MC8weGYgcmV0 dXJuZWQgMCBhZnRlciA4IHVzZWNzDQpbICAgIDIuNzI0MTYzXSBjYWxsaW5nICBpbml0X21l bnUrMHgwLzB4ZiBAIDENClsgICAgMi43MjQxNzFdIGNwdWlkbGU6IHVzaW5nIGdvdmVybm9y IG1lbnUNClsgICAgMi43MjQxODBdIGluaXRjYWxsIGluaXRfbWVudSsweDAvMHhmIHJldHVy bmVkIDAgYWZ0ZXIgNyB1c2Vjcw0KWyAgICAyLjcyNDE5Ml0gY2FsbGluZyAgZWZpdmFyc19p bml0KzB4MC8weGRhIEAgMQ0KWyAgICAyLjcyNDIwMV0gRUZJIFZhcmlhYmxlcyBGYWNpbGl0 eSB2MC4wOCAyMDA0LU1heS0xNw0KWyAgICAyLjcyNDIxMl0gaW5pdGNhbGwgZWZpdmFyc19p bml0KzB4MC8weGRhIHJldHVybmVkIDAgYWZ0ZXIgOSB1c2Vjcw0KWyAgICAyLjcyNDIyM10g Y2FsbGluZyAgZmxvd19jYWNoZV9pbml0X2dsb2JhbCsweDAvMHgxMGQgQCAxDQpbICAgIDIu NzI0MjQ1XSBpbml0Y2FsbCBmbG93X2NhY2hlX2luaXRfZ2xvYmFsKzB4MC8weDEwZCByZXR1 cm5lZCAwIGFmdGVyIDEwIHVzZWNzDQpbICAgIDIuNzI0MjU4XSBjYWxsaW5nICBsbGNfaW5p dCsweDAvMHgxYiBAIDENClsgICAgMi43MjQyNjddIGluaXRjYWxsIGxsY19pbml0KzB4MC8w eDFiIHJldHVybmVkIDAgYWZ0ZXIgMCB1c2Vjcw0KWyAgICAyLjcyNDI3OF0gY2FsbGluZyAg c25hcF9pbml0KzB4MC8weDM1IEAgMQ0KWyAgICAyLjcyNDI4N10gaW5pdGNhbGwgc25hcF9p bml0KzB4MC8weDM1IHJldHVybmVkIDAgYWZ0ZXIgMSB1c2Vjcw0KWyAgICAyLjcyNDI5OV0g Y2FsbGluZyAgcmlmX2luaXQrMHgwLzB4NzAgQCAxDQpbICAgIDIuNzI0MzIwXSBpbml0Y2Fs bCByaWZfaW5pdCsweDAvMHg3MCByZXR1cm5lZCAwIGFmdGVyIDEzIHVzZWNzDQpbICAgIDIu NzI0MzMyXSBjYWxsaW5nICBibGFja2hvbGVfbW9kdWxlX2luaXQrMHgwLzB4ZiBAIDENClsg ICAgMi43MjQzNDNdIGluaXRjYWxsIGJsYWNraG9sZV9tb2R1bGVfaW5pdCsweDAvMHhmIHJl dHVybmVkIDAgYWZ0ZXIgMCB1c2Vjcw0KWyAgICAyLjcyNDM1NV0gY2FsbGluZyAgaW5pdF9j Z3JvdXBfY2xzKzB4MC8weDMzIEAgMQ0KWyAgICAyLjcyNDM2Nl0gaW5pdGNhbGwgaW5pdF9j Z3JvdXBfY2xzKzB4MC8weDMzIHJldHVybmVkIDAgYWZ0ZXIgMCB1c2Vjcw0KWyAgICAyLjcy NDM3OF0gY2FsbGluZyAgc3lzY3RsX2lwdjRfaW5pdCsweDAvMHg3MSBAIDENClsgICAgMi43 MjQ1NDJdIGluaXRjYWxsIHN5c2N0bF9pcHY0X2luaXQrMHgwLzB4NzEgcmV0dXJuZWQgMCBh ZnRlciAxNTAgdXNlY3MNClsgICAgMi43MjQ1NTRdIGNhbGxpbmcgIGluaXRfc3luY29va2ll cysweDAvMHgxNiBAIDENClsgICAgMi43MjQ1ODZdIGluaXRjYWxsIGluaXRfc3luY29va2ll cysweDAvMHgxNiByZXR1cm5lZCAwIGFmdGVyIDIxIHVzZWNzDQpbICAgIDIuNzI0NTk5XSBj YWxsaW5nICBpcHY0X25ldGZpbHRlcl9pbml0KzB4MC8weDIwIEAgMQ0KWyAgICAyLjcyNDYx MF0gaW5pdGNhbGwgaXB2NF9uZXRmaWx0ZXJfaW5pdCsweDAvMHgyMCByZXR1cm5lZCAwIGFm dGVyIDAgdXNlY3MNClsgICAgMi43MjQ2MjFdIGNhbGxpbmcgIGluZXRfZGlhZ19pbml0KzB4 MC8weDc5IEAgMQ0KWyAgICAyLjcyNDY0NF0gaW5pdGNhbGwgaW5ldF9kaWFnX2luaXQrMHgw LzB4NzkgcmV0dXJuZWQgMCBhZnRlciAxMSB1c2Vjcw0KWyAgICAyLjcyNDY1Nl0gY2FsbGlu ZyAgdGNwX2RpYWdfaW5pdCsweDAvMHhmIEAgMQ0KWyAgICAyLjcyNDY2N10gaW5pdGNhbGwg dGNwX2RpYWdfaW5pdCsweDAvMHhmIHJldHVybmVkIDAgYWZ0ZXIgMCB1c2Vjcw0KWyAgICAy LjcyNDY3OF0gY2FsbGluZyAgY3ViaWN0Y3BfcmVnaXN0ZXIrMHgwLzB4ODIgQCAxDQpbICAg IDIuNzI0Njg5XSBUQ1AgY3ViaWMgcmVnaXN0ZXJlZA0KWyAgICAyLjcyNDY5N10gaW5pdGNh bGwgY3ViaWN0Y3BfcmVnaXN0ZXIrMHgwLzB4ODIgcmV0dXJuZWQgMCBhZnRlciA4IHVzZWNz DQpbICAgIDIuNzI0NzA5XSBjYWxsaW5nICBpbmV0Nl9pbml0KzB4MC8weDI4NyBAIDENClsg ICAgMi43MjQ4MTBdIE5FVDogUmVnaXN0ZXJlZCBwcm90b2NvbCBmYW1pbHkgMTANClsgICAg Mi43MjUyODNdIGluaXRjYWxsIGluZXQ2X2luaXQrMHgwLzB4Mjg3IHJldHVybmVkIDAgYWZ0 ZXIgNTUwIHVzZWNzDQpbICAgIDIuNzI1Mjk3XSBjYWxsaW5nICBwYWNrZXRfaW5pdCsweDAv MHgzOSBAIDENClsgICAgMi43MjUzMDldIE5FVDogUmVnaXN0ZXJlZCBwcm90b2NvbCBmYW1p bHkgMTcNClsgICAgMi43MjUzMjJdIGluaXRjYWxsIHBhY2tldF9pbml0KzB4MC8weDM5IHJl dHVybmVkIDAgYWZ0ZXIgMTIgdXNlY3MNClsgICAgMi43MjUzMzRdIGNhbGxpbmcgIGJyX2lu aXQrMHgwLzB4YTAgQCAxDQpbICAgIDIuNzI1MzY5XSBCcmlkZ2UgZmlyZXdhbGxpbmcgcmVn aXN0ZXJlZA0KWyAgICAyLjcyNTM3OV0gaW5pdGNhbGwgYnJfaW5pdCsweDAvMHhhMCByZXR1 cm5lZCAwIGFmdGVyIDM1IHVzZWNzDQpbICAgIDIuNzI1MzkxXSBjYWxsaW5nICB2bGFuX3By b3RvX2luaXQrMHgwLzB4ODggQCAxDQpbICAgIDIuNzI1NDAwXSA4MDIuMVEgVkxBTiBTdXBw b3J0IHYxLjgNClsgICAgMi43MjU0MTNdIGluaXRjYWxsIHZsYW5fcHJvdG9faW5pdCsweDAv MHg4OCByZXR1cm5lZCAwIGFmdGVyIDEyIHVzZWNzDQpbICAgIDIuNzI1NDI1XSBjYWxsaW5n ICBzY3RwX2luaXQrMHgwLzB4NzAxIEAgMQ0KWyAgICAyLjcyNTg3Ml0gc2N0cDogSGFzaCB0 YWJsZXMgY29uZmlndXJlZCAoZXN0YWJsaXNoZWQgNjU1MzYgYmluZCA2NTUzNikNClsgICAg Mi43MjYwNjNdIGluaXRjYWxsIHNjdHBfaW5pdCsweDAvMHg3MDEgcmV0dXJuZWQgMCBhZnRl ciA2MDkgdXNlY3MNClsgICAgMi43MjYwNzddIGNhbGxpbmcgIG1jaGVja19kZWJ1Z2ZzX2lu aXQrMHgwLzB4M2UgQCAxDQpbICAgIDIuNzI2MDk4XSBpbml0Y2FsbCBtY2hlY2tfZGVidWdm c19pbml0KzB4MC8weDNlIHJldHVybmVkIDAgYWZ0ZXIgMTAgdXNlY3MNClsgICAgMi43MjYx MTFdIGNhbGxpbmcgIHNldmVyaXRpZXNfZGVidWdmc19pbml0KzB4MC8weDNlIEAgMQ0KWyAg ICAyLjcyNjEyM10gaW5pdGNhbGwgc2V2ZXJpdGllc19kZWJ1Z2ZzX2luaXQrMHgwLzB4M2Ug cmV0dXJuZWQgMCBhZnRlciAxIHVzZWNzDQpbICAgIDIuNzI2MTM3XSBjYWxsaW5nICBocGV0 X2luc2VydF9yZXNvdXJjZSsweDAvMHgxZSBAIDENClsgICAgMi43MjYxNTBdIGluaXRjYWxs IGhwZXRfaW5zZXJ0X3Jlc291cmNlKzB4MC8weDFlIHJldHVybmVkIDAgYWZ0ZXIgMSB1c2Vj cw0KWyAgICAyLjcyNjE2Ml0gY2FsbGluZyAgdXBkYXRlX21wX3RhYmxlKzB4MC8weDU0MyBA IDENClsgICAgMi43MjYxNzNdIGluaXRjYWxsIHVwZGF0ZV9tcF90YWJsZSsweDAvMHg1NDMg cmV0dXJuZWQgMCBhZnRlciAwIHVzZWNzDQpbICAgIDIuNzI2MTg2XSBjYWxsaW5nICBsYXBp Y19pbnNlcnRfcmVzb3VyY2UrMHgwLzB4NDYgQCAxDQpbICAgIDIuNzI2MTk3XSBpbml0Y2Fs bCBsYXBpY19pbnNlcnRfcmVzb3VyY2UrMHgwLzB4NDYgcmV0dXJuZWQgMCBhZnRlciAwIHVz ZWNzDQpbICAgIDIuNzI2MjEwXSBjYWxsaW5nICBpb19hcGljX2J1Z19maW5hbGl6ZSsweDAv MHgxYSBAIDENClsgICAgMi43MjYyMjFdIGluaXRjYWxsIGlvX2FwaWNfYnVnX2ZpbmFsaXpl KzB4MC8weDFhIHJldHVybmVkIDAgYWZ0ZXIgMCB1c2Vjcw0KWyAgICAyLjcyNjIzM10gY2Fs bGluZyAgcHJpbnRfaXBpX21vZGUrMHgwLzB4MmUgQCAxDQpbICAgIDIuNzI2MjQzXSBVc2lu ZyBJUEkgTm8tU2hvcnRjdXQgbW9kZQ0KWyAgICAyLjcyNjI1MV0gaW5pdGNhbGwgcHJpbnRf aXBpX21vZGUrMHgwLzB4MmUgcmV0dXJuZWQgMCBhZnRlciA3IHVzZWNzDQpbICAgIDIuNzI2 MjY0XSBjYWxsaW5nICBjaGVja19lYXJseV9pb3JlbWFwX2xlYWsrMHgwLzB4NjkgQCAxDQpb ICAgIDIuNzI2Mjc1XSBpbml0Y2FsbCBjaGVja19lYXJseV9pb3JlbWFwX2xlYWsrMHgwLzB4 NjkgcmV0dXJuZWQgMCBhZnRlciAwIHVzZWNzDQpbICAgIDIuNzI2Mjg4XSBjYWxsaW5nICBw YXRfbWVtdHlwZV9saXN0X2luaXQrMHgwLzB4MzcgQCAxDQpbICAgIDIuNzI2MzAyXSBpbml0 Y2FsbCBwYXRfbWVtdHlwZV9saXN0X2luaXQrMHgwLzB4MzcgcmV0dXJuZWQgMCBhZnRlciAy IHVzZWNzDQpbICAgIDIuNzI2MzE1XSBjYWxsaW5nICBzY2hlZF9pbml0X2RlYnVnKzB4MC8w eDJhIEAgMQ0KWyAgICAyLjcyNjMyOF0gaW5pdGNhbGwgc2NoZWRfaW5pdF9kZWJ1ZysweDAv MHgyYSByZXR1cm5lZCAwIGFmdGVyIDIgdXNlY3MNClsgICAgMi43MjYzNDFdIGNhbGxpbmcg IGluaXRfb29wc19pZCsweDAvMHg1MCBAIDENClsgICAgMi43MjYzNTRdIGluaXRjYWxsIGlu aXRfb29wc19pZCsweDAvMHg1MCByZXR1cm5lZCAwIGFmdGVyIDIgdXNlY3MNClsgICAgMi43 MjYzNjZdIGNhbGxpbmcgIHByaW50a19sYXRlX2luaXQrMHgwLzB4NGQgQCAxDQpbICAgIDIu NzI2Mzc5XSBpbml0Y2FsbCBwcmludGtfbGF0ZV9pbml0KzB4MC8weDRkIHJldHVybmVkIDAg YWZ0ZXIgMSB1c2Vjcw0KWyAgICAyLjcyNjM5MV0gY2FsbGluZyAgcG1fcW9zX3Bvd2VyX2lu aXQrMHgwLzB4NjUgQCAxDQpbICAgIDIuNzI2NDc2XSBpbml0Y2FsbCBwbV9xb3NfcG93ZXJf aW5pdCsweDAvMHg2NSByZXR1cm5lZCAwIGFmdGVyIDcyIHVzZWNzDQpbICAgIDIuNzI2NDg5 XSBjYWxsaW5nICB0ZXN0X3N1c3BlbmQrMHgwLzB4MTlhIEAgMQ0KWyAgICAyLjcyNjUwMV0g aW5pdGNhbGwgdGVzdF9zdXNwZW5kKzB4MC8weDE5YSByZXR1cm5lZCAwIGFmdGVyIDAgdXNl Y3MNClsgICAgMi43MjY1MTddIGNhbGxpbmcgIHNvZnR3YXJlX3Jlc3VtZSsweDAvMHgxZjAg QCAxDQpbICAgIDIuNzI2NTI4XSBQTTogSGliZXJuYXRpb24gaW1hZ2Ugbm90IHByZXNlbnQg b3IgY291bGQgbm90IGJlIGxvYWRlZC4NClsgICAgMi43MjY1NDBdIGluaXRjYWxsIHNvZnR3 YXJlX3Jlc3VtZSsweDAvMHgxZjAgcmV0dXJuZWQgLTIgYWZ0ZXIgMTEgdXNlY3MNClsgICAg Mi43MjY1NTNdIGluaXRjYWxsIHNvZnR3YXJlX3Jlc3VtZSsweDAvMHgxZjAgcmV0dXJuZWQg d2l0aCBlcnJvciBjb2RlIC0yIA0KWyAgICAyLjcyNjU2NV0gY2FsbGluZyAgdGFza3N0YXRz X2luaXQrMHgwLzB4ODUgQCAxDQpbICAgIDIuNzI2NTc5XSByZWdpc3RlcmVkIHRhc2tzdGF0 cyB2ZXJzaW9uIDENClsgICAgMi43MjY1ODhdIGluaXRjYWxsIHRhc2tzdGF0c19pbml0KzB4 MC8weDg1IHJldHVybmVkIDAgYWZ0ZXIgMTIgdXNlY3MNClsgICAgMi43MjY2MDBdIGNhbGxp bmcgIGNsZWFyX2Jvb3RfdHJhY2VyKzB4MC8weDJkIEAgMQ0KWyAgICAyLjcyNjYxMV0gaW5p dGNhbGwgY2xlYXJfYm9vdF90cmFjZXIrMHgwLzB4MmQgcmV0dXJuZWQgMCBhZnRlciAwIHVz ZWNzDQpbICAgIDIuNzI2NjIzXSBjYWxsaW5nICBrZGJfZnRyYWNlX3JlZ2lzdGVyKzB4MC8w eDM1IEAgMQ0KWyAgICAyLjcyNjYzNl0gaW5pdGNhbGwga2RiX2Z0cmFjZV9yZWdpc3Rlcisw eDAvMHgzNSByZXR1cm5lZCAwIGFmdGVyIDIgdXNlY3MNClsgICAgMi43MjY2NDldIGNhbGxp bmcgIG1heF9zd2FwZmlsZXNfY2hlY2srMHgwLzB4NyBAIDENClsgICAgMi43MjY2NjBdIGlu aXRjYWxsIG1heF9zd2FwZmlsZXNfY2hlY2srMHgwLzB4NyByZXR1cm5lZCAwIGFmdGVyIDAg dXNlY3MNClsgICAgMi43MjY2NzJdIGNhbGxpbmcgIHJhbmRvbTMyX3Jlc2VlZCsweDAvMHg4 MyBAIDENClsgICAgMi43MjY2OTBdIGluaXRjYWxsIHJhbmRvbTMyX3Jlc2VlZCsweDAvMHg4 MyByZXR1cm5lZCAwIGFmdGVyIDggdXNlY3MNClsgICAgMi43MjY3MDJdIGNhbGxpbmcgIHBj aV9yZXNvdXJjZV9hbGlnbm1lbnRfc3lzZnNfaW5pdCsweDAvMHgxNCBAIDENClsgICAgMi43 MjY3MTddIGluaXRjYWxsIHBjaV9yZXNvdXJjZV9hbGlnbm1lbnRfc3lzZnNfaW5pdCsweDAv MHgxNCByZXR1cm5lZCAwIGFmdGVyIDIgdXNlY3MNClsgICAgMi43MjY3MzBdIGNhbGxpbmcg IHBjaV9zeXNmc19pbml0KzB4MC8weDQ0IEAgMQ0KWyAgICAyLjcyNzA0OV0gaW5pdGNhbGwg cGNpX3N5c2ZzX2luaXQrMHgwLzB4NDQgcmV0dXJuZWQgMCBhZnRlciAzMDEgdXNlY3MNClsg ICAgMi43MjcwNjNdIGNhbGxpbmcgIGJvb3Rfd2FpdF9mb3JfZGV2aWNlcysweDAvMHgyZiBA IDENClsgICAgMi43MjcwNzZdIGluaXRjYWxsIGJvb3Rfd2FpdF9mb3JfZGV2aWNlcysweDAv MHgyZiByZXR1cm5lZCAwIGFmdGVyIDEgdXNlY3MNClsgICAgMi43MjcwOTBdIGNhbGxpbmcg IHJlZ3VsYXRvcl9pbml0X2NvbXBsZXRlKzB4MC8weDE0YyBAIDENClsgICAgMi43MjcxMDFd IGluaXRjYWxsIHJlZ3VsYXRvcl9pbml0X2NvbXBsZXRlKzB4MC8weDE0YyByZXR1cm5lZCAw IGFmdGVyIDAgdXNlY3MNClsgICAgMi43MjcxMTVdIGNhbGxpbmcgIHJhbmRvbV9pbnRfc2Vj cmV0X2luaXQrMHgwLzB4MTYgQCAxDQpbICAgIDIuNzI3MTM4XSBpbml0Y2FsbCByYW5kb21f aW50X3NlY3JldF9pbml0KzB4MC8weDE2IHJldHVybmVkIDAgYWZ0ZXIgMTIgdXNlY3MNClsg ICAgMi43MjcxNTRdIGNhbGxpbmcgIGxhdGVfcmVzdW1lX2luaXQrMHgwLzB4MWEwIEAgMQ0K WyAgICAyLjcyNzE2NF0gICBNYWdpYyBudW1iZXI6IDExOjI2MTo1ODcNClsgICAgMi43Mjcy MzldIGluaXRjYWxsIGxhdGVfcmVzdW1lX2luaXQrMHgwLzB4MWEwIHJldHVybmVkIDAgYWZ0 ZXIgNzMgdXNlY3MNClsgICAgMi43MjcyNTNdIGNhbGxpbmcgIHNjc2lfY29tcGxldGVfYXN5 bmNfc2NhbnMrMHgwLzB4MTIwIEAgMQ0KWyAgICAyLjcyNzI2Nl0gaW5pdGNhbGwgc2NzaV9j b21wbGV0ZV9hc3luY19zY2FucysweDAvMHgxMjAgcmV0dXJuZWQgMCBhZnRlciAwIHVzZWNz DQpbICAgIDIuNzI3MjgwXSBjYWxsaW5nICBydGNfaGN0b3N5cysweDAvMHgxMTAgQCAxDQpb ICAgIDIuNzI3MzcyXSBydGNfY21vcyAwMDowMjogc2V0dGluZyBzeXN0ZW0gY2xvY2sgdG8g MjAxMS0wOS0yMyAxNDozNDoyNyBVVEMgKDEzMTY3ODg0NjcpDQpbICAgIDIuNzI3Mzg3XSBp bml0Y2FsbCBydGNfaGN0b3N5cysweDAvMHgxMTAgcmV0dXJuZWQgMCBhZnRlciA5NCB1c2Vj cw0KWyAgICAyLjcyNzQwMV0gY2FsbGluZyAgcG93ZXJub3drOF9pbml0KzB4MC8weDE3OSBA IDENClsgICAgMi43Mjc0MjFdIHBvd2Vybm93LWs4OiBGb3VuZCAxIEFNRCBBdGhsb24odG0p IElJIFgyIDI1MCBQcm9jZXNzb3IgKDIgY3B1IGNvcmVzKSAodmVyc2lvbiAyLjIwLjAwKQ0K WyAgICAyLjcyNzQ0Ml0gW0Zpcm13YXJlIEJ1Z106IHBvd2Vybm93LWs4OiBObyBjb21wYXRp YmxlIEFDUEkgX1BTUyBvYmplY3RzIGZvdW5kLg0KWyAgICAyLjcyNzQ0M10gW0Zpcm13YXJl IEJ1Z106IHBvd2Vybm93LWs4OiBUcnkgYWdhaW4gd2l0aCBsYXRlc3QgQklPUy4NClsgICAg Mi43Mjc0NjddIGluaXRjYWxsIHBvd2Vybm93azhfaW5pdCsweDAvMHgxNzkgcmV0dXJuZWQg LTE5IGFmdGVyIDU0IHVzZWNzDQpbICAgIDIuNzI3NDc5XSBjYWxsaW5nICBhY3BpX2NwdWZy ZXFfaW5pdCsweDAvMHg4ZiBAIDENClsgICAgMi43Mjc1MTJdIGluaXRjYWxsIGFjcGlfY3B1 ZnJlcV9pbml0KzB4MC8weDhmIHJldHVybmVkIC01IGFmdGVyIDIxIHVzZWNzDQpbICAgIDIu NzI3NTI1XSBpbml0Y2FsbCBhY3BpX2NwdWZyZXFfaW5pdCsweDAvMHg4ZiByZXR1cm5lZCB3 aXRoIGVycm9yIGNvZGUgLTUgDQpbICAgIDIuNzI3NTM5XSBjYWxsaW5nICBwb3dlcm5vd19p bml0KzB4MC8weDExNCBAIDENClsgICAgMi43Mjc1NTBdIGluaXRjYWxsIHBvd2Vybm93X2lu aXQrMHgwLzB4MTE0IHJldHVybmVkIC0xOSBhZnRlciAwIHVzZWNzDQpbICAgIDIuNzI3NTYy XSBjYWxsaW5nICBsb25naGF1bF9pbml0KzB4MC8weDk1IEAgMQ0KWyAgICAyLjcyNzU3M10g aW5pdGNhbGwgbG9uZ2hhdWxfaW5pdCsweDAvMHg5NSByZXR1cm5lZCAtMTkgYWZ0ZXIgMCB1 c2Vjcw0KWyAgICAyLjcyNzU4NV0gY2FsbGluZyAgY2VudHJpbm9faW5pdCsweDAvMHgyNiBA IDENClsgICAgMi43Mjc1OTZdIGluaXRjYWxsIGNlbnRyaW5vX2luaXQrMHgwLzB4MjYgcmV0 dXJuZWQgLTE5IGFmdGVyIDAgdXNlY3MNClsgICAgMi43Mjc2MDldIGNhbGxpbmcgIGVkZF9p bml0KzB4MC8weDMxMiBAIDENClsgICAgMi43Mjc2MTddIEJJT1MgRUREIGZhY2lsaXR5IHYw LjE2IDIwMDQtSnVuLTI1LCAwIGRldmljZXMgZm91bmQNClsgICAgMi43Mjc2MjhdIEVERCBp bmZvcm1hdGlvbiBub3QgYXZhaWxhYmxlLg0KWyAgICAyLjcyNzYzN10gaW5pdGNhbGwgZWRk X2luaXQrMHgwLzB4MzEyIHJldHVybmVkIC0xOSBhZnRlciAxOCB1c2Vjcw0KWyAgICAyLjcy NzY0OV0gY2FsbGluZyAgbWVtbWFwX2luaXQrMHgwLzB4MjkgQCAxDQpbICAgIDIuNzI3Njgx XSBpbml0Y2FsbCBtZW1tYXBfaW5pdCsweDAvMHgyOSByZXR1cm5lZCAwIGFmdGVyIDE5IHVz ZWNzDQpbICAgIDIuNzI3NjkzXSBjYWxsaW5nICBwY2lfbW1jZmdfbGF0ZV9pbnNlcnRfcmVz b3VyY2VzKzB4MC8weDUzIEAgMQ0KWyAgICAyLjcyNzcwN10gaW5pdGNhbGwgcGNpX21tY2Zn X2xhdGVfaW5zZXJ0X3Jlc291cmNlcysweDAvMHg1MyByZXR1cm5lZCAwIGFmdGVyIDAgdXNl Y3MNClsgICAgMi43Mjc3MjFdIGNhbGxpbmcgIG5ldF9zZWNyZXRfaW5pdCsweDAvMHgxNiBA IDENClsgICAgMi43Mjc3NDNdIGluaXRjYWxsIG5ldF9zZWNyZXRfaW5pdCsweDAvMHgxNiBy ZXR1cm5lZCAwIGFmdGVyIDExIHVzZWNzDQpbICAgIDIuNzI3NzU1XSBjYWxsaW5nICB0Y3Bf Y29uZ2VzdGlvbl9kZWZhdWx0KzB4MC8weGYgQCAxDQpbICAgIDIuNzI3NzY3XSBpbml0Y2Fs bCB0Y3BfY29uZ2VzdGlvbl9kZWZhdWx0KzB4MC8weGYgcmV0dXJuZWQgMCBhZnRlciAxIHVz ZWNzDQpbICAgIDIuNzI3NzgxXSBjYWxsaW5nICBpbml0aWFsaXplX2hhc2hybmQrMHgwLzB4 MTYgQCAxDQpbICAgIDIuNzI3Nzk0XSBpbml0Y2FsbCBpbml0aWFsaXplX2hhc2hybmQrMHgw LzB4MTYgcmV0dXJuZWQgMCBhZnRlciAyIHVzZWNzDQpbICAgIDIuNzI3OTM5XSBhc3luY193 YWl0aW5nIEAgMQ0KWyAgICAyLjcyNzk0OV0gYXN5bmNfY29udGludWluZyBAIDEgYWZ0ZXIg MCB1c2VjDQpbICAgIDIuNzI4MjExXSBGcmVlaW5nIHVudXNlZCBrZXJuZWwgbWVtb3J5OiA2 NzZrIGZyZWVkDQpbICAgIDIuNzI5NjA5XSBXcml0ZSBwcm90ZWN0aW5nIHRoZSBrZXJuZWwg dGV4dDogNTA4MGsNClsgICAgMi43MzAwODVdIFdyaXRlIHByb3RlY3RpbmcgdGhlIGtlcm5l bCByZWFkLW9ubHkgZGF0YTogMTkzNmsNClsgICAgMi43MzAwOTddIE5YLXByb3RlY3Rpbmcg dGhlIGtlcm5lbCBkYXRhOiAzMTEyaw0KL2luaXQ6IE1vdW50aW5nIC9wcm9jLi4uDQovaW5p dDogTW91bnRpbmcgL3N5cy4uLg0KL2luaXQ6IE1vdW50aW5nIC93b3Jrc3BhY2UNClsgICAg Mi43NDIxMDBdIGlucHV0OiBBVCBUcmFuc2xhdGVkIFNldCAyIGtleWJvYXJkIGFzIC9kZXZp Y2VzL3BsYXRmb3JtL2k4MDQyL3NlcmlvMC9pbnB1dC9pbnB1dDINCi9pbml0OiBNb3VudGlu ZyAvZGV2Li4uDQovaW5pdDogTm90aWZ5aW5nIGluaXQgb2YgL2RldiBjcmVhdGlvbi4uLg0K L2luaXQ6IFN0YXJ0aW5nIHN5c2xvZ2QuLi4NCi9pbml0OiBTdGFydGluZyBrbG9nZC4uLg0K L2luaXQ6IFNlYXJjaGluZyBmb3IgYm9vdCB2b2x1bWUgb24gL2Rldi9zZGExIC9kZXYvc2Ri MQ0KL2luaXQ6IEJvb3Qgdm9sdW1lIGZvdW5kIG9uIC9kZXYvc2RiMS4NCi9pbml0OiBHZW5l cmF0aW5nIC9zeXNjb25maWcNCi9pbml0OiBNb3VudGluZyAvYm9vdC9tYXN0ZXIvWGVuTWFz dGVyLTUuMTAvcm9vdGZzIG9uIC9zeXNyb290Lg0KL2luaXQ6IFN0b3BwaW5nIGluaXRyYW1m cyBwcm9jZXNzZXMuLi4NCi9pbml0OiBSZW1vdW50aW5nIC93b3Jrc3BhY2UNCi9pbml0OiBS ZW1vdW50aW5nIC9kZXYNCi9pbml0OiBSZW1vdW50aW5nIC9zeXMNCi9pbml0OiBSZW1vdW50 aW5nIC9wcm9jDQovaW5pdDogUmVtb3VudGluZyAvc3lzY29uZmlnDQovaW5pdDogUmVtb3Vu dGluZyAvYm9vdA0KL2luaXQ6IFN3aXRjaGluZyByb290IHRvIC9zeXNyb290DQoNSU5JVDog dmVyc2lvbiAyLjg2IGJvb3RpbmcNDQpTZXR0aW5nIHRoZSBjb25zb2xlIGxvZyBsZXZlbCB0 byA3Li4uDQobWzFBG1swRxtbNzJHG1sxOzM0bVsbWzE7MzJtICBPSyAgG1sxOzM0bV0bWzA7 MzltDQpSZXN0YXJ0aW5nIHN5c3RlbSBsb2cgZGFlbW9uLi4uDQobWzFBG1swRxtbNzJHG1sx OzM0bVsbWzE7MzJtICBPSyAgG1sxOzM0bV0bWzA7MzltDQpSZXN0YXJ0aW5nIGtlcm5lbCBs b2cgZGFlbW9uLi4uDQobWzFBG1swRxtbNzJHG1sxOzM0bVsbWzE7MzJtICBPSyAgG1sxOzM0 bV0bWzA7MzltDQpTdGFydGluZyB1ZGV2ZC4uLg0KG1sxQRtbMEcbWzcyRxtbMTszNG1bG1sx OzMybSAgT0sgIBtbMTszNG1dG1swOzM5bQ0KTW91bnRpbmcgL2Rldi9wdHMuLi4NChtbMUEb WzBHG1s3MkcbWzE7MzRtWxtbMTszMm0gIE9LICAbWzE7MzRtXRtbMDszOW0NCkNyZWF0aW5n IC93b3Jrc3BhY2UvcGVyc2lzdC4uLg0KG1sxQRtbMEcbWzcyRxtbMTszNG1bG1sxOzMybSAg T0sgIBtbMTszNG1dG1swOzM5bQ0KU2V0dGluZyBzeXN0ZW0gY2xvY2suLi4NChtbMUEbWzBH G1s3MkcbWzE7MzRtWxtbMTszMm0gIE9LICAbWzE7MzRtXRtbMDszOW0NClNldHRpbmcgdXAg TGludXggY29uc29sZS4uLg0KG1sxQRtbMEcbWzcyRxtbMTszNG1bG1sxOzMybSAgT0sgIBtb MTszNG1dG1swOzM5bQ0KQnJpbmdpbmcgdXAgdGhlIGxvb3BiYWNrIGludGVyZmFjZS4uLg0K G1sxQRtbMEcbWzcyRxtbMTszNG1bG1sxOzMybSAgT0sgIBtbMTszNG1dG1swOzM5bQ0KU2V0 dGluZyBob3N0bmFtZSB0byBTZXR1cC4uLg0KG1sxQRtbMEcbWzcyRxtbMTszNG1bG1sxOzMy bSAgT0sgIBtbMTszNG1dG1swOzM5bQ0KU3RhcnRpbmcgeGVuc3RvcmVkLi4uDQpTZXR0aW5n IGRvbWFpbiAwIG5hbWUuLi4NClN0YXJ0aW5nIHhlbmNvbnNvbGVkLi4uDQpJbnN0YWxsaW5n IEVCVGFibGVzIHJ1bGVzLi4uDQobWzFBG1swRxtbNzJHG1sxOzM0bVsbWzE7MzJtICBPSyAg G1sxOzM0bV0bWzA7MzltDQpJbnN0YWxsaW5nIElQVGFibGVzIHJ1bGVzLi4uDQobWzFBG1sw RxtbNzJHG1sxOzM0bVsbWzE7MzJtICBPSyAgG1sxOzM0bV0bWzA7MzltDQoNSU5JVDogRW50 ZXJpbmcgcnVubGV2ZWw6IDMNDQpTdGFydGluZyBudHBkLi4uDQobWzFBG1swRxtbNzJHG1sx OzM0bVsbWzE7MzJtICBPSyAgG1sxOzM0bV0bWzA7MzltDQpTdGFydGluZyBtYW5hZ2VtZW50 IGFnZW50Li4uDQobWzFBG1swRxtbNzJHG1sxOzM0bVsbWzE7MzJtICBPSyAgG1sxOzM0bV0b WzA7MzltDQo= --------------080100020007070504090806 Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel --------------080100020007070504090806-- From xen-devel-bounces@lists.xensource.com Fri Sep 23 07:46:32 2011 Return-path: <xen-devel-bounces@lists.xensource.com> Envelope-to: www-data@lists.xensource.com Delivery-date: Fri, 23 Sep 2011 07:46:32 -0700 Received: from localhost ([127.0.0.1] helo=lists.colo.xensource.com) by lists.xensource.com with esmtp (Exim 4.43) id 1R771M-0005FW-1P; Fri, 23 Sep 2011 07:46:32 -0700 Received: from mail182.messagelabs.com ([85.158.139.83]) by lists.xensource.com with esmtp (Exim 4.43) id 1R770n-00052f-Pr for xen-devel@lists.xensource.com; Fri, 23 Sep 2011 07:45:58 -0700 X-Env-Sender: konrad@oracle.com X-Msg-Ref: server-14.tower-182.messagelabs.com!1316789153!19336584!1 X-Originating-IP: [148.87.113.117] X-StarScan-Version: 6.4.1; banners=-,-,- X-VirusChecked: Checked Received: (qmail 14769 invoked from network); 23 Sep 2011 14:45:54 -0000 Received: from rcsinet15.oracle.com (HELO rcsinet15.oracle.com) (148.87.113.117) by server-14.tower-182.messagelabs.com with DHE-RSA-AES256-SHA encrypted SMTP; 23 Sep 2011 14:45:54 -0000 Received: from acsinet21.oracle.com (acsinet21.oracle.com [141.146.126.237]) by rcsinet15.oracle.com (Switch-3.4.4/Switch-3.4.4) with ESMTP id p8NEjdTE014910 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Fri, 23 Sep 2011 14:45:41 GMT Received: from acsmt356.oracle.com (acsmt356.oracle.com [141.146.40.156]) by acsinet21.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id p8NEjcST016074 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 23 Sep 2011 14:45:38 GMT Received: from abhmt109.oracle.com (abhmt109.oracle.com [141.146.116.61]) by acsmt356.oracle.com (8.12.11.20060308/8.12.11) with ESMTP id p8NEjX8c008939; Fri, 23 Sep 2011 09:45:33 -0500 Received: from oracle.com (/209.6.55.207) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Fri, 23 Sep 2011 07:45:32 -0700 Received: by oracle.com (Postfix, from userid 1000) id 2A2991566; Fri, 23 Sep 2011 10:45:38 -0400 (EDT) Date: Fri, 23 Sep 2011 10:45:38 -0400 From: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com> To: Stefano Stabellini <stefano.stabellini@eu.citrix.com> Message-ID: <20110923144538.GA10701@phenom.oracle.com> References: <alpine.DEB.2.00.1109081944150.12963@kaball-desktop> <20110921145853.GA541@phenom.oracle.com> <alpine.DEB.2.00.1109231412220.8700@kaball-desktop> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <alpine.DEB.2.00.1109231412220.8700@kaball-desktop> User-Agent: Mutt/1.5.21 (2010-09-15) X-Source-IP: acsinet21.oracle.com [141.146.126.237] X-Auth-Type: Internal IP X-CT-RefId: str=0001.0A090208.4E7C9B9D.0005:SCFMA922111,ss=1,re=-6.300,fgs=0 Cc: Jeremy Fitzhardinge <jeremy@goop.org>, "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>, "linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org> Subject: [Xen-devel] Re: [PATCH v4 2/2] xen: modify kernel mappings corresponding to granted pages X-BeenThere: xen-devel@lists.xensource.com X-Mailman-Version: 2.1.5 Precedence: list List-Id: Xen developer discussion <xen-devel.lists.xensource.com> List-Unsubscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe> List-Post: <mailto:xen-devel@lists.xensource.com> List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help> List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=subscribe> Sender: xen-devel-bounces@lists.xensource.com Errors-To: xen-devel-bounces@lists.xensource.com On Fri, Sep 23, 2011 at 02:55:09PM +0100, Stefano Stabellini wrote: > On Wed, 21 Sep 2011, konrad.wilk@oracle.com wrote: > > On Thu, Sep 08, 2011 at 07:45:29PM +0100, Stefano Stabellini wrote: > > > If we want to use granted pages for AIO, changing the mappings of a user > > > vma and the corresponding p2m is not enough, we also need to update the > > > kernel mappings accordingly. > > > > Please add:" > > > > But only for pages that are created for user usages through /dev/xen/gntdev. > > As in, pages that have been in use by the kernel and use the P2M will not need > > this special mapping." > > > > Just so that it is quite clear when in a year somebody wants to debug > > this code and wants to figure out if this patch causes issues. > > > > .. more comments below. > > OK, even though in the future it might happen that the kernel starts > accessing pages through the 1:1 even for internal usage. Right now the > only case in which this happens is on the user AIO code path but it > doesn't mean that the problem is always going to be limited to pages > used for user AIO. OK, please add that comment saying that.. > > > > > In order to avoid the complexity of dealing with highmem, we allocated > > > the pages lowmem. > > > We issue a HYPERVISOR_grant_table_op right away in > > > m2p_add_override and we remove the mappings using another > > > HYPERVISOR_grant_table_op in m2p_remove_override. > > > Considering that m2p_add_override and m2p_remove_override are called > > > once per page we use multicalls and hypercall batching. > > > > > > Use the kmap_op pointer directly as argument to do the mapping as it is > > > guaranteed to be present up until the unmapping is done. > > > Before issuing any unmapping multicalls, we need to make sure that the > > > mapping has already being done, because we need the kmap->handle to be > > > set correctly. > > > > > > Signed-off-by: Stefano Stabellini <stefano.stabellini@eu.citrix.com> > > > --- > > > arch/x86/include/asm/xen/page.h | 5 ++- > > > arch/x86/xen/p2m.c | 68 +++++++++++++++++++++++++++++------ > > > drivers/block/xen-blkback/blkback.c | 2 +- > > > drivers/xen/gntdev.c | 27 +++++++++++++- > > > drivers/xen/grant-table.c | 6 ++-- > > > include/xen/grant_table.h | 1 + > > > 6 files changed, 92 insertions(+), 17 deletions(-) > > > > > > diff --git a/arch/x86/include/asm/xen/page.h b/arch/x86/include/asm/xen/page.h > > > index 7ff4669..0ce1884 100644 > > > --- a/arch/x86/include/asm/xen/page.h > > > +++ b/arch/x86/include/asm/xen/page.h > > > @@ -12,6 +12,7 @@ > > > #include <asm/pgtable.h> > > > > > > #include <xen/interface/xen.h> > > > +#include <xen/grant_table.h> > > > #include <xen/features.h> > > > > > > /* Xen machine address */ > > > @@ -31,8 +32,10 @@ typedef struct xpaddr { > > > #define INVALID_P2M_ENTRY (~0UL) > > > #define FOREIGN_FRAME_BIT (1UL<<(BITS_PER_LONG-1)) > > > #define IDENTITY_FRAME_BIT (1UL<<(BITS_PER_LONG-2)) > > > +#define GRANT_FRAME_BIT (1UL<<(BITS_PER_LONG-3)) We aren't actually using the GRANT_FRAME_BIT in the P2M? As in setting the value in the nice p2m.c code? So could this be 1UL<<(BITS_PER_LONG-1) ? as you are setting this bit only in the page->private and not really in the P2M tree...? Or did I miss some extra patch? > > > #define FOREIGN_FRAME(m) ((m) | FOREIGN_FRAME_BIT) > > > #define IDENTITY_FRAME(m) ((m) | IDENTITY_FRAME_BIT) > > > +#define GRANT_FRAME(m) ((m) | GRANT_FRAME_BIT) > > > > > > /* Maximum amount of memory we can handle in a domain in pages */ > > > #define MAX_DOMAIN_PAGES \ > > > @@ -48,7 +51,7 @@ extern unsigned long set_phys_range_identity(unsigned long pfn_s, > > > unsigned long pfn_e); > > > > > > extern int m2p_add_override(unsigned long mfn, struct page *page, > > > - bool clear_pte); > > > + struct gnttab_map_grant_ref *kmap_op); > > > extern int m2p_remove_override(struct page *page, bool clear_pte); > > > extern struct page *m2p_find_override(unsigned long mfn); > > > extern unsigned long m2p_find_override_pfn(unsigned long mfn, unsigned long pfn); > > > diff --git a/arch/x86/xen/p2m.c b/arch/x86/xen/p2m.c > > > index 58efeb9..23f8465 100644 > > > --- a/arch/x86/xen/p2m.c > > > +++ b/arch/x86/xen/p2m.c > > > @@ -161,7 +161,9 @@ > > > #include <asm/xen/page.h> > > > #include <asm/xen/hypercall.h> > > > #include <asm/xen/hypervisor.h> > > > +#include <xen/grant_table.h> > > > > > > +#include "multicalls.h" > > > #include "xen-ops.h" > > > > > > static void __init m2p_override_init(void); > > > @@ -676,7 +678,8 @@ static unsigned long mfn_hash(unsigned long mfn) > > > } > > > > > > /* Add an MFN override for a particular page */ > > > -int m2p_add_override(unsigned long mfn, struct page *page, bool clear_pte) > > > +int m2p_add_override(unsigned long mfn, struct page *page, > > > + struct gnttab_map_grant_ref *kmap_op) > > > { > > > unsigned long flags; > > > unsigned long pfn; > > > @@ -699,9 +702,20 @@ int m2p_add_override(unsigned long mfn, struct page *page, bool clear_pte) > > > if (unlikely(!set_phys_to_machine(pfn, FOREIGN_FRAME(mfn)))) > > > return -ENOMEM; > > > > > > - if (clear_pte && !PageHighMem(page)) > > > - /* Just zap old mapping for now */ > > > - pte_clear(&init_mm, address, ptep); > > > + if (kmap_op != NULL) { > > > + if (!PageHighMem(page)) { > > > + struct multicall_space mcs = xen_mc_entry(sizeof(*kmap_op)); > > > + > > > + MULTI_grant_table_op(mcs.mc, > > > + GNTTABOP_map_grant_ref, kmap_op, 1); > > > + > > > + xen_mc_issue(PARAVIRT_LAZY_MMU); > > > + } > > > + page->private |= GRANT_FRAME_BIT; It took a bit of stroll through the different users of page->private and they seem to vary from sticking a 'struct list' (virtblk) on it, to sticking an writeblock structure in it (afs) to some other users. Wonder if it makes sense to use the provided macros: SetPagePrivate(page) set_page_private(page, page_private(page) | GRANT_FRAME_BIT); just to make it more prettier? Not really worried here, I can queue up a patch for that myself for the rest of the M2P. But (on a completlty different subject of this patch), I wonder about fs/btrfs/extent_io.c (set_page_extent_mapped) or nfs_inode_add_request (fs/nfs/write.c) and whether we are we in danger of colliding with that? Say the page is used for AIO and eventually ends up in btrfs or NFS? Wouldn't BTFS/NFS end up scrambling our precious page->private contents? Hm... NFS and both BTRFS seems to check for PagePrivate bit (which we forgot to set) so we might be shooting ourselves in the foot - but I don't know enough about those FS to know whether those pages that use ->private are special pages which the user does not provide. Anyhow, If you want to modify your patchset to check PagePrivate bit and set the SetPagePrivate/set_page_private - go ahead. Otherwise I will queue up a patch that does those SetPagePrivate/set_page_private calls. > > > + /* let's use dev_bus_addr to record the old mfn instead */ > > > + kmap_op->dev_bus_addr = page->index; > > > + page->index = (unsigned long) kmap_op; > > > + } > > > spin_lock_irqsave(&m2p_override_lock, flags); > > > list_add(&page->lru, &m2p_overrides[mfn_hash(mfn)]); > > > spin_unlock_irqrestore(&m2p_override_lock, flags); > > > @@ -735,13 +749,45 @@ int m2p_remove_override(struct page *page, bool clear_pte) > > > spin_lock_irqsave(&m2p_override_lock, flags); > > > list_del(&page->lru); > > > spin_unlock_irqrestore(&m2p_override_lock, flags); > > > - set_phys_to_machine(pfn, page->index); > > > > > > - if (clear_pte && !PageHighMem(page)) > > > - set_pte_at(&init_mm, address, ptep, > > > - pfn_pte(pfn, PAGE_KERNEL)); > > > - /* No tlb flush necessary because the caller already > > > - * left the pte unmapped. */ > > > + if (clear_pte) { > > > + struct gnttab_map_grant_ref *map_op = > > > + (struct gnttab_map_grant_ref *) page->index; > > > + set_phys_to_machine(pfn, map_op->dev_bus_addr); > > > + if (!PageHighMem(page)) { > > > + struct multicall_space mcs; > > > + struct gnttab_unmap_grant_ref *unmap_op; > > > + > > > + /* > > > + * Has the grant_op mapping multicall being issued? If not, > > > + * make sure it is called now. > > > + */ > > > + if (map_op->handle == -1) > > > + xen_mc_flush(); > > > > How do you trigger this case? The mapping looks to be set by "gntdev_add_map" > > which is happening right after in gntdev_alloc_map.. > > > > If it had failed from the gntdev_alloc_map to gntdev_add_map this page would > > have never been used in the m2p as we would not have provided the proper > > op.index value to the user. Which mean that the user could not have mmaped > > and gotten to this code. > > The problem is that all the grant table mappings are done through > multicalls now, and we are not really sure when the multicall is going > to be actually issued. > It might be that we queued all the m2p grant table hypercalls in a > multicall, then m2p_remove_override gets called before the multicall has > actually been issued. In this case handle is going to -1 because it hasn't > been modified yet. Aaaah. Can you add that in the comment? /* It might be that we queued all the m2p grant table hypercalls in a multicall, then m2p_remove_override gets called before the multicall has actually been issued. In this case handle is going to -1 because it hasn't been modifuied yet. */ > This is the case we are trying to handle here. > > > > > + if (map_op->handle == -1) { > > > > The other one I can understand, but this one I am baffled by. How > > would the xen_mc_flush trigger the handle to be set to -1? > > > > Is the hypercall writting that value in the op.handle after it has completed? > > Yes. The hypercall might return -1 in the handle in case of errors. Which is GNTST_general_error? How about we check against that instead of using -1? > > > > Also, we might want to document somwhere -1 now that I think of it. > > It does not look like that is a value that is defined anywhere. > > It is already documented in the hypercall interface in > include/xen/interface/grant_table.h > > > > > + printk(KERN_WARNING "m2p_remove_override: pfn %lx mfn %lx, " > > > + "failed to modify kernel mappings", pfn, mfn); > > > + return -1; > > > + } > > > + > > > + mcs = xen_mc_entry(sizeof(struct gnttab_unmap_grant_ref)); > > > + unmap_op = mcs.args; > > > + unmap_op->host_addr = map_op->host_addr; > > > + unmap_op->handle = map_op->handle; > > > + unmap_op->dev_bus_addr = 0; > > > + > > > + MULTI_grant_table_op(mcs.mc, > > > + GNTTABOP_unmap_grant_ref, unmap_op, 1); > > > + > > > + xen_mc_issue(PARAVIRT_LAZY_MMU); > > > + > > > + set_pte_at(&init_mm, address, ptep, > > > + pfn_pte(pfn, PAGE_KERNEL)); > > > + __flush_tlb_single(address); > > > + map_op->host_addr = 0; > > > > I am not sure that is neccesseray? When we are done, err, when we end > > up calling here that means the region has been unmapped or > > IOCTL_GNTDEV_UNMAP_GRANT_REF called right? > > Yes. > > > And when we do end up here, then the a whole bunch of those pages > > get free-ed? Don't they? > > Right. However considering that map_op is a parameter passed by the > caller, it makes sense to set it back to a consistent state, no matter > if the caller is just going to free map_op right after. Ok. > > > > > + } > > > + } else > > > + set_phys_to_machine(pfn, page->index); > > > > > > return 0; > > > } > > > @@ -758,7 +804,7 @@ struct page *m2p_find_override(unsigned long mfn) > > > spin_lock_irqsave(&m2p_override_lock, flags); > > > > > > list_for_each_entry(p, bucket, lru) { > > > - if (p->private == mfn) { > > > + if ((p->private & (~GRANT_FRAME_BIT)) == mfn) { > > > ret = p; > > > break; > > > } > > > diff --git a/drivers/block/xen-blkback/blkback.c b/drivers/block/xen-blkback/blkback.c > > > index 2330a9a..1540792 100644 > > > --- a/drivers/block/xen-blkback/blkback.c > > > +++ b/drivers/block/xen-blkback/blkback.c > > > @@ -396,7 +396,7 @@ static int xen_blkbk_map(struct blkif_request *req, > > > continue; > > > > > > ret = m2p_add_override(PFN_DOWN(map[i].dev_bus_addr), > > > - blkbk->pending_page(pending_req, i), false); > > > + blkbk->pending_page(pending_req, i), NULL); > > > if (ret) { > > > pr_alert(DRV_PFX "Failed to install M2P override for %lx (ret: %d)\n", > > > (unsigned long)map[i].dev_bus_addr, ret); > > > diff --git a/drivers/xen/gntdev.c b/drivers/xen/gntdev.c > > > index 7b9b1d1..bfe1271 100644 > > > --- a/drivers/xen/gntdev.c > > > +++ b/drivers/xen/gntdev.c > > > @@ -83,6 +83,7 @@ struct grant_map { > > > struct ioctl_gntdev_grant_ref *grants; > > > struct gnttab_map_grant_ref *map_ops; > > > struct gnttab_unmap_grant_ref *unmap_ops; > > > + struct gnttab_map_grant_ref *kmap_ops; > > > struct page **pages; > > > }; > > > > > > @@ -116,10 +117,12 @@ static struct grant_map *gntdev_alloc_map(struct gntdev_priv *priv, int count) > > > add->grants = kzalloc(sizeof(add->grants[0]) * count, GFP_KERNEL); > > > add->map_ops = kzalloc(sizeof(add->map_ops[0]) * count, GFP_KERNEL); > > > add->unmap_ops = kzalloc(sizeof(add->unmap_ops[0]) * count, GFP_KERNEL); > > > + add->kmap_ops = kzalloc(sizeof(add->kmap_ops[0]) * count, GFP_KERNEL); > > > add->pages = kzalloc(sizeof(add->pages[0]) * count, GFP_KERNEL); > > > if (NULL == add->grants || > > > NULL == add->map_ops || > > > NULL == add->unmap_ops || > > > + NULL == add->kmap_ops || > > > NULL == add->pages) > > > goto err; > > > > > > @@ -129,6 +132,7 @@ static struct grant_map *gntdev_alloc_map(struct gntdev_priv *priv, int count) > > > for (i = 0; i < count; i++) { > > > add->map_ops[i].handle = -1; > > > add->unmap_ops[i].handle = -1; > > > + add->kmap_ops[i].handle = -1; > > > } > > > > > > add->index = 0; > > > @@ -142,6 +146,7 @@ err: > > > kfree(add->grants); > > > kfree(add->map_ops); > > > kfree(add->unmap_ops); > > > + kfree(add->kmap_ops); > > > kfree(add); > > > return NULL; > > > } > > > @@ -243,10 +248,30 @@ static int map_grant_pages(struct grant_map *map) > > > gnttab_set_unmap_op(&map->unmap_ops[i], addr, > > > map->flags, -1 /* handle */); > > > } > > > + } else { > > > + for (i = 0; i < map->count; i++) { > > > + unsigned level; > > > + unsigned long address = (unsigned long) > > > + pfn_to_kaddr(page_to_pfn(map->pages[i])); > > > + pte_t *ptep; > > > + u64 pte_maddr = 0; > > > + if (!PageHighMem(map->pages[i])) { > > > + ptep = lookup_address(address, &level); > > > + pte_maddr = > > > + arbitrary_virt_to_machine(ptep).maddr; > > > + } > > > > And it looks like having kmap->ops.host_addr = 0 is valid > > so that is good on the chance it is high map... but that begs > > the question whether we should the hypercall at all? > > As in, can we do anything with the grants if there is no PTE > > or MFN associated with it - just the handle? Does Xen do something > > special - like a relaxed "oh ok, we can handle that later on" ? > > map->pages[i] cannot be highmap pages anymore, thanks to the previous > patch that changes alloc_xenballooned_pages. > We could even remove the if (!PageHighMem(map->pages[i])) at this > point... Ok. And perhaps replace it with BUG_ON just in case? > > > > > + gnttab_set_map_op(&map->kmap_ops[i], pte_maddr, > > > + map->flags | > > > + GNTMAP_host_map | > > > + GNTMAP_contains_pte, > > > + map->grants[i].ref, > > > + map->grants[i].domid); > > > + } > > > > So, on startup.. (before this function is called) the > > find_grant_ptes is called which pretty much does the exact thing for > > each virtual address. Except its flags are GNTMAP_application_map > > instead of GNTMAP_host_map. > > > > It even uses the same type structure.. It fills out map_ops[i] one. > > > > Can we use that instead of adding a new structure? > > Do you mean moving this code inside find_grant_ptes? > I don't think that can be done because find_grant_ptes is called on a > range of virtual addresses while this is called on an array of struct > pages. It is true that the current implementation of But aren't that 'range of virtual address' of struct pages? You are using 'alloc_xenballooned_pages' to get those pages and that is what the 'range of virtual adresses' is walking through. > alloc_xenballooned_pages is going to return a consecutive set of pages > but it might not always be the case. I am sensing some grand plans in work here? I thought we are going to try to simply our lives and see about making alloc_xenballooned_pages returned sane pages that are !PageHighMem (or if they are PageHighMem they are already pinned, and set in the &init_mm)? I am just thinking in terms of lookup_address and arbitrary_virt_to_machine calls being done _twice_. And it seems like we have the find_grant_ptes which does the bulk of this already - so why not piggyback on it? Besides that, the patch set looks fine. .. How do I reproduce the failures you had encountered with the AIO? _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel From xen-devel-bounces@lists.xensource.com Fri Sep 23 07:50:51 2011 Return-path: <xen-devel-bounces@lists.xensource.com> Envelope-to: www-data@lists.xensource.com Delivery-date: Fri, 23 Sep 2011 07:50:51 -0700 Received: from localhost ([127.0.0.1] helo=lists.colo.xensource.com) by lists.xensource.com with esmtp (Exim 4.43) id 1R775X-0005fV-0X; Fri, 23 Sep 2011 07:50:51 -0700 Received: from mail182.messagelabs.com ([85.158.139.83]) by lists.xensource.com with smtp (Exim 4.43) id 1R774n-0005T3-Ds for xen-devel@lists.xensource.com; Fri, 23 Sep 2011 07:50:07 -0700 X-Env-Sender: anthony@overnetdata.com X-Msg-Ref: server-6.tower-182.messagelabs.com!1316789399!18298879!1 X-Originating-IP: [81.137.131.225] X-StarScan-Version: 6.4.1; banners=-,-,- X-VirusChecked: Checked Received: (qmail 20519 invoked from network); 23 Sep 2011 14:49:59 -0000 Received: from host81-137-131-225.in-addr.btopenworld.com (HELO zimbra.overnetdata.com) (81.137.131.225) by server-6.tower-182.messagelabs.com with SMTP; 23 Sep 2011 14:49:59 -0000 Received: from localhost (localhost.localdomain [127.0.0.1]) by zimbra.overnetdata.com (Postfix) with ESMTP id C92F616187F; Fri, 23 Sep 2011 15:49:58 +0100 (BST) X-Virus-Scanned: amavisd-new at overnetdata.com Received: from zimbra.overnetdata.com ([127.0.0.1]) by localhost (zimbra.overnetdata.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JaQjA-7Oykt5; Fri, 23 Sep 2011 15:49:49 +0100 (BST) Received: from [192.168.1.60] (unknown [192.168.1.60]) by zimbra.overnetdata.com (Postfix) with ESMTPSA id 4CD9D1616D7; Fri, 23 Sep 2011 15:49:49 +0100 (BST) Message-ID: <4E7C9C8B.2010108@overnetdata.com> Date: Fri, 23 Sep 2011 15:49:47 +0100 From: Anthony Wright <anthony@overnetdata.com> User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:6.0.2) Gecko/20110902 Thunderbird/6.0.2 MIME-Version: 1.0 To: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com> Subject: Re: [Xen-devel] dmidecode doesn't work under xen 4.1.1 on certain hardware References: <4E7C6BDC.8070005@overnetdata.com> <20110923133200.GC19579@phenom.oracle.com> In-Reply-To: <20110923133200.GC19579@phenom.oracle.com> X-Enigmail-Version: 1.3.2 Content-Type: multipart/mixed; boundary="------------050307050103030702000305" Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com> X-BeenThere: xen-devel@lists.xensource.com X-Mailman-Version: 2.1.5 Precedence: list List-Id: Xen developer discussion <xen-devel.lists.xensource.com> List-Unsubscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe> List-Post: <mailto:xen-devel@lists.xensource.com> List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help> List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=subscribe> Sender: xen-devel-bounces@lists.xensource.com Errors-To: xen-devel-bounces@lists.xensource.com This is a multi-part message in MIME format. --------------050307050103030702000305 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit On 23/09/2011 14:32, Konrad Rzeszutek Wilk wrote: > On Fri, Sep 23, 2011 at 12:22:04PM +0100, Anthony Wright wrote: >> I have a xen 4.1.1 with a 3.0.4 linux kernel running on a Supermicro >> Supermicro X8DTL-iF motherboard with 16GB of RAM. >> >> If I run the 3.0.4 kernel on the bare metal dmidecode works fine. If I > Can you attach the beginning of the kernel bootup log? It should > have some entry about 1-1 mappings. Make sure to run Linux with "debug loglevel=8" Please find attached. --------------050307050103030702000305 Content-Type: text/plain; name="dmidecode-messages.log" Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename="dmidecode-messages.log" 2011 Sep 23 14:45:41 syslog-ng[77]: syslog-ng version 1.6.12 starting 2011 Sep 23 14:45:41 kernel: klogd 1.5.0, log source = /proc/kmsg started. 2011 Sep 23 14:45:41 kernel: Cannot find map file. 2011 Sep 23 14:45:41 kernel: Loaded 58607 symbols from 1 module. 2011 Sep 23 14:45:41 kernel: [ 0.000000] Reserving virtual address space above 0xf5800000 2011 Sep 23 14:45:41 kernel: [ 0.000000] Initializing cgroup subsys cpuset 2011 Sep 23 14:45:41 kernel: [ 0.000000] Initializing cgroup subsys cpu 2011 Sep 23 14:45:41 kernel: [ 0.000000] Linux version 3.0.4 (root@linux-krq0) (gcc version 4.4.3 (GCC) ) #1 SMP Thu Sep 22 12:32:25 GMT 2011 2011 Sep 23 14:45:41 kernel: [ 0.000000] KERNEL supported cpus: 2011 Sep 23 14:45:41 kernel: [ 0.000000] Intel GenuineIntel 2011 Sep 23 14:45:41 kernel: [ 0.000000] AMD AuthenticAMD 2011 Sep 23 14:45:41 kernel: [ 0.000000] NSC Geode by NSC 2011 Sep 23 14:45:41 kernel: [ 0.000000] Cyrix CyrixInstead 2011 Sep 23 14:45:41 kernel: [ 0.000000] Centaur CentaurHauls 2011 Sep 23 14:45:41 kernel: [ 0.000000] Transmeta GenuineTMx86 2011 Sep 23 14:45:41 kernel: [ 0.000000] Transmeta TransmetaCPU 2011 Sep 23 14:45:41 kernel: [ 0.000000] UMC UMC UMC UMC 2011 Sep 23 14:45:41 kernel: [ 0.000000] xen_release_chunk: looking at area pfn bf780-bf78e: 14 pages freed 2011 Sep 23 14:45:41 kernel: [ 0.000000] xen_release_chunk: looking at area pfn bf7e0-bf7ec: 12 pages freed 2011 Sep 23 14:45:41 kernel: [ 0.000000] xen_release_chunk: looking at area pfn c0000-e0000: 131072 pages freed 2011 Sep 23 14:45:41 kernel: [ 0.000000] xen_release_chunk: looking at area pfn f0000-fec00: 60416 pages freed 2011 Sep 23 14:45:41 kernel: [ 0.000000] xen_release_chunk: looking at area pfn fec01-fec8a: 137 pages freed 2011 Sep 23 14:45:41 kernel: [ 0.000000] xen_release_chunk: looking at area pfn fec8b-fee00: 373 pages freed 2011 Sep 23 14:45:41 kernel: [ 0.000000] xen_release_chunk: looking at area pfn fee01-ffc00: 3583 pages freed 2011 Sep 23 14:45:41 kernel: [ 0.000000] released 195607 pages of unused memory 2011 Sep 23 14:45:41 kernel: [ 0.000000] 1-1 mapping on 9a->100 2011 Sep 23 14:45:41 kernel: [ 0.000000] 1-1 mapping on bf780->100000 2011 Sep 23 14:45:41 kernel: [ 0.000000] Set 264422 page(s) to 1-1 mapping. 2011 Sep 23 14:45:41 kernel: [ 0.000000] BIOS-provided physical RAM map: 2011 Sep 23 14:45:41 kernel: [ 0.000000] Xen: 0000000000000000 - 0000000000099000 (usable) 2011 Sep 23 14:45:41 kernel: [ 0.000000] Xen: 0000000000099800 - 0000000000100000 (reserved) 2011 Sep 23 14:45:41 kernel: [ 0.000000] Xen: 0000000000100000 - 00000000bf780000 (usable) 2011 Sep 23 14:45:41 kernel: [ 0.000000] Xen: 00000000bf78e000 - 00000000bf790000 type 9 2011 Sep 23 14:45:41 kernel: [ 0.000000] Xen: 00000000bf790000 - 00000000bf79e000 (ACPI data) 2011 Sep 23 14:45:41 kernel: [ 0.000000] Xen: 00000000bf79e000 - 00000000bf7d0000 (ACPI NVS) 2011 Sep 23 14:45:41 kernel: [ 0.000000] Xen: 00000000bf7d0000 - 00000000bf7e0000 (reserved) 2011 Sep 23 14:45:41 kernel: [ 0.000000] Xen: 00000000bf7ec000 - 00000000c0000000 (reserved) 2011 Sep 23 14:45:41 kernel: [ 0.000000] Xen: 00000000e0000000 - 00000000f0000000 (reserved) 2011 Sep 23 14:45:41 kernel: [ 0.000000] Xen: 00000000fec00000 - 00000000fec01000 (reserved) 2011 Sep 23 14:45:41 kernel: [ 0.000000] Xen: 00000000fec8a000 - 00000000fec8b000 (reserved) 2011 Sep 23 14:45:41 kernel: [ 0.000000] Xen: 00000000fee00000 - 00000000fee01000 (reserved) 2011 Sep 23 14:45:41 kernel: [ 0.000000] Xen: 00000000ffc00000 - 0000000100000000 (reserved) 2011 Sep 23 14:45:41 kernel: [ 0.000000] Xen: 0000000100000000 - 00000003b017a000 (usable) 2011 Sep 23 14:45:41 kernel: [ 0.000000] Xen: 0000000400000000 - 0000000440000000 (unusable) 2011 Sep 23 14:45:41 kernel: [ 0.000000] NX (Execute Disable) protection: active 2011 Sep 23 14:45:41 kernel: [ 0.000000] DMI present. 2011 Sep 23 14:45:41 kernel: [ 0.000000] DMI: Supermicro X8DTL/X8DTL, BIOS 2.0c 01/05/11 2011 Sep 23 14:45:41 kernel: [ 0.000000] e820 update range: 0000000000000000 - 0000000000010000 (usable) ==> (reserved) 2011 Sep 23 14:45:41 kernel: [ 0.000000] e820 remove range: 00000000000a0000 - 0000000000100000 (usable) 2011 Sep 23 14:45:41 kernel: [ 0.000000] last_pfn = 0x3b017a max_arch_pfn = 0x1000000 2011 Sep 23 14:45:41 kernel: [ 0.000000] found SMP MP-table at [c00ff780] ff780 2011 Sep 23 14:45:41 kernel: [ 0.000000] initial memory mapped : 0 - 03bff000 2011 Sep 23 14:45:41 kernel: [ 0.000000] Base memory trampoline at [c0095000] 95000 size 16384 2011 Sep 23 14:45:41 kernel: [ 0.000000] init_memory_mapping: 0000000000000000-000000002d3fe000 2011 Sep 23 14:45:41 kernel: [ 0.000000] 0000000000 - 002d3fe000 page 4k 2011 Sep 23 14:45:41 kernel: [ 0.000000] kernel direct mapping tables up to 2d3fe000 @ 3a92000-3bff000 2011 Sep 23 14:45:41 kernel: [ 0.000000] xen: setting RW the range 3bde000 - 3bff000 2011 Sep 23 14:45:41 kernel: [ 0.000000] RAMDISK: 01b38000 - 02449000 2011 Sep 23 14:45:41 kernel: [ 0.000000] ACPI: RSDP 000fabe0 00024 (v02 ACPIAM) 2011 Sep 23 14:45:41 kernel: [ 0.000000] ACPI: XSDT bf790100 0007C (v01 SMCI 20110105 MSFT 00000097) 2011 Sep 23 14:45:41 kernel: [ 0.000000] ACPI: FACP bf790290 000F4 (v03 010511 FACP1122 20110105 MSFT 00000097) 2011 Sep 23 14:45:41 kernel: [ 0.000000] ACPI: DSDT bf7906a0 0655C (v01 10006 10006000 00000000 INTL 20051117) 2011 Sep 23 14:45:41 kernel: [ 0.000000] ACPI: FACS bf79e000 00040 2011 Sep 23 14:45:41 kernel: [ 0.000000] ACPI: APIC bf790390 0011E (v01 010511 APIC1122 20110105 MSFT 00000097) 2011 Sep 23 14:45:41 kernel: [ 0.000000] ACPI: MCFG bf7904b0 0003C (v01 010511 OEMMCFG 20110105 MSFT 00000097) 2011 Sep 23 14:45:41 kernel: [ 0.000000] ACPI: SLIT bf7904f0 00030 (v01 010511 OEMSLIT 20110105 MSFT 00000097) 2011 Sep 23 14:45:41 kernel: [ 0.000000] ACPI: OEMB bf79e040 00085 (v01 010511 OEMB1122 20110105 MSFT 00000097) 2011 Sep 23 14:45:41 kernel: [ 0.000000] ACPI: HPET bf79a6a0 00038 (v01 010511 OEMHPET 20110105 MSFT 00000097) 2011 Sep 23 14:45:41 kernel: [ 0.000000] ACPI: SSDT bf79efb0 00363 (v01 DpgPmm CpuPm 00000012 INTL 20051117) 2011 Sep 23 14:45:41 kernel: [ 0.000000] ACPI: EINJ bf79a6e0 00130 (v01 AMIER AMI_EINJ 20110105 MSFT 00000097) 2011 Sep 23 14:45:41 kernel: [ 0.000000] ACPI: BERT bf79a870 00030 (v01 AMIER AMI_BERT 20110105 MSFT 00000097) 2011 Sep 23 14:45:41 kernel: [ 0.000000] ACPI: ERST bf79a8a0 001B0 (v01 AMIER AMI_ERST 20110105 MSFT 00000097) 2011 Sep 23 14:45:41 kernel: [ 0.000000] ACPI: HEST bf79aa50 000A8 (v01 AMIER ABC_HEST 20110105 MSFT 00000097) 2011 Sep 23 14:45:41 kernel: [ 0.000000] ACPI: Local APIC address 0xfee00000 2011 Sep 23 14:45:41 kernel: [ 0.000000] 14381MB HIGHMEM available. 2011 Sep 23 14:45:41 kernel: [ 0.000000] 723MB LOWMEM available. 2011 Sep 23 14:45:41 kernel: [ 0.000000] mapped low ram: 0 - 2d3fe000 2011 Sep 23 14:45:41 kernel: [ 0.000000] low ram: 0 - 2d3fe000 2011 Sep 23 14:45:41 kernel: [ 0.000000] Zone PFN ranges: 2011 Sep 23 14:45:41 kernel: [ 0.000000] DMA 0x00000010 -> 0x00001000 2011 Sep 23 14:45:41 kernel: [ 0.000000] Normal 0x00001000 -> 0x0002d3fe 2011 Sep 23 14:45:41 kernel: [ 0.000000] HighMem 0x0002d3fe -> 0x003b017a 2011 Sep 23 14:45:41 kernel: [ 0.000000] Movable zone start PFN for each node 2011 Sep 23 14:45:41 kernel: [ 0.000000] early_node_map[3] active PFN ranges 2011 Sep 23 14:45:41 kernel: [ 0.000000] 0: 0x00000010 -> 0x00000099 2011 Sep 23 14:45:41 kernel: [ 0.000000] 0: 0x00000100 -> 0x000bf780 2011 Sep 23 14:45:41 kernel: [ 0.000000] 0: 0x00100000 -> 0x003b017a 2011 Sep 23 14:45:41 kernel: [ 0.000000] On node 0 totalpages: 3602563 2011 Sep 23 14:45:41 kernel: [ 0.000000] free_area_init_node: node 0, pgdat c1733b40, node_mem_map e5df5200 2011 Sep 23 14:45:41 kernel: [ 0.000000] DMA zone: 32 pages used for memmap 2011 Sep 23 14:45:41 kernel: [ 0.000000] DMA zone: 0 pages reserved 2011 Sep 23 14:45:41 kernel: [ 0.000000] DMA zone: 3945 pages, LIFO batch:0 2011 Sep 23 14:45:41 kernel: [ 0.000000] Normal zone: 1416 pages used for memmap 2011 Sep 23 14:45:41 kernel: [ 0.000000] Normal zone: 179830 pages, LIFO batch:31 2011 Sep 23 14:45:41 kernel: [ 0.000000] HighMem zone: 28763 pages used for memmap 2011 Sep 23 14:45:41 kernel: [ 0.000000] HighMem zone: 3388577 pages, LIFO batch:31 2011 Sep 23 14:45:41 kernel: [ 0.000000] Using APIC driver default 2011 Sep 23 14:45:41 kernel: [ 0.000000] ACPI: PM-Timer IO Port: 0x808 2011 Sep 23 14:45:41 kernel: [ 0.000000] ACPI: Local APIC address 0xfee00000 2011 Sep 23 14:45:41 kernel: [ 0.000000] ACPI: LAPIC (acpi_id[0x01] lapic_id[0x00] enabled) 2011 Sep 23 14:45:41 kernel: [ 0.000000] BIOS bug: APIC version is 0 for CPU 0/0x0, fixing up to 0x10 2011 Sep 23 14:45:41 kernel: [ 0.000000] ACPI: LAPIC (acpi_id[0x02] lapic_id[0x02] enabled) 2011 Sep 23 14:45:41 kernel: [ 0.000000] ACPI: LAPIC (acpi_id[0x03] lapic_id[0x04] enabled) 2011 Sep 23 14:45:41 kernel: [ 0.000000] ACPI: LAPIC (acpi_id[0x04] lapic_id[0x06] enabled) 2011 Sep 23 14:45:41 kernel: [ 0.000000] ACPI: LAPIC (acpi_id[0x05] lapic_id[0x84] disabled) 2011 Sep 23 14:45:41 kernel: [ 0.000000] ACPI: LAPIC (acpi_id[0x06] lapic_id[0x85] disabled) 2011 Sep 23 14:45:41 kernel: [ 0.000000] ACPI: LAPIC (acpi_id[0x07] lapic_id[0x86] disabled) 2011 Sep 23 14:45:41 kernel: [ 0.000000] ACPI: LAPIC (acpi_id[0x08] lapic_id[0x87] disabled) 2011 Sep 23 14:45:41 kernel: [ 0.000000] ACPI: LAPIC (acpi_id[0x09] lapic_id[0x88] disabled) 2011 Sep 23 14:45:41 kernel: [ 0.000000] ACPI: LAPIC (acpi_id[0x0a] lapic_id[0x89] disabled) 2011 Sep 23 14:45:41 kernel: [ 0.000000] ACPI: LAPIC (acpi_id[0x0b] lapic_id[0x8a] disabled) 2011 Sep 23 14:45:41 kernel: [ 0.000000] ACPI: LAPIC (acpi_id[0x0c] lapic_id[0x8b] disabled) 2011 Sep 23 14:45:41 kernel: [ 0.000000] ACPI: LAPIC (acpi_id[0x0d] lapic_id[0x8c] disabled) 2011 Sep 23 14:45:41 kernel: [ 0.000000] ACPI: LAPIC (acpi_id[0x0e] lapic_id[0x8d] disabled) 2011 Sep 23 14:45:41 kernel: [ 0.000000] ACPI: LAPIC (acpi_id[0x0f] lapic_id[0x8e] disabled) 2011 Sep 23 14:45:41 kernel: [ 0.000000] ACPI: LAPIC (acpi_id[0x10] lapic_id[0x8f] disabled) 2011 Sep 23 14:45:41 kernel: [ 0.000000] ACPI: LAPIC (acpi_id[0x11] lapic_id[0x90] disabled) 2011 Sep 23 14:45:41 kernel: [ 0.000000] ACPI: LAPIC (acpi_id[0x12] lapic_id[0x91] disabled) 2011 Sep 23 14:45:41 kernel: [ 0.000000] ACPI: LAPIC (acpi_id[0x13] lapic_id[0x92] disabled) 2011 Sep 23 14:45:41 kernel: [ 0.000000] ACPI: LAPIC (acpi_id[0x14] lapic_id[0x93] disabled) 2011 Sep 23 14:45:41 kernel: [ 0.000000] ACPI: LAPIC (acpi_id[0x15] lapic_id[0x94] disabled) 2011 Sep 23 14:45:41 kernel: [ 0.000000] ACPI: LAPIC (acpi_id[0x16] lapic_id[0x95] disabled) 2011 Sep 23 14:45:41 kernel: [ 0.000000] ACPI: LAPIC (acpi_id[0x17] lapic_id[0x96] disabled) 2011 Sep 23 14:45:41 kernel: [ 0.000000] ACPI: LAPIC (acpi_id[0x18] lapic_id[0x97] disabled) 2011 Sep 23 14:45:41 kernel: [ 0.000000] ACPI: LAPIC_NMI (acpi_id[0xff] dfl dfl lint[0x1]) 2011 Sep 23 14:45:41 kernel: [ 0.000000] ACPI: IOAPIC (id[0x01] address[0xfec00000] gsi_base[0]) 2011 Sep 23 14:45:41 kernel: [ 0.000000] IOAPIC[0]: apic_id 1, version 255, address 0xfec00000, GSI 0-255 2011 Sep 23 14:45:41 kernel: [ 0.000000] ACPI: IOAPIC (id[0x03] address[0xfec8a000] gsi_base[24]) 2011 Sep 23 14:45:41 kernel: [ 0.000000] IOAPIC[1]: apic_id 3, version 255, address 0xfec8a000, GSI 24-279 2011 Sep 23 14:45:41 kernel: [ 0.000000] ACPI: INT_SRC_OVR (bus 0 bus_irq 0 global_irq 2 dfl dfl) 2011 Sep 23 14:45:41 kernel: [ 0.000000] ACPI: INT_SRC_OVR (bus 0 bus_irq 9 global_irq 9 high level) 2011 Sep 23 14:45:41 kernel: [ 0.000000] ACPI: IRQ0 used by override. 2011 Sep 23 14:45:41 kernel: [ 0.000000] ACPI: IRQ2 used by override. 2011 Sep 23 14:45:41 kernel: [ 0.000000] ACPI: IRQ9 used by override. 2011 Sep 23 14:45:41 kernel: [ 0.000000] Using ACPI (MADT) for SMP configuration information 2011 Sep 23 14:45:41 kernel: [ 0.000000] ACPI: HPET id: 0x8086a301 base: 0xfed00000 2011 Sep 23 14:45:41 kernel: [ 0.000000] 24 Processors exceeds NR_CPUS limit of 8 2011 Sep 23 14:45:41 kernel: [ 0.000000] SMP: Allowing 8 CPUs, 4 hotplug CPUs 2011 Sep 23 14:45:41 kernel: [ 0.000000] nr_irqs_gsi: 296 2011 Sep 23 14:45:41 kernel: [ 0.000000] PM: Registered nosave memory: 0000000000099000 - 000000000009a000 2011 Sep 23 14:45:41 kernel: [ 0.000000] PM: Registered nosave memory: 000000000009a000 - 0000000000100000 2011 Sep 23 14:45:41 kernel: [ 0.000000] Allocating PCI resources starting at c0000000 (gap: c0000000:20000000) 2011 Sep 23 14:45:41 kernel: [ 0.000000] Booting paravirtualized kernel on Xen 2011 Sep 23 14:45:41 kernel: [ 0.000000] Xen version: 4.1.1 (preserve-AD) 2011 Sep 23 14:45:41 kernel: [ 0.000000] setup_percpu: NR_CPUS:8 nr_cpumask_bits:8 nr_cpu_ids:8 nr_node_ids:1 2011 Sep 23 14:45:41 kernel: [ 0.000000] PERCPU: Embedded 12 pages/cpu @e5d82000 s28352 r0 d20800 u49152 2011 Sep 23 14:45:41 kernel: [ 0.000000] pcpu-alloc: s28352 r0 d20800 u49152 alloc=12*4096 2011 Sep 23 14:45:41 kernel: [ 0.000000] pcpu-alloc: [0] 0 [0] 1 [0] 2 [0] 3 [0] 4 [0] 5 [0] 6 [0] 7 2011 Sep 23 14:45:41 kernel: [ 2.841935] Built 1 zonelists in Zone order, mobility grouping on. Total pages: 3572352 2011 Sep 23 14:45:41 kernel: [ 2.841941] Kernel command line: boot_media=loop-disk boot_volume="/dev/sd?1" boot_volume_id=59e069103c926191 boot_mode=setup-automatic debug loglevel=8 2011 Sep 23 14:45:41 kernel: [ 2.842012] PID hash table entries: 4096 (order: 2, 16384 bytes) 2011 Sep 23 14:45:41 kernel: [ 2.842086] Dentry cache hash table entries: 131072 (order: 7, 524288 bytes) 2011 Sep 23 14:45:41 kernel: [ 2.842298] Inode-cache hash table entries: 65536 (order: 6, 262144 bytes) 2011 Sep 23 14:45:41 kernel: [ 2.842570] Initializing CPU#0 2011 Sep 23 14:45:41 kernel: [ 2.865142] allocated 61871776 bytes of page_cgroup 2011 Sep 23 14:45:41 kernel: [ 2.865148] please try 'cgroup_disable=memory' option if you don't want memory cgroups 2011 Sep 23 14:45:41 kernel: [ 2.896399] Placing 64MB software IO TLB between de1bc000 - e21bc000 2011 Sep 23 14:45:41 kernel: [ 2.896404] software IO TLB at phys 0x1e1bc000 - 0x221bc000 2011 Sep 23 14:45:41 kernel: [ 2.922211] Initializing HighMem for node 0 (0002d3fe:003b017a) 2011 Sep 23 14:45:41 kernel: [ 4.299397] Memory: 14126856k/15468008k available (5077k kernel code, 283396k reserved, 2334k data, 676k init, 13669360k highmem) 2011 Sep 23 14:45:41 kernel: [ 4.299406] virtual kernel memory layout: 2011 Sep 23 14:45:41 kernel: [ 4.299407] fixmap : 0xf5716000 - 0xf57ff000 ( 932 kB) 2011 Sep 23 14:45:41 kernel: [ 4.299409] pkmap : 0xf5400000 - 0xf5600000 (2048 kB) 2011 Sep 23 14:45:41 kernel: [ 4.299410] vmalloc : 0xedbfe000 - 0xf53fe000 ( 120 MB) 2011 Sep 23 14:45:41 kernel: [ 4.299411] lowmem : 0xc0000000 - 0xed3fe000 ( 723 MB) 2011 Sep 23 14:45:41 kernel: [ 4.299412] .init : 0xc173e000 - 0xc17e7000 ( 676 kB) 2011 Sep 23 14:45:41 kernel: [ 4.299414] .data : 0xc14f5620 - 0xc173d180 (2334 kB) 2011 Sep 23 14:45:41 kernel: [ 4.299415] .text : 0xc1000000 - 0xc14f5620 (5077 kB) 2011 Sep 23 14:45:41 kernel: [ 4.299478] SLUB: Genslabs=15, HWalign=64, Order=0-3, MinObjects=0, CPUs=8, Nodes=1 2011 Sep 23 14:45:41 kernel: [ 4.299516] Hierarchical RCU implementation. 2011 Sep 23 14:45:41 kernel: [ 4.299519] RCU dyntick-idle grace-period acceleration is enabled. 2011 Sep 23 14:45:41 kernel: [ 4.299530] NR_IRQS:2304 nr_irqs:2048 16 2011 Sep 23 14:45:41 kernel: [ 4.299577] CPU 0 irqstacks, hard=ddc0a000 soft=ddc0c000 2011 Sep 23 14:45:41 kernel: [ 4.299582] xen: sci override: global_irq=9 trigger=0 polarity=0 2011 Sep 23 14:45:41 kernel: [ 4.299587] xen: registering gsi 9 triggering 0 polarity 0 2011 Sep 23 14:45:41 kernel: [ 4.299596] xen: --> pirq=9 -> irq=9 (gsi=9) 2011 Sep 23 14:45:41 kernel: [ 4.299607] xen: acpi sci 9 2011 Sep 23 14:45:41 kernel: [ 4.299612] xen: --> pirq=1 -> irq=1 (gsi=1) 2011 Sep 23 14:45:41 kernel: [ 4.299618] xen: --> pirq=2 -> irq=2 (gsi=2) 2011 Sep 23 14:45:41 kernel: [ 4.299623] xen: --> pirq=3 -> irq=3 (gsi=3) 2011 Sep 23 14:45:41 kernel: [ 4.299629] xen: --> pirq=4 -> irq=4 (gsi=4) 2011 Sep 23 14:45:41 kernel: [ 4.299634] xen: --> pirq=5 -> irq=5 (gsi=5) 2011 Sep 23 14:45:41 kernel: [ 4.299639] xen: --> pirq=6 -> irq=6 (gsi=6) 2011 Sep 23 14:45:41 kernel: [ 4.299644] xen: --> pirq=7 -> irq=7 (gsi=7) 2011 Sep 23 14:45:41 kernel: [ 4.299650] xen: --> pirq=8 -> irq=8 (gsi=8) 2011 Sep 23 14:45:41 kernel: [ 4.299653] xen_map_pirq_gsi: returning irq 9 for gsi 9 2011 Sep 23 14:45:41 kernel: [ 4.299656] xen: --> pirq=9 -> irq=9 (gsi=9) 2011 Sep 23 14:45:41 kernel: [ 4.299662] xen: --> pirq=10 -> irq=10 (gsi=10) 2011 Sep 23 14:45:41 kernel: [ 4.299667] xen: --> pirq=11 -> irq=11 (gsi=11) 2011 Sep 23 14:45:41 kernel: [ 4.299673] xen: --> pirq=12 -> irq=12 (gsi=12) 2011 Sep 23 14:45:41 kernel: [ 4.299678] xen: --> pirq=13 -> irq=13 (gsi=13) 2011 Sep 23 14:45:41 kernel: [ 4.299683] xen: --> pirq=14 -> irq=14 (gsi=14) 2011 Sep 23 14:45:41 kernel: [ 4.299689] xen: --> pirq=15 -> irq=15 (gsi=15) 2011 Sep 23 14:45:41 kernel: [ 4.301776] Console: colour VGA+ 80x25 2011 Sep 23 14:45:41 kernel: [ 4.314614] console [tty0] enabled 2011 Sep 23 14:45:41 kernel: [ 4.314691] Xen: using vcpuop timer interface 2011 Sep 23 14:45:41 kernel: [ 4.314755] installing Xen timer for CPU 0 2011 Sep 23 14:45:41 kernel: [ 4.314844] Detected 2266.816 MHz processor. 2011 Sep 23 14:45:41 kernel: [ 4.314907] Calibrating delay loop (skipped), value calculated using timer frequency.. 4533.63 BogoMIPS (lpj=9067264) 2011 Sep 23 14:45:41 kernel: [ 4.315031] pid_max: default: 32768 minimum: 301 2011 Sep 23 14:45:41 kernel: [ 4.315151] Mount-cache hash table entries: 512 2011 Sep 23 14:45:41 kernel: [ 4.315358] Initializing cgroup subsys cpuacct 2011 Sep 23 14:45:41 kernel: [ 4.315423] Initializing cgroup subsys memory 2011 Sep 23 14:45:41 kernel: [ 4.315492] Initializing cgroup subsys devices 2011 Sep 23 14:45:41 kernel: [ 4.315553] Initializing cgroup subsys freezer 2011 Sep 23 14:45:41 kernel: [ 4.315613] Initializing cgroup subsys net_cls 2011 Sep 23 14:45:41 kernel: [ 4.315674] Initializing cgroup subsys blkio 2011 Sep 23 14:45:41 kernel: [ 4.315791] CPU: Physical Processor ID: 0 2011 Sep 23 14:45:41 kernel: [ 4.315851] CPU: Processor Core ID: 0 2011 Sep 23 14:45:41 kernel: [ 4.319456] ACPI: Core revision 20110413 2011 Sep 23 14:45:41 kernel: [ 4.350230] ftrace: allocating 21320 entries in 42 pages 2011 Sep 23 14:45:41 kernel: [ 4.356879] cpu 0 spinlock event irq 297 2011 Sep 23 14:45:41 kernel: [ 4.356978] Performance Events: unsupported p6 CPU model 26 no PMU driver, software events only. 2011 Sep 23 14:45:41 kernel: [ 4.357355] CPU 1 irqstacks, hard=ddcc0000 soft=ddcc2000 2011 Sep 23 14:45:41 kernel: [ 4.357420] installing Xen timer for CPU 1 2011 Sep 23 14:45:41 kernel: [ 4.357491] cpu 1 spinlock event irq 303 2011 Sep 23 14:45:41 kernel: [ 4.357602] Initializing CPU#1 2011 Sep 23 14:45:41 kernel: [ 4.357752] CPU 2 irqstacks, hard=ddcca000 soft=ddccc000 2011 Sep 23 14:45:41 kernel: [ 4.357871] installing Xen timer for CPU 2 2011 Sep 23 14:45:41 kernel: [ 4.357942] cpu 2 spinlock event irq 309 2011 Sep 23 14:45:41 kernel: [ 4.358048] Initializing CPU#2 2011 Sep 23 14:45:41 kernel: [ 4.358187] CPU 3 irqstacks, hard=ddcf4000 soft=ddcf6000 2011 Sep 23 14:45:41 kernel: [ 4.358304] installing Xen timer for CPU 3 2011 Sep 23 14:45:41 kernel: [ 4.358374] cpu 3 spinlock event irq 315 2011 Sep 23 14:45:41 kernel: [ 4.358475] Initializing CPU#3 2011 Sep 23 14:45:41 kernel: [ 4.358543] Brought up 4 CPUs 2011 Sep 23 14:45:41 kernel: [ 4.358812] devtmpfs: initialized 2011 Sep 23 14:45:41 kernel: [ 4.359237] PM: Registering ACPI NVS region at bf79e000 (204800 bytes) 2011 Sep 23 14:45:41 kernel: [ 4.360197] Grant table initialized 2011 Sep 23 14:45:41 kernel: [ 4.360298] print_constraints: dummy: 2011 Sep 23 14:45:41 kernel: [ 4.360392] Time: 14:45:37 Date: 09/23/11 2011 Sep 23 14:45:41 kernel: [ 4.360489] NET: Registered protocol family 16 2011 Sep 23 14:45:41 kernel: [ 4.360707] EISA bus registered 2011 Sep 23 14:45:41 kernel: [ 4.360798] ACPI: bus type pci registered 2011 Sep 23 14:45:41 kernel: [ 4.360925] PCI: MMCONFIG for domain 0000 [bus 00-ff] at [mem 0xe0000000-0xefffffff] (base 0xe0000000) 2011 Sep 23 14:45:41 kernel: [ 4.361013] PCI: MMCONFIG at [mem 0xe0000000-0xefffffff] reserved in E820 2011 Sep 23 14:45:41 kernel: [ 4.361078] PCI: Using MMCONFIG for extended config space 2011 Sep 23 14:45:41 kernel: [ 4.361140] PCI: Using configuration type 1 for base access 2011 Sep 23 14:45:41 kernel: [ 4.362089] bio: create slab <bio-0> at 0 2011 Sep 23 14:45:41 kernel: [ 4.387089] ACPI: EC: Look up EC in DSDT 2011 Sep 23 14:45:41 kernel: [ 4.387476] \_SB_:_OSC evaluation returned wrong type 2011 Sep 23 14:45:41 kernel: [ 4.387537] _OSC request data:1 7 2011 Sep 23 14:45:41 kernel: [ 4.392156] ACPI: Executed 1 blocks of module-level executable AML code 2011 Sep 23 14:45:41 kernel: [ 4.398564] ACPI: SSDT bf79e0d0 009F8 (v01 DpgPmm P001Ist 00000011 INTL 20051117) 2011 Sep 23 14:45:41 kernel: [ 4.399920] ACPI: Dynamic OEM Table Load: 2011 Sep 23 14:45:41 kernel: [ 4.400045] ACPI: SSDT (null) 009F8 (v01 DpgPmm P001Ist 00000011 INTL 20051117) 2011 Sep 23 14:45:41 kernel: [ 4.400412] ACPI: SSDT bf79ead0 004D5 (v01 PmRef P001Cst 00003001 INTL 20051117) 2011 Sep 23 14:45:41 kernel: [ 4.401718] ACPI: Dynamic OEM Table Load: 2011 Sep 23 14:45:41 kernel: [ 4.401843] ACPI: SSDT (null) 004D5 (v01 PmRef P001Cst 00003001 INTL 20051117) 2011 Sep 23 14:45:41 kernel: [ 4.402711] ACPI: Interpreter enabled 2011 Sep 23 14:45:41 kernel: [ 4.402774] ACPI: (supports S0 S1 S4 S5) 2011 Sep 23 14:45:41 kernel: [ 4.402985] ACPI: Using IOAPIC for interrupt routing 2011 Sep 23 14:45:41 kernel: [ 4.415316] ACPI: No dock devices found. 2011 Sep 23 14:45:41 kernel: [ 4.415418] HEST: Table parsing has been initialized. 2011 Sep 23 14:45:41 kernel: [ 4.415481] PCI: Using host bridge windows from ACPI; if necessary, use "pci=nocrs" and report a bug 2011 Sep 23 14:45:41 kernel: [ 4.415732] ACPI: PCI Root Bridge [PCI0] (domain 0000 [bus 00-ff]) 2011 Sep 23 14:45:41 kernel: [ 4.416091] pci_root PNP0A08:00: host bridge window [io 0x0000-0x03af] 2011 Sep 23 14:45:41 kernel: [ 4.416158] pci_root PNP0A08:00: host bridge window [io 0x03e0-0x0cf7] 2011 Sep 23 14:45:41 kernel: [ 4.416223] pci_root PNP0A08:00: host bridge window [io 0x03b0-0x03bb] 2011 Sep 23 14:45:41 kernel: [ 4.416288] pci_root PNP0A08:00: host bridge window [io 0x03c0-0x03df] 2011 Sep 23 14:45:41 kernel: [ 4.416353] pci_root PNP0A08:00: host bridge window [io 0x0d00-0xefff] 2011 Sep 23 14:45:41 kernel: [ 4.416420] pci_root PNP0A08:00: host bridge window [io 0xf000-0xffff] 2011 Sep 23 14:45:41 kernel: [ 4.416485] pci_root PNP0A08:00: host bridge window [mem 0x000a0000-0x000bffff] 2011 Sep 23 14:45:41 kernel: [ 4.416571] pci_root PNP0A08:00: host bridge window [mem 0x000d0000-0x000dffff] 2011 Sep 23 14:45:41 kernel: [ 4.416654] pci_root PNP0A08:00: host bridge window [mem 0xc0000000-0xdfffffff] 2011 Sep 23 14:45:41 kernel: [ 4.416737] pci_root PNP0A08:00: host bridge window [mem 0xf0000000-0xfed8ffff] 2011 Sep 23 14:45:41 kernel: [ 4.416821] pci_root PNP0A08:00: host bridge window [mem 0xfed40000-0xfed44fff] 2011 Sep 23 14:45:41 kernel: [ 4.416906] pci_root PNP0A08:00: host bridge window expanded to [mem 0xf0000000-0xfed8ffff]; [mem 0xfed40000-0xfed44fff] ignored 2011 Sep 23 14:45:41 kernel: [ 4.417025] pci 0000:00:00.0: [8086:3403] type 0 class 0x000600 2011 Sep 23 14:45:41 kernel: [ 4.417208] pci 0000:00:00.0: PME# supported from D0 D3hot D3cold 2011 Sep 23 14:45:41 kernel: [ 4.417276] pci 0000:00:00.0: PME# disabled 2011 Sep 23 14:45:41 kernel: [ 4.417390] pci 0000:00:01.0: [8086:3408] type 1 class 0x000604 2011 Sep 23 14:45:41 kernel: [ 4.417576] pci 0000:00:01.0: PME# supported from D0 D3hot D3cold 2011 Sep 23 14:45:41 kernel: [ 4.417644] pci 0000:00:01.0: PME# disabled 2011 Sep 23 14:45:41 kernel: [ 4.417761] pci 0000:00:03.0: [8086:340a] type 1 class 0x000604 2011 Sep 23 14:45:41 kernel: [ 4.417945] pci 0000:00:03.0: PME# supported from D0 D3hot D3cold 2011 Sep 23 14:45:41 kernel: [ 4.418014] pci 0000:00:03.0: PME# disabled 2011 Sep 23 14:45:41 kernel: [ 4.418134] pci 0000:00:07.0: [8086:340e] type 1 class 0x000604 2011 Sep 23 14:45:41 kernel: [ 4.418319] pci 0000:00:07.0: PME# supported from D0 D3hot D3cold 2011 Sep 23 14:45:41 kernel: [ 4.418387] pci 0000:00:07.0: PME# disabled 2011 Sep 23 14:45:41 kernel: [ 4.418503] pci 0000:00:09.0: [8086:3410] type 1 class 0x000604 2011 Sep 23 14:45:41 kernel: [ 4.418688] pci 0000:00:09.0: PME# supported from D0 D3hot D3cold 2011 Sep 23 14:45:41 kernel: [ 4.418757] pci 0000:00:09.0: PME# disabled 2011 Sep 23 14:45:41 kernel: [ 4.418872] pci 0000:00:13.0: [8086:342d] type 0 class 0x000800 2011 Sep 23 14:45:41 kernel: [ 4.418959] pci 0000:00:13.0: reg 10: [mem 0xfec8a000-0xfec8afff] 2011 Sep 23 14:45:41 kernel: [ 4.419136] pci 0000:00:13.0: PME# supported from D0 D3hot D3cold 2011 Sep 23 14:45:41 kernel: [ 4.419204] pci 0000:00:13.0: PME# disabled 2011 Sep 23 14:45:41 kernel: [ 4.419302] pci 0000:00:14.0: [8086:342e] type 0 class 0x000800 2011 Sep 23 14:45:41 kernel: [ 4.419531] pci 0000:00:14.1: [8086:3422] type 0 class 0x000800 2011 Sep 23 14:45:41 kernel: [ 4.419756] pci 0000:00:14.2: [8086:3423] type 0 class 0x000800 2011 Sep 23 14:45:41 kernel: [ 4.419977] pci 0000:00:14.3: [8086:3438] type 0 class 0x000800 2011 Sep 23 14:45:41 kernel: [ 4.420190] pci 0000:00:16.0: [8086:3430] type 0 class 0x000880 2011 Sep 23 14:45:41 kernel: [ 4.420286] pci 0000:00:16.0: reg 10: [mem 0xfbef8000-0xfbefbfff 64bit] 2011 Sep 23 14:45:41 kernel: [ 4.420510] pci 0000:00:16.1: [8086:3431] type 0 class 0x000880 2011 Sep 23 14:45:41 kernel: [ 4.420605] pci 0000:00:16.1: reg 10: [mem 0xfbef4000-0xfbef7fff 64bit] 2011 Sep 23 14:45:41 kernel: [ 4.420829] pci 0000:00:16.2: [8086:3432] type 0 class 0x000880 2011 Sep 23 14:45:41 kernel: [ 4.420924] pci 0000:00:16.2: reg 10: [mem 0xfbef0000-0xfbef3fff 64bit] 2011 Sep 23 14:45:41 kernel: [ 4.421148] pci 0000:00:16.3: [8086:3433] type 0 class 0x000880 2011 Sep 23 14:45:41 kernel: [ 4.421243] pci 0000:00:16.3: reg 10: [mem 0xfbeec000-0xfbeeffff 64bit] 2011 Sep 23 14:45:41 kernel: [ 4.421467] pci 0000:00:16.4: [8086:3429] type 0 class 0x000880 2011 Sep 23 14:45:41 kernel: [ 4.421563] pci 0000:00:16.4: reg 10: [mem 0xfbee8000-0xfbeebfff 64bit] 2011 Sep 23 14:45:41 kernel: [ 4.421787] pci 0000:00:16.5: [8086:342a] type 0 class 0x000880 2011 Sep 23 14:45:41 kernel: [ 4.421882] pci 0000:00:16.5: reg 10: [mem 0xfbee4000-0xfbee7fff 64bit] 2011 Sep 23 14:45:41 kernel: [ 4.422106] pci 0000:00:16.6: [8086:342b] type 0 class 0x000880 2011 Sep 23 14:45:41 kernel: [ 4.422201] pci 0000:00:16.6: reg 10: [mem 0xfbee0000-0xfbee3fff 64bit] 2011 Sep 23 14:45:41 kernel: [ 4.422428] pci 0000:00:16.7: [8086:342c] type 0 class 0x000880 2011 Sep 23 14:45:41 kernel: [ 4.422524] pci 0000:00:16.7: reg 10: [mem 0xfbedc000-0xfbedffff 64bit] 2011 Sep 23 14:45:41 kernel: [ 4.422752] pci 0000:00:1a.0: [8086:3a37] type 0 class 0x000c03 2011 Sep 23 14:45:41 kernel: [ 4.422910] pci 0000:00:1a.0: reg 20: [io 0xcc00-0xcc1f] 2011 Sep 23 14:45:41 kernel: [ 4.423066] pci 0000:00:1a.1: [8086:3a38] type 0 class 0x000c03 2011 Sep 23 14:45:41 kernel: [ 4.423218] pci 0000:00:1a.1: reg 20: [io 0xc880-0xc89f] 2011 Sep 23 14:45:41 kernel: [ 4.423375] pci 0000:00:1a.2: [8086:3a39] type 0 class 0x000c03 2011 Sep 23 14:45:41 kernel: [ 4.423532] pci 0000:00:1a.2: reg 20: [io 0xc800-0xc81f] 2011 Sep 23 14:45:41 kernel: [ 4.423707] pci 0000:00:1a.7: [8086:3a3c] type 0 class 0x000c03 2011 Sep 23 14:45:41 kernel: [ 4.423812] pci 0000:00:1a.7: reg 10: [mem 0xfbeda000-0xfbeda3ff] 2011 Sep 23 14:45:41 kernel: [ 4.424030] pci 0000:00:1a.7: PME# supported from D0 D3hot D3cold 2011 Sep 23 14:45:41 kernel: [ 4.424099] pci 0000:00:1a.7: PME# disabled 2011 Sep 23 14:45:41 kernel: [ 4.424204] pci 0000:00:1b.0: [8086:3a3e] type 0 class 0x000403 2011 Sep 23 14:45:41 kernel: [ 4.424302] pci 0000:00:1b.0: reg 10: [mem 0xfbed4000-0xfbed7fff 64bit] 2011 Sep 23 14:45:41 kernel: [ 4.424493] pci 0000:00:1b.0: PME# supported from D0 D3hot D3cold 2011 Sep 23 14:45:41 kernel: [ 4.424561] pci 0000:00:1b.0: PME# disabled 2011 Sep 23 14:45:41 kernel: [ 4.424662] pci 0000:00:1c.0: [8086:3a40] type 1 class 0x000604 2011 Sep 23 14:45:41 kernel: [ 4.424857] pci 0000:00:1c.0: PME# supported from D0 D3hot D3cold 2011 Sep 23 14:45:41 kernel: [ 4.424926] pci 0000:00:1c.0: PME# disabled 2011 Sep 23 14:45:41 kernel: [ 4.425037] pci 0000:00:1c.4: [8086:3a48] type 1 class 0x000604 2011 Sep 23 14:45:41 kernel: [ 4.425232] pci 0000:00:1c.4: PME# supported from D0 D3hot D3cold 2011 Sep 23 14:45:41 kernel: [ 4.425300] pci 0000:00:1c.4: PME# disabled 2011 Sep 23 14:45:41 kernel: [ 4.425407] pci 0000:00:1c.5: [8086:3a4a] type 1 class 0x000604 2011 Sep 23 14:45:41 kernel: [ 4.425602] pci 0000:00:1c.5: PME# supported from D0 D3hot D3cold 2011 Sep 23 14:45:41 kernel: [ 4.425670] pci 0000:00:1c.5: PME# disabled 2011 Sep 23 14:45:41 kernel: [ 4.425780] pci 0000:00:1d.0: [8086:3a34] type 0 class 0x000c03 2011 Sep 23 14:45:41 kernel: [ 4.425938] pci 0000:00:1d.0: reg 20: [io 0xc480-0xc49f] 2011 Sep 23 14:45:41 kernel: [ 4.426093] pci 0000:00:1d.1: [8086:3a35] type 0 class 0x000c03 2011 Sep 23 14:45:41 kernel: [ 4.426250] pci 0000:00:1d.1: reg 20: [io 0xc400-0xc41f] 2011 Sep 23 14:45:41 kernel: [ 4.426405] pci 0000:00:1d.2: [8086:3a36] type 0 class 0x000c03 2011 Sep 23 14:45:41 kernel: [ 4.426562] pci 0000:00:1d.2: reg 20: [io 0xc080-0xc09f] 2011 Sep 23 14:45:41 kernel: [ 4.426739] pci 0000:00:1d.7: [8086:3a3a] type 0 class 0x000c03 2011 Sep 23 14:45:41 kernel: [ 4.426844] pci 0000:00:1d.7: reg 10: [mem 0xfbed8000-0xfbed83ff] 2011 Sep 23 14:45:41 kernel: [ 4.427063] pci 0000:00:1d.7: PME# supported from D0 D3hot D3cold 2011 Sep 23 14:45:41 kernel: [ 4.427132] pci 0000:00:1d.7: PME# disabled 2011 Sep 23 14:45:41 kernel: [ 4.427228] pci 0000:00:1e.0: [8086:244e] type 1 class 0x000604 2011 Sep 23 14:45:41 kernel: [ 4.427414] pci 0000:00:1f.0: [8086:3a16] type 0 class 0x000601 2011 Sep 23 14:45:41 kernel: [ 4.427621] pci 0000:00:1f.0: ICH7 LPC Generic IO decode 1 PIO at 0a00 (mask 00ff) 2011 Sep 23 14:45:41 kernel: [ 4.429093] pci 0000:00:1f.0: ICH7 LPC Generic IO decode 2 PIO at 4700 (mask 00ff) 2011 Sep 23 14:45:41 kernel: [ 4.429182] pci 0000:00:1f.0: ICH7 LPC Generic IO decode 4 PIO at 0ca0 (mask 000f) 2011 Sep 23 14:45:41 kernel: [ 4.429337] pci 0000:00:1f.2: [8086:3a20] type 0 class 0x000101 2011 Sep 23 14:45:41 kernel: [ 4.429434] pci 0000:00:1f.2: reg 10: [io 0xc000-0xc007] 2011 Sep 23 14:45:41 kernel: [ 4.429512] pci 0000:00:1f.2: reg 14: [io 0xbc00-0xbc03] 2011 Sep 23 14:45:41 kernel: [ 4.429590] pci 0000:00:1f.2: reg 18: [io 0xb880-0xb887] 2011 Sep 23 14:45:41 kernel: [ 4.429668] pci 0000:00:1f.2: reg 1c: [io 0xb800-0xb803] 2011 Sep 23 14:45:41 kernel: [ 4.429745] pci 0000:00:1f.2: reg 20: [io 0xb480-0xb48f] 2011 Sep 23 14:45:41 kernel: [ 4.429823] pci 0000:00:1f.2: reg 24: [io 0xb400-0xb40f] 2011 Sep 23 14:45:41 kernel: [ 4.429968] pci 0000:00:1f.3: [8086:3a30] type 0 class 0x000c05 2011 Sep 23 14:45:41 kernel: [ 4.430063] pci 0000:00:1f.3: reg 10: [mem 0xfbed2000-0xfbed20ff 64bit] 2011 Sep 23 14:45:41 kernel: [ 4.430175] pci 0000:00:1f.3: reg 20: [io 0x0400-0x041f] 2011 Sep 23 14:45:41 kernel: [ 4.430306] pci 0000:00:1f.5: [8086:3a26] type 0 class 0x000101 2011 Sep 23 14:45:41 kernel: [ 4.430403] pci 0000:00:1f.5: reg 10: [io 0xb000-0xb007] 2011 Sep 23 14:45:41 kernel: [ 4.430481] pci 0000:00:1f.5: reg 14: [io 0xac00-0xac03] 2011 Sep 23 14:45:41 kernel: [ 4.430559] pci 0000:00:1f.5: reg 18: [io 0xa880-0xa887] 2011 Sep 23 14:45:41 kernel: [ 4.430637] pci 0000:00:1f.5: reg 1c: [io 0xa800-0xa803] 2011 Sep 23 14:45:41 kernel: [ 4.430714] pci 0000:00:1f.5: reg 20: [io 0xa480-0xa48f] 2011 Sep 23 14:45:41 kernel: [ 4.430792] pci 0000:00:1f.5: reg 24: [io 0xa400-0xa40f] 2011 Sep 23 14:45:41 kernel: [ 4.431022] pci 0000:00:01.0: PCI bridge to [bus 01-01] 2011 Sep 23 14:45:41 kernel: [ 4.431089] pci 0000:00:01.0: bridge window [io 0xf000-0x0000] (disabled) 2011 Sep 23 14:45:41 kernel: [ 4.431159] pci 0000:00:01.0: bridge window [mem 0xfff00000-0x000fffff] (disabled) 2011 Sep 23 14:45:41 kernel: [ 4.431252] pci 0000:00:01.0: bridge window [mem 0xfff00000-0x000fffff pref] (disabled) 2011 Sep 23 14:45:41 kernel: [ 4.431429] pci 0000:00:03.0: PCI bridge to [bus 02-02] 2011 Sep 23 14:45:41 kernel: [ 4.431496] pci 0000:00:03.0: bridge window [io 0xf000-0x0000] (disabled) 2011 Sep 23 14:45:41 kernel: [ 4.431566] pci 0000:00:03.0: bridge window [mem 0xfff00000-0x000fffff] (disabled) 2011 Sep 23 14:45:41 kernel: [ 4.431659] pci 0000:00:03.0: bridge window [mem 0xfff00000-0x000fffff pref] (disabled) 2011 Sep 23 14:45:41 kernel: [ 4.431837] pci 0000:00:07.0: PCI bridge to [bus 03-03] 2011 Sep 23 14:45:41 kernel: [ 4.431903] pci 0000:00:07.0: bridge window [io 0xf000-0x0000] (disabled) 2011 Sep 23 14:45:41 kernel: [ 4.431973] pci 0000:00:07.0: bridge window [mem 0xfff00000-0x000fffff] (disabled) 2011 Sep 23 14:45:41 kernel: [ 4.432066] pci 0000:00:07.0: bridge window [mem 0xfff00000-0x000fffff pref] (disabled) 2011 Sep 23 14:45:41 kernel: [ 4.432243] pci 0000:00:09.0: PCI bridge to [bus 04-04] 2011 Sep 23 14:45:41 kernel: [ 4.432310] pci 0000:00:09.0: bridge window [io 0xf000-0x0000] (disabled) 2011 Sep 23 14:45:41 kernel: [ 4.432380] pci 0000:00:09.0: bridge window [mem 0xfff00000-0x000fffff] (disabled) 2011 Sep 23 14:45:41 kernel: [ 4.432472] pci 0000:00:09.0: bridge window [mem 0xfff00000-0x000fffff pref] (disabled) 2011 Sep 23 14:45:41 kernel: [ 4.432648] pci 0000:00:1c.0: PCI bridge to [bus 05-05] 2011 Sep 23 14:45:41 kernel: [ 4.432715] pci 0000:00:1c.0: bridge window [io 0xf000-0x0000] (disabled) 2011 Sep 23 14:45:41 kernel: [ 4.432785] pci 0000:00:1c.0: bridge window [mem 0xfff00000-0x000fffff] (disabled) 2011 Sep 23 14:45:41 kernel: [ 4.432878] pci 0000:00:1c.0: bridge window [mem 0xfff00000-0x000fffff pref] (disabled) 2011 Sep 23 14:45:41 kernel: [ 4.433092] pci 0000:06:00.0: [8086:10d3] type 0 class 0x000200 2011 Sep 23 14:45:41 kernel: [ 4.433194] pci 0000:06:00.0: reg 10: [mem 0xfbce0000-0xfbcfffff] 2011 Sep 23 14:45:41 kernel: [ 4.433308] pci 0000:06:00.0: reg 18: [io 0xdc00-0xdc1f] 2011 Sep 23 14:45:41 kernel: [ 4.433395] pci 0000:06:00.0: reg 1c: [mem 0xfbcdc000-0xfbcdffff] 2011 Sep 23 14:45:41 kernel: [ 4.433612] pci 0000:06:00.0: PME# supported from D0 D3hot D3cold 2011 Sep 23 14:45:41 kernel: [ 4.433684] pci 0000:06:00.0: PME# disabled 2011 Sep 23 14:45:41 kernel: [ 4.441741] pci 0000:00:1c.4: PCI bridge to [bus 06-06] 2011 Sep 23 14:45:41 kernel: [ 4.441816] pci 0000:00:1c.4: bridge window [io 0xd000-0xdfff] 2011 Sep 23 14:45:41 kernel: [ 4.441885] pci 0000:00:1c.4: bridge window [mem 0xfbc00000-0xfbcfffff] 2011 Sep 23 14:45:41 kernel: [ 4.441959] pci 0000:00:1c.4: bridge window [mem 0xfff00000-0x000fffff pref] (disabled) 2011 Sep 23 14:45:41 kernel: [ 4.442174] pci 0000:07:00.0: [8086:10d3] type 0 class 0x000200 2011 Sep 23 14:45:41 kernel: [ 4.442277] pci 0000:07:00.0: reg 10: [mem 0xfbde0000-0xfbdfffff] 2011 Sep 23 14:45:41 kernel: [ 4.442390] pci 0000:07:00.0: reg 18: [io 0xec00-0xec1f] 2011 Sep 23 14:45:41 kernel: [ 4.442477] pci 0000:07:00.0: reg 1c: [mem 0xfbddc000-0xfbddffff] 2011 Sep 23 14:45:41 kernel: [ 4.442697] pci 0000:07:00.0: PME# supported from D0 D3hot D3cold 2011 Sep 23 14:45:41 kernel: [ 4.442768] pci 0000:07:00.0: PME# disabled 2011 Sep 23 14:45:41 kernel: [ 4.449849] pci 0000:00:1c.5: PCI bridge to [bus 07-07] 2011 Sep 23 14:45:41 kernel: [ 4.449922] pci 0000:00:1c.5: bridge window [io 0xe000-0xefff] 2011 Sep 23 14:45:41 kernel: [ 4.449991] pci 0000:00:1c.5: bridge window [mem 0xfbd00000-0xfbdfffff] 2011 Sep 23 14:45:41 kernel: [ 4.450065] pci 0000:00:1c.5: bridge window [mem 0xfff00000-0x000fffff pref] (disabled) 2011 Sep 23 14:45:41 kernel: [ 4.450218] pci 0000:08:01.0: [102b:0532] type 0 class 0x000300 2011 Sep 23 14:45:41 kernel: [ 4.450313] pci 0000:08:01.0: reg 10: [mem 0xf9000000-0xf9ffffff pref] 2011 Sep 23 14:45:41 kernel: [ 4.450395] pci 0000:08:01.0: reg 14: [mem 0xfaffc000-0xfaffffff] 2011 Sep 23 14:45:41 kernel: [ 4.450476] pci 0000:08:01.0: reg 18: [mem 0xfb000000-0xfb7fffff] 2011 Sep 23 14:45:41 kernel: [ 4.450727] pci 0000:00:1e.0: PCI bridge to [bus 08-08] (subtractive decode) 2011 Sep 23 14:45:41 kernel: [ 4.450798] pci 0000:00:1e.0: bridge window [io 0xf000-0x0000] (disabled) 2011 Sep 23 14:45:41 kernel: [ 4.450869] pci 0000:00:1e.0: bridge window [mem 0xfaf00000-0xfb7fffff] 2011 Sep 23 14:45:41 kernel: [ 4.450943] pci 0000:00:1e.0: bridge window [mem 0xf9000000-0xf9ffffff 64bit pref] 2011 Sep 23 14:45:41 kernel: [ 4.451028] pci 0000:00:1e.0: bridge window [io 0x0000-0x03af] (subtractive decode) 2011 Sep 23 14:45:41 kernel: [ 4.451112] pci 0000:00:1e.0: bridge window [io 0x03e0-0x0cf7] (subtractive decode) 2011 Sep 23 14:45:41 kernel: [ 4.451197] pci 0000:00:1e.0: bridge window [io 0x03b0-0x03bb] (subtractive decode) 2011 Sep 23 14:45:41 kernel: [ 4.451282] pci 0000:00:1e.0: bridge window [io 0x03c0-0x03df] (subtractive decode) 2011 Sep 23 14:45:41 kernel: [ 4.451367] pci 0000:00:1e.0: bridge window [io 0x0d00-0xefff] (subtractive decode) 2011 Sep 23 14:45:41 kernel: [ 4.451451] pci 0000:00:1e.0: bridge window [io 0xf000-0xffff] (subtractive decode) 2011 Sep 23 14:45:41 kernel: [ 4.451536] pci 0000:00:1e.0: bridge window [mem 0x000a0000-0x000bffff] (subtractive decode) 2011 Sep 23 14:45:41 kernel: [ 4.451623] pci 0000:00:1e.0: bridge window [mem 0x000d0000-0x000dffff] (subtractive decode) 2011 Sep 23 14:45:41 kernel: [ 4.451709] pci 0000:00:1e.0: bridge window [mem 0xc0000000-0xdfffffff] (subtractive decode) 2011 Sep 23 14:45:41 kernel: [ 4.451795] pci 0000:00:1e.0: bridge window [mem 0xf0000000-0xfed8ffff] (subtractive decode) 2011 Sep 23 14:45:41 kernel: [ 4.451953] pci_bus 0000:00: on NUMA node 0 2011 Sep 23 14:45:41 kernel: [ 4.452014] ACPI: PCI Interrupt Routing Table [\_SB_.PCI0._PRT] 2011 Sep 23 14:45:41 kernel: [ 4.452362] ACPI: PCI Interrupt Routing Table [\_SB_.PCI0.NPE1._PRT] 2011 Sep 23 14:45:41 kernel: [ 4.452472] ACPI: PCI Interrupt Routing Table [\_SB_.PCI0.NPE3._PRT] 2011 Sep 23 14:45:41 kernel: [ 4.452590] ACPI: PCI Interrupt Routing Table [\_SB_.PCI0.NPE7._PRT] 2011 Sep 23 14:45:41 kernel: [ 4.452698] ACPI: PCI Interrupt Routing Table [\_SB_.PCI0.NPE9._PRT] 2011 Sep 23 14:45:41 kernel: [ 4.452806] ACPI: PCI Interrupt Routing Table [\_SB_.PCI0.P0P1._PRT] 2011 Sep 23 14:45:41 kernel: [ 4.453005] ACPI: PCI Interrupt Routing Table [\_SB_.PCI0.P0P4._PRT] 2011 Sep 23 14:45:41 kernel: [ 4.453123] ACPI: PCI Interrupt Routing Table [\_SB_.PCI0.P0P8._PRT] 2011 Sep 23 14:45:41 kernel: [ 4.453226] ACPI: PCI Interrupt Routing Table [\_SB_.PCI0.P0P9._PRT] 2011 Sep 23 14:45:41 kernel: [ 4.453334] pci0000:00: Requesting ACPI _OSC control (0x1d) 2011 Sep 23 14:45:41 kernel: [ 4.453399] pci0000:00: ACPI _OSC request failed (AE_NOT_FOUND), returned control mask: 0x1d 2011 Sep 23 14:45:41 kernel: [ 4.453484] ACPI _OSC control for PCIe not granted, disabling ASPM 2011 Sep 23 14:45:41 kernel: [ 4.484173] ACPI: PCI Interrupt Link [LNKA] (IRQs 3 4 6 7 10 *11 12 14 15) 2011 Sep 23 14:45:41 kernel: [ 4.484675] ACPI: PCI Interrupt Link [LNKB] (IRQs 3 4 6 7 *10 11 12 14 15) 2011 Sep 23 14:45:41 kernel: [ 4.485166] ACPI: PCI Interrupt Link [LNKC] (IRQs 3 4 6 7 10 11 12 14 *15) 2011 Sep 23 14:45:41 kernel: [ 4.485654] ACPI: PCI Interrupt Link [LNKD] (IRQs 3 4 6 7 10 11 12 *14 15) 2011 Sep 23 14:45:41 kernel: [ 4.486141] ACPI: PCI Interrupt Link [LNKE] (IRQs 3 4 6 7 10 11 12 14 15) *0, disabled. 2011 Sep 23 14:45:41 kernel: [ 4.486725] ACPI: PCI Interrupt Link [LNKF] (IRQs 3 4 6 *7 10 11 12 14 15) 2011 Sep 23 14:45:41 kernel: [ 4.487225] ACPI: PCI Interrupt Link [LNKG] (IRQs 3 4 *6 7 10 11 12 14 15) 2011 Sep 23 14:45:41 kernel: [ 4.487727] ACPI: PCI Interrupt Link [LNKH] (IRQs 3 4 6 7 *10 11 12 14 15) 2011 Sep 23 14:45:41 kernel: [ 4.488191] xen/balloon: Initialising balloon driver. 2011 Sep 23 14:45:41 kernel: [ 4.488254] last_pfn = 0x3b017a max_arch_pfn = 0x1000000 2011 Sep 23 14:45:41 kernel: [ 4.488328] xen-balloon: Initialising balloon driver. 2011 Sep 23 14:45:41 kernel: [ 4.488465] vgaarb: device added: PCI:0000:08:01.0,decodes=io+mem,owns=io+mem,locks=none 2011 Sep 23 14:45:41 kernel: [ 4.488551] vgaarb: loaded 2011 Sep 23 14:45:41 kernel: [ 4.488607] vgaarb: bridge control possible 0000:08:01.0 2011 Sep 23 14:45:41 kernel: [ 4.488809] SCSI subsystem initialized 2011 Sep 23 14:45:41 kernel: [ 4.488925] libata version 3.00 loaded. 2011 Sep 23 14:45:41 kernel: [ 4.489022] usbcore: registered new interface driver usbfs 2011 Sep 23 14:45:41 kernel: [ 4.489092] usbcore: registered new interface driver hub 2011 Sep 23 14:45:41 kernel: [ 4.489193] usbcore: registered new device driver usb 2011 Sep 23 14:45:41 kernel: [ 4.489342] PCI: Using ACPI for IRQ routing 2011 Sep 23 14:45:41 kernel: [ 4.502707] PCI: Discovered peer bus ff 2011 Sep 23 14:45:41 kernel: [ 4.502796] pci 0000:ff:00.0: [8086:2c40] type 0 class 0x000600 2011 Sep 23 14:45:41 kernel: [ 4.502935] pci 0000:ff:00.1: [8086:2c01] type 0 class 0x000600 2011 Sep 23 14:45:41 kernel: [ 4.503082] pci 0000:ff:02.0: [8086:2c10] type 0 class 0x000600 2011 Sep 23 14:45:41 kernel: [ 4.503219] pci 0000:ff:02.1: [8086:2c11] type 0 class 0x000600 2011 Sep 23 14:45:41 kernel: [ 4.503357] pci 0000:ff:02.4: [8086:2c14] type 0 class 0x000600 2011 Sep 23 14:45:41 kernel: [ 4.503492] pci 0000:ff:02.5: [8086:2c15] type 0 class 0x000600 2011 Sep 23 14:45:41 kernel: [ 4.503629] pci 0000:ff:03.0: [8086:2c18] type 0 class 0x000600 2011 Sep 23 14:45:41 kernel: [ 4.503764] pci 0000:ff:03.1: [8086:2c19] type 0 class 0x000600 2011 Sep 23 14:45:41 kernel: [ 4.503899] pci 0000:ff:03.2: [8086:2c1a] type 0 class 0x000600 2011 Sep 23 14:45:41 kernel: [ 4.504035] pci 0000:ff:03.4: [8086:2c1c] type 0 class 0x000600 2011 Sep 23 14:45:41 kernel: [ 4.504174] pci 0000:ff:04.0: [8086:2c20] type 0 class 0x000600 2011 Sep 23 14:45:41 kernel: [ 4.504308] pci 0000:ff:04.1: [8086:2c21] type 0 class 0x000600 2011 Sep 23 14:45:41 kernel: [ 4.504443] pci 0000:ff:04.2: [8086:2c22] type 0 class 0x000600 2011 Sep 23 14:45:41 kernel: [ 4.504578] pci 0000:ff:04.3: [8086:2c23] type 0 class 0x000600 2011 Sep 23 14:45:41 kernel: [ 4.504719] pci 0000:ff:05.0: [8086:2c28] type 0 class 0x000600 2011 Sep 23 14:45:41 kernel: [ 4.504853] pci 0000:ff:05.1: [8086:2c29] type 0 class 0x000600 2011 Sep 23 14:45:41 kernel: [ 4.504988] pci 0000:ff:05.2: [8086:2c2a] type 0 class 0x000600 2011 Sep 23 14:45:41 kernel: [ 4.505122] pci 0000:ff:05.3: [8086:2c2b] type 0 class 0x000600 2011 Sep 23 14:45:41 kernel: [ 4.505264] pci 0000:ff:06.0: [8086:2c30] type 0 class 0x000600 2011 Sep 23 14:45:41 kernel: [ 4.505400] pci 0000:ff:06.1: [8086:2c31] type 0 class 0x000600 2011 Sep 23 14:45:41 kernel: [ 4.505535] pci 0000:ff:06.2: [8086:2c32] type 0 class 0x000600 2011 Sep 23 14:45:41 kernel: [ 4.505669] pci 0000:ff:06.3: [8086:2c33] type 0 class 0x000600 2011 Sep 23 14:45:41 kernel: [ 4.506320] PCI: pci_cache_line_size set to 64 bytes 2011 Sep 23 14:45:41 kernel: [ 4.506699] reserve RAM buffer: 0000000000099000 - 000000000009ffff 2011 Sep 23 14:45:41 kernel: [ 4.506747] reserve RAM buffer: 00000000bf780000 - 00000000bfffffff 2011 Sep 23 14:45:41 kernel: [ 4.506843] reserve RAM buffer: 00000003b017a000 - 00000003b3ffffff 2011 Sep 23 14:45:41 kernel: [ 4.507072] Switching to clocksource xen 2011 Sep 23 14:45:41 kernel: [ 4.511025] Switched to NOHz mode on CPU #0 2011 Sep 23 14:45:41 kernel: [ 4.511805] Switched to NOHz mode on CPU #1 2011 Sep 23 14:45:41 kernel: [ 4.511807] Switched to NOHz mode on CPU #3 2011 Sep 23 14:45:41 kernel: [ 4.511810] Switched to NOHz mode on CPU #2 2011 Sep 23 14:45:41 kernel: [ 4.513622] pnp: PnP ACPI init 2011 Sep 23 14:45:41 kernel: [ 4.513690] ACPI: bus type pnp registered 2011 Sep 23 14:45:41 kernel: [ 4.513919] pnp 00:00: [bus 00-ff] 2011 Sep 23 14:45:41 kernel: [ 4.513979] pnp 00:00: [io 0x0cf8-0x0cff] 2011 Sep 23 14:45:41 kernel: [ 4.514039] pnp 00:00: [io 0x0000-0x03af window] 2011 Sep 23 14:45:41 kernel: [ 4.514100] pnp 00:00: [io 0x03e0-0x0cf7 window] 2011 Sep 23 14:45:41 kernel: [ 4.514161] pnp 00:00: [io 0x03b0-0x03bb window] 2011 Sep 23 14:45:41 kernel: [ 4.514222] pnp 00:00: [io 0x03c0-0x03df window] 2011 Sep 23 14:45:41 kernel: [ 4.514283] pnp 00:00: [io 0x0d00-0xefff window] 2011 Sep 23 14:45:41 kernel: [ 4.514344] pnp 00:00: [io 0xf000-0xffff window] 2011 Sep 23 14:45:41 kernel: [ 4.516011] pnp 00:00: [mem 0x000a0000-0x000bffff window] 2011 Sep 23 14:45:41 kernel: [ 4.516073] pnp 00:00: [mem 0x000d0000-0x000dffff window] 2011 Sep 23 14:45:41 kernel: [ 4.516135] pnp 00:00: [mem 0xc0000000-0xdfffffff window] 2011 Sep 23 14:45:41 kernel: [ 4.516198] pnp 00:00: [mem 0xf0000000-0xfed8ffff window] 2011 Sep 23 14:45:41 kernel: [ 4.516260] pnp 00:00: [mem 0xfed40000-0xfed44fff] 2011 Sep 23 14:45:41 kernel: [ 4.516376] pnp 00:00: Plug and Play ACPI device, IDs PNP0a08 PNP0a03 (active) 2011 Sep 23 14:45:41 kernel: [ 4.516467] pnp 00:01: [mem 0xfed1c000-0xfed1ffff] 2011 Sep 23 14:45:41 kernel: [ 4.516605] system 00:01: [mem 0xfed1c000-0xfed1ffff] has been reserved 2011 Sep 23 14:45:41 kernel: [ 4.516673] system 00:01: Plug and Play ACPI device, IDs PNP0c01 (active) 2011 Sep 23 14:45:41 kernel: [ 4.516955] pnp 00:02: [dma 4] 2011 Sep 23 14:45:41 kernel: [ 4.517016] pnp 00:02: [io 0x0000-0x000f] 2011 Sep 23 14:45:41 kernel: [ 4.517076] pnp 00:02: [io 0x0081-0x0083] 2011 Sep 23 14:45:41 kernel: [ 4.517136] pnp 00:02: [io 0x0087] 2011 Sep 23 14:45:41 kernel: [ 4.517194] pnp 00:02: [io 0x0089-0x008b] 2011 Sep 23 14:45:41 kernel: [ 4.517254] pnp 00:02: [io 0x008f] 2011 Sep 23 14:45:41 kernel: [ 4.517312] pnp 00:02: [io 0x00c0-0x00df] 2011 Sep 23 14:45:41 kernel: [ 4.517449] pnp 00:02: Plug and Play ACPI device, IDs PNP0200 (active) 2011 Sep 23 14:45:41 kernel: [ 4.517529] pnp 00:03: [io 0x0070-0x0071] 2011 Sep 23 14:45:41 kernel: [ 4.517591] xen: registering gsi 8 triggering 1 polarity 0 2011 Sep 23 14:45:41 kernel: [ 4.517654] xen_map_pirq_gsi: returning irq 8 for gsi 8 2011 Sep 23 14:45:41 kernel: [ 4.517716] xen: --> pirq=8 -> irq=8 (gsi=8) 2011 Sep 23 14:45:41 kernel: [ 4.517783] pnp 00:03: [irq 8] 2011 Sep 23 14:45:41 kernel: [ 4.517916] pnp 00:03: Plug and Play ACPI device, IDs PNP0b00 (active) 2011 Sep 23 14:45:41 kernel: [ 4.518022] pnp 00:04: [io 0x0060] 2011 Sep 23 14:45:41 kernel: [ 4.518081] pnp 00:04: [io 0x0064] 2011 Sep 23 14:45:41 kernel: [ 4.518140] xen: registering gsi 1 triggering 1 polarity 0 2011 Sep 23 14:45:41 kernel: [ 4.518202] xen_map_pirq_gsi: returning irq 1 for gsi 1 2011 Sep 23 14:45:41 kernel: [ 4.518264] xen: --> pirq=1 -> irq=1 (gsi=1) 2011 Sep 23 14:45:41 kernel: [ 4.518328] pnp 00:04: [irq 1] 2011 Sep 23 14:45:41 kernel: [ 4.518465] pnp 00:04: Plug and Play ACPI device, IDs PNP0303 PNP030b (active) 2011 Sep 23 14:45:41 kernel: [ 4.518585] pnp 00:05: [io 0x0061] 2011 Sep 23 14:45:41 kernel: [ 4.518722] pnp 00:05: Plug and Play ACPI device, IDs PNP0800 (active) 2011 Sep 23 14:45:41 kernel: [ 4.518798] pnp 00:06: [io 0x00f0-0x00ff] 2011 Sep 23 14:45:41 kernel: [ 4.518858] xen: registering gsi 13 triggering 1 polarity 0 2011 Sep 23 14:45:41 kernel: [ 4.518921] xen_map_pirq_gsi: returning irq 13 for gsi 13 2011 Sep 23 14:45:41 kernel: [ 4.518983] xen: --> pirq=13 -> irq=13 (gsi=13) 2011 Sep 23 14:45:41 kernel: [ 4.519047] pnp 00:06: [irq 13] 2011 Sep 23 14:45:41 kernel: [ 4.519188] pnp 00:06: Plug and Play ACPI device, IDs PNP0c04 (active) 2011 Sep 23 14:45:41 kernel: [ 4.519335] pnp 00:07: [io 0x0000-0xffffffffffffffff disabled] 2011 Sep 23 14:45:41 kernel: [ 4.519402] pnp 00:07: [io 0x0000-0xffffffffffffffff disabled] 2011 Sep 23 14:45:41 kernel: [ 4.519466] pnp 00:07: [io 0x0a10-0x0a1f] 2011 Sep 23 14:45:41 kernel: [ 4.519616] system 00:07: [io 0x0a10-0x0a1f] has been reserved 2011 Sep 23 14:45:41 kernel: [ 4.519683] system 00:07: Plug and Play ACPI device, IDs PNP0c02 (active) 2011 Sep 23 14:45:41 kernel: [ 4.520013] pnp 00:08: [io 0x03f8-0x03ff] 2011 Sep 23 14:45:41 kernel: [ 4.520074] xen: registering gsi 4 triggering 1 polarity 0 2011 Sep 23 14:45:41 kernel: [ 4.520137] xen_map_pirq_gsi: returning irq 4 for gsi 4 2011 Sep 23 14:45:41 kernel: [ 4.520199] xen: --> pirq=4 -> irq=4 (gsi=4) 2011 Sep 23 14:45:41 kernel: [ 4.520263] pnp 00:08: [irq 4] 2011 Sep 23 14:45:41 kernel: [ 4.520320] pnp 00:08: [dma 0 disabled] 2011 Sep 23 14:45:41 kernel: [ 4.520501] pnp 00:08: Plug and Play ACPI device, IDs PNP0501 (active) 2011 Sep 23 14:45:41 kernel: [ 4.520815] pnp 00:09: [io 0x02f8-0x02ff] 2011 Sep 23 14:45:41 kernel: [ 4.520876] xen: registering gsi 3 triggering 1 polarity 0 2011 Sep 23 14:45:41 kernel: [ 4.520939] xen_map_pirq_gsi: returning irq 3 for gsi 3 2011 Sep 23 14:45:41 kernel: [ 4.521000] xen: --> pirq=3 -> irq=3 (gsi=3) 2011 Sep 23 14:45:41 kernel: [ 4.521064] pnp 00:09: [irq 3] 2011 Sep 23 14:45:41 kernel: [ 4.521122] pnp 00:09: [dma 0 disabled] 2011 Sep 23 14:45:41 kernel: [ 4.521302] pnp 00:09: Plug and Play ACPI device, IDs PNP0501 (active) 2011 Sep 23 14:45:41 kernel: [ 4.521546] pnp 00:0a: [io 0x0010-0x001f] 2011 Sep 23 14:45:41 kernel: [ 4.521607] pnp 00:0a: [io 0x0022-0x003f] 2011 Sep 23 14:45:41 kernel: [ 4.521668] pnp 00:0a: [io 0x0044-0x004f] 2011 Sep 23 14:45:41 kernel: [ 4.521728] pnp 00:0a: [io 0x0050-0x005f] 2011 Sep 23 14:45:41 kernel: [ 4.521789] pnp 00:0a: [io 0x0062-0x0063] 2011 Sep 23 14:45:41 kernel: [ 4.521849] pnp 00:0a: [io 0x0065-0x006f] 2011 Sep 23 14:45:41 kernel: [ 4.521910] pnp 00:0a: [io 0x0072-0x007f] 2011 Sep 23 14:45:41 kernel: [ 4.521970] pnp 00:0a: [io 0x0080] 2011 Sep 23 14:45:41 kernel: [ 4.522030] pnp 00:0a: [io 0x0084-0x0086] 2011 Sep 23 14:45:41 kernel: [ 4.522090] pnp 00:0a: [io 0x0088] 2011 Sep 23 14:45:41 kernel: [ 4.522149] pnp 00:0a: [io 0x008c-0x008e] 2011 Sep 23 14:45:41 kernel: [ 4.522209] pnp 00:0a: [io 0x0090-0x009f] 2011 Sep 23 14:45:41 kernel: [ 4.522270] pnp 00:0a: [io 0x00a2-0x00bf] 2011 Sep 23 14:45:41 kernel: [ 4.522330] pnp 00:0a: [io 0x00e0-0x00ef] 2011 Sep 23 14:45:41 kernel: [ 4.522391] pnp 00:0a: [io 0x0ca2-0x0ca3] 2011 Sep 23 14:45:41 kernel: [ 4.522451] pnp 00:0a: [io 0x0cf8-0x0cff] 2011 Sep 23 14:45:41 kernel: [ 4.522511] pnp 00:0a: [io 0x04d0-0x04d1] 2011 Sep 23 14:45:41 kernel: [ 4.522572] pnp 00:0a: [mem 0x00000400-0x000004ff] 2011 Sep 23 14:45:41 kernel: [ 4.522634] pnp 00:0a: [io 0x0800-0x087f] 2011 Sep 23 14:45:41 kernel: [ 4.522695] pnp 00:0a: [io 0x0000-0xffffffffffffffff disabled] 2011 Sep 23 14:45:41 kernel: [ 4.522760] pnp 00:0a: [io 0x0500-0x057f] 2011 Sep 23 14:45:41 kernel: [ 4.522821] pnp 00:0a: [mem 0xfed1c000-0xfed1ffff] 2011 Sep 23 14:45:41 kernel: [ 4.522882] pnp 00:0a: [mem 0xfed20000-0xfed3ffff] 2011 Sep 23 14:45:41 kernel: [ 4.522944] pnp 00:0a: [mem 0xfed40000-0xfed8ffff] 2011 Sep 23 14:45:41 kernel: [ 4.523157] system 00:0a: [io 0x0ca2-0x0ca3] has been reserved 2011 Sep 23 14:45:41 kernel: [ 4.523221] system 00:0a: [io 0x0cf8-0x0cff] could not be reserved 2011 Sep 23 14:45:41 kernel: [ 4.523288] system 00:0a: [io 0x04d0-0x04d1] has been reserved 2011 Sep 23 14:45:41 kernel: [ 4.523351] system 00:0a: [io 0x0800-0x087f] has been reserved 2011 Sep 23 14:45:41 kernel: [ 4.523415] system 00:0a: [io 0x0500-0x057f] has been reserved 2011 Sep 23 14:45:41 kernel: [ 4.523479] system 00:0a: [mem 0x00000400-0x000004ff] could not be reserved 2011 Sep 23 14:45:41 kernel: [ 4.523545] system 00:0a: [mem 0xfed1c000-0xfed1ffff] has been reserved 2011 Sep 23 14:45:41 kernel: [ 4.523611] system 00:0a: [mem 0xfed20000-0xfed3ffff] has been reserved 2011 Sep 23 14:45:41 kernel: [ 4.523676] system 00:0a: [mem 0xfed40000-0xfed8ffff] has been reserved 2011 Sep 23 14:45:41 kernel: [ 4.523742] system 00:0a: Plug and Play ACPI device, IDs PNP0c02 (active) 2011 Sep 23 14:45:41 kernel: [ 4.523872] pnp 00:0b: [mem 0xfed00000-0xfed003ff] 2011 Sep 23 14:45:41 kernel: [ 4.523976] pnp 00:0b: Plug and Play ACPI device, IDs PNP0103 (active) 2011 Sep 23 14:45:41 kernel: [ 4.524155] pnp 00:0c: [mem 0xfec00000-0xfec00fff] 2011 Sep 23 14:45:41 kernel: [ 4.524217] pnp 00:0c: [mem 0xfee00000-0xfee00fff] 2011 Sep 23 14:45:41 kernel: [ 4.524371] system 00:0c: [mem 0xfec00000-0xfec00fff] could not be reserved 2011 Sep 23 14:45:41 kernel: [ 4.524439] system 00:0c: [mem 0xfee00000-0xfee00fff] has been reserved 2011 Sep 23 14:45:41 kernel: [ 4.524506] system 00:0c: Plug and Play ACPI device, IDs PNP0c02 (active) 2011 Sep 23 14:45:41 kernel: [ 4.524642] pnp 00:0d: [mem 0xe0000000-0xefffffff] 2011 Sep 23 14:45:41 kernel: [ 4.524829] system 00:0d: [mem 0xe0000000-0xefffffff] has been reserved 2011 Sep 23 14:45:41 kernel: [ 4.524897] system 00:0d: Plug and Play ACPI device, IDs PNP0c02 (active) 2011 Sep 23 14:45:41 kernel: [ 4.525144] pnp 00:0e: [mem 0x000c0000-0x000cffff] 2011 Sep 23 14:45:41 kernel: [ 4.525207] pnp 00:0e: [mem 0x000e0000-0x000fffff] 2011 Sep 23 14:45:41 kernel: [ 4.525269] pnp 00:0e: [mem 0xfed90000-0xffffffff] 2011 Sep 23 14:45:41 kernel: [ 4.525458] system 00:0e: [mem 0x000c0000-0x000cffff] could not be reserved 2011 Sep 23 14:45:41 kernel: [ 4.525525] system 00:0e: [mem 0x000e0000-0x000fffff] could not be reserved 2011 Sep 23 14:45:41 kernel: [ 4.525591] system 00:0e: [mem 0xfed90000-0xffffffff] could not be reserved 2011 Sep 23 14:45:41 kernel: [ 4.525658] system 00:0e: Plug and Play ACPI device, IDs PNP0c01 (active) 2011 Sep 23 14:45:41 kernel: [ 4.525924] pnp: PnP ACPI: found 15 devices 2011 Sep 23 14:45:41 kernel: [ 4.525985] ACPI: ACPI bus type pnp unregistered 2011 Sep 23 14:45:41 kernel: [ 4.526048] PnPBIOS: Disabled 2011 Sep 23 14:45:41 kernel: [ 4.531463] PM-Timer failed consistency check (0x0xffffff) - aborting. 2011 Sep 23 14:45:41 kernel: [ 4.531560] PCI: max bus depth: 1 pci_try_num: 2 2011 Sep 23 14:45:41 kernel: [ 4.531748] pci 0000:00:1c.5: BAR 15: assigned [mem 0xc0000000-0xc01fffff 64bit pref] 2011 Sep 23 14:45:41 kernel: [ 4.531834] pci 0000:00:1c.4: BAR 15: assigned [mem 0xc0200000-0xc03fffff 64bit pref] 2011 Sep 23 14:45:41 kernel: [ 4.531921] pci 0000:00:1c.0: BAR 14: assigned [mem 0xc0400000-0xc05fffff] 2011 Sep 23 14:45:41 kernel: [ 4.531988] pci 0000:00:1c.0: BAR 15: assigned [mem 0xc0600000-0xc07fffff 64bit pref] 2011 Sep 23 14:45:41 kernel: [ 4.532074] pci 0000:00:1c.0: BAR 13: assigned [io 0x1000-0x1fff] 2011 Sep 23 14:45:41 kernel: [ 4.532138] pci 0000:00:01.0: PCI bridge to [bus 01-01] 2011 Sep 23 14:45:41 kernel: [ 4.532200] pci 0000:00:01.0: bridge window [io disabled] 2011 Sep 23 14:45:41 kernel: [ 4.532269] pci 0000:00:01.0: bridge window [mem disabled] 2011 Sep 23 14:45:41 kernel: [ 4.532336] pci 0000:00:01.0: bridge window [mem pref disabled] 2011 Sep 23 14:45:41 kernel: [ 4.532408] pci 0000:00:03.0: PCI bridge to [bus 02-02] 2011 Sep 23 14:45:41 kernel: [ 4.532470] pci 0000:00:03.0: bridge window [io disabled] 2011 Sep 23 14:45:41 kernel: [ 4.532538] pci 0000:00:03.0: bridge window [mem disabled] 2011 Sep 23 14:45:41 kernel: [ 4.532605] pci 0000:00:03.0: bridge window [mem pref disabled] 2011 Sep 23 14:45:41 kernel: [ 4.532677] pci 0000:00:07.0: PCI bridge to [bus 03-03] 2011 Sep 23 14:45:41 kernel: [ 4.532739] pci 0000:00:07.0: bridge window [io disabled] 2011 Sep 23 14:45:41 kernel: [ 4.532808] pci 0000:00:07.0: bridge window [mem disabled] 2011 Sep 23 14:45:41 kernel: [ 4.532875] pci 0000:00:07.0: bridge window [mem pref disabled] 2011 Sep 23 14:45:41 kernel: [ 4.532947] pci 0000:00:09.0: PCI bridge to [bus 04-04] 2011 Sep 23 14:45:41 kernel: [ 4.533008] pci 0000:00:09.0: bridge window [io disabled] 2011 Sep 23 14:45:41 kernel: [ 4.533078] pci 0000:00:09.0: bridge window [mem disabled] 2011 Sep 23 14:45:41 kernel: [ 4.533144] pci 0000:00:09.0: bridge window [mem pref disabled] 2011 Sep 23 14:45:41 kernel: [ 4.533217] pci 0000:00:1c.0: PCI bridge to [bus 05-05] 2011 Sep 23 14:45:41 kernel: [ 4.533281] pci 0000:00:1c.0: bridge window [io 0x1000-0x1fff] 2011 Sep 23 14:45:41 kernel: [ 4.533351] pci 0000:00:1c.0: bridge window [mem 0xc0400000-0xc05fffff] 2011 Sep 23 14:45:41 kernel: [ 4.533421] pci 0000:00:1c.0: bridge window [mem 0xc0600000-0xc07fffff 64bit pref] 2011 Sep 23 14:45:41 kernel: [ 4.533515] pci 0000:00:1c.4: PCI bridge to [bus 06-06] 2011 Sep 23 14:45:41 kernel: [ 4.533579] pci 0000:00:1c.4: bridge window [io 0xd000-0xdfff] 2011 Sep 23 14:45:41 kernel: [ 4.533649] pci 0000:00:1c.4: bridge window [mem 0xfbc00000-0xfbcfffff] 2011 Sep 23 14:45:41 kernel: [ 4.533719] pci 0000:00:1c.4: bridge window [mem 0xc0200000-0xc03fffff 64bit pref] 2011 Sep 23 14:45:41 kernel: [ 4.533812] pci 0000:00:1c.5: PCI bridge to [bus 07-07] 2011 Sep 23 14:45:41 kernel: [ 4.533876] pci 0000:00:1c.5: bridge window [io 0xe000-0xefff] 2011 Sep 23 14:45:41 kernel: [ 4.533946] pci 0000:00:1c.5: bridge window [mem 0xfbd00000-0xfbdfffff] 2011 Sep 23 14:45:41 kernel: [ 4.534016] pci 0000:00:1c.5: bridge window [mem 0xc0000000-0xc01fffff 64bit pref] 2011 Sep 23 14:45:41 kernel: [ 4.534109] pci 0000:00:1e.0: PCI bridge to [bus 08-08] 2011 Sep 23 14:45:41 kernel: [ 4.534171] pci 0000:00:1e.0: bridge window [io disabled] 2011 Sep 23 14:45:41 kernel: [ 4.534240] pci 0000:00:1e.0: bridge window [mem 0xfaf00000-0xfb7fffff] 2011 Sep 23 14:45:41 kernel: [ 4.534310] pci 0000:00:1e.0: bridge window [mem 0xf9000000-0xf9ffffff 64bit pref] 2011 Sep 23 14:45:41 kernel: [ 4.534416] pci 0000:00:01.0: setting latency timer to 64 2011 Sep 23 14:45:41 kernel: [ 4.534491] pci 0000:00:03.0: setting latency timer to 64 2011 Sep 23 14:45:41 kernel: [ 4.534565] pci 0000:00:07.0: setting latency timer to 64 2011 Sep 23 14:45:41 kernel: [ 4.534640] pci 0000:00:09.0: setting latency timer to 64 2011 Sep 23 14:45:41 kernel: [ 4.534711] pci 0000:00:1c.0: enabling device (0104 -> 0107) 2011 Sep 23 14:45:41 kernel: [ 4.534777] xen: registering gsi 17 triggering 0 polarity 1 2011 Sep 23 14:45:41 kernel: [ 4.534848] xen: --> pirq=17 -> irq=17 (gsi=17) 2011 Sep 23 14:45:41 kernel: [ 4.534914] pci 0000:00:1c.0: PCI INT A -> GSI 17 (level, low) -> IRQ 17 2011 Sep 23 14:45:41 kernel: [ 4.534984] pci 0000:00:1c.0: setting latency timer to 64 2011 Sep 23 14:45:41 kernel: [ 4.535055] xen: registering gsi 17 triggering 0 polarity 1 2011 Sep 23 14:45:41 kernel: [ 4.535117] xen_map_pirq_gsi: returning irq 17 for gsi 17 2011 Sep 23 14:45:41 kernel: [ 4.535179] xen: --> pirq=17 -> irq=17 (gsi=17) 2011 Sep 23 14:45:41 kernel: [ 4.535240] Already setup the GSI :17 2011 Sep 23 14:45:41 kernel: [ 4.535299] pci 0000:00:1c.4: PCI INT A -> GSI 17 (level, low) -> IRQ 17 2011 Sep 23 14:45:41 kernel: [ 4.535368] pci 0000:00:1c.4: setting latency timer to 64 2011 Sep 23 14:45:41 kernel: [ 4.535437] xen: registering gsi 16 triggering 0 polarity 1 2011 Sep 23 14:45:41 kernel: [ 4.535511] xen: --> pirq=16 -> irq=16 (gsi=16) 2011 Sep 23 14:45:41 kernel: [ 4.535575] pci 0000:00:1c.5: PCI INT B -> GSI 16 (level, low) -> IRQ 16 2011 Sep 23 14:45:41 kernel: [ 4.535645] pci 0000:00:1c.5: setting latency timer to 64 2011 Sep 23 14:45:41 kernel: [ 4.535718] pci 0000:00:1e.0: setting latency timer to 64 2011 Sep 23 14:45:41 kernel: [ 4.535784] pci_bus 0000:00: resource 4 [io 0x0000-0x03af] 2011 Sep 23 14:45:41 kernel: [ 4.537381] pci_bus 0000:00: resource 5 [io 0x03e0-0x0cf7] 2011 Sep 23 14:45:41 kernel: [ 4.537444] pci_bus 0000:00: resource 6 [io 0x03b0-0x03bb] 2011 Sep 23 14:45:41 kernel: [ 4.537507] pci_bus 0000:00: resource 7 [io 0x03c0-0x03df] 2011 Sep 23 14:45:41 kernel: [ 4.537570] pci_bus 0000:00: resource 8 [io 0x0d00-0xefff] 2011 Sep 23 14:45:41 kernel: [ 4.537633] pci_bus 0000:00: resource 9 [io 0xf000-0xffff] 2011 Sep 23 14:45:41 kernel: [ 4.537695] pci_bus 0000:00: resource 10 [mem 0x000a0000-0x000bffff] 2011 Sep 23 14:45:41 kernel: [ 4.537760] pci_bus 0000:00: resource 11 [mem 0x000d0000-0x000dffff] 2011 Sep 23 14:45:41 kernel: [ 4.537824] pci_bus 0000:00: resource 12 [mem 0xc0000000-0xdfffffff] 2011 Sep 23 14:45:41 kernel: [ 4.537889] pci_bus 0000:00: resource 13 [mem 0xf0000000-0xfed8ffff] 2011 Sep 23 14:45:41 kernel: [ 4.537954] pci_bus 0000:05: resource 0 [io 0x1000-0x1fff] 2011 Sep 23 14:45:41 kernel: [ 4.538016] pci_bus 0000:05: resource 1 [mem 0xc0400000-0xc05fffff] 2011 Sep 23 14:45:41 kernel: [ 4.538081] pci_bus 0000:05: resource 2 [mem 0xc0600000-0xc07fffff 64bit pref] 2011 Sep 23 14:45:41 kernel: [ 4.538164] pci_bus 0000:06: resource 0 [io 0xd000-0xdfff] 2011 Sep 23 14:45:41 kernel: [ 4.538227] pci_bus 0000:06: resource 1 [mem 0xfbc00000-0xfbcfffff] 2011 Sep 23 14:45:41 kernel: [ 4.538292] pci_bus 0000:06: resource 2 [mem 0xc0200000-0xc03fffff 64bit pref] 2011 Sep 23 14:45:41 kernel: [ 4.538375] pci_bus 0000:07: resource 0 [io 0xe000-0xefff] 2011 Sep 23 14:45:41 kernel: [ 4.538437] pci_bus 0000:07: resource 1 [mem 0xfbd00000-0xfbdfffff] 2011 Sep 23 14:45:41 kernel: [ 4.538502] pci_bus 0000:07: resource 2 [mem 0xc0000000-0xc01fffff 64bit pref] 2011 Sep 23 14:45:41 kernel: [ 4.538585] pci_bus 0000:08: resource 1 [mem 0xfaf00000-0xfb7fffff] 2011 Sep 23 14:45:41 kernel: [ 4.538649] pci_bus 0000:08: resource 2 [mem 0xf9000000-0xf9ffffff 64bit pref] 2011 Sep 23 14:45:41 kernel: [ 4.538732] pci_bus 0000:08: resource 4 [io 0x0000-0x03af] 2011 Sep 23 14:45:41 kernel: [ 4.538795] pci_bus 0000:08: resource 5 [io 0x03e0-0x0cf7] 2011 Sep 23 14:45:41 kernel: [ 4.538858] pci_bus 0000:08: resource 6 [io 0x03b0-0x03bb] 2011 Sep 23 14:45:41 kernel: [ 4.538921] pci_bus 0000:08: resource 7 [io 0x03c0-0x03df] 2011 Sep 23 14:45:41 kernel: [ 4.538983] pci_bus 0000:08: resource 8 [io 0x0d00-0xefff] 2011 Sep 23 14:45:41 kernel: [ 4.539046] pci_bus 0000:08: resource 9 [io 0xf000-0xffff] 2011 Sep 23 14:45:41 kernel: [ 4.539109] pci_bus 0000:08: resource 10 [mem 0x000a0000-0x000bffff] 2011 Sep 23 14:45:41 kernel: [ 4.539174] pci_bus 0000:08: resource 11 [mem 0x000d0000-0x000dffff] 2011 Sep 23 14:45:41 kernel: [ 4.539238] pci_bus 0000:08: resource 12 [mem 0xc0000000-0xdfffffff] 2011 Sep 23 14:45:41 kernel: [ 4.539303] pci_bus 0000:08: resource 13 [mem 0xf0000000-0xfed8ffff] 2011 Sep 23 14:45:41 kernel: [ 4.539368] pci_bus 0000:ff: resource 0 [io 0x0000-0xffff] 2011 Sep 23 14:45:41 kernel: [ 4.539430] pci_bus 0000:ff: resource 1 [mem 0x00000000-0xffffffffff] 2011 Sep 23 14:45:41 kernel: [ 4.539522] NET: Registered protocol family 2 2011 Sep 23 14:45:41 kernel: [ 4.539637] IP route cache hash table entries: 32768 (order: 5, 131072 bytes) 2011 Sep 23 14:45:41 kernel: [ 4.539910] TCP established hash table entries: 131072 (order: 8, 1048576 bytes) 2011 Sep 23 14:45:41 kernel: [ 4.540249] TCP bind hash table entries: 65536 (order: 7, 524288 bytes) 2011 Sep 23 14:45:41 kernel: [ 4.540422] TCP: Hash tables configured (established 131072 bind 65536) 2011 Sep 23 14:45:41 kernel: [ 4.540488] TCP reno registered 2011 Sep 23 14:45:41 kernel: [ 4.540548] UDP hash table entries: 512 (order: 2, 16384 bytes) 2011 Sep 23 14:45:41 kernel: [ 4.540616] UDP-Lite hash table entries: 512 (order: 2, 16384 bytes) 2011 Sep 23 14:45:41 kernel: [ 4.540757] NET: Registered protocol family 1 2011 Sep 23 14:45:41 kernel: [ 4.541114] pci 0000:08:01.0: Boot video device 2011 Sep 23 14:45:41 kernel: [ 4.541234] PCI: CLS 256 bytes, default 64 2011 Sep 23 14:45:41 kernel: [ 4.541331] Trying to unpack rootfs image as initramfs... 2011 Sep 23 14:45:41 kernel: [ 6.598812] Freeing initrd memory: 9284k freed 2011 Sep 23 14:45:41 kernel: [ 6.601646] audit: initializing netlink socket (disabled) 2011 Sep 23 14:45:41 kernel: [ 6.601724] type=2000 audit(1316789139.546:1): initialized 2011 Sep 23 14:45:41 kernel: [ 6.616878] highmem bounce pool size: 64 pages 2011 Sep 23 14:45:41 kernel: [ 6.616949] HugeTLB registered 2 MB page size, pre-allocated 0 pages 2011 Sep 23 14:45:41 kernel: [ 6.619056] squashfs: version 4.0 (2009/01/31) Phillip Lougher 2011 Sep 23 14:45:41 kernel: [ 6.619287] msgmni has been set to 911 2011 Sep 23 14:45:41 kernel: [ 6.619700] Block layer SCSI generic (bsg) driver version 0.4 loaded (major 253) 2011 Sep 23 14:45:41 kernel: [ 6.619822] io scheduler noop registered 2011 Sep 23 14:45:41 kernel: [ 6.619882] io scheduler deadline registered 2011 Sep 23 14:45:41 kernel: [ 6.619953] io scheduler cfq registered (default) 2011 Sep 23 14:45:41 kernel: [ 6.620576] pcieport 0000:00:1c.0: setting latency timer to 64 2011 Sep 23 14:45:41 kernel: [ 6.620852] pcieport 0000:00:1c.4: setting latency timer to 64 2011 Sep 23 14:45:41 kernel: [ 6.621110] pcieport 0000:00:1c.5: setting latency timer to 64 2011 Sep 23 14:45:41 kernel: [ 6.621385] pci_hotplug: PCI Hot Plug PCI Core version: 0.5 2011 Sep 23 14:45:41 kernel: [ 6.621468] pciehp: PCI Express Hot Plug Controller Driver version: 0.4 2011 Sep 23 14:45:41 kernel: [ 6.621610] input: Power Button as /devices/LNXSYSTM:00/device:00/PNP0C0C:00/input/input0 2011 Sep 23 14:45:41 kernel: [ 6.621699] ACPI: Power Button [PWRB] 2011 Sep 23 14:45:41 kernel: [ 6.621794] input: Power Button as /devices/LNXSYSTM:00/LNXPWRBN:00/input/input1 2011 Sep 23 14:45:41 kernel: [ 6.621879] ACPI: Power Button [PWRF] 2011 Sep 23 14:45:41 kernel: [ 6.622340] ACPI: acpi_idle registered with cpuidle 2011 Sep 23 14:45:41 kernel: [ 6.625410] APEI: Can not request iomem region <00000000bf7b334a-00000000bf7b334c> for GARs. 2011 Sep 23 14:45:41 kernel: [ 6.625541] isapnp: Scanning for PnP cards... 2011 Sep 23 14:45:41 kernel: [ 6.979766] isapnp: No Plug & Play device found 2011 Sep 23 14:45:41 kernel: [ 6.979886] Event-channel device installed. 2011 Sep 23 14:45:41 kernel: [ 6.980211] Serial: 8250/16550 driver, 32 ports, IRQ sharing enabled 2011 Sep 23 14:45:41 kernel: [ 7.000839] serial8250: ttyS0 at I/O 0x3f8 (irq = 4) is a 16550A 2011 Sep 23 14:45:41 kernel: [ 7.021513] serial8250: ttyS1 at I/O 0x2f8 (irq = 3) is a 16550A 2011 Sep 23 14:45:41 kernel: [ 7.164007] 00:08: ttyS0 at I/O 0x3f8 (irq = 4) is a 16550A 2011 Sep 23 14:45:41 kernel: [ 7.187894] 00:09: ttyS1 at I/O 0x2f8 (irq = 3) is a 16550A 2011 Sep 23 14:45:41 kernel: [ 7.191542] hpet_acpi_add: no address or irqs in _CRS 2011 Sep 23 14:45:41 kernel: [ 7.191617] Linux agpgart interface v0.103 2011 Sep 23 14:45:41 kernel: [ 7.192819] brd: module loaded 2011 Sep 23 14:45:41 kernel: [ 7.193402] loop: module loaded 2011 Sep 23 14:45:41 kernel: [ 7.193653] ata_piix 0000:00:1f.2: version 2.13 2011 Sep 23 14:45:41 kernel: [ 7.193729] xen: registering gsi 19 triggering 0 polarity 1 2011 Sep 23 14:45:41 kernel: [ 7.193800] xen: --> pirq=19 -> irq=19 (gsi=19) 2011 Sep 23 14:45:41 kernel: [ 7.193867] ata_piix 0000:00:1f.2: PCI INT B -> GSI 19 (level, low) -> IRQ 19 2011 Sep 23 14:45:41 kernel: [ 7.193940] ata_piix 0000:00:1f.2: MAP [ P0 P2 P1 P3 ] 2011 Sep 23 14:45:41 kernel: [ 7.194220] ata_piix 0000:00:1f.2: setting latency timer to 64 2011 Sep 23 14:45:41 kernel: [ 7.194554] scsi0 : ata_piix 2011 Sep 23 14:45:41 kernel: [ 7.194702] scsi1 : ata_piix 2011 Sep 23 14:45:41 kernel: [ 7.196242] ata1: SATA max UDMA/133 cmd 0xc000 ctl 0xbc00 bmdma 0xb480 irq 19 2011 Sep 23 14:45:41 kernel: [ 7.196315] ata2: SATA max UDMA/133 cmd 0xb880 ctl 0xb800 bmdma 0xb488 irq 19 2011 Sep 23 14:45:41 kernel: [ 7.196421] xen: registering gsi 19 triggering 0 polarity 1 2011 Sep 23 14:45:41 kernel: [ 7.196486] xen_map_pirq_gsi: returning irq 19 for gsi 19 2011 Sep 23 14:45:41 kernel: [ 7.196548] xen: --> pirq=19 -> irq=19 (gsi=19) 2011 Sep 23 14:45:41 kernel: [ 7.196610] Already setup the GSI :19 2011 Sep 23 14:45:41 kernel: [ 7.196669] ata_piix 0000:00:1f.5: PCI INT B -> GSI 19 (level, low) -> IRQ 19 2011 Sep 23 14:45:41 kernel: [ 7.196741] ata_piix 0000:00:1f.5: MAP [ P0 -- P1 -- ] 2011 Sep 23 14:45:41 kernel: [ 7.197012] ata_piix 0000:00:1f.5: setting latency timer to 64 2011 Sep 23 14:45:41 kernel: [ 7.197273] scsi2 : ata_piix 2011 Sep 23 14:45:41 kernel: [ 7.197406] scsi3 : ata_piix 2011 Sep 23 14:45:41 kernel: [ 7.198560] ata3: SATA max UDMA/133 cmd 0xb000 ctl 0xac00 bmdma 0xa480 irq 19 2011 Sep 23 14:45:41 kernel: [ 7.198630] ata4: SATA max UDMA/133 cmd 0xa880 ctl 0xa800 bmdma 0xa488 irq 19 2011 Sep 23 14:45:41 kernel: [ 7.199033] Fixed MDIO Bus: probed 2011 Sep 23 14:45:41 kernel: [ 7.199119] PPP generic driver version 2.4.2 2011 Sep 23 14:45:41 kernel: [ 7.199581] tun: Universal TUN/TAP device driver, 1.6 2011 Sep 23 14:45:41 kernel: [ 7.199645] tun: (C) 1999-2004 Max Krasnyansky <maxk@qualcomm.com> 2011 Sep 23 14:45:41 kernel: [ 7.199785] ehci_hcd: USB 2.0 'Enhanced' Host Controller (EHCI) Driver 2011 Sep 23 14:45:41 kernel: [ 7.199869] xen: registering gsi 18 triggering 0 polarity 1 2011 Sep 23 14:45:41 kernel: [ 7.199940] xen: --> pirq=18 -> irq=18 (gsi=18) 2011 Sep 23 14:45:41 kernel: [ 7.200005] ehci_hcd 0000:00:1a.7: PCI INT C -> GSI 18 (level, low) -> IRQ 18 2011 Sep 23 14:45:41 kernel: [ 7.200088] ehci_hcd 0000:00:1a.7: setting latency timer to 64 2011 Sep 23 14:45:41 kernel: [ 7.200155] ehci_hcd 0000:00:1a.7: EHCI Host Controller 2011 Sep 23 14:45:41 kernel: [ 7.200245] ehci_hcd 0000:00:1a.7: new USB bus registered, assigned bus number 1 2011 Sep 23 14:45:41 kernel: [ 7.200379] ehci_hcd 0000:00:1a.7: debug port 1 2011 Sep 23 14:45:41 kernel: [ 7.204315] ehci_hcd 0000:00:1a.7: cache line size of 256 is not supported 2011 Sep 23 14:45:41 kernel: [ 7.204402] ehci_hcd 0000:00:1a.7: irq 18, io mem 0xfbeda000 2011 Sep 23 14:45:41 kernel: [ 7.219263] ehci_hcd 0000:00:1a.7: USB 2.0 started, EHCI 1.00 2011 Sep 23 14:45:41 kernel: [ 7.219460] hub 1-0:1.0: USB hub found 2011 Sep 23 14:45:41 kernel: [ 7.219523] hub 1-0:1.0: 6 ports detected 2011 Sep 23 14:45:41 kernel: [ 7.219671] xen: registering gsi 23 triggering 0 polarity 1 2011 Sep 23 14:45:41 kernel: [ 7.219742] xen: --> pirq=23 -> irq=23 (gsi=23) 2011 Sep 23 14:45:41 kernel: [ 7.219807] ehci_hcd 0000:00:1d.7: PCI INT A -> GSI 23 (level, low) -> IRQ 23 2011 Sep 23 14:45:41 kernel: [ 7.219889] ehci_hcd 0000:00:1d.7: setting latency timer to 64 2011 Sep 23 14:45:41 kernel: [ 7.219955] ehci_hcd 0000:00:1d.7: EHCI Host Controller 2011 Sep 23 14:45:41 kernel: [ 7.220047] ehci_hcd 0000:00:1d.7: new USB bus registered, assigned bus number 2 2011 Sep 23 14:45:41 kernel: [ 7.220179] ehci_hcd 0000:00:1d.7: debug port 1 2011 Sep 23 14:45:41 kernel: [ 7.224120] ehci_hcd 0000:00:1d.7: cache line size of 256 is not supported 2011 Sep 23 14:45:41 kernel: [ 7.224206] ehci_hcd 0000:00:1d.7: irq 23, io mem 0xfbed8000 2011 Sep 23 14:45:41 kernel: [ 7.239263] ehci_hcd 0000:00:1d.7: USB 2.0 started, EHCI 1.00 2011 Sep 23 14:45:41 kernel: [ 7.239449] hub 2-0:1.0: USB hub found 2011 Sep 23 14:45:41 kernel: [ 7.239511] hub 2-0:1.0: 6 ports detected 2011 Sep 23 14:45:41 kernel: [ 7.239653] ohci_hcd: USB 1.1 'Open' Host Controller (OHCI) Driver 2011 Sep 23 14:45:41 kernel: [ 7.239732] uhci_hcd: USB Universal Host Controller Interface driver 2011 Sep 23 14:45:41 kernel: [ 7.239824] xen: registering gsi 16 triggering 0 polarity 1 2011 Sep 23 14:45:41 kernel: [ 7.239888] xen_map_pirq_gsi: returning irq 16 for gsi 16 2011 Sep 23 14:45:41 kernel: [ 7.239950] xen: --> pirq=16 -> irq=16 (gsi=16) 2011 Sep 23 14:45:41 kernel: [ 7.240012] Already setup the GSI :16 2011 Sep 23 14:45:41 kernel: [ 7.240071] uhci_hcd 0000:00:1a.0: PCI INT A -> GSI 16 (level, low) -> IRQ 16 2011 Sep 23 14:45:41 kernel: [ 7.240144] uhci_hcd 0000:00:1a.0: setting latency timer to 64 2011 Sep 23 14:45:41 kernel: [ 7.240210] uhci_hcd 0000:00:1a.0: UHCI Host Controller 2011 Sep 23 14:45:41 kernel: [ 7.240312] uhci_hcd 0000:00:1a.0: new USB bus registered, assigned bus number 3 2011 Sep 23 14:45:41 kernel: [ 7.240446] uhci_hcd 0000:00:1a.0: irq 16, io base 0x0000cc00 2011 Sep 23 14:45:41 kernel: [ 7.240638] hub 3-0:1.0: USB hub found 2011 Sep 23 14:45:41 kernel: [ 7.240701] hub 3-0:1.0: 2 ports detected 2011 Sep 23 14:45:41 kernel: [ 7.240840] xen: registering gsi 21 triggering 0 polarity 1 2011 Sep 23 14:45:41 kernel: [ 7.240911] xen: --> pirq=21 -> irq=21 (gsi=21) 2011 Sep 23 14:45:41 kernel: [ 7.240978] uhci_hcd 0000:00:1a.1: PCI INT B -> GSI 21 (level, low) -> IRQ 21 2011 Sep 23 14:45:41 kernel: [ 7.241051] uhci_hcd 0000:00:1a.1: setting latency timer to 64 2011 Sep 23 14:45:41 kernel: [ 7.241117] uhci_hcd 0000:00:1a.1: UHCI Host Controller 2011 Sep 23 14:45:41 kernel: [ 7.241212] uhci_hcd 0000:00:1a.1: new USB bus registered, assigned bus number 4 2011 Sep 23 14:45:41 kernel: [ 7.241345] uhci_hcd 0000:00:1a.1: irq 21, io base 0x0000c880 2011 Sep 23 14:45:41 kernel: [ 7.241537] hub 4-0:1.0: USB hub found 2011 Sep 23 14:45:41 kernel: [ 7.241600] hub 4-0:1.0: 2 ports detected 2011 Sep 23 14:45:41 kernel: [ 7.241736] xen: registering gsi 19 triggering 0 polarity 1 2011 Sep 23 14:45:41 kernel: [ 7.241799] xen_map_pirq_gsi: returning irq 19 for gsi 19 2011 Sep 23 14:45:41 kernel: [ 7.241861] xen: --> pirq=19 -> irq=19 (gsi=19) 2011 Sep 23 14:45:41 kernel: [ 7.241923] Already setup the GSI :19 2011 Sep 23 14:45:41 kernel: [ 7.241982] uhci_hcd 0000:00:1a.2: PCI INT D -> GSI 19 (level, low) -> IRQ 19 2011 Sep 23 14:45:41 kernel: [ 7.242055] uhci_hcd 0000:00:1a.2: setting latency timer to 64 2011 Sep 23 14:45:41 kernel: [ 7.242120] uhci_hcd 0000:00:1a.2: UHCI Host Controller 2011 Sep 23 14:45:41 kernel: [ 7.242211] uhci_hcd 0000:00:1a.2: new USB bus registered, assigned bus number 5 2011 Sep 23 14:45:41 kernel: [ 7.242326] uhci_hcd 0000:00:1a.2: irq 19, io base 0x0000c800 2011 Sep 23 14:45:41 kernel: [ 7.242516] hub 5-0:1.0: USB hub found 2011 Sep 23 14:45:41 kernel: [ 7.242578] hub 5-0:1.0: 2 ports detected 2011 Sep 23 14:45:41 kernel: [ 7.242717] xen: registering gsi 23 triggering 0 polarity 1 2011 Sep 23 14:45:41 kernel: [ 7.242780] xen_map_pirq_gsi: returning irq 23 for gsi 23 2011 Sep 23 14:45:41 kernel: [ 7.242843] xen: --> pirq=23 -> irq=23 (gsi=23) 2011 Sep 23 14:45:41 kernel: [ 7.242904] Already setup the GSI :23 2011 Sep 23 14:45:41 kernel: [ 7.242964] uhci_hcd 0000:00:1d.0: PCI INT A -> GSI 23 (level, low) -> IRQ 23 2011 Sep 23 14:45:41 kernel: [ 7.244422] uhci_hcd 0000:00:1d.0: setting latency timer to 64 2011 Sep 23 14:45:41 kernel: [ 7.244488] uhci_hcd 0000:00:1d.0: UHCI Host Controller 2011 Sep 23 14:45:41 kernel: [ 7.244595] uhci_hcd 0000:00:1d.0: new USB bus registered, assigned bus number 6 2011 Sep 23 14:45:41 kernel: [ 7.244711] uhci_hcd 0000:00:1d.0: irq 23, io base 0x0000c480 2011 Sep 23 14:45:41 kernel: [ 7.244903] hub 6-0:1.0: USB hub found 2011 Sep 23 14:45:41 kernel: [ 7.244966] hub 6-0:1.0: 2 ports detected 2011 Sep 23 14:45:41 kernel: [ 7.245104] xen: registering gsi 19 triggering 0 polarity 1 2011 Sep 23 14:45:41 kernel: [ 7.245167] xen_map_pirq_gsi: returning irq 19 for gsi 19 2011 Sep 23 14:45:41 kernel: [ 7.245230] xen: --> pirq=19 -> irq=19 (gsi=19) 2011 Sep 23 14:45:41 kernel: [ 7.245291] Already setup the GSI :19 2011 Sep 23 14:45:41 kernel: [ 7.245350] uhci_hcd 0000:00:1d.1: PCI INT B -> GSI 19 (level, low) -> IRQ 19 2011 Sep 23 14:45:41 kernel: [ 7.245426] uhci_hcd 0000:00:1d.1: setting latency timer to 64 2011 Sep 23 14:45:41 kernel: [ 7.245491] uhci_hcd 0000:00:1d.1: UHCI Host Controller 2011 Sep 23 14:45:41 kernel: [ 7.245590] uhci_hcd 0000:00:1d.1: new USB bus registered, assigned bus number 7 2011 Sep 23 14:45:41 kernel: [ 7.245706] uhci_hcd 0000:00:1d.1: irq 19, io base 0x0000c400 2011 Sep 23 14:45:41 kernel: [ 7.245899] hub 7-0:1.0: USB hub found 2011 Sep 23 14:45:41 kernel: [ 7.245962] hub 7-0:1.0: 2 ports detected 2011 Sep 23 14:45:41 kernel: [ 7.246098] xen: registering gsi 18 triggering 0 polarity 1 2011 Sep 23 14:45:41 kernel: [ 7.246162] xen_map_pirq_gsi: returning irq 18 for gsi 18 2011 Sep 23 14:45:41 kernel: [ 7.246224] xen: --> pirq=18 -> irq=18 (gsi=18) 2011 Sep 23 14:45:41 kernel: [ 7.246285] Already setup the GSI :18 2011 Sep 23 14:45:41 kernel: [ 7.246344] uhci_hcd 0000:00:1d.2: PCI INT C -> GSI 18 (level, low) -> IRQ 18 2011 Sep 23 14:45:41 kernel: [ 7.246417] uhci_hcd 0000:00:1d.2: setting latency timer to 64 2011 Sep 23 14:45:41 kernel: [ 7.246483] uhci_hcd 0000:00:1d.2: UHCI Host Controller 2011 Sep 23 14:45:41 kernel: [ 7.246576] uhci_hcd 0000:00:1d.2: new USB bus registered, assigned bus number 8 2011 Sep 23 14:45:41 kernel: [ 7.246691] uhci_hcd 0000:00:1d.2: irq 18, io base 0x0000c080 2011 Sep 23 14:45:41 kernel: [ 7.246894] hub 8-0:1.0: USB hub found 2011 Sep 23 14:45:41 kernel: [ 7.246957] hub 8-0:1.0: 2 ports detected 2011 Sep 23 14:45:41 kernel: [ 7.247153] i8042: PNP: PS/2 Controller [PNP0303:PS2K] at 0x60,0x64 irq 1 2011 Sep 23 14:45:41 kernel: [ 7.247218] i8042: PNP: PS/2 appears to have AUX port disabled, if this is incorrect please boot with i8042.nopnp 2011 Sep 23 14:45:41 kernel: [ 7.248047] serio: i8042 KBD port at 0x60,0x64 irq 1 2011 Sep 23 14:45:41 kernel: [ 7.248199] mousedev: PS/2 mouse device common for all mice 2011 Sep 23 14:45:41 kernel: [ 7.248376] rtc_cmos 00:03: RTC can wake from S4 2011 Sep 23 14:45:41 kernel: [ 7.248557] rtc_cmos 00:03: rtc core: registered rtc_cmos as rtc0 2011 Sep 23 14:45:41 kernel: [ 7.248656] rtc0: alarms up to one month, y3k, 114 bytes nvram 2011 Sep 23 14:45:41 kernel: [ 7.248783] device-mapper: uevent: version 1.0.3 2011 Sep 23 14:45:41 kernel: [ 7.248907] device-mapper: ioctl: 4.20.0-ioctl (2011-02-02) initialised: dm-devel@redhat.com 2011 Sep 23 14:45:41 kernel: [ 7.249094] device-mapper: multipath: version 1.3.0 loaded 2011 Sep 23 14:45:41 kernel: [ 7.249157] device-mapper: multipath round-robin: version 1.0.0 loaded 2011 Sep 23 14:45:41 kernel: [ 7.249308] EISA: Probing bus 0 at eisa.0 2011 Sep 23 14:45:41 kernel: [ 7.249368] EISA: Cannot allocate resource for mainboard 2011 Sep 23 14:45:41 kernel: [ 7.249430] Cannot allocate resource for EISA slot 1 2011 Sep 23 14:45:41 kernel: [ 7.249491] Cannot allocate resource for EISA slot 2 2011 Sep 23 14:45:41 kernel: [ 7.249552] Cannot allocate resource for EISA slot 3 2011 Sep 23 14:45:41 kernel: [ 7.249613] Cannot allocate resource for EISA slot 4 2011 Sep 23 14:45:41 kernel: [ 7.249674] Cannot allocate resource for EISA slot 5 2011 Sep 23 14:45:41 kernel: [ 7.249735] Cannot allocate resource for EISA slot 6 2011 Sep 23 14:45:41 kernel: [ 7.249796] Cannot allocate resource for EISA slot 7 2011 Sep 23 14:45:41 kernel: [ 7.249857] Cannot allocate resource for EISA slot 8 2011 Sep 23 14:45:41 kernel: [ 7.249918] EISA: Detected 0 cards. 2011 Sep 23 14:45:41 kernel: [ 7.249985] cpufreq-nforce2: No nForce2 chipset. 2011 Sep 23 14:45:41 kernel: [ 7.250046] cpuidle: using governor ladder 2011 Sep 23 14:45:41 kernel: [ 7.250105] cpuidle: using governor menu 2011 Sep 23 14:45:41 kernel: [ 7.250164] EFI Variables Facility v0.08 2004-May-17 2011 Sep 23 14:45:41 kernel: [ 7.250480] TCP cubic registered 2011 Sep 23 14:45:41 kernel: [ 7.250652] NET: Registered protocol family 10 2011 Sep 23 14:45:41 kernel: [ 7.251310] NET: Registered protocol family 17 2011 Sep 23 14:45:41 kernel: [ 7.251408] Bridge firewalling registered 2011 Sep 23 14:45:41 kernel: [ 7.251469] 802.1Q VLAN Support v1.8 2011 Sep 23 14:45:41 kernel: [ 7.251789] sctp: Hash tables configured (established 65536 bind 65536) 2011 Sep 23 14:45:41 kernel: [ 7.252012] Using IPI No-Shortcut mode 2011 Sep 23 14:45:41 kernel: [ 7.252140] PM: Hibernation image not present or could not be loaded. 2011 Sep 23 14:45:41 kernel: [ 7.252209] registered taskstats version 1 2011 Sep 23 14:45:41 kernel: [ 7.253231] Magic number: 11:467:789 2011 Sep 23 14:45:41 kernel: [ 7.253320] pci 0000:00:16.7: hash matches 2011 Sep 23 14:45:41 kernel: [ 7.253444] rtc_cmos 00:03: setting system clock to 2011-09-23 14:45:40 UTC (1316789140) 2011 Sep 23 14:45:41 kernel: [ 7.254484] BIOS EDD facility v0.16 2004-Jun-25, 0 devices found 2011 Sep 23 14:45:41 kernel: [ 7.254550] EDD information not available. 2011 Sep 23 14:45:41 kernel: [ 7.268475] input: AT Translated Set 2 keyboard as /devices/platform/i8042/serio0/input/input2 2011 Sep 23 14:45:41 kernel: [ 7.526608] ata3: SATA link down (SStatus 0 SControl 300) 2011 Sep 23 14:45:41 kernel: [ 7.537985] ata4: SATA link down (SStatus 0 SControl 300) 2011 Sep 23 14:45:41 kernel: [ 7.643268] usb 2-2: new high speed USB device number 2 using ehci_hcd 2011 Sep 23 14:45:41 kernel: [ 8.003362] ata1.00: SATA link up 3.0 Gbps (SStatus 123 SControl 300) 2011 Sep 23 14:45:41 kernel: [ 8.003448] ata1.01: SATA link up 3.0 Gbps (SStatus 123 SControl 300) 2011 Sep 23 14:45:41 kernel: [ 8.003685] ata2.00: SATA link up 3.0 Gbps (SStatus 123 SControl 300) 2011 Sep 23 14:45:41 kernel: [ 8.003768] ata2.01: SATA link down (SStatus 0 SControl 300) 2011 Sep 23 14:45:41 kernel: [ 8.011738] ata2.00: ATA-8: ST1000DL002-9TT153, CC32, max UDMA/133 2011 Sep 23 14:45:41 kernel: [ 8.011804] ata2.00: 1953525168 sectors, multi 16: LBA48 NCQ (depth 0/32) 2011 Sep 23 14:45:41 kernel: [ 8.015267] usb 4-1: new full speed USB device number 2 using uhci_hcd 2011 Sep 23 14:45:41 kernel: [ 8.019720] ata1.00: ATA-8: ST1000DL002-9TT153, CC32, max UDMA/133 2011 Sep 23 14:45:41 kernel: [ 8.019790] ata1.00: 1953525168 sectors, multi 16: LBA48 NCQ (depth 0/32) 2011 Sep 23 14:45:41 kernel: [ 8.020147] ata1.01: ATA-8: ST31000524AS, JC4B, max UDMA/133 2011 Sep 23 14:45:41 kernel: [ 8.020215] ata1.01: 1953525168 sectors, multi 16: LBA48 NCQ (depth 0/32) 2011 Sep 23 14:45:41 kernel: [ 8.027689] ata2.00: configured for UDMA/133 2011 Sep 23 14:45:41 kernel: [ 8.035690] ata1.00: configured for UDMA/133 2011 Sep 23 14:45:41 kernel: [ 8.051689] ata1.01: configured for UDMA/133 2011 Sep 23 14:45:41 kernel: [ 8.051889] scsi 0:0:0:0: Direct-Access ATA ST1000DL002-9TT1 CC32 PQ: 0 ANSI: 5 2011 Sep 23 14:45:41 kernel: [ 8.052112] sd 0:0:0:0: Attached scsi generic sg0 type 0 2011 Sep 23 14:45:41 kernel: [ 8.052192] sd 0:0:0:0: [sda] 1953525168 512-byte logical blocks: (1.00 TB/931 GiB) 2011 Sep 23 14:45:41 kernel: [ 8.052315] scsi 0:0:1:0: Direct-Access ATA ST31000524AS JC4B PQ: 0 ANSI: 5 2011 Sep 23 14:45:41 kernel: [ 8.052378] sd 0:0:0:0: [sda] Write Protect is off 2011 Sep 23 14:45:41 kernel: [ 8.052382] sd 0:0:0:0: [sda] Mode Sense: 00 3a 00 00 2011 Sep 23 14:45:41 kernel: [ 8.052419] sd 0:0:0:0: [sda] Write cache: enabled, read cache: enabled, doesn't support DPO or FUA 2011 Sep 23 14:45:41 kernel: [ 8.052704] sd 0:0:1:0: Attached scsi generic sg1 type 0 2011 Sep 23 14:45:41 kernel: [ 8.052925] scsi 1:0:0:0: Direct-Access ATA ST1000DL002-9TT1 CC32 PQ: 0 ANSI: 5 2011 Sep 23 14:45:41 kernel: [ 8.053125] sd 1:0:0:0: [sdc] 1953525168 512-byte logical blocks: (1.00 TB/931 GiB) 2011 Sep 23 14:45:41 kernel: [ 8.053134] sd 1:0:0:0: Attached scsi generic sg2 type 0 2011 Sep 23 14:45:41 kernel: [ 8.053368] sd 1:0:0:0: [sdc] Write Protect is off 2011 Sep 23 14:45:41 kernel: [ 8.053431] sd 1:0:0:0: [sdc] Mode Sense: 00 3a 00 00 2011 Sep 23 14:45:41 kernel: [ 8.053525] sd 1:0:0:0: [sdc] Write cache: enabled, read cache: enabled, doesn't support DPO or FUA 2011 Sep 23 14:45:41 kernel: [ 8.071818] sda: sda1 sda2 2011 Sep 23 14:45:41 kernel: [ 8.071834] sd 0:0:1:0: [sdb] 1953525168 512-byte logical blocks: (1.00 TB/931 GiB) 2011 Sep 23 14:45:41 kernel: [ 8.071920] sd 0:0:1:0: [sdb] Write Protect is off 2011 Sep 23 14:45:41 kernel: [ 8.071923] sd 0:0:1:0: [sdb] Mode Sense: 00 3a 00 00 2011 Sep 23 14:45:41 kernel: [ 8.071960] sd 0:0:1:0: [sdb] Write cache: enabled, read cache: enabled, doesn't support DPO or FUA 2011 Sep 23 14:45:41 kernel: [ 8.091537] sdb: sdb1 sdb2 2011 Sep 23 14:45:41 kernel: [ 8.091673] sd 0:0:0:0: [sda] Attached SCSI disk 2011 Sep 23 14:45:41 kernel: [ 8.091877] sd 0:0:1:0: [sdb] Attached SCSI disk 2011 Sep 23 14:45:41 kernel: [ 8.109152] sdc: sdc1 sdc2 < sdc5 > 2011 Sep 23 14:45:41 kernel: [ 8.109524] sd 1:0:0:0: [sdc] Attached SCSI disk 2011 Sep 23 14:45:41 kernel: [ 8.109845] Freeing unused kernel memory: 676k freed 2011 Sep 23 14:45:41 kernel: [ 8.111460] Write protecting the kernel text: 5080k 2011 Sep 23 14:45:41 kernel: [ 8.112055] Write protecting the kernel read-only data: 1936k 2011 Sep 23 14:45:41 kernel: [ 8.112119] NX-protecting the kernel data: 3112k 2011 Sep 23 14:45:41 kernel: [ 8.298828] udevd (87): /proc/87/oom_adj is deprecated, please use /proc/87/oom_score_adj instead. 2011 Sep 23 14:45:41 kernel: [ 8.518455] dca service started, version 1.12.1 2011 Sep 23 14:45:41 kernel: [ 8.519117] ioatdma: Intel(R) QuickData Technology Driver 4.00 2011 Sep 23 14:45:41 kernel: [ 8.519179] xen: registering gsi 43 triggering 0 polarity 1 2011 Sep 23 14:45:41 kernel: [ 8.519192] xen: --> pirq=43 -> irq=43 (gsi=43) 2011 Sep 23 14:45:41 kernel: [ 8.519206] ioatdma 0000:00:16.0: PCI INT A -> GSI 43 (level, low) -> IRQ 43 2011 Sep 23 14:45:41 kernel: [ 8.519242] ioatdma 0000:00:16.0: setting latency timer to 64 2011 Sep 23 14:45:41 kernel: [ 8.595485] xen: registering gsi 44 triggering 0 polarity 1 2011 Sep 23 14:45:41 kernel: [ 8.595500] xen: --> pirq=44 -> irq=44 (gsi=44) 2011 Sep 23 14:45:41 kernel: [ 8.595512] ioatdma 0000:00:16.1: PCI INT B -> GSI 44 (level, low) -> IRQ 44 2011 Sep 23 14:45:41 kernel: [ 8.595551] ioatdma 0000:00:16.1: setting latency timer to 64 2011 Sep 23 14:45:41 kernel: [ 8.607452] xen: registering gsi 45 triggering 0 polarity 1 2011 Sep 23 14:45:41 kernel: [ 8.607463] xen: --> pirq=45 -> irq=45 (gsi=45) 2011 Sep 23 14:45:41 kernel: [ 8.607473] ioatdma 0000:00:16.2: PCI INT C -> GSI 45 (level, low) -> IRQ 45 2011 Sep 23 14:45:41 kernel: [ 8.607502] ioatdma 0000:00:16.2: setting latency timer to 64 2011 Sep 23 14:45:41 kernel: [ 8.608187] xen: registering gsi 46 triggering 0 polarity 1 2011 Sep 23 14:45:41 kernel: [ 8.608197] xen: --> pirq=46 -> irq=46 (gsi=46) 2011 Sep 23 14:45:41 kernel: [ 8.608206] ioatdma 0000:00:16.3: PCI INT D -> GSI 46 (level, low) -> IRQ 46 2011 Sep 23 14:45:41 kernel: [ 8.608233] ioatdma 0000:00:16.3: setting latency timer to 64 2011 Sep 23 14:45:41 kernel: [ 8.615463] xen: registering gsi 43 triggering 0 polarity 1 2011 Sep 23 14:45:41 kernel: [ 8.615469] xen_map_pirq_gsi: returning irq 43 for gsi 43 2011 Sep 23 14:45:41 kernel: [ 8.615472] xen: --> pirq=43 -> irq=43 (gsi=43) 2011 Sep 23 14:45:41 kernel: [ 8.615477] Already setup the GSI :43 2011 Sep 23 14:45:41 kernel: [ 8.615481] ioatdma 0000:00:16.4: PCI INT A -> GSI 43 (level, low) -> IRQ 43 2011 Sep 23 14:45:41 kernel: [ 8.615511] ioatdma 0000:00:16.4: setting latency timer to 64 2011 Sep 23 14:45:41 kernel: [ 8.626660] EDAC MC: Ver: 2.1.0 2011 Sep 23 14:45:41 kernel: [ 8.631467] xen: registering gsi 44 triggering 0 polarity 1 2011 Sep 23 14:45:41 kernel: [ 8.631473] xen_map_pirq_gsi: returning irq 44 for gsi 44 2011 Sep 23 14:45:41 kernel: [ 8.631476] xen: --> pirq=44 -> irq=44 (gsi=44) 2011 Sep 23 14:45:41 kernel: [ 8.631482] Already setup the GSI :44 2011 Sep 23 14:45:41 kernel: [ 8.631486] ioatdma 0000:00:16.5: PCI INT B -> GSI 44 (level, low) -> IRQ 44 2011 Sep 23 14:45:41 kernel: [ 8.631518] ioatdma 0000:00:16.5: setting latency timer to 64 2011 Sep 23 14:45:41 kernel: [ 8.632755] xen: registering gsi 45 triggering 0 polarity 1 2011 Sep 23 14:45:41 kernel: [ 8.632760] xen_map_pirq_gsi: returning irq 45 for gsi 45 2011 Sep 23 14:45:41 kernel: [ 8.632763] xen: --> pirq=45 -> irq=45 (gsi=45) 2011 Sep 23 14:45:41 kernel: [ 8.632768] Already setup the GSI :45 2011 Sep 23 14:45:41 kernel: [ 8.632772] ioatdma 0000:00:16.6: PCI INT C -> GSI 45 (level, low) -> IRQ 45 2011 Sep 23 14:45:41 kernel: [ 8.632800] ioatdma 0000:00:16.6: setting latency timer to 64 2011 Sep 23 14:45:41 kernel: [ 8.643460] xen: registering gsi 46 triggering 0 polarity 1 2011 Sep 23 14:45:41 kernel: [ 8.643465] xen_map_pirq_gsi: returning irq 46 for gsi 46 2011 Sep 23 14:45:41 kernel: [ 8.643468] xen: --> pirq=46 -> irq=46 (gsi=46) 2011 Sep 23 14:45:41 kernel: [ 8.643473] Already setup the GSI :46 2011 Sep 23 14:45:41 kernel: [ 8.643477] ioatdma 0000:00:16.7: PCI INT D -> GSI 46 (level, low) -> IRQ 46 2011 Sep 23 14:45:41 kernel: [ 8.643508] ioatdma 0000:00:16.7: setting latency timer to 64 2011 Sep 23 14:45:41 kernel: [ 8.663491] EDAC MC0: Giving out device to 'i7core_edac.c' 'i7 core #0': DEV 0000:ff:03.0 2011 Sep 23 14:45:41 kernel: [ 8.663510] EDAC PCI0: Giving out device to module 'i7core_edac' controller 'EDAC PCI controller': DEV '0000:ff:03.0' (POLLED) 2011 Sep 23 14:45:41 kernel: [ 8.663514] EDAC i7core: Driver loaded. 2011 Sep 23 14:45:41 kernel: [ 8.686737] e1000e: Intel(R) PRO/1000 Network Driver - 1.3.10-k2 2011 Sep 23 14:45:41 kernel: [ 8.686742] e1000e: Copyright(c) 1999 - 2011 Intel Corporation. 2011 Sep 23 14:45:41 kernel: [ 8.686775] e1000e 0000:06:00.0: Disabling ASPM L0s 2011 Sep 23 14:45:41 kernel: [ 8.686794] xen: registering gsi 16 triggering 0 polarity 1 2011 Sep 23 14:45:41 kernel: [ 8.686799] xen_map_pirq_gsi: returning irq 16 for gsi 16 2011 Sep 23 14:45:41 kernel: [ 8.686802] xen: --> pirq=16 -> irq=16 (gsi=16) 2011 Sep 23 14:45:41 kernel: [ 8.686808] Already setup the GSI :16 2011 Sep 23 14:45:41 kernel: [ 8.686813] e1000e 0000:06:00.0: PCI INT A -> GSI 16 (level, low) -> IRQ 16 2011 Sep 23 14:45:41 kernel: [ 8.686846] e1000e 0000:06:00.0: setting latency timer to 64 2011 Sep 23 14:45:42 kernel: [ 8.789672] iTCO_vendor_support: vendor-support=0 2011 Sep 23 14:45:42 kernel: [ 8.790054] iTCO_wdt: Intel TCO WatchDog Timer Driver v1.06 2011 Sep 23 14:45:42 kernel: [ 8.790166] iTCO_wdt: Found a ICH10R TCO device (Version=2, TCOBASE=0x0860) 2011 Sep 23 14:45:42 kernel: [ 8.790232] iTCO_wdt: initialized. heartbeat=30 sec (nowayout=0) 2011 Sep 23 14:45:42 kernel: [ 8.887375] Initializing USB Mass Storage driver... 2011 Sep 23 14:45:42 kernel: [ 8.903262] scsi4 : usb-storage 2-2:1.0 2011 Sep 23 14:45:42 kernel: [ 8.904033] input: Winbond Electronics Corp Hermon USB hidmouse Device as /devices/pci0000:00/0000:00:1a.1/usb4/4-1/4-1:1.1/input/input3 2011 Sep 23 14:45:42 kernel: [ 8.904099] usbcore: registered new interface driver usbkbd 2011 Sep 23 14:45:42 kernel: [ 8.904103] usbkbd: :USB HID Boot Protocol keyboard driver 2011 Sep 23 14:45:42 kernel: [ 8.906568] usbcore: registered new interface driver usb-storage 2011 Sep 23 14:45:42 kernel: [ 8.906572] USB Mass Storage support registered. 2011 Sep 23 14:45:42 kernel: [ 8.906868] usbcore: registered new interface driver uas 2011 Sep 23 14:45:42 kernel: [ 8.931538] input: Winbond Electronics Corp Hermon USB hidmouse Device as /devices/pci0000:00/0000:00:1a.1/usb4/4-1/4-1:1.0/input/input4 2011 Sep 23 14:45:42 kernel: [ 8.931632] generic-usb 0003:0557:2221.0001: input,hidraw0: USB HID v1.00 Mouse [Winbond Electronics Corp Hermon USB hidmouse Device] on usb-0000:00:1a.1-1/input0 2011 Sep 23 14:45:42 kernel: [ 8.931658] usbcore: registered new interface driver usbhid 2011 Sep 23 14:45:42 kernel: [ 8.931662] usbhid: USB HID core driver 2011 Sep 23 14:45:42 kernel: [ 8.936136] usbcore: registered new interface driver usbmouse 2011 Sep 23 14:45:42 kernel: [ 8.936139] usbmouse: v1.6:USB HID Boot Protocol mouse driver 2011 Sep 23 14:45:42 kernel: [ 8.936526] input: PC Speaker as /devices/platform/pcspkr/input/input5 2011 Sep 23 14:45:42 kernel: [ 8.956157] e1000e 0000:06:00.0: eth0: (PCI Express:2.5GT/s:Width x1) 00:25:90:38:d8:2c 2011 Sep 23 14:45:42 kernel: [ 8.956162] e1000e 0000:06:00.0: eth0: Intel(R) PRO/1000 Network Connection 2011 Sep 23 14:45:42 kernel: [ 8.956250] e1000e 0000:06:00.0: eth0: MAC: 3, PHY: 8, PBA No: 0101FF-0FF 2011 Sep 23 14:45:42 kernel: [ 8.959590] [Firmware Warn]: GHES: Poll interval is 0 for generic hardware error source: 1, disabled. 2011 Sep 23 14:45:42 kernel: [ 8.968922] xen: registering gsi 18 triggering 0 polarity 1 2011 Sep 23 14:45:42 kernel: [ 8.968929] xen_map_pirq_gsi: returning irq 18 for gsi 18 2011 Sep 23 14:45:42 kernel: [ 8.968932] xen: --> pirq=18 -> irq=18 (gsi=18) 2011 Sep 23 14:45:42 kernel: [ 8.968939] Already setup the GSI :18 2011 Sep 23 14:45:42 kernel: [ 8.968943] i801_smbus 0000:00:1f.3: PCI INT C -> GSI 18 (level, low) -> IRQ 18 2011 Sep 23 14:45:42 kernel: [ 8.975650] e1000e 0000:07:00.0: Disabling ASPM L0s 2011 Sep 23 14:45:42 kernel: [ 8.975666] xen: registering gsi 17 triggering 0 polarity 1 2011 Sep 23 14:45:42 kernel: [ 8.975670] xen_map_pirq_gsi: returning irq 17 for gsi 17 2011 Sep 23 14:45:42 kernel: [ 8.975673] xen: --> pirq=17 -> irq=17 (gsi=17) 2011 Sep 23 14:45:42 kernel: [ 8.975678] Already setup the GSI :17 2011 Sep 23 14:45:42 kernel: [ 8.975682] e1000e 0000:07:00.0: PCI INT A -> GSI 17 (level, low) -> IRQ 17 2011 Sep 23 14:45:42 kernel: [ 8.975714] e1000e 0000:07:00.0: setting latency timer to 64 2011 Sep 23 14:45:42 kernel: [ 9.083625] e1000e 0000:07:00.0: eth1: (PCI Express:2.5GT/s:Width x1) 00:25:90:38:d8:2d 2011 Sep 23 14:45:42 kernel: [ 9.083630] e1000e 0000:07:00.0: eth1: Intel(R) PRO/1000 Network Connection 2011 Sep 23 14:45:42 kernel: [ 9.083717] e1000e 0000:07:00.0: eth1: MAC: 3, PHY: 8, PBA No: 0101FF-0FF 2011 Sep 23 14:45:43 kernel: [ 9.904128] scsi 4:0:0:0: Direct-Access Kingston DataTraveler G2 8.20 PQ: 0 ANSI: 2 2011 Sep 23 14:45:43 kernel: [ 10.291445] sd 4:0:0:0: Attached scsi generic sg3 type 0 2011 Sep 23 14:45:43 kernel: [ 10.292237] sd 4:0:0:0: [sdd] 3870720 512-byte logical blocks: (1.98 GB/1.84 GiB) 2011 Sep 23 14:45:43 kernel: [ 10.293580] sd 4:0:0:0: [sdd] Write Protect is off 2011 Sep 23 14:45:43 kernel: [ 10.293585] sd 4:0:0:0: [sdd] Mode Sense: 23 00 00 00 2011 Sep 23 14:45:43 kernel: [ 10.294210] sd 4:0:0:0: [sdd] No Caching mode page present 2011 Sep 23 14:45:43 kernel: [ 10.294215] sd 4:0:0:0: [sdd] Assuming drive cache: write through 2011 Sep 23 14:45:43 kernel: [ 10.296959] sd 4:0:0:0: [sdd] No Caching mode page present 2011 Sep 23 14:45:43 kernel: [ 10.296964] sd 4:0:0:0: [sdd] Assuming drive cache: write through 2011 Sep 23 14:45:43 kernel: [ 10.297736] sdd: sdd1 2011 Sep 23 14:45:43 kernel: [ 10.299950] sd 4:0:0:0: [sdd] No Caching mode page present 2011 Sep 23 14:45:43 kernel: [ 10.299954] sd 4:0:0:0: [sdd] Assuming drive cache: write through 2011 Sep 23 14:45:43 kernel: [ 10.299958] sd 4:0:0:0: [sdd] Attached SCSI removable disk 2011 Sep 23 14:45:45 kernel: [ 12.146359] EXT3-fs: barriers not enabled 2011 Sep 23 14:45:45 kernel: [ 12.146746] kjournald starting. Commit interval 5 seconds 2011 Sep 23 14:45:45 kernel: [ 12.146765] EXT3-fs (sda1): mounted filesystem with ordered data mode 2011 Sep 23 14:45:45 kernel: [ 12.169820] EXT3-fs: barriers not enabled 2011 Sep 23 14:45:45 kernel: [ 12.170094] kjournald starting. Commit interval 5 seconds 2011 Sep 23 14:45:45 kernel: [ 12.170112] EXT3-fs (sdb1): mounted filesystem with ordered data mode 2011 Sep 23 14:45:45 kernel: [ 12.213887] EXT3-fs (sdc1): error: couldn't mount because of unsupported optional features (240) 2011 Sep 23 14:45:45 kernel: [ 12.264394] EXT2-fs (sdc1): error: couldn't mount because of unsupported optional features (240) 2011 Sep 23 14:45:45 kernel: [ 12.388790] EXT4-fs (sdc1): mounted filesystem with ordered data mode. Opts: (null) 2011 Sep 23 14:45:51 syslog-ng[77]: syslog-ng version 1.6.12 going down 2011 Sep 23 15:45:52 syslog-ng[449]: syslog-ng version 1.6.12 starting 2011 Sep 23 15:45:53 kernel: klogd 1.5.0, log source = /proc/kmsg started. 2011 Sep 23 15:45:53 kernel: Cannot find map file. 2011 Sep 23 15:45:53 kernel: Loaded 60396 symbols from 18 modules. 2011 Sep 23 15:45:53 kernel: [ 20.107257] udev: starting version 151 2011 Sep 23 15:45:53 kernel: [ 20.563596] md: bind<sdb1> 2011 Sep 23 15:45:53 kernel: [ 20.570257] md: bind<sda1> 2011 Sep 23 15:45:53 kernel: [ 20.580738] md: bind<sdb2> 2011 Sep 23 15:45:53 kernel: [ 20.586761] md: bind<sda2> 2011 Sep 23 15:45:55 xenstored: Checking store ... 2011 Sep 23 15:45:55 xenstored: Checking store complete. 2011 Sep 23 15:45:55 kernel: [ 22.457006] XENBUS: Unable to read cpu state 2011 Sep 23 15:45:55 kernel: [ 22.457174] XENBUS: Unable to read cpu state 2011 Sep 23 15:45:55 kernel: [ 22.457329] XENBUS: Unable to read cpu state 2011 Sep 23 15:45:55 kernel: [ 22.457486] XENBUS: Unable to read cpu state 2011 Sep 23 15:45:56 BLKTAPCTRL[761]: blktapctrl.c:790: blktapctrl: v1.0.0 2011 Sep 23 15:45:56 BLKTAPCTRL[761]: blktapctrl.c:792: Found driver: [raw image (aio)] 2011 Sep 23 15:45:56 BLKTAPCTRL[761]: blktapctrl.c:792: Found driver: [raw image (sync)] 2011 Sep 23 15:45:56 BLKTAPCTRL[761]: blktapctrl.c:792: Found driver: [vmware image (vmdk)] 2011 Sep 23 15:45:56 BLKTAPCTRL[761]: blktapctrl.c:792: Found driver: [ramdisk image (ram)] 2011 Sep 23 15:45:56 BLKTAPCTRL[761]: blktapctrl.c:792: Found driver: [qcow disk (qcow)] 2011 Sep 23 15:45:56 BLKTAPCTRL[761]: blktapctrl.c:792: Found driver: [qcow2 disk (qcow2)] 2011 Sep 23 15:45:56 BLKTAPCTRL[761]: blktapctrl_linux.c:86: blktap0 open failed 2011 Sep 23 15:45:56 BLKTAPCTRL[761]: blktapctrl.c:859: couldn't open blktap interface 2011 Sep 23 15:45:56 BLKTAPCTRL[761]: blktapctrl.c:922: Unable to start blktapctrl 2011 Sep 23 15:45:58 kernel: [ 26.063959] Ebtables v2.0 registered 2011 Sep 23 15:45:58 kernel: [ 26.159717] ip_tables: (C) 2000-2006 Netfilter Core Team 2011 Sep 23 15:45:59 init: Entering runlevel: 3 2011 Sep 23 15:45:59 ntpd[1022]: ntpd 4.2.6p3@1.2290-o Wed Sep 21 08:28:39 UTC 2011 (1) 2011 Sep 23 15:45:59 ntpd[1023]: proto: precision = 0.429 usec 2011 Sep 23 15:45:59 ntpd[1023]: ntp_io: estimated max descriptors: 1024, initial socket boundary: 16 2011 Sep 23 15:45:59 ntpd[1023]: Listen and drop on 0 v4wildcard 0.0.0.0 UDP 123 2011 Sep 23 15:45:59 ntpd[1023]: Listen and drop on 1 v6wildcard :: UDP 123 2011 Sep 23 15:45:59 ntpd[1023]: Listen normally on 2 lo 127.0.0.1 UDP 123 2011 Sep 23 15:45:59 ntpd[1023]: Listen normally on 3 lo ::1 UDP 123 2011 Sep 23 15:45:59 ntpd[1023]: peers refreshed 2011 Sep 23 15:45:59 ntpd[1023]: Deferring DNS for 01.ntp.overnetdata.net 1 2011 Sep 23 15:46:03 login[1044]: ROOT LOGIN on '/dev/tty2' --------------050307050103030702000305 Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel --------------050307050103030702000305-- From xen-devel-bounces@lists.xensource.com Fri Sep 23 07:55:15 2011 Return-path: <xen-devel-bounces@lists.xensource.com> Envelope-to: www-data@lists.xensource.com Delivery-date: Fri, 23 Sep 2011 07:55:15 -0700 Received: from localhost ([127.0.0.1] helo=lists.colo.xensource.com) by lists.xensource.com with esmtp (Exim 4.43) id 1R779n-0006q8-D3; Fri, 23 Sep 2011 07:55:15 -0700 Received: from mail27.messagelabs.com ([193.109.254.147]) by lists.xensource.com with esmtp (Exim 4.43) id 1R777M-00069K-7y for xen-devel@lists.xensource.com; Fri, 23 Sep 2011 07:52:44 -0700 X-Env-Sender: javier.manzano@edu.uah.es X-Msg-Ref: server-11.tower-27.messagelabs.com!1316789551!38647093!1 X-Originating-IP: [216.139.236.26] X-StarScan-Version: 6.4.1; banners=-,-,- X-VirusChecked: Checked Received: (qmail 887 invoked from network); 23 Sep 2011 14:52:32 -0000 Received: from sam.nabble.com (HELO sam.nabble.com) (216.139.236.26) by server-11.tower-27.messagelabs.com with AES256-SHA encrypted SMTP; 23 Sep 2011 14:52:32 -0000 Received: from [192.168.236.26] (helo=sam.nabble.com) by sam.nabble.com with esmtp (Exim 4.72) (envelope-from <javier.manzano@edu.uah.es>) id 1R777H-0003Ia-Ms for xen-devel@lists.xensource.com; Fri, 23 Sep 2011 07:52:39 -0700 Date: Fri, 23 Sep 2011 07:52:39 -0700 (PDT) From: JavMV <javier.manzano@edu.uah.es> To: xen-devel@lists.xensource.com Message-ID: <1316789559703-4833862.post@n5.nabble.com> In-Reply-To: <1316786412428-4833637.post@n5.nabble.com> References: <1316615526442-4826582.post@n5.nabble.com> <1316616001843-4826614.post@n5.nabble.com> <1316616472579-4826635.post@n5.nabble.com> <1316616757871-4826655.post@n5.nabble.com> <1316618006.67296.YahooMailNeo@web29818.mail.ird.yahoo.com> <1316693722029-4829929.post@n5.nabble.com> <20110922182705.GE12984@reaktio.net> <1316728444821-4831624.post@n5.nabble.com> <1316777654598-4833174.post@n5.nabble.com> <1316786412428-4833637.post@n5.nabble.com> Subject: Re: Re : Re : Re : Re : [Xen-devel] Re: Patches for VGA-Passthrough XEN 4.2 unstable MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-BeenThere: xen-devel@lists.xensource.com X-Mailman-Version: 2.1.5 Precedence: list List-Id: Xen developer discussion <xen-devel.lists.xensource.com> List-Unsubscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe> List-Post: <mailto:xen-devel@lists.xensource.com> List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help> List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=subscribe> Sender: xen-devel-bounces@lists.xensource.com Errors-To: xen-devel-bounces@lists.xensource.com Am I still able to use gfx_passthru if I get this messages from xm dmesg?: ... (XEN) Intel VT-d Snoop Control not enabled. (XEN) Intel VT-d Dom0 DMA Passthrough not enabled. (XEN) Intel VT-d Queued Invalidation not enabled. (XEN) Intel VT-d Interrupt Remapping not enabled. (XEN) [VT-D]iommu.c:847: iommu_fault_status: Fault Overflow (XEN) [VT-D]iommu.c:850: iommu_fault_status: Primary Pending Fault (XEN) [VT-D]iommu.c:825: DMAR:[DMA Write] Request device [00:02.0] fault addr ffffff000, iommu reg = fff16000 ... (XEN) Enabling APIC mode: Flat. Using 1 I/O APICs (XEN) I/O virtualisation enabled ... I can see I/O enabled but all the VT-d features are disabled, so maybe that's why with the last revision of XEN I can't have I/O virtualisation enabled, anyone have an answer? Thanks in advance ----- JavMV -- View this message in context: http://xen.1045712.n5.nabble.com/Patches-for-VGA-Passthrough-XEN-4-2-unstable-tp4406265p4833862.html Sent from the Xen - Dev mailing list archive at Nabble.com. _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel From xen-devel-bounces@lists.xensource.com Fri Sep 23 07:59:44 2011 Return-path: <xen-devel-bounces@lists.xensource.com> Envelope-to: www-data@lists.xensource.com Delivery-date: Fri, 23 Sep 2011 07:59:44 -0700 Received: from localhost ([127.0.0.1] helo=lists.colo.xensource.com) by lists.xensource.com with esmtp (Exim 4.43) id 1R77E6-0007Hr-KM; Fri, 23 Sep 2011 07:59:43 -0700 Received: from mail182.messagelabs.com ([85.158.139.83]) by lists.xensource.com with esmtp (Exim 4.43) id 1R77CS-00074F-U0 for xen-devel@lists.xensource.com; Fri, 23 Sep 2011 07:58:01 -0700 X-Env-Sender: Ian.Jackson@eu.citrix.com X-Msg-Ref: server-11.tower-182.messagelabs.com!1316789877!19503330!1 X-Originating-IP: [62.200.22.115] X-StarScan-Version: 6.4.1; banners=-,-,- X-VirusChecked: Checked Received: (qmail 31977 invoked from network); 23 Sep 2011 14:57:57 -0000 Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115) by server-11.tower-182.messagelabs.com with RC4-SHA encrypted SMTP; 23 Sep 2011 14:57:57 -0000 X-IronPort-AV: E=Sophos;i="4.68,430,1312156800"; d="scan'208";a="8033274" Received: from lonpmailmx01.citrite.net ([10.30.203.162]) by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5; 23 Sep 2011 14:57:57 +0000 Received: from woking.xci-test.com (10.80.248.135) by smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id 8.3.137.0; Fri, 23 Sep 2011 15:57:57 +0100 Received: from osstest by woking.xci-test.com with local (Exim 4.69) (envelope-from <ian.jackson@eu.citrix.com>) id 1R77CN-0007sb-4r; Fri, 23 Sep 2011 15:57:56 +0100 To: xen-devel@lists.xensource.com Message-ID: <osstest-9044-mainreport@xen.org> From: xen.org <ian.jackson@eu.citrix.com> Date: Fri, 23 Sep 2011 15:57:55 +0100 MIME-Version: 1.0 Content-Type: text/plain Cc: ian.jackson@eu.citrix.com Subject: [Xen-devel] [linux test] 9044: tolerable FAIL X-BeenThere: xen-devel@lists.xensource.com X-Mailman-Version: 2.1.5 Precedence: list List-Id: Xen developer discussion <xen-devel.lists.xensource.com> List-Unsubscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe> List-Post: <mailto:xen-devel@lists.xensource.com> List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help> List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=subscribe> Sender: xen-devel-bounces@lists.xensource.com Errors-To: xen-devel-bounces@lists.xensource.com flight 9044 linux real [real] http://www.chiark.greenend.org.uk/~xensrcts/logs/9044/ Failures :-/ but no regressions. Tests which did not succeed, but are not blocking, including regressions (tests previously passed) regarded as allowable: test-amd64-amd64-xl-pcipt-intel 9 guest-start fail never pass test-amd64-i386-rhel6hvm-amd 9 guest-start.2 fail never pass test-amd64-i386-rhel6hvm-intel 9 guest-start.2 fail never pass test-amd64-i386-win-vcpus1 16 leak-check/check fail never pass test-amd64-i386-xl-win-vcpus1 13 guest-stop fail never pass test-amd64-amd64-win 16 leak-check/check fail never pass test-amd64-amd64-xl-win 13 guest-stop fail never pass test-i386-i386-xl-win 13 guest-stop fail never pass test-i386-i386-win 16 leak-check/check fail never pass test-amd64-i386-win 16 leak-check/check fail never pass version targeted for testing: linux 6bec8b4a4c14095d0b7ce424db9d583c3decae6c baseline version: linux 1c3f03ccc5258887f5f2cafc0836a865834f9205 ------------------------------------------------------------ People who touched revisions under test: Jeremy Fitzhardinge <jeremy.fitzhardinge@citrix.com> ------------------------------------------------------------ jobs: build-amd64 pass build-i386 pass build-amd64-pvops pass build-i386-pvops pass test-amd64-amd64-xl pass test-amd64-i386-xl pass test-i386-i386-xl pass test-amd64-i386-rhel6hvm-amd fail test-amd64-i386-xl-credit2 pass test-amd64-amd64-xl-pcipt-intel fail test-amd64-i386-rhel6hvm-intel fail test-amd64-i386-xl-multivcpu pass test-amd64-amd64-pair pass test-amd64-i386-pair pass test-i386-i386-pair pass test-amd64-amd64-pv pass test-amd64-i386-pv pass test-i386-i386-pv pass test-amd64-amd64-xl-sedf pass test-amd64-i386-win-vcpus1 fail test-amd64-i386-xl-win-vcpus1 fail test-amd64-amd64-win fail test-amd64-i386-win fail test-i386-i386-win fail test-amd64-amd64-xl-win fail test-i386-i386-xl-win fail ------------------------------------------------------------ sg-report-flight on woking.cam.xci-test.com logs: /home/xc_osstest/logs images: /home/xc_osstest/images Logs, config files, etc. are available at http://www.chiark.greenend.org.uk/~xensrcts/logs Test harness code can be found at http://xenbits.xensource.com/gitweb?p=osstest.git;a=summary Pushing revision : + branch=linux + revision=6bec8b4a4c14095d0b7ce424db9d583c3decae6c + . cri-lock-repos ++ . cri-common +++ umask 002 +++ getconfig Repos +++ perl -e ' use Osstest; readconfigonly(); print $c{Repos} or die $!; ' ++ repos=/export/home/osstest/repos ++ repos_lock=/export/home/osstest/repos/lock ++ '[' x '!=' x/export/home/osstest/repos/lock ']' ++ OSSTEST_REPOS_LOCK_LOCKED=/export/home/osstest/repos/lock ++ exec with-lock-ex -w /export/home/osstest/repos/lock ./ap-push linux 6bec8b4a4c14095d0b7ce424db9d583c3decae6c + branch=linux + revision=6bec8b4a4c14095d0b7ce424db9d583c3decae6c + . cri-lock-repos ++ . cri-common +++ umask 002 +++ getconfig Repos +++ perl -e ' use Osstest; readconfigonly(); print $c{Repos} or die $!; ' ++ repos=/export/home/osstest/repos ++ repos_lock=/export/home/osstest/repos/lock ++ '[' x/export/home/osstest/repos/lock '!=' x/export/home/osstest/repos/lock ']' + : xen@xenbits.xensource.com + : xen@xenbits.xensource.com:git/linux-pvops + : master + : tested/2.6.39.x + case "$branch" in + cd /export/home/osstest/repos/xen ./ap-push: line 20: cd: /export/home/osstest/repos/xen: No such file or directory ------------------------------------------------------------ commit 6bec8b4a4c14095d0b7ce424db9d583c3decae6c Author: Jeremy Fitzhardinge <jeremy.fitzhardinge@citrix.com> Date: Fri Sep 2 12:23:22 2011 -0700 Revert "xen/apic: Provide an 'apic_xen' to set the override the apic->[read|write] for all cases." This reverts commit c3dd7941354fa96a71f2613e2c7a1b215fa175dc. It prevents the kernel from booting natively on hardware. Conflicts: arch/x86/xen/enlighten.c Signed-off-by: Jeremy Fitzhardinge <jeremy.fitzhardinge@citrix.com> _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel From xen-devel-bounces@lists.xensource.com Fri Sep 23 08:17:43 2011 Return-path: <xen-devel-bounces@lists.xensource.com> Envelope-to: www-data@lists.xensource.com Delivery-date: Fri, 23 Sep 2011 08:17:43 -0700 Received: from localhost ([127.0.0.1] helo=lists.colo.xensource.com) by lists.xensource.com with esmtp (Exim 4.43) id 1R77VX-00028D-AK; Fri, 23 Sep 2011 08:17:43 -0700 Received: from mail216.messagelabs.com ([85.158.143.99]) by lists.xensource.com with esmtp (Exim 4.43) id 1R77Nl-00005L-6h for xen-devel@lists.xensource.com; Fri, 23 Sep 2011 08:09:42 -0700 X-Env-Sender: d.vrabel.98@gmail.com X-Msg-Ref: server-3.tower-216.messagelabs.com!1316790577!18349384!1 X-Originating-IP: [209.85.160.171] X-StarScan-Version: 6.4.1; banners=-,-,- X-VirusChecked: Checked Received: (qmail 16660 invoked from network); 23 Sep 2011 15:09:38 -0000 Received: from mail-gy0-f171.google.com (HELO mail-gy0-f171.google.com) (209.85.160.171) by server-3.tower-216.messagelabs.com with RC4-SHA encrypted SMTP; 23 Sep 2011 15:09:38 -0000 Received: by gyh3 with SMTP id 3so4039060gyh.30 for <xen-devel@lists.xensource.com>; Fri, 23 Sep 2011 08:09:37 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=sender:message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:content-type:content-transfer-encoding; bh=6nHTT7q/7NbNVprcsVAxPrajzbdF80TvIJOQXgusUiA=; b=bjK54F8hUEVGQH2qoh+1bpGdR0/vjPYe1ej0lbiwyBKoTKTWjODrkdiRhdmJTVx7Z0 pqP0qNnLS84VsFFgD9h2qXXY7GfsAoKkyxdwAqt3vIV1qwHQzNH34Tas4XgoGvVuStaG 8px66EBKLN3eCSXPp72xtYoHlrs+WPZQdeXvk= Received: by 10.236.156.67 with SMTP id l43mr3943389yhk.10.1316790576406; Fri, 23 Sep 2011 08:09:36 -0700 (PDT) Received: from [10.80.2.76] (firewall.ctxuk.citrix.com. [62.200.22.2]) by mx.google.com with ESMTPS id s77sm16687293yhe.22.2011.09.23.08.09.32 (version=SSLv3 cipher=OTHER); Fri, 23 Sep 2011 08:09:34 -0700 (PDT) Message-ID: <4E7CA1BA.5020701@cantab.net> Date: Fri, 23 Sep 2011 16:11:54 +0100 From: David Vrabel <dvrabel@cantab.net> User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.1.16) Gecko/20110818 Icedove/3.0.11 MIME-Version: 1.0 To: David Vrabel <david.vrabel@citrix.com> Subject: Re: [Xen-devel] Re: [PATCH 0/6] xen: don't call vmalloc_sync_all() when mapping foreign pages References: <1316090411-22608-1-git-send-email-david.vrabel@citrix.com> <4E727017.4030001@goop.org> <4E79F867.2020909@citrix.com> In-Reply-To: <4E79F867.2020909@citrix.com> Content-Type: text/plain; charset=ISO-8859-15 Content-Transfer-Encoding: 7bit Cc: linux-kernel@vger.kernel.org, Jeremy Fitzhardinge <jeremy@goop.org>, xen-devel@lists.xensource.com, Andrew Morton <akpm@linux-foundation.org>, Konrad Rzeszutek Wilk <konrad.wilk@oracle.com> X-BeenThere: xen-devel@lists.xensource.com X-Mailman-Version: 2.1.5 Precedence: list List-Id: Xen developer discussion <xen-devel.lists.xensource.com> List-Unsubscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe> List-Post: <mailto:xen-devel@lists.xensource.com> List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help> List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=subscribe> Sender: xen-devel-bounces@lists.xensource.com Errors-To: xen-devel-bounces@lists.xensource.com On 21/09/11 15:44, David Vrabel wrote: > On 15/09/11 22:37, Jeremy Fitzhardinge wrote: >> On 09/15/2011 05:40 AM, David Vrabel wrote: >>> This set of pages avoids the need to call vmalloc_sync_all() when >>> mapping foreign pages. Two new functions are adding for mapping >>> foreign pages onto RAM pages instead of vmalloc space. >>> >>> [...] >> >> But that said, if you want to allocate virtual addresses for mapping >> granted pages, then alloc_vm_area() is the right thing to use. You need >> to make sure you touch the pages from within the kernel before passing >> those addresses to a hypercall to make sure the mappings are established >> within the current task (possibly within a no-preempt region to >> guarantee that nothing odd happens). Or alternatively, you could switch >> the current pagetable to init_mm for the hypercall (if it isn't already) >> - since that's the reference pagetable - assuming you're not passing >> usermode virtual addresses to the hypercall. > > Making alloc_vm_area() fill in a array of pte_t *'s and passing the pointer > to the PTE (using the GNTMAP_contains_pte flag) in the hypercall should > allow Xen to update the PTEs in init_mm directly. > > However, I'm not sure what to do about ia64 where GNTMAP_contains_pte > is not supported. Any ideas? > > Here's the untested patch I have so far. This (sort of) works with some hacks/changes (described below). > diff --git a/arch/x86/xen/grant-table.c b/arch/x86/xen/grant-table.c > index 49ba9b5..77348e8 100644 > --- a/arch/x86/xen/grant-table.c > +++ b/arch/x86/xen/grant-table.c > @@ -71,7 +71,7 @@ int arch_gnttab_map_shared(unsigned long *frames, unsigned long nr_gframes, > > if (shared == NULL) { > struct vm_struct *area = > - alloc_vm_area(PAGE_SIZE * max_nr_gframes); > + alloc_vm_area(PAGE_SIZE * max_nr_gframes, NULL); > BUG_ON(area == NULL); > shared = area->addr; > *__shared = shared; > diff --git a/drivers/xen/xenbus/xenbus_client.c b/drivers/xen/xenbus/xenbus_client.c > index cdacf92..75eb179 100644 > --- a/drivers/xen/xenbus/xenbus_client.c > +++ b/drivers/xen/xenbus/xenbus_client.c > @@ -435,19 +435,20 @@ EXPORT_SYMBOL_GPL(xenbus_free_evtchn); > int xenbus_map_ring_valloc(struct xenbus_device *dev, int gnt_ref, void **vaddr) > { > struct gnttab_map_grant_ref op = { > - .flags = GNTMAP_host_map, > + .flags = GNTMAP_host_map | GNTMAP_contains_pte, > .ref = gnt_ref, > .dom = dev->otherend_id, > }; > struct vm_struct *area; > + pte_t *pte; alloc_vm_area() is allocating two pages instead of the one we ask for. I hacked this with pte_t *pte[2]; > *vaddr = NULL; > > - area = alloc_vm_area(PAGE_SIZE); > + area = alloc_vm_area(PAGE_SIZE, &pte); > if (!area) > return -ENOMEM; > > - op.host_addr = (unsigned long)area->addr; > + op.host_addr = (unsigned long)pte; With the GNTMAP_contains_pte flags this needs a machine address here so: op.host_addr = arbitrary_virt_to_machine(pte).maddr; > if (HYPERVISOR_grant_table_op(GNTTABOP_map_grant_ref, &op, 1)) > BUG(); Also need to do something with xenbus_map_ring_vfree() which doesn't work. > diff --git a/include/linux/vmalloc.h b/include/linux/vmalloc.h > index 9332e52..1a77252 100644 > --- a/include/linux/vmalloc.h > +++ b/include/linux/vmalloc.h > @@ -118,7 +118,7 @@ unmap_kernel_range(unsigned long addr, unsigned long size) > #endif > > /* Allocate/destroy a 'vmalloc' VM area. */ > -extern struct vm_struct *alloc_vm_area(size_t size); > +extern struct vm_struct *alloc_vm_area(size_t size, pte_t **ptes); > extern void free_vm_area(struct vm_struct *area); > > /* for /dev/kmem */ > diff --git a/mm/vmalloc.c b/mm/vmalloc.c > index 5016f19..786b4f6 100644 > --- a/mm/vmalloc.c > +++ b/mm/vmalloc.c > @@ -2105,23 +2105,30 @@ void __attribute__((weak)) vmalloc_sync_all(void) > > static int f(pte_t *pte, pgtable_t table, unsigned long addr, void *data) > { > - /* apply_to_page_range() does all the hard work. */ > + pte_t ***p = data; > + > + if (p) { > + *(*p) = pte; > + (*p)++; > + } > return 0; > } > > /** > * alloc_vm_area - allocate a range of kernel address space > * @size: size of the area > + * @ptes: returns the PTEs for the address space > * > * Returns: NULL on failure, vm_struct on success > * > * This function reserves a range of kernel address space, and > * allocates pagetables to map that range. No actual mappings > - * are created. If the kernel address space is not shared > - * between processes, it syncs the pagetable across all > - * processes. > + * are created. > + * > + * If @ptes is non-NULL, pointers to the PTEs (in init_mm) > + * allocated for the VM area are returned. > */ > -struct vm_struct *alloc_vm_area(size_t size) > +struct vm_struct *alloc_vm_area(size_t size, pte_t **ptes) > { > struct vm_struct *area; > > @@ -2135,19 +2142,11 @@ struct vm_struct *alloc_vm_area(size_t size) > * of kernel virtual address space and mapped into init_mm. > */ > if (apply_to_page_range(&init_mm, (unsigned long)area->addr, > - area->size, f, NULL)) { > + area->size, f, ptes ? &ptes : NULL)) { > free_vm_area(area); > return NULL; > } > > - /* > - * If the allocated address space is passed to a hypercall > - * before being used then we cannot rely on a page fault to > - * trigger an update of the page tables. So sync all the page > - * tables here. > - */ > - vmalloc_sync_all(); > - > return area; > } > EXPORT_SYMBOL_GPL(alloc_vm_area); _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel From xen-devel-bounces@lists.xensource.com Fri Sep 23 08:18:48 2011 Return-path: <xen-devel-bounces@lists.xensource.com> Envelope-to: www-data@lists.xensource.com Delivery-date: Fri, 23 Sep 2011 08:18:48 -0700 Received: from localhost ([127.0.0.1] helo=lists.colo.xensource.com) by lists.xensource.com with esmtp (Exim 4.43) id 1R77Wa-0002VE-9h; Fri, 23 Sep 2011 08:18:48 -0700 Received: from mail182.messagelabs.com ([85.158.139.83]) by lists.xensource.com with esmtp (Exim 4.43) id 1R77QO-0000c6-1b for xen-devel@lists.xensource.com; Fri, 23 Sep 2011 08:12:24 -0700 X-Env-Sender: komkon555@freenet.de X-Msg-Ref: server-12.tower-182.messagelabs.com!1316790739!19342379!1 X-Originating-IP: [216.139.236.26] X-StarScan-Version: 6.4.1; banners=-,-,- X-VirusChecked: Checked Received: (qmail 28435 invoked from network); 23 Sep 2011 15:12:20 -0000 Received: from sam.nabble.com (HELO sam.nabble.com) (216.139.236.26) by server-12.tower-182.messagelabs.com with AES256-SHA encrypted SMTP; 23 Sep 2011 15:12:20 -0000 Received: from [192.168.236.26] (helo=sam.nabble.com) by sam.nabble.com with esmtp (Exim 4.72) (envelope-from <komkon555@freenet.de>) id 1R77QI-0005Jv-Ts for xen-devel@lists.xensource.com; Fri, 23 Sep 2011 08:12:18 -0700 Date: Fri, 23 Sep 2011 08:12:18 -0700 (PDT) From: komkon555 <komkon555@freenet.de> To: xen-devel@lists.xensource.com Message-ID: <1316790738919-4833943.post@n5.nabble.com> In-Reply-To: <1316789559703-4833862.post@n5.nabble.com> References: <1316616001843-4826614.post@n5.nabble.com> <1316616472579-4826635.post@n5.nabble.com> <1316616757871-4826655.post@n5.nabble.com> <1316618006.67296.YahooMailNeo@web29818.mail.ird.yahoo.com> <1316693722029-4829929.post@n5.nabble.com> <20110922182705.GE12984@reaktio.net> <1316728444821-4831624.post@n5.nabble.com> <1316777654598-4833174.post@n5.nabble.com> <1316786412428-4833637.post@n5.nabble.com> <1316789559703-4833862.post@n5.nabble.com> Subject: Re: Re : Re : Re : Re : [Xen-devel] Re: Patches for VGA-Passthrough XEN 4.2 unstable MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-BeenThere: xen-devel@lists.xensource.com X-Mailman-Version: 2.1.5 Precedence: list List-Id: Xen developer discussion <xen-devel.lists.xensource.com> List-Unsubscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe> List-Post: <mailto:xen-devel@lists.xensource.com> List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help> List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=subscribe> Sender: xen-devel-bounces@lists.xensource.com Errors-To: xen-devel-bounces@lists.xensource.com My report is this one: xm dmesg | grep VT-d (XEN) Intel VT-d Snoop Control not enabled. (XEN) Intel VT-d Dom0 DMA Passthrough not enabled. (XEN) Intel VT-d Queued Invalidation enabled. (XEN) Intel VT-d Interrupt Remapping enabled. (XEN) Intel VT-d Shared EPT tables not enabled. Kom. -- View this message in context: http://xen.1045712.n5.nabble.com/Patches-for-VGA-Passthrough-XEN-4-2-unstable-tp4406265p4833943.html Sent from the Xen - Dev mailing list archive at Nabble.com. _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel From xen-devel-bounces@lists.xensource.com Fri Sep 23 08:20:15 2011 Return-path: <xen-devel-bounces@lists.xensource.com> Envelope-to: www-data@lists.xensource.com Delivery-date: Fri, 23 Sep 2011 08:20:15 -0700 Received: from localhost ([127.0.0.1] helo=lists.colo.xensource.com) by lists.xensource.com with esmtp (Exim 4.43) id 1R77Xy-0002tK-H7; Fri, 23 Sep 2011 08:20:14 -0700 Received: from mail174.messagelabs.com ([85.158.138.51]) by lists.xensource.com with esmtp (Exim 4.43) id 1R77RK-0000up-Kx for xen-devel@lists.xensource.com; Fri, 23 Sep 2011 08:13:23 -0700 X-Env-Sender: Ian.Campbell@eu.citrix.com X-Msg-Ref: server-11.tower-174.messagelabs.com!1316790799!32514138!1 X-Originating-IP: [62.200.22.115] X-StarScan-Version: 6.4.1; banners=-,-,- X-VirusChecked: Checked Received: (qmail 32556 invoked from network); 23 Sep 2011 15:13:19 -0000 Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115) by server-11.tower-174.messagelabs.com with RC4-SHA encrypted SMTP; 23 Sep 2011 15:13:19 -0000 X-IronPort-AV: E=Sophos;i="4.68,430,1312156800"; d="scan'208";a="8033821" Received: from lonpmailmx01.citrite.net ([10.30.203.162]) by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5; 23 Sep 2011 15:13:19 +0000 Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net (10.30.203.162) with Microsoft SMTP Server id 8.3.137.0; Fri, 23 Sep 2011 16:13:19 +0100 Subject: Re: [Xen-devel] [PATCH] libxl: add custom disconnect functions for different device types From: Ian Campbell <Ian.Campbell@citrix.com> To: Roger Pau Monne <roger.pau@entel.upc.edu> Date: Fri, 23 Sep 2011 16:13:18 +0100 In-Reply-To: <1d42b1b355c231e794a5.1316778942@loki> References: <1d42b1b355c231e794a5.1316778942@loki> Organization: Citrix Systems, Inc. Content-Type: text/plain; charset="UTF-8" X-Mailer: Evolution 3.0.3- Content-Transfer-Encoding: 7bit Message-ID: <1316790798.23371.108.camel@zakaz.uk.xensource.com> MIME-Version: 1.0 Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com> X-BeenThere: xen-devel@lists.xensource.com X-Mailman-Version: 2.1.5 Precedence: list List-Id: Xen developer discussion <xen-devel.lists.xensource.com> List-Unsubscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe> List-Post: <mailto:xen-devel@lists.xensource.com> List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help> List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=subscribe> Sender: xen-devel-bounces@lists.xensource.com Errors-To: xen-devel-bounces@lists.xensource.com On Fri, 2011-09-23 at 12:55 +0100, Roger Pau Monne wrote: > # HG changeset patch > # User Roger Pau Monne <roger.pau@entel.upc.edu> > # Date 1316778937 -7200 > # Node ID 1d42b1b355c231e794a56dfadf3ee450346e3516 > # Parent 0ab9f548890e5e58122f73aa1c4164fd6e319b1c > libxl: add custom disconnect functions for different device types. > > This patch creates a new struct, called libxl__disconnect that can be > used to assign different functions that will be called to check if the > device is disconnected and to add it to the shutdown watch. Added a > helper function to get the libxl__device_kind from a be_path. The only > device that has a different shutdown mechanism right now is vbd. Looks good. I think all the new functions can be static to libxl_device.c though. > diff -r 0ab9f548890e -r 1d42b1b355c2 tools/libxl/libxl_device.c > --- a/tools/libxl/libxl_device.c Fri Sep 23 13:31:51 2011 +0200 > +++ b/tools/libxl/libxl_device.c Fri Sep 23 13:55:37 2011 +0200 > @@ -59,6 +80,18 @@ char *libxl__device_backend_path(libxl__ > device->domid, device->devid); > } > > +libxl__device_kinds libxl__device_identify(char *be_path) > +{ > + int len = sizeof(string_of_kinds)/sizeof(char *); > + > + for (int j = 1; j < len; j++) { > + if (strstr(be_path, string_of_kinds[j])) > + return j; > + } > + > + return DEVICE_UNKNOWN; You can sscanf out the precise backend rather than using strstr (which I worry might give false positives and/or rely in the ordering on the enum in the future). e.g. something like: /* /local/domain/<domid>/backend/<kind>/<domid>/<devid> */ char strkind[16]; /* Longest is actually "console" */ uint32_t domain; int rc = sscanf(path, "/local/domain/%d/backend/%16s/%d/%d", domid, strkind, &domain, devid); /* loop and strcmp of strkind vs string_of_kinds */ Ian. _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel From xen-devel-bounces@lists.xensource.com Fri Sep 23 08:32:21 2011 Return-path: <xen-devel-bounces@lists.xensource.com> Envelope-to: www-data@lists.xensource.com Delivery-date: Fri, 23 Sep 2011 08:32:21 -0700 Received: from localhost ([127.0.0.1] helo=lists.colo.xensource.com) by lists.xensource.com with esmtp (Exim 4.43) id 1R77jf-0003TH-Mn; Fri, 23 Sep 2011 08:32:19 -0700 Received: from mail216.messagelabs.com ([85.158.143.99]) by lists.xensource.com with esmtp (Exim 4.43) id 1R77im-0003Fi-Iv for xen-devel@lists.xensource.com; Fri, 23 Sep 2011 08:31:24 -0700 X-Env-Sender: evil.dani@gmail.com X-Msg-Ref: server-3.tower-216.messagelabs.com!1316791881!18351167!1 X-Originating-IP: [209.85.161.43] X-StarScan-Version: 6.4.1; banners=-,-,- X-VirusChecked: Checked Received: (qmail 25713 invoked from network); 23 Sep 2011 15:31:21 -0000 Received: from mail-fx0-f43.google.com (HELO mail-fx0-f43.google.com) (209.85.161.43) by server-3.tower-216.messagelabs.com with RC4-SHA encrypted SMTP; 23 Sep 2011 15:31:21 -0000 Received: by fxh19 with SMTP id 19so4869907fxh.30 for <xen-devel@lists.xensource.com>; Fri, 23 Sep 2011 08:31:21 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:date:message-id:subject:from:to:content-type :content-transfer-encoding; bh=Z+Xj5KrI4y6fw8xe2ByikIZk/v/mGLt7rrkp88pPdfA=; b=xEg9rBWL/kkujulOY7wbklxtNw/MTxqSQsno7riw0bdztGLXyOI+ce/b+kmrIj8nnx CDLC32Oil8vN6T6C/N8lwEbxgigJj+DZICJYnx7I7kc6LLGecpoJQMdv3qcevfb9fcgH edBNrz1WuDLZaHgXyacA4WjG1sWOAS6z0mZik= MIME-Version: 1.0 Received: by 10.223.43.218 with SMTP id x26mr5161048fae.75.1316791881347; Fri, 23 Sep 2011 08:31:21 -0700 (PDT) Received: by 10.223.97.9 with HTTP; Fri, 23 Sep 2011 08:31:21 -0700 (PDT) Date: Sat, 24 Sep 2011 00:31:21 +0900 Message-ID: <CAP2B858p3EDUykcM3RNpfU+9WGMHKL1bi+xdrwupMDuA+RvTZQ@mail.gmail.com> From: Daniel Castro <evil.dani@gmail.com> To: xen-devel@lists.xensource.com Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Subject: [Xen-devel] Question on Xenstore watch X-BeenThere: xen-devel@lists.xensource.com X-Mailman-Version: 2.1.5 Precedence: list List-Id: Xen developer discussion <xen-devel.lists.xensource.com> List-Unsubscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe> List-Post: <mailto:xen-devel@lists.xensource.com> List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help> List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=subscribe> Sender: xen-devel-bounces@lists.xensource.com Errors-To: xen-devel-bounces@lists.xensource.com Hello All, I am trying to set up a watch on xentore. According to the documentation xenstore.txt a watch is simply done with the path to the node that the path is going to set, but according to the definitive guide to xen, it is done like a write, path to node and key to be watched. I have tried both and both fail. Probably I have something wrong but it helps to know the correct format. Which one? Thanks, Daniel --=20 +-=3D=3D=3D=3D=3D---------------------------+ | +---------------------------------+ | This space intentionally blank for notetaking. | |=A0=A0 | Daniel Castro,=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 | | |=A0=A0 | Consultant/Programmer.| | |=A0=A0 | U Andes=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0=A0 | +-------------------------------------+ _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel From xen-devel-bounces@lists.xensource.com Fri Sep 23 08:37:41 2011 Return-path: <xen-devel-bounces@lists.xensource.com> Envelope-to: www-data@lists.xensource.com Delivery-date: Fri, 23 Sep 2011 08:37:41 -0700 Received: from localhost ([127.0.0.1] helo=lists.colo.xensource.com) by lists.xensource.com with esmtp (Exim 4.43) id 1R77or-0003zH-ET; Fri, 23 Sep 2011 08:37:41 -0700 Received: from mail27.messagelabs.com ([193.109.254.147]) by lists.xensource.com with smtp (Exim 4.43) id 1R72AX-0005dE-Ax for xen-devel@lists.xensource.com; Fri, 23 Sep 2011 02:35:41 -0700 X-Env-Sender: hongkaixing@huawei.com X-Msg-Ref: server-4.tower-27.messagelabs.com!1316770518!41443161!1 X-Originating-IP: [119.145.14.66] X-StarScan-Version: 6.4.1; banners=-,-,- X-VirusChecked: Checked Received: (qmail 29000 invoked from network); 23 Sep 2011 09:35:19 -0000 Received: from szxga03-in.huawei.com (HELO szxga03-in.huawei.com) (119.145.14.66) by server-4.tower-27.messagelabs.com with SMTP; 23 Sep 2011 09:35:19 -0000 Received: from huawei.com (szxga03-in [172.24.2.9]) by szxga03-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0LRY00HB1YNA9T@szxga03-in.huawei.com> for xen-devel@lists.xensource.com; Fri, 23 Sep 2011 17:35:34 +0800 (CST) Received: from szxrg02-dlp.huawei.com ([172.24.2.119]) by szxga03-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0LRY00FI3YN9KT@szxga03-in.huawei.com> for xen-devel@lists.xensource.com; Fri, 23 Sep 2011 17:35:34 +0800 (CST) Received: from szxeml206-edg.china.huawei.com ([172.24.2.119]) by szxrg02-dlp.huawei.com (MOS 4.1.9-GA) with ESMTP id ADV86790; Fri, 23 Sep 2011 17:35:16 +0800 Received: from SZXEML409-HUB.china.huawei.com (10.82.67.136) by szxeml206-edg.china.huawei.com (172.24.2.58) with Microsoft SMTP Server (TLS) id 14.1.270.1; Fri, 23 Sep 2011 17:35:08 +0800 Received: from SZXEML528-MBS.china.huawei.com ([169.254.5.113]) by szxeml409-hub.china.huawei.com ([10.82.67.136]) with mapi id 14.01.0270.001; Fri, 23 Sep 2011 17:35:13 +0800 Date: Fri, 23 Sep 2011 09:35:11 +0000 From: Hongkaixing <hongkaixing@huawei.com> X-Originating-IP: [10.166.80.196] To: "olaf@aepfle.de" <olaf@aepfle.de> Message-id: <E0AF011477D2AE458DC8801E0E570709014BD2BF@szxeml528-mbs.china.huawei.com> MIME-version: 1.0 Content-type: text/plain; charset=us-ascii Content-language: zh-CN Content-transfer-encoding: 7BIT Accept-Language: zh-CN, en-US Thread-topic: Some problems about xenpaging Thread-index: Acx50SmyVYjcmmJdTy2dRugbnYgiSQ== X-MS-Has-Attach: X-MS-TNEF-Correlator: X-CFilter-Loop: Reflected X-Mailman-Approved-At: Fri, 23 Sep 2011 08:36:53 -0700 Cc: YangXiaowei <xiaowei.yang@huawei.com>, ", " <xen-devel@lists.xensource.com>, "Eric Li\(Zhentao\)" <lizhentao@huawei.com>, Yanqiangjun <yanqiangjun@huawei.com> Subject: [Xen-devel] Some problems about xenpaging X-BeenThere: xen-devel@lists.xensource.com X-Mailman-Version: 2.1.5 Precedence: list List-Id: Xen developer discussion <xen-devel.lists.xensource.com> List-Unsubscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe> List-Post: <mailto:xen-devel@lists.xensource.com> List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help> List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=subscribe> Sender: xen-devel-bounces@lists.xensource.com Errors-To: xen-devel-bounces@lists.xensource.com Hi, Olaf we have tested the xenpaging feature and found some problems. (1) the test case like this : when we start a VM with POD enable, the xenpaging is started at the same time. this case will cause many problems ,finally, we fixed the BUG, the patch is attached below. (2) there is a very serious problem. we have observed many VM crash examples, the error code is not always the same. we guess there exists conflict between xenpaging and memory mapping. for instance, if the Dom0 map the DomU's memory to its own space , then the memory of DomainU is paged out, when the Domain0 access this memory area, a panic is caused. And I really do not know whether the qemu device can perceive the memory modified by xenpaging? thanks! here is the patch to solve the pod problem 1) fix the p2m_pod_decrease_reservation() function, take care of the paging type --- ./origin/xen/arch/x86/mm/p2m.c 2011-09-05 20:39:30.000000000 +0800 +++ ./b/xen/arch/x86/mm/p2m.c 2011-09-23 23:46:19.000000000 +0800 @@ -675,6 +675,23 @@ BUG_ON(p2md->pod.entry_count < 0); pod--; } + else if ( steal_for_cache && p2m_is_paging(t) ) + { + struct page_info *page; + /* alloc a new page to compensate the pod list */ + page = alloc_domheap_page(d, 0); + if ( unlikely(page == NULL) ) + { + goto out_entry_check; + } + set_p2m_entry(d, gpfn + i, _mfn(INVALID_MFN), 0, p2m_invalid); + p2m_mem_paging_drop_page(d, gpfn+i); + p2m_pod_cache_add(d, page, 0); + steal_for_cache = ( p2md->pod.entry_count > p2md->pod.count ); + nonpod--; + ram--; + } + /* for other ram types */ else if ( steal_for_cache && p2m_is_ram(t) ) { struct page_info *page; 2) fix the race between POD and xenpaging situation can be described as the follow xenpaging POD mfn = gfn_to_mfn() mfn = gfn_to_mfn() check p2m type check p2mt p2m_lock change p2m type p2m_unlock add to pod list p2m_lock() change p2m type p2m_unlock put_page() the result is a page is added to the pod list,and then it's removed from the list by put_page. my suggestion is to extend the range of the p2m lock to contain the p2m check. in p2m_mem_paging_nominate() function @@ -2532,7 +2561,8 @@ mfn_t mfn; int ret; - mfn = gfn_to_mfn(d, gfn, &p2mt); + p2m_lock(d->arch.p2m); + mfn = gfn_to_mfn_query(d, gfn, &p2mt); /* Check if mfn is valid */ ret = -EINVAL; @@ -2580,13 +2610,12 @@ goto out; /* Fix p2m entry */ - p2m_lock(d->arch.p2m); set_p2m_entry(d, gfn, mfn, 0, p2m_ram_paging_out); - p2m_unlock(d->arch.p2m); ret = 0; out: + p2m_unlock(d->arch.p2m); return ret; } in @@ -2595,34 +2624,39 @@ struct page_info *page; p2m_type_t p2mt; mfn_t mfn; - + int ret; + p2m_lock(d->arch.p2m); /* Get mfn */ - mfn = gfn_to_mfn(d, gfn, &p2mt); + mfn = gfn_to_mfn_query(d, gfn, &p2mt); + + ret = -EINVAL; if ( unlikely(!mfn_valid(mfn)) ) - return -EINVAL; + goto out; if (p2mt != p2m_ram_paging_out) { printk("p2m_mem_paging_evict type %d\n", p2mt); - return -EINVAL; + goto out; } /* Get the page so it doesn't get modified under Xen's feet */ page = mfn_to_page(mfn); if ( unlikely(!get_page(page, d)) ) - return -EINVAL; + goto out; /* Decrement guest domain's ref count of the page */ if ( test_and_clear_bit(_PGC_allocated, &page->count_info) ) put_page(page); /* Remove mapping from p2m table */ - p2m_lock(d->arch.p2m); set_p2m_entry(d, gfn, _mfn(PAGING_MFN), 0, p2m_ram_paged); - p2m_unlock(d->arch.p2m); /* Put the page back so it gets freed */ put_page(page); + + ret = 0; +out: + p2m_unlock(d->arch.p2m); return 0; } 3) fix the vmx_load_pdptrs() function in vmx.c in this situation the page directory table is paged out. Although using mdelay() is a bad idea, it's better than making the xen crash void vmx_load_pdptrs(struct vcpu *v) { unsigned long cr3 = v->arch.hvm_vcpu.guest_cr[3], mfn; uint64_t *guest_pdptrs; p2m_type_t p2mt; char *p; unsigned int try_count = 0; /* EPT needs to load PDPTRS into VMCS for PAE. */ if ( !hvm_pae_enabled(v) || (v->arch.hvm_vcpu.guest_efer & EFER_LMA) ) return; if ( cr3 & 0x1fUL ) goto crash; mfn = mfn_x(gfn_to_mfn(v->domain, cr3 >> PAGE_SHIFT, &p2mt)); if ( !p2m_is_ram(p2mt) ) goto crash; + if( p2m_is_paging(p2mt)) + { + p2m_mem_paging_populate(v->domain, cr3 >> PAGE_SHIFT); + do + { + mdelay(1); + try_count ++; + if ( try_count > 65535 ) + { + goto crash; + } + mfn = mfn_x(gfn_to_mfn(v->domain, cr3 >> PAGE_SHIFT, &p2mt)); + }while( !mfn_valid(mfn)); + } + p = map_domain_page(mfn); _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel From xen-devel-bounces@lists.xensource.com Fri Sep 23 09:05:59 2011 Return-path: <xen-devel-bounces@lists.xensource.com> Envelope-to: www-data@lists.xensource.com Delivery-date: Fri, 23 Sep 2011 09:06:00 -0700 Received: from localhost ([127.0.0.1] helo=lists.colo.xensource.com) by lists.xensource.com with esmtp (Exim 4.43) id 1R78GF-0005z7-MN; Fri, 23 Sep 2011 09:05:59 -0700 Received: from mail182.messagelabs.com ([85.158.139.83]) by lists.xensource.com with esmtp (Exim 4.43) id 1R78DE-0005kI-0x for xen-devel@lists.xensource.com; Fri, 23 Sep 2011 09:03:19 -0700 X-Env-Sender: dunlapg@gmail.com X-Msg-Ref: server-15.tower-182.messagelabs.com!1316793768!18498621!1 X-Originating-IP: [74.125.82.171] X-StarScan-Version: 6.4.1; banners=-,-,- X-VirusChecked: Checked Received: (qmail 29820 invoked from network); 23 Sep 2011 16:02:48 -0000 Received: from mail-wy0-f171.google.com (HELO mail-wy0-f171.google.com) (74.125.82.171) by server-15.tower-182.messagelabs.com with RC4-SHA encrypted SMTP; 23 Sep 2011 16:02:48 -0000 Received: by wyh13 with SMTP id 13so2894676wyh.30 for <xen-devel@lists.xensource.com>; Fri, 23 Sep 2011 09:02:47 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=8ckfYIDsist04YjwhST1g7g8uBDUUTlNc+iGEwvFobQ=; b=Klht83R0tkdJdM0OfPpqTIbYBoGFJg5p3hKnXheBHvkQAeyCQBPsjAbej7+pgsC5nf 9OOrTrNUHBLWW4irgkvPp41GlOI/h0F9hLMM9SS3Aw+KAB+tmKYPgoMU4ONsOzOuywQa 9NkAZ9JREVCAjmvGvsA/QsIqz7M/6NLHkuTQc= MIME-Version: 1.0 Received: by 10.216.82.211 with SMTP id o61mr2154621wee.81.1316793547411; Fri, 23 Sep 2011 08:59:07 -0700 (PDT) Received: by 10.216.176.81 with HTTP; Fri, 23 Sep 2011 08:59:07 -0700 (PDT) In-Reply-To: <E0AF011477D2AE458DC8801E0E570709014BD2BF@szxeml528-mbs.china.huawei.com> References: <E0AF011477D2AE458DC8801E0E570709014BD2BF@szxeml528-mbs.china.huawei.com> Date: Fri, 23 Sep 2011 16:59:07 +0100 X-Google-Sender-Auth: wySkVDERgV9F63kWhyXCNvtKojc Message-ID: <CAFLBxZZU+5-Q-y0rSk212XM8gUTpAq+38bNQu-XQev5=kFANUg@mail.gmail.com> Subject: Re: [Xen-devel] Some problems about xenpaging From: George Dunlap <dunlapg@umich.edu> To: Hongkaixing <hongkaixing@huawei.com> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: YangXiaowei <xiaowei.yang@huawei.com>, "olaf@aepfle.de" <olaf@aepfle.de>, ", " <xen-devel@lists.xensource.com>, "Eric Li\(Zhentao\)" <lizhentao@huawei.com>, Yanqiangjun <yanqiangjun@huawei.com> X-BeenThere: xen-devel@lists.xensource.com X-Mailman-Version: 2.1.5 Precedence: list List-Id: Xen developer discussion <xen-devel.lists.xensource.com> List-Unsubscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe> List-Post: <mailto:xen-devel@lists.xensource.com> List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help> List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=subscribe> Sender: xen-devel-bounces@lists.xensource.com Errors-To: xen-devel-bounces@lists.xensource.com On Fri, Sep 23, 2011 at 10:35 AM, Hongkaixing <hongkaixing@huawei.com> wrot= e: > Hi, Olaf > > we have tested the xenpaging feature and found some problems. > (1) the test case like this : when we start a VM with POD enable, the xen= paging is started at the same time. > =A0 =A0this case will cause many problems ,finally, we fixed the BUG, the= patch is attached below. > > (2) there is a very serious problem. we have observed many VM crash examp= les, the error code is not always the same. > =A0 =A0 we guess there exists conflict between xenpaging and memory mappi= ng. > =A0 =A0 for instance, if the Dom0 map the DomU's memory to its own space = , then the memory of DomainU is paged out, when the Domain0 access this mem= ory area, a panic is caused. > =A0 =A0 And I really do not know whether the qemu device can perceive the= memory modified by xenpaging? > > =A0 =A0thanks! > > here is the patch to solve the pod problem > 1) fix the p2m_pod_decrease_reservation() function, take care of the pagi= ng type > --- ./origin/xen/arch/x86/mm/p2m.c =A0 =A0 =A02011-09-05 20:39:30.0000000= 00 +0800 > +++ ./b/xen/arch/x86/mm/p2m.c =A0 2011-09-23 23:46:19.000000000 +0800 Kaixing, Xie xie ni dui wo men shuo zhe xie shi. (Dui bu qi wo de zhong wen bu hao.) As Olaf says, it would help us a lot if you could submit the patches in a form that is easier for us to apply and to comment on: namely, either having all the patches in separate files as attachments, or having one e-mail per patch, with the patch being the last thing in the e-mail. There are some suggestions on how to post patches here: http://wiki.xensource.com/xenwiki/SubmittingXenPatches. My preferred technique is to make a patch series using Mercurial Queues, and then use the PatchBomb extension (mentioned in the link above) to mail them as a series, by using "hg email -o" -George > @@ -675,6 +675,23 @@ > =A0 =A0 =A0 =A0 =A0 =A0 BUG_ON(p2md->pod.entry_count < 0); > =A0 =A0 =A0 =A0 =A0 =A0 pod--; > =A0 =A0 =A0 =A0 } > + =A0 =A0 =A0 =A0else if ( steal_for_cache && p2m_is_paging(t) ) > + =A0 =A0 =A0 =A0{ > + =A0 =A0 =A0 =A0 =A0 =A0struct page_info *page; > + =A0 =A0 =A0 =A0 =A0 =A0/* alloc a new page to compensate the pod list *= / > + =A0 =A0 =A0 =A0 =A0 =A0page =3D alloc_domheap_page(d, 0); > + =A0 =A0 =A0 =A0 =A0 =A0if ( unlikely(page =3D=3D NULL) ) > + =A0 =A0 =A0 =A0 =A0 =A0{ > + =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0goto out_entry_check; > + =A0 =A0 =A0 =A0 =A0 =A0} > + =A0 =A0 =A0 =A0 =A0 =A0set_p2m_entry(d, gpfn + i, _mfn(INVALID_MFN), 0,= p2m_invalid); > + =A0 =A0 =A0 =A0 =A0 =A0p2m_mem_paging_drop_page(d, gpfn+i); > + =A0 =A0 =A0 =A0 =A0 =A0p2m_pod_cache_add(d, page, 0); > + =A0 =A0 =A0 =A0 =A0 =A0steal_for_cache =3D =A0( p2md->pod.entry_count >= p2md->pod.count ); > + =A0 =A0 =A0 =A0 =A0 =A0nonpod--; > + =A0 =A0 =A0 =A0 =A0 =A0ram--; > + =A0 =A0 =A0 =A0} > + =A0 =A0 =A0 =A0/* for other ram types */ > =A0 =A0 =A0 =A0 else if ( steal_for_cache && p2m_is_ram(t) ) > =A0 =A0 =A0 =A0 { > =A0 =A0 =A0 =A0 =A0 =A0 struct page_info *page; > > 2) fix the race between POD and xenpaging > =A0 situation can be described as the follow > > =A0 xenpaging =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0POD > > =A0mfn =3D gfn_to_mfn() =A0 =A0 =A0 =A0 mfn =3D gfn_to_mfn() > =A0 check p2m type =A0 =A0 =A0 =A0 =A0 check p2mt > =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0p2m_lock > =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0change p2m type > =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0p2m_unlock > =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0add to pod list > =A0 =A0p2m_lock() > =A0 =A0change p2m type > =A0 =A0p2m_unlock > =A0 =A0put_page() > > the result is a page is added to the pod list,and then it's removed from = the list by put_page. > my suggestion is to extend the range of the p2m lock to contain the p2m c= heck. > > in =A0p2m_mem_paging_nominate() function > @@ -2532,7 +2561,8 @@ > =A0 =A0 mfn_t mfn; > =A0 =A0 int ret; > > - =A0 =A0mfn =3D gfn_to_mfn(d, gfn, &p2mt); > + =A0 =A0p2m_lock(d->arch.p2m); > + =A0 =A0mfn =3D gfn_to_mfn_query(d, gfn, &p2mt); > > =A0 =A0 /* Check if mfn is valid */ > =A0 =A0 ret =3D -EINVAL; > @@ -2580,13 +2610,12 @@ > =A0 =A0 =A0 =A0 goto out; > > =A0 =A0 /* Fix p2m entry */ > - =A0 =A0p2m_lock(d->arch.p2m); > =A0 =A0 set_p2m_entry(d, gfn, mfn, 0, p2m_ram_paging_out); > - =A0 =A0p2m_unlock(d->arch.p2m); > > =A0 =A0 ret =3D 0; > > =A0out: > + =A0 =A0p2m_unlock(d->arch.p2m); > =A0 =A0 return ret; > =A0} > in > @@ -2595,34 +2624,39 @@ > =A0 =A0 struct page_info *page; > =A0 =A0 p2m_type_t p2mt; > =A0 =A0 mfn_t mfn; > - > + =A0 =A0int ret; > + =A0 =A0p2m_lock(d->arch.p2m); > =A0 =A0 /* Get mfn */ > - =A0 =A0mfn =3D gfn_to_mfn(d, gfn, &p2mt); > + =A0 =A0mfn =3D gfn_to_mfn_query(d, gfn, &p2mt); > + > + =A0 =A0ret =3D -EINVAL; > =A0 =A0 if ( unlikely(!mfn_valid(mfn)) ) > - =A0 =A0 =A0 =A0return -EINVAL; > + =A0 =A0 =A0 =A0goto out; > > =A0 =A0 if (p2mt !=3D p2m_ram_paging_out) > =A0 =A0 =A0{ > =A0 =A0 =A0 =A0 =A0printk("p2m_mem_paging_evict type %d\n", p2mt); > - =A0 =A0 =A0 =A0 =A0 =A0 =A0 return -EINVAL; > + =A0 =A0 =A0 =A0 goto out; > =A0 =A0 =A0} > =A0 =A0 /* Get the page so it doesn't get modified under Xen's feet */ > =A0 =A0 page =3D mfn_to_page(mfn); > =A0 =A0 if ( unlikely(!get_page(page, d)) ) > - =A0 =A0 =A0 =A0return -EINVAL; > + =A0 =A0 =A0 =A0goto out; > > =A0 =A0 /* Decrement guest domain's ref count of the page */ > =A0 =A0 if ( test_and_clear_bit(_PGC_allocated, &page->count_info) ) > =A0 =A0 =A0 =A0 put_page(page); > > =A0 =A0 /* Remove mapping from p2m table */ > - =A0 =A0p2m_lock(d->arch.p2m); > =A0 =A0 set_p2m_entry(d, gfn, _mfn(PAGING_MFN), 0, p2m_ram_paged); > - =A0 =A0p2m_unlock(d->arch.p2m); > > =A0 =A0 /* Put the page back so it gets freed */ > =A0 =A0 put_page(page); > + > + =A0 =A0ret =3D 0; > > +out: > + =A0 =A0p2m_unlock(d->arch.p2m); > =A0 =A0 return 0; > =A0} > > 3) fix the vmx_load_pdptrs() function in =A0vmx.c > in this situation the page directory table is paged out. > Although using mdelay() is a bad idea, it's better than making the xen cr= ash > > void vmx_load_pdptrs(struct vcpu *v) > { > =A0 =A0unsigned long cr3 =3D v->arch.hvm_vcpu.guest_cr[3], mfn; > =A0 =A0uint64_t *guest_pdptrs; > =A0 =A0p2m_type_t p2mt; > =A0 =A0char *p; > =A0 =A0unsigned int try_count =3D 0; > =A0 =A0/* EPT needs to load PDPTRS into VMCS for PAE. */ > =A0 =A0if ( !hvm_pae_enabled(v) || (v->arch.hvm_vcpu.guest_efer & EFER_LM= A) ) > =A0 =A0 =A0 =A0return; > =A0 =A0if ( cr3 & 0x1fUL ) > =A0 =A0 =A0 =A0goto crash; > =A0 =A0mfn =3D mfn_x(gfn_to_mfn(v->domain, cr3 >> PAGE_SHIFT, &p2mt)); > =A0 =A0if ( !p2m_is_ram(p2mt) ) > =A0 =A0 =A0 =A0goto crash; > + =A0if( p2m_is_paging(p2mt)) > + =A0{ > + =A0 =A0 =A0 =A0p2m_mem_paging_populate(v->domain, cr3 >> PAGE_SHIFT); > + =A0 =A0 =A0 =A0do > + =A0 =A0 =A0 =A0{ > + =A0 =A0 =A0 =A0 =A0 =A0 mdelay(1); > + =A0 =A0 =A0 =A0 =A0 =A0 try_count ++; > + =A0 =A0 =A0 =A0 =A0 =A0 if ( try_count > 65535 ) > + =A0 =A0 =A0 =A0 =A0 =A0 { > + =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 goto crash; > + =A0 =A0 =A0 =A0 =A0 =A0 } > + =A0 =A0 =A0 =A0 =A0 =A0 mfn =3D mfn_x(gfn_to_mfn(v->domain, cr3 >> PAGE= _SHIFT, &p2mt)); > + =A0 =A0 =A0 =A0}while( !mfn_valid(mfn)); > + =A0 =A0} > + > =A0 =A0p =3D map_domain_page(mfn); > > _______________________________________________ > Xen-devel mailing list > Xen-devel@lists.xensource.com > http://lists.xensource.com/xen-devel > _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel From xen-devel-bounces@lists.xensource.com Fri Sep 23 09:20:28 2011 Return-path: <xen-devel-bounces@lists.xensource.com> Envelope-to: www-data@lists.xensource.com Delivery-date: Fri, 23 Sep 2011 09:20:28 -0700 Received: from localhost ([127.0.0.1] helo=lists.colo.xensource.com) by lists.xensource.com with esmtp (Exim 4.43) id 1R78UG-0006Xc-9Q; Fri, 23 Sep 2011 09:20:28 -0700 Received: from mail216.messagelabs.com ([85.158.143.99]) by lists.xensource.com with esmtp (Exim 4.43) id 1R78TQ-0006Kz-3M for xen-devel@lists.xensource.com; Fri, 23 Sep 2011 09:19:37 -0700 X-Env-Sender: olaf@aepfle.de X-Msg-Ref: server-15.tower-216.messagelabs.com!1316794772!18874537!1 X-Originating-IP: [81.169.146.160] X-StarScan-Version: 6.4.1; banners=-,-,- X-VirusChecked: Checked Received: (qmail 19869 invoked from network); 23 Sep 2011 16:19:32 -0000 Received: from mo-p00-ob.rzone.de (HELO mo-p00-ob.rzone.de) (81.169.146.160) by server-15.tower-216.messagelabs.com with DHE-RSA-AES256-SHA encrypted SMTP; 23 Sep 2011 16:19:32 -0000 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; t=1316794771; l=651; s=domk; d=aepfle.de; h=In-Reply-To:Content-Type:MIME-Version:References:Subject:Cc:To:From: Date:X-RZG-CLASS-ID:X-RZG-AUTH; bh=nfENW4rD2KAgNYgyvTvcldwFuGs=; b=tlk1TsukZWK90ebZYARBkasfV8ZRJdmJ3Tioxa2kvwkqEAUr63l5T+DGChKdPq2kCzd qnjMjI8E+iUvlQEIXG9/xbbCOP1alJnzw0uEQEfHszgcuEyc/CscOrz+D7NqqPD9CMBvz MkZ77/i77ruzKiciJ/OQsHymKFXHqbnmtsI= X-RZG-AUTH: :P2EQZWCpfu+qG7CngxMFH1J+zrwiavkK6tmQaLfmwtM48/lq3s7jFtE= X-RZG-CLASS-ID: mo00 Received: from probook.site (dslb-084-057-077-084.pools.arcor-ip.net [84.57.77.84]) by smtp.strato.de (cohen mo21) (RZmta 26.7) with (DHE-RSA-AES256-SHA encrypted) ESMTPA id 604e57n8NFRbLt ; Fri, 23 Sep 2011 18:19:11 +0200 (MEST) Received: by probook.site (Postfix, from userid 1000) id AF29618B65; Fri, 23 Sep 2011 18:19:10 +0200 (CEST) Date: Fri, 23 Sep 2011 18:19:10 +0200 From: Olaf Hering <olaf@aepfle.de> To: Tim Deegan <tim@xen.org> Subject: Re: [Xen-devel] [PATCH] xenpaging: track number of paged pages in struct domain Message-ID: <20110923161910.GA16514@aepfle.de> References: <13b4be345ebac016abe2.1316089567@probook.site> <20110916112403.GB95880@ocelot.phlegethon.org> <20110916113254.GA7332@aepfle.de> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline In-Reply-To: <20110916113254.GA7332@aepfle.de> User-Agent: Mutt/1.5.21.rev5535 (2011-07-01) Cc: xen-devel@lists.xensource.com X-BeenThere: xen-devel@lists.xensource.com X-Mailman-Version: 2.1.5 Precedence: list List-Id: Xen developer discussion <xen-devel.lists.xensource.com> List-Unsubscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe> List-Post: <mailto:xen-devel@lists.xensource.com> List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help> List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=subscribe> Sender: xen-devel-bounces@lists.xensource.com Errors-To: xen-devel-bounces@lists.xensource.com On Fri, Sep 16, Olaf Hering wrote: > > For the xen parts, Acked-by: Tim Deegan <tim@xen.org> > > > > Again, I'd like the tools maintainers to ack/nack the change to the domctl > > interface and associated libxc plumbing. > > Thanks, but please wait a bit before applying it. > Eventually a new XENMEM op is required as well to export that value for > a guests balloon driver. I'm not finished yet with browsing the > codepaths which make use of tot_pages. Please go ahead with applying. The balloon driver does not need to know about paged pages, its job is to just free as many pages as it is asked for by xenstore or sysfs. Olaf _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel From xen-devel-bounces@lists.xensource.com Fri Sep 23 09:57:15 2011 Return-path: <xen-devel-bounces@lists.xensource.com> Envelope-to: www-data@lists.xensource.com Delivery-date: Fri, 23 Sep 2011 09:57:15 -0700 Received: from localhost ([127.0.0.1] helo=lists.colo.xensource.com) by lists.xensource.com with esmtp (Exim 4.43) id 1R793q-00005P-Lx; Fri, 23 Sep 2011 09:57:14 -0700 Received: from mail216.messagelabs.com ([85.158.143.99]) by lists.xensource.com with esmtp (Exim 4.43) id 1R7932-0008Ik-LI for xen-devel@lists.xensource.com; Fri, 23 Sep 2011 09:56:24 -0700 X-Env-Sender: aravindh@virtuata.com X-Msg-Ref: server-9.tower-216.messagelabs.com!1316796980!19404040!1 X-Originating-IP: [209.85.213.43] X-StarScan-Version: 6.4.1; banners=-,-,- X-VirusChecked: Checked Received: (qmail 20743 invoked from network); 23 Sep 2011 16:56:21 -0000 Received: from mail-yw0-f43.google.com (HELO mail-yw0-f43.google.com) (209.85.213.43) by server-9.tower-216.messagelabs.com with RC4-SHA encrypted SMTP; 23 Sep 2011 16:56:21 -0000 Received: by ywm21 with SMTP id 21so4277968ywm.30 for <xen-devel@lists.xensource.com>; Fri, 23 Sep 2011 09:56:20 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=virtuata.com; s=google; h=mime-version:x-originating-ip:date:message-id:subject:from:to :content-type; bh=18A1ZO8iYTnyKN2SIZrvwjn5DudYfZGAYHlQnat6Mg4=; b=wFhQLE+7OlkGYvwAd3rPN6Lfx13MX6cy17N1GwPBQA+lCpnJoeNF9HVZ8Uksz+D0pM /V64Dzckzlw15usNuNE//ELV1C6Q9AU447Xe51o3jc158BOpA81dTCZDaohFkvUe4pya G3AileB3wTJilBQWseMhyePeFdG4/ieOZr38A= MIME-Version: 1.0 Received: by 10.68.11.138 with SMTP id q10mr11089248pbb.37.1316796979971; Fri, 23 Sep 2011 09:56:19 -0700 (PDT) Received: by 10.142.221.13 with HTTP; Fri, 23 Sep 2011 09:56:19 -0700 (PDT) X-Originating-IP: [174.253.240.25] Received: by 10.142.221.13 with HTTP; Fri, 23 Sep 2011 09:56:19 -0700 (PDT) Date: Fri, 23 Sep 2011 09:56:19 -0700 Message-ID: <CAB10MZBD-5M=wrkj6rsQxqdQn5E1UMA4j+C1EQq8Y-BjXZaRoA@mail.gmail.com> From: Aravindh Puthiyaparambil <aravindh@virtuata.com> To: xen-devel@lists.xensource.com Subject: [Xen-devel] Differentiate between Xen versions at compile time X-BeenThere: xen-devel@lists.xensource.com X-Mailman-Version: 2.1.5 Precedence: list List-Id: Xen developer discussion <xen-devel.lists.xensource.com> List-Unsubscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe> List-Post: <mailto:xen-devel@lists.xensource.com> List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help> List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=subscribe> Content-Type: multipart/mixed; boundary="===============1117100764==" Sender: xen-devel-bounces@lists.xensource.com Errors-To: xen-devel-bounces@lists.xensource.com --===============1117100764== Content-Type: multipart/alternative; boundary=bcaec5314ad13b85d104ad9eb0f3 --bcaec5314ad13b85d104ad9eb0f3 Content-Type: text/plain; charset=ISO-8859-1 The men_access interface has changed between 4.1 and unstable. Mainly xc_mem_event_enable/disable() is now xc_mem_access_enable/disable(). Is there a define to check against, to pick up this difference during compile time for a libxc app? Thanks, Aravindh --bcaec5314ad13b85d104ad9eb0f3 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable <p>The men_access interface has changed between 4.1 and unstable. Mainly xc= _mem_event_enable/disable() is now xc_mem_access_enable/disable(). Is there= a define to check against,=A0 to pick up this difference during compile ti= me for a libxc app?</p> <p>Thanks,<br> Aravindh</p> --bcaec5314ad13b85d104ad9eb0f3-- --===============1117100764== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel --===============1117100764==-- From xen-devel-bounces@lists.xensource.com Fri Sep 23 09:59:52 2011 Return-path: <xen-devel-bounces@lists.xensource.com> Envelope-to: www-data@lists.xensource.com Delivery-date: Fri, 23 Sep 2011 09:59:52 -0700 Received: from localhost ([127.0.0.1] helo=lists.colo.xensource.com) by lists.xensource.com with esmtp (Exim 4.43) id 1R796N-0000U0-A1; Fri, 23 Sep 2011 09:59:51 -0700 Received: from mail174.messagelabs.com ([85.158.138.51]) by lists.xensource.com with esmtp (Exim 4.43) id 1R793m-0008Uq-6p for xen-devel@lists.xensource.com; Fri, 23 Sep 2011 09:57:11 -0700 X-Env-Sender: Ian.Jackson@eu.citrix.com X-Msg-Ref: server-15.tower-174.messagelabs.com!1316797026!26187793!1 X-Originating-IP: [62.200.22.115] X-StarScan-Version: 6.4.1; banners=-,-,- X-VirusChecked: Checked Received: (qmail 9696 invoked from network); 23 Sep 2011 16:57:07 -0000 Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115) by server-15.tower-174.messagelabs.com with RC4-SHA encrypted SMTP; 23 Sep 2011 16:57:07 -0000 X-IronPort-AV: E=Sophos;i="4.68,431,1312156800"; d="scan'208";a="8035647" Received: from lonpmailmx01.citrite.net ([10.30.203.162]) by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5; 23 Sep 2011 16:57:06 +0000 Received: from woking.xci-test.com (10.80.248.135) by smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id 8.3.137.0; Fri, 23 Sep 2011 17:57:06 +0100 Received: from osstest by woking.xci-test.com with local (Exim 4.69) (envelope-from <ian.jackson@eu.citrix.com>) id 1R793i-0000Q3-89; Fri, 23 Sep 2011 17:57:06 +0100 To: <xen-devel@lists.xensource.com> Message-ID: <osstest-9054-mainreport@xen.org> From: xen.org <ian.jackson@eu.citrix.com> Date: Fri, 23 Sep 2011 17:57:06 +0100 MIME-Version: 1.0 Content-Type: text/plain Cc: ian.jackson@eu.citrix.com Subject: [Xen-devel] [xen-unstable test] 9054: regressions - FAIL X-BeenThere: xen-devel@lists.xensource.com X-Mailman-Version: 2.1.5 Precedence: list List-Id: Xen developer discussion <xen-devel.lists.xensource.com> List-Unsubscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe> List-Post: <mailto:xen-devel@lists.xensource.com> List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help> List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=subscribe> Sender: xen-devel-bounces@lists.xensource.com Errors-To: xen-devel-bounces@lists.xensource.com flight 9054 xen-unstable real [real] http://www.chiark.greenend.org.uk/~xensrcts/logs/9054/ Regressions :-( Tests which did not succeed and are blocking: test-amd64-i386-rhel6hvm-amd 5 xen-boot fail REGR. vs. 8995 Tests which are failing intermittently (not blocking): test-amd64-amd64-pv 5 xen-boot fail pass in 9043 test-amd64-amd64-xl-sedf 5 xen-boot fail pass in 9043 test-amd64-i386-xl 5 xen-boot fail pass in 9043 test-i386-i386-xl 5 xen-boot fail pass in 9005 test-amd64-i386-xl-win-vcpus1 5 xen-boot fail pass in 9043 test-i386-i386-win 5 xen-boot fail pass in 9005 test-amd64-amd64-pair 7 xen-boot/src_host fail pass in 9043 test-amd64-amd64-pair 8 xen-boot/dst_host fail pass in 9043 test-amd64-i386-xl-multivcpu 5 xen-boot fail in 9043 pass in 9054 test-amd64-i386-xl-credit2 5 xen-boot fail in 9043 pass in 9054 test-amd64-amd64-win 5 xen-boot fail in 9043 pass in 9054 test-amd64-i386-win-vcpus1 5 xen-boot fail in 9043 pass in 9054 test-amd64-i386-win 5 xen-boot fail in 9043 pass in 9054 test-amd64-amd64-xl-win 5 xen-boot fail in 9043 pass in 9054 test-amd64-amd64-xl 5 xen-boot fail in 9005 pass in 9054 test-amd64-i386-pv 5 xen-boot fail in 9005 pass in 9054 test-i386-i386-pv 5 xen-boot fail in 9005 pass in 9054 test-amd64-i386-pair 8 xen-boot/dst_host fail in 9005 pass in 9054 test-amd64-i386-pair 7 xen-boot/src_host fail in 9005 pass in 9054 Tests which did not succeed, but are not blocking, including regressions (tests previously passed) regarded as allowable: test-amd64-amd64-xl-pcipt-intel 9 guest-start fail never pass test-amd64-i386-rhel6hvm-intel 9 guest-start.2 fail never pass test-i386-i386-xl-win 13 guest-stop fail never pass test-amd64-amd64-win 16 leak-check/check fail never pass test-amd64-i386-win-vcpus1 16 leak-check/check fail never pass test-amd64-i386-win 16 leak-check/check fail never pass test-amd64-amd64-xl-win 13 guest-stop fail never pass test-amd64-amd64-xl-sedf 14 guest-localmigrate/x10 fail in 9043 like 8995 test-amd64-i386-xl-win-vcpus1 13 guest-stop fail in 9043 never pass test-i386-i386-win 16 leak-check/check fail in 9005 never pass version targeted for testing: xen cc339ab1d917 baseline version: xen a422e2a4451e ------------------------------------------------------------ People who touched revisions under test: Andreas Herrmann <herrmann.der.user@googlemail.com> Ian Campbell <ian.campbell@citrix.com> Ian Jackson <ian.jackson@eu.citrix.com> Jan Beulich <jbeulich@suse.com> Lasse Collin <lasse.collin@tukaani.org> Olaf Hering <olaf@aepfle.de> Thomas Renninger <trenn@suse.de> ------------------------------------------------------------ jobs: build-amd64 pass build-i386 pass build-amd64-oldkern pass build-i386-oldkern pass build-amd64-pvops pass build-i386-pvops pass test-amd64-amd64-xl pass test-amd64-i386-xl fail test-i386-i386-xl fail test-amd64-i386-rhel6hvm-amd fail test-amd64-i386-xl-credit2 pass test-amd64-amd64-xl-pcipt-intel fail test-amd64-i386-rhel6hvm-intel fail test-amd64-i386-xl-multivcpu pass test-amd64-amd64-pair fail test-amd64-i386-pair pass test-i386-i386-pair pass test-amd64-amd64-pv fail test-amd64-i386-pv pass test-i386-i386-pv pass test-amd64-amd64-xl-sedf fail test-amd64-i386-win-vcpus1 fail test-amd64-i386-xl-win-vcpus1 fail test-amd64-amd64-win fail test-amd64-i386-win fail test-i386-i386-win fail test-amd64-amd64-xl-win fail test-i386-i386-xl-win fail ------------------------------------------------------------ sg-report-flight on woking.cam.xci-test.com logs: /home/xc_osstest/logs images: /home/xc_osstest/images Logs, config files, etc. are available at http://www.chiark.greenend.org.uk/~xensrcts/logs Test harness code can be found at http://xenbits.xensource.com/gitweb?p=osstest.git;a=summary Not pushing. ------------------------------------------------------------ changeset: 23872:cc339ab1d917 tag: tip user: Ian Campbell <ian.campbell@citrix.com> date: Thu Sep 22 18:37:06 2011 +0100 tools: fix install of lomount $(BIN) went away in 23124:e3d4c34b14a3. Also there are no *.so, *.a or *.rpm built in here Signed-off-by: Ian Campbell <ian.campbell@citrix.com> changeset: 23871:503ee256fecf user: Jan Beulich <jbeulich@suse.com> date: Thu Sep 22 18:35:30 2011 +0100 x86: ucode-amd: Don't warn when no ucode is available for a CPU revision This patch originally comes from the Linus mainline kernel (2.6.33), find below the patch details: From: Andreas Herrmann <herrmann.der.user@googlemail.com> There is no point in warning when there is no ucode available for a specific CPU revision. Currently the container-file, which provides the AMD ucode patches for OS load, contains only a few ucode patches. It's already clearly indicated by the printed patch_level whenever new ucode was available and an update happened. So the warning message is of no help but rather annoying on systems with many CPUs. Signed-off-by: Thomas Renninger <trenn@suse.de> Signed-off-by: Jan Beulich <jbeulich@suse.com> changeset: 23870:5c97b02f48fc user: Jan Beulich <jbeulich@suse.com> date: Thu Sep 22 18:34:27 2011 +0100 XZ: Fix incorrect XZ_BUF_ERROR From: Lasse Collin <lasse.collin@tukaani.org> xz_dec_run() could incorrectly return XZ_BUF_ERROR if all of the following was true: - The caller knows how many bytes of output to expect and only provides that much output space. - When the last output bytes are decoded, the caller-provided input buffer ends right before the LZMA2 end of payload marker. So LZMA2 won't provide more output anymore, but it won't know it yet and thus won't return XZ_STREAM_END yet. - A BCJ filter is in use and it hasn't left any unfiltered bytes in the temp buffer. This can happen with any BCJ filter, but in practice it's more likely with filters other than the x86 BCJ. This fixes <https://bugzilla.redhat.com/show_bug.cgi?id=3D735408> where Squashfs thinks that a valid file system is corrupt. This also fixes a similar bug in single-call mode where the uncompressed size of a block using BCJ + LZMA2 was 0 bytes and caller provided no output space. Many empty .xz files don't contain any blocks and thus don't trigger this bug. This also tweaks a closely related detail: xz_dec_bcj_run() could call xz_dec_lzma2_run() to decode into temp buffer when it was known to be useless. This was harmless although it wasted a minuscule number of CPU cycles. Signed-off-by: Lasse Collin <lasse.collin@tukaani.org> Signed-off-by: Jan Beulich <jbeulich@suse.com> changeset: 23869:db1ea4b127cd user: Jan Beulich <jbeulich@suse.com> date: Thu Sep 22 18:33:48 2011 +0100 XZ decompressor: Fix decoding of empty LZMA2 streams From: Lasse Collin <lasse.collin@tukaani.org> The old code considered valid empty LZMA2 streams to be corrupt. Note that a typical empty .xz file has no LZMA2 data at all, and thus most .xz files having no uncompressed data are handled correctly even without this fix. Signed-off-by: Lasse Collin <lasse.collin@tukaani.org> Signed-off-by: Jan Beulich <jbeulich@suse.com> changeset: 23868:28147fd781af user: Jan Beulich <jbeulich@suse.com> date: Thu Sep 22 18:32:34 2011 +0100 VT-d: fix off-by-one error in RMRR validation (base_addr,end_addr) is an inclusive range, and hence there shouldn't be a subtraction of 1 in the second invocation of page_is_ram_type(). For RMRRs covering a single page that actually resulted in the immediately preceding page to get checked (which could have resulted in a false warning). Signed-off-by: Jan Beulich <jbeulich@suse.com> changeset: 23867:571b6e90dfb4 user: Jan Beulich <jbeulich@suse.com> date: Thu Sep 22 18:31:44 2011 +0100 VT-d: eliminate a mis-use of pcidevs_lock dma_pte_clear_one() shouldn't acquire this global lock for the purpose of processing a per-domain list. Furthermore the function a few lines earlier has a comment stating that acquiring pcidevs_lock isn't necessary here (whether that's really correct is another question). Use the domain's mappin_lock instead to protect the mapped_rmrrs list. Fold domain_rmrr_mapped() into its sole caller so that the otherwise implicit dependency on pcidevs_lock there becomes more obvious (see the comment there). Signed-off-by: Jan Beulich <jbeulich@suse.com> changeset: 23866:47ec1d405af9 user: Jan Beulich <jbeulich@suse.com> date: Thu Sep 22 18:31:02 2011 +0100 x86: IO-APIC code has no dependency on PCI The IRQ handling code requires pcidevs_lock to be held only for MSI interrupts. As the handling of which was now fully moved into msi.c (i.e. while applying fine without, the patch needs to be applied after the one titled "x86: split MSI IRQ chip"), io_apic.c now also doesn't need to include PCI headers anymore. Signed-off-by: Jan Beulich <jbeulich@suse.com> changeset: 23865:d6e01c7853cf user: Jan Beulich <jbeulich@suse.com> date: Thu Sep 22 18:29:19 2011 +0100 PCI multi-seg: config space accessor adjustments Signed-off-by: Jan Beulich <jbeulich@suse.com> changeset: 23864:314b147d524d user: Jan Beulich <jbeulich@suse.com> date: Thu Sep 22 18:28:38 2011 +0100 PCI multi-seg: Pass-through adjustments Signed-off-by: Jan Beulich <jbeulich@suse.com> changeset: 23863:9e0259239822 user: Jan Beulich <jbeulich@suse.com> date: Thu Sep 22 18:28:03 2011 +0100 PCI multi-seg: AMD-IOMMU specific adjustments There are two places here where it is entirely unclear to me where the necessary PCI segment number should be taken from (as IVMD descriptors don't have such, only IVHD ones do). AMD confirmed that for the time being it is acceptable to imply that only segment 0 exists. Signed-off-by: Jan Beulich <jbeulich@suse.com> changeset: 23862:85418e168527 user: Jan Beulich <jbeulich@suse.com> date: Thu Sep 22 18:27:26 2011 +0100 PCI multi-seg: VT-d specific adjustments Signed-off-by: Jan Beulich <jbeulich@suse.com> changeset: 23861:ec7c81fbe0de user: Jan Beulich <jbeulich@suse.com> date: Thu Sep 22 18:26:54 2011 +0100 PCI multi-seg: adjust domctl interface Again, a couple of directly related functions at once get adjusted to account for the segment number. Signed-off-by: Jan Beulich <jbeulich@suse.com> changeset: 23860:a422e2a4451e user: Jan Beulich <jbeulich@suse.com> date: Sun Sep 18 00:26:52 2011 +0100 x86: split MSI IRQ chip With the .end() accessor having become optional and noting that several of the accessors' behavior really depends on the result of msi_maskable_irq(), the splits the MSI IRQ chip type into two - one for the maskable ones, and the other for the (MSI only) non-maskable ones. At once the implementation of those methods gets moved from io_apic.c to msi.c. Signed-off-by: Jan Beulich <jbeulich@suse.com> ======================================== commit cd776ee9408ff127f934a707c1a339ee600bc127 Author: Ian Jackson <ian.jackson@eu.citrix.com> Date: Tue Jun 28 13:50:53 2011 +0100 qemu-char.c: fix incorrect CONFIG_STUBDOM handling qemu-char.c:1123:7: warning: "CONFIG_STUBDOM" is not defined [-Wundef] Signed-off-by: Olaf Hering <olaf@aepfle.de> Acked-by: Ian Jackson <ian.jackson@eu.citrix.com> _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel From xen-devel-bounces@lists.xensource.com Fri Sep 23 10:22:23 2011 Return-path: <xen-devel-bounces@lists.xensource.com> Envelope-to: www-data@lists.xensource.com Delivery-date: Fri, 23 Sep 2011 10:22:23 -0700 Received: from localhost ([127.0.0.1] helo=lists.colo.xensource.com) by lists.xensource.com with esmtp (Exim 4.43) id 1R79SA-0001MW-TE; Fri, 23 Sep 2011 10:22:22 -0700 Received: from mail174.messagelabs.com ([85.158.138.51]) by lists.xensource.com with esmtp (Exim 4.43) id 1R79RC-00019j-5A for xen-devel@lists.xensource.com; Fri, 23 Sep 2011 10:21:23 -0700 X-Env-Sender: pasik@iki.fi X-Msg-Ref: server-13.tower-174.messagelabs.com!1316798478!32550798!1 X-Originating-IP: [192.89.123.25] X-StarScan-Version: 6.4.1; banners=-,-,- X-VirusChecked: Checked Received: (qmail 21406 invoked from network); 23 Sep 2011 17:21:19 -0000 Received: from smtp.tele.fi (HELO smtp.tele.fi) (192.89.123.25) by server-13.tower-174.messagelabs.com with DHE-RSA-AES256-SHA encrypted SMTP; 23 Sep 2011 17:21:19 -0000 X-Originating-Ip: [194.89.68.22] Received: from ydin.reaktio.net (reaktio.net [194.89.68.22]) by smtp.tele.fi (Postfix) with ESMTP id D61A91C13; Fri, 23 Sep 2011 20:21:16 +0300 (EEST) Received: by ydin.reaktio.net (Postfix, from userid 1001) id 0BBC8200EA; Fri, 23 Sep 2011 20:21:16 +0300 (EEST) Date: Fri, 23 Sep 2011 20:21:15 +0300 From: Pasi =?iso-8859-1?Q?K=E4rkk=E4inen?= <pasik@iki.fi> To: JavMV <javier.manzano@edu.uah.es> Subject: Re: Re : Re : Re : Re : [Xen-devel] Re: Patches for VGA-Passthrough XEN 4.2 unstable Message-ID: <20110923172115.GI12984@reaktio.net> References: <1316615526442-4826582.post@n5.nabble.com> <1316616001843-4826614.post@n5.nabble.com> <1316616472579-4826635.post@n5.nabble.com> <1316616757871-4826655.post@n5.nabble.com> <1316618006.67296.YahooMailNeo@web29818.mail.ird.yahoo.com> <1316693722029-4829929.post@n5.nabble.com> <20110922182705.GE12984@reaktio.net> <1316728444821-4831624.post@n5.nabble.com> <1316777654598-4833174.post@n5.nabble.com> <1316786412428-4833637.post@n5.nabble.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <1316786412428-4833637.post@n5.nabble.com> User-Agent: Mutt/1.5.18 (2008-05-17) Cc: xen-devel@lists.xensource.com X-BeenThere: xen-devel@lists.xensource.com X-Mailman-Version: 2.1.5 Precedence: list List-Id: Xen developer discussion <xen-devel.lists.xensource.com> List-Unsubscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe> List-Post: <mailto:xen-devel@lists.xensource.com> List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help> List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=subscribe> Sender: xen-devel-bounces@lists.xensource.com Errors-To: xen-devel-bounces@lists.xensource.com On Fri, Sep 23, 2011 at 07:00:12AM -0700, JavMV wrote: > Hi again, ... do you wanna hear a funny story? > > Well here it is, The Vt-d features doesn't work if I use the changeset 23799 > (David's patches are for this one), but Vt-d features works if I use > changeset 23350 but in this changeset there is a bug related with VNC viewer > which shows a white screen all time instead of guest screen ( > http://bugzilla.xensource.com/bugzilla/show_bug.cgi?id=1766 > http://bugzilla.xensource.com/bugzilla/show_bug.cgi?id=1766 ). > > So I must use a changeset lower than 23799 (*because this have some changes > that provokes VT-d (iommu) fails on my computer*) but I need a changeset > that have already fixed the VNC bug (greater than 23350) in order to have > access to the winxp guest, and then I will need luck to patch them with one > of the adaptations (mine or David's) otherwise I will have to adapt them > again. > > So now, do you know where I can find a list with all the changesets and > their respective changes applied? > Do you mean the mercurial changelog? http://xenbits.xen.org/xen-unstable.hg Also you should open a new thread about the VT-d problem with the latest xen-unstable, because that's a separate issue from vga passthru, and it should be solved first and separately. -- Pasi > Best regards > > Javier > > ----- > JavMV > -- > View this message in context: http://xen.1045712.n5.nabble.com/Patches-for-VGA-Passthrough-XEN-4-2-unstable-tp4406265p4833637.html > Sent from the Xen - Dev mailing list archive at Nabble.com. > > _______________________________________________ > Xen-devel mailing list > Xen-devel@lists.xensource.com > http://lists.xensource.com/xen-devel _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel From xen-devel-bounces@lists.xensource.com Fri Sep 23 10:34:01 2011 Return-path: <xen-devel-bounces@lists.xensource.com> Envelope-to: www-data@lists.xensource.com Delivery-date: Fri, 23 Sep 2011 10:34:01 -0700 Received: from localhost ([127.0.0.1] helo=lists.colo.xensource.com) by lists.xensource.com with esmtp (Exim 4.43) id 1R79dQ-0001tZ-FB; Fri, 23 Sep 2011 10:34:00 -0700 Received: from mail27.messagelabs.com ([193.109.254.147]) by lists.xensource.com with smtp (Exim 4.43) id 1R79ch-0001h5-Bi for xen-devel@lists.xensource.com; Fri, 23 Sep 2011 10:33:16 -0700 X-Env-Sender: jim_burn@bellsouth.net X-Msg-Ref: server-11.tower-27.messagelabs.com!1316799182!38666944!1 X-Originating-IP: [66.94.236.21] X-StarScan-Version: 6.4.1; banners=-,-,- X-VirusChecked: Checked Received: (qmail 1304 invoked from network); 23 Sep 2011 17:33:03 -0000 Received: from nm17-vm0.access.bullet.mail.mud.yahoo.com (HELO nm17-vm0.access.bullet.mail.mud.yahoo.com) (66.94.236.21) by server-11.tower-27.messagelabs.com with SMTP; 23 Sep 2011 17:33:03 -0000 Received: from [66.94.237.201] by nm17.access.bullet.mail.mud.yahoo.com with NNFMP; 23 Sep 2011 17:33:11 -0000 Received: from [66.94.237.98] by tm12.access.bullet.mail.mud.yahoo.com with NNFMP; 23 Sep 2011 17:33:11 -0000 Received: from [127.0.0.1] by omp1003.access.mail.mud.yahoo.com with NNFMP; 23 Sep 2011 17:33:11 -0000 X-Yahoo-Newman-Id: 308753.57738.bm@omp1003.access.mail.mud.yahoo.com Received: (qmail 26406 invoked from network); 23 Sep 2011 17:33:11 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=bellsouth.net; s=s1024; t=1316799191; bh=9Jgik8vP1V9+SfO9rljB+px8/Mfee7ssgwQxxBH1no8=; h=X-Yahoo-Newman-Property:X-YMail-OSG:X-Yahoo-SMTP:Received:From:To:Cc:Subject:Date:Message-ID:User-Agent:In-Reply-To:References:MIME-Version:Content-Transfer-Encoding:Content-Type; b=WkuZmNmLJsEdMBIPapKmeqHg+eZAwm/0LAVhGQeplYtK7+0PENLlfo7r9mONrxJN67PGfYiwPr+DhoJi5+41j0BwGl6JLbCSoZTCdFQ9uB+esBO8/IyQflpU0e0hJEc2sUB98AotRr/rndp5TYLzMUcG1L6MOBFJnyDoSCPSJD0= X-Yahoo-Newman-Property: ymail-3 X-YMail-OSG: cVoti7QVM1lQiD7_EKIry.OLuWZKKiEmliEAvf6Uwi.Zn2f k4Acb7RWGHZl8hQWtdIOf1l87zPbFXSC29BclZTmJMv9D9ogMfjRq81T4RL_ .soq14lqllWcj3HbcXO5V8Ox_niAxmAw4Y23TluStpdcyR78l6c5ZPTPDWyr yFw0Dk4JktHYx5ppO2z4bR8R0X7jPQzsFtfh7cjwVzTtDC7PWM7FV2eiV0eV 025.tY7jp.pyU4AiyLMILr8F.kkU8kYWIAI5MH5vj5X6V1Q_5DjNGX0wQ9Y9 aSPd62y0xDXGYX9eeUPsQEK8CqbiarMiOBk4pzfM1NiKxuZYGy3qNVACmShA aoe9J3Zx9qbpPf_MTsWhg5aEdLoD.RubFzS266Jv0Yozi.tw.z9MAqKhxQpQ bb.ipeHXViGuW7FZedtY5Mjf.wuH7QaNFyNhgwg-- X-Yahoo-SMTP: g0AhWW2swBA2djJKuhuwxPlPqLrHlDrycdPnfR9kZNrpKCA- Received: from dell4550.localnet (jim_burn@74.190.198.77 with plain) by smtp112.sbc.mail.mud.yahoo.com with SMTP; 23 Sep 2011 10:33:10 -0700 PDT From: jim burns <jim_burn@bellsouth.net> To: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com> Subject: Re: [Fedora-xen] [Xen-devel] Re: [Xen-users] Continuing BUG:-iness booting Fedora Rawhide 3.1.0-rc's (was Summary: Experiences setting up a debug serial port) Date: Fri, 23 Sep 2011 13:33:02 -0400 Message-ID: <28648118.H7Wrr3RcQX@dell4550> User-Agent: KMail/4.7.1 (Linux/2.6.37.6-0.7-default; KDE/4.7.1; i686; ; ) In-Reply-To: <2321907.7IxSxmjte4@dell4550> References: <201107231426.56811.jim_burn@bellsouth.net> <1777265.Pkue3yJNHT@dell4550> <2321907.7IxSxmjte4@dell4550> MIME-Version: 1.0 Content-Transfer-Encoding: 7Bit Content-Type: text/plain; charset="us-ascii" Cc: xen-devel@lists.xensource.com, Fedora Xen List <fedora-xen@redhat.com>, Ian Campbell <Ian.Campbell@eu.citrix.com>, M A Young <m.a.young@durham.ac.uk>, xen-users@lists.xensource.com X-BeenThere: xen-devel@lists.xensource.com X-Mailman-Version: 2.1.5 Precedence: list List-Id: Xen developer discussion <xen-devel.lists.xensource.com> List-Unsubscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe> List-Post: <mailto:xen-devel@lists.xensource.com> List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help> List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=subscribe> Sender: xen-devel-bounces@lists.xensource.com Errors-To: xen-devel-bounces@lists.xensource.com On Fri September 16 2011, 6:42:32 PM, jim burns wrote: > On Fri September 16 2011, 4:06:30 PM, jim burns wrote: > > OK, if your confident that these problems will go away in a production > > kernel, especially the GPF error, I can wait. If you don't need > > anything > > else, I'll bring down the system, and retreat to 2.6.40 in a couple of > > hours. Thanx for you attention. > > Sorry, I take it back. Just rebooted back into 2.6.40, and I'm still getting > GPF errors - just not very frequently. Yayyy! Fedora rawhide just came out with 3.1.0-0.rc7.git0.2.fc17. It boots up without any BUG:s. I assume your ' Alter the locking to be a mutex.' patch made it into rc7. It starts my winxp domu, w/512 MB, reasonably fast, for a rawhide kernel. 'time xm create' reports: xm create winxp 0.21s user 0.48s system 3% cpu 17.738 total This is a far cry from the 3-6 min. under rc6. When I up the memory to 768 MB, 'xm create' does not hang, like in rc6, but does take longer to complete: xm create winxp 0.18s user 0.64s system 0% cpu 2:48.65 total Also, tmem (I'm guessing) is cooperating with dom0's 'free' a lot better. Starting up rc7, before starting any guests: jimb@insp6400 09/23/11 11:07AM:~ [503] > free total used free shared buffers cached Mem: 1797668 1702884 94784 0 82784 490104 -/+ buffers/cache: 1129996 667672 Swap: 4063228 0 4063228 After starting one 512 MB guest: root@insp6400 09/23/11 11:23AM:~ [504] > free total used free shared buffers cached Mem: 1387244 1352212 35032 0 23660 178560 -/+ buffers/cache: 1149992 237252 Swap: 4063228 104 4063124 After stopping the 512 MB guest, and starting a 768 MB guest: root@insp6400 09/23/11 11:38AM:~ [510] > free total used free shared buffers cached Mem: 1073900 1058108 15792 0 2564 66488 -/+ buffers/cache: 989056 84844 Swap: 4063228 141368 3921860 However, on 3.1.0-0.rc6.git0.0.xendom0.fc17 (myoung's temp build), before any guests: [506] > free total used free shared buffers cached Mem: 1495104 1407388 87716 0 14780 116976 -/+ buffers/cache: 1275632 219472 Swap: 4063228 8508 4054720 which is 300 MB less than rc7. After starting up a 512 MB guest: root@insp6400 09/23/11 1:17PM:/boot/grub [510] > free total used free shared buffers cached Mem: 1084680 1000164 84516 0 2580 75724 -/+ buffers/cache: 921860 162820 Swap: 4063228 388032 3675196 which is still 300 MB less than rc7. In all cases, 'xm list' does report the correct amount of memory. I'm saying the cooperation with dom0's 'free' is better in rc7. All in all, you're heading in the right direction. Thanx a lot. _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel From xen-devel-bounces@lists.xensource.com Fri Sep 23 10:53:59 2011 Return-path: <xen-devel-bounces@lists.xensource.com> Envelope-to: www-data@lists.xensource.com Delivery-date: Fri, 23 Sep 2011 10:53:59 -0700 Received: from localhost ([127.0.0.1] helo=lists.colo.xensource.com) by lists.xensource.com with esmtp (Exim 4.43) id 1R79wl-00044B-JH; Fri, 23 Sep 2011 10:53:59 -0700 Received: from mail216.messagelabs.com ([85.158.143.99]) by lists.xensource.com with esmtp (Exim 4.43) id 1R79w3-0003ry-Bt for xen-devel@lists.xensource.com; Fri, 23 Sep 2011 10:53:15 -0700 X-Env-Sender: david.vrabel@citrix.com X-Msg-Ref: server-15.tower-216.messagelabs.com!1316800390!18881727!1 X-Originating-IP: [66.165.176.89] X-StarScan-Version: 6.4.1; banners=-,-,- X-VirusChecked: Checked Received: (qmail 4965 invoked from network); 23 Sep 2011 17:53:12 -0000 Received: from smtp.citrix.com (HELO SMTP.CITRIX.COM) (66.165.176.89) by server-15.tower-216.messagelabs.com with RC4-SHA encrypted SMTP; 23 Sep 2011 17:53:12 -0000 X-IronPort-AV: E=Sophos;i="4.68,431,1312171200"; d="scan'208";a="17654503" Received: from ftlpmailmx02.citrite.net ([10.13.107.66]) by FTLPIPO01.CITRIX.COM with ESMTP/TLS/RC4-MD5; 23 Sep 2011 13:53:10 -0400 Received: from smtp01.ad.xensource.com (10.219.128.104) by smtprelay.citrix.com (10.13.107.66) with Microsoft SMTP Server id 8.3.137.0; Fri, 23 Sep 2011 13:53:10 -0400 Received: from qabil.uk.xensource.com (qabil.uk.xensource.com [10.80.2.76]) by smtp01.ad.xensource.com (8.13.1/8.13.1) with ESMTP id p8NHr6tl031719; Fri, 23 Sep 2011 10:53:06 -0700 From: David Vrabel <david.vrabel@citrix.com> To: xen-devel@lists.xensource.com Date: Fri, 23 Sep 2011 18:55:19 +0100 Message-ID: <1316800523-30144-1-git-send-email-david.vrabel@citrix.com> X-Mailer: git-send-email 1.7.2.5 MIME-Version: 1.0 Content-Type: text/plain Cc: Jeremy Fitzhardinge <jeremy@goop.org>, Konrad Rzeszutek Wilk <konrad.wilk@oracle.com> Subject: [Xen-devel] [RFC] xen: map foreign pages for shared rings by updating the PTEs directly X-BeenThere: xen-devel@lists.xensource.com X-Mailman-Version: 2.1.5 Precedence: list List-Id: Xen developer discussion <xen-devel.lists.xensource.com> List-Unsubscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe> List-Post: <mailto:xen-devel@lists.xensource.com> List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help> List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=subscribe> Sender: xen-devel-bounces@lists.xensource.com Errors-To: xen-devel-bounces@lists.xensource.com This series of patches allows the vmalloc_sync_all() to be removed from alloc_vm_area() by getting the hypervisor to update the PTEs (in init_mm) directly rather than having the hypervisor look in the current page tables to find the PTEs. Once the hypervisor has updated the PTEs, the normal mechanism of syncing the page tables after a fault works as expected. This mechanism doesn't currently work on the ia64 port as that does not support the GNTMAP_contains_pte flag. David _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel From xen-devel-bounces@lists.xensource.com Fri Sep 23 10:55:08 2011 Return-path: <xen-devel-bounces@lists.xensource.com> Envelope-to: www-data@lists.xensource.com Delivery-date: Fri, 23 Sep 2011 10:55:08 -0700 Received: from localhost ([127.0.0.1] helo=lists.colo.xensource.com) by lists.xensource.com with esmtp (Exim 4.43) id 1R79xs-0004Rj-FK; Fri, 23 Sep 2011 10:55:08 -0700 Received: from mail216.messagelabs.com ([85.158.143.99]) by lists.xensource.com with esmtp (Exim 4.43) id 1R79w4-0003rz-Gm for xen-devel@lists.xensource.com; Fri, 23 Sep 2011 10:53:17 -0700 X-Env-Sender: david.vrabel@citrix.com X-Msg-Ref: server-15.tower-216.messagelabs.com!1316800390!18881727!2 X-Originating-IP: [66.165.176.89] X-StarScan-Version: 6.4.1; banners=-,-,- X-VirusChecked: Checked Received: (qmail 4977 invoked from network); 23 Sep 2011 17:53:13 -0000 Received: from smtp.citrix.com (HELO SMTP.CITRIX.COM) (66.165.176.89) by server-15.tower-216.messagelabs.com with RC4-SHA encrypted SMTP; 23 Sep 2011 17:53:13 -0000 X-IronPort-AV: E=Sophos;i="4.68,431,1312171200"; d="scan'208";a="17654504" Received: from ftlpmailmx02.citrite.net ([10.13.107.66]) by FTLPIPO01.CITRIX.COM with ESMTP/TLS/RC4-MD5; 23 Sep 2011 13:53:12 -0400 Received: from smtp01.ad.xensource.com (10.219.128.104) by smtprelay.citrix.com (10.13.107.66) with Microsoft SMTP Server id 8.3.137.0; Fri, 23 Sep 2011 13:53:13 -0400 Received: from qabil.uk.xensource.com (qabil.uk.xensource.com [10.80.2.76]) by smtp01.ad.xensource.com (8.13.1/8.13.1) with ESMTP id p8NHr6tn031719; Fri, 23 Sep 2011 10:53:11 -0700 From: David Vrabel <david.vrabel@citrix.com> To: xen-devel@lists.xensource.com Date: Fri, 23 Sep 2011 18:55:21 +0100 Message-ID: <1316800523-30144-3-git-send-email-david.vrabel@citrix.com> X-Mailer: git-send-email 1.7.2.5 In-Reply-To: <1316800523-30144-1-git-send-email-david.vrabel@citrix.com> References: <1316800523-30144-1-git-send-email-david.vrabel@citrix.com> MIME-Version: 1.0 Content-Type: text/plain Cc: Jeremy Fitzhardinge <jeremy@goop.org>, David Vrabel <david.vrabel@citrix.com>, Konrad Rzeszutek Wilk <konrad.wilk@oracle.com> Subject: [Xen-devel] [PATCH 2/4] block: xen-blkback: use API provided by xenbus module to map rings X-BeenThere: xen-devel@lists.xensource.com X-Mailman-Version: 2.1.5 Precedence: list List-Id: Xen developer discussion <xen-devel.lists.xensource.com> List-Unsubscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe> List-Post: <mailto:xen-devel@lists.xensource.com> List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help> List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=subscribe> Sender: xen-devel-bounces@lists.xensource.com Errors-To: xen-devel-bounces@lists.xensource.com From: David Vrabel <david.vrabel@citrix.com> The xenbus module provides xenbus_map_ring_valloc() and xenbus_map_ring_vfree(). Use these to map the ring pages granted by the frontend. Signed-off-by: David Vrabel <david.vrabel@citrix.com> --- drivers/block/xen-blkback/common.h | 5 +-- drivers/block/xen-blkback/xenbus.c | 54 ++++------------------------------- 2 files changed, 8 insertions(+), 51 deletions(-) diff --git a/drivers/block/xen-blkback/common.h b/drivers/block/xen-blkback/common.h index 9e40b28..07dd177 100644 --- a/drivers/block/xen-blkback/common.h +++ b/drivers/block/xen-blkback/common.h @@ -139,7 +139,7 @@ struct xen_blkif { /* Comms information. */ enum blkif_protocol blk_protocol; union blkif_back_rings blk_rings; - struct vm_struct *blk_ring_area; + void *blk_ring; /* The VBD attached to this interface. */ struct xen_vbd vbd; /* Back pointer to the backend_info. */ @@ -163,9 +163,6 @@ struct xen_blkif { int st_wr_sect; wait_queue_head_t waiting_to_free; - - grant_handle_t shmem_handle; - grant_ref_t shmem_ref; }; diff --git a/drivers/block/xen-blkback/xenbus.c b/drivers/block/xen-blkback/xenbus.c index 3f129b4..73703d5 100644 --- a/drivers/block/xen-blkback/xenbus.c +++ b/drivers/block/xen-blkback/xenbus.c @@ -120,38 +120,6 @@ static struct xen_blkif *xen_blkif_alloc(domid_t domid) return blkif; } -static int map_frontend_page(struct xen_blkif *blkif, unsigned long shared_page) -{ - struct gnttab_map_grant_ref op; - - gnttab_set_map_op(&op, (unsigned long)blkif->blk_ring_area->addr, - GNTMAP_host_map, shared_page, blkif->domid); - - if (HYPERVISOR_grant_table_op(GNTTABOP_map_grant_ref, &op, 1)) - BUG(); - - if (op.status) { - DPRINTK("Grant table operation failure !\n"); - return op.status; - } - - blkif->shmem_ref = shared_page; - blkif->shmem_handle = op.handle; - - return 0; -} - -static void unmap_frontend_page(struct xen_blkif *blkif) -{ - struct gnttab_unmap_grant_ref op; - - gnttab_set_unmap_op(&op, (unsigned long)blkif->blk_ring_area->addr, - GNTMAP_host_map, blkif->shmem_handle); - - if (HYPERVISOR_grant_table_op(GNTTABOP_unmap_grant_ref, &op, 1)) - BUG(); -} - static int xen_blkif_map(struct xen_blkif *blkif, unsigned long shared_page, unsigned int evtchn) { @@ -161,35 +129,29 @@ static int xen_blkif_map(struct xen_blkif *blkif, unsigned long shared_page, if (blkif->irq) return 0; - blkif->blk_ring_area = alloc_vm_area(PAGE_SIZE); - if (!blkif->blk_ring_area) - return -ENOMEM; - - err = map_frontend_page(blkif, shared_page); - if (err) { - free_vm_area(blkif->blk_ring_area); + err = xenbus_map_ring_valloc(blkif->be->dev, shared_page, &blkif->blk_ring); + if (err < 0) return err; - } switch (blkif->blk_protocol) { case BLKIF_PROTOCOL_NATIVE: { struct blkif_sring *sring; - sring = (struct blkif_sring *)blkif->blk_ring_area->addr; + sring = (struct blkif_sring *)blkif->blk_ring; BACK_RING_INIT(&blkif->blk_rings.native, sring, PAGE_SIZE); break; } case BLKIF_PROTOCOL_X86_32: { struct blkif_x86_32_sring *sring_x86_32; - sring_x86_32 = (struct blkif_x86_32_sring *)blkif->blk_ring_area->addr; + sring_x86_32 = (struct blkif_x86_32_sring *)blkif->blk_ring; BACK_RING_INIT(&blkif->blk_rings.x86_32, sring_x86_32, PAGE_SIZE); break; } case BLKIF_PROTOCOL_X86_64: { struct blkif_x86_64_sring *sring_x86_64; - sring_x86_64 = (struct blkif_x86_64_sring *)blkif->blk_ring_area->addr; + sring_x86_64 = (struct blkif_x86_64_sring *)blkif->blk_ring; BACK_RING_INIT(&blkif->blk_rings.x86_64, sring_x86_64, PAGE_SIZE); break; } @@ -201,8 +163,7 @@ static int xen_blkif_map(struct xen_blkif *blkif, unsigned long shared_page, xen_blkif_be_int, 0, "blkif-backend", blkif); if (err < 0) { - unmap_frontend_page(blkif); - free_vm_area(blkif->blk_ring_area); + xenbus_unmap_ring_vfree(blkif->be->dev, blkif->blk_ring); blkif->blk_rings.common.sring = NULL; return err; } @@ -228,8 +189,7 @@ static void xen_blkif_disconnect(struct xen_blkif *blkif) } if (blkif->blk_rings.common.sring) { - unmap_frontend_page(blkif); - free_vm_area(blkif->blk_ring_area); + xenbus_unmap_ring_vfree(blkif->be->dev, blkif->blk_ring); blkif->blk_rings.common.sring = NULL; } } -- 1.7.2.5 _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel From xen-devel-bounces@lists.xensource.com Fri Sep 23 10:56:17 2011 Return-path: <xen-devel-bounces@lists.xensource.com> Envelope-to: www-data@lists.xensource.com Delivery-date: Fri, 23 Sep 2011 10:56:17 -0700 Received: from localhost ([127.0.0.1] helo=lists.colo.xensource.com) by lists.xensource.com with esmtp (Exim 4.43) id 1R79yz-0004oh-1a; Fri, 23 Sep 2011 10:56:17 -0700 Received: from mail27.messagelabs.com ([193.109.254.147]) by lists.xensource.com with esmtp (Exim 4.43) id 1R79w5-0003s0-QK for xen-devel@lists.xensource.com; Fri, 23 Sep 2011 10:53:18 -0700 X-Env-Sender: david.vrabel@citrix.com X-Msg-Ref: server-9.tower-27.messagelabs.com!1316800376!45780172!1 X-Originating-IP: [66.165.176.63] X-StarScan-Version: 6.4.1; banners=-,-,- X-VirusChecked: Checked Received: (qmail 8284 invoked from network); 23 Sep 2011 17:52:57 -0000 Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63) by server-9.tower-27.messagelabs.com with RC4-SHA encrypted SMTP; 23 Sep 2011 17:52:57 -0000 X-IronPort-AV: E=Sophos;i="4.68,431,1312171200"; d="scan'208";a="164485004" Received: from ftlpmailmx02.citrite.net ([10.13.107.66]) by FTLPIPO02.CITRIX.COM with ESMTP/TLS/RC4-MD5; 23 Sep 2011 13:53:11 -0400 Received: from smtp01.ad.xensource.com (10.219.128.104) by smtprelay.citrix.com (10.13.107.66) with Microsoft SMTP Server id 8.3.137.0; Fri, 23 Sep 2011 13:53:11 -0400 Received: from qabil.uk.xensource.com (qabil.uk.xensource.com [10.80.2.76]) by smtp01.ad.xensource.com (8.13.1/8.13.1) with ESMTP id p8NHr6tm031719; Fri, 23 Sep 2011 10:53:10 -0700 From: David Vrabel <david.vrabel@citrix.com> To: xen-devel@lists.xensource.com Date: Fri, 23 Sep 2011 18:55:20 +0100 Message-ID: <1316800523-30144-2-git-send-email-david.vrabel@citrix.com> X-Mailer: git-send-email 1.7.2.5 In-Reply-To: <1316800523-30144-1-git-send-email-david.vrabel@citrix.com> References: <1316800523-30144-1-git-send-email-david.vrabel@citrix.com> MIME-Version: 1.0 Content-Type: text/plain Cc: Jeremy Fitzhardinge <jeremy@goop.org>, David Vrabel <david.vrabel@citrix.com>, Konrad Rzeszutek Wilk <konrad.wilk@oracle.com> Subject: [Xen-devel] [PATCH 1/4] xen: use generic functions instead of xen_{alloc, free}_vm_area() X-BeenThere: xen-devel@lists.xensource.com X-Mailman-Version: 2.1.5 Precedence: list List-Id: Xen developer discussion <xen-devel.lists.xensource.com> List-Unsubscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe> List-Post: <mailto:xen-devel@lists.xensource.com> List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help> List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=subscribe> Sender: xen-devel-bounces@lists.xensource.com Errors-To: xen-devel-bounces@lists.xensource.com From: David Vrabel <david.vrabel@citrix.com> Replace calls to the Xen-specific xen_alloc_vm_area() and xen_free_vm_area() functions with the generic equivalent (alloc_vm_area() and free_vm_area()). On x86, these were identical already. Signed-off-by: David Vrabel <david.vrabel@citrix.com> --- arch/ia64/include/asm/xen/grant_table.h | 29 -------------- arch/ia64/xen/grant-table.c | 62 ------------------------------- arch/x86/include/asm/xen/grant_table.h | 7 --- arch/x86/xen/grant-table.c | 2 +- drivers/xen/xenbus/xenbus_client.c | 6 +- include/xen/grant_table.h | 1 - 6 files changed, 4 insertions(+), 103 deletions(-) delete mode 100644 arch/ia64/include/asm/xen/grant_table.h delete mode 100644 arch/x86/include/asm/xen/grant_table.h diff --git a/arch/ia64/include/asm/xen/grant_table.h b/arch/ia64/include/asm/xen/grant_table.h deleted file mode 100644 index 2b1fae0..0000000 --- a/arch/ia64/include/asm/xen/grant_table.h +++ /dev/null @@ -1,29 +0,0 @@ -/****************************************************************************** - * arch/ia64/include/asm/xen/grant_table.h - * - * Copyright (c) 2008 Isaku Yamahata <yamahata at valinux co jp> - * VA Linux Systems Japan K.K. - * - * This program is free software; you can redistribute it and/or modify - * it under the terms of the GNU General Public License as published by - * the Free Software Foundation; either version 2 of the License, or - * (at your option) any later version. - * - * This program is distributed in the hope that it will be useful, - * but WITHOUT ANY WARRANTY; without even the implied warranty of - * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the - * GNU General Public License for more details. - * - * You should have received a copy of the GNU General Public License - * along with this program; if not, write to the Free Software - * Foundation, Inc., 59 Temple Place, Suite 330, Boston, MA 02111-1307 USA - * - */ - -#ifndef _ASM_IA64_XEN_GRANT_TABLE_H -#define _ASM_IA64_XEN_GRANT_TABLE_H - -struct vm_struct *xen_alloc_vm_area(unsigned long size); -void xen_free_vm_area(struct vm_struct *area); - -#endif /* _ASM_IA64_XEN_GRANT_TABLE_H */ diff --git a/arch/ia64/xen/grant-table.c b/arch/ia64/xen/grant-table.c index 48cca37..c182813 100644 --- a/arch/ia64/xen/grant-table.c +++ b/arch/ia64/xen/grant-table.c @@ -31,68 +31,6 @@ #include <asm/xen/hypervisor.h> -struct vm_struct *xen_alloc_vm_area(unsigned long size) -{ - int order; - unsigned long virt; - unsigned long nr_pages; - struct vm_struct *area; - - order = get_order(size); - virt = __get_free_pages(GFP_KERNEL, order); - if (virt == 0) - goto err0; - nr_pages = 1 << order; - scrub_pages(virt, nr_pages); - - area = kmalloc(sizeof(*area), GFP_KERNEL); - if (area == NULL) - goto err1; - - area->flags = VM_IOREMAP; - area->addr = (void *)virt; - area->size = size; - area->pages = NULL; - area->nr_pages = nr_pages; - area->phys_addr = 0; /* xenbus_map_ring_valloc uses this field! */ - - return area; - -err1: - free_pages(virt, order); -err0: - return NULL; -} -EXPORT_SYMBOL_GPL(xen_alloc_vm_area); - -void xen_free_vm_area(struct vm_struct *area) -{ - unsigned int order = get_order(area->size); - unsigned long i; - unsigned long phys_addr = __pa(area->addr); - - /* This area is used for foreign page mappping. - * So underlying machine page may not be assigned. */ - for (i = 0; i < (1 << order); i++) { - unsigned long ret; - unsigned long gpfn = (phys_addr >> PAGE_SHIFT) + i; - struct xen_memory_reservation reservation = { - .nr_extents = 1, - .address_bits = 0, - .extent_order = 0, - .domid = DOMID_SELF - }; - set_xen_guest_handle(reservation.extent_start, &gpfn); - ret = HYPERVISOR_memory_op(XENMEM_populate_physmap, - &reservation); - BUG_ON(ret != 1); - } - free_pages((unsigned long)area->addr, order); - kfree(area); -} -EXPORT_SYMBOL_GPL(xen_free_vm_area); - - /**************************************************************************** * grant table hack * cmd: GNTTABOP_xxx diff --git a/arch/x86/include/asm/xen/grant_table.h b/arch/x86/include/asm/xen/grant_table.h deleted file mode 100644 index fdbbb45..0000000 --- a/arch/x86/include/asm/xen/grant_table.h +++ /dev/null @@ -1,7 +0,0 @@ -#ifndef _ASM_X86_XEN_GRANT_TABLE_H -#define _ASM_X86_XEN_GRANT_TABLE_H - -#define xen_alloc_vm_area(size) alloc_vm_area(size) -#define xen_free_vm_area(area) free_vm_area(area) - -#endif /* _ASM_X86_XEN_GRANT_TABLE_H */ diff --git a/arch/x86/xen/grant-table.c b/arch/x86/xen/grant-table.c index 49ba9b5..6bbfd7a 100644 --- a/arch/x86/xen/grant-table.c +++ b/arch/x86/xen/grant-table.c @@ -71,7 +71,7 @@ int arch_gnttab_map_shared(unsigned long *frames, unsigned long nr_gframes, if (shared == NULL) { struct vm_struct *area = - xen_alloc_vm_area(PAGE_SIZE * max_nr_gframes); + alloc_vm_area(PAGE_SIZE * max_nr_gframes); BUG_ON(area == NULL); shared = area->addr; *__shared = shared; diff --git a/drivers/xen/xenbus/xenbus_client.c b/drivers/xen/xenbus/xenbus_client.c index cdacf92..229d3ad 100644 --- a/drivers/xen/xenbus/xenbus_client.c +++ b/drivers/xen/xenbus/xenbus_client.c @@ -443,7 +443,7 @@ int xenbus_map_ring_valloc(struct xenbus_device *dev, int gnt_ref, void **vaddr) *vaddr = NULL; - area = xen_alloc_vm_area(PAGE_SIZE); + area = alloc_vm_area(PAGE_SIZE); if (!area) return -ENOMEM; @@ -453,7 +453,7 @@ int xenbus_map_ring_valloc(struct xenbus_device *dev, int gnt_ref, void **vaddr) BUG(); if (op.status != GNTST_okay) { - xen_free_vm_area(area); + free_vm_area(area); xenbus_dev_fatal(dev, op.status, "mapping in shared page %d from domain %d", gnt_ref, dev->otherend_id); @@ -552,7 +552,7 @@ int xenbus_unmap_ring_vfree(struct xenbus_device *dev, void *vaddr) BUG(); if (op.status == GNTST_okay) - xen_free_vm_area(area); + free_vm_area(area); else xenbus_dev_error(dev, op.status, "unmapping page at handle %d error %d", diff --git a/include/xen/grant_table.h b/include/xen/grant_table.h index b1fab6b..8a8bb76 100644 --- a/include/xen/grant_table.h +++ b/include/xen/grant_table.h @@ -43,7 +43,6 @@ #include <xen/interface/grant_table.h> #include <asm/xen/hypervisor.h> -#include <asm/xen/grant_table.h> #include <xen/features.h> -- 1.7.2.5 _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel From xen-devel-bounces@lists.xensource.com Fri Sep 23 10:57:15 2011 Return-path: <xen-devel-bounces@lists.xensource.com> Envelope-to: www-data@lists.xensource.com Delivery-date: Fri, 23 Sep 2011 10:57:15 -0700 Received: from localhost ([127.0.0.1] helo=lists.colo.xensource.com) by lists.xensource.com with esmtp (Exim 4.43) id 1R79zv-0005DG-BO; Fri, 23 Sep 2011 10:57:15 -0700 Received: from mail27.messagelabs.com ([193.109.254.147]) by lists.xensource.com with esmtp (Exim 4.43) id 1R79w6-0003s6-Gb for xen-devel@lists.xensource.com; Fri, 23 Sep 2011 10:53:18 -0700 X-Env-Sender: david.vrabel@citrix.com X-Msg-Ref: server-9.tower-27.messagelabs.com!1316800376!45780172!2 X-Originating-IP: [66.165.176.63] X-StarScan-Version: 6.4.1; banners=-,-,- X-VirusChecked: Checked Received: (qmail 8296 invoked from network); 23 Sep 2011 17:52:58 -0000 Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63) by server-9.tower-27.messagelabs.com with RC4-SHA encrypted SMTP; 23 Sep 2011 17:52:58 -0000 X-IronPort-AV: E=Sophos;i="4.68,431,1312171200"; d="scan'208";a="164485012" Received: from ftlpmailmx02.citrite.net ([10.13.107.66]) by FTLPIPO02.CITRIX.COM with ESMTP/TLS/RC4-MD5; 23 Sep 2011 13:53:14 -0400 Received: from smtp01.ad.xensource.com (10.219.128.104) by smtprelay.citrix.com (10.13.107.66) with Microsoft SMTP Server id 8.3.137.0; Fri, 23 Sep 2011 13:53:14 -0400 Received: from qabil.uk.xensource.com (qabil.uk.xensource.com [10.80.2.76]) by smtp01.ad.xensource.com (8.13.1/8.13.1) with ESMTP id p8NHr6to031719; Fri, 23 Sep 2011 10:53:12 -0700 From: David Vrabel <david.vrabel@citrix.com> To: xen-devel@lists.xensource.com Date: Fri, 23 Sep 2011 18:55:22 +0100 Message-ID: <1316800523-30144-4-git-send-email-david.vrabel@citrix.com> X-Mailer: git-send-email 1.7.2.5 In-Reply-To: <1316800523-30144-1-git-send-email-david.vrabel@citrix.com> References: <1316800523-30144-1-git-send-email-david.vrabel@citrix.com> MIME-Version: 1.0 Content-Type: text/plain Cc: Jeremy Fitzhardinge <jeremy@goop.org>, David Vrabel <david.vrabel@citrix.com>, Ian Campbell <ian.campbell@citrix.com>, Konrad Rzeszutek Wilk <konrad.wilk@oracle.com> Subject: [Xen-devel] [PATCH 3/4] net: xen-netback: use API provided by xenbus module to map rings X-BeenThere: xen-devel@lists.xensource.com X-Mailman-Version: 2.1.5 Precedence: list List-Id: Xen developer discussion <xen-devel.lists.xensource.com> List-Unsubscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe> List-Post: <mailto:xen-devel@lists.xensource.com> List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help> List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=subscribe> Sender: xen-devel-bounces@lists.xensource.com Errors-To: xen-devel-bounces@lists.xensource.com From: David Vrabel <david.vrabel@citrix.com> The xenbus module provides xenbus_map_ring_valloc() and xenbus_map_ring_vfree(). Use these to map the Tx and Rx ring pages granted by the frontend. Signed-off-by: David Vrabel <david.vrabel@citrix.com> Cc: Ian Campbell <ian.campbell@citrix.com> --- drivers/net/xen-netback/common.h | 11 ++--- drivers/net/xen-netback/netback.c | 80 ++++++++----------------------------- 2 files changed, 22 insertions(+), 69 deletions(-) diff --git a/drivers/net/xen-netback/common.h b/drivers/net/xen-netback/common.h index 161f207..94b79c3 100644 --- a/drivers/net/xen-netback/common.h +++ b/drivers/net/xen-netback/common.h @@ -58,10 +58,6 @@ struct xenvif { u8 fe_dev_addr[6]; /* Physical parameters of the comms window. */ - grant_handle_t tx_shmem_handle; - grant_ref_t tx_shmem_ref; - grant_handle_t rx_shmem_handle; - grant_ref_t rx_shmem_ref; unsigned int irq; /* List of frontends to notify after a batch of frames sent. */ @@ -70,8 +66,6 @@ struct xenvif { /* The shared rings and indexes. */ struct xen_netif_tx_back_ring tx; struct xen_netif_rx_back_ring rx; - struct vm_struct *tx_comms_area; - struct vm_struct *rx_comms_area; /* Frontend feature information. */ u8 can_sg:1; @@ -106,6 +100,11 @@ struct xenvif { wait_queue_head_t waiting_to_free; }; +static inline struct xenbus_device *xenvif_to_xenbus_device(struct xenvif *vif) +{ + return to_xenbus_device(vif->dev->dev.parent); +} + #define XEN_NETIF_TX_RING_SIZE __CONST_RING_SIZE(xen_netif_tx, PAGE_SIZE) #define XEN_NETIF_RX_RING_SIZE __CONST_RING_SIZE(xen_netif_rx, PAGE_SIZE) diff --git a/drivers/net/xen-netback/netback.c b/drivers/net/xen-netback/netback.c index fd00f25..3af2924 100644 --- a/drivers/net/xen-netback/netback.c +++ b/drivers/net/xen-netback/netback.c @@ -1577,88 +1577,42 @@ static int xen_netbk_kthread(void *data) void xen_netbk_unmap_frontend_rings(struct xenvif *vif) { - struct gnttab_unmap_grant_ref op; - - if (vif->tx.sring) { - gnttab_set_unmap_op(&op, (unsigned long)vif->tx_comms_area->addr, - GNTMAP_host_map, vif->tx_shmem_handle); - - if (HYPERVISOR_grant_table_op(GNTTABOP_unmap_grant_ref, &op, 1)) - BUG(); - } - - if (vif->rx.sring) { - gnttab_set_unmap_op(&op, (unsigned long)vif->rx_comms_area->addr, - GNTMAP_host_map, vif->rx_shmem_handle); - - if (HYPERVISOR_grant_table_op(GNTTABOP_unmap_grant_ref, &op, 1)) - BUG(); - } - if (vif->rx_comms_area) - free_vm_area(vif->rx_comms_area); - if (vif->tx_comms_area) - free_vm_area(vif->tx_comms_area); + if (vif->tx.sring) + xenbus_unmap_ring_vfree(xenvif_to_xenbus_device(vif), + vif->tx.sring); + if (vif->rx.sring) + xenbus_unmap_ring_vfree(xenvif_to_xenbus_device(vif), + vif->rx.sring); } int xen_netbk_map_frontend_rings(struct xenvif *vif, grant_ref_t tx_ring_ref, grant_ref_t rx_ring_ref) { - struct gnttab_map_grant_ref op; + void *addr; struct xen_netif_tx_sring *txs; struct xen_netif_rx_sring *rxs; int err = -ENOMEM; - vif->tx_comms_area = alloc_vm_area(PAGE_SIZE); - if (vif->tx_comms_area == NULL) + err = xenbus_map_ring_valloc(xenvif_to_xenbus_device(vif), + tx_ring_ref, &addr); + if (err) goto err; - vif->rx_comms_area = alloc_vm_area(PAGE_SIZE); - if (vif->rx_comms_area == NULL) - goto err; - - gnttab_set_map_op(&op, (unsigned long)vif->tx_comms_area->addr, - GNTMAP_host_map, tx_ring_ref, vif->domid); - - if (HYPERVISOR_grant_table_op(GNTTABOP_map_grant_ref, &op, 1)) - BUG(); - - if (op.status) { - netdev_warn(vif->dev, - "failed to map tx ring. err=%d status=%d\n", - err, op.status); - err = op.status; - goto err; - } - - vif->tx_shmem_ref = tx_ring_ref; - vif->tx_shmem_handle = op.handle; - - txs = (struct xen_netif_tx_sring *)vif->tx_comms_area->addr; + txs = (struct xen_netif_tx_sring *)addr; BACK_RING_INIT(&vif->tx, txs, PAGE_SIZE); - gnttab_set_map_op(&op, (unsigned long)vif->rx_comms_area->addr, - GNTMAP_host_map, rx_ring_ref, vif->domid); - - if (HYPERVISOR_grant_table_op(GNTTABOP_map_grant_ref, &op, 1)) - BUG(); - - if (op.status) { - netdev_warn(vif->dev, - "failed to map rx ring. err=%d status=%d\n", - err, op.status); - err = op.status; + err = xenbus_map_ring_valloc(xenvif_to_xenbus_device(vif), + rx_ring_ref, &addr); + if (err) goto err; - } - - vif->rx_shmem_ref = rx_ring_ref; - vif->rx_shmem_handle = op.handle; - vif->rx_req_cons_peek = 0; - rxs = (struct xen_netif_rx_sring *)vif->rx_comms_area->addr; + rxs = (struct xen_netif_rx_sring *)addr; BACK_RING_INIT(&vif->rx, rxs, PAGE_SIZE); + vif->rx_req_cons_peek = 0; + return 0; err: -- 1.7.2.5 _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel From xen-devel-bounces@lists.xensource.com Fri Sep 23 11:00:18 2011 Return-path: <xen-devel-bounces@lists.xensource.com> Envelope-to: www-data@lists.xensource.com Delivery-date: Fri, 23 Sep 2011 11:00:18 -0700 Received: from localhost ([127.0.0.1] helo=lists.colo.xensource.com) by lists.xensource.com with esmtp (Exim 4.43) id 1R7A2r-0005cL-3S; Fri, 23 Sep 2011 11:00:17 -0700 Received: from mail216.messagelabs.com ([85.158.143.99]) by lists.xensource.com with esmtp (Exim 4.43) id 1R79w7-0003s7-Fm for xen-devel@lists.xensource.com; Fri, 23 Sep 2011 10:53:20 -0700 X-Env-Sender: david.vrabel@citrix.com X-Msg-Ref: server-15.tower-216.messagelabs.com!1316800390!18881727!3 X-Originating-IP: [66.165.176.89] X-StarScan-Version: 6.4.1; banners=-,-,- X-VirusChecked: Checked Received: (qmail 5002 invoked from network); 23 Sep 2011 17:53:16 -0000 Received: from smtp.citrix.com (HELO SMTP.CITRIX.COM) (66.165.176.89) by server-15.tower-216.messagelabs.com with RC4-SHA encrypted SMTP; 23 Sep 2011 17:53:16 -0000 X-IronPort-AV: E=Sophos;i="4.68,431,1312171200"; d="scan'208";a="17654506" Received: from ftlpmailmx02.citrite.net ([10.13.107.66]) by FTLPIPO01.CITRIX.COM with ESMTP/TLS/RC4-MD5; 23 Sep 2011 13:53:15 -0400 Received: from smtp01.ad.xensource.com (10.219.128.104) by smtprelay.citrix.com (10.13.107.66) with Microsoft SMTP Server id 8.3.137.0; Fri, 23 Sep 2011 13:53:15 -0400 Received: from qabil.uk.xensource.com (qabil.uk.xensource.com [10.80.2.76]) by smtp01.ad.xensource.com (8.13.1/8.13.1) with ESMTP id p8NHr6tp031719; Fri, 23 Sep 2011 10:53:13 -0700 From: David Vrabel <david.vrabel@citrix.com> To: xen-devel@lists.xensource.com Date: Fri, 23 Sep 2011 18:55:23 +0100 Message-ID: <1316800523-30144-5-git-send-email-david.vrabel@citrix.com> X-Mailer: git-send-email 1.7.2.5 In-Reply-To: <1316800523-30144-1-git-send-email-david.vrabel@citrix.com> References: <1316800523-30144-1-git-send-email-david.vrabel@citrix.com> MIME-Version: 1.0 Content-Type: text/plain Cc: Jeremy Fitzhardinge <jeremy@goop.org>, David Vrabel <david.vrabel@citrix.com>, Andrew Morton <akpm@linux-foundation.org>, Konrad Rzeszutek Wilk <konrad.wilk@oracle.com> Subject: [Xen-devel] [PATCH 4/4] xen: map foreign pages for shared rings by updating the PTEs directly X-BeenThere: xen-devel@lists.xensource.com X-Mailman-Version: 2.1.5 Precedence: list List-Id: Xen developer discussion <xen-devel.lists.xensource.com> List-Unsubscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe> List-Post: <mailto:xen-devel@lists.xensource.com> List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help> List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=subscribe> Sender: xen-devel-bounces@lists.xensource.com Errors-To: xen-devel-bounces@lists.xensource.com From: David Vrabel <david.vrabel@citrix.com> When mapping a foreign page with xenbus_map_ring_valloc() with the GNTTABOP_map_grant_ref hypercall, set the GNTMAP_contains_pte flag and pass a pointer to the PTE (in init_mm). After the page is mapped, the usual fault mechanism can be used to update additional MMs. This allows the vmalloc_sync_all() to be removed from alloc_vm_area(). Signed-off-by: David Vrabel <david.vrabel@citrix.com> Cc: Andrew Morton <akpm@linux-foundation.org> Cc: Jeremy Fitzhardinge <jeremy@goop.org> --- arch/x86/xen/grant-table.c | 2 +- drivers/xen/xenbus/xenbus_client.c | 11 ++++++++--- include/linux/vmalloc.h | 2 +- mm/vmalloc.c | 27 +++++++++++++-------------- 4 files changed, 23 insertions(+), 19 deletions(-) diff --git a/arch/x86/xen/grant-table.c b/arch/x86/xen/grant-table.c index 6bbfd7a..5a40d24 100644 --- a/arch/x86/xen/grant-table.c +++ b/arch/x86/xen/grant-table.c @@ -71,7 +71,7 @@ int arch_gnttab_map_shared(unsigned long *frames, unsigned long nr_gframes, if (shared == NULL) { struct vm_struct *area = - alloc_vm_area(PAGE_SIZE * max_nr_gframes); + alloc_vm_area(PAGE_SIZE * max_nr_gframes, NULL); BUG_ON(area == NULL); shared = area->addr; *__shared = shared; diff --git a/drivers/xen/xenbus/xenbus_client.c b/drivers/xen/xenbus/xenbus_client.c index 229d3ad..52bc57f 100644 --- a/drivers/xen/xenbus/xenbus_client.c +++ b/drivers/xen/xenbus/xenbus_client.c @@ -34,6 +34,7 @@ #include <linux/types.h> #include <linux/vmalloc.h> #include <asm/xen/hypervisor.h> +#include <asm/xen/page.h> #include <xen/interface/xen.h> #include <xen/interface/event_channel.h> #include <xen/events.h> @@ -435,19 +436,20 @@ EXPORT_SYMBOL_GPL(xenbus_free_evtchn); int xenbus_map_ring_valloc(struct xenbus_device *dev, int gnt_ref, void **vaddr) { struct gnttab_map_grant_ref op = { - .flags = GNTMAP_host_map, + .flags = GNTMAP_host_map | GNTMAP_contains_pte, .ref = gnt_ref, .dom = dev->otherend_id, }; struct vm_struct *area; + pte_t *pte; *vaddr = NULL; - area = alloc_vm_area(PAGE_SIZE); + area = alloc_vm_area(PAGE_SIZE, &pte); if (!area) return -ENOMEM; - op.host_addr = (unsigned long)area->addr; + op.host_addr = arbitrary_virt_to_machine(pte).maddr; if (HYPERVISOR_grant_table_op(GNTTABOP_map_grant_ref, &op, 1)) BUG(); @@ -526,6 +528,7 @@ int xenbus_unmap_ring_vfree(struct xenbus_device *dev, void *vaddr) struct gnttab_unmap_grant_ref op = { .host_addr = (unsigned long)vaddr, }; + unsigned int level; /* It'd be nice if linux/vmalloc.h provided a find_vm_area(void *addr) * method so that we don't have to muck with vmalloc internals here. @@ -547,6 +550,8 @@ int xenbus_unmap_ring_vfree(struct xenbus_device *dev, void *vaddr) } op.handle = (grant_handle_t)area->phys_addr; + op.host_addr = arbitrary_virt_to_machine( + lookup_address((unsigned long)vaddr, &level)).maddr; if (HYPERVISOR_grant_table_op(GNTTABOP_unmap_grant_ref, &op, 1)) BUG(); diff --git a/include/linux/vmalloc.h b/include/linux/vmalloc.h index 9332e52..1a77252 100644 --- a/include/linux/vmalloc.h +++ b/include/linux/vmalloc.h @@ -118,7 +118,7 @@ unmap_kernel_range(unsigned long addr, unsigned long size) #endif /* Allocate/destroy a 'vmalloc' VM area. */ -extern struct vm_struct *alloc_vm_area(size_t size); +extern struct vm_struct *alloc_vm_area(size_t size, pte_t **ptes); extern void free_vm_area(struct vm_struct *area); /* for /dev/kmem */ diff --git a/mm/vmalloc.c b/mm/vmalloc.c index 5016f19..b5deec6 100644 --- a/mm/vmalloc.c +++ b/mm/vmalloc.c @@ -2105,23 +2105,30 @@ void __attribute__((weak)) vmalloc_sync_all(void) static int f(pte_t *pte, pgtable_t table, unsigned long addr, void *data) { - /* apply_to_page_range() does all the hard work. */ + pte_t ***p = data; + + if (p) { + *(*p) = pte; + (*p)++; + } return 0; } /** * alloc_vm_area - allocate a range of kernel address space * @size: size of the area + * @ptes: returns the PTEs for the address space * * Returns: NULL on failure, vm_struct on success * * This function reserves a range of kernel address space, and * allocates pagetables to map that range. No actual mappings - * are created. If the kernel address space is not shared - * between processes, it syncs the pagetable across all - * processes. + * are created. + * + * If @ptes is non-NULL, pointers to the PTEs (in init_mm) + * allocated for the VM area are returned. */ -struct vm_struct *alloc_vm_area(size_t size) +struct vm_struct *alloc_vm_area(size_t size, pte_t **ptes) { struct vm_struct *area; @@ -2135,19 +2142,11 @@ struct vm_struct *alloc_vm_area(size_t size) * of kernel virtual address space and mapped into init_mm. */ if (apply_to_page_range(&init_mm, (unsigned long)area->addr, - area->size, f, NULL)) { + size, f, ptes ? &ptes : NULL)) { free_vm_area(area); return NULL; } - /* - * If the allocated address space is passed to a hypercall - * before being used then we cannot rely on a page fault to - * trigger an update of the page tables. So sync all the page - * tables here. - */ - vmalloc_sync_all(); - return area; } EXPORT_SYMBOL_GPL(alloc_vm_area); -- 1.7.2.5 _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel From xen-devel-bounces@lists.xensource.com Fri Sep 23 11:17:21 2011 Return-path: <xen-devel-bounces@lists.xensource.com> Envelope-to: www-data@lists.xensource.com Delivery-date: Fri, 23 Sep 2011 11:17:21 -0700 Received: from localhost ([127.0.0.1] helo=lists.colo.xensource.com) by lists.xensource.com with esmtp (Exim 4.43) id 1R7AJM-0006IS-Oa; Fri, 23 Sep 2011 11:17:20 -0700 Received: from mail182.messagelabs.com ([85.158.139.83]) by lists.xensource.com with esmtp (Exim 4.43) id 1R7AIE-00065d-EK for xen-devel@lists.xensource.com; Fri, 23 Sep 2011 11:16:10 -0700 X-Env-Sender: olaf@aepfle.de X-Msg-Ref: server-3.tower-182.messagelabs.com!1316801766!16728406!1 X-Originating-IP: [81.169.146.162] X-StarScan-Version: 6.4.1; banners=-,-,- X-VirusChecked: Checked Received: (qmail 22551 invoked from network); 23 Sep 2011 18:16:07 -0000 Received: from mo-p00-ob.rzone.de (HELO mo-p00-ob.rzone.de) (81.169.146.162) by server-3.tower-182.messagelabs.com with EDH-RSA-DES-CBC3-SHA encrypted SMTP; 23 Sep 2011 18:16:07 -0000 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; t=1316801766; l=438; s=domk; d=aepfle.de; h=In-Reply-To:Content-Transfer-Encoding:Content-Type:MIME-Version: References:Subject:Cc:To:From:Date:X-RZG-CLASS-ID:X-RZG-AUTH; bh=X5eQ/B6RjUu4t+12Kg8ED9+QvxY=; b=IE5R98Tj54XqZ6NitpUxiPXXVJahC6vu3Itr3R0QWK/b3PAU9vCOpVKRmsCrs04Wrqv j8gcvVM6qmrTUDuLhn8F6eQ3Ge1ZxvIRBxC5I0//pA+U6JXgk5c8KxkaT4JSE78yaUjFk 5MQGwpcvF3AHu9M5BFSwBoB4WzhkgPTO3is= X-RZG-AUTH: :P2EQZWCpfu+qG7CngxMFH1J+zrwiavkK6tmQaLfmwtM48/lq3s7jFtE= X-RZG-CLASS-ID: mo00 Received: from probook.site (dslb-084-057-077-084.pools.arcor-ip.net [84.57.77.84]) by smtp.strato.de (klopstock mo36) (RZmta 26.7) with (EDH-RSA-DES-CBC3-SHA encrypted) ESMTPA id x0065cn8NGXF7N ; Fri, 23 Sep 2011 20:15:43 +0200 (MEST) Received: by probook.site (Postfix, from userid 1000) id 43FFF18B65; Fri, 23 Sep 2011 20:15:43 +0200 (CEST) Date: Fri, 23 Sep 2011 20:15:43 +0200 From: Olaf Hering <olaf@aepfle.de> To: Aravindh Puthiyaparambil <aravindh@virtuata.com> Subject: Re: [Xen-devel] Differentiate between Xen versions at compile time Message-ID: <20110923181543.GA17550@aepfle.de> References: <CAB10MZBD-5M=wrkj6rsQxqdQn5E1UMA4j+C1EQq8Y-BjXZaRoA@mail.gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <CAB10MZBD-5M=wrkj6rsQxqdQn5E1UMA4j+C1EQq8Y-BjXZaRoA@mail.gmail.com> User-Agent: Mutt/1.5.21.rev5535 (2011-07-01) Cc: xen-devel@lists.xensource.com X-BeenThere: xen-devel@lists.xensource.com X-Mailman-Version: 2.1.5 Precedence: list List-Id: Xen developer discussion <xen-devel.lists.xensource.com> List-Unsubscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe> List-Post: <mailto:xen-devel@lists.xensource.com> List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help> List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=subscribe> Sender: xen-devel-bounces@lists.xensource.com Errors-To: xen-devel-bounces@lists.xensource.com On Fri, Sep 23, Aravindh Puthiyaparambil wrote: > The men_access interface has changed between 4.1 and unstable. Mainly > xc_mem_event_enable/disable() is now xc_mem_access_enable/disable(). > Is there a define to check against,  to pick up this difference during > compile time for a libxc app? Changeset 23842:483c5f8319ad removes XEN_DOMCTL_MEM_EVENT_OP_ENABLE, and XEN_DOMCTL_MEM_EVENT_OP_ACCESS_ENABLE was added. Olaf _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel From xen-devel-bounces@lists.xensource.com Fri Sep 23 11:36:23 2011 Return-path: <xen-devel-bounces@lists.xensource.com> Envelope-to: www-data@lists.xensource.com Delivery-date: Fri, 23 Sep 2011 11:36:23 -0700 Received: from localhost ([127.0.0.1] helo=lists.colo.xensource.com) by lists.xensource.com with esmtp (Exim 4.43) id 1R7Abl-0006xF-Kk; Fri, 23 Sep 2011 11:36:22 -0700 Received: from mail216.messagelabs.com ([85.158.143.99]) by lists.xensource.com with esmtp (Exim 4.43) id 1R7Ab8-0006kb-K0 for xen-devel@lists.xensource.com; Fri, 23 Sep 2011 11:35:43 -0700 X-Env-Sender: Ian.Jackson@eu.citrix.com X-Msg-Ref: server-9.tower-216.messagelabs.com!1316802939!19411576!1 X-Originating-IP: [62.200.22.115] X-StarScan-Version: 6.4.1; banners=-,-,- X-VirusChecked: Checked Received: (qmail 24666 invoked from network); 23 Sep 2011 18:35:39 -0000 Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115) by server-9.tower-216.messagelabs.com with RC4-SHA encrypted SMTP; 23 Sep 2011 18:35:39 -0000 X-IronPort-AV: E=Sophos;i="4.68,431,1312156800"; d="scan'208";a="8036645" Received: from lonpmailmx01.citrite.net ([10.30.203.162]) by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5; 23 Sep 2011 18:35:33 +0000 Received: from woking.xci-test.com (10.80.248.135) by smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id 8.3.137.0; Fri, 23 Sep 2011 19:35:33 +0100 Received: from osstest by woking.xci-test.com with local (Exim 4.69) (envelope-from <ian.jackson@eu.citrix.com>) id 1R7Aaz-0002KX-0f; Fri, 23 Sep 2011 19:35:33 +0100 To: <xen-devel@lists.xensource.com> Message-ID: <osstest-9056-mainreport@xen.org> From: xen.org <ian.jackson@eu.citrix.com> Date: Fri, 23 Sep 2011 19:35:33 +0100 MIME-Version: 1.0 Content-Type: text/plain Cc: ian.jackson@eu.citrix.com Subject: [Xen-devel] [linux test] 9056: tolerable FAIL X-BeenThere: xen-devel@lists.xensource.com X-Mailman-Version: 2.1.5 Precedence: list List-Id: Xen developer discussion <xen-devel.lists.xensource.com> List-Unsubscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe> List-Post: <mailto:xen-devel@lists.xensource.com> List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help> List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=subscribe> Sender: xen-devel-bounces@lists.xensource.com Errors-To: xen-devel-bounces@lists.xensource.com flight 9056 linux real [real] http://www.chiark.greenend.org.uk/~xensrcts/logs/9056/ Failures :-/ but no regressions. Tests which are failing intermittently (not blocking): test-amd64-amd64-xl-sedf 12 guest-saverestore.2 fail pass in 9044 Tests which did not succeed, but are not blocking, including regressions (tests previously passed) regarded as allowable: test-amd64-amd64-xl-pcipt-intel 9 guest-start fail never pass test-amd64-i386-rhel6hvm-amd 9 guest-start.2 fail never pass test-amd64-i386-rhel6hvm-intel 9 guest-start.2 fail never pass test-amd64-i386-win-vcpus1 16 leak-check/check fail never pass test-amd64-i386-xl-win-vcpus1 13 guest-stop fail never pass test-amd64-amd64-win 16 leak-check/check fail never pass test-amd64-amd64-xl-win 13 guest-stop fail never pass test-i386-i386-xl-win 13 guest-stop fail never pass test-i386-i386-win 16 leak-check/check fail never pass test-amd64-i386-win 16 leak-check/check fail never pass version targeted for testing: linux 6bec8b4a4c14095d0b7ce424db9d583c3decae6c baseline version: linux 1c3f03ccc5258887f5f2cafc0836a865834f9205 ------------------------------------------------------------ People who touched revisions under test: Jeremy Fitzhardinge <jeremy.fitzhardinge@citrix.com> ------------------------------------------------------------ jobs: build-amd64 pass build-i386 pass build-amd64-pvops pass build-i386-pvops pass test-amd64-amd64-xl pass test-amd64-i386-xl pass test-i386-i386-xl pass test-amd64-i386-rhel6hvm-amd fail test-amd64-i386-xl-credit2 pass test-amd64-amd64-xl-pcipt-intel fail test-amd64-i386-rhel6hvm-intel fail test-amd64-i386-xl-multivcpu pass test-amd64-amd64-pair pass test-amd64-i386-pair pass test-i386-i386-pair pass test-amd64-amd64-pv pass test-amd64-i386-pv pass test-i386-i386-pv pass test-amd64-amd64-xl-sedf fail test-amd64-i386-win-vcpus1 fail test-amd64-i386-xl-win-vcpus1 fail test-amd64-amd64-win fail test-amd64-i386-win fail test-i386-i386-win fail test-amd64-amd64-xl-win fail test-i386-i386-xl-win fail ------------------------------------------------------------ sg-report-flight on woking.cam.xci-test.com logs: /home/xc_osstest/logs images: /home/xc_osstest/images Logs, config files, etc. are available at http://www.chiark.greenend.org.uk/~xensrcts/logs Test harness code can be found at http://xenbits.xensource.com/gitweb?p=osstest.git;a=summary Pushing revision : + branch=linux + revision=6bec8b4a4c14095d0b7ce424db9d583c3decae6c + . cri-lock-repos ++ . cri-common +++ umask 002 +++ getconfig Repos +++ perl -e ' use Osstest; readconfigonly(); print $c{Repos} or die $!; ' ++ repos=/export/home/osstest/repos ++ repos_lock=/export/home/osstest/repos/lock ++ '[' x '!=' x/export/home/osstest/repos/lock ']' ++ OSSTEST_REPOS_LOCK_LOCKED=/export/home/osstest/repos/lock ++ exec with-lock-ex -w /export/home/osstest/repos/lock ./ap-push linux 6bec8b4a4c14095d0b7ce424db9d583c3decae6c + branch=linux + revision=6bec8b4a4c14095d0b7ce424db9d583c3decae6c + . cri-lock-repos ++ . cri-common +++ umask 002 +++ getconfig Repos +++ perl -e ' use Osstest; readconfigonly(); print $c{Repos} or die $!; ' ++ repos=/export/home/osstest/repos ++ repos_lock=/export/home/osstest/repos/lock ++ '[' x/export/home/osstest/repos/lock '!=' x/export/home/osstest/repos/lock ']' + : xen@xenbits.xensource.com + : xen@xenbits.xensource.com:git/linux-pvops + : master + : tested/2.6.39.x + case "$branch" in + cd /export/home/osstest/repos/xen ./ap-push: line 20: cd: /export/home/osstest/repos/xen: No such file or directory ------------------------------------------------------------ commit 6bec8b4a4c14095d0b7ce424db9d583c3decae6c Author: Jeremy Fitzhardinge <jeremy.fitzhardinge@citrix.com> Date: Fri Sep 2 12:23:22 2011 -0700 Revert "xen/apic: Provide an 'apic_xen' to set the override the apic->[read|write] for all cases." This reverts commit c3dd7941354fa96a71f2613e2c7a1b215fa175dc. It prevents the kernel from booting natively on hardware. Conflicts: arch/x86/xen/enlighten.c Signed-off-by: Jeremy Fitzhardinge <jeremy.fitzhardinge@citrix.com> _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel From xen-devel-bounces@lists.xensource.com Fri Sep 23 11:54:37 2011 Return-path: <xen-devel-bounces@lists.xensource.com> Envelope-to: www-data@lists.xensource.com Delivery-date: Fri, 23 Sep 2011 11:54:37 -0700 Received: from localhost ([127.0.0.1] helo=lists.colo.xensource.com) by lists.xensource.com with esmtp (Exim 4.43) id 1R7AtR-0007oI-JI; Fri, 23 Sep 2011 11:54:37 -0700 Received: from mail21.messagelabs.com ([85.158.143.35]) by lists.xensource.com with esmtp (Exim 4.43) id 1R7Asg-0007bY-4G for xen-devel@lists.xensource.com; Fri, 23 Sep 2011 11:53:50 -0700 X-Env-Sender: aravindh@virtuata.com X-Msg-Ref: server-11.tower-21.messagelabs.com!1316804008!43753679!1 X-Originating-IP: [209.85.218.43] X-StarScan-Version: 6.4.1; banners=-,-,- X-VirusChecked: Checked Received: (qmail 12106 invoked from network); 23 Sep 2011 18:53:29 -0000 Received: from mail-yi0-f43.google.com (HELO mail-yi0-f43.google.com) (209.85.218.43) by server-11.tower-21.messagelabs.com with RC4-SHA encrypted SMTP; 23 Sep 2011 18:53:29 -0000 Received: by yib17 with SMTP id 17so4347986yib.30 for <xen-devel@lists.xensource.com>; Fri, 23 Sep 2011 11:53:45 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=virtuata.com; s=google; h=mime-version:x-originating-ip:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=XG7DLXjF+IJiQil4hr4Z0fG8q5ROiLEhOpnowZ+xTTo=; b=T52FZyUMZUFp0P3Et5ZiyZCy5Cf830gLFnFdw7q+P1pZfehFRN8FXYuHkBPl7gAe3j 7a4tl7/YUaXuY/td2NgYBnUd43ocJprRQ3bG+YM8go2WcCqRK4WY9ind+K24VwECc82d ln+o0/uQ7SE2jbI6UAAvymTHEwNOdKKVUSJ0k= MIME-Version: 1.0 Received: by 10.68.34.138 with SMTP id z10mr11624477pbi.105.1316804025343; Fri, 23 Sep 2011 11:53:45 -0700 (PDT) Received: by 10.142.221.13 with HTTP; Fri, 23 Sep 2011 11:53:44 -0700 (PDT) X-Originating-IP: [174.253.240.25] Received: by 10.142.221.13 with HTTP; Fri, 23 Sep 2011 11:53:44 -0700 (PDT) In-Reply-To: <20110923181543.GA17550@aepfle.de> References: <CAB10MZBD-5M=wrkj6rsQxqdQn5E1UMA4j+C1EQq8Y-BjXZaRoA@mail.gmail.com> <20110923181543.GA17550@aepfle.de> Date: Fri, 23 Sep 2011 11:53:44 -0700 Message-ID: <CAB10MZACKASNo2F1FoA38mRPO7_Qz4q-aWDsTigs2DATQp9KgA@mail.gmail.com> Subject: Re: [Xen-devel] Differentiate between Xen versions at compile time From: Aravindh Puthiyaparambil <aravindh@virtuata.com> To: Olaf Hering <olaf@aepfle.de> Cc: xen-devel@lists.xensource.com X-BeenThere: xen-devel@lists.xensource.com X-Mailman-Version: 2.1.5 Precedence: list List-Id: Xen developer discussion <xen-devel.lists.xensource.com> List-Unsubscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe> List-Post: <mailto:xen-devel@lists.xensource.com> List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help> List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=subscribe> Content-Type: multipart/mixed; boundary="===============2132998264==" Sender: xen-devel-bounces@lists.xensource.com Errors-To: xen-devel-bounces@lists.xensource.com --===============2132998264== Content-Type: multipart/alternative; boundary=bcaec52163032b5f8204ada05403 --bcaec52163032b5f8204ada05403 Content-Type: text/plain; charset=ISO-8859-1 On Sep 23, 2011 11:16 AM, "Olaf Hering" <olaf@aepfle.de> wrote: > > On Fri, Sep 23, Aravindh Puthiyaparambil wrote: > > > The men_access interface has changed between 4.1 and unstable. Mainly > > xc_mem_event_enable/disable() is now xc_mem_access_enable/disable(). > > Is there a define to check against, to pick up this difference during > > compile time for a libxc app? > > Changeset 23842:483c5f8319ad removes XEN_DOMCTL_MEM_EVENT_OP_ENABLE, and > XEN_DOMCTL_MEM_EVENT_OP_ACCESS_ENABLE was added. Thanks. I will check for that. Aravindh --bcaec52163032b5f8204ada05403 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable <p><br> On Sep 23, 2011 11:16 AM, "Olaf Hering" <<a href=3D"mailto:ola= f@aepfle.de">olaf@aepfle.de</a>> wrote:<br> ><br> > On Fri, Sep 23, Aravindh Puthiyaparambil wrote:<br> ><br> > > The men_access interface has changed between 4.1 and unstable. Ma= inly<br> > > xc_mem_event_enable/disable() is now xc_mem_access_enable/disable= ().<br> > > Is there a define to check against,=A0 to pick up this difference= during<br> > > compile time for a libxc app?<br> ><br> > Changeset 23842:483c5f8319ad removes XEN_DOMCTL_MEM_EVENT_OP_ENABLE, a= nd<br> > XEN_DOMCTL_MEM_EVENT_OP_ACCESS_ENABLE was added.</p> <p>Thanks. I will check for that.<br> Aravindh</p> --bcaec52163032b5f8204ada05403-- --===============2132998264== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel --===============2132998264==-- From xen-devel-bounces@lists.xensource.com Fri Sep 23 12:28:09 2011 Return-path: <xen-devel-bounces@lists.xensource.com> Envelope-to: www-data@lists.xensource.com Delivery-date: Fri, 23 Sep 2011 12:28:09 -0700 Received: from localhost ([127.0.0.1] helo=lists.colo.xensource.com) by lists.xensource.com with esmtp (Exim 4.43) id 1R7BPs-0000YF-RF; Fri, 23 Sep 2011 12:28:08 -0700 Received: from mail216.messagelabs.com ([85.158.143.99]) by lists.xensource.com with esmtp (Exim 4.43) id 1R7BP7-0000LF-Nj for xen-devel@lists.xensource.com; Fri, 23 Sep 2011 12:27:22 -0700 X-Env-Sender: dan.magenheimer@oracle.com X-Msg-Ref: server-13.tower-216.messagelabs.com!1316806037!19410862!1 X-Originating-IP: [148.87.113.117] X-StarScan-Version: 6.4.1; banners=-,-,- X-VirusChecked: Checked Received: (qmail 18982 invoked from network); 23 Sep 2011 19:27:18 -0000 Received: from rcsinet15.oracle.com (HELO rcsinet15.oracle.com) (148.87.113.117) by server-13.tower-216.messagelabs.com with DHE-RSA-AES256-SHA encrypted SMTP; 23 Sep 2011 19:27:18 -0000 Received: from acsinet22.oracle.com (acsinet22.oracle.com [141.146.126.238]) by rcsinet15.oracle.com (Switch-3.4.4/Switch-3.4.4) with ESMTP id p8NJR74c008232 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Fri, 23 Sep 2011 19:27:13 GMT Received: from acsmt358.oracle.com (acsmt358.oracle.com [141.146.40.158]) by acsinet22.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id p8NJ5Hub028158 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 23 Sep 2011 19:05:20 GMT Received: from abhmt118.oracle.com (abhmt118.oracle.com [141.146.116.70]) by acsmt358.oracle.com (8.12.11.20060308/8.12.11) with ESMTP id p8NJ5Aum016248; Fri, 23 Sep 2011 14:05:10 -0500 MIME-Version: 1.0 Message-ID: <cf440447-8773-4302-808e-dccb92a033f1@default> Date: Fri, 23 Sep 2011 12:04:51 -0700 (PDT) From: Dan Magenheimer <dan.magenheimer@oracle.com> To: David Vrabel <david.vrabel@citrix.com> Subject: RE: [Xen-devel] xen: memory initialization/balloon fixes (#3) References: <1316089768-22461-1-git-send-email-david.vrabel@citrix.com> <63997331-e53b-48e5-bf7c-87141aae49d6@default> <4E7B2ADA.7000605@citrix.com> <df22e0b8-15d8-4cb1-a9d9-d3565aa5f9b7@default> <8af71cad-415d-42d4-8a2e-e4efd7e36fd4@default> <4E7BBC00.1050602@goop.org> <005ea591-cfb5-4ca0-9c9c-df2bbae88172@default 4E7C6344.3000401@citrix.com> In-Reply-To: <4E7C6344.3000401@citrix.com> X-Priority: 3 X-Mailer: Oracle Beehive Extensions for Outlook 2.0.1.4.1.0 (410211) [OL 12.0.6557.5001] Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable X-Source-IP: acsinet22.oracle.com [141.146.126.238] X-Auth-Type: Internal IP X-CT-RefId: str=0001.0A090207.4E7CDD92.009F:SCFMA922111,ss=1,re=-4.000,fgs=0 Cc: Jeremy Fitzhardinge <jeremy@goop.org>, xen-devel@lists.xensource.com, JBeulich@novell.com, Konrad Wilk <konrad.wilk@oracle.com> X-BeenThere: xen-devel@lists.xensource.com X-Mailman-Version: 2.1.5 Precedence: list List-Id: Xen developer discussion <xen-devel.lists.xensource.com> List-Unsubscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe> List-Post: <mailto:xen-devel@lists.xensource.com> List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help> List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=subscribe> Sender: xen-devel-bounces@lists.xensource.com Errors-To: xen-devel-bounces@lists.xensource.com > From: David Vrabel [mailto:david.vrabel@citrix.com] > Subject: Re: [Xen-devel] xen: memory initialization/balloon fixes (#3) >=20 > On 23/09/11 00:46, Dan Magenheimer wrote: > >> From: Jeremy Fitzhardinge [mailto:jeremy@goop.org] > >> > >> I don't think the Xen parts allocate/reserves lots of memory > >> unnecessarily, so it shouldn't be too different from the 2.6.18-xen > >> kernels. They do reserve various chunks of memory, but for things lik= e > >> RAMDISK I think they get released again (and anyway, I don't think > >> that's going to be anywhere near 30MB, let alone 60). I'm not very > >> confident in those /proc/meminfo numbers - they may count memory as > >> "reserved" if its in a reserved region even if the pages themselves ha= ve > >> been released to the kernel pool. > > > > No, the first line of /proc/meminfo is precisely "totalram_pages". >=20 > I think most of the increase in reserved memory compared to classic Xen > kernels is the change to using the generic SWIOTLB. This is up to 64 MiB= . Hi David -- My data agrees with Konrad's reply. I don't see the SWIOTLB but am only testing with smaller guests (<2GB). > >>>>> Again, this looks like the correct behavior to me. > >>>> Hmmm... so if a user (or automated tool) uses the Xen-defined > >>>> API (i.e. /sys/devices/system/xen_memory/xen_memory0/target_kb) > >>>> to use the Xen balloon driver to attempt to reduce memory usage > >>>> to 100MB, and the Xen balloon driver instead reduces it to > >>>> some random number somewhere between 40MB and 90MB, which > >>>> may or may not cause OOMs, you consider this correct behavior? > >>> I still think this is a bug but apparently orthogonal to > >>> your patchset. So sorry to bother you. > >> > >> If you ask for 100MB, it should never try to make the domain smaller > >> than that; if it does, it suggests the number is being misparsed or > >> something. (Jeremy -- No it's not getting mis-parsed... in the existing balloon code the try-to-balloon-to-target-N code is instead ballooning to N-D, where D is "reserved_pages+absent_pages"... and as you pointed out, this sum gets modified after the balloon is initialized.) > > OK then balloon_stats.current_pages can never be larger than totalram_p= ages. > > Which means that balloon_stats.current_pages must always grow > > and shrink when totalram_pages does (which is true now only in > > the balloon driver code). Which means, I think: > > > > balloon_stats.current_pages is just plain wrong! It doesn't need to > > exist! If we replace every instance in balloon.c with totalram_pages, > > I think everything just works. Will run some tests tomorrow. >=20 > No. balloon_stats.current_pages is the amount of pages used by the > domain from Xen's point of view (and must be equal to the amount report > by xl top). It is not what the guest kernel thinks is the number of > usable pages. OK. It still appears to be not always accurate to me. Are you using balloon_stats.current_pages via sysfs? AFAICT, the interface used to get the amount of domain memory (e.g. for xl top) does not use balloon_stats.current_pages, so the only way it would be visible outside of the balloon driver is via sysfs. I suppose that is part of the guest ABI now, even if it contains an unreliable value. In any case, I can leave balloon_stats.current_pages alone in my patch-under-development. It is "just plain wrong" for my purposes and for setting a balloon target, and I think still wrong for the purpose you state, but I think I can leave unmodified the code that updates it so as not to affect code that uses it via sysfs. > Because totalram_pages doesn't include some reserved pages > balloon_stats.current_pages will necessarily always be greater. Yep. > If you're attempting to make the domain self-balloon I don't see why > you're even interested in the total number of pages. Surely it's the > number of free pages that's useful? No, after the kernel has been busy awhile, the number of free pages can be quite small, because most of RAM gets used in the page cache. Self-ballooning (as used with tmem) is much more aggressive than that because part of the purpose of tmem is to act as an all-domain page cache. If you're not familiar with tmem, see http://oss.oracle.com/projects/tmem. Thanks again for the feedback. I'll cc you on my upcoming patch. Dan _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel From xen-devel-bounces@lists.xensource.com Fri Sep 23 13:13:02 2011 Return-path: <xen-devel-bounces@lists.xensource.com> Envelope-to: www-data@lists.xensource.com Delivery-date: Fri, 23 Sep 2011 13:13:02 -0700 Received: from localhost ([127.0.0.1] helo=lists.colo.xensource.com) by lists.xensource.com with esmtp (Exim 4.43) id 1R7C7K-0001p2-I5; Fri, 23 Sep 2011 13:13:02 -0700 Received: from mail174.messagelabs.com ([85.158.138.51]) by lists.xensource.com with esmtp (Exim 4.43) id 1R7C6A-0001bl-Bb for xen-devel@lists.xensource.com; Fri, 23 Sep 2011 13:11:58 -0700 X-Env-Sender: Ian.Jackson@eu.citrix.com X-Msg-Ref: server-4.tower-174.messagelabs.com!1316808707!32567957!1 X-Originating-IP: [62.200.22.115] X-StarScan-Version: 6.4.1; banners=-,-,- X-VirusChecked: Checked Received: (qmail 14500 invoked from network); 23 Sep 2011 20:11:47 -0000 Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115) by server-4.tower-174.messagelabs.com with RC4-SHA encrypted SMTP; 23 Sep 2011 20:11:47 -0000 X-IronPort-AV: E=Sophos;i="4.68,432,1312156800"; d="scan'208";a="8037309" Received: from lonpmailmx01.citrite.net ([10.30.203.162]) by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5; 23 Sep 2011 20:11:46 +0000 Received: from woking.xci-test.com (10.80.248.135) by smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id 8.3.137.0; Fri, 23 Sep 2011 21:11:46 +0100 Received: from osstest by woking.xci-test.com with local (Exim 4.69) (envelope-from <ian.jackson@eu.citrix.com>) id 1R7C66-0003s8-4N; Fri, 23 Sep 2011 21:11:46 +0100 To: <xen-devel@lists.xensource.com> Message-ID: <osstest-9059-mainreport@xen.org> From: xen.org <ian.jackson@eu.citrix.com> Date: Fri, 23 Sep 2011 21:11:46 +0100 MIME-Version: 1.0 Content-Type: text/plain Cc: ian.jackson@eu.citrix.com Subject: [Xen-devel] [xen-unstable test] 9059: regressions - FAIL X-BeenThere: xen-devel@lists.xensource.com X-Mailman-Version: 2.1.5 Precedence: list List-Id: Xen developer discussion <xen-devel.lists.xensource.com> List-Unsubscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe> List-Post: <mailto:xen-devel@lists.xensource.com> List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help> List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=subscribe> Sender: xen-devel-bounces@lists.xensource.com Errors-To: xen-devel-bounces@lists.xensource.com flight 9059 xen-unstable real [real] http://www.chiark.greenend.org.uk/~xensrcts/logs/9059/ Regressions :-( Tests which did not succeed and are blocking: test-amd64-i386-rhel6hvm-amd 5 xen-boot fail REGR. vs. 8995 Tests which are failing intermittently (not blocking): test-amd64-i386-pv 5 xen-boot fail pass in 9054 test-amd64-amd64-xl-sedf 5 xen-boot fail pass in 9043 test-amd64-i386-xl-credit2 5 xen-boot fail pass in 9054 test-amd64-i386-xl 5 xen-boot fail pass in 9043 test-amd64-i386-xl-win-vcpus1 5 xen-boot fail pass in 9043 test-i386-i386-xl-win 5 xen-boot fail pass in 9054 test-amd64-i386-pair 7 xen-boot/src_host fail pass in 9054 test-amd64-i386-pair 8 xen-boot/dst_host fail pass in 9054 test-amd64-amd64-pv 5 xen-boot fail in 9054 pass in 9059 test-i386-i386-xl 5 xen-boot fail in 9054 pass in 9059 test-i386-i386-win 5 xen-boot fail in 9054 pass in 9059 test-amd64-amd64-pair 7 xen-boot/src_host fail in 9054 pass in 9059 test-amd64-amd64-pair 8 xen-boot/dst_host fail in 9054 pass in 9059 test-amd64-i386-xl-multivcpu 5 xen-boot fail in 9043 pass in 9059 test-amd64-amd64-win 5 xen-boot fail in 9043 pass in 9059 test-amd64-i386-win-vcpus1 5 xen-boot fail in 9043 pass in 9059 test-amd64-i386-win 5 xen-boot fail in 9043 pass in 9059 test-amd64-amd64-xl-win 5 xen-boot fail in 9043 pass in 9059 Tests which did not succeed, but are not blocking, including regressions (tests previously passed) regarded as allowable: test-amd64-amd64-xl-pcipt-intel 9 guest-start fail never pass test-amd64-i386-rhel6hvm-intel 9 guest-start.2 fail never pass test-i386-i386-win 16 leak-check/check fail never pass test-amd64-amd64-win 16 leak-check/check fail never pass test-amd64-i386-win-vcpus1 16 leak-check/check fail never pass test-amd64-i386-win 16 leak-check/check fail never pass test-amd64-amd64-xl-win 13 guest-stop fail never pass test-i386-i386-xl-win 13 guest-stop fail in 9054 never pass test-amd64-amd64-xl-sedf 14 guest-localmigrate/x10 fail in 9043 like 8995 test-amd64-i386-xl-win-vcpus1 13 guest-stop fail in 9043 never pass version targeted for testing: xen cc339ab1d917 baseline version: xen a422e2a4451e ------------------------------------------------------------ People who touched revisions under test: Andreas Herrmann <herrmann.der.user@googlemail.com> Ian Campbell <ian.campbell@citrix.com> Ian Jackson <ian.jackson@eu.citrix.com> Jan Beulich <jbeulich@suse.com> Lasse Collin <lasse.collin@tukaani.org> Olaf Hering <olaf@aepfle.de> Thomas Renninger <trenn@suse.de> ------------------------------------------------------------ jobs: build-amd64 pass build-i386 pass build-amd64-oldkern pass build-i386-oldkern pass build-amd64-pvops pass build-i386-pvops pass test-amd64-amd64-xl pass test-amd64-i386-xl fail test-i386-i386-xl pass test-amd64-i386-rhel6hvm-amd fail test-amd64-i386-xl-credit2 fail test-amd64-amd64-xl-pcipt-intel fail test-amd64-i386-rhel6hvm-intel fail test-amd64-i386-xl-multivcpu pass test-amd64-amd64-pair pass test-amd64-i386-pair fail test-i386-i386-pair pass test-amd64-amd64-pv pass test-amd64-i386-pv fail test-i386-i386-pv pass test-amd64-amd64-xl-sedf fail test-amd64-i386-win-vcpus1 fail test-amd64-i386-xl-win-vcpus1 fail test-amd64-amd64-win fail test-amd64-i386-win fail test-i386-i386-win fail test-amd64-amd64-xl-win fail test-i386-i386-xl-win fail ------------------------------------------------------------ sg-report-flight on woking.cam.xci-test.com logs: /home/xc_osstest/logs images: /home/xc_osstest/images Logs, config files, etc. are available at http://www.chiark.greenend.org.uk/~xensrcts/logs Test harness code can be found at http://xenbits.xensource.com/gitweb?p=osstest.git;a=summary Not pushing. ------------------------------------------------------------ changeset: 23872:cc339ab1d917 tag: tip user: Ian Campbell <ian.campbell@citrix.com> date: Thu Sep 22 18:37:06 2011 +0100 tools: fix install of lomount $(BIN) went away in 23124:e3d4c34b14a3. Also there are no *.so, *.a or *.rpm built in here Signed-off-by: Ian Campbell <ian.campbell@citrix.com> changeset: 23871:503ee256fecf user: Jan Beulich <jbeulich@suse.com> date: Thu Sep 22 18:35:30 2011 +0100 x86: ucode-amd: Don't warn when no ucode is available for a CPU revision This patch originally comes from the Linus mainline kernel (2.6.33), find below the patch details: From: Andreas Herrmann <herrmann.der.user@googlemail.com> There is no point in warning when there is no ucode available for a specific CPU revision. Currently the container-file, which provides the AMD ucode patches for OS load, contains only a few ucode patches. It's already clearly indicated by the printed patch_level whenever new ucode was available and an update happened. So the warning message is of no help but rather annoying on systems with many CPUs. Signed-off-by: Thomas Renninger <trenn@suse.de> Signed-off-by: Jan Beulich <jbeulich@suse.com> changeset: 23870:5c97b02f48fc user: Jan Beulich <jbeulich@suse.com> date: Thu Sep 22 18:34:27 2011 +0100 XZ: Fix incorrect XZ_BUF_ERROR From: Lasse Collin <lasse.collin@tukaani.org> xz_dec_run() could incorrectly return XZ_BUF_ERROR if all of the following was true: - The caller knows how many bytes of output to expect and only provides that much output space. - When the last output bytes are decoded, the caller-provided input buffer ends right before the LZMA2 end of payload marker. So LZMA2 won't provide more output anymore, but it won't know it yet and thus won't return XZ_STREAM_END yet. - A BCJ filter is in use and it hasn't left any unfiltered bytes in the temp buffer. This can happen with any BCJ filter, but in practice it's more likely with filters other than the x86 BCJ. This fixes <https://bugzilla.redhat.com/show_bug.cgi?id=3D735408> where Squashfs thinks that a valid file system is corrupt. This also fixes a similar bug in single-call mode where the uncompressed size of a block using BCJ + LZMA2 was 0 bytes and caller provided no output space. Many empty .xz files don't contain any blocks and thus don't trigger this bug. This also tweaks a closely related detail: xz_dec_bcj_run() could call xz_dec_lzma2_run() to decode into temp buffer when it was known to be useless. This was harmless although it wasted a minuscule number of CPU cycles. Signed-off-by: Lasse Collin <lasse.collin@tukaani.org> Signed-off-by: Jan Beulich <jbeulich@suse.com> changeset: 23869:db1ea4b127cd user: Jan Beulich <jbeulich@suse.com> date: Thu Sep 22 18:33:48 2011 +0100 XZ decompressor: Fix decoding of empty LZMA2 streams From: Lasse Collin <lasse.collin@tukaani.org> The old code considered valid empty LZMA2 streams to be corrupt. Note that a typical empty .xz file has no LZMA2 data at all, and thus most .xz files having no uncompressed data are handled correctly even without this fix. Signed-off-by: Lasse Collin <lasse.collin@tukaani.org> Signed-off-by: Jan Beulich <jbeulich@suse.com> changeset: 23868:28147fd781af user: Jan Beulich <jbeulich@suse.com> date: Thu Sep 22 18:32:34 2011 +0100 VT-d: fix off-by-one error in RMRR validation (base_addr,end_addr) is an inclusive range, and hence there shouldn't be a subtraction of 1 in the second invocation of page_is_ram_type(). For RMRRs covering a single page that actually resulted in the immediately preceding page to get checked (which could have resulted in a false warning). Signed-off-by: Jan Beulich <jbeulich@suse.com> changeset: 23867:571b6e90dfb4 user: Jan Beulich <jbeulich@suse.com> date: Thu Sep 22 18:31:44 2011 +0100 VT-d: eliminate a mis-use of pcidevs_lock dma_pte_clear_one() shouldn't acquire this global lock for the purpose of processing a per-domain list. Furthermore the function a few lines earlier has a comment stating that acquiring pcidevs_lock isn't necessary here (whether that's really correct is another question). Use the domain's mappin_lock instead to protect the mapped_rmrrs list. Fold domain_rmrr_mapped() into its sole caller so that the otherwise implicit dependency on pcidevs_lock there becomes more obvious (see the comment there). Signed-off-by: Jan Beulich <jbeulich@suse.com> changeset: 23866:47ec1d405af9 user: Jan Beulich <jbeulich@suse.com> date: Thu Sep 22 18:31:02 2011 +0100 x86: IO-APIC code has no dependency on PCI The IRQ handling code requires pcidevs_lock to be held only for MSI interrupts. As the handling of which was now fully moved into msi.c (i.e. while applying fine without, the patch needs to be applied after the one titled "x86: split MSI IRQ chip"), io_apic.c now also doesn't need to include PCI headers anymore. Signed-off-by: Jan Beulich <jbeulich@suse.com> changeset: 23865:d6e01c7853cf user: Jan Beulich <jbeulich@suse.com> date: Thu Sep 22 18:29:19 2011 +0100 PCI multi-seg: config space accessor adjustments Signed-off-by: Jan Beulich <jbeulich@suse.com> changeset: 23864:314b147d524d user: Jan Beulich <jbeulich@suse.com> date: Thu Sep 22 18:28:38 2011 +0100 PCI multi-seg: Pass-through adjustments Signed-off-by: Jan Beulich <jbeulich@suse.com> changeset: 23863:9e0259239822 user: Jan Beulich <jbeulich@suse.com> date: Thu Sep 22 18:28:03 2011 +0100 PCI multi-seg: AMD-IOMMU specific adjustments There are two places here where it is entirely unclear to me where the necessary PCI segment number should be taken from (as IVMD descriptors don't have such, only IVHD ones do). AMD confirmed that for the time being it is acceptable to imply that only segment 0 exists. Signed-off-by: Jan Beulich <jbeulich@suse.com> changeset: 23862:85418e168527 user: Jan Beulich <jbeulich@suse.com> date: Thu Sep 22 18:27:26 2011 +0100 PCI multi-seg: VT-d specific adjustments Signed-off-by: Jan Beulich <jbeulich@suse.com> changeset: 23861:ec7c81fbe0de user: Jan Beulich <jbeulich@suse.com> date: Thu Sep 22 18:26:54 2011 +0100 PCI multi-seg: adjust domctl interface Again, a couple of directly related functions at once get adjusted to account for the segment number. Signed-off-by: Jan Beulich <jbeulich@suse.com> changeset: 23860:a422e2a4451e user: Jan Beulich <jbeulich@suse.com> date: Sun Sep 18 00:26:52 2011 +0100 x86: split MSI IRQ chip With the .end() accessor having become optional and noting that several of the accessors' behavior really depends on the result of msi_maskable_irq(), the splits the MSI IRQ chip type into two - one for the maskable ones, and the other for the (MSI only) non-maskable ones. At once the implementation of those methods gets moved from io_apic.c to msi.c. Signed-off-by: Jan Beulich <jbeulich@suse.com> ======================================== commit cd776ee9408ff127f934a707c1a339ee600bc127 Author: Ian Jackson <ian.jackson@eu.citrix.com> Date: Tue Jun 28 13:50:53 2011 +0100 qemu-char.c: fix incorrect CONFIG_STUBDOM handling qemu-char.c:1123:7: warning: "CONFIG_STUBDOM" is not defined [-Wundef] Signed-off-by: Olaf Hering <olaf@aepfle.de> Acked-by: Ian Jackson <ian.jackson@eu.citrix.com> _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel From xen-devel-bounces@lists.xensource.com Fri Sep 23 13:32:51 2011 Return-path: <xen-devel-bounces@lists.xensource.com> Envelope-to: www-data@lists.xensource.com Delivery-date: Fri, 23 Sep 2011 13:32:51 -0700 Received: from localhost ([127.0.0.1] helo=lists.colo.xensource.com) by lists.xensource.com with esmtp (Exim 4.43) id 1R7CQU-0002Yq-SG; Fri, 23 Sep 2011 13:32:50 -0700 Received: from mail21.messagelabs.com ([85.158.143.35]) by lists.xensource.com with esmtp (Exim 4.43) id 1R7CPk-0002Mx-Mx for xen-devel@lists.xensource.com; Fri, 23 Sep 2011 13:32:05 -0700 X-Env-Sender: konrad@oracle.com X-Msg-Ref: server-9.tower-21.messagelabs.com!1316809875!49584468!1 X-Originating-IP: [141.146.126.227] X-StarScan-Version: 6.4.1; banners=-,-,- X-VirusChecked: Checked Received: (qmail 1055 invoked from network); 23 Sep 2011 20:31:16 -0000 Received: from acsinet15.oracle.com (HELO acsinet15.oracle.com) (141.146.126.227) by server-9.tower-21.messagelabs.com with DHE-RSA-AES256-SHA encrypted SMTP; 23 Sep 2011 20:31:16 -0000 Received: from rtcsinet22.oracle.com (rtcsinet22.oracle.com [66.248.204.30]) by acsinet15.oracle.com (Switch-3.4.4/Switch-3.4.4) with ESMTP id p8NKVpol014598 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Fri, 23 Sep 2011 20:31:53 GMT Received: from acsmt356.oracle.com (acsmt356.oracle.com [141.146.40.156]) by rtcsinet22.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id p8NKVnch002347 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 23 Sep 2011 20:31:50 GMT Received: from abhmt103.oracle.com (abhmt103.oracle.com [141.146.116.55]) by acsmt356.oracle.com (8.12.11.20060308/8.12.11) with ESMTP id p8NKViDE016011; Fri, 23 Sep 2011 15:31:44 -0500 Received: from oracle.com (/209.6.55.207) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Fri, 23 Sep 2011 13:31:44 -0700 Received: by oracle.com (Postfix, from userid 1000) id 32BA41591; Fri, 23 Sep 2011 16:31:49 -0400 (EDT) Date: Fri, 23 Sep 2011 16:31:49 -0400 From: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com> To: Daniel Castro <evil.dani@gmail.com> Subject: Re: [Xen-devel] Question on Xenstore watch Message-ID: <20110923203148.GA24199@phenom.oracle.com> References: <CAP2B858p3EDUykcM3RNpfU+9WGMHKL1bi+xdrwupMDuA+RvTZQ@mail.gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <CAP2B858p3EDUykcM3RNpfU+9WGMHKL1bi+xdrwupMDuA+RvTZQ@mail.gmail.com> User-Agent: Mutt/1.5.21 (2010-09-15) X-Source-IP: rtcsinet22.oracle.com [66.248.204.30] X-CT-RefId: str=0001.0A090208.4E7CECBE.0015,ss=1,re=0.000,fgs=0 Cc: xen-devel@lists.xensource.com X-BeenThere: xen-devel@lists.xensource.com X-Mailman-Version: 2.1.5 Precedence: list List-Id: Xen developer discussion <xen-devel.lists.xensource.com> List-Unsubscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe> List-Post: <mailto:xen-devel@lists.xensource.com> List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help> List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=subscribe> Sender: xen-devel-bounces@lists.xensource.com Errors-To: xen-devel-bounces@lists.xensource.com On Sat, Sep 24, 2011 at 12:31:21AM +0900, Daniel Castro wrote: > Hello All, > > I am trying to set up a watch on xentore. According to the > documentation xenstore.txt a watch is simply done with the path to the > node that the path is going to set, but according to the definitive > guide to xen, it is done like a write, path to node and key to be > watched. I have tried both and both fail. Probably I have something xs_watch(fd, "/local/domain/23/console/vnc-port","5001"); ? _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel From xen-devel-bounces@lists.xensource.com Fri Sep 23 13:58:34 2011 Return-path: <xen-devel-bounces@lists.xensource.com> Envelope-to: www-data@lists.xensource.com Delivery-date: Fri, 23 Sep 2011 13:58:34 -0700 Received: from localhost ([127.0.0.1] helo=lists.colo.xensource.com) by lists.xensource.com with esmtp (Exim 4.43) id 1R7CpO-0003WV-Oy; Fri, 23 Sep 2011 13:58:34 -0700 Received: from mail174.messagelabs.com ([85.158.138.51]) by lists.xensource.com with smtp (Exim 4.43) id 1R7Co4-0003Jm-Ud for xen-devel@lists.xensource.com; Fri, 23 Sep 2011 13:57:17 -0700 X-Env-Sender: ml-xen-devel@hfp.de X-Msg-Ref: server-3.tower-174.messagelabs.com!1316811429!26490875!1 X-Originating-IP: [88.205.101.6] X-StarScan-Version: 6.4.1; banners=-,-,- X-VirusChecked: Checked Received: (qmail 9978 invoked from network); 23 Sep 2011 20:57:09 -0000 Received: from rootsrv.hfp.de (HELO rootsrv.hfp.de) (88.205.101.6) by server-3.tower-174.messagelabs.com with SMTP; 23 Sep 2011 20:57:09 -0000 Received: from localhost (localhost [127.0.0.1]) by rootsrv.hfp.de (Postfix) with ESMTP id 6E9401A9189; Fri, 23 Sep 2011 22:57:08 +0200 (CEST) X-Virus-Scanned: amavisd-new/ClamAV at rootsrv.hfp.de Received: from rootsrv.hfp.de ([127.0.0.1]) by localhost (rootsrv.hfp.de [127.0.0.1]) (amavisd-new, port 10026) with ESMTP id D6ylxnVfUzsq; Fri, 23 Sep 2011 22:57:08 +0200 (CEST) Received: from [10.0.0.1] (p5DCB7411.dip.t-dialin.net [93.203.116.17]) by rootsrv.hfp.de (Postfix) with ESMTPA; Fri, 23 Sep 2011 22:57:08 +0200 (CEST) Message-ID: <4E7CF2A8.5040405@hfp.de> Date: Fri, 23 Sep 2011 22:57:12 +0200 From: Andreas Kinzler <ml-xen-devel@hfp.de> User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:6.0.2) Gecko/20110902 Thunderbird/6.0.2 MIME-Version: 1.0 To: James Harper <james.harper@bendigoit.com.au> Subject: Re: [Xen-devel] RE: Stability report GPLPV 0.11.0.308 References: <4E64A0DF.2070007@hfp.de> <AEC6C66638C05B468B556EA548C1A77D01E5DB8C@trantor> <4E64D569.5030607@hfp.de> <AEC6C66638C05B468B556EA548C1A77D01E5DBBF@trantor> <4E7728F9.9020208@hfp.de> <AEC6C66638C05B468B556EA548C1A77D01E5E008@trantor> <4E7B04A4.9070601@hfp.de> <AEC6C66638C05B468B556EA548C1A77D01E5E072@trantor> In-Reply-To: <AEC6C66638C05B468B556EA548C1A77D01E5E072@trantor> Content-Type: multipart/mixed; boundary="------------080705080205020601040607" Cc: xen-devel@lists.xensource.com X-BeenThere: xen-devel@lists.xensource.com X-Mailman-Version: 2.1.5 Precedence: list List-Id: Xen developer discussion <xen-devel.lists.xensource.com> List-Unsubscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe> List-Post: <mailto:xen-devel@lists.xensource.com> List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help> List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=subscribe> Sender: xen-devel-bounces@lists.xensource.com Errors-To: xen-devel-bounces@lists.xensource.com This is a multi-part message in MIME format. --------------080705080205020601040607 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Hello James, I did take a look at your commit 950 and I think there are 3 typos (see my patch). Anyway, I don't think that memory problems are causing the stability issues and (as some kind of "proof") I did not notice any increase in kernel memory usage during uptime of the VMs. Actually I am not really sure if xennet is even the problem since in none of the crash scenarios there was something in the Windows event log. In my last test I was able to enter my password via VNC (it did not login though) - this should have written some entries to the security log which it did not. So I assume that xenvbd was dead too (killed by xennet) or is actually the real reason for the stability problems. Regards Andreas --------------080705080205020601040607 Content-Type: text/plain; name="diff.patch" Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename="diff.patch" --- x\xennet6_rx.c 2011-09-22 13:47:46.000000000 +0200 +++ xennet6_rx.c 2011-09-23 22:39:47.892796400 +0200 @@ -50,8 +50,8 @@ pb->mdl = IoAllocateMdl(pb->virtual, PAGE_SIZE, FALSE, FALSE, NULL); if (!pb->mdl) { - NdisFreeMemory(pb->virtual, sizeof(shared_buffer_t), 0); - NdisFreeMemory(pb, PAGE_SIZE, 0); + NdisFreeMemory(pb->virtual, PAGE_SIZE, 0); + NdisFreeMemory(pb, sizeof(shared_buffer_t), 0); return NULL; } pb->gref = (grant_ref_t)xi->vectors.GntTbl_GrantAccess(xi->vectors.context, 0, @@ -59,8 +59,8 @@ if (pb->gref == INVALID_GRANT_REF) { IoFreeMdl(pb->mdl); - NdisFreeMemory(pb->virtual, sizeof(shared_buffer_t), 0); - NdisFreeMemory(pb, PAGE_SIZE, 0); + NdisFreeMemory(pb->virtual, PAGE_SIZE, 0); + NdisFreeMemory(pb, sizeof(shared_buffer_t), 0); return NULL; } MmBuildMdlForNonPagedPool(pb->mdl); @@ -85,8 +85,8 @@ if (xi->rx_pb_free > RX_MAX_PB_FREELIST) { IoFreeMdl(pb->mdl); - NdisFreeMemory(pb->virtual, sizeof(shared_buffer_t), 0); - NdisFreeMemory(pb, PAGE_SIZE, 0); + NdisFreeMemory(pb->virtual, PAGE_SIZE, 0); + NdisFreeMemory(pb, sizeof(shared_buffer_t), 0); return; } pb->mdl->ByteCount = PAGE_SIZE; --------------080705080205020601040607 Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel --------------080705080205020601040607-- From xen-devel-bounces@lists.xensource.com Fri Sep 23 15:18:07 2011 Return-path: <xen-devel-bounces@lists.xensource.com> Envelope-to: www-data@lists.xensource.com Delivery-date: Fri, 23 Sep 2011 15:18:07 -0700 Received: from localhost ([127.0.0.1] helo=lists.colo.xensource.com) by lists.xensource.com with esmtp (Exim 4.43) id 1R7E4N-0007dE-LW; Fri, 23 Sep 2011 15:18:07 -0700 Received: from mail182.messagelabs.com ([85.158.139.83]) by lists.xensource.com with esmtp (Exim 4.43) id 1R7E3c-0007Qt-6O for xen-devel@lists.xensource.com; Fri, 23 Sep 2011 15:17:20 -0700 X-Env-Sender: Ian.Jackson@eu.citrix.com X-Msg-Ref: server-15.tower-182.messagelabs.com!1316816237!18526012!1 X-Originating-IP: [62.200.22.115] X-StarScan-Version: 6.4.1; banners=-,-,- X-VirusChecked: Checked Received: (qmail 22944 invoked from network); 23 Sep 2011 22:17:17 -0000 Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115) by server-15.tower-182.messagelabs.com with RC4-SHA encrypted SMTP; 23 Sep 2011 22:17:17 -0000 X-IronPort-AV: E=Sophos;i="4.68,432,1312156800"; d="scan'208";a="8038025" Received: from lonpmailmx01.citrite.net ([10.30.203.162]) by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5; 23 Sep 2011 22:17:16 +0000 Received: from woking.xci-test.com (10.80.248.135) by smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id 8.3.137.0; Fri, 23 Sep 2011 23:17:16 +0100 Received: from osstest by woking.xci-test.com with local (Exim 4.69) (envelope-from <ian.jackson@eu.citrix.com>) id 1R7E3X-000583-SQ; Fri, 23 Sep 2011 23:17:16 +0100 To: xen-devel@lists.xensource.com Message-ID: <osstest-9060-mainreport@xen.org> From: xen.org <ian.jackson@eu.citrix.com> Date: Fri, 23 Sep 2011 23:17:15 +0100 MIME-Version: 1.0 Content-Type: text/plain Cc: ian.jackson@eu.citrix.com Subject: [Xen-devel] [linux test] 9060: tolerable FAIL X-BeenThere: xen-devel@lists.xensource.com X-Mailman-Version: 2.1.5 Precedence: list List-Id: Xen developer discussion <xen-devel.lists.xensource.com> List-Unsubscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe> List-Post: <mailto:xen-devel@lists.xensource.com> List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help> List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=subscribe> Sender: xen-devel-bounces@lists.xensource.com Errors-To: xen-devel-bounces@lists.xensource.com flight 9060 linux real [real] http://www.chiark.greenend.org.uk/~xensrcts/logs/9060/ Failures :-/ but no regressions. Tests which did not succeed, but are not blocking, including regressions (tests previously passed) regarded as allowable: test-amd64-amd64-xl-pcipt-intel 9 guest-start fail never pass test-amd64-i386-rhel6hvm-amd 9 guest-start.2 fail never pass test-amd64-i386-rhel6hvm-intel 9 guest-start.2 fail never pass test-amd64-i386-win-vcpus1 16 leak-check/check fail never pass test-amd64-i386-xl-win-vcpus1 13 guest-stop fail never pass test-amd64-amd64-win 16 leak-check/check fail never pass test-amd64-amd64-xl-win 13 guest-stop fail never pass test-i386-i386-win 16 leak-check/check fail never pass test-i386-i386-xl-win 13 guest-stop fail never pass test-amd64-i386-win 16 leak-check/check fail never pass version targeted for testing: linux 6bec8b4a4c14095d0b7ce424db9d583c3decae6c baseline version: linux 1c3f03ccc5258887f5f2cafc0836a865834f9205 ------------------------------------------------------------ People who touched revisions under test: Jeremy Fitzhardinge <jeremy.fitzhardinge@citrix.com> ------------------------------------------------------------ jobs: build-amd64 pass build-i386 pass build-amd64-pvops pass build-i386-pvops pass test-amd64-amd64-xl pass test-amd64-i386-xl pass test-i386-i386-xl pass test-amd64-i386-rhel6hvm-amd fail test-amd64-i386-xl-credit2 pass test-amd64-amd64-xl-pcipt-intel fail test-amd64-i386-rhel6hvm-intel fail test-amd64-i386-xl-multivcpu pass test-amd64-amd64-pair pass test-amd64-i386-pair pass test-i386-i386-pair pass test-amd64-amd64-pv pass test-amd64-i386-pv pass test-i386-i386-pv pass test-amd64-amd64-xl-sedf pass test-amd64-i386-win-vcpus1 fail test-amd64-i386-xl-win-vcpus1 fail test-amd64-amd64-win fail test-amd64-i386-win fail test-i386-i386-win fail test-amd64-amd64-xl-win fail test-i386-i386-xl-win fail ------------------------------------------------------------ sg-report-flight on woking.cam.xci-test.com logs: /home/xc_osstest/logs images: /home/xc_osstest/images Logs, config files, etc. are available at http://www.chiark.greenend.org.uk/~xensrcts/logs Test harness code can be found at http://xenbits.xensource.com/gitweb?p=osstest.git;a=summary Pushing revision : + branch=linux + revision=6bec8b4a4c14095d0b7ce424db9d583c3decae6c + . cri-lock-repos ++ . cri-common +++ umask 002 +++ getconfig Repos +++ perl -e ' use Osstest; readconfigonly(); print $c{Repos} or die $!; ' ++ repos=/export/home/osstest/repos ++ repos_lock=/export/home/osstest/repos/lock ++ '[' x '!=' x/export/home/osstest/repos/lock ']' ++ OSSTEST_REPOS_LOCK_LOCKED=/export/home/osstest/repos/lock ++ exec with-lock-ex -w /export/home/osstest/repos/lock ./ap-push linux 6bec8b4a4c14095d0b7ce424db9d583c3decae6c + branch=linux + revision=6bec8b4a4c14095d0b7ce424db9d583c3decae6c + . cri-lock-repos ++ . cri-common +++ umask 002 +++ getconfig Repos +++ perl -e ' use Osstest; readconfigonly(); print $c{Repos} or die $!; ' ++ repos=/export/home/osstest/repos ++ repos_lock=/export/home/osstest/repos/lock ++ '[' x/export/home/osstest/repos/lock '!=' x/export/home/osstest/repos/lock ']' + : xen@xenbits.xensource.com + : xen@xenbits.xensource.com:git/linux-pvops + : master + : tested/2.6.39.x + case "$branch" in + cd /export/home/osstest/repos/xen ./ap-push: line 20: cd: /export/home/osstest/repos/xen: No such file or directory ------------------------------------------------------------ commit 6bec8b4a4c14095d0b7ce424db9d583c3decae6c Author: Jeremy Fitzhardinge <jeremy.fitzhardinge@citrix.com> Date: Fri Sep 2 12:23:22 2011 -0700 Revert "xen/apic: Provide an 'apic_xen' to set the override the apic->[read|write] for all cases." This reverts commit c3dd7941354fa96a71f2613e2c7a1b215fa175dc. It prevents the kernel from booting natively on hardware. Conflicts: arch/x86/xen/enlighten.c Signed-off-by: Jeremy Fitzhardinge <jeremy.fitzhardinge@citrix.com> _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel From xen-devel-bounces@lists.xensource.com Fri Sep 23 16:13:37 2011 Return-path: <xen-devel-bounces@lists.xensource.com> Envelope-to: www-data@lists.xensource.com Delivery-date: Fri, 23 Sep 2011 16:13:37 -0700 Received: from localhost ([127.0.0.1] helo=lists.colo.xensource.com) by lists.xensource.com with esmtp (Exim 4.43) id 1R7Ew3-000260-Ij; Fri, 23 Sep 2011 16:13:35 -0700 Received: from mail174.messagelabs.com ([85.158.138.51]) by lists.xensource.com with esmtp (Exim 4.43) id 1R7EvB-0001tX-Iv for xen-devel@lists.xensource.com; Fri, 23 Sep 2011 16:12:42 -0700 X-Env-Sender: Ian.Jackson@eu.citrix.com X-Msg-Ref: server-15.tower-174.messagelabs.com!1316819558!26208564!1 X-Originating-IP: [62.200.22.115] X-StarScan-Version: 6.4.1; banners=-,-,- X-VirusChecked: Checked Received: (qmail 27611 invoked from network); 23 Sep 2011 23:12:38 -0000 Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115) by server-15.tower-174.messagelabs.com with RC4-SHA encrypted SMTP; 23 Sep 2011 23:12:38 -0000 X-IronPort-AV: E=Sophos;i="4.68,432,1312156800"; d="scan'208";a="8038552" Received: from lonpmailmx01.citrite.net ([10.30.203.162]) by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5; 23 Sep 2011 23:12:37 +0000 Received: from woking.xci-test.com (10.80.248.135) by smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id 8.3.137.0; Sat, 24 Sep 2011 00:12:38 +0100 Received: from osstest by woking.xci-test.com with local (Exim 4.69) (envelope-from <ian.jackson@eu.citrix.com>) id 1R7Ev7-0003rm-Hb; Sat, 24 Sep 2011 00:12:37 +0100 To: xen-devel@lists.xensource.com Message-ID: <osstest-9061-mainreport@xen.org> From: xen.org <ian.jackson@eu.citrix.com> Date: Sat, 24 Sep 2011 00:12:37 +0100 MIME-Version: 1.0 Content-Type: text/plain Cc: ian.jackson@eu.citrix.com Subject: [Xen-devel] [xen-unstable test] 9061: regressions - FAIL X-BeenThere: xen-devel@lists.xensource.com X-Mailman-Version: 2.1.5 Precedence: list List-Id: Xen developer discussion <xen-devel.lists.xensource.com> List-Unsubscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe> List-Post: <mailto:xen-devel@lists.xensource.com> List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help> List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=subscribe> Sender: xen-devel-bounces@lists.xensource.com Errors-To: xen-devel-bounces@lists.xensource.com flight 9061 xen-unstable real [real] http://www.chiark.greenend.org.uk/~xensrcts/logs/9061/ Regressions :-( Tests which did not succeed and are blocking: test-amd64-i386-rhel6hvm-amd 5 xen-boot fail REGR. vs. 8995 Tests which are failing intermittently (not blocking): test-amd64-i386-pv 5 xen-boot fail pass in 9054 test-i386-i386-pv 5 xen-boot fail pass in 9059 test-amd64-i386-xl-credit2 5 xen-boot fail pass in 9054 test-amd64-i386-xl-win-vcpus1 5 xen-boot fail pass in 9043 test-i386-i386-win 5 xen-boot fail pass in 9059 test-i386-i386-xl-win 5 xen-boot fail pass in 9054 test-i386-i386-pair 8 xen-boot/dst_host fail pass in 9059 test-i386-i386-pair 7 xen-boot/src_host fail pass in 9059 test-amd64-i386-win 5 xen-boot fail pass in 9059 test-amd64-amd64-xl-win 5 xen-boot fail pass in 9059 test-amd64-amd64-pv 5 xen-boot fail in 9054 pass in 9061 test-amd64-amd64-xl-sedf 5 xen-boot fail in 9054 pass in 9061 test-amd64-i386-xl 5 xen-boot fail in 9054 pass in 9061 test-i386-i386-xl 5 xen-boot fail in 9054 pass in 9061 test-amd64-amd64-pair 7 xen-boot/src_host fail in 9054 pass in 9061 test-amd64-amd64-pair 8 xen-boot/dst_host fail in 9054 pass in 9061 test-amd64-i386-xl-multivcpu 5 xen-boot fail in 9043 pass in 9061 test-amd64-amd64-win 5 xen-boot fail in 9043 pass in 9061 test-amd64-i386-win-vcpus1 5 xen-boot fail in 9043 pass in 9061 test-amd64-i386-pair 7 xen-boot/src_host fail in 9059 pass in 9061 test-amd64-i386-pair 8 xen-boot/dst_host fail in 9059 pass in 9061 Tests which did not succeed, but are not blocking, including regressions (tests previously passed) regarded as allowable: test-amd64-amd64-xl-pcipt-intel 9 guest-start fail never pass test-amd64-i386-rhel6hvm-intel 9 guest-start.2 fail never pass test-amd64-amd64-win 16 leak-check/check fail never pass test-amd64-i386-win-vcpus1 16 leak-check/check fail never pass test-i386-i386-xl-win 13 guest-stop fail in 9054 never pass test-amd64-i386-win 16 leak-check/check fail in 9054 never pass test-amd64-amd64-xl-win 13 guest-stop fail in 9054 never pass test-amd64-amd64-xl-sedf 14 guest-localmigrate/x10 fail in 9043 like 8995 test-amd64-i386-xl-win-vcpus1 13 guest-stop fail in 9043 never pass test-i386-i386-win 16 leak-check/check fail in 9059 never pass version targeted for testing: xen cc339ab1d917 baseline version: xen a422e2a4451e ------------------------------------------------------------ People who touched revisions under test: Andreas Herrmann <herrmann.der.user@googlemail.com> Ian Campbell <ian.campbell@citrix.com> Ian Jackson <ian.jackson@eu.citrix.com> Jan Beulich <jbeulich@suse.com> Lasse Collin <lasse.collin@tukaani.org> Olaf Hering <olaf@aepfle.de> Thomas Renninger <trenn@suse.de> ------------------------------------------------------------ jobs: build-amd64 pass build-i386 pass build-amd64-oldkern pass build-i386-oldkern pass build-amd64-pvops pass build-i386-pvops pass test-amd64-amd64-xl pass test-amd64-i386-xl pass test-i386-i386-xl pass test-amd64-i386-rhel6hvm-amd fail test-amd64-i386-xl-credit2 fail test-amd64-amd64-xl-pcipt-intel fail test-amd64-i386-rhel6hvm-intel fail test-amd64-i386-xl-multivcpu pass test-amd64-amd64-pair pass test-amd64-i386-pair pass test-i386-i386-pair fail test-amd64-amd64-pv pass test-amd64-i386-pv fail test-i386-i386-pv fail test-amd64-amd64-xl-sedf pass test-amd64-i386-win-vcpus1 fail test-amd64-i386-xl-win-vcpus1 fail test-amd64-amd64-win fail test-amd64-i386-win fail test-i386-i386-win fail test-amd64-amd64-xl-win fail test-i386-i386-xl-win fail ------------------------------------------------------------ sg-report-flight on woking.cam.xci-test.com logs: /home/xc_osstest/logs images: /home/xc_osstest/images Logs, config files, etc. are available at http://www.chiark.greenend.org.uk/~xensrcts/logs Test harness code can be found at http://xenbits.xensource.com/gitweb?p=osstest.git;a=summary Not pushing. ------------------------------------------------------------ changeset: 23872:cc339ab1d917 tag: tip user: Ian Campbell <ian.campbell@citrix.com> date: Thu Sep 22 18:37:06 2011 +0100 tools: fix install of lomount $(BIN) went away in 23124:e3d4c34b14a3. Also there are no *.so, *.a or *.rpm built in here Signed-off-by: Ian Campbell <ian.campbell@citrix.com> changeset: 23871:503ee256fecf user: Jan Beulich <jbeulich@suse.com> date: Thu Sep 22 18:35:30 2011 +0100 x86: ucode-amd: Don't warn when no ucode is available for a CPU revision This patch originally comes from the Linus mainline kernel (2.6.33), find below the patch details: From: Andreas Herrmann <herrmann.der.user@googlemail.com> There is no point in warning when there is no ucode available for a specific CPU revision. Currently the container-file, which provides the AMD ucode patches for OS load, contains only a few ucode patches. It's already clearly indicated by the printed patch_level whenever new ucode was available and an update happened. So the warning message is of no help but rather annoying on systems with many CPUs. Signed-off-by: Thomas Renninger <trenn@suse.de> Signed-off-by: Jan Beulich <jbeulich@suse.com> changeset: 23870:5c97b02f48fc user: Jan Beulich <jbeulich@suse.com> date: Thu Sep 22 18:34:27 2011 +0100 XZ: Fix incorrect XZ_BUF_ERROR From: Lasse Collin <lasse.collin@tukaani.org> xz_dec_run() could incorrectly return XZ_BUF_ERROR if all of the following was true: - The caller knows how many bytes of output to expect and only provides that much output space. - When the last output bytes are decoded, the caller-provided input buffer ends right before the LZMA2 end of payload marker. So LZMA2 won't provide more output anymore, but it won't know it yet and thus won't return XZ_STREAM_END yet. - A BCJ filter is in use and it hasn't left any unfiltered bytes in the temp buffer. This can happen with any BCJ filter, but in practice it's more likely with filters other than the x86 BCJ. This fixes <https://bugzilla.redhat.com/show_bug.cgi?id=3D735408> where Squashfs thinks that a valid file system is corrupt. This also fixes a similar bug in single-call mode where the uncompressed size of a block using BCJ + LZMA2 was 0 bytes and caller provided no output space. Many empty .xz files don't contain any blocks and thus don't trigger this bug. This also tweaks a closely related detail: xz_dec_bcj_run() could call xz_dec_lzma2_run() to decode into temp buffer when it was known to be useless. This was harmless although it wasted a minuscule number of CPU cycles. Signed-off-by: Lasse Collin <lasse.collin@tukaani.org> Signed-off-by: Jan Beulich <jbeulich@suse.com> changeset: 23869:db1ea4b127cd user: Jan Beulich <jbeulich@suse.com> date: Thu Sep 22 18:33:48 2011 +0100 XZ decompressor: Fix decoding of empty LZMA2 streams From: Lasse Collin <lasse.collin@tukaani.org> The old code considered valid empty LZMA2 streams to be corrupt. Note that a typical empty .xz file has no LZMA2 data at all, and thus most .xz files having no uncompressed data are handled correctly even without this fix. Signed-off-by: Lasse Collin <lasse.collin@tukaani.org> Signed-off-by: Jan Beulich <jbeulich@suse.com> changeset: 23868:28147fd781af user: Jan Beulich <jbeulich@suse.com> date: Thu Sep 22 18:32:34 2011 +0100 VT-d: fix off-by-one error in RMRR validation (base_addr,end_addr) is an inclusive range, and hence there shouldn't be a subtraction of 1 in the second invocation of page_is_ram_type(). For RMRRs covering a single page that actually resulted in the immediately preceding page to get checked (which could have resulted in a false warning). Signed-off-by: Jan Beulich <jbeulich@suse.com> changeset: 23867:571b6e90dfb4 user: Jan Beulich <jbeulich@suse.com> date: Thu Sep 22 18:31:44 2011 +0100 VT-d: eliminate a mis-use of pcidevs_lock dma_pte_clear_one() shouldn't acquire this global lock for the purpose of processing a per-domain list. Furthermore the function a few lines earlier has a comment stating that acquiring pcidevs_lock isn't necessary here (whether that's really correct is another question). Use the domain's mappin_lock instead to protect the mapped_rmrrs list. Fold domain_rmrr_mapped() into its sole caller so that the otherwise implicit dependency on pcidevs_lock there becomes more obvious (see the comment there). Signed-off-by: Jan Beulich <jbeulich@suse.com> changeset: 23866:47ec1d405af9 user: Jan Beulich <jbeulich@suse.com> date: Thu Sep 22 18:31:02 2011 +0100 x86: IO-APIC code has no dependency on PCI The IRQ handling code requires pcidevs_lock to be held only for MSI interrupts. As the handling of which was now fully moved into msi.c (i.e. while applying fine without, the patch needs to be applied after the one titled "x86: split MSI IRQ chip"), io_apic.c now also doesn't need to include PCI headers anymore. Signed-off-by: Jan Beulich <jbeulich@suse.com> changeset: 23865:d6e01c7853cf user: Jan Beulich <jbeulich@suse.com> date: Thu Sep 22 18:29:19 2011 +0100 PCI multi-seg: config space accessor adjustments Signed-off-by: Jan Beulich <jbeulich@suse.com> changeset: 23864:314b147d524d user: Jan Beulich <jbeulich@suse.com> date: Thu Sep 22 18:28:38 2011 +0100 PCI multi-seg: Pass-through adjustments Signed-off-by: Jan Beulich <jbeulich@suse.com> changeset: 23863:9e0259239822 user: Jan Beulich <jbeulich@suse.com> date: Thu Sep 22 18:28:03 2011 +0100 PCI multi-seg: AMD-IOMMU specific adjustments There are two places here where it is entirely unclear to me where the necessary PCI segment number should be taken from (as IVMD descriptors don't have such, only IVHD ones do). AMD confirmed that for the time being it is acceptable to imply that only segment 0 exists. Signed-off-by: Jan Beulich <jbeulich@suse.com> changeset: 23862:85418e168527 user: Jan Beulich <jbeulich@suse.com> date: Thu Sep 22 18:27:26 2011 +0100 PCI multi-seg: VT-d specific adjustments Signed-off-by: Jan Beulich <jbeulich@suse.com> changeset: 23861:ec7c81fbe0de user: Jan Beulich <jbeulich@suse.com> date: Thu Sep 22 18:26:54 2011 +0100 PCI multi-seg: adjust domctl interface Again, a couple of directly related functions at once get adjusted to account for the segment number. Signed-off-by: Jan Beulich <jbeulich@suse.com> changeset: 23860:a422e2a4451e user: Jan Beulich <jbeulich@suse.com> date: Sun Sep 18 00:26:52 2011 +0100 x86: split MSI IRQ chip With the .end() accessor having become optional and noting that several of the accessors' behavior really depends on the result of msi_maskable_irq(), the splits the MSI IRQ chip type into two - one for the maskable ones, and the other for the (MSI only) non-maskable ones. At once the implementation of those methods gets moved from io_apic.c to msi.c. Signed-off-by: Jan Beulich <jbeulich@suse.com> ======================================== commit cd776ee9408ff127f934a707c1a339ee600bc127 Author: Ian Jackson <ian.jackson@eu.citrix.com> Date: Tue Jun 28 13:50:53 2011 +0100 qemu-char.c: fix incorrect CONFIG_STUBDOM handling qemu-char.c:1123:7: warning: "CONFIG_STUBDOM" is not defined [-Wundef] Signed-off-by: Olaf Hering <olaf@aepfle.de> Acked-by: Ian Jackson <ian.jackson@eu.citrix.com> _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel From xen-devel-bounces@lists.xensource.com Fri Sep 23 16:51:13 2011 Return-path: <xen-devel-bounces@lists.xensource.com> Envelope-to: www-data@lists.xensource.com Delivery-date: Fri, 23 Sep 2011 16:51:13 -0700 Received: from localhost ([127.0.0.1] helo=lists.colo.xensource.com) by lists.xensource.com with esmtp (Exim 4.43) id 1R7FWS-00046W-SC; Fri, 23 Sep 2011 16:51:12 -0700 Received: from mail216.messagelabs.com ([85.158.143.99]) by lists.xensource.com with esmtp (Exim 4.43) id 1R7FVT-0003tn-8e for xen-devel@lists.xensource.com; Fri, 23 Sep 2011 16:50:12 -0700 X-Env-Sender: james.harper@bendigoit.com.au X-Msg-Ref: server-12.tower-216.messagelabs.com!1316821804!13666922!1 X-Originating-IP: [203.16.207.99] X-StarScan-Version: 6.4.1; banners=-,-,- X-VirusChecked: Checked Received: (qmail 30065 invoked from network); 23 Sep 2011 23:50:08 -0000 Received: from mail.bendigoit.com.au (HELO smtp2.bendigoit.com.au) (203.16.207.99) by server-12.tower-216.messagelabs.com with AES256-SHA encrypted SMTP; 23 Sep 2011 23:50:08 -0000 Received: from trantor.int.sbss.com.au ([192.168.200.206] helo=mail.bendigoit.com.au) by smtp2.bendigoit.com.au with esmtp (Exim 4.72) (envelope-from <james.harper@bendigoit.com.au>) id 1R7FVJ-0005Kv-NT; Sat, 24 Sep 2011 09:50:01 +1000 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable X-MimeOLE: Produced By Microsoft Exchange V6.5 Subject: RE: [Xen-devel] RE: Stability report GPLPV 0.11.0.308 Date: Sat, 24 Sep 2011 09:49:58 +1000 Message-ID: <AEC6C66638C05B468B556EA548C1A77D01E5E0D0@trantor> In-Reply-To: <4E7CF2A8.5040405@hfp.de> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Xen-devel] RE: Stability report GPLPV 0.11.0.308 Thread-Index: Acx6M2LIFxUgew04Qf6IVjYzjMuw+QAF66qQ References: <4E64A0DF.2070007@hfp.de> <AEC6C66638C05B468B556EA548C1A77D01E5DB8C@trantor> <4E64D569.5030607@hfp.de> <AEC6C66638C05B468B556EA548C1A77D01E5DBBF@trantor> <4E7728F9.9020208@hfp.de> <AEC6C66638C05B468B556EA548C1A77D01E5E008@trantor> <4E7B04A4.9070601@hfp.de> <AEC6C66638C05B468B556EA548C1A77D01E5E072@trantor> <4E7CF2A8.5040405@hfp.de> From: "James Harper" <james.harper@bendigoit.com.au> To: "Andreas Kinzler" <ml-xen-devel@hfp.de> X-Really-From-Bendigo-IT: magichashvalue Cc: xen-devel@lists.xensource.com X-BeenThere: xen-devel@lists.xensource.com X-Mailman-Version: 2.1.5 Precedence: list List-Id: Xen developer discussion <xen-devel.lists.xensource.com> List-Unsubscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe> List-Post: <mailto:xen-devel@lists.xensource.com> List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help> List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=subscribe> Sender: xen-devel-bounces@lists.xensource.com Errors-To: xen-devel-bounces@lists.xensource.com >=20 > I did take a look at your commit 950 and I think there are 3 typos (see my > patch). Thanks for that. I guess the length parameter mustn't be verified or I would have crashed... > Anyway, I don't think that memory problems are causing the stability > issues and (as some kind of "proof") I did not notice any increase in kernel > memory usage during uptime of the VMs. >=20 > Actually I am not really sure if xennet is even the problem since in none of > the crash scenarios there was something in the Windows event log. In my > last test I was able to enter my password via VNC (it did not login though) - > this should have written some entries to the security log which it did not. So I > assume that xenvbd was dead too (killed by > xennet) or is actually the real reason for the stability problems. >=20 I'm just setting up a few new servers and on one of them a Windows 2008R2 machine hung and there were lots of xenvbd errors in the logs. The underlying block device for that DomU is iSCSI and I assumed the problem was there (I was doing a lot of testing on the SAN at the time) but maybe not. No evidence of problems in /var/log/xen/qemu-dm-<domu name>.log? James _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel From xen-devel-bounces@lists.xensource.com Fri Sep 23 18:10:21 2011 Return-path: <xen-devel-bounces@lists.xensource.com> Envelope-to: www-data@lists.xensource.com Delivery-date: Fri, 23 Sep 2011 18:10:21 -0700 Received: from localhost ([127.0.0.1] helo=lists.colo.xensource.com) by lists.xensource.com with esmtp (Exim 4.43) id 1R7Gl3-00062H-HO; Fri, 23 Sep 2011 18:10:21 -0700 Received: from mail27.messagelabs.com ([193.109.254.147]) by lists.xensource.com with esmtp (Exim 4.43) id 1R7Gk8-0005po-8f for xen-devel@lists.xensource.com; Fri, 23 Sep 2011 18:09:25 -0700 X-Env-Sender: Ian.Jackson@eu.citrix.com X-Msg-Ref: server-5.tower-27.messagelabs.com!1316826541!46153580!1 X-Originating-IP: [62.200.22.115] X-StarScan-Version: 6.4.1; banners=-,-,- X-VirusChecked: Checked Received: (qmail 18592 invoked from network); 24 Sep 2011 01:09:01 -0000 Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115) by server-5.tower-27.messagelabs.com with RC4-SHA encrypted SMTP; 24 Sep 2011 01:09:01 -0000 X-IronPort-AV: E=Sophos;i="4.68,433,1312156800"; d="scan'208";a="8038813" Received: from lonpmailmx01.citrite.net ([10.30.203.162]) by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5; 24 Sep 2011 01:09:20 +0000 Received: from woking.xci-test.com (10.80.248.135) by smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id 8.3.137.0; Sat, 24 Sep 2011 02:09:20 +0100 Received: from osstest by woking.xci-test.com with local (Exim 4.69) (envelope-from <ian.jackson@eu.citrix.com>) id 1R7Gk4-0007qR-0K; Sat, 24 Sep 2011 02:09:20 +0100 To: xen-devel@lists.xensource.com Message-ID: <osstest-9062-mainreport@xen.org> From: xen.org <ian.jackson@eu.citrix.com> Date: Sat, 24 Sep 2011 02:09:20 +0100 MIME-Version: 1.0 Content-Type: text/plain Cc: ian.jackson@eu.citrix.com Subject: [Xen-devel] [linux test] 9062: tolerable FAIL X-BeenThere: xen-devel@lists.xensource.com X-Mailman-Version: 2.1.5 Precedence: list List-Id: Xen developer discussion <xen-devel.lists.xensource.com> List-Unsubscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe> List-Post: <mailto:xen-devel@lists.xensource.com> List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help> List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=subscribe> Sender: xen-devel-bounces@lists.xensource.com Errors-To: xen-devel-bounces@lists.xensource.com flight 9062 linux real [real] http://www.chiark.greenend.org.uk/~xensrcts/logs/9062/ Failures :-/ but no regressions. Tests which are failing intermittently (not blocking): test-amd64-amd64-xl-sedf 12 guest-saverestore.2 fail pass in 9060 Tests which did not succeed, but are not blocking, including regressions (tests previously passed) regarded as allowable: test-amd64-amd64-xl-pcipt-intel 9 guest-start fail never pass test-amd64-i386-rhel6hvm-amd 9 guest-start.2 fail never pass test-amd64-i386-rhel6hvm-intel 9 guest-start.2 fail never pass test-amd64-i386-win-vcpus1 16 leak-check/check fail never pass test-amd64-i386-xl-win-vcpus1 13 guest-stop fail never pass test-amd64-amd64-win 16 leak-check/check fail never pass test-amd64-amd64-xl-win 13 guest-stop fail never pass test-i386-i386-win 16 leak-check/check fail never pass test-i386-i386-xl-win 13 guest-stop fail never pass test-amd64-i386-win 16 leak-check/check fail never pass version targeted for testing: linux 6bec8b4a4c14095d0b7ce424db9d583c3decae6c baseline version: linux 1c3f03ccc5258887f5f2cafc0836a865834f9205 ------------------------------------------------------------ People who touched revisions under test: Jeremy Fitzhardinge <jeremy.fitzhardinge@citrix.com> ------------------------------------------------------------ jobs: build-amd64 pass build-i386 pass build-amd64-pvops pass build-i386-pvops pass test-amd64-amd64-xl pass test-amd64-i386-xl pass test-i386-i386-xl pass test-amd64-i386-rhel6hvm-amd fail test-amd64-i386-xl-credit2 pass test-amd64-amd64-xl-pcipt-intel fail test-amd64-i386-rhel6hvm-intel fail test-amd64-i386-xl-multivcpu pass test-amd64-amd64-pair pass test-amd64-i386-pair pass test-i386-i386-pair pass test-amd64-amd64-pv pass test-amd64-i386-pv pass test-i386-i386-pv pass test-amd64-amd64-xl-sedf fail test-amd64-i386-win-vcpus1 fail test-amd64-i386-xl-win-vcpus1 fail test-amd64-amd64-win fail test-amd64-i386-win fail test-i386-i386-win fail test-amd64-amd64-xl-win fail test-i386-i386-xl-win fail ------------------------------------------------------------ sg-report-flight on woking.cam.xci-test.com logs: /home/xc_osstest/logs images: /home/xc_osstest/images Logs, config files, etc. are available at http://www.chiark.greenend.org.uk/~xensrcts/logs Test harness code can be found at http://xenbits.xensource.com/gitweb?p=osstest.git;a=summary Pushing revision : + branch=linux + revision=6bec8b4a4c14095d0b7ce424db9d583c3decae6c + . cri-lock-repos ++ . cri-common +++ umask 002 +++ getconfig Repos +++ perl -e ' use Osstest; readconfigonly(); print $c{Repos} or die $!; ' ++ repos=/export/home/osstest/repos ++ repos_lock=/export/home/osstest/repos/lock ++ '[' x '!=' x/export/home/osstest/repos/lock ']' ++ OSSTEST_REPOS_LOCK_LOCKED=/export/home/osstest/repos/lock ++ exec with-lock-ex -w /export/home/osstest/repos/lock ./ap-push linux 6bec8b4a4c14095d0b7ce424db9d583c3decae6c + branch=linux + revision=6bec8b4a4c14095d0b7ce424db9d583c3decae6c + . cri-lock-repos ++ . cri-common +++ umask 002 +++ getconfig Repos +++ perl -e ' use Osstest; readconfigonly(); print $c{Repos} or die $!; ' ++ repos=/export/home/osstest/repos ++ repos_lock=/export/home/osstest/repos/lock ++ '[' x/export/home/osstest/repos/lock '!=' x/export/home/osstest/repos/lock ']' + : xen@xenbits.xensource.com + : xen@xenbits.xensource.com:git/linux-pvops + : master + : tested/2.6.39.x + case "$branch" in + cd /export/home/osstest/repos/xen ./ap-push: line 20: cd: /export/home/osstest/repos/xen: No such file or directory ------------------------------------------------------------ commit 6bec8b4a4c14095d0b7ce424db9d583c3decae6c Author: Jeremy Fitzhardinge <jeremy.fitzhardinge@citrix.com> Date: Fri Sep 2 12:23:22 2011 -0700 Revert "xen/apic: Provide an 'apic_xen' to set the override the apic->[read|write] for all cases." This reverts commit c3dd7941354fa96a71f2613e2c7a1b215fa175dc. It prevents the kernel from booting natively on hardware. Conflicts: arch/x86/xen/enlighten.c Signed-off-by: Jeremy Fitzhardinge <jeremy.fitzhardinge@citrix.com> _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel From xen-devel-bounces@lists.xensource.com Fri Sep 23 20:22:21 2011 Return-path: <xen-devel-bounces@lists.xensource.com> Envelope-to: www-data@lists.xensource.com Delivery-date: Fri, 23 Sep 2011 20:22:21 -0700 Received: from localhost ([127.0.0.1] helo=lists.colo.xensource.com) by lists.xensource.com with esmtp (Exim 4.43) id 1R7Iom-0000WW-Ry; Fri, 23 Sep 2011 20:22:21 -0700 Received: from mail21.messagelabs.com ([85.158.143.35]) by lists.xensource.com with esmtp (Exim 4.43) id 1R7InX-0000Ia-Gj for xen-devel@lists.xensource.com; Fri, 23 Sep 2011 20:21:07 -0700 X-Env-Sender: Ian.Jackson@eu.citrix.com X-Msg-Ref: server-2.tower-21.messagelabs.com!1316834458!35286683!1 X-Originating-IP: [62.200.22.115] X-StarScan-Version: 6.4.1; banners=-,-,- X-VirusChecked: Checked Received: (qmail 13243 invoked from network); 24 Sep 2011 03:20:59 -0000 Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115) by server-2.tower-21.messagelabs.com with RC4-SHA encrypted SMTP; 24 Sep 2011 03:20:59 -0000 X-IronPort-AV: E=Sophos;i="4.68,434,1312156800"; d="scan'208";a="8039042" Received: from lonpmailmx01.citrite.net ([10.30.203.162]) by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5; 24 Sep 2011 03:21:00 +0000 Received: from woking.xci-test.com (10.80.248.135) by smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id 8.3.137.0; Sat, 24 Sep 2011 04:20:59 +0100 Received: from osstest by woking.xci-test.com with local (Exim 4.69) (envelope-from <ian.jackson@eu.citrix.com>) id 1R7InT-0002WW-BQ; Sat, 24 Sep 2011 04:20:59 +0100 To: xen-devel@lists.xensource.com Message-ID: <osstest-9063-mainreport@xen.org> From: xen.org <ian.jackson@eu.citrix.com> Date: Sat, 24 Sep 2011 04:20:59 +0100 MIME-Version: 1.0 Content-Type: text/plain Cc: ian.jackson@eu.citrix.com Subject: [Xen-devel] [xen-unstable test] 9063: regressions - FAIL X-BeenThere: xen-devel@lists.xensource.com X-Mailman-Version: 2.1.5 Precedence: list List-Id: Xen developer discussion <xen-devel.lists.xensource.com> List-Unsubscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe> List-Post: <mailto:xen-devel@lists.xensource.com> List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help> List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=subscribe> Sender: xen-devel-bounces@lists.xensource.com Errors-To: xen-devel-bounces@lists.xensource.com flight 9063 xen-unstable real [real] http://www.chiark.greenend.org.uk/~xensrcts/logs/9063/ Regressions :-( Tests which did not succeed and are blocking: test-amd64-i386-rhel6hvm-amd 5 xen-boot fail REGR. vs. 8995 Tests which are failing intermittently (not blocking): test-amd64-amd64-xl 5 xen-boot fail pass in 9061 test-i386-i386-pv 5 xen-boot fail pass in 9059 test-amd64-amd64-pv 5 xen-boot fail pass in 9061 test-amd64-i386-xl-multivcpu 5 xen-boot fail pass in 9061 test-amd64-i386-xl-win-vcpus1 5 xen-boot fail pass in 9043 test-i386-i386-xl-win 5 xen-boot fail pass in 9054 test-amd64-amd64-pair 7 xen-boot/src_host fail pass in 9061 test-amd64-amd64-pair 8 xen-boot/dst_host fail pass in 9061 test-amd64-i386-win-vcpus1 5 xen-boot fail pass in 9061 test-amd64-i386-win 5 xen-boot fail pass in 9059 test-amd64-i386-pv 5 xen-boot fail in 9061 pass in 9063 test-amd64-i386-xl-credit2 5 xen-boot fail in 9061 pass in 9063 test-i386-i386-win 5 xen-boot fail in 9061 pass in 9063 test-i386-i386-pair 8 xen-boot/dst_host fail in 9061 pass in 9063 test-i386-i386-pair 7 xen-boot/src_host fail in 9061 pass in 9063 test-amd64-amd64-xl-win 5 xen-boot fail in 9061 pass in 9063 test-amd64-amd64-xl-sedf 5 xen-boot fail in 9059 pass in 9063 test-amd64-i386-xl 5 xen-boot fail in 9059 pass in 9063 test-amd64-i386-pair 7 xen-boot/src_host fail in 9059 pass in 9063 test-amd64-i386-pair 8 xen-boot/dst_host fail in 9059 pass in 9063 test-i386-i386-xl 5 xen-boot fail in 9043 pass in 9063 test-amd64-amd64-win 5 xen-boot fail in 9043 pass in 9063 Tests which did not succeed, but are not blocking, including regressions (tests previously passed) regarded as allowable: test-amd64-amd64-xl-pcipt-intel 9 guest-start fail never pass test-amd64-i386-rhel6hvm-intel 9 guest-start.2 fail never pass test-i386-i386-win 16 leak-check/check fail never pass test-amd64-amd64-win 16 leak-check/check fail never pass test-amd64-amd64-xl-win 13 guest-stop fail never pass test-amd64-i386-win-vcpus1 16 leak-check/check fail in 9061 never pass test-amd64-i386-win 16 leak-check/check fail in 9059 never pass test-amd64-amd64-xl-sedf 14 guest-localmigrate/x10 fail in 9043 like 8995 test-amd64-i386-xl-win-vcpus1 13 guest-stop fail in 9043 never pass test-i386-i386-xl-win 13 guest-stop fail in 9043 never pass version targeted for testing: xen cc339ab1d917 baseline version: xen a422e2a4451e ------------------------------------------------------------ People who touched revisions under test: Andreas Herrmann <herrmann.der.user@googlemail.com> Ian Campbell <ian.campbell@citrix.com> Ian Jackson <ian.jackson@eu.citrix.com> Jan Beulich <jbeulich@suse.com> Lasse Collin <lasse.collin@tukaani.org> Olaf Hering <olaf@aepfle.de> Thomas Renninger <trenn@suse.de> ------------------------------------------------------------ jobs: build-amd64 pass build-i386 pass build-amd64-oldkern pass build-i386-oldkern pass build-amd64-pvops pass build-i386-pvops pass test-amd64-amd64-xl fail test-amd64-i386-xl pass test-i386-i386-xl pass test-amd64-i386-rhel6hvm-amd fail test-amd64-i386-xl-credit2 pass test-amd64-amd64-xl-pcipt-intel fail test-amd64-i386-rhel6hvm-intel fail test-amd64-i386-xl-multivcpu fail test-amd64-amd64-pair fail test-amd64-i386-pair pass test-i386-i386-pair pass test-amd64-amd64-pv fail test-amd64-i386-pv pass test-i386-i386-pv fail test-amd64-amd64-xl-sedf pass test-amd64-i386-win-vcpus1 fail test-amd64-i386-xl-win-vcpus1 fail test-amd64-amd64-win fail test-amd64-i386-win fail test-i386-i386-win fail test-amd64-amd64-xl-win fail test-i386-i386-xl-win fail ------------------------------------------------------------ sg-report-flight on woking.cam.xci-test.com logs: /home/xc_osstest/logs images: /home/xc_osstest/images Logs, config files, etc. are available at http://www.chiark.greenend.org.uk/~xensrcts/logs Test harness code can be found at http://xenbits.xensource.com/gitweb?p=osstest.git;a=summary Not pushing. ------------------------------------------------------------ changeset: 23872:cc339ab1d917 tag: tip user: Ian Campbell <ian.campbell@citrix.com> date: Thu Sep 22 18:37:06 2011 +0100 tools: fix install of lomount $(BIN) went away in 23124:e3d4c34b14a3. Also there are no *.so, *.a or *.rpm built in here Signed-off-by: Ian Campbell <ian.campbell@citrix.com> changeset: 23871:503ee256fecf user: Jan Beulich <jbeulich@suse.com> date: Thu Sep 22 18:35:30 2011 +0100 x86: ucode-amd: Don't warn when no ucode is available for a CPU revision This patch originally comes from the Linus mainline kernel (2.6.33), find below the patch details: From: Andreas Herrmann <herrmann.der.user@googlemail.com> There is no point in warning when there is no ucode available for a specific CPU revision. Currently the container-file, which provides the AMD ucode patches for OS load, contains only a few ucode patches. It's already clearly indicated by the printed patch_level whenever new ucode was available and an update happened. So the warning message is of no help but rather annoying on systems with many CPUs. Signed-off-by: Thomas Renninger <trenn@suse.de> Signed-off-by: Jan Beulich <jbeulich@suse.com> changeset: 23870:5c97b02f48fc user: Jan Beulich <jbeulich@suse.com> date: Thu Sep 22 18:34:27 2011 +0100 XZ: Fix incorrect XZ_BUF_ERROR From: Lasse Collin <lasse.collin@tukaani.org> xz_dec_run() could incorrectly return XZ_BUF_ERROR if all of the following was true: - The caller knows how many bytes of output to expect and only provides that much output space. - When the last output bytes are decoded, the caller-provided input buffer ends right before the LZMA2 end of payload marker. So LZMA2 won't provide more output anymore, but it won't know it yet and thus won't return XZ_STREAM_END yet. - A BCJ filter is in use and it hasn't left any unfiltered bytes in the temp buffer. This can happen with any BCJ filter, but in practice it's more likely with filters other than the x86 BCJ. This fixes <https://bugzilla.redhat.com/show_bug.cgi?id=3D735408> where Squashfs thinks that a valid file system is corrupt. This also fixes a similar bug in single-call mode where the uncompressed size of a block using BCJ + LZMA2 was 0 bytes and caller provided no output space. Many empty .xz files don't contain any blocks and thus don't trigger this bug. This also tweaks a closely related detail: xz_dec_bcj_run() could call xz_dec_lzma2_run() to decode into temp buffer when it was known to be useless. This was harmless although it wasted a minuscule number of CPU cycles. Signed-off-by: Lasse Collin <lasse.collin@tukaani.org> Signed-off-by: Jan Beulich <jbeulich@suse.com> changeset: 23869:db1ea4b127cd user: Jan Beulich <jbeulich@suse.com> date: Thu Sep 22 18:33:48 2011 +0100 XZ decompressor: Fix decoding of empty LZMA2 streams From: Lasse Collin <lasse.collin@tukaani.org> The old code considered valid empty LZMA2 streams to be corrupt. Note that a typical empty .xz file has no LZMA2 data at all, and thus most .xz files having no uncompressed data are handled correctly even without this fix. Signed-off-by: Lasse Collin <lasse.collin@tukaani.org> Signed-off-by: Jan Beulich <jbeulich@suse.com> changeset: 23868:28147fd781af user: Jan Beulich <jbeulich@suse.com> date: Thu Sep 22 18:32:34 2011 +0100 VT-d: fix off-by-one error in RMRR validation (base_addr,end_addr) is an inclusive range, and hence there shouldn't be a subtraction of 1 in the second invocation of page_is_ram_type(). For RMRRs covering a single page that actually resulted in the immediately preceding page to get checked (which could have resulted in a false warning). Signed-off-by: Jan Beulich <jbeulich@suse.com> changeset: 23867:571b6e90dfb4 user: Jan Beulich <jbeulich@suse.com> date: Thu Sep 22 18:31:44 2011 +0100 VT-d: eliminate a mis-use of pcidevs_lock dma_pte_clear_one() shouldn't acquire this global lock for the purpose of processing a per-domain list. Furthermore the function a few lines earlier has a comment stating that acquiring pcidevs_lock isn't necessary here (whether that's really correct is another question). Use the domain's mappin_lock instead to protect the mapped_rmrrs list. Fold domain_rmrr_mapped() into its sole caller so that the otherwise implicit dependency on pcidevs_lock there becomes more obvious (see the comment there). Signed-off-by: Jan Beulich <jbeulich@suse.com> changeset: 23866:47ec1d405af9 user: Jan Beulich <jbeulich@suse.com> date: Thu Sep 22 18:31:02 2011 +0100 x86: IO-APIC code has no dependency on PCI The IRQ handling code requires pcidevs_lock to be held only for MSI interrupts. As the handling of which was now fully moved into msi.c (i.e. while applying fine without, the patch needs to be applied after the one titled "x86: split MSI IRQ chip"), io_apic.c now also doesn't need to include PCI headers anymore. Signed-off-by: Jan Beulich <jbeulich@suse.com> changeset: 23865:d6e01c7853cf user: Jan Beulich <jbeulich@suse.com> date: Thu Sep 22 18:29:19 2011 +0100 PCI multi-seg: config space accessor adjustments Signed-off-by: Jan Beulich <jbeulich@suse.com> changeset: 23864:314b147d524d user: Jan Beulich <jbeulich@suse.com> date: Thu Sep 22 18:28:38 2011 +0100 PCI multi-seg: Pass-through adjustments Signed-off-by: Jan Beulich <jbeulich@suse.com> changeset: 23863:9e0259239822 user: Jan Beulich <jbeulich@suse.com> date: Thu Sep 22 18:28:03 2011 +0100 PCI multi-seg: AMD-IOMMU specific adjustments There are two places here where it is entirely unclear to me where the necessary PCI segment number should be taken from (as IVMD descriptors don't have such, only IVHD ones do). AMD confirmed that for the time being it is acceptable to imply that only segment 0 exists. Signed-off-by: Jan Beulich <jbeulich@suse.com> changeset: 23862:85418e168527 user: Jan Beulich <jbeulich@suse.com> date: Thu Sep 22 18:27:26 2011 +0100 PCI multi-seg: VT-d specific adjustments Signed-off-by: Jan Beulich <jbeulich@suse.com> changeset: 23861:ec7c81fbe0de user: Jan Beulich <jbeulich@suse.com> date: Thu Sep 22 18:26:54 2011 +0100 PCI multi-seg: adjust domctl interface Again, a couple of directly related functions at once get adjusted to account for the segment number. Signed-off-by: Jan Beulich <jbeulich@suse.com> changeset: 23860:a422e2a4451e user: Jan Beulich <jbeulich@suse.com> date: Sun Sep 18 00:26:52 2011 +0100 x86: split MSI IRQ chip With the .end() accessor having become optional and noting that several of the accessors' behavior really depends on the result of msi_maskable_irq(), the splits the MSI IRQ chip type into two - one for the maskable ones, and the other for the (MSI only) non-maskable ones. At once the implementation of those methods gets moved from io_apic.c to msi.c. Signed-off-by: Jan Beulich <jbeulich@suse.com> ======================================== commit cd776ee9408ff127f934a707c1a339ee600bc127 Author: Ian Jackson <ian.jackson@eu.citrix.com> Date: Tue Jun 28 13:50:53 2011 +0100 qemu-char.c: fix incorrect CONFIG_STUBDOM handling qemu-char.c:1123:7: warning: "CONFIG_STUBDOM" is not defined [-Wundef] Signed-off-by: Olaf Hering <olaf@aepfle.de> Acked-by: Ian Jackson <ian.jackson@eu.citrix.com> _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel From xen-devel-bounces@lists.xensource.com Fri Sep 23 21:56:23 2011 Return-path: <xen-devel-bounces@lists.xensource.com> Envelope-to: www-data@lists.xensource.com Delivery-date: Fri, 23 Sep 2011 21:56:23 -0700 Received: from localhost ([127.0.0.1] helo=lists.colo.xensource.com) by lists.xensource.com with esmtp (Exim 4.43) id 1R7KHl-0002o1-9g; Fri, 23 Sep 2011 21:56:21 -0700 Received: from mail27.messagelabs.com ([193.109.254.147]) by lists.xensource.com with esmtp (Exim 4.43) id 1R7KGV-0002aI-Js for xen-devel@lists.xensource.com; Fri, 23 Sep 2011 21:55:04 -0700 X-Env-Sender: konrad@oracle.com X-Msg-Ref: server-4.tower-27.messagelabs.com!1316840080!41549051!1 X-Originating-IP: [141.146.126.227] X-StarScan-Version: 6.4.1; banners=-,-,- X-VirusChecked: Checked Received: (qmail 30887 invoked from network); 24 Sep 2011 04:54:41 -0000 Received: from acsinet15.oracle.com (HELO acsinet15.oracle.com) (141.146.126.227) by server-4.tower-27.messagelabs.com with DHE-RSA-AES256-SHA encrypted SMTP; 24 Sep 2011 04:54:41 -0000 Received: from rtcsinet21.oracle.com (rtcsinet21.oracle.com [66.248.204.29]) by acsinet15.oracle.com (Switch-3.4.4/Switch-3.4.4) with ESMTP id p8O4smFd022556 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Sat, 24 Sep 2011 04:54:57 GMT Received: from acsmt356.oracle.com (acsmt356.oracle.com [141.146.40.156]) by rtcsinet21.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id p8O28162011729 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sat, 24 Sep 2011 02:08:02 GMT Received: from abhmt112.oracle.com (abhmt112.oracle.com [141.146.116.64]) by acsmt356.oracle.com (8.12.11.20060308/8.12.11) with ESMTP id p8O27tNT002220; Fri, 23 Sep 2011 21:07:56 -0500 Received: from oracle.com (/209.6.55.207) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Fri, 23 Sep 2011 19:07:55 -0700 Received: by oracle.com (Postfix, from userid 1000) id 433C3520D; Fri, 23 Sep 2011 22:08:00 -0400 (EDT) Date: Fri, 23 Sep 2011 22:08:00 -0400 From: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com> To: David Vrabel <david.vrabel@citrix.com> Message-ID: <20110924020759.GA27796@phenom.oracle.com> References: <1316089768-22461-1-git-send-email-david.vrabel@citrix.com> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline In-Reply-To: <1316089768-22461-1-git-send-email-david.vrabel@citrix.com> User-Agent: Mutt/1.5.21 (2010-09-15) Content-Transfer-Encoding: quoted-printable X-Source-IP: rtcsinet21.oracle.com [66.248.204.29] X-CT-RefId: str=0001.0A090209.4E7D62A1.0096,ss=1,re=0.000,fgs=0 Cc: xen-devel@lists.xensource.com Subject: [Xen-devel] Re: xen: memory initialization/balloon fixes (#3) X-BeenThere: xen-devel@lists.xensource.com X-Mailman-Version: 2.1.5 Precedence: list List-Id: Xen developer discussion <xen-devel.lists.xensource.com> List-Unsubscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe> List-Post: <mailto:xen-devel@lists.xensource.com> List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help> List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=subscribe> Sender: xen-devel-bounces@lists.xensource.com Errors-To: xen-devel-bounces@lists.xensource.com On Thu, Sep 15, 2011 at 01:29:21PM +0100, David Vrabel wrote: > This set of patches fixes some bugs in the memory initialization under > Xen and in Xen's memory balloon driver. They can make 100s of MB of > additional RAM available (depending on the system/configuration). >=20 > Patch 1 is already applied. >=20 > Patch 2 fixes a bug in patch 1 and should be queued for 3.1 (and along > with patch 1 considered for 3.0 stable). >=20 > Patch 3 is a bug fix and should be queued for 3.1 and possibly > queued for the 3.0 stable tree. >=20 > Patches 5 & 6 increase the amount of low memory in 32 bit domains > started with < 1 GiB of RAM. Please queue for 3.2 >=20 > Patch 7 releases all pages in the initial allocation with PFNs that > lie within a 1-1 mapping. This seems correct to me as I think that > once the 1-1 mapping is set the MFN of the original page is lost so > it's no longer accessible by the kernel (and it cannot be used by > another domain >=20 > Changes since #2: >=20 > - New patch: xen: avoid adding non-existant memory if the reservation > is unlimited > - Avoid using a hypercall to get the current number of pages in the > ballon driver. Apparently the hypercall won't return the right > value if paging is used. > - Addresses Konrad's review comments. They don't work on AMD boxes: XELINUX 3.82 2009-06-09 Copyright (C) 1994-2009 H. Peter Anvin et al Loading xen.gz... ok Loading vmlinuz... ok Loading initramfs.cpio.gz... ok __ __ _ _ _ _ _ ___ __ _____ ___ =20 \ \/ /___ _ __ | || | / | / / |/ _ \ / /_|___ / / _ \=20 \ // _ \ '_ \ | || |_ | |__| | | | | | '_ \ |_ \| | | | / \ __/ | | | |__ _|| |__| | | |_| | (_) |__) | |_| | /_/\_\___|_| |_| |_|(_)_| |_|_|\___/ \___/____/ \___/=20 =20 (XEN) Xen version 4.1-110923 (konrad@dumpdata.com) (gcc version 4.4.4 201= 00503 (Red Hat 4.4.4-2) (GCC) ) Fri Sep 23 19:38:15 EDT 2011 (XEN) Latest ChangeSet: unavailable (XEN) Console output is synchronous. (XEN) Bootloader: unknown (XEN) Command line: com1=3D115200,8n1 console=3Dcom1,vga guest_loglvl=3Da= ll sync_console apic=3Ddebug (XEN) Video information: (XEN) VGA is text mode 80x25, font 8x16 (XEN) VBE/DDC methods: none; EDID transfer time: 2 seconds (XEN) EDID info not retrieved because no DDC retrieval method detected (XEN) Disc information: (XEN) Found 0 MBR signatures (XEN) Found 0 EDD information structures (XEN) Xen-e820 RAM map: (XEN) 0000000000000000 - 000000000009d800 (usable) (XEN) 000000000009d800 - 00000000000a0000 (reserved) (XEN) 00000000000cc000 - 0000000000100000 (reserved) (XEN) 0000000000100000 - 000000007fff0000 (usable) (XEN) 000000007fff0000 - 0000000080000000 (reserved) (XEN) 0000000080000000 - 00000000cfef0000 (usable) (XEN) 00000000cfef0000 - 00000000cfef5000 (ACPI data) (XEN) 00000000cfef5000 - 00000000cff7f000 (ACPI NVS) (XEN) 00000000cff80000 - 00000000d0000000 (reserved) (XEN) 00000000e0000000 - 00000000f0000000 (reserved) (XEN) 00000000fec00000 - 00000000fec10000 (reserved) (XEN) 00000000fee00000 - 00000000fee01000 (reserved) (XEN) 00000000fff80000 - 0000000100000000 (reserved) (XEN) 0000000100000000 - 0000000130000000 (usable) (XEN) ACPI: RSDP 000F79B0, 0024 (r2 PTLTD ) (XEN) ACPI: XSDT CFEF0753, 009C (r1 DELL PE_SC3 6040000 DELL = 0) (XEN) DELL PE_SC3 6040000 MSFT 100000E) (XEN) ACPI: FACS CFEF5FC0, 0040 (XEN) ACPI: TCPA CFEF3D53, 0032 (r1 Phoeni x 6040000 TL = 0) (XEN) ACPI: SLIC CFEF3D85, 0024 (r1 DELL PE_SC3 6040000 PTL = 1) (XEN) ACPI: SPCR CFEF3DA9, 0050 (r1 DELL PE_SC3 6040000 PTL = 1) (XEN) ACPI: EINJ CFEF3DF9, 01B0 (r1 PTL WHEAPTL 6040000 PTL = 1) (XEN) ACPI: HEST CFEF3FA9, 00A8 (r1 PTL WHEAPTL 6040000 PTL = 1) (XEN) ACPI: BERT CFEF4051, 0030 (r1 PTL WHEAPTL 6040000 PTL = 1) (XEN) ACPI: SSDT CFEF4081, 00E1 (r1 wheaos wheaosc 6040000 INTL 2005062= 4) (XEN) ACPI: ERST CFEF4162, 0270 (r1 PTL WHEAPTL 6040000 PTL = 1) (XEN) ACPI: SRAT CFEF43D2, 00E8 (r1 AMD HAMMER 6040000 AMD = 1) (XEN) ACPI: SSDT CFEF44BA, 0A30 (r1 AMD POWERNOW 6040000 AMD = 1) (XEN) ACPI: MCFG CFEF4EEA, 003C (r1 PTLTD MCFG 6040000 LTP = 0) (XEN) ACPI: HPET CFEF4F26, 0038 (r1 PTLTD HPETTBL 6040000 LTP = 1) (XEN) ACPI: APIC CFEF4F5E, 007A (r1 PTLTD APIC 6040000 LTP = 0) (XEN) ACPI: BOOT CFEF4FD8, 0028 (r1 PTLTD $SBFTBL$ 6040000 LTP = 1) (XEN) System RAM: 4094MB (4192756kB) (XEN) Domain heap initialised (XEN) Processor #0 0:2 APIC version 16 (XEN) Processor #1 0:2 APIC version 16 (XEN) Processor #2 0:2 APIC version 16 (XEN) Processor #3 0:2 APIC version 16 (XEN) IOAPIC[0]: apic_id 4, version 17, address 0xfec00000, GSI 0-23 (XEN) Enabling APIC mode: Flat. Using 1 I/O APICs (XEN) ERST table is invalid (XEN) Using scheduler: SMP Credit Scheduler (credit) (XEN) Detected 2109.743 MHz processor. (XEN) Initing memory sharing. (XEN) AMD-Vi: IOMMU not found! (XEN) I/O virtualisation disabled (XEN) ENABLING IO-APIC IRQs (XEN) -> Using new ACK method (XEN) Platform timer is 25.000MHz HPET =EF=BF=BD(XEN) Allocated console ring of 16 KiB. (XEN) HVM: ASIDs enabled. (XEN) SVM: Support(XEN) Brought up 4 CPUs (XEN) *** LOADING DOMAIN 0 *** (XEN) Xen kernel: 64-bit, lsb, compat32 (XEN) Dom0 kernel: 64-bit, PAE, lsb, paddr 0x1000000 -> 0x202f000 (XEN) PHYSICAL MEY ARRANGEMENT: (XEN) Dom0 alloc.: 0000000118000000->000000011c000000 (926244 pages to= be allocated) (XEN) Init. ramdisk: 00000001216cc000->000000012ffffc00 (XEN) VIRTUAL MEMORY ARRANGEMENT: (XEN) Loaded kernel: ffffffff81000000->ffffffff8202f000 (XEN) Init. ramdisk: ffffffff8202f000->ffffffff90962c00 (XEN) Phys-Mach map: ffffffff90963000->ffffffff91108ac0 (XEN) Start info: ffffffff91109000->ffffffff911094b4 (XEN) Page tables: ffffffff9110a000->ffffffff91197000 (XEN) Boot stack: ffffffff91197000->ffffffff91198000 (XEN) TOTAL: ffffffff80000000->ffffffff91400000 (XEN) ENTRY ADDRESS: ffffffff81aeb200 (XEN) Dom0 has maximum 4 VCPUs (XEN) Scrubbing Free RAM: .done. (XEN) Xen trace buffers: disabled (XEN) Std. Loglevel: Errors and warnings (XEN) Guest Loglevel: All (XEN) ********************************************** (XEN) ******* WARNING: CONSOLE OUTPUT IS SYNCHRONOUS (XEN) ******* This option is intended to aid debugging of Xen by ensuring (XEN) ******* that all output is synchronously delivered on the serial li= ne. (XEN) ******* However it can introduce SIGNIFICANT latencies and affect (XEN) ******* timekeeping. It is NOT recommended for production use! (XEN) ********************************************** (XEN) 3... 2... 1...=20 (XEN) Xen is relinquishing VGA console. (XEN) *** Serial input -> DOM0 (type 'CTRL-a' three times to switch input= to Xen) (XEN) Freed 228kB init memory. mapping kernel into physical memory Xen: setup ISA identity maps about to get started... and then it is just stuck.. This is v3.1-rc7 + your patches _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel From xen-devel-bounces@lists.xensource.com Fri Sep 23 21:58:17 2011 Return-path: <xen-devel-bounces@lists.xensource.com> Envelope-to: www-data@lists.xensource.com Delivery-date: Fri, 23 Sep 2011 21:58:17 -0700 Received: from localhost ([127.0.0.1] helo=lists.colo.xensource.com) by lists.xensource.com with esmtp (Exim 4.43) id 1R7KJb-0003DA-M3; Fri, 23 Sep 2011 21:58:15 -0700 Received: from mail21.messagelabs.com ([85.158.143.35]) by lists.xensource.com with esmtp (Exim 4.43) id 1R7KIO-0002vl-Da for xen-devel@lists.xensource.com; Fri, 23 Sep 2011 21:57:02 -0700 X-Env-Sender: konrad@oracle.com X-Msg-Ref: server-11.tower-21.messagelabs.com!1316840198!43780318!1 X-Originating-IP: [141.146.126.227] X-StarScan-Version: 6.4.1; banners=-,-,- X-VirusChecked: Checked Received: (qmail 10139 invoked from network); 24 Sep 2011 04:56:39 -0000 Received: from acsinet15.oracle.com (HELO acsinet15.oracle.com) (141.146.126.227) by server-11.tower-21.messagelabs.com with DHE-RSA-AES256-SHA encrypted SMTP; 24 Sep 2011 04:56:39 -0000 Received: from rtcsinet21.oracle.com (rtcsinet21.oracle.com [66.248.204.29]) by acsinet15.oracle.com (Switch-3.4.4/Switch-3.4.4) with ESMTP id p8O4ulgK027977 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Sat, 24 Sep 2011 04:56:53 GMT Received: from acsmt357.oracle.com (acsmt357.oracle.com [141.146.40.157]) by rtcsinet21.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id p8O2SXCa024007 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sat, 24 Sep 2011 02:28:34 GMT Received: from abhmt109.oracle.com (abhmt109.oracle.com [141.146.116.61]) by acsmt357.oracle.com (8.12.11.20060308/8.12.11) with ESMTP id p8O2SPPm021739; Fri, 23 Sep 2011 21:28:25 -0500 Received: from oracle.com (/209.6.55.207) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Fri, 23 Sep 2011 19:28:25 -0700 Received: by oracle.com (Postfix, from userid 1000) id EB1A41451; Fri, 23 Sep 2011 22:28:23 -0400 (EDT) From: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com> To: linux-kernel@vger.kernel.org, xen-devel@lists.xensource.com, jeremy@goop.org Date: Fri, 23 Sep 2011 22:28:18 -0400 Message-Id: <1316831299-4144-3-git-send-email-konrad.wilk@oracle.com> X-Mailer: git-send-email 1.7.4.1 In-Reply-To: <1316831299-4144-1-git-send-email-konrad.wilk@oracle.com> References: <1316831299-4144-1-git-send-email-konrad.wilk@oracle.com> X-Source-IP: rtcsinet21.oracle.com [66.248.204.29] X-CT-RefId: str=0001.0A090205.4E7D6315.014F,ss=1,re=0.000,fgs=0 Cc: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com> Subject: [Xen-devel] [PATCH 2/3] xen/p2m: Make debug/xen/mmu/p2m visible again. X-BeenThere: xen-devel@lists.xensource.com X-Mailman-Version: 2.1.5 Precedence: list List-Id: Xen developer discussion <xen-devel.lists.xensource.com> List-Unsubscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe> List-Post: <mailto:xen-devel@lists.xensource.com> List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help> List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=subscribe> Sender: xen-devel-bounces@lists.xensource.com Errors-To: xen-devel-bounces@lists.xensource.com We dropped a lot of the MMU debugfs in favour of using tracing API - but there is one which just provides mostly static information that was made invisible by this change. Bring it back. Signed-off-by: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com> --- arch/x86/include/asm/xen/page.h | 3 --- arch/x86/xen/mmu.c | 14 -------------- arch/x86/xen/p2m.c | 35 ++++++++++++++++++++++++++++++++--- 3 files changed, 32 insertions(+), 20 deletions(-) diff --git a/arch/x86/include/asm/xen/page.h b/arch/x86/include/asm/xen/page.h index 64a619d..bc12c12 100644 --- a/arch/x86/include/asm/xen/page.h +++ b/arch/x86/include/asm/xen/page.h @@ -53,9 +53,6 @@ extern int m2p_remove_override(struct page *page, bool clear_pte); extern struct page *m2p_find_override(unsigned long mfn); extern unsigned long m2p_find_override_pfn(unsigned long mfn, unsigned long pfn); -#ifdef CONFIG_XEN_DEBUG_FS -extern int p2m_dump_show(struct seq_file *m, void *v); -#endif static inline unsigned long pfn_to_mfn(unsigned long pfn) { unsigned long mfn; diff --git a/arch/x86/xen/mmu.c b/arch/x86/xen/mmu.c index 3c9aecd..4df0444 100644 --- a/arch/x86/xen/mmu.c +++ b/arch/x86/xen/mmu.c @@ -2362,17 +2362,3 @@ out: return err; } EXPORT_SYMBOL_GPL(xen_remap_domain_mfn_range); - -#ifdef CONFIG_XEN_DEBUG_FS -static int p2m_dump_open(struct inode *inode, struct file *filp) -{ - return single_open(filp, p2m_dump_show, NULL); -} - -static const struct file_operations p2m_dump_fops = { - .open = p2m_dump_open, - .read = seq_read, - .llseek = seq_lseek, - .release = single_release, -}; -#endif /* CONFIG_XEN_DEBUG_FS */ diff --git a/arch/x86/xen/p2m.c b/arch/x86/xen/p2m.c index 58efeb9..cc2f8dc 100644 --- a/arch/x86/xen/p2m.c +++ b/arch/x86/xen/p2m.c @@ -782,8 +782,9 @@ unsigned long m2p_find_override_pfn(unsigned long mfn, unsigned long pfn) EXPORT_SYMBOL_GPL(m2p_find_override_pfn); #ifdef CONFIG_XEN_DEBUG_FS - -int p2m_dump_show(struct seq_file *m, void *v) +#include <linux/debugfs.h> +#include "debugfs.h" +static int p2m_dump_show(struct seq_file *m, void *v) { static const char * const level_name[] = { "top", "middle", "entry", "abnormal" }; @@ -856,4 +857,32 @@ int p2m_dump_show(struct seq_file *m, void *v) #undef TYPE_PFN #undef TYPE_UNKNOWN } -#endif + +static int p2m_dump_open(struct inode *inode, struct file *filp) +{ + return single_open(filp, p2m_dump_show, NULL); +} + +static const struct file_operations p2m_dump_fops = { + .open = p2m_dump_open, + .read = seq_read, + .llseek = seq_lseek, + .release = single_release, +}; + +static struct dentry *d_mmu_debug; + +static int __init xen_p2m_debugfs(void) +{ + struct dentry *d_xen = xen_init_debugfs(); + + if (d_xen == NULL) + return -ENOMEM; + + d_mmu_debug = debugfs_create_dir("mmu", d_xen); + + debugfs_create_file("p2m", 0600, d_mmu_debug, NULL, &p2m_dump_fops); + return 0; +} +fs_initcall(xen_p2m_debugfs); +#endif /* CONFIG_XEN_DEBUG_FS */ -- 1.7.4.1 _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel From xen-devel-bounces@lists.xensource.com Fri Sep 23 22:04:30 2011 Return-path: <xen-devel-bounces@lists.xensource.com> Envelope-to: www-data@lists.xensource.com Delivery-date: Fri, 23 Sep 2011 22:04:30 -0700 Received: from localhost ([127.0.0.1] helo=lists.colo.xensource.com) by lists.xensource.com with esmtp (Exim 4.43) id 1R7KPd-0003k6-5k; Fri, 23 Sep 2011 22:04:29 -0700 Received: from mail182.messagelabs.com ([85.158.139.83]) by lists.xensource.com with esmtp (Exim 4.43) id 1R7KIV-0002yH-Dx for xen-devel@lists.xensource.com; Fri, 23 Sep 2011 21:57:07 -0700 X-Env-Sender: konrad@oracle.com X-Msg-Ref: server-8.tower-182.messagelabs.com!1316840222!18364673!1 X-Originating-IP: [148.87.113.117] X-StarScan-Version: 6.4.1; banners=-,-,- X-VirusChecked: Checked Received: (qmail 7013 invoked from network); 24 Sep 2011 04:57:04 -0000 Received: from rcsinet15.oracle.com (HELO rcsinet15.oracle.com) (148.87.113.117) by server-8.tower-182.messagelabs.com with DHE-RSA-AES256-SHA encrypted SMTP; 24 Sep 2011 04:57:04 -0000 Received: from rtcsinet22.oracle.com (rtcsinet22.oracle.com [66.248.204.30]) by rcsinet15.oracle.com (Switch-3.4.4/Switch-3.4.4) with ESMTP id p8O4u7rn027280 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Sat, 24 Sep 2011 04:57:00 GMT Received: from acsmt356.oracle.com (acsmt356.oracle.com [141.146.40.156]) by rtcsinet22.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id p8O2SXwH006650 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sat, 24 Sep 2011 02:28:34 GMT Received: from abhmt107.oracle.com (abhmt107.oracle.com [141.146.116.59]) by acsmt356.oracle.com (8.12.11.20060308/8.12.11) with ESMTP id p8O2SPOl010571; Fri, 23 Sep 2011 21:28:25 -0500 Received: from oracle.com (/209.6.55.207) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Fri, 23 Sep 2011 19:28:25 -0700 Received: by oracle.com (Postfix, from userid 1000) id E1A3110D8; Fri, 23 Sep 2011 22:28:23 -0400 (EDT) From: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com> To: linux-kernel@vger.kernel.org, xen-devel@lists.xensource.com, jeremy@goop.org Date: Fri, 23 Sep 2011 22:28:17 -0400 Message-Id: <1316831299-4144-2-git-send-email-konrad.wilk@oracle.com> X-Mailer: git-send-email 1.7.4.1 In-Reply-To: <1316831299-4144-1-git-send-email-konrad.wilk@oracle.com> References: <1316831299-4144-1-git-send-email-konrad.wilk@oracle.com> X-Source-IP: rtcsinet22.oracle.com [66.248.204.30] X-CT-RefId: str=0001.0A090208.4E7D631D.0069,ss=1,re=0.000,fgs=0 Cc: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com> Subject: [Xen-devel] [PATCH 1/3] Revert "xen/debug: WARN_ON when identity PFN has no _PAGE_IOMAP flag set." X-BeenThere: xen-devel@lists.xensource.com X-Mailman-Version: 2.1.5 Precedence: list List-Id: Xen developer discussion <xen-devel.lists.xensource.com> List-Unsubscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe> List-Post: <mailto:xen-devel@lists.xensource.com> List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help> List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=subscribe> Sender: xen-devel-bounces@lists.xensource.com Errors-To: xen-devel-bounces@lists.xensource.com We don' use it anymore and there are more false positives. This reverts commit fc25151d9ac7d809239fe68de0a1490b504bb94a. Signed-off-by: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com> --- arch/x86/xen/Kconfig | 8 -------- arch/x86/xen/mmu.c | 38 -------------------------------------- 2 files changed, 0 insertions(+), 46 deletions(-) diff --git a/arch/x86/xen/Kconfig b/arch/x86/xen/Kconfig index 5cc821c..ae559fe 100644 --- a/arch/x86/xen/Kconfig +++ b/arch/x86/xen/Kconfig @@ -49,11 +49,3 @@ config XEN_DEBUG_FS help Enable statistics output and various tuning options in debugfs. Enabling this option may incur a significant performance overhead. - -config XEN_DEBUG - bool "Enable Xen debug checks" - depends on XEN - default n - help - Enable various WARN_ON checks in the Xen MMU code. - Enabling this option WILL incur a significant performance overhead. diff --git a/arch/x86/xen/mmu.c b/arch/x86/xen/mmu.c index f987bde..3c9aecd 100644 --- a/arch/x86/xen/mmu.c +++ b/arch/x86/xen/mmu.c @@ -495,41 +495,6 @@ static pte_t xen_make_pte(pteval_t pte) } PV_CALLEE_SAVE_REGS_THUNK(xen_make_pte); -#ifdef CONFIG_XEN_DEBUG -pte_t xen_make_pte_debug(pteval_t pte) -{ - phys_addr_t addr = (pte & PTE_PFN_MASK); - phys_addr_t other_addr; - bool io_page = false; - pte_t _pte; - - if (pte & _PAGE_IOMAP) - io_page = true; - - _pte = xen_make_pte(pte); - - if (!addr) - return _pte; - - if (io_page && - (xen_initial_domain() || addr >= ISA_END_ADDRESS)) { - other_addr = pfn_to_mfn(addr >> PAGE_SHIFT) << PAGE_SHIFT; - WARN_ONCE(addr != other_addr, - "0x%lx is using VM_IO, but it is 0x%lx!\n", - (unsigned long)addr, (unsigned long)other_addr); - } else { - pteval_t iomap_set = (_pte.pte & PTE_FLAGS_MASK) & _PAGE_IOMAP; - other_addr = (_pte.pte & PTE_PFN_MASK); - WARN_ONCE((addr == other_addr) && (!io_page) && (!iomap_set), - "0x%lx is missing VM_IO (and wasn't fixed)!\n", - (unsigned long)addr); - } - - return _pte; -} -PV_CALLEE_SAVE_REGS_THUNK(xen_make_pte_debug); -#endif - static pgd_t xen_make_pgd(pgdval_t pgd) { pgd = pte_pfn_to_mfn(pgd); @@ -1988,9 +1953,6 @@ void __init xen_ident_map_ISA(void) static void __init xen_post_allocator_init(void) { -#ifdef CONFIG_XEN_DEBUG - pv_mmu_ops.make_pte = PV_CALLEE_SAVE(xen_make_pte_debug); -#endif pv_mmu_ops.set_pte = xen_set_pte; pv_mmu_ops.set_pmd = xen_set_pmd; pv_mmu_ops.set_pud = xen_set_pud; -- 1.7.4.1 _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel From xen-devel-bounces@lists.xensource.com Fri Sep 23 22:07:05 2011 Return-path: <xen-devel-bounces@lists.xensource.com> Envelope-to: www-data@lists.xensource.com Delivery-date: Fri, 23 Sep 2011 22:07:05 -0700 Received: from localhost ([127.0.0.1] helo=lists.colo.xensource.com) by lists.xensource.com with esmtp (Exim 4.43) id 1R7KS8-00048C-Mn; Fri, 23 Sep 2011 22:07:04 -0700 Received: from mail174.messagelabs.com ([85.158.138.51]) by lists.xensource.com with esmtp (Exim 4.43) id 1R7KJD-00037u-A5 for xen-devel@lists.xensource.com; Fri, 23 Sep 2011 21:57:52 -0700 X-Env-Sender: konrad@oracle.com X-Msg-Ref: server-8.tower-174.messagelabs.com!1316840266!18885352!1 X-Originating-IP: [141.146.126.227] X-StarScan-Version: 6.4.1; banners=-,-,- X-VirusChecked: Checked Received: (qmail 6313 invoked from network); 24 Sep 2011 04:57:47 -0000 Received: from acsinet15.oracle.com (HELO acsinet15.oracle.com) (141.146.126.227) by server-8.tower-174.messagelabs.com with DHE-RSA-AES256-SHA encrypted SMTP; 24 Sep 2011 04:57:47 -0000 Received: from rtcsinet21.oracle.com (rtcsinet21.oracle.com [66.248.204.29]) by acsinet15.oracle.com (Switch-3.4.4/Switch-3.4.4) with ESMTP id p8O4v7Lq028991 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Sat, 24 Sep 2011 04:57:43 GMT Received: from acsmt358.oracle.com (acsmt358.oracle.com [141.146.40.158]) by rtcsinet21.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id p8O2SX6p024011 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sat, 24 Sep 2011 02:28:34 GMT Received: from abhmt108.oracle.com (abhmt108.oracle.com [141.146.116.60]) by acsmt358.oracle.com (8.12.11.20060308/8.12.11) with ESMTP id p8O2SPiw007312; Fri, 23 Sep 2011 21:28:25 -0500 Received: from oracle.com (/209.6.55.207) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Fri, 23 Sep 2011 19:28:25 -0700 Received: by oracle.com (Postfix, from userid 1000) id F207E14EC; Fri, 23 Sep 2011 22:28:23 -0400 (EDT) From: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com> To: linux-kernel@vger.kernel.org, xen-devel@lists.xensource.com, jeremy@goop.org Date: Fri, 23 Sep 2011 22:28:19 -0400 Message-Id: <1316831299-4144-4-git-send-email-konrad.wilk@oracle.com> X-Mailer: git-send-email 1.7.4.1 In-Reply-To: <1316831299-4144-1-git-send-email-konrad.wilk@oracle.com> References: <1316831299-4144-1-git-send-email-konrad.wilk@oracle.com> X-Source-IP: rtcsinet21.oracle.com [66.248.204.29] X-CT-RefId: str=0001.0A090205.4E7D6348.004D,ss=1,re=0.000,fgs=0 Cc: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com> Subject: [Xen-devel] [PATCH 3/3] xen/p2m: Use SetPagePrivate and its friends for M2P overrides. X-BeenThere: xen-devel@lists.xensource.com X-Mailman-Version: 2.1.5 Precedence: list List-Id: Xen developer discussion <xen-devel.lists.xensource.com> List-Unsubscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe> List-Post: <mailto:xen-devel@lists.xensource.com> List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help> List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=subscribe> Sender: xen-devel-bounces@lists.xensource.com Errors-To: xen-devel-bounces@lists.xensource.com We use the page->private field and hence should use the proper macros and set proper bits. Also WARN_ON in case somebody tries to overwrite our data. Signed-off-by: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com> --- arch/x86/xen/p2m.c | 10 ++++++---- 1 files changed, 6 insertions(+), 4 deletions(-) diff --git a/arch/x86/xen/p2m.c b/arch/x86/xen/p2m.c index cc2f8dc..6e56b65 100644 --- a/arch/x86/xen/p2m.c +++ b/arch/x86/xen/p2m.c @@ -692,8 +692,9 @@ int m2p_add_override(unsigned long mfn, struct page *page, bool clear_pte) "m2p_add_override: pfn %lx not mapped", pfn)) return -EINVAL; } - - page->private = mfn; + WARN_ON(PagePrivate(page)); + SetPagePrivate(page); + set_page_private(page, mfn); page->index = pfn_to_mfn(pfn); if (unlikely(!set_phys_to_machine(pfn, FOREIGN_FRAME(mfn)))) @@ -736,7 +737,8 @@ int m2p_remove_override(struct page *page, bool clear_pte) list_del(&page->lru); spin_unlock_irqrestore(&m2p_override_lock, flags); set_phys_to_machine(pfn, page->index); - + WARN_ON(!PagePrivate(page)); + ClearPagePrivate(page); if (clear_pte && !PageHighMem(page)) set_pte_at(&init_mm, address, ptep, pfn_pte(pfn, PAGE_KERNEL)); @@ -758,7 +760,7 @@ struct page *m2p_find_override(unsigned long mfn) spin_lock_irqsave(&m2p_override_lock, flags); list_for_each_entry(p, bucket, lru) { - if (p->private == mfn) { + if (page_private(p) == mfn) { ret = p; break; } -- 1.7.4.1 _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel From xen-devel-bounces@lists.xensource.com Fri Sep 23 22:08:37 2011 Return-path: <xen-devel-bounces@lists.xensource.com> Envelope-to: www-data@lists.xensource.com Delivery-date: Fri, 23 Sep 2011 22:08:37 -0700 Received: from localhost ([127.0.0.1] helo=lists.colo.xensource.com) by lists.xensource.com with esmtp (Exim 4.43) id 1R7KTc-0004VE-7r; Fri, 23 Sep 2011 22:08:37 -0700 Received: from mail174.messagelabs.com ([85.158.138.51]) by lists.xensource.com with esmtp (Exim 4.43) id 1R7KLr-0003P0-OZ for xen-devel@lists.xensource.com; Fri, 23 Sep 2011 22:00:46 -0700 X-Env-Sender: konrad@oracle.com X-Msg-Ref: server-13.tower-174.messagelabs.com!1316840427!32583224!1 X-Originating-IP: [141.146.126.227] X-StarScan-Version: 6.4.1; banners=-,-,- X-VirusChecked: Checked Received: (qmail 29778 invoked from network); 24 Sep 2011 05:00:28 -0000 Received: from acsinet15.oracle.com (HELO acsinet15.oracle.com) (141.146.126.227) by server-13.tower-174.messagelabs.com with DHE-RSA-AES256-SHA encrypted SMTP; 24 Sep 2011 05:00:28 -0000 Received: from acsinet21.oracle.com (acsinet21.oracle.com [141.146.126.237]) by acsinet15.oracle.com (Switch-3.4.4/Switch-3.4.4) with ESMTP id p8O500fN001693 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Sat, 24 Sep 2011 05:00:25 GMT Received: from acsmt356.oracle.com (acsmt356.oracle.com [141.146.40.156]) by acsinet21.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id p8O2SX9h004790 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sat, 24 Sep 2011 02:28:33 GMT Received: from abhmt112.oracle.com (abhmt112.oracle.com [141.146.116.64]) by acsmt356.oracle.com (8.12.11.20060308/8.12.11) with ESMTP id p8O2SPuV010570; Fri, 23 Sep 2011 21:28:25 -0500 Received: from oracle.com (/209.6.55.207) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Fri, 23 Sep 2011 19:28:25 -0700 Received: by oracle.com (Postfix, from userid 1000) id DC93713A1; Fri, 23 Sep 2011 22:28:23 -0400 (EDT) From: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com> To: linux-kernel@vger.kernel.org, xen-devel@lists.xensource.com, jeremy@goop.org Date: Fri, 23 Sep 2011 22:28:16 -0400 Message-Id: <1316831299-4144-1-git-send-email-konrad.wilk@oracle.com> X-Mailer: git-send-email 1.7.4.1 X-Source-IP: acsinet21.oracle.com [141.146.126.237] X-Auth-Type: Internal IP X-CT-RefId: str=0001.0A020203.4E7D63EA.0020:SCFMA922111,ss=1,re=-4.000,fgs=0 Cc: Subject: [Xen-devel] [PATCH] Xen MMU fixes for 3.2 (v1) X-BeenThere: xen-devel@lists.xensource.com X-Mailman-Version: 2.1.5 Precedence: list List-Id: Xen developer discussion <xen-devel.lists.xensource.com> List-Unsubscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe> List-Post: <mailto:xen-devel@lists.xensource.com> List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help> List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=subscribe> Sender: xen-devel-bounces@lists.xensource.com Errors-To: xen-devel-bounces@lists.xensource.com I am proposing these three patches for 3.2. [PATCH 1/3] Revert "xen/debug: WARN_ON when identity PFN has no _PAGE_IOMAP flag set." .. which just removes code that was meant there to be for some releases to check if we forgot something. And it looks like we have covered all the boundary cases for the 1-1 identity pages. [PATCH 2/3] xen/p2m: Make debug/xen/mmu/p2m visible again. .. was removed in v3.0 by the Xen MMU tracing updated by mistake. Puts it back in. [PATCH 3/3] xen/p2m: Use SetPagePrivate and its friends for M2P overrides. .. and will now warn us if somebody has overwritten the MFN of the 'struct page' (of the pages that are in the M2P override) and also use the appropiate macros. arch/x86/include/asm/xen/page.h | 3 -- arch/x86/xen/Kconfig | 8 ------ arch/x86/xen/mmu.c | 52 --------------------------------------- arch/x86/xen/p2m.c | 45 ++++++++++++++++++++++++++++----- 4 files changed, 38 insertions(+), 70 deletions(-) _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel From xen-devel-bounces@lists.xensource.com Fri Sep 23 22:10:10 2011 Return-path: <xen-devel-bounces@lists.xensource.com> Envelope-to: www-data@lists.xensource.com Delivery-date: Fri, 23 Sep 2011 22:10:10 -0700 Received: from localhost ([127.0.0.1] helo=lists.colo.xensource.com) by lists.xensource.com with esmtp (Exim 4.43) id 1R7KV8-0004t0-Mn; Fri, 23 Sep 2011 22:10:10 -0700 Received: from mail174.messagelabs.com ([85.158.138.51]) by lists.xensource.com with esmtp (Exim 4.43) id 1R7KSC-00048T-BP for xen-devel@lists.xensource.com; Fri, 23 Sep 2011 22:07:09 -0700 X-Env-Sender: Ian.Jackson@eu.citrix.com X-Msg-Ref: server-11.tower-174.messagelabs.com!1316840825!32559399!1 X-Originating-IP: [62.200.22.115] X-StarScan-Version: 6.4.1; banners=-,-,- X-VirusChecked: Checked Received: (qmail 17365 invoked from network); 24 Sep 2011 05:07:05 -0000 Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115) by server-11.tower-174.messagelabs.com with RC4-SHA encrypted SMTP; 24 Sep 2011 05:07:05 -0000 X-IronPort-AV: E=Sophos;i="4.68,434,1312156800"; d="scan'208";a="8039372" Received: from lonpmailmx01.citrite.net ([10.30.203.162]) by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5; 24 Sep 2011 05:07:04 +0000 Received: from woking.xci-test.com (10.80.248.135) by smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id 8.3.137.0; Sat, 24 Sep 2011 06:07:04 +0100 Received: from osstest by woking.xci-test.com with local (Exim 4.69) (envelope-from <ian.jackson@eu.citrix.com>) id 1R7KS8-0004Fd-8h; Sat, 24 Sep 2011 06:07:04 +0100 To: <xen-devel@lists.xensource.com> Message-ID: <osstest-9064-mainreport@xen.org> From: xen.org <ian.jackson@eu.citrix.com> Date: Sat, 24 Sep 2011 06:07:04 +0100 MIME-Version: 1.0 Content-Type: text/plain Cc: ian.jackson@eu.citrix.com Subject: [Xen-devel] [linux test] 9064: tolerable FAIL X-BeenThere: xen-devel@lists.xensource.com X-Mailman-Version: 2.1.5 Precedence: list List-Id: Xen developer discussion <xen-devel.lists.xensource.com> List-Unsubscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe> List-Post: <mailto:xen-devel@lists.xensource.com> List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help> List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=subscribe> Sender: xen-devel-bounces@lists.xensource.com Errors-To: xen-devel-bounces@lists.xensource.com flight 9064 linux real [real] http://www.chiark.greenend.org.uk/~xensrcts/logs/9064/ Failures :-/ but no regressions. Tests which are failing intermittently (not blocking): test-amd64-amd64-xl-sedf 14 guest-localmigrate/x10 fail pass in 9060 Tests which did not succeed, but are not blocking, including regressions (tests previously passed) regarded as allowable: test-amd64-amd64-xl-pcipt-intel 9 guest-start fail never pass test-amd64-i386-rhel6hvm-amd 9 guest-start.2 fail never pass test-amd64-i386-rhel6hvm-intel 9 guest-start.2 fail never pass test-amd64-i386-win-vcpus1 16 leak-check/check fail never pass test-amd64-i386-xl-win-vcpus1 13 guest-stop fail never pass test-amd64-amd64-win 16 leak-check/check fail never pass test-amd64-amd64-xl-win 13 guest-stop fail never pass test-i386-i386-win 16 leak-check/check fail never pass test-i386-i386-xl-win 13 guest-stop fail never pass test-amd64-i386-win 16 leak-check/check fail never pass version targeted for testing: linux 6bec8b4a4c14095d0b7ce424db9d583c3decae6c baseline version: linux 1c3f03ccc5258887f5f2cafc0836a865834f9205 ------------------------------------------------------------ People who touched revisions under test: Jeremy Fitzhardinge <jeremy.fitzhardinge@citrix.com> ------------------------------------------------------------ jobs: build-amd64 pass build-i386 pass build-amd64-pvops pass build-i386-pvops pass test-amd64-amd64-xl pass test-amd64-i386-xl pass test-i386-i386-xl pass test-amd64-i386-rhel6hvm-amd fail test-amd64-i386-xl-credit2 pass test-amd64-amd64-xl-pcipt-intel fail test-amd64-i386-rhel6hvm-intel fail test-amd64-i386-xl-multivcpu pass test-amd64-amd64-pair pass test-amd64-i386-pair pass test-i386-i386-pair pass test-amd64-amd64-pv pass test-amd64-i386-pv pass test-i386-i386-pv pass test-amd64-amd64-xl-sedf fail test-amd64-i386-win-vcpus1 fail test-amd64-i386-xl-win-vcpus1 fail test-amd64-amd64-win fail test-amd64-i386-win fail test-i386-i386-win fail test-amd64-amd64-xl-win fail test-i386-i386-xl-win fail ------------------------------------------------------------ sg-report-flight on woking.cam.xci-test.com logs: /home/xc_osstest/logs images: /home/xc_osstest/images Logs, config files, etc. are available at http://www.chiark.greenend.org.uk/~xensrcts/logs Test harness code can be found at http://xenbits.xensource.com/gitweb?p=osstest.git;a=summary Pushing revision : + branch=linux + revision=6bec8b4a4c14095d0b7ce424db9d583c3decae6c + . cri-lock-repos ++ . cri-common +++ umask 002 +++ getconfig Repos +++ perl -e ' use Osstest; readconfigonly(); print $c{Repos} or die $!; ' ++ repos=/export/home/osstest/repos ++ repos_lock=/export/home/osstest/repos/lock ++ '[' x '!=' x/export/home/osstest/repos/lock ']' ++ OSSTEST_REPOS_LOCK_LOCKED=/export/home/osstest/repos/lock ++ exec with-lock-ex -w /export/home/osstest/repos/lock ./ap-push linux 6bec8b4a4c14095d0b7ce424db9d583c3decae6c + branch=linux + revision=6bec8b4a4c14095d0b7ce424db9d583c3decae6c + . cri-lock-repos ++ . cri-common +++ umask 002 +++ getconfig Repos +++ perl -e ' use Osstest; readconfigonly(); print $c{Repos} or die $!; ' ++ repos=/export/home/osstest/repos ++ repos_lock=/export/home/osstest/repos/lock ++ '[' x/export/home/osstest/repos/lock '!=' x/export/home/osstest/repos/lock ']' + : xen@xenbits.xensource.com + : xen@xenbits.xensource.com:git/linux-pvops + : master + : tested/2.6.39.x + case "$branch" in + cd /export/home/osstest/repos/xen ./ap-push: line 20: cd: /export/home/osstest/repos/xen: No such file or directory ------------------------------------------------------------ commit 6bec8b4a4c14095d0b7ce424db9d583c3decae6c Author: Jeremy Fitzhardinge <jeremy.fitzhardinge@citrix.com> Date: Fri Sep 2 12:23:22 2011 -0700 Revert "xen/apic: Provide an 'apic_xen' to set the override the apic->[read|write] for all cases." This reverts commit c3dd7941354fa96a71f2613e2c7a1b215fa175dc. It prevents the kernel from booting natively on hardware. Conflicts: arch/x86/xen/enlighten.c Signed-off-by: Jeremy Fitzhardinge <jeremy.fitzhardinge@citrix.com> _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel From xen-devel-bounces@lists.xensource.com Sat Sep 24 01:15:25 2011 Return-path: <xen-devel-bounces@lists.xensource.com> Envelope-to: www-data@lists.xensource.com Delivery-date: Sat, 24 Sep 2011 01:15:25 -0700 Received: from localhost ([127.0.0.1] helo=lists.colo.xensource.com) by lists.xensource.com with esmtp (Exim 4.43) id 1R7NOP-00017D-4X; Sat, 24 Sep 2011 01:15:25 -0700 Received: from mail21.messagelabs.com ([85.158.143.35]) by lists.xensource.com with esmtp (Exim 4.43) id 1R7NNX-0000uZ-0H; Sat, 24 Sep 2011 01:14:31 -0700 X-Env-Sender: Ian.Campbell@eu.citrix.com X-Msg-Ref: server-4.tower-21.messagelabs.com!1316852031!61421787!1 X-Originating-IP: [62.200.22.115] X-StarScan-Version: 6.4.1; banners=-,-,- X-VirusChecked: Checked Received: (qmail 14013 invoked from network); 24 Sep 2011 08:13:51 -0000 Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115) by server-4.tower-21.messagelabs.com with RC4-SHA encrypted SMTP; 24 Sep 2011 08:13:51 -0000 X-IronPort-AV: E=Sophos;i="4.68,434,1312156800"; d="scan'208";a="8040002" Received: from lonpmailmx01.citrite.net ([10.30.203.162]) by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5; 24 Sep 2011 08:14:27 +0000 Received: from [127.0.0.1] (10.80.16.67) by smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id 8.3.137.0; Sat, 24 Sep 2011 09:14:27 +0100 Subject: Re: [Xen-devel] Xen document day (Oct 12 or 26) From: Ian Campbell <Ian.Campbell@citrix.com> To: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com> In-Reply-To: <20110922174002.GA1205@phenom.oracle.com> References: <20110922130618.GA13238@phenom.oracle.com> <CAFLBxZaAaXTUtW5+VkxPnr_MR0fbW+d1Mzu4y0x=gEOaX9e0OQ@mail.gmail.com> <20110922174002.GA1205@phenom.oracle.com> Content-Type: text/plain; charset="ISO-8859-1" Organization: Citrix Systems, Inc. Date: Sat, 24 Sep 2011 09:14:26 +0100 Message-ID: <1316852066.27431.15.camel@dagon.hellion.org.uk> MIME-Version: 1.0 X-Mailer: Evolution 2.32.3 Content-Transfer-Encoding: 7bit Cc: George Dunlap <George.Dunlap@eu.citrix.com>, "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>, "xen-users@lists.xensource.com" <xen-users@lists.xensource.com> X-BeenThere: xen-devel@lists.xensource.com X-Mailman-Version: 2.1.5 Precedence: list List-Id: Xen developer discussion <xen-devel.lists.xensource.com> List-Unsubscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe> List-Post: <mailto:xen-devel@lists.xensource.com> List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help> List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=subscribe> Sender: xen-devel-bounces@lists.xensource.com Errors-To: xen-devel-bounces@lists.xensource.com On Thu, 2011-09-22 at 18:40 +0100, Konrad Rzeszutek Wilk wrote: > On Thu, Sep 22, 2011 at 05:32:46PM +0100, George Dunlap wrote: > > Another thing that needs to be done is to write man pages for xl, and > > update the man pages for xm to indicate that it is deprecated. > > So: > > 1). PDF/section > 2). Wiki > 3). man page for xl/xm > 4). HOWTO, docs in xen.hg/docs > 5). Convert said HOWTO, docs in Markdown. Another thing which came up which I'd like to do was setting up doxygen (or something similar, recommendations greatfully received) for xen/include/public to allow us to document the hypercall interface inline, with the intention of replacing interface.tex with something we might actually maintain. > > Who wants to do what? I created a sign up sheet: > > https://docs.google.com/spreadsheet/ccc?key=0Aj5ukWh4htwMdEFLVWpjRmx3VXdETDExNlByamd4Rmc&hl=en_US > > in case folks want to get an idea of who is doing what and not > step on each toes. We should have a specific IRC channel on the day too (e.g. #xen-documentathon on freenode). > > > > > We also discussed the idea of moving some of the documentation and the > > HOWTOs into the xen.hg/docs folder, preferrably in a nice language > > like Markdown, so that we can enforce changes in documentation with > > changes code. I propose using Markdown, if no one has a better idea. > > Which pretty much looks like writting normal text files per > http://en.wikipedia.org/wiki/Markdown description. > > :-) > > > > -George > > > > On Thu, Sep 22, 2011 at 2:06 PM, Konrad Rzeszutek Wilk > > <konrad.wilk@oracle.com> wrote: > > > Part of what we brainstormed at Xen Hackathon was what we could do make Xen easier. > > > > > > And the one thing that seemed to surface up was making the docs better - either > > > be the Wiki or the three .pdfs that get created/shipped with Xen. > > > > > > One thought was to come up with a Documention Day - where volunteers would try to > > > fix up some portion of the documentation that they feel they have > > > a good grasp of knowledge off and are willing to change (and also look > > > to be incorrect) > > > > > > What do you guys think of Oct 12th or Oct 26 as a day for this? > > > > > > And then the next question - what page/pdf section interests you? > > > > > > http://bits.xensource.com/Xen/docs/user.pdf > > > http://www.rites.uic.edu/~solworth/xenInterfaceManual.pdf [the one on Xen.org is an older version] > > > > > > Or Wiki pages: > > > http://wiki.xensource.com/xenwiki/ > > > > > > http://wiki.xensource.com/xenwiki/XenDom0Kernels > > > http://wiki.xensource.com/xenwiki/XenSerialConsole > > > http://wiki.xensource.com/xenwiki/XenParavirtOps > > > http://wiki.xensource.com/xenwiki/XenCommonProblems > > > > > > http://wiki.xensource.com/xenwiki/Consulting > > > http://wiki.xensource.com/xenwiki/Consultants > > > http://wiki.xensource.com/xenwiki/VpsHostingWithXen > > > > > > http://wiki.xen.org/xenwiki/XenPCIpassthrough > > > http://wiki.xen.org/xenwiki/VTdHowTo > > > > > > _______________________________________________ > > > Xen-devel mailing list > > > Xen-devel@lists.xensource.com > > > http://lists.xensource.com/xen-devel > > > > > > > _______________________________________________ > > Xen-devel mailing list > > Xen-devel@lists.xensource.com > > http://lists.xensource.com/xen-devel > > _______________________________________________ > Xen-devel mailing list > Xen-devel@lists.xensource.com > http://lists.xensource.com/xen-devel _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel From xen-devel-bounces@lists.xensource.com Sat Sep 24 04:12:50 2011 Return-path: <xen-devel-bounces@lists.xensource.com> Envelope-to: www-data@lists.xensource.com Delivery-date: Sat, 24 Sep 2011 04:12:50 -0700 Received: from localhost ([127.0.0.1] helo=lists.colo.xensource.com) by lists.xensource.com with esmtp (Exim 4.43) id 1R7QA5-000771-N4; Sat, 24 Sep 2011 04:12:49 -0700 Received: from mail216.messagelabs.com ([85.158.143.99]) by lists.xensource.com with esmtp (Exim 4.43) id 1R7Q99-0006uY-Fk for xen-devel@lists.xensource.com; Sat, 24 Sep 2011 04:11:58 -0700 X-Env-Sender: javier.manzano@edu.uah.es X-Msg-Ref: server-14.tower-216.messagelabs.com!1316862707!19442495!1 X-Originating-IP: [216.139.236.26] X-StarScan-Version: 6.4.1; banners=-,-,- X-VirusChecked: Checked Received: (qmail 27142 invoked from network); 24 Sep 2011 11:11:48 -0000 Received: from sam.nabble.com (HELO sam.nabble.com) (216.139.236.26) by server-14.tower-216.messagelabs.com with AES256-SHA encrypted SMTP; 24 Sep 2011 11:11:48 -0000 Received: from [192.168.236.26] (helo=sam.nabble.com) by sam.nabble.com with esmtp (Exim 4.72) (envelope-from <javier.manzano@edu.uah.es>) id 1R7Q94-0000HX-F4 for xen-devel@lists.xensource.com; Sat, 24 Sep 2011 04:11:46 -0700 Date: Sat, 24 Sep 2011 04:11:46 -0700 (PDT) From: JavMV <javier.manzano@edu.uah.es> To: xen-devel@lists.xensource.com Message-ID: <1316862706461-4836389.post@n5.nabble.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Subject: [Xen-devel] VT-d Stop working after XEN update X-BeenThere: xen-devel@lists.xensource.com X-Mailman-Version: 2.1.5 Precedence: list List-Id: Xen developer discussion <xen-devel.lists.xensource.com> List-Unsubscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe> List-Post: <mailto:xen-devel@lists.xensource.com> List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help> List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=subscribe> Sender: xen-devel-bounces@lists.xensource.com Errors-To: xen-devel-bounces@lists.xensource.com Hello, I was trying to achieve VGA-passthrough but I have encountered a problem enabling VT-d on Xen-unstable, I was able to use it in the past with the changeset 23350 but if I use the changeset 23799 or greater this feature is automatically disabled, so there must be some changes between those two changesets that provokes VT-d crash on my computer. Details below: -Mother board: Intel DQ35MP. -Bios version 1143 (the latest version available, it is from 2010). -Options VT Technology and VT for directed I/O (VT-d) are enabled. -Using the option iommu=force in grub entry '# xm dmesg' output with *changeset 23799*: (XEN) [VT-D]dmar.c:456: Non-existent device (0:2.1) is reported in this DRHD\047s scope! (XEN) [VT-D]dmar.c:479: The DRHD is invalid due to there are devices under its scope are not PCI discoverable! Pls try option iommu=force or iommu=workaround_bios_bug if you really want VT-d (XEN) Failed to parse ACPI DMAR. Disabling VT-d. (XEN) Table is not found! (XEN) Using ACPI (MADT) for SMP configuration information ... (XEN) I/O virtualisation disabled ... (XEN) HVM: ASIDs disabled. (XEN) HVM: VMX enabled '# xm dmesg' output with *changeset 23350*: ... (XEN) Intel VT-d Snoop Control not enabled. (XEN) Intel VT-d Dom0 DMA Passthrough not enabled. (XEN) Intel VT-d Queued Invalidation not enabled. (XEN) Intel VT-d Interrupt Remapping not enabled. (XEN) [VT-D]iommu.c:847: iommu_fault_status: Fault Overflow (XEN) [VT-D]iommu.c:850: iommu_fault_status: Primary Pending Fault (XEN) [VT-D]iommu.c:825: DMAR:[DMA Write] Request device [00:02.0] fault addr ffffff000, iommu reg = fff16000 ... (XEN) Enabling APIC mode: Flat. Using 1 I/O APICs (XEN) I/O virtualisation enabled I can see I/O enabled but all the VT-d features are disabled, so maybe that's why with the last revision of XEN I can't have I/O virtualisation enabled. Am I still able to use vga-passthru with this kind of output? Thanks in advance Javier ----- JavMV -- View this message in context: http://xen.1045712.n5.nabble.com/VT-d-Stop-working-after-XEN-update-tp4836389p4836389.html Sent from the Xen - Dev mailing list archive at Nabble.com. _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel From xen-devel-bounces@lists.xensource.com Sat Sep 24 06:37:51 2011 Return-path: <xen-devel-bounces@lists.xensource.com> Envelope-to: www-data@lists.xensource.com Delivery-date: Sat, 24 Sep 2011 06:37:51 -0700 Received: from localhost ([127.0.0.1] helo=lists.colo.xensource.com) by lists.xensource.com with esmtp (Exim 4.43) id 1R7SQQ-00040g-9x; Sat, 24 Sep 2011 06:37:50 -0700 Received: from mail182.messagelabs.com ([85.158.139.83]) by lists.xensource.com with esmtp (Exim 4.43) id 1R7SPi-0003nX-36 for xen-devel@lists.xensource.com; Sat, 24 Sep 2011 06:37:06 -0700 X-Env-Sender: Ian.Jackson@eu.citrix.com X-Msg-Ref: server-2.tower-182.messagelabs.com!1316871422!18582198!1 X-Originating-IP: [62.200.22.115] X-StarScan-Version: 6.4.1; banners=-,-,- X-VirusChecked: Checked Received: (qmail 30813 invoked from network); 24 Sep 2011 13:37:03 -0000 Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115) by server-2.tower-182.messagelabs.com with RC4-SHA encrypted SMTP; 24 Sep 2011 13:37:03 -0000 X-IronPort-AV: E=Sophos;i="4.68,435,1312156800"; d="scan'208";a="8041428" Received: from lonpmailmx01.citrite.net ([10.30.203.162]) by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5; 24 Sep 2011 13:37:02 +0000 Received: from woking.xci-test.com (10.80.248.135) by smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id 8.3.137.0; Sat, 24 Sep 2011 14:37:02 +0100 Received: from osstest by woking.xci-test.com with local (Exim 4.69) (envelope-from <ian.jackson@eu.citrix.com>) id 1R7SPd-0006Jo-TT; Sat, 24 Sep 2011 14:37:01 +0100 To: xen-devel@lists.xensource.com Message-ID: <osstest-9065-mainreport@xen.org> From: xen.org <ian.jackson@eu.citrix.com> Date: Sat, 24 Sep 2011 14:37:01 +0100 MIME-Version: 1.0 Content-Type: text/plain Cc: ian.jackson@eu.citrix.com Subject: [Xen-devel] [xen-unstable test] 9065: regressions - FAIL X-BeenThere: xen-devel@lists.xensource.com X-Mailman-Version: 2.1.5 Precedence: list List-Id: Xen developer discussion <xen-devel.lists.xensource.com> List-Unsubscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe> List-Post: <mailto:xen-devel@lists.xensource.com> List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help> List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=subscribe> Sender: xen-devel-bounces@lists.xensource.com Errors-To: xen-devel-bounces@lists.xensource.com flight 9065 xen-unstable real [real] http://www.chiark.greenend.org.uk/~xensrcts/logs/9065/ Regressions :-( Tests which did not succeed and are blocking: test-amd64-i386-rhel6hvm-amd 5 xen-boot fail REGR. vs. 8995 Tests which are failing intermittently (not blocking): test-amd64-amd64-xl-sedf 5 xen-boot fail pass in 9063 test-amd64-i386-xl-multivcpu 5 xen-boot fail pass in 9061 test-amd64-i386-xl-credit2 5 xen-boot fail pass in 9063 test-i386-i386-xl 5 xen-boot fail pass in 9063 test-i386-i386-win 5 xen-boot fail pass in 9063 test-amd64-amd64-win 5 xen-boot fail pass in 9063 test-amd64-i386-win-vcpus1 5 xen-boot fail pass in 9061 test-amd64-amd64-xl-win 5 xen-boot fail pass in 9063 test-amd64-amd64-xl 5 xen-boot fail in 9063 pass in 9065 test-i386-i386-pv 5 xen-boot fail in 9063 pass in 9065 test-amd64-amd64-pv 5 xen-boot fail in 9063 pass in 9065 test-amd64-i386-xl-win-vcpus1 5 xen-boot fail in 9063 pass in 9065 test-i386-i386-xl-win 5 xen-boot fail in 9063 pass in 9065 test-amd64-amd64-pair 7 xen-boot/src_host fail in 9063 pass in 9065 test-amd64-amd64-pair 8 xen-boot/dst_host fail in 9063 pass in 9065 test-amd64-i386-win 5 xen-boot fail in 9063 pass in 9065 test-amd64-i386-pv 5 xen-boot fail in 9061 pass in 9065 test-i386-i386-pair 8 xen-boot/dst_host fail in 9061 pass in 9065 test-i386-i386-pair 7 xen-boot/src_host fail in 9061 pass in 9065 Tests which did not succeed, but are not blocking, including regressions (tests previously passed) regarded as allowable: test-amd64-amd64-xl-pcipt-intel 9 guest-start fail never pass test-amd64-i386-rhel6hvm-intel 9 guest-start.2 fail never pass test-amd64-i386-xl-win-vcpus1 13 guest-stop fail never pass test-i386-i386-xl-win 13 guest-stop fail never pass test-amd64-i386-win 16 leak-check/check fail never pass test-i386-i386-win 16 leak-check/check fail in 9063 never pass test-amd64-amd64-win 16 leak-check/check fail in 9063 never pass test-amd64-amd64-xl-win 13 guest-stop fail in 9063 never pass test-amd64-i386-win-vcpus1 16 leak-check/check fail in 9061 never pass version targeted for testing: xen cc339ab1d917 baseline version: xen a422e2a4451e ------------------------------------------------------------ People who touched revisions under test: Andreas Herrmann <herrmann.der.user@googlemail.com> Ian Campbell <ian.campbell@citrix.com> Ian Jackson <ian.jackson@eu.citrix.com> Jan Beulich <jbeulich@suse.com> Lasse Collin <lasse.collin@tukaani.org> Olaf Hering <olaf@aepfle.de> Thomas Renninger <trenn@suse.de> ------------------------------------------------------------ jobs: build-amd64 pass build-i386 pass build-amd64-oldkern pass build-i386-oldkern pass build-amd64-pvops pass build-i386-pvops pass test-amd64-amd64-xl pass test-amd64-i386-xl pass test-i386-i386-xl fail test-amd64-i386-rhel6hvm-amd fail test-amd64-i386-xl-credit2 fail test-amd64-amd64-xl-pcipt-intel fail test-amd64-i386-rhel6hvm-intel fail test-amd64-i386-xl-multivcpu fail test-amd64-amd64-pair pass test-amd64-i386-pair pass test-i386-i386-pair pass test-amd64-amd64-pv pass test-amd64-i386-pv pass test-i386-i386-pv pass test-amd64-amd64-xl-sedf fail test-amd64-i386-win-vcpus1 fail test-amd64-i386-xl-win-vcpus1 fail test-amd64-amd64-win fail test-amd64-i386-win fail test-i386-i386-win fail test-amd64-amd64-xl-win fail test-i386-i386-xl-win fail ------------------------------------------------------------ sg-report-flight on woking.cam.xci-test.com logs: /home/xc_osstest/logs images: /home/xc_osstest/images Logs, config files, etc. are available at http://www.chiark.greenend.org.uk/~xensrcts/logs Test harness code can be found at http://xenbits.xensource.com/gitweb?p=osstest.git;a=summary Not pushing. ------------------------------------------------------------ changeset: 23872:cc339ab1d917 tag: tip user: Ian Campbell <ian.campbell@citrix.com> date: Thu Sep 22 18:37:06 2011 +0100 tools: fix install of lomount $(BIN) went away in 23124:e3d4c34b14a3. Also there are no *.so, *.a or *.rpm built in here Signed-off-by: Ian Campbell <ian.campbell@citrix.com> changeset: 23871:503ee256fecf user: Jan Beulich <jbeulich@suse.com> date: Thu Sep 22 18:35:30 2011 +0100 x86: ucode-amd: Don't warn when no ucode is available for a CPU revision This patch originally comes from the Linus mainline kernel (2.6.33), find below the patch details: From: Andreas Herrmann <herrmann.der.user@googlemail.com> There is no point in warning when there is no ucode available for a specific CPU revision. Currently the container-file, which provides the AMD ucode patches for OS load, contains only a few ucode patches. It's already clearly indicated by the printed patch_level whenever new ucode was available and an update happened. So the warning message is of no help but rather annoying on systems with many CPUs. Signed-off-by: Thomas Renninger <trenn@suse.de> Signed-off-by: Jan Beulich <jbeulich@suse.com> changeset: 23870:5c97b02f48fc user: Jan Beulich <jbeulich@suse.com> date: Thu Sep 22 18:34:27 2011 +0100 XZ: Fix incorrect XZ_BUF_ERROR From: Lasse Collin <lasse.collin@tukaani.org> xz_dec_run() could incorrectly return XZ_BUF_ERROR if all of the following was true: - The caller knows how many bytes of output to expect and only provides that much output space. - When the last output bytes are decoded, the caller-provided input buffer ends right before the LZMA2 end of payload marker. So LZMA2 won't provide more output anymore, but it won't know it yet and thus won't return XZ_STREAM_END yet. - A BCJ filter is in use and it hasn't left any unfiltered bytes in the temp buffer. This can happen with any BCJ filter, but in practice it's more likely with filters other than the x86 BCJ. This fixes <https://bugzilla.redhat.com/show_bug.cgi?id=3D735408> where Squashfs thinks that a valid file system is corrupt. This also fixes a similar bug in single-call mode where the uncompressed size of a block using BCJ + LZMA2 was 0 bytes and caller provided no output space. Many empty .xz files don't contain any blocks and thus don't trigger this bug. This also tweaks a closely related detail: xz_dec_bcj_run() could call xz_dec_lzma2_run() to decode into temp buffer when it was known to be useless. This was harmless although it wasted a minuscule number of CPU cycles. Signed-off-by: Lasse Collin <lasse.collin@tukaani.org> Signed-off-by: Jan Beulich <jbeulich@suse.com> changeset: 23869:db1ea4b127cd user: Jan Beulich <jbeulich@suse.com> date: Thu Sep 22 18:33:48 2011 +0100 XZ decompressor: Fix decoding of empty LZMA2 streams From: Lasse Collin <lasse.collin@tukaani.org> The old code considered valid empty LZMA2 streams to be corrupt. Note that a typical empty .xz file has no LZMA2 data at all, and thus most .xz files having no uncompressed data are handled correctly even without this fix. Signed-off-by: Lasse Collin <lasse.collin@tukaani.org> Signed-off-by: Jan Beulich <jbeulich@suse.com> changeset: 23868:28147fd781af user: Jan Beulich <jbeulich@suse.com> date: Thu Sep 22 18:32:34 2011 +0100 VT-d: fix off-by-one error in RMRR validation (base_addr,end_addr) is an inclusive range, and hence there shouldn't be a subtraction of 1 in the second invocation of page_is_ram_type(). For RMRRs covering a single page that actually resulted in the immediately preceding page to get checked (which could have resulted in a false warning). Signed-off-by: Jan Beulich <jbeulich@suse.com> changeset: 23867:571b6e90dfb4 user: Jan Beulich <jbeulich@suse.com> date: Thu Sep 22 18:31:44 2011 +0100 VT-d: eliminate a mis-use of pcidevs_lock dma_pte_clear_one() shouldn't acquire this global lock for the purpose of processing a per-domain list. Furthermore the function a few lines earlier has a comment stating that acquiring pcidevs_lock isn't necessary here (whether that's really correct is another question). Use the domain's mappin_lock instead to protect the mapped_rmrrs list. Fold domain_rmrr_mapped() into its sole caller so that the otherwise implicit dependency on pcidevs_lock there becomes more obvious (see the comment there). Signed-off-by: Jan Beulich <jbeulich@suse.com> changeset: 23866:47ec1d405af9 user: Jan Beulich <jbeulich@suse.com> date: Thu Sep 22 18:31:02 2011 +0100 x86: IO-APIC code has no dependency on PCI The IRQ handling code requires pcidevs_lock to be held only for MSI interrupts. As the handling of which was now fully moved into msi.c (i.e. while applying fine without, the patch needs to be applied after the one titled "x86: split MSI IRQ chip"), io_apic.c now also doesn't need to include PCI headers anymore. Signed-off-by: Jan Beulich <jbeulich@suse.com> changeset: 23865:d6e01c7853cf user: Jan Beulich <jbeulich@suse.com> date: Thu Sep 22 18:29:19 2011 +0100 PCI multi-seg: config space accessor adjustments Signed-off-by: Jan Beulich <jbeulich@suse.com> changeset: 23864:314b147d524d user: Jan Beulich <jbeulich@suse.com> date: Thu Sep 22 18:28:38 2011 +0100 PCI multi-seg: Pass-through adjustments Signed-off-by: Jan Beulich <jbeulich@suse.com> changeset: 23863:9e0259239822 user: Jan Beulich <jbeulich@suse.com> date: Thu Sep 22 18:28:03 2011 +0100 PCI multi-seg: AMD-IOMMU specific adjustments There are two places here where it is entirely unclear to me where the necessary PCI segment number should be taken from (as IVMD descriptors don't have such, only IVHD ones do). AMD confirmed that for the time being it is acceptable to imply that only segment 0 exists. Signed-off-by: Jan Beulich <jbeulich@suse.com> changeset: 23862:85418e168527 user: Jan Beulich <jbeulich@suse.com> date: Thu Sep 22 18:27:26 2011 +0100 PCI multi-seg: VT-d specific adjustments Signed-off-by: Jan Beulich <jbeulich@suse.com> changeset: 23861:ec7c81fbe0de user: Jan Beulich <jbeulich@suse.com> date: Thu Sep 22 18:26:54 2011 +0100 PCI multi-seg: adjust domctl interface Again, a couple of directly related functions at once get adjusted to account for the segment number. Signed-off-by: Jan Beulich <jbeulich@suse.com> changeset: 23860:a422e2a4451e user: Jan Beulich <jbeulich@suse.com> date: Sun Sep 18 00:26:52 2011 +0100 x86: split MSI IRQ chip With the .end() accessor having become optional and noting that several of the accessors' behavior really depends on the result of msi_maskable_irq(), the splits the MSI IRQ chip type into two - one for the maskable ones, and the other for the (MSI only) non-maskable ones. At once the implementation of those methods gets moved from io_apic.c to msi.c. Signed-off-by: Jan Beulich <jbeulich@suse.com> ======================================== commit cd776ee9408ff127f934a707c1a339ee600bc127 Author: Ian Jackson <ian.jackson@eu.citrix.com> Date: Tue Jun 28 13:50:53 2011 +0100 qemu-char.c: fix incorrect CONFIG_STUBDOM handling qemu-char.c:1123:7: warning: "CONFIG_STUBDOM" is not defined [-Wundef] Signed-off-by: Olaf Hering <olaf@aepfle.de> Acked-by: Ian Jackson <ian.jackson@eu.citrix.com> _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel From xen-devel-bounces@lists.xensource.com Sat Sep 24 08:03:39 2011 Return-path: <xen-devel-bounces@lists.xensource.com> Envelope-to: www-data@lists.xensource.com Delivery-date: Sat, 24 Sep 2011 08:03:39 -0700 Received: from localhost ([127.0.0.1] helo=lists.colo.xensource.com) by lists.xensource.com with esmtp (Exim 4.43) id 1R7TlT-0006Fi-2e; Sat, 24 Sep 2011 08:03:39 -0700 Received: from mail21.messagelabs.com ([85.158.143.35]) by lists.xensource.com with esmtp (Exim 4.43) id 1R7Tkh-00063T-G5 for xen-devel@lists.xensource.com; Sat, 24 Sep 2011 08:02:51 -0700 X-Env-Sender: Ian.Jackson@eu.citrix.com X-Msg-Ref: server-14.tower-21.messagelabs.com!1316876559!60821293!1 X-Originating-IP: [62.200.22.115] X-StarScan-Version: 6.4.1; banners=-,-,- X-VirusChecked: Checked Received: (qmail 28793 invoked from network); 24 Sep 2011 15:02:39 -0000 Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115) by server-14.tower-21.messagelabs.com with RC4-SHA encrypted SMTP; 24 Sep 2011 15:02:39 -0000 X-IronPort-AV: E=Sophos;i="4.68,435,1312156800"; d="scan'208";a="8041757" Received: from lonpmailmx01.citrite.net ([10.30.203.162]) by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5; 24 Sep 2011 15:02:47 +0000 Received: from woking.xci-test.com (10.80.248.135) by smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id 8.3.137.0; Sat, 24 Sep 2011 16:02:47 +0100 Received: from osstest by woking.xci-test.com with local (Exim 4.69) (envelope-from <ian.jackson@eu.citrix.com>) id 1R7Tka-0003Z5-QR; Sat, 24 Sep 2011 16:02:45 +0100 To: xen-devel@lists.xensource.com Message-ID: <osstest-9066-mainreport@xen.org> From: xen.org <ian.jackson@eu.citrix.com> Date: Sat, 24 Sep 2011 16:02:44 +0100 MIME-Version: 1.0 Content-Type: text/plain Cc: ian.jackson@eu.citrix.com Subject: [Xen-devel] [linux test] 9066: tolerable FAIL X-BeenThere: xen-devel@lists.xensource.com X-Mailman-Version: 2.1.5 Precedence: list List-Id: Xen developer discussion <xen-devel.lists.xensource.com> List-Unsubscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe> List-Post: <mailto:xen-devel@lists.xensource.com> List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help> List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=subscribe> Sender: xen-devel-bounces@lists.xensource.com Errors-To: xen-devel-bounces@lists.xensource.com flight 9066 linux real [real] http://www.chiark.greenend.org.uk/~xensrcts/logs/9066/ Failures :-/ but no regressions. Tests which are failing intermittently (not blocking): test-amd64-amd64-xl-sedf 14 guest-localmigrate/x10 fail pass in 9060 Tests which did not succeed, but are not blocking, including regressions (tests previously passed) regarded as allowable: test-amd64-amd64-xl-pcipt-intel 9 guest-start fail never pass test-amd64-i386-rhel6hvm-amd 9 guest-start.2 fail never pass test-amd64-i386-rhel6hvm-intel 9 guest-start.2 fail never pass test-amd64-i386-win-vcpus1 16 leak-check/check fail never pass test-amd64-i386-xl-win-vcpus1 13 guest-stop fail never pass test-amd64-amd64-win 16 leak-check/check fail never pass test-amd64-amd64-xl-win 13 guest-stop fail never pass test-i386-i386-win 16 leak-check/check fail never pass test-i386-i386-xl-win 13 guest-stop fail never pass test-amd64-i386-win 16 leak-check/check fail never pass version targeted for testing: linux 6bec8b4a4c14095d0b7ce424db9d583c3decae6c baseline version: linux 1c3f03ccc5258887f5f2cafc0836a865834f9205 ------------------------------------------------------------ People who touched revisions under test: Jeremy Fitzhardinge <jeremy.fitzhardinge@citrix.com> ------------------------------------------------------------ jobs: build-amd64 pass build-i386 pass build-amd64-pvops pass build-i386-pvops pass test-amd64-amd64-xl pass test-amd64-i386-xl pass test-i386-i386-xl pass test-amd64-i386-rhel6hvm-amd fail test-amd64-i386-xl-credit2 pass test-amd64-amd64-xl-pcipt-intel fail test-amd64-i386-rhel6hvm-intel fail test-amd64-i386-xl-multivcpu pass test-amd64-amd64-pair pass test-amd64-i386-pair pass test-i386-i386-pair pass test-amd64-amd64-pv pass test-amd64-i386-pv pass test-i386-i386-pv pass test-amd64-amd64-xl-sedf fail test-amd64-i386-win-vcpus1 fail test-amd64-i386-xl-win-vcpus1 fail test-amd64-amd64-win fail test-amd64-i386-win fail test-i386-i386-win fail test-amd64-amd64-xl-win fail test-i386-i386-xl-win fail ------------------------------------------------------------ sg-report-flight on woking.cam.xci-test.com logs: /home/xc_osstest/logs images: /home/xc_osstest/images Logs, config files, etc. are available at http://www.chiark.greenend.org.uk/~xensrcts/logs Test harness code can be found at http://xenbits.xensource.com/gitweb?p=osstest.git;a=summary Pushing revision : + branch=linux + revision=6bec8b4a4c14095d0b7ce424db9d583c3decae6c + . cri-lock-repos ++ . cri-common +++ umask 002 +++ getconfig Repos +++ perl -e ' use Osstest; readconfigonly(); print $c{Repos} or die $!; ' ++ repos=/export/home/osstest/repos ++ repos_lock=/export/home/osstest/repos/lock ++ '[' x '!=' x/export/home/osstest/repos/lock ']' ++ OSSTEST_REPOS_LOCK_LOCKED=/export/home/osstest/repos/lock ++ exec with-lock-ex -w /export/home/osstest/repos/lock ./ap-push linux 6bec8b4a4c14095d0b7ce424db9d583c3decae6c + branch=linux + revision=6bec8b4a4c14095d0b7ce424db9d583c3decae6c + . cri-lock-repos ++ . cri-common +++ umask 002 +++ getconfig Repos +++ perl -e ' use Osstest; readconfigonly(); print $c{Repos} or die $!; ' ++ repos=/export/home/osstest/repos ++ repos_lock=/export/home/osstest/repos/lock ++ '[' x/export/home/osstest/repos/lock '!=' x/export/home/osstest/repos/lock ']' + : xen@xenbits.xensource.com + : xen@xenbits.xensource.com:git/linux-pvops + : master + : tested/2.6.39.x + case "$branch" in + cd /export/home/osstest/repos/xen ./ap-push: line 20: cd: /export/home/osstest/repos/xen: No such file or directory ------------------------------------------------------------ commit 6bec8b4a4c14095d0b7ce424db9d583c3decae6c Author: Jeremy Fitzhardinge <jeremy.fitzhardinge@citrix.com> Date: Fri Sep 2 12:23:22 2011 -0700 Revert "xen/apic: Provide an 'apic_xen' to set the override the apic->[read|write] for all cases." This reverts commit c3dd7941354fa96a71f2613e2c7a1b215fa175dc. It prevents the kernel from booting natively on hardware. Conflicts: arch/x86/xen/enlighten.c Signed-off-by: Jeremy Fitzhardinge <jeremy.fitzhardinge@citrix.com> _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel From xen-devel-bounces@lists.xensource.com Sat Sep 24 09:47:11 2011 Return-path: <xen-devel-bounces@lists.xensource.com> Envelope-to: www-data@lists.xensource.com Delivery-date: Sat, 24 Sep 2011 09:47:11 -0700 Received: from localhost ([127.0.0.1] helo=lists.colo.xensource.com) by lists.xensource.com with esmtp (Exim 4.43) id 1R7VNe-0001U9-Vh; Sat, 24 Sep 2011 09:47:11 -0700 Received: from mail174.messagelabs.com ([85.158.138.51]) by lists.xensource.com with esmtp (Exim 4.43) id 1R7VMQ-00014Y-ED for xen-devel@lists.xensource.com; Sat, 24 Sep 2011 09:45:57 -0700 X-Env-Sender: Ian.Jackson@eu.citrix.com X-Msg-Ref: server-11.tower-174.messagelabs.com!1316882750!32607555!1 X-Originating-IP: [62.200.22.115] X-StarScan-Version: 6.4.1; banners=-,-,- X-VirusChecked: Checked Received: (qmail 32193 invoked from network); 24 Sep 2011 16:45:51 -0000 Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115) by server-11.tower-174.messagelabs.com with RC4-SHA encrypted SMTP; 24 Sep 2011 16:45:51 -0000 X-IronPort-AV: E=Sophos;i="4.68,435,1312156800"; d="scan'208";a="8042264" Received: from lonpmailmx01.citrite.net ([10.30.203.162]) by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5; 24 Sep 2011 16:45:50 +0000 Received: from woking.xci-test.com (10.80.248.135) by smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id 8.3.137.0; Sat, 24 Sep 2011 17:45:50 +0100 Received: from osstest by woking.xci-test.com with local (Exim 4.69) (envelope-from <ian.jackson@eu.citrix.com>) id 1R7VML-00083A-NW; Sat, 24 Sep 2011 17:45:49 +0100 To: <xen-devel@lists.xensource.com> Message-ID: <osstest-9067-mainreport@xen.org> From: xen.org <ian.jackson@eu.citrix.com> Date: Sat, 24 Sep 2011 17:45:49 +0100 MIME-Version: 1.0 Content-Type: text/plain Cc: ian.jackson@eu.citrix.com Subject: [Xen-devel] [xen-unstable test] 9067: regressions - FAIL X-BeenThere: xen-devel@lists.xensource.com X-Mailman-Version: 2.1.5 Precedence: list List-Id: Xen developer discussion <xen-devel.lists.xensource.com> List-Unsubscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe> List-Post: <mailto:xen-devel@lists.xensource.com> List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help> List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=subscribe> Sender: xen-devel-bounces@lists.xensource.com Errors-To: xen-devel-bounces@lists.xensource.com flight 9067 xen-unstable real [real] http://www.chiark.greenend.org.uk/~xensrcts/logs/9067/ Regressions :-( Tests which did not succeed and are blocking: test-amd64-i386-rhel6hvm-amd 5 xen-boot fail REGR. vs. 8995 Tests which are failing intermittently (not blocking): test-amd64-i386-pv 5 xen-boot fail pass in 9065 test-amd64-amd64-xl 5 xen-boot fail pass in 9065 test-amd64-amd64-pv 5 xen-boot fail pass in 9065 test-amd64-i386-xl-multivcpu 5 xen-boot fail pass in 9061 test-amd64-i386-xl-credit2 5 xen-boot fail pass in 9063 test-amd64-i386-xl 5 xen-boot fail pass in 9065 test-i386-i386-xl 5 xen-boot fail pass in 9063 test-amd64-i386-xl-win-vcpus1 5 xen-boot fail pass in 9065 test-amd64-i386-win-vcpus1 5 xen-boot fail pass in 9061 test-amd64-i386-win 5 xen-boot fail pass in 9065 test-amd64-amd64-xl-win 5 xen-boot fail pass in 9063 test-amd64-amd64-xl-sedf 5 xen-boot fail in 9065 pass in 9067 test-amd64-amd64-win 5 xen-boot fail in 9065 pass in 9067 test-i386-i386-win 5 xen-boot fail in 9065 pass in 9067 test-i386-i386-pv 5 xen-boot fail in 9061 pass in 9067 test-i386-i386-xl-win 5 xen-boot fail in 9061 pass in 9067 test-i386-i386-pair 8 xen-boot/dst_host fail in 9061 pass in 9067 test-i386-i386-pair 7 xen-boot/src_host fail in 9061 pass in 9067 test-amd64-amd64-pair 7 xen-boot/src_host fail in 9063 pass in 9067 test-amd64-amd64-pair 8 xen-boot/dst_host fail in 9063 pass in 9067 Tests which did not succeed, but are not blocking, including regressions (tests previously passed) regarded as allowable: test-amd64-amd64-xl-pcipt-intel 9 guest-start fail never pass test-amd64-i386-rhel6hvm-intel 9 guest-start.2 fail never pass test-i386-i386-xl-win 13 guest-stop fail never pass test-amd64-amd64-win 16 leak-check/check fail never pass test-i386-i386-win 16 leak-check/check fail never pass test-amd64-i386-xl-win-vcpus1 13 guest-stop fail in 9065 never pass test-amd64-i386-win 16 leak-check/check fail in 9065 never pass test-amd64-i386-win-vcpus1 16 leak-check/check fail in 9061 never pass test-amd64-amd64-xl-win 13 guest-stop fail in 9063 never pass version targeted for testing: xen cc339ab1d917 baseline version: xen a422e2a4451e ------------------------------------------------------------ People who touched revisions under test: Andreas Herrmann <herrmann.der.user@googlemail.com> Ian Campbell <ian.campbell@citrix.com> Ian Jackson <ian.jackson@eu.citrix.com> Jan Beulich <jbeulich@suse.com> Lasse Collin <lasse.collin@tukaani.org> Olaf Hering <olaf@aepfle.de> Thomas Renninger <trenn@suse.de> ------------------------------------------------------------ jobs: build-amd64 pass build-i386 pass build-amd64-oldkern pass build-i386-oldkern pass build-amd64-pvops pass build-i386-pvops pass test-amd64-amd64-xl fail test-amd64-i386-xl fail test-i386-i386-xl fail test-amd64-i386-rhel6hvm-amd fail test-amd64-i386-xl-credit2 fail test-amd64-amd64-xl-pcipt-intel fail test-amd64-i386-rhel6hvm-intel fail test-amd64-i386-xl-multivcpu fail test-amd64-amd64-pair pass test-amd64-i386-pair pass test-i386-i386-pair pass test-amd64-amd64-pv fail test-amd64-i386-pv fail test-i386-i386-pv pass test-amd64-amd64-xl-sedf pass test-amd64-i386-win-vcpus1 fail test-amd64-i386-xl-win-vcpus1 fail test-amd64-amd64-win fail test-amd64-i386-win fail test-i386-i386-win fail test-amd64-amd64-xl-win fail test-i386-i386-xl-win fail ------------------------------------------------------------ sg-report-flight on woking.cam.xci-test.com logs: /home/xc_osstest/logs images: /home/xc_osstest/images Logs, config files, etc. are available at http://www.chiark.greenend.org.uk/~xensrcts/logs Test harness code can be found at http://xenbits.xensource.com/gitweb?p=osstest.git;a=summary Not pushing. ------------------------------------------------------------ changeset: 23872:cc339ab1d917 tag: tip user: Ian Campbell <ian.campbell@citrix.com> date: Thu Sep 22 18:37:06 2011 +0100 tools: fix install of lomount $(BIN) went away in 23124:e3d4c34b14a3. Also there are no *.so, *.a or *.rpm built in here Signed-off-by: Ian Campbell <ian.campbell@citrix.com> changeset: 23871:503ee256fecf user: Jan Beulich <jbeulich@suse.com> date: Thu Sep 22 18:35:30 2011 +0100 x86: ucode-amd: Don't warn when no ucode is available for a CPU revision This patch originally comes from the Linus mainline kernel (2.6.33), find below the patch details: From: Andreas Herrmann <herrmann.der.user@googlemail.com> There is no point in warning when there is no ucode available for a specific CPU revision. Currently the container-file, which provides the AMD ucode patches for OS load, contains only a few ucode patches. It's already clearly indicated by the printed patch_level whenever new ucode was available and an update happened. So the warning message is of no help but rather annoying on systems with many CPUs. Signed-off-by: Thomas Renninger <trenn@suse.de> Signed-off-by: Jan Beulich <jbeulich@suse.com> changeset: 23870:5c97b02f48fc user: Jan Beulich <jbeulich@suse.com> date: Thu Sep 22 18:34:27 2011 +0100 XZ: Fix incorrect XZ_BUF_ERROR From: Lasse Collin <lasse.collin@tukaani.org> xz_dec_run() could incorrectly return XZ_BUF_ERROR if all of the following was true: - The caller knows how many bytes of output to expect and only provides that much output space. - When the last output bytes are decoded, the caller-provided input buffer ends right before the LZMA2 end of payload marker. So LZMA2 won't provide more output anymore, but it won't know it yet and thus won't return XZ_STREAM_END yet. - A BCJ filter is in use and it hasn't left any unfiltered bytes in the temp buffer. This can happen with any BCJ filter, but in practice it's more likely with filters other than the x86 BCJ. This fixes <https://bugzilla.redhat.com/show_bug.cgi?id=3D735408> where Squashfs thinks that a valid file system is corrupt. This also fixes a similar bug in single-call mode where the uncompressed size of a block using BCJ + LZMA2 was 0 bytes and caller provided no output space. Many empty .xz files don't contain any blocks and thus don't trigger this bug. This also tweaks a closely related detail: xz_dec_bcj_run() could call xz_dec_lzma2_run() to decode into temp buffer when it was known to be useless. This was harmless although it wasted a minuscule number of CPU cycles. Signed-off-by: Lasse Collin <lasse.collin@tukaani.org> Signed-off-by: Jan Beulich <jbeulich@suse.com> changeset: 23869:db1ea4b127cd user: Jan Beulich <jbeulich@suse.com> date: Thu Sep 22 18:33:48 2011 +0100 XZ decompressor: Fix decoding of empty LZMA2 streams From: Lasse Collin <lasse.collin@tukaani.org> The old code considered valid empty LZMA2 streams to be corrupt. Note that a typical empty .xz file has no LZMA2 data at all, and thus most .xz files having no uncompressed data are handled correctly even without this fix. Signed-off-by: Lasse Collin <lasse.collin@tukaani.org> Signed-off-by: Jan Beulich <jbeulich@suse.com> changeset: 23868:28147fd781af user: Jan Beulich <jbeulich@suse.com> date: Thu Sep 22 18:32:34 2011 +0100 VT-d: fix off-by-one error in RMRR validation (base_addr,end_addr) is an inclusive range, and hence there shouldn't be a subtraction of 1 in the second invocation of page_is_ram_type(). For RMRRs covering a single page that actually resulted in the immediately preceding page to get checked (which could have resulted in a false warning). Signed-off-by: Jan Beulich <jbeulich@suse.com> changeset: 23867:571b6e90dfb4 user: Jan Beulich <jbeulich@suse.com> date: Thu Sep 22 18:31:44 2011 +0100 VT-d: eliminate a mis-use of pcidevs_lock dma_pte_clear_one() shouldn't acquire this global lock for the purpose of processing a per-domain list. Furthermore the function a few lines earlier has a comment stating that acquiring pcidevs_lock isn't necessary here (whether that's really correct is another question). Use the domain's mappin_lock instead to protect the mapped_rmrrs list. Fold domain_rmrr_mapped() into its sole caller so that the otherwise implicit dependency on pcidevs_lock there becomes more obvious (see the comment there). Signed-off-by: Jan Beulich <jbeulich@suse.com> changeset: 23866:47ec1d405af9 user: Jan Beulich <jbeulich@suse.com> date: Thu Sep 22 18:31:02 2011 +0100 x86: IO-APIC code has no dependency on PCI The IRQ handling code requires pcidevs_lock to be held only for MSI interrupts. As the handling of which was now fully moved into msi.c (i.e. while applying fine without, the patch needs to be applied after the one titled "x86: split MSI IRQ chip"), io_apic.c now also doesn't need to include PCI headers anymore. Signed-off-by: Jan Beulich <jbeulich@suse.com> changeset: 23865:d6e01c7853cf user: Jan Beulich <jbeulich@suse.com> date: Thu Sep 22 18:29:19 2011 +0100 PCI multi-seg: config space accessor adjustments Signed-off-by: Jan Beulich <jbeulich@suse.com> changeset: 23864:314b147d524d user: Jan Beulich <jbeulich@suse.com> date: Thu Sep 22 18:28:38 2011 +0100 PCI multi-seg: Pass-through adjustments Signed-off-by: Jan Beulich <jbeulich@suse.com> changeset: 23863:9e0259239822 user: Jan Beulich <jbeulich@suse.com> date: Thu Sep 22 18:28:03 2011 +0100 PCI multi-seg: AMD-IOMMU specific adjustments There are two places here where it is entirely unclear to me where the necessary PCI segment number should be taken from (as IVMD descriptors don't have such, only IVHD ones do). AMD confirmed that for the time being it is acceptable to imply that only segment 0 exists. Signed-off-by: Jan Beulich <jbeulich@suse.com> changeset: 23862:85418e168527 user: Jan Beulich <jbeulich@suse.com> date: Thu Sep 22 18:27:26 2011 +0100 PCI multi-seg: VT-d specific adjustments Signed-off-by: Jan Beulich <jbeulich@suse.com> changeset: 23861:ec7c81fbe0de user: Jan Beulich <jbeulich@suse.com> date: Thu Sep 22 18:26:54 2011 +0100 PCI multi-seg: adjust domctl interface Again, a couple of directly related functions at once get adjusted to account for the segment number. Signed-off-by: Jan Beulich <jbeulich@suse.com> changeset: 23860:a422e2a4451e user: Jan Beulich <jbeulich@suse.com> date: Sun Sep 18 00:26:52 2011 +0100 x86: split MSI IRQ chip With the .end() accessor having become optional and noting that several of the accessors' behavior really depends on the result of msi_maskable_irq(), the splits the MSI IRQ chip type into two - one for the maskable ones, and the other for the (MSI only) non-maskable ones. At once the implementation of those methods gets moved from io_apic.c to msi.c. Signed-off-by: Jan Beulich <jbeulich@suse.com> ======================================== commit cd776ee9408ff127f934a707c1a339ee600bc127 Author: Ian Jackson <ian.jackson@eu.citrix.com> Date: Tue Jun 28 13:50:53 2011 +0100 qemu-char.c: fix incorrect CONFIG_STUBDOM handling qemu-char.c:1123:7: warning: "CONFIG_STUBDOM" is not defined [-Wundef] Signed-off-by: Olaf Hering <olaf@aepfle.de> Acked-by: Ian Jackson <ian.jackson@eu.citrix.com> _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel From xen-devel-bounces@lists.xensource.com Sat Sep 24 11:37:20 2011 Return-path: <xen-devel-bounces@lists.xensource.com> Envelope-to: www-data@lists.xensource.com Delivery-date: Sat, 24 Sep 2011 11:37:21 -0700 Received: from localhost ([127.0.0.1] helo=lists.colo.xensource.com) by lists.xensource.com with esmtp (Exim 4.43) id 1R7X6G-000405-LG; Sat, 24 Sep 2011 11:37:20 -0700 Received: from mail216.messagelabs.com ([85.158.143.99]) by lists.xensource.com with esmtp (Exim 4.43) id 1R7X5J-0003dz-D2 for xen-devel@lists.xensource.com; Sat, 24 Sep 2011 11:36:24 -0700 X-Env-Sender: Ian.Jackson@eu.citrix.com X-Msg-Ref: server-2.tower-216.messagelabs.com!1316889378!19030812!1 X-Originating-IP: [62.200.22.115] X-StarScan-Version: 6.4.1; banners=-,-,- X-VirusChecked: Checked Received: (qmail 20741 invoked from network); 24 Sep 2011 18:36:18 -0000 Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115) by server-2.tower-216.messagelabs.com with RC4-SHA encrypted SMTP; 24 Sep 2011 18:36:18 -0000 X-IronPort-AV: E=Sophos;i="4.68,435,1312156800"; d="scan'208";a="8042708" Received: from lonpmailmx01.citrite.net ([10.30.203.162]) by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5; 24 Sep 2011 18:36:17 +0000 Received: from woking.xci-test.com (10.80.248.135) by smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id 8.3.137.0; Sat, 24 Sep 2011 19:36:17 +0100 Received: from osstest by woking.xci-test.com with local (Exim 4.69) (envelope-from <ian.jackson@eu.citrix.com>) id 1R7X5E-00025l-RN; Sat, 24 Sep 2011 19:36:17 +0100 To: xen-devel@lists.xensource.com Message-ID: <osstest-9068-mainreport@xen.org> From: xen.org <ian.jackson@eu.citrix.com> Date: Sat, 24 Sep 2011 19:36:16 +0100 MIME-Version: 1.0 Content-Type: text/plain Cc: ian.jackson@eu.citrix.com Subject: [Xen-devel] [linux test] 9068: tolerable FAIL X-BeenThere: xen-devel@lists.xensource.com X-Mailman-Version: 2.1.5 Precedence: list List-Id: Xen developer discussion <xen-devel.lists.xensource.com> List-Unsubscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe> List-Post: <mailto:xen-devel@lists.xensource.com> List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help> List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=subscribe> Sender: xen-devel-bounces@lists.xensource.com Errors-To: xen-devel-bounces@lists.xensource.com flight 9068 linux real [real] http://www.chiark.greenend.org.uk/~xensrcts/logs/9068/ Failures :-/ but no regressions. Tests which are failing intermittently (not blocking): test-amd64-amd64-xl-sedf 14 guest-localmigrate/x10 fail pass in 9060 Tests which did not succeed, but are not blocking, including regressions (tests previously passed) regarded as allowable: test-amd64-amd64-xl-pcipt-intel 9 guest-start fail never pass test-amd64-i386-rhel6hvm-amd 9 guest-start.2 fail never pass test-amd64-i386-rhel6hvm-intel 9 guest-start.2 fail never pass test-amd64-i386-win-vcpus1 16 leak-check/check fail never pass test-amd64-i386-xl-win-vcpus1 13 guest-stop fail never pass test-amd64-amd64-win 16 leak-check/check fail never pass test-amd64-amd64-xl-win 13 guest-stop fail never pass test-i386-i386-win 16 leak-check/check fail never pass test-i386-i386-xl-win 13 guest-stop fail never pass test-amd64-i386-win 16 leak-check/check fail never pass version targeted for testing: linux 6bec8b4a4c14095d0b7ce424db9d583c3decae6c baseline version: linux 1c3f03ccc5258887f5f2cafc0836a865834f9205 ------------------------------------------------------------ People who touched revisions under test: Jeremy Fitzhardinge <jeremy.fitzhardinge@citrix.com> ------------------------------------------------------------ jobs: build-amd64 pass build-i386 pass build-amd64-pvops pass build-i386-pvops pass test-amd64-amd64-xl pass test-amd64-i386-xl pass test-i386-i386-xl pass test-amd64-i386-rhel6hvm-amd fail test-amd64-i386-xl-credit2 pass test-amd64-amd64-xl-pcipt-intel fail test-amd64-i386-rhel6hvm-intel fail test-amd64-i386-xl-multivcpu pass test-amd64-amd64-pair pass test-amd64-i386-pair pass test-i386-i386-pair pass test-amd64-amd64-pv pass test-amd64-i386-pv pass test-i386-i386-pv pass test-amd64-amd64-xl-sedf fail test-amd64-i386-win-vcpus1 fail test-amd64-i386-xl-win-vcpus1 fail test-amd64-amd64-win fail test-amd64-i386-win fail test-i386-i386-win fail test-amd64-amd64-xl-win fail test-i386-i386-xl-win fail ------------------------------------------------------------ sg-report-flight on woking.cam.xci-test.com logs: /home/xc_osstest/logs images: /home/xc_osstest/images Logs, config files, etc. are available at http://www.chiark.greenend.org.uk/~xensrcts/logs Test harness code can be found at http://xenbits.xensource.com/gitweb?p=osstest.git;a=summary Pushing revision : + branch=linux + revision=6bec8b4a4c14095d0b7ce424db9d583c3decae6c + . cri-lock-repos ++ . cri-common +++ umask 002 +++ getconfig Repos +++ perl -e ' use Osstest; readconfigonly(); print $c{Repos} or die $!; ' ++ repos=/export/home/osstest/repos ++ repos_lock=/export/home/osstest/repos/lock ++ '[' x '!=' x/export/home/osstest/repos/lock ']' ++ OSSTEST_REPOS_LOCK_LOCKED=/export/home/osstest/repos/lock ++ exec with-lock-ex -w /export/home/osstest/repos/lock ./ap-push linux 6bec8b4a4c14095d0b7ce424db9d583c3decae6c + branch=linux + revision=6bec8b4a4c14095d0b7ce424db9d583c3decae6c + . cri-lock-repos ++ . cri-common +++ umask 002 +++ getconfig Repos +++ perl -e ' use Osstest; readconfigonly(); print $c{Repos} or die $!; ' ++ repos=/export/home/osstest/repos ++ repos_lock=/export/home/osstest/repos/lock ++ '[' x/export/home/osstest/repos/lock '!=' x/export/home/osstest/repos/lock ']' + : xen@xenbits.xensource.com + : xen@xenbits.xensource.com:git/linux-pvops + : master + : tested/2.6.39.x + case "$branch" in + cd /export/home/osstest/repos/xen ./ap-push: line 20: cd: /export/home/osstest/repos/xen: No such file or directory ------------------------------------------------------------ commit 6bec8b4a4c14095d0b7ce424db9d583c3decae6c Author: Jeremy Fitzhardinge <jeremy.fitzhardinge@citrix.com> Date: Fri Sep 2 12:23:22 2011 -0700 Revert "xen/apic: Provide an 'apic_xen' to set the override the apic->[read|write] for all cases." This reverts commit c3dd7941354fa96a71f2613e2c7a1b215fa175dc. It prevents the kernel from booting natively on hardware. Conflicts: arch/x86/xen/enlighten.c Signed-off-by: Jeremy Fitzhardinge <jeremy.fitzhardinge@citrix.com> _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel From xen-devel-bounces@lists.xensource.com Sat Sep 24 12:33:35 2011 Return-path: <xen-devel-bounces@lists.xensource.com> Envelope-to: www-data@lists.xensource.com Delivery-date: Sat, 24 Sep 2011 12:33:35 -0700 Received: from localhost ([127.0.0.1] helo=lists.colo.xensource.com) by lists.xensource.com with esmtp (Exim 4.43) id 1R7Xyg-0005Yw-RA; Sat, 24 Sep 2011 12:33:34 -0700 Received: from mail182.messagelabs.com ([85.158.139.83]) by lists.xensource.com with esmtp (Exim 4.43) id 1R7Xxx-0005MZ-Op for xen-devel@lists.xensource.com; Sat, 24 Sep 2011 12:32:50 -0700 X-Env-Sender: Ian.Jackson@eu.citrix.com X-Msg-Ref: server-2.tower-182.messagelabs.com!1316892766!18605712!1 X-Originating-IP: [62.200.22.115] X-StarScan-Version: 6.4.1; banners=-,-,- X-VirusChecked: Checked Received: (qmail 10686 invoked from network); 24 Sep 2011 19:32:46 -0000 Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115) by server-2.tower-182.messagelabs.com with RC4-SHA encrypted SMTP; 24 Sep 2011 19:32:46 -0000 X-IronPort-AV: E=Sophos;i="4.68,435,1312156800"; d="scan'208";a="8042823" Received: from lonpmailmx01.citrite.net ([10.30.203.162]) by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5; 24 Sep 2011 19:32:45 +0000 Received: from woking.xci-test.com (10.80.248.135) by smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id 8.3.137.0; Sat, 24 Sep 2011 20:32:45 +0100 Received: from osstest by woking.xci-test.com with local (Exim 4.69) (envelope-from <ian.jackson@eu.citrix.com>) id 1R7Xxt-0003Eb-5Q; Sat, 24 Sep 2011 20:32:45 +0100 To: <xen-devel@lists.xensource.com> Message-ID: <osstest-9069-mainreport@xen.org> From: xen.org <ian.jackson@eu.citrix.com> Date: Sat, 24 Sep 2011 20:32:45 +0100 MIME-Version: 1.0 Content-Type: text/plain Cc: ian.jackson@eu.citrix.com Subject: [Xen-devel] [xen-unstable test] 9069: regressions - FAIL X-BeenThere: xen-devel@lists.xensource.com X-Mailman-Version: 2.1.5 Precedence: list List-Id: Xen developer discussion <xen-devel.lists.xensource.com> List-Unsubscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe> List-Post: <mailto:xen-devel@lists.xensource.com> List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help> List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=subscribe> Sender: xen-devel-bounces@lists.xensource.com Errors-To: xen-devel-bounces@lists.xensource.com flight 9069 xen-unstable real [real] http://www.chiark.greenend.org.uk/~xensrcts/logs/9069/ Regressions :-( Tests which did not succeed and are blocking: test-amd64-i386-rhel6hvm-amd 5 xen-boot fail REGR. vs. 8995 Tests which are failing intermittently (not blocking): test-amd64-i386-pv 5 xen-boot fail pass in 9065 test-amd64-amd64-xl 5 xen-boot fail pass in 9065 test-i386-i386-pv 5 xen-boot fail pass in 9067 test-amd64-i386-xl 5 xen-boot fail pass in 9065 test-amd64-amd64-xl-sedf 5 xen-boot fail pass in 9067 test-amd64-i386-xl-win-vcpus1 5 xen-boot fail pass in 9065 test-i386-i386-xl-win 5 xen-boot fail pass in 9067 test-i386-i386-win 5 xen-boot fail pass in 9067 test-amd64-i386-win 5 xen-boot fail pass in 9065 test-amd64-amd64-xl-win 5 xen-boot fail pass in 9063 test-amd64-i386-xl-multivcpu 5 xen-boot fail in 9065 pass in 9069 test-amd64-i386-xl-credit2 5 xen-boot fail in 9065 pass in 9069 test-i386-i386-xl 5 xen-boot fail in 9065 pass in 9069 test-amd64-amd64-win 5 xen-boot fail in 9065 pass in 9069 test-amd64-i386-win-vcpus1 5 xen-boot fail in 9065 pass in 9069 test-amd64-amd64-pv 5 xen-boot fail in 9067 pass in 9069 test-amd64-amd64-pair 7 xen-boot/src_host fail in 9063 pass in 9069 test-amd64-amd64-pair 8 xen-boot/dst_host fail in 9063 pass in 9069 Tests which did not succeed, but are not blocking, including regressions (tests previously passed) regarded as allowable: test-amd64-amd64-xl-pcipt-intel 9 guest-start fail never pass test-amd64-i386-rhel6hvm-intel 9 guest-start.2 fail never pass test-amd64-amd64-win 16 leak-check/check fail never pass test-amd64-i386-win-vcpus1 16 leak-check/check fail never pass test-amd64-i386-xl-win-vcpus1 13 guest-stop fail in 9065 never pass test-i386-i386-xl-win 13 guest-stop fail in 9065 never pass test-amd64-i386-win 16 leak-check/check fail in 9065 never pass test-i386-i386-win 16 leak-check/check fail in 9067 never pass test-amd64-amd64-xl-win 13 guest-stop fail in 9063 never pass version targeted for testing: xen cc339ab1d917 baseline version: xen a422e2a4451e ------------------------------------------------------------ People who touched revisions under test: Andreas Herrmann <herrmann.der.user@googlemail.com> Ian Campbell <ian.campbell@citrix.com> Ian Jackson <ian.jackson@eu.citrix.com> Jan Beulich <jbeulich@suse.com> Lasse Collin <lasse.collin@tukaani.org> Olaf Hering <olaf@aepfle.de> Thomas Renninger <trenn@suse.de> ------------------------------------------------------------ jobs: build-amd64 pass build-i386 pass build-amd64-oldkern pass build-i386-oldkern pass build-amd64-pvops pass build-i386-pvops pass test-amd64-amd64-xl fail test-amd64-i386-xl fail test-i386-i386-xl pass test-amd64-i386-rhel6hvm-amd fail test-amd64-i386-xl-credit2 pass test-amd64-amd64-xl-pcipt-intel fail test-amd64-i386-rhel6hvm-intel fail test-amd64-i386-xl-multivcpu pass test-amd64-amd64-pair pass test-amd64-i386-pair pass test-i386-i386-pair pass test-amd64-amd64-pv pass test-amd64-i386-pv fail test-i386-i386-pv fail test-amd64-amd64-xl-sedf fail test-amd64-i386-win-vcpus1 fail test-amd64-i386-xl-win-vcpus1 fail test-amd64-amd64-win fail test-amd64-i386-win fail test-i386-i386-win fail test-amd64-amd64-xl-win fail test-i386-i386-xl-win fail ------------------------------------------------------------ sg-report-flight on woking.cam.xci-test.com logs: /home/xc_osstest/logs images: /home/xc_osstest/images Logs, config files, etc. are available at http://www.chiark.greenend.org.uk/~xensrcts/logs Test harness code can be found at http://xenbits.xensource.com/gitweb?p=osstest.git;a=summary Not pushing. ------------------------------------------------------------ changeset: 23872:cc339ab1d917 tag: tip user: Ian Campbell <ian.campbell@citrix.com> date: Thu Sep 22 18:37:06 2011 +0100 tools: fix install of lomount $(BIN) went away in 23124:e3d4c34b14a3. Also there are no *.so, *.a or *.rpm built in here Signed-off-by: Ian Campbell <ian.campbell@citrix.com> changeset: 23871:503ee256fecf user: Jan Beulich <jbeulich@suse.com> date: Thu Sep 22 18:35:30 2011 +0100 x86: ucode-amd: Don't warn when no ucode is available for a CPU revision This patch originally comes from the Linus mainline kernel (2.6.33), find below the patch details: From: Andreas Herrmann <herrmann.der.user@googlemail.com> There is no point in warning when there is no ucode available for a specific CPU revision. Currently the container-file, which provides the AMD ucode patches for OS load, contains only a few ucode patches. It's already clearly indicated by the printed patch_level whenever new ucode was available and an update happened. So the warning message is of no help but rather annoying on systems with many CPUs. Signed-off-by: Thomas Renninger <trenn@suse.de> Signed-off-by: Jan Beulich <jbeulich@suse.com> changeset: 23870:5c97b02f48fc user: Jan Beulich <jbeulich@suse.com> date: Thu Sep 22 18:34:27 2011 +0100 XZ: Fix incorrect XZ_BUF_ERROR From: Lasse Collin <lasse.collin@tukaani.org> xz_dec_run() could incorrectly return XZ_BUF_ERROR if all of the following was true: - The caller knows how many bytes of output to expect and only provides that much output space. - When the last output bytes are decoded, the caller-provided input buffer ends right before the LZMA2 end of payload marker. So LZMA2 won't provide more output anymore, but it won't know it yet and thus won't return XZ_STREAM_END yet. - A BCJ filter is in use and it hasn't left any unfiltered bytes in the temp buffer. This can happen with any BCJ filter, but in practice it's more likely with filters other than the x86 BCJ. This fixes <https://bugzilla.redhat.com/show_bug.cgi?id=3D735408> where Squashfs thinks that a valid file system is corrupt. This also fixes a similar bug in single-call mode where the uncompressed size of a block using BCJ + LZMA2 was 0 bytes and caller provided no output space. Many empty .xz files don't contain any blocks and thus don't trigger this bug. This also tweaks a closely related detail: xz_dec_bcj_run() could call xz_dec_lzma2_run() to decode into temp buffer when it was known to be useless. This was harmless although it wasted a minuscule number of CPU cycles. Signed-off-by: Lasse Collin <lasse.collin@tukaani.org> Signed-off-by: Jan Beulich <jbeulich@suse.com> changeset: 23869:db1ea4b127cd user: Jan Beulich <jbeulich@suse.com> date: Thu Sep 22 18:33:48 2011 +0100 XZ decompressor: Fix decoding of empty LZMA2 streams From: Lasse Collin <lasse.collin@tukaani.org> The old code considered valid empty LZMA2 streams to be corrupt. Note that a typical empty .xz file has no LZMA2 data at all, and thus most .xz files having no uncompressed data are handled correctly even without this fix. Signed-off-by: Lasse Collin <lasse.collin@tukaani.org> Signed-off-by: Jan Beulich <jbeulich@suse.com> changeset: 23868:28147fd781af user: Jan Beulich <jbeulich@suse.com> date: Thu Sep 22 18:32:34 2011 +0100 VT-d: fix off-by-one error in RMRR validation (base_addr,end_addr) is an inclusive range, and hence there shouldn't be a subtraction of 1 in the second invocation of page_is_ram_type(). For RMRRs covering a single page that actually resulted in the immediately preceding page to get checked (which could have resulted in a false warning). Signed-off-by: Jan Beulich <jbeulich@suse.com> changeset: 23867:571b6e90dfb4 user: Jan Beulich <jbeulich@suse.com> date: Thu Sep 22 18:31:44 2011 +0100 VT-d: eliminate a mis-use of pcidevs_lock dma_pte_clear_one() shouldn't acquire this global lock for the purpose of processing a per-domain list. Furthermore the function a few lines earlier has a comment stating that acquiring pcidevs_lock isn't necessary here (whether that's really correct is another question). Use the domain's mappin_lock instead to protect the mapped_rmrrs list. Fold domain_rmrr_mapped() into its sole caller so that the otherwise implicit dependency on pcidevs_lock there becomes more obvious (see the comment there). Signed-off-by: Jan Beulich <jbeulich@suse.com> changeset: 23866:47ec1d405af9 user: Jan Beulich <jbeulich@suse.com> date: Thu Sep 22 18:31:02 2011 +0100 x86: IO-APIC code has no dependency on PCI The IRQ handling code requires pcidevs_lock to be held only for MSI interrupts. As the handling of which was now fully moved into msi.c (i.e. while applying fine without, the patch needs to be applied after the one titled "x86: split MSI IRQ chip"), io_apic.c now also doesn't need to include PCI headers anymore. Signed-off-by: Jan Beulich <jbeulich@suse.com> changeset: 23865:d6e01c7853cf user: Jan Beulich <jbeulich@suse.com> date: Thu Sep 22 18:29:19 2011 +0100 PCI multi-seg: config space accessor adjustments Signed-off-by: Jan Beulich <jbeulich@suse.com> changeset: 23864:314b147d524d user: Jan Beulich <jbeulich@suse.com> date: Thu Sep 22 18:28:38 2011 +0100 PCI multi-seg: Pass-through adjustments Signed-off-by: Jan Beulich <jbeulich@suse.com> changeset: 23863:9e0259239822 user: Jan Beulich <jbeulich@suse.com> date: Thu Sep 22 18:28:03 2011 +0100 PCI multi-seg: AMD-IOMMU specific adjustments There are two places here where it is entirely unclear to me where the necessary PCI segment number should be taken from (as IVMD descriptors don't have such, only IVHD ones do). AMD confirmed that for the time being it is acceptable to imply that only segment 0 exists. Signed-off-by: Jan Beulich <jbeulich@suse.com> changeset: 23862:85418e168527 user: Jan Beulich <jbeulich@suse.com> date: Thu Sep 22 18:27:26 2011 +0100 PCI multi-seg: VT-d specific adjustments Signed-off-by: Jan Beulich <jbeulich@suse.com> changeset: 23861:ec7c81fbe0de user: Jan Beulich <jbeulich@suse.com> date: Thu Sep 22 18:26:54 2011 +0100 PCI multi-seg: adjust domctl interface Again, a couple of directly related functions at once get adjusted to account for the segment number. Signed-off-by: Jan Beulich <jbeulich@suse.com> changeset: 23860:a422e2a4451e user: Jan Beulich <jbeulich@suse.com> date: Sun Sep 18 00:26:52 2011 +0100 x86: split MSI IRQ chip With the .end() accessor having become optional and noting that several of the accessors' behavior really depends on the result of msi_maskable_irq(), the splits the MSI IRQ chip type into two - one for the maskable ones, and the other for the (MSI only) non-maskable ones. At once the implementation of those methods gets moved from io_apic.c to msi.c. Signed-off-by: Jan Beulich <jbeulich@suse.com> ======================================== commit cd776ee9408ff127f934a707c1a339ee600bc127 Author: Ian Jackson <ian.jackson@eu.citrix.com> Date: Tue Jun 28 13:50:53 2011 +0100 qemu-char.c: fix incorrect CONFIG_STUBDOM handling qemu-char.c:1123:7: warning: "CONFIG_STUBDOM" is not defined [-Wundef] Signed-off-by: Olaf Hering <olaf@aepfle.de> Acked-by: Ian Jackson <ian.jackson@eu.citrix.com> _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel From xen-devel-bounces@lists.xensource.com Sat Sep 24 13:59:53 2011 Return-path: <xen-devel-bounces@lists.xensource.com> Envelope-to: www-data@lists.xensource.com Delivery-date: Sat, 24 Sep 2011 13:59:53 -0700 Received: from localhost ([127.0.0.1] helo=lists.colo.xensource.com) by lists.xensource.com with esmtp (Exim 4.43) id 1R7ZKC-0007Vt-7m; Sat, 24 Sep 2011 13:59:52 -0700 Received: from mail182.messagelabs.com ([85.158.139.83]) by lists.xensource.com with esmtp (Exim 4.43) id 1R7ZJA-0007J9-5L for xen-devel@lists.xensource.com; Sat, 24 Sep 2011 13:58:48 -0700 X-Env-Sender: dan.magenheimer@oracle.com X-Msg-Ref: server-4.tower-182.messagelabs.com!1316897923!19609966!1 X-Originating-IP: [148.87.113.117] X-StarScan-Version: 6.4.1; banners=-,-,- X-VirusChecked: Checked Received: (qmail 27019 invoked from network); 24 Sep 2011 20:58:44 -0000 Received: from rcsinet15.oracle.com (HELO rcsinet15.oracle.com) (148.87.113.117) by server-4.tower-182.messagelabs.com with DHE-RSA-AES256-SHA encrypted SMTP; 24 Sep 2011 20:58:44 -0000 Received: from acsinet21.oracle.com (acsinet21.oracle.com [141.146.126.237]) by rcsinet15.oracle.com (Switch-3.4.4/Switch-3.4.4) with ESMTP id p8OKwbuu006916 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Sat, 24 Sep 2011 20:58:39 GMT Received: from acsmt357.oracle.com (acsmt357.oracle.com [141.146.40.157]) by acsinet21.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id p8OKwY3B002090 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sat, 24 Sep 2011 20:58:35 GMT Received: from abhmt118.oracle.com (abhmt118.oracle.com [141.146.116.70]) by acsmt357.oracle.com (8.12.11.20060308/8.12.11) with ESMTP id p8OKwRGr021860; Sat, 24 Sep 2011 15:58:27 -0500 MIME-Version: 1.0 Message-ID: <9827a70d-dfb2-4bbc-9df6-207b10c835ac@default> Date: Sat, 24 Sep 2011 13:58:08 -0700 (PDT) From: Dan Magenheimer <dan.magenheimer@oracle.com> To: Konrad Wilk <konrad.wilk@oracle.com>, linux-kernel@vger.kernel.org X-Priority: 3 X-Mailer: Oracle Beehive Extensions for Outlook 2.0.1.4.1.0 (410211) [OL 12.0.6557.5001] Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable X-Source-IP: acsinet21.oracle.com [141.146.126.237] X-Auth-Type: Internal IP X-CT-RefId: str=0001.0A090208.4E7E4480.0020:SCFMA922111,ss=1,re=-4.000,fgs=0 Cc: Jeremy Fitzhardinge <jeremy@goop.org>, xen-devel@lists.xensource.com, David Vrabel <david.vrabel@citrix.com> Subject: [Xen-devel] [PATCH] xen: Fix selfballooning and ensure it doesn't go too far X-BeenThere: xen-devel@lists.xensource.com X-Mailman-Version: 2.1.5 Precedence: list List-Id: Xen developer discussion <xen-devel.lists.xensource.com> List-Unsubscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe> List-Post: <mailto:xen-devel@lists.xensource.com> List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help> List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=subscribe> Sender: xen-devel-bounces@lists.xensource.com Errors-To: xen-devel-bounces@lists.xensource.com [PATCH] xen: Fix selfballooning and ensure it doesn't go too far The balloon driver's "current_pages" is very different from totalram_pages. Self-ballooning needs to be driven by the latter. Also, Committed_AS doesn't account for pages used by the kernel so enforce a floor for when there are little or no user-space threads using memory. Signed-off-by: Dan Magenheimer <dan.magenheimer@oracle.com> diff --git a/drivers/xen/xen-selfballoon.c b/drivers/xen/xen-selfballoon.c index 6ea852e..e3e48f1 100644 --- a/drivers/xen/xen-selfballoon.c +++ b/drivers/xen/xen-selfballoon.c @@ -195,14 +195,13 @@ __setup("selfballooning", xen_selfballooning_setup); */ static void selfballoon_process(struct work_struct *work) { -=09unsigned long cur_pages, goal_pages, tgt_pages; +=09unsigned long cur_pages, goal_pages, tgt_pages, floor_pages; =09bool reset_timer =3D false; =20 =09if (xen_selfballooning_enabled) { -=09=09cur_pages =3D balloon_stats.current_pages; +=09=09cur_pages =3D totalram_pages; =09=09tgt_pages =3D cur_pages; /* default is no change */ -=09=09goal_pages =3D percpu_counter_read_positive(&vm_committed_as) + -=09=09=09balloon_stats.current_pages - totalram_pages; +=09=09goal_pages =3D percpu_counter_read_positive(&vm_committed_as); #ifdef CONFIG_FRONTSWAP =09=09/* allow space for frontswap pages to be repatriated */ =09=09if (frontswap_selfshrinking && frontswap_enabled) @@ -217,7 +216,13 @@ static void selfballoon_process(struct work_struct *wo= rk) =09=09=09=09((goal_pages - cur_pages) / =09=09=09=09 selfballoon_uphysteresis); =09=09/* else if cur_pages =3D=3D goal_pages, no change */ -=09=09balloon_set_new_target(tgt_pages); +=09=09floor_pages =3D totalreserve_pages + +=09=09=09=09(roundup_pow_of_two(max_pfn) >> 5); +=09=09/* don't balloon too far, lest OOMs occur... */ +=09=09if (tgt_pages < floor_pages) +=09=09=09tgt_pages =3D floor_pages; +=09=09balloon_set_new_target(tgt_pages + +=09=09=09balloon_stats.current_pages - totalram_pages); =09=09reset_timer =3D true; =09} #ifdef CONFIG_FRONTSWAP _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel From xen-devel-bounces@lists.xensource.com Sat Sep 24 14:18:51 2011 Return-path: <xen-devel-bounces@lists.xensource.com> Envelope-to: www-data@lists.xensource.com Delivery-date: Sat, 24 Sep 2011 14:18:51 -0700 Received: from localhost ([127.0.0.1] helo=lists.colo.xensource.com) by lists.xensource.com with esmtp (Exim 4.43) id 1R7ZcZ-00088Z-Lh; Sat, 24 Sep 2011 14:18:51 -0700 Received: from mail182.messagelabs.com ([85.158.139.83]) by lists.xensource.com with esmtp (Exim 4.43) id 1R7Zbk-0007vg-N4 for xen-devel@lists.xensource.com; Sat, 24 Sep 2011 14:18:02 -0700 X-Env-Sender: Ian.Jackson@eu.citrix.com X-Msg-Ref: server-6.tower-182.messagelabs.com!1316899077!18409059!1 X-Originating-IP: [62.200.22.115] X-StarScan-Version: 6.4.1; banners=-,-,- X-VirusChecked: Checked Received: (qmail 5961 invoked from network); 24 Sep 2011 21:17:57 -0000 Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115) by server-6.tower-182.messagelabs.com with RC4-SHA encrypted SMTP; 24 Sep 2011 21:17:57 -0000 X-IronPort-AV: E=Sophos;i="4.68,436,1312156800"; d="scan'208";a="8043173" Received: from lonpmailmx01.citrite.net ([10.30.203.162]) by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5; 24 Sep 2011 21:17:57 +0000 Received: from woking.xci-test.com (10.80.248.135) by smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id 8.3.137.0; Sat, 24 Sep 2011 22:17:57 +0100 Received: from osstest by woking.xci-test.com with local (Exim 4.69) (envelope-from <ian.jackson@eu.citrix.com>) id 1R7Zbh-0007Yd-26; Sat, 24 Sep 2011 22:17:57 +0100 To: <xen-devel@lists.xensource.com> Message-ID: <osstest-9070-mainreport@xen.org> From: xen.org <ian.jackson@eu.citrix.com> Date: Sat, 24 Sep 2011 22:17:57 +0100 MIME-Version: 1.0 Content-Type: text/plain Cc: ian.jackson@eu.citrix.com Subject: [Xen-devel] [linux test] 9070: tolerable FAIL X-BeenThere: xen-devel@lists.xensource.com X-Mailman-Version: 2.1.5 Precedence: list List-Id: Xen developer discussion <xen-devel.lists.xensource.com> List-Unsubscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe> List-Post: <mailto:xen-devel@lists.xensource.com> List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help> List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=subscribe> Sender: xen-devel-bounces@lists.xensource.com Errors-To: xen-devel-bounces@lists.xensource.com flight 9070 linux real [real] http://www.chiark.greenend.org.uk/~xensrcts/logs/9070/ Failures :-/ but no regressions. Tests which did not succeed, but are not blocking, including regressions (tests previously passed) regarded as allowable: test-amd64-amd64-xl-pcipt-intel 9 guest-start fail never pass test-amd64-i386-rhel6hvm-amd 9 guest-start.2 fail never pass test-amd64-i386-rhel6hvm-intel 9 guest-start.2 fail never pass test-amd64-i386-win-vcpus1 16 leak-check/check fail never pass test-amd64-i386-xl-win-vcpus1 13 guest-stop fail never pass test-amd64-amd64-win 16 leak-check/check fail never pass test-amd64-amd64-xl-win 13 guest-stop fail never pass test-i386-i386-win 16 leak-check/check fail never pass test-i386-i386-xl-win 13 guest-stop fail never pass test-amd64-i386-win 16 leak-check/check fail never pass version targeted for testing: linux 6bec8b4a4c14095d0b7ce424db9d583c3decae6c baseline version: linux 1c3f03ccc5258887f5f2cafc0836a865834f9205 ------------------------------------------------------------ People who touched revisions under test: Jeremy Fitzhardinge <jeremy.fitzhardinge@citrix.com> ------------------------------------------------------------ jobs: build-amd64 pass build-i386 pass build-amd64-pvops pass build-i386-pvops pass test-amd64-amd64-xl pass test-amd64-i386-xl pass test-i386-i386-xl pass test-amd64-i386-rhel6hvm-amd fail test-amd64-i386-xl-credit2 pass test-amd64-amd64-xl-pcipt-intel fail test-amd64-i386-rhel6hvm-intel fail test-amd64-i386-xl-multivcpu pass test-amd64-amd64-pair pass test-amd64-i386-pair pass test-i386-i386-pair pass test-amd64-amd64-pv pass test-amd64-i386-pv pass test-i386-i386-pv pass test-amd64-amd64-xl-sedf pass test-amd64-i386-win-vcpus1 fail test-amd64-i386-xl-win-vcpus1 fail test-amd64-amd64-win fail test-amd64-i386-win fail test-i386-i386-win fail test-amd64-amd64-xl-win fail test-i386-i386-xl-win fail ------------------------------------------------------------ sg-report-flight on woking.cam.xci-test.com logs: /home/xc_osstest/logs images: /home/xc_osstest/images Logs, config files, etc. are available at http://www.chiark.greenend.org.uk/~xensrcts/logs Test harness code can be found at http://xenbits.xensource.com/gitweb?p=osstest.git;a=summary Pushing revision : + branch=linux + revision=6bec8b4a4c14095d0b7ce424db9d583c3decae6c + . cri-lock-repos ++ . cri-common +++ umask 002 +++ getconfig Repos +++ perl -e ' use Osstest; readconfigonly(); print $c{Repos} or die $!; ' ++ repos=/export/home/osstest/repos ++ repos_lock=/export/home/osstest/repos/lock ++ '[' x '!=' x/export/home/osstest/repos/lock ']' ++ OSSTEST_REPOS_LOCK_LOCKED=/export/home/osstest/repos/lock ++ exec with-lock-ex -w /export/home/osstest/repos/lock ./ap-push linux 6bec8b4a4c14095d0b7ce424db9d583c3decae6c + branch=linux + revision=6bec8b4a4c14095d0b7ce424db9d583c3decae6c + . cri-lock-repos ++ . cri-common +++ umask 002 +++ getconfig Repos +++ perl -e ' use Osstest; readconfigonly(); print $c{Repos} or die $!; ' ++ repos=/export/home/osstest/repos ++ repos_lock=/export/home/osstest/repos/lock ++ '[' x/export/home/osstest/repos/lock '!=' x/export/home/osstest/repos/lock ']' + : xen@xenbits.xensource.com + : xen@xenbits.xensource.com:git/linux-pvops + : master + : tested/2.6.39.x + case "$branch" in + cd /export/home/osstest/repos/xen ./ap-push: line 20: cd: /export/home/osstest/repos/xen: No such file or directory ------------------------------------------------------------ commit 6bec8b4a4c14095d0b7ce424db9d583c3decae6c Author: Jeremy Fitzhardinge <jeremy.fitzhardinge@citrix.com> Date: Fri Sep 2 12:23:22 2011 -0700 Revert "xen/apic: Provide an 'apic_xen' to set the override the apic->[read|write] for all cases." This reverts commit c3dd7941354fa96a71f2613e2c7a1b215fa175dc. It prevents the kernel from booting natively on hardware. Conflicts: arch/x86/xen/enlighten.c Signed-off-by: Jeremy Fitzhardinge <jeremy.fitzhardinge@citrix.com> _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel From xen-devel-bounces@lists.xensource.com Sat Sep 24 15:54:23 2011 Return-path: <xen-devel-bounces@lists.xensource.com> Envelope-to: www-data@lists.xensource.com Delivery-date: Sat, 24 Sep 2011 15:54:23 -0700 Received: from localhost ([127.0.0.1] helo=lists.colo.xensource.com) by lists.xensource.com with esmtp (Exim 4.43) id 1R7b70-0005t9-S0; Sat, 24 Sep 2011 15:54:22 -0700 Received: from mail216.messagelabs.com ([85.158.143.99]) by lists.xensource.com with esmtp (Exim 4.43) id 1R7b6N-0005gu-Jc for xen-devel@lists.xensource.com; Sat, 24 Sep 2011 15:53:44 -0700 X-Env-Sender: Ian.Jackson@eu.citrix.com X-Msg-Ref: server-11.tower-216.messagelabs.com!1316904820!11898934!1 X-Originating-IP: [62.200.22.115] X-StarScan-Version: 6.4.1; banners=-,-,- X-VirusChecked: Checked Received: (qmail 26872 invoked from network); 24 Sep 2011 22:53:40 -0000 Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115) by server-11.tower-216.messagelabs.com with RC4-SHA encrypted SMTP; 24 Sep 2011 22:53:40 -0000 X-IronPort-AV: E=Sophos;i="4.68,436,1312156800"; d="scan'208";a="8043736" Received: from lonpmailmx01.citrite.net ([10.30.203.162]) by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5; 24 Sep 2011 22:53:40 +0000 Received: from woking.xci-test.com (10.80.248.135) by smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id 8.3.137.0; Sat, 24 Sep 2011 23:53:40 +0100 Received: from osstest by woking.xci-test.com with local (Exim 4.69) (envelope-from <ian.jackson@eu.citrix.com>) id 1R7b6K-0000qa-0m; Sat, 24 Sep 2011 23:53:40 +0100 To: xen-devel@lists.xensource.com Message-ID: <osstest-9071-mainreport@xen.org> From: xen.org <ian.jackson@eu.citrix.com> Date: Sat, 24 Sep 2011 23:53:40 +0100 MIME-Version: 1.0 Content-Type: text/plain Cc: ian.jackson@eu.citrix.com Subject: [Xen-devel] [xen-unstable test] 9071: regressions - FAIL X-BeenThere: xen-devel@lists.xensource.com X-Mailman-Version: 2.1.5 Precedence: list List-Id: Xen developer discussion <xen-devel.lists.xensource.com> List-Unsubscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe> List-Post: <mailto:xen-devel@lists.xensource.com> List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help> List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=subscribe> Sender: xen-devel-bounces@lists.xensource.com Errors-To: xen-devel-bounces@lists.xensource.com flight 9071 xen-unstable real [real] http://www.chiark.greenend.org.uk/~xensrcts/logs/9071/ Regressions :-( Tests which did not succeed and are blocking: test-amd64-i386-rhel6hvm-amd 5 xen-boot fail REGR. vs. 8995 Tests which are failing intermittently (not blocking): test-amd64-i386-pv 5 xen-boot fail pass in 9065 test-i386-i386-pv 5 xen-boot fail pass in 9067 test-amd64-amd64-xl-sedf 5 xen-boot fail pass in 9067 test-amd64-i386-xl-win-vcpus1 5 xen-boot fail pass in 9065 test-i386-i386-xl-win 5 xen-boot fail pass in 9067 test-i386-i386-pair 8 xen-boot/dst_host fail pass in 9069 test-i386-i386-pair 7 xen-boot/src_host fail pass in 9069 test-amd64-amd64-win 5 xen-boot fail pass in 9069 test-amd64-i386-xl-multivcpu 5 xen-boot fail in 9065 pass in 9071 test-amd64-i386-xl-credit2 5 xen-boot fail in 9065 pass in 9071 test-i386-i386-xl 5 xen-boot fail in 9065 pass in 9071 test-i386-i386-win 5 xen-boot fail in 9065 pass in 9071 test-amd64-i386-win-vcpus1 5 xen-boot fail in 9065 pass in 9071 test-amd64-amd64-xl-win 5 xen-boot fail in 9065 pass in 9071 test-amd64-amd64-xl 5 xen-boot fail in 9067 pass in 9071 test-amd64-amd64-pv 5 xen-boot fail in 9067 pass in 9071 test-amd64-i386-xl 5 xen-boot fail in 9067 pass in 9071 test-amd64-i386-win 5 xen-boot fail in 9067 pass in 9071 Tests which did not succeed, but are not blocking, including regressions (tests previously passed) regarded as allowable: test-amd64-amd64-xl-pcipt-intel 9 guest-start fail never pass test-amd64-i386-rhel6hvm-intel 9 guest-start.2 fail never pass test-i386-i386-win 16 leak-check/check fail never pass test-amd64-i386-win-vcpus1 16 leak-check/check fail never pass test-amd64-i386-win 16 leak-check/check fail never pass test-amd64-amd64-xl-win 13 guest-stop fail never pass test-amd64-i386-xl-win-vcpus1 13 guest-stop fail in 9065 never pass test-i386-i386-xl-win 13 guest-stop fail in 9065 never pass test-amd64-amd64-win 16 leak-check/check fail in 9067 never pass version targeted for testing: xen cc339ab1d917 baseline version: xen a422e2a4451e ------------------------------------------------------------ People who touched revisions under test: Andreas Herrmann <herrmann.der.user@googlemail.com> Ian Campbell <ian.campbell@citrix.com> Ian Jackson <ian.jackson@eu.citrix.com> Jan Beulich <jbeulich@suse.com> Lasse Collin <lasse.collin@tukaani.org> Olaf Hering <olaf@aepfle.de> Thomas Renninger <trenn@suse.de> ------------------------------------------------------------ jobs: build-amd64 pass build-i386 pass build-amd64-oldkern pass build-i386-oldkern pass build-amd64-pvops pass build-i386-pvops pass test-amd64-amd64-xl pass test-amd64-i386-xl pass test-i386-i386-xl pass test-amd64-i386-rhel6hvm-amd fail test-amd64-i386-xl-credit2 pass test-amd64-amd64-xl-pcipt-intel fail test-amd64-i386-rhel6hvm-intel fail test-amd64-i386-xl-multivcpu pass test-amd64-amd64-pair pass test-amd64-i386-pair pass test-i386-i386-pair fail test-amd64-amd64-pv pass test-amd64-i386-pv fail test-i386-i386-pv fail test-amd64-amd64-xl-sedf fail test-amd64-i386-win-vcpus1 fail test-amd64-i386-xl-win-vcpus1 fail test-amd64-amd64-win fail test-amd64-i386-win fail test-i386-i386-win fail test-amd64-amd64-xl-win fail test-i386-i386-xl-win fail ------------------------------------------------------------ sg-report-flight on woking.cam.xci-test.com logs: /home/xc_osstest/logs images: /home/xc_osstest/images Logs, config files, etc. are available at http://www.chiark.greenend.org.uk/~xensrcts/logs Test harness code can be found at http://xenbits.xensource.com/gitweb?p=osstest.git;a=summary Not pushing. ------------------------------------------------------------ changeset: 23872:cc339ab1d917 tag: tip user: Ian Campbell <ian.campbell@citrix.com> date: Thu Sep 22 18:37:06 2011 +0100 tools: fix install of lomount $(BIN) went away in 23124:e3d4c34b14a3. Also there are no *.so, *.a or *.rpm built in here Signed-off-by: Ian Campbell <ian.campbell@citrix.com> changeset: 23871:503ee256fecf user: Jan Beulich <jbeulich@suse.com> date: Thu Sep 22 18:35:30 2011 +0100 x86: ucode-amd: Don't warn when no ucode is available for a CPU revision This patch originally comes from the Linus mainline kernel (2.6.33), find below the patch details: From: Andreas Herrmann <herrmann.der.user@googlemail.com> There is no point in warning when there is no ucode available for a specific CPU revision. Currently the container-file, which provides the AMD ucode patches for OS load, contains only a few ucode patches. It's already clearly indicated by the printed patch_level whenever new ucode was available and an update happened. So the warning message is of no help but rather annoying on systems with many CPUs. Signed-off-by: Thomas Renninger <trenn@suse.de> Signed-off-by: Jan Beulich <jbeulich@suse.com> changeset: 23870:5c97b02f48fc user: Jan Beulich <jbeulich@suse.com> date: Thu Sep 22 18:34:27 2011 +0100 XZ: Fix incorrect XZ_BUF_ERROR From: Lasse Collin <lasse.collin@tukaani.org> xz_dec_run() could incorrectly return XZ_BUF_ERROR if all of the following was true: - The caller knows how many bytes of output to expect and only provides that much output space. - When the last output bytes are decoded, the caller-provided input buffer ends right before the LZMA2 end of payload marker. So LZMA2 won't provide more output anymore, but it won't know it yet and thus won't return XZ_STREAM_END yet. - A BCJ filter is in use and it hasn't left any unfiltered bytes in the temp buffer. This can happen with any BCJ filter, but in practice it's more likely with filters other than the x86 BCJ. This fixes <https://bugzilla.redhat.com/show_bug.cgi?id=3D735408> where Squashfs thinks that a valid file system is corrupt. This also fixes a similar bug in single-call mode where the uncompressed size of a block using BCJ + LZMA2 was 0 bytes and caller provided no output space. Many empty .xz files don't contain any blocks and thus don't trigger this bug. This also tweaks a closely related detail: xz_dec_bcj_run() could call xz_dec_lzma2_run() to decode into temp buffer when it was known to be useless. This was harmless although it wasted a minuscule number of CPU cycles. Signed-off-by: Lasse Collin <lasse.collin@tukaani.org> Signed-off-by: Jan Beulich <jbeulich@suse.com> changeset: 23869:db1ea4b127cd user: Jan Beulich <jbeulich@suse.com> date: Thu Sep 22 18:33:48 2011 +0100 XZ decompressor: Fix decoding of empty LZMA2 streams From: Lasse Collin <lasse.collin@tukaani.org> The old code considered valid empty LZMA2 streams to be corrupt. Note that a typical empty .xz file has no LZMA2 data at all, and thus most .xz files having no uncompressed data are handled correctly even without this fix. Signed-off-by: Lasse Collin <lasse.collin@tukaani.org> Signed-off-by: Jan Beulich <jbeulich@suse.com> changeset: 23868:28147fd781af user: Jan Beulich <jbeulich@suse.com> date: Thu Sep 22 18:32:34 2011 +0100 VT-d: fix off-by-one error in RMRR validation (base_addr,end_addr) is an inclusive range, and hence there shouldn't be a subtraction of 1 in the second invocation of page_is_ram_type(). For RMRRs covering a single page that actually resulted in the immediately preceding page to get checked (which could have resulted in a false warning). Signed-off-by: Jan Beulich <jbeulich@suse.com> changeset: 23867:571b6e90dfb4 user: Jan Beulich <jbeulich@suse.com> date: Thu Sep 22 18:31:44 2011 +0100 VT-d: eliminate a mis-use of pcidevs_lock dma_pte_clear_one() shouldn't acquire this global lock for the purpose of processing a per-domain list. Furthermore the function a few lines earlier has a comment stating that acquiring pcidevs_lock isn't necessary here (whether that's really correct is another question). Use the domain's mappin_lock instead to protect the mapped_rmrrs list. Fold domain_rmrr_mapped() into its sole caller so that the otherwise implicit dependency on pcidevs_lock there becomes more obvious (see the comment there). Signed-off-by: Jan Beulich <jbeulich@suse.com> changeset: 23866:47ec1d405af9 user: Jan Beulich <jbeulich@suse.com> date: Thu Sep 22 18:31:02 2011 +0100 x86: IO-APIC code has no dependency on PCI The IRQ handling code requires pcidevs_lock to be held only for MSI interrupts. As the handling of which was now fully moved into msi.c (i.e. while applying fine without, the patch needs to be applied after the one titled "x86: split MSI IRQ chip"), io_apic.c now also doesn't need to include PCI headers anymore. Signed-off-by: Jan Beulich <jbeulich@suse.com> changeset: 23865:d6e01c7853cf user: Jan Beulich <jbeulich@suse.com> date: Thu Sep 22 18:29:19 2011 +0100 PCI multi-seg: config space accessor adjustments Signed-off-by: Jan Beulich <jbeulich@suse.com> changeset: 23864:314b147d524d user: Jan Beulich <jbeulich@suse.com> date: Thu Sep 22 18:28:38 2011 +0100 PCI multi-seg: Pass-through adjustments Signed-off-by: Jan Beulich <jbeulich@suse.com> changeset: 23863:9e0259239822 user: Jan Beulich <jbeulich@suse.com> date: Thu Sep 22 18:28:03 2011 +0100 PCI multi-seg: AMD-IOMMU specific adjustments There are two places here where it is entirely unclear to me where the necessary PCI segment number should be taken from (as IVMD descriptors don't have such, only IVHD ones do). AMD confirmed that for the time being it is acceptable to imply that only segment 0 exists. Signed-off-by: Jan Beulich <jbeulich@suse.com> changeset: 23862:85418e168527 user: Jan Beulich <jbeulich@suse.com> date: Thu Sep 22 18:27:26 2011 +0100 PCI multi-seg: VT-d specific adjustments Signed-off-by: Jan Beulich <jbeulich@suse.com> changeset: 23861:ec7c81fbe0de user: Jan Beulich <jbeulich@suse.com> date: Thu Sep 22 18:26:54 2011 +0100 PCI multi-seg: adjust domctl interface Again, a couple of directly related functions at once get adjusted to account for the segment number. Signed-off-by: Jan Beulich <jbeulich@suse.com> changeset: 23860:a422e2a4451e user: Jan Beulich <jbeulich@suse.com> date: Sun Sep 18 00:26:52 2011 +0100 x86: split MSI IRQ chip With the .end() accessor having become optional and noting that several of the accessors' behavior really depends on the result of msi_maskable_irq(), the splits the MSI IRQ chip type into two - one for the maskable ones, and the other for the (MSI only) non-maskable ones. At once the implementation of those methods gets moved from io_apic.c to msi.c. Signed-off-by: Jan Beulich <jbeulich@suse.com> ======================================== commit cd776ee9408ff127f934a707c1a339ee600bc127 Author: Ian Jackson <ian.jackson@eu.citrix.com> Date: Tue Jun 28 13:50:53 2011 +0100 qemu-char.c: fix incorrect CONFIG_STUBDOM handling qemu-char.c:1123:7: warning: "CONFIG_STUBDOM" is not defined [-Wundef] Signed-off-by: Olaf Hering <olaf@aepfle.de> Acked-by: Ian Jackson <ian.jackson@eu.citrix.com> _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel From xen-devel-bounces@lists.xensource.com Sat Sep 24 17:42:14 2011 Return-path: <xen-devel-bounces@lists.xensource.com> Envelope-to: www-data@lists.xensource.com Delivery-date: Sat, 24 Sep 2011 17:42:14 -0700 Received: from localhost ([127.0.0.1] helo=lists.colo.xensource.com) by lists.xensource.com with esmtp (Exim 4.43) id 1R7cnO-0001Ef-Cn; Sat, 24 Sep 2011 17:42:14 -0700 Received: from mail27.messagelabs.com ([193.109.254.147]) by lists.xensource.com with esmtp (Exim 4.43) id 1R7cmf-00012X-Bc for xen-devel@lists.xensource.com; Sat, 24 Sep 2011 17:41:30 -0700 X-Env-Sender: Ian.Jackson@eu.citrix.com X-Msg-Ref: server-15.tower-27.messagelabs.com!1316911277!50130378!1 X-Originating-IP: [62.200.22.115] X-StarScan-Version: 6.4.1; banners=-,-,- X-VirusChecked: Checked Received: (qmail 21316 invoked from network); 25 Sep 2011 00:41:17 -0000 Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115) by server-15.tower-27.messagelabs.com with RC4-SHA encrypted SMTP; 25 Sep 2011 00:41:17 -0000 X-IronPort-AV: E=Sophos;i="4.68,436,1312156800"; d="scan'208";a="8043949" Received: from lonpmailmx01.citrite.net ([10.30.203.162]) by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5; 25 Sep 2011 00:41:25 +0000 Received: from woking.xci-test.com (10.80.248.135) by smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id 8.3.137.0; Sun, 25 Sep 2011 01:41:25 +0100 Received: from osstest by woking.xci-test.com with local (Exim 4.69) (envelope-from <ian.jackson@eu.citrix.com>) id 1R7cma-0002NS-UO; Sun, 25 Sep 2011 01:41:25 +0100 To: xen-devel@lists.xensource.com Message-ID: <osstest-9072-mainreport@xen.org> From: xen.org <ian.jackson@eu.citrix.com> Date: Sun, 25 Sep 2011 01:41:24 +0100 MIME-Version: 1.0 Content-Type: text/plain Cc: ian.jackson@eu.citrix.com Subject: [Xen-devel] [linux test] 9072: tolerable FAIL X-BeenThere: xen-devel@lists.xensource.com X-Mailman-Version: 2.1.5 Precedence: list List-Id: Xen developer discussion <xen-devel.lists.xensource.com> List-Unsubscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe> List-Post: <mailto:xen-devel@lists.xensource.com> List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help> List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=subscribe> Sender: xen-devel-bounces@lists.xensource.com Errors-To: xen-devel-bounces@lists.xensource.com flight 9072 linux real [real] http://www.chiark.greenend.org.uk/~xensrcts/logs/9072/ Failures :-/ but no regressions. Tests which are failing intermittently (not blocking): test-amd64-amd64-xl-sedf 14 guest-localmigrate/x10 fail pass in 9070 Tests which did not succeed, but are not blocking, including regressions (tests previously passed) regarded as allowable: test-amd64-amd64-xl-pcipt-intel 9 guest-start fail never pass test-amd64-i386-rhel6hvm-amd 9 guest-start.2 fail never pass test-amd64-i386-rhel6hvm-intel 9 guest-start.2 fail never pass test-amd64-i386-win-vcpus1 16 leak-check/check fail never pass test-amd64-i386-xl-win-vcpus1 13 guest-stop fail never pass test-amd64-amd64-win 16 leak-check/check fail never pass test-amd64-amd64-xl-win 13 guest-stop fail never pass test-i386-i386-win 16 leak-check/check fail never pass test-i386-i386-xl-win 13 guest-stop fail never pass test-amd64-i386-win 16 leak-check/check fail never pass version targeted for testing: linux 6bec8b4a4c14095d0b7ce424db9d583c3decae6c baseline version: linux 1c3f03ccc5258887f5f2cafc0836a865834f9205 ------------------------------------------------------------ People who touched revisions under test: Jeremy Fitzhardinge <jeremy.fitzhardinge@citrix.com> ------------------------------------------------------------ jobs: build-amd64 pass build-i386 pass build-amd64-pvops pass build-i386-pvops pass test-amd64-amd64-xl pass test-amd64-i386-xl pass test-i386-i386-xl pass test-amd64-i386-rhel6hvm-amd fail test-amd64-i386-xl-credit2 pass test-amd64-amd64-xl-pcipt-intel fail test-amd64-i386-rhel6hvm-intel fail test-amd64-i386-xl-multivcpu pass test-amd64-amd64-pair pass test-amd64-i386-pair pass test-i386-i386-pair pass test-amd64-amd64-pv pass test-amd64-i386-pv pass test-i386-i386-pv pass test-amd64-amd64-xl-sedf fail test-amd64-i386-win-vcpus1 fail test-amd64-i386-xl-win-vcpus1 fail test-amd64-amd64-win fail test-amd64-i386-win fail test-i386-i386-win fail test-amd64-amd64-xl-win fail test-i386-i386-xl-win fail ------------------------------------------------------------ sg-report-flight on woking.cam.xci-test.com logs: /home/xc_osstest/logs images: /home/xc_osstest/images Logs, config files, etc. are available at http://www.chiark.greenend.org.uk/~xensrcts/logs Test harness code can be found at http://xenbits.xensource.com/gitweb?p=osstest.git;a=summary Pushing revision : + branch=linux + revision=6bec8b4a4c14095d0b7ce424db9d583c3decae6c + . cri-lock-repos ++ . cri-common +++ umask 002 +++ getconfig Repos +++ perl -e ' use Osstest; readconfigonly(); print $c{Repos} or die $!; ' ++ repos=/export/home/osstest/repos ++ repos_lock=/export/home/osstest/repos/lock ++ '[' x '!=' x/export/home/osstest/repos/lock ']' ++ OSSTEST_REPOS_LOCK_LOCKED=/export/home/osstest/repos/lock ++ exec with-lock-ex -w /export/home/osstest/repos/lock ./ap-push linux 6bec8b4a4c14095d0b7ce424db9d583c3decae6c + branch=linux + revision=6bec8b4a4c14095d0b7ce424db9d583c3decae6c + . cri-lock-repos ++ . cri-common +++ umask 002 +++ getconfig Repos +++ perl -e ' use Osstest; readconfigonly(); print $c{Repos} or die $!; ' ++ repos=/export/home/osstest/repos ++ repos_lock=/export/home/osstest/repos/lock ++ '[' x/export/home/osstest/repos/lock '!=' x/export/home/osstest/repos/lock ']' + : xen@xenbits.xensource.com + : xen@xenbits.xensource.com:git/linux-pvops + : master + : tested/2.6.39.x + case "$branch" in + cd /export/home/osstest/repos/xen ./ap-push: line 20: cd: /export/home/osstest/repos/xen: No such file or directory ------------------------------------------------------------ commit 6bec8b4a4c14095d0b7ce424db9d583c3decae6c Author: Jeremy Fitzhardinge <jeremy.fitzhardinge@citrix.com> Date: Fri Sep 2 12:23:22 2011 -0700 Revert "xen/apic: Provide an 'apic_xen' to set the override the apic->[read|write] for all cases." This reverts commit c3dd7941354fa96a71f2613e2c7a1b215fa175dc. It prevents the kernel from booting natively on hardware. Conflicts: arch/x86/xen/enlighten.c Signed-off-by: Jeremy Fitzhardinge <jeremy.fitzhardinge@citrix.com> _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel From xen-users-bounces@lists.xensource.com Sat Sep 24 19:19:25 2011 Return-path: <xen-users-bounces@lists.xensource.com> Envelope-to: www-data@lists.xensource.com Delivery-date: Sat, 24 Sep 2011 19:19:25 -0700 Received: from localhost ([127.0.0.1] helo=lists.colo.xensource.com) by lists.xensource.com with esmtp (Exim 4.43) id 1R7eJR-0004iz-HZ; Sat, 24 Sep 2011 19:19:25 -0700 Received: from mail27.messagelabs.com ([193.109.254.147]) by lists.xensource.com with smtp (Exim 4.43) id 1R7eHl-00045u-I1 for xen-users@lists.xensource.com; Sat, 24 Sep 2011 19:17:43 -0700 X-Env-Sender: jim_burn@bellsouth.net X-Msg-Ref: server-15.tower-27.messagelabs.com!1316917048!50133621!1 X-Originating-IP: [66.94.237.215] X-StarScan-Version: 6.4.1; banners=-,-,- X-VirusChecked: Checked Received: (qmail 19454 invoked from network); 25 Sep 2011 02:17:29 -0000 Received: from nm14.access.bullet.mail.mud.yahoo.com (HELO nm14.access.bullet.mail.mud.yahoo.com) (66.94.237.215) by server-15.tower-27.messagelabs.com with SMTP; 25 Sep 2011 02:17:29 -0000 Received: from [66.94.237.192] by nm14.access.bullet.mail.mud.yahoo.com with NNFMP; 25 Sep 2011 02:17:37 -0000 Received: from [66.94.237.98] by tm3.access.bullet.mail.mud.yahoo.com with NNFMP; 25 Sep 2011 02:17:37 -0000 Received: from [127.0.0.1] by omp1003.access.mail.mud.yahoo.com with NNFMP; 25 Sep 2011 02:17:37 -0000 X-Yahoo-Newman-Id: 649556.16722.bm@omp1003.access.mail.mud.yahoo.com Received: (qmail 50745 invoked from network); 25 Sep 2011 02:17:37 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=bellsouth.net; s=s1024; t=1316917057; bh=HmV6VlDvkfr/asi1nPkQkutm2p8EKsWbkCWAhh9DUzQ=; h=X-Yahoo-Newman-Property:X-YMail-OSG:X-Yahoo-SMTP:Received:From:To:Cc:Subject:Date:Message-ID:User-Agent:In-Reply-To:References:MIME-Version:Content-Transfer-Encoding:Content-Type; b=qSSezWMxX5ugQowGiUsRK8TkKBvNOMR/IrlxVr31huxuqq4LbngZxJfLNK3CoFRicFuO7mXTw/QQN6l5Ktz5T61EqqtzvRfkzUE0AuKcra815YOdAdcmFSHPWl2IloRLLg9Yp1Hb+/A5rxhoRJ+TRLu2Gn15ELZKdxCjeihAv/U= X-Yahoo-Newman-Property: ymail-3 X-YMail-OSG: ocszdIkVM1mevA5HEXSDKX5szC8HR.JirQRd6Utf9SV1FLY MyFuZ78WqrEiLOguTsUDyr_cHgT8lokbiTUDCWYzP7laV42Fx8eYMIB7zdyV U4kMlRsFCC0Z7dM9upk5WhWxbSLM3inYTEZVMml.JsFQAvRD3gBehuwG.NhT X_RpfOu_jixfyismHm56xka5WqGEKjtHa4HMJOfWKWn8.mzdHjRtEMs9Jr.A 1exz2rR2iHlrpexdCmFSG2DJw.jWfe9Ek3sEG06Q1zP94p721ylnn09xMvNy 5GfM4w0saWVpzfrQGIgr4ph6ZSq7sxDanTtqG8y87YQI.KmWlGT9VE2AuHfg .2EF6xvSEaBHladayQcUvsAqw1rftJh0_O4GynrPETw.0B6nkC3vpc20r0Yk SpmFSytGjUoJ07JvAWn5lda24qhtPSyHfcFEhHv7XcEkNFGTn1mAMxadUhtn urV0u8LwQVOTkulGgOWbPNiNm.57aOVRn2_QEYdgCD0Ept8zeBEF.2TnoGq8 TtgjEsfPeueswXrSyuH4c3n.1VuExeWpLppyLIk3yrUc5.8Nr.HR2qdlH5gv et_NiCvatI_3kTYSzryENSCLgwu2f_Z_E_6aZYlZ7X5FMNgCncv9Dg875m0b Z4hPx7BuxCUDfc0IRbGlPfKFV X-Yahoo-SMTP: g0AhWW2swBA2djJKuhuwxPlPqLrHlDrycdPnfR9kZNrpKCA- Received: from dell4550.localnet (jim_burn@184.36.204.110 with plain) by smtp101.sbc.mail.bf1.yahoo.com with SMTP; 24 Sep 2011 19:17:36 -0700 PDT From: jim burns <jim_burn@bellsouth.net> To: xen-users@lists.xensource.com, xen-devel@lists.xensource.com Subject: Re: [Xen-users] Is xen planning to support hvm guests booting under UEFI? Date: Sat, 24 Sep 2011 22:17:30 -0400 Message-ID: <2744508.hgiQGpxhdI@dell4550> User-Agent: KMail/4.7.1 (Linux/2.6.37.6-0.7-default; KDE/4.7.1; i686; ; ) In-Reply-To: <CAMrPLW+rL-O9VYYgOU=_ojhE352YTOJyOfw38qfXu3KUjautug@mail.gmail.com> References: <2082539.WE5RVzqO5R@dell4550> <4597364.LrXQjvBoPa@dell4550> <CAMrPLW+rL-O9VYYgOU=_ojhE352YTOJyOfw38qfXu3KUjautug@mail.gmail.com> MIME-Version: 1.0 Content-Transfer-Encoding: 7Bit Content-Type: text/plain; charset="us-ascii" Cc: Todd Deshane <todd.deshane@xen.org> X-BeenThere: xen-users@lists.xensource.com X-Mailman-Version: 2.1.5 Precedence: list List-Id: Xen user discussion <xen-users.lists.xensource.com> List-Unsubscribe: <http://lists.xensource.com/mailman/listinfo/xen-users>, <mailto:xen-users-request@lists.xensource.com?subject=unsubscribe> List-Post: <mailto:xen-users@lists.xensource.com> List-Help: <mailto:xen-users-request@lists.xensource.com?subject=help> List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-users>, <mailto:xen-users-request@lists.xensource.com?subject=subscribe> Sender: xen-users-bounces@lists.xensource.com Errors-To: xen-users-bounces@lists.xensource.com On Sat September 24 2011, 6:43:42 PM, Todd Deshane wrote: > On Sat, Sep 24, 2011 at 5:34 PM, jim burns <jim_burn@bellsouth.net> wrote: > > On Wed September 21 2011, 9:06:38 PM, jim burns wrote: > >> Pls cc: me as I am not subscribed. > > > > [...] > > http://wiki.xensource.com/xenwiki/XenParavirtOps has been reworked > > recently. Not sure if this was there before: > > > > "Add EFI support in Linux pv-ops. Jan Beulich wrote patches to make Xen > > hypervisor be able to compile as an EFI application. "Build xen.efi, > > write up a config file for it to read (most importantly so it knows > > what Dom0 kernel and initrd to use), and you should be good to go > > (provided the EFI implementation isn't too flawed). This being an EFI > > application you can simply run it from the shell prompt. Parameter for > > Xen.efi is -cfg <file>, and <file> has: kernel=, ramdisk=, options=, > > video=gfx-x. The Linux pv-ops needs at least to parse > > XEN_VGATYPE_EFI_LFB data, E820 parsed (should be working) and give the > > ACPI subsystem a pointer to the ACPI DSDT without consulting EBDA." > > > > This doesn't solve the Windows 8 hvm problem, but at least EFI is being > > considered. > > There was a google summer of code project around UEFI: > http://code.google.com/p/google-summer-of-code-2011-tianocore/downloads/deta > il?name=Bei_Guan.tar.gz&can=2&q= > > I don't know if it was submitted to xen-devel, but you can follow up > with the xen-devel mailing list if you are interested. > > Hope that helps. The article I quoted was from http://www.itworld.com/it- managementstrategy/205255/windows-8-oem-specs- may-block-linux-booting : "Red Hat's Matthew Garrett was one of the first to notice that according to the new logo rules, all Windows 8 machines will need to be have the Unified Extensible Firmware Interface (UEFI) instead of the venerable BIOS firmware layer. BIOS has been pretty much the sole firmware interface for PCs for a long time. The EFI system has slowly been making headway in recent years, and right now EFI firmware is compatible with Windows supporting the GUID Partition Table (GPT), OS X/Intel, and Linux 2.6 and beyond machines. EFI is seen as a better hardware/software interface than BIOS, since it is platform-agnostic, runs in 32- or 64-bit mode, and GPT machines can handle boot partitions of up to 9.4 zettabytes. (That's 9.5 billion terabytes to you and me.) EFI, and the later UEFI specification, is not the problem for Linux. The problem is Microsoft's other requirement for any Windows 8-certified client: the system must support secure booting. This hardened boot means that "all firmware and software in the boot process must be signed by a trusted Certificate Authority (CA)," according to slides from a recent presentation on the UEFI boot process made by Arie van der Hoeven, Microsoft Principal Lead Program Manager." Putting aside the signing problem for now, the immediate problem is qemu-dm as the emulator for hvm guests, since it provides an emulated *bios*. Or hvmloader as the bootloader. The url Todd provides points to a project to modify 'ovmf', an EFI bootloader, to be xen hvm aware. Windows 8 will be a game changer, if the article is right. Hope plans are being made to incorporate some sort of EFI bootloader into xen. _______________________________________________ Xen-users mailing list Xen-users@lists.xensource.com http://lists.xensource.com/xen-users From xen-devel-bounces@lists.xensource.com Sat Sep 24 20:07:53 2011 Return-path: <xen-devel-bounces@lists.xensource.com> Envelope-to: www-data@lists.xensource.com Delivery-date: Sat, 24 Sep 2011 20:07:53 -0700 Received: from localhost ([127.0.0.1] helo=lists.colo.xensource.com) by lists.xensource.com with esmtp (Exim 4.43) id 1R7f4K-0007Dz-BD; Sat, 24 Sep 2011 20:07:52 -0700 Received: from mail174.messagelabs.com ([85.158.138.51]) by lists.xensource.com with esmtp (Exim 4.43) id 1R7f2t-000718-DG for xen-devel@lists.xensource.com; Sat, 24 Sep 2011 20:06:44 -0700 X-Env-Sender: Ian.Jackson@eu.citrix.com X-Msg-Ref: server-2.tower-174.messagelabs.com!1316919980!32645196!1 X-Originating-IP: [62.200.22.115] X-StarScan-Version: 6.4.1; banners=-,-,- X-VirusChecked: Checked Received: (qmail 24880 invoked from network); 25 Sep 2011 03:06:20 -0000 Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115) by server-2.tower-174.messagelabs.com with RC4-SHA encrypted SMTP; 25 Sep 2011 03:06:20 -0000 X-IronPort-AV: E=Sophos;i="4.68,438,1312156800"; d="scan'208";a="8044112" Received: from lonpmailmx01.citrite.net ([10.30.203.162]) by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5; 25 Sep 2011 03:06:02 +0000 Received: from woking.xci-test.com (10.80.248.135) by smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id 8.3.137.0; Sun, 25 Sep 2011 04:06:03 +0100 Received: from osstest by woking.xci-test.com with local (Exim 4.69) (envelope-from <ian.jackson@eu.citrix.com>) id 1R7f2Y-0008Rr-Cn; Sun, 25 Sep 2011 04:06:02 +0100 To: xen-devel@lists.xensource.com Message-ID: <osstest-9073-mainreport@xen.org> From: xen.org <ian.jackson@eu.citrix.com> Date: Sun, 25 Sep 2011 04:06:02 +0100 MIME-Version: 1.0 Content-Type: text/plain Cc: ian.jackson@eu.citrix.com Subject: [Xen-devel] [xen-unstable test] 9073: regressions - FAIL X-BeenThere: xen-devel@lists.xensource.com X-Mailman-Version: 2.1.5 Precedence: list List-Id: Xen developer discussion <xen-devel.lists.xensource.com> List-Unsubscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe> List-Post: <mailto:xen-devel@lists.xensource.com> List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help> List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=subscribe> Sender: xen-devel-bounces@lists.xensource.com Errors-To: xen-devel-bounces@lists.xensource.com flight 9073 xen-unstable real [real] http://www.chiark.greenend.org.uk/~xensrcts/logs/9073/ Regressions :-( Tests which did not succeed and are blocking: test-amd64-i386-rhel6hvm-amd 5 xen-boot fail REGR. vs. 8995 Tests which are failing intermittently (not blocking): test-amd64-i386-xl-credit2 5 xen-boot fail pass in 9071 test-amd64-amd64-xl-sedf 5 xen-boot fail pass in 9067 test-amd64-i386-xl-win-vcpus1 5 xen-boot fail pass in 9065 test-i386-i386-xl-win 5 xen-boot fail pass in 9067 test-amd64-amd64-win 5 xen-boot fail pass in 9069 test-i386-i386-win 5 xen-boot fail pass in 9071 test-amd64-i386-win-vcpus1 5 xen-boot fail pass in 9071 test-amd64-i386-win 5 xen-boot fail pass in 9071 test-amd64-i386-pv 5 xen-boot fail in 9071 pass in 9073 test-i386-i386-pv 5 xen-boot fail in 9071 pass in 9073 test-i386-i386-pair 8 xen-boot/dst_host fail in 9071 pass in 9073 test-i386-i386-pair 7 xen-boot/src_host fail in 9071 pass in 9073 test-amd64-amd64-xl 5 xen-boot fail in 9067 pass in 9073 test-amd64-amd64-pv 5 xen-boot fail in 9067 pass in 9073 test-amd64-i386-xl-multivcpu 5 xen-boot fail in 9067 pass in 9073 test-amd64-i386-xl 5 xen-boot fail in 9067 pass in 9073 test-i386-i386-xl 5 xen-boot fail in 9067 pass in 9073 test-amd64-amd64-xl-win 5 xen-boot fail in 9067 pass in 9073 Tests which did not succeed, but are not blocking, including regressions (tests previously passed) regarded as allowable: test-amd64-amd64-xl-pcipt-intel 9 guest-start fail never pass test-amd64-i386-rhel6hvm-intel 9 guest-start.2 fail never pass test-amd64-amd64-xl-win 13 guest-stop fail never pass test-i386-i386-win 16 leak-check/check fail in 9071 never pass test-amd64-i386-win-vcpus1 16 leak-check/check fail in 9071 never pass test-amd64-i386-win 16 leak-check/check fail in 9071 never pass test-i386-i386-xl-win 13 guest-stop fail in 9067 never pass test-amd64-amd64-win 16 leak-check/check fail in 9067 never pass test-amd64-i386-xl-win-vcpus1 13 guest-stop fail in 9065 never pass version targeted for testing: xen cc339ab1d917 baseline version: xen a422e2a4451e ------------------------------------------------------------ People who touched revisions under test: Andreas Herrmann <herrmann.der.user@googlemail.com> Ian Campbell <ian.campbell@citrix.com> Ian Jackson <ian.jackson@eu.citrix.com> Jan Beulich <jbeulich@suse.com> Lasse Collin <lasse.collin@tukaani.org> Olaf Hering <olaf@aepfle.de> Thomas Renninger <trenn@suse.de> ------------------------------------------------------------ jobs: build-amd64 pass build-i386 pass build-amd64-oldkern pass build-i386-oldkern pass build-amd64-pvops pass build-i386-pvops pass test-amd64-amd64-xl pass test-amd64-i386-xl pass test-i386-i386-xl pass test-amd64-i386-rhel6hvm-amd fail test-amd64-i386-xl-credit2 fail test-amd64-amd64-xl-pcipt-intel fail test-amd64-i386-rhel6hvm-intel fail test-amd64-i386-xl-multivcpu pass test-amd64-amd64-pair pass test-amd64-i386-pair pass test-i386-i386-pair pass test-amd64-amd64-pv pass test-amd64-i386-pv pass test-i386-i386-pv pass test-amd64-amd64-xl-sedf fail test-amd64-i386-win-vcpus1 fail test-amd64-i386-xl-win-vcpus1 fail test-amd64-amd64-win fail test-amd64-i386-win fail test-i386-i386-win fail test-amd64-amd64-xl-win fail test-i386-i386-xl-win fail ------------------------------------------------------------ sg-report-flight on woking.cam.xci-test.com logs: /home/xc_osstest/logs images: /home/xc_osstest/images Logs, config files, etc. are available at http://www.chiark.greenend.org.uk/~xensrcts/logs Test harness code can be found at http://xenbits.xensource.com/gitweb?p=osstest.git;a=summary Not pushing. ------------------------------------------------------------ changeset: 23872:cc339ab1d917 tag: tip user: Ian Campbell <ian.campbell@citrix.com> date: Thu Sep 22 18:37:06 2011 +0100 tools: fix install of lomount $(BIN) went away in 23124:e3d4c34b14a3. Also there are no *.so, *.a or *.rpm built in here Signed-off-by: Ian Campbell <ian.campbell@citrix.com> changeset: 23871:503ee256fecf user: Jan Beulich <jbeulich@suse.com> date: Thu Sep 22 18:35:30 2011 +0100 x86: ucode-amd: Don't warn when no ucode is available for a CPU revision This patch originally comes from the Linus mainline kernel (2.6.33), find below the patch details: From: Andreas Herrmann <herrmann.der.user@googlemail.com> There is no point in warning when there is no ucode available for a specific CPU revision. Currently the container-file, which provides the AMD ucode patches for OS load, contains only a few ucode patches. It's already clearly indicated by the printed patch_level whenever new ucode was available and an update happened. So the warning message is of no help but rather annoying on systems with many CPUs. Signed-off-by: Thomas Renninger <trenn@suse.de> Signed-off-by: Jan Beulich <jbeulich@suse.com> changeset: 23870:5c97b02f48fc user: Jan Beulich <jbeulich@suse.com> date: Thu Sep 22 18:34:27 2011 +0100 XZ: Fix incorrect XZ_BUF_ERROR From: Lasse Collin <lasse.collin@tukaani.org> xz_dec_run() could incorrectly return XZ_BUF_ERROR if all of the following was true: - The caller knows how many bytes of output to expect and only provides that much output space. - When the last output bytes are decoded, the caller-provided input buffer ends right before the LZMA2 end of payload marker. So LZMA2 won't provide more output anymore, but it won't know it yet and thus won't return XZ_STREAM_END yet. - A BCJ filter is in use and it hasn't left any unfiltered bytes in the temp buffer. This can happen with any BCJ filter, but in practice it's more likely with filters other than the x86 BCJ. This fixes <https://bugzilla.redhat.com/show_bug.cgi?id=3D735408> where Squashfs thinks that a valid file system is corrupt. This also fixes a similar bug in single-call mode where the uncompressed size of a block using BCJ + LZMA2 was 0 bytes and caller provided no output space. Many empty .xz files don't contain any blocks and thus don't trigger this bug. This also tweaks a closely related detail: xz_dec_bcj_run() could call xz_dec_lzma2_run() to decode into temp buffer when it was known to be useless. This was harmless although it wasted a minuscule number of CPU cycles. Signed-off-by: Lasse Collin <lasse.collin@tukaani.org> Signed-off-by: Jan Beulich <jbeulich@suse.com> changeset: 23869:db1ea4b127cd user: Jan Beulich <jbeulich@suse.com> date: Thu Sep 22 18:33:48 2011 +0100 XZ decompressor: Fix decoding of empty LZMA2 streams From: Lasse Collin <lasse.collin@tukaani.org> The old code considered valid empty LZMA2 streams to be corrupt. Note that a typical empty .xz file has no LZMA2 data at all, and thus most .xz files having no uncompressed data are handled correctly even without this fix. Signed-off-by: Lasse Collin <lasse.collin@tukaani.org> Signed-off-by: Jan Beulich <jbeulich@suse.com> changeset: 23868:28147fd781af user: Jan Beulich <jbeulich@suse.com> date: Thu Sep 22 18:32:34 2011 +0100 VT-d: fix off-by-one error in RMRR validation (base_addr,end_addr) is an inclusive range, and hence there shouldn't be a subtraction of 1 in the second invocation of page_is_ram_type(). For RMRRs covering a single page that actually resulted in the immediately preceding page to get checked (which could have resulted in a false warning). Signed-off-by: Jan Beulich <jbeulich@suse.com> changeset: 23867:571b6e90dfb4 user: Jan Beulich <jbeulich@suse.com> date: Thu Sep 22 18:31:44 2011 +0100 VT-d: eliminate a mis-use of pcidevs_lock dma_pte_clear_one() shouldn't acquire this global lock for the purpose of processing a per-domain list. Furthermore the function a few lines earlier has a comment stating that acquiring pcidevs_lock isn't necessary here (whether that's really correct is another question). Use the domain's mappin_lock instead to protect the mapped_rmrrs list. Fold domain_rmrr_mapped() into its sole caller so that the otherwise implicit dependency on pcidevs_lock there becomes more obvious (see the comment there). Signed-off-by: Jan Beulich <jbeulich@suse.com> changeset: 23866:47ec1d405af9 user: Jan Beulich <jbeulich@suse.com> date: Thu Sep 22 18:31:02 2011 +0100 x86: IO-APIC code has no dependency on PCI The IRQ handling code requires pcidevs_lock to be held only for MSI interrupts. As the handling of which was now fully moved into msi.c (i.e. while applying fine without, the patch needs to be applied after the one titled "x86: split MSI IRQ chip"), io_apic.c now also doesn't need to include PCI headers anymore. Signed-off-by: Jan Beulich <jbeulich@suse.com> changeset: 23865:d6e01c7853cf user: Jan Beulich <jbeulich@suse.com> date: Thu Sep 22 18:29:19 2011 +0100 PCI multi-seg: config space accessor adjustments Signed-off-by: Jan Beulich <jbeulich@suse.com> changeset: 23864:314b147d524d user: Jan Beulich <jbeulich@suse.com> date: Thu Sep 22 18:28:38 2011 +0100 PCI multi-seg: Pass-through adjustments Signed-off-by: Jan Beulich <jbeulich@suse.com> changeset: 23863:9e0259239822 user: Jan Beulich <jbeulich@suse.com> date: Thu Sep 22 18:28:03 2011 +0100 PCI multi-seg: AMD-IOMMU specific adjustments There are two places here where it is entirely unclear to me where the necessary PCI segment number should be taken from (as IVMD descriptors don't have such, only IVHD ones do). AMD confirmed that for the time being it is acceptable to imply that only segment 0 exists. Signed-off-by: Jan Beulich <jbeulich@suse.com> changeset: 23862:85418e168527 user: Jan Beulich <jbeulich@suse.com> date: Thu Sep 22 18:27:26 2011 +0100 PCI multi-seg: VT-d specific adjustments Signed-off-by: Jan Beulich <jbeulich@suse.com> changeset: 23861:ec7c81fbe0de user: Jan Beulich <jbeulich@suse.com> date: Thu Sep 22 18:26:54 2011 +0100 PCI multi-seg: adjust domctl interface Again, a couple of directly related functions at once get adjusted to account for the segment number. Signed-off-by: Jan Beulich <jbeulich@suse.com> changeset: 23860:a422e2a4451e user: Jan Beulich <jbeulich@suse.com> date: Sun Sep 18 00:26:52 2011 +0100 x86: split MSI IRQ chip With the .end() accessor having become optional and noting that several of the accessors' behavior really depends on the result of msi_maskable_irq(), the splits the MSI IRQ chip type into two - one for the maskable ones, and the other for the (MSI only) non-maskable ones. At once the implementation of those methods gets moved from io_apic.c to msi.c. Signed-off-by: Jan Beulich <jbeulich@suse.com> ======================================== commit cd776ee9408ff127f934a707c1a339ee600bc127 Author: Ian Jackson <ian.jackson@eu.citrix.com> Date: Tue Jun 28 13:50:53 2011 +0100 qemu-char.c: fix incorrect CONFIG_STUBDOM handling qemu-char.c:1123:7: warning: "CONFIG_STUBDOM" is not defined [-Wundef] Signed-off-by: Olaf Hering <olaf@aepfle.de> Acked-by: Ian Jackson <ian.jackson@eu.citrix.com> _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel From xen-devel-bounces@lists.xensource.com Sat Sep 24 22:12:18 2011 Return-path: <xen-devel-bounces@lists.xensource.com> Envelope-to: www-data@lists.xensource.com Delivery-date: Sat, 24 Sep 2011 22:12:18 -0700 Received: from localhost ([127.0.0.1] helo=lists.colo.xensource.com) by lists.xensource.com with esmtp (Exim 4.43) id 1R7h0j-0001c2-8J; Sat, 24 Sep 2011 22:12:17 -0700 Received: from mail21.messagelabs.com ([85.158.143.35]) by lists.xensource.com with esmtp (Exim 4.43) id 1R7gzk-0001Pi-HW for xen-devel@lists.xensource.com; Sat, 24 Sep 2011 22:11:21 -0700 X-Env-Sender: Ian.Jackson@eu.citrix.com X-Msg-Ref: server-5.tower-21.messagelabs.com!1316927438!49401456!1 X-Originating-IP: [62.200.22.115] X-StarScan-Version: 6.4.1; banners=-,-,- X-VirusChecked: Checked Received: (qmail 829 invoked from network); 25 Sep 2011 05:10:39 -0000 Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115) by server-5.tower-21.messagelabs.com with RC4-SHA encrypted SMTP; 25 Sep 2011 05:10:39 -0000 X-IronPort-AV: E=Sophos;i="4.68,438,1312156800"; d="scan'208";a="8044275" Received: from lonpmailmx01.citrite.net ([10.30.203.162]) by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5; 25 Sep 2011 05:11:12 +0000 Received: from woking.xci-test.com (10.80.248.135) by smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id 8.3.137.0; Sun, 25 Sep 2011 06:11:12 +0100 Received: from osstest by woking.xci-test.com with local (Exim 4.69) (envelope-from <ian.jackson@eu.citrix.com>) id 1R7gzg-0005LA-EB; Sun, 25 Sep 2011 06:11:12 +0100 To: xen-devel@lists.xensource.com Message-ID: <osstest-9074-mainreport@xen.org> From: xen.org <ian.jackson@eu.citrix.com> Date: Sun, 25 Sep 2011 06:11:12 +0100 MIME-Version: 1.0 Content-Type: text/plain Cc: ian.jackson@eu.citrix.com Subject: [Xen-devel] [linux test] 9074: tolerable FAIL X-BeenThere: xen-devel@lists.xensource.com X-Mailman-Version: 2.1.5 Precedence: list List-Id: Xen developer discussion <xen-devel.lists.xensource.com> List-Unsubscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe> List-Post: <mailto:xen-devel@lists.xensource.com> List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help> List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=subscribe> Sender: xen-devel-bounces@lists.xensource.com Errors-To: xen-devel-bounces@lists.xensource.com flight 9074 linux real [real] http://www.chiark.greenend.org.uk/~xensrcts/logs/9074/ Failures :-/ but no regressions. Tests which are failing intermittently (not blocking): test-i386-i386-win 5 xen-boot fail pass in 9072 test-amd64-amd64-xl-sedf 14 guest-localmigrate/x10 fail in 9072 pass in 9074 Tests which did not succeed, but are not blocking, including regressions (tests previously passed) regarded as allowable: test-amd64-amd64-xl-pcipt-intel 9 guest-start fail never pass test-amd64-i386-rhel6hvm-amd 9 guest-start.2 fail never pass test-amd64-i386-rhel6hvm-intel 9 guest-start.2 fail never pass test-amd64-i386-win-vcpus1 16 leak-check/check fail never pass test-amd64-i386-xl-win-vcpus1 13 guest-stop fail never pass test-amd64-amd64-win 16 leak-check/check fail never pass test-amd64-amd64-xl-win 13 guest-stop fail never pass test-i386-i386-xl-win 13 guest-stop fail never pass test-amd64-i386-win 16 leak-check/check fail never pass test-i386-i386-win 16 leak-check/check fail in 9072 never pass version targeted for testing: linux 6bec8b4a4c14095d0b7ce424db9d583c3decae6c baseline version: linux 1c3f03ccc5258887f5f2cafc0836a865834f9205 ------------------------------------------------------------ People who touched revisions under test: Jeremy Fitzhardinge <jeremy.fitzhardinge@citrix.com> ------------------------------------------------------------ jobs: build-amd64 pass build-i386 pass build-amd64-pvops pass build-i386-pvops pass test-amd64-amd64-xl pass test-amd64-i386-xl pass test-i386-i386-xl pass test-amd64-i386-rhel6hvm-amd fail test-amd64-i386-xl-credit2 pass test-amd64-amd64-xl-pcipt-intel fail test-amd64-i386-rhel6hvm-intel fail test-amd64-i386-xl-multivcpu pass test-amd64-amd64-pair pass test-amd64-i386-pair pass test-i386-i386-pair pass test-amd64-amd64-pv pass test-amd64-i386-pv pass test-i386-i386-pv pass test-amd64-amd64-xl-sedf pass test-amd64-i386-win-vcpus1 fail test-amd64-i386-xl-win-vcpus1 fail test-amd64-amd64-win fail test-amd64-i386-win fail test-i386-i386-win fail test-amd64-amd64-xl-win fail test-i386-i386-xl-win fail ------------------------------------------------------------ sg-report-flight on woking.cam.xci-test.com logs: /home/xc_osstest/logs images: /home/xc_osstest/images Logs, config files, etc. are available at http://www.chiark.greenend.org.uk/~xensrcts/logs Test harness code can be found at http://xenbits.xensource.com/gitweb?p=osstest.git;a=summary Pushing revision : + branch=linux + revision=6bec8b4a4c14095d0b7ce424db9d583c3decae6c + . cri-lock-repos ++ . cri-common +++ umask 002 +++ getconfig Repos +++ perl -e ' use Osstest; readconfigonly(); print $c{Repos} or die $!; ' ++ repos=/export/home/osstest/repos ++ repos_lock=/export/home/osstest/repos/lock ++ '[' x '!=' x/export/home/osstest/repos/lock ']' ++ OSSTEST_REPOS_LOCK_LOCKED=/export/home/osstest/repos/lock ++ exec with-lock-ex -w /export/home/osstest/repos/lock ./ap-push linux 6bec8b4a4c14095d0b7ce424db9d583c3decae6c + branch=linux + revision=6bec8b4a4c14095d0b7ce424db9d583c3decae6c + . cri-lock-repos ++ . cri-common +++ umask 002 +++ getconfig Repos +++ perl -e ' use Osstest; readconfigonly(); print $c{Repos} or die $!; ' ++ repos=/export/home/osstest/repos ++ repos_lock=/export/home/osstest/repos/lock ++ '[' x/export/home/osstest/repos/lock '!=' x/export/home/osstest/repos/lock ']' + : xen@xenbits.xensource.com + : xen@xenbits.xensource.com:git/linux-pvops + : master + : tested/2.6.39.x + case "$branch" in + cd /export/home/osstest/repos/xen ./ap-push: line 20: cd: /export/home/osstest/repos/xen: No such file or directory ------------------------------------------------------------ commit 6bec8b4a4c14095d0b7ce424db9d583c3decae6c Author: Jeremy Fitzhardinge <jeremy.fitzhardinge@citrix.com> Date: Fri Sep 2 12:23:22 2011 -0700 Revert "xen/apic: Provide an 'apic_xen' to set the override the apic->[read|write] for all cases." This reverts commit c3dd7941354fa96a71f2613e2c7a1b215fa175dc. It prevents the kernel from booting natively on hardware. Conflicts: arch/x86/xen/enlighten.c Signed-off-by: Jeremy Fitzhardinge <jeremy.fitzhardinge@citrix.com> _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel From xen-devel-bounces@lists.xensource.com Sun Sep 25 01:46:42 2011 Return-path: <xen-devel-bounces@lists.xensource.com> Envelope-to: www-data@lists.xensource.com Delivery-date: Sun, 25 Sep 2011 01:46:42 -0700 Received: from localhost ([127.0.0.1] helo=lists.colo.xensource.com) by lists.xensource.com with esmtp (Exim 4.43) id 1R7kMD-000632-So; Sun, 25 Sep 2011 01:46:41 -0700 Received: from mail21.messagelabs.com ([85.158.143.35]) by lists.xensource.com with smtp (Exim 4.43) id 1R7kLI-0005qi-57 for xen-devel@lists.xensource.com; Sun, 25 Sep 2011 01:45:47 -0700 X-Env-Sender: tinnycloud@hotmail.com X-Msg-Ref: server-12.tower-21.messagelabs.com!1316940324!51227386!1 X-Originating-IP: [65.55.116.39] X-StarScan-Version: 6.4.1; banners=-,-,- X-VirusChecked: Checked Received: (qmail 21856 invoked from network); 25 Sep 2011 08:45:25 -0000 Received: from blu0-omc1-s28.blu0.hotmail.com (HELO blu0-omc1-s28.blu0.hotmail.com) (65.55.116.39) by server-12.tower-21.messagelabs.com with SMTP; 25 Sep 2011 08:45:25 -0000 Received: from BLU157-W25 ([65.55.116.9]) by blu0-omc1-s28.blu0.hotmail.com with Microsoft SMTPSVC(6.0.3790.4675); Sun, 25 Sep 2011 01:45:39 -0700 Message-ID: <BLU157-W25EB1EAC24CC11FA14859ADAF20@phx.gbl> Content-Type: multipart/mixed; boundary="_382051e3-f4e4-4822-8610-a3f7da59baf0_" X-Originating-IP: [121.0.29.75] From: MaoXiaoyun <tinnycloud@hotmail.com> To: <linux-ext4@vger.kernel.org> Date: Sun, 25 Sep 2011 16:45:39 +0800 Importance: Normal In-Reply-To: <BLU157-W7DABA5FE01C50C29B1A64DA060@phx.gbl> References: <BLU157-W499E698F650F554E645F9DDA1C0@phx.gbl>, , <20110906145347.GA4133@dumpdata.com>, <BLU157-W4106FA4CF4EBA78C63FDA0DA1C0@phx.gbl>, <4E666C86.5090707@goop.org>, <BLU157-W323C330706CB8D7E976BC3DA1F0@phx.gbl>, <BLU157-W7DABA5FE01C50C29B1A64DA060@phx.gbl> MIME-Version: 1.0 X-OriginalArrivalTime: 25 Sep 2011 08:45:39.0660 (UTC) FILETIME=[809A30C0:01CC7B5F] Cc: jack@suse.cz, xen devel <xen-devel@lists.xensource.com>, tytso@mit.edu, konrad.wilk@oracle.com Subject: [Xen-devel] [patch 1/1] ext4-fix-dirty-extent-when-origin-leaf-extent-reac.patch X-BeenThere: xen-devel@lists.xensource.com X-Mailman-Version: 2.1.5 Precedence: list List-Id: Xen developer discussion <xen-devel.lists.xensource.com> List-Unsubscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe> List-Post: <mailto:xen-devel@lists.xensource.com> List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help> List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=subscribe> Sender: xen-devel-bounces@lists.xensource.com Errors-To: xen-devel-bounces@lists.xensource.com --_382051e3-f4e4-4822-8610-a3f7da59baf0_ Content-Type: text/plain; charset="gb2312" Content-Transfer-Encoding: 8bit Hi: We met an ext4 BUG_ON in extents.c:1716 which crash kernel flush thread, and result in disk unvailiable. BUG details refer to: http://www.gossamer-threads.com/lists/xen/devel/217091?do=post_view_threaded Attached is the fix, verified in our env. Without this patch, more than 3 servers hit BUG_ON in our hundreds of servers every day. many thanks. --_382051e3-f4e4-4822-8610-a3f7da59baf0_ Content-Type: application/octet-stream Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="0001-ext4-fix_dirty_extent_when_split_max&last_extent.patch" RnJvbSA0NWEwMjdkOTYxZjcyNjMyYjE1YjQ2MzM3ZWJiZDczMTdmNzUyOGVkIE1vbiBTZXAgMTcg MDA6MDA6MDAgMjAwMQpGcm9tOiBYaWFveXVuIE1hbyA8eGlhb3l1bi5tYW94eUBhbGl5dW4taW5j LmNvbT4KRGF0ZTogU3VuLCAyNSBTZXAgMjAxMSAxNjoyNDowMyArMDgwMApTdWJqZWN0OiBbUEFU Q0hdIGV4dDQgOiBmaXggZGlydHkgZXh0ZW50IHdoZW4gb3JpZ2luIGxlYWYgZXh0ZW50IHJlYWNo IG1heAoKRXh0ZW50cyBhcmUgc3VwcG9zZWQgdG8gYmUgZGlydGllZCBpbiBleHQ0X2V4dF9pbnNl cnRfZXh0ZW50LgpUd28gZXhpc3Rpbmcgc2NlbmFyaW9zCjEpIHBhdGggaGFzIGZyZWUgc3BhY2Vz CiAgIGV4dGVudCBpbiBwYXRoIHdpbGwgYmUgZGlydGllZCwgdGhpcyBpcyBjb3JyZWN0CjIpIHBh dGggaGFzIG5vIGZyZWUgc3BhY2VzCiAgIEFjdHVhbGx5IG5ldyBwYXRoIGlzIGRpcnRpZWQsIHRo ZSBvcmlnaW4gcGF0aCBpc24ndCBkaXJ0ZWQsIG1pZ2h0IGNhdXNlIHByb2JsZW0KCnRoZXJlJ3Mg YSBjaGFuY2UgdGhhdCBleHRlbnQgaXMgZm9yZ290dGVuIHRvIG1hcmsgZGlydHkgaW4gZXh0NF9l eHRfY29udmVydF90b19pbml0aWFsaXplZCgpCgpGb3IgZXhhbXBsZTogZXggaXMgdGhlIGxhc3Qg ZXh0ZW5kIGluIGxlYWYgd2hpY2ggaGFzIG5vIGZyZWUgc3BhY2UKZXg6CnsKICBlZV9ibG9jayAg ICAgICAgICA6IDM4ODUKICBpc191bmluaXRpYWxpemVkICA6IFllcwogIGFjdHVhbGx5IGVlX2xl biAgIDogMjExCiAgcGJfYmxvY2sgICAgICAgICAgOiAxMTMwMjA2OTcKfQphZnRlciBpbnNlcnQg aWJsb2NrIDM4ODYgbWF4X2Jsb2NrczogMjEwLCAgZXggd2lsbCBiZSBzcGxpdCBpbnRvCmV4CnsK ICBlZV9ibG9jayAgICAgICAgICA6IDM4ODUKICBpc191bmluaXRpYWxpemVkICA6IFllcwogIGFj dHVhbGx5IGVlX2xlbiAgIDogMQogIHBiX2Jsb2NrICAgICAgICAgIDogMTEzMDIwNjk3Cn0KbmV3 ZXggaW4gbmV3IHBhdGgKewogIGVlX2Jsb2NrICAgICAgICAgIDogMzg4NgogIGlzX3VuaW5pdGlh bGl6ZWQgIDogbm8KICBhY3R1YWxseSBlZV9sZW4gICA6IDIwMAogIHBiX2Jsb2NrICAgICAgICAg IDogMTEzMDIwNjk4Cn0KCmV4IGlzIG5vdCBkaXJ0aWVkIGJvdGggaW4gZXh0NF9leHRfY29udmVy dF90b19pbml0aWFsaXplZCgpIGFuZCBleHQ0X2V4dF9pbnNlcnRfZXh0ZW50KCkKYWx0aG91Z2gg ZWVfbGVuIGlzIHVwZGF0ZWQsIHNvIHRoZSBwYWdlIGNhY2hlIGNvbnRhaW5zIGV4IG1heSBiZSBm cmVlZC4gSWYgdGhpcyBoYXBwZW5zLAp0aGUgbGF0ZXIgZXh0NF9leHRfY29udmVydF90b19pbml0 aWFsaXplZCgpIG9uIHRoaXMgZXh0ZW50IHdpbGwgbG9hZCB0aGUgc3RhbGUgZGF0YSBmcm9tIGRp c2suCkFuZCB0aGlzIHN0YWxlIGV4IG92ZXJsYXBzIHdpdGggbmV3ZXgsIHdpbGwgY2F1c2UgdGhl IEJVR19PTihuZXdleHQtPmVlX2Jsb2NrID09IG5lYXJleC0+ZWVfYmxvY2spLAppbiBleHQ0X2V4 dF9pbnNlcnRfZXh0ZW50KCkuIFRoZSBwYXRjaCBkaXJ0aWVzIHRoZSBleCBpbiBzY2VuYXJpbyAy KQoKU2lnbmVkLW9mZi1ieTogWGlhb3l1biBNYW8gPHhpYW95dW4ubWFveHlAYWxpeXVuLWluYy5j b20+ClNpZ25lZC1vZmYtYnk6IFlpbmdiaW4gV2FuZyA8eWluZ2Jpbi53YW5neWJAYWxpeXVuLWlu Yy5jb20+ClNpZ25lZC1vZmYtYnk6IEppYSBXYW4gPGppYS53YW5qQGFsaXl1bi1pbmMuY29tPgot LS0KIGZzL2V4dDQvZXh0ZW50cy5jIHwgICAyOSArKysrKysrKysrKysrKysrKysrKysrKysrKysr KwogMSBmaWxlcyBjaGFuZ2VkLCAyOSBpbnNlcnRpb25zKCspLCAwIGRlbGV0aW9ucygtKQoKZGlm ZiAtLWdpdCBhL2ZzL2V4dDQvZXh0ZW50cy5jIGIvZnMvZXh0NC9leHRlbnRzLmMKaW5kZXggNDg5 MGQ2Zi4uMmUwNDFjMiAxMDA2NDQKLS0tIGEvZnMvZXh0NC9leHRlbnRzLmMKKysrIGIvZnMvZXh0 NC9leHRlbnRzLmMKQEAgLTI1NTYsNiArMjU1Niw4IEBAIHN0YXRpYyBpbnQgZXh0NF9leHRfY29u dmVydF90b19pbml0aWFsaXplZChoYW5kbGVfdCAqaGFuZGxlLAogCWludCBlcnIgPSAwOwogCWlu dCByZXQgPSAwOwogCWludCBtYXlfemVyb291dDsKKwlpbnQgaW5zZXJ0X21heF9leHRlbnQgPSAw OworCXN0cnVjdCBleHQ0X2V4dF9wYXRoICpvbGRfbGVhZl9wYXRoID0gTlVMTDsKIAogCWV4dF9k ZWJ1ZygiZXh0NF9leHRfY29udmVydF90b19pbml0aWFsaXplZDogaW5vZGUgJWx1LCBsb2dpY2Fs IgogCQkiYmxvY2sgJWxsdSwgbWF4X2Jsb2NrcyAldVxuIiwgaW5vZGUtPmlfaW5vLApAQCAtMjgx Niw2ICsyODE4LDkgQEAgc3RhdGljIGludCBleHQ0X2V4dF9jb252ZXJ0X3RvX2luaXRpYWxpemVk KGhhbmRsZV90ICpoYW5kbGUsCiAJZXJyID0gZXh0NF9leHRfZGlydHkoaGFuZGxlLCBpbm9kZSwg cGF0aCArIGRlcHRoKTsKIAlnb3RvIG91dDsKIGluc2VydDoKKwlpZiAocGF0aFtkZXB0aF0ucF9l eHQgPT0gRVhUX01BWF9FWFRFTlQocGF0aFtkZXB0aF0ucF9oZHIpKQorCQlpbnNlcnRfbWF4X2V4 dGVudCA9IDE7CisKIAllcnIgPSBleHQ0X2V4dF9pbnNlcnRfZXh0ZW50KGhhbmRsZSwgaW5vZGUs IHBhdGgsICZuZXdleCwgMCk7CiAJaWYgKGVyciA9PSAtRU5PU1BDICYmIG1heV96ZXJvb3V0KSB7 CiAJCWVyciA9ICBleHQ0X2V4dF96ZXJvb3V0KGlub2RlLCAmb3JpZ19leCk7CkBAIC0yODMwLDYg KzI4MzUsMzAgQEAgaW5zZXJ0OgogCQlyZXR1cm4gYWxsb2NhdGVkOwogCX0gZWxzZSBpZiAoZXJy KQogCQlnb3RvIGZpeF9leHRlbnRfbGVuOworCisJaWYgKGluc2VydF9tYXhfZXh0ZW50KSB7CisJ CW9sZF9sZWFmX3BhdGggPSBleHQ0X2V4dF9maW5kX2V4dGVudChpbm9kZSwgZWVfYmxvY2ssIE5V TEwpOworCQlpZiAoSVNfRVJSKG9sZF9sZWFmX3BhdGgpKSB7CisJCQllcnIgPSBQVFJfRVJSKG9s ZF9sZWFmX3BhdGgpOworCQkJb2xkX2xlYWZfcGF0aCA9IE5VTEw7CisJCQlnb3RvIG91dDsKKwkJ fQorCQlkZXB0aCA9IGV4dF9kZXB0aChpbm9kZSk7CisKKwkJZXJyID0gZXh0NF9leHRfZ2V0X2Fj Y2VzcyhoYW5kbGUsIGlub2RlLCBvbGRfbGVhZl9wYXRoICsgZGVwdGgpOworCQlpZiAoZXJyKQor CQkJZ290byBvdXQ7CisKKwkJb2xkX2xlYWZfcGF0aFtkZXB0aF0ucF9leHQtPmVlX2xlbiA9IGNw dV90b19sZTE2KGlibG9jayAtIGVlX2Jsb2NrKTsKKwkJZXh0NF9leHRfbWFya191bmluaXRpYWxp emVkKG9sZF9sZWFmX3BhdGhbZGVwdGhdLnBfZXh0KTsKKworCQllcnIgPSBleHQ0X2V4dF9kaXJ0 eShoYW5kbGUsIGlub2RlLCBvbGRfbGVhZl9wYXRoICsgZGVwdGgpOworCisJCWlmIChvbGRfbGVh Zl9wYXRoKSB7CisJCQlleHQ0X2V4dF9kcm9wX3JlZnMob2xkX2xlYWZfcGF0aCk7CisJCQlrZnJl ZShvbGRfbGVhZl9wYXRoKTsKKwkJfQorCX0KIG91dDoKIAlleHQ0X2V4dF9zaG93X2xlYWYoaW5v ZGUsIHBhdGgpOwogCXJldHVybiBlcnIgPyBlcnIgOiBhbGxvY2F0ZWQ7Ci0tIAoxLjUuNS42Cgo= --_382051e3-f4e4-4822-8610-a3f7da59baf0_ Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel --_382051e3-f4e4-4822-8610-a3f7da59baf0_-- From xen-devel-bounces@lists.xensource.com Sun Sep 25 06:21:52 2011 Return-path: <xen-devel-bounces@lists.xensource.com> Envelope-to: www-data@lists.xensource.com Delivery-date: Sun, 25 Sep 2011 06:21:52 -0700 Received: from localhost ([127.0.0.1] helo=lists.colo.xensource.com) by lists.xensource.com with esmtp (Exim 4.43) id 1R7oeW-0006VU-9r; Sun, 25 Sep 2011 06:21:52 -0700 Received: from mail174.messagelabs.com ([85.158.138.51]) by lists.xensource.com with esmtp (Exim 4.43) id 1R7odj-0006J3-Fv for xen-devel@lists.xensource.com; Sun, 25 Sep 2011 06:21:04 -0700 X-Env-Sender: Ian.Jackson@eu.citrix.com X-Msg-Ref: server-15.tower-174.messagelabs.com!1316956860!26319604!1 X-Originating-IP: [62.200.22.115] X-StarScan-Version: 6.4.1; banners=-,-,- X-VirusChecked: Checked Received: (qmail 21086 invoked from network); 25 Sep 2011 13:21:00 -0000 Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115) by server-15.tower-174.messagelabs.com with RC4-SHA encrypted SMTP; 25 Sep 2011 13:21:00 -0000 X-IronPort-AV: E=Sophos;i="4.68,439,1312156800"; d="scan'208";a="8046330" Received: from lonpmailmx01.citrite.net ([10.30.203.162]) by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5; 25 Sep 2011 13:20:31 +0000 Received: from woking.xci-test.com (10.80.248.135) by smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id 8.3.137.0; Sun, 25 Sep 2011 14:20:30 +0100 Received: from osstest by woking.xci-test.com with local (Exim 4.69) (envelope-from <ian.jackson@eu.citrix.com>) id 1R7odC-0002XW-Ip; Sun, 25 Sep 2011 14:20:30 +0100 To: xen-devel@lists.xensource.com Message-ID: <osstest-9075-mainreport@xen.org> From: xen.org <ian.jackson@eu.citrix.com> Date: Sun, 25 Sep 2011 14:20:30 +0100 MIME-Version: 1.0 Content-Type: text/plain Cc: ian.jackson@eu.citrix.com Subject: [Xen-devel] [xen-unstable test] 9075: regressions - FAIL X-BeenThere: xen-devel@lists.xensource.com X-Mailman-Version: 2.1.5 Precedence: list List-Id: Xen developer discussion <xen-devel.lists.xensource.com> List-Unsubscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe> List-Post: <mailto:xen-devel@lists.xensource.com> List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help> List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=subscribe> Sender: xen-devel-bounces@lists.xensource.com Errors-To: xen-devel-bounces@lists.xensource.com flight 9075 xen-unstable real [real] http://www.chiark.greenend.org.uk/~xensrcts/logs/9075/ Regressions :-( Tests which did not succeed and are blocking: test-amd64-i386-rhel6hvm-amd 5 xen-boot fail REGR. vs. 8995 Tests which are failing intermittently (not blocking): test-amd64-i386-pv 5 xen-boot fail pass in 9073 test-amd64-amd64-pv 5 xen-boot fail pass in 9073 test-amd64-i386-xl-multivcpu 5 xen-boot fail pass in 9073 test-amd64-amd64-xl-sedf 5 xen-boot fail pass in 9067 test-i386-i386-xl-win 5 xen-boot fail pass in 9067 test-i386-i386-win 5 xen-boot fail pass in 9071 test-amd64-amd64-win 5 xen-boot fail pass in 9069 test-amd64-i386-win 5 xen-boot fail pass in 9071 test-amd64-i386-xl-credit2 5 xen-boot fail in 9073 pass in 9075 test-amd64-i386-xl-win-vcpus1 5 xen-boot fail in 9073 pass in 9075 test-amd64-i386-win-vcpus1 5 xen-boot fail in 9073 pass in 9075 test-amd64-amd64-xl 5 xen-boot fail in 9067 pass in 9075 test-amd64-i386-xl 5 xen-boot fail in 9067 pass in 9075 test-i386-i386-xl 5 xen-boot fail in 9067 pass in 9075 test-amd64-amd64-xl-win 5 xen-boot fail in 9067 pass in 9075 test-i386-i386-pv 5 xen-boot fail in 9071 pass in 9075 test-i386-i386-pair 8 xen-boot/dst_host fail in 9071 pass in 9075 test-i386-i386-pair 7 xen-boot/src_host fail in 9071 pass in 9075 Tests which did not succeed, but are not blocking, including regressions (tests previously passed) regarded as allowable: test-amd64-amd64-xl-pcipt-intel 9 guest-start fail never pass test-amd64-i386-rhel6hvm-intel 9 guest-start.2 fail never pass test-amd64-i386-xl-win-vcpus1 13 guest-stop fail never pass test-amd64-i386-win-vcpus1 16 leak-check/check fail never pass test-amd64-amd64-xl-win 13 guest-stop fail never pass test-i386-i386-xl-win 13 guest-stop fail in 9067 never pass test-i386-i386-win 16 leak-check/check fail in 9067 never pass test-amd64-amd64-win 16 leak-check/check fail in 9067 never pass test-amd64-i386-win 16 leak-check/check fail in 9071 never pass version targeted for testing: xen cc339ab1d917 baseline version: xen a422e2a4451e ------------------------------------------------------------ People who touched revisions under test: Andreas Herrmann <herrmann.der.user@googlemail.com> Ian Campbell <ian.campbell@citrix.com> Ian Jackson <ian.jackson@eu.citrix.com> Jan Beulich <jbeulich@suse.com> Lasse Collin <lasse.collin@tukaani.org> Olaf Hering <olaf@aepfle.de> Thomas Renninger <trenn@suse.de> ------------------------------------------------------------ jobs: build-amd64 pass build-i386 pass build-amd64-oldkern pass build-i386-oldkern pass build-amd64-pvops pass build-i386-pvops pass test-amd64-amd64-xl pass test-amd64-i386-xl pass test-i386-i386-xl pass test-amd64-i386-rhel6hvm-amd fail test-amd64-i386-xl-credit2 pass test-amd64-amd64-xl-pcipt-intel fail test-amd64-i386-rhel6hvm-intel fail test-amd64-i386-xl-multivcpu fail test-amd64-amd64-pair pass test-amd64-i386-pair pass test-i386-i386-pair pass test-amd64-amd64-pv fail test-amd64-i386-pv fail test-i386-i386-pv pass test-amd64-amd64-xl-sedf fail test-amd64-i386-win-vcpus1 fail test-amd64-i386-xl-win-vcpus1 fail test-amd64-amd64-win fail test-amd64-i386-win fail test-i386-i386-win fail test-amd64-amd64-xl-win fail test-i386-i386-xl-win fail ------------------------------------------------------------ sg-report-flight on woking.cam.xci-test.com logs: /home/xc_osstest/logs images: /home/xc_osstest/images Logs, config files, etc. are available at http://www.chiark.greenend.org.uk/~xensrcts/logs Test harness code can be found at http://xenbits.xensource.com/gitweb?p=osstest.git;a=summary Not pushing. ------------------------------------------------------------ changeset: 23872:cc339ab1d917 tag: tip user: Ian Campbell <ian.campbell@citrix.com> date: Thu Sep 22 18:37:06 2011 +0100 tools: fix install of lomount $(BIN) went away in 23124:e3d4c34b14a3. Also there are no *.so, *.a or *.rpm built in here Signed-off-by: Ian Campbell <ian.campbell@citrix.com> changeset: 23871:503ee256fecf user: Jan Beulich <jbeulich@suse.com> date: Thu Sep 22 18:35:30 2011 +0100 x86: ucode-amd: Don't warn when no ucode is available for a CPU revision This patch originally comes from the Linus mainline kernel (2.6.33), find below the patch details: From: Andreas Herrmann <herrmann.der.user@googlemail.com> There is no point in warning when there is no ucode available for a specific CPU revision. Currently the container-file, which provides the AMD ucode patches for OS load, contains only a few ucode patches. It's already clearly indicated by the printed patch_level whenever new ucode was available and an update happened. So the warning message is of no help but rather annoying on systems with many CPUs. Signed-off-by: Thomas Renninger <trenn@suse.de> Signed-off-by: Jan Beulich <jbeulich@suse.com> changeset: 23870:5c97b02f48fc user: Jan Beulich <jbeulich@suse.com> date: Thu Sep 22 18:34:27 2011 +0100 XZ: Fix incorrect XZ_BUF_ERROR From: Lasse Collin <lasse.collin@tukaani.org> xz_dec_run() could incorrectly return XZ_BUF_ERROR if all of the following was true: - The caller knows how many bytes of output to expect and only provides that much output space. - When the last output bytes are decoded, the caller-provided input buffer ends right before the LZMA2 end of payload marker. So LZMA2 won't provide more output anymore, but it won't know it yet and thus won't return XZ_STREAM_END yet. - A BCJ filter is in use and it hasn't left any unfiltered bytes in the temp buffer. This can happen with any BCJ filter, but in practice it's more likely with filters other than the x86 BCJ. This fixes <https://bugzilla.redhat.com/show_bug.cgi?id=3D735408> where Squashfs thinks that a valid file system is corrupt. This also fixes a similar bug in single-call mode where the uncompressed size of a block using BCJ + LZMA2 was 0 bytes and caller provided no output space. Many empty .xz files don't contain any blocks and thus don't trigger this bug. This also tweaks a closely related detail: xz_dec_bcj_run() could call xz_dec_lzma2_run() to decode into temp buffer when it was known to be useless. This was harmless although it wasted a minuscule number of CPU cycles. Signed-off-by: Lasse Collin <lasse.collin@tukaani.org> Signed-off-by: Jan Beulich <jbeulich@suse.com> changeset: 23869:db1ea4b127cd user: Jan Beulich <jbeulich@suse.com> date: Thu Sep 22 18:33:48 2011 +0100 XZ decompressor: Fix decoding of empty LZMA2 streams From: Lasse Collin <lasse.collin@tukaani.org> The old code considered valid empty LZMA2 streams to be corrupt. Note that a typical empty .xz file has no LZMA2 data at all, and thus most .xz files having no uncompressed data are handled correctly even without this fix. Signed-off-by: Lasse Collin <lasse.collin@tukaani.org> Signed-off-by: Jan Beulich <jbeulich@suse.com> changeset: 23868:28147fd781af user: Jan Beulich <jbeulich@suse.com> date: Thu Sep 22 18:32:34 2011 +0100 VT-d: fix off-by-one error in RMRR validation (base_addr,end_addr) is an inclusive range, and hence there shouldn't be a subtraction of 1 in the second invocation of page_is_ram_type(). For RMRRs covering a single page that actually resulted in the immediately preceding page to get checked (which could have resulted in a false warning). Signed-off-by: Jan Beulich <jbeulich@suse.com> changeset: 23867:571b6e90dfb4 user: Jan Beulich <jbeulich@suse.com> date: Thu Sep 22 18:31:44 2011 +0100 VT-d: eliminate a mis-use of pcidevs_lock dma_pte_clear_one() shouldn't acquire this global lock for the purpose of processing a per-domain list. Furthermore the function a few lines earlier has a comment stating that acquiring pcidevs_lock isn't necessary here (whether that's really correct is another question). Use the domain's mappin_lock instead to protect the mapped_rmrrs list. Fold domain_rmrr_mapped() into its sole caller so that the otherwise implicit dependency on pcidevs_lock there becomes more obvious (see the comment there). Signed-off-by: Jan Beulich <jbeulich@suse.com> changeset: 23866:47ec1d405af9 user: Jan Beulich <jbeulich@suse.com> date: Thu Sep 22 18:31:02 2011 +0100 x86: IO-APIC code has no dependency on PCI The IRQ handling code requires pcidevs_lock to be held only for MSI interrupts. As the handling of which was now fully moved into msi.c (i.e. while applying fine without, the patch needs to be applied after the one titled "x86: split MSI IRQ chip"), io_apic.c now also doesn't need to include PCI headers anymore. Signed-off-by: Jan Beulich <jbeulich@suse.com> changeset: 23865:d6e01c7853cf user: Jan Beulich <jbeulich@suse.com> date: Thu Sep 22 18:29:19 2011 +0100 PCI multi-seg: config space accessor adjustments Signed-off-by: Jan Beulich <jbeulich@suse.com> changeset: 23864:314b147d524d user: Jan Beulich <jbeulich@suse.com> date: Thu Sep 22 18:28:38 2011 +0100 PCI multi-seg: Pass-through adjustments Signed-off-by: Jan Beulich <jbeulich@suse.com> changeset: 23863:9e0259239822 user: Jan Beulich <jbeulich@suse.com> date: Thu Sep 22 18:28:03 2011 +0100 PCI multi-seg: AMD-IOMMU specific adjustments There are two places here where it is entirely unclear to me where the necessary PCI segment number should be taken from (as IVMD descriptors don't have such, only IVHD ones do). AMD confirmed that for the time being it is acceptable to imply that only segment 0 exists. Signed-off-by: Jan Beulich <jbeulich@suse.com> changeset: 23862:85418e168527 user: Jan Beulich <jbeulich@suse.com> date: Thu Sep 22 18:27:26 2011 +0100 PCI multi-seg: VT-d specific adjustments Signed-off-by: Jan Beulich <jbeulich@suse.com> changeset: 23861:ec7c81fbe0de user: Jan Beulich <jbeulich@suse.com> date: Thu Sep 22 18:26:54 2011 +0100 PCI multi-seg: adjust domctl interface Again, a couple of directly related functions at once get adjusted to account for the segment number. Signed-off-by: Jan Beulich <jbeulich@suse.com> changeset: 23860:a422e2a4451e user: Jan Beulich <jbeulich@suse.com> date: Sun Sep 18 00:26:52 2011 +0100 x86: split MSI IRQ chip With the .end() accessor having become optional and noting that several of the accessors' behavior really depends on the result of msi_maskable_irq(), the splits the MSI IRQ chip type into two - one for the maskable ones, and the other for the (MSI only) non-maskable ones. At once the implementation of those methods gets moved from io_apic.c to msi.c. Signed-off-by: Jan Beulich <jbeulich@suse.com> ======================================== commit cd776ee9408ff127f934a707c1a339ee600bc127 Author: Ian Jackson <ian.jackson@eu.citrix.com> Date: Tue Jun 28 13:50:53 2011 +0100 qemu-char.c: fix incorrect CONFIG_STUBDOM handling qemu-char.c:1123:7: warning: "CONFIG_STUBDOM" is not defined [-Wundef] Signed-off-by: Olaf Hering <olaf@aepfle.de> Acked-by: Ian Jackson <ian.jackson@eu.citrix.com> _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel From xen-devel-bounces@lists.xensource.com Sun Sep 25 07:13:22 2011 Return-path: <xen-devel-bounces@lists.xensource.com> Envelope-to: www-data@lists.xensource.com Delivery-date: Sun, 25 Sep 2011 07:13:22 -0700 Received: from localhost ([127.0.0.1] helo=lists.colo.xensource.com) by lists.xensource.com with esmtp (Exim 4.43) id 1R7pSM-00007z-IX; Sun, 25 Sep 2011 07:13:22 -0700 Received: from mail174.messagelabs.com ([85.158.138.51]) by lists.xensource.com with esmtp (Exim 4.43) id 1R7pRh-0008NL-CT; Sun, 25 Sep 2011 07:12:42 -0700 X-Env-Sender: Paul.Durrant@citrix.com X-Msg-Ref: server-9.tower-174.messagelabs.com!1316959957!26641415!1 X-Originating-IP: [62.200.22.115] X-StarScan-Version: 6.4.1; banners=-,-,- X-VirusChecked: Checked Received: (qmail 30184 invoked from network); 25 Sep 2011 14:12:38 -0000 Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115) by server-9.tower-174.messagelabs.com with RC4-SHA encrypted SMTP; 25 Sep 2011 14:12:38 -0000 X-IronPort-AV: E=Sophos;i="4.68,439,1312156800"; d="scan'208";a="8046782" Received: from lonpmailmx01.citrite.net ([10.30.203.162]) by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5; 25 Sep 2011 14:12:37 +0000 Received: from LONPMAILBOX01.citrite.net ([10.30.224.160]) by LONPMAILMX01.citrite.net ([10.30.203.162]) with mapi; Sun, 25 Sep 2011 15:12:37 +0100 From: Paul Durrant <Paul.Durrant@citrix.com> To: jim burns <jim_burn@bellsouth.net>, "xen-users@lists.xensource.com" <xen-users@lists.xensource.com>, "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com> Date: Sun, 25 Sep 2011 15:12:57 +0100 Subject: RE: [Xen-devel] Re: [Xen-users] Is xen planning to support hvm guests booting under UEFI? Thread-Topic: [Xen-devel] Re: [Xen-users] Is xen planning to support hvm guests booting under UEFI? Thread-Index: Acx7KbyBVgUafLsDR3+KFWrLDrdL1QAYr61A Message-ID: <291EDFCB1E9E224A99088639C4762022B44F50F0EF@LONPMAILBOX01.citrite.net> References: <2082539.WE5RVzqO5R@dell4550> <4597364.LrXQjvBoPa@dell4550> <CAMrPLW+rL-O9VYYgOU=_ojhE352YTOJyOfw38qfXu3KUjautug@mail.gmail.com> <2744508.hgiQGpxhdI@dell4550> In-Reply-To: <2744508.hgiQGpxhdI@dell4550> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: Todd Deshane <todd.deshane@xen.org> X-BeenThere: xen-devel@lists.xensource.com X-Mailman-Version: 2.1.5 Precedence: list List-Id: Xen developer discussion <xen-devel.lists.xensource.com> List-Unsubscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe> List-Post: <mailto:xen-devel@lists.xensource.com> List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help> List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=subscribe> Sender: xen-devel-bounces@lists.xensource.com Errors-To: xen-devel-bounces@lists.xensource.com Since I was at the presentation in question, I asked about requirements for= virtual platforms. I seem to recall the response being that UEFI was not a= requirement for virtual platforms as yet and moreover I don't believe hype= r-v VMs UEFI boot.=20 That said I'm not sure about the requirements surrounding trusted boot; I g= uess they will become clearer as the HCK requirements are firmed up. I'd certainly like to see HVM UEFI boot sooner rather than later as I think= it will speed up Windows boot (and not just for Windows 8) quite a lot but= I didn't see any need to panic just yet. Paul=20 > -----Original Message----- > From: xen-devel-bounces@lists.xensource.com [mailto:xen-devel- > bounces@lists.xensource.com] On Behalf Of jim burns > Sent: 25 September 2011 03:18 > To: xen-users@lists.xensource.com; xen-devel@lists.xensource.com > Cc: Todd Deshane > Subject: [Xen-devel] Re: [Xen-users] Is xen planning to support hvm > guests booting under UEFI? >=20 > On Sat September 24 2011, 6:43:42 PM, Todd Deshane wrote: > > On Sat, Sep 24, 2011 at 5:34 PM, jim burns > <jim_burn@bellsouth.net> wrote: > > > On Wed September 21 2011, 9:06:38 PM, jim burns wrote: > > >> Pls cc: me as I am not subscribed. > > > > > > [...] > > > http://wiki.xensource.com/xenwiki/XenParavirtOps has been > reworked > > > recently. Not sure if this was there before: > > > > > > "Add EFI support in Linux pv-ops. Jan Beulich wrote patches to > make > > > Xen hypervisor be able to compile as an EFI application. "Build > > > xen.efi, write up a config file for it to read (most importantly > so > > > it knows what Dom0 kernel and initrd to use), and you should be > good > > > to go (provided the EFI implementation isn't too flawed). This > being > > > an EFI application you can simply run it from the shell prompt. > > > Parameter for Xen.efi is -cfg <file>, and <file> has: kernel=3D, > > > ramdisk=3D, options=3D, video=3Dgfx-x. The Linux pv-ops needs at leas= t > to > > > parse XEN_VGATYPE_EFI_LFB data, E820 parsed (should be working) > and > > > give the ACPI subsystem a pointer to the ACPI DSDT without > consulting EBDA." > > > > > > This doesn't solve the Windows 8 hvm problem, but at least EFI > is > > > being considered. > > > > There was a google summer of code project around UEFI: > > http://code.google.com/p/google-summer-of-code-2011- > tianocore/download > > s/deta > > il?name=3DBei_Guan.tar.gz&can=3D2&q=3D > > > > I don't know if it was submitted to xen-devel, but you can follow > up > > with the xen-devel mailing list if you are interested. > > > > Hope that helps. >=20 > The article I quoted was from http://www.itworld.com/it- > managementstrategy/205255/windows-8-oem-specs- > may-block-linux-booting : >=20 > "Red Hat's Matthew Garrett was one of the first to notice that > according to the new logo rules, all Windows 8 machines will need to > be have the Unified Extensible Firmware Interface (UEFI) instead of > the venerable BIOS firmware layer. BIOS has been pretty much the > sole firmware interface for PCs for a long time. >=20 > The EFI system has slowly been making headway in recent years, and > right now EFI firmware is compatible with Windows supporting the > GUID Partition Table (GPT), OS X/Intel, and Linux 2.6 and beyond > machines. EFI is seen as a better hardware/software interface than > BIOS, since it is platform-agnostic, runs in > 32- or 64-bit mode, and GPT machines can handle boot partitions of > up to 9.4 zettabytes. (That's 9.5 billion terabytes to you and me.) >=20 > EFI, and the later UEFI specification, is not the problem for Linux. > The problem is Microsoft's other requirement for any Windows 8- > certified client: > the system must support secure booting. This hardened boot means > that "all firmware and software in the boot process must be signed > by a trusted Certificate Authority (CA)," according to slides from a > recent presentation on the UEFI boot process made by Arie van der > Hoeven, Microsoft Principal Lead Program Manager." >=20 > Putting aside the signing problem for now, the immediate problem is > qemu-dm as the emulator for hvm guests, since it provides an > emulated *bios*. Or hvmloader as the bootloader. The url Todd > provides points to a project to modify 'ovmf', an EFI bootloader, to > be xen hvm aware. Windows 8 will be a game changer, if the article > is right. Hope plans are being made to incorporate some sort of EFI > bootloader into xen. >=20 > _______________________________________________ > Xen-devel mailing list > Xen-devel@lists.xensource.com > http://lists.xensource.com/xen-devel _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel From xen-devel-bounces@lists.xensource.com Sun Sep 25 07:51:08 2011 Return-path: <xen-devel-bounces@lists.xensource.com> Envelope-to: www-data@lists.xensource.com Delivery-date: Sun, 25 Sep 2011 07:51:08 -0700 Received: from localhost ([127.0.0.1] helo=lists.colo.xensource.com) by lists.xensource.com with esmtp (Exim 4.43) id 1R7q2u-0001Hx-D9; Sun, 25 Sep 2011 07:51:08 -0700 Received: from mail216.messagelabs.com ([85.158.143.99]) by lists.xensource.com with esmtp (Exim 4.43) id 1R7q27-00015U-VX; Sun, 25 Sep 2011 07:50:20 -0700 X-Env-Sender: keir.xen@gmail.com X-Msg-Ref: server-10.tower-216.messagelabs.com!1316962215!11433615!1 X-Originating-IP: [209.85.161.171] X-StarScan-Version: 6.4.1; banners=-,-,- X-VirusChecked: Checked Received: (qmail 26620 invoked from network); 25 Sep 2011 14:50:16 -0000 Received: from mail-gx0-f171.google.com (HELO mail-gx0-f171.google.com) (209.85.161.171) by server-10.tower-216.messagelabs.com with RC4-SHA encrypted SMTP; 25 Sep 2011 14:50:16 -0000 Received: by gxk27 with SMTP id 27so4911821gxk.30 for <multiple recipients>; Sun, 25 Sep 2011 07:50:15 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=user-agent:date:subject:from:to:cc:message-id:thread-topic :thread-index:in-reply-to:mime-version:content-type :content-transfer-encoding; bh=GuG1u9N1SrlFsbIvzx7QcA0lW4Ag6mFRWx+8ilhuAT4=; b=byYE+nlwZhOXvL7xLuzvT1poxOoP7fIhxWATGNokiuGUiDxbKkvBdGwwvM71g25NiV 0c1ZnjWvhjnl1ovSLSPUs8pe6hcditNPKDrT+Tz85aYOmfHC+0v9ACusTdBA+hOPjtDs Qxeu3i7pWnMch/Q9YCgGiL4zDkzcLpoymyg84= Received: by 10.42.74.131 with SMTP id w3mr6335238icj.223.1316962215056; Sun, 25 Sep 2011 07:50:15 -0700 (PDT) Received: from [10.255.255.36] ([96.49.135.17]) by mx.google.com with ESMTPS id ek22sm23017403ibb.12.2011.09.25.07.50.10 (version=SSLv3 cipher=OTHER); Sun, 25 Sep 2011 07:50:13 -0700 (PDT) User-Agent: Microsoft-Entourage/12.30.0.110427 Date: Sun, 25 Sep 2011 07:50:07 -0700 Subject: Re: [Xen-devel] Re: [Xen-users] Is xen planning to support hvm guests booting under UEFI? From: Keir Fraser <keir.xen@gmail.com> To: Paul Durrant <Paul.Durrant@citrix.com>, jim burns <jim_burn@bellsouth.net>, "xen-users@lists.xensource.com" <xen-users@lists.xensource.com>, "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com> Message-ID: <CAA48DAF.2172A%keir.xen@gmail.com> Thread-Topic: [Xen-devel] Re: [Xen-users] Is xen planning to support hvm guests booting under UEFI? Thread-Index: Acx7KbyBVgUafLsDR3+KFWrLDrdL1QAYr61AAAF71mk= In-Reply-To: <291EDFCB1E9E224A99088639C4762022B44F50F0EF@LONPMAILBOX01.citrite.net> Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit Cc: Todd Deshane <todd.deshane@xen.org> X-BeenThere: xen-devel@lists.xensource.com X-Mailman-Version: 2.1.5 Precedence: list List-Id: Xen developer discussion <xen-devel.lists.xensource.com> List-Unsubscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe> List-Post: <mailto:xen-devel@lists.xensource.com> List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help> List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=subscribe> Sender: xen-devel-bounces@lists.xensource.com Errors-To: xen-devel-bounces@lists.xensource.com The GSOC project student seemed to be making good progress, and there were others on the OVMF side who were giving him support. I haven't heard anything in about a month now, though. On 25/09/2011 07:12, "Paul Durrant" <Paul.Durrant@citrix.com> wrote: > Since I was at the presentation in question, I asked about requirements for > virtual platforms. I seem to recall the response being that UEFI was not a > requirement for virtual platforms as yet and moreover I don't believe hyper-v > VMs UEFI boot. > That said I'm not sure about the requirements surrounding trusted boot; I > guess they will become clearer as the HCK requirements are firmed up. > > I'd certainly like to see HVM UEFI boot sooner rather than later as I think it > will speed up Windows boot (and not just for Windows 8) quite a lot but I > didn't see any need to panic just yet. > > Paul > >> -----Original Message----- >> From: xen-devel-bounces@lists.xensource.com [mailto:xen-devel- >> bounces@lists.xensource.com] On Behalf Of jim burns >> Sent: 25 September 2011 03:18 >> To: xen-users@lists.xensource.com; xen-devel@lists.xensource.com >> Cc: Todd Deshane >> Subject: [Xen-devel] Re: [Xen-users] Is xen planning to support hvm >> guests booting under UEFI? >> >> On Sat September 24 2011, 6:43:42 PM, Todd Deshane wrote: >>> On Sat, Sep 24, 2011 at 5:34 PM, jim burns >> <jim_burn@bellsouth.net> wrote: >>>> On Wed September 21 2011, 9:06:38 PM, jim burns wrote: >>>>> Pls cc: me as I am not subscribed. >>>> >>>> [...] >>>> http://wiki.xensource.com/xenwiki/XenParavirtOps has been >> reworked >>>> recently. Not sure if this was there before: >>>> >>>> "Add EFI support in Linux pv-ops. Jan Beulich wrote patches to >> make >>>> Xen hypervisor be able to compile as an EFI application. "Build >>>> xen.efi, write up a config file for it to read (most importantly >> so >>>> it knows what Dom0 kernel and initrd to use), and you should be >> good >>>> to go (provided the EFI implementation isn't too flawed). This >> being >>>> an EFI application you can simply run it from the shell prompt. >>>> Parameter for Xen.efi is -cfg <file>, and <file> has: kernel=, >>>> ramdisk=, options=, video=gfx-x. The Linux pv-ops needs at least >> to >>>> parse XEN_VGATYPE_EFI_LFB data, E820 parsed (should be working) >> and >>>> give the ACPI subsystem a pointer to the ACPI DSDT without >> consulting EBDA." >>>> >>>> This doesn't solve the Windows 8 hvm problem, but at least EFI >> is >>>> being considered. >>> >>> There was a google summer of code project around UEFI: >>> http://code.google.com/p/google-summer-of-code-2011- >> tianocore/download >>> s/deta >>> il?name=Bei_Guan.tar.gz&can=2&q= >>> >>> I don't know if it was submitted to xen-devel, but you can follow >> up >>> with the xen-devel mailing list if you are interested. >>> >>> Hope that helps. >> >> The article I quoted was from http://www.itworld.com/it- >> managementstrategy/205255/windows-8-oem-specs- >> may-block-linux-booting : >> >> "Red Hat's Matthew Garrett was one of the first to notice that >> according to the new logo rules, all Windows 8 machines will need to >> be have the Unified Extensible Firmware Interface (UEFI) instead of >> the venerable BIOS firmware layer. BIOS has been pretty much the >> sole firmware interface for PCs for a long time. >> >> The EFI system has slowly been making headway in recent years, and >> right now EFI firmware is compatible with Windows supporting the >> GUID Partition Table (GPT), OS X/Intel, and Linux 2.6 and beyond >> machines. EFI is seen as a better hardware/software interface than >> BIOS, since it is platform-agnostic, runs in >> 32- or 64-bit mode, and GPT machines can handle boot partitions of >> up to 9.4 zettabytes. (That's 9.5 billion terabytes to you and me.) >> >> EFI, and the later UEFI specification, is not the problem for Linux. >> The problem is Microsoft's other requirement for any Windows 8- >> certified client: >> the system must support secure booting. This hardened boot means >> that "all firmware and software in the boot process must be signed >> by a trusted Certificate Authority (CA)," according to slides from a >> recent presentation on the UEFI boot process made by Arie van der >> Hoeven, Microsoft Principal Lead Program Manager." >> >> Putting aside the signing problem for now, the immediate problem is >> qemu-dm as the emulator for hvm guests, since it provides an >> emulated *bios*. Or hvmloader as the bootloader. The url Todd >> provides points to a project to modify 'ovmf', an EFI bootloader, to >> be xen hvm aware. Windows 8 will be a game changer, if the article >> is right. Hope plans are being made to incorporate some sort of EFI >> bootloader into xen. >> >> _______________________________________________ >> Xen-devel mailing list >> Xen-devel@lists.xensource.com >> http://lists.xensource.com/xen-devel > > _______________________________________________ > Xen-devel mailing list > Xen-devel@lists.xensource.com > http://lists.xensource.com/xen-devel _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel From xen-devel-bounces@lists.xensource.com Sun Sep 25 08:02:21 2011 Return-path: <xen-devel-bounces@lists.xensource.com> Envelope-to: www-data@lists.xensource.com Delivery-date: Sun, 25 Sep 2011 08:02:21 -0700 Received: from localhost ([127.0.0.1] helo=lists.colo.xensource.com) by lists.xensource.com with esmtp (Exim 4.43) id 1R7qDk-0002V2-8j; Sun, 25 Sep 2011 08:02:20 -0700 Received: from mail216.messagelabs.com ([85.158.143.99]) by lists.xensource.com with esmtp (Exim 4.43) id 1R7q9k-0002FP-GT for xen-devel@lists.xensource.com; Sun, 25 Sep 2011 07:58:13 -0700 X-Env-Sender: Ian.Jackson@eu.citrix.com X-Msg-Ref: server-12.tower-216.messagelabs.com!1316962689!13776906!1 X-Originating-IP: [62.200.22.115] X-StarScan-Version: 6.4.1; banners=-,-,- X-VirusChecked: Checked Received: (qmail 20928 invoked from network); 25 Sep 2011 14:58:09 -0000 Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115) by server-12.tower-216.messagelabs.com with RC4-SHA encrypted SMTP; 25 Sep 2011 14:58:09 -0000 X-IronPort-AV: E=Sophos;i="4.68,439,1312156800"; d="scan'208";a="8047066" Received: from lonpmailmx01.citrite.net ([10.30.203.162]) by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5; 25 Sep 2011 14:58:09 +0000 Received: from woking.xci-test.com (10.80.248.135) by smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id 8.3.137.0; Sun, 25 Sep 2011 15:58:08 +0100 Received: from osstest by woking.xci-test.com with local (Exim 4.69) (envelope-from <ian.jackson@eu.citrix.com>) id 1R7q9g-0003HP-Hi; Sun, 25 Sep 2011 15:58:08 +0100 To: xen-devel@lists.xensource.com Message-ID: <osstest-9076-mainreport@xen.org> From: xen.org <ian.jackson@eu.citrix.com> Date: Sun, 25 Sep 2011 15:58:08 +0100 MIME-Version: 1.0 Content-Type: text/plain Cc: ian.jackson@eu.citrix.com Subject: [Xen-devel] [linux test] 9076: tolerable FAIL X-BeenThere: xen-devel@lists.xensource.com X-Mailman-Version: 2.1.5 Precedence: list List-Id: Xen developer discussion <xen-devel.lists.xensource.com> List-Unsubscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe> List-Post: <mailto:xen-devel@lists.xensource.com> List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help> List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=subscribe> Sender: xen-devel-bounces@lists.xensource.com Errors-To: xen-devel-bounces@lists.xensource.com flight 9076 linux real [real] http://www.chiark.greenend.org.uk/~xensrcts/logs/9076/ Failures :-/ but no regressions. Tests which did not succeed, but are not blocking, including regressions (tests previously passed) regarded as allowable: test-amd64-amd64-xl-pcipt-intel 9 guest-start fail never pass test-amd64-i386-rhel6hvm-amd 9 guest-start.2 fail never pass test-amd64-i386-rhel6hvm-intel 9 guest-start.2 fail never pass test-amd64-i386-win-vcpus1 16 leak-check/check fail never pass test-amd64-i386-xl-win-vcpus1 13 guest-stop fail never pass test-amd64-amd64-win 16 leak-check/check fail never pass test-amd64-amd64-xl-win 13 guest-stop fail never pass test-i386-i386-win 16 leak-check/check fail never pass test-i386-i386-xl-win 13 guest-stop fail never pass test-amd64-i386-win 16 leak-check/check fail never pass version targeted for testing: linux 6bec8b4a4c14095d0b7ce424db9d583c3decae6c baseline version: linux 1c3f03ccc5258887f5f2cafc0836a865834f9205 ------------------------------------------------------------ People who touched revisions under test: Jeremy Fitzhardinge <jeremy.fitzhardinge@citrix.com> ------------------------------------------------------------ jobs: build-amd64 pass build-i386 pass build-amd64-pvops pass build-i386-pvops pass test-amd64-amd64-xl pass test-amd64-i386-xl pass test-i386-i386-xl pass test-amd64-i386-rhel6hvm-amd fail test-amd64-i386-xl-credit2 pass test-amd64-amd64-xl-pcipt-intel fail test-amd64-i386-rhel6hvm-intel fail test-amd64-i386-xl-multivcpu pass test-amd64-amd64-pair pass test-amd64-i386-pair pass test-i386-i386-pair pass test-amd64-amd64-pv pass test-amd64-i386-pv pass test-i386-i386-pv pass test-amd64-amd64-xl-sedf pass test-amd64-i386-win-vcpus1 fail test-amd64-i386-xl-win-vcpus1 fail test-amd64-amd64-win fail test-amd64-i386-win fail test-i386-i386-win fail test-amd64-amd64-xl-win fail test-i386-i386-xl-win fail ------------------------------------------------------------ sg-report-flight on woking.cam.xci-test.com logs: /home/xc_osstest/logs images: /home/xc_osstest/images Logs, config files, etc. are available at http://www.chiark.greenend.org.uk/~xensrcts/logs Test harness code can be found at http://xenbits.xensource.com/gitweb?p=osstest.git;a=summary Pushing revision : + branch=linux + revision=6bec8b4a4c14095d0b7ce424db9d583c3decae6c + . cri-lock-repos ++ . cri-common +++ umask 002 +++ getconfig Repos +++ perl -e ' use Osstest; readconfigonly(); print $c{Repos} or die $!; ' ++ repos=/export/home/osstest/repos ++ repos_lock=/export/home/osstest/repos/lock ++ '[' x '!=' x/export/home/osstest/repos/lock ']' ++ OSSTEST_REPOS_LOCK_LOCKED=/export/home/osstest/repos/lock ++ exec with-lock-ex -w /export/home/osstest/repos/lock ./ap-push linux 6bec8b4a4c14095d0b7ce424db9d583c3decae6c + branch=linux + revision=6bec8b4a4c14095d0b7ce424db9d583c3decae6c + . cri-lock-repos ++ . cri-common +++ umask 002 +++ getconfig Repos +++ perl -e ' use Osstest; readconfigonly(); print $c{Repos} or die $!; ' ++ repos=/export/home/osstest/repos ++ repos_lock=/export/home/osstest/repos/lock ++ '[' x/export/home/osstest/repos/lock '!=' x/export/home/osstest/repos/lock ']' + : xen@xenbits.xensource.com + : xen@xenbits.xensource.com:git/linux-pvops + : master + : tested/2.6.39.x + case "$branch" in + cd /export/home/osstest/repos/xen ./ap-push: line 20: cd: /export/home/osstest/repos/xen: No such file or directory ------------------------------------------------------------ commit 6bec8b4a4c14095d0b7ce424db9d583c3decae6c Author: Jeremy Fitzhardinge <jeremy.fitzhardinge@citrix.com> Date: Fri Sep 2 12:23:22 2011 -0700 Revert "xen/apic: Provide an 'apic_xen' to set the override the apic->[read|write] for all cases." This reverts commit c3dd7941354fa96a71f2613e2c7a1b215fa175dc. It prevents the kernel from booting natively on hardware. Conflicts: arch/x86/xen/enlighten.c Signed-off-by: Jeremy Fitzhardinge <jeremy.fitzhardinge@citrix.com> _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel From xen-devel-bounces@lists.xensource.com Sun Sep 25 09:16:06 2011 Return-path: <xen-devel-bounces@lists.xensource.com> Envelope-to: www-data@lists.xensource.com Delivery-date: Sun, 25 Sep 2011 09:16:06 -0700 Received: from localhost ([127.0.0.1] helo=lists.colo.xensource.com) by lists.xensource.com with esmtp (Exim 4.43) id 1R7rN7-0004JK-56; Sun, 25 Sep 2011 09:16:05 -0700 Received: from mail21.messagelabs.com ([85.158.143.35]) by lists.xensource.com with esmtp (Exim 4.43) id 1R7rM4-000468-76 for xen-devel@lists.xensource.com; Sun, 25 Sep 2011 09:15:02 -0700 X-Env-Sender: Ian.Jackson@eu.citrix.com X-Msg-Ref: server-13.tower-21.messagelabs.com!1316967290!50238584!1 X-Originating-IP: [62.200.22.115] X-StarScan-Version: 6.4.1; banners=-,-,- X-VirusChecked: Checked Received: (qmail 20121 invoked from network); 25 Sep 2011 16:14:50 -0000 Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115) by server-13.tower-21.messagelabs.com with RC4-SHA encrypted SMTP; 25 Sep 2011 16:14:50 -0000 X-IronPort-AV: E=Sophos;i="4.68,440,1312156800"; d="scan'208";a="8047447" Received: from lonpmailmx01.citrite.net ([10.30.203.162]) by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5; 25 Sep 2011 16:14:55 +0000 Received: from woking.xci-test.com (10.80.248.135) by smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id 8.3.137.0; Sun, 25 Sep 2011 17:14:55 +0100 Received: from osstest by woking.xci-test.com with local (Exim 4.69) (envelope-from <ian.jackson@eu.citrix.com>) id 1R7rLz-0007zY-F0; Sun, 25 Sep 2011 17:14:55 +0100 To: xen-devel@lists.xensource.com Message-ID: <osstest-9077-mainreport@xen.org> From: xen.org <ian.jackson@eu.citrix.com> Date: Sun, 25 Sep 2011 17:14:55 +0100 MIME-Version: 1.0 Content-Type: text/plain Cc: ian.jackson@eu.citrix.com Subject: [Xen-devel] [xen-unstable test] 9077: regressions - FAIL X-BeenThere: xen-devel@lists.xensource.com X-Mailman-Version: 2.1.5 Precedence: list List-Id: Xen developer discussion <xen-devel.lists.xensource.com> List-Unsubscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe> List-Post: <mailto:xen-devel@lists.xensource.com> List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help> List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=subscribe> Sender: xen-devel-bounces@lists.xensource.com Errors-To: xen-devel-bounces@lists.xensource.com flight 9077 xen-unstable real [real] http://www.chiark.greenend.org.uk/~xensrcts/logs/9077/ Regressions :-( Tests which did not succeed and are blocking: test-amd64-i386-rhel6hvm-amd 5 xen-boot fail REGR. vs. 8995 Tests which are failing intermittently (not blocking): test-amd64-i386-pv 5 xen-boot fail pass in 9073 test-amd64-amd64-xl 5 xen-boot fail pass in 9075 test-amd64-i386-xl-credit2 5 xen-boot fail pass in 9075 test-i386-i386-xl-win 5 xen-boot fail pass in 9067 test-amd64-i386-xl-win-vcpus1 5 xen-boot fail pass in 9075 test-i386-i386-win 5 xen-boot fail pass in 9071 test-amd64-i386-win-vcpus1 5 xen-boot fail pass in 9075 test-amd64-amd64-xl-win 5 xen-boot fail pass in 9075 test-amd64-amd64-xl-sedf 5 xen-boot fail in 9073 pass in 9077 test-amd64-amd64-win 5 xen-boot fail in 9073 pass in 9077 test-amd64-i386-win 5 xen-boot fail in 9073 pass in 9077 test-amd64-amd64-pv 5 xen-boot fail in 9075 pass in 9077 test-amd64-i386-xl-multivcpu 5 xen-boot fail in 9075 pass in 9077 test-amd64-i386-xl 5 xen-boot fail in 9067 pass in 9077 test-i386-i386-xl 5 xen-boot fail in 9067 pass in 9077 test-i386-i386-pv 5 xen-boot fail in 9071 pass in 9077 test-i386-i386-pair 8 xen-boot/dst_host fail in 9071 pass in 9077 test-i386-i386-pair 7 xen-boot/src_host fail in 9071 pass in 9077 Tests which did not succeed, but are not blocking, including regressions (tests previously passed) regarded as allowable: test-amd64-amd64-xl-pcipt-intel 9 guest-start fail never pass test-amd64-i386-rhel6hvm-intel 9 guest-start.2 fail never pass test-amd64-amd64-win 16 leak-check/check fail never pass test-amd64-i386-win 16 leak-check/check fail never pass test-amd64-amd64-xl-win 13 guest-stop fail in 9073 never pass test-amd64-i386-xl-win-vcpus1 13 guest-stop fail in 9075 never pass test-amd64-i386-win-vcpus1 16 leak-check/check fail in 9075 never pass test-i386-i386-xl-win 13 guest-stop fail in 9067 never pass test-i386-i386-win 16 leak-check/check fail in 9067 never pass version targeted for testing: xen cc339ab1d917 baseline version: xen a422e2a4451e ------------------------------------------------------------ People who touched revisions under test: Andreas Herrmann <herrmann.der.user@googlemail.com> Ian Campbell <ian.campbell@citrix.com> Ian Jackson <ian.jackson@eu.citrix.com> Jan Beulich <jbeulich@suse.com> Lasse Collin <lasse.collin@tukaani.org> Olaf Hering <olaf@aepfle.de> Thomas Renninger <trenn@suse.de> ------------------------------------------------------------ jobs: build-amd64 pass build-i386 pass build-amd64-oldkern pass build-i386-oldkern pass build-amd64-pvops pass build-i386-pvops pass test-amd64-amd64-xl fail test-amd64-i386-xl pass test-i386-i386-xl pass test-amd64-i386-rhel6hvm-amd fail test-amd64-i386-xl-credit2 fail test-amd64-amd64-xl-pcipt-intel fail test-amd64-i386-rhel6hvm-intel fail test-amd64-i386-xl-multivcpu pass test-amd64-amd64-pair pass test-amd64-i386-pair pass test-i386-i386-pair pass test-amd64-amd64-pv pass test-amd64-i386-pv fail test-i386-i386-pv pass test-amd64-amd64-xl-sedf pass test-amd64-i386-win-vcpus1 fail test-amd64-i386-xl-win-vcpus1 fail test-amd64-amd64-win fail test-amd64-i386-win fail test-i386-i386-win fail test-amd64-amd64-xl-win fail test-i386-i386-xl-win fail ------------------------------------------------------------ sg-report-flight on woking.cam.xci-test.com logs: /home/xc_osstest/logs images: /home/xc_osstest/images Logs, config files, etc. are available at http://www.chiark.greenend.org.uk/~xensrcts/logs Test harness code can be found at http://xenbits.xensource.com/gitweb?p=osstest.git;a=summary Not pushing. ------------------------------------------------------------ changeset: 23872:cc339ab1d917 tag: tip user: Ian Campbell <ian.campbell@citrix.com> date: Thu Sep 22 18:37:06 2011 +0100 tools: fix install of lomount $(BIN) went away in 23124:e3d4c34b14a3. Also there are no *.so, *.a or *.rpm built in here Signed-off-by: Ian Campbell <ian.campbell@citrix.com> changeset: 23871:503ee256fecf user: Jan Beulich <jbeulich@suse.com> date: Thu Sep 22 18:35:30 2011 +0100 x86: ucode-amd: Don't warn when no ucode is available for a CPU revision This patch originally comes from the Linus mainline kernel (2.6.33), find below the patch details: From: Andreas Herrmann <herrmann.der.user@googlemail.com> There is no point in warning when there is no ucode available for a specific CPU revision. Currently the container-file, which provides the AMD ucode patches for OS load, contains only a few ucode patches. It's already clearly indicated by the printed patch_level whenever new ucode was available and an update happened. So the warning message is of no help but rather annoying on systems with many CPUs. Signed-off-by: Thomas Renninger <trenn@suse.de> Signed-off-by: Jan Beulich <jbeulich@suse.com> changeset: 23870:5c97b02f48fc user: Jan Beulich <jbeulich@suse.com> date: Thu Sep 22 18:34:27 2011 +0100 XZ: Fix incorrect XZ_BUF_ERROR From: Lasse Collin <lasse.collin@tukaani.org> xz_dec_run() could incorrectly return XZ_BUF_ERROR if all of the following was true: - The caller knows how many bytes of output to expect and only provides that much output space. - When the last output bytes are decoded, the caller-provided input buffer ends right before the LZMA2 end of payload marker. So LZMA2 won't provide more output anymore, but it won't know it yet and thus won't return XZ_STREAM_END yet. - A BCJ filter is in use and it hasn't left any unfiltered bytes in the temp buffer. This can happen with any BCJ filter, but in practice it's more likely with filters other than the x86 BCJ. This fixes <https://bugzilla.redhat.com/show_bug.cgi?id=3D735408> where Squashfs thinks that a valid file system is corrupt. This also fixes a similar bug in single-call mode where the uncompressed size of a block using BCJ + LZMA2 was 0 bytes and caller provided no output space. Many empty .xz files don't contain any blocks and thus don't trigger this bug. This also tweaks a closely related detail: xz_dec_bcj_run() could call xz_dec_lzma2_run() to decode into temp buffer when it was known to be useless. This was harmless although it wasted a minuscule number of CPU cycles. Signed-off-by: Lasse Collin <lasse.collin@tukaani.org> Signed-off-by: Jan Beulich <jbeulich@suse.com> changeset: 23869:db1ea4b127cd user: Jan Beulich <jbeulich@suse.com> date: Thu Sep 22 18:33:48 2011 +0100 XZ decompressor: Fix decoding of empty LZMA2 streams From: Lasse Collin <lasse.collin@tukaani.org> The old code considered valid empty LZMA2 streams to be corrupt. Note that a typical empty .xz file has no LZMA2 data at all, and thus most .xz files having no uncompressed data are handled correctly even without this fix. Signed-off-by: Lasse Collin <lasse.collin@tukaani.org> Signed-off-by: Jan Beulich <jbeulich@suse.com> changeset: 23868:28147fd781af user: Jan Beulich <jbeulich@suse.com> date: Thu Sep 22 18:32:34 2011 +0100 VT-d: fix off-by-one error in RMRR validation (base_addr,end_addr) is an inclusive range, and hence there shouldn't be a subtraction of 1 in the second invocation of page_is_ram_type(). For RMRRs covering a single page that actually resulted in the immediately preceding page to get checked (which could have resulted in a false warning). Signed-off-by: Jan Beulich <jbeulich@suse.com> changeset: 23867:571b6e90dfb4 user: Jan Beulich <jbeulich@suse.com> date: Thu Sep 22 18:31:44 2011 +0100 VT-d: eliminate a mis-use of pcidevs_lock dma_pte_clear_one() shouldn't acquire this global lock for the purpose of processing a per-domain list. Furthermore the function a few lines earlier has a comment stating that acquiring pcidevs_lock isn't necessary here (whether that's really correct is another question). Use the domain's mappin_lock instead to protect the mapped_rmrrs list. Fold domain_rmrr_mapped() into its sole caller so that the otherwise implicit dependency on pcidevs_lock there becomes more obvious (see the comment there). Signed-off-by: Jan Beulich <jbeulich@suse.com> changeset: 23866:47ec1d405af9 user: Jan Beulich <jbeulich@suse.com> date: Thu Sep 22 18:31:02 2011 +0100 x86: IO-APIC code has no dependency on PCI The IRQ handling code requires pcidevs_lock to be held only for MSI interrupts. As the handling of which was now fully moved into msi.c (i.e. while applying fine without, the patch needs to be applied after the one titled "x86: split MSI IRQ chip"), io_apic.c now also doesn't need to include PCI headers anymore. Signed-off-by: Jan Beulich <jbeulich@suse.com> changeset: 23865:d6e01c7853cf user: Jan Beulich <jbeulich@suse.com> date: Thu Sep 22 18:29:19 2011 +0100 PCI multi-seg: config space accessor adjustments Signed-off-by: Jan Beulich <jbeulich@suse.com> changeset: 23864:314b147d524d user: Jan Beulich <jbeulich@suse.com> date: Thu Sep 22 18:28:38 2011 +0100 PCI multi-seg: Pass-through adjustments Signed-off-by: Jan Beulich <jbeulich@suse.com> changeset: 23863:9e0259239822 user: Jan Beulich <jbeulich@suse.com> date: Thu Sep 22 18:28:03 2011 +0100 PCI multi-seg: AMD-IOMMU specific adjustments There are two places here where it is entirely unclear to me where the necessary PCI segment number should be taken from (as IVMD descriptors don't have such, only IVHD ones do). AMD confirmed that for the time being it is acceptable to imply that only segment 0 exists. Signed-off-by: Jan Beulich <jbeulich@suse.com> changeset: 23862:85418e168527 user: Jan Beulich <jbeulich@suse.com> date: Thu Sep 22 18:27:26 2011 +0100 PCI multi-seg: VT-d specific adjustments Signed-off-by: Jan Beulich <jbeulich@suse.com> changeset: 23861:ec7c81fbe0de user: Jan Beulich <jbeulich@suse.com> date: Thu Sep 22 18:26:54 2011 +0100 PCI multi-seg: adjust domctl interface Again, a couple of directly related functions at once get adjusted to account for the segment number. Signed-off-by: Jan Beulich <jbeulich@suse.com> changeset: 23860:a422e2a4451e user: Jan Beulich <jbeulich@suse.com> date: Sun Sep 18 00:26:52 2011 +0100 x86: split MSI IRQ chip With the .end() accessor having become optional and noting that several of the accessors' behavior really depends on the result of msi_maskable_irq(), the splits the MSI IRQ chip type into two - one for the maskable ones, and the other for the (MSI only) non-maskable ones. At once the implementation of those methods gets moved from io_apic.c to msi.c. Signed-off-by: Jan Beulich <jbeulich@suse.com> ======================================== commit cd776ee9408ff127f934a707c1a339ee600bc127 Author: Ian Jackson <ian.jackson@eu.citrix.com> Date: Tue Jun 28 13:50:53 2011 +0100 qemu-char.c: fix incorrect CONFIG_STUBDOM handling qemu-char.c:1123:7: warning: "CONFIG_STUBDOM" is not defined [-Wundef] Signed-off-by: Olaf Hering <olaf@aepfle.de> Acked-by: Ian Jackson <ian.jackson@eu.citrix.com> _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel From xen-devel-bounces@lists.xensource.com Sun Sep 25 10:57:02 2011 Return-path: <xen-devel-bounces@lists.xensource.com> Envelope-to: www-data@lists.xensource.com Delivery-date: Sun, 25 Sep 2011 10:57:02 -0700 Received: from localhost ([127.0.0.1] helo=lists.colo.xensource.com) by lists.xensource.com with esmtp (Exim 4.43) id 1R7swn-0007P0-FY; Sun, 25 Sep 2011 10:57:01 -0700 Received: from mail182.messagelabs.com ([85.158.139.83]) by lists.xensource.com with esmtp (Exim 4.43) id 1R7swA-0007DL-1A for xen-devel@lists.xensource.com; Sun, 25 Sep 2011 10:56:23 -0700 X-Env-Sender: Ian.Jackson@eu.citrix.com X-Msg-Ref: server-2.tower-182.messagelabs.com!1316973378!18666434!1 X-Originating-IP: [62.200.22.115] X-StarScan-Version: 6.4.1; banners=-,-,- X-VirusChecked: Checked Received: (qmail 29485 invoked from network); 25 Sep 2011 17:56:19 -0000 Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115) by server-2.tower-182.messagelabs.com with RC4-SHA encrypted SMTP; 25 Sep 2011 17:56:19 -0000 X-IronPort-AV: E=Sophos;i="4.68,440,1312156800"; d="scan'208";a="8048162" Received: from lonpmailmx01.citrite.net ([10.30.203.162]) by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5; 25 Sep 2011 17:56:18 +0000 Received: from woking.xci-test.com (10.80.248.135) by smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id 8.3.137.0; Sun, 25 Sep 2011 18:56:18 +0100 Received: from osstest by woking.xci-test.com with local (Exim 4.69) (envelope-from <ian.jackson@eu.citrix.com>) id 1R7sw6-0002RJ-5w; Sun, 25 Sep 2011 18:56:18 +0100 To: xen-devel@lists.xensource.com Message-ID: <osstest-9078-mainreport@xen.org> From: xen.org <ian.jackson@eu.citrix.com> Date: Sun, 25 Sep 2011 18:56:18 +0100 MIME-Version: 1.0 Content-Type: text/plain Cc: ian.jackson@eu.citrix.com Subject: [Xen-devel] [linux test] 9078: tolerable FAIL X-BeenThere: xen-devel@lists.xensource.com X-Mailman-Version: 2.1.5 Precedence: list List-Id: Xen developer discussion <xen-devel.lists.xensource.com> List-Unsubscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe> List-Post: <mailto:xen-devel@lists.xensource.com> List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help> List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=subscribe> Sender: xen-devel-bounces@lists.xensource.com Errors-To: xen-devel-bounces@lists.xensource.com flight 9078 linux real [real] http://www.chiark.greenend.org.uk/~xensrcts/logs/9078/ Failures :-/ but no regressions. Tests which are failing intermittently (not blocking): test-amd64-amd64-xl-sedf 10 guest-saverestore fail pass in 9076 Tests which did not succeed, but are not blocking, including regressions (tests previously passed) regarded as allowable: test-amd64-amd64-xl-pcipt-intel 9 guest-start fail never pass test-amd64-i386-rhel6hvm-amd 9 guest-start.2 fail never pass test-amd64-i386-rhel6hvm-intel 9 guest-start.2 fail never pass test-amd64-i386-win-vcpus1 16 leak-check/check fail never pass test-amd64-i386-xl-win-vcpus1 13 guest-stop fail never pass test-amd64-amd64-win 16 leak-check/check fail never pass test-amd64-amd64-xl-win 13 guest-stop fail never pass test-i386-i386-win 16 leak-check/check fail never pass test-i386-i386-xl-win 13 guest-stop fail never pass test-amd64-i386-win 16 leak-check/check fail never pass version targeted for testing: linux 6bec8b4a4c14095d0b7ce424db9d583c3decae6c baseline version: linux 1c3f03ccc5258887f5f2cafc0836a865834f9205 ------------------------------------------------------------ People who touched revisions under test: Jeremy Fitzhardinge <jeremy.fitzhardinge@citrix.com> ------------------------------------------------------------ jobs: build-amd64 pass build-i386 pass build-amd64-pvops pass build-i386-pvops pass test-amd64-amd64-xl pass test-amd64-i386-xl pass test-i386-i386-xl pass test-amd64-i386-rhel6hvm-amd fail test-amd64-i386-xl-credit2 pass test-amd64-amd64-xl-pcipt-intel fail test-amd64-i386-rhel6hvm-intel fail test-amd64-i386-xl-multivcpu pass test-amd64-amd64-pair pass test-amd64-i386-pair pass test-i386-i386-pair pass test-amd64-amd64-pv pass test-amd64-i386-pv pass test-i386-i386-pv pass test-amd64-amd64-xl-sedf fail test-amd64-i386-win-vcpus1 fail test-amd64-i386-xl-win-vcpus1 fail test-amd64-amd64-win fail test-amd64-i386-win fail test-i386-i386-win fail test-amd64-amd64-xl-win fail test-i386-i386-xl-win fail ------------------------------------------------------------ sg-report-flight on woking.cam.xci-test.com logs: /home/xc_osstest/logs images: /home/xc_osstest/images Logs, config files, etc. are available at http://www.chiark.greenend.org.uk/~xensrcts/logs Test harness code can be found at http://xenbits.xensource.com/gitweb?p=osstest.git;a=summary Pushing revision : + branch=linux + revision=6bec8b4a4c14095d0b7ce424db9d583c3decae6c + . cri-lock-repos ++ . cri-common +++ umask 002 +++ getconfig Repos +++ perl -e ' use Osstest; readconfigonly(); print $c{Repos} or die $!; ' ++ repos=/export/home/osstest/repos ++ repos_lock=/export/home/osstest/repos/lock ++ '[' x '!=' x/export/home/osstest/repos/lock ']' ++ OSSTEST_REPOS_LOCK_LOCKED=/export/home/osstest/repos/lock ++ exec with-lock-ex -w /export/home/osstest/repos/lock ./ap-push linux 6bec8b4a4c14095d0b7ce424db9d583c3decae6c + branch=linux + revision=6bec8b4a4c14095d0b7ce424db9d583c3decae6c + . cri-lock-repos ++ . cri-common +++ umask 002 +++ getconfig Repos +++ perl -e ' use Osstest; readconfigonly(); print $c{Repos} or die $!; ' ++ repos=/export/home/osstest/repos ++ repos_lock=/export/home/osstest/repos/lock ++ '[' x/export/home/osstest/repos/lock '!=' x/export/home/osstest/repos/lock ']' + : xen@xenbits.xensource.com + : xen@xenbits.xensource.com:git/linux-pvops + : master + : tested/2.6.39.x + case "$branch" in + cd /export/home/osstest/repos/xen ./ap-push: line 20: cd: /export/home/osstest/repos/xen: No such file or directory ------------------------------------------------------------ commit 6bec8b4a4c14095d0b7ce424db9d583c3decae6c Author: Jeremy Fitzhardinge <jeremy.fitzhardinge@citrix.com> Date: Fri Sep 2 12:23:22 2011 -0700 Revert "xen/apic: Provide an 'apic_xen' to set the override the apic->[read|write] for all cases." This reverts commit c3dd7941354fa96a71f2613e2c7a1b215fa175dc. It prevents the kernel from booting natively on hardware. Conflicts: arch/x86/xen/enlighten.c Signed-off-by: Jeremy Fitzhardinge <jeremy.fitzhardinge@citrix.com> _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel From xen-devel-bounces@lists.xensource.com Sun Sep 25 12:42:43 2011 Return-path: <xen-devel-bounces@lists.xensource.com> Envelope-to: www-data@lists.xensource.com Delivery-date: Sun, 25 Sep 2011 12:42:43 -0700 Received: from localhost ([127.0.0.1] helo=lists.colo.xensource.com) by lists.xensource.com with esmtp (Exim 4.43) id 1R7ub5-0002qU-Iq; Sun, 25 Sep 2011 12:42:43 -0700 Received: from mail174.messagelabs.com ([85.158.138.51]) by lists.xensource.com with esmtp (Exim 4.43) id 1R7uaC-0002e1-PF for xen-devel@lists.xensource.com; Sun, 25 Sep 2011 12:41:49 -0700 X-Env-Sender: Ian.Jackson@eu.citrix.com X-Msg-Ref: server-4.tower-174.messagelabs.com!1316979705!32706353!1 X-Originating-IP: [62.200.22.115] X-StarScan-Version: 6.4.1; banners=-,-,- X-VirusChecked: Checked Received: (qmail 16736 invoked from network); 25 Sep 2011 19:41:45 -0000 Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115) by server-4.tower-174.messagelabs.com with RC4-SHA encrypted SMTP; 25 Sep 2011 19:41:45 -0000 X-IronPort-AV: E=Sophos;i="4.68,440,1312156800"; d="scan'208";a="8048679" Received: from lonpmailmx01.citrite.net ([10.30.203.162]) by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5; 25 Sep 2011 19:41:44 +0000 Received: from woking.xci-test.com (10.80.248.135) by smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id 8.3.137.0; Sun, 25 Sep 2011 20:41:45 +0100 Received: from osstest by woking.xci-test.com with local (Exim 4.69) (envelope-from <ian.jackson@eu.citrix.com>) id 1R7ua8-0007JU-Ed; Sun, 25 Sep 2011 20:41:44 +0100 To: <xen-devel@lists.xensource.com> Message-ID: <osstest-9079-mainreport@xen.org> From: xen.org <ian.jackson@eu.citrix.com> Date: Sun, 25 Sep 2011 20:41:44 +0100 MIME-Version: 1.0 Content-Type: text/plain Cc: ian.jackson@eu.citrix.com Subject: [Xen-devel] [xen-unstable test] 9079: regressions - FAIL X-BeenThere: xen-devel@lists.xensource.com X-Mailman-Version: 2.1.5 Precedence: list List-Id: Xen developer discussion <xen-devel.lists.xensource.com> List-Unsubscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe> List-Post: <mailto:xen-devel@lists.xensource.com> List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help> List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=subscribe> Sender: xen-devel-bounces@lists.xensource.com Errors-To: xen-devel-bounces@lists.xensource.com flight 9079 xen-unstable real [real] http://www.chiark.greenend.org.uk/~xensrcts/logs/9079/ Regressions :-( Tests which did not succeed and are blocking: test-amd64-i386-rhel6hvm-amd 5 xen-boot fail REGR. vs. 8995 Tests which are failing intermittently (not blocking): test-amd64-i386-pv 5 xen-boot fail pass in 9073 test-amd64-amd64-pv 5 xen-boot fail pass in 9077 test-amd64-i386-xl-multivcpu 5 xen-boot fail pass in 9077 test-amd64-amd64-xl-sedf 5 xen-boot fail pass in 9077 test-i386-i386-xl 5 xen-boot fail pass in 9077 test-i386-i386-xl-win 5 xen-boot fail pass in 9067 test-i386-i386-pair 7 xen-boot/src_host fail pass in 9077 test-i386-i386-pair 8 xen-boot/dst_host fail pass in 9077 test-amd64-i386-xl-win-vcpus1 5 xen-boot fail pass in 9075 test-i386-i386-win 5 xen-boot fail pass in 9071 test-amd64-i386-xl-credit2 5 xen-boot fail in 9073 pass in 9079 test-amd64-i386-win-vcpus1 5 xen-boot fail in 9073 pass in 9079 test-amd64-amd64-win 5 xen-boot fail in 9073 pass in 9079 test-amd64-i386-win 5 xen-boot fail in 9073 pass in 9079 test-amd64-amd64-xl 5 xen-boot fail in 9077 pass in 9079 test-amd64-amd64-xl-win 5 xen-boot fail in 9077 pass in 9079 test-amd64-i386-xl 5 xen-boot fail in 9067 pass in 9079 test-i386-i386-pv 5 xen-boot fail in 9071 pass in 9079 Tests which did not succeed, but are not blocking, including regressions (tests previously passed) regarded as allowable: test-amd64-amd64-xl-pcipt-intel 9 guest-start fail never pass test-amd64-i386-rhel6hvm-intel 9 guest-start.2 fail never pass test-amd64-i386-win-vcpus1 16 leak-check/check fail never pass test-amd64-amd64-win 16 leak-check/check fail never pass test-amd64-i386-win 16 leak-check/check fail never pass test-amd64-amd64-xl-win 13 guest-stop fail never pass test-i386-i386-xl-win 13 guest-stop fail in 9067 never pass test-i386-i386-win 16 leak-check/check fail in 9067 never pass test-amd64-i386-xl-win-vcpus1 13 guest-stop fail in 9075 never pass version targeted for testing: xen cc339ab1d917 baseline version: xen a422e2a4451e ------------------------------------------------------------ People who touched revisions under test: Andreas Herrmann <herrmann.der.user@googlemail.com> Ian Campbell <ian.campbell@citrix.com> Ian Jackson <ian.jackson@eu.citrix.com> Jan Beulich <jbeulich@suse.com> Lasse Collin <lasse.collin@tukaani.org> Olaf Hering <olaf@aepfle.de> Thomas Renninger <trenn@suse.de> ------------------------------------------------------------ jobs: build-amd64 pass build-i386 pass build-amd64-oldkern pass build-i386-oldkern pass build-amd64-pvops pass build-i386-pvops pass test-amd64-amd64-xl pass test-amd64-i386-xl pass test-i386-i386-xl fail test-amd64-i386-rhel6hvm-amd fail test-amd64-i386-xl-credit2 pass test-amd64-amd64-xl-pcipt-intel fail test-amd64-i386-rhel6hvm-intel fail test-amd64-i386-xl-multivcpu fail test-amd64-amd64-pair pass test-amd64-i386-pair pass test-i386-i386-pair fail test-amd64-amd64-pv fail test-amd64-i386-pv fail test-i386-i386-pv pass test-amd64-amd64-xl-sedf fail test-amd64-i386-win-vcpus1 fail test-amd64-i386-xl-win-vcpus1 fail test-amd64-amd64-win fail test-amd64-i386-win fail test-i386-i386-win fail test-amd64-amd64-xl-win fail test-i386-i386-xl-win fail ------------------------------------------------------------ sg-report-flight on woking.cam.xci-test.com logs: /home/xc_osstest/logs images: /home/xc_osstest/images Logs, config files, etc. are available at http://www.chiark.greenend.org.uk/~xensrcts/logs Test harness code can be found at http://xenbits.xensource.com/gitweb?p=osstest.git;a=summary Not pushing. ------------------------------------------------------------ changeset: 23872:cc339ab1d917 tag: tip user: Ian Campbell <ian.campbell@citrix.com> date: Thu Sep 22 18:37:06 2011 +0100 tools: fix install of lomount $(BIN) went away in 23124:e3d4c34b14a3. Also there are no *.so, *.a or *.rpm built in here Signed-off-by: Ian Campbell <ian.campbell@citrix.com> changeset: 23871:503ee256fecf user: Jan Beulich <jbeulich@suse.com> date: Thu Sep 22 18:35:30 2011 +0100 x86: ucode-amd: Don't warn when no ucode is available for a CPU revision This patch originally comes from the Linus mainline kernel (2.6.33), find below the patch details: From: Andreas Herrmann <herrmann.der.user@googlemail.com> There is no point in warning when there is no ucode available for a specific CPU revision. Currently the container-file, which provides the AMD ucode patches for OS load, contains only a few ucode patches. It's already clearly indicated by the printed patch_level whenever new ucode was available and an update happened. So the warning message is of no help but rather annoying on systems with many CPUs. Signed-off-by: Thomas Renninger <trenn@suse.de> Signed-off-by: Jan Beulich <jbeulich@suse.com> changeset: 23870:5c97b02f48fc user: Jan Beulich <jbeulich@suse.com> date: Thu Sep 22 18:34:27 2011 +0100 XZ: Fix incorrect XZ_BUF_ERROR From: Lasse Collin <lasse.collin@tukaani.org> xz_dec_run() could incorrectly return XZ_BUF_ERROR if all of the following was true: - The caller knows how many bytes of output to expect and only provides that much output space. - When the last output bytes are decoded, the caller-provided input buffer ends right before the LZMA2 end of payload marker. So LZMA2 won't provide more output anymore, but it won't know it yet and thus won't return XZ_STREAM_END yet. - A BCJ filter is in use and it hasn't left any unfiltered bytes in the temp buffer. This can happen with any BCJ filter, but in practice it's more likely with filters other than the x86 BCJ. This fixes <https://bugzilla.redhat.com/show_bug.cgi?id=3D735408> where Squashfs thinks that a valid file system is corrupt. This also fixes a similar bug in single-call mode where the uncompressed size of a block using BCJ + LZMA2 was 0 bytes and caller provided no output space. Many empty .xz files don't contain any blocks and thus don't trigger this bug. This also tweaks a closely related detail: xz_dec_bcj_run() could call xz_dec_lzma2_run() to decode into temp buffer when it was known to be useless. This was harmless although it wasted a minuscule number of CPU cycles. Signed-off-by: Lasse Collin <lasse.collin@tukaani.org> Signed-off-by: Jan Beulich <jbeulich@suse.com> changeset: 23869:db1ea4b127cd user: Jan Beulich <jbeulich@suse.com> date: Thu Sep 22 18:33:48 2011 +0100 XZ decompressor: Fix decoding of empty LZMA2 streams From: Lasse Collin <lasse.collin@tukaani.org> The old code considered valid empty LZMA2 streams to be corrupt. Note that a typical empty .xz file has no LZMA2 data at all, and thus most .xz files having no uncompressed data are handled correctly even without this fix. Signed-off-by: Lasse Collin <lasse.collin@tukaani.org> Signed-off-by: Jan Beulich <jbeulich@suse.com> changeset: 23868:28147fd781af user: Jan Beulich <jbeulich@suse.com> date: Thu Sep 22 18:32:34 2011 +0100 VT-d: fix off-by-one error in RMRR validation (base_addr,end_addr) is an inclusive range, and hence there shouldn't be a subtraction of 1 in the second invocation of page_is_ram_type(). For RMRRs covering a single page that actually resulted in the immediately preceding page to get checked (which could have resulted in a false warning). Signed-off-by: Jan Beulich <jbeulich@suse.com> changeset: 23867:571b6e90dfb4 user: Jan Beulich <jbeulich@suse.com> date: Thu Sep 22 18:31:44 2011 +0100 VT-d: eliminate a mis-use of pcidevs_lock dma_pte_clear_one() shouldn't acquire this global lock for the purpose of processing a per-domain list. Furthermore the function a few lines earlier has a comment stating that acquiring pcidevs_lock isn't necessary here (whether that's really correct is another question). Use the domain's mappin_lock instead to protect the mapped_rmrrs list. Fold domain_rmrr_mapped() into its sole caller so that the otherwise implicit dependency on pcidevs_lock there becomes more obvious (see the comment there). Signed-off-by: Jan Beulich <jbeulich@suse.com> changeset: 23866:47ec1d405af9 user: Jan Beulich <jbeulich@suse.com> date: Thu Sep 22 18:31:02 2011 +0100 x86: IO-APIC code has no dependency on PCI The IRQ handling code requires pcidevs_lock to be held only for MSI interrupts. As the handling of which was now fully moved into msi.c (i.e. while applying fine without, the patch needs to be applied after the one titled "x86: split MSI IRQ chip"), io_apic.c now also doesn't need to include PCI headers anymore. Signed-off-by: Jan Beulich <jbeulich@suse.com> changeset: 23865:d6e01c7853cf user: Jan Beulich <jbeulich@suse.com> date: Thu Sep 22 18:29:19 2011 +0100 PCI multi-seg: config space accessor adjustments Signed-off-by: Jan Beulich <jbeulich@suse.com> changeset: 23864:314b147d524d user: Jan Beulich <jbeulich@suse.com> date: Thu Sep 22 18:28:38 2011 +0100 PCI multi-seg: Pass-through adjustments Signed-off-by: Jan Beulich <jbeulich@suse.com> changeset: 23863:9e0259239822 user: Jan Beulich <jbeulich@suse.com> date: Thu Sep 22 18:28:03 2011 +0100 PCI multi-seg: AMD-IOMMU specific adjustments There are two places here where it is entirely unclear to me where the necessary PCI segment number should be taken from (as IVMD descriptors don't have such, only IVHD ones do). AMD confirmed that for the time being it is acceptable to imply that only segment 0 exists. Signed-off-by: Jan Beulich <jbeulich@suse.com> changeset: 23862:85418e168527 user: Jan Beulich <jbeulich@suse.com> date: Thu Sep 22 18:27:26 2011 +0100 PCI multi-seg: VT-d specific adjustments Signed-off-by: Jan Beulich <jbeulich@suse.com> changeset: 23861:ec7c81fbe0de user: Jan Beulich <jbeulich@suse.com> date: Thu Sep 22 18:26:54 2011 +0100 PCI multi-seg: adjust domctl interface Again, a couple of directly related functions at once get adjusted to account for the segment number. Signed-off-by: Jan Beulich <jbeulich@suse.com> changeset: 23860:a422e2a4451e user: Jan Beulich <jbeulich@suse.com> date: Sun Sep 18 00:26:52 2011 +0100 x86: split MSI IRQ chip With the .end() accessor having become optional and noting that several of the accessors' behavior really depends on the result of msi_maskable_irq(), the splits the MSI IRQ chip type into two - one for the maskable ones, and the other for the (MSI only) non-maskable ones. At once the implementation of those methods gets moved from io_apic.c to msi.c. Signed-off-by: Jan Beulich <jbeulich@suse.com> ======================================== commit cd776ee9408ff127f934a707c1a339ee600bc127 Author: Ian Jackson <ian.jackson@eu.citrix.com> Date: Tue Jun 28 13:50:53 2011 +0100 qemu-char.c: fix incorrect CONFIG_STUBDOM handling qemu-char.c:1123:7: warning: "CONFIG_STUBDOM" is not defined [-Wundef] Signed-off-by: Olaf Hering <olaf@aepfle.de> Acked-by: Ian Jackson <ian.jackson@eu.citrix.com> _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel From xen-api-bounces@lists.xensource.com Sun Sep 25 13:12:19 2011 Return-path: <xen-api-bounces@lists.xensource.com> Envelope-to: www-data@lists.xensource.com Delivery-date: Sun, 25 Sep 2011 13:12:19 -0700 Received: from localhost ([127.0.0.1] helo=lists.colo.xensource.com) by lists.xensource.com with esmtp (Exim 4.43) id 1R7v3i-0004GF-Cy; Sun, 25 Sep 2011 13:12:18 -0700 Received: from mail216.messagelabs.com ([85.158.143.99]) by lists.xensource.com with esmtp (Exim 4.43) id 1R7v2r-0004Cb-Ul; Sun, 25 Sep 2011 13:11:40 -0700 X-Env-Sender: torushikeshj@gmail.com X-Msg-Ref: server-14.tower-216.messagelabs.com!1316981479!19540240!1 X-Originating-IP: [209.85.210.49] X-StarScan-Version: 6.4.1; banners=-,-,- X-VirusChecked: Checked Received: (qmail 14436 invoked from network); 25 Sep 2011 20:11:21 -0000 Received: from mail-pz0-f49.google.com (HELO mail-pz0-f49.google.com) (209.85.210.49) by server-14.tower-216.messagelabs.com with RC4-SHA encrypted SMTP; 25 Sep 2011 20:11:21 -0000 Received: by pzk34 with SMTP id 34so12913633pzk.8 for <multiple recipients>; Sun, 25 Sep 2011 13:11:19 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:date:message-id:subject:from:to:content-type; bh=aFx3soaAp2cNIqCRyAO1RDC4eOpanFzyxnRr1Qy1zd4=; b=xWJYNyznizU62aaLmd7Z3tkOienWP5okGFxaSQmUsB4/rgXCfDUjJ1S2MDhUptJ1Ym ZJZNAAFd8lNG0eLby5XFg6of7GdBBo9Nglg3yhywBazi+utHRqgjxkjMDK9Isd24ascA YT8MYm92JBGWRkyc0vVZkwsMXRSgOfXZ7bdfk= MIME-Version: 1.0 Received: by 10.68.34.69 with SMTP id x5mr24731417pbi.121.1316981479437; Sun, 25 Sep 2011 13:11:19 -0700 (PDT) Received: by 10.142.196.15 with HTTP; Sun, 25 Sep 2011 13:11:19 -0700 (PDT) Date: Mon, 26 Sep 2011 01:41:19 +0530 Message-ID: <CAO14VsP9by7CYgSiVN-hY0rJpDk0MYjuJ+FD5Tp3i8w+BcNYHw@mail.gmail.com> From: R J <torushikeshj@gmail.com> To: xen-api@lists.xensource.com, xen-devel@lists.xensource.com, xen-users@lists.xensource.com Cc: Subject: [Xen-API] FT for XCP X-BeenThere: xen-api@lists.xensource.com X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussion of API issues surrounding Xen <xen-api.lists.xensource.com> List-Unsubscribe: <http://lists.xensource.com/mailman/listinfo/xen-api>, <mailto:xen-api-request@lists.xensource.com?subject=unsubscribe> List-Post: <mailto:xen-api@lists.xensource.com> List-Help: <mailto:xen-api-request@lists.xensource.com?subject=help> List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-api>, <mailto:xen-api-request@lists.xensource.com?subject=subscribe> Content-Type: multipart/mixed; boundary="===============0461446668==" Sender: xen-api-bounces@lists.xensource.com Errors-To: xen-api-bounces@lists.xensource.com --===============0461446668== Content-Type: multipart/alternative; boundary=bcaec520e5a741f50704adc9a527 --bcaec520e5a741f50704adc9a527 Content-Type: text/plain; charset=ISO-8859-1 Hello List, I have a proposal and wont mind to implement my self but need a helping hand to start on. I want to implement the aggressive FT feature in XCP. The best way I could imagine is the use of feature *Live Migration* Steps 1. Enable the FT of a particular VM using xe commands and adding as a param to that VM e.g. xe vm-param-set FT=true uuid=XYZ 2. If the FT = true detected by xenstore then xapi will initiate a live migrate of that VM to any of available host. 3. A parallel "network ping"/"xapi heartbit" from/to that host could be initialized for each FT VM. 4. Live migrate will run forever until its disabled by FT = false or one of the host is down. e.g. the process will loop at 99.99% migration state 5. If there is a packet drop of x packets the VM Migrate procedure will mark the VM Migration as Complete and will switch the devices forcefully. -- this could result in some data loss but I dont have any alternative to this. -- The specific x packets can be set by XCP but we cant rely for default XCP Errors 6. If there is a successful migration due to host down then we will again start from step2 Above steps I have assumed to my knowledge, we can discuss the problems in it. Apologies if I'm being too naive. Regards, Rushikesh --bcaec520e5a741f50704adc9a527 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Hello List,<br><br>I have a proposal and wont mind to implement my self but= need a helping hand to start on.<br>I want to implement the aggressive FT = feature in XCP. The best way I could imagine is the use of feature *Live Mi= gration*<br> <br>Steps<br>1. Enable the FT of a particular VM using xe commands and addi= ng as a param to that VM e.g. xe vm-param-set FT=3Dtrue uuid=3DXYZ<br>2. If= the FT =3D true detected by xenstore then xapi will initiate a live migrat= e of that VM to any of available host.<br> 3. A parallel "network ping"/"xapi heartbit" from/to th= at host could be initialized for each FT VM.<br>4. Live migrate will run fo= rever until its disabled by FT =3D false or one of the host is down. e.g. t= he process will loop at 99.99% migration state<br> 5. If there is a packet drop of x packets the VM Migrate procedure will mar= k the VM Migration as Complete and will switch the devices forcefully.<br>-= - this could result in some data loss but I dont have any alternative to th= is.<br> -- The specific x packets can be set by XCP but we cant rely for default XC= P Errors<br>6. If there is a successful migration due to host down then we = will again start from step2<br><br>Above steps I have assumed to my knowled= ge, we can discuss the problems in it.<br> <br>Apologies if I'm being too naive.<br><br>Regards,<br>Rushikesh<br><= br> --bcaec520e5a741f50704adc9a527-- --===============0461446668== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ xen-api mailing list xen-api@lists.xensource.com http://lists.xensource.com/mailman/listinfo/xen-api --===============0461446668==-- From xen-devel-bounces@lists.xensource.com Sun Sep 25 14:31:20 2011 Return-path: <xen-devel-bounces@lists.xensource.com> Envelope-to: www-data@lists.xensource.com Delivery-date: Sun, 25 Sep 2011 14:31:20 -0700 Received: from localhost ([127.0.0.1] helo=lists.colo.xensource.com) by lists.xensource.com with esmtp (Exim 4.43) id 1R7wIB-0006MB-UK; Sun, 25 Sep 2011 14:31:20 -0700 Received: from mail182.messagelabs.com ([85.158.139.83]) by lists.xensource.com with esmtp (Exim 4.43) id 1R7wHH-00069R-SK for xen-devel@lists.xensource.com; Sun, 25 Sep 2011 14:30:24 -0700 X-Env-Sender: Ian.Jackson@eu.citrix.com X-Msg-Ref: server-3.tower-182.messagelabs.com!1316986220!16886165!1 X-Originating-IP: [62.200.22.115] X-StarScan-Version: 6.4.1; banners=-,-,- X-VirusChecked: Checked Received: (qmail 5459 invoked from network); 25 Sep 2011 21:30:20 -0000 Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115) by server-3.tower-182.messagelabs.com with RC4-SHA encrypted SMTP; 25 Sep 2011 21:30:20 -0000 X-IronPort-AV: E=Sophos;i="4.68,440,1312156800"; d="scan'208";a="8049033" Received: from lonpmailmx01.citrite.net ([10.30.203.162]) by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5; 25 Sep 2011 21:30:20 +0000 Received: from woking.xci-test.com (10.80.248.135) by smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id 8.3.137.0; Sun, 25 Sep 2011 22:30:20 +0100 Received: from osstest by woking.xci-test.com with local (Exim 4.69) (envelope-from <ian.jackson@eu.citrix.com>) id 1R7wHD-0001Hn-VK; Sun, 25 Sep 2011 22:30:20 +0100 To: xen-devel@lists.xensource.com Message-ID: <osstest-9080-mainreport@xen.org> From: xen.org <ian.jackson@eu.citrix.com> Date: Sun, 25 Sep 2011 22:30:19 +0100 MIME-Version: 1.0 Content-Type: text/plain Cc: ian.jackson@eu.citrix.com Subject: [Xen-devel] [linux test] 9080: tolerable FAIL X-BeenThere: xen-devel@lists.xensource.com X-Mailman-Version: 2.1.5 Precedence: list List-Id: Xen developer discussion <xen-devel.lists.xensource.com> List-Unsubscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe> List-Post: <mailto:xen-devel@lists.xensource.com> List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help> List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=subscribe> Sender: xen-devel-bounces@lists.xensource.com Errors-To: xen-devel-bounces@lists.xensource.com flight 9080 linux real [real] http://www.chiark.greenend.org.uk/~xensrcts/logs/9080/ Failures :-/ but no regressions. Tests which did not succeed, but are not blocking, including regressions (tests previously passed) regarded as allowable: test-amd64-amd64-xl-pcipt-intel 9 guest-start fail never pass test-amd64-i386-rhel6hvm-amd 9 guest-start.2 fail never pass test-amd64-i386-rhel6hvm-intel 9 guest-start.2 fail never pass test-amd64-i386-win-vcpus1 16 leak-check/check fail never pass test-amd64-i386-xl-win-vcpus1 13 guest-stop fail never pass test-amd64-amd64-win 16 leak-check/check fail never pass test-amd64-amd64-xl-win 13 guest-stop fail never pass test-i386-i386-win 16 leak-check/check fail never pass test-i386-i386-xl-win 13 guest-stop fail never pass test-amd64-i386-win 16 leak-check/check fail never pass version targeted for testing: linux 6bec8b4a4c14095d0b7ce424db9d583c3decae6c baseline version: linux 1c3f03ccc5258887f5f2cafc0836a865834f9205 ------------------------------------------------------------ People who touched revisions under test: Jeremy Fitzhardinge <jeremy.fitzhardinge@citrix.com> ------------------------------------------------------------ jobs: build-amd64 pass build-i386 pass build-amd64-pvops pass build-i386-pvops pass test-amd64-amd64-xl pass test-amd64-i386-xl pass test-i386-i386-xl pass test-amd64-i386-rhel6hvm-amd fail test-amd64-i386-xl-credit2 pass test-amd64-amd64-xl-pcipt-intel fail test-amd64-i386-rhel6hvm-intel fail test-amd64-i386-xl-multivcpu pass test-amd64-amd64-pair pass test-amd64-i386-pair pass test-i386-i386-pair pass test-amd64-amd64-pv pass test-amd64-i386-pv pass test-i386-i386-pv pass test-amd64-amd64-xl-sedf pass test-amd64-i386-win-vcpus1 fail test-amd64-i386-xl-win-vcpus1 fail test-amd64-amd64-win fail test-amd64-i386-win fail test-i386-i386-win fail test-amd64-amd64-xl-win fail test-i386-i386-xl-win fail ------------------------------------------------------------ sg-report-flight on woking.cam.xci-test.com logs: /home/xc_osstest/logs images: /home/xc_osstest/images Logs, config files, etc. are available at http://www.chiark.greenend.org.uk/~xensrcts/logs Test harness code can be found at http://xenbits.xensource.com/gitweb?p=osstest.git;a=summary Pushing revision : + branch=linux + revision=6bec8b4a4c14095d0b7ce424db9d583c3decae6c + . cri-lock-repos ++ . cri-common +++ umask 002 +++ getconfig Repos +++ perl -e ' use Osstest; readconfigonly(); print $c{Repos} or die $!; ' ++ repos=/export/home/osstest/repos ++ repos_lock=/export/home/osstest/repos/lock ++ '[' x '!=' x/export/home/osstest/repos/lock ']' ++ OSSTEST_REPOS_LOCK_LOCKED=/export/home/osstest/repos/lock ++ exec with-lock-ex -w /export/home/osstest/repos/lock ./ap-push linux 6bec8b4a4c14095d0b7ce424db9d583c3decae6c + branch=linux + revision=6bec8b4a4c14095d0b7ce424db9d583c3decae6c + . cri-lock-repos ++ . cri-common +++ umask 002 +++ getconfig Repos +++ perl -e ' use Osstest; readconfigonly(); print $c{Repos} or die $!; ' ++ repos=/export/home/osstest/repos ++ repos_lock=/export/home/osstest/repos/lock ++ '[' x/export/home/osstest/repos/lock '!=' x/export/home/osstest/repos/lock ']' + : xen@xenbits.xensource.com + : xen@xenbits.xensource.com:git/linux-pvops + : master + : tested/2.6.39.x + case "$branch" in + cd /export/home/osstest/repos/xen ./ap-push: line 20: cd: /export/home/osstest/repos/xen: No such file or directory ------------------------------------------------------------ commit 6bec8b4a4c14095d0b7ce424db9d583c3decae6c Author: Jeremy Fitzhardinge <jeremy.fitzhardinge@citrix.com> Date: Fri Sep 2 12:23:22 2011 -0700 Revert "xen/apic: Provide an 'apic_xen' to set the override the apic->[read|write] for all cases." This reverts commit c3dd7941354fa96a71f2613e2c7a1b215fa175dc. It prevents the kernel from booting natively on hardware. Conflicts: arch/x86/xen/enlighten.c Signed-off-by: Jeremy Fitzhardinge <jeremy.fitzhardinge@citrix.com> _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel From xen-devel-bounces@lists.xensource.com Sun Sep 25 15:07:46 2011 Return-path: <xen-devel-bounces@lists.xensource.com> Envelope-to: www-data@lists.xensource.com Delivery-date: Sun, 25 Sep 2011 15:07:46 -0700 Received: from localhost ([127.0.0.1] helo=lists.colo.xensource.com) by lists.xensource.com with esmtp (Exim 4.43) id 1R7wrS-0008Ah-Nm; Sun, 25 Sep 2011 15:07:46 -0700 Received: from mail216.messagelabs.com ([85.158.143.99]) by lists.xensource.com with esmtp (Exim 4.43) id 1R7wqU-0007yE-D3 for xen-devel@lists.xensource.com; Sun, 25 Sep 2011 15:06:47 -0700 X-Env-Sender: tknchris@gmail.com X-Msg-Ref: server-11.tower-216.messagelabs.com!1316988402!11962950!1 X-Originating-IP: [209.85.160.171] X-StarScan-Version: 6.4.1; banners=-,-,- X-VirusChecked: Checked Received: (qmail 23902 invoked from network); 25 Sep 2011 22:06:43 -0000 Received: from mail-gy0-f171.google.com (HELO mail-gy0-f171.google.com) (209.85.160.171) by server-11.tower-216.messagelabs.com with RC4-SHA encrypted SMTP; 25 Sep 2011 22:06:43 -0000 Received: by gyh3 with SMTP id 3so5946620gyh.30 for <xen-devel@lists.xensource.com>; Sun, 25 Sep 2011 15:06:41 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:date:message-id:subject:from:to:content-type; bh=13DtQcbkhlKNsf5m7vDmJPfyFkMxJeZXAwKMiQ2A0ZI=; b=Fn3v6SWlapP2dtgB+p0CgAsdj11qhNlB87vqpnfc+2gRTi5bHd3iuN2TFt+X+QlpZU bkKxauqivBkeuJUL4u9SOCMEKwqJf4xiAIx0nJCeeRD/ywP0bk+FMU4R1/Huf0elUqJ1 wUEJWEdudIsb/Bq9o5MJy4ZjuO8+TJVw2z6bU= MIME-Version: 1.0 Received: by 10.42.154.136 with SMTP id q8mr6437653icw.109.1316988401687; Sun, 25 Sep 2011 15:06:41 -0700 (PDT) Received: by 10.42.177.137 with HTTP; Sun, 25 Sep 2011 15:06:41 -0700 (PDT) Date: Sun, 25 Sep 2011 18:06:41 -0400 Message-ID: <CAKnNFz_yraTP0-BrGQrC5BwzKKUmFVUqjDqbMhNu6-Nq6dVptQ@mail.gmail.com> From: chris <tknchris@gmail.com> To: Xen-Devel List <xen-devel@lists.xensource.com> Subject: [Xen-devel] PVUSB not working on squeeze X-BeenThere: xen-devel@lists.xensource.com X-Mailman-Version: 2.1.5 Precedence: list List-Id: Xen developer discussion <xen-devel.lists.xensource.com> List-Unsubscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe> List-Post: <mailto:xen-devel@lists.xensource.com> List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help> List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=subscribe> Content-Type: multipart/mixed; boundary="===============0599742205==" Sender: xen-devel-bounces@lists.xensource.com Errors-To: xen-devel-bounces@lists.xensource.com --===============0599742205== Content-Type: multipart/alternative; boundary=90e6ba6e8b1adb1ded04adcb416f --90e6ba6e8b1adb1ded04adcb416f Content-Type: text/plain; charset=ISO-8859-1 Hello,, I am trying to use PVUSB on a debian squeeze dom0 as well as a squeeze domU. The error suggested I email here, so here it is. I do the following root@dom0:~# xm usb-hc-create vm-test 2 16 root@dom0:~# xm usb-list-assignable-devices 1-7 : ID 17e9:0136 DisplayLink DL-195 Adapter root@dom0:~# xm usb-attach vm-test 0 1 1-7 Unexpected error: <class 'xen.util.vusb_util.UsbDeviceParseError'> Please report to xen-devel@lists.xensource.com Traceback (most recent call last): File "/usr/lib/xen-4.0/bin/xm", line 8, in <module> main.main(sys.argv) File "/usr/lib/xen-4.0/lib/python/xen/xm/main.py", line 3620, in main _, rc = _run_cmd(cmd, cmd_name, args) File "/usr/lib/xen-4.0/lib/python/xen/xm/main.py", line 3644, in _run_cmd return True, cmd(args) File "/usr/lib/xen-4.0/lib/python/xen/xm/main.py", line 2868, in xm_usb_attach if vusb_util.bus_is_assigned(bus): File "/usr/lib/xen-4.0/lib/python/xen/util/vusb_util.py", line 275, in bus_is_assigned raise UsbDeviceParseError("Can't get assignment status: (%s)." % bus) xen.util.vusb_util.UsbDeviceParseError: vusb: Error parsing USB device info: Can't get assignment status: (1-7). root@dom0:~# uname -a Linux dom0 2.6.32-5-xen-amd64 #1 SMP Tue Jun 14 12:46:30 UTC 2011 x86_64 GNU/Linux One thing I noticed is that I don't see any kind of usbfront module or any usb frontend in lsmod. Is there some backend/frontend lacking in the squeeze kernel? Any help would be greatly appreciated. - chris --90e6ba6e8b1adb1ded04adcb416f Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Hello,,<div><br></div><div>I am trying to use PVUSB on a debian squeeze dom= 0 as well as a squeeze domU.=A0The error suggested I email here, so here it= is.=A0I do the following</div><div><br></div><div><div>root@dom0:~# xm usb= -hc-create vm-test 2 16</div> </div><div><div><br></div><div>root@dom0:~# xm usb-list-assignable-devices<= /div><div>1-7 =A0 =A0 =A0 =A0 =A0: ID 17e9:0136 DisplayLink DL-195 Adapter<= /div><div><br></div><div><div>root@dom0:~# xm usb-attach vm-test 0 1 1-7</d= iv><div> Unexpected error: <class 'xen.util.vusb_util.UsbDeviceParseError'= ;></div><div><br></div><div>Please report to <a href=3D"mailto:xen-devel= @lists.xensource.com">xen-devel@lists.xensource.com</a></div><div>Traceback= (most recent call last):</div> <div>=A0 File "/usr/lib/xen-4.0/bin/xm", line 8, in <module>= ;</div><div>=A0 =A0 main.main(sys.argv)</div><div>=A0 File "/usr/lib/x= en-4.0/lib/python/xen/xm/main.py", line 3620, in main</div><div>=A0 = =A0 _, rc =3D _run_cmd(cmd, cmd_name, args)</div> <div>=A0 File "/usr/lib/xen-4.0/lib/python/xen/xm/main.py", line = 3644, in _run_cmd</div><div>=A0 =A0 return True, cmd(args)</div><div>=A0 Fi= le "/usr/lib/xen-4.0/lib/python/xen/xm/main.py", line 2868, in xm= _usb_attach</div> <div>=A0 =A0 if vusb_util.bus_is_assigned(bus):</div><div>=A0 File "/u= sr/lib/xen-4.0/lib/python/xen/util/vusb_util.py", line 275, in bus_is_= assigned</div><div>=A0 =A0 raise UsbDeviceParseError("Can't get as= signment status: (%s)." % bus)</div> <div>xen.util.vusb_util.UsbDeviceParseError: vusb: Error parsing USB device= info: Can't get assignment status: (1-7).</div><div>root@dom0:~# uname= -a</div><div>Linux dom0 2.6.32-5-xen-amd64 #1 SMP Tue Jun 14 12:46:30 UTC = 2011 x86_64 GNU/Linux</div> </div><div><br></div><div><br></div></div><div>One thing I noticed is that = I don't see any kind of usbfront module or any usb frontend in lsmod. I= s there some backend/frontend lacking in the squeeze kernel?</div><div> <br></div><div>Any help would be greatly appreciated.</div><div><br></div><= div>- chris</div> --90e6ba6e8b1adb1ded04adcb416f-- --===============0599742205== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel --===============0599742205==-- From xen-devel-bounces@lists.xensource.com Sun Sep 25 15:47:46 2011 Return-path: <xen-devel-bounces@lists.xensource.com> Envelope-to: www-data@lists.xensource.com Delivery-date: Sun, 25 Sep 2011 15:47:46 -0700 Received: from localhost ([127.0.0.1] helo=lists.colo.xensource.com) by lists.xensource.com with esmtp (Exim 4.43) id 1R7xUA-0001AF-QQ; Sun, 25 Sep 2011 15:47:46 -0700 Received: from mail216.messagelabs.com ([85.158.143.99]) by lists.xensource.com with esmtp (Exim 4.43) id 1R7xTV-0000y7-US for xen-devel@lists.xensource.com; Sun, 25 Sep 2011 15:47:06 -0700 X-Env-Sender: Ian.Jackson@eu.citrix.com X-Msg-Ref: server-3.tower-216.messagelabs.com!1316990822!18513017!1 X-Originating-IP: [62.200.22.115] X-StarScan-Version: 6.4.1; banners=-,-,- X-VirusChecked: Checked Received: (qmail 26290 invoked from network); 25 Sep 2011 22:47:03 -0000 Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115) by server-3.tower-216.messagelabs.com with RC4-SHA encrypted SMTP; 25 Sep 2011 22:47:03 -0000 X-IronPort-AV: E=Sophos;i="4.68,441,1312156800"; d="scan'208";a="8049261" Received: from lonpmailmx01.citrite.net ([10.30.203.162]) by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5; 25 Sep 2011 22:47:02 +0000 Received: from woking.xci-test.com (10.80.248.135) by smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id 8.3.137.0; Sun, 25 Sep 2011 23:47:02 +0100 Received: from osstest by woking.xci-test.com with local (Exim 4.69) (envelope-from <ian.jackson@eu.citrix.com>) id 1R7xTR-0008Ps-V7; Sun, 25 Sep 2011 23:47:02 +0100 To: xen-devel@lists.xensource.com Message-ID: <osstest-9081-mainreport@xen.org> From: xen.org <ian.jackson@eu.citrix.com> Date: Sun, 25 Sep 2011 23:47:01 +0100 MIME-Version: 1.0 Content-Type: text/plain Cc: ian.jackson@eu.citrix.com Subject: [Xen-devel] [xen-unstable test] 9081: regressions - FAIL X-BeenThere: xen-devel@lists.xensource.com X-Mailman-Version: 2.1.5 Precedence: list List-Id: Xen developer discussion <xen-devel.lists.xensource.com> List-Unsubscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe> List-Post: <mailto:xen-devel@lists.xensource.com> List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help> List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=subscribe> Sender: xen-devel-bounces@lists.xensource.com Errors-To: xen-devel-bounces@lists.xensource.com flight 9081 xen-unstable real [real] http://www.chiark.greenend.org.uk/~xensrcts/logs/9081/ Regressions :-( Tests which did not succeed and are blocking: test-amd64-i386-rhel6hvm-amd 5 xen-boot fail REGR. vs. 8995 Tests which are failing intermittently (not blocking): test-amd64-amd64-xl 5 xen-boot fail pass in 9079 test-i386-i386-pv 5 xen-boot fail pass in 9079 test-amd64-i386-xl 5 xen-boot fail pass in 9079 test-amd64-amd64-xl-sedf 7 debian-install fail pass in 9077 test-i386-i386-xl-win 5 xen-boot fail pass in 9067 test-amd64-i386-pair 7 xen-boot/src_host fail pass in 9079 test-amd64-i386-pair 8 xen-boot/dst_host fail pass in 9079 test-i386-i386-win 5 xen-boot fail pass in 9071 test-amd64-i386-win-vcpus1 5 xen-boot fail pass in 9079 test-amd64-i386-win 5 xen-boot fail pass in 9079 test-amd64-amd64-xl-win 5 xen-boot fail pass in 9079 test-amd64-i386-pv 5 xen-boot fail in 9079 pass in 9081 test-amd64-amd64-pv 5 xen-boot fail in 9079 pass in 9081 test-amd64-i386-xl-multivcpu 5 xen-boot fail in 9079 pass in 9081 test-i386-i386-xl 5 xen-boot fail in 9079 pass in 9081 test-amd64-amd64-xl-sedf 5 xen-boot fail in 9079 pass in 9081 test-i386-i386-pair 7 xen-boot/src_host fail in 9079 pass in 9081 test-i386-i386-pair 8 xen-boot/dst_host fail in 9079 pass in 9081 test-amd64-i386-xl-win-vcpus1 5 xen-boot fail in 9079 pass in 9081 test-amd64-i386-xl-credit2 5 xen-boot fail in 9067 pass in 9081 test-amd64-amd64-win 5 xen-boot fail in 9071 pass in 9081 Tests which did not succeed, but are not blocking, including regressions (tests previously passed) regarded as allowable: test-amd64-amd64-xl-pcipt-intel 9 guest-start fail never pass test-amd64-i386-rhel6hvm-intel 9 guest-start.2 fail never pass test-amd64-i386-xl-win-vcpus1 13 guest-stop fail never pass test-amd64-amd64-win 16 leak-check/check fail never pass test-amd64-i386-win-vcpus1 16 leak-check/check fail in 9079 never pass test-amd64-i386-win 16 leak-check/check fail in 9079 never pass test-amd64-amd64-xl-win 13 guest-stop fail in 9079 never pass test-i386-i386-xl-win 13 guest-stop fail in 9067 never pass test-i386-i386-win 16 leak-check/check fail in 9067 never pass version targeted for testing: xen cc339ab1d917 baseline version: xen a422e2a4451e ------------------------------------------------------------ People who touched revisions under test: Andreas Herrmann <herrmann.der.user@googlemail.com> Ian Campbell <ian.campbell@citrix.com> Ian Jackson <ian.jackson@eu.citrix.com> Jan Beulich <jbeulich@suse.com> Lasse Collin <lasse.collin@tukaani.org> Olaf Hering <olaf@aepfle.de> Thomas Renninger <trenn@suse.de> ------------------------------------------------------------ jobs: build-amd64 pass build-i386 pass build-amd64-oldkern pass build-i386-oldkern pass build-amd64-pvops pass build-i386-pvops pass test-amd64-amd64-xl fail test-amd64-i386-xl fail test-i386-i386-xl pass test-amd64-i386-rhel6hvm-amd fail test-amd64-i386-xl-credit2 pass test-amd64-amd64-xl-pcipt-intel fail test-amd64-i386-rhel6hvm-intel fail test-amd64-i386-xl-multivcpu pass test-amd64-amd64-pair pass test-amd64-i386-pair fail test-i386-i386-pair pass test-amd64-amd64-pv pass test-amd64-i386-pv pass test-i386-i386-pv fail test-amd64-amd64-xl-sedf fail test-amd64-i386-win-vcpus1 fail test-amd64-i386-xl-win-vcpus1 fail test-amd64-amd64-win fail test-amd64-i386-win fail test-i386-i386-win fail test-amd64-amd64-xl-win fail test-i386-i386-xl-win fail ------------------------------------------------------------ sg-report-flight on woking.cam.xci-test.com logs: /home/xc_osstest/logs images: /home/xc_osstest/images Logs, config files, etc. are available at http://www.chiark.greenend.org.uk/~xensrcts/logs Test harness code can be found at http://xenbits.xensource.com/gitweb?p=osstest.git;a=summary Not pushing. ------------------------------------------------------------ changeset: 23872:cc339ab1d917 tag: tip user: Ian Campbell <ian.campbell@citrix.com> date: Thu Sep 22 18:37:06 2011 +0100 tools: fix install of lomount $(BIN) went away in 23124:e3d4c34b14a3. Also there are no *.so, *.a or *.rpm built in here Signed-off-by: Ian Campbell <ian.campbell@citrix.com> changeset: 23871:503ee256fecf user: Jan Beulich <jbeulich@suse.com> date: Thu Sep 22 18:35:30 2011 +0100 x86: ucode-amd: Don't warn when no ucode is available for a CPU revision This patch originally comes from the Linus mainline kernel (2.6.33), find below the patch details: From: Andreas Herrmann <herrmann.der.user@googlemail.com> There is no point in warning when there is no ucode available for a specific CPU revision. Currently the container-file, which provides the AMD ucode patches for OS load, contains only a few ucode patches. It's already clearly indicated by the printed patch_level whenever new ucode was available and an update happened. So the warning message is of no help but rather annoying on systems with many CPUs. Signed-off-by: Thomas Renninger <trenn@suse.de> Signed-off-by: Jan Beulich <jbeulich@suse.com> changeset: 23870:5c97b02f48fc user: Jan Beulich <jbeulich@suse.com> date: Thu Sep 22 18:34:27 2011 +0100 XZ: Fix incorrect XZ_BUF_ERROR From: Lasse Collin <lasse.collin@tukaani.org> xz_dec_run() could incorrectly return XZ_BUF_ERROR if all of the following was true: - The caller knows how many bytes of output to expect and only provides that much output space. - When the last output bytes are decoded, the caller-provided input buffer ends right before the LZMA2 end of payload marker. So LZMA2 won't provide more output anymore, but it won't know it yet and thus won't return XZ_STREAM_END yet. - A BCJ filter is in use and it hasn't left any unfiltered bytes in the temp buffer. This can happen with any BCJ filter, but in practice it's more likely with filters other than the x86 BCJ. This fixes <https://bugzilla.redhat.com/show_bug.cgi?id=3D735408> where Squashfs thinks that a valid file system is corrupt. This also fixes a similar bug in single-call mode where the uncompressed size of a block using BCJ + LZMA2 was 0 bytes and caller provided no output space. Many empty .xz files don't contain any blocks and thus don't trigger this bug. This also tweaks a closely related detail: xz_dec_bcj_run() could call xz_dec_lzma2_run() to decode into temp buffer when it was known to be useless. This was harmless although it wasted a minuscule number of CPU cycles. Signed-off-by: Lasse Collin <lasse.collin@tukaani.org> Signed-off-by: Jan Beulich <jbeulich@suse.com> changeset: 23869:db1ea4b127cd user: Jan Beulich <jbeulich@suse.com> date: Thu Sep 22 18:33:48 2011 +0100 XZ decompressor: Fix decoding of empty LZMA2 streams From: Lasse Collin <lasse.collin@tukaani.org> The old code considered valid empty LZMA2 streams to be corrupt. Note that a typical empty .xz file has no LZMA2 data at all, and thus most .xz files having no uncompressed data are handled correctly even without this fix. Signed-off-by: Lasse Collin <lasse.collin@tukaani.org> Signed-off-by: Jan Beulich <jbeulich@suse.com> changeset: 23868:28147fd781af user: Jan Beulich <jbeulich@suse.com> date: Thu Sep 22 18:32:34 2011 +0100 VT-d: fix off-by-one error in RMRR validation (base_addr,end_addr) is an inclusive range, and hence there shouldn't be a subtraction of 1 in the second invocation of page_is_ram_type(). For RMRRs covering a single page that actually resulted in the immediately preceding page to get checked (which could have resulted in a false warning). Signed-off-by: Jan Beulich <jbeulich@suse.com> changeset: 23867:571b6e90dfb4 user: Jan Beulich <jbeulich@suse.com> date: Thu Sep 22 18:31:44 2011 +0100 VT-d: eliminate a mis-use of pcidevs_lock dma_pte_clear_one() shouldn't acquire this global lock for the purpose of processing a per-domain list. Furthermore the function a few lines earlier has a comment stating that acquiring pcidevs_lock isn't necessary here (whether that's really correct is another question). Use the domain's mappin_lock instead to protect the mapped_rmrrs list. Fold domain_rmrr_mapped() into its sole caller so that the otherwise implicit dependency on pcidevs_lock there becomes more obvious (see the comment there). Signed-off-by: Jan Beulich <jbeulich@suse.com> changeset: 23866:47ec1d405af9 user: Jan Beulich <jbeulich@suse.com> date: Thu Sep 22 18:31:02 2011 +0100 x86: IO-APIC code has no dependency on PCI The IRQ handling code requires pcidevs_lock to be held only for MSI interrupts. As the handling of which was now fully moved into msi.c (i.e. while applying fine without, the patch needs to be applied after the one titled "x86: split MSI IRQ chip"), io_apic.c now also doesn't need to include PCI headers anymore. Signed-off-by: Jan Beulich <jbeulich@suse.com> changeset: 23865:d6e01c7853cf user: Jan Beulich <jbeulich@suse.com> date: Thu Sep 22 18:29:19 2011 +0100 PCI multi-seg: config space accessor adjustments Signed-off-by: Jan Beulich <jbeulich@suse.com> changeset: 23864:314b147d524d user: Jan Beulich <jbeulich@suse.com> date: Thu Sep 22 18:28:38 2011 +0100 PCI multi-seg: Pass-through adjustments Signed-off-by: Jan Beulich <jbeulich@suse.com> changeset: 23863:9e0259239822 user: Jan Beulich <jbeulich@suse.com> date: Thu Sep 22 18:28:03 2011 +0100 PCI multi-seg: AMD-IOMMU specific adjustments There are two places here where it is entirely unclear to me where the necessary PCI segment number should be taken from (as IVMD descriptors don't have such, only IVHD ones do). AMD confirmed that for the time being it is acceptable to imply that only segment 0 exists. Signed-off-by: Jan Beulich <jbeulich@suse.com> changeset: 23862:85418e168527 user: Jan Beulich <jbeulich@suse.com> date: Thu Sep 22 18:27:26 2011 +0100 PCI multi-seg: VT-d specific adjustments Signed-off-by: Jan Beulich <jbeulich@suse.com> changeset: 23861:ec7c81fbe0de user: Jan Beulich <jbeulich@suse.com> date: Thu Sep 22 18:26:54 2011 +0100 PCI multi-seg: adjust domctl interface Again, a couple of directly related functions at once get adjusted to account for the segment number. Signed-off-by: Jan Beulich <jbeulich@suse.com> changeset: 23860:a422e2a4451e user: Jan Beulich <jbeulich@suse.com> date: Sun Sep 18 00:26:52 2011 +0100 x86: split MSI IRQ chip With the .end() accessor having become optional and noting that several of the accessors' behavior really depends on the result of msi_maskable_irq(), the splits the MSI IRQ chip type into two - one for the maskable ones, and the other for the (MSI only) non-maskable ones. At once the implementation of those methods gets moved from io_apic.c to msi.c. Signed-off-by: Jan Beulich <jbeulich@suse.com> ======================================== commit cd776ee9408ff127f934a707c1a339ee600bc127 Author: Ian Jackson <ian.jackson@eu.citrix.com> Date: Tue Jun 28 13:50:53 2011 +0100 qemu-char.c: fix incorrect CONFIG_STUBDOM handling qemu-char.c:1123:7: warning: "CONFIG_STUBDOM" is not defined [-Wundef] Signed-off-by: Olaf Hering <olaf@aepfle.de> Acked-by: Ian Jackson <ian.jackson@eu.citrix.com> _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel From xen-devel-bounces@lists.xensource.com Sun Sep 25 17:12:39 2011 Return-path: <xen-devel-bounces@lists.xensource.com> Envelope-to: www-data@lists.xensource.com Delivery-date: Sun, 25 Sep 2011 17:12:39 -0700 Received: from localhost ([127.0.0.1] helo=lists.colo.xensource.com) by lists.xensource.com with esmtp (Exim 4.43) id 1R7yoJ-0004cL-NJ; Sun, 25 Sep 2011 17:12:39 -0700 Received: from mail182.messagelabs.com ([85.158.139.83]) by lists.xensource.com with esmtp (Exim 4.43) id 1R7ynJ-0004Pf-3i for xen-devel@lists.xensource.com; Sun, 25 Sep 2011 17:11:37 -0700 X-Env-Sender: todd.deshane.xen@gmail.com X-Msg-Ref: server-10.tower-182.messagelabs.com!1316995892!19668881!1 X-Originating-IP: [209.85.213.43] X-StarScan-Version: 6.4.1; banners=-,-,- X-VirusChecked: Checked Received: (qmail 13241 invoked from network); 26 Sep 2011 00:11:33 -0000 Received: from mail-yw0-f43.google.com (HELO mail-yw0-f43.google.com) (209.85.213.43) by server-10.tower-182.messagelabs.com with RC4-SHA encrypted SMTP; 26 Sep 2011 00:11:33 -0000 Received: by ywm21 with SMTP id 21so6102777ywm.30 for <xen-devel@lists.xensource.com>; Sun, 25 Sep 2011 17:11:32 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:sender:in-reply-to:references:from:date :x-google-sender-auth:message-id:subject:to:cc:content-type; bh=V6dr1Y6mADIx4LwYoKaZdLaN/O4GPtQVG+wiNG1Sp9w=; b=oQx25Tb69BxmAFo9j7e96+68biQ33qezBc0NFLQN9mpCWuiBS9Ck0RRC+nbgmkJJfe 6pY1t7f14lh4eInWcJs0niNRqSvkXNP3xtb62Ye++WxI7K3AAxRvV4HcEBU03bK1A8Mb 8eZJYMZMrji41pLODN7+iNAx4bnW0DjXFUUso= Received: by 10.42.244.197 with SMTP id lr5mr6599990icb.24.1316995892141; Sun, 25 Sep 2011 17:11:32 -0700 (PDT) MIME-Version: 1.0 Received: by 10.231.206.136 with HTTP; Sun, 25 Sep 2011 17:11:12 -0700 (PDT) In-Reply-To: <CAKnNFz_yraTP0-BrGQrC5BwzKKUmFVUqjDqbMhNu6-Nq6dVptQ@mail.gmail.com> References: <CAKnNFz_yraTP0-BrGQrC5BwzKKUmFVUqjDqbMhNu6-Nq6dVptQ@mail.gmail.com> From: Todd Deshane <todd.deshane@xen.org> Date: Sun, 25 Sep 2011 20:11:12 -0400 X-Google-Sender-Auth: UAYUgcikjmQ9ROBoGkKEUc1C57E Message-ID: <CAMrPLWJbK20VgzphhVtm98N6o-y3qyeP7+BhPJ-0O3NySrjHjg@mail.gmail.com> Subject: Re: [Xen-devel] PVUSB not working on squeeze To: chris <tknchris@gmail.com> Content-Type: text/plain; charset=ISO-8859-1 Cc: Xen-Devel List <xen-devel@lists.xensource.com> X-BeenThere: xen-devel@lists.xensource.com X-Mailman-Version: 2.1.5 Precedence: list List-Id: Xen developer discussion <xen-devel.lists.xensource.com> List-Unsubscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe> List-Post: <mailto:xen-devel@lists.xensource.com> List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help> List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=subscribe> Sender: xen-devel-bounces@lists.xensource.com Errors-To: xen-devel-bounces@lists.xensource.com On Sun, Sep 25, 2011 at 6:06 PM, chris <tknchris@gmail.com> wrote: > One thing I noticed is that I don't see any kind of usbfront module or any > usb frontend in lsmod. Is there some backend/frontend lacking in the squeeze > kernel? There is a "PVUSB support in Xen 4.0 and newer versions" on this wiki page: http://wiki.xensource.com/xenwiki/XenUSBPassthrough Hope that helps. Thanks, Todd -- Todd Deshane http://www.linkedin.com/in/deshantm http://www.xen.org/products/cloudxen.html http://runningxen.com/ _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel From xen-devel-bounces@lists.xensource.com Sun Sep 25 17:16:30 2011 Return-path: <xen-devel-bounces@lists.xensource.com> Envelope-to: www-data@lists.xensource.com Delivery-date: Sun, 25 Sep 2011 17:16:30 -0700 Received: from localhost ([127.0.0.1] helo=lists.colo.xensource.com) by lists.xensource.com with esmtp (Exim 4.43) id 1R7ys2-00052e-JX; Sun, 25 Sep 2011 17:16:30 -0700 Received: from mail216.messagelabs.com ([85.158.143.99]) by lists.xensource.com with esmtp (Exim 4.43) id 1R7yrP-0004qE-R2 for xen-devel@lists.xensource.com; Sun, 25 Sep 2011 17:15:52 -0700 X-Env-Sender: tknchris@gmail.com X-Msg-Ref: server-13.tower-216.messagelabs.com!1316996147!19556500!1 X-Originating-IP: [209.85.160.171] X-StarScan-Version: 6.4.1; banners=-,-,- X-VirusChecked: Checked Received: (qmail 8740 invoked from network); 26 Sep 2011 00:15:48 -0000 Received: from mail-gy0-f171.google.com (HELO mail-gy0-f171.google.com) (209.85.160.171) by server-13.tower-216.messagelabs.com with RC4-SHA encrypted SMTP; 26 Sep 2011 00:15:48 -0000 Received: by gyh3 with SMTP id 3so6010338gyh.30 for <xen-devel@lists.xensource.com>; Sun, 25 Sep 2011 17:15:47 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=5l8CXzrrEUR5T23cOd8GCwrzLseEKEx7zoktx/zzXJ0=; b=nyoG+ddqhMZ3gPhvTqOlP4ACfNeTsfsBsl3kGBkn+Z0E7t5M9XVqo2XrmKX5MFNwpI lIrNjqq/Qk7pNryEebf15FhauSg7Cu4fckLO9+Ze3SQvvydUr8tMyE8gGr1USKXqhReS a5iDJ6lzgj1jQyWzwqrIQvBTddAyvwsB4UQ9w= MIME-Version: 1.0 Received: by 10.42.150.4 with SMTP id y4mr5655404icv.196.1316996103955; Sun, 25 Sep 2011 17:15:03 -0700 (PDT) Received: by 10.42.177.137 with HTTP; Sun, 25 Sep 2011 17:15:03 -0700 (PDT) In-Reply-To: <CAMrPLWJbK20VgzphhVtm98N6o-y3qyeP7+BhPJ-0O3NySrjHjg@mail.gmail.com> References: <CAKnNFz_yraTP0-BrGQrC5BwzKKUmFVUqjDqbMhNu6-Nq6dVptQ@mail.gmail.com> <CAMrPLWJbK20VgzphhVtm98N6o-y3qyeP7+BhPJ-0O3NySrjHjg@mail.gmail.com> Date: Sun, 25 Sep 2011 20:15:03 -0400 Message-ID: <CAKnNFz8m5RdpFcnvs7=Nx=dEp=t9_1RTZ7wwRjDCa0mhxque7w@mail.gmail.com> Subject: Re: [Xen-devel] PVUSB not working on squeeze From: chris <tknchris@gmail.com> To: Todd Deshane <todd.deshane@xen.org> Cc: Xen-Devel List <xen-devel@lists.xensource.com> X-BeenThere: xen-devel@lists.xensource.com X-Mailman-Version: 2.1.5 Precedence: list List-Id: Xen developer discussion <xen-devel.lists.xensource.com> List-Unsubscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe> List-Post: <mailto:xen-devel@lists.xensource.com> List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help> List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=subscribe> Content-Type: multipart/mixed; boundary="===============1917976934==" Sender: xen-devel-bounces@lists.xensource.com Errors-To: xen-devel-bounces@lists.xensource.com --===============1917976934== Content-Type: multipart/alternative; boundary=90e6ba6e8242f2648c04adcd0cbb --90e6ba6e8242f2648c04adcd0cbb Content-Type: text/plain; charset=ISO-8859-1 >From what I read on http://wiki.xensource.com/xenwiki/XenDom0Kernels , pv_ops currently doesnt have the PVUSB support without patching. So therein lies my answer ;( - chris On Sun, Sep 25, 2011 at 8:11 PM, Todd Deshane <todd.deshane@xen.org> wrote: > On Sun, Sep 25, 2011 at 6:06 PM, chris <tknchris@gmail.com> wrote: > > One thing I noticed is that I don't see any kind of usbfront module or > any > > usb frontend in lsmod. Is there some backend/frontend lacking in the > squeeze > > kernel? > > There is a "PVUSB support in Xen 4.0 and newer versions" on this wiki page: > > http://wiki.xensource.com/xenwiki/XenUSBPassthrough > > Hope that helps. > > Thanks, > Todd > > -- > Todd Deshane > http://www.linkedin.com/in/deshantm > http://www.xen.org/products/cloudxen.html > http://runningxen.com/ > --90e6ba6e8242f2648c04adcd0cbb Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable >From what I read on=A0<a href=3D"http://wiki.xensource.com/xenwiki/XenDom0K= ernels">http://wiki.xensource.com/xenwiki/XenDom0Kernels</a>=A0, pv_ops cur= rently doesnt have the PVUSB support without patching. So therein lies my a= nswer ;(<div> <br></div><div>- chris<br><br><div class=3D"gmail_quote">On Sun, Sep 25, 20= 11 at 8:11 PM, Todd Deshane <span dir=3D"ltr"><<a href=3D"mailto:todd.de= shane@xen.org">todd.deshane@xen.org</a>></span> wrote:<br><blockquote cl= ass=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;p= adding-left:1ex;"> <div class=3D"im">On Sun, Sep 25, 2011 at 6:06 PM, chris <<a href=3D"mai= lto:tknchris@gmail.com">tknchris@gmail.com</a>> wrote:<br> > One thing I noticed is that I don't see any kind of usbfront modul= e or any<br> > usb frontend in lsmod. Is there some backend/frontend lacking in the s= queeze<br> > kernel?<br> <br> </div>There is a "PVUSB support in Xen 4.0 and newer versions" on= this wiki page:<br> <br> <a href=3D"http://wiki.xensource.com/xenwiki/XenUSBPassthrough" target=3D"_= blank">http://wiki.xensource.com/xenwiki/XenUSBPassthrough</a><br> <br> Hope that helps.<br> <br> Thanks,<br> Todd<br> <font color=3D"#888888"><br> --<br> Todd Deshane<br> <a href=3D"http://www.linkedin.com/in/deshantm" target=3D"_blank">http://ww= w.linkedin.com/in/deshantm</a><br> <a href=3D"http://www.xen.org/products/cloudxen.html" target=3D"_blank">htt= p://www.xen.org/products/cloudxen.html</a><br> <a href=3D"http://runningxen.com/" target=3D"_blank">http://runningxen.com/= </a><br> </font></blockquote></div><br></div> --90e6ba6e8242f2648c04adcd0cbb-- --===============1917976934== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel --===============1917976934==-- From xen-devel-bounces@lists.xensource.com Sun Sep 25 17:47:35 2011 Return-path: <xen-devel-bounces@lists.xensource.com> Envelope-to: www-data@lists.xensource.com Delivery-date: Sun, 25 Sep 2011 17:47:35 -0700 Received: from localhost ([127.0.0.1] helo=lists.colo.xensource.com) by lists.xensource.com with esmtp (Exim 4.43) id 1R7zM7-0006qh-GE; Sun, 25 Sep 2011 17:47:35 -0700 Received: from mail21.messagelabs.com ([85.158.143.35]) by lists.xensource.com with esmtp (Exim 4.43) id 1R7zLI-0006eF-9A for xen-devel@lists.xensource.com; Sun, 25 Sep 2011 17:46:45 -0700 X-Env-Sender: Ian.Jackson@eu.citrix.com X-Msg-Ref: server-11.tower-21.messagelabs.com!1316997983!43924155!1 X-Originating-IP: [62.200.22.115] X-StarScan-Version: 6.4.1; banners=-,-,- X-VirusChecked: Checked Received: (qmail 9476 invoked from network); 26 Sep 2011 00:46:23 -0000 Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115) by server-11.tower-21.messagelabs.com with RC4-SHA encrypted SMTP; 26 Sep 2011 00:46:23 -0000 X-IronPort-AV: E=Sophos;i="4.68,441,1312156800"; d="scan'208";a="8049553" Received: from lonpmailmx01.citrite.net ([10.30.203.162]) by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5; 26 Sep 2011 00:46:40 +0000 Received: from woking.xci-test.com (10.80.248.135) by smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id 8.3.137.0; Mon, 26 Sep 2011 01:46:40 +0100 Received: from osstest by woking.xci-test.com with local (Exim 4.69) (envelope-from <ian.jackson@eu.citrix.com>) id 1R7zLE-0003vs-AH; Mon, 26 Sep 2011 01:46:40 +0100 To: xen-devel@lists.xensource.com Message-ID: <osstest-9082-mainreport@xen.org> From: xen.org <ian.jackson@eu.citrix.com> Date: Mon, 26 Sep 2011 01:46:40 +0100 MIME-Version: 1.0 Content-Type: text/plain Cc: ian.jackson@eu.citrix.com Subject: [Xen-devel] [linux test] 9082: tolerable FAIL X-BeenThere: xen-devel@lists.xensource.com X-Mailman-Version: 2.1.5 Precedence: list List-Id: Xen developer discussion <xen-devel.lists.xensource.com> List-Unsubscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe> List-Post: <mailto:xen-devel@lists.xensource.com> List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help> List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=subscribe> Sender: xen-devel-bounces@lists.xensource.com Errors-To: xen-devel-bounces@lists.xensource.com flight 9082 linux real [real] http://www.chiark.greenend.org.uk/~xensrcts/logs/9082/ Failures :-/ but no regressions. Tests which did not succeed, but are not blocking, including regressions (tests previously passed) regarded as allowable: test-amd64-amd64-xl-pcipt-intel 9 guest-start fail never pass test-amd64-i386-rhel6hvm-amd 9 guest-start.2 fail never pass test-amd64-i386-rhel6hvm-intel 9 guest-start.2 fail never pass test-amd64-i386-win-vcpus1 16 leak-check/check fail never pass test-amd64-i386-xl-win-vcpus1 13 guest-stop fail never pass test-amd64-amd64-win 16 leak-check/check fail never pass test-amd64-amd64-xl-win 13 guest-stop fail never pass test-i386-i386-win 16 leak-check/check fail never pass test-i386-i386-xl-win 13 guest-stop fail never pass test-amd64-i386-win 16 leak-check/check fail never pass version targeted for testing: linux 6bec8b4a4c14095d0b7ce424db9d583c3decae6c baseline version: linux 1c3f03ccc5258887f5f2cafc0836a865834f9205 ------------------------------------------------------------ People who touched revisions under test: Jeremy Fitzhardinge <jeremy.fitzhardinge@citrix.com> ------------------------------------------------------------ jobs: build-amd64 pass build-i386 pass build-amd64-pvops pass build-i386-pvops pass test-amd64-amd64-xl pass test-amd64-i386-xl pass test-i386-i386-xl pass test-amd64-i386-rhel6hvm-amd fail test-amd64-i386-xl-credit2 pass test-amd64-amd64-xl-pcipt-intel fail test-amd64-i386-rhel6hvm-intel fail test-amd64-i386-xl-multivcpu pass test-amd64-amd64-pair pass test-amd64-i386-pair pass test-i386-i386-pair pass test-amd64-amd64-pv pass test-amd64-i386-pv pass test-i386-i386-pv pass test-amd64-amd64-xl-sedf pass test-amd64-i386-win-vcpus1 fail test-amd64-i386-xl-win-vcpus1 fail test-amd64-amd64-win fail test-amd64-i386-win fail test-i386-i386-win fail test-amd64-amd64-xl-win fail test-i386-i386-xl-win fail ------------------------------------------------------------ sg-report-flight on woking.cam.xci-test.com logs: /home/xc_osstest/logs images: /home/xc_osstest/images Logs, config files, etc. are available at http://www.chiark.greenend.org.uk/~xensrcts/logs Test harness code can be found at http://xenbits.xensource.com/gitweb?p=osstest.git;a=summary Pushing revision : + branch=linux + revision=6bec8b4a4c14095d0b7ce424db9d583c3decae6c + . cri-lock-repos ++ . cri-common +++ umask 002 +++ getconfig Repos +++ perl -e ' use Osstest; readconfigonly(); print $c{Repos} or die $!; ' ++ repos=/export/home/osstest/repos ++ repos_lock=/export/home/osstest/repos/lock ++ '[' x '!=' x/export/home/osstest/repos/lock ']' ++ OSSTEST_REPOS_LOCK_LOCKED=/export/home/osstest/repos/lock ++ exec with-lock-ex -w /export/home/osstest/repos/lock ./ap-push linux 6bec8b4a4c14095d0b7ce424db9d583c3decae6c + branch=linux + revision=6bec8b4a4c14095d0b7ce424db9d583c3decae6c + . cri-lock-repos ++ . cri-common +++ umask 002 +++ getconfig Repos +++ perl -e ' use Osstest; readconfigonly(); print $c{Repos} or die $!; ' ++ repos=/export/home/osstest/repos ++ repos_lock=/export/home/osstest/repos/lock ++ '[' x/export/home/osstest/repos/lock '!=' x/export/home/osstest/repos/lock ']' + : xen@xenbits.xensource.com + : xen@xenbits.xensource.com:git/linux-pvops + : master + : tested/2.6.39.x + case "$branch" in + cd /export/home/osstest/repos/xen ./ap-push: line 20: cd: /export/home/osstest/repos/xen: No such file or directory ------------------------------------------------------------ commit 6bec8b4a4c14095d0b7ce424db9d583c3decae6c Author: Jeremy Fitzhardinge <jeremy.fitzhardinge@citrix.com> Date: Fri Sep 2 12:23:22 2011 -0700 Revert "xen/apic: Provide an 'apic_xen' to set the override the apic->[read|write] for all cases." This reverts commit c3dd7941354fa96a71f2613e2c7a1b215fa175dc. It prevents the kernel from booting natively on hardware. Conflicts: arch/x86/xen/enlighten.c Signed-off-by: Jeremy Fitzhardinge <jeremy.fitzhardinge@citrix.com> _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel From xen-devel-bounces@lists.xensource.com Sun Sep 25 20:32:49 2011 Return-path: <xen-devel-bounces@lists.xensource.com> Envelope-to: www-data@lists.xensource.com Delivery-date: Sun, 25 Sep 2011 20:32:49 -0700 Received: from localhost ([127.0.0.1] helo=lists.colo.xensource.com) by lists.xensource.com with esmtp (Exim 4.43) id 1R81w1-0002DF-KC; Sun, 25 Sep 2011 20:32:49 -0700 Received: from mail27.messagelabs.com ([193.109.254.147]) by lists.xensource.com with esmtp (Exim 4.43) id 1R81v4-0001vZ-Ks for xen-devel@lists.xensource.com; Sun, 25 Sep 2011 20:31:52 -0700 X-Env-Sender: Ian.Jackson@eu.citrix.com X-Msg-Ref: server-7.tower-27.messagelabs.com!1317007883!50100593!1 X-Originating-IP: [62.200.22.115] X-StarScan-Version: 6.4.1; banners=-,-,- X-VirusChecked: Checked Received: (qmail 28217 invoked from network); 26 Sep 2011 03:31:23 -0000 Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115) by server-7.tower-27.messagelabs.com with RC4-SHA encrypted SMTP; 26 Sep 2011 03:31:23 -0000 X-IronPort-AV: E=Sophos;i="4.68,441,1312156800"; d="scan'208";a="8049975" Received: from lonpmailmx01.citrite.net ([10.30.203.162]) by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5; 26 Sep 2011 03:31:47 +0000 Received: from woking.xci-test.com (10.80.248.135) by smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id 8.3.137.0; Mon, 26 Sep 2011 04:31:47 +0100 Received: from osstest by woking.xci-test.com with local (Exim 4.69) (envelope-from <ian.jackson@eu.citrix.com>) id 1R81v0-0007xO-Na; Mon, 26 Sep 2011 04:31:46 +0100 To: xen-devel@lists.xensource.com Message-ID: <osstest-9083-mainreport@xen.org> From: xen.org <ian.jackson@eu.citrix.com> Date: Mon, 26 Sep 2011 04:31:46 +0100 MIME-Version: 1.0 Content-Type: text/plain Cc: ian.jackson@eu.citrix.com Subject: [Xen-devel] [xen-unstable test] 9083: regressions - FAIL X-BeenThere: xen-devel@lists.xensource.com X-Mailman-Version: 2.1.5 Precedence: list List-Id: Xen developer discussion <xen-devel.lists.xensource.com> List-Unsubscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe> List-Post: <mailto:xen-devel@lists.xensource.com> List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help> List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=subscribe> Sender: xen-devel-bounces@lists.xensource.com Errors-To: xen-devel-bounces@lists.xensource.com flight 9083 xen-unstable real [real] http://www.chiark.greenend.org.uk/~xensrcts/logs/9083/ Regressions :-( Tests which did not succeed and are blocking: test-amd64-i386-rhel6hvm-amd 5 xen-boot fail REGR. vs. 8995 Tests which are failing intermittently (not blocking): test-amd64-i386-xl-multivcpu 5 xen-boot fail pass in 9081 test-amd64-i386-xl-credit2 5 xen-boot fail pass in 9081 test-i386-i386-xl 5 xen-boot fail pass in 9081 test-amd64-i386-pair 7 xen-boot/src_host fail pass in 9079 test-amd64-i386-pair 8 xen-boot/dst_host fail pass in 9079 test-amd64-i386-xl-win-vcpus1 5 xen-boot fail pass in 9081 test-amd64-i386-win-vcpus1 5 xen-boot fail pass in 9079 test-amd64-amd64-win 5 xen-boot fail pass in 9081 test-amd64-i386-win 5 xen-boot fail pass in 9079 test-amd64-amd64-xl-win 5 xen-boot fail pass in 9079 test-amd64-amd64-xl 5 xen-boot fail in 9081 pass in 9083 test-i386-i386-pv 5 xen-boot fail in 9081 pass in 9083 test-amd64-i386-xl 5 xen-boot fail in 9081 pass in 9083 test-amd64-amd64-xl-sedf 7 debian-install fail in 9081 pass in 9083 test-i386-i386-xl-win 5 xen-boot fail in 9081 pass in 9083 test-i386-i386-win 5 xen-boot fail in 9081 pass in 9083 test-amd64-i386-pv 5 xen-boot fail in 9079 pass in 9083 test-amd64-amd64-pv 5 xen-boot fail in 9079 pass in 9083 test-amd64-amd64-xl-sedf 5 xen-boot fail in 9079 pass in 9083 test-i386-i386-pair 7 xen-boot/src_host fail in 9079 pass in 9083 test-i386-i386-pair 8 xen-boot/dst_host fail in 9079 pass in 9083 Tests which did not succeed, but are not blocking, including regressions (tests previously passed) regarded as allowable: test-amd64-amd64-xl-pcipt-intel 9 guest-start fail never pass test-amd64-i386-rhel6hvm-intel 9 guest-start.2 fail never pass test-i386-i386-xl-win 13 guest-stop fail never pass test-i386-i386-win 16 leak-check/check fail never pass test-amd64-i386-xl-win-vcpus1 13 guest-stop fail in 9081 never pass test-amd64-amd64-win 16 leak-check/check fail in 9081 never pass test-amd64-i386-win-vcpus1 16 leak-check/check fail in 9079 never pass test-amd64-i386-win 16 leak-check/check fail in 9079 never pass test-amd64-amd64-xl-win 13 guest-stop fail in 9079 never pass version targeted for testing: xen cc339ab1d917 baseline version: xen a422e2a4451e ------------------------------------------------------------ People who touched revisions under test: Andreas Herrmann <herrmann.der.user@googlemail.com> Ian Campbell <ian.campbell@citrix.com> Ian Jackson <ian.jackson@eu.citrix.com> Jan Beulich <jbeulich@suse.com> Lasse Collin <lasse.collin@tukaani.org> Olaf Hering <olaf@aepfle.de> Thomas Renninger <trenn@suse.de> ------------------------------------------------------------ jobs: build-amd64 pass build-i386 pass build-amd64-oldkern pass build-i386-oldkern pass build-amd64-pvops pass build-i386-pvops pass test-amd64-amd64-xl pass test-amd64-i386-xl pass test-i386-i386-xl fail test-amd64-i386-rhel6hvm-amd fail test-amd64-i386-xl-credit2 fail test-amd64-amd64-xl-pcipt-intel fail test-amd64-i386-rhel6hvm-intel fail test-amd64-i386-xl-multivcpu fail test-amd64-amd64-pair pass test-amd64-i386-pair fail test-i386-i386-pair pass test-amd64-amd64-pv pass test-amd64-i386-pv pass test-i386-i386-pv pass test-amd64-amd64-xl-sedf pass test-amd64-i386-win-vcpus1 fail test-amd64-i386-xl-win-vcpus1 fail test-amd64-amd64-win fail test-amd64-i386-win fail test-i386-i386-win fail test-amd64-amd64-xl-win fail test-i386-i386-xl-win fail ------------------------------------------------------------ sg-report-flight on woking.cam.xci-test.com logs: /home/xc_osstest/logs images: /home/xc_osstest/images Logs, config files, etc. are available at http://www.chiark.greenend.org.uk/~xensrcts/logs Test harness code can be found at http://xenbits.xensource.com/gitweb?p=osstest.git;a=summary Not pushing. ------------------------------------------------------------ changeset: 23872:cc339ab1d917 tag: tip user: Ian Campbell <ian.campbell@citrix.com> date: Thu Sep 22 18:37:06 2011 +0100 tools: fix install of lomount $(BIN) went away in 23124:e3d4c34b14a3. Also there are no *.so, *.a or *.rpm built in here Signed-off-by: Ian Campbell <ian.campbell@citrix.com> changeset: 23871:503ee256fecf user: Jan Beulich <jbeulich@suse.com> date: Thu Sep 22 18:35:30 2011 +0100 x86: ucode-amd: Don't warn when no ucode is available for a CPU revision This patch originally comes from the Linus mainline kernel (2.6.33), find below the patch details: From: Andreas Herrmann <herrmann.der.user@googlemail.com> There is no point in warning when there is no ucode available for a specific CPU revision. Currently the container-file, which provides the AMD ucode patches for OS load, contains only a few ucode patches. It's already clearly indicated by the printed patch_level whenever new ucode was available and an update happened. So the warning message is of no help but rather annoying on systems with many CPUs. Signed-off-by: Thomas Renninger <trenn@suse.de> Signed-off-by: Jan Beulich <jbeulich@suse.com> changeset: 23870:5c97b02f48fc user: Jan Beulich <jbeulich@suse.com> date: Thu Sep 22 18:34:27 2011 +0100 XZ: Fix incorrect XZ_BUF_ERROR From: Lasse Collin <lasse.collin@tukaani.org> xz_dec_run() could incorrectly return XZ_BUF_ERROR if all of the following was true: - The caller knows how many bytes of output to expect and only provides that much output space. - When the last output bytes are decoded, the caller-provided input buffer ends right before the LZMA2 end of payload marker. So LZMA2 won't provide more output anymore, but it won't know it yet and thus won't return XZ_STREAM_END yet. - A BCJ filter is in use and it hasn't left any unfiltered bytes in the temp buffer. This can happen with any BCJ filter, but in practice it's more likely with filters other than the x86 BCJ. This fixes <https://bugzilla.redhat.com/show_bug.cgi?id=3D735408> where Squashfs thinks that a valid file system is corrupt. This also fixes a similar bug in single-call mode where the uncompressed size of a block using BCJ + LZMA2 was 0 bytes and caller provided no output space. Many empty .xz files don't contain any blocks and thus don't trigger this bug. This also tweaks a closely related detail: xz_dec_bcj_run() could call xz_dec_lzma2_run() to decode into temp buffer when it was known to be useless. This was harmless although it wasted a minuscule number of CPU cycles. Signed-off-by: Lasse Collin <lasse.collin@tukaani.org> Signed-off-by: Jan Beulich <jbeulich@suse.com> changeset: 23869:db1ea4b127cd user: Jan Beulich <jbeulich@suse.com> date: Thu Sep 22 18:33:48 2011 +0100 XZ decompressor: Fix decoding of empty LZMA2 streams From: Lasse Collin <lasse.collin@tukaani.org> The old code considered valid empty LZMA2 streams to be corrupt. Note that a typical empty .xz file has no LZMA2 data at all, and thus most .xz files having no uncompressed data are handled correctly even without this fix. Signed-off-by: Lasse Collin <lasse.collin@tukaani.org> Signed-off-by: Jan Beulich <jbeulich@suse.com> changeset: 23868:28147fd781af user: Jan Beulich <jbeulich@suse.com> date: Thu Sep 22 18:32:34 2011 +0100 VT-d: fix off-by-one error in RMRR validation (base_addr,end_addr) is an inclusive range, and hence there shouldn't be a subtraction of 1 in the second invocation of page_is_ram_type(). For RMRRs covering a single page that actually resulted in the immediately preceding page to get checked (which could have resulted in a false warning). Signed-off-by: Jan Beulich <jbeulich@suse.com> changeset: 23867:571b6e90dfb4 user: Jan Beulich <jbeulich@suse.com> date: Thu Sep 22 18:31:44 2011 +0100 VT-d: eliminate a mis-use of pcidevs_lock dma_pte_clear_one() shouldn't acquire this global lock for the purpose of processing a per-domain list. Furthermore the function a few lines earlier has a comment stating that acquiring pcidevs_lock isn't necessary here (whether that's really correct is another question). Use the domain's mappin_lock instead to protect the mapped_rmrrs list. Fold domain_rmrr_mapped() into its sole caller so that the otherwise implicit dependency on pcidevs_lock there becomes more obvious (see the comment there). Signed-off-by: Jan Beulich <jbeulich@suse.com> changeset: 23866:47ec1d405af9 user: Jan Beulich <jbeulich@suse.com> date: Thu Sep 22 18:31:02 2011 +0100 x86: IO-APIC code has no dependency on PCI The IRQ handling code requires pcidevs_lock to be held only for MSI interrupts. As the handling of which was now fully moved into msi.c (i.e. while applying fine without, the patch needs to be applied after the one titled "x86: split MSI IRQ chip"), io_apic.c now also doesn't need to include PCI headers anymore. Signed-off-by: Jan Beulich <jbeulich@suse.com> changeset: 23865:d6e01c7853cf user: Jan Beulich <jbeulich@suse.com> date: Thu Sep 22 18:29:19 2011 +0100 PCI multi-seg: config space accessor adjustments Signed-off-by: Jan Beulich <jbeulich@suse.com> changeset: 23864:314b147d524d user: Jan Beulich <jbeulich@suse.com> date: Thu Sep 22 18:28:38 2011 +0100 PCI multi-seg: Pass-through adjustments Signed-off-by: Jan Beulich <jbeulich@suse.com> changeset: 23863:9e0259239822 user: Jan Beulich <jbeulich@suse.com> date: Thu Sep 22 18:28:03 2011 +0100 PCI multi-seg: AMD-IOMMU specific adjustments There are two places here where it is entirely unclear to me where the necessary PCI segment number should be taken from (as IVMD descriptors don't have such, only IVHD ones do). AMD confirmed that for the time being it is acceptable to imply that only segment 0 exists. Signed-off-by: Jan Beulich <jbeulich@suse.com> changeset: 23862:85418e168527 user: Jan Beulich <jbeulich@suse.com> date: Thu Sep 22 18:27:26 2011 +0100 PCI multi-seg: VT-d specific adjustments Signed-off-by: Jan Beulich <jbeulich@suse.com> changeset: 23861:ec7c81fbe0de user: Jan Beulich <jbeulich@suse.com> date: Thu Sep 22 18:26:54 2011 +0100 PCI multi-seg: adjust domctl interface Again, a couple of directly related functions at once get adjusted to account for the segment number. Signed-off-by: Jan Beulich <jbeulich@suse.com> changeset: 23860:a422e2a4451e user: Jan Beulich <jbeulich@suse.com> date: Sun Sep 18 00:26:52 2011 +0100 x86: split MSI IRQ chip With the .end() accessor having become optional and noting that several of the accessors' behavior really depends on the result of msi_maskable_irq(), the splits the MSI IRQ chip type into two - one for the maskable ones, and the other for the (MSI only) non-maskable ones. At once the implementation of those methods gets moved from io_apic.c to msi.c. Signed-off-by: Jan Beulich <jbeulich@suse.com> ======================================== commit cd776ee9408ff127f934a707c1a339ee600bc127 Author: Ian Jackson <ian.jackson@eu.citrix.com> Date: Tue Jun 28 13:50:53 2011 +0100 qemu-char.c: fix incorrect CONFIG_STUBDOM handling qemu-char.c:1123:7: warning: "CONFIG_STUBDOM" is not defined [-Wundef] Signed-off-by: Olaf Hering <olaf@aepfle.de> Acked-by: Ian Jackson <ian.jackson@eu.citrix.com> _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel From xen-devel-bounces@lists.xensource.com Sun Sep 25 22:03:11 2011 Return-path: <xen-devel-bounces@lists.xensource.com> Envelope-to: www-data@lists.xensource.com Delivery-date: Sun, 25 Sep 2011 22:03:11 -0700 Received: from localhost ([127.0.0.1] helo=lists.colo.xensource.com) by lists.xensource.com with esmtp (Exim 4.43) id 1R83LT-0004bE-2U; Sun, 25 Sep 2011 22:03:11 -0700 Received: from mail174.messagelabs.com ([85.158.138.51]) by lists.xensource.com with smtp (Exim 4.43) id 1R83KH-0004Na-Nw; Sun, 25 Sep 2011 22:02:01 -0700 X-Env-Sender: scottmeyers@live.com X-Msg-Ref: server-9.tower-174.messagelabs.com!1317013313!26683342!1 X-Originating-IP: [65.54.61.90] X-StarScan-Version: 6.4.1; banners=-,-,- X-VirusChecked: Checked Received: (qmail 26380 invoked from network); 26 Sep 2011 05:01:54 -0000 Received: from snt0-omc2-s39.snt0.hotmail.com (HELO snt0-omc2-s39.snt0.hotmail.com) (65.54.61.90) by server-9.tower-174.messagelabs.com with SMTP; 26 Sep 2011 05:01:54 -0000 Received: from SNT127-W41 ([65.55.90.73]) by snt0-omc2-s39.snt0.hotmail.com with Microsoft SMTPSVC(6.0.3790.4675); Sun, 25 Sep 2011 22:01:53 -0700 Message-ID: <SNT127-W41B1685EC11A7B7693B0A9C9F30@phx.gbl> X-Originating-IP: [97.116.1.132] From: Scott Meyers <scottmeyers@live.com> To: <xen-users@lists.xensource.com>, <xen-devel@lists.xensource.com> Date: Mon, 26 Sep 2011 00:01:52 -0500 Importance: Normal MIME-Version: 1.0 X-OriginalArrivalTime: 26 Sep 2011 05:01:53.0412 (UTC) FILETIME=[68591440:01CC7C09] Cc: Subject: [Xen-devel] Viewing the content of *.img file X-BeenThere: xen-devel@lists.xensource.com X-Mailman-Version: 2.1.5 Precedence: list List-Id: Xen developer discussion <xen-devel.lists.xensource.com> List-Unsubscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe> List-Post: <mailto:xen-devel@lists.xensource.com> List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help> List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=subscribe> Content-Type: multipart/mixed; boundary="===============0685288816==" Sender: xen-devel-bounces@lists.xensource.com Errors-To: xen-devel-bounces@lists.xensource.com --===============0685288816== Content-Type: multipart/alternative; boundary="_dc024d12-c111-40f3-99c9-f837e7d4c200_" --_dc024d12-c111-40f3-99c9-f837e7d4c200_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hello=2C I created 3 different DomUs and they are located/saved in /vm/ partition. T= he files extension is *.img. How can I view the content of any of these *.i= mg files in non-xen environment? Is that possible? If os=2C how?Thank you = --_dc024d12-c111-40f3-99c9-f837e7d4c200_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable <html> <head> <style><!-- .hmmessage P { margin:0px=3B padding:0px } body.hmmessage { font-size: 10pt=3B font-family:Tahoma } --></style> </head> <body class=3D'hmmessage'><div dir=3D'ltr'> <style><!messagesage P { margin:0px=3B padding:0px } body.hmmessage { font-size: 10pt=3B font-family:Tahoma } --></style> <div dir=3D"ltr"> Hello=2C<br>I created 3 different DomUs and they are located/saved in /vm/= partition. The files extension is *.img. </div><div dir=3D"ltr">How can I = view the content of any of these *.img files in non-xen environment? Is tha= t possible? If os=2C how?</div><div dir=3D"ltr">Thank you</div> </div></body> </html>= --_dc024d12-c111-40f3-99c9-f837e7d4c200_-- --===============0685288816== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel --===============0685288816==-- From xen-devel-bounces@lists.xensource.com Sun Sep 25 22:18:11 2011 Return-path: <xen-devel-bounces@lists.xensource.com> Envelope-to: www-data@lists.xensource.com Delivery-date: Sun, 25 Sep 2011 22:18:11 -0700 Received: from localhost ([127.0.0.1] helo=lists.colo.xensource.com) by lists.xensource.com with esmtp (Exim 4.43) id 1R83Zy-0006XC-RY; Sun, 25 Sep 2011 22:18:10 -0700 Received: from mail182.messagelabs.com ([85.158.139.83]) by lists.xensource.com with esmtp (Exim 4.43) id 1R83Z8-0006KW-JE for xen-devel@lists.xensource.com; Sun, 25 Sep 2011 22:17:19 -0700 X-Env-Sender: Ian.Jackson@eu.citrix.com X-Msg-Ref: server-8.tower-182.messagelabs.com!1317014235!18511007!1 X-Originating-IP: [62.200.22.115] X-StarScan-Version: 6.4.1; banners=-,-,- X-VirusChecked: Checked Received: (qmail 9331 invoked from network); 26 Sep 2011 05:17:15 -0000 Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115) by server-8.tower-182.messagelabs.com with RC4-SHA encrypted SMTP; 26 Sep 2011 05:17:15 -0000 X-IronPort-AV: E=Sophos;i="4.68,441,1312156800"; d="scan'208";a="8050292" Received: from lonpmailmx01.citrite.net ([10.30.203.162]) by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5; 26 Sep 2011 05:17:15 +0000 Received: from woking.xci-test.com (10.80.248.135) by smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id 8.3.137.0; Mon, 26 Sep 2011 06:17:15 +0100 Received: from osstest by woking.xci-test.com with local (Exim 4.69) (envelope-from <ian.jackson@eu.citrix.com>) id 1R83Z2-0007fw-Rl; Mon, 26 Sep 2011 06:17:14 +0100 To: xen-devel@lists.xensource.com Message-ID: <osstest-9084-mainreport@xen.org> From: xen.org <ian.jackson@eu.citrix.com> Date: Mon, 26 Sep 2011 06:17:12 +0100 MIME-Version: 1.0 Content-Type: text/plain Cc: ian.jackson@eu.citrix.com Subject: [Xen-devel] [linux test] 9084: tolerable FAIL X-BeenThere: xen-devel@lists.xensource.com X-Mailman-Version: 2.1.5 Precedence: list List-Id: Xen developer discussion <xen-devel.lists.xensource.com> List-Unsubscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe> List-Post: <mailto:xen-devel@lists.xensource.com> List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help> List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=subscribe> Sender: xen-devel-bounces@lists.xensource.com Errors-To: xen-devel-bounces@lists.xensource.com flight 9084 linux real [real] http://www.chiark.greenend.org.uk/~xensrcts/logs/9084/ Failures :-/ but no regressions. Tests which did not succeed, but are not blocking, including regressions (tests previously passed) regarded as allowable: test-amd64-amd64-xl-pcipt-intel 9 guest-start fail never pass test-amd64-i386-rhel6hvm-amd 9 guest-start.2 fail never pass test-amd64-i386-rhel6hvm-intel 9 guest-start.2 fail never pass test-amd64-i386-win-vcpus1 16 leak-check/check fail never pass test-amd64-i386-xl-win-vcpus1 13 guest-stop fail never pass test-amd64-amd64-win 16 leak-check/check fail never pass test-amd64-amd64-xl-win 13 guest-stop fail never pass test-i386-i386-win 16 leak-check/check fail never pass test-i386-i386-xl-win 13 guest-stop fail never pass test-amd64-i386-win 16 leak-check/check fail never pass version targeted for testing: linux 6bec8b4a4c14095d0b7ce424db9d583c3decae6c baseline version: linux 1c3f03ccc5258887f5f2cafc0836a865834f9205 ------------------------------------------------------------ People who touched revisions under test: Jeremy Fitzhardinge <jeremy.fitzhardinge@citrix.com> ------------------------------------------------------------ jobs: build-amd64 pass build-i386 pass build-amd64-pvops pass build-i386-pvops pass test-amd64-amd64-xl pass test-amd64-i386-xl pass test-i386-i386-xl pass test-amd64-i386-rhel6hvm-amd fail test-amd64-i386-xl-credit2 pass test-amd64-amd64-xl-pcipt-intel fail test-amd64-i386-rhel6hvm-intel fail test-amd64-i386-xl-multivcpu pass test-amd64-amd64-pair pass test-amd64-i386-pair pass test-i386-i386-pair pass test-amd64-amd64-pv pass test-amd64-i386-pv pass test-i386-i386-pv pass test-amd64-amd64-xl-sedf pass test-amd64-i386-win-vcpus1 fail test-amd64-i386-xl-win-vcpus1 fail test-amd64-amd64-win fail test-amd64-i386-win fail test-i386-i386-win fail test-amd64-amd64-xl-win fail test-i386-i386-xl-win fail ------------------------------------------------------------ sg-report-flight on woking.cam.xci-test.com logs: /home/xc_osstest/logs images: /home/xc_osstest/images Logs, config files, etc. are available at http://www.chiark.greenend.org.uk/~xensrcts/logs Test harness code can be found at http://xenbits.xensource.com/gitweb?p=osstest.git;a=summary Pushing revision : + branch=linux + revision=6bec8b4a4c14095d0b7ce424db9d583c3decae6c + . cri-lock-repos ++ . cri-common +++ umask 002 +++ getconfig Repos +++ perl -e ' use Osstest; readconfigonly(); print $c{Repos} or die $!; ' ++ repos=/export/home/osstest/repos ++ repos_lock=/export/home/osstest/repos/lock ++ '[' x '!=' x/export/home/osstest/repos/lock ']' ++ OSSTEST_REPOS_LOCK_LOCKED=/export/home/osstest/repos/lock ++ exec with-lock-ex -w /export/home/osstest/repos/lock ./ap-push linux 6bec8b4a4c14095d0b7ce424db9d583c3decae6c + branch=linux + revision=6bec8b4a4c14095d0b7ce424db9d583c3decae6c + . cri-lock-repos ++ . cri-common +++ umask 002 +++ getconfig Repos +++ perl -e ' use Osstest; readconfigonly(); print $c{Repos} or die $!; ' ++ repos=/export/home/osstest/repos ++ repos_lock=/export/home/osstest/repos/lock ++ '[' x/export/home/osstest/repos/lock '!=' x/export/home/osstest/repos/lock ']' + : xen@xenbits.xensource.com + : xen@xenbits.xensource.com:git/linux-pvops + : master + : tested/2.6.39.x + case "$branch" in + cd /export/home/osstest/repos/xen ./ap-push: line 20: cd: /export/home/osstest/repos/xen: No such file or directory ------------------------------------------------------------ commit 6bec8b4a4c14095d0b7ce424db9d583c3decae6c Author: Jeremy Fitzhardinge <jeremy.fitzhardinge@citrix.com> Date: Fri Sep 2 12:23:22 2011 -0700 Revert "xen/apic: Provide an 'apic_xen' to set the override the apic->[read|write] for all cases." This reverts commit c3dd7941354fa96a71f2613e2c7a1b215fa175dc. It prevents the kernel from booting natively on hardware. Conflicts: arch/x86/xen/enlighten.c Signed-off-by: Jeremy Fitzhardinge <jeremy.fitzhardinge@citrix.com> _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel From xen-devel-bounces@lists.xensource.com Sun Sep 25 23:05:27 2011 Return-path: <xen-devel-bounces@lists.xensource.com> Envelope-to: www-data@lists.xensource.com Delivery-date: Sun, 25 Sep 2011 23:05:27 -0700 Received: from localhost ([127.0.0.1] helo=lists.colo.xensource.com) by lists.xensource.com with esmtp (Exim 4.43) id 1R84Jh-0007zQ-7K; Sun, 25 Sep 2011 23:05:25 -0700 Received: from mail27.messagelabs.com ([193.109.254.147]) by lists.xensource.com with esmtp (Exim 4.43) id 1R84Hu-0007lb-0C for xen-devel@lists.xensource.com; Sun, 25 Sep 2011 23:03:37 -0700 X-Env-Sender: pasik@iki.fi X-Msg-Ref: server-8.tower-27.messagelabs.com!1317016993!48049291!1 X-Originating-IP: [192.89.123.25] X-StarScan-Version: 6.4.1; banners=-,-,- X-VirusChecked: Checked Received: (qmail 32498 invoked from network); 26 Sep 2011 06:03:13 -0000 Received: from smtp.tele.fi (HELO smtp.tele.fi) (192.89.123.25) by server-8.tower-27.messagelabs.com with DHE-RSA-AES256-SHA encrypted SMTP; 26 Sep 2011 06:03:13 -0000 X-Originating-Ip: [194.89.68.22] Received: from ydin.reaktio.net (reaktio.net [194.89.68.22]) by smtp.tele.fi (Postfix) with ESMTP id 458E52CC2; Mon, 26 Sep 2011 09:03:29 +0300 (EEST) Received: by ydin.reaktio.net (Postfix, from userid 1001) id 2AE29200E8; Mon, 26 Sep 2011 09:03:29 +0300 (EEST) Date: Mon, 26 Sep 2011 09:03:29 +0300 From: Pasi =?iso-8859-1?Q?K=E4rkk=E4inen?= <pasik@iki.fi> To: chris <tknchris@gmail.com> Subject: Re: [Xen-devel] PVUSB not working on squeeze Message-ID: <20110926060328.GJ12984@reaktio.net> References: <CAKnNFz_yraTP0-BrGQrC5BwzKKUmFVUqjDqbMhNu6-Nq6dVptQ@mail.gmail.com> <CAMrPLWJbK20VgzphhVtm98N6o-y3qyeP7+BhPJ-0O3NySrjHjg@mail.gmail.com> <CAKnNFz8m5RdpFcnvs7=Nx=dEp=t9_1RTZ7wwRjDCa0mhxque7w@mail.gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <CAKnNFz8m5RdpFcnvs7=Nx=dEp=t9_1RTZ7wwRjDCa0mhxque7w@mail.gmail.com> User-Agent: Mutt/1.5.18 (2008-05-17) Cc: Todd Deshane <todd.deshane@xen.org>, Xen-Devel List <xen-devel@lists.xensource.com> X-BeenThere: xen-devel@lists.xensource.com X-Mailman-Version: 2.1.5 Precedence: list List-Id: Xen developer discussion <xen-devel.lists.xensource.com> List-Unsubscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe> List-Post: <mailto:xen-devel@lists.xensource.com> List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help> List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=subscribe> Sender: xen-devel-bounces@lists.xensource.com Errors-To: xen-devel-bounces@lists.xensource.com On Sun, Sep 25, 2011 at 08:15:03PM -0400, chris wrote: > >From what I read on [1]http://wiki.xensource.com/xenwiki/XenDom0Kernels , > pv_ops currently doesnt have the PVUSB support without patching. So > therein lies my answer ;( There's a pvusb patch available for 2.6.32 pvops on: http://lists.xensource.com/archives/html/xen-devel/2011-01/msg00354.html -- Pasi > - chris > > On Sun, Sep 25, 2011 at 8:11 PM, Todd Deshane <[2]todd.deshane@xen.org> > wrote: > > On Sun, Sep 25, 2011 at 6:06 PM, chris <[3]tknchris@gmail.com> wrote: > > One thing I noticed is that I don't see any kind of usbfront module or > any > > usb frontend in lsmod. Is there some backend/frontend lacking in the > squeeze > > kernel? > > There is a "PVUSB support in Xen 4.0 and newer versions" on this wiki > page: > > [4]http://wiki.xensource.com/xenwiki/XenUSBPassthrough > > Hope that helps. > > Thanks, > Todd > -- > Todd Deshane > [5]http://www.linkedin.com/in/deshantm > [6]http://www.xen.org/products/cloudxen.html > [7]http://runningxen.com/ > > References > > Visible links > 1. http://wiki.xensource.com/xenwiki/XenDom0Kernels > 2. mailto:todd.deshane@xen.org > 3. mailto:tknchris@gmail.com > 4. http://wiki.xensource.com/xenwiki/XenUSBPassthrough > 5. http://www.linkedin.com/in/deshantm > 6. http://www.xen.org/products/cloudxen.html > 7. http://runningxen.com/ > _______________________________________________ > Xen-devel mailing list > Xen-devel@lists.xensource.com > http://lists.xensource.com/xen-devel _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel From xen-devel-bounces@lists.xensource.com Sun Sep 25 23:10:59 2011 Return-path: <xen-devel-bounces@lists.xensource.com> Envelope-to: www-data@lists.xensource.com Delivery-date: Sun, 25 Sep 2011 23:10:59 -0700 Received: from localhost ([127.0.0.1] helo=lists.colo.xensource.com) by lists.xensource.com with esmtp (Exim 4.43) id 1R84P4-0008Qo-Ko; Sun, 25 Sep 2011 23:10:58 -0700 Received: from mail182.messagelabs.com ([85.158.139.83]) by lists.xensource.com with esmtp (Exim 4.43) id 1R84Nu-0008De-Qz; Sun, 25 Sep 2011 23:09:49 -0700 X-Env-Sender: liuw@liuw.name X-Msg-Ref: server-13.tower-182.messagelabs.com!1317017382!19540720!1 X-Originating-IP: [209.85.213.171] X-StarScan-Version: 6.4.1; banners=-,-,- X-VirusChecked: Checked Received: (qmail 31643 invoked from network); 26 Sep 2011 06:09:43 -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; 26 Sep 2011 06:09:43 -0000 Received: by yxt3 with SMTP id 3so6260296yxt.30 for <multiple recipients>; Sun, 25 Sep 2011 23:09:42 -0700 (PDT) Received: by 10.42.108.70 with SMTP id g6mr6693868icp.111.1317017382162; Sun, 25 Sep 2011 23:09:42 -0700 (PDT) MIME-Version: 1.0 Received: by 10.231.13.137 with HTTP; Sun, 25 Sep 2011 23:09:12 -0700 (PDT) In-Reply-To: <SNT127-W41B1685EC11A7B7693B0A9C9F30@phx.gbl> References: <SNT127-W41B1685EC11A7B7693B0A9C9F30@phx.gbl> From: Wei Liu <liuw@liuw.name> Date: Mon, 26 Sep 2011 14:09:12 +0800 Message-ID: <CAOsiSVVc+3=o0EkCoJjV2KnfGue_bxXYEcJ-q=HEpWkX6Upp8A@mail.gmail.com> Subject: Re: [Xen-devel] Viewing the content of *.img file To: Scott Meyers <scottmeyers@live.com> Content-Type: text/plain; charset=UTF-8 Cc: xen-devel@lists.xensource.com, xen-users@lists.xensource.com X-BeenThere: xen-devel@lists.xensource.com X-Mailman-Version: 2.1.5 Precedence: list List-Id: Xen developer discussion <xen-devel.lists.xensource.com> List-Unsubscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe> List-Post: <mailto:xen-devel@lists.xensource.com> List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help> List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=subscribe> Sender: xen-devel-bounces@lists.xensource.com Errors-To: xen-devel-bounces@lists.xensource.com On Mon, Sep 26, 2011 at 1:01 PM, Scott Meyers <scottmeyers@live.com> wrote: > Hello, > I created 3 different DomUs and they are located/saved in /vm/ partition. > The files extension is *.img. > How can I view the content of any of these *.img files in non-xen > environment? Is that possible? If os, how? Please don't cross-post... And I think this question belongs to xen-users list. Firstly, try `file *.img` command to identify their format. Then, google access method according to the format. There should be lots of posts and articles on the web. Wei. _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel From xen-api-bounces@lists.xensource.com Mon Sep 26 00:09:00 2011 Return-path: <xen-api-bounces@lists.xensource.com> Envelope-to: www-data@lists.xensource.com Delivery-date: Mon, 26 Sep 2011 00:09:00 -0700 Received: from localhost ([127.0.0.1] helo=lists.colo.xensource.com) by lists.xensource.com with esmtp (Exim 4.43) id 1R85JE-0002un-4T; Mon, 26 Sep 2011 00:09:00 -0700 Received: from mail27.messagelabs.com ([193.109.254.147]) by lists.xensource.com with esmtp (Exim 4.43) id 1R85IM-0002rV-67; Mon, 26 Sep 2011 00:08:21 -0700 X-Env-Sender: mike.mcclurg@citrix.com X-Msg-Ref: server-8.tower-27.messagelabs.com!1317020864!48055979!1 X-Originating-IP: [66.165.176.63] X-StarScan-Version: 6.4.1; banners=-,-,- X-VirusChecked: Checked Received: (qmail 1727 invoked from network); 26 Sep 2011 07:07:45 -0000 Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63) by server-8.tower-27.messagelabs.com with RC4-SHA encrypted SMTP; 26 Sep 2011 07:07:45 -0000 X-IronPort-AV: E=Sophos;i="4.68,442,1312171200"; d="scan'208,217";a="164612326" Received: from ftlpmailmx02.citrite.net ([10.13.107.66]) by FTLPIPO02.CITRIX.COM with ESMTP/TLS/RC4-MD5; 26 Sep 2011 03:08:00 -0400 Received: from [IPv6:::1] (10.80.16.67) by smtprelay.citrix.com (10.13.107.66) with Microsoft SMTP Server id 8.3.137.0; Mon, 26 Sep 2011 03:08:00 -0400 Message-ID: <4E8024E5.9020406@citrix.com> Date: Mon, 26 Sep 2011 08:08:21 +0100 From: Mike McClurg <mike.mcclurg@citrix.com> User-Agent: Mozilla/5.0 (X11; Linux i686; rv:5.0) Gecko/20110807 Icedove/5.0 MIME-Version: 1.0 To: R J <torushikeshj@gmail.com> Subject: Re: [Xen-API] FT for XCP References: <CAO14VsP9by7CYgSiVN-hY0rJpDk0MYjuJ+FD5Tp3i8w+BcNYHw@mail.gmail.com> In-Reply-To: <CAO14VsP9by7CYgSiVN-hY0rJpDk0MYjuJ+FD5Tp3i8w+BcNYHw@mail.gmail.com> Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>, "xen-users@lists.xensource.com" <xen-users@lists.xensource.com>, "xen-api@lists.xensource.com" <xen-api@lists.xensource.com> X-BeenThere: xen-api@lists.xensource.com X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussion of API issues surrounding Xen <xen-api.lists.xensource.com> List-Unsubscribe: <http://lists.xensource.com/mailman/listinfo/xen-api>, <mailto:xen-api-request@lists.xensource.com?subject=unsubscribe> List-Post: <mailto:xen-api@lists.xensource.com> List-Help: <mailto:xen-api-request@lists.xensource.com?subject=help> List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-api>, <mailto:xen-api-request@lists.xensource.com?subject=subscribe> Content-Type: multipart/mixed; boundary="===============1085696570==" Sender: xen-api-bounces@lists.xensource.com Errors-To: xen-api-bounces@lists.xensource.com --===============1085696570== Content-Type: multipart/alternative; boundary="------------090300050806030107000906" --------------090300050806030107000906 Content-Type: text/plain; charset="ISO-8859-1"; format=flowed Content-Transfer-Encoding: 7bit On 09/25/2011 09:11 PM, R J wrote: > Hello List, > > I have a proposal and wont mind to implement my self but need a > helping hand to start on. > I want to implement the aggressive FT feature in XCP. The best way I > could imagine is the use of feature *Live Migration* > > Steps > 1. Enable the FT of a particular VM using xe commands and adding as a > param to that VM e.g. xe vm-param-set FT=true uuid=XYZ > 2. If the FT = true detected by xenstore then xapi will initiate a > live migrate of that VM to any of available host. > 3. A parallel "network ping"/"xapi heartbit" from/to that host could > be initialized for each FT VM. > 4. Live migrate will run forever until its disabled by FT = false or > one of the host is down. e.g. the process will loop at 99.99% > migration state > 5. If there is a packet drop of x packets the VM Migrate procedure > will mark the VM Migration as Complete and will switch the devices > forcefully. > -- this could result in some data loss but I dont have any alternative > to this. > -- The specific x packets can be set by XCP but we cant rely for > default XCP Errors > 6. If there is a successful migration due to host down then we will > again start from step2 > > Above steps I have assumed to my knowledge, we can discuss the > problems in it. > > Apologies if I'm being too naive. > > Regards, > Rushikesh > This sounds like Remus (http://nss.cs.ubc.ca/remus/). Are you proposing to implement Remus support in xapi? Mike --------------090300050806030107000906 Content-Type: text/html; charset="ISO-8859-1" Content-Transfer-Encoding: 7bit <html> <head> <meta content="text/html; charset=ISO-8859-1" http-equiv="Content-Type"> </head> <body bgcolor="#FFFFFF" text="#000000"> On 09/25/2011 09:11 PM, R J wrote: <blockquote cite="mid:%20%3CCAO14VsP9by7CYgSiVN-hY0rJpDk0MYjuJ+FD5Tp3i8w+BcNYHw@mail.gmail.com" type="cite">Hello List,<br> <br> I have a proposal and wont mind to implement my self but need a helping hand to start on.<br> I want to implement the aggressive FT feature in XCP. The best way I could imagine is the use of feature *Live Migration*<br> <br> Steps<br> 1. Enable the FT of a particular VM using xe commands and adding as a param to that VM e.g. xe vm-param-set FT=true uuid=XYZ<br> 2. If the FT = true detected by xenstore then xapi will initiate a live migrate of that VM to any of available host.<br> 3. A parallel "network ping"/"xapi heartbit" from/to that host could be initialized for each FT VM.<br> 4. Live migrate will run forever until its disabled by FT = false or one of the host is down. e.g. the process will loop at 99.99% migration state<br> 5. If there is a packet drop of x packets the VM Migrate procedure will mark the VM Migration as Complete and will switch the devices forcefully.<br> -- this could result in some data loss but I dont have any alternative to this.<br> -- The specific x packets can be set by XCP but we cant rely for default XCP Errors<br> 6. If there is a successful migration due to host down then we will again start from step2<br> <br> Above steps I have assumed to my knowledge, we can discuss the problems in it.<br> <br> Apologies if I'm being too naive.<br> <br> Regards,<br> Rushikesh<br> <br> </blockquote> <font size="-1">This sounds like Remus (<a class="moz-txt-link-freetext" href="http://nss.cs.ubc.ca/remus/">http://nss.cs.ubc.ca/remus/</a>). Are you proposing to implement Remus support in xapi?<br> <br> Mike<br> </font> </body> </html> --------------090300050806030107000906-- --===============1085696570== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ xen-api mailing list xen-api@lists.xensource.com http://lists.xensource.com/mailman/listinfo/xen-api --===============1085696570==-- From xen-devel-bounces@lists.xensource.com Mon Sep 26 00:23:40 2011 Return-path: <xen-devel-bounces@lists.xensource.com> Envelope-to: www-data@lists.xensource.com Delivery-date: Mon, 26 Sep 2011 00:23:40 -0700 Received: from localhost ([127.0.0.1] helo=lists.colo.xensource.com) by lists.xensource.com with esmtp (Exim 4.43) id 1R85XQ-0004Pj-73; Mon, 26 Sep 2011 00:23:40 -0700 Received: from mail182.messagelabs.com ([85.158.139.83]) by lists.xensource.com with esmtp (Exim 4.43) id 1R85Wf-0004DO-Nh for xen-devel@lists.xensource.com; Mon, 26 Sep 2011 00:22:54 -0700 X-Env-Sender: burns.me.uk@gmail.com X-Msg-Ref: server-9.tower-182.messagelabs.com!1317021769!19692052!1 X-Originating-IP: [209.85.212.43] X-StarScan-Version: 6.4.1; banners=-,-,- X-VirusChecked: Checked Received: (qmail 31768 invoked from network); 26 Sep 2011 07:22:50 -0000 Received: from mail-vw0-f43.google.com (HELO mail-vw0-f43.google.com) (209.85.212.43) by server-9.tower-182.messagelabs.com with RC4-SHA encrypted SMTP; 26 Sep 2011 07:22:50 -0000 Received: by vws13 with SMTP id 13so7009543vws.30 for <xen-devel@lists.xensource.com>; Mon, 26 Sep 2011 00:22:49 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:content-type; bh=y+4gWPd0N3YYe+PMSHHyHFK9zT43Ash5AnmQ1ZSgPgk=; b=AdMfOgAxVwmNkO3vJgLWC/nw5i0mKQtGnxmamCN+Q9L8UKIUVcpmlKGTJpgB82G+mx 0pFtUDiu+thAQV6s/k/QMqcW/o0hcOnCDBACnIAwfpKY0BCipTIaXxa6VTf2cp3QiHhY VyrVzZe4tOxkkwJTKzLGXimrJGhs2jRqaj6/Y= MIME-Version: 1.0 Received: by 10.52.173.47 with SMTP id bh15mr5327163vdc.503.1317021769506; Mon, 26 Sep 2011 00:22:49 -0700 (PDT) Received: by 10.52.160.9 with HTTP; Mon, 26 Sep 2011 00:22:49 -0700 (PDT) In-Reply-To: <28648118.H7Wrr3RcQX@dell4550> References: <201107231426.56811.jim_burn@bellsouth.net> <1777265.Pkue3yJNHT@dell4550> <2321907.7IxSxmjte4@dell4550> <28648118.H7Wrr3RcQX@dell4550> Date: Mon, 26 Sep 2011 08:22:49 +0100 X-Google-Sender-Auth: 9C_yncLSgUDFDKJOB6TSOcv1qPM Message-ID: <CAE1-PRfSn_y+2x-tGKgUwbUTTFm=7Q=a2Pf_mREwSQZFCi6ZEA@mail.gmail.com> Subject: Re: [Fedora-xen] [Xen-devel] Re: [Xen-users] Continuing BUG:-iness booting Fedora Rawhide 3.1.0-rc's (was Summary: Experiences setting up a debug serial port) From: Andy Burns <xen.lists@burns.me.uk> To: xen-devel@lists.xensource.com, Fedora Xen List <fedora-xen@redhat.com> Content-Type: text/plain; charset=ISO-8859-1 Cc: X-BeenThere: xen-devel@lists.xensource.com X-Mailman-Version: 2.1.5 Precedence: list List-Id: Xen developer discussion <xen-devel.lists.xensource.com> List-Unsubscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe> List-Post: <mailto:xen-devel@lists.xensource.com> List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help> List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=subscribe> Sender: xen-devel-bounces@lists.xensource.com Errors-To: xen-devel-bounces@lists.xensource.com On 23 September 2011 18:33, jim burns <jim_burn@bellsouth.net> wrote: > All in all, you're heading in the right direction. Thanx a lot. I ran into a couple of issues trying to install a FC16betaRC2 domU https://bugzilla.redhat.com/show_bug.cgi?id=708267 DIssapointing to read in the comments that the domU installation release blocker criteria might be dropped from Fedora :-( Even after I "hand-crafted" a domU (copied partitions from a baremetal FC16 install into an LVM PV) it wouldn't boot due to pygrub expecting /boot/grub/menu.lst rather than /boot/grub2/grub.cfg, so I hand-crafted one of those too, it boots but udev seems to dislike some USB devices embedded on the PCIe card I've passed through to the domU (PCI cards seem happy). Also the dom0 is very slow to reboot or poweroff, seems systemd related, it appears to want to unmount a sys/xen (?or similar?) mountpoint and keeps attempting this in with all the other closedown actions. I also found a few ways of triggering bugchecks when using PCI passthrough, I'll log BZs later for these when I have a serial console hooked up again (not forgotten about upstreaming my grub2 helper patch either) _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel From xen-devel-bounces@lists.xensource.com Mon Sep 26 01:10:10 2011 Return-path: <xen-devel-bounces@lists.xensource.com> Envelope-to: www-data@lists.xensource.com Delivery-date: Mon, 26 Sep 2011 01:10:10 -0700 Received: from localhost ([127.0.0.1] helo=lists.colo.xensource.com) by lists.xensource.com with esmtp (Exim 4.43) id 1R86GP-0005sb-Fj; Mon, 26 Sep 2011 01:10:09 -0700 Received: from mail21.messagelabs.com ([85.158.143.35]) by lists.xensource.com with esmtp (Exim 4.43) id 1R86EF-0005e1-OG; Mon, 26 Sep 2011 01:08:01 -0700 X-Env-Sender: Ian.Campbell@eu.citrix.com X-Msg-Ref: server-10.tower-21.messagelabs.com!1317024457!55479046!1 X-Originating-IP: [62.200.22.115] X-StarScan-Version: 6.4.1; banners=-,-,- X-VirusChecked: Checked Received: (qmail 30072 invoked from network); 26 Sep 2011 08:07:37 -0000 Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115) by server-10.tower-21.messagelabs.com with RC4-SHA encrypted SMTP; 26 Sep 2011 08:07:37 -0000 X-IronPort-AV: E=Sophos;i="4.68,442,1312156800"; d="scan'208";a="8052585" Received: from lonpmailmx01.citrite.net ([10.30.203.162]) by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5; 26 Sep 2011 08:07:52 +0000 Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net (10.30.203.162) with Microsoft SMTP Server id 8.3.137.0; Mon, 26 Sep 2011 09:07:51 +0100 Subject: Re: [Xen-devel] Re: [Xen-users] Is xen planning to support hvm guests booting under UEFI? From: Ian Campbell <Ian.Campbell@citrix.com> To: Keir Fraser <keir.xen@gmail.com>, Bei Guan <gbtju85@gmail.com>, <andrey.warkentin@gmail.com> Date: Mon, 26 Sep 2011 09:07:51 +0100 In-Reply-To: <CAA48DAF.2172A%keir.xen@gmail.com> References: <CAA48DAF.2172A%keir.xen@gmail.com> Organization: Citrix Systems, Inc. Content-Type: text/plain; charset="UTF-8" X-Mailer: Evolution 3.0.3- Content-Transfer-Encoding: 7bit Message-ID: <1317024471.24532.2.camel@zakaz.uk.xensource.com> MIME-Version: 1.0 Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>, Todd Deshane <todd.deshane@xen.org>, Paul Durrant <Paul.Durrant@citrix.com>, "xen-users@lists.xensource.com" <xen-users@lists.xensource.com>, jim burns <jim_burn@bellsouth.net> X-BeenThere: xen-devel@lists.xensource.com X-Mailman-Version: 2.1.5 Precedence: list List-Id: Xen developer discussion <xen-devel.lists.xensource.com> List-Unsubscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe> List-Post: <mailto:xen-devel@lists.xensource.com> List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help> List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=subscribe> Sender: xen-devel-bounces@lists.xensource.com Errors-To: xen-devel-bounces@lists.xensource.com Adding Bei Guan and Andrey Warkentin who I think were student and mentor respectively. Hi guys! On Sun, 2011-09-25 at 15:50 +0100, Keir Fraser wrote: > The GSOC project student seemed to be making good progress, and there were > others on the OVMF side who were giving him support. I haven't heard > anything in about a month now, though. It would be very interesting to get an update (or a pointer to one) of the status/result of this particular project now that the GSoC is over. Thanks, Ian. > > > On 25/09/2011 07:12, "Paul Durrant" <Paul.Durrant@citrix.com> wrote: > > > Since I was at the presentation in question, I asked about requirements for > > virtual platforms. I seem to recall the response being that UEFI was not a > > requirement for virtual platforms as yet and moreover I don't believe hyper-v > > VMs UEFI boot. > > That said I'm not sure about the requirements surrounding trusted boot; I > > guess they will become clearer as the HCK requirements are firmed up. > > > > I'd certainly like to see HVM UEFI boot sooner rather than later as I think it > > will speed up Windows boot (and not just for Windows 8) quite a lot but I > > didn't see any need to panic just yet. > > > > Paul > > > >> -----Original Message----- > >> From: xen-devel-bounces@lists.xensource.com [mailto:xen-devel- > >> bounces@lists.xensource.com] On Behalf Of jim burns > >> Sent: 25 September 2011 03:18 > >> To: xen-users@lists.xensource.com; xen-devel@lists.xensource.com > >> Cc: Todd Deshane > >> Subject: [Xen-devel] Re: [Xen-users] Is xen planning to support hvm > >> guests booting under UEFI? > >> > >> On Sat September 24 2011, 6:43:42 PM, Todd Deshane wrote: > >>> On Sat, Sep 24, 2011 at 5:34 PM, jim burns > >> <jim_burn@bellsouth.net> wrote: > >>>> On Wed September 21 2011, 9:06:38 PM, jim burns wrote: > >>>>> Pls cc: me as I am not subscribed. > >>>> > >>>> [...] > >>>> http://wiki.xensource.com/xenwiki/XenParavirtOps has been > >> reworked > >>>> recently. Not sure if this was there before: > >>>> > >>>> "Add EFI support in Linux pv-ops. Jan Beulich wrote patches to > >> make > >>>> Xen hypervisor be able to compile as an EFI application. "Build > >>>> xen.efi, write up a config file for it to read (most importantly > >> so > >>>> it knows what Dom0 kernel and initrd to use), and you should be > >> good > >>>> to go (provided the EFI implementation isn't too flawed). This > >> being > >>>> an EFI application you can simply run it from the shell prompt. > >>>> Parameter for Xen.efi is -cfg <file>, and <file> has: kernel=, > >>>> ramdisk=, options=, video=gfx-x. The Linux pv-ops needs at least > >> to > >>>> parse XEN_VGATYPE_EFI_LFB data, E820 parsed (should be working) > >> and > >>>> give the ACPI subsystem a pointer to the ACPI DSDT without > >> consulting EBDA." > >>>> > >>>> This doesn't solve the Windows 8 hvm problem, but at least EFI > >> is > >>>> being considered. > >>> > >>> There was a google summer of code project around UEFI: > >>> http://code.google.com/p/google-summer-of-code-2011- > >> tianocore/download > >>> s/deta > >>> il?name=Bei_Guan.tar.gz&can=2&q= > >>> > >>> I don't know if it was submitted to xen-devel, but you can follow > >> up > >>> with the xen-devel mailing list if you are interested. > >>> > >>> Hope that helps. > >> > >> The article I quoted was from http://www.itworld.com/it- > >> managementstrategy/205255/windows-8-oem-specs- > >> may-block-linux-booting : > >> > >> "Red Hat's Matthew Garrett was one of the first to notice that > >> according to the new logo rules, all Windows 8 machines will need to > >> be have the Unified Extensible Firmware Interface (UEFI) instead of > >> the venerable BIOS firmware layer. BIOS has been pretty much the > >> sole firmware interface for PCs for a long time. > >> > >> The EFI system has slowly been making headway in recent years, and > >> right now EFI firmware is compatible with Windows supporting the > >> GUID Partition Table (GPT), OS X/Intel, and Linux 2.6 and beyond > >> machines. EFI is seen as a better hardware/software interface than > >> BIOS, since it is platform-agnostic, runs in > >> 32- or 64-bit mode, and GPT machines can handle boot partitions of > >> up to 9.4 zettabytes. (That's 9.5 billion terabytes to you and me.) > >> > >> EFI, and the later UEFI specification, is not the problem for Linux. > >> The problem is Microsoft's other requirement for any Windows 8- > >> certified client: > >> the system must support secure booting. This hardened boot means > >> that "all firmware and software in the boot process must be signed > >> by a trusted Certificate Authority (CA)," according to slides from a > >> recent presentation on the UEFI boot process made by Arie van der > >> Hoeven, Microsoft Principal Lead Program Manager." > >> > >> Putting aside the signing problem for now, the immediate problem is > >> qemu-dm as the emulator for hvm guests, since it provides an > >> emulated *bios*. Or hvmloader as the bootloader. The url Todd > >> provides points to a project to modify 'ovmf', an EFI bootloader, to > >> be xen hvm aware. Windows 8 will be a game changer, if the article > >> is right. Hope plans are being made to incorporate some sort of EFI > >> bootloader into xen. > >> > >> _______________________________________________ > >> Xen-devel mailing list > >> Xen-devel@lists.xensource.com > >> http://lists.xensource.com/xen-devel > > > > _______________________________________________ > > Xen-devel mailing list > > Xen-devel@lists.xensource.com > > http://lists.xensource.com/xen-devel > > > > _______________________________________________ > Xen-devel mailing list > Xen-devel@lists.xensource.com > http://lists.xensource.com/xen-devel _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel From xen-devel-bounces@lists.xensource.com Mon Sep 26 01:36:32 2011 Return-path: <xen-devel-bounces@lists.xensource.com> Envelope-to: www-data@lists.xensource.com Delivery-date: Mon, 26 Sep 2011 01:36:32 -0700 Received: from localhost ([127.0.0.1] helo=lists.colo.xensource.com) by lists.xensource.com with esmtp (Exim 4.43) id 1R86fw-0007S0-2i; Mon, 26 Sep 2011 01:36:32 -0700 Received: from mail174.messagelabs.com ([85.158.138.51]) by lists.xensource.com with esmtp (Exim 4.43) id 1R86f8-0007Ew-Ru for xen-devel@lists.xensource.com; Mon, 26 Sep 2011 01:35:43 -0700 X-Env-Sender: xieliwei@gmail.com X-Msg-Ref: server-5.tower-174.messagelabs.com!1317026138!29042841!1 X-Originating-IP: [209.85.218.43] X-StarScan-Version: 6.4.1; banners=-,-,- X-VirusChecked: Checked Received: (qmail 24893 invoked from network); 26 Sep 2011 08:35:39 -0000 Received: from mail-yi0-f43.google.com (HELO mail-yi0-f43.google.com) (209.85.218.43) by server-5.tower-174.messagelabs.com with RC4-SHA encrypted SMTP; 26 Sep 2011 08:35:39 -0000 Received: by yib17 with SMTP id 17so6513515yib.30 for <xen-devel@lists.xensource.com>; Mon, 26 Sep 2011 01:35:38 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:from:date:message-id:subject:to:content-type; bh=S+lMqWriFQpqhPcyO5PqZVT9Zv18h4k+VxQE2zjYmmU=; b=cwj9M7wDBXePvqhxHOZVWWphJBa12WYkgT6+B44plIR49hjj/PlQ0S9sq8710jZP8l AHBhaaabpvtF0Lswqorf03VltueCWCDnI+OwBDF2UaMeIAxZu04AJrlfwSTR4dxB1Paz qeAaZK8gq3/AaNY3f1IJKMFTBml3GHP/P/lPw= Received: by 10.100.103.1 with SMTP id a1mr5650015anc.13.1317026138108; Mon, 26 Sep 2011 01:35:38 -0700 (PDT) MIME-Version: 1.0 Received: by 10.100.201.19 with HTTP; Mon, 26 Sep 2011 01:35:18 -0700 (PDT) From: Liwei <xieliwei@gmail.com> Date: Mon, 26 Sep 2011 16:35:18 +0800 Message-ID: <CAPE0SYxHsdSw0gabEXLA1ng3MMiMAGHpCn4o0RzV6bfNHxjrRA@mail.gmail.com> To: xen-devel <xen-devel@lists.xensource.com> Content-Type: multipart/mixed; boundary=0016e644c5701f34bf04add40bab Subject: [Xen-devel] Stuck at "Hardware Assisted Paging Enabled" with xen-unstable X-BeenThere: xen-devel@lists.xensource.com X-Mailman-Version: 2.1.5 Precedence: list List-Id: Xen developer discussion <xen-devel.lists.xensource.com> List-Unsubscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe> List-Post: <mailto:xen-devel@lists.xensource.com> List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help> List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=subscribe> Sender: xen-devel-bounces@lists.xensource.com Errors-To: xen-devel-bounces@lists.xensource.com --0016e644c5701f34bf04add40bab Content-Type: text/plain; charset=ISO-8859-1 Hello list, Decided to upgrade to the latest xen-unstable today. However the boot always stops at "HVM: Hardware Assisted Paging detected." Attached is a log of the boot process. The latest 4.1 version in mercurial works though (log attached as well), but causes the system to lockup every 10 or so hours (see next email). Any ideas? --0016e644c5701f34bf04add40bab Content-Type: text/plain; charset=US-ASCII; name="XenUnstableStuck.txt" Content-Disposition: attachment; filename="XenUnstableStuck.txt" Content-Transfer-Encoding: base64 X-Attachment-Id: f_gt1703s30 DQogX18gIF9fICAgICAgICAgICAgXyAgXyAgICBfX19fICAgICAgICAgICAgICAgICAgICAgXyAg ICAgICAgXyAgICAgXw0KIFwgXC8gL19fXyBfIF9fICAgfCB8fCB8ICB8X19fIFwgICAgXyAgIF8g XyBfXyAgX19ffCB8XyBfXyBffCB8X18gfCB8IF9fXw0KICBcICAvLyBfIFwgJ18gXCAgfCB8fCB8 XyAgIF9fKSB8X198IHwgfCB8ICdfIFwvIF9ffCBfXy8gX2AgfCAnXyBcfCB8LyBfIFwNCiAgLyAg XCAgX18vIHwgfCB8IHxfXyAgIF98IC8gX18vfF9ffCB8X3wgfCB8IHwgXF9fIFwgfHwgKF98IHwg fF8pIHwgfCAgX18vDQogL18vXF9cX19ffF98IHxffCAgICB8X3woXylfX19fX3wgICBcX18sX3xf fCB8X3xfX18vXF9fXF9fLF98Xy5fXy98X3xcX19ffA0KDQooWEVOKSBYZW4gdmVyc2lvbiA0LjIt dW5zdGFibGUgKHJvb3RAbG9jYWxob3N0KSAoZ2NjIHZlcnNpb24gNC42LjEgKERlYmlhbiA0LjYu MS00KSApIFN1biBTZXAgMjUgMjI6NDc6NTIgU0dUIDIwMTENCihYRU4pIExhdGVzdCBDaGFuZ2VT ZXQ6IFN1biBTZXAgMTggMDA6MjY6NTIgMjAxMSArMDEwMCAyMzg2MDphNDIyZTJhNDQ1MWUNCihY RU4pIENvbnNvbGUgb3V0cHV0IGlzIHN5bmNocm9ub3VzLg0KKFhFTikgQm9vdGxvYWRlcjogR1JV QiAxLjk5LTEyDQooWEVOKSBDb21tYW5kIGxpbmU6IHBsYWNlaG9sZGVyIGRvbTBfbWVtPTEwMjRN IGxvZ2x2bD1hbGwgZ3Vlc3RfbG9nbHZsPWFsbCBzeW5jX2NvbnNvbGUgY29uc29sZV90b19yaW5n IGNvbTE9MTE1MjAwLDhuMSwweGRjMDAsMCBjb25zb2xlPWNvbTENCihYRU4pIFZpZGVvIGluZm9y bWF0aW9uOg0KKFhFTikgIFZHQSBpcyB0ZXh0IG1vZGUgODB4MjUsIGZvbnQgOHgxNg0KKFhFTikg IFZCRS9EREMgbWV0aG9kczogVjI7IEVESUQgdHJhbnNmZXIgdGltZTogMSBzZWNvbmRzDQooWEVO KSBEaXNjIGluZm9ybWF0aW9uOg0KKFhFTikgIEZvdW5kIDUgTUJSIHNpZ25hdHVyZXMNCihYRU4p ICBGb3VuZCA1IEVERCBpbmZvcm1hdGlvbiBzdHJ1Y3R1cmVzDQooWEVOKSBYZW4tZTgyMCBSQU0g bWFwOg0KKFhFTikgIDAwMDAwMDAwMDAwMDAwMDAgLSAwMDAwMDAwMDAwMDllNDAwICh1c2FibGUp DQooWEVOKSAgMDAwMDAwMDAwMDA5ZTQwMCAtIDAwMDAwMDAwMDAwYTAwMDAgKHJlc2VydmVkKQ0K KFhFTikgIDAwMDAwMDAwMDAwZTAwMDAgLSAwMDAwMDAwMDAwMTAwMDAwIChyZXNlcnZlZCkNCihY RU4pICAwMDAwMDAwMDAwMTAwMDAwIC0gMDAwMDAwMDA5Zjc4MDAwMCAodXNhYmxlKQ0KKFhFTikg IDAwMDAwMDAwOWY3ODAwMDAgLSAwMDAwMDAwMDlmNzhlMDAwIChBQ1BJIGRhdGEpDQooWEVOKSAg MDAwMDAwMDA5Zjc4ZTAwMCAtIDAwMDAwMDAwOWY3ZDAwMDAgKEFDUEkgTlZTKQ0KKFhFTikgIDAw MDAwMDAwOWY3ZDAwMDAgLSAwMDAwMDAwMDlmN2UwMDAwIChyZXNlcnZlZCkNCihYRU4pICAwMDAw MDAwMDlmN2VkMDAwIC0gMDAwMDAwMDBhMDAwMDAwMCAocmVzZXJ2ZWQpDQooWEVOKSAgMDAwMDAw MDBmZWUwMDAwMCAtIDAwMDAwMDAwZmVlMDEwMDAgKHJlc2VydmVkKQ0KKFhFTikgIDAwMDAwMDAw ZmZhMDAwMDAgLSAwMDAwMDAwMTAwMDAwMDAwIChyZXNlcnZlZCkNCihYRU4pICAwMDAwMDAwMTAw MDAwMDAwIC0gMDAwMDAwMDQ2MDAwMDAwMCAodXNhYmxlKQ0KKFhFTikgQUNQSTogUlNEUCAwMDBG OUFBMCwgMDAyNCAocjIgQUNQSUFNKQ0KKFhFTikgQUNQSTogWFNEVCA5Rjc4MDEwMCwgMDA1QyAo cjEgMDkwOTA5IFhTRFQxNjAwIDIwMDkwOTA5IE1TRlQgICAgICAgOTcpDQooWEVOKSBBQ1BJOiBG QUNQIDlGNzgwMjkwLCAwMEY0IChyNCAwOTA5MDkgRkFDUDE2MDAgMjAwOTA5MDkgTVNGVCAgICAg ICA5NykNCihYRU4pIEFDUEk6IERTRFQgOUY3ODA0NjAsIDU5MTAgKHIyICAxRTY1OSAxRTY1OUEy NyAgICAgIEEyNyBJTlRMIDIwMDUxMTE3KQ0KKFhFTikgQUNQSTogRkFDUyA5Rjc4RTAwMCwgMDA0 MA0KKFhFTikgQUNQSTogQVBJQyA5Rjc4MDM5MCwgMDA4QyAocjIgMDkwOTA5IEFQSUMxNjAwIDIw MDkwOTA5IE1TRlQgICAgICAgOTcpDQooWEVOKSBBQ1BJOiBNQ0ZHIDlGNzgwNDIwLCAwMDNDIChy MSAwOTA5MDkgT0VNTUNGRyAgMjAwOTA5MDkgTVNGVCAgICAgICA5NykNCihYRU4pIEFDUEk6IE9F TUIgOUY3OEUwNDAsIDAwNzIgKHIxIDA5MDkwOSBPRU1CMTYwMCAyMDA5MDkwOSBNU0ZUICAgICAg IDk3KQ0KKFhFTikgQUNQSTogSFBFVCA5Rjc4QTQ2MCwgMDAzOCAocjEgMDkwOTA5IE9FTUhQRVQg IDIwMDkwOTA5IE1TRlQgICAgICAgOTcpDQooWEVOKSBBQ1BJOiBETUFSIDlGNzhFMEMwLCAwMDkw IChyMSAgICBBTUkgIE9FTURNQVIgICAgICAgIDEgTVNGVCAgICAgICA5NykNCihYRU4pIEFDUEk6 IFNTRFQgOUY3OTBFMzAsIDAzNjMgKHIxIERwZ1BtbSAgICBDcHVQbSAgICAgICAxMiBJTlRMIDIw MDUxMTE3KQ0KKFhFTikgU3lzdGVtIFJBTTogMTYzNzVNQiAoMTY3NjgxMjBrQikNCihYRU4pIE5v IE5VTUEgY29uZmlndXJhdGlvbiBmb3VuZA0KKFhFTikgRmFraW5nIGEgbm9kZSBhdCAwMDAwMDAw MDAwMDAwMDAwLTAwMDAwMDA0NjAwMDAwMDANCihYRU4pIERvbWFpbiBoZWFwIGluaXRpYWxpc2Vk DQooWEVOKSBmb3VuZCBTTVAgTVAtdGFibGUgYXQgMDAwZmY3ODANCihYRU4pIERNSSBwcmVzZW50 Lg0KKFhFTikgVXNpbmcgQVBJQyBkcml2ZXIgZGVmYXVsdA0KKFhFTikgQUNQSTogUE0tVGltZXIg SU8gUG9ydDogMHg4MDgNCihYRU4pIEFDUEk6IEFDUEkgU0xFRVAgSU5GTzogcG0xeF9jbnRbODA0 LDBdLCBwbTF4X2V2dFs4MDAsMF0NCihYRU4pIEFDUEk6ICAgICAgICAgICAgICAgICAgd2FrZXVw X3ZlY1s5Zjc4ZTAwY10sIHZlY19zaXplWzIwXQ0KKFhFTikgQUNQSTogTG9jYWwgQVBJQyBhZGRy ZXNzIDB4ZmVlMDAwMDANCihYRU4pIEFDUEk6IExBUElDIChhY3BpX2lkWzB4MDFdIGxhcGljX2lk WzB4MDBdIGVuYWJsZWQpDQooWEVOKSBQcm9jZXNzb3IgIzAgNzoxNCBBUElDIHZlcnNpb24gMjEN CihYRU4pIEFDUEk6IExBUElDIChhY3BpX2lkWzB4MDJdIGxhcGljX2lkWzB4MDJdIGVuYWJsZWQp DQooWEVOKSBQcm9jZXNzb3IgIzIgNzoxNCBBUElDIHZlcnNpb24gMjENCihYRU4pIEFDUEk6IExB UElDIChhY3BpX2lkWzB4MDNdIGxhcGljX2lkWzB4MDRdIGVuYWJsZWQpDQooWEVOKSBQcm9jZXNz b3IgIzQgNzoxNCBBUElDIHZlcnNpb24gMjENCihYRU4pIEFDUEk6IExBUElDIChhY3BpX2lkWzB4 MDRdIGxhcGljX2lkWzB4MDZdIGVuYWJsZWQpDQooWEVOKSBQcm9jZXNzb3IgIzYgNzoxNCBBUElD IHZlcnNpb24gMjENCihYRU4pIEFDUEk6IExBUElDIChhY3BpX2lkWzB4MDVdIGxhcGljX2lkWzB4 MDFdIGVuYWJsZWQpDQooWEVOKSBQcm9jZXNzb3IgIzEgNzoxNCBBUElDIHZlcnNpb24gMjENCihY RU4pIEFDUEk6IExBUElDIChhY3BpX2lkWzB4MDZdIGxhcGljX2lkWzB4MDNdIGVuYWJsZWQpDQoo WEVOKSBQcm9jZXNzb3IgIzMgNzoxNCBBUElDIHZlcnNpb24gMjENCihYRU4pIEFDUEk6IExBUElD IChhY3BpX2lkWzB4MDddIGxhcGljX2lkWzB4MDVdIGVuYWJsZWQpDQooWEVOKSBQcm9jZXNzb3Ig IzUgNzoxNCBBUElDIHZlcnNpb24gMjENCihYRU4pIEFDUEk6IExBUElDIChhY3BpX2lkWzB4MDhd IGxhcGljX2lkWzB4MDddIGVuYWJsZWQpDQooWEVOKSBQcm9jZXNzb3IgIzcgNzoxNCBBUElDIHZl cnNpb24gMjENCihYRU4pIEFDUEk6IElPQVBJQyAoaWRbMHgwOF0gYWRkcmVzc1sweGZlYzAwMDAw XSBnc2lfYmFzZVswXSkNCihYRU4pIElPQVBJQ1swXTogYXBpY19pZCA4LCB2ZXJzaW9uIDMyLCBh ZGRyZXNzIDB4ZmVjMDAwMDAsIEdTSSAwLTIzDQooWEVOKSBBQ1BJOiBJTlRfU1JDX09WUiAoYnVz IDAgYnVzX2lycSAwIGdsb2JhbF9pcnEgMiBkZmwgZGZsKQ0KKFhFTikgQUNQSTogSU5UX1NSQ19P VlIgKGJ1cyAwIGJ1c19pcnEgOSBnbG9iYWxfaXJxIDIwIGxvdyBsZXZlbCkNCihYRU4pIEFDUEk6 IElSUTAgdXNlZCBieSBvdmVycmlkZS4NCihYRU4pIEFDUEk6IElSUTIgdXNlZCBieSBvdmVycmlk ZS4NCihYRU4pIEFDUEk6IElSUTkgdXNlZCBieSBvdmVycmlkZS4NCihYRU4pIEVuYWJsaW5nIEFQ SUMgbW9kZTogIEZsYXQuICBVc2luZyAxIEkvTyBBUElDcw0KKFhFTikgQUNQSTogSFBFVCBpZDog MHhmZmZmZmZmZiBiYXNlOiAweGZlZDAwMDAwDQooWEVOKSBUYWJsZSBpcyBub3QgZm91bmQhDQoo WEVOKSBVc2luZyBBQ1BJIChNQURUKSBmb3IgU01QIGNvbmZpZ3VyYXRpb24gaW5mb3JtYXRpb24N CihYRU4pIElSUSBsaW1pdHM6IDI0IEdTSSwgMTUyOCBNU0kvTVNJLVgNCihYRU4pIFVzaW5nIHNj aGVkdWxlcjogU01QIENyZWRpdCBTY2hlZHVsZXIgKGNyZWRpdCkNCihYRU4pIERldGVjdGVkIDI5 MjkuNzA2IE1IeiBwcm9jZXNzb3IuDQooWEVOKSBJbml0aW5nIG1lbW9yeSBzaGFyaW5nLg0KKFhF TikgbWNlX2ludGVsLmM6MTIxNzogTUNBIENhcGFiaWxpdHk6IEJDQVNUIDEgU0VSIDAgQ01DSSAx IGZpcnN0YmFuayAwIGV4dGVuZGVkIE1DRSBNU1IgMA0KKFhFTikgSW50ZWwgbWFjaGluZSBjaGVj ayByZXBvcnRpbmcgZW5hYmxlZA0KKFhFTikgUENJOiBNQ0ZHIGNvbmZpZ3VyYXRpb24gMDogYmFz ZSBlMDAwMDAwMCBzZWdtZW50IDAwMDAgYnVzZXMgMDAgLSBmZg0KKFhFTikgUENJOiBOb3QgdXNp bmcgTUNGRyBmb3Igc2VnbWVudCAwMDAwIGJ1cyAwMC1mZg0KKFhFTikgSW50ZWwgVlQtZCBTbm9v cCBDb250cm9sIGVuYWJsZWQuDQooWEVOKSBJbnRlbCBWVC1kIERvbTAgRE1BIFBhc3N0aHJvdWdo IG5vdCBlbmFibGVkLg0KKFhFTikgSW50ZWwgVlQtZCBRdWV1ZWQgSW52YWxpZGF0aW9uIGVuYWJs ZWQuDQooWEVOKSBJbnRlbCBWVC1kIEludGVycnVwdCBSZW1hcHBpbmcgbm90IGVuYWJsZWQuDQoo WEVOKSBJbnRlbCBWVC1kIFNoYXJlZCBFUFQgdGFibGVzIG5vdCBlbmFibGVkLg0KKFhFTikgSS9P IHZpcnR1YWxpc2F0aW9uIGVuYWJsZWQNCihYRU4pICAtIERvbTAgbW9kZTogUmVsYXhlZA0KKFhF TikgRU5BQkxJTkcgSU8tQVBJQyBJUlFzDQooWEVOKSAgLT4gVXNpbmcgbmV3IEFDSyBtZXRob2QN CihYRU4pIC4uVElNRVI6IHZlY3Rvcj0weEYwIGFwaWMxPTAgcGluMT0yIGFwaWMyPS0xIHBpbjI9 LTENCihYRU4pIFBsYXRmb3JtIHRpbWVyIGlzIDE0LjMxOE1IeiBIUEVUDQooWEVOKSBBbGxvY2F0 ZWQgY29uc29sZSByaW5nIG9mIDY0IEtpQi4NCihYRU4pIFZNWDogU3VwcG9ydGVkIGFkdmFuY2Vk IGZlYXR1cmVzOg0KKFhFTikgIC0gQVBJQyBNTUlPIGFjY2VzcyB2aXJ0dWFsaXNhdGlvbg0KKFhF TikgIC0gQVBJQyBUUFIgc2hhZG93DQooWEVOKSAgLSBFeHRlbmRlZCBQYWdlIFRhYmxlcyAoRVBU KQ0KKFhFTikgIC0gVmlydHVhbC1Qcm9jZXNzb3IgSWRlbnRpZmllcnMgKFZQSUQpDQooWEVOKSAg LSBWaXJ0dWFsIE5NSQ0KKFhFTikgIC0gTVNSIGRpcmVjdC1hY2Nlc3MgYml0bWFwDQooWEVOKSBF UFQgc3VwcG9ydHMgMk1CIHN1cGVyIHBhZ2UuDQooWEVOKSBIVk06IEFTSURzIGVuYWJsZWQuDQoo WEVOKSBIVk06IFZNWCBlbmFibGVkDQooWEVOKSBIVk06IEhhcmR3YXJlIEFzc2lzdGVkIFBhZ2lu ZyBkZXRlY3RlZC4= --0016e644c5701f34bf04add40bab Content-Type: text/plain; charset=US-ASCII; name="Xen4.1Boot.txt" Content-Disposition: attachment; filename="Xen4.1Boot.txt" Content-Transfer-Encoding: base64 X-Attachment-Id: f_gt176uf91 IF9fICBfXyAgICAgICAgICAgIF8gIF8gICAgXyAgIF9fX18gICAgICAgICAgICAgIF9fX19fICAg ICAgICAgICAgICAgICAgIA0KIFwgXC8gL19fXyBfIF9fICAgfCB8fCB8ICAvIHwgfF9fXyBcICAg IF8gX18gX19ffF9fXyAvICAgIF8gX18gIF8gX18gX19fIA0KICBcICAvLyBfIFwgJ18gXCAgfCB8 fCB8XyB8IHwgICBfXykgfF9ffCAnX18vIF9ffCB8XyBcIF9ffCAnXyBcfCAnX18vIF8gXA0KICAv ICBcICBfXy8gfCB8IHwgfF9fICAgX3x8IHxfIC8gX18vfF9ffCB8IHwgKF9fIF9fXykgfF9ffCB8 XykgfCB8IHwgIF9fLw0KIC9fL1xfXF9fX3xffCB8X3wgICAgfF98KF8pXyhfKV9fX19ffCAgfF98 ICBcX19ffF9fX18vICAgfCAuX18vfF98ICBcX19ffA0KICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgfF98ICAgICAgICAgICAgIA0KKFhFTikg WGVuIHZlcnNpb24gNC4xLjItcmMzLXByZSAocm9vdEBsb2NhbGhvc3QpIChnY2MgdmVyc2lvbiA0 LjYuMSAoRGViaWFuIDQuNi4xLTQpICkgVHVlIFNlcCAyMCAxNzoxOToxOCBTR1QgMjAxMQ0KKFhF TikgTGF0ZXN0IENoYW5nZVNldDogU2F0IFNlcCAxNyAxNjozODozMSAyMDExICswMTAwIDIzMTU4 OjdkMTNlMDhiNTEyMA0KKFhFTikgQ29uc29sZSBvdXRwdXQgaXMgc3luY2hyb25vdXMuDQooWEVO KSBCb290bG9hZGVyOiBHUlVCIDEuOTktMTINCihYRU4pIENvbW1hbmQgbGluZTogcGxhY2Vob2xk ZXIgZG9tMF9tZW09MTAyNE0gbG9nbHZsPWFsbCBndWVzdF9sb2dsdmw9YWxsIHN5bmNfY29uc29s ZSBjb25zb2xlX3RvX3JpbmcgY29tMT0xMTUyMDAsOG4xLDB4ZGMwMCwwIGNvbnNvbGU9Y29tMQ0K KFhFTikgVmlkZW8gaW5mb3JtYXRpb246DQooWEVOKSAgVkdBIGlzIHRleHQgbW9kZSA4MHgyNSwg Zm9udCA4eDE2DQooWEVOKSAgVkJFL0REQyBtZXRob2RzOiBWMjsgRURJRCB0cmFuc2ZlciB0aW1l OiAxIHNlY29uZHMNCihYRU4pIERpc2MgaW5mb3JtYXRpb246DQooWEVOKSAgRm91bmQgMCBNQlIg c2lnbmF0dXJlcw0KKFhFTikgIEZvdW5kIDUgRUREIGluZm9ybWF0aW9uIHN0cnVjdHVyZXMNCihY RU4pIFhlbi1lODIwIFJBTSBtYXA6DQooWEVOKSAgMDAwMDAwMDAwMDAwMDAwMCAtIDAwMDAwMDAw MDAwOWU0MDAgKHVzYWJsZSkNCihYRU4pICAwMDAwMDAwMDAwMDllNDAwIC0gMDAwMDAwMDAwMDBh MDAwMCAocmVzZXJ2ZWQpDQooWEVOKSAgMDAwMDAwMDAwMDBlMDAwMCAtIDAwMDAwMDAwMDAxMDAw MDAgKHJlc2VydmVkKQ0KKFhFTikgIDAwMDAwMDAwMDAxMDAwMDAgLSAwMDAwMDAwMDlmNzgwMDAw ICh1c2FibGUpDQooWEVOKSAgMDAwMDAwMDA5Zjc4MDAwMCAtIDAwMDAwMDAwOWY3OGUwMDAgKEFD UEkgZGF0YSkNCihYRU4pICAwMDAwMDAwMDlmNzhlMDAwIC0gMDAwMDAwMDA5ZjdkMDAwMCAoQUNQ SSBOVlMpDQooWEVOKSAgMDAwMDAwMDA5ZjdkMDAwMCAtIDAwMDAwMDAwOWY3ZTAwMDAgKHJlc2Vy dmVkKQ0KKFhFTikgIDAwMDAwMDAwOWY3ZWQwMDAgLSAwMDAwMDAwMGEwMDAwMDAwIChyZXNlcnZl ZCkNCihYRU4pICAwMDAwMDAwMGZlZTAwMDAwIC0gMDAwMDAwMDBmZWUwMTAwMCAocmVzZXJ2ZWQp DQooWEVOKSAgMDAwMDAwMDBmZmEwMDAwMCAtIDAwMDAwMDAxMDAwMDAwMDAgKHJlc2VydmVkKQ0K KFhFTikgIDAwMDAwMDAxMDAwMDAwMDAgLSAwMDAwMDAwNDYwMDAwMDAwICh1c2FibGUpDQooWEVO KSBBQ1BJOiBSU0RQIDAwMEY5QUEwLCAwMDI0IChyMiBBQ1BJQU0pDQooWEVOKSBBQ1BJOiBYU0RU IDlGNzgwMTAwLCAwMDVDIChyMSAwOTA5MDkgWFNEVDE2MDAgMjAwOTA5MDkgTVNGVCAgICAgICA5 NykNCihYRU4pIEFDUEk6IEZBQ1AgOUY3ODAyOTAsIDAwRjQgKHI0IDA5MDkwOSBGQUNQMTYwMCAy MDA5MDkwOSBNU0ZUICAgICAgIDk3KQ0KKFhFTikgQUNQSTogRFNEVCA5Rjc4MDQ2MCwgNTkxMCAo cjIgIDFFNjU5IDFFNjU5QTI3ICAgICAgQTI3IElOVEwgMjAwNTExMTcpDQooWEVOKSBBQ1BJOiBG QUNTIDlGNzhFMDAwLCAwMDQwDQooWEVOKSBBQ1BJOiBBUElDIDlGNzgwMzkwLCAwMDhDIChyMiAw OTA5MDkgQVBJQzE2MDAgMjAwOTA5MDkgTVNGVCAgICAgICA5NykNCihYRU4pIEFDUEk6IE1DRkcg OUY3ODA0MjAsIDAwM0MgKHIxIDA5MDkwOSBPRU1NQ0ZHICAyMDA5MDkwOSBNU0ZUICAgICAgIDk3 KQ0KKFhFTikgQUNQSTogT0VNQiA5Rjc4RTA0MCwgMDA3MiAocjEgMDkwOTA5IE9FTUIxNjAwIDIw MDkwOTA5IE1TRlQgICAgICAgOTcpDQooWEVOKSBBQ1BJOiBIUEVUIDlGNzhBNDYwLCAwMDM4IChy MSAwOTA5MDkgT0VNSFBFVCAgMjAwOTA5MDkgTVNGVCAgICAgICA5NykNCihYRU4pIEFDUEk6IERN QVIgOUY3OEUwQzAsIDAwOTAgKHIxICAgIEFNSSAgT0VNRE1BUiAgICAgICAgMSBNU0ZUICAgICAg IDk3KQ0KKFhFTikgQUNQSTogU1NEVCA5Rjc5MEUzMCwgMDM2MyAocjEgRHBnUG1tICAgIENwdVBt ICAgICAgIDEyIElOVEwgMjAwNTExMTcpDQooWEVOKSBTeXN0ZW0gUkFNOiAxNjM3NU1CICgxNjc2 ODEyMGtCKQ0KKFhFTikgTm8gTlVNQSBjb25maWd1cmF0aW9uIGZvdW5kDQooWEVOKSBGYWtpbmcg YSBub2RlIGF0IDAwMDAwMDAwMDAwMDAwMDAtMDAwMDAwMDQ2MDAwMDAwMA0KKFhFTikgRG9tYWlu IGhlYXAgaW5pdGlhbGlzZWQNCihYRU4pIGZvdW5kIFNNUCBNUC10YWJsZSBhdCAwMDBmZjc4MA0K KFhFTikgRE1JIHByZXNlbnQuDQooWEVOKSBVc2luZyBBUElDIGRyaXZlciBkZWZhdWx0DQooWEVO KSBBQ1BJOiBQTS1UaW1lciBJTyBQb3J0OiAweDgwOA0KKFhFTikgQUNQSTogQUNQSSBTTEVFUCBJ TkZPOiBwbTF4X2NudFs4MDQsMF0sIHBtMXhfZXZ0WzgwMCwwXQ0KKFhFTikgQUNQSTogICAgICAg ICAgICAgICAgICB3YWtldXBfdmVjWzlmNzhlMDBjXSwgdmVjX3NpemVbMjBdDQooWEVOKSBBQ1BJ OiBMb2NhbCBBUElDIGFkZHJlc3MgMHhmZWUwMDAwMA0KKFhFTikgQUNQSTogTEFQSUMgKGFjcGlf aWRbMHgwMV0gbGFwaWNfaWRbMHgwMF0gZW5hYmxlZCkNCihYRU4pIFByb2Nlc3NvciAjMCA3OjE0 IEFQSUMgdmVyc2lvbiAyMQ0KKFhFTikgQUNQSTogTEFQSUMgKGFjcGlfaWRbMHgwMl0gbGFwaWNf aWRbMHgwMl0gZW5hYmxlZCkNCihYRU4pIFByb2Nlc3NvciAjMiA3OjE0IEFQSUMgdmVyc2lvbiAy MQ0KKFhFTikgQUNQSTogTEFQSUMgKGFjcGlfaWRbMHgwM10gbGFwaWNfaWRbMHgwNF0gZW5hYmxl ZCkNCihYRU4pIFByb2Nlc3NvciAjNCA3OjE0IEFQSUMgdmVyc2lvbiAyMQ0KKFhFTikgQUNQSTog TEFQSUMgKGFjcGlfaWRbMHgwNF0gbGFwaWNfaWRbMHgwNl0gZW5hYmxlZCkNCihYRU4pIFByb2Nl c3NvciAjNiA3OjE0IEFQSUMgdmVyc2lvbiAyMQ0KKFhFTikgQUNQSTogTEFQSUMgKGFjcGlfaWRb MHgwNV0gbGFwaWNfaWRbMHgwMV0gZW5hYmxlZCkNCihYRU4pIFByb2Nlc3NvciAjMSA3OjE0IEFQ SUMgdmVyc2lvbiAyMQ0KKFhFTikgQUNQSTogTEFQSUMgKGFjcGlfaWRbMHgwNl0gbGFwaWNfaWRb MHgwM10gZW5hYmxlZCkNCihYRU4pIFByb2Nlc3NvciAjMyA3OjE0IEFQSUMgdmVyc2lvbiAyMQ0K KFhFTikgQUNQSTogTEFQSUMgKGFjcGlfaWRbMHgwN10gbGFwaWNfaWRbMHgwNV0gZW5hYmxlZCkN CihYRU4pIFByb2Nlc3NvciAjNSA3OjE0IEFQSUMgdmVyc2lvbiAyMQ0KKFhFTikgQUNQSTogTEFQ SUMgKGFjcGlfaWRbMHgwOF0gbGFwaWNfaWRbMHgwN10gZW5hYmxlZCkNCihYRU4pIFByb2Nlc3Nv ciAjNyA3OjE0IEFQSUMgdmVyc2lvbiAyMQ0KKFhFTikgQUNQSTogSU9BUElDIChpZFsweDA4XSBh ZGRyZXNzWzB4ZmVjMDAwMDBdIGdzaV9iYXNlWzBdKQ0KKFhFTikgSU9BUElDWzBdOiBhcGljX2lk IDgsIHZlcnNpb24gMzIsIGFkZHJlc3MgMHhmZWMwMDAwMCwgR1NJIDAtMjMNCihYRU4pIEFDUEk6 IElOVF9TUkNfT1ZSIChidXMgMCBidXNfaXJxIDAgZ2xvYmFsX2lycSAyIGRmbCBkZmwpDQooWEVO KSBBQ1BJOiBJTlRfU1JDX09WUiAoYnVzIDAgYnVzX2lycSA5IGdsb2JhbF9pcnEgMjAgbG93IGxl dmVsKQ0KKFhFTikgQUNQSTogSVJRMCB1c2VkIGJ5IG92ZXJyaWRlLg0KKFhFTikgQUNQSTogSVJR MiB1c2VkIGJ5IG92ZXJyaWRlLg0KKFhFTikgQUNQSTogSVJROSB1c2VkIGJ5IG92ZXJyaWRlLg0K KFhFTikgRW5hYmxpbmcgQVBJQyBtb2RlOiAgRmxhdC4gIFVzaW5nIDEgSS9PIEFQSUNzDQooWEVO KSBBQ1BJOiBIUEVUIGlkOiAweGZmZmZmZmZmIGJhc2U6IDB4ZmVkMDAwMDANCihYRU4pIFBDSTog TUNGRyBjb25maWd1cmF0aW9uIDA6IGJhc2UgZTAwMDAwMDAgc2VnbWVudCAwIGJ1c2VzIDAgLSAy NTUNCihYRU4pIFBDSTogTm90IHVzaW5nIE1NQ09ORklHLg0KKFhFTikgVGFibGUgaXMgbm90IGZv dW5kIQ0KKFhFTikgVXNpbmcgQUNQSSAoTUFEVCkgZm9yIFNNUCBjb25maWd1cmF0aW9uIGluZm9y bWF0aW9uDQooWEVOKSBJUlEgbGltaXRzOiAyNCBHU0ksIDE1MjggTVNJL01TSS1YDQooWEVOKSBV c2luZyBzY2hlZHVsZXI6IFNNUCBDcmVkaXQgU2NoZWR1bGVyIChjcmVkaXQpDQooWEVOKSBEZXRl Y3RlZCAyOTI5Ljc0OCBNSHogcHJvY2Vzc29yLg0KKFhFTikgSW5pdGluZyBtZW1vcnkgc2hhcmlu Zy4NCihYRU4pIG1jZV9pbnRlbC5jOjExNjI6IE1DQSBDYXBhYmlsaXR5OiBCQ0FTVCAxIFNFUiAw IENNQ0kgMSBmaXJzdGJhbmsgMCBleHRlbmRlZCBNQ0UgTVNSIDANCihYRU4pIEludGVsIG1hY2hp bmUgY2hlY2sgcmVwb3J0aW5nIGVuYWJsZWQNCihYRU4pIEludGVsIFZULWQgU25vb3AgQ29udHJv bCBlbmFibGVkLg0KKFhFTikgSW50ZWwgVlQtZCBEb20wIERNQSBQYXNzdGhyb3VnaCBub3QgZW5h YmxlZC4NCihYRU4pIEludGVsIFZULWQgUXVldWVkIEludmFsaWRhdGlvbiBlbmFibGVkLg0KKFhF TikgSW50ZWwgVlQtZCBJbnRlcnJ1cHQgUmVtYXBwaW5nIG5vdCBlbmFibGVkLg0KKFhFTikgSW50 ZWwgVlQtZCBTaGFyZWQgRVBUIHRhYmxlcyBub3QgZW5hYmxlZC4NCihYRU4pIEkvTyB2aXJ0dWFs aXNhdGlvbiBlbmFibGVkDQooWEVOKSAgLSBEb20wIG1vZGU6IFJlbGF4ZWQNCihYRU4pIEVOQUJM SU5HIElPLUFQSUMgSVJRcw0KKFhFTikgIC0+IFVzaW5nIG5ldyBBQ0sgbWV0aG9kDQooWEVOKSAu LlRJTUVSOiB2ZWN0b3I9MHhGMCBhcGljMT0wIHBpbjE9MiBhcGljMj0tMSBwaW4yPS0xDQooWEVO KSBQbGF0Zm9ybSB0aW1lciBpcyAxNC4zMThNSHogSFBFVA0KKFhFTikgQWxsb2NhdGVkIGNvbnNv bGUgcmluZyBvZiA2NCBLaUIuDQooWEVOKSBWTVg6IFN1cHBvcnRlZCBhZHZhbmNlZCBmZWF0dXJl czoNCihYRU4pICAtIEFQSUMgTU1JTyBhY2Nlc3MgdmlydHVhbGlzYXRpb24NCihYRU4pICAtIEFQ SUMgVFBSIHNoYWRvdw0KKFhFTikgIC0gRXh0ZW5kZWQgUGFnZSBUYWJsZXMgKEVQVCkNCihYRU4p ICAtIFZpcnR1YWwtUHJvY2Vzc29yIElkZW50aWZpZXJzIChWUElEKQ0KKFhFTikgIC0gVmlydHVh bCBOTUkNCihYRU4pICAtIE1TUiBkaXJlY3QtYWNjZXNzIGJpdG1hcA0KKFhFTikgRVBUIHN1cHBv cnRzIDJNQiBzdXBlciBwYWdlLg0KKFhFTikgSFZNOiBBU0lEcyBlbmFibGVkLg0KKFhFTikgSFZN OiBWTVggZW5hYmxlZA0KKFhFTikgSFZNOiBIYXJkd2FyZSBBc3Npc3RlZCBQYWdpbmcgZGV0ZWN0 ZWQuDQooWEVOKSBCcm91Z2h0IHVwIDggQ1BVcw0KKFhFTikgSFBFVDogOCB0aW1lcnMgaW4gdG90 YWwsIDggdGltZXJzIHdpbGwgYmUgdXNlZCBmb3IgYnJvYWRjYXN0DQooWEVOKSBBQ1BJIHNsZWVw IG1vZGVzOiBTMw0KKFhFTikgbWNoZWNrX3BvbGw6IE1hY2hpbmUgY2hlY2sgcG9sbGluZyB0aW1l ciBzdGFydGVkLg0KKFhFTikgKioqIExPQURJTkcgRE9NQUlOIDAgKioqDQooWEVOKSAgWGVuICBr ZXJuZWw6IDY0LWJpdCwgbHNiLCBjb21wYXQzMg0KKFhFTikgIERvbTAga2VybmVsOiA2NC1iaXQs IFBBRSwgbHNiLCBwYWRkciAweDEwMDAwMDAgLT4gMHgxYjJjMDAwDQooWEVOKSBQSFlTSUNBTCBN RU1PUlkgQVJSQU5HRU1FTlQ6DQooWEVOKSAgRG9tMCBhbGxvYy46ICAgMDAwMDAwMDQ0ZTAwMDAw MC0+MDAwMDAwMDQ1MDAwMDAwMCAoMjQ1MzYxIHBhZ2VzIHRvIGJlIGFsbG9jYXRlZCkNCihYRU4p ICBJbml0LiByYW1kaXNrOiAwMDAwMDAwNDVkZTcxMDAwLT4wMDAwMDAwNDVmZmZmMjAwDQooWEVO KSBWSVJUVUFMIE1FTU9SWSBBUlJBTkdFTUVOVDoNCihYRU4pICBMb2FkZWQga2VybmVsOiBmZmZm ZmZmZjgxMDAwMDAwLT5mZmZmZmZmZjgxYjJjMDAwDQooWEVOKSAgSW5pdC4gcmFtZGlzazogZmZm ZmZmZmY4MWIyYzAwMC0+ZmZmZmZmZmY4M2NiYTIwMA0KKFhFTikgIFBoeXMtTWFjaCBtYXA6IGZm ZmZmZmZmODNjYmIwMDAtPmZmZmZmZmZmODNlYmIwMDANCihYRU4pICBTdGFydCBpbmZvOiAgICBm ZmZmZmZmZjgzZWJiMDAwLT5mZmZmZmZmZjgzZWJiNGI0DQooWEVOKSAgUGFnZSB0YWJsZXM6ICAg ZmZmZmZmZmY4M2ViYzAwMC0+ZmZmZmZmZmY4M2VkZjAwMA0KKFhFTikgIEJvb3Qgc3RhY2s6ICAg IGZmZmZmZmZmODNlZGYwMDAtPmZmZmZmZmZmODNlZTAwMDANCihYRU4pICBUT1RBTDogICAgICAg ICBmZmZmZmZmZjgwMDAwMDAwLT5mZmZmZmZmZjg0MDAwMDAwDQooWEVOKSAgRU5UUlkgQUREUkVT UzogZmZmZmZmZmY4MTg5ZTIwMA0KKFhFTikgRG9tMCBoYXMgbWF4aW11bSA4IFZDUFVzDQooWEVO KSBTY3J1YmJpbmcgRnJlZSBSQU06IC4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4u Li4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4u Li4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4u Li5kb25lLg0KKFhFTikgWGVuIHRyYWNlIGJ1ZmZlcnM6IGRpc2FibGVkDQooWEVOKSBTdGQuIExv Z2xldmVsOiBBbGwNCihYRU4pIEd1ZXN0IExvZ2xldmVsOiBBbGwNCihYRU4pICoqKioqKioqKioq KioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioNCihYRU4pICoqKioqKiogV0FSTklO RzogQ09OU09MRSBPVVRQVVQgSVMgU1lOQ0hST05PVVMNCihYRU4pICoqKioqKiogVGhpcyBvcHRp b24gaXMgaW50ZW5kZWQgdG8gYWlkIGRlYnVnZ2luZyBvZiBYZW4gYnkgZW5zdXJpbmcNCihYRU4p ICoqKioqKiogdGhhdCBhbGwgb3V0cHV0IGlzIHN5bmNocm9ub3VzbHkgZGVsaXZlcmVkIG9uIHRo ZSBzZXJpYWwgbGluZS4NCihYRU4pICoqKioqKiogSG93ZXZlciBpdCBjYW4gaW50cm9kdWNlIFNJ R05JRklDQU5UIGxhdGVuY2llcyBhbmQgYWZmZWN0DQooWEVOKSAqKioqKioqIHRpbWVrZWVwaW5n LiBJdCBpcyBOT1QgcmVjb21tZW5kZWQgZm9yIHByb2R1Y3Rpb24gdXNlIQ0KKFhFTikgKioqKioq KioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKg0KKFhFTikgMy4uLiAyLi4u IDEuLi4gDQooWEVOKSAqKiogU2VyaWFsIGlucHV0IC0+IERPTTAgKHR5cGUgJ0NUUkwtYScgdGhy ZWUgdGltZXMgdG8gc3dpdGNoIGlucHV0IHRvIFhlbikNCihYRU4pIEZyZWVkIDIxNmtCIGluaXQg bWVtb3J5Lg0KbWFwcGluZyBrZXJuZWwgaW50byBwaHlzaWNhbCBtZW1vcnkNClhlbjogc2V0dXAg SVNBIGlkZW50aXR5IG1hcHMNCmFib3V0IHRvIGdldCBzdGFydGVkLi4uDQooWEVOKSBQQ0kgYWRk IGRldmljZSAwMDowMC4wDQooWEVOKSBQQ0kgYWRkIGRldmljZSAwMDowMy4wDQooWEVOKSBQQ0kg YWRkIGRldmljZSAwMDowNS4wDQooWEVOKSBQQ0kgYWRkIGRldmljZSAwMDowOC4wDQooWEVOKSBQ Q0kgYWRkIGRldmljZSAwMDowOC4xDQooWEVOKSBQQ0kgYWRkIGRldmljZSAwMDowOC4yDQooWEVO KSBQQ0kgYWRkIGRldmljZSAwMDowOC4zDQooWEVOKSBQQ0kgYWRkIGRldmljZSAwMDoxMC4wDQoo WEVOKSBQQ0kgYWRkIGRldmljZSAwMDoxMC4xDQooWEVOKSBQQ0kgYWRkIGRldmljZSAwMDoxYS4w DQooWEVOKSBQQ0kgYWRkIGRldmljZSAwMDoxYi4wDQooWEVOKSBQQ0kgYWRkIGRldmljZSAwMDox Yy4wDQooWEVOKSBQQ0kgYWRkIGRldmljZSAwMDoxYy40DQooWEVOKSBQQ0kgYWRkIGRldmljZSAw MDoxYy41DQooWEVOKSBQQ0kgYWRkIGRldmljZSAwMDoxYy43DQooWEVOKSBQQ0kgYWRkIGRldmlj ZSAwMDoxZC4wDQooWEVOKSBQQ0kgYWRkIGRldmljZSAwMDoxZS4wDQooWEVOKSBQQ0kgYWRkIGRl dmljZSAwMDoxZi4wDQooWEVOKSBQQ0kgYWRkIGRldmljZSAwMDoxZi4yDQooWEVOKSBQQ0kgYWRk IGRldmljZSAwMDoxZi4zDQooWEVOKSBQQ0kgYWRkIGRldmljZSAwMTowMC4wDQooWEVOKSBQQ0kg YWRkIGRldmljZSAwMTowMC4xDQooWEVOKSBQQ0kgYWRkIGRldmljZSAwMjowMC4wDQooWEVOKSBQ Q0kgYWRkIGRldmljZSAwMzowMC4wDQooWEVOKSBQQ0kgYWRkIGRldmljZSAwMzowMi4wDQooWEVO KSBQQ0kgYWRkIGRldmljZSAwNDowMC4wDQooWEVOKSBQQ0kgYWRkIGRldmljZSAwNTowMC4wDQoo WEVOKSBQQ0kgYWRkIGRldmljZSAwNjowMi4wDQooWEVOKSBQQ0kgYWRkIGRldmljZSAwNjowMy4w DQooWEVOKSBQQ0kgYWRkIGRldmljZSAwNjowNC4wDQooWEVOKSBQQ0kgYWRkIGRldmljZSAwNjow NS4wDQooWEVOKSBQQ0kgYWRkIGRldmljZSAwNzowMC4wDQooWEVOKSBQQ0kgYWRkIGRldmljZSAw ODowMC4wDQooWEVOKSBQQ0kgYWRkIGRldmljZSAwOTowMC4wDQooWEVOKSBQQ0kgYWRkIGRldmlj ZSAwYTowMC4wDQooWEVOKSBQQ0kgYWRkIGRldmljZSAwYzowMC4wDQooWEVOKSBQQ0kgYWRkIGRl dmljZSAwZDowMC4wDQooWEVOKSBQQ0kgYWRkIGRldmljZSAwZTowMC4wDQooWEVOKSBQQ0kgYWRk IGRldmljZSAwZTowMC4xDQooWEVOKSBQQ0kgYWRkIGRldmljZSAwZTowMC4yDQooWEVOKSBQQ0kg YWRkIGRldmljZSAwZjowMy4wDQooWEVOKSBQQ0kgYWRkIGRldmljZSBmZjowMC4wDQooWEVOKSBQ Q0kgYWRkIGRldmljZSBmZjowMC4xDQooWEVOKSBQQ0kgYWRkIGRldmljZSBmZjowMi4wDQooWEVO KSBQQ0kgYWRkIGRldmljZSBmZjowMi4xDQooWEVOKSBQQ0kgYWRkIGRldmljZSBmZjowMy4wDQoo WEVOKSBQQ0kgYWRkIGRldmljZSBmZjowMy4xDQooWEVOKSBQQ0kgYWRkIGRldmljZSBmZjowMy40 DQooWEVOKSBQQ0kgYWRkIGRldmljZSBmZjowNC4wDQooWEVOKSBQQ0kgYWRkIGRldmljZSBmZjow NC4xDQooWEVOKSBQQ0kgYWRkIGRldmljZSBmZjowNC4yDQooWEVOKSBQQ0kgYWRkIGRldmljZSBm ZjowNC4zDQooWEVOKSBQQ0kgYWRkIGRldmljZSBmZjowNS4wDQooWEVOKSBQQ0kgYWRkIGRldmlj ZSBmZjowNS4xDQooWEVOKSBQQ0kgYWRkIGRldmljZSBmZjowNS4yDQooWEVOKSBQQ0kgYWRkIGRl dmljZSBmZjowNS4zDQpMb2FkaW5nLCBwbGVhc2Ugd2FpdC4uLg0K --0016e644c5701f34bf04add40bab Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel --0016e644c5701f34bf04add40bab-- From xen-devel-bounces@lists.xensource.com Mon Sep 26 01:48:08 2011 Return-path: <xen-devel-bounces@lists.xensource.com> Envelope-to: www-data@lists.xensource.com Delivery-date: Mon, 26 Sep 2011 01:48:08 -0700 Received: from localhost ([127.0.0.1] helo=lists.colo.xensource.com) by lists.xensource.com with esmtp (Exim 4.43) id 1R86r9-00088z-Qs; Mon, 26 Sep 2011 01:48:08 -0700 Received: from mail27.messagelabs.com ([193.109.254.147]) by lists.xensource.com with esmtp (Exim 4.43) id 1R86qK-0007vw-1y for xen-devel@lists.xensource.com; Mon, 26 Sep 2011 01:47:17 -0700 X-Env-Sender: xieliwei@gmail.com X-Msg-Ref: server-11.tower-27.messagelabs.com!1317026822!38890766!1 X-Originating-IP: [209.85.160.171] X-StarScan-Version: 6.4.1; banners=-,-,- X-VirusChecked: Checked Received: (qmail 6386 invoked from network); 26 Sep 2011 08:47:03 -0000 Received: from mail-gy0-f171.google.com (HELO mail-gy0-f171.google.com) (209.85.160.171) by server-11.tower-27.messagelabs.com with RC4-SHA encrypted SMTP; 26 Sep 2011 08:47:03 -0000 Received: by gyh3 with SMTP id 3so6417298gyh.30 for <xen-devel@lists.xensource.com>; Mon, 26 Sep 2011 01:47:11 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:from:date:message-id:subject:to:content-type; bh=Oucxlleoz7X1VkiCyOoeEOYKS9w/o+tLi6oRefi2dOI=; b=j8dnkj6xeos660L4X8wOV8CW276Wm6xUVgSDHAGMMc2rMJtuquI7qdpljD8D+Q8w7N tjhxGXmQmlsBB7Pfe7TATiRJBQkj1rTAF89X+wsrKTGZwLXyFLilzeK/S/QscUN//Gso oSaTYrupp5yOeHuItcagwHOPo5rvyDYxzObRo= Received: by 10.101.88.10 with SMTP id q10mr5528450anl.35.1317026831228; Mon, 26 Sep 2011 01:47:11 -0700 (PDT) MIME-Version: 1.0 Received: by 10.100.201.19 with HTTP; Mon, 26 Sep 2011 01:46:51 -0700 (PDT) From: Liwei <xieliwei@gmail.com> Date: Mon, 26 Sep 2011 16:46:51 +0800 Message-ID: <CAPE0SYyHSsgPEUmsiow0pz9KYrGv+M57rMQmhBusw=qNjTAnyw@mail.gmail.com> To: xen-devel <xen-devel@lists.xensource.com> Content-Type: multipart/mixed; boundary=001636ed670c6f5e0704add43467 Subject: [Xen-devel] FATAL PAGE FAULT on Xen-4.1.2-rc3-pre X-BeenThere: xen-devel@lists.xensource.com X-Mailman-Version: 2.1.5 Precedence: list List-Id: Xen developer discussion <xen-devel.lists.xensource.com> List-Unsubscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe> List-Post: <mailto:xen-devel@lists.xensource.com> List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help> List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=subscribe> Sender: xen-devel-bounces@lists.xensource.com Errors-To: xen-devel-bounces@lists.xensource.com --001636ed670c6f5e0704add43467 Content-Type: text/plain; charset=ISO-8859-1 Hello list, Running on the latest xen-4.1 tree in mercurial, the system crashes every 10 hours or so. Attached are samples of two types of crashes I've logged. There's also one case where the whole system stalled (See log file attached, unfortunately the console mangled that log a bit). Hope this helps. --001636ed670c6f5e0704add43467 Content-Type: text/plain; charset=US-ASCII; name="Xen4.1Stalls.txt" Content-Disposition: attachment; filename="Xen4.1Stalls.txt" Content-Transfer-Encoding: base64 X-Attachment-Id: f_gt17p93n0 WzgyNTU1LjQxNjU3NV0gSU5GTzogcmN1X3ByZWVtcHRfc3RhdGUgZGV0ZWN0ZWQgc3RhbGxzIG9u IENQVXMvdGFza3M6IHt9IChkZXRlY3QNCls4MjczNS41MjMyMzddIElORk86IHJjdV9wcmVlbXB0 X3N0YXRlIGRldGVjdGVkIHN0YWxscyBvbiBDUFVzL3Rhc2tzOiB7fSAoZGV0ZWN0DQpbODI5MTUu NjI5ODU1XSBJTkZPOiByY3VfcHJlZW1wdF9zdGF0ZSBkZXRlY3RlZCBzdGFsbHMgb24gQ1BVcy90 YXNrczoge30gKGRldGVjdA0KWzgzMDk1LjczNjQ4Nl0gSU5GTzogcmN1X3ByZWVtcHRfc3RhdGUg ZGV0ZWN0ZWQgc3RhbGxzIG9uIENQVXMvdGFza3M6IHt9IChkZXRlY3QNCls4MzI3NS44NDMxMjNd IElORk86IHJjdV9wcmVlbXB0X3N0YXRlIGRldGVjdGVkIHN0YWxscyBvbiBDUFVzL3Rhc2tzOiB7 fSAoZGV0ZWN0DQpbODM0NTUuOTQ5NzUwXSBJTkZPOiByY3VfcHJlZW1wdF9zdGF0ZSBkZXRlY3Rl ZCBzdGFsbHMgb24gQ1BVcy90YXNrczoge30gKGRldGVjdA0KWzgzNjM2LjA1NjM5MF0gSU5GTzog cmN1X3ByZWVtcHRfc3RhdGUgZGV0ZWN0ZWQgc3RhbGxzIG9uIENQVXMvdGFza3M6IHt9IChkZXRl Y3QNCls4MzgxNi4xNjMwMTNdIElORk86IHJjdV9wcmVlbXB0X3N0YXRlIGRldGVjdGVkIHN0YWxs cyBvbiBDUFVzL3Rhc2tzOiB7fSAoZGV0ZWN0DQpbODM5OTYuMjY5NjQ0XSBJTkZPOiByY3VfcHJl ZW1wdF9zdGF0ZSBkZXRlY3RlZCBzdGFsbHMgb24gQ1BVcy90YXNrczoge30gKGRldGVjdA0KWzg0 MTc2LjM3NjI4MF0gSU5GTzogcmN1X3ByZWVtcHRfc3RhdGUgZGV0ZWN0ZWQgc3RhbGxzIG9uIENQ VXMvdGFza3M6IHt9IChkZXRlY3QNCls4NDM1Ni40ODI5MDNdIElORk86IHJjdV9wcmVlbXB0X3N0 YXRlIGRldGVjdGVkIHN0YWxscyBvbiBDUFVzL3Rhc2tzOiB7fSAoZGV0ZWN0DQpbODQ1MzYuNTg5 NTM0XSBJTkZPOiByY3VfcHJlZW1wdF9zdGF0ZSBkZXRlY3RlZCBzdGFsbHMgb24gQ1BVcy90YXNr czoge30gKGRldGVjdA0KWzg0NzE2LjY5NjE2NV0gSU5GTzogcmN1X3ByZWVtcHRfc3RhdGUgZGV0 ZWN0ZWQgc3RhbGxzIG9uIENQVXMvdGFza3M6IHt9IChkZXRlY3QNCls4NDg5Ni44MDI4MDJdIElO Rk86IHJjdV9wcmVlbXB0X3N0YXRlIGRldGVjdGVkIHN0YWxscyBvbiBDUFVzL3Rhc2tzOiB7fSAo ZGV0ZWN0DQpbODUwNzYuOTA5NDMyXSBJTkZPOiByY3VfcHJlZW1wdF9zdGF0ZSBkZXRlY3RlZCBz dGFsbHMgb24gQ1BVcy90YXNrczoge30gKGRldGVjdA0KWzg1MjU3LjAxNjA1NV0gSU5GTzogcmN1 X3ByZWVtcHRfc3RhdGUgZGV0ZWN0ZWQgc3RhbGxzIG9uIENQVXMvdGFza3M6IHt9IChkZXRlY3QN Cls4NTQzNy4xMjI2ODddIElORk86IHJjdV9wcmVlbXB0X3N0YXRlIGRldGVjdGVkIHN0YWxscyBv biBDUFVzL3Rhc2tzOiB7fSAoZGV0ZWN0DQpbODU2MTcuMjI5MzMyXSBJTkZPOiByY3VfcHJlZW1w dF9zdGF0ZSBkZXRlY3RlZCBzdGFsbHMgb24gQ1BVcy90YXNrczoge30gKGRldGVjdA0KWzg1Nzk3 LjMzNTk2MF0gSU5GTzogcmN1X3ByZWVtcHRfc3RhdGUgZGV0ZWN0ZWQgc3RhbGxzIG9uIENQVXMv dGFza3M6IHt9IChkZXRlY3QNCls4NTk3Ny40NDI1NzhdIElORk86IHJjdV9wcmVlbXB0X3N0YXRl IGRldGVjdGVkIHN0YWxscyBvbiBDUFVzL3Rhc2tzOiB7fSAoZGV0ZWN0DQpbODYxNTcuNTQ5MjE5 XSBJTkZPOiByY3VfcHJlZW1wdF9zdGF0ZSBkZXRlY3RlZCBzdGFsbHMgb24gQ1BVcy90YXNrczog e30gKGRldGVjdA0KWzg2MzM3LjY1NTg0MF0gSU5GTzogcmN1X3ByZWVtcHRfc3RhdGUgZGV0ZWN0 ZWQgc3RhbGxzIG9uIENQVXMvdGFza3M6IHt9IChkZXRlY3QNCls4NjUxNy43NjI0ODBdIElORk86 IHJjdV9wcmVlbXB0X3N0YXRlIGRldGVjdGVkIHN0YWxscyBvbiBDUFVzL3Rhc2tzOiB7fSAoZGV0 ZWN0DQpbODY2OTcuODY5MDgwXSBJTkZPOiByY3VfcHJlZW1wdF9zdGF0ZSBkZXRlY3RlZCBzdGFs bHMgb24gQ1BVcy90YXNrczoge30gKGRldGVjdA0KWzg2ODc3Ljk3NTczOV0gSU5GTzogcmN1X3By ZWVtcHRfc3RhdGUgZGV0ZWN0ZWQgc3RhbGxzIG9uIENQVXMvdGFza3M6IHt9IChkZXRlY3QNCls4 NzA1OC4wODIzNzFdIElORk86IHJjdV9wcmVlbXB0X3N0YXRlIGRldGVjdGVkIHN0YWxscyBvbiBD UFVzL3Rhc2tzOiB7fSAoZGV0ZWN0DQpbODcyMzguMTg4OTk1XSBJTkZPOiByY3VfcHJlZW1wdF9z dGF0ZSBkZXRlY3RlZCBzdGFsbHMgb24gQ1BVcy90YXNrczoge30gKGRldGVjdA0KWzg3NDE4LjI5 NTYzNF0gSU5GTzogcmN1X3ByZWVtcHRfc3RhdGUgZGV0ZWN0ZWQgc3RhbGxzIG9uIENQVXMvdGFz a3M6IHt9IChkZXRlY3QNCls4NzU5OC40MDIyNjddIElORk86IHJjdV9wcmVlbXB0X3N0YXRlIGRl dGVjdGVkIHN0YWxscyBvbiBDUFVzL3Rhc2tzOiB7fSAoZGV0ZWN0DQpbODc3NzguNTA4ODg5XSBJ TkZPOiByY3VfcHJlZW1wdF9zdGF0ZSBkZXRlY3RlZCBzdGFsbHMgb24gQ1BVcy90YXNrczoge30g KGRldGVjdA0KWzg3OTU4LjYxNTUzMl0gSU5GTzogcmN1X3ByZWVtcHRfc3RhdGUgZGV0ZWN0ZWQg c3RhbGxzIG9uIENQVXMvdGFza3M6IHt9IChkZXRlY3QNCls4ODEzOC43MjIxNTRdIElORk86IHJj dV9wcmVlbXB0X3N0YXRlIGRldGVjdGVkIHN0YWxscyBvbiBDUFVzL3Rhc2tzOiB7fSAoZGV0ZWN0 DQpbODgzMTguODI4NzkzXSBJTkZPOiByY3VfcHJlZW1wdF9zdGF0ZSBkZXRlY3RlZCBzdGFsbHMg b24gQ1BVcy90YXNrczoge30gKGRldGVjdA0KWzg4NDk4LjkzNTQwN10gSU5GTzogcmN1X3ByZWVt cHRfc3RhdGUgZGV0ZWN0ZWQgc3RhbGxzIG9uIENQVXMvdGFza3M6IHt9IChkZXRlY3QNCls4ODY3 OS4wNDIwNDNdIElORk86IHJjdV9wcmVlbXB0X3N0YXRlIGRldGVjdGVkIHN0YWxscyBvbiBDUFVz L3Rhc2tzOiB7fSAoZGV0ZWN0DQpbODg4NTkuMTQ4NjgyXSBJTkZPOiByY3VfcHJlZW1wdF9zdGF0 ZSBkZXRlY3RlZCBzdGFsbHMgb24gQ1BVcy90YXNrczoge30gKGRldGVjdA0KWzg5MDM5LjI1NTI5 OV0gSU5GTzogcmN1X3ByZWVtcHRfc3RhdGUgZGV0ZWN0ZWQgc3RhbGxzIG9uIENQVXMvdGFza3M6 IHt9IChkZXRlY3QNCls4OTIxOS4zNjE5MzhdIElORk86IHJjdV9wcmVlbXB0X3N0YXRlIGRldGVj dGVkIHN0YWxscyBvbiBDUFVzL3Rhc2tzOiB7fSAoZGV0ZWN0DQpbODkzOTkuNDY4NTYwXSBJTkZP OiByY3VfcHJlZW1wdF9zdGF0ZSBkZXRlY3RlZCBzdGFsbHMgb24gQ1BVcy90YXNrczoge30gKGRl dGVjdA0KWzg5NTc5LjU3NTE5N10gSU5GTzogcmN1X3ByZWVtcHRfc3RhdGUgZGV0ZWN0ZWQgc3Rh bGxzIG9uIENQVXMvdGFza3M6IHt9IChkZXRlY3QNCls4OTc1OS42ODE4MjJdIElORk86IHJjdV9w cmVlbXB0X3N0YXRlIGRldGVjdGVkIHN0YWxscyBvbiBDUFVzL3Rhc2tzOiB7fSAoZGV0ZWN0DQpb ODk5MzkuNzg4NDU4XSBJTkZPOiByY3VfcHJlZW1wdF9zdGF0ZSBkZXRlY3RlZCBzdGFsbHMgb24g Q1BVcy90YXNrczoge30gKGRldGVjdA0KWzkwMTE5Ljg5NTA4NF0gSU5GTzogcmN1X3ByZWVtcHRf c3RhdGUgZGV0ZWN0ZWQgc3RhbGxzIG9uIENQVXMvdGFza3M6IHt9IChkZXRlY3QNCls5MDMwMC4w MDE3MTRdIElORk86IHJjdV9wcmVlbXB0X3N0YXRlIGRldGVjdGVkIHN0YWxscyBvbiBDUFVzL3Rh c2tzOiB7fSAoZGV0ZWN0DQpbOTA0ODAuMTA4MzQzXSBJTkZPOiByY3VfcHJlZW1wdF9zdGF0ZSBk ZXRlY3RlZCBzdGFsbHMgb24gQ1BVcy90YXNrczoge30gKGRldGVjdA0KWzkwNjYwLjIxNDk4MF0g SU5GTzogcmN1X3ByZWVtcHRfc3RhdGUgZGV0ZWN0ZWQgc3RhbGxzIG9uIENQVXMvdGFza3M6IHt9 IChkZXRlY3QNCls5MDg0MC4zMjE1ODVdIElORk86IHJjdV9wcmVlbXB0X3N0YXRlIGRldGVjdGVk IHN0YWxscyBvbiBDUFVzL3Rhc2tzOiB7fSAoZGV0ZWN0DQpbOTEwMjAuNDI4MjM4XSBJTkZPOiBy Y3VfcHJlZW1wdF9zdGF0ZSBkZXRlY3RlZCBzdGFsbHMgb24gQ1BVcy90YXNrczoge30gKGRldGVj dA0KWzkxMjAwLjUzNDg4NV0gSU5GTzogcmN1X3ByZWVtcHRfc3RhdGUgZGV0ZWN0ZWQgc3RhbGxz IG9uIENQVXMvdGFza3M6IHt9IChkZXRlY3QNCls5MTM4MC42NDE1MTNdIElORk86IHJjdV9wcmVl bXB0X3N0YXRlIGRldGVjdGVkIHN0YWxscyBvbiBDUFVzL3Rhc2tzOiB7fSAoZGV0ZWN0DQpbOTE1 NjAuNzQ4MTI3XSBJTkZPOiByY3VfcHJlZW1wdF9zdGF0ZSBkZXRlY3RlZCBzdGFsbHMgb24gQ1BV cy90YXNrczoge30gKGRldGVjdA0KWzkxNzQwLjg1NDc1OF0gSU5GTzogcmN1X3ByZWVtcHRfc3Rh dGUgZGV0ZWN0ZWQgc3RhbGxzIG9uIENQVXMvdGFza3M6IHt9IChkZXRlY3QNCls5MTkyMC45NjEz ODhdIElORk86IHJjdV9wcmVlbXB0X3N0YXRlIGRldGVjdGVkIHN0YWxscyBvbiBDUFVzL3Rhc2tz OiB7fSAoZGV0ZWN0DQpbOTIxMDEuMDY4MDIzXSBJTkZPOiByY3VfcHJlZW1wdF9zdGF0ZSBkZXRl Y3RlZCBzdGFsbHMgb24gQ1BVcy90YXNrczoge30gKGRldGVjdA0KWzkyMjgxLjE3NDY1OF0gSU5G TzogcmN1X3ByZWVtcHRfc3RhdGUgZGV0ZWN0ZWQgc3RhbGxzIG9uIENQVXMvdGFza3M6IHt9IChk ZXRlY3QNCls5MjQ2MS4yODEzMDRdIElORk86IHJjdV9wcmVlbXB0X3N0YXRlIGRldGVjdGVkIHN0 YWxscyBvbiBDUFVzL3Rhc2tzOiB7fSAoZGV0ZWN0DQpbOTI2NDEuMzg3OTEwXSBJTkZPOiByY3Vf cHJlZW1wdF9zdGF0ZSBkZXRlY3RlZCBzdGFsbHMgb24gQ1BVcy90YXNrczoge30gKGRldGVjdA0K WzkyODIxLjQ5NDU0NV0gSU5GTzogcmN1X3ByZWVtcHRfc3RhdGUgZGV0ZWN0ZWQgc3RhbGxzIG9u IENQVXMvdGFza3M6IHt9IChkZXRlY3QNCls5MzAwMS42MDExODFdIElORk86IHJjdV9wcmVlbXB0 X3N0YXRlIGRldGVjdGVkIHN0YWxscyBvbiBDUFVzL3Rhc2tzOiB7fSAoZGV0ZWN0DQpbOTMxODEu NzA3ODAxXSBJTkZPOiByY3VfcHJlZW1wdF9zdGF0ZSBkZXRlY3RlZCBzdGFsbHMgb24gQ1BVcy90 YXNrczoge30gKGRldGVjdA0KWzkzMzYxLjgxNDQzN10gSU5GTzogcmN1X3ByZWVtcHRfc3RhdGUg ZGV0ZWN0ZWQgc3RhbGxzIG9uIENQVXMvdGFza3M6IHt9IChkZXRlY3QNCls5MzU0MS45MjEwODNd IElORk86IHJjdV9wcmVlbXB0X3N0YXRlIGRldGVjdGVkIHN0YWxscyBvbiBDUFVzL3Rhc2tzOiB7 fSAoZGV0ZWN0DQpbOTM3MjIuMDI3NzAxXSBJTkZPOiByY3VfcHJlZW1wdF9zdGF0ZSBkZXRlY3Rl ZCBzdGFsbHMgb24gQ1BVcy90YXNrczoge30gKGRldGVjdA0KWzkzOTAyLjEzNDMzNl0gSU5GTzog cmN1X3ByZWVtcHRfc3RhdGUgZGV0ZWN0ZWQgc3RhbGxzIG9uIENQVXMvdGFza3M6IHt9IChkZXRl Y3QNCls5NDA4Mi4yNDA5NzFdIElORk86IHJjdV9wcmVlbXB0X3N0YXRlIGRldGVjdGVkIHN0YWxs cyBvbiBDUFVzL3Rhc2tzOiB7fSAoZGV0ZWN0DQpbOTQyNjIuMzQ3NTc1XSBJTkZPOiByY3VfcHJl ZW1wdF9zdGF0ZSBkZXRlY3RlZCBzdGFsbHMgb24gQ1BVcy90YXNrczoge30gKGRldGVjdA0KWzk0 NDQyLjQ1NDIyMF0gSU5GTzogcmN1X3ByZWVtcHRfc3RhdGUgZGV0ZWN0ZWQgc3RhbGxzIG9uIENQ VXMvdGFza3M6IHt9IChkZXRlY3QNCls5NDYyMi41NjA4NDhdIElORk86IHJjdV9wcmVlbXB0X3N0 YXRlIGRldGVjdGVkIHN0YWxscyBvbiBDUFVzL3Rhc2tzOiB7fSAoZGV0ZWN0DQpbOTQ4MDIuNjY3 NDg3XSBJTkZPOiByY3VfcHJlZW1wdF9zdGF0ZSBkZXRlY3RlZCBzdGFsbHMgb24gQ1BVcy90YXNr czoge30gKGRldGVjdA0KWzk0OTgyLjc3NDA3MF0gSU5GTzogcmN1X3ByZWVtcHRfc3RhdGUgZGV0 ZWN0ZWQgc3RhbGxzIG9uIENQVXMvdGFza3M6IHt9IChkZXRlY3QNCls5NTE2Mi44ODA3NTRdIElO Rk86IHJjdV9wcmVlbXB0X3N0YXRlIGRldGVjdGVkIHN0YWxscyBvbiBDUFVzL3Rhc2tzOiB7fSAo ZGV0ZWN0DQpbOTUzNDIuOTg3NDA5XSBJTkZPOiByY3VfcHJlZW1wdF9zdGF0ZSBkZXRlY3RlZCBz dGFsbHMgb24gQ1BVcy90YXNrczoge30gKGRldGVjdA0KWzk1NTIzLjA5NDAwMl0gSU5GTzogcmN1 X3ByZWVtcHRfc3RhdGUgZGV0ZWN0ZWQgc3RhbGxzIG9uIENQVXMvdGFza3M6IHt9IChkZXRlY3QN Cls5NTcwMy4yMDA2NDNdIElORk86IHJjdV9wcmVlbXB0X3N0YXRlIGRldGVjdGVkIHN0YWxscyBv biBDUFVzL3Rhc2tzOiB7fSAoZGV0ZWN0DQpbOTU4ODMuMzA3MjYyXSBJTkZPOiByY3VfcHJlZW1w dF9zdGF0ZSBkZXRlY3RlZCBzdGFsbHMgb24gQ1BVcy90YXNrczoge30gKGRldGVjdA0KWzk2MDYz LjQxMzk4NF0gSU5GTzogcmN1X3ByZWVtcHRfc3RhdGUgZGV0ZWN0ZWQgc3RhbGxzIG9uIENQVXMv dGFza3M6IHt9IChkZXRlY3QNCls5NjI0My41MjA1MjddIElORk86IHJjdV9wcmVlbXB0X3N0YXRl IGRldGVjdGVkIHN0YWxscyBvbiBDUFVzL3Rhc2tzOiB7fSAoZGV0ZWN0DQpbOTY0MjMuNjI3MTU1 XSBJTkZPOiByY3VfcHJlZW1wdF9zdGF0ZSBkZXRlY3RlZCBzdGFsbHMgb24gQ1BVcy90YXNrczog e30gKGRldGVjdA0KWzk2NjAzLjczMzc4NF0gSU5GTzogcmN1X3ByZWVtcHRfc3RhdGUgZGV0ZWN0 ZWQgc3RhbGxzIG9uIENQVXMvdGFza3M6IHt9IChkZXRlY3QNCls5Njc4My44NDA0MjVdIElORk86 IHJjdV9wcmVlbXB0X3N0YXRlIGRldGVjdGVkIHN0YWxscyBvbiBDUFVzL3Rhc2tzOiB7fSAoZGV0 ZWN0DQpbOTY5NjMuOTQ3MDUxXSBJTkZPOiByY3VfcHJlZW1wdF9zdGF0ZSBkZXRlY3RlZCBzdGFs bHMgb24gQ1BVcy90YXNrczoge30gKGRldGVjdA0KWzk3MTQ0LjA1MzY3Nl0gSU5GTzogcmN1X3By ZWVtcHRfc3RhdGUgZGV0ZWN0ZWQgc3RhbGxzIG9uIENQVXMvdGFza3M6IHt9IChkZXRlY3QNCls5 NzMyNC4xNjAzMjhdIElORk86IHJjdV9wcmVlbXB0X3N0YXRlIGRldGVjdGVkIHN0YWxscyBvbiBD UFVzL3Rhc2tzOiB7fSAoZGV0ZWN0DQpbOTc1MDQuMjY2OTQxXSBJTkZPOiByY3VfcHJlZW1wdF9z dGF0ZSBkZXRlY3RlZCBzdGFsbHMgb24gQ1BVcy90YXNrczoge30gKGRldGVjdA0KWzk3Njg0LjM3 MzU3OF0gSU5GTzogcmN1X3ByZWVtcHRfc3RhdGUgZGV0ZWN0ZWQgc3RhbGxzIG9uIENQVXMvdGFz a3M6IHt9IChkZXRlY3QNCls5Nzg2NC40ODAyMTZdIElORk86IHJjdV9wcmVlbXB0X3N0YXRlIGRl dGVjdGVkIHN0YWxscyBvbiBDUFVzL3Rhc2tzOiB7fSAoZGV0ZWN0DQpbOTgwNDQuNTg2ODMwXSBJ TkZPOiByY3VfcHJlZW1wdF9zdGF0ZSBkZXRlY3RlZCBzdGFsbHMgb24gQ1BVcy90YXNrczoge30g KGRldGVjdA0KWzk4MjI0LjY5MzUyN10gSU5GTzogcmN1X3ByZWVtcHRfc3RhdGUgZGV0ZWN0ZWQg c3RhbGxzIG9uIENQVXMvdGFza3M6IHt9IChkZXRlY3QNCls5ODQwNC44MDAwNzFdIElORk86IHJj dV9wcmVlbXB0X3N0YXRlIGRldGVjdGVkIHN0YWxscyBvbiBDUFVzL3Rhc2tzOiB7fSAoZGV0ZWN0 DQpbOTg1ODQuOTA2Njc4XSBJTkZPOiByY3VfcHJlZW1wdF9zdGF0ZSBkZXRlY3RlZCBzdGFsbHMg b24gQ1BVcy90YXNrczoge30gKGRldGVjdA0KWzk4NzY1LjAxMzM1M10gSU5GTzogcmN1X3ByZWVt cHRfc3RhdGUgZGV0ZWN0ZWQgc3RhbGxzIG9uIENQVXMvdGFza3M6IHt9IChkZXRlY3QNCls5ODk0 NS4xMTk5ODRdIElORk86IHJjdV9wcmVlbXB0X3N0YXRlIGRldGVjdGVkIHN0YWxscyBvbiBDUFVz L3Rhc2tzOiB7fSAoZGV0ZWN0DQpbOTkxMjUuMjI2NjE3XSBJTkZPOiByY3VfcHJlZW1wdF9zdGF0 ZSBkZXRlY3RlZCBzdGFsbHMgb24gQ1BVcy90YXNrczoge30gKGRldGVjdA0KWzk5MzA1LjMzMzI0 Nl0gSU5GTzogcmN1X3ByZWVtcHRfc3RhdGUgZGV0ZWN0ZWQgc3RhbGxzIG9uIENQVXMvdGFza3M6 IHt9IChkZXRlY3QNCls5OTQ4NS40Mzk4NzZdIElORk86IHJjdV9wcmVlbXB0X3N0YXRlIGRldGVj dGVkIHN0YWxscyBvbiBDUFVzL3Rhc2tzOiB7fSAoZGV0ZWN0DQpbOTk2NjUuNTQ2NTE2XSBJTkZP OiByY3VfcHJlZW1wdF9zdGF0ZSBkZXRlY3RlZCBzdGFsbHMgb24gQ1BVcy90YXNrczoge30gKGRl dGVjdA0KWzk5ODQ1LjY1MzE0Ml0gSU5GTzogcmN1X3ByZWVtcHRfc3RhdGUgZGV0ZWN0ZWQgc3Rh bGxzIG9uIENQVXMvdGFza3M6IHt9IChkZXRlY3QNClsxMDAwMjUuNzU5NzgxXSBJTkZPOiByY3Vf cHJlZW1wdF9zdGF0ZSBkZXRlY3RlZCBzdGFsbHMgb24gQ1BVcy90YXNrczoge30gKGRldGVjDQpb MTAwMjA1Ljg2NjQwMF0gSU5GTzogcmN1X3ByZWVtcHRfc3RhdGUgZGV0ZWN0ZWQgc3RhbGxzIG9u IENQVXMvdGFza3M6IHt9IChkZXRlYw0KWzEwMDM4NS45NzMwMzldIElORk86IHJjdV9wcmVlbXB0 X3N0YXRlIGRldGVjdGVkIHN0YWxscyBvbiBDUFVzL3Rhc2tzOiB7fSAoZGV0ZWMNClsxMDA1NjYu MDc5NjY5XSBJTkZPOiByY3VfcHJlZW1wdF9zdGF0ZSBkZXRlY3RlZCBzdGFsbHMgb24gQ1BVcy90 YXNrczoge30gKGRldGVjDQpbMTAwNzQ2LjE4NjI5MV0gSU5GTzogcmN1X3ByZWVtcHRfc3RhdGUg ZGV0ZWN0ZWQgc3RhbGxzIG9uIENQVXMvdGFza3M6IHt9IChkZXRlYw0KWzEwMDkyNi4yOTI5NDBd IElORk86IHJjdV9wcmVlbXB0X3N0YXRlIGRldGVjdGVkIHN0YWxscyBvbiBDUFVzL3Rhc2tzOiB7 fSAoZGV0ZWMNClsxMDExMDYuMzk5NTY0XSBJTkZPOiByY3VfcHJlZW1wdF9zdGF0ZSBkZXRlY3Rl ZCBzdGFsbHMgb24gQ1BVcy90YXNrczoge30gKGRldGVjDQpbMTAxMjg2LjUwNjE5Nl0gSU5GTzog cmN1X3ByZWVtcHRfc3RhdGUgZGV0ZWN0ZWQgc3RhbGxzIG9uIENQVXMvdGFza3M6IHt9IChkZXRl Yw0KWzEwMTQ2Ni42MTI4MjRdIElORk86IHJjdV9wcmVlbXB0X3N0YXRlIGRldGVjdGVkIHN0YWxs cyBvbiBDUFVzL3Rhc2tzOiB7fSAoZGV0ZWMNClsxMDE2NDYuNzE5NDQ0XSBJTkZPOiByY3VfcHJl ZW1wdF9zdGF0ZSBkZXRlY3RlZCBzdGFsbHMgb24gQ1BVcy90YXNrczoge30gKGRldGVjDQpbMTAx ODI2LjgyNjA3Ml0gSU5GTzogcmN1X3ByZWVtcHRfc3RhdGUgZGV0ZWN0ZWQgc3RhbGxzIG9uIENQ VXMvdGFza3M6IHt9IChkZXRlYw0KWzEwMjAwNi45MzI3MThdIElORk86IHJjdV9wcmVlbXB0X3N0 YXRlIGRldGVjdGVkIHN0YWxscyBvbiBDUFVzL3Rhc2tzOiB7fSAoZGV0ZWMNClsxMDIxODcuMDM5 MzM1XSBJTkZPOiByY3VfcHJlZW1wdF9zdGF0ZSBkZXRlY3RlZCBzdGFsbHMgb24gQ1BVcy90YXNr czoge30gKGRldGVjDQpbMTAyMzY3LjE0NTk2M10gSU5GTzogcmN1X3ByZWVtcHRfc3RhdGUgZGV0 ZWN0ZWQgc3RhbGxzIG9uIENQVXMvdGFza3M6IHt9IChkZXRlYw0KWzEwMjU0Ny4yNTI1OTVdIElO Rk86IHJjdV9wcmVlbXB0X3N0YXRlIGRldGVjdGVkIHN0YWxscyBvbiBDUFVzL3Rhc2tzOiB7fSAo ZGV0ZWMNClsxMDI3MjcuMzU5MjI4XSBJTkZPOiByY3VfcHJlZW1wdF9zdGF0ZSBkZXRlY3RlZCBz dGFsbHMgb24gQ1BVcy90YXNrczoge30gKGRldGVjDQpbMTAyOTA3LjQ2NTg1OV0gSU5GTzogcmN1 X3ByZWVtcHRfc3RhdGUgZGV0ZWN0ZWQgc3RhbGxzIG9uIENQVXMvdGFza3M6IHt9IChkZXRlYw0K WzEwMjkxMi40MTE3NzNdIE91dCBvZiBtZW1vcnk6IEtpbGwgcHJvY2VzcyAzNTE0IChiYXNoKSBz Y29yZSAyIG9yIHNhY3JpZmljZSBjaGkNClsxMDI5MTIuNDE5MTYwXSBLaWxsZWQgcHJvY2VzcyAz NjE0IChzdSkgdG90YWwtdm06NjAzNDRrQiwgYW5vbi1yc3M6MGtCLCBmaWxlLXJzDQpbMTAyOTIy LjkyMjgxNl0gT3V0IG9mIG1lbW9yeTogS2lsbCBwcm9jZXNzIDM1MTQgKGJhc2gpIHNjb3JlIDIg b3Igc2FjcmlmaWNlIGNoaQ0KWzEwMjkyMi45MzAyMDJdIEtpbGxlZCBwcm9jZXNzIDM1MTQgKGJh c2gpIHRvdGFsLXZtOjI2Njg0a0IsIGFub24tcnNzOjRrQiwgZmlsZS0NClsxMDI5MjMuMzgxMDI0 XSBPdXQgb2YgbWVtb3J5OiBLaWxsIHByb2Nlc3MgMjA4MSAocnBjYmluZCkgc2NvcmUgMSBvciBz YWNyaWZpY2UNClsxMDI5MjMuMzg4Njc1XSBLaWxsZWQgcHJvY2VzcyAyMDgxIChycGNiaW5kKSB0 b3RhbC12bToxODkyNGtCLCBhbm9uLXJzczowa0IsIGZpDQpbMTAyOTIzLjQyNTk4OV0gT3V0IG9m IG1lbW9yeTogS2lsbCBwcm9jZXNzIDIwOTcgKHJwYy5zdGF0ZCkgc2NvcmUgMSBvciBzYWNyaWZp Yw0KWzEwMjkyMy40MzM4MTldIEtpbGxlZCBwcm9jZXNzIDIwOTcgKHJwYy5zdGF0ZCkgdG90YWwt dm06MjMzMDBrQiwgYW5vbi1yc3M6MGtCLA0KWzEwMjkyMy40NzAxMzRdIE91dCBvZiBtZW1vcnk6 IEtpbGwgcHJvY2VzcyAyMTEzIChycGMuaWRtYXBkKSBzY29yZSAxIG9yIHNhY3JpZmkNClsxMDI5 MjMuNDc4MDUyXSBLaWxsZWQgcHJvY2VzcyAyMTEzIChycGMuaWRtYXBkKSB0b3RhbC12bTozMTUw NGtCLCBhbm9uLXJzczowa0IsDQpbMTAyOTI0LjE4NTQwNl0gT3V0IG9mIG1lbW9yeTogS2lsbCBw cm9jZXNzIDIzMDQgKHJzeXNsb2dkKSBzY29yZSAxIG9yIHNhY3JpZmljZQ0KWzEwMjkyNC4xOTMx NDddIEtpbGxlZCBwcm9jZXNzIDIzMDQgKHJzeXNsb2dkKSB0b3RhbC12bTo1MzI1MmtCLCBhbm9u LXJzczowa0IsIGYNClsxMDI5NDIuMDc2NzQ0XSBPdXQgb2YgbWVtb3J5OiBLaWxsIHByb2Nlc3Mg MjM3MyAoYWNwaWQpIHNjb3JlIDEgb3Igc2FjcmlmaWNlIGNoDQpbMTAyOTQyLjA4NDIxOF0gS2ls bGVkIHByb2Nlc3MgMjM3MyAoYWNwaWQpIHRvdGFsLXZtOjQxMDhrQiwgYW5vbi1yc3M6MGtCLCBm aWxlLQ0KWzEwMzA4Ny4wMTI3NTddIElORk86IHRhc2sgYWNwaWQ6MjM3MyBibG9ja2VkIGZvciBt b3JlIHRoYW4gMTIwIHNlY29uZHMuDQpbMTAzMDg3LjAxOTI0Nl0gImVjaG8gMCA+IC9wcm9jL3N5 cy9rZXJuZWwvaHVuZ190YXNrX3RpbWVvdXRfc2VjcyIgZGlzYWJsZXMgdGhpcw0KWzEwMzA4Ny41 ODM1NThdIElORk86IHJjdV9wcmVlbXB0X3N0YXRlIGRldGVjdGVkIHN0YWxscyBvbiBDUFVzL3Rh c2tzOiB7fSAoZGV0ZWMNClsxMDMyMDcuMjExMDY2XSBJTkZPOiB0YXNrIGFjcGlkOjIzNzMgYmxv Y2tlZCBmb3IgbW9yZSB0aGFuIDEyMCBzZWNvbmRzLg0KWzEwMzIwNy4yMTc1OTVdICJlY2hvIDAg PiAvcHJvYy9zeXMva2VybmVsL2h1bmdfdGFza190aW1lb3V0X3NlY3MiIGRpc2FibGVzIHRoaXMN ClsxMDMyNjcuNzY2ODY0XSBJTkZPOiByY3VfcHJlZW1wdF9zdGF0ZSBkZXRlY3RlZCBzdGFsbHMg b24gQ1BVcy90YXNrczoge30gKGRldGVjDQpbMTAzMzI3LjI4ODA2MF0gSU5GTzogdGFzayBhY3Bp ZDoyMzczIGJsb2NrZWQgZm9yIG1vcmUgdGhhbiAxMjAgc2Vjb25kcy4NClsxMDMzMjcuMjk0NTQ5 XSAiZWNobyAwID4gL3Byb2Mvc3lzL2tlcm5lbC9odW5nX3Rhc2tfdGltZW91dF9zZWNzIiBkaXNh YmxlcyB0aGlzDQpbMTAzNDQ3LjQyMDg5NF0gSU5GTzogdGFzayBhY3BpZDoyMzczIGJsb2NrZWQg Zm9yIG1vcmUgdGhhbiAxMjAgc2Vjb25kcy4NClsxMDM0NDcuNDU3MjcxXSAiZWNobyAwID4gL3By b2Mvc3lzL2tlcm5lbC9odW5nX3Rhc2tfdGltZW91dF9zZWNzIiBkaXNhYmxlcyB0aGlzDQpbMTAz NDQ3LjkzMTczNV0gSU5GTzogcmN1X3ByZWVtcHRfc3RhdGUgZGV0ZWN0ZWQgc3RhbGxzIG9uIENQ VXMvdGFza3M6IHt9IChkZXRlYw0KWzEwMzU2Ny42Mjc3MzBdIElORk86IHRhc2sgYWNwaWQ6MjM3 MyBibG9ja2VkIGZvciBtb3JlIHRoYW4gMTIwIHNlY29uZHMuDQpbMTAzNTY3LjYzNDIxOF0gImVj aG8gMCA+IC9wcm9jL3N5cy9rZXJuZWwvaHVuZ190YXNrX3RpbWVvdXRfc2VjcyIgZGlzYWJsZXMg dGhpcw0KWzEwMzYyOC4wMzU3MTBdIElORk86IHJjdV9wcmVlbXB0X3N0YXRlIGRldGVjdGVkIHN0 YWxscyBvbiBDUFVzL3Rhc2tzOiB7fSAoZGV0ZWMNClsxMDM2ODcuNjY3MDQ5XSBJTkZPOiB0YXNr IGFjcGlkOjIzNzMgYmxvY2tlZCBmb3IgbW9yZSB0aGFuIDEyMCBzZWNvbmRzLg0KWzEwMzY4Ny42 NzM1MzddICJlY2hvIDAgPiAvcHJvYy9zeXMva2VybmVsL2h1bmdfdGFza190aW1lb3V0X3NlY3Mi IGRpc2FibGVzIHRoaXMNCjw0PlsxMDM3NzguMDg2MzM5XSAgPEVPST4gWzEwMzgwNy43MTE5Mzhd IElORk86IHRhc2sgYWNwaWQ6MjM3MyBibG9ja2VkIGZvciBtb3JlDQpbMTAzODA3LjcxODQzOF0g ImVjaG8gMCA+IC9wcm9jL3N5cy9rZXJuZWwvaHVuZ190YXNrX3RpbWVvdXRfc2VjcyIgZGlzYWJs ZXMgdGhpcw0KWzEwMzgwOC4xOTI2MTZdIElORk86IHJjdV9wcmVlbXB0X3N0YXRlIGRldGVjdGVk IHN0YWxscyBvbiBDUFVzL3Rhc2tzOiB7fSAoZGV0ZWMNClsxMDM5MjcuODgzMzI2XSBJTkZPOiB0 YXNrIGFjcGlkOjIzNzMgYmxvY2tlZCBmb3IgbW9yZSB0aGFuIDEyMCBzZWNvbmRzLg0KWzEwMzky Ny44ODk4MTNdICJlY2hvIDAgPiAvcHJvYy9zeXMva2VybmVsL2h1bmdfdGFza190aW1lb3V0X3Nl Y3MiIGRpc2FibGVzIHRoaXMNClsxMDM5ODguMzcwOTY3XSBJTkZPOiByY3VfcHJlZW1wdF9zdGF0 ZSBkZXRlY3RlZCBzdGFsbHMgb24gQ1BVcy90YXNrczoge30gKGRldGVjDQpbMTA0MDQ4LjA4MjQ2 OF0gSU5GTzogdGFzayBhY3BpZDoyMzczIGJsb2NrZWQgZm9yIG1vcmUgdGhhbiAxMjAgc2Vjb25k cy4NClsxMDQwNDguMDg4OTU2XSAiZWNobyAwID4gL3Byb2Mvc3lzL2tlcm5lbC9odW5nX3Rhc2tf dGltZW91dF9zZWNzIiBkaXNhYmxlcyB0aGlzDQpbMTA0MTY4LjUxOTExMF0gSU5GTzogcmN1X3By ZWVtcHRfc3RhdGUgZGV0ZWN0ZWQgc3RhbGxzIG9uIENQVXMvdGFza3M6IHt9IChkZXRlYw0KWzEw NDE2OC41Nzg5NTBdIElORk86IHRhc2sgYWNwaWQ6MjM3MyBibG9ja2VkIGZvciBtb3JlIHRoYW4g MTIwIHNlY29uZHMuDQpbMTA0MTY4LjU4NTQzNl0gImVjaG8gMCA+IC9wcm9jL3N5cy9rZXJuZWwv aHVuZ190YXNrX3RpbWVvdXRfc2VjcyIgZGlzYWJsZXMgdGhpcw0KWzEwNDM0OC42MzIyNTldIElO Rk86IHJjdV9wcmVlbXB0X3N0YXRlIGRldGVjdGVkIHN0YWxscyBvbiBDUFVzL3Rhc2tzOiB7fSAo ZGV0ZWMNClsxMDQ1MjguNzM4ODYwXSBJTkZPOiByY3VfcHJlZW1wdF9zdGF0ZSBkZXRlY3RlZCBz dGFsbHMgb24gQ1BVcy90YXNrczoge30gKGRldGVjDQpbMTA0NzA4LjkyODgxMl0gSU5GTzogcmN1 X3ByZWVtcHRfc3RhdGUgZGV0ZWN0ZWQgc3RhbGxzIG9uIENQVXMvdGFza3M6IHt9IChkZXRlYw0K WzEwNDg4OS4wMzU0NTVdIElORk86IHJjdV9wcmVlbXB0X3N0YXRlIGRldGVjdGVkIHN0YWxscyBv biBDUFVzL3Rhc2tzOiB7fSAoZGV0ZWMNClsxMDUwNjkuMTQyMDg5XSBJTkZPOiByY3VfcHJlZW1w dF9zdGF0ZSBkZXRlY3RlZCBzdGFsbHMgb24gQ1BVcy90YXNrczoge30gKGRldGVjDQpbMTA1MjQ5 LjI1OTYwN10gSU5GTzogcmN1X3ByZWVtcHRfc3RhdGUgZGV0ZWN0ZWQgc3RhbGxzIG9uIENQVXMv dGFza3M6IHt9IChkZXRlYw0KWzEwNTQyOS4zNjUzNDldIElORk86IHJjdV9wcmVlbXB0X3N0YXRl IGRldGVjdGVkIHN0YWxscyBvbiBDUFVzL3Rhc2tzOiB7fSAoZGV0ZWMNClsxMDU2MDkuNDcxOTc5 XSBJTkZPOiByY3VfcHJlZW1wdF9zdGF0ZSBkZXRlY3RlZCBzdGFsbHMgb24gQ1BVcy90YXNrczog e30gKGRldGVjDQpbMTA1Nzg5LjU3ODYxMV0gSU5GTzogcmN1X3ByZWVtcHRfc3RhdGUgZGV0ZWN0 ZWQgc3RhbGxzIG9uIENQVXMvdGFza3M6IHt9IChkZXRlYw0KWzEwNTk2OS43MTA0MzRdIElORk86 IHJjdV9wcmVlbXB0X3N0YXRlIGRldGVjdGVkIHN0YWxscyBvbiBDUFVzL3Rhc2tzOiB7fSAoZGV0 ZWMNCjw0PlsxMDU5NzMuNDE0NDM1XSBsb3dtZW1fcmVzZXJ2ZVtdOiAwIDAgMCAwWzEwNjE0OS44 Mjk4MTVdIElORk86IHJjdV9wcmVlbXB0X3N0ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ZWQgYnkgMywgdD03MDk2MzI3IGppZmZpZXMpDQpbMTA2MzI5LjkzNTE2OF0gSU5GTzogcmN1X3By ZWVtcHRfc3RhdGUgZGV0ZWN0ZWQgc3RhbGxzIG9uIENQVXMvdGFza3M6IHt9IChkZXRlYw0KWzEw NjUxMC4wNDY5MzldIElORk86IHJjdV9wcmVlbXB0X3N0YXRlIGRldGVjdGVkIHN0YWxscyBvbiBD UFVzL3Rhc2tzOiB7fSAoZGV0ZWMNClsxMDY2OTAuMjA0MDQ0XSBJTkZPOiByY3VfcHJlZW1wdF9z dGF0ZSBkZXRlY3RlZCBzdGFsbHMgb24gQ1BVcy90YXNrczoge30gKGRldGVjDQpbMTA2ODcwLjMx MTU2M10gSU5GTzogcmN1X3ByZWVtcHRfc3RhdGUgZGV0ZWN0ZWQgc3RhbGxzIG9uIENQVXMvdGFz a3M6IHt9IChkZXRlYw0KWzEwNzA1MC40Mjc4MDRdIElORk86IHJjdV9wcmVlbXB0X3N0YXRlIGRl dGVjdGVkIHN0YWxscyBvbiBDUFVzL3Rhc2tzOiB7fSAoZGV0ZWMNClsxMDcyMzAuNTMyMjE2XSBJ TkZPOiByY3VfcHJlZW1wdF9zdGF0ZSBkZXRlY3RlZCBzdGFsbHMgb24gQ1BVcy90YXNrczoge30g KGRldGVjDQpbMTA3NDEwLjY1MTU2NF0gSU5GTzogcmN1X3ByZWVtcHRfc3RhdGUgZGV0ZWN0ZWQg c3RhbGxzIG9uIENQVXMvdGFza3M6IHt9IChkZXRlYw0KWzEwNzU5MC43NTQ5MTVdIElORk86IHJj dV9wcmVlbXB0X3N0YXRlIGRldGVjdGVkIHN0YWxscyBvbiBDUFVzL3Rhc2tzOiB7fSAoZGV0ZWMN ClsxMDc3NzAuOTE2MzE2XSBJTkZPOiByY3VfcHJlZW1wdF9zdGF0ZSBkZXRlY3RlZCBzdGFsbHMg b24gQ1BVcy90YXNrczoge30gKGRldGVjDQpbMTA3OTUxLjA3NTMwMV0gSU5GTzogcmN1X3ByZWVt cHRfc3RhdGUgZGV0ZWN0ZWQgc3RhbGxzIG9uIENQVXMvdGFza3M6IHt9IChkZXRlYw0KWzEwODEz MS4yMjEwNjRdIElORk86IHJjdV9wcmVlbXB0X3N0YXRlIGRldGVjdGVkIHN0YWxscyBvbiBDUFVz L3Rhc2tzOiB7fSAoZGV0ZWMNClsxMDgzMTEuMzM4NTYyXSBJTkZPOiByY3VfcHJlZW1wdF9zdGF0 ZSBkZXRlY3RlZCBzdGFsbHMgb24gQ1BVcy90YXNrczoge30gKGRldGVjDQpbMTA4NDkxLjQ0NDcz NF0gSU5GTzogcmN1X3ByZWVtcHRfc3RhdGUgZGV0ZWN0ZWQgc3RhbGxzIG9uIENQVXMvdGFza3M6 IHt9IChkZXRlYw0KWzEwODY3MS41NTEzNjVdIElORk86IHJjdV9wcmVlbXB0X3N0YXRlIGRldGVj dGVkIHN0YWxscyBvbiBDUFVzL3Rhc2tzOiB7fSAoZGV0ZWM= --001636ed670c6f5e0704add43467 Content-Type: text/plain; charset=US-ASCII; name="Xen4.1Trace.txt" Content-Disposition: attachment; filename="Xen4.1Trace.txt" Content-Transfer-Encoding: base64 X-Attachment-Id: f_gt17p9411 KFhFTikgLS0tLVsgWGVuLTQuMS4yLXJjMy1wcmUgIHg4Nl82NCAgZGVidWc9biAgVGFpbnRlZDog ICAgQyBdLS0tLQ0KKFhFTikgLS0tLVsgWGVuLTQuMS4yLXJjMy1wcmUgIHg4Nl82NCAgZGVidWc9 biAgVGFpbnRlZDogICAgQyBdLS0tLQ0KKFhFTikgQ1BVOiAgICA0DQooWEVOKSBDUFU6ICAgIDAN CihYRU4pIFJJUDogICAgZTAwODpbPGZmZmY4MmM0ODAxODFiZjI+XVJJUDogICAgZTAwODpbPGZm ZmY4MmM0ODAxODFiZjI+XSB4ODZfZW11bGF0ZSsweDJlZTIvMHgxMDkgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgODZf NjQgIGRlYnVnPW4gIFRhaW50ZWQ6ICAgIEMgXS0tLS0NCihYRU4pDQooWEVOKSBSRkxBR1M6IDAw MDAwMDAwMDAwMTAyMDIgICAgeDg2X2VtdWxhdGUrMHgyZWUyLzB4MTA5YjBDUFU6ICAgIDINCihY RU4pDQooWEVOKSBSRkxBR1M6IDAwMDAwMDAwMDAwMTAyMDIgICBSSVA6ICAgIGUwMDg6WzxmZmZm ODJjNDgwMTgxYmYyPl0tLS0tWyBYZW4tNC4xLjItcmMzLXByZSAgeDg2XzY0ICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg IC0tDQooWEVOKSBDT05URVhUOiBoeXBlcnZpc29yDQooWEVOKSByYXg6IDAwMDAwMDAwMDAwMDAw MDAgICByYng6IDAwMDAwMDAwMDAwMDAwMDAgICByY3g6IDAwMDAwMDAwMDAwMDAwMDQNCihYRU4p IHJkeDogMDAwMDAwMDAwMDAwMDAwMCAgIHJzaTogZmZmZmZmZmZmZjVmYjM4MCAgIHJkaTogMDAw MDAwMDAwMDAwMDAwMQ0KKFhFTikgQ09OVEVYVDogaHlwZXJ2aXNvcg0KKFhFTikgcmJwOiAwMDAw MDAwMDAwMDAwMDA4ICAgcnNwOiBmZmZmODJjNDgwMjdmN2M4ICAgcjg6ICBmZmZmODJjNDgwMjdm YmU4DQooWEVOKSAgeDg2X2VtdWxhdGUrMHgyZWUyLzB4MTA5YjBDUFU6ICAgIDENCihYRU4pIHI5 OiAgMDAwMDAwMDAwMDAwMDAwMCAgIHIxMDogMDAwMDAwMDAwMDAwMDAwMCAgIHIxMTogMDAwMDAw MDAwMDAwMDAwMA0KKFhFTikNCihYRU4pIFJGTEFHUzogMDAwMDAwMDAwMDAxMDIwMiAgIHJheDog MDAwMDAwMDAwMDAwMDAwMCAgIHJieDogMDAwMDAwMDAwMDAwMDAwMCAgIHJjeDogMDAwMDAwMDAw MDANCihYRU4pIHIxMjogMDAwMDAwMDAwMDAwMDA4OSAgIHIxMzogZmZmZjgyYzQ4MDI3ZmJlOCAg IHIxNDogZmZmZjgyYzQ4MDIzNWVjMA0KKFhFTikgcjE1OiAwMDAwMDAwMDAwMDAwMDAwICAgY3Iw OiAwMDAwMDAwMDgwMDUwMDNiICAgY3I0OiAwMDAwMDAwMDAwMDAyNmYwDQooWEVOKSBjcjM6IDAw MDAwMDAyNWM3M2UwMDAgICBjcjI6IGZmZmY4MmM0N2Y4N2FkNTgNCihYRU4pIENPTlRFWFQ6IGh5 cGVydmlzb3INCihYRU4pIC0tLS1bIFhlbi00LjEuMi1yYzMtcHJlICB4ODZfNjQgIGRlYnVnPW4g IFRhaW50ZWQ6ICAgIEMgXS0tLS0NCihYRU4pIHJheDogMDAwMDAwMDAwMDAwMDAwMCAgIHJieDog MDAwMDAwMDAwMDAwMDAwMCAgIHJjeDogMDAwMDAwMDAwMDAwMDAwNA0KKFhFTikgcmR4OiAwMDAw MDAwMDAwMDAwMDAwICAgcnNpOiBmZmZmZmYwMGZlZTAwMzEwICAgcmRpOiAwMDAwMDAwMDAwMDAw MDAxDQooWEVOKSByZHg6IDAwMDAwMDAwMDAwMDAwMDQgICByc2k6IGZmZmZmODgwMDY3ODIwZDgg ICByZGk6IDAwMDAwMDAwMDAwMDAwMDENCihYRU4pIFJJUDogICAgZTAwODpbPGZmZmY4MmM0ODAx ODFiZjI+XXJicDogMDAwMDAwMDAwMDAwMDAwOCAgIHJzcDogZmZmZjgzMDQ1MTc3ZjdjOCAgIHI4 OiAgZmZmZjgNCihYRU4pICB4ODZfZW11bGF0ZSsweDJlZTIvMHgxMDliMA0KKFhFTikgUkZMQUdT OiAwMDAwMDAwMDAwMDEwMjAyICAgZHM6IDAwMDAgICBlczogMDAwMCAgIGZzOiAwMDAwICAgZ3M6 IDAwMDAgICBzczogMDAwMCAgIGNzOiBlMDA4DQooWEVOKSBDT05URVhUOiBoeXBlcnZpc29yDQoo WEVOKSBYZW4gc3RhY2sgdHJhY2UgZnJvbSByc3A9ZmZmZjgyYzQ4MDI3ZjdjODoNCihYRU4pICAg cmF4OiAwMDAwMDAwMDAwMDAwMDAwICAgcmJ4OiAwMDAwMDAwMDAwMDAwMDAwICAgcmN4OiAwMDAw MDAwMDAwMDAwMDA0DQooWEVOKSByZHg6IDAwMDAwMDAwMDAwMDAwMDQgICByc2k6IGZmZmZmZjAw ZjMwMDAwZDggICByZGk6IDAwMDAwMDAwMDAwMDAwMDENCihYRU4pIHI5OiAgMDAwMDAwMDAwMDAw MDAwMCAgIHIxMDogMDAwMDAwMDAwMDAwMDAwMCAgIHIxMTogMDAwMDAwMDAwMDAwMDAwMA0KKFhF TikgcmJwOiAwMDAwMDAwMDAwMDAwMDA4ICAgcnNwOiBmZmZmODMwNDUxNzlmNzU4ICAgcjg6ICBm ZmZmODMwNDUxNzlmYjc4DQooWEVOKSByMTI6IDAwMDAwMDAwMDAwMDAwODkgICByMTM6IGZmZmY4 MzA0NTE3N2ZiZTggICByMTQ6IGZmZmY4MmM0ODAyMzVlYzANCihYRU4pIHI5OiAgMDAwMDAwMDAw MDAwMDAwMCAgIHIxMDogMDAwMDAwMDAwMDAwMDAwMCAgIHIxMTogMDAwMDAwMDAwMDAwMDAwMA0K KFhFTikgcjE1OiAwMDAwMDAwMDAwMDAwMDAwICAgY3IwOiAwMDAwMDAwMDgwMDUwMDNiICAgY3I0 OiAwMDAwMDAwMDAwMDAyNmYwDQooWEVOKSByMTI6IDAwMDAwMDAwMDAwMDAwYzcgICByMTM6IGZm ZmY4MzA0NTE3OWZiNzggICByMTQ6IGZmZmY4MmM0ODAyMzVlYzANCihYRU4pIENQVTogICAgNw0K KFhFTikgY3IzOiAwMDAwMDAwNDVmNGZjMDAwICAgY3IyOiBmZmZmODIwNTUwNTdmY2U4DQooWEVO KSByMTU6IDAwMDAwMDAwMDAwMDAwMDAgICBjcjA6IDAwMDAwMDAwODAwNTAwM2IgICBjcjQ6IDAw MDAwMDAwMDAwMDI2ZjANCihYRU4pIGRzOiAwMDAwICAgZXM6IDAwMDAgICBmczogMDAwMCAgIGdz OiAwMDAwICAgc3M6IDAwMDAgICBjczogZTAwOA0KKFhFTikgIDAwMDAwMDAwMDAwMDAwMDByYnA6 IDAwMDAwMDAwMDAwMDAwMDggICByc3A6IGZmZmY4MzA0NTE3YWY3NTggICByODogIGZmZmY4MzA0 NTE3YWZiNzgNCihYRU4pIFJJUDogICAgZTAwODpbPGZmZmY4MmM0ODAxODFiZjI+XXI5OiAgMDAw MDAwMDAwMDAwMDAwMCAgIHIxMDogMDAwMDAwMDAwMDAwMDAwMCAgIHIxMTogMDAwMDANCihYRU4p IHIxMjogMDAwMDAwMDAwMDAwMDBjNyAgIHIxMzogZmZmZjgzMDQ1MTdhZmI3OCAgIHIxNDogZmZm ZjgyYzQ4MDIzNWVjMA0KKFhFTikgWGVuIHN0YWNrIHRyYWNlIGZyb20gcnNwPWZmZmY4MzA0NTE3 N2Y3Yzg6DQooWEVOKSAgICAwMDAwMDAwMTAwMDAwMDAwIHg4Nl9lbXVsYXRlKzB4MmVlMi8weDEw OWIwIDAwZmY4MzA0MDAwMDAwMDAgZmZmZmZmMDAwMDAwMDAwMGNyMzogMDAwMDAwICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgIGZlODAwMA0KKFhFTikNCihYRU4pIFJGTEFHUzogMDAwMDAwMDAwMDAxMDIwMiAgICAwMDAw MDAwMTAwMDAwMDAwcjE1OiAwMDAwMDAwMDAwMDAwMDAwICAgY3IwOiAwMDAwMDAwMDgwMDUwMDNi DQooWEVOKSAgZmZmZjgyYzQ4MDI3ZjkwMGRzOiAwMDAwICAgZXM6IDAwMDAgICBmczogMDAwMCAg IGdzOiAwMDAwICAgc3M6IDAwMDAgICBjczogZTAwOA0KKFhFTikgQ09OVEVYVDogaHlwZXJ2aXNv cg0KKFhFTikgIGZmZmZmODgwMDAwMDAwMDBjcjM6IDAwMDAwMDA0NWYxMzEwMDAgICBjcjI6IGZm ZmY4MjA1NDQ3YWZhNDANCihYRU4pIGRzOiAwMDAwICAgZXM6IDAwMDAgICBmczogMDAwMCAgIGdz OiAwMDAwICAgc3M6IDAwMDAgICBjczogZTAwOA0KKFhFTikgcmF4OiAwMDAwMDAwMDAwMDAwMDAw ICAgcmJ4OiAwMDAwMDAwMDAwMDAwMDAwICAgcmN4OiAwMDAwMDAwMDAwMDAwMDA0DQooWEVOKQ0K KFhFTikgICAgMDAwMDAwMDAwMDAwMDBkNlhlbiBzdGFjayB0cmFjZSBmcm9tIHJzcD1mZmZmODMw NDUxNzlmNzU4Og0KKFhFTikgICByZHg6IDAwMDAwMDAwMDAwMDAwMDAgICByc2k6IGZmZmZmZjAw ZmVlMDAzMTAgICByZGk6IDAwMDAwMDAwMDAwMDAwMDENCihYRU4pICAwMDAwMDAwMDAwMDAwMGMw IGZmZmY4MmM0ODAxNGE1NGEgZmZmZjgyYzQ4MDI3ZjkwMCAwMDAwMDAwMDAwMDAwMDAwIDAwMDAw MDAwMDAwMDAwMDAgZmZmZjggICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgcm9tIHJzcD1mZmZmODMwNDUxN2FmNzU4Og0K KFhFTikNCihYRU4pICAgcmJwOiAwMDAwMDAwMDAwMDAwMDA4ICAgcnNwOiBmZmZmODMwNDUxNzU3 N2M4ICAgcjg6ICBmZmZmODMwNDUxNzU3YmU4DQooWEVOKSAgMDAwMDAwMDAwMDAwMDAwMHI5OiAg MDAwMDAwMDAwMDAwMDAwMCAgIHIxMDogMDAwMDAwMDAwMDAwMDAwMCAgIHIxMTogMDAwMDAwMDAw MDAwMDAwMA0KKFhFTikgIDAwMDAwMDAxMDAwMDAwMDAgMDAwMDAwMDEwMDAwMDAwNSBmZmZmODJj NDgwMjdmYTA4IDAwMDAwMDAwMDAwMDAwMDAgZmZmZmZmZmZmZjVmYjEwMCBmZmZmOCAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICByMTI6IDAwMDAwMDAwMDAwMDAwODkgICByMTM6IGZmZmY4MzA0NTE3NTdiZTggICByMTQ6 IGZmZmY4MmM0ODAyMzVlYzANCihYRU4pDQooWEVOKQ0KKFhFTikgICAgMDAwMDAwMDIwMDAwMDBk NiAwMDAwMDAwMDAwMDAwMDEwDQooWEVOKSAgIHIxNTogMDAwMDAwMDAwMDAwMDAwMCAgIGNyMDog MDAwMDAwMDA4MDA1MDAzYiAgIGNyNDogMDAwMDAwMDAwMDAwMjZmMA0KKFhFTikgIGZmZmY4MmM0 ODAxNzJhMTIgMDAwMDAwMDAwMDAwMDBlZSAwMDAwMDAwMDAwMDAwMDAyY3IzOiAwMDAwMDAwNDVm MjIyMDAwICAgY3IyOiBmZmZmODIwNTUwNQ0KKFhFTikgIDAwMDAwMDAwMDAwMDAwZWUgMDAwMDAw MDAwMDAwMDAwNCBmZmZmODMwNDUxNzdmYWYwZHM6IDAwMDAgICBlczogMDAwMCAgIGZzOiAwMDAw ICAgZ3M6IDAwMA0KKFhFTikNCihYRU4pICAgWGVuIHN0YWNrIHRyYWNlIGZyb20gcnNwPWZmZmY4 MzA0NTE3NTc3Yzg6DQooWEVOKSAgICBmZmZmODMwNDUxNzdmYTA4IDAwZmY4MzA0MDAwMDAwMDAg MDAwMDAwMDAwMDAwMDAwMiBmZmZmODMwNDUxNzdmODc4IDAwMDAwMDAwMDAwMDAwMDQgMDAwICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgIDEwIGZmZmZmODgwMDAwMDAwMDAgMDAwMDAwZDYwMDAwMDAwNCAwMDAwMDAwMDAw MDAwMDAxIGZmZmY4MzA0NTE3YWZhODANCihYRU4pICAgIDAwMDAwMDAwMDAwMDAwMDggZmZmZjgz MDQ1MTc5ZmE4MCAwMDAwMDBkNjAwMDAwMDA0DQooWEVOKQ0KKFhFTikgICAgZmZmZjgzMDQ1MTc5 Zjk5OCBmZmZmZjg4MDA2NzgyMDAwIGZmZmZmZmZmZmY1ZmIzODAgZmZmZjgzMDQ1MTc5ZjgwOCAw MDAwMDAwMDAwMDAwMDA4DQooWEVOKQ0KKFhFTikgICAgMDAwMDAwMDAwMDAwMDAyOCBmZmZmZmYw MGZlZTAwMzEwIGZmZmY4MzA0NTE3YWY5OTggZmZmZjgzMDQ1MTdhZjgwOCAwMDAwMDAwMDAwMDAw MDAwIDAwZiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICBkNiAwMDAwMDAwMTAwMDAwMDAwIGZmZmY4MmM0MDAwMDAwMjgN CihYRU4pICAgIDAwMDAwMGVlMDAwMDAwMDQgMDAwMDAwMDBmMzAwMDBjMCAwMDAwMDAwMTAwMDAw MDAwIDAwMDAwMDAwMDAwMDAwMDYgMDAwMDAwZWUwMDAwMDAwNCAwMDAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgMTgg ZmZmZjgzMDQ1MTc1N2FmMA0KKFhFTikNCihYRU4pICAgIDAwMDAwMDAwMDAwMDAwODENCihYRU4p ICAgIDAwMDAwMDAwMDAwMDAwMDggMDAwMDAwMDAwMDAwMDAxNiBmZmZmODMwNDUxNzU3YTA4IDAw MDAwMDAwMWFhYmZlMDAgZmZmZjgzMDQ1MTc1Nzg3OCAwMDAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgMDYNCihYRU4p ICAgIGZmZmZmZjAwMDAwMDAwMTAgZmZmZmZmMDBmZWQwMDAwMSBmZmZmZjg4MDA2NzgyMGQ4IGZm ZmZmZjAwMDIyYzUwMDAgMDAwMDAwZDYwMDAwMDAwNCAwMDANCihYRU4pICAgIDAwMDAwMDAwMDAw MDAwMDgNCihYRU4pICAgIDAwMDAwMDAwMDA1YWNlMDcgMDAwMDAwMDAwMDAwMDAwNA0KKFhFTikg ICAgZmZmZmZmMDBmMzAwMDBkOCAwMGZmODMwNDAwMDAwMDAwIDAwMDAwMDAwMDAwMDAwZjggMDBm ZjgzMDQwMDAwMDAwMCAwMDAwMDAwMDAwMDAwMDA4DQooWEVOKSAgICBmZmZmZmYwMGZlZTAwMzEw IDAwMDAwMDAwMDAwMDAwMTAgMDAwMDAwMDAyNTAxMjgyMCAwMGZmZmZmZjAwMDAwMDAwIDAwMDAw MDAwMDAwMDAwMDAgMDAwICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgIDVhDQooWEVOKSAgICAwMDAwMDAwMTAwMDAwMDAw IDAwMDAwMDAxMDAwMDAwMDANCihYRU4pDQooWEVOKQ0KKFhFTikgICAgMDAwMDAwMDAwMDAwMDA4 MSAwMDAwMDAwMDAwMDAwMDAyIDAwMDAwMDAwMDAwMDAxZjQgZmZmZmZmMDAwMDAwMDA4MCBmZmZm ZmY4MDAwNWIyNTAwIGZmZiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICA0MCAwMDAwMDAwMDAwMDAwMGMwIGZmZmZmZjgw MDAwNzk4ZTAgMDAwMDAwMDAwMDAwMDAwMCAwMDAwMDAwMDAwMDAwMDAwIGZmZmZmODgwMDY3ODIw YzAgZmZmZjg4MDA3DQooWEVOKSAgICAwMDAwMDAwMDAwMDAwMDA0IDAwMDAwMDAwZjMwMDAwMDAN CihYRU4pICAgIDAwMDAwMDAwZjMwMDAwYzAgMDAwMDAwMDAwMDAwMDAwMSAwMDAwMDAwMDAwMDAw MDAxIDAwMDAwMDAwMDAwMDAwMDAgZmZmZmZmMDBmMzAwMDAwMQ0KKFhFTikgICAgZmZmZmZmMDBm MzAwMDBjMCAwMDAwMDAwMDAwMDAwMDAwIDAwMDAwMDAwZjMwMDAwYzAgMDAwMDAwMDAwMDAwMDAw MA0KKFhFTikgICAgMDAwMDAwMDAwMDAwMDAwMSBmZmZmZmZmZjgxMTYzZjU4DQooWEVOKSAgICBm ZmZmZmZmZjgxYTExZmEwIDAwMDAwMDAwMDAwMDAwMDMgZmZmZmZmZmY4MTE2M2Y1MA0KKFhFTikg ICAgMDAwMDAwMDAwMDAwMDAwMiAwMDAwMDAwMDAwMDAwMDAxIDAwMDAwMDAwMDAwMDAwMDggMDAw MDAwMDAwMDAwMDBmOCAwMDAwMDAwMDAwMDAwMDAwIGZmZiAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICBjMA0KKFhFTikN CihYRU4pICAgIDAwMDAwMDAwMDAwMDAwMDAgMDAwMDAwMDAwMDAwMDAyMCBmZmZmZmZmZjgxMDIw MTEwDQooWEVOKSAgICAwMDAwMDAwMDA4MDAwMDAwIDAwMDAwMDAwMDAwMDAwMDIgMDAwMDAwMDA3 MzUzMjQ1MCAwMDAwMDAwMDAwMDZhNzgzIGZmZmZmZjAwMDIyYzFlMDAgMDAwICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg IDAwIDAwMDAwMDAwMDAwMDAwMDINCihYRU4pICAgIGZmZmZmZjgwMDAwNmY5MDAgMDAwMDAwMDA4 MDAwMDA4MA0KKFhFTikgICAgMDAwMDAwMDAwMDAwMDAwMSAwMDAwMDAwMDAwMDAwMzgwIDAwMDAw MDAwMDAxY2ZkMjAgMDAwMDAwYjEwMDAwMDAwMCAwMDAwMDAwMGZmZmRiMDAwIGZmZg0KKFhFTikg ICAgZmZmZmZmMDBmMzAwMDBkOA0KKFhFTikgICAgZmZmZmZmZmY4MTAyNTE2OCAwMDAwMDAwMDAw MDAwMDAwIGZmZmZmZmZmODAyNGExNjAgMDAwMDAwMDAwMDAwMDAwMCBmZmZmZmE4MDA4NTFiNjQw IDAwMCAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAwMCAwMDAwMDAwMDAwMDAwMDAwDQooWEVOKSAgICAwMDAwMDAwMDAw MDAwMDAwIGZmZmZmZmZmODExNjE5ZDggMDAwMDAwMDAwMDIwMDI4MyAwMDAwMDAwMDAwMDAwMWY0 IDAwMDAwMDAwMDgwMDAwMDAgZmZmDQooWEVOKSAgICBmZmZmZmE4MDA3ZTU2YjYwIDAwMDAwMDAw MDAwMDAwMDINCihYRU4pDQooWEVOKSAgICBmZmZmZjg4MDBjYjRjYzI4LS0tLVsgWGVuLTQuMS4y LXJjMy1wcmUgIHg4Nl82NCAgZGVidWc9biAgVGFpbnRlZDogICAgQyBdLS0tLQ0KKFhFTikNCihY RU4pICAgIGZmZmZmZjgwMDA1YjI1ZjAgMDAwMDAwMDAwMDAwMDBkOCBmZmZmZmE4MDA3ZWQ4MDAw LS0tLVsgWGVuLTQuMS4yLXJjMy1wcmUgIHg4Nl82NCAgZGVidWcNCihYRU4pICAwMDAwMDAwMDAy MDAwMDAwIDAwMDAwMDAwMDAwMTAwOTIgZmZmZmZmMDBmMzAwMDAwMCBmZmZmZmYwMGYzMDAwMGMw DQooWEVOKSAgICBmZmZmZmYwMGZlZTAwMDAwDQooWEVOKSAgIENQVTogICAgMw0KKFhFTikgUklQ OiAgICBlMDA4Ols8ZmZmZjgyYzQ4MDE4MWJmMj5dIGZmZmZmODgwMDY3ODIwMDAgMDAwMDAwMDAw MDAwMDAwMCBmZmZmODgwMDdhNWJkZTUwIDAwMDAwMCAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAwMDAwMDAwMDAwMDAw MDAwDQooWEVOKSAgICBmZmZmZmY4MDAwNWIyNWYwIDAwMDAwMDAwMDAwMDAwMDAgMDAwMDAwMDAw MDAwMDAwMCAwMDAwMDBhOTAwMDAwMDAwDQooWEVOKSAgICB4ODZfZW11bGF0ZSsweDJlZTIvMHgx MDliMCAwMDAwMDAwMDgwMDAwMDgwIDAwMDAwMDAwMDAwMDAwMDENCihYRU4pIFJGTEFHUzogMDAw MDAwMDAwMDAxMDIwMiAgICBmZmZmZmZmZjgwM2YxZTZlIDAwMDAwMDAwMDAwMDAwMDAgZmZmZmZh ODAwNzRlODljMCAwMDAwMDAwMDAwMDANCihYRU4pICAgIDAwMDAwMDAwMDAwMDAwZjgNCihYRU4p ICAgIDAwMDAwMDAwMDAwMDAwZjhDT05URVhUOiBoeXBlcnZpc29yDQooWEVOKQ0KKFhFTikgICBy YXg6IDAwMDAwMDAwMDAwMDAwMDAgICByYng6IDAwMDAwMDAwMDAwMDAwMDAgICByY3g6IDAwMDAw MDAwMDAwMDAwMDQNCihYRU4pICAwMDAwMDBiMTAwMDAwMDAwcmR4OiAwMDAwMDAwMDAwMDAwMDAw ICAgcnNpOiBmZmZmZjg4MDA2NzgyMDIwICAgcmRpOiAwMDAwMDAwMDAwMDAwMDAxDQooWEVOKSBy YnA6IDAwMDAwMDAwMDAwMDAwMDggICByc3A6IGZmZmY4MzA0NTE3OGY3NTggICByODogIGZmZmY4 MzA0NTE3OGZiNzgNCihYRU4pIHI5OiAgMDAwMDAwMDAwMDAwMDAwMCAgIHIxMDogMDAwMDAwMDAw MDAwMDAwMCAgIHIxMTogMDAwMDAwMDAwMDAwMDAwMA0KKFhFTikgIGZmZmZmYTgwMDdjZjUxYTAg MDAwMDAwMDAwMDAxMDAwMiAwMDAwMDBiMTAwMDAwMDAwQ1BVOiAgICA1DQooWEVOKSAgZmZmZmZm ZmY4MTAyNTE2MiBmZmZmZmY4MDAwMDU2OWMwIDAwMDAwMDAwMDAwMDAwMDAgNmQ4ODQ1Mjg0OWRk Y2JkNyBmZmZmZmZmZjgwYTMzOWYxUklQOiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIGZmZmZmZmZmODBhMzM5ZjEN CihYRU4pICAgIDM2MWM2YzA1YTgyYmU4NGQgZmZmZjgzMDQyNDljMGMzMCAwMDAwMDAwMDAwODAw MDAxIDIwOGMyOGMwZjFiYjMxYmJyMTI6IDAwMDAwMDAwMDAwMDAwODkgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgMTQ6 IGZmZmY4MmM0ODAyMzVlYzANCihYRU4pICA0ZWFjODlhZThkZTEyODYwIDAwMDAwMDAwMDAwMDAw MDAgMDAwMDAwMDAwMDAwMDAwMHIxNTogMDAwMDAwMDAwMDAwMDAwMCAgIGNyMDogMDAwMDAwMDA4 MDAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgMA0KKFhFTikgIDAwMDAwMGE5MDAwMDAwMDANCihYRU4pICAgIGZmZmY4 MzA0MjQ5YzBjMzANCihYRU4pICAgIDAwMDAwMDAwMDAwMDAwMDANCihYRU4pICAgIGZmZmZmODgw MDVjOGM2MWRjcjM6IDAwMDAwMDAyOWJjNmQwMDAgICBjcjI6IDAwMDAwMDAwMDI0MmUwNDANCihY RU4pIGRzOiAwMDAwICAgZXM6IDAwMDAgICBmczogMDAwMCAgIGdzOiAwMDAwICAgc3M6IDAwMDAg ICBjczogZTAwOA0KKFhFTikgIDAwMDAwMDAwMDAwMDAwMDAgMDAwMDAwMDAwMDAwMTAyNSAwMDAw MDAwMDAwMDAwMDAxIDAwMDAwMDAwMDAwMDAwMDEgMDAwMDAwMDAwMDAxMDAwNg0KKFhFTikgICBY ZW4gc3RhY2sgdHJhY2UgZnJvbSByc3A9ZmZmZjgzMDQ1MTc4Zjc1ODoNCihYRU4pICAgIGZmZmZm ZmZmODAzZjFlNjgNCihYRU4pICAgIHg4Nl9lbXVsYXRlKzB4MmVlMi8weDEwOWIwIDAwMDAwMDAw MDAwMTAwMDYgMDAwMDAwMDAwMDIxMDI0NiBmZmZmZjg4MDBjYjRjYmQ4IGZmZmY4MzA0NTEgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgMDAwMDAwMDAwMDAwIGZmZmY4MmM0ODAxZjJkNWEgMDAwMDAwMDAwMDgwMDAwMSBh NjUwYWQxOTY4NmRiNDNjIDAwMDAwMDAwMDAwMDAwMDANCihYRU4pDQooWEVOKSBSRkxBR1M6IDAw MDAwMDAwMDAwMTAyMDIgICAgZmZmZmZmODAwMDA3OThlMCBmZmZmZmY4MDAwMDZmOTAwIDAwMDAw MDAwMDAwMDAwMDAgYTcxMmU1MDE2ODJkDQooWEVOKQ0KKFhFTikgICByYXg6IDAwMDAwMDAwMDAw MDAwMDAgICByYng6IDAwMDAwMDAwMDAwMDAwMDAgICByY3g6IDAwMDAwMDAwMDAwMDAwMDQNCihY RU4pIHJkeDogMDAwMDAwMDAwMDAwMDAwMCAgIHJzaTogZmZmZmY4ODAwNjc4NTgxOCAgIHJkaTog MDAwMDAwMDAwMDAwMDAwMQ0KKFhFTikNCihYRU4pICAgIGZmZmY4MzA0NTE3MjdmMTAgMDAwMDAw MDQwMDAwMDAwMCAwMDAwMDAwMDAwMDAwMDAwIDAwMDAwMDAxMDAwMDAwMDAgZTdlYTg3ZWMwNTEx MGQ5MCBmZmYgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgODMNCihYRU4pICAgIDAwMDAwMDAwMDAwMDAwMDAgMDAwMDAw MDMwMDAwMDAwOQ0KKFhFTikgICAgMDAwMDAwMDAwMDAwMDNmMSBlZGMxZTE4OWE5MzlhMDA4IDAw MDAwMDAwMDAwMDAwMDINCihYRU4pICAgIDBjOWVkMWEyZWZjMjdhYzIgMDAwMDAwMDAwMDAwMDBk NiBmZmZmODJjNDgwMjdmOGUwIGZmZmY4MzAyNWM3NDQwMDAgMTk4ZThiMDdkOGQyMTkxYSAwMDAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgMDANCihYRU4pICAgIDAwMDAwMDAwMDAwMDAwMDRyYnA6IDAwMDAwMDAwMDAw MDAwMDggICByc3A6IGZmZmY4MzA0NTE3NmY3NTggICByODogIGZmZmY4MzA0NTE3NmZiNzgNCihY RU4pICBmZmZmODMwNDUxNzhmYTgwIGZmZmZmODgwMDVjOGM2MTMgZTdlMjk3NmUyNTE4MGQ5MCAw MDAwMDAwMDAwMDAxMDI1DQooWEVOKQ0KKFhFTikgICAgMDAwMDAwMDAwMDAwMDAwMSAwMDAwMDAw MDAwMDAwMDAxIGZmZmY4MmM0ODAxZjJkNWENCihYRU4pICAgIDFkOWU5MGMzZWY0MDdhYzYgMDAw MDAwMDQwMDAwMDAwMSAwMDAwMDAwMDAwMDAwMDAwIDAwMDAwMDAwMDAwMDEwMjUgMDAwMDAwMDAw MDA3OTVhNSAwMDAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgZmYgZGM0MGM1M2FlZTM5YTQ5MyBmZmZmODMwMjE1OTkx ZjQwDQooWEVOKSAgICAzOTVlNzVmM2M5NjlkMTEwIGZmZmY4MzA0NTE3OGY5OTggMDAwMDAwMDAw MDgwMDAwMSBmZmZmODMwNDUxNzhmODA4IDAwMDAwMDAwMDAwMDAwMTAgMDAwICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg IGY0DQooWEVOKSAgICBmZmZmODJjNDgwMjdmYjA0IDAwMDAwMDAwMDAyYTYzYTUgZmZmZmZmZmZm ZjVmYjM4MCBlNWI5MDdkOTVhMzU3ZGUzIGZmZmY4MzAyMTU5OTFmNDANCihYRU4pDQooWEVOKSAg ICBmZmZmODJjNDgwMWYyMTE1IDAwMDAwMDAwMDAyMGZmYjIgMDAwMDAwMDAwMDAwMDAwOCAwMDAw MDAwMDAwMDAwMDAxIGZmZmZmODgwMDY3ODIwMjAgMDAwICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIDVhIDE5OGVkYjA3 ZGNkMjFkMWENCihYRU4pICAgIDAwMDAwMDAwMDAwMDAwMDByOTogIDAwMDAwMDAwMDAwMDAwMDAg ICByMTA6IDAwMDAwMDAwMDAwMDAwMDAgICByMTE6IDAwMDAwMDAwMDAwMDAwMDANCihYRU4pICAw MDAwMDAwMDAwMDAwMDAwDQooWEVOKSAgICAwMDAwMDAwMDAwMDAwMDAwcjEyOiAwMDAwMDAwMDAw MDAwMDg5ICAgcjEzOiBmZmZmODMwNDUxNzZmYjc4ICAgcjE0OiBmZmZmODJjNDgwMjM1ZWMwDQoo WEVOKSByMTU6IDAwMDAwMDAwMDAwMDAwMDAgICBjcjA6IDAwMDAwMDAwODAwNTAwMzMgICBjcjQ6 IDAwMDAwMDAwMDAwMDI2ZjANCihYRU4pIGNyMzogMDAwMDAwMDI5NDY4ZTAwMCAgIGNyMjogMDAw MDAwMDAwMjQyZTA0MA0KKFhFTikNCihYRU4pICAgIDAwMDAwMDAwMDAwMDAwMDAgMDAwMDAwMDMw MDAwMDAwOSAwMDAwMDAwNDAwMDAwMDAyIGZmZmZmZmZmZmZmZmZmZmYNCihYRU4pICAgIDAwMDAw MDAwMDAwMDAwMDAgMDAwMDAwMDAwMDAwMDAwMmRzOiAwMDAwICAgZXM6IDAwMDAgICBmczogMDAw MCAgIGdzOiAwMDAwICAgc3M6IDAwMDANCihYRU4pICBmZmZmZmZmZjgwYTMzOWViWGVuIHN0YWNr IHRyYWNlIGZyb20gcnNwPWZmZmY4MzA0NTE3NmY3NTg6DQooWEVOKSAgICAwMDAwMDAwMDAwMDAw MDAzIGZmZmY4MzA0NWY0NjAwMDANCihYRU4pICAgIDAwZmY4MzA0MDAwMDAwMDAgZmZmZmZmZmY4 MGEzMzllYiBmZmZmODMwNDAwMDAwMDAwIGZmZmY4MzA0NTE3MjdmMTAgMDAwMDAwMDAwMDAwMDAw MCAwMDAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgMDANCihYRU4pICAgIDAwMDAwMDAzMDAwMDAwMDAgZmZmZmZmMDAw MDAwMDA1OCBmZmZmODMwNDUxNzI3ZjEwDQooWEVOKSAgICAwMDAwMDAwMDAwMDAwMDAwIDAwMDAw MDAwMDA4MDAwMDENCihYRU4pICAgIDAwMDAwMDAwMDAwMDAwMDMgZmZmZjgzMDQ1MTcyN2YxMCAw MDAwMDAwMDAwMDAwMDAzIGZmZmZmODgwMDY3ODIwMDgNCihYRU4pICAgIDAwMDAwMDAwMDAwMDAw MDMgMDAwMDAwMDAwMDAwMGEzMyAwMDAwMDAwMGYzMDAwMDA4IGZmZmY4MzA0NTE3NmY5ZDAgMDAw MDAwMDAwMDAwMDAwMQ0KKFhFTikgICAgMDAwMDAwMDEwMDAwMDAwMCBmZmZmZmZmZmZmNWZiMzAw IDAwMDAwMDAwMDAwMDAwMDAgMDAwMDAwMDAwMDAwMDAwMCAwMDAwMDAwMDAwMDAwM2YxIDAwMCAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAwMSBmZmZmODMwMjliOWNhMDAwIDAwMDAwMDAwMDAwMDAwMDAgZmZmZjgyYzQ4 MDFmMmQ1YQ0KKFhFTikgICAgMDAwMDAwMDQwMDAwMDAwMQ0KKFhFTikgIGZmZmZmODAwMDM2NDFl ODAgMDAwMDAwMDAwMDgwMDAwMSBmZmZmODJjNDgwMWYyZDVhIGZmZmZmODAwMDM2NGZjYzANCihY RU4pICAgIDAwMDAwMDAwMDAwMDAxYjIgZmZmZmY4MDAwMGI5Y2M1OFhlbiBjYWxsIHRyYWNlOg0K KFhFTikgICAgWzxmZmZmODJjNDgwMTgxYmYyPl0gZmZmZjgzMDQ1MTcyN2YxMCB4ODZfZW11bGF0 ZSsweDJlZTIvMHgxMDliMA0KKFhFTikNCihYRU4pICAgIDAwMDAwMDAwMDAwMDAwMDAgMDAwMDAw MDQwMDAwMDAwMSAwMDAwMDAwMDAwMDAwMDAwIGZmZmZmODAwMDBiOWM1MjBbPGZmZmY4MmM0ODAx NGE1NGE+XSAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgb25faW50ZXJydXB0KzB4MmEvMHgzMA0KKFhFTikNCihYRU4p ICAgIDAwMDAwMDAwMDgyYTAwMDAgMDAwMDAwMDAwMDAwMDNmMVs8ZmZmZjgyYzQ4MDFmMmQ1YT5d DQooWEVOKSAgICAwMDAwMDAwMDAwMDAxNDJjDQooWEVOKSAgICBmZmZmODMwNDUxN2FmYTk0DQoo WEVOKSAgICAwMDAwMDAwMDAwMDAwMGQ2IGVwdF9nZXRfZW50cnkrMHgxMWEvMHgyYTANCihYRU4p ICAgICAwMDAwMDAwMGZlZTAwMzgwIDAwMDAwMDAwMDAwMDAwMDEgZmZmZjgzMDQ1MTc2ZmE4MCAw MDAwMDAwNDAwMDAwMDAwWzxmZmZmODJjNDgwMWYyMTE1Pl0gICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgX2dmbl80X2xl dmVscysweDM1NS8weDRlMA0KKFhFTikgICAgIGZmZmZmZjAwZjMwMDAwZDggZmZmZjgyYzQ4MDFm MjExNQ0KKFhFTikgICAgMDAwMDAwMDAwMjAwMDAwMCAwMDAwMDAwMDAwMDAwMDAwIDAwMDAwMDAw MDAwMDAwMDAgMDAwMDAwMDAwMDAwMDAwMiAwMDAwMDAwMDAwMjBmZmIyIDAwMA0KKFhFTikgICAg MDAwMDAwMDAwMDAwMDAwMFs8ZmZmZjgyYzQ4MDFmMmQ1YT5dIDAwMDAwMDAwMDAwMDAwMDAgMDAw MDAwMDAwMDAwMDAwMCBlcHRfZ2V0X2VudHJ5KzB4MQ0KKFhFTikNCihYRU4pICAgIGZmZmY4MzA0 NTE3OWZhOTQgMDAwMDAwMDA4MDA4MDdmZiAwMDAwMDAwMDAwMmM4NTJhIGZmZmZmODAwMDBiOWM1 MjAgMDAwMDAwMDAwMDAwMDAwMCBmZmYNCihYRU4pICAgIGZmZmY4MmM0ODAxZjIxMTVbPGZmZmY4 MmM0ODAxYTUzNjM+XSAwMDAwMDAwMDAwMDAwMDAwIF9faHZtX2NvcHkrMHgyZDMvMHg0NDANCihY RU4pICAgICAwMDAwMDAwMDAwMDAwMDAyIGZmZmZmODgwMDY3ODIwMDAgMDAwMDAwMDAwMDAwMDAw MFs8ZmZmZjgyYzQ4MDFhMjA1Zj5dIDAwMDAwMDAzMDAwMDAwMDkNCihYRU4pDQooWEVOKSAgICAw MDAwMDAwMDAwMDAwMDBhIDAwMDAwMDAwMDAwMDAwMDIgaHZtX2VtdWxhdGVfb25lKzB4Y2YvMHgx YjANCihYRU4pICAgIFs8ZmZmZjgyYzQ4MDFhYzcxMz5dIDAwMDAwMDAwMDAwMDAwMDAgMDAwMDAw MDAwMDAwMDAwMCAwMDAwMDAwMDAwMDAwMDAwIDAwMDAwMDAwMDAwMDAwMDANCihYRU4pICAgIDAw MDAwMDAwMDAwMDAwMDAgZmZmZmZhODAwN2VkODAwMCBmZmZmODMwNDUxNzU3OGM4DQooWEVOKQ0K KFhFTikgICAgMDAwMDAwMDAwMDAwMGEzMw0KKFhFTikgICAgMDAwMDAwYTkwMDAwMDAwMCBmZmZm ODMwNDVmNDYwMDAwIGZmZmY4MzA0NTE3NmY5OTggZmZmZjgzMDQ1MTc2ZjgwOCBmZmZmZjg4MDA1 Yzk2YWE2IDAwMCAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAzMyAwMDAwMDAwMDAwMDAwMDAyIGZmZmY4MzA0MDAwMDAw MTAgMDAwMDAwMDAwMDAwMDAwMSAwMDAwMDBkNjAwMDAwMDA0IDAwMDAwMDAwMDAwMDAwMDANCihY RU4pICAgIGhhbmRsZV9tbWlvKzB4NjMvMHgxYTANCihYRU4pICAgICAwMDAwMDAwMDAwMDAwMDAx IGZmZmY4MmM0ODAxZjJkNWENCihYRU4pICAwMDAwMDAwMDAwMDAwMDAwDQooWEVOKSAgICBmZmZm ODJjNDgwMWYyZDVhDQooWEVOKQ0KKFhFTikgIDAwMDAwMDAwMDAwMTAyNDZYZW4gY2FsbCB0cmFj ZToNCihYRU4pICAgICBmZmZmZjgwMDAwYjljNGEwWzxmZmZmODJjNDgwMTgxYmYyPl0gMDAwMDAw MDAwMDAwMDAwMCB4ODZfZW11bGF0ZSsweDJlZTIvMHgxMDliMA0KKFhFTikgICAgWzxmZmZmODJj NDgwMTA3MjM3Pl0gZmZmZjgyYzQ4MDFmMmQ1YSAwMDAwMDAwMDAwMDAwMDA4DQooWEVOKSAgICBm ZmZmZjg4MDA2Nzg1ODE4IDAwZmY4MzA0MDAwMDAwMDAgMDAwMDAwMDQwMDAwMDAwMSAwMDAwMDAw MTAwMDAwMDAwIG5vdGlmeV92aWFfeGVuX2V2ZW50DQooWEVOKSAgICBYZW4gY2FsbCB0cmFjZToN CihYRU4pICAgIFs8ZmZmZjgyYzQ4MDE4MWJmMj5dWzxmZmZmODJjNDgwMWE2MmQ2Pl0gNjFhODY1 YTg2OWRkZGJkN1s8ZmZmZjgyYzQ4MDFmMmQ1YT5dDQooWEVOKSAgICAwMDAwMDAwMDAwMDAwMDAw IHg4Nl9lbXVsYXRlKzB4MmVlMi8weDEwOWIwDQooWEVOKSAgICAgMjMwYzY0MTRlODY5ZTg0ZFs8 ZmZmZjgyYzQ4MDFmMmQ1YT5dIDY4OGMyYzg0NzFmYTExYmYgNGFhYzA5MmMwZGU0MjgyMCBlcHRf Z2V0X2VudHJ5KzB4DQooWEVOKSAgICAgMDAwMDAwMDAwMDAwMDAwMCBodm1fc2VuZF9hc3Npc3Rf cmVxKzB4NzYvMHhlMA0KKFhFTikNCihYRU4pICAgWzxmZmZmODJjNDgwMWYyMTE1Pl0gZmZmZmY4 ODAwNWM5NmFhMyAwMDAwMDAwNDAwMDAwMDAwIGZmZmY4MzAyMTU5OTFmNDANCihYRU4pICAgIGVw dF9nZXRfZW50cnkrMHgxMWEvMHgyYTANCihYRU4pICAgICAwMDAwMDAwMDA4MDAwMDAwWzxmZmZm ODJjNDgwMWYyMTE1Pl1bPGZmZmY4MmM0ODAxM2JkZDk+XSAwMDAwMDAwMDAwMDAwYTMzIDAwMDAw MDAwMDA4MDAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgMHgzNTUvMHg0ZTANCihYRU4pICAgICBmZmZmODMwMjE1OTkx ZjQwWzxmZmZmODJjNDgwMWYyZDVhPl0gaHZtX2RwY2lfZW9pKzB4NTkvMHgxYTANCihYRU4pICAg ICBmZmZmZmYwMDAwMDAwMDgxIDAwMDAwMDAwMDAwMDAwMDANCihYRU4pICAgIGhhcF9ndmFfdG9f Z2ZuXzRfbGV2ZWxzKzB4MzU1LzB4NGUwDQooWEVOKSAgICAgMDAwMDAwMDAwMDAwMTQyY1s8ZmZm ZjgyYzQ4MDFmMmQ1YT5dIDAwMDAwMDAwMDAyMGZmYTggZXB0X2dldF9lbnRyeSsweDExYS8weDJh MA0KKFhFTikgICAgIDAwMDAwMDAwMDAwMDAwMDEgMDAwMDAwMDAwMDAwMDAwMVs8ZmZmZjgyYzQ4 MDFiNDk1Nj5dIGVwdF9nZXRfZW50cnkrMHgxMWEvMHgyYTANCihYRU4pDQooWEVOKSAgIFs8ZmZm ZjgyYzQ4MDFhNTM2Mz5dIHZsYXBpY19oYXNfcGVuZGluZ19pcnErMHgyNi8weDYwDQooWEVOKSAg ICAgZmZmZjgzMDQ1MTc1N2IwNCAwMDAwMDAwMDAwMDAwMDAwWzxmZmZmODJjNDgwMWE1MzYzPl0g ZmZmZjgyYzQ4MDFmMmQ1YVs8ZmZmZjgyYzQ4MDFiMjNjICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIG9weSsweDJkMy8w eDQ0MA0KKFhFTikNCihYRU4pICAgIHZpb2FwaWNfdXBkYXRlX0VPSSsweGRmLzB4ZjANCihYRU4p ICAgIFs8ZmZmZjgyYzQ4MDFmMmQ1YT5dWzxmZmZmODJjNDgwMWMyYzM1Pl0gMDAwMDAwMDMwMDAw MDAwOQ0KKFhFTikgICAgMDAwMDAwMDAwMDAwMDAwMiAwMDAwMDAwMDAwMDAwMDAwIGZmZmY4MzA0 NTE3N2Y4YzggZmZmZjgzMDQ1ZjQ2MDAwMCBfX2h2bV9jb3B5KzB4MmQzLzB4NA0KKFhFTikgICAg IDAwMDAwMDAwZjMwMDAwYzAgMDAwMDAwMDAwMDAwMGEzMw0KKFhFTikgICAgZmZmZmZmMDBmZWUw MDMxMCAwMDAwMDAwMDAwMDAwMDAxIHZteF92bWV4aXRfaGFuZGxlcisweDZiNS8weDFjZTANCihY RU4pDQooWEVOKSAgICBmZmZmODMwNDUxNzZmYWYwIDAwMDAwMDA0MDAwMDAwMDEgMDAwMDAwMDAw MDAwMDEwMyBlcHRfZ2V0X2VudHJ5KzB4MTFhLzB4MmEwDQooWEVOKSAgICBbPGZmZmY4MmM0ODAx MzZhOWQ+XSBmZmZmODJjNDgwMWYyMTE1IG5zMTY1NTBfcG9sbCsweDJkLzB4MzANCihYRU4pICAg IFs8ZmZmZjgyYzQ4MDFhMjA1Zj5dWzxmZmZmODJjNDgwMTIwYTYzPl0NCihYRU4pICAgWzxmZmZm ODJjNDgwMWEyMDVmPl0gMDAwMDAwMDAwMDAwMDAwMCAwMDAwMDAwNDAwMDAwMDAwIDAwMDAwMDAw MDAwMDAwMDAgMDAwMDAwMDIxZGE1ZTAwMA0KKFhFTikgICAgIDAwMDAwMDAwMDAwMDBhMzMgY3B1 bWFza19yYWlzZV9zb2Z0aXJxKzB4ODMvMHg5MA0KKFhFTikgICAgWzxmZmZmODJjNDgwMWFjNzEz Pl0gMDAwMDAwMDAwMDAwMDAwMCAwMDAwMDAwMDAwMDAxNDJjIDAwMDAwMDAwMDAwMDAwMDBbPGZm ZmY4MmM0ODAxMTc1Yg0KKFhFTikNCihYRU4pICAgIGZmZmZmYTgwMDdlZTc1ODAgZmZmZjgzMDQ1 MTc3ZmIwNCAwMDAwMDAwMDAwNDIxMDJjIGZmZmZmZjAwZmVlMDAzMTAgZmZmZjgyYzQ4MDFmMjEx NQ0KKFhFTikgICAgMDAwMDAwMDAwMDAwMDAwMCAwMDAwMDAwMDAwMDAwMDAwIDAwMDAwMDAwMDAw MDAwMDAgMDAwMDAwMDAwMDAwMDAwMCAwMDAwMDAwMDAwMDAwMDAwIGZmZg0KKFhFTikgICAgMDAw MDAwMDAwMDAwMDAwMA0KKFhFTikgICAgaHZtX2VtdWxhdGVfb25lKzB4Y2YvMHgxYjANCihYRU4p ICAgICAwMDAwMDAwMDAwMDAwMDAwIDAwMDAwMDAwMDgyYTAwMDBbPGZmZmY4MmM0ODAxYWM3MTM+ XSBjc2NoZWRfdmNwdV93YWtlKzB4MTQ0LzB4MmQwDQooWEVOKSAgICAgMDAwMDAwMDA4MDA4MDc4 MyBoYW5kbGVfbW1pbysweDYzLzB4MWEwDQooWEVOKSAgICAgMDAwMDAwMDMwMDAwMDAwMFs8ZmZm ZjgyYzQ4MDFhMDAwMT5dIGhhbmRsZV9tbWlvKzB4NjMvMHgxYTANCihYRU4pICAgIFs8ZmZmZjgy YzQ4MDFiZWJlMT5dWzxmZmZmODJjNDgwMWFjNzQzPl0NCihYRU4pICAgIGluaXRfYXBpY19sZHJf cGh5cysweDIxLzB4NDANCihYRU4pICAgICAwMDAwMDAwMDAwMDAwMDAyIDAwMDAwMDAwMDAwMDAw MjEgMDAwMDAwMDAwMDAwMDAwMiAwMDAwMDAwMDAwMDAwMDAwIDAwMDAwMDAwMDAwMDAwMDMgMDAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgKzB4MTQxLzB4MjAwDQooWEVOKSAgICAgZmZmZjgzMDQ1MTc4ZjgzMFs8ZmZm ZjgyYzQ4MDFiNjc4Yz5dIGhhbmRsZV9tbWlvKzB4OTMvMHgxYTANCihYRU4pICAgICBmZmZmODJj NDgwMWYyZDVhIHB0X3VwZGF0ZV9pcnErMHgyYy8weDFmMA0KKFhFTikgICAgWzxmZmZmODJjNDgw MWYyZDVhPl1bPGZmZmY4MmM0ODAxZjJkNWE+XQ0KKFhFTikgIGZmZmY4MzAyOWI5Y2EwMDBYZW4g Y2FsbCB0cmFjZToNCihYRU4pICAgIFs8ZmZmZjgyYzQ4MDFiNjM0MD5dIGVwdF9nZXRfZW50cnkr MHgxMWEvMHgyYTANCihYRU4pICAgICBmZmZmZmE4MDA3ZWQ4MDAwIGZmZmY4MmM0ODAxZjJkNWFb PGZmZmY4MmM0ODAxYzU4NjA+XQ0KKFhFTikgIHB0X3RpbWVyX2ZuKzB4MC8weDQwDQooWEVOKSAg ICBbPGZmZmY4MmM0ODAxODFiZjI+XSBwYWdpbmdfbWFwX2xvZ19kaXJ0eV9iaXRtYXArMHgxMC8w eDUwDQooWEVOKSAgICBbPGZmZmY4MmM0ODAxNGI5ZGE+XVhlbiBjYWxsIHRyYWNlOg0KKFhFTikN CihYRU4pICAgIGZmZmZmYTgwMDgyNWUwMDBbPGZmZmY4MmM0ODAxYTY2YmQ+XSBlcHRfZ2V0X2Vu dHJ5KzB4MTFhLzB4MmEwDQooWEVOKSAgICAgMDAwMDAwMDAwMDAwMDFhOCB4ODZfZW11bGF0ZSsw eDJlZTIvMHgxMDliMA0KKFhFTikgICAgWzxmZmZmODJjNDgwMWE2NmJkPl0NCihYRU4pICAgIGZm ZmZmYTgwMDdlZDgwMDAgMDAwMDAwMDAyYTEwMDAwMFs8ZmZmZjgyYzQ4MDE4MWJmMj5dIDAwMDAw MDA0MDAwMDAwMDEgcmVwcm9ncmFtX3RpbWVyKzANCihYRU4pICAgICAwMDAwMDAwMDAwMDAwMDM2 IDAwMDAwMDAwMDAwMDAwMDBbPGZmZmY4MmM0ODAxZjJkNWE+XSBodm1faGFwX25lc3RlZF9wYWdl X2ZhdWx0KzB4MWVkLzANCihYRU4pICAgICAwMDAwMDAwMDAwMjBmZmE4IGh2bV9oYXBfbmVzdGVk X3BhZ2VfZmF1bHQrMHgxZWQvMHgyYzANCihYRU4pICAgIFs8ZmZmZjgyYzQ4MDEwODUzMj5dDQoo WEVOKSAgICB4ODZfZW11bGF0ZSsweDJlZTIvMHgxMDliMA0KKFhFTikgICAgWzxmZmZmODJjNDgw MWI0OTU2Pl0gMDAwMDAwMDAwMDAwMDAyZFs8ZmZmZjgyYzQ4MDE3MmExMj5dIGZmZmZmODgwMDY3 ODIwMDBbPGZmZmY4MmM0ODAxYyAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICBvcHkrMHhmMi8weDFiMA0KKFhFTikgICAg IDAwMDAwMDAwMDAwMDAxODdbPGZmZmY4MmM0ODAxYzJkMGE+XSBmZmZmZmE4MDA5ZWJhZmFlIHZs YXBpY19oYXNfcGVuZGluZ19pcnErMHgyNi8weDYwDQooWEVOKSAgICAgMDAwMDAwMDAwMDAwMDA2 YiB2bXhfdm1leGl0X2hhbmRsZXIrMHg3OGEvMHgxY2UwDQooWEVOKSAgICBbPGZmZmY4MmM0ODAx YWRkZWE+XQ0KKFhFTikNCihYRU4pICAgIGZmZmY4MzA0NTE3OGZhOTQgMDAwMDAwMDAwMDAwMDEw M1s8ZmZmZjgyYzQ4MDFhY2FhYT5dIDAwMDAwMDAwMDAyOTA1OTUgMDAwMDAwOTkwMDAwMDAwMCAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgZjIxMTUgZmZmZmY4ODAwNWM4ZTk5MQ0KKFhFTikgICAgMDAwMDAwMDAwMDAw MDAwMCB2bXhfdm1leGl0X2hhbmRsZXIrMHg3OGEvMHgxY2UwDQooWEVOKQ0KKFhFTikgICBbPGZm ZmY4MmM0ODAxMjNhMDA+XSBfX3NtcF9jYWxsX2Z1bmN0aW9uX2ludGVycnVwdCsweGEyLzB4YjAN CihYRU4pICAgICAwMDAwMDAwMDAwMDAwMDAwIDAwMDAwMDAwMDAwMDAwMDBbPGZmZmY4MmM0ODAx ZjJkNWE+XSAwMDAwMDAwMDAwMDAwMDAwIG1pZ3JhdGVfdGltZXIrMHgNCihYRU4pICAgICAwMDAw MDAwMDAwMjEwMjAyIGZmZmZmODgwMDRkMmJjMDAgZXB0X2dldF9lbnRyeSsweDExYS8weDJhMA0K KFhFTikgICAgIDAwMDAwMDAwMDAwMDAwMDBbPGZmZmY4MmM0ODAxYzA3Zjk+XVs8ZmZmZjgyYzQ4 MDFmMjExNT5dDQooWEVOKSAgICAwMDAwMDAwMDAwMDAwMDAwIDAwMDAwMDAwMDAwMDAwMDAgaHZt X3ZjcHVfaGFzX3BlbmRpbmdfaXJxKzB4NGEvMHg5MA0KKFhFTikgICAgIDdkYWM3NWFjNjlmZGRm ZDYgdm14X2N0eHRfc3dpdGNoX3RvKzB4MTQ5LzB4MjIwDQooWEVOKSAgICAgMDAwMDAwMDAwMDAw MDAwMls8ZmZmZjgyYzQ4MDFhY2FhYT5dIGhhcF9ndmFfdG9fZ2ZuXzRfbGV2ZWxzKzB4MzU1LzB4 NGUwDQooWEVOKQ0KKFhFTikgICBbPGZmZmY4MmM0ODAxYmMzY2U+XSAyNjhjNjUxNGY4NmJlODQ1 IGh2bV9pb19hc3Npc3QrMHhjYS8weGQwDQooWEVOKSAgICBbPGZmZmY4MmM0ODAxZjJkNWE+XSBl cHRfZ2V0X2VudHJ5KzB4MTFhLzB4MmEwDQooWEVOKSAgICAgMjAwYzI4MjhiMWJiMTFiZiB2bXhf aW50cl9hc3Npc3QrMHg0ZS8weDFlMA0KKFhFTikgICAgWzxmZmZmODJjNDgwMWYyMTE1Pl0gNGVh YzA5MmMwZGVkMjAyMCBodm1faW9fYXNzaXN0KzB4Y2EvMHhkMA0KKFhFTikgICAgWzxmZmZmODJj NDgwMWM0MmJiPl1bPGZmZmY4MmM0ODAxYTVjYTU+XVs8ZmZmZjgyYzQ4MDFhNWNhNT5dIGhhcF9n dmFfdG9fZ2ZuXzRfbGV2ZWxzKzB4Mw0KKFhFTikgICAgIDAwMDAwMDAwMDAwMDAwMDAgZXB0X2dl dF9lbnRyeSsweDExYS8weDJhMA0KKFhFTikgICAgIGZmZmY4MmM0ODAxZjJkNWEgaHZtX2RvX3Jl c3VtZSsweDE3NS8weDFhMA0KKFhFTikgICAgWzxmZmZmODJjNDgwMWYyZDVhPl0gaHZtX2RvX3Jl c3VtZSsweDE3NS8weDFhMA0KKFhFTikgICAgWzxmZmZmODJjNDgwMWJlYmUxPl1bPGZmZmY4MmM0 ODAxYmViZTE+XVs8ZmZmZjgyYzQ4MDFhNTM2Mz5dIHZteF92bWVudGVyX2hlbHBlcisweDViLzB4 MQ0KKFhFTikgICAgIDAwMDAwMDAwMDAwMDAwMDBbPGZmZmY4MmM0ODAxYmMyYTY+XQ0KKFhFTikg ICAgZmZmZmY4ODAwNWM4ZTk4YiB2bXhfZG9fcmVzdW1lKzB4MTQxLzB4MjAwDQooWEVOKQ0KKFhF TikgIGZmZmY4MzAyMTU5OTFmNDAgdm14X2FzbV9kb192bWVudHJ5KzB4MC8weGRhDQooWEVOKSAg ICAgMDAwMDAwMDAwMDgwMDAwMSB2bXhfZG9fcmVzdW1lKzB4MTQxLzB4MjAwDQooWEVOKQ0KKFhF TikgWzxmZmZmODJjNDgwMTUzNWFhPl0gZmZmZjgzMDIxNTk5MWY0MCBlcHRfZ2V0X2VudHJ5KzB4 MTFhLzB4MmEwDQooWEVOKSAgICBbPGZmZmY4MmM0ODAxNTM1YWE+XVBhZ2V0YWJsZSB3YWxrIGZy b20gZmZmZjgyYzQ3Zjg3YWQ1ODoNCihYRU4pIFs8ZmZmZjgyYzQ4MDFhNTM2Mz5dWGVuIGNhbGwg dHJhY2U6DQooWEVOKQ0KKFhFTikgICAgTDRbMHgxMDVdID0gMDAwMDAwMDA5ZjQ4NzAyNyA1NTU1 NTU1NTU1NTU1NTU1DQooWEVOKSBbPGZmZmY4MmM0ODAxODFiZjI+XSBMM1sweDExMV0gPSAwMDAw MDAwNDVjYzUxMDYzIDU1NTU1NTU1NTU1NTU1NTUNCihYRU4pICAwMDAwMDAwMDAwMjBmZmIwIDAw MDAwMDAwMDAwMDAwMDEgTDJbMHgxZmNdID0gMDAwMDAwMDAwMDAwMDAwMCBmZmZmZmZmZmZmZmZm ZmZmDQooWEVOKSAgY29udGV4dF9zd2l0Y2grMHgxNGEvMHhkYjANCihYRU4pDQooWEVOKSAqKioq KioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqDQooWEVOKSAgeDg2X2VtdWxhdGUr MHgyZWUyLzB4MTA5YjANCihYRU4pICAgICAwMDAwMDAwMDAwMDAwMDAxIF9faHZtX2NvcHkrMHgy ZDMvMHg0NDANCihYRU4pICAgIFBhbmljIG9uIENQVSAwOg0KKFhFTikgIGNvbnRleHRfc3dpdGNo KzB4MTRhLzB4ZGIwDQooWEVOKSAgICBGQVRBTCBQQUdFIEZBVUxUDQooWEVOKSBbZXJyb3JfY29k ZT0wMDAyXQ0KKFhFTikgRmF1bHRpbmcgbGluZWFyIGFkZHJlc3M6IGZmZmY4MmM0N2Y4N2FkNTgN CihYRU4pIFs8ZmZmZjgyYzQ4MDFiNjc4Yz5dIF9faHZtX2NvcHkrMHgyZDMvMHg0NDANCihYRU4p ICAgIFs8ZmZmZjgyYzQ4MDFhMjA1Zj5dKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioq KioqKioqKg0KKFhFTikNCihYRU4pIFs8ZmZmZjgyYzQ4MDFhMjA1Zj5dIGZmZmY4MmM0ODAxZjJk NWFSZWJvb3QgaW4gZml2ZSBzZWNvbmRzLi4uDQooWEVOKSBbPGZmZmY4MmM0ODAxYjY4YTg+XQ0K KFhFTikgICAgcHRfdXBkYXRlX2lycSsweDJjLzB4MWYwDQooWEVOKSAgICBbPGZmZmY4MmM0ODAx ZjJkNWE+XQ== --001636ed670c6f5e0704add43467 Content-Type: text/plain; charset=US-ASCII; name="Xen4.1Trace2.txt" Content-Disposition: attachment; filename="Xen4.1Trace2.txt" Content-Transfer-Encoding: base64 X-Attachment-Id: f_gt17p94d2 KFhFTikgLS0tLVsgWGVuLTQuMS4yLXJjMy1wcmUgIHg4Nl82NCAgZGVidWc9biAgVGFpbnRlZDog ICAgQyBdLS0tLQ0KKFhFTikgQ1BVOiAgICA3DQooWEVOKSBSSVA6ICAgIGUwMDg6WzxmZmZmODJj NDgwMTgxYmYyPl0geDg2X2VtdWxhdGUrMHgyZWUyLzB4MTA5YjANCihYRU4pIFJGTEFHUzogMDAw MDAwMDAwMDAxMDIwMiAgIENPTlRFWFQ6IGh5cGVydmlzb3INCihYRU4pIHJheDogMDAwMDAwMDAw MDAwMDAwMCAgIHJieDogMDAwMDAwMDAwMDAwMDAwMCAgIHJjeDogMDAwMDAwMDAwMDAwMDAwNA0K KFhFTikgcmR4OiAwMDAwMDAwMDAwMDAwMDAwICAgcnNpOiBmZmZmZmYwMGZlZTAwMzEwICAgcmRp OiAwMDAwMDAwMDAwMDAwMDAxDQooWEVOKSByYnA6IDAwMDAwMDAwMDAwMDAwMDggICByc3A6IGZm ZmY4MzA0NTE3NTc3YzggICByODogIGZmZmY4MzA0NTE3NTdiZTgNCihYRU4pIHI5OiAgMDAwMDAw MDAwMDAwMDAwMCAgIHIxMDogMDAwMDAwMDAwMDAwMDAwMCAgIHIxMTogMDAwMDAwMDAwMDAwMDAw MA0KKFhFTikgcjEyOiAwMDAwMDAwMDAwMDAwMDg5ICAgcjEzOiBmZmZmODMwNDUxNzU3YmU4ICAg cjE0OiBmZmZmODJjNDgwMjM1ZWMwDQooWEVOKSByMTU6IDAwMDAwMDAwMDAwMDAwMDAgICBjcjA6 IDAwMDAwMDAwODAwNTAwM2IgICBjcjQ6IDAwMDAwMDAwMDAwMDI2ZjANCihYRU4pIGNyMzogMDAw MDAwMDQ1ZmUyYjAwMCAgIGNyMjogZmZmZjgyMDU1MDU1N2NlOA0KKFhFTikgZHM6IDAwMDAgICBl czogMDAwMCAgIGZzOiAwMDAwICAgZ3M6IDAwMDAgICBzczogMDAwMCAgIGNzOiBlMDA4DQooWEVO KSBYZW4gc3RhY2sgdHJhY2UgZnJvbSByc3A9ZmZmZjgzMDQ1MTc1NzdjODoNCihYRU4pICAgIDAw MDAwMDAwMDAwMDAwMDAgMDAwMDAwMDEwMDAwMDAwMCBmZmZmZmYwMDAwMDAwMDAwIGZmZmY4MzA0 NTE3NTc5MDANCihYRU4pICAgIDAwMDAwMDAwMDAwMDAwZDYgZmZmZjgyYzQ4MDE0YTU0YSAwMDAw MDAwMjliZDBjMDAyIGZmZmY4MzA0NTE3NTdhZjANCihYRU4pICAgIGZmZmY4MzA0NTE3NTdhMDgg ZmZmZjgzMDQ1MTc1Nzg3OCBmZmZmZmY4MDAwMDAwMDEwIDAwMDAwMGQ2MDAwMDAwMDQNCihYRU4p ICAgIDAwMDAwMDAwMDAwMDAwMDggZmZmZmZmMDBmZWUwMDMxMCAwMDAwMDAwMDAwMDAwMDAwIDAw MDAwMDAxMDAwMDAwMDANCihYRU4pICAgIDAwMDAwMDAwMDAwMDAwODEgMDAwMDAwMDAwMDAwMDAw MiAwMDAwMDAwMGZhZjg1OTAwIDAwMDAwMDAwMDAwMDAwMDANCihYRU4pICAgIGZmZmZmZjAwZmVk MDAwMDEgZmZmZmZmZmY4MTBiYWE5MCAwMDAwMDAwMDAwMDAwMDA2IDAwMDAwMDAwMDAwMDAwZjgN CihYRU4pICAgIDAwMDAwMDAwMDAwMDAwNDAgMDAwMDAwMDAwMDAwMDAwMiBmZmZmZmY4MDAwMDc5 OGUwIDAwMDAwMDAwMDAwMDAwMDYNCihYRU4pICAgIDAwMDAwMDAwMDAwMDAwMDAgZmZmZmZmZmY4 MTE2NTg1OCBmZmZmZmZmZjgxMTY1ODUwIDAwMDAwMDAwMDAwMDAwMDINCihYRU4pICAgIDAwMDAw MDAwMGMwMDAwMDAgZmZmZmZmMDBmZWUwMDAwMCAwMDAwMDAwMDAwMDAwMDAwIDAwMDAwMDAwMGMw MDAwMDANCihYRU4pICAgIDAwMDAwMDAwMDAwMDAwZjggMDAwMDAwYjkwMDAwMDAwMCBmZmZmZmZm ZjgwYTMzOWYxIDAwMDAwMDAwMDAwMDAwMDANCihYRU4pICAgIDAwMDAwMDAwMDAwMTAwMDYgZmZm ZmZmODAwMDA3OThlMCAwMDAwMDAwMDAwMDAwMDAwIDAwMDAwMDAwMDAwMDAwMDANCihYRU4pICAg IDAwMDAwMDAwMDAwMDAwMDAgMDAwMDAwMDAwMDAwMDAwMCAwMDAwMDAwMDAwMDAwMDAwIDAwMDAw MDAwMDAwMDAwMDANCihYRU4pICAgIGZmZmZmZmZmODBhMzM5ZWIgZmZmZjgzMDQ1MTcyN2YxMCAw MDAwMDAwMDAwODAwMDAxIGZmZmY4MzA0NTE3MjdmMTANCihYRU4pICAgIDAwMDAwMDAwMDAwMDBh MzMgMDAwMDAwMDAwMDAwMDAwMSAwMDAwMDAwMDAwMDAwMDAxIGZmZmY4MmM0ODAxZjJkNWENCihY RU4pICAgIDAwMDAwMDA0MDAwMDAwMDAgMDAwMDAwMDAwYzAwMDAwMCAwMDAwMDAwMDAwMDAwMDAw IDAwMDAwMDAzMDAwMDAwMDkNCihYRU4pICAgIDAwMDAwMDAwMDAwMDAwMDIgZmZmZjgzMDQ1MTc1 NzhjOCBmZmZmODMwNDVmMjNiMDAwIDAwMDAwMDAwMDAwMDBhMzMNCihYRU4pICAgIDAwMDAwMDA0 MDAwMDAwMDEgMDAwMDAwMDAwMDAwMDAwMCAwMDAwMDAwMDAwMDAwYTMzIDAwMDAwMDAwMDAwMDE0 MmMNCihYRU4pICAgIGZmZmY4MzA0NTE3NTdiMDQgMDAwMDAwMDAwMDQyMTAyYyBmZmZmZmYwMGZl ZTAwMzEwIGZmZmY4MmM0ODAxZjIxMTUNCihYRU4pICAgIDAwMDAwMDAwMDAwMDAwMDAgMDAwMDAw MDAwMDAwMDAwMCAwMDAwMDAwMDAwMDAwMDAwIDAwMDAwMDAwMDAwMDAwMDANCihYRU4pICAgIDAw MDAwMDAwMDAwMDAwMDAgMDAwMDAwMDAwMDAwMDAwMiAwMDAwMDAwMDAwMDAwMDAwIGZmZmY4MmM0 ODAxZjJkNWENCihYRU4pIFhlbiBjYWxsIHRyYWNlOg0KKFhFTikgICAgWzxmZmZmODJjNDgwMTgx YmYyPl0geDg2X2VtdWxhdGUrMHgyZWUyLzB4MTA5YjANCihYRU4pICAgIFs8ZmZmZjgyYzQ4MDE0 YTU0YT5dIGNhbGxfZnVuY3Rpb25faW50ZXJydXB0KzB4MmEvMHgzMA0KKFhFTikgICAgWzxmZmZm ODJjNDgwMWYyZDVhPl0gZXB0X2dldF9lbnRyeSsweDExYS8weDJhMA0KKFhFTikgICAgWzxmZmZm ODJjNDgwMWYyMTE1Pl0gaGFwX2d2YV90b19nZm5fNF9sZXZlbHMrMHgzNTUvMHg0ZTANCihYRU4p ICAgIFs8ZmZmZjgyYzQ4MDFmMmQ1YT5dIGVwdF9nZXRfZW50cnkrMHgxMWEvMHgyYTANCihYRU4p ICAgIFs8ZmZmZjgyYzQ4MDFhNTM2Mz5dIF9faHZtX2NvcHkrMHgyZDMvMHg0NDANCihYRU4pICAg IFs8ZmZmZjgyYzQ4MDFhMjA1Zj5dIGh2bV9lbXVsYXRlX29uZSsweGNmLzB4MWIwDQooWEVOKSAg ICBbPGZmZmY4MmM0ODAxYWM3MTM+XSBoYW5kbGVfbW1pbysweDYzLzB4MWEwDQooWEVOKSAgICBb PGZmZmY4MmM0ODAxMDcyMzc+XSBub3RpZnlfdmlhX3hlbl9ldmVudF9jaGFubmVsKzB4OTcvMHhj MA0KKFhFTikgICAgWzxmZmZmODJjNDgwMWE2MmQ2Pl0gaHZtX3NlbmRfYXNzaXN0X3JlcSsweDc2 LzB4ZTANCihYRU4pICAgIFs8ZmZmZjgyYzQ4MDFiNDk1Nj5dIHZsYXBpY19oYXNfcGVuZGluZ19p cnErMHgyNi8weDYwDQooWEVOKSAgICBbPGZmZmY4MmM0ODAxNjMxMmQ+XSBnZXRfcGFnZSsweDJk LzB4MTAwDQooWEVOKSAgICBbPGZmZmY4MmM0ODAxYTFkNjc+XSBodm1lbXVsX2RvX3BpbysweDI3 LzB4MzANCihYRU4pICAgIFs8ZmZmZjgyYzQ4MDFjMmMzNT5dIHZteF92bWV4aXRfaGFuZGxlcisw eDZiNS8weDFjZTANCihYRU4pICAgIFs8ZmZmZjgyYzQ4MDFjMDdmOT5dIHZteF9jdHh0X3N3aXRj aF90bysweDE0OS8weDIyMA0KKFhFTikgICAgWzxmZmZmODJjNDgwMWI2NmQzPl0gcHRfcmVzdG9y ZV90aW1lcisweDIzLzB4YjANCihYRU4pICAgIFs8ZmZmZjgyYzQ4MDFhNWI1Yz5dIGh2bV9kb19y ZXN1bWUrMHgyYy8weDFhMA0KKFhFTikgICAgWzxmZmZmODJjNDgwMWJlYmUxPl0gdm14X2RvX3Jl c3VtZSsweDE0MS8weDIwMA0KKFhFTikgICAgWzxmZmZmODJjNDgwMTUzNWFhPl0gY29udGV4dF9z d2l0Y2grMHgxNGEvMHhkYjANCihYRU4pICAgIFs8ZmZmZjgyYzQ4MDEyMmQxYj5dIGFkZF9lbnRy eSsweDRiLzB4YjANCihYRU4pICAgIFs8ZmZmZjgyYzQ4MDFiNjc4Yz5dIHB0X3VwZGF0ZV9pcnEr MHgyYy8weDFmMA0KKFhFTikgICAgWzxmZmZmODJjNDgwMTRiOWRhPl0gcmVwcm9ncmFtX3RpbWVy KzB4YmEvMHgxMDANCihYRU4pICAgIFs8ZmZmZjgyYzQ4MDFiNDk1Nj5dIHZsYXBpY19oYXNfcGVu ZGluZ19pcnErMHgyNi8weDYwDQooWEVOKSAgICBbPGZmZmY4MmM0ODAxYWRkZWE+XSBodm1fdmNw dV9oYXNfcGVuZGluZ19pcnErMHg0YS8weDkwDQooWEVOKSAgICBbPGZmZmY4MmM0ODAxYmMzY2U+ XSB2bXhfaW50cl9hc3Npc3QrMHg0ZS8weDFlMA0KKFhFTikgICAgWzxmZmZmODJjNDgwMWM0MmJi Pl0gdm14X3ZtZW50ZXJfaGVscGVyKzB4NWIvMHgxNTANCihYRU4pICAgIFs8ZmZmZjgyYzQ4MDFi YzJhNj5dIHZteF9hc21fZG9fdm1lbnRyeSsweDAvMHhkYQ0KKFhFTikNCihYRU4pIFBhZ2V0YWJs ZSB3YWxrIGZyb20gZmZmZjgyMDU1MDU1N2NlODoNCihYRU4pICBMNFsweDEwNF0gPSAwMDAwMDAw NDVmMTlhMDYzIDAwMDAwMDAwMDAwMDJlNWYNCihYRU4pICBMM1sweDAxNV0gPSAwMDAwMDAwMDAw MDAwMDAwIGZmZmZmZmZmZmZmZmZmZmYNCihYRU4pDQooWEVOKSAqKioqKioqKioqKioqKioqKioq KioqKioqKioqKioqKioqKioqKioqDQooWEVOKSBQYW5pYyBvbiBDUFUgNzoNCihYRU4pIEZBVEFM IFBBR0UgRkFVTFQNCihYRU4pIFtlcnJvcl9jb2RlPTAwMDJdDQooWEVOKSBGYXVsdGluZyBsaW5l YXIgYWRkcmVzczogZmZmZjgyMDU1MDU1N2NlOA0KKFhFTikgKioqKioqKioqKioqKioqKioqKioq KioqKioqKioqKioqKioqKioqKg0KKFhFTikNCihYRU4pIFJlYm9vdCBpbiBmaXZlIHNlY29uZHMu Li4= --001636ed670c6f5e0704add43467 Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel --001636ed670c6f5e0704add43467-- From xen-devel-bounces@lists.xensource.com Mon Sep 26 02:28:07 2011 Return-path: <xen-devel-bounces@lists.xensource.com> Envelope-to: www-data@lists.xensource.com Delivery-date: Mon, 26 Sep 2011 02:28:07 -0700 Received: from localhost ([127.0.0.1] helo=lists.colo.xensource.com) by lists.xensource.com with esmtp (Exim 4.43) id 1R87Tp-00010V-Sq; Mon, 26 Sep 2011 02:28:06 -0700 Received: from mail182.messagelabs.com ([85.158.139.83]) by lists.xensource.com with esmtp (Exim 4.43) id 1R87Sn-0000n0-Ne for xen-devel@lists.xensource.com; Mon, 26 Sep 2011 02:27:03 -0700 X-Env-Sender: royger@gmail.com X-Msg-Ref: server-10.tower-182.messagelabs.com!1317029218!19713805!1 X-Originating-IP: [74.125.82.171] X-StarScan-Version: 6.4.1; banners=-,-,- X-VirusChecked: Checked Received: (qmail 17193 invoked from network); 26 Sep 2011 09:26:58 -0000 Received: from mail-wy0-f171.google.com (HELO mail-wy0-f171.google.com) (74.125.82.171) by server-10.tower-182.messagelabs.com with RC4-SHA encrypted SMTP; 26 Sep 2011 09:26:58 -0000 Received: by wyh13 with SMTP id 13so5041440wyh.30 for <xen-devel@lists.xensource.com>; Mon, 26 Sep 2011 02:26:58 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=sender:content-type:mime-version:content-transfer-encoding:subject :x-mercurial-node:message-id:in-reply-to:references:user-agent:date :from:to:cc; bh=iQpd4fq97CSmyP0ONpcGzjUeAtljQsRDwx4aWdZuPHQ=; b=Jx4fd4MkkEL9OURYyqLLnOL+tOIH2MEuArUNGIlcrEQ9FC+rGPKoSzSe9ePMEQJKtB htht7WndgzPHD8YlfzcE3kUei9gy2wTcRnjMIykkIe5uMG7EFGi/SEEmR8nBP/ewypRo 5/UR7Gt/vdYhzqwbcogo3janzsq8/rwSkh8Jc= Received: by 10.216.137.232 with SMTP id y82mr8460916wei.104.1317029218321; Mon, 26 Sep 2011 02:26:58 -0700 (PDT) Received: from [127.0.0.1] (monk.upc.es. [147.83.39.235]) by mx.google.com with ESMTPS id f26sm30074632wbp.7.2011.09.26.02.26.56 (version=TLSv1/SSLv3 cipher=OTHER); Mon, 26 Sep 2011 02:26:56 -0700 (PDT) Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Mercurial-Node: 18c7ed71d2bfe50b65427860bb192ef273568b04 Message-Id: <18c7ed71d2bfe50b6542.1317029206@loki> In-Reply-To: <1316790798.23371.108.camel@zakaz.uk.xensource.com> References: <1316790798.23371.108.camel@zakaz.uk.xensource.com> User-Agent: Mercurial-patchbomb/1.8.4 Date: Mon, 26 Sep 2011 11:26:46 +0200 From: Roger Pau Monne <roger.pau@entel.upc.edu> To: xen-devel@lists.xensource.com Cc: Ian.Campbell@citrix.com Subject: [Xen-devel] [PATCH] libxl: add custom disconnect functions for different device types X-BeenThere: xen-devel@lists.xensource.com X-Mailman-Version: 2.1.5 Precedence: list List-Id: Xen developer discussion <xen-devel.lists.xensource.com> List-Unsubscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe> List-Post: <mailto:xen-devel@lists.xensource.com> List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help> List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=subscribe> Sender: xen-devel-bounces@lists.xensource.com Errors-To: xen-devel-bounces@lists.xensource.com # HG changeset patch # User Roger Pau Monne <roger.pau@entel.upc.edu> # Date 1317028951 -7200 # Node ID 18c7ed71d2bfe50b65427860bb192ef273568b04 # Parent 0ab9f548890e5e58122f73aa1c4164fd6e319b1c libxl: add custom disconnect functions for different device types. This patch creates a new struct, called libxl__disconnect that can be used to assign different functions that will be called to check if the device is disconnected and to add it to the shutdown watch. Added a helper function to get the libxl__device_kind from a be_path. The only device that has a different shutdown mechanism right now is vbd. diff -r 0ab9f548890e -r 18c7ed71d2bf tools/libxl/libxl_device.c --- a/tools/libxl/libxl_device.c Fri Sep 23 13:31:51 2011 +0200 +++ b/tools/libxl/libxl_device.c Mon Sep 26 11:22:31 2011 +0200 @@ -28,6 +28,11 @@ #include "libxl.h" #include "libxl_internal.h" +static int libxl__watch_for_disconnect_vbd(libxl__gc *gc, char *be_path); +static int libxl__has_disconnected_vbd(libxl__gc *gc, char *be_path); +static int libxl__watch_for_disconnect_generic(libxl__gc *gc, char *be_path); +static int libxl__has_disconnected_generic(libxl__gc *gc, char *be_path); + static const char *string_of_kinds[] = { [DEVICE_VIF] = "vif", [DEVICE_VBD] = "vbd", @@ -38,6 +43,27 @@ static const char *string_of_kinds[] = { [DEVICE_CONSOLE] = "console", }; +static const libxl__disconnect disconnect_vbd = { + .watch_for_disconnect = libxl__watch_for_disconnect_vbd, + .has_disconnected = libxl__has_disconnected_vbd, +}; + +static const libxl__disconnect disconnect_generic = { + .watch_for_disconnect = libxl__watch_for_disconnect_generic, + .has_disconnected = libxl__has_disconnected_generic, +}; + +static const libxl__disconnect *disconnect_ops[] = { + [DEVICE_UNKNOWN] = &disconnect_generic, + [DEVICE_VIF] = &disconnect_generic, + [DEVICE_VBD] = &disconnect_vbd, + [DEVICE_QDISK] = &disconnect_generic, + [DEVICE_PCI] = &disconnect_generic, + [DEVICE_VFB] = &disconnect_generic, + [DEVICE_VKBD] = &disconnect_generic, + [DEVICE_CONSOLE] = &disconnect_generic, +}; + char *libxl__device_frontend_path(libxl__gc *gc, libxl__device *device) { char *dom_path = libxl__xs_get_dompath(gc, device->domid); @@ -59,6 +85,23 @@ char *libxl__device_backend_path(libxl__ device->domid, device->devid); } +static libxl__device_kinds libxl__device_identify(char *be_path) +{ + char strkind[16]; /* Longest is actually "console" */ + int len = sizeof(string_of_kinds)/sizeof(char *); + + /* /local/domain/<domid>/backend/<kind>/<domid>/<devid> */ + if (sscanf(be_path, "/local/domain/%*d/backend/%16[^/]s", strkind) != 1) + return DEVICE_UNKNOWN; + + for (int j = 1; j < len; j++) { + if (strncmp(strkind, string_of_kinds[j], 16) == 0) + return j; + } + + return DEVICE_UNKNOWN; +} + int libxl__device_generic_add(libxl__gc *gc, libxl__device *device, char **bents, char **fents) { @@ -371,15 +414,11 @@ int libxl__device_destroy(libxl__gc *gc, libxl_ctx *ctx = libxl__gc_owner(gc); xs_transaction_t t; char *state_path = libxl__sprintf(gc, "%s/state", be_path); - char *state = libxl__xs_read(gc, XBT_NULL, state_path); + libxl__device_kinds device_type = libxl__device_identify(be_path); int rc = 0; - if (!state) + if (disconnect_ops[device_type]->has_disconnected(gc, be_path)) goto out; - if (atoi(state) != 4) { - xs_rm(ctx->xsh, XBT_NULL, be_path); - goto out; - } retry_transaction: t = xs_transaction_start(ctx->xsh); @@ -394,7 +433,7 @@ retry_transaction: } } if (!force) { - xs_watch(ctx->xsh, state_path, be_path); + disconnect_ops[device_type]->watch_for_disconnect(gc, be_path); rc = 1; } else { xs_rm(ctx->xsh, XBT_NULL, be_path); @@ -410,6 +449,7 @@ static int wait_for_dev_destroy(libxl__g unsigned int n; fd_set rfds; char **l1 = NULL; + libxl__device_kinds device_type; rc = 1; nfds = xs_fileno(ctx->xsh) + 1; @@ -418,11 +458,9 @@ static int wait_for_dev_destroy(libxl__g if (select(nfds, &rfds, NULL, NULL, tv) > 0) { l1 = xs_read_watch(ctx->xsh, &n); if (l1 != NULL) { - char *state = libxl__xs_read(gc, XBT_NULL, l1[XS_WATCH_PATH]); - if (!state || atoi(state) == 6) { + device_type = libxl__device_identify(l1[XS_WATCH_TOKEN]); + if (disconnect_ops[device_type]->has_disconnected(gc, l1[XS_WATCH_TOKEN])) { xs_unwatch(ctx->xsh, l1[0], l1[1]); - xs_rm(ctx->xsh, XBT_NULL, l1[XS_WATCH_TOKEN]); - LIBXL__LOG(ctx, LIBXL__LOG_DEBUG, "Destroyed device backend at %s", l1[XS_WATCH_TOKEN]); rc = 0; } free(l1); @@ -528,6 +566,62 @@ out: return rc; } +static int libxl__watch_for_disconnect_vbd(libxl__gc *gc, char *be_path) +{ + libxl_ctx *ctx = libxl__gc_owner(gc); + char *hotplug_path = libxl__sprintf(gc, "%s/hotplug-status", be_path); + + xs_watch(ctx->xsh, hotplug_path, be_path); + + return 1; +} + +static int libxl__has_disconnected_vbd(libxl__gc *gc, char *be_path) +{ + libxl_ctx *ctx = libxl__gc_owner(gc); + char *hotplug_path = libxl__sprintf(gc, "%s/hotplug-status", be_path); + char *hotplug = libxl__xs_read(gc, XBT_NULL, hotplug_path); + int rc = 0; + + if (!hotplug || !strcmp(hotplug, "disconnected")) { + xs_rm(ctx->xsh, XBT_NULL, be_path); + LIBXL__LOG(ctx, LIBXL__LOG_DEBUG, + "Destroyed device backend at %s", + be_path); + rc = 1; + } + + return rc; +} + +static int libxl__watch_for_disconnect_generic(libxl__gc *gc, char *be_path) +{ + libxl_ctx *ctx = libxl__gc_owner(gc); + char *state_path = libxl__sprintf(gc, "%s/state", be_path); + + xs_watch(ctx->xsh, state_path, be_path); + + return 1; +} + +static int libxl__has_disconnected_generic(libxl__gc *gc, char *be_path) +{ + libxl_ctx *ctx = libxl__gc_owner(gc); + char *state_path = libxl__sprintf(gc, "%s/state", be_path); + char *state = libxl__xs_read(gc, XBT_NULL, state_path); + int rc = 0; + + if (!state || atoi(state) != 4) { + xs_rm(ctx->xsh, XBT_NULL, be_path); + LIBXL__LOG(ctx, LIBXL__LOG_DEBUG, + "Destroyed device backend at %s", + be_path); + rc = 1; + } + + return rc; +} + int libxl__wait_for_device_model(libxl__gc *gc, uint32_t domid, char *state, libxl__device_model_starting *starting, diff -r 0ab9f548890e -r 18c7ed71d2bf tools/libxl/libxl_internal.h --- a/tools/libxl/libxl_internal.h Fri Sep 23 13:31:51 2011 +0200 +++ b/tools/libxl/libxl_internal.h Mon Sep 26 11:22:31 2011 +0200 @@ -95,7 +95,8 @@ struct libxl__ctx { }; typedef enum { - DEVICE_VIF = 1, + DEVICE_UNKNOWN = 0, + DEVICE_VIF, DEVICE_VBD, DEVICE_QDISK, DEVICE_PCI, @@ -206,6 +207,12 @@ _hidden int libxl__domain_save_device_mo _hidden void libxl__userdata_destroyall(libxl__gc *gc, uint32_t domid); /* from xl_device */ + +typedef struct { + int (*watch_for_disconnect)(libxl__gc *gc, char *be_path); + int (*has_disconnected)(libxl__gc *gc, char *be_path); +} libxl__disconnect; + _hidden char *libxl__device_disk_string_of_backend(libxl_disk_backend backend); _hidden char *libxl__device_disk_string_of_format(libxl_disk_format format); _hidden int libxl__device_disk_set_backend(libxl__gc*, libxl_device_disk*); _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel From xen-devel-bounces@lists.xensource.com Mon Sep 26 03:10:17 2011 Return-path: <xen-devel-bounces@lists.xensource.com> Envelope-to: www-data@lists.xensource.com Delivery-date: Mon, 26 Sep 2011 03:10:17 -0700 Received: from localhost ([127.0.0.1] helo=lists.colo.xensource.com) by lists.xensource.com with esmtp (Exim 4.43) id 1R888e-0002yC-Ut; Mon, 26 Sep 2011 03:10:16 -0700 Received: from mail216.messagelabs.com ([85.158.143.99]) by lists.xensource.com with esmtp (Exim 4.43) id 1R7vSg-0005GI-1y for xen-devel@lists.xensource.com; Sun, 25 Sep 2011 13:38:08 -0700 X-Env-Sender: stephen.more@gmail.com X-Msg-Ref: server-9.tower-216.messagelabs.com!1316983081!19554171!1 X-Originating-IP: [209.85.213.43] X-StarScan-Version: 6.4.1; banners=-,-,- X-VirusChecked: Checked Received: (qmail 5694 invoked from network); 25 Sep 2011 20:38:02 -0000 Received: from mail-yw0-f43.google.com (HELO mail-yw0-f43.google.com) (209.85.213.43) by server-9.tower-216.messagelabs.com with RC4-SHA encrypted SMTP; 25 Sep 2011 20:38:02 -0000 Received: by ywm21 with SMTP id 21so6000686ywm.30 for <xen-devel@lists.xensource.com>; Sun, 25 Sep 2011 13:38:01 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:date:message-id:subject:from:to:content-type; bh=rt/I6pQYh9Ve2qbk/uJws+yNmhXCJR2t/nu+C2ugwtw=; b=W7hWJYr6wRx+QfEUskZRU8CoLbjWiyLX1YndPTwQwHs2tcmA1VABSaBfwYJxYjASRO 0bz9bt20Xl7E5JTk/sY3t8gA890xbELRrLlSNExUq19PZoHrlfCNSbicz5xvb7X63On8 uAQbZWFc1x7hfaCVayOD8tryBmFbX1vW2TlZ4= MIME-Version: 1.0 Received: by 10.231.8.32 with SMTP id f32mr8143395ibf.65.1316983081232; Sun, 25 Sep 2011 13:38:01 -0700 (PDT) Received: by 10.231.13.204 with HTTP; Sun, 25 Sep 2011 13:38:00 -0700 (PDT) Date: Sun, 25 Sep 2011 16:38:00 -0400 Message-ID: <CAL2vA_N6ZPsZyqReEEEs_+DwbNKfrZpcEEVcUY4-qTo=kBrL5w@mail.gmail.com> From: Stephen More <stephen.more@gmail.com> To: xen-devel@lists.xensource.com Content-Type: text/plain; charset=ISO-8859-1 X-Mailman-Approved-At: Mon, 26 Sep 2011 03:09:02 -0700 Subject: [Xen-devel] Please report to - xm new X-BeenThere: xen-devel@lists.xensource.com X-Mailman-Version: 2.1.5 Precedence: list List-Id: Xen developer discussion <xen-devel.lists.xensource.com> List-Unsubscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe> List-Post: <mailto:xen-devel@lists.xensource.com> List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help> List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=subscribe> Sender: xen-devel-bounces@lists.xensource.com Errors-To: xen-devel-bounces@lists.xensource.com I installed the beta version of oneiric and got this error: root@g4-01:~# xm new Unexpected error: <type 'exceptions.ImportError'> Please report to xen-devel@lists.xensource.com Traceback (most recent call last): File "/usr/lib/xen-4.1/bin/xm", line 8, in <module> main.main(sys.argv) File "/usr/lib/xen-4.1/bin/../lib/python/xen/xm/main.py", line 3983, in main _, rc = _run_cmd(cmd, cmd_name, args) File "/usr/lib/xen-4.1/bin/../lib/python/xen/xm/main.py", line 4007, in _run_cmd return True, cmd(args) File "<string>", line 1, in <lambda> File "/usr/lib/xen-4.1/bin/../lib/python/xen/xm/main.py", line 1518, in xm_importcommand cmd = __import__(command, globals(), locals(), 'xen.xm') File "/usr/lib/xen-4.1/bin/../lib/python/xen/xm/new.py", line 26, in <module> from xen.xm.xenapi_create import * File "/usr/lib/xen-4.1/bin/../lib/python/xen/xm/xenapi_create.py", line 24, in <module> from lxml import etree ImportError: No module named lxml root@g4-01:~# _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel From xen-devel-bounces@lists.xensource.com Mon Sep 26 03:25:15 2011 Return-path: <xen-devel-bounces@lists.xensource.com> Envelope-to: www-data@lists.xensource.com Delivery-date: Mon, 26 Sep 2011 03:25:15 -0700 Received: from localhost ([127.0.0.1] helo=lists.colo.xensource.com) by lists.xensource.com with esmtp (Exim 4.43) id 1R88N9-0003YY-GP; Mon, 26 Sep 2011 03:25:15 -0700 Received: from mail182.messagelabs.com ([85.158.139.83]) by lists.xensource.com with esmtp (Exim 4.43) id 1R88MD-0003LZ-UF for xen-devel@lists.xensource.com; Mon, 26 Sep 2011 03:24:18 -0700 X-Env-Sender: Andrew.Cooper3@citrix.com X-Msg-Ref: server-11.tower-182.messagelabs.com!1317032653!19738444!1 X-Originating-IP: [66.165.176.89] X-StarScan-Version: 6.4.1; banners=-,-,- X-VirusChecked: Checked Received: (qmail 14378 invoked from network); 26 Sep 2011 10:24:14 -0000 Received: from smtp.citrix.com (HELO SMTP.CITRIX.COM) (66.165.176.89) by server-11.tower-182.messagelabs.com with RC4-SHA encrypted SMTP; 26 Sep 2011 10:24:14 -0000 X-IronPort-AV: E=Sophos;i="4.68,443,1312171200"; d="scan'208";a="17689383" Received: from ftlpmailmx02.citrite.net ([10.13.107.66]) by FTLPIPO01.CITRIX.COM with ESMTP/TLS/RC4-MD5; 26 Sep 2011 06:24:13 -0400 Received: from [10.80.2.18] (10.80.2.18) by FTLPMAILMX02.citrite.net (10.13.107.66) with Microsoft SMTP Server id 8.3.137.0; Mon, 26 Sep 2011 06:24:12 -0400 Message-ID: <4E8052BB.609@citrix.com> Date: Mon, 26 Sep 2011 11:23:55 +0100 From: Andrew Cooper <andrew.cooper3@citrix.com> User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.2.21) Gecko/20110831 Lightning/1.0b2 Thunderbird/3.1.13 MIME-Version: 1.0 To: <xen-devel@lists.xensource.com>, Jan Beulich <JBeulich@suse.com> Subject: Re: [Xen-devel] [PATCH 2/4] pass struct irq_desc * to set_affinity() IRQ accessors References: <4E78D0BE0200007800056D89@nat28.tlf.novell.com> In-Reply-To: <4E78D0BE0200007800056D89@nat28.tlf.novell.com> Content-Type: text/plain; charset="ISO-8859-1" Content-Transfer-Encoding: 7bit Cc: X-BeenThere: xen-devel@lists.xensource.com X-Mailman-Version: 2.1.5 Precedence: list List-Id: Xen developer discussion <xen-devel.lists.xensource.com> List-Unsubscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe> List-Post: <mailto:xen-devel@lists.xensource.com> List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help> List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=subscribe> Sender: xen-devel-bounces@lists.xensource.com Errors-To: xen-devel-bounces@lists.xensource.com On 20/09/11 16:43, Jan Beulich wrote: > This is because the descriptor is generally more useful (with the IRQ > number being accessible in it if necessary) and going forward will > hopefully allow to remove all direct accesses to the IRQ descriptor > array, in turn making it possible to make this some other, more > efficient data structure. Do be aware that certain bits of the code use pointer arithmetic between an irq_{cfg,desc} * and the base of the array to work out the irq value. Changing the data structure will likely invalidate that logic in subtle ways. ~Andrew > Signed-off-by: Jan Beulich <jbeulich@suse.com> > > --- a/xen/arch/ia64/linux-xen/iosapic.c > +++ b/xen/arch/ia64/linux-xen/iosapic.c > @@ -352,18 +352,18 @@ unmask_irq (unsigned int irq) > > > static void > -iosapic_set_affinity (unsigned int irq, const cpumask_t *mask) > +iosapic_set_affinity (struct irq_desc *desc, const cpumask_t *mask) > { > #ifdef CONFIG_SMP > unsigned long flags; > u32 high32, low32; > int dest, rte_index; > char __iomem *addr; > - int redir = (irq & IA64_IRQ_REDIRECTED) ? 1 : 0; > + int redir = (desc->irq & IA64_IRQ_REDIRECTED) ? 1 : 0; > + unsigned int irq = desc->irq & ~IA64_IRQ_REDIRECTED; > ia64_vector vec; > struct iosapic_rte_info *rte; > > - irq &= (~IA64_IRQ_REDIRECTED); > vec = irq_to_vector(irq); > > if (cpumask_empty(mask)) > --- a/xen/arch/x86/hpet.c > +++ b/xen/arch/x86/hpet.c > @@ -258,24 +258,14 @@ static void hpet_msi_mask(unsigned int i > hpet_write32(cfg, HPET_Tn_CFG(ch->idx)); > } > > -static void hpet_msi_write(unsigned int irq, struct msi_msg *msg) > +static void hpet_msi_write(struct hpet_event_channel *ch, struct msi_msg *msg) > { > - unsigned int ch_idx = irq_to_channel(irq); > - struct hpet_event_channel *ch = hpet_events + ch_idx; > - > - BUG_ON(ch_idx >= num_hpets_used); > - > hpet_write32(msg->data, HPET_Tn_ROUTE(ch->idx)); > hpet_write32(msg->address_lo, HPET_Tn_ROUTE(ch->idx) + 4); > } > > -static void hpet_msi_read(unsigned int irq, struct msi_msg *msg) > +static void hpet_msi_read(struct hpet_event_channel *ch, struct msi_msg *msg) > { > - unsigned int ch_idx = irq_to_channel(irq); > - struct hpet_event_channel *ch = hpet_events + ch_idx; > - > - BUG_ON(ch_idx >= num_hpets_used); > - > msg->data = hpet_read32(HPET_Tn_ROUTE(ch->idx)); > msg->address_lo = hpet_read32(HPET_Tn_ROUTE(ch->idx) + 4); > msg->address_hi = 0; > @@ -305,23 +295,22 @@ static void hpet_msi_end(unsigned int ir > { > } > > -static void hpet_msi_set_affinity(unsigned int irq, const cpumask_t *mask) > +static void hpet_msi_set_affinity(struct irq_desc *desc, const cpumask_t *mask) > { > struct msi_msg msg; > unsigned int dest; > - struct irq_desc * desc = irq_to_desc(irq); > struct irq_cfg *cfg= desc->chip_data; > > dest = set_desc_affinity(desc, mask); > if (dest == BAD_APICID) > return; > > - hpet_msi_read(irq, &msg); > + hpet_msi_read(desc->action->dev_id, &msg); > msg.data &= ~MSI_DATA_VECTOR_MASK; > msg.data |= MSI_DATA_VECTOR(cfg->vector); > msg.address_lo &= ~MSI_ADDR_DEST_ID_MASK; > msg.address_lo |= MSI_ADDR_DEST_ID(dest); > - hpet_msi_write(irq, &msg); > + hpet_msi_write(desc->action->dev_id, &msg); > } > > /* > @@ -338,12 +327,12 @@ static hw_irq_controller hpet_msi_type = > .set_affinity = hpet_msi_set_affinity, > }; > > -static void __hpet_setup_msi_irq(unsigned int irq) > +static void __hpet_setup_msi_irq(struct irq_desc *desc) > { > struct msi_msg msg; > > - msi_compose_msg(irq, &msg); > - hpet_msi_write(irq, &msg); > + msi_compose_msg(desc->irq, &msg); > + hpet_msi_write(desc->action->dev_id, &msg); > } > > static int __init hpet_setup_msi_irq(unsigned int irq) > @@ -357,7 +346,7 @@ static int __init hpet_setup_msi_irq(uns > if ( ret < 0 ) > return ret; > > - __hpet_setup_msi_irq(irq); > + __hpet_setup_msi_irq(desc); > > return 0; > } > @@ -471,7 +460,7 @@ static void hpet_attach_channel(unsigned > if ( ch->cpu != cpu ) > return; > > - hpet_msi_set_affinity(ch->irq, cpumask_of(ch->cpu)); > + hpet_msi_set_affinity(irq_to_desc(ch->irq), cpumask_of(ch->cpu)); > } > > static void hpet_detach_channel(unsigned int cpu, > @@ -493,7 +482,7 @@ static void hpet_detach_channel(unsigned > } > > ch->cpu = first_cpu(ch->cpumask); > - hpet_msi_set_affinity(ch->irq, cpumask_of(ch->cpu)); > + hpet_msi_set_affinity(irq_to_desc(ch->irq), cpumask_of(ch->cpu)); > } > > #include <asm/mc146818rtc.h> > @@ -619,7 +608,7 @@ void hpet_broadcast_resume(void) > for ( i = 0; i < n; i++ ) > { > if ( hpet_events[i].irq >= 0 ) > - __hpet_setup_msi_irq(hpet_events[i].irq); > + __hpet_setup_msi_irq(irq_to_desc(hpet_events[i].irq)); > > /* set HPET Tn as oneshot */ > cfg = hpet_read32(HPET_Tn_CFG(hpet_events[i].idx)); > --- a/xen/arch/x86/io_apic.c > +++ b/xen/arch/x86/io_apic.c > @@ -658,7 +658,7 @@ unsigned int set_desc_affinity(struct ir > } > > static void > -set_ioapic_affinity_irq_desc(struct irq_desc *desc, const cpumask_t *mask) > +set_ioapic_affinity_irq(struct irq_desc *desc, const cpumask_t *mask) > { > unsigned long flags; > unsigned int dest; > @@ -695,16 +695,6 @@ set_ioapic_affinity_irq_desc(struct irq_ > spin_unlock_irqrestore(&ioapic_lock, flags); > > } > - > -static void > -set_ioapic_affinity_irq(unsigned int irq, const struct cpumask *mask) > -{ > - struct irq_desc *desc; > - > - desc = irq_to_desc(irq); > - > - set_ioapic_affinity_irq_desc(desc, mask); > -} > #endif /* CONFIG_SMP */ > > /* > @@ -802,7 +792,7 @@ void /*__init*/ setup_ioapic_dest(void) > irq = pin_2_irq(irq_entry, ioapic, pin); > cfg = irq_cfg(irq); > BUG_ON(cpus_empty(cfg->cpu_mask)); > - set_ioapic_affinity_irq(irq, &cfg->cpu_mask); > + set_ioapic_affinity_irq(irq_to_desc(irq), &cfg->cpu_mask); > } > > } > @@ -1780,7 +1770,7 @@ static void mask_and_ack_level_ioapic_ir > > if ((irq_desc[irq].status & IRQ_MOVE_PENDING) && > !io_apic_level_ack_pending(irq)) > - move_masked_irq(irq); > + move_masked_irq(desc); > > if ( !(v & (1 << (i & 0x1f))) ) { > spin_lock(&ioapic_lock); > @@ -1799,7 +1789,9 @@ static void end_level_ioapic_irq (unsign > { > if ( directed_eoi_enabled ) > { > - if ( !(irq_desc[irq].status & (IRQ_DISABLED|IRQ_MOVE_PENDING)) ) > + struct irq_desc *desc = irq_to_desc(irq); > + > + if ( !(desc->status & (IRQ_DISABLED|IRQ_MOVE_PENDING)) ) > { > eoi_IO_APIC_irq(irq); > return; > @@ -1807,9 +1799,9 @@ static void end_level_ioapic_irq (unsign > > mask_IO_APIC_irq(irq); > eoi_IO_APIC_irq(irq); > - if ( (irq_desc[irq].status & IRQ_MOVE_PENDING) && > + if ( (desc->status & IRQ_MOVE_PENDING) && > !io_apic_level_ack_pending(irq) ) > - move_masked_irq(irq); > + move_masked_irq(desc); > } > > if ( !(irq_desc[irq].status & IRQ_DISABLED) ) > --- a/xen/arch/x86/irq.c > +++ b/xen/arch/x86/irq.c > @@ -557,10 +557,8 @@ void __setup_vector_irq(int cpu) > } > } > > -void move_masked_irq(int irq) > +void move_masked_irq(struct irq_desc *desc) > { > - struct irq_desc *desc = irq_to_desc(irq); > - > if (likely(!(desc->status & IRQ_MOVE_PENDING))) > return; > > @@ -582,7 +580,7 @@ void move_masked_irq(int irq) > * For correct operation this depends on the caller masking the irqs. > */ > if (likely(cpus_intersects(desc->pending_mask, cpu_online_map))) > - desc->handler->set_affinity(irq, &desc->pending_mask); > + desc->handler->set_affinity(desc, &desc->pending_mask); > > cpus_clear(desc->pending_mask); > } > @@ -598,7 +596,7 @@ void move_native_irq(int irq) > return; > > desc->handler->disable(irq); > - move_masked_irq(irq); > + move_masked_irq(desc); > desc->handler->enable(irq); > } > > @@ -1409,7 +1407,7 @@ int pirq_guest_bind(struct vcpu *v, stru > /* Attempt to bind the interrupt target to the correct CPU. */ > cpu_set(v->processor, cpumask); > if ( !opt_noirqbalance && (desc->handler->set_affinity != NULL) ) > - desc->handler->set_affinity(irq, &cpumask); > + desc->handler->set_affinity(desc, &cpumask); > } > else if ( !will_share || !action->shareable ) > { > @@ -1963,7 +1961,7 @@ void fixup_irqs(void) > desc->handler->disable(irq); > > if ( desc->handler->set_affinity ) > - desc->handler->set_affinity(irq, &affinity); > + desc->handler->set_affinity(desc, &affinity); > else if ( !(warned++) ) > set_affinity = 0; > > --- a/xen/arch/x86/msi.c > +++ b/xen/arch/x86/msi.c > @@ -266,11 +266,10 @@ static void write_msi_msg(struct msi_des > } > } > > -void set_msi_affinity(unsigned int irq, const cpumask_t *mask) > +void set_msi_affinity(struct irq_desc *desc, const cpumask_t *mask) > { > struct msi_msg msg; > unsigned int dest; > - struct irq_desc *desc = irq_to_desc(irq); > struct msi_desc *msi_desc = desc->msi_desc; > struct irq_cfg *cfg = desc->chip_data; > > --- a/xen/drivers/passthrough/amd/iommu_init.c > +++ b/xen/drivers/passthrough/amd/iommu_init.c > @@ -344,12 +344,11 @@ static void amd_iommu_reset_event_log(st > set_iommu_event_log_control(iommu, IOMMU_CONTROL_ENABLED); > } > > -static void iommu_msi_set_affinity(unsigned int irq, const cpumask_t *mask) > +static void iommu_msi_set_affinity(struct irq_desc *desc, const cpumask_t *mask) > { > struct msi_msg msg; > unsigned int dest; > - struct amd_iommu *iommu = irq_to_iommu[irq]; > - struct irq_desc *desc = irq_to_desc(irq); > + struct amd_iommu *iommu = desc->action->dev_id; > struct irq_cfg *cfg = desc->chip_data; > u8 bus = (iommu->bdf >> 8) & 0xff; > u8 dev = PCI_SLOT(iommu->bdf & 0xff); > @@ -591,7 +590,7 @@ static void enable_iommu(struct amd_iomm > register_iommu_event_log_in_mmio_space(iommu); > register_iommu_exclusion_range(iommu); > > - iommu_msi_set_affinity(iommu->irq, &cpu_online_map); > + iommu_msi_set_affinity(irq_to_desc(iommu->irq), &cpu_online_map); > amd_iommu_msi_enable(iommu, IOMMU_CONTROL_ENABLED); > > set_iommu_command_buffer_control(iommu, IOMMU_CONTROL_ENABLED); > --- a/xen/drivers/passthrough/vtd/iommu.c > +++ b/xen/drivers/passthrough/vtd/iommu.c > @@ -998,14 +998,12 @@ static void dma_msi_end(unsigned int irq > ack_APIC_irq(); > } > > -static void dma_msi_set_affinity(unsigned int irq, const cpumask_t *mask) > +static void dma_msi_set_affinity(struct irq_desc *desc, const cpumask_t *mask) > { > struct msi_msg msg; > unsigned int dest; > unsigned long flags; > - > - struct iommu *iommu = irq_to_iommu[irq]; > - struct irq_desc *desc = irq_to_desc(irq); > + struct iommu *iommu = desc->action->dev_id; > struct irq_cfg *cfg = desc->chip_data; > > #ifdef CONFIG_X86 > @@ -1984,7 +1982,7 @@ static int init_vtd_hw(void) > iommu = drhd->iommu; > > cfg = irq_cfg(iommu->irq); > - dma_msi_set_affinity(iommu->irq, &cfg->cpu_mask); > + dma_msi_set_affinity(irq_to_desc(iommu->irq), &cfg->cpu_mask); > > clear_fault_bits(iommu); > > --- a/xen/include/asm-x86/irq.h > +++ b/xen/include/asm-x86/irq.h > @@ -172,7 +172,7 @@ void unlock_vector_lock(void); > void __setup_vector_irq(int cpu); > > void move_native_irq(int irq); > -void move_masked_irq(int irq); > +void move_masked_irq(struct irq_desc *); > > int __assign_irq_vector(int irq, struct irq_cfg *, const cpumask_t *); > > --- a/xen/include/asm-x86/msi.h > +++ b/xen/include/asm-x86/msi.h > @@ -77,7 +77,7 @@ struct msi_desc; > /* Helper functions */ > extern void mask_msi_irq(unsigned int irq); > extern void unmask_msi_irq(unsigned int irq); > -extern void set_msi_affinity(unsigned int vector, const cpumask_t *); > +extern void set_msi_affinity(struct irq_desc *, const cpumask_t *); > extern int pci_enable_msi(struct msi_info *msi, struct msi_desc **desc); > extern void pci_disable_msi(struct msi_desc *desc); > extern void pci_cleanup_msi(struct pci_dev *pdev); > --- a/xen/include/xen/irq.h > +++ b/xen/include/xen/irq.h > @@ -33,6 +33,8 @@ struct irqaction { > #define NEVER_ASSIGN_IRQ (-2) > #define FREE_TO_ASSIGN_IRQ (-3) > > +struct irq_desc; > + > /* > * Interrupt controller descriptor. This is all we need > * to describe about the low-level hardware. > @@ -45,7 +47,7 @@ struct hw_interrupt_type { > void (*disable)(unsigned int irq); > void (*ack)(unsigned int irq); > void (*end)(unsigned int irq, u8 vector); > - void (*set_affinity)(unsigned int irq, const cpumask_t *); > + void (*set_affinity)(struct irq_desc *, const cpumask_t *); > }; > > typedef const struct hw_interrupt_type hw_irq_controller; > > -- Andrew Cooper - Dom0 Kernel Engineer, Citrix XenServer T: +44 (0)1223 225 900, http://www.citrix.com _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel From xen-devel-bounces@lists.xensource.com Mon Sep 26 04:19:19 2011 Return-path: <xen-devel-bounces@lists.xensource.com> Envelope-to: www-data@lists.xensource.com Delivery-date: Mon, 26 Sep 2011 04:19:19 -0700 Received: from localhost ([127.0.0.1] helo=lists.colo.xensource.com) by lists.xensource.com with esmtp (Exim 4.43) id 1R89DT-0000fb-7M; Mon, 26 Sep 2011 04:19:19 -0700 Received: from mail174.messagelabs.com ([85.158.138.51]) by lists.xensource.com with esmtp (Exim 4.43) id 1R893g-0007Zz-CG for xen-devel@lists.xensource.com; Mon, 26 Sep 2011 04:09:13 -0700 X-Env-Sender: piyush.today@gmail.com X-Msg-Ref: server-9.tower-174.messagelabs.com!1317035322!26733670!2 X-Originating-IP: [209.85.210.171] X-StarScan-Version: 6.4.1; banners=-,-,- X-VirusChecked: Checked Received: (qmail 24155 invoked from network); 26 Sep 2011 11:09:09 -0000 Received: from mail-iy0-f171.google.com (HELO mail-iy0-f171.google.com) (209.85.210.171) by server-9.tower-174.messagelabs.com with RC4-SHA encrypted SMTP; 26 Sep 2011 11:09:09 -0000 Received: by mail-iy0-f171.google.com with SMTP id v1so5955828iag.30 for <xen-devel@lists.xensource.com>; Mon, 26 Sep 2011 04:09:08 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:date:message-id:subject:from:to:content-type; bh=mavVw3lR5cOOd2nkd+LpT7ui9dDh7cyn7q5uRBEWFlM=; b=aw8+tIWOVYyQj5yo2N66HTZV2ZxLWaSdS32TMAkJUwYPGCKpgf/ThoT8+Zx0ieURcm eiIsrIy1k58CmJyAfHuS25vDwGPlhpggCqmBTR5wMzf5MGRA9nVrHvqgBtvZ1kw3+zvR 215cxl44/cn1uPJUHexQWN/SJUSsdfjGsQHpQ= MIME-Version: 1.0 Received: by 10.42.177.72 with SMTP id bh8mr4123511icb.39.1317035348711; Mon, 26 Sep 2011 04:09:08 -0700 (PDT) Received: by 10.42.179.134 with HTTP; Mon, 26 Sep 2011 04:09:08 -0700 (PDT) Date: Mon, 26 Sep 2011 16:39:08 +0530 Message-ID: <CACyYOe+78Jss5AmBqwLa-d=0+9mSzh0DbpGOx4KQJO=wqOeJVA@mail.gmail.com> From: piyush jain <piyush.today@gmail.com> To: xen-devel@lists.xensource.com Subject: [Xen-devel] xen + windbg.. X-BeenThere: xen-devel@lists.xensource.com X-Mailman-Version: 2.1.5 Precedence: list List-Id: Xen developer discussion <xen-devel.lists.xensource.com> List-Unsubscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe> List-Post: <mailto:xen-devel@lists.xensource.com> List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help> List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=subscribe> Content-Type: multipart/mixed; boundary="===============1435541080==" Sender: xen-devel-bounces@lists.xensource.com Errors-To: xen-devel-bounces@lists.xensource.com --===============1435541080== Content-Type: multipart/alternative; boundary=90e6ba6e8cf61de33f04add630c3 --90e6ba6e8cf61de33f04add630c3 Content-Type: text/plain; charset=ISO-8859-1 Hi, Is it possible to connect windbg to guest windows 2008 R2, over xen? Anyone how did it succesfully? I tried steps in this links http://wiki.xensource.com/xenwiki/XenWindowsGplPv but it's not working for me :( (i modified add in xinited, instead of inetd.conf) Can any1 update this doc? Regards, Piyush --90e6ba6e8cf61de33f04add630c3 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable <div>Hi,</div><div>Is it possible to connect windbg to guest windows 2008 R= 2, over xen?</div><div>=A0</div><div>Anyone how did it succesfully?</div><d= iv>=A0</div><div>I tried steps in this links</div><div>=A0</div><div><a hre= f=3D"http://wiki.xensource.com/xenwiki/XenWindowsGplPv">http://wiki.xensour= ce.com/xenwiki/XenWindowsGplPv</a></div> <div>=A0</div><div>but it's not working for me :( (i modified add in xi= nited, instead of inetd.conf)</div><div>=A0</div><div>Can any1 update this = doc?</div><div>=A0</div><div>Regards,</div><div>Piyush</div> --90e6ba6e8cf61de33f04add630c3-- --===============1435541080== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel --===============1435541080==-- From xen-devel-bounces@lists.xensource.com Mon Sep 26 04:45:04 2011 Return-path: <xen-devel-bounces@lists.xensource.com> Envelope-to: www-data@lists.xensource.com Delivery-date: Mon, 26 Sep 2011 04:45:04 -0700 Received: from localhost ([127.0.0.1] helo=lists.colo.xensource.com) by lists.xensource.com with esmtp (Exim 4.43) id 1R89cN-0002JQ-R4; Mon, 26 Sep 2011 04:45:03 -0700 Received: from mail174.messagelabs.com ([85.158.138.51]) by lists.xensource.com with esmtp (Exim 4.43) id 1R89be-00027U-4e for xen-devel@lists.xensource.com; Mon, 26 Sep 2011 04:44:19 -0700 X-Env-Sender: dunlapg@gmail.com X-Msg-Ref: server-10.tower-174.messagelabs.com!1317037454!32758035!1 X-Originating-IP: [74.125.82.41] X-StarScan-Version: 6.4.1; banners=-,-,- X-VirusChecked: Checked Received: (qmail 11967 invoked from network); 26 Sep 2011 11:44:15 -0000 Received: from mail-ww0-f41.google.com (HELO mail-ww0-f41.google.com) (74.125.82.41) by server-10.tower-174.messagelabs.com with RC4-SHA encrypted SMTP; 26 Sep 2011 11:44:15 -0000 Received: by wwf10 with SMTP id 10so10419588wwf.0 for <xen-devel@lists.xensource.com>; Mon, 26 Sep 2011 04:44:14 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:sender:date:x-google-sender-auth:message-id:subject :from:to:content-type; bh=PVAKzFEpMWy0g6mo61HbkjdXPQ70eYa1uDGYsW2PvlQ=; b=fQwaYwCO3fAjXmyvdLQRoISWfcjvTjFuNQEdWytbHwJZCiJdlOW5z8IHiLtQVidSNK WDTz+UTWivDHju45yU5kDJpakK2ysoUvcQbeaenOsj+4K4XA7W2NqL3QIEcEut8WYjSM vofr162L9Y8RlFyaRacPAFWegswzP7ztyB7eI= MIME-Version: 1.0 Received: by 10.216.36.16 with SMTP id v16mr7655409wea.66.1317037439473; Mon, 26 Sep 2011 04:43:59 -0700 (PDT) Received: by 10.216.176.81 with HTTP; Mon, 26 Sep 2011 04:43:59 -0700 (PDT) Date: Mon, 26 Sep 2011 12:43:59 +0100 X-Google-Sender-Auth: KsQsH20gkRcwHTVx-oIOXaYtLBE Message-ID: <CAFLBxZbHvhK2U1+1i5UFYhJ9SLDLzx2kdmc-C8qnUbXb-eGsQw@mail.gmail.com> From: George Dunlap <dunlapg@umich.edu> To: xen-devel@lists.xensource.com Content-Type: text/plain; charset=ISO-8859-1 Subject: [Xen-devel] [RFC] SubmittingXenPatches wiki page X-BeenThere: xen-devel@lists.xensource.com X-Mailman-Version: 2.1.5 Precedence: list List-Id: Xen developer discussion <xen-devel.lists.xensource.com> List-Unsubscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe> List-Post: <mailto:xen-devel@lists.xensource.com> List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help> List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=subscribe> Sender: xen-devel-bounces@lists.xensource.com Errors-To: xen-devel-bounces@lists.xensource.com I've made a new version of the SubmittingXenPatches wiki page that suggest using mercurial queues and patchbomb extension, instead of the rather daft "clone a repository, commit changes, and then do hg export" method. I created it here: http://wiki.xensource.com/xenwiki/SubmittingXenPatches2 Please skim it and comment on it. If there are no objections, I shall replace the original SubmittingXenPatches in a few days. -George _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel From xen-devel-bounces@lists.xensource.com Mon Sep 26 05:06:14 2011 Return-path: <xen-devel-bounces@lists.xensource.com> Envelope-to: www-data@lists.xensource.com Delivery-date: Mon, 26 Sep 2011 05:06:14 -0700 Received: from localhost ([127.0.0.1] helo=lists.colo.xensource.com) by lists.xensource.com with esmtp (Exim 4.43) id 1R89ws-0003lL-5L; Mon, 26 Sep 2011 05:06:14 -0700 Received: from mail27.messagelabs.com ([193.109.254.147]) by lists.xensource.com with esmtp (Exim 4.43) id 1R89uG-0003Vx-PG for xen-devel@lists.xensource.com; Mon, 26 Sep 2011 05:03:50 -0700 X-Env-Sender: royger@gmail.com X-Msg-Ref: server-13.tower-27.messagelabs.com!1317038595!41554927!1 X-Originating-IP: [209.85.213.171] X-StarScan-Version: 6.4.1; banners=-,-,- X-VirusChecked: Checked Received: (qmail 22144 invoked from network); 26 Sep 2011 12:03:16 -0000 Received: from mail-yx0-f171.google.com (HELO mail-yx0-f171.google.com) (209.85.213.171) by server-13.tower-27.messagelabs.com with RC4-SHA encrypted SMTP; 26 Sep 2011 12:03:16 -0000 Received: by yxt3 with SMTP id 3so6840372yxt.30 for <xen-devel@lists.xensource.com>; Mon, 26 Sep 2011 05:03:27 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=kpnZgnE2cgcDwY6FCIOVqSNu3U7rwruFJU/aMCkNNSM=; b=f5S6NLRzuUIHXjuMnes4g1uu8ymrW+ikMyY/urlGfkDwnLRRHtm6JzFrn4jAm2sGLF Azb22l9hUuGQn72OPtSzKVZQuDgzLD61z6ddMQxZVVSLhvkrI8QMWqxQZWxF02J+UsoK 5CJxXaRztNeOO6FMtT1TUmOC5rK+gUoBwjgJo= MIME-Version: 1.0 Received: by 10.68.31.4 with SMTP id w4mr646955pbh.20.1317038607322; Mon, 26 Sep 2011 05:03:27 -0700 (PDT) Received: by 10.142.154.18 with HTTP; Mon, 26 Sep 2011 05:03:27 -0700 (PDT) In-Reply-To: <CAFLBxZbHvhK2U1+1i5UFYhJ9SLDLzx2kdmc-C8qnUbXb-eGsQw@mail.gmail.com> References: <CAFLBxZbHvhK2U1+1i5UFYhJ9SLDLzx2kdmc-C8qnUbXb-eGsQw@mail.gmail.com> Date: Mon, 26 Sep 2011 14:03:27 +0200 X-Google-Sender-Auth: NtrZxuhUQ_YQWWrENyk4H2cQ1FY Message-ID: <CAPLaKK5gJ8BfDCKfNAv_zDXc+jDHMq1D6hUH+eLYfcbjPjhW4g@mail.gmail.com> Subject: Re: [Xen-devel] [RFC] SubmittingXenPatches wiki page From: =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= <roger.pau@entel.upc.edu> To: George Dunlap <dunlapg@umich.edu> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Cc: xen-devel@lists.xensource.com X-BeenThere: xen-devel@lists.xensource.com X-Mailman-Version: 2.1.5 Precedence: list List-Id: Xen developer discussion <xen-devel.lists.xensource.com> List-Unsubscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe> List-Post: <mailto:xen-devel@lists.xensource.com> List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help> List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=subscribe> Sender: xen-devel-bounces@lists.xensource.com Errors-To: xen-devel-bounces@lists.xensource.com You can also edit commit messages by using hg qrefresh -e instead of opening every patch file and changing it manually. 2011/9/26 George Dunlap <dunlapg@umich.edu>: > I've made a new version of the SubmittingXenPatches wiki page that > suggest using mercurial queues and patchbomb extension, instead of the > rather daft "clone a repository, commit changes, and then do hg > export" method. > > I created it here: > http://wiki.xensource.com/xenwiki/SubmittingXenPatches2 > > Please skim it and comment on it. =C2=A0If there are no objections, I sha= ll > replace the original SubmittingXenPatches in a few days. > > =C2=A0-George > > _______________________________________________ > Xen-devel mailing list > Xen-devel@lists.xensource.com > http://lists.xensource.com/xen-devel > _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel From xen-devel-bounces@lists.xensource.com Mon Sep 26 06:10:24 2011 Return-path: <xen-devel-bounces@lists.xensource.com> Envelope-to: www-data@lists.xensource.com Delivery-date: Mon, 26 Sep 2011 06:10:24 -0700 Received: from localhost ([127.0.0.1] helo=lists.colo.xensource.com) by lists.xensource.com with esmtp (Exim 4.43) id 1R8Aww-0005U1-Oo; Mon, 26 Sep 2011 06:10:22 -0700 Received: from mail21.messagelabs.com ([85.158.143.35]) by lists.xensource.com with esmtp (Exim 4.43) id 1R8Aw4-0005HB-5x for xen-devel@lists.xensource.com; Mon, 26 Sep 2011 06:09:29 -0700 X-Env-Sender: Ian.Jackson@eu.citrix.com X-Msg-Ref: server-6.tower-21.messagelabs.com!1317042545!39681606!1 X-Originating-IP: [62.200.22.115] X-StarScan-Version: 6.4.1; banners=-,-,- X-VirusChecked: Checked Received: (qmail 7297 invoked from network); 26 Sep 2011 13:09:05 -0000 Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115) by server-6.tower-21.messagelabs.com with RC4-SHA encrypted SMTP; 26 Sep 2011 13:09:05 -0000 X-IronPort-AV: E=Sophos;i="4.68,444,1312156800"; d="scan'208";a="8061312" Received: from lonpmailmx01.citrite.net ([10.30.203.162]) by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5; 26 Sep 2011 13:09:24 +0000 Received: from woking.xci-test.com (10.80.248.135) by smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id 8.3.137.0; Mon, 26 Sep 2011 14:09:25 +0100 Received: from osstest by woking.xci-test.com with local (Exim 4.69) (envelope-from <ian.jackson@eu.citrix.com>) id 1R8Aw0-0000Tx-Fi; Mon, 26 Sep 2011 14:09:24 +0100 To: xen-devel@lists.xensource.com Message-ID: <osstest-9085-mainreport@xen.org> From: xen.org <ian.jackson@eu.citrix.com> Date: Mon, 26 Sep 2011 14:09:24 +0100 MIME-Version: 1.0 Content-Type: text/plain Cc: ian.jackson@eu.citrix.com Subject: [Xen-devel] [xen-unstable test] 9085: regressions - FAIL X-BeenThere: xen-devel@lists.xensource.com X-Mailman-Version: 2.1.5 Precedence: list List-Id: Xen developer discussion <xen-devel.lists.xensource.com> List-Unsubscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe> List-Post: <mailto:xen-devel@lists.xensource.com> List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help> List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=subscribe> Sender: xen-devel-bounces@lists.xensource.com Errors-To: xen-devel-bounces@lists.xensource.com flight 9085 xen-unstable real [real] http://www.chiark.greenend.org.uk/~xensrcts/logs/9085/ Regressions :-( Tests which did not succeed and are blocking: test-amd64-i386-rhel6hvm-amd 5 xen-boot fail REGR. vs. 8995 Tests which are failing intermittently (not blocking): test-amd64-i386-pv 5 xen-boot fail pass in 9083 test-amd64-amd64-xl 5 xen-boot fail pass in 9083 test-amd64-amd64-pv 5 xen-boot fail pass in 9083 test-amd64-i386-xl 5 xen-boot fail pass in 9083 test-amd64-i386-rhel6hvm-intel 7 redhat-install fail pass in 9083 test-amd64-amd64-xl-sedf 5 xen-boot fail pass in 9083 test-i386-i386-xl-win 5 xen-boot fail pass in 9083 test-amd64-i386-xl-win-vcpus1 5 xen-boot fail pass in 9081 test-i386-i386-win 5 xen-boot fail pass in 9083 test-amd64-i386-win-vcpus1 5 xen-boot fail pass in 9079 test-amd64-i386-win 5 xen-boot fail pass in 9079 test-amd64-i386-xl-multivcpu 5 xen-boot fail in 9083 pass in 9085 test-amd64-i386-xl-credit2 5 xen-boot fail in 9083 pass in 9085 test-i386-i386-xl 5 xen-boot fail in 9083 pass in 9085 test-amd64-i386-pair 7 xen-boot/src_host fail in 9083 pass in 9085 test-amd64-i386-pair 8 xen-boot/dst_host fail in 9083 pass in 9085 test-amd64-amd64-win 5 xen-boot fail in 9083 pass in 9085 test-amd64-amd64-xl-win 5 xen-boot fail in 9083 pass in 9085 test-i386-i386-pv 5 xen-boot fail in 9081 pass in 9085 test-amd64-amd64-xl-sedf 7 debian-install fail in 9081 pass in 9083 test-i386-i386-pair 7 xen-boot/src_host fail in 9079 pass in 9085 test-i386-i386-pair 8 xen-boot/dst_host fail in 9079 pass in 9085 Tests which did not succeed, but are not blocking, including regressions (tests previously passed) regarded as allowable: test-amd64-amd64-xl-pcipt-intel 9 guest-start fail never pass test-amd64-amd64-win 16 leak-check/check fail never pass test-amd64-amd64-xl-win 13 guest-stop fail never pass test-amd64-i386-rhel6hvm-intel 9 guest-start.2 fail in 9083 never pass test-i386-i386-xl-win 13 guest-stop fail in 9083 never pass test-i386-i386-win 16 leak-check/check fail in 9083 never pass test-amd64-i386-xl-win-vcpus1 13 guest-stop fail in 9081 never pass test-amd64-i386-win-vcpus1 16 leak-check/check fail in 9079 never pass test-amd64-i386-win 16 leak-check/check fail in 9079 never pass version targeted for testing: xen cc339ab1d917 baseline version: xen a422e2a4451e ------------------------------------------------------------ People who touched revisions under test: Andreas Herrmann <herrmann.der.user@googlemail.com> Ian Campbell <ian.campbell@citrix.com> Ian Jackson <ian.jackson@eu.citrix.com> Jan Beulich <jbeulich@suse.com> Lasse Collin <lasse.collin@tukaani.org> Olaf Hering <olaf@aepfle.de> Thomas Renninger <trenn@suse.de> ------------------------------------------------------------ jobs: build-amd64 pass build-i386 pass build-amd64-oldkern pass build-i386-oldkern pass build-amd64-pvops pass build-i386-pvops pass test-amd64-amd64-xl fail test-amd64-i386-xl fail test-i386-i386-xl pass test-amd64-i386-rhel6hvm-amd fail test-amd64-i386-xl-credit2 pass test-amd64-amd64-xl-pcipt-intel fail test-amd64-i386-rhel6hvm-intel fail test-amd64-i386-xl-multivcpu pass test-amd64-amd64-pair pass test-amd64-i386-pair pass test-i386-i386-pair pass test-amd64-amd64-pv fail test-amd64-i386-pv fail test-i386-i386-pv pass test-amd64-amd64-xl-sedf fail test-amd64-i386-win-vcpus1 fail test-amd64-i386-xl-win-vcpus1 fail test-amd64-amd64-win fail test-amd64-i386-win fail test-i386-i386-win fail test-amd64-amd64-xl-win fail test-i386-i386-xl-win fail ------------------------------------------------------------ sg-report-flight on woking.cam.xci-test.com logs: /home/xc_osstest/logs images: /home/xc_osstest/images Logs, config files, etc. are available at http://www.chiark.greenend.org.uk/~xensrcts/logs Test harness code can be found at http://xenbits.xensource.com/gitweb?p=osstest.git;a=summary Not pushing. ------------------------------------------------------------ changeset: 23872:cc339ab1d917 tag: tip user: Ian Campbell <ian.campbell@citrix.com> date: Thu Sep 22 18:37:06 2011 +0100 tools: fix install of lomount $(BIN) went away in 23124:e3d4c34b14a3. Also there are no *.so, *.a or *.rpm built in here Signed-off-by: Ian Campbell <ian.campbell@citrix.com> changeset: 23871:503ee256fecf user: Jan Beulich <jbeulich@suse.com> date: Thu Sep 22 18:35:30 2011 +0100 x86: ucode-amd: Don't warn when no ucode is available for a CPU revision This patch originally comes from the Linus mainline kernel (2.6.33), find below the patch details: From: Andreas Herrmann <herrmann.der.user@googlemail.com> There is no point in warning when there is no ucode available for a specific CPU revision. Currently the container-file, which provides the AMD ucode patches for OS load, contains only a few ucode patches. It's already clearly indicated by the printed patch_level whenever new ucode was available and an update happened. So the warning message is of no help but rather annoying on systems with many CPUs. Signed-off-by: Thomas Renninger <trenn@suse.de> Signed-off-by: Jan Beulich <jbeulich@suse.com> changeset: 23870:5c97b02f48fc user: Jan Beulich <jbeulich@suse.com> date: Thu Sep 22 18:34:27 2011 +0100 XZ: Fix incorrect XZ_BUF_ERROR From: Lasse Collin <lasse.collin@tukaani.org> xz_dec_run() could incorrectly return XZ_BUF_ERROR if all of the following was true: - The caller knows how many bytes of output to expect and only provides that much output space. - When the last output bytes are decoded, the caller-provided input buffer ends right before the LZMA2 end of payload marker. So LZMA2 won't provide more output anymore, but it won't know it yet and thus won't return XZ_STREAM_END yet. - A BCJ filter is in use and it hasn't left any unfiltered bytes in the temp buffer. This can happen with any BCJ filter, but in practice it's more likely with filters other than the x86 BCJ. This fixes <https://bugzilla.redhat.com/show_bug.cgi?id=3D735408> where Squashfs thinks that a valid file system is corrupt. This also fixes a similar bug in single-call mode where the uncompressed size of a block using BCJ + LZMA2 was 0 bytes and caller provided no output space. Many empty .xz files don't contain any blocks and thus don't trigger this bug. This also tweaks a closely related detail: xz_dec_bcj_run() could call xz_dec_lzma2_run() to decode into temp buffer when it was known to be useless. This was harmless although it wasted a minuscule number of CPU cycles. Signed-off-by: Lasse Collin <lasse.collin@tukaani.org> Signed-off-by: Jan Beulich <jbeulich@suse.com> changeset: 23869:db1ea4b127cd user: Jan Beulich <jbeulich@suse.com> date: Thu Sep 22 18:33:48 2011 +0100 XZ decompressor: Fix decoding of empty LZMA2 streams From: Lasse Collin <lasse.collin@tukaani.org> The old code considered valid empty LZMA2 streams to be corrupt. Note that a typical empty .xz file has no LZMA2 data at all, and thus most .xz files having no uncompressed data are handled correctly even without this fix. Signed-off-by: Lasse Collin <lasse.collin@tukaani.org> Signed-off-by: Jan Beulich <jbeulich@suse.com> changeset: 23868:28147fd781af user: Jan Beulich <jbeulich@suse.com> date: Thu Sep 22 18:32:34 2011 +0100 VT-d: fix off-by-one error in RMRR validation (base_addr,end_addr) is an inclusive range, and hence there shouldn't be a subtraction of 1 in the second invocation of page_is_ram_type(). For RMRRs covering a single page that actually resulted in the immediately preceding page to get checked (which could have resulted in a false warning). Signed-off-by: Jan Beulich <jbeulich@suse.com> changeset: 23867:571b6e90dfb4 user: Jan Beulich <jbeulich@suse.com> date: Thu Sep 22 18:31:44 2011 +0100 VT-d: eliminate a mis-use of pcidevs_lock dma_pte_clear_one() shouldn't acquire this global lock for the purpose of processing a per-domain list. Furthermore the function a few lines earlier has a comment stating that acquiring pcidevs_lock isn't necessary here (whether that's really correct is another question). Use the domain's mappin_lock instead to protect the mapped_rmrrs list. Fold domain_rmrr_mapped() into its sole caller so that the otherwise implicit dependency on pcidevs_lock there becomes more obvious (see the comment there). Signed-off-by: Jan Beulich <jbeulich@suse.com> changeset: 23866:47ec1d405af9 user: Jan Beulich <jbeulich@suse.com> date: Thu Sep 22 18:31:02 2011 +0100 x86: IO-APIC code has no dependency on PCI The IRQ handling code requires pcidevs_lock to be held only for MSI interrupts. As the handling of which was now fully moved into msi.c (i.e. while applying fine without, the patch needs to be applied after the one titled "x86: split MSI IRQ chip"), io_apic.c now also doesn't need to include PCI headers anymore. Signed-off-by: Jan Beulich <jbeulich@suse.com> changeset: 23865:d6e01c7853cf user: Jan Beulich <jbeulich@suse.com> date: Thu Sep 22 18:29:19 2011 +0100 PCI multi-seg: config space accessor adjustments Signed-off-by: Jan Beulich <jbeulich@suse.com> changeset: 23864:314b147d524d user: Jan Beulich <jbeulich@suse.com> date: Thu Sep 22 18:28:38 2011 +0100 PCI multi-seg: Pass-through adjustments Signed-off-by: Jan Beulich <jbeulich@suse.com> changeset: 23863:9e0259239822 user: Jan Beulich <jbeulich@suse.com> date: Thu Sep 22 18:28:03 2011 +0100 PCI multi-seg: AMD-IOMMU specific adjustments There are two places here where it is entirely unclear to me where the necessary PCI segment number should be taken from (as IVMD descriptors don't have such, only IVHD ones do). AMD confirmed that for the time being it is acceptable to imply that only segment 0 exists. Signed-off-by: Jan Beulich <jbeulich@suse.com> changeset: 23862:85418e168527 user: Jan Beulich <jbeulich@suse.com> date: Thu Sep 22 18:27:26 2011 +0100 PCI multi-seg: VT-d specific adjustments Signed-off-by: Jan Beulich <jbeulich@suse.com> changeset: 23861:ec7c81fbe0de user: Jan Beulich <jbeulich@suse.com> date: Thu Sep 22 18:26:54 2011 +0100 PCI multi-seg: adjust domctl interface Again, a couple of directly related functions at once get adjusted to account for the segment number. Signed-off-by: Jan Beulich <jbeulich@suse.com> changeset: 23860:a422e2a4451e user: Jan Beulich <jbeulich@suse.com> date: Sun Sep 18 00:26:52 2011 +0100 x86: split MSI IRQ chip With the .end() accessor having become optional and noting that several of the accessors' behavior really depends on the result of msi_maskable_irq(), the splits the MSI IRQ chip type into two - one for the maskable ones, and the other for the (MSI only) non-maskable ones. At once the implementation of those methods gets moved from io_apic.c to msi.c. Signed-off-by: Jan Beulich <jbeulich@suse.com> ======================================== commit cd776ee9408ff127f934a707c1a339ee600bc127 Author: Ian Jackson <ian.jackson@eu.citrix.com> Date: Tue Jun 28 13:50:53 2011 +0100 qemu-char.c: fix incorrect CONFIG_STUBDOM handling qemu-char.c:1123:7: warning: "CONFIG_STUBDOM" is not defined [-Wundef] Signed-off-by: Olaf Hering <olaf@aepfle.de> Acked-by: Ian Jackson <ian.jackson@eu.citrix.com> _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel From xen-devel-bounces@lists.xensource.com Mon Sep 26 06:15:11 2011 Return-path: <xen-devel-bounces@lists.xensource.com> Envelope-to: www-data@lists.xensource.com Delivery-date: Mon, 26 Sep 2011 06:15:11 -0700 Received: from localhost ([127.0.0.1] helo=lists.colo.xensource.com) by lists.xensource.com with esmtp (Exim 4.43) id 1R8B1b-0005ub-Bw; Mon, 26 Sep 2011 06:15:11 -0700 Received: from mail174.messagelabs.com ([85.158.138.51]) by lists.xensource.com with esmtp (Exim 4.43) id 1R8B17-0005i1-0I for xen-devel@lists.xensource.com; Mon, 26 Sep 2011 06:14:41 -0700 X-Env-Sender: konrad@oracle.com X-Msg-Ref: server-15.tower-174.messagelabs.com!1317042873!26439065!1 X-Originating-IP: [141.146.126.227] X-StarScan-Version: 6.4.1; banners=-,-,- X-VirusChecked: Checked Received: (qmail 30902 invoked from network); 26 Sep 2011 13:14:36 -0000 Received: from acsinet15.oracle.com (HELO acsinet15.oracle.com) (141.146.126.227) by server-15.tower-174.messagelabs.com with DHE-RSA-AES256-SHA encrypted SMTP; 26 Sep 2011 13:14:36 -0000 Received: from rtcsinet21.oracle.com (rtcsinet21.oracle.com [66.248.204.29]) by acsinet15.oracle.com (Switch-3.4.4/Switch-3.4.4) with ESMTP id p8QDDjZr018816 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Mon, 26 Sep 2011 13:13:48 GMT Received: from acsmt358.oracle.com (acsmt358.oracle.com [141.146.40.158]) by rtcsinet21.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id p8QDDhdr005586 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 26 Sep 2011 13:13:44 GMT Received: from abhmt118.oracle.com (abhmt118.oracle.com [141.146.116.70]) by acsmt358.oracle.com (8.12.11.20060308/8.12.11) with ESMTP id p8QDDb5x030873; Mon, 26 Sep 2011 08:13:37 -0500 Received: from oracle.com (/209.6.55.207) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Mon, 26 Sep 2011 06:13:37 -0700 Received: by oracle.com (Postfix, from userid 1000) id 2DC561551; Mon, 26 Sep 2011 09:13:30 -0400 (EDT) From: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com> To: linux-kernel@vger.kernel.org, jeremy@goop.org Date: Mon, 26 Sep 2011 09:13:17 -0400 Message-Id: <1317042797-19975-1-git-send-email-konrad.wilk@oracle.com> X-Mailer: git-send-email 1.7.4.1 X-Source-IP: rtcsinet21.oracle.com [66.248.204.29] X-CT-RefId: str=0001.0A090202.4E807A8D.00D9,ss=1,re=0.000,fgs=0 Cc: xen-devel@lists.xensource.com, Peter Zijlstra <a.p.zijlstra@chello.nl>, Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>, x86@kernel.org, Jeremy Fitzhardinge <jeremy.fitzhardinge@citrix.com>, Ingo Molnar <mingo@redhat.com>, "H. Peter Anvin" <hpa@zytor.com>, Thomas Gleixner <tglx@linutronix.de>, stable@kernel.org Subject: [Xen-devel] [PATCH] x86/paravirt: Partially revert "remove lazy mode in interrupts" X-BeenThere: xen-devel@lists.xensource.com X-Mailman-Version: 2.1.5 Precedence: list List-Id: Xen developer discussion <xen-devel.lists.xensource.com> List-Unsubscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe> List-Post: <mailto:xen-devel@lists.xensource.com> List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help> List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=subscribe> Sender: xen-devel-bounces@lists.xensource.com Errors-To: xen-devel-bounces@lists.xensource.com which has git commit b8bcfe997e46150fedcc3f5b26b846400122fdd9. The unintended consequence of removing the flushing of MMU updates when doing kmap_atomic (or kunmap_atomic) is that we can hit a dereference bug when processing a "fork()" under a heavy loaded machine. Specifically we can hit: BUG: unable to handle kernel paging request at f573fc8c IP: [<c01abc54>] swap_count_continued+0x104/0x180 *pdpt = 000000002a3b9027 *pde = 0000000001bed067 *pte = 0000000000000000 Oops: 0000 [#1] SMP Modules linked in: Pid: 1638, comm: apache2 Not tainted 3.0.4-linode37 #1 EIP: 0061:[<c01abc54>] EFLAGS: 00210246 CPU: 3 EIP is at swap_count_continued+0x104/0x180 .. snip.. Call Trace: [<c01ac222>] ? __swap_duplicate+0xc2/0x160 [<c01040f7>] ? pte_mfn_to_pfn+0x87/0xe0 [<c01ac2e4>] ? swap_duplicate+0x14/0x40 [<c01a0a6b>] ? copy_pte_range+0x45b/0x500 [<c01a0ca5>] ? copy_page_range+0x195/0x200 [<c01328c6>] ? dup_mmap+0x1c6/0x2c0 [<c0132cf8>] ? dup_mm+0xa8/0x130 [<c013376a>] ? copy_process+0x98a/0xb30 [<c013395f>] ? do_fork+0x4f/0x280 [<c01573b3>] ? getnstimeofday+0x43/0x100 [<c010f770>] ? sys_clone+0x30/0x40 [<c06c048d>] ? ptregs_clone+0x15/0x48 [<c06bfb71>] ? syscall_call+0x7/0xb The problem looks that in copy_page_range we turn lazy mode on, and then in swap_entry_free we call swap_count_continued which ends up in: map = kmap_atomic(page, KM_USER0) + offset; and then later touches *map. Since we are running in batched mode (lazy) we don't actually set up the PTE mappings and the kmap_atomic is not done synchronously and ends up trying to dereference a page that has not been set. Looking at kmap_atomic_prot_pfn, it uses 'arch_flush_lazy_mmu_mode' and sprinkling that in kmap_atomic_prot and __kunmap_atomic makes the problem go away. CC: Thomas Gleixner <tglx@linutronix.de> CC: Ingo Molnar <mingo@redhat.com> CC: "H. Peter Anvin" <hpa@zytor.com> CC: x86@kernel.org CC: Peter Zijlstra <a.p.zijlstra@chello.nl> CC: Jeremy Fitzhardinge <jeremy.fitzhardinge@citrix.com> CC: stable@kernel.org Signed-off-by: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com> --- arch/x86/mm/highmem_32.c | 2 ++ 1 files changed, 2 insertions(+), 0 deletions(-) diff --git a/arch/x86/mm/highmem_32.c b/arch/x86/mm/highmem_32.c index b499626..f4f29b1 100644 --- a/arch/x86/mm/highmem_32.c +++ b/arch/x86/mm/highmem_32.c @@ -45,6 +45,7 @@ void *kmap_atomic_prot(struct page *page, pgprot_t prot) vaddr = __fix_to_virt(FIX_KMAP_BEGIN + idx); BUG_ON(!pte_none(*(kmap_pte-idx))); set_pte(kmap_pte-idx, mk_pte(page, prot)); + arch_flush_lazy_mmu_mode(); return (void *)vaddr; } @@ -88,6 +89,7 @@ void __kunmap_atomic(void *kvaddr) */ kpte_clear_flush(kmap_pte-idx, vaddr); kmap_atomic_idx_pop(); + arch_flush_lazy_mmu_mode(); } #ifdef CONFIG_DEBUG_HIGHMEM else { -- 1.7.4.1 _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel From xen-devel-bounces@lists.xensource.com Mon Sep 26 06:31:34 2011 Return-path: <xen-devel-bounces@lists.xensource.com> Envelope-to: www-data@lists.xensource.com Delivery-date: Mon, 26 Sep 2011 06:31:34 -0700 Received: from localhost ([127.0.0.1] helo=lists.colo.xensource.com) by lists.xensource.com with esmtp (Exim 4.43) id 1R8BHS-0006VH-00; Mon, 26 Sep 2011 06:31:34 -0700 Received: from mail174.messagelabs.com ([85.158.138.51]) by lists.xensource.com with esmtp (Exim 4.43) id 1R8BGd-0006IY-PY for xen-devel@lists.xensource.com; Mon, 26 Sep 2011 06:30:44 -0700 X-Env-Sender: konrad@oracle.com X-Msg-Ref: server-4.tower-174.messagelabs.com!1317043839!32805794!1 X-Originating-IP: [141.146.126.227] X-StarScan-Version: 6.4.1; banners=-,-,- X-VirusChecked: Checked Received: (qmail 1273 invoked from network); 26 Sep 2011 13:30:40 -0000 Received: from acsinet15.oracle.com (HELO acsinet15.oracle.com) (141.146.126.227) by server-4.tower-174.messagelabs.com with DHE-RSA-AES256-SHA encrypted SMTP; 26 Sep 2011 13:30:40 -0000 Received: from rtcsinet21.oracle.com (rtcsinet21.oracle.com [66.248.204.29]) by acsinet15.oracle.com (Switch-3.4.4/Switch-3.4.4) with ESMTP id p8QDUa1N014906 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Mon, 26 Sep 2011 13:30:38 GMT Received: from acsmt358.oracle.com (acsmt358.oracle.com [141.146.40.158]) by rtcsinet21.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id p8QDUZL4025989 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 26 Sep 2011 13:30:35 GMT Received: from abhmt103.oracle.com (abhmt103.oracle.com [141.146.116.55]) by acsmt358.oracle.com (8.12.11.20060308/8.12.11) with ESMTP id p8QDUTUO012406; Mon, 26 Sep 2011 08:30:29 -0500 Received: from oracle.com (/209.6.55.207) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Mon, 26 Sep 2011 06:30:29 -0700 Received: by oracle.com (Postfix, from userid 1000) id A4C6B1551; Mon, 26 Sep 2011 09:30:22 -0400 (EDT) Date: Mon, 26 Sep 2011 09:30:22 -0400 From: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com> To: George Dunlap <dunlapg@umich.edu> Subject: Re: [Xen-devel] [RFC] SubmittingXenPatches wiki page Message-ID: <20110926133022.GA3840@phenom.oracle.com> References: <CAFLBxZbHvhK2U1+1i5UFYhJ9SLDLzx2kdmc-C8qnUbXb-eGsQw@mail.gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <CAFLBxZbHvhK2U1+1i5UFYhJ9SLDLzx2kdmc-C8qnUbXb-eGsQw@mail.gmail.com> User-Agent: Mutt/1.5.21 (2010-09-15) X-Source-IP: rtcsinet21.oracle.com [66.248.204.29] X-CT-RefId: str=0001.0A090203.4E807E7E.0178,ss=1,re=0.000,fgs=0 Cc: xen-devel@lists.xensource.com X-BeenThere: xen-devel@lists.xensource.com X-Mailman-Version: 2.1.5 Precedence: list List-Id: Xen developer discussion <xen-devel.lists.xensource.com> List-Unsubscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe> List-Post: <mailto:xen-devel@lists.xensource.com> List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help> List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=subscribe> Sender: xen-devel-bounces@lists.xensource.com Errors-To: xen-devel-bounces@lists.xensource.com On Mon, Sep 26, 2011 at 12:43:59PM +0100, George Dunlap wrote: > I've made a new version of the SubmittingXenPatches wiki page that > suggest using mercurial queues and patchbomb extension, instead of the > rather daft "clone a repository, commit changes, and then do hg > export" method. > > I created it here: > http://wiki.xensource.com/xenwiki/SubmittingXenPatches2 > > Please skim it and comment on it. If there are no objections, I shall > replace the original SubmittingXenPatches in a few days. might want to add: [ui] username = Konrad Rzeszutek Wilk <konrad.wilk@oracle.com> > > -George > > _______________________________________________ > Xen-devel mailing list > Xen-devel@lists.xensource.com > http://lists.xensource.com/xen-devel _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel From xen-devel-bounces@lists.xensource.com Mon Sep 26 06:58:57 2011 Return-path: <xen-devel-bounces@lists.xensource.com> Envelope-to: www-data@lists.xensource.com Delivery-date: Mon, 26 Sep 2011 06:58:57 -0700 Received: from localhost ([127.0.0.1] helo=lists.colo.xensource.com) by lists.xensource.com with esmtp (Exim 4.43) id 1R8Bhw-0007SM-Tq; Mon, 26 Sep 2011 06:58:57 -0700 Received: from mail174.messagelabs.com ([85.158.138.51]) by lists.xensource.com with esmtp (Exim 4.43) id 1R8BgY-0007FJ-WC for xen-devel@lists.xensource.com; Mon, 26 Sep 2011 06:57:31 -0700 X-Env-Sender: pasik@iki.fi X-Msg-Ref: server-8.tower-174.messagelabs.com!1317045447!19108833!1 X-Originating-IP: [192.89.123.25] X-StarScan-Version: 6.4.1; banners=-,-,- X-VirusChecked: Checked Received: (qmail 10294 invoked from network); 26 Sep 2011 13:57:28 -0000 Received: from smtp.tele.fi (HELO smtp.tele.fi) (192.89.123.25) by server-8.tower-174.messagelabs.com with DHE-RSA-AES256-SHA encrypted SMTP; 26 Sep 2011 13:57:28 -0000 X-Originating-Ip: [194.89.68.22] Received: from ydin.reaktio.net (reaktio.net [194.89.68.22]) by smtp.tele.fi (Postfix) with ESMTP id E67C82F1C; Mon, 26 Sep 2011 16:57:26 +0300 (EEST) Received: by ydin.reaktio.net (Postfix, from userid 1001) id CF74E200E8; Mon, 26 Sep 2011 16:57:26 +0300 (EEST) Date: Mon, 26 Sep 2011 16:57:26 +0300 From: Pasi =?iso-8859-1?Q?K=E4rkk=E4inen?= <pasik@iki.fi> To: Stephen More <stephen.more@gmail.com> Subject: Re: [Xen-devel] Please report to - xm new Message-ID: <20110926135726.GK12984@reaktio.net> References: <CAL2vA_N6ZPsZyqReEEEs_+DwbNKfrZpcEEVcUY4-qTo=kBrL5w@mail.gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <CAL2vA_N6ZPsZyqReEEEs_+DwbNKfrZpcEEVcUY4-qTo=kBrL5w@mail.gmail.com> User-Agent: Mutt/1.5.18 (2008-05-17) Cc: xen-devel@lists.xensource.com X-BeenThere: xen-devel@lists.xensource.com X-Mailman-Version: 2.1.5 Precedence: list List-Id: Xen developer discussion <xen-devel.lists.xensource.com> List-Unsubscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe> List-Post: <mailto:xen-devel@lists.xensource.com> List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help> List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=subscribe> Sender: xen-devel-bounces@lists.xensource.com Errors-To: xen-devel-bounces@lists.xensource.com On Sun, Sep 25, 2011 at 04:38:00PM -0400, Stephen More wrote: > I installed the beta version of oneiric and got this error: > > root@g4-01:~# xm new > Unexpected error: <type 'exceptions.ImportError'> > > Please report to xen-devel@lists.xensource.com > Traceback (most recent call last): > File "/usr/lib/xen-4.1/bin/xm", line 8, in <module> > main.main(sys.argv) > File "/usr/lib/xen-4.1/bin/../lib/python/xen/xm/main.py", line 3983, in main > _, rc = _run_cmd(cmd, cmd_name, args) > File "/usr/lib/xen-4.1/bin/../lib/python/xen/xm/main.py", line 4007, > in _run_cmd > return True, cmd(args) > File "<string>", line 1, in <lambda> > File "/usr/lib/xen-4.1/bin/../lib/python/xen/xm/main.py", line 1518, > in xm_importcommand > cmd = __import__(command, globals(), locals(), 'xen.xm') > File "/usr/lib/xen-4.1/bin/../lib/python/xen/xm/new.py", line 26, in <module> > from xen.xm.xenapi_create import * > File "/usr/lib/xen-4.1/bin/../lib/python/xen/xm/xenapi_create.py", > line 24, in <module> > from lxml import etree > ImportError: No module named lxml > root@g4-01:~# > Hey, Do you have python xml modules installed? -- Pasi _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel From xen-devel-bounces@lists.xensource.com Mon Sep 26 07:02:13 2011 Return-path: <xen-devel-bounces@lists.xensource.com> Envelope-to: www-data@lists.xensource.com Delivery-date: Mon, 26 Sep 2011 07:02:13 -0700 Received: from localhost ([127.0.0.1] helo=lists.colo.xensource.com) by lists.xensource.com with esmtp (Exim 4.43) id 1R8Bl7-0007uJ-0Q; Mon, 26 Sep 2011 07:02:13 -0700 Received: from mail182.messagelabs.com ([85.158.139.83]) by lists.xensource.com with esmtp (Exim 4.43) id 1R8Bie-0007X2-Ka for xen-devel@lists.xensource.com; Mon, 26 Sep 2011 07:00:06 -0700 X-Env-Sender: konrad@oracle.com X-Msg-Ref: server-7.tower-182.messagelabs.com!1317045575!14775276!1 X-Originating-IP: [148.87.113.117] X-StarScan-Version: 6.4.1; banners=-,-,- X-VirusChecked: Checked Received: (qmail 11755 invoked from network); 26 Sep 2011 13:59:37 -0000 Received: from rcsinet15.oracle.com (HELO rcsinet15.oracle.com) (148.87.113.117) by server-7.tower-182.messagelabs.com with DHE-RSA-AES256-SHA encrypted SMTP; 26 Sep 2011 13:59:37 -0000 Received: from rtcsinet22.oracle.com (rtcsinet22.oracle.com [66.248.204.30]) by rcsinet15.oracle.com (Switch-3.4.4/Switch-3.4.4) with ESMTP id p8QDxXKF002736 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Mon, 26 Sep 2011 13:59:35 GMT Received: from acsmt357.oracle.com (acsmt357.oracle.com [141.146.40.157]) by rtcsinet22.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id p8QDxSuQ029734 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 26 Sep 2011 13:59:29 GMT Received: from abhmt113.oracle.com (abhmt113.oracle.com [141.146.116.65]) by acsmt357.oracle.com (8.12.11.20060308/8.12.11) with ESMTP id p8QDxGet016270; Mon, 26 Sep 2011 08:59:23 -0500 Received: from oracle.com (/209.6.55.207) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Mon, 26 Sep 2011 06:59:16 -0700 Received: by oracle.com (Postfix, from userid 1000) id 9E7031551; Mon, 26 Sep 2011 09:59:09 -0400 (EDT) Date: Mon, 26 Sep 2011 09:59:09 -0400 From: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com> To: Anthony Wright <anthony@overnetdata.com> Subject: Re: [Xen-devel] Getting IOAPIC errors in xl dmesg on old hardware Message-ID: <20110926135909.GB4102@phenom.oracle.com> References: <4E7C60B1.3000901@overnetdata.com> <20110923133341.GD19579@phenom.oracle.com> <4E7C8C00.2050806@overnetdata.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <4E7C8C00.2050806@overnetdata.com> User-Agent: Mutt/1.5.21 (2010-09-15) X-Source-IP: rtcsinet22.oracle.com [66.248.204.30] X-CT-RefId: str=0001.0A090209.4E808547.007A,ss=1,re=0.000,fgs=0 Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com> X-BeenThere: xen-devel@lists.xensource.com X-Mailman-Version: 2.1.5 Precedence: list List-Id: Xen developer discussion <xen-devel.lists.xensource.com> List-Unsubscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe> List-Post: <mailto:xen-devel@lists.xensource.com> List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help> List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=subscribe> Sender: xen-devel-bounces@lists.xensource.com Errors-To: xen-devel-bounces@lists.xensource.com On Fri, Sep 23, 2011 at 02:39:12PM +0100, Anthony Wright wrote: > On 23/09/2011 14:33, Konrad Rzeszutek Wilk wrote: > > On Fri, Sep 23, 2011 at 11:34:25AM +0100, Anthony Wright wrote: > >> I am getting a series of IOAPIC errors in xl dmesg on a Dell OptiPlex > >> GX100 machine (bought in 2000). I also get an error from traps.c which > >> is very similar to the one in the 'Getting mm.c errors from xl dmesg on > >> certain hardware' thread. This happens during system startup with no > >> DomUs running. I have attached the xl dmesg log. > >> __ __ _ _ _ _ > >> \ \/ /___ _ __ | || | / | / | > >> \ // _ \ '_ \ | || |_ | | | | > >> / \ __/ | | | |__ _|| |_| | > >> /_/\_\___|_| |_| |_|(_)_(_)_| > >> > >> (XEN) Xen version 4.1.1 (@[unknown]) (gcc version 4.4.3 (GCC) ) Wed Sep 21 08:25:36 GMT 2011 > >> (XEN) Latest ChangeSet: unavailable > >> (XEN) Bootloader: GNU GRUB 0.97 > >> (XEN) Command line: > >> (XEN) Video information: > >> (XEN) VGA is text mode 80x25, font 8x16 > >> (XEN) VBE/DDC methods: V2; EDID transfer time: 1 seconds > >> (XEN) Disc information: > >> (XEN) Found 0 MBR signatures > >> (XEN) Found 0 EDD information structures > >> (XEN) Xen-e820 RAM map: > >> (XEN) 0000000000000000 - 00000000000a0000 (usable) > >> (XEN) 00000000000f0000 - 0000000000100000 (reserved) > >> (XEN) 0000000000100000 - 000000001feae000 (usable) > >> (XEN) 000000001feae000 - 0000000020000000 (reserved) > >> (XEN) 00000000ffb00000 - 0000000100000000 (reserved) > >> (XEN) System RAM: 510MB (522552kB) > > Is that right? 512MB? > Yup 512MB > > 3.4.1 with 2.6.18 works fine on it. 4.4.1 with 3.0.4 also seems to work > fine, though it does seem to use an awful lot of ram (something I'm > going to have a closer look at shortly). It's just that I get these Probably Xen-SWIOTLB eating up 64MB, then there are the per_cpu maps and whole bunch of other stuff.. > error messages in 'xl dmesg', and wondered whether I can safely ignore > them, or whether they're indicative of a more serious problem. I am not sure what to tell you. Your hardware is well.. so old that I am not going to take a look at this (from a Linux kernel perspective) for a looooong loooooong time. _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel From xen-devel-bounces@lists.xensource.com Mon Sep 26 07:05:42 2011 Return-path: <xen-devel-bounces@lists.xensource.com> Envelope-to: www-data@lists.xensource.com Delivery-date: Mon, 26 Sep 2011 07:05:43 -0700 Received: from localhost ([127.0.0.1] helo=lists.colo.xensource.com) by lists.xensource.com with esmtp (Exim 4.43) id 1R8BoT-0008JV-49; Mon, 26 Sep 2011 07:05:41 -0700 Received: from mail27.messagelabs.com ([193.109.254.147]) by lists.xensource.com with esmtp (Exim 4.43) id 1R8Blv-000842-Ty for xen-devel@lists.xensource.com; Mon, 26 Sep 2011 07:03:21 -0700 X-Env-Sender: konrad@oracle.com X-Msg-Ref: server-12.tower-27.messagelabs.com!1317045762!43968303!1 X-Originating-IP: [141.146.126.227] X-StarScan-Version: 6.4.1; banners=-,-,- X-VirusChecked: Checked Received: (qmail 23652 invoked from network); 26 Sep 2011 14:02:43 -0000 Received: from acsinet15.oracle.com (HELO acsinet15.oracle.com) (141.146.126.227) by server-12.tower-27.messagelabs.com with DHE-RSA-AES256-SHA encrypted SMTP; 26 Sep 2011 14:02:43 -0000 Received: from ucsinet23.oracle.com (ucsinet23.oracle.com [156.151.31.71]) by acsinet15.oracle.com (Switch-3.4.4/Switch-3.4.4) with ESMTP id p8QE2tNu029962 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Mon, 26 Sep 2011 14:02:57 GMT Received: from acsmt358.oracle.com (acsmt358.oracle.com [141.146.40.158]) by ucsinet23.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id p8QE2sA5020656 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 26 Sep 2011 14:02:55 GMT Received: from abhmt105.oracle.com (abhmt105.oracle.com [141.146.116.57]) by acsmt358.oracle.com (8.12.11.20060308/8.12.11) with ESMTP id p8QE2nte007806; Mon, 26 Sep 2011 09:02:49 -0500 Received: from oracle.com (/209.6.55.207) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Mon, 26 Sep 2011 07:02:48 -0700 Received: by oracle.com (Postfix, from userid 1000) id E03801551; Mon, 26 Sep 2011 10:02:41 -0400 (EDT) Date: Mon, 26 Sep 2011 10:02:41 -0400 From: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com> To: Anthony Wright <anthony@overnetdata.com> Subject: Re: [Xen-devel] Getting mm.c errors from xl dmesg on certain hardware Message-ID: <20110926140241.GC4102@phenom.oracle.com> References: <4E7C5F8B.6050509@overnetdata.com> <20110923132940.GB19579@phenom.oracle.com> <4E7C9AEF.602@overnetdata.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable In-Reply-To: <4E7C9AEF.602@overnetdata.com> User-Agent: Mutt/1.5.21 (2010-09-15) X-Source-IP: ucsinet23.oracle.com [156.151.31.71] X-CT-RefId: str=0001.0A090207.4E808612.007E,ss=1,re=-15.000,fgs=0 Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com> X-BeenThere: xen-devel@lists.xensource.com X-Mailman-Version: 2.1.5 Precedence: list List-Id: Xen developer discussion <xen-devel.lists.xensource.com> List-Unsubscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe> List-Post: <mailto:xen-devel@lists.xensource.com> List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help> List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=subscribe> Sender: xen-devel-bounces@lists.xensource.com Errors-To: xen-devel-bounces@lists.xensource.com On Fri, Sep 23, 2011 at 03:42:55PM +0100, Anthony Wright wrote: > On 23/09/2011 14:29, Konrad Rzeszutek Wilk wrote: > > On Fri, Sep 23, 2011 at 11:29:31AM +0100, Anthony Wright wrote: > >> Konrad Rzeszutek Wilk wrote: > >> > >>>> (XEN) mm.c:907:d0 Error getting mfn 3a09c (pfn 55555555) from L1 ent= ry 000000003a09c023 for l1e_owner=3D0, pg_owner=3D0 > >>>> (XEN) mm.c:907:d0 Error getting mfn 3a09d (pfn 55555555) from L1 ent= ry 000000003a09d023 for l1e_owner=3D0, pg_owner=3D0 > >>>> (XEN) mm.c:907:d0 Error getting mfn 3a09e (pfn 55555555) from L1 ent= ry 000000003a09e023 for l1e_owner=3D0, pg_owner=3D0 > >>>> (XEN) mm.c:907:d0 Error getting mfn 3a09f (pfn 55555555) from L1 ent= ry 000000003a09f023 for l1e_owner=3D0, pg_owner=3D0 > >>>> (XEN) traps.c:2388:d0 Domain attempted WRMSR c0010004 from 0x0000ab2= 3d6d622da to 0x000000000000abcd. > >>> Do they show up during bootup? As in do you see those _when_ you laun= ch your guests? > >>> To figure out this particular issue you should try using 'console_to_= ring' (so that > >>> dom0 output and Xen output are mingled togehter) and also post this u= nder a new subject > >>> to not confuse this email thread. > >> The messages show up during the initial dom0 boot, before any domUs are > >> loaded. I've attached a second xl dmesg log which is similar to the > >> first, but the numbers in the error messages are different. > >> > >> The messages are hardware dependant as I don't get them on another > >> system with different hardware configuration but with identical softwa= re. > >> > >> The motherboard is a ASUS M2N68 AM PLUS, with 4GB of RAM. If I remove > >> one of the sticks of ram to take it down to 2GB, the mm.c errors are no > >> longer displayed, but I still get the traps.c message. > >> > > Um, you might want to include 'loglevel=3D9 console=3Dhvc0 initcall_deb= ug' on your Linux line > > so the output from Linux kernel gets intermingled with the Xen. > > > >> mapping kernel into physical memory > >> Xen: setup ISA identity maps > >> about to get started... > >> (XEN) mm.c:907:d0 Error getting mfn 3809c (pfn b602c) from L1 entry 00= 0000003809c023 for l1e_owner=3D0, pg_owner=3D0 > >> (XEN) mm.c:907:d0 Error getting mfn 3809d (pfn b602d) from L1 entry 00= 0000003809d023 for l1e_owner=3D0, pg_owner=3D0 > >> (XEN) mm.c:907:d0 Error getting mfn 3809e (pfn b602e) from L1 entry 00= 0000003809e023 for l1e_owner=3D0, pg_owner=3D0 > >> (XEN) mm.c:907:d0 Error getting mfn 3809f (pfn b602f) from L1 entry 00= 0000003809f023 for l1e_owner=3D0, pg_owner=3D0 > >> (XEN) traps.c:2388:d0 Domain attempted WRMSR c0010004 from 0x00009b27f= e9726ca to 0x000000000000abcd. > I ran with 'console_to_ring conring_size=3D65536' on the xen command line > & 'debug loglevel=3D9 console=3Dhvc0 initcall_debug' on the kernel comman= d line. For the fun of it, can you twiddle with dom0_mem=3D512MB just to see what t= ranspires? Nothing really jumps at me in regards to what could be at fault here. Is th= e .config based on some distro? Or is it a distro's config? >=20 > The output is attached. > __ __ _ _ _ _=20 > \ \/ /___ _ __ | || | / | / | > \ // _ \ '_ \ | || |_ | | | | > / \ __/ | | | |__ _|| |_| | > /_/\_\___|_| |_| |_|(_)_(_)_| > =20 > (XEN) Xen version 4.1.1 (@[unknown]) (gcc version 4.4.3 (GCC) ) Wed Sep 2= 1 08:25:36 GMT 2011 > (XEN) Latest ChangeSet: unavailable > (XEN) Bootloader: GNU GRUB 0.97 > (XEN) Command line: console_to_ring conring_size=3D65536 > (XEN) Video information: > (XEN) VGA is text mode 80x25, font 8x16 > (XEN) VBE/DDC methods: none; EDID transfer time: 0 seconds > (XEN) EDID info not retrieved because no DDC retrieval method detected > (XEN) Disc information: > (XEN) Found 2 MBR signatures > (XEN) Found 2 EDD information structures > (XEN) Xen-e820 RAM map: > (XEN) 0000000000000000 - 000000000009b400 (usable) > (XEN) 000000000009b400 - 00000000000a0000 (reserved) > (XEN) 00000000000e2000 - 0000000000100000 (reserved) > (XEN) 0000000000100000 - 00000000aff90000 (usable) > (XEN) 00000000aff90000 - 00000000aff9e000 (ACPI data) > (XEN) 00000000aff9e000 - 00000000affe0000 (ACPI NVS) > (XEN) 00000000affe0000 - 00000000affee000 (reserved) > (XEN) 00000000afff0000 - 00000000b0000000 (reserved) > (XEN) 00000000fec00000 - 00000000fec01000 (reserved) > (XEN) 00000000fee00000 - 00000000fef00000 (reserved) > (XEN) 00000000fff00000 - 0000000100000000 (reserved) > (XEN) 0000000100000000 - 0000000140000000 (usable) > (XEN) System RAM: 3839MB (3931308kB) > (XEN) ACPI: RSDP 000FB5D0, 0014 (r0 ACPIAM) > (XEN) ACPI: RSDT AFF90000, 0038 (r1 032210 RSDT1037 20100322 MSFT 9= 7) > (XEN) ACPI: FACP AFF90200, 0084 (r2 032210 FACP1037 20100322 MSFT 9= 7) > (XEN) ACPI: DSDT AFF90460, 7307 (r1 A1270 A1270000 0 INTL 2006011= 3) > (XEN) ACPI: FACS AFF9E000, 0040 > (XEN) ACPI: APIC AFF90390, 0090 (r1 032210 APIC1037 20100322 MSFT 9= 7) > (XEN) ACPI: MCFG AFF90420, 003C (r1 032210 OEMMCFG 20100322 MSFT 9= 7) > (XEN) ACPI: OEMB AFF9E040, 0071 (r1 032210 OEMB1037 20100322 MSFT 9= 7) > (XEN) ACPI: HPET AFF97770, 0038 (r1 032210 OEMHPET0 20100322 MSFT 9= 7) > (XEN) Xen heap: 9MB (9788kB) > (XEN) Domain heap initialised > (XEN) Processor #0 0:6 APIC version 16 > (XEN) Processor #1 0:6 APIC version 16 > (XEN) IOAPIC[0]: apic_id 2, version 17, address 0xfec00000, GSI 0-23 > (XEN) Enabling APIC mode: Flat. Using 1 I/O APICs > (XEN) Table is not found! > (XEN) Using scheduler: SMP Credit Scheduler (credit) > (XEN) Detected 3013.751 MHz processor. > (XEN) AMD-Vi: IOMMU not found! > (XEN) I/O virtualisation disabled > (XEN) ENABLING IO-APIC IRQs > (XEN) -> Using new ACK method > (XEN) Platform timer is 25.000MHz HPET > (XEN) Allocated console ring of 4096 KiB. > (XEN) CPU0: AMD SVM Extension is disabled in BIOS. > (XEN) SVM: failed to initialise. > (XEN) Brought up 2 CPUs > (XEN) *** LOADING DOMAIN 0 *** > (XEN) Xen kernel: 32-bit, PAE, lsb > (XEN) Dom0 kernel: 32-bit, PAE, lsb, paddr 0x1000000 -> 0x1b38000 > (XEN) PHYSICAL MEMORY ARRANGEMENT: > (XEN) Dom0 alloc.: 0000000138000000->000000013c000000 (920701 pages to= be allocated) > (XEN) Init. ramdisk: 000000013f6ef000->000000013ffffca4 > (XEN) VIRTUAL MEMORY ARRANGEMENT: > (XEN) Loaded kernel: c1000000->c1b38000 > (XEN) Init. ramdisk: c1b38000->c2448ca4 > (XEN) Phys-Mach map: c2449000->c27de638 > (XEN) Start info: c27df000->c27df47c > (XEN) Page tables: c27e0000->c27fb000 > (XEN) Boot stack: c27fb000->c27fc000 > (XEN) TOTAL: c0000000->c2c00000 > (XEN) ENTRY ADDRESS: c173e000 > (XEN) Dom0 has maximum 2 VCPUs > (XEN) Scrubbing Free RAM: .done. > (XEN) Xen trace buffers: disabled > (XEN) Std. Loglevel: Errors and warnings > (XEN) Guest Loglevel: Nothing (Rate-limited: Errors and warnings) > (XEN) Xen is relinquishing VGA console. > (XEN) *** Serial input -> DOM0 (type 'CTRL-a' three times to switch input= to Xen) > (XEN) Freed 188kB init memory. > mapping kernel into physical memory > Xen: setup ISA identity maps > about to get started... > (XEN) mm.c:907:d0 Error getting mfn 3809c (pfn b602c) from L1 entry 00000= 0003809c023 for l1e_owner=3D0, pg_owner=3D0 > (XEN) mm.c:907:d0 Error getting mfn 3809d (pfn b602d) from L1 entry 00000= 0003809d023 for l1e_owner=3D0, pg_owner=3D0 > (XEN) mm.c:907:d0 Error getting mfn 3809e (pfn b602e) from L1 entry 00000= 0003809e023 for l1e_owner=3D0, pg_owner=3D0 > (XEN) mm.c:907:d0 Error getting mfn 3809f (pfn b602f) from L1 entry 00000= 0003809f023 for l1e_owner=3D0, pg_owner=3D0 > [ 0.000000] Reserving virtual address space above 0xf5800000 > [ 0.000000] Initializing cgroup subsys cpuset > [ 0.000000] Initializing cgroup subsys cpu > [ 0.000000] Linux version 3.0.4 (root@linux-krq0) (gcc version 4.4.3 (= GCC) ) #1 SMP Thu Sep 22 12:32:25 GMT 2011 > [ 0.000000] KERNEL supported cpus: > [ 0.000000] Intel GenuineIntel > [ 0.000000] AMD AuthenticAMD > [ 0.000000] NSC Geode by NSC > [ 0.000000] Cyrix CyrixInstead > [ 0.000000] Centaur CentaurHauls > [ 0.000000] Transmeta GenuineTMx86 > [ 0.000000] Transmeta TransmetaCPU > [ 0.000000] UMC UMC UMC UMC > [ 0.000000] xen_release_chunk: looking at area pfn affee-afff0: 2 page= s freed > [ 0.000000] xen_release_chunk: looking at area pfn b0000-e558e: 218510= pages freed > [ 0.000000] released 218512 pages of unused memory > [ 0.000000] 1-1 mapping on 9c->100 > [ 0.000000] 1-1 mapping on aff90->100000 > [ 0.000000] Set 327892 page(s) to 1-1 mapping. > [ 0.000000] BIOS-provided physical RAM map: > [ 0.000000] Xen: 0000000000000000 - 000000000009b000 (usable) > [ 0.000000] Xen: 000000000009b400 - 0000000000100000 (reserved) > [ 0.000000] Xen: 0000000000100000 - 00000000aff90000 (usable) > [ 0.000000] Xen: 00000000aff90000 - 00000000aff9e000 (ACPI data) > [ 0.000000] Xen: 00000000aff9e000 - 00000000affe0000 (ACPI NVS) > [ 0.000000] Xen: 00000000affe0000 - 00000000affee000 (reserved) > [ 0.000000] Xen: 00000000afff0000 - 00000000b0000000 (reserved) > [ 0.000000] Xen: 00000000fec00000 - 00000000fec01000 (reserved) > [ 0.000000] Xen: 00000000fee00000 - 00000000fef00000 (reserved) > [ 0.000000] Xen: 00000000fff00000 - 0000000100000000 (reserved) > [ 0.000000] Xen: 0000000100000000 - 0000000175590000 (usable) > [ 0.000000] NX (Execute Disable) protection: active > [ 0.000000] DMI present. > [ 0.000000] DMI: System manufacturer System Product Name/M2N68-AM Plus= , BIOS 1402 03/22/2010 > [ 0.000000] e820 update range: 0000000000000000 - 0000000000010000 (us= able) =3D=3D> (reserved) > [ 0.000000] e820 remove range: 00000000000a0000 - 0000000000100000 (us= able) > [ 0.000000] last_pfn =3D 0x175590 max_arch_pfn =3D 0x1000000 > [ 0.000000] found SMP MP-table at [c00ff780] ff780 > [ 0.000000] initial memory mapped : 0 - 033ff000 > [ 0.000000] Base memory trampoline at [c0097000] 97000 size 16384 > [ 0.000000] init_memory_mapping: 0000000000000000-000000002d3fe000 > [ 0.000000] 0000000000 - 002d3fe000 page 4k > [ 0.000000] kernel direct mapping tables up to 2d3fe000 @ 3292000-33ff= 000 > [ 0.000000] xen: setting RW the range 33e2000 - 33ff000 > [ 0.000000] RAMDISK: 01b38000 - 02449000 > [ 0.000000] ACPI: RSDP 000fb5d0 00014 (v00 ACPIAM) > [ 0.000000] ACPI: RSDT aff90000 00038 (v01 032210 RSDT1037 20100322 MS= FT 00000097) > [ 0.000000] ACPI: FACP aff90200 00084 (v02 032210 FACP1037 20100322 MS= FT 00000097) > [ 0.000000] ACPI: DSDT aff90460 07307 (v01 A1270 A1270000 00000000 IN= TL 20060113) > [ 0.000000] ACPI: FACS aff9e000 00040 > [ 0.000000] ACPI: APIC aff90390 00090 (v01 032210 APIC1037 20100322 MS= FT 00000097) > [ 0.000000] ACPI: MCFG aff90420 0003C (v01 032210 OEMMCFG 20100322 MS= FT 00000097) > [ 0.000000] ACPI: OEMB aff9e040 00071 (v01 032210 OEMB1037 20100322 MS= FT 00000097) > [ 0.000000] ACPI: HPET aff97770 00038 (v01 032210 OEMHPET0 20100322 MS= FT 00000097) > [ 0.000000] ACPI: Local APIC address 0xfee00000 > [ 0.000000] 5249MB HIGHMEM available. > [ 0.000000] 723MB LOWMEM available. > [ 0.000000] mapped low ram: 0 - 2d3fe000 > [ 0.000000] low ram: 0 - 2d3fe000 > [ 0.000000] Zone PFN ranges: > [ 0.000000] DMA 0x00000010 -> 0x00001000 > [ 0.000000] Normal 0x00001000 -> 0x0002d3fe > [ 0.000000] HighMem 0x0002d3fe -> 0x00175590 > [ 0.000000] Movable zone start PFN for each node > [ 0.000000] early_node_map[3] active PFN ranges > [ 0.000000] 0: 0x00000010 -> 0x0000009b > [ 0.000000] 0: 0x00000100 -> 0x000aff90 > [ 0.000000] 0: 0x00100000 -> 0x00175590 > [ 0.000000] On node 0 totalpages: 1201323 > [ 0.000000] free_area_init_node: node 0, pgdat c1733b40, node_mem_map = ea54d200 > [ 0.000000] DMA zone: 32 pages used for memmap > [ 0.000000] DMA zone: 0 pages reserved > [ 0.000000] DMA zone: 3947 pages, LIFO batch:0 > [ 0.000000] Normal zone: 1416 pages used for memmap > [ 0.000000] Normal zone: 179830 pages, LIFO batch:31 > [ 0.000000] HighMem zone: 10500 pages used for memmap > [ 0.000000] HighMem zone: 1005598 pages, LIFO batch:31 > [ 0.000000] Using APIC driver default > [ 0.000000] ACPI: PM-Timer IO Port: 0x508 > [ 0.000000] ACPI: Local APIC address 0xfee00000 > [ 0.000000] ACPI: LAPIC (acpi_id[0x01] lapic_id[0x00] enabled) > [ 0.000000] BIOS bug: APIC version is 0 for CPU 0/0x0, fixing up to 0x= 10 > [ 0.000000] ACPI: LAPIC (acpi_id[0x02] lapic_id[0x01] enabled) > [ 0.000000] ACPI: LAPIC (acpi_id[0x03] lapic_id[0x82] disabled) > [ 0.000000] ACPI: LAPIC (acpi_id[0x04] lapic_id[0x83] disabled) > [ 0.000000] ACPI: LAPIC (acpi_id[0x05] lapic_id[0x84] disabled) > [ 0.000000] ACPI: LAPIC (acpi_id[0x06] lapic_id[0x85] disabled) > [ 0.000000] ACPI: IOAPIC (id[0x02] address[0xfec00000] gsi_base[0]) > [ 0.000000] IOAPIC[0]: apic_id 2, version 255, address 0xfec00000, GSI= 0-255 > [ 0.000000] ACPI: INT_SRC_OVR (bus 0 bus_irq 0 global_irq 2 dfl dfl) > [ 0.000000] ACPI: INT_SRC_OVR (bus 0 bus_irq 9 global_irq 9 high level) > [ 0.000000] ACPI: INT_SRC_OVR (bus 0 bus_irq 14 global_irq 14 high edg= e) > [ 0.000000] ACPI: INT_SRC_OVR (bus 0 bus_irq 15 global_irq 15 high edg= e) > [ 0.000000] ACPI: IRQ0 used by override. > [ 0.000000] ACPI: IRQ2 used by override. > [ 0.000000] ACPI: IRQ9 used by override. > [ 0.000000] ACPI: IRQ14 used by override. > [ 0.000000] ACPI: IRQ15 used by override. > [ 0.000000] Using ACPI (MADT) for SMP configuration information > [ 0.000000] ACPI: HPET id: 0x10de8201 base: 0xfed00000 > [ 0.000000] SMP: Allowing 6 CPUs, 4 hotplug CPUs > [ 0.000000] nr_irqs_gsi: 272 > [ 0.000000] PM: Registered nosave memory: 000000000009b000 - 000000000= 009c000 > [ 0.000000] PM: Registered nosave memory: 000000000009c000 - 000000000= 0100000 > [ 0.000000] Allocating PCI resources starting at b0000000 (gap: b00000= 00:4ec00000) > [ 0.000000] Booting paravirtualized kernel on Xen > [ 0.000000] Xen version: 4.1.1 (preserve-AD) > [ 0.000000] setup_percpu: NR_CPUS:8 nr_cpumask_bits:8 nr_cpu_ids:6 nr_= node_ids:1 > [ 0.000000] PERCPU: Embedded 12 pages/cpu @ea4f3000 s28352 r0 d20800 u= 49152 > [ 0.000000] pcpu-alloc: s28352 r0 d20800 u49152 alloc=3D12*4096 > [ 0.000000] pcpu-alloc: [0] 0 [0] 1 [0] 2 [0] 3 [0] 4 [0] 5=20 > [ 0.000000] Built 1 zonelists in Zone order, mobility grouping on. To= tal pages: 1189375 > [ 0.000000] Kernel command line: boot_media=3Dloop-disk boot_volume=3D= "/dev/sd?1" boot_volume_id=3D59e069103c926191 boot_mode=3Dsetup-automatic d= ebug loglevel=3D9 console=3Dhvc0 initcall_debug > [ 0.000000] PID hash table entries: 4096 (order: 2, 16384 bytes) > [ 0.000000] Dentry cache hash table entries: 131072 (order: 7, 524288 = bytes) > [ 0.000000] Inode-cache hash table entries: 65536 (order: 6, 262144 by= tes) > [ 0.000000] Initializing CPU#0 > [ 0.000000] allocated 24467456 bytes of page_cgroup > [ 0.000000] please try 'cgroup_disable=3Dmemory' option if you don't w= ant memory cgroups > [ 0.000000] Placing 64MB software IO TLB between e4cd9000 - e8cd9000 > [ 0.000000] software IO TLB at phys 0x24cd9000 - 0x28cd9000 > [ 0.000000] Initializing HighMem for node 0 (0002d3fe:00175590) > [ 0.000000] Memory: 2720416k/6116928k available (5077k kernel code, 16= 2252k reserved, 2334k data, 676k init, 2141768k highmem) > [ 0.000000] virtual kernel memory layout: > [ 0.000000] fixmap : 0xf5716000 - 0xf57ff000 ( 932 kB) > [ 0.000000] pkmap : 0xf5400000 - 0xf5600000 (2048 kB) > [ 0.000000] vmalloc : 0xedbfe000 - 0xf53fe000 ( 120 MB) > [ 0.000000] lowmem : 0xc0000000 - 0xed3fe000 ( 723 MB) > [ 0.000000] .init : 0xc173e000 - 0xc17e7000 ( 676 kB) > [ 0.000000] .data : 0xc14f5620 - 0xc173d180 (2334 kB) > [ 0.000000] .text : 0xc1000000 - 0xc14f5620 (5077 kB) > [ 0.000000] SLUB: Genslabs=3D15, HWalign=3D64, Order=3D0-3, MinObjects= =3D0, CPUs=3D6, Nodes=3D1 > [ 0.000000] Hierarchical RCU implementation. > [ 0.000000] RCU dyntick-idle grace-period acceleration is enabled. > [ 0.000000] NR_IRQS:2304 nr_irqs:1536 16 > [ 0.000000] CPU 0 irqstacks, hard=3De4818000 soft=3De481a000 > [ 0.000000] xen: sci override: global_irq=3D9 trigger=3D0 polarity=3D0 > [ 0.000000] xen: registering gsi 9 triggering 0 polarity 0 > [ 0.000000] xen: --> pirq=3D9 -> irq=3D9 (gsi=3D9) > [ 0.000000] xen: acpi sci 9 > [ 0.000000] xen: --> pirq=3D1 -> irq=3D1 (gsi=3D1) > [ 0.000000] xen: --> pirq=3D2 -> irq=3D2 (gsi=3D2) > [ 0.000000] xen: --> pirq=3D3 -> irq=3D3 (gsi=3D3) > [ 0.000000] xen: --> pirq=3D4 -> irq=3D4 (gsi=3D4) > [ 0.000000] xen: --> pirq=3D5 -> irq=3D5 (gsi=3D5) > [ 0.000000] xen: --> pirq=3D6 -> irq=3D6 (gsi=3D6) > [ 0.000000] xen: --> pirq=3D7 -> irq=3D7 (gsi=3D7) > [ 0.000000] xen: --> pirq=3D8 -> irq=3D8 (gsi=3D8) > [ 0.000000] xen_map_pirq_gsi: returning irq 9 for gsi 9 > [ 0.000000] xen: --> pirq=3D9 -> irq=3D9 (gsi=3D9) > [ 0.000000] xen: --> pirq=3D10 -> irq=3D10 (gsi=3D10) > [ 0.000000] xen: --> pirq=3D11 -> irq=3D11 (gsi=3D11) > [ 0.000000] xen: --> pirq=3D12 -> irq=3D12 (gsi=3D12) > [ 0.000000] xen: --> pirq=3D13 -> irq=3D13 (gsi=3D13) > [ 0.000000] xen: --> pirq=3D14 -> irq=3D14 (gsi=3D14) > [ 0.000000] xen: --> pirq=3D15 -> irq=3D15 (gsi=3D15) > [ 0.000000] Console: colour VGA+ 80x25 > [ 0.000000] console [hvc0] enabled > [ 0.000000] Xen: using vcpuop timer interface > [ 0.000000] installing Xen timer for CPU 0 > [ 0.000000] Detected 3013.750 MHz processor. > [ 0.004000] Calibrating delay loop (skipped), value calculated using t= imer frequency.. 6027.50 BogoMIPS (lpj=3D12055000) > [ 0.004000] pid_max: default: 32768 minimum: 301 > [ 0.004000] Mount-cache hash table entries: 512 > [ 0.004000] Initializing cgroup subsys cpuacct > [ 0.004000] Initializing cgroup subsys memory > [ 0.004000] Initializing cgroup subsys devices > [ 0.004000] Initializing cgroup subsys freezer > [ 0.004000] Initializing cgroup subsys net_cls > [ 0.004000] Initializing cgroup subsys blkio > [ 0.004000] CPU: Physical Processor ID: 0 > [ 0.004000] CPU: Processor Core ID: 0 > [ 0.004000] ACPI: Core revision 20110413 > [ 0.012000] ftrace: allocating 21320 entries in 42 pages > [ 0.016106] cpu 0 spinlock event irq 273 > [ 0.016154] calling trace_init_flags_sys_exit+0x0/0x11 @ 1 > [ 0.016166] initcall trace_init_flags_sys_exit+0x0/0x11 returned 0 aft= er 0 usecs > [ 0.016180] calling trace_init_flags_sys_enter+0x0/0x11 @ 1 > [ 0.016192] initcall trace_init_flags_sys_enter+0x0/0x11 returned 0 af= ter 0 usecs > [ 0.016206] calling init_hw_perf_events+0x0/0xef8 @ 1 > [ 0.016215] Performance Events: (XEN) traps.c:2388:d0 Domain attempted= WRMSR c0010004 from 0x00009b27f69722da to 0x000000000000abcd. > Broken PMU hardware detected, using software events only. > [ 0.016245] initcall init_hw_perf_events+0x0/0xef8 returned 0 after 0 = usecs > [ 0.016258] calling migration_init+0x0/0x5b @ 1 > [ 0.016271] initcall migration_init+0x0/0x5b returned 0 after 0 usecs > [ 0.016283] calling spawn_ksoftirqd+0x0/0x45 @ 1 > [ 0.016320] initcall spawn_ksoftirqd+0x0/0x45 returned 0 after 0 usecs > [ 0.016333] calling init_workqueues+0x0/0x287 @ 1 > [ 0.016409] initcall init_workqueues+0x0/0x287 returned 0 after 0 usecs > [ 0.016422] calling cpu_stop_init+0x0/0x83 @ 1 > [ 0.016459] initcall cpu_stop_init+0x0/0x83 returned 0 after 0 usecs > [ 0.016472] calling rcu_scheduler_really_started+0x0/0x11 @ 1 > [ 0.016485] initcall rcu_scheduler_really_started+0x0/0x11 returned 0 = after 0 usecs > [ 0.016499] calling relay_init+0x0/0x11 @ 1 > [ 0.016509] initcall relay_init+0x0/0x11 returned 0 after 0 usecs > [ 0.016521] calling tracer_alloc_buffers+0x0/0x18b @ 1 > [ 0.016581] initcall tracer_alloc_buffers+0x0/0x18b returned 0 after 0= usecs > [ 0.016595] calling init_trace_printk+0x0/0xf @ 1 > [ 0.016606] initcall init_trace_printk+0x0/0xf returned 0 after 0 usecs > [ 0.016686] CPU 1 irqstacks, hard=3De48b0000 soft=3De48b2000 > [ 0.016698] installing Xen timer for CPU 1 > [ 0.016715] cpu 1 spinlock event irq 279 > [ 0.004000] Initializing CPU#1 > [ 0.016859] Brought up 2 CPUs > [ 0.016949] devtmpfs: initialized > [ 0.016949] calling init_mmap_min_addr+0x0/0x11 @ 1 > [ 0.016949] initcall init_mmap_min_addr+0x0/0x11 returned 0 after 0 us= ecs > [ 0.016949] calling init_cpufreq_transition_notifier_list+0x0/0x18 @ 1 > [ 0.016949] initcall init_cpufreq_transition_notifier_list+0x0/0x18 re= turned 0 after 0 usecs > [ 0.016949] calling net_ns_init+0x0/0xed @ 1 > [ 0.016949] initcall net_ns_init+0x0/0xed returned 0 after 0 usecs > [ 0.016949] calling e820_mark_nvs_memory+0x0/0x33 @ 1 > [ 0.016949] PM: Registering ACPI NVS region at aff9e000 (270336 bytes) > [ 0.016949] initcall e820_mark_nvs_memory+0x0/0x33 returned 0 after 0 = usecs > [ 0.016949] calling cpufreq_tsc+0x0/0x26 @ 1 > [ 0.016949] initcall cpufreq_tsc+0x0/0x26 returned 0 after 0 usecs > [ 0.016949] calling pci_reboot_init+0x0/0x11 @ 1 > [ 0.016949] initcall pci_reboot_init+0x0/0x11 returned 0 after 0 usecs > [ 0.016949] calling reboot_init+0x0/0x11 @ 1 > [ 0.016949] initcall reboot_init+0x0/0x11 returned 0 after 0 usecs > [ 0.016949] calling init_lapic_sysfs+0x0/0x1b @ 1 > [ 0.016949] initcall init_lapic_sysfs+0x0/0x1b returned 0 after 0 usecs > [ 0.016949] calling init_smp_flush+0x0/0x2c @ 1 > [ 0.016949] initcall init_smp_flush+0x0/0x2c returned 0 after 0 usecs > [ 0.016949] calling alloc_frozen_cpus+0x0/0x10 @ 1 > [ 0.016949] initcall alloc_frozen_cpus+0x0/0x10 returned 0 after 0 use= cs > [ 0.016949] calling sysctl_init+0x0/0x29 @ 1 > [ 0.016949] initcall sysctl_init+0x0/0x29 returned 0 after 0 usecs > [ 0.016949] calling ksysfs_init+0x0/0x74 @ 1 > [ 0.016949] initcall ksysfs_init+0x0/0x74 returned 0 after 0 usecs > [ 0.016949] calling init_jiffies_clocksource+0x0/0xf @ 1 > [ 0.016949] initcall init_jiffies_clocksource+0x0/0xf returned 0 after= 0 usecs > [ 0.016949] calling pm_init+0x0/0x61 @ 1 > [ 0.016949] initcall pm_init+0x0/0x61 returned 0 after 0 usecs > [ 0.016949] calling pm_disk_init+0x0/0x14 @ 1 > [ 0.016949] initcall pm_disk_init+0x0/0x14 returned 0 after 0 usecs > [ 0.016949] calling swsusp_header_init+0x0/0x30 @ 1 > [ 0.016949] initcall swsusp_header_init+0x0/0x30 returned 0 after 0 us= ecs > [ 0.016949] calling init_ftrace_syscalls+0x0/0x6f @ 1 > [ 0.017052] initcall init_ftrace_syscalls+0x0/0x6f returned 0 after 0 = usecs > [ 0.017064] calling init_zero_pfn+0x0/0x14 @ 1 > [ 0.017075] initcall init_zero_pfn+0x0/0x14 returned 0 after 0 usecs > [ 0.017087] calling fsnotify_init+0x0/0x24 @ 1 > [ 0.017098] initcall fsnotify_init+0x0/0x24 returned 0 after 0 usecs > [ 0.017110] calling filelock_init+0x0/0x2f @ 1 > [ 0.017123] initcall filelock_init+0x0/0x2f returned 0 after 0 usecs > [ 0.017135] calling init_script_binfmt+0x0/0x11 @ 1 > [ 0.017145] initcall init_script_binfmt+0x0/0x11 returned 0 after 0 us= ecs > [ 0.017157] calling init_elf_binfmt+0x0/0x11 @ 1 > [ 0.017167] initcall init_elf_binfmt+0x0/0x11 returned 0 after 0 usecs > [ 0.017179] calling debugfs_init+0x0/0x4a @ 1 > [ 0.017192] initcall debugfs_init+0x0/0x4a returned 0 after 0 usecs > [ 0.017204] calling securityfs_init+0x0/0x41 @ 1 > [ 0.017216] initcall securityfs_init+0x0/0x41 returned 0 after 0 usecs > [ 0.017228] calling random32_init+0x0/0xa8 @ 1 > [ 0.017239] initcall random32_init+0x0/0xa8 returned 0 after 0 usecs > [ 0.017251] calling sfi_sysfs_init+0x0/0xbe @ 1 > [ 0.017261] initcall sfi_sysfs_init+0x0/0xbe returned 0 after 0 usecs > [ 0.017275] calling virtio_init+0x0/0x30 @ 1 > [ 0.017290] initcall virtio_init+0x0/0x30 returned 0 after 0 usecs > [ 0.017302] calling __gnttab_init+0x0/0x21 @ 1 > [ 0.017326] Grant table initialized > [ 0.017335] initcall __gnttab_init+0x0/0x21 returned 0 after 0 usecs > [ 0.017347] calling regulator_init+0x0/0x5e @ 1 > [ 0.017397] print_constraints: dummy:=20 > [ 0.017411] initcall regulator_init+0x0/0x5e returned 0 after 0 usecs > [ 0.017425] calling early_resume_init+0x0/0x1b0 @ 1 > [ 0.017475] Time: 14:34:24 Date: 09/23/11 > [ 0.017484] initcall early_resume_init+0x0/0x1b0 returned 0 after 0 us= ecs > [ 0.017496] calling cpufreq_core_init+0x0/0x84 @ 1 > [ 0.017508] initcall cpufreq_core_init+0x0/0x84 returned 0 after 0 use= cs > [ 0.017520] calling cpuidle_init+0x0/0x32 @ 1 > [ 0.017533] initcall cpuidle_init+0x0/0x32 returned 0 after 0 usecs > [ 0.017545] calling sock_init+0x0/0x78 @ 1 > [ 0.017576] initcall sock_init+0x0/0x78 returned 0 after 0 usecs > [ 0.017588] calling net_inuse_init+0x0/0x24 @ 1 > [ 0.017600] initcall net_inuse_init+0x0/0x24 returned 0 after 0 usecs > [ 0.017612] calling netpoll_init+0x0/0x2f @ 1 > [ 0.017622] initcall netpoll_init+0x0/0x2f returned 0 after 0 usecs > [ 0.017634] calling netlink_proto_init+0x0/0x17b @ 1 > [ 0.017647] NET: Registered protocol family 16 > [ 0.017664] initcall netlink_proto_init+0x0/0x17b returned 0 after 0 u= secs > [ 0.017676] calling bdi_class_init+0x0/0x40 @ 1 > [ 0.017691] initcall bdi_class_init+0x0/0x40 returned 0 after 0 usecs > [ 0.017703] calling kobject_uevent_init+0x0/0x1e @ 1 > [ 0.017715] initcall kobject_uevent_init+0x0/0x1e returned 0 after 0 u= secs > [ 0.017726] calling gpiolib_sysfs_init+0x0/0x66 @ 1 > [ 0.017744] initcall gpiolib_sysfs_init+0x0/0x66 returned 0 after 0 us= ecs > [ 0.017755] calling pcibus_class_init+0x0/0x14 @ 1 > [ 0.017769] initcall pcibus_class_init+0x0/0x14 returned 0 after 0 use= cs > [ 0.017781] calling pci_driver_init+0x0/0xf @ 1 > [ 0.017797] initcall pci_driver_init+0x0/0xf returned 0 after 0 usecs > [ 0.017809] calling backlight_class_init+0x0/0x53 @ 1 > [ 0.017824] initcall backlight_class_init+0x0/0x53 returned 0 after 0 = usecs > [ 0.017837] calling video_output_class_init+0x0/0x14 @ 1 > [ 0.017850] initcall video_output_class_init+0x0/0x14 returned 0 after= 0 usecs > [ 0.017864] calling xenbus_init+0x0/0x250 @ 1 > [ 0.017917] initcall xenbus_init+0x0/0x250 returned 0 after 0 usecs > [ 0.017917] calling tty_class_init+0x0/0x2f @ 1 > [ 0.017917] initcall tty_class_init+0x0/0x2f returned 0 after 0 usecs > [ 0.017917] calling vtconsole_class_init+0x0/0xc2 @ 1 > [ 0.017917] initcall vtconsole_class_init+0x0/0xc2 returned 0 after 0 = usecs > [ 0.017917] calling wakeup_sources_debugfs_init+0x0/0x2f @ 1 > [ 0.017917] initcall wakeup_sources_debugfs_init+0x0/0x2f returned 0 a= fter 0 usecs > [ 0.017917] calling i2c_init+0x0/0x57 @ 1 > [ 0.017917] initcall i2c_init+0x0/0x57 returned 0 after 0 usecs > [ 0.017917] calling eisa_init+0x0/0x29 @ 1 > [ 0.017917] EISA bus registered > [ 0.017917] initcall eisa_init+0x0/0x29 returned 0 after 0 usecs > [ 0.017917] calling amd_postcore_init+0x0/0x139 @ 1 > [ 0.017917] node 0 link 0: io port [5000, ffffff] > [ 0.017917] TOM: 00000000c0000000 aka 3072M > [ 0.017917] Fam 10h mmconf [e0000000, efffffff] > [ 0.017917] node 0 link 0: mmio [e0000000, efffffff] =3D=3D> none > [ 0.017917] node 0 link 0: mmio [a0000, bffff] > [ 0.017917] node 0 link 0: mmio [c0000000, fe0bffff] =3D=3D> [c0000000= , dfffffff] and [f0000000, fe0bffff] > [ 0.017917] TOM2: 0000000140000000 aka 5120M > [ 0.017917] bus: [00, 07] on node 0 link 0 > [ 0.017917] bus: 00 index 0 [io 0x0000-0xffff] > [ 0.017917] bus: 00 index 1 [mem 0x000a0000-0x000bffff] > [ 0.017917] bus: 00 index 2 [mem 0xc0000000-0xdfffffff] > [ 0.017917] bus: 00 index 3 [mem 0xf0000000-0xffffffff] > [ 0.017917] bus: 00 index 4 [mem 0x140000000-0xfcffffffff] > [ 0.017917] Extended Config Space enabled on 1 nodes > [ 0.017917] initcall amd_postcore_init+0x0/0x139 returned 0 after 0 us= ecs > [ 0.017917] calling arch_kdebugfs_init+0x0/0x1e @ 1 > [ 0.017917] initcall arch_kdebugfs_init+0x0/0x1e returned 0 after 0 us= ecs > [ 0.017917] calling init_pit_clocksource+0x0/0x36 @ 1 > [ 0.017917] initcall init_pit_clocksource+0x0/0x36 returned 0 after 0 = usecs > [ 0.017917] calling configure_trampolines+0x0/0x1f @ 1 > [ 0.017917] initcall configure_trampolines+0x0/0x1f returned 0 after 0= usecs > [ 0.017917] calling mtrr_if_init+0x0/0x56 @ 1 > [ 0.017917] initcall mtrr_if_init+0x0/0x56 returned -19 after 0 usecs > [ 0.017917] calling ffh_cstate_init+0x0/0x27 @ 1 > [ 0.017917] initcall ffh_cstate_init+0x0/0x27 returned -1 after 0 usecs > [ 0.017917] initcall ffh_cstate_init+0x0/0x27 returned with error code= -1=20 > [ 0.017917] calling kdump_buf_page_init+0x0/0x41 @ 1 > [ 0.017917] initcall kdump_buf_page_init+0x0/0x41 returned 0 after 0 u= secs > [ 0.017917] calling acpi_pci_init+0x0/0x5b @ 1 > [ 0.017917] ACPI: bus type pci registered > [ 0.017917] initcall acpi_pci_init+0x0/0x5b returned 0 after 0 usecs > [ 0.017917] calling dma_bus_init+0x0/0x32 @ 1 > [ 0.017917] initcall dma_bus_init+0x0/0x32 returned 0 after 0 usecs > [ 0.017917] calling dma_channel_table_init+0x0/0xe8 @ 1 > [ 0.017917] initcall dma_channel_table_init+0x0/0xe8 returned 0 after = 0 usecs > [ 0.017917] calling setup_vcpu_hotplug_event+0x0/0x1f @ 1 > [ 0.017917] initcall setup_vcpu_hotplug_event+0x0/0x1f returned 0 afte= r 0 usecs > [ 0.017917] calling register_xen_pci_notifier+0x0/0x2c @ 1 > [ 0.017917] initcall register_xen_pci_notifier+0x0/0x2c returned 0 aft= er 0 usecs > [ 0.017917] calling dmi_id_init+0x0/0x2ad @ 1 > [ 0.017917] initcall dmi_id_init+0x0/0x2ad returned 0 after 0 usecs > [ 0.017917] calling pci_arch_init+0x0/0x65 @ 1 > [ 0.017917] PCI: MMCONFIG for domain 0000 [bus 00-ff] at [mem 0xe00000= 00-0xefffffff] (base 0xe0000000) > [ 0.017917] PCI: not using MMCONFIG > [ 0.020114] PCI : PCI BIOS aera is rw and x. Use pci=3Dnobios if you w= ant it NX. > [ 0.020267] PCI: PCI BIOS revision 3.00 entry at 0xf0031, last bus=3D4 > [ 0.020278] PCI: Using configuration type 1 for base access > [ 0.020287] PCI: Using configuration type 1 for extended access > [ 0.020307] initcall pci_arch_init+0x0/0x65 returned 0 after 3906 usecs > [ 0.020318] calling topology_init+0x0/0x36 @ 1 > [ 0.020337] initcall topology_init+0x0/0x36 returned 0 after 0 usecs > [ 0.020349] calling mtrr_init_finialize+0x0/0x30 @ 1 > [ 0.020360] initcall mtrr_init_finialize+0x0/0x30 returned 0 after 0 u= secs > [ 0.020372] calling mca_init+0x0/0x2e4 @ 1 > [ 0.020386] initcall mca_init+0x0/0x2e4 returned -19 after 0 usecs > [ 0.020398] calling param_sysfs_init+0x0/0x166 @ 1 > [ 0.020933] initcall param_sysfs_init+0x0/0x166 returned 0 after 0 use= cs > [ 0.020945] calling pm_sysrq_init+0x0/0x20 @ 1 > [ 0.020956] initcall pm_sysrq_init+0x0/0x20 returned 0 after 0 usecs > [ 0.020968] calling default_bdi_init+0x0/0xac @ 1 > [ 0.020997] initcall default_bdi_init+0x0/0xac returned 0 after 0 usecs > [ 0.020997] calling init_bio+0x0/0x100 @ 1 > [ 0.020997] bio: create slab <bio-0> at 0 > [ 0.020997] initcall init_bio+0x0/0x100 returned 0 after 0 usecs > [ 0.020997] calling fsnotify_notification_init+0x0/0x9c @ 1 > [ 0.020997] initcall fsnotify_notification_init+0x0/0x9c returned 0 af= ter 0 usecs > [ 0.020997] calling cryptomgr_init+0x0/0xf @ 1 > [ 0.020997] initcall cryptomgr_init+0x0/0xf returned 0 after 0 usecs > [ 0.020997] calling blk_settings_init+0x0/0x21 @ 1 > [ 0.020997] initcall blk_settings_init+0x0/0x21 returned 0 after 0 use= cs > [ 0.020997] calling blk_ioc_init+0x0/0x2f @ 1 > [ 0.020997] initcall blk_ioc_init+0x0/0x2f returned 0 after 0 usecs > [ 0.020997] calling blk_softirq_init+0x0/0x54 @ 1 > [ 0.020997] initcall blk_softirq_init+0x0/0x54 returned 0 after 0 usecs > [ 0.020997] calling blk_iopoll_setup+0x0/0x54 @ 1 > [ 0.020997] initcall blk_iopoll_setup+0x0/0x54 returned 0 after 0 usecs > [ 0.020997] calling genhd_device_init+0x0/0x61 @ 1 > [ 0.020997] initcall genhd_device_init+0x0/0x61 returned 0 after 0 use= cs > [ 0.020997] calling blk_dev_integrity_init+0x0/0x2f @ 1 > [ 0.020997] initcall blk_dev_integrity_init+0x0/0x2f returned 0 after = 0 usecs > [ 0.020997] calling gpiolib_debugfs_init+0x0/0x2a @ 1 > [ 0.020997] initcall gpiolib_debugfs_init+0x0/0x2a returned 0 after 0 = usecs > [ 0.020997] calling stmpe_gpio_init+0x0/0xf @ 1 > [ 0.020997] initcall stmpe_gpio_init+0x0/0xf returned 0 after 0 usecs > [ 0.020997] calling tc3589x_gpio_init+0x0/0xf @ 1 > [ 0.020997] initcall tc3589x_gpio_init+0x0/0xf returned 0 after 0 usecs > [ 0.020997] calling sx150x_init+0x0/0x11 @ 1 > [ 0.020997] initcall sx150x_init+0x0/0x11 returned 0 after 0 usecs > [ 0.020997] calling pci_slot_init+0x0/0x50 @ 1 > [ 0.020997] initcall pci_slot_init+0x0/0x50 returned 0 after 0 usecs > [ 0.020997] calling acpi_init+0x0/0x272 @ 1 > [ 0.024240] ACPI: EC: Look up EC in DSDT > [ 0.028023] ACPI: Executed 1 blocks of module-level executable AML code > [ 0.032001] ACPI: Interpreter enabled > [ 0.032001] ACPI: (supports S0 S1 S3 S4 S5) > [ 0.032001] ACPI: Using IOAPIC for interrupt routing > [ 0.032027] PCI: MMCONFIG for domain 0000 [bus 00-ff] at [mem 0xe00000= 00-0xefffffff] (base 0xe0000000) > [ 0.033838] PCI: MMCONFIG at [mem 0xe0000000-0xefffffff] reserved in A= CPI motherboard resources > [ 0.033853] PCI: Using MMCONFIG for extended config space > [ 0.041215] initcall acpi_init+0x0/0x272 returned 0 after 19532 usecs > [ 0.041229] calling dock_init+0x0/0xb3 @ 1 > [ 0.041447] ACPI: No dock devices found. > [ 0.041456] initcall dock_init+0x0/0xb3 returned 0 after 0 usecs > [ 0.041468] calling acpi_pci_root_init+0x0/0x2f @ 1 > [ 0.041477] HEST: Table not found. > [ 0.041486] PCI: Using host bridge windows from ACPI; if necessary, us= e "pci=3Dnocrs" and report a bug > [ 0.041732] ACPI: PCI Root Bridge [PCI0] (domain 0000 [bus 00-ff]) > [ 0.041944] pci_root PNP0A03:00: host bridge window [io 0x0000-0x0cf7] > [ 0.041957] pci_root PNP0A03:00: host bridge window [io 0x0d00-0xffff] > [ 0.041968] pci_root PNP0A03:00: host bridge window [mem 0x000a0000-0x= 000bffff] > [ 0.041982] pci_root PNP0A03:00: host bridge window [mem 0x000d0000-0x= 000dffff] > [ 0.041995] pci_root PNP0A03:00: host bridge window [mem 0xb0000000-0x= dfffffff] > [ 0.042007] pci_root PNP0A03:00: host bridge window [mem 0xf0000000-0x= fed44fff] > [ 0.042049] pci 0000:00:00.0: [10de:03e2] type 0 class 0x000500 > [ 0.042276] pci 0000:00:01.0: [10de:03e1] type 0 class 0x000601 > [ 0.042300] pci 0000:00:01.0: reg 10: [io 0x0900-0x09ff] > [ 0.042383] pci 0000:00:01.1: [10de:03eb] type 0 class 0x000c05 > [ 0.042414] pci 0000:00:01.1: reg 10: [io 0x0e00-0x0e3f] > [ 0.042458] pci 0000:00:01.1: reg 20: [io 0x0600-0x063f] > [ 0.042477] pci 0000:00:01.1: reg 24: [io 0x0700-0x073f] > [ 0.042521] pci 0000:00:01.1: PME# supported from D3hot D3cold > [ 0.042538] pci 0000:00:01.1: PME# disabled > [ 0.042560] pci 0000:00:01.2: [10de:03f5] type 0 class 0x000500 > [ 0.042662] pci 0000:00:02.0: [10de:03f1] type 0 class 0x000c03 > [ 0.042691] pci 0000:00:02.0: reg 10: [mem 0xdfffb000-0xdfffbfff] > [ 0.042773] pci 0000:00:02.0: supports D1 D2 > [ 0.042783] pci 0000:00:02.0: PME# supported from D0 D1 D2 D3hot D3cold > [ 0.042797] pci 0000:00:02.0: PME# disabled > [ 0.042824] pci 0000:00:02.1: [10de:03f2] type 0 class 0x000c03 > [ 0.042856] pci 0000:00:02.1: reg 10: [mem 0xdfffac00-0xdfffacff] > [ 0.042946] pci 0000:00:02.1: supports D1 D2 > [ 0.042956] pci 0000:00:02.1: PME# supported from D0 D1 D2 D3hot D3cold > [ 0.042970] pci 0000:00:02.1: PME# disabled > [ 0.043010] pci 0000:00:04.0: [10de:03f3] type 1 class 0x000604 > [ 0.043107] pci 0000:00:05.0: [10de:03f0] type 0 class 0x000403 > [ 0.043140] pci 0000:00:05.0: reg 10: [mem 0xdfff4000-0xdfff7fff] > [ 0.043233] pci 0000:00:05.0: PME# supported from D3hot D3cold > [ 0.043247] pci 0000:00:05.0: PME# disabled > [ 0.043287] pci 0000:00:06.0: [10de:03ec] type 0 class 0x000101 > [ 0.043349] pci 0000:00:06.0: reg 20: [io 0xffa0-0xffaf] > [ 0.043417] pci 0000:00:07.0: [10de:03ef] type 0 class 0x000680 > [ 0.043449] pci 0000:00:07.0: reg 10: [mem 0xdfff9000-0xdfff9fff] > [ 0.043468] pci 0000:00:07.0: reg 14: [io 0xe480-0xe487] > [ 0.043546] pci 0000:00:07.0: supports D1 D2 > [ 0.043556] pci 0000:00:07.0: PME# supported from D0 D1 D2 D3hot D3cold > [ 0.043571] pci 0000:00:07.0: PME# disabled > [ 0.043604] pci 0000:00:08.0: [10de:03f6] type 0 class 0x000101 > [ 0.043635] pci 0000:00:08.0: reg 10: [io 0xe400-0xe407] > [ 0.043652] pci 0000:00:08.0: reg 14: [io 0xe080-0xe083] > [ 0.043670] pci 0000:00:08.0: reg 18: [io 0xe000-0xe007] > [ 0.043688] pci 0000:00:08.0: reg 1c: [io 0xdc00-0xdc03] > [ 0.043705] pci 0000:00:08.0: reg 20: [io 0xd880-0xd88f] > [ 0.043723] pci 0000:00:08.0: reg 24: [mem 0xdfff8000-0xdfff8fff] > [ 0.043796] pci 0000:00:08.1: [10de:03f6] type 0 class 0x000101 > [ 0.043828] pci 0000:00:08.1: reg 10: [io 0xd800-0xd807] > [ 0.043846] pci 0000:00:08.1: reg 14: [io 0xd480-0xd483] > [ 0.043863] pci 0000:00:08.1: reg 18: [io 0xd400-0xd407] > [ 0.043881] pci 0000:00:08.1: reg 1c: [io 0xd080-0xd083] > [ 0.043898] pci 0000:00:08.1: reg 20: [io 0xd000-0xd00f] > [ 0.043916] pci 0000:00:08.1: reg 24: [mem 0xdffef000-0xdffeffff] > [ 0.043998] pci 0000:00:09.0: [10de:03e8] type 1 class 0x000604 > [ 0.044034] pci 0000:00:09.0: PME# supported from D0 D1 D2 D3hot D3cold > [ 0.044048] pci 0000:00:09.0: PME# disabled > [ 0.044090] pci 0000:00:0b.0: [10de:03e9] type 1 class 0x000604 > [ 0.044169] pci 0000:00:0b.0: PME# supported from D0 D1 D2 D3hot D3cold > [ 0.044182] pci 0000:00:0b.0: PME# disabled > [ 0.044222] pci 0000:00:0c.0: [10de:03e9] type 1 class 0x000604 > [ 0.044300] pci 0000:00:0c.0: PME# supported from D0 D1 D2 D3hot D3cold > [ 0.044314] pci 0000:00:0c.0: PME# disabled > [ 0.044348] pci 0000:00:0d.0: [10de:03d6] type 0 class 0x000300 > [ 0.044376] pci 0000:00:0d.0: reg 10: [mem 0xde000000-0xdeffffff] > [ 0.044399] pci 0000:00:0d.0: reg 14: [mem 0xc0000000-0xcfffffff 64bit= pref] > [ 0.044424] pci 0000:00:0d.0: reg 1c: [mem 0xdd000000-0xddffffff 64bit] > [ 0.044450] pci 0000:00:0d.0: reg 30: [mem 0xdffc0000-0xdffdffff pref] > [ 0.044514] pci 0000:00:18.0: [1022:1200] type 0 class 0x000600 > [ 0.044582] pci 0000:00:18.1: [1022:1201] type 0 class 0x000600 > [ 0.044639] pci 0000:00:18.2: [1022:1202] type 0 class 0x000600 > [ 0.044697] pci 0000:00:18.3: [1022:1203] type 0 class 0x000600 > [ 0.044765] pci 0000:00:18.4: [1022:1204] type 0 class 0x000600 > [ 0.044917] pci 0000:00:04.0: PCI bridge to [bus 01-01] (subtractive d= ecode) > [ 0.044933] pci 0000:00:04.0: bridge window [io 0xf000-0x0000] (dis= abled) > [ 0.044948] pci 0000:00:04.0: bridge window [mem 0xfff00000-0x000fff= ff] (disabled) > [ 0.044964] pci 0000:00:04.0: bridge window [mem 0xfff00000-0x000fff= ff pref] (disabled) > [ 0.044977] pci 0000:00:04.0: bridge window [io 0x0000-0x0cf7] (sub= tractive decode) > [ 0.044991] pci 0000:00:04.0: bridge window [io 0x0d00-0xffff] (sub= tractive decode) > [ 0.045004] pci 0000:00:04.0: bridge window [mem 0x000a0000-0x000bff= ff] (subtractive decode) > [ 0.045019] pci 0000:00:04.0: bridge window [mem 0x000d0000-0x000dff= ff] (subtractive decode) > [ 0.045034] pci 0000:00:04.0: bridge window [mem 0xb0000000-0xdfffff= ff] (subtractive decode) > [ 0.045049] pci 0000:00:04.0: bridge window [mem 0xf0000000-0xfed44f= ff] (subtractive decode) > [ 0.045123] pci 0000:00:09.0: PCI bridge to [bus 02-02] > [ 0.045137] pci 0000:00:09.0: bridge window [io 0xf000-0x0000] (dis= abled) > [ 0.045153] pci 0000:00:09.0: bridge window [mem 0xfff00000-0x000fff= ff] (disabled) > [ 0.045170] pci 0000:00:09.0: bridge window [mem 0xfff00000-0x000fff= ff pref] (disabled) > [ 0.045242] pci 0000:00:0b.0: PCI bridge to [bus 03-03] > [ 0.045256] pci 0000:00:0b.0: bridge window [io 0xf000-0x0000] (dis= abled) > [ 0.045272] pci 0000:00:0b.0: bridge window [mem 0xfff00000-0x000fff= ff] (disabled) > [ 0.045289] pci 0000:00:0b.0: bridge window [mem 0xfff00000-0x000fff= ff pref] (disabled) > [ 0.045361] pci 0000:00:0c.0: PCI bridge to [bus 04-04] > [ 0.045375] pci 0000:00:0c.0: bridge window [io 0xf000-0x0000] (dis= abled) > [ 0.045391] pci 0000:00:0c.0: bridge window [mem 0xfff00000-0x000fff= ff] (disabled) > [ 0.045408] pci 0000:00:0c.0: bridge window [mem 0xfff00000-0x000fff= ff pref] (disabled) > [ 0.045440] pci_bus 0000:00: on NUMA node 0 > [ 0.045450] ACPI: PCI Interrupt Routing Table [\_SB_.PCI0._PRT] > [ 0.045579] ACPI: PCI Interrupt Routing Table [\_SB_.PCI0.P0P1._PRT] > [ 0.045639] ACPI: PCI Interrupt Routing Table [\_SB_.PCI0.BR10._PRT] > [ 0.045681] ACPI: PCI Interrupt Routing Table [\_SB_.PCI0.BR11._PRT] > [ 0.045725] ACPI: PCI Interrupt Routing Table [\_SB_.PCI0.BR12._PRT] > [ 0.045888] pci0000:00: Requesting ACPI _OSC control (0x1d) > [ 0.046096] pci0000:00: ACPI _OSC request failed (AE_SUPPORT), return= ed control mask: 0x0c > [ 0.046110] ACPI _OSC control for PCIe not granted, disabling ASPM > [ 0.052327] initcall acpi_pci_root_init+0x0/0x2f returned 0 after 1171= 9 usecs > [ 0.052342] calling acpi_pci_link_init+0x0/0x3f @ 1 > [ 0.052451] ACPI: PCI Interrupt Link [LNKA] (IRQs 16 17 18 19) *0, dis= abled. > [ 0.052590] ACPI: PCI Interrupt Link [LNKB] (IRQs 16 17 18 19) *0, dis= abled. > [ 0.052726] ACPI: PCI Interrupt Link [LNKC] (IRQs 16 17 18 19) *0, dis= abled. > [ 0.052862] ACPI: PCI Interrupt Link [LNKD] (IRQs 16 17 18 19) *0, dis= abled. > [ 0.052998] ACPI: PCI Interrupt Link [LNEA] (IRQs 16 17 18 19) *0, dis= abled. > [ 0.053134] ACPI: PCI Interrupt Link [LNEB] (IRQs 16 17 18 19) *0, dis= abled. > [ 0.053269] ACPI: PCI Interrupt Link [LNEC] (IRQs 16 17 18 19) *0, dis= abled. > [ 0.053406] ACPI: PCI Interrupt Link [LNED] (IRQs 16 17 18 19) *0, dis= abled. > [ 0.053545] ACPI: PCI Interrupt Link [LUB0] (IRQs 20 21 22 23) *5 > [ 0.053681] ACPI: PCI Interrupt Link [LUB2] (IRQs 20 21 22 23) *11 > [ 0.053817] ACPI: PCI Interrupt Link [LMAC] (IRQs 20 21 22 23) *5 > [ 0.053955] ACPI: PCI Interrupt Link [LAZA] (IRQs 20 21 22 23) *10 > [ 0.054092] ACPI: PCI Interrupt Link [LMC9] (IRQs 20 21 22 23) *11 > [ 0.054229] ACPI: PCI Interrupt Link [LSMB] (IRQs 20 21 22 23) *10 > [ 0.054363] ACPI: PCI Interrupt Link [LPMU] (IRQs 20 21 22 23) *0, dis= abled. > [ 0.054503] ACPI: PCI Interrupt Link [LSA0] (IRQs 20 21 22 23) *11 > [ 0.054639] ACPI: PCI Interrupt Link [LSA1] (IRQs 20 21 22 23) *11 > [ 0.054786] ACPI: PCI Interrupt Link [LATA] (IRQs 20 21 22 23) *0, dis= abled. > [ 0.054842] initcall acpi_pci_link_init+0x0/0x3f returned 0 after 0 us= ecs > [ 0.054854] calling pnp_init+0x0/0xf @ 1 > [ 0.054870] initcall pnp_init+0x0/0xf returned 0 after 0 usecs > [ 0.054883] calling xen_setup_shutdown_event+0x0/0x30 @ 1 > [ 0.054894] initcall xen_setup_shutdown_event+0x0/0x30 returned 0 afte= r 0 usecs > [ 0.054908] calling balloon_init+0x0/0x16b @ 1 > [ 0.054917] xen/balloon: Initialising balloon driver. > [ 0.054927] last_pfn =3D 0x175590 max_arch_pfn =3D 0x1000000 > [ 0.060367] initcall balloon_init+0x0/0x16b returned 0 after 7812 usecs > [ 0.060389] calling xenbus_probe_backend_init+0x0/0x23 @ 1 > [ 0.060425] initcall xenbus_probe_backend_init+0x0/0x23 returned 0 aft= er 0 usecs > [ 0.060440] calling xenbus_probe_frontend_init+0x0/0x23 @ 1 > [ 0.060464] initcall xenbus_probe_frontend_init+0x0/0x23 returned 0 af= ter 0 usecs > [ 0.060478] calling balloon_init+0x0/0xe5 @ 1 > [ 0.060487] xen-balloon: Initialising balloon driver. > [ 0.060511] initcall balloon_init+0x0/0xe5 returned 0 after 0 usecs > [ 0.060524] calling pm8607_regulator_init+0x0/0xf @ 1 > [ 0.060544] initcall pm8607_regulator_init+0x0/0xf returned 0 after 0 = usecs > [ 0.060556] calling ab8500_regulator_init+0x0/0x2e @ 1 > [ 0.060572] initcall ab8500_regulator_init+0x0/0x2e returned 0 after 0= usecs > [ 0.060586] calling misc_init+0x0/0xad @ 1 > [ 0.060607] initcall misc_init+0x0/0xad returned 0 after 0 usecs > [ 0.060619] calling vga_arb_device_init+0x0/0xcc @ 1 > [ 0.060685] vgaarb: device added: PCI:0000:00:0d.0,decodes=3Dio+mem,ow= ns=3Dio+mem,locks=3Dnone > [ 0.060702] vgaarb: loaded > [ 0.060708] vgaarb: bridge control possible 0000:00:0d.0 > [ 0.060718] initcall vga_arb_device_init+0x0/0xcc returned 0 after 0 u= secs > [ 0.060731] calling cn_init+0x0/0x98 @ 1 > [ 0.060748] initcall cn_init+0x0/0x98 returned 0 after 0 usecs > [ 0.060760] calling pm860x_i2c_init+0x0/0x30 @ 1 > [ 0.060777] initcall pm860x_i2c_init+0x0/0x30 returned 0 after 0 usecs > [ 0.060789] calling stmpe_init+0x0/0x11 @ 1 > [ 0.060804] initcall stmpe_init+0x0/0x11 returned 0 after 0 usecs > [ 0.060816] calling tc3589x_init+0x0/0x11 @ 1 > [ 0.060831] initcall tc3589x_init+0x0/0x11 returned 0 after 0 usecs > [ 0.060842] calling wm831x_i2c_init+0x0/0x30 @ 1 > [ 0.060858] initcall wm831x_i2c_init+0x0/0x30 returned 0 after 0 usecs > [ 0.060870] calling wm8350_i2c_init+0x0/0x11 @ 1 > [ 0.060885] initcall wm8350_i2c_init+0x0/0x11 returned 0 after 0 usecs > [ 0.060896] calling da903x_init+0x0/0x11 @ 1 > [ 0.060911] initcall da903x_init+0x0/0x11 returned 0 after 0 usecs > [ 0.060923] calling max8925_i2c_init+0x0/0x30 @ 1 > [ 0.060938] initcall max8925_i2c_init+0x0/0x30 returned 0 after 0 usecs > [ 0.060950] calling max8998_i2c_init+0x0/0x11 @ 1 > [ 0.060965] initcall max8998_i2c_init+0x0/0x11 returned 0 after 0 usecs > [ 0.060977] calling ab3100_i2c_init+0x0/0x11 @ 1 > [ 0.060992] initcall ab3100_i2c_init+0x0/0x11 returned 0 after 0 usecs > [ 0.061004] calling ab3550_i2c_init+0x0/0x11 @ 1 > [ 0.061019] initcall ab3550_i2c_init+0x0/0x11 returned 0 after 0 usecs > [ 0.061031] calling ab8500_sysctrl_init+0x0/0xf @ 1 > [ 0.061047] initcall ab8500_sysctrl_init+0x0/0xf returned 0 after 0 us= ecs > [ 0.061058] calling ab8500_debug_init+0x0/0xf @ 1 > [ 0.061073] initcall ab8500_debug_init+0x0/0xf returned 0 after 0 usecs > [ 0.061085] calling tps6586x_init+0x0/0x11 @ 1 > [ 0.061103] initcall tps6586x_init+0x0/0x11 returned 0 after 0 usecs > [ 0.061115] calling init_scsi+0x0/0x90 @ 1 > [ 0.061198] SCSI subsystem initialized > [ 0.061207] initcall init_scsi+0x0/0x90 returned 0 after 0 usecs > [ 0.061219] calling ata_init+0x0/0x290 @ 1 > [ 0.061291] libata version 3.00 loaded. > [ 0.061291] initcall ata_init+0x0/0x290 returned 0 after 0 usecs > [ 0.061291] calling phy_init+0x0/0x2a @ 1 > [ 0.061291] initcall phy_init+0x0/0x2a returned 0 after 0 usecs > [ 0.061291] calling usb_init+0x0/0x142 @ 1 > [ 0.061291] usbcore: registered new interface driver usbfs > [ 0.061291] usbcore: registered new interface driver hub > [ 0.061291] usbcore: registered new device driver usb > [ 0.061291] initcall usb_init+0x0/0x142 returned 0 after 0 usecs > [ 0.061291] calling serio_init+0x0/0x2e @ 1 > [ 0.061291] initcall serio_init+0x0/0x2e returned 0 after 0 usecs > [ 0.061291] calling input_init+0x0/0xfd @ 1 > [ 0.061291] initcall input_init+0x0/0xfd returned 0 after 0 usecs > [ 0.061291] calling rtc_init+0x0/0x64 @ 1 > [ 0.061291] initcall rtc_init+0x0/0x64 returned 0 after 0 usecs > [ 0.061291] calling power_supply_class_init+0x0/0x39 @ 1 > [ 0.061291] initcall power_supply_class_init+0x0/0x39 returned 0 after= 0 usecs > [ 0.061291] calling hwmon_init+0x0/0xe3 @ 1 > [ 0.061291] initcall hwmon_init+0x0/0xe3 returned 0 after 0 usecs > [ 0.061291] calling md_init+0x0/0x152 @ 1 > [ 0.061291] initcall md_init+0x0/0x152 returned 0 after 0 usecs > [ 0.061291] calling leds_init+0x0/0x3d @ 1 > [ 0.061291] initcall leds_init+0x0/0x3d returned 0 after 0 usecs > [ 0.061291] calling pci_subsys_init+0x0/0x48 @ 1 > [ 0.061291] PCI: Using ACPI for IRQ routing > [ 0.061291] PCI: pci_cache_line_size set to 64 bytes > [ 0.061291] reserve RAM buffer: 000000000009b000 - 000000000009ffff=20 > [ 0.061291] reserve RAM buffer: 00000000aff90000 - 00000000afffffff=20 > [ 0.061291] reserve RAM buffer: 0000000175590000 - 0000000177ffffff=20 > [ 0.061291] initcall pci_subsys_init+0x0/0x48 returned 0 after 0 usecs > [ 0.061291] calling proto_init+0x0/0xf @ 1 > [ 0.061291] initcall proto_init+0x0/0xf returned 0 after 0 usecs > [ 0.061291] calling net_dev_init+0x0/0x161 @ 1 > [ 0.061291] initcall net_dev_init+0x0/0x161 returned 0 after 0 usecs > [ 0.061291] calling neigh_init+0x0/0x7c @ 1 > [ 0.061291] initcall neigh_init+0x0/0x7c returned 0 after 0 usecs > [ 0.061291] calling fib_rules_init+0x0/0xa4 @ 1 > [ 0.061291] initcall fib_rules_init+0x0/0xa4 returned 0 after 0 usecs > [ 0.061291] calling pktsched_init+0x0/0xe6 @ 1 > [ 0.061291] initcall pktsched_init+0x0/0xe6 returned 0 after 0 usecs > [ 0.061291] calling tc_filter_init+0x0/0x52 @ 1 > [ 0.061291] initcall tc_filter_init+0x0/0x52 returned 0 after 0 usecs > [ 0.061291] calling tc_action_init+0x0/0x52 @ 1 > [ 0.061291] initcall tc_action_init+0x0/0x52 returned 0 after 0 usecs > [ 0.061291] calling genl_init+0x0/0x76 @ 1 > [ 0.061291] initcall genl_init+0x0/0x76 returned 0 after 0 usecs > [ 0.061291] calling sysctl_init+0x0/0x3b @ 1 > [ 0.061291] initcall sysctl_init+0x0/0x3b returned 0 after 0 usecs > [ 0.061291] calling ab8500_gpadc_init+0x0/0xf @ 1 > [ 0.061291] initcall ab8500_gpadc_init+0x0/0xf returned 0 after 0 usecs > [ 0.061291] calling print_ICs+0x0/0x4ee @ 1 > [ 0.061291] initcall print_ICs+0x0/0x4ee returned 0 after 0 usecs > [ 0.061291] calling hpet_late_init+0x0/0xdc @ 1 > [ 0.061291] initcall hpet_late_init+0x0/0xdc returned -19 after 0 usecs > [ 0.061291] calling init_amd_nbs+0x0/0xba @ 1 > [ 0.061291] initcall init_amd_nbs+0x0/0xba returned 0 after 0 usecs > [ 0.061291] calling clocksource_done_booting+0x0/0x4f @ 1 > [ 0.061291] Switching to clocksource xen > [ 0.061291] initcall clocksource_done_booting+0x0/0x4f returned 0 afte= r 3 usecs > [ 0.061291] calling ftrace_init_debugfs+0x0/0x21b @ 1 > [ 0.061291] initcall ftrace_init_debugfs+0x0/0x21b returned 0 after 19= usecs > [ 0.061291] calling rb_init_debugfs+0x0/0x2f @ 1 > [ 0.061291] initcall rb_init_debugfs+0x0/0x2f returned 0 after 1 usecs > [ 0.061291] calling tracer_init_debugfs+0x0/0x367 @ 1 > [ 0.061291] initcall tracer_init_debugfs+0x0/0x367 returned 0 after 45= usecs > [ 0.061291] calling init_trace_printk_function_export+0x0/0x33 @ 1 > [ 0.061291] initcall init_trace_printk_function_export+0x0/0x33 return= ed 0 after 1 usecs > [ 0.061291] calling event_trace_init+0x0/0x2a8 @ 1 > [ 0.061508] Switched to NOHz mode on CPU #1 > [ 0.061652] Switched to NOHz mode on CPU #0 > [ 0.065001] initcall event_trace_init+0x0/0x2a8 returned 0 after 4686 = usecs > [ 0.065024] calling init_pipe_fs+0x0/0x3d @ 1 > [ 0.065051] initcall init_pipe_fs+0x0/0x3d returned 0 after 16 usecs > [ 0.065063] calling eventpoll_init+0x0/0xef @ 1 > [ 0.065084] initcall eventpoll_init+0x0/0xef returned 0 after 10 usecs > [ 0.065097] calling anon_inode_init+0x0/0x100 @ 1 > [ 0.065114] initcall anon_inode_init+0x0/0x100 returned 0 after 6 usecs > [ 0.065126] calling blk_scsi_ioctl_init+0x0/0x288 @ 1 > [ 0.065137] initcall blk_scsi_ioctl_init+0x0/0x288 returned 0 after 0 = usecs > [ 0.065149] calling acpi_event_init+0x0/0x79 @ 1 > [ 0.065172] initcall acpi_event_init+0x0/0x79 returned 0 after 11 usecs > [ 0.065184] calling pnp_system_init+0x0/0xf @ 1 > [ 0.065211] initcall pnp_system_init+0x0/0xf returned 0 after 16 usecs > [ 0.065224] calling pnpacpi_init+0x0/0x88 @ 1 > [ 0.065233] pnp: PnP ACPI init > [ 0.065254] ACPI: bus type pnp registered > [ 0.065407] pnp 00:00: [bus 00-ff] > [ 0.065417] pnp 00:00: [io 0x0cf8-0x0cff] > [ 0.065426] pnp 00:00: [io 0x0000-0x0cf7 window] > [ 0.065436] pnp 00:00: [io 0x0d00-0xffff window] > [ 0.065446] pnp 00:00: [mem 0x000a0000-0x000bffff window] > [ 0.065456] pnp 00:00: [mem 0x000d0000-0x000dffff window] > [ 0.065466] pnp 00:00: [mem 0xb0000000-0xdfffffff window] > [ 0.065476] pnp 00:00: [mem 0xf0000000-0xfed44fff window] > [ 0.065561] pnp 00:00: Plug and Play ACPI device, IDs PNP0a03 (active) > [ 0.065605] pnp 00:01: [dma 4] > [ 0.065614] pnp 00:01: [io 0x0000-0x000f] > [ 0.065622] pnp 00:01: [io 0x0081-0x0083] > [ 0.065630] pnp 00:01: [io 0x0087] > [ 0.065638] pnp 00:01: [io 0x0089-0x008b] > [ 0.065646] pnp 00:01: [io 0x008f] > [ 0.065654] pnp 00:01: [io 0x00c0-0x00df] > [ 0.065683] pnp 00:01: Plug and Play ACPI device, IDs PNP0200 (active) > [ 0.065708] pnp 00:02: [io 0x0070-0x0071] > [ 0.065718] xen: registering gsi 8 triggering 1 polarity 0 > [ 0.065729] xen_map_pirq_gsi: returning irq 8 for gsi 8 > [ 0.065738] xen: --> pirq=3D8 -> irq=3D8 (gsi=3D8) > [ 0.065760] pnp 00:02: [irq 8] > [ 0.065792] pnp 00:02: Plug and Play ACPI device, IDs PNP0b00 (active) > [ 0.065812] pnp 00:03: [io 0x0061] > [ 0.065839] pnp 00:03: Plug and Play ACPI device, IDs PNP0800 (active) > [ 0.065863] pnp 00:04: [io 0x00f0-0x00ff] > [ 0.065872] xen: registering gsi 13 triggering 1 polarity 0 > [ 0.065882] xen_map_pirq_gsi: returning irq 13 for gsi 13 > [ 0.065891] xen: --> pirq=3D13 -> irq=3D13 (gsi=3D13) > [ 0.065906] pnp 00:04: [irq 13] > [ 0.065935] pnp 00:04: Plug and Play ACPI device, IDs PNP0c04 (active) > [ 0.066902] pnp 00:05: [io 0x0378-0x037f] > [ 0.066911] xen: registering gsi 7 triggering 1 polarity 0 > [ 0.066921] xen_map_pirq_gsi: returning irq 7 for gsi 7 > [ 0.066930] xen: --> pirq=3D7 -> irq=3D7 (gsi=3D7) > [ 0.066945] pnp 00:05: [irq 7] > [ 0.066953] pnp 00:05: [dma 0 disabled] > [ 0.067207] pnp 00:05: Plug and Play ACPI device, IDs PNP0400 (active) > [ 0.067785] pnp 00:06: [mem 0x000d0000-0x000d3fff window] > [ 0.067796] pnp 00:06: [mem 0x000d4000-0x000d7fff window] > [ 0.067806] pnp 00:06: [mem 0x000de000-0x000dffff window] > [ 0.067816] pnp 00:06: [io 0x0010-0x001f] > [ 0.067825] pnp 00:06: [io 0x0022-0x003f] > [ 0.067833] pnp 00:06: [io 0x0044-0x004d] > [ 0.067841] pnp 00:06: [io 0x0050-0x005f] > [ 0.067849] pnp 00:06: [io 0x0062-0x0063] > [ 0.067857] pnp 00:06: [io 0x0065-0x006f] > [ 0.067865] pnp 00:06: [io 0x0072-0x007f] > [ 0.067873] pnp 00:06: [io 0x0080] > [ 0.067881] pnp 00:06: [io 0x0084-0x0086] > [ 0.067889] pnp 00:06: [io 0x0088] > [ 0.067897] pnp 00:06: [io 0x008c-0x008e] > [ 0.067905] pnp 00:06: [io 0x0090-0x009f] > [ 0.067914] pnp 00:06: [io 0x00a2-0x00bf] > [ 0.067922] pnp 00:06: [io 0x00e0-0x00ef] > [ 0.067930] pnp 00:06: [io 0x04d0-0x04d1] > [ 0.067938] pnp 00:06: [io 0x0800-0x080f] > [ 0.067946] pnp 00:06: [io 0x0500-0x057f] > [ 0.067954] pnp 00:06: [io 0x0580-0x05ff] > [ 0.067962] pnp 00:06: [io 0x0800-0x087f] > [ 0.067970] pnp 00:06: [io 0x0880-0x08ff] > [ 0.067978] pnp 00:06: [io 0x0d00-0x0d7f] > [ 0.067987] pnp 00:06: [io 0x0d80-0x0dff] > [ 0.067995] pnp 00:06: [io 0x0900-0x097f] > [ 0.068003] pnp 00:06: [io 0x0980-0x09ff] > [ 0.068011] pnp 00:06: [io 0x1100-0x117f] > [ 0.068019] pnp 00:06: [io 0x1180-0x11ff] > [ 0.068028] pnp 00:06: [mem 0xfec80000-0x1fd93ffff] > [ 0.068038] pnp 00:06: [mem 0xfefe0000-0xfefe01ff] > [ 0.068047] pnp 00:06: [mem 0xfefe1000-0xfefe1fff] > [ 0.068058] pnp 00:06: [mem 0xfee01000-0xfeefffff] > [ 0.068068] pnp 00:06: disabling [io 0x0900-0x097f] because it overla= ps 0000:00:01.0 BAR 0 [io 0x0900-0x09ff] > [ 0.068068] pnp 00:06: disabling [io 0x0980-0x09ff] because it overla= ps 0000:00:01.0 BAR 0 [io 0x0900-0x09ff] > [ 0.068177] system 00:06: [io 0x04d0-0x04d1] has been reserved > [ 0.068190] system 00:06: [io 0x0800-0x080f] has been reserved > [ 0.068202] system 00:06: [io 0x0500-0x057f] has been reserved > [ 0.068214] system 00:06: [io 0x0580-0x05ff] has been reserved > [ 0.068226] system 00:06: [io 0x0800-0x087f] could not be reserved > [ 0.068238] system 00:06: [io 0x0880-0x08ff] has been reserved > [ 0.068250] system 00:06: [io 0x0d00-0x0d7f] has been reserved > [ 0.068262] system 00:06: [io 0x0d80-0x0dff] has been reserved > [ 0.068274] system 00:06: [io 0x1100-0x117f] has been reserved > [ 0.068285] system 00:06: [io 0x1180-0x11ff] has been reserved > [ 0.068298] system 00:06: [mem 0x000d0000-0x000d3fff window] could not= be reserved > [ 0.068312] system 00:06: [mem 0x000d4000-0x000d7fff window] could not= be reserved > [ 0.068325] system 00:06: [mem 0x000de000-0x000dffff window] could not= be reserved > [ 0.068339] system 00:06: [mem 0xfec80000-0x1fd93ffff] could not be re= served > [ 0.068353] system 00:06: [mem 0xfefe0000-0xfefe01ff] has been reserved > [ 0.068365] system 00:06: [mem 0xfefe1000-0xfefe1fff] has been reserved > [ 0.068378] system 00:06: [mem 0xfee01000-0xfeefffff] has been reserved > [ 0.068390] system 00:06: Plug and Play ACPI device, IDs PNP0c02 (acti= ve) > [ 0.068480] pnp 00:07: [mem 0xfed00000-0xfed00fff] > [ 0.068514] pnp 00:07: Plug and Play ACPI device, IDs PNP0103 (active) > [ 0.068609] pnp 00:08: [mem 0xfec00000-0xfec00fff] > [ 0.068620] pnp 00:08: [mem 0xfee00000-0xfee00fff] > [ 0.068629] pnp 00:08: [mem 0xb0000000-0xbfffffff] > [ 0.068675] system 00:08: [mem 0xfec00000-0xfec00fff] could not be res= erved > [ 0.068688] system 00:08: [mem 0xfee00000-0xfee00fff] has been reserved > [ 0.068702] system 00:08: [mem 0xb0000000-0xbfffffff] has been reserved > [ 0.068714] system 00:08: Plug and Play ACPI device, IDs PNP0c02 (acti= ve) > [ 0.068752] pnp 00:09: [io 0x0060] > [ 0.068760] pnp 00:09: [io 0x0064] > [ 0.068768] xen: registering gsi 1 triggering 1 polarity 0 > [ 0.068778] xen_map_pirq_gsi: returning irq 1 for gsi 1 > [ 0.068787] xen: --> pirq=3D1 -> irq=3D1 (gsi=3D1) > [ 0.068802] pnp 00:09: [irq 1] > [ 0.068839] pnp 00:09: Plug and Play ACPI device, IDs PNP0303 PNP030b = (active) > [ 0.069074] pnp 00:0a: [io 0x0000-0xffffffffffffffff disabled] > [ 0.069086] pnp 00:0a: [io 0x0230-0x023f] > [ 0.069094] pnp 00:0a: [io 0x0290-0x029f] > [ 0.069103] pnp 00:0a: [io 0x0a00-0x0a0f] > [ 0.069111] pnp 00:0a: [io 0x0a10-0x0a1f] > [ 0.069157] system 00:0a: [io 0x0230-0x023f] has been reserved > [ 0.069169] system 00:0a: [io 0x0290-0x029f] has been reserved > [ 0.069181] system 00:0a: [io 0x0a00-0x0a0f] has been reserved > [ 0.069193] system 00:0a: [io 0x0a10-0x0a1f] has been reserved > [ 0.069206] system 00:0a: Plug and Play ACPI device, IDs PNP0c02 (acti= ve) > [ 0.069720] pnp 00:0b: [io 0x03f8-0x03ff] > [ 0.069729] xen: registering gsi 4 triggering 1 polarity 0 > [ 0.069739] xen_map_pirq_gsi: returning irq 4 for gsi 4 > [ 0.069748] xen: --> pirq=3D4 -> irq=3D4 (gsi=3D4) > [ 0.069763] pnp 00:0b: [irq 4] > [ 0.069771] pnp 00:0b: [dma 0 disabled] > [ 0.069833] pnp 00:0b: Plug and Play ACPI device, IDs PNP0501 (active) > [ 0.069911] pnp 00:0c: [mem 0xe0000000-0xefffffff] > [ 0.069959] system 00:0c: [mem 0xe0000000-0xefffffff] has been reserved > [ 0.069972] system 00:0c: Plug and Play ACPI device, IDs PNP0c02 (acti= ve) > [ 0.070207] pnp 00:0d: [mem 0x00000000-0x0009ffff] > [ 0.070218] pnp 00:0d: [mem 0x000c0000-0x000cffff] > [ 0.070228] pnp 00:0d: [mem 0x000e0000-0x000fffff] > [ 0.070238] pnp 00:0d: [mem 0x00100000-0xafffffff] > [ 0.070247] pnp 00:0d: [mem 0xfed45000-0xffffffff] > [ 0.070308] system 00:0d: [mem 0x00000000-0x0009ffff] could not be res= erved > [ 0.070320] system 00:0d: [mem 0x000c0000-0x000cffff] could not be res= erved > [ 0.070332] system 00:0d: [mem 0x000e0000-0x000fffff] could not be res= erved > [ 0.070344] system 00:0d: [mem 0x00100000-0xafffffff] could not be res= erved > [ 0.070356] system 00:0d: [mem 0xfed45000-0xffffffff] could not be res= erved > [ 0.070369] system 00:0d: Plug and Play ACPI device, IDs PNP0c01 (acti= ve) > [ 0.070722] pnp: PnP ACPI: found 14 devices > [ 0.070731] ACPI: ACPI bus type pnp unregistered > [ 0.070742] initcall pnpacpi_init+0x0/0x88 returned 0 after 5378 usecs > [ 0.070754] calling pnpbios_init+0x0/0x39f @ 1 > [ 0.070764] PnPBIOS: Disabled > [ 0.070773] initcall pnpbios_init+0x0/0x39f returned -19 after 8 usecs > [ 0.070786] calling chr_dev_init+0x0/0xc9 @ 1 > [ 0.071722] initcall chr_dev_init+0x0/0xc9 returned 0 after 903 usecs > [ 0.071735] calling firmware_class_init+0x0/0x14 @ 1 > [ 0.071752] initcall firmware_class_init+0x0/0x14 returned 0 after 5 u= secs > [ 0.071764] calling thermal_init+0x0/0x5f @ 1 > [ 0.071781] initcall thermal_init+0x0/0x5f returned 0 after 6 usecs > [ 0.071793] calling cpufreq_gov_performance_init+0x0/0xf @ 1 > [ 0.071807] initcall cpufreq_gov_performance_init+0x0/0xf returned 0 a= fter 0 usecs > [ 0.071821] calling init_acpi_pm_clocksource+0x0/0x18d @ 1 > [ 0.074186] PM-Timer failed consistency check (0x0xffffff) - aborting. > [ 0.074199] initcall init_acpi_pm_clocksource+0x0/0x18d returned -19 a= fter 2311 usecs > [ 0.074212] calling pcibios_assign_resources+0x0/0x86 @ 1 > [ 0.074232] PCI: max bus depth: 1 pci_try_num: 2 > [ 0.074271] pci 0000:00:04.0: PCI bridge to [bus 01-01] > [ 0.074281] pci 0000:00:04.0: bridge window [io disabled] > [ 0.074296] pci 0000:00:04.0: bridge window [mem disabled] > [ 0.074309] pci 0000:00:04.0: bridge window [mem pref disabled] > [ 0.074326] pci 0000:00:09.0: PCI bridge to [bus 02-02] > [ 0.074335] pci 0000:00:09.0: bridge window [io disabled] > [ 0.074349] pci 0000:00:09.0: bridge window [mem disabled] > [ 0.074363] pci 0000:00:09.0: bridge window [mem pref disabled] > [ 0.074378] pci 0000:00:0b.0: PCI bridge to [bus 03-03] > [ 0.074388] pci 0000:00:0b.0: bridge window [io disabled] > [ 0.074402] pci 0000:00:0b.0: bridge window [mem disabled] > [ 0.074415] pci 0000:00:0b.0: bridge window [mem pref disabled] > [ 0.074431] pci 0000:00:0c.0: PCI bridge to [bus 04-04] > [ 0.074440] pci 0000:00:0c.0: bridge window [io disabled] > [ 0.074454] pci 0000:00:0c.0: bridge window [mem disabled] > [ 0.074467] pci 0000:00:0c.0: bridge window [mem pref disabled] > [ 0.074491] pci 0000:00:04.0: setting latency timer to 64 > [ 0.074508] pci 0000:00:09.0: setting latency timer to 64 > [ 0.074525] pci 0000:00:0b.0: setting latency timer to 64 > [ 0.074541] pci 0000:00:0c.0: setting latency timer to 64 > [ 0.074552] pci_bus 0000:00: resource 4 [io 0x0000-0x0cf7] > [ 0.074562] pci_bus 0000:00: resource 5 [io 0x0d00-0xffff] > [ 0.074572] pci_bus 0000:00: resource 6 [mem 0x000a0000-0x000bffff] > [ 0.074584] pci_bus 0000:00: resource 7 [mem 0x000d0000-0x000dffff] > [ 0.074595] pci_bus 0000:00: resource 8 [mem 0xb0000000-0xdfffffff] > [ 0.074607] pci_bus 0000:00: resource 9 [mem 0xf0000000-0xfed44fff] > [ 0.074619] pci_bus 0000:01: resource 4 [io 0x0000-0x0cf7] > [ 0.074628] pci_bus 0000:01: resource 5 [io 0x0d00-0xffff] > [ 0.074638] pci_bus 0000:01: resource 6 [mem 0x000a0000-0x000bffff] > [ 0.074650] pci_bus 0000:01: resource 7 [mem 0x000d0000-0x000dffff] > [ 0.074661] pci_bus 0000:01: resource 8 [mem 0xb0000000-0xdfffffff] > [ 0.074673] pci_bus 0000:01: resource 9 [mem 0xf0000000-0xfed44fff] > [ 0.074686] initcall pcibios_assign_resources+0x0/0x86 returned 0 afte= r 451 usecs > [ 0.074699] calling sysctl_core_init+0x0/0x2d @ 1 > [ 0.074723] initcall sysctl_core_init+0x0/0x2d returned 0 after 14 use= cs > [ 0.074736] calling inet_init+0x0/0x243 @ 1 > [ 0.074760] NET: Registered protocol family 2 > [ 0.074823] IP route cache hash table entries: 32768 (order: 5, 131072= bytes) > [ 0.075038] TCP established hash table entries: 131072 (order: 8, 1048= 576 bytes) > [ 0.075469] TCP bind hash table entries: 65536 (order: 7, 524288 bytes) > [ 0.075694] TCP: Hash tables configured (established 131072 bind 65536) > [ 0.075706] TCP reno registered > [ 0.075716] UDP hash table entries: 512 (order: 2, 16384 bytes) > [ 0.075737] UDP-Lite hash table entries: 512 (order: 2, 16384 bytes) > [ 0.075844] initcall inet_init+0x0/0x243 returned 0 after 1068 usecs > [ 0.075858] calling af_unix_init+0x0/0x4d @ 1 > [ 0.075869] NET: Registered protocol family 1 > [ 0.075885] initcall af_unix_init+0x0/0x4d returned 0 after 16 usecs > [ 0.075898] calling pci_apply_final_quirks+0x0/0x106 @ 1 > [ 0.656244] pci 0000:00:00.0: Found enabled HT MSI Mapping > [ 0.656346] pci 0000:00:00.0: Found enabled HT MSI Mapping > [ 0.656462] pci 0000:00:00.0: Found enabled HT MSI Mapping > [ 0.656578] pci 0000:00:00.0: Found enabled HT MSI Mapping > [ 0.656694] pci 0000:00:00.0: Found enabled HT MSI Mapping > [ 0.656826] pci 0000:00:00.0: Found enabled HT MSI Mapping > [ 0.656973] pci 0000:00:00.0: Found enabled HT MSI Mapping > [ 0.657133] pci 0000:00:00.0: Found enabled HT MSI Mapping > [ 0.657153] pci 0000:00:0d.0: Boot video device > [ 0.657174] PCI: CLS 64 bytes, default 64 > [ 0.657186] initcall pci_apply_final_quirks+0x0/0x106 returned 0 after= 567650 usecs > [ 0.657203] calling populate_rootfs+0x0/0x24b @ 1 > [ 0.657256] Trying to unpack rootfs image as initramfs... > [ 2.108479] Freeing initrd memory: 9284k freed > [ 2.111767] initcall populate_rootfs+0x0/0x24b returned 0 after 142045= 5 usecs > [ 2.111789] calling pci_iommu_init+0x0/0x34 @ 1 > [ 2.111801] initcall pci_iommu_init+0x0/0x34 returned 0 after 0 usecs > [ 2.111812] calling i8259A_init_ops+0x0/0x1d @ 1 > [ 2.111824] initcall i8259A_init_ops+0x0/0x1d returned 0 after 1 usecs > [ 2.111835] calling sbf_init+0x0/0xe4 @ 1 > [ 2.111844] initcall sbf_init+0x0/0xe4 returned 0 after 0 usecs > [ 2.111856] calling init_tsc_clocksource+0x0/0x58 @ 1 > [ 2.111878] initcall init_tsc_clocksource+0x0/0x58 returned 0 after 11= usecs > [ 2.111892] calling add_rtc_cmos+0x0/0x7d @ 1 > [ 2.111904] initcall add_rtc_cmos+0x0/0x7d returned 0 after 2 usecs > [ 2.111916] calling i8237A_init_ops+0x0/0x11 @ 1 > [ 2.111993] initcall i8237A_init_ops+0x0/0x11 returned 0 after 64 usecs > [ 2.112007] calling cache_sysfs_init+0x0/0x4f @ 1 > [ 2.112180] initcall cache_sysfs_init+0x0/0x4f returned 0 after 157 us= ecs > [ 2.112193] calling mcheck_init_device+0x0/0xfe @ 1 > [ 2.112204] initcall mcheck_init_device+0x0/0xfe returned -5 after 0 u= secs > [ 2.112216] initcall mcheck_init_device+0x0/0xfe returned with error c= ode -5=20 > [ 2.112230] calling threshold_init_device+0x0/0x71 @ 1 > [ 2.112241] initcall threshold_init_device+0x0/0x71 returned 0 after 0= usecs > [ 2.112255] calling thermal_throttle_init_device+0x0/0x77 @ 1 > [ 2.112267] initcall thermal_throttle_init_device+0x0/0x77 returned 0 = after 0 usecs > [ 2.112280] calling ioapic_init_ops+0x0/0x11 @ 1 > [ 2.112291] initcall ioapic_init_ops+0x0/0x11 returned 0 after 0 usecs > [ 2.112302] calling add_pcspkr+0x0/0x43 @ 1 > [ 2.112335] initcall add_pcspkr+0x0/0x43 returned 0 after 22 usecs > [ 2.112349] calling start_periodic_check_for_corruption+0x0/0x50 @ 1 > [ 2.112362] initcall start_periodic_check_for_corruption+0x0/0x50 retu= rned 0 after 0 usecs > [ 2.112376] calling crc32c_intel_mod_init+0x0/0x22 @ 1 > [ 2.112387] initcall crc32c_intel_mod_init+0x0/0x22 returned -19 after= 0 usecs > [ 2.112400] calling init_sched_debug_procfs+0x0/0x30 @ 1 > [ 2.112416] initcall init_sched_debug_procfs+0x0/0x30 returned 0 after= 5 usecs > [ 2.112429] calling proc_schedstat_init+0x0/0x27 @ 1 > [ 2.112442] initcall proc_schedstat_init+0x0/0x27 returned 0 after 1 u= secs > [ 2.112454] calling proc_execdomains_init+0x0/0x27 @ 1 > [ 2.112466] initcall proc_execdomains_init+0x0/0x27 returned 0 after 1= usecs > [ 2.112479] calling ioresources_init+0x0/0x44 @ 1 > [ 2.112492] initcall ioresources_init+0x0/0x44 returned 0 after 2 usecs > [ 2.112504] calling uid_cache_init+0x0/0x8a @ 1 > [ 2.112521] initcall uid_cache_init+0x0/0x8a returned 0 after 6 usecs > [ 2.112533] calling init_posix_timers+0x0/0x1cb @ 1 > [ 2.112554] initcall init_posix_timers+0x0/0x1cb returned 0 after 10 u= secs > [ 2.112566] calling init_posix_cpu_timers+0x0/0x9b @ 1 > [ 2.112577] initcall init_posix_cpu_timers+0x0/0x9b returned 0 after 0= usecs > [ 2.112591] calling nsproxy_cache_init+0x0/0x32 @ 1 > [ 2.112602] initcall nsproxy_cache_init+0x0/0x32 returned 0 after 1 us= ecs > [ 2.112614] calling timekeeping_init_ops+0x0/0x11 @ 1 > [ 2.112625] initcall timekeeping_init_ops+0x0/0x11 returned 0 after 0 = usecs > [ 2.112637] calling init_clocksource_sysfs+0x0/0x43 @ 1 > [ 2.112657] initcall init_clocksource_sysfs+0x0/0x43 returned 0 after = 9 usecs > [ 2.112671] calling init_timer_list_procfs+0x0/0x30 @ 1 > [ 2.112684] initcall init_timer_list_procfs+0x0/0x30 returned 0 after = 1 usecs > [ 2.112697] calling alarmtimer_init+0x0/0x136 @ 1 > [ 2.112728] initcall alarmtimer_init+0x0/0x136 returned 0 after 20 use= cs > [ 2.112741] calling init_tstats_procfs+0x0/0x30 @ 1 > [ 2.112754] initcall init_tstats_procfs+0x0/0x30 returned 0 after 2 us= ecs > [ 2.112766] calling futex_init+0x0/0x5a @ 1 > [ 2.112781] initcall futex_init+0x0/0x5a returned 0 after 4 usecs > [ 2.112792] calling proc_dma_init+0x0/0x27 @ 1 > [ 2.112804] initcall proc_dma_init+0x0/0x27 returned 0 after 1 usecs > [ 2.112816] calling proc_modules_init+0x0/0x27 @ 1 > [ 2.112829] initcall proc_modules_init+0x0/0x27 returned 0 after 1 use= cs > [ 2.112841] calling kallsyms_init+0x0/0x2a @ 1 > [ 2.112853] initcall kallsyms_init+0x0/0x2a returned 0 after 1 usecs > [ 2.112865] calling snapshot_device_init+0x0/0xf @ 1 > [ 2.112920] initcall snapshot_device_init+0x0/0xf returned 0 after 43 = usecs > [ 2.112932] calling crash_save_vmcoreinfo_init+0x0/0x4b4 @ 1 > [ 2.112959] initcall crash_save_vmcoreinfo_init+0x0/0x4b4 returned 0 a= fter 14 usecs > [ 2.112973] calling crash_notes_memory_init+0x0/0x35 @ 1 > [ 2.112986] initcall crash_notes_memory_init+0x0/0x35 returned 0 after= 2 usecs > [ 2.113000] calling user_namespaces_init+0x0/0x32 @ 1 > [ 2.113014] initcall user_namespaces_init+0x0/0x32 returned 0 after 3 = usecs > [ 2.113026] calling pid_namespaces_init+0x0/0x32 @ 1 > [ 2.113037] initcall pid_namespaces_init+0x0/0x32 returned 0 after 0 u= secs > [ 2.113049] calling ikconfig_init+0x0/0x43 @ 1 > [ 2.113062] initcall ikconfig_init+0x0/0x43 returned 0 after 1 usecs > [ 2.113074] calling audit_init+0x0/0x12c @ 1 > [ 2.113084] audit: initializing netlink socket (disabled) > [ 2.113103] type=3D2000 audit(1316788467.439:1): initialized > [ 2.113115] initcall audit_init+0x0/0x12c returned 0 after 29 usecs > [ 2.113127] calling audit_watch_init+0x0/0x31 @ 1 > [ 2.113138] initcall audit_watch_init+0x0/0x31 returned 0 after 0 usecs > [ 2.113150] calling audit_tree_init+0x0/0x3b @ 1 > [ 2.113161] initcall audit_tree_init+0x0/0x3b returned 0 after 0 usecs > [ 2.113173] calling hung_task_init+0x0/0x56 @ 1 > [ 2.113260] initcall hung_task_init+0x0/0x56 returned 0 after 73 usecs > [ 2.113273] calling utsname_sysctl_init+0x0/0x11 @ 1 > [ 2.113300] initcall utsname_sysctl_init+0x0/0x11 returned 0 after 15 = usecs > [ 2.113313] calling init_tracepoints+0x0/0x20 @ 1 > [ 2.113324] initcall init_tracepoints+0x0/0x20 returned 0 after 0 usecs > [ 2.113336] calling init_lstats_procfs+0x0/0x2a @ 1 > [ 2.113348] initcall init_lstats_procfs+0x0/0x2a returned 0 after 1 us= ecs > [ 2.113360] calling ftrace_mod_cmd_init+0x0/0xf @ 1 > [ 2.113370] initcall ftrace_mod_cmd_init+0x0/0xf returned 0 after 0 us= ecs > [ 2.113382] calling init_events+0x0/0x5f @ 1 > [ 2.113397] initcall init_events+0x0/0x5f returned 0 after 4 usecs > [ 2.113408] calling init_function_trace+0x0/0x35 @ 1 > [ 2.113420] initcall init_function_trace+0x0/0x35 returned 0 after 1 u= secs > [ 2.113432] calling init_wakeup_tracer+0x0/0x1d @ 1 > [ 2.113443] initcall init_wakeup_tracer+0x0/0x1d returned 0 after 0 us= ecs > [ 2.113454] calling stack_trace_init+0x0/0x68 @ 1 > [ 2.113470] initcall stack_trace_init+0x0/0x68 returned 0 after 5 usecs > [ 2.113482] calling init_mmio_trace+0x0/0xf @ 1 > [ 2.113493] initcall init_mmio_trace+0x0/0xf returned 0 after 0 usecs > [ 2.113505] calling init_graph_trace+0x0/0x6e @ 1 > [ 2.113517] initcall init_graph_trace+0x0/0x6e returned 0 after 2 usecs > [ 2.113528] calling init_blk_tracer+0x0/0x56 @ 1 > [ 2.113540] initcall init_blk_tracer+0x0/0x56 returned 0 after 1 usecs > [ 2.113552] calling perf_event_sysfs_init+0x0/0x8f @ 1 > [ 2.113599] initcall perf_event_sysfs_init+0x0/0x8f returned 0 after 3= 5 usecs > [ 2.113614] calling init_per_zone_wmark_min+0x0/0x77 @ 1 > [ 2.116055] initcall init_per_zone_wmark_min+0x0/0x77 returned 0 after= 4343 usecs > [ 2.116055] calling kswapd_init+0x0/0x1d @ 1 > [ 2.118270] initcall kswapd_init+0x0/0x1d returned 0 after 159 usecs > [ 2.118284] calling extfrag_debug_init+0x0/0x72 @ 1 > [ 2.118304] initcall extfrag_debug_init+0x0/0x72 returned 0 after 8 us= ecs > [ 2.118316] calling setup_vmstat+0x0/0xca @ 1 > [ 2.118341] initcall setup_vmstat+0x0/0xca returned 0 after 14 usecs > [ 2.118353] calling mm_sysfs_init+0x0/0x22 @ 1 > [ 2.118369] initcall mm_sysfs_init+0x0/0x22 returned 0 after 4 usecs > [ 2.118381] calling proc_vmalloc_init+0x0/0x2a @ 1 > [ 2.118393] initcall proc_vmalloc_init+0x0/0x2a returned 0 after 1 use= cs > [ 2.118405] calling init_emergency_pool+0x0/0x7e @ 1 > [ 2.118436] highmem bounce pool size: 64 pages > [ 2.118447] initcall init_emergency_pool+0x0/0x7e returned 0 after 30 = usecs > [ 2.118459] calling procswaps_init+0x0/0x27 @ 1 > [ 2.118471] initcall procswaps_init+0x0/0x27 returned 0 after 1 usecs > [ 2.118483] calling hugetlb_init+0x0/0x321 @ 1 > [ 2.118494] HugeTLB registered 2 MB page size, pre-allocated 0 pages > [ 2.118511] initcall hugetlb_init+0x0/0x321 returned 0 after 17 usecs > [ 2.118523] calling ksm_init+0x0/0x15c @ 1 > [ 2.118615] initcall ksm_init+0x0/0x15c returned 0 after 80 usecs > [ 2.118629] calling slab_proc_init+0x0/0x2a @ 1 > [ 2.118641] initcall slab_proc_init+0x0/0x2a returned 0 after 2 usecs > [ 2.118653] calling slab_sysfs_init+0x0/0xdf @ 1 > [ 2.119725] initcall slab_sysfs_init+0x0/0xdf returned 0 after 1036 us= ecs > [ 2.119737] calling fcntl_init+0x0/0x2f @ 1 > [ 2.119752] initcall fcntl_init+0x0/0x2f returned 0 after 4 usecs > [ 2.119764] calling proc_filesystems_init+0x0/0x27 @ 1 > [ 2.119777] initcall proc_filesystems_init+0x0/0x27 returned 0 after 2= usecs > [ 2.119791] calling fsnotify_mark_init+0x0/0x46 @ 1 > [ 2.119868] initcall fsnotify_mark_init+0x0/0x46 returned 0 after 64 u= secs > [ 2.119880] calling dnotify_init+0x0/0x7c @ 1 > [ 2.119898] initcall dnotify_init+0x0/0x7c returned 0 after 7 usecs > [ 2.119910] calling inotify_user_setup+0x0/0x78 @ 1 > [ 2.119928] initcall inotify_user_setup+0x0/0x78 returned 0 after 6 us= ecs > [ 2.119940] calling aio_setup+0x0/0x87 @ 1 > [ 2.119960] initcall aio_setup+0x0/0x87 returned 0 after 10 usecs > [ 2.119972] calling proc_locks_init+0x0/0x27 @ 1 > [ 2.119984] initcall proc_locks_init+0x0/0x27 returned 0 after 2 usecs > [ 2.119996] calling init_mbcache+0x0/0x11 @ 1 > [ 2.120008] initcall init_mbcache+0x0/0x11 returned 0 after 1 usecs > [ 2.120020] calling proc_cmdline_init+0x0/0x27 @ 1 > [ 2.120032] initcall proc_cmdline_init+0x0/0x27 returned 0 after 2 use= cs > [ 2.120044] calling proc_consoles_init+0x0/0x27 @ 1 > [ 2.120061] initcall proc_consoles_init+0x0/0x27 returned 0 after 1 us= ecs > [ 2.120073] calling proc_cpuinfo_init+0x0/0x27 @ 1 > [ 2.120085] initcall proc_cpuinfo_init+0x0/0x27 returned 0 after 1 use= cs > [ 2.120097] calling proc_devices_init+0x0/0x27 @ 1 > [ 2.120110] initcall proc_devices_init+0x0/0x27 returned 0 after 1 use= cs > [ 2.120122] calling proc_interrupts_init+0x0/0x27 @ 1 > [ 2.120134] initcall proc_interrupts_init+0x0/0x27 returned 0 after 1 = usecs > [ 2.120146] calling proc_loadavg_init+0x0/0x27 @ 1 > [ 2.120158] initcall proc_loadavg_init+0x0/0x27 returned 0 after 1 use= cs > [ 2.120169] calling proc_meminfo_init+0x0/0x27 @ 1 > [ 2.120181] initcall proc_meminfo_init+0x0/0x27 returned 0 after 1 use= cs > [ 2.120193] calling proc_stat_init+0x0/0x27 @ 1 > [ 2.120204] initcall proc_stat_init+0x0/0x27 returned 0 after 1 usecs > [ 2.120216] calling proc_uptime_init+0x0/0x27 @ 1 > [ 2.120228] initcall proc_uptime_init+0x0/0x27 returned 0 after 1 usecs > [ 2.120240] calling proc_version_init+0x0/0x27 @ 1 > [ 2.120251] initcall proc_version_init+0x0/0x27 returned 0 after 1 use= cs > [ 2.120263] calling proc_softirqs_init+0x0/0x27 @ 1 > [ 2.120275] initcall proc_softirqs_init+0x0/0x27 returned 0 after 1 us= ecs > [ 2.120287] calling proc_kcore_init+0x0/0xae @ 1 > [ 2.120299] initcall proc_kcore_init+0x0/0xae returned 0 after 2 usecs > [ 2.120311] calling vmcore_init+0x0/0x37c @ 1 > [ 2.120321] initcall vmcore_init+0x0/0x37c returned 0 after 0 usecs > [ 2.120333] calling proc_kmsg_init+0x0/0x2a @ 1 > [ 2.120345] initcall proc_kmsg_init+0x0/0x2a returned 0 after 1 usecs > [ 2.120357] calling proc_page_init+0x0/0x4a @ 1 > [ 2.120369] initcall proc_page_init+0x0/0x4a returned 0 after 2 usecs > [ 2.120381] calling init_devpts_fs+0x0/0x3d @ 1 > [ 2.120402] initcall init_devpts_fs+0x0/0x3d returned 0 after 10 usecs > [ 2.120414] calling init_ext3_fs+0x0/0x6a @ 1 > [ 2.120481] initcall init_ext3_fs+0x0/0x6a returned 0 after 55 usecs > [ 2.120494] calling init_ext2_fs+0x0/0x6a @ 1 > [ 2.120526] initcall init_ext2_fs+0x0/0x6a returned 0 after 21 usecs > [ 2.120538] calling ext4_init_fs+0x0/0x1ba @ 1 > [ 2.120677] initcall ext4_init_fs+0x0/0x1ba returned 0 after 125 usecs > [ 2.120690] calling journal_init+0x0/0xa3 @ 1 > [ 2.120763] initcall journal_init+0x0/0xa3 returned 0 after 61 usecs > [ 2.120776] calling journal_init+0x0/0x104 @ 1 > [ 2.120821] initcall journal_init+0x0/0x104 returned 0 after 33 usecs > [ 2.120833] calling init_squashfs_fs+0x0/0x64 @ 1 > [ 2.120862] squashfs: version 4.0 (2009/01/31) Phillip Lougher > [ 2.120874] initcall init_squashfs_fs+0x0/0x64 returned 0 after 29 use= cs > [ 2.120886] calling init_ramfs_fs+0x0/0xf @ 1 > [ 2.120898] initcall init_ramfs_fs+0x0/0xf returned 0 after 0 usecs > [ 2.120909] calling init_hugetlbfs_fs+0x0/0x8b @ 1 > [ 2.120954] initcall init_hugetlbfs_fs+0x0/0x8b returned 0 after 33 us= ecs > [ 2.120966] calling init_fat_fs+0x0/0x4c @ 1 > [ 2.121011] initcall init_fat_fs+0x0/0x4c returned 0 after 33 usecs > [ 2.121023] calling init_vfat_fs+0x0/0xf @ 1 > [ 2.121035] initcall init_vfat_fs+0x0/0xf returned 0 after 1 usecs > [ 2.121047] calling init_msdos_fs+0x0/0xf @ 1 > [ 2.121058] initcall init_msdos_fs+0x0/0xf returned 0 after 0 usecs > [ 2.121070] calling init_iso9660_fs+0x0/0x6a @ 1 > [ 2.121129] initcall init_iso9660_fs+0x0/0x6a returned 0 after 47 usecs > [ 2.121142] calling init_pstore_fs+0x0/0xf @ 1 > [ 2.121154] initcall init_pstore_fs+0x0/0xf returned 0 after 1 usecs > [ 2.121166] calling ipc_init+0x0/0x20 @ 1 > [ 2.121176] msgmni has been set to 1148 > [ 2.121189] initcall ipc_init+0x0/0x20 returned 0 after 13 usecs > [ 2.121201] calling ipc_sysctl_init+0x0/0x11 @ 1 > [ 2.121231] initcall ipc_sysctl_init+0x0/0x11 returned 0 after 19 usecs > [ 2.121243] calling init_mqueue_fs+0x0/0x9f @ 1 > [ 2.121292] initcall init_mqueue_fs+0x0/0x9f returned 0 after 36 usecs > [ 2.121305] calling crypto_wq_init+0x0/0x38 @ 1 > [ 2.121380] initcall crypto_wq_init+0x0/0x38 returned 0 after 62 usecs > [ 2.121393] calling crypto_algapi_init+0x0/0xc @ 1 > [ 2.121406] initcall crypto_algapi_init+0x0/0xc returned 0 after 2 use= cs > [ 2.121419] calling skcipher_module_init+0x0/0x2e @ 1 > [ 2.121430] initcall skcipher_module_init+0x0/0x2e returned 0 after 0 = usecs > [ 2.121441] calling chainiv_module_init+0x0/0xf @ 1 > [ 2.121452] initcall chainiv_module_init+0x0/0xf returned 0 after 1 us= ecs > [ 2.121464] calling eseqiv_module_init+0x0/0xf @ 1 > [ 2.121474] initcall eseqiv_module_init+0x0/0xf returned 0 after 0 use= cs > [ 2.121485] calling hmac_module_init+0x0/0xf @ 1 > [ 2.121496] initcall hmac_module_init+0x0/0xf returned 0 after 0 usecs > [ 2.121507] calling md5_mod_init+0x0/0xf @ 1 > [ 2.121597] initcall md5_mod_init+0x0/0xf returned 0 after 77 usecs > [ 2.121609] calling sha1_generic_mod_init+0x0/0xf @ 1 > [ 2.121665] initcall sha1_generic_mod_init+0x0/0xf returned 0 after 44= usecs > [ 2.121679] calling crypto_ecb_module_init+0x0/0xf @ 1 > [ 2.121690] initcall crypto_ecb_module_init+0x0/0xf returned 0 after 0= usecs > [ 2.121703] calling crypto_cbc_module_init+0x0/0xf @ 1 > [ 2.121714] initcall crypto_cbc_module_init+0x0/0xf returned 0 after 0= usecs > [ 2.121727] calling crc32c_mod_init+0x0/0xf @ 1 > [ 2.121814] initcall crc32c_mod_init+0x0/0xf returned 0 after 74 usecs > [ 2.121826] calling krng_mod_init+0x0/0xf @ 1 > [ 2.121882] initcall krng_mod_init+0x0/0xf returned 0 after 44 usecs > [ 2.121895] calling proc_genhd_init+0x0/0x44 @ 1 > [ 2.121908] initcall proc_genhd_init+0x0/0x44 returned 0 after 3 usecs > [ 2.121920] calling bsg_init+0x0/0x119 @ 1 > [ 2.121961] Block layer SCSI generic (bsg) driver version 0.4 loaded (= major 253) > [ 2.121974] initcall bsg_init+0x0/0x119 returned 0 after 44 usecs > [ 2.121986] calling init_cgroup_blkio+0x0/0xf @ 1 > [ 2.121997] initcall init_cgroup_blkio+0x0/0xf returned 0 after 0 usecs > [ 2.122008] calling throtl_init+0x0/0x49 @ 1 > [ 2.122086] initcall throtl_init+0x0/0x49 returned 0 after 66 usecs > [ 2.122098] calling noop_init+0x0/0x11 @ 1 > [ 2.122107] io scheduler noop registered > [ 2.122115] initcall noop_init+0x0/0x11 returned 0 after 8 usecs > [ 2.122127] calling deadline_init+0x0/0x11 @ 1 > [ 2.122137] io scheduler deadline registered > [ 2.122147] initcall deadline_init+0x0/0x11 returned 0 after 9 usecs > [ 2.122158] calling cfq_init+0x0/0xbb @ 1 > [ 2.122175] io scheduler cfq registered (default) > [ 2.122185] initcall cfq_init+0x0/0xbb returned 0 after 18 usecs > [ 2.122197] calling libcrc32c_mod_init+0x0/0x25 @ 1 > [ 2.122209] initcall libcrc32c_mod_init+0x0/0x25 returned 0 after 2 us= ecs > [ 2.122221] calling percpu_counter_startup+0x0/0x2e @ 1 > [ 2.122232] initcall percpu_counter_startup+0x0/0x2e returned 0 after = 0 usecs > [ 2.122245] calling audit_classes_init+0x0/0x4f @ 1 > [ 2.122257] initcall audit_classes_init+0x0/0x4f returned 0 after 1 us= ecs > [ 2.122268] calling lnw_gpio_init+0x0/0x3a @ 1 > [ 2.122305] initcall lnw_gpio_init+0x0/0x3a returned 0 after 25 usecs > [ 2.122317] calling timbgpio_init+0x0/0xf @ 1 > [ 2.122333] initcall timbgpio_init+0x0/0xf returned 0 after 5 usecs > [ 2.122344] calling pci_proc_init+0x0/0x64 @ 1 > [ 2.122392] initcall pci_proc_init+0x0/0x64 returned 0 after 36 usecs > [ 2.122404] calling pcie_portdrv_init+0x0/0x6f @ 1 > [ 2.122449] pcieport 0000:00:09.0: setting latency timer to 64 > [ 2.122587] pcieport 0000:00:0b.0: setting latency timer to 64 > [ 2.122709] pcieport 0000:00:0c.0: setting latency timer to 64 > [ 2.122825] initcall pcie_portdrv_init+0x0/0x6f returned 0 after 401 u= secs > [ 2.122838] calling aer_service_init+0x0/0x28 @ 1 > [ 2.122854] initcall aer_service_init+0x0/0x28 returned 0 after 5 usecs > [ 2.122866] calling pcie_pme_service_init+0x0/0xf @ 1 > [ 2.122882] initcall pcie_pme_service_init+0x0/0xf returned 0 after 5 = usecs > [ 2.122894] calling ioapic_init+0x0/0x16 @ 1 > [ 2.122912] initcall ioapic_init+0x0/0x16 returned 0 after 8 usecs > [ 2.122924] calling pci_hotplug_init+0x0/0x4d @ 1 > [ 2.122934] pci_hotplug: PCI Hot Plug PCI Core version: 0.5 > [ 2.122944] initcall pci_hotplug_init+0x0/0x4d returned 0 after 9 usecs > [ 2.122956] calling pcied_init+0x0/0xf1 @ 1 > [ 2.122983] pciehp: PCI Express Hot Plug Controller Driver version: 0.4 > [ 2.122996] initcall pcied_init+0x0/0xf1 returned 0 after 29 usecs > [ 2.123008] calling intel_idle_init+0x0/0x377 @ 1 > [ 2.123018] initcall intel_idle_init+0x0/0x377 returned -19 after 0 us= ecs > [ 2.123031] calling acpi_reserve_resources+0x0/0xc8 @ 1 > [ 2.123044] initcall acpi_reserve_resources+0x0/0xc8 returned 0 after = 3 usecs > [ 2.123058] calling irqrouter_init_ops+0x0/0x23 @ 1 > [ 2.123069] initcall irqrouter_init_ops+0x0/0x23 returned 0 after 0 us= ecs > [ 2.123081] calling acpi_ac_init+0x0/0x3d @ 1 > [ 2.123115] initcall acpi_ac_init+0x0/0x3d returned 0 after 23 usecs > [ 2.123128] calling acpi_button_init+0x0/0xf @ 1 > [ 2.123177] input: Power Button as /devices/LNXSYSTM:00/device:00/PNP0= C0C:00/input/input0 > [ 2.123193] ACPI: Power Button [PWRB] > [ 2.123231] input: Power Button as /devices/LNXSYSTM:00/LNXPWRBN:00/in= put/input1 > [ 2.123245] ACPI: Power Button [PWRF] > [ 2.123272] initcall acpi_button_init+0x0/0xf returned 0 after 130 use= cs > [ 2.123284] calling acpi_fan_init+0x0/0x15 @ 1 > [ 2.123307] initcall acpi_fan_init+0x0/0x15 returned 0 after 12 usecs > [ 2.123320] calling acpi_pci_slot_init+0x0/0x1b @ 1 > [ 2.123480] initcall acpi_pci_slot_init+0x0/0x1b returned 0 after 145 = usecs > [ 2.123493] calling acpi_processor_init+0x0/0xd0 @ 1 > [ 2.123503] ACPI: acpi_idle registered with cpuidle > [ 2.123643] initcall acpi_processor_init+0x0/0xd0 returned 0 after 135= usecs > [ 2.123658] calling acpi_container_init+0x0/0x4d @ 1 > [ 2.125862] initcall acpi_container_init+0x0/0x4d returned 0 after 214= 1 usecs > [ 2.125877] calling acpi_thermal_init+0x0/0x3e @ 1 > [ 2.125902] initcall acpi_thermal_init+0x0/0x3e returned 0 after 13 us= ecs > [ 2.125914] calling acpi_battery_init+0x0/0x13 @ 1 > [ 2.125929] initcall acpi_battery_init+0x0/0x13 returned 0 after 4 use= cs > [ 2.125941] calling acpi_smb_hc_init+0x0/0x15 @ 1 > [ 2.125989] initcall acpi_smb_hc_init+0x0/0x15 returned 0 after 36 use= cs > [ 2.126002] calling acpi_sbs_init+0x0/0x46 @ 1 > [ 2.126026] initcall acpi_sbs_init+0x0/0x46 returned 0 after 12 usecs > [ 2.126039] calling erst_init+0x0/0x2c4 @ 1 > [ 2.126048] ERST: Table is not found! > [ 2.126057] initcall erst_init+0x0/0x2c4 returned 0 after 7 usecs > [ 2.126069] calling pnpbios_thread_init+0x0/0x5e @ 1 > [ 2.126102] calling 1_acpi_battery_init_async+0x0/0x34 @ 5 > [ 2.126127] initcall 1_acpi_battery_init_async+0x0/0x34 returned 0 aft= er 13 usecs > [ 2.126150] initcall pnpbios_thread_init+0x0/0x5e returned 0 after 68 = usecs > [ 2.126163] calling isapnp_init+0x0/0x642 @ 1 > [ 2.126180] isapnp: Scanning for PnP cards... > [ 2.480760] isapnp: No Plug & Play device found > [ 2.480772] initcall isapnp_init+0x0/0x642 returned 0 after 346287 use= cs > [ 2.480784] calling virtio_pci_init+0x0/0x16 @ 1 > [ 2.480807] initcall virtio_pci_init+0x0/0x16 returned 0 after 12 usecs > [ 2.480820] calling xenbus_probe_initcall+0x0/0x38 @ 1 > [ 2.480831] initcall xenbus_probe_initcall+0x0/0x38 returned 0 after 0= usecs > [ 2.480844] calling xen_tmem_init+0x0/0x7 @ 1 > [ 2.480855] initcall xen_tmem_init+0x0/0x7 returned 0 after 0 usecs > [ 2.480867] calling evtchn_init+0x0/0x69 @ 1 > [ 2.480919] Event-channel device installed. > [ 2.480929] initcall evtchn_init+0x0/0x69 returned 0 after 49 usecs > [ 2.480941] calling gntdev_init+0x0/0x45 @ 1 > [ 2.480966] initcall gntdev_init+0x0/0x45 returned 0 after 14 usecs > [ 2.480978] calling gntalloc_init+0x0/0x37 @ 1 > [ 2.481003] initcall gntalloc_init+0x0/0x37 returned 0 after 13 usecs > [ 2.481015] calling xenfs_init+0x0/0x2b @ 1 > [ 2.481028] initcall xenfs_init+0x0/0x2b returned 0 after 1 usecs > [ 2.481040] calling hypervisor_subsys_init+0x0/0x21 @ 1 > [ 2.481051] initcall hypervisor_subsys_init+0x0/0x21 returned 0 after = 0 usecs > [ 2.481064] calling hyper_sysfs_init+0x0/0xc4 @ 1 > [ 2.481081] initcall hyper_sysfs_init+0x0/0xc4 returned 0 after 5 usecs > [ 2.481093] calling platform_pci_module_init+0x0/0x24 @ 1 > [ 2.481104] initcall platform_pci_module_init+0x0/0x24 returned -19 af= ter 0 usecs > [ 2.481117] calling pty_init+0x0/0x2bd @ 1 > [ 2.481165] initcall pty_init+0x0/0x2bd returned 0 after 37 usecs > [ 2.481177] calling sysrq_init+0x0/0x7a @ 1 > [ 2.481191] initcall sysrq_init+0x0/0x7a returned 0 after 3 usecs > [ 2.481203] calling xen_hvc_init+0x0/0x115 @ 1 > [ 2.481397] initcall xen_hvc_init+0x0/0x115 returned 0 after 179 usecs > [ 2.481410] calling serial8250_init+0x0/0x154 @ 1 > [ 2.481420] Serial: 8250/16550 driver, 32 ports, IRQ sharing enabled > [ 2.485280] serial8250: ttyS0 at I/O 0x3f8 (irq =3D 4) is a 16550A > [ 2.624160] initcall serial8250_init+0x0/0x154 returned 0 after 139389= usecs > [ 2.624184] calling serial8250_pnp_init+0x0/0xf @ 1 > [ 2.628097] 00:0b: ttyS0 at I/O 0x3f8 (irq =3D 4) is a 16550A > [ 2.648158] initcall serial8250_pnp_init+0x0/0xf returned 0 after 2339= 7 usecs > [ 2.648182] calling serial8250_pci_init+0x0/0x16 @ 1 > [ 2.648225] initcall serial8250_pci_init+0x0/0x16 returned 0 after 31 = usecs > [ 2.648238] calling init_kgdboc+0x0/0x15 @ 1 > [ 2.648250] initcall init_kgdboc+0x0/0x15 returned 0 after 2 usecs > [ 2.648263] calling rand_initialize+0x0/0x30 @ 1 > [ 2.648288] initcall rand_initialize+0x0/0x30 returned 0 after 15 usecs > [ 2.648300] calling ttyprintk_init+0x0/0x12d @ 1 > [ 2.648377] initcall ttyprintk_init+0x0/0x12d returned 0 after 65 usecs > [ 2.648389] calling hpet_init+0x0/0x57 @ 1 > [ 2.648525] hpet_acpi_add: no address or irqs in _CRS > [ 2.648554] initcall hpet_init+0x0/0x57 returned 0 after 152 usecs > [ 2.648566] calling agp_init+0x0/0x2f @ 1 > [ 2.648574] Linux agpgart interface v0.103 > [ 2.648582] initcall agp_init+0x0/0x2f returned 0 after 7 usecs > [ 2.648594] calling agp_amdk7_init+0x0/0x24 @ 1 > [ 2.648613] initcall agp_amdk7_init+0x0/0x24 returned 0 after 9 usecs > [ 2.648625] calling agp_amd64_mod_init+0x0/0xa @ 1 > [ 2.648837] initcall agp_amd64_mod_init+0x0/0xa returned -19 after 197= usecs > [ 2.648851] calling agp_intel_init+0x0/0x24 @ 1 > [ 2.648874] initcall agp_intel_init+0x0/0x24 returned 0 after 12 usecs > [ 2.648886] calling agp_nvidia_init+0x0/0x24 @ 1 > [ 2.648904] initcall agp_nvidia_init+0x0/0x24 returned 0 after 8 usecs > [ 2.648916] calling agp_via_init+0x0/0x24 @ 1 > [ 2.648937] initcall agp_via_init+0x0/0x24 returned 0 after 11 usecs > [ 2.648949] calling cn_proc_init+0x0/0x33 @ 1 > [ 2.648960] initcall cn_proc_init+0x0/0x33 returned 0 after 1 usecs > [ 2.648972] calling isa_bus_init+0x0/0x33 @ 1 > [ 2.648997] initcall isa_bus_init+0x0/0x33 returned 0 after 14 usecs > [ 2.649010] calling topology_sysfs_init+0x0/0x4c @ 1 > [ 2.649032] initcall topology_sysfs_init+0x0/0x4c returned 0 after 11 = usecs > [ 2.649043] calling brd_init+0x0/0x18a @ 1 > [ 2.649796] brd: module loaded > [ 2.649805] initcall brd_init+0x0/0x18a returned 0 after 735 usecs > [ 2.649817] calling loop_init+0x0/0x1a4 @ 1 > [ 2.650195] loop: module loaded > [ 2.650205] initcall loop_init+0x0/0x1a4 returned 0 after 368 usecs > [ 2.650216] calling pkt_init+0x0/0x1a2 @ 1 > [ 2.650262] initcall pkt_init+0x0/0x1a2 returned 0 after 36 usecs > [ 2.650274] calling init+0x0/0x79 @ 1 > [ 2.650294] initcall init+0x0/0x79 returned 0 after 11 usecs > [ 2.650306] calling htcpld_core_init+0x0/0x24 @ 1 > [ 2.650334] initcall htcpld_core_init+0x0/0x24 returned -19 after 18 u= secs > [ 2.650346] calling wm8994_i2c_init+0x0/0x30 @ 1 > [ 2.650362] initcall wm8994_i2c_init+0x0/0x30 returned 0 after 5 usecs > [ 2.650374] calling adp5520_init+0x0/0x11 @ 1 > [ 2.650389] initcall adp5520_init+0x0/0x11 returned 0 after 5 usecs > [ 2.650401] calling mac_hid_init+0x0/0x1c @ 1 > [ 2.650418] initcall mac_hid_init+0x0/0x1c returned 0 after 6 usecs > [ 2.650430] calling spi_transport_init+0x0/0x75 @ 1 > [ 2.650452] initcall spi_transport_init+0x0/0x75 returned 0 after 11 u= secs > [ 2.650464] calling scsi_dh_init+0x0/0x4c @ 1 > [ 2.650475] initcall scsi_dh_init+0x0/0x4c returned 0 after 0 usecs > [ 2.650487] calling sym2_init+0x0/0xe4 @ 1 > [ 2.650508] initcall sym2_init+0x0/0xe4 returned 0 after 12 usecs > [ 2.650520] calling init_sd+0x0/0x14b @ 1 > [ 2.650561] initcall init_sd+0x0/0x14b returned 0 after 31 usecs > [ 2.650573] calling init_sr+0x0/0x3d @ 1 > [ 2.650587] initcall init_sr+0x0/0x3d returned 0 after 5 usecs > [ 2.650599] calling init_sg+0x0/0x111 @ 1 > [ 2.650621] initcall init_sg+0x0/0x111 returned 0 after 13 usecs > [ 2.650633] calling adma_ata_init+0x0/0x16 @ 1 > [ 2.650654] initcall adma_ata_init+0x0/0x16 returned 0 after 10 usecs > [ 2.650666] calling piix_init+0x0/0x24 @ 1 > [ 2.650690] initcall piix_init+0x0/0x24 returned 0 after 15 usecs > [ 2.650702] calling sis_init+0x0/0x16 @ 1 > [ 2.650723] initcall sis_init+0x0/0x16 returned 0 after 12 usecs > [ 2.650735] calling pacpi_init+0x0/0x16 @ 1 > [ 2.650788] pata_acpi 0000:00:06.0: setting latency timer to 64 > [ 2.651003] ACPI: PCI Interrupt Link [LSA0] enabled at IRQ 23 > [ 2.651016] xen: registering gsi 23 triggering 0 polarity 1 > [ 2.651035] xen: --> pirq=3D23 -> irq=3D23 (gsi=3D23) > [ 2.651055] pata_acpi 0000:00:08.0: PCI INT A -> Link[LSA0] -> GSI 23 = (level, low) -> IRQ 23 > [ 2.651089] pata_acpi 0000:00:08.0: setting latency timer to 64 > [ 2.651109] pata_acpi 0000:00:08.0: PCI INT A disabled > [ 2.651289] ACPI: PCI Interrupt Link [LSA1] enabled at IRQ 22 > [ 2.651301] xen: registering gsi 22 triggering 0 polarity 1 > [ 2.651315] xen: --> pirq=3D22 -> irq=3D22 (gsi=3D22) > [ 2.651329] pata_acpi 0000:00:08.1: PCI INT B -> Link[LSA1] -> GSI 22 = (level, low) -> IRQ 22 > [ 2.651360] pata_acpi 0000:00:08.1: setting latency timer to 64 > [ 2.651379] pata_acpi 0000:00:08.1: PCI INT B disabled > [ 2.651401] initcall pacpi_init+0x0/0x16 returned 0 after 639 usecs > [ 2.651413] calling ata_generic_init+0x0/0x16 @ 1 > [ 2.651445] initcall ata_generic_init+0x0/0x16 returned 0 after 21 use= cs > [ 2.651457] calling marvell_init+0x0/0x4c @ 1 > [ 2.651504] initcall marvell_init+0x0/0x4c returned 0 after 36 usecs > [ 2.651516] calling davicom_init+0x0/0x4d @ 1 > [ 2.651539] initcall davicom_init+0x0/0x4d returned 0 after 12 usecs > [ 2.651551] calling cicada_init+0x0/0x33 @ 1 > [ 2.651570] initcall cicada_init+0x0/0x33 returned 0 after 8 usecs > [ 2.651582] calling lxt_init+0x0/0x4d @ 1 > [ 2.651605] initcall lxt_init+0x0/0x4d returned 0 after 13 usecs > [ 2.651616] calling qs6612_init+0x0/0xf @ 1 > [ 2.651632] initcall qs6612_init+0x0/0xf returned 0 after 5 usecs > [ 2.651644] calling smsc_init+0x0/0x81 @ 1 > [ 2.651674] initcall smsc_init+0x0/0x81 returned 0 after 20 usecs > [ 2.651686] calling vsc82xx_init+0x0/0x33 @ 1 > [ 2.651705] initcall vsc82xx_init+0x0/0x33 returned 0 after 9 usecs > [ 2.651717] calling broadcom_init+0x0/0x135 @ 1 > [ 2.651778] initcall broadcom_init+0x0/0x135 returned 0 after 49 usecs > [ 2.651790] calling icplus_init+0x0/0x24 @ 1 > [ 2.651811] initcall icplus_init+0x0/0x24 returned 0 after 10 usecs > [ 2.651823] calling realtek_init+0x0/0xf @ 1 > [ 2.651839] initcall realtek_init+0x0/0xf returned 0 after 5 usecs > [ 2.651850] calling et1011c_init+0x0/0xf @ 1 > [ 2.651866] initcall et1011c_init+0x0/0xf returned 0 after 5 usecs > [ 2.651878] calling fixed_mdio_bus_init+0x0/0xf3 @ 1 > [ 2.651912] Fixed MDIO Bus: probed > [ 2.651921] initcall fixed_mdio_bus_init+0x0/0xf3 returned 0 after 32 = usecs > [ 2.651933] calling mdio_gpio_init+0x0/0xf @ 1 > [ 2.651949] initcall mdio_gpio_init+0x0/0xf returned 0 after 6 usecs > [ 2.651961] calling ns_init+0x0/0xf @ 1 > [ 2.651975] initcall ns_init+0x0/0xf returned 0 after 5 usecs > [ 2.651987] calling ste10Xp_init+0x0/0x1d @ 1 > [ 2.652006] initcall ste10Xp_init+0x0/0x1d returned 0 after 9 usecs > [ 2.652018] calling net_olddevs_init+0x0/0x84 @ 1 > [ 2.652032] initcall net_olddevs_init+0x0/0x84 returned 0 after 3 usecs > [ 2.652044] calling ppp_init+0x0/0xe5 @ 1 > [ 2.652052] PPP generic driver version 2.4.2 > [ 2.652106] initcall ppp_init+0x0/0xe5 returned 0 after 51 usecs > [ 2.652118] calling netif_init+0x0/0x5f @ 1 > [ 2.652129] initcall netif_init+0x0/0x5f returned 0 after 0 usecs > [ 2.652141] calling netback_init+0x0/0x1fa @ 1 > [ 2.652378] initcall netback_init+0x0/0x1fa returned 0 after 220 usecs > [ 2.652391] calling tun_init+0x0/0x8b @ 1 > [ 2.652399] tun: Universal TUN/TAP device driver, 1.6 > [ 2.652409] tun: (C) 1999-2004 Max Krasnyansky <maxk@qualcomm.com> > [ 2.652445] initcall tun_init+0x0/0x8b returned 0 after 43 usecs > [ 2.652457] calling init+0x0/0xf @ 1 > [ 2.652471] initcall init+0x0/0xf returned 0 after 5 usecs > [ 2.652482] calling cdrom_init+0x0/0xc @ 1 > [ 2.652502] initcall cdrom_init+0x0/0xc returned 0 after 11 usecs > [ 2.652514] calling mon_init+0x0/0xe2 @ 1 > [ 2.652550] initcall mon_init+0x0/0xe2 returned 0 after 26 usecs > [ 2.652563] calling ehci_hcd_init+0x0/0x6f @ 1 > [ 2.652573] ehci_hcd: USB 2.0 'Enhanced' Host Controller (EHCI) Driver > [ 2.652758] ACPI: PCI Interrupt Link [LUB2] enabled at IRQ 21 > [ 2.652770] xen: registering gsi 21 triggering 0 polarity 1 > [ 2.652784] xen: --> pirq=3D21 -> irq=3D21 (gsi=3D21) > [ 2.652799] ehci_hcd 0000:00:02.1: PCI INT B -> Link[LUB2] -> GSI 21 (= level, low) -> IRQ 21 > [ 2.652825] ehci_hcd 0000:00:02.1: setting latency timer to 64 > [ 2.652838] ehci_hcd 0000:00:02.1: EHCI Host Controller > [ 2.652871] ehci_hcd 0000:00:02.1: new USB bus registered, assigned bu= s number 1 > [ 2.652933] ehci_hcd 0000:00:02.1: debug port 1 > [ 2.652952] ehci_hcd 0000:00:02.1: cache line size of 64 is not suppor= ted > [ 2.652991] ehci_hcd 0000:00:02.1: irq 21, io mem 0xdfffac00 > [ 2.664116] ehci_hcd 0000:00:02.1: USB 2.0 started, EHCI 1.00 > [ 2.664300] hub 1-0:1.0: USB hub found > [ 2.664312] hub 1-0:1.0: 10 ports detected > [ 2.664392] initcall ehci_hcd_init+0x0/0x6f returned 0 after 11538 use= cs > [ 2.664405] calling ohci_hcd_mod_init+0x0/0x51 @ 1 > [ 2.664415] ohci_hcd: USB 1.1 'Open' Host Controller (OHCI) Driver > [ 2.664642] ACPI: PCI Interrupt Link [LUB0] enabled at IRQ 20 > [ 2.664654] xen: registering gsi 20 triggering 0 polarity 1 > [ 2.664675] xen: --> pirq=3D20 -> irq=3D20 (gsi=3D20) > [ 2.664694] ohci_hcd 0000:00:02.0: PCI INT A -> Link[LUB0] -> GSI 20 (= level, low) -> IRQ 20 > [ 2.664730] ohci_hcd 0000:00:02.0: setting latency timer to 64 > [ 2.664744] ohci_hcd 0000:00:02.0: OHCI Host Controller > [ 2.664783] ohci_hcd 0000:00:02.0: new USB bus registered, assigned bu= s number 2 > [ 2.664852] ohci_hcd 0000:00:02.0: irq 20, io mem 0xdfffb000 > [ 2.722246] hub 2-0:1.0: USB hub found > [ 2.722266] hub 2-0:1.0: 10 ports detected > [ 2.722352] initcall ohci_hcd_mod_init+0x0/0x51 returned 0 after 56575= usecs > [ 2.722366] calling uhci_hcd_init+0x0/0xb8 @ 1 > [ 2.722377] uhci_hcd: USB Universal Host Controller Interface driver > [ 2.722431] initcall uhci_hcd_init+0x0/0xb8 returned 0 after 53 usecs > [ 2.722444] calling i8042_init+0x0/0x39e @ 1 > [ 2.722489] i8042: PNP: PS/2 Controller [PNP0303:PS2K] at 0x60,0x64 ir= q 1 > [ 2.722501] i8042: PNP: PS/2 appears to have AUX port disabled, if thi= s is incorrect please boot with i8042.nopnp > [ 2.722689] serio: i8042 KBD port at 0x60,0x64 irq 1 > [ 2.722734] initcall i8042_init+0x0/0x39e returned 0 after 274 usecs > [ 2.722747] calling mousedev_init+0x0/0x7f @ 1 > [ 2.722799] mousedev: PS/2 mouse device common for all mice > [ 2.722811] initcall mousedev_init+0x0/0x7f returned 0 after 52 usecs > [ 2.722823] calling evdev_init+0x0/0xf @ 1 > [ 2.722863] initcall evdev_init+0x0/0xf returned 0 after 30 usecs > [ 2.722875] calling atkbd_init+0x0/0x20 @ 1 > [ 2.722899] initcall atkbd_init+0x0/0x20 returned 0 after 13 usecs > [ 2.722911] calling uinput_init+0x0/0xf @ 1 > [ 2.722952] initcall uinput_init+0x0/0xf returned 0 after 30 usecs > [ 2.722965] calling cmos_init+0x0/0x5e @ 1 > [ 2.723000] rtc_cmos 00:02: RTC can wake from S4 > [ 2.723148] rtc_cmos 00:02: rtc core: registered rtc_cmos as rtc0 > [ 2.723201] rtc0: alarms up to one year, y3k, 114 bytes nvram > [ 2.723223] initcall cmos_init+0x0/0x5e returned 0 after 243 usecs > [ 2.723235] calling dm_init+0x0/0x3f @ 1 > [ 2.723289] device-mapper: uevent: version 1.0.3 > [ 2.723348] device-mapper: ioctl: 4.20.0-ioctl (2011-02-02) initialise= d: dm-devel@redhat.com > [ 2.723364] initcall dm_init+0x0/0x3f returned 0 after 117 usecs > [ 2.723376] calling dm_multipath_init+0x0/0x133 @ 1 > [ 2.723518] device-mapper: multipath: version 1.3.0 loaded > [ 2.723531] initcall dm_multipath_init+0x0/0x133 returned 0 after 140 = usecs > [ 2.723543] calling dm_rr_init+0x0/0x3a @ 1 > [ 2.723553] device-mapper: multipath round-robin: version 1.0.0 loaded > [ 2.723565] initcall dm_rr_init+0x0/0x3a returned 0 after 11 usecs > [ 2.723577] calling dm_snapshot_init+0x0/0x1fd @ 1 > [ 2.723605] initcall dm_snapshot_init+0x0/0x1fd returned 0 after 16 us= ecs > [ 2.723617] calling dm_mirror_init+0x0/0x77 @ 1 > [ 2.723654] initcall dm_mirror_init+0x0/0x77 returned 0 after 25 usecs > [ 2.723666] calling dm_dirty_log_init+0x0/0x4d @ 1 > [ 2.723677] initcall dm_dirty_log_init+0x0/0x4d returned 0 after 0 use= cs > [ 2.723689] calling pci_eisa_init_module+0x0/0x16 @ 1 > [ 2.723710] initcall pci_eisa_init_module+0x0/0x16 returned 0 after 9 = usecs > [ 2.723722] calling virtual_eisa_root_init+0x0/0x4d @ 1 > [ 2.723744] EISA: Probing bus 0 at eisa.0 > [ 2.723752] EISA: Cannot allocate resource for mainboard > [ 2.723762] Cannot allocate resource for EISA slot 1 > [ 2.723771] Cannot allocate resource for EISA slot 2 > [ 2.723781] Cannot allocate resource for EISA slot 3 > [ 2.723790] Cannot allocate resource for EISA slot 4 > [ 2.723800] Cannot allocate resource for EISA slot 5 > [ 2.723809] Cannot allocate resource for EISA slot 6 > [ 2.723819] Cannot allocate resource for EISA slot 7 > [ 2.723828] Cannot allocate resource for EISA slot 8 > [ 2.723837] EISA: Detected 0 cards. > [ 2.723846] initcall virtual_eisa_root_init+0x0/0x4d returned 0 after = 110 usecs > [ 2.723860] calling cpufreq_stats_init+0x0/0x84 @ 1 > [ 2.723873] initcall cpufreq_stats_init+0x0/0x84 returned 0 after 2 us= ecs > [ 2.723885] calling cpufreq_gov_powersave_init+0x0/0xf @ 1 > [ 2.723896] initcall cpufreq_gov_powersave_init+0x0/0xf returned 0 aft= er 0 usecs > [ 2.723910] calling cpufreq_gov_userspace_init+0x0/0xf @ 1 > [ 2.723921] initcall cpufreq_gov_userspace_init+0x0/0xf returned 0 aft= er 0 usecs > [ 2.723934] calling cpufreq_gov_dbs_init+0x0/0x5b @ 1 > [ 2.723946] initcall cpufreq_gov_dbs_init+0x0/0x5b returned 0 after 0 = usecs > [ 2.723958] calling cpufreq_gov_dbs_init+0x0/0xf @ 1 > [ 2.723969] initcall cpufreq_gov_dbs_init+0x0/0xf returned 0 after 0 u= secs > [ 2.723981] calling powernow_k6_init+0x0/0xb1 @ 1 > [ 2.723991] initcall powernow_k6_init+0x0/0xb1 returned -19 after 0 us= ecs > [ 2.724003] calling longrun_init+0x0/0x2e @ 1 > [ 2.724014] initcall longrun_init+0x0/0x2e returned -19 after 0 usecs > [ 2.724026] calling cpufreq_gx_init+0x0/0x10a @ 1 > [ 2.724036] initcall cpufreq_gx_init+0x0/0x10a returned -19 after 0 us= ecs > [ 2.724048] calling speedstep_init+0x0/0x1a8 @ 1 > [ 2.724064] initcall speedstep_init+0x0/0x1a8 returned -19 after 0 use= cs > [ 2.724076] calling speedstep_init+0x0/0xb0 @ 1 > [ 2.724087] initcall speedstep_init+0x0/0xb0 returned -19 after 0 usecs > [ 2.724100] calling nforce2_init+0x0/0x6f @ 1 > [ 2.724111] cpufreq-nforce2: No nForce2 chipset. > [ 2.724122] initcall nforce2_init+0x0/0x6f returned -19 after 11 usecs > [ 2.724133] calling init_ladder+0x0/0xf @ 1 > [ 2.724143] cpuidle: using governor ladder > [ 2.724152] initcall init_ladder+0x0/0xf returned 0 after 8 usecs > [ 2.724163] calling init_menu+0x0/0xf @ 1 > [ 2.724171] cpuidle: using governor menu > [ 2.724180] initcall init_menu+0x0/0xf returned 0 after 7 usecs > [ 2.724192] calling efivars_init+0x0/0xda @ 1 > [ 2.724201] EFI Variables Facility v0.08 2004-May-17 > [ 2.724212] initcall efivars_init+0x0/0xda returned 0 after 9 usecs > [ 2.724223] calling flow_cache_init_global+0x0/0x10d @ 1 > [ 2.724245] initcall flow_cache_init_global+0x0/0x10d returned 0 after= 10 usecs > [ 2.724258] calling llc_init+0x0/0x1b @ 1 > [ 2.724267] initcall llc_init+0x0/0x1b returned 0 after 0 usecs > [ 2.724278] calling snap_init+0x0/0x35 @ 1 > [ 2.724287] initcall snap_init+0x0/0x35 returned 0 after 1 usecs > [ 2.724299] calling rif_init+0x0/0x70 @ 1 > [ 2.724320] initcall rif_init+0x0/0x70 returned 0 after 13 usecs > [ 2.724332] calling blackhole_module_init+0x0/0xf @ 1 > [ 2.724343] initcall blackhole_module_init+0x0/0xf returned 0 after 0 = usecs > [ 2.724355] calling init_cgroup_cls+0x0/0x33 @ 1 > [ 2.724366] initcall init_cgroup_cls+0x0/0x33 returned 0 after 0 usecs > [ 2.724378] calling sysctl_ipv4_init+0x0/0x71 @ 1 > [ 2.724542] initcall sysctl_ipv4_init+0x0/0x71 returned 0 after 150 us= ecs > [ 2.724554] calling init_syncookies+0x0/0x16 @ 1 > [ 2.724586] initcall init_syncookies+0x0/0x16 returned 0 after 21 usecs > [ 2.724599] calling ipv4_netfilter_init+0x0/0x20 @ 1 > [ 2.724610] initcall ipv4_netfilter_init+0x0/0x20 returned 0 after 0 u= secs > [ 2.724621] calling inet_diag_init+0x0/0x79 @ 1 > [ 2.724644] initcall inet_diag_init+0x0/0x79 returned 0 after 11 usecs > [ 2.724656] calling tcp_diag_init+0x0/0xf @ 1 > [ 2.724667] initcall tcp_diag_init+0x0/0xf returned 0 after 0 usecs > [ 2.724678] calling cubictcp_register+0x0/0x82 @ 1 > [ 2.724689] TCP cubic registered > [ 2.724697] initcall cubictcp_register+0x0/0x82 returned 0 after 8 use= cs > [ 2.724709] calling inet6_init+0x0/0x287 @ 1 > [ 2.724810] NET: Registered protocol family 10 > [ 2.725283] initcall inet6_init+0x0/0x287 returned 0 after 550 usecs > [ 2.725297] calling packet_init+0x0/0x39 @ 1 > [ 2.725309] NET: Registered protocol family 17 > [ 2.725322] initcall packet_init+0x0/0x39 returned 0 after 12 usecs > [ 2.725334] calling br_init+0x0/0xa0 @ 1 > [ 2.725369] Bridge firewalling registered > [ 2.725379] initcall br_init+0x0/0xa0 returned 0 after 35 usecs > [ 2.725391] calling vlan_proto_init+0x0/0x88 @ 1 > [ 2.725400] 802.1Q VLAN Support v1.8 > [ 2.725413] initcall vlan_proto_init+0x0/0x88 returned 0 after 12 usecs > [ 2.725425] calling sctp_init+0x0/0x701 @ 1 > [ 2.725872] sctp: Hash tables configured (established 65536 bind 65536) > [ 2.726063] initcall sctp_init+0x0/0x701 returned 0 after 609 usecs > [ 2.726077] calling mcheck_debugfs_init+0x0/0x3e @ 1 > [ 2.726098] initcall mcheck_debugfs_init+0x0/0x3e returned 0 after 10 = usecs > [ 2.726111] calling severities_debugfs_init+0x0/0x3e @ 1 > [ 2.726123] initcall severities_debugfs_init+0x0/0x3e returned 0 after= 1 usecs > [ 2.726137] calling hpet_insert_resource+0x0/0x1e @ 1 > [ 2.726150] initcall hpet_insert_resource+0x0/0x1e returned 0 after 1 = usecs > [ 2.726162] calling update_mp_table+0x0/0x543 @ 1 > [ 2.726173] initcall update_mp_table+0x0/0x543 returned 0 after 0 usecs > [ 2.726186] calling lapic_insert_resource+0x0/0x46 @ 1 > [ 2.726197] initcall lapic_insert_resource+0x0/0x46 returned 0 after 0= usecs > [ 2.726210] calling io_apic_bug_finalize+0x0/0x1a @ 1 > [ 2.726221] initcall io_apic_bug_finalize+0x0/0x1a returned 0 after 0 = usecs > [ 2.726233] calling print_ipi_mode+0x0/0x2e @ 1 > [ 2.726243] Using IPI No-Shortcut mode > [ 2.726251] initcall print_ipi_mode+0x0/0x2e returned 0 after 7 usecs > [ 2.726264] calling check_early_ioremap_leak+0x0/0x69 @ 1 > [ 2.726275] initcall check_early_ioremap_leak+0x0/0x69 returned 0 afte= r 0 usecs > [ 2.726288] calling pat_memtype_list_init+0x0/0x37 @ 1 > [ 2.726302] initcall pat_memtype_list_init+0x0/0x37 returned 0 after 2= usecs > [ 2.726315] calling sched_init_debug+0x0/0x2a @ 1 > [ 2.726328] initcall sched_init_debug+0x0/0x2a returned 0 after 2 usecs > [ 2.726341] calling init_oops_id+0x0/0x50 @ 1 > [ 2.726354] initcall init_oops_id+0x0/0x50 returned 0 after 2 usecs > [ 2.726366] calling printk_late_init+0x0/0x4d @ 1 > [ 2.726379] initcall printk_late_init+0x0/0x4d returned 0 after 1 usecs > [ 2.726391] calling pm_qos_power_init+0x0/0x65 @ 1 > [ 2.726476] initcall pm_qos_power_init+0x0/0x65 returned 0 after 72 us= ecs > [ 2.726489] calling test_suspend+0x0/0x19a @ 1 > [ 2.726501] initcall test_suspend+0x0/0x19a returned 0 after 0 usecs > [ 2.726517] calling software_resume+0x0/0x1f0 @ 1 > [ 2.726528] PM: Hibernation image not present or could not be loaded. > [ 2.726540] initcall software_resume+0x0/0x1f0 returned -2 after 11 us= ecs > [ 2.726553] initcall software_resume+0x0/0x1f0 returned with error cod= e -2=20 > [ 2.726565] calling taskstats_init+0x0/0x85 @ 1 > [ 2.726579] registered taskstats version 1 > [ 2.726588] initcall taskstats_init+0x0/0x85 returned 0 after 12 usecs > [ 2.726600] calling clear_boot_tracer+0x0/0x2d @ 1 > [ 2.726611] initcall clear_boot_tracer+0x0/0x2d returned 0 after 0 use= cs > [ 2.726623] calling kdb_ftrace_register+0x0/0x35 @ 1 > [ 2.726636] initcall kdb_ftrace_register+0x0/0x35 returned 0 after 2 u= secs > [ 2.726649] calling max_swapfiles_check+0x0/0x7 @ 1 > [ 2.726660] initcall max_swapfiles_check+0x0/0x7 returned 0 after 0 us= ecs > [ 2.726672] calling random32_reseed+0x0/0x83 @ 1 > [ 2.726690] initcall random32_reseed+0x0/0x83 returned 0 after 8 usecs > [ 2.726702] calling pci_resource_alignment_sysfs_init+0x0/0x14 @ 1 > [ 2.726717] initcall pci_resource_alignment_sysfs_init+0x0/0x14 return= ed 0 after 2 usecs > [ 2.726730] calling pci_sysfs_init+0x0/0x44 @ 1 > [ 2.727049] initcall pci_sysfs_init+0x0/0x44 returned 0 after 301 usecs > [ 2.727063] calling boot_wait_for_devices+0x0/0x2f @ 1 > [ 2.727076] initcall boot_wait_for_devices+0x0/0x2f returned 0 after 1= usecs > [ 2.727090] calling regulator_init_complete+0x0/0x14c @ 1 > [ 2.727101] initcall regulator_init_complete+0x0/0x14c returned 0 afte= r 0 usecs > [ 2.727115] calling random_int_secret_init+0x0/0x16 @ 1 > [ 2.727138] initcall random_int_secret_init+0x0/0x16 returned 0 after = 12 usecs > [ 2.727154] calling late_resume_init+0x0/0x1a0 @ 1 > [ 2.727164] Magic number: 11:261:587 > [ 2.727239] initcall late_resume_init+0x0/0x1a0 returned 0 after 73 us= ecs > [ 2.727253] calling scsi_complete_async_scans+0x0/0x120 @ 1 > [ 2.727266] initcall scsi_complete_async_scans+0x0/0x120 returned 0 af= ter 0 usecs > [ 2.727280] calling rtc_hctosys+0x0/0x110 @ 1 > [ 2.727372] rtc_cmos 00:02: setting system clock to 2011-09-23 14:34:2= 7 UTC (1316788467) > [ 2.727387] initcall rtc_hctosys+0x0/0x110 returned 0 after 94 usecs > [ 2.727401] calling powernowk8_init+0x0/0x179 @ 1 > [ 2.727421] powernow-k8: Found 1 AMD Athlon(tm) II X2 250 Processor (2= cpu cores) (version 2.20.00) > [ 2.727442] [Firmware Bug]: powernow-k8: No compatible ACPI _PSS objec= ts found. > [ 2.727443] [Firmware Bug]: powernow-k8: Try again with latest BIOS. > [ 2.727467] initcall powernowk8_init+0x0/0x179 returned -19 after 54 u= secs > [ 2.727479] calling acpi_cpufreq_init+0x0/0x8f @ 1 > [ 2.727512] initcall acpi_cpufreq_init+0x0/0x8f returned -5 after 21 u= secs > [ 2.727525] initcall acpi_cpufreq_init+0x0/0x8f returned with error co= de -5=20 > [ 2.727539] calling powernow_init+0x0/0x114 @ 1 > [ 2.727550] initcall powernow_init+0x0/0x114 returned -19 after 0 usecs > [ 2.727562] calling longhaul_init+0x0/0x95 @ 1 > [ 2.727573] initcall longhaul_init+0x0/0x95 returned -19 after 0 usecs > [ 2.727585] calling centrino_init+0x0/0x26 @ 1 > [ 2.727596] initcall centrino_init+0x0/0x26 returned -19 after 0 usecs > [ 2.727609] calling edd_init+0x0/0x312 @ 1 > [ 2.727617] BIOS EDD facility v0.16 2004-Jun-25, 0 devices found > [ 2.727628] EDD information not available. > [ 2.727637] initcall edd_init+0x0/0x312 returned -19 after 18 usecs > [ 2.727649] calling memmap_init+0x0/0x29 @ 1 > [ 2.727681] initcall memmap_init+0x0/0x29 returned 0 after 19 usecs > [ 2.727693] calling pci_mmcfg_late_insert_resources+0x0/0x53 @ 1 > [ 2.727707] initcall pci_mmcfg_late_insert_resources+0x0/0x53 returned= 0 after 0 usecs > [ 2.727721] calling net_secret_init+0x0/0x16 @ 1 > [ 2.727743] initcall net_secret_init+0x0/0x16 returned 0 after 11 usecs > [ 2.727755] calling tcp_congestion_default+0x0/0xf @ 1 > [ 2.727767] initcall tcp_congestion_default+0x0/0xf returned 0 after 1= usecs > [ 2.727781] calling initialize_hashrnd+0x0/0x16 @ 1 > [ 2.727794] initcall initialize_hashrnd+0x0/0x16 returned 0 after 2 us= ecs > [ 2.727939] async_waiting @ 1 > [ 2.727949] async_continuing @ 1 after 0 usec > [ 2.728211] Freeing unused kernel memory: 676k freed > [ 2.729609] Write protecting the kernel text: 5080k > [ 2.730085] Write protecting the kernel read-only data: 1936k > [ 2.730097] NX-protecting the kernel data: 3112k > /init: Mounting /proc... > /init: Mounting /sys... > /init: Mounting /workspace > [ 2.742100] input: AT Translated Set 2 keyboard as /devices/platform/i= 8042/serio0/input/input2 > /init: Mounting /dev... > /init: Notifying init of /dev creation... > /init: Starting syslogd... > /init: Starting klogd... > /init: Searching for boot volume on /dev/sda1 /dev/sdb1 > /init: Boot volume found on /dev/sdb1. > /init: Generating /sysconfig > /init: Mounting /boot/master/XenMaster-5.10/rootfs on /sysroot. > /init: Stopping initramfs processes... > /init: Remounting /workspace > /init: Remounting /dev > /init: Remounting /sys > /init: Remounting /proc > /init: Remounting /sysconfig > /init: Remounting /boot > /init: Switching root to /sysroot > =0DINIT: version 2.86 booting > Setting the console log level to 7... > =1B[1A=1B[0G=1B[72G=1B[1;34m[=1B[1;32m OK =1B[1;34m]=1B[0;39m > Restarting system log daemon... > =1B[1A=1B[0G=1B[72G=1B[1;34m[=1B[1;32m OK =1B[1;34m]=1B[0;39m > Restarting kernel log daemon... > =1B[1A=1B[0G=1B[72G=1B[1;34m[=1B[1;32m OK =1B[1;34m]=1B[0;39m > Starting udevd... > =1B[1A=1B[0G=1B[72G=1B[1;34m[=1B[1;32m OK =1B[1;34m]=1B[0;39m > Mounting /dev/pts... > =1B[1A=1B[0G=1B[72G=1B[1;34m[=1B[1;32m OK =1B[1;34m]=1B[0;39m > Creating /workspace/persist... > =1B[1A=1B[0G=1B[72G=1B[1;34m[=1B[1;32m OK =1B[1;34m]=1B[0;39m > Setting system clock... > =1B[1A=1B[0G=1B[72G=1B[1;34m[=1B[1;32m OK =1B[1;34m]=1B[0;39m > Setting up Linux console... > =1B[1A=1B[0G=1B[72G=1B[1;34m[=1B[1;32m OK =1B[1;34m]=1B[0;39m > Bringing up the loopback interface... > =1B[1A=1B[0G=1B[72G=1B[1;34m[=1B[1;32m OK =1B[1;34m]=1B[0;39m > Setting hostname to Setup... > =1B[1A=1B[0G=1B[72G=1B[1;34m[=1B[1;32m OK =1B[1;34m]=1B[0;39m > Starting xenstored... > Setting domain 0 name... > Starting xenconsoled... > Installing EBTables rules... > =1B[1A=1B[0G=1B[72G=1B[1;34m[=1B[1;32m OK =1B[1;34m]=1B[0;39m > Installing IPTables rules... > =1B[1A=1B[0G=1B[72G=1B[1;34m[=1B[1;32m OK =1B[1;34m]=1B[0;39m > =0DINIT: Entering runlevel: 3 > Starting ntpd... > =1B[1A=1B[0G=1B[72G=1B[1;34m[=1B[1;32m OK =1B[1;34m]=1B[0;39m > Starting management agent... > =1B[1A=1B[0G=1B[72G=1B[1;34m[=1B[1;32m OK =1B[1;34m]=1B[0;39m _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel From xen-devel-bounces@lists.xensource.com Mon Sep 26 07:15:59 2011 Return-path: <xen-devel-bounces@lists.xensource.com> Envelope-to: www-data@lists.xensource.com Delivery-date: Mon, 26 Sep 2011 07:15:59 -0700 Received: from localhost ([127.0.0.1] helo=lists.colo.xensource.com) by lists.xensource.com with esmtp (Exim 4.43) id 1R8ByR-0001t2-BN; Mon, 26 Sep 2011 07:15:59 -0700 Received: from mail21.messagelabs.com ([85.158.143.35]) by lists.xensource.com with esmtp (Exim 4.43) id 1R8BwD-0000wn-Sg for xen-devel@lists.xensource.com; Mon, 26 Sep 2011 07:13:42 -0700 X-Env-Sender: konrad@oracle.com X-Msg-Ref: server-8.tower-21.messagelabs.com!1317046400!60408550!1 X-Originating-IP: [148.87.113.117] X-StarScan-Version: 6.4.1; banners=-,-,- X-VirusChecked: Checked Received: (qmail 29622 invoked from network); 26 Sep 2011 14:13:22 -0000 Received: from rcsinet15.oracle.com (HELO rcsinet15.oracle.com) (148.87.113.117) by server-8.tower-21.messagelabs.com with DHE-RSA-AES256-SHA encrypted SMTP; 26 Sep 2011 14:13:22 -0000 Received: from acsinet21.oracle.com (acsinet21.oracle.com [141.146.126.237]) by rcsinet15.oracle.com (Switch-3.4.4/Switch-3.4.4) with ESMTP id p8QEDY5A023011 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Mon, 26 Sep 2011 14:13:36 GMT Received: from acsmt357.oracle.com (acsmt357.oracle.com [141.146.40.157]) by acsinet21.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id p8QEDYk3007355 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 26 Sep 2011 14:13:34 GMT Received: from abhmt118.oracle.com (abhmt118.oracle.com [141.146.116.70]) by acsmt357.oracle.com (8.12.11.20060308/8.12.11) with ESMTP id p8QEDSFG029164; Mon, 26 Sep 2011 09:13:28 -0500 Received: from oracle.com (/209.6.55.207) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Mon, 26 Sep 2011 07:13:28 -0700 Received: by oracle.com (Postfix, from userid 1000) id 48B051551; Mon, 26 Sep 2011 10:13:22 -0400 (EDT) Date: Mon, 26 Sep 2011 10:13:22 -0400 From: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com> To: Anthony Wright <anthony@overnetdata.com> Subject: Re: [Xen-devel] dmidecode doesn't work under xen 4.1.1 on certain hardware Message-ID: <20110926141322.GD4102@phenom.oracle.com> References: <4E7C6BDC.8070005@overnetdata.com> <20110923133200.GC19579@phenom.oracle.com> <4E7C9C8B.2010108@overnetdata.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <4E7C9C8B.2010108@overnetdata.com> User-Agent: Mutt/1.5.21 (2010-09-15) X-Source-IP: acsinet21.oracle.com [141.146.126.237] X-Auth-Type: Internal IP X-CT-RefId: str=0001.0A090206.4E808890.0106:SCFMA922111,ss=1,re=-4.000,fgs=0 Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com> X-BeenThere: xen-devel@lists.xensource.com X-Mailman-Version: 2.1.5 Precedence: list List-Id: Xen developer discussion <xen-devel.lists.xensource.com> List-Unsubscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe> List-Post: <mailto:xen-devel@lists.xensource.com> List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help> List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=subscribe> Sender: xen-devel-bounces@lists.xensource.com Errors-To: xen-devel-bounces@lists.xensource.com On Fri, Sep 23, 2011 at 03:49:47PM +0100, Anthony Wright wrote: > On 23/09/2011 14:32, Konrad Rzeszutek Wilk wrote: > > On Fri, Sep 23, 2011 at 12:22:04PM +0100, Anthony Wright wrote: > >> I have a xen 4.1.1 with a 3.0.4 linux kernel running on a Supermicro > >> Supermicro X8DTL-iF motherboard with 16GB of RAM. > >> > >> If I run the 3.0.4 kernel on the bare metal dmidecode works fine. If I > > Can you attach the beginning of the kernel bootup log? It should > > have some entry about 1-1 mappings. Make sure to run Linux with "debug loglevel=8" > Please find attached. > 2011 Sep 23 14:45:41 kernel: [ 0.000000] 1-1 mapping on 9a->100 > 2011 Sep 23 14:45:41 kernel: [ 0.000000] 1-1 mapping on bf780->100000 > 2011 Sep 23 14:45:41 kernel: [ 0.000000] Set 264422 page(s) to 1-1 mapping. > 2011 Sep 23 14:45:41 kernel: [ 0.000000] BIOS-provided physical RAM map: > 2011 Sep 23 14:45:41 kernel: [ 0.000000] Xen: 0000000000000000 - 0000000000099000 (usable) > 2011 Sep 23 14:45:41 kernel: [ 0.000000] Xen: 0000000000099800 - 0000000000100000 (reserved) .. snip.. So 99C00 is right at cusp of 'usuable' and 'reserved'. Meaning that region falls within the 4KB page. And we did not set the 1-1 mapping for 99 (we started at 9A). But now that I think of it - this is Linux E820 which does get modified. Can you also provide the hypervisor E820 output? You can get 'xl dmesg' for that. That should provide the "virgin" output of the e820 which we use for 1-1 mapping. _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel From xen-devel-bounces@lists.xensource.com Mon Sep 26 07:21:33 2011 Return-path: <xen-devel-bounces@lists.xensource.com> Envelope-to: www-data@lists.xensource.com Delivery-date: Mon, 26 Sep 2011 07:21:33 -0700 Received: from localhost ([127.0.0.1] helo=lists.colo.xensource.com) by lists.xensource.com with esmtp (Exim 4.43) id 1R8C3p-0002Ld-Bo; Mon, 26 Sep 2011 07:21:33 -0700 Received: from mail216.messagelabs.com ([85.158.143.99]) by lists.xensource.com with esmtp (Exim 4.43) id 1R8C2t-00028u-4N for xen-devel@lists.xensource.com; Mon, 26 Sep 2011 07:20:39 -0700 X-Env-Sender: konrad@oracle.com X-Msg-Ref: server-15.tower-216.messagelabs.com!1317046819!19115763!1 X-Originating-IP: [148.87.113.117] X-StarScan-Version: 6.4.1; banners=-,-,- X-VirusChecked: Checked Received: (qmail 9051 invoked from network); 26 Sep 2011 14:20:22 -0000 Received: from rcsinet15.oracle.com (HELO rcsinet15.oracle.com) (148.87.113.117) by server-15.tower-216.messagelabs.com with DHE-RSA-AES256-SHA encrypted SMTP; 26 Sep 2011 14:20:22 -0000 Received: from ucsinet24.oracle.com (ucsinet24.oracle.com [156.151.31.67]) by rcsinet15.oracle.com (Switch-3.4.4/Switch-3.4.4) with ESMTP id p8QEKFnO032748 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Mon, 26 Sep 2011 14:20:17 GMT Received: from acsmt357.oracle.com (acsmt357.oracle.com [141.146.40.157]) by ucsinet24.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id p8QEEbXa013565 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 26 Sep 2011 14:14:38 GMT Received: from abhmt119.oracle.com (abhmt119.oracle.com [141.146.116.71]) by acsmt357.oracle.com (8.12.11.20060308/8.12.11) with ESMTP id p8QEK80D002987; Mon, 26 Sep 2011 09:20:09 -0500 Received: from oracle.com (/209.6.55.207) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Mon, 26 Sep 2011 07:20:08 -0700 Received: by oracle.com (Postfix, from userid 1000) id 551521551; Mon, 26 Sep 2011 10:20:02 -0400 (EDT) Date: Mon, 26 Sep 2011 10:20:02 -0400 From: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com> To: David Vrabel <david.vrabel@citrix.com> Subject: Re: [Xen-devel] Re: xen: memory initialization/balloon fixes (#3) Message-ID: <20110926142002.GE4102@phenom.oracle.com> References: <1316089768-22461-1-git-send-email-david.vrabel@citrix.com> <20110924020759.GA27796@phenom.oracle.com> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="M9NhX3UHpAaciwkO" Content-Disposition: inline In-Reply-To: <20110924020759.GA27796@phenom.oracle.com> User-Agent: Mutt/1.5.21 (2010-09-15) X-Source-IP: ucsinet24.oracle.com [156.151.31.67] X-CT-RefId: str=0001.0A090207.4E808A21.012A,ss=1,re=-6.500,fgs=0 Cc: xen-devel@lists.xensource.com X-BeenThere: xen-devel@lists.xensource.com X-Mailman-Version: 2.1.5 Precedence: list List-Id: Xen developer discussion <xen-devel.lists.xensource.com> List-Unsubscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe> List-Post: <mailto:xen-devel@lists.xensource.com> List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help> List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=subscribe> Sender: xen-devel-bounces@lists.xensource.com Errors-To: xen-devel-bounces@lists.xensource.com --M9NhX3UHpAaciwkO Content-Type: text/plain; charset=us-ascii Content-Disposition: inline > They don't work on AMD boxes: > > mapping kernel into physical memory > Xen: setup ISA identity maps > about to get started... > > and then it is just stuck.. This is v3.1-rc7 + your patches This is a Dell T105 w/ 4GB of RAM. The config file is attached. earlyprintk=xen shows nothing, .. interestingly enough Ctrl-A works - it is just that I can't see anything from the Linux kernel. It probably is stuck in a loop... --M9NhX3UHpAaciwkO Content-Type: text/plain; charset=us-ascii Content-Disposition: attachment; filename=".config" # # Automatically generated file; DO NOT EDIT. # Linux/x86_64 3.1.0-rc7 Kernel Configuration # CONFIG_64BIT=y # CONFIG_X86_32 is not set CONFIG_X86_64=y CONFIG_X86=y CONFIG_INSTRUCTION_DECODER=y CONFIG_OUTPUT_FORMAT="elf64-x86-64" CONFIG_ARCH_DEFCONFIG="arch/x86/configs/x86_64_defconfig" CONFIG_GENERIC_CMOS_UPDATE=y CONFIG_CLOCKSOURCE_WATCHDOG=y CONFIG_GENERIC_CLOCKEVENTS=y CONFIG_ARCH_CLOCKSOURCE_DATA=y CONFIG_GENERIC_CLOCKEVENTS_BROADCAST=y CONFIG_LOCKDEP_SUPPORT=y CONFIG_STACKTRACE_SUPPORT=y CONFIG_HAVE_LATENCYTOP_SUPPORT=y CONFIG_MMU=y CONFIG_ZONE_DMA=y CONFIG_NEED_DMA_MAP_STATE=y CONFIG_NEED_SG_DMA_LENGTH=y CONFIG_GENERIC_ISA_DMA=y CONFIG_GENERIC_IOMAP=y CONFIG_GENERIC_BUG=y CONFIG_GENERIC_BUG_RELATIVE_POINTERS=y CONFIG_GENERIC_HWEIGHT=y CONFIG_ARCH_MAY_HAVE_PC_FDC=y # CONFIG_RWSEM_GENERIC_SPINLOCK is not set CONFIG_RWSEM_XCHGADD_ALGORITHM=y CONFIG_ARCH_HAS_CPU_IDLE_WAIT=y CONFIG_GENERIC_CALIBRATE_DELAY=y CONFIG_GENERIC_TIME_VSYSCALL=y CONFIG_ARCH_HAS_CPU_RELAX=y CONFIG_ARCH_HAS_DEFAULT_IDLE=y CONFIG_ARCH_HAS_CACHE_LINE_SIZE=y CONFIG_HAVE_SETUP_PER_CPU_AREA=y CONFIG_NEED_PER_CPU_EMBED_FIRST_CHUNK=y CONFIG_NEED_PER_CPU_PAGE_FIRST_CHUNK=y CONFIG_HAVE_CPUMASK_OF_CPU_MAP=y CONFIG_ARCH_HIBERNATION_POSSIBLE=y CONFIG_ARCH_SUSPEND_POSSIBLE=y CONFIG_ZONE_DMA32=y CONFIG_ARCH_POPULATES_NODE_MAP=y CONFIG_AUDIT_ARCH=y CONFIG_ARCH_SUPPORTS_OPTIMIZED_INLINING=y CONFIG_ARCH_SUPPORTS_DEBUG_PAGEALLOC=y CONFIG_HAVE_INTEL_TXT=y CONFIG_X86_64_SMP=y CONFIG_X86_HT=y CONFIG_ARCH_HWEIGHT_CFLAGS="-fcall-saved-rdi -fcall-saved-rsi -fcall-saved-rdx -fcall-saved-rcx -fcall-saved-r8 -fcall-saved-r9 -fcall-saved-r10 -fcall-saved-r11" # CONFIG_KTIME_SCALAR is not set CONFIG_ARCH_CPU_PROBE_RELEASE=y CONFIG_DEFCONFIG_LIST="/lib/modules/$UNAME_RELEASE/.config" CONFIG_HAVE_IRQ_WORK=y CONFIG_IRQ_WORK=y # # General setup # CONFIG_EXPERIMENTAL=y CONFIG_INIT_ENV_ARG_LIMIT=32 CONFIG_CROSS_COMPILE="" CONFIG_LOCALVERSION="" CONFIG_LOCALVERSION_AUTO=y CONFIG_HAVE_KERNEL_GZIP=y CONFIG_HAVE_KERNEL_BZIP2=y CONFIG_HAVE_KERNEL_LZMA=y CONFIG_HAVE_KERNEL_XZ=y CONFIG_HAVE_KERNEL_LZO=y CONFIG_KERNEL_GZIP=y # CONFIG_KERNEL_BZIP2 is not set # CONFIG_KERNEL_LZMA is not set # CONFIG_KERNEL_XZ is not set # CONFIG_KERNEL_LZO is not set CONFIG_DEFAULT_HOSTNAME="(none)" CONFIG_SWAP=y CONFIG_SYSVIPC=y CONFIG_SYSVIPC_SYSCTL=y CONFIG_POSIX_MQUEUE=y CONFIG_POSIX_MQUEUE_SYSCTL=y CONFIG_BSD_PROCESS_ACCT=y CONFIG_BSD_PROCESS_ACCT_V3=y # CONFIG_FHANDLE is not set CONFIG_TASKSTATS=y CONFIG_TASK_DELAY_ACCT=y CONFIG_TASK_XACCT=y CONFIG_TASK_IO_ACCOUNTING=y CONFIG_AUDIT=y CONFIG_AUDITSYSCALL=y CONFIG_AUDIT_WATCH=y CONFIG_AUDIT_TREE=y CONFIG_HAVE_GENERIC_HARDIRQS=y # # IRQ subsystem # CONFIG_GENERIC_HARDIRQS=y CONFIG_HAVE_SPARSE_IRQ=y CONFIG_GENERIC_IRQ_PROBE=y CONFIG_GENERIC_IRQ_SHOW=y CONFIG_GENERIC_PENDING_IRQ=y CONFIG_IRQ_FORCED_THREADING=y CONFIG_SPARSE_IRQ=y # # RCU Subsystem # CONFIG_TREE_PREEMPT_RCU=y CONFIG_PREEMPT_RCU=y # CONFIG_RCU_TRACE is not set CONFIG_RCU_FANOUT=64 # CONFIG_RCU_FANOUT_EXACT is not set # CONFIG_TREE_RCU_TRACE is not set # CONFIG_RCU_BOOST is not set # CONFIG_IKCONFIG is not set CONFIG_LOG_BUF_SHIFT=18 CONFIG_HAVE_UNSTABLE_SCHED_CLOCK=y CONFIG_CGROUPS=y # CONFIG_CGROUP_DEBUG is not set CONFIG_CGROUP_FREEZER=y # CONFIG_CGROUP_DEVICE is not set CONFIG_CPUSETS=y CONFIG_PROC_PID_CPUSET=y CONFIG_CGROUP_CPUACCT=y CONFIG_RESOURCE_COUNTERS=y # CONFIG_CGROUP_MEM_RES_CTLR is not set # CONFIG_CGROUP_PERF is not set CONFIG_CGROUP_SCHED=y CONFIG_FAIR_GROUP_SCHED=y # CONFIG_RT_GROUP_SCHED is not set # CONFIG_BLK_CGROUP is not set CONFIG_NAMESPACES=y CONFIG_UTS_NS=y CONFIG_IPC_NS=y CONFIG_USER_NS=y CONFIG_PID_NS=y CONFIG_NET_NS=y # CONFIG_SCHED_AUTOGROUP is not set CONFIG_SYSFS_DEPRECATED=y # CONFIG_SYSFS_DEPRECATED_V2 is not set CONFIG_RELAY=y CONFIG_BLK_DEV_INITRD=y CONFIG_INITRAMFS_SOURCE="early-devs" CONFIG_INITRAMFS_ROOT_UID=0 CONFIG_INITRAMFS_ROOT_GID=0 CONFIG_RD_GZIP=y CONFIG_RD_BZIP2=y CONFIG_RD_LZMA=y CONFIG_RD_XZ=y CONFIG_RD_LZO=y # CONFIG_INITRAMFS_COMPRESSION_NONE is not set CONFIG_INITRAMFS_COMPRESSION_GZIP=y # CONFIG_INITRAMFS_COMPRESSION_BZIP2 is not set # CONFIG_INITRAMFS_COMPRESSION_LZMA is not set # CONFIG_INITRAMFS_COMPRESSION_XZ is not set # CONFIG_INITRAMFS_COMPRESSION_LZO is not set # CONFIG_CC_OPTIMIZE_FOR_SIZE is not set CONFIG_SYSCTL=y CONFIG_ANON_INODES=y # CONFIG_EXPERT is not set CONFIG_UID16=y CONFIG_SYSCTL_SYSCALL=y CONFIG_KALLSYMS=y # CONFIG_KALLSYMS_ALL is not set CONFIG_HOTPLUG=y CONFIG_PRINTK=y CONFIG_BUG=y CONFIG_ELF_CORE=y CONFIG_PCSPKR_PLATFORM=y CONFIG_HAVE_PCSPKR_PLATFORM=y CONFIG_BASE_FULL=y CONFIG_FUTEX=y CONFIG_EPOLL=y CONFIG_SIGNALFD=y CONFIG_TIMERFD=y CONFIG_EVENTFD=y CONFIG_SHMEM=y CONFIG_AIO=y # CONFIG_EMBEDDED is not set CONFIG_HAVE_PERF_EVENTS=y # # Kernel Performance Events And Counters # CONFIG_PERF_EVENTS=y # CONFIG_PERF_COUNTERS is not set # CONFIG_DEBUG_PERF_USE_VMALLOC is not set CONFIG_VM_EVENT_COUNTERS=y CONFIG_PCI_QUIRKS=y CONFIG_SLUB_DEBUG=y # CONFIG_COMPAT_BRK is not set # CONFIG_SLAB is not set CONFIG_SLUB=y CONFIG_PROFILING=y CONFIG_TRACEPOINTS=y # CONFIG_OPROFILE is not set CONFIG_HAVE_OPROFILE=y CONFIG_KPROBES=y # CONFIG_JUMP_LABEL is not set CONFIG_HAVE_EFFICIENT_UNALIGNED_ACCESS=y CONFIG_KRETPROBES=y CONFIG_USER_RETURN_NOTIFIER=y CONFIG_HAVE_IOREMAP_PROT=y CONFIG_HAVE_KPROBES=y CONFIG_HAVE_KRETPROBES=y CONFIG_HAVE_OPTPROBES=y CONFIG_HAVE_ARCH_TRACEHOOK=y CONFIG_HAVE_DMA_ATTRS=y CONFIG_USE_GENERIC_SMP_HELPERS=y CONFIG_HAVE_REGS_AND_STACK_ACCESS_API=y CONFIG_HAVE_DMA_API_DEBUG=y CONFIG_HAVE_HW_BREAKPOINT=y CONFIG_HAVE_MIXED_BREAKPOINTS_REGS=y CONFIG_HAVE_USER_RETURN_NOTIFIER=y CONFIG_HAVE_PERF_EVENTS_NMI=y CONFIG_HAVE_ARCH_JUMP_LABEL=y CONFIG_ARCH_HAVE_NMI_SAFE_CMPXCHG=y # # GCOV-based kernel profiling # # CONFIG_GCOV_KERNEL is not set # CONFIG_HAVE_GENERIC_DMA_COHERENT is not set CONFIG_SLABINFO=y CONFIG_RT_MUTEXES=y CONFIG_BASE_SMALL=0 CONFIG_MODULES=y # CONFIG_MODULE_FORCE_LOAD is not set CONFIG_MODULE_UNLOAD=y CONFIG_MODULE_FORCE_UNLOAD=y # CONFIG_MODVERSIONS is not set # CONFIG_MODULE_SRCVERSION_ALL is not set CONFIG_STOP_MACHINE=y CONFIG_BLOCK=y CONFIG_BLK_DEV_BSG=y # CONFIG_BLK_DEV_BSGLIB is not set # CONFIG_BLK_DEV_INTEGRITY is not set CONFIG_BLOCK_COMPAT=y # # IO Schedulers # CONFIG_IOSCHED_NOOP=y CONFIG_IOSCHED_DEADLINE=y CONFIG_IOSCHED_CFQ=y # CONFIG_DEFAULT_DEADLINE is not set CONFIG_DEFAULT_CFQ=y # CONFIG_DEFAULT_NOOP is not set CONFIG_DEFAULT_IOSCHED="cfq" CONFIG_PREEMPT_NOTIFIERS=y # CONFIG_INLINE_SPIN_TRYLOCK is not set # CONFIG_INLINE_SPIN_TRYLOCK_BH is not set # CONFIG_INLINE_SPIN_LOCK is not set # CONFIG_INLINE_SPIN_LOCK_BH is not set # CONFIG_INLINE_SPIN_LOCK_IRQ is not set # CONFIG_INLINE_SPIN_LOCK_IRQSAVE is not set # CONFIG_INLINE_SPIN_UNLOCK is not set # CONFIG_INLINE_SPIN_UNLOCK_BH is not set # CONFIG_INLINE_SPIN_UNLOCK_IRQ is not set # CONFIG_INLINE_SPIN_UNLOCK_IRQRESTORE is not set # CONFIG_INLINE_READ_TRYLOCK is not set # CONFIG_INLINE_READ_LOCK is not set # CONFIG_INLINE_READ_LOCK_BH is not set # CONFIG_INLINE_READ_LOCK_IRQ is not set # CONFIG_INLINE_READ_LOCK_IRQSAVE is not set # CONFIG_INLINE_READ_UNLOCK is not set # CONFIG_INLINE_READ_UNLOCK_BH is not set # CONFIG_INLINE_READ_UNLOCK_IRQ is not set # CONFIG_INLINE_READ_UNLOCK_IRQRESTORE is not set # CONFIG_INLINE_WRITE_TRYLOCK is not set # CONFIG_INLINE_WRITE_LOCK is not set # CONFIG_INLINE_WRITE_LOCK_BH is not set # CONFIG_INLINE_WRITE_LOCK_IRQ is not set # CONFIG_INLINE_WRITE_LOCK_IRQSAVE is not set # CONFIG_INLINE_WRITE_UNLOCK is not set # CONFIG_INLINE_WRITE_UNLOCK_BH is not set # CONFIG_INLINE_WRITE_UNLOCK_IRQ is not set # CONFIG_INLINE_WRITE_UNLOCK_IRQRESTORE is not set CONFIG_MUTEX_SPIN_ON_OWNER=y CONFIG_FREEZER=y # # Processor type and features # CONFIG_TICK_ONESHOT=y CONFIG_NO_HZ=y CONFIG_HIGH_RES_TIMERS=y CONFIG_GENERIC_CLOCKEVENTS_BUILD=y CONFIG_SMP=y CONFIG_X86_MPPARSE=y # CONFIG_X86_EXTENDED_PLATFORM is not set CONFIG_X86_SUPPORTS_MEMORY_FAILURE=y CONFIG_SCHED_OMIT_FRAME_POINTER=y CONFIG_PARAVIRT_GUEST=y # CONFIG_PARAVIRT_TIME_ACCOUNTING is not set CONFIG_XEN=y CONFIG_XEN_DOM0=y CONFIG_XEN_PRIVILEGED_GUEST=y CONFIG_XEN_PVHVM=y CONFIG_XEN_MAX_DOMAIN_MEMORY=128 CONFIG_XEN_SAVE_RESTORE=y CONFIG_XEN_DEBUG_FS=y CONFIG_XEN_DEBUG=y CONFIG_KVM_CLOCK=y CONFIG_KVM_GUEST=y CONFIG_PARAVIRT=y CONFIG_PARAVIRT_SPINLOCKS=y CONFIG_PARAVIRT_CLOCK=y CONFIG_PARAVIRT_DEBUG=y CONFIG_NO_BOOTMEM=y # CONFIG_MEMTEST is not set # CONFIG_MK8 is not set # CONFIG_MPSC is not set # CONFIG_MCORE2 is not set # CONFIG_MATOM is not set CONFIG_GENERIC_CPU=y CONFIG_X86_INTERNODE_CACHE_SHIFT=7 CONFIG_X86_CMPXCHG=y CONFIG_CMPXCHG_LOCAL=y CONFIG_CMPXCHG_DOUBLE=y CONFIG_X86_L1_CACHE_SHIFT=6 CONFIG_X86_XADD=y CONFIG_X86_WP_WORKS_OK=y CONFIG_X86_TSC=y CONFIG_X86_CMPXCHG64=y CONFIG_X86_CMOV=y CONFIG_X86_MINIMUM_CPU_FAMILY=64 CONFIG_X86_DEBUGCTLMSR=y CONFIG_CPU_SUP_INTEL=y CONFIG_CPU_SUP_AMD=y CONFIG_CPU_SUP_CENTAUR=y CONFIG_HPET_TIMER=y CONFIG_HPET_EMULATE_RTC=y CONFIG_DMI=y CONFIG_GART_IOMMU=y CONFIG_CALGARY_IOMMU=y CONFIG_CALGARY_IOMMU_ENABLED_BY_DEFAULT=y CONFIG_SWIOTLB=y CONFIG_IOMMU_HELPER=y CONFIG_MAXSMP=y CONFIG_NR_CPUS=4096 CONFIG_SCHED_SMT=y CONFIG_SCHED_MC=y CONFIG_IRQ_TIME_ACCOUNTING=y # CONFIG_PREEMPT_NONE is not set # CONFIG_PREEMPT_VOLUNTARY is not set CONFIG_PREEMPT=y CONFIG_PREEMPT_COUNT=y CONFIG_X86_LOCAL_APIC=y CONFIG_X86_IO_APIC=y CONFIG_X86_REROUTE_FOR_BROKEN_BOOT_IRQS=y CONFIG_X86_MCE=y CONFIG_X86_MCE_INTEL=y CONFIG_X86_MCE_AMD=y CONFIG_X86_MCE_THRESHOLD=y CONFIG_X86_MCE_INJECT=y CONFIG_X86_THERMAL_VECTOR=y # CONFIG_I8K is not set CONFIG_MICROCODE=y CONFIG_MICROCODE_INTEL=y CONFIG_MICROCODE_AMD=y CONFIG_MICROCODE_OLD_INTERFACE=y CONFIG_X86_MSR=y CONFIG_X86_CPUID=y CONFIG_ARCH_PHYS_ADDR_T_64BIT=y CONFIG_ARCH_DMA_ADDR_T_64BIT=y CONFIG_DIRECT_GBPAGES=y CONFIG_NUMA=y CONFIG_AMD_NUMA=y CONFIG_X86_64_ACPI_NUMA=y CONFIG_NODES_SPAN_OTHER_NODES=y # CONFIG_NUMA_EMU is not set CONFIG_NODES_SHIFT=10 CONFIG_ARCH_SPARSEMEM_ENABLE=y CONFIG_ARCH_SPARSEMEM_DEFAULT=y CONFIG_ARCH_SELECT_MEMORY_MODEL=y CONFIG_ARCH_PROC_KCORE_TEXT=y CONFIG_ILLEGAL_POINTER_VALUE=0xdead000000000000 CONFIG_SELECT_MEMORY_MODEL=y CONFIG_SPARSEMEM_MANUAL=y CONFIG_SPARSEMEM=y CONFIG_NEED_MULTIPLE_NODES=y CONFIG_HAVE_MEMORY_PRESENT=y CONFIG_SPARSEMEM_EXTREME=y CONFIG_SPARSEMEM_VMEMMAP_ENABLE=y CONFIG_SPARSEMEM_ALLOC_MEM_MAP_TOGETHER=y CONFIG_SPARSEMEM_VMEMMAP=y CONFIG_HAVE_MEMBLOCK=y # CONFIG_MEMORY_HOTPLUG is not set CONFIG_PAGEFLAGS_EXTENDED=y CONFIG_SPLIT_PTLOCK_CPUS=4 CONFIG_COMPACTION=y CONFIG_MIGRATION=y CONFIG_PHYS_ADDR_T_64BIT=y CONFIG_ZONE_DMA_FLAG=1 CONFIG_BOUNCE=y CONFIG_VIRT_TO_BUS=y CONFIG_MMU_NOTIFIER=y # CONFIG_KSM is not set CONFIG_DEFAULT_MMAP_MIN_ADDR=4096 CONFIG_ARCH_SUPPORTS_MEMORY_FAILURE=y # CONFIG_MEMORY_FAILURE is not set # CONFIG_TRANSPARENT_HUGEPAGE is not set CONFIG_CLEANCACHE=y CONFIG_X86_CHECK_BIOS_CORRUPTION=y CONFIG_X86_BOOTPARAM_MEMORY_CORRUPTION_CHECK=y CONFIG_X86_RESERVE_LOW=64 CONFIG_MTRR=y # CONFIG_MTRR_SANITIZER is not set CONFIG_X86_PAT=y CONFIG_ARCH_USES_PG_UNCACHED=y CONFIG_EFI=y CONFIG_SECCOMP=y CONFIG_CC_STACKPROTECTOR=y # CONFIG_HZ_100 is not set # CONFIG_HZ_250 is not set # CONFIG_HZ_300 is not set CONFIG_HZ_1000=y CONFIG_HZ=1000 CONFIG_SCHED_HRTICK=y CONFIG_KEXEC=y CONFIG_CRASH_DUMP=y # CONFIG_KEXEC_JUMP is not set CONFIG_PHYSICAL_START=0x1000000 CONFIG_RELOCATABLE=y CONFIG_PHYSICAL_ALIGN=0x1000000 CONFIG_HOTPLUG_CPU=y # CONFIG_COMPAT_VDSO is not set # CONFIG_CMDLINE_BOOL is not set CONFIG_ARCH_ENABLE_MEMORY_HOTPLUG=y CONFIG_USE_PERCPU_NUMA_NODE_ID=y # # Power management and ACPI options # CONFIG_ARCH_HIBERNATION_HEADER=y CONFIG_SUSPEND=y CONFIG_SUSPEND_FREEZER=y CONFIG_HIBERNATE_CALLBACKS=y CONFIG_HIBERNATION=y CONFIG_PM_STD_PARTITION="" CONFIG_PM_SLEEP=y CONFIG_PM_SLEEP_SMP=y # CONFIG_PM_RUNTIME is not set CONFIG_PM=y CONFIG_PM_DEBUG=y # CONFIG_PM_ADVANCED_DEBUG is not set # CONFIG_PM_TEST_SUSPEND is not set CONFIG_CAN_PM_TRACE=y CONFIG_PM_TRACE=y CONFIG_PM_TRACE_RTC=y CONFIG_ACPI=y CONFIG_ACPI_SLEEP=y CONFIG_ACPI_PROCFS=y # CONFIG_ACPI_PROCFS_POWER is not set # CONFIG_ACPI_EC_DEBUGFS is not set CONFIG_ACPI_PROC_EVENT=y CONFIG_ACPI_AC=y CONFIG_ACPI_BATTERY=y CONFIG_ACPI_BUTTON=y CONFIG_ACPI_VIDEO=m CONFIG_ACPI_FAN=y CONFIG_ACPI_DOCK=y CONFIG_ACPI_PROCESSOR=y CONFIG_ACPI_HOTPLUG_CPU=y # CONFIG_ACPI_PROCESSOR_AGGREGATOR is not set CONFIG_ACPI_THERMAL=y CONFIG_ACPI_NUMA=y # CONFIG_ACPI_CUSTOM_DSDT is not set CONFIG_ACPI_BLACKLIST_YEAR=0 CONFIG_ACPI_DEBUG=y CONFIG_ACPI_DEBUG_FUNC_TRACE=y # CONFIG_ACPI_PCI_SLOT is not set CONFIG_X86_PM_TIMER=y CONFIG_ACPI_CONTAINER=y # CONFIG_ACPI_SBS is not set # CONFIG_ACPI_HED is not set # CONFIG_ACPI_CUSTOM_METHOD is not set # CONFIG_ACPI_APEI is not set # CONFIG_SFI is not set # # CPU Frequency scaling # CONFIG_CPU_FREQ=y CONFIG_CPU_FREQ_TABLE=y # CONFIG_CPU_FREQ_STAT is not set # CONFIG_CPU_FREQ_DEFAULT_GOV_PERFORMANCE is not set # CONFIG_CPU_FREQ_DEFAULT_GOV_USERSPACE is not set # CONFIG_CPU_FREQ_DEFAULT_GOV_ONDEMAND is not set CONFIG_CPU_FREQ_DEFAULT_GOV_CONSERVATIVE=y CONFIG_CPU_FREQ_GOV_PERFORMANCE=y # CONFIG_CPU_FREQ_GOV_POWERSAVE is not set # CONFIG_CPU_FREQ_GOV_USERSPACE is not set CONFIG_CPU_FREQ_GOV_ONDEMAND=y CONFIG_CPU_FREQ_GOV_CONSERVATIVE=y # # x86 CPU frequency scaling drivers # # CONFIG_X86_PCC_CPUFREQ is not set CONFIG_X86_ACPI_CPUFREQ=y CONFIG_X86_POWERNOW_K8=y CONFIG_X86_SPEEDSTEP_CENTRINO=y CONFIG_X86_P4_CLOCKMOD=y # # shared options # CONFIG_X86_SPEEDSTEP_LIB=y CONFIG_CPU_IDLE=y CONFIG_CPU_IDLE_GOV_LADDER=y CONFIG_CPU_IDLE_GOV_MENU=y # CONFIG_INTEL_IDLE is not set # # Memory power savings # # CONFIG_I7300_IDLE is not set # # Bus options (PCI etc.) # CONFIG_PCI=y CONFIG_PCI_DIRECT=y CONFIG_PCI_MMCONFIG=y CONFIG_PCI_XEN=y CONFIG_PCI_DOMAINS=y # CONFIG_PCI_CNB20LE_QUIRK is not set CONFIG_PCIEPORTBUS=y # CONFIG_HOTPLUG_PCI_PCIE is not set CONFIG_PCIEAER=y CONFIG_PCIE_ECRC=y # CONFIG_PCIEAER_INJECT is not set CONFIG_PCIEASPM=y # CONFIG_PCIEASPM_DEBUG is not set CONFIG_ARCH_SUPPORTS_MSI=y CONFIG_PCI_MSI=y # CONFIG_PCI_DEBUG is not set # CONFIG_PCI_STUB is not set CONFIG_XEN_PCIDEV_FRONTEND=y CONFIG_HT_IRQ=y CONFIG_PCI_IOV=y CONFIG_PCI_IOAPIC=y CONFIG_PCI_LABEL=y CONFIG_ISA_DMA_API=y CONFIG_AMD_NB=y CONFIG_PCCARD=y CONFIG_PCMCIA=y CONFIG_PCMCIA_LOAD_CIS=y CONFIG_CARDBUS=y # # PC-card bridges # CONFIG_YENTA=y CONFIG_YENTA_O2=y CONFIG_YENTA_RICOH=y CONFIG_YENTA_TI=y CONFIG_YENTA_ENE_TUNE=y CONFIG_YENTA_TOSHIBA=y # CONFIG_PD6729 is not set # CONFIG_I82092 is not set CONFIG_PCCARD_NONSTATIC=y CONFIG_HOTPLUG_PCI=y # CONFIG_HOTPLUG_PCI_FAKE is not set # CONFIG_HOTPLUG_PCI_ACPI is not set # CONFIG_HOTPLUG_PCI_CPCI is not set # CONFIG_HOTPLUG_PCI_SHPC is not set # CONFIG_RAPIDIO is not set # # Executable file formats / Emulations # CONFIG_BINFMT_ELF=y CONFIG_COMPAT_BINFMT_ELF=y CONFIG_CORE_DUMP_DEFAULT_ELF_HEADERS=y # CONFIG_HAVE_AOUT is not set CONFIG_BINFMT_MISC=y CONFIG_IA32_EMULATION=y # CONFIG_IA32_AOUT is not set CONFIG_COMPAT=y CONFIG_COMPAT_FOR_U64_ALIGNMENT=y CONFIG_SYSVIPC_COMPAT=y CONFIG_KEYS_COMPAT=y CONFIG_HAVE_TEXT_POKE_SMP=y CONFIG_NET=y # # Networking options # CONFIG_PACKET=y CONFIG_UNIX=y CONFIG_XFRM=y CONFIG_XFRM_USER=y # CONFIG_XFRM_SUB_POLICY is not set # CONFIG_XFRM_MIGRATE is not set # CONFIG_XFRM_STATISTICS is not set # CONFIG_NET_KEY is not set CONFIG_INET=y CONFIG_IP_MULTICAST=y CONFIG_IP_ADVANCED_ROUTER=y # CONFIG_IP_FIB_TRIE_STATS is not set CONFIG_IP_MULTIPLE_TABLES=y CONFIG_IP_ROUTE_MULTIPATH=y CONFIG_IP_ROUTE_VERBOSE=y CONFIG_IP_PNP=y CONFIG_IP_PNP_DHCP=y CONFIG_IP_PNP_BOOTP=y CONFIG_IP_PNP_RARP=y # CONFIG_NET_IPIP is not set # CONFIG_NET_IPGRE_DEMUX is not set CONFIG_IP_MROUTE=y # CONFIG_IP_MROUTE_MULTIPLE_TABLES is not set CONFIG_IP_PIMSM_V1=y CONFIG_IP_PIMSM_V2=y # CONFIG_ARPD is not set CONFIG_SYN_COOKIES=y # CONFIG_INET_AH is not set # CONFIG_INET_ESP is not set # CONFIG_INET_IPCOMP is not set # CONFIG_INET_XFRM_TUNNEL is not set CONFIG_INET_TUNNEL=y # CONFIG_INET_XFRM_MODE_TRANSPORT is not set # CONFIG_INET_XFRM_MODE_TUNNEL is not set # CONFIG_INET_XFRM_MODE_BEET is not set CONFIG_INET_LRO=y # CONFIG_INET_DIAG is not set CONFIG_TCP_CONG_ADVANCED=y # CONFIG_TCP_CONG_BIC is not set CONFIG_TCP_CONG_CUBIC=y # CONFIG_TCP_CONG_WESTWOOD is not set # CONFIG_TCP_CONG_HTCP is not set # CONFIG_TCP_CONG_HSTCP is not set # CONFIG_TCP_CONG_HYBLA is not set # CONFIG_TCP_CONG_VEGAS is not set # CONFIG_TCP_CONG_SCALABLE is not set # CONFIG_TCP_CONG_LP is not set # CONFIG_TCP_CONG_VENO is not set # CONFIG_TCP_CONG_YEAH is not set # CONFIG_TCP_CONG_ILLINOIS is not set CONFIG_DEFAULT_CUBIC=y # CONFIG_DEFAULT_RENO is not set CONFIG_DEFAULT_TCP_CONG="cubic" CONFIG_TCP_MD5SIG=y CONFIG_IPV6=y # CONFIG_IPV6_PRIVACY is not set # CONFIG_IPV6_ROUTER_PREF is not set # CONFIG_IPV6_OPTIMISTIC_DAD is not set CONFIG_INET6_AH=y CONFIG_INET6_ESP=y # CONFIG_INET6_IPCOMP is not set # CONFIG_IPV6_MIP6 is not set # CONFIG_INET6_XFRM_TUNNEL is not set # CONFIG_INET6_TUNNEL is not set CONFIG_INET6_XFRM_MODE_TRANSPORT=y CONFIG_INET6_XFRM_MODE_TUNNEL=y CONFIG_INET6_XFRM_MODE_BEET=y # CONFIG_INET6_XFRM_MODE_ROUTEOPTIMIZATION is not set CONFIG_IPV6_SIT=y # CONFIG_IPV6_SIT_6RD is not set CONFIG_IPV6_NDISC_NODETYPE=y # CONFIG_IPV6_TUNNEL is not set # CONFIG_IPV6_MULTIPLE_TABLES is not set # CONFIG_IPV6_MROUTE is not set CONFIG_NETLABEL=y CONFIG_NETWORK_SECMARK=y # CONFIG_NETWORK_PHY_TIMESTAMPING is not set CONFIG_NETFILTER=y # CONFIG_NETFILTER_DEBUG is not set # CONFIG_NETFILTER_ADVANCED is not set # # Core Netfilter Configuration # CONFIG_NETFILTER_NETLINK=y CONFIG_NETFILTER_NETLINK_LOG=y CONFIG_NF_CONNTRACK=y CONFIG_NF_CONNTRACK_SECMARK=y CONFIG_NF_CONNTRACK_FTP=y CONFIG_NF_CONNTRACK_IRC=y CONFIG_NF_CONNTRACK_SIP=y CONFIG_NF_CT_NETLINK=y CONFIG_NETFILTER_XTABLES=y # # Xtables combined modules # CONFIG_NETFILTER_XT_MARK=m # # Xtables targets # CONFIG_NETFILTER_XT_TARGET_CONNSECMARK=y CONFIG_NETFILTER_XT_TARGET_NFLOG=y CONFIG_NETFILTER_XT_TARGET_SECMARK=y CONFIG_NETFILTER_XT_TARGET_TCPMSS=y # # Xtables matches # CONFIG_NETFILTER_XT_MATCH_CONNTRACK=y CONFIG_NETFILTER_XT_MATCH_POLICY=y CONFIG_NETFILTER_XT_MATCH_STATE=y # CONFIG_IP_SET is not set # CONFIG_IP_VS is not set # # IP: Netfilter Configuration # CONFIG_NF_DEFRAG_IPV4=y CONFIG_NF_CONNTRACK_IPV4=y CONFIG_NF_CONNTRACK_PROC_COMPAT=y CONFIG_IP_NF_IPTABLES=y CONFIG_IP_NF_FILTER=y CONFIG_IP_NF_TARGET_REJECT=y CONFIG_IP_NF_TARGET_LOG=y CONFIG_IP_NF_TARGET_ULOG=y CONFIG_NF_NAT=y CONFIG_NF_NAT_NEEDED=y CONFIG_IP_NF_TARGET_MASQUERADE=y CONFIG_NF_NAT_FTP=y CONFIG_NF_NAT_IRC=y # CONFIG_NF_NAT_TFTP is not set # CONFIG_NF_NAT_AMANDA is not set # CONFIG_NF_NAT_PPTP is not set # CONFIG_NF_NAT_H323 is not set CONFIG_NF_NAT_SIP=y CONFIG_IP_NF_MANGLE=y # # IPv6: Netfilter Configuration # CONFIG_NF_DEFRAG_IPV6=y CONFIG_NF_CONNTRACK_IPV6=y CONFIG_IP6_NF_IPTABLES=y CONFIG_IP6_NF_MATCH_IPV6HEADER=y CONFIG_IP6_NF_TARGET_LOG=y CONFIG_IP6_NF_FILTER=y CONFIG_IP6_NF_TARGET_REJECT=y CONFIG_IP6_NF_MANGLE=y # CONFIG_BRIDGE_NF_EBTABLES is not set # CONFIG_IP_DCCP is not set # CONFIG_IP_SCTP is not set # CONFIG_RDS is not set # CONFIG_TIPC is not set # CONFIG_ATM is not set # CONFIG_L2TP is not set CONFIG_STP=y CONFIG_BRIDGE=y CONFIG_BRIDGE_IGMP_SNOOPING=y # CONFIG_NET_DSA is not set # CONFIG_VLAN_8021Q is not set # CONFIG_DECNET is not set CONFIG_LLC=y # CONFIG_LLC2 is not set # CONFIG_IPX is not set # CONFIG_ATALK is not set # CONFIG_X25 is not set # CONFIG_LAPB is not set # CONFIG_ECONET is not set # CONFIG_WAN_ROUTER is not set # CONFIG_PHONET is not set # CONFIG_IEEE802154 is not set CONFIG_NET_SCHED=y # # Queueing/Scheduling # # CONFIG_NET_SCH_CBQ is not set # CONFIG_NET_SCH_HTB is not set # CONFIG_NET_SCH_HFSC is not set # CONFIG_NET_SCH_PRIO is not set # CONFIG_NET_SCH_MULTIQ is not set # CONFIG_NET_SCH_RED is not set # CONFIG_NET_SCH_SFB is not set # CONFIG_NET_SCH_SFQ is not set # CONFIG_NET_SCH_TEQL is not set # CONFIG_NET_SCH_TBF is not set # CONFIG_NET_SCH_GRED is not set # CONFIG_NET_SCH_DSMARK is not set # CONFIG_NET_SCH_NETEM is not set # CONFIG_NET_SCH_DRR is not set # CONFIG_NET_SCH_MQPRIO is not set # CONFIG_NET_SCH_CHOKE is not set # CONFIG_NET_SCH_QFQ is not set # CONFIG_NET_SCH_INGRESS is not set # # Classification # CONFIG_NET_CLS=y # CONFIG_NET_CLS_BASIC is not set # CONFIG_NET_CLS_TCINDEX is not set # CONFIG_NET_CLS_ROUTE4 is not set # CONFIG_NET_CLS_FW is not set # CONFIG_NET_CLS_U32 is not set # CONFIG_NET_CLS_RSVP is not set # CONFIG_NET_CLS_RSVP6 is not set # CONFIG_NET_CLS_FLOW is not set # CONFIG_NET_CLS_CGROUP is not set CONFIG_NET_EMATCH=y CONFIG_NET_EMATCH_STACK=32 # CONFIG_NET_EMATCH_CMP is not set # CONFIG_NET_EMATCH_NBYTE is not set # CONFIG_NET_EMATCH_U32 is not set # CONFIG_NET_EMATCH_META is not set # CONFIG_NET_EMATCH_TEXT is not set CONFIG_NET_CLS_ACT=y # CONFIG_NET_ACT_POLICE is not set # CONFIG_NET_ACT_GACT is not set # CONFIG_NET_ACT_MIRRED is not set # CONFIG_NET_ACT_IPT is not set # CONFIG_NET_ACT_NAT is not set # CONFIG_NET_ACT_PEDIT is not set # CONFIG_NET_ACT_SIMP is not set # CONFIG_NET_ACT_SKBEDIT is not set # CONFIG_NET_ACT_CSUM is not set CONFIG_NET_SCH_FIFO=y # CONFIG_DCB is not set CONFIG_DNS_RESOLVER=y # CONFIG_BATMAN_ADV is not set CONFIG_RPS=y CONFIG_RFS_ACCEL=y CONFIG_XPS=y CONFIG_HAVE_BPF_JIT=y # CONFIG_BPF_JIT is not set # # Network testing # # CONFIG_NET_PKTGEN is not set # CONFIG_NET_TCPPROBE is not set # CONFIG_NET_DROP_MONITOR is not set # CONFIG_HAMRADIO is not set # CONFIG_CAN is not set # CONFIG_IRDA is not set # CONFIG_BT is not set # CONFIG_AF_RXRPC is not set CONFIG_FIB_RULES=y # CONFIG_WIRELESS is not set # CONFIG_WIMAX is not set CONFIG_RFKILL=y CONFIG_RFKILL_INPUT=y # CONFIG_NET_9P is not set # CONFIG_CAIF is not set # CONFIG_CEPH_LIB is not set # CONFIG_NFC is not set # # Device Drivers # # # Generic Driver Options # CONFIG_UEVENT_HELPER_PATH="/sbin/hotplug" # CONFIG_DEVTMPFS is not set CONFIG_STANDALONE=y CONFIG_PREVENT_FIRMWARE_BUILD=y CONFIG_FW_LOADER=y CONFIG_FIRMWARE_IN_KERNEL=y CONFIG_EXTRA_FIRMWARE="" # CONFIG_DEBUG_DRIVER is not set CONFIG_DEBUG_DEVRES=y CONFIG_SYS_HYPERVISOR=y CONFIG_CONNECTOR=y CONFIG_PROC_EVENTS=y # CONFIG_MTD is not set # CONFIG_PARPORT is not set CONFIG_PNP=y CONFIG_PNP_DEBUG_MESSAGES=y # # Protocols # CONFIG_PNPACPI=y CONFIG_BLK_DEV=y # CONFIG_BLK_DEV_FD is not set # CONFIG_BLK_CPQ_DA is not set # CONFIG_BLK_CPQ_CISS_DA is not set # CONFIG_BLK_DEV_DAC960 is not set # CONFIG_BLK_DEV_UMEM is not set # CONFIG_BLK_DEV_COW_COMMON is not set CONFIG_BLK_DEV_LOOP=y CONFIG_BLK_DEV_LOOP_MIN_COUNT=8 # CONFIG_BLK_DEV_CRYPTOLOOP is not set # CONFIG_BLK_DEV_DRBD is not set # CONFIG_BLK_DEV_NBD is not set # CONFIG_BLK_DEV_SX8 is not set # CONFIG_BLK_DEV_UB is not set CONFIG_BLK_DEV_RAM=y CONFIG_BLK_DEV_RAM_COUNT=16 CONFIG_BLK_DEV_RAM_SIZE=16384 # CONFIG_BLK_DEV_XIP is not set # CONFIG_CDROM_PKTCDVD is not set # CONFIG_ATA_OVER_ETH is not set CONFIG_XEN_BLKDEV_FRONTEND=m CONFIG_XEN_BLKDEV_BACKEND=y CONFIG_VIRTIO_BLK=m # CONFIG_BLK_DEV_HD is not set # CONFIG_BLK_DEV_RBD is not set # CONFIG_SENSORS_LIS3LV02D is not set # CONFIG_MISC_DEVICES is not set CONFIG_HAVE_IDE=y # CONFIG_IDE is not set # # SCSI device support # CONFIG_SCSI_MOD=m CONFIG_RAID_ATTRS=m CONFIG_SCSI=m CONFIG_SCSI_DMA=y CONFIG_SCSI_TGT=m CONFIG_SCSI_NETLINK=y CONFIG_SCSI_PROC_FS=y # # SCSI support type (disk, tape, CD-ROM) # CONFIG_BLK_DEV_SD=m CONFIG_CHR_DEV_ST=m CONFIG_CHR_DEV_OSST=m CONFIG_BLK_DEV_SR=m CONFIG_BLK_DEV_SR_VENDOR=y CONFIG_CHR_DEV_SG=m CONFIG_CHR_DEV_SCH=m CONFIG_SCSI_MULTI_LUN=y CONFIG_SCSI_CONSTANTS=y CONFIG_SCSI_LOGGING=y CONFIG_SCSI_SCAN_ASYNC=y CONFIG_SCSI_WAIT_SCAN=m # # SCSI Transports # CONFIG_SCSI_SPI_ATTRS=m CONFIG_SCSI_FC_ATTRS=m CONFIG_SCSI_FC_TGT_ATTRS=y CONFIG_SCSI_ISCSI_ATTRS=m CONFIG_SCSI_SAS_ATTRS=m CONFIG_SCSI_SAS_LIBSAS=m CONFIG_SCSI_SAS_ATA=y CONFIG_SCSI_SAS_HOST_SMP=y # CONFIG_SCSI_SRP_ATTRS is not set CONFIG_SCSI_LOWLEVEL=y CONFIG_ISCSI_TCP=m CONFIG_ISCSI_BOOT_SYSFS=m # CONFIG_SCSI_CXGB3_ISCSI is not set # CONFIG_SCSI_CXGB4_ISCSI is not set # CONFIG_SCSI_BNX2_ISCSI is not set # CONFIG_SCSI_BNX2X_FCOE is not set # CONFIG_BE2ISCSI is not set CONFIG_BLK_DEV_3W_XXXX_RAID=m # CONFIG_SCSI_HPSA is not set CONFIG_SCSI_3W_9XXX=m # CONFIG_SCSI_3W_SAS is not set CONFIG_SCSI_ACARD=m CONFIG_SCSI_AACRAID=m CONFIG_SCSI_AIC7XXX=m CONFIG_AIC7XXX_CMDS_PER_DEVICE=8 CONFIG_AIC7XXX_RESET_DELAY_MS=15000 CONFIG_AIC7XXX_DEBUG_ENABLE=y CONFIG_AIC7XXX_DEBUG_MASK=0 CONFIG_AIC7XXX_REG_PRETTY_PRINT=y CONFIG_SCSI_AIC7XXX_OLD=m CONFIG_SCSI_AIC79XX=m CONFIG_AIC79XX_CMDS_PER_DEVICE=32 CONFIG_AIC79XX_RESET_DELAY_MS=15000 CONFIG_AIC79XX_DEBUG_ENABLE=y CONFIG_AIC79XX_DEBUG_MASK=0 CONFIG_AIC79XX_REG_PRETTY_PRINT=y CONFIG_SCSI_AIC94XX=m # CONFIG_AIC94XX_DEBUG is not set CONFIG_SCSI_MVSAS=m # CONFIG_SCSI_MVSAS_DEBUG is not set # CONFIG_SCSI_MVSAS_TASKLET is not set CONFIG_SCSI_DPT_I2O=m CONFIG_SCSI_ADVANSYS=m CONFIG_SCSI_ARCMSR=m CONFIG_SCSI_ARCMSR_AER=y CONFIG_MEGARAID_NEWGEN=y CONFIG_MEGARAID_MM=m CONFIG_MEGARAID_MAILBOX=m CONFIG_MEGARAID_LEGACY=m CONFIG_MEGARAID_SAS=m CONFIG_SCSI_MPT2SAS=m CONFIG_SCSI_MPT2SAS_MAX_SGE=128 CONFIG_SCSI_MPT2SAS_LOGGING=y CONFIG_SCSI_HPTIOP=m CONFIG_SCSI_BUSLOGIC=m # CONFIG_VMWARE_PVSCSI is not set CONFIG_LIBFC=m CONFIG_LIBFCOE=m CONFIG_FCOE=m # CONFIG_FCOE_FNIC is not set CONFIG_SCSI_DMX3191D=m CONFIG_SCSI_EATA=m CONFIG_SCSI_EATA_TAGGED_QUEUE=y CONFIG_SCSI_EATA_LINKED_COMMANDS=y CONFIG_SCSI_EATA_MAX_TAGS=16 CONFIG_SCSI_FUTURE_DOMAIN=m CONFIG_SCSI_GDTH=m CONFIG_SCSI_ISCI=m CONFIG_SCSI_IPS=m CONFIG_SCSI_INITIO=m # CONFIG_SCSI_INIA100 is not set CONFIG_SCSI_STEX=m CONFIG_SCSI_SYM53C8XX_2=m CONFIG_SCSI_SYM53C8XX_DMA_ADDRESSING_MODE=1 CONFIG_SCSI_SYM53C8XX_DEFAULT_TAGS=16 CONFIG_SCSI_SYM53C8XX_MAX_TAGS=64 CONFIG_SCSI_SYM53C8XX_MMIO=y CONFIG_SCSI_IPR=m # CONFIG_SCSI_IPR_TRACE is not set # CONFIG_SCSI_IPR_DUMP is not set CONFIG_SCSI_QLOGIC_1280=m CONFIG_SCSI_QLA_FC=m # CONFIG_SCSI_QLA_ISCSI is not set CONFIG_SCSI_LPFC=m # CONFIG_SCSI_LPFC_DEBUG_FS is not set CONFIG_SCSI_DC395x=m CONFIG_SCSI_DC390T=m CONFIG_SCSI_DEBUG=m # CONFIG_SCSI_PMCRAID is not set # CONFIG_SCSI_PM8001 is not set CONFIG_SCSI_SRP=m # CONFIG_SCSI_BFA_FC is not set # CONFIG_SCSI_LOWLEVEL_PCMCIA is not set # CONFIG_SCSI_DH is not set # CONFIG_SCSI_OSD_INITIATOR is not set CONFIG_ATA=m # CONFIG_ATA_NONSTANDARD is not set CONFIG_ATA_VERBOSE_ERROR=y CONFIG_ATA_ACPI=y CONFIG_SATA_PMP=y # # Controllers with non-SFF native interface # CONFIG_SATA_AHCI=m # CONFIG_SATA_AHCI_PLATFORM is not set CONFIG_SATA_INIC162X=m # CONFIG_SATA_ACARD_AHCI is not set CONFIG_SATA_SIL24=m CONFIG_ATA_SFF=y # # SFF controllers with custom DMA interface # CONFIG_PDC_ADMA=m CONFIG_SATA_QSTOR=m CONFIG_SATA_SX4=m CONFIG_ATA_BMDMA=y # # SATA SFF controllers with BMDMA # CONFIG_ATA_PIIX=m CONFIG_SATA_MV=m CONFIG_SATA_NV=m CONFIG_SATA_PROMISE=m CONFIG_SATA_SIL=m CONFIG_SATA_SIS=m CONFIG_SATA_SVW=m CONFIG_SATA_ULI=m CONFIG_SATA_VIA=m CONFIG_SATA_VITESSE=m # # PATA SFF controllers with BMDMA # # CONFIG_PATA_ALI is not set # CONFIG_PATA_AMD is not set # CONFIG_PATA_ARASAN_CF is not set # CONFIG_PATA_ARTOP is not set # CONFIG_PATA_ATIIXP is not set # CONFIG_PATA_ATP867X is not set # CONFIG_PATA_CMD64X is not set # CONFIG_PATA_CS5520 is not set # CONFIG_PATA_CS5530 is not set # CONFIG_PATA_CS5536 is not set # CONFIG_PATA_CYPRESS is not set CONFIG_PATA_EFAR=m # CONFIG_PATA_HPT366 is not set # CONFIG_PATA_HPT37X is not set # CONFIG_PATA_HPT3X2N is not set # CONFIG_PATA_HPT3X3 is not set # CONFIG_PATA_IT8213 is not set # CONFIG_PATA_IT821X is not set # CONFIG_PATA_JMICRON is not set CONFIG_PATA_MARVELL=m # CONFIG_PATA_NETCELL is not set # CONFIG_PATA_NINJA32 is not set # CONFIG_PATA_NS87415 is not set # CONFIG_PATA_OLDPIIX is not set # CONFIG_PATA_OPTIDMA is not set # CONFIG_PATA_PDC2027X is not set CONFIG_PATA_PDC_OLD=m CONFIG_PATA_RADISYS=m # CONFIG_PATA_RDC is not set # CONFIG_PATA_SC1200 is not set CONFIG_PATA_SCH=m # CONFIG_PATA_SERVERWORKS is not set # CONFIG_PATA_SIL680 is not set CONFIG_PATA_SIS=m # CONFIG_PATA_TOSHIBA is not set # CONFIG_PATA_TRIFLEX is not set # CONFIG_PATA_VIA is not set CONFIG_PATA_WINBOND=m # # PIO-only SFF controllers # # CONFIG_PATA_CMD640_PCI is not set # CONFIG_PATA_MPIIX is not set # CONFIG_PATA_NS87410 is not set # CONFIG_PATA_OPTI is not set CONFIG_PATA_PCMCIA=m # CONFIG_PATA_RZ1000 is not set # # Generic fallback / legacy drivers # # CONFIG_PATA_ACPI is not set CONFIG_ATA_GENERIC=m CONFIG_PATA_LEGACY=m CONFIG_MD=y CONFIG_BLK_DEV_MD=m CONFIG_MD_LINEAR=m CONFIG_MD_RAID0=m CONFIG_MD_RAID1=m CONFIG_MD_RAID10=m CONFIG_MD_RAID456=m # CONFIG_MULTICORE_RAID456 is not set CONFIG_MD_MULTIPATH=m CONFIG_MD_FAULTY=m CONFIG_BLK_DEV_DM=m # CONFIG_DM_DEBUG is not set CONFIG_DM_CRYPT=m CONFIG_DM_SNAPSHOT=m CONFIG_DM_MIRROR=m # CONFIG_DM_RAID is not set # CONFIG_DM_LOG_USERSPACE is not set CONFIG_DM_ZERO=m CONFIG_DM_MULTIPATH=m # CONFIG_DM_MULTIPATH_QL is not set # CONFIG_DM_MULTIPATH_ST is not set CONFIG_DM_DELAY=m # CONFIG_DM_UEVENT is not set # CONFIG_DM_FLAKEY is not set CONFIG_TARGET_CORE=m CONFIG_TCM_IBLOCK=m CONFIG_TCM_FILEIO=m CONFIG_TCM_PSCSI=m CONFIG_LOOPBACK_TARGET=m CONFIG_TCM_FC=m CONFIG_ISCSI_TARGET=m CONFIG_FUSION=y CONFIG_FUSION_SPI=m CONFIG_FUSION_FC=m CONFIG_FUSION_SAS=m CONFIG_FUSION_MAX_SGE=40 CONFIG_FUSION_CTL=m # CONFIG_FUSION_LOGGING is not set # # IEEE 1394 (FireWire) support # # CONFIG_FIREWIRE is not set # CONFIG_FIREWIRE_NOSY is not set # CONFIG_I2O is not set CONFIG_MACINTOSH_DRIVERS=y CONFIG_MAC_EMUMOUSEBTN=y CONFIG_NETDEVICES=y # CONFIG_IFB is not set # CONFIG_DUMMY is not set # CONFIG_BONDING is not set # CONFIG_MACVLAN is not set # CONFIG_EQUALIZER is not set CONFIG_TUN=y # CONFIG_VETH is not set # CONFIG_NET_SB1000 is not set # CONFIG_ARCNET is not set CONFIG_MII=m CONFIG_PHYLIB=y # # MII PHY device drivers # CONFIG_MARVELL_PHY=m CONFIG_DAVICOM_PHY=m CONFIG_QSEMI_PHY=m CONFIG_LXT_PHY=m CONFIG_CICADA_PHY=m CONFIG_VITESSE_PHY=m CONFIG_SMSC_PHY=m CONFIG_BROADCOM_PHY=m # CONFIG_ICPLUS_PHY is not set # CONFIG_REALTEK_PHY is not set # CONFIG_NATIONAL_PHY is not set # CONFIG_STE10XP is not set # CONFIG_LSI_ET1011C_PHY is not set # CONFIG_MICREL_PHY is not set CONFIG_FIXED_PHY=y # CONFIG_MDIO_BITBANG is not set CONFIG_NET_ETHERNET=y CONFIG_HAPPYMEAL=m CONFIG_SUNGEM=m CONFIG_CASSINI=m CONFIG_NET_VENDOR_3COM=y CONFIG_VORTEX=m CONFIG_TYPHOON=m # CONFIG_ETHOC is not set # CONFIG_DNET is not set CONFIG_NET_TULIP=y # CONFIG_DE2104X is not set # CONFIG_TULIP is not set # CONFIG_DE4X5 is not set # CONFIG_WINBOND_840 is not set # CONFIG_DM9102 is not set # CONFIG_ULI526X is not set # CONFIG_PCMCIA_XIRCOM is not set # CONFIG_HP100 is not set # CONFIG_IBM_NEW_EMAC_ZMII is not set # CONFIG_IBM_NEW_EMAC_RGMII is not set # CONFIG_IBM_NEW_EMAC_TAH is not set # CONFIG_IBM_NEW_EMAC_EMAC4 is not set # CONFIG_IBM_NEW_EMAC_NO_FLOW_CTRL is not set # CONFIG_IBM_NEW_EMAC_MAL_CLR_ICINTSTAT is not set # CONFIG_IBM_NEW_EMAC_MAL_COMMON_ERR is not set CONFIG_NET_PCI=y # CONFIG_PCNET32 is not set # CONFIG_AMD8111_ETH is not set # CONFIG_ADAPTEC_STARFIRE is not set # CONFIG_KSZ884X_PCI is not set # CONFIG_B44 is not set CONFIG_FORCEDETH=y CONFIG_E100=m # CONFIG_FEALNX is not set # CONFIG_NATSEMI is not set CONFIG_NE2K_PCI=m # CONFIG_8139CP is not set CONFIG_8139TOO=m # CONFIG_8139TOO_PIO is not set # CONFIG_8139TOO_TUNE_TWISTER is not set # CONFIG_8139TOO_8129 is not set # CONFIG_8139_OLD_RX_RESET is not set # CONFIG_R6040 is not set # CONFIG_SIS900 is not set # CONFIG_EPIC100 is not set # CONFIG_SMSC9420 is not set # CONFIG_SUNDANCE is not set CONFIG_TLAN=m # CONFIG_KS8851_MLL is not set CONFIG_VIA_RHINE=m # CONFIG_VIA_RHINE_MMIO is not set CONFIG_SC92031=m # CONFIG_ATL2 is not set CONFIG_NETDEV_1000=y # CONFIG_ACENIC is not set # CONFIG_DL2K is not set CONFIG_E1000=m CONFIG_E1000E=m # CONFIG_IP1000 is not set CONFIG_IGB=m CONFIG_IGBVF=m # CONFIG_NS83820 is not set # CONFIG_HAMACHI is not set # CONFIG_YELLOWFIN is not set CONFIG_R8169=m # CONFIG_SIS190 is not set CONFIG_SKGE=m # CONFIG_SKGE_DEBUG is not set # CONFIG_SKGE_GENESIS is not set CONFIG_SKY2=m # CONFIG_SKY2_DEBUG is not set CONFIG_VIA_VELOCITY=m CONFIG_TIGON3=y CONFIG_BNX2=m # CONFIG_CNIC is not set # CONFIG_QLA3XXX is not set # CONFIG_ATL1 is not set # CONFIG_ATL1E is not set CONFIG_ATL1C=m # CONFIG_JME is not set # CONFIG_STMMAC_ETH is not set # CONFIG_PCH_GBE is not set CONFIG_NETDEV_10000=y CONFIG_MDIO=m # CONFIG_CHELSIO_T1 is not set # CONFIG_CHELSIO_T3 is not set # CONFIG_CHELSIO_T4 is not set # CONFIG_CHELSIO_T4VF is not set # CONFIG_ENIC is not set CONFIG_IXGBE=m # CONFIG_IXGBEVF is not set # CONFIG_IXGB is not set # CONFIG_S2IO is not set # CONFIG_VXGE is not set # CONFIG_MYRI10GE is not set # CONFIG_NETXEN_NIC is not set # CONFIG_NIU is not set # CONFIG_MLX4_EN is not set # CONFIG_MLX4_CORE is not set # CONFIG_TEHUTI is not set CONFIG_BNX2X=m # CONFIG_QLCNIC is not set # CONFIG_QLGE is not set # CONFIG_BNA is not set # CONFIG_SFC is not set # CONFIG_BE2NET is not set CONFIG_TR=y # CONFIG_IBMOL is not set CONFIG_3C359=m # CONFIG_TMS380TR is not set # CONFIG_WLAN is not set # # Enable WiMAX (Networking options) to see the WiMAX drivers # # # USB Network Adapters # # CONFIG_USB_CATC is not set # CONFIG_USB_KAWETH is not set # CONFIG_USB_PEGASUS is not set # CONFIG_USB_RTL8150 is not set # CONFIG_USB_USBNET is not set # CONFIG_USB_HSO is not set # CONFIG_USB_IPHETH is not set CONFIG_NET_PCMCIA=y # CONFIG_PCMCIA_3C589 is not set # CONFIG_PCMCIA_3C574 is not set # CONFIG_PCMCIA_FMVJ18X is not set # CONFIG_PCMCIA_PCNET is not set # CONFIG_PCMCIA_NMCLAN is not set # CONFIG_PCMCIA_SMC91C92 is not set # CONFIG_PCMCIA_XIRC2PS is not set # CONFIG_PCMCIA_AXNET is not set # CONFIG_PCMCIA_IBMTR is not set # CONFIG_WAN is not set # # CAIF transport drivers # CONFIG_XEN_NETDEV_FRONTEND=m CONFIG_XEN_NETDEV_BACKEND=y CONFIG_FDDI=y # CONFIG_DEFXX is not set # CONFIG_SKFP is not set # CONFIG_HIPPI is not set # CONFIG_PPP is not set # CONFIG_SLIP is not set # CONFIG_NET_FC is not set CONFIG_NETCONSOLE=m # CONFIG_NETCONSOLE_DYNAMIC is not set CONFIG_NETPOLL=y # CONFIG_NETPOLL_TRAP is not set CONFIG_NET_POLL_CONTROLLER=y CONFIG_VIRTIO_NET=m # CONFIG_VMXNET3 is not set # CONFIG_ISDN is not set # CONFIG_PHONE is not set # # Input device support # CONFIG_INPUT=y CONFIG_INPUT_FF_MEMLESS=m # CONFIG_INPUT_POLLDEV is not set CONFIG_INPUT_SPARSEKMAP=y # # Userland interfaces # CONFIG_INPUT_MOUSEDEV=y # CONFIG_INPUT_MOUSEDEV_PSAUX is not set CONFIG_INPUT_MOUSEDEV_SCREEN_X=1024 CONFIG_INPUT_MOUSEDEV_SCREEN_Y=768 # CONFIG_INPUT_JOYDEV is not set CONFIG_INPUT_EVDEV=y # CONFIG_INPUT_EVBUG is not set # # Input Device Drivers # CONFIG_INPUT_KEYBOARD=y # CONFIG_KEYBOARD_ADP5588 is not set # CONFIG_KEYBOARD_ADP5589 is not set CONFIG_KEYBOARD_ATKBD=y # CONFIG_KEYBOARD_QT1070 is not set # CONFIG_KEYBOARD_QT2160 is not set # CONFIG_KEYBOARD_LKKBD is not set # CONFIG_KEYBOARD_TCA6416 is not set # CONFIG_KEYBOARD_LM8323 is not set # CONFIG_KEYBOARD_MAX7359 is not set # CONFIG_KEYBOARD_MCS is not set # CONFIG_KEYBOARD_MPR121 is not set # CONFIG_KEYBOARD_NEWTON is not set # CONFIG_KEYBOARD_OPENCORES is not set # CONFIG_KEYBOARD_STOWAWAY is not set # CONFIG_KEYBOARD_SUNKBD is not set # CONFIG_KEYBOARD_XTKBD is not set CONFIG_INPUT_MOUSE=y CONFIG_MOUSE_PS2=y CONFIG_MOUSE_PS2_ALPS=y CONFIG_MOUSE_PS2_LOGIPS2PP=y CONFIG_MOUSE_PS2_SYNAPTICS=y CONFIG_MOUSE_PS2_LIFEBOOK=y CONFIG_MOUSE_PS2_TRACKPOINT=y # CONFIG_MOUSE_PS2_ELANTECH is not set # CONFIG_MOUSE_PS2_SENTELIC is not set # CONFIG_MOUSE_PS2_TOUCHKIT is not set # CONFIG_MOUSE_SERIAL is not set # CONFIG_MOUSE_APPLETOUCH is not set # CONFIG_MOUSE_BCM5974 is not set # CONFIG_MOUSE_VSXXXAA is not set # CONFIG_MOUSE_SYNAPTICS_I2C is not set CONFIG_INPUT_JOYSTICK=y # CONFIG_JOYSTICK_ANALOG is not set # CONFIG_JOYSTICK_A3D is not set # CONFIG_JOYSTICK_ADI is not set # CONFIG_JOYSTICK_COBRA is not set # CONFIG_JOYSTICK_GF2K is not set # CONFIG_JOYSTICK_GRIP is not set # CONFIG_JOYSTICK_GRIP_MP is not set # CONFIG_JOYSTICK_GUILLEMOT is not set # CONFIG_JOYSTICK_INTERACT is not set # CONFIG_JOYSTICK_SIDEWINDER is not set # CONFIG_JOYSTICK_TMDC is not set # CONFIG_JOYSTICK_IFORCE is not set # CONFIG_JOYSTICK_WARRIOR is not set # CONFIG_JOYSTICK_MAGELLAN is not set # CONFIG_JOYSTICK_SPACEORB is not set # CONFIG_JOYSTICK_SPACEBALL is not set # CONFIG_JOYSTICK_STINGER is not set # CONFIG_JOYSTICK_TWIDJOY is not set # CONFIG_JOYSTICK_ZHENHUA is not set # CONFIG_JOYSTICK_AS5011 is not set # CONFIG_JOYSTICK_JOYDUMP is not set # CONFIG_JOYSTICK_XPAD is not set CONFIG_INPUT_TABLET=y # CONFIG_TABLET_USB_ACECAD is not set # CONFIG_TABLET_USB_AIPTEK is not set # CONFIG_TABLET_USB_GTCO is not set # CONFIG_TABLET_USB_HANWANG is not set # CONFIG_TABLET_USB_KBTAB is not set # CONFIG_TABLET_USB_WACOM is not set # CONFIG_INPUT_TOUCHSCREEN is not set CONFIG_INPUT_MISC=y # CONFIG_INPUT_AD714X is not set # CONFIG_INPUT_PCSPKR is not set # CONFIG_INPUT_MMA8450 is not set # CONFIG_INPUT_MPU3050 is not set # CONFIG_INPUT_APANEL is not set # CONFIG_INPUT_ATLAS_BTNS is not set # CONFIG_INPUT_ATI_REMOTE is not set # CONFIG_INPUT_ATI_REMOTE2 is not set # CONFIG_INPUT_KEYSPAN_REMOTE is not set # CONFIG_INPUT_KXTJ9 is not set # CONFIG_INPUT_POWERMATE is not set # CONFIG_INPUT_YEALINK is not set # CONFIG_INPUT_CM109 is not set # CONFIG_INPUT_UINPUT is not set # CONFIG_INPUT_PCF8574 is not set # CONFIG_INPUT_ADXL34X is not set # CONFIG_INPUT_CMA3000 is not set CONFIG_INPUT_XEN_KBDDEV_FRONTEND=m # # Hardware I/O ports # CONFIG_SERIO=y CONFIG_SERIO_I8042=y CONFIG_SERIO_SERPORT=y # CONFIG_SERIO_CT82C710 is not set # CONFIG_SERIO_PCIPS2 is not set CONFIG_SERIO_LIBPS2=y # CONFIG_SERIO_RAW is not set # CONFIG_SERIO_ALTERA_PS2 is not set # CONFIG_SERIO_PS2MULT is not set # CONFIG_GAMEPORT is not set # # Character devices # CONFIG_VT=y CONFIG_CONSOLE_TRANSLATIONS=y CONFIG_VT_CONSOLE=y CONFIG_HW_CONSOLE=y # CONFIG_VT_HW_CONSOLE_BINDING is not set CONFIG_UNIX98_PTYS=y # CONFIG_DEVPTS_MULTIPLE_INSTANCES is not set CONFIG_LEGACY_PTYS=y CONFIG_LEGACY_PTY_COUNT=256 # CONFIG_SERIAL_NONSTANDARD is not set # CONFIG_NOZOMI is not set # CONFIG_N_GSM is not set # CONFIG_TRACE_SINK is not set CONFIG_DEVKMEM=y # # Serial drivers # CONFIG_SERIAL_8250=y CONFIG_SERIAL_8250_CONSOLE=y CONFIG_FIX_EARLYCON_MEM=y CONFIG_SERIAL_8250_PCI=y CONFIG_SERIAL_8250_PNP=y CONFIG_SERIAL_8250_CS=m CONFIG_SERIAL_8250_NR_UARTS=16 CONFIG_SERIAL_8250_RUNTIME_UARTS=4 CONFIG_SERIAL_8250_EXTENDED=y CONFIG_SERIAL_8250_MANY_PORTS=y CONFIG_SERIAL_8250_SHARE_IRQ=y # CONFIG_SERIAL_8250_DETECT_IRQ is not set # CONFIG_SERIAL_8250_RSA is not set # # Non-8250 serial port support # # CONFIG_SERIAL_MFD_HSU is not set CONFIG_SERIAL_CORE=y CONFIG_SERIAL_CORE_CONSOLE=y CONFIG_CONSOLE_POLL=y # CONFIG_SERIAL_JSM is not set # CONFIG_SERIAL_TIMBERDALE is not set # CONFIG_SERIAL_ALTERA_JTAGUART is not set # CONFIG_SERIAL_ALTERA_UART is not set # CONFIG_SERIAL_PCH_UART is not set # CONFIG_SERIAL_XILINX_PS_UART is not set CONFIG_HVC_DRIVER=y CONFIG_HVC_IRQ=y CONFIG_HVC_XEN=y # CONFIG_VIRTIO_CONSOLE is not set # CONFIG_IPMI_HANDLER is not set CONFIG_HW_RANDOM=y # CONFIG_HW_RANDOM_TIMERIOMEM is not set # CONFIG_HW_RANDOM_INTEL is not set # CONFIG_HW_RANDOM_AMD is not set CONFIG_HW_RANDOM_VIA=y CONFIG_HW_RANDOM_VIRTIO=m CONFIG_NVRAM=y # CONFIG_R3964 is not set # CONFIG_APPLICOM is not set # # PCMCIA character devices # # CONFIG_SYNCLINK_CS is not set # CONFIG_CARDMAN_4000 is not set # CONFIG_CARDMAN_4040 is not set # CONFIG_IPWIRELESS is not set # CONFIG_MWAVE is not set # CONFIG_RAW_DRIVER is not set CONFIG_HPET=y # CONFIG_HPET_MMAP is not set # CONFIG_HANGCHECK_TIMER is not set # CONFIG_TCG_TPM is not set # CONFIG_TELCLOCK is not set CONFIG_DEVPORT=y # CONFIG_RAMOOPS is not set CONFIG_I2C=y CONFIG_I2C_BOARDINFO=y CONFIG_I2C_COMPAT=y # CONFIG_I2C_CHARDEV is not set # CONFIG_I2C_MUX is not set CONFIG_I2C_HELPER_AUTO=y CONFIG_I2C_ALGOBIT=y # # I2C Hardware Bus support # # # PC SMBus host controller drivers # # CONFIG_I2C_ALI1535 is not set # CONFIG_I2C_ALI1563 is not set # CONFIG_I2C_ALI15X3 is not set # CONFIG_I2C_AMD756 is not set # CONFIG_I2C_AMD8111 is not set CONFIG_I2C_I801=y # CONFIG_I2C_ISCH is not set # CONFIG_I2C_PIIX4 is not set # CONFIG_I2C_NFORCE2 is not set # CONFIG_I2C_SIS5595 is not set # CONFIG_I2C_SIS630 is not set # CONFIG_I2C_SIS96X is not set # CONFIG_I2C_VIA is not set # CONFIG_I2C_VIAPRO is not set # # ACPI drivers # # CONFIG_I2C_SCMI is not set # # I2C system bus drivers (mostly embedded / system-on-chip) # # CONFIG_I2C_INTEL_MID is not set # CONFIG_I2C_OCORES is not set # CONFIG_I2C_PCA_PLATFORM is not set # CONFIG_I2C_PXA_PCI is not set # CONFIG_I2C_SIMTEC is not set # CONFIG_I2C_XILINX is not set # CONFIG_I2C_EG20T is not set # # External I2C/SMBus adapter drivers # # CONFIG_I2C_DIOLAN_U2C is not set # CONFIG_I2C_PARPORT_LIGHT is not set # CONFIG_I2C_TAOS_EVM is not set # CONFIG_I2C_TINY_USB is not set # # Other I2C/SMBus bus drivers # # CONFIG_I2C_STUB is not set # CONFIG_I2C_DEBUG_CORE is not set # CONFIG_I2C_DEBUG_ALGO is not set # CONFIG_I2C_DEBUG_BUS is not set # CONFIG_SPI is not set # # PPS support # # CONFIG_PPS is not set # # PPS generators support # # # PTP clock support # # # Enable Device Drivers -> PPS to see the PTP clock options. # CONFIG_ARCH_WANT_OPTIONAL_GPIOLIB=y # CONFIG_GPIOLIB is not set # CONFIG_W1 is not set CONFIG_POWER_SUPPLY=y # CONFIG_POWER_SUPPLY_DEBUG is not set # CONFIG_PDA_POWER is not set # CONFIG_TEST_POWER is not set # CONFIG_BATTERY_DS2780 is not set # CONFIG_BATTERY_DS2782 is not set # CONFIG_BATTERY_BQ20Z75 is not set # CONFIG_BATTERY_BQ27x00 is not set # CONFIG_BATTERY_MAX17040 is not set # CONFIG_BATTERY_MAX17042 is not set # CONFIG_CHARGER_MAX8903 is not set CONFIG_HWMON=y # CONFIG_HWMON_VID is not set # CONFIG_HWMON_DEBUG_CHIP is not set # # Native drivers # # CONFIG_SENSORS_ABITUGURU is not set # CONFIG_SENSORS_ABITUGURU3 is not set # CONFIG_SENSORS_AD7414 is not set # CONFIG_SENSORS_AD7418 is not set # CONFIG_SENSORS_ADM1021 is not set # CONFIG_SENSORS_ADM1025 is not set # CONFIG_SENSORS_ADM1026 is not set # CONFIG_SENSORS_ADM1029 is not set # CONFIG_SENSORS_ADM1031 is not set # CONFIG_SENSORS_ADM9240 is not set # CONFIG_SENSORS_ADT7411 is not set # CONFIG_SENSORS_ADT7462 is not set # CONFIG_SENSORS_ADT7470 is not set # CONFIG_SENSORS_ADT7475 is not set # CONFIG_SENSORS_ASC7621 is not set # CONFIG_SENSORS_K8TEMP is not set # CONFIG_SENSORS_K10TEMP is not set # CONFIG_SENSORS_FAM15H_POWER is not set # CONFIG_SENSORS_ASB100 is not set # CONFIG_SENSORS_ATXP1 is not set # CONFIG_SENSORS_DS620 is not set # CONFIG_SENSORS_DS1621 is not set # CONFIG_SENSORS_I5K_AMB is not set # CONFIG_SENSORS_F71805F is not set # CONFIG_SENSORS_F71882FG is not set # CONFIG_SENSORS_F75375S is not set # CONFIG_SENSORS_FSCHMD is not set # CONFIG_SENSORS_G760A is not set # CONFIG_SENSORS_GL518SM is not set # CONFIG_SENSORS_GL520SM is not set # CONFIG_SENSORS_CORETEMP is not set # CONFIG_SENSORS_IT87 is not set # CONFIG_SENSORS_JC42 is not set # CONFIG_SENSORS_LINEAGE is not set # CONFIG_SENSORS_LM63 is not set # CONFIG_SENSORS_LM73 is not set # CONFIG_SENSORS_LM75 is not set # CONFIG_SENSORS_LM77 is not set # CONFIG_SENSORS_LM78 is not set # CONFIG_SENSORS_LM80 is not set # CONFIG_SENSORS_LM83 is not set # CONFIG_SENSORS_LM85 is not set # CONFIG_SENSORS_LM87 is not set # CONFIG_SENSORS_LM90 is not set # CONFIG_SENSORS_LM92 is not set # CONFIG_SENSORS_LM93 is not set # CONFIG_SENSORS_LTC4151 is not set # CONFIG_SENSORS_LTC4215 is not set # CONFIG_SENSORS_LTC4245 is not set # CONFIG_SENSORS_LTC4261 is not set # CONFIG_SENSORS_LM95241 is not set # CONFIG_SENSORS_LM95245 is not set # CONFIG_SENSORS_MAX16065 is not set # CONFIG_SENSORS_MAX1619 is not set # CONFIG_SENSORS_MAX1668 is not set # CONFIG_SENSORS_MAX6639 is not set # CONFIG_SENSORS_MAX6642 is not set # CONFIG_SENSORS_MAX6650 is not set # CONFIG_SENSORS_NTC_THERMISTOR is not set # CONFIG_SENSORS_PC87360 is not set # CONFIG_SENSORS_PC87427 is not set # CONFIG_SENSORS_PCF8591 is not set # CONFIG_PMBUS is not set # CONFIG_SENSORS_SHT21 is not set # CONFIG_SENSORS_SIS5595 is not set # CONFIG_SENSORS_SMM665 is not set # CONFIG_SENSORS_DME1737 is not set # CONFIG_SENSORS_EMC1403 is not set # CONFIG_SENSORS_EMC2103 is not set # CONFIG_SENSORS_EMC6W201 is not set # CONFIG_SENSORS_SMSC47M1 is not set # CONFIG_SENSORS_SMSC47M192 is not set # CONFIG_SENSORS_SMSC47B397 is not set # CONFIG_SENSORS_SCH56XX_COMMON is not set # CONFIG_SENSORS_SCH5627 is not set # CONFIG_SENSORS_SCH5636 is not set # CONFIG_SENSORS_ADS1015 is not set # CONFIG_SENSORS_ADS7828 is not set # CONFIG_SENSORS_AMC6821 is not set # CONFIG_SENSORS_THMC50 is not set # CONFIG_SENSORS_TMP102 is not set # CONFIG_SENSORS_TMP401 is not set # CONFIG_SENSORS_TMP421 is not set # CONFIG_SENSORS_VIA_CPUTEMP is not set # CONFIG_SENSORS_VIA686A is not set # CONFIG_SENSORS_VT1211 is not set # CONFIG_SENSORS_VT8231 is not set # CONFIG_SENSORS_W83781D is not set # CONFIG_SENSORS_W83791D is not set # CONFIG_SENSORS_W83792D is not set # CONFIG_SENSORS_W83793 is not set # CONFIG_SENSORS_W83795 is not set # CONFIG_SENSORS_W83L785TS is not set # CONFIG_SENSORS_W83L786NG is not set # CONFIG_SENSORS_W83627HF is not set # CONFIG_SENSORS_W83627EHF is not set # CONFIG_SENSORS_APPLESMC is not set # # ACPI drivers # # CONFIG_SENSORS_ACPI_POWER is not set # CONFIG_SENSORS_ATK0110 is not set CONFIG_THERMAL=y CONFIG_THERMAL_HWMON=y # CONFIG_WATCHDOG is not set CONFIG_SSB_POSSIBLE=y # # Sonics Silicon Backplane # # CONFIG_SSB is not set CONFIG_BCMA_POSSIBLE=y # # Broadcom specific AMBA # # CONFIG_BCMA is not set CONFIG_MFD_SUPPORT=y # CONFIG_MFD_CORE is not set # CONFIG_MFD_88PM860X is not set # CONFIG_MFD_SM501 is not set # CONFIG_HTC_PASIC3 is not set # CONFIG_TPS6105X is not set # CONFIG_TPS6507X is not set # CONFIG_TWL4030_CORE is not set # CONFIG_MFD_STMPE is not set # CONFIG_MFD_TC3589X is not set # CONFIG_MFD_TMIO is not set # CONFIG_PMIC_DA903X is not set # CONFIG_PMIC_ADP5520 is not set # CONFIG_MFD_MAX8925 is not set # CONFIG_MFD_MAX8997 is not set # CONFIG_MFD_MAX8998 is not set # CONFIG_MFD_WM8400 is not set # CONFIG_MFD_WM831X_I2C is not set # CONFIG_MFD_WM8350_I2C is not set # CONFIG_MFD_WM8994 is not set # CONFIG_MFD_PCF50633 is not set # CONFIG_ABX500_CORE is not set # CONFIG_MFD_CS5535 is not set # CONFIG_LPC_SCH is not set # CONFIG_MFD_RDC321X is not set # CONFIG_MFD_JANZ_CMODIO is not set # CONFIG_MFD_VX855 is not set # CONFIG_MFD_WL1273_CORE is not set # CONFIG_REGULATOR is not set # CONFIG_MEDIA_SUPPORT is not set # # Graphics support # CONFIG_AGP=y CONFIG_AGP_AMD64=y CONFIG_AGP_INTEL=y CONFIG_AGP_SIS=y CONFIG_AGP_VIA=y CONFIG_VGA_ARB=y CONFIG_VGA_ARB_MAX_GPUS=16 CONFIG_VGA_SWITCHEROO=y CONFIG_DRM=y CONFIG_DRM_KMS_HELPER=m CONFIG_DRM_TTM=m # CONFIG_DRM_TDFX is not set # CONFIG_DRM_R128 is not set CONFIG_DRM_RADEON=m CONFIG_DRM_RADEON_KMS=y CONFIG_DRM_I915=m CONFIG_DRM_I915_KMS=y CONFIG_DRM_MGA=m CONFIG_DRM_SIS=m CONFIG_DRM_VIA=m CONFIG_DRM_SAVAGE=m # CONFIG_STUB_POULSBO is not set # CONFIG_VGASTATE is not set CONFIG_VIDEO_OUTPUT_CONTROL=y CONFIG_FB=y # CONFIG_FIRMWARE_EDID is not set # CONFIG_FB_DDC is not set # CONFIG_FB_BOOT_VESA_SUPPORT is not set CONFIG_FB_CFB_FILLRECT=y CONFIG_FB_CFB_COPYAREA=y CONFIG_FB_CFB_IMAGEBLIT=y # CONFIG_FB_CFB_REV_PIXELS_IN_BYTE is not set CONFIG_FB_SYS_FILLRECT=m CONFIG_FB_SYS_COPYAREA=m CONFIG_FB_SYS_IMAGEBLIT=m # CONFIG_FB_FOREIGN_ENDIAN is not set CONFIG_FB_SYS_FOPS=m # CONFIG_FB_WMT_GE_ROPS is not set CONFIG_FB_DEFERRED_IO=y # CONFIG_FB_SVGALIB is not set # CONFIG_FB_MACMODES is not set # CONFIG_FB_BACKLIGHT is not set CONFIG_FB_MODE_HELPERS=y CONFIG_FB_TILEBLITTING=y # # Frame buffer hardware drivers # CONFIG_FB_CIRRUS=y # CONFIG_FB_PM2 is not set # CONFIG_FB_CYBER2000 is not set # CONFIG_FB_ARC is not set # CONFIG_FB_ASILIANT is not set # CONFIG_FB_IMSTT is not set # CONFIG_FB_VGA16 is not set # CONFIG_FB_UVESA is not set # CONFIG_FB_VESA is not set CONFIG_FB_EFI=y # CONFIG_FB_N411 is not set # CONFIG_FB_HGA is not set # CONFIG_FB_S1D13XXX is not set # CONFIG_FB_NVIDIA is not set # CONFIG_FB_RIVA is not set # CONFIG_FB_LE80578 is not set # CONFIG_FB_MATROX is not set # CONFIG_FB_RADEON is not set # CONFIG_FB_ATY128 is not set # CONFIG_FB_ATY is not set # CONFIG_FB_S3 is not set # CONFIG_FB_SAVAGE is not set # CONFIG_FB_SIS is not set # CONFIG_FB_VIA is not set # CONFIG_FB_NEOMAGIC is not set # CONFIG_FB_KYRO is not set # CONFIG_FB_3DFX is not set # CONFIG_FB_VOODOO1 is not set # CONFIG_FB_VT8623 is not set # CONFIG_FB_TRIDENT is not set # CONFIG_FB_ARK is not set # CONFIG_FB_PM3 is not set # CONFIG_FB_CARMINE is not set # CONFIG_FB_GEODE is not set # CONFIG_FB_UDL is not set # CONFIG_FB_VIRTUAL is not set CONFIG_XEN_FBDEV_FRONTEND=m # CONFIG_FB_METRONOME is not set # CONFIG_FB_MB862XX is not set # CONFIG_FB_BROADSHEET is not set CONFIG_BACKLIGHT_LCD_SUPPORT=y # CONFIG_LCD_CLASS_DEVICE is not set CONFIG_BACKLIGHT_CLASS_DEVICE=y CONFIG_BACKLIGHT_GENERIC=y # CONFIG_BACKLIGHT_PROGEAR is not set # CONFIG_BACKLIGHT_APPLE is not set # CONFIG_BACKLIGHT_SAHARA is not set # CONFIG_BACKLIGHT_ADP8860 is not set # CONFIG_BACKLIGHT_ADP8870 is not set # # Display device support # CONFIG_DISPLAY_SUPPORT=m # # Display hardware drivers # # # Console display driver support # CONFIG_VGA_CONSOLE=y # CONFIG_VGACON_SOFT_SCROLLBACK is not set CONFIG_DUMMY_CONSOLE=y CONFIG_FRAMEBUFFER_CONSOLE=m CONFIG_FRAMEBUFFER_CONSOLE_DETECT_PRIMARY=y # CONFIG_FRAMEBUFFER_CONSOLE_ROTATION is not set # CONFIG_FONTS is not set CONFIG_FONT_8x8=y CONFIG_FONT_8x16=y # CONFIG_LOGO is not set # CONFIG_SOUND is not set CONFIG_HID_SUPPORT=y CONFIG_HID=m CONFIG_HIDRAW=y # # USB Input Devices # CONFIG_USB_HID=m CONFIG_HID_PID=y CONFIG_USB_HIDDEV=y # # Special HID drivers # CONFIG_HID_A4TECH=m # CONFIG_HID_ACRUX is not set CONFIG_HID_APPLE=m CONFIG_HID_BELKIN=m CONFIG_HID_CHERRY=m CONFIG_HID_CHICONY=m CONFIG_HID_CYPRESS=m # CONFIG_HID_DRAGONRISE is not set # CONFIG_HID_EMS_FF is not set CONFIG_HID_EZKEY=m # CONFIG_HID_HOLTEK is not set # CONFIG_HID_KEYTOUCH is not set CONFIG_HID_KYE=m # CONFIG_HID_UCLOGIC is not set # CONFIG_HID_WALTOP is not set CONFIG_HID_GYRATION=m # CONFIG_HID_TWINHAN is not set CONFIG_HID_KENSINGTON=m # CONFIG_HID_LCPOWER is not set CONFIG_HID_LOGITECH=m CONFIG_LOGITECH_FF=y # CONFIG_LOGIRUMBLEPAD2_FF is not set # CONFIG_LOGIG940_FF is not set # CONFIG_LOGIWII_FF is not set CONFIG_HID_MICROSOFT=m CONFIG_HID_MONTEREY=m # CONFIG_HID_MULTITOUCH is not set CONFIG_HID_NTRIG=m # CONFIG_HID_ORTEK is not set CONFIG_HID_PANTHERLORD=m CONFIG_PANTHERLORD_FF=y CONFIG_HID_PETALYNX=m # CONFIG_HID_PICOLCD is not set # CONFIG_HID_QUANTA is not set # CONFIG_HID_ROCCAT is not set CONFIG_HID_SAMSUNG=m CONFIG_HID_SONY=m # CONFIG_HID_SPEEDLINK is not set CONFIG_HID_SUNPLUS=m # CONFIG_HID_GREENASIA is not set # CONFIG_HID_SMARTJOYPLUS is not set CONFIG_HID_TOPSEED=m # CONFIG_HID_THRUSTMASTER is not set # CONFIG_HID_ZEROPLUS is not set # CONFIG_HID_ZYDACRON is not set CONFIG_USB_SUPPORT=y CONFIG_USB_ARCH_HAS_HCD=y CONFIG_USB_ARCH_HAS_OHCI=y CONFIG_USB_ARCH_HAS_EHCI=y CONFIG_USB=y CONFIG_USB_DEBUG=y CONFIG_USB_ANNOUNCE_NEW_DEVICES=y # # Miscellaneous USB options # CONFIG_USB_DEVICEFS=y # CONFIG_USB_DEVICE_CLASS is not set # CONFIG_USB_DYNAMIC_MINORS is not set CONFIG_USB_MON=y # CONFIG_USB_WUSB is not set # CONFIG_USB_WUSB_CBAF is not set # # USB Host Controller Drivers # # CONFIG_USB_C67X00_HCD is not set CONFIG_USB_XHCI_HCD=y # CONFIG_USB_XHCI_HCD_DEBUGGING is not set CONFIG_USB_EHCI_HCD=y # CONFIG_USB_EHCI_ROOT_HUB_TT is not set # CONFIG_USB_EHCI_TT_NEWSCHED is not set # CONFIG_USB_OXU210HP_HCD is not set # CONFIG_USB_ISP116X_HCD is not set # CONFIG_USB_ISP1760_HCD is not set # CONFIG_USB_ISP1362_HCD is not set CONFIG_USB_OHCI_HCD=y # CONFIG_USB_OHCI_BIG_ENDIAN_DESC is not set # CONFIG_USB_OHCI_BIG_ENDIAN_MMIO is not set CONFIG_USB_OHCI_LITTLE_ENDIAN=y CONFIG_USB_UHCI_HCD=y # CONFIG_USB_SL811_HCD is not set # CONFIG_USB_R8A66597_HCD is not set # CONFIG_USB_WHCI_HCD is not set # CONFIG_USB_HWA_HCD is not set # # USB Device Class drivers # # CONFIG_USB_ACM is not set CONFIG_USB_PRINTER=y # CONFIG_USB_WDM is not set # CONFIG_USB_TMC is not set # # NOTE: USB_STORAGE depends on SCSI but BLK_DEV_SD may # # # also be needed; see USB_STORAGE Help for more info # CONFIG_USB_STORAGE=m # CONFIG_USB_STORAGE_DEBUG is not set # CONFIG_USB_STORAGE_REALTEK is not set # CONFIG_USB_STORAGE_DATAFAB is not set # CONFIG_USB_STORAGE_FREECOM is not set # CONFIG_USB_STORAGE_ISD200 is not set # CONFIG_USB_STORAGE_USBAT is not set # CONFIG_USB_STORAGE_SDDR09 is not set # CONFIG_USB_STORAGE_SDDR55 is not set # CONFIG_USB_STORAGE_JUMPSHOT is not set # CONFIG_USB_STORAGE_ALAUDA is not set # CONFIG_USB_STORAGE_ONETOUCH is not set # CONFIG_USB_STORAGE_KARMA is not set # CONFIG_USB_STORAGE_CYPRESS_ATACB is not set # CONFIG_USB_STORAGE_ENE_UB6250 is not set # CONFIG_USB_UAS is not set CONFIG_USB_LIBUSUAL=y # # USB Imaging devices # # CONFIG_USB_MDC800 is not set # CONFIG_USB_MICROTEK is not set # # USB port drivers # # CONFIG_USB_SERIAL is not set # # USB Miscellaneous drivers # # CONFIG_USB_EMI62 is not set # CONFIG_USB_EMI26 is not set # CONFIG_USB_ADUTUX is not set # CONFIG_USB_SEVSEG is not set # CONFIG_USB_RIO500 is not set # CONFIG_USB_LEGOTOWER is not set # CONFIG_USB_LCD is not set # CONFIG_USB_LED is not set # CONFIG_USB_CYPRESS_CY7C63 is not set # CONFIG_USB_CYTHERM is not set # CONFIG_USB_IDMOUSE is not set # CONFIG_USB_FTDI_ELAN is not set # CONFIG_USB_APPLEDISPLAY is not set # CONFIG_USB_SISUSBVGA is not set # CONFIG_USB_LD is not set # CONFIG_USB_TRANCEVIBRATOR is not set # CONFIG_USB_IOWARRIOR is not set # CONFIG_USB_TEST is not set # CONFIG_USB_ISIGHTFW is not set # CONFIG_USB_YUREX is not set # CONFIG_USB_GADGET is not set # # OTG and related infrastructure # # CONFIG_NOP_USB_XCEIV is not set # CONFIG_UWB is not set # CONFIG_MMC is not set # CONFIG_MEMSTICK is not set CONFIG_NEW_LEDS=y CONFIG_LEDS_CLASS=y # # LED drivers # # CONFIG_LEDS_LM3530 is not set # CONFIG_LEDS_ALIX2 is not set # CONFIG_LEDS_PCA9532 is not set # CONFIG_LEDS_LP3944 is not set # CONFIG_LEDS_LP5521 is not set # CONFIG_LEDS_LP5523 is not set # CONFIG_LEDS_CLEVO_MAIL is not set # CONFIG_LEDS_PCA955X is not set # CONFIG_LEDS_BD2802 is not set # CONFIG_LEDS_INTEL_SS4200 is not set # CONFIG_LEDS_DELL_NETBOOKS is not set # CONFIG_LEDS_TRIGGERS is not set # # LED Triggers # # CONFIG_ACCESSIBILITY is not set # CONFIG_INFINIBAND is not set CONFIG_EDAC=y # # Reporting subsystems # # CONFIG_EDAC_DEBUG is not set CONFIG_EDAC_DECODE_MCE=y # CONFIG_EDAC_MCE_INJ is not set # CONFIG_EDAC_MM_EDAC is not set CONFIG_RTC_LIB=y CONFIG_RTC_CLASS=y # CONFIG_RTC_HCTOSYS is not set # CONFIG_RTC_DEBUG is not set # # RTC interfaces # CONFIG_RTC_INTF_SYSFS=y CONFIG_RTC_INTF_PROC=y CONFIG_RTC_INTF_DEV=y # CONFIG_RTC_INTF_DEV_UIE_EMUL is not set # CONFIG_RTC_DRV_TEST is not set # # I2C RTC drivers # # CONFIG_RTC_DRV_DS1307 is not set # CONFIG_RTC_DRV_DS1374 is not set # CONFIG_RTC_DRV_DS1672 is not set # CONFIG_RTC_DRV_DS3232 is not set # CONFIG_RTC_DRV_MAX6900 is not set # CONFIG_RTC_DRV_RS5C372 is not set # CONFIG_RTC_DRV_ISL1208 is not set # CONFIG_RTC_DRV_ISL12022 is not set # CONFIG_RTC_DRV_X1205 is not set # CONFIG_RTC_DRV_PCF8563 is not set # CONFIG_RTC_DRV_PCF8583 is not set # CONFIG_RTC_DRV_M41T80 is not set # CONFIG_RTC_DRV_BQ32K is not set # CONFIG_RTC_DRV_S35390A is not set # CONFIG_RTC_DRV_FM3130 is not set # CONFIG_RTC_DRV_RX8581 is not set # CONFIG_RTC_DRV_RX8025 is not set # CONFIG_RTC_DRV_EM3027 is not set # CONFIG_RTC_DRV_RV3029C2 is not set # # SPI RTC drivers # # # Platform RTC drivers # CONFIG_RTC_DRV_CMOS=y # CONFIG_RTC_DRV_DS1286 is not set # CONFIG_RTC_DRV_DS1511 is not set # CONFIG_RTC_DRV_DS1553 is not set # CONFIG_RTC_DRV_DS1742 is not set # CONFIG_RTC_DRV_STK17TA8 is not set # CONFIG_RTC_DRV_M48T86 is not set # CONFIG_RTC_DRV_M48T35 is not set # CONFIG_RTC_DRV_M48T59 is not set # CONFIG_RTC_DRV_MSM6242 is not set # CONFIG_RTC_DRV_BQ4802 is not set # CONFIG_RTC_DRV_RP5C01 is not set # CONFIG_RTC_DRV_V3020 is not set # # on-CPU RTC drivers # CONFIG_DMADEVICES=y # CONFIG_DMADEVICES_DEBUG is not set # # DMA Devices # # CONFIG_INTEL_MID_DMAC is not set # CONFIG_INTEL_IOATDMA is not set # CONFIG_TIMB_DMA is not set # CONFIG_PCH_DMA is not set # CONFIG_AUXDISPLAY is not set # CONFIG_UIO is not set CONFIG_VIRTIO=y CONFIG_VIRTIO_RING=y # # Virtio drivers # CONFIG_VIRTIO_PCI=m CONFIG_VIRTIO_BALLOON=y # # Xen driver support # CONFIG_XEN_BALLOON=y CONFIG_XEN_SELFBALLOONING=y CONFIG_XEN_SCRUB_PAGES=y CONFIG_XEN_DEV_EVTCHN=m CONFIG_XEN_BACKEND=y CONFIG_XENFS=m CONFIG_XEN_COMPAT_XENFS=y CONFIG_XEN_SYS_HYPERVISOR=y CONFIG_XEN_XENBUS_FRONTEND=y CONFIG_XEN_GNTDEV=y CONFIG_XEN_GRANT_DEV_ALLOC=y CONFIG_XEN_PLATFORM_PCI=m CONFIG_SWIOTLB_XEN=y CONFIG_XEN_TMEM=y CONFIG_XEN_PCIDEV_BACKEND=y CONFIG_STAGING=y # CONFIG_ET131X is not set # CONFIG_SLICOSS is not set CONFIG_USBIP_CORE=m CONFIG_USBIP_VHCI_HCD=m CONFIG_USBIP_HOST=m # CONFIG_USBIP_DEBUG is not set # CONFIG_ECHO is not set # CONFIG_BRCMUTIL is not set # CONFIG_COMEDI is not set # CONFIG_ASUS_OLED is not set # CONFIG_RTS_PSTOR is not set # CONFIG_TRANZPORT is not set # CONFIG_POHMELFS is not set # CONFIG_IDE_PHISON is not set # CONFIG_DRM_VMWGFX is not set CONFIG_DRM_NOUVEAU=m # CONFIG_DRM_NOUVEAU_BACKLIGHT is not set CONFIG_DRM_NOUVEAU_DEBUG=y # # I2C encoder or helper chips # CONFIG_DRM_I2C_CH7006=m CONFIG_DRM_I2C_SIL164=m # CONFIG_HYPERV is not set # CONFIG_VME_BUS is not set # CONFIG_DX_SEP is not set # CONFIG_IIO is not set CONFIG_XVMALLOC=y CONFIG_ZRAM=y # CONFIG_ZRAM_DEBUG is not set CONFIG_ZCACHE=y # CONFIG_FB_SM7XX is not set # CONFIG_CRYSTALHD is not set # CONFIG_FB_XGI is not set # CONFIG_ACPI_QUICKSTART is not set # CONFIG_USB_ENESTORAGE is not set # CONFIG_BCM_WIMAX is not set # CONFIG_FT1000 is not set # # Speakup console speech # # CONFIG_SPEAKUP is not set # CONFIG_TOUCHSCREEN_SYNAPTICS_I2C_RMI4 is not set # CONFIG_DRM_PSB is not set # CONFIG_ALTERA_STAPL is not set # CONFIG_INTEL_MEI is not set CONFIG_X86_PLATFORM_DEVICES=y # CONFIG_ACER_WMI is not set # CONFIG_ACERHDF is not set # CONFIG_ASUS_LAPTOP is not set # CONFIG_DELL_WMI is not set # CONFIG_DELL_WMI_AIO is not set # CONFIG_FUJITSU_LAPTOP is not set # CONFIG_HP_ACCEL is not set # CONFIG_HP_WMI is not set # CONFIG_MSI_LAPTOP is not set # CONFIG_PANASONIC_LAPTOP is not set # CONFIG_COMPAL_LAPTOP is not set # CONFIG_SONY_LAPTOP is not set # CONFIG_IDEAPAD_LAPTOP is not set # CONFIG_THINKPAD_ACPI is not set # CONFIG_SENSORS_HDAPS is not set # CONFIG_INTEL_MENLOW is not set CONFIG_EEEPC_LAPTOP=y # CONFIG_ASUS_WMI is not set CONFIG_ACPI_WMI=m # CONFIG_MSI_WMI is not set # CONFIG_ACPI_ASUS is not set # CONFIG_TOPSTAR_LAPTOP is not set # CONFIG_ACPI_TOSHIBA is not set # CONFIG_TOSHIBA_BT_RFKILL is not set # CONFIG_ACPI_CMPC is not set # CONFIG_INTEL_IPS is not set # CONFIG_IBM_RTL is not set # CONFIG_XO15_EBOOK is not set # CONFIG_SAMSUNG_LAPTOP is not set CONFIG_MXM_WMI=m # CONFIG_INTEL_OAKTRAIL is not set # CONFIG_SAMSUNG_Q10 is not set CONFIG_CLKEVT_I8253=y CONFIG_I8253_LOCK=y CONFIG_CLKBLD_I8253=y CONFIG_IOMMU_API=y CONFIG_IOMMU_SUPPORT=y CONFIG_AMD_IOMMU=y CONFIG_AMD_IOMMU_STATS=y CONFIG_DMAR=y # CONFIG_DMAR_DEFAULT_ON is not set CONFIG_DMAR_FLOPPY_WA=y # CONFIG_INTR_REMAP is not set # CONFIG_VIRT_DRIVERS is not set # # Firmware Drivers # # CONFIG_EDD is not set CONFIG_FIRMWARE_MEMMAP=y CONFIG_EFI_VARS=y # CONFIG_DELL_RBU is not set # CONFIG_DCDBAS is not set CONFIG_DMIID=y # CONFIG_DMI_SYSFS is not set CONFIG_ISCSI_IBFT_FIND=y CONFIG_ISCSI_IBFT=m # CONFIG_SIGMA is not set # CONFIG_GOOGLE_FIRMWARE is not set # # File systems # CONFIG_EXT2_FS=m CONFIG_EXT2_FS_XATTR=y CONFIG_EXT2_FS_POSIX_ACL=y CONFIG_EXT2_FS_SECURITY=y CONFIG_EXT2_FS_XIP=y CONFIG_EXT3_FS=m # CONFIG_EXT3_DEFAULTS_TO_ORDERED is not set CONFIG_EXT3_FS_XATTR=y CONFIG_EXT3_FS_POSIX_ACL=y CONFIG_EXT3_FS_SECURITY=y CONFIG_EXT4_FS=m CONFIG_EXT4_FS_XATTR=y CONFIG_EXT4_FS_POSIX_ACL=y CONFIG_EXT4_FS_SECURITY=y # CONFIG_EXT4_DEBUG is not set CONFIG_FS_XIP=y CONFIG_JBD=m # CONFIG_JBD_DEBUG is not set CONFIG_JBD2=m # CONFIG_JBD2_DEBUG is not set CONFIG_FS_MBCACHE=m CONFIG_REISERFS_FS=m # CONFIG_REISERFS_CHECK is not set CONFIG_REISERFS_PROC_INFO=y CONFIG_REISERFS_FS_XATTR=y CONFIG_REISERFS_FS_POSIX_ACL=y CONFIG_REISERFS_FS_SECURITY=y CONFIG_JFS_FS=m CONFIG_JFS_POSIX_ACL=y CONFIG_JFS_SECURITY=y # CONFIG_JFS_DEBUG is not set CONFIG_JFS_STATISTICS=y CONFIG_XFS_FS=m # CONFIG_XFS_QUOTA is not set CONFIG_XFS_POSIX_ACL=y # CONFIG_XFS_RT is not set # CONFIG_XFS_DEBUG is not set # CONFIG_GFS2_FS is not set # CONFIG_OCFS2_FS is not set # CONFIG_BTRFS_FS is not set # CONFIG_NILFS2_FS is not set CONFIG_FS_POSIX_ACL=y CONFIG_EXPORTFS=m CONFIG_FILE_LOCKING=y CONFIG_FSNOTIFY=y CONFIG_DNOTIFY=y CONFIG_INOTIFY_USER=y # CONFIG_FANOTIFY is not set CONFIG_QUOTA=y CONFIG_QUOTA_NETLINK_INTERFACE=y # CONFIG_PRINT_QUOTA_WARNING is not set # CONFIG_QUOTA_DEBUG is not set CONFIG_QUOTA_TREE=y # CONFIG_QFMT_V1 is not set CONFIG_QFMT_V2=y CONFIG_QUOTACTL=y CONFIG_QUOTACTL_COMPAT=y CONFIG_AUTOFS4_FS=y # CONFIG_FUSE_FS is not set CONFIG_GENERIC_ACL=y # # Caches # # CONFIG_FSCACHE is not set # # CD-ROM/DVD Filesystems # CONFIG_ISO9660_FS=y CONFIG_JOLIET=y CONFIG_ZISOFS=y # CONFIG_UDF_FS is not set # # DOS/FAT/NT Filesystems # CONFIG_FAT_FS=y CONFIG_MSDOS_FS=y CONFIG_VFAT_FS=y CONFIG_FAT_DEFAULT_CODEPAGE=437 CONFIG_FAT_DEFAULT_IOCHARSET="iso8859-1" CONFIG_NTFS_FS=y # CONFIG_NTFS_DEBUG is not set CONFIG_NTFS_RW=y # # Pseudo filesystems # CONFIG_PROC_FS=y CONFIG_PROC_KCORE=y CONFIG_PROC_VMCORE=y CONFIG_PROC_SYSCTL=y CONFIG_PROC_PAGE_MONITOR=y CONFIG_SYSFS=y CONFIG_TMPFS=y CONFIG_TMPFS_POSIX_ACL=y CONFIG_TMPFS_XATTR=y CONFIG_HUGETLBFS=y CONFIG_HUGETLB_PAGE=y CONFIG_CONFIGFS_FS=m CONFIG_MISC_FILESYSTEMS=y # CONFIG_ADFS_FS is not set # CONFIG_AFFS_FS is not set # CONFIG_ECRYPT_FS is not set # CONFIG_HFS_FS is not set # CONFIG_HFSPLUS_FS is not set # CONFIG_BEFS_FS is not set # CONFIG_BFS_FS is not set # CONFIG_EFS_FS is not set # CONFIG_LOGFS is not set # CONFIG_CRAMFS is not set # CONFIG_SQUASHFS is not set # CONFIG_VXFS_FS is not set # CONFIG_MINIX_FS is not set # CONFIG_OMFS_FS is not set # CONFIG_HPFS_FS is not set # CONFIG_QNX4FS_FS is not set # CONFIG_ROMFS_FS is not set # CONFIG_PSTORE is not set # CONFIG_SYSV_FS is not set # CONFIG_UFS_FS is not set CONFIG_NETWORK_FILESYSTEMS=y CONFIG_NFS_FS=y CONFIG_NFS_V3=y CONFIG_NFS_V3_ACL=y CONFIG_NFS_V4=y # CONFIG_NFS_V4_1 is not set CONFIG_ROOT_NFS=y # CONFIG_NFS_USE_LEGACY_DNS is not set CONFIG_NFS_USE_KERNEL_DNS=y # CONFIG_NFS_USE_NEW_IDMAPPER is not set # CONFIG_NFSD is not set CONFIG_LOCKD=y CONFIG_LOCKD_V4=y CONFIG_NFS_ACL_SUPPORT=y CONFIG_NFS_COMMON=y CONFIG_SUNRPC=y CONFIG_SUNRPC_GSS=y # CONFIG_CEPH_FS is not set # CONFIG_CIFS is not set # CONFIG_NCP_FS is not set # CONFIG_CODA_FS is not set # CONFIG_AFS_FS is not set # # Partition Types # CONFIG_PARTITION_ADVANCED=y # CONFIG_ACORN_PARTITION is not set CONFIG_OSF_PARTITION=y CONFIG_AMIGA_PARTITION=y # CONFIG_ATARI_PARTITION is not set CONFIG_MAC_PARTITION=y CONFIG_MSDOS_PARTITION=y CONFIG_BSD_DISKLABEL=y CONFIG_MINIX_SUBPARTITION=y CONFIG_SOLARIS_X86_PARTITION=y CONFIG_UNIXWARE_DISKLABEL=y # CONFIG_LDM_PARTITION is not set CONFIG_SGI_PARTITION=y # CONFIG_ULTRIX_PARTITION is not set CONFIG_SUN_PARTITION=y CONFIG_KARMA_PARTITION=y CONFIG_EFI_PARTITION=y # CONFIG_SYSV68_PARTITION is not set CONFIG_NLS=y CONFIG_NLS_DEFAULT="utf8" CONFIG_NLS_CODEPAGE_437=y # CONFIG_NLS_CODEPAGE_737 is not set # CONFIG_NLS_CODEPAGE_775 is not set # CONFIG_NLS_CODEPAGE_850 is not set # CONFIG_NLS_CODEPAGE_852 is not set # CONFIG_NLS_CODEPAGE_855 is not set # CONFIG_NLS_CODEPAGE_857 is not set # CONFIG_NLS_CODEPAGE_860 is not set # CONFIG_NLS_CODEPAGE_861 is not set # CONFIG_NLS_CODEPAGE_862 is not set # CONFIG_NLS_CODEPAGE_863 is not set # CONFIG_NLS_CODEPAGE_864 is not set # CONFIG_NLS_CODEPAGE_865 is not set # CONFIG_NLS_CODEPAGE_866 is not set # CONFIG_NLS_CODEPAGE_869 is not set # CONFIG_NLS_CODEPAGE_936 is not set # CONFIG_NLS_CODEPAGE_950 is not set # CONFIG_NLS_CODEPAGE_932 is not set # CONFIG_NLS_CODEPAGE_949 is not set # CONFIG_NLS_CODEPAGE_874 is not set # CONFIG_NLS_ISO8859_8 is not set # CONFIG_NLS_CODEPAGE_1250 is not set # CONFIG_NLS_CODEPAGE_1251 is not set CONFIG_NLS_ASCII=y CONFIG_NLS_ISO8859_1=y # CONFIG_NLS_ISO8859_2 is not set # CONFIG_NLS_ISO8859_3 is not set # CONFIG_NLS_ISO8859_4 is not set # CONFIG_NLS_ISO8859_5 is not set # CONFIG_NLS_ISO8859_6 is not set # CONFIG_NLS_ISO8859_7 is not set # CONFIG_NLS_ISO8859_9 is not set # CONFIG_NLS_ISO8859_13 is not set # CONFIG_NLS_ISO8859_14 is not set # CONFIG_NLS_ISO8859_15 is not set # CONFIG_NLS_KOI8_R is not set # CONFIG_NLS_KOI8_U is not set CONFIG_NLS_UTF8=y # CONFIG_DLM is not set # # Kernel hacking # CONFIG_TRACE_IRQFLAGS_SUPPORT=y CONFIG_PRINTK_TIME=y CONFIG_DEFAULT_MESSAGE_LOGLEVEL=4 # CONFIG_ENABLE_WARN_DEPRECATED is not set CONFIG_ENABLE_MUST_CHECK=y CONFIG_FRAME_WARN=2048 CONFIG_MAGIC_SYSRQ=y # CONFIG_STRIP_ASM_SYMS is not set # CONFIG_UNUSED_SYMBOLS is not set CONFIG_DEBUG_FS=y # CONFIG_HEADERS_CHECK is not set # CONFIG_DEBUG_SECTION_MISMATCH is not set CONFIG_DEBUG_KERNEL=y CONFIG_DEBUG_SHIRQ=y CONFIG_LOCKUP_DETECTOR=y CONFIG_HARDLOCKUP_DETECTOR=y # CONFIG_BOOTPARAM_HARDLOCKUP_PANIC is not set CONFIG_BOOTPARAM_HARDLOCKUP_PANIC_VALUE=0 # CONFIG_BOOTPARAM_SOFTLOCKUP_PANIC is not set CONFIG_BOOTPARAM_SOFTLOCKUP_PANIC_VALUE=0 # CONFIG_DETECT_HUNG_TASK is not set # CONFIG_SCHED_DEBUG is not set CONFIG_SCHEDSTATS=y CONFIG_TIMER_STATS=y # CONFIG_DEBUG_OBJECTS is not set # CONFIG_SLUB_DEBUG_ON is not set # CONFIG_SLUB_STATS is not set CONFIG_DEBUG_KMEMLEAK=y CONFIG_DEBUG_KMEMLEAK_EARLY_LOG_SIZE=400 # CONFIG_DEBUG_KMEMLEAK_TEST is not set # CONFIG_DEBUG_KMEMLEAK_DEFAULT_OFF is not set CONFIG_DEBUG_PREEMPT=y # CONFIG_DEBUG_RT_MUTEXES is not set # CONFIG_RT_MUTEX_TESTER is not set # CONFIG_DEBUG_SPINLOCK is not set # CONFIG_DEBUG_MUTEXES is not set # CONFIG_DEBUG_LOCK_ALLOC is not set # CONFIG_PROVE_LOCKING is not set # CONFIG_SPARSE_RCU_POINTER is not set # CONFIG_LOCK_STAT is not set CONFIG_DEBUG_ATOMIC_SLEEP=y # CONFIG_DEBUG_LOCKING_API_SELFTESTS is not set CONFIG_STACKTRACE=y CONFIG_DEBUG_STACK_USAGE=y # CONFIG_DEBUG_KOBJECT is not set CONFIG_DEBUG_BUGVERBOSE=y CONFIG_DEBUG_INFO=y CONFIG_DEBUG_INFO_REDUCED=y # CONFIG_DEBUG_VM is not set # CONFIG_DEBUG_VIRTUAL is not set # CONFIG_DEBUG_WRITECOUNT is not set CONFIG_DEBUG_MEMORY_INIT=y # CONFIG_DEBUG_LIST is not set # CONFIG_TEST_LIST_SORT is not set # CONFIG_DEBUG_SG is not set # CONFIG_DEBUG_NOTIFIERS is not set # CONFIG_DEBUG_CREDENTIALS is not set CONFIG_ARCH_WANT_FRAME_POINTERS=y CONFIG_FRAME_POINTER=y # CONFIG_BOOT_PRINTK_DELAY is not set # CONFIG_RCU_TORTURE_TEST is not set CONFIG_RCU_CPU_STALL_TIMEOUT=60 CONFIG_RCU_CPU_STALL_VERBOSE=y # CONFIG_KPROBES_SANITY_TEST is not set # CONFIG_BACKTRACE_SELF_TEST is not set # CONFIG_DEBUG_BLOCK_EXT_DEVT is not set # CONFIG_DEBUG_FORCE_WEAK_PER_CPU is not set # CONFIG_DEBUG_PER_CPU_MAPS is not set # CONFIG_LKDTM is not set # CONFIG_CPU_NOTIFIER_ERROR_INJECT is not set CONFIG_FAULT_INJECTION=y # CONFIG_FAILSLAB is not set # CONFIG_FAIL_PAGE_ALLOC is not set CONFIG_FAIL_MAKE_REQUEST=y # CONFIG_FAIL_IO_TIMEOUT is not set CONFIG_FAULT_INJECTION_DEBUG_FS=y # CONFIG_LATENCYTOP is not set CONFIG_SYSCTL_SYSCALL_CHECK=y # CONFIG_DEBUG_PAGEALLOC is not set CONFIG_USER_STACKTRACE_SUPPORT=y CONFIG_NOP_TRACER=y CONFIG_HAVE_FTRACE_NMI_ENTER=y CONFIG_HAVE_FUNCTION_TRACER=y CONFIG_HAVE_FUNCTION_GRAPH_TRACER=y CONFIG_HAVE_FUNCTION_GRAPH_FP_TEST=y CONFIG_HAVE_FUNCTION_TRACE_MCOUNT_TEST=y CONFIG_HAVE_DYNAMIC_FTRACE=y CONFIG_HAVE_FTRACE_MCOUNT_RECORD=y CONFIG_HAVE_SYSCALL_TRACEPOINTS=y CONFIG_HAVE_C_RECORDMCOUNT=y CONFIG_RING_BUFFER=y CONFIG_FTRACE_NMI_ENTER=y CONFIG_EVENT_TRACING=y CONFIG_EVENT_POWER_TRACING_DEPRECATED=y CONFIG_CONTEXT_SWITCH_TRACER=y CONFIG_TRACING=y CONFIG_GENERIC_TRACER=y CONFIG_TRACING_SUPPORT=y CONFIG_FTRACE=y CONFIG_FUNCTION_TRACER=y CONFIG_FUNCTION_GRAPH_TRACER=y # CONFIG_IRQSOFF_TRACER is not set # CONFIG_PREEMPT_TRACER is not set # CONFIG_SCHED_TRACER is not set # CONFIG_FTRACE_SYSCALLS is not set CONFIG_BRANCH_PROFILE_NONE=y # CONFIG_PROFILE_ANNOTATED_BRANCHES is not set # CONFIG_PROFILE_ALL_BRANCHES is not set # CONFIG_STACK_TRACER is not set CONFIG_BLK_DEV_IO_TRACE=y CONFIG_KPROBE_EVENT=y CONFIG_DYNAMIC_FTRACE=y # CONFIG_FUNCTION_PROFILER is not set CONFIG_FTRACE_MCOUNT_RECORD=y # CONFIG_FTRACE_STARTUP_TEST is not set # CONFIG_MMIOTRACE is not set # CONFIG_RING_BUFFER_BENCHMARK is not set CONFIG_PROVIDE_OHCI1394_DMA_INIT=y CONFIG_DYNAMIC_DEBUG=y CONFIG_DMA_API_DEBUG=y # CONFIG_ATOMIC64_SELFTEST is not set # CONFIG_ASYNC_RAID6_TEST is not set # CONFIG_SAMPLES is not set CONFIG_HAVE_ARCH_KGDB=y CONFIG_KGDB=y CONFIG_KGDB_SERIAL_CONSOLE=y # CONFIG_KGDB_TESTS is not set # CONFIG_KGDB_LOW_LEVEL_TRAP is not set # CONFIG_KGDB_KDB is not set CONFIG_HAVE_ARCH_KMEMCHECK=y # CONFIG_TEST_KSTRTOX is not set # CONFIG_STRICT_DEVMEM is not set CONFIG_X86_VERBOSE_BOOTUP=y CONFIG_EARLY_PRINTK=y CONFIG_EARLY_PRINTK_DBGP=y CONFIG_DEBUG_STACKOVERFLOW=y CONFIG_X86_PTDUMP=y CONFIG_DEBUG_RODATA=y CONFIG_DEBUG_RODATA_TEST=y CONFIG_DEBUG_SET_MODULE_RONX=y CONFIG_DEBUG_NX_TEST=m # CONFIG_IOMMU_DEBUG is not set # CONFIG_IOMMU_STRESS is not set CONFIG_HAVE_MMIOTRACE_SUPPORT=y # CONFIG_X86_DECODER_SELFTEST is not set CONFIG_IO_DELAY_TYPE_0X80=0 CONFIG_IO_DELAY_TYPE_0XED=1 CONFIG_IO_DELAY_TYPE_UDELAY=2 CONFIG_IO_DELAY_TYPE_NONE=3 CONFIG_IO_DELAY_0X80=y # CONFIG_IO_DELAY_0XED is not set # CONFIG_IO_DELAY_UDELAY is not set # CONFIG_IO_DELAY_NONE is not set CONFIG_DEFAULT_IO_DELAY_TYPE=0 CONFIG_DEBUG_BOOT_PARAMS=y # CONFIG_CPA_DEBUG is not set CONFIG_OPTIMIZE_INLINING=y # CONFIG_DEBUG_STRICT_USER_COPY_CHECKS is not set # # Security options # CONFIG_KEYS=y CONFIG_KEYS_DEBUG_PROC_KEYS=y # CONFIG_SECURITY_DMESG_RESTRICT is not set CONFIG_SECURITY=y # CONFIG_SECURITYFS is not set CONFIG_SECURITY_NETWORK=y # CONFIG_SECURITY_NETWORK_XFRM is not set # CONFIG_SECURITY_PATH is not set # CONFIG_INTEL_TXT is not set CONFIG_LSM_MMAP_MIN_ADDR=65534 CONFIG_SECURITY_SELINUX=y CONFIG_SECURITY_SELINUX_BOOTPARAM=y CONFIG_SECURITY_SELINUX_BOOTPARAM_VALUE=1 CONFIG_SECURITY_SELINUX_DISABLE=y CONFIG_SECURITY_SELINUX_DEVELOP=y CONFIG_SECURITY_SELINUX_AVC_STATS=y CONFIG_SECURITY_SELINUX_CHECKREQPROT_VALUE=1 # CONFIG_SECURITY_SELINUX_POLICYDB_VERSION_MAX is not set # CONFIG_SECURITY_SMACK is not set # CONFIG_SECURITY_TOMOYO is not set # CONFIG_SECURITY_APPARMOR is not set # CONFIG_IMA is not set CONFIG_DEFAULT_SECURITY_SELINUX=y # CONFIG_DEFAULT_SECURITY_DAC is not set CONFIG_DEFAULT_SECURITY="selinux" CONFIG_XOR_BLOCKS=m CONFIG_ASYNC_CORE=m CONFIG_ASYNC_MEMCPY=m CONFIG_ASYNC_XOR=m CONFIG_ASYNC_PQ=m CONFIG_ASYNC_RAID6_RECOV=m CONFIG_CRYPTO=y # # Crypto core or helper # CONFIG_CRYPTO_ALGAPI=y CONFIG_CRYPTO_ALGAPI2=y CONFIG_CRYPTO_AEAD=y CONFIG_CRYPTO_AEAD2=y CONFIG_CRYPTO_BLKCIPHER=y CONFIG_CRYPTO_BLKCIPHER2=y CONFIG_CRYPTO_HASH=y CONFIG_CRYPTO_HASH2=y CONFIG_CRYPTO_RNG2=y CONFIG_CRYPTO_PCOMP=y CONFIG_CRYPTO_PCOMP2=y CONFIG_CRYPTO_MANAGER=y CONFIG_CRYPTO_MANAGER2=y CONFIG_CRYPTO_MANAGER_DISABLE_TESTS=y # CONFIG_CRYPTO_GF128MUL is not set # CONFIG_CRYPTO_NULL is not set # CONFIG_CRYPTO_PCRYPT is not set CONFIG_CRYPTO_WORKQUEUE=y # CONFIG_CRYPTO_CRYPTD is not set CONFIG_CRYPTO_AUTHENC=y # CONFIG_CRYPTO_TEST is not set # # Authenticated Encryption with Associated Data # # CONFIG_CRYPTO_CCM is not set # CONFIG_CRYPTO_GCM is not set # CONFIG_CRYPTO_SEQIV is not set # # Block modes # CONFIG_CRYPTO_CBC=y # CONFIG_CRYPTO_CTR is not set # CONFIG_CRYPTO_CTS is not set # CONFIG_CRYPTO_ECB is not set # CONFIG_CRYPTO_LRW is not set # CONFIG_CRYPTO_PCBC is not set # CONFIG_CRYPTO_XTS is not set # # Hash modes # CONFIG_CRYPTO_HMAC=y # CONFIG_CRYPTO_XCBC is not set # CONFIG_CRYPTO_VMAC is not set # # Digest # CONFIG_CRYPTO_CRC32C=m CONFIG_CRYPTO_CRC32C_INTEL=m # CONFIG_CRYPTO_GHASH is not set # CONFIG_CRYPTO_MD4 is not set CONFIG_CRYPTO_MD5=y # CONFIG_CRYPTO_MICHAEL_MIC is not set # CONFIG_CRYPTO_RMD128 is not set # CONFIG_CRYPTO_RMD160 is not set # CONFIG_CRYPTO_RMD256 is not set # CONFIG_CRYPTO_RMD320 is not set CONFIG_CRYPTO_SHA1=y # CONFIG_CRYPTO_SHA256 is not set # CONFIG_CRYPTO_SHA512 is not set # CONFIG_CRYPTO_TGR192 is not set # CONFIG_CRYPTO_WP512 is not set # CONFIG_CRYPTO_GHASH_CLMUL_NI_INTEL is not set # # Ciphers # # CONFIG_CRYPTO_AES is not set # CONFIG_CRYPTO_AES_X86_64 is not set # CONFIG_CRYPTO_AES_NI_INTEL is not set # CONFIG_CRYPTO_ANUBIS is not set # CONFIG_CRYPTO_ARC4 is not set # CONFIG_CRYPTO_BLOWFISH is not set # CONFIG_CRYPTO_CAMELLIA is not set # CONFIG_CRYPTO_CAST5 is not set # CONFIG_CRYPTO_CAST6 is not set CONFIG_CRYPTO_DES=y # CONFIG_CRYPTO_FCRYPT is not set # CONFIG_CRYPTO_KHAZAD is not set # CONFIG_CRYPTO_SALSA20 is not set # CONFIG_CRYPTO_SALSA20_X86_64 is not set # CONFIG_CRYPTO_SEED is not set # CONFIG_CRYPTO_SERPENT is not set # CONFIG_CRYPTO_TEA is not set # CONFIG_CRYPTO_TWOFISH is not set # CONFIG_CRYPTO_TWOFISH_X86_64 is not set # # Compression # # CONFIG_CRYPTO_DEFLATE is not set CONFIG_CRYPTO_ZLIB=y # CONFIG_CRYPTO_LZO is not set # # Random Number Generation # # CONFIG_CRYPTO_ANSI_CPRNG is not set # CONFIG_CRYPTO_USER_API_HASH is not set # CONFIG_CRYPTO_USER_API_SKCIPHER is not set CONFIG_CRYPTO_HW=y # CONFIG_CRYPTO_DEV_PADLOCK is not set # CONFIG_CRYPTO_DEV_HIFN_795X is not set CONFIG_HAVE_KVM=y CONFIG_HAVE_KVM_IRQCHIP=y CONFIG_HAVE_KVM_EVENTFD=y CONFIG_KVM_APIC_ARCHITECTURE=y CONFIG_KVM_MMIO=y CONFIG_KVM_ASYNC_PF=y CONFIG_VIRTUALIZATION=y CONFIG_KVM=y CONFIG_KVM_INTEL=m CONFIG_KVM_AMD=m # CONFIG_KVM_MMU_AUDIT is not set CONFIG_VHOST_NET=y CONFIG_BINARY_PRINTF=y # # Library routines # CONFIG_RAID6_PQ=m CONFIG_BITREVERSE=y CONFIG_GENERIC_FIND_FIRST_BIT=y CONFIG_CRC_CCITT=m CONFIG_CRC16=m CONFIG_CRC_T10DIF=y # CONFIG_CRC_ITU_T is not set CONFIG_CRC32=y # CONFIG_CRC7 is not set CONFIG_LIBCRC32C=m # CONFIG_CRC8 is not set CONFIG_ZLIB_INFLATE=y CONFIG_ZLIB_DEFLATE=y CONFIG_LZO_COMPRESS=y CONFIG_LZO_DECOMPRESS=y CONFIG_XZ_DEC=y CONFIG_XZ_DEC_X86=y CONFIG_XZ_DEC_POWERPC=y CONFIG_XZ_DEC_IA64=y CONFIG_XZ_DEC_ARM=y CONFIG_XZ_DEC_ARMTHUMB=y CONFIG_XZ_DEC_SPARC=y CONFIG_XZ_DEC_BCJ=y # CONFIG_XZ_DEC_TEST is not set CONFIG_DECOMPRESS_GZIP=y CONFIG_DECOMPRESS_BZIP2=y CONFIG_DECOMPRESS_LZMA=y CONFIG_DECOMPRESS_XZ=y CONFIG_DECOMPRESS_LZO=y CONFIG_HAS_IOMEM=y CONFIG_HAS_IOPORT=y CONFIG_HAS_DMA=y CONFIG_CHECK_SIGNATURE=y CONFIG_CPUMASK_OFFSTACK=y CONFIG_CPU_RMAP=y CONFIG_NLATTR=y # CONFIG_AVERAGE is not set # CONFIG_CORDIC is not set --M9NhX3UHpAaciwkO Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel --M9NhX3UHpAaciwkO-- From xen-devel-bounces@lists.xensource.com Mon Sep 26 07:29:03 2011 Return-path: <xen-devel-bounces@lists.xensource.com> Envelope-to: www-data@lists.xensource.com Delivery-date: Mon, 26 Sep 2011 07:29:03 -0700 Received: from localhost ([127.0.0.1] helo=lists.colo.xensource.com) by lists.xensource.com with esmtp (Exim 4.43) id 1R8CB5-0003ZO-No; Mon, 26 Sep 2011 07:29:03 -0700 Received: from mail27.messagelabs.com ([193.109.254.147]) by lists.xensource.com with esmtp (Exim 4.43) id 1R8CAX-0003Mg-IA for xen-devel@lists.xensource.com; Mon, 26 Sep 2011 07:28:29 -0700 X-Env-Sender: konrad@oracle.com X-Msg-Ref: server-10.tower-27.messagelabs.com!1317047284!37281554!1 X-Originating-IP: [141.146.126.227] X-StarScan-Version: 6.4.1; banners=-,-,- X-VirusChecked: Checked Received: (qmail 21776 invoked from network); 26 Sep 2011 14:28:05 -0000 Received: from acsinet15.oracle.com (HELO acsinet15.oracle.com) (141.146.126.227) by server-10.tower-27.messagelabs.com with DHE-RSA-AES256-SHA encrypted SMTP; 26 Sep 2011 14:28:05 -0000 Received: from ucsinet23.oracle.com (ucsinet23.oracle.com [156.151.31.71]) by acsinet15.oracle.com (Switch-3.4.4/Switch-3.4.4) with ESMTP id p8QESMx3001294 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Mon, 26 Sep 2011 14:28:23 GMT Received: from acsmt358.oracle.com (acsmt358.oracle.com [141.146.40.158]) by ucsinet23.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id p8QESLZW018900 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 26 Sep 2011 14:28:21 GMT Received: from abhmt112.oracle.com (abhmt112.oracle.com [141.146.116.64]) by acsmt358.oracle.com (8.12.11.20060308/8.12.11) with ESMTP id p8QESFJ9031043; Mon, 26 Sep 2011 09:28:15 -0500 Received: from oracle.com (/209.6.55.207) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Mon, 26 Sep 2011 07:28:15 -0700 Received: by oracle.com (Postfix, from userid 1000) id 875721551; Mon, 26 Sep 2011 10:28:08 -0400 (EDT) Date: Mon, 26 Sep 2011 10:28:08 -0400 From: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com> To: MaoXiaoyun <tinnycloud@hotmail.com> Message-ID: <20110926142808.GG4102@phenom.oracle.com> References: <BLU157-W499E698F650F554E645F9DDA1C0@phx.gbl> <20110906145347.GA4133@dumpdata.com> <BLU157-W4106FA4CF4EBA78C63FDA0DA1C0@phx.gbl> <4E666C86.5090707@goop.org> <BLU157-W323C330706CB8D7E976BC3DA1F0@phx.gbl> <BLU157-W7DABA5FE01C50C29B1A64DA060@phx.gbl> <BLU157-W25EB1EAC24CC11FA14859ADAF20@phx.gbl> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <BLU157-W25EB1EAC24CC11FA14859ADAF20@phx.gbl> User-Agent: Mutt/1.5.21 (2010-09-15) X-Source-IP: ucsinet23.oracle.com [156.151.31.71] X-CT-RefId: str=0001.0A090203.4E808C08.00C2,ss=1,re=0.000,fgs=0 Cc: jack@suse.cz, linux-ext4@vger.kernel.org, tytso@mit.edu, xen devel <xen-devel@lists.xensource.com> Subject: [Xen-devel] Re: [patch 1/1] ext4-fix-dirty-extent-when-origin-leaf-extent-reac.patch X-BeenThere: xen-devel@lists.xensource.com X-Mailman-Version: 2.1.5 Precedence: list List-Id: Xen developer discussion <xen-devel.lists.xensource.com> List-Unsubscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe> List-Post: <mailto:xen-devel@lists.xensource.com> List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help> List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=subscribe> Sender: xen-devel-bounces@lists.xensource.com Errors-To: xen-devel-bounces@lists.xensource.com On Sun, Sep 25, 2011 at 04:45:39PM +0800, MaoXiaoyun wrote: > > > Hi: > > We met an ext4 BUG_ON in extents.c:1716 which crash kernel flush thread, and result in disk unvailiable. > > BUG details refer to: http://www.gossamer-threads.com/lists/xen/devel/217091?do=post_view_threaded > > Attached is the fix, verified in our env. So.. you are asking for this upstream git commit to be back-ported to 2.6.32, right? > > Without this patch, more than 3 servers hit BUG_ON in our hundreds of servers every day. > > > many thanks. _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel From xen-devel-bounces@lists.xensource.com Mon Sep 26 07:43:24 2011 Return-path: <xen-devel-bounces@lists.xensource.com> Envelope-to: www-data@lists.xensource.com Delivery-date: Mon, 26 Sep 2011 07:43:24 -0700 Received: from localhost ([127.0.0.1] helo=lists.colo.xensource.com) by lists.xensource.com with esmtp (Exim 4.43) id 1R8COy-0004Ek-HV; Mon, 26 Sep 2011 07:43:24 -0700 Received: from mail182.messagelabs.com ([85.158.139.83]) by lists.xensource.com with esmtp (Exim 4.43) id 1R8CO9-00041x-8t; Mon, 26 Sep 2011 07:42:33 -0700 X-Env-Sender: konrad@oracle.com X-Msg-Ref: server-14.tower-182.messagelabs.com!1317048148!19620647!1 X-Originating-IP: [141.146.126.227] X-StarScan-Version: 6.4.1; banners=-,-,- X-VirusChecked: Checked Received: (qmail 14281 invoked from network); 26 Sep 2011 14:42:29 -0000 Received: from acsinet15.oracle.com (HELO acsinet15.oracle.com) (141.146.126.227) by server-14.tower-182.messagelabs.com with DHE-RSA-AES256-SHA encrypted SMTP; 26 Sep 2011 14:42:29 -0000 Received: from ucsinet23.oracle.com (ucsinet23.oracle.com [156.151.31.71]) by acsinet15.oracle.com (Switch-3.4.4/Switch-3.4.4) with ESMTP id p8QEgFTn021430 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Mon, 26 Sep 2011 14:42:17 GMT Received: from acsmt357.oracle.com (acsmt357.oracle.com [141.146.40.157]) by ucsinet23.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id p8QEgEAp004999 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 26 Sep 2011 14:42:14 GMT Received: from abhmt106.oracle.com (abhmt106.oracle.com [141.146.116.58]) by acsmt357.oracle.com (8.12.11.20060308/8.12.11) with ESMTP id p8QEg9Rf023345; Mon, 26 Sep 2011 09:42:09 -0500 Received: from oracle.com (/209.6.55.207) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Mon, 26 Sep 2011 07:42:08 -0700 Received: by oracle.com (Postfix, from userid 1000) id 4BB521551; Mon, 26 Sep 2011 10:42:02 -0400 (EDT) Date: Mon, 26 Sep 2011 10:42:02 -0400 From: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com> To: Ian Campbell <Ian.Campbell@citrix.com> Subject: Re: [Xen-devel] Updating Xen 4.1.x xmexamples files (vfb line required for HVM guests) Message-ID: <20110926144202.GA7269@phenom.oracle.com> References: <201107231426.56811.jim_burn@bellsouth.net> <201107251548.19324.jim_burn@bellsouth.net> <20110725195723.GM32373@reaktio.net> <201107251639.17471.jim_burn@bellsouth.net> <20110725210550.GQ32373@reaktio.net> <1311694781.24408.57.camel@cthulhu.hellion.org.uk> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline In-Reply-To: <1311694781.24408.57.camel@cthulhu.hellion.org.uk> User-Agent: Mutt/1.5.21 (2010-09-15) Content-Transfer-Encoding: quoted-printable X-Source-IP: ucsinet23.oracle.com [156.151.31.71] X-CT-RefId: str=0001.0A090209.4E808F49.015B,ss=1,re=0.000,fgs=0 Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>, "xen-users@lists.xensource.com" <xen-users@lists.xensource.com>, jim burns <jim_burn@bellsouth.net> X-BeenThere: xen-devel@lists.xensource.com X-Mailman-Version: 2.1.5 Precedence: list List-Id: Xen developer discussion <xen-devel.lists.xensource.com> List-Unsubscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe> List-Post: <mailto:xen-devel@lists.xensource.com> List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help> List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=subscribe> Sender: xen-devel-bounces@lists.xensource.com Errors-To: xen-devel-bounces@lists.xensource.com On Tue, Jul 26, 2011 at 04:39:41PM +0100, Ian Campbell wrote: > On Mon, 2011-07-25 at 17:05 -0400, Pasi K=E4rkk=E4inen wrote: > > On Mon, Jul 25, 2011 at 04:39:16PM -0400, jim burns wrote: > > > On Mon July 25 2011 3:57:23 PM Pasi wrote: > > > > On Mon, Jul 25, 2011 at 03:48:18PM -0400, jim burns wrote: > > > > > On Mon July 25 2011 3:31:22 PM Pasi wrote: > > > > > > On Sat, Jul 23, 2011 at 02:26:56PM -0400, jim burns wrote: > > > > > > > Pls cc: me, as I am not subscribed. > > >=20 > > > > > > Hello, > > >=20 > > > > > Hi, Pasi! Long time no 'see'. > > >=20 > > > Btw, maybe you were following the thread '[Xen-devel] Failure to cr= eate HVM=20 > > > DomU at Xen 4.1 ( kernel 3.0.0-5-generic) Ubuntu 11.10 (alpha 2)'. = In my fork=20 > > > of that thread, I summarized many other threads over the last month= of people=20 > > > having problems starting an hvm domu under xen 4.1.x. Konrad finall= y provided=20 > > > the solution - 4.1.x requires the pv style vfb=3D line, not the ind= idvidual=20 > > > variables. >=20 > Perhaps I misunderstand this stuff but AIUI the vfb=3D line configures = a > Xen PV framebuffer device whereas the individual vnc*/sdl*/etc variable= s > configure the backend for the emulated VGA device. IOW they are pretty > much orthogonal and (for an HVM guest) both should work (dependent on > the required in-guest support being available). Also I'm not sure if > they can be used simultaneously, I expect they can. Seems you can (mix them both). I honestly had no idea and just used eithe= r one figuring it was 'xl' "bug". As in 'xm' it used to work with just individu= al 'vfb' lines. Hmm, should have reported this at some point - sorry about that. _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel From xen-devel-bounces@lists.xensource.com Mon Sep 26 07:47:00 2011 Return-path: <xen-devel-bounces@lists.xensource.com> Envelope-to: www-data@lists.xensource.com Delivery-date: Mon, 26 Sep 2011 07:47:00 -0700 Received: from localhost ([127.0.0.1] helo=lists.colo.xensource.com) by lists.xensource.com with esmtp (Exim 4.43) id 1R8CSS-0005IT-7U; Mon, 26 Sep 2011 07:47:00 -0700 Received: from mail27.messagelabs.com ([193.109.254.147]) by lists.xensource.com with esmtp (Exim 4.43) id 1R8CPF-0004Hk-Jj for xen-devel@lists.xensource.com; Mon, 26 Sep 2011 07:43:42 -0700 X-Env-Sender: Ian.Jackson@eu.citrix.com X-Msg-Ref: server-11.tower-27.messagelabs.com!1317048209!38956946!1 X-Originating-IP: [62.200.22.115] X-StarScan-Version: 6.4.1; banners=-,-,- X-VirusChecked: Checked Received: (qmail 27351 invoked from network); 26 Sep 2011 14:43:29 -0000 Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115) by server-11.tower-27.messagelabs.com with RC4-SHA encrypted SMTP; 26 Sep 2011 14:43:29 -0000 X-IronPort-AV: E=Sophos;i="4.68,444,1312156800"; d="scan'208";a="8064002" Received: from lonpmailmx01.citrite.net ([10.30.203.162]) by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5; 26 Sep 2011 14:43:38 +0000 Received: from woking.xci-test.com (10.80.248.135) by smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id 8.3.137.0; Mon, 26 Sep 2011 15:43:38 +0100 Received: from osstest by woking.xci-test.com with local (Exim 4.69) (envelope-from <ian.jackson@eu.citrix.com>) id 1R8CPB-0006B5-Ja; Mon, 26 Sep 2011 15:43:37 +0100 To: xen-devel@lists.xensource.com Message-ID: <osstest-9086-mainreport@xen.org> From: xen.org <ian.jackson@eu.citrix.com> Date: Mon, 26 Sep 2011 15:43:37 +0100 MIME-Version: 1.0 Content-Type: text/plain Cc: ian.jackson@eu.citrix.com Subject: [Xen-devel] [linux test] 9086: tolerable FAIL X-BeenThere: xen-devel@lists.xensource.com X-Mailman-Version: 2.1.5 Precedence: list List-Id: Xen developer discussion <xen-devel.lists.xensource.com> List-Unsubscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe> List-Post: <mailto:xen-devel@lists.xensource.com> List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help> List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=subscribe> Sender: xen-devel-bounces@lists.xensource.com Errors-To: xen-devel-bounces@lists.xensource.com flight 9086 linux real [real] http://www.chiark.greenend.org.uk/~xensrcts/logs/9086/ Failures :-/ but no regressions. Tests which are failing intermittently (not blocking): test-amd64-amd64-xl-sedf 11 guest-localmigrate fail pass in 9084 Tests which did not succeed, but are not blocking, including regressions (tests previously passed) regarded as allowable: test-amd64-amd64-xl-pcipt-intel 9 guest-start fail never pass test-amd64-i386-rhel6hvm-amd 9 guest-start.2 fail never pass test-amd64-i386-rhel6hvm-intel 9 guest-start.2 fail never pass test-amd64-i386-win-vcpus1 16 leak-check/check fail never pass test-amd64-i386-xl-win-vcpus1 13 guest-stop fail never pass test-amd64-amd64-win 16 leak-check/check fail never pass test-amd64-amd64-xl-win 13 guest-stop fail never pass test-i386-i386-win 16 leak-check/check fail never pass test-i386-i386-xl-win 13 guest-stop fail never pass test-amd64-i386-win 16 leak-check/check fail never pass version targeted for testing: linux 6bec8b4a4c14095d0b7ce424db9d583c3decae6c baseline version: linux 1c3f03ccc5258887f5f2cafc0836a865834f9205 ------------------------------------------------------------ People who touched revisions under test: Jeremy Fitzhardinge <jeremy.fitzhardinge@citrix.com> ------------------------------------------------------------ jobs: build-amd64 pass build-i386 pass build-amd64-pvops pass build-i386-pvops pass test-amd64-amd64-xl pass test-amd64-i386-xl pass test-i386-i386-xl pass test-amd64-i386-rhel6hvm-amd fail test-amd64-i386-xl-credit2 pass test-amd64-amd64-xl-pcipt-intel fail test-amd64-i386-rhel6hvm-intel fail test-amd64-i386-xl-multivcpu pass test-amd64-amd64-pair pass test-amd64-i386-pair pass test-i386-i386-pair pass test-amd64-amd64-pv pass test-amd64-i386-pv pass test-i386-i386-pv pass test-amd64-amd64-xl-sedf fail test-amd64-i386-win-vcpus1 fail test-amd64-i386-xl-win-vcpus1 fail test-amd64-amd64-win fail test-amd64-i386-win fail test-i386-i386-win fail test-amd64-amd64-xl-win fail test-i386-i386-xl-win fail ------------------------------------------------------------ sg-report-flight on woking.cam.xci-test.com logs: /home/xc_osstest/logs images: /home/xc_osstest/images Logs, config files, etc. are available at http://www.chiark.greenend.org.uk/~xensrcts/logs Test harness code can be found at http://xenbits.xensource.com/gitweb?p=osstest.git;a=summary Pushing revision : + branch=linux + revision=6bec8b4a4c14095d0b7ce424db9d583c3decae6c + . cri-lock-repos ++ . cri-common +++ umask 002 +++ getconfig Repos +++ perl -e ' use Osstest; readconfigonly(); print $c{Repos} or die $!; ' ++ repos=/export/home/osstest/repos ++ repos_lock=/export/home/osstest/repos/lock ++ '[' x '!=' x/export/home/osstest/repos/lock ']' ++ OSSTEST_REPOS_LOCK_LOCKED=/export/home/osstest/repos/lock ++ exec with-lock-ex -w /export/home/osstest/repos/lock ./ap-push linux 6bec8b4a4c14095d0b7ce424db9d583c3decae6c + branch=linux + revision=6bec8b4a4c14095d0b7ce424db9d583c3decae6c + . cri-lock-repos ++ . cri-common +++ umask 002 +++ getconfig Repos +++ perl -e ' use Osstest; readconfigonly(); print $c{Repos} or die $!; ' ++ repos=/export/home/osstest/repos ++ repos_lock=/export/home/osstest/repos/lock ++ '[' x/export/home/osstest/repos/lock '!=' x/export/home/osstest/repos/lock ']' + : xen@xenbits.xensource.com + : xen@xenbits.xensource.com:git/linux-pvops + : master + : tested/2.6.39.x + case "$branch" in + cd /export/home/osstest/repos/xen ./ap-push: line 20: cd: /export/home/osstest/repos/xen: No such file or directory ------------------------------------------------------------ commit 6bec8b4a4c14095d0b7ce424db9d583c3decae6c Author: Jeremy Fitzhardinge <jeremy.fitzhardinge@citrix.com> Date: Fri Sep 2 12:23:22 2011 -0700 Revert "xen/apic: Provide an 'apic_xen' to set the override the apic->[read|write] for all cases." This reverts commit c3dd7941354fa96a71f2613e2c7a1b215fa175dc. It prevents the kernel from booting natively on hardware. Conflicts: arch/x86/xen/enlighten.c Signed-off-by: Jeremy Fitzhardinge <jeremy.fitzhardinge@citrix.com> _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel From xen-devel-bounces@lists.xensource.com Mon Sep 26 07:47:46 2011 Return-path: <xen-devel-bounces@lists.xensource.com> Envelope-to: www-data@lists.xensource.com Delivery-date: Mon, 26 Sep 2011 07:47:46 -0700 Received: from localhost ([127.0.0.1] helo=lists.colo.xensource.com) by lists.xensource.com with esmtp (Exim 4.43) id 1R8CTC-0005f5-B2; Mon, 26 Sep 2011 07:47:46 -0700 Received: from mail21.messagelabs.com ([85.158.143.35]) by lists.xensource.com with smtp (Exim 4.43) id 1R8CQX-0004cJ-3R for xen-devel@lists.xensource.com; Mon, 26 Sep 2011 07:45:01 -0700 X-Env-Sender: ml-xen-devel@hfp.de X-Msg-Ref: server-6.tower-21.messagelabs.com!1317048278!39698771!1 X-Originating-IP: [88.205.101.6] X-StarScan-Version: 6.4.1; banners=-,-,- X-VirusChecked: Checked Received: (qmail 15128 invoked from network); 26 Sep 2011 14:44:38 -0000 Received: from rootsrv.hfp.de (HELO rootsrv.hfp.de) (88.205.101.6) by server-6.tower-21.messagelabs.com with SMTP; 26 Sep 2011 14:44:38 -0000 Received: from localhost (localhost [127.0.0.1]) by rootsrv.hfp.de (Postfix) with ESMTP id 21AA01A9209; Mon, 26 Sep 2011 16:44:57 +0200 (CEST) X-Virus-Scanned: amavisd-new/ClamAV at rootsrv.hfp.de Received: from rootsrv.hfp.de ([127.0.0.1]) by localhost (rootsrv.hfp.de [127.0.0.1]) (amavisd-new, port 10026) with ESMTP id 1BGW3yebZnng; Mon, 26 Sep 2011 16:44:56 +0200 (CEST) Received: from [10.0.0.1] (p5DCB6962.dip.t-dialin.net [93.203.105.98]) by rootsrv.hfp.de (Postfix) with ESMTPA; Mon, 26 Sep 2011 16:44:56 +0200 (CEST) Message-ID: <4E808FE9.5050008@hfp.de> Date: Mon, 26 Sep 2011 16:44:57 +0200 From: Andreas Kinzler <ml-xen-devel@hfp.de> User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:6.0.2) Gecko/20110902 Thunderbird/6.0.2 MIME-Version: 1.0 To: James Harper <james.harper@bendigoit.com.au> Subject: Re: [Xen-devel] RE: Stability report GPLPV 0.11.0.308 References: <4E64A0DF.2070007@hfp.de> <AEC6C66638C05B468B556EA548C1A77D01E5DB8C@trantor> <4E64D569.5030607@hfp.de> <AEC6C66638C05B468B556EA548C1A77D01E5DBBF@trantor> <4E7728F9.9020208@hfp.de> <AEC6C66638C05B468B556EA548C1A77D01E5E008@trantor> <4E7B04A4.9070601@hfp.de> <AEC6C66638C05B468B556EA548C1A77D01E5E072@trantor> <4E7CF2A8.5040405@hfp.de> <AEC6C66638C05B468B556EA548C1A77D01E5E0D0@trantor> In-Reply-To: <AEC6C66638C05B468B556EA548C1A77D01E5E0D0@trantor> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: xen-devel@lists.xensource.com X-BeenThere: xen-devel@lists.xensource.com X-Mailman-Version: 2.1.5 Precedence: list List-Id: Xen developer discussion <xen-devel.lists.xensource.com> List-Unsubscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe> List-Post: <mailto:xen-devel@lists.xensource.com> List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help> List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=subscribe> Sender: xen-devel-bounces@lists.xensource.com Errors-To: xen-devel-bounces@lists.xensource.com On 24.09.2011 01:49, James Harper wrote: > I'm just setting up a few new servers and on one of them a Windows > 2008R2 machine hung and there were lots of xenvbd errors in the logs. > The underlying block device for that DomU is iSCSI and I assumed the > problem was there (I was doing a lot of testing on the SAN at the time) > but maybe not. Hmmm, do you have any more ideas? Anything how I could help you debugging? > No evidence of problems in /var/log/xen/qemu-dm-<domu name>.log? I did not see anything special. Regards Andreas _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel From xen-devel-bounces@lists.xensource.com Mon Sep 26 07:49:30 2011 Return-path: <xen-devel-bounces@lists.xensource.com> Envelope-to: www-data@lists.xensource.com Delivery-date: Mon, 26 Sep 2011 07:49:30 -0700 Received: from localhost ([127.0.0.1] helo=lists.colo.xensource.com) by lists.xensource.com with esmtp (Exim 4.43) id 1R8CUs-000665-GD; Mon, 26 Sep 2011 07:49:30 -0700 Received: from mail21.messagelabs.com ([85.158.143.35]) by lists.xensource.com with esmtp (Exim 4.43) id 1R8CUQ-0005tk-2b for xen-devel@lists.xensource.com; Mon, 26 Sep 2011 07:49:03 -0700 X-Env-Sender: Andrew.Cooper3@citrix.com X-Msg-Ref: server-4.tower-21.messagelabs.com!1317048502!61657261!1 X-Originating-IP: [62.200.22.115] X-StarScan-Version: 6.4.1; banners=-,-,- X-VirusChecked: Checked Received: (qmail 22472 invoked from network); 26 Sep 2011 14:48:22 -0000 Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115) by server-4.tower-21.messagelabs.com with RC4-SHA encrypted SMTP; 26 Sep 2011 14:48:22 -0000 X-IronPort-AV: E=Sophos;i="4.68,444,1312156800"; d="scan'208";a="8064226" Received: from lonpmailmx01.citrite.net ([10.30.203.162]) by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5; 26 Sep 2011 14:48:58 +0000 Received: from andrewcoop.uk.xensource.com (10.80.2.18) by LONPMAILMX01.citrite.net (10.30.203.162) with Microsoft SMTP Server id 8.3.137.0; Mon, 26 Sep 2011 15:48:59 +0100 Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Mercurial-Node: 6896ad0a17986a06a4709911bf446d49ee95dd23 Message-ID: <6896ad0a17986a06a470.1317048538@andrewcoop.uk.xensource.com> User-Agent: Mercurial-patchbomb/1.4.3 Date: Mon, 26 Sep 2011 15:48:58 +0100 From: Andrew Cooper <andrew.cooper3@citrix.com> To: xen-devel@lists.xensource.com Cc: Andrew Cooper <andrew.cooper3@citrix.com> Subject: [Xen-devel] [PATCH] IRQ Cleanup: rename nr_ioapic_registers to nr_ioapic_entries X-BeenThere: xen-devel@lists.xensource.com X-Mailman-Version: 2.1.5 Precedence: list List-Id: Xen developer discussion <xen-devel.lists.xensource.com> List-Unsubscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe> List-Post: <mailto:xen-devel@lists.xensource.com> List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help> List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=subscribe> Sender: xen-devel-bounces@lists.xensource.com Errors-To: xen-devel-bounces@lists.xensource.com The name "nr_ioapic_registers" is wrong and actively misleading. The variable holds the number of redirection entries for each apic, which is two registers fewer than the total number of registers. Signed-off-by: Andrew Cooper <andrew.cooper3@citrix.com> diff -r a422e2a4451e -r 6896ad0a1798 xen/arch/x86/io_apic.c --- a/xen/arch/x86/io_apic.c Sun Sep 18 00:26:52 2011 +0100 +++ b/xen/arch/x86/io_apic.c Mon Sep 26 15:47:58 2011 +0100 @@ -58,7 +58,7 @@ s8 __read_mostly sis_apic_bug = -1; /* * # of IRQ routing registers */ -int __read_mostly nr_ioapic_registers[MAX_IO_APICS]; +int __read_mostly nr_ioapic_entries[MAX_IO_APICS]; int __read_mostly nr_ioapics; /* @@ -149,7 +149,7 @@ struct IO_APIC_route_entry **alloc_ioapi for (apic = 0; apic < nr_ioapics; apic++) { ioapic_entries[apic] = xmalloc_array(struct IO_APIC_route_entry, - nr_ioapic_registers[apic]); + nr_ioapic_entries[apic]); if (!ioapic_entries[apic]) goto nomem; } @@ -245,7 +245,7 @@ static void __io_apic_eoi(unsigned int a if ( pin == -1 ) { unsigned int p; - for ( p = 0; p < nr_ioapic_registers[apic]; ++p ) + for ( p = 0; p < nr_ioapic_entries[apic]; ++p ) { entry = __ioapic_read_entry(apic, p, TRUE); if ( entry.vector == vector ) @@ -328,7 +328,7 @@ int save_IO_APIC_setup(struct IO_APIC_ro if (!ioapic_entries[apic]) return -ENOMEM; - for (pin = 0; pin < nr_ioapic_registers[apic]; pin++) + for (pin = 0; pin < nr_ioapic_entries[apic]; pin++) ioapic_entries[apic][pin] = __ioapic_read_entry(apic, pin, 1); } @@ -349,7 +349,7 @@ void mask_IO_APIC_setup(struct IO_APIC_r if (!ioapic_entries[apic]) break; - for (pin = 0; pin < nr_ioapic_registers[apic]; pin++) { + for (pin = 0; pin < nr_ioapic_entries[apic]; pin++) { struct IO_APIC_route_entry entry; entry = ioapic_entries[apic][pin]; @@ -376,7 +376,7 @@ int restore_IO_APIC_setup(struct IO_APIC if (!ioapic_entries[apic]) return -ENOMEM; - for (pin = 0; pin < nr_ioapic_registers[apic]; pin++) + for (pin = 0; pin < nr_ioapic_entries[apic]; pin++) ioapic_write_entry(apic, pin, 1, ioapic_entries[apic][pin]); } @@ -524,7 +524,7 @@ static void clear_IO_APIC (void) int apic, pin; for (apic = 0; apic < nr_ioapics; apic++) { - for (pin = 0; pin < nr_ioapic_registers[apic]; pin++) + for (pin = 0; pin < nr_ioapic_entries[apic]; pin++) clear_IO_APIC_pin(apic, pin); } } @@ -785,7 +785,7 @@ void /*__init*/ setup_ioapic_dest(void) return; for (ioapic = 0; ioapic < nr_ioapics; ioapic++) { - for (pin = 0; pin < nr_ioapic_registers[ioapic]; pin++) { + for (pin = 0; pin < nr_ioapic_entries[ioapic]; pin++) { irq_entry = find_irq_entry(ioapic, pin, mp_INT); if (irq_entry == -1) continue; @@ -1031,7 +1031,7 @@ static int pin_2_irq(int idx, int apic, */ i = irq = 0; while (i < apic) - irq += nr_ioapic_registers[i++]; + irq += nr_ioapic_entries[i++]; irq += pin; break; } @@ -1051,7 +1051,7 @@ static inline int IO_APIC_irq_trigger(in int apic, idx, pin; for (apic = 0; apic < nr_ioapics; apic++) { - for (pin = 0; pin < nr_ioapic_registers[apic]; pin++) { + for (pin = 0; pin < nr_ioapic_entries[apic]; pin++) { idx = find_irq_entry(apic,pin,mp_INT); if ((idx != -1) && (irq == pin_2_irq(idx,apic,pin))) return irq_trigger(idx); @@ -1092,7 +1092,7 @@ static void __init setup_IO_APIC_irqs(vo apic_printk(APIC_VERBOSE, KERN_DEBUG "init IO_APIC IRQs\n"); for (apic = 0; apic < nr_ioapics; apic++) { - for (pin = 0; pin < nr_ioapic_registers[apic]; pin++) { + for (pin = 0; pin < nr_ioapic_entries[apic]; pin++) { /* * add it to the IO-APIC irq-routing table: @@ -1218,7 +1218,7 @@ static void /*__init*/ __print_IO_APIC(v printk(KERN_DEBUG "number of MP IRQ sources: %d.\n", mp_irq_entries); for (i = 0; i < nr_ioapics; i++) printk(KERN_DEBUG "number of IO-APIC #%d registers: %d.\n", - mp_ioapics[i].mpc_apicid, nr_ioapic_registers[i]); + mp_ioapics[i].mpc_apicid, nr_ioapic_entries[i]); /* * We are a bit conservative about what we expect. We have to @@ -1378,7 +1378,7 @@ static void __init enable_IO_APIC(void) for(apic = 0; apic < nr_ioapics; apic++) { int pin; /* See if any of the pins is in ExtINT mode */ - for (pin = 0; pin < nr_ioapic_registers[apic]; pin++) { + for (pin = 0; pin < nr_ioapic_entries[apic]; pin++) { struct IO_APIC_route_entry entry = ioapic_read_entry(apic, pin, 0); /* If the interrupt line is enabled and in ExtInt mode @@ -2116,7 +2116,7 @@ static void __init ioapic_pm_state_alloc int i, nr_entry = 0; for (i = 0; i < nr_ioapics; i++) - nr_entry += nr_ioapic_registers[i]; + nr_entry += nr_ioapic_entries[i]; ioapic_pm_state = _xmalloc(sizeof(struct IO_APIC_route_entry)*nr_entry, sizeof(struct IO_APIC_route_entry)); @@ -2158,7 +2158,7 @@ void ioapic_suspend(void) spin_lock_irqsave(&ioapic_lock, flags); for (apic = 0; apic < nr_ioapics; apic++) { - for (i = 0; i < nr_ioapic_registers[apic]; i ++, entry ++ ) { + for (i = 0; i < nr_ioapic_entries[apic]; i ++, entry ++ ) { *(((int *)entry) + 1) = __io_apic_read(apic, 0x11 + 2 * i); *(((int *)entry) + 0) = __io_apic_read(apic, 0x10 + 2 * i); } @@ -2180,7 +2180,7 @@ void ioapic_resume(void) reg_00.bits.ID = mp_ioapics[apic].mpc_apicid; __io_apic_write(apic, 0, reg_00.raw); } - for (i = 0; i < nr_ioapic_registers[apic]; i++, entry++) { + for (i = 0; i < nr_ioapic_entries[apic]; i++, entry++) { __io_apic_write(apic, 0x11+2*i, *(((int *)entry)+1)); __io_apic_write(apic, 0x10+2*i, *(((int *)entry)+0)); } @@ -2609,8 +2609,8 @@ void __init init_ioapic_mappings(void) { /* The number of IO-APIC IRQ registers (== #pins): */ reg_01.raw = io_apic_read(i, 1); - nr_ioapic_registers[i] = reg_01.bits.entries + 1; - nr_irqs_gsi += nr_ioapic_registers[i]; + nr_ioapic_entries[i] = reg_01.bits.entries + 1; + nr_irqs_gsi += nr_ioapic_entries[i]; } } diff -r a422e2a4451e -r 6896ad0a1798 xen/drivers/passthrough/amd/iommu_intr.c --- a/xen/drivers/passthrough/amd/iommu_intr.c Sun Sep 18 00:26:52 2011 +0100 +++ b/xen/drivers/passthrough/amd/iommu_intr.c Mon Sep 26 15:47:58 2011 +0100 @@ -165,7 +165,7 @@ int __init amd_iommu_setup_ioapic_remapp /* Read ioapic entries and update interrupt remapping table accordingly */ for ( apic = 0; apic < nr_ioapics; apic++ ) { - for ( pin = 0; pin < nr_ioapic_registers[apic]; pin++ ) + for ( pin = 0; pin < nr_ioapic_entries[apic]; pin++ ) { *(((int *)&rte) + 1) = io_apic_read(apic, 0x11 + 2 * pin); *(((int *)&rte) + 0) = io_apic_read(apic, 0x10 + 2 * pin); diff -r a422e2a4451e -r 6896ad0a1798 xen/drivers/passthrough/vtd/intremap.c --- a/xen/drivers/passthrough/vtd/intremap.c Sun Sep 18 00:26:52 2011 +0100 +++ b/xen/drivers/passthrough/vtd/intremap.c Mon Sep 26 15:47:58 2011 +0100 @@ -33,7 +33,7 @@ #ifdef __ia64__ #define nr_ioapics iosapic_get_nr_iosapics() -#define nr_ioapic_registers(i) iosapic_get_nr_pins(i) +#define nr_ioapic_entries(i) iosapic_get_nr_pins(i) #define __io_apic_read(apic, reg) \ (*IO_APIC_BASE(apic) = reg, *(IO_APIC_BASE(apic)+4)) #define __io_apic_write(apic, reg, val) \ @@ -53,7 +53,7 @@ #else #include <asm/apic.h> #include <asm/io_apic.h> -#define nr_ioapic_registers(i) nr_ioapic_registers[i] +#define nr_ioapic_entries(i) nr_ioapic_entries[i] #endif /* @@ -91,7 +91,7 @@ static int init_apic_pin_2_ir_idx(void) nr_pins = 0; for ( i = 0; i < nr_ioapics; i++ ) - nr_pins += nr_ioapic_registers(i); + nr_pins += nr_ioapic_entries(i); _apic_pin_2_ir_idx = xmalloc_array(int, nr_pins); apic_pin_2_ir_idx = xmalloc_array(int *, nr_ioapics); @@ -109,7 +109,7 @@ static int init_apic_pin_2_ir_idx(void) for ( i = 0; i < nr_ioapics; i++ ) { apic_pin_2_ir_idx[i] = &_apic_pin_2_ir_idx[nr_pins]; - nr_pins += nr_ioapic_registers(i); + nr_pins += nr_ioapic_entries(i); } return 0; diff -r a422e2a4451e -r 6896ad0a1798 xen/include/asm-x86/io_apic.h --- a/xen/include/asm-x86/io_apic.h Sun Sep 18 00:26:52 2011 +0100 +++ b/xen/include/asm-x86/io_apic.h Mon Sep 26 15:47:58 2011 +0100 @@ -77,7 +77,7 @@ union IO_APIC_reg_03 { * # of IO-APICs and # of IRQ routing registers */ extern int nr_ioapics; -extern int nr_ioapic_registers[MAX_IO_APICS]; +extern int nr_ioapic_entries[MAX_IO_APICS]; enum ioapic_irq_destination_types { dest_Fixed = 0, _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel From xen-devel-bounces@lists.xensource.com Mon Sep 26 07:50:43 2011 Return-path: <xen-devel-bounces@lists.xensource.com> Envelope-to: www-data@lists.xensource.com Delivery-date: Mon, 26 Sep 2011 07:50:43 -0700 Received: from localhost ([127.0.0.1] helo=lists.colo.xensource.com) by lists.xensource.com with esmtp (Exim 4.43) id 1R8CW3-0006YN-Dw; Mon, 26 Sep 2011 07:50:43 -0700 Received: from mail27.messagelabs.com ([193.109.254.147]) by lists.xensource.com with smtp (Exim 4.43) id 1R8CUY-0005vB-0m for xen-devel@lists.xensource.com; Mon, 26 Sep 2011 07:49:10 -0700 X-Env-Sender: anthony@overnetdata.com X-Msg-Ref: server-2.tower-27.messagelabs.com!1317048520!56498939!1 X-Originating-IP: [81.137.131.225] X-StarScan-Version: 6.4.1; banners=-,-,- X-VirusChecked: Checked Received: (qmail 26919 invoked from network); 26 Sep 2011 14:48:40 -0000 Received: from host81-137-131-225.in-addr.btopenworld.com (HELO zimbra.overnetdata.com) (81.137.131.225) by server-2.tower-27.messagelabs.com with SMTP; 26 Sep 2011 14:48:40 -0000 Received: from localhost (localhost.localdomain [127.0.0.1]) by zimbra.overnetdata.com (Postfix) with ESMTP id 0F87A1619F1; Mon, 26 Sep 2011 15:49:06 +0100 (BST) X-Virus-Scanned: amavisd-new at overnetdata.com Received: from zimbra.overnetdata.com ([127.0.0.1]) by localhost (zimbra.overnetdata.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id M3cAEhsIyi6w; Mon, 26 Sep 2011 15:48:55 +0100 (BST) Received: from [192.168.1.60] (unknown [192.168.1.60]) by zimbra.overnetdata.com (Postfix) with ESMTPSA id AB1B01617A9; Mon, 26 Sep 2011 15:48:54 +0100 (BST) Message-ID: <4E8090D4.2090009@overnetdata.com> Date: Mon, 26 Sep 2011 15:48:52 +0100 From: Anthony Wright <anthony@overnetdata.com> User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:6.0.2) Gecko/20110902 Thunderbird/6.0.2 MIME-Version: 1.0 To: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com> Subject: Re: [Xen-devel] dmidecode doesn't work under xen 4.1.1 on certain hardware References: <4E7C6BDC.8070005@overnetdata.com> <20110923133200.GC19579@phenom.oracle.com> <4E7C9C8B.2010108@overnetdata.com> <20110926141322.GD4102@phenom.oracle.com> In-Reply-To: <20110926141322.GD4102@phenom.oracle.com> X-Enigmail-Version: 1.3.2 Content-Type: multipart/mixed; boundary="------------010105050301030905020601" Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com> X-BeenThere: xen-devel@lists.xensource.com X-Mailman-Version: 2.1.5 Precedence: list List-Id: Xen developer discussion <xen-devel.lists.xensource.com> List-Unsubscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe> List-Post: <mailto:xen-devel@lists.xensource.com> List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help> List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=subscribe> Sender: xen-devel-bounces@lists.xensource.com Errors-To: xen-devel-bounces@lists.xensource.com This is a multi-part message in MIME format. --------------010105050301030905020601 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit On 26/09/2011 15:13, Konrad Rzeszutek Wilk wrote: > On Fri, Sep 23, 2011 at 03:49:47PM +0100, Anthony Wright wrote: >> On 23/09/2011 14:32, Konrad Rzeszutek Wilk wrote: >>> On Fri, Sep 23, 2011 at 12:22:04PM +0100, Anthony Wright wrote: >>>> I have a xen 4.1.1 with a 3.0.4 linux kernel running on a Supermicro >>>> Supermicro X8DTL-iF motherboard with 16GB of RAM. >>>> >>>> If I run the 3.0.4 kernel on the bare metal dmidecode works fine. If I >>> Can you attach the beginning of the kernel bootup log? It should >>> have some entry about 1-1 mappings. Make sure to run Linux with "debug loglevel=8" >> Please find attached. >> 2011 Sep 23 14:45:41 kernel: [ 0.000000] 1-1 mapping on 9a->100 >> 2011 Sep 23 14:45:41 kernel: [ 0.000000] 1-1 mapping on bf780->100000 >> 2011 Sep 23 14:45:41 kernel: [ 0.000000] Set 264422 page(s) to 1-1 mapping. >> 2011 Sep 23 14:45:41 kernel: [ 0.000000] BIOS-provided physical RAM map: >> 2011 Sep 23 14:45:41 kernel: [ 0.000000] Xen: 0000000000000000 - 0000000000099000 (usable) >> 2011 Sep 23 14:45:41 kernel: [ 0.000000] Xen: 0000000000099800 - 0000000000100000 (reserved) > .. snip.. > > So 99C00 is right at cusp of 'usuable' and 'reserved'. Meaning that region > falls within the 4KB page. And we did not set the 1-1 mapping for 99 (we > started at 9A). > > But now that I think of it - this is Linux E820 which does get modified. > Can you also provide the hypervisor E820 output? You can get 'xl dmesg' > for that. That should provide the "virgin" output of the e820 which we > use for 1-1 mapping. I'm not quite sure I understand all that, but I think you would find the xl dmesg output helpful, so I've attached it. --------------010105050301030905020601 Content-Type: text/plain; name="dmidecode-fails-xl-dmesg.log" Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename="dmidecode-fails-xl-dmesg.log" __ __ _ _ _ _ \ \/ /___ _ __ | || | / | / | \ // _ \ '_ \ | || |_ | | | | / \ __/ | | | |__ _|| |_| | /_/\_\___|_| |_| |_|(_)_(_)_| (XEN) Xen version 4.1.1 (@[unknown]) (gcc version 4.4.3 (GCC) ) Wed Sep 21 08:25:36 GMT 2011 (XEN) Latest ChangeSet: unavailable (XEN) Bootloader: GNU GRUB 0.97 (XEN) Command line: (XEN) Video information: (XEN) VGA is text mode 80x25, font 8x16 (XEN) VBE/DDC methods: V2; EDID transfer time: 1 seconds (XEN) Disc information: (XEN) Found 4 MBR signatures (XEN) Found 4 EDD information structures (XEN) WARNING: Only the first 16 GB of the physical memory map can be accessed by Xen in 32-bit mode. (XEN) Truncating RAM from 17825792kB to 16777216kB (XEN) Xen-e820 RAM map: (XEN) 0000000000000000 - 0000000000099800 (usable) (XEN) 0000000000099800 - 00000000000a0000 (reserved) (XEN) 00000000000e4000 - 0000000000100000 (reserved) (XEN) 0000000000100000 - 00000000bf780000 (usable) (XEN) 00000000bf78e000 - 00000000bf790000 type 9 (XEN) 00000000bf790000 - 00000000bf79e000 (ACPI data) (XEN) 00000000bf79e000 - 00000000bf7d0000 (ACPI NVS) (XEN) 00000000bf7d0000 - 00000000bf7e0000 (reserved) (XEN) 00000000bf7ec000 - 00000000c0000000 (reserved) (XEN) 00000000e0000000 - 00000000f0000000 (reserved) (XEN) 00000000fee00000 - 00000000fee01000 (reserved) (XEN) 00000000ffc00000 - 0000000100000000 (reserved) (XEN) 0000000100000000 - 0000000400000000 (usable) (XEN) 0000000400000000 - 0000000440000000 (unusable) (XEN) System RAM: 15351MB (15719524kB) (XEN) ACPI: RSDP 000FABE0, 0024 (r2 ACPIAM) (XEN) ACPI: XSDT BF790100, 007C (r1 SMCI 20110105 MSFT 97) (XEN) ACPI: FACP BF790290, 00F4 (r3 010511 FACP1122 20110105 MSFT 97) (XEN) ACPI: DSDT BF7906A0, 655C (r1 10006 10006000 0 INTL 20051117) (XEN) ACPI: FACS BF79E000, 0040 (XEN) ACPI: APIC BF790390, 011E (r1 010511 APIC1122 20110105 MSFT 97) (XEN) ACPI: MCFG BF7904B0, 003C (r1 010511 OEMMCFG 20110105 MSFT 97) (XEN) ACPI: SLIT BF7904F0, 0030 (r1 010511 OEMSLIT 20110105 MSFT 97) (XEN) ACPI: OEMB BF79E040, 0085 (r1 010511 OEMB1122 20110105 MSFT 97) (XEN) ACPI: HPET BF79A6A0, 0038 (r1 010511 OEMHPET 20110105 MSFT 97) (XEN) ACPI: SSDT BF79EFB0, 0363 (r1 DpgPmm CpuPm 12 INTL 20051117) (XEN) ACPI: EINJ BF79A6E0, 0130 (r1 AMIER AMI_EINJ 20110105 MSFT 97) (XEN) ACPI: BERT BF79A870, 0030 (r1 AMIER AMI_BERT 20110105 MSFT 97) (XEN) ACPI: ERST BF79A8A0, 01B0 (r1 AMIER AMI_ERST 20110105 MSFT 97) (XEN) ACPI: HEST BF79AA50, 00A8 (r1 AMIER ABC_HEST 20110105 MSFT 97) (XEN) Xen heap: 9MB (9788kB) (XEN) Domain heap initialised (XEN) Processor #0 7:10 APIC version 21 (XEN) Processor #2 7:10 APIC version 21 (XEN) Processor #4 7:10 APIC version 21 (XEN) Processor #6 7:10 APIC version 21 (XEN) IOAPIC[0]: apic_id 1, version 32, address 0xfec00000, GSI 0-23 (XEN) IOAPIC[1]: apic_id 3, version 32, address 0xfec8a000, GSI 24-47 (XEN) Enabling APIC mode: Flat. Using 2 I/O APICs (XEN) ERST table is invalid (XEN) Using scheduler: SMP Credit Scheduler (credit) (XEN) Detected 2266.797 MHz processor. (XEN) I/O virtualisation disabled (XEN) ENABLING IO-APIC IRQs (XEN) -> Using new ACK method (XEN) Platform timer is 14.318MHz HPET (XEN) Allocated console ring of 16 KiB. (XEN) VMX: Supported advanced features: (XEN) - APIC MMIO access virtualisation (XEN) - APIC TPR shadow (XEN) - Extended Page Tables (EPT) (XEN) - Virtual-Processor Identifiers (VPID) (XEN) - Virtual NMI (XEN) - MSR direct-access bitmap (XEN) EPT supports 2MB super page. (XEN) HVM: ASIDs enabled. (XEN) HVM: VMX enabled (XEN) HVM: Hardware Assisted Paging detected. (XEN) Brought up 4 CPUs (XEN) *** LOADING DOMAIN 0 *** (XEN) Xen kernel: 32-bit, PAE, lsb (XEN) Dom0 kernel: 32-bit, PAE, lsb, paddr 0x1000000 -> 0x1b38000 (XEN) PHYSICAL MEMORY ARRANGEMENT: (XEN) Dom0 alloc.: 00000003f0000000->00000003f4000000 (3848297 pages to be allocated) (XEN) Init. ramdisk: 00000003ff6ef000->00000003fffffca4 (XEN) VIRTUAL MEMORY ARRANGEMENT: (XEN) Loaded kernel: c1000000->c1b38000 (XEN) Init. ramdisk: c1b38000->c2448ca4 (XEN) Phys-Mach map: c2449000->c33095e8 (XEN) Start info: c330a000->c330a47c (XEN) Page tables: c330b000->c332a000 (XEN) Boot stack: c332a000->c332b000 (XEN) TOTAL: c0000000->c3400000 (XEN) ENTRY ADDRESS: c173e000 (XEN) Dom0 has maximum 4 VCPUs (XEN) Scrubbing Free RAM: .done. (XEN) Xen trace buffers: disabled (XEN) Std. Loglevel: Errors and warnings (XEN) Guest Loglevel: Nothing (Rate-limited: Errors and warnings) (XEN) Xen is relinquishing VGA console. (XEN) *** Serial input -> DOM0 (type 'CTRL-a' three times to switch input to Xen) (XEN) Freed 188kB init memory. --------------010105050301030905020601 Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel --------------010105050301030905020601-- From xen-devel-bounces@lists.xensource.com Mon Sep 26 08:00:32 2011 Return-path: <xen-devel-bounces@lists.xensource.com> Envelope-to: www-data@lists.xensource.com Delivery-date: Mon, 26 Sep 2011 08:00:33 -0700 Received: from localhost ([127.0.0.1] helo=lists.colo.xensource.com) by lists.xensource.com with esmtp (Exim 4.43) id 1R8CfW-0007tr-NB; Mon, 26 Sep 2011 08:00:31 -0700 Received: from mail216.messagelabs.com ([85.158.143.99]) by lists.xensource.com with esmtp (Exim 4.43) id 1R8Cd8-0007fX-1g for xen-devel@lists.xensource.com; Mon, 26 Sep 2011 07:58:02 -0700 X-Env-Sender: JBeulich@suse.com X-Msg-Ref: server-2.tower-216.messagelabs.com!1317049078!19201054!1 X-Originating-IP: [130.57.49.28] X-StarScan-Version: 6.4.1; banners=-,-,- X-VirusChecked: Checked Received: (qmail 13021 invoked from network); 26 Sep 2011 14:57:59 -0000 Received: from nat28.tlf.novell.com (HELO nat28.tlf.novell.com) (130.57.49.28) by server-2.tower-216.messagelabs.com with DHE-RSA-AES256-SHA encrypted SMTP; 26 Sep 2011 14:57:59 -0000 Received: from EMEA1-MTA by nat28.tlf.novell.com with Novell_GroupWise; Mon, 26 Sep 2011 15:57:58 +0100 Message-Id: <4E80AF140200007800057DA4@nat28.tlf.novell.com> X-Mailer: Novell GroupWise Internet Agent 8.0.1 Date: Mon, 26 Sep 2011 15:57:56 +0100 From: "Jan Beulich" <JBeulich@suse.com> To: "Andrew Cooper" <andrew.cooper3@citrix.com> Subject: Re: [Xen-devel] [PATCH] IRQ Cleanup: rename nr_ioapic_registers to nr_ioapic_entries References: <6896ad0a17986a06a470.1317048538@andrewcoop.uk.xensource.com> In-Reply-To: <6896ad0a17986a06a470.1317048538@andrewcoop.uk.xensource.com> Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: quoted-printable Content-Disposition: inline Cc: xen-devel@lists.xensource.com X-BeenThere: xen-devel@lists.xensource.com X-Mailman-Version: 2.1.5 Precedence: list List-Id: Xen developer discussion <xen-devel.lists.xensource.com> List-Unsubscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe> List-Post: <mailto:xen-devel@lists.xensource.com> List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help> List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=subscribe> Sender: xen-devel-bounces@lists.xensource.com Errors-To: xen-devel-bounces@lists.xensource.com >>> On 26.09.11 at 16:48, Andrew Cooper <andrew.cooper3@citrix.com> wrote: > The name "nr_ioapic_registers" is wrong and actively misleading. The > variable holds the number of redirection entries for each apic, which > is two registers fewer than the total number of registers. To be honest, this is the kind of renaming that I wouldn't want to do as long as Linux, from where the code originates, continues to use the prior name (no matter whether you consider it misleading). Jan > Signed-off-by: Andrew Cooper <andrew.cooper3@citrix.com> >=20 > diff -r a422e2a4451e -r 6896ad0a1798 xen/arch/x86/io_apic.c > --- a/xen/arch/x86/io_apic.c Sun Sep 18 00:26:52 2011 +0100 > +++ b/xen/arch/x86/io_apic.c Mon Sep 26 15:47:58 2011 +0100 > @@ -58,7 +58,7 @@ s8 __read_mostly sis_apic_bug =3D -1; > /* > * # of IRQ routing registers > */ > -int __read_mostly nr_ioapic_registers[MAX_IO_APICS]; > +int __read_mostly nr_ioapic_entries[MAX_IO_APICS]; > int __read_mostly nr_ioapics; > =20 > /* > @@ -149,7 +149,7 @@ struct IO_APIC_route_entry **alloc_ioapi > for (apic =3D 0; apic < nr_ioapics; apic++) { > ioapic_entries[apic] =3D > xmalloc_array(struct IO_APIC_route_entry, > - nr_ioapic_registers[apic]); > + nr_ioapic_entries[apic]); > if (!ioapic_entries[apic]) > goto nomem; > } > @@ -245,7 +245,7 @@ static void __io_apic_eoi(unsigned int a > if ( pin =3D=3D -1 ) > { > unsigned int p; > - for ( p =3D 0; p < nr_ioapic_registers[apic]; ++p ) > + for ( p =3D 0; p < nr_ioapic_entries[apic]; ++p ) > { > entry =3D __ioapic_read_entry(apic, p, TRUE); > if ( entry.vector =3D=3D vector ) > @@ -328,7 +328,7 @@ int save_IO_APIC_setup(struct IO_APIC_ro > if (!ioapic_entries[apic]) > return -ENOMEM; > =20 > - for (pin =3D 0; pin < nr_ioapic_registers[apic]; pin++) > + for (pin =3D 0; pin < nr_ioapic_entries[apic]; pin++) > ioapic_entries[apic][pin] =3D __ioapic_read_entry(apic, pin, = 1); > } > =20 > @@ -349,7 +349,7 @@ void mask_IO_APIC_setup(struct IO_APIC_r > if (!ioapic_entries[apic]) > break; > =20 > - for (pin =3D 0; pin < nr_ioapic_registers[apic]; pin++) { > + for (pin =3D 0; pin < nr_ioapic_entries[apic]; pin++) { > struct IO_APIC_route_entry entry; > =20 > entry =3D ioapic_entries[apic][pin]; > @@ -376,7 +376,7 @@ int restore_IO_APIC_setup(struct IO_APIC > if (!ioapic_entries[apic]) > return -ENOMEM; > =20 > - for (pin =3D 0; pin < nr_ioapic_registers[apic]; pin++) > + for (pin =3D 0; pin < nr_ioapic_entries[apic]; pin++) > ioapic_write_entry(apic, pin, 1, ioapic_entries[apic][pin]); > } > =20 > @@ -524,7 +524,7 @@ static void clear_IO_APIC (void) > int apic, pin; > =20 > for (apic =3D 0; apic < nr_ioapics; apic++) { > - for (pin =3D 0; pin < nr_ioapic_registers[apic]; pin++) > + for (pin =3D 0; pin < nr_ioapic_entries[apic]; pin++) > clear_IO_APIC_pin(apic, pin); > } > } > @@ -785,7 +785,7 @@ void /*__init*/ setup_ioapic_dest(void) > return; > =20 > for (ioapic =3D 0; ioapic < nr_ioapics; ioapic++) { > - for (pin =3D 0; pin < nr_ioapic_registers[ioapic]; pin++) { > + for (pin =3D 0; pin < nr_ioapic_entries[ioapic]; pin++) { > irq_entry =3D find_irq_entry(ioapic, pin, mp_INT); > if (irq_entry =3D=3D -1) > continue; > @@ -1031,7 +1031,7 @@ static int pin_2_irq(int idx, int apic,=20 > */ > i =3D irq =3D 0; > while (i < apic) > - irq +=3D nr_ioapic_registers[i++]; > + irq +=3D nr_ioapic_entries[i++]; > irq +=3D pin; > break; > } > @@ -1051,7 +1051,7 @@ static inline int IO_APIC_irq_trigger(in > int apic, idx, pin; > =20 > for (apic =3D 0; apic < nr_ioapics; apic++) { > - for (pin =3D 0; pin < nr_ioapic_registers[apic]; pin++) { > + for (pin =3D 0; pin < nr_ioapic_entries[apic]; pin++) { > idx =3D find_irq_entry(apic,pin,mp_INT); > if ((idx !=3D -1) && (irq =3D=3D pin_2_irq(idx,apic,pin))) > return irq_trigger(idx); > @@ -1092,7 +1092,7 @@ static void __init setup_IO_APIC_irqs(vo > apic_printk(APIC_VERBOSE, KERN_DEBUG "init IO_APIC IRQs\n"); > =20 > for (apic =3D 0; apic < nr_ioapics; apic++) { > - for (pin =3D 0; pin < nr_ioapic_registers[apic]; pin++) { > + for (pin =3D 0; pin < nr_ioapic_entries[apic]; pin++) { > =20 > /* > * add it to the IO-APIC irq-routing table: > @@ -1218,7 +1218,7 @@ static void /*__init*/ __print_IO_APIC(v > printk(KERN_DEBUG "number of MP IRQ sources: %d.\n", mp_irq_entries)= ; > for (i =3D 0; i < nr_ioapics; i++) > printk(KERN_DEBUG "number of IO-APIC #%d registers: %d.\n", > - mp_ioapics[i].mpc_apicid, nr_ioapic_registers[i]); > + mp_ioapics[i].mpc_apicid, nr_ioapic_entries[i]); > =20 > /* > * We are a bit conservative about what we expect. We have to > @@ -1378,7 +1378,7 @@ static void __init enable_IO_APIC(void) > for(apic =3D 0; apic < nr_ioapics; apic++) { > int pin; > /* See if any of the pins is in ExtINT mode */ > - for (pin =3D 0; pin < nr_ioapic_registers[apic]; pin++) { > + for (pin =3D 0; pin < nr_ioapic_entries[apic]; pin++) { > struct IO_APIC_route_entry entry =3D ioapic_read_entry(apic,= pin,=20 > 0); > =20 > /* If the interrupt line is enabled and in ExtInt mode > @@ -2116,7 +2116,7 @@ static void __init ioapic_pm_state_alloc > int i, nr_entry =3D 0; > =20 > for (i =3D 0; i < nr_ioapics; i++) > - nr_entry +=3D nr_ioapic_registers[i]; > + nr_entry +=3D nr_ioapic_entries[i]; > =20 > ioapic_pm_state =3D _xmalloc(sizeof(struct IO_APIC_route_entry)*nr_e= ntry, > sizeof(struct IO_APIC_route_entry)); > @@ -2158,7 +2158,7 @@ void ioapic_suspend(void) > =20 > spin_lock_irqsave(&ioapic_lock, flags); > for (apic =3D 0; apic < nr_ioapics; apic++) { > - for (i =3D 0; i < nr_ioapic_registers[apic]; i ++, entry ++ ) { > + for (i =3D 0; i < nr_ioapic_entries[apic]; i ++, entry ++ ) { > *(((int *)entry) + 1) =3D __io_apic_read(apic, 0x11 + 2 * = i); > *(((int *)entry) + 0) =3D __io_apic_read(apic, 0x10 + 2 * = i); > } > @@ -2180,7 +2180,7 @@ void ioapic_resume(void) > reg_00.bits.ID =3D mp_ioapics[apic].mpc_apicid; > __io_apic_write(apic, 0, reg_00.raw); > } > - for (i =3D 0; i < nr_ioapic_registers[apic]; i++, entry++) { > + for (i =3D 0; i < nr_ioapic_entries[apic]; i++, entry++) { > __io_apic_write(apic, 0x11+2*i, *(((int *)entry)+1)); > __io_apic_write(apic, 0x10+2*i, *(((int *)entry)+0)); > } > @@ -2609,8 +2609,8 @@ void __init init_ioapic_mappings(void) > { > /* The number of IO-APIC IRQ registers (=3D=3D #pins): */ > reg_01.raw =3D io_apic_read(i, 1); > - nr_ioapic_registers[i] =3D reg_01.bits.entries + 1; > - nr_irqs_gsi +=3D nr_ioapic_registers[i]; > + nr_ioapic_entries[i] =3D reg_01.bits.entries + 1; > + nr_irqs_gsi +=3D nr_ioapic_entries[i]; > } > } > =20 > diff -r a422e2a4451e -r 6896ad0a1798 xen/drivers/passthrough/amd/iommu_in= tr.c > --- a/xen/drivers/passthrough/amd/iommu_intr.c Sun Sep 18 = 00:26:52 2011 +0100 > +++ b/xen/drivers/passthrough/amd/iommu_intr.c Mon Sep 26 = 15:47:58 2011 +0100 > @@ -165,7 +165,7 @@ int __init amd_iommu_setup_ioapic_remapp > /* Read ioapic entries and update interrupt remapping table = accordingly=20 > */ > for ( apic =3D 0; apic < nr_ioapics; apic++ ) > { > - for ( pin =3D 0; pin < nr_ioapic_registers[apic]; pin++ ) > + for ( pin =3D 0; pin < nr_ioapic_entries[apic]; pin++ ) > { > *(((int *)&rte) + 1) =3D io_apic_read(apic, 0x11 + 2 * = pin); > *(((int *)&rte) + 0) =3D io_apic_read(apic, 0x10 + 2 * = pin); > diff -r a422e2a4451e -r 6896ad0a1798 xen/drivers/passthrough/vtd/intremap= .c > --- a/xen/drivers/passthrough/vtd/intremap.c Sun Sep 18 00:26:52 2011 = +0100 > +++ b/xen/drivers/passthrough/vtd/intremap.c Mon Sep 26 15:47:58 2011 = +0100 > @@ -33,7 +33,7 @@ > =20 > #ifdef __ia64__ > #define nr_ioapics iosapic_get_nr_iosapics() > -#define nr_ioapic_registers(i) iosapic_get_nr_pins(i) > +#define nr_ioapic_entries(i) iosapic_get_nr_pins(i) > #define __io_apic_read(apic, reg) \ > (*IO_APIC_BASE(apic) =3D reg, *(IO_APIC_BASE(apic)+4)) > #define __io_apic_write(apic, reg, val) \ > @@ -53,7 +53,7 @@ > #else > #include <asm/apic.h> > #include <asm/io_apic.h> > -#define nr_ioapic_registers(i) nr_ioapic_registers[i] > +#define nr_ioapic_entries(i) nr_ioapic_entries[i] > #endif > =20 > /* > @@ -91,7 +91,7 @@ static int init_apic_pin_2_ir_idx(void) > =20 > nr_pins =3D 0; > for ( i =3D 0; i < nr_ioapics; i++ ) > - nr_pins +=3D nr_ioapic_registers(i); > + nr_pins +=3D nr_ioapic_entries(i); > =20 > _apic_pin_2_ir_idx =3D xmalloc_array(int, nr_pins); > apic_pin_2_ir_idx =3D xmalloc_array(int *, nr_ioapics); > @@ -109,7 +109,7 @@ static int init_apic_pin_2_ir_idx(void) > for ( i =3D 0; i < nr_ioapics; i++ ) > { > apic_pin_2_ir_idx[i] =3D &_apic_pin_2_ir_idx[nr_pins]; > - nr_pins +=3D nr_ioapic_registers(i); > + nr_pins +=3D nr_ioapic_entries(i); > } > =20 > return 0; > diff -r a422e2a4451e -r 6896ad0a1798 xen/include/asm-x86/io_apic.h > --- a/xen/include/asm-x86/io_apic.h Sun Sep 18 00:26:52 2011 +0100 > +++ b/xen/include/asm-x86/io_apic.h Mon Sep 26 15:47:58 2011 +0100 > @@ -77,7 +77,7 @@ union IO_APIC_reg_03 { > * # of IO-APICs and # of IRQ routing registers > */ > extern int nr_ioapics; > -extern int nr_ioapic_registers[MAX_IO_APICS]; > +extern int nr_ioapic_entries[MAX_IO_APICS]; > =20 > enum ioapic_irq_destination_types { > dest_Fixed =3D 0, >=20 > _______________________________________________ > Xen-devel mailing list > Xen-devel@lists.xensource.com=20 > http://lists.xensource.com/xen-devel=20 _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel From xen-devel-bounces@lists.xensource.com Mon Sep 26 08:04:55 2011 Return-path: <xen-devel-bounces@lists.xensource.com> Envelope-to: www-data@lists.xensource.com Delivery-date: Mon, 26 Sep 2011 08:04:55 -0700 Received: from localhost ([127.0.0.1] helo=lists.colo.xensource.com) by lists.xensource.com with esmtp (Exim 4.43) id 1R8Cjm-0008L9-3f; Mon, 26 Sep 2011 08:04:54 -0700 Received: from mail182.messagelabs.com ([85.158.139.83]) by lists.xensource.com with smtp (Exim 4.43) id 1R8CfI-0007sm-B0 for xen-devel@lists.xensource.com; Mon, 26 Sep 2011 08:00:38 -0700 X-Env-Sender: anthony@overnetdata.com X-Msg-Ref: server-4.tower-182.messagelabs.com!1317049213!19787613!1 X-Originating-IP: [81.137.131.225] X-StarScan-Version: 6.4.1; banners=-,-,- X-VirusChecked: Checked Received: (qmail 21685 invoked from network); 26 Sep 2011 15:00:13 -0000 Received: from host81-137-131-225.in-addr.btopenworld.com (HELO zimbra.overnetdata.com) (81.137.131.225) by server-4.tower-182.messagelabs.com with SMTP; 26 Sep 2011 15:00:13 -0000 Received: from localhost (localhost.localdomain [127.0.0.1]) by zimbra.overnetdata.com (Postfix) with ESMTP id C79311619F1; Mon, 26 Sep 2011 16:00:12 +0100 (BST) X-Virus-Scanned: amavisd-new at overnetdata.com Received: from zimbra.overnetdata.com ([127.0.0.1]) by localhost (zimbra.overnetdata.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id benX68Jcpb8O; Mon, 26 Sep 2011 16:00:12 +0100 (BST) Received: from [192.168.1.60] (unknown [192.168.1.60]) by zimbra.overnetdata.com (Postfix) with ESMTPSA id 004971617A9; Mon, 26 Sep 2011 16:00:11 +0100 (BST) Message-ID: <4E809379.2090206@overnetdata.com> Date: Mon, 26 Sep 2011 16:00:09 +0100 From: Anthony Wright <anthony@overnetdata.com> User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:6.0.2) Gecko/20110902 Thunderbird/6.0.2 MIME-Version: 1.0 To: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com> Subject: Re: [Xen-devel] Getting mm.c errors from xl dmesg on certain hardware References: <4E7C5F8B.6050509@overnetdata.com> <20110923132940.GB19579@phenom.oracle.com> <4E7C9AEF.602@overnetdata.com> <20110926140241.GC4102@phenom.oracle.com> In-Reply-To: <20110926140241.GC4102@phenom.oracle.com> X-Enigmail-Version: 1.3.2 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com> X-BeenThere: xen-devel@lists.xensource.com X-Mailman-Version: 2.1.5 Precedence: list List-Id: Xen developer discussion <xen-devel.lists.xensource.com> List-Unsubscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe> List-Post: <mailto:xen-devel@lists.xensource.com> List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help> List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=subscribe> Sender: xen-devel-bounces@lists.xensource.com Errors-To: xen-devel-bounces@lists.xensource.com On 26/09/2011 15:02, Konrad Rzeszutek Wilk wrote: > On Fri, Sep 23, 2011 at 03:42:55PM +0100, Anthony Wright wrote: >> On 23/09/2011 14:29, Konrad Rzeszutek Wilk wrote: >>> On Fri, Sep 23, 2011 at 11:29:31AM +0100, Anthony Wright wrote: >>>> Konrad Rzeszutek Wilk wrote: >>>> >>>>>> (XEN) mm.c:907:d0 Error getting mfn 3a09c (pfn 55555555) from L1 entry 000000003a09c023 for l1e_owner=0, pg_owner=0 >>>>>> (XEN) mm.c:907:d0 Error getting mfn 3a09d (pfn 55555555) from L1 entry 000000003a09d023 for l1e_owner=0, pg_owner=0 >>>>>> (XEN) mm.c:907:d0 Error getting mfn 3a09e (pfn 55555555) from L1 entry 000000003a09e023 for l1e_owner=0, pg_owner=0 >>>>>> (XEN) mm.c:907:d0 Error getting mfn 3a09f (pfn 55555555) from L1 entry 000000003a09f023 for l1e_owner=0, pg_owner=0 >>>>>> (XEN) traps.c:2388:d0 Domain attempted WRMSR c0010004 from 0x0000ab23d6d622da to 0x000000000000abcd. >>>>> Do they show up during bootup? As in do you see those _when_ you launch your guests? >>>>> To figure out this particular issue you should try using 'console_to_ring' (so that >>>>> dom0 output and Xen output are mingled togehter) and also post this under a new subject >>>>> to not confuse this email thread. >>>> The messages show up during the initial dom0 boot, before any domUs are >>>> loaded. I've attached a second xl dmesg log which is similar to the >>>> first, but the numbers in the error messages are different. >>>> >>>> The messages are hardware dependant as I don't get them on another >>>> system with different hardware configuration but with identical software. >>>> >>>> The motherboard is a ASUS M2N68 AM PLUS, with 4GB of RAM. If I remove >>>> one of the sticks of ram to take it down to 2GB, the mm.c errors are no >>>> longer displayed, but I still get the traps.c message. >>>> >>> Um, you might want to include 'loglevel=9 console=hvc0 initcall_debug' on your Linux line >>> so the output from Linux kernel gets intermingled with the Xen. >>> >>>> mapping kernel into physical memory >>>> Xen: setup ISA identity maps >>>> about to get started... >>>> (XEN) mm.c:907:d0 Error getting mfn 3809c (pfn b602c) from L1 entry 000000003809c023 for l1e_owner=0, pg_owner=0 >>>> (XEN) mm.c:907:d0 Error getting mfn 3809d (pfn b602d) from L1 entry 000000003809d023 for l1e_owner=0, pg_owner=0 >>>> (XEN) mm.c:907:d0 Error getting mfn 3809e (pfn b602e) from L1 entry 000000003809e023 for l1e_owner=0, pg_owner=0 >>>> (XEN) mm.c:907:d0 Error getting mfn 3809f (pfn b602f) from L1 entry 000000003809f023 for l1e_owner=0, pg_owner=0 >>>> (XEN) traps.c:2388:d0 Domain attempted WRMSR c0010004 from 0x00009b27fe9726ca to 0x000000000000abcd. >> I ran with 'console_to_ring conring_size=65536' on the xen command line >> & 'debug loglevel=9 console=hvc0 initcall_debug' on the kernel command line. > For the fun of it, can you twiddle with dom0_mem=512MB just to see what transpires? I booted with dom0_mem=512MB on the xen command line (without the other debug parameters), and got the mm.c & traps.c message as before. > Nothing really jumps at me in regards to what could be at fault here. Is the .config > based on some distro? Or is it a distro's config? The .config is fairly home grown, but I've had a number of substantially different kernel configs and they all consistantly produce this error on this particular machine, but not on any other machines (aparts from the traps on the old Dell). This is the same machine that we had problems with the USB access (I've seen the problem once since, but can't reliably reproduce it). The system seems to work ok, but I worry when I see errors messages!! _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel From xen-devel-bounces@lists.xensource.com Mon Sep 26 08:08:35 2011 Return-path: <xen-devel-bounces@lists.xensource.com> Envelope-to: www-data@lists.xensource.com Delivery-date: Mon, 26 Sep 2011 08:08:35 -0700 Received: from localhost ([127.0.0.1] helo=lists.colo.xensource.com) by lists.xensource.com with esmtp (Exim 4.43) id 1R8CnK-0000Lb-Cc; Mon, 26 Sep 2011 08:08:34 -0700 Received: from mail27.messagelabs.com ([193.109.254.147]) by lists.xensource.com with smtp (Exim 4.43) id 1R8Cm2-00008J-R7 for xen-devel@lists.xensource.com; Mon, 26 Sep 2011 08:07:16 -0700 X-Env-Sender: anthony@overnetdata.com X-Msg-Ref: server-14.tower-27.messagelabs.com!1317049616!37684395!1 X-Originating-IP: [81.137.131.225] X-StarScan-Version: 6.4.1; banners=-,-,- X-VirusChecked: Checked Received: (qmail 26059 invoked from network); 26 Sep 2011 15:06:56 -0000 Received: from host81-137-131-225.in-addr.btopenworld.com (HELO zimbra.overnetdata.com) (81.137.131.225) by server-14.tower-27.messagelabs.com with SMTP; 26 Sep 2011 15:06:56 -0000 Received: from localhost (localhost.localdomain [127.0.0.1]) by zimbra.overnetdata.com (Postfix) with ESMTP id 5CAFE1619F1; Mon, 26 Sep 2011 16:07:11 +0100 (BST) X-Virus-Scanned: amavisd-new at overnetdata.com Received: from zimbra.overnetdata.com ([127.0.0.1]) by localhost (zimbra.overnetdata.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 47Dksbp1uUP2; Mon, 26 Sep 2011 16:07:10 +0100 (BST) Received: from [192.168.1.60] (unknown [192.168.1.60]) by zimbra.overnetdata.com (Postfix) with ESMTPSA id 5896D1617A9; Mon, 26 Sep 2011 16:07:10 +0100 (BST) Message-ID: <4E80951B.3000006@overnetdata.com> Date: Mon, 26 Sep 2011 16:07:07 +0100 From: Anthony Wright <anthony@overnetdata.com> User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:6.0.2) Gecko/20110902 Thunderbird/6.0.2 MIME-Version: 1.0 To: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com> Subject: Re: [Xen-devel] Getting IOAPIC errors in xl dmesg on old hardware References: <4E7C60B1.3000901@overnetdata.com> <20110923133341.GD19579@phenom.oracle.com> <4E7C8C00.2050806@overnetdata.com> <20110926135909.GB4102@phenom.oracle.com> In-Reply-To: <20110926135909.GB4102@phenom.oracle.com> X-Enigmail-Version: 1.3.2 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com> X-BeenThere: xen-devel@lists.xensource.com X-Mailman-Version: 2.1.5 Precedence: list List-Id: Xen developer discussion <xen-devel.lists.xensource.com> List-Unsubscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe> List-Post: <mailto:xen-devel@lists.xensource.com> List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help> List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=subscribe> Sender: xen-devel-bounces@lists.xensource.com Errors-To: xen-devel-bounces@lists.xensource.com On 26/09/2011 14:59, Konrad Rzeszutek Wilk wrote: > On Fri, Sep 23, 2011 at 02:39:12PM +0100, Anthony Wright wrote: >> On 23/09/2011 14:33, Konrad Rzeszutek Wilk wrote: >>> On Fri, Sep 23, 2011 at 11:34:25AM +0100, Anthony Wright wrote: >>>> I am getting a series of IOAPIC errors in xl dmesg on a Dell OptiPlex >>>> GX100 machine (bought in 2000). I also get an error from traps.c which >>>> is very similar to the one in the 'Getting mm.c errors from xl dmesg on >>>> certain hardware' thread. This happens during system startup with no >>>> DomUs running. I have attached the xl dmesg log. >>>> __ __ _ _ _ _ >>>> \ \/ /___ _ __ | || | / | / | >>>> \ // _ \ '_ \ | || |_ | | | | >>>> / \ __/ | | | |__ _|| |_| | >>>> /_/\_\___|_| |_| |_|(_)_(_)_| >>>> >>>> (XEN) Xen version 4.1.1 (@[unknown]) (gcc version 4.4.3 (GCC) ) Wed Sep 21 08:25:36 GMT 2011 >>>> (XEN) Latest ChangeSet: unavailable >>>> (XEN) Bootloader: GNU GRUB 0.97 >>>> (XEN) Command line: >>>> (XEN) Video information: >>>> (XEN) VGA is text mode 80x25, font 8x16 >>>> (XEN) VBE/DDC methods: V2; EDID transfer time: 1 seconds >>>> (XEN) Disc information: >>>> (XEN) Found 0 MBR signatures >>>> (XEN) Found 0 EDD information structures >>>> (XEN) Xen-e820 RAM map: >>>> (XEN) 0000000000000000 - 00000000000a0000 (usable) >>>> (XEN) 00000000000f0000 - 0000000000100000 (reserved) >>>> (XEN) 0000000000100000 - 000000001feae000 (usable) >>>> (XEN) 000000001feae000 - 0000000020000000 (reserved) >>>> (XEN) 00000000ffb00000 - 0000000100000000 (reserved) >>>> (XEN) System RAM: 510MB (522552kB) >>> Is that right? 512MB? >> Yup 512MB >> >> 3.4.1 with 2.6.18 works fine on it. 4.4.1 with 3.0.4 also seems to work >> fine, though it does seem to use an awful lot of ram (something I'm >> going to have a closer look at shortly). It's just that I get these > Probably Xen-SWIOTLB eating up 64MB, then there are the per_cpu maps > and whole bunch of other stuff.. >> error messages in 'xl dmesg', and wondered whether I can safely ignore >> them, or whether they're indicative of a more serious problem. > I am not sure what to tell you. Your hardware is well.. so old > that I am not going to take a look at this (from a Linux kernel perspective) > for a looooong loooooong time. I can understand where you're coming from, and since the system seems to work fine despite the errors I'm not too worried, but please don't discount systems just because they're old. Despite the fact that the system is over 10 years old, it's still quite a capable machine, I can run (or could with 3.4.1) dom0 in 128MB of ram leaving 380MB for DomUs. I've got a fair number of low memory, low cpu, paravirtualized DomUs that run quite happily on the machine. _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel From xen-devel-bounces@lists.xensource.com Mon Sep 26 08:16:23 2011 Return-path: <xen-devel-bounces@lists.xensource.com> Envelope-to: www-data@lists.xensource.com Delivery-date: Mon, 26 Sep 2011 08:16:23 -0700 Received: from localhost ([127.0.0.1] helo=lists.colo.xensource.com) by lists.xensource.com with esmtp (Exim 4.43) id 1R8Cut-0000wG-A7; Mon, 26 Sep 2011 08:16:23 -0700 Received: from mail27.messagelabs.com ([193.109.254.147]) by lists.xensource.com with esmtp (Exim 4.43) id 1R8Ctz-0000if-Sc for xen-devel@lists.xensource.com; Mon, 26 Sep 2011 08:15:28 -0700 X-Env-Sender: Andrew.Cooper3@citrix.com X-Msg-Ref: server-10.tower-27.messagelabs.com!1317050102!37291077!1 X-Originating-IP: [66.165.176.89] X-StarScan-Version: 6.4.1; banners=-,-,- X-VirusChecked: Checked Received: (qmail 903 invoked from network); 26 Sep 2011 15:15:03 -0000 Received: from smtp.citrix.com (HELO SMTP.CITRIX.COM) (66.165.176.89) by server-10.tower-27.messagelabs.com with RC4-SHA encrypted SMTP; 26 Sep 2011 15:15:03 -0000 X-IronPort-AV: E=Sophos;i="4.68,445,1312171200"; d="scan'208";a="17697745" Received: from ftlpmailmx02.citrite.net ([10.13.107.66]) by FTLPIPO01.CITRIX.COM with ESMTP/TLS/RC4-MD5; 26 Sep 2011 11:15:23 -0400 Received: from [10.80.2.18] (10.80.2.18) by FTLPMAILMX02.citrite.net (10.13.107.66) with Microsoft SMTP Server id 8.3.137.0; Mon, 26 Sep 2011 11:15:23 -0400 Message-ID: <4E809709.5060602@citrix.com> Date: Mon, 26 Sep 2011 16:15:21 +0100 From: Andrew Cooper <andrew.cooper3@citrix.com> User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.2.21) Gecko/20110831 Lightning/1.0b2 Thunderbird/3.1.13 MIME-Version: 1.0 To: Jan Beulich <JBeulich@suse.com> Subject: Re: [Xen-devel] [PATCH] IRQ Cleanup: rename nr_ioapic_registers to nr_ioapic_entries References: <6896ad0a17986a06a470.1317048538@andrewcoop.uk.xensource.com> <4E80AF140200007800057DA4@nat28.tlf.novell.com> In-Reply-To: <4E80AF140200007800057DA4@nat28.tlf.novell.com> Content-Type: text/plain; charset="ISO-8859-1" Content-Transfer-Encoding: 7bit Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com> X-BeenThere: xen-devel@lists.xensource.com X-Mailman-Version: 2.1.5 Precedence: list List-Id: Xen developer discussion <xen-devel.lists.xensource.com> List-Unsubscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe> List-Post: <mailto:xen-devel@lists.xensource.com> List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help> List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=subscribe> Sender: xen-devel-bounces@lists.xensource.com Errors-To: xen-devel-bounces@lists.xensource.com On 26/09/11 15:57, Jan Beulich wrote: >>>> On 26.09.11 at 16:48, Andrew Cooper <andrew.cooper3@citrix.com> wrote: >> The name "nr_ioapic_registers" is wrong and actively misleading. The >> variable holds the number of redirection entries for each apic, which >> is two registers fewer than the total number of registers. > To be honest, this is the kind of renaming that I wouldn't want to do > as long as Linux, from where the code originates, continues to use > the prior name (no matter whether you consider it misleading). > > Jan I guess it depends on whether you consider that we should stay in line with Linux or not. While the code did start in Linux, it has diverged so far that it really is its own file now. Either we should un-diverge from Linux (unlikely to happen), or consider it properly forked and not worry; staying in this intermediate state is not sustainable and leads to keeping misleading bits about while an overhaul is needed. ~Andrew >> Signed-off-by: Andrew Cooper <andrew.cooper3@citrix.com> >> >> diff -r a422e2a4451e -r 6896ad0a1798 xen/arch/x86/io_apic.c >> --- a/xen/arch/x86/io_apic.c Sun Sep 18 00:26:52 2011 +0100 >> +++ b/xen/arch/x86/io_apic.c Mon Sep 26 15:47:58 2011 +0100 >> @@ -58,7 +58,7 @@ s8 __read_mostly sis_apic_bug = -1; >> /* >> * # of IRQ routing registers >> */ >> -int __read_mostly nr_ioapic_registers[MAX_IO_APICS]; >> +int __read_mostly nr_ioapic_entries[MAX_IO_APICS]; >> int __read_mostly nr_ioapics; >> >> /* >> @@ -149,7 +149,7 @@ struct IO_APIC_route_entry **alloc_ioapi >> for (apic = 0; apic < nr_ioapics; apic++) { >> ioapic_entries[apic] = >> xmalloc_array(struct IO_APIC_route_entry, >> - nr_ioapic_registers[apic]); >> + nr_ioapic_entries[apic]); >> if (!ioapic_entries[apic]) >> goto nomem; >> } >> @@ -245,7 +245,7 @@ static void __io_apic_eoi(unsigned int a >> if ( pin == -1 ) >> { >> unsigned int p; >> - for ( p = 0; p < nr_ioapic_registers[apic]; ++p ) >> + for ( p = 0; p < nr_ioapic_entries[apic]; ++p ) >> { >> entry = __ioapic_read_entry(apic, p, TRUE); >> if ( entry.vector == vector ) >> @@ -328,7 +328,7 @@ int save_IO_APIC_setup(struct IO_APIC_ro >> if (!ioapic_entries[apic]) >> return -ENOMEM; >> >> - for (pin = 0; pin < nr_ioapic_registers[apic]; pin++) >> + for (pin = 0; pin < nr_ioapic_entries[apic]; pin++) >> ioapic_entries[apic][pin] = __ioapic_read_entry(apic, pin, 1); >> } >> >> @@ -349,7 +349,7 @@ void mask_IO_APIC_setup(struct IO_APIC_r >> if (!ioapic_entries[apic]) >> break; >> >> - for (pin = 0; pin < nr_ioapic_registers[apic]; pin++) { >> + for (pin = 0; pin < nr_ioapic_entries[apic]; pin++) { >> struct IO_APIC_route_entry entry; >> >> entry = ioapic_entries[apic][pin]; >> @@ -376,7 +376,7 @@ int restore_IO_APIC_setup(struct IO_APIC >> if (!ioapic_entries[apic]) >> return -ENOMEM; >> >> - for (pin = 0; pin < nr_ioapic_registers[apic]; pin++) >> + for (pin = 0; pin < nr_ioapic_entries[apic]; pin++) >> ioapic_write_entry(apic, pin, 1, ioapic_entries[apic][pin]); >> } >> >> @@ -524,7 +524,7 @@ static void clear_IO_APIC (void) >> int apic, pin; >> >> for (apic = 0; apic < nr_ioapics; apic++) { >> - for (pin = 0; pin < nr_ioapic_registers[apic]; pin++) >> + for (pin = 0; pin < nr_ioapic_entries[apic]; pin++) >> clear_IO_APIC_pin(apic, pin); >> } >> } >> @@ -785,7 +785,7 @@ void /*__init*/ setup_ioapic_dest(void) >> return; >> >> for (ioapic = 0; ioapic < nr_ioapics; ioapic++) { >> - for (pin = 0; pin < nr_ioapic_registers[ioapic]; pin++) { >> + for (pin = 0; pin < nr_ioapic_entries[ioapic]; pin++) { >> irq_entry = find_irq_entry(ioapic, pin, mp_INT); >> if (irq_entry == -1) >> continue; >> @@ -1031,7 +1031,7 @@ static int pin_2_irq(int idx, int apic, >> */ >> i = irq = 0; >> while (i < apic) >> - irq += nr_ioapic_registers[i++]; >> + irq += nr_ioapic_entries[i++]; >> irq += pin; >> break; >> } >> @@ -1051,7 +1051,7 @@ static inline int IO_APIC_irq_trigger(in >> int apic, idx, pin; >> >> for (apic = 0; apic < nr_ioapics; apic++) { >> - for (pin = 0; pin < nr_ioapic_registers[apic]; pin++) { >> + for (pin = 0; pin < nr_ioapic_entries[apic]; pin++) { >> idx = find_irq_entry(apic,pin,mp_INT); >> if ((idx != -1) && (irq == pin_2_irq(idx,apic,pin))) >> return irq_trigger(idx); >> @@ -1092,7 +1092,7 @@ static void __init setup_IO_APIC_irqs(vo >> apic_printk(APIC_VERBOSE, KERN_DEBUG "init IO_APIC IRQs\n"); >> >> for (apic = 0; apic < nr_ioapics; apic++) { >> - for (pin = 0; pin < nr_ioapic_registers[apic]; pin++) { >> + for (pin = 0; pin < nr_ioapic_entries[apic]; pin++) { >> >> /* >> * add it to the IO-APIC irq-routing table: >> @@ -1218,7 +1218,7 @@ static void /*__init*/ __print_IO_APIC(v >> printk(KERN_DEBUG "number of MP IRQ sources: %d.\n", mp_irq_entries); >> for (i = 0; i < nr_ioapics; i++) >> printk(KERN_DEBUG "number of IO-APIC #%d registers: %d.\n", >> - mp_ioapics[i].mpc_apicid, nr_ioapic_registers[i]); >> + mp_ioapics[i].mpc_apicid, nr_ioapic_entries[i]); >> >> /* >> * We are a bit conservative about what we expect. We have to >> @@ -1378,7 +1378,7 @@ static void __init enable_IO_APIC(void) >> for(apic = 0; apic < nr_ioapics; apic++) { >> int pin; >> /* See if any of the pins is in ExtINT mode */ >> - for (pin = 0; pin < nr_ioapic_registers[apic]; pin++) { >> + for (pin = 0; pin < nr_ioapic_entries[apic]; pin++) { >> struct IO_APIC_route_entry entry = ioapic_read_entry(apic, pin, >> 0); >> >> /* If the interrupt line is enabled and in ExtInt mode >> @@ -2116,7 +2116,7 @@ static void __init ioapic_pm_state_alloc >> int i, nr_entry = 0; >> >> for (i = 0; i < nr_ioapics; i++) >> - nr_entry += nr_ioapic_registers[i]; >> + nr_entry += nr_ioapic_entries[i]; >> >> ioapic_pm_state = _xmalloc(sizeof(struct IO_APIC_route_entry)*nr_entry, >> sizeof(struct IO_APIC_route_entry)); >> @@ -2158,7 +2158,7 @@ void ioapic_suspend(void) >> >> spin_lock_irqsave(&ioapic_lock, flags); >> for (apic = 0; apic < nr_ioapics; apic++) { >> - for (i = 0; i < nr_ioapic_registers[apic]; i ++, entry ++ ) { >> + for (i = 0; i < nr_ioapic_entries[apic]; i ++, entry ++ ) { >> *(((int *)entry) + 1) = __io_apic_read(apic, 0x11 + 2 * i); >> *(((int *)entry) + 0) = __io_apic_read(apic, 0x10 + 2 * i); >> } >> @@ -2180,7 +2180,7 @@ void ioapic_resume(void) >> reg_00.bits.ID = mp_ioapics[apic].mpc_apicid; >> __io_apic_write(apic, 0, reg_00.raw); >> } >> - for (i = 0; i < nr_ioapic_registers[apic]; i++, entry++) { >> + for (i = 0; i < nr_ioapic_entries[apic]; i++, entry++) { >> __io_apic_write(apic, 0x11+2*i, *(((int *)entry)+1)); >> __io_apic_write(apic, 0x10+2*i, *(((int *)entry)+0)); >> } >> @@ -2609,8 +2609,8 @@ void __init init_ioapic_mappings(void) >> { >> /* The number of IO-APIC IRQ registers (== #pins): */ >> reg_01.raw = io_apic_read(i, 1); >> - nr_ioapic_registers[i] = reg_01.bits.entries + 1; >> - nr_irqs_gsi += nr_ioapic_registers[i]; >> + nr_ioapic_entries[i] = reg_01.bits.entries + 1; >> + nr_irqs_gsi += nr_ioapic_entries[i]; >> } >> } >> >> diff -r a422e2a4451e -r 6896ad0a1798 xen/drivers/passthrough/amd/iommu_intr.c >> --- a/xen/drivers/passthrough/amd/iommu_intr.c Sun Sep 18 00:26:52 2011 +0100 >> +++ b/xen/drivers/passthrough/amd/iommu_intr.c Mon Sep 26 15:47:58 2011 +0100 >> @@ -165,7 +165,7 @@ int __init amd_iommu_setup_ioapic_remapp >> /* Read ioapic entries and update interrupt remapping table accordingly >> */ >> for ( apic = 0; apic < nr_ioapics; apic++ ) >> { >> - for ( pin = 0; pin < nr_ioapic_registers[apic]; pin++ ) >> + for ( pin = 0; pin < nr_ioapic_entries[apic]; pin++ ) >> { >> *(((int *)&rte) + 1) = io_apic_read(apic, 0x11 + 2 * pin); >> *(((int *)&rte) + 0) = io_apic_read(apic, 0x10 + 2 * pin); >> diff -r a422e2a4451e -r 6896ad0a1798 xen/drivers/passthrough/vtd/intremap.c >> --- a/xen/drivers/passthrough/vtd/intremap.c Sun Sep 18 00:26:52 2011 +0100 >> +++ b/xen/drivers/passthrough/vtd/intremap.c Mon Sep 26 15:47:58 2011 +0100 >> @@ -33,7 +33,7 @@ >> >> #ifdef __ia64__ >> #define nr_ioapics iosapic_get_nr_iosapics() >> -#define nr_ioapic_registers(i) iosapic_get_nr_pins(i) >> +#define nr_ioapic_entries(i) iosapic_get_nr_pins(i) >> #define __io_apic_read(apic, reg) \ >> (*IO_APIC_BASE(apic) = reg, *(IO_APIC_BASE(apic)+4)) >> #define __io_apic_write(apic, reg, val) \ >> @@ -53,7 +53,7 @@ >> #else >> #include <asm/apic.h> >> #include <asm/io_apic.h> >> -#define nr_ioapic_registers(i) nr_ioapic_registers[i] >> +#define nr_ioapic_entries(i) nr_ioapic_entries[i] >> #endif >> >> /* >> @@ -91,7 +91,7 @@ static int init_apic_pin_2_ir_idx(void) >> >> nr_pins = 0; >> for ( i = 0; i < nr_ioapics; i++ ) >> - nr_pins += nr_ioapic_registers(i); >> + nr_pins += nr_ioapic_entries(i); >> >> _apic_pin_2_ir_idx = xmalloc_array(int, nr_pins); >> apic_pin_2_ir_idx = xmalloc_array(int *, nr_ioapics); >> @@ -109,7 +109,7 @@ static int init_apic_pin_2_ir_idx(void) >> for ( i = 0; i < nr_ioapics; i++ ) >> { >> apic_pin_2_ir_idx[i] = &_apic_pin_2_ir_idx[nr_pins]; >> - nr_pins += nr_ioapic_registers(i); >> + nr_pins += nr_ioapic_entries(i); >> } >> >> return 0; >> diff -r a422e2a4451e -r 6896ad0a1798 xen/include/asm-x86/io_apic.h >> --- a/xen/include/asm-x86/io_apic.h Sun Sep 18 00:26:52 2011 +0100 >> +++ b/xen/include/asm-x86/io_apic.h Mon Sep 26 15:47:58 2011 +0100 >> @@ -77,7 +77,7 @@ union IO_APIC_reg_03 { >> * # of IO-APICs and # of IRQ routing registers >> */ >> extern int nr_ioapics; >> -extern int nr_ioapic_registers[MAX_IO_APICS]; >> +extern int nr_ioapic_entries[MAX_IO_APICS]; >> >> enum ioapic_irq_destination_types { >> dest_Fixed = 0, >> >> _______________________________________________ >> Xen-devel mailing list >> Xen-devel@lists.xensource.com >> http://lists.xensource.com/xen-devel > -- Andrew Cooper - Dom0 Kernel Engineer, Citrix XenServer T: +44 (0)1223 225 900, http://www.citrix.com _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel From xen-devel-bounces@lists.xensource.com Mon Sep 26 08:41:08 2011 Return-path: <xen-devel-bounces@lists.xensource.com> Envelope-to: www-data@lists.xensource.com Delivery-date: Mon, 26 Sep 2011 08:41:08 -0700 Received: from localhost ([127.0.0.1] helo=lists.colo.xensource.com) by lists.xensource.com with esmtp (Exim 4.43) id 1R8DIp-0001n4-TJ; Mon, 26 Sep 2011 08:41:07 -0700 Received: from mail27.messagelabs.com ([193.109.254.147]) by lists.xensource.com with esmtp (Exim 4.43) id 1R8DHz-0001Yw-9C for xen-devel@lists.xensource.com; Mon, 26 Sep 2011 08:40:15 -0700 X-Env-Sender: JBeulich@suse.com X-Msg-Ref: server-2.tower-27.messagelabs.com!1317051586!56509594!1 X-Originating-IP: [130.57.49.28] X-StarScan-Version: 6.4.1; banners=-,-,- X-VirusChecked: Checked Received: (qmail 20047 invoked from network); 26 Sep 2011 15:39:46 -0000 Received: from nat28.tlf.novell.com (HELO nat28.tlf.novell.com) (130.57.49.28) by server-2.tower-27.messagelabs.com with DHE-RSA-AES256-SHA encrypted SMTP; 26 Sep 2011 15:39:46 -0000 Received: from EMEA1-MTA by nat28.tlf.novell.com with Novell_GroupWise; Mon, 26 Sep 2011 16:40:12 +0100 Message-Id: <4E80B8F90200007800057DCE@nat28.tlf.novell.com> X-Mailer: Novell GroupWise Internet Agent 8.0.1 Date: Mon, 26 Sep 2011 16:40:09 +0100 From: "Jan Beulich" <JBeulich@suse.com> To: "Andrew Cooper" <andrew.cooper3@citrix.com> Subject: Re: [Xen-devel] [PATCH] IRQ Cleanup: rename nr_ioapic_registers to nr_ioapic_entries References: <6896ad0a17986a06a470.1317048538@andrewcoop.uk.xensource.com> <4E80AF140200007800057DA4@nat28.tlf.novell.com> <4E809709.5060602@citrix.com> In-Reply-To: <4E809709.5060602@citrix.com> Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: quoted-printable Content-Disposition: inline Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com> X-BeenThere: xen-devel@lists.xensource.com X-Mailman-Version: 2.1.5 Precedence: list List-Id: Xen developer discussion <xen-devel.lists.xensource.com> List-Unsubscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe> List-Post: <mailto:xen-devel@lists.xensource.com> List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help> List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=subscribe> Sender: xen-devel-bounces@lists.xensource.com Errors-To: xen-devel-bounces@lists.xensource.com >>> On 26.09.11 at 17:15, Andrew Cooper <andrew.cooper3@citrix.com> wrote: > On 26/09/11 15:57, Jan Beulich wrote: >>>>> On 26.09.11 at 16:48, Andrew Cooper <andrew.cooper3@citrix.com> = wrote: >>> The name "nr_ioapic_registers" is wrong and actively misleading. The >>> variable holds the number of redirection entries for each apic, which >>> is two registers fewer than the total number of registers. >> To be honest, this is the kind of renaming that I wouldn't want to do >> as long as Linux, from where the code originates, continues to use >> the prior name (no matter whether you consider it misleading). >> >> Jan >=20 > I guess it depends on whether you consider that we should stay in line > with Linux or not. While the code did start in Linux, it has diverged > so far that it really is its own file now. >=20 > Either we should un-diverge from Linux (unlikely to happen), or consider > it properly forked and not worry; staying in this intermediate state is > not sustainable and leads to keeping misleading bits about while an > overhaul is needed. There's one more alternative: You could propose the same renaming on Linux. Jan _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel From xen-devel-bounces@lists.xensource.com Mon Sep 26 08:46:10 2011 Return-path: <xen-devel-bounces@lists.xensource.com> Envelope-to: www-data@lists.xensource.com Delivery-date: Mon, 26 Sep 2011 08:46:10 -0700 Received: from localhost ([127.0.0.1] helo=lists.colo.xensource.com) by lists.xensource.com with esmtp (Exim 4.43) id 1R8DNi-0002Gm-JT; Mon, 26 Sep 2011 08:46:10 -0700 Received: from mail27.messagelabs.com ([193.109.254.147]) by lists.xensource.com with esmtp (Exim 4.43) id 1R8DN9-00023i-Fw for xen-devel@lists.xensource.com; Mon, 26 Sep 2011 08:45:36 -0700 X-Env-Sender: konrad@oracle.com X-Msg-Ref: server-9.tower-27.messagelabs.com!1317051913!46079030!1 X-Originating-IP: [148.87.113.117] X-StarScan-Version: 6.4.1; banners=-,-,- X-VirusChecked: Checked Received: (qmail 2086 invoked from network); 26 Sep 2011 15:45:14 -0000 Received: from rcsinet15.oracle.com (HELO rcsinet15.oracle.com) (148.87.113.117) by server-9.tower-27.messagelabs.com with DHE-RSA-AES256-SHA encrypted SMTP; 26 Sep 2011 15:45:14 -0000 Received: from acsinet21.oracle.com (acsinet21.oracle.com [141.146.126.237]) by rcsinet15.oracle.com (Switch-3.4.4/Switch-3.4.4) with ESMTP id p8QFjRwt001508 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Mon, 26 Sep 2011 15:45:28 GMT Received: from acsmt356.oracle.com (acsmt356.oracle.com [141.146.40.156]) by acsinet21.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id p8QFjQ6j027737 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 26 Sep 2011 15:45:26 GMT Received: from abhmt101.oracle.com (abhmt101.oracle.com [141.146.116.53]) by acsmt356.oracle.com (8.12.11.20060308/8.12.11) with ESMTP id p8QFjL2a015285; Mon, 26 Sep 2011 10:45:21 -0500 Received: from oracle.com (/209.6.55.207) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Mon, 26 Sep 2011 08:45:21 -0700 Received: by oracle.com (Postfix, from userid 1000) id 85F341551; Mon, 26 Sep 2011 11:45:14 -0400 (EDT) Date: Mon, 26 Sep 2011 11:45:14 -0400 From: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com> To: Andrew Cooper <andrew.cooper3@citrix.com> Subject: Re: [Xen-devel] [PATCH] IRQ Cleanup: rename nr_ioapic_registers to nr_ioapic_entries Message-ID: <20110926154514.GB17331@phenom.oracle.com> References: <6896ad0a17986a06a470.1317048538@andrewcoop.uk.xensource.com> <4E80AF140200007800057DA4@nat28.tlf.novell.com> <4E809709.5060602@citrix.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <4E809709.5060602@citrix.com> User-Agent: Mutt/1.5.21 (2010-09-15) X-Source-IP: acsinet21.oracle.com [141.146.126.237] X-Auth-Type: Internal IP X-CT-RefId: str=0001.0A090201.4E809E19.0153:SCFMA922111,ss=1,re=-6.300,fgs=0 Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>, Jan Beulich <JBeulich@suse.com> X-BeenThere: xen-devel@lists.xensource.com X-Mailman-Version: 2.1.5 Precedence: list List-Id: Xen developer discussion <xen-devel.lists.xensource.com> List-Unsubscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe> List-Post: <mailto:xen-devel@lists.xensource.com> List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help> List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=subscribe> Sender: xen-devel-bounces@lists.xensource.com Errors-To: xen-devel-bounces@lists.xensource.com On Mon, Sep 26, 2011 at 04:15:21PM +0100, Andrew Cooper wrote: > On 26/09/11 15:57, Jan Beulich wrote: > >>>> On 26.09.11 at 16:48, Andrew Cooper <andrew.cooper3@citrix.com> wrote: > >> The name "nr_ioapic_registers" is wrong and actively misleading. The > >> variable holds the number of redirection entries for each apic, which > >> is two registers fewer than the total number of registers. > > To be honest, this is the kind of renaming that I wouldn't want to do > > as long as Linux, from where the code originates, continues to use > > the prior name (no matter whether you consider it misleading). > > > > Jan > > I guess it depends on whether you consider that we should stay in line > with Linux or not. While the code did start in Linux, it has diverged Stay. Intel does a lot of work of "lift from Linux" and drop in Xen code. There is similarity. > so far that it really is its own file now. > > Either we should un-diverge from Linux (unlikely to happen), or consider > it properly forked and not worry; staying in this intermediate state is > not sustainable and leads to keeping misleading bits about while an > overhaul is needed. So maybe a solution is to provide a patch to the Linux code that would do the rename? And then you are in line? > > ~Andrew > > >> Signed-off-by: Andrew Cooper <andrew.cooper3@citrix.com> > >> > >> diff -r a422e2a4451e -r 6896ad0a1798 xen/arch/x86/io_apic.c > >> --- a/xen/arch/x86/io_apic.c Sun Sep 18 00:26:52 2011 +0100 > >> +++ b/xen/arch/x86/io_apic.c Mon Sep 26 15:47:58 2011 +0100 > >> @@ -58,7 +58,7 @@ s8 __read_mostly sis_apic_bug = -1; > >> /* > >> * # of IRQ routing registers > >> */ > >> -int __read_mostly nr_ioapic_registers[MAX_IO_APICS]; > >> +int __read_mostly nr_ioapic_entries[MAX_IO_APICS]; > >> int __read_mostly nr_ioapics; > >> > >> /* > >> @@ -149,7 +149,7 @@ struct IO_APIC_route_entry **alloc_ioapi > >> for (apic = 0; apic < nr_ioapics; apic++) { > >> ioapic_entries[apic] = > >> xmalloc_array(struct IO_APIC_route_entry, > >> - nr_ioapic_registers[apic]); > >> + nr_ioapic_entries[apic]); > >> if (!ioapic_entries[apic]) > >> goto nomem; > >> } > >> @@ -245,7 +245,7 @@ static void __io_apic_eoi(unsigned int a > >> if ( pin == -1 ) > >> { > >> unsigned int p; > >> - for ( p = 0; p < nr_ioapic_registers[apic]; ++p ) > >> + for ( p = 0; p < nr_ioapic_entries[apic]; ++p ) > >> { > >> entry = __ioapic_read_entry(apic, p, TRUE); > >> if ( entry.vector == vector ) > >> @@ -328,7 +328,7 @@ int save_IO_APIC_setup(struct IO_APIC_ro > >> if (!ioapic_entries[apic]) > >> return -ENOMEM; > >> > >> - for (pin = 0; pin < nr_ioapic_registers[apic]; pin++) > >> + for (pin = 0; pin < nr_ioapic_entries[apic]; pin++) > >> ioapic_entries[apic][pin] = __ioapic_read_entry(apic, pin, 1); > >> } > >> > >> @@ -349,7 +349,7 @@ void mask_IO_APIC_setup(struct IO_APIC_r > >> if (!ioapic_entries[apic]) > >> break; > >> > >> - for (pin = 0; pin < nr_ioapic_registers[apic]; pin++) { > >> + for (pin = 0; pin < nr_ioapic_entries[apic]; pin++) { > >> struct IO_APIC_route_entry entry; > >> > >> entry = ioapic_entries[apic][pin]; > >> @@ -376,7 +376,7 @@ int restore_IO_APIC_setup(struct IO_APIC > >> if (!ioapic_entries[apic]) > >> return -ENOMEM; > >> > >> - for (pin = 0; pin < nr_ioapic_registers[apic]; pin++) > >> + for (pin = 0; pin < nr_ioapic_entries[apic]; pin++) > >> ioapic_write_entry(apic, pin, 1, ioapic_entries[apic][pin]); > >> } > >> > >> @@ -524,7 +524,7 @@ static void clear_IO_APIC (void) > >> int apic, pin; > >> > >> for (apic = 0; apic < nr_ioapics; apic++) { > >> - for (pin = 0; pin < nr_ioapic_registers[apic]; pin++) > >> + for (pin = 0; pin < nr_ioapic_entries[apic]; pin++) > >> clear_IO_APIC_pin(apic, pin); > >> } > >> } > >> @@ -785,7 +785,7 @@ void /*__init*/ setup_ioapic_dest(void) > >> return; > >> > >> for (ioapic = 0; ioapic < nr_ioapics; ioapic++) { > >> - for (pin = 0; pin < nr_ioapic_registers[ioapic]; pin++) { > >> + for (pin = 0; pin < nr_ioapic_entries[ioapic]; pin++) { > >> irq_entry = find_irq_entry(ioapic, pin, mp_INT); > >> if (irq_entry == -1) > >> continue; > >> @@ -1031,7 +1031,7 @@ static int pin_2_irq(int idx, int apic, > >> */ > >> i = irq = 0; > >> while (i < apic) > >> - irq += nr_ioapic_registers[i++]; > >> + irq += nr_ioapic_entries[i++]; > >> irq += pin; > >> break; > >> } > >> @@ -1051,7 +1051,7 @@ static inline int IO_APIC_irq_trigger(in > >> int apic, idx, pin; > >> > >> for (apic = 0; apic < nr_ioapics; apic++) { > >> - for (pin = 0; pin < nr_ioapic_registers[apic]; pin++) { > >> + for (pin = 0; pin < nr_ioapic_entries[apic]; pin++) { > >> idx = find_irq_entry(apic,pin,mp_INT); > >> if ((idx != -1) && (irq == pin_2_irq(idx,apic,pin))) > >> return irq_trigger(idx); > >> @@ -1092,7 +1092,7 @@ static void __init setup_IO_APIC_irqs(vo > >> apic_printk(APIC_VERBOSE, KERN_DEBUG "init IO_APIC IRQs\n"); > >> > >> for (apic = 0; apic < nr_ioapics; apic++) { > >> - for (pin = 0; pin < nr_ioapic_registers[apic]; pin++) { > >> + for (pin = 0; pin < nr_ioapic_entries[apic]; pin++) { > >> > >> /* > >> * add it to the IO-APIC irq-routing table: > >> @@ -1218,7 +1218,7 @@ static void /*__init*/ __print_IO_APIC(v > >> printk(KERN_DEBUG "number of MP IRQ sources: %d.\n", mp_irq_entries); > >> for (i = 0; i < nr_ioapics; i++) > >> printk(KERN_DEBUG "number of IO-APIC #%d registers: %d.\n", > >> - mp_ioapics[i].mpc_apicid, nr_ioapic_registers[i]); > >> + mp_ioapics[i].mpc_apicid, nr_ioapic_entries[i]); > >> > >> /* > >> * We are a bit conservative about what we expect. We have to > >> @@ -1378,7 +1378,7 @@ static void __init enable_IO_APIC(void) > >> for(apic = 0; apic < nr_ioapics; apic++) { > >> int pin; > >> /* See if any of the pins is in ExtINT mode */ > >> - for (pin = 0; pin < nr_ioapic_registers[apic]; pin++) { > >> + for (pin = 0; pin < nr_ioapic_entries[apic]; pin++) { > >> struct IO_APIC_route_entry entry = ioapic_read_entry(apic, pin, > >> 0); > >> > >> /* If the interrupt line is enabled and in ExtInt mode > >> @@ -2116,7 +2116,7 @@ static void __init ioapic_pm_state_alloc > >> int i, nr_entry = 0; > >> > >> for (i = 0; i < nr_ioapics; i++) > >> - nr_entry += nr_ioapic_registers[i]; > >> + nr_entry += nr_ioapic_entries[i]; > >> > >> ioapic_pm_state = _xmalloc(sizeof(struct IO_APIC_route_entry)*nr_entry, > >> sizeof(struct IO_APIC_route_entry)); > >> @@ -2158,7 +2158,7 @@ void ioapic_suspend(void) > >> > >> spin_lock_irqsave(&ioapic_lock, flags); > >> for (apic = 0; apic < nr_ioapics; apic++) { > >> - for (i = 0; i < nr_ioapic_registers[apic]; i ++, entry ++ ) { > >> + for (i = 0; i < nr_ioapic_entries[apic]; i ++, entry ++ ) { > >> *(((int *)entry) + 1) = __io_apic_read(apic, 0x11 + 2 * i); > >> *(((int *)entry) + 0) = __io_apic_read(apic, 0x10 + 2 * i); > >> } > >> @@ -2180,7 +2180,7 @@ void ioapic_resume(void) > >> reg_00.bits.ID = mp_ioapics[apic].mpc_apicid; > >> __io_apic_write(apic, 0, reg_00.raw); > >> } > >> - for (i = 0; i < nr_ioapic_registers[apic]; i++, entry++) { > >> + for (i = 0; i < nr_ioapic_entries[apic]; i++, entry++) { > >> __io_apic_write(apic, 0x11+2*i, *(((int *)entry)+1)); > >> __io_apic_write(apic, 0x10+2*i, *(((int *)entry)+0)); > >> } > >> @@ -2609,8 +2609,8 @@ void __init init_ioapic_mappings(void) > >> { > >> /* The number of IO-APIC IRQ registers (== #pins): */ > >> reg_01.raw = io_apic_read(i, 1); > >> - nr_ioapic_registers[i] = reg_01.bits.entries + 1; > >> - nr_irqs_gsi += nr_ioapic_registers[i]; > >> + nr_ioapic_entries[i] = reg_01.bits.entries + 1; > >> + nr_irqs_gsi += nr_ioapic_entries[i]; > >> } > >> } > >> > >> diff -r a422e2a4451e -r 6896ad0a1798 xen/drivers/passthrough/amd/iommu_intr.c > >> --- a/xen/drivers/passthrough/amd/iommu_intr.c Sun Sep 18 00:26:52 2011 +0100 > >> +++ b/xen/drivers/passthrough/amd/iommu_intr.c Mon Sep 26 15:47:58 2011 +0100 > >> @@ -165,7 +165,7 @@ int __init amd_iommu_setup_ioapic_remapp > >> /* Read ioapic entries and update interrupt remapping table accordingly > >> */ > >> for ( apic = 0; apic < nr_ioapics; apic++ ) > >> { > >> - for ( pin = 0; pin < nr_ioapic_registers[apic]; pin++ ) > >> + for ( pin = 0; pin < nr_ioapic_entries[apic]; pin++ ) > >> { > >> *(((int *)&rte) + 1) = io_apic_read(apic, 0x11 + 2 * pin); > >> *(((int *)&rte) + 0) = io_apic_read(apic, 0x10 + 2 * pin); > >> diff -r a422e2a4451e -r 6896ad0a1798 xen/drivers/passthrough/vtd/intremap.c > >> --- a/xen/drivers/passthrough/vtd/intremap.c Sun Sep 18 00:26:52 2011 +0100 > >> +++ b/xen/drivers/passthrough/vtd/intremap.c Mon Sep 26 15:47:58 2011 +0100 > >> @@ -33,7 +33,7 @@ > >> > >> #ifdef __ia64__ > >> #define nr_ioapics iosapic_get_nr_iosapics() > >> -#define nr_ioapic_registers(i) iosapic_get_nr_pins(i) > >> +#define nr_ioapic_entries(i) iosapic_get_nr_pins(i) > >> #define __io_apic_read(apic, reg) \ > >> (*IO_APIC_BASE(apic) = reg, *(IO_APIC_BASE(apic)+4)) > >> #define __io_apic_write(apic, reg, val) \ > >> @@ -53,7 +53,7 @@ > >> #else > >> #include <asm/apic.h> > >> #include <asm/io_apic.h> > >> -#define nr_ioapic_registers(i) nr_ioapic_registers[i] > >> +#define nr_ioapic_entries(i) nr_ioapic_entries[i] > >> #endif > >> > >> /* > >> @@ -91,7 +91,7 @@ static int init_apic_pin_2_ir_idx(void) > >> > >> nr_pins = 0; > >> for ( i = 0; i < nr_ioapics; i++ ) > >> - nr_pins += nr_ioapic_registers(i); > >> + nr_pins += nr_ioapic_entries(i); > >> > >> _apic_pin_2_ir_idx = xmalloc_array(int, nr_pins); > >> apic_pin_2_ir_idx = xmalloc_array(int *, nr_ioapics); > >> @@ -109,7 +109,7 @@ static int init_apic_pin_2_ir_idx(void) > >> for ( i = 0; i < nr_ioapics; i++ ) > >> { > >> apic_pin_2_ir_idx[i] = &_apic_pin_2_ir_idx[nr_pins]; > >> - nr_pins += nr_ioapic_registers(i); > >> + nr_pins += nr_ioapic_entries(i); > >> } > >> > >> return 0; > >> diff -r a422e2a4451e -r 6896ad0a1798 xen/include/asm-x86/io_apic.h > >> --- a/xen/include/asm-x86/io_apic.h Sun Sep 18 00:26:52 2011 +0100 > >> +++ b/xen/include/asm-x86/io_apic.h Mon Sep 26 15:47:58 2011 +0100 > >> @@ -77,7 +77,7 @@ union IO_APIC_reg_03 { > >> * # of IO-APICs and # of IRQ routing registers > >> */ > >> extern int nr_ioapics; > >> -extern int nr_ioapic_registers[MAX_IO_APICS]; > >> +extern int nr_ioapic_entries[MAX_IO_APICS]; > >> > >> enum ioapic_irq_destination_types { > >> dest_Fixed = 0, > >> > >> _______________________________________________ > >> Xen-devel mailing list > >> Xen-devel@lists.xensource.com > >> http://lists.xensource.com/xen-devel > > > > -- > Andrew Cooper - Dom0 Kernel Engineer, Citrix XenServer > T: +44 (0)1223 225 900, http://www.citrix.com > > > _______________________________________________ > Xen-devel mailing list > Xen-devel@lists.xensource.com > http://lists.xensource.com/xen-devel _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel From xen-devel-bounces@lists.xensource.com Mon Sep 26 08:48:17 2011 Return-path: <xen-devel-bounces@lists.xensource.com> Envelope-to: www-data@lists.xensource.com Delivery-date: Mon, 26 Sep 2011 08:48:17 -0700 Received: from localhost ([127.0.0.1] helo=lists.colo.xensource.com) by lists.xensource.com with esmtp (Exim 4.43) id 1R8DPl-0002kN-A7; Mon, 26 Sep 2011 08:48:17 -0700 Received: from mail174.messagelabs.com ([85.158.138.51]) by lists.xensource.com with esmtp (Exim 4.43) id 1R8DNm-0002HY-Fq for xen-devel@lists.xensource.com; Mon, 26 Sep 2011 08:46:14 -0700 X-Env-Sender: konrad@oracle.com X-Msg-Ref: server-7.tower-174.messagelabs.com!1317051969!32787230!1 X-Originating-IP: [148.87.113.117] X-StarScan-Version: 6.4.1; banners=-,-,- X-VirusChecked: Checked Received: (qmail 2009 invoked from network); 26 Sep 2011 15:46:10 -0000 Received: from rcsinet15.oracle.com (HELO rcsinet15.oracle.com) (148.87.113.117) by server-7.tower-174.messagelabs.com with DHE-RSA-AES256-SHA encrypted SMTP; 26 Sep 2011 15:46:10 -0000 Received: from ucsinet23.oracle.com (ucsinet23.oracle.com [156.151.31.71]) by rcsinet15.oracle.com (Switch-3.4.4/Switch-3.4.4) with ESMTP id p8QFk6lK002473 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Mon, 26 Sep 2011 15:46:07 GMT Received: from acsmt356.oracle.com (acsmt356.oracle.com [141.146.40.156]) by ucsinet23.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id p8QFk5J9025486 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 26 Sep 2011 15:46:05 GMT Received: from abhmt111.oracle.com (abhmt111.oracle.com [141.146.116.63]) by acsmt356.oracle.com (8.12.11.20060308/8.12.11) with ESMTP id p8QFk0UP015792; Mon, 26 Sep 2011 10:46:00 -0500 Received: from oracle.com (/209.6.55.207) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Mon, 26 Sep 2011 08:46:00 -0700 Received: by oracle.com (Postfix, from userid 1000) id 92AD91551; Mon, 26 Sep 2011 11:45:53 -0400 (EDT) Date: Mon, 26 Sep 2011 11:45:53 -0400 From: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com> To: George Dunlap <dunlapg@umich.edu> Subject: Re: [Xen-devel] [RFC] SubmittingXenPatches wiki page Message-ID: <20110926154553.GA3002@phenom.oracle.com> References: <CAFLBxZbHvhK2U1+1i5UFYhJ9SLDLzx2kdmc-C8qnUbXb-eGsQw@mail.gmail.com> <20110926133022.GA3840@phenom.oracle.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20110926133022.GA3840@phenom.oracle.com> User-Agent: Mutt/1.5.21 (2010-09-15) X-Source-IP: ucsinet23.oracle.com [156.151.31.71] X-CT-RefId: str=0001.0A090201.4E809E41.0004,ss=1,re=0.000,fgs=0 Cc: xen-devel@lists.xensource.com X-BeenThere: xen-devel@lists.xensource.com X-Mailman-Version: 2.1.5 Precedence: list List-Id: Xen developer discussion <xen-devel.lists.xensource.com> List-Unsubscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe> List-Post: <mailto:xen-devel@lists.xensource.com> List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help> List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=subscribe> Sender: xen-devel-bounces@lists.xensource.com Errors-To: xen-devel-bounces@lists.xensource.com On Mon, Sep 26, 2011 at 09:30:22AM -0400, Konrad Rzeszutek Wilk wrote: > On Mon, Sep 26, 2011 at 12:43:59PM +0100, George Dunlap wrote: > > I've made a new version of the SubmittingXenPatches wiki page that > > suggest using mercurial queues and patchbomb extension, instead of the > > rather daft "clone a repository, commit changes, and then do hg > > export" method. > > > > I created it here: > > http://wiki.xensource.com/xenwiki/SubmittingXenPatches2 > > > > Please skim it and comment on it. If there are no objections, I shall > > replace the original SubmittingXenPatches in a few days. > > might want to add: > > [ui] > username = Konrad Rzeszutek Wilk <konrad.wilk@oracle.com> Ignore me please. Saw that later on in the Wiki you had that. So +1. _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel From xen-api-bounces@lists.xensource.com Mon Sep 26 09:03:04 2011 Return-path: <xen-api-bounces@lists.xensource.com> Envelope-to: www-data@lists.xensource.com Delivery-date: Mon, 26 Sep 2011 09:03:04 -0700 Received: from localhost ([127.0.0.1] helo=lists.colo.xensource.com) by lists.xensource.com with esmtp (Exim 4.43) id 1R8De3-0003KI-Lc; Mon, 26 Sep 2011 09:03:03 -0700 Received: from mail21.messagelabs.com ([85.158.143.35]) by lists.xensource.com with esmtp (Exim 4.43) id 1R8Da2-00036z-Di; Mon, 26 Sep 2011 09:00:31 -0700 X-Env-Sender: torushikeshj@gmail.com X-Msg-Ref: server-15.tower-21.messagelabs.com!1317052727!52034945!1 X-Originating-IP: [209.85.210.49] X-StarScan-Version: 6.4.1; banners=-,-,- X-VirusChecked: Checked Received: (qmail 23890 invoked from network); 26 Sep 2011 15:58:49 -0000 Received: from mail-pz0-f49.google.com (HELO mail-pz0-f49.google.com) (209.85.210.49) by server-15.tower-21.messagelabs.com with RC4-SHA encrypted SMTP; 26 Sep 2011 15:58:49 -0000 Received: by pzk34 with SMTP id 34so15324371pzk.8 for <multiple recipients>; Mon, 26 Sep 2011 08:58:45 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=nmMkMSFNAjIxg/YOSCrVIx8tMkCzewidaeFVbNcehCk=; b=gkLH1zYbyqMZ+8+6tHRn0wi8w2IZdz4gTQvdUDGTVFEapch8EPneBwK+N8vMjQ32/N sM24LqvySgwjXGEML0mMao9KefhsTnTikYbrs+noGEP/M80wF81XrQZw6QkXQc2C8Pd3 IY66c7S7tjn8HNuQzQOGEHk6YH7VA0O62nJ3M= MIME-Version: 1.0 Received: by 10.68.29.138 with SMTP id k10mr30289973pbh.70.1317052725374; Mon, 26 Sep 2011 08:58:45 -0700 (PDT) Received: by 10.143.90.4 with HTTP; Mon, 26 Sep 2011 08:58:45 -0700 (PDT) In-Reply-To: <4E8024E5.9020406@citrix.com> References: <CAO14VsP9by7CYgSiVN-hY0rJpDk0MYjuJ+FD5Tp3i8w+BcNYHw@mail.gmail.com> <4E8024E5.9020406@citrix.com> Date: Mon, 26 Sep 2011 21:28:45 +0530 Message-ID: <CAO14VsMXGyNjbgF0PiJ5MLH_HGwMA6M8yN0Z3Vq5e7tE-tW1bw@mail.gmail.com> Subject: Re: [Xen-API] FT for XCP From: R J <torushikeshj@gmail.com> To: Mike McClurg <mike.mcclurg@citrix.com> Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>, "xen-users@lists.xensource.com" <xen-users@lists.xensource.com>, "xen-api@lists.xensource.com" <xen-api@lists.xensource.com> X-BeenThere: xen-api@lists.xensource.com X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussion of API issues surrounding Xen <xen-api.lists.xensource.com> List-Unsubscribe: <http://lists.xensource.com/mailman/listinfo/xen-api>, <mailto:xen-api-request@lists.xensource.com?subject=unsubscribe> List-Post: <mailto:xen-api@lists.xensource.com> List-Help: <mailto:xen-api-request@lists.xensource.com?subject=help> List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-api>, <mailto:xen-api-request@lists.xensource.com?subject=subscribe> Content-Type: multipart/mixed; boundary="===============0209354065==" Sender: xen-api-bounces@lists.xensource.com Errors-To: xen-api-bounces@lists.xensource.com --===============0209354065== Content-Type: multipart/alternative; boundary=bcaec520ead3d8af8904adda3bfc --bcaec520ead3d8af8904adda3bfc Content-Type: text/plain; charset=ISO-8859-1 Hello Mike, Thank you for suggestion. I would love to incorporate remus in xapi if thats possible. Remus as its inbuilt logic of detecting checkpoint failure and taking decisions accordingly. I think there is remus support for xen 3.4 What do you suggest as my next step ? Regards, Rushikesh On Mon, Sep 26, 2011 at 12:38 PM, Mike McClurg <mike.mcclurg@citrix.com>wrote: > On 09/25/2011 09:11 PM, R J wrote: > > Hello List, > > I have a proposal and wont mind to implement my self but need a helping > hand to start on. > I want to implement the aggressive FT feature in XCP. The best way I could > imagine is the use of feature *Live Migration* > > Steps > 1. Enable the FT of a particular VM using xe commands and adding as a param > to that VM e.g. xe vm-param-set FT=true uuid=XYZ > 2. If the FT = true detected by xenstore then xapi will initiate a live > migrate of that VM to any of available host. > 3. A parallel "network ping"/"xapi heartbit" from/to that host could be > initialized for each FT VM. > 4. Live migrate will run forever until its disabled by FT = false or one of > the host is down. e.g. the process will loop at 99.99% migration state > 5. If there is a packet drop of x packets the VM Migrate procedure will > mark the VM Migration as Complete and will switch the devices forcefully. > -- this could result in some data loss but I dont have any alternative to > this. > -- The specific x packets can be set by XCP but we cant rely for default > XCP Errors > 6. If there is a successful migration due to host down then we will again > start from step2 > > Above steps I have assumed to my knowledge, we can discuss the problems in > it. > > Apologies if I'm being too naive. > > Regards, > Rushikesh > > This sounds like Remus (http://nss.cs.ubc.ca/remus/). Are you proposing > to implement Remus support in xapi? > > Mike > --bcaec520ead3d8af8904adda3bfc Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Hello Mike,<br><br>Thank you for suggestion. I would love to incorporate re= mus in xapi if thats possible.<br>Remus as its inbuilt logic of detecting c= heckpoint failure and taking decisions accordingly.<br><br>I think there is= remus support for xen 3.4<br> <br>What do you suggest as my next step ?<br><br>Regards,<br>Rushikesh<br><= br><br><br><div class=3D"gmail_quote">On Mon, Sep 26, 2011 at 12:38 PM, Mik= e McClurg <span dir=3D"ltr"><<a href=3D"mailto:mike.mcclurg@citrix.com">= mike.mcclurg@citrix.com</a>></span> wrote:<br> <blockquote class=3D"gmail_quote" style=3D"margin: 0pt 0pt 0pt 0.8ex; borde= r-left: 1px solid rgb(204, 204, 204); padding-left: 1ex;"> =20 =20 =20 <div bgcolor=3D"#FFFFFF" text=3D"#000000"><div><div></div><div class=3D"h= 5"> On 09/25/2011 09:11 PM, R J wrote: <blockquote type=3D"cite">Hello List,<br> <br> I have a proposal and wont mind to implement my self but need a helping hand to start on.<br> I want to implement the aggressive FT feature in XCP. The best way I could imagine is the use of feature *Live Migration*<br> <br> Steps<br> 1. Enable the FT of a particular VM using xe commands and adding as a param to that VM e.g. xe vm-param-set FT=3Dtrue uuid=3DXYZ<br> 2. If the FT =3D true detected by xenstore then xapi will initiate a live migrate of that VM to any of available host.<br> 3. A parallel "network ping"/"xapi heartbit" from= /to that host could be initialized for each FT VM.<br> 4. Live migrate will run forever until its disabled by FT =3D false or one of the host is down. e.g. the process will loop at 99.99% migration state<br> 5. If there is a packet drop of x packets the VM Migrate procedure will mark the VM Migration as Complete and will switch the devices forcefully.<br> -- this could result in some data loss but I dont have any alternative to this.<br> -- The specific x packets can be set by XCP but we cant rely for default XCP Errors<br> 6. If there is a successful migration due to host down then we will again start from step2<br> <br> Above steps I have assumed to my knowledge, we can discuss the problems in it.<br> <br> Apologies if I'm being too naive.<br> <br> Regards,<br> Rushikesh<br> <br> </blockquote> </div></div><font size=3D"-1">This sounds like Remus (<a href=3D"http://nss.cs.ubc.ca/remus/" target=3D"_blank">http://nss= .cs.ubc.ca/remus/</a>). Are you proposing to implement Remus support in xapi?<br><font color=3D"#888888"> <br> Mike<br> </font></font> </div> </blockquote></div><br> --bcaec520ead3d8af8904adda3bfc-- --===============0209354065== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ xen-api mailing list xen-api@lists.xensource.com http://lists.xensource.com/mailman/listinfo/xen-api --===============0209354065==-- From xen-devel-bounces@lists.xensource.com Mon Sep 26 09:14:45 2011 Return-path: <xen-devel-bounces@lists.xensource.com> Envelope-to: www-data@lists.xensource.com Delivery-date: Mon, 26 Sep 2011 09:14:45 -0700 Received: from localhost ([127.0.0.1] helo=lists.colo.xensource.com) by lists.xensource.com with esmtp (Exim 4.43) id 1R8DpM-0004sx-Sm; Mon, 26 Sep 2011 09:14:45 -0700 Received: from mail216.messagelabs.com ([85.158.143.99]) by lists.xensource.com with esmtp (Exim 4.43) id 1R8DoU-0004gR-6D for xen-devel@lists.xensource.com; Mon, 26 Sep 2011 09:13:50 -0700 X-Env-Sender: dunlapg@gmail.com X-Msg-Ref: server-4.tower-216.messagelabs.com!1317053627!19623527!1 X-Originating-IP: [74.125.82.43] X-StarScan-Version: 6.4.1; banners=-,-,- X-VirusChecked: Checked Received: (qmail 5213 invoked from network); 26 Sep 2011 16:13:47 -0000 Received: from mail-ww0-f43.google.com (HELO mail-ww0-f43.google.com) (74.125.82.43) by server-4.tower-216.messagelabs.com with RC4-SHA encrypted SMTP; 26 Sep 2011 16:13:47 -0000 Received: by wwf27 with SMTP id 27so5577202wwf.24 for <xen-devel@lists.xensource.com>; Mon, 26 Sep 2011 09:13:47 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type; bh=+ELnNOuTZjvOALB+zmjEiDwKRsSfr3FI4U31Dk2E+ss=; b=ab3yfirMQFlHCrMwbk/YlYseop3faNV4uJKrKon1zQ+1xzQWndIwb+qQb/k6b7ELDI PHdG25EzqBYVEM3bbaNZWadLrXbwOrEM/ax5pY1jplBMDpBAmVMlJswgWL2Aw3uI7xWq wYG8Tq9ykoS2v6knbb4AiVQhvr4x0nXlEW6eo= MIME-Version: 1.0 Received: by 10.216.229.202 with SMTP id h52mr2320739weq.111.1317053626939; Mon, 26 Sep 2011 09:13:46 -0700 (PDT) Received: by 10.216.176.81 with HTTP; Mon, 26 Sep 2011 09:13:46 -0700 (PDT) In-Reply-To: <20110926154553.GA3002@phenom.oracle.com> References: <CAFLBxZbHvhK2U1+1i5UFYhJ9SLDLzx2kdmc-C8qnUbXb-eGsQw@mail.gmail.com> <20110926133022.GA3840@phenom.oracle.com> <20110926154553.GA3002@phenom.oracle.com> Date: Mon, 26 Sep 2011 17:13:46 +0100 X-Google-Sender-Auth: KsA5P5gNBklB0OdoZfam0xRDUC4 Message-ID: <CAFLBxZY9Y=5oPF20WnApXWV+dhk=bOePsbVPEM2M3416ffBE+Q@mail.gmail.com> Subject: Re: [Xen-devel] [RFC] SubmittingXenPatches wiki page From: George Dunlap <dunlapg@umich.edu> To: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com> Content-Type: text/plain; charset=ISO-8859-1 Cc: xen-devel@lists.xensource.com X-BeenThere: xen-devel@lists.xensource.com X-Mailman-Version: 2.1.5 Precedence: list List-Id: Xen developer discussion <xen-devel.lists.xensource.com> List-Unsubscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe> List-Post: <mailto:xen-devel@lists.xensource.com> List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help> List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=subscribe> Sender: xen-devel-bounces@lists.xensource.com Errors-To: xen-devel-bounces@lists.xensource.com On Mon, Sep 26, 2011 at 4:45 PM, Konrad Rzeszutek Wilk <konrad.wilk@oracle.com> wrote: >> [ui] >> username = Konrad Rzeszutek Wilk <konrad.wilk@oracle.com> > > Ignore me please. Saw that later on in the Wiki you had that. > So +1. But it's probably worthwhile having it in before then anyway. I'll see what I can do. Thanks! -George _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel From xen-devel-bounces@lists.xensource.com Mon Sep 26 09:26:23 2011 Return-path: <xen-devel-bounces@lists.xensource.com> Envelope-to: www-data@lists.xensource.com Delivery-date: Mon, 26 Sep 2011 09:26:23 -0700 Received: from localhost ([127.0.0.1] helo=lists.colo.xensource.com) by lists.xensource.com with esmtp (Exim 4.43) id 1R8E0d-0005Qe-1I; Mon, 26 Sep 2011 09:26:23 -0700 Received: from mail174.messagelabs.com ([85.158.138.51]) by lists.xensource.com with esmtp (Exim 4.43) id 1R8Dzs-0005EP-D4 for xen-devel@lists.xensource.com; Mon, 26 Sep 2011 09:25:36 -0700 X-Env-Sender: keir.xen@gmail.com X-Msg-Ref: server-7.tower-174.messagelabs.com!1317054331!32792171!1 X-Originating-IP: [209.85.218.43] X-StarScan-Version: 6.4.1; banners=-,-,- X-VirusChecked: Checked Received: (qmail 32207 invoked from network); 26 Sep 2011 16:25:32 -0000 Received: from mail-yi0-f43.google.com (HELO mail-yi0-f43.google.com) (209.85.218.43) by server-7.tower-174.messagelabs.com with RC4-SHA encrypted SMTP; 26 Sep 2011 16:25:32 -0000 Received: by yib17 with SMTP id 17so7124764yib.30 for <xen-devel@lists.xensource.com>; Mon, 26 Sep 2011 09:25:31 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=user-agent:date:subject:from:to:cc:message-id:thread-topic :thread-index:in-reply-to:mime-version:content-type :content-transfer-encoding; bh=3ZhYqgfW3M6w74zd+akCRwSEK8b900Og/FDauKxJ0jM=; b=gdz0mNzn37C3DjevNM81aInnpvRu+BS7Y/xZz9sVsrm3MmjbKm8XlWMUFa8eNNkuZQ oX6/zcHOxrQoF+FvC0ALSwudsrG/TtH7t9cBzHJmOl7dsrpIYCLabaQVvztSNz+NhvMd QqIIjswBmQL4OmbStETMdHlmMfLtFrog5fKSo= Received: by 10.236.185.228 with SMTP id u64mr40972108yhm.91.1317054330699; Mon, 26 Sep 2011 09:25:30 -0700 (PDT) Received: from [192.168.0.189] ([142.103.56.220]) by mx.google.com with ESMTPS id x65sm1749126yhg.18.2011.09.26.09.25.26 (version=SSLv3 cipher=OTHER); Mon, 26 Sep 2011 09:25:28 -0700 (PDT) User-Agent: Microsoft-Entourage/12.30.0.110427 Date: Mon, 26 Sep 2011 09:25:22 -0700 Subject: Re: [Xen-devel] [PATCH] IRQ Cleanup: rename nr_ioapic_registers to nr_ioapic_entries From: Keir Fraser <keir.xen@gmail.com> To: Jan Beulich <JBeulich@suse.com>, Andrew Cooper <andrew.cooper3@citrix.com> Message-ID: <CAA5F582.217CD%keir.xen@gmail.com> Thread-Topic: [Xen-devel] [PATCH] IRQ Cleanup: rename nr_ioapic_registers to nr_ioapic_entries Thread-Index: Acx8aONfJjbX9jUfA0uFRHibol8Uhw== In-Reply-To: <4E80B8F90200007800057DCE@nat28.tlf.novell.com> Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com> X-BeenThere: xen-devel@lists.xensource.com X-Mailman-Version: 2.1.5 Precedence: list List-Id: Xen developer discussion <xen-devel.lists.xensource.com> List-Unsubscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe> List-Post: <mailto:xen-devel@lists.xensource.com> List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help> List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=subscribe> Sender: xen-devel-bounces@lists.xensource.com Errors-To: xen-devel-bounces@lists.xensource.com On 26/09/2011 08:40, "Jan Beulich" <JBeulich@suse.com> wrote: >> I guess it depends on whether you consider that we should stay in line >> with Linux or not. While the code did start in Linux, it has diverged >> so far that it really is its own file now. >> >> Either we should un-diverge from Linux (unlikely to happen), or consider >> it properly forked and not worry; staying in this intermediate state is >> not sustainable and leads to keeping misleading bits about while an >> overhaul is needed. > > There's one more alternative: You could propose the same renaming > on Linux. Not a bad idea. But I don't think it should stop us making these kinds of changes in Xen now. We stayed in sync with upstream Linux on these files for a long while, but we're well diverged now. -- Keir _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel From xen-devel-bounces@lists.xensource.com Mon Sep 26 09:28:12 2011 Return-path: <xen-devel-bounces@lists.xensource.com> Envelope-to: www-data@lists.xensource.com Delivery-date: Mon, 26 Sep 2011 09:28:12 -0700 Received: from localhost ([127.0.0.1] helo=lists.colo.xensource.com) by lists.xensource.com with esmtp (Exim 4.43) id 1R8E2O-0005oY-Ga; Mon, 26 Sep 2011 09:28:12 -0700 Received: from mail216.messagelabs.com ([85.158.143.99]) by lists.xensource.com with esmtp (Exim 4.43) id 1R8E1p-0005c7-H9 for xen-devel@lists.xensource.com; Mon, 26 Sep 2011 09:27:38 -0700 X-Env-Sender: keir.xen@gmail.com X-Msg-Ref: server-14.tower-216.messagelabs.com!1317054453!19652359!1 X-Originating-IP: [209.85.213.171] X-StarScan-Version: 6.4.1; banners=-,-,- X-VirusChecked: Checked Received: (qmail 17350 invoked from network); 26 Sep 2011 16:27:34 -0000 Received: from mail-yx0-f171.google.com (HELO mail-yx0-f171.google.com) (209.85.213.171) by server-14.tower-216.messagelabs.com with RC4-SHA encrypted SMTP; 26 Sep 2011 16:27:34 -0000 Received: by yxt3 with SMTP id 3so7150645yxt.30 for <xen-devel@lists.xensource.com>; Mon, 26 Sep 2011 09:27:33 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=user-agent:date:subject:from:to:cc:message-id:thread-topic :thread-index:in-reply-to:mime-version:content-type :content-transfer-encoding; bh=0aAApGCDv6tuZuITThF2XYSFAT/vFDq6u+dQSEHSZ8Q=; b=G4MofnA+vEkrz/fy7dGtJR1/SEG8i8Oz2PHJUz3WKQMdOS2TWezCGc1KbASdbXiffo +YEVSfQ2o+2D8knRLkba9sfqtaM9uDetb7xiE/BL12aM7K4eGKaMGWVkbixjna3110rt cIQ9hWaN4+pPpybstLAe8bC+0gF4E4LXUz4SY= Received: by 10.236.201.137 with SMTP id b9mr40634839yho.46.1317054452900; Mon, 26 Sep 2011 09:27:32 -0700 (PDT) Received: from [192.168.0.189] ([142.103.56.220]) by mx.google.com with ESMTPS id w70sm29707260yhk.6.2011.09.26.09.27.30 (version=SSLv3 cipher=OTHER); Mon, 26 Sep 2011 09:27:32 -0700 (PDT) User-Agent: Microsoft-Entourage/12.30.0.110427 Date: Mon, 26 Sep 2011 09:27:27 -0700 Subject: Re: [Xen-devel] [PATCH] IRQ Cleanup: rename nr_ioapic_registers to nr_ioapic_entries From: Keir Fraser <keir.xen@gmail.com> To: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>, Andrew Cooper <andrew.cooper3@citrix.com> Message-ID: <CAA5F5FF.217CE%keir.xen@gmail.com> Thread-Topic: [Xen-devel] [PATCH] IRQ Cleanup: rename nr_ioapic_registers to nr_ioapic_entries Thread-Index: Acx8aS3gi1qJ/PosS0SBfIegJwl7Gg== In-Reply-To: <20110926154514.GB17331@phenom.oracle.com> Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>, Jan Beulich <JBeulich@suse.com> X-BeenThere: xen-devel@lists.xensource.com X-Mailman-Version: 2.1.5 Precedence: list List-Id: Xen developer discussion <xen-devel.lists.xensource.com> List-Unsubscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe> List-Post: <mailto:xen-devel@lists.xensource.com> List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help> List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=subscribe> Sender: xen-devel-bounces@lists.xensource.com Errors-To: xen-devel-bounces@lists.xensource.com On 26/09/2011 08:45, "Konrad Rzeszutek Wilk" <konrad.wilk@oracle.com> wrote: >> I guess it depends on whether you consider that we should stay in line >> with Linux or not. While the code did start in Linux, it has diverged > > Stay. Intel does a lot of work of "lift from Linux" and drop in Xen > code. There is similarity. You might also say it gives a false sense of similarity. Andrew's now having to go fix the per-cpu vector stuff for example. It got dropped in; it was complex and opaque; it doesn't really work properly yet. I'd prefer the people doing the porting to have to think about each line a bit more. -- Keir _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel From xen-devel-bounces@lists.xensource.com Mon Sep 26 09:30:20 2011 Return-path: <xen-devel-bounces@lists.xensource.com> Envelope-to: www-data@lists.xensource.com Delivery-date: Mon, 26 Sep 2011 09:30:20 -0700 Received: from localhost ([127.0.0.1] helo=lists.colo.xensource.com) by lists.xensource.com with esmtp (Exim 4.43) id 1R8E4S-0006Ca-Nx; Mon, 26 Sep 2011 09:30:20 -0700 Received: from mail21.messagelabs.com ([85.158.143.35]) by lists.xensource.com with esmtp (Exim 4.43) id 1R8E3v-00060K-Mb for xen-devel@lists.xensource.com; Mon, 26 Sep 2011 09:29:48 -0700 X-Env-Sender: keir.xen@gmail.com X-Msg-Ref: server-9.tower-21.messagelabs.com!1317054538!49871335!1 X-Originating-IP: [74.125.83.43] X-StarScan-Version: 6.4.1; banners=-,-,- X-VirusChecked: Checked Received: (qmail 9522 invoked from network); 26 Sep 2011 16:28:59 -0000 Received: from mail-gw0-f43.google.com (HELO mail-gw0-f43.google.com) (74.125.83.43) by server-9.tower-21.messagelabs.com with RC4-SHA encrypted SMTP; 26 Sep 2011 16:28:59 -0000 Received: by gwm11 with SMTP id 11so5874026gwm.30 for <xen-devel@lists.xensource.com>; Mon, 26 Sep 2011 09:29:43 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=user-agent:date:subject:from:to:cc:message-id:thread-topic :thread-index:in-reply-to:mime-version:content-type :content-transfer-encoding; bh=t0tnQ0mu52/REvjfjV7JTAt6cWdLvuAl2k9wAhoDusI=; b=piu642dEZY+9lVOpYW2krrvZ56CKwl4SJqckHNaqDicNUDEkvF5Pho+nQQ+m/hjfn6 WeTArhJ/UCSJBP3RfQulyRiAmm2oIXryJu/tESz062wp/bBk0CjeYcFuv9Dp5VtZVE2i yNuBXOA3gfiYXTNF4I4hFKolK0G3Qns7ZCQPA= Received: by 10.151.114.19 with SMTP id r19mr2885074ybm.110.1317054583285; Mon, 26 Sep 2011 09:29:43 -0700 (PDT) Received: from [192.168.0.189] ([142.103.56.220]) by mx.google.com with ESMTPS id g20sm110358ybd.1.2011.09.26.09.29.40 (version=SSLv3 cipher=OTHER); Mon, 26 Sep 2011 09:29:41 -0700 (PDT) User-Agent: Microsoft-Entourage/12.30.0.110427 Date: Mon, 26 Sep 2011 09:29:37 -0700 From: Keir Fraser <keir.xen@gmail.com> To: Stefano Stabellini <Stefano.Stabellini@eu.citrix.com>, "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com> Message-ID: <CAA5F681.217D0%keir.xen@gmail.com> Thread-Topic: [PATCH v6 0/5] build upstream qemu and seabios by default Thread-Index: Acx8aXtcBKq3Ji/SVUeSkI6KY3o4qQ== In-Reply-To: <alpine.DEB.2.00.1109231302370.8700@kaball-desktop> Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit Cc: Ian Campbell <Ian.Campbell@eu.citrix.com>, Ian Jackson <Ian.Jackson@eu.citrix.com> Subject: [Xen-devel] Re: [PATCH v6 0/5] build upstream qemu and seabios by default X-BeenThere: xen-devel@lists.xensource.com X-Mailman-Version: 2.1.5 Precedence: list List-Id: Xen developer discussion <xen-devel.lists.xensource.com> List-Unsubscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe> List-Post: <mailto:xen-devel@lists.xensource.com> List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help> List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=subscribe> Sender: xen-devel-bounces@lists.xensource.com Errors-To: xen-devel-bounces@lists.xensource.com On 23/09/2011 05:09, "Stefano Stabellini" <Stefano.Stabellini@eu.citrix.com> wrote: > Hi all, > this is the sixth version of the patch series to introduce upstream qemu > and seabios in the xen-unstable build system. > I'm happy with this by the way. Do you want me to check it in again? Perhaps better to give it a run through the automated tests first, and then have IanJ push it on success? -- Keir > Changes to v5: > > - use $GIT in git-checkout.sh; > > - add an http mirror for seabios; > > - use $(LIBEXEC) to configure upstream qemu; > > - append a patch for libxenlight to find the upstream qemu binary under > $(LIBEXEC). > > > Changes to v4: > > - remove an obsolete comment; > > - use /bin/sh to execute git-checkout.sh rathen than /bin/bash. > > > Changes to v3: > > - reduce the scope of git-checkout.sh, now it only does what the name > says; calling "configure" is responsibility of the caller. As a result > of this change, the build still works when the user specifies a local > directory in the CONFIG_QEMU environmental variable; > > - use a more official qemu repository hosted on xenbits; > > - use a changeset as QEMU_UPSTREAM_TAG rather than a branch name. > > > > Changes to v2: > > - move tools/git-checkout.sh to scripts/git-checkout.sh; > > - use git-checkout.sh for seabios; > > - improve seabios integration with tools/firmware make system; > > - add qemu-xen-traditional, qemu-xen and seabios dir entries to > .hgignore. > > > > Changes to v1: > > - always build upstream qemu and seabios, rather than introducing them > as an option. > > > Cheers, > > Stefano _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel From xen-devel-bounces@lists.xensource.com Mon Sep 26 09:33:54 2011 Return-path: <xen-devel-bounces@lists.xensource.com> Envelope-to: www-data@lists.xensource.com Delivery-date: Mon, 26 Sep 2011 09:33:54 -0700 Received: from localhost ([127.0.0.1] helo=lists.colo.xensource.com) by lists.xensource.com with esmtp (Exim 4.43) id 1R8E7u-0006ej-3A; Mon, 26 Sep 2011 09:33:54 -0700 Received: from mail182.messagelabs.com ([85.158.139.83]) by lists.xensource.com with esmtp (Exim 4.43) id 1R8E7I-0006SG-I4 for xen-devel@lists.xensource.com; Mon, 26 Sep 2011 09:33:17 -0700 X-Env-Sender: Andrew.Cooper3@citrix.com X-Msg-Ref: server-6.tower-182.messagelabs.com!1317054793!18604236!1 X-Originating-IP: [62.200.22.115] X-StarScan-Version: 6.4.1; banners=-,-,- X-VirusChecked: Checked Received: (qmail 21721 invoked from network); 26 Sep 2011 16:33:13 -0000 Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115) by server-6.tower-182.messagelabs.com with RC4-SHA encrypted SMTP; 26 Sep 2011 16:33:13 -0000 X-IronPort-AV: E=Sophos;i="4.68,445,1312156800"; d="scan'208";a="8066857" Received: from lonpmailmx01.citrite.net ([10.30.203.162]) by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5; 26 Sep 2011 16:33:13 +0000 Received: from andrewcoop.uk.xensource.com (10.80.2.18) by LONPMAILMX01.citrite.net (10.30.203.162) with Microsoft SMTP Server id 8.3.137.0; Mon, 26 Sep 2011 17:33:12 +0100 Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Mercurial-Node: 88b8953f5f5a514c84d72ee982093814c030ef33 Message-ID: <88b8953f5f5a514c84d7.1317054792@andrewcoop.uk.xensource.com> User-Agent: Mercurial-patchbomb/1.4.3 Date: Mon, 26 Sep 2011 17:33:12 +0100 From: Andrew Cooper <andrew.cooper3@citrix.com> To: xen-devel@lists.xensource.com Cc: Andrew Cooper <andrew.cooper3@citrix.com> Subject: [Xen-devel] [PATCH] IRQ: Fix trace bug introduced by c/s 23816:7f357e1ef60a X-BeenThere: xen-devel@lists.xensource.com X-Mailman-Version: 2.1.5 Precedence: list List-Id: Xen developer discussion <xen-devel.lists.xensource.com> List-Unsubscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe> List-Post: <mailto:xen-devel@lists.xensource.com> List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help> List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=subscribe> Sender: xen-devel-bounces@lists.xensource.com Errors-To: xen-devel-bounces@lists.xensource.com c/s 23816:7f357e1ef60a introduces cfg->old_vector and removes a loop as a result. Outside the loop, 'vector' is set to cfg->vector, but the loop aliased 'vector' to mean cfg->old_vector at the point at which this TRACE_3D is executed. Therefore, when the loop was removed, the code still compiled, although the trace would record incorrect information. Signed-off-by: Andrew Cooper <andrew.cooper3@citrix.com> diff -r a422e2a4451e -r 88b8953f5f5a xen/arch/x86/irq.c --- a/xen/arch/x86/irq.c Sun Sep 18 00:26:52 2011 +0100 +++ b/xen/arch/x86/irq.c Mon Sep 26 17:31:32 2011 +0100 @@ -235,7 +235,7 @@ static void __clear_irq_vector(int irq) cpus_and(tmp_mask, cfg->old_cpu_mask, cpu_online_map); for_each_cpu_mask(cpu, tmp_mask) { ASSERT( per_cpu(vector_irq, cpu)[cfg->old_vector] == irq ); - TRACE_3D(TRC_HW_IRQ_MOVE_FINISH, irq, vector, cpu); + TRACE_3D(TRC_HW_IRQ_MOVE_FINISH, irq, cfg->old_vector, cpu); per_cpu(vector_irq, cpu)[cfg->old_vector] = -1; } _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel From xen-devel-bounces@lists.xensource.com Mon Sep 26 09:49:58 2011 Return-path: <xen-devel-bounces@lists.xensource.com> Envelope-to: www-data@lists.xensource.com Delivery-date: Mon, 26 Sep 2011 09:49:58 -0700 Received: from localhost ([127.0.0.1] helo=lists.colo.xensource.com) by lists.xensource.com with esmtp (Exim 4.43) id 1R8ENS-0007V4-Jf; Mon, 26 Sep 2011 09:49:58 -0700 Received: from mail182.messagelabs.com ([85.158.139.83]) by lists.xensource.com with esmtp (Exim 4.43) id 1R8EMq-0007JE-48 for xen-devel@lists.xensource.com; Mon, 26 Sep 2011 09:49:20 -0700 X-Env-Sender: Ian.Jackson@eu.citrix.com X-Msg-Ref: server-7.tower-182.messagelabs.com!1317055756!14804469!1 X-Originating-IP: [62.200.22.115] X-StarScan-Version: 6.4.1; banners=-,-,- X-VirusChecked: Checked Received: (qmail 24913 invoked from network); 26 Sep 2011 16:49:17 -0000 Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115) by server-7.tower-182.messagelabs.com with RC4-SHA encrypted SMTP; 26 Sep 2011 16:49:17 -0000 X-IronPort-AV: E=Sophos;i="4.68,445,1312156800"; d="scan'208";a="8067075" Received: from lonpmailmx01.citrite.net ([10.30.203.162]) by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5; 26 Sep 2011 16:49:16 +0000 Received: from norwich.cam.xci-test.com (10.80.248.129) by smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id 8.3.137.0; Mon, 26 Sep 2011 17:49:16 +0100 Received: from mariner.cam.xci-test.com ([10.80.2.22] helo=mariner.uk.xensource.com ident=Debian-exim) by norwich.cam.xci-test.com with esmtp (Exim 4.72) (envelope-from <Ian.Jackson@eu.citrix.com>) id 1R8EMm-0007Pq-Bn; Mon, 26 Sep 2011 16:49:16 +0000 Received: from iwj by mariner.uk.xensource.com with local (Exim 4.69) (envelope-from <Ian.Jackson@eu.citrix.com>) id 1R8EMm-00078D-AA; Mon, 26 Sep 2011 17:49:16 +0100 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Message-ID: <20096.44300.281562.840700@mariner.uk.xensource.com> Date: Mon, 26 Sep 2011 17:49:16 +0100 To: Keir Fraser <keir.xen@gmail.com> Subject: [Xen-devel] Re: [PATCH v6 0/5] build upstream qemu and seabios by default Newsgroups: chiark.mail.xen.devel In-Reply-To: <CAA5F681.217D0%keir.xen@gmail.com> References: <alpine.DEB.2.00.1109231302370.8700@kaball-desktop> <CAA5F681.217D0%keir.xen@gmail.com> X-Mailer: VM 8.0.9 under Emacs 21.4.1 (i486-pc-linux-gnu) From: Ian Jackson <Ian.Jackson@eu.citrix.com> Cc: Ian Campbell <Ian.Campbell@eu.citrix.com>, "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>, Stefano Stabellini <Stefano.Stabellini@eu.citrix.com> X-BeenThere: xen-devel@lists.xensource.com X-Mailman-Version: 2.1.5 Precedence: list List-Id: Xen developer discussion <xen-devel.lists.xensource.com> List-Unsubscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe> List-Post: <mailto:xen-devel@lists.xensource.com> List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help> List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=subscribe> Sender: xen-devel-bounces@lists.xensource.com Errors-To: xen-devel-bounces@lists.xensource.com Keir Fraser writes ("[Xen-devel] Re: [PATCH v6 0/5] build upstream qemu and seabios by default"): > I'm happy with this by the way. Do you want me to check it in again? Perhaps > better to give it a run through the automated tests first, and then have > IanJ push it on success? Noted, thanks for the ack. I will review and test this whole series and apply it if I'm happy. Ian. _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel From xen-devel-bounces@lists.xensource.com Mon Sep 26 09:53:47 2011 Return-path: <xen-devel-bounces@lists.xensource.com> Envelope-to: www-data@lists.xensource.com Delivery-date: Mon, 26 Sep 2011 09:53:47 -0700 Received: from localhost ([127.0.0.1] helo=lists.colo.xensource.com) by lists.xensource.com with esmtp (Exim 4.43) id 1R8ER8-00080K-TG; Mon, 26 Sep 2011 09:53:46 -0700 Received: from mail27.messagelabs.com ([193.109.254.147]) by lists.xensource.com with smtp (Exim 4.43) id 1R8EQD-0007nf-Vo for xen-devel@lists.xensource.com; Mon, 26 Sep 2011 09:52:51 -0700 X-Env-Sender: rdunlap@xenotime.net X-Msg-Ref: server-5.tower-27.messagelabs.com!1317055945!46440921!1 X-Originating-IP: [67.222.38.55] X-StarScan-Version: 6.4.1; banners=-,-,- X-VirusChecked: Checked Received: (qmail 2565 invoked from network); 26 Sep 2011 16:52:26 -0000 Received: from oproxy5-pub.bluehost.com (HELO oproxy5-pub.bluehost.com) (67.222.38.55) by server-5.tower-27.messagelabs.com with SMTP; 26 Sep 2011 16:52:26 -0000 Received: (qmail 23132 invoked by uid 0); 26 Sep 2011 16:52:45 -0000 Received: from unknown (HELO box742.bluehost.com) (66.147.244.242) by cpoproxy2.bluehost.com with SMTP; 26 Sep 2011 16:52:45 -0000 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=xenotime.net; s=default; h=Content-Type:In-Reply-To:References:Subject:CC:To:MIME-Version:From:Date:Message-ID; bh=mMUHx08ab8BiUH2/esUJr1eG6Q3dEkpzCt2TL0PQByc=; b=o5SlQ/nRRNzVamQIzYihxTriVYTgVLhd8kkBQtGteLoNj1RNzWBPDMH3XIXa4NdeeIHSAo3coe/0C4mTDnFQ5QXDpihN2iPHXLz02u1HBoPpbZqbV6t/IL+edtX3+zfw; Received: from static-50-53-38-135.bvtn.or.frontiernet.net ([50.53.38.135] helo=[192.168.1.4]) by box742.bluehost.com with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.76) (envelope-from <rdunlap@xenotime.net>) id 1R8EQ8-0003gg-Ta; Mon, 26 Sep 2011 10:52:45 -0600 Message-ID: <4E80ADDA.8090105@xenotime.net> Date: Mon, 26 Sep 2011 09:52:42 -0700 From: Randy Dunlap <rdunlap@xenotime.net> Organization: YPO4 User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.2.22) Gecko/20110907 SUSE/3.1.14 Thunderbird/3.1.14 MIME-Version: 1.0 To: Stephen Rothwell <sfr@canb.auug.org.au> References: <20110926172348.be01ff9a1c16267ffd000d2a@canb.auug.org.au> In-Reply-To: <20110926172348.be01ff9a1c16267ffd000d2a@canb.auug.org.au> Content-Type: multipart/mixed; boundary="------------080300090904080808020606" X-Identified-User: {1807:box742.bluehost.com:xenotime:xenotime.net} {sentby:smtp auth 50.53.38.135 authed with rdunlap@xenotime.net} Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>, Jeremy Fitzhardinge <jeremy.fitzhardinge@citrix.com>, Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>, LKML <linux-kernel@vger.kernel.org>, Linux Virtualization <virtualization@lists.linux-foundation.org>, linux-next@vger.kernel.org Subject: [Xen-devel] Re: linux-next: Tree for Sept 26 (xen) X-BeenThere: xen-devel@lists.xensource.com X-Mailman-Version: 2.1.5 Precedence: list List-Id: Xen developer discussion <xen-devel.lists.xensource.com> List-Unsubscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe> List-Post: <mailto:xen-devel@lists.xensource.com> List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help> List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=subscribe> Sender: xen-devel-bounces@lists.xensource.com Errors-To: xen-devel-bounces@lists.xensource.com This is a multi-part message in MIME format. --------------080300090904080808020606 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit On 09/26/2011 12:23 AM, Stephen Rothwell wrote: > Hi all, x86_64 build sometimes fails with: drivers/xen/xenbus/xenbus_xs.c:909:2: error: implicit declaration of function 'xen_hvm_domain' One failing randconfig file is attached. -- ~Randy *** Remember to use Documentation/SubmitChecklist when testing your code *** --------------080300090904080808020606 Content-Type: text/plain; name="config-r1845" Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename="config-r1845" # # Automatically generated file; DO NOT EDIT. # Linux/x86_64 3.1.0-rc7 Kernel Configuration # CONFIG_64BIT=y # CONFIG_X86_32 is not set CONFIG_X86_64=y CONFIG_X86=y CONFIG_INSTRUCTION_DECODER=y CONFIG_OUTPUT_FORMAT="elf64-x86-64" CONFIG_ARCH_DEFCONFIG="arch/x86/configs/x86_64_defconfig" CONFIG_GENERIC_CMOS_UPDATE=y CONFIG_CLOCKSOURCE_WATCHDOG=y CONFIG_GENERIC_CLOCKEVENTS=y CONFIG_ARCH_CLOCKSOURCE_DATA=y CONFIG_GENERIC_CLOCKEVENTS_BROADCAST=y CONFIG_LOCKDEP_SUPPORT=y CONFIG_STACKTRACE_SUPPORT=y CONFIG_HAVE_LATENCYTOP_SUPPORT=y CONFIG_MMU=y # CONFIG_ZONE_DMA is not set CONFIG_NEED_DMA_MAP_STATE=y CONFIG_NEED_SG_DMA_LENGTH=y # CONFIG_GENERIC_ISA_DMA is not set CONFIG_GENERIC_IOMAP=y CONFIG_GENERIC_BUG=y CONFIG_GENERIC_BUG_RELATIVE_POINTERS=y CONFIG_GENERIC_HWEIGHT=y CONFIG_GENERIC_GPIO=y # CONFIG_ARCH_MAY_HAVE_PC_FDC is not set # CONFIG_RWSEM_GENERIC_SPINLOCK is not set CONFIG_RWSEM_XCHGADD_ALGORITHM=y CONFIG_ARCH_HAS_CPU_IDLE_WAIT=y CONFIG_GENERIC_CALIBRATE_DELAY=y CONFIG_GENERIC_TIME_VSYSCALL=y CONFIG_ARCH_HAS_CPU_RELAX=y CONFIG_ARCH_HAS_DEFAULT_IDLE=y CONFIG_ARCH_HAS_CACHE_LINE_SIZE=y CONFIG_HAVE_SETUP_PER_CPU_AREA=y CONFIG_NEED_PER_CPU_EMBED_FIRST_CHUNK=y CONFIG_NEED_PER_CPU_PAGE_FIRST_CHUNK=y # CONFIG_HAVE_CPUMASK_OF_CPU_MAP is not set CONFIG_ARCH_HIBERNATION_POSSIBLE=y CONFIG_ARCH_SUSPEND_POSSIBLE=y CONFIG_ZONE_DMA32=y CONFIG_ARCH_POPULATES_NODE_MAP=y CONFIG_AUDIT_ARCH=y CONFIG_ARCH_SUPPORTS_OPTIMIZED_INLINING=y CONFIG_ARCH_SUPPORTS_DEBUG_PAGEALLOC=y CONFIG_ARCH_HWEIGHT_CFLAGS="-fcall-saved-rdi -fcall-saved-rsi -fcall-saved-rdx -fcall-saved-rcx -fcall-saved-r8 -fcall-saved-r9 -fcall-saved-r10 -fcall-saved-r11" # CONFIG_KTIME_SCALAR is not set CONFIG_DEFCONFIG_LIST="/lib/modules/$UNAME_RELEASE/.config" CONFIG_HAVE_IRQ_WORK=y CONFIG_IRQ_WORK=y # # General setup # # CONFIG_EXPERIMENTAL is not set CONFIG_BROKEN_ON_SMP=y CONFIG_INIT_ENV_ARG_LIMIT=32 CONFIG_CROSS_COMPILE="" CONFIG_LOCALVERSION="" # CONFIG_LOCALVERSION_AUTO is not set CONFIG_HAVE_KERNEL_GZIP=y CONFIG_HAVE_KERNEL_BZIP2=y CONFIG_HAVE_KERNEL_LZMA=y CONFIG_HAVE_KERNEL_XZ=y CONFIG_HAVE_KERNEL_LZO=y # CONFIG_KERNEL_GZIP is not set # CONFIG_KERNEL_BZIP2 is not set CONFIG_KERNEL_LZMA=y # CONFIG_KERNEL_XZ is not set # CONFIG_KERNEL_LZO is not set CONFIG_DEFAULT_HOSTNAME="(none)" # CONFIG_SWAP is not set CONFIG_SYSVIPC=y # CONFIG_BSD_PROCESS_ACCT is not set # CONFIG_FHANDLE is not set CONFIG_TASKSTATS=y CONFIG_TASK_DELAY_ACCT=y CONFIG_TASK_XACCT=y # CONFIG_TASK_IO_ACCOUNTING is not set CONFIG_AUDIT=y # CONFIG_AUDITSYSCALL is not set CONFIG_HAVE_GENERIC_HARDIRQS=y # # IRQ subsystem # CONFIG_GENERIC_HARDIRQS=y CONFIG_HAVE_SPARSE_IRQ=y CONFIG_GENERIC_IRQ_PROBE=y CONFIG_GENERIC_IRQ_SHOW=y CONFIG_IRQ_FORCED_THREADING=y CONFIG_SPARSE_IRQ=y # # RCU Subsystem # CONFIG_TINY_RCU=y # CONFIG_PREEMPT_RCU is not set CONFIG_RCU_TRACE=y # CONFIG_TREE_RCU_TRACE is not set CONFIG_IKCONFIG=y CONFIG_IKCONFIG_PROC=y CONFIG_LOG_BUF_SHIFT=17 CONFIG_HAVE_UNSTABLE_SCHED_CLOCK=y CONFIG_CGROUPS=y # CONFIG_CGROUP_DEBUG is not set CONFIG_CGROUP_FREEZER=y # CONFIG_CGROUP_DEVICE is not set CONFIG_CPUSETS=y CONFIG_PROC_PID_CPUSET=y # CONFIG_CGROUP_CPUACCT is not set CONFIG_RESOURCE_COUNTERS=y # CONFIG_CGROUP_MEM_RES_CTLR is not set # CONFIG_CGROUP_PERF is not set CONFIG_CGROUP_SCHED=y CONFIG_FAIR_GROUP_SCHED=y # CONFIG_BLK_CGROUP is not set # CONFIG_NAMESPACES is not set CONFIG_SCHED_AUTOGROUP=y # CONFIG_SYSFS_DEPRECATED is not set CONFIG_RELAY=y CONFIG_BLK_DEV_INITRD=y CONFIG_INITRAMFS_SOURCE="" CONFIG_RD_GZIP=y # CONFIG_RD_BZIP2 is not set # CONFIG_RD_LZMA is not set # CONFIG_RD_XZ is not set CONFIG_RD_LZO=y # CONFIG_CC_OPTIMIZE_FOR_SIZE is not set CONFIG_ANON_INODES=y CONFIG_EXPERT=y # CONFIG_UID16 is not set CONFIG_KALLSYMS=y CONFIG_KALLSYMS_ALL=y # CONFIG_HOTPLUG is not set # CONFIG_PRINTK is not set CONFIG_BUG=y # CONFIG_ELF_CORE is not set CONFIG_PCSPKR_PLATFORM=y CONFIG_HAVE_PCSPKR_PLATFORM=y CONFIG_BASE_FULL=y # CONFIG_FUTEX is not set # CONFIG_EPOLL is not set # CONFIG_SIGNALFD is not set # CONFIG_TIMERFD is not set CONFIG_EVENTFD=y CONFIG_SHMEM=y CONFIG_AIO=y CONFIG_EMBEDDED=y CONFIG_HAVE_PERF_EVENTS=y CONFIG_PERF_USE_VMALLOC=y # # Kernel Performance Events And Counters # CONFIG_PERF_EVENTS=y # CONFIG_PERF_COUNTERS is not set CONFIG_DEBUG_PERF_USE_VMALLOC=y # CONFIG_VM_EVENT_COUNTERS is not set CONFIG_PCI_QUIRKS=y CONFIG_SLUB_DEBUG=y # CONFIG_COMPAT_BRK is not set # CONFIG_SLAB is not set CONFIG_SLUB=y # CONFIG_SLOB is not set # CONFIG_PROFILING is not set CONFIG_TRACEPOINTS=y CONFIG_HAVE_OPROFILE=y CONFIG_JUMP_LABEL=y CONFIG_HAVE_EFFICIENT_UNALIGNED_ACCESS=y CONFIG_HAVE_IOREMAP_PROT=y CONFIG_HAVE_KPROBES=y CONFIG_HAVE_KRETPROBES=y CONFIG_HAVE_OPTPROBES=y CONFIG_HAVE_ARCH_TRACEHOOK=y CONFIG_HAVE_DMA_ATTRS=y CONFIG_HAVE_REGS_AND_STACK_ACCESS_API=y CONFIG_HAVE_DMA_API_DEBUG=y CONFIG_HAVE_HW_BREAKPOINT=y CONFIG_HAVE_MIXED_BREAKPOINTS_REGS=y CONFIG_HAVE_USER_RETURN_NOTIFIER=y CONFIG_HAVE_PERF_EVENTS_NMI=y CONFIG_HAVE_ARCH_JUMP_LABEL=y CONFIG_ARCH_HAVE_NMI_SAFE_CMPXCHG=y # # GCOV-based kernel profiling # # CONFIG_GCOV_KERNEL is not set # CONFIG_HAVE_GENERIC_DMA_COHERENT is not set CONFIG_SLABINFO=y CONFIG_RT_MUTEXES=y CONFIG_BASE_SMALL=0 # CONFIG_MODULES is not set CONFIG_BLOCK=y CONFIG_BLK_DEV_BSG=y CONFIG_BLK_DEV_BSGLIB=y CONFIG_BLK_DEV_INTEGRITY=y CONFIG_BLOCK_COMPAT=y # # IO Schedulers # CONFIG_IOSCHED_NOOP=y CONFIG_IOSCHED_DEADLINE=y # CONFIG_IOSCHED_CFQ is not set CONFIG_DEFAULT_DEADLINE=y # CONFIG_DEFAULT_NOOP is not set CONFIG_DEFAULT_IOSCHED="deadline" # CONFIG_INLINE_SPIN_TRYLOCK is not set # CONFIG_INLINE_SPIN_TRYLOCK_BH is not set # CONFIG_INLINE_SPIN_LOCK is not set # CONFIG_INLINE_SPIN_LOCK_BH is not set # CONFIG_INLINE_SPIN_LOCK_IRQ is not set # CONFIG_INLINE_SPIN_LOCK_IRQSAVE is not set CONFIG_INLINE_SPIN_UNLOCK=y # CONFIG_INLINE_SPIN_UNLOCK_BH is not set CONFIG_INLINE_SPIN_UNLOCK_IRQ=y # CONFIG_INLINE_SPIN_UNLOCK_IRQRESTORE is not set # CONFIG_INLINE_READ_TRYLOCK is not set # CONFIG_INLINE_READ_LOCK is not set # CONFIG_INLINE_READ_LOCK_BH is not set # CONFIG_INLINE_READ_LOCK_IRQ is not set # CONFIG_INLINE_READ_LOCK_IRQSAVE is not set CONFIG_INLINE_READ_UNLOCK=y # CONFIG_INLINE_READ_UNLOCK_BH is not set CONFIG_INLINE_READ_UNLOCK_IRQ=y # CONFIG_INLINE_READ_UNLOCK_IRQRESTORE is not set # CONFIG_INLINE_WRITE_TRYLOCK is not set # CONFIG_INLINE_WRITE_LOCK is not set # CONFIG_INLINE_WRITE_LOCK_BH is not set # CONFIG_INLINE_WRITE_LOCK_IRQ is not set # CONFIG_INLINE_WRITE_LOCK_IRQSAVE is not set CONFIG_INLINE_WRITE_UNLOCK=y # CONFIG_INLINE_WRITE_UNLOCK_BH is not set CONFIG_INLINE_WRITE_UNLOCK_IRQ=y # CONFIG_INLINE_WRITE_UNLOCK_IRQRESTORE is not set # CONFIG_MUTEX_SPIN_ON_OWNER is not set CONFIG_FREEZER=y # # Processor type and features # CONFIG_TICK_ONESHOT=y CONFIG_NO_HZ=y # CONFIG_HIGH_RES_TIMERS is not set CONFIG_GENERIC_CLOCKEVENTS_BUILD=y CONFIG_GENERIC_CLOCKEVENTS_MIN_ADJUST=y # CONFIG_SMP is not set # CONFIG_X86_MPPARSE is not set # CONFIG_X86_EXTENDED_PLATFORM is not set CONFIG_X86_SUPPORTS_MEMORY_FAILURE=y # CONFIG_SCHED_OMIT_FRAME_POINTER is not set CONFIG_PARAVIRT_GUEST=y # CONFIG_PARAVIRT_TIME_ACCOUNTING is not set CONFIG_XEN=y CONFIG_XEN_DOM0=y CONFIG_XEN_PRIVILEGED_GUEST=y CONFIG_XEN_PVHVM=y CONFIG_XEN_MAX_DOMAIN_MEMORY=128 CONFIG_XEN_SAVE_RESTORE=y CONFIG_XEN_DEBUG_FS=y CONFIG_MICROCODE_XEN=y CONFIG_KVM_CLOCK=y CONFIG_KVM_GUEST=y CONFIG_PARAVIRT=y CONFIG_PARAVIRT_CLOCK=y # CONFIG_PARAVIRT_DEBUG is not set CONFIG_NO_BOOTMEM=y # CONFIG_MEMTEST is not set # CONFIG_MK8 is not set # CONFIG_MPSC is not set # CONFIG_MCORE2 is not set # CONFIG_MATOM is not set CONFIG_GENERIC_CPU=y CONFIG_X86_INTERNODE_CACHE_SHIFT=6 CONFIG_X86_CMPXCHG=y CONFIG_CMPXCHG_LOCAL=y CONFIG_CMPXCHG_DOUBLE=y CONFIG_X86_L1_CACHE_SHIFT=6 CONFIG_X86_XADD=y CONFIG_X86_WP_WORKS_OK=y CONFIG_X86_TSC=y CONFIG_X86_CMPXCHG64=y CONFIG_X86_CMOV=y CONFIG_X86_MINIMUM_CPU_FAMILY=64 CONFIG_X86_DEBUGCTLMSR=y CONFIG_PROCESSOR_SELECT=y # CONFIG_CPU_SUP_INTEL is not set CONFIG_CPU_SUP_AMD=y # CONFIG_CPU_SUP_CENTAUR is not set CONFIG_HPET_TIMER=y CONFIG_HPET_EMULATE_RTC=y # CONFIG_DMI is not set CONFIG_GART_IOMMU=y CONFIG_SWIOTLB=y CONFIG_IOMMU_HELPER=y CONFIG_NR_CPUS=1 # CONFIG_IRQ_TIME_ACCOUNTING is not set CONFIG_PREEMPT_NONE=y # CONFIG_PREEMPT_VOLUNTARY is not set # CONFIG_PREEMPT is not set CONFIG_X86_LOCAL_APIC=y CONFIG_X86_IO_APIC=y CONFIG_X86_REROUTE_FOR_BROKEN_BOOT_IRQS=y CONFIG_X86_MCE=y # CONFIG_X86_MCE_INTEL is not set CONFIG_X86_MCE_AMD=y CONFIG_X86_MCE_THRESHOLD=y CONFIG_X86_MCE_INJECT=y # CONFIG_I8K is not set CONFIG_MICROCODE=y # CONFIG_MICROCODE_INTEL is not set # CONFIG_MICROCODE_AMD is not set CONFIG_MICROCODE_OLD_INTERFACE=y # CONFIG_X86_MSR is not set # CONFIG_X86_CPUID is not set CONFIG_ARCH_PHYS_ADDR_T_64BIT=y CONFIG_ARCH_DMA_ADDR_T_64BIT=y CONFIG_DIRECT_GBPAGES=y CONFIG_ARCH_SPARSEMEM_ENABLE=y CONFIG_ARCH_SPARSEMEM_DEFAULT=y CONFIG_ARCH_SELECT_MEMORY_MODEL=y CONFIG_ARCH_PROC_KCORE_TEXT=y CONFIG_ILLEGAL_POINTER_VALUE=0xdead000000000000 CONFIG_SELECT_MEMORY_MODEL=y CONFIG_SPARSEMEM_MANUAL=y CONFIG_SPARSEMEM=y CONFIG_HAVE_MEMORY_PRESENT=y CONFIG_SPARSEMEM_EXTREME=y CONFIG_SPARSEMEM_VMEMMAP_ENABLE=y CONFIG_SPARSEMEM_ALLOC_MEM_MAP_TOGETHER=y CONFIG_SPARSEMEM_VMEMMAP=y CONFIG_HAVE_MEMBLOCK=y CONFIG_PAGEFLAGS_EXTENDED=y CONFIG_SPLIT_PTLOCK_CPUS=4 CONFIG_COMPACTION=y CONFIG_MIGRATION=y CONFIG_PHYS_ADDR_T_64BIT=y CONFIG_ZONE_DMA_FLAG=0 CONFIG_VIRT_TO_BUS=y CONFIG_KSM=y CONFIG_DEFAULT_MMAP_MIN_ADDR=4096 CONFIG_ARCH_SUPPORTS_MEMORY_FAILURE=y CONFIG_MEMORY_FAILURE=y # CONFIG_HWPOISON_INJECT is not set CONFIG_TRANSPARENT_HUGEPAGE=y CONFIG_TRANSPARENT_HUGEPAGE_ALWAYS=y # CONFIG_TRANSPARENT_HUGEPAGE_MADVISE is not set CONFIG_NEED_PER_CPU_KM=y # CONFIG_CLEANCACHE is not set # CONFIG_X86_CHECK_BIOS_CORRUPTION is not set CONFIG_X86_RESERVE_LOW=64 CONFIG_MTRR=y CONFIG_MTRR_SANITIZER=y CONFIG_MTRR_SANITIZER_ENABLE_DEFAULT=0 CONFIG_MTRR_SANITIZER_SPARE_REG_NR_DEFAULT=1 # CONFIG_X86_PAT is not set # CONFIG_ARCH_RANDOM is not set CONFIG_EFI=y CONFIG_SECCOMP=y CONFIG_CC_STACKPROTECTOR=y CONFIG_HZ_100=y # CONFIG_HZ_250 is not set # CONFIG_HZ_300 is not set # CONFIG_HZ_1000 is not set CONFIG_HZ=100 # CONFIG_SCHED_HRTICK is not set CONFIG_KEXEC=y CONFIG_CRASH_DUMP=y CONFIG_PHYSICAL_START=0x1000000 CONFIG_RELOCATABLE=y CONFIG_PHYSICAL_ALIGN=0x1000000 CONFIG_COMPAT_VDSO=y # CONFIG_CMDLINE_BOOL is not set CONFIG_ARCH_ENABLE_MEMORY_HOTPLUG=y # # Power management and ACPI options # # CONFIG_SUSPEND is not set CONFIG_HIBERNATE_CALLBACKS=y CONFIG_PM_SLEEP=y CONFIG_PM_RUNTIME=y CONFIG_PM=y # CONFIG_PM_DEBUG is not set CONFIG_ACPI=y CONFIG_ACPI_PROCFS=y CONFIG_ACPI_PROCFS_POWER=y CONFIG_ACPI_EC_DEBUGFS=y # CONFIG_ACPI_PROC_EVENT is not set # CONFIG_ACPI_AC is not set CONFIG_ACPI_BATTERY=y CONFIG_ACPI_BUTTON=y CONFIG_ACPI_VIDEO=y CONFIG_ACPI_FAN=y # CONFIG_ACPI_PROCESSOR is not set # CONFIG_ACPI_CUSTOM_DSDT is not set CONFIG_ACPI_BLACKLIST_YEAR=0 # CONFIG_ACPI_DEBUG is not set # CONFIG_ACPI_PCI_SLOT is not set CONFIG_X86_PM_TIMER=y # CONFIG_ACPI_SBS is not set CONFIG_ACPI_HED=y CONFIG_ACPI_CUSTOM_METHOD=y # CONFIG_ACPI_APEI is not set CONFIG_SFI=y # # CPU Frequency scaling # CONFIG_CPU_FREQ=y CONFIG_CPU_FREQ_TABLE=y CONFIG_CPU_FREQ_STAT=y # CONFIG_CPU_FREQ_STAT_DETAILS is not set # CONFIG_CPU_FREQ_DEFAULT_GOV_PERFORMANCE is not set # CONFIG_CPU_FREQ_DEFAULT_GOV_POWERSAVE is not set # CONFIG_CPU_FREQ_DEFAULT_GOV_USERSPACE is not set # CONFIG_CPU_FREQ_DEFAULT_GOV_ONDEMAND is not set CONFIG_CPU_FREQ_DEFAULT_GOV_CONSERVATIVE=y CONFIG_CPU_FREQ_GOV_PERFORMANCE=y CONFIG_CPU_FREQ_GOV_POWERSAVE=y CONFIG_CPU_FREQ_GOV_USERSPACE=y CONFIG_CPU_FREQ_GOV_ONDEMAND=y CONFIG_CPU_FREQ_GOV_CONSERVATIVE=y # # x86 CPU frequency scaling drivers # CONFIG_X86_P4_CLOCKMOD=y # # shared options # CONFIG_X86_SPEEDSTEP_LIB=y # CONFIG_CPU_IDLE is not set # # Memory power savings # # # Bus options (PCI etc.) # CONFIG_PCI=y CONFIG_PCI_DIRECT=y CONFIG_PCI_MMCONFIG=y CONFIG_PCI_XEN=y CONFIG_PCI_DOMAINS=y # CONFIG_PCIEPORTBUS is not set CONFIG_ARCH_SUPPORTS_MSI=y CONFIG_PCI_MSI=y CONFIG_PCI_DEBUG=y CONFIG_PCI_STUB=y # CONFIG_XEN_PCIDEV_FRONTEND is not set CONFIG_HT_IRQ=y CONFIG_PCI_IOV=y CONFIG_PCI_LABEL=y # CONFIG_ISA_DMA_API is not set CONFIG_AMD_NB=y # CONFIG_RAPIDIO is not set # # Executable file formats / Emulations # # CONFIG_BINFMT_ELF is not set CONFIG_COMPAT_BINFMT_ELF=y # CONFIG_HAVE_AOUT is not set CONFIG_BINFMT_MISC=y CONFIG_IA32_EMULATION=y CONFIG_IA32_AOUT=y CONFIG_COMPAT=y CONFIG_COMPAT_FOR_U64_ALIGNMENT=y CONFIG_SYSVIPC_COMPAT=y CONFIG_KEYS_COMPAT=y CONFIG_HAVE_TEXT_POKE_SMP=y CONFIG_NET=y CONFIG_COMPAT_NETLINK_MESSAGES=y # # Networking options # # CONFIG_PACKET is not set CONFIG_UNIX=y CONFIG_XFRM=y CONFIG_NET_KEY=y # CONFIG_INET is not set CONFIG_NETWORK_SECMARK=y CONFIG_NETFILTER=y CONFIG_NETFILTER_DEBUG=y CONFIG_NETFILTER_ADVANCED=y # CONFIG_BRIDGE_NF_EBTABLES is not set # CONFIG_ATM is not set CONFIG_STP=y CONFIG_BRIDGE=y # CONFIG_VLAN_8021Q is not set CONFIG_DECNET=y CONFIG_LLC=y # CONFIG_LLC2 is not set # CONFIG_IPX is not set CONFIG_ATALK=y # CONFIG_DEV_APPLETALK is not set # CONFIG_PHONET is not set CONFIG_NET_SCHED=y # # Queueing/Scheduling # CONFIG_NET_SCH_CBQ=y CONFIG_NET_SCH_HTB=y # CONFIG_NET_SCH_HFSC is not set # CONFIG_NET_SCH_PRIO is not set CONFIG_NET_SCH_MULTIQ=y CONFIG_NET_SCH_RED=y CONFIG_NET_SCH_SFB=y CONFIG_NET_SCH_SFQ=y # CONFIG_NET_SCH_TEQL is not set # CONFIG_NET_SCH_TBF is not set CONFIG_NET_SCH_GRED=y CONFIG_NET_SCH_DSMARK=y # CONFIG_NET_SCH_NETEM is not set CONFIG_NET_SCH_DRR=y CONFIG_NET_SCH_MQPRIO=y # CONFIG_NET_SCH_CHOKE is not set CONFIG_NET_SCH_QFQ=y # CONFIG_NET_SCH_INGRESS is not set # # Classification # CONFIG_NET_CLS=y # CONFIG_NET_CLS_BASIC is not set CONFIG_NET_CLS_TCINDEX=y # CONFIG_NET_CLS_FW is not set CONFIG_NET_CLS_U32=y CONFIG_CLS_U32_PERF=y # CONFIG_CLS_U32_MARK is not set # CONFIG_NET_CLS_RSVP is not set # CONFIG_NET_CLS_RSVP6 is not set # CONFIG_NET_CLS_FLOW is not set CONFIG_NET_CLS_CGROUP=y # CONFIG_NET_EMATCH is not set CONFIG_NET_CLS_ACT=y CONFIG_NET_ACT_POLICE=y CONFIG_NET_ACT_GACT=y # CONFIG_GACT_PROB is not set # CONFIG_NET_ACT_MIRRED is not set CONFIG_NET_ACT_NAT=y CONFIG_NET_ACT_PEDIT=y # CONFIG_NET_ACT_SIMP is not set # CONFIG_NET_ACT_SKBEDIT is not set CONFIG_NET_CLS_IND=y CONFIG_NET_SCH_FIFO=y # CONFIG_DCB is not set CONFIG_DNS_RESOLVER=y CONFIG_BATMAN_ADV=y # CONFIG_BATMAN_ADV_DEBUG is not set CONFIG_HAVE_BPF_JIT=y # # Network testing # # CONFIG_NET_PKTGEN is not set # CONFIG_HAMRADIO is not set CONFIG_CAN=y # CONFIG_CAN_RAW is not set # CONFIG_CAN_BCM is not set CONFIG_CAN_GW=y # # CAN Device Drivers # # CONFIG_CAN_VCAN is not set CONFIG_CAN_SLCAN=y # CONFIG_CAN_DEV is not set CONFIG_CAN_DEBUG_DEVICES=y CONFIG_IRDA=y # # IrDA protocols # # CONFIG_IRLAN is not set # CONFIG_IRCOMM is not set # CONFIG_IRDA_ULTRA is not set # # IrDA options # CONFIG_IRDA_CACHE_LAST_LSAP=y CONFIG_IRDA_FAST_RR=y # CONFIG_IRDA_DEBUG is not set # # Infrared-port device drivers # # # SIR device drivers # # CONFIG_IRTTY_SIR is not set # # Dongle support # # # FIR device drivers # CONFIG_BT=y # CONFIG_BT_L2CAP is not set # CONFIG_BT_SCO is not set # # Bluetooth device drivers # # CONFIG_BT_HCIUART is not set # CONFIG_BT_HCIVHCI is not set # CONFIG_BT_MRVL is not set CONFIG_BT_WILINK=y CONFIG_WIRELESS=y CONFIG_WIRELESS_EXT=y CONFIG_WEXT_CORE=y CONFIG_WEXT_PROC=y CONFIG_WEXT_PRIV=y # CONFIG_CFG80211 is not set # CONFIG_WIRELESS_EXT_SYSFS is not set # CONFIG_LIB80211 is not set # # CFG80211 needs to be enabled for MAC80211 # # CONFIG_WIMAX is not set CONFIG_RFKILL=y CONFIG_RFKILL_LEDS=y # CONFIG_RFKILL_INPUT is not set # CONFIG_RFKILL_REGULATOR is not set # CONFIG_NET_9P is not set # CONFIG_CAIF is not set # # Device Drivers # # # Generic Driver Options # CONFIG_STANDALONE=y CONFIG_PREVENT_FIRMWARE_BUILD=y CONFIG_FW_LOADER=y CONFIG_FIRMWARE_IN_KERNEL=y CONFIG_EXTRA_FIRMWARE="" CONFIG_DEBUG_DRIVER=y CONFIG_DEBUG_DEVRES=y # CONFIG_SYS_HYPERVISOR is not set CONFIG_REGMAP=y CONFIG_REGMAP_I2C=y CONFIG_CONNECTOR=y CONFIG_PROC_EVENTS=y # CONFIG_MTD is not set # CONFIG_PARPORT is not set CONFIG_PNP=y CONFIG_PNP_DEBUG_MESSAGES=y # # Protocols # CONFIG_PNPACPI=y CONFIG_BLK_DEV=y # CONFIG_BLK_CPQ_DA is not set # CONFIG_BLK_CPQ_CISS_DA is not set # CONFIG_BLK_DEV_DAC960 is not set # CONFIG_BLK_DEV_COW_COMMON is not set CONFIG_BLK_DEV_LOOP=y CONFIG_BLK_DEV_LOOP_MIN_COUNT=8 # CONFIG_BLK_DEV_CRYPTOLOOP is not set # # DRBD disabled because PROC_FS, INET or CONNECTOR not selected # CONFIG_BLK_DEV_NBD=y # CONFIG_BLK_DEV_SX8 is not set # CONFIG_BLK_DEV_RAM is not set # CONFIG_CDROM_PKTCDVD is not set # CONFIG_ATA_OVER_ETH is not set CONFIG_XEN_BLKDEV_FRONTEND=y CONFIG_BLK_DEV_HD=y CONFIG_SENSORS_LIS3LV02D=y CONFIG_MISC_DEVICES=y CONFIG_AD525X_DPOT=y CONFIG_AD525X_DPOT_I2C=y CONFIG_PHANTOM=y # CONFIG_INTEL_MID_PTI is not set # CONFIG_SGI_IOC4 is not set CONFIG_ENCLOSURE_SERVICES=y CONFIG_HP_ILO=y # CONFIG_APDS9802ALS is not set CONFIG_ISL29003=y # CONFIG_ISL29020 is not set CONFIG_SENSORS_TSL2550=y # CONFIG_SENSORS_BH1780 is not set CONFIG_SENSORS_BH1770=y # CONFIG_SENSORS_APDS990X is not set # CONFIG_HMC6352 is not set # CONFIG_VMWARE_BALLOON is not set CONFIG_BMP085=y CONFIG_PCH_PHUB=y CONFIG_USB_SWITCH_FSA9480=y # # EEPROM support # # CONFIG_EEPROM_AT24 is not set CONFIG_EEPROM_LEGACY=y CONFIG_EEPROM_93CX6=y CONFIG_CB710_CORE=y CONFIG_CB710_DEBUG=y CONFIG_CB710_DEBUG_ASSUMPTIONS=y # # Texas Instruments shared transport line discipline # CONFIG_TI_ST=y CONFIG_SENSORS_LIS3_I2C=y CONFIG_HAVE_IDE=y # CONFIG_IDE is not set # # SCSI device support # CONFIG_SCSI_MOD=y # CONFIG_RAID_ATTRS is not set CONFIG_SCSI=y CONFIG_SCSI_DMA=y CONFIG_SCSI_TGT=y CONFIG_SCSI_NETLINK=y # CONFIG_SCSI_PROC_FS is not set # # SCSI support type (disk, tape, CD-ROM) # # CONFIG_BLK_DEV_SD is not set # CONFIG_CHR_DEV_ST is not set # CONFIG_CHR_DEV_OSST is not set # CONFIG_BLK_DEV_SR is not set # CONFIG_CHR_DEV_SG is not set # CONFIG_CHR_DEV_SCH is not set # CONFIG_SCSI_ENCLOSURE is not set CONFIG_SCSI_MULTI_LUN=y # CONFIG_SCSI_CONSTANTS is not set CONFIG_SCSI_LOGGING=y # CONFIG_SCSI_SCAN_ASYNC is not set # # SCSI Transports # CONFIG_SCSI_SPI_ATTRS=y CONFIG_SCSI_FC_ATTRS=y # CONFIG_SCSI_FC_TGT_ATTRS is not set CONFIG_SCSI_ISCSI_ATTRS=y CONFIG_SCSI_SAS_ATTRS=y CONFIG_SCSI_SAS_LIBSAS=y CONFIG_SCSI_SAS_HOST_SMP=y # CONFIG_SCSI_SRP_ATTRS is not set CONFIG_SCSI_LOWLEVEL=y CONFIG_ISCSI_BOOT_SYSFS=y CONFIG_SCSI_BNX2_ISCSI=y CONFIG_SCSI_BNX2X_FCOE=y # CONFIG_BE2ISCSI is not set # CONFIG_BLK_DEV_3W_XXXX_RAID is not set # CONFIG_SCSI_HPSA is not set CONFIG_SCSI_3W_9XXX=y CONFIG_SCSI_3W_SAS=y CONFIG_SCSI_ACARD=y # CONFIG_SCSI_AACRAID is not set CONFIG_SCSI_AIC7XXX=y CONFIG_AIC7XXX_CMDS_PER_DEVICE=32 CONFIG_AIC7XXX_RESET_DELAY_MS=5000 # CONFIG_AIC7XXX_DEBUG_ENABLE is not set CONFIG_AIC7XXX_DEBUG_MASK=0 # CONFIG_AIC7XXX_REG_PRETTY_PRINT is not set CONFIG_SCSI_AIC7XXX_OLD=y CONFIG_SCSI_AIC79XX=y CONFIG_AIC79XX_CMDS_PER_DEVICE=32 CONFIG_AIC79XX_RESET_DELAY_MS=5000 # CONFIG_AIC79XX_DEBUG_ENABLE is not set CONFIG_AIC79XX_DEBUG_MASK=0 # CONFIG_AIC79XX_REG_PRETTY_PRINT is not set CONFIG_SCSI_AIC94XX=y CONFIG_AIC94XX_DEBUG=y # CONFIG_SCSI_MVSAS is not set CONFIG_SCSI_MVUMI=y # CONFIG_SCSI_DPT_I2O is not set # CONFIG_SCSI_ADVANSYS is not set CONFIG_SCSI_ARCMSR=y # CONFIG_MEGARAID_NEWGEN is not set CONFIG_MEGARAID_LEGACY=y # CONFIG_MEGARAID_SAS is not set # CONFIG_SCSI_MPT2SAS is not set CONFIG_SCSI_HPTIOP=y CONFIG_VMWARE_PVSCSI=y CONFIG_LIBFC=y CONFIG_LIBFCOE=y CONFIG_FCOE=y # CONFIG_FCOE_FNIC is not set # CONFIG_SCSI_DMX3191D is not set CONFIG_SCSI_FUTURE_DOMAIN=y CONFIG_SCSI_IPS=y # CONFIG_SCSI_INITIO is not set # CONFIG_SCSI_INIA100 is not set CONFIG_SCSI_STEX=y # CONFIG_SCSI_SYM53C8XX_2 is not set # CONFIG_SCSI_QLOGIC_1280 is not set # CONFIG_SCSI_QLA_FC is not set CONFIG_SCSI_QLA_ISCSI=y # CONFIG_SCSI_LPFC is not set CONFIG_SCSI_DC390T=y CONFIG_SCSI_DEBUG=y CONFIG_SCSI_PMCRAID=y CONFIG_SCSI_PM8001=y CONFIG_SCSI_SRP=y CONFIG_SCSI_BFA_FC=y # CONFIG_SCSI_DH is not set # CONFIG_SCSI_OSD_INITIATOR is not set # CONFIG_ATA is not set # CONFIG_MD is not set CONFIG_TARGET_CORE=y # CONFIG_TCM_IBLOCK is not set # CONFIG_TCM_FILEIO is not set # CONFIG_TCM_PSCSI is not set # CONFIG_LOOPBACK_TARGET is not set CONFIG_TCM_FC=y CONFIG_ISCSI_TARGET=y CONFIG_FUSION=y CONFIG_FUSION_SPI=y CONFIG_FUSION_FC=y # CONFIG_FUSION_SAS is not set CONFIG_FUSION_MAX_SGE=128 # CONFIG_FUSION_CTL is not set CONFIG_FUSION_LAN=y CONFIG_FUSION_LOGGING=y # # IEEE 1394 (FireWire) support # CONFIG_FIREWIRE=y CONFIG_FIREWIRE_OHCI=y CONFIG_FIREWIRE_OHCI_DEBUG=y CONFIG_FIREWIRE_SBP2=y CONFIG_FIREWIRE_NOSY=y # CONFIG_I2O is not set # CONFIG_MACINTOSH_DRIVERS is not set CONFIG_NETDEVICES=y CONFIG_NET_CORE=y # CONFIG_DUMMY is not set CONFIG_EQUALIZER=y CONFIG_NET_FC=y CONFIG_MII=y CONFIG_IFB=y # CONFIG_NETCONSOLE is not set # CONFIG_NETPOLL is not set # CONFIG_NET_POLL_CONTROLLER is not set CONFIG_TUN=y CONFIG_VETH=y CONFIG_ARCNET=y # CONFIG_ARCNET_1201 is not set # CONFIG_ARCNET_1051 is not set # CONFIG_ARCNET_RAW is not set CONFIG_ARCNET_CAP=y CONFIG_ARCNET_COM90xx=y CONFIG_ARCNET_COM90xxIO=y # CONFIG_ARCNET_RIM_I is not set # CONFIG_ARCNET_COM20020 is not set # # CAIF transport drivers # CONFIG_ETHERNET=y CONFIG_MDIO=y # CONFIG_NET_VENDOR_3COM is not set # CONFIG_NET_VENDOR_ADAPTEC is not set CONFIG_NET_VENDOR_ALTEON=y # CONFIG_ACENIC is not set CONFIG_NET_VENDOR_AMD=y CONFIG_AMD8111_ETH=y # CONFIG_PCNET32 is not set CONFIG_NET_VENDOR_ATHEROS=y CONFIG_ATL2=y CONFIG_ATL1=y CONFIG_NET_VENDOR_BROADCOM=y # CONFIG_B44 is not set CONFIG_BNX2=y CONFIG_CNIC=y # CONFIG_TIGON3 is not set CONFIG_BNX2X=y CONFIG_NET_VENDOR_BROCADE=y # CONFIG_BNA is not set CONFIG_NET_VENDOR_CHELSIO=y # CONFIG_CHELSIO_T1 is not set # CONFIG_CHELSIO_T4 is not set # CONFIG_CHELSIO_T4VF is not set CONFIG_DNET=y CONFIG_NET_VENDOR_DEC=y CONFIG_NET_TULIP=y # CONFIG_DE2104X is not set # CONFIG_TULIP is not set # CONFIG_DE4X5 is not set CONFIG_WINBOND_840=y # CONFIG_DM9102 is not set # CONFIG_ULI526X is not set CONFIG_NET_VENDOR_DLINK=y CONFIG_DL2K=y # CONFIG_SUNDANCE is not set # CONFIG_NET_VENDOR_EXAR is not set # CONFIG_NET_VENDOR_HP is not set CONFIG_NET_VENDOR_INTEL=y CONFIG_E100=y CONFIG_E1000=y CONFIG_E1000E=y # CONFIG_IGB is not set CONFIG_IGBVF=y CONFIG_IXGB=y # CONFIG_IXGBEVF is not set # CONFIG_JME is not set CONFIG_NET_VENDOR_MARVELL=y CONFIG_SKGE=y # CONFIG_SKGE_DEBUG is not set CONFIG_SKGE_GENESIS=y CONFIG_SKY2=y # CONFIG_SKY2_DEBUG is not set CONFIG_NET_VENDOR_MICREL=y CONFIG_KS8851_MLL=y # CONFIG_KSZ884X_PCI is not set # CONFIG_FEALNX is not set # CONFIG_NET_VENDOR_NATSEMI is not set # CONFIG_NET_VENDOR_NVIDIA is not set CONFIG_NET_VENDOR_OKI=y # CONFIG_PCH_GBE is not set CONFIG_ETHOC=y # CONFIG_NET_PACKET_ENGINE is not set # CONFIG_NET_VENDOR_QLOGIC is not set # CONFIG_NET_VENDOR_REALTEK is not set # CONFIG_NET_VENDOR_RDC is not set CONFIG_NET_VENDOR_SIS=y # CONFIG_SIS900 is not set # CONFIG_SIS190 is not set CONFIG_NET_VENDOR_SMSC=y CONFIG_EPIC100=y CONFIG_SMSC9420=y CONFIG_NET_VENDOR_STMICRO=y # CONFIG_STMMAC_ETH is not set CONFIG_NET_VENDOR_SUN=y CONFIG_HAPPYMEAL=y # CONFIG_SUNGEM is not set CONFIG_CASSINI=y CONFIG_NIU=y CONFIG_NET_VENDOR_TEHUTI=y CONFIG_TEHUTI=y CONFIG_NET_VENDOR_TI=y # CONFIG_TLAN is not set CONFIG_NET_VENDOR_VIA=y CONFIG_VIA_RHINE=y CONFIG_VIA_RHINE_MMIO=y # CONFIG_VIA_VELOCITY is not set CONFIG_FDDI=y # CONFIG_DEFXX is not set CONFIG_SKFP=y CONFIG_NET_SB1000=y CONFIG_PHYLIB=y # # MII PHY device drivers # # CONFIG_MARVELL_PHY is not set # CONFIG_DAVICOM_PHY is not set # CONFIG_QSEMI_PHY is not set # CONFIG_LXT_PHY is not set CONFIG_CICADA_PHY=y # CONFIG_VITESSE_PHY is not set CONFIG_SMSC_PHY=y CONFIG_BROADCOM_PHY=y CONFIG_ICPLUS_PHY=y # CONFIG_REALTEK_PHY is not set CONFIG_NATIONAL_PHY=y CONFIG_STE10XP=y CONFIG_LSI_ET1011C_PHY=y CONFIG_MICREL_PHY=y CONFIG_FIXED_PHY=y CONFIG_MDIO_BITBANG=y CONFIG_MDIO_GPIO=y # CONFIG_PPP is not set # CONFIG_SLIP is not set # CONFIG_TR is not set CONFIG_WLAN=y CONFIG_ATMEL=y # CONFIG_PCI_ATMEL is not set # CONFIG_HOSTAP is not set # # Enable WiMAX (Networking options) to see the WiMAX drivers # # CONFIG_WAN is not set CONFIG_XEN_NETDEV_FRONTEND=y CONFIG_ISDN=y CONFIG_ISDN_I4L=y # CONFIG_ISDN_AUDIO is not set # # ISDN feature submodules # # CONFIG_ISDN_DRV_LOOP is not set CONFIG_ISDN_DIVERSION=y # # ISDN4Linux hardware drivers # # # Passive cards # CONFIG_ISDN_DRV_HISAX=y # # D-channel protocol features # CONFIG_HISAX_EURO=y # CONFIG_DE_AOC is not set CONFIG_HISAX_NO_SENDCOMPLETE=y CONFIG_HISAX_NO_LLC=y CONFIG_HISAX_NO_KEYPAD=y CONFIG_HISAX_1TR6=y # CONFIG_HISAX_NI1 is not set CONFIG_HISAX_MAX_CARDS=8 # # HiSax supported cards # # CONFIG_HISAX_16_3 is not set CONFIG_HISAX_TELESPCI=y CONFIG_HISAX_S0BOX=y CONFIG_HISAX_FRITZPCI=y # CONFIG_HISAX_AVM_A1_PCMCIA is not set # CONFIG_HISAX_ELSA is not set # CONFIG_HISAX_DIEHLDIVA is not set # CONFIG_HISAX_SEDLBAUER is not set # CONFIG_HISAX_NETJET is not set CONFIG_HISAX_NETJET_U=y CONFIG_HISAX_NICCY=y CONFIG_HISAX_BKM_A4T=y # CONFIG_HISAX_SCT_QUADRO is not set CONFIG_HISAX_GAZEL=y CONFIG_HISAX_HFC_PCI=y # CONFIG_HISAX_W6692 is not set # CONFIG_HISAX_HFC_SX is not set # CONFIG_HISAX_DEBUG is not set # # HiSax PCMCIA card service modules # # # HiSax sub driver modules # # # Active cards # # CONFIG_ISDN_CAPI is not set # CONFIG_ISDN_DRV_GIGASET is not set CONFIG_MISDN=y CONFIG_MISDN_DSP=y CONFIG_MISDN_L1OIP=y # # mISDN hardware drivers # CONFIG_MISDN_HFCPCI=y # CONFIG_MISDN_HFCMULTI is not set CONFIG_MISDN_AVMFRITZ=y CONFIG_MISDN_SPEEDFAX=y # CONFIG_MISDN_INFINEON is not set # CONFIG_MISDN_W6692 is not set CONFIG_MISDN_NETJET=y CONFIG_MISDN_IPAC=y CONFIG_MISDN_ISAR=y CONFIG_ISDN_HDLC=y # CONFIG_PHONE is not set # # Input device support # CONFIG_INPUT=y CONFIG_INPUT_FF_MEMLESS=y CONFIG_INPUT_POLLDEV=y CONFIG_INPUT_SPARSEKMAP=y # # Userland interfaces # # CONFIG_INPUT_MOUSEDEV is not set CONFIG_INPUT_JOYDEV=y # CONFIG_INPUT_EVDEV is not set # CONFIG_INPUT_EVBUG is not set # # Input Device Drivers # # CONFIG_INPUT_KEYBOARD is not set CONFIG_INPUT_MOUSE=y CONFIG_MOUSE_PS2=y CONFIG_MOUSE_PS2_ALPS=y # CONFIG_MOUSE_PS2_LOGIPS2PP is not set # CONFIG_MOUSE_PS2_SYNAPTICS is not set # CONFIG_MOUSE_PS2_TRACKPOINT is not set # CONFIG_MOUSE_PS2_ELANTECH is not set # CONFIG_MOUSE_PS2_SENTELIC is not set CONFIG_MOUSE_PS2_TOUCHKIT=y # CONFIG_MOUSE_SERIAL is not set CONFIG_MOUSE_VSXXXAA=y CONFIG_MOUSE_GPIO=y CONFIG_MOUSE_SYNAPTICS_I2C=y # CONFIG_INPUT_JOYSTICK is not set CONFIG_INPUT_TABLET=y CONFIG_INPUT_TOUCHSCREEN=y # CONFIG_TOUCHSCREEN_88PM860X is not set CONFIG_TOUCHSCREEN_AD7879=y CONFIG_TOUCHSCREEN_AD7879_I2C=y # CONFIG_TOUCHSCREEN_ATMEL_MXT is not set CONFIG_TOUCHSCREEN_BU21013=y CONFIG_TOUCHSCREEN_CY8CTMG110=y # CONFIG_TOUCHSCREEN_DA9034 is not set # CONFIG_TOUCHSCREEN_DYNAPRO is not set CONFIG_TOUCHSCREEN_HAMPSHIRE=y CONFIG_TOUCHSCREEN_EETI=y CONFIG_TOUCHSCREEN_FUJITSU=y # CONFIG_TOUCHSCREEN_GUNZE is not set CONFIG_TOUCHSCREEN_ELO=y # CONFIG_TOUCHSCREEN_WACOM_W8001 is not set # CONFIG_TOUCHSCREEN_MAX11801 is not set CONFIG_TOUCHSCREEN_MCS5000=y CONFIG_TOUCHSCREEN_MTOUCH=y # CONFIG_TOUCHSCREEN_INEXIO is not set CONFIG_TOUCHSCREEN_MK712=y CONFIG_TOUCHSCREEN_PENMOUNT=y # CONFIG_TOUCHSCREEN_TOUCHRIGHT is not set # CONFIG_TOUCHSCREEN_TOUCHWIN is not set # CONFIG_TOUCHSCREEN_WM831X is not set CONFIG_TOUCHSCREEN_TOUCHIT213=y CONFIG_TOUCHSCREEN_TSC2007=y CONFIG_TOUCHSCREEN_ST1232=y CONFIG_TOUCHSCREEN_TPS6507X=y CONFIG_INPUT_MISC=y # CONFIG_INPUT_88PM860X_ONKEY is not set # CONFIG_INPUT_AD714X is not set CONFIG_INPUT_BMA150=y # CONFIG_INPUT_PCSPKR is not set CONFIG_INPUT_MAX8925_ONKEY=y # CONFIG_INPUT_MMA8450 is not set CONFIG_INPUT_MPU3050=y # CONFIG_INPUT_APANEL is not set # CONFIG_INPUT_ATLAS_BTNS is not set # CONFIG_INPUT_KXTJ9 is not set CONFIG_INPUT_UINPUT=y CONFIG_INPUT_PCF50633_PMU=y CONFIG_INPUT_GPIO_ROTARY_ENCODER=y CONFIG_INPUT_WM831X_ON=y CONFIG_INPUT_ADXL34X=y CONFIG_INPUT_ADXL34X_I2C=y CONFIG_INPUT_CMA3000=y # CONFIG_INPUT_CMA3000_I2C is not set # CONFIG_INPUT_XEN_KBDDEV_FRONTEND is not set # # Hardware I/O ports # CONFIG_SERIO=y CONFIG_SERIO_I8042=y CONFIG_SERIO_SERPORT=y CONFIG_SERIO_CT82C710=y # CONFIG_SERIO_PCIPS2 is not set CONFIG_SERIO_LIBPS2=y CONFIG_SERIO_RAW=y CONFIG_SERIO_ALTERA_PS2=y # CONFIG_SERIO_PS2MULT is not set CONFIG_GAMEPORT=y # CONFIG_GAMEPORT_NS558 is not set # CONFIG_GAMEPORT_L4 is not set # CONFIG_GAMEPORT_EMU10K1 is not set # CONFIG_GAMEPORT_FM801 is not set # # Character devices # CONFIG_VT=y CONFIG_CONSOLE_TRANSLATIONS=y CONFIG_VT_CONSOLE=y CONFIG_VT_CONSOLE_SLEEP=y CONFIG_HW_CONSOLE=y # CONFIG_VT_HW_CONSOLE_BINDING is not set # CONFIG_UNIX98_PTYS is not set # CONFIG_LEGACY_PTYS is not set # CONFIG_SERIAL_NONSTANDARD is not set # CONFIG_TRACE_SINK is not set CONFIG_DEVKMEM=y # # Serial drivers # CONFIG_SERIAL_8250=y # CONFIG_SERIAL_8250_CONSOLE is not set CONFIG_FIX_EARLYCON_MEM=y CONFIG_SERIAL_8250_PCI=y # CONFIG_SERIAL_8250_PNP is not set CONFIG_SERIAL_8250_NR_UARTS=4 CONFIG_SERIAL_8250_RUNTIME_UARTS=4 # CONFIG_SERIAL_8250_EXTENDED is not set # # Non-8250 serial port support # CONFIG_SERIAL_MFD_HSU=y CONFIG_SERIAL_MFD_HSU_CONSOLE=y # CONFIG_SERIAL_UARTLITE is not set CONFIG_SERIAL_CORE=y CONFIG_SERIAL_CORE_CONSOLE=y CONFIG_SERIAL_JSM=y # CONFIG_SERIAL_TIMBERDALE is not set CONFIG_SERIAL_ALTERA_JTAGUART=y CONFIG_SERIAL_ALTERA_JTAGUART_CONSOLE=y # CONFIG_SERIAL_ALTERA_JTAGUART_CONSOLE_BYPASS is not set CONFIG_SERIAL_ALTERA_UART=y CONFIG_SERIAL_ALTERA_UART_MAXPORTS=4 CONFIG_SERIAL_ALTERA_UART_BAUDRATE=115200 CONFIG_SERIAL_ALTERA_UART_CONSOLE=y # CONFIG_SERIAL_PCH_UART is not set # CONFIG_SERIAL_XILINX_PS_UART is not set # CONFIG_TTY_PRINTK is not set # CONFIG_HVC_XEN is not set # CONFIG_IPMI_HANDLER is not set CONFIG_HW_RANDOM=y # CONFIG_HW_RANDOM_TIMERIOMEM is not set # CONFIG_HW_RANDOM_INTEL is not set # CONFIG_HW_RANDOM_AMD is not set CONFIG_HW_RANDOM_VIA=y CONFIG_NVRAM=y CONFIG_R3964=y CONFIG_APPLICOM=y # CONFIG_MWAVE is not set # CONFIG_RAW_DRIVER is not set CONFIG_HPET=y # CONFIG_HPET_MMAP is not set CONFIG_HANGCHECK_TIMER=y CONFIG_DEVPORT=y # CONFIG_RAMOOPS is not set CONFIG_I2C=y CONFIG_I2C_BOARDINFO=y # CONFIG_I2C_COMPAT is not set # CONFIG_I2C_CHARDEV is not set # CONFIG_I2C_HELPER_AUTO is not set # CONFIG_I2C_SMBUS is not set # # I2C Algorithms # CONFIG_I2C_ALGOBIT=y # CONFIG_I2C_ALGOPCF is not set # CONFIG_I2C_ALGOPCA is not set # # I2C Hardware Bus support # # # PC SMBus host controller drivers # # CONFIG_I2C_ALI1535 is not set CONFIG_I2C_ALI15X3=y # CONFIG_I2C_AMD756 is not set # CONFIG_I2C_AMD8111 is not set # CONFIG_I2C_I801 is not set CONFIG_I2C_ISCH=y CONFIG_I2C_PIIX4=y # CONFIG_I2C_NFORCE2 is not set CONFIG_I2C_SIS5595=y # CONFIG_I2C_SIS630 is not set # CONFIG_I2C_SIS96X is not set CONFIG_I2C_VIAPRO=y # # ACPI drivers # CONFIG_I2C_SCMI=y # # I2C system bus drivers (mostly embedded / system-on-chip) # # CONFIG_I2C_GPIO is not set CONFIG_I2C_INTEL_MID=y # CONFIG_I2C_PCA_PLATFORM is not set # CONFIG_I2C_PXA_PCI is not set # CONFIG_I2C_SIMTEC is not set # CONFIG_I2C_EG20T is not set # # External I2C/SMBus adapter drivers # # CONFIG_I2C_PARPORT_LIGHT is not set # # Other I2C/SMBus bus drivers # CONFIG_I2C_DEBUG_CORE=y # CONFIG_I2C_DEBUG_ALGO is not set CONFIG_I2C_DEBUG_BUS=y # CONFIG_SPI is not set # # PPS support # # # PPS generators support # # # PTP clock support # # # Enable Device Drivers -> PPS to see the PTP clock options. # CONFIG_ARCH_WANT_OPTIONAL_GPIOLIB=y CONFIG_GPIOLIB=y # CONFIG_DEBUG_GPIO is not set CONFIG_GPIO_GENERIC=y # # Memory mapped GPIO drivers: # CONFIG_GPIO_GENERIC_PLATFORM=y CONFIG_GPIO_IT8761E=y # CONFIG_GPIO_SCH is not set # CONFIG_GPIO_VX855 is not set # # I2C GPIO expanders: # # CONFIG_GPIO_MAX7300 is not set CONFIG_GPIO_MAX732X=y CONFIG_GPIO_MAX732X_IRQ=y # CONFIG_GPIO_PCA953X is not set # CONFIG_GPIO_PCF857X is not set CONFIG_GPIO_SX150X=y CONFIG_GPIO_WM831X=y # CONFIG_GPIO_ADP5520 is not set CONFIG_GPIO_ADP5588=y CONFIG_GPIO_ADP5588_IRQ=y # # PCI GPIO expanders: # CONFIG_GPIO_BT8XX=y # CONFIG_GPIO_LANGWELL is not set CONFIG_GPIO_PCH=y # CONFIG_GPIO_ML_IOH is not set # CONFIG_GPIO_TIMBERDALE is not set # CONFIG_GPIO_RDC321X is not set # # SPI GPIO expanders: # # CONFIG_GPIO_MCP23S08 is not set # # AC97 GPIO expanders: # # # MODULbus GPIO expanders: # CONFIG_GPIO_JANZ_TTL=y CONFIG_GPIO_TPS65910=y CONFIG_W1=y CONFIG_W1_CON=y # # 1-wire Bus Masters # CONFIG_W1_MASTER_MATROX=y CONFIG_W1_MASTER_DS1WM=y # CONFIG_W1_MASTER_GPIO is not set # # 1-wire Slaves # CONFIG_W1_SLAVE_THERM=y CONFIG_W1_SLAVE_SMEM=y # CONFIG_W1_SLAVE_DS2408 is not set CONFIG_W1_SLAVE_DS2423=y CONFIG_W1_SLAVE_DS2431=y # CONFIG_W1_SLAVE_DS2433 is not set CONFIG_W1_SLAVE_DS2760=y CONFIG_W1_SLAVE_DS2780=y # CONFIG_W1_SLAVE_BQ27000 is not set CONFIG_POWER_SUPPLY=y # CONFIG_POWER_SUPPLY_DEBUG is not set CONFIG_PDA_POWER=y # CONFIG_MAX8925_POWER is not set # CONFIG_WM831X_BACKUP is not set CONFIG_WM831X_POWER=y CONFIG_TEST_POWER=y CONFIG_BATTERY_DS2760=y CONFIG_BATTERY_DS2780=y # CONFIG_BATTERY_DS2782 is not set CONFIG_BATTERY_BQ20Z75=y CONFIG_BATTERY_BQ27x00=y # CONFIG_BATTERY_BQ27X00_I2C is not set # CONFIG_BATTERY_BQ27X00_PLATFORM is not set CONFIG_BATTERY_DA9030=y CONFIG_BATTERY_MAX17040=y # CONFIG_BATTERY_MAX17042 is not set # CONFIG_CHARGER_PCF50633 is not set CONFIG_CHARGER_MAX8903=y # CONFIG_CHARGER_GPIO is not set # CONFIG_CHARGER_MAX8997 is not set CONFIG_CHARGER_MAX8998=y # CONFIG_HWMON is not set CONFIG_THERMAL=y CONFIG_WATCHDOG=y # CONFIG_WATCHDOG_CORE is not set # CONFIG_WATCHDOG_NOWAYOUT is not set # # Watchdog Device Drivers # # CONFIG_SOFT_WATCHDOG is not set CONFIG_WM831X_WATCHDOG=y # CONFIG_ACQUIRE_WDT is not set CONFIG_ADVANTECH_WDT=y CONFIG_ALIM1535_WDT=y CONFIG_ALIM7101_WDT=y CONFIG_SP5100_TCO=y CONFIG_SC520_WDT=y CONFIG_SBC_FITPC2_WATCHDOG=y CONFIG_EUROTECH_WDT=y CONFIG_IB700_WDT=y # CONFIG_IBMASR is not set CONFIG_WAFER_WDT=y # CONFIG_I6300ESB_WDT is not set # CONFIG_ITCO_WDT is not set # CONFIG_IT8712F_WDT is not set # CONFIG_HP_WATCHDOG is not set CONFIG_SC1200_WDT=y # CONFIG_PC87413_WDT is not set # CONFIG_NV_TCO is not set # CONFIG_60XX_WDT is not set # CONFIG_SBC8360_WDT is not set # CONFIG_CPU5_WDT is not set CONFIG_SMSC_SCH311X_WDT=y CONFIG_SMSC37B787_WDT=y # CONFIG_W83627HF_WDT is not set # CONFIG_W83697HF_WDT is not set CONFIG_W83697UG_WDT=y # CONFIG_W83877F_WDT is not set # CONFIG_W83977F_WDT is not set # CONFIG_MACHZ_WDT is not set # CONFIG_SBC_EPX_C3_WATCHDOG is not set CONFIG_XEN_WDT=y # # PCI-based Watchdog Cards # CONFIG_PCIPCWATCHDOG=y # CONFIG_WDTPCI is not set CONFIG_SSB_POSSIBLE=y # # Sonics Silicon Backplane # # CONFIG_SSB is not set CONFIG_BCMA_POSSIBLE=y # # Broadcom specific AMBA # CONFIG_BCMA=y CONFIG_BCMA_HOST_PCI_POSSIBLE=y # CONFIG_BCMA_HOST_PCI is not set CONFIG_BCMA_DEBUG=y # # Multifunction device drivers # CONFIG_MFD_CORE=y CONFIG_MFD_88PM860X=y CONFIG_MFD_SM501=y # CONFIG_MFD_SM501_GPIO is not set # CONFIG_HTC_PASIC3 is not set CONFIG_HTC_I2CPLD=y CONFIG_TPS6105X=y # CONFIG_TPS65010 is not set # CONFIG_TPS6507X is not set # CONFIG_MFD_TPS6586X is not set CONFIG_MFD_TPS65910=y # CONFIG_MFD_TPS65912_I2C is not set # CONFIG_TWL4030_CORE is not set # CONFIG_MFD_STMPE is not set # CONFIG_MFD_TC3589X is not set # CONFIG_MFD_TMIO is not set CONFIG_PMIC_DA903X=y CONFIG_PMIC_ADP5520=y CONFIG_MFD_MAX8925=y CONFIG_MFD_MAX8997=y CONFIG_MFD_MAX8998=y # CONFIG_MFD_WM8400 is not set CONFIG_MFD_WM831X=y CONFIG_MFD_WM831X_I2C=y # CONFIG_MFD_WM8350_I2C is not set # CONFIG_MFD_WM8994 is not set CONFIG_MFD_PCF50633=y # CONFIG_PCF50633_ADC is not set CONFIG_PCF50633_GPIO=y # CONFIG_ABX500_CORE is not set # CONFIG_MFD_CS5535 is not set CONFIG_MFD_TIMBERDALE=y CONFIG_LPC_SCH=y CONFIG_MFD_RDC321X=y CONFIG_MFD_JANZ_CMODIO=y # CONFIG_MFD_VX855 is not set CONFIG_MFD_WL1273_CORE=y # CONFIG_MFD_AAT2870_CORE is not set CONFIG_REGULATOR=y CONFIG_REGULATOR_DEBUG=y CONFIG_REGULATOR_DUMMY=y CONFIG_REGULATOR_FIXED_VOLTAGE=y CONFIG_REGULATOR_VIRTUAL_CONSUMER=y CONFIG_REGULATOR_USERSPACE_CONSUMER=y CONFIG_REGULATOR_BQ24022=y CONFIG_REGULATOR_MAX1586=y CONFIG_REGULATOR_MAX8649=y # CONFIG_REGULATOR_MAX8660 is not set # CONFIG_REGULATOR_MAX8925 is not set # CONFIG_REGULATOR_MAX8952 is not set CONFIG_REGULATOR_MAX8997=y CONFIG_REGULATOR_MAX8998=y # CONFIG_REGULATOR_WM831X is not set # CONFIG_REGULATOR_DA903X is not set # CONFIG_REGULATOR_PCF50633 is not set # CONFIG_REGULATOR_LP3971 is not set CONFIG_REGULATOR_LP3972=y # CONFIG_REGULATOR_TPS6105X is not set # CONFIG_REGULATOR_TPS65023 is not set # CONFIG_REGULATOR_TPS6507X is not set # CONFIG_REGULATOR_88PM8607 is not set CONFIG_REGULATOR_ISL6271A=y CONFIG_REGULATOR_AD5398=y CONFIG_REGULATOR_TPS65910=y # CONFIG_MEDIA_SUPPORT is not set # # Graphics support # CONFIG_AGP=y # CONFIG_AGP_AMD64 is not set CONFIG_AGP_INTEL=y # CONFIG_AGP_SIS is not set CONFIG_AGP_VIA=y CONFIG_VGA_ARB=y CONFIG_VGA_ARB_MAX_GPUS=16 # CONFIG_VGA_SWITCHEROO is not set CONFIG_DRM=y CONFIG_DRM_KMS_HELPER=y # CONFIG_DRM_TDFX is not set CONFIG_DRM_R128=y # CONFIG_DRM_RADEON is not set # CONFIG_DRM_I810 is not set CONFIG_DRM_I915=y CONFIG_DRM_I915_KMS=y # CONFIG_DRM_MGA is not set CONFIG_DRM_SIS=y # CONFIG_DRM_VIA is not set # CONFIG_DRM_SAVAGE is not set CONFIG_STUB_POULSBO=y CONFIG_VGASTATE=y CONFIG_VIDEO_OUTPUT_CONTROL=y CONFIG_FB=y CONFIG_FIRMWARE_EDID=y CONFIG_FB_DDC=y # CONFIG_FB_BOOT_VESA_SUPPORT is not set CONFIG_FB_CFB_FILLRECT=y CONFIG_FB_CFB_COPYAREA=y CONFIG_FB_CFB_IMAGEBLIT=y # CONFIG_FB_CFB_REV_PIXELS_IN_BYTE is not set CONFIG_FB_SYS_FILLRECT=y CONFIG_FB_SYS_COPYAREA=y CONFIG_FB_SYS_IMAGEBLIT=y # CONFIG_FB_FOREIGN_ENDIAN is not set CONFIG_FB_SYS_FOPS=y # CONFIG_FB_WMT_GE_ROPS is not set CONFIG_FB_DEFERRED_IO=y CONFIG_FB_HECUBA=y CONFIG_FB_SVGALIB=y # CONFIG_FB_MACMODES is not set CONFIG_FB_BACKLIGHT=y CONFIG_FB_MODE_HELPERS=y CONFIG_FB_TILEBLITTING=y # # Frame buffer hardware drivers # # CONFIG_FB_CIRRUS is not set # CONFIG_FB_PM2 is not set CONFIG_FB_CYBER2000=y CONFIG_FB_CYBER2000_DDC=y CONFIG_FB_ARC=y # CONFIG_FB_ASILIANT is not set # CONFIG_FB_IMSTT is not set CONFIG_FB_VGA16=y CONFIG_FB_UVESA=y # CONFIG_FB_VESA is not set # CONFIG_FB_EFI is not set CONFIG_FB_N411=y CONFIG_FB_HGA=y # CONFIG_FB_S1D13XXX is not set CONFIG_FB_NVIDIA=y # CONFIG_FB_NVIDIA_I2C is not set # CONFIG_FB_NVIDIA_DEBUG is not set CONFIG_FB_NVIDIA_BACKLIGHT=y CONFIG_FB_RIVA=y CONFIG_FB_RIVA_I2C=y # CONFIG_FB_RIVA_DEBUG is not set # CONFIG_FB_RIVA_BACKLIGHT is not set CONFIG_FB_LE80578=y CONFIG_FB_CARILLO_RANCH=y # CONFIG_FB_MATROX is not set # CONFIG_FB_RADEON is not set CONFIG_FB_ATY128=y # CONFIG_FB_ATY128_BACKLIGHT is not set # CONFIG_FB_ATY is not set # CONFIG_FB_S3 is not set # CONFIG_FB_SIS is not set # CONFIG_FB_VIA is not set # CONFIG_FB_NEOMAGIC is not set # CONFIG_FB_KYRO is not set # CONFIG_FB_3DFX is not set # CONFIG_FB_VOODOO1 is not set CONFIG_FB_VT8623=y CONFIG_FB_TRIDENT=y # CONFIG_FB_ARK is not set # CONFIG_FB_CARMINE is not set CONFIG_FB_TMIO=y CONFIG_FB_TMIO_ACCELL=y CONFIG_FB_SM501=y CONFIG_FB_VIRTUAL=y CONFIG_XEN_FBDEV_FRONTEND=y # CONFIG_FB_METRONOME is not set # CONFIG_FB_MB862XX is not set # CONFIG_FB_BROADSHEET is not set CONFIG_BACKLIGHT_LCD_SUPPORT=y CONFIG_LCD_CLASS_DEVICE=y CONFIG_LCD_PLATFORM=y CONFIG_BACKLIGHT_CLASS_DEVICE=y CONFIG_BACKLIGHT_GENERIC=y CONFIG_BACKLIGHT_PROGEAR=y CONFIG_BACKLIGHT_CARILLO_RANCH=y # CONFIG_BACKLIGHT_DA903X is not set # CONFIG_BACKLIGHT_MAX8925 is not set # CONFIG_BACKLIGHT_APPLE is not set CONFIG_BACKLIGHT_SAHARA=y CONFIG_BACKLIGHT_WM831X=y CONFIG_BACKLIGHT_ADP5520=y # CONFIG_BACKLIGHT_ADP8860 is not set CONFIG_BACKLIGHT_ADP8870=y # CONFIG_BACKLIGHT_88PM860X is not set CONFIG_BACKLIGHT_PCF50633=y # # Display device support # CONFIG_DISPLAY_SUPPORT=y # # Display hardware drivers # # # Console display driver support # CONFIG_VGA_CONSOLE=y # CONFIG_VGACON_SOFT_SCROLLBACK is not set CONFIG_DUMMY_CONSOLE=y # CONFIG_FRAMEBUFFER_CONSOLE is not set # CONFIG_LOGO is not set CONFIG_SOUND=y CONFIG_SOUND_OSS_CORE=y # CONFIG_SOUND_OSS_CORE_PRECLAIM is not set CONFIG_SND=y CONFIG_SND_TIMER=y CONFIG_SND_SEQUENCER=y CONFIG_SND_SEQ_DUMMY=y CONFIG_SND_OSSEMUL=y CONFIG_SND_MIXER_OSS=y # CONFIG_SND_PCM_OSS is not set CONFIG_SND_SEQUENCER_OSS=y CONFIG_SND_DYNAMIC_MINORS=y CONFIG_SND_SUPPORT_OLD_API=y CONFIG_SND_VERBOSE_PROCFS=y CONFIG_SND_VERBOSE_PRINTK=y # CONFIG_SND_DEBUG is not set CONFIG_SND_DMA_SGBUF=y # CONFIG_SND_RAWMIDI_SEQ is not set # CONFIG_SND_OPL3_LIB_SEQ is not set # CONFIG_SND_OPL4_LIB_SEQ is not set # CONFIG_SND_SBAWE_SEQ is not set # CONFIG_SND_EMU10K1_SEQ is not set # CONFIG_SND_DRIVERS is not set # CONFIG_SND_PCI is not set # CONFIG_SND_FIREWIRE is not set # CONFIG_SND_SOC is not set # CONFIG_SOUND_PRIME is not set CONFIG_HID_SUPPORT=y # CONFIG_HID is not set CONFIG_HID_PID=y # CONFIG_USB_SUPPORT is not set # CONFIG_MMC is not set # CONFIG_MEMSTICK is not set CONFIG_NEW_LEDS=y CONFIG_LEDS_CLASS=y # # LED drivers # CONFIG_LEDS_88PM860X=y # CONFIG_LEDS_LM3530 is not set # CONFIG_LEDS_GPIO is not set CONFIG_LEDS_LP3944=y # CONFIG_LEDS_LP5521 is not set CONFIG_LEDS_LP5523=y # CONFIG_LEDS_PCA955X is not set CONFIG_LEDS_WM831X_STATUS=y CONFIG_LEDS_DA903X=y # CONFIG_LEDS_REGULATOR is not set # CONFIG_LEDS_BD2802 is not set # CONFIG_LEDS_LT3593 is not set # CONFIG_LEDS_ADP5520 is not set CONFIG_LEDS_TRIGGERS=y # # LED Triggers # # CONFIG_LEDS_TRIGGER_TIMER is not set CONFIG_LEDS_TRIGGER_HEARTBEAT=y # CONFIG_LEDS_TRIGGER_BACKLIGHT is not set CONFIG_LEDS_TRIGGER_GPIO=y CONFIG_LEDS_TRIGGER_DEFAULT_ON=y # # iptables trigger is under Netfilter config (LED target) # CONFIG_ACCESSIBILITY=y # CONFIG_A11Y_BRAILLE_CONSOLE is not set # CONFIG_INFINIBAND is not set CONFIG_EDAC=y # # Reporting subsystems # # CONFIG_EDAC_DEBUG is not set # CONFIG_EDAC_DECODE_MCE is not set # CONFIG_EDAC_MM_EDAC is not set CONFIG_RTC_LIB=y CONFIG_RTC_CLASS=y CONFIG_RTC_HCTOSYS=y CONFIG_RTC_HCTOSYS_DEVICE="rtc0" CONFIG_RTC_DEBUG=y # # RTC interfaces # CONFIG_RTC_INTF_SYSFS=y CONFIG_RTC_INTF_PROC=y CONFIG_RTC_INTF_DEV=y CONFIG_RTC_INTF_DEV_UIE_EMUL=y # CONFIG_RTC_DRV_TEST is not set # # I2C RTC drivers # CONFIG_RTC_DRV_88PM860X=y # CONFIG_RTC_DRV_DS1307 is not set CONFIG_RTC_DRV_DS1374=y # CONFIG_RTC_DRV_DS1672 is not set # CONFIG_RTC_DRV_DS3232 is not set # CONFIG_RTC_DRV_MAX6900 is not set CONFIG_RTC_DRV_MAX8925=y # CONFIG_RTC_DRV_MAX8998 is not set # CONFIG_RTC_DRV_RS5C372 is not set # CONFIG_RTC_DRV_ISL1208 is not set CONFIG_RTC_DRV_ISL12022=y CONFIG_RTC_DRV_X1205=y CONFIG_RTC_DRV_PCF8563=y CONFIG_RTC_DRV_PCF8583=y CONFIG_RTC_DRV_M41T80=y # CONFIG_RTC_DRV_M41T80_WDT is not set # CONFIG_RTC_DRV_BQ32K is not set # CONFIG_RTC_DRV_S35390A is not set CONFIG_RTC_DRV_FM3130=y CONFIG_RTC_DRV_RX8581=y # CONFIG_RTC_DRV_RX8025 is not set # CONFIG_RTC_DRV_EM3027 is not set CONFIG_RTC_DRV_RV3029C2=y # # SPI RTC drivers # # # Platform RTC drivers # CONFIG_RTC_DRV_CMOS=y CONFIG_RTC_DRV_DS1286=y # CONFIG_RTC_DRV_DS1511 is not set # CONFIG_RTC_DRV_DS1553 is not set # CONFIG_RTC_DRV_DS1742 is not set # CONFIG_RTC_DRV_STK17TA8 is not set # CONFIG_RTC_DRV_M48T86 is not set # CONFIG_RTC_DRV_M48T35 is not set # CONFIG_RTC_DRV_M48T59 is not set CONFIG_RTC_DRV_MSM6242=y # CONFIG_RTC_DRV_BQ4802 is not set # CONFIG_RTC_DRV_RP5C01 is not set CONFIG_RTC_DRV_V3020=y # CONFIG_RTC_DRV_WM831X is not set CONFIG_RTC_DRV_PCF50633=y # # on-CPU RTC drivers # # CONFIG_DMADEVICES is not set CONFIG_AUXDISPLAY=y CONFIG_UIO=y # CONFIG_UIO_CIF is not set CONFIG_UIO_PDRV=y CONFIG_UIO_PDRV_GENIRQ=y # CONFIG_UIO_AEC is not set CONFIG_UIO_SERCOS3=y # CONFIG_UIO_PCI_GENERIC is not set # CONFIG_UIO_NETX is not set # # Virtio drivers # # CONFIG_VIRTIO_BALLOON is not set # # Xen driver support # # CONFIG_XEN_BALLOON is not set # CONFIG_XEN_DEV_EVTCHN is not set # CONFIG_XEN_BACKEND is not set # CONFIG_XENFS is not set # CONFIG_XEN_SYS_HYPERVISOR is not set CONFIG_XEN_XENBUS_FRONTEND=y # CONFIG_XEN_GNTDEV is not set # CONFIG_XEN_GRANT_DEV_ALLOC is not set CONFIG_XEN_PLATFORM_PCI=y CONFIG_SWIOTLB_XEN=y # CONFIG_STAGING is not set # CONFIG_X86_PLATFORM_DEVICES is not set # # Hardware Spinlock drivers # CONFIG_CLKEVT_I8253=y CONFIG_I8253_LOCK=y CONFIG_CLKBLD_I8253=y # CONFIG_IOMMU_SUPPORT is not set # CONFIG_VIRT_DRIVERS is not set # # Firmware Drivers # # CONFIG_EDD is not set # CONFIG_FIRMWARE_MEMMAP is not set # CONFIG_EFI_VARS is not set # CONFIG_DELL_RBU is not set # CONFIG_DCDBAS is not set CONFIG_ISCSI_IBFT_FIND=y CONFIG_ISCSI_IBFT=y CONFIG_SIGMA=y CONFIG_GOOGLE_FIRMWARE=y # # Google Firmware Drivers # # # File systems # CONFIG_EXT2_FS=y # CONFIG_EXT2_FS_XATTR is not set CONFIG_EXT2_FS_XIP=y # CONFIG_EXT3_FS is not set # CONFIG_EXT4_FS is not set CONFIG_FS_XIP=y # CONFIG_REISERFS_FS is not set # CONFIG_JFS_FS is not set CONFIG_XFS_FS=y CONFIG_XFS_QUOTA=y CONFIG_XFS_POSIX_ACL=y # CONFIG_XFS_RT is not set CONFIG_GFS2_FS=y # CONFIG_OCFS2_FS is not set CONFIG_FS_POSIX_ACL=y CONFIG_EXPORTFS=y CONFIG_FILE_LOCKING=y CONFIG_FSNOTIFY=y # CONFIG_DNOTIFY is not set CONFIG_INOTIFY_USER=y CONFIG_FANOTIFY=y # CONFIG_QUOTA is not set CONFIG_QUOTA_NETLINK_INTERFACE=y CONFIG_QUOTACTL=y CONFIG_QUOTACTL_COMPAT=y CONFIG_AUTOFS4_FS=y CONFIG_FUSE_FS=y CONFIG_CUSE=y # # Caches # # CONFIG_FSCACHE is not set # # CD-ROM/DVD Filesystems # # CONFIG_ISO9660_FS is not set CONFIG_UDF_FS=y CONFIG_UDF_NLS=y # # DOS/FAT/NT Filesystems # CONFIG_FAT_FS=y CONFIG_MSDOS_FS=y # CONFIG_VFAT_FS is not set CONFIG_FAT_DEFAULT_CODEPAGE=437 # CONFIG_NTFS_FS is not set # # Pseudo filesystems # CONFIG_PROC_FS=y CONFIG_PROC_KCORE=y CONFIG_PROC_VMCORE=y # CONFIG_PROC_SYSCTL is not set CONFIG_PROC_PAGE_MONITOR=y CONFIG_SYSFS=y CONFIG_TMPFS=y # CONFIG_TMPFS_POSIX_ACL is not set # CONFIG_TMPFS_XATTR is not set # CONFIG_HUGETLBFS is not set # CONFIG_HUGETLB_PAGE is not set CONFIG_CONFIGFS_FS=y CONFIG_MISC_FILESYSTEMS=y CONFIG_HFSPLUS_FS=y # CONFIG_CRAMFS is not set # CONFIG_SQUASHFS is not set # CONFIG_VXFS_FS is not set CONFIG_MINIX_FS=y CONFIG_OMFS_FS=y CONFIG_HPFS_FS=y CONFIG_QNX4FS_FS=y CONFIG_ROMFS_FS=y CONFIG_ROMFS_BACKED_BY_BLOCK=y CONFIG_ROMFS_ON_BLOCK=y CONFIG_PSTORE=y CONFIG_SYSV_FS=y CONFIG_UFS_FS=y # CONFIG_UFS_DEBUG is not set # CONFIG_NETWORK_FILESYSTEMS is not set # # Partition Types # CONFIG_PARTITION_ADVANCED=y CONFIG_ACORN_PARTITION=y CONFIG_ACORN_PARTITION_CUMANA=y CONFIG_ACORN_PARTITION_EESOX=y # CONFIG_ACORN_PARTITION_ICS is not set # CONFIG_ACORN_PARTITION_ADFS is not set # CONFIG_ACORN_PARTITION_POWERTEC is not set # CONFIG_ACORN_PARTITION_RISCIX is not set CONFIG_OSF_PARTITION=y # CONFIG_AMIGA_PARTITION is not set # CONFIG_ATARI_PARTITION is not set # CONFIG_MAC_PARTITION is not set # CONFIG_MSDOS_PARTITION is not set # CONFIG_LDM_PARTITION is not set # CONFIG_SGI_PARTITION is not set CONFIG_ULTRIX_PARTITION=y # CONFIG_SUN_PARTITION is not set # CONFIG_KARMA_PARTITION is not set CONFIG_EFI_PARTITION=y # CONFIG_SYSV68_PARTITION is not set CONFIG_NLS=y CONFIG_NLS_DEFAULT="iso8859-1" CONFIG_NLS_CODEPAGE_437=y # CONFIG_NLS_CODEPAGE_737 is not set CONFIG_NLS_CODEPAGE_775=y CONFIG_NLS_CODEPAGE_850=y CONFIG_NLS_CODEPAGE_852=y CONFIG_NLS_CODEPAGE_855=y # CONFIG_NLS_CODEPAGE_857 is not set CONFIG_NLS_CODEPAGE_860=y # CONFIG_NLS_CODEPAGE_861 is not set # CONFIG_NLS_CODEPAGE_862 is not set CONFIG_NLS_CODEPAGE_863=y CONFIG_NLS_CODEPAGE_864=y # CONFIG_NLS_CODEPAGE_865 is not set # CONFIG_NLS_CODEPAGE_866 is not set CONFIG_NLS_CODEPAGE_869=y # CONFIG_NLS_CODEPAGE_936 is not set CONFIG_NLS_CODEPAGE_950=y # CONFIG_NLS_CODEPAGE_932 is not set # CONFIG_NLS_CODEPAGE_949 is not set CONFIG_NLS_CODEPAGE_874=y CONFIG_NLS_ISO8859_8=y # CONFIG_NLS_CODEPAGE_1250 is not set # CONFIG_NLS_CODEPAGE_1251 is not set CONFIG_NLS_ASCII=y CONFIG_NLS_ISO8859_1=y # CONFIG_NLS_ISO8859_2 is not set # CONFIG_NLS_ISO8859_3 is not set # CONFIG_NLS_ISO8859_4 is not set # CONFIG_NLS_ISO8859_5 is not set # CONFIG_NLS_ISO8859_6 is not set CONFIG_NLS_ISO8859_7=y CONFIG_NLS_ISO8859_9=y CONFIG_NLS_ISO8859_13=y CONFIG_NLS_ISO8859_14=y # CONFIG_NLS_ISO8859_15 is not set CONFIG_NLS_KOI8_R=y # CONFIG_NLS_KOI8_U is not set CONFIG_NLS_UTF8=y # # Kernel hacking # CONFIG_TRACE_IRQFLAGS_SUPPORT=y CONFIG_DEFAULT_MESSAGE_LOGLEVEL=4 # CONFIG_ENABLE_WARN_DEPRECATED is not set # CONFIG_ENABLE_MUST_CHECK is not set CONFIG_FRAME_WARN=2048 # CONFIG_MAGIC_SYSRQ is not set # CONFIG_STRIP_ASM_SYMS is not set # CONFIG_UNUSED_SYMBOLS is not set CONFIG_DEBUG_FS=y # CONFIG_HEADERS_CHECK is not set CONFIG_DEBUG_SECTION_MISMATCH=y CONFIG_DEBUG_KERNEL=y CONFIG_DEBUG_SHIRQ=y CONFIG_LOCKUP_DETECTOR=y CONFIG_HARDLOCKUP_DETECTOR=y CONFIG_BOOTPARAM_HARDLOCKUP_PANIC=y CONFIG_BOOTPARAM_HARDLOCKUP_PANIC_VALUE=1 CONFIG_BOOTPARAM_SOFTLOCKUP_PANIC=y CONFIG_BOOTPARAM_SOFTLOCKUP_PANIC_VALUE=1 CONFIG_DETECT_HUNG_TASK=y CONFIG_DEFAULT_HUNG_TASK_TIMEOUT=120 # CONFIG_BOOTPARAM_HUNG_TASK_PANIC is not set CONFIG_BOOTPARAM_HUNG_TASK_PANIC_VALUE=0 CONFIG_SCHED_DEBUG=y CONFIG_SCHEDSTATS=y CONFIG_TIMER_STATS=y CONFIG_DEBUG_OBJECTS=y # CONFIG_DEBUG_OBJECTS_SELFTEST is not set CONFIG_DEBUG_OBJECTS_FREE=y CONFIG_DEBUG_OBJECTS_TIMERS=y # CONFIG_DEBUG_OBJECTS_WORK is not set CONFIG_DEBUG_OBJECTS_RCU_HEAD=y # CONFIG_DEBUG_OBJECTS_PERCPU_COUNTER is not set CONFIG_DEBUG_OBJECTS_ENABLE_DEFAULT=1 # CONFIG_SLUB_DEBUG_ON is not set CONFIG_SLUB_STATS=y # CONFIG_DEBUG_RT_MUTEXES is not set CONFIG_RT_MUTEX_TESTER=y # CONFIG_DEBUG_SPINLOCK is not set # CONFIG_DEBUG_MUTEXES is not set # CONFIG_DEBUG_LOCK_ALLOC is not set # CONFIG_PROVE_LOCKING is not set CONFIG_SPARSE_RCU_POINTER=y # CONFIG_LOCK_STAT is not set CONFIG_TRACE_IRQFLAGS=y # CONFIG_DEBUG_ATOMIC_SLEEP is not set CONFIG_DEBUG_LOCKING_API_SELFTESTS=y CONFIG_STACKTRACE=y # CONFIG_DEBUG_STACK_USAGE is not set # CONFIG_DEBUG_KOBJECT is not set CONFIG_DEBUG_BUGVERBOSE=y # CONFIG_DEBUG_INFO is not set # CONFIG_DEBUG_VM is not set CONFIG_DEBUG_VIRTUAL=y # CONFIG_DEBUG_WRITECOUNT is not set # CONFIG_DEBUG_MEMORY_INIT is not set # CONFIG_DEBUG_LIST is not set CONFIG_TEST_LIST_SORT=y # CONFIG_DEBUG_SG is not set CONFIG_DEBUG_NOTIFIERS=y CONFIG_DEBUG_CREDENTIALS=y CONFIG_ARCH_WANT_FRAME_POINTERS=y CONFIG_FRAME_POINTER=y # CONFIG_RCU_TORTURE_TEST is not set CONFIG_BACKTRACE_SELF_TEST=y CONFIG_DEBUG_BLOCK_EXT_DEVT=y CONFIG_DEBUG_FORCE_WEAK_PER_CPU=y # CONFIG_LKDTM is not set CONFIG_FAULT_INJECTION=y # CONFIG_FAILSLAB is not set CONFIG_FAIL_PAGE_ALLOC=y CONFIG_FAIL_MAKE_REQUEST=y CONFIG_FAIL_IO_TIMEOUT=y # CONFIG_FAULT_INJECTION_DEBUG_FS is not set CONFIG_LATENCYTOP=y CONFIG_ARCH_HAS_DEBUG_STRICT_USER_COPY_CHECKS=y CONFIG_DEBUG_PAGEALLOC=y CONFIG_USER_STACKTRACE_SUPPORT=y CONFIG_NOP_TRACER=y CONFIG_HAVE_FTRACE_NMI_ENTER=y CONFIG_HAVE_FUNCTION_TRACER=y CONFIG_HAVE_FUNCTION_GRAPH_TRACER=y CONFIG_HAVE_FUNCTION_GRAPH_FP_TEST=y CONFIG_HAVE_FUNCTION_TRACE_MCOUNT_TEST=y CONFIG_HAVE_DYNAMIC_FTRACE=y CONFIG_HAVE_FTRACE_MCOUNT_RECORD=y CONFIG_HAVE_SYSCALL_TRACEPOINTS=y CONFIG_HAVE_C_RECORDMCOUNT=y CONFIG_TRACER_MAX_TRACE=y CONFIG_RING_BUFFER=y CONFIG_FTRACE_NMI_ENTER=y CONFIG_EVENT_TRACING=y CONFIG_EVENT_POWER_TRACING_DEPRECATED=y CONFIG_CONTEXT_SWITCH_TRACER=y CONFIG_RING_BUFFER_ALLOW_SWAP=y CONFIG_TRACING=y CONFIG_GENERIC_TRACER=y CONFIG_TRACING_SUPPORT=y CONFIG_FTRACE=y CONFIG_FUNCTION_TRACER=y # CONFIG_FUNCTION_GRAPH_TRACER is not set CONFIG_IRQSOFF_TRACER=y # CONFIG_SCHED_TRACER is not set # CONFIG_FTRACE_SYSCALLS is not set CONFIG_TRACE_BRANCH_PROFILING=y # CONFIG_BRANCH_PROFILE_NONE is not set # CONFIG_PROFILE_ANNOTATED_BRANCHES is not set CONFIG_PROFILE_ALL_BRANCHES=y CONFIG_TRACING_BRANCHES=y CONFIG_BRANCH_TRACER=y CONFIG_STACK_TRACER=y # CONFIG_BLK_DEV_IO_TRACE is not set CONFIG_DYNAMIC_FTRACE=y # CONFIG_FUNCTION_PROFILER is not set CONFIG_FTRACE_MCOUNT_RECORD=y # CONFIG_FTRACE_STARTUP_TEST is not set # CONFIG_MMIOTRACE is not set CONFIG_RING_BUFFER_BENCHMARK=y # CONFIG_PROVIDE_OHCI1394_DMA_INIT is not set CONFIG_FIREWIRE_OHCI_REMOTE_DMA=y # CONFIG_DMA_API_DEBUG is not set # CONFIG_ATOMIC64_SELFTEST is not set # CONFIG_SAMPLES is not set CONFIG_HAVE_ARCH_KGDB=y CONFIG_HAVE_ARCH_KMEMCHECK=y CONFIG_TEST_KSTRTOX=y # CONFIG_STRICT_DEVMEM is not set # CONFIG_X86_VERBOSE_BOOTUP is not set # CONFIG_EARLY_PRINTK is not set # CONFIG_DEBUG_STACKOVERFLOW is not set # CONFIG_X86_PTDUMP is not set # CONFIG_DEBUG_RODATA is not set CONFIG_IOMMU_DEBUG=y # CONFIG_IOMMU_STRESS is not set CONFIG_HAVE_MMIOTRACE_SUPPORT=y CONFIG_IO_DELAY_TYPE_0X80=0 CONFIG_IO_DELAY_TYPE_0XED=1 CONFIG_IO_DELAY_TYPE_UDELAY=2 CONFIG_IO_DELAY_TYPE_NONE=3 CONFIG_IO_DELAY_0X80=y # CONFIG_IO_DELAY_0XED is not set # CONFIG_IO_DELAY_UDELAY is not set # CONFIG_IO_DELAY_NONE is not set CONFIG_DEFAULT_IO_DELAY_TYPE=0 CONFIG_DEBUG_BOOT_PARAMS=y # CONFIG_CPA_DEBUG is not set # CONFIG_OPTIMIZE_INLINING is not set # # Security options # CONFIG_KEYS=y # CONFIG_ENCRYPTED_KEYS is not set # CONFIG_KEYS_DEBUG_PROC_KEYS is not set # CONFIG_SECURITY_DMESG_RESTRICT is not set # CONFIG_SECURITY is not set CONFIG_SECURITYFS=y CONFIG_DEFAULT_SECURITY_DAC=y CONFIG_DEFAULT_SECURITY="" CONFIG_CRYPTO=y # # Crypto core or helper # CONFIG_CRYPTO_ALGAPI=y CONFIG_CRYPTO_ALGAPI2=y CONFIG_CRYPTO_AEAD=y CONFIG_CRYPTO_AEAD2=y CONFIG_CRYPTO_BLKCIPHER=y CONFIG_CRYPTO_BLKCIPHER2=y CONFIG_CRYPTO_HASH=y CONFIG_CRYPTO_HASH2=y CONFIG_CRYPTO_RNG=y CONFIG_CRYPTO_RNG2=y CONFIG_CRYPTO_PCOMP=y CONFIG_CRYPTO_PCOMP2=y CONFIG_CRYPTO_MANAGER=y CONFIG_CRYPTO_MANAGER2=y # CONFIG_CRYPTO_MANAGER_DISABLE_TESTS is not set CONFIG_CRYPTO_GF128MUL=y CONFIG_CRYPTO_NULL=y CONFIG_CRYPTO_WORKQUEUE=y CONFIG_CRYPTO_CRYPTD=y CONFIG_CRYPTO_AUTHENC=y # # Authenticated Encryption with Associated Data # # CONFIG_CRYPTO_CCM is not set CONFIG_CRYPTO_GCM=y CONFIG_CRYPTO_SEQIV=y # # Block modes # CONFIG_CRYPTO_CBC=y CONFIG_CRYPTO_CTR=y CONFIG_CRYPTO_CTS=y CONFIG_CRYPTO_ECB=y CONFIG_CRYPTO_PCBC=y # # Hash modes # # CONFIG_CRYPTO_HMAC is not set # # Digest # CONFIG_CRYPTO_CRC32C=y CONFIG_CRYPTO_CRC32C_INTEL=y CONFIG_CRYPTO_GHASH=y # CONFIG_CRYPTO_MD4 is not set # CONFIG_CRYPTO_MD5 is not set CONFIG_CRYPTO_MICHAEL_MIC=y # CONFIG_CRYPTO_RMD128 is not set CONFIG_CRYPTO_RMD160=y CONFIG_CRYPTO_RMD256=y CONFIG_CRYPTO_RMD320=y CONFIG_CRYPTO_SHA1=y CONFIG_CRYPTO_SHA1_SSSE3=y CONFIG_CRYPTO_SHA256=y # CONFIG_CRYPTO_SHA512 is not set CONFIG_CRYPTO_TGR192=y CONFIG_CRYPTO_WP512=y CONFIG_CRYPTO_GHASH_CLMUL_NI_INTEL=y # # Ciphers # CONFIG_CRYPTO_AES=y CONFIG_CRYPTO_AES_X86_64=y CONFIG_CRYPTO_AES_NI_INTEL=y # CONFIG_CRYPTO_ANUBIS is not set # CONFIG_CRYPTO_ARC4 is not set CONFIG_CRYPTO_BLOWFISH=y CONFIG_CRYPTO_BLOWFISH_COMMON=y # CONFIG_CRYPTO_BLOWFISH_X86_64 is not set CONFIG_CRYPTO_CAMELLIA=y # CONFIG_CRYPTO_CAST5 is not set CONFIG_CRYPTO_CAST6=y CONFIG_CRYPTO_DES=y # CONFIG_CRYPTO_FCRYPT is not set # CONFIG_CRYPTO_KHAZAD is not set # CONFIG_CRYPTO_SEED is not set CONFIG_CRYPTO_SERPENT=y CONFIG_CRYPTO_TEA=y # CONFIG_CRYPTO_TWOFISH is not set CONFIG_CRYPTO_TWOFISH_COMMON=y CONFIG_CRYPTO_TWOFISH_X86_64=y # # Compression # CONFIG_CRYPTO_DEFLATE=y CONFIG_CRYPTO_ZLIB=y # CONFIG_CRYPTO_LZO is not set # # Random Number Generation # # CONFIG_CRYPTO_ANSI_CPRNG is not set CONFIG_CRYPTO_USER_API=y # CONFIG_CRYPTO_USER_API_HASH is not set CONFIG_CRYPTO_USER_API_SKCIPHER=y CONFIG_CRYPTO_HW=y CONFIG_CRYPTO_DEV_PADLOCK=y # CONFIG_CRYPTO_DEV_PADLOCK_AES is not set # CONFIG_CRYPTO_DEV_PADLOCK_SHA is not set CONFIG_CRYPTO_DEV_HIFN_795X=y # CONFIG_CRYPTO_DEV_HIFN_795X_RNG is not set CONFIG_HAVE_KVM=y CONFIG_VIRTUALIZATION=y # CONFIG_KVM is not set CONFIG_BINARY_PRINTF=y # # Library routines # CONFIG_BITREVERSE=y CONFIG_GENERIC_FIND_FIRST_BIT=y CONFIG_CRC_CCITT=y CONFIG_CRC16=y CONFIG_CRC_T10DIF=y CONFIG_CRC_ITU_T=y CONFIG_CRC32=y CONFIG_CRC7=y CONFIG_LIBCRC32C=y # CONFIG_CRC8 is not set CONFIG_ZLIB_INFLATE=y CONFIG_ZLIB_DEFLATE=y CONFIG_LZO_COMPRESS=y CONFIG_LZO_DECOMPRESS=y CONFIG_XZ_DEC=y # CONFIG_XZ_DEC_X86 is not set CONFIG_XZ_DEC_POWERPC=y # CONFIG_XZ_DEC_IA64 is not set CONFIG_XZ_DEC_ARM=y # CONFIG_XZ_DEC_ARMTHUMB is not set # CONFIG_XZ_DEC_SPARC is not set CONFIG_XZ_DEC_BCJ=y CONFIG_XZ_DEC_TEST=y CONFIG_DECOMPRESS_GZIP=y CONFIG_DECOMPRESS_LZO=y CONFIG_HAS_IOMEM=y CONFIG_HAS_IOPORT=y CONFIG_HAS_DMA=y CONFIG_CHECK_SIGNATURE=y CONFIG_NLATTR=y # CONFIG_AVERAGE is not set CONFIG_CORDIC=y --------------080300090904080808020606 Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel --------------080300090904080808020606-- From xen-devel-bounces@lists.xensource.com Mon Sep 26 10:07:03 2011 Return-path: <xen-devel-bounces@lists.xensource.com> Envelope-to: www-data@lists.xensource.com Delivery-date: Mon, 26 Sep 2011 10:07:03 -0700 Received: from localhost ([127.0.0.1] helo=lists.colo.xensource.com) by lists.xensource.com with esmtp (Exim 4.43) id 1R8Edz-0000Ec-Lf; Mon, 26 Sep 2011 10:07:03 -0700 Received: from mail182.messagelabs.com ([85.158.139.83]) by lists.xensource.com with esmtp (Exim 4.43) id 1R8Ec2-0008S7-K4 for xen-devel@lists.xensource.com; Mon, 26 Sep 2011 10:05:05 -0700 X-Env-Sender: dan.magenheimer@oracle.com X-Msg-Ref: server-15.tower-182.messagelabs.com!1317056697!18799106!1 X-Originating-IP: [141.146.126.227] X-StarScan-Version: 6.4.1; banners=-,-,- X-VirusChecked: Checked Received: (qmail 2727 invoked from network); 26 Sep 2011 17:04:58 -0000 Received: from acsinet15.oracle.com (HELO acsinet15.oracle.com) (141.146.126.227) by server-15.tower-182.messagelabs.com with DHE-RSA-AES256-SHA encrypted SMTP; 26 Sep 2011 17:04:58 -0000 Received: from ucsinet24.oracle.com (ucsinet24.oracle.com [156.151.31.67]) by acsinet15.oracle.com (Switch-3.4.4/Switch-3.4.4) with ESMTP id p8QH4rfm029212 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Mon, 26 Sep 2011 17:04:54 GMT Received: from acsmt357.oracle.com (acsmt357.oracle.com [141.146.40.157]) by ucsinet24.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id p8QGxBLD023460 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 26 Sep 2011 16:59:14 GMT Received: from abhmt103.oracle.com (abhmt103.oracle.com [141.146.116.55]) by acsmt357.oracle.com (8.12.11.20060308/8.12.11) with ESMTP id p8QH4gS4023572; Mon, 26 Sep 2011 12:04:42 -0500 MIME-Version: 1.0 Message-ID: <719f11be-2aef-4db3-a0bb-db6355882f64@default> Date: Mon, 26 Sep 2011 10:04:21 -0700 (PDT) From: Dan Magenheimer <dan.magenheimer@oracle.com> To: Keir Fraser <keir.xen@gmail.com>, Konrad Wilk <konrad.wilk@oracle.com>, Andrew Cooper <andrew.cooper3@citrix.com> Subject: RE: [Xen-devel] [PATCH] IRQ Cleanup: rename nr_ioapic_registers to nr_ioapic_entries References: <20110926154514.GB17331@phenom.oracle.com CAA5F5FF.217CE%keir.xen@gmail.com> In-Reply-To: <CAA5F5FF.217CE%keir.xen@gmail.com> X-Priority: 3 X-Mailer: Oracle Beehive Extensions for Outlook 2.0.1.4.1.0 (410211) [OL 12.0.6557.5001] Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable X-Source-IP: ucsinet24.oracle.com [156.151.31.67] X-CT-RefId: str=0001.0A090206.4E80B0B7.002E,ss=1,re=0.000,fgs=0 Cc: xen-devel@lists.xensource.com, Jan Beulich <JBeulich@suse.com> X-BeenThere: xen-devel@lists.xensource.com X-Mailman-Version: 2.1.5 Precedence: list List-Id: Xen developer discussion <xen-devel.lists.xensource.com> List-Unsubscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe> List-Post: <mailto:xen-devel@lists.xensource.com> List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help> List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=subscribe> Sender: xen-devel-bounces@lists.xensource.com Errors-To: xen-devel-bounces@lists.xensource.com > From: Keir Fraser [mailto:keir.xen@gmail.com] > Sent: Monday, September 26, 2011 10:27 AM > To: Konrad Rzeszutek Wilk; Andrew Cooper > Cc: xen-devel@lists.xensource.com; Jan Beulich > Subject: Re: [Xen-devel] [PATCH] IRQ Cleanup: rename nr_ioapic_registers = to nr_ioapic_entries >=20 > On 26/09/2011 08:45, "Konrad Rzeszutek Wilk" <konrad.wilk@oracle.com> wro= te: >=20 > >> I guess it depends on whether you consider that we should stay in line > >> with Linux or not. While the code did start in Linux, it has diverged > > > > Stay. Intel does a lot of work of "lift from Linux" and drop in Xen > > code. There is similarity. >=20 > You might also say it gives a false sense of similarity. Andrew's now hav= ing > to go fix the per-cpu vector stuff for example. It got dropped in; it was > complex and opaque; it doesn't really work properly yet. I'd prefer the > people doing the porting to have to think about each line a bit more. You also don't want the people doing the porting thinking about each line so hard that they decide to rewrite all of them to meet their own personal preference. Remember that the number of people familiar with "code X" on Linux probably outnumbers the number of people familiar with code X on Xen by a factor of 10-100. The point of stealing the Linux code to begin with is to leverage developer knowledge and (historical) maintenance knowledge. A suggested compromise: Any divergence of this sort from Linux should be explicitly noted in a comment, e.g. "Linux calls this foo, but Xen calls it bar, though they otherwise should function very similarly". IMHO, Dan _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel From xen-devel-bounces@lists.xensource.com Mon Sep 26 10:20:21 2011 Return-path: <xen-devel-bounces@lists.xensource.com> Envelope-to: www-data@lists.xensource.com Delivery-date: Mon, 26 Sep 2011 10:20:21 -0700 Received: from localhost ([127.0.0.1] helo=lists.colo.xensource.com) by lists.xensource.com with esmtp (Exim 4.43) id 1R8Eqr-0001ZN-4h; Mon, 26 Sep 2011 10:20:21 -0700 Received: from mail174.messagelabs.com ([85.158.138.51]) by lists.xensource.com with esmtp (Exim 4.43) id 1R8Eq7-0001N7-2b for xen-devel@lists.xensource.com; Mon, 26 Sep 2011 10:19:39 -0700 X-Env-Sender: konrad@oracle.com X-Msg-Ref: server-15.tower-174.messagelabs.com!1317057570!26476778!1 X-Originating-IP: [141.146.126.227] X-StarScan-Version: 6.4.1; banners=-,-,- X-VirusChecked: Checked Received: (qmail 26259 invoked from network); 26 Sep 2011 17:19:31 -0000 Received: from acsinet15.oracle.com (HELO acsinet15.oracle.com) (141.146.126.227) by server-15.tower-174.messagelabs.com with DHE-RSA-AES256-SHA encrypted SMTP; 26 Sep 2011 17:19:31 -0000 Received: from rtcsinet22.oracle.com (rtcsinet22.oracle.com [66.248.204.30]) by acsinet15.oracle.com (Switch-3.4.4/Switch-3.4.4) with ESMTP id p8QHIora016843 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Mon, 26 Sep 2011 17:18:52 GMT Received: from acsmt358.oracle.com (acsmt358.oracle.com [141.146.40.158]) by rtcsinet22.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id p8QHIm61029604 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 26 Sep 2011 17:18:49 GMT Received: from abhmt116.oracle.com (abhmt116.oracle.com [141.146.116.68]) by acsmt358.oracle.com (8.12.11.20060308/8.12.11) with ESMTP id p8QHIgFL023460; Mon, 26 Sep 2011 12:18:42 -0500 Received: from oracle.com (/209.6.55.207) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Mon, 26 Sep 2011 10:18:42 -0700 Received: by oracle.com (Postfix, from userid 1000) id C7D231551; Mon, 26 Sep 2011 13:18:34 -0400 (EDT) Date: Mon, 26 Sep 2011 13:18:34 -0400 From: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com> To: Randy Dunlap <rdunlap@xenotime.net> Subject: Re: [Xen-devel] Re: linux-next: Tree for Sept 26 (xen) Message-ID: <20110926171834.GA30114@phenom.oracle.com> References: <20110926172348.be01ff9a1c16267ffd000d2a@canb.auug.org.au> <4E80ADDA.8090105@xenotime.net> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <4E80ADDA.8090105@xenotime.net> User-Agent: Mutt/1.5.21 (2010-09-15) X-Source-IP: rtcsinet22.oracle.com [66.248.204.30] X-CT-RefId: str=0001.0A090203.4E80B3FD.00A6,ss=1,re=-6.500,fgs=0 Cc: Stephen Rothwell <sfr@canb.auug.org.au>, "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>, LKML <linux-kernel@vger.kernel.org>, Jeremy Fitzhardinge <jeremy.fitzhardinge@citrix.com>, Linux Virtualization <virtualization@lists.linux-foundation.org>, linux-next@vger.kernel.org X-BeenThere: xen-devel@lists.xensource.com X-Mailman-Version: 2.1.5 Precedence: list List-Id: Xen developer discussion <xen-devel.lists.xensource.com> List-Unsubscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe> List-Post: <mailto:xen-devel@lists.xensource.com> List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help> List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=subscribe> Sender: xen-devel-bounces@lists.xensource.com Errors-To: xen-devel-bounces@lists.xensource.com On Mon, Sep 26, 2011 at 09:52:42AM -0700, Randy Dunlap wrote: > On 09/26/2011 12:23 AM, Stephen Rothwell wrote: > > Hi all, > > > x86_64 build sometimes fails with: > > drivers/xen/xenbus/xenbus_xs.c:909:2: error: implicit declaration of function 'xen_hvm_domain' Ok, got a patch queued up. Thought I am not entirely sure what made your .config trigger this. CONFIG_XEN_PVHVM is set.. > > One failing randconfig file is attached. > > -- > ~Randy > *** Remember to use Documentation/SubmitChecklist when testing your code *** > # > # Automatically generated file; DO NOT EDIT. > # Linux/x86_64 3.1.0-rc7 Kernel Configuration > # > CONFIG_64BIT=y > # CONFIG_X86_32 is not set > CONFIG_X86_64=y > CONFIG_X86=y > CONFIG_INSTRUCTION_DECODER=y > CONFIG_OUTPUT_FORMAT="elf64-x86-64" > CONFIG_ARCH_DEFCONFIG="arch/x86/configs/x86_64_defconfig" > CONFIG_GENERIC_CMOS_UPDATE=y > CONFIG_CLOCKSOURCE_WATCHDOG=y > CONFIG_GENERIC_CLOCKEVENTS=y > CONFIG_ARCH_CLOCKSOURCE_DATA=y > CONFIG_GENERIC_CLOCKEVENTS_BROADCAST=y > CONFIG_LOCKDEP_SUPPORT=y > CONFIG_STACKTRACE_SUPPORT=y > CONFIG_HAVE_LATENCYTOP_SUPPORT=y > CONFIG_MMU=y > # CONFIG_ZONE_DMA is not set > CONFIG_NEED_DMA_MAP_STATE=y > CONFIG_NEED_SG_DMA_LENGTH=y > # CONFIG_GENERIC_ISA_DMA is not set > CONFIG_GENERIC_IOMAP=y > CONFIG_GENERIC_BUG=y > CONFIG_GENERIC_BUG_RELATIVE_POINTERS=y > CONFIG_GENERIC_HWEIGHT=y > CONFIG_GENERIC_GPIO=y > # CONFIG_ARCH_MAY_HAVE_PC_FDC is not set > # CONFIG_RWSEM_GENERIC_SPINLOCK is not set > CONFIG_RWSEM_XCHGADD_ALGORITHM=y > CONFIG_ARCH_HAS_CPU_IDLE_WAIT=y > CONFIG_GENERIC_CALIBRATE_DELAY=y > CONFIG_GENERIC_TIME_VSYSCALL=y > CONFIG_ARCH_HAS_CPU_RELAX=y > CONFIG_ARCH_HAS_DEFAULT_IDLE=y > CONFIG_ARCH_HAS_CACHE_LINE_SIZE=y > CONFIG_HAVE_SETUP_PER_CPU_AREA=y > CONFIG_NEED_PER_CPU_EMBED_FIRST_CHUNK=y > CONFIG_NEED_PER_CPU_PAGE_FIRST_CHUNK=y > # CONFIG_HAVE_CPUMASK_OF_CPU_MAP is not set > CONFIG_ARCH_HIBERNATION_POSSIBLE=y > CONFIG_ARCH_SUSPEND_POSSIBLE=y > CONFIG_ZONE_DMA32=y > CONFIG_ARCH_POPULATES_NODE_MAP=y > CONFIG_AUDIT_ARCH=y > CONFIG_ARCH_SUPPORTS_OPTIMIZED_INLINING=y > CONFIG_ARCH_SUPPORTS_DEBUG_PAGEALLOC=y > CONFIG_ARCH_HWEIGHT_CFLAGS="-fcall-saved-rdi -fcall-saved-rsi -fcall-saved-rdx -fcall-saved-rcx -fcall-saved-r8 -fcall-saved-r9 -fcall-saved-r10 -fcall-saved-r11" > # CONFIG_KTIME_SCALAR is not set > CONFIG_DEFCONFIG_LIST="/lib/modules/$UNAME_RELEASE/.config" > CONFIG_HAVE_IRQ_WORK=y > CONFIG_IRQ_WORK=y > > # > # General setup > # > # CONFIG_EXPERIMENTAL is not set > CONFIG_BROKEN_ON_SMP=y > CONFIG_INIT_ENV_ARG_LIMIT=32 > CONFIG_CROSS_COMPILE="" > CONFIG_LOCALVERSION="" > # CONFIG_LOCALVERSION_AUTO is not set > CONFIG_HAVE_KERNEL_GZIP=y > CONFIG_HAVE_KERNEL_BZIP2=y > CONFIG_HAVE_KERNEL_LZMA=y > CONFIG_HAVE_KERNEL_XZ=y > CONFIG_HAVE_KERNEL_LZO=y > # CONFIG_KERNEL_GZIP is not set > # CONFIG_KERNEL_BZIP2 is not set > CONFIG_KERNEL_LZMA=y > # CONFIG_KERNEL_XZ is not set > # CONFIG_KERNEL_LZO is not set > CONFIG_DEFAULT_HOSTNAME="(none)" > # CONFIG_SWAP is not set > CONFIG_SYSVIPC=y > # CONFIG_BSD_PROCESS_ACCT is not set > # CONFIG_FHANDLE is not set > CONFIG_TASKSTATS=y > CONFIG_TASK_DELAY_ACCT=y > CONFIG_TASK_XACCT=y > # CONFIG_TASK_IO_ACCOUNTING is not set > CONFIG_AUDIT=y > # CONFIG_AUDITSYSCALL is not set > CONFIG_HAVE_GENERIC_HARDIRQS=y > > # > # IRQ subsystem > # > CONFIG_GENERIC_HARDIRQS=y > CONFIG_HAVE_SPARSE_IRQ=y > CONFIG_GENERIC_IRQ_PROBE=y > CONFIG_GENERIC_IRQ_SHOW=y > CONFIG_IRQ_FORCED_THREADING=y > CONFIG_SPARSE_IRQ=y > > # > # RCU Subsystem > # > CONFIG_TINY_RCU=y > # CONFIG_PREEMPT_RCU is not set > CONFIG_RCU_TRACE=y > # CONFIG_TREE_RCU_TRACE is not set > CONFIG_IKCONFIG=y > CONFIG_IKCONFIG_PROC=y > CONFIG_LOG_BUF_SHIFT=17 > CONFIG_HAVE_UNSTABLE_SCHED_CLOCK=y > CONFIG_CGROUPS=y > # CONFIG_CGROUP_DEBUG is not set > CONFIG_CGROUP_FREEZER=y > # CONFIG_CGROUP_DEVICE is not set > CONFIG_CPUSETS=y > CONFIG_PROC_PID_CPUSET=y > # CONFIG_CGROUP_CPUACCT is not set > CONFIG_RESOURCE_COUNTERS=y > # CONFIG_CGROUP_MEM_RES_CTLR is not set > # CONFIG_CGROUP_PERF is not set > CONFIG_CGROUP_SCHED=y > CONFIG_FAIR_GROUP_SCHED=y > # CONFIG_BLK_CGROUP is not set > # CONFIG_NAMESPACES is not set > CONFIG_SCHED_AUTOGROUP=y > # CONFIG_SYSFS_DEPRECATED is not set > CONFIG_RELAY=y > CONFIG_BLK_DEV_INITRD=y > CONFIG_INITRAMFS_SOURCE="" > CONFIG_RD_GZIP=y > # CONFIG_RD_BZIP2 is not set > # CONFIG_RD_LZMA is not set > # CONFIG_RD_XZ is not set > CONFIG_RD_LZO=y > # CONFIG_CC_OPTIMIZE_FOR_SIZE is not set > CONFIG_ANON_INODES=y > CONFIG_EXPERT=y > # CONFIG_UID16 is not set > CONFIG_KALLSYMS=y > CONFIG_KALLSYMS_ALL=y > # CONFIG_HOTPLUG is not set > # CONFIG_PRINTK is not set > CONFIG_BUG=y > # CONFIG_ELF_CORE is not set > CONFIG_PCSPKR_PLATFORM=y > CONFIG_HAVE_PCSPKR_PLATFORM=y > CONFIG_BASE_FULL=y > # CONFIG_FUTEX is not set > # CONFIG_EPOLL is not set > # CONFIG_SIGNALFD is not set > # CONFIG_TIMERFD is not set > CONFIG_EVENTFD=y > CONFIG_SHMEM=y > CONFIG_AIO=y > CONFIG_EMBEDDED=y > CONFIG_HAVE_PERF_EVENTS=y > CONFIG_PERF_USE_VMALLOC=y > > # > # Kernel Performance Events And Counters > # > CONFIG_PERF_EVENTS=y > # CONFIG_PERF_COUNTERS is not set > CONFIG_DEBUG_PERF_USE_VMALLOC=y > # CONFIG_VM_EVENT_COUNTERS is not set > CONFIG_PCI_QUIRKS=y > CONFIG_SLUB_DEBUG=y > # CONFIG_COMPAT_BRK is not set > # CONFIG_SLAB is not set > CONFIG_SLUB=y > # CONFIG_SLOB is not set > # CONFIG_PROFILING is not set > CONFIG_TRACEPOINTS=y > CONFIG_HAVE_OPROFILE=y > CONFIG_JUMP_LABEL=y > CONFIG_HAVE_EFFICIENT_UNALIGNED_ACCESS=y > CONFIG_HAVE_IOREMAP_PROT=y > CONFIG_HAVE_KPROBES=y > CONFIG_HAVE_KRETPROBES=y > CONFIG_HAVE_OPTPROBES=y > CONFIG_HAVE_ARCH_TRACEHOOK=y > CONFIG_HAVE_DMA_ATTRS=y > CONFIG_HAVE_REGS_AND_STACK_ACCESS_API=y > CONFIG_HAVE_DMA_API_DEBUG=y > CONFIG_HAVE_HW_BREAKPOINT=y > CONFIG_HAVE_MIXED_BREAKPOINTS_REGS=y > CONFIG_HAVE_USER_RETURN_NOTIFIER=y > CONFIG_HAVE_PERF_EVENTS_NMI=y > CONFIG_HAVE_ARCH_JUMP_LABEL=y > CONFIG_ARCH_HAVE_NMI_SAFE_CMPXCHG=y > > # > # GCOV-based kernel profiling > # > # CONFIG_GCOV_KERNEL is not set > # CONFIG_HAVE_GENERIC_DMA_COHERENT is not set > CONFIG_SLABINFO=y > CONFIG_RT_MUTEXES=y > CONFIG_BASE_SMALL=0 > # CONFIG_MODULES is not set > CONFIG_BLOCK=y > CONFIG_BLK_DEV_BSG=y > CONFIG_BLK_DEV_BSGLIB=y > CONFIG_BLK_DEV_INTEGRITY=y > CONFIG_BLOCK_COMPAT=y > > # > # IO Schedulers > # > CONFIG_IOSCHED_NOOP=y > CONFIG_IOSCHED_DEADLINE=y > # CONFIG_IOSCHED_CFQ is not set > CONFIG_DEFAULT_DEADLINE=y > # CONFIG_DEFAULT_NOOP is not set > CONFIG_DEFAULT_IOSCHED="deadline" > # CONFIG_INLINE_SPIN_TRYLOCK is not set > # CONFIG_INLINE_SPIN_TRYLOCK_BH is not set > # CONFIG_INLINE_SPIN_LOCK is not set > # CONFIG_INLINE_SPIN_LOCK_BH is not set > # CONFIG_INLINE_SPIN_LOCK_IRQ is not set > # CONFIG_INLINE_SPIN_LOCK_IRQSAVE is not set > CONFIG_INLINE_SPIN_UNLOCK=y > # CONFIG_INLINE_SPIN_UNLOCK_BH is not set > CONFIG_INLINE_SPIN_UNLOCK_IRQ=y > # CONFIG_INLINE_SPIN_UNLOCK_IRQRESTORE is not set > # CONFIG_INLINE_READ_TRYLOCK is not set > # CONFIG_INLINE_READ_LOCK is not set > # CONFIG_INLINE_READ_LOCK_BH is not set > # CONFIG_INLINE_READ_LOCK_IRQ is not set > # CONFIG_INLINE_READ_LOCK_IRQSAVE is not set > CONFIG_INLINE_READ_UNLOCK=y > # CONFIG_INLINE_READ_UNLOCK_BH is not set > CONFIG_INLINE_READ_UNLOCK_IRQ=y > # CONFIG_INLINE_READ_UNLOCK_IRQRESTORE is not set > # CONFIG_INLINE_WRITE_TRYLOCK is not set > # CONFIG_INLINE_WRITE_LOCK is not set > # CONFIG_INLINE_WRITE_LOCK_BH is not set > # CONFIG_INLINE_WRITE_LOCK_IRQ is not set > # CONFIG_INLINE_WRITE_LOCK_IRQSAVE is not set > CONFIG_INLINE_WRITE_UNLOCK=y > # CONFIG_INLINE_WRITE_UNLOCK_BH is not set > CONFIG_INLINE_WRITE_UNLOCK_IRQ=y > # CONFIG_INLINE_WRITE_UNLOCK_IRQRESTORE is not set > # CONFIG_MUTEX_SPIN_ON_OWNER is not set > CONFIG_FREEZER=y > > # > # Processor type and features > # > CONFIG_TICK_ONESHOT=y > CONFIG_NO_HZ=y > # CONFIG_HIGH_RES_TIMERS is not set > CONFIG_GENERIC_CLOCKEVENTS_BUILD=y > CONFIG_GENERIC_CLOCKEVENTS_MIN_ADJUST=y > # CONFIG_SMP is not set > # CONFIG_X86_MPPARSE is not set > # CONFIG_X86_EXTENDED_PLATFORM is not set > CONFIG_X86_SUPPORTS_MEMORY_FAILURE=y > # CONFIG_SCHED_OMIT_FRAME_POINTER is not set > CONFIG_PARAVIRT_GUEST=y > # CONFIG_PARAVIRT_TIME_ACCOUNTING is not set > CONFIG_XEN=y > CONFIG_XEN_DOM0=y > CONFIG_XEN_PRIVILEGED_GUEST=y > CONFIG_XEN_PVHVM=y > CONFIG_XEN_MAX_DOMAIN_MEMORY=128 > CONFIG_XEN_SAVE_RESTORE=y > CONFIG_XEN_DEBUG_FS=y > CONFIG_MICROCODE_XEN=y > CONFIG_KVM_CLOCK=y > CONFIG_KVM_GUEST=y > CONFIG_PARAVIRT=y > CONFIG_PARAVIRT_CLOCK=y > # CONFIG_PARAVIRT_DEBUG is not set > CONFIG_NO_BOOTMEM=y > # CONFIG_MEMTEST is not set > # CONFIG_MK8 is not set > # CONFIG_MPSC is not set > # CONFIG_MCORE2 is not set > # CONFIG_MATOM is not set > CONFIG_GENERIC_CPU=y > CONFIG_X86_INTERNODE_CACHE_SHIFT=6 > CONFIG_X86_CMPXCHG=y > CONFIG_CMPXCHG_LOCAL=y > CONFIG_CMPXCHG_DOUBLE=y > CONFIG_X86_L1_CACHE_SHIFT=6 > CONFIG_X86_XADD=y > CONFIG_X86_WP_WORKS_OK=y > CONFIG_X86_TSC=y > CONFIG_X86_CMPXCHG64=y > CONFIG_X86_CMOV=y > CONFIG_X86_MINIMUM_CPU_FAMILY=64 > CONFIG_X86_DEBUGCTLMSR=y > CONFIG_PROCESSOR_SELECT=y > # CONFIG_CPU_SUP_INTEL is not set > CONFIG_CPU_SUP_AMD=y > # CONFIG_CPU_SUP_CENTAUR is not set > CONFIG_HPET_TIMER=y > CONFIG_HPET_EMULATE_RTC=y > # CONFIG_DMI is not set > CONFIG_GART_IOMMU=y > CONFIG_SWIOTLB=y > CONFIG_IOMMU_HELPER=y > CONFIG_NR_CPUS=1 > # CONFIG_IRQ_TIME_ACCOUNTING is not set > CONFIG_PREEMPT_NONE=y > # CONFIG_PREEMPT_VOLUNTARY is not set > # CONFIG_PREEMPT is not set > CONFIG_X86_LOCAL_APIC=y > CONFIG_X86_IO_APIC=y > CONFIG_X86_REROUTE_FOR_BROKEN_BOOT_IRQS=y > CONFIG_X86_MCE=y > # CONFIG_X86_MCE_INTEL is not set > CONFIG_X86_MCE_AMD=y > CONFIG_X86_MCE_THRESHOLD=y > CONFIG_X86_MCE_INJECT=y > # CONFIG_I8K is not set > CONFIG_MICROCODE=y > # CONFIG_MICROCODE_INTEL is not set > # CONFIG_MICROCODE_AMD is not set > CONFIG_MICROCODE_OLD_INTERFACE=y > # CONFIG_X86_MSR is not set > # CONFIG_X86_CPUID is not set > CONFIG_ARCH_PHYS_ADDR_T_64BIT=y > CONFIG_ARCH_DMA_ADDR_T_64BIT=y > CONFIG_DIRECT_GBPAGES=y > CONFIG_ARCH_SPARSEMEM_ENABLE=y > CONFIG_ARCH_SPARSEMEM_DEFAULT=y > CONFIG_ARCH_SELECT_MEMORY_MODEL=y > CONFIG_ARCH_PROC_KCORE_TEXT=y > CONFIG_ILLEGAL_POINTER_VALUE=0xdead000000000000 > CONFIG_SELECT_MEMORY_MODEL=y > CONFIG_SPARSEMEM_MANUAL=y > CONFIG_SPARSEMEM=y > CONFIG_HAVE_MEMORY_PRESENT=y > CONFIG_SPARSEMEM_EXTREME=y > CONFIG_SPARSEMEM_VMEMMAP_ENABLE=y > CONFIG_SPARSEMEM_ALLOC_MEM_MAP_TOGETHER=y > CONFIG_SPARSEMEM_VMEMMAP=y > CONFIG_HAVE_MEMBLOCK=y > CONFIG_PAGEFLAGS_EXTENDED=y > CONFIG_SPLIT_PTLOCK_CPUS=4 > CONFIG_COMPACTION=y > CONFIG_MIGRATION=y > CONFIG_PHYS_ADDR_T_64BIT=y > CONFIG_ZONE_DMA_FLAG=0 > CONFIG_VIRT_TO_BUS=y > CONFIG_KSM=y > CONFIG_DEFAULT_MMAP_MIN_ADDR=4096 > CONFIG_ARCH_SUPPORTS_MEMORY_FAILURE=y > CONFIG_MEMORY_FAILURE=y > # CONFIG_HWPOISON_INJECT is not set > CONFIG_TRANSPARENT_HUGEPAGE=y > CONFIG_TRANSPARENT_HUGEPAGE_ALWAYS=y > # CONFIG_TRANSPARENT_HUGEPAGE_MADVISE is not set > CONFIG_NEED_PER_CPU_KM=y > # CONFIG_CLEANCACHE is not set > # CONFIG_X86_CHECK_BIOS_CORRUPTION is not set > CONFIG_X86_RESERVE_LOW=64 > CONFIG_MTRR=y > CONFIG_MTRR_SANITIZER=y > CONFIG_MTRR_SANITIZER_ENABLE_DEFAULT=0 > CONFIG_MTRR_SANITIZER_SPARE_REG_NR_DEFAULT=1 > # CONFIG_X86_PAT is not set > # CONFIG_ARCH_RANDOM is not set > CONFIG_EFI=y > CONFIG_SECCOMP=y > CONFIG_CC_STACKPROTECTOR=y > CONFIG_HZ_100=y > # CONFIG_HZ_250 is not set > # CONFIG_HZ_300 is not set > # CONFIG_HZ_1000 is not set > CONFIG_HZ=100 > # CONFIG_SCHED_HRTICK is not set > CONFIG_KEXEC=y > CONFIG_CRASH_DUMP=y > CONFIG_PHYSICAL_START=0x1000000 > CONFIG_RELOCATABLE=y > CONFIG_PHYSICAL_ALIGN=0x1000000 > CONFIG_COMPAT_VDSO=y > # CONFIG_CMDLINE_BOOL is not set > CONFIG_ARCH_ENABLE_MEMORY_HOTPLUG=y > > # > # Power management and ACPI options > # > # CONFIG_SUSPEND is not set > CONFIG_HIBERNATE_CALLBACKS=y > CONFIG_PM_SLEEP=y > CONFIG_PM_RUNTIME=y > CONFIG_PM=y > # CONFIG_PM_DEBUG is not set > CONFIG_ACPI=y > CONFIG_ACPI_PROCFS=y > CONFIG_ACPI_PROCFS_POWER=y > CONFIG_ACPI_EC_DEBUGFS=y > # CONFIG_ACPI_PROC_EVENT is not set > # CONFIG_ACPI_AC is not set > CONFIG_ACPI_BATTERY=y > CONFIG_ACPI_BUTTON=y > CONFIG_ACPI_VIDEO=y > CONFIG_ACPI_FAN=y > # CONFIG_ACPI_PROCESSOR is not set > # CONFIG_ACPI_CUSTOM_DSDT is not set > CONFIG_ACPI_BLACKLIST_YEAR=0 > # CONFIG_ACPI_DEBUG is not set > # CONFIG_ACPI_PCI_SLOT is not set > CONFIG_X86_PM_TIMER=y > # CONFIG_ACPI_SBS is not set > CONFIG_ACPI_HED=y > CONFIG_ACPI_CUSTOM_METHOD=y > # CONFIG_ACPI_APEI is not set > CONFIG_SFI=y > > # > # CPU Frequency scaling > # > CONFIG_CPU_FREQ=y > CONFIG_CPU_FREQ_TABLE=y > CONFIG_CPU_FREQ_STAT=y > # CONFIG_CPU_FREQ_STAT_DETAILS is not set > # CONFIG_CPU_FREQ_DEFAULT_GOV_PERFORMANCE is not set > # CONFIG_CPU_FREQ_DEFAULT_GOV_POWERSAVE is not set > # CONFIG_CPU_FREQ_DEFAULT_GOV_USERSPACE is not set > # CONFIG_CPU_FREQ_DEFAULT_GOV_ONDEMAND is not set > CONFIG_CPU_FREQ_DEFAULT_GOV_CONSERVATIVE=y > CONFIG_CPU_FREQ_GOV_PERFORMANCE=y > CONFIG_CPU_FREQ_GOV_POWERSAVE=y > CONFIG_CPU_FREQ_GOV_USERSPACE=y > CONFIG_CPU_FREQ_GOV_ONDEMAND=y > CONFIG_CPU_FREQ_GOV_CONSERVATIVE=y > > # > # x86 CPU frequency scaling drivers > # > CONFIG_X86_P4_CLOCKMOD=y > > # > # shared options > # > CONFIG_X86_SPEEDSTEP_LIB=y > # CONFIG_CPU_IDLE is not set > > # > # Memory power savings > # > > # > # Bus options (PCI etc.) > # > CONFIG_PCI=y > CONFIG_PCI_DIRECT=y > CONFIG_PCI_MMCONFIG=y > CONFIG_PCI_XEN=y > CONFIG_PCI_DOMAINS=y > # CONFIG_PCIEPORTBUS is not set > CONFIG_ARCH_SUPPORTS_MSI=y > CONFIG_PCI_MSI=y > CONFIG_PCI_DEBUG=y > CONFIG_PCI_STUB=y > # CONFIG_XEN_PCIDEV_FRONTEND is not set > CONFIG_HT_IRQ=y > CONFIG_PCI_IOV=y > CONFIG_PCI_LABEL=y > # CONFIG_ISA_DMA_API is not set > CONFIG_AMD_NB=y > # CONFIG_RAPIDIO is not set > > # > # Executable file formats / Emulations > # > # CONFIG_BINFMT_ELF is not set > CONFIG_COMPAT_BINFMT_ELF=y > # CONFIG_HAVE_AOUT is not set > CONFIG_BINFMT_MISC=y > CONFIG_IA32_EMULATION=y > CONFIG_IA32_AOUT=y > CONFIG_COMPAT=y > CONFIG_COMPAT_FOR_U64_ALIGNMENT=y > CONFIG_SYSVIPC_COMPAT=y > CONFIG_KEYS_COMPAT=y > CONFIG_HAVE_TEXT_POKE_SMP=y > CONFIG_NET=y > CONFIG_COMPAT_NETLINK_MESSAGES=y > > # > # Networking options > # > # CONFIG_PACKET is not set > CONFIG_UNIX=y > CONFIG_XFRM=y > CONFIG_NET_KEY=y > # CONFIG_INET is not set > CONFIG_NETWORK_SECMARK=y > CONFIG_NETFILTER=y > CONFIG_NETFILTER_DEBUG=y > CONFIG_NETFILTER_ADVANCED=y > # CONFIG_BRIDGE_NF_EBTABLES is not set > # CONFIG_ATM is not set > CONFIG_STP=y > CONFIG_BRIDGE=y > # CONFIG_VLAN_8021Q is not set > CONFIG_DECNET=y > CONFIG_LLC=y > # CONFIG_LLC2 is not set > # CONFIG_IPX is not set > CONFIG_ATALK=y > # CONFIG_DEV_APPLETALK is not set > # CONFIG_PHONET is not set > CONFIG_NET_SCHED=y > > # > # Queueing/Scheduling > # > CONFIG_NET_SCH_CBQ=y > CONFIG_NET_SCH_HTB=y > # CONFIG_NET_SCH_HFSC is not set > # CONFIG_NET_SCH_PRIO is not set > CONFIG_NET_SCH_MULTIQ=y > CONFIG_NET_SCH_RED=y > CONFIG_NET_SCH_SFB=y > CONFIG_NET_SCH_SFQ=y > # CONFIG_NET_SCH_TEQL is not set > # CONFIG_NET_SCH_TBF is not set > CONFIG_NET_SCH_GRED=y > CONFIG_NET_SCH_DSMARK=y > # CONFIG_NET_SCH_NETEM is not set > CONFIG_NET_SCH_DRR=y > CONFIG_NET_SCH_MQPRIO=y > # CONFIG_NET_SCH_CHOKE is not set > CONFIG_NET_SCH_QFQ=y > # CONFIG_NET_SCH_INGRESS is not set > > # > # Classification > # > CONFIG_NET_CLS=y > # CONFIG_NET_CLS_BASIC is not set > CONFIG_NET_CLS_TCINDEX=y > # CONFIG_NET_CLS_FW is not set > CONFIG_NET_CLS_U32=y > CONFIG_CLS_U32_PERF=y > # CONFIG_CLS_U32_MARK is not set > # CONFIG_NET_CLS_RSVP is not set > # CONFIG_NET_CLS_RSVP6 is not set > # CONFIG_NET_CLS_FLOW is not set > CONFIG_NET_CLS_CGROUP=y > # CONFIG_NET_EMATCH is not set > CONFIG_NET_CLS_ACT=y > CONFIG_NET_ACT_POLICE=y > CONFIG_NET_ACT_GACT=y > # CONFIG_GACT_PROB is not set > # CONFIG_NET_ACT_MIRRED is not set > CONFIG_NET_ACT_NAT=y > CONFIG_NET_ACT_PEDIT=y > # CONFIG_NET_ACT_SIMP is not set > # CONFIG_NET_ACT_SKBEDIT is not set > CONFIG_NET_CLS_IND=y > CONFIG_NET_SCH_FIFO=y > # CONFIG_DCB is not set > CONFIG_DNS_RESOLVER=y > CONFIG_BATMAN_ADV=y > # CONFIG_BATMAN_ADV_DEBUG is not set > CONFIG_HAVE_BPF_JIT=y > > # > # Network testing > # > # CONFIG_NET_PKTGEN is not set > # CONFIG_HAMRADIO is not set > CONFIG_CAN=y > # CONFIG_CAN_RAW is not set > # CONFIG_CAN_BCM is not set > CONFIG_CAN_GW=y > > # > # CAN Device Drivers > # > # CONFIG_CAN_VCAN is not set > CONFIG_CAN_SLCAN=y > # CONFIG_CAN_DEV is not set > CONFIG_CAN_DEBUG_DEVICES=y > CONFIG_IRDA=y > > # > # IrDA protocols > # > # CONFIG_IRLAN is not set > # CONFIG_IRCOMM is not set > # CONFIG_IRDA_ULTRA is not set > > # > # IrDA options > # > CONFIG_IRDA_CACHE_LAST_LSAP=y > CONFIG_IRDA_FAST_RR=y > # CONFIG_IRDA_DEBUG is not set > > # > # Infrared-port device drivers > # > > # > # SIR device drivers > # > # CONFIG_IRTTY_SIR is not set > > # > # Dongle support > # > > # > # FIR device drivers > # > CONFIG_BT=y > # CONFIG_BT_L2CAP is not set > # CONFIG_BT_SCO is not set > > # > # Bluetooth device drivers > # > # CONFIG_BT_HCIUART is not set > # CONFIG_BT_HCIVHCI is not set > # CONFIG_BT_MRVL is not set > CONFIG_BT_WILINK=y > CONFIG_WIRELESS=y > CONFIG_WIRELESS_EXT=y > CONFIG_WEXT_CORE=y > CONFIG_WEXT_PROC=y > CONFIG_WEXT_PRIV=y > # CONFIG_CFG80211 is not set > # CONFIG_WIRELESS_EXT_SYSFS is not set > # CONFIG_LIB80211 is not set > > # > # CFG80211 needs to be enabled for MAC80211 > # > # CONFIG_WIMAX is not set > CONFIG_RFKILL=y > CONFIG_RFKILL_LEDS=y > # CONFIG_RFKILL_INPUT is not set > # CONFIG_RFKILL_REGULATOR is not set > # CONFIG_NET_9P is not set > # CONFIG_CAIF is not set > > # > # Device Drivers > # > > # > # Generic Driver Options > # > CONFIG_STANDALONE=y > CONFIG_PREVENT_FIRMWARE_BUILD=y > CONFIG_FW_LOADER=y > CONFIG_FIRMWARE_IN_KERNEL=y > CONFIG_EXTRA_FIRMWARE="" > CONFIG_DEBUG_DRIVER=y > CONFIG_DEBUG_DEVRES=y > # CONFIG_SYS_HYPERVISOR is not set > CONFIG_REGMAP=y > CONFIG_REGMAP_I2C=y > CONFIG_CONNECTOR=y > CONFIG_PROC_EVENTS=y > # CONFIG_MTD is not set > # CONFIG_PARPORT is not set > CONFIG_PNP=y > CONFIG_PNP_DEBUG_MESSAGES=y > > # > # Protocols > # > CONFIG_PNPACPI=y > CONFIG_BLK_DEV=y > # CONFIG_BLK_CPQ_DA is not set > # CONFIG_BLK_CPQ_CISS_DA is not set > # CONFIG_BLK_DEV_DAC960 is not set > # CONFIG_BLK_DEV_COW_COMMON is not set > CONFIG_BLK_DEV_LOOP=y > CONFIG_BLK_DEV_LOOP_MIN_COUNT=8 > # CONFIG_BLK_DEV_CRYPTOLOOP is not set > > # > # DRBD disabled because PROC_FS, INET or CONNECTOR not selected > # > CONFIG_BLK_DEV_NBD=y > # CONFIG_BLK_DEV_SX8 is not set > # CONFIG_BLK_DEV_RAM is not set > # CONFIG_CDROM_PKTCDVD is not set > # CONFIG_ATA_OVER_ETH is not set > CONFIG_XEN_BLKDEV_FRONTEND=y > CONFIG_BLK_DEV_HD=y > CONFIG_SENSORS_LIS3LV02D=y > CONFIG_MISC_DEVICES=y > CONFIG_AD525X_DPOT=y > CONFIG_AD525X_DPOT_I2C=y > CONFIG_PHANTOM=y > # CONFIG_INTEL_MID_PTI is not set > # CONFIG_SGI_IOC4 is not set > CONFIG_ENCLOSURE_SERVICES=y > CONFIG_HP_ILO=y > # CONFIG_APDS9802ALS is not set > CONFIG_ISL29003=y > # CONFIG_ISL29020 is not set > CONFIG_SENSORS_TSL2550=y > # CONFIG_SENSORS_BH1780 is not set > CONFIG_SENSORS_BH1770=y > # CONFIG_SENSORS_APDS990X is not set > # CONFIG_HMC6352 is not set > # CONFIG_VMWARE_BALLOON is not set > CONFIG_BMP085=y > CONFIG_PCH_PHUB=y > CONFIG_USB_SWITCH_FSA9480=y > > # > # EEPROM support > # > # CONFIG_EEPROM_AT24 is not set > CONFIG_EEPROM_LEGACY=y > CONFIG_EEPROM_93CX6=y > CONFIG_CB710_CORE=y > CONFIG_CB710_DEBUG=y > CONFIG_CB710_DEBUG_ASSUMPTIONS=y > > # > # Texas Instruments shared transport line discipline > # > CONFIG_TI_ST=y > CONFIG_SENSORS_LIS3_I2C=y > CONFIG_HAVE_IDE=y > # CONFIG_IDE is not set > > # > # SCSI device support > # > CONFIG_SCSI_MOD=y > # CONFIG_RAID_ATTRS is not set > CONFIG_SCSI=y > CONFIG_SCSI_DMA=y > CONFIG_SCSI_TGT=y > CONFIG_SCSI_NETLINK=y > # CONFIG_SCSI_PROC_FS is not set > > # > # SCSI support type (disk, tape, CD-ROM) > # > # CONFIG_BLK_DEV_SD is not set > # CONFIG_CHR_DEV_ST is not set > # CONFIG_CHR_DEV_OSST is not set > # CONFIG_BLK_DEV_SR is not set > # CONFIG_CHR_DEV_SG is not set > # CONFIG_CHR_DEV_SCH is not set > # CONFIG_SCSI_ENCLOSURE is not set > CONFIG_SCSI_MULTI_LUN=y > # CONFIG_SCSI_CONSTANTS is not set > CONFIG_SCSI_LOGGING=y > # CONFIG_SCSI_SCAN_ASYNC is not set > > # > # SCSI Transports > # > CONFIG_SCSI_SPI_ATTRS=y > CONFIG_SCSI_FC_ATTRS=y > # CONFIG_SCSI_FC_TGT_ATTRS is not set > CONFIG_SCSI_ISCSI_ATTRS=y > CONFIG_SCSI_SAS_ATTRS=y > CONFIG_SCSI_SAS_LIBSAS=y > CONFIG_SCSI_SAS_HOST_SMP=y > # CONFIG_SCSI_SRP_ATTRS is not set > CONFIG_SCSI_LOWLEVEL=y > CONFIG_ISCSI_BOOT_SYSFS=y > CONFIG_SCSI_BNX2_ISCSI=y > CONFIG_SCSI_BNX2X_FCOE=y > # CONFIG_BE2ISCSI is not set > # CONFIG_BLK_DEV_3W_XXXX_RAID is not set > # CONFIG_SCSI_HPSA is not set > CONFIG_SCSI_3W_9XXX=y > CONFIG_SCSI_3W_SAS=y > CONFIG_SCSI_ACARD=y > # CONFIG_SCSI_AACRAID is not set > CONFIG_SCSI_AIC7XXX=y > CONFIG_AIC7XXX_CMDS_PER_DEVICE=32 > CONFIG_AIC7XXX_RESET_DELAY_MS=5000 > # CONFIG_AIC7XXX_DEBUG_ENABLE is not set > CONFIG_AIC7XXX_DEBUG_MASK=0 > # CONFIG_AIC7XXX_REG_PRETTY_PRINT is not set > CONFIG_SCSI_AIC7XXX_OLD=y > CONFIG_SCSI_AIC79XX=y > CONFIG_AIC79XX_CMDS_PER_DEVICE=32 > CONFIG_AIC79XX_RESET_DELAY_MS=5000 > # CONFIG_AIC79XX_DEBUG_ENABLE is not set > CONFIG_AIC79XX_DEBUG_MASK=0 > # CONFIG_AIC79XX_REG_PRETTY_PRINT is not set > CONFIG_SCSI_AIC94XX=y > CONFIG_AIC94XX_DEBUG=y > # CONFIG_SCSI_MVSAS is not set > CONFIG_SCSI_MVUMI=y > # CONFIG_SCSI_DPT_I2O is not set > # CONFIG_SCSI_ADVANSYS is not set > CONFIG_SCSI_ARCMSR=y > # CONFIG_MEGARAID_NEWGEN is not set > CONFIG_MEGARAID_LEGACY=y > # CONFIG_MEGARAID_SAS is not set > # CONFIG_SCSI_MPT2SAS is not set > CONFIG_SCSI_HPTIOP=y > CONFIG_VMWARE_PVSCSI=y > CONFIG_LIBFC=y > CONFIG_LIBFCOE=y > CONFIG_FCOE=y > # CONFIG_FCOE_FNIC is not set > # CONFIG_SCSI_DMX3191D is not set > CONFIG_SCSI_FUTURE_DOMAIN=y > CONFIG_SCSI_IPS=y > # CONFIG_SCSI_INITIO is not set > # CONFIG_SCSI_INIA100 is not set > CONFIG_SCSI_STEX=y > # CONFIG_SCSI_SYM53C8XX_2 is not set > # CONFIG_SCSI_QLOGIC_1280 is not set > # CONFIG_SCSI_QLA_FC is not set > CONFIG_SCSI_QLA_ISCSI=y > # CONFIG_SCSI_LPFC is not set > CONFIG_SCSI_DC390T=y > CONFIG_SCSI_DEBUG=y > CONFIG_SCSI_PMCRAID=y > CONFIG_SCSI_PM8001=y > CONFIG_SCSI_SRP=y > CONFIG_SCSI_BFA_FC=y > # CONFIG_SCSI_DH is not set > # CONFIG_SCSI_OSD_INITIATOR is not set > # CONFIG_ATA is not set > # CONFIG_MD is not set > CONFIG_TARGET_CORE=y > # CONFIG_TCM_IBLOCK is not set > # CONFIG_TCM_FILEIO is not set > # CONFIG_TCM_PSCSI is not set > # CONFIG_LOOPBACK_TARGET is not set > CONFIG_TCM_FC=y > CONFIG_ISCSI_TARGET=y > CONFIG_FUSION=y > CONFIG_FUSION_SPI=y > CONFIG_FUSION_FC=y > # CONFIG_FUSION_SAS is not set > CONFIG_FUSION_MAX_SGE=128 > # CONFIG_FUSION_CTL is not set > CONFIG_FUSION_LAN=y > CONFIG_FUSION_LOGGING=y > > # > # IEEE 1394 (FireWire) support > # > CONFIG_FIREWIRE=y > CONFIG_FIREWIRE_OHCI=y > CONFIG_FIREWIRE_OHCI_DEBUG=y > CONFIG_FIREWIRE_SBP2=y > CONFIG_FIREWIRE_NOSY=y > # CONFIG_I2O is not set > # CONFIG_MACINTOSH_DRIVERS is not set > CONFIG_NETDEVICES=y > CONFIG_NET_CORE=y > # CONFIG_DUMMY is not set > CONFIG_EQUALIZER=y > CONFIG_NET_FC=y > CONFIG_MII=y > CONFIG_IFB=y > # CONFIG_NETCONSOLE is not set > # CONFIG_NETPOLL is not set > # CONFIG_NET_POLL_CONTROLLER is not set > CONFIG_TUN=y > CONFIG_VETH=y > CONFIG_ARCNET=y > # CONFIG_ARCNET_1201 is not set > # CONFIG_ARCNET_1051 is not set > # CONFIG_ARCNET_RAW is not set > CONFIG_ARCNET_CAP=y > CONFIG_ARCNET_COM90xx=y > CONFIG_ARCNET_COM90xxIO=y > # CONFIG_ARCNET_RIM_I is not set > # CONFIG_ARCNET_COM20020 is not set > > # > # CAIF transport drivers > # > CONFIG_ETHERNET=y > CONFIG_MDIO=y > # CONFIG_NET_VENDOR_3COM is not set > # CONFIG_NET_VENDOR_ADAPTEC is not set > CONFIG_NET_VENDOR_ALTEON=y > # CONFIG_ACENIC is not set > CONFIG_NET_VENDOR_AMD=y > CONFIG_AMD8111_ETH=y > # CONFIG_PCNET32 is not set > CONFIG_NET_VENDOR_ATHEROS=y > CONFIG_ATL2=y > CONFIG_ATL1=y > CONFIG_NET_VENDOR_BROADCOM=y > # CONFIG_B44 is not set > CONFIG_BNX2=y > CONFIG_CNIC=y > # CONFIG_TIGON3 is not set > CONFIG_BNX2X=y > CONFIG_NET_VENDOR_BROCADE=y > # CONFIG_BNA is not set > CONFIG_NET_VENDOR_CHELSIO=y > # CONFIG_CHELSIO_T1 is not set > # CONFIG_CHELSIO_T4 is not set > # CONFIG_CHELSIO_T4VF is not set > CONFIG_DNET=y > CONFIG_NET_VENDOR_DEC=y > CONFIG_NET_TULIP=y > # CONFIG_DE2104X is not set > # CONFIG_TULIP is not set > # CONFIG_DE4X5 is not set > CONFIG_WINBOND_840=y > # CONFIG_DM9102 is not set > # CONFIG_ULI526X is not set > CONFIG_NET_VENDOR_DLINK=y > CONFIG_DL2K=y > # CONFIG_SUNDANCE is not set > # CONFIG_NET_VENDOR_EXAR is not set > # CONFIG_NET_VENDOR_HP is not set > CONFIG_NET_VENDOR_INTEL=y > CONFIG_E100=y > CONFIG_E1000=y > CONFIG_E1000E=y > # CONFIG_IGB is not set > CONFIG_IGBVF=y > CONFIG_IXGB=y > # CONFIG_IXGBEVF is not set > # CONFIG_JME is not set > CONFIG_NET_VENDOR_MARVELL=y > CONFIG_SKGE=y > # CONFIG_SKGE_DEBUG is not set > CONFIG_SKGE_GENESIS=y > CONFIG_SKY2=y > # CONFIG_SKY2_DEBUG is not set > CONFIG_NET_VENDOR_MICREL=y > CONFIG_KS8851_MLL=y > # CONFIG_KSZ884X_PCI is not set > # CONFIG_FEALNX is not set > # CONFIG_NET_VENDOR_NATSEMI is not set > # CONFIG_NET_VENDOR_NVIDIA is not set > CONFIG_NET_VENDOR_OKI=y > # CONFIG_PCH_GBE is not set > CONFIG_ETHOC=y > # CONFIG_NET_PACKET_ENGINE is not set > # CONFIG_NET_VENDOR_QLOGIC is not set > # CONFIG_NET_VENDOR_REALTEK is not set > # CONFIG_NET_VENDOR_RDC is not set > CONFIG_NET_VENDOR_SIS=y > # CONFIG_SIS900 is not set > # CONFIG_SIS190 is not set > CONFIG_NET_VENDOR_SMSC=y > CONFIG_EPIC100=y > CONFIG_SMSC9420=y > CONFIG_NET_VENDOR_STMICRO=y > # CONFIG_STMMAC_ETH is not set > CONFIG_NET_VENDOR_SUN=y > CONFIG_HAPPYMEAL=y > # CONFIG_SUNGEM is not set > CONFIG_CASSINI=y > CONFIG_NIU=y > CONFIG_NET_VENDOR_TEHUTI=y > CONFIG_TEHUTI=y > CONFIG_NET_VENDOR_TI=y > # CONFIG_TLAN is not set > CONFIG_NET_VENDOR_VIA=y > CONFIG_VIA_RHINE=y > CONFIG_VIA_RHINE_MMIO=y > # CONFIG_VIA_VELOCITY is not set > CONFIG_FDDI=y > # CONFIG_DEFXX is not set > CONFIG_SKFP=y > CONFIG_NET_SB1000=y > CONFIG_PHYLIB=y > > # > # MII PHY device drivers > # > # CONFIG_MARVELL_PHY is not set > # CONFIG_DAVICOM_PHY is not set > # CONFIG_QSEMI_PHY is not set > # CONFIG_LXT_PHY is not set > CONFIG_CICADA_PHY=y > # CONFIG_VITESSE_PHY is not set > CONFIG_SMSC_PHY=y > CONFIG_BROADCOM_PHY=y > CONFIG_ICPLUS_PHY=y > # CONFIG_REALTEK_PHY is not set > CONFIG_NATIONAL_PHY=y > CONFIG_STE10XP=y > CONFIG_LSI_ET1011C_PHY=y > CONFIG_MICREL_PHY=y > CONFIG_FIXED_PHY=y > CONFIG_MDIO_BITBANG=y > CONFIG_MDIO_GPIO=y > # CONFIG_PPP is not set > # CONFIG_SLIP is not set > # CONFIG_TR is not set > CONFIG_WLAN=y > CONFIG_ATMEL=y > # CONFIG_PCI_ATMEL is not set > # CONFIG_HOSTAP is not set > > # > # Enable WiMAX (Networking options) to see the WiMAX drivers > # > # CONFIG_WAN is not set > CONFIG_XEN_NETDEV_FRONTEND=y > CONFIG_ISDN=y > CONFIG_ISDN_I4L=y > # CONFIG_ISDN_AUDIO is not set > > # > # ISDN feature submodules > # > # CONFIG_ISDN_DRV_LOOP is not set > CONFIG_ISDN_DIVERSION=y > > # > # ISDN4Linux hardware drivers > # > > # > # Passive cards > # > CONFIG_ISDN_DRV_HISAX=y > > # > # D-channel protocol features > # > CONFIG_HISAX_EURO=y > # CONFIG_DE_AOC is not set > CONFIG_HISAX_NO_SENDCOMPLETE=y > CONFIG_HISAX_NO_LLC=y > CONFIG_HISAX_NO_KEYPAD=y > CONFIG_HISAX_1TR6=y > # CONFIG_HISAX_NI1 is not set > CONFIG_HISAX_MAX_CARDS=8 > > # > # HiSax supported cards > # > # CONFIG_HISAX_16_3 is not set > CONFIG_HISAX_TELESPCI=y > CONFIG_HISAX_S0BOX=y > CONFIG_HISAX_FRITZPCI=y > # CONFIG_HISAX_AVM_A1_PCMCIA is not set > # CONFIG_HISAX_ELSA is not set > # CONFIG_HISAX_DIEHLDIVA is not set > # CONFIG_HISAX_SEDLBAUER is not set > # CONFIG_HISAX_NETJET is not set > CONFIG_HISAX_NETJET_U=y > CONFIG_HISAX_NICCY=y > CONFIG_HISAX_BKM_A4T=y > # CONFIG_HISAX_SCT_QUADRO is not set > CONFIG_HISAX_GAZEL=y > CONFIG_HISAX_HFC_PCI=y > # CONFIG_HISAX_W6692 is not set > # CONFIG_HISAX_HFC_SX is not set > # CONFIG_HISAX_DEBUG is not set > > # > # HiSax PCMCIA card service modules > # > > # > # HiSax sub driver modules > # > > # > # Active cards > # > # CONFIG_ISDN_CAPI is not set > # CONFIG_ISDN_DRV_GIGASET is not set > CONFIG_MISDN=y > CONFIG_MISDN_DSP=y > CONFIG_MISDN_L1OIP=y > > # > # mISDN hardware drivers > # > CONFIG_MISDN_HFCPCI=y > # CONFIG_MISDN_HFCMULTI is not set > CONFIG_MISDN_AVMFRITZ=y > CONFIG_MISDN_SPEEDFAX=y > # CONFIG_MISDN_INFINEON is not set > # CONFIG_MISDN_W6692 is not set > CONFIG_MISDN_NETJET=y > CONFIG_MISDN_IPAC=y > CONFIG_MISDN_ISAR=y > CONFIG_ISDN_HDLC=y > # CONFIG_PHONE is not set > > # > # Input device support > # > CONFIG_INPUT=y > CONFIG_INPUT_FF_MEMLESS=y > CONFIG_INPUT_POLLDEV=y > CONFIG_INPUT_SPARSEKMAP=y > > # > # Userland interfaces > # > # CONFIG_INPUT_MOUSEDEV is not set > CONFIG_INPUT_JOYDEV=y > # CONFIG_INPUT_EVDEV is not set > # CONFIG_INPUT_EVBUG is not set > > # > # Input Device Drivers > # > # CONFIG_INPUT_KEYBOARD is not set > CONFIG_INPUT_MOUSE=y > CONFIG_MOUSE_PS2=y > CONFIG_MOUSE_PS2_ALPS=y > # CONFIG_MOUSE_PS2_LOGIPS2PP is not set > # CONFIG_MOUSE_PS2_SYNAPTICS is not set > # CONFIG_MOUSE_PS2_TRACKPOINT is not set > # CONFIG_MOUSE_PS2_ELANTECH is not set > # CONFIG_MOUSE_PS2_SENTELIC is not set > CONFIG_MOUSE_PS2_TOUCHKIT=y > # CONFIG_MOUSE_SERIAL is not set > CONFIG_MOUSE_VSXXXAA=y > CONFIG_MOUSE_GPIO=y > CONFIG_MOUSE_SYNAPTICS_I2C=y > # CONFIG_INPUT_JOYSTICK is not set > CONFIG_INPUT_TABLET=y > CONFIG_INPUT_TOUCHSCREEN=y > # CONFIG_TOUCHSCREEN_88PM860X is not set > CONFIG_TOUCHSCREEN_AD7879=y > CONFIG_TOUCHSCREEN_AD7879_I2C=y > # CONFIG_TOUCHSCREEN_ATMEL_MXT is not set > CONFIG_TOUCHSCREEN_BU21013=y > CONFIG_TOUCHSCREEN_CY8CTMG110=y > # CONFIG_TOUCHSCREEN_DA9034 is not set > # CONFIG_TOUCHSCREEN_DYNAPRO is not set > CONFIG_TOUCHSCREEN_HAMPSHIRE=y > CONFIG_TOUCHSCREEN_EETI=y > CONFIG_TOUCHSCREEN_FUJITSU=y > # CONFIG_TOUCHSCREEN_GUNZE is not set > CONFIG_TOUCHSCREEN_ELO=y > # CONFIG_TOUCHSCREEN_WACOM_W8001 is not set > # CONFIG_TOUCHSCREEN_MAX11801 is not set > CONFIG_TOUCHSCREEN_MCS5000=y > CONFIG_TOUCHSCREEN_MTOUCH=y > # CONFIG_TOUCHSCREEN_INEXIO is not set > CONFIG_TOUCHSCREEN_MK712=y > CONFIG_TOUCHSCREEN_PENMOUNT=y > # CONFIG_TOUCHSCREEN_TOUCHRIGHT is not set > # CONFIG_TOUCHSCREEN_TOUCHWIN is not set > # CONFIG_TOUCHSCREEN_WM831X is not set > CONFIG_TOUCHSCREEN_TOUCHIT213=y > CONFIG_TOUCHSCREEN_TSC2007=y > CONFIG_TOUCHSCREEN_ST1232=y > CONFIG_TOUCHSCREEN_TPS6507X=y > CONFIG_INPUT_MISC=y > # CONFIG_INPUT_88PM860X_ONKEY is not set > # CONFIG_INPUT_AD714X is not set > CONFIG_INPUT_BMA150=y > # CONFIG_INPUT_PCSPKR is not set > CONFIG_INPUT_MAX8925_ONKEY=y > # CONFIG_INPUT_MMA8450 is not set > CONFIG_INPUT_MPU3050=y > # CONFIG_INPUT_APANEL is not set > # CONFIG_INPUT_ATLAS_BTNS is not set > # CONFIG_INPUT_KXTJ9 is not set > CONFIG_INPUT_UINPUT=y > CONFIG_INPUT_PCF50633_PMU=y > CONFIG_INPUT_GPIO_ROTARY_ENCODER=y > CONFIG_INPUT_WM831X_ON=y > CONFIG_INPUT_ADXL34X=y > CONFIG_INPUT_ADXL34X_I2C=y > CONFIG_INPUT_CMA3000=y > # CONFIG_INPUT_CMA3000_I2C is not set > # CONFIG_INPUT_XEN_KBDDEV_FRONTEND is not set > > # > # Hardware I/O ports > # > CONFIG_SERIO=y > CONFIG_SERIO_I8042=y > CONFIG_SERIO_SERPORT=y > CONFIG_SERIO_CT82C710=y > # CONFIG_SERIO_PCIPS2 is not set > CONFIG_SERIO_LIBPS2=y > CONFIG_SERIO_RAW=y > CONFIG_SERIO_ALTERA_PS2=y > # CONFIG_SERIO_PS2MULT is not set > CONFIG_GAMEPORT=y > # CONFIG_GAMEPORT_NS558 is not set > # CONFIG_GAMEPORT_L4 is not set > # CONFIG_GAMEPORT_EMU10K1 is not set > # CONFIG_GAMEPORT_FM801 is not set > > # > # Character devices > # > CONFIG_VT=y > CONFIG_CONSOLE_TRANSLATIONS=y > CONFIG_VT_CONSOLE=y > CONFIG_VT_CONSOLE_SLEEP=y > CONFIG_HW_CONSOLE=y > # CONFIG_VT_HW_CONSOLE_BINDING is not set > # CONFIG_UNIX98_PTYS is not set > # CONFIG_LEGACY_PTYS is not set > # CONFIG_SERIAL_NONSTANDARD is not set > # CONFIG_TRACE_SINK is not set > CONFIG_DEVKMEM=y > > # > # Serial drivers > # > CONFIG_SERIAL_8250=y > # CONFIG_SERIAL_8250_CONSOLE is not set > CONFIG_FIX_EARLYCON_MEM=y > CONFIG_SERIAL_8250_PCI=y > # CONFIG_SERIAL_8250_PNP is not set > CONFIG_SERIAL_8250_NR_UARTS=4 > CONFIG_SERIAL_8250_RUNTIME_UARTS=4 > # CONFIG_SERIAL_8250_EXTENDED is not set > > # > # Non-8250 serial port support > # > CONFIG_SERIAL_MFD_HSU=y > CONFIG_SERIAL_MFD_HSU_CONSOLE=y > # CONFIG_SERIAL_UARTLITE is not set > CONFIG_SERIAL_CORE=y > CONFIG_SERIAL_CORE_CONSOLE=y > CONFIG_SERIAL_JSM=y > # CONFIG_SERIAL_TIMBERDALE is not set > CONFIG_SERIAL_ALTERA_JTAGUART=y > CONFIG_SERIAL_ALTERA_JTAGUART_CONSOLE=y > # CONFIG_SERIAL_ALTERA_JTAGUART_CONSOLE_BYPASS is not set > CONFIG_SERIAL_ALTERA_UART=y > CONFIG_SERIAL_ALTERA_UART_MAXPORTS=4 > CONFIG_SERIAL_ALTERA_UART_BAUDRATE=115200 > CONFIG_SERIAL_ALTERA_UART_CONSOLE=y > # CONFIG_SERIAL_PCH_UART is not set > # CONFIG_SERIAL_XILINX_PS_UART is not set > # CONFIG_TTY_PRINTK is not set > # CONFIG_HVC_XEN is not set > # CONFIG_IPMI_HANDLER is not set > CONFIG_HW_RANDOM=y > # CONFIG_HW_RANDOM_TIMERIOMEM is not set > # CONFIG_HW_RANDOM_INTEL is not set > # CONFIG_HW_RANDOM_AMD is not set > CONFIG_HW_RANDOM_VIA=y > CONFIG_NVRAM=y > CONFIG_R3964=y > CONFIG_APPLICOM=y > # CONFIG_MWAVE is not set > # CONFIG_RAW_DRIVER is not set > CONFIG_HPET=y > # CONFIG_HPET_MMAP is not set > CONFIG_HANGCHECK_TIMER=y > CONFIG_DEVPORT=y > # CONFIG_RAMOOPS is not set > CONFIG_I2C=y > CONFIG_I2C_BOARDINFO=y > # CONFIG_I2C_COMPAT is not set > # CONFIG_I2C_CHARDEV is not set > # CONFIG_I2C_HELPER_AUTO is not set > # CONFIG_I2C_SMBUS is not set > > # > # I2C Algorithms > # > CONFIG_I2C_ALGOBIT=y > # CONFIG_I2C_ALGOPCF is not set > # CONFIG_I2C_ALGOPCA is not set > > # > # I2C Hardware Bus support > # > > # > # PC SMBus host controller drivers > # > # CONFIG_I2C_ALI1535 is not set > CONFIG_I2C_ALI15X3=y > # CONFIG_I2C_AMD756 is not set > # CONFIG_I2C_AMD8111 is not set > # CONFIG_I2C_I801 is not set > CONFIG_I2C_ISCH=y > CONFIG_I2C_PIIX4=y > # CONFIG_I2C_NFORCE2 is not set > CONFIG_I2C_SIS5595=y > # CONFIG_I2C_SIS630 is not set > # CONFIG_I2C_SIS96X is not set > CONFIG_I2C_VIAPRO=y > > # > # ACPI drivers > # > CONFIG_I2C_SCMI=y > > # > # I2C system bus drivers (mostly embedded / system-on-chip) > # > # CONFIG_I2C_GPIO is not set > CONFIG_I2C_INTEL_MID=y > # CONFIG_I2C_PCA_PLATFORM is not set > # CONFIG_I2C_PXA_PCI is not set > # CONFIG_I2C_SIMTEC is not set > # CONFIG_I2C_EG20T is not set > > # > # External I2C/SMBus adapter drivers > # > # CONFIG_I2C_PARPORT_LIGHT is not set > > # > # Other I2C/SMBus bus drivers > # > CONFIG_I2C_DEBUG_CORE=y > # CONFIG_I2C_DEBUG_ALGO is not set > CONFIG_I2C_DEBUG_BUS=y > # CONFIG_SPI is not set > > # > # PPS support > # > > # > # PPS generators support > # > > # > # PTP clock support > # > > # > # Enable Device Drivers -> PPS to see the PTP clock options. > # > CONFIG_ARCH_WANT_OPTIONAL_GPIOLIB=y > CONFIG_GPIOLIB=y > # CONFIG_DEBUG_GPIO is not set > CONFIG_GPIO_GENERIC=y > > # > # Memory mapped GPIO drivers: > # > CONFIG_GPIO_GENERIC_PLATFORM=y > CONFIG_GPIO_IT8761E=y > # CONFIG_GPIO_SCH is not set > # CONFIG_GPIO_VX855 is not set > > # > # I2C GPIO expanders: > # > # CONFIG_GPIO_MAX7300 is not set > CONFIG_GPIO_MAX732X=y > CONFIG_GPIO_MAX732X_IRQ=y > # CONFIG_GPIO_PCA953X is not set > # CONFIG_GPIO_PCF857X is not set > CONFIG_GPIO_SX150X=y > CONFIG_GPIO_WM831X=y > # CONFIG_GPIO_ADP5520 is not set > CONFIG_GPIO_ADP5588=y > CONFIG_GPIO_ADP5588_IRQ=y > > # > # PCI GPIO expanders: > # > CONFIG_GPIO_BT8XX=y > # CONFIG_GPIO_LANGWELL is not set > CONFIG_GPIO_PCH=y > # CONFIG_GPIO_ML_IOH is not set > # CONFIG_GPIO_TIMBERDALE is not set > # CONFIG_GPIO_RDC321X is not set > > # > # SPI GPIO expanders: > # > # CONFIG_GPIO_MCP23S08 is not set > > # > # AC97 GPIO expanders: > # > > # > # MODULbus GPIO expanders: > # > CONFIG_GPIO_JANZ_TTL=y > CONFIG_GPIO_TPS65910=y > CONFIG_W1=y > CONFIG_W1_CON=y > > # > # 1-wire Bus Masters > # > CONFIG_W1_MASTER_MATROX=y > CONFIG_W1_MASTER_DS1WM=y > # CONFIG_W1_MASTER_GPIO is not set > > # > # 1-wire Slaves > # > CONFIG_W1_SLAVE_THERM=y > CONFIG_W1_SLAVE_SMEM=y > # CONFIG_W1_SLAVE_DS2408 is not set > CONFIG_W1_SLAVE_DS2423=y > CONFIG_W1_SLAVE_DS2431=y > # CONFIG_W1_SLAVE_DS2433 is not set > CONFIG_W1_SLAVE_DS2760=y > CONFIG_W1_SLAVE_DS2780=y > # CONFIG_W1_SLAVE_BQ27000 is not set > CONFIG_POWER_SUPPLY=y > # CONFIG_POWER_SUPPLY_DEBUG is not set > CONFIG_PDA_POWER=y > # CONFIG_MAX8925_POWER is not set > # CONFIG_WM831X_BACKUP is not set > CONFIG_WM831X_POWER=y > CONFIG_TEST_POWER=y > CONFIG_BATTERY_DS2760=y > CONFIG_BATTERY_DS2780=y > # CONFIG_BATTERY_DS2782 is not set > CONFIG_BATTERY_BQ20Z75=y > CONFIG_BATTERY_BQ27x00=y > # CONFIG_BATTERY_BQ27X00_I2C is not set > # CONFIG_BATTERY_BQ27X00_PLATFORM is not set > CONFIG_BATTERY_DA9030=y > CONFIG_BATTERY_MAX17040=y > # CONFIG_BATTERY_MAX17042 is not set > # CONFIG_CHARGER_PCF50633 is not set > CONFIG_CHARGER_MAX8903=y > # CONFIG_CHARGER_GPIO is not set > # CONFIG_CHARGER_MAX8997 is not set > CONFIG_CHARGER_MAX8998=y > # CONFIG_HWMON is not set > CONFIG_THERMAL=y > CONFIG_WATCHDOG=y > # CONFIG_WATCHDOG_CORE is not set > # CONFIG_WATCHDOG_NOWAYOUT is not set > > # > # Watchdog Device Drivers > # > # CONFIG_SOFT_WATCHDOG is not set > CONFIG_WM831X_WATCHDOG=y > # CONFIG_ACQUIRE_WDT is not set > CONFIG_ADVANTECH_WDT=y > CONFIG_ALIM1535_WDT=y > CONFIG_ALIM7101_WDT=y > CONFIG_SP5100_TCO=y > CONFIG_SC520_WDT=y > CONFIG_SBC_FITPC2_WATCHDOG=y > CONFIG_EUROTECH_WDT=y > CONFIG_IB700_WDT=y > # CONFIG_IBMASR is not set > CONFIG_WAFER_WDT=y > # CONFIG_I6300ESB_WDT is not set > # CONFIG_ITCO_WDT is not set > # CONFIG_IT8712F_WDT is not set > # CONFIG_HP_WATCHDOG is not set > CONFIG_SC1200_WDT=y > # CONFIG_PC87413_WDT is not set > # CONFIG_NV_TCO is not set > # CONFIG_60XX_WDT is not set > # CONFIG_SBC8360_WDT is not set > # CONFIG_CPU5_WDT is not set > CONFIG_SMSC_SCH311X_WDT=y > CONFIG_SMSC37B787_WDT=y > # CONFIG_W83627HF_WDT is not set > # CONFIG_W83697HF_WDT is not set > CONFIG_W83697UG_WDT=y > # CONFIG_W83877F_WDT is not set > # CONFIG_W83977F_WDT is not set > # CONFIG_MACHZ_WDT is not set > # CONFIG_SBC_EPX_C3_WATCHDOG is not set > CONFIG_XEN_WDT=y > > # > # PCI-based Watchdog Cards > # > CONFIG_PCIPCWATCHDOG=y > # CONFIG_WDTPCI is not set > CONFIG_SSB_POSSIBLE=y > > # > # Sonics Silicon Backplane > # > # CONFIG_SSB is not set > CONFIG_BCMA_POSSIBLE=y > > # > # Broadcom specific AMBA > # > CONFIG_BCMA=y > CONFIG_BCMA_HOST_PCI_POSSIBLE=y > # CONFIG_BCMA_HOST_PCI is not set > CONFIG_BCMA_DEBUG=y > > # > # Multifunction device drivers > # > CONFIG_MFD_CORE=y > CONFIG_MFD_88PM860X=y > CONFIG_MFD_SM501=y > # CONFIG_MFD_SM501_GPIO is not set > # CONFIG_HTC_PASIC3 is not set > CONFIG_HTC_I2CPLD=y > CONFIG_TPS6105X=y > # CONFIG_TPS65010 is not set > # CONFIG_TPS6507X is not set > # CONFIG_MFD_TPS6586X is not set > CONFIG_MFD_TPS65910=y > # CONFIG_MFD_TPS65912_I2C is not set > # CONFIG_TWL4030_CORE is not set > # CONFIG_MFD_STMPE is not set > # CONFIG_MFD_TC3589X is not set > # CONFIG_MFD_TMIO is not set > CONFIG_PMIC_DA903X=y > CONFIG_PMIC_ADP5520=y > CONFIG_MFD_MAX8925=y > CONFIG_MFD_MAX8997=y > CONFIG_MFD_MAX8998=y > # CONFIG_MFD_WM8400 is not set > CONFIG_MFD_WM831X=y > CONFIG_MFD_WM831X_I2C=y > # CONFIG_MFD_WM8350_I2C is not set > # CONFIG_MFD_WM8994 is not set > CONFIG_MFD_PCF50633=y > # CONFIG_PCF50633_ADC is not set > CONFIG_PCF50633_GPIO=y > # CONFIG_ABX500_CORE is not set > # CONFIG_MFD_CS5535 is not set > CONFIG_MFD_TIMBERDALE=y > CONFIG_LPC_SCH=y > CONFIG_MFD_RDC321X=y > CONFIG_MFD_JANZ_CMODIO=y > # CONFIG_MFD_VX855 is not set > CONFIG_MFD_WL1273_CORE=y > # CONFIG_MFD_AAT2870_CORE is not set > CONFIG_REGULATOR=y > CONFIG_REGULATOR_DEBUG=y > CONFIG_REGULATOR_DUMMY=y > CONFIG_REGULATOR_FIXED_VOLTAGE=y > CONFIG_REGULATOR_VIRTUAL_CONSUMER=y > CONFIG_REGULATOR_USERSPACE_CONSUMER=y > CONFIG_REGULATOR_BQ24022=y > CONFIG_REGULATOR_MAX1586=y > CONFIG_REGULATOR_MAX8649=y > # CONFIG_REGULATOR_MAX8660 is not set > # CONFIG_REGULATOR_MAX8925 is not set > # CONFIG_REGULATOR_MAX8952 is not set > CONFIG_REGULATOR_MAX8997=y > CONFIG_REGULATOR_MAX8998=y > # CONFIG_REGULATOR_WM831X is not set > # CONFIG_REGULATOR_DA903X is not set > # CONFIG_REGULATOR_PCF50633 is not set > # CONFIG_REGULATOR_LP3971 is not set > CONFIG_REGULATOR_LP3972=y > # CONFIG_REGULATOR_TPS6105X is not set > # CONFIG_REGULATOR_TPS65023 is not set > # CONFIG_REGULATOR_TPS6507X is not set > # CONFIG_REGULATOR_88PM8607 is not set > CONFIG_REGULATOR_ISL6271A=y > CONFIG_REGULATOR_AD5398=y > CONFIG_REGULATOR_TPS65910=y > # CONFIG_MEDIA_SUPPORT is not set > > # > # Graphics support > # > CONFIG_AGP=y > # CONFIG_AGP_AMD64 is not set > CONFIG_AGP_INTEL=y > # CONFIG_AGP_SIS is not set > CONFIG_AGP_VIA=y > CONFIG_VGA_ARB=y > CONFIG_VGA_ARB_MAX_GPUS=16 > # CONFIG_VGA_SWITCHEROO is not set > CONFIG_DRM=y > CONFIG_DRM_KMS_HELPER=y > # CONFIG_DRM_TDFX is not set > CONFIG_DRM_R128=y > # CONFIG_DRM_RADEON is not set > # CONFIG_DRM_I810 is not set > CONFIG_DRM_I915=y > CONFIG_DRM_I915_KMS=y > # CONFIG_DRM_MGA is not set > CONFIG_DRM_SIS=y > # CONFIG_DRM_VIA is not set > # CONFIG_DRM_SAVAGE is not set > CONFIG_STUB_POULSBO=y > CONFIG_VGASTATE=y > CONFIG_VIDEO_OUTPUT_CONTROL=y > CONFIG_FB=y > CONFIG_FIRMWARE_EDID=y > CONFIG_FB_DDC=y > # CONFIG_FB_BOOT_VESA_SUPPORT is not set > CONFIG_FB_CFB_FILLRECT=y > CONFIG_FB_CFB_COPYAREA=y > CONFIG_FB_CFB_IMAGEBLIT=y > # CONFIG_FB_CFB_REV_PIXELS_IN_BYTE is not set > CONFIG_FB_SYS_FILLRECT=y > CONFIG_FB_SYS_COPYAREA=y > CONFIG_FB_SYS_IMAGEBLIT=y > # CONFIG_FB_FOREIGN_ENDIAN is not set > CONFIG_FB_SYS_FOPS=y > # CONFIG_FB_WMT_GE_ROPS is not set > CONFIG_FB_DEFERRED_IO=y > CONFIG_FB_HECUBA=y > CONFIG_FB_SVGALIB=y > # CONFIG_FB_MACMODES is not set > CONFIG_FB_BACKLIGHT=y > CONFIG_FB_MODE_HELPERS=y > CONFIG_FB_TILEBLITTING=y > > # > # Frame buffer hardware drivers > # > # CONFIG_FB_CIRRUS is not set > # CONFIG_FB_PM2 is not set > CONFIG_FB_CYBER2000=y > CONFIG_FB_CYBER2000_DDC=y > CONFIG_FB_ARC=y > # CONFIG_FB_ASILIANT is not set > # CONFIG_FB_IMSTT is not set > CONFIG_FB_VGA16=y > CONFIG_FB_UVESA=y > # CONFIG_FB_VESA is not set > # CONFIG_FB_EFI is not set > CONFIG_FB_N411=y > CONFIG_FB_HGA=y > # CONFIG_FB_S1D13XXX is not set > CONFIG_FB_NVIDIA=y > # CONFIG_FB_NVIDIA_I2C is not set > # CONFIG_FB_NVIDIA_DEBUG is not set > CONFIG_FB_NVIDIA_BACKLIGHT=y > CONFIG_FB_RIVA=y > CONFIG_FB_RIVA_I2C=y > # CONFIG_FB_RIVA_DEBUG is not set > # CONFIG_FB_RIVA_BACKLIGHT is not set > CONFIG_FB_LE80578=y > CONFIG_FB_CARILLO_RANCH=y > # CONFIG_FB_MATROX is not set > # CONFIG_FB_RADEON is not set > CONFIG_FB_ATY128=y > # CONFIG_FB_ATY128_BACKLIGHT is not set > # CONFIG_FB_ATY is not set > # CONFIG_FB_S3 is not set > # CONFIG_FB_SIS is not set > # CONFIG_FB_VIA is not set > # CONFIG_FB_NEOMAGIC is not set > # CONFIG_FB_KYRO is not set > # CONFIG_FB_3DFX is not set > # CONFIG_FB_VOODOO1 is not set > CONFIG_FB_VT8623=y > CONFIG_FB_TRIDENT=y > # CONFIG_FB_ARK is not set > # CONFIG_FB_CARMINE is not set > CONFIG_FB_TMIO=y > CONFIG_FB_TMIO_ACCELL=y > CONFIG_FB_SM501=y > CONFIG_FB_VIRTUAL=y > CONFIG_XEN_FBDEV_FRONTEND=y > # CONFIG_FB_METRONOME is not set > # CONFIG_FB_MB862XX is not set > # CONFIG_FB_BROADSHEET is not set > CONFIG_BACKLIGHT_LCD_SUPPORT=y > CONFIG_LCD_CLASS_DEVICE=y > CONFIG_LCD_PLATFORM=y > CONFIG_BACKLIGHT_CLASS_DEVICE=y > CONFIG_BACKLIGHT_GENERIC=y > CONFIG_BACKLIGHT_PROGEAR=y > CONFIG_BACKLIGHT_CARILLO_RANCH=y > # CONFIG_BACKLIGHT_DA903X is not set > # CONFIG_BACKLIGHT_MAX8925 is not set > # CONFIG_BACKLIGHT_APPLE is not set > CONFIG_BACKLIGHT_SAHARA=y > CONFIG_BACKLIGHT_WM831X=y > CONFIG_BACKLIGHT_ADP5520=y > # CONFIG_BACKLIGHT_ADP8860 is not set > CONFIG_BACKLIGHT_ADP8870=y > # CONFIG_BACKLIGHT_88PM860X is not set > CONFIG_BACKLIGHT_PCF50633=y > > # > # Display device support > # > CONFIG_DISPLAY_SUPPORT=y > > # > # Display hardware drivers > # > > # > # Console display driver support > # > CONFIG_VGA_CONSOLE=y > # CONFIG_VGACON_SOFT_SCROLLBACK is not set > CONFIG_DUMMY_CONSOLE=y > # CONFIG_FRAMEBUFFER_CONSOLE is not set > # CONFIG_LOGO is not set > CONFIG_SOUND=y > CONFIG_SOUND_OSS_CORE=y > # CONFIG_SOUND_OSS_CORE_PRECLAIM is not set > CONFIG_SND=y > CONFIG_SND_TIMER=y > CONFIG_SND_SEQUENCER=y > CONFIG_SND_SEQ_DUMMY=y > CONFIG_SND_OSSEMUL=y > CONFIG_SND_MIXER_OSS=y > # CONFIG_SND_PCM_OSS is not set > CONFIG_SND_SEQUENCER_OSS=y > CONFIG_SND_DYNAMIC_MINORS=y > CONFIG_SND_SUPPORT_OLD_API=y > CONFIG_SND_VERBOSE_PROCFS=y > CONFIG_SND_VERBOSE_PRINTK=y > # CONFIG_SND_DEBUG is not set > CONFIG_SND_DMA_SGBUF=y > # CONFIG_SND_RAWMIDI_SEQ is not set > # CONFIG_SND_OPL3_LIB_SEQ is not set > # CONFIG_SND_OPL4_LIB_SEQ is not set > # CONFIG_SND_SBAWE_SEQ is not set > # CONFIG_SND_EMU10K1_SEQ is not set > # CONFIG_SND_DRIVERS is not set > # CONFIG_SND_PCI is not set > # CONFIG_SND_FIREWIRE is not set > # CONFIG_SND_SOC is not set > # CONFIG_SOUND_PRIME is not set > CONFIG_HID_SUPPORT=y > # CONFIG_HID is not set > CONFIG_HID_PID=y > # CONFIG_USB_SUPPORT is not set > # CONFIG_MMC is not set > # CONFIG_MEMSTICK is not set > CONFIG_NEW_LEDS=y > CONFIG_LEDS_CLASS=y > > # > # LED drivers > # > CONFIG_LEDS_88PM860X=y > # CONFIG_LEDS_LM3530 is not set > # CONFIG_LEDS_GPIO is not set > CONFIG_LEDS_LP3944=y > # CONFIG_LEDS_LP5521 is not set > CONFIG_LEDS_LP5523=y > # CONFIG_LEDS_PCA955X is not set > CONFIG_LEDS_WM831X_STATUS=y > CONFIG_LEDS_DA903X=y > # CONFIG_LEDS_REGULATOR is not set > # CONFIG_LEDS_BD2802 is not set > # CONFIG_LEDS_LT3593 is not set > # CONFIG_LEDS_ADP5520 is not set > CONFIG_LEDS_TRIGGERS=y > > # > # LED Triggers > # > # CONFIG_LEDS_TRIGGER_TIMER is not set > CONFIG_LEDS_TRIGGER_HEARTBEAT=y > # CONFIG_LEDS_TRIGGER_BACKLIGHT is not set > CONFIG_LEDS_TRIGGER_GPIO=y > CONFIG_LEDS_TRIGGER_DEFAULT_ON=y > > # > # iptables trigger is under Netfilter config (LED target) > # > CONFIG_ACCESSIBILITY=y > # CONFIG_A11Y_BRAILLE_CONSOLE is not set > # CONFIG_INFINIBAND is not set > CONFIG_EDAC=y > > # > # Reporting subsystems > # > # CONFIG_EDAC_DEBUG is not set > # CONFIG_EDAC_DECODE_MCE is not set > # CONFIG_EDAC_MM_EDAC is not set > CONFIG_RTC_LIB=y > CONFIG_RTC_CLASS=y > CONFIG_RTC_HCTOSYS=y > CONFIG_RTC_HCTOSYS_DEVICE="rtc0" > CONFIG_RTC_DEBUG=y > > # > # RTC interfaces > # > CONFIG_RTC_INTF_SYSFS=y > CONFIG_RTC_INTF_PROC=y > CONFIG_RTC_INTF_DEV=y > CONFIG_RTC_INTF_DEV_UIE_EMUL=y > # CONFIG_RTC_DRV_TEST is not set > > # > # I2C RTC drivers > # > CONFIG_RTC_DRV_88PM860X=y > # CONFIG_RTC_DRV_DS1307 is not set > CONFIG_RTC_DRV_DS1374=y > # CONFIG_RTC_DRV_DS1672 is not set > # CONFIG_RTC_DRV_DS3232 is not set > # CONFIG_RTC_DRV_MAX6900 is not set > CONFIG_RTC_DRV_MAX8925=y > # CONFIG_RTC_DRV_MAX8998 is not set > # CONFIG_RTC_DRV_RS5C372 is not set > # CONFIG_RTC_DRV_ISL1208 is not set > CONFIG_RTC_DRV_ISL12022=y > CONFIG_RTC_DRV_X1205=y > CONFIG_RTC_DRV_PCF8563=y > CONFIG_RTC_DRV_PCF8583=y > CONFIG_RTC_DRV_M41T80=y > # CONFIG_RTC_DRV_M41T80_WDT is not set > # CONFIG_RTC_DRV_BQ32K is not set > # CONFIG_RTC_DRV_S35390A is not set > CONFIG_RTC_DRV_FM3130=y > CONFIG_RTC_DRV_RX8581=y > # CONFIG_RTC_DRV_RX8025 is not set > # CONFIG_RTC_DRV_EM3027 is not set > CONFIG_RTC_DRV_RV3029C2=y > > # > # SPI RTC drivers > # > > # > # Platform RTC drivers > # > CONFIG_RTC_DRV_CMOS=y > CONFIG_RTC_DRV_DS1286=y > # CONFIG_RTC_DRV_DS1511 is not set > # CONFIG_RTC_DRV_DS1553 is not set > # CONFIG_RTC_DRV_DS1742 is not set > # CONFIG_RTC_DRV_STK17TA8 is not set > # CONFIG_RTC_DRV_M48T86 is not set > # CONFIG_RTC_DRV_M48T35 is not set > # CONFIG_RTC_DRV_M48T59 is not set > CONFIG_RTC_DRV_MSM6242=y > # CONFIG_RTC_DRV_BQ4802 is not set > # CONFIG_RTC_DRV_RP5C01 is not set > CONFIG_RTC_DRV_V3020=y > # CONFIG_RTC_DRV_WM831X is not set > CONFIG_RTC_DRV_PCF50633=y > > # > # on-CPU RTC drivers > # > # CONFIG_DMADEVICES is not set > CONFIG_AUXDISPLAY=y > CONFIG_UIO=y > # CONFIG_UIO_CIF is not set > CONFIG_UIO_PDRV=y > CONFIG_UIO_PDRV_GENIRQ=y > # CONFIG_UIO_AEC is not set > CONFIG_UIO_SERCOS3=y > # CONFIG_UIO_PCI_GENERIC is not set > # CONFIG_UIO_NETX is not set > > # > # Virtio drivers > # > # CONFIG_VIRTIO_BALLOON is not set > > # > # Xen driver support > # > # CONFIG_XEN_BALLOON is not set > # CONFIG_XEN_DEV_EVTCHN is not set > # CONFIG_XEN_BACKEND is not set > # CONFIG_XENFS is not set > # CONFIG_XEN_SYS_HYPERVISOR is not set > CONFIG_XEN_XENBUS_FRONTEND=y > # CONFIG_XEN_GNTDEV is not set > # CONFIG_XEN_GRANT_DEV_ALLOC is not set > CONFIG_XEN_PLATFORM_PCI=y > CONFIG_SWIOTLB_XEN=y > # CONFIG_STAGING is not set > # CONFIG_X86_PLATFORM_DEVICES is not set > > # > # Hardware Spinlock drivers > # > CONFIG_CLKEVT_I8253=y > CONFIG_I8253_LOCK=y > CONFIG_CLKBLD_I8253=y > # CONFIG_IOMMU_SUPPORT is not set > # CONFIG_VIRT_DRIVERS is not set > > # > # Firmware Drivers > # > # CONFIG_EDD is not set > # CONFIG_FIRMWARE_MEMMAP is not set > # CONFIG_EFI_VARS is not set > # CONFIG_DELL_RBU is not set > # CONFIG_DCDBAS is not set > CONFIG_ISCSI_IBFT_FIND=y > CONFIG_ISCSI_IBFT=y > CONFIG_SIGMA=y > CONFIG_GOOGLE_FIRMWARE=y > > # > # Google Firmware Drivers > # > > # > # File systems > # > CONFIG_EXT2_FS=y > # CONFIG_EXT2_FS_XATTR is not set > CONFIG_EXT2_FS_XIP=y > # CONFIG_EXT3_FS is not set > # CONFIG_EXT4_FS is not set > CONFIG_FS_XIP=y > # CONFIG_REISERFS_FS is not set > # CONFIG_JFS_FS is not set > CONFIG_XFS_FS=y > CONFIG_XFS_QUOTA=y > CONFIG_XFS_POSIX_ACL=y > # CONFIG_XFS_RT is not set > CONFIG_GFS2_FS=y > # CONFIG_OCFS2_FS is not set > CONFIG_FS_POSIX_ACL=y > CONFIG_EXPORTFS=y > CONFIG_FILE_LOCKING=y > CONFIG_FSNOTIFY=y > # CONFIG_DNOTIFY is not set > CONFIG_INOTIFY_USER=y > CONFIG_FANOTIFY=y > # CONFIG_QUOTA is not set > CONFIG_QUOTA_NETLINK_INTERFACE=y > CONFIG_QUOTACTL=y > CONFIG_QUOTACTL_COMPAT=y > CONFIG_AUTOFS4_FS=y > CONFIG_FUSE_FS=y > CONFIG_CUSE=y > > # > # Caches > # > # CONFIG_FSCACHE is not set > > # > # CD-ROM/DVD Filesystems > # > # CONFIG_ISO9660_FS is not set > CONFIG_UDF_FS=y > CONFIG_UDF_NLS=y > > # > # DOS/FAT/NT Filesystems > # > CONFIG_FAT_FS=y > CONFIG_MSDOS_FS=y > # CONFIG_VFAT_FS is not set > CONFIG_FAT_DEFAULT_CODEPAGE=437 > # CONFIG_NTFS_FS is not set > > # > # Pseudo filesystems > # > CONFIG_PROC_FS=y > CONFIG_PROC_KCORE=y > CONFIG_PROC_VMCORE=y > # CONFIG_PROC_SYSCTL is not set > CONFIG_PROC_PAGE_MONITOR=y > CONFIG_SYSFS=y > CONFIG_TMPFS=y > # CONFIG_TMPFS_POSIX_ACL is not set > # CONFIG_TMPFS_XATTR is not set > # CONFIG_HUGETLBFS is not set > # CONFIG_HUGETLB_PAGE is not set > CONFIG_CONFIGFS_FS=y > CONFIG_MISC_FILESYSTEMS=y > CONFIG_HFSPLUS_FS=y > # CONFIG_CRAMFS is not set > # CONFIG_SQUASHFS is not set > # CONFIG_VXFS_FS is not set > CONFIG_MINIX_FS=y > CONFIG_OMFS_FS=y > CONFIG_HPFS_FS=y > CONFIG_QNX4FS_FS=y > CONFIG_ROMFS_FS=y > CONFIG_ROMFS_BACKED_BY_BLOCK=y > CONFIG_ROMFS_ON_BLOCK=y > CONFIG_PSTORE=y > CONFIG_SYSV_FS=y > CONFIG_UFS_FS=y > # CONFIG_UFS_DEBUG is not set > # CONFIG_NETWORK_FILESYSTEMS is not set > > # > # Partition Types > # > CONFIG_PARTITION_ADVANCED=y > CONFIG_ACORN_PARTITION=y > CONFIG_ACORN_PARTITION_CUMANA=y > CONFIG_ACORN_PARTITION_EESOX=y > # CONFIG_ACORN_PARTITION_ICS is not set > # CONFIG_ACORN_PARTITION_ADFS is not set > # CONFIG_ACORN_PARTITION_POWERTEC is not set > # CONFIG_ACORN_PARTITION_RISCIX is not set > CONFIG_OSF_PARTITION=y > # CONFIG_AMIGA_PARTITION is not set > # CONFIG_ATARI_PARTITION is not set > # CONFIG_MAC_PARTITION is not set > # CONFIG_MSDOS_PARTITION is not set > # CONFIG_LDM_PARTITION is not set > # CONFIG_SGI_PARTITION is not set > CONFIG_ULTRIX_PARTITION=y > # CONFIG_SUN_PARTITION is not set > # CONFIG_KARMA_PARTITION is not set > CONFIG_EFI_PARTITION=y > # CONFIG_SYSV68_PARTITION is not set > CONFIG_NLS=y > CONFIG_NLS_DEFAULT="iso8859-1" > CONFIG_NLS_CODEPAGE_437=y > # CONFIG_NLS_CODEPAGE_737 is not set > CONFIG_NLS_CODEPAGE_775=y > CONFIG_NLS_CODEPAGE_850=y > CONFIG_NLS_CODEPAGE_852=y > CONFIG_NLS_CODEPAGE_855=y > # CONFIG_NLS_CODEPAGE_857 is not set > CONFIG_NLS_CODEPAGE_860=y > # CONFIG_NLS_CODEPAGE_861 is not set > # CONFIG_NLS_CODEPAGE_862 is not set > CONFIG_NLS_CODEPAGE_863=y > CONFIG_NLS_CODEPAGE_864=y > # CONFIG_NLS_CODEPAGE_865 is not set > # CONFIG_NLS_CODEPAGE_866 is not set > CONFIG_NLS_CODEPAGE_869=y > # CONFIG_NLS_CODEPAGE_936 is not set > CONFIG_NLS_CODEPAGE_950=y > # CONFIG_NLS_CODEPAGE_932 is not set > # CONFIG_NLS_CODEPAGE_949 is not set > CONFIG_NLS_CODEPAGE_874=y > CONFIG_NLS_ISO8859_8=y > # CONFIG_NLS_CODEPAGE_1250 is not set > # CONFIG_NLS_CODEPAGE_1251 is not set > CONFIG_NLS_ASCII=y > CONFIG_NLS_ISO8859_1=y > # CONFIG_NLS_ISO8859_2 is not set > # CONFIG_NLS_ISO8859_3 is not set > # CONFIG_NLS_ISO8859_4 is not set > # CONFIG_NLS_ISO8859_5 is not set > # CONFIG_NLS_ISO8859_6 is not set > CONFIG_NLS_ISO8859_7=y > CONFIG_NLS_ISO8859_9=y > CONFIG_NLS_ISO8859_13=y > CONFIG_NLS_ISO8859_14=y > # CONFIG_NLS_ISO8859_15 is not set > CONFIG_NLS_KOI8_R=y > # CONFIG_NLS_KOI8_U is not set > CONFIG_NLS_UTF8=y > > # > # Kernel hacking > # > CONFIG_TRACE_IRQFLAGS_SUPPORT=y > CONFIG_DEFAULT_MESSAGE_LOGLEVEL=4 > # CONFIG_ENABLE_WARN_DEPRECATED is not set > # CONFIG_ENABLE_MUST_CHECK is not set > CONFIG_FRAME_WARN=2048 > # CONFIG_MAGIC_SYSRQ is not set > # CONFIG_STRIP_ASM_SYMS is not set > # CONFIG_UNUSED_SYMBOLS is not set > CONFIG_DEBUG_FS=y > # CONFIG_HEADERS_CHECK is not set > CONFIG_DEBUG_SECTION_MISMATCH=y > CONFIG_DEBUG_KERNEL=y > CONFIG_DEBUG_SHIRQ=y > CONFIG_LOCKUP_DETECTOR=y > CONFIG_HARDLOCKUP_DETECTOR=y > CONFIG_BOOTPARAM_HARDLOCKUP_PANIC=y > CONFIG_BOOTPARAM_HARDLOCKUP_PANIC_VALUE=1 > CONFIG_BOOTPARAM_SOFTLOCKUP_PANIC=y > CONFIG_BOOTPARAM_SOFTLOCKUP_PANIC_VALUE=1 > CONFIG_DETECT_HUNG_TASK=y > CONFIG_DEFAULT_HUNG_TASK_TIMEOUT=120 > # CONFIG_BOOTPARAM_HUNG_TASK_PANIC is not set > CONFIG_BOOTPARAM_HUNG_TASK_PANIC_VALUE=0 > CONFIG_SCHED_DEBUG=y > CONFIG_SCHEDSTATS=y > CONFIG_TIMER_STATS=y > CONFIG_DEBUG_OBJECTS=y > # CONFIG_DEBUG_OBJECTS_SELFTEST is not set > CONFIG_DEBUG_OBJECTS_FREE=y > CONFIG_DEBUG_OBJECTS_TIMERS=y > # CONFIG_DEBUG_OBJECTS_WORK is not set > CONFIG_DEBUG_OBJECTS_RCU_HEAD=y > # CONFIG_DEBUG_OBJECTS_PERCPU_COUNTER is not set > CONFIG_DEBUG_OBJECTS_ENABLE_DEFAULT=1 > # CONFIG_SLUB_DEBUG_ON is not set > CONFIG_SLUB_STATS=y > # CONFIG_DEBUG_RT_MUTEXES is not set > CONFIG_RT_MUTEX_TESTER=y > # CONFIG_DEBUG_SPINLOCK is not set > # CONFIG_DEBUG_MUTEXES is not set > # CONFIG_DEBUG_LOCK_ALLOC is not set > # CONFIG_PROVE_LOCKING is not set > CONFIG_SPARSE_RCU_POINTER=y > # CONFIG_LOCK_STAT is not set > CONFIG_TRACE_IRQFLAGS=y > # CONFIG_DEBUG_ATOMIC_SLEEP is not set > CONFIG_DEBUG_LOCKING_API_SELFTESTS=y > CONFIG_STACKTRACE=y > # CONFIG_DEBUG_STACK_USAGE is not set > # CONFIG_DEBUG_KOBJECT is not set > CONFIG_DEBUG_BUGVERBOSE=y > # CONFIG_DEBUG_INFO is not set > # CONFIG_DEBUG_VM is not set > CONFIG_DEBUG_VIRTUAL=y > # CONFIG_DEBUG_WRITECOUNT is not set > # CONFIG_DEBUG_MEMORY_INIT is not set > # CONFIG_DEBUG_LIST is not set > CONFIG_TEST_LIST_SORT=y > # CONFIG_DEBUG_SG is not set > CONFIG_DEBUG_NOTIFIERS=y > CONFIG_DEBUG_CREDENTIALS=y > CONFIG_ARCH_WANT_FRAME_POINTERS=y > CONFIG_FRAME_POINTER=y > # CONFIG_RCU_TORTURE_TEST is not set > CONFIG_BACKTRACE_SELF_TEST=y > CONFIG_DEBUG_BLOCK_EXT_DEVT=y > CONFIG_DEBUG_FORCE_WEAK_PER_CPU=y > # CONFIG_LKDTM is not set > CONFIG_FAULT_INJECTION=y > # CONFIG_FAILSLAB is not set > CONFIG_FAIL_PAGE_ALLOC=y > CONFIG_FAIL_MAKE_REQUEST=y > CONFIG_FAIL_IO_TIMEOUT=y > # CONFIG_FAULT_INJECTION_DEBUG_FS is not set > CONFIG_LATENCYTOP=y > CONFIG_ARCH_HAS_DEBUG_STRICT_USER_COPY_CHECKS=y > CONFIG_DEBUG_PAGEALLOC=y > CONFIG_USER_STACKTRACE_SUPPORT=y > CONFIG_NOP_TRACER=y > CONFIG_HAVE_FTRACE_NMI_ENTER=y > CONFIG_HAVE_FUNCTION_TRACER=y > CONFIG_HAVE_FUNCTION_GRAPH_TRACER=y > CONFIG_HAVE_FUNCTION_GRAPH_FP_TEST=y > CONFIG_HAVE_FUNCTION_TRACE_MCOUNT_TEST=y > CONFIG_HAVE_DYNAMIC_FTRACE=y > CONFIG_HAVE_FTRACE_MCOUNT_RECORD=y > CONFIG_HAVE_SYSCALL_TRACEPOINTS=y > CONFIG_HAVE_C_RECORDMCOUNT=y > CONFIG_TRACER_MAX_TRACE=y > CONFIG_RING_BUFFER=y > CONFIG_FTRACE_NMI_ENTER=y > CONFIG_EVENT_TRACING=y > CONFIG_EVENT_POWER_TRACING_DEPRECATED=y > CONFIG_CONTEXT_SWITCH_TRACER=y > CONFIG_RING_BUFFER_ALLOW_SWAP=y > CONFIG_TRACING=y > CONFIG_GENERIC_TRACER=y > CONFIG_TRACING_SUPPORT=y > CONFIG_FTRACE=y > CONFIG_FUNCTION_TRACER=y > # CONFIG_FUNCTION_GRAPH_TRACER is not set > CONFIG_IRQSOFF_TRACER=y > # CONFIG_SCHED_TRACER is not set > # CONFIG_FTRACE_SYSCALLS is not set > CONFIG_TRACE_BRANCH_PROFILING=y > # CONFIG_BRANCH_PROFILE_NONE is not set > # CONFIG_PROFILE_ANNOTATED_BRANCHES is not set > CONFIG_PROFILE_ALL_BRANCHES=y > CONFIG_TRACING_BRANCHES=y > CONFIG_BRANCH_TRACER=y > CONFIG_STACK_TRACER=y > # CONFIG_BLK_DEV_IO_TRACE is not set > CONFIG_DYNAMIC_FTRACE=y > # CONFIG_FUNCTION_PROFILER is not set > CONFIG_FTRACE_MCOUNT_RECORD=y > # CONFIG_FTRACE_STARTUP_TEST is not set > # CONFIG_MMIOTRACE is not set > CONFIG_RING_BUFFER_BENCHMARK=y > # CONFIG_PROVIDE_OHCI1394_DMA_INIT is not set > CONFIG_FIREWIRE_OHCI_REMOTE_DMA=y > # CONFIG_DMA_API_DEBUG is not set > # CONFIG_ATOMIC64_SELFTEST is not set > # CONFIG_SAMPLES is not set > CONFIG_HAVE_ARCH_KGDB=y > CONFIG_HAVE_ARCH_KMEMCHECK=y > CONFIG_TEST_KSTRTOX=y > # CONFIG_STRICT_DEVMEM is not set > # CONFIG_X86_VERBOSE_BOOTUP is not set > # CONFIG_EARLY_PRINTK is not set > # CONFIG_DEBUG_STACKOVERFLOW is not set > # CONFIG_X86_PTDUMP is not set > # CONFIG_DEBUG_RODATA is not set > CONFIG_IOMMU_DEBUG=y > # CONFIG_IOMMU_STRESS is not set > CONFIG_HAVE_MMIOTRACE_SUPPORT=y > CONFIG_IO_DELAY_TYPE_0X80=0 > CONFIG_IO_DELAY_TYPE_0XED=1 > CONFIG_IO_DELAY_TYPE_UDELAY=2 > CONFIG_IO_DELAY_TYPE_NONE=3 > CONFIG_IO_DELAY_0X80=y > # CONFIG_IO_DELAY_0XED is not set > # CONFIG_IO_DELAY_UDELAY is not set > # CONFIG_IO_DELAY_NONE is not set > CONFIG_DEFAULT_IO_DELAY_TYPE=0 > CONFIG_DEBUG_BOOT_PARAMS=y > # CONFIG_CPA_DEBUG is not set > # CONFIG_OPTIMIZE_INLINING is not set > > # > # Security options > # > CONFIG_KEYS=y > # CONFIG_ENCRYPTED_KEYS is not set > # CONFIG_KEYS_DEBUG_PROC_KEYS is not set > # CONFIG_SECURITY_DMESG_RESTRICT is not set > # CONFIG_SECURITY is not set > CONFIG_SECURITYFS=y > CONFIG_DEFAULT_SECURITY_DAC=y > CONFIG_DEFAULT_SECURITY="" > CONFIG_CRYPTO=y > > # > # Crypto core or helper > # > CONFIG_CRYPTO_ALGAPI=y > CONFIG_CRYPTO_ALGAPI2=y > CONFIG_CRYPTO_AEAD=y > CONFIG_CRYPTO_AEAD2=y > CONFIG_CRYPTO_BLKCIPHER=y > CONFIG_CRYPTO_BLKCIPHER2=y > CONFIG_CRYPTO_HASH=y > CONFIG_CRYPTO_HASH2=y > CONFIG_CRYPTO_RNG=y > CONFIG_CRYPTO_RNG2=y > CONFIG_CRYPTO_PCOMP=y > CONFIG_CRYPTO_PCOMP2=y > CONFIG_CRYPTO_MANAGER=y > CONFIG_CRYPTO_MANAGER2=y > # CONFIG_CRYPTO_MANAGER_DISABLE_TESTS is not set > CONFIG_CRYPTO_GF128MUL=y > CONFIG_CRYPTO_NULL=y > CONFIG_CRYPTO_WORKQUEUE=y > CONFIG_CRYPTO_CRYPTD=y > CONFIG_CRYPTO_AUTHENC=y > > # > # Authenticated Encryption with Associated Data > # > # CONFIG_CRYPTO_CCM is not set > CONFIG_CRYPTO_GCM=y > CONFIG_CRYPTO_SEQIV=y > > # > # Block modes > # > CONFIG_CRYPTO_CBC=y > CONFIG_CRYPTO_CTR=y > CONFIG_CRYPTO_CTS=y > CONFIG_CRYPTO_ECB=y > CONFIG_CRYPTO_PCBC=y > > # > # Hash modes > # > # CONFIG_CRYPTO_HMAC is not set > > # > # Digest > # > CONFIG_CRYPTO_CRC32C=y > CONFIG_CRYPTO_CRC32C_INTEL=y > CONFIG_CRYPTO_GHASH=y > # CONFIG_CRYPTO_MD4 is not set > # CONFIG_CRYPTO_MD5 is not set > CONFIG_CRYPTO_MICHAEL_MIC=y > # CONFIG_CRYPTO_RMD128 is not set > CONFIG_CRYPTO_RMD160=y > CONFIG_CRYPTO_RMD256=y > CONFIG_CRYPTO_RMD320=y > CONFIG_CRYPTO_SHA1=y > CONFIG_CRYPTO_SHA1_SSSE3=y > CONFIG_CRYPTO_SHA256=y > # CONFIG_CRYPTO_SHA512 is not set > CONFIG_CRYPTO_TGR192=y > CONFIG_CRYPTO_WP512=y > CONFIG_CRYPTO_GHASH_CLMUL_NI_INTEL=y > > # > # Ciphers > # > CONFIG_CRYPTO_AES=y > CONFIG_CRYPTO_AES_X86_64=y > CONFIG_CRYPTO_AES_NI_INTEL=y > # CONFIG_CRYPTO_ANUBIS is not set > # CONFIG_CRYPTO_ARC4 is not set > CONFIG_CRYPTO_BLOWFISH=y > CONFIG_CRYPTO_BLOWFISH_COMMON=y > # CONFIG_CRYPTO_BLOWFISH_X86_64 is not set > CONFIG_CRYPTO_CAMELLIA=y > # CONFIG_CRYPTO_CAST5 is not set > CONFIG_CRYPTO_CAST6=y > CONFIG_CRYPTO_DES=y > # CONFIG_CRYPTO_FCRYPT is not set > # CONFIG_CRYPTO_KHAZAD is not set > # CONFIG_CRYPTO_SEED is not set > CONFIG_CRYPTO_SERPENT=y > CONFIG_CRYPTO_TEA=y > # CONFIG_CRYPTO_TWOFISH is not set > CONFIG_CRYPTO_TWOFISH_COMMON=y > CONFIG_CRYPTO_TWOFISH_X86_64=y > > # > # Compression > # > CONFIG_CRYPTO_DEFLATE=y > CONFIG_CRYPTO_ZLIB=y > # CONFIG_CRYPTO_LZO is not set > > # > # Random Number Generation > # > # CONFIG_CRYPTO_ANSI_CPRNG is not set > CONFIG_CRYPTO_USER_API=y > # CONFIG_CRYPTO_USER_API_HASH is not set > CONFIG_CRYPTO_USER_API_SKCIPHER=y > CONFIG_CRYPTO_HW=y > CONFIG_CRYPTO_DEV_PADLOCK=y > # CONFIG_CRYPTO_DEV_PADLOCK_AES is not set > # CONFIG_CRYPTO_DEV_PADLOCK_SHA is not set > CONFIG_CRYPTO_DEV_HIFN_795X=y > # CONFIG_CRYPTO_DEV_HIFN_795X_RNG is not set > CONFIG_HAVE_KVM=y > CONFIG_VIRTUALIZATION=y > # CONFIG_KVM is not set > CONFIG_BINARY_PRINTF=y > > # > # Library routines > # > CONFIG_BITREVERSE=y > CONFIG_GENERIC_FIND_FIRST_BIT=y > CONFIG_CRC_CCITT=y > CONFIG_CRC16=y > CONFIG_CRC_T10DIF=y > CONFIG_CRC_ITU_T=y > CONFIG_CRC32=y > CONFIG_CRC7=y > CONFIG_LIBCRC32C=y > # CONFIG_CRC8 is not set > CONFIG_ZLIB_INFLATE=y > CONFIG_ZLIB_DEFLATE=y > CONFIG_LZO_COMPRESS=y > CONFIG_LZO_DECOMPRESS=y > CONFIG_XZ_DEC=y > # CONFIG_XZ_DEC_X86 is not set > CONFIG_XZ_DEC_POWERPC=y > # CONFIG_XZ_DEC_IA64 is not set > CONFIG_XZ_DEC_ARM=y > # CONFIG_XZ_DEC_ARMTHUMB is not set > # CONFIG_XZ_DEC_SPARC is not set > CONFIG_XZ_DEC_BCJ=y > CONFIG_XZ_DEC_TEST=y > CONFIG_DECOMPRESS_GZIP=y > CONFIG_DECOMPRESS_LZO=y > CONFIG_HAS_IOMEM=y > CONFIG_HAS_IOPORT=y > CONFIG_HAS_DMA=y > CONFIG_CHECK_SIGNATURE=y > CONFIG_NLATTR=y > # CONFIG_AVERAGE is not set > CONFIG_CORDIC=y > _______________________________________________ > Xen-devel mailing list > Xen-devel@lists.xensource.com > http://lists.xensource.com/xen-devel _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel From xen-devel-bounces@lists.xensource.com Mon Sep 26 10:24:02 2011 Return-path: <xen-devel-bounces@lists.xensource.com> Envelope-to: www-data@lists.xensource.com Delivery-date: Mon, 26 Sep 2011 10:24:02 -0700 Received: from localhost ([127.0.0.1] helo=lists.colo.xensource.com) by lists.xensource.com with esmtp (Exim 4.43) id 1R8EuQ-00023Q-A5; Mon, 26 Sep 2011 10:24:02 -0700 Received: from mail182.messagelabs.com ([85.158.139.83]) by lists.xensource.com with esmtp (Exim 4.43) id 1R8Etx-0001rb-JQ for xen-devel@lists.xensource.com; Mon, 26 Sep 2011 10:23:33 -0700 X-Env-Sender: konrad@oracle.com X-Msg-Ref: server-2.tower-182.messagelabs.com!1317057809!18809382!1 X-Originating-IP: [141.146.126.227] X-StarScan-Version: 6.4.1; banners=-,-,- X-VirusChecked: Checked Received: (qmail 28333 invoked from network); 26 Sep 2011 17:23:30 -0000 Received: from acsinet15.oracle.com (HELO acsinet15.oracle.com) (141.146.126.227) by server-2.tower-182.messagelabs.com with DHE-RSA-AES256-SHA encrypted SMTP; 26 Sep 2011 17:23:30 -0000 Received: from rtcsinet21.oracle.com (rtcsinet21.oracle.com [66.248.204.29]) by acsinet15.oracle.com (Switch-3.4.4/Switch-3.4.4) with ESMTP id p8QHNNXG022844 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Mon, 26 Sep 2011 17:23:25 GMT Received: from acsmt356.oracle.com (acsmt356.oracle.com [141.146.40.156]) by rtcsinet21.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id p8QHNLTJ022083 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 26 Sep 2011 17:23:22 GMT Received: from abhmt102.oracle.com (abhmt102.oracle.com [141.146.116.54]) by acsmt356.oracle.com (8.12.11.20060308/8.12.11) with ESMTP id p8QHNEa5031960; Mon, 26 Sep 2011 12:23:14 -0500 Received: from oracle.com (/209.6.55.207) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Mon, 26 Sep 2011 10:23:14 -0700 Received: by oracle.com (Postfix, from userid 1000) id 723151551; Mon, 26 Sep 2011 13:23:07 -0400 (EDT) Date: Mon, 26 Sep 2011 13:23:07 -0400 From: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com> To: Dan Magenheimer <dan.magenheimer@oracle.com> Message-ID: <20110926172307.GA9973@phenom.oracle.com> References: <9827a70d-dfb2-4bbc-9df6-207b10c835ac@default> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <9827a70d-dfb2-4bbc-9df6-207b10c835ac@default> User-Agent: Mutt/1.5.21 (2010-09-15) X-Source-IP: rtcsinet21.oracle.com [66.248.204.29] X-CT-RefId: str=0001.0A090203.4E80B50F.006E,ss=1,re=0.000,fgs=0 Cc: Jeremy Fitzhardinge <jeremy@goop.org>, xen-devel@lists.xensource.com, linux-kernel@vger.kernel.org, David Vrabel <david.vrabel@citrix.com> Subject: [Xen-devel] Re: [PATCH] xen: Fix selfballooning and ensure it doesn't go too far X-BeenThere: xen-devel@lists.xensource.com X-Mailman-Version: 2.1.5 Precedence: list List-Id: Xen developer discussion <xen-devel.lists.xensource.com> List-Unsubscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe> List-Post: <mailto:xen-devel@lists.xensource.com> List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help> List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=subscribe> Sender: xen-devel-bounces@lists.xensource.com Errors-To: xen-devel-bounces@lists.xensource.com On Sat, Sep 24, 2011 at 01:58:08PM -0700, Dan Magenheimer wrote: > [PATCH] xen: Fix selfballooning and ensure it doesn't go too far > > The balloon driver's "current_pages" is very different from > totalram_pages. Self-ballooning needs to be driven by > the latter. Also, Committed_AS doesn't account for pages > used by the kernel so enforce a floor for when there > are little or no user-space threads using memory. Hey Dan, .. > + floor_pages = totalreserve_pages + > + (roundup_pow_of_two(max_pfn) >> 5); Would it make sense to make the shift be a runtime argument in case some users report problems with that calculation? > + /* don't balloon too far, lest OOMs occur... */ > + if (tgt_pages < floor_pages) > + tgt_pages = floor_pages; > + balloon_set_new_target(tgt_pages + > + balloon_stats.current_pages - totalram_pages); > reset_timer = true; > } > #ifdef CONFIG_FRONTSWAP Otherwise it looks OK to me. Would you like me to queue it up for 3.1-rc7? _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel From xen-devel-bounces@lists.xensource.com Mon Sep 26 10:25:21 2011 Return-path: <xen-devel-bounces@lists.xensource.com> Envelope-to: www-data@lists.xensource.com Delivery-date: Mon, 26 Sep 2011 10:25:21 -0700 Received: from localhost ([127.0.0.1] helo=lists.colo.xensource.com) by lists.xensource.com with esmtp (Exim 4.43) id 1R8Evg-0002Qq-UG; Mon, 26 Sep 2011 10:25:20 -0700 Received: from mail174.messagelabs.com ([85.158.138.51]) by lists.xensource.com with esmtp (Exim 4.43) id 1R8EvF-0002EX-2x for xen-devel@lists.xensource.com; Mon, 26 Sep 2011 10:24:53 -0700 X-Env-Sender: Ian.Jackson@eu.citrix.com X-Msg-Ref: server-9.tower-174.messagelabs.com!1317057889!26792134!1 X-Originating-IP: [62.200.22.115] X-StarScan-Version: 6.4.1; banners=-,-,- X-VirusChecked: Checked Received: (qmail 17526 invoked from network); 26 Sep 2011 17:24:50 -0000 Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115) by server-9.tower-174.messagelabs.com with RC4-SHA encrypted SMTP; 26 Sep 2011 17:24:50 -0000 X-IronPort-AV: E=Sophos;i="4.68,445,1312156800"; d="scan'208";a="8067534" Received: from lonpmailmx01.citrite.net ([10.30.203.162]) by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5; 26 Sep 2011 17:24:49 +0000 Received: from woking.xci-test.com (10.80.248.135) by smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id 8.3.137.0; Mon, 26 Sep 2011 18:24:49 +0100 Received: from osstest by woking.xci-test.com with local (Exim 4.69) (envelope-from <ian.jackson@eu.citrix.com>) id 1R8EvA-0006ag-Ty; Mon, 26 Sep 2011 18:24:48 +0100 To: xen-devel@lists.xensource.com Message-ID: <osstest-9088-mainreport@xen.org> From: xen.org <ian.jackson@eu.citrix.com> Date: Mon, 26 Sep 2011 18:24:48 +0100 MIME-Version: 1.0 Content-Type: text/plain Cc: ian.jackson@eu.citrix.com Subject: [Xen-devel] [linux test] 9088: tolerable FAIL X-BeenThere: xen-devel@lists.xensource.com X-Mailman-Version: 2.1.5 Precedence: list List-Id: Xen developer discussion <xen-devel.lists.xensource.com> List-Unsubscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe> List-Post: <mailto:xen-devel@lists.xensource.com> List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help> List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=subscribe> Sender: xen-devel-bounces@lists.xensource.com Errors-To: xen-devel-bounces@lists.xensource.com flight 9088 linux real [real] http://www.chiark.greenend.org.uk/~xensrcts/logs/9088/ Failures :-/ but no regressions. Tests which are failing intermittently (not blocking): test-amd64-amd64-xl-sedf 14 guest-localmigrate/x10 fail pass in 9084 Tests which did not succeed, but are not blocking, including regressions (tests previously passed) regarded as allowable: test-amd64-amd64-xl-pcipt-intel 9 guest-start fail never pass test-amd64-i386-rhel6hvm-amd 9 guest-start.2 fail never pass test-amd64-i386-rhel6hvm-intel 9 guest-start.2 fail never pass test-amd64-i386-win-vcpus1 16 leak-check/check fail never pass test-amd64-i386-xl-win-vcpus1 13 guest-stop fail never pass test-amd64-amd64-win 16 leak-check/check fail never pass test-amd64-amd64-xl-win 13 guest-stop fail never pass test-i386-i386-win 16 leak-check/check fail never pass test-i386-i386-xl-win 13 guest-stop fail never pass test-amd64-i386-win 16 leak-check/check fail never pass version targeted for testing: linux 6bec8b4a4c14095d0b7ce424db9d583c3decae6c baseline version: linux 1c3f03ccc5258887f5f2cafc0836a865834f9205 ------------------------------------------------------------ People who touched revisions under test: Jeremy Fitzhardinge <jeremy.fitzhardinge@citrix.com> ------------------------------------------------------------ jobs: build-amd64 pass build-i386 pass build-amd64-pvops pass build-i386-pvops pass test-amd64-amd64-xl pass test-amd64-i386-xl pass test-i386-i386-xl pass test-amd64-i386-rhel6hvm-amd fail test-amd64-i386-xl-credit2 pass test-amd64-amd64-xl-pcipt-intel fail test-amd64-i386-rhel6hvm-intel fail test-amd64-i386-xl-multivcpu pass test-amd64-amd64-pair pass test-amd64-i386-pair pass test-i386-i386-pair pass test-amd64-amd64-pv pass test-amd64-i386-pv pass test-i386-i386-pv pass test-amd64-amd64-xl-sedf fail test-amd64-i386-win-vcpus1 fail test-amd64-i386-xl-win-vcpus1 fail test-amd64-amd64-win fail test-amd64-i386-win fail test-i386-i386-win fail test-amd64-amd64-xl-win fail test-i386-i386-xl-win fail ------------------------------------------------------------ sg-report-flight on woking.cam.xci-test.com logs: /home/xc_osstest/logs images: /home/xc_osstest/images Logs, config files, etc. are available at http://www.chiark.greenend.org.uk/~xensrcts/logs Test harness code can be found at http://xenbits.xensource.com/gitweb?p=osstest.git;a=summary Pushing revision : + branch=linux + revision=6bec8b4a4c14095d0b7ce424db9d583c3decae6c + . cri-lock-repos ++ . cri-common +++ umask 002 +++ getconfig Repos +++ perl -e ' use Osstest; readconfigonly(); print $c{Repos} or die $!; ' ++ repos=/export/home/osstest/repos ++ repos_lock=/export/home/osstest/repos/lock ++ '[' x '!=' x/export/home/osstest/repos/lock ']' ++ OSSTEST_REPOS_LOCK_LOCKED=/export/home/osstest/repos/lock ++ exec with-lock-ex -w /export/home/osstest/repos/lock ./ap-push linux 6bec8b4a4c14095d0b7ce424db9d583c3decae6c + branch=linux + revision=6bec8b4a4c14095d0b7ce424db9d583c3decae6c + . cri-lock-repos ++ . cri-common +++ umask 002 +++ getconfig Repos +++ perl -e ' use Osstest; readconfigonly(); print $c{Repos} or die $!; ' ++ repos=/export/home/osstest/repos ++ repos_lock=/export/home/osstest/repos/lock ++ '[' x/export/home/osstest/repos/lock '!=' x/export/home/osstest/repos/lock ']' + : xen@xenbits.xensource.com + : xen@xenbits.xensource.com:git/linux-pvops + : master + : tested/2.6.39.x + case "$branch" in + cd /export/home/osstest/repos/xen ./ap-push: line 20: cd: /export/home/osstest/repos/xen: No such file or directory ------------------------------------------------------------ commit 6bec8b4a4c14095d0b7ce424db9d583c3decae6c Author: Jeremy Fitzhardinge <jeremy.fitzhardinge@citrix.com> Date: Fri Sep 2 12:23:22 2011 -0700 Revert "xen/apic: Provide an 'apic_xen' to set the override the apic->[read|write] for all cases." This reverts commit c3dd7941354fa96a71f2613e2c7a1b215fa175dc. It prevents the kernel from booting natively on hardware. Conflicts: arch/x86/xen/enlighten.c Signed-off-by: Jeremy Fitzhardinge <jeremy.fitzhardinge@citrix.com> _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel From xen-users-bounces@lists.xensource.com Mon Sep 26 10:27:11 2011 Return-path: <xen-users-bounces@lists.xensource.com> Envelope-to: www-data@lists.xensource.com Delivery-date: Mon, 26 Sep 2011 10:27:11 -0700 Received: from localhost ([127.0.0.1] helo=lists.colo.xensource.com) by lists.xensource.com with esmtp (Exim 4.43) id 1R8ExT-0002w5-8N; Mon, 26 Sep 2011 10:27:11 -0700 Received: from mail27.messagelabs.com ([193.109.254.147]) by lists.xensource.com with esmtp (Exim 4.43) id 1R8EvL-0002Ff-22; Mon, 26 Sep 2011 10:25:00 -0700 X-Env-Sender: shriganeshs@gmail.com X-Msg-Ref: server-14.tower-27.messagelabs.com!1317057878!37706229!1 X-Originating-IP: [209.85.210.49] X-StarScan-Version: 6.4.1; banners=-,-,- X-VirusChecked: Checked Received: (qmail 24303 invoked from network); 26 Sep 2011 17:24:40 -0000 Received: from mail-pz0-f49.google.com (HELO mail-pz0-f49.google.com) (209.85.210.49) by server-14.tower-27.messagelabs.com with RC4-SHA encrypted SMTP; 26 Sep 2011 17:24:40 -0000 Received: by pzk34 with SMTP id 34so15500580pzk.8 for <multiple recipients>; Mon, 26 Sep 2011 10:24:53 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:date:message-id:subject:from:to:content-type; bh=TxA9z/DQV/AKzZuruR1VGwGJ/ubam0utHp9HQ8I1frk=; b=AZx/Vje6PiS7ifj6AvRwFZvehEhmLBRtaGQR59StOLuz8HE7xQ0/VcMnls2ChvwGpw b6nHRI078SWrEZv6I117ZJaNJY0912g1AwfgAziHTU5VQHMVy6h29LmH7jz0xuryXXNU 6mJOEW20lCFRYzwNzw1bkiKKqEVjfkztspwqU= MIME-Version: 1.0 Received: by 10.68.33.163 with SMTP id s3mr29186081pbi.10.1317057893250; Mon, 26 Sep 2011 10:24:53 -0700 (PDT) Received: by 10.142.155.16 with HTTP; Mon, 26 Sep 2011 10:24:53 -0700 (PDT) Date: Mon, 26 Sep 2011 10:24:53 -0700 Message-ID: <CAM3t-NPZmFnCdv0T=-54Ff0YNeKD+XaUq5-+h8icz5K3mKNkUA@mail.gmail.com> From: Shriganesh Shintre <shriganeshs@gmail.com> To: Xen-users@lists.xensource.com, xen-devel@lists.xensource.com Cc: Subject: [Xen-users] warning trace while starting domU X-BeenThere: xen-users@lists.xensource.com X-Mailman-Version: 2.1.5 Precedence: list List-Id: Xen user discussion <xen-users.lists.xensource.com> List-Unsubscribe: <http://lists.xensource.com/mailman/listinfo/xen-users>, <mailto:xen-users-request@lists.xensource.com?subject=unsubscribe> List-Post: <mailto:xen-users@lists.xensource.com> List-Help: <mailto:xen-users-request@lists.xensource.com?subject=help> List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-users>, <mailto:xen-users-request@lists.xensource.com?subject=subscribe> Content-Type: multipart/mixed; boundary="===============0220063547==" Sender: xen-users-bounces@lists.xensource.com Errors-To: xen-users-bounces@lists.xensource.com --===============0220063547== Content-Type: multipart/alternative; boundary=bcaec520ecd3e0362004addb6fb1 --bcaec520ecd3e0362004addb6fb1 Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable Environment: Xen 4.1.1 with Linux 3.0.4 kernel (compiled with DEBUG enabled= ) I am chasing the warning trace while starting domU. Trace is as follows Sep 12 22:18:58 ucs-xen24-srv1 kernel: ------------[ cut here ]------------ Sep 12 22:18:58 ucs-xen24-srv1 kernel: WARNING: at arch/x86/xen/mmu.c:486 xen_make_pte_debug+0xdb/0x187() Sep 12 22:18:58 ucs-xen24-srv1 kernel: Hardware name: N20-B6625-1 Sep 12 22:18:58 ucs-xen24-srv1 kernel: 0xec0f1000 is using VM_IO, but it is 0xfffff000! Sep 12 22:18:58 ucs-xen24-srv1 kernel: Modules linked in: veth raid1 vnp iptable_filter ip_tables bridge stp ipmi_si ipmi_devintf ipmi_msghandler nb= d hoop bonding xt_tcpudp x_tables ipv6 xenfs loop dm_mirror dm_region_hash dm_log dm_multipath scsi_dh dm_mod thermal fan parport nvram sg ub enic acpi_power_meter hwmon 8250_pnp button 8250 i2c_i801 ehci_hcd serial_core ioatdma i2c_core iTCO_wdt iTCO_vendor_support uhci_hcd dca pcspkr mptsas mptscsih mptbase scsi_transport_sas sd_mod scsi_mod ext3 jbd mbcache [last unloaded: ip_tables] Sep 12 22:18:58 ucs-xen24-srv1 kernel: Pid: 16534, comm: xend Tainted: G W 3.0.1-11.xen0 #1 Sep 12 22:18:58 ucs-xen24-srv1 kernel: Call Trace: Sep 12 22:18:58 ucs-xen24-srv1 kernel: [<c100647f>] ? xen_make_pte_debug+0xdb/0x187 Sep 12 22:18:58 ucs-xen24-srv1 kernel: [<c10351e0>] warn_slowpath_common+0x76/0x8b Sep 12 22:18:58 ucs-xen24-srv1 kernel: [<c100647f>] ? xen_make_pte_debug+0xdb/0x187 Sep 12 22:18:58 ucs-xen24-srv1 kernel: [<c1035271>] warn_slowpath_fmt+0x2e/0x30 Sep 12 22:18:58 ucs-xen24-srv1 kernel: [<c100647f>] xen_make_pte_debug+0xdb/0x187 Sep 12 22:18:58 ucs-xen24-srv1 kernel: [<c100466e>] __raw_callee_save_xen_make_pte_debug+0x6/0x8 Sep 12 22:18:59 ucs-xen24-srv1 kernel: [<c1004db9>] ? remap_area_mfn_pte_fn+0x60/0xf7 Sep 12 22:18:59 ucs-xen24-srv1 kernel: [<c10842b9>] apply_to_page_range+0x1fe/0x307 Sep 12 22:18:59 ucs-xen24-srv1 kernel: [<c100514c>] xen_remap_domain_mfn_range+0xd3/0x107 Sep 12 22:18:59 ucs-xen24-srv1 logger: /etc/xen/scripts/block: add XENBUS_PATH=3Dbackend/vbd/1/768 Sep 12 22:18:59 ucs-xen24-srv1 logger: /etc/xen/scripts/block: add XENBUS_PATH=3Dbackend/vbd/1/832 Sep 12 22:18:59 ucs-xen24-srv1 kernel: [<c1004d59>] ? xen_make_pte+0x113/0x113 Sep 12 22:18:59 ucs-xen24-srv1 logger: /etc/xen/scripts/block: add XENBUS_PATH=3Dbackend/vbd/1/5632 Sep 12 22:18:59 ucs-xen24-srv1 logger: /etc/xen/scripts/block: add XENBUS_PATH=3Dbackend/vbd/1/5696 Sep 12 22:18:59 ucs-xen24-srv1 VRM: TP_SKT.c(1193): m_skt_connect(): Failed to connect to remote host, err=3DNo route to host, 113 Sep 12 22:18:59 ucs-xen24-srv1 kernel: [<c1007097>] ? xen_restore_fl_direct_reloc+0x4/0x4 Sep 12 22:19:00 ucs-xen24-srv1 kernel: [<c1005352>] ? xen_flush_tlb+0x5f/0x6c Sep 12 22:19:00 ucs-xen24-srv1 kernel: [<c1024766>] ? kernel_map_pages+0xab/0x104 Sep 12 22:19:00 ucs-xen24-srv1 kernel: [<c107288d>] ? get_page_from_freelist+0x255/0x39c Sep 12 22:19:00 ucs-xen24-srv1 kernel: [<c10044a5>] ? xen_mc_flush+0x101/0x1b6 Sep 12 22:19:00 ucs-xen24-srv1 kernel: [<c1072b9e>] ? __alloc_pages_nodemask+0xd9/0x561 Sep 12 22:19:00 ucs-xen24-srv1 kernel: [<c10823eb>] ? do_wp_page+0x348/0x879 Sep 12 22:19:00 ucs-xen24-srv1 kernel: [<f818909b>] mmap_batch_fn+0x3c/0x5= b [xenfs] Sep 12 22:19:00 ucs-xen24-srv1 kernel: [<f8188c53>] traverse_pages+0x75/0x89 [xenfs] Sep 12 22:19:00 ucs-xen24-srv1 kernel: [<f8189022>] privcmd_ioctl+0x2ad/0x2ea [xenfs] Sep 12 22:19:00 ucs-xen24-srv1 kernel: [<f818905f>] ? privcmd_ioctl+0x2ea/0x2ea [xenfs] Sep 12 22:19:00 ucs-xen24-srv1 kernel: [<c10884a7>] ? vma_link+0x4f/0x8d Sep 12 22:19:00 ucs-xen24-srv1 kernel: [<f8188d75>] ? free_page_list+0x3b/0x3b [xenfs] Sep 12 22:19:00 ucs-xen24-srv1 kernel: [<c10a4734>] vfs_ioctl+0x24/0x37 Sep 12 22:19:00 ucs-xen24-srv1 kernel: [<c10a48a5>] do_vfs_ioctl+0x8a/0x4d= f Sep 12 22:19:00 ucs-xen24-srv1 kernel: [<c1089284>] ? sys_brk+0x101/0x101 Sep 12 22:19:00 ucs-xen24-srv1 kernel: [<c1089011>] ? do_mmap_pgoff+0x2bb/0x2df Sep 12 22:19:00 ucs-xen24-srv1 kernel: [<c10a4d2d>] sys_ioctl+0x33/0x57 Sep 12 22:19:00 ucs-xen24-srv1 kernel: [<c1251d9c>] sysenter_do_call+0x12/0x2c Sep 12 22:19:00 ucs-xen24-srv1 kernel: ---[ end trace 4eaa2a86a8e2da26 ]--- Following is the code from where the trace is coming. It=92s clear from the code that this warning trace is observed only when the debug kernel is used= . Also warning appears only once (WARN_ONCE) while starting first domU. File: linux-3.0.4/arch/x86/xen/mmu.c #ifdef CONFIG_XEN_DEBUG pte_t xen_make_pte_debug(pteval_t pte) { phys_addr_t addr =3D (pte & PTE_PFN_MASK); phys_addr_t other_addr; bool io_page =3D false; pte_t _pte; if (pte & _PAGE_IOMAP) io_page =3D true; _pte =3D xen_make_pte(pte); if (!addr) return _pte; * if (io_page && * * (xen_initial_domain() || addr >=3D ISA_END_ADDRESS)) {* * other_addr =3D pfn_to_mfn(addr >> PAGE_SHIFT) << PAGE_SHIF= T;* * WARN_ONCE(addr !=3D other_addr,* * "0x%lx is using VM_IO, but it is 0x%lx!\n",* * (unsigned long)addr, (unsigned long)other_addr);* } else { pteval_t iomap_set =3D (_pte.pte & PTE_FLAGS_MASK) & _PAGE_IOMAP; other_addr =3D (_pte.pte & PTE_PFN_MASK); WARN_ONCE((addr =3D=3D other_addr) && (!io_page) && (!iomap_set), "0x%lx is missing VM_IO (and wasn't fixed)!\n", (unsigned long)addr); } return _pte; } PV_CALLEE_SAVE_REGS_THUNK(xen_make_pte_debug); #endif When googled, I found this link http://www.gossamer-threads.com/lists/xen/devel/217630, but could not find the patch he is talking about. Could you please help me resolving this warning? or provide me more pointer= s and direction for debugging. Thank you in advance. ~Shri --bcaec520ecd3e0362004addb6fb1 Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: quoted-printable <p class=3D"MsoNormal">Environment: Xen 4.1.1 with Linux 3.0.4 kernel (comp= iled with DEBUG enabled)<br></p><p class=3D"MsoNormal">I am chasing the war= ning trace while starting domU. Trace is as follows</p><p class=3D"MsoNorma= l"> <br>Sep 12 22:18:58 ucs-xen24-srv1 kernel: ------------[ cut here ]--------= ----<br>Sep 12 22:18:58 ucs-xen24-srv1 kernel: WARNING: at arch/x86/xen/mmu= .c:486 xen_make_pte_debug+0xdb/0x187()<br>Sep 12 22:18:58 ucs-xen24-srv1 ke= rnel: Hardware name: N20-B6625-1<br> Sep 12 22:18:58 ucs-xen24-srv1 kernel: 0xec0f1000 is using VM_IO, but it is= 0xfffff000!<br>Sep 12 22:18:58 ucs-xen24-srv1 kernel: Modules linked in: v= eth raid1 vnp iptable_filter ip_tables bridge stp ipmi_si ipmi_devintf ipmi= _msghandler nbd hoop bonding xt_tcpudp x_tables ipv6 xenfs loop dm_mirror d= m_region_hash dm_log dm_multipath scsi_dh dm_mod thermal fan parport nvram = sg ub enic acpi_power_meter hwmon 8250_pnp button 8250 i2c_i801 ehci_hcd se= rial_core ioatdma i2c_core iTCO_wdt iTCO_vendor_support uhci_hcd dca pcspkr= mptsas mptscsih mptbase scsi_transport_sas sd_mod scsi_mod ext3 jbd mbcach= e [last unloaded: ip_tables]<br> Sep 12 22:18:58 ucs-xen24-srv1 kernel: Pid: 16534, comm: xend Tainted: G=A0= =A0=A0=A0=A0=A0=A0 W=A0=A0 3.0.1-11.xen0 #1<br>Sep 12 22:18:58 ucs-xen24-sr= v1 kernel: Call Trace:<br>Sep 12 22:18:58 ucs-xen24-srv1 kernel:=A0 [<c1= 00647f>] ? xen_make_pte_debug+0xdb/0x187<br> Sep 12 22:18:58 ucs-xen24-srv1 kernel:=A0 [<c10351e0>] warn_slowpath_= common+0x76/0x8b<br>Sep 12 22:18:58 ucs-xen24-srv1 kernel:=A0 [<c100647f= >] ? xen_make_pte_debug+0xdb/0x187<br>Sep 12 22:18:58 ucs-xen24-srv1 ker= nel:=A0 [<c1035271>] warn_slowpath_fmt+0x2e/0x30<br> Sep 12 22:18:58 ucs-xen24-srv1 kernel:=A0 [<c100647f>] xen_make_pte_d= ebug+0xdb/0x187<br>Sep 12 22:18:58 ucs-xen24-srv1 kernel:=A0 [<c100466e&= gt;] __raw_callee_save_xen_make_pte_debug+0x6/0x8<br>Sep 12 22:18:59 ucs-xe= n24-srv1 kernel:=A0 [<c1004db9>] ? remap_area_mfn_pte_fn+0x60/0xf7<br= > Sep 12 22:18:59 ucs-xen24-srv1 kernel:=A0 [<c10842b9>] apply_to_page_= range+0x1fe/0x307<br>Sep 12 22:18:59 ucs-xen24-srv1 kernel:=A0 [<c100514= c>] xen_remap_domain_mfn_range+0xd3/0x107<br>Sep 12 22:18:59 ucs-xen24-s= rv1 logger: /etc/xen/scripts/block: add XENBUS_PATH=3Dbackend/vbd/1/768<br> Sep 12 22:18:59 ucs-xen24-srv1 logger: /etc/xen/scripts/block: add XENBUS_P= ATH=3Dbackend/vbd/1/832<br>Sep 12 22:18:59 ucs-xen24-srv1 kernel:=A0 [<c= 1004d59>] ? xen_make_pte+0x113/0x113<br>Sep 12 22:18:59 ucs-xen24-srv1 l= ogger: /etc/xen/scripts/block: add XENBUS_PATH=3Dbackend/vbd/1/5632<br> Sep 12 22:18:59 ucs-xen24-srv1 logger: /etc/xen/scripts/block: add XENBUS_P= ATH=3Dbackend/vbd/1/5696<br>Sep 12 22:18:59 ucs-xen24-srv1 VRM: TP_SKT.c(11= 93): m_skt_connect(): Failed to connect to remote host, err=3DNo route to h= ost, 113<br> Sep 12 22:18:59 ucs-xen24-srv1 kernel:=A0 [<c1007097>] ? xen_restore_= fl_direct_reloc+0x4/0x4<br>Sep 12 22:19:00 ucs-xen24-srv1 kernel:=A0 [<c= 1005352>] ? xen_flush_tlb+0x5f/0x6c<br>Sep 12 22:19:00 ucs-xen24-srv1 ke= rnel:=A0 [<c1024766>] ? kernel_map_pages+0xab/0x104<br> Sep 12 22:19:00 ucs-xen24-srv1 kernel:=A0 [<c107288d>] ? get_page_fro= m_freelist+0x255/0x39c<br>Sep 12 22:19:00 ucs-xen24-srv1 kernel:=A0 [<c1= 0044a5>] ? xen_mc_flush+0x101/0x1b6<br>Sep 12 22:19:00 ucs-xen24-srv1 ke= rnel:=A0 [<c1072b9e>] ? __alloc_pages_nodemask+0xd9/0x561<br> Sep 12 22:19:00 ucs-xen24-srv1 kernel:=A0 [<c10823eb>] ? do_wp_page+0= x348/0x879<br>Sep 12 22:19:00 ucs-xen24-srv1 kernel:=A0 [<f818909b>] = mmap_batch_fn+0x3c/0x5b [xenfs]<br>Sep 12 22:19:00 ucs-xen24-srv1 kernel:= =A0 [<f8188c53>] traverse_pages+0x75/0x89 [xenfs]<br> Sep 12 22:19:00 ucs-xen24-srv1 kernel:=A0 [<f8189022>] privcmd_ioctl+= 0x2ad/0x2ea [xenfs]<br>Sep 12 22:19:00 ucs-xen24-srv1 kernel:=A0 [<f8189= 05f>] ? privcmd_ioctl+0x2ea/0x2ea [xenfs]<br>Sep 12 22:19:00 ucs-xen24-s= rv1 kernel:=A0 [<c10884a7>] ? vma_link+0x4f/0x8d<br> Sep 12 22:19:00 ucs-xen24-srv1 kernel:=A0 [<f8188d75>] ? free_page_li= st+0x3b/0x3b [xenfs]<br>Sep 12 22:19:00 ucs-xen24-srv1 kernel:=A0 [<c10a= 4734>] vfs_ioctl+0x24/0x37<br>Sep 12 22:19:00 ucs-xen24-srv1 kernel:=A0 = [<c10a48a5>] do_vfs_ioctl+0x8a/0x4df<br> Sep 12 22:19:00 ucs-xen24-srv1 kernel:=A0 [<c1089284>] ? sys_brk+0x10= 1/0x101<br>Sep 12 22:19:00 ucs-xen24-srv1 kernel:=A0 [<c1089011>] ? d= o_mmap_pgoff+0x2bb/0x2df<br>Sep 12 22:19:00 ucs-xen24-srv1 kernel:=A0 [<= c10a4d2d>] sys_ioctl+0x33/0x57<br> Sep 12 22:19:00 ucs-xen24-srv1 kernel:=A0 [<c1251d9c>] sysenter_do_ca= ll+0x12/0x2c<br>Sep 12 22:19:00 ucs-xen24-srv1 kernel: ---[ end trace 4eaa2= a86a8e2da26 ]---<br><br> </p> <p class=3D"MsoNormal">=A0</p> <p class=3D"MsoNormal">Following is the code from where the trace is coming= . It=92s clear from the code that this warning trace is observed only when the debug kernel is used. Also warning appears only once (WARN_ONCE) while starting f= irst domU.</p>=A0 <p class=3D"MsoNormal">File: linux-3.0.4/arch/x86/xen/mmu.c</p> <p class=3D"MsoNormal">#ifdef CONFIG_XEN_DEBUG</p> <p class=3D"MsoNormal">pte_t xen_make_pte_debug(pteval_t pte)</p> <p class=3D"MsoNormal">{</p> <p class=3D"MsoNormal">=A0=A0=A0=A0=A0=A0=A0 phys_addr_t addr =3D (pte & PTE_PFN_MASK);</p> <p class=3D"MsoNormal">=A0=A0=A0=A0=A0=A0=A0 phys_addr_t other_addr;</p> <p class=3D"MsoNormal">=A0=A0=A0=A0=A0=A0=A0 bool io_page =3D false;</p> <p class=3D"MsoNormal">=A0=A0=A0=A0=A0=A0=A0 pte_t _pte;</p> <p class=3D"MsoNormal">=A0</p> <p class=3D"MsoNormal">=A0=A0=A0=A0=A0=A0=A0 if (pte & _PAGE_IOMAP)</p> <p class=3D"MsoNormal">=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 io_page =3D true;</p> <p class=3D"MsoNormal">=A0</p> <p class=3D"MsoNormal">=A0=A0=A0=A0=A0=A0=A0 _pte =3D xen_make_pte(pte);</p> <p class=3D"MsoNormal">=A0</p> <p class=3D"MsoNormal">=A0=A0=A0=A0=A0=A0=A0 if (!addr)</p> <p class=3D"MsoNormal">=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 return _pte;</p> <p class=3D"MsoNormal">=A0</p> <p class=3D"MsoNormal"><b>=A0=A0=A0=A0=A0=A0=A0 if (io_page &&=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0= =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0= =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 </b></p> <p class=3D"MsoNormal"><b>=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 (xen_initial_domain() || addr >=3D ISA_END_ADDRESS)) {</b></p> <p class=3D"MsoNormal"><b>=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 other_addr =3D pfn_to_mfn(addr >> PAGE_SHIFT) << PAGE_SHIFT;</b= ></p> <p class=3D"MsoNormal"><b>=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 WARN_ONCE(addr !=3D other_addr,</b></p> <p class=3D"MsoNormal"><b>=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0= =A0=A0=A0=A0=A0=A0=A0 "0x%lx is using VM_IO, but it is 0x%lx!\n",</b></p> <p class=3D"MsoNormal"><b>=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0= =A0=A0=A0=A0=A0=A0=A0 (unsigned long)addr, (unsigned long)other_addr);</b></p> <p class=3D"MsoNormal">=A0=A0=A0=A0=A0=A0=A0 } else {</p> <p class=3D"MsoNormal">=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 pteval_t iomap_set =3D (_pte.pte & PTE_FLAGS_MASK) & _PAGE_IOMAP;</= p> <p class=3D"MsoNormal">=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 other_addr =3D (_pte.pte & PTE_PFN_MASK);</p> <p class=3D"MsoNormal">=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 WARN_ONCE((addr =3D=3D other_addr) && (!io_page) && (!iomap= _set),</p> <p class=3D"MsoNormal">=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0= =A0 =A0=A0=A0=A0=A0"0x%lx is missing VM_IO (and wasn't fixed)!\n",</p> <p class=3D"MsoNormal">=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0= =A0=A0=A0=A0=A0=A0 (unsigned long)addr);</p> <p class=3D"MsoNormal">=A0=A0=A0=A0=A0=A0=A0 }</p> <p class=3D"MsoNormal">=A0</p> <p class=3D"MsoNormal">=A0=A0=A0=A0=A0=A0=A0 return _pte;</p> <p class=3D"MsoNormal">}</p> <p class=3D"MsoNormal">PV_CALLEE_SAVE_REGS_THUNK(xen_make_pte_debug);</p> <p class=3D"MsoNormal">#endif</p><p class=3D"MsoNormal"><br></p><p class=3D= "MsoNormal"><br></p><p class=3D"MsoNormal">When googled, I found this link = <a href=3D"http://www.gossamer-threads.com/lists/xen/devel/217630">http://w= ww.gossamer-threads.com/lists/xen/devel/217630</a>, but could not find the = patch he is talking about.</p> <p class=3D"MsoNormal"><br></p><p class=3D"MsoNormal">Could you please help= me resolving this warning? or provide me more pointers and direction for d= ebugging. Thank you in advance.<br></p><p class=3D"MsoNormal"><br></p><p cl= ass=3D"MsoNormal"> ~Shri<br></p> --bcaec520ecd3e0362004addb6fb1-- --===============0220063547== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Xen-users mailing list Xen-users@lists.xensource.com http://lists.xensource.com/xen-users --===============0220063547==-- From xen-devel-bounces@lists.xensource.com Mon Sep 26 10:29:48 2011 Return-path: <xen-devel-bounces@lists.xensource.com> Envelope-to: www-data@lists.xensource.com Delivery-date: Mon, 26 Sep 2011 10:29:48 -0700 Received: from localhost ([127.0.0.1] helo=lists.colo.xensource.com) by lists.xensource.com with esmtp (Exim 4.43) id 1R8Ezz-0003rJ-VK; Mon, 26 Sep 2011 10:29:48 -0700 Received: from mail27.messagelabs.com ([193.109.254.147]) by lists.xensource.com with esmtp (Exim 4.43) id 1R8Evf-0002Q4-Q6 for xen-devel@lists.xensource.com; Mon, 26 Sep 2011 10:25:20 -0700 X-Env-Sender: dan.magenheimer@oracle.com X-Msg-Ref: server-4.tower-27.messagelabs.com!1317057896!41833908!1 X-Originating-IP: [141.146.126.227] X-StarScan-Version: 6.4.1; banners=-,-,- X-VirusChecked: Checked Received: (qmail 6990 invoked from network); 26 Sep 2011 17:24:57 -0000 Received: from acsinet15.oracle.com (HELO acsinet15.oracle.com) (141.146.126.227) by server-4.tower-27.messagelabs.com with DHE-RSA-AES256-SHA encrypted SMTP; 26 Sep 2011 17:24:57 -0000 Received: from acsinet21.oracle.com (acsinet21.oracle.com [141.146.126.237]) by acsinet15.oracle.com (Switch-3.4.4/Switch-3.4.4) with ESMTP id p8QHPB5b025251 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Mon, 26 Sep 2011 17:25:13 GMT Received: from acsmt356.oracle.com (acsmt356.oracle.com [141.146.40.156]) by acsinet21.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id p8QHPBeT001932 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 26 Sep 2011 17:25:11 GMT Received: from abhmt103.oracle.com (abhmt103.oracle.com [141.146.116.55]) by acsmt356.oracle.com (8.12.11.20060308/8.12.11) with ESMTP id p8QHP5Lg001131; Mon, 26 Sep 2011 12:25:05 -0500 MIME-Version: 1.0 Message-ID: <827ee42e-14e5-468c-b8a2-a24baa251b2d@default> Date: Mon, 26 Sep 2011 10:24:45 -0700 (PDT) From: Dan Magenheimer <dan.magenheimer@oracle.com> To: Konrad Wilk <konrad.wilk@oracle.com> References: <9827a70d-dfb2-4bbc-9df6-207b10c835ac@default 20110926172307.GA9973@phenom.oracle.com> In-Reply-To: <20110926172307.GA9973@phenom.oracle.com> X-Priority: 3 X-Mailer: Oracle Beehive Extensions for Outlook 2.0.1.4.1.0 (410211) [OL 12.0.6557.5001] Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable X-Source-IP: acsinet21.oracle.com [141.146.126.237] X-Auth-Type: Internal IP X-CT-RefId: str=0001.0A090208.4E80B579.00AB:SCFMA922111,ss=1,re=-4.000,fgs=0 Cc: Jeremy Fitzhardinge <jeremy@goop.org>, xen-devel@lists.xensource.com, linux-kernel@vger.kernel.org, David Vrabel <david.vrabel@citrix.com> Subject: [Xen-devel] RE: [PATCH] xen: Fix selfballooning and ensure it doesn't go too far X-BeenThere: xen-devel@lists.xensource.com X-Mailman-Version: 2.1.5 Precedence: list List-Id: Xen developer discussion <xen-devel.lists.xensource.com> List-Unsubscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe> List-Post: <mailto:xen-devel@lists.xensource.com> List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help> List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=subscribe> Sender: xen-devel-bounces@lists.xensource.com Errors-To: xen-devel-bounces@lists.xensource.com > From: Konrad Rzeszutek Wilk > Sent: Monday, September 26, 2011 11:23 AM > To: Dan Magenheimer > Cc: linux-kernel@vger.kernel.org; xen-devel@lists.xensource.com; David Vr= abel; Jeremy Fitzhardinge > Subject: Re: [PATCH] xen: Fix selfballooning and ensure it doesn't go too= far >=20 > On Sat, Sep 24, 2011 at 01:58:08PM -0700, Dan Magenheimer wrote: > > [PATCH] xen: Fix selfballooning and ensure it doesn't go too far > > > > The balloon driver's "current_pages" is very different from > > totalram_pages. Self-ballooning needs to be driven by > > the latter. Also, Committed_AS doesn't account for pages > > used by the kernel so enforce a floor for when there > > are little or no user-space threads using memory. >=20 > Hey Dan, > .. > > +=09=09floor_pages =3D totalreserve_pages + > > +=09=09=09=09(roundup_pow_of_two(max_pfn) >> 5); >=20 > Would it make sense to make the shift be a runtime argument > in case some users report problems with that calculation? Good idea. I'll take a look at that. > > +=09=09/* don't balloon too far, lest OOMs occur... */ > > +=09=09if (tgt_pages < floor_pages) > > +=09=09=09tgt_pages =3D floor_pages; > > +=09=09balloon_set_new_target(tgt_pages + > > +=09=09=09balloon_stats.current_pages - totalram_pages); > > =09=09reset_timer =3D true; > > =09} > > #ifdef CONFIG_FRONTSWAP >=20 > Otherwise it looks OK to me. Would you like me to queue it up > for 3.1-rc7? Will let you know when I have that change done/tested. Thanks, Dan _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel From xen-users-bounces@lists.xensource.com Mon Sep 26 11:07:33 2011 Return-path: <xen-users-bounces@lists.xensource.com> Envelope-to: www-data@lists.xensource.com Delivery-date: Mon, 26 Sep 2011 11:07:33 -0700 Received: from localhost ([127.0.0.1] helo=lists.colo.xensource.com) by lists.xensource.com with esmtp (Exim 4.43) id 1R8FaW-0007CN-Gy; Mon, 26 Sep 2011 11:07:32 -0700 Received: from mail182.messagelabs.com ([85.158.139.83]) by lists.xensource.com with esmtp (Exim 4.43) id 1R8FYq-0006rk-Hs; Mon, 26 Sep 2011 11:05:51 -0700 X-Env-Sender: konrad@oracle.com X-Msg-Ref: server-8.tower-182.messagelabs.com!1317060343!18629408!1 X-Originating-IP: [148.87.113.117] X-StarScan-Version: 6.4.1; banners=-,-,- X-VirusChecked: Checked Received: (qmail 32027 invoked from network); 26 Sep 2011 18:05:45 -0000 Received: from rcsinet15.oracle.com (HELO rcsinet15.oracle.com) (148.87.113.117) by server-8.tower-182.messagelabs.com with DHE-RSA-AES256-SHA encrypted SMTP; 26 Sep 2011 18:05:45 -0000 Received: from rtcsinet22.oracle.com (rtcsinet22.oracle.com [66.248.204.30]) by rcsinet15.oracle.com (Switch-3.4.4/Switch-3.4.4) with ESMTP id p8QI5eHg030489 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Mon, 26 Sep 2011 18:05:42 GMT Received: from acsmt357.oracle.com (acsmt357.oracle.com [141.146.40.157]) by rtcsinet22.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id p8QI5dR8023429 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 26 Sep 2011 18:05:40 GMT Received: from abhmt108.oracle.com (abhmt108.oracle.com [141.146.116.60]) by acsmt357.oracle.com (8.12.11.20060308/8.12.11) with ESMTP id p8QI5XUA008705; Mon, 26 Sep 2011 13:05:33 -0500 Received: from oracle.com (/209.6.55.207) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Mon, 26 Sep 2011 11:05:33 -0700 Received: by oracle.com (Postfix, from userid 1000) id BB6371551; Mon, 26 Sep 2011 14:05:26 -0400 (EDT) Date: Mon, 26 Sep 2011 14:05:26 -0400 From: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com> To: Shriganesh Shintre <shriganeshs@gmail.com> Message-ID: <20110926180526.GA8008@phenom.oracle.com> References: <CAM3t-NPZmFnCdv0T=-54Ff0YNeKD+XaUq5-+h8icz5K3mKNkUA@mail.gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline In-Reply-To: <CAM3t-NPZmFnCdv0T=-54Ff0YNeKD+XaUq5-+h8icz5K3mKNkUA@mail.gmail.com> User-Agent: Mutt/1.5.21 (2010-09-15) Content-Transfer-Encoding: quoted-printable X-Source-IP: rtcsinet22.oracle.com [66.248.204.30] X-CT-RefId: str=0001.0A090208.4E80BEF6.0136,ss=1,re=0.000,fgs=0 Cc: xen-devel@lists.xensource.com, Xen-users@lists.xensource.com Subject: [Xen-users] Re: [Xen-devel] warning trace while starting domU X-BeenThere: xen-users@lists.xensource.com X-Mailman-Version: 2.1.5 Precedence: list List-Id: Xen user discussion <xen-users.lists.xensource.com> List-Unsubscribe: <http://lists.xensource.com/mailman/listinfo/xen-users>, <mailto:xen-users-request@lists.xensource.com?subject=unsubscribe> List-Post: <mailto:xen-users@lists.xensource.com> List-Help: <mailto:xen-users-request@lists.xensource.com?subject=help> List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-users>, <mailto:xen-users-request@lists.xensource.com?subject=subscribe> Sender: xen-users-bounces@lists.xensource.com Errors-To: xen-users-bounces@lists.xensource.com On Mon, Sep 26, 2011 at 10:24:53AM -0700, Shriganesh Shintre wrote: > Environment: Xen 4.1.1 with Linux 3.0.4 kernel (compiled with DEBUG ena= bled) >=20 > I am chasing the warning trace while starting domU. Trace is as follows Don't worry about it. Ignore it please - I am droping this piece of code = in 3.2 as it is causing more headache that it is worth. >=20 >=20 > Sep 12 22:18:58 ucs-xen24-srv1 kernel: ------------[ cut here ]--------= ---- > Sep 12 22:18:58 ucs-xen24-srv1 kernel: WARNING: at arch/x86/xen/mmu.c:4= 86 > xen_make_pte_debug+0xdb/0x187() > Sep 12 22:18:58 ucs-xen24-srv1 kernel: Hardware name: N20-B6625-1 > Sep 12 22:18:58 ucs-xen24-srv1 kernel: 0xec0f1000 is using VM_IO, but i= t is > 0xfffff000! > Sep 12 22:18:58 ucs-xen24-srv1 kernel: Modules linked in: veth raid1 vn= p > iptable_filter ip_tables bridge stp ipmi_si ipmi_devintf ipmi_msghandle= r nbd > hoop bonding xt_tcpudp x_tables ipv6 xenfs loop dm_mirror dm_region_has= h > dm_log dm_multipath scsi_dh dm_mod thermal fan parport nvram sg ub enic > acpi_power_meter hwmon 8250_pnp button 8250 i2c_i801 ehci_hcd serial_co= re > ioatdma i2c_core iTCO_wdt iTCO_vendor_support uhci_hcd dca pcspkr mptsa= s > mptscsih mptbase scsi_transport_sas sd_mod scsi_mod ext3 jbd mbcache [l= ast > unloaded: ip_tables] > Sep 12 22:18:58 ucs-xen24-srv1 kernel: Pid: 16534, comm: xend Tainted: > G W 3.0.1-11.xen0 #1 > Sep 12 22:18:58 ucs-xen24-srv1 kernel: Call Trace: > Sep 12 22:18:58 ucs-xen24-srv1 kernel: [<c100647f>] ? > xen_make_pte_debug+0xdb/0x187 > Sep 12 22:18:58 ucs-xen24-srv1 kernel: [<c10351e0>] > warn_slowpath_common+0x76/0x8b > Sep 12 22:18:58 ucs-xen24-srv1 kernel: [<c100647f>] ? > xen_make_pte_debug+0xdb/0x187 > Sep 12 22:18:58 ucs-xen24-srv1 kernel: [<c1035271>] > warn_slowpath_fmt+0x2e/0x30 > Sep 12 22:18:58 ucs-xen24-srv1 kernel: [<c100647f>] > xen_make_pte_debug+0xdb/0x187 > Sep 12 22:18:58 ucs-xen24-srv1 kernel: [<c100466e>] > __raw_callee_save_xen_make_pte_debug+0x6/0x8 > Sep 12 22:18:59 ucs-xen24-srv1 kernel: [<c1004db9>] ? > remap_area_mfn_pte_fn+0x60/0xf7 > Sep 12 22:18:59 ucs-xen24-srv1 kernel: [<c10842b9>] > apply_to_page_range+0x1fe/0x307 > Sep 12 22:18:59 ucs-xen24-srv1 kernel: [<c100514c>] > xen_remap_domain_mfn_range+0xd3/0x107 > Sep 12 22:18:59 ucs-xen24-srv1 logger: /etc/xen/scripts/block: add > XENBUS_PATH=3Dbackend/vbd/1/768 > Sep 12 22:18:59 ucs-xen24-srv1 logger: /etc/xen/scripts/block: add > XENBUS_PATH=3Dbackend/vbd/1/832 > Sep 12 22:18:59 ucs-xen24-srv1 kernel: [<c1004d59>] ? > xen_make_pte+0x113/0x113 > Sep 12 22:18:59 ucs-xen24-srv1 logger: /etc/xen/scripts/block: add > XENBUS_PATH=3Dbackend/vbd/1/5632 > Sep 12 22:18:59 ucs-xen24-srv1 logger: /etc/xen/scripts/block: add > XENBUS_PATH=3Dbackend/vbd/1/5696 > Sep 12 22:18:59 ucs-xen24-srv1 VRM: TP_SKT.c(1193): m_skt_connect(): Fa= iled > to connect to remote host, err=3DNo route to host, 113 > Sep 12 22:18:59 ucs-xen24-srv1 kernel: [<c1007097>] ? > xen_restore_fl_direct_reloc+0x4/0x4 > Sep 12 22:19:00 ucs-xen24-srv1 kernel: [<c1005352>] ? > xen_flush_tlb+0x5f/0x6c > Sep 12 22:19:00 ucs-xen24-srv1 kernel: [<c1024766>] ? > kernel_map_pages+0xab/0x104 > Sep 12 22:19:00 ucs-xen24-srv1 kernel: [<c107288d>] ? > get_page_from_freelist+0x255/0x39c > Sep 12 22:19:00 ucs-xen24-srv1 kernel: [<c10044a5>] ? > xen_mc_flush+0x101/0x1b6 > Sep 12 22:19:00 ucs-xen24-srv1 kernel: [<c1072b9e>] ? > __alloc_pages_nodemask+0xd9/0x561 > Sep 12 22:19:00 ucs-xen24-srv1 kernel: [<c10823eb>] ? > do_wp_page+0x348/0x879 > Sep 12 22:19:00 ucs-xen24-srv1 kernel: [<f818909b>] mmap_batch_fn+0x3c= /0x5b > [xenfs] > Sep 12 22:19:00 ucs-xen24-srv1 kernel: [<f8188c53>] > traverse_pages+0x75/0x89 [xenfs] > Sep 12 22:19:00 ucs-xen24-srv1 kernel: [<f8189022>] > privcmd_ioctl+0x2ad/0x2ea [xenfs] > Sep 12 22:19:00 ucs-xen24-srv1 kernel: [<f818905f>] ? > privcmd_ioctl+0x2ea/0x2ea [xenfs] > Sep 12 22:19:00 ucs-xen24-srv1 kernel: [<c10884a7>] ? vma_link+0x4f/0x= 8d > Sep 12 22:19:00 ucs-xen24-srv1 kernel: [<f8188d75>] ? > free_page_list+0x3b/0x3b [xenfs] > Sep 12 22:19:00 ucs-xen24-srv1 kernel: [<c10a4734>] vfs_ioctl+0x24/0x3= 7 > Sep 12 22:19:00 ucs-xen24-srv1 kernel: [<c10a48a5>] do_vfs_ioctl+0x8a/= 0x4df > Sep 12 22:19:00 ucs-xen24-srv1 kernel: [<c1089284>] ? sys_brk+0x101/0x= 101 > Sep 12 22:19:00 ucs-xen24-srv1 kernel: [<c1089011>] ? > do_mmap_pgoff+0x2bb/0x2df > Sep 12 22:19:00 ucs-xen24-srv1 kernel: [<c10a4d2d>] sys_ioctl+0x33/0x5= 7 > Sep 12 22:19:00 ucs-xen24-srv1 kernel: [<c1251d9c>] > sysenter_do_call+0x12/0x2c > Sep 12 22:19:00 ucs-xen24-srv1 kernel: ---[ end trace 4eaa2a86a8e2da26 = ]--- >=20 >=20 >=20 > Following is the code from where the trace is coming. It=E2=80=99s clea= r from the > code that this warning trace is observed only when the debug kernel is = used. > Also warning appears only once (WARN_ONCE) while starting first domU. >=20 >=20 > File: linux-3.0.4/arch/x86/xen/mmu.c >=20 > #ifdef CONFIG_XEN_DEBUG >=20 > pte_t xen_make_pte_debug(pteval_t pte) >=20 > { >=20 > phys_addr_t addr =3D (pte & PTE_PFN_MASK); >=20 > phys_addr_t other_addr; >=20 > bool io_page =3D false; >=20 > pte_t _pte; >=20 >=20 >=20 > if (pte & _PAGE_IOMAP) >=20 > io_page =3D true; >=20 >=20 >=20 > _pte =3D xen_make_pte(pte); >=20 >=20 >=20 > if (!addr) >=20 > return _pte; >=20 >=20 >=20 > * if (io_page > && * >=20 > * (xen_initial_domain() || addr >=3D ISA_END_ADDRESS)) {* >=20 > * other_addr =3D pfn_to_mfn(addr >> PAGE_SHIFT) << PAGE_= SHIFT;* >=20 > * WARN_ONCE(addr !=3D other_addr,* >=20 > * "0x%lx is using VM_IO, but it is 0x%lx!\n",* >=20 > * (unsigned long)addr, (unsigned long)other_addr= );* >=20 > } else { >=20 > pteval_t iomap_set =3D (_pte.pte & PTE_FLAGS_MASK) & > _PAGE_IOMAP; >=20 > other_addr =3D (_pte.pte & PTE_PFN_MASK); >=20 > WARN_ONCE((addr =3D=3D other_addr) && (!io_page) && > (!iomap_set), >=20 > "0x%lx is missing VM_IO (and wasn't fixed)!\n", >=20 > (unsigned long)addr); >=20 > } >=20 >=20 >=20 > return _pte; >=20 > } >=20 > PV_CALLEE_SAVE_REGS_THUNK(xen_make_pte_debug); >=20 > #endif >=20 >=20 >=20 > When googled, I found this link > http://www.gossamer-threads.com/lists/xen/devel/217630, but could not f= ind > the patch he is talking about. >=20 >=20 > Could you please help me resolving this warning? or provide me more poi= nters > and direction for debugging. Thank you in advance. >=20 >=20 > ~Shri > _______________________________________________ > Xen-devel mailing list > Xen-devel@lists.xensource.com > http://lists.xensource.com/xen-devel _______________________________________________ Xen-users mailing list Xen-users@lists.xensource.com http://lists.xensource.com/xen-users From xen-devel-bounces@lists.xensource.com Mon Sep 26 11:19:25 2011 Return-path: <xen-devel-bounces@lists.xensource.com> Envelope-to: www-data@lists.xensource.com Delivery-date: Mon, 26 Sep 2011 11:19:25 -0700 Received: from localhost ([127.0.0.1] helo=lists.colo.xensource.com) by lists.xensource.com with esmtp (Exim 4.43) id 1R8Flz-0008Kx-KQ; Mon, 26 Sep 2011 11:19:25 -0700 Received: from mail216.messagelabs.com ([85.158.143.99]) by lists.xensource.com with esmtp (Exim 4.43) id 1R8Fks-00086D-5b for xen-devel@lists.xensource.com; Mon, 26 Sep 2011 11:18:17 -0700 X-Env-Sender: jeremy@goop.org X-Msg-Ref: server-12.tower-216.messagelabs.com!1317061089!13914334!1 X-Originating-IP: [74.207.240.146] X-StarScan-Version: 6.4.1; banners=-,-,- X-VirusChecked: Checked Received: (qmail 8693 invoked from network); 26 Sep 2011 18:18:11 -0000 Received: from claw.goop.org (HELO claw.goop.org) (74.207.240.146) by server-12.tower-216.messagelabs.com with DHE-RSA-AES256-SHA encrypted SMTP; 26 Sep 2011 18:18:11 -0000 Received: from saboo.goop.org (unknown [IPv6:2001:470:1f05:899:d4cf:8dff:fec9:d94b]) (Authenticated sender: smtp-saboo) by claw.goop.org (Postfix) with ESMTPSA id 9B479A068; Mon, 26 Sep 2011 11:18:08 -0700 (PDT) Received: by saboo.goop.org (Postfix, from userid 500) id D3B04208C4; Mon, 26 Sep 2011 11:18:04 -0700 (PDT) From: Jeremy Fitzhardinge <jeremy@goop.org> To: "H. Peter Anvin" <hpa@zytor.com> Date: Mon, 26 Sep 2011 11:17:59 -0700 Message-Id: <cover.1317060617.git.jeremy.fitzhardinge@citrix.com> X-Mailer: git-send-email 1.7.6.2 Cc: Jeremy Fitzhardinge <jeremy.fitzhardinge@citrix.com>, the arch/x86 maintainers <x86@kernel.org>, Xen Devel <xen-devel@lists.xensource.com>, Tigran Aivazian <tigran@aivazian.fsnet.co.uk>, Linux Kernel Mailing List <linux-kernel@vger.kernel.org> Subject: [Xen-devel] [PATCH 0/3] x86/microcode: support for microcode update in Xen dom0 X-BeenThere: xen-devel@lists.xensource.com X-Mailman-Version: 2.1.5 Precedence: list List-Id: Xen developer discussion <xen-devel.lists.xensource.com> List-Unsubscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe> List-Post: <mailto:xen-devel@lists.xensource.com> List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help> List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=subscribe> Sender: xen-devel-bounces@lists.xensource.com Errors-To: xen-devel-bounces@lists.xensource.com From: Jeremy Fitzhardinge <jeremy.fitzhardinge@citrix.com> Hi all, I'm proposing this for the next merge window v3.2. I originally posted this early this year, and it prompted a debate about what the "proper" way that Linux should do microcode updates, with the general concensus being "earlier", ideally in the bootloader (or in the case of Xen, as the hypervisor boots before starting any domains). However, as far as I know there has been no progress along those lines. I would like to therefore merge this so that a Linux kernel booting as dom0 under Xen can update the microcode in the same manner as a kernel booting natively. When we work out how boot-time microcode updates can be done, then we'll look at modifying Xen accordingly. In the meantime, we should have a functional parity. The only change to this code from the previous posting is some patch restructuring so that regardless of how the platform.h ABI header gets merged (since there are some other pending branches containing it), it will be identical and cause no merge headaches. >From original posting: This series adds a new "Xen" microcode update type, in addition to Intel and AMD. The Xen hypervisor is responsible for performing the actual microcode update (since only it knows what physical CPUs are in the system and has sufficient privilege to access them), but it requires the dom0 kernel to provide the actual microcode update data. Xen update mechanism is uniform independent of the CPU type, but the driver must know where to find the data file, which depends on the CPU type. And since the update hypercall updates all CPUs, we only need to execute it once on any CPU - but for simplicity it just runs it only on (V)CPU 0. Thanks, J Jeremy Fitzhardinge (2): xen: add dom0_op hypercall xen: add CPU microcode update driver Yu Ke (1): xen/acpi: Domain0 acpi parser related platform hypercall arch/ia64/include/asm/xen/interface.h | 1 + arch/x86/include/asm/microcode.h | 9 + arch/x86/include/asm/xen/hypercall.h | 8 + arch/x86/include/asm/xen/interface.h | 1 + arch/x86/kernel/Makefile | 1 + arch/x86/kernel/microcode_core.c | 5 +- arch/x86/kernel/microcode_xen.c | 198 ++++++++++++++++++++ arch/x86/xen/Kconfig | 4 + include/xen/interface/platform.h | 320 +++++++++++++++++++++++++++++++++ include/xen/interface/xen.h | 1 + 10 files changed, 547 insertions(+), 1 deletions(-) create mode 100644 arch/x86/kernel/microcode_xen.c create mode 100644 include/xen/interface/platform.h -- 1.7.6.2 _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel From xen-devel-bounces@lists.xensource.com Mon Sep 26 11:20:49 2011 Return-path: <xen-devel-bounces@lists.xensource.com> Envelope-to: www-data@lists.xensource.com Delivery-date: Mon, 26 Sep 2011 11:20:49 -0700 Received: from localhost ([127.0.0.1] helo=lists.colo.xensource.com) by lists.xensource.com with esmtp (Exim 4.43) id 1R8FnN-0000If-4D; Mon, 26 Sep 2011 11:20:49 -0700 Received: from mail182.messagelabs.com ([85.158.139.83]) by lists.xensource.com with esmtp (Exim 4.43) id 1R8Fks-00086F-7v for xen-devel@lists.xensource.com; Mon, 26 Sep 2011 11:18:20 -0700 X-Env-Sender: jeremy@goop.org X-Msg-Ref: server-15.tower-182.messagelabs.com!1317061089!18805250!1 X-Originating-IP: [74.207.240.146] X-StarScan-Version: 6.4.1; banners=-,-,- X-VirusChecked: Checked Received: (qmail 29760 invoked from network); 26 Sep 2011 18:18:11 -0000 Received: from claw.goop.org (HELO claw.goop.org) (74.207.240.146) by server-15.tower-182.messagelabs.com with DHE-RSA-AES256-SHA encrypted SMTP; 26 Sep 2011 18:18:11 -0000 Received: from saboo.goop.org (unknown [IPv6:2001:470:1f05:899:d4cf:8dff:fec9:d94b]) (Authenticated sender: smtp-saboo) by claw.goop.org (Postfix) with ESMTPSA id DDAE6A066; Mon, 26 Sep 2011 11:18:07 -0700 (PDT) Received: by saboo.goop.org (Postfix, from userid 500) id EDB31208D2; Mon, 26 Sep 2011 11:18:04 -0700 (PDT) From: Jeremy Fitzhardinge <jeremy@goop.org> To: "H. Peter Anvin" <hpa@zytor.com> Date: Mon, 26 Sep 2011 11:18:02 -0700 Message-Id: <23757fb5d6781bf945d21d1f5373aa71122cbea9.1317060617.git.jeremy.fitzhardinge@citrix.com> X-Mailer: git-send-email 1.7.6.2 In-Reply-To: <cover.1317060617.git.jeremy.fitzhardinge@citrix.com> References: <cover.1317060617.git.jeremy.fitzhardinge@citrix.com> In-Reply-To: <cover.1317060617.git.jeremy.fitzhardinge@citrix.com> References: <cover.1317060617.git.jeremy.fitzhardinge@citrix.com> Cc: Jeremy Fitzhardinge <jeremy.fitzhardinge@citrix.com>, the arch/x86 maintainers <x86@kernel.org>, Xen Devel <xen-devel@lists.xensource.com>, Tigran Aivazian <tigran@aivazian.fsnet.co.uk>, Linux Kernel Mailing List <linux-kernel@vger.kernel.org> Subject: [Xen-devel] [PATCH 3/3] xen: add CPU microcode update driver X-BeenThere: xen-devel@lists.xensource.com X-Mailman-Version: 2.1.5 Precedence: list List-Id: Xen developer discussion <xen-devel.lists.xensource.com> List-Unsubscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe> List-Post: <mailto:xen-devel@lists.xensource.com> List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help> List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=subscribe> Sender: xen-devel-bounces@lists.xensource.com Errors-To: xen-devel-bounces@lists.xensource.com From: Jeremy Fitzhardinge <jeremy.fitzhardinge@citrix.com> Xen does all the hard work for us, including choosing the right update method for this cpu type and actually doing it for all cpus. We just need to supply it with the firmware blob. Because Xen updates all CPUs (and the kernel's virtual cpu numbers have no fixed relationship with the underlying physical cpus), we only bother doing anything for cpu "0". [ Impact: allow CPU microcode update in Xen dom0 ] Signed-off-by: Jeremy Fitzhardinge <jeremy.fitzhardinge@citrix.com> --- arch/x86/include/asm/microcode.h | 9 ++ arch/x86/kernel/Makefile | 1 + arch/x86/kernel/microcode_core.c | 5 +- arch/x86/kernel/microcode_xen.c | 198 ++++++++++++++++++++++++++++++++++++++ arch/x86/xen/Kconfig | 4 + 5 files changed, 216 insertions(+), 1 deletions(-) create mode 100644 arch/x86/kernel/microcode_xen.c diff --git a/arch/x86/include/asm/microcode.h b/arch/x86/include/asm/microcode.h index 2421507..22677d6 100644 --- a/arch/x86/include/asm/microcode.h +++ b/arch/x86/include/asm/microcode.h @@ -61,4 +61,13 @@ static inline struct microcode_ops * __init init_amd_microcode(void) } #endif +#ifdef CONFIG_MICROCODE_XEN +extern struct microcode_ops * __init init_xen_microcode(void); +#else +static inline struct microcode_ops * __init init_xen_microcode(void) +{ + return NULL; +} +#endif + #endif /* _ASM_X86_MICROCODE_H */ diff --git a/arch/x86/kernel/Makefile b/arch/x86/kernel/Makefile index 7338ef2..d34362a 100644 --- a/arch/x86/kernel/Makefile +++ b/arch/x86/kernel/Makefile @@ -105,6 +105,7 @@ obj-$(CONFIG_PCSPKR_PLATFORM) += pcspeaker.o microcode-y := microcode_core.o microcode-$(CONFIG_MICROCODE_INTEL) += microcode_intel.o microcode-$(CONFIG_MICROCODE_AMD) += microcode_amd.o +microcode-$(CONFIG_MICROCODE_XEN) += microcode_xen.o obj-$(CONFIG_MICROCODE) += microcode.o obj-$(CONFIG_X86_CHECK_BIOS_CORRUPTION) += check.o diff --git a/arch/x86/kernel/microcode_core.c b/arch/x86/kernel/microcode_core.c index f924280..ecbcbc0 100644 --- a/arch/x86/kernel/microcode_core.c +++ b/arch/x86/kernel/microcode_core.c @@ -84,6 +84,7 @@ #include <linux/mm.h> #include <linux/syscore_ops.h> +#include <xen/xen.h> #include <asm/microcode.h> #include <asm/processor.h> @@ -501,7 +502,9 @@ static int __init microcode_init(void) struct cpuinfo_x86 *c = &cpu_data(0); int error; - if (c->x86_vendor == X86_VENDOR_INTEL) + if (xen_pv_domain()) + microcode_ops = init_xen_microcode(); + else if (c->x86_vendor == X86_VENDOR_INTEL) microcode_ops = init_intel_microcode(); else if (c->x86_vendor == X86_VENDOR_AMD) microcode_ops = init_amd_microcode(); diff --git a/arch/x86/kernel/microcode_xen.c b/arch/x86/kernel/microcode_xen.c new file mode 100644 index 0000000..9d2a06b --- /dev/null +++ b/arch/x86/kernel/microcode_xen.c @@ -0,0 +1,198 @@ +/* + * Xen microcode update driver + * + * Xen does most of the work here. We just pass the whole blob into + * Xen, and it will apply it to all CPUs as appropriate. Xen will + * worry about how different CPU models are actually updated. + */ +#include <linux/sched.h> +#include <linux/module.h> +#include <linux/firmware.h> +#include <linux/vmalloc.h> +#include <linux/uaccess.h> + +#include <asm/microcode.h> + +#include <xen/xen.h> +#include <xen/interface/platform.h> +#include <xen/interface/xen.h> + +#include <asm/xen/hypercall.h> +#include <asm/xen/hypervisor.h> + +MODULE_DESCRIPTION("Xen microcode update driver"); +MODULE_LICENSE("GPL"); + +struct xen_microcode { + size_t len; + char data[0]; +}; + +static int xen_microcode_update(int cpu) +{ + int err; + struct xen_platform_op op; + struct ucode_cpu_info *uci = ucode_cpu_info + cpu; + struct xen_microcode *uc = uci->mc; + + if (uc == NULL || uc->len == 0) { + /* + * We do all cpus at once, so we don't need to do + * other cpus explicitly (besides, these vcpu numbers + * have no relationship to underlying physical cpus). + */ + return 0; + } + + op.cmd = XENPF_microcode_update; + set_xen_guest_handle(op.u.microcode.data, uc->data); + op.u.microcode.length = uc->len; + + err = HYPERVISOR_dom0_op(&op); + + if (err != 0) + printk(KERN_WARNING "microcode_xen: microcode update failed: %d\n", err); + + return err; +} + +static enum ucode_state xen_request_microcode_fw(int cpu, struct device *device) +{ + char name[30]; + struct cpuinfo_x86 *c = &cpu_data(cpu); + const struct firmware *firmware; + struct ucode_cpu_info *uci = ucode_cpu_info + cpu; + enum ucode_state ret; + struct xen_microcode *uc; + size_t size; + int err; + + switch (c->x86_vendor) { + case X86_VENDOR_INTEL: + snprintf(name, sizeof(name), "intel-ucode/%02x-%02x-%02x", + c->x86, c->x86_model, c->x86_mask); + break; + + case X86_VENDOR_AMD: + snprintf(name, sizeof(name), "amd-ucode/microcode_amd.bin"); + break; + + default: + return UCODE_NFOUND; + } + + err = request_firmware(&firmware, name, device); + if (err) { + pr_debug("microcode: data file %s load failed\n", name); + return UCODE_NFOUND; + } + + /* + * Only bother getting real firmware for cpu 0; the others get + * dummy placeholders. + */ + if (cpu == 0) + size = firmware->size; + else + size = 0; + + if (uci->mc != NULL) { + vfree(uci->mc); + uci->mc = NULL; + } + + ret = UCODE_ERROR; + uc = vmalloc(sizeof(*uc) + size); + if (uc == NULL) + goto out; + + ret = UCODE_OK; + uc->len = size; + memcpy(uc->data, firmware->data, uc->len); + + uci->mc = uc; + +out: + release_firmware(firmware); + + return ret; +} + +static enum ucode_state xen_request_microcode_user(int cpu, + const void __user *buf, size_t size) +{ + struct ucode_cpu_info *uci = ucode_cpu_info + cpu; + struct xen_microcode *uc; + enum ucode_state ret; + size_t unread; + + if (cpu != 0) { + /* No real firmware for non-zero cpus; just store a + placeholder */ + size = 0; + } + + if (uci->mc != NULL) { + vfree(uci->mc); + uci->mc = NULL; + } + + ret = UCODE_ERROR; + uc = vmalloc(sizeof(*uc) + size); + if (uc == NULL) + goto out; + + uc->len = size; + + ret = UCODE_NFOUND; + + unread = copy_from_user(uc->data, buf, size); + + if (unread != 0) { + printk(KERN_WARNING "failed to read %zd of %zd bytes at %p -> %p\n", + unread, size, buf, uc->data); + goto out; + } + + ret = UCODE_OK; + +out: + if (ret == 0) + uci->mc = uc; + else + vfree(uc); + + return ret; +} + +static void xen_microcode_fini_cpu(int cpu) +{ + struct ucode_cpu_info *uci = ucode_cpu_info + cpu; + + vfree(uci->mc); + uci->mc = NULL; +} + +static int xen_collect_cpu_info(int cpu, struct cpu_signature *sig) +{ + sig->sig = 0; + sig->pf = 0; + sig->rev = 0; + + return 0; +} + +static struct microcode_ops microcode_xen_ops = { + .request_microcode_user = xen_request_microcode_user, + .request_microcode_fw = xen_request_microcode_fw, + .collect_cpu_info = xen_collect_cpu_info, + .apply_microcode = xen_microcode_update, + .microcode_fini_cpu = xen_microcode_fini_cpu, +}; + +struct microcode_ops * __init init_xen_microcode(void) +{ + if (!xen_initial_domain()) + return NULL; + return µcode_xen_ops; +} diff --git a/arch/x86/xen/Kconfig b/arch/x86/xen/Kconfig index 5cc821c..4d04d4f 100644 --- a/arch/x86/xen/Kconfig +++ b/arch/x86/xen/Kconfig @@ -57,3 +57,7 @@ config XEN_DEBUG help Enable various WARN_ON checks in the Xen MMU code. Enabling this option WILL incur a significant performance overhead. + +config MICROCODE_XEN + def_bool y + depends on XEN_DOM0 && MICROCODE -- 1.7.6.2 _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel From xen-devel-bounces@lists.xensource.com Mon Sep 26 11:21:42 2011 Return-path: <xen-devel-bounces@lists.xensource.com> Envelope-to: www-data@lists.xensource.com Delivery-date: Mon, 26 Sep 2011 11:21:42 -0700 Received: from localhost ([127.0.0.1] helo=lists.colo.xensource.com) by lists.xensource.com with esmtp (Exim 4.43) id 1R8FoE-0000fm-BM; Mon, 26 Sep 2011 11:21:42 -0700 Received: from mail27.messagelabs.com ([193.109.254.147]) by lists.xensource.com with esmtp (Exim 4.43) id 1R8Fks-00086E-8k for xen-devel@lists.xensource.com; Mon, 26 Sep 2011 11:18:20 -0700 X-Env-Sender: jeremy@goop.org X-Msg-Ref: server-12.tower-27.messagelabs.com!1317061073!44007007!1 X-Originating-IP: [74.207.240.146] X-StarScan-Version: 6.4.1; banners=-,-,- X-VirusChecked: Checked Received: (qmail 18555 invoked from network); 26 Sep 2011 18:17:54 -0000 Received: from claw.goop.org (HELO claw.goop.org) (74.207.240.146) by server-12.tower-27.messagelabs.com with DHE-RSA-AES256-SHA encrypted SMTP; 26 Sep 2011 18:17:54 -0000 Received: from saboo.goop.org (unknown [IPv6:2001:470:1f05:899:d4cf:8dff:fec9:d94b]) (Authenticated sender: smtp-saboo) by claw.goop.org (Postfix) with ESMTPSA id 736A5A067; Mon, 26 Sep 2011 11:18:08 -0700 (PDT) Received: by saboo.goop.org (Postfix, from userid 500) id DA249208CC; Mon, 26 Sep 2011 11:18:04 -0700 (PDT) From: Jeremy Fitzhardinge <jeremy@goop.org> To: "H. Peter Anvin" <hpa@zytor.com> Date: Mon, 26 Sep 2011 11:18:00 -0700 Message-Id: <58dc87cb12b80f52c8f1030e9651f31385d9c653.1317060617.git.jeremy.fitzhardinge@citrix.com> X-Mailer: git-send-email 1.7.6.2 In-Reply-To: <cover.1317060617.git.jeremy.fitzhardinge@citrix.com> References: <cover.1317060617.git.jeremy.fitzhardinge@citrix.com> In-Reply-To: <cover.1317060617.git.jeremy.fitzhardinge@citrix.com> References: <cover.1317060617.git.jeremy.fitzhardinge@citrix.com> Cc: Tian Kevin <kevin.tian@intel.com>, Xen Devel <xen-devel@lists.xensource.com>, Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>, the arch/x86 maintainers <x86@kernel.org>, Tigran Aivazian <tigran@aivazian.fsnet.co.uk>, Linux Kernel Mailing List <linux-kernel@vger.kernel.org>, Jeremy Fitzhardinge <jeremy.fitzhardinge@citrix.com>, Yu Ke <ke.yu@intel.com> Subject: [Xen-devel] [PATCH 1/3] xen/acpi: Domain0 acpi parser related platform hypercall X-BeenThere: xen-devel@lists.xensource.com X-Mailman-Version: 2.1.5 Precedence: list List-Id: Xen developer discussion <xen-devel.lists.xensource.com> List-Unsubscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe> List-Post: <mailto:xen-devel@lists.xensource.com> List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help> List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=subscribe> Sender: xen-devel-bounces@lists.xensource.com Errors-To: xen-devel-bounces@lists.xensource.com From: Yu Ke <ke.yu@intel.com> This patches implements the xen_platform_op hypercall, to pass the parsed ACPI info to hypervisor. Signed-off-by: Yu Ke <ke.yu@intel.com> Signed-off-by: Tian Kevin <kevin.tian@intel.com> Signed-off-by: Jeremy Fitzhardinge <jeremy.fitzhardinge@citrix.com> [v1: Added DEFINE_GUEST.. in appropiate headers] [v2: Ripped out typedefs] Signed-off-by: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com> --- arch/ia64/include/asm/xen/interface.h | 1 + arch/x86/include/asm/xen/interface.h | 1 + include/xen/interface/platform.h | 320 +++++++++++++++++++++++++++++++++ include/xen/interface/xen.h | 1 + 4 files changed, 323 insertions(+), 0 deletions(-) create mode 100644 include/xen/interface/platform.h diff --git a/arch/ia64/include/asm/xen/interface.h b/arch/ia64/include/asm/xen/interface.h index e951e74..1d2427d 100644 --- a/arch/ia64/include/asm/xen/interface.h +++ b/arch/ia64/include/asm/xen/interface.h @@ -76,6 +76,7 @@ DEFINE_GUEST_HANDLE(char); DEFINE_GUEST_HANDLE(int); DEFINE_GUEST_HANDLE(long); DEFINE_GUEST_HANDLE(void); +DEFINE_GUEST_HANDLE(uint64_t); typedef unsigned long xen_pfn_t; DEFINE_GUEST_HANDLE(xen_pfn_t); diff --git a/arch/x86/include/asm/xen/interface.h b/arch/x86/include/asm/xen/interface.h index 5d4922a..a1f2db5 100644 --- a/arch/x86/include/asm/xen/interface.h +++ b/arch/x86/include/asm/xen/interface.h @@ -55,6 +55,7 @@ DEFINE_GUEST_HANDLE(char); DEFINE_GUEST_HANDLE(int); DEFINE_GUEST_HANDLE(long); DEFINE_GUEST_HANDLE(void); +DEFINE_GUEST_HANDLE(uint64_t); #endif #ifndef HYPERVISOR_VIRT_START diff --git a/include/xen/interface/platform.h b/include/xen/interface/platform.h new file mode 100644 index 0000000..c168468 --- /dev/null +++ b/include/xen/interface/platform.h @@ -0,0 +1,320 @@ +/****************************************************************************** + * platform.h + * + * Hardware platform operations. Intended for use by domain-0 kernel. + * + * Permission is hereby granted, free of charge, to any person obtaining a copy + * of this software and associated documentation files (the "Software"), to + * deal in the Software without restriction, including without limitation the + * rights to use, copy, modify, merge, publish, distribute, sublicense, and/or + * sell copies of the Software, and to permit persons to whom the Software is + * furnished to do so, subject to the following conditions: + * + * The above copyright notice and this permission notice shall be included in + * all copies or substantial portions of the Software. + * + * THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR + * IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY, + * FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL THE + * AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER + * LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING + * FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER + * DEALINGS IN THE SOFTWARE. + * + * Copyright (c) 2002-2006, K Fraser + */ + +#ifndef __XEN_PUBLIC_PLATFORM_H__ +#define __XEN_PUBLIC_PLATFORM_H__ + +#include "xen.h" + +#define XENPF_INTERFACE_VERSION 0x03000001 + +/* + * Set clock such that it would read <secs,nsecs> after 00:00:00 UTC, + * 1 January, 1970 if the current system time was <system_time>. + */ +#define XENPF_settime 17 +struct xenpf_settime { + /* IN variables. */ + uint32_t secs; + uint32_t nsecs; + uint64_t system_time; +}; +DEFINE_GUEST_HANDLE_STRUCT(xenpf_settime_t); + +/* + * Request memory range (@mfn, @mfn+@nr_mfns-1) to have type @type. + * On x86, @type is an architecture-defined MTRR memory type. + * On success, returns the MTRR that was used (@reg) and a handle that can + * be passed to XENPF_DEL_MEMTYPE to accurately tear down the new setting. + * (x86-specific). + */ +#define XENPF_add_memtype 31 +struct xenpf_add_memtype { + /* IN variables. */ + unsigned long mfn; + uint64_t nr_mfns; + uint32_t type; + /* OUT variables. */ + uint32_t handle; + uint32_t reg; +}; +DEFINE_GUEST_HANDLE_STRUCT(xenpf_add_memtype_t); + +/* + * Tear down an existing memory-range type. If @handle is remembered then it + * should be passed in to accurately tear down the correct setting (in case + * of overlapping memory regions with differing types). If it is not known + * then @handle should be set to zero. In all cases @reg must be set. + * (x86-specific). + */ +#define XENPF_del_memtype 32 +struct xenpf_del_memtype { + /* IN variables. */ + uint32_t handle; + uint32_t reg; +}; +DEFINE_GUEST_HANDLE_STRUCT(xenpf_del_memtype_t); + +/* Read current type of an MTRR (x86-specific). */ +#define XENPF_read_memtype 33 +struct xenpf_read_memtype { + /* IN variables. */ + uint32_t reg; + /* OUT variables. */ + unsigned long mfn; + uint64_t nr_mfns; + uint32_t type; +}; +DEFINE_GUEST_HANDLE_STRUCT(xenpf_read_memtype_t); + +#define XENPF_microcode_update 35 +struct xenpf_microcode_update { + /* IN variables. */ + GUEST_HANDLE(void) data; /* Pointer to microcode data */ + uint32_t length; /* Length of microcode data. */ +}; +DEFINE_GUEST_HANDLE_STRUCT(xenpf_microcode_update_t); + +#define XENPF_platform_quirk 39 +#define QUIRK_NOIRQBALANCING 1 /* Do not restrict IO-APIC RTE targets */ +#define QUIRK_IOAPIC_BAD_REGSEL 2 /* IO-APIC REGSEL forgets its value */ +#define QUIRK_IOAPIC_GOOD_REGSEL 3 /* IO-APIC REGSEL behaves properly */ +struct xenpf_platform_quirk { + /* IN variables. */ + uint32_t quirk_id; +}; +DEFINE_GUEST_HANDLE_STRUCT(xenpf_platform_quirk_t); + +#define XENPF_firmware_info 50 +#define XEN_FW_DISK_INFO 1 /* from int 13 AH=08/41/48 */ +#define XEN_FW_DISK_MBR_SIGNATURE 2 /* from MBR offset 0x1b8 */ +#define XEN_FW_VBEDDC_INFO 3 /* from int 10 AX=4f15 */ +struct xenpf_firmware_info { + /* IN variables. */ + uint32_t type; + uint32_t index; + /* OUT variables. */ + union { + struct { + /* Int13, Fn48: Check Extensions Present. */ + uint8_t device; /* %dl: bios device number */ + uint8_t version; /* %ah: major version */ + uint16_t interface_support; /* %cx: support bitmap */ + /* Int13, Fn08: Legacy Get Device Parameters. */ + uint16_t legacy_max_cylinder; /* %cl[7:6]:%ch: max cyl # */ + uint8_t legacy_max_head; /* %dh: max head # */ + uint8_t legacy_sectors_per_track; /* %cl[5:0]: max sector # */ + /* Int13, Fn41: Get Device Parameters (as filled into %ds:%esi). */ + /* NB. First uint16_t of buffer must be set to buffer size. */ + GUEST_HANDLE(void) edd_params; + } disk_info; /* XEN_FW_DISK_INFO */ + struct { + uint8_t device; /* bios device number */ + uint32_t mbr_signature; /* offset 0x1b8 in mbr */ + } disk_mbr_signature; /* XEN_FW_DISK_MBR_SIGNATURE */ + struct { + /* Int10, AX=4F15: Get EDID info. */ + uint8_t capabilities; + uint8_t edid_transfer_time; + /* must refer to 128-byte buffer */ + GUEST_HANDLE(uchar) edid; + } vbeddc_info; /* XEN_FW_VBEDDC_INFO */ + } u; +}; +DEFINE_GUEST_HANDLE_STRUCT(xenpf_firmware_info_t); + +#define XENPF_enter_acpi_sleep 51 +struct xenpf_enter_acpi_sleep { + /* IN variables */ + uint16_t pm1a_cnt_val; /* PM1a control value. */ + uint16_t pm1b_cnt_val; /* PM1b control value. */ + uint32_t sleep_state; /* Which state to enter (Sn). */ + uint32_t flags; /* Must be zero. */ +}; +DEFINE_GUEST_HANDLE_STRUCT(xenpf_enter_acpi_sleep_t); + +#define XENPF_change_freq 52 +struct xenpf_change_freq { + /* IN variables */ + uint32_t flags; /* Must be zero. */ + uint32_t cpu; /* Physical cpu. */ + uint64_t freq; /* New frequency (Hz). */ +}; +DEFINE_GUEST_HANDLE_STRUCT(xenpf_change_freq_t); + +/* + * Get idle times (nanoseconds since boot) for physical CPUs specified in the + * @cpumap_bitmap with range [0..@cpumap_nr_cpus-1]. The @idletime array is + * indexed by CPU number; only entries with the corresponding @cpumap_bitmap + * bit set are written to. On return, @cpumap_bitmap is modified so that any + * non-existent CPUs are cleared. Such CPUs have their @idletime array entry + * cleared. + */ +#define XENPF_getidletime 53 +struct xenpf_getidletime { + /* IN/OUT variables */ + /* IN: CPUs to interrogate; OUT: subset of IN which are present */ + GUEST_HANDLE(uchar) cpumap_bitmap; + /* IN variables */ + /* Size of cpumap bitmap. */ + uint32_t cpumap_nr_cpus; + /* Must be indexable for every cpu in cpumap_bitmap. */ + GUEST_HANDLE(uint64_t) idletime; + /* OUT variables */ + /* System time when the idletime snapshots were taken. */ + uint64_t now; +}; +DEFINE_GUEST_HANDLE_STRUCT(xenpf_getidletime_t); + +#define XENPF_set_processor_pminfo 54 + +/* ability bits */ +#define XEN_PROCESSOR_PM_CX 1 +#define XEN_PROCESSOR_PM_PX 2 +#define XEN_PROCESSOR_PM_TX 4 + +/* cmd type */ +#define XEN_PM_CX 0 +#define XEN_PM_PX 1 +#define XEN_PM_TX 2 + +/* Px sub info type */ +#define XEN_PX_PCT 1 +#define XEN_PX_PSS 2 +#define XEN_PX_PPC 4 +#define XEN_PX_PSD 8 + +struct xen_power_register { + uint32_t space_id; + uint32_t bit_width; + uint32_t bit_offset; + uint32_t access_size; + uint64_t address; +}; + +struct xen_processor_csd { + uint32_t domain; /* domain number of one dependent group */ + uint32_t coord_type; /* coordination type */ + uint32_t num; /* number of processors in same domain */ +}; +DEFINE_GUEST_HANDLE_STRUCT(xen_processor_csd); + +struct xen_processor_cx { + struct xen_power_register reg; /* GAS for Cx trigger register */ + uint8_t type; /* cstate value, c0: 0, c1: 1, ... */ + uint32_t latency; /* worst latency (ms) to enter/exit this cstate */ + uint32_t power; /* average power consumption(mW) */ + uint32_t dpcnt; /* number of dependency entries */ + GUEST_HANDLE(xen_processor_csd) dp; /* NULL if no dependency */ +}; +DEFINE_GUEST_HANDLE_STRUCT(xen_processor_cx); + +struct xen_processor_flags { + uint32_t bm_control:1; + uint32_t bm_check:1; + uint32_t has_cst:1; + uint32_t power_setup_done:1; + uint32_t bm_rld_set:1; +}; + +struct xen_processor_power { + uint32_t count; /* number of C state entries in array below */ + struct xen_processor_flags flags; /* global flags of this processor */ + GUEST_HANDLE(xen_processor_cx) states; /* supported c states */ +}; + +struct xen_pct_register { + uint8_t descriptor; + uint16_t length; + uint8_t space_id; + uint8_t bit_width; + uint8_t bit_offset; + uint8_t reserved; + uint64_t address; +}; + +struct xen_processor_px { + uint64_t core_frequency; /* megahertz */ + uint64_t power; /* milliWatts */ + uint64_t transition_latency; /* microseconds */ + uint64_t bus_master_latency; /* microseconds */ + uint64_t control; /* control value */ + uint64_t status; /* success indicator */ +}; +DEFINE_GUEST_HANDLE_STRUCT(xen_processor_px); + +struct xen_psd_package { + uint64_t num_entries; + uint64_t revision; + uint64_t domain; + uint64_t coord_type; + uint64_t num_processors; +}; + +struct xen_processor_performance { + uint32_t flags; /* flag for Px sub info type */ + uint32_t platform_limit; /* Platform limitation on freq usage */ + struct xen_pct_register control_register; + struct xen_pct_register status_register; + uint32_t state_count; /* total available performance states */ + GUEST_HANDLE(xen_processor_px) states; + struct xen_psd_package domain_info; + uint32_t shared_type; /* coordination type of this processor */ +}; +DEFINE_GUEST_HANDLE_STRUCT(xen_processor_performance); + +struct xenpf_set_processor_pminfo { + /* IN variables */ + uint32_t id; /* ACPI CPU ID */ + uint32_t type; /* {XEN_PM_CX, XEN_PM_PX} */ + union { + struct xen_processor_power power;/* Cx: _CST/_CSD */ + struct xen_processor_performance perf; /* Px: _PPC/_PCT/_PSS/_PSD */ + }; +}; +DEFINE_GUEST_HANDLE_STRUCT(xenpf_set_processor_pminfo); + +struct xen_platform_op { + uint32_t cmd; + uint32_t interface_version; /* XENPF_INTERFACE_VERSION */ + union { + struct xenpf_settime settime; + struct xenpf_add_memtype add_memtype; + struct xenpf_del_memtype del_memtype; + struct xenpf_read_memtype read_memtype; + struct xenpf_microcode_update microcode; + struct xenpf_platform_quirk platform_quirk; + struct xenpf_firmware_info firmware_info; + struct xenpf_enter_acpi_sleep enter_acpi_sleep; + struct xenpf_change_freq change_freq; + struct xenpf_getidletime getidletime; + struct xenpf_set_processor_pminfo set_pminfo; + uint8_t pad[128]; + } u; +}; +DEFINE_GUEST_HANDLE_STRUCT(xen_platform_op_t); + +#endif /* __XEN_PUBLIC_PLATFORM_H__ */ diff --git a/include/xen/interface/xen.h b/include/xen/interface/xen.h index b33257b..063ed39 100644 --- a/include/xen/interface/xen.h +++ b/include/xen/interface/xen.h @@ -452,6 +452,7 @@ struct start_info { /* These flags are passed in the 'flags' field of start_info_t. */ #define SIF_PRIVILEGED (1<<0) /* Is the domain privileged? */ #define SIF_INITDOMAIN (1<<1) /* Is this the initial control domain? */ +#define SIF_PM_MASK (0xFF<<8) /* reserve 1 byte for xen-pm options */ typedef uint64_t cpumap_t; -- 1.7.6.2 _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel From xen-devel-bounces@lists.xensource.com Mon Sep 26 11:22:34 2011 Return-path: <xen-devel-bounces@lists.xensource.com> Envelope-to: www-data@lists.xensource.com Delivery-date: Mon, 26 Sep 2011 11:22:34 -0700 Received: from localhost ([127.0.0.1] helo=lists.colo.xensource.com) by lists.xensource.com with esmtp (Exim 4.43) id 1R8Fp4-00012V-TV; Mon, 26 Sep 2011 11:22:34 -0700 Received: from mail21.messagelabs.com ([85.158.143.35]) by lists.xensource.com with esmtp (Exim 4.43) id 1R8Fkw-00086I-3E for xen-devel@lists.xensource.com; Mon, 26 Sep 2011 11:18:20 -0700 X-Env-Sender: jeremy@goop.org X-Msg-Ref: server-14.tower-21.messagelabs.com!1317061084!61047667!1 X-Originating-IP: [74.207.240.146] X-StarScan-Version: 6.4.1; banners=-,-,- X-VirusChecked: Checked Received: (qmail 25902 invoked from network); 26 Sep 2011 18:18:06 -0000 Received: from claw.goop.org (HELO claw.goop.org) (74.207.240.146) by server-14.tower-21.messagelabs.com with DHE-RSA-AES256-SHA encrypted SMTP; 26 Sep 2011 18:18:06 -0000 Received: from saboo.goop.org (unknown [IPv6:2001:470:1f05:899:d4cf:8dff:fec9:d94b]) (Authenticated sender: smtp-saboo) by claw.goop.org (Postfix) with ESMTPSA id A04E4A069; Mon, 26 Sep 2011 11:18:12 -0700 (PDT) Received: by saboo.goop.org (Postfix, from userid 500) id E4A5B208D1; Mon, 26 Sep 2011 11:18:04 -0700 (PDT) From: Jeremy Fitzhardinge <jeremy@goop.org> To: "H. Peter Anvin" <hpa@zytor.com> Date: Mon, 26 Sep 2011 11:18:01 -0700 Message-Id: <c0daea995be5dd647dde40ca1ed6de34a9ba6040.1317060617.git.jeremy.fitzhardinge@citrix.com> X-Mailer: git-send-email 1.7.6.2 In-Reply-To: <cover.1317060617.git.jeremy.fitzhardinge@citrix.com> References: <cover.1317060617.git.jeremy.fitzhardinge@citrix.com> In-Reply-To: <cover.1317060617.git.jeremy.fitzhardinge@citrix.com> References: <cover.1317060617.git.jeremy.fitzhardinge@citrix.com> Cc: Jeremy Fitzhardinge <jeremy.fitzhardinge@citrix.com>, the arch/x86 maintainers <x86@kernel.org>, Xen Devel <xen-devel@lists.xensource.com>, Tigran Aivazian <tigran@aivazian.fsnet.co.uk>, Linux Kernel Mailing List <linux-kernel@vger.kernel.org> Subject: [Xen-devel] [PATCH 2/3] xen: add dom0_op hypercall X-BeenThere: xen-devel@lists.xensource.com X-Mailman-Version: 2.1.5 Precedence: list List-Id: Xen developer discussion <xen-devel.lists.xensource.com> List-Unsubscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe> List-Post: <mailto:xen-devel@lists.xensource.com> List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help> List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=subscribe> Sender: xen-devel-bounces@lists.xensource.com Errors-To: xen-devel-bounces@lists.xensource.com From: Jeremy Fitzhardinge <jeremy.fitzhardinge@citrix.com> Signed-off-by: Jeremy Fitzhardinge <jeremy.fitzhardinge@citrix.com> --- arch/x86/include/asm/xen/hypercall.h | 8 ++++++++ 1 files changed, 8 insertions(+), 0 deletions(-) diff --git a/arch/x86/include/asm/xen/hypercall.h b/arch/x86/include/asm/xen/hypercall.h index 8508bfe..93762ff 100644 --- a/arch/x86/include/asm/xen/hypercall.h +++ b/arch/x86/include/asm/xen/hypercall.h @@ -45,6 +45,7 @@ #include <xen/interface/xen.h> #include <xen/interface/sched.h> #include <xen/interface/physdev.h> +#include <xen/interface/platform.h> /* * The hypercall asms have to meet several constraints: @@ -299,6 +300,13 @@ HYPERVISOR_set_timer_op(u64 timeout) } static inline int +HYPERVISOR_dom0_op(struct xen_platform_op *platform_op) +{ + platform_op->interface_version = XENPF_INTERFACE_VERSION; + return _hypercall1(int, dom0_op, platform_op); +} + +static inline int HYPERVISOR_set_debugreg(int reg, unsigned long value) { return _hypercall2(int, set_debugreg, reg, value); -- 1.7.6.2 _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel From xen-devel-bounces@lists.xensource.com Mon Sep 26 11:24:29 2011 Return-path: <xen-devel-bounces@lists.xensource.com> Envelope-to: www-data@lists.xensource.com Delivery-date: Mon, 26 Sep 2011 11:24:29 -0700 Received: from localhost ([127.0.0.1] helo=lists.colo.xensource.com) by lists.xensource.com with esmtp (Exim 4.43) id 1R8Fqv-0001VU-Ga; Mon, 26 Sep 2011 11:24:29 -0700 Received: from mail174.messagelabs.com ([85.158.138.51]) by lists.xensource.com with esmtp (Exim 4.43) id 1R8FqA-0001Iw-6M for xen-devel@lists.xensource.com; Mon, 26 Sep 2011 11:23:42 -0700 X-Env-Sender: jeremy@goop.org X-Msg-Ref: server-9.tower-174.messagelabs.com!1317061417!26798033!1 X-Originating-IP: [74.207.240.146] X-StarScan-Version: 6.4.1; banners=-,-,- X-VirusChecked: Checked Received: (qmail 6517 invoked from network); 26 Sep 2011 18:23:38 -0000 Received: from claw.goop.org (HELO claw.goop.org) (74.207.240.146) by server-9.tower-174.messagelabs.com with DHE-RSA-AES256-SHA encrypted SMTP; 26 Sep 2011 18:23:38 -0000 Received: from saboo.goop.org (unknown [IPv6:2001:470:1f05:899:d4cf:8dff:fec9:d94b]) (Authenticated sender: smtp-saboo) by claw.goop.org (Postfix) with ESMTPSA id 7B788A06A; Mon, 26 Sep 2011 11:23:36 -0700 (PDT) Received: from saboo.goop.org (localhost [IPv6:::1]) by saboo.goop.org (Postfix) with ESMTP id B11DF2043F; Mon, 26 Sep 2011 09:22:21 -0700 (PDT) Message-ID: <4E80A6BD.3070703@goop.org> Date: Mon, 26 Sep 2011 09:22:21 -0700 From: Jeremy Fitzhardinge <jeremy@goop.org> User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:6.0.2) Gecko/20110906 Thunderbird/6.0.2 MIME-Version: 1.0 To: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com> References: <1317042797-19975-1-git-send-email-konrad.wilk@oracle.com> In-Reply-To: <1317042797-19975-1-git-send-email-konrad.wilk@oracle.com> X-Enigmail-Version: 1.3.2 Content-Type: text/plain; charset=ISO-8859-15 Content-Transfer-Encoding: 7bit Cc: xen-devel@lists.xensource.com, Peter Zijlstra <a.p.zijlstra@chello.nl>, Jeremy Fitzhardinge <jeremy.fitzhardinge@citrix.com>, x86@kernel.org, linux-kernel@vger.kernel.org, Ingo Molnar <mingo@redhat.com>, "H. Peter Anvin" <hpa@zytor.com>, Thomas Gleixner <tglx@linutronix.de>, stable@kernel.org Subject: [Xen-devel] Re: [PATCH] x86/paravirt: Partially revert "remove lazy mode in interrupts" X-BeenThere: xen-devel@lists.xensource.com X-Mailman-Version: 2.1.5 Precedence: list List-Id: Xen developer discussion <xen-devel.lists.xensource.com> List-Unsubscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe> List-Post: <mailto:xen-devel@lists.xensource.com> List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help> List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=subscribe> Sender: xen-devel-bounces@lists.xensource.com Errors-To: xen-devel-bounces@lists.xensource.com On 09/26/2011 06:13 AM, Konrad Rzeszutek Wilk wrote: > which has git commit b8bcfe997e46150fedcc3f5b26b846400122fdd9. > > The unintended consequence of removing the flushing of MMU > updates when doing kmap_atomic (or kunmap_atomic) is that we can > hit a dereference bug when processing a "fork()" under a heavy loaded > machine. Specifically we can hit: The patch is all OK, but I wouldn't have headlined it as a "partial revert" - the important point is that the pte updates in k(un)map_atomic need to be synchronous, regardless of whether we're in lazy_mmu mode. The fact that b8bcfe997e4 introduced the problem is interesting to note, but only somewhat relevant to the analysis of what's being fixed here. J > > BUG: unable to handle kernel paging request at f573fc8c > IP: [<c01abc54>] swap_count_continued+0x104/0x180 > *pdpt = 000000002a3b9027 *pde = 0000000001bed067 *pte = 0000000000000000 > Oops: 0000 [#1] SMP > Modules linked in: > Pid: 1638, comm: apache2 Not tainted 3.0.4-linode37 #1 > EIP: 0061:[<c01abc54>] EFLAGS: 00210246 CPU: 3 > EIP is at swap_count_continued+0x104/0x180 > .. snip.. > Call Trace: > [<c01ac222>] ? __swap_duplicate+0xc2/0x160 > [<c01040f7>] ? pte_mfn_to_pfn+0x87/0xe0 > [<c01ac2e4>] ? swap_duplicate+0x14/0x40 > [<c01a0a6b>] ? copy_pte_range+0x45b/0x500 > [<c01a0ca5>] ? copy_page_range+0x195/0x200 > [<c01328c6>] ? dup_mmap+0x1c6/0x2c0 > [<c0132cf8>] ? dup_mm+0xa8/0x130 > [<c013376a>] ? copy_process+0x98a/0xb30 > [<c013395f>] ? do_fork+0x4f/0x280 > [<c01573b3>] ? getnstimeofday+0x43/0x100 > [<c010f770>] ? sys_clone+0x30/0x40 > [<c06c048d>] ? ptregs_clone+0x15/0x48 > [<c06bfb71>] ? syscall_call+0x7/0xb > > The problem looks that in copy_page_range we turn lazy mode on, and then > in swap_entry_free we call swap_count_continued which ends up in: > > map = kmap_atomic(page, KM_USER0) + offset; > > and then later touches *map. > > Since we are running in batched mode (lazy) we don't actually set up the > PTE mappings and the kmap_atomic is not done synchronously and ends up > trying to dereference a page that has not been set. > > Looking at kmap_atomic_prot_pfn, it uses 'arch_flush_lazy_mmu_mode' and > sprinkling that in kmap_atomic_prot and __kunmap_atomic makes the problem > go away. > > CC: Thomas Gleixner <tglx@linutronix.de> > CC: Ingo Molnar <mingo@redhat.com> > CC: "H. Peter Anvin" <hpa@zytor.com> > CC: x86@kernel.org > CC: Peter Zijlstra <a.p.zijlstra@chello.nl> > CC: Jeremy Fitzhardinge <jeremy.fitzhardinge@citrix.com> > CC: stable@kernel.org > Signed-off-by: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com> > --- > arch/x86/mm/highmem_32.c | 2 ++ > 1 files changed, 2 insertions(+), 0 deletions(-) > > diff --git a/arch/x86/mm/highmem_32.c b/arch/x86/mm/highmem_32.c > index b499626..f4f29b1 100644 > --- a/arch/x86/mm/highmem_32.c > +++ b/arch/x86/mm/highmem_32.c > @@ -45,6 +45,7 @@ void *kmap_atomic_prot(struct page *page, pgprot_t prot) > vaddr = __fix_to_virt(FIX_KMAP_BEGIN + idx); > BUG_ON(!pte_none(*(kmap_pte-idx))); > set_pte(kmap_pte-idx, mk_pte(page, prot)); > + arch_flush_lazy_mmu_mode(); > > return (void *)vaddr; > } > @@ -88,6 +89,7 @@ void __kunmap_atomic(void *kvaddr) > */ > kpte_clear_flush(kmap_pte-idx, vaddr); > kmap_atomic_idx_pop(); > + arch_flush_lazy_mmu_mode(); > } > #ifdef CONFIG_DEBUG_HIGHMEM > else { _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel From xen-devel-bounces@lists.xensource.com Mon Sep 26 11:28:29 2011 Return-path: <xen-devel-bounces@lists.xensource.com> Envelope-to: www-data@lists.xensource.com Delivery-date: Mon, 26 Sep 2011 11:28:29 -0700 Received: from localhost ([127.0.0.1] helo=lists.colo.xensource.com) by lists.xensource.com with esmtp (Exim 4.43) id 1R8Ful-0001wr-Io; Mon, 26 Sep 2011 11:28:27 -0700 Received: from mail216.messagelabs.com ([85.158.143.99]) by lists.xensource.com with esmtp (Exim 4.43) id 1R8Ftv-0001jS-09 for xen-devel@lists.xensource.com; Mon, 26 Sep 2011 11:27:35 -0700 X-Env-Sender: jeremy@goop.org X-Msg-Ref: server-3.tower-216.messagelabs.com!1317061650!18630579!1 X-Originating-IP: [74.207.240.146] X-StarScan-Version: 6.4.1; banners=-,-,- X-VirusChecked: Checked Received: (qmail 24893 invoked from network); 26 Sep 2011 18:27:31 -0000 Received: from claw.goop.org (HELO claw.goop.org) (74.207.240.146) by server-3.tower-216.messagelabs.com with DHE-RSA-AES256-SHA encrypted SMTP; 26 Sep 2011 18:27:31 -0000 Received: from saboo.goop.org (unknown [IPv6:2001:470:1f05:899:d4cf:8dff:fec9:d94b]) (Authenticated sender: smtp-saboo) by claw.goop.org (Postfix) with ESMTPSA id BA167A083; Mon, 26 Sep 2011 11:27:29 -0700 (PDT) Received: by saboo.goop.org (Postfix, from userid 500) id 3D537208AC; Mon, 26 Sep 2011 11:27:27 -0700 (PDT) From: Jeremy Fitzhardinge <jeremy@goop.org> To: Xen Devel <xen-devel@lists.xensource.com> Date: Mon, 26 Sep 2011 11:27:22 -0700 Message-Id: <cover.1317061152.git.jeremy.fitzhardinge@citrix.com> X-Mailer: git-send-email 1.7.6.2 Cc: the arch/x86 maintainers <x86@kernel.org>, Linux Kernel Mailing List <linux-kernel@vger.kernel.org>, Jeremy Fitzhardinge <jeremy.fitzhardinge@citrix.com>, Stable Kernel <stable@kernel.org> Subject: [Xen-devel] [PATCH RFC 0/3] xen: enable settime in Xen dom0 X-BeenThere: xen-devel@lists.xensource.com X-Mailman-Version: 2.1.5 Precedence: list List-Id: Xen developer discussion <xen-devel.lists.xensource.com> List-Unsubscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe> List-Post: <mailto:xen-devel@lists.xensource.com> List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help> List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=subscribe> Sender: xen-devel-bounces@lists.xensource.com Errors-To: xen-devel-bounces@lists.xensource.com From: Jeremy Fitzhardinge <jeremy.fitzhardinge@citrix.com> Proposed patch for the v3.2 merge window, but it should be probably be put into v3.0 and v3.1 stable branches too (but not important enough to burn any of my "Linus, merge this in late -rc karma"). This series implements the time-setting pvops for Xen dom0 so that a privileged kernel can set the system time via Xen. This had previously been a no-op, because upstream Linux only supported non-privieged operation, and so there was no point in trying to set the system time. Also available at: git://github.com/jsgf/linux-xen.git upstream/xen-settime Thanks, J Jeremy Fitzhardinge (2): xen: add dom0_op hypercall xen/dom0: set wallclock time in Xen Yu Ke (1): xen/acpi: Domain0 acpi parser related platform hypercall arch/ia64/include/asm/xen/interface.h | 1 + arch/x86/include/asm/xen/hypercall.h | 8 + arch/x86/include/asm/xen/interface.h | 1 + arch/x86/xen/time.c | 16 ++- include/xen/interface/platform.h | 320 +++++++++++++++++++++++++++++++++ include/xen/interface/xen.h | 1 + 6 files changed, 346 insertions(+), 1 deletions(-) create mode 100644 include/xen/interface/platform.h -- 1.7.6.2 _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel From xen-devel-bounces@lists.xensource.com Mon Sep 26 11:29:57 2011 Return-path: <xen-devel-bounces@lists.xensource.com> Envelope-to: www-data@lists.xensource.com Delivery-date: Mon, 26 Sep 2011 11:29:57 -0700 Received: from localhost ([127.0.0.1] helo=lists.colo.xensource.com) by lists.xensource.com with esmtp (Exim 4.43) id 1R8FwD-0002Jy-Ca; Mon, 26 Sep 2011 11:29:57 -0700 Received: from mail21.messagelabs.com ([85.158.143.35]) by lists.xensource.com with esmtp (Exim 4.43) id 1R8Ftt-0001jP-W0 for xen-devel@lists.xensource.com; Mon, 26 Sep 2011 11:27:35 -0700 X-Env-Sender: jeremy@goop.org X-Msg-Ref: server-9.tower-21.messagelabs.com!1317061604!49883753!1 X-Originating-IP: [74.207.240.146] X-StarScan-Version: 6.4.1; banners=-,-,- X-VirusChecked: Checked Received: (qmail 7547 invoked from network); 26 Sep 2011 18:26:45 -0000 Received: from claw.goop.org (HELO claw.goop.org) (74.207.240.146) by server-9.tower-21.messagelabs.com with DHE-RSA-AES256-SHA encrypted SMTP; 26 Sep 2011 18:26:45 -0000 Received: from saboo.goop.org (unknown [IPv6:2001:470:1f05:899:d4cf:8dff:fec9:d94b]) (Authenticated sender: smtp-saboo) by claw.goop.org (Postfix) with ESMTPSA id F26CBA07E; Mon, 26 Sep 2011 11:27:28 -0700 (PDT) Received: by saboo.goop.org (Postfix, from userid 500) id 57F31208D1; Mon, 26 Sep 2011 11:27:27 -0700 (PDT) From: Jeremy Fitzhardinge <jeremy@goop.org> To: Xen Devel <xen-devel@lists.xensource.com> Date: Mon, 26 Sep 2011 11:27:25 -0700 Message-Id: <fdb9eb9f155bfc0f8dc2fc88f90448b30c78ad97.1317061152.git.jeremy.fitzhardinge@citrix.com> X-Mailer: git-send-email 1.7.6.2 In-Reply-To: <cover.1317061152.git.jeremy.fitzhardinge@citrix.com> References: <cover.1317061152.git.jeremy.fitzhardinge@citrix.com> In-Reply-To: <cover.1317061152.git.jeremy.fitzhardinge@citrix.com> References: <cover.1317061152.git.jeremy.fitzhardinge@citrix.com> Cc: the arch/x86 maintainers <x86@kernel.org>, Linux Kernel Mailing List <linux-kernel@vger.kernel.org>, Jeremy Fitzhardinge <jeremy.fitzhardinge@citrix.com>, Stable Kernel <stable@kernel.org> Subject: [Xen-devel] [PATCH 3/3] xen/dom0: set wallclock time in Xen X-BeenThere: xen-devel@lists.xensource.com X-Mailman-Version: 2.1.5 Precedence: list List-Id: Xen developer discussion <xen-devel.lists.xensource.com> List-Unsubscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe> List-Post: <mailto:xen-devel@lists.xensource.com> List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help> List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=subscribe> Sender: xen-devel-bounces@lists.xensource.com Errors-To: xen-devel-bounces@lists.xensource.com From: Jeremy Fitzhardinge <jeremy.fitzhardinge@citrix.com> Signed-off-by: Jeremy Fitzhardinge <jeremy.fitzhardinge@citrix.com> --- arch/x86/xen/time.c | 16 +++++++++++++++- 1 files changed, 15 insertions(+), 1 deletions(-) diff --git a/arch/x86/xen/time.c b/arch/x86/xen/time.c index 5158c50..8c9cdfa 100644 --- a/arch/x86/xen/time.c +++ b/arch/x86/xen/time.c @@ -200,8 +200,22 @@ static unsigned long xen_get_wallclock(void) static int xen_set_wallclock(unsigned long now) { + struct xen_platform_op op; + int rc; + /* do nothing for domU */ - return -1; + if (!xen_initial_domain()) + return -1; + + op.cmd = XENPF_settime; + op.u.settime.secs = now; + op.u.settime.nsecs = 0; + op.u.settime.system_time = xen_clocksource_read(); + + rc = HYPERVISOR_dom0_op(&op); + WARN(rc != 0, "XENPF_settime failed: now=%ld\n", now); + + return rc; } static struct clocksource xen_clocksource __read_mostly = { -- 1.7.6.2 _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel From xen-devel-bounces@lists.xensource.com Mon Sep 26 11:31:26 2011 Return-path: <xen-devel-bounces@lists.xensource.com> Envelope-to: www-data@lists.xensource.com Delivery-date: Mon, 26 Sep 2011 11:31:26 -0700 Received: from localhost ([127.0.0.1] helo=lists.colo.xensource.com) by lists.xensource.com with esmtp (Exim 4.43) id 1R8Fxe-0002hV-LI; Mon, 26 Sep 2011 11:31:26 -0700 Received: from mail21.messagelabs.com ([85.158.143.35]) by lists.xensource.com with esmtp (Exim 4.43) id 1R8Ftt-0001jQ-W5 for xen-devel@lists.xensource.com; Mon, 26 Sep 2011 11:27:34 -0700 X-Env-Sender: jeremy@goop.org X-Msg-Ref: server-8.tower-21.messagelabs.com!1317061632!60441026!1 X-Originating-IP: [74.207.240.146] X-StarScan-Version: 6.4.1; banners=-,-,- X-VirusChecked: Checked Received: (qmail 21192 invoked from network); 26 Sep 2011 18:27:14 -0000 Received: from claw.goop.org (HELO claw.goop.org) (74.207.240.146) by server-8.tower-21.messagelabs.com with DHE-RSA-AES256-SHA encrypted SMTP; 26 Sep 2011 18:27:14 -0000 Received: from saboo.goop.org (unknown [IPv6:2001:470:1f05:899:d4cf:8dff:fec9:d94b]) (Authenticated sender: smtp-saboo) by claw.goop.org (Postfix) with ESMTPSA id C847BA07C; Mon, 26 Sep 2011 11:27:28 -0700 (PDT) Received: by saboo.goop.org (Postfix, from userid 500) id 4E72B208CC; Mon, 26 Sep 2011 11:27:27 -0700 (PDT) From: Jeremy Fitzhardinge <jeremy@goop.org> To: Xen Devel <xen-devel@lists.xensource.com> Date: Mon, 26 Sep 2011 11:27:24 -0700 Message-Id: <eec07a9ecf428a680d72dc7f2428ea8bed80b84d.1317061152.git.jeremy.fitzhardinge@citrix.com> X-Mailer: git-send-email 1.7.6.2 In-Reply-To: <cover.1317061152.git.jeremy.fitzhardinge@citrix.com> References: <cover.1317061152.git.jeremy.fitzhardinge@citrix.com> In-Reply-To: <cover.1317061152.git.jeremy.fitzhardinge@citrix.com> References: <cover.1317061152.git.jeremy.fitzhardinge@citrix.com> Cc: the arch/x86 maintainers <x86@kernel.org>, Linux Kernel Mailing List <linux-kernel@vger.kernel.org>, Jeremy Fitzhardinge <jeremy.fitzhardinge@citrix.com>, Stable Kernel <stable@kernel.org> Subject: [Xen-devel] [PATCH 2/3] xen: add dom0_op hypercall X-BeenThere: xen-devel@lists.xensource.com X-Mailman-Version: 2.1.5 Precedence: list List-Id: Xen developer discussion <xen-devel.lists.xensource.com> List-Unsubscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe> List-Post: <mailto:xen-devel@lists.xensource.com> List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help> List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=subscribe> Sender: xen-devel-bounces@lists.xensource.com Errors-To: xen-devel-bounces@lists.xensource.com From: Jeremy Fitzhardinge <jeremy.fitzhardinge@citrix.com> Signed-off-by: Jeremy Fitzhardinge <jeremy.fitzhardinge@citrix.com> --- arch/x86/include/asm/xen/hypercall.h | 8 ++++++++ 1 files changed, 8 insertions(+), 0 deletions(-) diff --git a/arch/x86/include/asm/xen/hypercall.h b/arch/x86/include/asm/xen/hypercall.h index d240ea9..0c9894e 100644 --- a/arch/x86/include/asm/xen/hypercall.h +++ b/arch/x86/include/asm/xen/hypercall.h @@ -45,6 +45,7 @@ #include <xen/interface/xen.h> #include <xen/interface/sched.h> #include <xen/interface/physdev.h> +#include <xen/interface/platform.h> /* * The hypercall asms have to meet several constraints: @@ -299,6 +300,13 @@ HYPERVISOR_set_timer_op(u64 timeout) } static inline int +HYPERVISOR_dom0_op(struct xen_platform_op *platform_op) +{ + platform_op->interface_version = XENPF_INTERFACE_VERSION; + return _hypercall1(int, dom0_op, platform_op); +} + +static inline int HYPERVISOR_set_debugreg(int reg, unsigned long value) { return _hypercall2(int, set_debugreg, reg, value); -- 1.7.6.2 _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel From xen-devel-bounces@lists.xensource.com Mon Sep 26 11:32:59 2011 Return-path: <xen-devel-bounces@lists.xensource.com> Envelope-to: www-data@lists.xensource.com Delivery-date: Mon, 26 Sep 2011 11:32:59 -0700 Received: from localhost ([127.0.0.1] helo=lists.colo.xensource.com) by lists.xensource.com with esmtp (Exim 4.43) id 1R8Fz9-00034e-Fl; Mon, 26 Sep 2011 11:32:59 -0700 Received: from mail27.messagelabs.com ([193.109.254.147]) by lists.xensource.com with esmtp (Exim 4.43) id 1R8Ftu-0001jR-G5 for xen-devel@lists.xensource.com; Mon, 26 Sep 2011 11:27:35 -0700 X-Env-Sender: jeremy@goop.org X-Msg-Ref: server-6.tower-27.messagelabs.com!1317061629!50550451!1 X-Originating-IP: [74.207.240.146] X-StarScan-Version: 6.4.1; banners=-,-,- X-VirusChecked: Checked Received: (qmail 20761 invoked from network); 26 Sep 2011 18:27:11 -0000 Received: from claw.goop.org (HELO claw.goop.org) (74.207.240.146) by server-6.tower-27.messagelabs.com with DHE-RSA-AES256-SHA encrypted SMTP; 26 Sep 2011 18:27:11 -0000 Received: from saboo.goop.org (unknown [IPv6:2001:470:1f05:899:d4cf:8dff:fec9:d94b]) (Authenticated sender: smtp-saboo) by claw.goop.org (Postfix) with ESMTPSA id F2684A07D; Mon, 26 Sep 2011 11:27:28 -0700 (PDT) Received: by saboo.goop.org (Postfix, from userid 500) id 4495C208C4; Mon, 26 Sep 2011 11:27:27 -0700 (PDT) From: Jeremy Fitzhardinge <jeremy@goop.org> To: Xen Devel <xen-devel@lists.xensource.com> Date: Mon, 26 Sep 2011 11:27:23 -0700 Message-Id: <3e0996798a6a113efae9e0187c5581491bdb07a7.1317061152.git.jeremy.fitzhardinge@citrix.com> X-Mailer: git-send-email 1.7.6.2 In-Reply-To: <cover.1317061152.git.jeremy.fitzhardinge@citrix.com> References: <cover.1317061152.git.jeremy.fitzhardinge@citrix.com> In-Reply-To: <cover.1317061152.git.jeremy.fitzhardinge@citrix.com> References: <cover.1317061152.git.jeremy.fitzhardinge@citrix.com> Cc: Tian Kevin <kevin.tian@intel.com>, Jeremy Fitzhardinge <jeremy.fitzhardinge@citrix.com>, Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>, the arch/x86 maintainers <x86@kernel.org>, Linux Kernel Mailing List <linux-kernel@vger.kernel.org>, Yu Ke <ke.yu@intel.com>, Stable Kernel <stable@kernel.org> Subject: [Xen-devel] [PATCH 1/3] xen/acpi: Domain0 acpi parser related platform hypercall X-BeenThere: xen-devel@lists.xensource.com X-Mailman-Version: 2.1.5 Precedence: list List-Id: Xen developer discussion <xen-devel.lists.xensource.com> List-Unsubscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe> List-Post: <mailto:xen-devel@lists.xensource.com> List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help> List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=subscribe> Sender: xen-devel-bounces@lists.xensource.com Errors-To: xen-devel-bounces@lists.xensource.com From: Yu Ke <ke.yu@intel.com> This patches implements the xen_platform_op hypercall, to pass the parsed ACPI info to hypervisor. Signed-off-by: Yu Ke <ke.yu@intel.com> Signed-off-by: Tian Kevin <kevin.tian@intel.com> Signed-off-by: Jeremy Fitzhardinge <jeremy.fitzhardinge@citrix.com> [v1: Added DEFINE_GUEST.. in appropiate headers] [v2: Ripped out typedefs] Signed-off-by: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com> --- arch/ia64/include/asm/xen/interface.h | 1 + arch/x86/include/asm/xen/interface.h | 1 + include/xen/interface/platform.h | 320 +++++++++++++++++++++++++++++++++ include/xen/interface/xen.h | 1 + 4 files changed, 323 insertions(+), 0 deletions(-) create mode 100644 include/xen/interface/platform.h diff --git a/arch/ia64/include/asm/xen/interface.h b/arch/ia64/include/asm/xen/interface.h index e951e74..1d2427d 100644 --- a/arch/ia64/include/asm/xen/interface.h +++ b/arch/ia64/include/asm/xen/interface.h @@ -76,6 +76,7 @@ DEFINE_GUEST_HANDLE(char); DEFINE_GUEST_HANDLE(int); DEFINE_GUEST_HANDLE(long); DEFINE_GUEST_HANDLE(void); +DEFINE_GUEST_HANDLE(uint64_t); typedef unsigned long xen_pfn_t; DEFINE_GUEST_HANDLE(xen_pfn_t); diff --git a/arch/x86/include/asm/xen/interface.h b/arch/x86/include/asm/xen/interface.h index 5d4922a..a1f2db5 100644 --- a/arch/x86/include/asm/xen/interface.h +++ b/arch/x86/include/asm/xen/interface.h @@ -55,6 +55,7 @@ DEFINE_GUEST_HANDLE(char); DEFINE_GUEST_HANDLE(int); DEFINE_GUEST_HANDLE(long); DEFINE_GUEST_HANDLE(void); +DEFINE_GUEST_HANDLE(uint64_t); #endif #ifndef HYPERVISOR_VIRT_START diff --git a/include/xen/interface/platform.h b/include/xen/interface/platform.h new file mode 100644 index 0000000..c168468 --- /dev/null +++ b/include/xen/interface/platform.h @@ -0,0 +1,320 @@ +/****************************************************************************** + * platform.h + * + * Hardware platform operations. Intended for use by domain-0 kernel. + * + * Permission is hereby granted, free of charge, to any person obtaining a copy + * of this software and associated documentation files (the "Software"), to + * deal in the Software without restriction, including without limitation the + * rights to use, copy, modify, merge, publish, distribute, sublicense, and/or + * sell copies of the Software, and to permit persons to whom the Software is + * furnished to do so, subject to the following conditions: + * + * The above copyright notice and this permission notice shall be included in + * all copies or substantial portions of the Software. + * + * THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR + * IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY, + * FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL THE + * AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER + * LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING + * FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER + * DEALINGS IN THE SOFTWARE. + * + * Copyright (c) 2002-2006, K Fraser + */ + +#ifndef __XEN_PUBLIC_PLATFORM_H__ +#define __XEN_PUBLIC_PLATFORM_H__ + +#include "xen.h" + +#define XENPF_INTERFACE_VERSION 0x03000001 + +/* + * Set clock such that it would read <secs,nsecs> after 00:00:00 UTC, + * 1 January, 1970 if the current system time was <system_time>. + */ +#define XENPF_settime 17 +struct xenpf_settime { + /* IN variables. */ + uint32_t secs; + uint32_t nsecs; + uint64_t system_time; +}; +DEFINE_GUEST_HANDLE_STRUCT(xenpf_settime_t); + +/* + * Request memory range (@mfn, @mfn+@nr_mfns-1) to have type @type. + * On x86, @type is an architecture-defined MTRR memory type. + * On success, returns the MTRR that was used (@reg) and a handle that can + * be passed to XENPF_DEL_MEMTYPE to accurately tear down the new setting. + * (x86-specific). + */ +#define XENPF_add_memtype 31 +struct xenpf_add_memtype { + /* IN variables. */ + unsigned long mfn; + uint64_t nr_mfns; + uint32_t type; + /* OUT variables. */ + uint32_t handle; + uint32_t reg; +}; +DEFINE_GUEST_HANDLE_STRUCT(xenpf_add_memtype_t); + +/* + * Tear down an existing memory-range type. If @handle is remembered then it + * should be passed in to accurately tear down the correct setting (in case + * of overlapping memory regions with differing types). If it is not known + * then @handle should be set to zero. In all cases @reg must be set. + * (x86-specific). + */ +#define XENPF_del_memtype 32 +struct xenpf_del_memtype { + /* IN variables. */ + uint32_t handle; + uint32_t reg; +}; +DEFINE_GUEST_HANDLE_STRUCT(xenpf_del_memtype_t); + +/* Read current type of an MTRR (x86-specific). */ +#define XENPF_read_memtype 33 +struct xenpf_read_memtype { + /* IN variables. */ + uint32_t reg; + /* OUT variables. */ + unsigned long mfn; + uint64_t nr_mfns; + uint32_t type; +}; +DEFINE_GUEST_HANDLE_STRUCT(xenpf_read_memtype_t); + +#define XENPF_microcode_update 35 +struct xenpf_microcode_update { + /* IN variables. */ + GUEST_HANDLE(void) data; /* Pointer to microcode data */ + uint32_t length; /* Length of microcode data. */ +}; +DEFINE_GUEST_HANDLE_STRUCT(xenpf_microcode_update_t); + +#define XENPF_platform_quirk 39 +#define QUIRK_NOIRQBALANCING 1 /* Do not restrict IO-APIC RTE targets */ +#define QUIRK_IOAPIC_BAD_REGSEL 2 /* IO-APIC REGSEL forgets its value */ +#define QUIRK_IOAPIC_GOOD_REGSEL 3 /* IO-APIC REGSEL behaves properly */ +struct xenpf_platform_quirk { + /* IN variables. */ + uint32_t quirk_id; +}; +DEFINE_GUEST_HANDLE_STRUCT(xenpf_platform_quirk_t); + +#define XENPF_firmware_info 50 +#define XEN_FW_DISK_INFO 1 /* from int 13 AH=08/41/48 */ +#define XEN_FW_DISK_MBR_SIGNATURE 2 /* from MBR offset 0x1b8 */ +#define XEN_FW_VBEDDC_INFO 3 /* from int 10 AX=4f15 */ +struct xenpf_firmware_info { + /* IN variables. */ + uint32_t type; + uint32_t index; + /* OUT variables. */ + union { + struct { + /* Int13, Fn48: Check Extensions Present. */ + uint8_t device; /* %dl: bios device number */ + uint8_t version; /* %ah: major version */ + uint16_t interface_support; /* %cx: support bitmap */ + /* Int13, Fn08: Legacy Get Device Parameters. */ + uint16_t legacy_max_cylinder; /* %cl[7:6]:%ch: max cyl # */ + uint8_t legacy_max_head; /* %dh: max head # */ + uint8_t legacy_sectors_per_track; /* %cl[5:0]: max sector # */ + /* Int13, Fn41: Get Device Parameters (as filled into %ds:%esi). */ + /* NB. First uint16_t of buffer must be set to buffer size. */ + GUEST_HANDLE(void) edd_params; + } disk_info; /* XEN_FW_DISK_INFO */ + struct { + uint8_t device; /* bios device number */ + uint32_t mbr_signature; /* offset 0x1b8 in mbr */ + } disk_mbr_signature; /* XEN_FW_DISK_MBR_SIGNATURE */ + struct { + /* Int10, AX=4F15: Get EDID info. */ + uint8_t capabilities; + uint8_t edid_transfer_time; + /* must refer to 128-byte buffer */ + GUEST_HANDLE(uchar) edid; + } vbeddc_info; /* XEN_FW_VBEDDC_INFO */ + } u; +}; +DEFINE_GUEST_HANDLE_STRUCT(xenpf_firmware_info_t); + +#define XENPF_enter_acpi_sleep 51 +struct xenpf_enter_acpi_sleep { + /* IN variables */ + uint16_t pm1a_cnt_val; /* PM1a control value. */ + uint16_t pm1b_cnt_val; /* PM1b control value. */ + uint32_t sleep_state; /* Which state to enter (Sn). */ + uint32_t flags; /* Must be zero. */ +}; +DEFINE_GUEST_HANDLE_STRUCT(xenpf_enter_acpi_sleep_t); + +#define XENPF_change_freq 52 +struct xenpf_change_freq { + /* IN variables */ + uint32_t flags; /* Must be zero. */ + uint32_t cpu; /* Physical cpu. */ + uint64_t freq; /* New frequency (Hz). */ +}; +DEFINE_GUEST_HANDLE_STRUCT(xenpf_change_freq_t); + +/* + * Get idle times (nanoseconds since boot) for physical CPUs specified in the + * @cpumap_bitmap with range [0..@cpumap_nr_cpus-1]. The @idletime array is + * indexed by CPU number; only entries with the corresponding @cpumap_bitmap + * bit set are written to. On return, @cpumap_bitmap is modified so that any + * non-existent CPUs are cleared. Such CPUs have their @idletime array entry + * cleared. + */ +#define XENPF_getidletime 53 +struct xenpf_getidletime { + /* IN/OUT variables */ + /* IN: CPUs to interrogate; OUT: subset of IN which are present */ + GUEST_HANDLE(uchar) cpumap_bitmap; + /* IN variables */ + /* Size of cpumap bitmap. */ + uint32_t cpumap_nr_cpus; + /* Must be indexable for every cpu in cpumap_bitmap. */ + GUEST_HANDLE(uint64_t) idletime; + /* OUT variables */ + /* System time when the idletime snapshots were taken. */ + uint64_t now; +}; +DEFINE_GUEST_HANDLE_STRUCT(xenpf_getidletime_t); + +#define XENPF_set_processor_pminfo 54 + +/* ability bits */ +#define XEN_PROCESSOR_PM_CX 1 +#define XEN_PROCESSOR_PM_PX 2 +#define XEN_PROCESSOR_PM_TX 4 + +/* cmd type */ +#define XEN_PM_CX 0 +#define XEN_PM_PX 1 +#define XEN_PM_TX 2 + +/* Px sub info type */ +#define XEN_PX_PCT 1 +#define XEN_PX_PSS 2 +#define XEN_PX_PPC 4 +#define XEN_PX_PSD 8 + +struct xen_power_register { + uint32_t space_id; + uint32_t bit_width; + uint32_t bit_offset; + uint32_t access_size; + uint64_t address; +}; + +struct xen_processor_csd { + uint32_t domain; /* domain number of one dependent group */ + uint32_t coord_type; /* coordination type */ + uint32_t num; /* number of processors in same domain */ +}; +DEFINE_GUEST_HANDLE_STRUCT(xen_processor_csd); + +struct xen_processor_cx { + struct xen_power_register reg; /* GAS for Cx trigger register */ + uint8_t type; /* cstate value, c0: 0, c1: 1, ... */ + uint32_t latency; /* worst latency (ms) to enter/exit this cstate */ + uint32_t power; /* average power consumption(mW) */ + uint32_t dpcnt; /* number of dependency entries */ + GUEST_HANDLE(xen_processor_csd) dp; /* NULL if no dependency */ +}; +DEFINE_GUEST_HANDLE_STRUCT(xen_processor_cx); + +struct xen_processor_flags { + uint32_t bm_control:1; + uint32_t bm_check:1; + uint32_t has_cst:1; + uint32_t power_setup_done:1; + uint32_t bm_rld_set:1; +}; + +struct xen_processor_power { + uint32_t count; /* number of C state entries in array below */ + struct xen_processor_flags flags; /* global flags of this processor */ + GUEST_HANDLE(xen_processor_cx) states; /* supported c states */ +}; + +struct xen_pct_register { + uint8_t descriptor; + uint16_t length; + uint8_t space_id; + uint8_t bit_width; + uint8_t bit_offset; + uint8_t reserved; + uint64_t address; +}; + +struct xen_processor_px { + uint64_t core_frequency; /* megahertz */ + uint64_t power; /* milliWatts */ + uint64_t transition_latency; /* microseconds */ + uint64_t bus_master_latency; /* microseconds */ + uint64_t control; /* control value */ + uint64_t status; /* success indicator */ +}; +DEFINE_GUEST_HANDLE_STRUCT(xen_processor_px); + +struct xen_psd_package { + uint64_t num_entries; + uint64_t revision; + uint64_t domain; + uint64_t coord_type; + uint64_t num_processors; +}; + +struct xen_processor_performance { + uint32_t flags; /* flag for Px sub info type */ + uint32_t platform_limit; /* Platform limitation on freq usage */ + struct xen_pct_register control_register; + struct xen_pct_register status_register; + uint32_t state_count; /* total available performance states */ + GUEST_HANDLE(xen_processor_px) states; + struct xen_psd_package domain_info; + uint32_t shared_type; /* coordination type of this processor */ +}; +DEFINE_GUEST_HANDLE_STRUCT(xen_processor_performance); + +struct xenpf_set_processor_pminfo { + /* IN variables */ + uint32_t id; /* ACPI CPU ID */ + uint32_t type; /* {XEN_PM_CX, XEN_PM_PX} */ + union { + struct xen_processor_power power;/* Cx: _CST/_CSD */ + struct xen_processor_performance perf; /* Px: _PPC/_PCT/_PSS/_PSD */ + }; +}; +DEFINE_GUEST_HANDLE_STRUCT(xenpf_set_processor_pminfo); + +struct xen_platform_op { + uint32_t cmd; + uint32_t interface_version; /* XENPF_INTERFACE_VERSION */ + union { + struct xenpf_settime settime; + struct xenpf_add_memtype add_memtype; + struct xenpf_del_memtype del_memtype; + struct xenpf_read_memtype read_memtype; + struct xenpf_microcode_update microcode; + struct xenpf_platform_quirk platform_quirk; + struct xenpf_firmware_info firmware_info; + struct xenpf_enter_acpi_sleep enter_acpi_sleep; + struct xenpf_change_freq change_freq; + struct xenpf_getidletime getidletime; + struct xenpf_set_processor_pminfo set_pminfo; + uint8_t pad[128]; + } u; +}; +DEFINE_GUEST_HANDLE_STRUCT(xen_platform_op_t); + +#endif /* __XEN_PUBLIC_PLATFORM_H__ */ diff --git a/include/xen/interface/xen.h b/include/xen/interface/xen.h index 70213b4..d83cc08 100644 --- a/include/xen/interface/xen.h +++ b/include/xen/interface/xen.h @@ -453,6 +453,7 @@ struct start_info { /* These flags are passed in the 'flags' field of start_info_t. */ #define SIF_PRIVILEGED (1<<0) /* Is the domain privileged? */ #define SIF_INITDOMAIN (1<<1) /* Is this the initial control domain? */ +#define SIF_PM_MASK (0xFF<<8) /* reserve 1 byte for xen-pm options */ typedef uint64_t cpumap_t; -- 1.7.6.2 _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel From xen-devel-bounces@lists.xensource.com Mon Sep 26 11:37:59 2011 Return-path: <xen-devel-bounces@lists.xensource.com> Envelope-to: www-data@lists.xensource.com Delivery-date: Mon, 26 Sep 2011 11:37:59 -0700 Received: from localhost ([127.0.0.1] helo=lists.colo.xensource.com) by lists.xensource.com with esmtp (Exim 4.43) id 1R8G3z-0004Md-07; Mon, 26 Sep 2011 11:37:59 -0700 Received: from mail182.messagelabs.com ([85.158.139.83]) by lists.xensource.com with esmtp (Exim 4.43) id 1R8FxX-0002dr-54; Mon, 26 Sep 2011 11:31:20 -0700 X-Env-Sender: konrad@oracle.com X-Msg-Ref: server-12.tower-182.messagelabs.com!1317061874!19657254!1 X-Originating-IP: [148.87.113.117] X-StarScan-Version: 6.4.1; banners=-,-,- X-VirusChecked: Checked Received: (qmail 30191 invoked from network); 26 Sep 2011 18:31:15 -0000 Received: from rcsinet15.oracle.com (HELO rcsinet15.oracle.com) (148.87.113.117) by server-12.tower-182.messagelabs.com with DHE-RSA-AES256-SHA encrypted SMTP; 26 Sep 2011 18:31:15 -0000 Received: from rtcsinet21.oracle.com (rtcsinet21.oracle.com [66.248.204.29]) by rcsinet15.oracle.com (Switch-3.4.4/Switch-3.4.4) with ESMTP id p8QIUb0X004260 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Mon, 26 Sep 2011 18:31:09 GMT Received: from acsmt356.oracle.com (acsmt356.oracle.com [141.146.40.156]) by rtcsinet21.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id p8QIFmu1024673 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 26 Sep 2011 18:15:49 GMT Received: from abhmt119.oracle.com (abhmt119.oracle.com [141.146.116.71]) by acsmt356.oracle.com (8.12.11.20060308/8.12.11) with ESMTP id p8QIFhl6009873; Mon, 26 Sep 2011 13:15:43 -0500 Received: from oracle.com (/209.6.55.207) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Mon, 26 Sep 2011 11:15:43 -0700 Received: by oracle.com (Postfix, from userid 1000) id 32EFB1551; Mon, 26 Sep 2011 14:15:36 -0400 (EDT) Date: Mon, 26 Sep 2011 14:15:36 -0400 From: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com> To: Ian Campbell <Ian.Campbell@citrix.com> Subject: Re: [Xen-devel] Xen document day (Oct 12 or 26) Message-ID: <20110926181536.GA8213@phenom.oracle.com> References: <20110922130618.GA13238@phenom.oracle.com> <CAFLBxZaAaXTUtW5+VkxPnr_MR0fbW+d1Mzu4y0x=gEOaX9e0OQ@mail.gmail.com> <20110922174002.GA1205@phenom.oracle.com> <1316852066.27431.15.camel@dagon.hellion.org.uk> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <1316852066.27431.15.camel@dagon.hellion.org.uk> User-Agent: Mutt/1.5.21 (2010-09-15) X-Source-IP: rtcsinet21.oracle.com [66.248.204.29] X-CT-RefId: str=0001.0A090207.4E80C4ED.0189,ss=1,re=0.000,fgs=0 Cc: George Dunlap <George.Dunlap@eu.citrix.com>, "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>, "xen-users@lists.xensource.com" <xen-users@lists.xensource.com> X-BeenThere: xen-devel@lists.xensource.com X-Mailman-Version: 2.1.5 Precedence: list List-Id: Xen developer discussion <xen-devel.lists.xensource.com> List-Unsubscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe> List-Post: <mailto:xen-devel@lists.xensource.com> List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help> List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=subscribe> Sender: xen-devel-bounces@lists.xensource.com Errors-To: xen-devel-bounces@lists.xensource.com On Sat, Sep 24, 2011 at 09:14:26AM +0100, Ian Campbell wrote: > On Thu, 2011-09-22 at 18:40 +0100, Konrad Rzeszutek Wilk wrote: > > On Thu, Sep 22, 2011 at 05:32:46PM +0100, George Dunlap wrote: > > > Another thing that needs to be done is to write man pages for xl, and > > > update the man pages for xm to indicate that it is deprecated. > > > > So: > > > > 1). PDF/section > > 2). Wiki > > 3). man page for xl/xm > > 4). HOWTO, docs in xen.hg/docs > > 5). Convert said HOWTO, docs in Markdown. > > Another thing which came up which I'd like to do was setting up doxygen > (or something similar, recommendations greatfully received) for > xen/include/public to allow us to document the hypercall interface > inline, with the intention of replacing interface.tex with something we > might actually maintain. OK, so: 1). PDF/section -> convert to something we can easily understand and it creates nice PDFs. 2). Wiki 3). man page for xl/xm 4). HOWTO, docs in xen.hg/docs 5). Convert said HOWTO, docs in Markdown. > > > > > Who wants to do what? I created a sign up sheet: > > > > https://docs.google.com/spreadsheet/ccc?key=0Aj5ukWh4htwMdEFLVWpjRmx3VXdETDExNlByamd4Rmc&hl=en_US > > > > in case folks want to get an idea of who is doing what and not > > step on each toes. > > We should have a specific IRC channel on the day too (e.g. > #xen-documentathon on freenode). <nods> Will do that. Was thinking to send a more "official" email along with a blog post on Xen.org But before I do that - date? Does that date work for folks? Oct 12th? Or is Oct 26th better? _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel From xen-devel-bounces@lists.xensource.com Mon Sep 26 11:44:16 2011 Return-path: <xen-devel-bounces@lists.xensource.com> Envelope-to: www-data@lists.xensource.com Delivery-date: Mon, 26 Sep 2011 11:44:16 -0700 Received: from localhost ([127.0.0.1] helo=lists.colo.xensource.com) by lists.xensource.com with esmtp (Exim 4.43) id 1R8GA4-0005ch-LQ; Mon, 26 Sep 2011 11:44:16 -0700 Received: from mail21.messagelabs.com ([85.158.143.35]) by lists.xensource.com with esmtp (Exim 4.43) id 1R8Fyu-0002zz-Gy for xen-devel@lists.xensource.com; Mon, 26 Sep 2011 11:32:45 -0700 X-Env-Sender: jeremy@goop.org X-Msg-Ref: server-11.tower-21.messagelabs.com!1317061942!44055422!1 X-Originating-IP: [74.207.240.146] X-StarScan-Version: 6.4.1; banners=-,-,- X-VirusChecked: Checked Received: (qmail 31502 invoked from network); 26 Sep 2011 18:32:23 -0000 Received: from claw.goop.org (HELO claw.goop.org) (74.207.240.146) by server-11.tower-21.messagelabs.com with DHE-RSA-AES256-SHA encrypted SMTP; 26 Sep 2011 18:32:23 -0000 Received: from saboo.goop.org (unknown [IPv6:2001:470:1f05:899:d4cf:8dff:fec9:d94b]) (Authenticated sender: smtp-saboo) by claw.goop.org (Postfix) with ESMTPSA id 6DE33A08D; Mon, 26 Sep 2011 11:32:39 -0700 (PDT) Received: from saboo.goop.org (localhost [IPv6:::1]) by saboo.goop.org (Postfix) with ESMTP id D8DA22043F; Mon, 26 Sep 2011 11:32:37 -0700 (PDT) Message-ID: <4E80C545.1070404@goop.org> Date: Mon, 26 Sep 2011 11:32:37 -0700 From: Jeremy Fitzhardinge <jeremy@goop.org> User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:6.0.2) Gecko/20110906 Thunderbird/6.0.2 MIME-Version: 1.0 To: Thomas Gleixner <tglx@linutronix.de> X-Enigmail-Version: 1.3.2 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>, the arch/x86 maintainers <x86@kernel.org>, Linux Kernel Mailing List <linux-kernel@vger.kernel.org>, "H. Peter Anvin" <hpa@zytor.com> Subject: [Xen-devel] Could you reinstate ticketlock cleanups in tip.git X-BeenThere: xen-devel@lists.xensource.com X-Mailman-Version: 2.1.5 Precedence: list List-Id: Xen developer discussion <xen-devel.lists.xensource.com> List-Unsubscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe> List-Post: <mailto:xen-devel@lists.xensource.com> List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help> List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=subscribe> Sender: xen-devel-bounces@lists.xensource.com Errors-To: xen-devel-bounces@lists.xensource.com Hi Thomas, Could you reinstate the ticketlock cleanup series in tip.git (I think it was in x86/spinlocks) from git://github.com/jsgf/linux-xen.git upstream/ticketlock-cleanup This branch is the final result of all the discussions and revisions and is ready for the next merge window. It's the one that's been in linux-next for a couple of weeks (at least), and won't cause any conflicts there. Or if you prefer I can submit it myself for next merge window. Thanks, J _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel From xen-devel-bounces@lists.xensource.com Mon Sep 26 12:07:42 2011 Return-path: <xen-devel-bounces@lists.xensource.com> Envelope-to: www-data@lists.xensource.com Delivery-date: Mon, 26 Sep 2011 12:07:42 -0700 Received: from localhost ([127.0.0.1] helo=lists.colo.xensource.com) by lists.xensource.com with esmtp (Exim 4.43) id 1R8GWj-0001Ov-ME; Mon, 26 Sep 2011 12:07:41 -0700 Received: from mail216.messagelabs.com ([85.158.143.99]) by lists.xensource.com with smtp (Exim 4.43) id 1R8GMz-0008Ti-Fp for xen-devel@lists.xensource.com; Mon, 26 Sep 2011 11:57:37 -0700 X-Env-Sender: bastian@waldi.eu.org X-Msg-Ref: server-9.tower-216.messagelabs.com!1317063454!19681378!1 X-Originating-IP: [82.139.201.20] X-StarScan-Version: 6.4.1; banners=-,-,- X-VirusChecked: Checked Received: (qmail 22238 invoked from network); 26 Sep 2011 18:57:34 -0000 Received: from wavehammer.waldi.eu.org (HELO wavehammer.waldi.eu.org) (82.139.201.20) by server-9.tower-216.messagelabs.com with SMTP; 26 Sep 2011 18:57:34 -0000 Received: by wavehammer.waldi.eu.org (Postfix, from userid 1000) id 1CA7054287; Mon, 26 Sep 2011 20:57:31 +0200 (CEST) Date: Mon, 26 Sep 2011 20:57:31 +0200 From: Bastian Blank <bastian@waldi.eu.org> To: xen-devel@lists.xensource.com, Linux Kernel Mailing List <linux-kernel@vger.kernel.org> Subject: Re: [Xen-devel] [PATCH 1/3] xen/acpi: Domain0 acpi parser related platform hypercall Message-ID: <20110926185731.GB22677@wavehammer.waldi.eu.org> Mail-Followup-To: Bastian Blank <bastian@waldi.eu.org>, xen-devel@lists.xensource.com, Linux Kernel Mailing List <linux-kernel@vger.kernel.org> References: <cover.1317061152.git.jeremy.fitzhardinge@citrix.com> <3e0996798a6a113efae9e0187c5581491bdb07a7.1317061152.git.jeremy.fitzhardinge@citrix.com> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline In-Reply-To: <3e0996798a6a113efae9e0187c5581491bdb07a7.1317061152.git.jeremy.fitzhardinge@citrix.com> User-Agent: Mutt/1.5.20 (2009-06-14) Cc: X-BeenThere: xen-devel@lists.xensource.com X-Mailman-Version: 2.1.5 Precedence: list List-Id: Xen developer discussion <xen-devel.lists.xensource.com> List-Unsubscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe> List-Post: <mailto:xen-devel@lists.xensource.com> List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help> List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=subscribe> Sender: xen-devel-bounces@lists.xensource.com Errors-To: xen-devel-bounces@lists.xensource.com On Mon, Sep 26, 2011 at 11:27:23AM -0700, Jeremy Fitzhardinge wrote: > +#define XENPF_INTERFACE_VERSION 0x03000001 May I assume that this interface is now fixed at this value? Bastian -- It is a human characteristic to love little animals, especially if they're attractive in some way. -- McCoy, "The Trouble with Tribbles", stardate 4525.6 _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel From xen-devel-bounces@lists.xensource.com Mon Sep 26 12:17:25 2011 Return-path: <xen-devel-bounces@lists.xensource.com> Envelope-to: www-data@lists.xensource.com Delivery-date: Mon, 26 Sep 2011 12:17:25 -0700 Received: from localhost ([127.0.0.1] helo=lists.colo.xensource.com) by lists.xensource.com with esmtp (Exim 4.43) id 1R8Gg9-00036m-F3; Mon, 26 Sep 2011 12:17:25 -0700 Received: from mail27.messagelabs.com ([193.109.254.147]) by lists.xensource.com with esmtp (Exim 4.43) id 1R8GRU-0000bH-TA; Mon, 26 Sep 2011 12:02:24 -0700 X-Env-Sender: Ian.Campbell@eu.citrix.com X-Msg-Ref: server-2.tower-27.messagelabs.com!1317063708!56534738!1 X-Originating-IP: [62.200.22.115] X-StarScan-Version: 6.4.1; banners=-,-,- X-VirusChecked: Checked Received: (qmail 1917 invoked from network); 26 Sep 2011 19:01:48 -0000 Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115) by server-2.tower-27.messagelabs.com with RC4-SHA encrypted SMTP; 26 Sep 2011 19:01:48 -0000 X-IronPort-AV: E=Sophos;i="4.68,445,1312156800"; d="scan'208";a="8068510" Received: from lonpmailmx01.citrite.net ([10.30.203.162]) by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5; 26 Sep 2011 19:02:13 +0000 Received: from [127.0.0.1] (10.80.16.67) by smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id 8.3.137.0; Mon, 26 Sep 2011 20:02:13 +0100 Subject: Re: [Xen-devel] Xen document day (Oct 12 or 26) From: Ian Campbell <Ian.Campbell@eu.citrix.com> To: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com> In-Reply-To: <20110926181536.GA8213@phenom.oracle.com> References: <20110922130618.GA13238@phenom.oracle.com> <CAFLBxZaAaXTUtW5+VkxPnr_MR0fbW+d1Mzu4y0x=gEOaX9e0OQ@mail.gmail.com> <20110922174002.GA1205@phenom.oracle.com> <1316852066.27431.15.camel@dagon.hellion.org.uk> <20110926181536.GA8213@phenom.oracle.com> Content-Type: text/plain; charset="ISO-8859-1" Organization: Citrix Systems, Inc. Date: Mon, 26 Sep 2011 20:02:12 +0100 Message-ID: <1317063732.13424.6.camel@dagon.hellion.org.uk> MIME-Version: 1.0 X-Mailer: Evolution 2.32.3 Content-Transfer-Encoding: 7bit Cc: George Dunlap <George.Dunlap@eu.citrix.com>, "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>, "xen-users@lists.xensource.com" <xen-users@lists.xensource.com> X-BeenThere: xen-devel@lists.xensource.com X-Mailman-Version: 2.1.5 Precedence: list List-Id: Xen developer discussion <xen-devel.lists.xensource.com> List-Unsubscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe> List-Post: <mailto:xen-devel@lists.xensource.com> List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help> List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=subscribe> Sender: xen-devel-bounces@lists.xensource.com Errors-To: xen-devel-bounces@lists.xensource.com On Mon, 2011-09-26 at 19:15 +0100, Konrad Rzeszutek Wilk wrote: > But before I do that - date? Does that date work for folks? Oct 12th? > Or is Oct 26th better? They are equally fine for me. Ian. _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel From xen-devel-bounces@lists.xensource.com Mon Sep 26 12:27:16 2011 Return-path: <xen-devel-bounces@lists.xensource.com> Envelope-to: www-data@lists.xensource.com Delivery-date: Mon, 26 Sep 2011 12:27:16 -0700 Received: from localhost ([127.0.0.1] helo=lists.colo.xensource.com) by lists.xensource.com with esmtp (Exim 4.43) id 1R8Gpg-0005fK-EL; Mon, 26 Sep 2011 12:27:16 -0700 Received: from mail182.messagelabs.com ([85.158.139.83]) by lists.xensource.com with esmtp (Exim 4.43) id 1R8Gf7-0002se-NS for xen-devel@lists.xensource.com; Mon, 26 Sep 2011 12:16:28 -0700 X-Env-Sender: pasik@iki.fi X-Msg-Ref: server-4.tower-182.messagelabs.com!1317064577!19821497!1 X-Originating-IP: [192.89.123.25] X-StarScan-Version: 6.4.1; banners=-,-,- X-VirusChecked: Checked Received: (qmail 19367 invoked from network); 26 Sep 2011 19:16:18 -0000 Received: from smtp.tele.fi (HELO smtp.tele.fi) (192.89.123.25) by server-4.tower-182.messagelabs.com with DHE-RSA-AES256-SHA encrypted SMTP; 26 Sep 2011 19:16:18 -0000 X-Originating-Ip: [194.89.68.22] Received: from ydin.reaktio.net (reaktio.net [194.89.68.22]) by smtp.tele.fi (Postfix) with ESMTP id 67ECC1924; Mon, 26 Sep 2011 22:15:57 +0300 (EEST) Received: by ydin.reaktio.net (Postfix, from userid 1001) id DF1DD200E8; Mon, 26 Sep 2011 22:15:56 +0300 (EEST) Date: Mon, 26 Sep 2011 22:15:56 +0300 From: Pasi =?iso-8859-1?Q?K=E4rkk=E4inen?= <pasik@iki.fi> To: piyush jain <piyush.today@gmail.com> Subject: Re: [Xen-devel] xen + windbg.. Message-ID: <20110926191556.GU12984@reaktio.net> References: <CACyYOe+78Jss5AmBqwLa-d=0+9mSzh0DbpGOx4KQJO=wqOeJVA@mail.gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <CACyYOe+78Jss5AmBqwLa-d=0+9mSzh0DbpGOx4KQJO=wqOeJVA@mail.gmail.com> User-Agent: Mutt/1.5.18 (2008-05-17) Cc: Paul Durrant <Paul.Durrant@citrix.com>, xen-devel@lists.xensource.com, James Harper <james.harper@bendigoit.com.au> X-BeenThere: xen-devel@lists.xensource.com X-Mailman-Version: 2.1.5 Precedence: list List-Id: Xen developer discussion <xen-devel.lists.xensource.com> List-Unsubscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe> List-Post: <mailto:xen-devel@lists.xensource.com> List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help> List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=subscribe> Sender: xen-devel-bounces@lists.xensource.com Errors-To: xen-devel-bounces@lists.xensource.com On Mon, Sep 26, 2011 at 04:39:08PM +0530, piyush jain wrote: > Hi, > Is it possible to connect windbg to guest windows 2008 R2, over xen? > > Anyone how did it succesfully? > > I tried steps in this links > > [1]http://wiki.xensource.com/xenwiki/XenWindowsGplPv > > but it's not working for me :( (i modified add in xinited, instead of > inetd.conf) > > Can any1 update this doc? > Hey, Maybe James or Paul can comment.. -- Pasi _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel From xen-devel-bounces@lists.xensource.com Mon Sep 26 12:36:57 2011 Return-path: <xen-devel-bounces@lists.xensource.com> Envelope-to: www-data@lists.xensource.com Delivery-date: Mon, 26 Sep 2011 12:36:57 -0700 Received: from localhost ([127.0.0.1] helo=lists.colo.xensource.com) by lists.xensource.com with esmtp (Exim 4.43) id 1R8Gz2-0006PV-P5; Mon, 26 Sep 2011 12:36:56 -0700 Received: from mail216.messagelabs.com ([85.158.143.99]) by lists.xensource.com with esmtp (Exim 4.43) id 1R8Gy9-0006AW-Vo for xen-devel@lists.xensource.com; Mon, 26 Sep 2011 12:36:03 -0700 X-Env-Sender: konrad@oracle.com X-Msg-Ref: server-13.tower-216.messagelabs.com!1317065757!19681245!1 X-Originating-IP: [141.146.126.227] X-StarScan-Version: 6.4.1; banners=-,-,- X-VirusChecked: Checked Received: (qmail 14820 invoked from network); 26 Sep 2011 19:35:58 -0000 Received: from acsinet15.oracle.com (HELO acsinet15.oracle.com) (141.146.126.227) by server-13.tower-216.messagelabs.com with DHE-RSA-AES256-SHA encrypted SMTP; 26 Sep 2011 19:35:58 -0000 Received: from rtcsinet22.oracle.com (rtcsinet22.oracle.com [66.248.204.30]) by acsinet15.oracle.com (Switch-3.4.4/Switch-3.4.4) with ESMTP id p8QJZB89016449 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Mon, 26 Sep 2011 19:35:13 GMT Received: from acsmt356.oracle.com (acsmt356.oracle.com [141.146.40.156]) by rtcsinet22.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id p8QJZ8hi006733 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 26 Sep 2011 19:35:09 GMT Received: from abhmt102.oracle.com (abhmt102.oracle.com [141.146.116.54]) by acsmt356.oracle.com (8.12.11.20060308/8.12.11) with ESMTP id p8QJZ0Le007112; Mon, 26 Sep 2011 14:35:00 -0500 Received: from oracle.com (/209.6.55.207) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Mon, 26 Sep 2011 12:35:00 -0700 Received: by oracle.com (Postfix, from userid 1000) id 464401555; Mon, 26 Sep 2011 15:34:53 -0400 (EDT) Date: Mon, 26 Sep 2011 15:34:53 -0400 From: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com> To: Jeremy Fitzhardinge <jeremy@goop.org> Message-ID: <20110926193453.GA9717@phenom.oracle.com> References: <1317042797-19975-1-git-send-email-konrad.wilk@oracle.com> <4E80A6BD.3070703@goop.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <4E80A6BD.3070703@goop.org> User-Agent: Mutt/1.5.21 (2010-09-15) X-Source-IP: rtcsinet22.oracle.com [66.248.204.30] X-CT-RefId: str=0001.0A090204.4E80D3F2.0046,ss=1,re=0.000,fgs=0 Cc: xen-devel@lists.xensource.com, Peter Zijlstra <a.p.zijlstra@chello.nl>, Jeremy Fitzhardinge <jeremy.fitzhardinge@citrix.com>, x86@kernel.org, linux-kernel@vger.kernel.org, Ingo Molnar <mingo@redhat.com>, "H. Peter Anvin" <hpa@zytor.com>, Thomas Gleixner <tglx@linutronix.de>, stable@kernel.org Subject: [Xen-devel] Is: [PATCH] x86/paravirt: PTE updates in k(un)map_atomic need to be synchronous, regardless of lazy_mmu mode. Was: Re: [PATCH] x86/paravirt: Partially revert "remove lazy mode in interrupts" X-BeenThere: xen-devel@lists.xensource.com X-Mailman-Version: 2.1.5 Precedence: list List-Id: Xen developer discussion <xen-devel.lists.xensource.com> List-Unsubscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe> List-Post: <mailto:xen-devel@lists.xensource.com> List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help> List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=subscribe> Sender: xen-devel-bounces@lists.xensource.com Errors-To: xen-devel-bounces@lists.xensource.com On Mon, Sep 26, 2011 at 09:22:21AM -0700, Jeremy Fitzhardinge wrote: > On 09/26/2011 06:13 AM, Konrad Rzeszutek Wilk wrote: > > which has git commit b8bcfe997e46150fedcc3f5b26b846400122fdd9. > > > > The unintended consequence of removing the flushing of MMU > > updates when doing kmap_atomic (or kunmap_atomic) is that we can > > hit a dereference bug when processing a "fork()" under a heavy loaded > > machine. Specifically we can hit: > > The patch is all OK, but I wouldn't have headlined it as a "partial > revert" - the important point is that the pte updates in k(un)map_atomic > need to be synchronous, regardless of whether we're in lazy_mmu mode. > > The fact that b8bcfe997e4 introduced the problem is interesting to note, > but only somewhat relevant to the analysis of what's being fixed here. Good point. How about >From 09966678dd645b68a422c9bf0223b13e73387302 Mon Sep 17 00:00:00 2001 From: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com> Date: Fri, 23 Sep 2011 17:02:29 -0400 Subject: [PATCH] x86/paravirt: PTE updates in k(un)map_atomic need to be synchronous, regardless of lazy_mmu mode. This patch fixes an outstanding issue that has been reported since 2.6.37. Under a heavy loaded machine processing "fork()" calls could keepover with: BUG: unable to handle kernel paging request at f573fc8c IP: [<c01abc54>] swap_count_continued+0x104/0x180 *pdpt = 000000002a3b9027 *pde = 0000000001bed067 *pte = 0000000000000000 Oops: 0000 [#1] SMP Modules linked in: Pid: 1638, comm: apache2 Not tainted 3.0.4-linode37 #1 EIP: 0061:[<c01abc54>] EFLAGS: 00210246 CPU: 3 EIP is at swap_count_continued+0x104/0x180 .. snip.. Call Trace: [<c01ac222>] ? __swap_duplicate+0xc2/0x160 [<c01040f7>] ? pte_mfn_to_pfn+0x87/0xe0 [<c01ac2e4>] ? swap_duplicate+0x14/0x40 [<c01a0a6b>] ? copy_pte_range+0x45b/0x500 [<c01a0ca5>] ? copy_page_range+0x195/0x200 [<c01328c6>] ? dup_mmap+0x1c6/0x2c0 [<c0132cf8>] ? dup_mm+0xa8/0x130 [<c013376a>] ? copy_process+0x98a/0xb30 [<c013395f>] ? do_fork+0x4f/0x280 [<c01573b3>] ? getnstimeofday+0x43/0x100 [<c010f770>] ? sys_clone+0x30/0x40 [<c06c048d>] ? ptregs_clone+0x15/0x48 [<c06bfb71>] ? syscall_call+0x7/0xb The problem is that in copy_page_range we turn lazy mode on, and then in swap_entry_free we call swap_count_continued which ends up in: map = kmap_atomic(page, KM_USER0) + offset; and then later we touch *map. Since we are running in batched mode (lazy) we don't actually set up the PTE mappings and the kmap_atomic is not done synchronously and ends up trying to dereference a page that has not been set. Looking at kmap_atomic_prot_pfn, it uses 'arch_flush_lazy_mmu_mode' and doing the same in kmap_atomic_prot and __kunmap_atomic makes the problem go away. Interestingly, git commit b8bcfe997e46150fedcc3f5b26b846400122fdd9 removed part of this to fix an interrupt issue - but it went to far and did not consider this scenario. CC: Thomas Gleixner <tglx@linutronix.de> CC: Ingo Molnar <mingo@redhat.com> CC: "H. Peter Anvin" <hpa@zytor.com> CC: x86@kernel.org CC: Peter Zijlstra <a.p.zijlstra@chello.nl> CC: Jeremy Fitzhardinge <jeremy.fitzhardinge@citrix.com> CC: stable@kernel.org [v1: Redid the commit description per Jeremy's apt suggestion] Signed-off-by: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com> --- arch/x86/mm/highmem_32.c | 2 ++ 1 files changed, 2 insertions(+), 0 deletions(-) diff --git a/arch/x86/mm/highmem_32.c b/arch/x86/mm/highmem_32.c index b499626..f4f29b1 100644 --- a/arch/x86/mm/highmem_32.c +++ b/arch/x86/mm/highmem_32.c @@ -45,6 +45,7 @@ void *kmap_atomic_prot(struct page *page, pgprot_t prot) vaddr = __fix_to_virt(FIX_KMAP_BEGIN + idx); BUG_ON(!pte_none(*(kmap_pte-idx))); set_pte(kmap_pte-idx, mk_pte(page, prot)); + arch_flush_lazy_mmu_mode(); return (void *)vaddr; } @@ -88,6 +89,7 @@ void __kunmap_atomic(void *kvaddr) */ kpte_clear_flush(kmap_pte-idx, vaddr); kmap_atomic_idx_pop(); + arch_flush_lazy_mmu_mode(); } #ifdef CONFIG_DEBUG_HIGHMEM else { -- 1.7.4.1 _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel From xen-devel-bounces@lists.xensource.com Mon Sep 26 12:38:34 2011 Return-path: <xen-devel-bounces@lists.xensource.com> Envelope-to: www-data@lists.xensource.com Delivery-date: Mon, 26 Sep 2011 12:38:34 -0700 Received: from localhost ([127.0.0.1] helo=lists.colo.xensource.com) by lists.xensource.com with esmtp (Exim 4.43) id 1R8H0b-0006sd-OA; Mon, 26 Sep 2011 12:38:34 -0700 Received: from mail27.messagelabs.com ([193.109.254.147]) by lists.xensource.com with esmtp (Exim 4.43) id 1R8Gzx-0006dx-OT for xen-devel@lists.xensource.com; Mon, 26 Sep 2011 12:37:54 -0700 X-Env-Sender: konrad@oracle.com X-Msg-Ref: server-8.tower-27.messagelabs.com!1317065852!48182768!1 X-Originating-IP: [148.87.113.117] X-StarScan-Version: 6.4.1; banners=-,-,- X-VirusChecked: Checked Received: (qmail 28657 invoked from network); 26 Sep 2011 19:37:33 -0000 Received: from rcsinet15.oracle.com (HELO rcsinet15.oracle.com) (148.87.113.117) by server-8.tower-27.messagelabs.com with DHE-RSA-AES256-SHA encrypted SMTP; 26 Sep 2011 19:37:33 -0000 Received: from acsinet21.oracle.com (acsinet21.oracle.com [141.146.126.237]) by rcsinet15.oracle.com (Switch-3.4.4/Switch-3.4.4) with ESMTP id p8QJbkf2001841 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Mon, 26 Sep 2011 19:37:48 GMT Received: from acsmt356.oracle.com (acsmt356.oracle.com [141.146.40.156]) by acsinet21.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id p8QJbjtd009863 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 26 Sep 2011 19:37:45 GMT Received: from abhmt112.oracle.com (abhmt112.oracle.com [141.146.116.64]) by acsmt356.oracle.com (8.12.11.20060308/8.12.11) with ESMTP id p8QJbeKP009165; Mon, 26 Sep 2011 14:37:40 -0500 Received: from oracle.com (/209.6.55.207) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Mon, 26 Sep 2011 12:37:40 -0700 Received: by oracle.com (Postfix, from userid 1000) id 3C21F1555; Mon, 26 Sep 2011 15:37:33 -0400 (EDT) Date: Mon, 26 Sep 2011 15:37:33 -0400 From: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com> To: Anthony Wright <anthony@overnetdata.com> Subject: Re: [Xen-devel] dmidecode doesn't work under xen 4.1.1 on certain hardware Message-ID: <20110926193732.GA10007@phenom.oracle.com> References: <4E7C6BDC.8070005@overnetdata.com> <20110923133200.GC19579@phenom.oracle.com> <4E7C9C8B.2010108@overnetdata.com> <20110926141322.GD4102@phenom.oracle.com> <4E8090D4.2090009@overnetdata.com> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="KsGdsel6WgEHnImy" Content-Disposition: inline In-Reply-To: <4E8090D4.2090009@overnetdata.com> User-Agent: Mutt/1.5.21 (2010-09-15) X-Source-IP: acsinet21.oracle.com [141.146.126.237] X-Auth-Type: Internal IP X-CT-RefId: str=0001.0A090202.4E80D48C.0112:SCFMA922111,ss=1,re=-4.000,fgs=0 Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com> X-BeenThere: xen-devel@lists.xensource.com X-Mailman-Version: 2.1.5 Precedence: list List-Id: Xen developer discussion <xen-devel.lists.xensource.com> List-Unsubscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe> List-Post: <mailto:xen-devel@lists.xensource.com> List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help> List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=subscribe> Sender: xen-devel-bounces@lists.xensource.com Errors-To: xen-devel-bounces@lists.xensource.com --KsGdsel6WgEHnImy Content-Type: text/plain; charset=us-ascii Content-Disposition: inline On Mon, Sep 26, 2011 at 03:48:52PM +0100, Anthony Wright wrote: > On 26/09/2011 15:13, Konrad Rzeszutek Wilk wrote: > > On Fri, Sep 23, 2011 at 03:49:47PM +0100, Anthony Wright wrote: > >> On 23/09/2011 14:32, Konrad Rzeszutek Wilk wrote: > >>> On Fri, Sep 23, 2011 at 12:22:04PM +0100, Anthony Wright wrote: > >>>> I have a xen 4.1.1 with a 3.0.4 linux kernel running on a Supermicro > >>>> Supermicro X8DTL-iF motherboard with 16GB of RAM. > >>>> > >>>> If I run the 3.0.4 kernel on the bare metal dmidecode works fine. If I > >>> Can you attach the beginning of the kernel bootup log? It should > >>> have some entry about 1-1 mappings. Make sure to run Linux with "debug loglevel=8" > >> Please find attached. > >> 2011 Sep 23 14:45:41 kernel: [ 0.000000] 1-1 mapping on 9a->100 > >> 2011 Sep 23 14:45:41 kernel: [ 0.000000] 1-1 mapping on bf780->100000 > >> 2011 Sep 23 14:45:41 kernel: [ 0.000000] Set 264422 page(s) to 1-1 mapping. > >> 2011 Sep 23 14:45:41 kernel: [ 0.000000] BIOS-provided physical RAM map: > >> 2011 Sep 23 14:45:41 kernel: [ 0.000000] Xen: 0000000000000000 - 0000000000099000 (usable) > >> 2011 Sep 23 14:45:41 kernel: [ 0.000000] Xen: 0000000000099800 - 0000000000100000 (reserved) > > .. snip.. > > > > So 99C00 is right at cusp of 'usuable' and 'reserved'. Meaning that region > > falls within the 4KB page. And we did not set the 1-1 mapping for 99 (we > > started at 9A). > > > > But now that I think of it - this is Linux E820 which does get modified. > > Can you also provide the hypervisor E820 output? You can get 'xl dmesg' > > for that. That should provide the "virgin" output of the e820 which we > > use for 1-1 mapping. > I'm not quite sure I understand all that, but I think you would find the > xl dmesg output helpful, so I've attached it. Thanks. > __ __ _ _ _ _ > \ \/ /___ _ __ | || | / | / | > \ // _ \ '_ \ | || |_ | | | | > / \ __/ | | | |__ _|| |_| | > /_/\_\___|_| |_| |_|(_)_(_)_| > > (XEN) Xen version 4.1.1 (@[unknown]) (gcc version 4.4.3 (GCC) ) Wed Sep 21 08:25:36 GMT 2011 > (XEN) Latest ChangeSet: unavailable > (XEN) Bootloader: GNU GRUB 0.97 > (XEN) Command line: > (XEN) Video information: > (XEN) VGA is text mode 80x25, font 8x16 > (XEN) VBE/DDC methods: V2; EDID transfer time: 1 seconds > (XEN) Disc information: > (XEN) Found 4 MBR signatures > (XEN) Found 4 EDD information structures > (XEN) WARNING: Only the first 16 GB of the physical memory map can be accessed by Xen in 32-bit mode. That bites ^^^^ > (XEN) Truncating RAM from 17825792kB to 16777216kB > (XEN) Xen-e820 RAM map: > (XEN) 0000000000000000 - 0000000000099800 (usable) > (XEN) 0000000000099800 - 00000000000a0000 (reserved) > (XEN) 00000000000e4000 - 0000000000100000 (reserved) > (XEN) 0000000000100000 - 00000000bf780000 (usable) > (XEN) 00000000bf78e000 - 00000000bf790000 type 9 Ok, so this patch should shed some light and potentially fix your problem. Please try it out and attach the serial log for Linux kernel. Thx. --KsGdsel6WgEHnImy Content-Type: text/x-diff; charset=us-ascii Content-Disposition: attachment; filename="e820.patch" diff --git a/arch/x86/xen/setup.c b/arch/x86/xen/setup.c index 46d6d21..3368c30 100644 --- a/arch/x86/xen/setup.c +++ b/arch/x86/xen/setup.c @@ -166,9 +166,11 @@ static unsigned long __init xen_set_identity(const struct e820entry *list, continue; if ((entry->type == E820_RAM) || (entry->type == E820_UNUSABLE)) { + printk(KERN_INFO "(%lx->%lx) PCI: %lx->%lx (last %lx, now %lx)\n", + start, end, start_pci, start, last, end); if (start > start_pci) identity += set_phys_range_identity( - PFN_UP(start_pci), PFN_DOWN(start)); + PFN_DOWN(start_pci), PFN_DOWN(start)); /* Without saving 'last' we would gooble RAM too * at the end of the loop. */ --KsGdsel6WgEHnImy Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel --KsGdsel6WgEHnImy-- From xen-devel-bounces@lists.xensource.com Mon Sep 26 13:25:54 2011 Return-path: <xen-devel-bounces@lists.xensource.com> Envelope-to: www-data@lists.xensource.com Delivery-date: Mon, 26 Sep 2011 13:25:54 -0700 Received: from localhost ([127.0.0.1] helo=lists.colo.xensource.com) by lists.xensource.com with esmtp (Exim 4.43) id 1R8HkQ-0008Hp-IN; Mon, 26 Sep 2011 13:25:54 -0700 Received: from mail216.messagelabs.com ([85.158.143.99]) by lists.xensource.com with esmtp (Exim 4.43) id 1R8HjK-000835-Kz; Mon, 26 Sep 2011 13:24:47 -0700 X-Env-Sender: linux@eikelenboom.it X-Msg-Ref: server-2.tower-216.messagelabs.com!1317068683!19238132!1 X-Originating-IP: [188.40.164.121] X-StarScan-Version: 6.4.1; banners=-,-,- X-VirusChecked: Checked Received: (qmail 7632 invoked from network); 26 Sep 2011 20:24:43 -0000 Received: from static.121.164.40.188.clients.your-server.de (HELO smtp.eikelenboom.it) (188.40.164.121) by server-2.tower-216.messagelabs.com with AES256-SHA encrypted SMTP; 26 Sep 2011 20:24:43 -0000 Received: from 231-79-ftth.onsneteindhoven.nl ([88.159.79.231]:65305 helo=[172.16.1.220]) by smtp.eikelenboom.it with esmtpsa (TLS1.0:RSA_AES_256_CBC_SHA1:32) (Exim 4.72) (envelope-from <linux@eikelenboom.it>) id 1R8Hh7-0007cI-8x; Mon, 26 Sep 2011 22:22:29 +0200 Date: Mon, 26 Sep 2011 22:24:39 +0200 From: Sander Eikelenboom <linux@eikelenboom.it> Organization: Eikelenboom IT services X-Priority: 3 (Normal) Message-ID: <499921842.20110926222439@eikelenboom.it> To: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com> Subject: Re: [Xen-devel] Xen document day (Oct 12 or 26) In-Reply-To: <20110926181536.GA8213@phenom.oracle.com> References: <20110922130618.GA13238@phenom.oracle.com> <CAFLBxZaAaXTUtW5+VkxPnr_MR0fbW+d1Mzu4y0x=gEOaX9e0OQ@mail.gmail.com> <20110922174002.GA1205@phenom.oracle.com> <1316852066.27431.15.camel@dagon.hellion.org.uk> <20110926181536.GA8213@phenom.oracle.com> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-15 Content-Transfer-Encoding: quoted-printable Cc: George Dunlap <George.Dunlap@eu.citrix.com>, "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>, Ian Campbell <Ian.Campbell@citrix.com>, "xen-users@lists.xensource.com" <xen-users@lists.xensource.com> X-BeenThere: xen-devel@lists.xensource.com X-Mailman-Version: 2.1.5 Precedence: list List-Id: Xen developer discussion <xen-devel.lists.xensource.com> List-Unsubscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe> List-Post: <mailto:xen-devel@lists.xensource.com> List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help> List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=subscribe> Sender: xen-devel-bounces@lists.xensource.com Errors-To: xen-devel-bounces@lists.xensource.com Hello Konrad, Monday, September 26, 2011, 8:15:36 PM, you wrote: > On Sat, Sep 24, 2011 at 09:14:26AM +0100, Ian Campbell wrote: >> On Thu, 2011-09-22 at 18:40 +0100, Konrad Rzeszutek Wilk wrote: >> > On Thu, Sep 22, 2011 at 05:32:46PM +0100, George Dunlap wrote: >> > > Another thing that needs to be done is to write man pages for xl, and >> > > update the man pages for xm to indicate that it is deprecated. >> >=20 >> > So: >> >=20 >> > 1). PDF/section >> > 2). Wiki >> > 3). man page for xl/xm >> > 4). HOWTO, docs in xen.hg/docs >> > 5). Convert said HOWTO, docs in Markdown. >>=20 >> Another thing which came up which I'd like to do was setting up doxygen >> (or something similar, recommendations greatfully received) for >> xen/include/public to allow us to document the hypercall interface >> inline, with the intention of replacing interface.tex with something we >> might actually maintain. > OK, so: > 1). PDF/section -> convert to something we can easily understand > and it creates nice PDFs. > 2). Wiki Some pages i missed in your previous lists: - http://wiki.xensource.com/xenwiki/XenHypervisorBootOptions - List of Xen specific/related Linux kernel boot options - A very good (set of) structured start page(s) so you get a overview = of what documentation is available > 3). man page for xl/xm > 4). HOWTO, docs in xen.hg/docs > 5). Convert said HOWTO, docs in Markdown. >>=20 >> >=20 >> > Who wants to do what? I created a sign up sheet: >> >=20 >> > https://docs.google.com/spreadsheet/ccc?key=3D0Aj5ukWh4htwMdEFLVWpjRmx= 3VXdETDExNlByamd4Rmc&hl=3Den_US >> >=20 >> > in case folks want to get an idea of who is doing what and not >> > step on each toes. >>=20 >> We should have a specific IRC channel on the day too (e.g. >> #xen-documentathon on freenode). > <nods> Will do that. Was thinking to send a more "official" email > along with a blog post on Xen.org > But before I do that - date? Does that date work for folks? Oct 12th? > Or is Oct 26th better? --=20 Best regards, Sander mailto:linux@eikelenboom.it _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel From xen-devel-bounces@lists.xensource.com Mon Sep 26 14:11:34 2011 Return-path: <xen-devel-bounces@lists.xensource.com> Envelope-to: www-data@lists.xensource.com Delivery-date: Mon, 26 Sep 2011 14:11:34 -0700 Received: from localhost ([127.0.0.1] helo=lists.colo.xensource.com) by lists.xensource.com with esmtp (Exim 4.43) id 1R8ISc-0002FX-7I; Mon, 26 Sep 2011 14:11:34 -0700 Received: from mail216.messagelabs.com ([85.158.143.99]) by lists.xensource.com with smtp (Exim 4.43) id 1R8IQu-00022I-SI for xen-devel@lists.xensource.com; Mon, 26 Sep 2011 14:10:06 -0700 X-Env-Sender: caker@theshore.net X-Msg-Ref: server-13.tower-216.messagelabs.com!1317071384!19687023!1 X-Originating-IP: [67.18.92.50] X-StarScan-Version: 6.4.1; banners=-,-,- X-VirusChecked: Checked Received: (qmail 31636 invoked from network); 26 Sep 2011 21:09:44 -0000 Received: from ns.theshore.net (HELO www.theshore.net) (67.18.92.50) by server-13.tower-216.messagelabs.com with SMTP; 26 Sep 2011 21:09:44 -0000 Received: from beefcake.linlan (173-161-199-49-Philadelphia.hfc.comcastbusiness.net [173.161.199.49]) by www.theshore.net (8.13.6/8.9.1) with ESMTP id p8QL9gWZ026655 for <xen-devel@lists.xensource.com>; Mon, 26 Sep 2011 17:09:43 -0400 Message-ID: <4E80EA16.6010609@theshore.net> Date: Mon, 26 Sep 2011 17:09:42 -0400 From: "Christopher S. Aker" <caker@theshore.net> User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.6; en-US; rv:1.9.2.22) Gecko/20110902 Lightning/1.0b2 Thunderbird/3.1.14 MIME-Version: 1.0 To: xen devel <xen-devel@lists.xensource.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: [Xen-devel] dom0: kernel BUG at mm/vmalloc.c:2165! X-BeenThere: xen-devel@lists.xensource.com X-Mailman-Version: 2.1.5 Precedence: list List-Id: Xen developer discussion <xen-devel.lists.xensource.com> List-Unsubscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe> List-Post: <mailto:xen-devel@lists.xensource.com> List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help> List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=subscribe> Sender: xen-devel-bounces@lists.xensource.com Errors-To: xen-devel-bounces@lists.xensource.com Xen 4.1.1 3.0.4 dom0 While trying to boot the first (and only) domU on the freshly-booted box (two attempts). Is this a symptom of my dom0 lacking the 'vmalloc_sync_all()' patch discussed recently? - http://lkml.org/lkml/2011/9/2/114 - I just want to make sure this isn't something unexpected. device vif1.0 entered promiscuous mode ADDRCONF(NETDEV_UP): vif1.0: link is not ready xen-blkback:ring-ref 8, event-channel 27, protocol 1 (x86_32-abi) xen-blkback:ring-ref 9, event-channel 28, protocol 1 (x86_32-abi) ADDRCONF(NETDEV_CHANGE): vif1.0: link becomes ready br0: port 3(vif1.0) entering forwarding state br0: port 3(vif1.0) entering forwarding state br0: port 3(vif1.0) entering forwarding state br0: port 3(vif1.0) entering forwarding state device vif1.0 left promiscuous mode br0: port 3(vif1.0) entering disabled state device vif2.0 entered promiscuous mode ADDRCONF(NETDEV_UP): vif2.0: link is not ready xen-blkback:ring-ref 8, event-channel 27, protocol 1 (x86_32-abi) (XEN) mm.c:3846:d0 Could not find L1 PTE for address f7e22000 vbd vbd-2-51712: 1 mapping ring-ref 8 port 27 xen-blkback:ring-ref 9, event-channel 28, protocol 1 (x86_32-abi) (XEN) mm.c:3846:d0 Could not find L1 PTE for address f7e24000 vbd vbd-2-51728: 1 mapping ring-ref 9 port 28 (XEN) mm.c:3846:d0 Could not find L1 PTE for address f7e26000 vif vif-2-0: vif2.0: failed to map tx ring. err=-12 status=-1 vif vif-2-0: 1 mapping shared-frames 768/769 port 29 br0: port 3(vif2.0) entering disabled state device vif2.0 left promiscuous mode br0: port 3(vif2.0) entering disabled state ------------[ cut here ]------------ kernel BUG at mm/vmalloc.c:2165! invalid opcode: 0000 [#1] SMP Modules linked in: ebt_arp ip6t_rt ebt_mark ebt_limit xt_mark ip6table_mangle ebtable_nat ebtable_filter Pid: 39, comm: xenwatch Not tainted 3.0.4-1 #1 Supermicro X8DTU/X8DTU EIP: 0061:[<c10e492c>] EFLAGS: 00010282 CPU: 5 EIP is at free_vm_area+0x1c/0x20 EAX: 00000000 EBX: e8d4b940 ECX: 00000001 EDX: 00000000 ESI: e94db46c EDI: e9b7fa20 EBP: eb1d9e24 ESP: eb1d9e20 DS: 007b ES: 007b FS: 00d8 GS: 0000 SS: 0069 Process xenwatch (pid: 39, ti=eb1d8000 task=eb11b0c0 task.ti=eb1d8000) Stack: e94db3c0 eb1d9e54 c14ecf8a e94db3c0 eb1d9e2c e94db000 e94db46c e9b7fa20 eb1d9e48 c15ba8d8 e94db3c0 e94db46c e9b7fa20 eb1d9e84 c14efd46 c139748f eabe22e0 eabe22e0 00000000 e9b7fa20 eb1d9e84 c139748f eb12f060 e9b7fa00 Call Trace: [<c14ecf8a>] xen_netbk_unmap_frontend_rings+0xda/0x100 [<c15ba8d8>] ? rtnl_unlock+0x8/0x10 [<c14efd46>] xenvif_disconnect+0xb6/0x110 [<c139748f>] ? xenbus_rm+0x3f/0x50 [<c139748f>] ? xenbus_rm+0x3f/0x50 [<c14eebff>] netback_remove+0x4f/0x80 [<c13982d7>] xenbus_dev_remove+0x37/0x50 [<c1437a1e>] __device_release_driver+0x3e/0x90 [<c1437b30>] device_release_driver+0x20/0x40 [<c1436e9b>] bus_remove_device+0x7b/0xa0 [<c1435557>] device_del+0xe7/0x170 [<c14355eb>] device_unregister+0xb/0x20 [<c14eed7e>] frontend_changed+0x8e/0x650 [<c139762d>] ? xenbus_read+0x3d/0x50 [<c1397671>] ? xenbus_gather+0x31/0x90 [<c10066c4>] ? check_events+0x8/0xc [<c13958f5>] ? xenbus_read_driver_state+0x35/0x50 [<c139852d>] xenbus_otherend_changed+0x7d/0x90 [<c1398732>] frontend_changed+0x12/0x20 [<c1396aa5>] xenwatch_thread+0x85/0x130 [<c10625d0>] ? wake_up_bit+0x60/0x60 [<c1396a20>] ? split+0xd0/0xd0 [<c10621e4>] kthread+0x74/0x80 [<c1062170>] ? kthread_worker_fn+0x160/0x160 [<c16ca2b6>] kernel_thread_helper+0x6/0x10 Code: 00 10 00 00 eb a3 89 f6 8d bc 27 00 00 00 00 55 89 e5 53 89 c3 8b 40 04 e8 72 ff ff ff 39 c3 75 0a 89 d8 e8 27 cf 00 00 5b 5d c3 <0f> 0b eb fe 55 85 d2 89 e5 57 89 d7 56 53 89 c3 7e 11 31 f6 8b EIP: [<c10e492c>] free_vm_area+0x1c/0x20 SS:ESP 0069:eb1d9e20 ---[ end trace 8c2c7e19ece622c9 ]--- Thanks, -Chris _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel From xen-devel-bounces@lists.xensource.com Mon Sep 26 14:22:55 2011 Return-path: <xen-devel-bounces@lists.xensource.com> Envelope-to: www-data@lists.xensource.com Delivery-date: Mon, 26 Sep 2011 14:22:55 -0700 Received: from localhost ([127.0.0.1] helo=lists.colo.xensource.com) by lists.xensource.com with esmtp (Exim 4.43) id 1R8Ida-0002no-VX; Mon, 26 Sep 2011 14:22:55 -0700 Received: from mail182.messagelabs.com ([85.158.139.83]) by lists.xensource.com with esmtp (Exim 4.43) id 1R8Ick-0002b7-TU for xen-devel@lists.xensource.com; Mon, 26 Sep 2011 14:22:03 -0700 X-Env-Sender: tim@xen.org X-Msg-Ref: server-11.tower-182.messagelabs.com!1317072119!19830619!1 X-Originating-IP: [81.29.64.94] X-StarScan-Version: 6.4.1; banners=-,-,- X-VirusChecked: Checked Received: (qmail 27184 invoked from network); 26 Sep 2011 21:21:59 -0000 Received: from ocelot.phlegethon.org (HELO mail.phlegethon.org) (81.29.64.94) by server-11.tower-182.messagelabs.com with DHE-RSA-AES256-SHA encrypted SMTP; 26 Sep 2011 21:21:59 -0000 Received: from tjd by mail.phlegethon.org with local (Exim 4.67 (FreeBSD)) (envelope-from <tim@xen.org>) id 1R8Icf-00023j-3i; Mon, 26 Sep 2011 21:21:57 +0000 Date: Mon, 26 Sep 2011 22:21:57 +0100 From: Tim Deegan <tim@xen.org> To: Paul Durrant <paul.durrant@citrix.com> Subject: Re: [Xen-devel] [PATCH] Add save/restore support for viridian APIC assist pfn Message-ID: <20110926212157.GA7566@ocelot.phlegethon.org> References: <55a9ffe0ca81b9b41836.1316781366@localhost.localdomain> Mime-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline In-Reply-To: <55a9ffe0ca81b9b41836.1316781366@localhost.localdomain> User-Agent: Mutt/1.4.2.1i Cc: xen-devel@lists.xensource.com X-BeenThere: xen-devel@lists.xensource.com X-Mailman-Version: 2.1.5 Precedence: list List-Id: Xen developer discussion <xen-devel.lists.xensource.com> List-Unsubscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe> List-Post: <mailto:xen-devel@lists.xensource.com> List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help> List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=subscribe> Sender: xen-devel-bounces@lists.xensource.com Errors-To: xen-devel-bounces@lists.xensource.com At 13:36 +0100 on 23 Sep (1316784966), Paul Durrant wrote: > # HG changeset patch > # User Paul Durrant <paul.durrant@citrix.com> > # Date 1316781326 -3600 > # Node ID 55a9ffe0ca81b9b4183626f81fa54343d378704f > # Parent cc339ab1d91789ed6ff4d3d9abc1bae2e90ac294 > Add save/restore support for viridian APIC assist pfn. > > c/s 17b754cab7b0 introduced a per-VCPU viridian structure to > store the APIC assist pfn. This patch adds support for save and > restore of that value. > > Signed-off-by: Paul Durrant <paul.durrant@citrix.com> Applied, thanks. Tim. _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel From xen-devel-bounces@lists.xensource.com Mon Sep 26 14:24:27 2011 Return-path: <xen-devel-bounces@lists.xensource.com> Envelope-to: www-data@lists.xensource.com Delivery-date: Mon, 26 Sep 2011 14:24:27 -0700 Received: from localhost ([127.0.0.1] helo=lists.colo.xensource.com) by lists.xensource.com with esmtp (Exim 4.43) id 1R8If5-0003Gm-3s; Mon, 26 Sep 2011 14:24:27 -0700 Received: from mail216.messagelabs.com ([85.158.143.99]) by lists.xensource.com with esmtp (Exim 4.43) id 1R8Idk-0002pn-Nf for xen-devel@lists.xensource.com; Mon, 26 Sep 2011 14:23:06 -0700 X-Env-Sender: tim@xen.org X-Msg-Ref: server-10.tower-216.messagelabs.com!1317072181!11594569!1 X-Originating-IP: [81.29.64.94] X-StarScan-Version: 6.4.1; banners=-,-,- X-VirusChecked: Checked Received: (qmail 14720 invoked from network); 26 Sep 2011 21:23:01 -0000 Received: from ocelot.phlegethon.org (HELO mail.phlegethon.org) (81.29.64.94) by server-10.tower-216.messagelabs.com with DHE-RSA-AES256-SHA encrypted SMTP; 26 Sep 2011 21:23:01 -0000 Received: from tjd by mail.phlegethon.org with local (Exim 4.67 (FreeBSD)) (envelope-from <tim@xen.org>) id 1R8Idh-00024n-1C; Mon, 26 Sep 2011 21:23:01 +0000 Date: Mon, 26 Sep 2011 22:23:00 +0100 From: Tim Deegan <tim@xen.org> To: Olaf Hering <olaf@aepfle.de> Subject: Re: [Xen-devel] [PATCH] xenpaging: track number of paged pages in struct domain Message-ID: <20110926212300.GB7566@ocelot.phlegethon.org> References: <13b4be345ebac016abe2.1316089567@probook.site> <20110916112403.GB95880@ocelot.phlegethon.org> <20110916113254.GA7332@aepfle.de> <20110923161910.GA16514@aepfle.de> Mime-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline In-Reply-To: <20110923161910.GA16514@aepfle.de> User-Agent: Mutt/1.4.2.1i Cc: xen-devel@lists.xensource.com X-BeenThere: xen-devel@lists.xensource.com X-Mailman-Version: 2.1.5 Precedence: list List-Id: Xen developer discussion <xen-devel.lists.xensource.com> List-Unsubscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe> List-Post: <mailto:xen-devel@lists.xensource.com> List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help> List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=subscribe> Sender: xen-devel-bounces@lists.xensource.com Errors-To: xen-devel-bounces@lists.xensource.com At 18:19 +0200 on 23 Sep (1316801950), Olaf Hering wrote: > On Fri, Sep 16, Olaf Hering wrote: > > > > For the xen parts, Acked-by: Tim Deegan <tim@xen.org> > > > > > > Again, I'd like the tools maintainers to ack/nack the change to the domctl > > > interface and associated libxc plumbing. > > > > Thanks, but please wait a bit before applying it. > > Eventually a new XENMEM op is required as well to export that value for > > a guests balloon driver. I'm not finished yet with browsing the > > codepaths which make use of tot_pages. > > Please go ahead with applying. > The balloon driver does not need to know about paged pages, its job is > to just free as many pages as it is asked for by xenstore or sysfs. Applied, thanks. Is that all the outstanding xenpaging patches? Tim. _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel From xen-devel-bounces@lists.xensource.com Mon Sep 26 18:00:56 2011 Return-path: <xen-devel-bounces@lists.xensource.com> Envelope-to: www-data@lists.xensource.com Delivery-date: Mon, 26 Sep 2011 18:00:56 -0700 Received: from localhost ([127.0.0.1] helo=lists.colo.xensource.com) by lists.xensource.com with esmtp (Exim 4.43) id 1R8M2Z-00085Z-6k; Mon, 26 Sep 2011 18:00:55 -0700 Received: from mail21.messagelabs.com ([85.158.143.35]) by lists.xensource.com with esmtp (Exim 4.43) id 1R8M1W-0007sr-AX for xen-devel@lists.xensource.com; Mon, 26 Sep 2011 17:59:50 -0700 X-Env-Sender: james.harper@bendigoit.com.au X-Msg-Ref: server-2.tower-21.messagelabs.com!1317085182!35593684!1 X-Originating-IP: [203.16.207.99] X-StarScan-Version: 6.4.1; banners=-,-,- X-VirusChecked: Checked Received: (qmail 18713 invoked from network); 27 Sep 2011 00:59:45 -0000 Received: from mail.bendigoit.com.au (HELO smtp2.bendigoit.com.au) (203.16.207.99) by server-2.tower-21.messagelabs.com with AES256-SHA encrypted SMTP; 27 Sep 2011 00:59:45 -0000 Received: from trantor.int.sbss.com.au ([192.168.200.206] helo=mail.bendigoit.com.au) by smtp2.bendigoit.com.au with esmtp (Exim 4.72) (envelope-from <james.harper@bendigoit.com.au>) id 1R8M1L-0007s0-SH; Tue, 27 Sep 2011 10:59:39 +1000 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable X-MimeOLE: Produced By Microsoft Exchange V6.5 Subject: RE: [Xen-devel] RE: Stability report GPLPV 0.11.0.308 Date: Tue, 27 Sep 2011 10:59:39 +1000 Message-ID: <AEC6C66638C05B468B556EA548C1A77D01E5E157@trantor> In-Reply-To: <4E808FE9.5050008@hfp.de> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Xen-devel] RE: Stability report GPLPV 0.11.0.308 Thread-Index: Acx8WuNjCktw+sZPQ3irGUdjGcNOgQAVZIdQ References: <4E64A0DF.2070007@hfp.de> <AEC6C66638C05B468B556EA548C1A77D01E5DB8C@trantor> <4E64D569.5030607@hfp.de> <AEC6C66638C05B468B556EA548C1A77D01E5DBBF@trantor> <4E7728F9.9020208@hfp.de> <AEC6C66638C05B468B556EA548C1A77D01E5E008@trantor> <4E7B04A4.9070601@hfp.de> <AEC6C66638C05B468B556EA548C1A77D01E5E072@trantor> <4E7CF2A8.5040405@hfp.de> <AEC6C66638C05B468B556EA548C1A77D01E5E0D0@trantor> <4E808FE9.5050008@hfp.de> From: "James Harper" <james.harper@bendigoit.com.au> To: "Andreas Kinzler" <ml-xen-devel@hfp.de> X-Really-From-Bendigo-IT: magichashvalue Cc: xen-devel@lists.xensource.com X-BeenThere: xen-devel@lists.xensource.com X-Mailman-Version: 2.1.5 Precedence: list List-Id: Xen developer discussion <xen-devel.lists.xensource.com> List-Unsubscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe> List-Post: <mailto:xen-devel@lists.xensource.com> List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help> List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=subscribe> Sender: xen-devel-bounces@lists.xensource.com Errors-To: xen-devel-bounces@lists.xensource.com >=20 > On 24.09.2011 01:49, James Harper wrote: > > I'm just setting up a few new servers and on one of them a Windows > > 2008R2 machine hung and there were lots of xenvbd errors in the logs. > > The underlying block device for that DomU is iSCSI and I assumed the > > problem was there (I was doing a lot of testing on the SAN at the > > time) but maybe not. >=20 > Hmmm, do you have any more ideas? Anything how I could help you > debugging? You could look for all the failure paths (eg can't allocate buffer etc) and put debug prints there. I'm almost in a position to be able to start testing a bit better now. James _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel From xen-devel-bounces@lists.xensource.com Mon Sep 26 18:13:04 2011 Return-path: <xen-devel-bounces@lists.xensource.com> Envelope-to: www-data@lists.xensource.com Delivery-date: Mon, 26 Sep 2011 18:13:04 -0700 Received: from localhost ([127.0.0.1] helo=lists.colo.xensource.com) by lists.xensource.com with esmtp (Exim 4.43) id 1R8MEJ-0000Ap-Uh; Mon, 26 Sep 2011 18:13:03 -0700 Received: from mail216.messagelabs.com ([85.158.143.99]) by lists.xensource.com with esmtp (Exim 4.43) id 1R8MDp-0008QG-SB for xen-devel@lists.xensource.com; Mon, 26 Sep 2011 18:12:34 -0700 X-Env-Sender: james.harper@bendigoit.com.au X-Msg-Ref: server-4.tower-216.messagelabs.com!1317085947!19663980!1 X-Originating-IP: [203.16.224.4] X-StarScan-Version: 6.4.1; banners=-,-,- X-VirusChecked: Checked Received: (qmail 22433 invoked from network); 27 Sep 2011 01:12:30 -0000 Received: from smtp1.bendigoit.com.au (HELO smtp1.bendigoit.com.au) (203.16.224.4) by server-4.tower-216.messagelabs.com with AES256-SHA encrypted SMTP; 27 Sep 2011 01:12:30 -0000 Received: from mail.bendigoit.com.au ([203.16.207.99]) by smtp1.bendigoit.com.au with esmtp (Exim 4.69) (envelope-from <james.harper@bendigoit.com.au>) id 1R8MDW-0008Sq-Oi; Tue, 27 Sep 2011 11:12:14 +1000 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable X-MimeOLE: Produced By Microsoft Exchange V6.5 Subject: RE: [Xen-devel] xen + windbg.. Date: Tue, 27 Sep 2011 11:12:14 +1000 Message-ID: <AEC6C66638C05B468B556EA548C1A77D01E5E15A@trantor> In-Reply-To: <20110926191556.GU12984@reaktio.net> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Xen-devel] xen + windbg.. Thread-Index: Acx8gMLkpICzLErbRTyn943apH6gBwAMZJCw References: <CACyYOe+78Jss5AmBqwLa-d=0+9mSzh0DbpGOx4KQJO=wqOeJVA@mail.gmail.com> <20110926191556.GU12984@reaktio.net> From: "James Harper" <james.harper@bendigoit.com.au> To: =?iso-8859-1?Q?Pasi_K=E4rkk=E4inen?= <pasik@iki.fi>, "piyush jain" <piyush.today@gmail.com> X-Really-From-Bendigo-IT: magichashvalue Cc: Paul Durrant <Paul.Durrant@citrix.com>, xen-devel@lists.xensource.com X-BeenThere: xen-devel@lists.xensource.com X-Mailman-Version: 2.1.5 Precedence: list List-Id: Xen developer discussion <xen-devel.lists.xensource.com> List-Unsubscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe> List-Post: <mailto:xen-devel@lists.xensource.com> List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help> List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=subscribe> Sender: xen-devel-bounces@lists.xensource.com Errors-To: xen-devel-bounces@lists.xensource.com >=20 > On Mon, Sep 26, 2011 at 04:39:08PM +0530, piyush jain wrote: > > Hi, > > Is it possible to connect windbg to guest windows 2008 R2, over = xen? > > > > Anyone how did it succesfully? > > > > I tried steps in this links > > > > [1]http://wiki.xensource.com/xenwiki/XenWindowsGplPv > > > > but it's not working for me :( (i modified add in xinited, = instead of > > inetd.conf) > > > > Can any1 update this doc? > > >=20 > Hey, >=20 > Maybe James or Paul can comment.. >=20 > -- Pasi Can you start with a tcpdump of the traffic between the two endpoints? James _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel From xen-devel-bounces@lists.xensource.com Mon Sep 26 19:23:48 2011 Return-path: <xen-devel-bounces@lists.xensource.com> Envelope-to: www-data@lists.xensource.com Delivery-date: Mon, 26 Sep 2011 19:23:48 -0700 Received: from localhost ([127.0.0.1] helo=lists.colo.xensource.com) by lists.xensource.com with esmtp (Exim 4.43) id 1R8NKm-0002Wd-0z; Mon, 26 Sep 2011 19:23:48 -0700 Received: from mail174.messagelabs.com ([85.158.138.51]) by lists.xensource.com with smtp (Exim 4.43) id 1R8NJs-0002K9-RK for xen-devel@lists.xensource.com; Mon, 26 Sep 2011 19:22:54 -0700 X-Env-Sender: tinnycloud@hotmail.com X-Msg-Ref: server-15.tower-174.messagelabs.com!1317090168!26512106!1 X-Originating-IP: [65.55.116.29] X-StarScan-Version: 6.4.1; banners=-,-,- X-VirusChecked: Checked Received: (qmail 21175 invoked from network); 27 Sep 2011 02:22:49 -0000 Received: from blu0-omc1-s18.blu0.hotmail.com (HELO blu0-omc1-s18.blu0.hotmail.com) (65.55.116.29) by server-15.tower-174.messagelabs.com with SMTP; 27 Sep 2011 02:22:49 -0000 Received: from BLU157-W5 ([65.55.116.7]) by blu0-omc1-s18.blu0.hotmail.com with Microsoft SMTPSVC(6.0.3790.4675); Mon, 26 Sep 2011 19:22:48 -0700 Message-ID: <BLU157-W54420DD5C05CB38610F67DAF00@phx.gbl> X-Originating-IP: [121.0.29.75] From: MaoXiaoyun <tinnycloud@hotmail.com> To: <konrad.wilk@oracle.com> Date: Tue, 27 Sep 2011 10:22:48 +0800 Importance: Normal In-Reply-To: <20110926142808.GG4102@phenom.oracle.com> References: <BLU157-W499E698F650F554E645F9DDA1C0@phx.gbl>, <20110906145347.GA4133@dumpdata.com>, <BLU157-W4106FA4CF4EBA78C63FDA0DA1C0@phx.gbl>, <4E666C86.5090707@goop.org>, <BLU157-W323C330706CB8D7E976BC3DA1F0@phx.gbl>, <BLU157-W7DABA5FE01C50C29B1A64DA060@phx.gbl>, <BLU157-W25EB1EAC24CC11FA14859ADAF20@phx.gbl>, <20110926142808.GG4102@phenom.oracle.com> Content-Type: text/plain; charset="gb2312" Content-Transfer-Encoding: 8bit MIME-Version: 1.0 X-OriginalArrivalTime: 27 Sep 2011 02:22:48.0458 (UTC) FILETIME=[59866EA0:01CC7CBC] Cc: jack@suse.cz, jeremy@goop.org, linux-ext4@vger.kernel.org, tytso@mit.edu, xen devel <xen-devel@lists.xensource.com> Subject: [Xen-devel] RE: [patch 1/1] ext4-fix-dirty-extent-when-origin-leaf-extent-reac.patch X-BeenThere: xen-devel@lists.xensource.com X-Mailman-Version: 2.1.5 Precedence: list List-Id: Xen developer discussion <xen-devel.lists.xensource.com> List-Unsubscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe> List-Post: <mailto:xen-devel@lists.xensource.com> List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help> List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=subscribe> Sender: xen-devel-bounces@lists.xensource.com Errors-To: xen-devel-bounces@lists.xensource.com ---------------------------------------- > Date: Mon, 26 Sep 2011 10:28:08 -0400 > From: konrad.wilk@oracle.com > To: tinnycloud@hotmail.com > CC: linux-ext4@vger.kernel.org; xen-devel@lists.xensource.com; tytso@mit.edu; jack@suse.cz > Subject: Re: [patch 1/1] ext4-fix-dirty-extent-when-origin-leaf-extent-reac.patch > > On Sun, Sep 25, 2011 at 04:45:39PM +0800, MaoXiaoyun wrote: > > > > > > Hi: > > > > We met an ext4 BUG_ON in extents.c:1716 which crash kernel flush thread, and result in disk unvailiable. > > > > BUG details refer to: http://www.gossamer-threads.com/lists/xen/devel/217091?do=post_view_threaded > > > > Attached is the fix, verified in our env. > > So.. you are asking for this upstream git commit to be back-ported to 2.6.32, right? > The patch is for 2.6.39. It can be patched on 2.6.32 too. Thanks. > > > > Without this patch, more than 3 servers hit BUG_ON in our hundreds of servers every day. > > > > > > many thanks. > > _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel From xen-devel-bounces@lists.xensource.com Mon Sep 26 22:46:40 2011 Return-path: <xen-devel-bounces@lists.xensource.com> Envelope-to: www-data@lists.xensource.com Delivery-date: Mon, 26 Sep 2011 22:46:40 -0700 Received: from localhost ([127.0.0.1] helo=lists.colo.xensource.com) by lists.xensource.com with esmtp (Exim 4.43) id 1R8QV6-0008TR-NP; Mon, 26 Sep 2011 22:46:40 -0700 Received: from mail21.messagelabs.com ([85.158.143.35]) by lists.xensource.com with esmtp (Exim 4.43) id 1R8QUN-0008H9-Vm for xen-devel@lists.xensource.com; Mon, 26 Sep 2011 22:45:56 -0700 X-Env-Sender: james.harper@bendigoit.com.au X-Msg-Ref: server-7.tower-21.messagelabs.com!1317102318!56359122!1 X-Originating-IP: [203.16.207.99] X-StarScan-Version: 6.4.1; banners=-,-,- X-VirusChecked: Checked Received: (qmail 10029 invoked from network); 27 Sep 2011 05:45:21 -0000 Received: from mail.bendigoit.com.au (HELO smtp2.bendigoit.com.au) (203.16.207.99) by server-7.tower-21.messagelabs.com with AES256-SHA encrypted SMTP; 27 Sep 2011 05:45:21 -0000 Received: from trantor.int.sbss.com.au ([192.168.200.206] helo=mail.bendigoit.com.au) by smtp2.bendigoit.com.au with esmtp (Exim 4.72) (envelope-from <james.harper@bendigoit.com.au>) id 1R8QUE-0000kM-CI; Tue, 27 Sep 2011 15:45:46 +1000 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable X-MimeOLE: Produced By Microsoft Exchange V6.5 Subject: RE: [Xen-devel] RE: Stability report GPLPV 0.11.0.308 Date: Tue, 27 Sep 2011 15:45:45 +1000 Message-ID: <AEC6C66638C05B468B556EA548C1A77D01E5E190@trantor> In-Reply-To: <4E808FE9.5050008@hfp.de> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Xen-devel] RE: Stability report GPLPV 0.11.0.308 Thread-Index: Acx8WuNjCktw+sZPQ3irGUdjGcNOgQAfQnqg References: <4E64A0DF.2070007@hfp.de> <AEC6C66638C05B468B556EA548C1A77D01E5DB8C@trantor> <4E64D569.5030607@hfp.de> <AEC6C66638C05B468B556EA548C1A77D01E5DBBF@trantor> <4E7728F9.9020208@hfp.de> <AEC6C66638C05B468B556EA548C1A77D01E5E008@trantor> <4E7B04A4.9070601@hfp.de> <AEC6C66638C05B468B556EA548C1A77D01E5E072@trantor> <4E7CF2A8.5040405@hfp.de> <AEC6C66638C05B468B556EA548C1A77D01E5E0D0@trantor> <4E808FE9.5050008@hfp.de> From: "James Harper" <james.harper@bendigoit.com.au> To: "Andreas Kinzler" <ml-xen-devel@hfp.de> X-Really-From-Bendigo-IT: magichashvalue Cc: xen-devel@lists.xensource.com X-BeenThere: xen-devel@lists.xensource.com X-Mailman-Version: 2.1.5 Precedence: list List-Id: Xen developer discussion <xen-devel.lists.xensource.com> List-Unsubscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe> List-Post: <mailto:xen-devel@lists.xensource.com> List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help> List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=subscribe> Sender: xen-devel-bounces@lists.xensource.com Errors-To: xen-devel-bounces@lists.xensource.com >=20 > On 24.09.2011 01:49, James Harper wrote: > > I'm just setting up a few new servers and on one of them a Windows > > 2008R2 machine hung and there were lots of xenvbd errors in the logs. > > The underlying block device for that DomU is iSCSI and I assumed the > > problem was there (I was doing a lot of testing on the SAN at the > > time) but maybe not. >=20 > Hmmm, do you have any more ideas? Anything how I could help you > debugging? >=20 > > No evidence of problems in /var/log/xen/qemu-dm-<domu name>.log? >=20 > I did not see anything special. >=20 I just had a crash under heavy testing: 12961573357740: 12961573357740: *** Assertion failed: pi.curr_mdl 12961573357740: *** Source File: c:\projects\win-pvdrivers.hg\xennet\xennet6_tx.c, line 308 12961573357740: Can you have a look in your logs for anything like this? I'm curious as to if we are chasing the same problem or a different one. I haven't checked yet to make sure I am running the latest code on that server so it could just be something stupid... James _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel From xen-users-bounces@lists.xensource.com Mon Sep 26 23:32:33 2011 Return-path: <xen-users-bounces@lists.xensource.com> Envelope-to: www-data@lists.xensource.com Delivery-date: Mon, 26 Sep 2011 23:32:33 -0700 Received: from localhost ([127.0.0.1] helo=lists.colo.xensource.com) by lists.xensource.com with esmtp (Exim 4.43) id 1R8RDV-0001YS-GY; Mon, 26 Sep 2011 23:32:33 -0700 Received: from mail182.messagelabs.com ([85.158.139.83]) by lists.xensource.com with esmtp (Exim 4.43) id 1R8Ggz-0003Hm-FW; Mon, 26 Sep 2011 12:18:24 -0700 X-Env-Sender: andrey.warkentin@gmail.com X-Msg-Ref: server-3.tower-182.messagelabs.com!1317064694!17032767!1 X-Originating-IP: [74.125.82.171] X-StarScan-Version: 6.4.1; banners=-,-,- X-VirusChecked: Checked Received: (qmail 32224 invoked from network); 26 Sep 2011 19:18:14 -0000 Received: from mail-wy0-f171.google.com (HELO mail-wy0-f171.google.com) (74.125.82.171) by server-3.tower-182.messagelabs.com with RC4-SHA encrypted SMTP; 26 Sep 2011 19:18:14 -0000 Received: by wyh13 with SMTP id 13so5682057wyh.30 for <multiple recipients>; Mon, 26 Sep 2011 12:18:14 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=Ng7bbeLtLpQwlBy9RhHlTgLm7w5l4Mc/nYn3H++Nnhk=; b=dWGaUEqtN+7+yg6vRSj8Iuw1R1pDCri0XqmCEpAgDsAX8daQKpJFuAZLt6IkVMNn7J ybL6tIbeIT161gIlr06uVZ2EPK6QzJU6QGUXT8JcVR2XHC8wpJSwLYX0sU6o0sAnkfeP b4ro8iX+4S3R579TASFHJt3WSN+TcfecCxyns= MIME-Version: 1.0 Received: by 10.216.229.198 with SMTP id h48mr3054717weq.45.1317064694088; Mon, 26 Sep 2011 12:18:14 -0700 (PDT) Received: by 10.216.187.130 with HTTP; Mon, 26 Sep 2011 12:18:13 -0700 (PDT) In-Reply-To: <1317024471.24532.2.camel@zakaz.uk.xensource.com> References: <CAA48DAF.2172A%keir.xen@gmail.com> <1317024471.24532.2.camel@zakaz.uk.xensource.com> Date: Mon, 26 Sep 2011 15:18:13 -0400 Message-ID: <CANz0V+6rBpboTiYb0YiFnSLTDHDSskSdyFxvkUZt8FoY89n0aw@mail.gmail.com> Subject: Re: [Xen-devel] Re: [Xen-users] Is xen planning to support hvm guests booting under UEFI? From: "Andrei E. Warkentin" <andrey.warkentin@gmail.com> To: Ian Campbell <Ian.Campbell@citrix.com> Content-Type: text/plain; charset=UTF-8 X-Mailman-Approved-At: Mon, 26 Sep 2011 23:30:43 -0700 Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>, Keir Fraser <keir.xen@gmail.com>, jim burns <jim_burn@bellsouth.net>, Bei Guan <gbtju85@gmail.com>, Paul Durrant <Paul.Durrant@citrix.com>, Todd Deshane <todd.deshane@xen.org>, Jordan Justen <jljusten@gmail.com>, "xen-users@lists.xensource.com" <xen-users@lists.xensource.com> X-BeenThere: xen-users@lists.xensource.com X-Mailman-Version: 2.1.5 Precedence: list List-Id: Xen user discussion <xen-users.lists.xensource.com> List-Unsubscribe: <http://lists.xensource.com/mailman/listinfo/xen-users>, <mailto:xen-users-request@lists.xensource.com?subject=unsubscribe> List-Post: <mailto:xen-users@lists.xensource.com> List-Help: <mailto:xen-users-request@lists.xensource.com?subject=help> List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-users>, <mailto:xen-users-request@lists.xensource.com?subject=subscribe> Sender: xen-users-bounces@lists.xensource.com Errors-To: xen-users-bounces@lists.xensource.com Hi Ian, Keir, others - I was the mentor for the project. We got to the point where OVMF on Xen was indistinguishable from OVMF on QEMU as far as emulated device support (Bei can confirm - is this true for network/PXE boot as well?). ACPI and DMI info published from the hvmloader is consumed by the firmware and published. I believe we could boot RedHat. Last I checked Win7 was unbootable under QEMU with OVMF (so we didn't check) and I don't know the status of that (if I remember correctly, it BSODs in bootvid.sys (under QEMU) due to low memory area not being reserved away, or because there is no fake IDT set up - that seems to match up with the hoops I needed to do doing similar work on Hyper-V). OVMF is aware of Xen, and work was being done on a PV block device (Bei got as far as hypercall support and xenstore). Bei, are you working on the PV block driver? I want to say we're pretty close on that one (PV block not very hard, and neither is the block device abstraction for EFI). I/Bei had patches against hvmloader (to support booting OVMF) and Bei had patches against the management stack as well to expose the functionality of picking OVMF as the firmware. I believe all of these were sent to xen development list. Jordan Justen (Intel) had been working on integrating the OVMF changes last I checked, but I am not positive (I just changed jobs and relocated, and still am not on the TianoCore mailing list). I am adding him to the reply. A 2011/9/26 Ian Campbell <Ian.Campbell@citrix.com>: > Adding Bei Guan and Andrey Warkentin who I think were student and mentor > respectively. Hi guys! > > On Sun, 2011-09-25 at 15:50 +0100, Keir Fraser wrote: >> The GSOC project student seemed to be making good progress, and there were >> others on the OVMF side who were giving him support. I haven't heard >> anything in about a month now, though. > > It would be very interesting to get an update (or a pointer to one) of > the status/result of this particular project now that the GSoC is over. > > Thanks, > Ian. _______________________________________________ Xen-users mailing list Xen-users@lists.xensource.com http://lists.xensource.com/xen-users From xen-devel-bounces@lists.xensource.com Mon Sep 26 23:40:30 2011 Return-path: <xen-devel-bounces@lists.xensource.com> Envelope-to: www-data@lists.xensource.com Delivery-date: Mon, 26 Sep 2011 23:40:30 -0700 Received: from localhost ([127.0.0.1] helo=lists.colo.xensource.com) by lists.xensource.com with esmtp (Exim 4.43) id 1R8RLB-0002Yl-Sz; Mon, 26 Sep 2011 23:40:29 -0700 Received: from mail174.messagelabs.com ([85.158.138.51]) by lists.xensource.com with esmtp (Exim 4.43) id 1R8RKk-0002Ma-Mf; Mon, 26 Sep 2011 23:40:04 -0700 X-Env-Sender: pasik@iki.fi X-Msg-Ref: server-14.tower-174.messagelabs.com!1317105598!32876872!1 X-Originating-IP: [192.89.123.25] X-StarScan-Version: 6.4.1; banners=-,-,- X-VirusChecked: Checked Received: (qmail 25511 invoked from network); 27 Sep 2011 06:39:59 -0000 Received: from smtp.tele.fi (HELO smtp.tele.fi) (192.89.123.25) by server-14.tower-174.messagelabs.com with DHE-RSA-AES256-SHA encrypted SMTP; 27 Sep 2011 06:39:59 -0000 X-Originating-Ip: [194.89.68.22] Received: from ydin.reaktio.net (reaktio.net [194.89.68.22]) by smtp.tele.fi (Postfix) with ESMTP id 005DD1445; Tue, 27 Sep 2011 09:39:56 +0300 (EEST) Received: by ydin.reaktio.net (Postfix, from userid 1001) id 37527200E8; Tue, 27 Sep 2011 09:39:56 +0300 (EEST) Date: Tue, 27 Sep 2011 09:39:56 +0300 From: Pasi =?iso-8859-1?Q?K=E4rkk=E4inen?= <pasik@iki.fi> To: Peter <peter@pajamian.dhs.org> Message-ID: <20110927063955.GV12984@reaktio.net> References: <4E7A356F.7050105@pajamian.dhs.org> <CAG1y0scMBO4VQZwnsLwSSJH3VPJP_NmUNBas68rsc47gRM2WGA@mail.gmail.com> <20110926190441.GS12984@reaktio.net> <4E814893.3010009@pajamian.dhs.org> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <4E814893.3010009@pajamian.dhs.org> User-Agent: Mutt/1.5.18 (2008-05-17) Cc: xen-devel@lists.xensource.com, xen-users@lists.xensource.com Subject: [Xen-devel] Re: [Xen-users] old RHEL3 domu kernel download X-BeenThere: xen-devel@lists.xensource.com X-Mailman-Version: 2.1.5 Precedence: list List-Id: Xen developer discussion <xen-devel.lists.xensource.com> List-Unsubscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe> List-Post: <mailto:xen-devel@lists.xensource.com> List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help> List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=subscribe> Sender: xen-devel-bounces@lists.xensource.com Errors-To: xen-devel-bounces@lists.xensource.com On Tue, Sep 27, 2011 at 04:52:51PM +1300, Peter wrote: > On 27/09/11 08:04, Pasi Kärkkäinen wrote: > >> On Thu, Sep 22, 2011 at 2:05 AM, Peter <peter@pajamian.dhs.org> wrote: > >>> I need to port over an old RHEL3 box to a xen domU (just for a little > >>> while until I can transfer all of its services over to a new domain). I > >>> was hoping to get a domU supported kernel so I can run it as a PV guest > >>> and found this page: > >>> > >>> http://xen.org/download/dl_304guest_rhel3.html > >>> > >>> ...but the links to the actual kernels come up with 404 errors. Anyone > >>> know where I can get this kernel from? > > > > The url mentioned above had Xen PV enabled Linux 2.4 kernel for RHEL3 (based on the actual RHEL3 kernel) > > It was developed by Xensource, back in the days. > > > > It was removed because it had some known bugs, and it is unmaintained. > > I think this is actually a violation of the GPL. It was distributed so > at least the source code has to remain available. > No it's not really a GPL violation. When the binary was still available, also the sources were available. People who only downloaded the binaries back then could always request the source by written notice, as required by GPL. .. that's not very nice or practical though. I think the reason why the rhel3 pv kernel downloads were removed was because the kernel was so buggy and it's better if noone uses them. > >> Another alternative is to contact Redhat. IIRC the supported > >> configuration is to use HVM (or KVM, if your host is RHEL6), but you > >> might be able to get PV drivers. > >> > > > > RHEL3 ships with Xen PVHVM drivers included, so install RHEL3 as Xen HVM VM, > > and then enable the PV drivers! > > > > That's the best way, and it's supported by Redhat. > > I will give that a try, but I haven't had much success with HVM yet. RHEL3 is supported (by Redhat) as HVM guest on RHEL5 dom0, and it works. > What I have actually ended up doing in the past is getting RHEL to work > with a 2.6 kernel (albeit with a few bugs of its own that way). Would > using the (buggy) 2.4 kernel be any worse than that? > Someone might still have access to the old rhel3 PV kernels, but I don't think you should use them. RHEL3 Xen HVM with PV drivers is shipped and supported by Redhat. The old rhel3 pv kernels were removed with a reason.. -- Pasi _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel From xen-devel-bounces@lists.xensource.com Tue Sep 27 00:36:56 2011 Return-path: <xen-devel-bounces@lists.xensource.com> Envelope-to: www-data@lists.xensource.com Delivery-date: Tue, 27 Sep 2011 00:36:56 -0700 Received: from localhost ([127.0.0.1] helo=lists.colo.xensource.com) by lists.xensource.com with esmtp (Exim 4.43) id 1R8SDo-0005Gb-EJ; Tue, 27 Sep 2011 00:36:56 -0700 Received: from mail216.messagelabs.com ([85.158.143.99]) by lists.xensource.com with esmtp (Exim 4.43) id 1R8SCs-00053d-FZ for xen-devel@lists.xensource.com; Tue, 27 Sep 2011 00:35:58 -0700 X-Env-Sender: olaf@aepfle.de X-Msg-Ref: server-12.tower-216.messagelabs.com!1317108954!13966469!1 X-Originating-IP: [81.169.146.162] X-StarScan-Version: 6.4.1; banners=-,-,- X-VirusChecked: Checked Received: (qmail 31061 invoked from network); 27 Sep 2011 07:35:55 -0000 Received: from mo-p00-ob.rzone.de (HELO mo-p00-ob.rzone.de) (81.169.146.162) by server-12.tower-216.messagelabs.com with DHE-RSA-AES256-SHA encrypted SMTP; 27 Sep 2011 07:35:55 -0000 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; t=1317108954; l=181; s=domk; d=aepfle.de; h=In-Reply-To:Content-Type:MIME-Version:References:Subject:Cc:To:From: Date:X-RZG-CLASS-ID:X-RZG-AUTH; bh=tOpKUFevN68SnOq313ljmgrMd2w=; b=PYZhgSGR0q8W65XsRfNQ1imul2fAjyrdi/qhY7KIYuSLRRdybjuDjjQUgFy4wsVtttt 0xnX7X45KwsJs0860c5+CgDO+otVmCNor/pdyPFh7jncM2T6lGwgf/WWw8Ap0Wts2e3HW EH4rbO1W1Ae/CkiEfkawj7eCGIsAavW1B9E= X-RZG-AUTH: :P2EQZWCpfu+qG7CngxMFH1J+zrwiavkK6tmQaLfmztM8TOFPjDEQEHc= X-RZG-CLASS-ID: mo00 Received: from probook.site (dslb-088-065-122-003.pools.arcor-ip.net [88.65.122.3]) by smtp.strato.de (cohen mo34) (RZmta 26.7) with (DHE-RSA-AES256-SHA encrypted) ESMTPA id j057cen8R68JRv ; Tue, 27 Sep 2011 09:35:51 +0200 (MEST) Received: by probook.site (Postfix, from userid 1000) id 6063418B65; Tue, 27 Sep 2011 09:35:50 +0200 (CEST) Date: Tue, 27 Sep 2011 09:35:50 +0200 From: Olaf Hering <olaf@aepfle.de> To: Tim Deegan <tim@xen.org> Subject: Re: [Xen-devel] [PATCH] xenpaging: track number of paged pages in struct domain Message-ID: <20110927073550.GA6049@aepfle.de> References: <13b4be345ebac016abe2.1316089567@probook.site> <20110916112403.GB95880@ocelot.phlegethon.org> <20110916113254.GA7332@aepfle.de> <20110923161910.GA16514@aepfle.de> <20110926212300.GB7566@ocelot.phlegethon.org> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline In-Reply-To: <20110926212300.GB7566@ocelot.phlegethon.org> User-Agent: Mutt/1.5.21.rev5535 (2011-07-01) Cc: xen-devel@lists.xensource.com X-BeenThere: xen-devel@lists.xensource.com X-Mailman-Version: 2.1.5 Precedence: list List-Id: Xen developer discussion <xen-devel.lists.xensource.com> List-Unsubscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe> List-Post: <mailto:xen-devel@lists.xensource.com> List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help> List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=subscribe> Sender: xen-devel-bounces@lists.xensource.com Errors-To: xen-devel-bounces@lists.xensource.com On Mon, Sep 26, Tim Deegan wrote: > Applied, thanks. Is that all the outstanding xenpaging patches? No, I have a dozen more in the queue, both tools and xen changes. Olaf _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel From xen-devel-bounces@lists.xensource.com Tue Sep 27 00:48:41 2011 Return-path: <xen-devel-bounces@lists.xensource.com> Envelope-to: www-data@lists.xensource.com Delivery-date: Tue, 27 Sep 2011 00:48:41 -0700 Received: from localhost ([127.0.0.1] helo=lists.colo.xensource.com) by lists.xensource.com with esmtp (Exim 4.43) id 1R8SPB-00061q-H5; Tue, 27 Sep 2011 00:48:41 -0700 Received: from mail21.messagelabs.com ([85.158.143.35]) by lists.xensource.com with esmtp (Exim 4.43) id 1R8SOa-0005pv-E6; Tue, 27 Sep 2011 00:48:04 -0700 X-Env-Sender: Ian.Campbell@eu.citrix.com X-Msg-Ref: server-7.tower-21.messagelabs.com!1317109650!56374409!1 X-Originating-IP: [62.200.22.115] X-StarScan-Version: 6.4.1; banners=-,-,- X-VirusChecked: Checked Received: (qmail 32166 invoked from network); 27 Sep 2011 07:47:30 -0000 Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115) by server-7.tower-21.messagelabs.com with RC4-SHA encrypted SMTP; 27 Sep 2011 07:47:30 -0000 X-IronPort-AV: E=Sophos;i="4.68,448,1312156800"; d="scan'208";a="8073378" Received: from lonpmailmx01.citrite.net ([10.30.203.162]) by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5; 27 Sep 2011 07:48:01 +0000 Received: from [127.0.0.1] (10.80.16.67) by smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id 8.3.137.0; Tue, 27 Sep 2011 08:48:01 +0100 From: Ian Campbell <Ian.Campbell@citrix.com> To: Pasi =?ISO-8859-1?Q?K=E4rkk=E4inen?= <pasik@iki.fi> In-Reply-To: <20110927063955.GV12984@reaktio.net> References: <4E7A356F.7050105@pajamian.dhs.org> <CAG1y0scMBO4VQZwnsLwSSJH3VPJP_NmUNBas68rsc47gRM2WGA@mail.gmail.com> <20110926190441.GS12984@reaktio.net> <4E814893.3010009@pajamian.dhs.org> <20110927063955.GV12984@reaktio.net> Content-Type: text/plain; charset="ISO-8859-1" Organization: Citrix Systems, Inc. Date: Tue, 27 Sep 2011 08:48:00 +0100 Message-ID: <1317109680.13424.50.camel@dagon.hellion.org.uk> MIME-Version: 1.0 X-Mailer: Evolution 2.32.3 Content-Transfer-Encoding: 8bit Cc: Peter <peter@pajamian.dhs.org>, "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>, "xen-users@lists.xensource.com" <xen-users@lists.xensource.com> Subject: [Xen-devel] Re: [Xen-users] old RHEL3 domu kernel download X-BeenThere: xen-devel@lists.xensource.com X-Mailman-Version: 2.1.5 Precedence: list List-Id: Xen developer discussion <xen-devel.lists.xensource.com> List-Unsubscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe> List-Post: <mailto:xen-devel@lists.xensource.com> List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help> List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=subscribe> Sender: xen-devel-bounces@lists.xensource.com Errors-To: xen-devel-bounces@lists.xensource.com On Tue, 2011-09-27 at 07:39 +0100, Pasi Kärkkäinen wrote: > On Tue, Sep 27, 2011 at 04:52:51PM +1300, Peter wrote: > > On 27/09/11 08:04, Pasi Kärkkäinen wrote: > > >> On Thu, Sep 22, 2011 at 2:05 AM, Peter <peter@pajamian.dhs.org> wrote: > > >>> I need to port over an old RHEL3 box to a xen domU (just for a little > > >>> while until I can transfer all of its services over to a new domain). I > > >>> was hoping to get a domU supported kernel so I can run it as a PV guest > > >>> and found this page: > > >>> > > >>> http://xen.org/download/dl_304guest_rhel3.html > > >>> > > >>> ...but the links to the actual kernels come up with 404 errors. Anyone > > >>> know where I can get this kernel from? > > > > > > The url mentioned above had Xen PV enabled Linux 2.4 kernel for RHEL3 (based on the actual RHEL3 kernel) > > > It was developed by Xensource, back in the days. > > > > > > It was removed because it had some known bugs, and it is unmaintained. > > > > I think this is actually a violation of the GPL. It was distributed so > > at least the source code has to remain available. I think you need to reread the GPL before making such serious claims. There is no such requirement that "source code has to remain available". There are some clauses which sound superficially like such a requirement but they are time limited and in any case do not apply in every case of distribution of a work since there are other alternatives allowed by the license. > No it's not really a GPL violation. When the binary was still available, > also the sources were available. Correct. These binary RPMs were always accompanied by the corresponding source RPM and therefore clause 3(a) of the GPL is satisfied: a) Accompany it with the complete corresponding machine-readable source code, which must be distributed under the terms of Sections 1 and 2 above on a medium customarily used for software interchange; or, > People who only downloaded the binaries back then could always request > the source by written notice, as required by GPL. That is clause 3(b): b) Accompany it with a written offer, valid for at least three years, to give any third party, for a charge no more than your cost of physically performing source distribution, a complete machine-readable copy of the corresponding source code, to be distributed under the terms of Sections 1 and 2 above on a medium customarily used for software interchange; or, AFAIK there was no explicit written offer given with these kernels so strictly speaking this clause is not active. Note that the sub-clauses of section 3 are _alternatives_ which may be selected by the distributor and since option 3(a) is satisfied this is not a GPL violation. > .. that's not very nice or practical though. Well, if clause 3(b) had been in effect it would have been their right though, regardless of the practicalities. > I think the reason why the rhel3 pv kernel downloads were removed > was because the kernel was so buggy and it's better if noone uses them. Agreed. Given the presence of supported by Red Hat PV drivers for RHEL3 HVM guests I would strongly recommend using those and not the unsupported kernels that used to be on xenbits. If nothing else then the fact that they haven't been updated for ~4 years (i.e. lack security updates over that period) should be enough to put most people off. Ian. _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel From xen-devel-bounces@lists.xensource.com Tue Sep 27 01:27:51 2011 Return-path: <xen-devel-bounces@lists.xensource.com> Envelope-to: www-data@lists.xensource.com Delivery-date: Tue, 27 Sep 2011 01:27:51 -0700 Received: from localhost ([127.0.0.1] helo=lists.colo.xensource.com) by lists.xensource.com with esmtp (Exim 4.43) id 1R8T15-0000av-OJ; Tue, 27 Sep 2011 01:27:51 -0700 Received: from mail174.messagelabs.com ([85.158.138.51]) by lists.xensource.com with esmtp (Exim 4.43) id 1R8Szq-0000O5-LL for xen-devel@lists.xensource.com; Tue, 27 Sep 2011 01:26:37 -0700 X-Env-Sender: Paul.Durrant@citrix.com X-Msg-Ref: server-15.tower-174.messagelabs.com!1317111991!26544870!1 X-Originating-IP: [62.200.22.115] X-StarScan-Version: 6.4.1; banners=-,-,- X-VirusChecked: Checked Received: (qmail 28544 invoked from network); 27 Sep 2011 08:26:31 -0000 Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115) by server-15.tower-174.messagelabs.com with RC4-SHA encrypted SMTP; 27 Sep 2011 08:26:31 -0000 X-IronPort-AV: E=Sophos;i="4.68,448,1312156800"; d="scan'208";a="8074393" Received: from lonpmailmx01.citrite.net ([10.30.203.162]) by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5; 27 Sep 2011 08:26:30 +0000 Received: from LONPMAILBOX01.citrite.net ([10.30.224.160]) by LONPMAILMX01.citrite.net ([10.30.203.162]) with mapi; Tue, 27 Sep 2011 09:26:31 +0100 From: Paul Durrant <Paul.Durrant@citrix.com> To: =?iso-8859-1?Q?Pasi_K=E4rkk=E4inen?= <pasik@iki.fi>, piyush jain <piyush.today@gmail.com> Date: Tue, 27 Sep 2011 09:26:31 +0100 Subject: RE: [Xen-devel] xen + windbg.. Thread-Topic: [Xen-devel] xen + windbg.. Thread-Index: Acx8gMXjW4jvop2RTXiIWUsGL7bkAgAbYD2A Message-ID: <291EDFCB1E9E224A99088639C4762022B44F50F21A@LONPMAILBOX01.citrite.net> References: <CACyYOe+78Jss5AmBqwLa-d=0+9mSzh0DbpGOx4KQJO=wqOeJVA@mail.gmail.com> <20110926191556.GU12984@reaktio.net> In-Reply-To: <20110926191556.GU12984@reaktio.net> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: James, "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>, Harper <james.harper@bendigoit.com.au> X-BeenThere: xen-devel@lists.xensource.com X-Mailman-Version: 2.1.5 Precedence: list List-Id: Xen developer discussion <xen-devel.lists.xensource.com> List-Unsubscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe> List-Post: <mailto:xen-devel@lists.xensource.com> List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help> List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=subscribe> Sender: xen-devel-bounces@lists.xensource.com Errors-To: xen-devel-bounces@lists.xensource.com It's a long time since I set it up on upstream Xen (as opposed to Citrix Xe= nServer) but what I usually do is set up my xl config to point qemu serial = at a passive open tcp socket (using something like serial=3Dtcp::4000,serve= r,nodelay,nowait). The 'nodelay' is important there, otherwise nagle will s= crew up your debug flow. I then normally use a little socket-to-pipe tool t= hat I have and point windbg at the pipe. You can do similar using HW VSP (h= ttp://www.hw-group.com/products/hw_vsp/index_en.html) and a COM port though= . Paul > -----Original Message----- > From: Pasi K=E4rkk=E4inen [mailto:pasik@iki.fi] > Sent: 26 September 2011 20:16 > To: piyush jain > Cc: xen-devel@lists.xensource.com; James Harper; Paul Durrant > Subject: Re: [Xen-devel] xen + windbg.. >=20 > On Mon, Sep 26, 2011 at 04:39:08PM +0530, piyush jain wrote: > > Hi, > > Is it possible to connect windbg to guest windows 2008 R2, over > xen? > > > > Anyone how did it succesfully? > > > > I tried steps in this links > > > > [1]http://wiki.xensource.com/xenwiki/XenWindowsGplPv > > > > but it's not working for me :( (i modified add in xinited, > instead of > > inetd.conf) > > > > Can any1 update this doc? > > >=20 > Hey, >=20 > Maybe James or Paul can comment.. >=20 > -- Pasi _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel From xen-devel-bounces@lists.xensource.com Tue Sep 27 01:31:39 2011 Return-path: <xen-devel-bounces@lists.xensource.com> Envelope-to: www-data@lists.xensource.com Delivery-date: Tue, 27 Sep 2011 01:31:39 -0700 Received: from localhost ([127.0.0.1] helo=lists.colo.xensource.com) by lists.xensource.com with esmtp (Exim 4.43) id 1R8T4l-00011r-Cs; Tue, 27 Sep 2011 01:31:39 -0700 Received: from mail216.messagelabs.com ([85.158.143.99]) by lists.xensource.com with esmtp (Exim 4.43) id 1R8T40-0000ov-8a; Tue, 27 Sep 2011 01:30:52 -0700 X-Env-Sender: peter@pajamian.dhs.org X-Msg-Ref: server-6.tower-216.messagelabs.com!1317112247!18449219!1 X-Originating-IP: [209.85.213.171] X-StarScan-Version: 6.4.1; banners=-,-,- X-VirusChecked: Checked Received: (qmail 27388 invoked from network); 27 Sep 2011 08:30:49 -0000 Received: from mail-yx0-f171.google.com (HELO mail-yx0-f171.google.com) (209.85.213.171) by server-6.tower-216.messagelabs.com with RC4-SHA encrypted SMTP; 27 Sep 2011 08:30:49 -0000 Received: by yxt3 with SMTP id 3so7988256yxt.30 for <multiple recipients>; Tue, 27 Sep 2011 01:30:47 -0700 (PDT) Received: by 10.236.116.65 with SMTP id f41mr45454507yhh.116.1317112247630; Tue, 27 Sep 2011 01:30:47 -0700 (PDT) Received: from [192.168.1.3] (60-234-254-5.bitstream.orcon.net.nz. [60.234.254.5]) by mx.google.com with ESMTPS id x65sm4858225yhg.18.2011.09.27.01.30.43 (version=TLSv1/SSLv3 cipher=OTHER); Tue, 27 Sep 2011 01:30:45 -0700 (PDT) Message-ID: <4E8189AF.9000003@pajamian.dhs.org> Date: Tue, 27 Sep 2011 21:30:39 +1300 From: Peter Ajamian <peter@pajamian.dhs.org> User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.2.21) Gecko/20110831 Thunderbird/3.1.13 MIME-Version: 1.0 To: Ian Campbell <Ian.Campbell@citrix.com> References: <4E7A356F.7050105@pajamian.dhs.org> <CAG1y0scMBO4VQZwnsLwSSJH3VPJP_NmUNBas68rsc47gRM2WGA@mail.gmail.com> <20110926190441.GS12984@reaktio.net> <4E814893.3010009@pajamian.dhs.org> <20110927063955.GV12984@reaktio.net> <1317109680.13424.50.camel@dagon.hellion.org.uk> In-Reply-To: <1317109680.13424.50.camel@dagon.hellion.org.uk> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>, "xen-users@lists.xensource.com" <xen-users@lists.xensource.com> Subject: [Xen-devel] Re: [Xen-users] old RHEL3 domu kernel download X-BeenThere: xen-devel@lists.xensource.com X-Mailman-Version: 2.1.5 Precedence: list List-Id: Xen developer discussion <xen-devel.lists.xensource.com> List-Unsubscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe> List-Post: <mailto:xen-devel@lists.xensource.com> List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help> List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=subscribe> Sender: xen-devel-bounces@lists.xensource.com Errors-To: xen-devel-bounces@lists.xensource.com On 27/09/11 20:48, Ian Campbell wrote: > I think you need to reread the GPL before making such serious claims. > There is no such requirement that "source code has to remain available". > There are some clauses which sound superficially like such a requirement > but they are time limited and in any case do not apply in every case of > distribution of a work since there are other alternatives allowed by the > license. I didn't mean to make accusations, just to point out a flaw where I saw it. >> No it's not really a GPL violation. When the binary was still available, >> also the sources were available. > > Correct. These binary RPMs were always accompanied by the corresponding > source RPM and therefore clause 3(a) of the GPL is satisfied: > a) Accompany it with the complete corresponding machine-readable > source code, which must be distributed under the terms of Sections > 1 and 2 above on a medium customarily used for software interchange; or, Ahhh, yep, you're right, the sources were always made available when the binary was (right along side the binary) so there is no need to enact any of the other clauses. I stand corrected. >> I think the reason why the rhel3 pv kernel downloads were removed >> was because the kernel was so buggy and it's better if noone uses them. > > Agreed. Given the presence of supported by Red Hat PV drivers for RHEL3 > HVM guests I would strongly recommend using those and not the > unsupported kernels that used to be on xenbits. If nothing else then the > fact that they haven't been updated for ~4 years (i.e. lack security > updates over that period) should be enough to put most people off. Fair enough, I understand that position. Still, it would be nice to have the kernel above available for those who really need it, with the full understanding that it is no longer supported, of course, especially since some people don't have the option to run HVM guests. As I said before I was able to get RHEL3 to run with a newer 2.6 kernel but some things were buggy (modprobe comes to mind, I had to put all the modules I needed in the initrd and force them to load at boot time). I was hoping for a better pv guest alternative to upgrading the kernel to 2.6. Also, when I port a RHEL3 box over to a VM it is almost always a temporary situation where the current need is just to get it off of existing hardware quickly and the future plan to migrate its functions to a more modern distro. Peter _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel From xen-devel-bounces@lists.xensource.com Tue Sep 27 01:52:31 2011 Return-path: <xen-devel-bounces@lists.xensource.com> Envelope-to: www-data@lists.xensource.com Delivery-date: Tue, 27 Sep 2011 01:52:31 -0700 Received: from localhost ([127.0.0.1] helo=lists.colo.xensource.com) by lists.xensource.com with esmtp (Exim 4.43) id 1R8TOx-0002dw-3y; Tue, 27 Sep 2011 01:52:31 -0700 Received: from mail182.messagelabs.com ([85.158.139.83]) by lists.xensource.com with esmtp (Exim 4.43) id 1R8TOO-0002Rg-UO; Tue, 27 Sep 2011 01:51:57 -0700 X-Env-Sender: Ian.Campbell@eu.citrix.com X-Msg-Ref: server-4.tower-182.messagelabs.com!1317113513!19879084!1 X-Originating-IP: [62.200.22.115] X-StarScan-Version: 6.4.1; banners=-,-,- X-VirusChecked: Checked Received: (qmail 26572 invoked from network); 27 Sep 2011 08:51:53 -0000 Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115) by server-4.tower-182.messagelabs.com with RC4-SHA encrypted SMTP; 27 Sep 2011 08:51:53 -0000 X-IronPort-AV: E=Sophos;i="4.68,448,1312156800"; d="scan'208";a="8075183" Received: from lonpmailmx01.citrite.net ([10.30.203.162]) by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5; 27 Sep 2011 08:51:53 +0000 Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net (10.30.203.162) with Microsoft SMTP Server id 8.3.137.0; Tue, 27 Sep 2011 09:51:53 +0100 Subject: Re: [Xen-devel] Re: [Xen-users] old RHEL3 domu kernel download From: Ian Campbell <Ian.Campbell@eu.citrix.com> To: Peter Ajamian <peter@pajamian.dhs.org> Date: Tue, 27 Sep 2011 09:51:52 +0100 In-Reply-To: <4E8189AF.9000003@pajamian.dhs.org> References: <4E7A356F.7050105@pajamian.dhs.org> <CAG1y0scMBO4VQZwnsLwSSJH3VPJP_NmUNBas68rsc47gRM2WGA@mail.gmail.com> <20110926190441.GS12984@reaktio.net> <4E814893.3010009@pajamian.dhs.org> <20110927063955.GV12984@reaktio.net> <1317109680.13424.50.camel@dagon.hellion.org.uk> <4E8189AF.9000003@pajamian.dhs.org> Organization: Citrix Systems, Inc. Content-Type: text/plain; charset="UTF-8" X-Mailer: Evolution 3.0.3- Content-Transfer-Encoding: 7bit Message-ID: <1317113512.26672.21.camel@zakaz.uk.xensource.com> MIME-Version: 1.0 Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>, "xen-users@lists.xensource.com" <xen-users@lists.xensource.com> X-BeenThere: xen-devel@lists.xensource.com X-Mailman-Version: 2.1.5 Precedence: list List-Id: Xen developer discussion <xen-devel.lists.xensource.com> List-Unsubscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe> List-Post: <mailto:xen-devel@lists.xensource.com> List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help> List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=subscribe> Sender: xen-devel-bounces@lists.xensource.com Errors-To: xen-devel-bounces@lists.xensource.com On Tue, 2011-09-27 at 09:30 +0100, Peter Ajamian wrote: > > > Agreed. Given the presence of supported by Red Hat PV drivers for > RHEL3 > > HVM guests I would strongly recommend using those and not the > > unsupported kernels that used to be on xenbits. If nothing else then > the > > fact that they haven't been updated for ~4 years (i.e. lack security > > updates over that period) should be enough to put most people off. > > Fair enough, I understand that position. Still, it would be nice to > have the kernel above available for those who really need it, with the > full understanding that it is no longer supported, I've looked around internally for the RPMs which were previously published on xen.org but I'm afraid I cannot find them anywhere. If you really feel you cannot use the supported stuff from Red Hat then some older XenServer versions also contained similar RPMs, which still appear to be available: http://updates.vmd.citrix.com/XenServer/5.5.0/rhel3x Obviously these are completely unsupported in this context, either by xen.org or the XenServer folks. These appear to have a few more fixes (over the same rhel3x baseline) than the ones previously on xen.org but I guess that is a good thing. Ian. _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel From xen-devel-bounces@lists.xensource.com Tue Sep 27 02:11:16 2011 Return-path: <xen-devel-bounces@lists.xensource.com> Envelope-to: www-data@lists.xensource.com Delivery-date: Tue, 27 Sep 2011 02:11:16 -0700 Received: from localhost ([127.0.0.1] helo=lists.colo.xensource.com) by lists.xensource.com with esmtp (Exim 4.43) id 1R8Th5-0003xw-57; Tue, 27 Sep 2011 02:11:15 -0700 Received: from mail182.messagelabs.com ([85.158.139.83]) by lists.xensource.com with esmtp (Exim 4.43) id 1R8Tfp-0003kw-NE for xen-devel@lists.xensource.com; Tue, 27 Sep 2011 02:09:58 -0700 X-Env-Sender: JBeulich@suse.com X-Msg-Ref: server-13.tower-182.messagelabs.com!1317114594!19728393!1 X-Originating-IP: [130.57.49.28] X-StarScan-Version: 6.4.1; banners=-,-,- X-VirusChecked: Checked Received: (qmail 6751 invoked from network); 27 Sep 2011 09:09:54 -0000 Received: from nat28.tlf.novell.com (HELO nat28.tlf.novell.com) (130.57.49.28) by server-13.tower-182.messagelabs.com with DHE-RSA-AES256-SHA encrypted SMTP; 27 Sep 2011 09:09:54 -0000 Received: from EMEA1-MTA by nat28.tlf.novell.com with Novell_GroupWise; Tue, 27 Sep 2011 10:09:53 +0100 Message-Id: <4E81AEFE0200007800057F72@nat28.tlf.novell.com> X-Mailer: Novell GroupWise Internet Agent 8.0.1 Date: Tue, 27 Sep 2011 10:09:50 +0100 From: "Jan Beulich" <JBeulich@suse.com> To: "MaoXiaoyun" <tinnycloud@hotmail.com> Subject: [Xen-devel] RE: [patch 1/1] ext4-fix-dirty-extent-when-origin-leaf-extent-reac.patch References: <BLU157-W499E698F650F554E645F9DDA1C0@phx.gbl>, <20110906145347.GA4133@dumpdata.com>, <BLU157-W4106FA4CF4EBA78C63FDA0DA1C0@phx.gbl>, <4E666C86.5090707@goop.org>, <BLU157-W323C330706CB8D7E976BC3DA1F0@phx.gbl>, <BLU157-W7DABA5FE01C50C29B1A64DA060@phx.gbl>, <BLU157-W25EB1EAC24CC11FA14859ADAF20@phx.gbl>, <20110926142808.GG4102@phenom.oracle.com> <BLU157-W54420DD5C05CB38610F67DAF00@phx.gbl> In-Reply-To: <BLU157-W54420DD5C05CB38610F67DAF00@phx.gbl> Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: quoted-printable Content-Disposition: inline Cc: jeremy@goop.org, xen devel <xen-devel@lists.xensource.com>, jack@suse.cz, konrad.wilk@oracle.com, tytso@mit.edu, linux-ext4@vger.kernel.org X-BeenThere: xen-devel@lists.xensource.com X-Mailman-Version: 2.1.5 Precedence: list List-Id: Xen developer discussion <xen-devel.lists.xensource.com> List-Unsubscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe> List-Post: <mailto:xen-devel@lists.xensource.com> List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help> List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=subscribe> Sender: xen-devel-bounces@lists.xensource.com Errors-To: xen-devel-bounces@lists.xensource.com >>> On 27.09.11 at 04:22, MaoXiaoyun <tinnycloud@hotmail.com> wrote: >=20 >=20 > ---------------------------------------- >> Date: Mon, 26 Sep 2011 10:28:08 -0400 >> From: konrad.wilk@oracle.com=20 >> To: tinnycloud@hotmail.com=20 >> CC: linux-ext4@vger.kernel.org; xen-devel@lists.xensource.com; = tytso@mit.edu;=20 > jack@suse.cz=20 >> Subject: Re: [patch 1/1] ext4-fix-dirty-extent-when-origin-leaf-extent-r= eac.patch >> >> On Sun, Sep 25, 2011 at 04:45:39PM +0800, MaoXiaoyun wrote: >> > >> > >> > Hi: >> > >> > We met an ext4 BUG_ON in extents.c:1716 which crash kernel flush = thread,=20 > and result in disk unvailiable. >> > >> > BUG details refer to:=20 > http://www.gossamer-threads.com/lists/xen/devel/217091?do=3Dpost_view_thr= eaded=20 >> > >> > Attached is the fix, verified in our env. >> >> So.. you are asking for this upstream git commit to be back-ported to = 2.6.32,=20 > right? >> > =20 > The patch is for 2.6.39. It can be patched on 2.6.32 too. > Thanks. So why don't you suggest applying this to the stable tree maintainers instead? xen-devel really isn't the right forum for this sort of bug = fixes, particularly when the underlying kernel.org tree is still being maintained.= Jan >> > >> > Without this patch, more than 3 servers hit BUG_ON in our hundreds = of=20 > servers every day. >> > >> > >> > many thanks. >> >> =20 >=20 > _______________________________________________ > Xen-devel mailing list > Xen-devel@lists.xensource.com=20 > http://lists.xensource.com/xen-devel=20 _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel From xen-devel-bounces@lists.xensource.com Tue Sep 27 02:19:30 2011 Return-path: <xen-devel-bounces@lists.xensource.com> Envelope-to: www-data@lists.xensource.com Delivery-date: Tue, 27 Sep 2011 02:19:30 -0700 Received: from localhost ([127.0.0.1] helo=lists.colo.xensource.com) by lists.xensource.com with esmtp (Exim 4.43) id 1R8Tp4-0004RR-M4; Tue, 27 Sep 2011 02:19:30 -0700 Received: from mail21.messagelabs.com ([85.158.143.35]) by lists.xensource.com with smtp (Exim 4.43) id 1R8ToM-0004Es-4q for xen-devel@lists.xensource.com; Tue, 27 Sep 2011 02:18:46 -0700 X-Env-Sender: Jes.Sorensen@redhat.com X-Msg-Ref: server-11.tower-21.messagelabs.com!1317115104!44128214!1 X-Originating-IP: [209.132.183.28] X-StarScan-Version: 6.4.1; banners=-,-,- X-VirusChecked: Checked Received: (qmail 13316 invoked from network); 27 Sep 2011 09:18:24 -0000 Received: from mx1.redhat.com (HELO mx1.redhat.com) (209.132.183.28) by server-11.tower-21.messagelabs.com with SMTP; 27 Sep 2011 09:18:24 -0000 Received: from int-mx09.intmail.prod.int.phx2.redhat.com (int-mx09.intmail.prod.int.phx2.redhat.com [10.5.11.22]) by mx1.redhat.com (8.14.4/8.14.4) with ESMTP id p8R9IG0h010756 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Tue, 27 Sep 2011 05:18:16 -0400 Received: from [10.36.116.25] (ovpn-116-25.ams2.redhat.com [10.36.116.25]) by int-mx09.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP id p8R9I7Nc010991; Tue, 27 Sep 2011 05:18:08 -0400 Message-ID: <4E8194CF.8050601@redhat.com> Date: Tue, 27 Sep 2011 11:18:07 +0200 From: Jes Sorensen <Jes.Sorensen@redhat.com> User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.2.22) Gecko/20110906 Fedora/3.1.14-1.fc14 Thunderbird/3.1.14 MIME-Version: 1.0 To: QEMU Developers <qemu-devel@nongnu.org>, xen-devel@lists.xensource.com, KVM General <kvm@vger.kernel.org>, virtualization@lists.linux-foundation.org, "libvir-list@redhat.com" <libvir-list@redhat.com>, LKML <linux-kernel@vger.kernel.org> References: <4DA84E5D.6040300@redhat.com> In-Reply-To: <4DA84E5D.6040300@redhat.com> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Scanned-By: MIMEDefang 2.68 on 10.5.11.22 Cc: =?ISO-8859-1?Q?ez?= <fernando.vazquez@gmail.com>, Ian Campbell <Ian.Campbell@citrix.com>, =?ISO-8859-1?Q?Fernando_V=E1zqu?=, yamahata@valinux.co.jp, Alex Williamson <alex.williamson@redhat.com>, Anthony.Perard@citrix.com, lpc-planning@linuxplumbersconf.org Subject: [Xen-devel] Re: LPC2011 Virtualization Micro Conf X-BeenThere: xen-devel@lists.xensource.com X-Mailman-Version: 2.1.5 Precedence: list List-Id: Xen developer discussion <xen-devel.lists.xensource.com> List-Unsubscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe> List-Post: <mailto:xen-devel@lists.xensource.com> List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help> List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=subscribe> Sender: xen-devel-bounces@lists.xensource.com Errors-To: xen-devel-bounces@lists.xensource.com Hi, For those who are interested, I have posted the notes from the 2011 Linux Plumbers Virtualization micro conference here: http://wiki.linuxplumbersconf.org/2011:virtualization Slides can be found by clicking on the presentation and going onto the Plumbers abstracts. Cheers, Jes _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel From xen-devel-bounces@lists.xensource.com Tue Sep 27 02:35:51 2011 Return-path: <xen-devel-bounces@lists.xensource.com> Envelope-to: www-data@lists.xensource.com Delivery-date: Tue, 27 Sep 2011 02:35:51 -0700 Received: from localhost ([127.0.0.1] helo=lists.colo.xensource.com) by lists.xensource.com with esmtp (Exim 4.43) id 1R8U4s-00057w-E1; Tue, 27 Sep 2011 02:35:50 -0700 Received: from mail27.messagelabs.com ([193.109.254.147]) by lists.xensource.com with esmtp (Exim 4.43) id 1R8U41-0004tn-Ub for xen-devel@lists.xensource.com; Tue, 27 Sep 2011 02:34:58 -0700 X-Env-Sender: Stephan.Diestelhorst@amd.com X-Msg-Ref: server-13.tower-27.messagelabs.com!1317116082!41696688!1 X-Originating-IP: [213.199.154.140] X-StarScan-Version: 6.4.1; banners=-,-,- X-VirusChecked: Checked Received: (qmail 27843 invoked from network); 27 Sep 2011 09:34:42 -0000 Received: from db3ehsobe002.messaging.microsoft.com (HELO DB3EHSOBE002.bigfish.com) (213.199.154.140) by server-13.tower-27.messagelabs.com with AES128-SHA encrypted SMTP; 27 Sep 2011 09:34:42 -0000 Received: from mail54-db3-R.bigfish.com (10.3.81.245) by DB3EHSOBE002.bigfish.com (10.3.84.22) with Microsoft SMTP Server id 14.1.225.22; Tue, 27 Sep 2011 09:34:54 +0000 Received: from mail54-db3 (localhost.localdomain [127.0.0.1]) by mail54-db3-R.bigfish.com (Postfix) with ESMTP id AFC7DA80427; Tue, 27 Sep 2011 09:34:54 +0000 (UTC) X-SpamScore: -13 X-BigFish: VPS-13(zzdf9M1432N98dKzz1202hzz8275bhz32i668h839h93fh61h) X-Spam-TCS-SCL: 0:0 X-Forefront-Antispam-Report: CIP:163.181.249.108; KIP:(null); UIP:(null); IPVD:NLI; H:ausb3twp01.amd.com; RD:none; EFVD:NLI Received: from mail54-db3 (localhost.localdomain [127.0.0.1]) by mail54-db3 (MessageSwitch) id 1317116094466713_11402; Tue, 27 Sep 2011 09:34:54 +0000 (UTC) Received: from DB3EHSMHS007.bigfish.com (unknown [10.3.81.254]) by mail54-db3.bigfish.com (Postfix) with ESMTP id 6192A1B88054; Tue, 27 Sep 2011 09:34:54 +0000 (UTC) Received: from ausb3twp01.amd.com (163.181.249.108) by DB3EHSMHS007.bigfish.com (10.3.87.107) with Microsoft SMTP Server id 14.1.225.22; Tue, 27 Sep 2011 09:34:53 +0000 X-WSS-ID: 0LS6D9Y-01-2UL-02 X-M-MSG: Received: from sausexedgep01.amd.com (sausexedgep01-ext.amd.com [163.181.249.72]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by ausb3twp01.amd.com (Axway MailGate 3.8.1) with ESMTP id 2F9CA1028362; Tue, 27 Sep 2011 04:34:45 -0500 (CDT) Received: from sausexhtp02.amd.com (163.181.3.152) by sausexedgep01.amd.com (163.181.36.54) with Microsoft SMTP Server (TLS) id 8.3.106.1; Tue, 27 Sep 2011 04:34:56 -0500 Received: from storexhtp02.amd.com (172.24.4.4) by sausexhtp02.amd.com (163.181.3.152) with Microsoft SMTP Server (TLS) id 8.3.83.0; Tue, 27 Sep 2011 04:34:49 -0500 Received: from gwo.osrc.amd.com (165.204.16.204) by storexhtp02.amd.com (172.24.4.4) with Microsoft SMTP Server id 8.3.83.0; Tue, 27 Sep 2011 05:34:47 -0400 Received: from chlor.localnet (chlor.osrc.amd.com [165.204.15.145]) by gwo.osrc.amd.com (Postfix) with ESMTP id 935C449C266; Tue, 27 Sep 2011 10:34:46 +0100 (BST) From: Stephan Diestelhorst <stephan.diestelhorst@amd.com> To: <xen-devel@lists.xensource.com> Subject: Re: [Xen-devel] [PATCH 00/10] [PATCH RFC V2] Paravirtualized ticketlocks Date: Tue, 27 Sep 2011 11:34:45 +0200 Message-ID: <3300108.XQUp9Wrktc@chlor> Organization: AMD OSRC User-Agent: KMail/4.7.0 (Linux/2.6.38-11-generic; KDE/4.7.0; x86_64; ; ) In-Reply-To: <cover.1315878463.git.jeremy.fitzhardinge@citrix.com> References: <cover.1315878463.git.jeremy.fitzhardinge@citrix.com> MIME-Version: 1.0 Content-Transfer-Encoding: 7Bit Content-Type: text/plain; charset="utf-8" X-OriginatorOrg: amd.com Cc: Jeremy Fitzhardinge <jeremy@goop.org>, maintainers <x86@kernel.org>, Nick Piggin <npiggin@kernel.dk>, KVM <kvm@vger.kernel.org>, Peter Zijlstra <peterz@infradead.org>, Marcelo Tosatti <mtosatti@redhat.com>, Linux Kernel Mailing List <linux-kernel@vger.kernel.org>, Ingo, Andi Kleen <andi@firstfloor.org>, Avi Kivity <avi@redhat.com>, Jeremy Fitzhardinge <jeremy.fitzhardinge@citrix.com>, "H. Peter Anvin" <hpa@zytor.com>, the, Linus Torvalds <torvalds@linux-foundation.org>, Molnar <mingo@elte.hu> X-BeenThere: xen-devel@lists.xensource.com X-Mailman-Version: 2.1.5 Precedence: list List-Id: Xen developer discussion <xen-devel.lists.xensource.com> List-Unsubscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe> List-Post: <mailto:xen-devel@lists.xensource.com> List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help> List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=subscribe> Sender: xen-devel-bounces@lists.xensource.com Errors-To: xen-devel-bounces@lists.xensource.com On Wednesday 14 September 2011, 17:31:32 Jeremy Fitzhardinge wrote: > This series replaces the existing paravirtualized spinlock mechanism > with a paravirtualized ticketlock mechanism. [...] > The unlock code is very straightforward: > prev = *lock; > __ticket_unlock_release(lock); > if (unlikely(__ticket_in_slowpath(lock))) > __ticket_unlock_slowpath(lock, prev); > > which generates: > push %rbp > mov %rsp,%rbp > > movzwl (%rdi),%esi > addb $0x2,(%rdi) > movzwl (%rdi),%eax > testb $0x1,%ah > jne 1f > > pop %rbp > retq > > ### SLOWPATH START > 1: movzwl (%rdi),%edx > movzbl %dh,%ecx > mov %edx,%eax > and $-2,%ecx # clear TICKET_SLOWPATH_FLAG > mov %cl,%dh > cmp %dl,%cl # test to see if lock is uncontended > je 3f > > 2: movzbl %dl,%esi > callq *__ticket_unlock_kick # kick anyone waiting > pop %rbp > retq > > 3: lock cmpxchg %dx,(%rdi) # use cmpxchg to safely write back flag > jmp 2b > ### SLOWPATH END [...] > Thoughts? Comments? Suggestions? You have a nasty data race in your code that can cause a losing acquirer to sleep forever, because its setting the TICKET_SLOWPATH flag can race with the lock holder releasing the lock. I used the code for the slow path from the GIT repo. Let me try to point out an interleaving: Lock is held by one thread, contains 0x0200. _Lock holder_ _Acquirer_ mov $0x200,%eax lock xadd %ax,(%rdi) // ax:= 0x0200, lock:= 0x0400 ... // this guy spins for a while, reading // the lock ... //trying to free the lock movzwl (%rdi),%esi (esi:=0x0400) addb $0x2,(%rdi) (LOCAL copy of lock is now: 0x0402) movzwl (%rdi),%eax (local forwarding from previous store: eax := 0x0402) testb $0x1,%ah (no wakeup of anybody) jne 1f callq *__ticket_lock_spinning ... // __ticket_enter_slowpath(lock) lock or (%rdi), $0x100 // (global view of lock := 0x0500) ... ACCESS_ONCE(lock->tickets.head) == want // (reads 0x00) ... xen_poll_irq(irq); // goes to sleep ... [addb $0x2,(%rdi)] // (becomes globally visible only now! global view of lock := 0x0502) ... Your code is reusing the (just about) safe version of unlocking a spinlock without understanding the effect that close has on later memory ordering. It may work on CPUs that cannot do narrow -> wide store to load forwarding and have to make the addb store visible globally. This is an implementation artifact of specific uarches, and you mustn't rely on it, since our specified memory model allows looser behaviour. Since you want to get that addb out to global memory before the second read, either use a LOCK prefix for it, add an MFENCE between addb and movzwl, or use a LOCKed instruction that will have a fencing effect (e.g., to top-of-stack)between addb and movzwl. Stephan -- Stephan Diestelhorst, AMD Operating System Research Center stephan.diestelhorst@amd.com Tel. +49 (0)351 448 356 719 Advanced Micro Devices GmbH Einsteinring 24 85609 Aschheim Germany Geschaeftsfuehrer: Alberto Bozzo Sitz: Dornach, Gemeinde Aschheim, Landkreis Muenchen Registergericht Muenchen, HRB Nr. 43632, WEEE-Reg-Nr: DE 12919551 _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel From xen-devel-bounces@lists.xensource.com Tue Sep 27 02:52:27 2011 Return-path: <xen-devel-bounces@lists.xensource.com> Envelope-to: www-data@lists.xensource.com Delivery-date: Tue, 27 Sep 2011 02:52:27 -0700 Received: from localhost ([127.0.0.1] helo=lists.colo.xensource.com) by lists.xensource.com with esmtp (Exim 4.43) id 1R8UKx-0005vx-2n; Tue, 27 Sep 2011 02:52:27 -0700 Received: from mail27.messagelabs.com ([193.109.254.147]) by lists.xensource.com with esmtp (Exim 4.43) id 1R8UKI-0005jX-Uc for xen-devel@lists.xensource.com; Tue, 27 Sep 2011 02:51:47 -0700 X-Env-Sender: dietmar.hahn@ts.fujitsu.com X-Msg-Ref: server-6.tower-27.messagelabs.com!1317117083!50633640!1 X-Originating-IP: [80.70.172.51] X-StarScan-Version: 6.4.1; banners=-,-,- X-VirusChecked: Checked Received: (qmail 20180 invoked from network); 27 Sep 2011 09:51:23 -0000 Received: from dgate20.ts.fujitsu.com (HELO dgate20.ts.fujitsu.com) (80.70.172.51) by server-6.tower-27.messagelabs.com with RC4-SHA encrypted SMTP; 27 Sep 2011 09:51:23 -0000 DomainKey-Signature: s=s1536a; d=ts.fujitsu.com; c=nofws; q=dns; h=X-SBRSScore:X-IronPort-AV:Received:X-IronPort-AV: Received:Received:From:To:Subject:Date:User-Agent: MIME-Version:Content-Type:Content-Transfer-Encoding: Message-Id; b=KIu1JBOr/mGvwYhqRYpjndAq2L37R8wQSGFN3sJOwjv78Ju93jzZMPoI OOI4wSfxZEHxxGmWDw3NGf3P4HmeAFtpNWv+UwITw1+beUPzYKIqpwJcF 3AxJuckiiKPgPR4bCb3W/8uafwaztEait22xpxFjP0SUkwJ9lst/WeACg z0F+YmRoSn7fC3hc1eE3kpf8HIXx6QdBO7NaKfxz8+S8Qp6aw4UmoO5J6 ZUPREcoUpXBMFUhUbh122Z0/PB5b2; DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=ts.fujitsu.com; i=dietmar.hahn@ts.fujitsu.com; q=dns/txt; s=s1536b; t=1317117104; x=1348653104; h=from:to:subject:date:mime-version: content-transfer-encoding:message-id; bh=/RPMuGIOvh24fdEz5uwIGL+nyO0Jz+K9mAh6sTPcaKU=; b=Boybj4BzxZ3k3TNV66TPAz4U4N2TaVEaXqFwTR43ix9ZnZvqZ7ippF0D GEw6yCTInLpf7xTEPeGzNPuWW0hBgGo9UaRmXWHGb+fRCGDYGujZx+tv/ EbUuDmSXDzjTqON+XoFzZ9QBjjJqKbWpL99Z8feGh7ukrKtb4VrCKr2EW M+y0MeDwTzPy8AXZedPUgJZU6wY5Lv6pfMpC9BLao3sUVkQnjsyLmyDaf Yf6IFiZkyCZtyrhNNieRcqao5/pcH; X-SBRSScore: None X-IronPort-AV: E=Sophos;i="4.68,448,1312149600"; d="scan'208";a="75334355" Received: from abgdgate40u.abg.fsc.net ([172.25.138.90]) by dgate20u.abg.fsc.net with ESMTP; 27 Sep 2011 11:51:43 +0200 X-IronPort-AV: E=Sophos;i="4.68,448,1312149600"; d="scan'208";a="120848077" Received: from sanpedro.mch.fsc.net ([172.17.20.6]) by abgdgate40u.abg.fsc.net with ESMTP; 27 Sep 2011 11:51:43 +0200 Received: from amur.localnet (amur.mch.fsc.net [172.25.53.126]) by sanpedro.mch.fsc.net (Postfix) with SMTP id 11DD9959BC5 for <xen-devel@lists.xensource.com>; Tue, 27 Sep 2011 11:51:43 +0200 (CEST) From: Dietmar Hahn <dietmar.hahn@ts.fujitsu.com> To: xen devel <xen-devel@lists.xensource.com> Date: Tue, 27 Sep 2011 11:51:42 +0200 User-Agent: KMail/1.13.6 (Linux/2.6.37.6-0.7-xen; KDE/4.6.0; x86_64; ; ) MIME-Version: 1.0 Content-Type: Text/Plain; charset="iso-8859-15" Content-Transfer-Encoding: 7bit Message-Id: <201109271151.42552.dietmar.hahn@ts.fujitsu.com> Subject: [Xen-devel] Architectural question: How to put BTS and PEBS in Xen X-BeenThere: xen-devel@lists.xensource.com X-Mailman-Version: 2.1.5 Precedence: list List-Id: Xen developer discussion <xen-devel.lists.xensource.com> List-Unsubscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe> List-Post: <mailto:xen-devel@lists.xensource.com> List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help> List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=subscribe> Sender: xen-devel-bounces@lists.xensource.com Errors-To: xen-devel-bounces@lists.xensource.com Hi list, I'm on the way to coding the virtualisation of BTS (Branch Trace Store) and later PEBS support for Intel CPU's in Xen. As some aspects overlap with the PMU (Performance Management Unit) I used the existing infrastructure of the VPMU stuff to do some coding and tests. But currently this infrastructure is only switched on with a 'vpmu' boot flag in the hypervisor. As reminder this flag was introduced because of an inexplicable behaviour of the Nehalem CPUs while using the performance counters which could lead to an endless interrupt loop (see check_pmc_quirk()). As currently no one else than we seem to use/need this feature for simplicity I would move the BTS code complete to the VPMU environment and therfore it would only be usable when using the 'vpmu' flag on boot. Any advices would be welcome! Thanks. Dietmar. -- Company details: http://ts.fujitsu.com/imprint.html _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel From xen-devel-bounces@lists.xensource.com Tue Sep 27 04:12:18 2011 Return-path: <xen-devel-bounces@lists.xensource.com> Envelope-to: www-data@lists.xensource.com Delivery-date: Tue, 27 Sep 2011 04:12:18 -0700 Received: from localhost ([127.0.0.1] helo=lists.colo.xensource.com) by lists.xensource.com with esmtp (Exim 4.43) id 1R8VaE-0008EA-4v; Tue, 27 Sep 2011 04:12:18 -0700 Received: from mail27.messagelabs.com ([193.109.254.147]) by lists.xensource.com with esmtp (Exim 4.43) id 1R8VXj-0007yi-KI for xen-devel@lists.xensource.com; Tue, 27 Sep 2011 04:11:06 -0700 X-Env-Sender: evil.dani@gmail.com X-Msg-Ref: server-5.tower-27.messagelabs.com!1317121757!46547329!1 X-Originating-IP: [209.85.161.43] X-StarScan-Version: 6.4.1; banners=-,-,- X-VirusChecked: Checked Received: (qmail 29790 invoked from network); 27 Sep 2011 11:09:17 -0000 Received: from mail-fx0-f43.google.com (HELO mail-fx0-f43.google.com) (209.85.161.43) by server-5.tower-27.messagelabs.com with RC4-SHA encrypted SMTP; 27 Sep 2011 11:09:17 -0000 Received: by fxh19 with SMTP id 19so8976243fxh.30 for <xen-devel@lists.xensource.com>; Tue, 27 Sep 2011 04:09:37 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:date:message-id:subject:from:to:content-type :content-transfer-encoding; bh=TluDyobMprSW4kwyfWD6PkfjimTA0gQW8ojCzcP+Cjo=; b=u9CNni6AKbuK1Vg5Dc1lW6Hit4GRs+UHCRkoFIf5MXd+KHnsQaOYXj9gsLYgDwwWkC tp7p/buok5A0N7/Thi69+mKvBIjspBAHDyPh+sTrw2yiSCvA/wW3ganQO8u4bIbIrTUu ZzdHmWUG/l87yHYtevZ5MYvUeHZIFk7tP7OU0= MIME-Version: 1.0 Received: by 10.223.5.152 with SMTP id 24mr1302630fav.113.1317121777316; Tue, 27 Sep 2011 04:09:37 -0700 (PDT) Received: by 10.223.97.9 with HTTP; Tue, 27 Sep 2011 04:09:37 -0700 (PDT) Date: Tue, 27 Sep 2011 20:09:37 +0900 Message-ID: <CAP2B85-QBczrKLWSKaRVBkao3=6PB=wnYvuKmoXYqGDbZFnTXA@mail.gmail.com> From: Daniel Castro <evil.dani@gmail.com> To: xen-devel@lists.xensource.com Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Subject: [Xen-devel] Debug event_channel.c X-BeenThere: xen-devel@lists.xensource.com X-Mailman-Version: 2.1.5 Precedence: list List-Id: Xen developer discussion <xen-devel.lists.xensource.com> List-Unsubscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe> List-Post: <mailto:xen-devel@lists.xensource.com> List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help> List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=subscribe> Sender: xen-devel-bounces@lists.xensource.com Errors-To: xen-devel-bounces@lists.xensource.com Hello All, I am trying to debug event_channel.c for this I have filled the functions with gdprintk(XENLOG_WARNING, "..."); yet the messages are not displayed on dmesg or /var/log/xen. Where could they be printed? or should I use a different function? In grub I have loglvl=3Dall to print all messages... Thanks for the answer, Daniel --=20 +-=3D=3D=3D=3D=3D---------------------------+ | +---------------------------------+ | This space intentionally blank for notetaking. | |=A0=A0 | Daniel Castro,=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 | | |=A0=A0 | Consultant/Programmer.| | |=A0=A0 | U Andes=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0=A0 | +-------------------------------------+ _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel From xen-devel-bounces@lists.xensource.com Tue Sep 27 04:23:50 2011 Return-path: <xen-devel-bounces@lists.xensource.com> Envelope-to: www-data@lists.xensource.com Delivery-date: Tue, 27 Sep 2011 04:23:50 -0700 Received: from localhost ([127.0.0.1] helo=lists.colo.xensource.com) by lists.xensource.com with esmtp (Exim 4.43) id 1R8VlO-0000JH-9U; Tue, 27 Sep 2011 04:23:50 -0700 Received: from mail27.messagelabs.com ([193.109.254.147]) by lists.xensource.com with esmtp (Exim 4.43) id 1R8Vkd-00007O-S2 for xen-devel@lists.xensource.com; Tue, 27 Sep 2011 04:23:04 -0700 X-Env-Sender: peter@pajamian.dhs.org X-Msg-Ref: server-4.tower-27.messagelabs.com!1317122558!41940650!1 X-Originating-IP: [219.88.242.56] X-StarScan-Version: 6.4.1; banners=-,-,- X-VirusChecked: Checked Received: (qmail 31550 invoked from network); 27 Sep 2011 11:22:41 -0000 Received: from mx6.orcon.net.nz (HELO mx6.orcon.net.nz) (219.88.242.56) by server-4.tower-27.messagelabs.com with AES256-SHA encrypted SMTP; 27 Sep 2011 11:22:41 -0000 Received: from Debian-exim by mx6.orcon.net.nz with local (Exim 4.69) (envelope-from <peter@pajamian.dhs.org>) id 1R8VkV-0007qQ-OM for xen-devel@lists.xensource.com; Wed, 28 Sep 2011 00:22:55 +1300 Received: from 60-234-254-5.bitstream.orcon.net.nz ([60.234.254.5] helo=[192.168.1.3]) by mx6.orcon.net.nz with esmtpsa (TLS1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.69) (envelope-from <peter@pajamian.dhs.org>) id 1R8VkU-0007pQ-Sa; Wed, 28 Sep 2011 00:22:55 +1300 Message-ID: <4E81B20D.9080104@pajamian.dhs.org> Date: Wed, 28 Sep 2011 00:22:53 +1300 From: Peter <peter@pajamian.dhs.org> User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.2.21) Gecko/20110831 Thunderbird/3.1.13 MIME-Version: 1.0 To: Ian Campbell <Ian.Campbell@eu.citrix.com> Subject: Re: [Xen-devel] Re: [Xen-users] old RHEL3 domu kernel download References: <4E7A356F.7050105@pajamian.dhs.org> <CAG1y0scMBO4VQZwnsLwSSJH3VPJP_NmUNBas68rsc47gRM2WGA@mail.gmail.com> <20110926190441.GS12984@reaktio.net> <4E814893.3010009@pajamian.dhs.org> <20110927063955.GV12984@reaktio.net> <1317109680.13424.50.camel@dagon.hellion.org.uk> <4E8189AF.9000003@pajamian.dhs.org> <1317113512.26672.21.camel@zakaz.uk.xensource.com> In-Reply-To: <1317113512.26672.21.camel@zakaz.uk.xensource.com> X-Enigmail-Version: 1.1.2 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-DSPAM-Check: by mx6.orcon.net.nz on Wed, 28 Sep 2011 00:22:55 +1300 X-DSPAM-Result: Innocent X-DSPAM-Processed: Wed Sep 28 00:22:55 2011 X-DSPAM-Confidence: 0.5942 X-DSPAM-Probability: 0.0000 Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>, "xen-users@lists.xensource.com" <xen-users@lists.xensource.com> X-BeenThere: xen-devel@lists.xensource.com X-Mailman-Version: 2.1.5 Precedence: list List-Id: Xen developer discussion <xen-devel.lists.xensource.com> List-Unsubscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe> List-Post: <mailto:xen-devel@lists.xensource.com> List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help> List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=subscribe> Sender: xen-devel-bounces@lists.xensource.com Errors-To: xen-devel-bounces@lists.xensource.com On 27/09/11 21:51, Ian Campbell wrote: > On Tue, 2011-09-27 at 09:30 +0100, Peter Ajamian wrote: >> >>> Agreed. Given the presence of supported by Red Hat PV drivers for >> RHEL3 >>> HVM guests I would strongly recommend using those and not the >>> unsupported kernels that used to be on xenbits. If nothing else then >> the >>> fact that they haven't been updated for ~4 years (i.e. lack security >>> updates over that period) should be enough to put most people off. >> >> Fair enough, I understand that position. Still, it would be nice to >> have the kernel above available for those who really need it, with the >> full understanding that it is no longer supported, > > I've looked around internally for the RPMs which were previously > published on xen.org but I'm afraid I cannot find them anywhere. > > If you really feel you cannot use the supported stuff from Red Hat then > some older XenServer versions also contained similar RPMs, which still > appear to be available: > http://updates.vmd.citrix.com/XenServer/5.5.0/rhel3x Thanks. I will try to go the supported route, but it's good to know that this option is there, and I think it's a better one than trying to make a 2.6 kernel work. > Obviously these are completely unsupported in this context, either by > xen.org or the XenServer folks. These appear to have a few more fixes > (over the same rhel3x baseline) than the ones previously on xen.org but > I guess that is a good thing. Right, well as I said before, I'm not too concerned with supported, just to get something that will work temporarily. This looks like a good option if the HVM route won't work, imo. Thanks, Peter _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel From xen-devel-bounces@lists.xensource.com Tue Sep 27 04:33:54 2011 Return-path: <xen-devel-bounces@lists.xensource.com> Envelope-to: www-data@lists.xensource.com Delivery-date: Tue, 27 Sep 2011 04:33:54 -0700 Received: from localhost ([127.0.0.1] helo=lists.colo.xensource.com) by lists.xensource.com with esmtp (Exim 4.43) id 1R8Vv7-0001Tp-Uc; Tue, 27 Sep 2011 04:33:54 -0700 Received: from mail174.messagelabs.com ([85.158.138.51]) by lists.xensource.com with esmtp (Exim 4.43) id 1R8VuQ-0001Hp-92 for xen-devel@lists.xensource.com; Tue, 27 Sep 2011 04:33:10 -0700 X-Env-Sender: Andrew.Cooper3@citrix.com X-Msg-Ref: server-7.tower-174.messagelabs.com!1317123185!32903129!1 X-Originating-IP: [66.165.176.63] X-StarScan-Version: 6.4.1; banners=-,-,- X-VirusChecked: Checked Received: (qmail 28069 invoked from network); 27 Sep 2011 11:33:06 -0000 Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63) by server-7.tower-174.messagelabs.com with RC4-SHA encrypted SMTP; 27 Sep 2011 11:33:06 -0000 X-IronPort-AV: E=Sophos;i="4.68,449,1312171200"; d="scan'208";a="164774902" Received: from ftlpmailmx02.citrite.net ([10.13.107.66]) by FTLPIPO02.CITRIX.COM with ESMTP/TLS/RC4-MD5; 27 Sep 2011 07:33:05 -0400 Received: from [10.80.2.18] (10.80.2.18) by FTLPMAILMX02.citrite.net (10.13.107.66) with Microsoft SMTP Server id 8.3.137.0; Tue, 27 Sep 2011 07:33:05 -0400 Message-ID: <4E81B46F.5080208@citrix.com> Date: Tue, 27 Sep 2011 12:33:03 +0100 From: Andrew Cooper <andrew.cooper3@citrix.com> User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.2.21) Gecko/20110831 Lightning/1.0b2 Thunderbird/3.1.13 MIME-Version: 1.0 To: <xen-devel@lists.xensource.com> Subject: Re: [Xen-devel] Debug event_channel.c References: <CAP2B85-QBczrKLWSKaRVBkao3=6PB=wnYvuKmoXYqGDbZFnTXA@mail.gmail.com> In-Reply-To: <CAP2B85-QBczrKLWSKaRVBkao3=6PB=wnYvuKmoXYqGDbZFnTXA@mail.gmail.com> Content-Type: text/plain; charset="ISO-8859-1" Content-Transfer-Encoding: 7bit X-BeenThere: xen-devel@lists.xensource.com X-Mailman-Version: 2.1.5 Precedence: list List-Id: Xen developer discussion <xen-devel.lists.xensource.com> List-Unsubscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe> List-Post: <mailto:xen-devel@lists.xensource.com> List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help> List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=subscribe> Sender: xen-devel-bounces@lists.xensource.com Errors-To: xen-devel-bounces@lists.xensource.com On 27/09/11 12:09, Daniel Castro wrote: > Hello All, > > I am trying to debug event_channel.c for this I have filled the > functions with gdprintk(XENLOG_WARNING, "..."); yet the messages are > not displayed on dmesg or /var/log/xen. Where could they be printed? > or should I use a different function? > > In grub I have loglvl=all to print all messages... > > Thanks for the answer, > > Daniel > gdprintk only gets set with guest debugging enabled. ( guest_loglvl on the command line ) My suggestion would be to just use regular printks and look at the serial log. -- Andrew Cooper - Dom0 Kernel Engineer, Citrix XenServer T: +44 (0)1223 225 900, http://www.citrix.com _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel From xen-devel-bounces@lists.xensource.com Tue Sep 27 04:36:56 2011 Return-path: <xen-devel-bounces@lists.xensource.com> Envelope-to: www-data@lists.xensource.com Delivery-date: Tue, 27 Sep 2011 04:36:56 -0700 Received: from localhost ([127.0.0.1] helo=lists.colo.xensource.com) by lists.xensource.com with esmtp (Exim 4.43) id 1R8Vy4-00029y-Jh; Tue, 27 Sep 2011 04:36:56 -0700 Received: from mail182.messagelabs.com ([85.158.139.83]) by lists.xensource.com with esmtp (Exim 4.43) id 1R8VxW-0001y6-AL for xen-devel@lists.xensource.com; Tue, 27 Sep 2011 04:36:22 -0700 X-Env-Sender: evil.dani@gmail.com X-Msg-Ref: server-5.tower-182.messagelabs.com!1317123379!14936611!1 X-Originating-IP: [209.85.161.43] X-StarScan-Version: 6.4.1; banners=-,-,- X-VirusChecked: Checked Received: (qmail 18064 invoked from network); 27 Sep 2011 11:36:19 -0000 Received: from mail-fx0-f43.google.com (HELO mail-fx0-f43.google.com) (209.85.161.43) by server-5.tower-182.messagelabs.com with RC4-SHA encrypted SMTP; 27 Sep 2011 11:36:19 -0000 Received: by fxh19 with SMTP id 19so9006617fxh.30 for <xen-devel@lists.xensource.com>; Tue, 27 Sep 2011 04:36:19 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; bh=YVpz6jPODL+S5/tbhEu4HcebNOhAbu7ZTcccRARuPmU=; b=tGOSwHeO5g2izB1O6uAxFeZWQ2BrwDX3W3f8YYJG6H7Rt0XKIx88rInkavMTeds+AX BmAhGtY66oP61f2CZQGw0dozpDMrEX1qXov+foAwZQFX+wNFyOMKHdnDcBb4eSN2dglb Iv9Wot7X/6i/vzpCVq21dhZCf4iEEJJKf7uNA= MIME-Version: 1.0 Received: by 10.223.52.91 with SMTP id h27mr4858264fag.18.1317123378997; Tue, 27 Sep 2011 04:36:18 -0700 (PDT) Received: by 10.223.97.9 with HTTP; Tue, 27 Sep 2011 04:36:18 -0700 (PDT) In-Reply-To: <4E81B46F.5080208@citrix.com> References: <CAP2B85-QBczrKLWSKaRVBkao3=6PB=wnYvuKmoXYqGDbZFnTXA@mail.gmail.com> <4E81B46F.5080208@citrix.com> Date: Tue, 27 Sep 2011 20:36:18 +0900 Message-ID: <CAP2B85_2L2jkRMqbD6OCRXXaPR1nXV3RmRgcLo2zTTuSLDq5_g@mail.gmail.com> Subject: Re: [Xen-devel] Debug event_channel.c From: Daniel Castro <evil.dani@gmail.com> To: Andrew Cooper <andrew.cooper3@citrix.com> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: xen-devel@lists.xensource.com X-BeenThere: xen-devel@lists.xensource.com X-Mailman-Version: 2.1.5 Precedence: list List-Id: Xen developer discussion <xen-devel.lists.xensource.com> List-Unsubscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe> List-Post: <mailto:xen-devel@lists.xensource.com> List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help> List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=subscribe> Sender: xen-devel-bounces@lists.xensource.com Errors-To: xen-devel-bounces@lists.xensource.com On Tue, Sep 27, 2011 at 8:33 PM, Andrew Cooper <andrew.cooper3@citrix.com> wrote: > On 27/09/11 12:09, Daniel Castro wrote: >> Hello All, >> >> I am trying to debug event_channel.c for this I have filled the >> functions with gdprintk(XENLOG_WARNING, "..."); yet the messages are >> not displayed on dmesg or /var/log/xen. Where could they be printed? >> or should I use a different function? >> >> In grub I have loglvl=3Dall to print all messages... >> >> Thanks for the answer, >> >> Daniel >> > > gdprintk only gets set with guest debugging enabled. ( guest_loglvl on > the command line ) > > My suggestion would be to just use regular printks and look at the > serial log. How can can I look at the serial log from dom0? > > -- > Andrew Cooper - Dom0 Kernel Engineer, Citrix XenServer > T: +44 (0)1223 225 900, http://www.citrix.com > > > _______________________________________________ > Xen-devel mailing list > Xen-devel@lists.xensource.com > http://lists.xensource.com/xen-devel > --=20 +-=3D=3D=3D=3D=3D---------------------------+ | +---------------------------------+ | This space intentionally blank for notetaking. | |=A0=A0 | Daniel Castro,=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 | | |=A0=A0 | Consultant/Programmer.| | |=A0=A0 | U Andes=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0=A0 | +-------------------------------------+ _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel From xen-devel-bounces@lists.xensource.com Tue Sep 27 04:42:32 2011 Return-path: <xen-devel-bounces@lists.xensource.com> Envelope-to: www-data@lists.xensource.com Delivery-date: Tue, 27 Sep 2011 04:42:32 -0700 Received: from localhost ([127.0.0.1] helo=lists.colo.xensource.com) by lists.xensource.com with esmtp (Exim 4.43) id 1R8W3U-0002bK-Ln; Tue, 27 Sep 2011 04:42:32 -0700 Received: from mail216.messagelabs.com ([85.158.143.99]) by lists.xensource.com with esmtp (Exim 4.43) id 1R8Rlz-0004Zs-Jy for xen-devel@lists.xensource.com; Tue, 27 Sep 2011 00:08:17 -0700 X-Env-Sender: dan.carpenter@oracle.com X-Msg-Ref: server-4.tower-216.messagelabs.com!1317107286!19684989!1 X-Originating-IP: [141.146.126.227] X-StarScan-Version: 6.4.1; banners=-,-,- X-VirusChecked: Checked Received: (qmail 3229 invoked from network); 27 Sep 2011 07:08:07 -0000 Received: from acsinet15.oracle.com (HELO acsinet15.oracle.com) (141.146.126.227) by server-4.tower-216.messagelabs.com with DHE-RSA-AES256-SHA encrypted SMTP; 27 Sep 2011 07:08:07 -0000 Received: from rtcsinet22.oracle.com (rtcsinet22.oracle.com [66.248.204.30]) by acsinet15.oracle.com (Switch-3.4.4/Switch-3.4.4) with ESMTP id p8R77WVH002713 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Tue, 27 Sep 2011 07:07:34 GMT Received: from acsmt358.oracle.com (acsmt358.oracle.com [141.146.40.158]) by rtcsinet22.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id p8R77UnY018182 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 27 Sep 2011 07:07:31 GMT Received: from abhmt109.oracle.com (abhmt109.oracle.com [141.146.116.61]) by acsmt358.oracle.com (8.12.11.20060308/8.12.11) with ESMTP id p8R77Ol9001496; Tue, 27 Sep 2011 02:07:24 -0500 Received: from elgon.mountain (/41.139.221.94) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Tue, 27 Sep 2011 00:07:24 -0700 Date: Tue, 27 Sep 2011 10:07:21 +0300 From: Dan Carpenter <dan.carpenter@oracle.com> To: Jeremy Fitzhardinge <jeremy.fitzhardinge@citrix.com> Message-ID: <20110927070721.GA7351@elgon.mountain> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.5.21 (2010-09-15) X-Source-IP: rtcsinet22.oracle.com [66.248.204.30] X-CT-RefId: str=0001.0A090203.4E817637.0013,ss=1,re=0.000,fgs=0 X-Mailman-Approved-At: Tue, 27 Sep 2011 04:41:38 -0700 Cc: kernel-janitors@vger.kernel.org, xen-devel@lists.xensource.com, virtualization@lists.linux-foundation.org, Jan Beulich <jbeulich@suse.com>, Konrad Rzeszutek Wilk <konrad.wilk@oracle.com> Subject: [Xen-devel] [patch] xen: double lock typo X-BeenThere: xen-devel@lists.xensource.com X-Mailman-Version: 2.1.5 Precedence: list List-Id: Xen developer discussion <xen-devel.lists.xensource.com> List-Unsubscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe> List-Post: <mailto:xen-devel@lists.xensource.com> List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help> List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=subscribe> Sender: xen-devel-bounces@lists.xensource.com Errors-To: xen-devel-bounces@lists.xensource.com We called mutex_lock() twice instead of unlocking. Signed-off-by: Dan Carpenter <dan.carpenter@oracle.com> diff --git a/drivers/xen/xen-pciback/vpci.c b/drivers/xen/xen-pciback/vpci.c index 01222d7..46d140b 100644 --- a/drivers/xen/xen-pciback/vpci.c +++ b/drivers/xen/xen-pciback/vpci.c @@ -238,7 +238,7 @@ static int __xen_pcibk_get_pcifront_dev(struct pci_dev *pcidev, } } } - mutex_lock(&vpci_dev->lock); + mutex_unlock(&vpci_dev->lock); return found; } _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel From xen-devel-bounces@lists.xensource.com Tue Sep 27 04:43:51 2011 Return-path: <xen-devel-bounces@lists.xensource.com> Envelope-to: www-data@lists.xensource.com Delivery-date: Tue, 27 Sep 2011 04:43:51 -0700 Received: from localhost ([127.0.0.1] helo=lists.colo.xensource.com) by lists.xensource.com with esmtp (Exim 4.43) id 1R8W4k-0002yG-HY; Tue, 27 Sep 2011 04:43:51 -0700 Received: from mail216.messagelabs.com ([85.158.143.99]) by lists.xensource.com with smtp (Exim 4.43) id 1R8T6P-0001Te-8A for xen-devel@lists.xensource.com; Tue, 27 Sep 2011 01:33:21 -0700 X-Env-Sender: tonis@elkdata.ee X-Msg-Ref: server-2.tower-216.messagelabs.com!1317112398!19284472!1 X-Originating-IP: [194.106.101.168] X-StarScan-Version: 6.4.1; banners=-,-,- X-VirusChecked: Checked Received: (qmail 17721 invoked from network); 27 Sep 2011 08:33:18 -0000 Received: from mail.elkdata.ee (HELO mail.elkdata.ee) (194.106.101.168) by server-2.tower-216.messagelabs.com with SMTP; 27 Sep 2011 08:33:18 -0000 Received: from [192.168.1.100] (hi2-253.dyn.online.ee [194.106.113.253]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (No client certificate requested) by mail.elkdata.ee (Postfix) with ESMTPSA id 1C44E676F1F4 for <xen-devel@lists.xensource.com>; Tue, 27 Sep 2011 11:33:47 +0300 (EEST) Message-ID: <4E818A50.3050607@elkdata.ee> Date: Tue, 27 Sep 2011 11:33:20 +0300 From: =?ISO-8859-1?Q?T=F5nis_Bramanis?= <tonis@elkdata.ee> User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.2.22) Gecko/20110902 Thunderbird/3.1.14 MIME-Version: 1.0 To: xen-devel@lists.xensource.com Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit X-Mailman-Approved-At: Tue, 27 Sep 2011 04:41:38 -0700 Subject: [Xen-devel] Limit I/O for individual disks of VM X-BeenThere: xen-devel@lists.xensource.com X-Mailman-Version: 2.1.5 Precedence: list List-Id: Xen developer discussion <xen-devel.lists.xensource.com> List-Unsubscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe> List-Post: <mailto:xen-devel@lists.xensource.com> List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help> List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=subscribe> Sender: xen-devel-bounces@lists.xensource.com Errors-To: xen-devel-bounces@lists.xensource.com Hello! Will disk i/o limiting be added in any future versions? I see it in the 4.0 feature requests, but not in any changelogs. Best regards, Tõnis Bramanis Server administrator / client advisor Elkdata OÜ www.veebimajutus.ee Info: abi@veebimajutus.ee +372 683 5188 Directly: tonis@elkdata.ee +372 56 960 910 ------------------------------------------------------- _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel From xen-devel-bounces@lists.xensource.com Tue Sep 27 04:45:19 2011 Return-path: <xen-devel-bounces@lists.xensource.com> Envelope-to: www-data@lists.xensource.com Delivery-date: Tue, 27 Sep 2011 04:45:19 -0700 Received: from localhost ([127.0.0.1] helo=lists.colo.xensource.com) by lists.xensource.com with esmtp (Exim 4.43) id 1R8W69-0003Lv-BQ; Tue, 27 Sep 2011 04:45:17 -0700 Received: from mail182.messagelabs.com ([85.158.139.83]) by lists.xensource.com with smtp (Exim 4.43) id 1R8UNT-0006DS-4H for xen-devel@lists.xensource.com; Tue, 27 Sep 2011 02:55:03 -0700 X-Env-Sender: tm@tao.ma X-Msg-Ref: server-10.tower-182.messagelabs.com!1317117299!19878713!1 X-Originating-IP: [69.89.21.11] X-StarScan-Version: 6.4.1; banners=-,-,- X-VirusChecked: Checked Received: (qmail 31226 invoked from network); 27 Sep 2011 09:54:59 -0000 Received: from oproxy4-pub.bluehost.com (HELO oproxy4-pub.bluehost.com) (69.89.21.11) by server-10.tower-182.messagelabs.com with SMTP; 27 Sep 2011 09:54:59 -0000 Received: (qmail 20804 invoked by uid 0); 27 Sep 2011 09:54:58 -0000 Received: from unknown (HELO box585.bluehost.com) (66.147.242.185) by cpoproxy1.bluehost.com with SMTP; 27 Sep 2011 09:54:58 -0000 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=tao.ma; s=default; h=Content-Transfer-Encoding:Content-Type:In-Reply-To:References:Subject:CC:To:MIME-Version:From:Date:Message-ID; bh=wJtrCcrEbon0Co649fz9wXB/ZS4Ib97y4iMjyyJH0m4=; b=CSlUF7mJ+qOi9EMHxk8/PQQyA/YxPKUc6r+GtW33AGFsPe6mzFLa5QLDPwGagq+svANQcv4Vvr4PDPiKzcJ9Blw6Asr68DdUOT/yika+USuhBuPQjqKYN4tY7w3tBV2N; Received: from [182.92.247.2] (helo=[10.32.105.148]) by box585.bluehost.com with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.76) (envelope-from <tm@tao.ma>) id 1R8UNO-0006wW-FM; Tue, 27 Sep 2011 03:54:58 -0600 Message-ID: <4E819D5B.2050105@tao.ma> Date: Tue, 27 Sep 2011 17:54:35 +0800 From: Tao Ma <tm@tao.ma> User-Agent: Mozilla/5.0 (X11; U; Linux i686 (x86_64); en-US; rv:1.9.1.9) Gecko/20100317 Thunderbird/3.0.4 MIME-Version: 1.0 To: Jan Beulich <JBeulich@suse.com> Subject: Re: [Xen-devel] RE: [patch 1/1] ext4-fix-dirty-extent-when-origin-leaf-extent-reac.patch References: <BLU157-W499E698F650F554E645F9DDA1C0@phx.gbl>, <20110906145347.GA4133@dumpdata.com>, <BLU157-W4106FA4CF4EBA78C63FDA0DA1C0@phx.gbl>, <4E666C86.5090707@goop.org>, <BLU157-W323C330706CB8D7E976BC3DA1F0@phx.gbl>, <BLU157-W7DABA5FE01C50C29B1A64DA060@phx.gbl>, <BLU157-W25EB1EAC24CC11FA14859ADAF20@phx.gbl>, <20110926142808.GG4102@phenom.oracle.com> <BLU157-W54420DD5C05CB38610F67DAF00@phx.gbl> <4E81AEFE0200007800057F72@nat28.tlf.novell.com> In-Reply-To: <4E81AEFE0200007800057F72@nat28.tlf.novell.com> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Identified-User: {1390:box585.bluehost.com:colyli:tao.ma} {sentby:smtp auth 182.92.247.2 authed with tm@tao.ma} X-Mailman-Approved-At: Tue, 27 Sep 2011 04:41:38 -0700 Cc: MaoXiaoyun <tinnycloud@hotmail.com>, xen devel <xen-devel@lists.xensource.com>, jack@suse.cz, konrad.wilk@oracle.com, jeremy@goop.org, tytso@mit.edu, linux-ext4@vger.kernel.org X-BeenThere: xen-devel@lists.xensource.com X-Mailman-Version: 2.1.5 Precedence: list List-Id: Xen developer discussion <xen-devel.lists.xensource.com> List-Unsubscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe> List-Post: <mailto:xen-devel@lists.xensource.com> List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help> List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=subscribe> Sender: xen-devel-bounces@lists.xensource.com Errors-To: xen-devel-bounces@lists.xensource.com On 09/27/2011 05:09 PM, Jan Beulich wrote: >>>> On 27.09.11 at 04:22, MaoXiaoyun <tinnycloud@hotmail.com> wrote: > >> >> >> ---------------------------------------- >>> Date: Mon, 26 Sep 2011 10:28:08 -0400 >>> From: konrad.wilk@oracle.com >>> To: tinnycloud@hotmail.com >>> CC: linux-ext4@vger.kernel.org; xen-devel@lists.xensource.com; tytso@mit.edu; >> jack@suse.cz >>> Subject: Re: [patch 1/1] ext4-fix-dirty-extent-when-origin-leaf-extent-reac.patch >>> >>> On Sun, Sep 25, 2011 at 04:45:39PM +0800, MaoXiaoyun wrote: >>>> >>>> >>>> Hi: >>>> >>>> We met an ext4 BUG_ON in extents.c:1716 which crash kernel flush thread, >> and result in disk unvailiable. >>>> >>>> BUG details refer to: >> http://www.gossamer-threads.com/lists/xen/devel/217091?do=post_view_threaded >>>> >>>> Attached is the fix, verified in our env. >>> >>> So.. you are asking for this upstream git commit to be back-ported to 2.6.32, >> right? >>> >> >> The patch is for 2.6.39. It can be patched on 2.6.32 too. >> Thanks. > > So why don't you suggest applying this to the stable tree maintainers > instead? xen-devel really isn't the right forum for this sort of bug fixes, > particularly when the underlying kernel.org tree is still being maintained. AFAIK, the upstream linux kernel doesn't have this problem because this part of codes have been refactored. So I am not sure whether Greg KH will accept it or not. btw, I don't think the fix is appropriate. One of my colleague is working out another patch to resolve this(I will ask him to post the patch when it is ready). And we will contact Redhat for considering merging it to the enterprise kernel. Thanks Tao _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel From xen-devel-bounces@lists.xensource.com Tue Sep 27 04:55:05 2011 Return-path: <xen-devel-bounces@lists.xensource.com> Envelope-to: www-data@lists.xensource.com Delivery-date: Tue, 27 Sep 2011 04:55:05 -0700 Received: from localhost ([127.0.0.1] helo=lists.colo.xensource.com) by lists.xensource.com with esmtp (Exim 4.43) id 1R8WFd-0003rD-0H; Tue, 27 Sep 2011 04:55:05 -0700 Received: from mail216.messagelabs.com ([85.158.143.99]) by lists.xensource.com with esmtp (Exim 4.43) id 1R8WEj-0003ek-6k for xen-devel@lists.xensource.com; Tue, 27 Sep 2011 04:54:09 -0700 X-Env-Sender: dunlapg@gmail.com X-Msg-Ref: server-15.tower-216.messagelabs.com!1317124444!19231563!1 X-Originating-IP: [209.85.210.171] X-StarScan-Version: 6.4.1; banners=-,-,- X-VirusChecked: Checked Received: (qmail 23836 invoked from network); 27 Sep 2011 11:54:05 -0000 Received: from mail-iy0-f171.google.com (HELO mail-iy0-f171.google.com) (209.85.210.171) by server-15.tower-216.messagelabs.com with RC4-SHA encrypted SMTP; 27 Sep 2011 11:54:05 -0000 Received: by iagv1 with SMTP id v1so7525365iag.30 for <xen-devel@lists.xensource.com>; Tue, 27 Sep 2011 04:54:03 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=IMgjoRKZSN/DDKxGxPkH890j5vnDvkWYg2sEU+z9nmA=; b=i7NFU/bjg9oSXFTdZrpKnvSZ65P87KKIioHEes5LUnJLmeGQp+FrO1ySzl+cLuUpNm e1AhBruge8bCG/o+Jmzcu2h0rGoRUhJ8D+oJmFBBRpuZ/UlZPu1cHdDj5YBYHfYtHaAo cDgxyzzitVDzqqvt8z94/MAMNpX6CSzA3b5Jo= MIME-Version: 1.0 Received: by 10.231.29.141 with SMTP id q13mr10128394ibc.58.1317124443738; Tue, 27 Sep 2011 04:54:03 -0700 (PDT) Received: by 10.231.48.9 with HTTP; Tue, 27 Sep 2011 04:54:03 -0700 (PDT) In-Reply-To: <88b8953f5f5a514c84d7.1317054792@andrewcoop.uk.xensource.com> References: <88b8953f5f5a514c84d7.1317054792@andrewcoop.uk.xensource.com> Date: Tue, 27 Sep 2011 12:54:03 +0100 X-Google-Sender-Auth: vk7J6OXYJCKjjjKaJ2UdiBjxMmI Message-ID: <CAFLBxZapQt0ZAERTgn09tVUeKuHq0tYan9+TUPu=Bsa2S-mL5Q@mail.gmail.com> Subject: Re: [Xen-devel] [PATCH] IRQ: Fix trace bug introduced by c/s 23816:7f357e1ef60a From: George Dunlap <George.Dunlap@eu.citrix.com> To: Andrew Cooper <andrew.cooper3@citrix.com> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: xen-devel@lists.xensource.com X-BeenThere: xen-devel@lists.xensource.com X-Mailman-Version: 2.1.5 Precedence: list List-Id: Xen developer discussion <xen-devel.lists.xensource.com> List-Unsubscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe> List-Post: <mailto:xen-devel@lists.xensource.com> List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help> List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=subscribe> Sender: xen-devel-bounces@lists.xensource.com Errors-To: xen-devel-bounces@lists.xensource.com Acked-by: George Dunlap <george.dunlap@eu.citrix.com> On Mon, Sep 26, 2011 at 5:33 PM, Andrew Cooper <andrew.cooper3@citrix.com> wrote: > c/s 23816:7f357e1ef60a introduces cfg->old_vector and removes a loop > as a result. > > Outside the loop, 'vector' is set to cfg->vector, but the loop aliased > 'vector' to mean cfg->old_vector at the point at which this TRACE_3D > is executed. > > Therefore, when the loop was removed, the code still compiled, although > the trace would record incorrect information. > > Signed-off-by: Andrew Cooper <andrew.cooper3@citrix.com> > > diff -r a422e2a4451e -r 88b8953f5f5a xen/arch/x86/irq.c > --- a/xen/arch/x86/irq.c =A0 =A0 =A0 =A0Sun Sep 18 00:26:52 2011 +0100 > +++ b/xen/arch/x86/irq.c =A0 =A0 =A0 =A0Mon Sep 26 17:31:32 2011 +0100 > @@ -235,7 +235,7 @@ static void __clear_irq_vector(int irq) > =A0 =A0 cpus_and(tmp_mask, cfg->old_cpu_mask, cpu_online_map); > =A0 =A0 for_each_cpu_mask(cpu, tmp_mask) { > =A0 =A0 =A0 =A0 ASSERT( per_cpu(vector_irq, cpu)[cfg->old_vector] =3D=3D = irq ); > - =A0 =A0 =A0 =A0TRACE_3D(TRC_HW_IRQ_MOVE_FINISH, irq, vector, cpu); > + =A0 =A0 =A0 =A0TRACE_3D(TRC_HW_IRQ_MOVE_FINISH, irq, cfg->old_vector, c= pu); > =A0 =A0 =A0 =A0 per_cpu(vector_irq, cpu)[cfg->old_vector] =3D -1; > =A0 =A0 =A0} > > > _______________________________________________ > Xen-devel mailing list > Xen-devel@lists.xensource.com > http://lists.xensource.com/xen-devel > _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel From xen-devel-bounces@lists.xensource.com Tue Sep 27 05:10:29 2011 Return-path: <xen-devel-bounces@lists.xensource.com> Envelope-to: www-data@lists.xensource.com Delivery-date: Tue, 27 Sep 2011 05:10:30 -0700 Received: from localhost ([127.0.0.1] helo=lists.colo.xensource.com) by lists.xensource.com with esmtp (Exim 4.43) id 1R8WUX-0004T9-Qw; Tue, 27 Sep 2011 05:10:29 -0700 Received: from mail21.messagelabs.com ([85.158.143.35]) by lists.xensource.com with esmtp (Exim 4.43) id 1R8WTN-0004GS-Ma for xen-devel@lists.xensource.com; Tue, 27 Sep 2011 05:09:21 -0700 X-Env-Sender: Ian.Campbell@eu.citrix.com X-Msg-Ref: server-8.tower-21.messagelabs.com!1317125337!60545412!1 X-Originating-IP: [62.200.22.115] X-StarScan-Version: 6.4.1; banners=-,-,- X-VirusChecked: Checked Received: (qmail 25950 invoked from network); 27 Sep 2011 12:08:58 -0000 Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115) by server-8.tower-21.messagelabs.com with RC4-SHA encrypted SMTP; 27 Sep 2011 12:08:58 -0000 X-IronPort-AV: E=Sophos;i="4.68,449,1312156800"; d="scan'208";a="8080420" Received: from lonpmailmx01.citrite.net ([10.30.203.162]) by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5; 27 Sep 2011 12:09:14 +0000 Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net (10.30.203.162) with Microsoft SMTP Server id 8.3.137.0; Tue, 27 Sep 2011 13:09:13 +0100 Subject: Re: [Xen-devel] Debug event_channel.c From: Ian Campbell <Ian.Campbell@citrix.com> To: Daniel Castro <evil.dani@gmail.com> Date: Tue, 27 Sep 2011 13:09:13 +0100 In-Reply-To: <CAP2B85_2L2jkRMqbD6OCRXXaPR1nXV3RmRgcLo2zTTuSLDq5_g@mail.gmail.com> References: <CAP2B85-QBczrKLWSKaRVBkao3=6PB=wnYvuKmoXYqGDbZFnTXA@mail.gmail.com> <4E81B46F.5080208@citrix.com> <CAP2B85_2L2jkRMqbD6OCRXXaPR1nXV3RmRgcLo2zTTuSLDq5_g@mail.gmail.com> Organization: Citrix Systems, Inc. Content-Type: text/plain; charset="UTF-8" X-Mailer: Evolution 3.0.3- Content-Transfer-Encoding: 7bit Message-ID: <1317125353.26672.25.camel@zakaz.uk.xensource.com> MIME-Version: 1.0 Cc: Andrew Cooper <Andrew.Cooper3@citrix.com>, "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com> X-BeenThere: xen-devel@lists.xensource.com X-Mailman-Version: 2.1.5 Precedence: list List-Id: Xen developer discussion <xen-devel.lists.xensource.com> List-Unsubscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe> List-Post: <mailto:xen-devel@lists.xensource.com> List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help> List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=subscribe> Sender: xen-devel-bounces@lists.xensource.com Errors-To: xen-devel-bounces@lists.xensource.com On Tue, 2011-09-27 at 12:36 +0100, Daniel Castro wrote: > On Tue, Sep 27, 2011 at 8:33 PM, Andrew Cooper > <andrew.cooper3@citrix.com> wrote: > > On 27/09/11 12:09, Daniel Castro wrote: > >> Hello All, > >> > >> I am trying to debug event_channel.c for this I have filled the > >> functions with gdprintk(XENLOG_WARNING, "..."); yet the messages are > >> not displayed on dmesg or /var/log/xen. Where could they be printed? > >> or should I use a different function? > >> > >> In grub I have loglvl=all to print all messages... > >> > >> Thanks for the answer, > >> > >> Daniel > >> > > > > gdprintk only gets set with guest debugging enabled. ( guest_loglvl on > > the command line ) > > > > My suggestion would be to just use regular printks and look at the > > serial log. > > How can can I look at the serial log from dom0? 'xl dmesg' (or using a serial cable of course ;-)) You can also add XENCONSOLED_TRACE=hv in /etc/sysconfig/xencommons (or the equivalent on your distro, the effect should be to add --log=hv to the xenconsoled command line). Then the xen console will be logged under /var/log/xen somewhere. Ian. > > > > > -- > > Andrew Cooper - Dom0 Kernel Engineer, Citrix XenServer > > T: +44 (0)1223 225 900, http://www.citrix.com > > > > > > _______________________________________________ > > Xen-devel mailing list > > Xen-devel@lists.xensource.com > > http://lists.xensource.com/xen-devel > > > > > _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel From xen-devel-bounces@lists.xensource.com Tue Sep 27 05:38:51 2011 Return-path: <xen-devel-bounces@lists.xensource.com> Envelope-to: www-data@lists.xensource.com Delivery-date: Tue, 27 Sep 2011 05:38:51 -0700 Received: from localhost ([127.0.0.1] helo=lists.colo.xensource.com) by lists.xensource.com with esmtp (Exim 4.43) id 1R8Wvz-0005fL-0u; Tue, 27 Sep 2011 05:38:51 -0700 Received: from mail21.messagelabs.com ([85.158.143.35]) by lists.xensource.com with esmtp (Exim 4.43) id 1R8WvD-0005T7-3x for xen-devel@lists.xensource.com; Tue, 27 Sep 2011 05:38:03 -0700 X-Env-Sender: Ian.Jackson@eu.citrix.com X-Msg-Ref: server-9.tower-21.messagelabs.com!1317127034!49993333!1 X-Originating-IP: [62.200.22.115] X-StarScan-Version: 6.4.1; banners=-,-,- X-VirusChecked: Checked Received: (qmail 7019 invoked from network); 27 Sep 2011 12:37:14 -0000 Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115) by server-9.tower-21.messagelabs.com with RC4-SHA encrypted SMTP; 27 Sep 2011 12:37:14 -0000 X-IronPort-AV: E=Sophos;i="4.68,449,1312156800"; d="scan'208";a="8081800" Received: from lonpmailmx01.citrite.net ([10.30.203.162]) by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5; 27 Sep 2011 12:37:59 +0000 Received: from norwich.cam.xci-test.com (10.80.248.129) by smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id 8.3.137.0; Tue, 27 Sep 2011 13:37:59 +0100 Received: from mariner.cam.xci-test.com ([10.80.2.22] helo=mariner.uk.xensource.com ident=Debian-exim) by norwich.cam.xci-test.com with esmtp (Exim 4.72) (envelope-from <Ian.Jackson@eu.citrix.com>) id 1R8Wv9-0004UA-KR for xen-devel@lists.xensource.com; Tue, 27 Sep 2011 12:37:59 +0000 Received: from iwj by mariner.uk.xensource.com with local (Exim 4.69) (envelope-from <Ian.Jackson@eu.citrix.com>) id 1R8Wv9-0007os-Je for xen-devel@lists.xensource.com; Tue, 27 Sep 2011 13:37:59 +0100 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Message-ID: <20097.50087.424666.797321@mariner.uk.xensource.com> Date: Tue, 27 Sep 2011 13:37:59 +0100 To: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com> In-Reply-To: <osstest-9085-mainreport@xen.org> References: <osstest-9085-mainreport@xen.org> X-Mailer: VM 8.0.9 under Emacs 21.4.1 (i486-pc-linux-gnu) From: Ian Jackson <Ian.Jackson@eu.citrix.com> Subject: [Xen-devel] Re: [xen-unstable test] 9085: regressions - FAIL X-BeenThere: xen-devel@lists.xensource.com X-Mailman-Version: 2.1.5 Precedence: list List-Id: Xen developer discussion <xen-devel.lists.xensource.com> List-Unsubscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe> List-Post: <mailto:xen-devel@lists.xensource.com> List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help> List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=subscribe> Sender: xen-devel-bounces@lists.xensource.com Errors-To: xen-devel-bounces@lists.xensource.com xen.org writes ("[xen-unstable test] 9085: regressions - FAIL"): > test-amd64-i386-xl 5 xen-boot fail pass in 9083 Boot failure on machines with AMD IOMMU, I think. Ian. Sep 26 12:13:59.207009 (XEN) PCI: Using MCFG for segment 0000 bus 00-ff Sep 26 12:13:59.214606 (XEN) Xen BUG at iommu_init.c:777 Sep 26 12:13:59.218999 (XEN) ----[ Xen-4.2-unstable x86_64 debug=y Not tainted ]---- Sep 26 12:13:59.226620 (XEN) CPU: 0 Sep 26 12:13:59.226659 (XEN) RIP: e008:[<ffff82c48026f576>] alloc_ivrs_mappings+0x14/0x18b Sep 26 12:13:59.235021 (XEN) RFLAGS: 0000000000010246 CONTEXT: hypervisor Sep 26 12:13:59.243013 (XEN) rax: 0000000000000000 rbx: ffff8302155faee0 rcx: 0000000000000000 Sep 26 12:13:59.250624 (XEN) rdx: 0000000000000000 rsi: 0000000000000010 rdi: 0000000000000000 Sep 26 12:13:59.259027 (XEN) rbp: ffff82c4802a7d58 rsp: ffff82c4802a7d48 r8: ffff83021b202004 Sep 26 12:13:59.266626 (XEN) r9: 0000000000000010 r10: 0000000000000004 r11: 0000000000000001 Sep 26 12:13:59.274671 (XEN) r12: 0000000000000000 r13: ffff82c3ffd7a620 r14: ffff82c3ffd7a620 Sep 26 12:13:59.282628 (XEN) r15: ffff83000007bfb0 cr0: 000000008005003b cr4: 00000000000006f0 Sep 26 12:13:59.290627 (XEN) cr3: 00000000dfcac000 cr2: 0000000000000000 Sep 26 12:13:59.295026 (XEN) ds: 0000 es: 0000 fs: 0000 gs: 0000 ss: 0000 cs: e008 Sep 26 12:13:59.303027 (XEN) Xen stack trace from rsp=ffff82c4802a7d48: Sep 26 12:13:59.310613 (XEN) ffff8302155faee0 ffff82c3ffd7a650 ffff82c4802a7da8 ffff82c480270508 Sep 26 12:13:59.318631 (XEN) ffff82c4802a7df0 ffff83000007bf30 ffff82c4802a7d98 0000000000000030 Sep 26 12:13:59.326629 (XEN) ffff82c3ffd7a650 ffff82c3ffd7a620 ffff82c3ffd7a620 ffff83000007bfb0 Sep 26 12:13:59.334630 (XEN) ffff82c4802a7dd8 ffff82c480271f5f ffff82c480271ebc ffff82c48028adbd Sep 26 12:13:59.342631 (XEN) ffff83000007bf30 ffff83000007bf30 ffff82c4802a7e08 ffff82c48027238b Sep 26 12:13:59.350631 (XEN) ffff8302155faea0 ffff82c3ffd7a620 00000000ffffffed 0000000000000000 Sep 26 12:13:59.359035 (XEN) ffff82c4802a7e18 ffff82c4802707df ffff82c4802a7e28 ffff82c48026ff9b Sep 26 12:13:59.366656 (XEN) ffff82c4802a7e48 ffff82c48026cfc7 ffff82c4802a7f18 ffff83000007bfb0 Sep 26 12:13:59.374634 (XEN) ffff82c4802a7f08 ffff82c48027e179 0000000000000000 0000000000000000 Sep 26 12:13:59.382632 (XEN) ffff83000007bdc0 000000000084a000 00000000dfa00000 0000000000000000 Sep 26 12:13:59.390632 (XEN) 00000000002f6280 ffff82c4802d9574 ffff83000007bf30 00000000ffffffff Sep 26 12:13:59.399033 (XEN) ffff82c400000004 ffff830000000003 0000000800000000 000000010000006e Sep 26 12:13:59.406634 (XEN) 0000000000000003 00000000000002f8 0000000000000000 0000000000000000 Sep 26 12:13:59.414634 (XEN) 0000000000000000 0000000000000000 0000000000000000 0000000000000000 Sep 26 12:13:59.422635 (XEN) 000000000007fe0c ffff82c4801000b5 0000000000000000 0000000000000000 Sep 26 12:13:59.430737 (XEN) 0000000000000000 0000000000000000 0000000000000000 0000000000000000 Sep 26 12:13:59.442655 (XEN) 0000000000000000 0000000000000000 0000000000000000 0000000000000000 Sep 26 12:13:59.451039 (XEN) 0000000000000000 0000000000000000 0000000000000000 0000000000000000 Sep 26 12:13:59.458638 (XEN) 0000000000000000 0000000000000000 0000000000000000 0000000000000000 Sep 26 12:13:59.466638 (XEN) 0000000000000000 0000000000000000 0000000000000000 0000000000000000 Sep 26 12:13:59.474638 (XEN) Xen call trace: Sep 26 12:13:59.479012 (XEN) [<ffff82c48026f576>] alloc_ivrs_mappings+0x14/0x18b Sep 26 12:13:59.483042 (XEN) [<ffff82c480270508>] amd_iommu_detect_one_acpi+0x108/0x300 Sep 26 12:13:59.491039 (XEN) [<ffff82c480271f5f>] detect_iommu_acpi+0xa3/0xd4 Sep 26 12:13:59.498633 (XEN) [<ffff82c48027238b>] acpi_table_parse+0x6e/0x7c Sep 26 12:13:59.502631 (XEN) [<ffff82c4802707df>] amd_iommu_detect_acpi+0x17/0x19 Sep 26 12:13:59.511033 (XEN) [<ffff82c48026ff9b>] amd_iov_detect+0x1a/0xcf Sep 26 12:13:59.519034 (XEN) [<ffff82c48026cfc7>] iommu_setup+0x67/0x151 Sep 26 12:13:59.522631 (XEN) [<ffff82c48027e179>] __start_xen+0x258a/0x2931 Sep 26 12:13:59.530665 (XEN) Sep 26 12:13:59.530702 (XEN) Sep 26 12:13:59.534602 (XEN) **************************************** Sep 26 12:13:59.539024 (XEN) Panic on CPU 0: Sep 26 12:13:59.542612 (XEN) Xen BUG at iommu_init.c:777 Sep 26 12:13:59.546620 (XEN) **************************************** Sep 26 12:13:59.555029 (XEN) Sep 26 12:13:59.555065 (XEN) Reboot in five seconds... _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel From xen-devel-bounces@lists.xensource.com Tue Sep 27 06:01:43 2011 Return-path: <xen-devel-bounces@lists.xensource.com> Envelope-to: www-data@lists.xensource.com Delivery-date: Tue, 27 Sep 2011 06:01:43 -0700 Received: from localhost ([127.0.0.1] helo=lists.colo.xensource.com) by lists.xensource.com with esmtp (Exim 4.43) id 1R8XI6-0006VR-B7; Tue, 27 Sep 2011 06:01:42 -0700 Received: from mail174.messagelabs.com ([85.158.138.51]) by lists.xensource.com with esmtp (Exim 4.43) id 1R8XFQ-0006H3-EW for xen-devel@lists.xensource.com; Tue, 27 Sep 2011 05:58:59 -0700 X-Env-Sender: JBeulich@suse.com X-Msg-Ref: server-14.tower-174.messagelabs.com!1317128332!32940552!1 X-Originating-IP: [130.57.49.28] X-StarScan-Version: 6.4.1; banners=-,-,- X-VirusChecked: Checked Received: (qmail 4716 invoked from network); 27 Sep 2011 12:58:53 -0000 Received: from nat28.tlf.novell.com (HELO nat28.tlf.novell.com) (130.57.49.28) by server-14.tower-174.messagelabs.com with DHE-RSA-AES256-SHA encrypted SMTP; 27 Sep 2011 12:58:53 -0000 Received: from EMEA1-MTA by nat28.tlf.novell.com with Novell_GroupWise; Tue, 27 Sep 2011 13:58:52 +0100 Message-Id: <4E81E4AB0200007800058005@nat28.tlf.novell.com> X-Mailer: Novell GroupWise Internet Agent 8.0.1 Date: Tue, 27 Sep 2011 13:58:51 +0100 From: "Jan Beulich" <JBeulich@suse.com> To: "Ian Jackson" <Ian.Jackson@eu.citrix.com> Subject: [Xen-devel] Re: [xen-unstable test] 9085: regressions - FAIL References: <osstest-9085-mainreport@xen.org> <20097.50087.424666.797321@mariner.uk.xensource.com> In-Reply-To: <20097.50087.424666.797321@mariner.uk.xensource.com> Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: quoted-printable Content-Disposition: inline Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com> X-BeenThere: xen-devel@lists.xensource.com X-Mailman-Version: 2.1.5 Precedence: list List-Id: Xen developer discussion <xen-devel.lists.xensource.com> List-Unsubscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe> List-Post: <mailto:xen-devel@lists.xensource.com> List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help> List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=subscribe> Sender: xen-devel-bounces@lists.xensource.com Errors-To: xen-devel-bounces@lists.xensource.com >>> On 27.09.11 at 14:37, Ian Jackson <Ian.Jackson@eu.citrix.com> wrote: > xen.org writes ("[xen-unstable test] 9085: regressions - FAIL"): >> test-amd64-i386-xl 5 xen-boot fail pass in = 9083 >=20 > Boot failure on machines with AMD IOMMU, I think. I did send a patch for this on Friday (http://lists.xensource.com/archives/= html/xen-devel/2011-09/msg01281.html), but it didn't get applied so far. Jan > Ian. >=20 > Sep 26 12:13:59.207009 (XEN) PCI: Using MCFG for segment 0000 bus 00-ff > Sep 26 12:13:59.214606 (XEN) Xen BUG at iommu_init.c:777 > Sep 26 12:13:59.218999 (XEN) ----[ Xen-4.2-unstable x86_64 debug=3Dy = Not tainted=20 > ]---- > Sep 26 12:13:59.226620 (XEN) CPU: 0 > Sep 26 12:13:59.226659 (XEN) RIP: e008:[<ffff82c48026f576>]=20 > alloc_ivrs_mappings+0x14/0x18b > Sep 26 12:13:59.235021 (XEN) RFLAGS: 0000000000010246 CONTEXT: = hypervisor > Sep 26 12:13:59.243013 (XEN) rax: 0000000000000000 rbx: ffff8302155faee= 0 =20 > rcx: 0000000000000000 > Sep 26 12:13:59.250624 (XEN) rdx: 0000000000000000 rsi: 000000000000001= 0 =20 > rdi: 0000000000000000 > Sep 26 12:13:59.259027 (XEN) rbp: ffff82c4802a7d58 rsp: ffff82c4802a7d4= 8 =20 > r8: ffff83021b202004 > Sep 26 12:13:59.266626 (XEN) r9: 0000000000000010 r10: 000000000000000= 4 =20 > r11: 0000000000000001 > Sep 26 12:13:59.274671 (XEN) r12: 0000000000000000 r13: ffff82c3ffd7a62= 0 =20 > r14: ffff82c3ffd7a620 > Sep 26 12:13:59.282628 (XEN) r15: ffff83000007bfb0 cr0: 000000008005003= b =20 > cr4: 00000000000006f0 > Sep 26 12:13:59.290627 (XEN) cr3: 00000000dfcac000 cr2: 000000000000000= 0 > Sep 26 12:13:59.295026 (XEN) ds: 0000 es: 0000 fs: 0000 gs: 0000 = ss:=20 > 0000 cs: e008 > Sep 26 12:13:59.303027 (XEN) Xen stack trace from rsp=3Dffff82c4802a7d48:= > Sep 26 12:13:59.310613 (XEN) ffff8302155faee0 ffff82c3ffd7a650=20 > ffff82c4802a7da8 ffff82c480270508 > Sep 26 12:13:59.318631 (XEN) ffff82c4802a7df0 ffff83000007bf30=20 > ffff82c4802a7d98 0000000000000030 > Sep 26 12:13:59.326629 (XEN) ffff82c3ffd7a650 ffff82c3ffd7a620=20 > ffff82c3ffd7a620 ffff83000007bfb0 > Sep 26 12:13:59.334630 (XEN) ffff82c4802a7dd8 ffff82c480271f5f=20 > ffff82c480271ebc ffff82c48028adbd > Sep 26 12:13:59.342631 (XEN) ffff83000007bf30 ffff83000007bf30=20 > ffff82c4802a7e08 ffff82c48027238b > Sep 26 12:13:59.350631 (XEN) ffff8302155faea0 ffff82c3ffd7a620=20 > 00000000ffffffed 0000000000000000 > Sep 26 12:13:59.359035 (XEN) ffff82c4802a7e18 ffff82c4802707df=20 > ffff82c4802a7e28 ffff82c48026ff9b > Sep 26 12:13:59.366656 (XEN) ffff82c4802a7e48 ffff82c48026cfc7=20 > ffff82c4802a7f18 ffff83000007bfb0 > Sep 26 12:13:59.374634 (XEN) ffff82c4802a7f08 ffff82c48027e179=20 > 0000000000000000 0000000000000000 > Sep 26 12:13:59.382632 (XEN) ffff83000007bdc0 000000000084a000=20 > 00000000dfa00000 0000000000000000 > Sep 26 12:13:59.390632 (XEN) 00000000002f6280 ffff82c4802d9574=20 > ffff83000007bf30 00000000ffffffff > Sep 26 12:13:59.399033 (XEN) ffff82c400000004 ffff830000000003=20 > 0000000800000000 000000010000006e > Sep 26 12:13:59.406634 (XEN) 0000000000000003 00000000000002f8=20 > 0000000000000000 0000000000000000 > Sep 26 12:13:59.414634 (XEN) 0000000000000000 0000000000000000=20 > 0000000000000000 0000000000000000 > Sep 26 12:13:59.422635 (XEN) 000000000007fe0c ffff82c4801000b5=20 > 0000000000000000 0000000000000000 > Sep 26 12:13:59.430737 (XEN) 0000000000000000 0000000000000000=20 > 0000000000000000 0000000000000000 > Sep 26 12:13:59.442655 (XEN) 0000000000000000 0000000000000000=20 > 0000000000000000 0000000000000000 > Sep 26 12:13:59.451039 (XEN) 0000000000000000 0000000000000000=20 > 0000000000000000 0000000000000000 > Sep 26 12:13:59.458638 (XEN) 0000000000000000 0000000000000000=20 > 0000000000000000 0000000000000000 > Sep 26 12:13:59.466638 (XEN) 0000000000000000 0000000000000000=20 > 0000000000000000 0000000000000000 > Sep 26 12:13:59.474638 (XEN) Xen call trace: > Sep 26 12:13:59.479012 (XEN) [<ffff82c48026f576>]=20 > alloc_ivrs_mappings+0x14/0x18b > Sep 26 12:13:59.483042 (XEN) [<ffff82c480270508>]=20 > amd_iommu_detect_one_acpi+0x108/0x300 > Sep 26 12:13:59.491039 (XEN) [<ffff82c480271f5f>]=20 > detect_iommu_acpi+0xa3/0xd4 > Sep 26 12:13:59.498633 (XEN) [<ffff82c48027238b>]=20 > acpi_table_parse+0x6e/0x7c > Sep 26 12:13:59.502631 (XEN) [<ffff82c4802707df>]=20 > amd_iommu_detect_acpi+0x17/0x19 > Sep 26 12:13:59.511033 (XEN) [<ffff82c48026ff9b>] amd_iov_detect+0x1a/= 0xcf > Sep 26 12:13:59.519034 (XEN) [<ffff82c48026cfc7>] iommu_setup+0x67/0x1= 51 > Sep 26 12:13:59.522631 (XEN) [<ffff82c48027e179>] __start_xen+0x258a/0= x2931 > Sep 26 12:13:59.530665 (XEN) =20 > Sep 26 12:13:59.530702 (XEN)=20 > Sep 26 12:13:59.534602 (XEN) **************************************** > Sep 26 12:13:59.539024 (XEN) Panic on CPU 0: > Sep 26 12:13:59.542612 (XEN) Xen BUG at iommu_init.c:777 > Sep 26 12:13:59.546620 (XEN) **************************************** > Sep 26 12:13:59.555029 (XEN)=20 > Sep 26 12:13:59.555065 (XEN) Reboot in five seconds... >=20 > _______________________________________________ > Xen-devel mailing list > Xen-devel@lists.xensource.com=20 > http://lists.xensource.com/xen-devel=20 _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel From xen-devel-bounces@lists.xensource.com Tue Sep 27 06:16:09 2011 Return-path: <xen-devel-bounces@lists.xensource.com> Envelope-to: www-data@lists.xensource.com Delivery-date: Tue, 27 Sep 2011 06:16:09 -0700 Received: from localhost ([127.0.0.1] helo=lists.colo.xensource.com) by lists.xensource.com with esmtp (Exim 4.43) id 1R8XW5-00074W-Cq; Tue, 27 Sep 2011 06:16:09 -0700 Received: from mail174.messagelabs.com ([85.158.138.51]) by lists.xensource.com with esmtp (Exim 4.43) id 1R8XV3-0006ru-RU for xen-devel@lists.xensource.com; Tue, 27 Sep 2011 06:15:11 -0700 X-Env-Sender: Ian.Jackson@eu.citrix.com X-Msg-Ref: server-15.tower-174.messagelabs.com!1317129302!26599752!1 X-Originating-IP: [62.200.22.115] X-StarScan-Version: 6.4.1; banners=-,-,- X-VirusChecked: Checked Received: (qmail 30691 invoked from network); 27 Sep 2011 13:15:02 -0000 Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115) by server-15.tower-174.messagelabs.com with RC4-SHA encrypted SMTP; 27 Sep 2011 13:15:02 -0000 X-IronPort-AV: E=Sophos;i="4.68,449,1312156800"; d="scan'208";a="8082939" Received: from lonpmailmx01.citrite.net ([10.30.203.162]) by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5; 27 Sep 2011 13:15:02 +0000 Received: from norwich.cam.xci-test.com (10.80.248.129) by smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id 8.3.137.0; Tue, 27 Sep 2011 14:15:02 +0100 Received: from mariner.cam.xci-test.com ([10.80.2.22] helo=mariner.uk.xensource.com ident=Debian-exim) by norwich.cam.xci-test.com with esmtp (Exim 4.72) (envelope-from <Ian.Jackson@eu.citrix.com>) id 1R8XUz-0004d2-UU; Tue, 27 Sep 2011 13:15:01 +0000 Received: from iwj by mariner.uk.xensource.com with local (Exim 4.69) (envelope-from <Ian.Jackson@eu.citrix.com>) id 1R8XUz-0003Nu-Rd; Tue, 27 Sep 2011 14:15:01 +0100 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Message-ID: <20097.52309.844413.714683@mariner.uk.xensource.com> Date: Tue, 27 Sep 2011 14:15:01 +0100 To: Keir Fraser <keir.xen@gmail.com> Subject: [Xen-devel] Re: [xen-unstable test] 9085: regressions - FAIL In-Reply-To: <4E81E4AB0200007800058005@nat28.tlf.novell.com> References: <osstest-9085-mainreport@xen.org> <20097.50087.424666.797321@mariner.uk.xensource.com> <4E81E4AB0200007800058005@nat28.tlf.novell.com> X-Mailer: VM 8.0.9 under Emacs 21.4.1 (i486-pc-linux-gnu) From: Ian Jackson <Ian.Jackson@eu.citrix.com> Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>, Jan Beulich <JBeulich@suse.com> X-BeenThere: xen-devel@lists.xensource.com X-Mailman-Version: 2.1.5 Precedence: list List-Id: Xen developer discussion <xen-devel.lists.xensource.com> List-Unsubscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe> List-Post: <mailto:xen-devel@lists.xensource.com> List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help> List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=subscribe> Sender: xen-devel-bounces@lists.xensource.com Errors-To: xen-devel-bounces@lists.xensource.com Jan Beulich writes ("[Xen-devel] Re: [xen-unstable test] 9085: regressions - FAIL"): > >>> On 27.09.11 at 14:37, Ian Jackson <Ian.Jackson@eu.citrix.com> wrote: > > xen.org writes ("[xen-unstable test] 9085: regressions - FAIL"): > >> test-amd64-i386-xl 5 xen-boot fail pass in 9083 > > > > Boot failure on machines with AMD IOMMU, I think. > > I did send a patch for this on Friday (http://lists.xensource.com/archives/html/xen-devel/2011-09/msg01281.html), but it didn't get applied so far. Keir ? I'm not qualified to review this patch but it's currently pretty badly broken... Ian. _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel From xen-devel-bounces@lists.xensource.com Tue Sep 27 06:21:22 2011 Return-path: <xen-devel-bounces@lists.xensource.com> Envelope-to: www-data@lists.xensource.com Delivery-date: Tue, 27 Sep 2011 06:21:22 -0700 Received: from localhost ([127.0.0.1] helo=lists.colo.xensource.com) by lists.xensource.com with esmtp (Exim 4.43) id 1R8Xb7-0007Vc-Sq; Tue, 27 Sep 2011 06:21:21 -0700 Received: from mail27.messagelabs.com ([193.109.254.147]) by lists.xensource.com with esmtp (Exim 4.43) id 1R8XaY-0007JI-37 for xen-devel@lists.xensource.com; Tue, 27 Sep 2011 06:20:46 -0700 X-Env-Sender: Ian.Jackson@eu.citrix.com X-Msg-Ref: server-9.tower-27.messagelabs.com!1317129624!46219757!1 X-Originating-IP: [62.200.22.115] X-StarScan-Version: 6.4.1; banners=-,-,- X-VirusChecked: Checked Received: (qmail 18715 invoked from network); 27 Sep 2011 13:20:25 -0000 Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115) by server-9.tower-27.messagelabs.com with RC4-SHA encrypted SMTP; 27 Sep 2011 13:20:25 -0000 X-IronPort-AV: E=Sophos;i="4.68,449,1312156800"; d="scan'208";a="8083120" Received: from lonpmailmx01.citrite.net ([10.30.203.162]) by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5; 27 Sep 2011 13:20:38 +0000 Received: from woking.xci-test.com (10.80.248.135) by smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id 8.3.137.0; Tue, 27 Sep 2011 14:20:30 +0100 Received: from osstest by woking.xci-test.com with local (Exim 4.69) (envelope-from <ian.jackson@eu.citrix.com>) id 1R8XaH-0002Q1-Lm; Tue, 27 Sep 2011 14:20:29 +0100 To: <xen-devel@lists.xensource.com> Message-ID: <osstest-9095-mainreport@xen.org> From: xen.org <ian.jackson@eu.citrix.com> Date: Tue, 27 Sep 2011 14:20:29 +0100 MIME-Version: 1.0 Content-Type: text/plain Cc: ian.jackson@eu.citrix.com Subject: [Xen-devel] [linux test] 9095: tolerable FAIL - PUSHED X-BeenThere: xen-devel@lists.xensource.com X-Mailman-Version: 2.1.5 Precedence: list List-Id: Xen developer discussion <xen-devel.lists.xensource.com> List-Unsubscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe> List-Post: <mailto:xen-devel@lists.xensource.com> List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help> List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=subscribe> Sender: xen-devel-bounces@lists.xensource.com Errors-To: xen-devel-bounces@lists.xensource.com flight 9095 linux real [real] http://www.chiark.greenend.org.uk/~xensrcts/logs/9095/ Failures :-/ but no regressions. Tests which are failing intermittently (not blocking): test-amd64-amd64-xl-sedf 5 xen-boot fail pass in 9088 test-amd64-amd64-xl-sedf 14 guest-localmigrate/x10 fail in 9088 pass in 9084 Tests which did not succeed, but are not blocking, including regressions (tests previously passed) regarded as allowable: test-amd64-amd64-xl-pcipt-intel 9 guest-start fail never pass test-amd64-i386-rhel6hvm-amd 9 guest-start.2 fail never pass test-amd64-i386-rhel6hvm-intel 9 guest-start.2 fail never pass test-amd64-i386-win-vcpus1 16 leak-check/check fail never pass test-amd64-i386-xl-win-vcpus1 13 guest-stop fail never pass test-amd64-amd64-win 16 leak-check/check fail never pass test-amd64-amd64-xl-win 13 guest-stop fail never pass test-i386-i386-win 16 leak-check/check fail never pass test-i386-i386-xl-win 13 guest-stop fail never pass test-amd64-i386-win 16 leak-check/check fail never pass version targeted for testing: linux 6bec8b4a4c14095d0b7ce424db9d583c3decae6c baseline version: linux 1c3f03ccc5258887f5f2cafc0836a865834f9205 ------------------------------------------------------------ People who touched revisions under test: Jeremy Fitzhardinge <jeremy.fitzhardinge@citrix.com> ------------------------------------------------------------ jobs: build-amd64 pass build-i386 pass build-amd64-pvops pass build-i386-pvops pass test-amd64-amd64-xl pass test-amd64-i386-xl pass test-i386-i386-xl pass test-amd64-i386-rhel6hvm-amd fail test-amd64-i386-xl-credit2 pass test-amd64-amd64-xl-pcipt-intel fail test-amd64-i386-rhel6hvm-intel fail test-amd64-i386-xl-multivcpu pass test-amd64-amd64-pair pass test-amd64-i386-pair pass test-i386-i386-pair pass test-amd64-amd64-pv pass test-amd64-i386-pv pass test-i386-i386-pv pass test-amd64-amd64-xl-sedf fail test-amd64-i386-win-vcpus1 fail test-amd64-i386-xl-win-vcpus1 fail test-amd64-amd64-win fail test-amd64-i386-win fail test-i386-i386-win fail test-amd64-amd64-xl-win fail test-i386-i386-xl-win fail ------------------------------------------------------------ sg-report-flight on woking.cam.xci-test.com logs: /home/xc_osstest/logs images: /home/xc_osstest/images Logs, config files, etc. are available at http://www.chiark.greenend.org.uk/~xensrcts/logs Test harness code can be found at http://xenbits.xensource.com/gitweb?p=osstest.git;a=summary Pushing revision : + branch=linux + revision=6bec8b4a4c14095d0b7ce424db9d583c3decae6c + . cri-lock-repos ++ . cri-common +++ umask 002 +++ getconfig Repos +++ perl -e ' use Osstest; readconfigonly(); print $c{Repos} or die $!; ' ++ repos=/export/home/osstest/repos ++ repos_lock=/export/home/osstest/repos/lock ++ '[' x '!=' x/export/home/osstest/repos/lock ']' ++ OSSTEST_REPOS_LOCK_LOCKED=/export/home/osstest/repos/lock ++ exec with-lock-ex -w /export/home/osstest/repos/lock ./ap-push linux 6bec8b4a4c14095d0b7ce424db9d583c3decae6c + branch=linux + revision=6bec8b4a4c14095d0b7ce424db9d583c3decae6c + . cri-lock-repos ++ . cri-common +++ umask 002 +++ getconfig Repos +++ perl -e ' use Osstest; readconfigonly(); print $c{Repos} or die $!; ' ++ repos=/export/home/osstest/repos ++ repos_lock=/export/home/osstest/repos/lock ++ '[' x/export/home/osstest/repos/lock '!=' x/export/home/osstest/repos/lock ']' + : xen@xenbits.xensource.com + : xen@xenbits.xensource.com:git/linux-pvops + : master + : tested/2.6.39.x + case "$branch" in + cd /export/home/osstest/repos/linux + git push xen@xenbits.xensource.com:git/linux-pvops 6bec8b4a4c14095d0b7ce424db9d583c3decae6c:master Counting objects: 1 Counting objects: 19, done. Compressing objects: 11% (1/9) Compressing objects: 22% (2/9) Compressing objects: 33% (3/9) Compressing objects: 44% (4/9) Compressing objects: 55% (5/9) Compressing objects: 66% (6/9) Compressing objects: 77% (7/9) Compressing objects: 88% (8/9) Compressing objects: 100% (9/9) Compressing objects: 100% (9/9), done. Writing objects: 10% (1/10) Writing objects: 20% (2/10) Writing objects: 30% (3/10) Writing objects: 40% (4/10) Writing objects: 50% (5/10) Writing objects: 60% (6/10) Writing objects: 70% (7/10) Writing objects: 80% (8/10) Writing objects: 90% (9/10) Writing objects: 100% (10/10) Writing objects: 100% (10/10), 974 bytes, done. Total 10 (delta 9), reused 2 (delta 1) To xen@xenbits.xensource.com:git/linux-pvops 1c3f03c..6bec8b4 6bec8b4a4c14095d0b7ce424db9d583c3decae6c -> master _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel From xen-devel-bounces@lists.xensource.com Tue Sep 27 06:26:09 2011 Return-path: <xen-devel-bounces@lists.xensource.com> Envelope-to: www-data@lists.xensource.com Delivery-date: Tue, 27 Sep 2011 06:26:09 -0700 Received: from localhost ([127.0.0.1] helo=lists.colo.xensource.com) by lists.xensource.com with esmtp (Exim 4.43) id 1R8Xfl-0007w2-PP; Tue, 27 Sep 2011 06:26:09 -0700 Received: from mail27.messagelabs.com ([193.109.254.147]) by lists.xensource.com with esmtp (Exim 4.43) id 1R8Xeg-0007iz-Tc for xen-devel@lists.xensource.com; Tue, 27 Sep 2011 06:25:08 -0700 X-Env-Sender: keir.xen@gmail.com X-Msg-Ref: server-13.tower-27.messagelabs.com!1317129886!41740108!1 X-Originating-IP: [209.85.218.43] X-StarScan-Version: 6.4.1; banners=-,-,- X-VirusChecked: Checked Received: (qmail 8734 invoked from network); 27 Sep 2011 13:24:47 -0000 Received: from mail-yi0-f43.google.com (HELO mail-yi0-f43.google.com) (209.85.218.43) by server-13.tower-27.messagelabs.com with RC4-SHA encrypted SMTP; 27 Sep 2011 13:24:47 -0000 Received: by yib17 with SMTP id 17so8342030yib.30 for <xen-devel@lists.xensource.com>; Tue, 27 Sep 2011 06:24:58 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=user-agent:date:subject:from:to:message-id:thread-topic :thread-index:in-reply-to:mime-version:content-type :content-transfer-encoding; bh=hwTF/MqN54bYkOHo8RUIGIH4Q92v2VGrdaOAzmiDCf8=; b=WqVHohteF8bZvxUw89SsC1rJjIpmAbJwlRkgNWzmGRKWq9JRBozKEXyQ5DbmWHtPZh 9Zy+jRRmCiwAsfi3x4XgaHT+ZyarLUXEnC2TqhbkbleQ1lqGlQ890RQwPnk92JSF3dls lQB/gfsziUHo/Hr6bsLeNkg4lhstktMUDGo/U= Received: by 10.100.5.16 with SMTP id 16mr7024578ane.60.1317129898728; Tue, 27 Sep 2011 06:24:58 -0700 (PDT) Received: from [10.255.255.36] ([96.49.135.17]) by mx.google.com with ESMTPS id z6sm78699281anf.22.2011.09.27.06.24.55 (version=SSLv3 cipher=OTHER); Tue, 27 Sep 2011 06:24:56 -0700 (PDT) User-Agent: Microsoft-Entourage/12.30.0.110427 Date: Tue, 27 Sep 2011 06:24:51 -0700 Subject: Re: [Xen-devel] Architectural question: How to put BTS and PEBS in Xen From: Keir Fraser <keir.xen@gmail.com> To: Dietmar Hahn <dietmar.hahn@ts.fujitsu.com>, xen devel <xen-devel@lists.xensource.com> Message-ID: <CAA71CB3.21A71%keir.xen@gmail.com> Thread-Topic: [Xen-devel] Architectural question: How to put BTS and PEBS in Xen Thread-Index: Acx9GNYBbSsTr9mcy02qie0GKp1IEw== In-Reply-To: <201109271151.42552.dietmar.hahn@ts.fujitsu.com> Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit Cc: X-BeenThere: xen-devel@lists.xensource.com X-Mailman-Version: 2.1.5 Precedence: list List-Id: Xen developer discussion <xen-devel.lists.xensource.com> List-Unsubscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe> List-Post: <mailto:xen-devel@lists.xensource.com> List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help> List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=subscribe> Sender: xen-devel-bounces@lists.xensource.com Errors-To: xen-devel-bounces@lists.xensource.com On 27/09/2011 02:51, "Dietmar Hahn" <dietmar.hahn@ts.fujitsu.com> wrote: > Hi list, > > I'm on the way to coding the virtualisation of BTS (Branch Trace Store) and > later PEBS support for Intel CPU's in Xen. > > As some aspects overlap with the PMU (Performance Management Unit) I used the > existing infrastructure of the VPMU stuff to do some coding and tests. > But currently this infrastructure is only switched on with a 'vpmu' boot flag > in the hypervisor. > As reminder this flag was introduced because of an inexplicable behaviour of > the Nehalem CPUs while using the performance counters which could lead to an > endless interrupt loop (see check_pmc_quirk()). > > As currently no one else than we seem to use/need this feature for simplicity > I would move the BTS code complete to the VPMU environment and therfore it > would only be usable when using the 'vpmu' flag on boot. It sounds quite sensible to me. -- Keir > Any advices would be welcome! > > Thanks. > Dietmar. > _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel From xen-devel-bounces@lists.xensource.com Tue Sep 27 07:08:38 2011 Return-path: <xen-devel-bounces@lists.xensource.com> Envelope-to: www-data@lists.xensource.com Delivery-date: Tue, 27 Sep 2011 07:08:38 -0700 Received: from localhost ([127.0.0.1] helo=lists.colo.xensource.com) by lists.xensource.com with esmtp (Exim 4.43) id 1R8YKs-0001a3-7x; Tue, 27 Sep 2011 07:08:38 -0700 Received: from mail21.messagelabs.com ([85.158.143.35]) by lists.xensource.com with esmtp (Exim 4.43) id 1R8YJx-0001Nj-A2 for xen-devel@lists.xensource.com; Tue, 27 Sep 2011 07:07:41 -0700 X-Env-Sender: david.vrabel@citrix.com X-Msg-Ref: server-6.tower-21.messagelabs.com!1317132436!39856088!1 X-Originating-IP: [66.165.176.89] X-StarScan-Version: 6.4.1; banners=-,-,- X-VirusChecked: Checked Received: (qmail 9249 invoked from network); 27 Sep 2011 14:07:18 -0000 Received: from smtp.citrix.com (HELO SMTP.CITRIX.COM) (66.165.176.89) by server-6.tower-21.messagelabs.com with RC4-SHA encrypted SMTP; 27 Sep 2011 14:07:18 -0000 X-IronPort-AV: E=Sophos;i="4.68,449,1312171200"; d="scan'208";a="17728968" Received: from ftlpmailmx02.citrite.net ([10.13.107.66]) by FTLPIPO01.CITRIX.COM with ESMTP/TLS/RC4-MD5; 27 Sep 2011 10:07:36 -0400 Received: from [10.80.2.76] (10.80.2.76) by FTLPMAILMX02.citrite.net (10.13.107.66) with Microsoft SMTP Server id 8.3.137.0; Tue, 27 Sep 2011 10:07:36 -0400 Message-ID: <4E81D909.8020603@citrix.com> Date: Tue, 27 Sep 2011 15:09:13 +0100 From: David Vrabel <david.vrabel@citrix.com> User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.1.16) Gecko/20110818 Icedove/3.0.11 MIME-Version: 1.0 To: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com> References: <1316089768-22461-1-git-send-email-david.vrabel@citrix.com> <20110924020759.GA27796@phenom.oracle.com> In-Reply-To: <20110924020759.GA27796@phenom.oracle.com> Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: 7bit Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com> Subject: [Xen-devel] Re: xen: memory initialization/balloon fixes (#3) X-BeenThere: xen-devel@lists.xensource.com X-Mailman-Version: 2.1.5 Precedence: list List-Id: Xen developer discussion <xen-devel.lists.xensource.com> List-Unsubscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe> List-Post: <mailto:xen-devel@lists.xensource.com> List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help> List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=subscribe> Sender: xen-devel-bounces@lists.xensource.com Errors-To: xen-devel-bounces@lists.xensource.com On 24/09/11 03:08, Konrad Rzeszutek Wilk wrote: > On Thu, Sep 15, 2011 at 01:29:21PM +0100, David Vrabel wrote: >> This set of patches fixes some bugs in the memory initialization under >> Xen and in Xen's memory balloon driver. They can make 100s of MB of >> additional RAM available (depending on the system/configuration). >> >> Patch 1 is already applied. >> >> Patch 2 fixes a bug in patch 1 and should be queued for 3.1 (and along >> with patch 1 considered for 3.0 stable). >> >> Patch 3 is a bug fix and should be queued for 3.1 and possibly >> queued for the 3.0 stable tree. >> >> Patches 5 & 6 increase the amount of low memory in 32 bit domains >> started with < 1 GiB of RAM. Please queue for 3.2 >> >> Patch 7 releases all pages in the initial allocation with PFNs that >> lie within a 1-1 mapping. This seems correct to me as I think that >> once the 1-1 mapping is set the MFN of the original page is lost so >> it's no longer accessible by the kernel (and it cannot be used by >> another domain >> >> Changes since #2: >> >> - New patch: xen: avoid adding non-existant memory if the reservation >> is unlimited >> - Avoid using a hypercall to get the current number of pages in the >> ballon driver. Apparently the hypercall won't return the right >> value if paging is used. >> - Addresses Konrad's review comments. > > They don't work on AMD boxes: It's not specific to AMD boxes. > (XEN) Xen-e820 RAM map: > (XEN) 0000000000000000 - 000000000009d800 (usable) It's because it's not correctly handling the half-page of RAM at the end of this region. I don't have access to any test boxes with a dodgy BIOS like this so can you test this patch? If it works I'll fold it in and post an updated series. Can you remember why this page alignment was required? I'd like to update the comment with the reason because the bare-metal x86 memory init code doesn't appear to fixup the memory map in this way. diff --git a/arch/x86/xen/setup.c b/arch/x86/xen/setup.c index 986661b..e473c4c 100644 --- a/arch/x86/xen/setup.c +++ b/arch/x86/xen/setup.c @@ -178,6 +178,19 @@ static unsigned long __init xen_get_max_pages(void) return min(max_pages, MAX_DOMAIN_PAGES); } +static void xen_e820_add_region(u64 start, u64 size, int type) +{ + u64 end = start + size; + + /* Align RAM regions to page boundaries. */ + if (type == E820_RAM || type == E820_UNUSABLE) { + start = PAGE_ALIGN(start); + end &= ~((u64)PAGE_SIZE - 1); + } + + e820_add_region(start, end - start, type); +} + /** * machine_specific_memory_setup - Hook for machine specific memory setup. **/ @@ -253,10 +266,6 @@ char * __init xen_memory_setup(void) u32 type = map[i].type; if (type == E820_RAM) { - /* RAM regions must be page aligned. */ - size -= (addr + size) % PAGE_SIZE; - addr = PAGE_ALIGN(addr); - if (addr < mem_end) { size = min(size, mem_end - addr); } else if (extra_pages) { @@ -267,7 +276,7 @@ char * __init xen_memory_setup(void) type = E820_UNUSABLE; } - e820_add_region(addr, size, type); + xen_e820_add_region(addr, size, type); map[i].addr += size; map[i].size -= size; David _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel From xen-devel-bounces@lists.xensource.com Tue Sep 27 07:42:12 2011 Return-path: <xen-devel-bounces@lists.xensource.com> Envelope-to: www-data@lists.xensource.com Delivery-date: Tue, 27 Sep 2011 07:42:12 -0700 Received: from localhost ([127.0.0.1] helo=lists.colo.xensource.com) by lists.xensource.com with esmtp (Exim 4.43) id 1R8YrL-0002ij-Pk; Tue, 27 Sep 2011 07:42:12 -0700 Received: from mail182.messagelabs.com ([85.158.139.83]) by lists.xensource.com with esmtp (Exim 4.43) id 1R8Yqc-0002W9-VO; Tue, 27 Sep 2011 07:41:27 -0700 X-Env-Sender: Ian.Campbell@eu.citrix.com X-Msg-Ref: server-6.tower-182.messagelabs.com!1317134483!18748794!1 X-Originating-IP: [62.200.22.115] X-StarScan-Version: 6.4.1; banners=-,-,- X-VirusChecked: Checked Received: (qmail 19695 invoked from network); 27 Sep 2011 14:41:23 -0000 Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115) by server-6.tower-182.messagelabs.com with RC4-SHA encrypted SMTP; 27 Sep 2011 14:41:23 -0000 X-IronPort-AV: E=Sophos;i="4.68,449,1312156800"; d="scan'208";a="8085615" Received: from lonpmailmx01.citrite.net ([10.30.203.162]) by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5; 27 Sep 2011 14:41:14 +0000 Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net (10.30.203.162) with Microsoft SMTP Server id 8.3.137.0; Tue, 27 Sep 2011 15:41:14 +0100 Subject: Re: [Xen-devel] Re: [Xen-users] Is xen planning to support hvm guests booting under UEFI? From: Ian Campbell <Ian.Campbell@eu.citrix.com> To: "Andrei E. Warkentin" <andrey.warkentin@gmail.com> Date: Tue, 27 Sep 2011 15:41:13 +0100 In-Reply-To: <CANz0V+6rBpboTiYb0YiFnSLTDHDSskSdyFxvkUZt8FoY89n0aw@mail.gmail.com> References: <CAA48DAF.2172A%keir.xen@gmail.com> <1317024471.24532.2.camel@zakaz.uk.xensource.com> <CANz0V+6rBpboTiYb0YiFnSLTDHDSskSdyFxvkUZt8FoY89n0aw@mail.gmail.com> Organization: Citrix Systems, Inc. Content-Type: text/plain; charset="UTF-8" X-Mailer: Evolution 3.0.3- Content-Transfer-Encoding: 7bit Message-ID: <1317134474.26672.43.camel@zakaz.uk.xensource.com> MIME-Version: 1.0 Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>, Keir Fraser <keir.xen@gmail.com>, jim burns <jim_burn@bellsouth.net>, Bei Guan <gbtju85@gmail.com>, Paul Durrant <Paul.Durrant@citrix.com>, Todd Deshane <todd.deshane@xen.org>, Jordan Justen <jljusten@gmail.com>, "xen-users@lists.xensource.com" <xen-users@lists.xensource.com> X-BeenThere: xen-devel@lists.xensource.com X-Mailman-Version: 2.1.5 Precedence: list List-Id: Xen developer discussion <xen-devel.lists.xensource.com> List-Unsubscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe> List-Post: <mailto:xen-devel@lists.xensource.com> List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help> List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=subscribe> Sender: xen-devel-bounces@lists.xensource.com Errors-To: xen-devel-bounces@lists.xensource.com On Mon, 2011-09-26 at 20:18 +0100, Andrei E. Warkentin wrote: > Hi Ian, Keir, others - > > I was the mentor for the project. We got to the point where OVMF on > Xen was indistinguishable from OVMF on QEMU as far > as emulated device support (Bei can confirm - is this true for > network/PXE boot as well?). ACPI and DMI info published from > the hvmloader is consumed by the firmware and published. I believe we > could boot RedHat. Last I checked Win7 was unbootable under QEMU with > OVMF (so we didn't check) and I don't know the status of that (if I > remember correctly, it BSODs in bootvid.sys (under QEMU) due to low > memory area not being reserved away, or because there is no fake IDT > set up - that seems to match up with the hoops I needed to do doing > similar work on Hyper-V). > > OVMF is aware of Xen, and work was being done on a PV block device > (Bei got as far as hypercall support and xenstore). Bei, are you > working on the PV block driver? I want to say we're pretty close on > that one (PV block not very hard, and neither is the block device > abstraction for EFI). Thanks for the update, it sounds like it's pretty far along. The PV enhancements etc sound great but it would be nice if we could tie up the baseline stuff so that folks can start using it. Is Bei still working on the project since the end of GSoC? If not is there an archive of what he accomplished so that we can find someone to pick up on it if necessary? > I/Bei had patches against hvmloader (to support booting OVMF) and Bei > had patches against the management stack as well to expose the > functionality of picking OVMF as the firmware. I believe all of these > were sent to xen development list. I remember these. A bunch got applied after some discussion but IIRC not all of them were? Bei, are you able to resend the ones which did not? Is there a wiki page or something somewhere detailing what a user needs to do (i.e. build steps, guest cfg etc) in order to use the UEFI support? Cheers, Ian. > > Jordan Justen (Intel) had been working on integrating the OVMF changes > last I checked, but I am not positive (I just changed jobs and > relocated, and still am not on the TianoCore mailing list). I am > adding him to the reply. > > A > > > 2011/9/26 Ian Campbell <Ian.Campbell@citrix.com>: > > Adding Bei Guan and Andrey Warkentin who I think were student and mentor > > respectively. Hi guys! > > > > On Sun, 2011-09-25 at 15:50 +0100, Keir Fraser wrote: > >> The GSOC project student seemed to be making good progress, and there were > >> others on the OVMF side who were giving him support. I haven't heard > >> anything in about a month now, though. > > > > It would be very interesting to get an update (or a pointer to one) of > > the status/result of this particular project now that the GSoC is over. > > > > Thanks, > > Ian. _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel From xen-devel-bounces@lists.xensource.com Tue Sep 27 07:46:52 2011 Return-path: <xen-devel-bounces@lists.xensource.com> Envelope-to: www-data@lists.xensource.com Delivery-date: Tue, 27 Sep 2011 07:46:52 -0700 Received: from localhost ([127.0.0.1] helo=lists.colo.xensource.com) by lists.xensource.com with esmtp (Exim 4.43) id 1R8Yvs-0003ne-BX; Tue, 27 Sep 2011 07:46:52 -0700 Received: from mail182.messagelabs.com ([85.158.139.83]) by lists.xensource.com with esmtp (Exim 4.43) id 1R8YvS-0003c1-Hz for xen-devel@lists.xensource.com; Tue, 27 Sep 2011 07:46:26 -0700 X-Env-Sender: Stefano.Stabellini@eu.citrix.com X-Msg-Ref: server-6.tower-182.messagelabs.com!1317134783!18749911!1 X-Originating-IP: [62.200.22.115] X-StarScan-Version: 6.4.1; banners=-,-,- X-VirusChecked: Checked Received: (qmail 4410 invoked from network); 27 Sep 2011 14:46:23 -0000 Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115) by server-6.tower-182.messagelabs.com with RC4-SHA encrypted SMTP; 27 Sep 2011 14:46:23 -0000 X-IronPort-AV: E=Sophos;i="4.68,449,1312156800"; d="scan'208";a="8085751" Received: from lonpmailmx01.citrite.net ([10.30.203.162]) by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5; 27 Sep 2011 14:46:21 +0000 Received: from kaball.uk.xensource.com (10.80.2.59) by LONPMAILMX01.citrite.net (10.30.203.162) with Microsoft SMTP Server id 8.3.137.0; Tue, 27 Sep 2011 15:46:21 +0100 Date: Tue, 27 Sep 2011 15:46:05 +0100 From: Stefano Stabellini <stefano.stabellini@eu.citrix.com> X-X-Sender: sstabellini@kaball-desktop To: Jeremy Fitzhardinge <jeremy@goop.org> In-Reply-To: <4E7C9ADD.6010209@goop.org> Message-ID: <alpine.DEB.2.00.1109271544470.3519@kaball-desktop> References: <1316776753-10168-1-git-send-email-stefano.stabellini@eu.citrix.com> <4E7C9ADD.6010209@goop.org> User-Agent: Alpine 2.00 (DEB 1167 2008-08-23) MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Cc: Ian Campbell <Ian.Campbell@eu.citrix.com>, "konrad.wilk@oracle.com" <konrad.wilk@oracle.com>, "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>, Stefano Stabellini <Stefano.Stabellini@eu.citrix.com> Subject: [Xen-devel] Re: [PATCH] xen: remove XEN_PLATFORM_PCI config option X-BeenThere: xen-devel@lists.xensource.com X-Mailman-Version: 2.1.5 Precedence: list List-Id: Xen developer discussion <xen-devel.lists.xensource.com> List-Unsubscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe> List-Post: <mailto:xen-devel@lists.xensource.com> List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help> List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=subscribe> Sender: xen-devel-bounces@lists.xensource.com Errors-To: xen-devel-bounces@lists.xensource.com On Fri, 23 Sep 2011, Jeremy Fitzhardinge wrote: > On 09/23/2011 04:19 AM, stefano.stabellini@eu.citrix.com wrote: > > From: Stefano Stabellini <stefano.stabellini@eu.citrix.com> > > > > Xen PVHVM needs xen-platform-pci, on the other hand xen-platform-pci is > > useless in any other cases. > > Therefore remove the XEN_PLATFORM_PCI config option and compile > > xen-platform-pci built-in if XEN_PVHVM is selected. > > What happens if you disable CONFIG_PCI? > > I think XEN_PLATFORM_PCI still needs to exist, but just not user-visible. What if we add CONFIG_PCI as a dependency of XEN_PVHVM? It is not like it is going to be useful to run a PV on HVM guest without PV drivers. _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel From xen-devel-bounces@lists.xensource.com Tue Sep 27 07:51:14 2011 Return-path: <xen-devel-bounces@lists.xensource.com> Envelope-to: www-data@lists.xensource.com Delivery-date: Tue, 27 Sep 2011 07:51:14 -0700 Received: from localhost ([127.0.0.1] helo=lists.colo.xensource.com) by lists.xensource.com with esmtp (Exim 4.43) id 1R8Z06-0004Du-9p; Tue, 27 Sep 2011 07:51:14 -0700 Received: from mail216.messagelabs.com ([85.158.143.99]) by lists.xensource.com with esmtp (Exim 4.43) id 1R8Yzh-00041e-Ut for xen-devel@lists.xensource.com; Tue, 27 Sep 2011 07:50:51 -0700 X-Env-Sender: adi@cg.tuwien.ac.at X-Msg-Ref: server-15.tower-216.messagelabs.com!1317135040!19257865!1 X-Originating-IP: [213.129.229.198] X-StarScan-Version: 6.4.1; banners=-,-,- X-VirusChecked: Checked Received: (qmail 22798 invoked from network); 27 Sep 2011 14:50:40 -0000 Received: from vrvis-198.vrvis.at (HELO iris.vrvis.at) (213.129.229.198) by server-15.tower-216.messagelabs.com with AES256-SHA encrypted SMTP; 27 Sep 2011 14:50:40 -0000 Received: from actoris.vrvis.lan ([10.42.1.75] helo=vrvis.at) by iris.vrvis.at with esmtpsa (TLS1.0:DHE_RSA_AES_128_CBC_SHA1:16) (Exim 4.72) (envelope-from <adi@cg.tuwien.ac.at>) id 1R8YzM-0003FT-1H; Tue, 27 Sep 2011 16:50:28 +0200 Date: Tue, 27 Sep 2011 16:50:08 +0200 From: Adi Kriegisch <adi@cg.tuwien.ac.at> To: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com> Subject: Re: [Xen-devel] Re: Dom0 ACPI S3 patches Message-ID: <20110927145008.GN6720@vrvis.at> References: <20110914081156.GB3079@vrvis.at> <20110914102112.GB15866@phenom.oracle.com> <20110914112718.GG3079@vrvis.at> <20110914142854.GB16956@phenom.oracle.com> <20110914150934.GK3079@vrvis.at> <20110914154726.GA18810@phenom.oracle.com> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline In-Reply-To: <20110914154726.GA18810@phenom.oracle.com> User-Agent: Mutt/1.5.20 (2009-06-14) X-SA-Exim-Connect-IP: 10.42.1.75 X-SA-Exim-Mail-From: adi@cg.tuwien.ac.at X-SA-Exim-Scanned: No (on iris.vrvis.at); SAEximRunCond expanded to false Cc: xen-devel@lists.xensource.com, Adi Kriegisch <adi@cg.tuwien.ac.at> X-BeenThere: xen-devel@lists.xensource.com X-Mailman-Version: 2.1.5 Precedence: list List-Id: Xen developer discussion <xen-devel.lists.xensource.com> List-Unsubscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe> List-Post: <mailto:xen-devel@lists.xensource.com> List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help> List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=subscribe> Sender: xen-devel-bounces@lists.xensource.com Errors-To: xen-devel-bounces@lists.xensource.com On Wed, Sep 14, 2011 at 11:47:26AM -0400, Konrad Rzeszutek Wilk wrote: > On Wed, Sep 14, 2011 at 05:09:34PM +0200, Adi Kriegisch wrote: > > On Wed, Sep 14, 2011 at 10:28:54AM -0400, Konrad Rzeszutek Wilk wrote: > > > > > Excellent. Is it OK if I put 'Tested-by: Adi Kriegish" on them? Works like a charme with 'nopat'. No crash ever since. > > > > > You know, I don't know. I just never thought about that - um. I wonder > > > > > if it is related to the RTC update patch that I've been meaning > > > > > to take a look at: > > > > > > > > > > http://lists.xensource.com/archives/html/xen-devel/2010-02/msg00469.html [SNIP] > Pfff.. well, I will try to rebase it in a couple of days. Can you ping in a week > if I haven't sent anything to you yet? Any news on this one? I still have to resync my clock after acpi sleep... Thanks, Adi Kriegisch _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel From xen-devel-bounces@lists.xensource.com Tue Sep 27 08:05:23 2011 Return-path: <xen-devel-bounces@lists.xensource.com> Envelope-to: www-data@lists.xensource.com Delivery-date: Tue, 27 Sep 2011 08:05:23 -0700 Received: from localhost ([127.0.0.1] helo=lists.colo.xensource.com) by lists.xensource.com with esmtp (Exim 4.43) id 1R8ZDm-00054Q-OW; Tue, 27 Sep 2011 08:05:22 -0700 Received: from mail21.messagelabs.com ([85.158.143.35]) by lists.xensource.com with esmtp (Exim 4.43) id 1R8ZBV-0004oV-8o for xen-devel@lists.xensource.com; Tue, 27 Sep 2011 08:03:04 -0700 X-Env-Sender: anthony.perard@gmail.com X-Msg-Ref: server-6.tower-21.messagelabs.com!1317135757!39866500!1 X-Originating-IP: [209.85.216.178] X-StarScan-Version: 6.4.1; banners=-,-,- X-VirusChecked: Checked Received: (qmail 13705 invoked from network); 27 Sep 2011 15:02:38 -0000 Received: from mail-qy0-f178.google.com (HELO mail-qy0-f178.google.com) (209.85.216.178) by server-6.tower-21.messagelabs.com with RC4-SHA encrypted SMTP; 27 Sep 2011 15:02:38 -0000 Received: by qyg14 with SMTP id 14so8225640qyg.9 for <xen-devel@lists.xensource.com>; Tue, 27 Sep 2011 08:02:57 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:sender:from:date:x-google-sender-auth:message-id :subject:to:cc:content-type; bh=LhYPgs6m7PatGssnN2ujgUP1IYn3siYIrwITuBxxTTQ=; b=gaLA2ivm2Ctb6q/m3ix8JPEVE6J5wgmOhUgG30FinHgiXXRlO5CMNtTbAjL2y7Seyf 8SufNy2ykFqbMRIDBzfxmgzyV8/zImYcabLc0aT2YXF8QtNjFxsl/2+MtMSqdtlwm1r0 xycQ8oKVb6DpOaL/HYoYNTx3VTb8HR6YaDpI4= Received: by 10.224.193.1 with SMTP id ds1mr5690289qab.5.1317135776947; Tue, 27 Sep 2011 08:02:56 -0700 (PDT) MIME-Version: 1.0 Received: by 10.224.47.74 with HTTP; Tue, 27 Sep 2011 08:02:23 -0700 (PDT) From: Anthony PERARD <anthony.perard@citrix.com> Date: Tue, 27 Sep 2011 16:02:23 +0100 X-Google-Sender-Auth: s6xIEVSegmDWK-GM2vwu0WkFDEc Message-ID: <CAJJyHjK3ySHcHRC6eB2cPS=-=1JnqsWV4tXG0xDJgxpS2jG4=w@mail.gmail.com> To: QEMU-devel <qemu-devel@nongnu.org> Content-Type: text/plain; charset=UTF-8 Cc: Xen Devel <xen-devel@lists.xensource.com>, "Michael S. Tsirkin" <mst@redhat.com>, Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>, Alexander Graf <agraf@suse.de>, Alex Williamson <alex.williamson@redhat.com>, Anthony Liguori <anthony@codemonkey.ws>, Anthony PERARD <anthony.perard@citrix.com>, Stefano Stabellini <stefano.stabellini@eu.citrix.com> Subject: [Xen-devel] Try to integrate the Xen PCI Passthrough code into linux: have pci_regs conflict with libpci. X-BeenThere: xen-devel@lists.xensource.com X-Mailman-Version: 2.1.5 Precedence: list List-Id: Xen developer discussion <xen-devel.lists.xensource.com> List-Unsubscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe> List-Post: <mailto:xen-devel@lists.xensource.com> List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help> List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=subscribe> Sender: xen-devel-bounces@lists.xensource.com Errors-To: xen-devel-bounces@lists.xensource.com Hi, I'm trying to integrate the Xen PCI Passthrough code into Qemu. But we use libpci, and it's not friendly with pci_regs.h. So can I replace pci_regs by the libpci one? Should I avoid to include both? (by having a "hook" the libpci functions) Or do you have any other suggestions? Thanks, Regards, -- Anthony PERARD _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel From xen-devel-bounces@lists.xensource.com Tue Sep 27 08:07:46 2011 Return-path: <xen-devel-bounces@lists.xensource.com> Envelope-to: www-data@lists.xensource.com Delivery-date: Tue, 27 Sep 2011 08:07:46 -0700 Received: from localhost ([127.0.0.1] helo=lists.colo.xensource.com) by lists.xensource.com with esmtp (Exim 4.43) id 1R8ZG6-0005TV-OU; Tue, 27 Sep 2011 08:07:46 -0700 Received: from mail174.messagelabs.com ([85.158.138.51]) by lists.xensource.com with esmtp (Exim 4.43) id 1R8ZD1-0004wS-8u for xen-devel@lists.xensource.com; Tue, 27 Sep 2011 08:04:36 -0700 X-Env-Sender: dan.magenheimer@oracle.com X-Msg-Ref: server-10.tower-174.messagelabs.com!1317135870!32953568!1 X-Originating-IP: [141.146.126.227] X-StarScan-Version: 6.4.1; banners=-,-,- X-VirusChecked: Checked Received: (qmail 17217 invoked from network); 27 Sep 2011 15:04:31 -0000 Received: from acsinet15.oracle.com (HELO acsinet15.oracle.com) (141.146.126.227) by server-10.tower-174.messagelabs.com with DHE-RSA-AES256-SHA encrypted SMTP; 27 Sep 2011 15:04:31 -0000 Received: from acsinet21.oracle.com (acsinet21.oracle.com [141.146.126.237]) by acsinet15.oracle.com (Switch-3.4.4/Switch-3.4.4) with ESMTP id p8RF4OoF013597 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Tue, 27 Sep 2011 15:04:26 GMT Received: from acsmt358.oracle.com (acsmt358.oracle.com [141.146.40.158]) by acsinet21.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id p8RF4NDw019611 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 27 Sep 2011 15:04:23 GMT Received: from abhmt113.oracle.com (abhmt113.oracle.com [141.146.116.65]) by acsmt358.oracle.com (8.12.11.20060308/8.12.11) with ESMTP id p8RF4HMO018401; Tue, 27 Sep 2011 10:04:17 -0500 MIME-Version: 1.0 Message-ID: <2de59b55-4ecc-4155-8709-f8b0f5e012bc@default> Date: Tue, 27 Sep 2011 08:03:56 -0700 (PDT) From: Dan Magenheimer <dan.magenheimer@oracle.com> To: Konrad Wilk <konrad.wilk@oracle.com>, linux-kernel@vger.kernel.org X-Priority: 3 X-Mailer: Oracle Beehive Extensions for Outlook 2.0.1.4.1.0 (410211) [OL 12.0.6557.5001] Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable X-Source-IP: acsinet21.oracle.com [141.146.126.237] X-Auth-Type: Internal IP X-CT-RefId: str=0001.0A090201.4E81E5FB.00B9:SCFMA922111,ss=1,re=-4.000,fgs=0 Cc: Jeremy Fitzhardinge <jeremy@goop.org>, xen-devel@lists.xensource.com, David Vrabel <david.vrabel@citrix.com> Subject: [Xen-devel] [PATCH v2] xen: Fix selfballooning and ensure it doesn't go too far X-BeenThere: xen-devel@lists.xensource.com X-Mailman-Version: 2.1.5 Precedence: list List-Id: Xen developer discussion <xen-devel.lists.xensource.com> List-Unsubscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe> List-Post: <mailto:xen-devel@lists.xensource.com> List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help> List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=subscribe> Sender: xen-devel-bounces@lists.xensource.com Errors-To: xen-devel-bounces@lists.xensource.com Note: This patch is also now in a git tree at: git://oss.oracle.com/git/djm/tmem.git#selfballoon-fix-v2 The balloon driver's "current_pages" is very different from totalram_pages. Self-ballooning needs to be driven by the latter. Also, Committed_AS doesn't account for pages used by the kernel so enforce a floor for when there are little or no user-space threads using memory. The floor function includes a "safety margin" tuneable in case we discover later that the floor function is still too aggressive in some workloads, though likely it will not be needed. Changes since version 1: - tuneable safety margin added [v2: konrad.wilk@oracle.com: make safety margin tuneable] Signed-off-by: Dan Magenheimer <dan.magenheimer@oracle.com> diff --git a/drivers/xen/xen-selfballoon.c b/drivers/xen/xen-selfballoon.c index 6ea852e..ceaada6 100644 --- a/drivers/xen/xen-selfballoon.c +++ b/drivers/xen/xen-selfballoon.c @@ -93,6 +93,12 @@ static unsigned int selfballoon_uphysteresis __read_most= ly =3D 1; /* In HZ, controls frequency of worker invocation. */ static unsigned int selfballoon_interval __read_mostly =3D 5; =20 +/* + * Scale factor for safety margin for minimum selfballooning target for ba= lloon. + * Default adds about 3% (4/128) of max_pfn. + */ +static unsigned int selfballoon_safety_margin =3D 4; + static void selfballoon_process(struct work_struct *work); static DECLARE_DELAYED_WORK(selfballoon_worker, selfballoon_process); =20 @@ -195,14 +201,13 @@ __setup("selfballooning", xen_selfballooning_setup); */ static void selfballoon_process(struct work_struct *work) { -=09unsigned long cur_pages, goal_pages, tgt_pages; +=09unsigned long cur_pages, goal_pages, tgt_pages, floor_pages; =09bool reset_timer =3D false; =20 =09if (xen_selfballooning_enabled) { -=09=09cur_pages =3D balloon_stats.current_pages; +=09=09cur_pages =3D totalram_pages; =09=09tgt_pages =3D cur_pages; /* default is no change */ -=09=09goal_pages =3D percpu_counter_read_positive(&vm_committed_as) + -=09=09=09balloon_stats.current_pages - totalram_pages; +=09=09goal_pages =3D percpu_counter_read_positive(&vm_committed_as); #ifdef CONFIG_FRONTSWAP =09=09/* allow space for frontswap pages to be repatriated */ =09=09if (frontswap_selfshrinking && frontswap_enabled) @@ -217,7 +222,13 @@ static void selfballoon_process(struct work_struct *wo= rk) =09=09=09=09((goal_pages - cur_pages) / =09=09=09=09 selfballoon_uphysteresis); =09=09/* else if cur_pages =3D=3D goal_pages, no change */ -=09=09balloon_set_new_target(tgt_pages); +=09=09floor_pages =3D totalreserve_pages + +=09=09=09((roundup_pow_of_two(max_pfn) / 128) * +=09=09=09=09selfballoon_safety_margin); +=09=09if (tgt_pages < floor_pages) +=09=09=09tgt_pages =3D floor_pages; +=09=09balloon_set_new_target(tgt_pages + +=09=09=09balloon_stats.current_pages - totalram_pages); =09=09reset_timer =3D true; =09} #ifdef CONFIG_FRONTSWAP @@ -340,6 +351,30 @@ static ssize_t store_selfballoon_uphys(struct sys_devi= ce *dev, static SYSDEV_ATTR(selfballoon_uphysteresis, S_IRUGO | S_IWUSR, =09=09 show_selfballoon_uphys, store_selfballoon_uphys); =20 +SELFBALLOON_SHOW(selfballoon_safety_margin, "%d\n", selfballoon_safety_mar= gin); + +static ssize_t store_selfballoon_safety_margin(struct sys_device *dev, +=09=09=09=09=09 struct sysdev_attribute *attr, +=09=09=09=09=09 const char *buf, +=09=09=09=09=09 size_t count) +{ +=09unsigned long val; +=09int err; + +=09if (!capable(CAP_SYS_ADMIN)) +=09=09return -EPERM; +=09err =3D strict_strtoul(buf, 10, &val); +=09if (err || val =3D=3D 0 || val > 128) +=09=09return -EINVAL; +=09selfballoon_safety_margin =3D val; +=09return count; +} + +static SYSDEV_ATTR(selfballoon_safety_margin, S_IRUGO | S_IWUSR, +=09=09 show_selfballoon_safety_margin, +=09=09 store_selfballoon_safety_margin); + + #ifdef CONFIG_FRONTSWAP SELFBALLOON_SHOW(frontswap_selfshrinking, "%d\n", frontswap_selfshrinking)= ; =20 @@ -421,6 +456,7 @@ static struct attribute *selfballoon_attrs[] =3D { =09&attr_selfballoon_interval.attr, =09&attr_selfballoon_downhysteresis.attr, =09&attr_selfballoon_uphysteresis.attr, +=09&attr_selfballoon_safety_margin.attr, #ifdef CONFIG_FRONTSWAP =09&attr_frontswap_selfshrinking.attr, =09&attr_frontswap_hysteresis.attr, _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel From xen-devel-bounces@lists.xensource.com Tue Sep 27 08:20:25 2011 Return-path: <xen-devel-bounces@lists.xensource.com> Envelope-to: www-data@lists.xensource.com Delivery-date: Tue, 27 Sep 2011 08:20:25 -0700 Received: from localhost ([127.0.0.1] helo=lists.colo.xensource.com) by lists.xensource.com with esmtp (Exim 4.43) id 1R8ZSL-00060y-HT; Tue, 27 Sep 2011 08:20:25 -0700 Received: from mail174.messagelabs.com ([85.158.138.51]) by lists.xensource.com with smtp (Exim 4.43) id 1R8ZRf-0005o8-Kt for xen-devel@lists.xensource.com; Tue, 27 Sep 2011 08:19:44 -0700 X-Env-Sender: mst@redhat.com X-Msg-Ref: server-13.tower-174.messagelabs.com!1317136779!32982942!1 X-Originating-IP: [209.132.183.28] X-StarScan-Version: 6.4.1; banners=-,-,- X-VirusChecked: Checked Received: (qmail 30295 invoked from network); 27 Sep 2011 15:19:40 -0000 Received: from mx1.redhat.com (HELO mx1.redhat.com) (209.132.183.28) by server-13.tower-174.messagelabs.com with SMTP; 27 Sep 2011 15:19:40 -0000 Received: from int-mx09.intmail.prod.int.phx2.redhat.com (int-mx09.intmail.prod.int.phx2.redhat.com [10.5.11.22]) by mx1.redhat.com (8.14.4/8.14.4) with ESMTP id p8RFJXVA030581 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Tue, 27 Sep 2011 11:19:33 -0400 Received: from redhat.com (dhcp-1-35.tlv.redhat.com [10.35.1.35]) by int-mx09.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with SMTP id p8RFJUuH015633; Tue, 27 Sep 2011 11:19:31 -0400 Date: Tue, 27 Sep 2011 18:20:43 +0300 From: "Michael S. Tsirkin" <mst@redhat.com> To: Anthony PERARD <anthony.perard@citrix.com> Message-ID: <20110927152041.GB13889@redhat.com> References: <CAJJyHjK3ySHcHRC6eB2cPS=-=1JnqsWV4tXG0xDJgxpS2jG4=w@mail.gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <CAJJyHjK3ySHcHRC6eB2cPS=-=1JnqsWV4tXG0xDJgxpS2jG4=w@mail.gmail.com> User-Agent: Mutt/1.5.21 (2010-09-15) X-Scanned-By: MIMEDefang 2.68 on 10.5.11.22 Cc: Xen Devel <xen-devel@lists.xensource.com>, Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>, Stefano Stabellini <stefano.stabellini@eu.citrix.com>, Alexander Graf <agraf@suse.de>, QEMU-devel <qemu-devel@nongnu.org>, Alex Williamson <alex.williamson@redhat.com>, Anthony Liguori <anthony@codemonkey.ws> Subject: [Xen-devel] Re: Try to integrate the Xen PCI Passthrough code into linux: have pci_regs conflict with libpci. X-BeenThere: xen-devel@lists.xensource.com X-Mailman-Version: 2.1.5 Precedence: list List-Id: Xen developer discussion <xen-devel.lists.xensource.com> List-Unsubscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe> List-Post: <mailto:xen-devel@lists.xensource.com> List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help> List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=subscribe> Sender: xen-devel-bounces@lists.xensource.com Errors-To: xen-devel-bounces@lists.xensource.com On Tue, Sep 27, 2011 at 04:02:23PM +0100, Anthony PERARD wrote: > Hi, > > I'm trying to integrate the Xen PCI Passthrough code into Qemu. But we > use libpci, and it's not friendly with pci_regs.h. > > So can I replace pci_regs by the libpci one? I prefer sticking to pci_regs in linux. > Should I avoid to include both? (by having a "hook" the libpci functions) > Or do you have any other suggestions? > > Thanks, > Regards, Can you avoid libpci? It was very useful before sysfs, but on modern systems there isn't much that it does. -- MST _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel From xen-devel-bounces@lists.xensource.com Tue Sep 27 08:27:56 2011 Return-path: <xen-devel-bounces@lists.xensource.com> Envelope-to: www-data@lists.xensource.com Delivery-date: Tue, 27 Sep 2011 08:27:56 -0700 Received: from localhost ([127.0.0.1] helo=lists.colo.xensource.com) by lists.xensource.com with esmtp (Exim 4.43) id 1R8ZZb-00077u-UW; Tue, 27 Sep 2011 08:27:55 -0700 Received: from mail182.messagelabs.com ([85.158.139.83]) by lists.xensource.com with esmtp (Exim 4.43) id 1R8ZXw-0006ZL-RL; Tue, 27 Sep 2011 08:26:13 -0700 X-Env-Sender: keir.xen@gmail.com X-Msg-Ref: server-15.tower-182.messagelabs.com!1317137168!18947148!1 X-Originating-IP: [209.85.213.43] X-StarScan-Version: 6.4.1; banners=-,-,- X-VirusChecked: Checked Received: (qmail 24028 invoked from network); 27 Sep 2011 15:26:09 -0000 Received: from mail-yw0-f43.google.com (HELO mail-yw0-f43.google.com) (209.85.213.43) by server-15.tower-182.messagelabs.com with RC4-SHA encrypted SMTP; 27 Sep 2011 15:26:09 -0000 Received: by ywm21 with SMTP id 21so8510958ywm.30 for <multiple recipients>; Tue, 27 Sep 2011 08:26:08 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=user-agent:date:subject:from:to:cc:message-id:thread-topic :thread-index:in-reply-to:mime-version:content-type :content-transfer-encoding; bh=3m5dVqKIDqPPPB0066tIwizZbcyMhrcZObEd3xqFcB8=; b=RpYvzFLDTJp7DnXb+v//u/CImJGGIkkfVEwg78j6g4LHYZqy56Es6qxI74Opoe0RXN TtCvyt/3y7gCoJWx2cuzGbuja1uvlvQfXPmECZz2MTjF24QGOp5foWZeoWL0WNAzj8AJ Po/sEBXZT31yHAc6nXqIXWMH/A9JKHIkKT0FA= Received: by 10.151.92.12 with SMTP id u12mr7422365ybl.189.1317137167693; Tue, 27 Sep 2011 08:26:07 -0700 (PDT) Received: from [10.255.255.36] ([96.49.135.17]) by mx.google.com with ESMTPS id g20sm665271ybd.1.2011.09.27.08.26.03 (version=SSLv3 cipher=OTHER); Tue, 27 Sep 2011 08:26:06 -0700 (PDT) User-Agent: Microsoft-Entourage/12.30.0.110427 Date: Tue, 27 Sep 2011 08:26:01 -0700 Subject: Re: [Xen-devel] Re: [Xen-users] Is xen planning to support hvm guests booting under UEFI? From: Keir Fraser <keir.xen@gmail.com> To: Ian Campbell <Ian.Campbell@eu.citrix.com>, "Andrei E. Warkentin" <andrey.warkentin@gmail.com> Message-ID: <CAA73919.21AB3%keir.xen@gmail.com> Thread-Topic: [Xen-devel] Re: [Xen-users] Is xen planning to support hvm guests booting under UEFI? Thread-Index: Acx9KcNDUX6P5ZmF90ScXy2YnYkoPQ== In-Reply-To: <1317134474.26672.43.camel@zakaz.uk.xensource.com> Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>, jim burns <jim_burn@bellsouth.net>, Bei Guan <gbtju85@gmail.com>, Paul Durrant <Paul.Durrant@citrix.com>, Todd Deshane <todd.deshane@xen.org>, Jordan Justen <jljusten@gmail.com>, "xen-users@lists.xensource.com" <xen-users@lists.xensource.com> X-BeenThere: xen-devel@lists.xensource.com X-Mailman-Version: 2.1.5 Precedence: list List-Id: Xen developer discussion <xen-devel.lists.xensource.com> List-Unsubscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe> List-Post: <mailto:xen-devel@lists.xensource.com> List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help> List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=subscribe> Sender: xen-devel-bounces@lists.xensource.com Errors-To: xen-devel-bounces@lists.xensource.com On 27/09/2011 07:41, "Ian Campbell" <Ian.Campbell@eu.citrix.com> wrote: >> OVMF is aware of Xen, and work was being done on a PV block device >> (Bei got as far as hypercall support and xenstore). Bei, are you >> working on the PV block driver? I want to say we're pretty close on >> that one (PV block not very hard, and neither is the block device >> abstraction for EFI). > > Thanks for the update, it sounds like it's pretty far along. > > The PV enhancements etc sound great but it would be nice if we could tie > up the baseline stuff so that folks can start using it. Yes, we'd rather get something basically working into the tree, than wait for everything to be absolutely perfect. > Is Bei still working on the project since the end of GSoC? If not is > there an archive of what he accomplished so that we can find someone to > pick up on it if necessary? > >> I/Bei had patches against hvmloader (to support booting OVMF) and Bei >> had patches against the management stack as well to expose the >> functionality of picking OVMF as the firmware. I believe all of these >> were sent to xen development list. > > I remember these. A bunch got applied after some discussion but IIRC not > all of them were? Bei, are you able to resend the ones which did not? Pretty much all the non-ovmf-specific changes went in (i.e., the most contentious bits, to existing hvmloader code, should be pretty much checked in already). -- Keir > Is there a wiki page or something somewhere detailing what a user needs > to do (i.e. build steps, guest cfg etc) in order to use the UEFI > support? _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel From xen-devel-bounces@lists.xensource.com Tue Sep 27 08:48:18 2011 Return-path: <xen-devel-bounces@lists.xensource.com> Envelope-to: www-data@lists.xensource.com Delivery-date: Tue, 27 Sep 2011 08:48:18 -0700 Received: from localhost ([127.0.0.1] helo=lists.colo.xensource.com) by lists.xensource.com with esmtp (Exim 4.43) id 1R8ZtJ-0000Z6-VA; Tue, 27 Sep 2011 08:48:18 -0700 Received: from mail174.messagelabs.com ([85.158.138.51]) by lists.xensource.com with esmtp (Exim 4.43) id 1R8Zsb-0000MG-5e for xen-devel@lists.xensource.com; Tue, 27 Sep 2011 08:47:34 -0700 X-Env-Sender: Stefano.Stabellini@eu.citrix.com X-Msg-Ref: server-11.tower-174.messagelabs.com!1317138446!32962594!1 X-Originating-IP: [62.200.22.115] X-StarScan-Version: 6.4.1; banners=-,-,- X-VirusChecked: Checked Received: (qmail 2462 invoked from network); 27 Sep 2011 15:47:29 -0000 Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115) by server-11.tower-174.messagelabs.com with RC4-SHA encrypted SMTP; 27 Sep 2011 15:47:29 -0000 X-IronPort-AV: E=Sophos;i="4.68,449,1312156800"; d="scan'208";a="8087437" Received: from lonpmailmx01.citrite.net ([10.30.203.162]) by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5; 27 Sep 2011 15:47:26 +0000 Received: from kaball.uk.xensource.com (10.80.2.59) by LONPMAILMX01.citrite.net (10.30.203.162) with Microsoft SMTP Server id 8.3.137.0; Tue, 27 Sep 2011 16:47:26 +0100 Date: Tue, 27 Sep 2011 16:47:10 +0100 From: Stefano Stabellini <stefano.stabellini@eu.citrix.com> X-X-Sender: sstabellini@kaball-desktop To: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com> In-Reply-To: <20110923144538.GA10701@phenom.oracle.com> Message-ID: <alpine.DEB.2.00.1109271549030.3519@kaball-desktop> References: <alpine.DEB.2.00.1109081944150.12963@kaball-desktop> <20110921145853.GA541@phenom.oracle.com> <alpine.DEB.2.00.1109231412220.8700@kaball-desktop> <20110923144538.GA10701@phenom.oracle.com> User-Agent: Alpine 2.00 (DEB 1167 2008-08-23) MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Cc: Jeremy Fitzhardinge <jeremy@goop.org>, "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>, "linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>, Stefano Stabellini <Stefano.Stabellini@eu.citrix.com> Subject: [Xen-devel] Re: [PATCH v4 2/2] xen: modify kernel mappings corresponding to granted pages X-BeenThere: xen-devel@lists.xensource.com X-Mailman-Version: 2.1.5 Precedence: list List-Id: Xen developer discussion <xen-devel.lists.xensource.com> List-Unsubscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe> List-Post: <mailto:xen-devel@lists.xensource.com> List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help> List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=subscribe> Sender: xen-devel-bounces@lists.xensource.com Errors-To: xen-devel-bounces@lists.xensource.com On Fri, 23 Sep 2011, Konrad Rzeszutek Wilk wrote: > On Fri, Sep 23, 2011 at 02:55:09PM +0100, Stefano Stabellini wrote: > > On Wed, 21 Sep 2011, konrad.wilk@oracle.com wrote: > > > On Thu, Sep 08, 2011 at 07:45:29PM +0100, Stefano Stabellini wrote: > > > > If we want to use granted pages for AIO, changing the mappings of a user > > > > vma and the corresponding p2m is not enough, we also need to update the > > > > kernel mappings accordingly. > > > > > > Please add:" > > > > > > But only for pages that are created for user usages through /dev/xen/gntdev. > > > As in, pages that have been in use by the kernel and use the P2M will not need > > > this special mapping." > > > > > > Just so that it is quite clear when in a year somebody wants to debug > > > this code and wants to figure out if this patch causes issues. > > > > > > .. more comments below. > > > > OK, even though in the future it might happen that the kernel starts > > accessing pages through the 1:1 even for internal usage. Right now the > > only case in which this happens is on the user AIO code path but it > > doesn't mean that the problem is always going to be limited to pages > > used for user AIO. > > OK, please add that comment saying that.. OK. > > > > In order to avoid the complexity of dealing with highmem, we allocated > > > > the pages lowmem. > > > > We issue a HYPERVISOR_grant_table_op right away in > > > > m2p_add_override and we remove the mappings using another > > > > HYPERVISOR_grant_table_op in m2p_remove_override. > > > > Considering that m2p_add_override and m2p_remove_override are called > > > > once per page we use multicalls and hypercall batching. > > > > > > > > Use the kmap_op pointer directly as argument to do the mapping as it is > > > > guaranteed to be present up until the unmapping is done. > > > > Before issuing any unmapping multicalls, we need to make sure that the > > > > mapping has already being done, because we need the kmap->handle to be > > > > set correctly. > > > > > > > > Signed-off-by: Stefano Stabellini <stefano.stabellini@eu.citrix.com> > > > > --- > > > > arch/x86/include/asm/xen/page.h | 5 ++- > > > > arch/x86/xen/p2m.c | 68 +++++++++++++++++++++++++++++------ > > > > drivers/block/xen-blkback/blkback.c | 2 +- > > > > drivers/xen/gntdev.c | 27 +++++++++++++- > > > > drivers/xen/grant-table.c | 6 ++-- > > > > include/xen/grant_table.h | 1 + > > > > 6 files changed, 92 insertions(+), 17 deletions(-) > > > > > > > > diff --git a/arch/x86/include/asm/xen/page.h b/arch/x86/include/asm/xen/page.h > > > > index 7ff4669..0ce1884 100644 > > > > --- a/arch/x86/include/asm/xen/page.h > > > > +++ b/arch/x86/include/asm/xen/page.h > > > > @@ -12,6 +12,7 @@ > > > > #include <asm/pgtable.h> > > > > > > > > #include <xen/interface/xen.h> > > > > +#include <xen/grant_table.h> > > > > #include <xen/features.h> > > > > > > > > /* Xen machine address */ > > > > @@ -31,8 +32,10 @@ typedef struct xpaddr { > > > > #define INVALID_P2M_ENTRY (~0UL) > > > > #define FOREIGN_FRAME_BIT (1UL<<(BITS_PER_LONG-1)) > > > > #define IDENTITY_FRAME_BIT (1UL<<(BITS_PER_LONG-2)) > > > > +#define GRANT_FRAME_BIT (1UL<<(BITS_PER_LONG-3)) > > We aren't actually using the GRANT_FRAME_BIT in the P2M? As in > setting the value in the nice p2m.c code? So could this be > 1UL<<(BITS_PER_LONG-1) ? as you are setting this bit only in the > page->private and not really in the P2M tree...? > > Or did I miss some extra patch? Yes, you are correct, we are only using in page->private. > > > > #define FOREIGN_FRAME(m) ((m) | FOREIGN_FRAME_BIT) > > > > #define IDENTITY_FRAME(m) ((m) | IDENTITY_FRAME_BIT) > > > > +#define GRANT_FRAME(m) ((m) | GRANT_FRAME_BIT) > > > > > > > > /* Maximum amount of memory we can handle in a domain in pages */ > > > > #define MAX_DOMAIN_PAGES \ > > > > @@ -48,7 +51,7 @@ extern unsigned long set_phys_range_identity(unsigned long pfn_s, > > > > unsigned long pfn_e); > > > > > > > > extern int m2p_add_override(unsigned long mfn, struct page *page, > > > > - bool clear_pte); > > > > + struct gnttab_map_grant_ref *kmap_op); > > > > extern int m2p_remove_override(struct page *page, bool clear_pte); > > > > extern struct page *m2p_find_override(unsigned long mfn); > > > > extern unsigned long m2p_find_override_pfn(unsigned long mfn, unsigned long pfn); > > > > diff --git a/arch/x86/xen/p2m.c b/arch/x86/xen/p2m.c > > > > index 58efeb9..23f8465 100644 > > > > --- a/arch/x86/xen/p2m.c > > > > +++ b/arch/x86/xen/p2m.c > > > > @@ -161,7 +161,9 @@ > > > > #include <asm/xen/page.h> > > > > #include <asm/xen/hypercall.h> > > > > #include <asm/xen/hypervisor.h> > > > > +#include <xen/grant_table.h> > > > > > > > > +#include "multicalls.h" > > > > #include "xen-ops.h" > > > > > > > > static void __init m2p_override_init(void); > > > > @@ -676,7 +678,8 @@ static unsigned long mfn_hash(unsigned long mfn) > > > > } > > > > > > > > /* Add an MFN override for a particular page */ > > > > -int m2p_add_override(unsigned long mfn, struct page *page, bool clear_pte) > > > > +int m2p_add_override(unsigned long mfn, struct page *page, > > > > + struct gnttab_map_grant_ref *kmap_op) > > > > { > > > > unsigned long flags; > > > > unsigned long pfn; > > > > @@ -699,9 +702,20 @@ int m2p_add_override(unsigned long mfn, struct page *page, bool clear_pte) > > > > if (unlikely(!set_phys_to_machine(pfn, FOREIGN_FRAME(mfn)))) > > > > return -ENOMEM; > > > > > > > > - if (clear_pte && !PageHighMem(page)) > > > > - /* Just zap old mapping for now */ > > > > - pte_clear(&init_mm, address, ptep); > > > > + if (kmap_op != NULL) { > > > > + if (!PageHighMem(page)) { > > > > + struct multicall_space mcs = xen_mc_entry(sizeof(*kmap_op)); > > > > + > > > > + MULTI_grant_table_op(mcs.mc, > > > > + GNTTABOP_map_grant_ref, kmap_op, 1); > > > > + > > > > + xen_mc_issue(PARAVIRT_LAZY_MMU); > > > > + } > > > > + page->private |= GRANT_FRAME_BIT; > > It took a bit of stroll through the different users of page->private > and they seem to vary from sticking a 'struct list' (virtblk) on it, > to sticking an writeblock structure in it (afs) to some other users. > > Wonder if it makes sense to use the provided macros: > > SetPagePrivate(page) > set_page_private(page, page_private(page) | GRANT_FRAME_BIT); > > just to make it more prettier? Not really worried here, I can queue > up a patch for that myself for the rest of the M2P. Yep, I think it would make it nicer. > But (on a completlty different subject of this patch), I wonder > about fs/btrfs/extent_io.c (set_page_extent_mapped) or > nfs_inode_add_request (fs/nfs/write.c) and whether we > are we in danger of colliding with that? Say the page is used for > AIO and eventually ends up in btrfs or NFS? > > Wouldn't BTFS/NFS end up scrambling our precious page->private contents? > > Hm... NFS and both BTRFS seems to check for PagePrivate bit (which we forgot to set) > so we might be shooting ourselves in the foot - but I don't know enough > about those FS to know whether those pages that use ->private are special > pages which the user does not provide. > > Anyhow, If you want to modify your patchset to check PagePrivate bit > and set the SetPagePrivate/set_page_private - go ahead. I'll do that. > Otherwise I will queue up a patch that does those > SetPagePrivate/set_page_private calls. > > > > > + /* let's use dev_bus_addr to record the old mfn instead */ > > > > + kmap_op->dev_bus_addr = page->index; > > > > + page->index = (unsigned long) kmap_op; > > > > + } > > > > spin_lock_irqsave(&m2p_override_lock, flags); > > > > list_add(&page->lru, &m2p_overrides[mfn_hash(mfn)]); > > > > spin_unlock_irqrestore(&m2p_override_lock, flags); > > > > @@ -735,13 +749,45 @@ int m2p_remove_override(struct page *page, bool clear_pte) > > > > spin_lock_irqsave(&m2p_override_lock, flags); > > > > list_del(&page->lru); > > > > spin_unlock_irqrestore(&m2p_override_lock, flags); > > > > - set_phys_to_machine(pfn, page->index); > > > > > > > > - if (clear_pte && !PageHighMem(page)) > > > > - set_pte_at(&init_mm, address, ptep, > > > > - pfn_pte(pfn, PAGE_KERNEL)); > > > > - /* No tlb flush necessary because the caller already > > > > - * left the pte unmapped. */ > > > > + if (clear_pte) { > > > > + struct gnttab_map_grant_ref *map_op = > > > > + (struct gnttab_map_grant_ref *) page->index; > > > > + set_phys_to_machine(pfn, map_op->dev_bus_addr); > > > > + if (!PageHighMem(page)) { > > > > + struct multicall_space mcs; > > > > + struct gnttab_unmap_grant_ref *unmap_op; > > > > + > > > > + /* > > > > + * Has the grant_op mapping multicall being issued? If not, > > > > + * make sure it is called now. > > > > + */ > > > > + if (map_op->handle == -1) > > > > + xen_mc_flush(); > > > > > > How do you trigger this case? The mapping looks to be set by "gntdev_add_map" > > > which is happening right after in gntdev_alloc_map.. > > > > > > If it had failed from the gntdev_alloc_map to gntdev_add_map this page would > > > have never been used in the m2p as we would not have provided the proper > > > op.index value to the user. Which mean that the user could not have mmaped > > > and gotten to this code. > > > > The problem is that all the grant table mappings are done through > > multicalls now, and we are not really sure when the multicall is going > > to be actually issued. > > It might be that we queued all the m2p grant table hypercalls in a > > multicall, then m2p_remove_override gets called before the multicall has > > actually been issued. In this case handle is going to -1 because it hasn't > > been modified yet. > > Aaaah. Can you add that in the comment? > > /* > It might be that we queued all the m2p grant table hypercalls in a > multicall, then m2p_remove_override gets called before the multicall has > actually been issued. In this case handle is going to -1 because it hasn't > been modifuied yet. > */ > Done. > > This is the case we are trying to handle here. > > > > > > > > + if (map_op->handle == -1) { > > > > > > The other one I can understand, but this one I am baffled by. How > > > would the xen_mc_flush trigger the handle to be set to -1? > > > > > > Is the hypercall writting that value in the op.handle after it has completed? > > > > Yes. The hypercall might return -1 in the handle in case of errors. > > Which is GNTST_general_error? How about we check against that instead > of using -1? OK. > > > > @@ -243,10 +248,30 @@ static int map_grant_pages(struct grant_map *map) > > > > gnttab_set_unmap_op(&map->unmap_ops[i], addr, > > > > map->flags, -1 /* handle */); > > > > } > > > > + } else { > > > > + for (i = 0; i < map->count; i++) { > > > > + unsigned level; > > > > + unsigned long address = (unsigned long) > > > > + pfn_to_kaddr(page_to_pfn(map->pages[i])); > > > > + pte_t *ptep; > > > > + u64 pte_maddr = 0; > > > > + if (!PageHighMem(map->pages[i])) { > > > > + ptep = lookup_address(address, &level); > > > > + pte_maddr = > > > > + arbitrary_virt_to_machine(ptep).maddr; > > > > + } > > > > > > And it looks like having kmap->ops.host_addr = 0 is valid > > > so that is good on the chance it is high map... but that begs > > > the question whether we should the hypercall at all? > > > As in, can we do anything with the grants if there is no PTE > > > or MFN associated with it - just the handle? Does Xen do something > > > special - like a relaxed "oh ok, we can handle that later on" ? > > > > map->pages[i] cannot be highmap pages anymore, thanks to the previous > > patch that changes alloc_xenballooned_pages. > > We could even remove the if (!PageHighMem(map->pages[i])) at this > > point... > > Ok. And perhaps replace it with BUG_ON just in case? Good idea. > > > > + gnttab_set_map_op(&map->kmap_ops[i], pte_maddr, > > > > + map->flags | > > > > + GNTMAP_host_map | > > > > + GNTMAP_contains_pte, > > > > + map->grants[i].ref, > > > > + map->grants[i].domid); > > > > + } > > > > > > So, on startup.. (before this function is called) the > > > find_grant_ptes is called which pretty much does the exact thing for > > > each virtual address. Except its flags are GNTMAP_application_map > > > instead of GNTMAP_host_map. > > > > > > It even uses the same type structure.. It fills out map_ops[i] one. > > > > > > Can we use that instead of adding a new structure? > > > > Do you mean moving this code inside find_grant_ptes? > > I don't think that can be done because find_grant_ptes is called on a > > range of virtual addresses while this is called on an array of struct > > pages. It is true that the current implementation of > > But aren't that 'range of virtual address' of struct pages? You > are using 'alloc_xenballooned_pages' to get those pages and that is > what the 'range of virtual adresses' is walking through. it is not the same range of virtual addresses > > alloc_xenballooned_pages is going to return a consecutive set of pages > > but it might not always be the case. > > I am sensing some grand plans in work here? I thought we are going to > try to simply our lives and see about making alloc_xenballooned_pages > returned sane pages that are !PageHighMem (or if they are PageHighMem they > are already pinned, and set in the &init_mm)? > > I am just thinking in terms of lookup_address and arbitrary_virt_to_machine > calls being done _twice_. And it seems like we have the find_grant_ptes > which does the bulk of this already - so why not piggyback on it? It has to be done twice: once for the user ptes and once for the kernel mappings of map->pages. > Besides that, the patch set looks fine. .. How do I reproduce the failures > you had encountered with the AIO? > Just setup and use upstream qemu and configure your VM to use a disk on a file (file:). _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel From xen-devel-bounces@lists.xensource.com Tue Sep 27 08:57:13 2011 Return-path: <xen-devel-bounces@lists.xensource.com> Envelope-to: www-data@lists.xensource.com Delivery-date: Tue, 27 Sep 2011 08:57:13 -0700 Received: from localhost ([127.0.0.1] helo=lists.colo.xensource.com) by lists.xensource.com with esmtp (Exim 4.43) id 1R8a1w-00019n-Op; Tue, 27 Sep 2011 08:57:12 -0700 Received: from mail216.messagelabs.com ([85.158.143.99]) by lists.xensource.com with esmtp (Exim 4.43) id 1R8a10-0000wT-3P for xen-devel@lists.xensource.com; Tue, 27 Sep 2011 08:56:14 -0700 X-Env-Sender: david.vrabel@citrix.com X-Msg-Ref: server-2.tower-216.messagelabs.com!1317138969!19353615!1 X-Originating-IP: [66.165.176.89] X-StarScan-Version: 6.4.1; banners=-,-,- X-VirusChecked: Checked Received: (qmail 1466 invoked from network); 27 Sep 2011 15:56:10 -0000 Received: from smtp.citrix.com (HELO SMTP.CITRIX.COM) (66.165.176.89) by server-2.tower-216.messagelabs.com with RC4-SHA encrypted SMTP; 27 Sep 2011 15:56:10 -0000 X-IronPort-AV: E=Sophos;i="4.68,449,1312171200"; d="scan'208";a="17733963" Received: from ftlpmailmx02.citrite.net ([10.13.107.66]) by FTLPIPO01.CITRIX.COM with ESMTP/TLS/RC4-MD5; 27 Sep 2011 11:56:09 -0400 Received: from [10.80.2.76] (10.80.2.76) by FTLPMAILMX02.citrite.net (10.13.107.66) with Microsoft SMTP Server id 8.3.137.0; Tue, 27 Sep 2011 11:56:09 -0400 Message-ID: <4E81F278.5040107@citrix.com> Date: Tue, 27 Sep 2011 16:57:44 +0100 From: David Vrabel <david.vrabel@citrix.com> User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.1.16) Gecko/20110818 Icedove/3.0.11 MIME-Version: 1.0 To: Dan Magenheimer <dan.magenheimer@oracle.com> References: <2de59b55-4ecc-4155-8709-f8b0f5e012bc@default> In-Reply-To: <2de59b55-4ecc-4155-8709-f8b0f5e012bc@default> Content-Type: text/plain; charset="ISO-8859-1" Content-Transfer-Encoding: 7bit Cc: Jeremy Fitzhardinge <jeremy@goop.org>, "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>, "linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>, Konrad Wilk <konrad.wilk@oracle.com> Subject: [Xen-devel] Re: [PATCH v2] xen: Fix selfballooning and ensure it doesn't go too far X-BeenThere: xen-devel@lists.xensource.com X-Mailman-Version: 2.1.5 Precedence: list List-Id: Xen developer discussion <xen-devel.lists.xensource.com> List-Unsubscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe> List-Post: <mailto:xen-devel@lists.xensource.com> List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help> List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=subscribe> Sender: xen-devel-bounces@lists.xensource.com Errors-To: xen-devel-bounces@lists.xensource.com On 27/09/11 16:03, Dan Magenheimer wrote: > Note: This patch is also now in a git tree at: > > git://oss.oracle.com/git/djm/tmem.git#selfballoon-fix-v2 > > The balloon driver's "current_pages" is very different from > totalram_pages. Self-ballooning needs to be driven by > the latter. I don't think this part of the change makes any difference. It looks like it rearranges the maths without changing the end result (other than slightly increasing the rate of change). I think this (partial, untested) patch is equivalent: diff --git a/drivers/xen/xen-selfballoon.c b/drivers/xen/xen-selfballoon.c index 1b4afd8..b207e89 100644 --- a/drivers/xen/xen-selfballoon.c +++ b/drivers/xen/xen-selfballoon.c @@ -194,14 +194,15 @@ __setup("selfballooning", xen_selfballooning_setup); */ static void selfballoon_process(struct work_struct *work) { - unsigned long cur_pages, goal_pages, tgt_pages; + unsigned long cur_pages, goal_pages, tgt_pages, rsvd_pages, floor_pages; bool reset_timer = false; if (xen_selfballooning_enabled) { cur_pages = balloon_stats.current_pages; tgt_pages = cur_pages; /* default is no change */ - goal_pages = percpu_counter_read_positive(&vm_committed_as) + - balloon_stats.current_pages - totalram_pages; + rsvd_pages = cur_pages - totalram_pages; + goal_pages = percpu_counter_read_positive(&vm_committed_as) + + rsvd_pages; #ifdef CONFIG_FRONTSWAP /* allow space for frontswap pages to be repatriated */ if (frontswap_selfshrinking && frontswap_enabled) @@ -216,6 +217,11 @@ static void selfballoon_process(struct work_struct *work) ((goal_pages - cur_pages) / selfballoon_uphysteresis); /* else if cur_pages == goal_pages, no change */ + floor_pages = rsvd_pages + totalreserve_pages + + ((roundup_pow_of_two(max_pfn) / 128) * + selfballoon_safety_margin); + if (tgt_pages < floor_pages) + tgt_pages = floor_pages; balloon_set_new_target(tgt_pages); reset_timer = true; } > Also, Committed_AS doesn't account for pages > used by the kernel so enforce a floor for when there are little > or no user-space threads using memory. The floor function > includes a "safety margin" tuneable in case we discover later > that the floor function is still too aggressive in some workloads, > though likely it will not be needed. The sysfs file isn't documented (but then neither are any of the other (self-)balloon driver sysfs files). I don't think "safety_margin" is the right name. Perhaps, "min_reservation_ratio" or something like that? David > Changes since version 1: > - tuneable safety margin added > > [v2: konrad.wilk@oracle.com: make safety margin tuneable] > > Signed-off-by: Dan Magenheimer <dan.magenheimer@oracle.com> > > diff --git a/drivers/xen/xen-selfballoon.c b/drivers/xen/xen-selfballoon.c > index 6ea852e..ceaada6 100644 > --- a/drivers/xen/xen-selfballoon.c > +++ b/drivers/xen/xen-selfballoon.c > @@ -93,6 +93,12 @@ static unsigned int selfballoon_uphysteresis __read_mostly = 1; > /* In HZ, controls frequency of worker invocation. */ > static unsigned int selfballoon_interval __read_mostly = 5; > > +/* > + * Scale factor for safety margin for minimum selfballooning target for balloon. > + * Default adds about 3% (4/128) of max_pfn. > + */ > +static unsigned int selfballoon_safety_margin = 4; > + > static void selfballoon_process(struct work_struct *work); > static DECLARE_DELAYED_WORK(selfballoon_worker, selfballoon_process); > > @@ -195,14 +201,13 @@ __setup("selfballooning", xen_selfballooning_setup); > */ > static void selfballoon_process(struct work_struct *work) > { > - unsigned long cur_pages, goal_pages, tgt_pages; > + unsigned long cur_pages, goal_pages, tgt_pages, floor_pages; > bool reset_timer = false; > > if (xen_selfballooning_enabled) { > - cur_pages = balloon_stats.current_pages; > + cur_pages = totalram_pages; > tgt_pages = cur_pages; /* default is no change */ > - goal_pages = percpu_counter_read_positive(&vm_committed_as) + > - balloon_stats.current_pages - totalram_pages; > + goal_pages = percpu_counter_read_positive(&vm_committed_as); > #ifdef CONFIG_FRONTSWAP > /* allow space for frontswap pages to be repatriated */ > if (frontswap_selfshrinking && frontswap_enabled) > @@ -217,7 +222,13 @@ static void selfballoon_process(struct work_struct *work) > ((goal_pages - cur_pages) / > selfballoon_uphysteresis); > /* else if cur_pages == goal_pages, no change */ > - balloon_set_new_target(tgt_pages); > + floor_pages = totalreserve_pages + > + ((roundup_pow_of_two(max_pfn) / 128) * > + selfballoon_safety_margin); > + if (tgt_pages < floor_pages) > + tgt_pages = floor_pages; > + balloon_set_new_target(tgt_pages + > + balloon_stats.current_pages - totalram_pages); > reset_timer = true; > } > #ifdef CONFIG_FRONTSWAP > @@ -340,6 +351,30 @@ static ssize_t store_selfballoon_uphys(struct sys_device *dev, > static SYSDEV_ATTR(selfballoon_uphysteresis, S_IRUGO | S_IWUSR, > show_selfballoon_uphys, store_selfballoon_uphys); > > +SELFBALLOON_SHOW(selfballoon_safety_margin, "%d\n", selfballoon_safety_margin); > + > +static ssize_t store_selfballoon_safety_margin(struct sys_device *dev, > + struct sysdev_attribute *attr, > + const char *buf, > + size_t count) > +{ > + unsigned long val; > + int err; > + > + if (!capable(CAP_SYS_ADMIN)) > + return -EPERM; > + err = strict_strtoul(buf, 10, &val); > + if (err || val == 0 || val > 128) > + return -EINVAL; > + selfballoon_safety_margin = val; > + return count; > +} > + > +static SYSDEV_ATTR(selfballoon_safety_margin, S_IRUGO | S_IWUSR, > + show_selfballoon_safety_margin, > + store_selfballoon_safety_margin); > + > + > #ifdef CONFIG_FRONTSWAP > SELFBALLOON_SHOW(frontswap_selfshrinking, "%d\n", frontswap_selfshrinking); > > @@ -421,6 +456,7 @@ static struct attribute *selfballoon_attrs[] = { > &attr_selfballoon_interval.attr, > &attr_selfballoon_downhysteresis.attr, > &attr_selfballoon_uphysteresis.attr, > + &attr_selfballoon_safety_margin.attr, > #ifdef CONFIG_FRONTSWAP > &attr_frontswap_selfshrinking.attr, > &attr_frontswap_hysteresis.attr, _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel From xen-devel-bounces@lists.xensource.com Tue Sep 27 09:16:07 2011 Return-path: <xen-devel-bounces@lists.xensource.com> Envelope-to: www-data@lists.xensource.com Delivery-date: Tue, 27 Sep 2011 09:16:07 -0700 Received: from localhost ([127.0.0.1] helo=lists.colo.xensource.com) by lists.xensource.com with esmtp (Exim 4.43) id 1R8aKF-0001tu-3Q; Tue, 27 Sep 2011 09:16:07 -0700 Received: from mail27.messagelabs.com ([193.109.254.147]) by lists.xensource.com with esmtp (Exim 4.43) id 1R8aJQ-0001hQ-F7 for xen-devel@lists.xensource.com; Tue, 27 Sep 2011 09:15:16 -0700 X-Env-Sender: anthony.perard@gmail.com X-Msg-Ref: server-7.tower-27.messagelabs.com!1317140088!50391425!1 X-Originating-IP: [209.85.216.171] X-StarScan-Version: 6.4.1; banners=-,-,- X-VirusChecked: Checked Received: (qmail 24886 invoked from network); 27 Sep 2011 16:14:49 -0000 Received: from mail-qy0-f171.google.com (HELO mail-qy0-f171.google.com) (209.85.216.171) by server-7.tower-27.messagelabs.com with RC4-SHA encrypted SMTP; 27 Sep 2011 16:14:49 -0000 Received: by qyk29 with SMTP id 29so1251623qyk.9 for <xen-devel@lists.xensource.com>; Tue, 27 Sep 2011 09:15:12 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:sender:in-reply-to:references:from:date :x-google-sender-auth:message-id:subject:to:cc:content-type; bh=iupPC9MVJWpYyGb14fVDRPYGYZRXhGsrQ10VQjKib9Q=; b=Hq1bF3Yjm7lvXnFP2xwIZVRQjn9sFg9vwwUI4SXpujrQOsNX0wmLmtAt0ZYTW6Dx+j xty/BJkuoBXHPd3vTzzSHag6jeyfj5DFA/Y/hXpoUaDLJitNOnJaGdP+YQ4NEV2WjbbW 90GIMc/8WSagl2V2rO4sG8XOXftonhVoQTtqY= Received: by 10.224.193.1 with SMTP id ds1mr5761524qab.5.1317140112116; Tue, 27 Sep 2011 09:15:12 -0700 (PDT) MIME-Version: 1.0 Received: by 10.224.47.74 with HTTP; Tue, 27 Sep 2011 09:14:42 -0700 (PDT) In-Reply-To: <20110927152041.GB13889@redhat.com> References: <CAJJyHjK3ySHcHRC6eB2cPS=-=1JnqsWV4tXG0xDJgxpS2jG4=w@mail.gmail.com> <20110927152041.GB13889@redhat.com> From: Anthony PERARD <anthony.perard@citrix.com> Date: Tue, 27 Sep 2011 17:14:42 +0100 X-Google-Sender-Auth: 3b8tAyDLnVIAmcufs8jVTFQUI_I Message-ID: <CAJJyHj+9tcjCprpiEKZ6rS4K5WeJ8DqMskuswywvtDxJBBQK2w@mail.gmail.com> Subject: Re: [Xen-devel] Re: Try to integrate the Xen PCI Passthrough code into linux: have pci_regs conflict with libpci. To: "Michael S. Tsirkin" <mst@redhat.com> Content-Type: text/plain; charset=UTF-8 Cc: Xen Devel <xen-devel@lists.xensource.com>, Stefano Stabellini <stefano.stabellini@eu.citrix.com>, Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>, QEMU-devel <qemu-devel@nongnu.org>, Alexander Graf <agraf@suse.de>, Alex Williamson <alex.williamson@redhat.com>, Anthony Liguori <anthony@codemonkey.ws> X-BeenThere: xen-devel@lists.xensource.com X-Mailman-Version: 2.1.5 Precedence: list List-Id: Xen developer discussion <xen-devel.lists.xensource.com> List-Unsubscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe> List-Post: <mailto:xen-devel@lists.xensource.com> List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help> List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=subscribe> Sender: xen-devel-bounces@lists.xensource.com Errors-To: xen-devel-bounces@lists.xensource.com On Tue, Sep 27, 2011 at 16:20, Michael S. Tsirkin <mst@redhat.com> wrote: > On Tue, Sep 27, 2011 at 04:02:23PM +0100, Anthony PERARD wrote: >> Hi, >> >> I'm trying to integrate the Xen PCI Passthrough code into Qemu. But we >> use libpci, and it's not friendly with pci_regs.h. >> >> So can I replace pci_regs by the libpci one? > > I prefer sticking to pci_regs in linux. Fair enough. >> Should I avoid to include both? (by having a "hook" the libpci functions) >> Or do you have any other suggestions? >> >> Thanks, >> Regards, > > Can you avoid libpci? It was very useful before sysfs, but > on modern systems there isn't much that it does. I was thinking to keep any compatibility with a *BSD system, but since there is one function that assume the existance of the sysfs, I will just "rewrote" the needed functions and remove the usage of libpci. Thanks, -- Anthony PERARD _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel From xen-devel-bounces@lists.xensource.com Tue Sep 27 09:21:13 2011 Return-path: <xen-devel-bounces@lists.xensource.com> Envelope-to: www-data@lists.xensource.com Delivery-date: Tue, 27 Sep 2011 09:21:13 -0700 Received: from localhost ([127.0.0.1] helo=lists.colo.xensource.com) by lists.xensource.com with esmtp (Exim 4.43) id 1R8aPA-0002La-9g; Tue, 27 Sep 2011 09:21:12 -0700 Received: from mail27.messagelabs.com ([193.109.254.147]) by lists.xensource.com with esmtp (Exim 4.43) id 1R8aOH-00028S-Hq for xen-devel@lists.xensource.com; Tue, 27 Sep 2011 09:20:17 -0700 X-Env-Sender: dan.magenheimer@oracle.com X-Msg-Ref: server-14.tower-27.messagelabs.com!1317140397!37873504!1 X-Originating-IP: [141.146.126.227] X-StarScan-Version: 6.4.1; banners=-,-,- X-VirusChecked: Checked Received: (qmail 7370 invoked from network); 27 Sep 2011 16:19:59 -0000 Received: from acsinet15.oracle.com (HELO acsinet15.oracle.com) (141.146.126.227) by server-14.tower-27.messagelabs.com with DHE-RSA-AES256-SHA encrypted SMTP; 27 Sep 2011 16:19:59 -0000 Received: from rtcsinet21.oracle.com (rtcsinet21.oracle.com [66.248.204.29]) by acsinet15.oracle.com (Switch-3.4.4/Switch-3.4.4) with ESMTP id p8RGK71E025543 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Tue, 27 Sep 2011 16:20:09 GMT Received: from acsmt358.oracle.com (acsmt358.oracle.com [141.146.40.158]) by rtcsinet21.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id p8RGK57u002471 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 27 Sep 2011 16:20:06 GMT Received: from abhmt101.oracle.com (abhmt101.oracle.com [141.146.116.53]) by acsmt358.oracle.com (8.12.11.20060308/8.12.11) with ESMTP id p8RGJwff020763; Tue, 27 Sep 2011 11:19:59 -0500 MIME-Version: 1.0 Message-ID: <f42e2a83-15f6-4767-a7df-8a23ceac239e@default> Date: Tue, 27 Sep 2011 09:19:37 -0700 (PDT) From: Dan Magenheimer <dan.magenheimer@oracle.com> To: David Vrabel <david.vrabel@citrix.com> References: <2de59b55-4ecc-4155-8709-f8b0f5e012bc@default 4E81F278.5040107@citrix.com> In-Reply-To: <4E81F278.5040107@citrix.com> X-Priority: 3 X-Mailer: Oracle Beehive Extensions for Outlook 2.0.1.4.1.0 (410211) [OL 12.0.6557.5001] Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable X-Source-IP: rtcsinet21.oracle.com [66.248.204.29] X-CT-RefId: str=0001.0A02020A.4E81F7BA.01CA,ss=1,re=0.000,fgs=0 Cc: Jeremy Fitzhardinge <jeremy@goop.org>, xen-devel@lists.xensource.com, linux-kernel@vger.kernel.org, Konrad Wilk <konrad.wilk@oracle.com> Subject: [Xen-devel] RE: [PATCH v2] xen: Fix selfballooning and ensure it doesn't go too far X-BeenThere: xen-devel@lists.xensource.com X-Mailman-Version: 2.1.5 Precedence: list List-Id: Xen developer discussion <xen-devel.lists.xensource.com> List-Unsubscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe> List-Post: <mailto:xen-devel@lists.xensource.com> List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help> List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=subscribe> Sender: xen-devel-bounces@lists.xensource.com Errors-To: xen-devel-bounces@lists.xensource.com > From: David Vrabel [mailto:david.vrabel@citrix.com] > Subject: Re: [PATCH v2] xen: Fix selfballooning and ensure it doesn't go = too far >=20 > On 27/09/11 16:03, Dan Magenheimer wrote: > > Note: This patch is also now in a git tree at: > > > > git://oss.oracle.com/git/djm/tmem.git#selfballoon-fix-v2 > > > > The balloon driver's "current_pages" is very different from > > totalram_pages. Self-ballooning needs to be driven by > > the latter. Hi David -- Thanks for the feedback! =20 > I don't think this part of the change makes any difference. It looks like= it > rearranges the maths without changing the end result (other than > slightly increasing the rate of change). > I think this (partial, untested) patch is equivalent: Actually it does. The key difference is the parameter to the call to balloon_set_new_target. The math in my patch is done in "internal" math (e.g. kernel-relevant variables) and the math in your patch is done in "external" math (e.g. Xen-relevant variables). Balloon_set_new_target requires "external" math, so I convert at the point of call. =20 > The sysfs file isn't documented (but then neither are any of the other > (self-)balloon driver sysfs files). Yep. This is a bug fix, so I'm not trying to fix all the sins of others (and myself). Since you are familiar with the meaning of all the core balloon driver variables exposed through sysfs, perhaps you might submit a patch to document them and/or suggest which ones should be in debugfs instead? =20 > I don't think "safety_margin" is the right name. Perhaps, > "min_reservation_ratio" or something like that? Yeah, I struggled with the name because the concept that the variable implements is pretty complex. I finally decided on safety_margin because I think it will draw the attention of a user who has reason to look for it. I don't expect that it will be used anyway, but it is there in case I am wrong. _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel From xen-devel-bounces@lists.xensource.com Tue Sep 27 09:28:23 2011 Return-path: <xen-devel-bounces@lists.xensource.com> Envelope-to: www-data@lists.xensource.com Delivery-date: Tue, 27 Sep 2011 09:28:23 -0700 Received: from localhost ([127.0.0.1] helo=lists.colo.xensource.com) by lists.xensource.com with esmtp (Exim 4.43) id 1R8aW7-0002ow-El; Tue, 27 Sep 2011 09:28:23 -0700 Received: from mail21.messagelabs.com ([85.158.143.35]) by lists.xensource.com with esmtp (Exim 4.43) id 1R8aVg-0002c9-GF for xen-devel@lists.xensource.com; Tue, 27 Sep 2011 09:27:56 -0700 X-Env-Sender: Ian.Jackson@eu.citrix.com X-Msg-Ref: server-2.tower-21.messagelabs.com!1317140871!35715245!1 X-Originating-IP: [62.200.22.115] X-StarScan-Version: 6.4.1; banners=-,-,- X-VirusChecked: Checked Received: (qmail 4676 invoked from network); 27 Sep 2011 16:27:51 -0000 Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115) by server-2.tower-21.messagelabs.com with RC4-SHA encrypted SMTP; 27 Sep 2011 16:27:51 -0000 X-IronPort-AV: E=Sophos;i="4.68,450,1312156800"; d="scan'208";a="8088399" Received: from lonpmailmx01.citrite.net ([10.30.203.162]) by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5; 27 Sep 2011 16:27:48 +0000 Received: from norwich.cam.xci-test.com (10.80.248.129) by smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id 8.3.137.0; Tue, 27 Sep 2011 17:27:48 +0100 Received: from mariner.cam.xci-test.com ([10.80.2.22] helo=mariner.uk.xensource.com ident=Debian-exim) by norwich.cam.xci-test.com with esmtp (Exim 4.72) (envelope-from <Ian.Jackson@eu.citrix.com>) id 1R8aVY-0005PD-4a; Tue, 27 Sep 2011 16:27:48 +0000 Received: from iwj by mariner.uk.xensource.com with local (Exim 4.69) (envelope-from <Ian.Jackson@eu.citrix.com>) id 1R8aVY-0006Kp-3Q; Tue, 27 Sep 2011 17:27:48 +0100 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Message-ID: <20097.63876.95514.433411@mariner.uk.xensource.com> Date: Tue, 27 Sep 2011 17:27:48 +0100 To: Marek Marczykowski <marmarek@mimuw.edu.pl> Subject: [Xen-devel] Re: [PATCH] libxl: fix double free at get_all_assigned_devices [and 1 more messages] Newsgroups: chiark.mail.xen.devel In-Reply-To: <4E63F630.5090607@mimuw.edu.pl>, <4683409fac3d4fef836c.1315173032@devel14> References: <4683409fac3d4fef836c.1315173032@devel14> <4E63F630.5090607@mimuw.edu.pl> X-Mailer: VM 8.0.9 under Emacs 21.4.1 (i486-pc-linux-gnu) From: Ian Jackson <Ian.Jackson@eu.citrix.com> Cc: xen-devel@lists.xensource.com X-BeenThere: xen-devel@lists.xensource.com X-Mailman-Version: 2.1.5 Precedence: list List-Id: Xen developer discussion <xen-devel.lists.xensource.com> List-Unsubscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe> List-Post: <mailto:xen-devel@lists.xensource.com> List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help> List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=subscribe> Sender: xen-devel-bounces@lists.xensource.com Errors-To: xen-devel-bounces@lists.xensource.com Marek Marczykowski writes ("[Xen-devel] Re: [PATCH] libxl: fix double free at get_all_assigned_devices"): > On 04.09.2011 23:50, Marek Marczykowski wrote: > > libxl: fix double free at get_all_assigned_devices > > > > Do not free() list manually - it will be freed by libxl__free_all. > > > > Signed-off-by: Marek Marczykowski <marmarek@mimuw.edu.pl> > > Ah, it is for xen-4.1. In unstable seems to be ok. Acked and applied to 4.1, thanks. Ian. _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel From xen-devel-bounces@lists.xensource.com Tue Sep 27 09:32:58 2011 Return-path: <xen-devel-bounces@lists.xensource.com> Envelope-to: www-data@lists.xensource.com Delivery-date: Tue, 27 Sep 2011 09:32:58 -0700 Received: from localhost ([127.0.0.1] helo=lists.colo.xensource.com) by lists.xensource.com with esmtp (Exim 4.43) id 1R8aaY-0003FE-Bx; Tue, 27 Sep 2011 09:32:58 -0700 Received: from mail174.messagelabs.com ([85.158.138.51]) by lists.xensource.com with esmtp (Exim 4.43) id 1R8aa2-00032g-JK for xen-devel@lists.xensource.com; Tue, 27 Sep 2011 09:32:26 -0700 X-Env-Sender: Ian.Jackson@eu.citrix.com X-Msg-Ref: server-5.tower-174.messagelabs.com!1317141143!29282080!1 X-Originating-IP: [62.200.22.115] X-StarScan-Version: 6.4.1; banners=-,-,- X-VirusChecked: Checked Received: (qmail 11140 invoked from network); 27 Sep 2011 16:32:23 -0000 Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115) by server-5.tower-174.messagelabs.com with RC4-SHA encrypted SMTP; 27 Sep 2011 16:32:23 -0000 X-IronPort-AV: E=Sophos;i="4.68,450,1312156800"; d="scan'208";a="8088481" Received: from lonpmailmx01.citrite.net ([10.30.203.162]) by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5; 27 Sep 2011 16:32:23 +0000 Received: from norwich.cam.xci-test.com (10.80.248.129) by smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id 8.3.137.0; Tue, 27 Sep 2011 17:32:23 +0100 Received: from mariner.cam.xci-test.com ([10.80.2.22] helo=mariner.uk.xensource.com ident=Debian-exim) by norwich.cam.xci-test.com with esmtp (Exim 4.72) (envelope-from <Ian.Jackson@eu.citrix.com>) id 1R8aZy-0005Qb-SR; Tue, 27 Sep 2011 16:32:22 +0000 Received: from iwj by mariner.uk.xensource.com with local (Exim 4.69) (envelope-from <Ian.Jackson@eu.citrix.com>) id 1R8aZy-0006ML-RS; Tue, 27 Sep 2011 17:32:22 +0100 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Message-ID: <20097.64150.841969.654047@mariner.uk.xensource.com> Date: Tue, 27 Sep 2011 17:32:22 +0100 To: Ian Campbell <ian.campbell@citrix.com> Subject: Re: [Xen-devel] [PATCH] xl: fixup "xl save" command line handling Newsgroups: chiark.mail.xen.devel In-Reply-To: <311080019e01809614da.1315922810@cosworth.uk.xensource.com> References: <311080019e01809614da.1315922810@cosworth.uk.xensource.com> X-Mailer: VM 8.0.9 under Emacs 21.4.1 (i486-pc-linux-gnu) From: Ian Jackson <Ian.Jackson@eu.citrix.com> Cc: xen-devel@lists.xensource.com X-BeenThere: xen-devel@lists.xensource.com X-Mailman-Version: 2.1.5 Precedence: list List-Id: Xen developer discussion <xen-devel.lists.xensource.com> List-Unsubscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe> List-Post: <mailto:xen-devel@lists.xensource.com> List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help> List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=subscribe> Sender: xen-devel-bounces@lists.xensource.com Errors-To: xen-devel-bounces@lists.xensource.com Ian Campbell writes ("[Xen-devel] [PATCH] xl: fixup "xl save" command line handling"): > # HG changeset patch > # User Ian Campbell <ian.campbell@citrix.com> > # Date 1315922772 -3600 > # Node ID 311080019e01809614dac0321b210ef1a9bbcb44 > # Parent 4309ff9535001bdca8db93a439edd86bb4c447cd > xl: fixup "xl save" command line handling. > > The save file paramter is required so ensure we have enough arguments. Right. > The config filename is optional so do not use argv[optind+3], which > may well happen to be NULL when the paramter is not present but > relying on that is pretty gross. It is guaranteed that argv[argc]==NULL but I agree that this part of the patch is a stylistic improvement. Acked-by: Ian Jackson <ian.jackson@eu.citrix.com> Committed-by: Ian Jackson <ian.jackson@eu.citrix.com> Ian. _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel From xen-devel-bounces@lists.xensource.com Tue Sep 27 09:34:10 2011 Return-path: <xen-devel-bounces@lists.xensource.com> Envelope-to: www-data@lists.xensource.com Delivery-date: Tue, 27 Sep 2011 09:34:10 -0700 Received: from localhost ([127.0.0.1] helo=lists.colo.xensource.com) by lists.xensource.com with esmtp (Exim 4.43) id 1R8abg-0003fO-S6; Tue, 27 Sep 2011 09:34:09 -0700 Received: from mail27.messagelabs.com ([193.109.254.147]) by lists.xensource.com with esmtp (Exim 4.43) id 1R8ab1-0003Q4-1d for xen-devel@lists.xensource.com; Tue, 27 Sep 2011 09:33:28 -0700 X-Env-Sender: Ian.Jackson@eu.citrix.com X-Msg-Ref: server-2.tower-27.messagelabs.com!1317141178!56689958!1 X-Originating-IP: [62.200.22.115] X-StarScan-Version: 6.4.1; banners=-,-,- X-VirusChecked: Checked Received: (qmail 3161 invoked from network); 27 Sep 2011 16:32:58 -0000 Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115) by server-2.tower-27.messagelabs.com with RC4-SHA encrypted SMTP; 27 Sep 2011 16:32:58 -0000 X-IronPort-AV: E=Sophos;i="4.68,450,1312156800"; d="scan'208";a="8088505" Received: from lonpmailmx01.citrite.net ([10.30.203.162]) by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5; 27 Sep 2011 16:33:23 +0000 Received: from woking.xci-test.com (10.80.248.135) by smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id 8.3.137.0; Tue, 27 Sep 2011 17:33:23 +0100 Received: from osstest by woking.xci-test.com with local (Exim 4.69) (envelope-from <ian.jackson@eu.citrix.com>) id 1R8aax-0004zk-GU; Tue, 27 Sep 2011 17:33:23 +0100 To: xen-devel@lists.xensource.com Message-ID: <osstest-9097-mainreport@xen.org> From: xen.org <ian.jackson@eu.citrix.com> Date: Tue, 27 Sep 2011 17:33:23 +0100 MIME-Version: 1.0 Content-Type: text/plain Cc: ian.jackson@eu.citrix.com Subject: [Xen-devel] [xen-unstable test] 9097: regressions - trouble: blocked/fail X-BeenThere: xen-devel@lists.xensource.com X-Mailman-Version: 2.1.5 Precedence: list List-Id: Xen developer discussion <xen-devel.lists.xensource.com> List-Unsubscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe> List-Post: <mailto:xen-devel@lists.xensource.com> List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help> List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=subscribe> Sender: xen-devel-bounces@lists.xensource.com Errors-To: xen-devel-bounces@lists.xensource.com flight 9097 xen-unstable real [real] http://www.chiark.greenend.org.uk/~xensrcts/logs/9097/ Regressions :-( Tests which did not succeed and are blocking: build-amd64 4 xen-build fail REGR. vs. 8995 build-i386-oldkern 4 xen-build fail REGR. vs. 8995 build-i386 4 xen-build fail REGR. vs. 8995 build-amd64-oldkern 4 xen-build fail REGR. vs. 8995 Tests which did not succeed, but are not blocking, including regressions (tests previously passed) regarded as allowable: test-amd64-amd64-xl-pcipt-intel 1 xen-build-check(1) blocked n/a test-amd64-i386-pv 1 xen-build-check(1) blocked n/a test-amd64-amd64-xl 1 xen-build-check(1) blocked n/a test-i386-i386-pv 1 xen-build-check(1) blocked n/a test-amd64-amd64-pv 1 xen-build-check(1) blocked n/a test-amd64-i386-xl-multivcpu 1 xen-build-check(1) blocked n/a test-amd64-i386-xl-credit2 1 xen-build-check(1) blocked n/a test-amd64-i386-xl 1 xen-build-check(1) blocked n/a test-amd64-i386-rhel6hvm-intel 1 xen-build-check(1) blocked n/a test-i386-i386-xl 1 xen-build-check(1) blocked n/a build-amd64-pvops 4 kernel-build fail like 8991 test-amd64-amd64-xl-sedf 1 xen-build-check(1) blocked n/a build-i386-pvops 4 kernel-build fail like 8991 test-i386-i386-xl-win 1 xen-build-check(1) blocked n/a test-i386-i386-pair 1 xen-build-check(1) blocked n/a test-amd64-i386-pair 1 xen-build-check(1) blocked n/a test-amd64-amd64-pair 1 xen-build-check(1) blocked n/a test-amd64-i386-xl-win-vcpus1 1 xen-build-check(1) blocked n/a test-i386-i386-win 1 xen-build-check(1) blocked n/a test-amd64-i386-win-vcpus1 1 xen-build-check(1) blocked n/a test-amd64-i386-rhel6hvm-amd 1 xen-build-check(1) blocked n/a test-amd64-amd64-win 1 xen-build-check(1) blocked n/a test-amd64-i386-win 1 xen-build-check(1) blocked n/a test-amd64-amd64-xl-win 1 xen-build-check(1) blocked n/a version targeted for testing: xen ade44be5b936 baseline version: xen a422e2a4451e ------------------------------------------------------------ People who touched revisions under test: Andreas Herrmann <herrmann.der.user@googlemail.com> Ian Campbell <ian.campbell@citrix.com> Ian Jackson <ian.jackson@eu.citrix.com> Jan Beulich <jbeulich@suse.com> Lasse Collin <lasse.collin@tukaani.org> Olaf Hering <olaf@aepfle.de> Paul Durrant <paul.durrant@citrix.com> Thomas Renninger <trenn@suse.de> Tim Deegan <tim@xen.org> ------------------------------------------------------------ jobs: build-amd64 fail build-i386 fail build-amd64-oldkern fail build-i386-oldkern fail build-amd64-pvops fail build-i386-pvops fail test-amd64-amd64-xl blocked test-amd64-i386-xl blocked test-i386-i386-xl blocked test-amd64-i386-rhel6hvm-amd blocked test-amd64-i386-xl-credit2 blocked test-amd64-amd64-xl-pcipt-intel blocked test-amd64-i386-rhel6hvm-intel blocked test-amd64-i386-xl-multivcpu blocked test-amd64-amd64-pair blocked test-amd64-i386-pair blocked test-i386-i386-pair blocked test-amd64-amd64-pv blocked test-amd64-i386-pv blocked test-i386-i386-pv blocked test-amd64-amd64-xl-sedf blocked test-amd64-i386-win-vcpus1 blocked test-amd64-i386-xl-win-vcpus1 blocked test-amd64-amd64-win blocked test-amd64-i386-win blocked test-i386-i386-win blocked test-amd64-amd64-xl-win blocked test-i386-i386-xl-win blocked ------------------------------------------------------------ sg-report-flight on woking.cam.xci-test.com logs: /home/xc_osstest/logs images: /home/xc_osstest/images Logs, config files, etc. are available at http://www.chiark.greenend.org.uk/~xensrcts/logs Test harness code can be found at http://xenbits.xensource.com/gitweb?p=osstest.git;a=summary Not pushing. ------------------------------------------------------------ changeset: 23875:ade44be5b936 tag: tip user: Jan Beulich <jbeulich@suse.com> date: Tue Sep 27 16:15:09 2011 +0100 AMD-IOMMU: fix initialization order (after 23863:9e0259239822) That original patch caused alloc_ivrs_mappings() to be called too early, so things get moved back to where they were, just converting the single call there to a loop over all IOMMUs. Signed-off-by: Jan Beulich <jbeulich@suse.com> changeset: 23874:651aed73b39c user: Olaf Hering <olafiaepfle.de> date: Mon Sep 26 22:19:42 2011 +0100 xenpaging: track number of paged pages in struct domain The toolstack should know how many pages are paged-out at a given point in time so it could make smarter decisions about how many pages should be paged or ballooned. Add a new member to xen_domctl_getdomaininfo and bump interface version. Use the new member in xc_dominfo_t. The SONAME of libxc should be changed if this patch gets applied. Signed-off-by: Olaf Hering <olaf@aepfle.de> Acked-by: Ian Campbell <ian.campbell@citrix.com> Acked-by: Tim Deegan <tim@xen.org> Committed-by: Tim Deegan <tim@xen.org> changeset: 23873:fef59e4eaf8d user: Paul Durrant <paul.durrant@citrix.com> date: Mon Sep 26 22:10:21 2011 +0100 Add save/restore support for viridian APIC assist pfn. c/s 17b754cab7b0 introduced a per-VCPU viridian structure to store the APIC assist pfn. This patch adds support for save and restore of that value. Signed-off-by: Paul Durrant <paul.durrant@citrix.com> Acked-by: Tim Deegan <tim@xen.org> Committed-by: Tim Deegan <tim@xen.org> changeset: 23872:cc339ab1d917 user: Ian Campbell <ian.campbell@citrix.com> date: Thu Sep 22 18:37:06 2011 +0100 tools: fix install of lomount $(BIN) went away in 23124:e3d4c34b14a3. Also there are no *.so, *.a or *.rpm built in here Signed-off-by: Ian Campbell <ian.campbell@citrix.com> changeset: 23871:503ee256fecf user: Jan Beulich <jbeulich@suse.com> date: Thu Sep 22 18:35:30 2011 +0100 x86: ucode-amd: Don't warn when no ucode is available for a CPU revision This patch originally comes from the Linus mainline kernel (2.6.33), find below the patch details: From: Andreas Herrmann <herrmann.der.user@googlemail.com> There is no point in warning when there is no ucode available for a specific CPU revision. Currently the container-file, which provides the AMD ucode patches for OS load, contains only a few ucode patches. It's already clearly indicated by the printed patch_level whenever new ucode was available and an update happened. So the warning message is of no help but rather annoying on systems with many CPUs. Signed-off-by: Thomas Renninger <trenn@suse.de> Signed-off-by: Jan Beulich <jbeulich@suse.com> changeset: 23870:5c97b02f48fc user: Jan Beulich <jbeulich@suse.com> date: Thu Sep 22 18:34:27 2011 +0100 XZ: Fix incorrect XZ_BUF_ERROR From: Lasse Collin <lasse.collin@tukaani.org> xz_dec_run() could incorrectly return XZ_BUF_ERROR if all of the following was true: - The caller knows how many bytes of output to expect and only provides that much output space. - When the last output bytes are decoded, the caller-provided input buffer ends right before the LZMA2 end of payload marker. So LZMA2 won't provide more output anymore, but it won't know it yet and thus won't return XZ_STREAM_END yet. - A BCJ filter is in use and it hasn't left any unfiltered bytes in the temp buffer. This can happen with any BCJ filter, but in practice it's more likely with filters other than the x86 BCJ. This fixes <https://bugzilla.redhat.com/show_bug.cgi?id=3D735408> where Squashfs thinks that a valid file system is corrupt. This also fixes a similar bug in single-call mode where the uncompressed size of a block using BCJ + LZMA2 was 0 bytes and caller provided no output space. Many empty .xz files don't contain any blocks and thus don't trigger this bug. This also tweaks a closely related detail: xz_dec_bcj_run() could call xz_dec_lzma2_run() to decode into temp buffer when it was known to be useless. This was harmless although it wasted a minuscule number of CPU cycles. Signed-off-by: Lasse Collin <lasse.collin@tukaani.org> Signed-off-by: Jan Beulich <jbeulich@suse.com> changeset: 23869:db1ea4b127cd user: Jan Beulich <jbeulich@suse.com> date: Thu Sep 22 18:33:48 2011 +0100 XZ decompressor: Fix decoding of empty LZMA2 streams From: Lasse Collin <lasse.collin@tukaani.org> The old code considered valid empty LZMA2 streams to be corrupt. Note that a typical empty .xz file has no LZMA2 data at all, and thus most .xz files having no uncompressed data are handled correctly even without this fix. Signed-off-by: Lasse Collin <lasse.collin@tukaani.org> Signed-off-by: Jan Beulich <jbeulich@suse.com> changeset: 23868:28147fd781af user: Jan Beulich <jbeulich@suse.com> date: Thu Sep 22 18:32:34 2011 +0100 VT-d: fix off-by-one error in RMRR validation (base_addr,end_addr) is an inclusive range, and hence there shouldn't be a subtraction of 1 in the second invocation of page_is_ram_type(). For RMRRs covering a single page that actually resulted in the immediately preceding page to get checked (which could have resulted in a false warning). Signed-off-by: Jan Beulich <jbeulich@suse.com> changeset: 23867:571b6e90dfb4 user: Jan Beulich <jbeulich@suse.com> date: Thu Sep 22 18:31:44 2011 +0100 VT-d: eliminate a mis-use of pcidevs_lock dma_pte_clear_one() shouldn't acquire this global lock for the purpose of processing a per-domain list. Furthermore the function a few lines earlier has a comment stating that acquiring pcidevs_lock isn't necessary here (whether that's really correct is another question). Use the domain's mappin_lock instead to protect the mapped_rmrrs list. Fold domain_rmrr_mapped() into its sole caller so that the otherwise implicit dependency on pcidevs_lock there becomes more obvious (see the comment there). Signed-off-by: Jan Beulich <jbeulich@suse.com> changeset: 23866:47ec1d405af9 user: Jan Beulich <jbeulich@suse.com> date: Thu Sep 22 18:31:02 2011 +0100 x86: IO-APIC code has no dependency on PCI The IRQ handling code requires pcidevs_lock to be held only for MSI interrupts. As the handling of which was now fully moved into msi.c (i.e. while applying fine without, the patch needs to be applied after the one titled "x86: split MSI IRQ chip"), io_apic.c now also doesn't need to include PCI headers anymore. Signed-off-by: Jan Beulich <jbeulich@suse.com> changeset: 23865:d6e01c7853cf user: Jan Beulich <jbeulich@suse.com> date: Thu Sep 22 18:29:19 2011 +0100 PCI multi-seg: config space accessor adjustments Signed-off-by: Jan Beulich <jbeulich@suse.com> changeset: 23864:314b147d524d user: Jan Beulich <jbeulich@suse.com> date: Thu Sep 22 18:28:38 2011 +0100 PCI multi-seg: Pass-through adjustments Signed-off-by: Jan Beulich <jbeulich@suse.com> changeset: 23863:9e0259239822 user: Jan Beulich <jbeulich@suse.com> date: Thu Sep 22 18:28:03 2011 +0100 PCI multi-seg: AMD-IOMMU specific adjustments There are two places here where it is entirely unclear to me where the necessary PCI segment number should be taken from (as IVMD descriptors don't have such, only IVHD ones do). AMD confirmed that for the time being it is acceptable to imply that only segment 0 exists. Signed-off-by: Jan Beulich <jbeulich@suse.com> changeset: 23862:85418e168527 user: Jan Beulich <jbeulich@suse.com> date: Thu Sep 22 18:27:26 2011 +0100 PCI multi-seg: VT-d specific adjustments Signed-off-by: Jan Beulich <jbeulich@suse.com> changeset: 23861:ec7c81fbe0de user: Jan Beulich <jbeulich@suse.com> date: Thu Sep 22 18:26:54 2011 +0100 PCI multi-seg: adjust domctl interface Again, a couple of directly related functions at once get adjusted to account for the segment number. Signed-off-by: Jan Beulich <jbeulich@suse.com> changeset: 23860:a422e2a4451e user: Jan Beulich <jbeulich@suse.com> date: Sun Sep 18 00:26:52 2011 +0100 x86: split MSI IRQ chip With the .end() accessor having become optional and noting that several of the accessors' behavior really depends on the result of msi_maskable_irq(), the splits the MSI IRQ chip type into two - one for the maskable ones, and the other for the (MSI only) non-maskable ones. At once the implementation of those methods gets moved from io_apic.c to msi.c. Signed-off-by: Jan Beulich <jbeulich@suse.com> ======================================== commit cd776ee9408ff127f934a707c1a339ee600bc127 Author: Ian Jackson <ian.jackson@eu.citrix.com> Date: Tue Jun 28 13:50:53 2011 +0100 qemu-char.c: fix incorrect CONFIG_STUBDOM handling qemu-char.c:1123:7: warning: "CONFIG_STUBDOM" is not defined [-Wundef] Signed-off-by: Olaf Hering <olaf@aepfle.de> Acked-by: Ian Jackson <ian.jackson@eu.citrix.com> _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel From xen-devel-bounces@lists.xensource.com Tue Sep 27 09:36:55 2011 Return-path: <xen-devel-bounces@lists.xensource.com> Envelope-to: www-data@lists.xensource.com Delivery-date: Tue, 27 Sep 2011 09:36:55 -0700 Received: from localhost ([127.0.0.1] helo=lists.colo.xensource.com) by lists.xensource.com with esmtp (Exim 4.43) id 1R8aeN-0004EG-IN; Tue, 27 Sep 2011 09:36:55 -0700 Received: from mail27.messagelabs.com ([193.109.254.147]) by lists.xensource.com with esmtp (Exim 4.43) id 1R8adx-00040x-4S for xen-devel@lists.xensource.com; Tue, 27 Sep 2011 09:36:29 -0700 X-Env-Sender: Ian.Jackson@eu.citrix.com X-Msg-Ref: server-15.tower-27.messagelabs.com!1317141377!50505470!1 X-Originating-IP: [62.200.22.115] X-StarScan-Version: 6.4.1; banners=-,-,- X-VirusChecked: Checked Received: (qmail 28981 invoked from network); 27 Sep 2011 16:36:17 -0000 Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115) by server-15.tower-27.messagelabs.com with RC4-SHA encrypted SMTP; 27 Sep 2011 16:36:17 -0000 X-IronPort-AV: E=Sophos;i="4.68,450,1312156800"; d="scan'208";a="8088568" Received: from lonpmailmx01.citrite.net ([10.30.203.162]) by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5; 27 Sep 2011 16:36:26 +0000 Received: from norwich.cam.xci-test.com (10.80.248.129) by smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id 8.3.137.0; Tue, 27 Sep 2011 17:36:26 +0100 Received: from mariner.cam.xci-test.com ([10.80.2.22] helo=mariner.uk.xensource.com ident=Debian-exim) by norwich.cam.xci-test.com with esmtp (Exim 4.72) (envelope-from <Ian.Jackson@eu.citrix.com>) id 1R8adt-0005Rb-Qb; Tue, 27 Sep 2011 16:36:25 +0000 Received: from iwj by mariner.uk.xensource.com with local (Exim 4.69) (envelope-from <Ian.Jackson@eu.citrix.com>) id 1R8adt-0006NO-Pj; Tue, 27 Sep 2011 17:36:25 +0100 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Message-ID: <20097.64393.789130.768965@mariner.uk.xensource.com> Date: Tue, 27 Sep 2011 17:36:25 +0100 To: xen.org <ian.jackson@eu.citrix.com> In-Reply-To: <osstest-9097-mainreport@xen.org> References: <osstest-9097-mainreport@xen.org> X-Mailer: VM 8.0.9 under Emacs 21.4.1 (i486-pc-linux-gnu) From: Ian Jackson <Ian.Jackson@eu.citrix.com> Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com> Subject: [Xen-devel] Re: [xen-unstable test] 9097: regressions - trouble: blocked/fail X-BeenThere: xen-devel@lists.xensource.com X-Mailman-Version: 2.1.5 Precedence: list List-Id: Xen developer discussion <xen-devel.lists.xensource.com> List-Unsubscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe> List-Post: <mailto:xen-devel@lists.xensource.com> List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help> List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=subscribe> Sender: xen-devel-bounces@lists.xensource.com Errors-To: xen-devel-bounces@lists.xensource.com xen.org writes ("[xen-unstable test] 9097: regressions - trouble: blocked/fail"): > flight 9097 xen-unstable real [real] > http://www.chiark.greenend.org.uk/~xensrcts/logs/9097/ > > Regressions :-( > > Tests which did not succeed and are blocking: > build-amd64 4 xen-build fail REGR. vs. 8995 We're reorganising our trees a bit and this is fallout from that. Ian. _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel From xen-devel-bounces@lists.xensource.com Tue Sep 27 09:43:34 2011 Return-path: <xen-devel-bounces@lists.xensource.com> Envelope-to: www-data@lists.xensource.com Delivery-date: Tue, 27 Sep 2011 09:43:34 -0700 Received: from localhost ([127.0.0.1] helo=lists.colo.xensource.com) by lists.xensource.com with esmtp (Exim 4.43) id 1R8ako-0004sV-RG; Tue, 27 Sep 2011 09:43:34 -0700 Received: from mail21.messagelabs.com ([85.158.143.35]) by lists.xensource.com with esmtp (Exim 4.43) id 1R8akL-0004g8-8h for xen-devel@lists.xensource.com; Tue, 27 Sep 2011 09:43:06 -0700 X-Env-Sender: Ian.Jackson@eu.citrix.com X-Msg-Ref: server-12.tower-21.messagelabs.com!1317141766!51560116!1 X-Originating-IP: [62.200.22.115] X-StarScan-Version: 6.4.1; banners=-,-,- X-VirusChecked: Checked Received: (qmail 3074 invoked from network); 27 Sep 2011 16:42:46 -0000 Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115) by server-12.tower-21.messagelabs.com with RC4-SHA encrypted SMTP; 27 Sep 2011 16:42:46 -0000 X-IronPort-AV: E=Sophos;i="4.68,450,1312156800"; d="scan'208";a="8088692" Received: from lonpmailmx01.citrite.net ([10.30.203.162]) by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5; 27 Sep 2011 16:43:01 +0000 Received: from woking.xci-test.com (10.80.248.135) by smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id 8.3.137.0; Tue, 27 Sep 2011 17:43:01 +0100 Received: from osstest by woking.xci-test.com with local (Exim 4.69) (envelope-from <ian.jackson@eu.citrix.com>) id 1R8akH-0000Yc-7e; Tue, 27 Sep 2011 17:43:01 +0100 To: xen-devel@lists.xensource.com Message-ID: <osstest-9098-mainreport@xen.org> From: xen.org <ian.jackson@eu.citrix.com> Date: Tue, 27 Sep 2011 17:43:01 +0100 MIME-Version: 1.0 Content-Type: text/plain Cc: ian.jackson@eu.citrix.com Subject: [Xen-devel] [xen-unstable test] 9098: regressions - trouble: blocked/fail X-BeenThere: xen-devel@lists.xensource.com X-Mailman-Version: 2.1.5 Precedence: list List-Id: Xen developer discussion <xen-devel.lists.xensource.com> List-Unsubscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe> List-Post: <mailto:xen-devel@lists.xensource.com> List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help> List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=subscribe> Sender: xen-devel-bounces@lists.xensource.com Errors-To: xen-devel-bounces@lists.xensource.com flight 9098 xen-unstable real [real] http://www.chiark.greenend.org.uk/~xensrcts/logs/9098/ Regressions :-( Tests which did not succeed and are blocking: build-amd64 4 xen-build fail REGR. vs. 8995 build-i386-oldkern 4 xen-build fail REGR. vs. 8995 build-i386 4 xen-build fail REGR. vs. 8995 build-amd64-oldkern 4 xen-build fail REGR. vs. 8995 Tests which did not succeed, but are not blocking, including regressions (tests previously passed) regarded as allowable: test-amd64-amd64-xl-pcipt-intel 1 xen-build-check(1) blocked n/a test-amd64-i386-pv 1 xen-build-check(1) blocked n/a test-amd64-amd64-xl 1 xen-build-check(1) blocked n/a test-i386-i386-pv 1 xen-build-check(1) blocked n/a test-amd64-amd64-pv 1 xen-build-check(1) blocked n/a test-amd64-i386-xl-multivcpu 1 xen-build-check(1) blocked n/a test-amd64-i386-xl-credit2 1 xen-build-check(1) blocked n/a test-amd64-i386-xl 1 xen-build-check(1) blocked n/a test-amd64-i386-rhel6hvm-intel 1 xen-build-check(1) blocked n/a test-i386-i386-xl 1 xen-build-check(1) blocked n/a build-amd64-pvops 4 kernel-build fail like 8991 test-amd64-amd64-xl-sedf 1 xen-build-check(1) blocked n/a build-i386-pvops 4 kernel-build fail like 8991 test-i386-i386-xl-win 1 xen-build-check(1) blocked n/a test-i386-i386-pair 1 xen-build-check(1) blocked n/a test-amd64-i386-pair 1 xen-build-check(1) blocked n/a test-amd64-amd64-pair 1 xen-build-check(1) blocked n/a test-amd64-i386-xl-win-vcpus1 1 xen-build-check(1) blocked n/a test-i386-i386-win 1 xen-build-check(1) blocked n/a test-amd64-i386-win-vcpus1 1 xen-build-check(1) blocked n/a test-amd64-i386-rhel6hvm-amd 1 xen-build-check(1) blocked n/a test-amd64-amd64-win 1 xen-build-check(1) blocked n/a test-amd64-i386-win 1 xen-build-check(1) blocked n/a test-amd64-amd64-xl-win 1 xen-build-check(1) blocked n/a version targeted for testing: xen b113d626cfaf baseline version: xen a422e2a4451e ------------------------------------------------------------ People who touched revisions under test: Andreas Herrmann <herrmann.der.user@googlemail.com> Ian Campbell <ian.campbell@citrix.com> Ian Jackson <ian.jackson@eu.citrix.com> Jan Beulich <jbeulich@suse.com> Lasse Collin <lasse.collin@tukaani.org> Olaf Hering <olaf@aepfle.de> Paul Durrant <paul.durrant@citrix.com> Thomas Renninger <trenn@suse.de> Tim Deegan <tim@xen.org> ------------------------------------------------------------ jobs: build-amd64 fail build-i386 fail build-amd64-oldkern fail build-i386-oldkern fail build-amd64-pvops fail build-i386-pvops fail test-amd64-amd64-xl blocked test-amd64-i386-xl blocked test-i386-i386-xl blocked test-amd64-i386-rhel6hvm-amd blocked test-amd64-i386-xl-credit2 blocked test-amd64-amd64-xl-pcipt-intel blocked test-amd64-i386-rhel6hvm-intel blocked test-amd64-i386-xl-multivcpu blocked test-amd64-amd64-pair blocked test-amd64-i386-pair blocked test-i386-i386-pair blocked test-amd64-amd64-pv blocked test-amd64-i386-pv blocked test-i386-i386-pv blocked test-amd64-amd64-xl-sedf blocked test-amd64-i386-win-vcpus1 blocked test-amd64-i386-xl-win-vcpus1 blocked test-amd64-amd64-win blocked test-amd64-i386-win blocked test-i386-i386-win blocked test-amd64-amd64-xl-win blocked test-i386-i386-xl-win blocked ------------------------------------------------------------ sg-report-flight on woking.cam.xci-test.com logs: /home/xc_osstest/logs images: /home/xc_osstest/images Logs, config files, etc. are available at http://www.chiark.greenend.org.uk/~xensrcts/logs Test harness code can be found at http://xenbits.xensource.com/gitweb?p=osstest.git;a=summary Not pushing. ------------------------------------------------------------ changeset: 23876:b113d626cfaf tag: tip user: Ian Campbell <ian.campbell@citrix.com> date: Tue Sep 27 17:32:16 2011 +0100 xl: fixup "xl save" command line handling. The save file paramter is required so ensure we have enough arguments. The config filename is optional so do not use argv[optind+3], which may well happen to be NULL when the paramter is not present but relying on that is pretty gross. Signed-off-by: Ian Campbell <ian.campbell@citrix.com> Acked-by: Ian Jackson <ian.jackson@eu.citrix.com> Committed-by: Ian Jackson <ian.jackson@eu.citrix.com> changeset: 23875:ade44be5b936 user: Jan Beulich <jbeulich@suse.com> date: Tue Sep 27 16:15:09 2011 +0100 AMD-IOMMU: fix initialization order (after 23863:9e0259239822) That original patch caused alloc_ivrs_mappings() to be called too early, so things get moved back to where they were, just converting the single call there to a loop over all IOMMUs. Signed-off-by: Jan Beulich <jbeulich@suse.com> changeset: 23874:651aed73b39c user: Olaf Hering <olafiaepfle.de> date: Mon Sep 26 22:19:42 2011 +0100 xenpaging: track number of paged pages in struct domain The toolstack should know how many pages are paged-out at a given point in time so it could make smarter decisions about how many pages should be paged or ballooned. Add a new member to xen_domctl_getdomaininfo and bump interface version. Use the new member in xc_dominfo_t. The SONAME of libxc should be changed if this patch gets applied. Signed-off-by: Olaf Hering <olaf@aepfle.de> Acked-by: Ian Campbell <ian.campbell@citrix.com> Acked-by: Tim Deegan <tim@xen.org> Committed-by: Tim Deegan <tim@xen.org> changeset: 23873:fef59e4eaf8d user: Paul Durrant <paul.durrant@citrix.com> date: Mon Sep 26 22:10:21 2011 +0100 Add save/restore support for viridian APIC assist pfn. c/s 17b754cab7b0 introduced a per-VCPU viridian structure to store the APIC assist pfn. This patch adds support for save and restore of that value. Signed-off-by: Paul Durrant <paul.durrant@citrix.com> Acked-by: Tim Deegan <tim@xen.org> Committed-by: Tim Deegan <tim@xen.org> changeset: 23872:cc339ab1d917 user: Ian Campbell <ian.campbell@citrix.com> date: Thu Sep 22 18:37:06 2011 +0100 tools: fix install of lomount $(BIN) went away in 23124:e3d4c34b14a3. Also there are no *.so, *.a or *.rpm built in here Signed-off-by: Ian Campbell <ian.campbell@citrix.com> changeset: 23871:503ee256fecf user: Jan Beulich <jbeulich@suse.com> date: Thu Sep 22 18:35:30 2011 +0100 x86: ucode-amd: Don't warn when no ucode is available for a CPU revision This patch originally comes from the Linus mainline kernel (2.6.33), find below the patch details: From: Andreas Herrmann <herrmann.der.user@googlemail.com> There is no point in warning when there is no ucode available for a specific CPU revision. Currently the container-file, which provides the AMD ucode patches for OS load, contains only a few ucode patches. It's already clearly indicated by the printed patch_level whenever new ucode was available and an update happened. So the warning message is of no help but rather annoying on systems with many CPUs. Signed-off-by: Thomas Renninger <trenn@suse.de> Signed-off-by: Jan Beulich <jbeulich@suse.com> changeset: 23870:5c97b02f48fc user: Jan Beulich <jbeulich@suse.com> date: Thu Sep 22 18:34:27 2011 +0100 XZ: Fix incorrect XZ_BUF_ERROR From: Lasse Collin <lasse.collin@tukaani.org> xz_dec_run() could incorrectly return XZ_BUF_ERROR if all of the following was true: - The caller knows how many bytes of output to expect and only provides that much output space. - When the last output bytes are decoded, the caller-provided input buffer ends right before the LZMA2 end of payload marker. So LZMA2 won't provide more output anymore, but it won't know it yet and thus won't return XZ_STREAM_END yet. - A BCJ filter is in use and it hasn't left any unfiltered bytes in the temp buffer. This can happen with any BCJ filter, but in practice it's more likely with filters other than the x86 BCJ. This fixes <https://bugzilla.redhat.com/show_bug.cgi?id=3D735408> where Squashfs thinks that a valid file system is corrupt. This also fixes a similar bug in single-call mode where the uncompressed size of a block using BCJ + LZMA2 was 0 bytes and caller provided no output space. Many empty .xz files don't contain any blocks and thus don't trigger this bug. This also tweaks a closely related detail: xz_dec_bcj_run() could call xz_dec_lzma2_run() to decode into temp buffer when it was known to be useless. This was harmless although it wasted a minuscule number of CPU cycles. Signed-off-by: Lasse Collin <lasse.collin@tukaani.org> Signed-off-by: Jan Beulich <jbeulich@suse.com> changeset: 23869:db1ea4b127cd user: Jan Beulich <jbeulich@suse.com> date: Thu Sep 22 18:33:48 2011 +0100 XZ decompressor: Fix decoding of empty LZMA2 streams From: Lasse Collin <lasse.collin@tukaani.org> The old code considered valid empty LZMA2 streams to be corrupt. Note that a typical empty .xz file has no LZMA2 data at all, and thus most .xz files having no uncompressed data are handled correctly even without this fix. Signed-off-by: Lasse Collin <lasse.collin@tukaani.org> Signed-off-by: Jan Beulich <jbeulich@suse.com> changeset: 23868:28147fd781af user: Jan Beulich <jbeulich@suse.com> date: Thu Sep 22 18:32:34 2011 +0100 VT-d: fix off-by-one error in RMRR validation (base_addr,end_addr) is an inclusive range, and hence there shouldn't be a subtraction of 1 in the second invocation of page_is_ram_type(). For RMRRs covering a single page that actually resulted in the immediately preceding page to get checked (which could have resulted in a false warning). Signed-off-by: Jan Beulich <jbeulich@suse.com> changeset: 23867:571b6e90dfb4 user: Jan Beulich <jbeulich@suse.com> date: Thu Sep 22 18:31:44 2011 +0100 VT-d: eliminate a mis-use of pcidevs_lock dma_pte_clear_one() shouldn't acquire this global lock for the purpose of processing a per-domain list. Furthermore the function a few lines earlier has a comment stating that acquiring pcidevs_lock isn't necessary here (whether that's really correct is another question). Use the domain's mappin_lock instead to protect the mapped_rmrrs list. Fold domain_rmrr_mapped() into its sole caller so that the otherwise implicit dependency on pcidevs_lock there becomes more obvious (see the comment there). Signed-off-by: Jan Beulich <jbeulich@suse.com> changeset: 23866:47ec1d405af9 user: Jan Beulich <jbeulich@suse.com> date: Thu Sep 22 18:31:02 2011 +0100 x86: IO-APIC code has no dependency on PCI The IRQ handling code requires pcidevs_lock to be held only for MSI interrupts. As the handling of which was now fully moved into msi.c (i.e. while applying fine without, the patch needs to be applied after the one titled "x86: split MSI IRQ chip"), io_apic.c now also doesn't need to include PCI headers anymore. Signed-off-by: Jan Beulich <jbeulich@suse.com> changeset: 23865:d6e01c7853cf user: Jan Beulich <jbeulich@suse.com> date: Thu Sep 22 18:29:19 2011 +0100 PCI multi-seg: config space accessor adjustments Signed-off-by: Jan Beulich <jbeulich@suse.com> changeset: 23864:314b147d524d user: Jan Beulich <jbeulich@suse.com> date: Thu Sep 22 18:28:38 2011 +0100 PCI multi-seg: Pass-through adjustments Signed-off-by: Jan Beulich <jbeulich@suse.com> changeset: 23863:9e0259239822 user: Jan Beulich <jbeulich@suse.com> date: Thu Sep 22 18:28:03 2011 +0100 PCI multi-seg: AMD-IOMMU specific adjustments There are two places here where it is entirely unclear to me where the necessary PCI segment number should be taken from (as IVMD descriptors don't have such, only IVHD ones do). AMD confirmed that for the time being it is acceptable to imply that only segment 0 exists. Signed-off-by: Jan Beulich <jbeulich@suse.com> changeset: 23862:85418e168527 user: Jan Beulich <jbeulich@suse.com> date: Thu Sep 22 18:27:26 2011 +0100 PCI multi-seg: VT-d specific adjustments Signed-off-by: Jan Beulich <jbeulich@suse.com> changeset: 23861:ec7c81fbe0de user: Jan Beulich <jbeulich@suse.com> date: Thu Sep 22 18:26:54 2011 +0100 PCI multi-seg: adjust domctl interface Again, a couple of directly related functions at once get adjusted to account for the segment number. Signed-off-by: Jan Beulich <jbeulich@suse.com> changeset: 23860:a422e2a4451e user: Jan Beulich <jbeulich@suse.com> date: Sun Sep 18 00:26:52 2011 +0100 x86: split MSI IRQ chip With the .end() accessor having become optional and noting that several of the accessors' behavior really depends on the result of msi_maskable_irq(), the splits the MSI IRQ chip type into two - one for the maskable ones, and the other for the (MSI only) non-maskable ones. At once the implementation of those methods gets moved from io_apic.c to msi.c. Signed-off-by: Jan Beulich <jbeulich@suse.com> ======================================== commit cd776ee9408ff127f934a707c1a339ee600bc127 Author: Ian Jackson <ian.jackson@eu.citrix.com> Date: Tue Jun 28 13:50:53 2011 +0100 qemu-char.c: fix incorrect CONFIG_STUBDOM handling qemu-char.c:1123:7: warning: "CONFIG_STUBDOM" is not defined [-Wundef] Signed-off-by: Olaf Hering <olaf@aepfle.de> Acked-by: Ian Jackson <ian.jackson@eu.citrix.com> _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel From xen-devel-bounces@lists.xensource.com Tue Sep 27 09:44:41 2011 Return-path: <xen-devel-bounces@lists.xensource.com> Envelope-to: www-data@lists.xensource.com Delivery-date: Tue, 27 Sep 2011 09:44:41 -0700 Received: from localhost ([127.0.0.1] helo=lists.colo.xensource.com) by lists.xensource.com with esmtp (Exim 4.43) id 1R8alt-0005Fb-FF; Tue, 27 Sep 2011 09:44:41 -0700 Received: from mail21.messagelabs.com ([85.158.143.35]) by lists.xensource.com with esmtp (Exim 4.43) id 1R8alQ-00053S-Uh for xen-devel@lists.xensource.com; Tue, 27 Sep 2011 09:44:13 -0700 X-Env-Sender: jeremy@goop.org X-Msg-Ref: server-4.tower-21.messagelabs.com!1317141811!61835622!1 X-Originating-IP: [74.207.240.146] X-StarScan-Version: 6.4.1; banners=-,-,- X-VirusChecked: Checked Received: (qmail 24473 invoked from network); 27 Sep 2011 16:43:33 -0000 Received: from claw.goop.org (HELO claw.goop.org) (74.207.240.146) by server-4.tower-21.messagelabs.com with DHE-RSA-AES256-SHA encrypted SMTP; 27 Sep 2011 16:43:33 -0000 Received: from saboo.goop.org (unknown [206.29.182.153]) (Authenticated sender: smtp-saboo) by claw.goop.org (Postfix) with ESMTPSA id 1F7983F4; Tue, 27 Sep 2011 09:44:07 -0700 (PDT) Received: from saboo.goop.org (localhost [IPv6:::1]) by saboo.goop.org (Postfix) with ESMTP id EA43520868; Tue, 27 Sep 2011 09:44:02 -0700 (PDT) Message-ID: <4E81FD52.50106@goop.org> Date: Tue, 27 Sep 2011 09:44:02 -0700 From: Jeremy Fitzhardinge <jeremy@goop.org> User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:6.0.2) Gecko/20110906 Thunderbird/6.0.2 MIME-Version: 1.0 To: Stephan Diestelhorst <stephan.diestelhorst@amd.com> Subject: Re: [Xen-devel] [PATCH 00/10] [PATCH RFC V2] Paravirtualized ticketlocks References: <cover.1315878463.git.jeremy.fitzhardinge@citrix.com> <3300108.XQUp9Wrktc@chlor> In-Reply-To: <3300108.XQUp9Wrktc@chlor> X-Enigmail-Version: 1.3.2 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Cc: xen-devel@lists.xensource.com, Nick Piggin <npiggin@kernel.dk>, KVM <kvm@vger.kernel.org>, Peter Zijlstra <peterz@infradead.org>, Marcelo Tosatti <mtosatti@redhat.com>, the arch/x86 maintainers <x86@kernel.org>, Linux Kernel Mailing List <linux-kernel@vger.kernel.org>, Andi Kleen <andi@firstfloor.org>, Avi Kivity <avi@redhat.com>, Jeremy Fitzhardinge <jeremy.fitzhardinge@citrix.com>, "H. Peter Anvin" <hpa@zytor.com>, Ingo Molnar <mingo@elte.hu>, Linus Torvalds <torvalds@linux-foundation.org> X-BeenThere: xen-devel@lists.xensource.com X-Mailman-Version: 2.1.5 Precedence: list List-Id: Xen developer discussion <xen-devel.lists.xensource.com> List-Unsubscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe> List-Post: <mailto:xen-devel@lists.xensource.com> List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help> List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=subscribe> Sender: xen-devel-bounces@lists.xensource.com Errors-To: xen-devel-bounces@lists.xensource.com On 09/27/2011 02:34 AM, Stephan Diestelhorst wrote: > On Wednesday 14 September 2011, 17:31:32 Jeremy Fitzhardinge wrote: >> This series replaces the existing paravirtualized spinlock mechanism >> with a paravirtualized ticketlock mechanism. > [...] >> The unlock code is very straightforward: >> prev = *lock; >> __ticket_unlock_release(lock); >> if (unlikely(__ticket_in_slowpath(lock))) >> __ticket_unlock_slowpath(lock, prev); >> >> which generates: >> push %rbp >> mov %rsp,%rbp >> >> movzwl (%rdi),%esi >> addb $0x2,(%rdi) >> movzwl (%rdi),%eax >> testb $0x1,%ah >> jne 1f >> >> pop %rbp >> retq >> >> ### SLOWPATH START >> 1: movzwl (%rdi),%edx >> movzbl %dh,%ecx >> mov %edx,%eax >> and $-2,%ecx # clear TICKET_SLOWPATH_FLAG >> mov %cl,%dh >> cmp %dl,%cl # test to see if lock is uncontended >> je 3f >> >> 2: movzbl %dl,%esi >> callq *__ticket_unlock_kick # kick anyone waiting >> pop %rbp >> retq >> >> 3: lock cmpxchg %dx,(%rdi) # use cmpxchg to safely write back flag >> jmp 2b >> ### SLOWPATH END > [...] >> Thoughts? Comments? Suggestions? > You have a nasty data race in your code that can cause a losing > acquirer to sleep forever, because its setting the TICKET_SLOWPATH flag > can race with the lock holder releasing the lock. > > I used the code for the slow path from the GIT repo. > > Let me try to point out an interleaving: > > Lock is held by one thread, contains 0x0200. > > _Lock holder_ _Acquirer_ > mov $0x200,%eax > lock xadd %ax,(%rdi) > // ax:= 0x0200, lock:= 0x0400 > ... > // this guy spins for a while, reading > // the lock > ... > //trying to free the lock > movzwl (%rdi),%esi (esi:=0x0400) > addb $0x2,(%rdi) (LOCAL copy of lock is now: 0x0402) > movzwl (%rdi),%eax (local forwarding from previous store: eax := 0x0402) > testb $0x1,%ah (no wakeup of anybody) > jne 1f > > callq *__ticket_lock_spinning > ... > // __ticket_enter_slowpath(lock) > lock or (%rdi), $0x100 > // (global view of lock := 0x0500) > ... > ACCESS_ONCE(lock->tickets.head) == want > // (reads 0x00) > ... > xen_poll_irq(irq); // goes to sleep > ... > [addb $0x2,(%rdi)] > // (becomes globally visible only now! global view of lock := 0x0502) > ... > > Your code is reusing the (just about) safe version of unlocking a > spinlock without understanding the effect that close has on later > memory ordering. It may work on CPUs that cannot do narrow -> wide > store to load forwarding and have to make the addb store visible > globally. This is an implementation artifact of specific uarches, and > you mustn't rely on it, since our specified memory model allows looser > behaviour. Ah, thanks for this observation. I've seen this bug before when I didn't pay attention to the unlock W vs flag R ordering at all, and I was hoping the aliasing would be sufficient - and certainly this seems to have been OK on my Intel systems. But you're saying that it will fail on current AMD systems? Have you tested this, or is this just from code analysis (which I agree with after reviewing the ordering rules in the Intel manual). > Since you want to get that addb out to global memory before the second > read, either use a LOCK prefix for it, add an MFENCE between addb and > movzwl, or use a LOCKed instruction that will have a fencing effect > (e.g., to top-of-stack)between addb and movzwl. Hm. I don't really want to do any of those because it will probably have a significant effect on the unlock performance; I was really trying to avoid adding any more locked instructions. A previous version of the code had an mfence in here, but I hit on the idea of using aliasing to get the ordering I want - but overlooked the possible effect of store forwarding. I guess it comes down to throwing myself on the efficiency of some kind of fence instruction. I guess an lfence would be sufficient; is that any more efficient than a full mfence? At least I can make it so that its only present when pv ticket locks are actually in use, so it won't affect the native case. Could you give me a pointer to AMD's description of the ordering rules? Thanks, J _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel From xen-devel-bounces@lists.xensource.com Tue Sep 27 09:49:03 2011 Return-path: <xen-devel-bounces@lists.xensource.com> Envelope-to: www-data@lists.xensource.com Delivery-date: Tue, 27 Sep 2011 09:49:03 -0700 Received: from localhost ([127.0.0.1] helo=lists.colo.xensource.com) by lists.xensource.com with esmtp (Exim 4.43) id 1R8aq7-0005fe-54; Tue, 27 Sep 2011 09:49:03 -0700 Received: from mail182.messagelabs.com ([85.158.139.83]) by lists.xensource.com with esmtp (Exim 4.43) id 1R8ape-0005TA-2N for xen-devel@lists.xensource.com; Tue, 27 Sep 2011 09:48:34 -0700 X-Env-Sender: Ian.Jackson@eu.citrix.com X-Msg-Ref: server-9.tower-182.messagelabs.com!1317142110!19948356!1 X-Originating-IP: [62.200.22.115] X-StarScan-Version: 6.4.1; banners=-,-,- X-VirusChecked: Checked Received: (qmail 5586 invoked from network); 27 Sep 2011 16:48:30 -0000 Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115) by server-9.tower-182.messagelabs.com with RC4-SHA encrypted SMTP; 27 Sep 2011 16:48:30 -0000 X-IronPort-AV: E=Sophos;i="4.68,450,1312156800"; d="scan'208";a="8088848" Received: from lonpmailmx01.citrite.net ([10.30.203.162]) by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5; 27 Sep 2011 16:48:30 +0000 Received: from norwich.cam.xci-test.com (10.80.248.129) by smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id 8.3.137.0; Tue, 27 Sep 2011 17:48:30 +0100 Received: from mariner.cam.xci-test.com ([10.80.2.22] helo=mariner.uk.xensource.com ident=Debian-exim) by norwich.cam.xci-test.com with esmtp (Exim 4.72) (envelope-from <Ian.Jackson@eu.citrix.com>) id 1R8apa-0005UR-CQ; Tue, 27 Sep 2011 16:48:30 +0000 Received: from iwj by mariner.uk.xensource.com with local (Exim 4.69) (envelope-from <Ian.Jackson@eu.citrix.com>) id 1R8apa-0006OV-BY; Tue, 27 Sep 2011 17:48:30 +0100 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Message-ID: <20097.65118.350804.135806@mariner.uk.xensource.com> Date: Tue, 27 Sep 2011 17:48:30 +0100 To: Olaf Hering <olaf@aepfle.de> Subject: Re: [Xen-devel] [PATCH] xenpaging: libxl support Newsgroups: chiark.mail.xen.devel In-Reply-To: <c9a9779fd9581666c327.1316100011@probook.site> References: <c9a9779fd9581666c327.1316100011@probook.site> X-Mailer: VM 8.0.9 under Emacs 21.4.1 (i486-pc-linux-gnu) From: Ian Jackson <Ian.Jackson@eu.citrix.com> Cc: xen-devel@lists.xensource.com X-BeenThere: xen-devel@lists.xensource.com X-Mailman-Version: 2.1.5 Precedence: list List-Id: Xen developer discussion <xen-devel.lists.xensource.com> List-Unsubscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe> List-Post: <mailto:xen-devel@lists.xensource.com> List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help> List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=subscribe> Sender: xen-devel-bounces@lists.xensource.com Errors-To: xen-devel-bounces@lists.xensource.com Olaf Hering writes ("[Xen-devel] [PATCH] xenpaging: libxl support"): > The patch adds four new config options: > xenpaging=<int> , the number of pages to page-out ... > +libxl_xenpaging_info = Struct("xenpaging_info",[ > + ("xenpaging", integer, False, "number of pages"), ... > + if (!xlu_cfg_get_long (config, "xenpaging", &l)) > + xp_info->xenpaging = l; The config file setting should be a number of megabytes, just like "memory", "maxmem", etc., not a number of pages. And at the libxl interface it should be a number of kilobytes like max_memkb et al. Also as I said at the hackathon, I think that we need a more sophisticated approach to the interaction with ballooning. I would like to see the argument to the xenpaging daemon not be a target number of pages to page out, but rather for it to be a total memory usage target. The effect of this would be that you could tell a guest to balloon down, but also tell xenpaging to page it out, and balance between ballooning and paging is then up to the guest. > +static int libxl__create_xenpaging(libxl__gc *gc, char *dom_name, uint32_t domid, libxl_xenpaging_info *xp_info) > +{ > + [a lot of stuff] Can any of this be factored out and made common with the device model creation ? Also: - what deletes the logfile, if anything ? - will the xenpaging daemon automatically exit if the domain dies ? Ian. _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel From xen-devel-bounces@lists.xensource.com Tue Sep 27 09:51:28 2011 Return-path: <xen-devel-bounces@lists.xensource.com> Envelope-to: www-data@lists.xensource.com Delivery-date: Tue, 27 Sep 2011 09:51:28 -0700 Received: from localhost ([127.0.0.1] helo=lists.colo.xensource.com) by lists.xensource.com with esmtp (Exim 4.43) id 1R8asS-00068z-Lq; Tue, 27 Sep 2011 09:51:28 -0700 Received: from mail216.messagelabs.com ([85.158.143.99]) by lists.xensource.com with esmtp (Exim 4.43) id 1R8arz-0005wP-Qz for xen-devel@lists.xensource.com; Tue, 27 Sep 2011 09:51:00 -0700 X-Env-Sender: jeremy@goop.org X-Msg-Ref: server-2.tower-216.messagelabs.com!1317142255!19358665!1 X-Originating-IP: [74.207.240.146] X-StarScan-Version: 6.4.1; banners=-,-,- X-VirusChecked: Checked Received: (qmail 5523 invoked from network); 27 Sep 2011 16:50:56 -0000 Received: from claw.goop.org (HELO claw.goop.org) (74.207.240.146) by server-2.tower-216.messagelabs.com with DHE-RSA-AES256-SHA encrypted SMTP; 27 Sep 2011 16:50:56 -0000 Received: from saboo.goop.org (unknown [206.29.182.153]) (Authenticated sender: smtp-saboo) by claw.goop.org (Postfix) with ESMTPSA id 6DD59438; Tue, 27 Sep 2011 09:50:54 -0700 (PDT) Received: from saboo.goop.org (localhost [IPv6:::1]) by saboo.goop.org (Postfix) with ESMTP id CCAB9209D6; Tue, 27 Sep 2011 09:50:51 -0700 (PDT) Message-ID: <4E81FEEB.7040100@goop.org> Date: Tue, 27 Sep 2011 09:50:51 -0700 From: Jeremy Fitzhardinge <jeremy@goop.org> User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:6.0.2) Gecko/20110906 Thunderbird/6.0.2 MIME-Version: 1.0 To: Stefano Stabellini <stefano.stabellini@eu.citrix.com> References: <1316776753-10168-1-git-send-email-stefano.stabellini@eu.citrix.com> <4E7C9ADD.6010209@goop.org> <alpine.DEB.2.00.1109271544470.3519@kaball-desktop> In-Reply-To: <alpine.DEB.2.00.1109271544470.3519@kaball-desktop> X-Enigmail-Version: 1.3.2 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: Ian Campbell <Ian.Campbell@eu.citrix.com>, "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>, "konrad.wilk@oracle.com" <konrad.wilk@oracle.com> Subject: [Xen-devel] Re: [PATCH] xen: remove XEN_PLATFORM_PCI config option X-BeenThere: xen-devel@lists.xensource.com X-Mailman-Version: 2.1.5 Precedence: list List-Id: Xen developer discussion <xen-devel.lists.xensource.com> List-Unsubscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe> List-Post: <mailto:xen-devel@lists.xensource.com> List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help> List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=subscribe> Sender: xen-devel-bounces@lists.xensource.com Errors-To: xen-devel-bounces@lists.xensource.com On 09/27/2011 07:46 AM, Stefano Stabellini wrote: > On Fri, 23 Sep 2011, Jeremy Fitzhardinge wrote: >> On 09/23/2011 04:19 AM, stefano.stabellini@eu.citrix.com wrote: >>> From: Stefano Stabellini <stefano.stabellini@eu.citrix.com> >>> >>> Xen PVHVM needs xen-platform-pci, on the other hand xen-platform-pci is >>> useless in any other cases. >>> Therefore remove the XEN_PLATFORM_PCI config option and compile >>> xen-platform-pci built-in if XEN_PVHVM is selected. >> What happens if you disable CONFIG_PCI? >> >> I think XEN_PLATFORM_PCI still needs to exist, but just not user-visible. > What if we add CONFIG_PCI as a dependency of XEN_PVHVM? > > It is not like it is going to be useful to run a PV on HVM guest without > PV drivers. In principle you could have a domain with emulated ISA IDE and net but with PV time, etc. But yeah, not very useful in practice. I think making PVHVM depend on PCI is fine. J _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel From xen-devel-bounces@lists.xensource.com Tue Sep 27 09:56:38 2011 Return-path: <xen-devel-bounces@lists.xensource.com> Envelope-to: www-data@lists.xensource.com Delivery-date: Tue, 27 Sep 2011 09:56:38 -0700 Received: from localhost ([127.0.0.1] helo=lists.colo.xensource.com) by lists.xensource.com with esmtp (Exim 4.43) id 1R8axR-0006aN-Vj; Tue, 27 Sep 2011 09:56:38 -0700 Received: from mail21.messagelabs.com ([85.158.143.35]) by lists.xensource.com with esmtp (Exim 4.43) id 1R8ax4-0006OM-6e for xen-devel@lists.xensource.com; Tue, 27 Sep 2011 09:56:14 -0700 X-Env-Sender: Ian.Jackson@eu.citrix.com X-Msg-Ref: server-8.tower-21.messagelabs.com!1317142554!60594146!1 X-Originating-IP: [62.200.22.115] X-StarScan-Version: 6.4.1; banners=-,-,- X-VirusChecked: Checked Received: (qmail 5477 invoked from network); 27 Sep 2011 16:55:54 -0000 Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115) by server-8.tower-21.messagelabs.com with RC4-SHA encrypted SMTP; 27 Sep 2011 16:55:54 -0000 X-IronPort-AV: E=Sophos;i="4.68,450,1312156800"; d="scan'208";a="8088970" Received: from lonpmailmx01.citrite.net ([10.30.203.162]) by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5; 27 Sep 2011 16:55:56 +0000 Received: from woking.xci-test.com (10.80.248.135) by smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id 8.3.137.0; Tue, 27 Sep 2011 17:55:56 +0100 Received: from osstest by woking.xci-test.com with local (Exim 4.69) (envelope-from <ian.jackson@eu.citrix.com>) id 1R8awm-00028e-Dj; Tue, 27 Sep 2011 17:55:56 +0100 To: <xen-devel@lists.xensource.com> Message-ID: <osstest-9100-mainreport@xen.org> From: xen.org <ian.jackson@eu.citrix.com> Date: Tue, 27 Sep 2011 17:55:56 +0100 MIME-Version: 1.0 Content-Type: text/plain Cc: ian.jackson@eu.citrix.com Subject: [Xen-devel] [xen-4.1-testing test] 9100: regressions - trouble: blocked/fail/preparing/queued X-BeenThere: xen-devel@lists.xensource.com X-Mailman-Version: 2.1.5 Precedence: list List-Id: Xen developer discussion <xen-devel.lists.xensource.com> List-Unsubscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe> List-Post: <mailto:xen-devel@lists.xensource.com> List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help> List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=subscribe> Sender: xen-devel-bounces@lists.xensource.com Errors-To: xen-devel-bounces@lists.xensource.com flight 9100 xen-4.1-testing running [real] http://www.chiark.greenend.org.uk/~xensrcts/logs/9100/ Regressions :-( Tests which did not succeed and are blocking: test-amd64-i386-pv <none executed> queued test-amd64-i386-xl-credit2 <none executed> queued test-i386-i386-pv <none executed> queued test-i386-i386-xl <none executed> queued test-amd64-i386-xl <none executed> queued test-amd64-i386-rhel6hvm-amd <none executed> queued test-amd64-i386-xl-multivcpu <none executed> queued build-amd64 4 xen-build fail REGR. vs. 8992 build-amd64-oldkern 4 xen-build fail REGR. vs. 8992 test-amd64-i386-rhel6hvm-intel <none executed> queued build-i386-pvops 1 hosts-allocate running build-i386-oldkern 1 hosts-allocate running test-amd64-i386-pair <none executed> queued test-i386-i386-pair <none executed> queued test-amd64-i386-win-vcpus1 <none executed> queued build-i386 2 host-install(2) running build-amd64-pvops 4 kernel-build fail REGR. vs. 8992 test-amd64-i386-win <none executed> queued test-i386-i386-win <none executed> queued test-amd64-i386-xl-win-vcpus1 <none executed> queued test-i386-i386-xl-win <none executed> queued Tests which did not succeed, but are not blocking, including regressions (tests previously passed) regarded as allowable: test-amd64-amd64-pv 1 xen-build-check(1) blocked n/a test-amd64-amd64-xl 1 xen-build-check(1) blocked n/a test-amd64-amd64-xl-pcipt-intel 1 xen-build-check(1) blocked n/a test-amd64-amd64-xl-sedf 1 xen-build-check(1) blocked n/a test-amd64-amd64-pair 1 xen-build-check(1) blocked n/a test-amd64-amd64-xl-win 1 xen-build-check(1) blocked n/a test-amd64-amd64-win 1 xen-build-check(1) blocked n/a version targeted for testing: xen 5c395e993fe4 baseline version: xen 2112db7c68b3 ------------------------------------------------------------ People who touched revisions under test: Ian Campbell <ian.campbell@citrix.com> Ian Jackson <ian.jackson@eu.citrix.com> Marek Marczykowski <marmarek@mimuw.edu.pl> ------------------------------------------------------------ jobs: build-amd64 fail build-i386 preparing build-amd64-oldkern fail build-i386-oldkern preparing build-amd64-pvops fail build-i386-pvops preparing test-amd64-amd64-xl blocked test-amd64-i386-xl queued test-i386-i386-xl queued test-amd64-i386-rhel6hvm-amd queued test-amd64-i386-xl-credit2 queued test-amd64-amd64-xl-pcipt-intel blocked test-amd64-i386-rhel6hvm-intel queued test-amd64-i386-xl-multivcpu queued test-amd64-amd64-pair blocked test-amd64-i386-pair queued test-i386-i386-pair queued test-amd64-amd64-pv blocked test-amd64-i386-pv queued test-i386-i386-pv queued test-amd64-amd64-xl-sedf blocked test-amd64-i386-win-vcpus1 queued test-amd64-i386-xl-win-vcpus1 queued test-amd64-amd64-win blocked test-amd64-i386-win queued test-i386-i386-win queued test-amd64-amd64-xl-win blocked test-i386-i386-xl-win queued ------------------------------------------------------------ sg-report-flight on woking.cam.xci-test.com logs: /home/xc_osstest/logs images: /home/xc_osstest/images Logs, config files, etc. are available at http://www.chiark.greenend.org.uk/~xensrcts/logs Test harness code can be found at http://xenbits.xensource.com/gitweb?p=osstest.git;a=summary Not pushing. ------------------------------------------------------------ changeset: 23160:5c395e993fe4 tag: tip user: Marek Marczykowski <marmarek@mimuw.edu.pl> date: Tue Sep 27 17:27:17 2011 +0100 libxl: fix double free at get_all_assigned_devices Do not free() list manually - it will be freed by libxl__free_all. Signed-off-by: Marek Marczykowski <marmarek@mimuw.edu.pl> Acked-by: Ian Jackson <ian.jackson@eu.citrix.com> Committed-by: Ian Jackson <ian.jackson@eu.citrix.com> changeset: 23159:2112db7c68b3 user: Ian Campbell <ian.campbell@citrix.com> date: Wed Sep 21 17:12:58 2011 +0100 libxl: do not start a xenpv qemu solely for tap devices if blktap is available qemu is used as a fallback for DISK_BACKEND_TAP if no blktap is available but if blktap is available, or for DISK_BACKEND_PHY, we don't need a qemu process. Signed-off-by: Ian Campbell <ian.campbell@citrix.com> Acked-by: Ian Jackson <ian.jackson@eu.citrix.com> Committed-by: Ian Jackson <ian.jackson@eu.citrix.com> xen-unstable changeset: 23044:d4ca456c0c25 xen-unstable date: Tue Mar 15 18:19:47 2011 +0000 Committed-by: Ian Jackson <ian.jackson@eu.citrix.com> (qemu changes not included) _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel From xen-devel-bounces@lists.xensource.com Tue Sep 27 10:04:42 2011 Return-path: <xen-devel-bounces@lists.xensource.com> Envelope-to: www-data@lists.xensource.com Delivery-date: Tue, 27 Sep 2011 10:04:42 -0700 Received: from localhost ([127.0.0.1] helo=lists.colo.xensource.com) by lists.xensource.com with esmtp (Exim 4.43) id 1R8b5G-00075b-2k; Tue, 27 Sep 2011 10:04:42 -0700 Received: from mail174.messagelabs.com ([85.158.138.51]) by lists.xensource.com with esmtp (Exim 4.43) id 1R8b2G-0006r4-83 for xen-devel@lists.xensource.com; Tue, 27 Sep 2011 10:02:10 -0700 X-Env-Sender: Ian.Jackson@eu.citrix.com X-Msg-Ref: server-15.tower-174.messagelabs.com!1317142891!26635423!1 X-Originating-IP: [62.200.22.115] X-StarScan-Version: 6.4.1; banners=-,-,- X-VirusChecked: Checked Received: (qmail 26490 invoked from network); 27 Sep 2011 17:01:31 -0000 Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115) by server-15.tower-174.messagelabs.com with RC4-SHA encrypted SMTP; 27 Sep 2011 17:01:31 -0000 X-IronPort-AV: E=Sophos;i="4.68,450,1312156800"; d="scan'208";a="8089078" Received: from lonpmailmx01.citrite.net ([10.30.203.162]) by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5; 27 Sep 2011 17:01:30 +0000 Received: from norwich.cam.xci-test.com (10.80.248.129) by smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id 8.3.137.0; Tue, 27 Sep 2011 18:01:31 +0100 Received: from mariner.cam.xci-test.com ([10.80.2.22] helo=mariner.uk.xensource.com ident=Debian-exim) by norwich.cam.xci-test.com with esmtp (Exim 4.72) (envelope-from <Ian.Jackson@eu.citrix.com>) id 1R8b2A-0005Xh-GE; Tue, 27 Sep 2011 17:01:30 +0000 Received: from iwj by mariner.uk.xensource.com with local (Exim 4.69) (envelope-from <Ian.Jackson@eu.citrix.com>) id 1R8b2A-0006Ps-FO; Tue, 27 Sep 2011 18:01:30 +0100 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Message-ID: <20098.362.319162.127153@mariner.uk.xensource.com> Date: Tue, 27 Sep 2011 18:01:30 +0100 To: Roger Pau Monne <roger.pau@entel.upc.edu> Subject: Re: [Xen-devel] [PATCH 2 of 2] libxl: add support for booting PV domains from NetBSD using raw files as disks Newsgroups: chiark.mail.xen.devel In-Reply-To: <aff3960421768180410c.1316187419@loki> References: <patchbomb.1316187417@loki> <aff3960421768180410c.1316187419@loki> X-Mailer: VM 8.0.9 under Emacs 21.4.1 (i486-pc-linux-gnu) From: Ian Jackson <Ian.Jackson@eu.citrix.com> Cc: xen-devel@lists.xensource.com X-BeenThere: xen-devel@lists.xensource.com X-Mailman-Version: 2.1.5 Precedence: list List-Id: Xen developer discussion <xen-devel.lists.xensource.com> List-Unsubscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe> List-Post: <mailto:xen-devel@lists.xensource.com> List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help> List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=subscribe> Sender: xen-devel-bounces@lists.xensource.com Errors-To: xen-devel-bounces@lists.xensource.com Roger Pau Monne writes ("[Xen-devel] [PATCH 2 of 2] libxl: add support for booting PV domains from NetBSD using raw files as disks"): > libxl: add support for booting PV domains from NetBSD using raw files as disks. Thanks, I have some comments: > + if (S_ISBLK(a->stab.st_mode)) > + return backend; > +#ifdef HAVE_PHY_BACKEND_FILE_SUPPORT > + if (S_ISREG(a->stab.st_mode)) > + return backend; I think we would prefer not to have #ifdefs in the code. That can make the logic quite hard to follow. Instead, invent a helper function which answers the "does the phy backend support files" which is provided in two versions, from osdep.c. > @@ -366,14 +371,26 @@ int libxl__device_destroy(libxl__gc *gc, > libxl_ctx *ctx = libxl__gc_owner(gc); > xs_transaction_t t; > char *state_path = libxl__sprintf(gc, "%s/state", be_path); > + char *hotplug_path = libxl__sprintf(gc, "%s/hotplug-status", be_path); We want to get away from the hotplug scripts for disks at least on Linux with libxl. Rather, any scripts that are needed should be run from libxl directly. How does that fit with NetBSD's disk backend approach ? What goes wrong on NetBSD without this additional code ? > @@ -482,7 +519,7 @@ int libxl__devices_destroy(libxl__gc *gc > tv.tv_usec = 0; > while (n_watches > 0) { > if (wait_for_dev_destroy(gc, &tv)) { > - break; > + continue; > } else { > n_watches--; > } I'm not sure I understand this change, or why it's needed. Ian. _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel From xen-devel-bounces@lists.xensource.com Tue Sep 27 10:06:00 2011 Return-path: <xen-devel-bounces@lists.xensource.com> Envelope-to: www-data@lists.xensource.com Delivery-date: Tue, 27 Sep 2011 10:06:00 -0700 Received: from localhost ([127.0.0.1] helo=lists.colo.xensource.com) by lists.xensource.com with esmtp (Exim 4.43) id 1R8b6W-0007SY-1E; Tue, 27 Sep 2011 10:06:00 -0700 Received: from mail174.messagelabs.com ([85.158.138.51]) by lists.xensource.com with esmtp (Exim 4.43) id 1R8b4y-00073h-6U for xen-devel@lists.xensource.com; Tue, 27 Sep 2011 10:04:34 -0700 X-Env-Sender: Ian.Jackson@eu.citrix.com X-Msg-Ref: server-7.tower-174.messagelabs.com!1317143060!32959283!1 X-Originating-IP: [62.200.22.115] X-StarScan-Version: 6.4.1; banners=-,-,- X-VirusChecked: Checked Received: (qmail 19156 invoked from network); 27 Sep 2011 17:04:21 -0000 Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115) by server-7.tower-174.messagelabs.com with RC4-SHA encrypted SMTP; 27 Sep 2011 17:04:21 -0000 X-IronPort-AV: E=Sophos;i="4.68,450,1312156800"; d="scan'208";a="8089160" Received: from lonpmailmx01.citrite.net ([10.30.203.162]) by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5; 27 Sep 2011 17:04:20 +0000 Received: from norwich.cam.xci-test.com (10.80.248.129) by smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id 8.3.137.0; Tue, 27 Sep 2011 18:04:21 +0100 Received: from mariner.cam.xci-test.com ([10.80.2.22] helo=mariner.uk.xensource.com ident=Debian-exim) by norwich.cam.xci-test.com with esmtp (Exim 4.72) (envelope-from <Ian.Jackson@eu.citrix.com>) id 1R8b4u-0005YG-Ic; Tue, 27 Sep 2011 17:04:20 +0000 Received: from iwj by mariner.uk.xensource.com with local (Exim 4.69) (envelope-from <Ian.Jackson@eu.citrix.com>) id 1R8b4u-0006Uh-Hj; Tue, 27 Sep 2011 18:04:20 +0100 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Message-ID: <20098.532.539777.349511@mariner.uk.xensource.com> Date: Tue, 27 Sep 2011 18:04:20 +0100 To: Ian Campbell <Ian.Campbell@eu.citrix.com> Subject: Re: [Xen-devel] xl create crash when using stub domains Newsgroups: chiark.mail.xen.devel In-Reply-To: <1316595394.3891.105.camel@zakaz.uk.xensource.com> References: <4E729960.2080101@goop.org> <4E793F42.7070803@goop.org> <1316595394.3891.105.camel@zakaz.uk.xensource.com> X-Mailer: VM 8.0.9 under Emacs 21.4.1 (i486-pc-linux-gnu) From: Ian Jackson <Ian.Jackson@eu.citrix.com> Cc: Jeremy Fitzhardinge <jeremy@goop.org>, "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>, Stefano Stabellini <Stefano.Stabellini@eu.citrix.com> X-BeenThere: xen-devel@lists.xensource.com X-Mailman-Version: 2.1.5 Precedence: list List-Id: Xen developer discussion <xen-devel.lists.xensource.com> List-Unsubscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe> List-Post: <mailto:xen-devel@lists.xensource.com> List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help> List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=subscribe> Sender: xen-devel-bounces@lists.xensource.com Errors-To: xen-devel-bounces@lists.xensource.com Ian Campbell writes ("Re: [Xen-devel] xl create crash when using stub domains"): > Hmm, actually this function never uses starting except to get at > for_spawn perhaps we should just pass in the for_spawn directly. Patch > to that effect follows. ... > libxl: make libxl__wait_for_device_model use libxl__spawn_starrting directly Acked-by: Ian Jackson <ian.jackson@eu.citrix.com> Committed-by: Ian Jackson <ian.jackson@eu.citrix.com> The original reason for the for_spawn was that all this create code used to be outside libxl where it shouldn't be looking into libxl's private data structures. That reason no longer applies. Ian. _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel From xen-devel-bounces@lists.xensource.com Tue Sep 27 10:06:50 2011 Return-path: <xen-devel-bounces@lists.xensource.com> Envelope-to: www-data@lists.xensource.com Delivery-date: Tue, 27 Sep 2011 10:06:50 -0700 Received: from localhost ([127.0.0.1] helo=lists.colo.xensource.com) by lists.xensource.com with esmtp (Exim 4.43) id 1R8b7K-0007pK-3a; Tue, 27 Sep 2011 10:06:50 -0700 Received: from mail21.messagelabs.com ([85.158.143.35]) by lists.xensource.com with esmtp (Exim 4.43) id 1R8b6e-0007V7-Br for xen-devel@lists.xensource.com; Tue, 27 Sep 2011 10:06:10 -0700 X-Env-Sender: Stefano.Stabellini@eu.citrix.com X-Msg-Ref: server-7.tower-21.messagelabs.com!1317143132!56471358!1 X-Originating-IP: [66.165.176.89] X-StarScan-Version: 6.4.1; banners=-,-,- X-VirusChecked: Checked Received: (qmail 5926 invoked from network); 27 Sep 2011 17:05:34 -0000 Received: from smtp.citrix.com (HELO SMTP.CITRIX.COM) (66.165.176.89) by server-7.tower-21.messagelabs.com with RC4-SHA encrypted SMTP; 27 Sep 2011 17:05:34 -0000 X-IronPort-AV: E=Sophos;i="4.68,450,1312171200"; d="scan'208";a="17736872" Received: from ftlpmailmx01.citrite.net ([10.13.107.65]) by FTLPIPO01.CITRIX.COM with ESMTP/TLS/RC4-MD5; 27 Sep 2011 13:06:03 -0400 Received: from smtp01.ad.xensource.com (10.219.128.104) by smtprelay.citrix.com (10.13.107.65) with Microsoft SMTP Server id 8.3.137.0; Tue, 27 Sep 2011 13:06:03 -0400 Received: from localhost.localdomain (kaball.uk.xensource.com [10.80.2.59]) by smtp01.ad.xensource.com (8.13.1/8.13.1) with ESMTP id p8RH60AY019644; Tue, 27 Sep 2011 10:06:01 -0700 From: <stefano.stabellini@eu.citrix.com> To: konrad.wilk@oracle.com Date: Tue, 27 Sep 2011 18:05:58 +0100 Message-ID: <1317143159-7235-1-git-send-email-stefano.stabellini@eu.citrix.com> X-Mailer: git-send-email 1.7.0.4 MIME-Version: 1.0 Content-Type: text/plain Cc: Ian.Campbell@eu.citrix.com, jeremy@goop.org, xen-devel@lists.xensource.com, stefano.stabellini@eu.citrix.com Subject: [Xen-devel] [PATCH 1/2] xen: XEN_PVHVM depends on PCI X-BeenThere: xen-devel@lists.xensource.com X-Mailman-Version: 2.1.5 Precedence: list List-Id: Xen developer discussion <xen-devel.lists.xensource.com> List-Unsubscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe> List-Post: <mailto:xen-devel@lists.xensource.com> List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help> List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=subscribe> Sender: xen-devel-bounces@lists.xensource.com Errors-To: xen-devel-bounces@lists.xensource.com From: Stefano Stabellini <stefano.stabellini@eu.citrix.com> Xen PV on HVM guests require PCI support because they need the xen-platform-pci driver in order to initialize xenbus. Signed-off-by: Stefano Stabellini <stefano.stabellini@eu.citrix.com> --- arch/x86/xen/Kconfig | 3 +-- 1 files changed, 1 insertions(+), 2 deletions(-) diff --git a/arch/x86/xen/Kconfig b/arch/x86/xen/Kconfig index 5cc821c..e061f55 100644 --- a/arch/x86/xen/Kconfig +++ b/arch/x86/xen/Kconfig @@ -25,8 +25,7 @@ config XEN_PRIVILEGED_GUEST config XEN_PVHVM def_bool y - depends on XEN - depends on X86_LOCAL_APIC + depends on XEN && PCI && X86_LOCAL_APIC config XEN_MAX_DOMAIN_MEMORY int -- 1.7.2.3 _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel From xen-devel-bounces@lists.xensource.com Tue Sep 27 10:07:50 2011 Return-path: <xen-devel-bounces@lists.xensource.com> Envelope-to: www-data@lists.xensource.com Delivery-date: Tue, 27 Sep 2011 10:07:50 -0700 Received: from localhost ([127.0.0.1] helo=lists.colo.xensource.com) by lists.xensource.com with esmtp (Exim 4.43) id 1R8b8I-0008CV-Ah; Tue, 27 Sep 2011 10:07:50 -0700 Received: from mail182.messagelabs.com ([85.158.139.83]) by lists.xensource.com with esmtp (Exim 4.43) id 1R8b6g-0007W6-Fa for xen-devel@lists.xensource.com; Tue, 27 Sep 2011 10:06:11 -0700 X-Env-Sender: Stefano.Stabellini@eu.citrix.com X-Msg-Ref: server-3.tower-182.messagelabs.com!1317143165!17181086!1 X-Originating-IP: [66.165.176.63] X-StarScan-Version: 6.4.1; banners=-,-,- X-VirusChecked: Checked Received: (qmail 19050 invoked from network); 27 Sep 2011 17:06:07 -0000 Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63) by server-3.tower-182.messagelabs.com with RC4-SHA encrypted SMTP; 27 Sep 2011 17:06:07 -0000 X-IronPort-AV: E=Sophos;i="4.68,450,1312171200"; d="scan'208";a="164838750" Received: from ftlpmailmx01.citrite.net ([10.13.107.65]) by FTLPIPO02.CITRIX.COM with ESMTP/TLS/RC4-MD5; 27 Sep 2011 13:06:05 -0400 Received: from smtp01.ad.xensource.com (10.219.128.104) by smtprelay.citrix.com (10.13.107.65) with Microsoft SMTP Server id 8.3.137.0; Tue, 27 Sep 2011 13:06:04 -0400 Received: from localhost.localdomain (kaball.uk.xensource.com [10.80.2.59]) by smtp01.ad.xensource.com (8.13.1/8.13.1) with ESMTP id p8RH60AZ019644; Tue, 27 Sep 2011 10:06:03 -0700 From: <stefano.stabellini@eu.citrix.com> To: konrad.wilk@oracle.com Date: Tue, 27 Sep 2011 18:05:59 +0100 Message-ID: <1317143159-7235-2-git-send-email-stefano.stabellini@eu.citrix.com> X-Mailer: git-send-email 1.7.0.4 In-Reply-To: <1317143159-7235-1-git-send-email-stefano.stabellini@eu.citrix.com> References: <1317143159-7235-1-git-send-email-stefano.stabellini@eu.citrix.com> MIME-Version: 1.0 Content-Type: text/plain Cc: Ian.Campbell@eu.citrix.com, jeremy@goop.org, xen-devel@lists.xensource.com, stefano.stabellini@eu.citrix.com Subject: [Xen-devel] [PATCH 2/2] xen: remove XEN_PLATFORM_PCI config option X-BeenThere: xen-devel@lists.xensource.com X-Mailman-Version: 2.1.5 Precedence: list List-Id: Xen developer discussion <xen-devel.lists.xensource.com> List-Unsubscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe> List-Post: <mailto:xen-devel@lists.xensource.com> List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help> List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=subscribe> Sender: xen-devel-bounces@lists.xensource.com Errors-To: xen-devel-bounces@lists.xensource.com From: Stefano Stabellini <stefano.stabellini@eu.citrix.com> Xen PVHVM needs xen-platform-pci, on the other hand xen-platform-pci is useless in any other cases. Therefore remove the XEN_PLATFORM_PCI config option and compile xen-platform-pci built-in if XEN_PVHVM is selected. Signed-off-by: Stefano Stabellini <stefano.stabellini@eu.citrix.com> --- drivers/xen/Kconfig | 10 ---------- drivers/xen/Makefile | 2 +- 2 files changed, 1 insertions(+), 11 deletions(-) diff --git a/drivers/xen/Kconfig b/drivers/xen/Kconfig index 5f7ff8e..8795480 100644 --- a/drivers/xen/Kconfig +++ b/drivers/xen/Kconfig @@ -137,16 +137,6 @@ config XEN_GRANT_DEV_ALLOC to other domains. This can be used to implement frontend drivers or as part of an inter-domain shared memory channel. -config XEN_PLATFORM_PCI - tristate "xen platform pci device driver" - depends on XEN_PVHVM && PCI - default m - help - Driver for the Xen PCI Platform device: it is responsible for - initializing xenbus and grant_table when running in a Xen HVM - domain. As a consequence this driver is required to run any Xen PV - frontend on Xen HVM. - config SWIOTLB_XEN def_bool y depends on PCI diff --git a/drivers/xen/Makefile b/drivers/xen/Makefile index 72bbb27..d8dc26a 100644 --- a/drivers/xen/Makefile +++ b/drivers/xen/Makefile @@ -14,7 +14,7 @@ obj-$(CONFIG_XEN_GNTDEV) += xen-gntdev.o obj-$(CONFIG_XEN_GRANT_DEV_ALLOC) += xen-gntalloc.o obj-$(CONFIG_XENFS) += xenfs/ obj-$(CONFIG_XEN_SYS_HYPERVISOR) += sys-hypervisor.o -obj-$(CONFIG_XEN_PLATFORM_PCI) += xen-platform-pci.o +obj-$(CONFIG_XEN_PVHVM) += xen-platform-pci.o obj-$(CONFIG_XEN_TMEM) += tmem.o obj-$(CONFIG_SWIOTLB_XEN) += swiotlb-xen.o obj-$(CONFIG_XEN_DOM0) += pci.o -- 1.7.2.3 _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel From xen-devel-bounces@lists.xensource.com Tue Sep 27 10:08:32 2011 Return-path: <xen-devel-bounces@lists.xensource.com> Envelope-to: www-data@lists.xensource.com Delivery-date: Tue, 27 Sep 2011 10:08:32 -0700 Received: from localhost ([127.0.0.1] helo=lists.colo.xensource.com) by lists.xensource.com with esmtp (Exim 4.43) id 1R8b8y-00007n-N6; Tue, 27 Sep 2011 10:08:32 -0700 Received: from mail27.messagelabs.com ([193.109.254.147]) by lists.xensource.com with esmtp (Exim 4.43) id 1R8b7V-0007sk-01 for xen-devel@lists.xensource.com; Tue, 27 Sep 2011 10:07:01 -0700 X-Env-Sender: Ian.Jackson@eu.citrix.com X-Msg-Ref: server-6.tower-27.messagelabs.com!1317143197!50715457!1 X-Originating-IP: [62.200.22.115] X-StarScan-Version: 6.4.1; banners=-,-,- X-VirusChecked: Checked Received: (qmail 14475 invoked from network); 27 Sep 2011 17:06:37 -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; 27 Sep 2011 17:06:37 -0000 X-IronPort-AV: E=Sophos;i="4.68,450,1312156800"; d="scan'208";a="8089216" Received: from lonpmailmx01.citrite.net ([10.30.203.162]) by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5; 27 Sep 2011 17:06:57 +0000 Received: from norwich.cam.xci-test.com (10.80.248.129) by smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id 8.3.137.0; Tue, 27 Sep 2011 18:06:57 +0100 Received: from mariner.cam.xci-test.com ([10.80.2.22] helo=mariner.uk.xensource.com ident=Debian-exim) by norwich.cam.xci-test.com with esmtp (Exim 4.72) (envelope-from <Ian.Jackson@eu.citrix.com>) id 1R8b7R-0005Z1-BP; Tue, 27 Sep 2011 17:06:57 +0000 Received: from iwj by mariner.uk.xensource.com with local (Exim 4.69) (envelope-from <Ian.Jackson@eu.citrix.com>) id 1R8b7R-0006VI-Ab; Tue, 27 Sep 2011 18:06:57 +0100 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Message-ID: <20098.689.312648.316912@mariner.uk.xensource.com> Date: Tue, 27 Sep 2011 18:06:57 +0100 To: Ian Campbell <Ian.Campbell@citrix.com>, Adin Scannell <adin@gridcentric.com> Subject: Re: [Xen-devel] [PATCH] expose shared page count through xenlight [and 1 more messages] Newsgroups: chiark.mail.xen.devel In-Reply-To: <CAAJKtqpMqpWckNY=a9HrNZY8hT+cmH8odyLM2HKctSMY63=RRA@mail.gmail.com>, <1316597699.3891.130.camel@zakaz.uk.xensource.com> References: <CAAJKtqpMqpWckNY=a9HrNZY8hT+cmH8odyLM2HKctSMY63=RRA@mail.gmail.com> <1316597699.3891.130.camel@zakaz.uk.xensource.com> X-Mailer: VM 8.0.9 under Emacs 21.4.1 (i486-pc-linux-gnu) From: Ian Jackson <Ian.Jackson@eu.citrix.com> Cc: xen-devel@lists.xensource.com X-BeenThere: xen-devel@lists.xensource.com X-Mailman-Version: 2.1.5 Precedence: list List-Id: Xen developer discussion <xen-devel.lists.xensource.com> List-Unsubscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe> List-Post: <mailto:xen-devel@lists.xensource.com> List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help> List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=subscribe> Sender: xen-devel-bounces@lists.xensource.com Errors-To: xen-devel-bounces@lists.xensource.com Adin Scannell writes ("[Xen-devel] [PATCH] expose shared page count through xenlight"): > Attached is a simple patch to expose the shared page information > through libxl and xl. Thanks, but this will break existing callers who try to parse the output from "xl list". It's a shame that we can't easily extend this. In the future we will hopefully have a json output mode and can tell people who need to parse xl's output to use that. I'm not sure what the right answer is right now, though. Ian. _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel From xen-devel-bounces@lists.xensource.com Tue Sep 27 10:09:17 2011 Return-path: <xen-devel-bounces@lists.xensource.com> Envelope-to: www-data@lists.xensource.com Delivery-date: Tue, 27 Sep 2011 10:09:17 -0700 Received: from localhost ([127.0.0.1] helo=lists.colo.xensource.com) by lists.xensource.com with esmtp (Exim 4.43) id 1R8b9h-0000Uv-Cu; Tue, 27 Sep 2011 10:09:17 -0700 Received: from mail21.messagelabs.com ([85.158.143.35]) by lists.xensource.com with esmtp (Exim 4.43) id 1R8b7b-0007wM-A4 for xen-devel@lists.xensource.com; Tue, 27 Sep 2011 10:07:08 -0700 X-Env-Sender: david.vrabel@citrix.com X-Msg-Ref: server-14.tower-21.messagelabs.com!1317143214!61203460!1 X-Originating-IP: [66.165.176.63] X-StarScan-Version: 6.4.1; banners=-,-,- X-VirusChecked: Checked Received: (qmail 19788 invoked from network); 27 Sep 2011 17:06:55 -0000 Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63) by server-14.tower-21.messagelabs.com with RC4-SHA encrypted SMTP; 27 Sep 2011 17:06:55 -0000 X-IronPort-AV: E=Sophos;i="4.68,450,1312171200"; d="scan'208";a="164838942" Received: from ftlpmailmx02.citrite.net ([10.13.107.66]) by FTLPIPO02.CITRIX.COM with ESMTP/TLS/RC4-MD5; 27 Sep 2011 13:07:02 -0400 Received: from [10.80.2.76] (10.80.2.76) by FTLPMAILMX02.citrite.net (10.13.107.66) with Microsoft SMTP Server id 8.3.137.0; Tue, 27 Sep 2011 13:07:02 -0400 Message-ID: <4E820316.6070101@citrix.com> Date: Tue, 27 Sep 2011 18:08:38 +0100 From: David Vrabel <david.vrabel@citrix.com> User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.1.16) Gecko/20110818 Icedove/3.0.11 MIME-Version: 1.0 To: Dan Magenheimer <dan.magenheimer@oracle.com> References: <2de59b55-4ecc-4155-8709-f8b0f5e012bc@default 4E81F278.5040107@citrix.com> <f42e2a83-15f6-4767-a7df-8a23ceac239e@default> In-Reply-To: <f42e2a83-15f6-4767-a7df-8a23ceac239e@default> Content-Type: text/plain; charset="ISO-8859-1" Content-Transfer-Encoding: 7bit Cc: Jeremy Fitzhardinge <jeremy@goop.org>, "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>, "linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>, Konrad Wilk <konrad.wilk@oracle.com> Subject: [Xen-devel] Re: [PATCH v2] xen: Fix selfballooning and ensure it doesn't go too far X-BeenThere: xen-devel@lists.xensource.com X-Mailman-Version: 2.1.5 Precedence: list List-Id: Xen developer discussion <xen-devel.lists.xensource.com> List-Unsubscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe> List-Post: <mailto:xen-devel@lists.xensource.com> List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help> List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=subscribe> Sender: xen-devel-bounces@lists.xensource.com Errors-To: xen-devel-bounces@lists.xensource.com On 27/09/11 17:19, Dan Magenheimer wrote: >> From: David Vrabel [mailto:david.vrabel@citrix.com] >> Subject: Re: [PATCH v2] xen: Fix selfballooning and ensure it doesn't go too far >> >> On 27/09/11 16:03, Dan Magenheimer wrote: >>> Note: This patch is also now in a git tree at: >>> >>> git://oss.oracle.com/git/djm/tmem.git#selfballoon-fix-v2 >>> >>> The balloon driver's "current_pages" is very different from >>> totalram_pages. Self-ballooning needs to be driven by >>> the latter. > > Hi David -- > > Thanks for the feedback! > >> I don't think this part of the change makes any difference. It looks like it >> rearranges the maths without changing the end result (other than >> slightly increasing the rate of change). >> I think this (partial, untested) patch is equivalent: > > Actually it does. Really? Both patched and unpatched the new target, S, is (eventually): S = V + F + C - T where V is vm_committed_as, F is frontswap_curr_pages(), C is balloon_stats.current_pages, and T = totalram_pages. Perhaps the refactoring of the maths is a good idea (I don't think so) but it shouldn't be part of this patch and it shouldn't be described as a fix. David _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel From xen-devel-bounces@lists.xensource.com Tue Sep 27 10:25:06 2011 Return-path: <xen-devel-bounces@lists.xensource.com> Envelope-to: www-data@lists.xensource.com Delivery-date: Tue, 27 Sep 2011 10:25:06 -0700 Received: from localhost ([127.0.0.1] helo=lists.colo.xensource.com) by lists.xensource.com with esmtp (Exim 4.43) id 1R8bOy-0001Az-T5; Tue, 27 Sep 2011 10:25:04 -0700 Received: from mail182.messagelabs.com ([85.158.139.83]) by lists.xensource.com with esmtp (Exim 4.43) id 1R8bNz-0000xU-5s for xen-devel@lists.xensource.com; Tue, 27 Sep 2011 10:24:03 -0700 X-Env-Sender: jeremy@goop.org X-Msg-Ref: server-10.tower-182.messagelabs.com!1317144238!19955891!1 X-Originating-IP: [74.207.240.146] X-StarScan-Version: 6.4.1; banners=-,-,- X-VirusChecked: Checked Received: (qmail 24211 invoked from network); 27 Sep 2011 17:24:00 -0000 Received: from claw.goop.org (HELO claw.goop.org) (74.207.240.146) by server-10.tower-182.messagelabs.com with DHE-RSA-AES256-SHA encrypted SMTP; 27 Sep 2011 17:24:00 -0000 Received: from saboo.goop.org (unknown [206.29.182.153]) (Authenticated sender: smtp-saboo) by claw.goop.org (Postfix) with ESMTPSA id 5A51F8875; Tue, 27 Sep 2011 10:23:57 -0700 (PDT) Received: from saboo.goop.org (localhost [IPv6:::1]) by saboo.goop.org (Postfix) with ESMTP id 60FBF208FE; Tue, 27 Sep 2011 10:23:52 -0700 (PDT) Message-ID: <4E8206A8.2090606@goop.org> Date: Tue, 27 Sep 2011 10:23:52 -0700 From: Jeremy Fitzhardinge <jeremy@goop.org> User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:6.0.2) Gecko/20110906 Thunderbird/6.0.2 MIME-Version: 1.0 To: stefano.stabellini@eu.citrix.com References: <1317143159-7235-1-git-send-email-stefano.stabellini@eu.citrix.com> <1317143159-7235-2-git-send-email-stefano.stabellini@eu.citrix.com> In-Reply-To: <1317143159-7235-2-git-send-email-stefano.stabellini@eu.citrix.com> X-Enigmail-Version: 1.3.2 Content-Type: text/plain; charset=ISO-8859-15 Content-Transfer-Encoding: 7bit Cc: Ian.Campbell@eu.citrix.com, xen-devel@lists.xensource.com, konrad.wilk@oracle.com Subject: [Xen-devel] Re: [PATCH 2/2] xen: remove XEN_PLATFORM_PCI config option X-BeenThere: xen-devel@lists.xensource.com X-Mailman-Version: 2.1.5 Precedence: list List-Id: Xen developer discussion <xen-devel.lists.xensource.com> List-Unsubscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe> List-Post: <mailto:xen-devel@lists.xensource.com> List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help> List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=subscribe> Sender: xen-devel-bounces@lists.xensource.com Errors-To: xen-devel-bounces@lists.xensource.com On 09/27/2011 10:05 AM, stefano.stabellini@eu.citrix.com wrote: > From: Stefano Stabellini <stefano.stabellini@eu.citrix.com> > > Xen PVHVM needs xen-platform-pci, on the other hand xen-platform-pci is > useless in any other cases. > Therefore remove the XEN_PLATFORM_PCI config option and compile > xen-platform-pci built-in if XEN_PVHVM is selected. > > Signed-off-by: Stefano Stabellini <stefano.stabellini@eu.citrix.com> > --- > drivers/xen/Kconfig | 10 ---------- > drivers/xen/Makefile | 2 +- > 2 files changed, 1 insertions(+), 11 deletions(-) > > diff --git a/drivers/xen/Kconfig b/drivers/xen/Kconfig > index 5f7ff8e..8795480 100644 > --- a/drivers/xen/Kconfig > +++ b/drivers/xen/Kconfig > @@ -137,16 +137,6 @@ config XEN_GRANT_DEV_ALLOC > to other domains. This can be used to implement frontend drivers > or as part of an inter-domain shared memory channel. > > -config XEN_PLATFORM_PCI > - tristate "xen platform pci device driver" > - depends on XEN_PVHVM && PCI > - default m > - help > - Driver for the Xen PCI Platform device: it is responsible for > - initializing xenbus and grant_table when running in a Xen HVM > - domain. As a consequence this driver is required to run any Xen PV > - frontend on Xen HVM. > - > config SWIOTLB_XEN > def_bool y > depends on PCI > diff --git a/drivers/xen/Makefile b/drivers/xen/Makefile > index 72bbb27..d8dc26a 100644 > --- a/drivers/xen/Makefile > +++ b/drivers/xen/Makefile > @@ -14,7 +14,7 @@ obj-$(CONFIG_XEN_GNTDEV) += xen-gntdev.o > obj-$(CONFIG_XEN_GRANT_DEV_ALLOC) += xen-gntalloc.o > obj-$(CONFIG_XENFS) += xenfs/ > obj-$(CONFIG_XEN_SYS_HYPERVISOR) += sys-hypervisor.o > -obj-$(CONFIG_XEN_PLATFORM_PCI) += xen-platform-pci.o > +obj-$(CONFIG_XEN_PVHVM) += xen-platform-pci.o May as well just say "platform-pci.o" and remove the "xen-platform-pci-y := platform-pci.o" further down, since its no longer externally visible. J _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel From xen-devel-bounces@lists.xensource.com Tue Sep 27 10:40:34 2011 Return-path: <xen-devel-bounces@lists.xensource.com> Envelope-to: www-data@lists.xensource.com Delivery-date: Tue, 27 Sep 2011 10:40:34 -0700 Received: from localhost ([127.0.0.1] helo=lists.colo.xensource.com) by lists.xensource.com with esmtp (Exim 4.43) id 1R8bdy-0002hi-If; Tue, 27 Sep 2011 10:40:34 -0700 Received: from mail27.messagelabs.com ([193.109.254.147]) by lists.xensource.com with esmtp (Exim 4.43) id 1R8bdB-0002Uc-ED for xen-devel@lists.xensource.com; Tue, 27 Sep 2011 10:39:46 -0700 X-Env-Sender: Ian.Jackson@eu.citrix.com X-Msg-Ref: server-3.tower-27.messagelabs.com!1317145158!41393888!1 X-Originating-IP: [62.200.22.115] X-StarScan-Version: 6.4.1; banners=-,-,- X-VirusChecked: Checked Received: (qmail 30328 invoked from network); 27 Sep 2011 17:39:18 -0000 Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115) by server-3.tower-27.messagelabs.com with RC4-SHA encrypted SMTP; 27 Sep 2011 17:39:18 -0000 X-IronPort-AV: E=Sophos;i="4.68,450,1312156800"; d="scan'208";a="8089620" Received: from lonpmailmx01.citrite.net ([10.30.203.162]) by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5; 27 Sep 2011 17:39:41 +0000 Received: from woking.xci-test.com (10.80.248.135) by smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id 8.3.137.0; Tue, 27 Sep 2011 18:39:42 +0100 Received: from osstest by woking.xci-test.com with local (Exim 4.69) (envelope-from <ian.jackson@eu.citrix.com>) id 1R8bd7-0000zZ-Ol; Tue, 27 Sep 2011 18:39:41 +0100 To: xen-devel@lists.xensource.com Message-ID: <osstest-9101-mainreport@xen.org> From: xen.org <ian.jackson@eu.citrix.com> Date: Tue, 27 Sep 2011 18:39:41 +0100 MIME-Version: 1.0 Content-Type: text/plain Cc: ian.jackson@eu.citrix.com Subject: [Xen-devel] [xen-unstable test] 9101: regressions - trouble: blocked/fail/preparing X-BeenThere: xen-devel@lists.xensource.com X-Mailman-Version: 2.1.5 Precedence: list List-Id: Xen developer discussion <xen-devel.lists.xensource.com> List-Unsubscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe> List-Post: <mailto:xen-devel@lists.xensource.com> List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help> List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=subscribe> Sender: xen-devel-bounces@lists.xensource.com Errors-To: xen-devel-bounces@lists.xensource.com flight 9101 xen-unstable running [real] http://www.chiark.greenend.org.uk/~xensrcts/logs/9101/ Regressions :-( Tests which did not succeed and are blocking: build-amd64 4 xen-build fail REGR. vs. 8995 build-i386-oldkern 4 xen-build fail REGR. vs. 8995 build-i386 4 xen-build fail REGR. vs. 8995 build-amd64-oldkern 2 host-install(2) running Tests which did not succeed, but are not blocking, including regressions (tests previously passed) regarded as allowable: test-amd64-amd64-xl-pcipt-intel 1 xen-build-check(1) blocked n/a test-amd64-i386-pv 1 xen-build-check(1) blocked n/a test-amd64-amd64-xl 1 xen-build-check(1) blocked n/a test-i386-i386-pv 1 xen-build-check(1) blocked n/a test-amd64-amd64-pv 1 xen-build-check(1) blocked n/a test-amd64-i386-xl-multivcpu 1 xen-build-check(1) blocked n/a test-amd64-i386-xl-credit2 1 xen-build-check(1) blocked n/a test-amd64-i386-xl 1 xen-build-check(1) blocked n/a test-amd64-i386-rhel6hvm-intel 1 xen-build-check(1) blocked n/a test-i386-i386-xl 1 xen-build-check(1) blocked n/a build-amd64-pvops 4 kernel-build fail like 8991 test-amd64-amd64-xl-sedf 1 xen-build-check(1) blocked n/a build-i386-pvops 4 kernel-build fail like 8991 test-i386-i386-xl-win 1 xen-build-check(1) blocked n/a test-i386-i386-pair 1 xen-build-check(1) blocked n/a test-amd64-i386-pair 1 xen-build-check(1) blocked n/a test-amd64-amd64-pair 1 xen-build-check(1) blocked n/a test-amd64-i386-xl-win-vcpus1 1 xen-build-check(1) blocked n/a test-i386-i386-win 1 xen-build-check(1) blocked n/a test-amd64-i386-win-vcpus1 1 xen-build-check(1) blocked n/a test-amd64-i386-rhel6hvm-amd 1 xen-build-check(1) blocked n/a test-amd64-amd64-win 1 xen-build-check(1) blocked n/a test-amd64-i386-win 1 xen-build-check(1) blocked n/a test-amd64-amd64-xl-win 1 xen-build-check(1) blocked n/a version targeted for testing: xen b113d626cfaf baseline version: xen a422e2a4451e ------------------------------------------------------------ People who touched revisions under test: Andreas Herrmann <herrmann.der.user@googlemail.com> Ian Campbell <ian.campbell@citrix.com> Ian Jackson <ian.jackson@eu.citrix.com> Jan Beulich <jbeulich@suse.com> Lasse Collin <lasse.collin@tukaani.org> Olaf Hering <olaf@aepfle.de> Paul Durrant <paul.durrant@citrix.com> Thomas Renninger <trenn@suse.de> Tim Deegan <tim@xen.org> ------------------------------------------------------------ jobs: build-amd64 fail build-i386 fail build-amd64-oldkern preparing build-i386-oldkern fail build-amd64-pvops fail build-i386-pvops fail test-amd64-amd64-xl blocked test-amd64-i386-xl blocked test-i386-i386-xl blocked test-amd64-i386-rhel6hvm-amd blocked test-amd64-i386-xl-credit2 blocked test-amd64-amd64-xl-pcipt-intel blocked test-amd64-i386-rhel6hvm-intel blocked test-amd64-i386-xl-multivcpu blocked test-amd64-amd64-pair blocked test-amd64-i386-pair blocked test-i386-i386-pair blocked test-amd64-amd64-pv blocked test-amd64-i386-pv blocked test-i386-i386-pv blocked test-amd64-amd64-xl-sedf blocked test-amd64-i386-win-vcpus1 blocked test-amd64-i386-xl-win-vcpus1 blocked test-amd64-amd64-win blocked test-amd64-i386-win blocked test-i386-i386-win blocked test-amd64-amd64-xl-win blocked test-i386-i386-xl-win blocked ------------------------------------------------------------ sg-report-flight on woking.cam.xci-test.com logs: /home/xc_osstest/logs images: /home/xc_osstest/images Logs, config files, etc. are available at http://www.chiark.greenend.org.uk/~xensrcts/logs Test harness code can be found at http://xenbits.xensource.com/gitweb?p=osstest.git;a=summary Not pushing. ------------------------------------------------------------ changeset: 23876:b113d626cfaf tag: tip user: Ian Campbell <ian.campbell@citrix.com> date: Tue Sep 27 17:32:16 2011 +0100 xl: fixup "xl save" command line handling. The save file paramter is required so ensure we have enough arguments. The config filename is optional so do not use argv[optind+3], which may well happen to be NULL when the paramter is not present but relying on that is pretty gross. Signed-off-by: Ian Campbell <ian.campbell@citrix.com> Acked-by: Ian Jackson <ian.jackson@eu.citrix.com> Committed-by: Ian Jackson <ian.jackson@eu.citrix.com> changeset: 23875:ade44be5b936 user: Jan Beulich <jbeulich@suse.com> date: Tue Sep 27 16:15:09 2011 +0100 AMD-IOMMU: fix initialization order (after 23863:9e0259239822) That original patch caused alloc_ivrs_mappings() to be called too early, so things get moved back to where they were, just converting the single call there to a loop over all IOMMUs. Signed-off-by: Jan Beulich <jbeulich@suse.com> changeset: 23874:651aed73b39c user: Olaf Hering <olafiaepfle.de> date: Mon Sep 26 22:19:42 2011 +0100 xenpaging: track number of paged pages in struct domain The toolstack should know how many pages are paged-out at a given point in time so it could make smarter decisions about how many pages should be paged or ballooned. Add a new member to xen_domctl_getdomaininfo and bump interface version. Use the new member in xc_dominfo_t. The SONAME of libxc should be changed if this patch gets applied. Signed-off-by: Olaf Hering <olaf@aepfle.de> Acked-by: Ian Campbell <ian.campbell@citrix.com> Acked-by: Tim Deegan <tim@xen.org> Committed-by: Tim Deegan <tim@xen.org> changeset: 23873:fef59e4eaf8d user: Paul Durrant <paul.durrant@citrix.com> date: Mon Sep 26 22:10:21 2011 +0100 Add save/restore support for viridian APIC assist pfn. c/s 17b754cab7b0 introduced a per-VCPU viridian structure to store the APIC assist pfn. This patch adds support for save and restore of that value. Signed-off-by: Paul Durrant <paul.durrant@citrix.com> Acked-by: Tim Deegan <tim@xen.org> Committed-by: Tim Deegan <tim@xen.org> changeset: 23872:cc339ab1d917 user: Ian Campbell <ian.campbell@citrix.com> date: Thu Sep 22 18:37:06 2011 +0100 tools: fix install of lomount $(BIN) went away in 23124:e3d4c34b14a3. Also there are no *.so, *.a or *.rpm built in here Signed-off-by: Ian Campbell <ian.campbell@citrix.com> changeset: 23871:503ee256fecf user: Jan Beulich <jbeulich@suse.com> date: Thu Sep 22 18:35:30 2011 +0100 x86: ucode-amd: Don't warn when no ucode is available for a CPU revision This patch originally comes from the Linus mainline kernel (2.6.33), find below the patch details: From: Andreas Herrmann <herrmann.der.user@googlemail.com> There is no point in warning when there is no ucode available for a specific CPU revision. Currently the container-file, which provides the AMD ucode patches for OS load, contains only a few ucode patches. It's already clearly indicated by the printed patch_level whenever new ucode was available and an update happened. So the warning message is of no help but rather annoying on systems with many CPUs. Signed-off-by: Thomas Renninger <trenn@suse.de> Signed-off-by: Jan Beulich <jbeulich@suse.com> changeset: 23870:5c97b02f48fc user: Jan Beulich <jbeulich@suse.com> date: Thu Sep 22 18:34:27 2011 +0100 XZ: Fix incorrect XZ_BUF_ERROR From: Lasse Collin <lasse.collin@tukaani.org> xz_dec_run() could incorrectly return XZ_BUF_ERROR if all of the following was true: - The caller knows how many bytes of output to expect and only provides that much output space. - When the last output bytes are decoded, the caller-provided input buffer ends right before the LZMA2 end of payload marker. So LZMA2 won't provide more output anymore, but it won't know it yet and thus won't return XZ_STREAM_END yet. - A BCJ filter is in use and it hasn't left any unfiltered bytes in the temp buffer. This can happen with any BCJ filter, but in practice it's more likely with filters other than the x86 BCJ. This fixes <https://bugzilla.redhat.com/show_bug.cgi?id=3D735408> where Squashfs thinks that a valid file system is corrupt. This also fixes a similar bug in single-call mode where the uncompressed size of a block using BCJ + LZMA2 was 0 bytes and caller provided no output space. Many empty .xz files don't contain any blocks and thus don't trigger this bug. This also tweaks a closely related detail: xz_dec_bcj_run() could call xz_dec_lzma2_run() to decode into temp buffer when it was known to be useless. This was harmless although it wasted a minuscule number of CPU cycles. Signed-off-by: Lasse Collin <lasse.collin@tukaani.org> Signed-off-by: Jan Beulich <jbeulich@suse.com> changeset: 23869:db1ea4b127cd user: Jan Beulich <jbeulich@suse.com> date: Thu Sep 22 18:33:48 2011 +0100 XZ decompressor: Fix decoding of empty LZMA2 streams From: Lasse Collin <lasse.collin@tukaani.org> The old code considered valid empty LZMA2 streams to be corrupt. Note that a typical empty .xz file has no LZMA2 data at all, and thus most .xz files having no uncompressed data are handled correctly even without this fix. Signed-off-by: Lasse Collin <lasse.collin@tukaani.org> Signed-off-by: Jan Beulich <jbeulich@suse.com> changeset: 23868:28147fd781af user: Jan Beulich <jbeulich@suse.com> date: Thu Sep 22 18:32:34 2011 +0100 VT-d: fix off-by-one error in RMRR validation (base_addr,end_addr) is an inclusive range, and hence there shouldn't be a subtraction of 1 in the second invocation of page_is_ram_type(). For RMRRs covering a single page that actually resulted in the immediately preceding page to get checked (which could have resulted in a false warning). Signed-off-by: Jan Beulich <jbeulich@suse.com> changeset: 23867:571b6e90dfb4 user: Jan Beulich <jbeulich@suse.com> date: Thu Sep 22 18:31:44 2011 +0100 VT-d: eliminate a mis-use of pcidevs_lock dma_pte_clear_one() shouldn't acquire this global lock for the purpose of processing a per-domain list. Furthermore the function a few lines earlier has a comment stating that acquiring pcidevs_lock isn't necessary here (whether that's really correct is another question). Use the domain's mappin_lock instead to protect the mapped_rmrrs list. Fold domain_rmrr_mapped() into its sole caller so that the otherwise implicit dependency on pcidevs_lock there becomes more obvious (see the comment there). Signed-off-by: Jan Beulich <jbeulich@suse.com> changeset: 23866:47ec1d405af9 user: Jan Beulich <jbeulich@suse.com> date: Thu Sep 22 18:31:02 2011 +0100 x86: IO-APIC code has no dependency on PCI The IRQ handling code requires pcidevs_lock to be held only for MSI interrupts. As the handling of which was now fully moved into msi.c (i.e. while applying fine without, the patch needs to be applied after the one titled "x86: split MSI IRQ chip"), io_apic.c now also doesn't need to include PCI headers anymore. Signed-off-by: Jan Beulich <jbeulich@suse.com> changeset: 23865:d6e01c7853cf user: Jan Beulich <jbeulich@suse.com> date: Thu Sep 22 18:29:19 2011 +0100 PCI multi-seg: config space accessor adjustments Signed-off-by: Jan Beulich <jbeulich@suse.com> changeset: 23864:314b147d524d user: Jan Beulich <jbeulich@suse.com> date: Thu Sep 22 18:28:38 2011 +0100 PCI multi-seg: Pass-through adjustments Signed-off-by: Jan Beulich <jbeulich@suse.com> changeset: 23863:9e0259239822 user: Jan Beulich <jbeulich@suse.com> date: Thu Sep 22 18:28:03 2011 +0100 PCI multi-seg: AMD-IOMMU specific adjustments There are two places here where it is entirely unclear to me where the necessary PCI segment number should be taken from (as IVMD descriptors don't have such, only IVHD ones do). AMD confirmed that for the time being it is acceptable to imply that only segment 0 exists. Signed-off-by: Jan Beulich <jbeulich@suse.com> changeset: 23862:85418e168527 user: Jan Beulich <jbeulich@suse.com> date: Thu Sep 22 18:27:26 2011 +0100 PCI multi-seg: VT-d specific adjustments Signed-off-by: Jan Beulich <jbeulich@suse.com> changeset: 23861:ec7c81fbe0de user: Jan Beulich <jbeulich@suse.com> date: Thu Sep 22 18:26:54 2011 +0100 PCI multi-seg: adjust domctl interface Again, a couple of directly related functions at once get adjusted to account for the segment number. Signed-off-by: Jan Beulich <jbeulich@suse.com> changeset: 23860:a422e2a4451e user: Jan Beulich <jbeulich@suse.com> date: Sun Sep 18 00:26:52 2011 +0100 x86: split MSI IRQ chip With the .end() accessor having become optional and noting that several of the accessors' behavior really depends on the result of msi_maskable_irq(), the splits the MSI IRQ chip type into two - one for the maskable ones, and the other for the (MSI only) non-maskable ones. At once the implementation of those methods gets moved from io_apic.c to msi.c. Signed-off-by: Jan Beulich <jbeulich@suse.com> ======================================== commit cd776ee9408ff127f934a707c1a339ee600bc127 Author: Ian Jackson <ian.jackson@eu.citrix.com> Date: Tue Jun 28 13:50:53 2011 +0100 qemu-char.c: fix incorrect CONFIG_STUBDOM handling qemu-char.c:1123:7: warning: "CONFIG_STUBDOM" is not defined [-Wundef] Signed-off-by: Olaf Hering <olaf@aepfle.de> Acked-by: Ian Jackson <ian.jackson@eu.citrix.com> _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel From xen-devel-bounces@lists.xensource.com Tue Sep 27 10:41:50 2011 Return-path: <xen-devel-bounces@lists.xensource.com> Envelope-to: www-data@lists.xensource.com Delivery-date: Tue, 27 Sep 2011 10:41:50 -0700 Received: from localhost ([127.0.0.1] helo=lists.colo.xensource.com) by lists.xensource.com with esmtp (Exim 4.43) id 1R8bfB-00034X-Ik; Tue, 27 Sep 2011 10:41:49 -0700 Received: from mail27.messagelabs.com ([193.109.254.147]) by lists.xensource.com with esmtp (Exim 4.43) id 1R8bdB-0002Ud-Rm for xen-devel@lists.xensource.com; Tue, 27 Sep 2011 10:39:46 -0700 X-Env-Sender: Ian.Jackson@eu.citrix.com X-Msg-Ref: server-3.tower-27.messagelabs.com!1317145158!41393888!2 X-Originating-IP: [62.200.22.115] X-StarScan-Version: 6.4.1; banners=-,-,- X-VirusChecked: Checked Received: (qmail 30340 invoked from network); 27 Sep 2011 17:39:18 -0000 Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115) by server-3.tower-27.messagelabs.com with RC4-SHA encrypted SMTP; 27 Sep 2011 17:39:18 -0000 X-IronPort-AV: E=Sophos;i="4.68,450,1312156800"; d="scan'208";a="8089621" Received: from lonpmailmx01.citrite.net ([10.30.203.162]) by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5; 27 Sep 2011 17:39:42 +0000 Received: from norwich.cam.xci-test.com (10.80.248.129) by smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id 8.3.137.0; Tue, 27 Sep 2011 18:39:43 +0100 Received: from mariner.cam.xci-test.com ([10.80.2.22] helo=mariner.uk.xensource.com ident=Debian-exim) by norwich.cam.xci-test.com with esmtp (Exim 4.72) (envelope-from <Ian.Jackson@eu.citrix.com>) id 1R8bd8-0005h1-NZ; Tue, 27 Sep 2011 17:39:42 +0000 Received: from iwj by mariner.uk.xensource.com with local (Exim 4.69) (envelope-from <Ian.Jackson@eu.citrix.com>) id 1R8bd8-0006a1-Md; Tue, 27 Sep 2011 18:39:42 +0100 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Message-ID: <20098.2654.689536.265060@mariner.uk.xensource.com> Date: Tue, 27 Sep 2011 18:39:42 +0100 To: Andreas Olsowski <andreas.olsowski@leuphana.de>, Ian Campbell <Ian.Campbell@citrix.com> Subject: Re: [Xen-devel] XL: pv guests dont reboot after migration (xen4.1.2-rc2-pre) [and 1 more messages] Newsgroups: chiark.mail.xen.devel In-Reply-To: <1316764843.23371.103.camel@zakaz.uk.xensource.com>, <4E7C4E45.5080509@leuphana.de> References: <4E785FDD.40209@leuphana.de> <1316546621.5182.23.camel@dagon.hellion.org.uk> <4E7C37D6.7050109@leuphana.de> <1316764843.23371.103.camel@zakaz.uk.xensource.com> <4E7C4E45.5080509@leuphana.de> X-Mailer: VM 8.0.9 under Emacs 21.4.1 (i486-pc-linux-gnu) From: Ian Jackson <Ian.Jackson@eu.citrix.com> Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com> X-BeenThere: xen-devel@lists.xensource.com X-Mailman-Version: 2.1.5 Precedence: list List-Id: Xen developer discussion <xen-devel.lists.xensource.com> List-Unsubscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe> List-Post: <mailto:xen-devel@lists.xensource.com> List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help> List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=subscribe> Sender: xen-devel-bounces@lists.xensource.com Errors-To: xen-devel-bounces@lists.xensource.com Ian Campbell writes ("Re: [Xen-devel] XL: pv guests dont reboot after migration (xen4.1.2-rc2-pre)"): > It smells like on reboot it is trying to receive another incoming > migration, instead of restarting the domain it already has. > > This (untested) might help: Thanks both, I've applied this patch. Ian. _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel From xen-devel-bounces@lists.xensource.com Tue Sep 27 11:08:36 2011 Return-path: <xen-devel-bounces@lists.xensource.com> Envelope-to: www-data@lists.xensource.com Delivery-date: Tue, 27 Sep 2011 11:08:36 -0700 Received: from localhost ([127.0.0.1] helo=lists.colo.xensource.com) by lists.xensource.com with esmtp (Exim 4.43) id 1R8c54-0003sp-I7; Tue, 27 Sep 2011 11:08:35 -0700 Received: from mail174.messagelabs.com ([85.158.138.51]) by lists.xensource.com with esmtp (Exim 4.43) id 1R8c3y-0003g5-8p for xen-devel@lists.xensource.com; Tue, 27 Sep 2011 11:07:26 -0700 X-Env-Sender: amscanne@gridcentric.ca X-Msg-Ref: server-12.tower-174.messagelabs.com!1317146843!32977157!1 X-Originating-IP: [209.85.161.43] X-StarScan-Version: 6.4.1; banners=-,-,- X-VirusChecked: Checked Received: (qmail 28391 invoked from network); 27 Sep 2011 18:07:23 -0000 Received: from mail-fx0-f43.google.com (HELO mail-fx0-f43.google.com) (209.85.161.43) by server-12.tower-174.messagelabs.com with RC4-SHA encrypted SMTP; 27 Sep 2011 18:07:23 -0000 Received: by fxh19 with SMTP id 19so9512519fxh.30 for <xen-devel@lists.xensource.com>; Tue, 27 Sep 2011 11:07:23 -0700 (PDT) Received: by 10.223.8.2 with SMTP id f2mr7184848faf.23.1317146843089; Tue, 27 Sep 2011 11:07:23 -0700 (PDT) MIME-Version: 1.0 Received: by 10.223.101.194 with HTTP; Tue, 27 Sep 2011 11:07:03 -0700 (PDT) In-Reply-To: <1316597699.3891.130.camel@zakaz.uk.xensource.com> References: <CAAJKtqpMqpWckNY=a9HrNZY8hT+cmH8odyLM2HKctSMY63=RRA@mail.gmail.com> <1316597699.3891.130.camel@zakaz.uk.xensource.com> From: Adin Scannell <adin@gridcentric.com> Date: Tue, 27 Sep 2011 14:07:03 -0400 X-Google-Sender-Auth: O9H8e3eDd0zhXQohknYyRj2-x80 Message-ID: <CAAJKtqr7MxL-X0RGikQTEokmc_f1de-2xm=tz-Ns=svV_TWJjg@mail.gmail.com> Subject: Re: [Xen-devel] [PATCH] expose shared page count through xenlight To: Ian Campbell <Ian.Campbell@citrix.com> Content-Type: text/plain; charset=ISO-8859-1 Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com> X-BeenThere: xen-devel@lists.xensource.com X-Mailman-Version: 2.1.5 Precedence: list List-Id: Xen developer discussion <xen-devel.lists.xensource.com> List-Unsubscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe> List-Post: <mailto:xen-devel@lists.xensource.com> List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help> List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=subscribe> Sender: xen-devel-bounces@lists.xensource.com Errors-To: xen-devel-bounces@lists.xensource.com Hi Ian, On Wed, Sep 21, 2011 at 5:34 AM, Ian Campbell <Ian.Campbell@citrix.com> wrote: > Can we only print this info in verbose mode, or only if >=1 domain has > shared pages or something? I don't suppose just printing the total > number of shared pages across the system is as useful as printing the nr > for each domain? Sure. I'll move the shared pages to verbose output and resend. I'll also see about throwing in the total number of shared frames to the info command (separate patch). > Also, was the change from \t to explicit padding in the header > intentional? I agree it's a bit odd to use \t in the header and spaces > in the actual info lines. It was intentional, as the \t's happen to line up very badly after the change (and they should both be either spaces or tabs anyways). Cheers, -Adin _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel From xen-devel-bounces@lists.xensource.com Tue Sep 27 11:14:11 2011 Return-path: <xen-devel-bounces@lists.xensource.com> Envelope-to: www-data@lists.xensource.com Delivery-date: Tue, 27 Sep 2011 11:14:11 -0700 Received: from localhost ([127.0.0.1] helo=lists.colo.xensource.com) by lists.xensource.com with esmtp (Exim 4.43) id 1R8cAU-0004K9-Sn; Tue, 27 Sep 2011 11:14:10 -0700 Received: from mail216.messagelabs.com ([85.158.143.99]) by lists.xensource.com with smtp (Exim 4.43) id 1R8c9l-00047h-S7 for xen-devel@lists.xensource.com; Tue, 27 Sep 2011 11:13:27 -0700 X-Env-Sender: caker@theshore.net X-Msg-Ref: server-5.tower-216.messagelabs.com!1317147202!17709983!1 X-Originating-IP: [67.18.92.50] X-StarScan-Version: 6.4.1; banners=-,-,- X-VirusChecked: Checked Received: (qmail 27939 invoked from network); 27 Sep 2011 18:13:22 -0000 Received: from ns.theshore.net (HELO www.theshore.net) (67.18.92.50) by server-5.tower-216.messagelabs.com with SMTP; 27 Sep 2011 18:13:22 -0000 Received: from beefcake.linlan (173-161-199-49-Philadelphia.hfc.comcastbusiness.net [173.161.199.49]) by www.theshore.net (8.13.6/8.9.1) with ESMTP id p8RIDLtI031684; Tue, 27 Sep 2011 14:13:21 -0400 Message-ID: <4E821241.6090602@theshore.net> Date: Tue, 27 Sep 2011 14:13:21 -0400 From: "Christopher S. Aker" <caker@theshore.net> User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.6; en-US; rv:1.9.2.22) Gecko/20110902 Lightning/1.0b2 Thunderbird/3.1.14 MIME-Version: 1.0 To: xen devel <xen-devel@lists.xensource.com> Subject: Re: [Xen-devel] Xen 4.1 + 3ware 9690SA = rejecting I/O to offline device References: <4CB38558.5060207@theshore.net> In-Reply-To: <4CB38558.5060207@theshore.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com> X-BeenThere: xen-devel@lists.xensource.com X-Mailman-Version: 2.1.5 Precedence: list List-Id: Xen developer discussion <xen-devel.lists.xensource.com> List-Unsubscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe> List-Post: <mailto:xen-devel@lists.xensource.com> List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help> List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=subscribe> Sender: xen-devel-bounces@lists.xensource.com Errors-To: xen-devel-bounces@lists.xensource.com On 10/11/10 5:44 PM, Christopher S. Aker wrote: > In an effort to fix the problem described in my previous xen-devel post > ("New CPUS, now get: NETDEV WATCHDOG: eth0: transmit timed out"), we've > come across another problem. 3ware 9690SA cards to not behave under Xen > 4.1 (as of cs 22155). > > We have a simple Xen thrash test suite which fires up domUs that do > different workloads (some swap thrash, some kernel build, some spin > CPUs, some cycle rebooting, etc). Almost immediately after launching the > suite we can get the 3ware 9690SA card to fail with something like the > following: > > sd 0:0:0:0: WARNING: (0x06:0x002C): Command (0x28) timed out, resetting > card. > sd 0:0:0:0: WARNING: (0x06:0x002C): Command (0x0) timed out, resetting > card. > sd 0:0:0:0: rejecting I/O to offline device > sd 0:0:0:0: rejecting I/O to offline device > > Under a 2.6.32 dom0 it sometimes also triggers Xenwatch like so: > > http://theshore.net/~caker/xen/BUGS/9690SA/xenwatch.txt > > Results matrix: > > +---------------------------------------------------------------+ > | Xen | Dom0 | 9550SXU | 9690SA | 9750 | > +---------------------------------------------------------------+ > | 3.4.1 | 2.6.18.8-931-2 | OK | OK | OK | > | 3.4.4-rc1-pre | 2.6.18.8-931-2 | OK | OK | OK | > | 3.4.4-rc1-pre | 2.6.32.23-g41a85de5 | OK | OK | OK | > | 4.1 @ 22155 | 2.6.18.8-931-2 | OK | FAIL | OK | > | 4.1 @ 22155 | 2.6.32.23-g41a85de5 | OK | FAIL | OK | > +---------------------------------------------------------------+ > > The failures were verified on at least 2 machines of identical > specification. > > The same dom0 kernels that produce a stable 9690SA under Xen 3.4, bomb > under Xen 4.1. I'm back at this, and the problem still exists with a 4.1.1/3.0.4 stack. Konrad, in the "offline raid" thread you asked for the following debug information: http://www.theshore.net/~caker/xen/BUGS/offline-raid/ The sysrq-t.txt and triple-a-star.txt outputs are after I got the raid card to hang up (but before it timed out and started spewing to the console). Oddly, lspci shows three devices assigned IRQ 16, however /proc/interrupts only lists two of them. Side effect of MSI? Also, the problem still happens even with MSI disabled (pci=nomsi). Thanks, -Chris _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel From xen-devel-bounces@lists.xensource.com Tue Sep 27 11:23:02 2011 Return-path: <xen-devel-bounces@lists.xensource.com> Envelope-to: www-data@lists.xensource.com Delivery-date: Tue, 27 Sep 2011 11:23:02 -0700 Received: from localhost ([127.0.0.1] helo=lists.colo.xensource.com) by lists.xensource.com with esmtp (Exim 4.43) id 1R8cJ4-0004u7-E0; Tue, 27 Sep 2011 11:23:02 -0700 Received: from mail27.messagelabs.com ([193.109.254.147]) by lists.xensource.com with esmtp (Exim 4.43) id 1R8cIY-0004hM-98 for xen-devel@lists.xensource.com; Tue, 27 Sep 2011 11:22:31 -0700 X-Env-Sender: Andrew.Cooper3@citrix.com X-Msg-Ref: server-6.tower-27.messagelabs.com!1317147726!50721567!1 X-Originating-IP: [62.200.22.115] X-StarScan-Version: 6.4.1; banners=-,-,- X-VirusChecked: Checked Received: (qmail 10576 invoked from network); 27 Sep 2011 18:22:06 -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; 27 Sep 2011 18:22:06 -0000 X-IronPort-AV: E=Sophos;i="4.68,450,1312156800"; d="scan'208";a="8090059" Received: from lonpmailmx01.citrite.net ([10.30.203.162]) by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5; 27 Sep 2011 18:22:27 +0000 Received: from [10.30.249.79] (10.30.249.79) by LONPMAILMX01.citrite.net (10.30.203.162) with Microsoft SMTP Server id 8.3.137.0; Tue, 27 Sep 2011 19:22:27 +0100 Message-ID: <4E821461.3060009@citrix.com> Date: Tue, 27 Sep 2011 19:22:25 +0100 From: Andrew Cooper <andrew.cooper3@citrix.com> User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:6.0.2) Gecko/20110902 Thunderbird/6.0.2 MIME-Version: 1.0 To: <xen-devel@lists.xensource.com> Subject: Re: [Xen-devel] Xen 4.1 + 3ware 9690SA = rejecting I/O to offline device References: <4CB38558.5060207@theshore.net> <4E821241.6090602@theshore.net> In-Reply-To: <4E821241.6090602@theshore.net> Content-Type: text/plain; charset="ISO-8859-1" Content-Transfer-Encoding: 7bit X-BeenThere: xen-devel@lists.xensource.com X-Mailman-Version: 2.1.5 Precedence: list List-Id: Xen developer discussion <xen-devel.lists.xensource.com> List-Unsubscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe> List-Post: <mailto:xen-devel@lists.xensource.com> List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help> List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=subscribe> Sender: xen-devel-bounces@lists.xensource.com Errors-To: xen-devel-bounces@lists.xensource.com On 27/09/2011 19:13, Christopher S. Aker wrote: > On 10/11/10 5:44 PM, Christopher S. Aker wrote: >> In an effort to fix the problem described in my previous xen-devel post >> ("New CPUS, now get: NETDEV WATCHDOG: eth0: transmit timed out"), we've >> come across another problem. 3ware 9690SA cards to not behave under Xen >> 4.1 (as of cs 22155). >> >> We have a simple Xen thrash test suite which fires up domUs that do >> different workloads (some swap thrash, some kernel build, some spin >> CPUs, some cycle rebooting, etc). Almost immediately after launching the >> suite we can get the 3ware 9690SA card to fail with something like the >> following: >> >> sd 0:0:0:0: WARNING: (0x06:0x002C): Command (0x28) timed out, resetting >> card. >> sd 0:0:0:0: WARNING: (0x06:0x002C): Command (0x0) timed out, resetting >> card. >> sd 0:0:0:0: rejecting I/O to offline device >> sd 0:0:0:0: rejecting I/O to offline device >> >> Under a 2.6.32 dom0 it sometimes also triggers Xenwatch like so: >> >> http://theshore.net/~caker/xen/BUGS/9690SA/xenwatch.txt >> >> Results matrix: >> >> +---------------------------------------------------------------+ >> | Xen | Dom0 | 9550SXU | 9690SA | 9750 | >> +---------------------------------------------------------------+ >> | 3.4.1 | 2.6.18.8-931-2 | OK | OK | OK | >> | 3.4.4-rc1-pre | 2.6.18.8-931-2 | OK | OK | OK | >> | 3.4.4-rc1-pre | 2.6.32.23-g41a85de5 | OK | OK | OK | >> | 4.1 @ 22155 | 2.6.18.8-931-2 | OK | FAIL | OK | >> | 4.1 @ 22155 | 2.6.32.23-g41a85de5 | OK | FAIL | OK | >> +---------------------------------------------------------------+ >> >> The failures were verified on at least 2 machines of identical >> specification. >> >> The same dom0 kernels that produce a stable 9690SA under Xen 3.4, bomb >> under Xen 4.1. > I'm back at this, and the problem still exists with a 4.1.1/3.0.4 stack. > > Konrad, in the "offline raid" thread you asked for the following debug > information: > > http://www.theshore.net/~caker/xen/BUGS/offline-raid/ > > The sysrq-t.txt and triple-a-star.txt outputs are after I got the raid > card to hang up (but before it timed out and started spewing to the > console). > > Oddly, lspci shows three devices assigned IRQ 16, however > /proc/interrupts only lists two of them. Side effect of MSI? > > Also, the problem still happens even with MSI disabled (pci=nomsi). > > Thanks, > -Chris This is almost certainly the bug to do with not ack'ing a migrating line level interrupt which I fixed in c/s 23145:1092a143ef9d. Try applying that patch, or just running from the tip of http://xenbits.xen.org/hg/xen-4.1-testing.hg/ ~Andrew > > > _______________________________________________ > Xen-devel mailing list > Xen-devel@lists.xensource.com > http://lists.xensource.com/xen-devel _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel From xen-devel-bounces@lists.xensource.com Tue Sep 27 12:35:42 2011 Return-path: <xen-devel-bounces@lists.xensource.com> Envelope-to: www-data@lists.xensource.com Delivery-date: Tue, 27 Sep 2011 12:35:42 -0700 Received: from localhost ([127.0.0.1] helo=lists.colo.xensource.com) by lists.xensource.com with esmtp (Exim 4.43) id 1R8dRO-0001zu-1n; Tue, 27 Sep 2011 12:35:42 -0700 Received: from mail21.messagelabs.com ([85.158.143.35]) by lists.xensource.com with smtp (Exim 4.43) id 1R8dPc-0001lP-NH for xen-devel@lists.xensource.com; Tue, 27 Sep 2011 12:33:53 -0700 X-Env-Sender: caker@theshore.net X-Msg-Ref: server-11.tower-21.messagelabs.com!1317152011!44219693!1 X-Originating-IP: [67.18.92.50] X-StarScan-Version: 6.4.1; banners=-,-,- X-VirusChecked: Checked Received: (qmail 22836 invoked from network); 27 Sep 2011 19:33:31 -0000 Received: from ns.theshore.net (HELO www.theshore.net) (67.18.92.50) by server-11.tower-21.messagelabs.com with SMTP; 27 Sep 2011 19:33:31 -0000 Received: from beefcake.linlan (173-161-199-49-Philadelphia.hfc.comcastbusiness.net [173.161.199.49]) by www.theshore.net (8.13.6/8.9.1) with ESMTP id p8RJXlN5015489; Tue, 27 Sep 2011 15:33:47 -0400 Message-ID: <4E82251B.409@theshore.net> Date: Tue, 27 Sep 2011 15:33:47 -0400 From: "Christopher S. Aker" <caker@theshore.net> User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.6; en-US; rv:1.9.2.22) Gecko/20110902 Lightning/1.0b2 Thunderbird/3.1.14 MIME-Version: 1.0 To: Andrew Cooper <andrew.cooper3@citrix.com> Subject: Re: [Xen-devel] Xen 4.1 + 3ware 9690SA = rejecting I/O to offline device References: <4CB38558.5060207@theshore.net> <4E821241.6090602@theshore.net> <4E821461.3060009@citrix.com> In-Reply-To: <4E821461.3060009@citrix.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: xen-devel@lists.xensource.com, Konrad Rzeszutek Wilk <konrad.wilk@oracle.com> X-BeenThere: xen-devel@lists.xensource.com X-Mailman-Version: 2.1.5 Precedence: list List-Id: Xen developer discussion <xen-devel.lists.xensource.com> List-Unsubscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe> List-Post: <mailto:xen-devel@lists.xensource.com> List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help> List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=subscribe> Sender: xen-devel-bounces@lists.xensource.com Errors-To: xen-devel-bounces@lists.xensource.com On 9/27/11 2:22 PM, Andrew Cooper wrote: > This is almost certainly the bug to do with not ack'ing a migrating line > level interrupt which I fixed in c/s 23145:1092a143ef9d. Try applying > that patch, or just running from the tip of > http://xenbits.xen.org/hg/xen-4.1-testing.hg/ That was it! You're a champion. Thanks, -Chris _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel From xen-devel-bounces@lists.xensource.com Tue Sep 27 12:38:09 2011 Return-path: <xen-devel-bounces@lists.xensource.com> Envelope-to: www-data@lists.xensource.com Delivery-date: Tue, 27 Sep 2011 12:38:09 -0700 Received: from localhost ([127.0.0.1] helo=lists.colo.xensource.com) by lists.xensource.com with esmtp (Exim 4.43) id 1R8dTk-0002V1-TU; Tue, 27 Sep 2011 12:38:09 -0700 Received: from mail216.messagelabs.com ([85.158.143.99]) by lists.xensource.com with esmtp (Exim 4.43) id 1R8dRC-0001yC-Ms for xen-devel@lists.xensource.com; Tue, 27 Sep 2011 12:35:32 -0700 X-Env-Sender: tytso@thunk.org X-Msg-Ref: server-7.tower-216.messagelabs.com!1317152126!19807658!1 X-Originating-IP: [67.18.176.11] X-StarScan-Version: 6.4.1; banners=-,-,- X-VirusChecked: Checked Received: (qmail 2989 invoked from network); 27 Sep 2011 19:35:27 -0000 Received: from li9-11.members.linode.com (HELO test.thunk.org) (67.18.176.11) by server-7.tower-216.messagelabs.com with AES256-SHA encrypted SMTP; 27 Sep 2011 19:35:27 -0000 Received: from root (helo=tytso-glaptop.cam.corp.google.com) by test.thunk.org with local-esmtp (Exim 4.69) (envelope-from <tytso@thunk.org>) id 1R8dR6-0000Tb-Eh; Tue, 27 Sep 2011 19:35:24 +0000 Received: from tytso by tytso-glaptop.cam.corp.google.com with local (Exim 4.71) (envelope-from <tytso@thunk.org>) id 1R8dR5-00012G-Cc; Tue, 27 Sep 2011 15:35:23 -0400 Date: Tue, 27 Sep 2011 15:35:23 -0400 From: Ted Ts'o <tytso@mit.edu> To: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com> Message-ID: <20110927193523.GB3309@thunk.org> References: <BLU157-W499E698F650F554E645F9DDA1C0@phx.gbl> <20110906145347.GA4133@dumpdata.com> <BLU157-W4106FA4CF4EBA78C63FDA0DA1C0@phx.gbl> <4E666C86.5090707@goop.org> <BLU157-W323C330706CB8D7E976BC3DA1F0@phx.gbl> <BLU157-W7DABA5FE01C50C29B1A64DA060@phx.gbl> <BLU157-W25EB1EAC24CC11FA14859ADAF20@phx.gbl> <20110926142808.GG4102@phenom.oracle.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20110926142808.GG4102@phenom.oracle.com> User-Agent: Mutt/1.5.20 (2009-06-14) X-SA-Exim-Connect-IP: <locally generated> X-SA-Exim-Mail-From: tytso@thunk.org X-SA-Exim-Scanned: No (on test.thunk.org); SAEximRunCond expanded to false Cc: MaoXiaoyun <tinnycloud@hotmail.com>, linux-ext4@vger.kernel.org, jack@suse.cz, xen devel <xen-devel@lists.xensource.com> Subject: [Xen-devel] Re: [patch 1/1] ext4-fix-dirty-extent-when-origin-leaf-extent-reac.patch X-BeenThere: xen-devel@lists.xensource.com X-Mailman-Version: 2.1.5 Precedence: list List-Id: Xen developer discussion <xen-devel.lists.xensource.com> List-Unsubscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe> List-Post: <mailto:xen-devel@lists.xensource.com> List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help> List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=subscribe> Sender: xen-devel-bounces@lists.xensource.com Errors-To: xen-devel-bounces@lists.xensource.com On Mon, Sep 26, 2011 at 10:28:08AM -0400, Konrad Rzeszutek Wilk wrote: > > > > Attached is the fix, verified in our env. > > So.. you are asking for this upstream git commit to be back-ported > to 2.6.32, right? I'm curious --- is there a good reason why Xen users are using an upstream 2.6.32 kernel? If they are using a distro kernel, fine, but then the distro kernel should be providing the support. But at this point, 2.6.32 is so positively *ancient* that, I'm personally not interesting in providing free, unpaid distro support for users who aren't willing to either (a) pay $$$ and get a supported distro kernel, or (b) use a much more modern kernel. At this point, Guest and Host Xen support is available in 3.0 kernels, so there's really no excuse, right? - Ted _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel From xen-devel-bounces@lists.xensource.com Tue Sep 27 12:44:33 2011 Return-path: <xen-devel-bounces@lists.xensource.com> Envelope-to: www-data@lists.xensource.com Delivery-date: Tue, 27 Sep 2011 12:44:33 -0700 Received: from localhost ([127.0.0.1] helo=lists.colo.xensource.com) by lists.xensource.com with esmtp (Exim 4.43) id 1R8dZx-0002z6-KO; Tue, 27 Sep 2011 12:44:33 -0700 Received: from mail216.messagelabs.com ([85.158.143.99]) by lists.xensource.com with esmtp (Exim 4.43) id 1R8dZF-0002mf-3c for xen-devel@lists.xensource.com; Tue, 27 Sep 2011 12:43:49 -0700 X-Env-Sender: chintamani.sid@gmail.com X-Msg-Ref: server-12.tower-216.messagelabs.com!1317152625!14059272!1 X-Originating-IP: [209.85.161.43] X-StarScan-Version: 6.4.1; banners=-,-,- X-VirusChecked: Checked Received: (qmail 10996 invoked from network); 27 Sep 2011 19:43:46 -0000 Received: from mail-fx0-f43.google.com (HELO mail-fx0-f43.google.com) (209.85.161.43) by server-12.tower-216.messagelabs.com with RC4-SHA encrypted SMTP; 27 Sep 2011 19:43:46 -0000 Received: by fxh19 with SMTP id 19so9615649fxh.30 for <xen-devel@lists.xensource.com>; Tue, 27 Sep 2011 12:43:45 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:date:message-id:subject:from:to:content-type; bh=NZqB4r9y1py3k9/j7zInZoq8flO5SJH4H1EYyc67puQ=; b=UY+hF7d7hBCA13+zuuVZtXzdFeT0cEmajfISsec699gBPMDKDVxrkj5hFAX4jQQ6dl WF/LU5Fees+dOfhAJg7mAj9RCliUYLmnTKF0QLb7TOAb/0vcb+XXpEfxHZQjE+7ybk2e SXU//wa87hJzkPdx0gDSfzYGGvzfAAO7iKjcs= MIME-Version: 1.0 Received: by 10.223.45.198 with SMTP id g6mr651949faf.118.1317152625792; Tue, 27 Sep 2011 12:43:45 -0700 (PDT) Received: by 10.152.19.67 with HTTP; Tue, 27 Sep 2011 12:43:45 -0700 (PDT) Date: Tue, 27 Sep 2011 14:43:45 -0500 Message-ID: <CANF5qa8onMK72CF1axDn1bngaqVEeyEfoBMicMjEJJ0hs4kjqQ@mail.gmail.com> From: chintamani siddheshwar <chintamani.sid@gmail.com> To: xen-devel@lists.xensource.com Subject: [Xen-devel] Getting the page fault count for a guest X-BeenThere: xen-devel@lists.xensource.com X-Mailman-Version: 2.1.5 Precedence: list List-Id: Xen developer discussion <xen-devel.lists.xensource.com> List-Unsubscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe> List-Post: <mailto:xen-devel@lists.xensource.com> List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help> List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=subscribe> Content-Type: multipart/mixed; boundary="===============1645784183==" Sender: xen-devel-bounces@lists.xensource.com Errors-To: xen-devel-bounces@lists.xensource.com --===============1645784183== Content-Type: multipart/alternative; boundary=0015173fe8226018d104adf17edd --0015173fe8226018d104adf17edd Content-Type: text/plain; charset=ISO-8859-1 Hi How can I get hold of page fault count for a guest? I am also curious to know how I can get this count for each guest within each scheduling period. thanks Chintu --0015173fe8226018d104adf17edd Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Hi<br>=A0 <br>=A0=A0 How can I get hold of page fault count for a guest?<br= >=A0=A0 I am also curious to know how I can get this count for each guest w= ithin each scheduling period.<br><br>=A0=A0=A0 thanks<br>=A0=A0=A0 Chintu<b= r><br>=A0=A0=A0 <br> --0015173fe8226018d104adf17edd-- --===============1645784183== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel --===============1645784183==-- From xen-devel-bounces@lists.xensource.com Tue Sep 27 13:28:58 2011 Return-path: <xen-devel-bounces@lists.xensource.com> Envelope-to: www-data@lists.xensource.com Delivery-date: Tue, 27 Sep 2011 13:28:58 -0700 Received: from localhost ([127.0.0.1] helo=lists.colo.xensource.com) by lists.xensource.com with esmtp (Exim 4.43) id 1R8eGw-0004h2-IW; Tue, 27 Sep 2011 13:28:58 -0700 Received: from mail216.messagelabs.com ([85.158.143.99]) by lists.xensource.com with esmtp (Exim 4.43) id 1R8eEN-0003v6-M4 for xen-devel@lists.xensource.com; Tue, 27 Sep 2011 13:26:20 -0700 X-Env-Sender: dan.magenheimer@oracle.com X-Msg-Ref: server-11.tower-216.messagelabs.com!1317155175!12231279!1 X-Originating-IP: [141.146.126.227] X-StarScan-Version: 6.4.1; banners=-,-,- X-VirusChecked: Checked Received: (qmail 4088 invoked from network); 27 Sep 2011 20:26:16 -0000 Received: from acsinet15.oracle.com (HELO acsinet15.oracle.com) (141.146.126.227) by server-11.tower-216.messagelabs.com with DHE-RSA-AES256-SHA encrypted SMTP; 27 Sep 2011 20:26:16 -0000 Received: from ucsinet24.oracle.com (ucsinet24.oracle.com [156.151.31.67]) by acsinet15.oracle.com (Switch-3.4.4/Switch-3.4.4) with ESMTP id p8RKQA3Z021308 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Tue, 27 Sep 2011 20:26:12 GMT Received: from acsmt357.oracle.com (acsmt357.oracle.com [141.146.40.157]) by ucsinet24.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id p8RKKUlg018513 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 27 Sep 2011 20:20:30 GMT Received: from abhmt101.oracle.com (abhmt101.oracle.com [141.146.116.53]) by acsmt357.oracle.com (8.12.11.20060308/8.12.11) with ESMTP id p8RKQ16T031206; Tue, 27 Sep 2011 15:26:01 -0500 MIME-Version: 1.0 Message-ID: <93d51294-ba6f-43e5-bf79-15c966a6c8ec@default> Date: Tue, 27 Sep 2011 13:25:39 -0700 (PDT) From: Dan Magenheimer <dan.magenheimer@oracle.com> To: David Vrabel <david.vrabel@citrix.com> References: <2de59b55-4ecc-4155-8709-f8b0f5e012bc@default> <4E81F278.5040107@citrix.com> <f42e2a83-15f6-4767-a7df-8a23ceac239e@default 4E820316.6070101@citrix.com> In-Reply-To: <4E820316.6070101@citrix.com> X-Priority: 3 X-Mailer: Oracle Beehive Extensions for Outlook 2.0.1.4.1.0 (410211) [OL 12.0.6557.5001] Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable X-Source-IP: ucsinet24.oracle.com [156.151.31.67] X-CT-RefId: str=0001.0A090206.4E823164.00B8,ss=1,re=0.000,fgs=0 Cc: Jeremy Fitzhardinge <jeremy@goop.org>, xen-devel@lists.xensource.com, linux-kernel@vger.kernel.org, Konrad Wilk <konrad.wilk@oracle.com> Subject: [Xen-devel] RE: [PATCH v2] xen: Fix selfballooning and ensure it doesn't go too far X-BeenThere: xen-devel@lists.xensource.com X-Mailman-Version: 2.1.5 Precedence: list List-Id: Xen developer discussion <xen-devel.lists.xensource.com> List-Unsubscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe> List-Post: <mailto:xen-devel@lists.xensource.com> List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help> List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=subscribe> Sender: xen-devel-bounces@lists.xensource.com Errors-To: xen-devel-bounces@lists.xensource.com > From: David Vrabel [mailto:david.vrabel@citrix.com] > Cc: Konrad Wilk; linux-kernel@vger.kernel.org; xen-devel@lists.xensource.= com; Jeremy Fitzhardinge > Subject: Re: [PATCH v2] xen: Fix selfballooning and ensure it doesn't go = too far >=20 > On 27/09/11 17:19, Dan Magenheimer wrote: > >> From: David Vrabel [mailto:david.vrabel@citrix.com] > >> Subject: Re: [PATCH v2] xen: Fix selfballooning and ensure it doesn't = go too far > >> > >> On 27/09/11 16:03, Dan Magenheimer wrote: > >>> Note: This patch is also now in a git tree at: > >>> > >>> git://oss.oracle.com/git/djm/tmem.git#selfballoon-fix-v2 > >>> > >>> The balloon driver's "current_pages" is very different from > >>> totalram_pages. Self-ballooning needs to be driven by > >>> the latter. > > > > Hi David -- > > > > Thanks for the feedback! > > > >> I don't think this part of the change makes any difference. It looks l= ike it > >> rearranges the maths without changing the end result (other than > >> slightly increasing the rate of change). > >> I think this (partial, untested) patch is equivalent: > > > > Actually it does. >=20 > Really? >=20 > Both patched and unpatched the new target, S, is (eventually): >=20 > S =3D V + F + C - T >=20 > where V is vm_committed_as, F is frontswap_curr_pages(), C is > balloon_stats.current_pages, and T =3D totalram_pages. Sorry, in my haste to shoot off a quick reply while my mind was somewhere else, I see my reply was poor and misleading. Yes, "S", the value passed to balloon_set_new_target(), is the same in most cases. However, it is V+F, not S, that must be compared against M (=3D the floor function); the "target" of selfballooning, the value that the kernel cares about (not the value that Xen cares about) is max(V+F,M). This gets converted to Xen-cares-about, IOW: =09S =3D max(V+F,M) + C - T where S is passed to balloon_set_new_target. > Perhaps the refactoring of the maths is a good idea (I don't think so) > but it shouldn't be part of this patch and it shouldn't be described as > a fix. The refactored version makes sense now from a kernel perspective, though I can see how it might be confusing from a Xen perspective, especially to a balloon driver expert such as yourself. It is most definitely a fix because the formula is different and OOMs that previously happened no longer happen. I don't think the commit comment describes the *refactoring* as a fix, just says that self-ballooning needs to be driven by kernel- cares-about values (even if it has to interface to the Xen balloon driver with a Xen-cares-about parameter). Hopefully that makes more sense? Dan _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel From xen-devel-bounces@lists.xensource.com Tue Sep 27 14:06:28 2011 Return-path: <xen-devel-bounces@lists.xensource.com> Envelope-to: www-data@lists.xensource.com Delivery-date: Tue, 27 Sep 2011 14:06:28 -0700 Received: from localhost ([127.0.0.1] helo=lists.colo.xensource.com) by lists.xensource.com with esmtp (Exim 4.43) id 1R8erE-0007EE-JP; Tue, 27 Sep 2011 14:06:28 -0700 Received: from mail174.messagelabs.com ([85.158.138.51]) by lists.xensource.com with esmtp (Exim 4.43) id 1R8epk-00070w-JY for xen-devel@lists.xensource.com; Tue, 27 Sep 2011 14:04:59 -0700 X-Env-Sender: Ian.Jackson@eu.citrix.com X-Msg-Ref: server-15.tower-174.messagelabs.com!1317157493!26651122!1 X-Originating-IP: [62.200.22.115] X-StarScan-Version: 6.4.1; banners=-,-,- X-VirusChecked: Checked Received: (qmail 6194 invoked from network); 27 Sep 2011 21:04:53 -0000 Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115) by server-15.tower-174.messagelabs.com with RC4-SHA encrypted SMTP; 27 Sep 2011 21:04:53 -0000 X-IronPort-AV: E=Sophos;i="4.68,451,1312156800"; d="scan'208";a="8091556" Received: from lonpmailmx01.citrite.net ([10.30.203.162]) by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5; 27 Sep 2011 21:04:52 +0000 Received: from woking.xci-test.com (10.80.248.135) by smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id 8.3.137.0; Tue, 27 Sep 2011 22:04:52 +0100 Received: from osstest by woking.xci-test.com with local (Exim 4.69) (envelope-from <ian.jackson@eu.citrix.com>) id 1R8epg-0005XZ-Hw; Tue, 27 Sep 2011 22:04:52 +0100 To: xen-devel@lists.xensource.com Message-ID: <osstest-9105-mainreport@xen.org> From: xen.org <ian.jackson@eu.citrix.com> Date: Tue, 27 Sep 2011 22:04:52 +0100 MIME-Version: 1.0 Content-Type: text/plain Cc: ian.jackson@eu.citrix.com Subject: [Xen-devel] [xen-unstable test] 9105: regressions - FAIL X-BeenThere: xen-devel@lists.xensource.com X-Mailman-Version: 2.1.5 Precedence: list List-Id: Xen developer discussion <xen-devel.lists.xensource.com> List-Unsubscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe> List-Post: <mailto:xen-devel@lists.xensource.com> List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help> List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=subscribe> Sender: xen-devel-bounces@lists.xensource.com Errors-To: xen-devel-bounces@lists.xensource.com flight 9105 xen-unstable real [real] http://www.chiark.greenend.org.uk/~xensrcts/logs/9105/ Regressions :-( Tests which did not succeed and are blocking: test-i386-i386-win 14 guest-start.2 fail REGR. vs. 8995 Tests which did not succeed, but are not blocking, including regressions (tests previously passed) regarded as allowable: test-amd64-amd64-xl-pcipt-intel 9 guest-start fail never pass test-amd64-i386-rhel6hvm-intel 9 guest-start.2 fail never pass test-amd64-i386-win-vcpus1 16 leak-check/check fail never pass test-amd64-i386-rhel6hvm-amd 9 guest-start.2 fail never pass test-amd64-amd64-win 16 leak-check/check fail never pass test-amd64-i386-xl-win-vcpus1 13 guest-stop fail never pass test-amd64-i386-win 16 leak-check/check fail never pass test-amd64-amd64-xl-win 13 guest-stop fail never pass test-i386-i386-xl-win 13 guest-stop fail never pass version targeted for testing: xen bfa65eb40b2a baseline version: xen a422e2a4451e ------------------------------------------------------------ People who touched revisions under test: Andreas Herrmann <herrmann.der.user@googlemail.com> Ian Campbell <ian.campbell@citrix.com> Ian Jackson <ian.jackson@eu.citrix.com> Jan Beulich <jbeulich@suse.com> Lasse Collin <lasse.collin@tukaani.org> Olaf Hering <olaf@aepfle.de> Paul Durrant <paul.durrant@citrix.com> Thomas Renninger <trenn@suse.de> Tim Deegan <tim@xen.org> ------------------------------------------------------------ jobs: build-amd64 pass build-i386 pass build-amd64-oldkern pass build-i386-oldkern pass build-amd64-pvops pass build-i386-pvops pass test-amd64-amd64-xl pass test-amd64-i386-xl pass test-i386-i386-xl pass test-amd64-i386-rhel6hvm-amd fail test-amd64-i386-xl-credit2 pass test-amd64-amd64-xl-pcipt-intel fail test-amd64-i386-rhel6hvm-intel fail test-amd64-i386-xl-multivcpu pass test-amd64-amd64-pair pass test-amd64-i386-pair pass test-i386-i386-pair pass test-amd64-amd64-pv pass test-amd64-i386-pv pass test-i386-i386-pv pass test-amd64-amd64-xl-sedf pass test-amd64-i386-win-vcpus1 fail test-amd64-i386-xl-win-vcpus1 fail test-amd64-amd64-win fail test-amd64-i386-win fail test-i386-i386-win fail test-amd64-amd64-xl-win fail test-i386-i386-xl-win fail ------------------------------------------------------------ sg-report-flight on woking.cam.xci-test.com logs: /home/xc_osstest/logs images: /home/xc_osstest/images Logs, config files, etc. are available at http://www.chiark.greenend.org.uk/~xensrcts/logs Test harness code can be found at http://xenbits.xensource.com/gitweb?p=osstest.git;a=summary Not pushing. (No revision log; it would be 318 lines long.) _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel From xen-devel-bounces@lists.xensource.com Tue Sep 27 14:59:08 2011 Return-path: <xen-devel-bounces@lists.xensource.com> Envelope-to: www-data@lists.xensource.com Delivery-date: Tue, 27 Sep 2011 14:59:08 -0700 Received: from localhost ([127.0.0.1] helo=lists.colo.xensource.com) by lists.xensource.com with esmtp (Exim 4.43) id 1R8fgA-0000Gl-NX; Tue, 27 Sep 2011 14:59:06 -0700 Received: from mail174.messagelabs.com ([85.158.138.51]) by lists.xensource.com with esmtp (Exim 4.43) id 1R8feZ-0008VU-DO for Xen-devel@lists.xensource.com; Tue, 27 Sep 2011 14:57:28 -0700 X-Env-Sender: mukesh.rathor@oracle.com X-Msg-Ref: server-11.tower-174.messagelabs.com!1317160642!32990780!1 X-Originating-IP: [148.87.113.117] X-StarScan-Version: 6.4.1; banners=-,-,- X-VirusChecked: Checked Received: (qmail 5927 invoked from network); 27 Sep 2011 21:57:24 -0000 Received: from rcsinet15.oracle.com (HELO rcsinet15.oracle.com) (148.87.113.117) by server-11.tower-174.messagelabs.com with DHE-RSA-AES256-SHA encrypted SMTP; 27 Sep 2011 21:57:24 -0000 Received: from acsinet22.oracle.com (acsinet22.oracle.com [141.146.126.238]) by rcsinet15.oracle.com (Switch-3.4.4/Switch-3.4.4) with ESMTP id p8RLvKd9030153 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK) for <Xen-devel@lists.xensource.com>; Tue, 27 Sep 2011 21:57:22 GMT Received: from acsmt357.oracle.com (acsmt357.oracle.com [141.146.40.157]) by acsinet22.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id p8RLvJv9007352 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for <Xen-devel@lists.xensource.com>; Tue, 27 Sep 2011 21:57:20 GMT Received: from abhmt118.oracle.com (abhmt118.oracle.com [141.146.116.70]) by acsmt357.oracle.com (8.12.11.20060308/8.12.11) with ESMTP id p8RLvE24032744 for <Xen-devel@lists.xensource.com>; Tue, 27 Sep 2011 16:57:14 -0500 Received: from mantra.us.oracle.com (/130.35.68.95) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Tue, 27 Sep 2011 14:57:14 -0700 Date: Tue, 27 Sep 2011 14:57:13 -0700 From: Mukesh Rathor <mukesh.rathor@oracle.com> To: "Xen-devel@lists.xensource.com" <Xen-devel@lists.xensource.com> Message-ID: <20110927145713.7d04a4f3@mantra.us.oracle.com> Organization: Oracle Corporation X-Mailer: Claws Mail 3.7.6 (GTK+ 2.18.9; x86_64-redhat-linux-gnu) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-Source-IP: acsinet22.oracle.com [141.146.126.238] X-Auth-Type: Internal IP X-CT-RefId: str=0001.0A090202.4E8246C2.0085:SCFMA922111,ss=1,re=-4.000,fgs=0 Cc: Subject: [Xen-devel] help: monitor table and hap X-BeenThere: xen-devel@lists.xensource.com X-Mailman-Version: 2.1.5 Precedence: list List-Id: Xen developer discussion <xen-devel.lists.xensource.com> List-Unsubscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe> List-Post: <mailto:xen-devel@lists.xensource.com> List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help> List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=subscribe> Sender: xen-devel-bounces@lists.xensource.com Errors-To: xen-devel-bounces@lists.xensource.com Hi, I'm trying to figure what the purpose of monitor_table is? It seems to be used for shadow_mode_external, which I understand doesn't apply to HAP mode? thanks, Mukesh _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel From xen-devel-bounces@lists.xensource.com Tue Sep 27 15:09:27 2011 Return-path: <xen-devel-bounces@lists.xensource.com> Envelope-to: www-data@lists.xensource.com Delivery-date: Tue, 27 Sep 2011 15:09:27 -0700 Received: from localhost ([127.0.0.1] helo=lists.colo.xensource.com) by lists.xensource.com with esmtp (Exim 4.43) id 1R8fqA-0000nL-SJ; Tue, 27 Sep 2011 15:09:26 -0700 Received: from mail21.messagelabs.com ([85.158.143.35]) by lists.xensource.com with esmtp (Exim 4.43) id 1R8foA-0000ZI-4U for xen-devel@lists.xensource.com; Tue, 27 Sep 2011 15:07:24 -0700 X-Env-Sender: konrad@oracle.com X-Msg-Ref: server-6.tower-21.messagelabs.com!1317161217!39902041!1 X-Originating-IP: [141.146.126.227] X-StarScan-Version: 6.4.1; banners=-,-,- X-VirusChecked: Checked Received: (qmail 14981 invoked from network); 27 Sep 2011 22:06:58 -0000 Received: from acsinet15.oracle.com (HELO acsinet15.oracle.com) (141.146.126.227) by server-6.tower-21.messagelabs.com with DHE-RSA-AES256-SHA encrypted SMTP; 27 Sep 2011 22:06:58 -0000 Received: from ucsinet23.oracle.com (ucsinet23.oracle.com [156.151.31.71]) by acsinet15.oracle.com (Switch-3.4.4/Switch-3.4.4) with ESMTP id p8RM7Fjw010479 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Tue, 27 Sep 2011 22:07:16 GMT Received: from acsmt358.oracle.com (acsmt358.oracle.com [141.146.40.158]) by ucsinet23.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id p8RM7EVF007421 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 27 Sep 2011 22:07:14 GMT Received: from abhmt105.oracle.com (abhmt105.oracle.com [141.146.116.57]) by acsmt358.oracle.com (8.12.11.20060308/8.12.11) with ESMTP id p8RM78V2029134; Tue, 27 Sep 2011 17:07:08 -0500 Received: from oracle.com (/207.172.105.198) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Tue, 27 Sep 2011 15:07:08 -0700 Received: by oracle.com (Postfix, from userid 1000) id C4F531544; Tue, 27 Sep 2011 18:07:07 -0400 (EDT) Date: Tue, 27 Sep 2011 18:07:07 -0400 From: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com> To: "Christopher S. Aker" <caker@theshore.net> Subject: Re: [Xen-devel] dom0: kernel BUG at mm/vmalloc.c:2165! Message-ID: <20110927220707.GA10820@phenom.oracle.com> References: <4E80EA16.6010609@theshore.net> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <4E80EA16.6010609@theshore.net> User-Agent: Mutt/1.5.21 (2010-09-15) X-Source-IP: ucsinet23.oracle.com [156.151.31.71] X-CT-RefId: str=0001.0A090206.4E824915.0029,ss=1,re=0.000,fgs=0 Cc: xen devel <xen-devel@lists.xensource.com> X-BeenThere: xen-devel@lists.xensource.com X-Mailman-Version: 2.1.5 Precedence: list List-Id: Xen developer discussion <xen-devel.lists.xensource.com> List-Unsubscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe> List-Post: <mailto:xen-devel@lists.xensource.com> List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help> List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=subscribe> Sender: xen-devel-bounces@lists.xensource.com Errors-To: xen-devel-bounces@lists.xensource.com On Mon, Sep 26, 2011 at 05:09:42PM -0400, Christopher S. Aker wrote: > Xen 4.1.1 > 3.0.4 dom0 > > While trying to boot the first (and only) domU on the freshly-booted > box (two attempts). > > Is this a symptom of my dom0 lacking the 'vmalloc_sync_all()' patch > discussed recently? - http://lkml.org/lkml/2011/9/2/114 - I just > want to make sure this isn't something unexpected. Yup. That is exactly what you will hit. And the fix is to use vmalloc_sync_all (which also should show up in 3.0.5). > > > device vif1.0 entered promiscuous mode > ADDRCONF(NETDEV_UP): vif1.0: link is not ready > xen-blkback:ring-ref 8, event-channel 27, protocol 1 (x86_32-abi) > xen-blkback:ring-ref 9, event-channel 28, protocol 1 (x86_32-abi) > ADDRCONF(NETDEV_CHANGE): vif1.0: link becomes ready > br0: port 3(vif1.0) entering forwarding state > br0: port 3(vif1.0) entering forwarding state > br0: port 3(vif1.0) entering forwarding state > br0: port 3(vif1.0) entering forwarding state > device vif1.0 left promiscuous mode > br0: port 3(vif1.0) entering disabled state > device vif2.0 entered promiscuous mode > ADDRCONF(NETDEV_UP): vif2.0: link is not ready > xen-blkback:ring-ref 8, event-channel 27, protocol 1 (x86_32-abi) > (XEN) mm.c:3846:d0 Could not find L1 PTE for address f7e22000 > vbd vbd-2-51712: 1 mapping ring-ref 8 port 27 > xen-blkback:ring-ref 9, event-channel 28, protocol 1 (x86_32-abi) > (XEN) mm.c:3846:d0 Could not find L1 PTE for address f7e24000 > vbd vbd-2-51728: 1 mapping ring-ref 9 port 28 > (XEN) mm.c:3846:d0 Could not find L1 PTE for address f7e26000 > vif vif-2-0: vif2.0: failed to map tx ring. err=-12 status=-1 > vif vif-2-0: 1 mapping shared-frames 768/769 port 29 > br0: port 3(vif2.0) entering disabled state > device vif2.0 left promiscuous mode > br0: port 3(vif2.0) entering disabled state > ------------[ cut here ]------------ > kernel BUG at mm/vmalloc.c:2165! > invalid opcode: 0000 [#1] SMP > Modules linked in: ebt_arp ip6t_rt ebt_mark ebt_limit xt_mark > ip6table_mangle ebtable_nat ebtable_filter > > Pid: 39, comm: xenwatch Not tainted 3.0.4-1 #1 Supermicro X8DTU/X8DTU > EIP: 0061:[<c10e492c>] EFLAGS: 00010282 CPU: 5 > EIP is at free_vm_area+0x1c/0x20 > EAX: 00000000 EBX: e8d4b940 ECX: 00000001 EDX: 00000000 > ESI: e94db46c EDI: e9b7fa20 EBP: eb1d9e24 ESP: eb1d9e20 > DS: 007b ES: 007b FS: 00d8 GS: 0000 SS: 0069 > Process xenwatch (pid: 39, ti=eb1d8000 task=eb11b0c0 task.ti=eb1d8000) > Stack: > e94db3c0 eb1d9e54 c14ecf8a e94db3c0 eb1d9e2c e94db000 e94db46c e9b7fa20 > eb1d9e48 c15ba8d8 e94db3c0 e94db46c e9b7fa20 eb1d9e84 c14efd46 c139748f > eabe22e0 eabe22e0 00000000 e9b7fa20 eb1d9e84 c139748f eb12f060 e9b7fa00 > Call Trace: > [<c14ecf8a>] xen_netbk_unmap_frontend_rings+0xda/0x100 > [<c15ba8d8>] ? rtnl_unlock+0x8/0x10 > [<c14efd46>] xenvif_disconnect+0xb6/0x110 > [<c139748f>] ? xenbus_rm+0x3f/0x50 > [<c139748f>] ? xenbus_rm+0x3f/0x50 > [<c14eebff>] netback_remove+0x4f/0x80 > [<c13982d7>] xenbus_dev_remove+0x37/0x50 > [<c1437a1e>] __device_release_driver+0x3e/0x90 > [<c1437b30>] device_release_driver+0x20/0x40 > [<c1436e9b>] bus_remove_device+0x7b/0xa0 > [<c1435557>] device_del+0xe7/0x170 > [<c14355eb>] device_unregister+0xb/0x20 > [<c14eed7e>] frontend_changed+0x8e/0x650 > [<c139762d>] ? xenbus_read+0x3d/0x50 > [<c1397671>] ? xenbus_gather+0x31/0x90 > [<c10066c4>] ? check_events+0x8/0xc > [<c13958f5>] ? xenbus_read_driver_state+0x35/0x50 > [<c139852d>] xenbus_otherend_changed+0x7d/0x90 > [<c1398732>] frontend_changed+0x12/0x20 > [<c1396aa5>] xenwatch_thread+0x85/0x130 > [<c10625d0>] ? wake_up_bit+0x60/0x60 > [<c1396a20>] ? split+0xd0/0xd0 > [<c10621e4>] kthread+0x74/0x80 > [<c1062170>] ? kthread_worker_fn+0x160/0x160 > [<c16ca2b6>] kernel_thread_helper+0x6/0x10 > Code: 00 10 00 00 eb a3 89 f6 8d bc 27 00 00 00 00 55 89 e5 53 89 c3 > 8b 40 04 e8 72 ff ff ff 39 c3 75 0a 89 d8 e8 27 cf 00 00 5b 5d c3 > <0f> 0b eb fe 55 85 d2 89 e5 57 89 d7 56 53 89 c3 7e 11 31 f6 8b > EIP: [<c10e492c>] free_vm_area+0x1c/0x20 SS:ESP 0069:eb1d9e20 > ---[ end trace 8c2c7e19ece622c9 ]--- > > Thanks, > -Chris > > > _______________________________________________ > Xen-devel mailing list > Xen-devel@lists.xensource.com > http://lists.xensource.com/xen-devel _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel From xen-devel-bounces@lists.xensource.com Tue Sep 27 15:19:11 2011 Return-path: <xen-devel-bounces@lists.xensource.com> Envelope-to: www-data@lists.xensource.com Delivery-date: Tue, 27 Sep 2011 15:19:11 -0700 Received: from localhost ([127.0.0.1] helo=lists.colo.xensource.com) by lists.xensource.com with esmtp (Exim 4.43) id 1R8fzb-0001Ot-0Z; Tue, 27 Sep 2011 15:19:11 -0700 Received: from mail27.messagelabs.com ([193.109.254.147]) by lists.xensource.com with esmtp (Exim 4.43) id 1R8fyp-0001CI-7m for Xen-devel@lists.xensource.com; Tue, 27 Sep 2011 15:18:23 -0700 X-Env-Sender: tim@xen.org X-Msg-Ref: server-12.tower-27.messagelabs.com!1317161883!44191780!1 X-Originating-IP: [81.29.64.94] X-StarScan-Version: 6.4.1; banners=-,-,- X-VirusChecked: Checked Received: (qmail 3692 invoked from network); 27 Sep 2011 22:18:03 -0000 Received: from ocelot.phlegethon.org (HELO mail.phlegethon.org) (81.29.64.94) by server-12.tower-27.messagelabs.com with DHE-RSA-AES256-SHA encrypted SMTP; 27 Sep 2011 22:18:03 -0000 Received: from tjd by mail.phlegethon.org with local (Exim 4.67 (FreeBSD)) (envelope-from <tim@xen.org>) id 1R8fyl-0009CY-Ec; Tue, 27 Sep 2011 22:18:19 +0000 Date: Tue, 27 Sep 2011 23:18:19 +0100 From: Tim Deegan <tim@xen.org> To: Mukesh Rathor <mukesh.rathor@oracle.com> Subject: Re: [Xen-devel] help: monitor table and hap Message-ID: <20110927221819.GA32205@ocelot.phlegethon.org> References: <20110927145713.7d04a4f3@mantra.us.oracle.com> Mime-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline In-Reply-To: <20110927145713.7d04a4f3@mantra.us.oracle.com> User-Agent: Mutt/1.4.2.1i Cc: "Xen-devel@lists.xensource.com" <Xen-devel@lists.xensource.com> X-BeenThere: xen-devel@lists.xensource.com X-Mailman-Version: 2.1.5 Precedence: list List-Id: Xen developer discussion <xen-devel.lists.xensource.com> List-Unsubscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe> List-Post: <mailto:xen-devel@lists.xensource.com> List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help> List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=subscribe> Sender: xen-devel-bounces@lists.xensource.com Errors-To: xen-devel-bounces@lists.xensource.com Hi, At 14:57 -0700 on 27 Sep (1317135433), Mukesh Rathor wrote: > I'm trying to figure what the purpose of monitor_table is? It seems to > be used for shadow_mode_external, which I understand doesn't apply to > HAP mode? paging_mode_external(d) is true for all HVM guests, including HAP ones. It means that the Xen virtual addresses aren't reserved in guest pagetables (the way they are in PV guests). The monitor_table, in those cases, is the set of pagetables that Xen runs on when that guest's VCPUs are scheduled (e.g. in VMEXIT handlers). Cheers, Tim. _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel From xen-devel-bounces@lists.xensource.com Tue Sep 27 15:20:32 2011 Return-path: <xen-devel-bounces@lists.xensource.com> Envelope-to: www-data@lists.xensource.com Delivery-date: Tue, 27 Sep 2011 15:20:32 -0700 Received: from localhost ([127.0.0.1] helo=lists.colo.xensource.com) by lists.xensource.com with esmtp (Exim 4.43) id 1R8g0u-0001mP-9I; Tue, 27 Sep 2011 15:20:32 -0700 Received: from mail182.messagelabs.com ([85.158.139.83]) by lists.xensource.com with esmtp (Exim 4.43) id 1R8fys-0001CP-S1 for xen-devel@lists.xensource.com; Tue, 27 Sep 2011 15:18:27 -0700 X-Env-Sender: konrad@oracle.com X-Msg-Ref: server-7.tower-182.messagelabs.com!1317161902!14986586!1 X-Originating-IP: [148.87.113.117] X-StarScan-Version: 6.4.1; banners=-,-,- X-VirusChecked: Checked Received: (qmail 18213 invoked from network); 27 Sep 2011 22:18:23 -0000 Received: from rcsinet15.oracle.com (HELO rcsinet15.oracle.com) (148.87.113.117) by server-7.tower-182.messagelabs.com with DHE-RSA-AES256-SHA encrypted SMTP; 27 Sep 2011 22:18:23 -0000 Received: from rtcsinet21.oracle.com (rtcsinet21.oracle.com [66.248.204.29]) by rcsinet15.oracle.com (Switch-3.4.4/Switch-3.4.4) with ESMTP id p8RMHmJ8019569 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Tue, 27 Sep 2011 22:17:50 GMT Received: from acsmt358.oracle.com (acsmt358.oracle.com [141.146.40.158]) by rtcsinet21.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id p8RMHkpq009143 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 27 Sep 2011 22:17:47 GMT Received: from abhmt106.oracle.com (abhmt106.oracle.com [141.146.116.58]) by acsmt358.oracle.com (8.12.11.20060308/8.12.11) with ESMTP id p8RMHfFS003557; Tue, 27 Sep 2011 17:17:41 -0500 Received: from oracle.com (/207.172.105.198) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Tue, 27 Sep 2011 15:17:40 -0700 Received: by oracle.com (Postfix, from userid 1000) id F3CDC1544; Tue, 27 Sep 2011 18:17:39 -0400 (EDT) Date: Tue, 27 Sep 2011 18:17:39 -0400 From: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com> To: Dan Carpenter <dan.carpenter@oracle.com> Message-ID: <20110927221739.GC10820@phenom.oracle.com> References: <20110927070721.GA7351@elgon.mountain> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20110927070721.GA7351@elgon.mountain> User-Agent: Mutt/1.5.21 (2010-09-15) X-Source-IP: rtcsinet21.oracle.com [66.248.204.29] X-CT-RefId: str=0001.0A090204.4E824B8E.00A4,ss=1,re=0.000,fgs=0 Cc: Jeremy Fitzhardinge <jeremy.fitzhardinge@citrix.com>, kernel-janitors@vger.kernel.org, xen-devel@lists.xensource.com, Jan Beulich <jbeulich@suse.com>, virtualization@lists.linux-foundation.org Subject: [Xen-devel] Re: [patch] xen: double lock typo X-BeenThere: xen-devel@lists.xensource.com X-Mailman-Version: 2.1.5 Precedence: list List-Id: Xen developer discussion <xen-devel.lists.xensource.com> List-Unsubscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe> List-Post: <mailto:xen-devel@lists.xensource.com> List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help> List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=subscribe> Sender: xen-devel-bounces@lists.xensource.com Errors-To: xen-devel-bounces@lists.xensource.com On Tue, Sep 27, 2011 at 10:07:21AM +0300, Dan Carpenter wrote: > We called mutex_lock() twice instead of unlocking. Duh. OK, queued up. > > Signed-off-by: Dan Carpenter <dan.carpenter@oracle.com> > > diff --git a/drivers/xen/xen-pciback/vpci.c b/drivers/xen/xen-pciback/vpci.c > index 01222d7..46d140b 100644 > --- a/drivers/xen/xen-pciback/vpci.c > +++ b/drivers/xen/xen-pciback/vpci.c > @@ -238,7 +238,7 @@ static int __xen_pcibk_get_pcifront_dev(struct pci_dev *pcidev, > } > } > } > - mutex_lock(&vpci_dev->lock); > + mutex_unlock(&vpci_dev->lock); > return found; > } > _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel From xen-devel-bounces@lists.xensource.com Tue Sep 27 15:21:25 2011 Return-path: <xen-devel-bounces@lists.xensource.com> Envelope-to: www-data@lists.xensource.com Delivery-date: Tue, 27 Sep 2011 15:21:25 -0700 Received: from localhost ([127.0.0.1] helo=lists.colo.xensource.com) by lists.xensource.com with esmtp (Exim 4.43) id 1R8g1l-00029D-JP; Tue, 27 Sep 2011 15:21:25 -0700 Received: from mail174.messagelabs.com ([85.158.138.51]) by lists.xensource.com with esmtp (Exim 4.43) id 1R8fz5-0001Fc-TF for xen-devel@lists.xensource.com; Tue, 27 Sep 2011 15:18:41 -0700 X-Env-Sender: evil.dani@gmail.com X-Msg-Ref: server-11.tower-174.messagelabs.com!1317161916!32991679!1 X-Originating-IP: [209.85.161.43] X-StarScan-Version: 6.4.1; banners=-,-,- X-VirusChecked: Checked Received: (qmail 22545 invoked from network); 27 Sep 2011 22:18:36 -0000 Received: from mail-fx0-f43.google.com (HELO mail-fx0-f43.google.com) (209.85.161.43) by server-11.tower-174.messagelabs.com with RC4-SHA encrypted SMTP; 27 Sep 2011 22:18:36 -0000 Received: by fxh19 with SMTP id 19so9762409fxh.30 for <xen-devel@lists.xensource.com>; Tue, 27 Sep 2011 15:18:36 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; bh=+tNWc2SloioiiFiKjiMdMXonEevAWDZIw3wBOQaTodo=; b=UfyGKvo3bsNMUkWN8qS8t0P7pci1RiR6BiTNqUpoFIZBNPrhvWiN6E05AlaEZb1GjD EV1h4+L9jdsWf4QJOw6HYgPf9NM2XCFqsmY9RazE+BqzsObf2uuJqOGVsyW88u/1COBe Qzt9uzFcZUxIUud2kDckn7Mx1xSc0nF1Q0S8U= MIME-Version: 1.0 Received: by 10.223.52.218 with SMTP id j26mr13196377fag.56.1317161916152; Tue, 27 Sep 2011 15:18:36 -0700 (PDT) Received: by 10.223.97.9 with HTTP; Tue, 27 Sep 2011 15:18:36 -0700 (PDT) In-Reply-To: <20098.1097.824552.541924@mariner.uk.xensource.com> References: <20110922130618.GA13238@phenom.oracle.com> <CAFLBxZaAaXTUtW5+VkxPnr_MR0fbW+d1Mzu4y0x=gEOaX9e0OQ@mail.gmail.com> <20110922174002.GA1205@phenom.oracle.com> <20098.1097.824552.541924@mariner.uk.xensource.com> Date: Wed, 28 Sep 2011 07:18:36 +0900 Message-ID: <CAP2B85-=CbMgUGSwO2utvkeLLqk8A1vjhKrPwe2OD+0daAtqsA@mail.gmail.com> Subject: Re: [Xen-devel] Xen document day (Oct 12 or 26) From: Daniel Castro <evil.dani@gmail.com> To: Ian Jackson <Ian.Jackson@eu.citrix.com>, xen-devel@lists.xensource.com Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com> X-BeenThere: xen-devel@lists.xensource.com X-Mailman-Version: 2.1.5 Precedence: list List-Id: Xen developer discussion <xen-devel.lists.xensource.com> List-Unsubscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe> List-Post: <mailto:xen-devel@lists.xensource.com> List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help> List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=subscribe> Sender: xen-devel-bounces@lists.xensource.com Errors-To: xen-devel-bounces@lists.xensource.com On Wed, Sep 28, 2011 at 2:13 AM, Ian Jackson <Ian.Jackson@eu.citrix.com> wr= ote: > Konrad Rzeszutek Wilk writes ("Re: [Xen-devel] Xen document day (Oct 12 o= r 26)"): >> [ docs todo list ] > ... >> Who wants to do what? I created a sign up sheet: >> >> https://docs.google.com/spreadsheet/ccc?key=3D0Aj5ukWh4htwMdEFLVWpjRmx3V= XdETDExNlByamd4Rmc&hl=3Den_US >> >> in case folks want to get an idea of who is doing what and not >> step on each toes. > > Daniel, I see you have put yourself down for some things to do with > "PDF manual". =A0I'm not sure exactly what you mean. =A0Do you mean the > user manual or the internals ("interface.tex") ? > > I think that both of these TeX documents really need to be abolished. > They're too hard to maintain so they have rotted; even if we were to > fix that they wouldn't stay up to date. I was meaning the interface document. My current work involves interacting with almost all parts of that document, so giving C examples was very easy for me and I thought it would be very helpful for new developers in the future. There are not many resources for new developers and Xen has a big entry barrier due to its size and complexity. For example there is no official guide on how to build Xen on a new system, and it took me several days to have a working system. When developing code, in my case most of the needed documentation came from The Definitive Guide to Xen Hypervisor from PrenticeHall Press. But its becoming outdated now, sadly. And in some few cases it is very general and lack much needed detail. I do understand that Xen is huge and making a easy guide for everything is impractical. Let me know how I can help, I really do want to help. > > I have volunteered to do some manpage-style or markdown docs for xl. > > Ian. > --=20 +-=3D=3D=3D=3D=3D---------------------------+ | +---------------------------------+ | This space intentionally blank for notetaking. | |=A0=A0 | Daniel Castro,=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 | | |=A0=A0 | Consultant/Programmer.| | |=A0=A0 | U Andes=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0=A0 | +-------------------------------------+ _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel From xen-devel-bounces@lists.xensource.com Tue Sep 27 15:27:31 2011 Return-path: <xen-devel-bounces@lists.xensource.com> Envelope-to: www-data@lists.xensource.com Delivery-date: Tue, 27 Sep 2011 15:27:31 -0700 Received: from localhost ([127.0.0.1] helo=lists.colo.xensource.com) by lists.xensource.com with esmtp (Exim 4.43) id 1R8g7f-0002aj-Oo; Tue, 27 Sep 2011 15:27:31 -0700 Received: from mail174.messagelabs.com ([85.158.138.51]) by lists.xensource.com with esmtp (Exim 4.43) id 1R8g6x-0002ON-8S for xen-devel@lists.xensource.com; Tue, 27 Sep 2011 15:26:47 -0700 X-Env-Sender: konrad@oracle.com X-Msg-Ref: server-8.tower-174.messagelabs.com!1317162402!19316893!1 X-Originating-IP: [148.87.113.117] X-StarScan-Version: 6.4.1; banners=-,-,- X-VirusChecked: Checked Received: (qmail 1087 invoked from network); 27 Sep 2011 22:26:44 -0000 Received: from rcsinet15.oracle.com (HELO rcsinet15.oracle.com) (148.87.113.117) by server-8.tower-174.messagelabs.com with DHE-RSA-AES256-SHA encrypted SMTP; 27 Sep 2011 22:26:44 -0000 Received: from rtcsinet21.oracle.com (rtcsinet21.oracle.com [66.248.204.29]) by rcsinet15.oracle.com (Switch-3.4.4/Switch-3.4.4) with ESMTP id p8RMQU81028730 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Tue, 27 Sep 2011 22:26:32 GMT Received: from acsmt358.oracle.com (acsmt358.oracle.com [141.146.40.158]) by rtcsinet21.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id p8RMQSQl018110 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 27 Sep 2011 22:26:29 GMT Received: from abhmt112.oracle.com (abhmt112.oracle.com [141.146.116.64]) by acsmt358.oracle.com (8.12.11.20060308/8.12.11) with ESMTP id p8RMQMcp009579; Tue, 27 Sep 2011 17:26:23 -0500 Received: from oracle.com (/207.172.105.198) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Tue, 27 Sep 2011 15:26:22 -0700 Received: by oracle.com (Postfix, from userid 1000) id 42E4F1544; Tue, 27 Sep 2011 18:26:22 -0400 (EDT) Date: Tue, 27 Sep 2011 18:26:22 -0400 From: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com> To: Adi Kriegisch <adi@cg.tuwien.ac.at> Subject: Re: [Xen-devel] Re: Dom0 ACPI S3 patches Message-ID: <20110927222622.GD10820@phenom.oracle.com> References: <20110914081156.GB3079@vrvis.at> <20110914102112.GB15866@phenom.oracle.com> <20110914112718.GG3079@vrvis.at> <20110914142854.GB16956@phenom.oracle.com> <20110914150934.GK3079@vrvis.at> <20110914154726.GA18810@phenom.oracle.com> <20110927145008.GN6720@vrvis.at> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20110927145008.GN6720@vrvis.at> User-Agent: Mutt/1.5.21 (2010-09-15) X-Source-IP: rtcsinet21.oracle.com [66.248.204.29] X-CT-RefId: str=0001.0A090203.4E824D98.007E,ss=1,re=0.000,fgs=0 Cc: xen-devel@lists.xensource.com X-BeenThere: xen-devel@lists.xensource.com X-Mailman-Version: 2.1.5 Precedence: list List-Id: Xen developer discussion <xen-devel.lists.xensource.com> List-Unsubscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe> List-Post: <mailto:xen-devel@lists.xensource.com> List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help> List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=subscribe> Sender: xen-devel-bounces@lists.xensource.com Errors-To: xen-devel-bounces@lists.xensource.com On Tue, Sep 27, 2011 at 04:50:08PM +0200, Adi Kriegisch wrote: > On Wed, Sep 14, 2011 at 11:47:26AM -0400, Konrad Rzeszutek Wilk wrote: > > On Wed, Sep 14, 2011 at 05:09:34PM +0200, Adi Kriegisch wrote: > > > On Wed, Sep 14, 2011 at 10:28:54AM -0400, Konrad Rzeszutek Wilk wrote: > > > > > > Excellent. Is it OK if I put 'Tested-by: Adi Kriegish" on them? > Works like a charme with 'nopat'. No crash ever since. > > > > > > > You know, I don't know. I just never thought about that - um. I wonder > > > > > > if it is related to the RTC update patch that I've been meaning > > > > > > to take a look at: > > > > > > > > > > > > http://lists.xensource.com/archives/html/xen-devel/2010-02/msg00469.html > [SNIP] > > Pfff.. well, I will try to rebase it in a couple of days. Can you ping in a week > > if I haven't sent anything to you yet? > Any news on this one? I still have to resync my clock after acpi sleep... Jeremy just sent out the patches for review. http://lists.xensource.com/archives/html/xen-devel/2011-09/msg01452.html Please test. _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel From xen-devel-bounces@lists.xensource.com Tue Sep 27 16:12:28 2011 Return-path: <xen-devel-bounces@lists.xensource.com> Envelope-to: www-data@lists.xensource.com Delivery-date: Tue, 27 Sep 2011 16:12:28 -0700 Received: from localhost ([127.0.0.1] helo=lists.colo.xensource.com) by lists.xensource.com with esmtp (Exim 4.43) id 1R8gp9-0003xi-QV; Tue, 27 Sep 2011 16:12:28 -0700 Received: from mail216.messagelabs.com ([85.158.143.99]) by lists.xensource.com with esmtp (Exim 4.43) id 1R8gnX-0003kS-PB for xen-devel@lists.xensource.com; Tue, 27 Sep 2011 16:10:52 -0700 X-Env-Sender: konrad@oracle.com X-Msg-Ref: server-10.tower-216.messagelabs.com!1317165043!11732413!1 X-Originating-IP: [141.146.126.227] X-StarScan-Version: 6.4.1; banners=-,-,- X-VirusChecked: Checked Received: (qmail 14360 invoked from network); 27 Sep 2011 23:10:44 -0000 Received: from acsinet15.oracle.com (HELO acsinet15.oracle.com) (141.146.126.227) by server-10.tower-216.messagelabs.com with DHE-RSA-AES256-SHA encrypted SMTP; 27 Sep 2011 23:10:44 -0000 Received: from acsinet21.oracle.com (acsinet21.oracle.com [141.146.126.237]) by acsinet15.oracle.com (Switch-3.4.4/Switch-3.4.4) with ESMTP id p8RNAewG010437 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Tue, 27 Sep 2011 23:10:41 GMT Received: from acsmt356.oracle.com (acsmt356.oracle.com [141.146.40.156]) by acsinet21.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id p8RNAd7p028962 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 27 Sep 2011 23:10:40 GMT Received: from abhmt115.oracle.com (abhmt115.oracle.com [141.146.116.67]) by acsmt356.oracle.com (8.12.11.20060308/8.12.11) with ESMTP id p8RNAYTb013037; Tue, 27 Sep 2011 18:10:34 -0500 Received: from oracle.com (/207.172.105.198) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Tue, 27 Sep 2011 16:10:34 -0700 Received: by oracle.com (Postfix, from userid 1000) id 9E3F11544; Tue, 27 Sep 2011 19:10:33 -0400 (EDT) Date: Tue, 27 Sep 2011 19:10:33 -0400 From: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com> To: David Vrabel <david.vrabel@citrix.com> Subject: Re: [Xen-devel] Re: xen: memory initialization/balloon fixes (#3) Message-ID: <20110927231033.GA4712@phenom.oracle.com> References: <1316089768-22461-1-git-send-email-david.vrabel@citrix.com> <20110924020759.GA27796@phenom.oracle.com> <4E81D909.8020603@citrix.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <4E81D909.8020603@citrix.com> User-Agent: Mutt/1.5.21 (2010-09-15) X-Source-IP: acsinet21.oracle.com [141.146.126.237] X-Auth-Type: Internal IP X-CT-RefId: str=0001.0A090206.4E8257F2.003E:SCFMA922111,ss=1,re=-4.000,fgs=0 Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com> X-BeenThere: xen-devel@lists.xensource.com X-Mailman-Version: 2.1.5 Precedence: list List-Id: Xen developer discussion <xen-devel.lists.xensource.com> List-Unsubscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe> List-Post: <mailto:xen-devel@lists.xensource.com> List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help> List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=subscribe> Sender: xen-devel-bounces@lists.xensource.com Errors-To: xen-devel-bounces@lists.xensource.com > > (XEN) Xen-e820 RAM map: > > (XEN) 0000000000000000 - 000000000009d800 (usable) > > It's because it's not correctly handling the half-page of RAM at the end > of this region. > > I don't have access to any test boxes with a dodgy BIOS like this so can > you test this patch? If it works I'll fold it in and post an updated > series. It works. Albeit I think we are going to hit a problem with dmidecode if the DMI data is right in the reserved region (http://lists.xensource.com/archives/html/xen-devel/2011-09/msg01299.html) As in, if it starts in 9D800 - we consider 0->9d as RAM PFN, and 9e->100 as 1-1 mapping. I am thinking that perhaps the call to xen_set_phys_identity, where we call PFN_UP(x) should be replaced with PFN_DOWN(x). That way we would consider 0>9c as RAM PFN and 9D->100 as 1-1 mapping. That would imply a new patch to your series naturally. > > Can you remember why this page alignment was required? I'd like to The e820_* calls define how the memory subsystem will use it. It ended at some point assuming that the full page is RAM even thought it was only half-RAM and tried to use it and blew the machine up. The fix was to make the calls to the e820_* with size and regions that were page-aligned. Anyhow, here is what the bootup looks now: [ 0.000000] Freeing 9e-a0 pfn range: 2 pages freed [ 0.000000] 1-1 mapping on 9e->a0 [ 0.000000] Freeing a0-100 pfn range: 96 pages freed [ 0.000000] 1-1 mapping on a0->100 [ 0.000000] Freeing 7fff0-80000 pfn range: 16 pages freed [ 0.000000] 1-1 mapping on 7fff0->80000 [ 0.000000] Freeing cfef0-cfef5 pfn range: 5 pages freed [ 0.000000] 1-1 mapping on cfef0->cfef5 [ 0.000000] Freeing cfef5-cff7f pfn range: 138 pages freed [ 0.000000] 1-1 mapping on cfef5->cff7f [ 0.000000] Freeing cff7f-d0000 pfn range: 129 pages freed [ 0.000000] 1-1 mapping on cff7f->d0000 [ 0.000000] Freeing d0000-f0000 pfn range: 131072 pages freed [ 0.000000] 1-1 mapping on d0000->f0000 [ 0.000000] Freeing f0000-f4b58 pfn range: 19288 pages freed [ 0.000000] 1-1 mapping on f0000->fec10 [ 0.000000] 1-1 mapping on fec10->fee01 [ 0.000000] 1-1 mapping on fee01->100000 [ 0.000000] Released 150746 pages of unused memory [ 0.000000] Set 196994 page(s) to 1-1 mapping [ 0.000000] BIOS-provided physical RAM map: [ 0.000000] Xen: 0000000000000000 - 000000000009d000 (usable) [ 0.000000] Xen: 000000000009d800 - 0000000000100000 (reserved) [ 0.000000] Xen: 0000000000100000 - 000000007fff0000 (usable) [ 0.000000] Xen: 000000007fff0000 - 0000000080000000 (reserved) > update the comment with the reason because the bare-metal x86 memory > init code doesn't appear to fixup the memory map in this way. > > diff --git a/arch/x86/xen/setup.c b/arch/x86/xen/setup.c > index 986661b..e473c4c 100644 > --- a/arch/x86/xen/setup.c > +++ b/arch/x86/xen/setup.c > @@ -178,6 +178,19 @@ static unsigned long __init xen_get_max_pages(void) > return min(max_pages, MAX_DOMAIN_PAGES); > } > > +static void xen_e820_add_region(u64 start, u64 size, int type) > +{ > + u64 end = start + size; > + > + /* Align RAM regions to page boundaries. */ > + if (type == E820_RAM || type == E820_UNUSABLE) { Hm, do we care about E820_UNUSABLE to be page aligned? If so, please comment why. > + start = PAGE_ALIGN(start); Is that actually safe? Say it starts a 9ffff? We would end up using 9f000 which is not right. _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel From xen-devel-bounces@lists.xensource.com Tue Sep 27 16:20:59 2011 Return-path: <xen-devel-bounces@lists.xensource.com> Envelope-to: www-data@lists.xensource.com Delivery-date: Tue, 27 Sep 2011 16:20:59 -0700 Received: from localhost ([127.0.0.1] helo=lists.colo.xensource.com) by lists.xensource.com with esmtp (Exim 4.43) id 1R8gxO-0004Sz-Pg; Tue, 27 Sep 2011 16:20:58 -0700 Received: from mail216.messagelabs.com ([85.158.143.99]) by lists.xensource.com with smtp (Exim 4.43) id 1R8gwD-0004Fk-JW for xen-devel@lists.xensource.com; Tue, 27 Sep 2011 16:19:48 -0700 X-Env-Sender: victor_ling12@yahoo.com X-Msg-Ref: server-4.tower-216.messagelabs.com!1317165581!19789527!1 X-Originating-IP: [98.139.91.85] X-StarScan-Version: 6.4.1; banners=-,-,- X-VirusChecked: Checked Received: (qmail 15346 invoked from network); 27 Sep 2011 23:19:41 -0000 Received: from nm15.bullet.mail.sp2.yahoo.com (HELO nm15.bullet.mail.sp2.yahoo.com) (98.139.91.85) by server-4.tower-216.messagelabs.com with SMTP; 27 Sep 2011 23:19:41 -0000 Received: from [98.139.91.65] by nm15.bullet.mail.sp2.yahoo.com with NNFMP; 27 Sep 2011 23:19:40 -0000 Received: from [98.139.91.22] by tm5.bullet.mail.sp2.yahoo.com with NNFMP; 27 Sep 2011 23:19:40 -0000 Received: from [127.0.0.1] by omp1022.mail.sp2.yahoo.com with NNFMP; 27 Sep 2011 23:19:40 -0000 X-Yahoo-Newman-Property: ymail-3 X-Yahoo-Newman-Id: 687297.56411.bm@omp1022.mail.sp2.yahoo.com Received: (qmail 86805 invoked by uid 60001); 27 Sep 2011 23:19:40 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s1024; t=1317165580; bh=S5jU86+eJACJz8EYVTkubCeuLA41+9vmyqkzO2un1UA=; h=X-YMail-OSG:Received:X-Mailer:Message-ID:Date:From:Reply-To:Subject:To:Cc:MIME-Version:Content-Type; b=FTaEgxFObsoiu2af97XYnSzEGbDOzT8Q+GnRE+e06C88dZY2lJ3+rTur62mb5AAJNzCn1YZyjmN5/i4adD1nOifpKV383UXG+AcfW8PCsBhGw6i3tmqsbaVAjbTOgQhuhN29svUh0psNhwz0GPfW8Z0zTGEmqnuS6MeEykkhfyI= DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com; h=X-YMail-OSG:Received:X-Mailer:Message-ID:Date:From:Reply-To:Subject:To:Cc:MIME-Version:Content-Type; b=Pgm1kzl4Z4FCcGGPOxQSefAUfVQSNc0RZfiiSKhqhOCwZv7hYA0rHx0VamkQ8+Kf5xaijH90qn/mAITQWz7GgI/9PmY6SoMZlyHMc2sjwkc6onQsXXgGm95PrFQJ/XpcA3RjYuBnjKTImXdFTGNFRYSat3X5BumoMWjdB7dx3LA=; X-YMail-OSG: EsRfENMVM1mdujaw6H2rSrlXGO0C9Qvt.BPlnP32QR93Zk9 Ksg05rbuWipL3pva7.Afrs5FFvn2xw1q3OJLC.jGORUapwJxVBA.hzBNdCcO cB102bVo8XbK69LKHFsJjz_rtOQW_FzNwbpmgTI1XJimu2g0jFYb3LZ3rCWV Mwt14RQo6EzTeJD_6Y5PluvB_lxCpg6g9lQ_s.fThQSZhZ6.So__SDYIoiVt bZrlbUr665Ncl9bFP0.dbWNktbRXj18jAvv3SyjaokPqWUqFyrJkXsTse7SV tuNf54Sd.DHDIT.fDtxV1tGs7QK7XafaXkRXrEm9J0lsrCXvqwtvfOaEAACq mkpBws_7pdmYaazPw6J4gJUXWU3rpt9lKOJXyoOauJaO7k7_YLRrqwvRKuc_ NT2tdie3wOKL49TWfg95AVG3u9bDNDYdAYNUAbYXpamf0hDaWSaLIZZd6BQ- - Received: from [12.207.18.42] by web114212.mail.gq1.yahoo.com via HTTP; Tue, 27 Sep 2011 16:19:40 PDT X-Mailer: YahooMailWebService/0.8.114.317681 Message-ID: <1317165580.71822.YahooMailNeo@web114212.mail.gq1.yahoo.com> Date: Tue, 27 Sep 2011 16:19:40 -0700 (PDT) From: Victor Ling <victor_ling12@yahoo.com> To: "Xen-devel@lists.xensource.com" <Xen-devel@lists.xensource.com> MIME-Version: 1.0 Cc: "xen-users@lists.xensource.com" <xen-users@lists.xensource.com> Subject: [Xen-devel] Please help: DomU creation problem X-BeenThere: xen-devel@lists.xensource.com X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Victor Ling <victor_ling12@yahoo.com> List-Id: Xen developer discussion <xen-devel.lists.xensource.com> List-Unsubscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe> List-Post: <mailto:xen-devel@lists.xensource.com> List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help> List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=subscribe> Content-Type: multipart/mixed; boundary="===============0640999996==" Sender: xen-devel-bounces@lists.xensource.com Errors-To: xen-devel-bounces@lists.xensource.com --===============0640999996== Content-Type: multipart/alternative; boundary="1357089822-1184329276-1317165580=:71822" --1357089822-1184329276-1317165580=:71822 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable Hi,=0A=0APlease help: I tried to create a DomU with PCI passthrough. I don'= t know hoe to proceed.=0AThe last output is:pcifront pci-0: Installing PCI = frontend=0Apcifront pci-0: Creating PCI Frontend Bus 0000:00=0Apcifront pci= -0: claiming resource 0000:00:00.0/0=0A=0AI tried to login VM with=0Axm cos= ole 6 but nothing happened.=0A=0Alinux:~/Desktop # xm console 6=0A=0A=0AThe= following is the detail info.=0A=0AThanks.=0A=0AVic=0A=0A=0A=0A=0A=0AI hav= e config file:=0A-------------------------------------------------=0Akernel= =A0 =3D "/boot/vmlinuz-3.0.1.stk64"=0A=0A#ramdisk =3D "/boot/initrd-xen"=0A= =0Amemory =3D 512=0A=0Avcpus =3D '2'=0A=0Apci =3D ['02:00.0']=0Aname =3D "x= en-vm1"=0Aroot =3D '/dev/xvda1 ro'=0Adisk =3D [=0A=A0=A0=A0=A0=A0=A0=A0=A0 = 'file:/home/domains/nvidia/XenGuest1.img,xvda1,w',=0A=A0=A0=A0=A0=A0=A0=A0 = ]=0A=0Aon_poweroff =3D 'destroy'=0Aon_reboot =3D 'restart'=0Aon_crash =3D '= restart'=0A=0A-----------------------------------------------------------= =0A=A0after xm create -c nvidia.cfg=0A=0AI can see =0Alinux:~/Desktop # xm = list=0AName=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0= =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 ID=A0=A0 Mem VCPUs= =A0=A0=A0=A0=A0 State=A0=A0 Time(s)=0ADomain-0=A0=A0=A0=A0=A0=A0=A0=A0=A0= =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0= =A0=A0 0=A0 3400=A0=A0=A0=A0 2=A0=A0=A0=A0 r-----=A0=A0=A0 206.5=0Axen-vm1= =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0= =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 6=A0=A0 512=A0=A0=A0=A0 2=A0=A0=A0=A0 = -b----=A0=A0=A0=A0 15.4=0Alinux:~/Desktop # =0A----------------------------= -------------------------------------------------------------------------= =0AI checked the log:=0A=0Alinux:/etc/xen # xm create -c nvidia.cfg=0AUsing= config file "./nvidia.cfg".=0AStarted domain xen-vm1 (id=3D6)=0AInitializi= ng cgroup subsys cpuset=0AInitializing cgroup subsys cpu=0ALinux version 3.= 0.1.stk64 (dfn@localhost.localdomain) (gcc version 4.5.1 20100924 (Red Hat = 4.5.1-4) (GCC) ) #1 SMP Sat Aug 13 12:53:46 EDT 2011=0ACommand line: root= =3D/dev/xvda1 ro =0AACPI in unprivileged domain disabled=0Areleased 0 pages= of unused memory=0ASet 0 page(s) to 1-1 mapping.=0ABIOS-provided physical = RAM map:=0A=A0Xen: 0000000000000000 - 00000000000a0000 (usable)=0A=A0Xen: 0= 0000000000a0000 - 0000000000100000 (reserved)=0A=A0Xen: 0000000000100000 - = 0000000020800000 (usable)=0ANX (Execute Disable) protection: active=0ADMI n= ot present or invalid.=0ANo AGP bridge found=0Alast_pfn =3D 0x20800 max_arc= h_pfn =3D 0x400000000=0Ainit_memory_mapping: 0000000000000000-0000000020800= 000=0ANo NUMA configuration found=0AFaking a node at 0000000000000000-00000= 00020800000=0AInitmem setup node 0 0000000000000000-0000000020800000=0A=A0 = NODE_DATA [000000001ffec000 - 000000001fffffff]=0AZone PFN ranges:=0A=A0 DM= A=A0=A0=A0=A0=A0 0x00000010 -> 0x00001000=0A=A0 DMA32=A0=A0=A0 0x00001000 -= > 0x00100000=0A=A0 Normal=A0=A0 empty=0AMovable zone start PFN for each nod= e=0Aearly_node_map[2] active PFN ranges=0A=A0=A0=A0 0: 0x00000010 -> 0x0000= 00a0=0A=A0=A0=A0 0: 0x00000100 -> 0x00020800=0ASFI: Simple Firmware Interfa= ce v0.81 http://simplefirmware.org=0ASMP: Allowing 2 CPUs, 0 hotplug CPUs= =0ANo local APIC present=0AAPIC: disable apic facility=0AAPIC: switched to = apic NOOP=0APM: Registered nosave memory: 00000000000a0000 - 00000000001000= 00=0AAllocating PCI resources starting at 20800000 (gap: 20800000:df800000)= =0ABooting paravirtualized kernel on Xen=0AXen version: 4.0.0_21091_04-0.2 = (preserve-AD)=0Asetup_percpu: NR_CPUS:256 nr_cpumask_bits:256 nr_cpu_ids:2 = nr_node_ids:1=0APERCPU: Embedded 27 pages/cpu @ffff88001fe8d000 s78400 r819= 2 d24000 u110592=0ABuilt 1 zonelists in Node order, mobility grouping on.= =A0 Total pages: 131183=0APolicy zone: DMA32=0AKernel command line: root=3D= /dev/xvda1 ro =0APID hash table entries: 4096 (order: 3, 32768 bytes)=0AChe= cking aperture...=0ANo AGP bridge found=0AMemory: 502844k/532480k available= (4501k kernel code, 448k absent, 29188k reserved, 2929k data, 920k init)= =0ASLUB: Genslabs=3D15, HWalign=3D64, Order=3D0-3, MinObjects=3D0, CPUs=3D2= , Nodes=3D1=0AHierarchical RCU implementation.=0ANR_IRQS:16640 nr_irqs:288 = 16=0AConsole: colour dummy device 80x25=0Aconsole [tty0] enabled=0Aconsole = [hvc0] enabled=0Aallocated 5242880 bytes of page_cgroup=0Aplease try 'cgrou= p_disable=3Dmemory' option if you don't want memory cgroups=0Ainstalling Xe= n timer for CPU 0=0ADetected 2926.084 MHz processor.=0ACalibrating delay lo= op (skipped), value calculated using timer frequency.. 5852.16 BogoMIPS (lp= j=3D2926084)=0Apid_max: default: 32768 minimum: 301=0ASecurity Framework in= itialized=0ASELinux:=A0 Initializing.=0ADentry cache hash table entries: 13= 1072 (order: 8, 1048576 bytes)=0AInode-cache hash table entries: 65536 (ord= er: 7, 524288 bytes)=0AMount-cache hash table entries: 256=0AInitializing c= group subsys cpuacct=0AInitializing cgroup subsys memory=0AInitializing cgr= oup subsys devices=0AInitializing cgroup subsys freezer=0AInitializing cgro= up subsys net_cls=0ACPU: Physical Processor ID: 0=0ACPU: Processor Core ID:= 0=0ASMP alternatives: switching to UP code=0Aftrace: allocating 23941 entr= ies in 94 pages=0APerformance Events: unsupported p6 CPU model 23 no PMU dr= iver, software events only.=0Ainstalling Xen timer for CPU 1=0ASMP alternat= ives: switching to SMP code=0ABrought up 2 CPUs=0Adevtmpfs: initialized=0AG= rant table initialized=0Aprint_constraints: dummy: =0ATime: 165:165:165=A0 = Date: 165/165/65=0ANET: Registered protocol family 16=0APCI: setting up Xen= PCI frontend stub=0Abio: create slab <bio-0> at 0=0AACPI: Interpreter disa= bled.=0Axen/balloon: Initialising balloon driver.=0Alast_pfn =3D 0x20800 ma= x_arch_pfn =3D 0x400000000=0Axen-balloon: Initialising balloon driver.=0Avg= aarb: loaded=0ASCSI subsystem initialized=0APCI: System does not support PC= I=0APCI: System does not support PCI=0ANetLabel: Initializing=0ANetLabel:= =A0 domain hash size =3D 128=0ANetLabel:=A0 protocols =3D UNLABELED CIPSOv4= =0ANetLabel:=A0 unlabeled traffic allowed by default=0ASwitching to clockso= urce xen=0ASwitched to NOHz mode on CPU #0=0ACE: xen increased min_delta_ns= to 150000 nsec=0ACE: xen increased min_delta_ns to 225000 nsec=0ACE: xen i= ncreased min_delta_ns to 337500 nsec=0ACE: xen increased min_delta_ns to 50= 6250 nsec=0ACE: xen increased min_delta_ns to 759375 nsec=0ACE: xen increas= ed min_delta_ns to 1000000 nsec=0ACE: Reprogramming failure. Giving up=0ACE= : Reprogramming failure. Giving up=0Ahrtimer: interrupt took 4279 ns=0ASwit= ched to NOHz mode on CPU #1=0ACE: xen increased min_delta_ns to 150000 nsec= =0ACE: xen increased min_delta_ns to 225000 nsec=0ACE: xen increased min_de= lta_ns to 337500 nsec=0ACE: xen increased min_delta_ns to 506250 nsec=0ACE:= xen increased min_delta_ns to 759375 nsec=0ACE: xen increased min_delta_ns= to 1000000 nsec=0ACE: Reprogramming failure. Giving up=0ACE: Reprogramming= failure. Giving up=0ACE: Reprogramming failure. Giving up=0Apnp: PnP ACPI:= disabled=0ANET: Registered protocol family 2=0AIP route cache hash table e= ntries: 8192 (order: 4, 65536 bytes)=0ATCP established hash table entries: = 32768 (order: 7, 524288 bytes)=0ATCP bind hash table entries: 32768 (order:= 7, 524288 bytes)=0ATCP: Hash tables configured (established 32768 bind 327= 68)=0ATCP reno registered=0AUDP hash table entries: 256 (order: 1, 8192 byt= es)=0AUDP-Lite hash table entries: 256 (order: 1, 8192 bytes)=0ANET: Regist= ered protocol family 1=0Aplatform rtc_cmos: registered platform RTC device = (no PNP device found)=0ACE: Reprogramming failure. Giving up=0Aaudit: initi= alizing netlink socket (disabled)=0Atype=3D2000 audit(1317138874.411:1): in= itialized=0AHugeTLB registered 2 MB page size, pre-allocated 0 pages=0AVFS:= Disk quotas dquot_6.5.2=0ADquot-cache hash table entries: 512 (order 0, 40= 96 bytes)=0Amsgmni has been set to 982=0ABlock layer SCSI generic (bsg) dri= ver version 0.4 loaded (major 253)=0Aio scheduler noop registered=0Aio sche= duler deadline registered=0Aio scheduler cfq registered (default)=0Apci_hot= plug: PCI Hot Plug PCI Core version: 0.5=0Apciehp: PCI Express Hot Plug Con= troller Driver version: 0.4=0Aacpiphp: ACPI Hot Plug PCI Controller Driver = version: 0.5=0ASerial: 8250/16550 driver, 4 ports, IRQ sharing enabled=0Apc= ifront pci-0: Installing PCI frontend=0Apcifront pci-0: Creating PCI Fronte= nd Bus 0000:00=0Apcifront pci-0: claiming resource 0000:00:00.0/0 --1357089822-1184329276-1317165580=:71822 Content-Type: text/html; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable <html><body><div style=3D"color:#000; background-color:#fff; font-family:ti= mes new roman, new york, times, serif;font-size:12pt"><div>Hi,</div><div><b= r></div><div>Please help: I tried to create a DomU with PCI passthrough. I = don't know hoe to proceed.</div><div>The last output is:</div>pcifront pci-= 0: Installing PCI frontend<br>=0Apcifront pci-0: Creating PCI Frontend Bus = 0000:00<br>=0Apcifront pci-0: claiming resource 0000:00:00.0/0<br><br>I tri= ed to login VM with<br>xm cosole 6 but nothing happened.<br><br>linux:~/Des= ktop # xm console 6<br><br><br>The following is the detail info.<br><br>Tha= nks.<br><br>Vic<br><br><br><div><br></div><div><br></div><div>I have config= file:</div><div>-------------------------------------------------<br></div= >kernel  =3D "/boot/vmlinuz-3.0.1.stk64"<br><br>#ramdisk =3D "/boot/in= itrd-xen"<br><br>memory =3D 512<br><br>vcpus =3D '2'<br><br>pci =3D ['02:00= .0']<br>name =3D "xen-vm1"<br>root =3D '/dev/xvda1 ro'<br>disk =3D [<br>&nb= sp;        'file:/home/domains/nvidia/Xe= nGuest1.img,xvda1,w',<br>        ]<br><b= r>on_poweroff =3D 'destroy'<br>on_reboot =3D 'restart'<br>on_crash =3D 'res= tart'<br><br>-----------------------------------------------------------<br= > after xm create -c nvidia.cfg<br><br>I can see <br>linux:~/Desktop #= xm list<br>Name          &n= bsp;            = ;            &n= bsp;    ID   Mem VCPUs    &nbs= p; State   Time(s)<br>Domain-0      = ;            &n= bsp;            = ;      0  3400     2 = ;    r-----    206.5<br>xen-vm1  &n= bsp;            = ;            &n= bsp;          6   51= 2     2     -b----     15.4<br>linux:~/Desktop # <br>-------------= ---------------------------------------------------------------------------= -------------<br>I checked the log:<br><br>linux:/etc/xen # xm create -c nv= idia.cfg<br>Using config file "./nvidia.cfg".<br>Started domain xen-vm1 (id= =3D6)<br>Initializing cgroup subsys cpuset<br>Initializing cgroup subsys cp= u<br>Linux version 3.0.1.stk64 (dfn@localhost.localdomain) (gcc version 4.5= .1 20100924 (Red Hat 4.5.1-4) (GCC) ) #1 SMP Sat Aug 13 12:53:46 EDT 2011<b= r>Command line: root=3D/dev/xvda1 ro <br>ACPI in unprivileged domain disabl= ed<br>released 0 pages of unused memory<br>Set 0 page(s) to 1-1 mapping.<br= >BIOS-provided physical RAM map:<br> Xen: 0000000000000000 - 000000000= 00a0000 (usable)<br> Xen: 00000000000a0000 - 0000000000100000 (reserve= d)<br> Xen: 0000000000100000 - 0000000020800000 (usable)<br>NX (Execut= e Disable) protection: active<br>DMI not present or invalid.<br>No AGP bridge found<br>last_pfn =3D 0x20800 max_arch_pfn =3D 0x400000000<br>init_= memory_mapping: 0000000000000000-0000000020800000<br>No NUMA configuration = found<br>Faking a node at 0000000000000000-0000000020800000<br>Initmem setu= p node 0 0000000000000000-0000000020800000<br>  NODE_DATA [000000001ff= ec000 - 000000001fffffff]<br>Zone PFN ranges:<br>  DMA  &nbs= p;   0x00000010 -> 0x00001000<br>  DMA32   = ; 0x00001000 -> 0x00100000<br>  Normal   empty<br>Movable= zone start PFN for each node<br>early_node_map[2] active PFN ranges<br>&nb= sp;   0: 0x00000010 -> 0x000000a0<br>    0: 0x0= 0000100 -> 0x00020800<br>SFI: Simple Firmware Interface v0.81 http://sim= plefirmware.org<br>SMP: Allowing 2 CPUs, 0 hotplug CPUs<br>No local APIC pr= esent<br>APIC: disable apic facility<br>APIC: switched to apic NOOP<br>PM: = Registered nosave memory: 00000000000a0000 - 0000000000100000<br>Allocating PCI resources starting at 20800000 (gap: 20= 800000:df800000)<br>Booting paravirtualized kernel on Xen<br>Xen version: 4= .0.0_21091_04-0.2 (preserve-AD)<br>setup_percpu: NR_CPUS:256 nr_cpumask_bit= s:256 nr_cpu_ids:2 nr_node_ids:1<br>PERCPU: Embedded 27 pages/cpu @ffff8800= 1fe8d000 s78400 r8192 d24000 u110592<br>Built 1 zonelists in Node order, mo= bility grouping on.  Total pages: 131183<br>Policy zone: DMA32<br>Kern= el command line: root=3D/dev/xvda1 ro <br>PID hash table entries: 4096 (ord= er: 3, 32768 bytes)<br>Checking aperture...<br>No AGP bridge found<br>Memor= y: 502844k/532480k available (4501k kernel code, 448k absent, 29188k reserv= ed, 2929k data, 920k init)<br>SLUB: Genslabs=3D15, HWalign=3D64, Order=3D0-= 3, MinObjects=3D0, CPUs=3D2, Nodes=3D1<br>Hierarchical RCU implementation.<= br>NR_IRQS:16640 nr_irqs:288 16<br>Console: colour dummy device 80x25<br>co= nsole [tty0] enabled<br>console [hvc0] enabled<br>allocated 5242880 bytes o= f page_cgroup<br>please try 'cgroup_disable=3Dmemory' option if you don't wa= nt memory cgroups<br>installing Xen timer for CPU 0<br>Detected 2926.084 MH= z processor.<br>Calibrating delay loop (skipped), value calculated using ti= mer frequency.. 5852.16 BogoMIPS (lpj=3D2926084)<br>pid_max: default: 32768= minimum: 301<br>Security Framework initialized<br>SELinux:  Initializ= ing.<br>Dentry cache hash table entries: 131072 (order: 8, 1048576 bytes)<b= r>Inode-cache hash table entries: 65536 (order: 7, 524288 bytes)<br>Mount-c= ache hash table entries: 256<br>Initializing cgroup subsys cpuacct<br>Initi= alizing cgroup subsys memory<br>Initializing cgroup subsys devices<br>Initi= alizing cgroup subsys freezer<br>Initializing cgroup subsys net_cls<br>CPU:= Physical Processor ID: 0<br>CPU: Processor Core ID: 0<br>SMP alternatives:= switching to UP code<br>ftrace: allocating 23941 entries in 94 pages<br>Pe= rformance Events: unsupported p6 CPU model 23 no PMU driver, software events only.<br>installing Xen timer for CPU 1<br>SMP alternatives: switch= ing to SMP code<br>Brought up 2 CPUs<br>devtmpfs: initialized<br>Grant tabl= e initialized<br>print_constraints: dummy: <br>Time: 165:165:165  Date= : 165/165/65<br>NET: Registered protocol family 16<br>PCI: setting up Xen P= CI frontend stub<br>bio: create slab <bio-0> at 0<br>ACPI: Interprete= r disabled.<br>xen/balloon: Initialising balloon driver.<br>last_pfn =3D 0x= 20800 max_arch_pfn =3D 0x400000000<br>xen-balloon: Initialising balloon dri= ver.<br>vgaarb: loaded<br>SCSI subsystem initialized<br>PCI: System does no= t support PCI<br>PCI: System does not support PCI<br>NetLabel: Initializing= <br>NetLabel:  domain hash size =3D 128<br>NetLabel:  protocols = =3D UNLABELED CIPSOv4<br>NetLabel:  unlabeled traffic allowed by defau= lt<br>Switching to clocksource xen<br>Switched to NOHz mode on CPU #0<br>CE= : xen increased min_delta_ns to 150000 nsec<br>CE: xen increased min_delta_= ns to 225000 nsec<br>CE: xen increased min_delta_ns to 337500 nsec<br>CE: xen= increased min_delta_ns to 506250 nsec<br>CE: xen increased min_delta_ns to= 759375 nsec<br>CE: xen increased min_delta_ns to 1000000 nsec<br>CE: Repro= gramming failure. Giving up<br>CE: Reprogramming failure. Giving up<br>hrti= mer: interrupt took 4279 ns<br>Switched to NOHz mode on CPU #1<br>CE: xen i= ncreased min_delta_ns to 150000 nsec<br>CE: xen increased min_delta_ns to 2= 25000 nsec<br>CE: xen increased min_delta_ns to 337500 nsec<br>CE: xen incr= eased min_delta_ns to 506250 nsec<br>CE: xen increased min_delta_ns to 7593= 75 nsec<br>CE: xen increased min_delta_ns to 1000000 nsec<br>CE: Reprogramm= ing failure. Giving up<br>CE: Reprogramming failure. Giving up<br>CE: Repro= gramming failure. Giving up<br>pnp: PnP ACPI: disabled<br>NET: Registered p= rotocol family 2<br>IP route cache hash table entries: 8192 (order: 4, 6553= 6 bytes)<br>TCP established hash table entries: 32768 (order: 7, 524288 bytes)<br>TCP bind hash table entries: 32768 (order: 7, 524288 byte= s)<br>TCP: Hash tables configured (established 32768 bind 32768)<br>TCP ren= o registered<br>UDP hash table entries: 256 (order: 1, 8192 bytes)<br>UDP-L= ite hash table entries: 256 (order: 1, 8192 bytes)<br>NET: Registered proto= col family 1<br>platform rtc_cmos: registered platform RTC device (no PNP d= evice found)<br>CE: Reprogramming failure. Giving up<br>audit: initializing= netlink socket (disabled)<br>type=3D2000 audit(1317138874.411:1): initiali= zed<br>HugeTLB registered 2 MB page size, pre-allocated 0 pages<br>VFS: Dis= k quotas dquot_6.5.2<br>Dquot-cache hash table entries: 512 (order 0, 4096 = bytes)<br>msgmni has been set to 982<br>Block layer SCSI generic (bsg) driv= er version 0.4 loaded (major 253)<br>io scheduler noop registered<br>io sch= eduler deadline registered<br>io scheduler cfq registered (default)<br>pci_= hotplug: PCI Hot Plug PCI Core version: 0.5<br>pciehp: PCI Express Hot Plug Controller Driver version: 0.4<br>acpiphp: ACPI Hot Plug PCI Controll= er Driver version: 0.5<br>Serial: 8250/16550 driver, 4 ports, IRQ sharing e= nabled<br>pcifront pci-0: Installing PCI frontend<br>pcifront pci-0: Creati= ng PCI Frontend Bus 0000:00<br>pcifront pci-0: claiming resource 0000:00:00= .0/0<br><br><br><br></div></body></html> --1357089822-1184329276-1317165580=:71822-- --===============0640999996== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel --===============0640999996==-- From xen-devel-bounces@lists.xensource.com Tue Sep 27 16:29:50 2011 Return-path: <xen-devel-bounces@lists.xensource.com> Envelope-to: www-data@lists.xensource.com Delivery-date: Tue, 27 Sep 2011 16:29:50 -0700 Received: from localhost ([127.0.0.1] helo=lists.colo.xensource.com) by lists.xensource.com with esmtp (Exim 4.43) id 1R8h5x-0005ib-Pl; Tue, 27 Sep 2011 16:29:50 -0700 Received: from mail174.messagelabs.com ([85.158.138.51]) by lists.xensource.com with esmtp (Exim 4.43) id 1R8h5A-0005Vy-8d for xen-devel@lists.xensource.com; Tue, 27 Sep 2011 16:29:00 -0700 X-Env-Sender: Ian.Jackson@eu.citrix.com X-Msg-Ref: server-15.tower-174.messagelabs.com!1317166136!26658089!1 X-Originating-IP: [62.200.22.115] X-StarScan-Version: 6.4.1; banners=-,-,- X-VirusChecked: Checked Received: (qmail 19661 invoked from network); 27 Sep 2011 23:28:57 -0000 Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115) by server-15.tower-174.messagelabs.com with RC4-SHA encrypted SMTP; 27 Sep 2011 23:28:57 -0000 X-IronPort-AV: E=Sophos;i="4.68,452,1312156800"; d="scan'208";a="8093021" Received: from lonpmailmx01.citrite.net ([10.30.203.162]) by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5; 27 Sep 2011 23:28:56 +0000 Received: from woking.xci-test.com (10.80.248.135) by smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id 8.3.137.0; Wed, 28 Sep 2011 00:28:56 +0100 Received: from osstest by woking.xci-test.com with local (Exim 4.69) (envelope-from <ian.jackson@eu.citrix.com>) id 1R8h56-0004VY-7p; Wed, 28 Sep 2011 00:28:56 +0100 To: xen-devel@lists.xensource.com Message-ID: <osstest-9107-mainreport@xen.org> From: xen.org <ian.jackson@eu.citrix.com> Date: Wed, 28 Sep 2011 00:28:56 +0100 MIME-Version: 1.0 Content-Type: text/plain Cc: ian.jackson@eu.citrix.com Subject: [Xen-devel] [xen-4.1-testing test] 9107: tolerable FAIL - PUSHED X-BeenThere: xen-devel@lists.xensource.com X-Mailman-Version: 2.1.5 Precedence: list List-Id: Xen developer discussion <xen-devel.lists.xensource.com> List-Unsubscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe> List-Post: <mailto:xen-devel@lists.xensource.com> List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help> List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=subscribe> Sender: xen-devel-bounces@lists.xensource.com Errors-To: xen-devel-bounces@lists.xensource.com flight 9107 xen-4.1-testing real [real] http://www.chiark.greenend.org.uk/~xensrcts/logs/9107/ Failures :-/ but no regressions. Tests which did not succeed, but are not blocking, including regressions (tests previously passed) regarded as allowable: test-amd64-amd64-xl-pcipt-intel 9 guest-start fail never pass test-amd64-i386-rhel6hvm-amd 9 guest-start.2 fail never pass test-amd64-i386-rhel6hvm-intel 9 guest-start.2 fail never pass test-amd64-amd64-xl-win 13 guest-stop fail never pass test-amd64-i386-win 16 leak-check/check fail never pass test-amd64-i386-xl-win-vcpus1 13 guest-stop fail never pass test-amd64-i386-win-vcpus1 16 leak-check/check fail never pass test-amd64-amd64-win 16 leak-check/check fail never pass test-i386-i386-xl-win 13 guest-stop fail never pass test-i386-i386-win 16 leak-check/check fail never pass version targeted for testing: xen 5c395e993fe4 baseline version: xen 2112db7c68b3 ------------------------------------------------------------ People who touched revisions under test: Ian Campbell <ian.campbell@citrix.com> Ian Jackson <ian.jackson@eu.citrix.com> Marek Marczykowski <marmarek@mimuw.edu.pl> ------------------------------------------------------------ jobs: build-amd64 pass build-i386 pass build-amd64-oldkern pass build-i386-oldkern pass build-amd64-pvops pass build-i386-pvops pass test-amd64-amd64-xl pass test-amd64-i386-xl pass test-i386-i386-xl pass test-amd64-i386-rhel6hvm-amd fail test-amd64-i386-xl-credit2 pass test-amd64-amd64-xl-pcipt-intel fail test-amd64-i386-rhel6hvm-intel fail test-amd64-i386-xl-multivcpu pass test-amd64-amd64-pair pass test-amd64-i386-pair pass test-i386-i386-pair pass test-amd64-amd64-pv pass test-amd64-i386-pv pass test-i386-i386-pv pass test-amd64-amd64-xl-sedf pass test-amd64-i386-win-vcpus1 fail test-amd64-i386-xl-win-vcpus1 fail test-amd64-amd64-win fail test-amd64-i386-win fail test-i386-i386-win fail test-amd64-amd64-xl-win fail test-i386-i386-xl-win fail ------------------------------------------------------------ sg-report-flight on woking.cam.xci-test.com logs: /home/xc_osstest/logs images: /home/xc_osstest/images Logs, config files, etc. are available at http://www.chiark.greenend.org.uk/~xensrcts/logs Test harness code can be found at http://xenbits.xensource.com/gitweb?p=osstest.git;a=summary Pushing revision : + branch=xen-4.1-testing + revision=5c395e993fe4 + . cri-lock-repos ++ . cri-common +++ umask 002 +++ getconfig Repos +++ perl -e ' use Osstest; readconfigonly(); print $c{Repos} or die $!; ' ++ repos=/export/home/osstest/repos ++ repos_lock=/export/home/osstest/repos/lock ++ '[' x '!=' x/export/home/osstest/repos/lock ']' ++ OSSTEST_REPOS_LOCK_LOCKED=/export/home/osstest/repos/lock ++ exec with-lock-ex -w /export/home/osstest/repos/lock ./ap-push xen-4.1-testing 5c395e993fe4 + branch=xen-4.1-testing + revision=5c395e993fe4 + . cri-lock-repos ++ . cri-common +++ umask 002 +++ getconfig Repos +++ perl -e ' use Osstest; readconfigonly(); print $c{Repos} or die $!; ' ++ repos=/export/home/osstest/repos ++ repos_lock=/export/home/osstest/repos/lock ++ '[' x/export/home/osstest/repos/lock '!=' x/export/home/osstest/repos/lock ']' + : xen@xenbits.xensource.com + : xen@xenbits.xensource.com:git/linux-pvops + : master + : tested/2.6.39.x + case "$branch" in + cd /export/home/osstest/repos/xen-4.1-testing.hg + hg push -r 5c395e993fe4 ssh://xen@xenbits.xensource.com/HG/xen-4.1-testing.hg pushing to ssh://xen@xenbits.xensource.com/HG/xen-4.1-testing.hg searching for changes remote: adding changesets remote: adding manifests remote: adding file changes remote: added 1 changesets with 1 changes to 1 files _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel From xen-devel-bounces@lists.xensource.com Tue Sep 27 16:41:28 2011 Return-path: <xen-devel-bounces@lists.xensource.com> Envelope-to: www-data@lists.xensource.com Delivery-date: Tue, 27 Sep 2011 16:41:28 -0700 Received: from localhost ([127.0.0.1] helo=lists.colo.xensource.com) by lists.xensource.com with esmtp (Exim 4.43) id 1R8hHD-0006dy-UP; Tue, 27 Sep 2011 16:41:27 -0700 Received: from mail21.messagelabs.com ([85.158.143.35]) by lists.xensource.com with smtp (Exim 4.43) id 1R8hGQ-0006RX-6Q for xen-devel@lists.xensource.com; Tue, 27 Sep 2011 16:40:38 -0700 X-Env-Sender: xen.list@daevel.fr X-Msg-Ref: server-7.tower-21.messagelabs.com!1317166804!56495234!1 X-Originating-IP: [178.32.94.222] X-StarScan-Version: 6.4.1; banners=-,-,- X-VirusChecked: Checked Received: (qmail 1181 invoked from network); 27 Sep 2011 23:40:04 -0000 Received: from licorne.daevel.fr (HELO licorne.daevel.fr) (178.32.94.222) by server-7.tower-21.messagelabs.com with SMTP; 27 Sep 2011 23:40:04 -0000 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=daevel.fr; s=default; h=Content-Transfer-Encoding:Content-Type:In-Reply-To:References:Subject:To:MIME-Version:From:Date:Message-ID; bh=cud5uQ1xD61+oVyZDqnueFD6Zx9LkAGSU+yEMVkDnU8=; b=OpHSwq6kPa5j8KB7nV3id5Eda54IfIK0NN1qKJV2z8iwWQkP0o0UOKbhurnCUnmhG5oEaYj4yHc+2ZFEEzYdxX2A60KNG5A98hkqZ8EdL38T3Wu26gRj4DcfMkF9CtMx; Received: from luuna.daevel.fr ([82.67.25.170] helo=[192.168.1.50]) by licorne.daevel.fr with esmtpsa (TLS1.0:RSA_AES_256_CBC_SHA1:32) (Exim 4.72) (envelope-from <xen.list@daevel.fr>) id 1R8hGM-000199-QX for xen-devel@lists.xensource.com; Wed, 28 Sep 2011 01:40:34 +0200 Message-ID: <4E825F2A.6060506@daevel.fr> Date: Wed, 28 Sep 2011 01:41:30 +0200 From: "Olivier B." <xen.list@daevel.fr> User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:5.0) Gecko/20110807 Icedove/5.0 MIME-Version: 1.0 To: xen-devel@lists.xensource.com Subject: Re: [Xen-devel] Re: [patch 1/1] ext4-fix-dirty-extent-when-origin-leaf-extent-reac.patch References: <BLU157-W499E698F650F554E645F9DDA1C0@phx.gbl> <20110906145347.GA4133@dumpdata.com> <BLU157-W4106FA4CF4EBA78C63FDA0DA1C0@phx.gbl> <4E666C86.5090707@goop.org> <BLU157-W323C330706CB8D7E976BC3DA1F0@phx.gbl> <BLU157-W7DABA5FE01C50C29B1A64DA060@phx.gbl> <BLU157-W25EB1EAC24CC11FA14859ADAF20@phx.gbl> <20110926142808.GG4102@phenom.oracle.com> <20110927193523.GB3309@thunk.org> In-Reply-To: <20110927193523.GB3309@thunk.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-BeenThere: xen-devel@lists.xensource.com X-Mailman-Version: 2.1.5 Precedence: list List-Id: Xen developer discussion <xen-devel.lists.xensource.com> List-Unsubscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe> List-Post: <mailto:xen-devel@lists.xensource.com> List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help> List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=subscribe> Sender: xen-devel-bounces@lists.xensource.com Errors-To: xen-devel-bounces@lists.xensource.com On 27/09/2011 21:35, Ted Ts'o wrote: > On Mon, Sep 26, 2011 at 10:28:08AM -0400, Konrad Rzeszutek Wilk wrote: >>> >>> Attached is the fix, verified in our env. >> >> So.. you are asking for this upstream git commit to be back-ported >> to 2.6.32, right? > > I'm curious --- is there a good reason why Xen users are using an > upstream 2.6.32 kernel? If they are using a distro kernel, fine, but > then the distro kernel should be providing the support. But at this > point, 2.6.32 is so positively *ancient* that, I'm personally not > interesting in providing free, unpaid distro support for users who > aren't willing to either (a) pay $$$ and get a supported distro > kernel, or (b) use a much more modern kernel. At this point, Guest > and Host Xen support is available in 3.0 kernels, so there's really no > excuse, right? > > - Ted > In my case, for Dom0 I use the 2.6.32 kernel from my distrib, because it's stable. I have stability problems with the kernel 3.0 on Dom0, and as I haven't physical access neither kvm or serial port, I don't know what to report... It just hang randomly, without any line in logs. Does the Xen support on 3.0 kernels should be considered stable ? _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel From xen-devel-bounces@lists.xensource.com Tue Sep 27 18:05:38 2011 Return-path: <xen-devel-bounces@lists.xensource.com> Envelope-to: www-data@lists.xensource.com Delivery-date: Tue, 27 Sep 2011 18:05:38 -0700 Received: from localhost ([127.0.0.1] helo=lists.colo.xensource.com) by lists.xensource.com with esmtp (Exim 4.43) id 1R8iaf-0000q0-Tj; Tue, 27 Sep 2011 18:05:37 -0700 Received: from mail182.messagelabs.com ([85.158.139.83]) by lists.xensource.com with esmtp (Exim 4.43) id 1R8iZl-0000dI-BX for xen-devel@lists.xensource.com; Tue, 27 Sep 2011 18:04:41 -0700 X-Env-Sender: jeremy@goop.org X-Msg-Ref: server-7.tower-182.messagelabs.com!1317171876!14993885!1 X-Originating-IP: [74.207.240.146] X-StarScan-Version: 6.4.1; banners=-,-,- X-VirusChecked: Checked Received: (qmail 12749 invoked from network); 28 Sep 2011 01:04:38 -0000 Received: from claw.goop.org (HELO claw.goop.org) (74.207.240.146) by server-7.tower-182.messagelabs.com with DHE-RSA-AES256-SHA encrypted SMTP; 28 Sep 2011 01:04:38 -0000 Received: from saboo.goop.org (unknown [IPv6:2001:470:1f05:899:f2de:f1ff:fe5c:34ed]) (Authenticated sender: smtp-saboo) by claw.goop.org (Postfix) with ESMTPSA id 9256394C3; Tue, 27 Sep 2011 18:04:35 -0700 (PDT) Received: from saboo.goop.org (localhost [IPv6:::1]) by saboo.goop.org (Postfix) with ESMTP id A385D20C28; Tue, 27 Sep 2011 12:58:27 -0700 (PDT) Message-ID: <4E822AE3.6050601@goop.org> Date: Tue, 27 Sep 2011 12:58:27 -0700 From: Jeremy Fitzhardinge <jeremy@goop.org> User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:6.0.2) Gecko/20110906 Thunderbird/6.0.2 MIME-Version: 1.0 To: =?ISO-8859-1?Q?T=F5nis_Bramanis?= <tonis@elkdata.ee> Subject: Re: [Xen-devel] Limit I/O for individual disks of VM References: <4E818A50.3050607@elkdata.ee> In-Reply-To: <4E818A50.3050607@elkdata.ee> X-Enigmail-Version: 1.3.2 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit Cc: xen-devel@lists.xensource.com X-BeenThere: xen-devel@lists.xensource.com X-Mailman-Version: 2.1.5 Precedence: list List-Id: Xen developer discussion <xen-devel.lists.xensource.com> List-Unsubscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe> List-Post: <mailto:xen-devel@lists.xensource.com> List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help> List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=subscribe> Sender: xen-devel-bounces@lists.xensource.com Errors-To: xen-devel-bounces@lists.xensource.com On 09/27/2011 01:33 AM, Tõnis Bramanis wrote: > Hello! > > Will disk i/o limiting be added in any future versions? I see it in > the 4.0 feature requests, but not in any changelogs. I think the hope is that we can use the generic Linux mechanisms for this rather than having to add anything Xen-specific. J _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel From xen-devel-bounces@lists.xensource.com Tue Sep 27 18:10:21 2011 Return-path: <xen-devel-bounces@lists.xensource.com> Envelope-to: www-data@lists.xensource.com Delivery-date: Tue, 27 Sep 2011 18:10:21 -0700 Received: from localhost ([127.0.0.1] helo=lists.colo.xensource.com) by lists.xensource.com with esmtp (Exim 4.43) id 1R8ifE-0001GZ-Vf; Tue, 27 Sep 2011 18:10:21 -0700 Received: from mail182.messagelabs.com ([85.158.139.83]) by lists.xensource.com with esmtp (Exim 4.43) id 1R8ieZ-00014C-1C for xen-devel@lists.xensource.com; Tue, 27 Sep 2011 18:09:39 -0700 X-Env-Sender: jeremy@goop.org X-Msg-Ref: server-3.tower-182.messagelabs.com!1317172174!17207800!1 X-Originating-IP: [74.207.240.146] X-StarScan-Version: 6.4.1; banners=-,-,- X-VirusChecked: Checked Received: (qmail 21115 invoked from network); 28 Sep 2011 01:09:35 -0000 Received: from claw.goop.org (HELO claw.goop.org) (74.207.240.146) by server-3.tower-182.messagelabs.com with DHE-RSA-AES256-SHA encrypted SMTP; 28 Sep 2011 01:09:35 -0000 Received: from saboo.goop.org (unknown [IPv6:2001:470:1f05:899:f2de:f1ff:fe5c:34ed]) (Authenticated sender: smtp-saboo) by claw.goop.org (Postfix) with ESMTPSA id B9AE294CE; Tue, 27 Sep 2011 18:09:33 -0700 (PDT) Received: from saboo.goop.org (localhost [IPv6:::1]) by saboo.goop.org (Postfix) with ESMTP id 867F0209D6; Tue, 27 Sep 2011 12:57:26 -0700 (PDT) Message-ID: <4E822AA6.4010605@goop.org> Date: Tue, 27 Sep 2011 12:57:26 -0700 From: Jeremy Fitzhardinge <jeremy@goop.org> User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:6.0.2) Gecko/20110906 Thunderbird/6.0.2 MIME-Version: 1.0 To: Jan Beulich <JBeulich@suse.com> X-Enigmail-Version: 1.3.2 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>, Konrad Rzeszutek Wilk <konrad.wilk@oracle.com> Subject: [Xen-devel] MSI error when reloading iwlagn module X-BeenThere: xen-devel@lists.xensource.com X-Mailman-Version: 2.1.5 Precedence: list List-Id: Xen developer discussion <xen-devel.lists.xensource.com> List-Unsubscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe> List-Post: <mailto:xen-devel@lists.xensource.com> List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help> List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=subscribe> Sender: xen-devel-bounces@lists.xensource.com Errors-To: xen-devel-bounces@lists.xensource.com Hi, With a fairly current kernel + xen, I'm seeing this if I rmmod iwlagn and try to reload it: [51230.646678] Intel(R) Wireless WiFi Link AGN driver for Linux, in-tree: [51230.646685] Copyright(c) 2003-2011 Intel Corporation [51230.646760] xen: registering gsi 17 triggering 0 polarity 1 [51230.646773] xen_map_pirq_gsi: returning irq 17 for gsi 17 [51230.646777] xen: --> pirq=17 -> irq=17 (gsi=17) [51230.646781] Already setup the GSI :17 [51230.646789] iwlagn 0000:03:00.0: PCI INT A -> GSI 17 (level, low) -> IRQ 17 [51230.646814] iwlagn 0000:03:00.0: setting latency timer to 64 [51230.646935] iwlagn 0000:03:00.0: pci_resource_len = 0x00002000 [51230.646941] iwlagn 0000:03:00.0: pci_resource_base = ffffc9000671c000 [51230.646945] iwlagn 0000:03:00.0: HW Revision ID = 0x35 [51230.647075] iwlagn 0000:03:00.0: xen map irq failed -22 for 32752 domain [51230.647081] iwlagn 0000:03:00.0: pci_enable_msi failed [51230.647113] iwlagn 0000:03:00.0: PCI INT A disabled [51230.647126] iwlagn: probe of 0000:03:00.0 failed with error -22 with this on the Xen console (XEN) physdev.c:139: dom0: can't create irq for msi! I'm running Xen as of a422e2a4451e, which your MSI changes in them, which I suspect of having caused a regression (since I don't remember having problems reloading msi-using drivers before). Thanks, J _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel From xen-devel-bounces@lists.xensource.com Tue Sep 27 18:23:52 2011 Return-path: <xen-devel-bounces@lists.xensource.com> Envelope-to: www-data@lists.xensource.com Delivery-date: Tue, 27 Sep 2011 18:23:52 -0700 Received: from localhost ([127.0.0.1] helo=lists.colo.xensource.com) by lists.xensource.com with esmtp (Exim 4.43) id 1R8isJ-0001o6-Tz; Tue, 27 Sep 2011 18:23:51 -0700 Received: from mail27.messagelabs.com ([193.109.254.147]) by lists.xensource.com with esmtp (Exim 4.43) id 1R8irl-0001cM-7o for xen-devel@lists.xensource.com; Tue, 27 Sep 2011 18:23:17 -0700 X-Env-Sender: chintamani.sid@gmail.com X-Msg-Ref: server-3.tower-27.messagelabs.com!1317172968!41420151!1 X-Originating-IP: [216.139.236.26] X-StarScan-Version: 6.4.1; banners=-,-,- X-VirusChecked: Checked Received: (qmail 13907 invoked from network); 28 Sep 2011 01:22:49 -0000 Received: from sam.nabble.com (HELO sam.nabble.com) (216.139.236.26) by server-3.tower-27.messagelabs.com with AES256-SHA encrypted SMTP; 28 Sep 2011 01:22:49 -0000 Received: from [192.168.236.26] (helo=sam.nabble.com) by sam.nabble.com with esmtp (Exim 4.72) (envelope-from <chintamani.sid@gmail.com>) id 1R8irg-0003Wy-1l for xen-devel@lists.xensource.com; Tue, 27 Sep 2011 18:23:12 -0700 Date: Tue, 27 Sep 2011 18:23:12 -0700 (PDT) From: Chintu <chintamani.sid@gmail.com> To: xen-devel@lists.xensource.com Message-ID: <1317172992048-4847541.post@n5.nabble.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Subject: [Xen-devel] Getting the page fault count for domU X-BeenThere: xen-devel@lists.xensource.com X-Mailman-Version: 2.1.5 Precedence: list List-Id: Xen developer discussion <xen-devel.lists.xensource.com> List-Unsubscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe> List-Post: <mailto:xen-devel@lists.xensource.com> List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help> List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=subscribe> Sender: xen-devel-bounces@lists.xensource.com Errors-To: xen-devel-bounces@lists.xensource.com Hi How do we get the number of page faults done by a guest in a scheduling epoch? Assuming only one VCPU per guest, can I get it from vcpu_info[]? I hope this is not a vey trivial question :) thanks Chintu -- View this message in context: http://xen.1045712.n5.nabble.com/Getting-the-page-fault-count-for-domU-tp4847541p4847541.html Sent from the Xen - Dev mailing list archive at Nabble.com. _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel From xen-devel-bounces@lists.xensource.com Tue Sep 27 18:51:58 2011 Return-path: <xen-devel-bounces@lists.xensource.com> Envelope-to: www-data@lists.xensource.com Delivery-date: Tue, 27 Sep 2011 18:51:58 -0700 Received: from localhost ([127.0.0.1] helo=lists.colo.xensource.com) by lists.xensource.com with esmtp (Exim 4.43) id 1R8jJW-0002vI-Dk; Tue, 27 Sep 2011 18:51:58 -0700 Received: from mail21.messagelabs.com ([85.158.143.35]) by lists.xensource.com with esmtp (Exim 4.43) id 1R8jIm-0002jO-VR for xen-devel@lists.xensource.com; Tue, 27 Sep 2011 18:51:13 -0700 X-Env-Sender: Ian.Jackson@eu.citrix.com X-Msg-Ref: server-9.tower-21.messagelabs.com!1317174624!50065528!1 X-Originating-IP: [62.200.22.115] X-StarScan-Version: 6.4.1; banners=-,-,- X-VirusChecked: Checked Received: (qmail 20083 invoked from network); 28 Sep 2011 01:50:24 -0000 Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115) by server-9.tower-21.messagelabs.com with RC4-SHA encrypted SMTP; 28 Sep 2011 01:50:24 -0000 X-IronPort-AV: E=Sophos;i="4.68,452,1312156800"; d="scan'208";a="8093453" Received: from lonpmailmx01.citrite.net ([10.30.203.162]) by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5; 28 Sep 2011 01:50:52 +0000 Received: from woking.xci-test.com (10.80.248.135) by smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id 8.3.137.0; Wed, 28 Sep 2011 02:50:53 +0100 Received: from osstest by woking.xci-test.com with local (Exim 4.69) (envelope-from <ian.jackson@eu.citrix.com>) id 1R8jIS-0008VI-D0; Wed, 28 Sep 2011 02:50:52 +0100 To: <xen-devel@lists.xensource.com> Message-ID: <osstest-9109-mainreport@xen.org> From: xen.org <ian.jackson@eu.citrix.com> Date: Wed, 28 Sep 2011 02:50:52 +0100 MIME-Version: 1.0 Content-Type: text/plain Cc: ian.jackson@eu.citrix.com Subject: [Xen-devel] [xen-unstable test] 9109: tolerable FAIL - PUSHED X-BeenThere: xen-devel@lists.xensource.com X-Mailman-Version: 2.1.5 Precedence: list List-Id: Xen developer discussion <xen-devel.lists.xensource.com> List-Unsubscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe> List-Post: <mailto:xen-devel@lists.xensource.com> List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help> List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=subscribe> Sender: xen-devel-bounces@lists.xensource.com Errors-To: xen-devel-bounces@lists.xensource.com flight 9109 xen-unstable real [real] http://www.chiark.greenend.org.uk/~xensrcts/logs/9109/ Failures :-/ but no regressions. Tests which did not succeed, but are not blocking, including regressions (tests previously passed) regarded as allowable: test-amd64-amd64-xl-pcipt-intel 9 guest-start fail never pass test-amd64-i386-rhel6hvm-intel 9 guest-start.2 fail never pass test-amd64-i386-win-vcpus1 16 leak-check/check fail never pass test-amd64-i386-rhel6hvm-amd 9 guest-start.2 fail never pass test-amd64-amd64-win 16 leak-check/check fail never pass test-amd64-i386-xl-win-vcpus1 13 guest-stop fail never pass test-amd64-i386-win 16 leak-check/check fail never pass test-amd64-amd64-xl-win 13 guest-stop fail never pass test-i386-i386-win 16 leak-check/check fail never pass test-i386-i386-xl-win 13 guest-stop fail never pass version targeted for testing: xen bfa65eb40b2a baseline version: xen a422e2a4451e ------------------------------------------------------------ People who touched revisions under test: Andreas Herrmann <herrmann.der.user@googlemail.com> Ian Campbell <ian.campbell@citrix.com> Ian Jackson <ian.jackson@eu.citrix.com> Jan Beulich <jbeulich@suse.com> Lasse Collin <lasse.collin@tukaani.org> Olaf Hering <olaf@aepfle.de> Paul Durrant <paul.durrant@citrix.com> Thomas Renninger <trenn@suse.de> Tim Deegan <tim@xen.org> ------------------------------------------------------------ jobs: build-amd64 pass build-i386 pass build-amd64-oldkern pass build-i386-oldkern pass build-amd64-pvops pass build-i386-pvops pass test-amd64-amd64-xl pass test-amd64-i386-xl pass test-i386-i386-xl pass test-amd64-i386-rhel6hvm-amd fail test-amd64-i386-xl-credit2 pass test-amd64-amd64-xl-pcipt-intel fail test-amd64-i386-rhel6hvm-intel fail test-amd64-i386-xl-multivcpu pass test-amd64-amd64-pair pass test-amd64-i386-pair pass test-i386-i386-pair pass test-amd64-amd64-pv pass test-amd64-i386-pv pass test-i386-i386-pv pass test-amd64-amd64-xl-sedf pass test-amd64-i386-win-vcpus1 fail test-amd64-i386-xl-win-vcpus1 fail test-amd64-amd64-win fail test-amd64-i386-win fail test-i386-i386-win fail test-amd64-amd64-xl-win fail test-i386-i386-xl-win fail ------------------------------------------------------------ sg-report-flight on woking.cam.xci-test.com logs: /home/xc_osstest/logs images: /home/xc_osstest/images Logs, config files, etc. are available at http://www.chiark.greenend.org.uk/~xensrcts/logs Test harness code can be found at http://xenbits.xensource.com/gitweb?p=osstest.git;a=summary Pushing revision : + branch=xen-unstable + revision=bfa65eb40b2a + . cri-lock-repos ++ . cri-common +++ umask 002 +++ getconfig Repos +++ perl -e ' use Osstest; readconfigonly(); print $c{Repos} or die $!; ' ++ repos=/export/home/osstest/repos ++ repos_lock=/export/home/osstest/repos/lock ++ '[' x '!=' x/export/home/osstest/repos/lock ']' ++ OSSTEST_REPOS_LOCK_LOCKED=/export/home/osstest/repos/lock ++ exec with-lock-ex -w /export/home/osstest/repos/lock ./ap-push xen-unstable bfa65eb40b2a + branch=xen-unstable + revision=bfa65eb40b2a + . cri-lock-repos ++ . cri-common +++ umask 002 +++ getconfig Repos +++ perl -e ' use Osstest; readconfigonly(); print $c{Repos} or die $!; ' ++ repos=/export/home/osstest/repos ++ repos_lock=/export/home/osstest/repos/lock ++ '[' x/export/home/osstest/repos/lock '!=' x/export/home/osstest/repos/lock ']' + : xen@xenbits.xensource.com + : xen@xenbits.xensource.com:git/linux-pvops + : master + : tested/2.6.39.x + case "$branch" in + cd /export/home/osstest/repos/xen-unstable.hg + hg push -r bfa65eb40b2a ssh://xen@xenbits.xensource.com/HG/xen-unstable.hg pushing to ssh://xen@xenbits.xensource.com/HG/xen-unstable.hg searching for changes remote: adding changesets remote: adding manifests remote: adding file changes remote: added 17 changesets with 74 changes to 53 files _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel From xen-devel-bounces@lists.xensource.com Tue Sep 27 21:10:42 2011 Return-path: <xen-devel-bounces@lists.xensource.com> Envelope-to: www-data@lists.xensource.com Delivery-date: Tue, 27 Sep 2011 21:10:42 -0700 Received: from localhost ([127.0.0.1] helo=lists.colo.xensource.com) by lists.xensource.com with esmtp (Exim 4.43) id 1R8lTm-00076M-HH; Tue, 27 Sep 2011 21:10:42 -0700 Received: from mail27.messagelabs.com ([193.109.254.147]) by lists.xensource.com with smtp (Exim 4.43) id 1R8lSp-0006tm-Am for xen-devel@lists.xensource.com; Tue, 27 Sep 2011 21:09:44 -0700 X-Env-Sender: tinnycloud@hotmail.com X-Msg-Ref: server-12.tower-27.messagelabs.com!1317182963!44207915!1 X-Originating-IP: [65.55.116.82] X-StarScan-Version: 6.4.1; banners=-,-,- X-VirusChecked: Checked Received: (qmail 741 invoked from network); 28 Sep 2011 04:09:24 -0000 Received: from blu0-omc3-s7.blu0.hotmail.com (HELO blu0-omc3-s7.blu0.hotmail.com) (65.55.116.82) by server-12.tower-27.messagelabs.com with SMTP; 28 Sep 2011 04:09:24 -0000 Received: from BLU157-W9 ([65.55.116.72]) by blu0-omc3-s7.blu0.hotmail.com with Microsoft SMTPSVC(6.0.3790.4675); Tue, 27 Sep 2011 21:09:39 -0700 Message-ID: <BLU157-W95100AF9A3CA3897D3964DAF10@phx.gbl> X-Originating-IP: [121.0.29.75] From: MaoXiaoyun <tinnycloud@hotmail.com> To: <tytso@mit.edu>, <konrad.wilk@oracle.com> Date: Wed, 28 Sep 2011 12:09:39 +0800 Importance: Normal In-Reply-To: <20110927193523.GB3309@thunk.org> References: <BLU157-W499E698F650F554E645F9DDA1C0@phx.gbl>, <20110906145347.GA4133@dumpdata.com>, <BLU157-W4106FA4CF4EBA78C63FDA0DA1C0@phx.gbl>, <4E666C86.5090707@goop.org>, <BLU157-W323C330706CB8D7E976BC3DA1F0@phx.gbl>, <BLU157-W7DABA5FE01C50C29B1A64DA060@phx.gbl>, <BLU157-W25EB1EAC24CC11FA14859ADAF20@phx.gbl>, <20110926142808.GG4102@phenom.oracle.com>, <20110927193523.GB3309@thunk.org> Content-Type: text/plain; charset="gb2312" Content-Transfer-Encoding: 8bit MIME-Version: 1.0 X-OriginalArrivalTime: 28 Sep 2011 04:09:39.0636 (UTC) FILETIME=[714C4F40:01CC7D94] Cc: jeremy@goop.org, linux-ext4@vger.kernel.org, jack@suse.cz, xen devel <xen-devel@lists.xensource.com> Subject: [Xen-devel] RE: [patch 1/1] ext4-fix-dirty-extent-when-origin-leaf-extent-reac.patch X-BeenThere: xen-devel@lists.xensource.com X-Mailman-Version: 2.1.5 Precedence: list List-Id: Xen developer discussion <xen-devel.lists.xensource.com> List-Unsubscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe> List-Post: <mailto:xen-devel@lists.xensource.com> List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help> List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=subscribe> Sender: xen-devel-bounces@lists.xensource.com Errors-To: xen-devel-bounces@lists.xensource.com ---------------------------------------- > Date: Tue, 27 Sep 2011 15:35:23 -0400 > From: tytso@mit.edu > To: konrad.wilk@oracle.com > CC: tinnycloud@hotmail.com; linux-ext4@vger.kernel.org; xen-devel@lists.xensource.com; jack@suse.cz > Subject: Re: [patch 1/1] ext4-fix-dirty-extent-when-origin-leaf-extent-reac.patch > > On Mon, Sep 26, 2011 at 10:28:08AM -0400, Konrad Rzeszutek Wilk wrote: > > > > > > Attached is the fix, verified in our env. > > > > So.. you are asking for this upstream git commit to be back-ported > > to 2.6.32, right? > > I'm curious --- is there a good reason why Xen users are using an > upstream 2.6.32 kernel? If they are using a distro kernel, fine, but > then the distro kernel should be providing the support. But at this > point, 2.6.32 is so positively *ancient* that, I'm personally not > interesting in providing free, unpaid distro support for users who > aren't willing to either (a) pay $$$ and get a supported distro > kernel, or (b) use a much more modern kernel. At this point, Guest > and Host Xen support is available in 3.0 kernels, so there's really no > excuse, right? Mmm... We first met this bug at pvops kernel(jeremy's tree, 2.6.32.36). We failed to find any related fix from google, so we debug the bug ourself. Fortunately, we located root cause and thought some other xen users might have this problem as well, that's why we sent out the fix to Xen-devel. We go through the code from 2.6.32 - 2.6.39, this bug exists. People who use *ancient* kernel need this. Thanks. > - Ted > -- > To unsubscribe from this list: send the line "unsubscribe linux-ext4" in > the body of a message to majordomo@vger.kernel.org > More majordomo info at http://vger.kernel.org/majordomo-info.html _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel From xen-devel-bounces@lists.xensource.com Tue Sep 27 22:30:29 2011 Return-path: <xen-devel-bounces@lists.xensource.com> Envelope-to: www-data@lists.xensource.com Delivery-date: Tue, 27 Sep 2011 22:30:29 -0700 Received: from localhost ([127.0.0.1] helo=lists.colo.xensource.com) by lists.xensource.com with esmtp (Exim 4.43) id 1R8miy-0002dR-I0; Tue, 27 Sep 2011 22:30:28 -0700 Received: from mail27.messagelabs.com ([193.109.254.147]) by lists.xensource.com with esmtp (Exim 4.43) id 1R8miB-0002Qo-JP for xen-devel@lists.xensource.com; Tue, 27 Sep 2011 22:29:39 -0700 X-Env-Sender: Ian.Jackson@eu.citrix.com X-Msg-Ref: server-14.tower-27.messagelabs.com!1317187761!37920837!1 X-Originating-IP: [62.200.22.115] X-StarScan-Version: 6.4.1; banners=-,-,- X-VirusChecked: Checked Received: (qmail 5407 invoked from network); 28 Sep 2011 05:29:21 -0000 Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115) by server-14.tower-27.messagelabs.com with RC4-SHA encrypted SMTP; 28 Sep 2011 05:29:21 -0000 X-IronPort-AV: E=Sophos;i="4.68,453,1312156800"; d="scan'208";a="8094395" Received: from lonpmailmx01.citrite.net ([10.30.203.162]) by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5; 28 Sep 2011 05:29:36 +0000 Received: from woking.xci-test.com (10.80.248.135) by smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id 8.3.137.0; Wed, 28 Sep 2011 06:29:35 +0100 Received: from osstest by woking.xci-test.com with local (Exim 4.69) (envelope-from <ian.jackson@eu.citrix.com>) id 1R8mi7-0000Gm-Me; Wed, 28 Sep 2011 06:29:35 +0100 To: xen-devel@lists.xensource.com Message-ID: <osstest-9110-mainreport@xen.org> From: xen.org <ian.jackson@eu.citrix.com> Date: Wed, 28 Sep 2011 06:29:35 +0100 MIME-Version: 1.0 Content-Type: text/plain Cc: ian.jackson@eu.citrix.com Subject: [Xen-devel] [xen-unstable test] 9110: tolerable FAIL X-BeenThere: xen-devel@lists.xensource.com X-Mailman-Version: 2.1.5 Precedence: list List-Id: Xen developer discussion <xen-devel.lists.xensource.com> List-Unsubscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe> List-Post: <mailto:xen-devel@lists.xensource.com> List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help> List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=subscribe> Sender: xen-devel-bounces@lists.xensource.com Errors-To: xen-devel-bounces@lists.xensource.com flight 9110 xen-unstable real [real] http://www.chiark.greenend.org.uk/~xensrcts/logs/9110/ Failures :-/ but no regressions. Tests which did not succeed, but are not blocking, including regressions (tests previously passed) regarded as allowable: test-amd64-amd64-xl-pcipt-intel 9 guest-start fail never pass test-amd64-i386-rhel6hvm-intel 9 guest-start.2 fail never pass test-amd64-i386-win-vcpus1 16 leak-check/check fail never pass test-amd64-i386-rhel6hvm-amd 9 guest-start.2 fail never pass test-amd64-amd64-win 16 leak-check/check fail never pass test-amd64-i386-xl-win-vcpus1 13 guest-stop fail never pass test-amd64-i386-win 16 leak-check/check fail never pass test-amd64-amd64-xl-win 13 guest-stop fail never pass test-i386-i386-win 14 guest-start.2 fail like 9105 test-i386-i386-xl-win 13 guest-stop fail never pass version targeted for testing: xen bfa65eb40b2a baseline version: xen bfa65eb40b2a jobs: build-amd64 pass build-i386 pass build-amd64-oldkern pass build-i386-oldkern pass build-amd64-pvops pass build-i386-pvops pass test-amd64-amd64-xl pass test-amd64-i386-xl pass test-i386-i386-xl pass test-amd64-i386-rhel6hvm-amd fail test-amd64-i386-xl-credit2 pass test-amd64-amd64-xl-pcipt-intel fail test-amd64-i386-rhel6hvm-intel fail test-amd64-i386-xl-multivcpu pass test-amd64-amd64-pair pass test-amd64-i386-pair pass test-i386-i386-pair pass test-amd64-amd64-pv pass test-amd64-i386-pv pass test-i386-i386-pv pass test-amd64-amd64-xl-sedf pass test-amd64-i386-win-vcpus1 fail test-amd64-i386-xl-win-vcpus1 fail test-amd64-amd64-win fail test-amd64-i386-win fail test-i386-i386-win fail test-amd64-amd64-xl-win fail test-i386-i386-xl-win fail ------------------------------------------------------------ sg-report-flight on woking.cam.xci-test.com logs: /home/xc_osstest/logs images: /home/xc_osstest/images Logs, config files, etc. are available at http://www.chiark.greenend.org.uk/~xensrcts/logs Test harness code can be found at http://xenbits.xensource.com/gitweb?p=osstest.git;a=summary Published tested tree is already up to date. _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel From xen-devel-bounces@lists.xensource.com Tue Sep 27 23:34:25 2011 Return-path: <xen-devel-bounces@lists.xensource.com> Envelope-to: www-data@lists.xensource.com Delivery-date: Tue, 27 Sep 2011 23:34:25 -0700 Received: from localhost ([127.0.0.1] helo=lists.colo.xensource.com) by lists.xensource.com with esmtp (Exim 4.43) id 1R8niq-0004HB-E2; Tue, 27 Sep 2011 23:34:24 -0700 Received: from mail216.messagelabs.com ([85.158.143.99]) by lists.xensource.com with esmtp (Exim 4.43) id 1R8nhQ-00043a-Rc for xen-devel@lists.xensource.com; Tue, 27 Sep 2011 23:32:58 -0700 X-Env-Sender: mingo@elte.hu X-Msg-Ref: server-3.tower-216.messagelabs.com!1317191573!18803961!1 X-Originating-IP: [157.181.151.9] X-StarScan-Version: 6.4.1; banners=-,-,- X-VirusChecked: Checked Received: (qmail 5450 invoked from network); 28 Sep 2011 06:32:53 -0000 Received: from mx2.mail.elte.hu (HELO mx2.mail.elte.hu) (157.181.151.9) by server-3.tower-216.messagelabs.com with DHE-RSA-AES256-SHA encrypted SMTP; 28 Sep 2011 06:32:53 -0000 Received: from elvis.elte.hu ([157.181.1.14]) by mx2.mail.elte.hu with esmtp (Exim) id 1R8nh9-0003dQ-Hx from <mingo@elte.hu>; Wed, 28 Sep 2011 08:32:49 +0200 Received: by elvis.elte.hu (Postfix, from userid 1004) id 49BAF3E2588; Wed, 28 Sep 2011 08:32:32 +0200 (CEST) Date: Wed, 28 Sep 2011 08:31:15 +0200 From: Ingo Molnar <mingo@elte.hu> To: Jeremy Fitzhardinge <jeremy@goop.org> Message-ID: <20110928063115.GA24510@elte.hu> References: <alpine.LFD.2.02.1109280209430.2711@ionos> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <alpine.LFD.2.02.1109280209430.2711@ionos> User-Agent: Mutt/1.5.21 (2010-09-15) Received-SPF: neutral (mx2.mail.elte.hu: 157.181.1.14 is neither permitted nor denied by domain of elte.hu) client-ip=157.181.1.14; envelope-from=mingo@elte.hu; helo=elvis.elte.hu; X-ELTE-SpamScore: -1.9 X-ELTE-SpamLevel: X-ELTE-SpamCheck: no X-ELTE-SpamVersion: ELTE 2.0 X-ELTE-SpamCheck-Details: score=-1.9 required=5.9 tests=AWL, BAYES_00 autolearn=no SpamAssassin version=3.3.1 -2.0 BAYES_00 BODY: Bayes spam probability is 0 to 1% [score: 0.0000] 0.1 AWL AWL: From: address is in the auto white-list Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>, the arch/x86 maintainers <x86@kernel.org>, Linux Kernel Mailing List <linux-kernel@vger.kernel.org>, "H. Peter Anvin" <hpa@zytor.com> Subject: [Xen-devel] Re: Could you reinstate ticketlock cleanups in tip.git X-BeenThere: xen-devel@lists.xensource.com X-Mailman-Version: 2.1.5 Precedence: list List-Id: Xen developer discussion <xen-devel.lists.xensource.com> List-Unsubscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe> List-Post: <mailto:xen-devel@lists.xensource.com> List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help> List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=subscribe> Sender: xen-devel-bounces@lists.xensource.com Errors-To: xen-devel-bounces@lists.xensource.com * Thomas Gleixner <tglx@linutronix.de> wrote: > Hi Thomas, > > Could you reinstate the ticketlock cleanup series in tip.git (I think it > was in x86/spinlocks) from > git://github.com/jsgf/linux-xen.git upstream/ticketlock-cleanup > > This branch is the final result of all the discussions and revisions and > is ready for the next merge window. It's the one that's been in > linux-next for a couple of weeks (at least), and won't cause any > conflicts there. > > Or if you prefer I can submit it myself for next merge window. > > Thanks, > J I'd prefer if this went via x86/spinlocks. Could you please send a proper pull request with diffstat, shortlog, etc? Thanks, Ingo _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel From xen-devel-bounces@lists.xensource.com Tue Sep 27 23:35:54 2011 Return-path: <xen-devel-bounces@lists.xensource.com> Envelope-to: www-data@lists.xensource.com Delivery-date: Tue, 27 Sep 2011 23:35:54 -0700 Received: from localhost ([127.0.0.1] helo=lists.colo.xensource.com) by lists.xensource.com with esmtp (Exim 4.43) id 1R8nkI-0004kw-B9; Tue, 27 Sep 2011 23:35:54 -0700 Received: from mail182.messagelabs.com ([85.158.139.83]) by lists.xensource.com with esmtp (Exim 4.43) id 1R8njZ-0004R6-S9 for xen-devel@lists.xensource.com; Tue, 27 Sep 2011 23:35:10 -0700 X-Env-Sender: jeremy@goop.org X-Msg-Ref: server-5.tower-182.messagelabs.com!1317191704!15040203!1 X-Originating-IP: [74.207.240.146] X-StarScan-Version: 6.4.1; banners=-,-,- X-VirusChecked: Checked Received: (qmail 11093 invoked from network); 28 Sep 2011 06:35:06 -0000 Received: from claw.goop.org (HELO claw.goop.org) (74.207.240.146) by server-5.tower-182.messagelabs.com with DHE-RSA-AES256-SHA encrypted SMTP; 28 Sep 2011 06:35:06 -0000 Received: from saboo.goop.org (unknown [IPv6:2001:470:1f05:899:f2de:f1ff:fe5c:34ed]) (Authenticated sender: smtp-saboo) by claw.goop.org (Postfix) with ESMTPSA id 5AF62431; Tue, 27 Sep 2011 23:35:04 -0700 (PDT) Received: from saboo.goop.org (localhost [IPv6:::1]) by saboo.goop.org (Postfix) with ESMTP id B6C792022D; Tue, 27 Sep 2011 23:35:03 -0700 (PDT) Message-ID: <4E82C017.1050803@goop.org> Date: Tue, 27 Sep 2011 23:35:03 -0700 From: Jeremy Fitzhardinge <jeremy@goop.org> User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:6.0.2) Gecko/20110906 Thunderbird/6.0.2 MIME-Version: 1.0 To: =?ISO-8859-1?Q?T=F5nis_Bramanis?= <tonis@elkdata.ee> Subject: Re: [Xen-devel] Limit I/O for individual disks of VM References: <4E818A50.3050607@elkdata.ee> <4E822AE3.6050601@goop.org> <4E82BDC0.7040604@elkdata.ee> In-Reply-To: <4E82BDC0.7040604@elkdata.ee> X-Enigmail-Version: 1.3.2 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit Cc: xen-devel@lists.xensource.com X-BeenThere: xen-devel@lists.xensource.com X-Mailman-Version: 2.1.5 Precedence: list List-Id: Xen developer discussion <xen-devel.lists.xensource.com> List-Unsubscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe> List-Post: <mailto:xen-devel@lists.xensource.com> List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help> List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=subscribe> Sender: xen-devel-bounces@lists.xensource.com Errors-To: xen-devel-bounces@lists.xensource.com On 09/27/2011 11:25 PM, Tõnis Bramanis wrote: > Hello > > and thank You for the answer. Has anyone of You tried to limit i/o on > the VMs? > > I have about 40 containers and when the i/o gets too high, the host > will crash with this error: > [23959.739698] sd 4:0:0:0: rejecting I/O to offline device > 5 [23959.771158] Buffer I/O error on device dm-0, logical block 40259 > > This is not a support request! I am just referring why i would like to > limit the disks i/o. I think that IO error is a real problem that you should try to solve, rather than work around it by rate-limiting IO. J > > Regards, > Tõnis Bramanis > > On 27.09.2011 22:58, Jeremy Fitzhardinge wrote: >> On 09/27/2011 01:33 AM, Tõnis Bramanis wrote: >>> Hello! >>> >>> Will disk i/o limiting be added in any future versions? I see it in >>> the 4.0 feature requests, but not in any changelogs. >> >> I think the hope is that we can use the generic Linux mechanisms for >> this rather than having to add anything Xen-specific. >> >> J > _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel From xen-devel-bounces@lists.xensource.com Tue Sep 27 23:41:26 2011 Return-path: <xen-devel-bounces@lists.xensource.com> Envelope-to: www-data@lists.xensource.com Delivery-date: Tue, 27 Sep 2011 23:41:26 -0700 Received: from localhost ([127.0.0.1] helo=lists.colo.xensource.com) by lists.xensource.com with esmtp (Exim 4.43) id 1R8npe-0005OZ-JG; Tue, 27 Sep 2011 23:41:26 -0700 Received: from mail174.messagelabs.com ([85.158.138.51]) by lists.xensource.com with esmtp (Exim 4.43) id 1R8np1-0005C8-Tj for xen-devel@lists.xensource.com; Tue, 27 Sep 2011 23:40:51 -0700 X-Env-Sender: jeremy@goop.org X-Msg-Ref: server-14.tower-174.messagelabs.com!1317192043!33025363!1 X-Originating-IP: [74.207.240.146] X-StarScan-Version: 6.4.1; banners=-,-,- X-VirusChecked: Checked Received: (qmail 14645 invoked from network); 28 Sep 2011 06:40:44 -0000 Received: from claw.goop.org (HELO claw.goop.org) (74.207.240.146) by server-14.tower-174.messagelabs.com with DHE-RSA-AES256-SHA encrypted SMTP; 28 Sep 2011 06:40:44 -0000 Received: from saboo.goop.org (unknown [IPv6:2001:470:1f05:899:f2de:f1ff:fe5c:34ed]) (Authenticated sender: smtp-saboo) by claw.goop.org (Postfix) with ESMTPSA id 82E5A8ADE; Tue, 27 Sep 2011 23:40:42 -0700 (PDT) Received: from saboo.goop.org (localhost [IPv6:::1]) by saboo.goop.org (Postfix) with ESMTP id 0E1732022E; Tue, 27 Sep 2011 23:40:41 -0700 (PDT) Message-ID: <4E82C169.8060803@goop.org> Date: Tue, 27 Sep 2011 23:40:41 -0700 From: Jeremy Fitzhardinge <jeremy@goop.org> User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:6.0.2) Gecko/20110906 Thunderbird/6.0.2 MIME-Version: 1.0 To: Ingo Molnar <mingo@elte.hu> References: <alpine.LFD.2.02.1109280209430.2711@ionos> <20110928063115.GA24510@elte.hu> In-Reply-To: <20110928063115.GA24510@elte.hu> X-Enigmail-Version: 1.3.2 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>, the arch/x86 maintainers <x86@kernel.org>, Linux Kernel Mailing List <linux-kernel@vger.kernel.org>, "H. Peter Anvin" <hpa@zytor.com> Subject: [Xen-devel] Re: Could you reinstate ticketlock cleanups in tip.git X-BeenThere: xen-devel@lists.xensource.com X-Mailman-Version: 2.1.5 Precedence: list List-Id: Xen developer discussion <xen-devel.lists.xensource.com> List-Unsubscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe> List-Post: <mailto:xen-devel@lists.xensource.com> List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help> List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=subscribe> Sender: xen-devel-bounces@lists.xensource.com Errors-To: xen-devel-bounces@lists.xensource.com On 09/27/2011 11:31 PM, Ingo Molnar wrote: > * Thomas Gleixner <tglx@linutronix.de> wrote: > >> Hi Thomas, >> >> Could you reinstate the ticketlock cleanup series in tip.git (I think it >> was in x86/spinlocks) from >> git://github.com/jsgf/linux-xen.git upstream/ticketlock-cleanup >> >> This branch is the final result of all the discussions and revisions and >> is ready for the next merge window. It's the one that's been in >> linux-next for a couple of weeks (at least), and won't cause any >> conflicts there. >> >> Or if you prefer I can submit it myself for next merge window. >> >> Thanks, >> J > I'd prefer if this went via x86/spinlocks. Could you please send a > proper pull request with diffstat, shortlog, etc? > Sure, here you are: The following changes since commit c6a389f123b9f68d605bb7e0f9b32ec1e3e14132: Linux 3.1-rc4 (2011-08-28 21:16:01 -0700) are available in the git repository at: git://github.com/jsgf/linux-xen upstream/ticketlock-cleanup (commit 4a7f340c6a75ec5fca23d9c80a59f3f28cc4a61e) Jeremy Fitzhardinge (12): x86, cmpxchg: <linux/alternative.h> has LOCK_PREFIX x86, cmpxchg: Move 32-bit __cmpxchg_wrong_size to match 64 bit. x86, cmpxchg: Move 64-bit set64_bit() to match 32-bit x86, cmpxchg: Unify cmpxchg into cmpxchg.h x86: Add xadd helper macro x86: Use xadd helper more widely x86, ticketlock: Clean up types and accessors x86, ticketlock: Convert spin loop to C x86, ticketlock: Convert __ticket_spin_lock to use xadd() x86, ticketlock: Make __ticket_spin_trylock common x86, cmpxchg: Use __compiletime_error() to make usage messages a bit nicer x86, ticketlock: remove obsolete comment arch/x86/include/asm/atomic.h | 8 +- arch/x86/include/asm/atomic64_64.h | 6 +- arch/x86/include/asm/cmpxchg.h | 205 +++++++++++++++++++++++++++++++++ arch/x86/include/asm/cmpxchg_32.h | 114 ------------------ arch/x86/include/asm/cmpxchg_64.h | 131 --------------------- arch/x86/include/asm/rwsem.h | 8 +- arch/x86/include/asm/spinlock.h | 114 +++++-------------- arch/x86/include/asm/spinlock_types.h | 22 +++- arch/x86/include/asm/uv/uv_bau.h | 6 +- 9 files changed, 257 insertions(+), 357 deletions(-) Thanks, J _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel From xen-devel-bounces@lists.xensource.com Wed Sep 28 00:39:10 2011 Return-path: <xen-devel-bounces@lists.xensource.com> Envelope-to: www-data@lists.xensource.com Delivery-date: Wed, 28 Sep 2011 00:39:10 -0700 Received: from localhost ([127.0.0.1] helo=lists.colo.xensource.com) by lists.xensource.com with esmtp (Exim 4.43) id 1R8ojW-0006lJ-IE; Wed, 28 Sep 2011 00:39:10 -0700 Received: from mail174.messagelabs.com ([85.158.138.51]) by lists.xensource.com with esmtp (Exim 4.43) id 1R8oid-0006Yz-So for xen-devel@lists.xensource.com; Wed, 28 Sep 2011 00:38:17 -0700 X-Env-Sender: joseph.glanville@orionvm.com.au X-Msg-Ref: server-13.tower-174.messagelabs.com!1317195491!33049712!1 X-Originating-IP: [209.85.210.171] X-StarScan-Version: 6.4.1; banners=-,-,- X-VirusChecked: Checked Received: (qmail 5041 invoked from network); 28 Sep 2011 07:38:12 -0000 Received: from mail-iy0-f171.google.com (HELO mail-iy0-f171.google.com) (209.85.210.171) by server-13.tower-174.messagelabs.com with RC4-SHA encrypted SMTP; 28 Sep 2011 07:38:12 -0000 Received: by iagv1 with SMTP id v1so8821347iag.30 for <xen-devel@lists.xensource.com>; Wed, 28 Sep 2011 00:38:11 -0700 (PDT) MIME-Version: 1.0 Received: by 10.231.66.14 with SMTP id l14mr11703916ibi.69.1317195490967; Wed, 28 Sep 2011 00:38:10 -0700 (PDT) Received: by 10.231.170.15 with HTTP; Wed, 28 Sep 2011 00:38:10 -0700 (PDT) X-Originating-IP: [59.167.234.130] In-Reply-To: <4E82C017.1050803@goop.org> References: <4E818A50.3050607@elkdata.ee> <4E822AE3.6050601@goop.org> <4E82BDC0.7040604@elkdata.ee> <4E82C017.1050803@goop.org> Date: Wed, 28 Sep 2011 17:38:10 +1000 Message-ID: <CAOzFzEhcJDy6K=ffUi8Y=VGBmo_pSqFSR50grhgp49s=7C-OZw@mail.gmail.com> Subject: Re: [Xen-devel] Limit I/O for individual disks of VM From: Joseph Glanville <joseph.glanville@orionvm.com.au> To: Jeremy Fitzhardinge <jeremy@goop.org> Cc: xen-devel@lists.xensource.com, =?ISO-8859-1?Q?T=F5nis_Bramanis?= <tonis@elkdata.ee> X-BeenThere: xen-devel@lists.xensource.com X-Mailman-Version: 2.1.5 Precedence: list List-Id: Xen developer discussion <xen-devel.lists.xensource.com> List-Unsubscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe> List-Post: <mailto:xen-devel@lists.xensource.com> List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help> List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=subscribe> Content-Type: multipart/mixed; boundary="===============1491453499==" Sender: xen-devel-bounces@lists.xensource.com Errors-To: xen-devel-bounces@lists.xensource.com --===============1491453499== Content-Type: multipart/alternative; boundary=00151773e02856bf9804adfb7942 --00151773e02856bf9804adfb7942 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Hi, To add to the above it looks like you have a device driver or hardware issu= e with your harddrive or raid controller. I/O ratelimiting might hide the symptoms but not correct the problem. After you have addressed that you can look at implementing rate limiting via the methods described below: cgroups blk-io controller: You can find documentation etc in the linux git repo at /documentation/cgroups/blkio-controller.txt dm-ioband: Wiki is here http://sourceforge.net/apps/trac/ioband/wiki/dm-ioband Both of these are external to Xen for the reasons outlined by previous posts. Kind regards, Joseph. 2011/9/28 Jeremy Fitzhardinge <jeremy@goop.org> > On 09/27/2011 11:25 PM, T=F5nis Bramanis wrote: > > Hello > > > > and thank You for the answer. Has anyone of You tried to limit i/o on > > the VMs? > > > > I have about 40 containers and when the i/o gets too high, the host > > will crash with this error: > > [23959.739698] sd 4:0:0:0: rejecting I/O to offline device > > 5 [23959.771158] Buffer I/O error on device dm-0, logical block 4025= 9 > > > > This is not a support request! I am just referring why i would like to > > limit the disks i/o. > > I think that IO error is a real problem that you should try to solve, > rather than work around it by rate-limiting IO. > > J > > > > > Regards, > > T=F5nis Bramanis > > > > On 27.09.2011 22:58, Jeremy Fitzhardinge wrote: > >> On 09/27/2011 01:33 AM, T=F5nis Bramanis wrote: > >>> Hello! > >>> > >>> Will disk i/o limiting be added in any future versions? I see it in > >>> the 4.0 feature requests, but not in any changelogs. > >> > >> I think the hope is that we can use the generic Linux mechanisms for > >> this rather than having to add anything Xen-specific. > >> > >> J > > > > > _______________________________________________ > Xen-devel mailing list > Xen-devel@lists.xensource.com > http://lists.xensource.com/xen-devel > --=20 * Founder | Director | VP Research Orion Virtualisation Solutions* | www.orionvm.com.au | Phone: 1300 56 99 52 | Mobile: 0428 754 846 --00151773e02856bf9804adfb7942 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Hi, <br><br>To add to the above it looks like you have a device driver or h= ardware issue with your harddrive or raid controller.<br>I/O ratelimiting m= ight hide the symptoms but not correct the problem. After you have addresse= d that you can look at implementing rate limiting via the methods described= below:<br> <br>cgroups blk-io controller:<br>You can find documentation etc in the lin= ux git repo at /documentation/cgroups/blkio-controller.txt<br><br>dm-ioband= :<br>Wiki is here <a href=3D"http://sourceforge.net/apps/trac/ioband/wiki/d= m-ioband">http://sourceforge.net/apps/trac/ioband/wiki/dm-ioband</a><br> <br>Both of these are external to Xen for the reasons outlined by previous = posts.<br><br>Kind regards,<br>Joseph.<br><br><div class=3D"gmail_quote">20= 11/9/28 Jeremy Fitzhardinge <span dir=3D"ltr"><<a href=3D"mailto:jeremy@= goop.org" target=3D"_blank">jeremy@goop.org</a>></span><br> <blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1p= x #ccc solid;padding-left:1ex"> On 09/27/2011 11:25 PM, T=F5nis Bramanis wrote:<br> > Hello<br> ><br> > and thank You for the answer. Has anyone of You tried to limit i/o on<= br> > the VMs?<br> ><br> > I have about 40 containers and when the i/o gets too high, the host<br= > > will crash with this error:<br> > [23959.739698] sd 4:0:0:0: rejecting I/O to offline device<br> > 5 =A0 =A0[23959.771158] Buffer I/O error on device dm-0, logical block= 40259<br> ><br> > This is not a support request! I am just referring why i would like to= <br> > limit the disks i/o.<br> <br> I think that IO error is a real problem that you should try to solve,<br> rather than work around it by rate-limiting IO.<br> <br> =A0 =A0J<br> <br> ><br> > Regards,<br> > T=F5nis Bramanis<br> <div><div></div><div>><br> > On <a href=3D"tel:27.09.2011%2022" value=3D"+12709201122" target=3D"_b= lank">27.09.2011 22</a>:58, Jeremy Fitzhardinge wrote:<br> >> On 09/27/2011 01:33 AM, T=F5nis Bramanis wrote:<br> >>> Hello!<br> >>><br> >>> Will disk i/o limiting be added in any future versions? I see = it in<br> >>> the 4.0 feature requests, but not in any changelogs.<br> >><br> >> I think the hope is that we can use the generic Linux mechanisms f= or<br> >> this rather than having to add anything Xen-specific.<br> >><br> >> =A0 =A0 =A0J<br> ><br> <br> <br> _______________________________________________<br> Xen-devel mailing list<br> <a href=3D"mailto:Xen-devel@lists.xensource.com" target=3D"_blank">Xen-deve= l@lists.xensource.com</a><br> <a href=3D"http://lists.xensource.com/xen-devel" target=3D"_blank">http://l= ists.xensource.com/xen-devel</a><br> </div></div></blockquote></div><br><br clear=3D"all"><br>-- <br><span style= =3D"font-family:arial,sans-serif;font-size:13px;border-collapse:collapse"><= b><i><font color=3D"#0000ff"><div><font color=3D"#000000"><span style=3D"fo= nt-style:normal;font-weight:normal">Founder | Director | VP Research<br> </span></font></div>Orion Virtualisation Solutions</font></i></b>=A0|=A0<fo= nt color=3D"#0000ff"><a href=3D"http://www.orionvm.com.au/" style=3D"color:= rgb(42, 93, 176)" target=3D"_blank">www.orionvm.com.au</a></font>=A0| Phone= : 1300 56 99 52 | Mobile: 0428 754 846</span><br> --00151773e02856bf9804adfb7942-- --===============1491453499== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel --===============1491453499==-- From xen-devel-bounces@lists.xensource.com Wed Sep 28 00:42:14 2011 Return-path: <xen-devel-bounces@lists.xensource.com> Envelope-to: www-data@lists.xensource.com Delivery-date: Wed, 28 Sep 2011 00:42:14 -0700 Received: from localhost ([127.0.0.1] helo=lists.colo.xensource.com) by lists.xensource.com with esmtp (Exim 4.43) id 1R8omU-0007Bb-MI; Wed, 28 Sep 2011 00:42:14 -0700 Received: from mail27.messagelabs.com ([193.109.254.147]) by lists.xensource.com with esmtp (Exim 4.43) id 1R8olq-0006yO-QO for xen-devel@lists.xensource.com; Wed, 28 Sep 2011 00:41:35 -0700 X-Env-Sender: Ian.Campbell@eu.citrix.com X-Msg-Ref: server-11.tower-27.messagelabs.com!1317195682!39212323!1 X-Originating-IP: [62.200.22.115] X-StarScan-Version: 6.4.1; banners=-,-,- X-VirusChecked: Checked Received: (qmail 17068 invoked from network); 28 Sep 2011 07:41:22 -0000 Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115) by server-11.tower-27.messagelabs.com with RC4-SHA encrypted SMTP; 28 Sep 2011 07:41:22 -0000 X-IronPort-AV: E=Sophos;i="4.68,454,1312156800"; d="scan'208";a="8096013" Received: from lonpmailmx01.citrite.net ([10.30.203.162]) by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5; 28 Sep 2011 07:40:56 +0000 Received: from [127.0.0.1] (10.80.16.67) by smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id 8.3.137.0; Wed, 28 Sep 2011 08:40:56 +0100 Subject: Re: [Xen-devel] Xen document day (Oct 12 or 26) From: Ian Campbell <Ian.Campbell@citrix.com> To: Daniel Castro <evil.dani@gmail.com> In-Reply-To: <CAP2B85-=CbMgUGSwO2utvkeLLqk8A1vjhKrPwe2OD+0daAtqsA@mail.gmail.com> References: <20110922130618.GA13238@phenom.oracle.com> <CAFLBxZaAaXTUtW5+VkxPnr_MR0fbW+d1Mzu4y0x=gEOaX9e0OQ@mail.gmail.com> <20110922174002.GA1205@phenom.oracle.com> <20098.1097.824552.541924@mariner.uk.xensource.com> <CAP2B85-=CbMgUGSwO2utvkeLLqk8A1vjhKrPwe2OD+0daAtqsA@mail.gmail.com> Content-Type: text/plain; charset="ISO-8859-1" Organization: Citrix Systems, Inc. Date: Wed, 28 Sep 2011 08:40:56 +0100 Message-ID: <1317195656.13424.73.camel@dagon.hellion.org.uk> MIME-Version: 1.0 X-Mailer: Evolution 2.32.3 Content-Transfer-Encoding: 7bit Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>, Ian Jackson <Ian.Jackson@eu.citrix.com>, Rzeszutek Wilk <konrad.wilk@oracle.com>, Konrad X-BeenThere: xen-devel@lists.xensource.com X-Mailman-Version: 2.1.5 Precedence: list List-Id: Xen developer discussion <xen-devel.lists.xensource.com> List-Unsubscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe> List-Post: <mailto:xen-devel@lists.xensource.com> List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help> List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=subscribe> Sender: xen-devel-bounces@lists.xensource.com Errors-To: xen-devel-bounces@lists.xensource.com On Tue, 2011-09-27 at 23:18 +0100, Daniel Castro wrote: > On Wed, Sep 28, 2011 at 2:13 AM, Ian Jackson <Ian.Jackson@eu.citrix.com> wrote: > > Konrad Rzeszutek Wilk writes ("Re: [Xen-devel] Xen document day (Oct 12 or 26)"): > >> [ docs todo list ] > > ... > >> Who wants to do what? I created a sign up sheet: > >> > >> https://docs.google.com/spreadsheet/ccc?key=0Aj5ukWh4htwMdEFLVWpjRmx3VXdETDExNlByamd4Rmc&hl=en_US > >> > >> in case folks want to get an idea of who is doing what and not > >> step on each toes. > > > > Daniel, I see you have put yourself down for some things to do with > > "PDF manual". I'm not sure exactly what you mean. Do you mean the > > user manual or the internals ("interface.tex") ? > > > > I think that both of these TeX documents really need to be abolished. > > They're too hard to maintain so they have rotted; even if we were to > > fix that they wouldn't stay up to date. > > I was meaning the interface document. My current work involves > interacting with almost all parts of that document, so giving C > examples was very easy for me I think these examples would be useful but I agree with Ian that interfaces.tex is not the right place for them since we'd like to remove it in favour of something maintainable. Since the guest APIs are stable there should be relatively little churn so perhaps a wiki page (or even series of pages) would be appropriate for this sort of thing? > For example there is no official guide on how to build Xen on a new > system, and it took me several days to have a working system. I think this would be good too and in fact even more important than the interface documentation. Everyone needs to be able to build Xen to hack on it but only a subset need to know any particular API. Also although we recommend that users consume Xen via their distro where possible such a guide would also help any who would rather build from scratch (e.g. because we've asked them to "try the latest version" or to bisect a bug etc). Ian. > When > developing code, in my case most of the needed documentation came from > The Definitive Guide to Xen Hypervisor from PrenticeHall Press. But > its becoming outdated now, sadly. And in some few cases it is very > general and lack much needed detail. I do understand that Xen is huge > and making a easy guide for everything is impractical. > > Let me know how I can help, I really do want to help. > > > > > I have volunteered to do some manpage-style or markdown docs for xl. > > > > Ian. > > > > > _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel From xen-devel-bounces@lists.xensource.com Wed Sep 28 00:44:12 2011 Return-path: <xen-devel-bounces@lists.xensource.com> Envelope-to: www-data@lists.xensource.com Delivery-date: Wed, 28 Sep 2011 00:44:12 -0700 Received: from localhost ([127.0.0.1] helo=lists.colo.xensource.com) by lists.xensource.com with esmtp (Exim 4.43) id 1R8ooO-0007aX-FA; Wed, 28 Sep 2011 00:44:12 -0700 Received: from mail21.messagelabs.com ([85.158.143.35]) by lists.xensource.com with esmtp (Exim 4.43) id 1R8onh-0007O0-9X; Wed, 28 Sep 2011 00:43:29 -0700 X-Env-Sender: Ian.Campbell@eu.citrix.com X-Msg-Ref: server-5.tower-21.messagelabs.com!1317195771!49805163!1 X-Originating-IP: [62.200.22.115] X-StarScan-Version: 6.4.1; banners=-,-,- X-VirusChecked: Checked Received: (qmail 9592 invoked from network); 28 Sep 2011 07:42:51 -0000 Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115) by server-5.tower-21.messagelabs.com with RC4-SHA encrypted SMTP; 28 Sep 2011 07:42:51 -0000 X-IronPort-AV: E=Sophos;i="4.68,454,1312156800"; d="scan'208";a="8096077" Received: from lonpmailmx01.citrite.net ([10.30.203.162]) by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5; 28 Sep 2011 07:43:25 +0000 Received: from [127.0.0.1] (10.80.16.67) by smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id 8.3.137.0; Wed, 28 Sep 2011 08:43:25 +0100 Subject: Re: [Xen-devel] Please help: DomU creation problem From: Ian Campbell <Ian.Campbell@citrix.com> To: Victor Ling <victor_ling12@yahoo.com> In-Reply-To: <1317165580.71822.YahooMailNeo@web114212.mail.gq1.yahoo.com> References: <1317165580.71822.YahooMailNeo@web114212.mail.gq1.yahoo.com> Content-Type: text/plain; charset="ISO-8859-1" Organization: Citrix Systems, Inc. Date: Wed, 28 Sep 2011 08:43:25 +0100 Message-ID: <1317195805.13424.76.camel@dagon.hellion.org.uk> MIME-Version: 1.0 X-Mailer: Evolution 2.32.3 Content-Transfer-Encoding: 7bit Cc: "Xen-devel@lists.xensource.com" <Xen-devel@lists.xensource.com>, "xen-users@lists.xensource.com" <xen-users@lists.xensource.com> X-BeenThere: xen-devel@lists.xensource.com X-Mailman-Version: 2.1.5 Precedence: list List-Id: Xen developer discussion <xen-devel.lists.xensource.com> List-Unsubscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe> List-Post: <mailto:xen-devel@lists.xensource.com> List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help> List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=subscribe> Sender: xen-devel-bounces@lists.xensource.com Errors-To: xen-devel-bounces@lists.xensource.com Please do not cross post. http://wiki.xen.org/xenwiki/AskingXenDevelQuestions and http://wiki.xen.org/xenwiki/XenUsersNetiquette both ask you not to do so. On Wed, 2011-09-28 at 00:19 +0100, Victor Ling wrote: > Hi, > > > Please help: I tried to create a DomU with PCI passthrough. I don't > know hoe to proceed. You don't say what version of anything you are running. Please take a look at http://wiki.xen.org/xenwiki/ReportingBugs it gives lots of things which you should consider including in your bug reports. Does it work without the pci device in your configuration file? What sort of device are you passing through? Have you tried something simple like a basic NIC or USB controller? Are there any messages in the dom0 logs? Ian. _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel From xen-devel-bounces@lists.xensource.com Wed Sep 28 01:08:19 2011 Return-path: <xen-devel-bounces@lists.xensource.com> Envelope-to: www-data@lists.xensource.com Delivery-date: Wed, 28 Sep 2011 01:08:19 -0700 Received: from localhost ([127.0.0.1] helo=lists.colo.xensource.com) by lists.xensource.com with esmtp (Exim 4.43) id 1R8pBi-0001Rv-VR; Wed, 28 Sep 2011 01:08:19 -0700 Received: from mail21.messagelabs.com ([85.158.143.35]) by lists.xensource.com with esmtp (Exim 4.43) id 1R8pAc-00015e-U0 for xen-devel@lists.xensource.com; Wed, 28 Sep 2011 01:07:12 -0700 X-Env-Sender: royger@gmail.com X-Msg-Ref: server-6.tower-21.messagelabs.com!1317197206!39941293!1 X-Originating-IP: [209.85.213.43] X-StarScan-Version: 6.4.1; banners=-,-,- X-VirusChecked: Checked Received: (qmail 28146 invoked from network); 28 Sep 2011 08:06:47 -0000 Received: from mail-yw0-f43.google.com (HELO mail-yw0-f43.google.com) (209.85.213.43) by server-6.tower-21.messagelabs.com with RC4-SHA encrypted SMTP; 28 Sep 2011 08:06:47 -0000 Received: by ywm21 with SMTP id 21so9518892ywm.30 for <xen-devel@lists.xensource.com>; Wed, 28 Sep 2011 01:07:06 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=+TqparCiX5iBT2FvpGATiv7eNWUwX4ZdIESoHEWiAnw=; b=mkd+5nqhR6IJSbROEMJr2irZXufxCgQ5akR/YXD8d5ckITbLU8/bObZvuKm78PBZGt aPrTJwDM3/dlrEHL1XfoN3tXYCmGAwbLyjor18y9TJHvbdpK0rQal4nO9gsPsDxn9EXT qtQu8Xgbpm3tUpEfbSvMjF6IHPPiruUf0DHtE= MIME-Version: 1.0 Received: by 10.68.11.138 with SMTP id q10mr42615019pbb.37.1317197226039; Wed, 28 Sep 2011 01:07:06 -0700 (PDT) Received: by 10.142.154.18 with HTTP; Wed, 28 Sep 2011 01:07:05 -0700 (PDT) In-Reply-To: <20098.362.319162.127153@mariner.uk.xensource.com> References: <patchbomb.1316187417@loki> <aff3960421768180410c.1316187419@loki> <20098.362.319162.127153@mariner.uk.xensource.com> Date: Wed, 28 Sep 2011 10:07:05 +0200 X-Google-Sender-Auth: evsyZeJHQLXh7sSliAVfC7gs3V0 Message-ID: <CAPLaKK7m_3=qV0NCvjY2vrJbRJvWhhhLJR5e0P3P+2tgQnjFcg@mail.gmail.com> Subject: Re: [Xen-devel] [PATCH 2 of 2] libxl: add support for booting PV domains from NetBSD using raw files as disks From: =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= <roger.pau@entel.upc.edu> To: Ian Jackson <Ian.Jackson@eu.citrix.com> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Cc: xen-devel@lists.xensource.com X-BeenThere: xen-devel@lists.xensource.com X-Mailman-Version: 2.1.5 Precedence: list List-Id: Xen developer discussion <xen-devel.lists.xensource.com> List-Unsubscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe> List-Post: <mailto:xen-devel@lists.xensource.com> List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help> List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=subscribe> Sender: xen-devel-bounces@lists.xensource.com Errors-To: xen-devel-bounces@lists.xensource.com 2011/9/27 Ian Jackson <Ian.Jackson@eu.citrix.com>: > Roger Pau Monne writes ("[Xen-devel] [PATCH 2 of 2] libxl: add support fo= r booting PV domains from NetBSD using raw files as disks"): >> libxl: add support for booting PV domains from NetBSD using raw files as= disks. > > Thanks, I have some comments: This is an old version of the patch, I've split this change across several patches, that are on the list also, and include more exact descriptions of every change. > >> + =C2=A0 =C2=A0 =C2=A0 =C2=A0if (S_ISBLK(a->stab.st_mode)) >> + =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0return backend; >> +#ifdef HAVE_PHY_BACKEND_FILE_SUPPORT >> + =C2=A0 =C2=A0 =C2=A0 =C2=A0if (S_ISREG(a->stab.st_mode)) >> + =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0return backend; > > I think we would prefer not to have #ifdefs in the code. =C2=A0That can > make the logic quite hard to follow. =C2=A0Instead, invent a helper > function which answers the "does the phy backend support files" which > is provided in two versions, from osdep.c. Ok, I don't like ifdefs also. > >> @@ -366,14 +371,26 @@ int libxl__device_destroy(libxl__gc *gc, >> =C2=A0 =C2=A0 =C2=A0libxl_ctx *ctx =3D libxl__gc_owner(gc); >> =C2=A0 =C2=A0 =C2=A0xs_transaction_t t; >> =C2=A0 =C2=A0 =C2=A0char *state_path =3D libxl__sprintf(gc, "%s/state", = be_path); >> + =C2=A0 =C2=A0char *hotplug_path =3D libxl__sprintf(gc, "%s/hotplug-sta= tus", be_path); > > We want to get away from the hotplug scripts for disks at least on > Linux with libxl. =C2=A0Rather, any scripts that are needed should be run > from libxl directly. > > How does that fit with NetBSD's disk backend approach ? > What goes wrong on NetBSD without this additional code ? NetBSD still uses the "loop" ("vnd" on NetBSD) device for files, because it doesn't have support for qdisk or blktap. If we don't check the hotplug-status before removing the vbd from xenstore (and only look at state) it might be removed before the hotplug scripts are executed, and the disk is never unmounted. This is why we need to check the hotplug-status before removing vbd from xenstore. Of course, I could call the hotplug scripts from libxl directly (for disk and inet interfaces), and we could get rid of xenbackendd. > >> @@ -482,7 +519,7 @@ int libxl__devices_destroy(libxl__gc *gc >> =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0tv.tv_usec =3D 0; >> =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0while (n_watches > 0) { >> =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0if (wait_for_dev_destroy= (gc, &tv)) { >> - =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0break; >> + =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0continue; >> =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0} else { >> =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0n_watches-= -; >> =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0} > > I'm not sure I understand this change, or why it's needed. This change is more explained in the series, basically libxl was not waiting for all devices to disconnect, because when it returned from wait_for_dev_destroy exited the loop immediately, even if we where watching for more than one device to disconnect. > > Ian. > > _______________________________________________ > Xen-devel mailing list > Xen-devel@lists.xensource.com > http://lists.xensource.com/xen-devel > _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel From xen-devel-bounces@lists.xensource.com Wed Sep 28 01:12:27 2011 Return-path: <xen-devel-bounces@lists.xensource.com> Envelope-to: www-data@lists.xensource.com Delivery-date: Wed, 28 Sep 2011 01:12:27 -0700 Received: from localhost ([127.0.0.1] helo=lists.colo.xensource.com) by lists.xensource.com with esmtp (Exim 4.43) id 1R8pFj-0001rl-M6; Wed, 28 Sep 2011 01:12:27 -0700 Received: from mail182.messagelabs.com ([85.158.139.83]) by lists.xensource.com with esmtp (Exim 4.43) id 1R8pFG-0001fR-Qh for xen-devel@lists.xensource.com; Wed, 28 Sep 2011 01:11:59 -0700 X-Env-Sender: vase@selfip.ru X-Msg-Ref: server-10.tower-182.messagelabs.com!1317197515!20012563!1 X-Originating-IP: [74.125.82.171] X-StarScan-Version: 6.4.1; banners=-,-,- X-VirusChecked: Checked Received: (qmail 12514 invoked from network); 28 Sep 2011 08:11:55 -0000 Received: from mail-wy0-f171.google.com (HELO mail-wy0-f171.google.com) (74.125.82.171) by server-10.tower-182.messagelabs.com with RC4-SHA encrypted SMTP; 28 Sep 2011 08:11:55 -0000 Received: by wyh13 with SMTP id 13so7907492wyh.30 for <xen-devel@lists.xensource.com>; Wed, 28 Sep 2011 01:11:55 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=selfip.ru; s=google; h=mime-version:sender:x-originating-ip:date:x-google-sender-auth :message-id:subject:from:to:content-type; bh=osUjq0ZZoHRiyr87VNDIZS2T6aOD/3JuBZ2g8Udef3k=; b=KArrW46+WgONZBY36Nce8a5xF7TCtFhrNHBdylyfYtwRULesRGA5bRy20ckyBkjr+O PZchAvtZpmwh5XZ8mxi50vWz6Qut855LW8Z4FuWjoAbHxQsOddyhE3ADwpH2O6xI3urx UtmxKDSw5hjPqX4dNpGzDjJhFu+gDoC9jzI5Q= MIME-Version: 1.0 Received: by 10.216.221.42 with SMTP id q42mr10470571wep.16.1317197515433; Wed, 28 Sep 2011 01:11:55 -0700 (PDT) Received: by 10.216.4.69 with HTTP; Wed, 28 Sep 2011 01:11:55 -0700 (PDT) X-Originating-IP: [85.143.161.18] Date: Wed, 28 Sep 2011 12:11:55 +0400 X-Google-Sender-Auth: lHWU8MCuib2NDQ-CmAgZdv-qFao Message-ID: <CACaajQuWMrZhz51p2x9frQ-PyS8P8tbbbQAsJq6hyc4qp=fomg@mail.gmail.com> From: Vasiliy Tolstov <v.tolstov@selfip.ru> To: xen-devel@lists.xensource.com Subject: [Xen-devel] dom0 kernel X-BeenThere: xen-devel@lists.xensource.com X-Mailman-Version: 2.1.5 Precedence: list List-Id: Xen developer discussion <xen-devel.lists.xensource.com> List-Unsubscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe> List-Post: <mailto:xen-devel@lists.xensource.com> List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help> List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=subscribe> Content-Type: multipart/mixed; boundary="===============0791192803==" Sender: xen-devel-bounces@lists.xensource.com Errors-To: xen-devel-bounces@lists.xensource.com --===============0791192803== Content-Type: multipart/alternative; boundary=001485f6d9b201a8c404adfbf284 --001485f6d9b201a8c404adfbf284 Content-Type: text/plain; charset=UTF-8 Hello. What kernel version is the best to use for dom0 under debian? Now i see, that kernel 2.6.32-5-xen-amd64 panic under heavy network load. What is the best - get kernel from official debian packages (may be in sid...) or compile from git and use? If i need 2.6.x kernel (becouse some packages not ready to run under 3.x) where i can find current stable xen git tree? Thanks. -- Vasiliy Tolstov, Clodo.ru e-mail: v.tolstov@selfip.ru jabber: vase@selfip.ru --001485f6d9b201a8c404adfbf284 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Hello. What kernel version is the best to use for dom0 under debian?<div>No= w i see, that kernel 2.6.32-5-xen-amd64 panic under heavy network load.</di= v><div>What is the best - get kernel from official debian packages (may be = in sid...) or compile from git and use?</div> <div>If i need 2.6.x kernel (becouse some packages not ready to run under 3= .x) where i can find current stable xen git tree?</div><div>Thanks.<br clea= r=3D"all"><div><br></div>-- <br><span style=3D"border-collapse:collapse;col= or:rgb(136, 136, 136);font-family:arial, sans-serif;font-size:13px"><div> <div>Vasiliy Tolstov,</div><div>Clodo.ru</div><div>e-mail: <a href=3D"mailt= o:v.tolstov@selfip.ru" target=3D"_blank">v.tolstov@selfip.ru</a></div><div>= jabber: <a href=3D"mailto:vase@selfip.ru" target=3D"_blank">vase@selfip.ru<= /a></div> </div></span><br> </div> --001485f6d9b201a8c404adfbf284-- --===============0791192803== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel --===============0791192803==-- From xen-devel-bounces@lists.xensource.com Wed Sep 28 01:14:27 2011 Return-path: <xen-devel-bounces@lists.xensource.com> Envelope-to: www-data@lists.xensource.com Delivery-date: Wed, 28 Sep 2011 01:14:27 -0700 Received: from localhost ([127.0.0.1] helo=lists.colo.xensource.com) by lists.xensource.com with esmtp (Exim 4.43) id 1R8pHf-0002Fd-17; Wed, 28 Sep 2011 01:14:27 -0700 Received: from mail182.messagelabs.com ([85.158.139.83]) by lists.xensource.com with esmtp (Exim 4.43) id 1R8pHG-00023P-N2 for xen-devel@lists.xensource.com; Wed, 28 Sep 2011 01:14:03 -0700 X-Env-Sender: Ian.Campbell@eu.citrix.com X-Msg-Ref: server-2.tower-182.messagelabs.com!1317197639!19025711!1 X-Originating-IP: [62.200.22.115] X-StarScan-Version: 6.4.1; banners=-,-,- X-VirusChecked: Checked Received: (qmail 6068 invoked from network); 28 Sep 2011 08:13:59 -0000 Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115) by server-2.tower-182.messagelabs.com with RC4-SHA encrypted SMTP; 28 Sep 2011 08:13:59 -0000 X-IronPort-AV: E=Sophos;i="4.68,454,1312156800"; d="scan'208";a="8096820" Received: from lonpmailmx01.citrite.net ([10.30.203.162]) by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5; 28 Sep 2011 08:13:59 +0000 Received: from [127.0.0.1] (10.80.16.67) by smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id 8.3.137.0; Wed, 28 Sep 2011 09:13:59 +0100 Subject: Re: [Xen-devel] [PATCH 2 of 2] libxl: add support for booting PV domains from NetBSD using raw files as disks From: Ian Campbell <Ian.Campbell@citrix.com> To: Ian Jackson <Ian.Jackson@eu.citrix.com> In-Reply-To: <20098.362.319162.127153@mariner.uk.xensource.com> References: <patchbomb.1316187417@loki> <aff3960421768180410c.1316187419@loki> <20098.362.319162.127153@mariner.uk.xensource.com> Content-Type: text/plain; charset="ISO-8859-1" Organization: Citrix Systems, Inc. Date: Wed, 28 Sep 2011 09:13:58 +0100 Message-ID: <1317197638.13424.104.camel@dagon.hellion.org.uk> MIME-Version: 1.0 X-Mailer: Evolution 2.32.3 Content-Transfer-Encoding: 7bit Cc: Roger Pau Monne <roger.pau@entel.upc.edu>, "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com> X-BeenThere: xen-devel@lists.xensource.com X-Mailman-Version: 2.1.5 Precedence: list List-Id: Xen developer discussion <xen-devel.lists.xensource.com> List-Unsubscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe> List-Post: <mailto:xen-devel@lists.xensource.com> List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help> List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=subscribe> Sender: xen-devel-bounces@lists.xensource.com Errors-To: xen-devel-bounces@lists.xensource.com On Tue, 2011-09-27 at 18:01 +0100, Ian Jackson wrote: > Roger Pau Monne writes ("[Xen-devel] [PATCH 2 of 2] libxl: add support for booting PV domains from NetBSD using raw files as disks"): > > libxl: add support for booting PV domains from NetBSD using raw files as disks. > > Thanks, I have some comments: > > > + if (S_ISBLK(a->stab.st_mode)) > > + return backend; > > +#ifdef HAVE_PHY_BACKEND_FILE_SUPPORT > > + if (S_ISREG(a->stab.st_mode)) > > + return backend; > > I think we would prefer not to have #ifdefs in the code. That can > make the logic quite hard to follow. Instead, invent a helper > function which answers the "does the phy backend support files" which > is provided in two versions, from osdep.c. This was my suggestion but you are right that a helper function is a much better idea. > > @@ -366,14 +371,26 @@ int libxl__device_destroy(libxl__gc *gc, > > libxl_ctx *ctx = libxl__gc_owner(gc); > > xs_transaction_t t; > > char *state_path = libxl__sprintf(gc, "%s/state", be_path); > > + char *hotplug_path = libxl__sprintf(gc, "%s/hotplug-status", be_path); > > We want to get away from the hotplug scripts for disks at least on > Linux with libxl. Rather, any scripts that are needed should be run > from libxl directly. xenbackendd is the component in NetBSD which runs the "hotplug" scripts, triggered off the xenstore state node transitions. (I presume the NetBSD kernel driver doesn't generate hotplug events) AIUI the issue is the synchronisation between the kernel device, libxl and NetBSD's xenbackendd. Effectively libxl and xenbackendd are racing on the teardown (both are watching the state node in xenstore). If xenbackendd loses then it cannot do its cleanup because libxl has already nuked the necessary info from xenstore. The fix which Roger has made is to have only xenbackendd watch "state" and set "hotplug-status=disconnected" and libxl to watch "hotplug-status". On Linux the equivalent is to have the hotplug script write the "hotplug-status=disconnected". I think strictly speaking the Linux hotplug scripts have a similar race but it just happens that there is no actual work on the teardown path so the race is benign. > How does that fit with NetBSD's disk backend approach ? I expect that if we get rid of hotplug scripts on Linux that this will be equivalent to removing xenbackendd on NetBSD, the same approximate scheme should work for both, I think. I think you've explained the scheme you have in mind for deprecating hotplug scripts before but could you remind me (and for the lists benefit)? Is it simply a case of shelling out to the vbd's configured "script=" at the right points on attach and detach? Would we then need special handling to turn "file:<X>" into "phy:<X>,script=block-loop"? I seem to remember something about setting up a faked out backend area for each backend and running the scripts against that instead of the real one. > What goes wrong on NetBSD without this additional code ? NetBSD doesn't have the option of falling back to blktap for file:// type disk devices so these simply don't work at the moment. This is a pretty serious blocker for NetBSD moving to xl. There was a subtle difference between NetBSD's and Linux's handling of these with xend. On Linux xend used to setup and manage the loopback device and create a simple phy backend referencing it. On NetBSD xend just sets up a file or phy backend as appropriate and the scripts which run out of xenbackendd take care of setting up the loopback as necessary and filing in the real device in xenstore. On teardown the loopback device needs to be cleaned up (and this is what currently fails). For libxl on Linux we decided to avoid managing loopback devices in libxl and instead just used blktap to meet that need but as I say this isn't an option on BSD. Roger has indicated that he is working on blktap-in-userspace functionality, which would solve this problem longer term, so I think we just need a stopgap measure to allow NetBSD users to switch to xl in the meantime. How much work do you expect deprecating the hotplug scripts to be, is it (or at least the subset necessary to solve this issue) something which can be achieved in the short term? > > @@ -482,7 +519,7 @@ int libxl__devices_destroy(libxl__gc *gc > > tv.tv_usec = 0; > > while (n_watches > 0) { > > if (wait_for_dev_destroy(gc, &tv)) { > > - break; > > + continue; > > } else { > > n_watches--; > > } > > I'm not sure I understand this change, or why it's needed. This was an unrelated fixup. Roger subsequently posted it again as a separate change. (as he did this whole series with clearer separation of different fixes) Ian. > > Ian. > > _______________________________________________ > Xen-devel mailing list > Xen-devel@lists.xensource.com > http://lists.xensource.com/xen-devel _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel From xen-devel-bounces@lists.xensource.com Wed Sep 28 01:21:48 2011 Return-path: <xen-devel-bounces@lists.xensource.com> Envelope-to: www-data@lists.xensource.com Delivery-date: Wed, 28 Sep 2011 01:21:48 -0700 Received: from localhost ([127.0.0.1] helo=lists.colo.xensource.com) by lists.xensource.com with esmtp (Exim 4.43) id 1R8pOm-0002jD-BS; Wed, 28 Sep 2011 01:21:48 -0700 Received: from mail182.messagelabs.com ([85.158.139.83]) by lists.xensource.com with esmtp (Exim 4.43) id 1R8pOO-0002XX-8Z for xen-devel@lists.xensource.com; Wed, 28 Sep 2011 01:21:24 -0700 X-Env-Sender: Ian.Campbell@eu.citrix.com X-Msg-Ref: server-10.tower-182.messagelabs.com!1317198080!20013999!1 X-Originating-IP: [62.200.22.115] X-StarScan-Version: 6.4.1; banners=-,-,- X-VirusChecked: Checked Received: (qmail 8319 invoked from network); 28 Sep 2011 08:21:21 -0000 Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115) by server-10.tower-182.messagelabs.com with RC4-SHA encrypted SMTP; 28 Sep 2011 08:21:21 -0000 X-IronPort-AV: E=Sophos;i="4.68,454,1312156800"; d="scan'208";a="8097008" Received: from lonpmailmx01.citrite.net ([10.30.203.162]) by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5; 28 Sep 2011 08:21:06 +0000 Received: from [127.0.0.1] (10.80.16.67) by smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id 8.3.137.0; Wed, 28 Sep 2011 09:21:06 +0100 Subject: Re: [Xen-devel] dom0 kernel From: Ian Campbell <Ian.Campbell@citrix.com> To: Vasiliy Tolstov <v.tolstov@selfip.ru> In-Reply-To: <CACaajQuWMrZhz51p2x9frQ-PyS8P8tbbbQAsJq6hyc4qp=fomg@mail.gmail.com> References: <CACaajQuWMrZhz51p2x9frQ-PyS8P8tbbbQAsJq6hyc4qp=fomg@mail.gmail.com> Content-Type: text/plain; charset="ISO-8859-1" Organization: Citrix Systems, Inc. Date: Wed, 28 Sep 2011 09:21:05 +0100 Message-ID: <1317198065.13424.109.camel@dagon.hellion.org.uk> MIME-Version: 1.0 X-Mailer: Evolution 2.32.3 Content-Transfer-Encoding: 7bit Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com> X-BeenThere: xen-devel@lists.xensource.com X-Mailman-Version: 2.1.5 Precedence: list List-Id: Xen developer discussion <xen-devel.lists.xensource.com> List-Unsubscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe> List-Post: <mailto:xen-devel@lists.xensource.com> List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help> List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=subscribe> Sender: xen-devel-bounces@lists.xensource.com Errors-To: xen-devel-bounces@lists.xensource.com On Wed, 2011-09-28 at 09:11 +0100, Vasiliy Tolstov wrote: > Hello. What kernel version is the best to use for dom0 under debian? > Now i see, that kernel 2.6.32-5-xen-amd64 panic under heavy network > load. Can you give us a pointer to your Debian bug report on this issue please. > What is the best - get kernel from official debian packages (may be in > sid...) or compile from git and use? Sid currently has 3.0 packages in it and experimental has 3.1-rc$late. If you want a more recent 2.6.32.x then git is the only real option. > If i need 2.6.x kernel (becouse some packages not ready to run under > 3.x) where i can find current stable xen git tree? Jeremy's tree is https://github.com/jsgf/linux-xen while kernel.org is down. Konrad's temporary tree is git://oss.oracle.com/git/kwilk/xen.git. Ian. _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel From xen-devel-bounces@lists.xensource.com Wed Sep 28 01:27:11 2011 Return-path: <xen-devel-bounces@lists.xensource.com> Envelope-to: www-data@lists.xensource.com Delivery-date: Wed, 28 Sep 2011 01:27:11 -0700 Received: from localhost ([127.0.0.1] helo=lists.colo.xensource.com) by lists.xensource.com with esmtp (Exim 4.43) id 1R8pTz-0003AX-67; Wed, 28 Sep 2011 01:27:11 -0700 Received: from mail27.messagelabs.com ([193.109.254.147]) by lists.xensource.com with esmtp (Exim 4.43) id 1R8pT2-0002xy-RG for xen-devel@lists.xensource.com; Wed, 28 Sep 2011 01:26:13 -0700 X-Env-Sender: mingo@elte.hu X-Msg-Ref: server-8.tower-27.messagelabs.com!1317198352!48397234!1 X-Originating-IP: [157.181.151.13] X-StarScan-Version: 6.4.1; banners=-,-,- X-VirusChecked: Checked Received: (qmail 16652 invoked from network); 28 Sep 2011 08:25:52 -0000 Received: from fallback.mail.elte.hu (HELO fallback.mail.elte.hu) (157.181.151.13) by server-8.tower-27.messagelabs.com with AES256-SHA encrypted SMTP; 28 Sep 2011 08:25:52 -0000 Received: from mx3.mail.elte.hu ([157.181.1.138]) by fallback.mail.elte.hu with esmtp (Exim) id 1R8pSs-0001dQ-Mv from <mingo@elte.hu>; Wed, 28 Sep 2011 10:26:02 +0200 Received: from elvis.elte.hu ([157.181.1.14]) by mx3.mail.elte.hu with esmtp (Exim) id 1R8pSl-0005gd-Rj from <mingo@elte.hu>; Wed, 28 Sep 2011 10:26:02 +0200 Received: by elvis.elte.hu (Postfix, from userid 1004) id CCD2B3E2591; Wed, 28 Sep 2011 10:25:45 +0200 (CEST) Date: Wed, 28 Sep 2011 10:24:30 +0200 From: Ingo Molnar <mingo@elte.hu> To: Jeremy Fitzhardinge <jeremy@goop.org> Message-ID: <20110928082430.GA29264@elte.hu> References: <alpine.LFD.2.02.1109280209430.2711@ionos> <20110928063115.GA24510@elte.hu> <4E82C169.8060803@goop.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <4E82C169.8060803@goop.org> User-Agent: Mutt/1.5.21 (2010-09-15) Received-SPF: neutral (mx3: 157.181.1.14 is neither permitted nor denied by domain of elte.hu) client-ip=157.181.1.14; envelope-from=mingo@elte.hu; helo=elvis.elte.hu; X-ELTE-SpamScore: -1.9 X-ELTE-SpamLevel: X-ELTE-SpamCheck: no X-ELTE-SpamVersion: ELTE 2.0 X-ELTE-SpamCheck-Details: score=-1.9 required=5.9 tests=AWL, BAYES_00 autolearn=no SpamAssassin version=3.3.1 -2.0 BAYES_00 BODY: Bayes spam probability is 0 to 1% [score: 0.0000] 0.1 AWL AWL: From: address is in the auto white-list Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>, the arch/x86 maintainers <x86@kernel.org>, Linux Kernel Mailing List <linux-kernel@vger.kernel.org>, "H. Peter Anvin" <hpa@zytor.com> Subject: [Xen-devel] Re: Could you reinstate ticketlock cleanups in tip.git X-BeenThere: xen-devel@lists.xensource.com X-Mailman-Version: 2.1.5 Precedence: list List-Id: Xen developer discussion <xen-devel.lists.xensource.com> List-Unsubscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe> List-Post: <mailto:xen-devel@lists.xensource.com> List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help> List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=subscribe> Sender: xen-devel-bounces@lists.xensource.com Errors-To: xen-devel-bounces@lists.xensource.com * Jeremy Fitzhardinge <jeremy@goop.org> wrote: > On 09/27/2011 11:31 PM, Ingo Molnar wrote: > > * Thomas Gleixner <tglx@linutronix.de> wrote: > > > >> Hi Thomas, > >> > >> Could you reinstate the ticketlock cleanup series in tip.git (I think it > >> was in x86/spinlocks) from > >> git://github.com/jsgf/linux-xen.git upstream/ticketlock-cleanup > >> > >> This branch is the final result of all the discussions and revisions and > >> is ready for the next merge window. It's the one that's been in > >> linux-next for a couple of weeks (at least), and won't cause any > >> conflicts there. > >> > >> Or if you prefer I can submit it myself for next merge window. > >> > >> Thanks, > >> J > > I'd prefer if this went via x86/spinlocks. Could you please send a > > proper pull request with diffstat, shortlog, etc? > > > > Sure, here you are: > > The following changes since commit c6a389f123b9f68d605bb7e0f9b32ec1e3e14132: > > Linux 3.1-rc4 (2011-08-28 21:16:01 -0700) > > are available in the git repository at: > git://github.com/jsgf/linux-xen upstream/ticketlock-cleanup > (commit 4a7f340c6a75ec5fca23d9c80a59f3f28cc4a61e) > > Jeremy Fitzhardinge (12): > x86, cmpxchg: <linux/alternative.h> has LOCK_PREFIX > x86, cmpxchg: Move 32-bit __cmpxchg_wrong_size to match 64 bit. > x86, cmpxchg: Move 64-bit set64_bit() to match 32-bit > x86, cmpxchg: Unify cmpxchg into cmpxchg.h > x86: Add xadd helper macro > x86: Use xadd helper more widely > x86, ticketlock: Clean up types and accessors > x86, ticketlock: Convert spin loop to C > x86, ticketlock: Convert __ticket_spin_lock to use xadd() > x86, ticketlock: Make __ticket_spin_trylock common > x86, cmpxchg: Use __compiletime_error() to make usage messages a bit nicer > x86, ticketlock: remove obsolete comment > > arch/x86/include/asm/atomic.h | 8 +- > arch/x86/include/asm/atomic64_64.h | 6 +- > arch/x86/include/asm/cmpxchg.h | 205 +++++++++++++++++++++++++++++++++ > arch/x86/include/asm/cmpxchg_32.h | 114 ------------------ > arch/x86/include/asm/cmpxchg_64.h | 131 --------------------- > arch/x86/include/asm/rwsem.h | 8 +- > arch/x86/include/asm/spinlock.h | 114 +++++-------------- > arch/x86/include/asm/spinlock_types.h | 22 +++- > arch/x86/include/asm/uv/uv_bau.h | 6 +- > 9 files changed, 257 insertions(+), 357 deletions(-) Pulled, thanks Jeremy! Ingo _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel From xen-devel-bounces@lists.xensource.com Wed Sep 28 01:34:07 2011 Return-path: <xen-devel-bounces@lists.xensource.com> Envelope-to: www-data@lists.xensource.com Delivery-date: Wed, 28 Sep 2011 01:34:07 -0700 Received: from localhost ([127.0.0.1] helo=lists.colo.xensource.com) by lists.xensource.com with esmtp (Exim 4.43) id 1R8paf-0003js-Tp; Wed, 28 Sep 2011 01:34:06 -0700 Received: from mail27.messagelabs.com ([193.109.254.147]) by lists.xensource.com with esmtp (Exim 4.43) id 1R8pa2-0003XX-Bi for xen-devel@lists.xensource.com; Wed, 28 Sep 2011 01:33:26 -0700 X-Env-Sender: JBeulich@suse.com X-Msg-Ref: server-15.tower-27.messagelabs.com!1317198794!50572840!1 X-Originating-IP: [130.57.49.28] X-StarScan-Version: 6.4.1; banners=-,-,- X-VirusChecked: Checked Received: (qmail 26573 invoked from network); 28 Sep 2011 08:33:14 -0000 Received: from nat28.tlf.novell.com (HELO nat28.tlf.novell.com) (130.57.49.28) by server-15.tower-27.messagelabs.com with DHE-RSA-AES256-SHA encrypted SMTP; 28 Sep 2011 08:33:14 -0000 Received: from EMEA1-MTA by nat28.tlf.novell.com with Novell_GroupWise; Wed, 28 Sep 2011 09:33:22 +0100 Message-Id: <4E82F7F10200007800058259@nat28.tlf.novell.com> X-Mailer: Novell GroupWise Internet Agent 8.0.1 Date: Wed, 28 Sep 2011 09:33:21 +0100 From: "Jan Beulich" <JBeulich@suse.com> To: "Jeremy Fitzhardinge" <jeremy@goop.org> References: <4E822AA6.4010605@goop.org> In-Reply-To: <4E822AA6.4010605@goop.org> Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: quoted-printable Content-Disposition: inline Cc: George Dunlap <George.Dunlap@eu.citrix.com>, andrew.cooper3@citrix.com, "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>, Konrad Rzeszutek Wilk <konrad.wilk@oracle.com> Subject: [Xen-devel] Re: MSI error when reloading iwlagn module X-BeenThere: xen-devel@lists.xensource.com X-Mailman-Version: 2.1.5 Precedence: list List-Id: Xen developer discussion <xen-devel.lists.xensource.com> List-Unsubscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe> List-Post: <mailto:xen-devel@lists.xensource.com> List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help> List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=subscribe> Sender: xen-devel-bounces@lists.xensource.com Errors-To: xen-devel-bounces@lists.xensource.com >>> On 27.09.11 at 21:57, Jeremy Fitzhardinge <jeremy@goop.org> wrote: > Hi, >=20 > With a fairly current kernel + xen, I'm seeing this if I rmmod iwlagn > and try to reload it: >=20 > [51230.646678] Intel(R) Wireless WiFi Link AGN driver for Linux, = in-tree: > [51230.646685] Copyright(c) 2003-2011 Intel Corporation > [51230.646760] xen: registering gsi 17 triggering 0 polarity 1 > [51230.646773] xen_map_pirq_gsi: returning irq 17 for gsi 17 > [51230.646777] xen: --> pirq=3D17 -> irq=3D17 (gsi=3D17) > [51230.646781] Already setup the GSI :17 > [51230.646789] iwlagn 0000:03:00.0: PCI INT A -> GSI 17 (level, low) -> = IRQ 17 > [51230.646814] iwlagn 0000:03:00.0: setting latency timer to 64 > [51230.646935] iwlagn 0000:03:00.0: pci_resource_len =3D 0x00002000 > [51230.646941] iwlagn 0000:03:00.0: pci_resource_base =3D ffffc9000671c00= 0 > [51230.646945] iwlagn 0000:03:00.0: HW Revision ID =3D 0x35 > [51230.647075] iwlagn 0000:03:00.0: xen map irq failed -22 for 32752 = domain > [51230.647081] iwlagn 0000:03:00.0: pci_enable_msi failed > [51230.647113] iwlagn 0000:03:00.0: PCI INT A disabled > [51230.647126] iwlagn: probe of 0000:03:00.0 failed with error -22 >=20 > with this on the Xen console >=20 > (XEN) physdev.c:139: dom0: can't create irq for msi! >=20 >=20 > I'm running Xen as of a422e2a4451e, which your MSI changes in them, > which I suspect of having caused a regression (since I don't remember > having problems reloading msi-using drivers before). Are you certain (i.e. did you try reverting the top 1 to 3 commits from there)? Alternatively, do you know what c/s last worked for you? Is this one the first removal, or after several of them? The message solely indicates a failure of create_irq(), with either find_unassigned_irq() or __assign_irq_vector() failing being the cause, none of which I touched recently. Instead I wonder whether 23812:32814ad7458d wouldn't be a more likely candidate (with 23815:9fa77d26a813 and 23816:7f357e1ef60a being less likely ones). I'll nevertheless see whether this reproduces with one of the MSI drivers that my machines have in use and allow easy removal/reload. Jan _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel From xen-devel-bounces@lists.xensource.com Wed Sep 28 02:11:04 2011 Return-path: <xen-devel-bounces@lists.xensource.com> Envelope-to: www-data@lists.xensource.com Delivery-date: Wed, 28 Sep 2011 02:11:04 -0700 Received: from localhost ([127.0.0.1] helo=lists.colo.xensource.com) by lists.xensource.com with esmtp (Exim 4.43) id 1R8qAR-0005Xm-Ss; Wed, 28 Sep 2011 02:11:03 -0700 Received: from mail27.messagelabs.com ([193.109.254.147]) by lists.xensource.com with smtp (Exim 4.43) id 1R8q8n-0005KV-MI for xen-devel@lists.xensource.com; Wed, 28 Sep 2011 02:09:27 -0700 X-Env-Sender: anthony@overnetdata.com X-Msg-Ref: server-14.tower-27.messagelabs.com!1317200940!37950144!1 X-Originating-IP: [81.137.131.225] X-StarScan-Version: 6.4.1; banners=-,-,- X-VirusChecked: Checked Received: (qmail 12209 invoked from network); 28 Sep 2011 09:09:00 -0000 Received: from host81-137-131-225.in-addr.btopenworld.com (HELO zimbra.overnetdata.com) (81.137.131.225) by server-14.tower-27.messagelabs.com with SMTP; 28 Sep 2011 09:09:00 -0000 Received: from localhost (localhost.localdomain [127.0.0.1]) by zimbra.overnetdata.com (Postfix) with ESMTP id 1663D161563; Wed, 28 Sep 2011 10:09:15 +0100 (BST) X-Virus-Scanned: amavisd-new at overnetdata.com Received: from zimbra.overnetdata.com ([127.0.0.1]) by localhost (zimbra.overnetdata.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id m8rO9VJ3OPCA; Wed, 28 Sep 2011 10:09:01 +0100 (BST) Received: from [192.168.1.60] (unknown [192.168.1.60]) by zimbra.overnetdata.com (Postfix) with ESMTPSA id E963C1617A8; Wed, 28 Sep 2011 10:09:00 +0100 (BST) Message-ID: <4E82E429.2080600@overnetdata.com> Date: Wed, 28 Sep 2011 10:08:57 +0100 From: Anthony Wright <anthony@overnetdata.com> User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:6.0.2) Gecko/20110902 Thunderbird/6.0.2 MIME-Version: 1.0 To: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com> Subject: Re: [Xen-devel] dmidecode doesn't work under xen 4.1.1 on certain hardware References: <4E7C6BDC.8070005@overnetdata.com> <20110923133200.GC19579@phenom.oracle.com> <4E7C9C8B.2010108@overnetdata.com> <20110926141322.GD4102@phenom.oracle.com> <4E8090D4.2090009@overnetdata.com> <20110926193732.GA10007@phenom.oracle.com> In-Reply-To: <20110926193732.GA10007@phenom.oracle.com> X-Enigmail-Version: 1.3.2 Content-Type: multipart/mixed; boundary="------------020502010604060608070304" Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com> X-BeenThere: xen-devel@lists.xensource.com X-Mailman-Version: 2.1.5 Precedence: list List-Id: Xen developer discussion <xen-devel.lists.xensource.com> List-Unsubscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe> List-Post: <mailto:xen-devel@lists.xensource.com> List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help> List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=subscribe> Sender: xen-devel-bounces@lists.xensource.com Errors-To: xen-devel-bounces@lists.xensource.com This is a multi-part message in MIME format. --------------020502010604060608070304 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit On 26/09/2011 20:37, Konrad Rzeszutek Wilk wrote: >> __ __ _ _ _ _ >> \ \/ /___ _ __ | || | / | / | >> \ // _ \ '_ \ | || |_ | | | | >> / \ __/ | | | |__ _|| |_| | >> /_/\_\___|_| |_| |_|(_)_(_)_| >> >> (XEN) Xen version 4.1.1 (@[unknown]) (gcc version 4.4.3 (GCC) ) Wed Sep 21 08:25:36 GMT 2011 >> (XEN) Latest ChangeSet: unavailable >> (XEN) Bootloader: GNU GRUB 0.97 >> (XEN) Command line: >> (XEN) Video information: >> (XEN) VGA is text mode 80x25, font 8x16 >> (XEN) VBE/DDC methods: V2; EDID transfer time: 1 seconds >> (XEN) Disc information: >> (XEN) Found 4 MBR signatures >> (XEN) Found 4 EDD information structures >> (XEN) WARNING: Only the first 16 GB of the physical memory map can be accessed by Xen in 32-bit mode. > That bites ^^^^ >> (XEN) Truncating RAM from 17825792kB to 16777216kB Does this mean that 32 bit Xen can only use a maximum of 16GB of RAM? If so, is there a way to use 32 bit Xen tools with a 64 bit Xen hypervisor? >> (XEN) Xen-e820 RAM map: >> (XEN) 0000000000000000 - 0000000000099800 (usable) >> (XEN) 0000000000099800 - 00000000000a0000 (reserved) >> (XEN) 00000000000e4000 - 0000000000100000 (reserved) >> (XEN) 0000000000100000 - 00000000bf780000 (usable) >> (XEN) 00000000bf78e000 - 00000000bf790000 type 9 > Ok, so this patch should shed some light and potentially fix your problem. Please > try it out and attach the serial log for Linux kernel. Thx. The patch works perfectly. I've attached a copy of the kernel log with 'debug loglevel=8' --------------020502010604060608070304 Content-Type: text/plain; name="messages" Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename="messages" 2011 Sep 28 08:41:46 syslog-ng[77]: syslog-ng version 1.6.12 starting 2011 Sep 28 08:41:46 kernel: klogd 1.5.0, log source = /proc/kmsg started. 2011 Sep 28 08:41:46 kernel: Cannot find map file. 2011 Sep 28 08:41:46 kernel: Loaded 58607 symbols from 1 module. 2011 Sep 28 08:41:46 kernel: [ 0.000000] Reserving virtual address space above 0xf5800000 2011 Sep 28 08:41:46 kernel: [ 0.000000] Initializing cgroup subsys cpuset 2011 Sep 28 08:41:46 kernel: [ 0.000000] Initializing cgroup subsys cpu 2011 Sep 28 08:41:46 kernel: [ 0.000000] Linux version 3.0.4 (root@linux-krq0) (gcc version 4.4.3 (GCC) ) #1 SMP Fri Sep 23 23:47:09 GMT 2011 2011 Sep 28 08:41:46 kernel: [ 0.000000] KERNEL supported cpus: 2011 Sep 28 08:41:46 kernel: [ 0.000000] Intel GenuineIntel 2011 Sep 28 08:41:46 kernel: [ 0.000000] AMD AuthenticAMD 2011 Sep 28 08:41:46 kernel: [ 0.000000] NSC Geode by NSC 2011 Sep 28 08:41:46 kernel: [ 0.000000] Cyrix CyrixInstead 2011 Sep 28 08:41:46 kernel: [ 0.000000] Centaur CentaurHauls 2011 Sep 28 08:41:46 kernel: [ 0.000000] Transmeta GenuineTMx86 2011 Sep 28 08:41:46 kernel: [ 0.000000] Transmeta TransmetaCPU 2011 Sep 28 08:41:46 kernel: [ 0.000000] UMC UMC UMC UMC 2011 Sep 28 08:41:46 kernel: [ 0.000000] xen_release_chunk: looking at area pfn bf780-bf78e: 14 pages freed 2011 Sep 28 08:41:46 kernel: [ 0.000000] xen_release_chunk: looking at area pfn bf7e0-bf7ec: 12 pages freed 2011 Sep 28 08:41:46 kernel: [ 0.000000] xen_release_chunk: looking at area pfn c0000-e0000: 131072 pages freed 2011 Sep 28 08:41:46 kernel: [ 0.000000] xen_release_chunk: looking at area pfn f0000-fec00: 60416 pages freed 2011 Sep 28 08:41:46 kernel: [ 0.000000] xen_release_chunk: looking at area pfn fec01-fec8a: 137 pages freed 2011 Sep 28 08:41:46 kernel: [ 0.000000] xen_release_chunk: looking at area pfn fec8b-fee00: 373 pages freed 2011 Sep 28 08:41:46 kernel: [ 0.000000] xen_release_chunk: looking at area pfn fee01-ffc00: 3583 pages freed 2011 Sep 28 08:41:46 kernel: [ 0.000000] released 195607 pages of unused memory 2011 Sep 28 08:41:46 kernel: [ 0.000000] (0->0) PCI: 99800->0 (last 0, now 0) 2011 Sep 28 08:41:46 kernel: [ 0.000000] (100000->0) PCI: bf780000->0 (last 99800, now 0) 2011 Sep 28 08:41:46 kernel: [ 0.000000] 1-1 mapping on 99->100 2011 Sep 28 08:41:46 kernel: [ 0.000000] (0->1) PCI: 0->4 (last bf780000, now 0) 2011 Sep 28 08:41:46 kernel: [ 0.000000] 1-1 mapping on bf780->100000 2011 Sep 28 08:41:46 kernel: [ 0.000000] (0->4) PCI: 40000000->4 (last 0, now 4) 2011 Sep 28 08:41:46 kernel: [ 0.000000] Set 264423 page(s) to 1-1 mapping. 2011 Sep 28 08:41:46 kernel: [ 0.000000] BIOS-provided physical RAM map: 2011 Sep 28 08:41:46 kernel: [ 0.000000] Xen: 0000000000000000 - 0000000000099000 (usable) 2011 Sep 28 08:41:46 kernel: [ 0.000000] Xen: 0000000000099800 - 0000000000100000 (reserved) 2011 Sep 28 08:41:46 kernel: [ 0.000000] Xen: 0000000000100000 - 00000000bf780000 (usable) 2011 Sep 28 08:41:46 kernel: [ 0.000000] Xen: 00000000bf78e000 - 00000000bf790000 type 9 2011 Sep 28 08:41:46 kernel: [ 0.000000] Xen: 00000000bf790000 - 00000000bf79e000 (ACPI data) 2011 Sep 28 08:41:46 kernel: [ 0.000000] Xen: 00000000bf79e000 - 00000000bf7d0000 (ACPI NVS) 2011 Sep 28 08:41:46 kernel: [ 0.000000] Xen: 00000000bf7d0000 - 00000000bf7e0000 (reserved) 2011 Sep 28 08:41:46 kernel: [ 0.000000] Xen: 00000000bf7ec000 - 00000000c0000000 (reserved) 2011 Sep 28 08:41:46 kernel: [ 0.000000] Xen: 00000000e0000000 - 00000000f0000000 (reserved) 2011 Sep 28 08:41:46 kernel: [ 0.000000] Xen: 00000000fec00000 - 00000000fec01000 (reserved) 2011 Sep 28 08:41:46 kernel: [ 0.000000] Xen: 00000000fec8a000 - 00000000fec8b000 (reserved) 2011 Sep 28 08:41:46 kernel: [ 0.000000] Xen: 00000000fee00000 - 00000000fee01000 (reserved) 2011 Sep 28 08:41:46 kernel: [ 0.000000] Xen: 00000000ffc00000 - 0000000100000000 (reserved) 2011 Sep 28 08:41:46 kernel: [ 0.000000] Xen: 0000000100000000 - 00000003b017a000 (usable) 2011 Sep 28 08:41:46 kernel: [ 0.000000] Xen: 0000000400000000 - 0000000440000000 (unusable) 2011 Sep 28 08:41:46 kernel: [ 0.000000] NX (Execute Disable) protection: active 2011 Sep 28 08:41:46 kernel: [ 0.000000] DMI present. 2011 Sep 28 08:41:46 kernel: [ 0.000000] DMI: Supermicro X8DTL/X8DTL, BIOS 2.0c 01/05/11 2011 Sep 28 08:41:46 kernel: [ 0.000000] e820 update range: 0000000000000000 - 0000000000010000 (usable) ==> (reserved) 2011 Sep 28 08:41:46 kernel: [ 0.000000] e820 remove range: 00000000000a0000 - 0000000000100000 (usable) 2011 Sep 28 08:41:46 kernel: [ 0.000000] last_pfn = 0x3b017a max_arch_pfn = 0x1000000 2011 Sep 28 08:41:46 kernel: [ 0.000000] found SMP MP-table at [c00ff780] ff780 2011 Sep 28 08:41:46 kernel: [ 0.000000] initial memory mapped : 0 - 03bff000 2011 Sep 28 08:41:46 kernel: [ 0.000000] Base memory trampoline at [c0095000] 95000 size 16384 2011 Sep 28 08:41:46 kernel: [ 0.000000] init_memory_mapping: 0000000000000000-000000002d3fe000 2011 Sep 28 08:41:46 kernel: [ 0.000000] 0000000000 - 002d3fe000 page 4k 2011 Sep 28 08:41:46 kernel: [ 0.000000] kernel direct mapping tables up to 2d3fe000 @ 3a92000-3bff000 2011 Sep 28 08:41:46 kernel: [ 0.000000] xen: setting RW the range 3bde000 - 3bff000 2011 Sep 28 08:41:46 kernel: [ 0.000000] RAMDISK: 01b38000 - 0244a000 2011 Sep 28 08:41:46 kernel: [ 0.000000] ACPI: RSDP 000fabe0 00024 (v02 ACPIAM) 2011 Sep 28 08:41:46 kernel: [ 0.000000] ACPI: XSDT bf790100 0007C (v01 SMCI 20110105 MSFT 00000097) 2011 Sep 28 08:41:46 kernel: [ 0.000000] ACPI: FACP bf790290 000F4 (v03 010511 FACP1122 20110105 MSFT 00000097) 2011 Sep 28 08:41:46 kernel: [ 0.000000] ACPI: DSDT bf7906a0 0655C (v01 10006 10006000 00000000 INTL 20051117) 2011 Sep 28 08:41:46 kernel: [ 0.000000] ACPI: FACS bf79e000 00040 2011 Sep 28 08:41:46 kernel: [ 0.000000] ACPI: APIC bf790390 0011E (v01 010511 APIC1122 20110105 MSFT 00000097) 2011 Sep 28 08:41:46 kernel: [ 0.000000] ACPI: MCFG bf7904b0 0003C (v01 010511 OEMMCFG 20110105 MSFT 00000097) 2011 Sep 28 08:41:46 kernel: [ 0.000000] ACPI: SLIT bf7904f0 00030 (v01 010511 OEMSLIT 20110105 MSFT 00000097) 2011 Sep 28 08:41:46 kernel: [ 0.000000] ACPI: OEMB bf79e040 00085 (v01 010511 OEMB1122 20110105 MSFT 00000097) 2011 Sep 28 08:41:46 kernel: [ 0.000000] ACPI: HPET bf79a6a0 00038 (v01 010511 OEMHPET 20110105 MSFT 00000097) 2011 Sep 28 08:41:46 kernel: [ 0.000000] ACPI: SSDT bf79efb0 00363 (v01 DpgPmm CpuPm 00000012 INTL 20051117) 2011 Sep 28 08:41:46 kernel: [ 0.000000] ACPI: EINJ bf79a6e0 00130 (v01 AMIER AMI_EINJ 20110105 MSFT 00000097) 2011 Sep 28 08:41:46 kernel: [ 0.000000] ACPI: BERT bf79a870 00030 (v01 AMIER AMI_BERT 20110105 MSFT 00000097) 2011 Sep 28 08:41:46 kernel: [ 0.000000] ACPI: ERST bf79a8a0 001B0 (v01 AMIER AMI_ERST 20110105 MSFT 00000097) 2011 Sep 28 08:41:46 kernel: [ 0.000000] ACPI: HEST bf79aa50 000A8 (v01 AMIER ABC_HEST 20110105 MSFT 00000097) 2011 Sep 28 08:41:46 kernel: [ 0.000000] ACPI: Local APIC address 0xfee00000 2011 Sep 28 08:41:46 kernel: [ 0.000000] 14381MB HIGHMEM available. 2011 Sep 28 08:41:46 kernel: [ 0.000000] 723MB LOWMEM available. 2011 Sep 28 08:41:46 kernel: [ 0.000000] mapped low ram: 0 - 2d3fe000 2011 Sep 28 08:41:46 kernel: [ 0.000000] low ram: 0 - 2d3fe000 2011 Sep 28 08:41:46 kernel: [ 0.000000] Zone PFN ranges: 2011 Sep 28 08:41:46 kernel: [ 0.000000] DMA 0x00000010 -> 0x00001000 2011 Sep 28 08:41:46 kernel: [ 0.000000] Normal 0x00001000 -> 0x0002d3fe 2011 Sep 28 08:41:46 kernel: [ 0.000000] HighMem 0x0002d3fe -> 0x003b017a 2011 Sep 28 08:41:46 kernel: [ 0.000000] Movable zone start PFN for each node 2011 Sep 28 08:41:46 kernel: [ 0.000000] early_node_map[3] active PFN ranges 2011 Sep 28 08:41:46 kernel: [ 0.000000] 0: 0x00000010 -> 0x00000099 2011 Sep 28 08:41:46 kernel: [ 0.000000] 0: 0x00000100 -> 0x000bf780 2011 Sep 28 08:41:46 kernel: [ 0.000000] 0: 0x00100000 -> 0x003b017a 2011 Sep 28 08:41:46 kernel: [ 0.000000] On node 0 totalpages: 3602563 2011 Sep 28 08:41:46 kernel: [ 0.000000] free_area_init_node: node 0, pgdat c1733b40, node_mem_map e5df5200 2011 Sep 28 08:41:46 kernel: [ 0.000000] DMA zone: 32 pages used for memmap 2011 Sep 28 08:41:46 kernel: [ 0.000000] DMA zone: 0 pages reserved 2011 Sep 28 08:41:46 kernel: [ 0.000000] DMA zone: 3945 pages, LIFO batch:0 2011 Sep 28 08:41:46 kernel: [ 0.000000] Normal zone: 1416 pages used for memmap 2011 Sep 28 08:41:46 kernel: [ 0.000000] Normal zone: 179830 pages, LIFO batch:31 2011 Sep 28 08:41:46 kernel: [ 0.000000] HighMem zone: 28763 pages used for memmap 2011 Sep 28 08:41:46 kernel: [ 0.000000] HighMem zone: 3388577 pages, LIFO batch:31 2011 Sep 28 08:41:46 kernel: [ 0.000000] Using APIC driver default 2011 Sep 28 08:41:46 kernel: [ 0.000000] ACPI: PM-Timer IO Port: 0x808 2011 Sep 28 08:41:46 kernel: [ 0.000000] ACPI: Local APIC address 0xfee00000 2011 Sep 28 08:41:46 kernel: [ 0.000000] ACPI: LAPIC (acpi_id[0x01] lapic_id[0x00] enabled) 2011 Sep 28 08:41:46 kernel: [ 0.000000] BIOS bug: APIC version is 0 for CPU 0/0x0, fixing up to 0x10 2011 Sep 28 08:41:46 kernel: [ 0.000000] ACPI: LAPIC (acpi_id[0x02] lapic_id[0x02] enabled) 2011 Sep 28 08:41:46 kernel: [ 0.000000] ACPI: LAPIC (acpi_id[0x03] lapic_id[0x04] enabled) 2011 Sep 28 08:41:46 kernel: [ 0.000000] ACPI: LAPIC (acpi_id[0x04] lapic_id[0x06] enabled) 2011 Sep 28 08:41:46 kernel: [ 0.000000] ACPI: LAPIC (acpi_id[0x05] lapic_id[0x84] disabled) 2011 Sep 28 08:41:46 kernel: [ 0.000000] ACPI: LAPIC (acpi_id[0x06] lapic_id[0x85] disabled) 2011 Sep 28 08:41:46 kernel: [ 0.000000] ACPI: LAPIC (acpi_id[0x07] lapic_id[0x86] disabled) 2011 Sep 28 08:41:46 kernel: [ 0.000000] ACPI: LAPIC (acpi_id[0x08] lapic_id[0x87] disabled) 2011 Sep 28 08:41:46 kernel: [ 0.000000] ACPI: LAPIC (acpi_id[0x09] lapic_id[0x88] disabled) 2011 Sep 28 08:41:46 kernel: [ 0.000000] ACPI: LAPIC (acpi_id[0x0a] lapic_id[0x89] disabled) 2011 Sep 28 08:41:46 kernel: [ 0.000000] ACPI: LAPIC (acpi_id[0x0b] lapic_id[0x8a] disabled) 2011 Sep 28 08:41:46 kernel: [ 0.000000] ACPI: LAPIC (acpi_id[0x0c] lapic_id[0x8b] disabled) 2011 Sep 28 08:41:46 kernel: [ 0.000000] ACPI: LAPIC (acpi_id[0x0d] lapic_id[0x8c] disabled) 2011 Sep 28 08:41:46 kernel: [ 0.000000] ACPI: LAPIC (acpi_id[0x0e] lapic_id[0x8d] disabled) 2011 Sep 28 08:41:46 kernel: [ 0.000000] ACPI: LAPIC (acpi_id[0x0f] lapic_id[0x8e] disabled) 2011 Sep 28 08:41:46 kernel: [ 0.000000] ACPI: LAPIC (acpi_id[0x10] lapic_id[0x8f] disabled) 2011 Sep 28 08:41:46 kernel: [ 0.000000] ACPI: LAPIC (acpi_id[0x11] lapic_id[0x90] disabled) 2011 Sep 28 08:41:46 kernel: [ 0.000000] ACPI: LAPIC (acpi_id[0x12] lapic_id[0x91] disabled) 2011 Sep 28 08:41:46 kernel: [ 0.000000] ACPI: LAPIC (acpi_id[0x13] lapic_id[0x92] disabled) 2011 Sep 28 08:41:46 kernel: [ 0.000000] ACPI: LAPIC (acpi_id[0x14] lapic_id[0x93] disabled) 2011 Sep 28 08:41:46 kernel: [ 0.000000] ACPI: LAPIC (acpi_id[0x15] lapic_id[0x94] disabled) 2011 Sep 28 08:41:46 kernel: [ 0.000000] ACPI: LAPIC (acpi_id[0x16] lapic_id[0x95] disabled) 2011 Sep 28 08:41:46 kernel: [ 0.000000] ACPI: LAPIC (acpi_id[0x17] lapic_id[0x96] disabled) 2011 Sep 28 08:41:46 kernel: [ 0.000000] ACPI: LAPIC (acpi_id[0x18] lapic_id[0x97] disabled) 2011 Sep 28 08:41:46 kernel: [ 0.000000] ACPI: LAPIC_NMI (acpi_id[0xff] dfl dfl lint[0x1]) 2011 Sep 28 08:41:46 kernel: [ 0.000000] ACPI: IOAPIC (id[0x01] address[0xfec00000] gsi_base[0]) 2011 Sep 28 08:41:46 kernel: [ 0.000000] IOAPIC[0]: apic_id 1, version 255, address 0xfec00000, GSI 0-255 2011 Sep 28 08:41:46 kernel: [ 0.000000] ACPI: IOAPIC (id[0x03] address[0xfec8a000] gsi_base[24]) 2011 Sep 28 08:41:46 kernel: [ 0.000000] IOAPIC[1]: apic_id 3, version 255, address 0xfec8a000, GSI 24-279 2011 Sep 28 08:41:46 kernel: [ 0.000000] ACPI: INT_SRC_OVR (bus 0 bus_irq 0 global_irq 2 dfl dfl) 2011 Sep 28 08:41:46 kernel: [ 0.000000] ACPI: INT_SRC_OVR (bus 0 bus_irq 9 global_irq 9 high level) 2011 Sep 28 08:41:46 kernel: [ 0.000000] ACPI: IRQ0 used by override. 2011 Sep 28 08:41:46 kernel: [ 0.000000] ACPI: IRQ2 used by override. 2011 Sep 28 08:41:46 kernel: [ 0.000000] ACPI: IRQ9 used by override. 2011 Sep 28 08:41:46 kernel: [ 0.000000] Using ACPI (MADT) for SMP configuration information 2011 Sep 28 08:41:46 kernel: [ 0.000000] ACPI: HPET id: 0x8086a301 base: 0xfed00000 2011 Sep 28 08:41:46 kernel: [ 0.000000] 24 Processors exceeds NR_CPUS limit of 8 2011 Sep 28 08:41:46 kernel: [ 0.000000] SMP: Allowing 8 CPUs, 4 hotplug CPUs 2011 Sep 28 08:41:46 kernel: [ 0.000000] nr_irqs_gsi: 296 2011 Sep 28 08:41:46 kernel: [ 0.000000] PM: Registered nosave memory: 0000000000099000 - 000000000009a000 2011 Sep 28 08:41:46 kernel: [ 0.000000] PM: Registered nosave memory: 000000000009a000 - 0000000000100000 2011 Sep 28 08:41:46 kernel: [ 0.000000] Allocating PCI resources starting at c0000000 (gap: c0000000:20000000) 2011 Sep 28 08:41:46 kernel: [ 0.000000] Booting paravirtualized kernel on Xen 2011 Sep 28 08:41:46 kernel: [ 0.000000] Xen version: 4.1.1 (preserve-AD) 2011 Sep 28 08:41:46 kernel: [ 0.000000] setup_percpu: NR_CPUS:8 nr_cpumask_bits:8 nr_cpu_ids:8 nr_node_ids:1 2011 Sep 28 08:41:46 kernel: [ 0.000000] PERCPU: Embedded 12 pages/cpu @e5d82000 s28352 r0 d20800 u49152 2011 Sep 28 08:41:46 kernel: [ 0.000000] pcpu-alloc: s28352 r0 d20800 u49152 alloc=12*4096 2011 Sep 28 08:41:46 kernel: [ 0.000000] pcpu-alloc: [0] 0 [0] 1 [0] 2 [0] 3 [0] 4 [0] 5 [0] 6 [0] 7 2011 Sep 28 08:41:46 kernel: [ 3.547683] Built 1 zonelists in Zone order, mobility grouping on. Total pages: 3572352 2011 Sep 28 08:41:46 kernel: [ 3.547689] Kernel command line: boot_media=loop-disk boot_volume="/dev/sd?1" boot_volume_id=14a245410aeb3984 boot_mode=setup-automatic debug loglevel=8 2011 Sep 28 08:41:46 kernel: [ 3.547761] PID hash table entries: 4096 (order: 2, 16384 bytes) 2011 Sep 28 08:41:46 kernel: [ 3.547837] Dentry cache hash table entries: 131072 (order: 7, 524288 bytes) 2011 Sep 28 08:41:46 kernel: [ 3.548048] Inode-cache hash table entries: 65536 (order: 6, 262144 bytes) 2011 Sep 28 08:41:46 kernel: [ 3.548315] Initializing CPU#0 2011 Sep 28 08:41:46 kernel: [ 3.570739] allocated 61871776 bytes of page_cgroup 2011 Sep 28 08:41:46 kernel: [ 3.570745] please try 'cgroup_disable=memory' option if you don't want memory cgroups 2011 Sep 28 08:41:46 kernel: [ 3.601991] Placing 64MB software IO TLB between de1bc000 - e21bc000 2011 Sep 28 08:41:46 kernel: [ 3.601996] software IO TLB at phys 0x1e1bc000 - 0x221bc000 2011 Sep 28 08:41:46 kernel: [ 3.626235] Initializing HighMem for node 0 (0002d3fe:003b017a) 2011 Sep 28 08:41:46 kernel: [ 4.998102] Memory: 14126852k/15468008k available (5077k kernel code, 283400k reserved, 2334k data, 676k init, 13669360k highmem) 2011 Sep 28 08:41:46 kernel: [ 4.998111] virtual kernel memory layout: 2011 Sep 28 08:41:46 kernel: [ 4.998112] fixmap : 0xf5716000 - 0xf57ff000 ( 932 kB) 2011 Sep 28 08:41:46 kernel: [ 4.998114] pkmap : 0xf5400000 - 0xf5600000 (2048 kB) 2011 Sep 28 08:41:46 kernel: [ 4.998115] vmalloc : 0xedbfe000 - 0xf53fe000 ( 120 MB) 2011 Sep 28 08:41:46 kernel: [ 4.998116] lowmem : 0xc0000000 - 0xed3fe000 ( 723 MB) 2011 Sep 28 08:41:46 kernel: [ 4.998117] .init : 0xc173e000 - 0xc17e7000 ( 676 kB) 2011 Sep 28 08:41:46 kernel: [ 4.998118] .data : 0xc14f5620 - 0xc173d180 (2334 kB) 2011 Sep 28 08:41:46 kernel: [ 4.998120] .text : 0xc1000000 - 0xc14f5620 (5077 kB) 2011 Sep 28 08:41:46 kernel: [ 4.998182] SLUB: Genslabs=15, HWalign=64, Order=0-3, MinObjects=0, CPUs=8, Nodes=1 2011 Sep 28 08:41:46 kernel: [ 4.998220] Hierarchical RCU implementation. 2011 Sep 28 08:41:46 kernel: [ 4.998223] RCU dyntick-idle grace-period acceleration is enabled. 2011 Sep 28 08:41:46 kernel: [ 4.998234] NR_IRQS:2304 nr_irqs:2048 16 2011 Sep 28 08:41:46 kernel: [ 4.998282] CPU 0 irqstacks, hard=ddc0a000 soft=ddc0c000 2011 Sep 28 08:41:46 kernel: [ 4.998287] xen: sci override: global_irq=9 trigger=0 polarity=0 2011 Sep 28 08:41:46 kernel: [ 4.998291] xen: registering gsi 9 triggering 0 polarity 0 2011 Sep 28 08:41:46 kernel: [ 4.998301] xen: --> pirq=9 -> irq=9 (gsi=9) 2011 Sep 28 08:41:46 kernel: [ 4.998312] xen: acpi sci 9 2011 Sep 28 08:41:46 kernel: [ 4.998317] xen: --> pirq=1 -> irq=1 (gsi=1) 2011 Sep 28 08:41:46 kernel: [ 4.998323] xen: --> pirq=2 -> irq=2 (gsi=2) 2011 Sep 28 08:41:46 kernel: [ 4.998328] xen: --> pirq=3 -> irq=3 (gsi=3) 2011 Sep 28 08:41:46 kernel: [ 4.998333] xen: --> pirq=4 -> irq=4 (gsi=4) 2011 Sep 28 08:41:46 kernel: [ 4.998338] xen: --> pirq=5 -> irq=5 (gsi=5) 2011 Sep 28 08:41:46 kernel: [ 4.998344] xen: --> pirq=6 -> irq=6 (gsi=6) 2011 Sep 28 08:41:46 kernel: [ 4.998349] xen: --> pirq=7 -> irq=7 (gsi=7) 2011 Sep 28 08:41:46 kernel: [ 4.998354] xen: --> pirq=8 -> irq=8 (gsi=8) 2011 Sep 28 08:41:46 kernel: [ 4.998358] xen_map_pirq_gsi: returning irq 9 for gsi 9 2011 Sep 28 08:41:46 kernel: [ 4.998361] xen: --> pirq=9 -> irq=9 (gsi=9) 2011 Sep 28 08:41:46 kernel: [ 4.998367] xen: --> pirq=10 -> irq=10 (gsi=10) 2011 Sep 28 08:41:46 kernel: [ 4.998372] xen: --> pirq=11 -> irq=11 (gsi=11) 2011 Sep 28 08:41:46 kernel: [ 4.998377] xen: --> pirq=12 -> irq=12 (gsi=12) 2011 Sep 28 08:41:46 kernel: [ 4.998383] xen: --> pirq=13 -> irq=13 (gsi=13) 2011 Sep 28 08:41:46 kernel: [ 4.998388] xen: --> pirq=14 -> irq=14 (gsi=14) 2011 Sep 28 08:41:46 kernel: [ 4.998393] xen: --> pirq=15 -> irq=15 (gsi=15) 2011 Sep 28 08:41:46 kernel: [ 5.000488] Console: colour VGA+ 80x25 2011 Sep 28 08:41:46 kernel: [ 5.013549] console [tty0] enabled 2011 Sep 28 08:41:46 kernel: [ 5.013626] Xen: using vcpuop timer interface 2011 Sep 28 08:41:46 kernel: [ 5.013690] installing Xen timer for CPU 0 2011 Sep 28 08:41:46 kernel: [ 5.013779] Detected 2266.788 MHz processor. 2011 Sep 28 08:41:46 kernel: [ 5.013842] Calibrating delay loop (skipped), value calculated using timer frequency.. 4533.57 BogoMIPS (lpj=9067152) 2011 Sep 28 08:41:46 kernel: [ 5.013967] pid_max: default: 32768 minimum: 301 2011 Sep 28 08:41:46 kernel: [ 5.014087] Mount-cache hash table entries: 512 2011 Sep 28 08:41:46 kernel: [ 5.014293] Initializing cgroup subsys cpuacct 2011 Sep 28 08:41:46 kernel: [ 5.014358] Initializing cgroup subsys memory 2011 Sep 28 08:41:46 kernel: [ 5.014428] Initializing cgroup subsys devices 2011 Sep 28 08:41:46 kernel: [ 5.014489] Initializing cgroup subsys freezer 2011 Sep 28 08:41:46 kernel: [ 5.014550] Initializing cgroup subsys net_cls 2011 Sep 28 08:41:46 kernel: [ 5.014611] Initializing cgroup subsys blkio 2011 Sep 28 08:41:46 kernel: [ 5.014728] CPU: Physical Processor ID: 0 2011 Sep 28 08:41:46 kernel: [ 5.014787] CPU: Processor Core ID: 0 2011 Sep 28 08:41:46 kernel: [ 5.018392] ACPI: Core revision 20110413 2011 Sep 28 08:41:46 kernel: [ 5.049173] ftrace: allocating 21320 entries in 42 pages 2011 Sep 28 08:41:46 kernel: [ 5.055814] cpu 0 spinlock event irq 297 2011 Sep 28 08:41:46 kernel: [ 5.055913] Performance Events: unsupported p6 CPU model 26 no PMU driver, software events only. 2011 Sep 28 08:41:46 kernel: [ 5.056290] CPU 1 irqstacks, hard=ddcc0000 soft=ddcc2000 2011 Sep 28 08:41:46 kernel: [ 5.056354] installing Xen timer for CPU 1 2011 Sep 28 08:41:46 kernel: [ 5.056426] cpu 1 spinlock event irq 303 2011 Sep 28 08:41:46 kernel: [ 5.056537] Initializing CPU#1 2011 Sep 28 08:41:46 kernel: [ 5.056688] CPU 2 irqstacks, hard=ddcca000 soft=ddccc000 2011 Sep 28 08:41:46 kernel: [ 5.056806] installing Xen timer for CPU 2 2011 Sep 28 08:41:46 kernel: [ 5.056876] cpu 2 spinlock event irq 309 2011 Sep 28 08:41:46 kernel: [ 5.056981] Initializing CPU#2 2011 Sep 28 08:41:46 kernel: [ 5.057121] CPU 3 irqstacks, hard=ddcf4000 soft=ddcf6000 2011 Sep 28 08:41:46 kernel: [ 5.057238] installing Xen timer for CPU 3 2011 Sep 28 08:41:46 kernel: [ 5.057309] cpu 3 spinlock event irq 315 2011 Sep 28 08:41:46 kernel: [ 5.057410] Initializing CPU#3 2011 Sep 28 08:41:46 kernel: [ 5.057479] Brought up 4 CPUs 2011 Sep 28 08:41:46 kernel: [ 5.057748] devtmpfs: initialized 2011 Sep 28 08:41:46 kernel: [ 5.058174] PM: Registering ACPI NVS region at bf79e000 (204800 bytes) 2011 Sep 28 08:41:46 kernel: [ 5.059132] Grant table initialized 2011 Sep 28 08:41:46 kernel: [ 5.059232] print_constraints: dummy: 2011 Sep 28 08:41:46 kernel: [ 5.059325] Time: 8:41:42 Date: 09/28/11 2011 Sep 28 08:41:46 kernel: [ 5.059422] NET: Registered protocol family 16 2011 Sep 28 08:41:46 kernel: [ 5.059642] EISA bus registered 2011 Sep 28 08:41:46 kernel: [ 5.059731] ACPI: bus type pci registered 2011 Sep 28 08:41:46 kernel: [ 5.059858] PCI: MMCONFIG for domain 0000 [bus 00-ff] at [mem 0xe0000000-0xefffffff] (base 0xe0000000) 2011 Sep 28 08:41:46 kernel: [ 5.059947] PCI: MMCONFIG at [mem 0xe0000000-0xefffffff] reserved in E820 2011 Sep 28 08:41:46 kernel: [ 5.060013] PCI: Using MMCONFIG for extended config space 2011 Sep 28 08:41:46 kernel: [ 5.060076] PCI: Using configuration type 1 for base access 2011 Sep 28 08:41:46 kernel: [ 5.061028] bio: create slab <bio-0> at 0 2011 Sep 28 08:41:46 kernel: [ 5.086030] ACPI: EC: Look up EC in DSDT 2011 Sep 28 08:41:46 kernel: [ 5.086417] \_SB_:_OSC evaluation returned wrong type 2011 Sep 28 08:41:46 kernel: [ 5.086479] _OSC request data:1 7 2011 Sep 28 08:41:46 kernel: [ 5.091089] ACPI: Executed 1 blocks of module-level executable AML code 2011 Sep 28 08:41:46 kernel: [ 5.097459] ACPI: SSDT bf79e0d0 009F8 (v01 DpgPmm P001Ist 00000011 INTL 20051117) 2011 Sep 28 08:41:46 kernel: [ 5.098815] ACPI: Dynamic OEM Table Load: 2011 Sep 28 08:41:46 kernel: [ 5.098941] ACPI: SSDT (null) 009F8 (v01 DpgPmm P001Ist 00000011 INTL 20051117) 2011 Sep 28 08:41:46 kernel: [ 5.099307] ACPI: SSDT bf79ead0 004D5 (v01 PmRef P001Cst 00003001 INTL 20051117) 2011 Sep 28 08:41:46 kernel: [ 5.099727] ACPI: Dynamic OEM Table Load: 2011 Sep 28 08:41:46 kernel: [ 5.099852] ACPI: SSDT (null) 004D5 (v01 PmRef P001Cst 00003001 INTL 20051117) 2011 Sep 28 08:41:46 kernel: [ 5.100434] ACPI: Interpreter enabled 2011 Sep 28 08:41:46 kernel: [ 5.100497] ACPI: (supports S0 S1 S4 S5) 2011 Sep 28 08:41:46 kernel: [ 5.100702] ACPI: Using IOAPIC for interrupt routing 2011 Sep 28 08:41:46 kernel: [ 5.113044] ACPI: No dock devices found. 2011 Sep 28 08:41:46 kernel: [ 5.113149] HEST: Table parsing has been initialized. 2011 Sep 28 08:41:46 kernel: [ 5.113214] PCI: Using host bridge windows from ACPI; if necessary, use "pci=nocrs" and report a bug 2011 Sep 28 08:41:46 kernel: [ 5.113466] ACPI: PCI Root Bridge [PCI0] (domain 0000 [bus 00-ff]) 2011 Sep 28 08:41:46 kernel: [ 5.113825] pci_root PNP0A08:00: host bridge window [io 0x0000-0x03af] 2011 Sep 28 08:41:46 kernel: [ 5.113891] pci_root PNP0A08:00: host bridge window [io 0x03e0-0x0cf7] 2011 Sep 28 08:41:46 kernel: [ 5.113957] pci_root PNP0A08:00: host bridge window [io 0x03b0-0x03bb] 2011 Sep 28 08:41:46 kernel: [ 5.114022] pci_root PNP0A08:00: host bridge window [io 0x03c0-0x03df] 2011 Sep 28 08:41:46 kernel: [ 5.114087] pci_root PNP0A08:00: host bridge window [io 0x0d00-0xefff] 2011 Sep 28 08:41:46 kernel: [ 5.114152] pci_root PNP0A08:00: host bridge window [io 0xf000-0xffff] 2011 Sep 28 08:41:46 kernel: [ 5.114218] pci_root PNP0A08:00: host bridge window [mem 0x000a0000-0x000bffff] 2011 Sep 28 08:41:46 kernel: [ 5.114301] pci_root PNP0A08:00: host bridge window [mem 0x000d0000-0x000dffff] 2011 Sep 28 08:41:46 kernel: [ 5.114385] pci_root PNP0A08:00: host bridge window [mem 0xc0000000-0xdfffffff] 2011 Sep 28 08:41:46 kernel: [ 5.114468] pci_root PNP0A08:00: host bridge window [mem 0xf0000000-0xfed8ffff] 2011 Sep 28 08:41:46 kernel: [ 5.114552] pci_root PNP0A08:00: host bridge window [mem 0xfed40000-0xfed44fff] 2011 Sep 28 08:41:46 kernel: [ 5.114636] pci_root PNP0A08:00: host bridge window expanded to [mem 0xf0000000-0xfed8ffff]; [mem 0xfed40000-0xfed44fff] ignored 2011 Sep 28 08:41:46 kernel: [ 5.114755] pci 0000:00:00.0: [8086:3403] type 0 class 0x000600 2011 Sep 28 08:41:46 kernel: [ 5.114939] pci 0000:00:00.0: PME# supported from D0 D3hot D3cold 2011 Sep 28 08:41:46 kernel: [ 5.115007] pci 0000:00:00.0: PME# disabled 2011 Sep 28 08:41:46 kernel: [ 5.115122] pci 0000:00:01.0: [8086:3408] type 1 class 0x000604 2011 Sep 28 08:41:46 kernel: [ 5.115307] pci 0000:00:01.0: PME# supported from D0 D3hot D3cold 2011 Sep 28 08:41:46 kernel: [ 5.115375] pci 0000:00:01.0: PME# disabled 2011 Sep 28 08:41:46 kernel: [ 5.115491] pci 0000:00:03.0: [8086:340a] type 1 class 0x000604 2011 Sep 28 08:41:46 kernel: [ 5.115676] pci 0000:00:03.0: PME# supported from D0 D3hot D3cold 2011 Sep 28 08:41:46 kernel: [ 5.115745] pci 0000:00:03.0: PME# disabled 2011 Sep 28 08:41:46 kernel: [ 5.115865] pci 0000:00:07.0: [8086:340e] type 1 class 0x000604 2011 Sep 28 08:41:46 kernel: [ 5.116050] pci 0000:00:07.0: PME# supported from D0 D3hot D3cold 2011 Sep 28 08:41:46 kernel: [ 5.116118] pci 0000:00:07.0: PME# disabled 2011 Sep 28 08:41:46 kernel: [ 5.116234] pci 0000:00:09.0: [8086:3410] type 1 class 0x000604 2011 Sep 28 08:41:46 kernel: [ 5.116419] pci 0000:00:09.0: PME# supported from D0 D3hot D3cold 2011 Sep 28 08:41:46 kernel: [ 5.116487] pci 0000:00:09.0: PME# disabled 2011 Sep 28 08:41:46 kernel: [ 5.116609] pci 0000:00:13.0: [8086:342d] type 0 class 0x000800 2011 Sep 28 08:41:46 kernel: [ 5.116699] pci 0000:00:13.0: reg 10: [mem 0xfec8a000-0xfec8afff] 2011 Sep 28 08:41:46 kernel: [ 5.116879] pci 0000:00:13.0: PME# supported from D0 D3hot D3cold 2011 Sep 28 08:41:46 kernel: [ 5.116947] pci 0000:00:13.0: PME# disabled 2011 Sep 28 08:41:46 kernel: [ 5.117042] pci 0000:00:14.0: [8086:342e] type 0 class 0x000800 2011 Sep 28 08:41:46 kernel: [ 5.117265] pci 0000:00:14.1: [8086:3422] type 0 class 0x000800 2011 Sep 28 08:41:46 kernel: [ 5.117491] pci 0000:00:14.2: [8086:3423] type 0 class 0x000800 2011 Sep 28 08:41:46 kernel: [ 5.117712] pci 0000:00:14.3: [8086:3438] type 0 class 0x000800 2011 Sep 28 08:41:46 kernel: [ 5.117925] pci 0000:00:16.0: [8086:3430] type 0 class 0x000880 2011 Sep 28 08:41:46 kernel: [ 5.118021] pci 0000:00:16.0: reg 10: [mem 0xfbef8000-0xfbefbfff 64bit] 2011 Sep 28 08:41:46 kernel: [ 5.118245] pci 0000:00:16.1: [8086:3431] type 0 class 0x000880 2011 Sep 28 08:41:46 kernel: [ 5.118341] pci 0000:00:16.1: reg 10: [mem 0xfbef4000-0xfbef7fff 64bit] 2011 Sep 28 08:41:46 kernel: [ 5.118565] pci 0000:00:16.2: [8086:3432] type 0 class 0x000880 2011 Sep 28 08:41:46 kernel: [ 5.118660] pci 0000:00:16.2: reg 10: [mem 0xfbef0000-0xfbef3fff 64bit] 2011 Sep 28 08:41:46 kernel: [ 5.118884] pci 0000:00:16.3: [8086:3433] type 0 class 0x000880 2011 Sep 28 08:41:46 kernel: [ 5.118979] pci 0000:00:16.3: reg 10: [mem 0xfbeec000-0xfbeeffff 64bit] 2011 Sep 28 08:41:46 kernel: [ 5.119204] pci 0000:00:16.4: [8086:3429] type 0 class 0x000880 2011 Sep 28 08:41:46 kernel: [ 5.119299] pci 0000:00:16.4: reg 10: [mem 0xfbee8000-0xfbeebfff 64bit] 2011 Sep 28 08:41:46 kernel: [ 5.119523] pci 0000:00:16.5: [8086:342a] type 0 class 0x000880 2011 Sep 28 08:41:46 kernel: [ 5.119619] pci 0000:00:16.5: reg 10: [mem 0xfbee4000-0xfbee7fff 64bit] 2011 Sep 28 08:41:46 kernel: [ 5.119843] pci 0000:00:16.6: [8086:342b] type 0 class 0x000880 2011 Sep 28 08:41:46 kernel: [ 5.119938] pci 0000:00:16.6: reg 10: [mem 0xfbee0000-0xfbee3fff 64bit] 2011 Sep 28 08:41:46 kernel: [ 5.120162] pci 0000:00:16.7: [8086:342c] type 0 class 0x000880 2011 Sep 28 08:41:46 kernel: [ 5.120258] pci 0000:00:16.7: reg 10: [mem 0xfbedc000-0xfbedffff 64bit] 2011 Sep 28 08:41:46 kernel: [ 5.120486] pci 0000:00:1a.0: [8086:3a37] type 0 class 0x000c03 2011 Sep 28 08:41:46 kernel: [ 5.120644] pci 0000:00:1a.0: reg 20: [io 0xcc00-0xcc1f] 2011 Sep 28 08:41:46 kernel: [ 5.120799] pci 0000:00:1a.1: [8086:3a38] type 0 class 0x000c03 2011 Sep 28 08:41:46 kernel: [ 5.120957] pci 0000:00:1a.1: reg 20: [io 0xc880-0xc89f] 2011 Sep 28 08:41:46 kernel: [ 5.121112] pci 0000:00:1a.2: [8086:3a39] type 0 class 0x000c03 2011 Sep 28 08:41:46 kernel: [ 5.121272] pci 0000:00:1a.2: reg 20: [io 0xc800-0xc81f] 2011 Sep 28 08:41:46 kernel: [ 5.121448] pci 0000:00:1a.7: [8086:3a3c] type 0 class 0x000c03 2011 Sep 28 08:41:46 kernel: [ 5.121553] pci 0000:00:1a.7: reg 10: [mem 0xfbeda000-0xfbeda3ff] 2011 Sep 28 08:41:46 kernel: [ 5.121772] pci 0000:00:1a.7: PME# supported from D0 D3hot D3cold 2011 Sep 28 08:41:46 kernel: [ 5.121841] pci 0000:00:1a.7: PME# disabled 2011 Sep 28 08:41:46 kernel: [ 5.121946] pci 0000:00:1b.0: [8086:3a3e] type 0 class 0x000403 2011 Sep 28 08:41:46 kernel: [ 5.122045] pci 0000:00:1b.0: reg 10: [mem 0xfbed4000-0xfbed7fff 64bit] 2011 Sep 28 08:41:46 kernel: [ 5.122235] pci 0000:00:1b.0: PME# supported from D0 D3hot D3cold 2011 Sep 28 08:41:46 kernel: [ 5.122304] pci 0000:00:1b.0: PME# disabled 2011 Sep 28 08:41:46 kernel: [ 5.122404] pci 0000:00:1c.0: [8086:3a40] type 1 class 0x000604 2011 Sep 28 08:41:46 kernel: [ 5.122599] pci 0000:00:1c.0: PME# supported from D0 D3hot D3cold 2011 Sep 28 08:41:46 kernel: [ 5.122668] pci 0000:00:1c.0: PME# disabled 2011 Sep 28 08:41:46 kernel: [ 5.122779] pci 0000:00:1c.4: [8086:3a48] type 1 class 0x000604 2011 Sep 28 08:41:46 kernel: [ 5.122975] pci 0000:00:1c.4: PME# supported from D0 D3hot D3cold 2011 Sep 28 08:41:46 kernel: [ 5.123043] pci 0000:00:1c.4: PME# disabled 2011 Sep 28 08:41:46 kernel: [ 5.123150] pci 0000:00:1c.5: [8086:3a4a] type 1 class 0x000604 2011 Sep 28 08:41:46 kernel: [ 5.123348] pci 0000:00:1c.5: PME# supported from D0 D3hot D3cold 2011 Sep 28 08:41:46 kernel: [ 5.123416] pci 0000:00:1c.5: PME# disabled 2011 Sep 28 08:41:46 kernel: [ 5.123527] pci 0000:00:1d.0: [8086:3a34] type 0 class 0x000c03 2011 Sep 28 08:41:46 kernel: [ 5.123684] pci 0000:00:1d.0: reg 20: [io 0xc480-0xc49f] 2011 Sep 28 08:41:46 kernel: [ 5.123840] pci 0000:00:1d.1: [8086:3a35] type 0 class 0x000c03 2011 Sep 28 08:41:46 kernel: [ 5.123997] pci 0000:00:1d.1: reg 20: [io 0xc400-0xc41f] 2011 Sep 28 08:41:46 kernel: [ 5.124152] pci 0000:00:1d.2: [8086:3a36] type 0 class 0x000c03 2011 Sep 28 08:41:46 kernel: [ 5.124310] pci 0000:00:1d.2: reg 20: [io 0xc080-0xc09f] 2011 Sep 28 08:41:46 kernel: [ 5.124484] pci 0000:00:1d.7: [8086:3a3a] type 0 class 0x000c03 2011 Sep 28 08:41:46 kernel: [ 5.124589] pci 0000:00:1d.7: reg 10: [mem 0xfbed8000-0xfbed83ff] 2011 Sep 28 08:41:46 kernel: [ 5.124807] pci 0000:00:1d.7: PME# supported from D0 D3hot D3cold 2011 Sep 28 08:41:46 kernel: [ 5.124876] pci 0000:00:1d.7: PME# disabled 2011 Sep 28 08:41:46 kernel: [ 5.126393] pci 0000:00:1e.0: [8086:244e] type 1 class 0x000604 2011 Sep 28 08:41:46 kernel: [ 5.126580] pci 0000:00:1f.0: [8086:3a16] type 0 class 0x000601 2011 Sep 28 08:41:46 kernel: [ 5.126802] pci 0000:00:1f.0: ICH7 LPC Generic IO decode 1 PIO at 0a00 (mask 00ff) 2011 Sep 28 08:41:46 kernel: [ 5.126889] pci 0000:00:1f.0: ICH7 LPC Generic IO decode 2 PIO at 4700 (mask 00ff) 2011 Sep 28 08:41:46 kernel: [ 5.126978] pci 0000:00:1f.0: ICH7 LPC Generic IO decode 4 PIO at 0ca0 (mask 000f) 2011 Sep 28 08:41:46 kernel: [ 5.127129] pci 0000:00:1f.2: [8086:3a20] type 0 class 0x000101 2011 Sep 28 08:41:46 kernel: [ 5.127226] pci 0000:00:1f.2: reg 10: [io 0xc000-0xc007] 2011 Sep 28 08:41:46 kernel: [ 5.127304] pci 0000:00:1f.2: reg 14: [io 0xbc00-0xbc03] 2011 Sep 28 08:41:46 kernel: [ 5.127381] pci 0000:00:1f.2: reg 18: [io 0xb880-0xb887] 2011 Sep 28 08:41:46 kernel: [ 5.127459] pci 0000:00:1f.2: reg 1c: [io 0xb800-0xb803] 2011 Sep 28 08:41:46 kernel: [ 5.127537] pci 0000:00:1f.2: reg 20: [io 0xb480-0xb48f] 2011 Sep 28 08:41:46 kernel: [ 5.127615] pci 0000:00:1f.2: reg 24: [io 0xb400-0xb40f] 2011 Sep 28 08:41:46 kernel: [ 5.127759] pci 0000:00:1f.3: [8086:3a30] type 0 class 0x000c05 2011 Sep 28 08:41:46 kernel: [ 5.127855] pci 0000:00:1f.3: reg 10: [mem 0xfbed2000-0xfbed20ff 64bit] 2011 Sep 28 08:41:46 kernel: [ 5.127966] pci 0000:00:1f.3: reg 20: [io 0x0400-0x041f] 2011 Sep 28 08:41:46 kernel: [ 5.128098] pci 0000:00:1f.5: [8086:3a26] type 0 class 0x000101 2011 Sep 28 08:41:46 kernel: [ 5.128195] pci 0000:00:1f.5: reg 10: [io 0xb000-0xb007] 2011 Sep 28 08:41:46 kernel: [ 5.128273] pci 0000:00:1f.5: reg 14: [io 0xac00-0xac03] 2011 Sep 28 08:41:46 kernel: [ 5.128351] pci 0000:00:1f.5: reg 18: [io 0xa880-0xa887] 2011 Sep 28 08:41:46 kernel: [ 5.128428] pci 0000:00:1f.5: reg 1c: [io 0xa800-0xa803] 2011 Sep 28 08:41:46 kernel: [ 5.128506] pci 0000:00:1f.5: reg 20: [io 0xa480-0xa48f] 2011 Sep 28 08:41:46 kernel: [ 5.128584] pci 0000:00:1f.5: reg 24: [io 0xa400-0xa40f] 2011 Sep 28 08:41:46 kernel: [ 5.128813] pci 0000:00:01.0: PCI bridge to [bus 01-01] 2011 Sep 28 08:41:46 kernel: [ 5.128880] pci 0000:00:01.0: bridge window [io 0xf000-0x0000] (disabled) 2011 Sep 28 08:41:46 kernel: [ 5.128950] pci 0000:00:01.0: bridge window [mem 0xfff00000-0x000fffff] (disabled) 2011 Sep 28 08:41:46 kernel: [ 5.129043] pci 0000:00:01.0: bridge window [mem 0xfff00000-0x000fffff pref] (disabled) 2011 Sep 28 08:41:46 kernel: [ 5.129220] pci 0000:00:03.0: PCI bridge to [bus 02-02] 2011 Sep 28 08:41:46 kernel: [ 5.129287] pci 0000:00:03.0: bridge window [io 0xf000-0x0000] (disabled) 2011 Sep 28 08:41:46 kernel: [ 5.129357] pci 0000:00:03.0: bridge window [mem 0xfff00000-0x000fffff] (disabled) 2011 Sep 28 08:41:46 kernel: [ 5.129450] pci 0000:00:03.0: bridge window [mem 0xfff00000-0x000fffff pref] (disabled) 2011 Sep 28 08:41:46 kernel: [ 5.129627] pci 0000:00:07.0: PCI bridge to [bus 03-03] 2011 Sep 28 08:41:46 kernel: [ 5.129693] pci 0000:00:07.0: bridge window [io 0xf000-0x0000] (disabled) 2011 Sep 28 08:41:46 kernel: [ 5.129764] pci 0000:00:07.0: bridge window [mem 0xfff00000-0x000fffff] (disabled) 2011 Sep 28 08:41:46 kernel: [ 5.129856] pci 0000:00:07.0: bridge window [mem 0xfff00000-0x000fffff pref] (disabled) 2011 Sep 28 08:41:46 kernel: [ 5.130034] pci 0000:00:09.0: PCI bridge to [bus 04-04] 2011 Sep 28 08:41:46 kernel: [ 5.130100] pci 0000:00:09.0: bridge window [io 0xf000-0x0000] (disabled) 2011 Sep 28 08:41:46 kernel: [ 5.130171] pci 0000:00:09.0: bridge window [mem 0xfff00000-0x000fffff] (disabled) 2011 Sep 28 08:41:46 kernel: [ 5.130263] pci 0000:00:09.0: bridge window [mem 0xfff00000-0x000fffff pref] (disabled) 2011 Sep 28 08:41:46 kernel: [ 5.130439] pci 0000:00:1c.0: PCI bridge to [bus 05-05] 2011 Sep 28 08:41:46 kernel: [ 5.130505] pci 0000:00:1c.0: bridge window [io 0xf000-0x0000] (disabled) 2011 Sep 28 08:41:46 kernel: [ 5.130576] pci 0000:00:1c.0: bridge window [mem 0xfff00000-0x000fffff] (disabled) 2011 Sep 28 08:41:46 kernel: [ 5.130669] pci 0000:00:1c.0: bridge window [mem 0xfff00000-0x000fffff pref] (disabled) 2011 Sep 28 08:41:46 kernel: [ 5.130870] pci 0000:06:00.0: [8086:10d3] type 0 class 0x000200 2011 Sep 28 08:41:46 kernel: [ 5.130971] pci 0000:06:00.0: reg 10: [mem 0xfbce0000-0xfbcfffff] 2011 Sep 28 08:41:46 kernel: [ 5.131081] pci 0000:06:00.0: reg 18: [io 0xdc00-0xdc1f] 2011 Sep 28 08:41:46 kernel: [ 5.131166] pci 0000:06:00.0: reg 1c: [mem 0xfbcdc000-0xfbcdffff] 2011 Sep 28 08:41:46 kernel: [ 5.131383] pci 0000:06:00.0: PME# supported from D0 D3hot D3cold 2011 Sep 28 08:41:46 kernel: [ 5.131454] pci 0000:06:00.0: PME# disabled 2011 Sep 28 08:41:46 kernel: [ 5.139513] pci 0000:00:1c.4: PCI bridge to [bus 06-06] 2011 Sep 28 08:41:46 kernel: [ 5.139587] pci 0000:00:1c.4: bridge window [io 0xd000-0xdfff] 2011 Sep 28 08:41:46 kernel: [ 5.139655] pci 0000:00:1c.4: bridge window [mem 0xfbc00000-0xfbcfffff] 2011 Sep 28 08:41:46 kernel: [ 5.139730] pci 0000:00:1c.4: bridge window [mem 0xfff00000-0x000fffff pref] (disabled) 2011 Sep 28 08:41:46 kernel: [ 5.139944] pci 0000:07:00.0: [8086:10d3] type 0 class 0x000200 2011 Sep 28 08:41:46 kernel: [ 5.140047] pci 0000:07:00.0: reg 10: [mem 0xfbde0000-0xfbdfffff] 2011 Sep 28 08:41:46 kernel: [ 5.140160] pci 0000:07:00.0: reg 18: [io 0xec00-0xec1f] 2011 Sep 28 08:41:46 kernel: [ 5.140248] pci 0000:07:00.0: reg 1c: [mem 0xfbddc000-0xfbddffff] 2011 Sep 28 08:41:46 kernel: [ 5.140468] pci 0000:07:00.0: PME# supported from D0 D3hot D3cold 2011 Sep 28 08:41:46 kernel: [ 5.140539] pci 0000:07:00.0: PME# disabled 2011 Sep 28 08:41:46 kernel: [ 5.147616] pci 0000:00:1c.5: PCI bridge to [bus 07-07] 2011 Sep 28 08:41:46 kernel: [ 5.147690] pci 0000:00:1c.5: bridge window [io 0xe000-0xefff] 2011 Sep 28 08:41:46 kernel: [ 5.147759] pci 0000:00:1c.5: bridge window [mem 0xfbd00000-0xfbdfffff] 2011 Sep 28 08:41:46 kernel: [ 5.147834] pci 0000:00:1c.5: bridge window [mem 0xfff00000-0x000fffff pref] (disabled) 2011 Sep 28 08:41:46 kernel: [ 5.147987] pci 0000:08:01.0: [102b:0532] type 0 class 0x000300 2011 Sep 28 08:41:46 kernel: [ 5.148083] pci 0000:08:01.0: reg 10: [mem 0xf9000000-0xf9ffffff pref] 2011 Sep 28 08:41:46 kernel: [ 5.148165] pci 0000:08:01.0: reg 14: [mem 0xfaffc000-0xfaffffff] 2011 Sep 28 08:41:46 kernel: [ 5.148246] pci 0000:08:01.0: reg 18: [mem 0xfb000000-0xfb7fffff] 2011 Sep 28 08:41:46 kernel: [ 5.148498] pci 0000:00:1e.0: PCI bridge to [bus 08-08] (subtractive decode) 2011 Sep 28 08:41:46 kernel: [ 5.148569] pci 0000:00:1e.0: bridge window [io 0xf000-0x0000] (disabled) 2011 Sep 28 08:41:46 kernel: [ 5.148640] pci 0000:00:1e.0: bridge window [mem 0xfaf00000-0xfb7fffff] 2011 Sep 28 08:41:46 kernel: [ 5.148714] pci 0000:00:1e.0: bridge window [mem 0xf9000000-0xf9ffffff 64bit pref] 2011 Sep 28 08:41:46 kernel: [ 5.148799] pci 0000:00:1e.0: bridge window [io 0x0000-0x03af] (subtractive decode) 2011 Sep 28 08:41:46 kernel: [ 5.148884] pci 0000:00:1e.0: bridge window [io 0x03e0-0x0cf7] (subtractive decode) 2011 Sep 28 08:41:46 kernel: [ 5.148969] pci 0000:00:1e.0: bridge window [io 0x03b0-0x03bb] (subtractive decode) 2011 Sep 28 08:41:46 kernel: [ 5.149054] pci 0000:00:1e.0: bridge window [io 0x03c0-0x03df] (subtractive decode) 2011 Sep 28 08:41:46 kernel: [ 5.149138] pci 0000:00:1e.0: bridge window [io 0x0d00-0xefff] (subtractive decode) 2011 Sep 28 08:41:46 kernel: [ 5.149224] pci 0000:00:1e.0: bridge window [io 0xf000-0xffff] (subtractive decode) 2011 Sep 28 08:41:46 kernel: [ 5.149309] pci 0000:00:1e.0: bridge window [mem 0x000a0000-0x000bffff] (subtractive decode) 2011 Sep 28 08:41:46 kernel: [ 5.149395] pci 0000:00:1e.0: bridge window [mem 0x000d0000-0x000dffff] (subtractive decode) 2011 Sep 28 08:41:46 kernel: [ 5.149482] pci 0000:00:1e.0: bridge window [mem 0xc0000000-0xdfffffff] (subtractive decode) 2011 Sep 28 08:41:46 kernel: [ 5.149568] pci 0000:00:1e.0: bridge window [mem 0xf0000000-0xfed8ffff] (subtractive decode) 2011 Sep 28 08:41:46 kernel: [ 5.149726] pci_bus 0000:00: on NUMA node 0 2011 Sep 28 08:41:46 kernel: [ 5.149788] ACPI: PCI Interrupt Routing Table [\_SB_.PCI0._PRT] 2011 Sep 28 08:41:46 kernel: [ 5.150135] ACPI: PCI Interrupt Routing Table [\_SB_.PCI0.NPE1._PRT] 2011 Sep 28 08:41:46 kernel: [ 5.150246] ACPI: PCI Interrupt Routing Table [\_SB_.PCI0.NPE3._PRT] 2011 Sep 28 08:41:46 kernel: [ 5.150365] ACPI: PCI Interrupt Routing Table [\_SB_.PCI0.NPE7._PRT] 2011 Sep 28 08:41:46 kernel: [ 5.150473] ACPI: PCI Interrupt Routing Table [\_SB_.PCI0.NPE9._PRT] 2011 Sep 28 08:41:46 kernel: [ 5.150581] ACPI: PCI Interrupt Routing Table [\_SB_.PCI0.P0P1._PRT] 2011 Sep 28 08:41:46 kernel: [ 5.150779] ACPI: PCI Interrupt Routing Table [\_SB_.PCI0.P0P4._PRT] 2011 Sep 28 08:41:46 kernel: [ 5.150897] ACPI: PCI Interrupt Routing Table [\_SB_.PCI0.P0P8._PRT] 2011 Sep 28 08:41:46 kernel: [ 5.151000] ACPI: PCI Interrupt Routing Table [\_SB_.PCI0.P0P9._PRT] 2011 Sep 28 08:41:46 kernel: [ 5.151107] pci0000:00: Requesting ACPI _OSC control (0x1d) 2011 Sep 28 08:41:46 kernel: [ 5.151173] pci0000:00: ACPI _OSC request failed (AE_NOT_FOUND), returned control mask: 0x1d 2011 Sep 28 08:41:46 kernel: [ 5.151258] ACPI _OSC control for PCIe not granted, disabling ASPM 2011 Sep 28 08:41:46 kernel: [ 5.181901] ACPI: PCI Interrupt Link [LNKA] (IRQs 3 4 6 7 10 *11 12 14 15) 2011 Sep 28 08:41:46 kernel: [ 5.182404] ACPI: PCI Interrupt Link [LNKB] (IRQs 3 4 6 7 *10 11 12 14 15) 2011 Sep 28 08:41:46 kernel: [ 5.182894] ACPI: PCI Interrupt Link [LNKC] (IRQs 3 4 6 7 10 11 12 14 *15) 2011 Sep 28 08:41:46 kernel: [ 5.183395] ACPI: PCI Interrupt Link [LNKD] (IRQs 3 4 6 7 10 11 12 *14 15) 2011 Sep 28 08:41:46 kernel: [ 5.183897] ACPI: PCI Interrupt Link [LNKE] (IRQs 3 4 6 7 10 11 12 14 15) *0, disabled. 2011 Sep 28 08:41:46 kernel: [ 5.184471] ACPI: PCI Interrupt Link [LNKF] (IRQs 3 4 6 *7 10 11 12 14 15) 2011 Sep 28 08:41:46 kernel: [ 5.184966] ACPI: PCI Interrupt Link [LNKG] (IRQs 3 4 *6 7 10 11 12 14 15) 2011 Sep 28 08:41:46 kernel: [ 5.185470] ACPI: PCI Interrupt Link [LNKH] (IRQs 3 4 6 7 *10 11 12 14 15) 2011 Sep 28 08:41:46 kernel: [ 5.185936] xen/balloon: Initialising balloon driver. 2011 Sep 28 08:41:46 kernel: [ 5.185999] last_pfn = 0x3b017a max_arch_pfn = 0x1000000 2011 Sep 28 08:41:46 kernel: [ 5.186073] xen-balloon: Initialising balloon driver. 2011 Sep 28 08:41:46 kernel: [ 5.186211] vgaarb: device added: PCI:0000:08:01.0,decodes=io+mem,owns=io+mem,locks=none 2011 Sep 28 08:41:46 kernel: [ 5.186296] vgaarb: loaded 2011 Sep 28 08:41:46 kernel: [ 5.186353] vgaarb: bridge control possible 0000:08:01.0 2011 Sep 28 08:41:46 kernel: [ 5.186555] SCSI subsystem initialized 2011 Sep 28 08:41:46 kernel: [ 5.186673] libata version 3.00 loaded. 2011 Sep 28 08:41:46 kernel: [ 5.186769] usbcore: registered new interface driver usbfs 2011 Sep 28 08:41:46 kernel: [ 5.186840] usbcore: registered new interface driver hub 2011 Sep 28 08:41:46 kernel: [ 5.186942] usbcore: registered new device driver usb 2011 Sep 28 08:41:46 kernel: [ 5.187090] PCI: Using ACPI for IRQ routing 2011 Sep 28 08:41:46 kernel: [ 5.199973] PCI: Discovered peer bus ff 2011 Sep 28 08:41:46 kernel: [ 5.200061] pci 0000:ff:00.0: [8086:2c40] type 0 class 0x000600 2011 Sep 28 08:41:46 kernel: [ 5.200202] pci 0000:ff:00.1: [8086:2c01] type 0 class 0x000600 2011 Sep 28 08:41:46 kernel: [ 5.200349] pci 0000:ff:02.0: [8086:2c10] type 0 class 0x000600 2011 Sep 28 08:41:46 kernel: [ 5.200486] pci 0000:ff:02.1: [8086:2c11] type 0 class 0x000600 2011 Sep 28 08:41:46 kernel: [ 5.200624] pci 0000:ff:02.4: [8086:2c14] type 0 class 0x000600 2011 Sep 28 08:41:46 kernel: [ 5.200758] pci 0000:ff:02.5: [8086:2c15] type 0 class 0x000600 2011 Sep 28 08:41:46 kernel: [ 5.200896] pci 0000:ff:03.0: [8086:2c18] type 0 class 0x000600 2011 Sep 28 08:41:46 kernel: [ 5.201031] pci 0000:ff:03.1: [8086:2c19] type 0 class 0x000600 2011 Sep 28 08:41:46 kernel: [ 5.201165] pci 0000:ff:03.2: [8086:2c1a] type 0 class 0x000600 2011 Sep 28 08:41:46 kernel: [ 5.201301] pci 0000:ff:03.4: [8086:2c1c] type 0 class 0x000600 2011 Sep 28 08:41:46 kernel: [ 5.201441] pci 0000:ff:04.0: [8086:2c20] type 0 class 0x000600 2011 Sep 28 08:41:46 kernel: [ 5.201575] pci 0000:ff:04.1: [8086:2c21] type 0 class 0x000600 2011 Sep 28 08:41:46 kernel: [ 5.201710] pci 0000:ff:04.2: [8086:2c22] type 0 class 0x000600 2011 Sep 28 08:41:46 kernel: [ 5.201845] pci 0000:ff:04.3: [8086:2c23] type 0 class 0x000600 2011 Sep 28 08:41:46 kernel: [ 5.201986] pci 0000:ff:05.0: [8086:2c28] type 0 class 0x000600 2011 Sep 28 08:41:46 kernel: [ 5.202120] pci 0000:ff:05.1: [8086:2c29] type 0 class 0x000600 2011 Sep 28 08:41:46 kernel: [ 5.202254] pci 0000:ff:05.2: [8086:2c2a] type 0 class 0x000600 2011 Sep 28 08:41:46 kernel: [ 5.202389] pci 0000:ff:05.3: [8086:2c2b] type 0 class 0x000600 2011 Sep 28 08:41:46 kernel: [ 5.202530] pci 0000:ff:06.0: [8086:2c30] type 0 class 0x000600 2011 Sep 28 08:41:46 kernel: [ 5.202667] pci 0000:ff:06.1: [8086:2c31] type 0 class 0x000600 2011 Sep 28 08:41:46 kernel: [ 5.202802] pci 0000:ff:06.2: [8086:2c32] type 0 class 0x000600 2011 Sep 28 08:41:46 kernel: [ 5.202936] pci 0000:ff:06.3: [8086:2c33] type 0 class 0x000600 2011 Sep 28 08:41:46 kernel: [ 5.203586] PCI: pci_cache_line_size set to 64 bytes 2011 Sep 28 08:41:46 kernel: [ 5.203966] reserve RAM buffer: 0000000000099000 - 000000000009ffff 2011 Sep 28 08:41:46 kernel: [ 5.204014] reserve RAM buffer: 00000000bf780000 - 00000000bfffffff 2011 Sep 28 08:41:46 kernel: [ 5.204111] reserve RAM buffer: 00000003b017a000 - 00000003b3ffffff 2011 Sep 28 08:41:46 kernel: [ 5.204338] Switching to clocksource xen 2011 Sep 28 08:41:46 kernel: [ 5.208325] Switched to NOHz mode on CPU #0 2011 Sep 28 08:41:46 kernel: [ 5.208429] Switched to NOHz mode on CPU #1 2011 Sep 28 08:41:46 kernel: [ 5.208432] Switched to NOHz mode on CPU #3 2011 Sep 28 08:41:46 kernel: [ 5.208434] Switched to NOHz mode on CPU #2 2011 Sep 28 08:41:46 kernel: [ 5.210850] pnp: PnP ACPI init 2011 Sep 28 08:41:46 kernel: [ 5.210918] ACPI: bus type pnp registered 2011 Sep 28 08:41:46 kernel: [ 5.211147] pnp 00:00: [bus 00-ff] 2011 Sep 28 08:41:46 kernel: [ 5.211208] pnp 00:00: [io 0x0cf8-0x0cff] 2011 Sep 28 08:41:46 kernel: [ 5.211267] pnp 00:00: [io 0x0000-0x03af window] 2011 Sep 28 08:41:46 kernel: [ 5.211328] pnp 00:00: [io 0x03e0-0x0cf7 window] 2011 Sep 28 08:41:46 kernel: [ 5.212964] pnp 00:00: [io 0x03b0-0x03bb window] 2011 Sep 28 08:41:46 kernel: [ 5.213025] pnp 00:00: [io 0x03c0-0x03df window] 2011 Sep 28 08:41:46 kernel: [ 5.213087] pnp 00:00: [io 0x0d00-0xefff window] 2011 Sep 28 08:41:46 kernel: [ 5.213148] pnp 00:00: [io 0xf000-0xffff window] 2011 Sep 28 08:41:46 kernel: [ 5.213209] pnp 00:00: [mem 0x000a0000-0x000bffff window] 2011 Sep 28 08:41:46 kernel: [ 5.213271] pnp 00:00: [mem 0x000d0000-0x000dffff window] 2011 Sep 28 08:41:46 kernel: [ 5.213334] pnp 00:00: [mem 0xc0000000-0xdfffffff window] 2011 Sep 28 08:41:46 kernel: [ 5.213396] pnp 00:00: [mem 0xf0000000-0xfed8ffff window] 2011 Sep 28 08:41:46 kernel: [ 5.213459] pnp 00:00: [mem 0xfed40000-0xfed44fff] 2011 Sep 28 08:41:46 kernel: [ 5.213574] pnp 00:00: Plug and Play ACPI device, IDs PNP0a08 PNP0a03 (active) 2011 Sep 28 08:41:46 kernel: [ 5.213664] pnp 00:01: [mem 0xfed1c000-0xfed1ffff] 2011 Sep 28 08:41:46 kernel: [ 5.213824] system 00:01: [mem 0xfed1c000-0xfed1ffff] has been reserved 2011 Sep 28 08:41:46 kernel: [ 5.213892] system 00:01: Plug and Play ACPI device, IDs PNP0c01 (active) 2011 Sep 28 08:41:46 kernel: [ 5.214174] pnp 00:02: [dma 4] 2011 Sep 28 08:41:46 kernel: [ 5.214233] pnp 00:02: [io 0x0000-0x000f] 2011 Sep 28 08:41:46 kernel: [ 5.214294] pnp 00:02: [io 0x0081-0x0083] 2011 Sep 28 08:41:46 kernel: [ 5.214353] pnp 00:02: [io 0x0087] 2011 Sep 28 08:41:46 kernel: [ 5.214411] pnp 00:02: [io 0x0089-0x008b] 2011 Sep 28 08:41:46 kernel: [ 5.214471] pnp 00:02: [io 0x008f] 2011 Sep 28 08:41:46 kernel: [ 5.214529] pnp 00:02: [io 0x00c0-0x00df] 2011 Sep 28 08:41:46 kernel: [ 5.214664] pnp 00:02: Plug and Play ACPI device, IDs PNP0200 (active) 2011 Sep 28 08:41:46 kernel: [ 5.214745] pnp 00:03: [io 0x0070-0x0071] 2011 Sep 28 08:41:46 kernel: [ 5.214807] xen: registering gsi 8 triggering 1 polarity 0 2011 Sep 28 08:41:46 kernel: [ 5.214870] xen_map_pirq_gsi: returning irq 8 for gsi 8 2011 Sep 28 08:41:46 kernel: [ 5.214933] xen: --> pirq=8 -> irq=8 (gsi=8) 2011 Sep 28 08:41:46 kernel: [ 5.215001] pnp 00:03: [irq 8] 2011 Sep 28 08:41:46 kernel: [ 5.215134] pnp 00:03: Plug and Play ACPI device, IDs PNP0b00 (active) 2011 Sep 28 08:41:46 kernel: [ 5.215239] pnp 00:04: [io 0x0060] 2011 Sep 28 08:41:46 kernel: [ 5.215298] pnp 00:04: [io 0x0064] 2011 Sep 28 08:41:46 kernel: [ 5.215356] xen: registering gsi 1 triggering 1 polarity 0 2011 Sep 28 08:41:46 kernel: [ 5.215418] xen_map_pirq_gsi: returning irq 1 for gsi 1 2011 Sep 28 08:41:46 kernel: [ 5.215480] xen: --> pirq=1 -> irq=1 (gsi=1) 2011 Sep 28 08:41:46 kernel: [ 5.215543] pnp 00:04: [irq 1] 2011 Sep 28 08:41:46 kernel: [ 5.215681] pnp 00:04: Plug and Play ACPI device, IDs PNP0303 PNP030b (active) 2011 Sep 28 08:41:46 kernel: [ 5.215801] pnp 00:05: [io 0x0061] 2011 Sep 28 08:41:46 kernel: [ 5.215938] pnp 00:05: Plug and Play ACPI device, IDs PNP0800 (active) 2011 Sep 28 08:41:46 kernel: [ 5.216014] pnp 00:06: [io 0x00f0-0x00ff] 2011 Sep 28 08:41:46 kernel: [ 5.216074] xen: registering gsi 13 triggering 1 polarity 0 2011 Sep 28 08:41:46 kernel: [ 5.216137] xen_map_pirq_gsi: returning irq 13 for gsi 13 2011 Sep 28 08:41:46 kernel: [ 5.216199] xen: --> pirq=13 -> irq=13 (gsi=13) 2011 Sep 28 08:41:46 kernel: [ 5.216264] pnp 00:06: [irq 13] 2011 Sep 28 08:41:46 kernel: [ 5.216405] pnp 00:06: Plug and Play ACPI device, IDs PNP0c04 (active) 2011 Sep 28 08:41:46 kernel: [ 5.216571] pnp 00:07: [io 0x0000-0xffffffffffffffff disabled] 2011 Sep 28 08:41:46 kernel: [ 5.216636] pnp 00:07: [io 0x0000-0xffffffffffffffff disabled] 2011 Sep 28 08:41:46 kernel: [ 5.216699] pnp 00:07: [io 0x0a10-0x0a1f] 2011 Sep 28 08:41:46 kernel: [ 5.216881] system 00:07: [io 0x0a10-0x0a1f] has been reserved 2011 Sep 28 08:41:46 kernel: [ 5.216947] system 00:07: Plug and Play ACPI device, IDs PNP0c02 (active) 2011 Sep 28 08:41:46 kernel: [ 5.217280] pnp 00:08: [io 0x03f8-0x03ff] 2011 Sep 28 08:41:46 kernel: [ 5.217342] xen: registering gsi 4 triggering 1 polarity 0 2011 Sep 28 08:41:46 kernel: [ 5.217404] xen_map_pirq_gsi: returning irq 4 for gsi 4 2011 Sep 28 08:41:46 kernel: [ 5.217466] xen: --> pirq=4 -> irq=4 (gsi=4) 2011 Sep 28 08:41:46 kernel: [ 5.217531] pnp 00:08: [irq 4] 2011 Sep 28 08:41:46 kernel: [ 5.217588] pnp 00:08: [dma 0 disabled] 2011 Sep 28 08:41:46 kernel: [ 5.217768] pnp 00:08: Plug and Play ACPI device, IDs PNP0501 (active) 2011 Sep 28 08:41:46 kernel: [ 5.218082] pnp 00:09: [io 0x02f8-0x02ff] 2011 Sep 28 08:41:46 kernel: [ 5.218143] xen: registering gsi 3 triggering 1 polarity 0 2011 Sep 28 08:41:46 kernel: [ 5.218205] xen_map_pirq_gsi: returning irq 3 for gsi 3 2011 Sep 28 08:41:46 kernel: [ 5.218267] xen: --> pirq=3 -> irq=3 (gsi=3) 2011 Sep 28 08:41:46 kernel: [ 5.218331] pnp 00:09: [irq 3] 2011 Sep 28 08:41:46 kernel: [ 5.218388] pnp 00:09: [dma 0 disabled] 2011 Sep 28 08:41:46 kernel: [ 5.218569] pnp 00:09: Plug and Play ACPI device, IDs PNP0501 (active) 2011 Sep 28 08:41:46 kernel: [ 5.218814] pnp 00:0a: [io 0x0010-0x001f] 2011 Sep 28 08:41:46 kernel: [ 5.218874] pnp 00:0a: [io 0x0022-0x003f] 2011 Sep 28 08:41:46 kernel: [ 5.218934] pnp 00:0a: [io 0x0044-0x004f] 2011 Sep 28 08:41:46 kernel: [ 5.218993] pnp 00:0a: [io 0x0050-0x005f] 2011 Sep 28 08:41:46 kernel: [ 5.219053] pnp 00:0a: [io 0x0062-0x0063] 2011 Sep 28 08:41:46 kernel: [ 5.219113] pnp 00:0a: [io 0x0065-0x006f] 2011 Sep 28 08:41:46 kernel: [ 5.219173] pnp 00:0a: [io 0x0072-0x007f] 2011 Sep 28 08:41:46 kernel: [ 5.219233] pnp 00:0a: [io 0x0080] 2011 Sep 28 08:41:46 kernel: [ 5.219291] pnp 00:0a: [io 0x0084-0x0086] 2011 Sep 28 08:41:46 kernel: [ 5.219351] pnp 00:0a: [io 0x0088] 2011 Sep 28 08:41:46 kernel: [ 5.219409] pnp 00:0a: [io 0x008c-0x008e] 2011 Sep 28 08:41:46 kernel: [ 5.219469] pnp 00:0a: [io 0x0090-0x009f] 2011 Sep 28 08:41:46 kernel: [ 5.219529] pnp 00:0a: [io 0x00a2-0x00bf] 2011 Sep 28 08:41:46 kernel: [ 5.219588] pnp 00:0a: [io 0x00e0-0x00ef] 2011 Sep 28 08:41:46 kernel: [ 5.219648] pnp 00:0a: [io 0x0ca2-0x0ca3] 2011 Sep 28 08:41:46 kernel: [ 5.219708] pnp 00:0a: [io 0x0cf8-0x0cff] 2011 Sep 28 08:41:46 kernel: [ 5.219767] pnp 00:0a: [io 0x04d0-0x04d1] 2011 Sep 28 08:41:46 kernel: [ 5.219827] pnp 00:0a: [mem 0x00000400-0x000004ff] 2011 Sep 28 08:41:46 kernel: [ 5.219888] pnp 00:0a: [io 0x0800-0x087f] 2011 Sep 28 08:41:46 kernel: [ 5.219948] pnp 00:0a: [io 0x0000-0xffffffffffffffff disabled] 2011 Sep 28 08:41:46 kernel: [ 5.220012] pnp 00:0a: [io 0x0500-0x057f] 2011 Sep 28 08:41:46 kernel: [ 5.220072] pnp 00:0a: [mem 0xfed1c000-0xfed1ffff] 2011 Sep 28 08:41:46 kernel: [ 5.220133] pnp 00:0a: [mem 0xfed20000-0xfed3ffff] 2011 Sep 28 08:41:46 kernel: [ 5.220194] pnp 00:0a: [mem 0xfed40000-0xfed8ffff] 2011 Sep 28 08:41:46 kernel: [ 5.220406] system 00:0a: [io 0x0ca2-0x0ca3] has been reserved 2011 Sep 28 08:41:46 kernel: [ 5.220471] system 00:0a: [io 0x0cf8-0x0cff] could not be reserved 2011 Sep 28 08:41:46 kernel: [ 5.220537] system 00:0a: [io 0x04d0-0x04d1] has been reserved 2011 Sep 28 08:41:46 kernel: [ 5.220601] system 00:0a: [io 0x0800-0x087f] has been reserved 2011 Sep 28 08:41:46 kernel: [ 5.220665] system 00:0a: [io 0x0500-0x057f] has been reserved 2011 Sep 28 08:41:46 kernel: [ 5.220729] system 00:0a: [mem 0x00000400-0x000004ff] could not be reserved 2011 Sep 28 08:41:46 kernel: [ 5.220795] system 00:0a: [mem 0xfed1c000-0xfed1ffff] has been reserved 2011 Sep 28 08:41:46 kernel: [ 5.220861] system 00:0a: [mem 0xfed20000-0xfed3ffff] has been reserved 2011 Sep 28 08:41:46 kernel: [ 5.220927] system 00:0a: [mem 0xfed40000-0xfed8ffff] has been reserved 2011 Sep 28 08:41:46 kernel: [ 5.220993] system 00:0a: Plug and Play ACPI device, IDs PNP0c02 (active) 2011 Sep 28 08:41:46 kernel: [ 5.221122] pnp 00:0b: [mem 0xfed00000-0xfed003ff] 2011 Sep 28 08:41:46 kernel: [ 5.221225] pnp 00:0b: Plug and Play ACPI device, IDs PNP0103 (active) 2011 Sep 28 08:41:46 kernel: [ 5.221404] pnp 00:0c: [mem 0xfec00000-0xfec00fff] 2011 Sep 28 08:41:46 kernel: [ 5.221467] pnp 00:0c: [mem 0xfee00000-0xfee00fff] 2011 Sep 28 08:41:46 kernel: [ 5.221620] system 00:0c: [mem 0xfec00000-0xfec00fff] could not be reserved 2011 Sep 28 08:41:46 kernel: [ 5.221687] system 00:0c: [mem 0xfee00000-0xfee00fff] has been reserved 2011 Sep 28 08:41:46 kernel: [ 5.221754] system 00:0c: Plug and Play ACPI device, IDs PNP0c02 (active) 2011 Sep 28 08:41:46 kernel: [ 5.221890] pnp 00:0d: [mem 0xe0000000-0xefffffff] 2011 Sep 28 08:41:46 kernel: [ 5.222077] system 00:0d: [mem 0xe0000000-0xefffffff] has been reserved 2011 Sep 28 08:41:46 kernel: [ 5.222145] system 00:0d: Plug and Play ACPI device, IDs PNP0c02 (active) 2011 Sep 28 08:41:46 kernel: [ 5.222391] pnp 00:0e: [mem 0x000c0000-0x000cffff] 2011 Sep 28 08:41:46 kernel: [ 5.222454] pnp 00:0e: [mem 0x000e0000-0x000fffff] 2011 Sep 28 08:41:46 kernel: [ 5.222514] pnp 00:0e: [mem 0xfed90000-0xffffffff] 2011 Sep 28 08:41:46 kernel: [ 5.222702] system 00:0e: [mem 0x000c0000-0x000cffff] could not be reserved 2011 Sep 28 08:41:46 kernel: [ 5.222769] system 00:0e: [mem 0x000e0000-0x000fffff] could not be reserved 2011 Sep 28 08:41:46 kernel: [ 5.222835] system 00:0e: [mem 0xfed90000-0xffffffff] could not be reserved 2011 Sep 28 08:41:46 kernel: [ 5.222903] system 00:0e: Plug and Play ACPI device, IDs PNP0c01 (active) 2011 Sep 28 08:41:46 kernel: [ 5.223170] pnp: PnP ACPI: found 15 devices 2011 Sep 28 08:41:46 kernel: [ 5.223231] ACPI: ACPI bus type pnp unregistered 2011 Sep 28 08:41:46 kernel: [ 5.223294] PnPBIOS: Disabled 2011 Sep 28 08:41:46 kernel: [ 5.228704] PM-Timer failed consistency check (0x0xffffff) - aborting. 2011 Sep 28 08:41:46 kernel: [ 5.228802] PCI: max bus depth: 1 pci_try_num: 2 2011 Sep 28 08:41:46 kernel: [ 5.228990] pci 0000:00:1c.5: BAR 15: assigned [mem 0xc0000000-0xc01fffff 64bit pref] 2011 Sep 28 08:41:46 kernel: [ 5.229076] pci 0000:00:1c.4: BAR 15: assigned [mem 0xc0200000-0xc03fffff 64bit pref] 2011 Sep 28 08:41:46 kernel: [ 5.229162] pci 0000:00:1c.0: BAR 14: assigned [mem 0xc0400000-0xc05fffff] 2011 Sep 28 08:41:46 kernel: [ 5.229230] pci 0000:00:1c.0: BAR 15: assigned [mem 0xc0600000-0xc07fffff 64bit pref] 2011 Sep 28 08:41:46 kernel: [ 5.229317] pci 0000:00:1c.0: BAR 13: assigned [io 0x1000-0x1fff] 2011 Sep 28 08:41:46 kernel: [ 5.229381] pci 0000:00:01.0: PCI bridge to [bus 01-01] 2011 Sep 28 08:41:46 kernel: [ 5.229443] pci 0000:00:01.0: bridge window [io disabled] 2011 Sep 28 08:41:46 kernel: [ 5.229512] pci 0000:00:01.0: bridge window [mem disabled] 2011 Sep 28 08:41:46 kernel: [ 5.229579] pci 0000:00:01.0: bridge window [mem pref disabled] 2011 Sep 28 08:41:46 kernel: [ 5.229651] pci 0000:00:03.0: PCI bridge to [bus 02-02] 2011 Sep 28 08:41:46 kernel: [ 5.229713] pci 0000:00:03.0: bridge window [io disabled] 2011 Sep 28 08:41:46 kernel: [ 5.229782] pci 0000:00:03.0: bridge window [mem disabled] 2011 Sep 28 08:41:46 kernel: [ 5.229848] pci 0000:00:03.0: bridge window [mem pref disabled] 2011 Sep 28 08:41:46 kernel: [ 5.229921] pci 0000:00:07.0: PCI bridge to [bus 03-03] 2011 Sep 28 08:41:46 kernel: [ 5.229982] pci 0000:00:07.0: bridge window [io disabled] 2011 Sep 28 08:41:46 kernel: [ 5.230051] pci 0000:00:07.0: bridge window [mem disabled] 2011 Sep 28 08:41:46 kernel: [ 5.230118] pci 0000:00:07.0: bridge window [mem pref disabled] 2011 Sep 28 08:41:46 kernel: [ 5.230190] pci 0000:00:09.0: PCI bridge to [bus 04-04] 2011 Sep 28 08:41:46 kernel: [ 5.230251] pci 0000:00:09.0: bridge window [io disabled] 2011 Sep 28 08:41:46 kernel: [ 5.230320] pci 0000:00:09.0: bridge window [mem disabled] 2011 Sep 28 08:41:46 kernel: [ 5.230387] pci 0000:00:09.0: bridge window [mem pref disabled] 2011 Sep 28 08:41:46 kernel: [ 5.230459] pci 0000:00:1c.0: PCI bridge to [bus 05-05] 2011 Sep 28 08:41:46 kernel: [ 5.230523] pci 0000:00:1c.0: bridge window [io 0x1000-0x1fff] 2011 Sep 28 08:41:46 kernel: [ 5.230594] pci 0000:00:1c.0: bridge window [mem 0xc0400000-0xc05fffff] 2011 Sep 28 08:41:46 kernel: [ 5.230663] pci 0000:00:1c.0: bridge window [mem 0xc0600000-0xc07fffff 64bit pref] 2011 Sep 28 08:41:46 kernel: [ 5.230757] pci 0000:00:1c.4: PCI bridge to [bus 06-06] 2011 Sep 28 08:41:46 kernel: [ 5.230821] pci 0000:00:1c.4: bridge window [io 0xd000-0xdfff] 2011 Sep 28 08:41:46 kernel: [ 5.230891] pci 0000:00:1c.4: bridge window [mem 0xfbc00000-0xfbcfffff] 2011 Sep 28 08:41:46 kernel: [ 5.230961] pci 0000:00:1c.4: bridge window [mem 0xc0200000-0xc03fffff 64bit pref] 2011 Sep 28 08:41:46 kernel: [ 5.231055] pci 0000:00:1c.5: PCI bridge to [bus 07-07] 2011 Sep 28 08:41:46 kernel: [ 5.231119] pci 0000:00:1c.5: bridge window [io 0xe000-0xefff] 2011 Sep 28 08:41:46 kernel: [ 5.231189] pci 0000:00:1c.5: bridge window [mem 0xfbd00000-0xfbdfffff] 2011 Sep 28 08:41:46 kernel: [ 5.231259] pci 0000:00:1c.5: bridge window [mem 0xc0000000-0xc01fffff 64bit pref] 2011 Sep 28 08:41:46 kernel: [ 5.231353] pci 0000:00:1e.0: PCI bridge to [bus 08-08] 2011 Sep 28 08:41:46 kernel: [ 5.231414] pci 0000:00:1e.0: bridge window [io disabled] 2011 Sep 28 08:41:46 kernel: [ 5.231484] pci 0000:00:1e.0: bridge window [mem 0xfaf00000-0xfb7fffff] 2011 Sep 28 08:41:46 kernel: [ 5.231554] pci 0000:00:1e.0: bridge window [mem 0xf9000000-0xf9ffffff 64bit pref] 2011 Sep 28 08:41:46 kernel: [ 5.231660] pci 0000:00:01.0: setting latency timer to 64 2011 Sep 28 08:41:46 kernel: [ 5.231735] pci 0000:00:03.0: setting latency timer to 64 2011 Sep 28 08:41:46 kernel: [ 5.231809] pci 0000:00:07.0: setting latency timer to 64 2011 Sep 28 08:41:46 kernel: [ 5.231884] pci 0000:00:09.0: setting latency timer to 64 2011 Sep 28 08:41:46 kernel: [ 5.231955] pci 0000:00:1c.0: enabling device (0104 -> 0107) 2011 Sep 28 08:41:46 kernel: [ 5.232021] xen: registering gsi 17 triggering 0 polarity 1 2011 Sep 28 08:41:46 kernel: [ 5.232093] xen: --> pirq=17 -> irq=17 (gsi=17) 2011 Sep 28 08:41:46 kernel: [ 5.232158] pci 0000:00:1c.0: PCI INT A -> GSI 17 (level, low) -> IRQ 17 2011 Sep 28 08:41:46 kernel: [ 5.232228] pci 0000:00:1c.0: setting latency timer to 64 2011 Sep 28 08:41:46 kernel: [ 5.232299] xen: registering gsi 17 triggering 0 polarity 1 2011 Sep 28 08:41:46 kernel: [ 5.232362] xen_map_pirq_gsi: returning irq 17 for gsi 17 2011 Sep 28 08:41:46 kernel: [ 5.232424] xen: --> pirq=17 -> irq=17 (gsi=17) 2011 Sep 28 08:41:46 kernel: [ 5.232485] Already setup the GSI :17 2011 Sep 28 08:41:46 kernel: [ 5.232545] pci 0000:00:1c.4: PCI INT A -> GSI 17 (level, low) -> IRQ 17 2011 Sep 28 08:41:46 kernel: [ 5.232614] pci 0000:00:1c.4: setting latency timer to 64 2011 Sep 28 08:41:46 kernel: [ 5.232683] xen: registering gsi 16 triggering 0 polarity 1 2011 Sep 28 08:41:46 kernel: [ 5.232757] xen: --> pirq=16 -> irq=16 (gsi=16) 2011 Sep 28 08:41:46 kernel: [ 5.234412] pci 0000:00:1c.5: PCI INT B -> GSI 16 (level, low) -> IRQ 16 2011 Sep 28 08:41:46 kernel: [ 5.234482] pci 0000:00:1c.5: setting latency timer to 64 2011 Sep 28 08:41:46 kernel: [ 5.234556] pci 0000:00:1e.0: setting latency timer to 64 2011 Sep 28 08:41:46 kernel: [ 5.234622] pci_bus 0000:00: resource 4 [io 0x0000-0x03af] 2011 Sep 28 08:41:46 kernel: [ 5.234685] pci_bus 0000:00: resource 5 [io 0x03e0-0x0cf7] 2011 Sep 28 08:41:46 kernel: [ 5.234747] pci_bus 0000:00: resource 6 [io 0x03b0-0x03bb] 2011 Sep 28 08:41:46 kernel: [ 5.234811] pci_bus 0000:00: resource 7 [io 0x03c0-0x03df] 2011 Sep 28 08:41:46 kernel: [ 5.234873] pci_bus 0000:00: resource 8 [io 0x0d00-0xefff] 2011 Sep 28 08:41:46 kernel: [ 5.234936] pci_bus 0000:00: resource 9 [io 0xf000-0xffff] 2011 Sep 28 08:41:46 kernel: [ 5.234999] pci_bus 0000:00: resource 10 [mem 0x000a0000-0x000bffff] 2011 Sep 28 08:41:46 kernel: [ 5.235064] pci_bus 0000:00: resource 11 [mem 0x000d0000-0x000dffff] 2011 Sep 28 08:41:46 kernel: [ 5.235129] pci_bus 0000:00: resource 12 [mem 0xc0000000-0xdfffffff] 2011 Sep 28 08:41:46 kernel: [ 5.235194] pci_bus 0000:00: resource 13 [mem 0xf0000000-0xfed8ffff] 2011 Sep 28 08:41:46 kernel: [ 5.235259] pci_bus 0000:05: resource 0 [io 0x1000-0x1fff] 2011 Sep 28 08:41:46 kernel: [ 5.235322] pci_bus 0000:05: resource 1 [mem 0xc0400000-0xc05fffff] 2011 Sep 28 08:41:46 kernel: [ 5.235386] pci_bus 0000:05: resource 2 [mem 0xc0600000-0xc07fffff 64bit pref] 2011 Sep 28 08:41:46 kernel: [ 5.235470] pci_bus 0000:06: resource 0 [io 0xd000-0xdfff] 2011 Sep 28 08:41:46 kernel: [ 5.235533] pci_bus 0000:06: resource 1 [mem 0xfbc00000-0xfbcfffff] 2011 Sep 28 08:41:46 kernel: [ 5.235597] pci_bus 0000:06: resource 2 [mem 0xc0200000-0xc03fffff 64bit pref] 2011 Sep 28 08:41:46 kernel: [ 5.235681] pci_bus 0000:07: resource 0 [io 0xe000-0xefff] 2011 Sep 28 08:41:46 kernel: [ 5.235743] pci_bus 0000:07: resource 1 [mem 0xfbd00000-0xfbdfffff] 2011 Sep 28 08:41:46 kernel: [ 5.235808] pci_bus 0000:07: resource 2 [mem 0xc0000000-0xc01fffff 64bit pref] 2011 Sep 28 08:41:46 kernel: [ 5.235891] pci_bus 0000:08: resource 1 [mem 0xfaf00000-0xfb7fffff] 2011 Sep 28 08:41:46 kernel: [ 5.235956] pci_bus 0000:08: resource 2 [mem 0xf9000000-0xf9ffffff 64bit pref] 2011 Sep 28 08:41:46 kernel: [ 5.236039] pci_bus 0000:08: resource 4 [io 0x0000-0x03af] 2011 Sep 28 08:41:46 kernel: [ 5.236102] pci_bus 0000:08: resource 5 [io 0x03e0-0x0cf7] 2011 Sep 28 08:41:46 kernel: [ 5.236165] pci_bus 0000:08: resource 6 [io 0x03b0-0x03bb] 2011 Sep 28 08:41:46 kernel: [ 5.236227] pci_bus 0000:08: resource 7 [io 0x03c0-0x03df] 2011 Sep 28 08:41:46 kernel: [ 5.236290] pci_bus 0000:08: resource 8 [io 0x0d00-0xefff] 2011 Sep 28 08:41:46 kernel: [ 5.236353] pci_bus 0000:08: resource 9 [io 0xf000-0xffff] 2011 Sep 28 08:41:46 kernel: [ 5.236416] pci_bus 0000:08: resource 10 [mem 0x000a0000-0x000bffff] 2011 Sep 28 08:41:46 kernel: [ 5.236480] pci_bus 0000:08: resource 11 [mem 0x000d0000-0x000dffff] 2011 Sep 28 08:41:46 kernel: [ 5.236546] pci_bus 0000:08: resource 12 [mem 0xc0000000-0xdfffffff] 2011 Sep 28 08:41:46 kernel: [ 5.236610] pci_bus 0000:08: resource 13 [mem 0xf0000000-0xfed8ffff] 2011 Sep 28 08:41:46 kernel: [ 5.236675] pci_bus 0000:ff: resource 0 [io 0x0000-0xffff] 2011 Sep 28 08:41:46 kernel: [ 5.236737] pci_bus 0000:ff: resource 1 [mem 0x00000000-0xffffffffff] 2011 Sep 28 08:41:46 kernel: [ 5.236829] NET: Registered protocol family 2 2011 Sep 28 08:41:46 kernel: [ 5.236945] IP route cache hash table entries: 32768 (order: 5, 131072 bytes) 2011 Sep 28 08:41:46 kernel: [ 5.237219] TCP established hash table entries: 131072 (order: 8, 1048576 bytes) 2011 Sep 28 08:41:46 kernel: [ 5.237551] TCP bind hash table entries: 65536 (order: 7, 524288 bytes) 2011 Sep 28 08:41:46 kernel: [ 5.237726] TCP: Hash tables configured (established 131072 bind 65536) 2011 Sep 28 08:41:46 kernel: [ 5.237793] TCP reno registered 2011 Sep 28 08:41:46 kernel: [ 5.237852] UDP hash table entries: 512 (order: 2, 16384 bytes) 2011 Sep 28 08:41:46 kernel: [ 5.237920] UDP-Lite hash table entries: 512 (order: 2, 16384 bytes) 2011 Sep 28 08:41:46 kernel: [ 5.238061] NET: Registered protocol family 1 2011 Sep 28 08:41:46 kernel: [ 5.238419] pci 0000:08:01.0: Boot video device 2011 Sep 28 08:41:46 kernel: [ 5.238538] PCI: CLS 256 bytes, default 64 2011 Sep 28 08:41:46 kernel: [ 5.238633] Trying to unpack rootfs image as initramfs... 2011 Sep 28 08:41:46 kernel: [ 7.302462] Freeing initrd memory: 9288k freed 2011 Sep 28 08:41:46 kernel: [ 7.305303] audit: initializing netlink socket (disabled) 2011 Sep 28 08:41:46 kernel: [ 7.305382] type=2000 audit(1317199305.245:1): initialized 2011 Sep 28 08:41:46 kernel: [ 7.320585] highmem bounce pool size: 64 pages 2011 Sep 28 08:41:46 kernel: [ 7.320657] HugeTLB registered 2 MB page size, pre-allocated 0 pages 2011 Sep 28 08:41:46 kernel: [ 7.322770] squashfs: version 4.0 (2009/01/31) Phillip Lougher 2011 Sep 28 08:41:46 kernel: [ 7.322988] msgmni has been set to 911 2011 Sep 28 08:41:46 kernel: [ 7.323400] Block layer SCSI generic (bsg) driver version 0.4 loaded (major 253) 2011 Sep 28 08:41:46 kernel: [ 7.323523] io scheduler noop registered 2011 Sep 28 08:41:46 kernel: [ 7.323583] io scheduler deadline registered 2011 Sep 28 08:41:46 kernel: [ 7.323655] io scheduler cfq registered (default) 2011 Sep 28 08:41:46 kernel: [ 7.324276] pcieport 0000:00:1c.0: setting latency timer to 64 2011 Sep 28 08:41:46 kernel: [ 7.324565] pcieport 0000:00:1c.4: setting latency timer to 64 2011 Sep 28 08:41:46 kernel: [ 7.324826] pcieport 0000:00:1c.5: setting latency timer to 64 2011 Sep 28 08:41:46 kernel: [ 7.325102] pci_hotplug: PCI Hot Plug PCI Core version: 0.5 2011 Sep 28 08:41:46 kernel: [ 7.325185] pciehp: PCI Express Hot Plug Controller Driver version: 0.4 2011 Sep 28 08:41:46 kernel: [ 7.325328] input: Power Button as /devices/LNXSYSTM:00/device:00/PNP0C0C:00/input/input0 2011 Sep 28 08:41:46 kernel: [ 7.325415] ACPI: Power Button [PWRB] 2011 Sep 28 08:41:46 kernel: [ 7.325510] input: Power Button as /devices/LNXSYSTM:00/LNXPWRBN:00/input/input1 2011 Sep 28 08:41:46 kernel: [ 7.325595] ACPI: Power Button [PWRF] 2011 Sep 28 08:41:46 kernel: [ 7.326054] ACPI: acpi_idle registered with cpuidle 2011 Sep 28 08:41:46 kernel: [ 7.329127] APEI: Can not request iomem region <00000000bf7b334a-00000000bf7b334c> for GARs. 2011 Sep 28 08:41:46 kernel: [ 7.329259] isapnp: Scanning for PnP cards... 2011 Sep 28 08:41:46 kernel: [ 7.683533] isapnp: No Plug & Play device found 2011 Sep 28 08:41:46 kernel: [ 7.683654] Event-channel device installed. 2011 Sep 28 08:41:46 kernel: [ 7.683980] Serial: 8250/16550 driver, 32 ports, IRQ sharing enabled 2011 Sep 28 08:41:46 kernel: [ 7.704615] serial8250: ttyS0 at I/O 0x3f8 (irq = 4) is a 16550A 2011 Sep 28 08:41:46 kernel: [ 7.725303] serial8250: ttyS1 at I/O 0x2f8 (irq = 3) is a 16550A 2011 Sep 28 08:41:46 kernel: [ 7.869280] 00:08: ttyS0 at I/O 0x3f8 (irq = 4) is a 16550A 2011 Sep 28 08:41:46 kernel: [ 7.893166] 00:09: ttyS1 at I/O 0x2f8 (irq = 3) is a 16550A 2011 Sep 28 08:41:46 kernel: [ 7.896810] hpet_acpi_add: no address or irqs in _CRS 2011 Sep 28 08:41:46 kernel: [ 7.896884] Linux agpgart interface v0.103 2011 Sep 28 08:41:46 kernel: [ 7.898084] brd: module loaded 2011 Sep 28 08:41:46 kernel: [ 7.898664] loop: module loaded 2011 Sep 28 08:41:46 kernel: [ 7.898914] ata_piix 0000:00:1f.2: version 2.13 2011 Sep 28 08:41:46 kernel: [ 7.898990] xen: registering gsi 19 triggering 0 polarity 1 2011 Sep 28 08:41:46 kernel: [ 7.899061] xen: --> pirq=19 -> irq=19 (gsi=19) 2011 Sep 28 08:41:46 kernel: [ 7.899129] ata_piix 0000:00:1f.2: PCI INT B -> GSI 19 (level, low) -> IRQ 19 2011 Sep 28 08:41:46 kernel: [ 7.899201] ata_piix 0000:00:1f.2: MAP [ P0 P2 P1 P3 ] 2011 Sep 28 08:41:46 kernel: [ 7.899481] ata_piix 0000:00:1f.2: setting latency timer to 64 2011 Sep 28 08:41:46 kernel: [ 7.899815] scsi0 : ata_piix 2011 Sep 28 08:41:46 kernel: [ 7.899962] scsi1 : ata_piix 2011 Sep 28 08:41:46 kernel: [ 7.901507] ata1: SATA max UDMA/133 cmd 0xc000 ctl 0xbc00 bmdma 0xb480 irq 19 2011 Sep 28 08:41:46 kernel: [ 7.901580] ata2: SATA max UDMA/133 cmd 0xb880 ctl 0xb800 bmdma 0xb488 irq 19 2011 Sep 28 08:41:46 kernel: [ 7.901688] xen: registering gsi 19 triggering 0 polarity 1 2011 Sep 28 08:41:46 kernel: [ 7.901752] xen_map_pirq_gsi: returning irq 19 for gsi 19 2011 Sep 28 08:41:46 kernel: [ 7.901814] xen: --> pirq=19 -> irq=19 (gsi=19) 2011 Sep 28 08:41:46 kernel: [ 7.901877] Already setup the GSI :19 2011 Sep 28 08:41:46 kernel: [ 7.901936] ata_piix 0000:00:1f.5: PCI INT B -> GSI 19 (level, low) -> IRQ 19 2011 Sep 28 08:41:46 kernel: [ 7.902008] ata_piix 0000:00:1f.5: MAP [ P0 -- P1 -- ] 2011 Sep 28 08:41:46 kernel: [ 7.902280] ata_piix 0000:00:1f.5: setting latency timer to 64 2011 Sep 28 08:41:46 kernel: [ 7.902542] scsi2 : ata_piix 2011 Sep 28 08:41:46 kernel: [ 7.902675] scsi3 : ata_piix 2011 Sep 28 08:41:46 kernel: [ 7.903828] ata3: SATA max UDMA/133 cmd 0xb000 ctl 0xac00 bmdma 0xa480 irq 19 2011 Sep 28 08:41:46 kernel: [ 7.903898] ata4: SATA max UDMA/133 cmd 0xa880 ctl 0xa800 bmdma 0xa488 irq 19 2011 Sep 28 08:41:46 kernel: [ 7.904301] Fixed MDIO Bus: probed 2011 Sep 28 08:41:46 kernel: [ 7.904387] PPP generic driver version 2.4.2 2011 Sep 28 08:41:46 kernel: [ 7.904850] tun: Universal TUN/TAP device driver, 1.6 2011 Sep 28 08:41:46 kernel: [ 7.904914] tun: (C) 1999-2004 Max Krasnyansky <maxk@qualcomm.com> 2011 Sep 28 08:41:46 kernel: [ 7.905054] ehci_hcd: USB 2.0 'Enhanced' Host Controller (EHCI) Driver 2011 Sep 28 08:41:46 kernel: [ 7.905139] xen: registering gsi 18 triggering 0 polarity 1 2011 Sep 28 08:41:46 kernel: [ 7.905210] xen: --> pirq=18 -> irq=18 (gsi=18) 2011 Sep 28 08:41:46 kernel: [ 7.905275] ehci_hcd 0000:00:1a.7: PCI INT C -> GSI 18 (level, low) -> IRQ 18 2011 Sep 28 08:41:46 kernel: [ 7.905357] ehci_hcd 0000:00:1a.7: setting latency timer to 64 2011 Sep 28 08:41:46 kernel: [ 7.905424] ehci_hcd 0000:00:1a.7: EHCI Host Controller 2011 Sep 28 08:41:46 kernel: [ 7.905515] ehci_hcd 0000:00:1a.7: new USB bus registered, assigned bus number 1 2011 Sep 28 08:41:46 kernel: [ 7.905649] ehci_hcd 0000:00:1a.7: debug port 1 2011 Sep 28 08:41:46 kernel: [ 7.909591] ehci_hcd 0000:00:1a.7: cache line size of 256 is not supported 2011 Sep 28 08:41:46 kernel: [ 7.909678] ehci_hcd 0000:00:1a.7: irq 18, io mem 0xfbeda000 2011 Sep 28 08:41:46 kernel: [ 7.924531] ehci_hcd 0000:00:1a.7: USB 2.0 started, EHCI 1.00 2011 Sep 28 08:41:46 kernel: [ 7.924727] hub 1-0:1.0: USB hub found 2011 Sep 28 08:41:46 kernel: [ 7.924790] hub 1-0:1.0: 6 ports detected 2011 Sep 28 08:41:46 kernel: [ 7.924938] xen: registering gsi 23 triggering 0 polarity 1 2011 Sep 28 08:41:46 kernel: [ 7.925009] xen: --> pirq=23 -> irq=23 (gsi=23) 2011 Sep 28 08:41:46 kernel: [ 7.925074] ehci_hcd 0000:00:1d.7: PCI INT A -> GSI 23 (level, low) -> IRQ 23 2011 Sep 28 08:41:46 kernel: [ 7.925156] ehci_hcd 0000:00:1d.7: setting latency timer to 64 2011 Sep 28 08:41:46 kernel: [ 7.925223] ehci_hcd 0000:00:1d.7: EHCI Host Controller 2011 Sep 28 08:41:46 kernel: [ 7.925315] ehci_hcd 0000:00:1d.7: new USB bus registered, assigned bus number 2 2011 Sep 28 08:41:46 kernel: [ 7.925447] ehci_hcd 0000:00:1d.7: debug port 1 2011 Sep 28 08:41:46 kernel: [ 7.929396] ehci_hcd 0000:00:1d.7: cache line size of 256 is not supported 2011 Sep 28 08:41:46 kernel: [ 7.929482] ehci_hcd 0000:00:1d.7: irq 23, io mem 0xfbed8000 2011 Sep 28 08:41:46 kernel: [ 7.944531] ehci_hcd 0000:00:1d.7: USB 2.0 started, EHCI 1.00 2011 Sep 28 08:41:46 kernel: [ 7.944716] hub 2-0:1.0: USB hub found 2011 Sep 28 08:41:46 kernel: [ 7.944779] hub 2-0:1.0: 6 ports detected 2011 Sep 28 08:41:46 kernel: [ 7.944923] ohci_hcd: USB 1.1 'Open' Host Controller (OHCI) Driver 2011 Sep 28 08:41:46 kernel: [ 7.945001] uhci_hcd: USB Universal Host Controller Interface driver 2011 Sep 28 08:41:46 kernel: [ 7.945094] xen: registering gsi 16 triggering 0 polarity 1 2011 Sep 28 08:41:46 kernel: [ 7.945157] xen_map_pirq_gsi: returning irq 16 for gsi 16 2011 Sep 28 08:41:46 kernel: [ 7.945219] xen: --> pirq=16 -> irq=16 (gsi=16) 2011 Sep 28 08:41:46 kernel: [ 7.945282] Already setup the GSI :16 2011 Sep 28 08:41:46 kernel: [ 7.945341] uhci_hcd 0000:00:1a.0: PCI INT A -> GSI 16 (level, low) -> IRQ 16 2011 Sep 28 08:41:46 kernel: [ 7.945414] uhci_hcd 0000:00:1a.0: setting latency timer to 64 2011 Sep 28 08:41:46 kernel: [ 7.945480] uhci_hcd 0000:00:1a.0: UHCI Host Controller 2011 Sep 28 08:41:46 kernel: [ 7.945580] uhci_hcd 0000:00:1a.0: new USB bus registered, assigned bus number 3 2011 Sep 28 08:41:46 kernel: [ 7.945715] uhci_hcd 0000:00:1a.0: irq 16, io base 0x0000cc00 2011 Sep 28 08:41:46 kernel: [ 7.945906] hub 3-0:1.0: USB hub found 2011 Sep 28 08:41:46 kernel: [ 7.945969] hub 3-0:1.0: 2 ports detected 2011 Sep 28 08:41:46 kernel: [ 7.946108] xen: registering gsi 21 triggering 0 polarity 1 2011 Sep 28 08:41:46 kernel: [ 7.946178] xen: --> pirq=21 -> irq=21 (gsi=21) 2011 Sep 28 08:41:46 kernel: [ 7.946244] uhci_hcd 0000:00:1a.1: PCI INT B -> GSI 21 (level, low) -> IRQ 21 2011 Sep 28 08:41:46 kernel: [ 7.946317] uhci_hcd 0000:00:1a.1: setting latency timer to 64 2011 Sep 28 08:41:46 kernel: [ 7.946382] uhci_hcd 0000:00:1a.1: UHCI Host Controller 2011 Sep 28 08:41:46 kernel: [ 7.946477] uhci_hcd 0000:00:1a.1: new USB bus registered, assigned bus number 4 2011 Sep 28 08:41:46 kernel: [ 7.946608] uhci_hcd 0000:00:1a.1: irq 21, io base 0x0000c880 2011 Sep 28 08:41:46 kernel: [ 7.946803] hub 4-0:1.0: USB hub found 2011 Sep 28 08:41:46 kernel: [ 7.946865] hub 4-0:1.0: 2 ports detected 2011 Sep 28 08:41:46 kernel: [ 7.947000] xen: registering gsi 19 triggering 0 polarity 1 2011 Sep 28 08:41:46 kernel: [ 7.947064] xen_map_pirq_gsi: returning irq 19 for gsi 19 2011 Sep 28 08:41:46 kernel: [ 7.947126] xen: --> pirq=19 -> irq=19 (gsi=19) 2011 Sep 28 08:41:46 kernel: [ 7.947187] Already setup the GSI :19 2011 Sep 28 08:41:46 kernel: [ 7.947247] uhci_hcd 0000:00:1a.2: PCI INT D -> GSI 19 (level, low) -> IRQ 19 2011 Sep 28 08:41:46 kernel: [ 7.947319] uhci_hcd 0000:00:1a.2: setting latency timer to 64 2011 Sep 28 08:41:46 kernel: [ 7.947386] uhci_hcd 0000:00:1a.2: UHCI Host Controller 2011 Sep 28 08:41:46 kernel: [ 7.947477] uhci_hcd 0000:00:1a.2: new USB bus registered, assigned bus number 5 2011 Sep 28 08:41:46 kernel: [ 7.947592] uhci_hcd 0000:00:1a.2: irq 19, io base 0x0000c800 2011 Sep 28 08:41:46 kernel: [ 7.947787] hub 5-0:1.0: USB hub found 2011 Sep 28 08:41:46 kernel: [ 7.947850] hub 5-0:1.0: 2 ports detected 2011 Sep 28 08:41:46 kernel: [ 7.947989] xen: registering gsi 23 triggering 0 polarity 1 2011 Sep 28 08:41:46 kernel: [ 7.949472] xen_map_pirq_gsi: returning irq 23 for gsi 23 2011 Sep 28 08:41:46 kernel: [ 7.949534] xen: --> pirq=23 -> irq=23 (gsi=23) 2011 Sep 28 08:41:46 kernel: [ 7.949607] Already setup the GSI :23 2011 Sep 28 08:41:46 kernel: [ 7.949666] uhci_hcd 0000:00:1d.0: PCI INT A -> GSI 23 (level, low) -> IRQ 23 2011 Sep 28 08:41:46 kernel: [ 7.949739] uhci_hcd 0000:00:1d.0: setting latency timer to 64 2011 Sep 28 08:41:46 kernel: [ 7.949805] uhci_hcd 0000:00:1d.0: UHCI Host Controller 2011 Sep 28 08:41:46 kernel: [ 7.949901] uhci_hcd 0000:00:1d.0: new USB bus registered, assigned bus number 6 2011 Sep 28 08:41:46 kernel: [ 7.950017] uhci_hcd 0000:00:1d.0: irq 23, io base 0x0000c480 2011 Sep 28 08:41:46 kernel: [ 7.950210] hub 6-0:1.0: USB hub found 2011 Sep 28 08:41:46 kernel: [ 7.950273] hub 6-0:1.0: 2 ports detected 2011 Sep 28 08:41:46 kernel: [ 7.950410] xen: registering gsi 19 triggering 0 polarity 1 2011 Sep 28 08:41:46 kernel: [ 7.950473] xen_map_pirq_gsi: returning irq 19 for gsi 19 2011 Sep 28 08:41:46 kernel: [ 7.950536] xen: --> pirq=19 -> irq=19 (gsi=19) 2011 Sep 28 08:41:46 kernel: [ 7.950598] Already setup the GSI :19 2011 Sep 28 08:41:46 kernel: [ 7.950657] uhci_hcd 0000:00:1d.1: PCI INT B -> GSI 19 (level, low) -> IRQ 19 2011 Sep 28 08:41:46 kernel: [ 7.950732] uhci_hcd 0000:00:1d.1: setting latency timer to 64 2011 Sep 28 08:41:46 kernel: [ 7.950798] uhci_hcd 0000:00:1d.1: UHCI Host Controller 2011 Sep 28 08:41:46 kernel: [ 7.950898] uhci_hcd 0000:00:1d.1: new USB bus registered, assigned bus number 7 2011 Sep 28 08:41:46 kernel: [ 7.951014] uhci_hcd 0000:00:1d.1: irq 19, io base 0x0000c400 2011 Sep 28 08:41:46 kernel: [ 7.951209] hub 7-0:1.0: USB hub found 2011 Sep 28 08:41:46 kernel: [ 7.951272] hub 7-0:1.0: 2 ports detected 2011 Sep 28 08:41:46 kernel: [ 7.951408] xen: registering gsi 18 triggering 0 polarity 1 2011 Sep 28 08:41:46 kernel: [ 7.951472] xen_map_pirq_gsi: returning irq 18 for gsi 18 2011 Sep 28 08:41:46 kernel: [ 7.951534] xen: --> pirq=18 -> irq=18 (gsi=18) 2011 Sep 28 08:41:46 kernel: [ 7.951595] Already setup the GSI :18 2011 Sep 28 08:41:46 kernel: [ 7.951654] uhci_hcd 0000:00:1d.2: PCI INT C -> GSI 18 (level, low) -> IRQ 18 2011 Sep 28 08:41:46 kernel: [ 7.951726] uhci_hcd 0000:00:1d.2: setting latency timer to 64 2011 Sep 28 08:41:46 kernel: [ 7.951793] uhci_hcd 0000:00:1d.2: UHCI Host Controller 2011 Sep 28 08:41:46 kernel: [ 7.951887] uhci_hcd 0000:00:1d.2: new USB bus registered, assigned bus number 8 2011 Sep 28 08:41:46 kernel: [ 7.952002] uhci_hcd 0000:00:1d.2: irq 18, io base 0x0000c080 2011 Sep 28 08:41:46 kernel: [ 7.952207] hub 8-0:1.0: USB hub found 2011 Sep 28 08:41:46 kernel: [ 7.952270] hub 8-0:1.0: 2 ports detected 2011 Sep 28 08:41:46 kernel: [ 7.952466] i8042: PNP: PS/2 Controller [PNP0303:PS2K] at 0x60,0x64 irq 1 2011 Sep 28 08:41:46 kernel: [ 7.952533] i8042: PNP: PS/2 appears to have AUX port disabled, if this is incorrect please boot with i8042.nopnp 2011 Sep 28 08:41:46 kernel: [ 7.953361] serio: i8042 KBD port at 0x60,0x64 irq 1 2011 Sep 28 08:41:46 kernel: [ 7.953513] mousedev: PS/2 mouse device common for all mice 2011 Sep 28 08:41:46 kernel: [ 7.953690] rtc_cmos 00:03: RTC can wake from S4 2011 Sep 28 08:41:46 kernel: [ 7.953873] rtc_cmos 00:03: rtc core: registered rtc_cmos as rtc0 2011 Sep 28 08:41:46 kernel: [ 7.953972] rtc0: alarms up to one month, y3k, 114 bytes nvram 2011 Sep 28 08:41:46 kernel: [ 7.954100] device-mapper: uevent: version 1.0.3 2011 Sep 28 08:41:46 kernel: [ 7.954224] device-mapper: ioctl: 4.20.0-ioctl (2011-02-02) initialised: dm-devel@redhat.com 2011 Sep 28 08:41:46 kernel: [ 7.954411] device-mapper: multipath: version 1.3.0 loaded 2011 Sep 28 08:41:46 kernel: [ 7.954475] device-mapper: multipath round-robin: version 1.0.0 loaded 2011 Sep 28 08:41:46 kernel: [ 7.954626] EISA: Probing bus 0 at eisa.0 2011 Sep 28 08:41:46 kernel: [ 7.954686] EISA: Cannot allocate resource for mainboard 2011 Sep 28 08:41:46 kernel: [ 7.954748] Cannot allocate resource for EISA slot 1 2011 Sep 28 08:41:46 kernel: [ 7.954809] Cannot allocate resource for EISA slot 2 2011 Sep 28 08:41:46 kernel: [ 7.954870] Cannot allocate resource for EISA slot 3 2011 Sep 28 08:41:46 kernel: [ 7.954932] Cannot allocate resource for EISA slot 4 2011 Sep 28 08:41:46 kernel: [ 7.954993] Cannot allocate resource for EISA slot 5 2011 Sep 28 08:41:46 kernel: [ 7.955054] Cannot allocate resource for EISA slot 6 2011 Sep 28 08:41:46 kernel: [ 7.955115] Cannot allocate resource for EISA slot 7 2011 Sep 28 08:41:46 kernel: [ 7.955176] Cannot allocate resource for EISA slot 8 2011 Sep 28 08:41:46 kernel: [ 7.955237] EISA: Detected 0 cards. 2011 Sep 28 08:41:46 kernel: [ 7.955304] cpufreq-nforce2: No nForce2 chipset. 2011 Sep 28 08:41:46 kernel: [ 7.955365] cpuidle: using governor ladder 2011 Sep 28 08:41:46 kernel: [ 7.955424] cpuidle: using governor menu 2011 Sep 28 08:41:46 kernel: [ 7.955483] EFI Variables Facility v0.08 2004-May-17 2011 Sep 28 08:41:46 kernel: [ 7.955799] TCP cubic registered 2011 Sep 28 08:41:46 kernel: [ 7.955972] NET: Registered protocol family 10 2011 Sep 28 08:41:46 kernel: [ 7.956623] NET: Registered protocol family 17 2011 Sep 28 08:41:46 kernel: [ 7.956722] Bridge firewalling registered 2011 Sep 28 08:41:46 kernel: [ 7.956784] 802.1Q VLAN Support v1.8 2011 Sep 28 08:41:46 kernel: [ 7.957105] sctp: Hash tables configured (established 65536 bind 65536) 2011 Sep 28 08:41:46 kernel: [ 7.957329] Using IPI No-Shortcut mode 2011 Sep 28 08:41:46 kernel: [ 7.957455] PM: Hibernation image not present or could not be loaded. 2011 Sep 28 08:41:46 kernel: [ 7.957524] registered taskstats version 1 2011 Sep 28 08:41:46 kernel: [ 7.958520] Magic number: 11:103:676 2011 Sep 28 08:41:46 kernel: [ 7.958673] rtc_cmos 00:03: setting system clock to 2011-09-28 08:41:45 UTC (1317199305) 2011 Sep 28 08:41:46 kernel: [ 7.959681] BIOS EDD facility v0.16 2004-Jun-25, 0 devices found 2011 Sep 28 08:41:46 kernel: [ 7.959746] EDD information not available. 2011 Sep 28 08:41:46 kernel: [ 7.974381] input: AT Translated Set 2 keyboard as /devices/platform/i8042/serio0/input/input2 2011 Sep 28 08:41:46 kernel: [ 8.231881] ata3: SATA link down (SStatus 0 SControl 300) 2011 Sep 28 08:41:46 kernel: [ 8.243273] ata4: SATA link down (SStatus 0 SControl 300) 2011 Sep 28 08:41:46 kernel: [ 8.348536] usb 2-2: new high speed USB device number 2 using ehci_hcd 2011 Sep 28 08:41:46 kernel: [ 8.696634] ata2.00: SATA link up 3.0 Gbps (SStatus 123 SControl 300) 2011 Sep 28 08:41:46 kernel: [ 8.696716] ata2.01: SATA link down (SStatus 0 SControl 300) 2011 Sep 28 08:41:46 kernel: [ 8.696948] ata1.00: SATA link up 3.0 Gbps (SStatus 123 SControl 300) 2011 Sep 28 08:41:46 kernel: [ 8.697033] ata1.01: SATA link up 3.0 Gbps (SStatus 123 SControl 300) 2011 Sep 28 08:41:46 kernel: [ 8.705091] ata2.00: ATA-8: ST1000DL002-9TT153, CC32, max UDMA/133 2011 Sep 28 08:41:46 kernel: [ 8.705156] ata2.00: 1953525168 sectors, multi 16: LBA48 NCQ (depth 0/32) 2011 Sep 28 08:41:46 kernel: [ 8.712973] ata1.00: ATA-8: ST1000DL002-9TT153, CC32, max UDMA/133 2011 Sep 28 08:41:46 kernel: [ 8.713038] ata1.00: 1953525168 sectors, multi 16: LBA48 NCQ (depth 0/32) 2011 Sep 28 08:41:46 kernel: [ 8.713393] ata1.01: ATA-8: ST31000524AS, JC4B, max UDMA/133 2011 Sep 28 08:41:46 kernel: [ 8.713463] ata1.01: 1953525168 sectors, multi 16: LBA48 NCQ (depth 0/32) 2011 Sep 28 08:41:46 kernel: [ 8.720651] usb 4-1: new full speed USB device number 2 using uhci_hcd 2011 Sep 28 08:41:46 kernel: [ 8.721199] ata2.00: configured for UDMA/133 2011 Sep 28 08:41:46 kernel: [ 8.728955] ata1.00: configured for UDMA/133 2011 Sep 28 08:41:46 kernel: [ 8.744961] ata1.01: configured for UDMA/133 2011 Sep 28 08:41:46 kernel: [ 8.745159] scsi 0:0:0:0: Direct-Access ATA ST1000DL002-9TT1 CC32 PQ: 0 ANSI: 5 2011 Sep 28 08:41:46 kernel: [ 8.745381] sd 0:0:0:0: Attached scsi generic sg0 type 0 2011 Sep 28 08:41:46 kernel: [ 8.745463] sd 0:0:0:0: [sda] 1953525168 512-byte logical blocks: (1.00 TB/931 GiB) 2011 Sep 28 08:41:46 kernel: [ 8.745586] scsi 0:0:1:0: Direct-Access ATA ST31000524AS JC4B PQ: 0 ANSI: 5 2011 Sep 28 08:41:46 kernel: [ 8.745649] sd 0:0:0:0: [sda] Write Protect is off 2011 Sep 28 08:41:46 kernel: [ 8.745652] sd 0:0:0:0: [sda] Mode Sense: 00 3a 00 00 2011 Sep 28 08:41:46 kernel: [ 8.745690] sd 0:0:0:0: [sda] Write cache: enabled, read cache: enabled, doesn't support DPO or FUA 2011 Sep 28 08:41:46 kernel: [ 8.745972] sd 0:0:1:0: Attached scsi generic sg1 type 0 2011 Sep 28 08:41:46 kernel: [ 8.746193] scsi 1:0:0:0: Direct-Access ATA ST1000DL002-9TT1 CC32 PQ: 0 ANSI: 5 2011 Sep 28 08:41:46 kernel: [ 8.746392] sd 1:0:0:0: [sdc] 1953525168 512-byte logical blocks: (1.00 TB/931 GiB) 2011 Sep 28 08:41:46 kernel: [ 8.746401] sd 1:0:0:0: Attached scsi generic sg2 type 0 2011 Sep 28 08:41:46 kernel: [ 8.746634] sd 1:0:0:0: [sdc] Write Protect is off 2011 Sep 28 08:41:46 kernel: [ 8.746698] sd 1:0:0:0: [sdc] Mode Sense: 00 3a 00 00 2011 Sep 28 08:41:46 kernel: [ 8.746792] sd 1:0:0:0: [sdc] Write cache: enabled, read cache: enabled, doesn't support DPO or FUA 2011 Sep 28 08:41:46 kernel: [ 8.767270] sda: sda1 sda2 2011 Sep 28 08:41:46 kernel: [ 8.767286] sd 0:0:1:0: [sdb] 1953525168 512-byte logical blocks: (1.00 TB/931 GiB) 2011 Sep 28 08:41:46 kernel: [ 8.767373] sd 0:0:1:0: [sdb] Write Protect is off 2011 Sep 28 08:41:46 kernel: [ 8.767376] sd 0:0:1:0: [sdb] Mode Sense: 00 3a 00 00 2011 Sep 28 08:41:46 kernel: [ 8.767412] sd 0:0:1:0: [sdb] Write cache: enabled, read cache: enabled, doesn't support DPO or FUA 2011 Sep 28 08:41:46 kernel: [ 8.782140] sdb: sdb1 sdb2 2011 Sep 28 08:41:46 kernel: [ 8.782277] sd 0:0:0:0: [sda] Attached SCSI disk 2011 Sep 28 08:41:46 kernel: [ 8.782479] sd 0:0:1:0: [sdb] Attached SCSI disk 2011 Sep 28 08:41:46 kernel: [ 8.800477] sdc: sdc1 sdc2 < sdc5 > 2011 Sep 28 08:41:46 kernel: [ 8.800838] sd 1:0:0:0: [sdc] Attached SCSI disk 2011 Sep 28 08:41:46 kernel: [ 8.801167] Freeing unused kernel memory: 676k freed 2011 Sep 28 08:41:46 kernel: [ 8.802751] Write protecting the kernel text: 5080k 2011 Sep 28 08:41:46 kernel: [ 8.803342] Write protecting the kernel read-only data: 1936k 2011 Sep 28 08:41:46 kernel: [ 8.803405] NX-protecting the kernel data: 3112k 2011 Sep 28 08:41:46 kernel: [ 8.990054] udevd (87): /proc/87/oom_adj is deprecated, please use /proc/87/oom_score_adj instead. 2011 Sep 28 08:41:46 kernel: [ 9.215814] dca service started, version 1.12.1 2011 Sep 28 08:41:46 kernel: [ 9.216492] ioatdma: Intel(R) QuickData Technology Driver 4.00 2011 Sep 28 08:41:46 kernel: [ 9.256593] xen: registering gsi 43 triggering 0 polarity 1 2011 Sep 28 08:41:46 kernel: [ 9.256609] xen: --> pirq=43 -> irq=43 (gsi=43) 2011 Sep 28 08:41:46 kernel: [ 9.256622] ioatdma 0000:00:16.0: PCI INT A -> GSI 43 (level, low) -> IRQ 43 2011 Sep 28 08:41:46 kernel: [ 9.256658] ioatdma 0000:00:16.0: setting latency timer to 64 2011 Sep 28 08:41:46 kernel: [ 9.257925] xen: registering gsi 44 triggering 0 polarity 1 2011 Sep 28 08:41:46 kernel: [ 9.257935] xen: --> pirq=44 -> irq=44 (gsi=44) 2011 Sep 28 08:41:46 kernel: [ 9.257944] ioatdma 0000:00:16.1: PCI INT B -> GSI 44 (level, low) -> IRQ 44 2011 Sep 28 08:41:46 kernel: [ 9.257972] ioatdma 0000:00:16.1: setting latency timer to 64 2011 Sep 28 08:41:46 kernel: [ 9.261168] xen: registering gsi 45 triggering 0 polarity 1 2011 Sep 28 08:41:46 kernel: [ 9.261178] xen: --> pirq=45 -> irq=45 (gsi=45) 2011 Sep 28 08:41:46 kernel: [ 9.261188] ioatdma 0000:00:16.2: PCI INT C -> GSI 45 (level, low) -> IRQ 45 2011 Sep 28 08:41:46 kernel: [ 9.261215] ioatdma 0000:00:16.2: setting latency timer to 64 2011 Sep 28 08:41:46 kernel: [ 9.269261] xen: registering gsi 46 triggering 0 polarity 1 2011 Sep 28 08:41:46 kernel: [ 9.269272] xen: --> pirq=46 -> irq=46 (gsi=46) 2011 Sep 28 08:41:46 kernel: [ 9.269281] ioatdma 0000:00:16.3: PCI INT D -> GSI 46 (level, low) -> IRQ 46 2011 Sep 28 08:41:46 kernel: [ 9.269310] ioatdma 0000:00:16.3: setting latency timer to 64 2011 Sep 28 08:41:46 kernel: [ 9.273752] xen: registering gsi 43 triggering 0 polarity 1 2011 Sep 28 08:41:46 kernel: [ 9.273757] xen_map_pirq_gsi: returning irq 43 for gsi 43 2011 Sep 28 08:41:46 kernel: [ 9.273760] xen: --> pirq=43 -> irq=43 (gsi=43) 2011 Sep 28 08:41:46 kernel: [ 9.273765] Already setup the GSI :43 2011 Sep 28 08:41:46 kernel: [ 9.273769] ioatdma 0000:00:16.4: PCI INT A -> GSI 43 (level, low) -> IRQ 43 2011 Sep 28 08:41:46 kernel: [ 9.273798] ioatdma 0000:00:16.4: setting latency timer to 64 2011 Sep 28 08:41:46 kernel: [ 9.275260] EDAC MC: Ver: 2.1.0 2011 Sep 28 08:41:46 kernel: [ 9.276731] xen: registering gsi 44 triggering 0 polarity 1 2011 Sep 28 08:41:46 kernel: [ 9.276736] xen_map_pirq_gsi: returning irq 44 for gsi 44 2011 Sep 28 08:41:46 kernel: [ 9.276739] xen: --> pirq=44 -> irq=44 (gsi=44) 2011 Sep 28 08:41:46 kernel: [ 9.276744] Already setup the GSI :44 2011 Sep 28 08:41:46 kernel: [ 9.276748] ioatdma 0000:00:16.5: PCI INT B -> GSI 44 (level, low) -> IRQ 44 2011 Sep 28 08:41:46 kernel: [ 9.276776] ioatdma 0000:00:16.5: setting latency timer to 64 2011 Sep 28 08:41:46 kernel: [ 9.284726] xen: registering gsi 45 triggering 0 polarity 1 2011 Sep 28 08:41:46 kernel: [ 9.284731] xen_map_pirq_gsi: returning irq 45 for gsi 45 2011 Sep 28 08:41:46 kernel: [ 9.284734] xen: --> pirq=45 -> irq=45 (gsi=45) 2011 Sep 28 08:41:46 kernel: [ 9.284739] Already setup the GSI :45 2011 Sep 28 08:41:46 kernel: [ 9.284743] ioatdma 0000:00:16.6: PCI INT C -> GSI 45 (level, low) -> IRQ 45 2011 Sep 28 08:41:46 kernel: [ 9.284772] ioatdma 0000:00:16.6: setting latency timer to 64 2011 Sep 28 08:41:46 kernel: [ 9.289128] xen: registering gsi 46 triggering 0 polarity 1 2011 Sep 28 08:41:46 kernel: [ 9.289134] xen_map_pirq_gsi: returning irq 46 for gsi 46 2011 Sep 28 08:41:46 kernel: [ 9.289137] xen: --> pirq=46 -> irq=46 (gsi=46) 2011 Sep 28 08:41:46 kernel: [ 9.289142] Already setup the GSI :46 2011 Sep 28 08:41:46 kernel: [ 9.289146] ioatdma 0000:00:16.7: PCI INT D -> GSI 46 (level, low) -> IRQ 46 2011 Sep 28 08:41:46 kernel: [ 9.289175] ioatdma 0000:00:16.7: setting latency timer to 64 2011 Sep 28 08:41:46 kernel: [ 9.317144] EDAC MC0: Giving out device to 'i7core_edac.c' 'i7 core #0': DEV 0000:ff:03.0 2011 Sep 28 08:41:46 kernel: [ 9.317162] EDAC PCI0: Giving out device to module 'i7core_edac' controller 'EDAC PCI controller': DEV '0000:ff:03.0' (POLLED) 2011 Sep 28 08:41:46 kernel: [ 9.317166] EDAC i7core: Driver loaded. 2011 Sep 28 08:41:46 kernel: [ 9.370976] e1000e: Intel(R) PRO/1000 Network Driver - 1.3.10-k2 2011 Sep 28 08:41:46 kernel: [ 9.370980] e1000e: Copyright(c) 1999 - 2011 Intel Corporation. 2011 Sep 28 08:41:46 kernel: [ 9.371015] e1000e 0000:06:00.0: Disabling ASPM L0s 2011 Sep 28 08:41:46 kernel: [ 9.371034] xen: registering gsi 16 triggering 0 polarity 1 2011 Sep 28 08:41:46 kernel: [ 9.371040] xen_map_pirq_gsi: returning irq 16 for gsi 16 2011 Sep 28 08:41:46 kernel: [ 9.371044] xen: --> pirq=16 -> irq=16 (gsi=16) 2011 Sep 28 08:41:46 kernel: [ 9.371052] Already setup the GSI :16 2011 Sep 28 08:41:46 kernel: [ 9.371057] e1000e 0000:06:00.0: PCI INT A -> GSI 16 (level, low) -> IRQ 16 2011 Sep 28 08:41:46 kernel: [ 9.371095] e1000e 0000:06:00.0: setting latency timer to 64 2011 Sep 28 08:41:46 kernel: [ 9.373648] iTCO_vendor_support: vendor-support=0 2011 Sep 28 08:41:46 kernel: [ 9.374040] iTCO_wdt: Intel TCO WatchDog Timer Driver v1.06 2011 Sep 28 08:41:46 kernel: [ 9.374148] iTCO_wdt: Found a ICH10R TCO device (Version=2, TCOBASE=0x0860) 2011 Sep 28 08:41:46 kernel: [ 9.374221] iTCO_wdt: initialized. heartbeat=30 sec (nowayout=0) 2011 Sep 28 08:41:46 kernel: [ 9.417256] xen: registering gsi 18 triggering 0 polarity 1 2011 Sep 28 08:41:46 kernel: [ 9.417263] xen_map_pirq_gsi: returning irq 18 for gsi 18 2011 Sep 28 08:41:46 kernel: [ 9.417266] xen: --> pirq=18 -> irq=18 (gsi=18) 2011 Sep 28 08:41:46 kernel: [ 9.417273] Already setup the GSI :18 2011 Sep 28 08:41:46 kernel: [ 9.417278] i801_smbus 0000:00:1f.3: PCI INT C -> GSI 18 (level, low) -> IRQ 18 2011 Sep 28 08:41:47 kernel: [ 9.492553] Initializing USB Mass Storage driver... 2011 Sep 28 08:41:47 kernel: [ 9.514707] [Firmware Warn]: GHES: Poll interval is 0 for generic hardware error source: 1, disabled. 2011 Sep 28 08:41:47 kernel: [ 9.514867] input: Winbond Electronics Corp Hermon USB hidmouse Device as /devices/pci0000:00/0000:00:1a.1/usb4/4-1/4-1:1.1/input/input3 2011 Sep 28 08:41:47 kernel: [ 9.514932] usbcore: registered new interface driver usbkbd 2011 Sep 28 08:41:47 kernel: [ 9.514935] usbkbd: :USB HID Boot Protocol keyboard driver 2011 Sep 28 08:41:47 kernel: [ 9.534236] input: Winbond Electronics Corp Hermon USB hidmouse Device as /devices/pci0000:00/0000:00:1a.1/usb4/4-1/4-1:1.0/input/input4 2011 Sep 28 08:41:47 kernel: [ 9.534302] usbcore: registered new interface driver usbmouse 2011 Sep 28 08:41:47 kernel: [ 9.534306] usbmouse: v1.6:USB HID Boot Protocol mouse driver 2011 Sep 28 08:41:47 kernel: [ 9.544000] input: PC Speaker as /devices/platform/pcspkr/input/input5 2011 Sep 28 08:41:47 kernel: [ 9.548305] scsi4 : usb-storage 2-2:1.0 2011 Sep 28 08:41:47 kernel: [ 9.551577] usbcore: registered new interface driver usb-storage 2011 Sep 28 08:41:47 kernel: [ 9.551581] USB Mass Storage support registered. 2011 Sep 28 08:41:47 kernel: [ 9.551900] usbcore: registered new interface driver uas 2011 Sep 28 08:41:47 kernel: [ 9.588634] e1000e 0000:06:00.0: eth0: (PCI Express:2.5GT/s:Width x1) 00:25:90:38:d8:2c 2011 Sep 28 08:41:47 kernel: [ 9.588640] e1000e 0000:06:00.0: eth0: Intel(R) PRO/1000 Network Connection 2011 Sep 28 08:41:47 kernel: [ 9.588729] e1000e 0000:06:00.0: eth0: MAC: 3, PHY: 8, PBA No: 0101FF-0FF 2011 Sep 28 08:41:47 kernel: [ 9.588919] usbcore: registered new interface driver usbhid 2011 Sep 28 08:41:47 kernel: [ 9.588923] usbhid: USB HID core driver 2011 Sep 28 08:41:47 kernel: [ 9.604559] e1000e 0000:07:00.0: Disabling ASPM L0s 2011 Sep 28 08:41:47 kernel: [ 9.604579] xen: registering gsi 17 triggering 0 polarity 1 2011 Sep 28 08:41:47 kernel: [ 9.604584] xen_map_pirq_gsi: returning irq 17 for gsi 17 2011 Sep 28 08:41:47 kernel: [ 9.604587] xen: --> pirq=17 -> irq=17 (gsi=17) 2011 Sep 28 08:41:47 kernel: [ 9.604594] Already setup the GSI :17 2011 Sep 28 08:41:47 kernel: [ 9.604598] e1000e 0000:07:00.0: PCI INT A -> GSI 17 (level, low) -> IRQ 17 2011 Sep 28 08:41:47 kernel: [ 9.604633] e1000e 0000:07:00.0: setting latency timer to 64 2011 Sep 28 08:41:47 kernel: [ 9.712108] e1000e 0000:07:00.0: eth1: (PCI Express:2.5GT/s:Width x1) 00:25:90:38:d8:2d 2011 Sep 28 08:41:47 kernel: [ 9.712113] e1000e 0000:07:00.0: eth1: Intel(R) PRO/1000 Network Connection 2011 Sep 28 08:41:47 kernel: [ 9.712200] e1000e 0000:07:00.0: eth1: MAC: 3, PHY: 8, PBA No: 0101FF-0FF 2011 Sep 28 08:41:48 kernel: [ 10.549397] scsi 4:0:0:0: Direct-Access Kingston DataTraveler G2 8.20 PQ: 0 ANSI: 2 2011 Sep 28 08:41:48 kernel: [ 10.618810] sd 4:0:0:0: [sdd] 3870720 512-byte logical blocks: (1.98 GB/1.84 GiB) 2011 Sep 28 08:41:48 kernel: [ 10.618835] sd 4:0:0:0: Attached scsi generic sg3 type 0 2011 Sep 28 08:41:48 kernel: [ 10.619375] sd 4:0:0:0: [sdd] Write Protect is off 2011 Sep 28 08:41:48 kernel: [ 10.619382] sd 4:0:0:0: [sdd] Mode Sense: 23 00 00 00 2011 Sep 28 08:41:48 kernel: [ 10.619996] sd 4:0:0:0: [sdd] No Caching mode page present 2011 Sep 28 08:41:48 kernel: [ 10.620001] sd 4:0:0:0: [sdd] Assuming drive cache: write through 2011 Sep 28 08:41:48 kernel: [ 10.622619] sd 4:0:0:0: [sdd] No Caching mode page present 2011 Sep 28 08:41:48 kernel: [ 10.622625] sd 4:0:0:0: [sdd] Assuming drive cache: write through 2011 Sep 28 08:41:48 kernel: [ 10.623398] sdd: sdd1 2011 Sep 28 08:41:48 kernel: [ 10.625361] sd 4:0:0:0: [sdd] No Caching mode page present 2011 Sep 28 08:41:48 kernel: [ 10.625365] sd 4:0:0:0: [sdd] Assuming drive cache: write through 2011 Sep 28 08:41:48 kernel: [ 10.625369] sd 4:0:0:0: [sdd] Attached SCSI removable disk 2011 Sep 28 08:41:49 kernel: [ 11.780576] EXT3-fs: barriers not enabled 2011 Sep 28 08:41:49 kernel: [ 11.780945] kjournald starting. Commit interval 5 seconds 2011 Sep 28 08:41:49 kernel: [ 11.780964] EXT3-fs (sda1): mounted filesystem with ordered data mode 2011 Sep 28 08:41:49 kernel: [ 11.803034] EXT3-fs: barriers not enabled 2011 Sep 28 08:41:49 kernel: [ 11.803292] kjournald starting. Commit interval 5 seconds 2011 Sep 28 08:41:49 kernel: [ 11.803309] EXT3-fs (sdb1): mounted filesystem with ordered data mode 2011 Sep 28 08:41:49 kernel: [ 11.874964] EXT3-fs (sdc1): error: couldn't mount because of unsupported optional features (240) 2011 Sep 28 08:41:49 kernel: [ 11.916992] EXT2-fs (sdc1): error: couldn't mount because of unsupported optional features (240) 2011 Sep 28 08:41:49 kernel: [ 12.049847] EXT4-fs (sdc1): mounted filesystem with ordered data mode. Opts: (null) 2011 Sep 28 08:41:55 syslog-ng[77]: syslog-ng version 1.6.12 going down 2011 Sep 28 09:41:56 syslog-ng[455]: syslog-ng version 1.6.12 starting 2011 Sep 28 09:41:57 kernel: klogd 1.5.0, log source = /proc/kmsg started. 2011 Sep 28 09:41:57 kernel: Cannot find map file. 2011 Sep 28 09:41:57 kernel: Loaded 60396 symbols from 18 modules. 2011 Sep 28 09:41:57 kernel: [ 19.778622] udev: starting version 151 2011 Sep 28 09:41:57 kernel: [ 20.144862] md: bind<sdb1> 2011 Sep 28 09:41:57 kernel: [ 20.151131] md: bind<sda1> 2011 Sep 28 09:41:57 kernel: [ 20.161680] md: bind<sdb2> 2011 Sep 28 09:41:57 kernel: [ 20.167537] md: bind<sda2> 2011 Sep 28 09:41:59 xenstored: Checking store ... 2011 Sep 28 09:41:59 xenstored: Checking store complete. 2011 Sep 28 09:41:59 kernel: [ 22.137786] XENBUS: Unable to read cpu state 2011 Sep 28 09:41:59 kernel: [ 22.137982] XENBUS: Unable to read cpu state 2011 Sep 28 09:41:59 kernel: [ 22.138139] XENBUS: Unable to read cpu state 2011 Sep 28 09:41:59 kernel: [ 22.138398] XENBUS: Unable to read cpu state 2011 Sep 28 09:42:00 BLKTAPCTRL[767]: blktapctrl.c:790: blktapctrl: v1.0.0 2011 Sep 28 09:42:00 BLKTAPCTRL[767]: blktapctrl.c:792: Found driver: [raw image (aio)] 2011 Sep 28 09:42:00 BLKTAPCTRL[767]: blktapctrl.c:792: Found driver: [raw image (sync)] 2011 Sep 28 09:42:00 BLKTAPCTRL[767]: blktapctrl.c:792: Found driver: [vmware image (vmdk)] 2011 Sep 28 09:42:00 BLKTAPCTRL[767]: blktapctrl.c:792: Found driver: [ramdisk image (ram)] 2011 Sep 28 09:42:00 BLKTAPCTRL[767]: blktapctrl.c:792: Found driver: [qcow disk (qcow)] 2011 Sep 28 09:42:00 BLKTAPCTRL[767]: blktapctrl.c:792: Found driver: [qcow2 disk (qcow2)] 2011 Sep 28 09:42:00 BLKTAPCTRL[767]: blktapctrl_linux.c:86: blktap0 open failed 2011 Sep 28 09:42:00 BLKTAPCTRL[767]: blktapctrl.c:859: couldn't open blktap interface 2011 Sep 28 09:42:00 BLKTAPCTRL[767]: blktapctrl.c:922: Unable to start blktapctrl 2011 Sep 28 09:42:02 kernel: [ 25.761693] Ebtables v2.0 registered 2011 Sep 28 09:42:02 kernel: [ 25.856686] ip_tables: (C) 2000-2006 Netfilter Core Team 2011 Sep 28 09:42:03 init: Entering runlevel: 3 2011 Sep 28 09:42:03 ntpd[1028]: ntpd 4.2.6p3@1.2290-o Wed Sep 21 08:28:39 UTC 2011 (1) 2011 Sep 28 09:42:03 ntpd[1029]: proto: precision = 0.427 usec 2011 Sep 28 09:42:03 ntpd[1029]: ntp_io: estimated max descriptors: 1024, initial socket boundary: 16 2011 Sep 28 09:42:03 ntpd[1029]: Listen and drop on 0 v4wildcard 0.0.0.0 UDP 123 2011 Sep 28 09:42:03 ntpd[1029]: Listen and drop on 1 v6wildcard :: UDP 123 2011 Sep 28 09:42:03 ntpd[1029]: Listen normally on 2 lo 127.0.0.1 UDP 123 2011 Sep 28 09:42:03 ntpd[1029]: Listen normally on 3 lo ::1 UDP 123 2011 Sep 28 09:42:03 ntpd[1029]: peers refreshed 2011 Sep 28 09:42:03 ntpd[1029]: Deferring DNS for 01.ntp.overnetdata.net 1 2011 Sep 28 09:51:56 syslog-ng[455]: STATS: dropped 0 2011 Sep 28 09:59:22 login[1050]: ROOT LOGIN on '/dev/tty2' --------------020502010604060608070304 Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel --------------020502010604060608070304-- From xen-devel-bounces@lists.xensource.com Wed Sep 28 02:44:04 2011 Return-path: <xen-devel-bounces@lists.xensource.com> Envelope-to: www-data@lists.xensource.com Delivery-date: Wed, 28 Sep 2011 02:44:04 -0700 Received: from localhost ([127.0.0.1] helo=lists.colo.xensource.com) by lists.xensource.com with esmtp (Exim 4.43) id 1R8qgN-0006qc-Dm; Wed, 28 Sep 2011 02:44:03 -0700 Received: from mail216.messagelabs.com ([85.158.143.99]) by lists.xensource.com with esmtp (Exim 4.43) id 1R8qfg-0006eL-V0 for xen-devel@lists.xensource.com; Wed, 28 Sep 2011 02:43:21 -0700 X-Env-Sender: Andrew.Cooper3@citrix.com X-Msg-Ref: server-11.tower-216.messagelabs.com!1317202996!12279540!1 X-Originating-IP: [66.165.176.89] X-StarScan-Version: 6.4.1; banners=-,-,- X-VirusChecked: Checked Received: (qmail 15280 invoked from network); 28 Sep 2011 09:43:17 -0000 Received: from smtp.citrix.com (HELO SMTP.CITRIX.COM) (66.165.176.89) by server-11.tower-216.messagelabs.com with RC4-SHA encrypted SMTP; 28 Sep 2011 09:43:17 -0000 X-IronPort-AV: E=Sophos;i="4.68,454,1312171200"; d="scan'208";a="17765458" Received: from ftlpmailmx01.citrite.net ([10.13.107.65]) by FTLPIPO01.CITRIX.COM with ESMTP/TLS/RC4-MD5; 28 Sep 2011 05:42:57 -0400 Received: from [10.80.2.18] (10.80.2.18) by FTLPMAILMX01.citrite.net (10.13.107.65) with Microsoft SMTP Server id 8.3.137.0; Wed, 28 Sep 2011 05:42:57 -0400 Message-ID: <4E82EC20.4070700@citrix.com> Date: Wed, 28 Sep 2011 10:42:56 +0100 From: Andrew Cooper <andrew.cooper3@citrix.com> User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.2.21) Gecko/20110831 Lightning/1.0b2 Thunderbird/3.1.13 MIME-Version: 1.0 To: <xen-devel@lists.xensource.com>, <tonis@elkdata.ee> Subject: Re: [Xen-devel] Limit I/O for individual disks of VM References: <4E818A50.3050607@elkdata.ee> <4E822AE3.6050601@goop.org> <4E82BDC0.7040604@elkdata.ee> <4E82C017.1050803@goop.org> In-Reply-To: <4E82C017.1050803@goop.org> Content-Type: text/plain; charset="ISO-8859-1" Content-Transfer-Encoding: 8bit Cc: X-BeenThere: xen-devel@lists.xensource.com X-Mailman-Version: 2.1.5 Precedence: list List-Id: Xen developer discussion <xen-devel.lists.xensource.com> List-Unsubscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe> List-Post: <mailto:xen-devel@lists.xensource.com> List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help> List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=subscribe> Sender: xen-devel-bounces@lists.xensource.com Errors-To: xen-devel-bounces@lists.xensource.com On 28/09/11 07:35, Jeremy Fitzhardinge wrote: > On 09/27/2011 11:25 PM, Tõnis Bramanis wrote: >> Hello >> >> and thank You for the answer. Has anyone of You tried to limit i/o on >> the VMs? >> >> I have about 40 containers and when the i/o gets too high, the host >> will crash with this error: >> [23959.739698] sd 4:0:0:0: rejecting I/O to offline device >> 5 [23959.771158] Buffer I/O error on device dm-0, logical block 40259 >> >> This is not a support request! I am just referring why i would like to >> limit the disks i/o. > I think that IO error is a real problem that you should try to solve, > rather than work around it by rate-limiting IO. > > J This is looking suspiciously like the line level interrupt migration bug. Can you confirm the version of Xen, the raid controller you are using, and paste /proc/interrupts from dom0 please. ~Andrew >> Regards, >> Tõnis Bramanis >> >> On 27.09.2011 22:58, Jeremy Fitzhardinge wrote: >>> On 09/27/2011 01:33 AM, Tõnis Bramanis wrote: >>>> Hello! >>>> >>>> Will disk i/o limiting be added in any future versions? I see it in >>>> the 4.0 feature requests, but not in any changelogs. >>> I think the hope is that we can use the generic Linux mechanisms for >>> this rather than having to add anything Xen-specific. >>> >>> J > > _______________________________________________ > Xen-devel mailing list > Xen-devel@lists.xensource.com > http://lists.xensource.com/xen-devel -- Andrew Cooper - Dom0 Kernel Engineer, Citrix XenServer T: +44 (0)1223 225 900, http://www.citrix.com _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel From xen-devel-bounces@lists.xensource.com Wed Sep 28 03:18:15 2011 Return-path: <xen-devel-bounces@lists.xensource.com> Envelope-to: www-data@lists.xensource.com Delivery-date: Wed, 28 Sep 2011 03:18:15 -0700 Received: from localhost ([127.0.0.1] helo=lists.colo.xensource.com) by lists.xensource.com with esmtp (Exim 4.43) id 1R8rDT-0007kC-8t; Wed, 28 Sep 2011 03:18:15 -0700 Received: from mail216.messagelabs.com ([85.158.143.99]) by lists.xensource.com with esmtp (Exim 4.43) id 1R8rCU-0007XG-3y for xen-devel@lists.xensource.com; Wed, 28 Sep 2011 03:17:17 -0700 X-Env-Sender: dunlapg@gmail.com X-Msg-Ref: server-13.tower-216.messagelabs.com!1317205029!19874323!1 X-Originating-IP: [209.85.210.171] X-StarScan-Version: 6.4.1; banners=-,-,- X-VirusChecked: Checked Received: (qmail 1968 invoked from network); 28 Sep 2011 10:17:10 -0000 Received: from mail-iy0-f171.google.com (HELO mail-iy0-f171.google.com) (209.85.210.171) by server-13.tower-216.messagelabs.com with RC4-SHA encrypted SMTP; 28 Sep 2011 10:17:10 -0000 Received: by iagv1 with SMTP id v1so9061917iag.30 for <xen-devel@lists.xensource.com>; Wed, 28 Sep 2011 03:17:09 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type; bh=pKqcATqdtKjucMwLawx8n8x+TISJuWMA7rsLkfkjpwo=; b=H0VirHKILVrp6PMfOkzxZIRYTVvzK67jRtBp5uMs+gEGLnxJicX14KIf6eDb+hs1IA vqPy/TCLnMnjgi+/CgTkAxU4M+P2Ov3fnx5+QgwNjbeg+nEMDMBAZTjv3ym0ZSyOOVoa 6LjeaprXuzxwA8uW7TCAw6UIsFhIMdswxjHUc= MIME-Version: 1.0 Received: by 10.231.44.203 with SMTP id b11mr12023249ibf.84.1317205029264; Wed, 28 Sep 2011 03:17:09 -0700 (PDT) Received: by 10.231.48.9 with HTTP; Wed, 28 Sep 2011 03:17:09 -0700 (PDT) In-Reply-To: <4E82F7F10200007800058259@nat28.tlf.novell.com> References: <4E822AA6.4010605@goop.org> <4E82F7F10200007800058259@nat28.tlf.novell.com> Date: Wed, 28 Sep 2011 11:17:09 +0100 X-Google-Sender-Auth: BCstqu77C1WwO4BIj7LJI5quA50 Message-ID: <CAFLBxZbOF=Lh=AUrSDcpJr2+YosKs0h9_N40RAkhS6Y5AFRtZg@mail.gmail.com> Subject: Re: [Xen-devel] Re: MSI error when reloading iwlagn module From: George Dunlap <George.Dunlap@eu.citrix.com> To: Jan Beulich <JBeulich@suse.com> Content-Type: multipart/mixed; boundary=001517740ff8dd9e3c04adfdb149 Cc: andrew.cooper3@citrix.com, Jeremy Fitzhardinge <jeremy@goop.org>, "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>, Konrad Rzeszutek Wilk <konrad.wilk@oracle.com> X-BeenThere: xen-devel@lists.xensource.com X-Mailman-Version: 2.1.5 Precedence: list List-Id: Xen developer discussion <xen-devel.lists.xensource.com> List-Unsubscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe> List-Post: <mailto:xen-devel@lists.xensource.com> List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help> List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=subscribe> Sender: xen-devel-bounces@lists.xensource.com Errors-To: xen-devel-bounces@lists.xensource.com --001517740ff8dd9e3c04adfdb149 Content-Type: text/plain; charset=ISO-8859-1 Jeremy, can you try the attached patch (which reverts some of the changes from c/s 23786:3a05da2dc7c0)? -George On Wed, Sep 28, 2011 at 9:33 AM, Jan Beulich <JBeulich@suse.com> wrote: >>>> On 27.09.11 at 21:57, Jeremy Fitzhardinge <jeremy@goop.org> wrote: >> Hi, >> >> With a fairly current kernel + xen, I'm seeing this if I rmmod iwlagn >> and try to reload it: >> >> [51230.646678] Intel(R) Wireless WiFi Link AGN driver for Linux, in-tree: >> [51230.646685] Copyright(c) 2003-2011 Intel Corporation >> [51230.646760] xen: registering gsi 17 triggering 0 polarity 1 >> [51230.646773] xen_map_pirq_gsi: returning irq 17 for gsi 17 >> [51230.646777] xen: --> pirq=17 -> irq=17 (gsi=17) >> [51230.646781] Already setup the GSI :17 >> [51230.646789] iwlagn 0000:03:00.0: PCI INT A -> GSI 17 (level, low) -> IRQ 17 >> [51230.646814] iwlagn 0000:03:00.0: setting latency timer to 64 >> [51230.646935] iwlagn 0000:03:00.0: pci_resource_len = 0x00002000 >> [51230.646941] iwlagn 0000:03:00.0: pci_resource_base = ffffc9000671c000 >> [51230.646945] iwlagn 0000:03:00.0: HW Revision ID = 0x35 >> [51230.647075] iwlagn 0000:03:00.0: xen map irq failed -22 for 32752 domain >> [51230.647081] iwlagn 0000:03:00.0: pci_enable_msi failed >> [51230.647113] iwlagn 0000:03:00.0: PCI INT A disabled >> [51230.647126] iwlagn: probe of 0000:03:00.0 failed with error -22 >> >> with this on the Xen console >> >> (XEN) physdev.c:139: dom0: can't create irq for msi! >> >> >> I'm running Xen as of a422e2a4451e, which your MSI changes in them, >> which I suspect of having caused a regression (since I don't remember >> having problems reloading msi-using drivers before). > > Are you certain (i.e. did you try reverting the top 1 to 3 commits from > there)? Alternatively, do you know what c/s last worked for you? Is > this one the first removal, or after several of them? > > The message solely indicates a failure of create_irq(), with either > find_unassigned_irq() or __assign_irq_vector() failing being the cause, > none of which I touched recently. Instead I wonder whether > 23812:32814ad7458d wouldn't be a more likely candidate (with > 23815:9fa77d26a813 and 23816:7f357e1ef60a being less likely ones). > > I'll nevertheless see whether this reproduces with one of the MSI > drivers that my machines have in use and allow easy removal/reload. > > Jan > > > _______________________________________________ > Xen-devel mailing list > Xen-devel@lists.xensource.com > http://lists.xensource.com/xen-devel > --001517740ff8dd9e3c04adfdb149 Content-Type: text/plain; charset=US-ASCII; name="revert-23786-partial.diff" Content-Disposition: attachment; filename="revert-23786-partial.diff" Content-Transfer-Encoding: base64 X-Attachment-Id: f_gt45v5qj0 ZGlmZiAtciBjYzMzOWFiMWQ5MTcgLXIgZmQ0ZmQ0ODY4MzI1IHhlbi9hcmNoL3g4Ni9pcnEuYwot LS0gYS94ZW4vYXJjaC94ODYvaXJxLmMJVGh1IFNlcCAyMiAxODozNzowNiAyMDExICswMTAwCisr KyBiL3hlbi9hcmNoL3g4Ni9pcnEuYwlXZWQgU2VwIDI4IDExOjE2OjM3IDIwMTEgKzAxMDAKQEAg LTIyNSw2ICsyMjUsOSBAQCBzdGF0aWMgdm9pZCBfX2NsZWFyX2lycV92ZWN0b3IoaW50IGlycSkK ICAgICBmb3JfZWFjaF9jcHVfbWFzayhjcHUsIHRtcF9tYXNrKQogICAgICAgICBwZXJfY3B1KHZl Y3Rvcl9pcnEsIGNwdSlbdmVjdG9yXSA9IC0xOwogCisgICAgaWYgKCBjZmctPnVzZWRfdmVjdG9y cyApCisgICAgICAgIGNsZWFyX2JpdCh2ZWN0b3IsIGNmZy0+dXNlZF92ZWN0b3JzKTsKKwogICAg IGNmZy0+dmVjdG9yID0gSVJRX1ZFQ1RPUl9VTkFTU0lHTkVEOwogICAgIGNwdXNfY2xlYXIoY2Zn LT5jcHVfbWFzayk7CiAgICAgY2ZnLT51c2VkID0gSVJRX1VOVVNFRDsKQEAgLTIzOSwxMiArMjQy LDYgQEAgc3RhdGljIHZvaWQgX19jbGVhcl9pcnFfdmVjdG9yKGludCBpcnEpCiAgICAgICAgIHBl cl9jcHUodmVjdG9yX2lycSwgY3B1KVtjZmctPm9sZF92ZWN0b3JdID0gLTE7CiAgICAgIH0KIAot ICAgIGlmICggY2ZnLT51c2VkX3ZlY3RvcnMgKQotICAgIHsKLSAgICAgICAgQVNTRVJUKHRlc3Rf Yml0KHZlY3RvciwgY2ZnLT51c2VkX3ZlY3RvcnMpKTsKLSAgICAgICAgY2xlYXJfYml0KHZlY3Rv ciwgY2ZnLT51c2VkX3ZlY3RvcnMpOwotICAgIH0KLQogICAgIGNmZy0+bW92ZV9pbl9wcm9ncmVz cyA9IDA7CiAgICAgY2ZnLT5vbGRfdmVjdG9yID0gSVJRX1ZFQ1RPUl9VTkFTU0lHTkVEOwogICAg IGNwdXNfY2xlYXIoY2ZnLT5vbGRfY3B1X21hc2spOwo= --001517740ff8dd9e3c04adfdb149 Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel --001517740ff8dd9e3c04adfdb149-- From xen-devel-bounces@lists.xensource.com Wed Sep 28 03:28:42 2011 Return-path: <xen-devel-bounces@lists.xensource.com> Envelope-to: www-data@lists.xensource.com Delivery-date: Wed, 28 Sep 2011 03:28:42 -0700 Received: from localhost ([127.0.0.1] helo=lists.colo.xensource.com) by lists.xensource.com with esmtp (Exim 4.43) id 1R8rNZ-0008HR-9s; Wed, 28 Sep 2011 03:28:42 -0700 Received: from mail182.messagelabs.com ([85.158.139.83]) by lists.xensource.com with esmtp (Exim 4.43) id 1R8rMn-00084S-OY for xen-devel@lists.xensource.com; Wed, 28 Sep 2011 03:27:54 -0700 X-Env-Sender: JBeulich@suse.com X-Msg-Ref: server-7.tower-182.messagelabs.com!1317205670!15047344!1 X-Originating-IP: [130.57.49.28] X-StarScan-Version: 6.4.1; banners=-,-,- X-VirusChecked: Checked Received: (qmail 29515 invoked from network); 28 Sep 2011 10:27:50 -0000 Received: from nat28.tlf.novell.com (HELO nat28.tlf.novell.com) (130.57.49.28) by server-7.tower-182.messagelabs.com with DHE-RSA-AES256-SHA encrypted SMTP; 28 Sep 2011 10:27:50 -0000 Received: from EMEA1-MTA by nat28.tlf.novell.com with Novell_GroupWise; Wed, 28 Sep 2011 11:27:49 +0100 Message-Id: <4E8312C4020000780005829C@nat28.tlf.novell.com> X-Mailer: Novell GroupWise Internet Agent 8.0.1 Date: Wed, 28 Sep 2011 11:27:48 +0100 From: "Jan Beulich" <JBeulich@suse.com> To: "Jeremy Fitzhardinge" <jeremy@goop.org> Subject: [Xen-devel] Re: MSI error when reloading iwlagn module References: <4E822AA6.4010605@goop.org> <4E82F7F10200007800058259@nat28.tlf.novell.com> In-Reply-To: <4E82F7F10200007800058259@nat28.tlf.novell.com> Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: quoted-printable Content-Disposition: inline Cc: George Dunlap <George.Dunlap@eu.citrix.com>, andrew.cooper3@citrix.com, "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>, Konrad Rzeszutek Wilk <konrad.wilk@oracle.com> X-BeenThere: xen-devel@lists.xensource.com X-Mailman-Version: 2.1.5 Precedence: list List-Id: Xen developer discussion <xen-devel.lists.xensource.com> List-Unsubscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe> List-Post: <mailto:xen-devel@lists.xensource.com> List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help> List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=subscribe> Sender: xen-devel-bounces@lists.xensource.com Errors-To: xen-devel-bounces@lists.xensource.com >>> On 28.09.11 at 10:33, "Jan Beulich" <JBeulich@suse.com> wrote: >>>> On 27.09.11 at 21:57, Jeremy Fitzhardinge <jeremy@goop.org> wrote: >> Hi, >>=20 >> With a fairly current kernel + xen, I'm seeing this if I rmmod iwlagn >> and try to reload it: >>=20 >> [51230.646678] Intel(R) Wireless WiFi Link AGN driver for Linux, = in-tree: >> [51230.646685] Copyright(c) 2003-2011 Intel Corporation >> [51230.646760] xen: registering gsi 17 triggering 0 polarity 1 >> [51230.646773] xen_map_pirq_gsi: returning irq 17 for gsi 17 >> [51230.646777] xen: --> pirq=3D17 -> irq=3D17 (gsi=3D17) >> [51230.646781] Already setup the GSI :17 >> [51230.646789] iwlagn 0000:03:00.0: PCI INT A -> GSI 17 (level, low) -> = IRQ 17 >> [51230.646814] iwlagn 0000:03:00.0: setting latency timer to 64 >> [51230.646935] iwlagn 0000:03:00.0: pci_resource_len =3D 0x00002000 >> [51230.646941] iwlagn 0000:03:00.0: pci_resource_base =3D ffffc9000671c0= 00 >> [51230.646945] iwlagn 0000:03:00.0: HW Revision ID =3D 0x35 >> [51230.647075] iwlagn 0000:03:00.0: xen map irq failed -22 for 32752 = domain >> [51230.647081] iwlagn 0000:03:00.0: pci_enable_msi failed >> [51230.647113] iwlagn 0000:03:00.0: PCI INT A disabled >> [51230.647126] iwlagn: probe of 0000:03:00.0 failed with error -22 >>=20 >> with this on the Xen console >>=20 >> (XEN) physdev.c:139: dom0: can't create irq for msi! >>=20 >>=20 >> I'm running Xen as of a422e2a4451e, which your MSI changes in them, >> which I suspect of having caused a regression (since I don't remember >> having problems reloading msi-using drivers before). >=20 > Are you certain (i.e. did you try reverting the top 1 to 3 commits from > there)? Alternatively, do you know what c/s last worked for you? Is > this one the first removal, or after several of them? >=20 > The message solely indicates a failure of create_irq(), with either > find_unassigned_irq() or __assign_irq_vector() failing being the cause, > none of which I touched recently. Instead I wonder whether > 23812:32814ad7458d wouldn't be a more likely candidate (with > 23815:9fa77d26a813 and 23816:7f357e1ef60a being less likely ones). >=20 > I'll nevertheless see whether this reproduces with one of the MSI > drivers that my machines have in use and allow easy removal/reload. A simple remove/load of mptsas doesn't reproduce this for me, so if George's suggested change doesn't help it would be good if you had more detail. Jan _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel From xen-devel-bounces@lists.xensource.com Wed Sep 28 03:44:23 2011 Return-path: <xen-devel-bounces@lists.xensource.com> Envelope-to: www-data@lists.xensource.com Delivery-date: Wed, 28 Sep 2011 03:44:23 -0700 Received: from localhost ([127.0.0.1] helo=lists.colo.xensource.com) by lists.xensource.com with esmtp (Exim 4.43) id 1R8rck-0000md-R9; Wed, 28 Sep 2011 03:44:22 -0700 Received: from mail27.messagelabs.com ([193.109.254.147]) by lists.xensource.com with esmtp (Exim 4.43) id 1R8rc1-0000aF-LE for xen-devel@lists.xensource.com; Wed, 28 Sep 2011 03:43:37 -0700 X-Env-Sender: david.vrabel@citrix.com X-Msg-Ref: server-13.tower-27.messagelabs.com!1317206600!41865498!1 X-Originating-IP: [66.165.176.63] X-StarScan-Version: 6.4.1; banners=-,-,- X-VirusChecked: Checked Received: (qmail 16483 invoked from network); 28 Sep 2011 10:43:21 -0000 Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63) by server-13.tower-27.messagelabs.com with RC4-SHA encrypted SMTP; 28 Sep 2011 10:43:21 -0000 X-IronPort-AV: E=Sophos;i="4.68,455,1312171200"; d="scan'208";a="164947468" Received: from ftlpmailmx01.citrite.net ([10.13.107.65]) by FTLPIPO02.CITRIX.COM with ESMTP/TLS/RC4-MD5; 28 Sep 2011 06:43:32 -0400 Received: from [10.80.2.76] (10.80.2.76) by FTLPMAILMX01.citrite.net (10.13.107.65) with Microsoft SMTP Server id 8.3.137.0; Wed, 28 Sep 2011 06:43:32 -0400 Message-ID: <4E82FAAE.6020206@citrix.com> Date: Wed, 28 Sep 2011 11:45:02 +0100 From: David Vrabel <david.vrabel@citrix.com> User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.1.16) Gecko/20110818 Icedove/3.0.11 MIME-Version: 1.0 To: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com> Subject: Re: [Xen-devel] Re: xen: memory initialization/balloon fixes (#3) References: <1316089768-22461-1-git-send-email-david.vrabel@citrix.com> <20110924020759.GA27796@phenom.oracle.com> <4E81D909.8020603@citrix.com> <20110927231033.GA4712@phenom.oracle.com> In-Reply-To: <20110927231033.GA4712@phenom.oracle.com> Content-Type: text/plain; charset="ISO-8859-1" Content-Transfer-Encoding: 7bit Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com> X-BeenThere: xen-devel@lists.xensource.com X-Mailman-Version: 2.1.5 Precedence: list List-Id: Xen developer discussion <xen-devel.lists.xensource.com> List-Unsubscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe> List-Post: <mailto:xen-devel@lists.xensource.com> List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help> List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=subscribe> Sender: xen-devel-bounces@lists.xensource.com Errors-To: xen-devel-bounces@lists.xensource.com On 28/09/11 00:10, Konrad Rzeszutek Wilk wrote: >>> (XEN) Xen-e820 RAM map: >>> (XEN) 0000000000000000 - 000000000009d800 (usable) >> >> It's because it's not correctly handling the half-page of RAM at the end >> of this region. >> >> I don't have access to any test boxes with a dodgy BIOS like this so can >> you test this patch? If it works I'll fold it in and post an updated >> series. > > It works. Albeit I think we are going to hit a problem with dmidecode > if the DMI data is right in the reserved region > > (http://lists.xensource.com/archives/html/xen-devel/2011-09/msg01299.html) > > As in, if it starts in 9D800 - we consider 0->9d as RAM PFN, and 9e->100 as 1-1 > mapping. > > I am thinking that perhaps the call to xen_set_phys_identity, where > we call PFN_UP(x) should be replaced with PFN_DOWN(x). That way > we would consider 0>9c as RAM PFN and 9D->100 as 1-1 mapping. I almost did an equivalent change (see below) but discarded it as it would have resulting in overlapping regions and attempting to release/map some pages twice. I think we will have to move the release/map until after the final e820 map has been sanitized so there are no overlapping regions. I'll prepare another patch for this. > That would imply a new patch to your series naturally. >> >> Can you remember why this page alignment was required? I'd like to > > The e820_* calls define how the memory subsystem will use it. > It ended at some point assuming that the full page is RAM even thought > it was only half-RAM and tried to use it and blew the machine up. > > The fix was to make the calls to the e820_* with size and regions > that were page-aligned. > > Anyhow, here is what the bootup looks now: > > [ 0.000000] Freeing 9e-a0 pfn range: 2 pages freed > [ 0.000000] 1-1 mapping on 9e->a0 > [ 0.000000] Freeing a0-100 pfn range: 96 pages freed > [ 0.000000] 1-1 mapping on a0->100 > [ 0.000000] Freeing 7fff0-80000 pfn range: 16 pages freed > [ 0.000000] 1-1 mapping on 7fff0->80000 > [ 0.000000] Freeing cfef0-cfef5 pfn range: 5 pages freed > [ 0.000000] 1-1 mapping on cfef0->cfef5 > [ 0.000000] Freeing cfef5-cff7f pfn range: 138 pages freed > [ 0.000000] 1-1 mapping on cfef5->cff7f > [ 0.000000] Freeing cff7f-d0000 pfn range: 129 pages freed > [ 0.000000] 1-1 mapping on cff7f->d0000 > [ 0.000000] Freeing d0000-f0000 pfn range: 131072 pages freed > [ 0.000000] 1-1 mapping on d0000->f0000 > [ 0.000000] Freeing f0000-f4b58 pfn range: 19288 pages freed > [ 0.000000] 1-1 mapping on f0000->fec10 > [ 0.000000] 1-1 mapping on fec10->fee01 > [ 0.000000] 1-1 mapping on fee01->100000 > [ 0.000000] Released 150746 pages of unused memory > [ 0.000000] Set 196994 page(s) to 1-1 mapping > [ 0.000000] BIOS-provided physical RAM map: > [ 0.000000] Xen: 0000000000000000 - 000000000009d000 (usable) > [ 0.000000] Xen: 000000000009d800 - 0000000000100000 (reserved) > [ 0.000000] Xen: 0000000000100000 - 000000007fff0000 (usable) > [ 0.000000] Xen: 000000007fff0000 - 0000000080000000 (reserved) > > >> update the comment with the reason because the bare-metal x86 memory >> init code doesn't appear to fixup the memory map in this way. >> >> diff --git a/arch/x86/xen/setup.c b/arch/x86/xen/setup.c >> index 986661b..e473c4c 100644 >> --- a/arch/x86/xen/setup.c >> +++ b/arch/x86/xen/setup.c >> @@ -178,6 +178,19 @@ static unsigned long __init xen_get_max_pages(void) >> return min(max_pages, MAX_DOMAIN_PAGES); >> } >> >> +static void xen_e820_add_region(u64 start, u64 size, int type) >> +{ >> + u64 end = start + size; >> + >> + /* Align RAM regions to page boundaries. */ >> + if (type == E820_RAM || type == E820_UNUSABLE) { > > Hm, do we care about E820_UNUSABLE to be page aligned? > If so, please comment why. Er. We don't really but I think this if needs to be: /* * Page align regions. * * Reduce RAM regions and expand other (reserved) regions. */ if (type == E820_RAM || type == E820_UNUSABLE) { start = PAGE_ALIGN(start); end &= ~((u64)PAGE_SIZE - 1); } else { start &= ~((u64)PAGE_SIZE - 1); end = PAGE_ALIGN(start); } So reserved regions also become page aligned (which is part of the fix for the dmidecode bug). >> + start = PAGE_ALIGN(start); > > Is that actually safe? Say it starts a 9ffff? We would > end up using 9f000 which is not right. PAGE_ALIGN() (and ALIGN()) round upwards. David _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel From xen-devel-bounces@lists.xensource.com Wed Sep 28 03:50:46 2011 Return-path: <xen-devel-bounces@lists.xensource.com> Envelope-to: www-data@lists.xensource.com Delivery-date: Wed, 28 Sep 2011 03:50:46 -0700 Received: from localhost ([127.0.0.1] helo=lists.colo.xensource.com) by lists.xensource.com with esmtp (Exim 4.43) id 1R8riw-0001E4-CC; Wed, 28 Sep 2011 03:50:46 -0700 Received: from mail216.messagelabs.com ([85.158.143.99]) by lists.xensource.com with esmtp (Exim 4.43) id 1R8riM-00012N-Jh for xen-devel@lists.xensource.com; Wed, 28 Sep 2011 03:50:12 -0700 X-Env-Sender: Christoph.Egger@amd.com X-Msg-Ref: server-4.tower-216.messagelabs.com!1317207006!19839288!1 X-Originating-IP: [216.32.181.182] X-StarScan-Version: 6.4.1; banners=-,-,- X-VirusChecked: Checked Received: (qmail 32466 invoked from network); 28 Sep 2011 10:50:07 -0000 Received: from ch1ehsobe002.messaging.microsoft.com (HELO ch1outboundpool.messaging.microsoft.com) (216.32.181.182) by server-4.tower-216.messagelabs.com with AES128-SHA encrypted SMTP; 28 Sep 2011 10:50:07 -0000 Received: from mail58-ch1-R.bigfish.com (216.32.181.169) by CH1EHSOBE014.bigfish.com (10.43.70.64) with Microsoft SMTP Server id 14.1.225.22; Wed, 28 Sep 2011 10:50:05 +0000 Received: from mail58-ch1 (localhost.localdomain [127.0.0.1]) by mail58-ch1-R.bigfish.com (Postfix) with ESMTP id D595B8C032C for <xen-devel@lists.xensource.com>; Wed, 28 Sep 2011 10:50:05 +0000 (UTC) X-SpamScore: 1 X-BigFish: VPS1(zzc85dhzz1202hzz8275bhz32i668h839haa6h34h61h) X-Spam-TCS-SCL: 0:0 X-Forefront-Antispam-Report: CIP:163.181.249.108; KIP:(null); UIP:(null); IPVD:NLI; H:ausb3twp01.amd.com; RD:none; EFVD:NLI X-FB-SS: 0,0, Received: from mail58-ch1 (localhost.localdomain [127.0.0.1]) by mail58-ch1 (MessageSwitch) id 1317207004331576_21638; Wed, 28 Sep 2011 10:50:04 +0000 (UTC) Received: from CH1EHSMHS035.bigfish.com (snatpool1.int.messaging.microsoft.com [10.43.68.244]) by mail58-ch1.bigfish.com (Postfix) with ESMTP id 441071720080 for <xen-devel@lists.xensource.com>; Wed, 28 Sep 2011 10:50:04 +0000 (UTC) Received: from ausb3twp01.amd.com (163.181.249.108) by CH1EHSMHS035.bigfish.com (10.43.70.35) with Microsoft SMTP Server id 14.1.225.22; Wed, 28 Sep 2011 10:50:01 +0000 X-WSS-ID: 0LS8BF9-01-2N8-02 X-M-MSG: Received: from sausexedgep01.amd.com (sausexedgep01-ext.amd.com [163.181.249.72]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by ausb3twp01.amd.com (Axway MailGate 3.8.1) with ESMTP id 210F6102838F for <xen-devel@lists.xensource.com>; Wed, 28 Sep 2011 05:49:57 -0500 (CDT) Received: from sausexhtp01.amd.com (163.181.3.165) by sausexedgep01.amd.com (163.181.36.54) with Microsoft SMTP Server (TLS) id 8.3.106.1; Wed, 28 Sep 2011 05:50:11 -0500 Received: from storexhtp01.amd.com (172.24.4.3) by sausexhtp01.amd.com (163.181.3.165) with Microsoft SMTP Server (TLS) id 8.3.83.0; Wed, 28 Sep 2011 05:50:00 -0500 Received: from rhodium.osrc.amd.com (165.204.15.173) by storexhtp01.amd.com (172.24.4.3) with Microsoft SMTP Server id 8.3.83.0; Wed, 28 Sep 2011 06:49:21 -0400 Message-ID: <4E82FBAF.8050603@amd.com> Date: Wed, 28 Sep 2011 12:49:19 +0200 From: Christoph Egger <Christoph.Egger@amd.com> User-Agent: Mozilla/5.0 (X11; U; NetBSD amd64; en-US; rv:1.9.2.17) Gecko/20110523 Lightning/1.0b3pre Thunderbird/3.1.10 MIME-Version: 1.0 To: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com> Content-Type: multipart/mixed; boundary="------------090203060106070209080908" X-OriginatorOrg: amd.com Subject: [Xen-devel] [PATCH] xen: cleanup viridian X-BeenThere: xen-devel@lists.xensource.com X-Mailman-Version: 2.1.5 Precedence: list List-Id: Xen developer discussion <xen-devel.lists.xensource.com> List-Unsubscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe> List-Post: <mailto:xen-devel@lists.xensource.com> List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help> List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=subscribe> Sender: xen-devel-bounces@lists.xensource.com Errors-To: xen-devel-bounces@lists.xensource.com --------------090203060106070209080908 Content-Type: text/plain; charset="ISO-8859-15"; format=flowed Content-Transfer-Encoding: 7bit Cleanup viridian code a little. Signed-off-by: Christoph Egger <Christoph.Egger@amd.com> -- ---to satisfy European Law for business letters: Advanced Micro Devices GmbH Einsteinring 24, 85689 Dornach b. Muenchen Geschaeftsfuehrer: Alberto Bozzo, Andrew Bowd Sitz: Dornach, Gemeinde Aschheim, Landkreis Muenchen Registergericht Muenchen, HRB Nr. 43632 --------------090203060106070209080908 Content-Type: text/plain; name="xen_viridian.diff" Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename="xen_viridian.diff" Content-Description: xen_viridian.diff diff -r 04fbcc0c1ec5 xen/arch/x86/hvm/viridian.c --- a/xen/arch/x86/hvm/viridian.c Wed Sep 28 12:09:13 2011 +0200 +++ b/xen/arch/x86/hvm/viridian.c Wed Sep 28 12:45:39 2011 +0200 @@ -98,37 +98,43 @@ int cpuid_viridian_leaves(unsigned int l void dump_guest_os_id(struct domain *d) { + struct viridian_domain *vd = &d->arch.hvm_domain.viridian; + gdprintk(XENLOG_INFO, "GUEST_OS_ID:\n"); gdprintk(XENLOG_INFO, "\tvendor: %x\n", - d->arch.hvm_domain.viridian.guest_os_id.fields.vendor); + vd->guest_os_id.fields.vendor); gdprintk(XENLOG_INFO, "\tos: %x\n", - d->arch.hvm_domain.viridian.guest_os_id.fields.os); + vd->guest_os_id.fields.os); gdprintk(XENLOG_INFO, "\tmajor: %x\n", - d->arch.hvm_domain.viridian.guest_os_id.fields.major); + vd->guest_os_id.fields.major); gdprintk(XENLOG_INFO, "\tminor: %x\n", - d->arch.hvm_domain.viridian.guest_os_id.fields.minor); + vd->guest_os_id.fields.minor); gdprintk(XENLOG_INFO, "\tsp: %x\n", - d->arch.hvm_domain.viridian.guest_os_id.fields.service_pack); + vd->guest_os_id.fields.service_pack); gdprintk(XENLOG_INFO, "\tbuild: %x\n", - d->arch.hvm_domain.viridian.guest_os_id.fields.build_number); + vd->guest_os_id.fields.build_number); } void dump_hypercall(struct domain *d) { + struct viridian_domain *vd = &d->arch.hvm_domain.viridian; + gdprintk(XENLOG_INFO, "HYPERCALL:\n"); gdprintk(XENLOG_INFO, "\tenabled: %x\n", - d->arch.hvm_domain.viridian.hypercall_gpa.fields.enabled); + vd->hypercall_gpa.fields.enabled); gdprintk(XENLOG_INFO, "\tpfn: %lx\n", - (unsigned long)d->arch.hvm_domain.viridian.hypercall_gpa.fields.pfn); + (unsigned long)vd->hypercall_gpa.fields.pfn); } void dump_apic_assist(struct vcpu *v) { + struct viridian_vcpu *vv = &v->arch.hvm_vcpu.viridian; + gdprintk(XENLOG_INFO, "APIC_ASSIST[%d]:\n", v->vcpu_id); gdprintk(XENLOG_INFO, "\tenabled: %x\n", - v->arch.hvm_vcpu.viridian.apic_assist.fields.enabled); + vv->apic_assist.fields.enabled); gdprintk(XENLOG_INFO, "\tpfn: %lx\n", - (unsigned long)v->arch.hvm_vcpu.viridian.apic_assist.fields.pfn); + (unsigned long)vv->apic_assist.fields.pfn); } static void enable_hypercall_page(struct domain *d) @@ -201,6 +207,8 @@ int wrmsr_viridian_regs(uint32_t idx, ui { struct vcpu *v = current; struct domain *d = v->domain; + struct viridian_domain *vd = &d->arch.hvm_domain.viridian; + struct viridian_vcpu *vv = &v->arch.hvm_vcpu.viridian; if ( !is_viridian_domain(d) ) return 0; @@ -209,15 +217,15 @@ int wrmsr_viridian_regs(uint32_t idx, ui { case VIRIDIAN_MSR_GUEST_OS_ID: perfc_incr(mshv_wrmsr_osid); - d->arch.hvm_domain.viridian.guest_os_id.raw = val; + vd->guest_os_id.raw = val; dump_guest_os_id(d); break; case VIRIDIAN_MSR_HYPERCALL: perfc_incr(mshv_wrmsr_hc_page); - d->arch.hvm_domain.viridian.hypercall_gpa.raw = val; + vd->hypercall_gpa.raw = val; dump_hypercall(d); - if ( d->arch.hvm_domain.viridian.hypercall_gpa.fields.enabled ) + if ( vd->hypercall_gpa.fields.enabled ) enable_hypercall_page(d); break; @@ -249,9 +257,9 @@ int wrmsr_viridian_regs(uint32_t idx, ui case VIRIDIAN_MSR_APIC_ASSIST: perfc_incr(mshv_wrmsr_apic_msr); - v->arch.hvm_vcpu.viridian.apic_assist.raw = val; + vv->apic_assist.raw = val; dump_apic_assist(v); - if (v->arch.hvm_vcpu.viridian.apic_assist.fields.enabled) + if (vv->apic_assist.fields.enabled) initialize_apic_assist(v); break; @@ -266,6 +274,8 @@ int rdmsr_viridian_regs(uint32_t idx, ui { struct vcpu *v = current; struct domain *d = v->domain; + struct viridian_domain *vd = &d->arch.hvm_domain.viridian; + struct viridian_vcpu *vv = &v->arch.hvm_vcpu.viridian; if ( !is_viridian_domain(d) ) return 0; @@ -274,12 +284,12 @@ int rdmsr_viridian_regs(uint32_t idx, ui { case VIRIDIAN_MSR_GUEST_OS_ID: perfc_incr(mshv_rdmsr_osid); - *val = d->arch.hvm_domain.viridian.guest_os_id.raw; + *val = vd->guest_os_id.raw; break; case VIRIDIAN_MSR_HYPERCALL: perfc_incr(mshv_rdmsr_hc_page); - *val = d->arch.hvm_domain.viridian.hypercall_gpa.raw; + *val = vd->hypercall_gpa.raw; break; case VIRIDIAN_MSR_VP_INDEX: @@ -300,7 +310,7 @@ int rdmsr_viridian_regs(uint32_t idx, ui case VIRIDIAN_MSR_APIC_ASSIST: perfc_incr(mshv_rdmsr_apic_msr); - *val = v->arch.hvm_vcpu.viridian.apic_assist.raw; + *val = vv->apic_assist.raw; break; default: @@ -390,12 +400,13 @@ out: static int viridian_save_domain_ctxt(struct domain *d, hvm_domain_context_t *h) { struct hvm_viridian_domain_context ctxt; + struct viridian_domain *vd = &d->arch.hvm_domain.viridian; if ( !is_viridian_domain(d) ) return 0; - ctxt.hypercall_gpa = d->arch.hvm_domain.viridian.hypercall_gpa.raw; - ctxt.guest_os_id = d->arch.hvm_domain.viridian.guest_os_id.raw; + ctxt.hypercall_gpa = vd->hypercall_gpa.raw; + ctxt.guest_os_id = vd->guest_os_id.raw; return (hvm_save_entry(VIRIDIAN_DOMAIN, 0, h, &ctxt) != 0); } @@ -403,12 +414,13 @@ static int viridian_save_domain_ctxt(str static int viridian_load_domain_ctxt(struct domain *d, hvm_domain_context_t *h) { struct hvm_viridian_domain_context ctxt; + struct viridian_domain *vd = &d->arch.hvm_domain.viridian; if ( hvm_load_entry(VIRIDIAN_DOMAIN, h, &ctxt) != 0 ) return -EINVAL; - d->arch.hvm_domain.viridian.hypercall_gpa.raw = ctxt.hypercall_gpa; - d->arch.hvm_domain.viridian.guest_os_id.raw = ctxt.guest_os_id; + vd->hypercall_gpa.raw = ctxt.hypercall_gpa; + vd->guest_os_id.raw = ctxt.guest_os_id; return 0; } --------------090203060106070209080908 Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel --------------090203060106070209080908-- From xen-devel-bounces@lists.xensource.com Wed Sep 28 04:11:25 2011 Return-path: <xen-devel-bounces@lists.xensource.com> Envelope-to: www-data@lists.xensource.com Delivery-date: Wed, 28 Sep 2011 04:11:25 -0700 Received: from localhost ([127.0.0.1] helo=lists.colo.xensource.com) by lists.xensource.com with esmtp (Exim 4.43) id 1R8s2t-00026W-UW; Wed, 28 Sep 2011 04:11:24 -0700 Received: from mail27.messagelabs.com ([193.109.254.147]) by lists.xensource.com with esmtp (Exim 4.43) id 1R8rzb-0001pa-9T for xen-devel@lists.xensource.com; Wed, 28 Sep 2011 04:08:01 -0700 X-Env-Sender: dunlapg@gmail.com X-Msg-Ref: server-12.tower-27.messagelabs.com!1317208058!44262576!1 X-Originating-IP: [209.85.210.171] X-StarScan-Version: 6.4.1; banners=-,-,- X-VirusChecked: Checked Received: (qmail 8044 invoked from network); 28 Sep 2011 11:07:39 -0000 Received: from mail-iy0-f171.google.com (HELO mail-iy0-f171.google.com) (209.85.210.171) by server-12.tower-27.messagelabs.com with RC4-SHA encrypted SMTP; 28 Sep 2011 11:07:39 -0000 Received: by iagv1 with SMTP id v1so9137148iag.30 for <xen-devel@lists.xensource.com>; Wed, 28 Sep 2011 04:07:54 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type; bh=iRzbtGXMVkNqm66e4Xgm+ZBZhJ0Mr92T4I8zSF0E8y4=; b=LF8hlhxkUw0U/8NGqN0OUOwGy7ExCqf8cgOsz8uwQ8RZtum3XqOzp+SUUInbfJZN6w l1lHCftCn685x4+rbWAwOY5lNm9sjUAzCzAATIOVTHyt5sVztuNFI8K5UQlv6MbqJdAs PiggL+yc2yFQB+oU5lj75Wyy+hH4F5DEKMEW0= MIME-Version: 1.0 Received: by 10.231.6.168 with SMTP id 40mr12174564ibz.71.1317208074496; Wed, 28 Sep 2011 04:07:54 -0700 (PDT) Received: by 10.231.48.9 with HTTP; Wed, 28 Sep 2011 04:07:54 -0700 (PDT) In-Reply-To: <4E8312C4020000780005829C@nat28.tlf.novell.com> References: <4E822AA6.4010605@goop.org> <4E82F7F10200007800058259@nat28.tlf.novell.com> <4E8312C4020000780005829C@nat28.tlf.novell.com> Date: Wed, 28 Sep 2011 12:07:54 +0100 X-Google-Sender-Auth: AnmX-Emq6sh8giIfPRd-ZTTeIk0 Message-ID: <CAFLBxZZjVxybmt7BEi3BNSLysdruRHonKPmH00MihCLjri6Khg@mail.gmail.com> Subject: Re: [Xen-devel] Re: MSI error when reloading iwlagn module From: George Dunlap <George.Dunlap@eu.citrix.com> To: Jan Beulich <JBeulich@suse.com> Content-Type: text/plain; charset=ISO-8859-1 Cc: andrew.cooper3@citrix.com, Jeremy Fitzhardinge <jeremy@goop.org>, "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>, Konrad Rzeszutek Wilk <konrad.wilk@oracle.com> X-BeenThere: xen-devel@lists.xensource.com X-Mailman-Version: 2.1.5 Precedence: list List-Id: Xen developer discussion <xen-devel.lists.xensource.com> List-Unsubscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe> List-Post: <mailto:xen-devel@lists.xensource.com> List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help> List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=subscribe> Sender: xen-devel-bounces@lists.xensource.com Errors-To: xen-devel-bounces@lists.xensource.com Actually, I think the patch I sent shouldn't have any effect on Intel systems, unless you've expicitly enabled one of the irq vector map options on your Xen command line. -George On Wed, Sep 28, 2011 at 11:27 AM, Jan Beulich <JBeulich@suse.com> wrote: >>>> On 28.09.11 at 10:33, "Jan Beulich" <JBeulich@suse.com> wrote: >>>>> On 27.09.11 at 21:57, Jeremy Fitzhardinge <jeremy@goop.org> wrote: >>> Hi, >>> >>> With a fairly current kernel + xen, I'm seeing this if I rmmod iwlagn >>> and try to reload it: >>> >>> [51230.646678] Intel(R) Wireless WiFi Link AGN driver for Linux, in-tree: >>> [51230.646685] Copyright(c) 2003-2011 Intel Corporation >>> [51230.646760] xen: registering gsi 17 triggering 0 polarity 1 >>> [51230.646773] xen_map_pirq_gsi: returning irq 17 for gsi 17 >>> [51230.646777] xen: --> pirq=17 -> irq=17 (gsi=17) >>> [51230.646781] Already setup the GSI :17 >>> [51230.646789] iwlagn 0000:03:00.0: PCI INT A -> GSI 17 (level, low) -> IRQ 17 >>> [51230.646814] iwlagn 0000:03:00.0: setting latency timer to 64 >>> [51230.646935] iwlagn 0000:03:00.0: pci_resource_len = 0x00002000 >>> [51230.646941] iwlagn 0000:03:00.0: pci_resource_base = ffffc9000671c000 >>> [51230.646945] iwlagn 0000:03:00.0: HW Revision ID = 0x35 >>> [51230.647075] iwlagn 0000:03:00.0: xen map irq failed -22 for 32752 domain >>> [51230.647081] iwlagn 0000:03:00.0: pci_enable_msi failed >>> [51230.647113] iwlagn 0000:03:00.0: PCI INT A disabled >>> [51230.647126] iwlagn: probe of 0000:03:00.0 failed with error -22 >>> >>> with this on the Xen console >>> >>> (XEN) physdev.c:139: dom0: can't create irq for msi! >>> >>> >>> I'm running Xen as of a422e2a4451e, which your MSI changes in them, >>> which I suspect of having caused a regression (since I don't remember >>> having problems reloading msi-using drivers before). >> >> Are you certain (i.e. did you try reverting the top 1 to 3 commits from >> there)? Alternatively, do you know what c/s last worked for you? Is >> this one the first removal, or after several of them? >> >> The message solely indicates a failure of create_irq(), with either >> find_unassigned_irq() or __assign_irq_vector() failing being the cause, >> none of which I touched recently. Instead I wonder whether >> 23812:32814ad7458d wouldn't be a more likely candidate (with >> 23815:9fa77d26a813 and 23816:7f357e1ef60a being less likely ones). >> >> I'll nevertheless see whether this reproduces with one of the MSI >> drivers that my machines have in use and allow easy removal/reload. > > A simple remove/load of mptsas doesn't reproduce this for me, so if > George's suggested change doesn't help it would be good if you had > more detail. > > Jan > > > > _______________________________________________ > Xen-devel mailing list > Xen-devel@lists.xensource.com > http://lists.xensource.com/xen-devel > _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel From xen-devel-bounces@lists.xensource.com Wed Sep 28 04:14:30 2011 Return-path: <xen-devel-bounces@lists.xensource.com> Envelope-to: www-data@lists.xensource.com Delivery-date: Wed, 28 Sep 2011 04:14:30 -0700 Received: from localhost ([127.0.0.1] helo=lists.colo.xensource.com) by lists.xensource.com with esmtp (Exim 4.43) id 1R8s5t-0002Vo-9K; Wed, 28 Sep 2011 04:14:30 -0700 Received: from mail21.messagelabs.com ([85.158.143.35]) by lists.xensource.com with smtp (Exim 4.43) id 1R8nZo-0003w0-EM for xen-devel@lists.xensource.com; Tue, 27 Sep 2011 23:25:06 -0700 X-Env-Sender: tonis@elkdata.ee X-Msg-Ref: server-3.tower-21.messagelabs.com!1317191112!53238028!1 X-Originating-IP: [194.106.101.168] X-StarScan-Version: 6.4.1; banners=-,-,- X-VirusChecked: Checked Received: (qmail 25655 invoked from network); 28 Sep 2011 06:25:12 -0000 Received: from mail.elkdata.ee (HELO mail.elkdata.ee) (194.106.101.168) by server-3.tower-21.messagelabs.com with SMTP; 28 Sep 2011 06:25:12 -0000 Received: from [192.168.1.100] (hi2-253.dyn.online.ee [194.106.113.253]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (No client certificate requested) by mail.elkdata.ee (Postfix) with ESMTPSA id 9F257676F1F6; Wed, 28 Sep 2011 09:25:34 +0300 (EEST) Message-ID: <4E82BDC0.7040604@elkdata.ee> Date: Wed, 28 Sep 2011 09:25:04 +0300 From: =?ISO-8859-1?Q?T=F5nis_Bramanis?= <tonis@elkdata.ee> User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.2.22) Gecko/20110902 Thunderbird/3.1.14 MIME-Version: 1.0 To: Jeremy Fitzhardinge <jeremy@goop.org> Subject: Re: [Xen-devel] Limit I/O for individual disks of VM References: <4E818A50.3050607@elkdata.ee> <4E822AE3.6050601@goop.org> In-Reply-To: <4E822AE3.6050601@goop.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit X-Mailman-Approved-At: Wed, 28 Sep 2011 04:10:02 -0700 Cc: xen-devel@lists.xensource.com X-BeenThere: xen-devel@lists.xensource.com X-Mailman-Version: 2.1.5 Precedence: list List-Id: Xen developer discussion <xen-devel.lists.xensource.com> List-Unsubscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe> List-Post: <mailto:xen-devel@lists.xensource.com> List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help> List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=subscribe> Sender: xen-devel-bounces@lists.xensource.com Errors-To: xen-devel-bounces@lists.xensource.com Hello and thank You for the answer. Has anyone of You tried to limit i/o on the VMs? I have about 40 containers and when the i/o gets too high, the host will crash with this error: [23959.739698] sd 4:0:0:0: rejecting I/O to offline device 5 [23959.771158] Buffer I/O error on device dm-0, logical block 40259 This is not a support request! I am just referring why i would like to limit the disks i/o. Regards, Tõnis Bramanis On 27.09.2011 22:58, Jeremy Fitzhardinge wrote: > On 09/27/2011 01:33 AM, Tõnis Bramanis wrote: >> Hello! >> >> Will disk i/o limiting be added in any future versions? I see it in >> the 4.0 feature requests, but not in any changelogs. > > I think the hope is that we can use the generic Linux mechanisms for > this rather than having to add anything Xen-specific. > > J _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel From xen-devel-bounces@lists.xensource.com Wed Sep 28 04:17:59 2011 Return-path: <xen-devel-bounces@lists.xensource.com> Envelope-to: www-data@lists.xensource.com Delivery-date: Wed, 28 Sep 2011 04:17:59 -0700 Received: from localhost ([127.0.0.1] helo=lists.colo.xensource.com) by lists.xensource.com with esmtp (Exim 4.43) id 1R8s9F-0002uZ-Qi; Wed, 28 Sep 2011 04:17:57 -0700 Received: from mail21.messagelabs.com ([85.158.143.35]) by lists.xensource.com with smtp (Exim 4.43) id 1R8nma-00050R-NQ for xen-devel@lists.xensource.com; Tue, 27 Sep 2011 23:38:17 -0700 X-Env-Sender: tonis@elkdata.ee X-Msg-Ref: server-5.tower-21.messagelabs.com!1317191858!49796304!1 X-Originating-IP: [194.106.101.168] X-StarScan-Version: 6.4.1; banners=-,-,- X-VirusChecked: Checked Received: (qmail 18673 invoked from network); 28 Sep 2011 06:37:38 -0000 Received: from mail.elkdata.ee (HELO mail.elkdata.ee) (194.106.101.168) by server-5.tower-21.messagelabs.com with SMTP; 28 Sep 2011 06:37:38 -0000 Received: from [192.168.1.100] (hi2-253.dyn.online.ee [194.106.113.253]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (No client certificate requested) by mail.elkdata.ee (Postfix) with ESMTPSA id 4A85A676F1D9; Wed, 28 Sep 2011 09:38:47 +0300 (EEST) Message-ID: <4E82C0D9.5040907@elkdata.ee> Date: Wed, 28 Sep 2011 09:38:17 +0300 From: =?ISO-8859-1?Q?T=F5nis_Bramanis?= <tonis@elkdata.ee> User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.2.22) Gecko/20110902 Thunderbird/3.1.14 MIME-Version: 1.0 To: Jeremy Fitzhardinge <jeremy@goop.org> Subject: Re: [Xen-devel] Limit I/O for individual disks of VM References: <4E818A50.3050607@elkdata.ee> <4E822AE3.6050601@goop.org> <4E82BDC0.7040604@elkdata.ee> <4E82C017.1050803@goop.org> In-Reply-To: <4E82C017.1050803@goop.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit X-Mailman-Approved-At: Wed, 28 Sep 2011 04:10:02 -0700 Cc: xen-devel@lists.xensource.com X-BeenThere: xen-devel@lists.xensource.com X-Mailman-Version: 2.1.5 Precedence: list List-Id: Xen developer discussion <xen-devel.lists.xensource.com> List-Unsubscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe> List-Post: <mailto:xen-devel@lists.xensource.com> List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help> List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=subscribe> Sender: xen-devel-bounces@lists.xensource.com Errors-To: xen-devel-bounces@lists.xensource.com I haven't met anyone yet who had ever seen something like that before. Guess it's time to change the hardware and see what happens then. Thanks, Tõnis On 28.09.2011 9:35, Jeremy Fitzhardinge wrote: > On 09/27/2011 11:25 PM, Tõnis Bramanis wrote: >> Hello >> >> and thank You for the answer. Has anyone of You tried to limit i/o on >> the VMs? >> >> I have about 40 containers and when the i/o gets too high, the host >> will crash with this error: >> [23959.739698] sd 4:0:0:0: rejecting I/O to offline device >> 5 [23959.771158] Buffer I/O error on device dm-0, logical block 40259 >> >> This is not a support request! I am just referring why i would like to >> limit the disks i/o. > > I think that IO error is a real problem that you should try to solve, > rather than work around it by rate-limiting IO. > > J > >> >> Regards, >> Tõnis Bramanis >> >> On 27.09.2011 22:58, Jeremy Fitzhardinge wrote: >>> On 09/27/2011 01:33 AM, Tõnis Bramanis wrote: >>>> Hello! >>>> >>>> Will disk i/o limiting be added in any future versions? I see it in >>>> the 4.0 feature requests, but not in any changelogs. >>> >>> I think the hope is that we can use the generic Linux mechanisms for >>> this rather than having to add anything Xen-specific. >>> >>> J >> > _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel From xen-devel-bounces@lists.xensource.com Wed Sep 28 04:22:25 2011 Return-path: <xen-devel-bounces@lists.xensource.com> Envelope-to: www-data@lists.xensource.com Delivery-date: Wed, 28 Sep 2011 04:22:25 -0700 Received: from localhost ([127.0.0.1] helo=lists.colo.xensource.com) by lists.xensource.com with esmtp (Exim 4.43) id 1R8sDY-0003Le-JK; Wed, 28 Sep 2011 04:22:25 -0700 Received: from mail21.messagelabs.com ([85.158.143.35]) by lists.xensource.com with smtp (Exim 4.43) id 1R8osC-0000I9-Po for xen-devel@lists.xensource.com; Wed, 28 Sep 2011 00:48:09 -0700 X-Env-Sender: tonis@elkdata.ee X-Msg-Ref: server-2.tower-21.messagelabs.com!1317196083!35774656!1 X-Originating-IP: [194.106.101.168] X-StarScan-Version: 6.4.1; banners=-,-,- X-VirusChecked: Checked Received: (qmail 3951 invoked from network); 28 Sep 2011 07:48:04 -0000 Received: from mail.elkdata.ee (HELO mail.elkdata.ee) (194.106.101.168) by server-2.tower-21.messagelabs.com with SMTP; 28 Sep 2011 07:48:04 -0000 Received: from [192.168.1.100] (hi2-253.dyn.online.ee [194.106.113.253]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (No client certificate requested) by mail.elkdata.ee (Postfix) with ESMTPSA id 85803676F1D9; Wed, 28 Sep 2011 10:48:39 +0300 (EEST) Message-ID: <4E82D139.2060100@elkdata.ee> Date: Wed, 28 Sep 2011 10:48:09 +0300 From: =?ISO-8859-1?Q?T=F5nis_Bramanis?= <tonis@elkdata.ee> User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.2.22) Gecko/20110902 Thunderbird/3.1.14 MIME-Version: 1.0 To: Joseph Glanville <joseph.glanville@orionvm.com.au> Subject: Re: [Xen-devel] Limit I/O for individual disks of VM References: <4E818A50.3050607@elkdata.ee> <4E822AE3.6050601@goop.org> <4E82BDC0.7040604@elkdata.ee> <4E82C017.1050803@goop.org> <CAOzFzEhcJDy6K=ffUi8Y=VGBmo_pSqFSR50grhgp49s=7C-OZw@mail.gmail.com> In-Reply-To: <CAOzFzEhcJDy6K=ffUi8Y=VGBmo_pSqFSR50grhgp49s=7C-OZw@mail.gmail.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit X-Mailman-Approved-At: Wed, 28 Sep 2011 04:10:02 -0700 Cc: Jeremy Fitzhardinge <jeremy@goop.org>, xen-devel@lists.xensource.com X-BeenThere: xen-devel@lists.xensource.com X-Mailman-Version: 2.1.5 Precedence: list List-Id: Xen developer discussion <xen-devel.lists.xensource.com> List-Unsubscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe> List-Post: <mailto:xen-devel@lists.xensource.com> List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help> List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=subscribe> Sender: xen-devel-bounces@lists.xensource.com Errors-To: xen-devel-bounces@lists.xensource.com If i run the exact same kernel without Xen and test the i/o, it won't crash. I just tried to look up an old post to refer it to You and seems it has been updated just yesterday with a fix: http://xen.1045712.n5.nabble.com/Xen-4-1-3ware-9690SA-rejecting-I-O-to-offline-device-td3208156.html Still, i will try to change the raid controller and see what happens then. Regards, Tõnis Bramanis On 28.09.2011 10:38, Joseph Glanville wrote: > Hi, > > To add to the above it looks like you have a device driver or hardware > issue with your harddrive or raid controller. > I/O ratelimiting might hide the symptoms but not correct the problem. > After you have addressed that you can look at implementing rate limiting > via the methods described below: > > cgroups blk-io controller: > You can find documentation etc in the linux git repo at > /documentation/cgroups/blkio-controller.txt > > dm-ioband: > Wiki is here http://sourceforge.net/apps/trac/ioband/wiki/dm-ioband > > Both of these are external to Xen for the reasons outlined by previous > posts. > > Kind regards, > Joseph. > > 2011/9/28 Jeremy Fitzhardinge <jeremy@goop.org <mailto:jeremy@goop.org>> > > On 09/27/2011 11:25 PM, Tõnis Bramanis wrote: > > Hello > > > > and thank You for the answer. Has anyone of You tried to limit i/o on > > the VMs? > > > > I have about 40 containers and when the i/o gets too high, the host > > will crash with this error: > > [23959.739698] sd 4:0:0:0: rejecting I/O to offline device > > 5 [23959.771158] Buffer I/O error on device dm-0, logical > block 40259 > > > > This is not a support request! I am just referring why i would > like to > > limit the disks i/o. > > I think that IO error is a real problem that you should try to solve, > rather than work around it by rate-limiting IO. > > J > > > > > Regards, > > Tõnis Bramanis > > > > On 27.09.2011 22 <tel:27.09.2011%2022>:58, Jeremy Fitzhardinge wrote: > >> On 09/27/2011 01:33 AM, Tõnis Bramanis wrote: > >>> Hello! > >>> > >>> Will disk i/o limiting be added in any future versions? I see it in > >>> the 4.0 feature requests, but not in any changelogs. > >> > >> I think the hope is that we can use the generic Linux mechanisms for > >> this rather than having to add anything Xen-specific. > >> > >> J > > > > > _______________________________________________ > Xen-devel mailing list > Xen-devel@lists.xensource.com <mailto:Xen-devel@lists.xensource.com> > http://lists.xensource.com/xen-devel > > > > > -- > */ > Founder | Director | VP Research > Orion Virtualisation Solutions/* | www.orionvm.com.au > <http://www.orionvm.com.au/> | Phone: 1300 56 99 52 | Mobile: 0428 754 846 _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel From xen-devel-bounces@lists.xensource.com Wed Sep 28 04:55:13 2011 Return-path: <xen-devel-bounces@lists.xensource.com> Envelope-to: www-data@lists.xensource.com Delivery-date: Wed, 28 Sep 2011 04:55:13 -0700 Received: from localhost ([127.0.0.1] helo=lists.colo.xensource.com) by lists.xensource.com with esmtp (Exim 4.43) id 1R8sjI-0005DP-SO; Wed, 28 Sep 2011 04:55:12 -0700 Received: from mail216.messagelabs.com ([85.158.143.99]) by lists.xensource.com with esmtp (Exim 4.43) id 1R8si7-00050Z-ST for xen-devel@lists.xensource.com; Wed, 28 Sep 2011 04:54:04 -0700 X-Env-Sender: vase@selfip.ru X-Msg-Ref: server-4.tower-216.messagelabs.com!1317210836!19849458!1 X-Originating-IP: [74.125.82.43] X-StarScan-Version: 6.4.1; banners=-,-,- X-VirusChecked: Checked Received: (qmail 22744 invoked from network); 28 Sep 2011 11:53:56 -0000 Received: from mail-ww0-f43.google.com (HELO mail-ww0-f43.google.com) (74.125.82.43) by server-4.tower-216.messagelabs.com with RC4-SHA encrypted SMTP; 28 Sep 2011 11:53:56 -0000 Received: by wwf27 with SMTP id 27so7042555wwf.24 for <xen-devel@lists.xensource.com>; Wed, 28 Sep 2011 04:53:56 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=selfip.ru; s=google; h=mime-version:sender:x-originating-ip:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type; bh=LBhl+dVUBjyomcJrxUynLDrDb74gBzHFS4I3tarWOS4=; b=Elo6il4Z+KfgPK3yr6rhaOGHv8/omkkg19QM3yoxeIuUv9g7eJ209nuF6L2f+Rbnjy 5n8QO23QOzXodIKhAaNrU7DN/RQfpYSoXtISifH7NaNqusMUYC9p4OCe/3Axlg+xkj0r i8auyq4hSx6IvKAV42TCH3r2C862HC8Edw5jY= MIME-Version: 1.0 Received: by 10.216.221.42 with SMTP id q42mr10740204wep.16.1317210836325; Wed, 28 Sep 2011 04:53:56 -0700 (PDT) Received: by 10.216.4.69 with HTTP; Wed, 28 Sep 2011 04:53:56 -0700 (PDT) X-Originating-IP: [85.143.161.18] In-Reply-To: <1317198065.13424.109.camel@dagon.hellion.org.uk> References: <CACaajQuWMrZhz51p2x9frQ-PyS8P8tbbbQAsJq6hyc4qp=fomg@mail.gmail.com> <1317198065.13424.109.camel@dagon.hellion.org.uk> Date: Wed, 28 Sep 2011 15:53:56 +0400 X-Google-Sender-Auth: NO_K0NaRf5CS--2TRQ9WEnyJkVQ Message-ID: <CACaajQsv0FebpEUO4kGz2=gRjv1eTnHhijxW12=OHOUya4YH_w@mail.gmail.com> Subject: Re: [Xen-devel] dom0 kernel From: Vasiliy Tolstov <v.tolstov@selfip.ru> To: Ian Campbell <Ian.Campbell@citrix.com> Content-Type: multipart/mixed; boundary=001485f6d9b2fe562304adff0bf9 Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com> X-BeenThere: xen-devel@lists.xensource.com X-Mailman-Version: 2.1.5 Precedence: list List-Id: Xen developer discussion <xen-devel.lists.xensource.com> List-Unsubscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe> List-Post: <mailto:xen-devel@lists.xensource.com> List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help> List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=subscribe> Sender: xen-devel-bounces@lists.xensource.com Errors-To: xen-devel-bounces@lists.xensource.com --001485f6d9b2fe562304adff0bf9 Content-Type: multipart/alternative; boundary=001485f6d9b2fe561c04adff0bf7 --001485f6d9b2fe561c04adff0bf7 Content-Type: text/plain; charset=UTF-8 2011/9/28 Ian Campbell <Ian.Campbell@citrix.com> > On Wed, 2011-09-28 at 09:11 +0100, Vasiliy Tolstov wrote: > > Hello. What kernel version is the best to use for dom0 under debian? > > Now i see, that kernel 2.6.32-5-xen-amd64 panic under heavy network > > load. > > Can you give us a pointer to your Debian bug report on this issue > please. > > > I'm not assign bug report. Now i have only small screenshot from ip-kvm of my server, that after some time dies.. -- Vasiliy Tolstov, Clodo.ru e-mail: v.tolstov@selfip.ru jabber: vase@selfip.ru --001485f6d9b2fe561c04adff0bf7 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable <br><br><div class=3D"gmail_quote">2011/9/28 Ian Campbell <span dir=3D"ltr"= ><<a href=3D"mailto:Ian.Campbell@citrix.com">Ian.Campbell@citrix.com</a>= ></span><br><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex= ;border-left:1px #ccc solid;padding-left:1ex;"> <div class=3D"im">On Wed, 2011-09-28 at 09:11 +0100, Vasiliy Tolstov wrote:= <br> > Hello. What kernel version is the best to use for dom0 under debian?<b= r> > Now i see, that kernel 2.6.32-5-xen-amd64 panic under heavy network<br= > > load.<br> <br> </div>Can you give us a pointer to your Debian bug report on this issue<br> please.<br> <font color=3D"#888888"> <br> <br> </font></blockquote></div><br>I'm not assign bug report. Now i have onl= y small screenshot from ip-kvm of my server, that after some time dies..<di= v><br clear=3D"all"><div><br></div>-- <br><span style=3D"border-collapse:co= llapse;color:rgb(136, 136, 136);font-family:arial, sans-serif;font-size:13p= x"><div> <div>Vasiliy Tolstov,</div><div>Clodo.ru</div><div>e-mail: <a href=3D"mailt= o:v.tolstov@selfip.ru" target=3D"_blank">v.tolstov@selfip.ru</a></div><div>= jabber: <a href=3D"mailto:vase@selfip.ru" target=3D"_blank">vase@selfip.ru<= /a></div> </div></span><br> </div> --001485f6d9b2fe561c04adff0bf7-- --001485f6d9b2fe562304adff0bf9 Content-Type: image/jpeg; name="error.jpg" Content-Disposition: attachment; filename="error.jpg" Content-Transfer-Encoding: base64 X-Attachment-Id: f_gt49b2800 /9j/4AAQSkZJRgABAgEASABIAAD/7gAOQWRvYmUAZAAAAAAB/9sAQwAIBgYHBgUIBwcHCQkICgwU DQwLCwwZEhMPFB0aHx4dGhwcICQuJyAiLCMcHCg3KSwwMTQ0NB8nOT04MjwuMzQy/9sAQwEJCQkM CwwYDQ0YMiEcITIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIy MjIy/8AAEQgDIgQ8AwEiAAIRAQMRAf/EABwAAQACAwEBAQAAAAAAAAAAAAAFBgMEBwgCAf/EAF8Q AAEDAwIDAgcLBQwHBgUCBwECAwQABRESIQYTFCIxFUFRUlWS0hYXIzJWYZGTlNHTB1NUcZUYJDM1 QnN1gaGitOI3dKOksbPDNDZigrLBJSZDcvBkhMLhREUIg4X/xAAZAQEBAQEBAQAAAAAAAAAAAAAA AQIDBAX/xAAyEQEAAgEDAgQEBAYDAQAAAAAAARECAxJRITEEExRBYXGx8CJSgcEFMjNCodEVI5Hx /9oADAMBAAIRAxEAPwCdNrhl0ttwbcs6Uqwq0xgoZSDuNBwd8f1VQeMbU7JvdmixILDUqUwW+Wyy hgLWZLyEZCQlOSAkZ+YVaWLr4KeUiItk8xkIXiGvQN1EYwtJB7R8Z8u1aF1ntjijhK5S1oQyw20t xSEqwlCJbu+CSrOBuMk5r5X8PmM8stSM5m/ab6RfxfU8bGeOGzLTiKrrURM9PgpV04Yu9mZ502Mg Nc5UdS2n23UodTuUKKFHSr5jg9/kqK5avJXZI3FnDyrs28vTGix7y9Mca5K3BLKwpLb41ZKFIyCU 7DxjcBNayuKbeoO9VPiuyk2mQyy+wxIJDxcStpPNdJcUQpOoEhIQTsfJ9V8tyPlKJ7q3IFlnXTqT DY5nSx1yXsrCdLacalbkZxnuG9dkk8XcLKvLEhbqH2WLx1DX72UeW2qMApYCkjA53bIG5I1YJxWl E4vhxYLEF29vPTl2yXGeuSQ8U81a9TJUopDh0DUAdJ069u84DjvJVUpb+FrzdYrMmDBW+09K6RBS pOS7p14xnIGnJJ7gBua6FI4mtquE24Ed+K20LQIrkNyO8tapGrdQSFBkb4XzDlYPiJ2rFwpf7Lbu EVWi5r/7XPdS9pZKnGWXI5bLqDjAIOx7zpKtjmgoHucuRchIQy04qbIVGY5UhtYW4lQSU5CiBupO 5wCFAjIOa2EcGcQOphLZty3m5ry2I7jLiHELWkkKGpJIA7KjkkAhJIOATVs4Y4ij2C23OK7LdLsd xUm2LjtAoU+W1slR1AHBC0qwQPieXsqkLNxm1aLLwpBYktBMeQ4Z4XHKywkvAhSSR3ltTieznZZ8 eMBRrbwRxDd5k6JBt/NfgucqSnnNp0KyRjJUM7pPdnurSkcN3iJahc5MB1mIZBjBbgCTzBnKdJ32 0kZxjII7xXV7ZxZYrfdWFddrZevU24vucpY5KVNrbbTjT2tQUDkd3cRWK0cdQn4NsVfltKej3bnq bbjbJQWVDm4AwTzVFZ8eSSB3Cg47ylHxVJS+HrlAjoflstMocjtyWwqQ3qW24SEqSnVqPccgDI8e K6Unim3qmNKkz4qpabZKjsz2GJB6d1Z7BLrhU6rACtwns68DIJxlunEtimWSTCk3N2Wp2Dbo7q2U L1uqaeWp4pK0jfByCrGc/rpI49yVd+NqknOHLk1JlsKZaC4kcSXiH2ykNkJKVBWrCs60YAJJ1DFX fj26Wm7R7WLfJRJejqkIcdw8pZbK8tBS3e0o4ztkgEnGBWC4cSMyuBI1uS8+bktLUWUktpDZYZUt TYBx3/CJGe/sHOP5QUOVBehyFsO8pS0YyWnUOp3GdlJJB7/Eaw8lXkzXb5HGdlVc7i9BuDDDz1xY f6l5mQA4yllKCMNYUopUFdheEnV8+0JbuLbSzAJltKddjzXUxWEw2+UmI+4hTqQkkhJ0pcTjJwHc ZI3SHKg0rHxa/eScfFrrbHFdramXZmNL0JbiRYdrlSkuIw00RrBUzhwajlW2M4wcd1YL3xaw5w/d GLdPQmVLuinHEsRVMoeZVH5a1aSVDClZO51Z7WAe4OV8pXmmnKV5pqcQ40mC5HMFhbqlZElRc5iB tsAFacbeNJO5+bFx4fudghcFT4D8lYkyY0lLjD4cWlTx0ckoSAWwOzupXaCgMHFBz6PZp0u3Tbgx H1xYWjqF60jRrOlOxOTk+TNafKPk/trtvuusvUTXBdiiC8/bnIkHlu/vVDS0FxOnToT3ZwknOP1V rzeJ+Hn7XLiiUlSVwp7CWywvB+GCoqcacYSnOnxIye6g5BKhOw5K2HeUpacZLTyHU7jOykkpP9Rr Dyj5P7a7ZcuNrWZ3MgXV1tDl+jyXS2hxGuMlhtC87bjKSNPjx3VUbdJs0fjW5TucqPGKpKoDjJca bSpWrl6uXhaUYOMJwe7xZoKb4HneBvC3T/vLqOm5utP8Jp1acZz3b5xivuPYbnKtEq7Mw1qgRVJS 8+SAlKlEAAZO53HdnGRnGa6VxjxPbLvZrtb7bcFBtdxbktt6FoQ80WkhaUjG3wuVkKwCTnc1XbXd I7HBnEFskyVc+SmMmI2oKUClDqlqAPckdonxbk0EK5wRxI27EaVaXi5KcDTaEqSopWUhelYB+DOk hWF42ye4Go65WafaJKWJzHLWttLqCFhaVoUMhSVJJSoHygnx10S78RQOIYFmt1wlNpL8hMu7y223 B20oDaQkYPb5YwcJ06sY2zUTfHYV7ubi5F0jMxosDlwG4zLriQEbIYytKVZ7yVnI3/qAVeRw3eIs a3PvQHkouWekGAVPYIGyRvvqGNt8jGa2WODb7JuUq3sw0qkRFJQ/8O3oQpRCUpK9WnUScac5zkYy DV4tfElqaVwa7cX1yHID0tyYVtqWpCnF5QskjtHOFZGSMeXFSMDibh+Nd5L3VJRIfahLkyuQvkPv tuhb6g3p2URjSrQMEKIKSckOQ9BL6zo+me6rmcrkaDr15xp09+c7YqYRwRxEu6yraLfiVF5fOCnm 0pQV40DWVacq1DAzk/1Gt64dE6uddIVwfbkvzXUoirSouchYPaU5k5JzpIJJOTknNXscWWNziu/v mdojTJFvfZfU0vSQwpBWnAGoE4ONsbd4oOSRbLcZt1Ra48N5c5Tha5BThQUO8EHuxg5zjGDnuqSa 4I4iemKiot+Vpbbc1l5sNKS4QGylwq0K1E4GCckEDuNS0xmy3i6y7k/dXYnV3JwlnpC4ptlWVBwk KwdyAUg57yM91XKFxZY2rkSudpWmJb2lPlpwxlKZcCnQhrHZ2+L2E4IURpzkhyWLZbjNuqLXHhvL nKcLXIKcKCh3gg92MHOcYwc91Zm+HLm7JiMIZaK5ccyWSZDYSWwFFSirVhONC8hRBGk5q5cPLiTu JOI1NNOuLmwJwgocSXHStQJAzudZRqGc5OSMnO/5A4kZjcCybcp58XFtLsWKEtp0dO+pCncny5bU PL29v/CFCkQXovK5nKPNbDieW6leAfLpJ0n/AMJwR4xWDlq8012Jjiqztwm22JTbc0WWHFRIdS8h La21qLjZW1hwZBSezsdO5rUHF8ASr4t13WpMjrraWISUNqlcpTRcKFFRG6kr3PejOxOkhyrlK8lS j/C16j2hN1dgrTDUlC9epOoJWSEKUnOpKVFJwogA+I7irLxldrddHoUWzc1NsioWttpxpKOW46su LAx4hlKcdw07Z7zMz+JbU9Mvd/afUqXd7d0Xg/lqBYUpISpRc+KUgIBGNzqwQnGaDmUSBInTGIkd srffcS02nUBqUo4AydhuaS4EiDMfiSGyh9hxTTidQOlSTgjI2O4rsU/jS0v3i8SXZrsqMmXb5Fvb KFnTy1AulsKACDjV34zk1+TbomDAfv6pGpTMuW5YHW1pAeEgkOZQpGr4M5V2sAk47sZDkMy1zbet lMuMtovMofa1dy21DKVA+Mf+4I7wakWODL7IiGWISWo4ZbfLkiQ2ykNrUpKFErUNlFCsf1eIjM/x Ayy3wjwrHU1y5qWH3HNTZCi0t0ls5I3B7ZH68+Pe0X28QbY7xQI6WmxcmLc5bW3Impt1pKRkhKkl OAPKNiNtxQchdjOMvLaWElSFFJKFhSSR5CCQR842qUf4Svca3LuDsLTFRHZkqc5qDht0lLasA53I O3ePHiuh8L3+zxmeFXJk9MZVnVMD7a2nFFYdHZKNKSMb75IO1fE7iK0TuDXremXy5LtphxghbS+y 5HcUVAkAjtBXZPdsdWnbIc8HDF18EM3VbUduG8lamluy2kKcCDhWlKlBSiCMYAz3eWovlK82uhS5 8KZ+T+z2tu4Q25ERMgvsvxlKcJU5qQG18s6Scb4UAcgGrFdOL7JPuN8XLkqnQVSYD0KO40paSEEc 4ISsYSSNQOcZye/NBxvlHzaco+bXYovE8JnjGNcZvEhlwkz5L7SOmcV0zS21BI1qSFjOUjQkFO2c 91anD1zkyLLKu3ELrrsKHLalxni8hKnZjSAlLR7JUrUjTlXi0E+U0HKOWfNNSUjh25ROV1LLbPNh ia3zJDadbJ7iMq3J8343zV1uFfEROH+Gbnd7h+9XvCK5kTSo9aVrVtoSNB7Su5RAGdqj3OLIEyPz JNydUtXDTtvLTocUrqiRlR2I7eAdWf5PaxtQch5a/NNbMC1zbpLTEhR3H5CkqUltHxlBKSo4HjOA du8+LeuvvcWWNUx14zdcNyXbnYUPkr/+HpaILh0lOlOwI+DJznyViZvEa/XOEyiQ7Nmp4p6mNqQt SkQ9j2SR2UbAlO2MZxtQcd5KvNpyVebVgvKYr19uDsEJERyS4pkIRpSEFR04HiGMbVpcoeSgjOSr zaclXm1J8oeSnKHkoIzkq82nJV5tSfKHkpyh5KCM5KvNpyVebUnyh5KcoeSgjOSrzaclXm1J8oeS nKHkoIzkq82nJV5tSfKHkpyh5KCM5KvNpyVebUnyh5K/OUPJQRa21BKiU42763OWsHCQQnuAFZX2 sR3P/tNW/hnhi3X1UwXC/RbSGSnRzwn4XOrOMqT3YHl76ClaF+RVYXGiX0ak9+nI8u+KuPEthhWS 5NxYN2YujS2Q4X2ANKSSRp2UrfYHv8dV55vEtA/m/wD1mgtHC3BNvv1lVcLjxPGs/wC+FsIbkJT2 9KUKJBK0+eNvvrZvv5P7XbLDMuNv4wh3R2MlCjGYQnUUlaUZyHDgDUPFWqzbl3LhaGww/DS6zNkK Wh+W0yoBSGAk4WoZB0q7vJX3HtLtstF6VJkQPhoiG20tTmXVKV1DKsBKFk9ySe7xUFF5R6ojSO// APhzVna4RlTOElX23yUS1R1qE2IgEORk/wAlZ85JAJyO758K0xBb/wDiGMfy8f7Or9wtMt/CFrXf xKTJvD4WxFgtrIS2PGt7GMjuIT49sb7oCr3rhKTw/ZYMq4yktXGWSoW0g81trGy1+bk7aTv/AFhQ FZbbKHHdsAJcH6tjXReMRar0W+I4MspfmL0y7e+srdZcCe9J8beBt5NgPNTSCgcuQe/+F/8A4qDV 6RPm1+9InyVIaKaKCP6RPkp0ifJUhopooI/pE+SnSJ8lSGimigj+kT5KdInyVIaKaKCP6RPkp0if JUhopooI/pE+SnSJ8lSGimigj+kT5KdInyVIaKaKCP6RPkp0ifJUhopooI/pE+SnSJ8lSGimigj+ kT5KdInyVIaKaKCP6RPkp0ifJUhopooI/pE+SnSJ8lSGimigj+kT5KdInyVIaKaKCP6RPkp0ifJU hopooI/pE+SnSJ8lSGimigj+kT5KdInyVIaKaKCP6RPkp0ifJUhopooI/pE+SnSJ8lSGimigj+kT 5KdInyVIaKaKCP6RPkp0ifJUhopooI/pE+SnSJ8lSGimigj+kT5KdInyVIaKaKCP6RPkp0ifJUho pooI/pE+SnSJ8lSGimigj+kT5KdInyVIaKaKCP6RPkp0ifJUhopooI/pE+SvzpE+SpHRTRQajEYc tYx3L/8AYVQ66haZ4tVzblpWyl6PIRIbS6cJVp0keMZGU771y+g7rzPyheTiv1ZNaE20cW3J4PTr XfpTqU6Qt+K+tQT34yR3bn6a7laOI51ybjy3rSI9tksl9uSZSSUJxlPMSQNORv2SrHjxT3dcPdDJ mm4gR4yULcUWlg6VK0pUBpypJJxkAig4L7meIPQF2+wu+zT3M8QegLt9hd9mu33L8odngrYbZL8t 1yW3FWhpheW9e4UezvtuAMlXizg4kmuLrM8Z+iZ2bepaJTimlpQ2pBwoaiACd+4HfxUHn73M8Qeg Lt9hd9mnuZ4g9AXb7C77Ndzm8dQW27e5BT1QlXJm3rSrU0pkuAnUUqTnuGcEDOe+rLzqDzR7meIP QF2+wu+zX57meIPQF2+wu+zXer3xLItt6tFqhwmZL9y52lTsgtJRy0hRzhCicgnxeKtS3/lAtr4S zOS5EnGU9E6ZCFv6nGsa9JSncYUD3Cg4h7meIPQF3+wu+zT3M8QegLv9hd9mvQLvFtnZnuQVzCZC CUlKGlq7YTq0AhJBXj+SDq+aouzflAh3GzIusxkwoz7ymoyPhHXXSnOewEb7DOUlQ78kEEUHEvcz xB6Au32F32ae5niD0BdvsLvs16BRxdZnZ0WEzMLr8plL7KWmlrCmyrSFZAwBkYOSMeOvlPGVjUuS kT0/vdtxxZ5a9JS38cpOML0+PTmg4B7meIPQF3+wu+zX57mOIPQF3+wu+zXf4/GlhktuON3FAQ3G EpSloUgco9yhqAyM7bePbvr9TxhZFw3pQm6UMrS24lbS0uBSvijQU6iTnbA38VBwD3M8QegLt9hd 9mnuZ4g9AXb7C77Nd/VxhZUxWJAmFYkLWhtDbK1uKUj4w5YSVAjx5G3jqRhXSLcoTUyG8l6O8nUh xPcRQeb/AHM8QegLt9hd9mnuZ4g9AXb7C77Nejbtc/BdmnXDl83pY7j/AC9WnVpSVYzg4zioVPGi S/wyhcQIRe4zkhSy9tHCWg5ju7XfjO3dmg4Z7meIPQF2+wu+zT3MX/0BdvsLvs1266/lCtcPh+dc 4ChOXES2ssHUyVpWsICgVJ3Tv3gEHFSDPGVkkXAwW5wMgSFxSktrA5qe9OSMZ8m++DjNBwH3M8Qe gLt9hd9mv33McQegLt9hd9mvS3O/VTmj5qDzR7mOIPQF2+wu+zX77mOIPQF2+wu+zXpbnfqpzR81 B5o9zPEHoC7fYXfZp7meIPQF2+wu+zXpfnfqpzv1UHmj3M8QfJ+7fYXfZp7meIPQF2+wu+zXpfnf qpzv1UHmj3M8QegLt9hd9mnuZ4g+T92+wu+zXpfnfqpzv1UHmj3M8QfJ+7fYXfZp7meIPQF2+wu+ zXpfnfqpzv1UHmn3McQegLt9hd9mvz3McQegLt9hd9mvS/NHzU5o+ag80+5jiD0BdvsLvs1+e5ji D0BdvsLvs16X5o+anNHzUHmtrh3iRl1DrVjvDbiFBSFohugpI7iCE7Gvn3McQegLt9hd9mvS/NFO aKDzP7mOIPQF2+wu+zT3McQegLt9hd9mvTHNFOaKDzP7mOIPQF2+wu+zT3McQegLt9hd9mvTHNFO aKDzP7mOIPQF2+wu+zT3McQegLt9hd9mvTHNFOaKDzU5w7xI6oKdsd4WoJCQVQ3TgAAAfF7gAB+o UXw7xI4lCV2O8KS2nSgGG6dIyTgdnYZJP6ya9K80U5ooPM/uY4g9AXb7C77NPcxxB6Au32F32a9M c0U5ooPM/uY4g9AXb7C77NPcxxB6Au32F32a9Mc0U5ooPNHuY4g9AXb7C77NfnuY4g9AXb7C77Ne mOaKc0UHmf3McQegLt9hd9mv33McQegLt9hd9mvS/NFOaKDzP7mOIPQF2+wu+zX23w7xGyoqbsd5 QopKSUwnRsQQR8XuIJH6jXpXnD/8NOcP/wANB5o9zHEHoC7fYXfZp7mOIPQF2+wu+zXpfnD/APDT nD/8NB5n9zHEHoG7fYXfZp7mOIPQN2+wu+zXpjnD/wDDTm0Hmf3McQegbt9hd9mnuY4g9A3b7C77 NemOb81OcPm+mg8z+5jiD0DdvsLvs09zHEHoG7fYXfZr0xzh5R9NOcPKPpoPM/uY4g9A3b7C77NP cxxB6Bu32F32a9Mc4eUfTTnDyj6aDzP7mOIPQN2+wu+zT3McQegbt9hd9mvTHOHlH005w8o+mg8z +5jiD0DdvsLvs09zHEHoG7fYXfZr0xzh5R9NOd84oPMy+Fr+tJSbBdsEYP7xd9mv0cP8UaQPAVwJ HjNseyfnNel+Z+qnM/VQeafc/wAUegZ/7MerErhbiJxRUux3bXtgpt7oCcHIwNPlr03zP1U5n6qD zT7n+KPQM79mPV+Hh7ig/wD9hn/sx6vTHN/VTm/qoPMnuW4j1czwJdubq1Z8Hu47sYxp7sbVk9z3 FHoKf+zXq9Lcz9VOZ+qg80+5/ij0DP8A2Y9UdcLZPtUVYuEKZFLjbikmTHU1rOMqIyBnvHd5a9Uc 0eWuRflxVrYtP8xL/wCDdB9+9VaPSd19dr8OnvVWj0ndfXZ/Dqecbjh4NNxGlrONgkePOPnPce4V pMS4q8kxmVJDgZJ5IQAs57OSSM/MSD3Dx1z3vZPhJ5R3vVWj0ndfXa/Dp71Vo9J3X12fw6sLbEV1 tDiI7OlaQodgdxr76SP+js+oKb2/QZfmVv3qrR6Tuvrtfh096q0ek7r67X4dWTpI/wCjs+oKwyvB 0GMuTL6SOwjGp13ShKcnAyTsNzirvPQZfmQPvVWj0ndfXa/Dp71Vo9J3X12vw6sLTUJ9lDzKIzjT iQpC0JBSoHuII7xX300b8wz9WKbz0GXKt+9VaPSd19dr8OnvVWj0ndfXa/Dqx9JG/MM/VinSRvzD P1YpvX/j8vzK571Vo9J3X12vw6e9VaPSd19dr8OrH0kb8wz9WKdJG/MM/Vim8/4/L8yue9VaPSd1 9dr8OnvVWj0ndfXa/DqwtswnklTSI60hSkkpSkjIJBG3jBBB+cV99JG/MM/Vim9PQZcq371Vo9J3 X12vw6e9VaPSd19dr8OrJ0kb8wz9WKdJG/MM/Vim89BlyrfvVWj0ndfXZ/Dp71Vo9J3X12vw6snS R/0dn6sV8OR2Gy0pDLaVc5vdKAD8YU3Wzn4LLHGcr7K971Vo9J3X12fw6e9VafSd19dr8Or2w229 JdDqEuJShOkKGQMlWdv6hX00iC9JfZRBjFLGErXpHxzvpAx4hjfPjrc1DwzMQoXvVWj0ndfXZ/Dp 71Vo9J3X12fw66IYMQdkw2kk+RsJP01Hx8PJhBwag5jUPL2Cf+IFWYVS/eqtHpO6+uz+HT3qrR6T uvrs/h10Hk27npj8mLz1J1pbLYyR822PEdvmr95Nu6hUfkxeelOtTfLGQPn2x4x9NTotTw5771Vo 9J3X12fw6e9VaPSd19dn8OryAEPvtoGEJWAkeTKUn/iTWINtkz3VRY77iG2A2HmwoDUtQPfWNTKM MZyn2XHGcpiIUv3qrR6Tuvrs/h096q0ek7r67P4dWh+UY8hbLlntocR8YCMDWe0yI865sx3LXbgh erJTHGdkk/8AtXz8P4v4bLUjT63M1293qnwOtGO/pXfuqHvVWj0ndfXZ/Dp71Vo9J3X12fw66t4H tfo2H9Qn7qeB7X6Nh/UJ+6vpvG5T71dp9J3X12vw6e9XafSd19dr8OureB7X6Nh/UJ+6nge1+jYf 1CfuoOU+9XafSd19dr8OnvV2n0ndfXa/Drq3ge1+jYf1Cfup4Htfo2H9Qn7qDlPvV2n0ndfXa/Dp 71dp9J3X12vw66t4Htfo2H9Qn7qeB7X6Nh/UJ+6g5T71dp9J3X12vw6e9XafSd19dr8OureB7X6N h/UJ+6nge1+jYf1CfuoOU+9XafSd19dr8OnvV2n0ndfXa/Drq3ge1+jYf1Cfup4Htfo2H9Qn7qDl HvV2j0ndfXZ/Dp71do9J3X12fw66v4Htfo2H9Qn7qeB7X6Nh/UJ+6g5R71do9J3X12fw6e9XaPSd 19dn8Our+B7X6Nh/UJ+6nge1+jYf1CfuoOUe9XaPSd19dn8OnvV2j0ndfXZ/Drq/ge1+jYf1Cfup 4Htfo2H9Qn7qDlHvV2j0ndfXZ/Dp71do9J3X12fw66v4Htfo2H9Qn7qeB7X6Nh/UJ+6g5R71do9J 3X12fw6e9XaPSd19dn8Our+B7X6Nh/UJ+6nge1+jYf1CfuoOUe9XaPSd19dn8OnvV2j0ndfXZ/Dr q/ge1+jYf1Cfup4Htfo2H9Qn7qDlHvV2j0ndfXZ/Dp71do9J3X12fw66v4Htfo2H9Qn7qeB7X6Nh /UJ+6g5R71lp9J3X12vw68yV7y8D2v0bD+oT91eDaD2BDtV5FjTYZjsFMBMJUMvNa1OuDToSoA4C MDv+Nn5qr83gS63C0PsOyYSJSbaxbI+hS9CkNupWVrOnIJ09wB/XXReQvzm/UPtU5C/K36h9qgo9 y4PuMviSZdWn4mldwgzGW1qUCoMIUlSVEJOM6tsZrOeD5EjhziW1vSWkG6XF2YytvJCQopUkK2G+ U74ztVx5C/OR6h9qnIX5zfqH76Cjv8I3Obc0XV9+GiW5dYkx9ttaihLbCCnCSU5KjnO4A+er3zfn r46dfnI9U/fTkL85Hqn76Cv36wuXniKxzebojQOfzgh9bTh1oATpUjB7xvuNvL3VhXwu3Gv/AA/L tqGWIduVJU8hSlFa1OoCQQTnUcjck/TVm5CvOb9U/fTp1Y+M36p++gpjXB7zPEDklRjvRF3PwilT sh/U2o+INJIQTnuWc7bEGtWNwRPjWLh5jqGVzbSqRlKJLrKHA6VdziAFpIyPF5R3VfeQrzm/VP30 6dXnI9U/fQVPh/hV6y36LNBiIjNWowy0wpzZwvFwkayTp37yrPzComNwDKjQlwuZFcDUaW1FkOSH 1Ky8lQHwedDfxu0QFZwDgHeuhdOvzkeqfvp06x/KR6h9qgoM3gSZPZbZclR20JsDNtKklRPOQ4le cYHY7OPL81St5s154gtraJzkJl+NLalR247jgB0A5CnBhQzk4KUgp27++rTyF+cj1D99OnV5yPVP 30FGkcFOPWttrpbf1AmOyV4lSApJWAMpfJUrV2QSSnB8g76tdhYmW+xxYlwmmZLbSQ4+c5VuSO/c 4GBk9+K3uQvzkeqfvpyFecj1T99BqXuO5crDcYLSkpckxnGUFZwkFSSBn5t6p6+AUaLClluBGMaC /GnvMI0rdU4xy9Qwkatyo5Vjv+er3yFecj1T99OQrzm/VP30HOX+AZ79glQQqCmUYTMNp9UmQ4VJ Q4lZzqyEJwnZCUnBPfivu1cP3OdcZfUIRGhMcSu3IFxKkuOafi6QRgoVnvz4j310PkL89v1T99On X5yPVPtUH3zR5ac0eWvjp1+e36h++nTr89v1D99B980eWnNHlr46dfnt+ofvp06/Pb9Q/fQffNHl pzR5a+OnX57fqH76dOvz2/UP30H3zR5ac0eWvjp1+e36h++nTr89v1D99B980eWnNHlr46dfnt+o fvp06/Pb9Q/fQffNHlpzR5a+OnX57fqH76dOvz2/UP30H3zR5ac0eWvjp1+e36h++nTr89v1D99B 980eWnNHlr46dfnt+ofvp06/Pb9Q/fQffNHlpzR5a+OnX57fqH76dOvz2/UP30H3zR5ac0eWvjp1 +e36h++nTr89v1D99B980eWnNHlr46dfnt+ofvp06/Pb9Q/fQffNHlpzR5a+OnX57fqH76dOvz2/ UP30H3zR5ac0eWvjp1+e36h++nTr89v1D99B980eWnNHlr46dfnt+ofvp06/Pb9Q/fQffNHlpzR5 a+OnX57fqH76dOvz2/UP30H3zR5ac0eWvjp1+e36h++nTr89v1D99B980eWnNHlr46dfnt+ofvp0 6/Pb9Q/fQffNHlpzR5a+OnX57fqH76dOvz2/UP30H3zR5ac0eWvjp1+e36h++nTr89v1D99B980e WnNHlr46dfnt+ofvp06/Pb9Q/fQffNHlpzR5a+OnX57fqH76dOvz2/UP30H3zR5ac0eWvjp1+e36 h++nTr89v1D99B980eWnNHlr46dfnt+ofvp06/Pb9Q/fQffNHlpzR5a+OnX57fqH76dOvz2/UP30 H3zU+WnNHlr46dfnt+ofvp06/PR6h++g++cPLTnDy18dOvz0eofvp06/PR6h++g++cPLTnDy18dO vz0eofvp06/PR6h++g++aPLTmjy18dOvz0eofvp06/PR6h++g++cPLTnDy18dOvz0eofvp06/PR6 h++g++aPLXKfy1LC2LZj8xL/AODddT6dfno9Q/fXKvy0NqQxbMlJyxK7gR4m/nNBNcQNDSh1cl2M 0lbbjjzKdS0pQVZ0jy4Vn5gCfFUM5fY3F9wiOoRJiuW+QHUMq7SHkZzrUR3OEgDx51ACrg6088go XCdI7/jIyD4iO1sawMwFsKKhDeJKyv8A+kBqPerCSMn5zvXCcZmX2fP0om76+08c+3Vq3VuSzYA1 GLupBZS7yc6+SFp5unHazy9eNPa83fFVyTcLfa1Il8OPwmLSlTSZzsXQI6VKksJGSOyFcsvaiNwN JV/Iq7YkfobvrI9qv3En9Dd9ZHtVrqmWppT2yc/Xxk+8qOLfcGpixIfDjUdTSlKR4QZaaHkGWlqA JIBznPjH2/MmO8RZvN5TbGIjz6UPNctLTa1MxlIbCnUkFWlx7CsBRGvGkEpq+/vj9Dd9ZHtU/fH6 G76yPaq0zvwnvmp1nvN3nyh4UdXBZDzCTy2kjDyo7CywvUCUJKlrwd1EkJ1JISF/fD9/k3DiVcRc tp1h6O7I6dT6FvxSlaAELQltJbOHCClRWcpxnY6rdiR+hu+sj2qYkfobvrI9qpTUamnFfjU6Xepq ItydauiE3Jp5TRt61NpTGZ6gN88jQVpHLw5qVqSNWrSU4FabF+krfhM3HiiPDiLTJKZjDzKkvFBY 0jmOMpQogrc+IkDbByUqq+/vj9Dd9ZHtVgXEUuY1LVAeL7Ta2kL1p2SspKhjVjcoT9FKZnVw9s1e hvXaXdbIqRcZUXq7eqXIhJaaCUOI5AKO0grAJcVkFWfIRiotniG+rt9nkvupYal21LjqtCSsfCRk uSCfipAS64oDGABlWfipvemT+hu+sj2qaZH6G76yPapUrOpp/nc3td9kw4ShbLmu6tqnOl0I5KlI KrghCQCkJSC6hxw9o4OMp0gGpI3niDw7JhLeRoSp7miK0FqYbCIistgjLik85ff35J0nCWzcY0RU RpTbEB1CFOLdI1pPaWorUd1eNSif66zYkfobvrI9qrSRnhEVvUu4cQvxrzAai3NpbJcisct+Q0lU xLikAvNoS3lacOfGStKdSFdnCSFbCJM+E3f3ZF2mykxHkxWtaWEBvW00rmqUlrYJLhJUQQEgkpOK tmJH6G76yPapiT+hu+sj2qlSvm4fnQHCN0kXSFM6iVHlmNK5KH2HkupcHLQv46UISSCsjZIxjG5B JnXv/pfzzf8A6xX6RI/Q3fWR7VfhakOKbHSuJw4hRJUnAAUCe4/NSIm1z19Pypx3X0lJskiS+N8F CAcKKTg6xsRuD84qKtXD0u3SZzrN4kKdkKPTlSSsIz3rcTkBa9yB4vHg5wJZtfIeW4ppbiVpSMIx kYJ8pHlr7XJZdbU25BdWhQKVIWG1JUD4iCrBFdcsMcqmY6w+JlhGUxMoLgtNyTbnXpk0yGHXlFhK kkn426wsnuVucYPiOdzmQjEhu3keT/pqrdTLbQ2lDUJxCUJCUIAQlKQNgAAdh+oVrttllMbbXycZ AOM9kjb6aaeMYYxjHsYY7caR9+nqdkxLNEYL10dHUNKBKExWwrBcUryEgjHzeXSD+WKeWpMuzS2C xdWhz3FklaZTZVgOJV5ASBj5/LqAnOvTp09PJ0+TKMf+qv3r06dPTydPkynH/qq7Y3bnp87/AKvK rp9/4+DVSSZMgnvKx/6E1+JWG0XFau5KYxP1iq+k5LjrmnTrVkJzkgYA/wDasfZBltOsSHGpDbY1 MlGQUqUf5RHlFcfEY5ZaWUY95iaY0piM4nLs+rzIuRmaoZcMZYBQpkZCtt84raiJPV2xyUEiepS9 WBhRToVgn+yo5EaK0MNt3ZA8iVtD/wDirLDTFhzUSkxrktxOfjlo5yCPO+evj4eE8T53mZR3mOkz cR1vp0/8e7LX0tm2PaOOs9PfqlFhHhR8hTPO57eEhPwpGlGcKz8XvyMd2a+ob75ioe5x0pUy3ygl IThSUZ7hn+UfH5K+vDyPR8z/AGft08PI9HzP9n7dfdfOZIUlbsplKpOtS2VLdZ7PwSgU7bDI7yN/ JUnUGi7sodU4LfOKz41KQrHzDK9v6vIKy+Hk+j5n+z9ugl6VEeHk+j5n+z9unh5Po+Z/s/boJelR Hh5Po+Z/s/bp4eT6Pmf7P26CXpUR4eT6Pmf7P26G/oH/APb5n+z9ugl6VD+6BHo+Z/s/bp7oEej5 n+z9ugmKVD+6BHo+Z/s/bp7oEej5n+z9ugmKVD+6BHo+Z/s/bp7oEej5n+z9ugmKVD+6BHo+Z/s/ bp7oEej5n+z9ugmKVD+6BHo+Z/s/bp7oEej5n+z9ugmKVD+6BHo+Z/s/bp7oEej5n+z9ugmKVD+6 BHo+Z/s/bp7oEej5n+z9ugmKVD+6BHo+Z/s/bp7oEej5n+z9ugmK8AV7n90CPR8z/Z+3Xhig9uhm AQ4RLdPK/hMTF9j9fa27q+24cV5sONPvrQruUmW4Qf71VoNrM6U2gHTLmuMLx4gFJOfo1V+xJDzd qjJLzjTQjOqaKCRqe1nA27/1UFm8HMefJ+1Oe1X74OY8+T9qc9qq9Mmy2o9yDrzrbxbjqQkKI0k4 148m+xrZ6h9q+8tT7joVIwENuEKQMdxQRgp/8Q+mgl/BzPnyftTntVidYgsKCXpbraj3BcxwE/Sq o61SJbs9rnPAOEuB9orUojfbs4wjxePevm6ExbhIfYkNFS0Dmxn0nDgxsE+X9QoJjwez+ck/anPa r98HsfnJP2pz2qgi/KE0W4F1nqFtOpGo5bbxlSR5MYxiscOVMTHtjiH3nHXm5GQtZVqKQdO366Cw +D2fPk/anParVClrsMQlxepwRwpQUQo5UkHcb75NflndbcSgiW+68WUl5ClFSUq8ff3HOds/1UR/ EED/APbf+tFBlDUAlzEp08r+ExMc7H6+1t3GvtuJFebDjT760HuUmW4Qf71VtKFGbKQkEplzHGF/ MApJ/wCGqkR91u1Rkl5xpoRnVNFBI1Pazgbd/wCqgs3g9nz5X2pz2qeD2fPlfanPaqAlzJbTFyDr zjb5bjqQAojSdtWnyb99bHUPtX3Qt5bgVI0pShZSUp8hQRgp/wDEPpoJjwezj48n7U57VYunh5cH UPAtjKx1bnYGM79rbaoy1SJb05sPPjmHmc9orUojB27OMI8Xj3r5kh0y+IC24hKQygqCkFRI5Z7j kY8flpAlW40N4kNSXlkAEhMxw4BG38rx1+ohxXdXLffXpUUq0y3DgjvB7XfVfYlSEtlIecSwnows hRHLQUdojyeLuo0+62HAhwpjLnvBxxThb8Q05UBkZoJ5bCY0uGW3H+26UqCn1qBGhR7iSO8Cvx8N G4PmS+ttptlsgh9TaQSpY3wR5BWOOp1ca1F9wOOc05WARq+DXg7gHu+atXiAfva4/wAwx/zFUEp4 OY8+V9qd9qsfTQi9yRJe5o70dY5q+jVW0zKjydXIfad09+hYVj6KhrWYohtw5gBm81epJSdYUSe1 tuNsdr+2g3+mh6kJEh7UvIQOrcyrHfjtb4rFrWiwzCHF6kB8JUVEqGFKA3O+2BUPaU6HLGk51hUk LSSTpOO7Hi8W1Sy/4hn7fpP/AKl0GwmJFW4ttL75WjGpIluEpz3Z7W1DDi83lc9/mEatHVuZx5ca q0o8mPG4guvPeaa1cnTrWE57Pz1j4jWuG5Gmtg50rZOPKpO39ooNwM24sqeExwtJOCsTV6QfITqr I1CiPNhxp99aD3KTLcIP96q+3DchzmLUclDy2nj/AOUHUP6yP7K/IkqU9HJXLf7Nvcd/hTuoOKwT /wDnioWsSGhGubKG1vFK2XCoLdUsZBRjvJ8prGEMuy5RkPuo+HS22BIUgfEScAAgZyTX5FWt522u LOVrhqUo+Unl1oXJSW3kqWoJSLo0SScADlpoJfwex58r7U57VYgzAVzNMtw8r+ExNX2P19rbx1sd YwqM6+2826hsEkoWCNhnxVU4uuMy4pba0mXBdUVKx21bqyMHyHx4oLOiHFc+I++rYK7Mtw7HuPxq wcxa7DDKlr1OBgKUFEKOVJB3G++TWjw40luXIySCqOwpOVHcFAyfp+jurcQP/gMD/wDbf+pFB9hF t5ha65XMzp0dcvOfJjVWVyHFZbLjr77aB3qVLcAH96oFaHVQrjqKekFwWXgE9sAEbg5/V4qk74tL 6YMZCC6H3gopTjtISMnGTjyUGyI0M8v98u/CDKP3452gNyR2t6+VMIZkwlsuvELcIOp9awoctR7i SO8Cq6rU/Egx1BXMZRKaIBwchGQNv6qnYenoLLpOoahntE4PKXkfTQZXw2ZzxkPrbabZbOQ+ptIJ Usb4IHiFfrMeDJzyJTrmO/RMWf8AgqtDiAfva4/zDH/MVWxGC2+IHOrUnnKYAaKBpSpOd9iTvn+y gzlu3pZS8ZjgaUcBZmr0k+QHVX6tmC26lpcp1LisaUKmuAnPdtqqAdiOS58i1DIbZU6+P/MBpH0n +2vyLKekOMTdS0FcqPHODjICTqB+YnxUFl8Hs/nJP2pz2q1tS27DLIcXqbEgJWVkqGFKA379sCo2 1SJBNnKpLq+oD4cC1k5091SKv4gn/wD7n/1LoPtxFuacLbk1aHB3pVNWCP6tVZlQYyElSnpASO8m U5gf3qhpSJK519DGggoaC0qTkkaN8HOxxnxGtuZocs8BbBK4yHGlOEjJ5Y78/wBmaDaRHhONhaJT q0E4CkzFkZ8nxqxvNMobS5HkPKUiQ2hX75WoA60gggqx3HuNaV2MOT0zzCgQmY2HXW8pSRvuVDAO PL4v66/Yn/Zp3d/Go/5iKCTkth64R2lLdCC04ohDikZIKAO4jymvhEeC44ptuS6tafjJTMcJH9Wq k9LipIDX8KYj4QfnyjFakN+OLay2whKp7UY6U6MqSoDcHyZPl76CQNvZ8+V9qc9qvkwI6RlTskZO BmU53+tVeemSRbn1MyXlJEZtTiys5Q8VgEA+LbO1fc/Wq5raceeUyxMjnKnD2ApJyc+Lxb+LxYoL B4OZ8+T9qc9qng9n85J+1Oe1UQJEs3daVv6CJWnllxW7WPEgAj59Wa1C69IDzLjz64xZe6Q6jl4j OxOcq+bPfQTqmUMyYS2XHlBbhB1PrWCOWo9xJHeBX4+GjPfMl9xtptls5D6m0glSxvgjyCsUPT0F l0qyNQzvnflLyPprW4hx0ty/mGP+YqgkGo0N4kNSXllIBITMcOAdx/K8dZfBzP5yT9qd9qo+PKjx uILrz322tXJxrWE57Pz1h6mV4U081fP6zRyc9nkY+Nju/roJRUGOhJUp2SEpBJJlOAAetXwqNDQz zlyH0tYB1mY4E4PdvqqJQ/zbbIMiS91xZf5rGSUjv7xjs7Yx3f118xXXhbZLUpZ1+D9TKQo6NGnH d5e7P66CXabQ3cWOS66ttxhau08pYO6MEZJ8p3+evwNNvSJrj7ryUtuhIxIWhKRoQe4EDvJr4gY/ +F/6ir/p1rXBKlB9W5aRPaU94+wEIz/7UG63HhOthbcl5aCcBSZjhGfJ8avtuHEd1ct99WlWlWmW 4cHxg9rvqMuphyemejkEJmNh11vKUkb7lQwDjy+L+us9odU2qcEsuOBU90EpKcJ7tzkj+zNBtJjQ 1PlhMl4vJGS2JjhUB+rVX63GhugFuS8sKBKSmY4cgbH+VUDDdPhVi4ltYRIkuN8wkYIOyR352x5K +eH0BuXFdwskw3ClIXjUoOK2GTju8Xd4/noJ15u3sKCHpjjaiMgLmrBI/rVWYQGCMhyTj/WnPaqN ckst8QFyWAyhUEgpdUnJ7Z22JBz8xqPS5NjwojTrqmEdMpSVKcUjC9W3cCSQMdnx0ExMYYRDmFmS +HmWlKIEpwlJ0kjI1Vvvy40XldTIaZ5rgab5iwnWs9yRnvJ8lQSCsm/Fw5WYreo4xvyjnvrR/KE8 2wzw4884htpu+xlLWsgJSkaySSe4UFok3GDCdYalzI7Dj6tLKHXQkuHbZIJ3O47vKKN3GC7OcgtT I65bSdTjCXUlxA23Kc5A3H0iub/lBejX66cPqtcxiUW25y0LYcCwHG2kuJGQe/IT9IqFtz8VziGd eLpOl2ti42pUtyRFUQ60FTAlABAJ7koHd3Gg7XWrJuUGG82zKmxmHHf4NDrqUqX+oE71XeMZb0ef ZW3pb8OzuuOibJZcLZSQjLYKxuAVZ/XiqAlqZcHZMm8KlCarhJ59fwziCSHFBOQCNikJJT8UkkkZ NB2OJOiXBkvQpTEloKKStlwLSCPFkeOtioXg9pLPBllSkrIMJlXaWVHJQCdz4t9h3AbDAFTVApSl Ark35bf4C1/zEv8A4N11muTflt/gLX/MS/8Ag3QdE0D9IP1H+emgfpB+o/z1+UoP3QP0g/Uf56aB +kH6j/PX5Sg/dA/SD9R/npoH6QfqP89flKD90D9IP1H+emgfpB+o/wA9flKD90D9IP1H+emgfpB+ o/z1+UoP3QP0g/Uf56aB+kH6j/PX5Sg/dA/SD9R/npoH6QfqP89flKD90D9IP1H+emgfpB+o/wA9 flKD95Y/ST9R/npyx+kn6j/PX5Sg/S2P0k/Uf56/OWP0g/Uf56UNA5Y/SD9R/npyx+kn6j/PSvyg /eWP0g/Uf56csfpB+o/z0r8oP3lj9IP1H+enLH6QfqP89fn0U+ig/eWP0k/Uf56csfpJ+o/z1+Uo P3lj9JP1H+enLH6SfqP89flKD95Y/ST9R/npyx+kn6j/AD1+UoP3lj9JP1H+enLH6SfqP89flKD9 5Y/ST9R/npyx+kn6j/PX5Sg/eWP0k/Uf56csfpJ+o/z1+UoP3lp/ST9R/npy0/pJ+o/z1+UoHLH6 QfqP89OWP0g/Uf56/M/qpn9VB+8sfpB+o/z05Y/SD9R/nr8z+qmf1UH7yx+kH6j/AD05Y/SD9R/n r8z+qmf1UH7yx+kH6j/PTlj9IP1H+evzP6qZ/VQfvLH6QfqP89OWP0g/Uf56/M/qpn9VB+8tP6Sf qP8APTlp/ST9R/nr8+in0UH7y0/pJ+o/z05af0k/Uf56/Pop9FB+8tP6SfqP89eKa9q/RXiqg9xd W96Pk+s37dOse9HyfWb9uuFv/wD+Qd4jSHGH+Go7TzSihxtx1aVIUDgggjIIPirH+6KufyfifXq+ 6lDvHWPejpPrN+3TrHvR0n1m/brg37oq5/J+J9er7qfuirn8n4n16vuq0O89Y96Ok+s37dOse9HS fWb9uuDfuirn8n4n16vup+6KufyfifXq+6lDuSOxJVIFslF0jBUpxCsDyDK9h8wrP1j3o6T6zft1 wb90Vc/k/E+vV91P3RVz+T8T69X3Uod56x70dJ9Zv26w9O8iyxWQ0VPNBgqQCM9lSSRknHiPjrhn 7oq5/J+J9er7qfuirn8n4n16vupQ7z1T/o6V6zXt06p/0dK9Zr264N+6KufyfifXq+6n7oq5/J+J 9er7qUO9dW96Ok+s37dOre9HSfWb9uuIN/l24kdtrtyb4RSuAyvQ5KSXC0hW2xXjAPaTsT4x5a1f 3RV09AQ/rlfdSh3nq3vR0n1m/bp1b3o6T6zft1wX90TdPQEP65X3U/dE3T0BD+uV91Sh3rq3vR0n 1m/bp1b3o6T6zft1wb90VdPQEP65X3U/dFXT0BD+uV91Wh3VSn5EmKTEebS24VKUtSMY0KHiUT3k V+rLzNwddTGddQtpCQUFOxBVnvI84Vwn90Tc/k9D+vV91P3RNz+T8P69X3Uod56t70dJ9Zv26dW9 6Ok+s37dcF/dE3P0BD+vV91P3RVz9AQ/r1fdSkd66t70dJ9Zv26wch5VklNcspdcDxSgkZ7SlEDv x4x464Z+6JunoCH9cr7q/f3RV09AQ/rlfdRXeere9HSfWb9unVvejpPrN+3XBv3RV09AQ/rlfdX5 +6JunoCH9cr7qUO9dW96Ok+s37dOre9HSfWb9uuDfuirp6Ah/XK+6n7oq6egIf1yvupQ7sgvPXBp 1UZ1pCGlpJWU7klOO4nzTX4lT8eTKIiPOJccCkqQpGMaEjxqB7wa4V+6Jufyfh/XK+6n7om5/J+H 9cr7qUO89W96Ok+s37dOre9HSfWb9uuC/uibp6Ah/Xq+6n7om6egIf1yvuqDvXVvejpPrN+3WHkP IskVrllTrQZKkAjPZUkkd+PEfHXC/wB0TdPQEP65X3U/dE3T0BD+uV91B3rq3vR0n1m/bp1b3o6T 6zft1wX90TdPQEP65X3U/dE3T0BD+uV91B3rq3vR0n1m/brEpT8mVF/ebzaG3CpSllGMaFDxKJ7y K4V+6JunoCH9cr7qfuibp6Ah/XK+6g7u4Xmbg46mM48hbSEgtlOxBUT8YjzhX11b3o+T6zft1wb9 0TdPQEP65X3U/dE3T0BD+uV91Et3rq3vR0n1m/bp1b3o6T6zft1wX90TdPQEP65X3U/dE3T0BD+u V91Fd66t70dJ9Zv26wch5VklNcspdcDxSgkZ7SlEDvx4x464Z+6JunoCH9cr7qfuibp6Ah/XK+6g 711b3o6T6zft06t70dJ9Zv264L+6JunoCH9cr7qfuibp6Ah/XK+6g711b3o6T6zft1hfXIkpQ2IL 6PhW1alKbwAlYJ7lZ7hXC/3RN09AQ/rlfdT90TdPQEP65X3UHeJPORNZfQw46lLa0KCCkEElBHeR 5DX71b/o+T6zft1wf90VdPQEP65X3V+fuibn6Ah/XK+6iW711b3o6T6zft06t70dJ9Zv264L+6Ju noCH9cr7qfuibp6Ah/XK+6iu9dW96Ok+s37dOre9HSfWb9uuC/uibp6Ah/XK+6n7om6egIf16vuo O7KU/IkxSYjzaW3CpSlqRjGhQ8Sie8iscyPzZL6XYbkiO602khCkjdKlHxqB8Yrh37om5/J+H9cr 7qfuibn8n4f1yvuoO7plOoSEi3yiAMbrbJ+krr66t70dJ9Zv264N+6Jufyfh/Xq+6n7oq5/J+H9e r7qI7z1b3o6T6zft1iedVJZW05bZZbUMKAcQMj+pdcK/dE3T0BD+uV91P3RN09AQ/r1fdRXdWEL6 tjER1hllhTY1qSe8owNlHxJNfqVPx5MoiI84lxwKSpCkYxoSPGoHvBrhX7om5/J+H9cr7qfuibn8 n4f1yvuoO89W96Ok+s37dOre9HSfWb9uuC/uibp6Ah/Xq+6n7om6egIf1yvuoO9dW96Ok+s37dOr e9HSfWb9uuC/uibp6Ah/XK+6n7om6egIf1yvuoO9dW96Ok+s37dOre9HSfWb9uuC/uibp6Ah/XK+ 6n7om6egIf1yvuoO5zHZEiFIZRb5AU42pAJU3jJGPPqRrz5+6JunoCH9cr7q/P3RN09AQ/rlfdRL ehKV57/dFXT0BD+uV91P3RV09AQ/rlfdVpXoSlefP3RV09AQ/r1fdT90VdPQEP69X3VEeg6V58/d F3T0BD+uV91P3Rd09AQ/rlfdVpXoOlefP3RV09AQ/r1fdT90VdPQEP69X3VEegsVyf8ALZ/AWv8A mZf/AAbqq/uirn6AifXq+6snFvEz3F/BlkvT7LLC3Uzkclok6NPLG5PeT37eUVaHaaU0NefI9dHs U0NefI9dHsVFKU0NefI9dHsU0NefI9dHsUClNDXnyPXR7FNDXnyPXR7FApTQ158j10exTQ158j10 exQKU0NefI9dHsU0NefI9dHsUClNDXnyPXR7FNDXnyPXR7FApTQ158j10exTQ158j10exQKU0Nef I9dHsU0NefI9dHsUClNDXnyPXR7FNDXnyPXR7FApTQ158n10exTQ158n10exQKU0NefJ9dHsU0Ne fJ9dHsUDNM00NedJ9dHsU0NedJ9dHsUDNM00NedJ9dHsU0NedJ9dHsUDNM00NedJ9dHsU0NedJ9d HsUDNM00NedJ9dHsU0NedJ9dHsUDNM00NedJ9dHsU0NedJ9dHsUH5mma/dDXnSfXR7FNDXnSfXR7 FB+Zpmv3Q150n10exTQ150n10exQflKaWvOk+uj2KaWvOk+uj2KBSmlrzpPro9imlrzpPro9igUp pa86T66PYppa86T66PYoPylfulrzpPro9imlrzpPro9ig/KV+6WvOk+uj2KaWvOk+uj2KD8pX7pa 86T66PYppa86T66PYoPylfulrzpPro9imlrzpPro9ig/KV+6WvOk+uj2KaWvOk+uj2KD8pX7pa86 T66PYppa86T66PYoPyvFVe1tLXnSfXR7FeKaBV0sdx8FcJR3vDN0s3PnSE8+1I1uSNLbJ0uDmN4S jVlO6t3F7Jx2qnOQtufJQ5E6NxLqgqNhQ5JzujCiVDHduSdt627ffp1sjqjsdK4yVFYblQ2ZKUqI AJSHUqCSQBkjGdKc5wMBbJM242i73tCJq+G7c1dpSXHLSVcx5eoAMIAU3zENgZGdIQFk7FaUq2+C 2Y0/i6HfoTFraek30BMF6UyjomeYhWW21FJcUQsoSUp7Og4GopKKfH4qu0dhbKnIslK31yVGbCZl KLqwkLVqdQo5OlOd98VoM3KVGu7d0jqQ1LafEhtTbSUpQsK1AhAGkAHxYx4sYoLDZplzs8B1Hhd+ ywWpTiXZltXqeluYSOWnQ4lLqUY1Z1BKQ4o5ytKVV66S2p93mzI8VERmQ+t1uO3jSylSiQgYA2AO O4d3dW3A4kuNtgCCyITkYOqeSiVAYkaVqCQoguIURkIT3eQV8Q7/AHK3yLg9DeQwq4MORpIbZQEq acIK0hOMJBwPigY8WKCSsN6l2uAlvwldLNDcdcV1lsZJckOAN/BrPMbCkoG4GSUlw7dvaWl3WXZL 9eInVTeHYfhSWOdZGyrmOBSRydWtoKQ2N09xTzD2Rr2q9vv0+2R1R2OlcZKtYblQ2ZKUqIAJSHUq CSQBkjGdKc5wMfcXiS6Redl1iVznVPL66K1K+EV8ZY5qVYUrAyRgqwM5wMBcJnELVpkXWzi73fh5 5i9zXVtWVsLZKVFtKUA81o4QW1AdnuV3Dur458vhyBJan8QXS2zfDMxiRNtWXXJjjYa1cwlxs6Ul RKSSokuL2T/KqUXiS6Redl1iVznVPL66K1K+EV8ZY5qVYUrAyRgqwM5wMIvEl0i87LrErnOqeX10 VqV8Ir4yxzUqwpWBkjBVgZzgYCy8QPyOHetkW5ti3yX77cI0huOApstNckpZ3SAprLi8pKQlY06k nSkBERHtHHnFVqhxWUsJaurDalgrW02hiRhKSonGcJyr43ZxnBUFVeJxBdYUiTIZmLL0lXMdcdAc UXMkh0FQJS4CpWHBhQ1HBGTX5Z79OsS3lwOlCnkFC1PRGnzpIKSBzEqwCFEEDGQcHNBuWD+JuKf6 LR/jI1QNWGPJufucvEhqxIXFmL5cq5tx3EpaHMbc5Y0kNIGpKNtOe1gbECq9QKUrIyw7IWUMtLcU EqWUoSVEJSCpR28QAJJ8QBNBjpSsj7DsWQ5HkNLaeaUUONuJKVIUDggg7gg+Kgx0pSgUpSgUpSgU pSgUpSgUpSgUpSgUpSgUpSgUrIph1MdEhTSwytSkJcKTpUpIBUAe4kBScjxah5ax0ClKUClZGWHZ CyhlpbiglSylCSohKQVKO3iABJPiAJrHQKUpQKUrI+w7FkOR5DS2nmlFDjbiSlSFA4IIO4IPioMd KUoFKUoFKUoFKUoFKUoFKUoFKUoFKUoFKUoFKUoFKUoFKUoFKUoFKUoFKVkfYdiyHI8hpbTzSihx txJSpCgcEEHcEHxUGOlKUCunM/6KLD/OXH/pVzGuns/6KLD/ADlx/wClRJeiKUpRSlKUClKUClKU ClKUClKUCqdb5XEk283Zgvp6MPYirbCdQSCrIHZxj4oyQrdJAzuRbXWw6ytpRUErSUkpUQcHyEbi oqJGmMPWp6HIZbgqYSZTGkBS1FJxjs7AZRgBQACcYrtpZxjjPS7Zyhs264mQox5ACJSBuMYCwMZI Hi7xkeLI7wQTv1Q+Erk9fcPy5KpK0TlIS9oCCUpRqBwkD5/nwog7Eir73VnWx25UYZbospUDYuDb Fw5cJ8+2QUMvzFZWR3Np2yhA/kpJGcDx/MEgT1c2ke7cl9e5EYYQtbaQVFboQN8bDP66wvXaTEV+ +oBaQBkq5udvKNsH6a11NOG73OQhuO4llKStLwzkaR3fPtXzcHmHLTJaQ4lLSmEvtNleS2onSpA+ bv2/VQWClK+VISogqGcUH1RpD7+vkRnHAhWlRCkgZwD4yPKKV+xbj0SJLYC0rW7qSoMqWMaUjxfq PjoNSXM6B9DEllbbriFLSkqRlSUjJI7XirZrBcZ7cuG/zWlOyOUpLKkw1pUMg7ZOe/byVnos10p8 uOIZbLjq0oQnvUo4Ar4irt0lgOvX1tlZUoaA80MAKIHeM92K1Lu046IehIIRI1KJSSBhCsHABPfj xd+K54vh9aBCK585Cpi20NIXGbSrUskAEF0EHKSD5MVYi2ZmI7ulQpTcqOhSHm3FhI16CDg48eK2 arXDUNcYxweatLbTzZddZLalfCDTkHbB3IwTkHO2am7jbYd3tz9vnx0SIr6dLja+4j/2IO4I3BAI 3qK2qVF8PcP27hiztWy2M8thvdSjutxR71qPjUcf8AMAAVKUEc1e4T9xMFnqXHApSC4iK6WQpOdQ 5unRkEEEatiCO/apE1XbOxIhW2Jw3NtDz8ViMIipmppUd5tKMAlJXr7QGCnQQCSMkDUa3I4cg2mJ aWHOG40gv32StcRllnL7eiWprOohJCUFJAJ2AwN9qDo1K5teeHL2/ZW2W7e8pxlqQu3JiiKXIbi3 FqQha3f4NKEchKeScgoVg4CDX3d+E75Js7yGXZLyly7mtMFSmQ0hLzcoNqBwFZUXUbFRxrOQMbB0 alUaVZbvC4rYuyY8m6BKmFvKacbQSoNTEKDaFrAQlPOawM9xzlStRMRKst6uHCFqYRaZiJcC29NG DaIodYlIBQpSlvHKUEobUhbJCiMnPxaDqFKi+ILOu+Wd2E1cJlvfPaalRHVIW2sdxOCNSfKk9/zH BG1bYKbZbmIaZEmQGk6edJdLriz4ypR3JJ/qHcABgUH3MlsW+DImSnOXHjtqddXgnShIyTgbnYeK sNvuse58zkNzEcvGrqYbzGc57uYlOe7xZx/XWDiWI/cOFrvCit8yRIhPNNIyBqUpBAGTsNz46qc6 w3S4RFNpi3Vq1h9pa4EmSzKkOkJdCiC8txspypghK1YHKUQArBUHQDQ1RmOHX2nrHyrbJTKiKCur eVGIbZLpVylrQEuJKUFQShocsFQQStGa0U8KzXosSMuzIbLaY7d0W4Wim5uJkx1qeOFEuAJbfOXA FfCbAlShQdGpVAncLOt9dEYsqDZ3J/UNx4TERSwenZQlSUPjlpTqDwVsF5042JzgHD10c4fmx7jZ lz7zKtfKYuC3GXFR1GGltTRWtesEuBw9nKTzM53VgOjUqjTuG7kLy7JkCTfIGmNzmZHThUhKRKBb 0gIQQlbrS+3juyCSAKyWyxyItxivXCydazt0aMtL8GfDurGy1AJw2tlPwWr+BwNkpyF1pVDl8Hpi Rr25arO1HkOXGK7FVCbYQ7yEGMpegqwkYU24dKtiRkg53tFi8JdEvwnztXMPJ6jl8/RgfwnK+D1a tWNO2nTntZoJSlQNj4aNluM+UbxdZqZCvgWZktbqI6NjpAUTk5z2jvjA8pVPUEfOvcK3PpYe6lx4 pCy3GiuyFJScgFQbSrSCQcZxnScdxxIVBHrbNcri8zbJNxZnvpkAxltJU0oNIbKVBxadsNgggnvI IGAVUy+cOTY0fiO4PtzOb01wdXJ1R0tONLbc5beoJ569IU2NCyEgoyDhCAQ6hXiqvRl04XfnKaVF 4cehWwSWVLtzKIevUlqQFOhtSlMnPMZTk9rsdw0pNec6BV0sdx8FcJR3vDN0s3PnSE8+1I1uSNLb J0uDmN4SjVlO6t3F7Jx2qe+4l6Q44hlDKVqKg02VFKAT8UaiTgd25J+c1v2+/TrZHVHY6VxkqKw3 KhsyUpUQASkOpUEkgDJGM6U5zgYC2SZtxtF3vaETV8N25q7SkuOWkq5jy9QAYQApvmIbAyM6QgLJ 2K0pVt8Fsxp/F0O/QmLW09JvoCYL0plHRM8xCsttqKS4ohZQkpT2dBwNRSUU+PxVdo7C2VORZKVv rkqM2EzKUXVhIWrU6hRydKc774rQZuUqNd27owpDUtp8SG1NtJSlCwrUCEAaQAfFjHixigsNmmXO zwHUeF37LBalOJdmW1ep6W5hI5adDiUupRjVnUEpDijnK0pVXrpLan3ebMjxURGZD63W47eNLKVK JCBgDYA47h3d1bcDiS422AILIhORg6p5KJUBiRpWoJCiC4hRGQhPd5BXxDv9yt8i4PQ3kMKuDDka SG2UBKmnCCtITjCQcD4oGPFigkrDepdrgJb8JXSzQ3HXFdZbGSXJDgDfwazzGwpKBuBklJcO3b2l pd1l2S/XiJ1U3h2H4UljnWRsq5jgUkcnVraCkNjdPcU8w9ka9qvb79PtkdUdjpXGSrWG5UNmSlKi ACUh1KgkkAZIxnSnOcDH3F4kukXnZdYlc51Ty+uitSvhFfGWOalWFKwMkYKsDOcDAXCZxC1aZF1s 4u934eeYvc11bVlbC2SlRbSlAPNaOEFtQHZ7ldw7q0Gru7YZFytE6/Xe23OPcXzKnWsF1UxWUpws lxtRCVIWpJJOearZO+a9F4kukXnZdYlc51Ty+uitSvhFfGWOalWFKwMkYKsDOcDGOJf7lCkSZLTy FSpCuYuS8yh14LyTrS4sFSF5JOpJBzg5yBQXC4S5dmv1/aiXF/h+0M3iWjn21JQ8+rUAllKUrQFp bAzgkBAWrfK0pVoxOLIg67ppt04a5896UPA6AvW25p0Mqw412W9KtPePhFYCfHAwOJLjbYAgsiE5 GDqnkolQGJGlagkKILiFEZCE93kFY4l+nQZEl+N0rT0hWsuJiNamlZJBaOnLRBOxb04wMdwwFluL DUW+flHjsNIaZaQ6htttISlCRcGAAAO4AeKqRUlEvBhWafb24MUqmpDbkpRc5oQFoXoA1aMam0nJ STud6jaC92a7eC+AYP8A8w3q0cy6S/4sb1c3DUb4/wAK33Z27+893jjLPJi3Piq8yEQERmZUO4vM stOKR03wDriQkoKcgAaMEaSkkafJXlzJC4DMFTmYzLq3kIwNlrCAo579w2j6PnNbdnv06xLeXA6U KeQULU9EafOkgpIHMSrAIUQQMZBwc0G/ERbYHDEW4S7aicuZMfjL1vLQplDaGVAtFJACzzlbrSsd lPZ7wZK9IaXx9xrzbG9dcOzinlLWnpFc04fVpBylPjB233NQUXiS6Q+d07rKOa6p4YjNfAuHvWz2 fgVbDdvSeynzRjXcvVycnzp3WvIkz+Z1S2lcvnBw5WlQTgFJPenu+ag0asvBcrkz7gwGGVF+1zgX Vo1LQkRHjhOdk5OMkDO2AQCoGtVJWe/TrEt5cDpQp5BQtT0Rp86SCkgcxKsAhRBAxkHBzQS9guNx t9oK0XaVZLcH18yXB1CRKWUow2AFp5gQBq3ICA4rfK0pVA3SW1Pu82ZHioiMyH1utx28aWUqUSED AGwBx3Du7q34/FNzix1x0Jt62Vvrkct62xnUoWsJCigLbOgEJTsnA2G1Y7bf5Ftl3KUhPws6K9GU lohpvDo0qyhIAKQCSEjACgg9ydJCJqwxBBtnDEW5P2qLcXpcx+OUynHgltLSGVAp5S0HJLpzkn4q cY3zXqk7ffp1sjqjsdK4yVFYblQ2ZKUqIAJSHUqCSQBkjGdKc5wMBJN+C7dYGboLOxN6yfJYQ3Oe dPJbbSypOC0pvKjziCSMHSMBO+bCrh2zW52bBVb0Sizcbu2l991wOaIbCHW09hSU4UchR05wo6Sk 4Ip8XiS6Redl1iVznVPL66K1K+EV8ZY5qVYUrAyRgqwM5wMY08QXVIIMxayVSVqU4AtSlSGw28So gklSQBk/rGDvQXhdhskeLGPgllxUtqRNKlvPZa5dvjyw0nCx2CtxaDnKtJ+MFdqoF+BDiXe4oasD 1xacs7ctDbLrgEFbrDTpdyMkobKyAFnuxqJO5iV8S3dxDKVS8pZaWy2OWjZC2ER1Du8bTaE/1Z7y TWuq9XJTzjyZrzbjsVMNwtK5etlKEoDatOMp0oSCD343zQaNWXh6wR+IoDjKVdJJiulxb6gVdShQ ASw2nIBfyhZQjbmalbp0DNarOuZIXAZgqczGZdW8hGBstYQFHPfuG0fR85oLhb4lgXaF3hxi0Rky 7jIaZjXRyatLLSEtKSlCo4ySOaQor78JxjtVglt8PWm0dZEtqLqh27TY0Z6Y86lKo7aWSgqSgoOv t5zkd6spO2mJRxVdkvynnHIshUp9clwSoTL6eas5WpKXEEIKts6QM6U57hjQlXObNYDMqSt5Ifdk 5cOpRdcCQtRUdyToT3nxfOaC4TeEbYxIlQ0F/wDe8+9Mh0r7a0RI6HGgrbHxs5wBnUfmxkXZ7RbW 2n5ES0NMvsRSh26PTFJWsxGHXAhMftA6ntSis4OtISBpVVaRxXeUPyn+qQtyU+uQ6XI7a+2s/CFI KSEhY2WE4C09lQI2o3xXeW1urEpBUtWtKlR21FhQASCzlPwJASgAt6cBCAPipwFliiDw9J47tSbV FnNQULbQ7KW7rcQmawgIVy1pGO5WQAcjvxtUDEEG2cMRbk/aotxelzH45TKceCW0tIZUCnlLQcku nOSfipxjfOgi/wByRd5V0LyFypalrkc1lC23ipWo6m1AoUNWFYIwCARggY/bffp1sjqjsdK4yVFY blQ2ZKUqIAJSHUqCSQBkjGdKc5wMBO9dbYnBMF1VnRMQu7TuQ1MkLKW0cuL8bllBUv4ozkD43ZOR pguIre1aOJrtbY6lqZhzHo7anCCopQspBOABnA8la8q5zZrAZlSVvJD7snLh1KLrgSFqKjuSdCe8 +L5zWObMkXGfInS3OZJkuqedXgDUtRJJwNhuT3UFm4Gvl2gT5MSHdJseMYE94ssyFoRzExHSF6Qc agUpIPf2R5K+7YpqdDcu9/Xb5D0l9TQmXuRMcLpQhGUoEftApC05KyQQpATjSrNWiTJEB5T0ZzQ4 ppxknAPYcQULG/lSoj+utu33+5WuOpmI8hKNXMQVsocUyvABW0pQJbXsntIIPZTv2RgJ6LbYts45 4itCErdZjMXRhlxbqkuJ5TLpSrKCkEkIwQQUkKUMb7akXwXbuEYVxfs7M+ZInyWMyHnUthtDbCh2 W1JJVlw4OoDBVkK2KdSLxVdodynXFtyKuXOUtUh16Ey6VFerXjWghIUFqBCcAg4O1aEq5SpccR3V IDKX3ZCW22koSlbgSFkBIGAQhOw2GNgKC6RRB4ek8d2pNqizmoKFtodlLd1uITNYQEK5a0jHcrIA OR342rQsVvtDfDLVynqtHOkTHo4TdDM0hLaGlAo6YZzl06tR8ScfyswKL/ckXeVdC8hcqWpa5HNZ Qtt4qVqOptQKFDVhWCMAgEYIGP2336dbI6o7HSuMlRWG5UNmSlKiACUh1KgkkAZIxnSnOcDATMqP YLVAXLYh+FIcq6S4jLrzrjbiY7QaKFo06QFqDpJK0qGQns94Oe9IaXx9xrzbG9dcOzinlLWnpFc0 4fVpBylPjB233NQUXiW7xOcW5etx11T5dfbQ64h1Xe4hawVNrOAStJCiUpOeyMa7l6uTk+dO615E mfzOqW0rl84OHK0qCcApJ7093zUGjVwtU2ZbuFLYq33pdlXLuMxEiW2462FJQ1HKAstAqUAVrwMH BWe7JNU+pK33+5WuOpmI8hKCsuIK2UOKZXgDW0pQJbXsntIIPZTv2RgHETDsXia6x5DUVp5qY8hx uIkpZQoLIIbB7kA9w8mKjazzZki4z5E6W5zJMl1Tzq8AalqJJOBsNye6sFApSlApSlApSlAq0x7p cbJwTb5FqnyoD0m4y0PuRXlNKdShuOUBRSRkJK14B7tSsd5qrVJ2+/TrZHVHY6VxkqKw3KhsyUpU QASkOpUEkgDJGM6U5zgYDXuinXLvNXIhohPKfWXIrbRbSyrUcoCDukA7Y8WMVPWC43G32grRdpVk twfXzJcHUJEpZSjDYAWnmBAGrcgIDit8rSlVaffdlSHJEh1brzqitxxxRUpaickkncknx1JQOJLj bYAgsiE5GDqnkolQGJGlagkKILiFEZCE93kFBqXSW1Pu82ZHioiMyH1utx28aWUqUSEDAGwBx3Du 7qtNkkRLRwjHni73O0zJU+QyqRbY4cccbbbZIQVF1spSC4o4GQokZ+InFeh3+5W+RcHobyGFXBhy NJDbKAlTThBWkJxhIOB8UDHixS336fbI6o7HSuMlWsNyobMlKVEAEpDqVBJIAyRjOlOc4GA17pb3 bRd5ttkKQp6I+thxTZJSVIUUkjIG2R5KmrDepdrgJb8JXSzQ3HXFdZbGSXJDgDfwazzGwpKBuBkl JcO3b2jYfEF1gSLhIjzF864sOR5bjgDinkOEFYJUCckjv7/npb79PtkdUdjpXGSrWG5UNmSlKiAC Uh1KgkkAZIxnSnOcDAWyTNuNou97Qiavhu3NXaUlxy0lXMeXqADCAFN8xDYGRnSEBZOxWlKq85Gt 18nz7h4TtdlbelOLbhOofVy0E6gE8plSdIzgd3d3Dascfiq7R2FsqciyUrfXJUZsJmUourCQtWp1 Cjk6U533xUS+8qRIceWEBTiishtCUJBJzslIAA+YAAUFwtPEce1WAWhriW9W1xme+8X7S0VNyUKS 0lJOXWlDHLURkdyvFuKjJdi/+L3Nm78SW+PPjzHWXzJElxTq0qwpYUhpWQTnckHyitG336dbI6o7 HSuMlRWG5UNmSlKiACUh1KgkkAZIxnSnOcDGg++7KkOSJDq3XnVFbjjiipS1E5JJO5JPjoLLZeHI t9YkRWpCG3oT6lKmJClJmIUAENMpVpJeJQsttkAualZKdG+9b4lgXaF3hxi0Rky7jIaZjXRyatLL SEtKSlCo4ySOaQor78JxjtVT1zJC4DMFTmYzLq3kIwNlrCAo579w2j6PnNSaOKrsl+U845FkKlPr kuCVCZfTzVnK1JS4ghBVtnSBnSnPcMBLS2+HrTaOsiW1F1Q7dpsaM9MedSlUdtLJQVJQUHX285yO 9WUnbTqXLhu3Rr9d4Ph+FCbhT3ozaJqH1OLQhRAUS00pO/8AVuDsNqhZVzmzWAzKkreSH3ZOXDqU XXAkLUVHck6E958Xzmsc2ZIuM+ROlucyTJdU86vAGpaiSTgbDcnuoLLZoFtjwHZE4WV1pcpxhmXc HJnLe0BJPKQwkLTgLSSXO8LSAAUqzNK4ds1vdmwVW9Ess3G7toffdcDmiGwh1tPYUlOFHIUdOcKO kpOCKZb7/crXHUzEeQlBXzEFbKHFMrwBraUoEtr2T2kEHsp37Ix9u8S3d5515yXlx12U8s8tG65K Ah4938pIA+bxYoLDebfZrFAiTDaUSk3JSSptT7iTGSYsZ4hkhWxzJWAXA5shGQe1qmr3IiWife54 u9ztMyTxHcWVSLbHDjjjbZaIQVF1spSC4o4GQokZ+InFIa4rvLQwmUglKW0tqXHbUpnQ2ltKmlFJ LawlCBrRhR0JJJIBojiq7JflPOORZCpT65LglQmX081ZytSUuIIQVbZ0gZ0pz3DAXDgvh02ji6Hq dtki5Rb6ILzb0tpHJQ24gKcbbcIU4peVJSQOzoJA1FJRzl9lUeQ4ysoKm1FBLa0rSSDjZSSQR84J BrOzc5se7t3VElZntviSH3DrUXQrVqOrOTnffOa1KDo35PrFAuNinKnNrSme+mC474TYj6IyCh95 1KHEkqLXLbKsd6XPFpJqbvkxVx4PjTltobVJuF3eU226HUpKloOAtOygM/GGx765bGvM+JGbjsP6 Gm+fpToScc9sNO94/lISB82MjB3roDP+iiw/zlx/6VB6IpXx0jnyPZ9dinSOfI9n12KvRH3SvjpH Pkez67FOkc+R7PrsU6D7pXx0jnyPZ9dinSOfI9n12KdB90r46Rz5Hs+uxTpHPkez67FOg+6V8dI5 8j2fXYp0jnyPZ9dinQfdK+Okc+R7PrsU6Rz5Hs+uxTodX1WsIEcJSlIdCU7JAeXgf21n6Rz5Hs+s xTpHPkez6zFOke404dmt1vIMOMlgAlQCCQMkYJx5cVvGvnpHPkgz67FOkc+R7PrMVZm+8j7pXx0r nyPZ9dinSufI9n12KVBbWk2yJLd5jzRKsYylak5+gjNYkWK2ocS4I2VJORqcUofQTW90rnyPZ9di nSufI9n12KVBb7pXx0rnyPZ9dinSufI9n12KVBb6pXz0rnyPZ9dinSufI9n12KVBb6pXz0rnyPZ9 dinSufI9n12KVBb7NYg2U7IfkoGSdKJC0jffuBxX10rnyPZ9dinSufI9n12KVBb9SlKEBCRhKRgD yCv2vnpXPkez67FOlc+R7PrsUqC31SvnpXPkez67FOlc+R7PrsUqC31SvnpXPkez67FOlc+R7Prs UqC31SvnpXPkez67FOlc+R7PrsUqC31SvnpXPkez67FOlc+R7PrsUqC31SvnpXPkez67FOlc+R7P rsUqC31SvnpXPkez67FOlc+R7PrsUqC31SvnpXPkez67FOlc+R7PrsUqC31SvnpXPkez67FOlc+R 7PrsUqC31SvnpXPkez67FOlc+R7PrsUqC37SvzpXPkez67FOlc+R7PrsUqC37SvzpXPkez67FOlc +R7PrsUqC37SvzpXPkez67FOlc+R7PrsUqC37XiqvanSufI9n12K8V1JUpWxOEgT5Ils8iSHVc1r lBrQvO6dAACcHbSAMd2K16gUpSgUpSgUpSgUpSgUpSgUrbbtdwdtrtybgylwGV6HJSWVFpCttivG Ae0nYnxjy1qUClKUClKUClKUClKUClKUClKUClKUClKUClKUClKUClKUClKUClKUClKUClKUClKU ClKUClKUClKUClKUClKUClKUClKUClKUClKUClKUClKUClKUClKUClKUClKUClKUCuns/wCiiw/z lx/6Vcwrp7P+iiw/zlx/6VB6wpSlApSlApSlApSlApSlApSlApSlApSlApSlApSlApSlApSlApSl ApSlApUbP4hstpfSxcrvAhvKTrS3IkobUU5IyASNsg7/ADVq+7ThX5S2f7c17VKkTlKgvdpwr8pb P9ua9qnu04V+Utn+3Ne1VqRO0qC92nCvyls/25r2qe7ThX5S2f7c17VKkTtKgvdpwr8pbP8Abmva p7tOFflLZ/tzXtUqRO0qC92nCvyls/25r2qe7ThX5S2f7c17VKkTtKgvdpwr8pbP9ua9qnu04V+U tn+3Ne1SpE7SoL3acK/KWz/bmvap7tOFflLZ/tzXtUqRO0qC92nCvyls/wBua9qnu04V+Utn+3Ne 1SpE7SoL3acK/KWz/bmvap7tOFflLZ/tzXtUqRO0qC92nCvyls/25r2qe7ThX5S2f7c17VKkTtKg vdpwr8pbP9ua9qnu04V+Utn+3Ne1SpE7SoL3acK/KWz/AG5r2qe7ThX5S2f7c17VKkTtKgvdpwr8 pbP9ua9qnu04V+Utn+3Ne1SpE7XgCvcXu04V+Utn+3Ne1Xh2pQVdLHcfBXCUd7wzdLNz50hPPtSN bkjS2ydLg5jeEo1ZTurdxeycdqpzkLbnyUOROjcS6oKjYUOSc7owolQx3bknbetu336dbI6o7HSu MlRWG5UNmSlKiACUh1KgkkAZIxnSnOcDAWyTNuNou97Qiavhu3NXaUlxy0lXMeXqADCAFN8xDYGR nSEBZOxWlKtvgtmNP4uh36Exa2npN9ATBelMo6JnmIVlttRSXFELKElKezoOBqKSinx+KrtHYWyp yLJSt9clRmwmZSi6sJC1anUKOTpTnffFaDNylRru3dI6kNS2nxIbU20lKULCtQIQBpAB8WMeLGKC w2aZc7PAdR4XfssFqU4l2ZbV6npbmEjlp0OJS6lGNWdQSkOKOcrSlVeuktqfd5syPFREZkPrdbjt 40spUokIGANgDjuHd3VtwOJLjbYAgsiE5GDqnkolQGJGlagkKILiFEZCE93kFfEO/wByt8i4PQ3k MKuDDkaSG2UBKmnCCtITjCQcD4oGPFigkrDepdrgJb8JXSzQ3HXFdZbGSXJDgDfwazzGwpKBuBkl JcO3b2lpd1l2S/XiJ1U3h2H4UljnWRsq5jgUkcnVraCkNjdPcU8w9ka9qvb79PtkdUdjpXGSrWG5 UNmSlKiACUh1KgkkAZIxnSnOcDH3F4kukXnZdYlc51Ty+uitSvhFfGWOalWFKwMkYKsDOcDAXScq JYfCUkT5tgmPX2fGUbMwHfg2uUQ0FlxopQkuKwAAFbEjsJxCy25vB1o5cZ5Dc/wtNgzHWhqS8hhL OGzqHabJcWSkjC8jUDpGIWLxJdIvOy6xK5zqnl9dFalfCK+Msc1KsKVgZIwVYGc4GPiJxBdYUiTI ZmLL0lXMdcdAcUXMkh0FQJS4CpWHBhQ1HBGTQWiIiPaOPOKrVDispYS1dWG1LBWtptDEjCUlROM4 TlXxuzjOCoKwWSREtHCMeeLvc7TMlT5DKpFtjhxxxtttkhBUXWylILijgZCiRn4icV2z36dYlvLg dKFPIKFqeiNPnSQUkDmJVgEKIIGMg4OayReJLjE5wbEJbbrqni0/AYdbQtXeUIWgpbzgA6QMhKR/ JGAk4lvdtCONbbIUhT0SHyHFNklJUidHSSMgbZHkqrVYY8q7q4cvEoWhclmavlzLw4h5ak/CNuaC vVoBK0oOSCrtd+4qvUFpj3S42Tgm3yLVPlQHpNxlofcivKaU6lDccoCikjISVrwD3alY7zW3EjxT 10+82yywXH5zzYbuHVtttrTpK2mmo41I0axnWe4pCcaVZr1vv062R1R2OlcZKisNyobMlKVEAEpD qVBJIAyRjOlOc4GNq03jiJ6WuLblPTZkl1T6R04kvh0jKnGypKloXsCVoIV2QSeyMBL2+N4D494j tMN98RmYt2iHUvdxtDD2AvGAd0JPdjIB8VRnBr7rV2mobdWhD1puCHEpUQFp6V1WD5RlKTjygHxV 8I4jvlqvVzkuBlNxlOuCYZUBlawtWoOJwtB0Z1KCkgDOcEbUsV2vbd1fFmiMPzpusFpu2MvqIKVa 0oQUHSkpUoFKQBjYjAoIGrbwNfLtAnyYkO6TY8YwJ7xZZkLQjmJiOkL0g41ApSQe/sjyVXWmJt5u RbiRFyJchalhiKxuTuo6UIGAAMnAGAB5KyWcXJdxDVoZeemPNOspbYa5i1oW2pKwE4OewVfq79sU E6udGPDkW+XWD4ZusufIYW/PlPEFttqOU5CVpUVDXgHVgDIIPZKcltiWREeTMUxbxAdmOtQ3r25K KloQEnSExRssBaSoqODqTpxpVmvRRcrq3Gs8Nl6VpdceZjMNa1lakp1kADJ7Laf1af11t2O43xCx brMhb7ziy4y03FS+62vG62spKm14SCVIwewk57IwE1d7ba+FesxbGLni8zYCOucdGhtjlaSOUtHa PNOc5GwwBvlaYFiRYBdHxa0dTPfYabvDktehttLSk6TFSMq+FIUVAA4TpA3qMgX3iGfcn24rKLlL mvuSVMOW5qUVOq7S1IQpCgkkDJ0gZCRnZIxjtN3v78tcSE14TkynVPcl+C3OWpwjK1pS4hZCiBlR G50jOcDAZI7NtTd7+3BtMq9wG2JHSOha0KjoCuxJXpTuEjBIUAO1viq9UlAfvc65Potztwfnz0uI eTHUtbshKu0sK07rBwSQc5xk1G0ClKUClZ4cKXcZaIkGK9KkuZ0MsNla1YGThI3OwJ/qrBQKVkfY diyHI8hpbTzSihxtxJSpCgcEEHcEHxVjoFKUoFK227XcHba7cm4MpcBlehyUllRaQrbYrxgHtJ2J 8Y8talApSlApWRTDqY6JCmlhlalIS4UnSpSQCoA9xICk5Hi1Dy1joFKVkZYdkLKGWluKCVLKUJKi EpBUo7eIAEk+IAmgx0rPDhS7jLREgxXpUlzOhlhsrWrAycJG52BP9VYKBSsimHUx0SFNLDK1KQlw pOlSkgFQB7iQFJyPFqHlrHQKUrIyw7IWUMtLcUEqWUoSVEJSCpR28QAJJ8QBNBjpSlApSlApSlAp SlApSlApSlApSlApSlApSlApSlApSlApSlApSlApSlApSlArpzP+iiw/zlx/6VcxrpzP+iiw/wA5 cf8ApUSVKpSlfdeApSlApSlApSlApSlApSlApSlApSlApSlApSlApSlApSlApSlApSlB1j8vn/fu F/Rrf/NdrlldT/L5/wB+4X9Gt/8ANdrllefQ/pw9WXcpSldkKUpQKUpQKUpQKUpQKUpQKUpQKUpQ KUpQKUpQKUpQKUpQKganqga8PjP7W8CrpY7j4K4SjveGbpZufOkJ59qRrckaW2TpcHMbwlGrKd1b uL2TjtVOchbc+ShyJ0biXVBUbChyTndGFEqGO7ck7b1t2+/TrZHVHY6VxkqKw3KhsyUpUQASkOpU EkgDJGM6U5zgY8TotkmbcbRd72hE1fDduau0pLjlpKuY8vUAGEAKb5iGwMjOkICyditKVbfBbMaf xdDv0Ji1tPSb6AmC9KZR0TPMQrLbaikuKIWUJKU9nQcDUUlFPj8VXaOwtlTkWSlb65KjNhMylF1Y SFq1OoUcnSnO++K0GblKjXdu6R1IaltPiQ2ptpKUoWFagQgDSAD4sY8WMUFhs0y52eA6jwu/ZYLU pxLsy2r1PS3MJHLTocSl1KMas6glIcUc5WlKq9dJbU+7zZkeKiIzIfW63HbxpZSpRIQMAbAHHcO7 urbgcSXG2wBBZEJyMHVPJRKgMSNK1BIUQXEKIyEJ7vIK+Id/uVvkXB6G8hhVwYcjSQ2ygJU04QVp CcYSDgfFAx4sUElYb1LtcBLfhK6WaG464rrLYyS5IcAb+DWeY2FJQNwMkpLh27e0tLusuyX68ROq m8Ow/Cksc6yNlXMcCkjk6tbQUhsbp7inmHsjXtV7ffp9sjqjsdK4yVaw3KhsyUpUQASkOpUEkgDJ GM6U5zgY+4vEl0i87LrErnOqeX10VqV8Ir4yxzUqwpWBkjBVgZzgYC6TlRLD4SkifNsEx6+z4yjZ mA78G1yiGgsuNFKElxWAAArYkdhOIWW3N4OtHLjPIbn+FpsGY60NSXkMJZw2dQ7TZLiyUkYXkagd IxCxeJLpF52XWJXOdU8vrorUr4RXxljmpVhSsDJGCrAznAx8ROILrCkSZDMxZekr5jrjoDii5kkO gqBKXASrDgwoajgjJoLvOatnC/hIxLnc7K4b9PhodtrPNcUyzytDZWp1CkpHMJwCdRwVfFTULY1X uzcWOcNi+3CFEjTHPCBt8tbaQhrPOcSNskIbURsSdIGCdqgrffp1sjqjsdK4yVaw3KhsyUpUQASk OpUEkgDJGM6U5zgY127nNanPTRJWqU+l1Drrh1qWHUqS5knOSQpW/fvnvoJ6JcHbujjW5SEoS9Lh 89xLYISFLnR1EDJO2T5aq1T0By4x+FLoqNY+ZDkaWJN05Tx5aQttYb1BXLHaSjvTntd+4qBoFT3C P8cyP6LuH+DeqBqW4bfnMXxo263eEpLjTzPScta+ahbSkLGEEK+KpR2IxjNAskOPI6uS831SojXO TBSSFP47ySMHQkDUrSdWO7A1LRNcNS7W5aeKnrjBlOvLhhxwxZDcdBQZUfspRylBJ1EHI2wNISO8 Vt9yTBu7jiGV26Uw+VBpsrQqMtKvijUSoFJGNzkY781mhO3W4TJcW3MLefuSSh2PFjAlxIWHSEoS OyAWwcJAwE+Sgm+E3rS3YeJROhTXnBASVqYmIaBb6qOAkAtKwrVg6skY2x46cJvWluw8SidCmvOC AkrUxMQ0C31UcBIBaVhWrB1ZIxtjx1A2sXJ9x+32tl592c1yVsMNcxbiEqS5gAAnYtpO3m+TNLWL k+4/b7Wy8+7Oa5K2GGuYtxCVJcwAATsW0nbzfJmgnuE3rS3YeJROhTXnBASVqYmIaBb6qOAkAtKw rVg6skY2x46cJvWluw8SidCmvOCAkrUxMQ0C31UcBIBaVhWrB1ZIxtjx1A2sXJ9x+32tl592c1yV sMNcxbiEqS5gAAnYtpO3m+TNLWLk+4/b7Wy8+7Oa5K2GGuYtxCVJcwAATsW0nbzfJmgnuE3rS3Ye JROhTXnBASVqYmIaBb6qOAkAtKwrVg6skY2x46cJvWluw8SidCmvOCAkrUxMQ0C31UcBIBaVhWrB 1ZIxtjx1A2sXJ9x+32tl592c1yVsMNcxbiEqS5gAAnYtpO3m+TNLWLk+4/b7Wy8+7Oa5K2GGuYtx CVJcwAATsW0nbzfJmgnuE3rS3YeJROhTXnBASVqYmIaBb6qOAkAtKwrVg6skY2x46z2O4+CuEo73 hm52bnzpCefaka3JGltk6XBzG8JRqyndW7i9k47VatYuT7j9vtbLz7s5rkrYYa5i3EJUlzAABOxb SdvN8mayW+/TrZHVHY6VxkqKw3KhsyUpUQASkOpUEkgDJGM6U5zgYC0RHOi484qhCBCYK2rqgpaT rDCUsSDoaJAATkDcJBwkAYBUDE8FyuTPuDAYZUX7XOBdWjUtCREeOE52Tk4yQM7YBAKgdC3cS3S2 S5Uth1lyTK1c56VGakLXqCgrtOJURqClBWPjZ3zS3cSXG1S5UmIISHZWoOFcBhYAUFBSUhSCEJIU oFKQAQcYxigl+E3rS3YeJROhTXnBASVqYmIaBb6qOAkAtKwrVg6skY2x4604iLbA4Yi3CXbUTlzJ j8Zet5aFMobQyoFopIAWecrdaVjsp7PeDEi5SkmcUKQ2JydEhLbSUpUnmJcwEgYSNSEnCcYxju2r bgXi72mADGOiM46otOuR0L5boCdSmlqSS2sAtkqQQrZBzsmgtl4vUu2cXcQNeErpZobl5nK622NE uSHA4n4NZ5jYUlA3G5KS4du3tgjzLtF/KHcbPGuU2z20XOQ7MYtctbbbDSFKU6pAAAOltBx2ckJA 09wqvI4quyX5TzjkWQqU+uS4JUJl9PNWcrUlLiCEFW2dIGdKc9wxr2568TLytcASpdzlJeQrQgvO uhxCg5tgkkpUvJ7+8/PQXjgsG7cXQ+JFG1ruU2+gusPSWm+mQXELUttpxWpxStakpxnToOMqKVIq dsholdZaZbbCEx9bxuDZSpMYpwkla05C2lEJTsSclJb1FRQ5EQpki3T486I5y5MZ1LzS8A6VpIIO DsdwO+v3rZHQdCHMRubzlISANS8YBUe9WBnGe7UrGNRyEtYP4l4p/oxH+MjVA1PQHLixwpdFRrFz IcjDEm6cp48pIW2sN6grljtJR3pz2u/cVA0Fh4evVxjBFvhXddmZ1OyJEuM6ppx1IbB0EhQCyAgh tJI7ThGRqyIm6S2p93mzI8VERmQ+t1uO3jSylSiQgYA2AOO4d3dWOJMkQHlPRnNDimnGScA9hxBQ sb+VKiP66wUFsYmw4XANsXJtbNwcVdJoQmQ64ltI5UXJw2pKiruwdWANWQcgp2LfF8B8e8R2mG++ IzMW7RDqXu42hh7AXjAO6EnuxkA+KoGBxJdLbAEBh1lcMOqe6eRGafb5igkFelxKhqwkAHvA1Yxq OVu4lulslypbDrLkmVq5z0qM1IWvUFBXacSojUFKCsfGzvmgnrfDjyOAYUl5vqlRJ855MFJIU/hq LkkjB0JA1K0nVjuwNS0RHCaWnLnMbca1arXOKVBxaFNqTGcWCClQznTpIOQQogitFd5nq5Ol/k8i UuYzyEJa5Tq9GpSdIGn+DRgDYY2ArbtF9u0KdLetrMVT8hDi3QLcy7hGlRc0pUghCNBXqCQBp79h QSfCb1pbsPEonQprzggJK1MTENAt9VHASAWlYVqwdWSMbY8dVKtsXKUkzihSGxOTokJbaSlKk8xL mAkDCRqQk4TjGMd21bFvukSFHU3IsVvnqKioOyVyEqAwOyOW6gY2z3Z3O9BMsTYcLgG2Lk2tm4OK uk0ITIdcS2kcqLk4bUlRV3YOrAGrIOQUy7vD1isfhHnuWtfLvMyA14YMs/BscvSU9KB2jzDq1bbJ 0gb1WU8WT47ao0JmFGt5dLyYBjpkMJcKUpKwl/WSrCBuSSMqAwFEHBF4kukXnZdYlc51Ty+uitSv hFfGWOalWFKwMkYKsDOcDAal0bhNXea3bXlvQEPrTGdcGFLaCjpUdhuRg9w/UKkuE0tOXOY241q1 WucUqDi0KbUmM4sEFKhnOnSQcghRBFYIt6Zb5y59nhXSS86p1cma7I5hJ78lDqQd8nJBOSd6yROJ ZVsnSZNriW+EJCNBa6VMhKU6SlQSX9agFBStQzvnB2wAG3F8F27hGFcX7OzPmSJ8ljMh51LYbQ2w odltSSVZcODqAwVZCtimaiiDw9J47tSbVFnNwULbQ7KW7rcQmawgIVy1pGO5WQAcjvxtVLlXKVLj iO6pAZS+7IS220lCUrcCQsgJAwCEJ2GwxsBWdF/uSLvKuheQuVLUtcjmsoW28VK1HU2oFChqwrBG AQCMEDASfCVit13kP9ddITOiLLUI7wf15RHWtLmUII0pUAojOTpI0nIBzrdXw3w5GkWmey67JnyG H5UdCtEhpDcdQbIcSCUZdXqQU6VbagoJTirsvux1lbLq21FKkFSFFJKVApUNvEQSCPGCRW3bbzPt HN6F/lczBOUJVpUM6Vp1A6VpydK04UnJwRk0FskcKQLjf79a4Seg8GXSQlLiipzntatLcdsE9p/s KKEZy5qVlQ0b6Dly8GWBu6WRrwd190ltrbCub+90JYUhhRUO2gc1QUkjC9tQOBitLmSHIDMFTmYz Lq3kIwNlrCAo579w2j6PnNb7fEt3anzZyJeJM10vvLLaD8KSSHEgjCFgqVpWnCk6jgjJoJabZoEH i7iRTjGLTaJT6EMlasOK5ikMs6s5OSAVDUFctDhByKOXmfGsDd8Zf0XK6XSWJzwQn4dKUsL0KTjS UFTqypGNKsjUDpTitLmSFwGYKnMxmXVvIRgbLWEBRz37htH0fOa2LbeZ9o5vQv8AK5mCcoSrSoZ0 rTqB0rTk6VpwpOTgjJoLZI4UgXG/361wk9B4MukhKXFFTnPa1aW47YJ7T/YUUIzlzUrKho31Lbd5 MaPJkwZsrhqzKmOrSuC4tUh0qCdLAOtHNDYwcqICQtRJytKVVZcyQuAzBU5mMy6t5CMDZawgKOe/ cNo+j5zUsnjC8fvjmrhSOfKcmL6q3R3/AIVzGtQ1oOnOlOwwNhtQSdjvtwmcWONW64XCyWeVMcmS I1vlqaTHYGVuFITgEoaScYTk6QADsKrV0uDt3u825SEoS9LfW+4lsEJClqKiBknbJ8tG7lKZnPTG VIaeeS6hfLaSlOlxKkLASBpSClShgAYztjArUoFKUoFKUoFKUoFKUoFKUoFKUoFKUoFKUoFKUoFd PZ/0UWH+cuP/AEq5hXT2f9FFh/nLj/0qIpNKUr7jwFKUoFKUoFKUoFKUoFKUoFKUoFKUoFKUoFKU oFKUoFKUoFKUoFKUoOsfl8/79wv6Nb/5rtcsrqf5fP8Av3C/o1v/AJrtcsrh4f8Apw9WXcpSldkK UpQKUpQKUpQKUpQZGGHZL6GGGluvOKCUNtpKlKJ7gAO818EEHB2PjFT3BH/fiyf661/6hX5w5b41 x4iW1KaLzTbT7/ICiC8W21LCMjfBKd8b4ziszNWR/r/KBpV9NmtPgT3QeCmtfg4SPBpedDWrnlrX nVr04Gcau/x42qG4tt8C3cQx2o0RUOM5GjvLZUtSygrQlShknPjNZjOJmkv7+/miPA9z8GeE/B0z oP0rkK5Xfj4+Md+3f31pV0hPWe/CrVnodas5/gvB+n6OXy/6v66jYvD9uf8ABjgiKW09ZZcpxQUr BdbL2lWc7Y0o27vL31I1Olz99/8AS+9KTSrTx86h2/RyiI1H/eEU/BlZ1ZZQf5Sj3d23k3ycmqtX TGbiz2iSlKVQpSlApSlAqBqeqBrw+M/tbwKuljuPgrhKO94Zulm586Qnn2pGtyRpbZOlwcxvCUas p3Vu4vZOO1U5yFtz5KHInRuJdUFRsKHJOd0YUSoY7tyTtvW3b79OtkdUdjpXGSorDcqGzJSlRABK Q6lQSSAMkYzpTnOBjxOi2SZtxtF3vaETV8N25q7SkuOWkq5jy9QAYQApvmIbAyM6QgLJ2K0pVt8F sxp/F0O/QmLW09JvoCYL0plHRM8xCsttqKS4ohZQkpT2dBwNRSUU+PxVdo7C2VORZKVvrkqM2EzK UXVhIWrU6hRydKc774rQZuUqNd27pHUhqW0+JDam2kpShYVqBCANIAPixjxYxQWGzTLnZ4DqPC79 lgtSnEuzLavU9LcwkctOhxKXUoxqzqCUhxRzlaUqr10ltT7vNmR4qIjMh9brcdvGllKlEhAwBsAc dw7u6tuBxJcbbAEFkQnIwdU8lEqAxI0rUEhRBcQojIQnu8gr4h3+5W+RcHobyGFXBhyNJDbKAlTT hBWkJxhIOB8UDHixQSVhvUu1wEt+ErpZobjriustjJLkhwBv4NZ5jYUlA3AySkuHbt7S0u6y7Jfr xE6qbw7D8KSxzrI2VcxwKSOTq1tBSGxunuKeYeyNe1Xt9+n2yOqOx0rjJVrDcqGzJSlRABKQ6lQS SAMkYzpTnOBj7i8SXSLzsusSuc6p5fXRWpXwivjLHNSrClYGSMFWBnOBgLpOVEsPhKSJ82wTHr7P jKNmYDvwbXKIaCy40UoSXFYAACtiR2E4hbAw7Y+Jb7ZnmorkhqHco7r4SVFPLjPghBPcCQN8BWBj IBUDCxeJLpF52XWJXOdU8vrorUr4RXxljmpVhSsDJGCrAznAwt3Et0tkuVLYdZckytXOelRmpC16 goK7TiVEagpQVj42d80EnYLjcbfaCtF2lWS3B9fMlwdQkSllKMNgBaeYEAatyAgOK3ytKVSzFztz FodvcebcOHXrjdpYSLVHS4pLKUsrS1q5jZShJdOydlbZHYTitR+KbnFjrjoTb1srfXI5b1tjOpQt YSFFAW2dAISnZOBsNqxxeJLjE5wbEJbbrqni0/AYdbQtXeUIWgpbzgA6QMhKR/JGAk4lvdtCONbb IUhT0SHyHFNklJUidHSSMgbZHkqrVYY8q7q4cvEoWhclmavlzLw4h5ak/CNuaCvVoBK0oOSCrtd+ 4qvUCp7hH+OZH9F3D/BvVA1LcNvzmL40bdbvCUlxp5npOWtfNQtpSFjCCFfFUo7EYxmgWSHHkdXJ eb6pURrnJgpJCn8d5JGDoSBqVpOrHdgalomuGpdrctPFT1xgynXlww44YshuOgoMqP2Uo5Sgk6iD kbYGkJHeK2+5Jg3dxxDK7dKYfKg02VoVGWlXxRqJUCkjG5yMd+azQnbrcJkuLbmFvP3JJQ7HixgS 4kLDpCUJHZALYOEgYCfJQTfCb1pbsPEonQprzggJK1MTENAt9VHASAWlYVqwdWSMbY8dOE3rS3Ye JROhTXnBASVqYmIaBb6qOAkAtKwrVg6skY2x46gbWLk+4/b7Wy8+7Oa5K2GGuYtxCVJcwAATsW0n bzfJmlrFyfcft9rZefdnNclbDDXMW4hKkuYAAJ2LaTt5vkzQT3Cb1pbsPEonQprzggJK1MTENAt9 VHASAWlYVqwdWSMbY8dOE3rS3YeJROhTXnBASVqYmIaBb6qOAkAtKwrVg6skY2x46gbWLk+4/b7W y8+7Oa5K2GGuYtxCVJcwAATsW0nbzfJmlrFyfcft9rZefdnNclbDDXMW4hKkuYAAJ2LaTt5vkzQT 3Cb1pbsPEonQprzggJK1MTENAt9VHASAWlYVqwdWSMbY8dOE3rS3YeJROhTXnBASVqYmIaBb6qOA kAtKwrVg6skY2x46gbWLk+4/b7Wy8+7Oa5K2GGuYtxCVJcwAATsW0nbzfJmlrFyfcft9rZefdnNc lbDDXMW4hKkuYAAJ2LaTt5vkzQT3Cb1pbsPEonQprzggJK1MTENAt9VHASAWlYVqwdWSMbY8dZ7H cfBXCUd7wzc7Nz50hPPtSNbkjS2ydLg5jeEo1ZTurdxeycdqtWsXJ9x+32tl592c1yVsMNcxbiEq S5gAAnYtpO3m+TNZLffp1sjqjsdK4yVFYblQ2ZKUqIAJSHUqCSQBkjGdKc5wMBaIjnRcecVQhAhM FbV1QUtJ1hhKWJB0NEgAJyBuEg4SAMAqBibDepdrgJb8JXSzQ3HXFdZbGSXJDgDfwazzGwpKBuBk lJcO3b20LdxLdLZLlS2HWXJMrVznpUZqQteoKCu04lRGoKUFY+NnfNIvElxic4NiEtt11TxafgMO toWrvKELQUt5wAdIGQlI/kjAWXiB+Rw71si3NsW+S/fbhGkNxwFNlprklLO6QFNZcXlJSErGnUk6 UgbHEfguwQJERNnZmNMcR3RiO1IedDbbaRHH8hSVKVgJAJVjGrIJIIp8TiC6wpEmQzMWXpKuY646 A4ouZJDoKgSlwFSsODChqOCMmvuBxJdLbAEBh1lcMOqe6eRGafb5igkFelxKhqwkAHvA1YxqVkLK oy+GJ92gRLxNs1ohXOQx1kQnqpakkJS3hKkBzQE6tykI5it8rSlWO0XGyS2OMpb1olNJfYLwYizE NIbZVMjlLSQWjgpJHa7sDGkd4go/FV2jsLZU5FkpW+uSozYTMpRdWEhatTqFHJ0pzvvitAXKUkzi hSGxOTokJbaSlKk8xLmAkDCRqQk4TjGMd21BPWCJb0WgzLixaEodfW029dHJZSsoSgqShMYZBGtJ UVnB1J040qz9yLREav8AfeHSjTFgSpBauKwNUdKFaMukAakKwkEYyFEaASShyNsdxviFi3WZC33n FlxlpuKl91teN1tZSVNrwkEqRg9hJz2RjUm3mfcep6p/X1MpUt/ShKeY6rOVKwBnGVYHcnUrAGo5 DfsH8S8U/wBGI/xkaoGp6A5cWOFLoqNYuZDkYYk3TlPHlJC21hvUFcsdpKO9Oe137ioGgsPD16uM YIt8K7rszOp2RIlxnVNOOpDYOgkKAWQEENpJHacIyNWRE3SW1Pu82ZHioiMyH1utx28aWUqUSEDA GwBx3Du7qxxJkiA8p6M5ocU04yTgHsOIKFjfypUR/XWCgssXwXbuEYVxfs7M+ZInyWMyHnUthtDb Ch2W1JJVlw4OoDBVkK2KZZVjtVln3ZmU1azGZukiFHkXh2UeYGiAQlMUAhQCklRVsdSdIGFZgYfF Uy32Bi1Rm2S23Kekr6hlt9twrS0kfBuJKQpPLOFd+FqAxk5wReJbvE5xbl63HXVPl19tDriHVd7i FrBU2s4BK0kKJSk57IwFhvNvs3C7ElItKLi83e58BC5j7gTyWQzp1JbUgleVncEDdWQezpwRbbFt nHPEVoQlbrMZi6MMuLdUlxPKZdKVZQUgkhGCCCkhShjfavXC8z7rr61/m65T0xXYSnLrunmK2A79 Cdu4Y2Arbi8VXaHcp1xbcirlzlLVIdehMulRXq141oISFBagQnAIODtQZ4ggWzhiLcn7VFuL0uY/ HKZTjwS2lpDKgU8paDkl05yT8VOMb52OGbJabzcJanrhFispYmLaiSVPLdSEMLWhZU21pISQCe4n QezuAYyLxHcYnODYhLbddU8Wn4DDzaFq7yhC0FLecAHSBkJSP5IxomdLMt2WZT5kva+a8XDrXrBC 9Su86gog578nPfQWRbq+G+HI0i0z2XXZM+Qw/KjoVokNIbjqDZDiQSjLq9SCnSrbUFBKcb8jhSBc b/frXCT0Hgy6SEpcUVOc9rVpbjtgntP9hRQjOXNSsqGjep228z7Rzehf5XMwTlCVaVDOladQOlac nStOFJycEZNa65khcBmCpzMZl1byEYGy1hAUc9+4bR9HzmgukG7R4NhMyJcLnw5GlXOVyhaiXnFo CWSGnCXGyUthfZJKsla9k/yt+cqJYfCUkT5tgmPX2fGUbMwHfg2uUQ0FlxopQkuKwAAFbEjsJxT0 cVXZL8p5xyLIVKfXJcEqEy+nmrOVqSlxBCCrbOkDOlOe4YxxeJLpF52XWJXOdU8vrorUr4RXxljm pVhSsDJGCrAznAwG2xYk2273dN2Sh2PZlONvBClBD74UUNtg7EhSxqIBSrlocIwRW25eZ8awN3xl /RcrpdJYnPBCfh0pSwvQpONJQVOrKkY0qyNQOlOK9Kuc2awGZUlbyQ+7Jy4dSi64Ehaio7knQnvP i+c1ktt5n2jm9C/yuZgnKEq0qGdK06gdK05OlacKTk4IyaC2SOFIFxv9+tcJPQeDLpISlxRU5z2t WluO2Ce0/wBhRQjOXNSsqGjfQ4ZnxzfryIdvZjsSoFwLaVkurjt9K+oNpUr/AMoKsajpxkBSgYKK LldW41nhsvStLrjzMZhrWsrUlOsgAZPZbT+rT+utuLxVdodynXFtyKuXOUtUh16Ey6VFerXjWghI UFqBCcAg4O1BZfybW5vwvZrkyu3vTFXZtlTUqUyhTDQU2StDa1AuLXqUlJAOnQrAKikoiLRdJtkY VEXc7hZ4ofdCptoTzFSXUhscsrS6hK0IG4wo45hO4XmoJm5So13bujCkNS2nxIbU20lKULCtQIQB pAB8WMeLGK2Lffp9sjqjsdK4yVFYblQ2ZKUqIAJSHUqCSQBkjGdKc5wMB98UNcji29M9OxG5c59P IYOW28OKGlJwOyO4bDbxComtyQxcJFylIktSnJ4U4uQlxKlOhScqcK875GFFRPdgk1p0ClKUClKU ClKUClKyPsOxZDkeQ0tp5pRQ424kpUhQOCCDuCD4qDHSlKBSlKBSlKBSlKBSlKBSlKBSlKBXT2f9 FFh/nLj/ANKuYV09n/RRYf5y4/8ASoKTSlK+4+eUpSgUpSgUpSgUpSgUpSgUpSgUpSgUpSgUpSgU pSgUpSgUpSgUpSg6x+Xz/v3C/o1v/mu1yyup/l8/79wv6Nb/AOa7XLK4eH/pw9WXcpSldkKUpQKU pQKUpQKUpQZGH3Yz6H2HVtPNqCkONqKVJI7iCO41vyOI75MWyuTeri8phfMaU5KWotq85OTsfnFR lKlQJ228SvR7q9cLi7cZcpbWhMpq4LZkNnbdLmFeLIwQdj4q1b/eV367uTltlsFKG0IKyspQlISk FR7zgbnbJycCoylTbF2N3wxc/Bvg3wjL6D9F56uV35+JnHfv+uv1m9XWPCMJi5zWoh1ZYQ+pLZyM Hsg43BIP660aVaj3GeROly22G5Mp99DCOWyl1wqDafNSD3D5hWClKoUpSgUpSgUpSgVA1PVA14fG f2t4FXSx3HwVwlHe8M3Szc+dITz7UjW5I0tsnS4OY3hKNWU7q3cXsnHaqc5C258lDkTo3EuqCo2F DknO6MKJUMd25J23rbt9+nWyOqOx0rjJUVhuVDZkpSogAlIdSoJJAGSMZ0pznAx4nRbJM242i73t CJq+G7c1dpSXHLSVcx5eoAMIAU3zENgZGdIQFk7FaUq2+C2Y0/i6HfoTFraek30BMF6UyjomeYhW W21FJcUQsoSUp7Og4GopKKfH4qu0dhbKnIslK31yVGbCZlKLqwkLVqdQo5OlOd98VoM3KVGu7d0j qQ1LafEhtTbSUpQsK1AhAGkAHxYx4sYoLDZplzs8B1Hhd+ywWpTiXZltXqeluYSOWnQ4lLqUY1Z1 BKQ4o5ytKVV66S2p93mzI8VERmQ+t1uO3jSylSiQgYA2AOO4d3dW3A4kuNtgCCyITkYOqeSiVAYk aVqCQoguIURkIT3eQV8Q7/crfIuD0N5DCrgw5GkhtlASppwgrSE4wkHA+KBjxYoJKw3qXa4CW/CV 0s0Nx1xXWWxklyQ4A38Gs8xsKSgbgZJSXDt29paXdZdkv14idVN4dh+FJY51kbKuY4FJHJ1a2gpD Y3T3FPMPZGvar2+/T7ZHVHY6Vxkq1huVDZkpSogAlIdSoJJAGSMZ0pznAx9xeJLpF52XWJXOdU8v rorUr4RXxljmpVhSsDJGCrAznAwF0nKiWHwlJE+bYJj19nxlGzMB34NrlENBZcaKUJLisAABWxI7 CcQtgYdsfEt9szzUVyQ1DuUd18JKinlxnwQgnuBIG+ArAxkAqBhYvEl0i87LrErnOqeX10VqV8Ir 4yxzUqwpWBkjBVgZzgYW7iW6WyXKlsOsuSZWrnPSozUha9QUFdpxKiNQUoKx8bO+aCesdx8FcJR3 vDNzs3PnSE8+1I1uSNLbJ0uDmN4SjVlO6t3F7Jx2s8u6y7JfrxE6qbw7D8KSxzrI2VcxwKSOTq1t BSGxunuKeYeyNe1ai8R3GJzg2IS23XVPFp+Aw82hau8oQtBS3nAB0gZCUj+SMIvEl0i87LrErnOq eX10VqV8Ir4yxzUqwpWBkjBVgZzgYCektci6flCZ6diNy2nE8hg5bbxPYGlJwOyO4bDYdwql1YY8 q7q4cvEoWhclmavlzLw4h5ak/CNuaCvVoBK0oOSCrtd+4qvUCp7hH+OZH9F3D/BvVA1LcNvzmL40 bdbvCUlxp5npOWtfNQtpSFjCCFfFUo7EYxmgWSHHkdXJeb6pURrnJgpJCn8d5JGDoSBqVpOrHdga lomuGpdrctPFT1xgynXlww44YshuOgoMqP2Uo5Sgk6iDkbYGkJHeK2+5Jg3dxxDK7dKYfKg02VoV GWlXxRqJUCkjG5yMd+azQnbrcJkuLbmFvP3JJQ7HixgS4kLDpCUJHZALYOEgYCfJQTfCb1pbsPEo nQprzggJK1MTENAt9VHASAWlYVqwdWSMbY8dOE3rS3YeJROhTXnBASVqYmIaBb6qOAkAtKwrVg6s kY2x46gbWLk+4/b7Wy8+7Oa5K2GGuYtxCVJcwAATsW0nbzfJmlrFyfcft9rZefdnNclbDDXMW4hK kuYAAJ2LaTt5vkzQT3Cb1pbsPEonQprzggJK1MTENAt9VHASAWlYVqwdWSMbY8dOE3rS3YeJROhT XnBASVqYmIaBb6qOAkAtKwrVg6skY2x46gbWLk+4/b7Wy8+7Oa5K2GGuYtxCVJcwAATsW0nbzfJm lrFyfcft9rZefdnNclbDDXMW4hKkuYAAJ2LaTt5vkzQT3Cb1pbsPEonQprzggJK1MTENAt9VHASA WlYVqwdWSMbY8dOE3rS3YeJROhTXnBASVqYmIaBb6qOAkAtKwrVg6skY2x46gbWLk+4/b7Wy8+7O a5K2GGuYtxCVJcwAATsW0nbzfJmlrFyfcft9rZefdnNclbDDXMW4hKkuYAAJ2LaTt5vkzQT3Cb1p bsPEonQprzggJK1MTENAt9VHASAWlYVqwdWSMbY8dZ7HcfBXCUd7wzc7Nz50hPPtSNbkjS2ydLg5 jeEo1ZTurdxeycdqtWsXJ9x+32tl592c1yVsMNcxbiEqS5gAAnYtpO3m+TNZLffp1sjqjsdK4yVF YblQ2ZKUqIAJSHUqCSQBkjGdKc5wMBaIjnRcecVQhAhMFbV1QUtJ1hhKWJB0NEgAJyBuEg4SAMAq BiYsyRZeEYU63uciTLnyWJCwAea022wUtqByCgl1epB7KttQOlONC3cS3S2S5Uth1lyTK1c56VGa kLXqCgrtOJURqClBWPjZ3zXxEv8AcoMiS9FeQyqQrmKCGUBKV5JStCcYbWnJ0qQAU5OkjNBaOIP/ AJT63wJ+9NV+uEJeO3rjs8nQ0rVnUj4RWpJyF7agrSMbcyxWC0yLq44LQhIvc2Cy1dFTSlDTJb06 On3z8IQorJ7k4/lZpFtvM+0c3on+VzME5QlWlQzpWnUDpWnJ0rThScnBGTWS336dbI6o7HSuMlWs NyobMlKVEAEpDqVBJIAyRjOlOc4GAmZLVks8Bc6JAYu8aRdJcaOuct5OGWg0W1ANqbOpQdOdXkGA nfOBvwXbrAzdBZ2JvWT5LCG5zzp5LbaWVJwWlN5UecQSRg6RgJ3zoReJLpF52XWJXOdU8vrorUr4 RXxljmpVhSsDJGCrAznAwi8SXSLzsusSuc6p5fXRWpXwivjLHNSrClYGSMFWBnOBgJrhp+yJtPFR et9wWnowoBE5CTyeqj6UZLJ7YOCV9xAI0jORE2Vlq5x5FvkNIbbbSqQJ4SB02AAS4e9TZOlON1BR ToBJKHNAXObmcpUla1T06JS3DrU6OYlw5J3zrQk579vnNfHWyOg6EOYjF3nKQkAal4wCo96sDOM9 2pWMajkJawfxLxT/AEYj/GRqganoDlxY4Uuio1i5kORhiTdOU8eUkLbWG9QVyx2ko7057XfuKgaC w8PXq4xgi3wruuzM6nZEiXGdU046kNg6CQoBZAQQ2kkdpwjI1ZETdJbU+7zZkeKiIzIfW63HbxpZ SpRIQMAbAHHcO7urHEmSIDynozmhxTTjJOAew4goWN/KlRH9dYKCy8PWCPxFAcZSrpJMV0uLfUCr qUKACWG05AL+ULKEbczUrdOgZkrfEsC7Qu8OMWiMmXcZDTMa6OTVpZaQlpSUoVHGSRzSFFffhOMd qqeuZIXAZgqczGZdW8hGBstYQFHPfuG0fR85qTRxVdkvynnHIshUp9clwSoTL6eas5WpKXEEIKts 6QM6U57hgJaW3w9abR1kS2ouqHbtNjRnpjzqUqjtpZKCpKCg6+3nOR3qyk7aYLiK3tWjia7W2Opa mYcx6O2pwgqKULKQTgAZwPJWvKuc2bHDMqSt5Ifdk5cOpRdcCQtRUdyToT3nxfOa30cQNuSJUq5W a33OXKfW+7IkqfQoqUckANOISBnJ7vH5MYDbi+C7dwjCuL9nZnzJE+SxmQ86lsNobYUOy2pJKsuH B1AYKshWxTJQLdw61aHLlqt5ZkXGRHjpvZlagy2lpSCOl/l4d7Wo42Tp8eavPui5raI7cdmJDbdW 81FY1FDa1pQlZBWVLOeWnvUfmxWS336dbI6o7HSuMlRWG5UNmSlKiACUh1KgkkAZIxnSnOcDATsK Pw8H7gxb27fcHUzHExReH3Y6XY4PwakLQptKV41lfNKf5ASMkislhlRrbB4ujvWBlamYuS3Oce5q U9XHTyl6FIHZO5ISk6h5OzUDF4kukXnZdYlc51Ty+uitSvhFfGWOalWFKwMkYKsDOcDC0zL0/elr t6Xp1wl6+Y0pgSjIz21a21BQc3GrcHdIV3gGg24gg2zhiLcn7VFuL0uY/HKZTjwS2lpDKgU8paDk l05yT8VOMb5lrzbrNwuxJSLSi4vN3ufAQuY+4E8lkM6dSW1IJXlZ3BA3VkHs6a3b79OtkdUdjpXG SorDcqGzJSlRABKQ6lQSSAMkYzpTnOBjXlXObNYDMqSt5Ifdk5cOpRdcCQtRUdyToT3nxfOaC2QL dw61aHLlqt5ZkXGRHjpvZlagy2lpSCOl214d7Wo42Tp8eandG4TV3mt215b0BD60xnXBhS2go6VH YbkYPcP1Cti336dbI6o7HSuMlesNyobMlKVEAEpDqVBJIAyRjOlOc4GM8e58mOuXcbFFuapL61Gb NXJ1LXhJUnUh1IURqBOQT29zuKCT4TetLdh4lE6FNecEBJWpiYhoFvqo4CQC0rCtWDqyRjbHjrT4 Nfdau01Dbq0IetNwQ4lKiAtPSuqwfKMpSceUA+Ko126L5k3o47MFiY0ll2OxqUjQFIXgFwqUO02l Xf8A2bV92e/TrEt5cDpQp5BQtT0Rp86SCkgcxKsAhRBAxkHBzQRtWGIi2wOGItwl21E5cyY/GXre WhTKG0MqBaKSAFnnK3WlY7Kez3g6kW8xmucqXYbZOdddU4XHec1pz/JSllxCAnyAJ2z5MAZG+Jps VbotzUWCytXMbZba5ojrwAVtKd1rbWdIJUlQOQnfspwFhlJac/Kjxe241r1eFylQcWhTaktvLBBS oZzp0kHIIUQRUTF8F27hGFcX7OzPmSJ8ljMh51LYbQ2wodltSSVZcODqAwVZCuyU6kXiq7Q7lOuL bkVcucpapDr0Jl0qK9WvGtBCQoLUCE4BBwdq0JVylS44juqQGUvuyEtttJQlK3AkLICQMAhCdhsM bAUFsgW7h1q0OXLVbyzIuMiPHTezK1BltLSkEdL/AC8O9rUcbJ0+POpJaslngLnRIDF3jSLpLjR1 zlvJwy0Gi2oBtTZ1KDpzq8gwE75hrffp1sjqjsdK4yVFYblQ2ZKUqIAJSHUqCSQBkjGdKc5wMfcX iS6Redl1iVznVPL66K1K+EV8ZY5qVYUrAyRgqwM5wMBNcNXGDHtPFQTZYshsQw4jqnnSsoMqOA2o trQCBkKyEpJI78dmqfW/GvM+JPemof5r7+rnmQhL6XsnUeYlYKV9oBXaB3APeAayW+6RIUdTcixW +eoqKg7JXISoDA7I5bqBjbPdnc70E7YrfaG+GWrlPVaOdImPRwm6GZpCW0NKBR0wznLp1aj4k4/l ZS2+HrTaOsiW1F1Q7dpsaM9MedSlUdtLJQVJQUHX285yO9WUnbTEt8TSoy3Uw4lvYirVrTEciolN NKwASgSOYUlWkZIO+B4gANCVc5s1gMypK3kh92Tlw6lF1wJC1FR3JOhPefF85oLTd7XaOGesQ5b/ AAg2bzNt4U+8tDjbTHKwpBQQkLPNOSpK05Sns94O/JsduvH5ReKTOukJnTKuihHeD+vKEOrS5lCC NKVAKIzk6CMHIBqyOK7yh+U/1SFPSX1yVOLjtqU28o5U40SnLSycdpGk9lPmjGg/c5sm5Sri5JX1 cpTinnUHQVlzOv4uBhQUoEd2CR3UFhW6vhvhyNItM9l12TPkMPyo6FaJDSG46g2Q4kEoy6vUgp0q 21BQSnG/I4UgXG/361wk9B4MukhKXFFTnPa1aW47YJ7T/YUUIzlzUrKho3qdtvM+0c3oX+VzME5Q lWlQzpWnUDpWnJ0rThScnBGTWuuZIXAZgqczGZdW8hGBstYQFHPfuG0fR85oLK5cvBlgbulka8Hd fdJba2wrm/vdCWFIYUVDtoHNUFJIwvbUDgYTbNAg8XcSKcYxabRKfQhkrVhxXMUhlnVnJyQCoagr locIORUS3xLd2p82ciXiTNdL7yy2g/CkkhxIIwhYKlaVpwpOo4Iya0FzJC4DMFTmYzLq3kIwNlrC Ao579w2j6PnNBZXLzPjWBu+Mv6LldLpLE54IT8OlKWF6FJxpKCp1ZUjGlWRqB0pxvyOFIFxv9+tc JPQeDLpISlxRU5z2tWluO2Ce0/2FFCM5c1KyoaN6nbbzPtHN6F/lczBOUJVpUM6Vp1A6VpydK04U nJwRk1rrmSFwGYKnMxmXVvIRgbLWEBRz37htH0fOaCy8Mz45v15EO3sx2JUC4FtKyXVx2+lfUG0q V/5QVY1HTjIClA1OpqLxVdodynXFtyKuXOUtUh16Ey6VFerXjWghIUFqBCcAg4O1RL7ypEhx5YQF OKKyG0JQkEnOyUgAD5gABQY6UpQKUpQKUpQK6ez/AKKLD/OXH/pVzCuns/6KLD/OXH/pUFJpXsj3 E8K/JizfYWvZp7ieFfkxZvsLXs17/Wxw83kTy8b0r2R7ieFfkxZvsLXs09xPCvyYs32Fr2aetjg8 ieXjeleyPcTwr8mLN9ha9mnuJ4V+TFm+wtezT1scHkTy8b0r2R7ieFfkxZvsLXs09xPCvyYs32Fr 2aetjg8ieXjeleyPcTwr8mLN9ha9mnuJ4V+TFm+wtezT1scHkTy8b0r2R7ieFfkxZvsLXs09xPCv yYs32Fr2aetjg8ieXjeleyPcTwr8mLN9ha9mnuJ4V+TFm+wtezT1scHkTy8b0r2R7ieFfkxZvsLX s09xPCvyYs32Fr2aetjg8ieXjeleyPcTwr8mLN9ha9mnuJ4V+TFm+wtezT1scHkTy8b0r2R7ieFf kxZvsLXs09xPCvyYs32Fr2aetjg8ieXjeleyPcTwr8mLN9ha9mnuJ4V+TFm+wtezT1scHkTy8b0r 2R7ieFfkxZvsLXs09xPCvyYs32Fr2aetjg8ieXjeleyPcTwr8mLN9ha9mnuJ4V+TFm+wtezT1scH kTy8b0r2R7ieFfkxZvsLXs09xPCvyYs32Fr2aetjg8ieXD/y+f8AfuF/Rrf/ADXa5ZXr2/8AAXDX FE5ubeLb1MhtoNJXz3EYSCSBhKgO9RqK96DgT0F/vj/t1nT8TjjhGMw7TjLyvSvVHvP8Cegv97f9 unvP8Cegv97f9uunq8OJTZLyvSvVHvP8Cegv97f9unvP8Cegv97f9unq8OJNkvK9K9Ue8/wJ6C/3 t/26e8/wJ6C/3t/26erw4k2S8r0r1R7z/AnoL/e3/bp7z/AnoL/e3/bp6vDiTZLyvSvVHvP8Cegv 97f9unvP8Cegv97f9unq8OJNkvK9K9Ue8/wJ6C/3t/26e8/wJ6C/3t/26erw4k2S8r0r1R7z/Ano L/e3/bp7z/AnoL/e3/bp6vDiTZLyvSvVHvP8Cegv97f9unvP8Cegv97f9unq8OJNkvK9K9Ue8/wJ 6C/3t/26e8/wJ6C/3t/26erw4k2S8r0r1R7z/AnoL/e3/bp7z/AnoL/e3/bp6vDiTZLyvSvVHvP8 Cegv97f9unvP8Cegv97f9unq8OJNkvK9K9Ue8/wJ6C/3t/26e8/wJ6C/3t/26erw4k2S8r1A17G9 5/gT0F/vb/t145rzeI1cdSqaxiirpY7j4K4SjveGbpZufOkJ59qRrckaW2TpcHMbwlGrKd1buL2T jtVOchbc+ShyJ0biXVBUbChyTndGFEqGO7ck7b1t2+/TrZHVHY6VxkqKw3KhsyUpUQASkOpUEkgD JGM6U5zgY87S2SZtxtF3vaETV8N25q7SkuOWkq5jy9QAYQApvmIbAyM6QgLJ2K0pVt8Fsxp/F0O/ QmLW09JvoCYL0plHRM8xCsttqKS4ohZQkpT2dBwNRSUU+PxVdo7C2VORZKVvrkqM2EzKUXVhIWrU 6hRydKc774rQZuUqNd27pHUhqW0+JDam2kpShYVqBCANIAPixjxYxQWGzTLnZ4DqPC79lgtSnEuz LavU9LcwkctOhxKXUoxqzqCUhxRzlaUqr10ltT7vNmR4qIjMh9brcdvGllKlEhAwBsAcdw7u6tuB xJcbbAEFkQnIwdU8lEqAxI0rUEhRBcQojIQnu8gr4h3+5W+RcHobyGFXBhyNJDbKAlTThBWkJxhI OB8UDHixQSVhvUu1wEt+ErpZobjriustjJLkhwBv4NZ5jYUlA3AySkuHbt7S0u6y7JfrxE6qbw7D 8KSxzrI2VcxwKSOTq1tBSGxunuKeYeyNe1Xt9+n2yOqOx0rjJVrDcqGzJSlRABKQ6lQSSAMkYzpT nOBj7i8SXSLzsusSuc6p5fXRWpXwivjLHNSrClYGSMFWBnOBgLpOVEsPhKSJ82wTHr7PjKNmYDvw bXKIaCy40UoSXFYAACtiR2E4iIhu3DHXQHLw/ZosKe8w/MtpXzpbqdKeWkakcxKNOrcpCA4rJytK VQUXiS6Redl1iVznVPL66K1K+EV8ZY5qVYUrAyRgqwM5wMZI/FV2jsLZU5FkpW+uSozYTMpRdWEh atTqFHJ0pzvviguHBbMafxdDv0Ji1tPSb6AmC9KZR0TPMQrLbaikuKIWUJKU9nQcDUUlFdtF0m2R hURdzuFnih90Km2hPMVJdSGxyytLqErQgbjCjjmE7heagmblKjXdu6MKQ1LafEhtTbSUpQsK1AhA GkAHxYx4sYrYt9+nWyOqOx0rjJVrDcqGzJSlRABKQ6lQSSAMkYzpTnOBgLDJa5F0/KEz07EbltOJ 5DBy23iewNKTgdkdw2Gw7hVLqwx5V3Vw5eJQtC5LM1fLmXhxDy1J+Ebc0FerQCVpQckFXa79xVeo FT3CP8cyP6LuH+DeqBqW4bfnMXxo263eEpLjTzPScta+ahbSkLGEEK+KpR2IxjNAskOPI6uS831S ojXOTBSSFP47ySMHQkDUrSdWO7A1LRNcNS7W5aeKnrjBlOvLhhxwxZDcdBQZUfspRylBJ1EHI2wN ISO8Vt9yTBu7jiGV26Uw+VBpsrQqMtKvijUSoFJGNzkY781mhO3W4TJcW3MLefuSSh2PFjAlxIWH SEoSOyAWwcJAwE+Sgm+E3rS3YeJROhTXnBASVqYmIaBb6qOAkAtKwrVg6skY2x46cJvWluw8SidC mvOCAkrUxMQ0C31UcBIBaVhWrB1ZIxtjx1A2sXJ9x+32tl592c1yVsMNcxbiEqS5gAAnYtpO3m+T NLWLk+4/b7Wy8+7Oa5K2GGuYtxCVJcwAATsW0nbzfJmgnuE3rS3YeJROhTXnBASVqYmIaBb6qOAk AtKwrVg6skY2x46cJvWluw8SidCmvOCAkrUxMQ0C31UcBIBaVhWrB1ZIxtjx1A2sXJ9x+32tl592 c1yVsMNcxbiEqS5gAAnYtpO3m+TNLWLk+4/b7Wy8+7Oa5K2GGuYtxCVJcwAATsW0nbzfJmgnuE3r S3YeJROhTXnBASVqYmIaBb6qOAkAtKwrVg6skY2x46cJvWluw8SidCmvOCAkrUxMQ0C31UcBIBaV hWrB1ZIxtjx1A2sXJ9x+32tl592c1yVsMNcxbiEqS5gAAnYtpO3m+TNLWLk+4/b7Wy8+7Oa5K2GG uYtxCVJcwAATsW0nbzfJmgnuE3rS3YeJROhTXnBASVqYmIaBb6qOAkAtKwrVg6skY2x46z2O4+Cu Eo73hm52bnzpCefaka3JGltk6XBzG8JRqyndW7i9k47VatYuT7j9vtbLz7s5rkrYYa5i3EJUlzAA BOxbSdvN8mayW+/TrZHVHY6VxkqKw3KhsyUpUQASkOpUEkgDJGM6U5zgYC0RHOi484qhCBCYK2rq gpaTrDCUsSDoaJAATkDcJBwkAYBUDExZkiy8Iwp1vc5EmXPksSFgA81pttgpbUDkFBLq9SD2Vbag dKcaFu4lulslypbDrLkmVq5z0qM1IWvUFBXacSojUFKCsfGzvmviJf7lBkSXoryGVSFcxQQygJSv JKVoTjDa05OlSACnJ0kZoLRxB/8AKfW+BP3pqv1whLx29cdnk6Glas6kfCK1JOQvbUFaRj4v0G08 Nv3BxuzRZqVXudBbalOvaWWmC3o08txJJPNIJUVfFTjG+atbbzPtHN6J/lczBOUJVpUM6Vp1A6Vp ydK04UnJwRk1kt9+nWyOqOx0rjJVrDcqGzJSlRABKQ6lQSSAMkYzpTnOBgJbhKW03dro1GioS1It 0/Qp/DjrSBFeISFYAyezlQSCdOBgFQKwRLei0GZcWLQlDr62m3ro5LKVlCUFSUJjDII1pKis4OpO nGlWYy3cS3S2S5Uth1lyTK1c56VGakLXqCgrtOJURqClBWPjZ3zSLxJdIfO6d1lHNdU8MRmvgXD3 rZ7PwKthu3pPZT5owFhgm4WXjybw3br7d4VnjXF/qDGlqbUGGieY5hOxWGmydgSdOADsKjWZXupn 3VVwYZZVIdduC5raNKYilHKtZ71NElKdOSoEp0ZUShyJVeZ67rKuin8zJfO5zmhPb5yVJc2xgZC1 dw2ztisHWyOg6EOYjc3nKQkAal4wCo96sDOM92pWMajkJawfxLxT/RiP8ZGqBqegOXFjhS6KjWLm Q5GGJN05Tx5SQttYb1BXLHaSjvTntd+4qBoLDw9erjGCLfCu67MzqdkSJcZ1TTjqQ2DoJCgFkBBD aSR2nCMjVkRN0ltT7vNmR4qIjMh9brcdvGllKlEhAwBsAcdw7u6scSZIgPKejOaHFNOMk4B7DiCh Y38qVEf11goLLw9YI/EUBxlKukkxXS4t9QKupQoAJYbTkAv5QsoRtzNSt06BmSt8SwLtC7w4xaIy ZdxkNMxro5NWllpCWlJShUcZJHNIUV9+E4x2qp65khcBmCpzMZl1byEYGy1hAUc9+4bR9HzmpNHF V2S/KecciyFSn1yXBKhMvp5qzlakpcQQgq2zpAzpTnuGAlpbfD1ptHWRLai6odu02NGemPOpSqO2 lkoKkoKDr7ec5HerKTtpguIre1aOJrtbY6lqZhzHo7anCCopQspBOABnA8la8q5zZscMypK3kh92 Tlw6lF1wJC1FR3JOhPefF85rfRxA25IlSrlZrfc5cp9b7siSp9CipRyQA04hIGcnu8fkxgJnh622 t/h6M7KtjMh9524rLy3HQoJixW30IASsDSpRUFbZwo4KTgjJeYNp4egRZ6LNFmm4KSrkynXtEcGL Gf0t6HEqxqkqHbKjhKd85Kq85xDLCgmE2zBjJ5/LjMAqQjnNJadwXCpR1JSO9Rx4sVka4quzY0qc iyEBLaEolQmX0oCG0tp0hxCgk6EIBIwVaU5zgUES+ppUhxUdC22SoltDiwtSU52BUAATjx4GfIKt PCb1pbsPEonQprzggJK1MTENAt9VHASAWlYVqwdWSMbY8dREW9Mt85c+zwrpJedU6uTNdkcwk9+S h1IO+TkgnJO9YHbovmTejjswWJjSWXY7GpSNAUheAXCpQ7TaVd/9m1BJcGvutXaaht1aEPWm4IcS lRAWnpXVYPlGUpOPKAfFWpIhR2+EbdOS3iS9PlMrXk7oQ3HKRju2Li/p+YVjs9+nWJby4HShTyCh anojT50kFJA5iVYBCiCBjIODmskXiS6Q+d07rKOa6p4YjNfAuHvWz2fgVbDdvSeynzRgLLIt9jhX 6+26NCtjsuPc5DLMe6ynmW+SlWEBtxLiEhQwvVzVjICNOSSDgffh2rhGKiTYue4m8T20Rp7zg5AD cbKVhvlqKxsM5AGFZTuNMKjiq7JflPOORZCpT65LglQmX081ZytSUuIIQVbZ0gZ0pz3DGhKuc2aw GZUlbyQ+7Jy4dSi64Ehaio7knQnvPi+c0FticJWk8XXy2vXaK2zBXcGmmZPOLpDTThQ6S22U4BSF EZydJ7JyAdNbq+G+HI0i0z2XXZM+Qw/KjoVokNIbjqDZDiQSjLq9SCnSrbUFBKcV5+5zZNylXFyS vq5SnFPOoOgrLmdfxcDCgpQI7sEjurJbbzPtHN6F/lczBOUJVpUM6Vp1A6VpydK04UnJwRk0Fskc KQLjf79a4Seg8GXSQlLiipzntatLcdsE9p/sKKEZy5qVlQ0b6HDM+Ob9eRDt7MdiVAuBbSsl1cdv pX1BtKlf+UFWNR04yApQNaXMkLgMwVOZjMureQjA2WsICjnv3DaPo+c1JxeKrtDuU64tuRVy5ylq kOvQmXSor1a8a0EJCgtQITgEHB2oJaxcTNQOGGram/32zvNzHpClWxoKS8laGkpCvhmzlJbV4j8a s7V3dsMi5WidfrvbbnHuL5lTrWC6qYrKU4WS42ohKkLUkknPNVsnfNei8SXGJzg2IS23XVPFp+Aw 62hau8oQtBS3nAB0gZCUj+SMY4l/uUKRJktPIVKkK5i5LzKHXgvJOtLiwVIXkk6kkHODnIFBPXS2 QmeNuKZD8ZCbXbJkjDCBoQtfMUllkYxsTuUgg8tDhScprG5eZ8awN3xl/RcrpdJYnPBCfh0pSwvQ pONJQVOrKkY0qyNQOlOK0uZIXAZgqczGZdW8hGBstYQFHPfuG0fR85rYtt5n2jm9C/yuZgnKEq0q GdK06gdK05OlacKTk4IyaC2SOFIFxv8AfrXCT0Hgy6SEpcUVOc9rVpbjtgntP9hRQjOXNSsqGjfQ 4ZnxzfryIdvZjsSoFwLaVkurjt9K+oNpUr/ygqxqOnGQFKBrS5khyAzBU5mMy6t5CMDZawgKOe/c No+j5zUnF4qu0O5Tri25FXLnKWqQ69CZdKivVrxrQQkKC1AhOAQcHagmrHcfBXCUd7wzc7Nz50hP PtSNbkjS2ydLg5jeEo1ZTurdxeycdqSmcQtWmRdbOLvd+HnmL3NdW1ZWwtkpUW0pQDzWjhBbUB2e 5XcO6qfF4juMTnBsQltuuqeLT8Bh5tC1d5QhaClvOADpAyEpH8kYReJLpF52XWJXOdU8vrorUr4R XxljmpVhSsDJGCrAznAwGC9xpcK/XGJPf58xiU62+9rK+Y4lRClajuckE5O5rQrI++7KkOSH3Vuv OqK3HHFFSlqJySSdySfHR9h2LIcjyGltPNKKHG3ElKkKBwQQdwQfFQY6UpQKUpQKUpQKUpQKUpQK UpQKUpQK6ez/AKKLD/OXH/pVzCuns/6KLD/OXH/pUHpLqHvzy/WNOof/ADy/WNR1pu8G9wRNt7/O YKlI1FBSQpJwQQoAg5HjFbtBk6h/88v1jTqH/wA8v1jWOlBk6h/88v1jTqH/AM8v1jWOlBk6h/8A PL9Y06h/88v1jWOlBk6h/wDPL9Y06h/88v1jWOlBk6h/88v1jTqH/wA8v1jWOlBk6h/88v1jTqH/ AM8v1jWOlBk6h/8APL9Y06h/88v1jWOlBk6h/wDPL9Y06h/88v1jWOlBk6h/88v1jTqH/wA8v1jW OlBk6h/88v1jTqH/AM8v1jWOlBk6h/8APL9Y06h/88v1jWOlBk6h/wDPL9Y06h/88v1jWOlBk6h/ 88v1jTqH/wA8v1jWOlBk6h/88v1jTqH/AM8v1jWOlBk6h/8APL9Y06h/88v1jWOlBk6h/wDPL9Y0 6h/88v1jWOlBk6h/88v1jTqH/wA8v1jWOlBk6h/88v1jTqH/AM8v1jWOlBk6h/8APL9Y06h/88v1 jWOlBk6h/wDPL9Y06h/88v1jWOlBk6h/88v1jTqH/wA8v1jWOlBk6h/88v1jTqH/AM8v1jWOlBk6 h/8APL9Y06h/88v1jWOlBk6h/wDPL9Y06h/88v1jWOlBk6h/88v1jTqH/wA8v1jWOlBk6h/88v1j TqH/AM8v1jWOlBk6h/8APL9Y14er27XiKgVdLHcfBXCUd7wzdLNz50hPPtSNbkjS2ydLg5jeEo1Z TurdxeycdqpzkLbnyUOROjcS6oKjYUOSc7owolQx3bknbetu336dbI6o7HSuMlRWG5UNmSlKiACU h1KgkkAZIxnSnOcDAWyTNuNou97Qiavhu3NXaUlxy0lXMeXqADCAFN8xDYGRnSEBZOxWlKtvgtmN P4uh36Exa2npN9ATBelMo6JnmIVlttRSXFELKElKezoOBqKSinx+KrtHYWypyLJSt9clRmwmZSi6 sJC1anUKOTpTnffFaDNylRru3dI6kNS2nxIbU20lKULCtQIQBpAB8WMeLGKCw2aZc7PAdR4XfssF qU4l2ZbV6npbmEjlp0OJS6lGNWdQSkOKOcrSlVeuktqfd5syPFREZkPrdbjt40spUokIGANgDjuH d3VtwOJLjbYAgsiE5GDqnkolQGJGlagkKILiFEZCE93kFfEO/wByt8i4PQ3kMKuDDkaSG2UBKmnC CtITjCQcD4oGPFigkrDepdrgJb8JXSzQ3HXFdZbGSXJDgDfwazzGwpKBuBklJcO3b2lpd1l2S/Xi J1U3h2H4UljnWRsq5jgUkcnVraCkNjdPcU8w9ka9qvb79PtkdUdjpXGSrWG5UNmSlKiACUh1Kgkk AZIxnSnOcDH3F4kukXnZdYlc51Ty+uitSvhFfGWOalWFKwMkYKsDOcDAXScqJYfCUkT5tgmPX2fG UbMwHfg2uUQ0FlxopQkuKwAAFbEjsJxCxZVx4VkS7Q/dLhaGY8yQy5OtDSlKkvIKElBJcbCkJHaH jTzDt29oWLxJdIvOy6xK5zqnl9dFalfCK+Msc1KsKVgZIwVYGc4GEXiS6Redl1iVznVPL66K1K+E V8ZY5qVYUrAyRgqwM5wMBZeIH5HDvWyLc2xb5L99uEaQ3HAU2WmuSUs7pAU1lxeUlISsadSTpSA4 g/8AlPrfAn701X64Ql47euOzydDStWdSPhFaknIXtqCtIxV4nEF1hSJMhmYsvSV8x1x0BxRcySHQ VAlLgKlYcGFDUcEZNY7beZ9o5vRP8rmYJyhKtKhnStOoHStOTpWnCk5OCMmgssqFHtt1/KHBit8u NGacZaRknShNwYAGTudgO+qXU9AcuMfhS6KjWPmQ5GliTdOU8eWkLbWG9QVyx2ko7057XfuKgaBU 9wj/ABzI/ou4f4N6oGpbht+cxfGjbrd4SkuNPM9Jy1r5qFtKQsYQQr4qlHYjGM0CyQ48jq5LzfVK iNc5MFJIU/jvJIwdCQNStJ1Y7sDUtE1w1Ltblp4qeuMGU68uGHHDFkNx0FBlR+ylHKUEnUQcjbA0 hI7xW33JMG7uOIZXbpTD5UGmytCoy0q+KNRKgUkY3ORjvzWaE7dbhMlxbcwt5+5JKHY8WMCXEhYd IShI7IBbBwkDAT5KCb4TetLdh4lE6FNecEBJWpiYhoFvqo4CQC0rCtWDqyRjbHjpwm9aW7DxKJ0K a84ICStTExDQLfVRwEgFpWFasHVkjG2PHUDaxcn3H7fa2Xn3ZzXJWww1zFuISpLmAACdi2k7eb5M 0tYuT7j9vtbLz7s5rkrYYa5i3EJUlzAABOxbSdvN8maCe4TetLdh4lE6FNecEBJWpiYhoFvqo4CQ C0rCtWDqyRjbHjpwm9aW7DxKJ0Ka84ICStTExDQLfVRwEgFpWFasHVkjG2PHUDaxcn3H7fa2Xn3Z zXJWww1zFuISpLmAACdi2k7eb5M0tYuT7j9vtbLz7s5rkrYYa5i3EJUlzAABOxbSdvN8maCe4Tet Ldh4lE6FNecEBJWpiYhoFvqo4CQC0rCtWDqyRjbHjpwm9aW7DxKJ0Ka84ICStTExDQLfVRwEgFpW FasHVkjG2PHUDaxcn3H7fa2Xn3ZzXJWww1zFuISpLmAACdi2k7eb5M0tYuT7j9vtbLz7s5rkrYYa 5i3EJUlzAABOxbSdvN8maCe4TetLdh4lE6FNecEBJWpiYhoFvqo4CQC0rCtWDqyRjbHjrPY7j4K4 SjveGbnZufOkJ59qRrckaW2TpcHMbwlGrKd1buL2TjtVq1i5PuP2+1svPuzmuSthhrmLcQlSXMAA E7FtJ283yZrJb79OtkdUdjpXGSorDcqGzJSlRABKQ6lQSSAMkYzpTnOBgLREc6LjziqEIEJgrauq ClpOsMJSxIOhokABOQNwkHCQBgFQMTFmSLLwjCnW9zkSZc+SxIWADzWm22CltQOQUEur1IPZVtqB 0pxoW7iW6WyXKlsOsuSZWrnPSozUha9QUFdpxKiNQUoKx8bO+a+Il/uUGRJeivIZVIVzFBDKAlK8 kpWhOMNrTk6VIAKcnSRmgtHEH/yn1vgT96ar9cIS8dvXHZ5OhpWrOpHwitSTkL21BWkY+L9BtPDb 9wcbs0WalV7nQW2pbr2llpgt6NPLcSSTzSCVFXxU4xvmrW28z7Rzeif5XMwTlCVaVDOladQOlacn StOFJycEZNZLffp9sjqjsdK4yVFYblQ2ZKUqIAJSHUqCSQBkjGdKc5wMBLWi9vW2OpEefd7FbHH3 ltyregreeVhvDTiwtpKwhJz8xcJx29rDOVEsPhKSJ82wTHr7PjKNmYDvwbXKIaCy40UoSXFYAACt iR2E4p6L7ebZIlR5Ghx4vrW+3cobchSHicLOHkqKVkgaiME6RnOBjHF4kukXnZdYlc51Ty+uitSv hFfGWOalWFKwMkYKsDOcDAT0S4+5jrrC9ebnaJkOc8l6VZ0a+qxpQEqy40dKChRTnP8ACq2T4/y7 QYkni7iazmKzGixp8p1qW22EJhpS4U4XjvaOEp07kEp0AklDleiX+5QpEmS08hUqQvmLkvModeC8 k60uLBUheSTqSQc4OcgVq9bI6DoQ5iMXecpCQBqXjAKj3qwM4z3alYxqOQlrB/EvFP8ARiP8ZGqB qegOXFjhS6KjWLmQ5GGJN05Tx5SQttYb1BXLHaSjvTntd+4qBoLDw9erjGCLfCu67MzqdkSJcZ1T TjqQ2DoJCgFkBBDaSR2nCMjVkRN0ltT7vNmR4qIjMh9brcdvGllKlEhAwBsAcdw7u6scSZIgPKej OaHFNOMk4B7DiChY38qVEf11goFKk7fdIkKOpuRYrfPUVFQdkrkJUBgdkct1Axtnuzud6zt3u3oW 6pXC1ocC1akpU7Lw2MAaRh8bZBO+TlR3xgANuL4Lt3CMK4v2dmfMkT5LGZDzqWw2hthQ7Lakkqy4 cHUBgqyFbFO3bYlkRHkzFMW8QHZjrUN69uSipaEBJ0hMUbLAWkqKjg6k6caVZr0+6Lmtojtx2YkN t1bzUVjUUNrWlCVkFZUs55ae9R+bFfdvv9ytcdTMR5CUFZcQVsocUyvAGtpSgS2vZPaQQeynfsjA WmbwjbGJEqGgv/vefemQ6V9taIkdDjQVtj42c4AzqPzYrXEUKPAubLMZvQ2qBDeIyT23Iza1nfyq UT/XWRHFd5Q/Kf6pC3JT65Dpcjtr7az8IUgpISFjZYTgLT2VAjajfEDa1uu3GzW+5SHFZ50hT6Ch IASlCUtOISlCQAAANhsNgAAzxBBtnDEW5P2qLcXpcx+OUynHgltLSGVAp5S0HJLpzkn4qcY3zt2a LahAdnSotrajPSnG467w/KXkJCSUJEVIOpIWnUpWArUnSBhVRrfE0qMt1MOJb2Iq1a0xHIqJTTSs AEoEjmFJVpGSDvgeIADHF4lu8TnFuXrcddU+XX20OuIdV3uIWsFTazgErSQolKTnsjAT1vjeA+Pe I7TDffEZmLdoh1L3cbQw9gLxgHdCT3YyAfFUZwa+61dpqG3VoQ9abghxKVEBaeldVg+UZSk48oB8 VYIvFV2h3KdcW3Iq5c5S1SHXoTLpUV6teNaCEhQWoEJwCDg7Vjt3ElxtUuVJiCEh2VqDhXAYWAFB QUlIUghCSFKBSkAEHGMYoJqxW+0N8MtXKeq0c6RMejhN0MzSEtoaUCjphnOXTq1HxJx/KztxrVw1 FgSJyJFrfjO3SVGirvHWDUy0GyhSRGAIUQ72tf8A4cAdqq1F4kuMTnBsQltuuqeLT8Bh1tC1d5Qh aClvOADpAyEpH8kYReJLpF52XWJXOdU8vrorUr4RXxljmpVhSsDJGCrAznAwGpdG4TV3mt215b0B D60xnXBhS2go6VHYbkYPcP1Cprh5u1uwHEKjWyTdC6cNXWQ6w2pvA08taFoQFfHKuYoAgICckkHQ i3plvnLn2eFdJLzqnVyZrsjmEnvyUOpB3yckE5J3rI3xNKjLdTDiW9iKtWtMRyKiU00rABKBI5hS VaRkg74HiAACWttut8RiS9cYFvipMx2O2L27LUpJbCSpsJjJSQtOtOpSwAdSdIGFVkm8Ix3p8i02 s6ZMbiJVqL0lZ7aHSUsZwMbFl4qIA+MnGe4QMXiW7xOcW5etx11T5dfbQ64h1Xe4hawVNrOAStJC iUpOeyMGeJbuxPus5qXpk3Vp5mavloPNQ6cuDGMJyfJjHixQWWNC4aMCRdkN2xmNKucpmKzeDMPL ZQG1ICemydWHcK1k9ycfyiafdG4TV3mt215b0BD60xnXBhS2go6VHYbkYPcP1Cti336fbI6o7HSu MlWsNyobMlKVEAEpDqVBJIAyRjOlOc4GPuLemW+cufZ4V0kvOqdXJmuyOYSe/JQ6kHfJyQTkneg3 +HrBH4igOMpV0kmK6XFvqBV1KFABLDacgF/KFlCNuZqVunQMyVviWBdoXeHGLRGTLuMhpmNdHJq0 stIS0pKUKjjJI5pCivvwnGO1VXn3Rc1tEduOzEhtureaisaihta0oSsgrKlnPLT3qPzYrbRxVdkv ynnHIshUp9clwSoTL6eas5WpKXEEIKts6QM6U57hgJaW3w9abR1kS2ouqHbtNjRnpjzqUqjtpZKC pKCg6+3nOR3qyk7aYLiK3tWjia7W2OpamYcx6O2pwgqKULKQTgAZwPJWvKuc2awGZUlbyQ+7Jy4d Si64Ehaio7knQnvPi+c1vo4gbckSpVys1vucuU+uQ7IkqfQoqUckANOISBnJ7vH5MYDbi+C7dwjC uL9nZnzJE+SxmQ86lsNobYUOy2pJKsuHB1AYKshWxTYVcO2a3OzYKreiUWbjd20vvuuBzRDYQ62n sKSnCjkKOnOFHSUnBFe92Mhm1twIECFEYTKdkqYLQksErQ0gYbf19octR1Ek/CKAwMgxieILqkEG YtZKpK1KcAWpSpDYbeJUQSSpIAyf1jB3oLLebfZrFAiTDaUSk3JSSptT7iTGSYsZ4hkhWxzJWAXA 5shGQe1qhuN/+/3Ef9KSf+aqsbXFd5aGEykEpS2ltS47alM6G0tpU0opJbWEoQNaMKOhJJJANEcQ NuSJUq5Wa33OXKfW+7IkqfQoqUckANOITjOT3ePyYwGe12JN8tEJuElDc9V2bguuuqUEqEhI5Pdn ZJaeKjjPaT8bxScNixK664iFa49ukT3kQjeHZZw2nSoISmNkhSUuJ1FaiDqTp+KomBY4hlwJc961 Ns25udFVDeYYSVo5SgApILhWoZxnOc+Qisdvv9ytcdTMR5CUauYgrZQ4pleACtpSgS2vZPaQQeyn fsjAWK3xvAfHvEdphvviMzFu0Q6l7uNoYewF4wDuhJ7sZAPirQ4SsVuu8h/rrpCZ0RZahHeD+vKI 61pcyhBGlKgFEZydJGDkA6kXiq7Q7lOuLbkVcucpapDr0Jl0qK9WvGtBCQoLUCE4BBwdqjTNkdW7 JQ5yXXdeosANDCwQpICcAJIJGkADBxjFBZFur4b4cjSLTPZddkz5DD8qOhWiQ0huOoNkOJBKMur1 IKdKttQUEpxvyOFIFxv9+tcJPQeDLpISlxRU5z2tWluO2Ce0/wBhRQjOXNSsqGjep228z7Rzehf5 XMwTlCVaVDOladQOlacnStOFJycEZNa65khcBmCpzMZl1byEYGy1hAUc9+4bR9HzmgsvDM+Ob9eR Dt7MdiVAuBbSsl1cdvpX1BtKlf8AlBVjUdOMgKUDg4LlcmfcGAwyov2ucC6tGpaEiI8cJzsnJxkg Z2wCAVA6kXiq7Q7lOuLbkVcucpapDr0Jl0qK9WvGtBCQoLUCE4BBwdqx27iS42qXKkxBCQ7K1Bwr gMLACgoKSkKQQhJClApSACDjGMUCyQo7nV3Cc3rgwWtakElIedVs01kY71dpQBCuWhwpOU1LOXmf GsDd8Zf0XK6XSWJzwQn4dKUsL0KTjSUFTqypGNKsjUDpTivSrlKlxxHdUgMpfdkJbbaShKVuBIWQ EgYBCE7DYY2ArJbbzPtHN6F/lczBOUJVpUM6Vp1A6VpydK04UnJwRk0FskcKQLjf79a4Seg8GXSQ lLiipzntatLcdsE9p/sKKEZy5qVlQ0b6HDM+Ob9eRDt7MdiVAuBbSsl1cdvpX1BtKlf+UFWNR04y ApQNaXMkLgMwVOZjMureQjA2WsICjnv3DaPo+c1JxeKrtDuU64tuRVy5ylqkOvQmXSor1a8a0EJC gtQITgEHB2oJaxW+zt8MNXKeq0c6RMejhN0MzSEtoaUCjphnOXTq1nxJx/KzWro3Cau81u2vLegI fWmM64MKW0FHSo7DcjB7h+oVtxeJLjE5wbEJbbrqni0/AYdbQtXeUIWgpbzgA6QMhKR/JGI1992V IckSHVuvOqK3HHFFSlqJySSdySfHQY66ez/oosP85cf+lXMK6ez/AKKLD/OXH/pUR0/gVaonGvGt pTnp2pjclAzslTqSVf8AAfRV/ql8BW6Ul6/X2bGdjP3WcpaGnmyhaWUEpRkHceOrpT2j5R9Fn+af mUpSgUpSgUpSgUpSgUpSgUpSgUpSgUpSgUpSgUpSgUpSgUpSgUpSgUpSgUpSgUpSgUpSgUpSgUpS gUpSgUpSgUpSgUpSgUpSgUpSgUpSgV4ir27XiKgVdLHcfBXCUd7wzdLNz50hPPtSNbkjS2ydLg5j eEo1ZTurdxeycdqpzkLbnyUOROjcS6oKjYUOSc7owolQx3bknbetu336dbI6o7HSuMlRWG5UNmSl KiACUh1KgkkAZIxnSnOcDAWyTNuNou97Qiavhu3NXaUlxy0lXMeXqADCAFN8xDYGRnSEBZOxWlKt vgtmNP4uh36Exa2npN9ATBelMo6JnmIVlttRSXFELKElKezoOBqKSinx+KrtHYWypyLJSt9clRmw mZSi6sJC1anUKOTpTnffFaDNylRru3dI6kNS2nxIbU20lKULCtQIQBpAB8WMeLGKCw2aZc7PAdR4 XfssFqU4l2ZbV6npbmEjlp0OJS6lGNWdQSkOKOcrSlVeuktqfd5syPFREZkPrdbjt40spUokIGAN gDjuHd3VtwOJLjbYAgsiE5GDqnkolQGJGlagkKILiFEZCE93kFfEO/3K3yLg9DeQwq4MORpIbZQE qacIK0hOMJBwPigY8WKCSsN6l2uAlvwldLNDcdcV1lsZJckOAN/BrPMbCkoG4GSUlw7dvaWl3WXZ L9eInVTeHYfhSWOdZGyrmOBSRydWtoKQ2N09xTzD2Rr2q9vv0+2R1R2OlcZKtYblQ2ZKUqIAJSHU qCSQBkjGdKc5wMfcXiS6Redl1iVznVPL66K1K+EV8ZY5qVYUrAyRgqwM5wMBdJyolh8JSRPm2CY9 fZ8ZRszAd+Da5RDQWXGilCS4rAAAVsSOwnELFlXHhWRLtD90uFoZjzJDLk60NKUqS8goSUElxsKQ kdoeNPMO3b2hYvEl0i87LrErnOqeX10VqV8Ir4yxzUqwpWBkjBVgZzgYReJLpF52XWJXOdU8vror Ur4RXxljmpVhSsDJGCrAznAwF0nKiWHwlJE+bYJj19nxlGzMB34NrlENBZcaKUJLisAABWxI7CcQ tgYdsfEt9szzUVyQ1DuUd18JKinlxnwQgnuBIG+ArAxkAqBhYvEl0i87LrErnOqeX10VqV8Ir4yx zUqwpWBkjBVgZzgYW7iW6WyXKlsOsuSZWrnPSozUha9QUFdpxKiNQUoKx8bO+aDYsH8TcU/0Wj/G RqgasMeTc/c5eJDViQuLMXy5VzbjuJS0OY25yxpIaQNSUbac9rA2IFV6gVPcI/xzI/ou4f4N6oGp bht+cxfGjbrd4SkuNPM9Jy1r5qFtKQsYQQr4qlHYjGM0CyQ48jq5LzfVKiNc5MFJIU/jvJIwdCQN StJ1Y7sDUtE1w1Ltblp4qeuMGU68uGHHDFkNx0FBlR+ylHKUEnUQcjbA0hI7xW33JMG7uOIZXbpT D5UGmytCoy0q+KNRKgUkY3ORjvzWaE7dbhMlxbcwt5+5JKHY8WMCXEhYdIShI7IBbBwkDAT5KCb4 TetLdh4lE6FNecEBJWpiYhoFvqo4CQC0rCtWDqyRjbHjpwm9aW7DxKJ0Ka84ICStTExDQLfVRwEg FpWFasHVkjG2PHUDaxcn3H7fa2Xn3ZzXJWww1zFuISpLmAACdi2k7eb5M0tYuT7j9vtbLz7s5rkr YYa5i3EJUlzAABOxbSdvN8maCe4TetLdh4lE6FNecEBJWpiYhoFvqo4CQC0rCtWDqyRjbHjpwm9a W7DxKJ0Ka84ICStTExDQLfVRwEgFpWFasHVkjG2PHUDaxcn3H7fa2Xn3ZzXJWww1zFuISpLmAACd i2k7eb5M0tYuT7j9vtbLz7s5rkrYYa5i3EJUlzAABOxbSdvN8maCe4TetLdh4lE6FNecEBJWpiYh oFvqo4CQC0rCtWDqyRjbHjpwm9aW7DxKJ0Ka84ICStTExDQLfVRwEgFpWFasHVkjG2PHUDaxcn3H 7fa2Xn3ZzXJWww1zFuISpLmAACdi2k7eb5M0tYuT7j9vtbLz7s5rkrYYa5i3EJUlzAABOxbSdvN8 maCe4TetLdh4lE6FNecEBJWpiYhoFvqo4CQC0rCtWDqyRjbHjrPY7j4K4SjveGbnZufOkJ59qRrc kaW2TpcHMbwlGrKd1buL2TjtVq1i5PuP2+1svPuzmuSthhrmLcQlSXMAAE7FtJ283yZrJb79Otkd UdjpXGSorDcqGzJSlRABKQ6lQSSAMkYzpTnOBgLREc6LjziqEIEJgrauqClpOsMJSxIOhokABOQN wkHCQBgFQMTFmSLLwjCnW9zkSZc+SxIWADzWm22CltQOQUEur1IPZVtqB0pxoW7iW6WyXKlsOsuS ZWrnPSozUha9QUFdpxKiNQUoKx8bO+a+Il/uUGRJeivIZVIVzFBDKAlK8kpWhOMNrTk6VIAKcnSR mgtHEH/yn1vgT96ar9cIS8dvXHZ5OhpWrOpHwitSTkL21BWkYx3632bh5+4K8EolMrvc6AlC33Eq YZZLenlKCsa8OndYWOynbvzXrDMvTUsxLIl52TI3SyywHl6kgkLQnBKVpGohacKTk4Iyax2+/wBy tcdTMR5CUFXMQVsocUyvAGtpSgS2vZPaQQeynfsjAXHi2ZIss+7Trc5yJMviO5sSFgA81pstFLag cgoJdXqQeyrbUDpTjUv0G08Nv3BxuzRZqVXudBbalOvaWWmC3o08txJJPNIJUVfFTjG+a63xLd2p 82ciXiTNdL7yy2g/CkkhxIIwhYKlaVpwpOo4Iya/YF3ulqgDlNMrhuOq0dXBakNhwBOvRzUKCVYK NWnBI0Z7hQStm4iiQIDsSNdL1Yv3048HreA64+2oJCG3VBbWdGlRB3BLisBPjz3aDEk8XcTWcxWY 0WNPlOtS22whMNKXCnC8d7RwlOncglOgEkocr0S/3KFIkyWnkKlSFcxcl5lDrwXknWlxYKkLySdS SDnBzkCtXrZHQdCHMRi7zlISANS8YBUe9WBnGe7UrGNRyEtYP4l4p/oxH+MjVA1PQHLixwpdFRrF zIcjDEm6cp48pIW2sN6grljtJR3pz2u/cVA0Fh4evVxjBFvhXddmZ1OyJEuM6ppx1IbB0EhQCyAg htJI7ThGRqyIm6S2p93mzI8VERmQ+t1uO3jSylSiQgYA2AOO4d3dWOJMkQHlPRnNDimnGScA9hxB Qsb+VKiP66wUFl4esEfiKA4ylXSSYrpcW+oFXUoUAEsNpyAX8oWUI25mpW6dAzJW+JYF2hd4cYtE ZMu4yGmY10cmrSy0hLSkpQqOMkjmkKK+/CcY7VVeKLldW41nhsvStLrjzMZhrWsrUlOsgAZPZbT+ rT+ut+NxHfHpctaQzNdkuuzHUPwGZICyCpxxKVoUEbJyopA2SM7JGAkpbfD1ptHWRLai6odu02NG emPOpSqO2lkoKkoKDr7ec5HerKTtpguIre1aOJrtbY6lqZhzHo7anCCopQspBOABnA8la8q5zZsc MypK3kh92Tlw6lF1wJC1FR3JOhPefF85rfRxA25IlSrlZrfc5cp9b7siSp9CipRyQA04hOM5Pd4/ JjAZ+DX3WrtNQ26tCHrTcEOJSogLT0rqsHyjKUnHlAPirfsVvs7fDDVynqtHOkTHo4TdDM0hLaGl Ao6YZzl06tZ8Scfysxrd+uFius1UK3wra6vLLsZcNL3KwkoWgc8LWnIKgoZ3yQdsAa8XiS4xOcGx CW266p4tPwGHW0LV3lCFoKW84AOkDISkfyRgJ6JAsUbrpAFrdtq57zEKXeHJfwzaNJGlEZIUlQSt BUV7HWkJA0qym8Ix3p8i02s6ZMbiJVqL0lZ7aHSUsZwMbFl4qIA+MnGe4QMXiW7xOcW5etx11T5d ebQ64h1Xe4hawVNrOAStJCiUpOeyMZG79fIsi5XVDy0KvCH40p8sp0vhZSp1IyMA9pJOnBGR3ZoL DGhcNGBIuyG7YzGlXOUzFZvBmHlsoDakBPTZOrDuFaye5OP5RNPujcJq7zW7a8t6Ah9aYzrgwpbQ UdKjsNyMHuH6hWxb79PtkdUdjpXGSrWG5UNmSlKiACUh1KgkkAZIxnSnOcDH3FvTLfOXPs8K6SXn VOrkzXZHMJPfkodSDvk5IJyTvQbfBr7rV2mobdWhD1puCHEpUQFp6V1WD5RlKTjygHxVsWCJb0Wg zLixaEodfW029dHJZSsoSgqShMYZBGtJUVnB1J040qzoROJZVsnSZNriW+EJCNBa6VMhKU6SlQSX +YoBQUrUM75wdsAY4vEl0h87p3WUc11TwxGa+BcPetns/Aq2G7ek9lPmjAT3QW60X++W9+0wpNtt s91pc+ap8uJQFFKEANOtpWtWg4TgZOokpSklMZMgxbjaGJlotq0PSLtIZ6dpanlNNqS0Y7Xzknmh JxlWlXfp2O8U36LImMTExVvLmPSH25ttYdUh9ZAcOHGyUElIyBgbd1fFkuSEy7gt6NdHXZbTnMRa ZSYgLWCp1KkhpQKMDOkAJASdsdwa/FMKPbeLr1BiN8uNGnvstIyTpQlxQAydzsB31O8PW21v8PRn ZVsZkPvO3FZeW46FBMWK2+hACVgaVKKgrbOFHBScERLnEjMqfPnT7BbJsmbKckrW6uQnSVnJSkId SNIOcZyd+81gc4hlhQTCbZgxk8/lxmAVIRzmktO4LhUo6kpHeo48WKC6LsNjjxYx8EsuKltSJpUt 57LXLt8eWGk4WOwVuLQc5VpPxgrtVA8WWaBbbTbZcNjlLlulawFqISlUWI8EDJPZSp9wDOTjGScZ qJXxLd3EMpVLyllpbLY5aNkLYRHUO7xtNoT/AFZ7yTWRriu8tDCZSCUpbS2pcdtSmdDaW0qaUUkt rCUIGtGFHQkkkgGgsLXC1ne424ggruEKLGiO3FtiI91BWlLTbpQvUlCgUpKQTlWToOxyAdBbq+G+ HI0i0z2XXZM+Qw/KjoVokNIbjqDZDiQSjLq9SCnSrbUFBKcV5+5zZNylXFySvq5SnFPOoOgrLmdf xcDCgpQI7sEjurJbbzPtHN6F/lczBOUJVpUM6Vp1A6VpydK04UnJwRk0FskcKQLjf79a4Seg8GXS QlLiipzntatLcdsE9p/sKKEZy5qVlQ0b6lt4mhRo8lmHOu/DiVzHX0G1/DKcaWEhDS1FxskN6TpJ Ks8xWyd81ZcyQuAzBU5mMy6t5CMDZawgKOe/cNo+j5zW+3xJdGp82el1kzJjpedkKjNKcS4STrbU U5aVlROUaSDjyDATV0tkJnjbimQ/GQm12yZIwwgaELXzFJZZGMbE7lIIPLQ4UnKaxuXmfGsDd8Zf 0XK6XSWJzwQn4dKUsL0KTjSUFTqypGNKsjUDpTitLmSFwGYKnMxmXVvIRgbLWEBRz37htH0fOa2L beZ9o5vQv8rmYJyhKtKhnStOoHStOTpWnCk5OCMmgtkjhSBcb/frXCT0Hgy6SEpcUVOc9rVpbjtg ntP9hRQjOXNSsqGjfQ4ZnxzfryIdvZjsSoFwLaVkurjt9K+oNpUr/wAoKsajpxkBSga0uZIXAZgq czGZdW8hGBstYQFHPfuG0fR85qatF94hdvst62somXS5KcU6PBzUhxwqCi5pSpCsAhS9QSACO/YU GSLMkWXhGFOt7nIky58liQsAHmtNtsFLagcgoJdXqQeyrbUDpTjQ4phR7bxdeoMRvlxo099lpGSd KEuKAGTudgO+viJf7lBkSXoryGVSFcxQQygJSvJKVoTjDa05OlSACnJ0kZqMoFKUoFKUoFKUoFKU oFKUoFKUoFdPZ/0UWH+cuP8A0q5hXT2f9FFh/nLj/wBKg9HUqe6dn8y36opyGfzTfqiggaVPdOz+ Zb9UU5DP5pv1RQQNKnunZ/NN+qKdOz+Zb9UUEDSp7p2fzLfqinTs/mW/VFBA0qe6dn8y36op07P5 lv1RQQNKnunZ/Mt+qKchn8036ooIGlTnIZ/Mo9UU5DAGS02B/wDaKCDpUywIcpht9gMusuJC0ON4 UlSTuCCO8Vk6Zn80j1RQQVKnunZ/Mt+qKdOz+ab9UUEDSp7p2fzLfqinTs/mW/VFBA0qe6dn8y36 op07P5lv1RQQNKnOQz+ZR6opyGAMlpsD/wC0UEHSplgQ5TDb7AZdZcSFIcRhSVJO4II7xWFMm1ru K7cl+Iqa2gOLjBaS4lJ7lFPeB89BGUqe6dn8y36op07P5lv1RQQNKnunZ/Mt+qKdOz+Zb9UUEDSp 7p2fzLfqinIZ/NN+qKCBpUpLlWuC7HalvxI7khfLYS6pKS6rzUg95+YVtdOz+Zb9UUEDSp7kM/mm /VFOnZ/Mt+qKCBpU907P5lv1RTp2fzTfqiggaVPchn8y36orQn3OyWtxhu4zbfDXIOllMh1DZcO2 yQrGe8d3lFBoUqe6dn8y36op07P5lv1RQQNKnunZ/Mt+qKxv9HFjuPyOQ0y2kqW45hKUgd5JOwFB C0qdDDBGzTfqisbXRvLdQ1yFqZVocSnBKFYBwfIcEHHkIoIalTLHRSUFxjkOoClIKm8KGpJIUMjx gggjxEV+AwlSFx08gvISla2xjUlJzgkd4B0nH6j5KCHpU707P5pHqinTs/mkeqKCCpW9KutjhT2Y Eudb2Jr+OTHddQlxzJwNKScnJ22qQ6dn8y36ooIGlT3Ts/mW/VFYnTDZW0hzkIW8rQ2lWAVqwTge U4BP6gaCGrxFXu5Ey0uXNdtRIhKnoRzFxQ4kupTt2invA3G/z14RoFXSx3HwVwlHe8M3Szc+dITz 7UjW5I0tsnS4OY3hKNWU7q3cXsnHaqc5C258lDkTo3EuqCo2FDknO6MKJUMd25J23rbt9+nWyOqO x0rjJUVhuVDZkpSogAlIdSoJJAGSMZ0pznAwFskzbjaLve0Imr4btzV2lJcctJVzHl6gAwgBTfMQ 2BkZ0hAWTsVpSrb4LZjT+Lod+hMWtp6TfQEwXpTKOiZ5iFZbbUUlxRCyhJSns6Dgaikop8fiq7R2 FsqciyUrfXJUZsJmUourCQtWp1Cjk6U533xWgzcpUa7t3SOpDUtp8SG1NtJSlCwrUCEAaQAfFjHi xigsNmmXOzwHUeF37LBalOJdmW1ep6W5hI5adDiUupRjVnUEpDijnK0pVXrpLan3ebMjxURGZD63 W47eNLKVKJCBgDYA47h3d1bcDiS422AILIhORg6p5KJUBiRpWoJCiC4hRGQhPd5BXxDv9yt8i4PQ 3kMKuDDkaSG2UBKmnCCtITjCQcD4oGPFigkrDepdrgJb8JXSzQ3HXFdZbGSXJDgDfwazzGwpKBuB klJcO3b2lpd1l2S/XiJ1U3h2H4UljnWRsq5jgUkcnVraCkNjdPcU8w9ka9qvb79PtkdUdjpXGSrW G5UNmSlKiACUh1KgkkAZIxnSnOcDH3F4kukXnZdYlc51Ty+uitSvhFfGWOalWFKwMkYKsDOcDAXS cqJYfCUkT5tgmPX2fGUbMwHfg2uUQ0FlxopQkuKwAAFbEjsJw4L4dNo4uh6nbZIuUW+iC829LaRy UNuICnG23CFOKXlSUkDs6CQNRSUUuLxJdIvOy6xK5zqnl9dFalfCK+Msc1KsKVgZIwVYGc4GNRm5 zY93buqJKzPbfEkPuHWouhWrUdWcnO++c0Fhs0y52eA6jwu/ZYLUpxLsy2r1PS3MJHLTocSl1KMa s6glIcUc5WlKtiJfZY66fElv8M2h6e87qtuQ84pekpYSEqQHEtjffSEBat8rSlUDA4kuNtgCCyIT kYOqeSiVAYkaVqCQoguIURkIT3eQVkj8U3OLHXHQm3rZW+uRy3rbGdShawkKKAtshAISnZOBsNqD fiS2p6ONZjEVERmRD5rcZvGllKp0chAwBsAcdw7u6qtVhjybn7nLxIasSFxZi+XKubcdxKWhzG3O WNJDSBqSjbTntYGxAqvUCp7hH+OZH9F3D/BvVA1LcNvzmL40bdbvCUlxp5npOWtfNQtpSFjCCFfF Uo7EYxmgWSHHkdXJeb6pURrnJgpJCn8d5JGDoSBqVpOrHdgalomuGpdrctPFT1xgynXlww44Yshu OgoMqP2Uo5Sgk6iDkbYGkJHeK2+5Jg3dxxDK7dKYfKg02VoVGWlXxRqJUCkjG5yMd+azQnbrcJku LbmFvP3JJQ7HixgS4kLDpCUJHZALYOEgYCfJQTfCb1pbsPEonQprzggJK1MTENAt9VHASAWlYVqw dWSMbY8dOE3rS3YeJROhTXnBASVqYmIaBb6qOAkAtKwrVg6skY2x46gbWLk+4/b7Wy8+7Oa5K2GG uYtxCVJcwAATsW0nbzfJmlrFyfcft9rZefdnNclbDDXMW4hKkuYAAJ2LaTt5vkzQT3Cb1pbsPEon QprzggJK1MTENAt9VHASAWlYVqwdWSMbY8dOE3rS3YeJROhTXnBASVqYmIaBb6qOAkAtKwrVg6sk Y2x46gbWLk+4/b7Wy8+7Oa5K2GGuYtxCVJcwAATsW0nbzfJmlrFyfcft9rZefdnNclbDDXMW4hKk uYAAJ2LaTt5vkzQT3Cb1pbsPEonQprzggJK1MTENAt9VHASAWlYVqwdWSMbY8dOE3rS3YeJROhTX nBASVqYmIaBb6qOAkAtKwrVg6skY2x46gbWLk+4/b7Wy8+7Oa5K2GGuYtxCVJcwAATsW0nbzfJml rFyfcft9rZefdnNclbDDXMW4hKkuYAAJ2LaTt5vkzQT3Cb1pbsPEonQprzggJK1MTENAt9VHASAW lYVqwdWSMbY8dZ7HcfBXCUd7wzc7Nz50hPPtSNbkjS2ydLg5jeEo1ZTurdxeycdqtWsXJ9x+32tl 592c1yVsMNcxbiEqS5gAAnYtpO3m+TNZLffp1sjqjsdK4yVFYblQ2ZKUqIAJSHUqCSQBkjGdKc5w MBaIjnRcecVQhAhMFbV1QUtJ1hhKWJB0NEgAJyBuEg4SAMAqBieC5XJn3BgMMqL9rnAurRqWhIiP HCc7JycZIGdsAgFQOhbuJbpbJcqWw6y5Jlauc9KjNSFr1BQV2nEqI1BSgrHxs75pbuJLjapcqTEE JDsrUHCuAwsAKCgpKQpBCEkKUClIAIOMYxQS/Cb1pbsPEonQprzggJK1MTENAt9VHASAWlYVqwdW SMbY8da9hvUu1wEt+ErpZobjriustjJLkhwBv4NZ5jYUlA3AySkuHbt7RkJ263CZLi25hbz9ySUO x4sYEuJCw6QlCR2QC2DhIGAnyV+2+/TrZHVHY6VxkqKw3KhsyUpUQASkOpUEkgDJGM6U5zgYC0cQ PyOHetkW5ti3yX77cI0huOApstNckpZ3SAprLi8pKQlY06knSkDY4j8F2CBIiJs7MxpjiO6MR2pD zobbbSI4/kKSpSsBIBKsY1ZBJBFPicQXWFIkyGZiy9JVzHXHQHFFzJIdBUCUuAqVhwYUNRwRk19w OJLpbYAgMOsrhh1T3TyIzT7fMUEgr0uJUNWEgA94GrGNSshZVXCJwvcLtYI15vVo6K6SEiVb0Bbk psEIQl3DjXxNCiO8ZdVgJ8evdoMSTxdxNZzFZjRY0+U61LbbCEw0pcKcLx3tHCU6dyCU6ASShyvR L/coUiTJaeQqVIVzFyXmUOvBeSdaXFgqQvJJ1JIOcHOQK1etkdB0IcxGLvOUhIA1LxgFR71YGcZ7 tSsY1HIS1g/iXin+jEf4yNUDU9AcuLHCl0VGsXMhyMMSbpynjykhbaw3qCuWO0lHenPa79xUDQWH h69XGMEW+Fd12ZnU7IkS4zqmnHUhsHQSFALICCG0kjtOEZGrIibpLan3ebMjxURGZD63W47eNLKV KJCBgDYA47h3d1Y4kyRAeU9Gc0OKacZJwD2HEFCxv5UqI/rrBQW3hN60t2HiUToU15wQElamJiGg W+qjgJALSsK1YOrJGNseOo/hNLTlzmNuNatVrnFKg4tCm1JjOLBBSoZzp0kHIIUQRUay7NhwX1Nh aIs1JjOLKOy4EqbcKQSO8ENk433HiO+3YbvdLU8/4KaZW640vma4TUhQbCFa8a0K0p0FerGARnOw oN+L4Lt3CMK4v2dmfMkT5LGZDzqWw2hthQ7Lakkqy4cHUBgqyFbFO/d7XaOGesQ5b/CDZvM23hT7 y0ONtMcrCkFBCQs805KkrTlKez3g1aTcpUuOGHVIDKX3ZCW22koSlbgSFkBIGAQhOw2GNgK30cV3 lD8p/qkKekvrkqcXHbUpt5RypxolOWlk47SNJ7KfNGAycb/9/uI/6Uk/81Va8iFHb4Rt05LeJL0+ UyteTuhDccpGO7YuL+n5hWw5eVNT56r1YYU65OynHJDk3ntOJcJ7SSltxAHaztpyCT8wGNviabFW 74OaiwWVq5jbLbXNEdeACtpTutbazpBKkqByE79lOAsN/hWPh3rVt2NmW4L9cITSZEh7loYa5OkY QtKioazg6u4qyFbFOS+N23hu0LgG2ouSIvEFyjMdY8sJCEJjJyoNlBKzhO+oAdrsnIKafcLzPuuv rX+brlPTFdhKcuu6eYrYDv0J27hjYCt4cY3z4cOSWX25Ep2Y61IiMutqfcxqc0LQU6uyADjYFQGN RyEvd7ba+FesxbGLni8zYCOucdGhtjlaSOUtHaPNOc5GwwBvnU4qsUKyMONxQsqZvdwg81xWVKaZ DGjONs9tRyAM5/ViMi8SXSLzsusSuc6p5fXRWpXwivjLHNSrClYGSMFWBnOBjJHv18hR1yUvLUiQ +taZL7KXVB/CStbbiwShzdBKkEK+ISdk0Fhv8Kx8O9atuxsy3BfrhCaTIkPctDDXJ0jCFpUVDWcH V3FWQrYpwXe12jhnrEOW/wAINm8zbeFPvLQ420xysKQUEJCzzTkqStOUp7PeDWrheZ9119a/zdcp 6YrsJTl13TzFbAd+hO3cMbAVto4rvKH5T/VIU9JfXJU4uO2pTbyjlTjRKctLJx2kaT2U+aMBk43/ AO/3Ef8ASkn/AJqq/OE0tOXOY241q1WucUqDi0KbUmM4sEFKhnOnSQcghRBFfCOIG3JEqVcrNb7n LlPrfdkSVPoUVKOSAGnEJAzk93j8mMInEsq2TpMm1xLfCEhGgtdKmQlKdJSoJL+tQCgpWoZ3zg7Y ADbi+C7dwjCuL9nZnzJE+SxmQ86lsNobYUOy2pJKsuHB1AYKshXZKftbdjgWgT27audFmXGVGa6p 5TbzLDaWlIKSghIcIeOSoLTlKcJxkGClXKVLjiO6pAZS+7IS220lCUrcCQsgJAwCEJ2GwxsBW3ab xd4bS4tuOrGt9I6dDq2SE5U42VJJaUEpBK0EHsA57IwFla4Ws73G3EEFdwhRY0R24tsRHuoK0pab dKF6koUClJSCcqydB2OQDoLdXw3w5GkWmey67JnyGH5UdCtEhpDcdQbIcSCUZdXqQU6VbagoJTiG ut5duPEVyu7IXFVOffdKEOHKUulWpGoYyMKKT5QTtvWO23mfaeb0L/K5mCcoSrSoZ0rTqB0rTk6V pwpOTgjJoLZI4UgXG/361wk9B4MukhKXFFTnPa1aW47YJ7T/AGFFCM5c1KyoaN9S28TQo0eSzDnX fhxK5jr6Da/hlONLCQhpai42SG9J0klWeYrZO+asuZIXAZgqczGZdW8hGBstYQFHPfuG0fR85rfb 4kujU+bPS6yZkx0vOyFRmlOJcJJ1tqKctKyonKNJBx5BgLpc+IIlnn3myxr1erF099nOhNpYHLW2 ooShJAebxp5asDBGFbVWvBK41+vj19X1YtbrolLLiiJUnUUoRqOCrUvKlbpUW0OEbio2336dbI6o 7HSuMlRWG5UNmSlKiACUh1KgkkAZIxnSnOcDGvKuc2awGZUlbyQ+7Jy4dSi64Ehaio7knQnvPi+c 0FhcvM+NYG74y/ouV0uksTnghPw6UpYXoUnGkoKnVlSMaVZGoHSnG/I4UgXG/wB+tcJPQeDLpISl xRU5z2tWluO2Ce0/2FFCM5c1KyoaN6nbbzPtHN6F/lczBOUJVpUM6Vp1A6VpydK04UnJwRk1rrmS FwGYKnMxmXVvIRgbLWEBRz37htH0fOaC021mzuR5Nyet9oiRJMx1EVN0kTHEpSkJVy0dONWUhxOp Th7WpOkAhWd+LEslkk8d2x6JcJKYaFshaJiGyplE1hKRu0rC8gEq7iMjSO8VpHFd5Q/Kf6pCnpL6 5KnFx21KbeUcqcaJTlpZOO0jSeynzRjUevM9+TcpDr+p2556tWhI5uXEunxbdtKTtjux3bUGhSlK BSlKBSlKBSlKBSlKBSlKBSlKBXT2f9FFh/nLj/0q5hXTmf8ARRYf5y4/9Kg7aqdxJbeHJV1cuFxl ImPx2YTMhmMl9ltbiUFw4Q2kLIVkJXsnbVncVYeEpl0kN3Bi6CQVxpAQ2Zao/P0lCVYcDCigHJOO 7KSnbxndicMWCAzIZhWS2xmpKND6GYiEJdTvsoAdobnY+U1uQLdCtcRMS3w48OMkkpZjtJbQCdzg AAUFDYuHEEl+Avw882ifdZkAtpjs4aabL5SpJKM8wcoDKiU470k71nh3a73RduthvLsNRE/mTW2m i46Y74aTspBQMg6lYSNwMYGauqbdDRy9ERhPKcU83hsDQtWdSh5FHUrJ7zqPlrXl2Czz4giTLVBk Rg4Xgy9HQtAWSSVaSMaiVEk/OfLT2Wau/v3UdHGF1e4cus9cppl5vh2PPZ0oTpS6sPZWkKBJBKEY Bz4vKa3592u8XiIurnSk25MthgdK3GdjoC9A0PJJD4cKl7FGUgKQcHcG1TLFaLi407OtcGUtpJQ0 p+OhZQkjBAJGwI76/XLHaXrm3c3LZCXcGhpblKjoLqB5AvGR3nx+OrM9bJnoptrv/EEu/sOrRMEJ 64SIa23jETGCEFwJ5eFc8ufBgkEEHt7AYIvzyillah3hJIrURZrW1dV3Ru2w03BxOlctLCQ6obDB XjJGw8fiFZoUJmBDRFZThpOcAgeMknYbeOszcxSe9uf2iZxFcEWRD3EchJuloVOdWiMxlpaOVgN5 bIweZ2tQV3baa+HOJ7zNsy7ii6iAuFYWLpyktNqRIcWFkhepJOj4MDCCk9o791dDbgQ2eTyojCOS 2WWtLYHLbOMpT5E9lOw22HkrWesFnkdHzrTBc6LHS646FcjGMaMjs9w7sdwrUzf3816KfcuKbxBj 3BlDgVNgNyJ6kqQnKo+jU0lQAGBqXpzsSGVb95qU4UnXly5TIdyM1bKWWnmlT1RA+CoqB2jqI0HS MEgHOrc+K0COyH1vhpAdWkIU5pGpSRkgE+MDUdvnPlrXttotlnacatduiQW3Fa1ojMJaCleUhIGT SGVMmXq7N3O/yW71pbtc+Oy1A5TelxLiGshZ068krVpwRv36htX3Gvl1VPhzVXMramXOVAVby03o aQ2HdKkkJ16xygTlRGFKwBtiwxOFrexept2kR40mW9J6hh1yOnmR/gkNkJUcnfRnIx31vIs1sbub tyRboiZ7qdDkpLCQ6tO2xVjJGw2z4hUns0537oeIpVhfuCLy4yuHw9EuRShhoh55SXSrVlB7J0DI Tg+QjfOyqZcLOOLpcWVKfeevEZhKAlnLXMbYTqRqCRqwvA1nT2U5zvm+i0W4MLYECKGVspjrbDKd Kmk5wgjG6RqOB3bny1+Ls9scdlOOW+KtcpsNSFKZSS8gDASs47QxnY1ZmLuPvqsypDN14jceiWt6 bLhrduhjF98RFyuV0yncLDWttKtQGDpGU428ZmeK2HHb9wmUTX44TcVghsIwr97unfUk+IFO2NlH x4InYlltcFhhiHbYcdqOsuMtssJQltRBBUkAbEgkZHlPlrNMgQ57aETIrElDaw4hLzYWErHcoA9x HiNLZv6KZCvd0cukGYu5lxqbdZNvVby02ENIb5uCkhOvX8ECcqIwpWANsTlxuciLxVBhh8IjOwJT ykqA3WhTWDk77BStvn+apFu0Wxm6OXNu3REXB1OlyUllIdWnbYrxkjYePxCvqfarddA0m4QIssMr 5jQkMpc0K85OQcH56nst9bc6i8R3ufED6+IekUxw9FuZSGGjzXSHCsq1J+IdKchOk92Cnx7Y4hvD rt3uHhblCBLioRbOU3pUl1tklKyU68krVpwQcg51DarN7kLU5eVTn4cN5lLEdqPGcjJKY5aLhCkZ 2H8JgYAxiskThe3sXqbdpEeNJlvSeoYdcjp5kf4JDZCVHJ30ZyMd+Kt9Zn77k91Yt/EHEEm9NvqR LTDdnyYi0PGImMlKC4Elvtc8ufBgkEEHt7AYIsHCb86ZwZDn3Cc5LkzIqJCipCEBGpAOlISkbfry dzv3VKostqRc3Lki2w03BxOhcoMJDqk4AwV4yRsPH4q2mYzMeM3HZZbbYbSEIbQkJSlI2AAGwGPF WZ640X1tyiJfL7H4ftsa1iYhECwxJSVM9IGlKUlWeeX1JPLHLH8GQR2snux9swpbvG7chd4moKuI d2gGCkHwfqwDy8nbsd/xd/jdqujv8P2aUIgkWmA8IWOlDkdCuRjGNGR2e4d2O4VkftFtlahIt8V3 U8l88xlKsupACV7j4wAAB7xgVu/xTP33LRvEsuY2/aIEWWuF18osuSkIQpaAG1rwkLBTqUUAbg7Z 2zgiLfl3F+fbbMzxKUhTMp124R2mS44ppaEhBCkqQCNZ14SDlO2ncVa50CHc4i4k+IxLjLxrZfbD iFYORlJ2O4rVfsFml29m3SbTAfhMY5UZyMhTbeBgaUkYGx8VYLUJXE9+m2WbdG7l0xi8OtXBLbLD ZQt5xL3aOtJOnsJIGR4s53FblwvV9sy7rF6+RPXogqaWGWUuNGQ8ttYRslG2kadecH4xUNqvLlvh PB4OQ46w80GXQpsHmIGcJV5U9pWx23Plo7b4T/P50RhzqGwy9rbB5iBnCVeUdpWx23PlrUzFn39F FZunEbr0S1vTZkNbt0McvviIuVyumU7hYb1tpVqAwdIynG3jNk4lly2XLRBizFQuvmFhclCEKWhI bW5hOsFOolAG6SME+PFSUSzWuAywxDtsOOzHWXGW2WEoS2oggqSANiQSMjyny1mnW+Hc4i4k+IxK jLxrZfbDiFYORlJ2O4qSKBZXZ9z40tEiTdH3DGYuTGUNtBD4akNt6j2MgqGNWkgZRtgEgyHF10u8 C4PvRp0pmDEipfc6JEZ0snKsrfbdIWWyE7cshR0r8eKt7FuhRuR08SO107ZaZ5bYTy0HGUpwNk9k bDbYeSsE6yWm5yGJM+2Q5b8c5ZdfYS4po5B7JIyNwDtVvsWr7M6bOvVwkOX4W+NAmtRkxFtNct1K kIV2yoa9Sy5hOFJx2dlbgw673fzBZcRMnvrn3eRDSiI3GC2G2lPY5fNATqPLSCVlWwOBmry9ZbXI uTVyetsNyeynS3KWwkuoG+yVkZA3PcfGa/XrRbZMByA/b4rsNxRWuO4ylTalFWokpIwSVb/r3qR2 L6KGb/xNIRbbdouIkrEtTjsEwVSFcpxKEhetZZBwrthJzqG2kZFYpXEHEci2z5wugiLg2Ni4cqOh lxtx484qBUQvKDoGyVeTCu/N9kcP2aZbmLfKtEB+ExjlRnYyFNt4GBpSRgbE91bC7bBcDqVw46g8 0GXQpoELbGcIV5UjUrbu3PlqxMETDO2oqQknxjNVSEIBvHFgu4j6so5vPxjo+SMZz/8AT1c7v2zq q0ojstOuOtstoccxrWlIBVjYZPjxWncLFaLs807crVCmuM55S5MdDhb/APtKgcdw7vJUlIUu4Xl9 mJLVZLs5Bt9psrU+K2tsK6kHmYDpdSV6MNpGxSrtHJ7q+37zfOunTU3NxpiLd4cRMLktFCkOhjWF Ep1ZHNUQQob9+RgVdJtntlyejvzrdElOxla2HH2UrU0rY5SSMpOQO7yCsirfCXzNURhXMdS8vLYO pxONKz5VDSnB7xpHkq31v77imxbteW+JGxLnSlRpEqQwzym4zsNzSFlKEKSQ8hxIR2tYKcpWPGCI i63+bcOC47b8tLnW8KypckBKRrdCWhq2G3x17DA+bauhtWS0sXNy5s2yG3cHAQ5LQwkOrG2xXjJ7 h4/FWNrhyxsl8tWe3tmQFh7RGQOaF41att84Gc9+BUhqMoibQvCLDrV94qUua88FXFGG1hGEfvdo 7aUg9xA3J2SPHknb4b/jrin+k0f4Ziplu3w2ZjsxqIwiU8lKXX0tgLWB3Aq7yB4s1pSeFuHps8z5 Vitj8wkKMh2I2pzI7jqIzkYH0U/1X0/0z7KtFvV2ukpmGbuqDg3B4voZbJcDMktoQdSSNISRnACj t2hvmAj3a9P2+bxC1dS1LZ4bhzXShhsiQ4OerCgQQEHfITg92FDG96v3C6ro3HbhLtjDTS1ucmXb ESW+Yo55qRqSUuA6jqzg6jkE7iQgcPW232lq3JitPNJioiLLraVKdbSCAle3aG527u0fLVien38W r6z8VQjm5RHOMHodzX1Dl0ZQhDpZTp1NMZDZUkDmFKtCNZKSQnPjJlbFe7iIclp2Jd7nJYmchxDz cRp+OChKxzClxLaxhQOUb4IBGQSbA7ZbW+uUt62w3FSkBuQVsJJeQO5K9u0B5DWWBboVqiJiW+HH hxkklLMdoNoBPfgAYqQzKoWvwceGOJPDIYCuqleEuaRnRqVy9WfFyuXp+bGKjmuILzbuGLiJUtbM yFw1GlJ5yUlaJBS6FqVkbnKE5ByMj56vUqx2mbcGbhLtcJ+axjlSXWEqcbwcjSojIwTnak6yWm6P NvXC2QpbrSVJbXIjocUgHYgEjYEd/lpErE9b++6C4RYdRfuKnHJrz2q4ow2sIARmO0dtKQe4gbk7 JHjyT88Q2yMnjLhi5EOKlGa40Cp1RShHTPEhKc6U5IGSBk4Ge4VZW7fDZmOzGojCJTyUpdeS2AtY HcCrvIHiz3VldjsvONOOtNrWyrW2pSQShRBGQfEcEj9RNWJ7JHS3OoWBItBbx4Q90Nw5uPj40yO/ 5tPK/q0/NXkqveSLTbmrm5c0QIqJ7qNDkpLKQ6tO2xXjJGw2+YV4NqLM3NlXSx3HwVwlHe8M3Szc +dITz7UjW5I0tsnS4OY3hKNWU7q3cXsnHaqc5C258lDkTo3EuqCo2FDknO6MKJUMd25J23rbt9+n WyOqOx0rjJUVhuVDZkpSogAlIdSoJJAGSMZ0pznAwRbJM242i73tCJq+G7c1dpSXHLSVcx5eoAMI AU3zENgZGdIQFk7FaUq2+C2Y0/i6HfoTFraek30BMF6UyjomeYhWW21FJcUQsoSUp7Og4GopKKfH 4qu0dhbKnIslK31yVGbCZlKLqwkLVqdQo5OlOd98VoM3KVGu7d0jqQ1LafEhtTbSUpQsK1AhAGkA HxYx4sYoLDZplzs8B1Hhd+ywWpTiXZltXqeluYSOWnQ4lLqUY1Z1BKQ4o5ytKVV66S2p93mzI8VE RmQ+t1uO3jSylSiQgYA2AOO4d3dW3A4kuNtgCCyITkYOqeSiVAYkaVqCQoguIURkIT3eQV8Q7/cr fIuD0N5DCrgw5GkhtlASppwgrSE4wkHA+KBjxYoJKw3qXa4CW/CV0s0Nx1xXWWxklyQ4A38Gs8xs KSgbgZJSXDt29paXdZdkv14idVN4dh+FJY51kbKuY4FJHJ1a2gpDY3T3FPMPZGvar2+/T7ZHVHY6 Vxkq1huVDZkpSogAlIdSoJJAGSMZ0pznAx9xeJLpF52XWJXOdU8vrorUr4RXxljmpVhSsDJGCrAz nAwF0nKiWHwlJE+bYJj19nxlGzMB34NrlENBZcaKUJLisAABWxI7CcOC+HTaOLoep22SLlFvogvN vS2kclDbiApxttwhTil5UlJA7OgkDUUlFLi8SXSLzsusSuc6p5fXRWpXwivjLHNSrClYGSMFWBnO BjUZuc2Pd27qiSsz23xJD7h1qLoVq1HVnJzvvnNBPcLTLxEvrVnZvlwgwA+p2b4PnFKUtIGp5xJQ SlRDaFEEas6RjOwqWY4hdVaHbxIu9wsj1yu0t1x2ztlSn1aWVFCwXWyEIK8o7S/4ReycZVR4kyRA eU9Gc0OKacZJwD2HEFCxv5UqI/r2rct9+n2yOqOx0rjJUVhuVDZkpSogAlIdSoJJAGSMZ0pznAwF hktci6flCZ6diNy2nE8hg5bbxPYGlJwOyO4bDYdwql1YY8q7q4cvEoWhclmavlzLw4h5ak/CNuaC vVoBK0oOSCrtd+4qvUCp7hH+OZH9F3D/AAb1QNS3Db85i+NG3W7wlJcaeZ6TlrXzULaUhYwghXxV KOxGMZoFkhx5HVyXm+qVEa5yYKSQp/HeSRg6EgalaTqx3YGpaJrhqXa3LTxU9cYMp15cMOOGLIbj oKDKj9lKOUoJOog5G2BpCR3itvuSYN3ccQyu3SmHyoNNlaFRlpV8UaiVApIxucjHfms0J263CZLi 25hbz9ySUOx4sYEuJCw6QlCR2QC2DhIGAnyUE3wm9aW7DxKJ0Ka84ICStTExDQLfVRwEgFpWFasH VkjG2PHThN60t2HiUToU15wQElamJiGgW+qjgJALSsK1YOrJGNseOoG1i5PuP2+1svPuzmuSthhr mLcQlSXMAAE7FtJ283yZpaxcn3H7fa2Xn3ZzXJWww1zFuISpLmAACdi2k7eb5M0E9wm9aW7DxKJ0 Ka84ICStTExDQLfVRwEgFpWFasHVkjG2PHThN60t2HiUToU15wQElamJiGgW+qjgJALSsK1YOrJG NseOoG1i5PuP2+1svPuzmuSthhrmLcQlSXMAAE7FtJ283yZpaxcn3H7fa2Xn3ZzXJWww1zFuISpL mAACdi2k7eb5M0E9wm9aW7DxKJ0Ka84ICStTExDQLfVRwEgFpWFasHVkjG2PHThN60t2HiUToU15 wQElamJiGgW+qjgJALSsK1YOrJGNseOoG1i5PuP2+1svPuzmuSthhrmLcQlSXMAAE7FtJ283yZpa xcn3H7fa2Xn3ZzXJWww1zFuISpLmAACdi2k7eb5M0E9wm9aW7DxKJ0Ka84ICStTExDQLfVRwEgFp WFasHVkjG2PHWex3HwVwlHe8M3Ozc+dITz7UjW5I0tsnS4OY3hKNWU7q3cXsnHarVrFyfcft9rZe fdnNclbDDXMW4hKkuYAAJ2LaTt5vkzWS336dbI6o7HSuMlRWG5UNmSlKiACUh1KgkkAZIxnSnOcD AWiI50XHnFUIQITBW1dUFLSdYYSliQdDRIACcgbhIOEgDAKgYnguVyZ9wYDDKi/a5wLq0aloSIjx wnOycnGSBnbAIBUDoW7iW6WyXKlsOsuSZWrnPSozUha9QUFdpxKiNQUoKx8bO+aW7iS42qXKkxBC Q7K1BwrgMLACgoKSkKQQhJClApSACDjGMUEvwm9aW7DxKJ0Ka84ICStTExDQLfVRwEgFpWFasHVk jG2PHWvYb1LtcBLfhK6WaG464rrLYyS5IcAb+DWeY2FJQNwMkpLh27e0ZCdutwmS4tuYW8/cklDs eLGBLiQsOkJQkdkAtg4SBgJ8lftvv062R1R2OlcZKisNyobMlKVEAEpDqVBJIAyRjOlOc4GAtkmb cbRd72hE1fDduau0pLjlpKuY8vUAGEAKb5iGwMjOkICyditKVakS+yx10+JLf4ZtD0953Vbch5xS 9JSwkJUgOJbG++kIC1b5WlKoWPxVdo8dbKnIslK31yVGbCZlKLqwkLVqdQo5OlOd98Uj8U3OLHXH Qm3rZW+uRy3rbGdShawkKKAtshAISnZOBsNqCWsd9uEzixxq3XC4WSzypjkyRGt8tTSY7AytwpCc AlDSTjCcnSAAdhWozK91M+6quDDLKpDrtwXNbRpTEUo5VrPepokpTpyVAlOjKiUOQrdylMznpjKk NPPJdQvltJSnS4lSFgJA0pBSpQwAMZ2xgV8dbI6DoQ5iNzecpCQBqXjAKj3qwM4z3alYxqOQlrB/ EvFP9GI/xkaoGp6A5cWOFLoqNYuZDkYYk3TlPHlJC21hvUFcsdpKO9Oe137ioGgsPD16uMYIt8K7 rszOp2RIlxnVNOOpDYOgkKAWQEENpJHacIyNWRE3SW1Pu82ZHioiMyH1utx28aWUqUSEDAGwBx3D u7qxxJkiA8p6M5ocU04yTgHsOIKFjfypUR/XWCgtjE2HC4Bti5NrZuDirpNCEyHXEtpHKi5OG1JU Vd2DqwBqyDkFOSLbYts454itCELdZjMXRhlxbqkuJ5TLpSrKCkEkIwQQUkKUMb7RMK+3m12hthrQ q2qfcWhuTEbeZU9pQFHDiSkrCdG/ekK2xqOVov15iTpciFokS5KHFvuPxG5Tik6VFwkuJUQCkr1H xjOcgUG3F8F27hGFcX7OzPmSJ8ljMh51LYbQ2wodltSSVZcODqAwVZCtinfu9rtHDPWIct/hBs3m bbwp95aHG2mOVhSCghIWeaclSVpylPZ7watJuUqXHDDqkBlL7shLbbSUJStwJCyAkDAIQnYbDGwF b6OK7yh+U/1SFPSX1yVOLjtqU28o5U40SnLSycdpGk9lPmjAZON/+/3Ef9KSf+aqpKxW+0N8MtXK eq0c6RMejhN0MzSEtoaUCjphnOXTq1HxJx/KzGuXlTU+eq9WGFOuTspxyQ5N57TiXCe0kpbcQB2s 7acgk/MAi3+eHnmrZb4SGFanhC6NMttnSjtrQHw4pOUoyog9yRnZIwG97noF3/e1gc1YvvQNyZJU Oa0/tGJAG2OU6VdkHtp2PcnctFztLTHGSodiiuwiwXY6ZS3gsMmZHCGlaHQMAEHI7WR8YjY1qHxB dYEi4yI8xfOuLDkeW44A4p5DhBWCVAnJI7+/5617fcpVrkKeirQCtOhaHWkutuJyDhSFgpUMgHBB wQD3gGglogg23hiLcn7VFuL0uY/HKZTjwS2lpDKgU8paDkl05yT8VOMb53+utsTgmC6qzomIXdp3 IamSFlLaOXF+NyygqX8UZyB8bsnI0wVvv062R1R2OlcZKisNyobMlKVEAEpDqVBJIAyRjOlOc4GN eTc5s1gMypK3kh92Tlw6lF1wJC1FXeSdCe8+L5zQWy82+zcLsSUi0ouLzd7nwELmPuBPJZDOnUlt SCV5WdwQN1ZB7Omt8RW9q0cTXa2x1LUzDmPR21OEFRShZSCcADOB5Kx3C8z7rr62Rzdcp6YrsJTl 13TzFbAd+hO3cMbAVvuXlTU+eq9WGFOuTspxyQ5N57TiXCe0kpbcQkdrO2nIJPzABv8ACdwjRbDx Kl60QpakwEuFb63gVJMqONB0OJGkHtbAHI78bVpxBBtnDEW5P2qLcXpcx+OUynHgltLSGVAp5S0H JLpzkn4qcY3zoN3p6LcnZlvjRYaHU6FRUoLzJTtsUPFeoZAVhWcKAIxgY/bffp1sjqjsdK4yVFYb lQ2ZKUqIAJSHUqCSQBkjGdKc5wMA4it7Vo4nu1tjqWpmHMejtqcIKilCykE4AGcDyVtcJpacucxt xrVqtc4pUHFoU2pMZxYIKVDOdOkg5BCiCK+Lfc+Yt/qbFFvMt1Tkhx+SuSp0gDUsnlupBAAUokgn vJOO5E4llWydJk2uJb4QkI0FrpUyEpTpKVBJf1qAUFK1DO+cHbAAbcXwXbuEYVxfs7M+ZInyWMyH nUthtDbCh2W1JJVlw4OoDBVkK7JT9rbscC0Ce3bVzosy4yozXVPKbeZYbS0pBSUEJDhDxyVBacpT hOMgwUq5SpccR3VIDKX3ZCW22koSlbgSFkBIGAQhOw2GNgKz2+/3K1x1MxHkJQVlxBWyhxTK8Aa2 lKBLa9k9pBB7Kd+yMBaWuFrO9xtxBBXcIUWNEduLbER7qCtKWm3ShepKFApSUgnKsnQdjkA6C3V8 N8ORpFpnsuuyZ8hh+VHQrRIaQ3HUGyHEglGXV6kFOlW2oKCU4hrreXbjxFcruyFxVTn33ShDhylL pVqRqGMjCik+UE7b1jtt5n2jm9C/yuZgnKEq0qGdK06gdK05OlacKTk4IyaC2SOFIFxv9+tcJPQe DLpISlxRU5z2tWluO2Ce0/2FFCM5c1KyoaN9S23eTGjyZMGbK4asypjq0rguLVIdKgnSwDrRzQ2M HKiAkLUScrSlVWXMkOQGYKnMxmXVvIRgbLWEBRz37htH0fOamvdTfkx3ZDyYr7MqY9ILkq2MPJU+ oILpSVtkA45eQnAHZ2oJqMzYpdvkX9+PZYnhC6SkNRbgZfLZbSG1pS10oHdziDq2wE6QN6hWLfah d7vMbUuTYrepwsKdJSZOVFLCCcJOVHClAaVaEOEYKa1IvEdxic4NiEtt11TxafgMPNoWrvKELQUt 5wAdIGQlI/kjGpKuc2awGZUlbyQ+7Jy4dSi64Ehaio7knQnvPi+c0FhcvM+NYG74y/ouV0uksTng hPw6UpYXoUnGkoKnVlSMaVZGoHSnG/I4UgXG/wB+tcJPQeDLpISlxRU5z2tWluO2Ce0/2FFCM5c1 KyoaN6nbbzPtHN6F/lczBOUJVpUM6Vp1A6VpydK04UnJwRk1rrmSFwGYKnMxmXVvIRgbLWEBRz37 htH0fOaC021mzuR5Nyet9oiRJMx1EVN0kTHEpSkJVy0dONWUhxOpTh7WpOkAhWZN3h6xWPwjz3LW vl3mZAa8MGWfg2OXpKelA7R5h1attk6QN6qyOK7yh+U/1SFPSX1yVOLjtqU28o5U40SnLSycdpGk 9lPmjGSNxHfHpctaQzNdkuuzHUPwGZICyCpxxKVoUEbJyopA2SM7JGAjLo3Cau81u2vLegIfWmM6 4MKW0FHSo7DcjB7h+oVqVkffdlSHJEh1brzqitxxxRUpaickkncknx1joFKyKYdTHRIU0sMrUpCX Ck6VKSAVAHuJAUnI8WoeWsdApSlApWR9h2LIcjyGltPNKKHG3ElKkKBwQQdwQfFWOgUpSgUpSgV0 9n/RRYf5y4/9KuYV09n/AEUWH+cuP/Sqj1hSlKgUpSgUpSgUpSgUpSgUpSgUpSgUpSgUpSgUpSgU pSgUpSgUpSgUpSgUpSgUpSgUpSgUpSgUpSgUpSgUpSgUpSgUpSgUpSgUpSgUpSgUpSgV4Ar3/XgC gVdLHcfBXCUd7wzdLNz50hPPtSNbkjS2ydLg5jeEo1ZTurdxeycdqnvuJekOOIZQylaioNNlRSgE /FGok4HduSfnNb9vv062R1R2OlcZKisNyobMlKVEAEpDqVBJIAyRjOlOc4GAtkmbcbRd72hE1fDd uau0pLjlpKuY8vUAGEAKb5iGwMjOkICyditKVbfBbMafxdDv0Ji1tPSb6AmC9KZR0TPMQrLbaiku KIWUJKU9nQcDUUlFPj8VXaOwtlTkWSlb65KjNhMylF1YSFq1OoUcnSnO++K0GblKjXdu6MKQ1Laf EhtTbSUpQsK1AhAGkAHxYx4sYoLDZplzs8B1Hhd+ywWpTiXZltXqeluYSOWnQ4lLqUY1Z1BKQ4o5 ytKVV66S2p93mzI8VERmQ+t1uO3jSylSiQgYA2AOO4d3dW3A4kuNtgCCyITkYOqeSiVAYkaVqCQo guIURkIT3eQV8Q7/AHK3yLg9DeQwq4MORpIbZQEqacIK0hOMJBwPigY8WKCSsN6l2uAlvwldLNDc dcV1lsZJckOAN/BrPMbCkoG4GSUlw7dvaWl3WXZL9eInVTeHYfhSWOdZGyrmOBSRydWtoKQ2N09x TzD2Rr2q9vv0+2R1R2OlcZKtYblQ2ZKUqIAJSHUqCSQBkjGdKc5wMfcXiS6Redl1iVznVPL66K1K +EV8ZY5qVYUrAyRgqwM5wMBdJyolh8JSRPm2CY9fZ8ZRszAd+Da5RDQWXGilCS4rAAAVsSOwnGhG u3uZt8jhp7iG9WmbAukrnLtLett/ZtsZJdbOxaVjI7leLeq1F4kukXnZdYlc51Ty+uitSvhFfGWO alWFKwMkYKsDOcDCLxJdIvOy6xK5zqnl9dFalfCK+Msc1KsKVgZIwVYGc4GAnUXC7cPT58Cfebnb dE+SiRcrYha3JkhJQlSVqLjetKd1DJyC4Tjt7S85USw+EpInzbBMevs+Mo2ZgO/BtcohoLLjRShJ cVgAAK2JHYTilxeJLpF52XWJXOdU8vrorUr4RXxljmpVhSsDJGCrAznAwi8SXSLzsusSuc6p5fXR WpXwivjLHNSrClYGSMFWBnOBgJOJb3bQjja2vqQp6JD5DimySkqROjpJGQNsjyVVquXA0D3Z8Tt8 OynlsvXVT637ilxxTy8NqcCVgq0rRzEJWQRqJHxhtiF4n4YunCN8etN2Y5chvdKk7odQe5aD40nH 9hBwQQAh6nuEf45kf0XcP8G9UDW/Z7ouz3ETER2ZHwTrKmn9WhaHG1NqB0lJ+Ks9xFBnskOPI6uS 831SojXOTBSSFP47ySMHQkDUrSdWO7A1LRNcNS7W5aeKnrjBlOvLhhxwxZDcdBQZUfspRylBJ1EH I2wNISO8Vfq1tz+siDo3Eu81oMLUOSc5GkklQx4iSTt319i5SkmcUKQ2JydEhLbSUpUnmJcwEgYS NSEnCcYxju2oLFwm9aW7DxKJ0Ka84ICStTExDQLfVRwEgFpWFasHVkjG2PHThN60t2HiUToU15wQ ElamJiGgW+qjgJALSsK1YOrJGNseOqzHmSIrMpllzS3KaDLwwDqQFpWBv3dpCTt5P10jzJEVmUyy 5pblNBl4YB1IC0rA37u0hJ28n66CzcJvWluw8SidCmvOCAkrUxMQ0C31UcBIBaVhWrB1ZIxtjx04 TetLdh4lE6FNecEBJWpiYhoFvqo4CQC0rCtWDqyRjbHjqsx5kiKzKZZc0tymgy8MA6kBaVgb93aQ k7eT9dI8yRFZlMsuaW5TQZeGAdSAtKwN+7tISdvJ+ugs3Cb1pbsPEonQprzggJK1MTENAt9VHASA WlYVqwdWSMbY8dOE3rS3YeJROhTXnBASVqYmIaBb6qOAkAtKwrVg6skY2x46rMeZIisymWXNLcpo MvDAOpAWlYG/d2kJO3k/XSPMkRWZTLLmluU0GXhgHUgLSsDfu7SEnbyfroLNwm9aW7DxKJ0Ka84I CStTExDQLfVRwEgFpWFasHVkjG2PHWex3HwVwlHe8M3Ozc+dITz7UjW5I0tsnS4OY3hKNWU7q3cX snHaqUeZIisymWXNLcpoMvDAOpAWlYG/d2kJO3k/XW5b79OtkdUdjpXGSorDcqGzJSlRABKQ6lQS SAMkYzpTnOBgLREc6LjziqEIEJgrauqClpOsMJSxIOhokABOQNwkHCQBgFQMTwXK5M+4MBhlRftc 4F1aNS0JER44TnZOTjJAztgEAqB0LdxLdLZLlS2HWXJMrVznpUZqQteoKCu04lRGoKUFY+NnfNLd xJcbVLlSYghIdlag4VwGFgBQUFJSFIIQkhSgUpABBxjGKCX4TetLdh4lE6FNecEBJWpiYhoFvqo4 CQC0rCtWDqyRjbHjrXsN6l2uAlvwldLNDcdcV1lsZJckOAN/BrPMbCkoG4GSUlw7dvaFFylJM4oU hsTk6JCW2kpSpPMS5gJAwkakJOE4xjHdtWxb79OtkdUdjpXGSorDcqGzJSlRABKQ6lQSSAMkYzpT nOBgLvOVEsPhKSJ82wTHr7PjKNmYDvwbXKIaCy40UoSXFYAACtiR2E4hZbc3g60cuM8huf4WmwZj rQ1JeQwlnDZ1DtNkuLJSRheRqB0jELF4kukXnZdYlc51Ty+uitSvhFfGWOalWFKwMkYKsDOcDHxE 4gusKRJkMzFl6SvmOuOgOKLmSQ6CoEpcBKsODChqOCMmgucyxWC0v3VxwWhCRe5sFlq6KmlKGmS3 p0dPvn4QhRWT3Jx/KzXWYltmz7pa4p1Wxl11+LdFo0qZbBwlTpwCpChoBTjUFEaAVEtuR1vv062R 1R2OlcZKtYblQ2ZKUqIAJSHUqCSQBkjGdKc5wMa71zmyY7jL0lbiHXzJdKjlTrpGNS1d6iMnGSca lYxqVkJOwfxNxT/RaP8AGRqgakol4MKzT7e3BilU1IbclKLnNCAtC9AGrRjU2k5KSdzvUbQWHh69 XGMEW+Fd12ZnU7IkS4zqmnHUhsHQSFALICCG0kjtOEZGrIibpLan3ebMjxURGZD63W47eNLKVKJC BgDYA47h3d1Y4kyRAeU9Gc0OKacZJwD2HEFCxv5UqI/rrBQWxibDhcA2xcm1s3BxV0mhCZDriW0j lRcnDakqKu7B1YA1ZByCnJFtsW2cc8RWhCFusxmLowy4t1SXE8pl0pVlBSCSEYIIKSFKGN9oWBxJ dLbAEBh1lcMOqe6eRGafb5igkFelxKhqwkAHvA1YxqVlbuJbpbJcqWw6y5Jlauc9KjNSFr1BQV2n EqI1BSgrHxs75oN+L4Lt3CMK4v2dmfMkT5LGZDzqWw2hthQ7Lakkqy4cHUBgqyFbFO/d7XaOGesQ 5b/CDZvM23hT7y0ONtMcrCkFBCQs805KkrTlKez3g1aVcpUuOI7qkBlL7shLbbSUJStwJCyAkDAI QnYbDGwFb6OK7yh+U/1SFPSX1yVOLjtqU28o5U40SnLSycdpGk9lPmjAZON/+/3Ef9KSf+aqvzhN LTlzmNuNatVrnFKg4tCm1JjOLBBSoZzp0kHIIUQRXwjiBtyRKlXKzW+5y5T633ZElT6FFSjkgBpx CcZye7x+TGETiWVbJ0mTa4lvhCQjQWulTISlOkpUEl/WoBQUrUM75wdsABtxfBdu4RhXF+zsz5ki fJYzIedS2G0NsKHZbUklWXDg6gMFWQrYpmoog8PSeO7Um1RZzUFC20Oylu63EJmsICFctaRjuVkA HI78bVS5VylS44juqQGUvuyEtttJQlK3AkLICQMAhCdhsMbAVnRf7ki7yroXkLlS1LXI5rKFtvFS tR1NqBQoasKwRgEAjBAwE9YrfaG+GWrlPVaOdImPRwm6GZpCW0NKBR0wznLp1aj4k4/lZS2+HrTa OsiW1F1Q7dpsaM9MedSlUdtLJQVJQUHX285yO9WUnbTBW+/TrZHVHY6VxkqKw3KhsyUpUQASkOpU EkgDJGM6U5zgY15VzmzWAzKkreSH3ZOXDqUXXAkLUVHck6E958XzmgnVt2OBaBPbtq50WZcZUZrq nlNvMsNpaUgpKCEhwh45KgtOUpwnGQZfiwQbZd7zcn7VFuL0viC4xymU48lLaWlNqBTylo3JdOck /FTjG+alb7/crXHUzEeQlBWXEFbKHFMrwBraUoEtr2T2kEHsp37IxsI4quyX5TzjkWQqU+uS4JUJ l9PNWcrUlLiCEFW2dIGdKc9wwFsVw7Zrc7Ngqt6JRZuN3bS++64HNENhDraewpKcKOQo6c4UdJSc EYHLPaLd++ZES0Mx5aWXGlXR6YpAUuMy8ttpMftAJLw3cJyCgA5SsmpJ4guqQQZi1kqkrUpwBalK kNht4lRBJKkgDJ/WMHethriu8tDCZSCUpbS2pcdtSmdDaW0qaUUktrCUIGtGFHQkkkgGglotti2z jniK0ISt1mMxdGGXFuqS4nlMulKsoKQSQjBBBSQpQxvtqRfBdu4RhXF+zsz5kifJYzIedS2G0NsK HZbUklWXDg6gMFWQrYp1IvFV2h3KdcW3Iq5c5S1SHXoTLpUV6teNaCEhQWoEJwCDg7VoSrlKlxxH dUgMpfdkJbbaShKVuBIWQEgYBCE7DYY2AoNjiK3tWjia7W2OpamYcx6O2pwgqKULKQTgAZwPJU7Y rfaG+GWrlPVaOdImPRwm6GZpCW0NKBR0wznLp1aj4k4/lZiUcQNuSJUq5Wa33OXKfXIdkSVPoUVK OSAGnEJAzk93j8mMG+JpUZbqYcS3sRVq1piORUSmmlYAJQJHMKSrSMkHfA8QAASXuegXf97WBzVi +9A3JklQ5rT+0YkAbY5TpV2Qe2nY9ydy0XO0tMcZKh2KK7CLBdjplLeCwyZkcIaVodAwAQcjtZHx iNjWofEF1gSLhIjzF864sOR5bjgDinkOEFYJUCckjv7/AJ617fcpVrkKeirQCtOhaHWkutuJyDhS FgpUMgHBBwQD3gGglogg23hiLcn7VFuL0uY/HKZTjwS2lpDKgU8paDkl05yT8VOMb53+utsTgmC6 qzomIXdp3IamSFlLaOXF+NyygqX8UZyB8bsnI0wVvv062R1R2OlcZKisNyobMlKVEAEpDqVBJIAy RjOlOc4GNeTc5s1gMypK3kh92Tlw6lF1wJC1FR3JOhPefF85oLZebfZuF2JKRaUXF5u9z4CFzH3A nkshnTqS2pBK8rO4IG6sg9nTW+Ire1aOJrtbY6lqZhzHo7anCCopQspBOABnA8lY7heZ9119bI5u uU9MV2Epy67p5itgO/QnbuGNgK20cQNuSJUq5Wa33OXKfW+7IkqfQoqUckANOITjOT3ePyYwEnwn cI0Ww8SpetEKWpMBLhW+t4FSTKjjQdDiRpB7WwByO/G1acQQbZwxFuT9qi3F6XMfjlMpx4JbS0hl QKeUtByS6c5J+KnGN86Dd6ei3J2Zb40WGh1OhUVKC8yU7bFDxXqGQFYVnCgCMYGP2336dbI6o7HS uMlRWG5UNmSlKiACUh1KgkkAZIxnSnOcDAOIre1aOJ7tbY6lqZhzHo7anCCopQspBOABnA8lbXCa WnLnMbca1arXOKVBxaFNqTGcWCClQznTpIOQQogisEW9Mt85c+zwrpJedU6uTNdkcwk9+Sh1IO+T kgnJO9ZInEsq2TpMm1xLfCEhGgtdKmQlKdJSoJL+tQCgpWoZ3zg7YADbi+C7dwjCuL9nZnzJE+Sx mQ86lsNobYUOy2pJKsuHB1AYKshXZKftbdjgWgT27audFmXGVGa6p5TbzLDaWlIKSghIcIeOSoLT lKcJxkGClXKVLjiO6pAZS+7IS220lCUrcCQsgJAwCEJ2GwxsBWe33+5WuOpmI8hKCsuIK2UOKZXg DW0pQJbXsntIIPZTv2RgLjxH4LsECRETZ2ZjTHEd0YjtSHnQ202kRx/IUlalYCQCVYxqyCSCNdVj tVln3ZmU1azGZukiFHkXh2UeYGiAQlMUAhQCklRVsdSdIGFZrV+v8i+T5byk8qM/PkTm4+QrlreK SrtYBOyED/y9wyayI4rvKH5T/VIU9JfXJU4uO2pTbyjlTjRKctLJx2kaT2U+aMBO3m32bhdiSkWl Fxebvc+Ahcx9wJ5LIZ06ktqQSvKzuCBurIPZ0/F3tdo4Z6xDlv8ACDZvM23hT7y0ONtMcrCkFBCQ s805KkrTlKez3g1q4XmfddfWyObrlPTFdhKcuu6eYrYDv0J27hjYCttHFd5Q/Kf6pCnpL65KnFx2 1KbeUcqcaJTlpZOO0jSeynzRgLK6+61+VTjBDbq0IeTeUOJSogLTyn1YPlGUpOPKAfFWhYrfaG+G WrlPVaOdImPRwm6GZpCW0NKBR0wznLp1aj4k4/lZiYvFV2h3KdcW3Iq5c5S1SHXoTLpUV6teNaCE hQWoEJwCDg7Vji8SXGJzg2IS23XVPFp+Aw62hau8oQtBS3nAB0gZCUj+SMBNS2+HrTaOsiW1F1Q7 dpsaM9MedSlUdtLJQVJQUHX285yO9WUnbTj4fsdkvF3n4ubLENDU1UaPND3P0IYcW24otIKeyQFE A76ThJyAa9Kuc2awGZUlbyQ+7Jy4dSi64Ehaio7knQnvPi+c1gZfdjrK2XVtqKVIKkKKSUqBSobe IgkEeMEigtC3V8N8ORpFpnsuuyZ8hh+VHQrRIaQ3HUGyHEglGXV6kFOlW2oKCU435HCkC43+/WuE noPBl0kJS4oqc57WrS3HbBPaf7CihGcualZUNG9Ttt5n2jm9C/yuZgnKEq0qGdK06gdK05OlacKT k4Iya11zJC4DMFTmYzLq3kIwNlrCAo579w2j6PnNBZbff3IfPMSTdOHLU/KfcadtiVOOLPY0srWX G9aW0kEEnIKycdva88RtcjhVpnp2I3LuV4TyI5y21hxA0pOB2R3DYbeIVzRHFV2S/KecciyFSn1y XBKhMvp5qzlakpcQQgq2zpAzpTnuGLyX3ZP5MLLIfdW6869cluOOKKlLUS2SSTuST46o9WUpSoFK UoFKUoFKUoFKUoFKUoFKUoFKUoFKUoFKUoFKUoFKUoFKUoFKUoFKUoFKUoFKUoFKUoFKUoFKUoFK UoFKUoFKUoFKUoFKUoFKUoFKUoFeAK9/14AoLhdLZCZ424pkPxkJtdsmSMMIGhC18xSWWRjGxO5S CDy0OFJymsbl5nxrA3fGX9Fyul0lic8EJ+HSlLC9Ck40lBU6sqRjSrI1A6U4r0p2aywLVKC20RH3 VchxGlTbqglK87Zz8GkYPdj9dZLbeZ9o5vQv8rmYJyhKtKhnStOoHStOTpWnCk5OCMmgtkjhSBcb /frXCT0Hgy6SEpcUVOc9rVpbjtgntP8AYUUIzlzUrKho30OHLvOc4l6O13K6WayvSlyn48KctPIj pytwg/ylJaQd8EnSNidqrS5khcBmCpzMZl1byEYGy1hAUc9+4bR9HzmthV5nrusq6KfzMl87nOaE 9rnJUlzbGBkLV3DbO2KCwy77NbtHugjKRGn3e7TTMLScpcQEsrDRCs5by6vKDkK21atIxC8Uwo9t 4uvUGI3y40ae+y0jJOlCXFADJ3OwHfWC23mfaOb0T/K5mCcoSrSoZ0rTqB0rTk6VpwpOTgjJrQoF KUoFKUoFKUoL3+Rp9mL+VWzyJDqGWGkSVuOOKCUoSI7hJJOwAHjrpH5X+MuHeJuA7fNi2hdyjPyJ DMe4Jd5S4TyCAAoaVbOJ7WhWklIBwDgp4O3a7g7bXbk3AlLgMr0OSksqLSFbbFeMA9pOxPjHlqd4 f4khxOF79w9d2n3oU1oPxOUkKVHmIPYWNRwlKgSlZAKinAFBV6UrPDhS7jLREgxXpUlzOhlhsrWr AycJG52BP9VBgpWR9h2LIcjyGltPNKKHG3ElKkKBwQQdwQfFX3DhS7jLREgxXpUlzOhlhsrWrAyc JG52BP8AVQYKVnhwpdxloiQYr0qS5nQyw2VrVgZOEjc7An+qkOFLuMtESDFelSXM6GWGytasDJwk bnYE/wBVBgpWeHCl3GWiJBivSpLmdDLDZWtWBk4SNzsCf6qQ4Uu4y0RIMV6VJczoZYbK1qwMnCRu dgT/AFUGClZ4cKXcZaIkGK9KkuZ0MsNla1YGThI3OwJ/qpDhS7jLREgxXpUlzOhlhsrWrAycJG52 BP8AVQYKVnhwpdxloiQYr0qS5nQyw2VrVgZOEjc7An+qsFApSlApWeHCl3GWiJBivSpLmdDLDZWt WBk4SNzsCf6qQ4Uu4y0RIMV6VJczoZYbK1qwMnCRudgT/VQYKUpQKUpQKVtt2u4O2125NwZS4DK9 DkpLKi0hW2xXjAPaTsT4x5a1KBSlKBSsimHUx0SFNLDK1KQlwpOlSkgFQB7iQFJyPFqHlrHQKUrI yw7IWUMtLcUEqWUoSVEJSCpR28QAJJ8QBNBjpWeHCl3GWiJBivSpLmdDLDZWtWBk4SNzsCf6qwUC lKUClKUClKUClKUClKUClKUClKUClZ4cKXcZaIkGK9KkuZ0MsNla1YGThI3OwJ/qrBQKUpQKUpQK UpQKUpQKUpQKUpQKUpQKUpQKUpQK6ez/AKKLD/OXH/pVzCuns/6KLD/OXH/pVYR6wpSlRSlKUClK UClKUClKUClKUClKUClKUClKUClKUClKUClKUClKUClKUClKUClKUClKUClKUClKUClKUClKUClK UClKUClKUClKUClKUClKUCvAFe/68AUCrpY7j4K4SjveGbpZufOkJ59qRrckaW2TpcHMbwlGrKd1 buL2TjtVOchbc+ShyJ0biXVBUbChyTndGFEqGO7ck7b1t2+/TrZHVHY6VxkqKw3KhsyUpUQASkOp UEkgDJGM6U5zgYC2SZtxtF3vaETV8N25q7SkuOWkq5jy9QAYQApvmIbAyM6QgLJ2K0pVt8Fsxp/F 0O/QmLW09JvoCYL0plHRM8xCsttqKS4ohZQkpT2dBwNRSUU+PxVdo7C2VORZKVvrkqM2EzKUXVhI WrU6hRydKc774rQZuUqNd27pHUhqW0+JDam2kpShYVqBCANIAPixjxYxQWGzTLnZ4DqPC79lgtSn EuzLavU9LcwkctOhxKXUoxqzqCUhxRzlaUqr10ltT7vNmR4qIjMh9brcdvGllKlEhAwBsAcdw7u6 tuBxJcbbAEFkQnIwdU8lEqAxI0rUEhRBcQojIQnu8gr4h3+5W+RcHobyGFXBhyNJDbKAlTThBWkJ xhIOB8UDHixQSVhvUu1wEt+ErpZobjriustjJLkhwBv4NZ5jYUlA3AySkuHbt7S0u6y7JfrxE6qb w7D8KSxzrI2VcxwKSOTq1tBSGxunuKeYeyNe1Xt9+n2yOqOx0rjJVrDcqGzJSlRABKQ6lQSSAMkY zpTnOBj7i8SXSLzsusSuc6p5fXRWpXwivjLHNSrClYGSMFWBnOBgLpOVEsPhKSJ82wTHr7PjKNmY DvwbXKIaCy40UoSXFYAACtiR2E41GIzPCNodQ/ebha7km7S4L0q1MBxTqWUs9nWXG1JRqWo4Hxsj UOwnFWi8SXSLzsusSuc6p5fXRWpXwivjLHNSrClYGSMFWBnOBhF4kukXnZdYlc51Ty+uitSvhFfG WOalWFKwMkYKsDOcDATsQ3bhjroDl4fs0WFPeYfmW0r50t1OlPLSNSOYlGnVuUhAcVk5WlKtxi52 5i0O3uPNuHDr1xu0sJFqjpcUllKWVpa1cxspQkunZOytsjsJxWo/FV2jsLZU5FkpW+uSozYTMpRd WEhatTqFHJ0pzvviscXiS4xOcGxCW266p4tPwGHW0LV3lCFoKW84AOkDISkfyRgJOJb3bQjjW2yF IU9Eh8hxTZJSVInR0kjIG2R5Kq1WGPKu6uHLxKFoXJZmr5cy8OIeWpPwjbmgr1aAStKDkgq7XfuK r1Aqe4R/jmR/Rdw/wb1QNS3Db85i+NG3W7wlJcaeZ6TlrXzULaUhYwghXxVKOxGMZoFkhx5HVyXm +qVEa5yYKSQp/HeSRg6EgalaTqx3YGpaJrhqXa3LTxU9cYMp15cMOOGLIbjoKDKj9lKOUoJOog5G 2BpCR3itvuSYN3ccQyu3SmHyoNNlaFRlpV8UaiVApIxucjHfms0J263CZLi25hbz9ySUOx4sYEuJ Cw6QlCR2QC2DhIGAnyUE3wm9aW7DxKJ0Ka84ICStTExDQLfVRwEgFpWFasHVkjG2PHThN60t2HiU ToU15wQElamJiGgW+qjgJALSsK1YOrJGNseOoG1i5PuP2+1svPuzmuSthhrmLcQlSXMAAE7FtJ28 3yZpaxcn3H7fa2Xn3ZzXJWww1zFuISpLmAACdi2k7eb5M0E9wm9aW7DxKJ0Ka84ICStTExDQLfVR wEgFpWFasHVkjG2PHThN60t2HiUToU15wQElamJiGgW+qjgJALSsK1YOrJGNseOoG1i5PuP2+1sv PuzmuSthhrmLcQlSXMAAE7FtJ283yZpaxcn3H7fa2Xn3ZzXJWww1zFuISpLmAACdi2k7eb5M0E9w m9aW7DxKJ0Ka84ICStTExDQLfVRwEgFpWFasHVkjG2PHThN60t2HiUToU15wQElamJiGgW+qjgJA LSsK1YOrJGNseOoG1i5PuP2+1svPuzmuSthhrmLcQlSXMAAE7FtJ283yZpaxcn3H7fa2Xn3ZzXJW ww1zFuISpLmAACdi2k7eb5M0E9wm9aW7DxKJ0Ka84ICStTExDQLfVRwEgFpWFasHVkjG2PHWex3H wVwlHe8M3Ozc+dITz7UjW5I0tsnS4OY3hKNWU7q3cXsnHarVrFyfcft9rZefdnNclbDDXMW4hKku YAAJ2LaTt5vkzWS336dbI6o7HSuMlRWG5UNmSlKiACUh1KgkkAZIxnSnOcDAWiI50XHnFUIQITBW 1dUFLSdYYSliQdDRIACcgbhIOEgDAKgYnguVyZ9wYDDKi/a5wLq0aloSIjxwnOycnGSBnbAIBUDo W7iW6WyXKlsOsuSZWrnPSozUha9QUFdpxKiNQUoKx8bO+aW7iS42qXKkxBCQ7K1BwrgMLACgoKSk KQQhJClApSACDjGMUEvwm9aW7DxKJ0Ka84ICStTExDQLfVRwEgFpWFasHVkjG2PHThN60t2HiUTo U15wQElamJiGgW+qjgJALSsK1YOrJGNseOoSE7dbhMlxbcwt5+5JKHY8WMCXEhYdIShI7IBbBwkD AT5K1I8yRFZlMsuaW5TQZeGAdSAtKwN+7tISdvJ+ugnosyRZeEYU63uciTLnyWJCwAea022wUtqB yCgl1epB7KttQOlOJO/QbTw2/cHG7NFmpVe50FtqW69pZaYLejTy3Ekk80glRV8VOMb5q1tvM+0c 3on+VzME5QlWlQzpWnUDpWnJ0rThScnBGTWS336dbI6o7HSuMlWsNyobMlKVEAEpDqVBJIAyRjOl Oc4GAlrRe3rbHUiPPu9itjj7y25VvQVvPKw3hpxYW0lYQk5+YuE47e2efDal8TcQ2mRCiwm48yS8 JEcDlwcLKSFK0p1M5CUgY1AlOhOSW3Iy03e/vy1xITXhOTKdU9yX4Lc5anCMrWlLiFkKIGVEbnSM 5wMRr1zmyY7jL0lbiHXzJdKjlTrpGNS1d6iMnGScalYxqVkJOwfxLxT/AEYj/GRqganoDlxY4Uui o1i5kORhiTdOU8eUkLbWG9QVyx2ko7057XfuKgaCw8PXq4xgi3wruuzM6nZEiXGdU046kNg6CQoB ZAQQ2kkdpwjI1ZETdJbU+7zZkeKiIzIfW63HbxpZSpRIQMAbAHHcO7urHEmSIDynozmhxTTjJOAe w4goWN/KlRH9dYKC2MTYcLgG2Lk2tm4OKuk0ITIdcS2kcqLk4bUlRV3YOrAGrIOQU7Fvi+A+PeI7 TDffEZmLdoh1L3cbQw9gLxgHdCT3YyAfFURZLvfuW3ZrU31ja3VvIgmE3KCnCkalhtSFZUEoG+Mg asY1Kzgt3Et0tkuVLYdZckytXOelRmpC16goK7TiVEagpQVj42d80E9b4ceRwDCkvN9UqJPnPJgp JCn8NRckkYOhIGpWk6sd2BqWiI4TS05c5jbjWrVa5xSoOLQptSYziwQUqGc6dJByCFEEVorvM9XJ 0v8AJ5EpctnkIS1ynV6NSk6QNP8ABowBsMbAVnt3ElxtUuVJiCEh2Vq5hXAYWAFBQUlIUghCSFKB SkAEHGMYoJfhN60t2HiUToU15wQElamJiGgW+qjgJALSsK1YOrJGNseOqlW2LlKSZxQpDYnJ0SEt tJSlSeYlzASBhI1IScJxjGO7ati33SJCjqbkWK3z1FRUHZK5CVAYHZHLdQMbZ7s7negsHD1ttb/D 0Z2VbGZD7ztxWXluOhQTFitvoQAlYGlSioK2zhRwUnBG45Z7Rbv3zIiWhmPLSy40q6PTFIClxmXl ttJj9oBJeG7hOQUAHKVk1ZziGWFBMJtmDGTz+XGYBUhHOaS07guFSjqSkd6jjxYrI1xXeWhhMpBK UtpbUuO2pTOhtLaVNKKSW1hKEDWjCjoSSSQDQTt5t9m4XYkgWlFxebvc+Ahcx9wJ5LIZ06ktqQSv KzuCBurIPZ0/sThK0ni6+W167RW2YK7g00zJ5xdIaacKHSW2ynAKQojOTpPZOQDoSeL7zHjvQZLS BLNxky5gmRm3ErecDYOplxBSlaS2rfGRrUBgZzXjOlmW7LMp8yXtfNeLh1r1ghepXedQUQc9+Tnv oLIt1fDfDkaRaZ7LrsmfIYflR0K0SGkNx1BshxIJRl1epBTpVtqCglON+RwpAuN/v1rhJ6DwZdJC UuKKnOe1q0tx2wT2n+wooRnLmpWVDRvV7fcrrZo6pENa2WX1FKXFNBSeYgA6kFQIS4gLGFpwpOvY jVvprmSFwGYKnMxmXVvIRgbLWEBRz37htH0fOaCy8Mz45v15EO3sx2JUC4FtKyXVx2+lfUG0qV/5 QVY1HTjIClA7FkkRLRwjHni73O0zJU+QyqRbY4cccbbbZIQVF1spSC4o4GQokZ+InELF4qu0O5Tr i25FXLnKWqQ69CZdKivVrxrQQkKC1AhOAQcHascXiO4xOcGxCW266p4tPwGHm0LPeUIWgpbzgA6Q MhKR/JGAtLEZnhG0OofvNwtdyTdpcF6VamA4p1LKWezrLjako1LUcD42RqHYTiBYsSbbd7um7JQ7 HsynG3ghSgh98KKG2wdiQpY1EApVy0OEYIrUi8SXSLzsusSuc6p5fXRWpXwivjLHNSrClYGSMFWB nOBjUlXObNYDMqSt5Ifdk5cOpRdcCQtRUdyToT3nxfOaCwuXmfGsDd8Zf0XK6XSWJzwQn4dKUsL0 KTjSUFTqypGNKsjUDpTjfkcKQLjf79a4Seg8GXSQlLiipzntatLcdsE9p/sKKEZy5qVlQ0b1eJcr rw/Ikx2VrivBWl1t1oam3EEgKAUMocSSrCxhScnBGTWmuZIXAZgqczGZdW8hGBstYQFHPfuG0fR8 5oLLwzPjm/XkQ7ezHYlQLgW0rJdXHb6V9QbSpX/lBVjUdOMgKUD8cP8AELVutBhi73eyvB9bq5Nr bClSUqSgJQv4VvAQUqKd1fwqth49CLxVdodynXFtyKuXOUtUh16Ey6VFerXjWghIUFqBCcAg4O1a 8S/ToMiS/G6Vp6QrWXExGtTSskgtHTlognYt6cYGO4YC6OCyQrx+USM9bZRSyt5ITFlIYQGROYCU JSWlaSDg53GBjSO+uc1njzJEVmUyy5pblNBl4YB1IC0rA37u0hJ28n66+H2HYshyPIaW080oocbc SUqQoHBBB3BB8VBjpSlApSlApSlApSlApSlApSlApSlApSlApSlArp7P+iiw/wA5cf8ApVzCuns/ 6KLD/OXH/pUHrClKUClKUClKUClKUClKUClKUClKUClKUClKUClKUClKUClKUClKUClKUClKUClK UClKUClKUClKUClKUClKUClKUClKUClKUClKUClKUClKUCvAFe/68AUCrpY7j4K4SjveGbpZufOk J59qRrckaW2TpcHMbwlGrKd1buL2TjtVOchbc+ShyJ0biXVBUbChyTndGFEqGO7ck7b1t2+/TrZH VHY6VxkqKw3KhsyUpUQASkOpUEkgDJGM6U5zgYC2SZtxtF3vaETV8N25q7SkuOWkq5jy9QAYQApv mIbAyM6QgLJ2K0pVt8Fsxp/F0O/QmLW09JvoCYL0plHRM8xCsttqKS4ohZQkpT2dBwNRSUU+PxVd o7C2VORZKVvrkqM2EzKUXVhIWrU6hRydKc774rQZuUqNd27pHUhqW0+JDam2kpShYVqBCANIAPix jxYxQWGzTLnZ4DqPC79lgtSnEuzLavU9LcwkctOhxKXUoxqzqCUhxRzlaUqr10ltT7vNmR4qIjMh 9brcdvGllKlEhAwBsAcdw7u6tuBxJcbbAEFkQnIwdU8lEqAxI0rUEhRBcQojIQnu8gr4h3+5W+Rc HobyGFXBhyNJDbKAlTThBWkJxhIOB8UDHixQSVhvUu1wEt+ErpZobjriustjJLkhwBv4NZ5jYUlA 3AySkuHbt7S0u6y7JfrxE6qbw7D8KSxzrI2VcxwKSOTq1tBSGxunuKeYeyNe1Xt9+n2yOqOx0rjJ VrDcqGzJSlRABKQ6lQSSAMkYzpTnOBj7i8SXSLzsusSuc6p5fXRWpXwivjLHNSrClYGSMFWBnOBg LpOVEsPhKSJ82wTHr7PjKNmYDvwbXKIaCy40UoSXFYAACtiR2E41GIzPCNodQ/ebha7km7S4L0q1 MBxTqWUs9nWXG1JRqWo4HxsjUOwnFWi8SXSLzsusSuc6p5fXRWpXwivjLHNSrClYGSMFWBnOBhF4 kukXnZdYlc51Ty+uitSvhFfGWOalWFKwMkYKsDOcDAWljncJ2h2HIvdwtDzV2lxXJFnSVqkqaSyC leXGuwkqyjdWeYvZP8rHEc6LjziqEIEJgrauqClpOsMJSxIOhokABOQNwkHCQBgFQNai8SXSLzsu sSuc6p5fXRWpXwivjLHNSrClYGSMFWBnOBhbuJbpbJcqWw6y5Jlauc9KjNSFr1BQV2nEqI1BSgrH xs75oNiwfxNxT/RaP8ZGqBqwx5Nz9zl4kNWJC4sxfLlXNuO4lLQ5jbnLGkhpA1JRtpz2sDYgVXqB U9wj/HMj+i7h/g3qgaluG35zF8aNut3hKS408z0nLWvmoW0pCxhBCviqUdiMYzQLJDjyOrkvN9Uq I1zkwUkhT+O8kjB0JA1K0nVjuwNS0TXDUu1uWnip64wZTry4YccMWQ3HQUGVH7KUcpQSdRByNsDS EjvFbfckwbu44hldulMPlQabK0KjLSr4o1EqBSRjc5GO/NZoTt1uEyXFtzC3n7kkodjxYwJcSFh0 hKEjsgFsHCQMBPkoJvhN60t2HiUToU15wQElamJiGgW+qjgJALSsK1YOrJGNseOnCb1pbsPEonQp rzggJK1MTENAt9VHASAWlYVqwdWSMbY8dQNrFyfcft9rZefdnNclbDDXMW4hKkuYAAJ2LaTt5vkz S1i5PuP2+1svPuzmuSthhrmLcQlSXMAAE7FtJ283yZoJ7hN60t2HiUToU15wQElamJiGgW+qjgJA LSsK1YOrJGNseOnCb1pbsPEonQprzggJK1MTENAt9VHASAWlYVqwdWSMbY8dQNrFyfcft9rZefdn NclbDDXMW4hKkuYAAJ2LaTt5vkzS1i5PuP2+1svPuzmuSthhrmLcQlSXMAAE7FtJ283yZoJ7hN60 t2HiUToU15wQElamJiGgW+qjgJALSsK1YOrJGNseOnCb1pbsPEonQprzggJK1MTENAt9VHASAWlY VqwdWSMbY8dQNrFyfcft9rZefdnNclbDDXMW4hKkuYAAJ2LaTt5vkzS1i5PuP2+1svPuzmuSthhr mLcQlSXMAAE7FtJ283yZoJ7hN60t2HiUToU15wQElamJiGgW+qjgJALSsK1YOrJGNseOs9juPgrh KO94Zudm586Qnn2pGtyRpbZOlwcxvCUasp3Vu4vZOO1WrWLk+4/b7Wy8+7Oa5K2GGuYtxCVJcwAA TsW0nbzfJmslvv062R1R2OlcZKisNyobMlKVEAEpDqVBJIAyRjOlOc4GAtERzouPOKoQgQmCtq6o KWk6wwlLEg6GiQAE5A3CQcJAGAVAxPBcrkz7gwGGVF+1zgXVo1LQkRHjhOdk5OMkDO2AQCoHQt3E t0tkuVLYdZckytXOelRmpC16goK7TiVEagpQVj42d80t3ElxtUuVJiCEh2VqDhXAYWAFBQUlIUgh CSFKBSkAEHGMYoJfhN60t2HiUToU15wQElamJiGgW+qjgJALSsK1YOrJGNseOvuxW+zt8MNXKeq0 c6RMejhN0MzSEtoaUCjphnOXTq1nxJx/KzAwnbrcJkuLbmFvP3JJQ7HixgS4kLDpCUJHZALYOEgY CfJX7b79OtkdUdjpXGSorDcqGzJSlRABKQ6lQSSAMkYzpTnOBgJ2xzpMfixy02TiC7xuHuscdW5G lLaUYqMqW7gYysNIKvi5OMY7hWSJxjzuueeut0sc2XPemvP2dvV1HM0kIUC6ghKCFFOSr+EV3b6q s3c5rU56aJK1Sn0upddcOtSw6lSXMk5ySFK379899ZLbeJlp5phllDjmMOqjtrcbIzhTa1JKm1DO dSCDkA52FBd3BZIV4/KJGetsopZW8kJiykMIDInMBKEpLStJBwc7jAxpHfVTsrLVzjyLfIaQ222l UgTwkDpsAAlw96mydKcbqCinQCSUORkeZIisymWXNLcpoMvDAOpAWlYG/d2kJO3k/XX71sjoOhDm Ixd5ykJAGpeMAqPerAzjPdqVjGo5CWsH8S8U/wBGI/xkaoGp6A5cWOFLoqNYuZDkYYk3TlPHlJC2 1hvUFcsdpKO9Oe137ioGgsPD16uMYIt8K7rszOp2RIlxnVNOOpDYOgkKAWQEENpJHacIyNWRE3SW 1Pu82ZHioiMyH1utx28aWUqUSEDAGwBx3Du7qxxJkiA8p6M5ocU04yTgHsOIKFjfypUR/XWCgtvC b1pbsPEonQprzggJK1MTENAt9VHASAWlYVqwdWSMbY8da8XwXbuEYVxfs7M+ZInyWMyHnUthtDbC h2W1JJVlw4OoDBVkK7JTAx5kiKzKZZc0tymgy8MA6kBaVgb93aQk7eT9dFzJC4DMFTmYzLq3kIwN lrCAo579w2j6PnNBYVCzWy0C5R7Ui4sy7jKjsJuS3EqbZaS0pB+BWgayHTqySOyMY3zv3m32bhdi SkWlFxebvc+Ahcx9wJ5LIZ06ktqQSvKzuCBurIPZ01u336dbI6o7HSuMlRWG5UNmSlKiACUh1Kgk kAZIxnSnOcDGvKuc2awGZUlbyQ+7Jy4dSi64Ehaio7knQnvPi+c0F0iiDw9J47tSbVFnNQULbQ7K W7rcQmawgIVy1pGO5WQAcjvxtWhYrfaG+GWrlPVaOdImPRwm6GZpCW0NKBR0wznLp1aj4k4/lZgU X+5Iu8q6F5C5UtS1yOayhbbxUrUdTagUKGrCsEYBAIwQMftvv062R1MMdK4yV6w3KhsyUpUQASkO pUEkgDJGM6U5zgYCdlt8PWm0dZEtqLqh27TY0Z6Y86lKo7aWSgqSgoOvt5zkd6spO2nJd7XaOGes Q5b/AAg2bzNt4U+8tDjbTHKwpBQQkLPNOSpK05Sns94NWk3ObNYDMqSt5Ifdk5cOpRdcCQtRUdyT oT3nxfOakhxJf2ufPLueslOPdQ5FbVpkHBWtpRT8EvtIJLekjseROA/eN/8Av9xH/Skn/mqr7iCD bOGItyftUW4vS5j8cplOPBLaWkMqBTyloOSXTnJPxU4xvnAjiBtyRKlXKzW+5y5T65DsiSp9CipR yQA04hIGcnu8fkxg3xNKjLdTDiW9iKtWtMRyKiU00rABKBI5hSVaRkg74HiAACW662xOCYLqrOiY hd2nchqZIWUto5cX43LKCpfxRnIHxuycjTtqsdqss+7MymrWYzN0kQo8i8OyjzA0QCEpigEKAUkq KtjqTpAwrNTlzLnLgNmW4+7GVKeeS64M63lBvmnWd1KwGyck4yD499tHFd5Q/Kf6pCnpL65KnFx2 1KbeUcqcaJTlpZOO0jSeynzRgJ282+zcLsSUi0ouLzd7nwELmPuBPJZDOnUltSCV5WdwQN1ZB7On bZ4assOfdY7zTL0KFeHoU6VMkltyJGBw240ApIcdUEvnTpc3aHY3wqmXC8z7rr62Rzdcp6YrsJTl 13TzFbAd+hO3cMbAVO2vjeRF6xcty6Jky5S5Tsm1TxBceWvGQ4Q2oLSCCUgAaStffq2DbgMWiTaF 32e1YmHp9xkIDE1MxLLSUpaWAymN3DLpBCidgjH8rOpKj2C1QFy2IfhSHKukuIy686424mO0Giha NOkBag6SStKhkJ7PeDGo4nnMyJS2GLehmQ+t8RVwWXmWVKO4aQ6lWgYAG3eEpBzpFEX6+WqRKZce WmUX1rcMplK3mX84WtKlgqbcyBlSSFZSnJykYC0ybHbrx+UXikzrpCZ0yrooR3g/ryhDq0uZQgjS lQCiM5OgjByAYhbq+G+HI0i0z2XXZM+Qw/KjoVokNIbjqDZDiQSjLq9SCnSrbUFBKcV5+5zZNylX FySvq5SnFPOoOgrLmdfxcDCgpQI7sEjurJbbzPtHN6F/lczBOUJVpUM6Vp1A6VpydK04UnJwRk0F skcKQLjf79a4Seg8GXSQlLiipzntatLcdsE9p/sKKEZy5qVlQ0b6HDM+Ob9eRDt7MdiVAuBbSsl1 cdvpX1BtKlf+UFWNR04yApQNaXMkLgMwVOZjMureQjA2WsICjnv3DaPo+c1JxeKrtDuU64tuRVy5 ylqkOvQmXSor1a8a0EJCgtQITgEHB2oM8RFtgcMRbhLtqJy5kx+MvW8tCmUNoZUC0UkALPOVutKx 2U9nvBuN7uPgqfe3vDNzs3P4juKefaka3JGktnS4OY3hKNWU7q3cXsnHaocXiS6Q+d07rKOa6p4Y jNfAuHvWz2fgVbDdvSeynzRjIjiq7JflPOORZCpT65LglQmX081ZytSUuIIQVbZ0gZ0pz3DASU22 x0cW8SSp0NhmDbZT5VFYUQ0XS4pLTCCAnKdW5A0q5bbhGCKOXmfGsDd8Zf0XK6XSWJzwQn4dKUsL 0KTjSUFTqypGNKsjUDpTivSrnNmsBmVJW8kPuycuHUouuBIWoqO5J0J7z4vnNZLbeZ9o5vQv8rmY JyhKtKhnStOoHStOTpWnCk5OCMmgtkjhSBcb/frXCT0Hgy6SEpcUVOc9rVpbjtgntP8AYUUIzlzU rKho31Lbd5MaPJkwZsrhqzKmOrSuC4tUh0qCdLAOtHNDYwcqICQtRJytKVVZcyQuAzBU5mMy6t5C MDZawgKOe/cNo+j5zUsnjC8fvjmrhSOfKcmL6q3R3/hXMa1DWg6c6U7DA2G1BJ2O+3CZxY41brhc LJZ5UxyZIjW+WppMdgZW4UhOAShpJxhOTpAAOwrbjeDblb5HEt28Cpm3O6StaLh1gbTgNufBCPuN 3jnWTsE4/lZp7dylMznpjKkNPPJdQvltJSnS4lSFgJA0pBSpQwAMZ2xgVsW+/T7ZHVHY6Vxkq1hu VDZkpSogAlIdSoJJAGSMZ0pznAwGvdG4TV3mt215b0BD60xnXBhS2go6VHYbkYPcP1CtSsj77sqQ 5IkOrdedUVuOOKKlLUTkkk7kk+OsdApSlApSlApSlApSlApSlArp7P8AoosP85cf+lXMK6ez/oos P85cf+lVHrClKVApSlApSlApSlApSlApSlApSlApSlApSlApSlApSlApSlApSlApSlApSlApSlAp SlApSlApSlApSlApSlApSlApSlApSlApSlApSlApSlArwBXv+vAFAq6WO4+CuEo73hm6WbnzpCef aka3JGltk6XBzG8JRqyndW7i9k47VTnIW3PkocidG4l1QVGwock53RhRKhju3JO29bdvv062R1R2 OlcZKisNyobMlKVEAEpDqVBJIAyRjOlOc4GAtkmbcbRd72hE1fDduau0pLjlpKuY8vUAGEAKb5iG wMjOkICyditKVbfBbMafxdDv0Ji1tPSb6AmC9KZR0TPMQrLbaikuKIWUJKU9nQcDUUlFPj8VXaOw tlTkWSlb65KjNhMylF1YSFq1OoUcnSnO++K0GblKjXdu6R1IaltPiQ2ptpKUoWFagQgDSAD4sY8W MUFhs0y52eA6jwu/ZYLUpxLsy2r1PS3MJHLTocSl1KMas6glIcUc5WlKq9dJbU+7zZkeKiIzIfW6 3HbxpZSpRIQMAbAHHcO7urbgcSXG2wBBZEJyMHVPJRKgMSNK1BIUQXEKIyEJ7vIK+Id/uVvkXB6G 8hhVwYcjSQ2ygJU04QVpCcYSDgfFAx4sUElYb1LtcBLfhK6WaG464rrLYyS5IcAb+DWeY2FJQNwM kpLh27e0tLusuyX68ROqm8Ow/Cksc6yNlXMcCkjk6tbQUhsbp7inmHsjXtV7ffp9sjqjsdK4yVaw 3KhsyUpUQASkOpUEkgDJGM6U5zgY+4vEl0i87LrErnOqeX10VqV8Ir4yxzUqwpWBkjBVgZzgYC6T lRLD4SkifNsEx6+z4yjZmA78G1yiGgsuNFKElxWAAArYkdhOIWxqvdm4sc4bF9uEKJGmOeEDb5a2 0hDWec4kbZIQ2ojYk6QME7VCxeJLpF52XWJXOdU8vrorUr4RXxljmpVhSsDJGCrAznAxqN3Oa1Oe miStUp9LqXXXDrUsOpUlzJOckhSt+/fPfQWWNxVcVyJc5+4XCyMz5kiS5LtDKtT7yiglokuoBQgH IGSU8w9+rNb8m+M2e73q2pn3Dh15q7SlqVZEBaXElQSlo9trsNlCtOx/hFbJ8dTt9+n2yOqOx0rj JVrDcqGzJSlRABKQ6lQSSAMkYzpTnOBj8iX+5QpEmS08hUqQvmLkvModeC8k60uLBUheSTqSQc4O cgUFluLDUW+flHjsNIaZaQ6htttISlCRcGAAAO4AeKqRU9AcuMfhS6KjWPmQ5GliTdOU8eWkLbWG 9QVyx2ko7057XfuKgaBU9wj/ABzI/ou4f4N6oGpbht+cxfGjbrd4SkuNPM9Jy1r5qFtKQsYQQr4q lHYjGM0CyQ48jq5LzfVKiNc5MFJIU/jvJIwdCQNStJ1Y7sDUtE1w1Ltblp4qeuMGU68uGHHDFkNx 0FBlR+ylHKUEnUQcjbA0hI7xW33JMG7uOIZXbpTD5UGmytCoy0q+KNRKgUkY3ORjvzWaE7dbhMlx bcwt5+5JKHY8WMCXEhYdIShI7IBbBwkDAT5KCb4TetLdh4lE6FNecEBJWpiYhoFvqo4CQC0rCtWD qyRjbHjpwm9aW7DxKJ0Ka84ICStTExDQLfVRwEgFpWFasHVkjG2PHUDaxcn3H7fa2Xn3ZzXJWww1 zFuISpLmAACdi2k7eb5M0tYuT7j9vtbLz7s5rkrYYa5i3EJUlzAABOxbSdvN8maCe4TetLdh4lE6 FNecEBJWpiYhoFvqo4CQC0rCtWDqyRjbHjpwm9aW7DxKJ0Ka84ICStTExDQLfVRwEgFpWFasHVkj G2PHUDaxcn3H7fa2Xn3ZzXJWww1zFuISpLmAACdi2k7eb5M0tYuT7j9vtbLz7s5rkrYYa5i3EJUl zAABOxbSdvN8maCe4TetLdh4lE6FNecEBJWpiYhoFvqo4CQC0rCtWDqyRjbHjpwm9aW7DxKJ0Ka8 4ICStTExDQLfVRwEgFpWFasHVkjG2PHUDaxcn3H7fa2Xn3ZzXJWww1zFuISpLmAACdi2k7eb5M0t YuT7j9vtbLz7s5rkrYYa5i3EJUlzAABOxbSdvN8maCe4TetLdh4lE6FNecEBJWpiYhoFvqo4CQC0 rCtWDqyRjbHjrPY7j4K4SjveGbnZufOkJ59qRrckaW2TpcHMbwlGrKd1buL2TjtVq1i5PuP2+1sv PuzmuSthhrmLcQlSXMAAE7FtJ283yZrJb79OtkdUdjpXGSorDcqGzJSlRABKQ6lQSSAMkYzpTnOB gLREc6LjziqEIEJgrauqClpOsMJSxIOhokABOQNwkHCQBgFQMTwXK5M+4MBhlRftc4F1aNS0JER4 4TnZOTjJAztgEAqB0LdxLdLZLlS2HWXJMrVznpUZqQteoKCu04lRGoKUFY+NnfNLdxJcbVLlSYgh Idlag4VwGFgBQUFJSFIIQkhSgUpABBxjGKCX4TetLdh4lE6FNecEBJWpiYhoFvqo4CQC0rCtWDqy RjbHjr7sXEzUDhhq2Jv99s7zcx6QpVsaCkvJWhpKQr4Zs5SW1eI/GqtC5SkmcUKQ2JydEhLbSUpU nmJcwEgYSNSEnCcYxju2rYt9+nWyOqOx0rjJUVhuVDZkpSogAlIdSoJJAGSMZ0pznAwFv0+5uBJc nX65wLyu8zYkqdbWuc5I5QayC4p1tQTqcUrb45IKhlKcfDEZnhG0OofvNwtdyTdpcF6VamA4p1LK WezrLjako1LUcD42RqHYTirReJLpF52XWJXOdU8vrorUr4RXxljmpVhSsDJGCrAznAxntN3v78tc SE14TkynVPcl+C3OWpwjK1pS4hZCiBlRG50jOcDAT0a7e5m3yOGnuIb1aZsC6Sucu0t6239m2xkl 1s7FpWMjuV4t6jDb3XbvebLd1IXIiPvuPXQEq5LiVaVrcWRqW2pQAwe1qUkoBUShyNi8SXSLzsus Suc6p5fXRWpXwivjLHNSrClYGSMFWBnOBjUeuc2THcZekrcQ6+ZLpUcqddIxqWrvURk4yTjUrGNS shJ2D+JeKf6MR/jI1QNT0By4scKXRUaxcyHIwxJunKePKSFtrDeoK5Y7SUd6c9rv3FQNBYeHr1cY wRb4V3XZmdTsiRLjOqacdSGwdBIUAsgIIbSSO04RkasiJuktqfd5syPFREZkPrdbjt40spUokIGA NgDjuHd3VjiTJEB5T0ZzQ4ppxknAPYcQULG/lSoj+usFBZeHrBH4igOMpV0kmK6XFvqBV1KFABLD acgF/KFlCNuZqVunQMyVviWBdoXeHGLRGTLuMhpmNdHJq0stIS0pKUKjjJI5pCivvwnGO1VPXMkL gMwVOZjMureQjA2WsICjnv3DaPo+c1Jo4quyX5TzjkWQqU+uS4JUJl9PNWcrUlLiCEFW2dIGdKc9 wwEtLb4etNo6yJbUXVDt2mxoz0x51KVR20slBUlBQdfbznI71ZSdtO3N4RtjEiVDQX/3vPvTIdK+ 2tESOhxoK2x8bOcAZ1H5sU+Vc5s1gMypK3kh92Tlw6lF1wJC1FR3JOhPefF85rfRxXeUPyn+qQty U+uQ6XI7a+2s/CFIKSEhY2WE4C09lQI2oLKuz2i2ttPyIloaZfYilDt0emKStZiMOuBCY/aB1Pal FZwdaQkDSqkUQeHpPHdqTaos5qChbaHZS3dbiEzWEBCuWtIx3KyADkd+NqrTfFd5bW6sSkFS1a0q VHbUWFABILOU/AkBKAC3pwEIA+KnGui/3JF3lXQvIXKlqWuRzWULbeKlajqbUChQ1YVgjAIBGCBg N+IINt4Yi3J+1Rbi9LmPxymU48EtpaQyoFPKWg5JdOck/FTjG+d/rrbE4Jguqs6JiF3adyGpkhZS 2jlxfjcsoKl/FGcgfG7JyNMFb79PtkdUdjpXGSorDcqGzJSlRABKQ6lQSSAMkYzpTnOBjXlXObNY DMqSt5Ifdk5cOpRdcCQtRUdyToT3nxfOaDY4it7Vo4mu1tjqWpmHMejtqcIKilCykE4AGcDyVNcJ 3CNFsPEqXrRClqTAS4VvreBUkyo40HQ4kaQe1sAcjvxtUYjiBtyRKlXKzW+5y5T633ZElT6FFSjk gBpxCcZye7x+TGNdu9PRbk7Mt8aLDQ6nQqKlBeZKdtih4r1DICsKzhQBGMDATTE2HC4Bti5NrZuD irpNCEyHXEtpHKi5OG1JUVd2DqwBqyDkFO3ebfZuF2JKRaUXF5u9z4CFzH3AnkshnTqS2pBK8rO4 IG6sg9nTT1zJC4DMFTmYzLq3kIwNlrCAo579w2j6PnNbFwvM+66+tkc3XKemK7CU5dd08xWwHfoT t3DGwFBaIFu4datDly1W8syLjIjx03sytQZbS0pBHS7a8O9rUcbJ0+PPxEgWKN10gC1u21c95iFL vDkv4ZtGkjSiMkKSoJWgqK9jrSEgaVZr1vv0+2R1R2OlcZKisNyobMlKVEAEpDqVBJIAyRjOlOc4 GPuLxLd4nOLcvW466p8uvtodcQ6rvcQtYKm1nAJWkhRKUnPZGAnrva7Rwz1iHLf4QbN5m28KfeWh xtpjlYUgoISFnmnJUlacpT2e8Hfk2O3Xj8ovFJnXSEzplXRQjvB/XlCHVpcyhBGlKgFEZydBGDkA 1ZHFd5Q/Kf6pCnpL65KnFx21KbeUcqcaJTlpZOO0jSeynzRjQfuc2TcpVxckr6uUpxTzqDoKy5nX 8XAwoKUCO7BI7qCwrdXw3w5GkWmey67JnyGH5UdCtEhpDcdQbIcSCUZdXqQU6VbagoJTjfkcKQLj f79a4Seg8GXSQlLiipzntatLcdsE9p/sKKEZy5qVlQ0b1qwzL01LMSyJedkyN0sssB5epIJC0JwS laRqIWnCk5OCMmtBcyQuAzBU5mMy6t5CMDZawgKOe/cNo+j5zQWXhmfHN+vIh29mOxKgXAtpWS6u O30r6g2lSv8AygqxqOnGQFKBwcFyuTPuDAYZUX7XOBdWjUtCREeOE52Tk4yQM7YBAKgdSLxVdody nXFtyKuXOUtUh16Ey6VFerXjWghIUFqBCcAg4O1Y7dxJcbVLlSYghIdlag4VwGFgBQUFJSFIIQkh SgUpABBxjGKDf4PuV2RdY1tjXq6W+2rdL8wQpS2tDSU6nXAAcFQbQo9xJ0gYOwrGw4m93e78RXZl BjpU5KeaQVJQ6+4o8tob5wVnJAUFctDhBymolu5SmZz0xlSGnnkuoXy2kpTpcSpCwEgaUgpUoYAG M7YwKIdmzIbVubC3WWFOyUNIRkpJQnmK2GcaWkk+IBJO29BYXLzPjWBu+Mv6LldLpLE54IT8OlKW F6FJxpKCp1ZUjGlWRqB0pxvyOFIFxv8AfrXCT0Hgy6SEpcUVOc9rVpbjtgntP9hRQjOXNSsqGjep 228z7Rzeif5XMwTlCVaVDOladQOlacnStOFJycEZNa65khyAzBU5mMy6t5CMDZawgKOe/cNo+j5z QWXhmfHN+vIh29mOxKgXAtpWS6uO30r6g2lSv/KCrGo6cZAUoGT/ACbW5vwvZrkyu3vTFXZtlTUq UyhTDQU2StDa1AuLXqUlJAOnQrAKikorUXiq7Q7lOuLbkVcucpapDr0Jl0qK9WvGtBCQoLUCE4BB wdq0GblKjXdu6MKQ1LafEhtTbSUpQsK1AhAGkAHxYx4sYoLDZrdBiQHXrozZd5TkdD9wkSXG1qbC SpLQiZ7tYJUokKCk6e5WYbiK3tWjia7W2OpamYcx6O2pwgqKULKQTgAZwPJX5b7/AHK1x1MxHkJQ VcxBWyhxTK8Aa2lKBLa9k9pBB7Kd+yMak2ZIuM+ROlucyTJdU86vAGpaiSTgbDcnuoMFKUoFKUoF KUoFKUoFKUoFKUoFdPZ/0UWH+cuP/SrmFdPZ/wBFFh/nLj/0qI9YUpSilKUoFKUoFKUoFKUoFKUo FKUoFKUoFKUoFKUoFKUoFKUoFKUoFKUoFKUoFKUoFKUoFKUoFKUoFKUoFKUoFKUoFKUoFKUoFKUo FKUoFKUoFeAK9/14AoFXSx3HwVwlHe8M3Szc+dITz7UjW5I0tsnS4OY3hKNWU7q3cXsnHaqc5C25 8lDkTo3EuqCo2FDknO6MKJUMd25J23rbt9+nWyOqOx0rjJUVhuVDZkpSogAlIdSoJJAGSMZ0pznA wFskzbjaLve0Imr4btzV2lJcctJVzHl6gAwgBTfMQ2BkZ0hAWTsVpSrb4LZjT+Lod+hMWtp6TfQE wXpTKOiZ5iFZbbUUlxRCyhJSns6Dgaikop8fiq7R2FsqciyUrfXJUZsJmUourCQtWp1Cjk6U533x WgzcpUa7t3SOpDUtp8SG1NtJSlCwrUCEAaQAfFjHixigsNmmXOzwHUeF37LBalOJdmW1ep6W5hI5 adDiUupRjVnUEpDijnK0pVXrpLan3ebMjxURGZD63W47eNLKVKJCBgDYA47h3d1bcDiS422AILIh ORg6p5KJUBiRpWoJCiC4hRGQhPd5BXxDv9yt8i4PQ3kMKuDDkaSG2UBKmnCCtITjCQcD4oGPFigk rDepdrgJb8JXSzQ3HXFdZbGSXJDgDfwazzGwpKBuBklJcO3b2lpd1l2S/XiJ1U3h2H4UljnWRsq5 jgUkcnVraCkNjdPcU8w9ka9qvb79PtkdUdjpXGSrWG5UNmSlKiACUh1KgkkAZIxnSnOcDH3F4kuk XnZdYlc51Ty+uitSvhFfGWOalWFKwMkYKsDOcDAXScqJYfCUkT5tgmPX2fGUbMwHfg2uUQ0Flxop QkuKwAAFbEjsJxC2NV7s3FjnDYvtwhRI0xzwgbfLW2kIazznEjbJCG1EbEnSBgnaoWLxJdIvOy6x K5zqnl9dFalfCK+Msc1KsKVgZIwVYGc4GNRu5zWpz00SVqlPpdS664dalh1KkuZJzkkKVv37576C 0xOMed1zz11uljmy57015+zt6uo5mkhCgXUEJQQopyVfwiu7fVtiXcIf5S7rZrddrharOm7SXJDV vkKYS0w2tRcWlKdspaQSAAT2QADsKp9tvEy080wyyhxzGHVR21uNkZwptaklTahnOpBByAc7CteJ MkQHlPRnNDimnGScA9hxBQsb+VKiP69qCxRLg7d0ca3KQlCXpcPnuJbBCQpc6OogZJ2yfLVWqegO XGPwpdFRrHzIcjSxJunKePLSFtrDeoK5Y7SUd6c9rv3FQNAqe4R/jmR/Rdw/wb1QNS3Db85i+NG3 W7wlJcaeZ6TlrXzULaUhYwghXxVKOxGMZoFkhx5HVyXm+qVEa5yYKSQp/HeSRg6EgalaTqx3YGpa JrhqXa3LTxU9cYMp15cMOOGLIbjoKDKj9lKOUoJOog5G2BpCR3itvuSYN3ccQyu3SmHyoNNlaFRl pV8UaiVApIxucjHfms0J263CZLi25hbz9ySUOx4sYEuJCw6QlCR2QC2DhIGAnyUE3wm9aW7DxKJ0 Ka84ICStTExDQLfVRwEgFpWFasHVkjG2PHThN60t2HiUToU15wQElamJiGgW+qjgJALSsK1YOrJG NseOoG1i5PuP2+1svPuzmuSthhrmLcQlSXMAAE7FtJ283yZpaxcn3H7fa2Xn3ZzXJWww1zFuISpL mAACdi2k7eb5M0E9wm9aW7DxKJ0Ka84ICStTExDQLfVRwEgFpWFasHVkjG2PHThN60t2HiUToU15 wQElamJiGgW+qjgJALSsK1YOrJGNseOoG1i5PuP2+1svPuzmuSthhrmLcQlSXMAAE7FtJ283yZpa xcn3H7fa2Xn3ZzXJWww1zFuISpLmAACdi2k7eb5M0E9wm9aW7DxKJ0Ka84ICStTExDQLfVRwEgFp WFasHVkjG2PHThN60t2HiUToU15wQElamJiGgW+qjgJALSsK1YOrJGNseOoG1i5PuP2+1svPuzmu SthhrmLcQlSXMAAE7FtJ283yZpaxcn3H7fa2Xn3ZzXJWww1zFuISpLmAACdi2k7eb5M0E9wm9aW7 DxKJ0Ka84ICStTExDQLfVRwEgFpWFasHVkjG2PHWex3HwVwlHe8M3Ozc+dITz7UjW5I0tsnS4OY3 hKNWU7q3cXsnHarVrFyfcft9rZefdnNclbDDXMW4hKkuYAAJ2LaTt5vkzWS336dbI6o7HSuMlRWG 5UNmSlKiACUh1KgkkAZIxnSnOcDAWiI50XHnFUIQITBW1dUFLSdYYSliQdDRIACcgbhIOEgDAKgY mLMkWXhGFOt7nIky58liQsAHmtNtsFLagcgoJdXqQeyrbUDpTjQt3Et0tkuVLYdZckytXOelRmpC 16goK7TiVEagpQVj42d818RL/coMiS9FeQyqQrmKCGUBKV5JStCcYbWnJ0qQAU5OkjNBd5zVs4X8 JGJc7nZXDfp8NDttZ5rimWeVobK1OoUlI5hOATqOCr4qa0I129zNvkcNPcQ3q0zYF0lc5dpb1tv7 NtjJLrZ2LSsZHcrxb1XrFcbylYttrjInLdUVtxXIDcw6sdooQtCtJISMlIGQkZ+KMY4vEl0i87Lr ErnOqeX10VqV8Ir4yxzUqwpWBkjBVgZzgYC0pssK2x5ki/SbRIuZu0uG+5dFzVpWpkNkqbMcaiSp xWSvv7OAO1WvZ1cORmOMmm2LhNiIjnkvIlpZLkfrI4RspokLzpUT5MjSDuK9F4kukXnZdYlc51Ty +uitSvhFfGWOalWFKwMkYKsDOcDGoLnNzOUqStap6dEpbh1qdHMS4ck751oSc9+3zmgtNkkRLRwj Hni73O0zJU+QyqRbY4cccbbbZIQVF1spSC4o4GQokZ+InGg1aOXPunDtwQwlUB10ruLY7MdSDoUV qwCppRCRjGoEp0AqJQ5G2+/TrZHVHY6VxkqKw3KhsyUpUQASkOpUEkgDJGM6U5zgY13rnNkx3GXp K3EOvmS6VHKnXSMalq71EZOMk41KxjUrISdg/iXin+jEf4yNUDU9AcuLHCl0VGsXMhyMMSbpynjy khbaw3qCuWO0lHenPa79xUDQWHh69XGMEW+Fd12ZnU7IkS4zqmnHUhsHQSFALICCG0kjtOEZGrIi bpLan3ebMjxURGZD63W47eNLKVKJCBgDYA47h3d1Y4kyRAeU9Gc0OKacZJwD2HEFCxv5UqI/rrBQ WmwRLei0GZcWLQlDr62m3ro5LKVlCUFSUJjDII1pKis4OpOnGlWXFdihWRhxuKFqUze7hB5risqU 0yGNGcbZ7ajkAZz+rHxw4OJFxFotKUhgLK0uutNq5LmACppawS2vZPaQQeynfsjEsiFxqh+U/wAy Kp6S+uSpxfIUpt5RypxokZaWTjtI0nsp80YDOhdusdw4/tzVkhSGInMS3z3H88tM1hCWyUuDsjZW fjZG6iMiq7EEG2cMRbk/aotxelzH45TKceCW0tIZUCnlLQckunOSfipxjfMoizcWou8q6HpVypal rkc0srbeKlajqbUChQ1YVgjAIBGCBhb7LxVbI6o7DNvcZKisNym48lKVEAEpDqVBJIAyRjOlOc4G A+rzbrNwuxJSLSi4vN3ufAQuY+4E8lkM6dSW1IJXlZ3BA3VkHs6UC3cOtWhy5areWZFxkR46b2ZW oMtpaUgjpf5eHe1qONk6fHnWlcNcUzWAzKWh5Ifdk5ckIUouuBIWoqJySdCe8+L5zWe32Xiq2R1R 2Gbe4yVFYblNx5KUqIAJSHUqCSQBkjGdKc5wMBtQ7Tw8YrvTQkT465l1VHlPuOpcUzFjoeaGEqSM LyQrKdWFHBScEa95g2nh6BFnos0WabgpKuTKde0RwYsZ/S3ocSrGqSodsqOEp3zkq+U2fjBIIL6F kqkrUpx5talKkNht4lRySVJAGT+sYO9bDULjJsaVJt8hAS2hKJTMZ9KAhtLadIcSoJOhCASMFWlO c4FBrTeEY70+RabX2ZMbiJVqL0lZ7aHSUsZwMbFl4qIA+MnGe4Z40LhowJF2Q3bGY0q5ymYrN4Mw 8tlAbUgJ6bJ1YdwrWT3Jx/KJww7PxhAkXCRHfRzriw5HluOPNuKeQ4QVglWTkkd/f89LfZeKrZHV HYZt7jJVrDcpuPJSlRABKQ6lQSSAMkYzpTnOBgKrdG4TV3mt215b0BD60xnXBhS2go6VHYbkYPcP 1Cp61WKFcLDDfcStDy1XVS3EK3UI8Rt5tODkY1FWdskKO/diQi2G7N85c+w2u6SXnVOrkzZr3MJP fkoeSDvk5IJyTvX23beKYq3Rb4lvhR1q1pjIUh1DZwEq0F4rUAsABYzhY7KspwKD7XZ7RbW2n5ES 0NMvsRih26PTFJWsxGHXAhMftA6ntSis4OtISBpVWe5WKFAtEmMErmNWi93RLMNSsOSEtpjDUojH ZSBqXp7WM4CRqWjVbhcatLdWHIpUtWtKlchRYUAEgs5HwJASgAt6cBCAPipxgk2fjGXID7r6OcmY 7PS4282hSX3CkrWCnBBJQnu2GNsUGKxW+zt8MNXKeq0c6RMejhN0MzSEtoaUCjphnOXTq1nxJx/K zWro3Cau81u2vLegIfWmM64MKW0FHSo7DcjB7h+oVbotr4sic4NsWtbbrqni0/HiutoWrvKELSUt 5wAdIGQlI/kjCLYbs3zlz7Da7pJedU6uTNmvcwk9+Sh5IO+TkgnJO9Bp8JvWluw8SidCmvOCAkrU xMQ0C31UcBIBaVhWrB1ZIxtjx1ESIUdvhG3Tkt4kvT5TK15O6ENxykY7ti4v6fmFTbvDd/5k3o4M KCxMaSy7HYf1I0BSF4BcUpQ7TaVd/wDZtWS32bi21x1MxDFSgr5iCssuKZXgDW0pQJbXsntIIPZT v2RgM1/hWPh3rVt2NmW4L9cITSZEh7loYa5OkYQtKioazg6u4qyFbFOC72218K9Zi2MXPF5mwEdc 46NDbHK0kcpaO0eac5yNhgDfPxcLBxXddfWqYd1ynpivhG05dd08xW2O/QnbuGNgK3EQeMkvynnE 2+QqU+uS4JTMZ9PNWcrUlLiSEFW2dIGdKc9wwGlw1cYMe08VBNliyGxDDiOqedKygyo4Dai2tAIG QrISkkjvx2ajeE0tOXOY241q1WucUqDi0KbUmM4sEFKhnOnSQcghRBFSkawcVxJ701CmHX39XPMh xt9L2TqPMSvKV9oBXaB3APeAa+7PZeKrEt5cBq3hTyChanm4750kFJA5gVgEKIIGMg4OaCLiCBbO GItyftUW4vS5j8cplOPBLaWkMqBTyloOSXTnJPxU4xvmWvNvs3C7ElItKLi83e58BC5j7gTyWQzp 1JbUgleVncEDdWQezp+otr4sic4NsWtbbrqni0/HiutoWrvKELSUt5wAdIGQlI/kjGpK4a4pmsBm UtDyQ+7Jy5IQpRdcCQtRUTkk6E958Xzmg2onCVpPF18tr12itswV3BppmTzi6Q004UOkttlOAUhR GcnSeycgHTW6vhvhyNItM9l12TPkMPyo6FaJDSG46g2Q4kEoy6vUgp0q21BQSnH0/wANcUyblKuL i0dXKU4p51EhCCsuZ1/FIGFBSgR3YJHdX3bbBxXaOb0KmGuZgnLjatKhnStOrOlacnStOFJycEZN BtSOFIFxv9+tcJPQeDLpISlxRU5z2tWluO2Ce0/2FFCM5c1KyoaN9By5eDLA3dLI14O6+6S21thX N/e6EsKQwoqHbQOaoKSRhe2oHAx8r4T4jXAZgqSwYzLq3kI5yNlrCAo579w2j6PnNb7ds4zanzZy HWBJmul95ZW0fhSSQ4kHZCwVK0rThSdRwRk0GlNs0CDxdxIpxjFptEp9CGStWHFcxSGWdWcnJAKh qCuWhwg5FHLzPjWBu+Mv6LldLpLE54IT8OlKWF6FJxpKCp1ZUjGlWRqB0px8r4T4jXAZgqSwYzLq 3kI5yNlrCAo579w2j6PnNZ7bYOK7RzehUw1zME5cbVpUM6Vp1Z0rTk6VpwpOTgjJoNqRwpAuN/v1 rhJ6DwZdJCUuKKnOe1q0tx2wT2n+wooRnLmpWVDRvqW27yY0eTJgzZXDVmVMdWlcFxapDpUE6WAd aOaGxg5UQEhaiTlaUqwr4T4jXAZgqSwYzLq3kI5yNlrCAo579w2j6PnNSyY/Gn745qLXI58pyYvq o0R/4VzGtQ1oOnOlOwwNhtQYozNil2+Rf349lieELpKQ1FuBl8tltIbWlLXSgd3OIOrbATpA3qn3 RuE1d5rdteW9AQ+tMZ1wYUtoKOlR2G5GD3D9Qq3RbXxZE5wbYta23XVPFp+PFdbQtXeUIWkpbzgA 6QMhKR/JGI1/g7iGVIckSAh151RW445JSpS1E5JJJyST46CsUqx+4e+fmWPr0ffT3D3z8yx9ej76 CuUqx+4e+fmWPr0ffT3D3z8yx9ej76CuUqx+4e+fmWPr0ffT3D3z8yx9ej76CuV05r/RPYf/AL7l /wBKqp7h75+ZY+vR99XBEOangm2WUxFdRFVLK181vQebo04OrO2k52FWEl6spVC99a2eh7t9Mf8A Gp761s9D3b6Y/wCNUVfaVQvfWtnoe7fTH/Gp761s9D3b6Y/41BfaVQvfWtnoe7fTH/Gp761s9D3b 6Y/41BfaVQvfWtnoe7fTH/Gp761s9D3b6Y/41BfaVQvfWtnoe7fTH/Gp761s9D3b6Y/41BfaVQvf Wtnoe7fTH/Gp761s9D3b6Y/41BfaVQvfWtnoe7fTH/Gp761s9D3b6Y/41BfaVQvfWtnoe7fTH/Gp 761s9D3b6Y/41BfaVQvfWtnoe7fTH/Gp761s9D3b6Y/41BfaVQvfWtnoe7fTH/Gp761s9D3b6Y/4 1BfaVQvfWtnoe7fTH/Gp761s9D3b6Y/41BfaVRWvyp2px1CF2u6NJUoAuKDKgkE95CXCogfMCfID VxgT4t0gtTYTyXo7qcoWM/qIIO4IOQQdwQQd6DZpSlApSlApSlApSlApSlApSlApSlApSlApSlAp SlApSlApSlApSlApSlApSlArwBXv+vAFAq6WO4+CuEo73hm6WbnzpCefaka3JGltk6XBzG8JRqyn dW7i9k47VTnIW3PkocidG4l1QVGwock53RhRKhju3JO29bdvv062R1R2OlcZKisNyobMlKVEAEpD qVBJIAyRjOlOc4GAtkmbcbRd72hE1fDduau0pLjlpKuY8vUAGEAKb5iGwMjOkICyditKVbfBbMaf xdDv0Ji1tPSb6AmC9KZR0TPMQrLbaikuKIWUJKU9nQcDUUlFPj8VXaOwtlTkWSlb65KjNhMylF1Y SFq1OoUcnSnO++K0GblKjXdu6R1IaltPiQ2ptpKUoWFagQgDSAD4sY8WMUFhs0y52eA6jwu/ZYLU pxLsy2r1PS3MJHLTocSl1KMas6glIcUc5WlKq9dJbU+7zZkeKiIzIfW63HbxpZSpRIQMAbAHHcO7 urbgcSXG2wBBZEJyMHVPJRKgMSNK1BIUQXEKIyEJ7vIK+Id/uVvkXB6G8hhVwYcjSQ2ygJU04QVp CcYSDgfFAx4sUElYb1LtcBLfhK6WaG464rrLYyS5IcAb+DWeY2FJQNwMkpLh27e0tLusuyX68ROq m8Ow/Cksc6yNlXMcCkjk6tbQUhsbp7inmHsjXtV7ffp9sjqjsdK4yVaw3KhsyUpUQASkOpUEkgDJ GM6U5zgY+4vEl0i87LrErnOqeX10VqV8Ir4yxzUqwpWBkjBVgZzgYC6TlRLD4SkifNsEx6+z4yjZ mA78G1yiGgsuNFKElxWAAArYkdhONRjncJ2h2HIvdwtDzV2lxXJFnSVqkqaSyCleXGuwkqyjdWeY vZP8qrReJLpF52XWJXOdU8vrorUr4RXxljmpVhSsDJGCrAznAwi8SXSLzsusSuc6p5fXRWpXwivj LHNSrClYGSMFWBnOBgLhM4hatEi62cXe78PPMXua6tqythbJSotpSgHmtHCC2oDs9yu4d1YE312x R5lincTX633OLdpa5T9sSXUyVENoypRebUSFNLOSD8bxb1VovEl0i87LrErnOqeX10VqV8Ir4yxz UqwpWBkjBVgZzgYReJLpF52XWJXOdU8vrorUr4RXxljmpVhSsDJGCrAznAwEs3GlwneOok9/nzGI pbfe1lfMcTOjhStR3OSCcnc1U6sMeVd1cOXiULQuSzNXy5l4cQ8tSfhG3NBXq0AlaUHJBV2u/cVX qBU9wj/HMj+i7h/g3qgaluG35zF8aNut3hKS408z0nLWvmoW0pCxhBCviqUdiMYzQLJDjyOrkvN9 UqI1zkwUkhT+O8kjB0JA1K0nVjuwNS0TXDUu1uWnip64wZTry4YccMWQ3HQUGVH7KUcpQSdRByNs DSEjvFbfckwbu44hldulMPlQabK0KjLSr4o1EqBSRjc5GO/NZoTt1uEyXFtzC3n7kkodjxYwJcSF h0hKEjsgFsHCQMBPkoJvhN60t2HiUToU15wQElamJiGgW+qjgJALSsK1YOrJGNseOnCb1pbsPEon QprzggJK1MTENAt9VHASAWlYVqwdWSMbY8dQNrFyfcft9rZefdnNclbDDXMW4hKkuYAAJ2LaTt5v kzS1i5PuP2+1svPuzmuSthhrmLcQlSXMAAE7FtJ283yZoJ7hN60t2HiUToU15wQElamJiGgW+qjg JALSsK1YOrJGNseOnCb1pbsPEonQprzggJK1MTENAt9VHASAWlYVqwdWSMbY8dQNrFyfcft9rZef dnNclbDDXMW4hKkuYAAJ2LaTt5vkzS1i5PuP2+1svPuzmuSthhrmLcQlSXMAAE7FtJ283yZoJ7hN 60t2HiUToU15wQElamJiGgW+qjgJALSsK1YOrJGNseOnCb1pbsPEonQprzggJK1MTENAt9VHASAW lYVqwdWSMbY8dQNrFyfcft9rZefdnNclbDDXMW4hKkuYAAJ2LaTt5vkzS1i5PuP2+1svPuzmuSth hrmLcQlSXMAAE7FtJ283yZoJ7hN60t2HiUToU15wQElamJiGgW+qjgJALSsK1YOrJGNseOs9juPg rhKO94Zudm586Qnn2pGtyRpbZOlwcxvCUasp3Vu4vZOO1WrWLk+4/b7Wy8+7Oa5K2GGuYtxCVJcw AATsW0nbzfJmslvv062R1R2OlcZKisNyobMlKVEAEpDqVBJIAyRjOlOc4GAtERzouPOKoQgQmCtq 6oKWk6wwlLEg6GiQAE5A3CQcJAGAVAxPBcrkz7gwGGVF+1zgXVo1LQkRHjhOdk5OMkDO2AQCoHQt 3Et0tkuVLYdZckytXOelRmpC16goK7TiVEagpQVj42d80t3ElxtUuVJiCEh2VqDhXAYWAFBQUlIU ghCSFKBSkAEHGMYoJfhN60t2HiUToU15wQElamJiGgW+qjgJALSsK1YOrJGNseOvuxcTNQOGWram /wB9s7zcx6QpVsaCkvJWhpKQr4Zs5SW1eI/GqtC5SkmcUKQ2JydEhLbSUpUnmJcwEgYSNSEnCcYx ju2rYt9+nWyOqOx0rjJUVhuVDZkpSogAlIdSoJJAGSMZ0pznAwFsTfXbFHmWKdxNfrfc4t2lrlP2 xJdTJUQ2jKlF5tRIU0s5IPxvFvW/wlZH4PGsd+TKt828tcQdJJ6qa0FNhDiNbqEOKCnVrKlBJwSN KiAVlJRR4vEl0i87LrErnOqeX10VqV8Ir4yxzUqwpWBkjBVgZzgY1GbnNj3du6okrM9t8SQ+4dai 6FatR1Zyc775zQWm02m1Q7CJlyXZVSXJ78Ui4OSlt4aS0ctGJkHJcOSSQQE6fHmPZiW2bPulrinV bGXXX4t0WjSplsHCVOnAKkKGgFONQURoBUS25HW+/TrZHVHY6Vxkq1huVDZkpSogAlIdSoJJAGSM Z0pznAxrvXObJjuMvSVuIdfMl0qOVOukY1LV3qIycZJxqVjGpWQk7B/EvFP9GI/xkaoGp6A5cWOF LoqNYuZDkYYk3TlPHlJC21hvUFcsdpKO9Oe137ioGgsPD16uMYIt8K7rszOp2RIlxnVNOOpDYOgk KAWQEENpJHacIyNWRE3SW1Pu82ZHioiMyH1utxm8aWUqUSEDAGwBx3Du7qxxJkiA8p6M5ocU04yT gHsOIKFjfypUR/XWCg7NY4aHo0KC043HQmLzCpzUUpAb5iicAnxHuBqcHDxOwu0I/qbkfhVXrHKI mcjSMeCH+0pWB/2JZ3q8P8UruHwjy46GittRxK1BsatJONIxsvJJ8gry+K1c9PG8Ji/aJies/s9P h8MM5/HE184j/FIKXZDEjOveEYrpaRzC2hDwUU6kpyNSAO9afHUPzvnq48QuW/wJd5EWaxIXHiIA 5UhCwoKfZzskkjGAN/LWOy2e2yeHbFPlwmEw340+RdJfPXzmW2SQhbaAvfBxnCFeLI333oTqzpxO tERl8GNaNLd/03XxVPn059SEmwswuH2J8y8xI0t62JuTcd5xtIWlW4bTlfMKykHGG9JIxqqZV+T5 wT1QU3VBfEtyEnLBCS6GOobyc7JLfecZSrYBQ3ru4qrza/ObUszw40qIhb1xWiR4GF7WlEcKbTGK twFFYJc05OnSBnbUO+pO98MQRxNxGiJIMO22hEbmJUUAhbqU4SlTrqUkd6ipSk7nSAe8hVubX7za leG7db5X5TGbC7IjXSBqcHPjPHQ6A0paSCk9/dkA7EEZOKyIhQ2OLrdw5KYjIakwkNpuaVOupkSH WwpDzeClJbDhCEjGCArUfIEPzqc6rPZrbZF3dy23ZtbTcLh8z7g6UOtvMPKKV4KckZbbUnYJ3JOQ TsNlHDdnkXTgmDEdbfRP6rrZLbi1oeWxp1pQez2chaQoAZGDv4wp/Opzq6HAsPB9yu/D5KREVcbc mUbX1DiipTiCtGDjJSEoeydQ3Sjbtb0t6wtQ+HI8+deoceW9a03JDDjjaUrCtw2nK+YVlOSMNlOe zqoI/m05tW6NwvBi+F7dIWZN1hSrYw4tbakstmQ6gKCdLgLg0rxkhJ2279oc8LyXIl+lFzkeDlzF NAthDT7cdYSsoy4pzbOPiqTkAFeTQRXOpzq3OFoTPE0STCQOXcW5EdaFobW4tTC1hpzIBCQEFaF5 xnAV4txJW+yM8VJQ/aFQ48SVfnYUdXKe1BhLKnArKl+NKCcFOST3pGwCA5tObUj4EhPSEMQr2zLk OwpEhmKwG3ny60M8pQZcWkak7pOo5wRjNbErhJ2KnBuLa1uymIUVSWHOW9IW6tpxvWR2eWppwk4O UhJ21AUEPzqc6rC3whEf4hjWdjiGMp9yW9FcbPKU8jltqXrDaHVHSdCgdRSoHGRvVJlXKKmSpMB5 yTG0oUl1xvlKOUBRBTk4IJKe8g42OKCV51OdUJ4UPmf3qeFD5n96gm+dTnVCeFD5n96nhQ+Z/eoJ vnU51QnhQ+Z/ep4UPmf3qCb51OdUJ4UPmf3qeFD5n96gm+dTnVCeFD5n96nhQ+Z/eoJvnU51QnhQ +Z/ep4UPmf3qCb51OdUJ4UPmf3qeFD5n96gm+dTnVCeFD5n96nhQ+Z/eoJvnU51QnhQ+Z/ep4UPm f3qCb51OdUJ4UPmf3qeFD5n96gm+dTnVCeFD5n96nhQ+Z/eoJvnU51QnhQ+Z/ep4UPmf3qCb51Od UJ4UPmf3qeFD5n96gm+dTnVCeFD5n96nhQ+Z/eoJvnU51QnhQ+Z/ep4UPmf3qCb51OdUJ4UPmf3q eFD5n96gm+dTnVCeFD5n96nhQ+Z/eoJvnU51QnhQ+Z/ep4UPmf3qCb51OdUJ4UPmf3qeFD5n96gm +dTnVCeFD5n96nhQ+Z/eoLVAtr05jnmQhlBJCRy9ROCQSdxjcVteAl+kEfZz7da/D3EL1riwJUdp JcRrWnUcj46tsYrpEhmPa7e5xEzanOrS0h3wcpQPSlRI5ih36diQMbYPdjs+Hzs8ssoiez7U+E0s NPDLLH+aIrr3n9vm5lcIbtuDay+l1tatOoI0kHBPdk+SuhfkllOrXeIxXlkJYfCcD46uYhRz37hp A/q+c1za/wB4XJh85xHbMlKjv3kpXnxVfvyMO85y7OEYzHjbf/7JFd/D6k54bpeLx/h40NacIinV 6UpXd4ilKUClKUClKUClKUClKUClKUClKUClKUClKUClKUClKUClKUClKUClKUCvAFe/68AUCrpY 7j4K4SjveGbpZufOkJ59qRrckaW2TpcHMbwlGrKd1buL2TjtVOchbc+ShyJ0biXVBUbChyTndGFE qGO7ck7b1t2+/TrZHVHY6VxkqKw3KhsyUpUQASkOpUEkgDJGM6U5zgYC2SZtxtF3vaETV8N25q7S kuOWkq5jy9QAYQApvmIbAyM6QgLJ2K0pVt8Fsxp/F0O/QmLW09JvoCYL0plHRM8xCsttqKS4ohZQ kpT2dBwNRSUU+PxVdo7C2VORZKVvrkqM2EzKUXVhIWrU6hRydKc774rQZuUqNd27pHUhqW0+JDam 2kpShYVqBCANIAPixjxYxQWGzTLnZ4DqPC79lgtSnEuzLavU9LcwkctOhxKXUoxqzqCUhxRzlaUq r10ltT7vNmR4qIjMh9brcdvGllKlEhAwBsAcdw7u6tuBxJcbbAEFkQnIwdU8lEqAxI0rUEhRBcQo jIQnu8gr4h3+5W+RcHobyGFXBhyNJDbKAlTThBWkJxhIOB8UDHixQSVhvUu1wEt+ErpZobjriust jJLkhwBv4NZ5jYUlA3AySkuHbt7S0u6y7JfrxE6qbw7D8KSxzrI2VcxwKSOTq1tBSGxunuKeYeyN e1Xt9+n2yOqOx0rjJVrDcqGzJSlRABKQ6lQSSAMkYzpTnOBj7i8SXSLzsusSuc6p5fXRWpXwivjL HNSrClYGSMFWBnOBgLpOVEsPhKSJ82wTHr7PjKNmYDvwbXKIaCy40UoSXFYAACtiR2E4iYlx9zHX WF683O0TIc55L0qzo19VjSgJVlxo6UFCinOf4VWyfHAxeJLpF52XWJXOdU8vrorUr4RXxljmpVhS sDJGCrAznAxjiX+5QpEmS08hUqQrmLkvModeC8k60uLBUheSTqSQc4OcgUFtbW1A/KJxdAjQ4qGl IuzaCGhlpCWJGEIHckHCdwM4TgEAqBhYsyRZeEYU63uciTLnyWJCwAea022wUtqByCgl1epB7Ktt QOlOIyz36dYlvLgdKFPIKFqeiNPnSQUkDmJVgEKIIGMg4Oa/Yl/uUGRJeivIZVIVzFBDKAlK8kpW hOMNrTk6VIAKcnSRmgsMqFHtt1/KHBit8uNGacZaRknShNwYAGTudgO+qXU9AcuMfhS6KjWPmQ5G liTdOU8eWkLbWG9QVyx2ko7057XfuKgaBU9wj/HMj+i7h/g3qgaluG35zF8aNut3hKS408z0nLWv moW0pCxhBCviqUdiMYzQLJDjyOrkvN9UqI1zkwUkhT+O8kjB0JA1K0nVjuwNS0TXDUu1uWnip64w ZTry4YccMWQ3HQUGVH7KUcpQSdRByNsDSEjvFbfckwbu44hldulMPlQabK0KjLSr4o1EqBSRjc5G O/NZoTt1uEyXFtzC3n7kkodjxYwJcSFh0hKEjsgFsHCQMBPkoJvhN60t2HiUToU15wQElamJiGgW +qjgJALSsK1YOrJGNseOnCb1pbsPEonQprzggJK1MTENAt9VHASAWlYVqwdWSMbY8dQNrFyfcft9 rZefdnNclbDDXMW4hKkuYAAJ2LaTt5vkzS1i5PuP2+1svPuzmuSthhrmLcQlSXMAAE7FtJ283yZo J7hN60t2HiUToU15wQElamJiGgW+qjgJALSsK1YOrJGNseOnCb1pbsPEonQprzggJK1MTENAt9VH ASAWlYVqwdWSMbY8dQNrFyfcft9rZefdnNclbDDXMW4hKkuYAAJ2LaTt5vkzS1i5PuP2+1svPuzm uSthhrmLcQlSXMAAE7FtJ283yZoJ7hN60t2HiUToU15wQElamJiGgW+qjgJALSsK1YOrJGNseOnC b1pbsPEonQprzggJK1MTENAt9VHASAWlYVqwdWSMbY8dQNrFyfcft9rZefdnNclbDDXMW4hKkuYA AJ2LaTt5vkzS1i5PuP2+1svPuzmuSthhrmLcQlSXMAAE7FtJ283yZoJ7hN60t2HiUToU15wQElam JiGgW+qjgJALSsK1YOrJGNseOs9juPgrhKO94Zudm586Qnn2pGtyRpbZOlwcxvCUasp3Vu4vZOO1 WrWLk+4/b7Wy8+7Oa5K2GGuYtxCVJcwAATsW0nbzfJmslvv062R1R2OlcZKisNyobMlKVEAEpDqV BJIAyRjOlOc4GAtERzouPOKoQgQmCtq6oKWk6wwlLEg6GiQAE5A3CQcJAGAVAxMWZIsvCMKdb3OR Jlz5LEhYAPNabbYKW1A5BQS6vUg9lW2oHSnGhbuJbpbJcqWw6y5Jlauc9KjNSFr1BQV2nEqI1BSg rHxs75r4iX+5QZEl6K8hlUhXMUEMoCUrySlaE4w2tOTpUgApydJGaC7zmrZwv4SMS53OyuG/T4aH bazzXFMs8rQ2VqdQpKRzCcAnUcFXxU1oRrt7mbfI4ae4hvVpmwLpK5y7S3rbf2bbGSXWzsWlYyO5 Xi3qr2+/TrZHVHY6Vxkq1huVDZkpSogAlIdSoJJAGSMZ0pznAx9xeJLpF52XWJXOdU8vrorUr4RX xljmpVhSsDJGCrAznAwE1cIjfD8eQ/doMW8XNy7TIchyU8+U6mQ0SpJQtCiVKdVkqznCdhvnHZrn LgwHXIlym2G0dU4eoiLKpUhRCdLXZU2HdAGrJ0hOtR2K0pVGx77eYcdchWiSzJfWvmT4bcpKnsJL hSXUqAWQUaiNz2c52pH4qu0dhbKnIslK31yVGbCZlKLqwkLVqdQo5OlOd98UE1E4siDrumm3Thrn z3pQ8DoC9bbmnQyrDjXZb0q094+EVgJ8f5doMSTxdxNZzFZjRY0+U61LbbCEw0pcKcLx3tHCU6dy CU6ASShyvRL9OgyJL8bpWnpCtZcTEa1NKySC0dOWiCdi3pxgY7hjV62R0HQhzEYu85SEgDUvGAVH vVgZxnu1KxjUchLWD+JeKf6MR/jI1QNT0By4scKXRUaxcyHIwxJunKePKSFtrDeoK5Y7SUd6c9rv 3FQNBYeHr1cYwRb4V3XZmdTsiRLjOqacdSGwdBIUAsgIIbSSO04RkasiJuktqfd5syPFREZkPrdb jN40spUokIGANgDjuHd3VjiTJEB5T0ZzQ4ppxknAPYcQULG/lSoj+usFB0213KLa7/Hfmhzp+i5S +WgLUNcbQDpKkg7qG2RVpk8bWGQlSUTrvHScYDNvaGkDxD4atfgXgi3cZvzjcJMxnpY0PR0ykJzq aOc6knzR5KufvIcOekbx9a1+HXn1/CaOvMZauN12ejR8Tq6MTGE1ag3PiezvWWfGjyrnJfkMpab6 mK2gJw62snUHFHuR5PJUDH4pvEXwVyJy2xai4YehKRy9ZyvfGVAnvCsjGR3Gut+8fw56RvH1rX4d fvvIcOekbx9a1+HXXDDHCNuPZyz1Ms5vJyd/jC+SIi4y5+G3GTGUpuO0hfJ1auUFpSFBvJxoBCQN sY2rZ98DifrTL8Knn9UZerp2v4Xk8nVjT+b7OO7x9+9dP95Dhz0jePrWvw6e8hw56RvH1rX4dbYc jPFV5NqFt68iP0whlQab5pYCtXKLunXo/wDDqxjbGNqynjG+KfkPOTUuqkstsvh6M04l4N4KC4lS SFqGBhagVfPXWPeQ4c9I3j61r8OnvIcOekbx9a1+HQchY4ovMfiFV/RcHFXUqUoyXEpWcqSUnAI0 gaTgDGAMYG1YHb7cXk24OTFlVubDcVwBIcbSDlI1gaiEnuBOE+LFdk95Dhz0jePrWvw6e8hw56Rv H1rX4dByE8TXczbnMM9xUq6MrYlurSlRcbXjUncYSMAAYxgAAYr7a4rvTNtRb2pxRERFfhpbDSDh p5QU4nJTncpG+cjxYrrfvIcOekbx9a1+HT3kOHPSN4+ta/DoOSs8WXqPdIFyam6ZcCMmJFXyUfBN JSpISBpwdlK3IJ3r591V68GJtwnqDAjCHqDSA6WArVyubp5mjP8AJ1YxtjG1dd95Dhz0jePrWvw6 e8hw56RvH1rX4dBy08d8RkHNxTqUthxxfSs8x1TJSpsrXo1LKSkfGJrF7tOIDDlxTclKbl88PamW lKIfOXQklOUBR3ITgZ3766t7yHDnpG8fWtfh095Dhz0jePrWvw6DjVuvVws77j9tmPRHltKaU40r B0qGCP8A3HkIBG4BrYt/E93tMWNFgTlx2I0rrGkISnZ3Ro1EkZI0kgpJwQTkGuu+8hw56RvH1rX4 dPeQ4c9I3j61r8Og5KOLL0mdAmNz1NOW8EREMNIZbZySVaW0JCO1nfbcbHIrAviK7uxo0dy6TVtx pCpTQU8olLyjkuZ79WcnPiKlEbqOexe8hw56RvH1rX4dPeQ4c9I3j61r8Og5aOO+I0zWZiLkGnmX nJCeTGZbSXXE6VOKSlAC1EEjKgTuaryVhKQnyDFdy95Dhz0jePrWvw6e8hw56RvH1rX4dBw7m05t dx95Dhz0hd/rWvw6e8hw56Qu/wBa1+HQcO5tObXcfeQ4c9IXf61r8OnvIcOekLv9a1+HQcO5tObX cfeQ4c9IXf61r8OnvIcOekLv9a1+HQcO5tObXcfeQ4c9IXf61r8OnvIcOekLv9a1+HQcO5tObXcf eQ4c9IXf61r8OnvIcOekLv8AWtfh0HDubTm13H3kOHPSF3+ta/Dp7yHDnpC7/Wtfh0HDubTm13H3 kOHPSF3+ta/Dp7yHDnpC7/Wtfh0HDubTm13H3kOHPSF3+ta/Dp7yHDnpC7/Wtfh0HDubTm13H3kO HPSF3+ta/Dp7yHDnpC7/AFrX4dBw7m1+82u4+8hw56Qu/wBa1+HT3kOHN/8A4hePrWvw6DhvNpza 7j7yHDnpC7/Wtfh095DhzP8AGF3+ta/DoOHc2nNruI/Ihw5j+Mbx9a1+HX77yHDnpG8fWtfh0HDe bTm13L3kOHPSN4+ta/Dp7yHDnpG8fWtfh0HDebTm13L3kOHPSN4+ta/Dp7yHDnpG8fWtfh0HDebT m13L3kOHPSN4+ta/Dp7yHDnpG8fWtfh0HDebTm13L3kOHPSN4+ta/Dp7yHDnpG8fWtfh0HDebTm1 3L3kOHPSN4+ta/Dp7yHDnpG8fWtfh0HDebTm13L3kOHPSN4+ta/Dp7yHDnpG8fWtfh0HDebTm13L 3kOHPSN4+ta/Dp7yHDnpG8fWtfh0HDebTm13L3kOHPSN4+ta/Dp7yHDnpG8fWtfh0FR4JudtiwYU lybBalxVKJblrSkZK1EEBRGdiNx3GrDHvkaLeTdkcRW8y1HK1KltkLHjSRq7vm8WBjGBW77yHDnp G8fWtfh095Dhz0jePrWvw680+Gxmbv3t9HH+I5xhGM4xPSv04UHjSZbVRENxJcV51yRzVJjLSpKE 6VD+SSBuoYFX38hpyzdD/wDp4/8AzJFfvvIcOekbx9a1+HWH8gyiqNcv9WjH/aya7aenGnjth5fE a+WvnvydjpSlbcClKUClKUClKUClKUClKUClKUClKUClKUClKUClKUClKUClKUClKUClKUCvAFe/ 68AUCrpY7j4K4SjveGbpZufOkJ59qRrckaW2TpcHMbwlGrKd1buL2TjtVOchbc+ShyJ0biXVBUbC hyTndGFEqGO7ck7b1t2+/TrZHVHY6VxkqKw3KhsyUpUQASkOpUEkgDJGM6U5zgYC2SZtxtF3vaET V8N25q7SkuOWkq5jy9QAYQApvmIbAyM6QgLJ2K0pVt8Fsxp/F0O/QmLW09JvoCYL0plHRM8xCstt qKS4ohZQkpT2dBwNRSUU+PxVdo7C2VORZKVvrkqM2EzKUXVhIWrU6hRydKc774rQZuUqNd27pHUh qW0+JDam2kpShYVqBCANIAPixjxYxQWGzTLnZ4DqPC79lgtSnEuzLavU9LcwkctOhxKXUoxqzqCU hxRzlaUqr10ltT7vNmR4qIjMh9brcdvGllKlEhAwBsAcdw7u6tuBxJcbbAEFkQnIwdU8lEqAxI0r UEhRBcQojIQnu8gr4h3+5W+RcHobyGFXBhyNJDbKAlTThBWkJxhIOB8UDHixQSVhvUu1wEt+ErpZ objriustjJLkhwBv4NZ5jYUlA3AySkuHbt7S0u6y7JfrxE6qbw7D8KSxzrI2VcxwKSOTq1tBSGxu nuKeYeyNe1Xt9+n2yOqOx0rjJVrDcqGzJSlRABKQ6lQSSAMkYzpTnOBj7i8SXSLzsusSuc6p5fXR WpXwivjLHNSrClYGSMFWBnOBgLpOVEsPhKSJ82wTHr7PjKNmYDvwbXKIaCy40UoSXFYAACtiR2E4 iYlx9zHXWF683O0TIc55L0qzo19VjSgJVlxo6UFCinOf4VWyfHAxeJLpF52XWJXOdU8vrorUr4RX xljmpVhSsDJGCrAznAxjiX+5QpEmS08hUqQvmLkvModeC8k60uLBUheSTqSQc4OcgUF8upt3D8i7 Px7lcLG87xBcIqXLVFSpRZaLRS3nmtlCAXD2U7K2z8ROMfBfDptHF0PU7bJFyi30QXm3pbSOShtx AU4224QpxS8qSkgdnQSBqKSikW+/TrZHVHY6VxkqKw3KhsyUpUQASkOpUEkgDJGM6U5zgY12bnNj 3du6okrM9t8SQ+4dai6FatR1Zyc775zQS1nZVHtvFrKygqbtyUEtrStJImRhspJII+cEg1XqnoDl xj8KXRUax8yHI0sSbpynjy0hbaw3qCuWO0lHenPa79xUDQKnuEf45kf0XcP8G9UDUtw2/OYvjRt1 u8JSXGnmek5a181C2lIWMIIV8VSjsRjGaBZIceR1cl5vqlRGucmCkkKfx3kkYOhIGpWk6sd2BqWi a4al2ty08VPXGDKdeXDDjhiyG46Cgyo/ZSjlKCTqIORtgaQkd4rb7kmDd3HEMrt0ph8qDTZWhUZa VfFGolQKSMbnIx35rNCdutwmS4tuYW8/cklDseLGBLiQsOkJQkdkAtg4SBgJ8lBN8JvWluw8SidC mvOCAkrUxMQ0C31UcBIBaVhWrB1ZIxtjx04TetLdh4lE6FNecEBJWpiYhoFvqo4CQC0rCtWDqyRj bHjqBtYuT7j9vtbLz7s5rkrYYa5i3EJUlzAABOxbSdvN8maWsXJ9x+32tl592c1yVsMNcxbiEqS5 gAAnYtpO3m+TNBPcJvWluw8SidCmvOCAkrUxMQ0C31UcBIBaVhWrB1ZIxtjx04TetLdh4lE6FNec EBJWpiYhoFvqo4CQC0rCtWDqyRjbHjqBtYuT7j9vtbLz7s5rkrYYa5i3EJUlzAABOxbSdvN8maWs XJ9x+32tl592c1yVsMNcxbiEqS5gAAnYtpO3m+TNBPcJvWluw8SidCmvOCAkrUxMQ0C31UcBIBaV hWrB1ZIxtjx04TetLdh4lE6FNecEBJWpiYhoFvqo4CQC0rCtWDqyRjbHjqBtYuT7j9vtbLz7s5rk rYYa5i3EJUlzAABOxbSdvN8maWsXJ9x+32tl592c1yVsMNcxbiEqS5gAAnYtpO3m+TNBPcJvWluw 8SidCmvOCAkrUxMQ0C31UcBIBaVhWrB1ZIxtjx1nsdx8FcJR3vDNzs3PnSE8+1I1uSNLbJ0uDmN4 SjVlO6t3F7Jx2q1axcn3H7fa2Xn3ZzXJWww1zFuISpLmAACdi2k7eb5M1kt9+nWyOqOx0rjJUVhu VDZkpSogAlIdSoJJAGSMZ0pznAwFoiOdFx5xVCECEwVtXVBS0nWGEpYkHQ0SAAnIG4SDhIAwCoGJ izJFl4RhTre5yJMufJYkLAB5rTbbBS2oHIKCXV6kHsq21A6U40LdxLdLZLlS2HWXJMrVznpUZqQt eoKCu04lRGoKUFY+NnfNfES/3KDIkvRXkMqkK5ighlASleSUrQnGG1pydKkAFOTpIzQWiIiPaOPO KrVDispYS1dWG1LBWtptDEjCUlROM4TlXxuzjOCoKjbBcbjb7QVou0qyW4Pr5kuDqEiUspRhsALT zAgDVuQEBxW+VpSqIs9+nWJby4HShTyChanojT50kFJA5iVYBCiCBjIODmtiPxTc4sdcdCbetlb6 5HLetsZ1KFrCQooC2zoBCU7JwNhtQTs68W1XDLM9VgiuolXu4OMRHHVpZjoUiMdIDZQSRlIByAAD 2TkacirHarLPuzMpq1mMzdJEKPIvDso8wNEAhKYoBCgFJKirY6k6QMKzXo/FV2isLjNuRTFW+uSY zkJlxnmrCQVBtSCkHCQBgdkZAwFHJF+vlqkSmXHlplF9a3DKZSt5l/OFrSpYKm3MgZUkhWUpycpG AsKrHarLPuzMpq1mMzdJEKPIvDso8wNEAhKYoBCgFJKirY6k6QMKzoSLREav994dKNMWBKkFq4rA 1R0oVoy6QBqQrCQRjIURoBJKHI1HFd5Q/Kf6pCnpL65KnFx21KbeUcqcaJTlpZOO0jSeynzRjUm3 mfcep6p/X1MpUt/ShKeY6rOVKwBnGVYHcnUrAGo5DfsH8S8U/wBGI/xkaoGp6A5cWOFLoqNYuZDk YYk3TlPHlJC21hvUFcsdpKO9Oe137ioGgsPD16uMYIt8K7rszOp2RIlxnVNOOpDYOgkKAWQEENpJ HacIyNWRE3SW1Pu82ZHioiMyH1utx28aWUqUSEDAGwBx3Du7qxxJkiA8p6M5ocU04yTgHsOIKFjf ypUR/XWCg9I/kdbS94daUVhK4kFJKFlKgC0ruIwQfnG9Slsu7lisPFd6dcmzXLfc34jDb8x1xIbC kBIwpRGxPfjOM71HfkX/AIa9f6tA/wCUqujtWG1tRZ0VMRJYnvLfkoWoqDi141Hc7ZwNhtQaFmvF wnzrzapXSpn28tgPtNq5SuYjUk6SrO3jGrfyiq3w9xPdjwfZnXZjMm43F2RyguOp11YSs7BIUkHG 5KipISMDB76u9ttEGztLRCYLfMVrWpS1LUo4xupRJO2252rTHCVjDDDKYRQ3HcW6yEPOJ5al/HCS FZCT40jb5qDnafyh3E3OHdeSvEmzE9MFqMdpwSVILqx4kgJO/fuBnfNWSfxldYl5lQI0ETTb0xy+ iPEdWqQXBklBTkNgJ3GrOcHFTsXg6wQm+WxACUdIuEUl1ahyVqK1J3V41EnPf89fbnCVjdLJXC1c ltDQBdWQtKPiBYzhePFqzQQ/FDlwc404YtrU1bEKWp9TrTSloK+WgK3UlaTjB2HiO51d1Qcnjm7S +FbU9ojsu3SDcluraC0qaLKF6C2dWQcgZ7/mxXQpFqhS7jCuD7OuVC19O5rUNGsYVsDg5A8eajDw Tw72f/hwASl5CQHnAEpdBS4ANWwIJ2HdkkYJoIH8ntxmzbldUypb76UQratKXXVLCSuPlRGTsSdz 5TW9aeJrrPsa+I1sQ/BIakO8hOsPoDZUBvulROk52TjI76nrZYbZZ3XnYEbkrebaacOtSspaToQN ye5O3z+PNYY/DFmizVS2YKA4deAVKUhOv4+lBOlOfHgDNBTZv5QbvAtD77kaCqSq2sXKOUoXoShx 1KChY1ZJGrvBH6q+b5xPfzfE2lt+LFXHu8KOtbTSlBxLySsA5UNhpIOMasj4u4Nt9xnD5gyYZt4L ElKEOJLqySlKtSUg6spSCM4BA+as8nhizy5ciU9D1PyHWnnHA6sK1tAhtSSD2SAT3Y+egrp4yuMe z8S3d9mKti1TXYbLLaFBSyFJSlSlFR27W+B9FaN24kuq7lEtT7qWpcO/QWnnYalNtvtuoUrSRknG 24JIO1XVqwWpqJPipiILE91b8lC1FQcWvGo7k47h3d3irXRwpZW2mWxDzyZSJaFKdWpXNQMJUVE5 VgbYJI+ag2L9Nm26xy5duhmbLbRltgZ7RyB4tzgZOB34xVQTx/KFpU7+9XZapzMNCUx3ULaLgJy4 zurI0nASo6vmNWi38M2+DwymwuNJfh4WFIWDg6lFXjJIwTtuTsN6/U8K2YRX46ohWl9aXHVuPLW4 pSfinWSVZHi328VBTZfFd0Td7JKmMSoyGPCXOYCHGEy0tMhSF6F74PiznBzWZvj+5sWSXcpdsU40 mC3KZdRGdZbC1rCeWVL2URqSdSdiM4q2NcK2Rl2M6iCnmRlOqbUpalEl0YcKsntlQ7yrNfjHCdjj NPtNwEKQ+1yFpcWpz4POdA1E6U53wMAUFe4mm8UQEWdC5tva6i7R44cjtL+ESrJwpJVskEHICjqB G6cEGd4iZlsoReY0t5Hg2PIdVESTokktnSFAHxEZGxr7HCVkTHLPREgvIf5innC5zEDCFayrVkDY b7VNEA7EUHPWZUy32/hG6ouMuTIukhlqW268paFh1JUSEZwjQe7SB89RPB17u88cMx7rIltwXS+W pPUEqlvIWSErVnOkDYA95T4xXQonDNogSm5EaHoca1coFxakNau/QgkpRn/wgV+N8L2Zm2wre3D0 xoLwfjJDq8tryVZCs571HvPjoM9kt79qtDEKROenOt6tUh4krXlRO+Se4HHf4qkMmtTwXD8MeFuT +/un6bm6j/B6tWnGcd/jxmtugUpSgUpSgUpSgUpSgUpSgUpSgUpSgUpSgUpSgUpSgUpSgUpSgUpS gUpSgUpSgUpSgUpSgUpSgUpSgUpSgVy38gv/AGW5f6rG/wCbJrqVct/IL/2W5f6rG/5smg7JSlKB SlKBSlKBSlKBSlKBSlKBSlKBSlKBSlKBSlKBSlKBSlKBSlKBSlKBSlKBXgCvf9eAKBV0sdx8FcJR 3vDN0s3PnSE8+1I1uSNLbJ0uDmN4SjVlO6t3F7Jx2qnOQtufJQ5E6NxLqgqNhQ5JzujCiVDHduSd t627ffp1sjqjsdK4yVFYblQ2ZKUqIAJSHUqCSQBkjGdKc5wMBbJM242i73tCJq+G7c1dpSXHLSVc x5eoAMIAU3zENgZGdIQFk7FaUq2+C2Y0/i6HfoTFraek30BMF6UyjomeYhWW21FJcUQsoSUp7Og4 GopKKfH4qu0dhbKnIslK31yVGbCZlKLqwkLVqdQo5OlOd98VoM3KVGu7d0jqQ1LafEhtTbSUpQsK 1AhAGkAHxYx4sYoLDZplzs8B1Hhd+ywWpTiXZltXqeluYSOWnQ4lLqUY1Z1BKQ4o5ytKVV66S2p9 3mzI8VERmQ+t1uO3jSylSiQgYA2AOO4d3dW3A4kuNtgCCyITkYOqeSiVAYkaVqCQoguIURkIT3eQ V8Q7/crfIuD0N5DCrgw5GkhtlASppwgrSE4wkHA+KBjxYoJKw3qXa4CW/CV0s0Nx1xXWWxklyQ4A 38Gs8xsKSgbgZJSXDt29paXdZdkv14idVN4dh+FJY51kbKuY4FJHJ1a2gpDY3T3FPMPZGvar2+/T 7ZHVHY6Vxkq1huVDZkpSogAlIdSoJJAGSMZ0pznAx9xeJLpF52XWJXOdU8vrorUr4RXxljmpVhSs DJGCrAznAwFljzLtF/KHcbPGuU2z20XOQ7MYtctbbbDSFKU6pAAAOltBx2ckJA09wrUl32a3aPdB GUiNPu92mmYWk5S4gJZWGiFZy3l1eUHIVtq1aRitN3Oa1OemiStUp9LqXXXDrUsOpUlzJOckhSt+ /fPfWS23mfaOb0T/ACuZgnKEq0qGdK06gdK05OlacKTk4IyaC2RER7Rx5xVaocVlLCWrqw2pYK1t NoYkYSkqJxnCcq+N2cZwVBUTwfcrsi6xrbGvV0t9tW6X5ghSltaGkp1OuAA4Kg2hR7iTpAwdhUZZ 79OsS3lwOlCnkFC1PRGnzpIKSBzEqwCFEEDGQcHNYG7lKZnPTGVIaeeS6hfLaSlOlxKkLASBpSCl ShgAYztjAoJ6JcHbujjW5SEoS9Lh89xLYISFLnR1EDJO2T5aq1T0By4x+FLoqNY+ZDkaWJN05Tx5 aQttYb1BXLHaSjvTntd+4qBoFT3CP8cyP6LuH+DeqBqW4bfnMXxo263eEpLjTzPScta+ahbSkLGE EK+KpR2IxjNAskOPI6uS831SojXOTBSSFP47ySMHQkDUrSdWO7A1LRNcNS7W5aeKnrjBlOvLhhxw xZDcdBQZUfspRylBJ1EHI2wNISO8Vt9yTBu7jiGV26Uw+VBpsrQqMtKvijUSoFJGNzkY781mhO3W 4TJcW3MLefuSSh2PFjAlxIWHSEoSOyAWwcJAwE+Sgm+E3rS3YeJROhTXnBASVqYmIaBb6qOAkAtK wrVg6skY2x46cJvWluw8SidCmvOCAkrUxMQ0C31UcBIBaVhWrB1ZIxtjx1A2sXJ9x+32tl592c1y VsMNcxbiEqS5gAAnYtpO3m+TNLWLk+4/b7Wy8+7Oa5K2GGuYtxCVJcwAATsW0nbzfJmgnuE3rS3Y eJROhTXnBASVqYmIaBb6qOAkAtKwrVg6skY2x46cJvWluw8SidCmvOCAkrUxMQ0C31UcBIBaVhWr B1ZIxtjx1A2sXJ9x+32tl592c1yVsMNcxbiEqS5gAAnYtpO3m+TNLWLk+4/b7Wy8+7Oa5K2GGuYt xCVJcwAATsW0nbzfJmgnuE3rS3YeJROhTXnBASVqYmIaBb6qOAkAtKwrVg6skY2x46cJvWluw8Si dCmvOCAkrUxMQ0C31UcBIBaVhWrB1ZIxtjx1A2sXJ9x+32tl592c1yVsMNcxbiEqS5gAAnYtpO3m +TNLWLk+4/b7Wy8+7Oa5K2GGuYtxCVJcwAATsW0nbzfJmgnuE3rS3YeJROhTXnBASVqYmIaBb6qO AkAtKwrVg6skY2x46z2O4+CuEo73hm52bnzpCefaka3JGltk6XBzG8JRqyndW7i9k47VatYuT7j9 vtbLz7s5rkrYYa5i3EJUlzAABOxbSdvN8mayW+/TrZHVHY6VxkqKw3KhsyUpUQASkOpUEkgDJGM6 U5zgYC0RHOi484qhCBCYK2rqgpaTrDCUsSDoaJAATkDcJBwkAYBUDExZkiy8Iwp1vc5EmXPksSFg A81pttgpbUDkFBLq9SD2VbagdKcaFu4lulslypbDrLkmVq5z0qM1IWvUFBXacSojUFKCsfGzvmvi Jf7lBkSXoryGVSFcxQQygJSvJKVoTjDa05OlSACnJ0kZoLRERHtHHnFVqhxWUsJaurDalgrW02hi RhKSonGcJyr43ZxnBUFRPBcrkz7gwGGVF+1zgXVo1LQkRHjhOdk5OMkDO2AQCoGMs9+nWJby4HSh TyChanojT50kFJA5iVYBCiCBjIODmslu4kuNqlypMQQkOytQcK4DCwAoKCkpCkEISQpQKUgAg4xj FBtxEW2BwxFuEu2onLmTH4y9by0KZQ2hlQLRSQAs85W60rHZT2e8G4XuREtE+9zxd7naZkniO4sq kW2OHHHG2y0QgqLrZSkFxRwMhRIz8ROKJF4kukPndO6yjmuqeGIzXwLh71s9n4FWw3b0nsp80YyI 4quyX5TzjkWQqU+uS4JUJl9PNWcrUlLiCEFW2dIGdKc9wwEtYGHbHxLfbM81FckNQ7lHdfCSop5c Z8EIJ7gSBvgKwMZAKgYmystXOPIt8hpDbbaVSBPCQOmwACXD3qbJ0pxuoKKdAJJQ5jt3Et0tkuVL YdZckytXOelRmpC16goK7TiVEagpQVj42d81gmy56epgSk9P++lOvxwwlnDoyCFJAGNPaAT3J1Kw BqOQ37B/EvFP9GI/xkaoGp6A5cWOFLoqNYuZDkYYk3TlPHlJC21hvUFcsdpKO9Oe137ioGgsPD16 uMYIt8K7rszOp2RIlxnVNOOpDYOgkKAWQEENpJHacIyNWRE3SW1Pu82ZHioiMyH1utx28aWUqUSE DAGwBx3Du7qxxJkiA8p6M5ocU04yTgHsOIKFjfypUR/XWCg9JfkdYbkG/MvNpcaciQELQsApUC0o EEHvFas23wo/APHDzMNht1u8uMIcQ2kKS0HmSEAgbJ+bura/I662wL6884htpuJBUtayAlKQ0okk nuFdBiu8MXVEmDDctExL6i/IjsqacDisjK1JGcnOnc+PFBS7rfLmnifwVIfZkoi323IQ45GbJCXW 1qUACDpII2I7Q8tbvDXEd4f4hjQ7tLJMkvcoMoadjPaN/g3EEKTpHeFas/Mauq7TbnJKpDlviLfU 4h0uKZSVFaAQhWcZykEgHvGa/WbXb48pyUxAitSXPjvIZSlav1kDJoKHxTxZe7XxDOtdvc1PANSm EltJAZQ2tTqc48ZQAM79rbxVCXbiKXeo7EpSm3IspF4DBWw3rSyiPhASrGpPcScHJ7jkYrrK7dBc l9W5Djrk6OXzlNgr0ebnvxudqwix2gMtMi1wg00laW0dOjCAsYWAMbBQ2OO/x0FI/Jn/ABpd/wDU LV/hq3LJxBNlWcXqffGI6nG5Szblx0KLfLKviAELJSE5IJOc+Lvq2cq02Rl6Xy4UBrShLr2lDSdK eygKVtsNgPJ3Csjdst7Up2U3BjIkPDDrqWkhax85xk/10HLbhxrf40ScqNNcKVWtmfHW6llbiNT6 EbhKAkZSo9k6iNt6lrrxNfPDHEEa2TGFtxZUJthCltIVpWhRcS2pQwVlQ2Cs+PA8VXBq2cPMS1Qm oNrbkrjnWwhpsLUyVb5SBko1f1ZrYFltQbdaFshBt5KUupEdOFhIwkKGNwBsM91BQk8XXaRHtcSO /LU7ImSY77pjMtvtFtIUGyFq5RVvurbIGwB2rNxNcblO/I65cJEgMTClHNMR1C0ODmhBGpORgjfs n5u7INzmQ7HEtBamxrezbWiCUPNoSygk4Gx7I3P9tbi4kZyIYi47SoxRoLKkAoKfJp7sfNQcuulw uNhvHG1xhzTzYng3UXG0Ev5SE9rbAyCrOkDcjGMVLMcTXx/id1CcJiNXfwephxTCGy1j4wKlBwuH 4wABBHdVzVZbUtp5pVshqbfCEvJLCSHAj4gUMb6cDGe7xVkNugmd1xhRjMAwJBaTzMeTVjNBTOLL /dIHEsyHEuaYjDNjXNQktIVrdSs4AKhncDGPJnx71ps3673aPxU7Ik8tiHaWX0Qyw2pGt2KVqCtS SSArxH/htVylcN26bffC8toSHulEXlOpStrSF6wrSR8bPjzWy6zaG5S2HmoSJFxSULbWEBcpKU4I IO6wEn58A0HL08V36PYbvLYnpaRbIVscZZRGbCMuto1DZOw3Ow7tsYAxU3I4luUC63m1SLg66pmX DjxnGmG0uKU8gq0gkaUjI+MoKwM953q6eBLTyXmfBcLlPJQh1HTo0rSjZAUMbhOBjPd4q+3rRbJJ fL9uiOmQUl8uMpVzdIwnVkb48We6g53auJ7/AHK92y1uXPla7jPiuutNtqK0stoUk5KMZyTuAM+S t21cSXqZxHG4dclqMyNPkdY7ykZXHQAUbYwArUBkYO1XZizWuM626xbYbTja1OIW2wlJSpQAUQQN iQACfHio+LZ7Xw/LnXyXNKpEgJS/NmLbRhIwAnICUgd3i3OKCqcScV3a2q4yQxODKoHQ9CC2g6eZ jmYyO1nfvzj5qzjiS8McYdPNllMFy49KwY6GnmVAjZteMONueMkkj/w43q6yrRbJq1rlW6I+taAh anWUrKkg5AORuMgHFfptdvM7rjBjGZjHUclPM9bGaDnETjDiORb3Z6lhtD0Sc5odMdIYW0lRRy05 5isacK1A94PdViiQH5/D9p4jlzi/dY0Fclhx7Q20lbrIyFBIHZHfn9dWTwRbec+94OicyQkofXyU 6nUnvCjjcH56+w5BhqjQAuOwXElEeOClOpKRuEJ8YA8ncKCo8F3+5z7kuDdpDypJiJkBpTTSkKGr HMbdbwCg+Qgn/wAR3rWHEl3Y4wMabL0wXLj0rBjoaeZUCNm14w42548kkDzcb1dolst9vU4qFBjR lOHKyy0lGr9eBvXw7BtbU5Nwdiw0SyQhMhbaQ4SdgArv37sUFCsvFfEU8tSVllCJTUs8uU4w22yt vOjQArmKAxheobZz3b1jh8U34224tOz0IuaICJDQlhgMbrCS428ghBSc4AUO/HaO9X4R7PCuiVBm CxcJmrBCUJdfwMq+dWO81gt7XDpelRLci1c1QIkMxg3k/wD3pH/vQUNfEU+Sq3xpTjipTV+htOMz YjJWylaVHZaRpVnGQpKUqH9ea+m+Mr6qA3M6lJXNh3F1UcNIHRKYCtBG2TkgA6s5zXQ2rLamWW2W rZDbbadDyEJYSEocHcsDGyh5e+vsWq2hyS54Pi65SSmQrkpy6D3hRx2h+ugqfC98u0q/wYM6YJLU qxM3E5aSjQ4VBJAwO7B+nux3VC2+6XO2wrty7g+tyRxQbeqQ+EK5CCQC5jTjOMDB7I2wB4+ktW+E w8h5mGw262yGELQ2kKS0NwgEDZPzd1aM1XD0Vctucq2MqfQl2Ul8tpLiM6QpYPeMkAE+Pagrzd0l 3T8n/FIlr5qogmxEP6QOchCDheBt48bbbVXovFd2stg5UZ9E1tqwRpTXwYxHWVBsp278A5380/qr qKYUREIwkRWExSgoLAbAQUnvGnux81fDFrt8VDiI8GM0l1IQ4G2kpC0gYAOBuANqChr4mv0ZlyK6 8BzLjEioluqjqeabdBKlLQ2pSEkY2yNwod9SE27XBiXarUzf2Xky5Ult64ttN6meWjUG1DdGvxE4 Hd3CrS3Z7Y1CchN26IiI5uthLCQhX604wa/VWi2Lgpgqt0Qw0nKY5YSWwfmTjFBzePxfxBcmecJn SaOHXbgpCWEHU6h1aQrtA4BCQcd2Dt5a+pXGd/t0Vx4yESlPWBm5ISWUpDTi3EoOMDcAKzuTuPEN q6Qu2W9xalrgxlKUx0xUWkklr833fF/8PdRNst6FpWiDGSpLHTBQaTkNfm+74vzd1BXLDNvdxZvM J+VoeaCBEkuKjqeSVoJ7aGipIwQCMjcEd9UriDjC73XhtxprlNrt0ZPhZD8Zt1Kn+clsIKVJI7wV 7DyeSutQ4EO3slmFEYjNE5KGWwhOfLgVjctFsdRIQ5boi0SVBT6VMpIdIOQVbdog+WgpTPE98f4n eQjCYjV36BTLqmG2+Vj4wKlBxTn8oAAgjuqCP5Q73GZW885rZhNOxZSuUkZlHm8o7Du+DTnG3arq htsAzxOMKMZgGBILSeZjuxqxmsSrJaltPNLtkJTb6+Y8gx0EOL85QxufnNBAXniaXauDZD7bb710 jQ2nFrXFWGypWgKUFaQg41ZwD4jtsag5fE18jXDwYzcw8G7zCipnFlBLrbzalKSQBp2IHdg/PXSF IQtstqSlSCNJSRkEeTFaiLPbGmGmG7dEQyy6Hmm0sJCUODuWBjZXzjeg5Rc7tep17hlqYTcLdNu0 eO/y0alBtlJGU40kncd1W/hfi1d+uD8x6Y0xbg3HjMtr0pDkpadSwCdyofFxnfyVZH7HBcyuOw1E la1OplMMN8xC14C1AqSRlQGCcbitODwhabfa4VvYZPIiSUyklWCpTo3Cicd/6sd2O7agov5T5UlF 1uLLTwaQmytuEoaQFrzKSgpK9OvTvnSCBkfrzb+IJDvDditcO2KRHS9MYhl8NIHKSs9pzSAEZ28g GT3VOyrVbpzi3JdviyFrbDSlOspWVICtQSSRuNQBx5d6zyI7EphbEhlt5lYwptxIUlQ+cHvoOeQ+ Jb7OvtptYuHLQudcIjkhLKCZCGUpKF4IwDue7bI7j3VHxuNeIrhbLdynND67a9LW8kMoS4tDqkDW XSEhACQVad9/JXTUWyA0qMpuDGQYoUI5S0kFkKGDp27OR3476xKslpVGZjKtcIsMEqaaMdGlsk5J SMYG++1BXOJLhIVbOE5C244dlXWGHUlCHkp1Ak6SQQD5FJ38hrR4Z4kvEjiGNDu8skyedygyhp2M 9o3+DcRhSSkd4Vqz8xq9PxI0oNCRHae5Lgda5iArQsdyhnuI8tY2LZb40tyWxBjNSXPjvNtJStX6 1AZNBReMuLLha5N0NslrCrZyC62tDYb+EIwncFayRk9kpAHlI3jLJPuLfFi7XDnLisTr/dOeUNoU VaENqTjUDjx/TXSpdmtU90uzLbDkOKTpK3mErJSNwMkd1fTdqtzUlMhu3xUPpcW6HUspCgtYwtWc ZyoAAnx4oKSxxPfH+J3UJwmI1d+gUy4thDZbx8YFSg4XD8YAAgjurQTxtdhOhyYz6pUKWxNW226h tJUplClApQkakAqTgalKJGe7FdHNugmeJxhRzMAwJBaTzAPJqxmsTVltTEkSWbZCbfClKDqGEhQU oYUcgZyR30HJn7zd2L3HvjNxTJlN8PsSpAS0jdBfSVtkYwMBR32OBV7sd7n3W2X67tyWumDrqbbz QEtpS2nGsnAOCrc5O2PFUlN4XtkmK4xHYbgc1tTLjkRhpK1tKzqbyUHCSTnbG9SFut0W1W1iBDa5 cdlIQhOfF8/znvoOU3Hii7OcK3Zi4PlcxMRiQlqTFYeaUC8hJcbWkaFIOdgpJI7wo4qWk8VXk3hO m4IZb90iLZ0fKRksDGVZIz2s9/zjBHjvSbFZ0MPMJtMEMvkF1sR0BLmDkahjB333qOd4Pt714Tcn XZDi0SRKDaigjmDOk6tOsgZ2SVYHkoKZa+Mb+i2WCbIlCYZ8a4LWyWUJyphKlIwUgHJxj9XizvX0 njHiONw7MnKUHiq2NSmlOljW24pYSSlDaieXhRIKxnKSDXRmbTbo/Tcm3xG+l1dPoZSOTq+Np27O fHjvozabbGbfQxb4jSXxh5LbKUhz/wC4Ab9/joKnwcFe7fi7mTBLUBDBfAA1/Bq8Q2z4tvJVVsPE d7NoQ3GmtxW2OH5Nw5bMRpKeYiQ4BgBOBkAA4HlPec11mJboMBS1Q4UeOXAkLLLSUFQSMJBwN8DY eSsTdktLKClq1wm0llTBCWEAFpRJKO74pJJI7smgwcPXZu7WiG6qQyuYYrLshptQJbUtAUMjORnx Zqh/kG/7Ncv9Wjf82TXSItvhQlrVFhx2FLShCi00EFSUDCQcDcAbDyCub/kG/wCzXL/Vo3/Nk0HY 6UpQKUpQKUpQKUpQKUpQKUpQKUpQKUpQKUpQKUpQKUpQKUpQKUpQKUpQKUpQK8AV7/rwBQKuljuP grhKO94Zulm586Qnn2pGtyRpbZOlwcxvCUasp3Vu4vZOO1U5yFtz5KHInRuJdUFRsKHJOd0YUSoY 7tyTtvW3b79OtkdUdjpXGSorDcqGzJSlRABKQ6lQSSAMkYzpTnOBgLZJm3G0Xe9oRNXw3bmrtKS4 5aSrmPL1ABhACm+YhsDIzpCAsnYrSlW3wWzGn8XQ79CYtbT0m+gJgvSmUdEzzEKy22opLiiFlCSl PZ0HA1FJRT4/FV2jsLZU5FkpW+uSozYTMpRdWEhatTqFHJ0pzvvitBm5So13bukdSGpbT4kNqbaS lKFhWoEIA0gA+LGPFjFBYbNMudngOo8Lv2WC1KcS7Mtq9T0tzCRy06HEpdSjGrOoJSHFHOVpSqvX SW1Pu82ZHioiMyH1utx28aWUqUSEDAGwBx3Du7q24HElxtsAQWRCcjB1TyUSoDEjStQSFEFxCiMh Ce7yCviHf7lb5FwehvIYVcGHI0kNsoCVNOEFaQnGEg4HxQMeLFBJWG9S7XAS34SulmhuOuK6y2Mk uSHAG/g1nmNhSUDcDJKS4du3tLS7rLsl+vETqpvDsPwpLHOsjZVzHApI5OrW0FIbG6e4p5h7I17V e336fbI6o7HSuMlWsNyobMlKVEAEpDqVBJIAyRjOlOc4GPuLxJdIvOy6xK5zqnl9dFalfCK+Msc1 KsKVgZIwVYGc4GAsseZdov5Q7jZ41ym2e2i5yHZjFrlrbbYaQpSnVIAAB0toOOzkhIGnuFaku+zW 7R7oIykRp93u00zC0nKXEBLKw0QrOW8uryg5CttWrSMVpu5zWpz00SVqlPpdS664dalh1KkuZJzk kKVv37576yW28z7Rzeif5XMwTlCVaVDOladQOlacnStOFJycEZNBbGHZ1r/KJceH7Xd7pbLKzdJB fbhTFo5UdpSi4sbnKktNk9xJ0gbnat/gsG7cXQ+JFG1ruU2+gusPSWm+mQXELUttpxWpxStakpxn ToOMqKVI55EmSIDynozmhxTTjJOAew4goWN/KlRH9e1IUyRbp8edEc5cmM6l5peAdK0kEHB2O4Hf QTVnZVHtvFrKygqbtyUEtrStJImRhspJII+cEg1XqnoDlxj8KXRUax8yHI0sSbpynjy0hbaw3qCu WO0lHenPa79xUDQKnuEf45kf0XcP8G9UDUtw2/OYvjRt1u8JSXGnmek5a181C2lIWMIIV8VSjsRj GaBZIceR1cl5vqlRGucmCkkKfx3kkYOhIGpWk6sd2BqWia4al2ty08VPXGDKdeXDDjhiyG46Cgyo /ZSjlKCTqIORtgaQkd4rb7kmDd3HEMrt0ph8qDTZWhUZaVfFGolQKSMbnIx35rNCdutwmS4tuYW8 /cklDseLGBLiQsOkJQkdkAtg4SBgJ8lBN8JvWluw8SidCmvOCAkrUxMQ0C31UcBIBaVhWrB1ZIxt jx04TetLdh4lE6FNecEBJWpiYhoFvqo4CQC0rCtWDqyRjbHjqBtYuT7j9vtbLz7s5rkrYYa5i3EJ UlzAABOxbSdvN8maWsXJ9x+32tl592c1yVsMNcxbiEqS5gAAnYtpO3m+TNBPcJvWluw8SidCmvOC AkrUxMQ0C31UcBIBaVhWrB1ZIxtjx04TetLdh4lE6FNecEBJWpiYhoFvqo4CQC0rCtWDqyRjbHjq BtYuT7j9vtbLz7s5rkrYYa5i3EJUlzAABOxbSdvN8maWsXJ9x+32tl592c1yVsMNcxbiEqS5gAAn YtpO3m+TNBPcJvWluw8SidCmvOCAkrUxMQ0C31UcBIBaVhWrB1ZIxtjx04TetLdh4lE6FNecEBJW piYhoFvqo4CQC0rCtWDqyRjbHjqBtYuT7j9vtbLz7s5rkrYYa5i3EJUlzAABOxbSdvN8maWsXJ9x +32tl592c1yVsMNcxbiEqS5gAAnYtpO3m+TNBPcJvWluw8SidCmvOCAkrUxMQ0C31UcBIBaVhWrB 1ZIxtjx1nsdx8FcJR3vDNzs3PnSE8+1I1uSNLbJ0uDmN4SjVlO6t3F7Jx2q1axcn3H7fa2Xn3ZzX JWww1zFuISpLmAACdi2k7eb5M1kt9+nWyOqOx0rjJUVhuVDZkpSogAlIdSoJJAGSMZ0pznAwFoiO dFx5xVCECEwVtXVBS0nWGEpYkHQ0SAAnIG4SDhIAwCoGJizJFl4RhTre5yJMufJYkLAB5rTbbBS2 oHIKCXV6kHsq21A6U40LdxLdLZLlS2HWXJMrVznpUZqQteoKCu04lRGoKUFY+NnfNfES/wBygyJL 0V5DKpCuYoIZQEpXklK0JxhtacnSpABTk6SM0FoiIj2jjziq1Q4rKWEtXVhtSwVrabQxIwlJUTjO E5V8bs4zgqCo2wXG42+0FaLtKsluD6+ZLg6hIlLKUYbAC08wIA1bkBAcVvlaUqiLPfp1iW8uB0oU 8goWp6I0+dJBSQOYlWAQoggYyDg5rYj8U3OLHXHQm3rZW+uRy3rbGdShawkKKAts6AQlOycDYbUF hj8YxOgkMxrreuHOZdJU0MWloKb5bobCEEh1r4mggbYwdsVgs/V2zi3iG2zuTJndLc2pEteXFlSI z+opUrzlAEqxqOMZAKgYWPfbtCjreSzFVFkPrUkSLcy6yHcJK+WlaClBwUZCANtGdgmsdu4lulsl ypbDrLkmVq5z0qM1IWvUFBXacSojUFKCsfGzvmg24iLbA4Yi3CXbUTlzJj8Zet5aFMobQyoFopIA WecrdaVjsp7PeDLX1hq5cbcVW+Q0httu4y5AnhIHTYcIJcPepsnSnG6gop0AqJQ5XovEl0h87p3W Uc11TwxGa+BcPetns/Aq2G7ek9lPmjGCbeZ9x6nqn9fUylS39KEp5jqs5UrAGcZVgdydSsAajkN+ wfxLxT/RiP8AGRqganoDlxY4Uuio1i5kORhiTdOU8eUkLbWG9QVyx2ko7057XfuKgaCw8PXq4xgi 3wruuzM6nZEiXGdU046kNg6CQoBZAQQ2kkdpwjI1ZETdJbU+7zZkeKiIzIfW63HbxpZSpRIQMAbA HHcO7urHEmSIDynozmhxTTjJOAew4goWN/KlRH9dYKD0r+Rf+FvP+rQP+Uqt2JIuMThDjh+1BXWI vUrQUDKgMo1EfOE5P9VaX5F/4W8/6tA/5Sq6xQVPg2W9InXltmW/Ms7TjXRSHnC4VEoy4NZ3ICsf qzVVgzrsj8l9ruaJ0x56XMSic+9Lc7DAdWknXuWxskFQGcHx4rq1KDl0CVcpl54bhPXh9yJIlXBI VFku4caShJSlS1JSXMHUAvB8oOa0rNerq1C4WmuXG4yFzY1x6hAd1lfJSoo0pORqyO8gkk75rr1K Dh9w4kuXRXJcO6yENu2hmWlDUx1xTDhktpI1qVkK0qIOnA3xjapxq5XJucZIuc0k8YmBy1PqKAwe 9Onux/wxtiuqUoOXflFu1xhXm5txLhKjoRZGnUpaeUkJWZiElQAOx0kjPfjap60dXJ4h4vsi7jML DKY4ZcU8oraLjRKilXeN98DAFXKmKDi96vnEM2wSQZk2E9YGUsy3GnlIL8hTyWxkg9oaBqz5VVPN XK8r42dadnJYeTduWmM4+6eZE07aWUoKcEdrmEjcYOK6XSg4mvim/wAOLJldTJUzag7bntTqjzHV l3S4fnThoZO/01fL3PvULgiS3BiTTNjwm8TVKQsLPYCyO0VlQBUclI3SfmzcKUHKJFznqkNR4F2n OWhd+hMRpfPUpTiVtq5qdZ3UArGxyKjJhuV0vbEJqfL6iNcbxHiO85XMSEMoKE68579u/wAddqrD KjNy4y2HS6ELxktOqbVsc7KSQR/UaCm8B3eZxLLmXh514RkMMxW2io6C4EhTqtPdnUQAfJVc4bk3 GajgtL94uShcxOTKzKXlQbJKQDnbu7xvv391dSt9viWqE3DgsJZjt50oT8+5+cn562aDjcW/XaRw 7b351zmNINqkuRnkOqSp+Yl5SUIUR8c6QOye+vnjCfcpFrvbN6kyGHxCgKjxUkpbcKikvEp7jhfj 8WAK7NSg5q1c7y5xq407PDDqLtykxnH3TzImnbSylBTgjfmEjcYOKs14uqLvwLKuVkuSmUONktS0 suEp0qwrshOodxGQNu+rJWGNFZhx0sR0aG05IGSdyckknckkkk+PNBytF9ux4fkhh6RpbuEduTIT PU6wGVA6y29grQMhOrJUU528lfCpV0Xc7A83KbnSG1XXoVoUt3IDA0J1rSkuYVtqwQdt667Sg5HD u/EPufuT8C4mQ+LY2440l92Q609rAWrKkBLZ06/gwTjSCNt62+IEWqVHtT0G73GdEZvUUPOOyXFN sJUDqKXNvm31EpJwNOSD1GlBEX+1Jnw3ZLLWbnHjPphOhRBbWtBTt4t9u+q7Y7lZWuF4DDTeu8Qr YoltljU+wpKPhBkpIbUVA7K7z4jV5pQcPuPElyEG4qiXWQht20sywhqY64WHDJbSRrUrIVpUQdOB vjG1WG43K6QrzfLei4TDAj3C3h95TpK2GHEEuqCu9IyB3YxnbFdPpQc4vFxUzGtKbZdpb9nclPpk S5MtxgAhPYTzwjVoznCu1qxjJ8WrZYXh3iqJGvi0T+dw4OasJWgOgSspPaCVeJJ7h9FdRpQakC6Q 7n1PRvc3pZC4z3ZKdLicak7gZxkbjatulKBSlKBSlKBSlKBSlKBSlKBSlKBSlKBSlKBSlKBSlKBS lKBSlKBSlKBSlKBSlKBXLvyD/wDZrl/qsb/mya6jXLvyD/8AZrl/qsb/AJsmg7HSlKBSlKBSlKBS lKBSlKBSlKBSlKBSlKBSlKBSlKBSlKBSlKBSlKBSlKBSlKBXgCvf9eAKBV0sdx8FcJR3vDN0s3Pn SE8+1I1uSNLbJ0uDmN4SjVlO6t3F7Jx2q3e7r4au79w6CDA52n97QGeUyjCQnspycZxk/OTX3b79 OtkdUdjpXGSorDcqGzJSlRABKQ6lQSSAMkYzpTnOBgLZJm3G0Xe9oRNXw3bmrtKS45aSrmPL1ABh ACm+YhsDIzpCAsnYrSlW3wWzGn8XQ79CYtbT0m+gJgvSmUdEzzEKy22opLiiFlCSlPZ0HA1FJRT4 /FV2jsLZU5FkpW+uSozYTMpRdWEhatTqFHJ0pzvvitBm5So13bujCkNS2nxIbU20lKULCtQIQBpA B8WMeLGKCw2aZc7PAdR4XfssFqU4l2ZbV6npbmEjlp0OJS6lGNWdQSkOKOcrSlVeuktqfd5syPFR EZkPrdbjt40spUokIGANgDjuHd3VtwOJLjbYAgsiE5GDqnkolQGJGlagkKILiFEZCE93kFfEO/3K 3yLg9DeQwq4MORpIbZQEqacIK0hOMJBwPigY8WKCSsN6l2uAlvwldLNDcdcV1lsZJckOAN/BrPMb CkoG4GSUlw7dva4cP2huP+UQzGWrQiYniVcZUNUtlKYbSXUElptZSXCdSkIIT2dBITqKSjntvv0+ 2R1R2OlcZKtYblQ2ZKUqIAJSHUqCSQBkjGdKc5wMa7Nzmx7u3dUSVme2+JIfcOtRdCtWo6s5Od98 5oLTaeIUWiwCzK4gvVokx577ri7SEutvBSWkjKkvoBwW1YI1AhWxr8RcLtw9PnwJ95udt0T5KJFy tiFrcmSElCVJWouN60p3UMnILhOO3tX7ffp1sjqjsdK4yVaw3KhsyUpUQASkOpUEkgDJGM6U5zgY +4vEl0i87LrErnOqeX10VqV8Ir4yxzUqwpWBkjBVgZzgYCyy7rLsl+vETqpvDsPwpLHOsjZVzHAp I5OrW0FIbG6e4p5h7I17b85USw+EpInzbBMevs+Mo2ZgO/BtcohoLLjRShJcVgAAK2JHYTilxeJL pF52XWJXOdU8vrorUr4RXxljmpVhSsDJGCrAznAwi8SXSLzsusSuc6p5fXRWpXwivjLHNSrClYGS MFWBnOBgJOJb3bQjjW2yFIU9Eh8hxTZJSVInR0kjIG2R5Kq1SzV/ebt1zjLjMvSbltInPLcU+U8x DhHx9O62wSSknc71E0Cp7hH+OZH9F3D/AAb1QNb9nui7PcRMRHZkfBOsqaf1aFocbU2oHSUn4qz3 EUGeyQ48jq5LzfVKiNc5MFJIU/jvJIwdCQNStJ1Y7sDUtE1w1Ltblp4qeuMGU68uGHHDFkNx0FBl R+ylHKUEnUQcjbA0hI7xV+rW3P6yIOjcS7zWgwtQ5JzkaSSVDHiJJO3fX2LlKSZxQpDYnJ0SEttJ SlSeYlzASBhI1IScJxjGO7agsXCb1pbsPEonQprzggJK1MTENAt9VHASAWlYVqwdWSMbY8dOE3rS 3YeJROhTXnBASVqYmIaBb6qOAkAtKwrVg6skY2x46rMeZIisymWXNLcpoMvDAOpAWlYG/d2kJO3k /XSPMkRWZTLLmluU0GXhgHUgLSsDfu7SEnbyfroLNwm9aW7DxKJ0Ka84ICStTExDQLfVRwEgFpWF asHVkjG2PHThN60t2HiUToU15wQElamJiGgW+qjgJALSsK1YOrJGNseOqzHmSIrMpllzS3KaDLww DqQFpWBv3dpCTt5P10jzJEVmUyy5pblNBl4YB1IC0rA37u0hJ28n66CzcJvWluw8SidCmvOCAkrU xMQ0C31UcBIBaVhWrB1ZIxtjx04TetLdh4lE6FNecEBJWpiYhoFvqo4CQC0rCtWDqyRjbHjqsx5k iKzKZZc0tymgy8MA6kBaVgb93aQk7eT9dI8yRFZlMsuaW5TQZeGAdSAtKwN+7tISdvJ+ugs3Cb1p bsPEonQprzggJK1MTENAt9VHASAWlYVqwdWSMbY8dZ7HcfBXCUd7wzc7Nz50hPPtSNbkjS2ydLg5 jeEo1ZTurdxeycdqpR5kiKzKZZc0tymgy8MA6kBaVgb93aQk7eT9dblvv062R1R2OlcZKisNyobM lKVEAEpDqVBJIAyRjOlOc4GAtERzouPOKoQgQmCtq6oKWk6wwlLEg6GiQAE5A3CQcJAGAVAxMWZI svCMKdb3ORJlz5LEhYAPNabbYKW1A5BQS6vUg9lW2oHSnGhbuJbpbJcqWw6y5Jlauc9KjNSFr1BQ V2nEqI1BSgrHxs75r4iX+5QZEl6K8hlUhXMUEMoCUrySlaE4w2tOTpUgApydJGaC0RER7Rx5xVao cVlLCWrqw2pYK1tNoYkYSkqJxnCcq+N2cZwVBUbYLjcbfaCtF2lWS3B9fMlwdQkSllKMNgBaeYEA atyAgOK3ytKVRFnv06xLeXA6UKeQULU9EafOkgpIHMSrAIUQQMZBwc1sR+KbnFjrjoTb1srfXI5b 1tjOpQtYSFFAW2dAISnZOBsNqCdnXi2q4ZZnqsEV1Eq93BxiI46tLMdCkRjpAbKCSMpAOQAAeycj TkVY7VZZ92ZlNWsxmbpIhR5F4dlHmBogEJTFAIUApJUVbHUnSBhWa9H4qu0VhcZtyKYq31yTGchM uM81YSCoNqQUg4SAMDsjIGAo5xxeJbvE5xbl63HXVPl19tDriHVd7iFrBU2s4BK0kKJSk57IwFhv LauDmJLdneW2rw3PgOOrCVKeYYDOhteRhSDzFFScaV5GoHSnGCfbIR4n4isKIyI8KFMkqZmD/wDo 0oWUjmKO62zhCcHKgopKMqJQ5Ct8S3dqfNnIl4kzXS+8stoPwpJIcSCMIWCpWlacKTqOCMmtHrZH QdCHMRubzlISANS8YBUe9WBnGe7UrGNRyEtYP4m4p/otH+MjVA1JRLwYVmn29uDFKpqQ25KUXOaE BaF6ANWjGptJyUk7neo2gsPD16uMYIt8K7rszOp2RIlxnVNOOpDYOgkKAWQEENpJHacIyNWRE3SW 1Pu82ZHioiMyH1utx28aWUqUSEDAGwBx3Du7qxxJkiA8p6M5ocU04yTgHsOIKFjfypUR/XWCg9Kf kW/hr1/q0D/lKrrNcm/It/DXr/VoH/KVXWaBSlKBSlKBSlKBSlKBSlKBSlKBSlKBSlKBSlKBSlKB Ude5ztttD8tlKFON6cBYJG6gPF+upGoXiv8A7tS//J/601Y7pPZ+44n8lp/2lNPFHktP+0qw89vy Cte4XJm322VOeBLUZpbq8d+Egk/2Ctfon6obHFHm2n/aUxxR5tp/2lRsbi25tM2G4XGPC6G8uoaQ 2wlQcjqcGW8qKiF5A32Tj560OGPyiyeJF2eE23CRPeDj05RQvQhCVkBCBqyVkaTucAHO/dUv4JU8 rCBxP5LT/tKxyXuJYsV2Q4m1lDSFLUE8zOAMmrLzkeQVo3l1CrFcABjMZz/0mr+h+r5gvqlW+NIW AFOtJWQO4EgGtitK0fxLA/1dv/0it2sNtSa6+hcZuOptK3ndBU4gqAGhSu4Eeb5a+eVdf0mJ9mV+ JX1JUEzraT+kK/5TlSXOR5BWo7MovlXT9JifZlfiU5V0/SYn2ZX4lOJOIGeHuHpl1WzzenQCGwca lEhKRnxbkVijzrxCbdeuzcN9kNpUkQW1hzX40aVEgjcdrUPnAG4tlMvKuv6TE+zK/Epyrr+kxPsy vxKhx+UizboMWZzkzGoamkBtwpW4FFJyhZSR2T3EnPirYRx5bHkISzEmOzFynYghpQjm8xsZX3q0 4AIOdXjpZSQ5V1/SYn2ZX4lOVdf0mJ9mV+JWjM45tsJtkrhTy6uMqW4xyNLjDKThS1pURgA+TJON s1+2PidV34kvkIJYVChoirjOIBClpdbKyVEnB8WMAUspu8q6fpMT7Mr8SvguTo8qKl92O4284UEI ZUkjsKVnJWfN8lTHPR5BUdcnErk20JH/APUn/lOUtKbNKUrDZSlKBSlKBSlKBSlKBSlKBSlKBSlK BSlKBSlKBSlKBXLvyD/9muX+qxv+bJrqNcu/IP8A9muX+qxv+bJoOx0pSgUpSgUpSgUpSgUpSgUp SgUpSgUpSgUpSgUpSgUpSgUpSgUpSgUpSgUpSgV4Ar3/AF4AoFK6B73ll+W8T9nSfZp73ll+W8T9 nSfZq0Of0roPveWT5bxP2dJ9mnveWT5bxP2dJ9moOfUroHveWX5bxP2dJ9mnveWX5bxP2dJ9mrQ5 /Suge95ZflvE/Z0n2ae95ZflvE/Z0n2aUOf0roHveWX5bxP2dJ9mnveWX5bxP2dJ9mlDn9K6B73l l+W8T9nSfZp73ll+W8T9nSfZpQ5/Suge95ZflvE/Z0n2ae95ZflvE/Z0n2aUOf0roHveWX5bxP2d J9mnveWX5bxP2dJ9mlDn9K6B73ll+W8T9nSfZp73ll+W8T9nSfZpQ5/Suge95ZflvE/Z0n2a/fe8 svy3ifs6T7NKHPqV0D3vLL8t4n7Ok+xT3vLJ8t4n7Ok+xShz+ldA97yy/LeJ+zpPsU97yy/LeJ+z pPsUoc/pXQPe8svy3ifs6T7FPe8svy3ifs6T7FKHP6V0D3vLL8t4n7Ok+xT3vLL8t4n7Ok+xShz+ ldA97yy/LeJ+zpPsU97yy/LeJ+zpPsUoc/pXQPe8svy3ifs6T7FPe8svy3ifs6T7FKHP6V0D3vLL 8t4n7Ok+xT3vLL8t4n7Ok+xShz+ldA97yy/LeJ+zpPsU97yy/LeJ+zpPsUoc/pXQPe8svy3ifs6T 7FPe8svy3ifs6T7FKHVPyLfw16/1aB/ylV1muTfkW/hb1/q0D/lKrrNQKUpQKUpQKUpQKUpQKUpQ KUpQKUpQKUpQKUpQKUpQKheLP+7Uv/yf+tNTVaV2geFLY9D5vK5mO3p1YwoHuyPJVjuk9nz1FYJy kSLfJZdZU+240pCmkkArBBBSMkDfu3IHz1q+Abp6c/3RP308A3T05/uifvrruxc9uSqxYFwR4LYl wLnJg2tYcis6YyVakjCCtXPOrSO7AFbsDhAW+1WOK1cP3zaZCnUSAzjmJWpRWgp1bAggZz4qnPAN z9Of7on76eArn6c/3RP30vBfxJLqK1LrIzaJv8wv/wBJrB4Cufpz/dE/fXw7w7cXm1NrveUKBSod KncH+uruwZrJL2j+JYH+rt/+kVu1giMdLCYj6tXKbSjVjGcADP8AZWeuE93b2R1zVpegH/8AUH/l OV98+vq4wlzUM8t5LS2nNYKkageyU4xkedWp4Lnfp0f7MfbrrjONdWMom+jU4hjtXSwy4T0d6Qh5 ATy2CkLzkYI1EJyDg7nxVX3Yt6vlvlWq6uXBpqSyGkuhmOhDeDnUoJdUtROADjbfuHfVq8GTv06P 9mPt08Fzv06P9mPt1bwZ/EqaeCVm5mc5c29ZnRJehqJoSOQlSQgDVsDq/qx46ztcIqjTVXCPcQia m4yJzLi2NSUB5ISpBTqGdgN8j9VWbwZO/TY/2Y+3TwZO/TY/2Y+3S8D8SuXPhLwm/GmPzmn5zcYx nHpcJt5KwTqCgjZKVAk4O/z5qRs1kTZ7tcpqHwtMxEdAbDQRyw0jQO7bfyAACpLwXO/To/2Y+3Tw XO/To/2Y+3VvArJs8+td13VPtw//AFCj/snK/PBk/wDTo/2ZXt19M2uSmYw89LaWllRUEoYKSSUl PeVHzvJUmcaIjK0rSlK4upSlKBSlKBSlKBSlKBSlKBSlKBSlKBSlKBSlKBSlKBXLvyD/APZrl/qs b/mya6jXLvyD/wDZrl/qsb/myaDsdKUoFKUoFKUoFKUoFKUoFKUoFKUoFKUoFKUoFKUoFKUoFKUo FKUoFKUoFKUoFeAK9/14AoPZ3vW8H+i3ft0j26e9bwf6Ld+3SPbq40oKd713B/ot37dI9unvXcH+ i3ft0j26uIoaCne9bwf6Ld+3SPbp71vB/ot37dI9urjSgp3vW8H+i3ft0j26e9bwf6Ld+3SPbq40 oKd71vB/ot37dI9unvW8H+i3ft0j26uNKCne9bwf6Ld+3SPbp71vB/ot37dI9urjSgp3vW8H+i3f t0j26e9bwf6Ld+3SPbq40oKd71vB/ot37dI9unvW8H+i3ft0j26uNKCne9bwf6Ld+3SPbp71vB/o t37dI9urjSgp3vW8H+i3ft0j26e9bwf6Ld+3SPbq40oKTI/JhwghsFNseBz+nSPbrX97XhPH8Wvf bX/bq7yv4MfrrU8VBUx+TXhP0c99tf8Abp72vCfo577a/wC3VspQVP3teE/Rz321/wBunva8J+jn vtr/ALdWylBU/e14T9HPfbX/AG6e9rwn6Oe+2v8At1bKUFT97XhP0c99tf8Abp72vCfo577a/wC3 VspQVP3teE/Rz321/wBunva8J+jnvtr/ALdWylBU/e14T9HPfbX/AG6e9rwn6Oe+2v8At1bKUFT9 7XhP0c99tf8Abp72vCfo577a/wC3VspQVP3teE/Rz321/wBunva8J+jnvtr/ALdWylBxuH+S/iyC MxLo3EcU2226Yl2eZDmhOkEgM/r7ye81te4Hjr5SSj//AN6R+DXWqUHJfcDx38o5X7ekfg09wPHf yjlft6R+DXWqUHJfcDx38o5X7ekfg09wPHfyjlft6R+DXWqUHJfcDx38o5X7ekfg09wPHfyjlft6 R+DXWqUHJfcDx38o5X7ekfg09wPHfyjlft6R+DXWqUHJfcDx38o5X7ekfg09wPHfyjlft6R+DXWq UHJfcDx38o5X7ekfg09wPHfyjlft6R+DXWqUHJfcDx38o5X7ekfg09wPHfyjlft6R+DXWqUHJfcD x38o5X7ekfg09wPHfyjlft6R+DXWqUHJfcDx38o5X7ekfg09wPHfyjlft6R+DXWqUHJfcDx38o5X 7ekfg09wPHfyjlft6R+DXWqUHJfcDx38o5X7ekfg09wPHfyjlft6R+DXWqUHJfcDx38o5X7ekfg0 9wPHfyjlft6R+DXWqUHJfcDx38o5X7ekfg09wPHfyjlft6R+DXWqUHJfcDx38o5X7ekfg09wPHfy jlft6R+DXWqUHJfcDx38o5X7ekfg09wPHfyjlft6R+DXWqUHJ2vye8eOHA4kk92d7/I/BrJ72/H3 ylkft+R+DXW4v8Kf1Vt0HGfe34++Usn9vyPwae9vx98pJP7fkfg12alBxn3t+PvlJJ/b8j8Gnvb8 ffKST+35H4NdmpQcZ97fj75SSf2/I/Bp72/H3ykk/t+R+DXZqUHGve448+Usj9vSPwae9xx58pZH 7ekfg12WlBxr3uOPPlLI/b0j8GnvccefKWR+3pH4NdlpQca97jjz5SyP29I/Bp73HHnylkft6R+D XZaUHGve448+Usj9vSPwae9xx58pZH7ekfg12WlBxr3uOPPlLI/b0j8GnvccefKWR+3pH4NdlpQc a97jjz5SyP29I/Bp73HHnylkft6R+DXZaUHGve448+Usj9vSPwae9xx58pZH7ekfg12WlBxr3uOP PlLI/b0j8GnvccefKWR+3pH4NdlpQca97jjz5SyP29I/Bp73HHnylkft6R+DXZaUHGve448+Usj9 vSPwae9xx58pZH7ekfg12WlBxr3uOPPlLI/b0j8GnvccefKWR+3pH4NdlpQca97jjz5SyP29I/Bp 73HHnylkft6R+DXZaUHGve449+Ukn9vSPwatH5N+Crjwf16ZqopbeaZbaDL6nT2FOqJUShP5wYwP FV9pQKUpQKUpQKUpQKUpQKUpQKUpQKUpQKUpQKUpQKUpQKUpQKUpQKUpQKUpQKUpQK8AV7/rwBQe /wClKUClKUClKUClKUClKUClKUClKUClKUClKUClKUGCV/Bj9danirblfwY/XWp4qBSlKBSlKBSl KBSlKBSlKBSlKBSlKBSlKBSlKBSlKBSlKBSlKBSlKBSlKBSlKBSlKBSlKBSlKBSlKBSlKBSlKBSl KBSlKBSlKDPF/hT+qtutSL/Cn9VbdApSlApSlApSlApSlApSlApSlApSlApSlApSlApSlApSlApS lApSlApSlApSlApSlApSlApSlApSlApSlApSlApSlApSlApSlApSlApSlApSlApSlApSlApSlApS lArwBXv+vAFB7/pSlApSlApSlApSlApSlApSlApSlApSlApSlApSlBglfwY/XWpUgpAWMKGRXx07 Xm/20GlSt3p2vN/tp07Xm/20GlSt3p2vN/tp07Xm/wBtBpUrd6drzf7adO15v9tBpUrd6drzf7ad O15v9tBpUrd6drzf7adO15v9tBpUrd6drzf7adO15v8AbQaVK3ena83+2nTteb/bQaVK3ena83+2 nTteb/bQaVK3ena83+2nTteb/bQaVK3ena83+2nTteb/AG0GlSt3p2vN/tp07Xm/20GlSt3p2vN/ tp07Xm/20GlSt3p2vN/tp07Xm/20GlSt3p2vN/tp07Xm/wBtBpUrd6drzf7adO15v9tBpUrd6drz f7adO15v9tBpUrd6drzf7adO15v9tBpUrd6drzf7adO15v8AbQaVK3ena83+2nTteb/bQaVK3ena 83+2nTteb/bQaVK3ena83+2nTteb/bQaVK3ena83+2nTteb/AG0GlSt3p2vN/tp07Xm/20GlSt3p 2vN/tp07Xm/20GGL/Cn9VbdfCWkIOUjBr7oFKUoFKUoFKUoFKUoFKUoFKUoFKUoFKUoFKUoFKUoF KUoFKUoFKUoFKUoFKUoFKUoFKUoFKUoFKUoFKUoFKUoFKUoFKUoFKUoFKUoFKUoFKUoFKUoFKUoF KUoFKUoFeAK9/wBeAKD3/SlKBSlKBSlKBSlKBSlKBSlKBSlKBSlKBSlKBSlKBSlKBSlKBSlKBSlK BSlKBSlKBSlKBSlKBSlKBSlKBSlKBSlKBSlKBSlKBSlKBSlKBSlKBSlKBSlKBSlKBSlKBSlKBSlK BSlKBSlKBSlKBSlKBSlKBSlKBSlKBSlKBSlKBSlKBSlKBSlKBSlKBSlKBSlKBSlKBSlKBSlKBSlK BSlKBSlKBSlKBSlKBSlKBSlKBSlKBSlKBSlKBSlKBSlKBSlKBSlKBSlKBSlKBXgCvf8AXgCg9/0p SgUpSgUpSgUpSgUpSgUpSgUpSgUpSgUpSgUpSgUpSgUpSgUpSgUpSgUpSgUpSgUpSgUpSgUpSgUp SgUpSgUpSgUpSgUpSgUpSgUpSgUpSgUpSgUpSgUpSgUpSgUpSgUpSgUpSgUpSgUpSgUpSgUpSgUp SgUpSgUpSgUpSgUpSgUpSgUpSgUpSgUpSgUpSgUpSgUpSgUpSgUpSgUpSgUpSgUpSgUpSgUpSgUp SgUpSgUpSgUpSgUpSgUpSgUpSgUpSgUpSgUpSgV4Ar3/AF4AoPf9KUoFKUoFKUoFKUoFKUoFKUoF KUoFKUoFKUoFKUoFKUoFKUoFKUoFKUoFKUoFKUoFKUoFKUoFKUoFKUoFKUoFKUoFKUoFKUoFKUoF KUoFKUoFKUoFKUoFKUoFKUoFKUoFKUoFKUoFKUoFKUoFKUoFKUoFKUoFKUoFKUoFKUoFKUoFKUoF KUoFKUoFKUoFKUoFKUoFKUoFKUoFKUoFKUoFKUoFKUoFKUoFKUoFKUoFKUoFKUoFKUoFKUoFKUoF KUoFKUoFKUoFKUoFeAK9/wBeAKD3/SlKBSlKBSlKBSlKBSlKBSlKBSlKBSlKBSlKBSlKBSlKBSlK BSlKBSlKBSlKBSlKBSlKBSlKBSlKBSlKBSlKBSlKBSlKBSlKBSlKBSlKBSlKBSlKBSlKBSlKBSlK BSlKBSlKBSlKBSlKBSlKBSlKBSlKBSlKBSlKBSlKBSlKBSlKBSlKBSlKBSlKBSlKBSlKBSlKBSlK BSlKBSlKBSlKBSlKBSlKBSlKBSlKBSlKBSlKBSlKBSlKBSlKBSlKBSlKBSlKBSlKBSlKBXgCvf8A XgCg9/0pSgUpSgUpSgUpSgUpSgUpSgUpSgUpSgUpSgUpSgUpSgUpSgUpSgUpSgUpSgUpSgUpSgUp SgUpSgUpSgUpSgUpSgUpSgUpSgUpSgUpSgUpSgUpSgUpSgUpSgUpSgUpSgUpSgUpSgUpSgUpSgUp SgUpSgUpSgUpSgUpSgUpSgUpSgUpSgUpSgUpSgUpSgUpSgUpSgUpSgUpSgUpSgUpSgUpSgUpSgUp SgUpSgUpSgUpSgUpSgUpSgUpSgUpSgUpSgUpSgUpSgUpSgV4Ar3/AF4AoPf9KUoFKUoFKUoFKUoF KUoFKUoFKUoFKUoFKUoFKUoFKUoFKUoFKUoFKUoFKUoFKUoFKUoFKUoFKUoFKUoFKUoFKUoFKUoF KUoFKUoFKUoFKUoFKUoFKUoFKUoFKUoFKUoFKUoFKUoFKUoFKUoFKUoFKUoFKUoFKUoFKUoFKUoF KUoFKUoFKUoFKUoFKUoFKUoFKUoFKUoFKUoFKUoFKUoFKUoFKUoFKUoFKUoFKUoFKUoFKUoFKUoF KUoFKUoFKUoFKUoFKUoFKUoFeAK9/wBeAKD3/SlKBSlKBSlKBSlKBSlKBSlKBSlKBSlKBSlKBSlK BSlKBSlKBSlKBSlKBSlKBSlKBSlKBSlKBSlKBSlKBSlKBSlKBSlKBSlKBSlKBSlKBSlKBSlKBSlK BSlKBSlKBSlKBSlKBSlKBSlKBSlKBSlKBSlKBSlKBSlKBSlKBSlKBSlKBSlKBSlKBSlKBSlKBSlK BSlKBSlKBSlKBSlKBSlKBSlKBSlKBSlKBSlKBSlKBSlKBSlKBSlKBSlKBSlKBSlKBSlKBSlKBSlK BXgCvf8AXgCg9/0pSgUpSgUpSgUpSgUpSgUpSgUpSgUpSgUpSgUpSgUpSgUpSgUpSgUpSgUpSgUp SgUpSgUpSgUpSgUpSgUpSgUpSgUpSgUpSgUpSgUpSgUpSgUpSgUpSgUpSgUpSgUpSgUpSgUpSgUp SgUpSgUpSgUpSgUpSgUpSgUpSgUpSgUpSgUpSgUpSgUpSgUpSgUpSgUpSgUpSgUpSgUpSgUpSgUp SgUpSgUpSgUpSgUpSgUpSgUpSgUpSgUpSgUpSgUpSgUpSgUpSgUpSgV4Ar3/AF4AoPf9KUoFKUoF KUoFKUoFKUoFKUoFKUoFKUoFKUoFKUoFKUoFKUoFKUoFKUoFKUoFKUoFKUoFKUoFKUoFKUoFKUoF KUoFKUoFKUoFKUoFKUoFKUoFKUoFKUoFKUoFKUoFKUoFKUoFKUoFKUoFKUoFKUoFKUoFKUoFKUoF KUoFKUoFKUoFKUoFKUoFKUoFKUoFKUoFKUoFKUoFKUoFKUoFKUoFKUoFKUoFKUoFKUoFKUoFKUoF KUoFKUoFKUoFKUoFKUoFKUoFKUoFKUoFeAK9/wBeAKD3/SlKBSlKBSlKBSlKBSlKBSlKBSlKBSlK BSlKBSlKBSlKBSlKBSlKBSlKBSlKBSlKBSlKBSlKBSlKBSlKBSlKBSlKBSlKBSlKBSlKBSlKBSlK BSlKBSlKBSlKBSlKBSlKBSlKBSlKBSlKBSlKBSlKBSlKBSlKBSlKBSlKBSlKBSlKBSlKBSlKBSlK BSlKBSlKBSlKBSlKBSlKBSlKBSlKBSlKBSlKBSlKBSlKBSlKBSlKBSlKBSlKBSlKBSlKBSlKBSlK BSlKBSlKBXgCvf8AXgCg9/0pSgUpSgUpSgUpSgUpSgUpSgUpSgUpSgUpSgUpSgUpSgUpSgUpSgUp SgUpSgUpSgUpSgUpSgUpSgUpSgUpSgUpSgUpSgUpSgUpSgUpSgUpSgUpSgUpSgUpSgUpSgUpSgUp SgUpSgUpSgUpSgUpSgUpSgUpSgUpSgUpSgUpSgUpSgUpSgUpSgUpSgUpSgUpSgUpSgUpSgUpSgUp SgUpSgUpSgUpSgUpSgUpSgUpSgUpSgUpSgUpSgUpSgUpSgUpSgUpSgUpSgUpSgV4Ar3/AF4AoPf9 KUoFKUoFKUoFKUoFKUoFKUoFKUoFKUoFKUoFKUoFKUoFKUoFKUoFKUoFKUoFKUoFKUoFKUoFKUoF KUoFKUoFKUoFKUoFKUoFKUoFKUoFKUoFKUoFKUoFKUoFKUoFKUoFKUoFKUoFKUoFKUoFKUoFKUoF KUoFKUoFKUoFKUoFKUoFKUoFKUoFKUoFKUoFKUoFKUoFKUoFKUoFKUoFKUoFKUoFKUoFKUoFKUoF KUoFKUoFKUoFKUoFKUoFKUoFKUoFKUoFKUoFKUoFeAK9/wBeAKD3/SlKBSlKBSlKBSlKBSlKBSlK BSlKBSlKBSlKBSlKBSlKBSlKBSlKBSlKBSlKBSlKBSlKBSlKBSlKBSlKBSlKBSlKBSlKBSlKBSlK BSlKBSlKBSlKBSlKBSlKBSlKBSlKBSlKBSlKBSlKBSlKBSlKBSlKBSlKBSlKBSlKBSlKBSlKBSlK BSlKBSlKBSlKBSlKBSlKBSlKBSlKBSlKBSlKBSlKBSlKBSlKBSlKBSlKBSlKBSlKBSlKBSlKBSlK BSlKBSlKBSlKBSlKBXgCvf8AXgCg9/0rifukuX6TJ+2P/iV+e6W5fpMn7Y/+JWd08fRajl22lcS9 0ty/SZP2x/8AEp7pbl+kyftj/wCJTdPH0Kjl22lcS90ty/SZP2x/8SnuluX6TJ+2P/iU3Tx9Co5d tpXEvdLcv0mT9sf/ABKe6W5fpMn7Y/8AiU3Tx9Co5dtpXEvdLcv0mT9sf/Ep7pbl+kyftj/4lN08 fQqOXbaVxL3S3L9Jk/bH/wASnuluX6TJ+2P/AIlN08fQqOXbaVxL3S3L9Jk/bH/xKe6W5fpMn7Y/ +JTdPH0Kjl22lcS90ty/SZP2x/8AEp7pbl+kyftj/wCJTdPH0Kjl22lcS90ty/SZP2x/8SnuluX6 TJ+2P/iU3Tx9Co5dtpXEvdLcv0mT9sf/ABKe6W5fpMn7Y/8AiU3Tx9Co5dtpXEvdLcv0mT9sf/Ep 7pbl+kyftj/4lN08fQqOXbaVxL3S3L9Jk/bH/wASnuluX6TJ+2P/AIlN08fQqOXbaVxP3SXL9Jk/ bH/xK/PdLcv0mT9sf/Epunj6FRy7bSuJ+6S5fpMn7Y/+JVq4GuMubdsvSH1JLD2ULfccTlKmsHC1 HftH6am7rETBToVKUraFKUoFKUoFKUoFKUoFKUoFKUoFKUoFKUoFKUoFKUoFKUoFKUoFKUoFKUoF KUoFKUoFKUoFKUoFKUoFKUoFKUoFKUoFKUoFKUoFKUoFKUoFKUoFKUoFKUoFKUoFKUoFKUoFKUoF KUoFKUoFKUoFKUoFKUoFKUoFKUoFKUoFKUoFKUoFKUoFKUoFKUoFKUoFKUoFKUoFKUoFKUoFKUoF eAK9/wBeAKDvWaZHlFblteiMuuGW2VAowjAzg7//AMqzdXC/N/3KRl1o9kbqHlFNQ8oqR6uF5n9y v3q4Xmf3KCN1DyimoeUVvvyYjjC0ob7RG3Yr76yF+b/uVRG6h5RTUPKKkushfm/7lOshfm/7lBG6 h5RTI8oqS6yF+b/uVj6mJ1JVo7OjHxPHmg0dQ8opkeWpLrIX5v8AuU6uF5n9ygjdQ8opkeUVJdZC /N/3KdZC/N/3KCN1DyimR5a3o8qIiM0lbfaSgA9jx4rJ1cLzP7lBG6h5RTUPKKkerheZ/cr96uF5 n9yoI3UPKKah5RW+uTELrSg32Uk57HzV99ZC/N/3KojdQ8opkeUVJdZC/N/3KdXC/N/3KCN1Dyiv pAU6sIbBUpRwAPGakOrheZ/crWtzzbF2aeV2Wg/q/wDtGe+s55TGMzBHd8yYj0RSQ8EjV3FKwoHH fuCayqtcxK0oLSdSiR/CJ7JAydW/Z28uK2lqEWNHZLrDim3FuLwtChpJSNj5ds7b1tF1LKn0okRV mRIWtOtwFKkaTsSPi51Dvx3V5stfOI6V7uuyLQjzDsdzQ6nCsAjBBBB8YI2NXP8AJ1/GY/mZH/qY qrXVxDjzKEcr4NlKCGjlIO5wDk5xnymrV+Tr+Mx/MyP/AFMV1jOcoxmfvoxMVMumUpSurJSlKBSl KBSlKBSlKBSlKBSlKBSlKBSlKBSlKBSlKBSlKBSlKBSlKBSlKBSlKBSlKBSlKBSlKBSlKBSlKBSl KBSlKBSlKBSlKBSlKBSlKBSlKBSlKBSlKBSlKBSlKBSlKBSlKBSlKBSlKBSlKBSlKBSlKBSlKBSl KBSlKBSlKBSlKBSlKBSlKBSlKBSlKBSlKBSlKBSlKBSlKBSlKBXgCvf9eAKDvVKlYEKO5GDjqSpS j5SMVKQbFHuD6mmmkBQTqypasY7v/epllGMXKxF9lWpV59xX/hj/AFi61Z3DLVvYDrzbRSVaeytR Ocf/AMq5x4jSmaiWvLyVClTy7dEUghKNB8oJP/GoeK0l6ShtXce+uzDDSp/oIQ/+j/eP31Kp4SSu KmQltnSpAXjmLzjGaxlqY4fzSsRM9lMpVwhcLtzo/OabaCCSO04oGtF62Q2HnGlMpKkKKThSsZBx 5aY6uOUzjE9YXbKuUreuMZqOtBayArOx8WKxx2G1N6l758VbZatKkOnZJxo/tNZU25Kk6g3sO/c1 JmI7iKpUiYrSTgt4/rNfJjMkbDB8uao0KVmitJekobV3HvqZECEP/o/3j99BAUqwdBC/Mj1lffTo IX5kesr76Cv0qwdBC/Mj1lffUbcozUdaC1kBWdvJig0aVK2+FHcjBx1JUpXduRitsW+GpQSGMk9w 1K3/ALaCv0q3jhlsAcxEdtZGQ2t4hX0ZrUftEeK6W3o2hY8RUfvrnjqY5dIlZxmFbFXn8nX8ZD+Z kf8AFioRy3RFIIQ2Unygn/3qc/J1/GI/mpH/ABYpn3j5/sQ6XSlK2hSlKBSlKBSlKBSlKBSlKBSl KBSlKBSlKBSlKBSlKBSlKBSlKBSlKBSlKBSlKBSlKBSlKBSlKBSlKBSlKBSlKBSlKBSlKBSlKBSl KBSlKBSlKBSlKBSlKBSlKBSlKBSlKBSlKBSlKBSlKBSlKBSlKBSlKBSlKBSlKBSlKBSlKBSlKBSl KBSlKBSlKBSlKBSlKBSlKBSlKBSlKBSlKBXgCvf9eAKD0bDkobipSpWCCf8AjVl4SfQ7dXQk5IYJ /vJqkNup0Y32PkNTXDl5jWe4OSJCHVIU0UANpyc5B8ePJXHxGM5acxDeE1lEy6fUDxa4GrU0onHw 4H91Vanu9tX5iZ9WPvqI4i4ohXi3tx4zUhK0uhZLiABjBHiJ8tfM0PD6mOpEzDvnnjtnqj+sb86o qI4G5Laydv8A+Rr5LoAyc/RWFDgSUE6voNfZeVO9Y3539ldBjKzYGVeLpQf7tco5ifn+g1cmOMrc 3Z2oamZXMRHDZIbGMhOPL3V4vGaeWcY7YdtLKMbtN8LuB2ypUDka1VUbpLQm6zAVdz6x/eNbdg4r g2u1iK+1JUsLUrKEAjf9Zquzpbcm4yZCAsIddWtIUnfBJP8A700MMo1s5mOkmcxOEQT30ulvSc4z /wC1Y2XUhsAnGM/8a1nXEqUAM7A+I1+JWPIr6DXtcUmy8nUo5zhORtU1H0pinfYZOTVWQ9oVqGdv mNbaLkEtFJRqO2lRQCUfN3b1y1cZns1jNNiQpKEkE50qA/srW5w8ta70ovHfOO/cHJNYtYx4/oNb xioSWaIvlym1E7An/galetb87+yoIOJStJ3xnyGs/NT8/wBBrSOi2WLBctTK5AaccUSsBRG2e4fQ BWuxxBEmXNuA3AQGlq0EKTv9Hiqg80fP9BrJHnOxHg8wtSHEggKA3GRj/wB68k+GuZmZuZ7fB18y oqEvLksszX2kL7CHFJT+oGo2e+l4thJzjP8A7Vrc0E53+g18OOAqA3yAfEa9URUOSThyUNxUoUrB BPi+epmxyW1zXHEnU40ytxAI71AbVVG3U6MYVsfIa2Yc9yDKbkMKUlxByNjv8x+as547sZiFxmpX e3Ro06EzKkNKMhWsoQXMGRjfO9R0uUHLE086CFtyFMoyN9OM4/qNR6rnZJC0vux57To35bCxoB79 idwM+StG53fr1NtoaDMZkYaaGTjPeSfGTXnwxznPr/8AHSZimx1rfnVP/k5/jBP8zI/4sVSS6kDJ z9Bq6fk6WBOQSFfwMj+SfLHr0Z98fn+znHaXTqVj5yfIv1FfdTnJ8i/UV91bRkpWPnJ8i/UV91Oc nyL9RX3UGSlY+cnyL9RX3U5yfIv1FfdQZKVj5yfIv1FfdTnJ8i/UV91BkpWPnJ8i/UV91OcnyL9R X3UGSlY+cnyL9RX3U5yfIv1FfdQZKVj5yfIv1FfdTnJ8i/UV91BkpWPnJ8i/UV91OcnyL9RX3UGS lY+cnyL9RX3U5yfIv1FfdQZKVj5yfIv1FfdTnJ8i/UV91BkpWPnJ8i/UV91OcnyL9RX3UGSlY+cn yL9RX3U5yfIv1FfdQZKVj5yfIv1FfdTnJ8i/UV91BkpWPnJ8i/UV91OcnyL9RX3UGSlY+cnyL9RX 3U5yfIv1FfdQZKVj5yfIv1FfdTnJ8i/UV91BkpWPnJ8i/UV91OcnyL9RX3UGSlY+cnyL9RX3U5yf Iv1FfdQZKVj5yfIv1FfdTnJ8i/UV91BkpWPnJ8i/UV91OcnyL9RX3UGSlY+cnyL9RX3U5yfIv1Ff dQZKVj5yfIv1FfdTnJ8i/UV91BkpWPnJ8i/UV91OcnyL9RX3UGSlY+cnyL9RX3U5yfIv1FfdQZKV j5yfIv1FfdTnJ8i/UV91BkpWPnJ8i/UV91OcnyL9RX3UGSlY+cnyL9RX3U5yfIv1FfdQZKVj5yfI v1FfdTnJ8i/UV91BkpWPnJ8i/UV91OcnyL9RX3UGSlY+cnyL9RX3U5yfIv1FfdQZKVj5yfIv1Ffd TnJ8i/UV91BkpWPnJ8i/UV91OcnyL9RX3UGSlY+cnyL9RX3U5yfIv1FfdQZKVj5yfIv1FfdTnJ8i /UV91BkpWPnJ8i/UV91OcnyL9RX3UGSlY+cnyL9RX3U5yfIv1FfdQZKVj5yfIv1FfdTnJ8i/UV91 BkpWPnJ8i/UV91OcnyL9RX3UGSlY+cnyL9RX3U5yfIv1FfdQZKVj5yfIv1FfdTnJ8i/UV91BkpWP nJ8i/UV91OcnyL9RX3UGSlY+cnyL9RX3U5yfIv1FfdQZKVj5yfIv1FfdTnJ8i/UV91BkpWPnJ8i/ UV91OcnyL9RX3UGSlY+cnyL9RX3U5yfIv1FfdQZKVj5yfIv1FfdTnJ8i/UV91BkpWPnJ8i/UV91O cnyL9RX3UGSlY+cnyL9RX3U5yfIv1FfdQZKVj5yfIv1FfdTnJ8i/UV91BkpWPnJ8i/UV91OcnyL9 RX3UGSlY+cnyL9RX3U5yfIv1FfdQZKVj5yfIv1FfdTnJ8i/UV91BkpWPnJ8i/UV91OcnyL9RX3UG SvAFe++cnyL9RX3V4EoO3FKSNwPor8KE+aPopShBoT5o+imhPmj6KUoP1KE5+KPor9wPIKUoj80I 81P0U0I81P0UpUlTQjzU/RTQjzU/RSlIH2lKQPij6K/FJHkFKVR86U+QfRTSnyD6KUqSP3SnyD6K /NI8g+ilKo+ykeQV86E+aPopSg/NCfNH0U0J80fRSlA0J80fRX7pSBsB9FKUApSe9I+ivzQnzR9F KUDQnzR9FNCfNH0UpQAhOfij6KvP5P0pMxGw/g5Hi+dilKxl3x+f7SsdpdE0J80fRX7oT5o+ilK2 j80J80fRTQnzR9FKUDQnzR9FNCfNH0UpQNCfNH0U0J80fRSlA0J80fRTQnzR9FKUDQnzR9FNCfNH 0UpQNCfNH0U0J80fRSlA0J80fRTQnzR9FKUDQnzR9FNCfNH0UpQNCfNH0U0J80fRSlA0J80fRTQn zR9FKUDQnzR9FNCfNH0UpQNCfNH0U0J80fRSlA0J80fRTQnzR9FKUDQnzR9FNCfNH0UpQNCfNH0U 0J80fRSlA0J80fRTQnzR9FKUDQnzR9FNCfNH0UpQNCfNH0U0J80fRSlA0J80fRTQnzR9FKUDQnzR 9FNCfNH0UpQNCfNH0U0J80fRSlA0J80fRTQnzR9FKUDQnzR9FNCfNH0UpQNCfNH0U0J80fRSlA0J 80fRTQnzR9FKUDQnzR9FNCfNH0UpQNCfNH0U0J80fRSlA0J80fRTQnzR9FKUDQnzR9FNCfNH0UpQ NCfNH0U0J80fRSlA0J80fRTQnzR9FKUDQnzR9FNCfNH0UpQNCfNH0U0J80fRSlA0J80fRTQnzR9F KUDQnzR9FNCfNH0UpQNCfNH0U0J80fRSlA0J80fRTQnzR9FKUDQnzR9FNCfNH0UpQNCfNH0U0J80 fRSlA0J80fRTQnzR9FKUDQnzR9FNCfNH0UpQNCfNH0U0J80fRSlA0J80fRTQnzR9FKUDQnzR9FNC fNH0UpQNCfNH0U0J80fRSlA0J80fRTQnzR9FKUDQnzR9FNCfNH0UpQNCfNH0U0J80fRSlA0J80fR TQnzR9FKUDQnzR9FNCfNH0UpQNCfNH0U0J80fRSlA0J80fRTQnzR9FKUDQnzR9FeFKUoP//Z --001485f6d9b2fe562304adff0bf9 Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel --001485f6d9b2fe562304adff0bf9-- From xen-devel-bounces@lists.xensource.com Wed Sep 28 05:43:55 2011 Return-path: <xen-devel-bounces@lists.xensource.com> Envelope-to: www-data@lists.xensource.com Delivery-date: Wed, 28 Sep 2011 05:43:55 -0700 Received: from localhost ([127.0.0.1] helo=lists.colo.xensource.com) by lists.xensource.com with esmtp (Exim 4.43) id 1R8tUQ-0006jz-US; Wed, 28 Sep 2011 05:43:55 -0700 Received: from mail182.messagelabs.com ([85.158.139.83]) by lists.xensource.com with esmtp (Exim 4.43) id 1R8tTU-0006Xa-2m for xen-devel@lists.xensource.com; Wed, 28 Sep 2011 05:42:56 -0700 X-Env-Sender: olaf@aepfle.de X-Msg-Ref: server-5.tower-182.messagelabs.com!1317213772!15098592!1 X-Originating-IP: [81.169.146.162] X-StarScan-Version: 6.4.1; banners=-,-,- X-VirusChecked: Checked Received: (qmail 23581 invoked from network); 28 Sep 2011 12:42:52 -0000 Received: from mo-p00-ob.rzone.de (HELO mo-p00-ob.rzone.de) (81.169.146.162) by server-5.tower-182.messagelabs.com with DHE-RSA-AES256-SHA encrypted SMTP; 28 Sep 2011 12:42:52 -0000 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; t=1317213772; l=3144; s=domk; d=aepfle.de; h=In-Reply-To:Content-Transfer-Encoding:Content-Type:MIME-Version: References:Subject:Cc:To:From:Date:X-RZG-CLASS-ID:X-RZG-AUTH; bh=zYzSgJS/WQHtMKdiYkMkVVDq0fk=; b=hQkuXqJ62BhdiUCv2qFR7LJJufeLiytvBIKWN4dlcOZykKweNuA/rnNIl/D2P1Eehxj Wz47TesUPxNcOwYFjEHr9XzALdj60FxUvF2eXTmz8QkHDGsGmI3SLSXlSwkyU1NeY6PqV r9e2a451+f32Kht+008NuDMDLiVVlHucqZI= X-RZG-AUTH: :P2EQZWCpfu+qG7CngxMFH1J+zrwiavkK6tmQaLfmztM8TOFHjC0IFVc= X-RZG-CLASS-ID: mo00 Received: from probook.site (dslb-088-065-092-066.pools.arcor-ip.net [88.65.92.66]) by smtp.strato.de (jimi mo1) (RZmta 26.7) with (DHE-RSA-AES256-SHA encrypted) ESMTPA id e06fadn8SBSpoE ; Wed, 28 Sep 2011 14:42:32 +0200 (MEST) Received: by probook.site (Postfix, from userid 1000) id D0C1118B65; Wed, 28 Sep 2011 14:42:31 +0200 (CEST) Date: Wed, 28 Sep 2011 14:42:31 +0200 From: Olaf Hering <olaf@aepfle.de> To: zhen shi <bickys1986@gmail.com> Message-ID: <20110928124231.GA19629@aepfle.de> References: <CACavRyCNghRyXwUMeWdoyqLwgmOX2KyuD+oerA8W75JL+07wdw@mail.gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <CACavRyCNghRyXwUMeWdoyqLwgmOX2KyuD+oerA8W75JL+07wdw@mail.gmail.com> User-Agent: Mutt/1.5.21.rev5535 (2011-07-01) Cc: xen-devel@lists.xensource.com Subject: [Xen-devel] Re: event channel in xenpaging X-BeenThere: xen-devel@lists.xensource.com X-Mailman-Version: 2.1.5 Precedence: list List-Id: Xen developer discussion <xen-devel.lists.xensource.com> List-Unsubscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe> List-Post: <mailto:xen-devel@lists.xensource.com> List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help> List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=subscribe> Sender: xen-devel-bounces@lists.xensource.com Errors-To: xen-devel-bounces@lists.xensource.com On Wed, Sep 28, zhen shi wrote: > Hi,Olaf, > > I have some questions about event channel in Xenpaging to ask you. > 1) In xenpaging it uses Inter-Domainain Commnication (IDC) between > dom0 and domU to build bidirectional connection,but I found there is > only an event channel notification from xen to dom0 when page faults > happens.It seems that xenpaging_resume_page()->xc_evtchn_notify() > doesn't make any difference.So why don't use vIRQ between dom0 and xen > instead of IDC between dom0 and domU? I talked with Adin Scannel about that, he has changes to use an event channel instead of domctrl for communication. The current event channel usage in xenpaging is a noop. > 2)In your latest patch,[PATCH 9 of 9] xenpaging: watch the domains > /xenpaging/num_pages xenstore value.I found some problems. > aã€In main(),you put the page_out process into while(1) and make the > following change. > if ( interrupted ) > victims[i].gfn = INVALID_MFN; > - else > - evict_victim(paging, &victims[i], fd, i); > I think the" if ( interrupted )" should remove here.Because once > handling page_in requests,the related victims slot should clear, > then in evict_pages we can populate new page in this slot because in > evict_page() the condition as followings: > /* Slot is allocated */ > + if ( victims[slot].gfn != INVALID_MFN ) > + continue; Thanks for spotting this, that part is not correct and the comment is now bogus as well. > bã€In xenpaging_init (),when it goes to err,you add > "free(dom_path);free(watch_targetpages)" in PATCH 9,but I think we > should firstly judge if dom_path and watch_targetpages variables are > NULL.what's more ,if it initializes paging successfully，before "return > paging",we should free (dom_path),and free(watch_targetpages) in > xenpaging_teardown() lastly. > cã€when initializing xenpaging fails,and goes to err,it returns NULL to > main() then exit main(). > If it has already opened event channel,bind event notification,opened > connections to xen successfully when goes to err in > xenpaging_init()，how about dealing with these resources such as > xenpaging_teardown. watch_targetpages is used in xenpaging_wait_for_event_or_timeout(), and dom_path is used elsewhere in upcoming changes. You are right about xenpaging_teardown(), perhaps the error path in xenpaging_init() could make use of that function. > 3)We have tested on Win7-32bit about 40vms to start xenpaging at the > same time.The vm is 1G 2VCPUS,and we page out 180M.Then we put 80-90% > memory pressure on each vm.About one hour later,there happens many > BSOD on vms.and most blue screen code is 0x... 7F or 0x...19. We guess > some special pages which systems need use to run may be paged out and > cause BSOD.and sometimes print out mmio information in messages.Do you > have any ideas about the BSOD on win7-32 bit vms? That sounds like incorrect handling of paged-out pages in Xen, many code paths are supposed to retry the gfn_to_mfn* calls currently, but some do not. I will start to work on that bug soon. Do these guests use the PV drivers? Olaf _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel From xen-devel-bounces@lists.xensource.com Wed Sep 28 05:45:17 2011 Return-path: <xen-devel-bounces@lists.xensource.com> Envelope-to: www-data@lists.xensource.com Delivery-date: Wed, 28 Sep 2011 05:45:17 -0700 Received: from localhost ([127.0.0.1] helo=lists.colo.xensource.com) by lists.xensource.com with esmtp (Exim 4.43) id 1R8tVk-00077v-VU; Wed, 28 Sep 2011 05:45:17 -0700 Received: from mail182.messagelabs.com ([85.158.139.83]) by lists.xensource.com with esmtp (Exim 4.43) id 1R8tUk-0006oL-2E for xen-devel@lists.xensource.com; Wed, 28 Sep 2011 05:44:14 -0700 X-Env-Sender: Ian.Campbell@eu.citrix.com X-Msg-Ref: server-12.tower-182.messagelabs.com!1317213850!19918032!1 X-Originating-IP: [62.200.22.115] X-StarScan-Version: 6.4.1; banners=-,-,- X-VirusChecked: Checked Received: (qmail 6177 invoked from network); 28 Sep 2011 12:44:10 -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 Sep 2011 12:44:10 -0000 X-IronPort-AV: E=Sophos;i="4.68,455,1312156800"; d="scan'208";a="8104347" Received: from lonpmailmx01.citrite.net ([10.30.203.162]) by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5; 28 Sep 2011 12:44:10 +0000 Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net (10.30.203.162) with Microsoft SMTP Server id 8.3.137.0; Wed, 28 Sep 2011 13:44:10 +0100 From: Ian Campbell <Ian.Campbell@eu.citrix.com> To: David Vrabel <david.vrabel@citrix.com> Date: Wed, 28 Sep 2011 13:44:10 +0100 In-Reply-To: <1316800523-30144-4-git-send-email-david.vrabel@citrix.com> References: <1316800523-30144-1-git-send-email-david.vrabel@citrix.com> <1316800523-30144-4-git-send-email-david.vrabel@citrix.com> Organization: Citrix Systems, Inc. Content-Type: text/plain; charset="UTF-8" X-Mailer: Evolution 3.0.3- Content-Transfer-Encoding: 7bit Message-ID: <1317213850.26672.55.camel@zakaz.uk.xensource.com> MIME-Version: 1.0 Cc: Jeremy Fitzhardinge <jeremy@goop.org>, "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>, Rzeszutek Wilk <konrad.wilk@oracle.com>, Konrad Subject: [Xen-devel] Re: [PATCH 3/4] net: xen-netback: use API provided by xenbus module to map rings X-BeenThere: xen-devel@lists.xensource.com X-Mailman-Version: 2.1.5 Precedence: list List-Id: Xen developer discussion <xen-devel.lists.xensource.com> List-Unsubscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe> List-Post: <mailto:xen-devel@lists.xensource.com> List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help> List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=subscribe> Sender: xen-devel-bounces@lists.xensource.com Errors-To: xen-devel-bounces@lists.xensource.com On Fri, 2011-09-23 at 18:55 +0100, David Vrabel wrote: > From: David Vrabel <david.vrabel@citrix.com> > > The xenbus module provides xenbus_map_ring_valloc() and > xenbus_map_ring_vfree(). Use these to map the Tx and Rx ring pages > granted by the frontend. > > Signed-off-by: David Vrabel <david.vrabel@citrix.com> Acked-by: Ian Campbell <ian.campbell@citrix.com> _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel From xen-devel-bounces@lists.xensource.com Wed Sep 28 05:48:54 2011 Return-path: <xen-devel-bounces@lists.xensource.com> Envelope-to: www-data@lists.xensource.com Delivery-date: Wed, 28 Sep 2011 05:48:54 -0700 Received: from localhost ([127.0.0.1] helo=lists.colo.xensource.com) by lists.xensource.com with esmtp (Exim 4.43) id 1R8tZG-0007Xg-K8; Wed, 28 Sep 2011 05:48:54 -0700 Received: from mail174.messagelabs.com ([85.158.138.51]) by lists.xensource.com with esmtp (Exim 4.43) id 1R8tYb-0007Lg-Lm for xen-devel@lists.xensource.com; Wed, 28 Sep 2011 05:48:15 -0700 X-Env-Sender: konrad@oracle.com X-Msg-Ref: server-14.tower-174.messagelabs.com!1317214088!33084303!1 X-Originating-IP: [148.87.113.117] X-StarScan-Version: 6.4.1; banners=-,-,- X-VirusChecked: Checked Received: (qmail 17208 invoked from network); 28 Sep 2011 12:48:10 -0000 Received: from rcsinet15.oracle.com (HELO rcsinet15.oracle.com) (148.87.113.117) by server-14.tower-174.messagelabs.com with DHE-RSA-AES256-SHA encrypted SMTP; 28 Sep 2011 12:48:10 -0000 Received: from ucsinet24.oracle.com (ucsinet24.oracle.com [156.151.31.67]) by rcsinet15.oracle.com (Switch-3.4.4/Switch-3.4.4) with ESMTP id p8SClxJF015128 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Wed, 28 Sep 2011 12:48:01 GMT Received: from acsmt358.oracle.com (acsmt358.oracle.com [141.146.40.158]) by ucsinet24.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id p8SCgIdd009989 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 28 Sep 2011 12:42:18 GMT Received: from abhmt117.oracle.com (abhmt117.oracle.com [141.146.116.69]) by acsmt358.oracle.com (8.12.11.20060308/8.12.11) with ESMTP id p8SClqFK002723; Wed, 28 Sep 2011 07:47:52 -0500 Received: from oracle.com (/207.172.105.198) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Wed, 28 Sep 2011 05:47:52 -0700 Received: by oracle.com (Postfix, from userid 1000) id 9D7821544; Wed, 28 Sep 2011 08:47:50 -0400 (EDT) Date: Wed, 28 Sep 2011 08:47:50 -0400 From: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com> To: "Olivier B." <xen.list@daevel.fr> Subject: Re: [Xen-devel] Re: [patch 1/1] ext4-fix-dirty-extent-when-origin-leaf-extent-reac.patch Message-ID: <20110928124750.GA6072@phenom.oracle.com> References: <BLU157-W499E698F650F554E645F9DDA1C0@phx.gbl> <20110906145347.GA4133@dumpdata.com> <BLU157-W4106FA4CF4EBA78C63FDA0DA1C0@phx.gbl> <4E666C86.5090707@goop.org> <BLU157-W323C330706CB8D7E976BC3DA1F0@phx.gbl> <BLU157-W7DABA5FE01C50C29B1A64DA060@phx.gbl> <BLU157-W25EB1EAC24CC11FA14859ADAF20@phx.gbl> <20110926142808.GG4102@phenom.oracle.com> <20110927193523.GB3309@thunk.org> <4E825F2A.6060506@daevel.fr> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <4E825F2A.6060506@daevel.fr> User-Agent: Mutt/1.5.21 (2010-09-15) X-Source-IP: ucsinet24.oracle.com [156.151.31.67] X-CT-RefId: str=0001.0A090206.4E831781.00EE,ss=1,re=0.000,fgs=0 Cc: xen-devel@lists.xensource.com X-BeenThere: xen-devel@lists.xensource.com X-Mailman-Version: 2.1.5 Precedence: list List-Id: Xen developer discussion <xen-devel.lists.xensource.com> List-Unsubscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe> List-Post: <mailto:xen-devel@lists.xensource.com> List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help> List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=subscribe> Sender: xen-devel-bounces@lists.xensource.com Errors-To: xen-devel-bounces@lists.xensource.com On Wed, Sep 28, 2011 at 01:41:30AM +0200, Olivier B. wrote: > On 27/09/2011 21:35, Ted Ts'o wrote: > >On Mon, Sep 26, 2011 at 10:28:08AM -0400, Konrad Rzeszutek Wilk wrote: > >>> > >>> Attached is the fix, verified in our env. > >> > >>So.. you are asking for this upstream git commit to be back-ported > >>to 2.6.32, right? > > > >I'm curious --- is there a good reason why Xen users are using an > >upstream 2.6.32 kernel? If they are using a distro kernel, fine, but > >then the distro kernel should be providing the support. But at this > >point, 2.6.32 is so positively *ancient* that, I'm personally not > >interesting in providing free, unpaid distro support for users who > >aren't willing to either (a) pay $$$ and get a supported distro > >kernel, or (b) use a much more modern kernel. At this point, Guest > >and Host Xen support is available in 3.0 kernels, so there's really no > >excuse, right? > > > > - Ted > > > > In my case, for Dom0 I use the 2.6.32 kernel from my distrib, because it's stable. > I have stability problems with the kernel 3.0 on Dom0, and as I haven't physical access neither kvm or serial port, I don't know what to report... It just hang randomly, without any line in logs. No physical access? No IPMI? No SOL? > > Does the Xen support on 3.0 kernels should be considered stable ? Yes - it should be considered stable (3.0.4 at least, with one particular patch that is going in 3.0.5: https://lkml.org/lkml/2011/9/2/114). Please help me find whatever is causing your crash. _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel From xen-devel-bounces@lists.xensource.com Wed Sep 28 05:51:07 2011 Return-path: <xen-devel-bounces@lists.xensource.com> Envelope-to: www-data@lists.xensource.com Delivery-date: Wed, 28 Sep 2011 05:51:07 -0700 Received: from localhost ([127.0.0.1] helo=lists.colo.xensource.com) by lists.xensource.com with esmtp (Exim 4.43) id 1R8tbO-0007wt-Tt; Wed, 28 Sep 2011 05:51:07 -0700 Received: from mail182.messagelabs.com ([85.158.139.83]) by lists.xensource.com with esmtp (Exim 4.43) id 1R8tZa-0007d3-Ov for xen-devel@lists.xensource.com; Wed, 28 Sep 2011 05:49:16 -0700 X-Env-Sender: vase@selfip.ru X-Msg-Ref: server-4.tower-182.messagelabs.com!1317210159!20059824!1 X-Originating-IP: [74.125.82.43] X-StarScan-Version: 6.4.1; banners=-,-,- X-VirusChecked: Checked Received: (qmail 2536 invoked from network); 28 Sep 2011 11:42:39 -0000 Received: from mail-ww0-f43.google.com (HELO mail-ww0-f43.google.com) (74.125.82.43) by server-4.tower-182.messagelabs.com with RC4-SHA encrypted SMTP; 28 Sep 2011 11:42:39 -0000 Received: by wwf27 with SMTP id 27so7029302wwf.24 for <xen-devel@lists.xensource.com>; Wed, 28 Sep 2011 04:42:39 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=selfip.ru; s=google; h=mime-version:sender:x-originating-ip:date:x-google-sender-auth :message-id:subject:from:to:content-type; bh=iZ8EtS7ji012MmtdoRszpU10EKyix6MkRv8npGW5KFE=; b=T3h/g5rY9VhX6wLXqAdcmPvQYNU6t0EMfT5HwI+0xTZ7Pxd71SZfXtLobGSZLPV2Wm upwwFfEFjITgWu/XzttFqLP0gE0Yb3oHmd9/SE7JE7ueeC6c1qA7xmgNYfzvVP6bB1FT Ezqp8BgnjpPbzHGDElLJ9rgWteQ8JyhKKyXZA= MIME-Version: 1.0 Received: by 10.216.50.143 with SMTP id z15mr996976web.16.1317210158380; Wed, 28 Sep 2011 04:42:38 -0700 (PDT) Received: by 10.216.4.69 with HTTP; Wed, 28 Sep 2011 04:42:38 -0700 (PDT) X-Originating-IP: [85.143.161.18] Date: Wed, 28 Sep 2011 15:42:38 +0400 X-Google-Sender-Auth: z64nfxg7cHNSdGEG0eexvxdi5Ds Message-ID: <CACaajQv4jgsQZhR62g8-k69OTuzNGHB2N4ZZfcs0TZJGbqa3JQ@mail.gmail.com> From: Vasiliy Tolstov <v.tolstov@selfip.ru> To: xen-devel@lists.xensource.com Subject: [Xen-devel] xenbus/xenstore protocol description X-BeenThere: xen-devel@lists.xensource.com X-Mailman-Version: 2.1.5 Precedence: list List-Id: Xen developer discussion <xen-devel.lists.xensource.com> List-Unsubscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe> List-Post: <mailto:xen-devel@lists.xensource.com> List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help> List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=subscribe> Content-Type: multipart/mixed; boundary="===============0165725284==" Sender: xen-devel-bounces@lists.xensource.com Errors-To: xen-devel-bounces@lists.xensource.com --===============0165725284== Content-Type: multipart/alternative; boundary=0016e6db7bac95b5ff04adfee3f0 --0016e6db7bac95b5ff04adfee3f0 Content-Type: text/plain; charset=UTF-8 Hello. Can somebody send me link to xensotre/xenbus protocol description, i can't use xenstore libs and want to read/write some values to xenstore via os read/write to /proc/xen/xenbus... -- Vasiliy Tolstov, Clodo.ru e-mail: v.tolstov@selfip.ru jabber: vase@selfip.ru --0016e6db7bac95b5ff04adfee3f0 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Hello. Can somebody send me link to xensotre/xenbus protocol description, i= can't use xenstore libs and want to read/write some values to xenstore= via os read/write to /proc/xen/xenbus...<div><br clear=3D"all"><div><br></= div> -- <br><span style=3D"border-collapse:collapse;color:rgb(136, 136, 136);fon= t-family:arial, sans-serif;font-size:13px"><div><div>Vasiliy Tolstov,</div>= <div>Clodo.ru</div><div>e-mail: <a href=3D"mailto:v.tolstov@selfip.ru" targ= et=3D"_blank">v.tolstov@selfip.ru</a></div> <div>jabber: <a href=3D"mailto:vase@selfip.ru" target=3D"_blank">vase@selfi= p.ru</a></div></div></span><br> </div> --0016e6db7bac95b5ff04adfee3f0-- --===============0165725284== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel --===============0165725284==-- From xen-devel-bounces@lists.xensource.com Wed Sep 28 06:13:58 2011 Return-path: <xen-devel-bounces@lists.xensource.com> Envelope-to: www-data@lists.xensource.com Delivery-date: Wed, 28 Sep 2011 06:13:58 -0700 Received: from localhost ([127.0.0.1] helo=lists.colo.xensource.com) by lists.xensource.com with esmtp (Exim 4.43) id 1R8txV-0000EE-6v; Wed, 28 Sep 2011 06:13:57 -0700 Received: from mail216.messagelabs.com ([85.158.143.99]) by lists.xensource.com with esmtp (Exim 4.43) id 1R8twP-0008Tg-OK for xen-devel@lists.xensource.com; Wed, 28 Sep 2011 06:12:54 -0700 X-Env-Sender: konrad@oracle.com X-Msg-Ref: server-9.tower-216.messagelabs.com!1317215565!19895816!1 X-Originating-IP: [141.146.126.227] X-StarScan-Version: 6.4.1; banners=-,-,- X-VirusChecked: Checked Received: (qmail 25588 invoked from network); 28 Sep 2011 13:12:46 -0000 Received: from acsinet15.oracle.com (HELO acsinet15.oracle.com) (141.146.126.227) by server-9.tower-216.messagelabs.com with DHE-RSA-AES256-SHA encrypted SMTP; 28 Sep 2011 13:12:46 -0000 Received: from ucsinet23.oracle.com (ucsinet23.oracle.com [156.151.31.71]) by acsinet15.oracle.com (Switch-3.4.4/Switch-3.4.4) with ESMTP id p8SDCbMF018431 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Wed, 28 Sep 2011 13:12:39 GMT Received: from acsmt357.oracle.com (acsmt357.oracle.com [141.146.40.157]) by ucsinet23.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id p8SDCavl016899 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 28 Sep 2011 13:12:37 GMT Received: from abhmt101.oracle.com (abhmt101.oracle.com [141.146.116.53]) by acsmt357.oracle.com (8.12.11.20060308/8.12.11) with ESMTP id p8SDCVTE000540; Wed, 28 Sep 2011 08:12:31 -0500 Received: from oracle.com (/207.172.105.198) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Wed, 28 Sep 2011 06:12:31 -0700 Received: by oracle.com (Postfix, from userid 1000) id 2FDDF1451; Wed, 28 Sep 2011 09:12:29 -0400 (EDT) Date: Wed, 28 Sep 2011 09:12:29 -0400 From: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com> To: Stefano Stabellini <stefano.stabellini@eu.citrix.com> Subject: Re: [Xen-devel] Re: [PATCH v4 2/2] xen: modify kernel mappings corresponding to granted pages Message-ID: <20110928131229.GA10270@phenom.oracle.com> References: <alpine.DEB.2.00.1109081944150.12963@kaball-desktop> <20110921145853.GA541@phenom.oracle.com> <alpine.DEB.2.00.1109231412220.8700@kaball-desktop> <20110923144538.GA10701@phenom.oracle.com> <alpine.DEB.2.00.1109271549030.3519@kaball-desktop> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <alpine.DEB.2.00.1109271549030.3519@kaball-desktop> User-Agent: Mutt/1.5.21 (2010-09-15) X-Source-IP: ucsinet23.oracle.com [156.151.31.71] X-CT-RefId: str=0001.0A090201.4E831D48.0005,ss=1,re=0.000,fgs=0 Cc: Jeremy Fitzhardinge <jeremy@goop.org>, "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>, "linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org> X-BeenThere: xen-devel@lists.xensource.com X-Mailman-Version: 2.1.5 Precedence: list List-Id: Xen developer discussion <xen-devel.lists.xensource.com> List-Unsubscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe> List-Post: <mailto:xen-devel@lists.xensource.com> List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help> List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=subscribe> Sender: xen-devel-bounces@lists.xensource.com Errors-To: xen-devel-bounces@lists.xensource.com > > Anyhow, If you want to modify your patchset to check PagePrivate bit > > and set the SetPagePrivate/set_page_private - go ahead. > > I'll do that. Preempted you a bit :-) http://lists.xensource.com/archives/html/xen-devel/2011-09/msg01364.html > > > > > + gnttab_set_map_op(&map->kmap_ops[i], pte_maddr, > > > > > + map->flags | > > > > > + GNTMAP_host_map | > > > > > + GNTMAP_contains_pte, > > > > > + map->grants[i].ref, > > > > > + map->grants[i].domid); > > > > > + } > > > > > > > > So, on startup.. (before this function is called) the > > > > find_grant_ptes is called which pretty much does the exact thing for > > > > each virtual address. Except its flags are GNTMAP_application_map > > > > instead of GNTMAP_host_map. > > > > > > > > It even uses the same type structure.. It fills out map_ops[i] one. > > > > > > > > Can we use that instead of adding a new structure? > > > > > > Do you mean moving this code inside find_grant_ptes? > > > I don't think that can be done because find_grant_ptes is called on a > > > range of virtual addresses while this is called on an array of struct > > > pages. It is true that the current implementation of > > > > But aren't that 'range of virtual address' of struct pages? You > > are using 'alloc_xenballooned_pages' to get those pages and that is > > what the 'range of virtual adresses' is walking through. > > it is not the same range of virtual addresses OK, but the pte_maddr is the same, isn't it? > > > > alloc_xenballooned_pages is going to return a consecutive set of pages > > > but it might not always be the case. > > > > I am sensing some grand plans in work here? I thought we are going to > > try to simply our lives and see about making alloc_xenballooned_pages > > returned sane pages that are !PageHighMem (or if they are PageHighMem they > > are already pinned, and set in the &init_mm)? > > > > I am just thinking in terms of lookup_address and arbitrary_virt_to_machine > > calls being done _twice_. And it seems like we have the find_grant_ptes > > which does the bulk of this already - so why not piggyback on it? > > It has to be done twice: once for the user ptes and once for the kernel > mappings of map->pages. > > > > Besides that, the patch set looks fine. .. How do I reproduce the failures > > you had encountered with the AIO? > > > > Just setup and use upstream qemu and configure your VM to use a disk on > a file (file:). OK. _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel From xen-devel-bounces@lists.xensource.com Wed Sep 28 06:26:54 2011 Return-path: <xen-devel-bounces@lists.xensource.com> Envelope-to: www-data@lists.xensource.com Delivery-date: Wed, 28 Sep 2011 06:26:54 -0700 Received: from localhost ([127.0.0.1] helo=lists.colo.xensource.com) by lists.xensource.com with esmtp (Exim 4.43) id 1R8uA2-0000o0-OJ; Wed, 28 Sep 2011 06:26:54 -0700 Received: from mail216.messagelabs.com ([85.158.143.99]) by lists.xensource.com with esmtp (Exim 4.43) id 1R8u9C-0000bR-EX for xen-devel@lists.xensource.com; Wed, 28 Sep 2011 06:26:03 -0700 X-Env-Sender: konrad@oracle.com X-Msg-Ref: server-11.tower-216.messagelabs.com!1317216357!12310551!1 X-Originating-IP: [148.87.113.117] X-StarScan-Version: 6.4.1; banners=-,-,- X-VirusChecked: Checked Received: (qmail 12195 invoked from network); 28 Sep 2011 13:25:59 -0000 Received: from rcsinet15.oracle.com (HELO rcsinet15.oracle.com) (148.87.113.117) by server-11.tower-216.messagelabs.com with DHE-RSA-AES256-SHA encrypted SMTP; 28 Sep 2011 13:25:59 -0000 Received: from acsinet21.oracle.com (acsinet21.oracle.com [141.146.126.237]) by rcsinet15.oracle.com (Switch-3.4.4/Switch-3.4.4) with ESMTP id p8SDPsYe032720 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Wed, 28 Sep 2011 13:25:56 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 p8SDPr6Q008714 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 28 Sep 2011 13:25:54 GMT Received: from abhmt107.oracle.com (abhmt107.oracle.com [141.146.116.59]) by acsmt358.oracle.com (8.12.11.20060308/8.12.11) with ESMTP id p8SDPmKS001453; Wed, 28 Sep 2011 08:25:48 -0500 Received: from oracle.com (/207.172.105.198) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Wed, 28 Sep 2011 06:25:47 -0700 Received: by oracle.com (Postfix, from userid 1000) id 311B71451; Wed, 28 Sep 2011 09:25:46 -0400 (EDT) Date: Wed, 28 Sep 2011 09:25:46 -0400 From: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com> To: David Vrabel <david.vrabel@citrix.com> Subject: Re: [Xen-devel] Re: xen: memory initialization/balloon fixes (#3) Message-ID: <20110928132546.GD10270@phenom.oracle.com> References: <1316089768-22461-1-git-send-email-david.vrabel@citrix.com> <20110924020759.GA27796@phenom.oracle.com> <4E81D909.8020603@citrix.com> <20110927231033.GA4712@phenom.oracle.com> <4E82FAAE.6020206@citrix.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <4E82FAAE.6020206@citrix.com> User-Agent: Mutt/1.5.21 (2010-09-15) X-Source-IP: acsinet21.oracle.com [141.146.126.237] X-Auth-Type: Internal IP X-CT-RefId: str=0001.0A090203.4E832064.00A1:SCFMA922111,ss=1,re=-4.000,fgs=0 Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com> X-BeenThere: xen-devel@lists.xensource.com X-Mailman-Version: 2.1.5 Precedence: list List-Id: Xen developer discussion <xen-devel.lists.xensource.com> List-Unsubscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe> List-Post: <mailto:xen-devel@lists.xensource.com> List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help> List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=subscribe> Sender: xen-devel-bounces@lists.xensource.com Errors-To: xen-devel-bounces@lists.xensource.com On Wed, Sep 28, 2011 at 11:45:02AM +0100, David Vrabel wrote: > On 28/09/11 00:10, Konrad Rzeszutek Wilk wrote: > >>> (XEN) Xen-e820 RAM map: > >>> (XEN) 0000000000000000 - 000000000009d800 (usable) > >> > >> It's because it's not correctly handling the half-page of RAM at the end > >> of this region. > >> > >> I don't have access to any test boxes with a dodgy BIOS like this so can > >> you test this patch? If it works I'll fold it in and post an updated > >> series. > > > > It works. Albeit I think we are going to hit a problem with dmidecode > > if the DMI data is right in the reserved region > > > > (http://lists.xensource.com/archives/html/xen-devel/2011-09/msg01299.html) > > > > As in, if it starts in 9D800 - we consider 0->9d as RAM PFN, and 9e->100 as 1-1 > > mapping. > > > > I am thinking that perhaps the call to xen_set_phys_identity, where > > we call PFN_UP(x) should be replaced with PFN_DOWN(x). That way > > we would consider 0>9c as RAM PFN and 9D->100 as 1-1 mapping. > > I almost did an equivalent change (see below) but discarded it as it > would have resulting in overlapping regions and attempting to > release/map some pages twice. > > I think we will have to move the release/map until after the final e820 > map has been sanitized so there are no overlapping regions. <nods>Fortunatly for us, the overlap does not happen - they are just next to each other. BTW, I think Xen hypervisor does the E820 sanitisation so there shouldn't be any funny entries. > > I'll prepare another patch for this. OK. > > > That would imply a new patch to your series naturally. > >> > >> Can you remember why this page alignment was required? I'd like to > > > > The e820_* calls define how the memory subsystem will use it. > > It ended at some point assuming that the full page is RAM even thought > > it was only half-RAM and tried to use it and blew the machine up. > > > > The fix was to make the calls to the e820_* with size and regions > > that were page-aligned. > > > > Anyhow, here is what the bootup looks now: > > > > [ 0.000000] Freeing 9e-a0 pfn range: 2 pages freed > > [ 0.000000] 1-1 mapping on 9e->a0 > > [ 0.000000] Freeing a0-100 pfn range: 96 pages freed > > [ 0.000000] 1-1 mapping on a0->100 > > [ 0.000000] Freeing 7fff0-80000 pfn range: 16 pages freed > > [ 0.000000] 1-1 mapping on 7fff0->80000 > > [ 0.000000] Freeing cfef0-cfef5 pfn range: 5 pages freed > > [ 0.000000] 1-1 mapping on cfef0->cfef5 > > [ 0.000000] Freeing cfef5-cff7f pfn range: 138 pages freed > > [ 0.000000] 1-1 mapping on cfef5->cff7f > > [ 0.000000] Freeing cff7f-d0000 pfn range: 129 pages freed > > [ 0.000000] 1-1 mapping on cff7f->d0000 > > [ 0.000000] Freeing d0000-f0000 pfn range: 131072 pages freed > > [ 0.000000] 1-1 mapping on d0000->f0000 > > [ 0.000000] Freeing f0000-f4b58 pfn range: 19288 pages freed > > [ 0.000000] 1-1 mapping on f0000->fec10 > > [ 0.000000] 1-1 mapping on fec10->fee01 > > [ 0.000000] 1-1 mapping on fee01->100000 > > [ 0.000000] Released 150746 pages of unused memory > > [ 0.000000] Set 196994 page(s) to 1-1 mapping > > [ 0.000000] BIOS-provided physical RAM map: > > [ 0.000000] Xen: 0000000000000000 - 000000000009d000 (usable) > > [ 0.000000] Xen: 000000000009d800 - 0000000000100000 (reserved) > > [ 0.000000] Xen: 0000000000100000 - 000000007fff0000 (usable) > > [ 0.000000] Xen: 000000007fff0000 - 0000000080000000 (reserved) > > > > > >> update the comment with the reason because the bare-metal x86 memory > >> init code doesn't appear to fixup the memory map in this way. > >> > >> diff --git a/arch/x86/xen/setup.c b/arch/x86/xen/setup.c > >> index 986661b..e473c4c 100644 > >> --- a/arch/x86/xen/setup.c > >> +++ b/arch/x86/xen/setup.c > >> @@ -178,6 +178,19 @@ static unsigned long __init xen_get_max_pages(void) > >> return min(max_pages, MAX_DOMAIN_PAGES); > >> } > >> > >> +static void xen_e820_add_region(u64 start, u64 size, int type) Might as well call this function "xen_align_and_add_e820_region" > >> +{ > >> + u64 end = start + size; > >> + > >> + /* Align RAM regions to page boundaries. */ > >> + if (type == E820_RAM || type == E820_UNUSABLE) { > > > > Hm, do we care about E820_UNUSABLE to be page aligned? > > If so, please comment why. > > Er. We don't really but I think this if needs to be: > > /* > * Page align regions. > * > * Reduce RAM regions and expand other (reserved) regions. > */ > if (type == E820_RAM || type == E820_UNUSABLE) { > start = PAGE_ALIGN(start); > end &= ~((u64)PAGE_SIZE - 1); > } else { > start &= ~((u64)PAGE_SIZE - 1); > end = PAGE_ALIGN(start); > } > > So reserved regions also become page aligned (which is part of the fix > for the dmidecode bug). <nods> That should be part of a seperate patch (well, the dmidecde patch). Instead of the "infinite loop, won't boot on Konrad's machines with non-standard E820". > > >> + start = PAGE_ALIGN(start); > > > > Is that actually safe? Say it starts a 9ffff? We would > > end up using 9f000 which is not right. > > PAGE_ALIGN() (and ALIGN()) round upwards. <smacks his head> Right. _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel From xen-devel-bounces@lists.xensource.com Wed Sep 28 06:28:20 2011 Return-path: <xen-devel-bounces@lists.xensource.com> Envelope-to: www-data@lists.xensource.com Delivery-date: Wed, 28 Sep 2011 06:28:20 -0700 Received: from localhost ([127.0.0.1] helo=lists.colo.xensource.com) by lists.xensource.com with esmtp (Exim 4.43) id 1R8uBQ-0001HJ-0I; Wed, 28 Sep 2011 06:28:20 -0700 Received: from mail27.messagelabs.com ([193.109.254.147]) by lists.xensource.com with esmtp (Exim 4.43) id 1R8u9j-0000ia-Hf for xen-devel@lists.xensource.com; Wed, 28 Sep 2011 06:26:38 -0700 X-Env-Sender: Ian.Jackson@eu.citrix.com X-Msg-Ref: server-12.tower-27.messagelabs.com!1317216375!44292751!1 X-Originating-IP: [62.200.22.115] X-StarScan-Version: 6.4.1; banners=-,-,- X-VirusChecked: Checked Received: (qmail 18227 invoked from network); 28 Sep 2011 13:26:15 -0000 Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115) by server-12.tower-27.messagelabs.com with RC4-SHA encrypted SMTP; 28 Sep 2011 13:26:15 -0000 X-IronPort-AV: E=Sophos;i="4.68,455,1312156800"; d="scan'208";a="8105559" Received: from lonpmailmx01.citrite.net ([10.30.203.162]) by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5; 28 Sep 2011 13:26:31 +0000 Received: from norwich.cam.xci-test.com (10.80.248.129) by smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id 8.3.137.0; Wed, 28 Sep 2011 14:26:32 +0100 Received: from mariner.cam.xci-test.com ([10.80.2.22] helo=mariner.uk.xensource.com ident=Debian-exim) by norwich.cam.xci-test.com with esmtp (Exim 4.72) (envelope-from <Ian.Jackson@eu.citrix.com>) id 1R8u9f-0002Bw-BZ; Wed, 28 Sep 2011 13:26:31 +0000 Received: from iwj by mariner.uk.xensource.com with local (Exim 4.69) (envelope-from <Ian.Jackson@eu.citrix.com>) id 1R8u9f-0007If-An; Wed, 28 Sep 2011 14:26:31 +0100 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Message-ID: <20099.8327.326129.357335@mariner.uk.xensource.com> Date: Wed, 28 Sep 2011 14:26:31 +0100 To: Ian Campbell <Ian.Campbell@citrix.com> Subject: Re: [Xen-devel] Xen document day (Oct 12 or 26) In-Reply-To: <1317195656.13424.73.camel@dagon.hellion.org.uk> References: <20110922130618.GA13238@phenom.oracle.com> <CAFLBxZaAaXTUtW5+VkxPnr_MR0fbW+d1Mzu4y0x=gEOaX9e0OQ@mail.gmail.com> <20110922174002.GA1205@phenom.oracle.com> <20098.1097.824552.541924@mariner.uk.xensource.com> <CAP2B85-=CbMgUGSwO2utvkeLLqk8A1vjhKrPwe2OD+0daAtqsA@mail.gmail.com> <1317195656.13424.73.camel@dagon.hellion.org.uk> X-Mailer: VM 8.0.9 under Emacs 21.4.1 (i486-pc-linux-gnu) From: Ian Jackson <Ian.Jackson@eu.citrix.com> Cc: Daniel Castro <evil.dani@gmail.com>, "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>, Konrad Rzeszutek Wilk <konrad.wilk@oracle.com> X-BeenThere: xen-devel@lists.xensource.com X-Mailman-Version: 2.1.5 Precedence: list List-Id: Xen developer discussion <xen-devel.lists.xensource.com> List-Unsubscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe> List-Post: <mailto:xen-devel@lists.xensource.com> List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help> List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=subscribe> Sender: xen-devel-bounces@lists.xensource.com Errors-To: xen-devel-bounces@lists.xensource.com Ian Campbell writes ("Re: [Xen-devel] Xen document day (Oct 12 or 26)"): > Since the guest APIs are stable there should be relatively little churn > so perhaps a wiki page (or even series of pages) would be appropriate > for this sort of thing? I want this to be in-tree. If it's in-tree, we can refuse patches which do not update the documentation. > I think this would be good too and in fact even more important than the > interface documentation. Everyone needs to be able to build Xen to hack > on it but only a subset need to know any particular API. > > Also although we recommend that users consume Xen via their distro where > possible such a guide would also help any who would rather build from > scratch (e.g. because we've asked them to "try the latest version" or to > bisect a bug etc). This would be a good candidate for a wiki page, backed up by revisions of the in-tree README. Ian. _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel From xen-devel-bounces@lists.xensource.com Wed Sep 28 06:29:16 2011 Return-path: <xen-devel-bounces@lists.xensource.com> Envelope-to: www-data@lists.xensource.com Delivery-date: Wed, 28 Sep 2011 06:29:16 -0700 Received: from localhost ([127.0.0.1] helo=lists.colo.xensource.com) by lists.xensource.com with esmtp (Exim 4.43) id 1R8uCK-0001eQ-6F; Wed, 28 Sep 2011 06:29:16 -0700 Received: from mail27.messagelabs.com ([193.109.254.147]) by lists.xensource.com with esmtp (Exim 4.43) id 1R8uBb-0001M3-W2 for xen-devel@lists.xensource.com; Wed, 28 Sep 2011 06:28:33 -0700 X-Env-Sender: Ian.Jackson@eu.citrix.com X-Msg-Ref: server-7.tower-27.messagelabs.com!1317216484!50503453!1 X-Originating-IP: [62.200.22.115] X-StarScan-Version: 6.4.1; banners=-,-,- X-VirusChecked: Checked Received: (qmail 8464 invoked from network); 28 Sep 2011 13:28:04 -0000 Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115) by server-7.tower-27.messagelabs.com with RC4-SHA encrypted SMTP; 28 Sep 2011 13:28:04 -0000 X-IronPort-AV: E=Sophos;i="4.68,455,1312156800"; d="scan'208";a="8105623" Received: from lonpmailmx01.citrite.net ([10.30.203.162]) by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5; 28 Sep 2011 13:28:28 +0000 Received: from norwich.cam.xci-test.com (10.80.248.129) by smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id 8.3.137.0; Wed, 28 Sep 2011 14:28:28 +0100 Received: from mariner.cam.xci-test.com ([10.80.2.22] helo=mariner.uk.xensource.com ident=Debian-exim) by norwich.cam.xci-test.com with esmtp (Exim 4.72) (envelope-from <Ian.Jackson@eu.citrix.com>) id 1R8uBY-0002CS-7a; Wed, 28 Sep 2011 13:28:28 +0000 Received: from iwj by mariner.uk.xensource.com with local (Exim 4.69) (envelope-from <Ian.Jackson@eu.citrix.com>) id 1R8uBY-0007Il-2L; Wed, 28 Sep 2011 14:28:28 +0100 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 8bit Message-ID: <20099.8444.3827.578982@mariner.uk.xensource.com> Date: Wed, 28 Sep 2011 14:28:28 +0100 To: Roger Pau =?iso-8859-1?Q?Monn=E9?= <roger.pau@entel.upc.edu> Subject: Re: [Xen-devel] [PATCH 2 of 2] libxl: add support for booting PV domains from NetBSD using raw files as disks In-Reply-To: <CAPLaKK7m_3=qV0NCvjY2vrJbRJvWhhhLJR5e0P3P+2tgQnjFcg@mail.gmail.com> References: <patchbomb.1316187417@loki> <aff3960421768180410c.1316187419@loki> <20098.362.319162.127153@mariner.uk.xensource.com> <CAPLaKK7m_3=qV0NCvjY2vrJbRJvWhhhLJR5e0P3P+2tgQnjFcg@mail.gmail.com> X-Mailer: VM 8.0.9 under Emacs 21.4.1 (i486-pc-linux-gnu) From: Ian Jackson <Ian.Jackson@eu.citrix.com> Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com> X-BeenThere: xen-devel@lists.xensource.com X-Mailman-Version: 2.1.5 Precedence: list List-Id: Xen developer discussion <xen-devel.lists.xensource.com> List-Unsubscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe> List-Post: <mailto:xen-devel@lists.xensource.com> List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help> List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=subscribe> Sender: xen-devel-bounces@lists.xensource.com Errors-To: xen-devel-bounces@lists.xensource.com Roger Pau Monné writes ("Re: [Xen-devel] [PATCH 2 of 2] libxl: add support for booting PV domains from NetBSD using raw files as disks"): > NetBSD still uses the "loop" ("vnd" on NetBSD) device for files, > because it doesn't have support for qdisk or blktap. If we don't check > the hotplug-status before removing the vbd from xenstore (and only > look at state) it might be removed before the hotplug scripts are > executed, and the disk is never unmounted. This is why we need to > check the hotplug-status before removing vbd from xenstore. Of course, > I could call the hotplug scripts from libxl directly (for disk and > inet interfaces), and we could get rid of xenbackendd. Right. Yes, I think you should call the hotplug scripts from libxl and get rid of xenbackendd. That is the way we want the Linux world to go, although of course Linux needs to call hotplug scripts in fewer cases. > >> @@ -482,7 +519,7 @@ int libxl__devices_destroy(libxl__gc *gc > >>          tv.tv_usec = 0; > >>          while (n_watches > 0) { > >>              if (wait_for_dev_destroy(gc, &tv)) { > >> -                break; > >> +                continue; > >>              } else { > >>                  n_watches--; > >>              } > > > > I'm not sure I understand this change, or why it's needed. > > This change is more explained in the series, basically libxl was not > waiting for all devices to disconnect, because when it returned from > wait_for_dev_destroy exited the loop immediately, even if we where > watching for more than one device to disconnect. Right. Ian. _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel From xen-devel-bounces@lists.xensource.com Wed Sep 28 06:30:04 2011 Return-path: <xen-devel-bounces@lists.xensource.com> Envelope-to: www-data@lists.xensource.com Delivery-date: Wed, 28 Sep 2011 06:30:04 -0700 Received: from localhost ([127.0.0.1] helo=lists.colo.xensource.com) by lists.xensource.com with esmtp (Exim 4.43) id 1R8uD6-00021Q-GB; Wed, 28 Sep 2011 06:30:04 -0700 Received: from mail216.messagelabs.com ([85.158.143.99]) by lists.xensource.com with esmtp (Exim 4.43) id 1R8uBc-0001M7-2S for xen-devel@lists.xensource.com; Wed, 28 Sep 2011 06:28:34 -0700 X-Env-Sender: konrad@oracle.com X-Msg-Ref: server-8.tower-216.messagelabs.com!1317216507!16770225!1 X-Originating-IP: [141.146.126.227] X-StarScan-Version: 6.4.1; banners=-,-,- X-VirusChecked: Checked Received: (qmail 27488 invoked from network); 28 Sep 2011 13:28:28 -0000 Received: from acsinet15.oracle.com (HELO acsinet15.oracle.com) (141.146.126.227) by server-8.tower-216.messagelabs.com with DHE-RSA-AES256-SHA encrypted SMTP; 28 Sep 2011 13:28:28 -0000 Received: from rtcsinet21.oracle.com (rtcsinet21.oracle.com [66.248.204.29]) by acsinet15.oracle.com (Switch-3.4.4/Switch-3.4.4) with ESMTP id p8SDSOir008058 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Wed, 28 Sep 2011 13:28:26 GMT Received: from acsmt358.oracle.com (acsmt358.oracle.com [141.146.40.158]) by rtcsinet21.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id p8SDSN5q014399 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 28 Sep 2011 13:28:23 GMT Received: from abhmt119.oracle.com (abhmt119.oracle.com [141.146.116.71]) by acsmt358.oracle.com (8.12.11.20060308/8.12.11) with ESMTP id p8SDSHDd003587; Wed, 28 Sep 2011 08:28:17 -0500 Received: from oracle.com (/207.172.105.198) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Wed, 28 Sep 2011 06:28:17 -0700 Received: by oracle.com (Postfix, from userid 1000) id 705DF1451; Wed, 28 Sep 2011 09:28:15 -0400 (EDT) Date: Wed, 28 Sep 2011 09:28:15 -0400 From: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com> To: Anthony Wright <anthony@overnetdata.com> Subject: Re: [Xen-devel] dmidecode doesn't work under xen 4.1.1 on certain hardware Message-ID: <20110928132815.GE10270@phenom.oracle.com> References: <4E7C6BDC.8070005@overnetdata.com> <20110923133200.GC19579@phenom.oracle.com> <4E7C9C8B.2010108@overnetdata.com> <20110926141322.GD4102@phenom.oracle.com> <4E8090D4.2090009@overnetdata.com> <20110926193732.GA10007@phenom.oracle.com> <4E82E429.2080600@overnetdata.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <4E82E429.2080600@overnetdata.com> User-Agent: Mutt/1.5.21 (2010-09-15) X-Source-IP: rtcsinet21.oracle.com [66.248.204.29] X-CT-RefId: str=0001.0A090202.4E8320FB.0024,ss=1,re=0.000,fgs=0 Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com> X-BeenThere: xen-devel@lists.xensource.com X-Mailman-Version: 2.1.5 Precedence: list List-Id: Xen developer discussion <xen-devel.lists.xensource.com> List-Unsubscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe> List-Post: <mailto:xen-devel@lists.xensource.com> List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help> List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=subscribe> Sender: xen-devel-bounces@lists.xensource.com Errors-To: xen-devel-bounces@lists.xensource.com > >> (XEN) WARNING: Only the first 16 GB of the physical memory map can be accessed by Xen in 32-bit mode. > > That bites ^^^^ > >> (XEN) Truncating RAM from 17825792kB to 16777216kB > Does this mean that 32 bit Xen can only use a maximum of 16GB of RAM? > > If so, is there a way to use 32 bit Xen tools with a 64 bit Xen hypervisor? Yes. I've been doing that without any trouble. > > >> (XEN) Xen-e820 RAM map: > >> (XEN) 0000000000000000 - 0000000000099800 (usable) > >> (XEN) 0000000000099800 - 00000000000a0000 (reserved) > >> (XEN) 00000000000e4000 - 0000000000100000 (reserved) > >> (XEN) 0000000000100000 - 00000000bf780000 (usable) > >> (XEN) 00000000bf78e000 - 00000000bf790000 type 9 > > Ok, so this patch should shed some light and potentially fix your problem. Please > > try it out and attach the serial log for Linux kernel. Thx. > The patch works perfectly. I've attached a copy of the kernel log with > 'debug loglevel=8' Yeeey! Great. Thanks for testing it. We are re-doing that whole E820 parsing for the next version of Linux (3.2) so will integrate the "essence" of that patch. Would you be up for testing a different variant of that patch just to make sure? _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel From xen-devel-bounces@lists.xensource.com Wed Sep 28 06:33:28 2011 Return-path: <xen-devel-bounces@lists.xensource.com> Envelope-to: www-data@lists.xensource.com Delivery-date: Wed, 28 Sep 2011 06:33:28 -0700 Received: from localhost ([127.0.0.1] helo=lists.colo.xensource.com) by lists.xensource.com with esmtp (Exim 4.43) id 1R8uGN-0002WB-D9; Wed, 28 Sep 2011 06:33:28 -0700 Received: from mail174.messagelabs.com ([85.158.138.51]) by lists.xensource.com with esmtp (Exim 4.43) id 1R8uFw-0002Jl-Ez for xen-devel@lists.xensource.com; Wed, 28 Sep 2011 06:33:00 -0700 X-Env-Sender: Ian.Jackson@eu.citrix.com X-Msg-Ref: server-4.tower-174.messagelabs.com!1317216777!33114040!1 X-Originating-IP: [62.200.22.115] X-StarScan-Version: 6.4.1; banners=-,-,- X-VirusChecked: Checked Received: (qmail 2604 invoked from network); 28 Sep 2011 13:32:57 -0000 Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115) by server-4.tower-174.messagelabs.com with RC4-SHA encrypted SMTP; 28 Sep 2011 13:32:57 -0000 X-IronPort-AV: E=Sophos;i="4.68,455,1312156800"; d="scan'208";a="8105774" Received: from lonpmailmx01.citrite.net ([10.30.203.162]) by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5; 28 Sep 2011 13:32:57 +0000 Received: from norwich.cam.xci-test.com (10.80.248.129) by smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id 8.3.137.0; Wed, 28 Sep 2011 14:32:57 +0100 Received: from mariner.cam.xci-test.com ([10.80.2.22] helo=mariner.uk.xensource.com ident=Debian-exim) by norwich.cam.xci-test.com with esmtp (Exim 4.72) (envelope-from <Ian.Jackson@eu.citrix.com>) id 1R8uFs-0002DX-MU; Wed, 28 Sep 2011 13:32:56 +0000 Received: from iwj by mariner.uk.xensource.com with local (Exim 4.69) (envelope-from <Ian.Jackson@eu.citrix.com>) id 1R8uFr-0007Iv-4y; Wed, 28 Sep 2011 14:32:56 +0100 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Message-ID: <20099.8711.134578.942269@mariner.uk.xensource.com> Date: Wed, 28 Sep 2011 14:32:55 +0100 To: Ian Campbell <Ian.Campbell@citrix.com> Subject: Re: [Xen-devel] [PATCH 2 of 2] libxl: add support for booting PV domains from NetBSD using raw files as disks In-Reply-To: <1317197638.13424.104.camel@dagon.hellion.org.uk> References: <patchbomb.1316187417@loki> <aff3960421768180410c.1316187419@loki> <20098.362.319162.127153@mariner.uk.xensource.com> <1317197638.13424.104.camel@dagon.hellion.org.uk> X-Mailer: VM 8.0.9 under Emacs 21.4.1 (i486-pc-linux-gnu) From: Ian Jackson <Ian.Jackson@eu.citrix.com> Cc: Roger Pau Monne <roger.pau@entel.upc.edu>, "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com> X-BeenThere: xen-devel@lists.xensource.com X-Mailman-Version: 2.1.5 Precedence: list List-Id: Xen developer discussion <xen-devel.lists.xensource.com> List-Unsubscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe> List-Post: <mailto:xen-devel@lists.xensource.com> List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help> List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=subscribe> Sender: xen-devel-bounces@lists.xensource.com Errors-To: xen-devel-bounces@lists.xensource.com Ian Campbell writes ("Re: [Xen-devel] [PATCH 2 of 2] libxl: add support for booting PV domains from NetBSD using raw files as disks"): > I think you've explained the scheme you have in mind for deprecating > hotplug scripts before but could you remind me (and for the lists > benefit)? Is it simply a case of shelling out to the vbd's configured > "script=" at the right points on attach and detach? Yes. The other elements of the block hotplug scripts don't do anything any more on Linux I think, and currently libxl does not cope with script= being set, so from a Linux pov this is a new feature for libxl. > Would we then need special handling to turn "file:<X>" into > "phy:<X>,script=block-loop"? I think this should be done behind the scenes. The backend-specific code in libxl should call some kind of "invoke this script" function which would also be used for explicit "script=". On NetBSD, how do "more exciting" script= things work ? Eg, iscsi or nbd. On Linux the idea is that the hotplug script sets up your nbd which causes a real block device to appear, and that block device is used by blkback. > I seem to remember something about setting up a faked out backend area > for each backend and running the scripts against that instead of the > real one. We would need to do that to support (eg) pygrub over nbd. > There was a subtle difference between NetBSD's and Linux's handling of > these with xend. On Linux xend used to setup and manage the loopback > device and create a simple phy backend referencing it. On NetBSD xend > just sets up a file or phy backend as appropriate and the scripts which > run out of xenbackendd take care of setting up the loopback as necessary > and filing in the real device in xenstore. On teardown the loopback > device needs to be cleaned up (and this is what currently fails). I'm not a fan of these approaches with a separate daemon. We should avoid that if we can as it produces a lot of complication. Ian. _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel From xen-devel-bounces@lists.xensource.com Wed Sep 28 06:39:07 2011 Return-path: <xen-devel-bounces@lists.xensource.com> Envelope-to: www-data@lists.xensource.com Delivery-date: Wed, 28 Sep 2011 06:39:07 -0700 Received: from localhost ([127.0.0.1] helo=lists.colo.xensource.com) by lists.xensource.com with esmtp (Exim 4.43) id 1R8uLq-0003DO-1v; Wed, 28 Sep 2011 06:39:06 -0700 Received: from mail174.messagelabs.com ([85.158.138.51]) by lists.xensource.com with esmtp (Exim 4.43) id 1R8uLE-000315-MD for xen-devel@lists.xensource.com; Wed, 28 Sep 2011 06:38:30 -0700 X-Env-Sender: Ian.Campbell@eu.citrix.com X-Msg-Ref: server-12.tower-174.messagelabs.com!1317217104!33086721!1 X-Originating-IP: [66.165.176.89] X-StarScan-Version: 6.4.1; banners=-,-,- X-VirusChecked: Checked Received: (qmail 21616 invoked from network); 28 Sep 2011 13:38:25 -0000 Received: from smtp.citrix.com (HELO SMTP.CITRIX.COM) (66.165.176.89) by server-12.tower-174.messagelabs.com with RC4-SHA encrypted SMTP; 28 Sep 2011 13:38:25 -0000 X-IronPort-AV: E=Sophos;i="4.68,455,1312171200"; d="scan'208";a="17771726" Received: from ftlpmailmx01.citrite.net ([10.13.107.65]) by FTLPIPO01.CITRIX.COM with ESMTP/TLS/RC4-MD5; 28 Sep 2011 09:38:02 -0400 Received: from smtp01.ad.xensource.com (10.219.128.104) by smtprelay.citrix.com (10.13.107.65) with Microsoft SMTP Server id 8.3.137.0; Wed, 28 Sep 2011 09:38:01 -0400 Received: from cosworth.uk.xensource.com (cosworth.uk.xensource.com [10.80.16.52]) by smtp01.ad.xensource.com (8.13.1/8.13.1) with ESMTP id p8SDc07Z022540; Wed, 28 Sep 2011 06:38:01 -0700 Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Mercurial-Node: 945b1d50724b3d68c562859a0e38f6ee4d9fe612 Message-ID: <945b1d50724b3d68c562.1317217079@cosworth.uk.xensource.com> User-Agent: Mercurial-patchbomb/1.6.4 Date: Wed, 28 Sep 2011 14:37:59 +0100 From: Ian Campbell <ian.campbell@citrix.com> To: xen-devel@lists.xensource.com Cc: Ian Campbell <ian.campbell@citrix.com> Subject: [Xen-devel] [PATCH] xl: fixup command line handling for several commands X-BeenThere: xen-devel@lists.xensource.com X-Mailman-Version: 2.1.5 Precedence: list List-Id: Xen developer discussion <xen-devel.lists.xensource.com> List-Unsubscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe> List-Post: <mailto:xen-devel@lists.xensource.com> List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help> List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=subscribe> Sender: xen-devel-bounces@lists.xensource.com Errors-To: xen-devel-bounces@lists.xensource.com # HG changeset patch # User Ian Campbell <ian.campbell@citrix.com> # Date 1317217065 -3600 # Node ID 945b1d50724b3d68c562859a0e38f6ee4d9fe612 # Parent b099e064f9970f27bf7dbf24b97715371240bb4c xl: fixup command line handling for several commands. def_getopt already checks for a minimum number of arguments for us. "xl save" simply need to use the correct argument for that value, contrary to the change I made in 23876:b113d626cfaf "xl block-list" does not need to check for at least 2 arguments, since it's already been done by def_getopt. "xl network-list" would previous accept zero arguments and just print the table header. Insist on a domain argument. Signed-off-by: Ian Campbell <ian.campbell@citrix.com> diff -r b099e064f997 -r 945b1d50724b tools/libxl/xl_cmdimpl.c --- a/tools/libxl/xl_cmdimpl.c Wed Sep 28 14:18:19 2011 +0100 +++ b/tools/libxl/xl_cmdimpl.c Wed Sep 28 14:37:45 2011 +0100 @@ -2921,7 +2921,7 @@ int main_save(int argc, char **argv) int checkpoint = 0; int opt; - while ((opt = def_getopt(argc, argv, "c", "save", 1)) != -1) { + while ((opt = def_getopt(argc, argv, "c", "save", 2)) != -1) { switch (opt) { case 0: case 2: return opt; @@ -2931,7 +2931,7 @@ int main_save(int argc, char **argv) } } - if (argc-optind < 2 || argc-optind > 3) { + if (argc-optind > 3) { help("save"); return 2; } @@ -4080,7 +4080,7 @@ int main_networklist(int argc, char **ar libxl_nicinfo *nics; unsigned int nb, i; - if ((opt = def_getopt(argc, argv, "", "network-list", 0)) != -1) + if ((opt = def_getopt(argc, argv, "", "network-list", 1)) != -1) return opt; /* Idx BE MAC Hdl Sta evch txr/rxr BE-path */ @@ -4151,10 +4151,6 @@ int main_blockattach(int argc, char **ar if ((opt = def_getopt(argc, argv, "", "block-attach", 2)) != -1) return opt; - if ((argc-optind < 2)) { - help("block-attach"); - return 2; - } if (domain_qualifier_to_domid(argv[optind], &fe_domid, 0) < 0) { fprintf(stderr, "%s is an invalid domain identifier\n", argv[optind]); _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel From xen-devel-bounces@lists.xensource.com Wed Sep 28 06:42:42 2011 Return-path: <xen-devel-bounces@lists.xensource.com> Envelope-to: www-data@lists.xensource.com Delivery-date: Wed, 28 Sep 2011 06:42:42 -0700 Received: from localhost ([127.0.0.1] helo=lists.colo.xensource.com) by lists.xensource.com with esmtp (Exim 4.43) id 1R8uPJ-0003dd-WD; Wed, 28 Sep 2011 06:42:42 -0700 Received: from mail174.messagelabs.com ([85.158.138.51]) by lists.xensource.com with esmtp (Exim 4.43) id 1R8uOj-0003Ri-7H for xen-devel@lists.xensource.com; Wed, 28 Sep 2011 06:42:05 -0700 X-Env-Sender: dunlapg@gmail.com X-Msg-Ref: server-3.tower-174.messagelabs.com!1317217320!27035929!1 X-Originating-IP: [209.85.210.171] X-StarScan-Version: 6.4.1; banners=-,-,- X-VirusChecked: Checked Received: (qmail 31480 invoked from network); 28 Sep 2011 13:42:02 -0000 Received: from mail-iy0-f171.google.com (HELO mail-iy0-f171.google.com) (209.85.210.171) by server-3.tower-174.messagelabs.com with RC4-SHA encrypted SMTP; 28 Sep 2011 13:42:02 -0000 Received: by iagv1 with SMTP id v1so9348446iag.30 for <xen-devel@lists.xensource.com>; Wed, 28 Sep 2011 06:42:00 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=tdi7RBzuNLVeNEb5MZWXIHr61jd0/wrL+de6S70ym/s=; b=iiZpJt2bdNwEkxLNwe58dAYm0QD5lK6srxUdtziynsYQR9P8T3p/ppi11iFvDgIkCP NnCs5GZnlSG9Fb8dEddD3DkHueIdeXVc8OugiA2Kk1Lbkq2/UwsNT+SOVjpqwFvV3o9a clx7bTnALb20jTWL+w8BKIw4M3M6n4BcP9GvY= MIME-Version: 1.0 Received: by 10.231.84.196 with SMTP id k4mr12712005ibl.45.1317217315890; Wed, 28 Sep 2011 06:41:55 -0700 (PDT) Received: by 10.231.48.9 with HTTP; Wed, 28 Sep 2011 06:41:55 -0700 (PDT) In-Reply-To: <CAFLBxZapQt0ZAERTgn09tVUeKuHq0tYan9+TUPu=Bsa2S-mL5Q@mail.gmail.com> References: <88b8953f5f5a514c84d7.1317054792@andrewcoop.uk.xensource.com> <CAFLBxZapQt0ZAERTgn09tVUeKuHq0tYan9+TUPu=Bsa2S-mL5Q@mail.gmail.com> Date: Wed, 28 Sep 2011 14:41:55 +0100 X-Google-Sender-Auth: d-cZMPcm3U0-OG_aiIBYzWgct8I Message-ID: <CAFLBxZb3KjqPmbaVcnvzGOCJf=fAcRd_mL=+3upKNXFGwOVEEA@mail.gmail.com> Subject: Re: [Xen-devel] [PATCH] IRQ: Fix trace bug introduced by c/s 23816:7f357e1ef60a From: George Dunlap <George.Dunlap@eu.citrix.com> To: Andrew Cooper <andrew.cooper3@citrix.com> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: xen-devel@lists.xensource.com, Keir Fraser <keir@xen.org> X-BeenThere: xen-devel@lists.xensource.com X-Mailman-Version: 2.1.5 Precedence: list List-Id: Xen developer discussion <xen-devel.lists.xensource.com> List-Unsubscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe> List-Post: <mailto:xen-devel@lists.xensource.com> List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help> List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=subscribe> Sender: xen-devel-bounces@lists.xensource.com Errors-To: xen-devel-bounces@lists.xensource.com Sorry, NACK-ing this for now, since it hasn't been applied, and I'm about to post a patch that subsumes it. -George On Tue, Sep 27, 2011 at 12:54 PM, George Dunlap <George.Dunlap@eu.citrix.com> wrote: > Acked-by: George Dunlap <george.dunlap@eu.citrix.com> > > On Mon, Sep 26, 2011 at 5:33 PM, Andrew Cooper > <andrew.cooper3@citrix.com> wrote: >> c/s 23816:7f357e1ef60a introduces cfg->old_vector and removes a loop >> as a result. >> >> Outside the loop, 'vector' is set to cfg->vector, but the loop aliased >> 'vector' to mean cfg->old_vector at the point at which this TRACE_3D >> is executed. >> >> Therefore, when the loop was removed, the code still compiled, although >> the trace would record incorrect information. >> >> Signed-off-by: Andrew Cooper <andrew.cooper3@citrix.com> >> >> diff -r a422e2a4451e -r 88b8953f5f5a xen/arch/x86/irq.c >> --- a/xen/arch/x86/irq.c =A0 =A0 =A0 =A0Sun Sep 18 00:26:52 2011 +0100 >> +++ b/xen/arch/x86/irq.c =A0 =A0 =A0 =A0Mon Sep 26 17:31:32 2011 +0100 >> @@ -235,7 +235,7 @@ static void __clear_irq_vector(int irq) >> =A0 =A0 cpus_and(tmp_mask, cfg->old_cpu_mask, cpu_online_map); >> =A0 =A0 for_each_cpu_mask(cpu, tmp_mask) { >> =A0 =A0 =A0 =A0 ASSERT( per_cpu(vector_irq, cpu)[cfg->old_vector] =3D=3D= irq ); >> - =A0 =A0 =A0 =A0TRACE_3D(TRC_HW_IRQ_MOVE_FINISH, irq, vector, cpu); >> + =A0 =A0 =A0 =A0TRACE_3D(TRC_HW_IRQ_MOVE_FINISH, irq, cfg->old_vector, = cpu); >> =A0 =A0 =A0 =A0 per_cpu(vector_irq, cpu)[cfg->old_vector] =3D -1; >> =A0 =A0 =A0} >> >> >> _______________________________________________ >> Xen-devel mailing list >> Xen-devel@lists.xensource.com >> http://lists.xensource.com/xen-devel >> > _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel From xen-devel-bounces@lists.xensource.com Wed Sep 28 06:43:48 2011 Return-path: <xen-devel-bounces@lists.xensource.com> Envelope-to: www-data@lists.xensource.com Delivery-date: Wed, 28 Sep 2011 06:43:48 -0700 Received: from localhost ([127.0.0.1] helo=lists.colo.xensource.com) by lists.xensource.com with esmtp (Exim 4.43) id 1R8uQO-00040W-IG; Wed, 28 Sep 2011 06:43:48 -0700 Received: from mail21.messagelabs.com ([85.158.143.35]) by lists.xensource.com with esmtp (Exim 4.43) id 1R8uPc-0003jK-Uw for xen-devel@lists.xensource.com; Wed, 28 Sep 2011 06:43:01 -0700 X-Env-Sender: olaf@aepfle.de X-Msg-Ref: server-4.tower-21.messagelabs.com!1317217340!61953465!1 X-Originating-IP: [81.169.146.161] X-StarScan-Version: 6.4.1; banners=-,-,- X-VirusChecked: Checked Received: (qmail 23326 invoked from network); 28 Sep 2011 13:42:21 -0000 Received: from mo-p00-ob.rzone.de (HELO mo-p00-ob.rzone.de) (81.169.146.161) by server-4.tower-21.messagelabs.com with EDH-RSA-DES-CBC3-SHA encrypted SMTP; 28 Sep 2011 13:42:21 -0000 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; t=1317217377; l=2449; s=domk; d=aepfle.de; h=In-Reply-To:Content-Type:MIME-Version:References:Subject:Cc:To:From: Date:X-RZG-CLASS-ID:X-RZG-AUTH; bh=Fi6GU9sf9NzAk9pEflX6u7/LiDg=; b=MRnKAKh0PT3m8FbuIXpoC/bt5koCynj9VtwXnMHEAdZ9I+MRKpUqNeZ6Uxnha//8dlw UyS7mwq+nbFtnoKMwX3ciEpLXX80/PO5/qvokMrMGBB4o0yrSPrbDbQcnXdAGpP7LOTL6 QfHpEGpjovOPX6oM8mlChE3Cc/CkfwN0uxs= X-RZG-AUTH: :P2EQZWCpfu+qG7CngxMFH1J+zrwiavkK6tmQaLfmztM8TOFHjC0IFVc= X-RZG-CLASS-ID: mo00 Received: from probook.site (dslb-088-065-092-066.pools.arcor-ip.net [88.65.92.66]) by smtp.strato.de (fruni mo6) (RZmta 26.8) with (EDH-RSA-DES-CBC3-SHA encrypted) ESMTPA id z00119n8SDLJwO ; Wed, 28 Sep 2011 15:42:41 +0200 (MEST) Received: by probook.site (Postfix, from userid 1000) id 49DCE18B65; Wed, 28 Sep 2011 15:42:41 +0200 (CEST) Date: Wed, 28 Sep 2011 15:42:41 +0200 From: Olaf Hering <olaf@aepfle.de> To: Ian Jackson <Ian.Jackson@eu.citrix.com> Subject: Re: [Xen-devel] [PATCH] xenpaging: libxl support Message-ID: <20110928134241.GA17921@aepfle.de> References: <c9a9779fd9581666c327.1316100011@probook.site> <20097.65118.350804.135806@mariner.uk.xensource.com> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline In-Reply-To: <20097.65118.350804.135806@mariner.uk.xensource.com> User-Agent: Mutt/1.5.21.rev5535 (2011-07-01) Cc: xen-devel@lists.xensource.com X-BeenThere: xen-devel@lists.xensource.com X-Mailman-Version: 2.1.5 Precedence: list List-Id: Xen developer discussion <xen-devel.lists.xensource.com> List-Unsubscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe> List-Post: <mailto:xen-devel@lists.xensource.com> List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help> List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=subscribe> Sender: xen-devel-bounces@lists.xensource.com Errors-To: xen-devel-bounces@lists.xensource.com On Tue, Sep 27, Ian Jackson wrote: > Olaf Hering writes ("[Xen-devel] [PATCH] xenpaging: libxl support"): > > The patch adds four new config options: > > xenpaging=<int> , the number of pages to page-out > ... > > +libxl_xenpaging_info = Struct("xenpaging_info",[ > > + ("xenpaging", integer, False, "number of pages"), > ... > > + if (!xlu_cfg_get_long (config, "xenpaging", &l)) > > + xp_info->xenpaging = l; > > The config file setting should be a number of megabytes, just like > "memory", "maxmem", etc., not a number of pages. And at the libxl > interface it should be a number of kilobytes like max_memkb et al. I will change that part. > Also as I said at the hackathon, I think that we need a more > sophisticated approach to the interaction with ballooning. I would > like to see the argument to the xenpaging daemon not be a target > number of pages to page out, but rather for it to be a total memory > usage target. That would mean xenpaging has to monitor tot_pages and try to reach the configured number? > The effect of this would be that you could tell a guest to balloon > down, but also tell xenpaging to page it out, and balance between > ballooning and paging is then up to the guest. Does a guest even know its paged? If I understand it correctly, mem-set will ask the guests balloon driver to work toward that number, but if xenpaging is instructed to page-out the entire guest, the guest wont notice it. A new mem-tot_pages command (with a better name) would limit the amount of consumed mfns, while mem-set would limit the amount of mfns the guest balloon driver thinks it has. Is it that what you have in mind? > > +static int libxl__create_xenpaging(libxl__gc *gc, char *dom_name, uint32_t domid, libxl_xenpaging_info *xp_info) > > +{ > > + [a lot of stuff] > > Can any of this be factored out and made common with the device model > creation ? Yes. The current device model startup uses the spawn functions, and things like *_record_pid and libxl__wait_for_* should be part of the spawn interface itself because the way libxl__spawn_spawn works a read from the pipe has to happen in some way. I will prepare patches for review. > Also: > - what deletes the logfile, if anything ? The pagefile is unlinked by xenpaging on exit. > - will the xenpaging daemon automatically exit if the domain dies ? xenpaging has a watch on @releaseDomain. Olaf _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel From xen-devel-bounces@lists.xensource.com Wed Sep 28 06:46:03 2011 Return-path: <xen-devel-bounces@lists.xensource.com> Envelope-to: www-data@lists.xensource.com Delivery-date: Wed, 28 Sep 2011 06:46:03 -0700 Received: from localhost ([127.0.0.1] helo=lists.colo.xensource.com) by lists.xensource.com with esmtp (Exim 4.43) id 1R8uSZ-0004Ug-F6; Wed, 28 Sep 2011 06:46:03 -0700 Received: from mail216.messagelabs.com ([85.158.143.99]) by lists.xensource.com with esmtp (Exim 4.43) id 1R8uS9-0004IT-9c for xen-devel@lists.xensource.com; Wed, 28 Sep 2011 06:45:38 -0700 X-Env-Sender: George.Dunlap@eu.citrix.com X-Msg-Ref: server-8.tower-216.messagelabs.com!1317217533!16772740!1 X-Originating-IP: [66.165.176.63] X-StarScan-Version: 6.4.1; banners=-,-,- X-VirusChecked: Checked Received: (qmail 14197 invoked from network); 28 Sep 2011 13:45:34 -0000 Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63) by server-8.tower-216.messagelabs.com with RC4-SHA encrypted SMTP; 28 Sep 2011 13:45:34 -0000 X-IronPort-AV: E=Sophos;i="4.68,455,1312171200"; d="scan'208";a="164970673" Received: from ftlpmailmx01.citrite.net ([10.13.107.65]) by FTLPIPO02.CITRIX.COM with ESMTP/TLS/RC4-MD5; 28 Sep 2011 09:45:32 -0400 Received: from smtp01.ad.xensource.com (10.219.128.104) by smtprelay.citrix.com (10.13.107.65) with Microsoft SMTP Server id 8.3.137.0; Wed, 28 Sep 2011 09:45:32 -0400 Received: from [127.0.1.1] (elijah.uk.xensource.com [10.80.2.24]) by smtp01.ad.xensource.com (8.13.1/8.13.1) with ESMTP id p8SDjVxn022555; Wed, 28 Sep 2011 06:45:31 -0700 Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Mercurial-Node: b8359ca81cd9b37d4a31b31d9e5d4e9f9e8bab2e Message-ID: <b8359ca81cd9b37d4a31.1317217584@elijah> User-Agent: Mercurial-patchbomb/1.4.3 Date: Wed, 28 Sep 2011 14:46:24 +0100 From: George Dunlap <george.dunlap@eu.citrix.com> To: xen-devel@lists.xensource.com Cc: george.dunlap@eu.citrix.com Subject: [Xen-devel] [PATCH] xen,irq: Clean up __clear_irq_vector X-BeenThere: xen-devel@lists.xensource.com X-Mailman-Version: 2.1.5 Precedence: list List-Id: Xen developer discussion <xen-devel.lists.xensource.com> List-Unsubscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe> List-Post: <mailto:xen-devel@lists.xensource.com> List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help> List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=subscribe> Sender: xen-devel-bounces@lists.xensource.com Errors-To: xen-devel-bounces@lists.xensource.com Fix and clean up the logic to __clear_irq_vector(). We always need to clear the things related to cfg->vector. If the IRQ is currently in motion, then we need to also clear out things related to cfg->old_vector. This patch reorganizes the function to make the parallels between the two clean-ups more obvious. The main functional change here is with cfg->used_vectors; make sure to clear cfg->vector always (even if !cfg->move_in_progress); if cfg->move_in_progress, clear cfg->old_vector as well. Signed-off-by: George Dunlap <george.dunlap@eu.citrix.com> diff -r 59c7213b5949 -r b8359ca81cd9 xen/arch/x86/irq.c --- a/xen/arch/x86/irq.c Tue Sep 27 18:39:15 2011 +0100 +++ b/xen/arch/x86/irq.c Wed Sep 28 14:46:12 2011 +0100 @@ -211,33 +211,23 @@ static void dynamic_irq_cleanup(unsigned static void __clear_irq_vector(int irq) { - int cpu, vector; + int cpu, vector, old_vector; cpumask_t tmp_mask; struct irq_cfg *cfg = irq_cfg(irq); BUG_ON(!cfg->vector); + /* Always clear cfg->vector */ vector = cfg->vector; cpus_and(tmp_mask, cfg->cpu_mask, cpu_online_map); - trace_irq_mask(TRC_HW_IRQ_CLEAR_VECTOR, irq, vector, &tmp_mask); - - for_each_cpu_mask(cpu, tmp_mask) + for_each_cpu_mask(cpu, tmp_mask) { + ASSERT( per_cpu(vector_irq, cpu)[vector] == irq ); per_cpu(vector_irq, cpu)[vector] = -1; + } cfg->vector = IRQ_VECTOR_UNASSIGNED; cpus_clear(cfg->cpu_mask); - cfg->used = IRQ_UNUSED; - - if (likely(!cfg->move_in_progress)) - return; - - cpus_and(tmp_mask, cfg->old_cpu_mask, cpu_online_map); - for_each_cpu_mask(cpu, tmp_mask) { - ASSERT( per_cpu(vector_irq, cpu)[cfg->old_vector] == irq ); - TRACE_3D(TRC_HW_IRQ_MOVE_FINISH, irq, vector, cpu); - per_cpu(vector_irq, cpu)[cfg->old_vector] = -1; - } if ( cfg->used_vectors ) { @@ -245,9 +235,33 @@ static void __clear_irq_vector(int irq) clear_bit(vector, cfg->used_vectors); } - cfg->move_in_progress = 0; + cfg->used = IRQ_UNUSED; + + trace_irq_mask(TRC_HW_IRQ_CLEAR_VECTOR, irq, vector, &tmp_mask); + + if (likely(!cfg->move_in_progress)) + return; + + /* If we were in motion, also clear cfg->old_vector */ + old_vector = cfg->old_vector; + cpus_and(tmp_mask, cfg->old_cpu_mask, cpu_online_map); + + for_each_cpu_mask(cpu, tmp_mask) { + ASSERT( per_cpu(vector_irq, cpu)[old_vector] == irq ); + TRACE_3D(TRC_HW_IRQ_MOVE_FINISH, irq, old_vector, cpu); + per_cpu(vector_irq, cpu)[old_vector] = -1; + } + cfg->old_vector = IRQ_VECTOR_UNASSIGNED; cpus_clear(cfg->old_cpu_mask); + + if ( cfg->used_vectors ) + { + ASSERT(test_bit(old_vector, cfg->used_vectors)); + clear_bit(old_vector, cfg->used_vectors); + } + + cfg->move_in_progress = 0; } void clear_irq_vector(int irq) _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel From xen-devel-bounces@lists.xensource.com Wed Sep 28 06:47:27 2011 Return-path: <xen-devel-bounces@lists.xensource.com> Envelope-to: www-data@lists.xensource.com Delivery-date: Wed, 28 Sep 2011 06:47:27 -0700 Received: from localhost ([127.0.0.1] helo=lists.colo.xensource.com) by lists.xensource.com with esmtp (Exim 4.43) id 1R8uTv-0004s0-QD; Wed, 28 Sep 2011 06:47:27 -0700 Received: from mail182.messagelabs.com ([85.158.139.83]) by lists.xensource.com with esmtp (Exim 4.43) id 1R8uTX-0004fj-0q for xen-devel@lists.xensource.com; Wed, 28 Sep 2011 06:47:03 -0700 X-Env-Sender: Andrew.Cooper3@citrix.com X-Msg-Ref: server-4.tower-182.messagelabs.com!1317217618!20081946!1 X-Originating-IP: [66.165.176.63] X-StarScan-Version: 6.4.1; banners=-,-,- X-VirusChecked: Checked Received: (qmail 7204 invoked from network); 28 Sep 2011 13:46:59 -0000 Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63) by server-4.tower-182.messagelabs.com with RC4-SHA encrypted SMTP; 28 Sep 2011 13:46:59 -0000 X-IronPort-AV: E=Sophos;i="4.68,455,1312171200"; d="scan'208";a="164970940" Received: from ftlpmailmx01.citrite.net ([10.13.107.65]) by FTLPIPO02.CITRIX.COM with ESMTP/TLS/RC4-MD5; 28 Sep 2011 09:46:58 -0400 Received: from [10.80.2.18] (10.80.2.18) by FTLPMAILMX01.citrite.net (10.13.107.65) with Microsoft SMTP Server id 8.3.137.0; Wed, 28 Sep 2011 09:46:57 -0400 Message-ID: <4E832551.8080907@citrix.com> Date: Wed, 28 Sep 2011 14:46:57 +0100 From: Andrew Cooper <andrew.cooper3@citrix.com> User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.2.21) Gecko/20110831 Lightning/1.0b2 Thunderbird/3.1.13 MIME-Version: 1.0 To: <xen-devel@lists.xensource.com> Subject: Re: [Xen-devel] [PATCH] xen,irq: Clean up __clear_irq_vector References: <b8359ca81cd9b37d4a31.1317217584@elijah> In-Reply-To: <b8359ca81cd9b37d4a31.1317217584@elijah> Content-Type: text/plain; charset="ISO-8859-1" Content-Transfer-Encoding: 7bit X-BeenThere: xen-devel@lists.xensource.com X-Mailman-Version: 2.1.5 Precedence: list List-Id: Xen developer discussion <xen-devel.lists.xensource.com> List-Unsubscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe> List-Post: <mailto:xen-devel@lists.xensource.com> List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help> List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=subscribe> Sender: xen-devel-bounces@lists.xensource.com Errors-To: xen-devel-bounces@lists.xensource.com On 28/09/11 14:46, George Dunlap wrote: > Fix and clean up the logic to __clear_irq_vector(). > > We always need to clear the things related to cfg->vector. > > If the IRQ is currently in motion, then we need to also clear > out things related to cfg->old_vector. > > This patch reorganizes the function to make the parallels between > the two clean-ups more obvious. > > The main functional change here is with cfg->used_vectors; make > sure to clear cfg->vector always (even if !cfg->move_in_progress); > if cfg->move_in_progress, clear cfg->old_vector as well. > > Signed-off-by: George Dunlap <george.dunlap@eu.citrix.com> Acked-by: Andrew Cooper <andrew.cooper3@citrix.com> > diff -r 59c7213b5949 -r b8359ca81cd9 xen/arch/x86/irq.c > --- a/xen/arch/x86/irq.c Tue Sep 27 18:39:15 2011 +0100 > +++ b/xen/arch/x86/irq.c Wed Sep 28 14:46:12 2011 +0100 > @@ -211,33 +211,23 @@ static void dynamic_irq_cleanup(unsigned > > static void __clear_irq_vector(int irq) > { > - int cpu, vector; > + int cpu, vector, old_vector; > cpumask_t tmp_mask; > struct irq_cfg *cfg = irq_cfg(irq); > > BUG_ON(!cfg->vector); > > + /* Always clear cfg->vector */ > vector = cfg->vector; > cpus_and(tmp_mask, cfg->cpu_mask, cpu_online_map); > > - trace_irq_mask(TRC_HW_IRQ_CLEAR_VECTOR, irq, vector, &tmp_mask); > - > - for_each_cpu_mask(cpu, tmp_mask) > + for_each_cpu_mask(cpu, tmp_mask) { > + ASSERT( per_cpu(vector_irq, cpu)[vector] == irq ); > per_cpu(vector_irq, cpu)[vector] = -1; > + } > > cfg->vector = IRQ_VECTOR_UNASSIGNED; > cpus_clear(cfg->cpu_mask); > - cfg->used = IRQ_UNUSED; > - > - if (likely(!cfg->move_in_progress)) > - return; > - > - cpus_and(tmp_mask, cfg->old_cpu_mask, cpu_online_map); > - for_each_cpu_mask(cpu, tmp_mask) { > - ASSERT( per_cpu(vector_irq, cpu)[cfg->old_vector] == irq ); > - TRACE_3D(TRC_HW_IRQ_MOVE_FINISH, irq, vector, cpu); > - per_cpu(vector_irq, cpu)[cfg->old_vector] = -1; > - } > > if ( cfg->used_vectors ) > { > @@ -245,9 +235,33 @@ static void __clear_irq_vector(int irq) > clear_bit(vector, cfg->used_vectors); > } > > - cfg->move_in_progress = 0; > + cfg->used = IRQ_UNUSED; > + > + trace_irq_mask(TRC_HW_IRQ_CLEAR_VECTOR, irq, vector, &tmp_mask); > + > + if (likely(!cfg->move_in_progress)) > + return; > + > + /* If we were in motion, also clear cfg->old_vector */ > + old_vector = cfg->old_vector; > + cpus_and(tmp_mask, cfg->old_cpu_mask, cpu_online_map); > + > + for_each_cpu_mask(cpu, tmp_mask) { > + ASSERT( per_cpu(vector_irq, cpu)[old_vector] == irq ); > + TRACE_3D(TRC_HW_IRQ_MOVE_FINISH, irq, old_vector, cpu); > + per_cpu(vector_irq, cpu)[old_vector] = -1; > + } > + > cfg->old_vector = IRQ_VECTOR_UNASSIGNED; > cpus_clear(cfg->old_cpu_mask); > + > + if ( cfg->used_vectors ) > + { > + ASSERT(test_bit(old_vector, cfg->used_vectors)); > + clear_bit(old_vector, cfg->used_vectors); > + } > + > + cfg->move_in_progress = 0; > } > > void clear_irq_vector(int irq) > > _______________________________________________ > Xen-devel mailing list > Xen-devel@lists.xensource.com > http://lists.xensource.com/xen-devel -- Andrew Cooper - Dom0 Kernel Engineer, Citrix XenServer T: +44 (0)1223 225 900, http://www.citrix.com _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel From xen-devel-bounces@lists.xensource.com Wed Sep 28 06:48:17 2011 Return-path: <xen-devel-bounces@lists.xensource.com> Envelope-to: www-data@lists.xensource.com Delivery-date: Wed, 28 Sep 2011 06:48:17 -0700 Received: from localhost ([127.0.0.1] helo=lists.colo.xensource.com) by lists.xensource.com with esmtp (Exim 4.43) id 1R8uUj-0005Ev-Se; Wed, 28 Sep 2011 06:48:17 -0700 Received: from mail174.messagelabs.com ([85.158.138.51]) by lists.xensource.com with esmtp (Exim 4.43) id 1R8uU1-0004tf-2E for xen-devel@lists.xensource.com; Wed, 28 Sep 2011 06:47:33 -0700 X-Env-Sender: konrad@oracle.com X-Msg-Ref: server-6.tower-174.messagelabs.com!1317217648!30952395!1 X-Originating-IP: [141.146.126.227] X-StarScan-Version: 6.4.1; banners=-,-,- X-VirusChecked: Checked Received: (qmail 30163 invoked from network); 28 Sep 2011 13:47:29 -0000 Received: from acsinet15.oracle.com (HELO acsinet15.oracle.com) (141.146.126.227) by server-6.tower-174.messagelabs.com with DHE-RSA-AES256-SHA encrypted SMTP; 28 Sep 2011 13:47:29 -0000 Received: from ucsinet23.oracle.com (ucsinet23.oracle.com [156.151.31.71]) by acsinet15.oracle.com (Switch-3.4.4/Switch-3.4.4) with ESMTP id p8SDlOES001673 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Wed, 28 Sep 2011 13:47:26 GMT Received: from acsmt358.oracle.com (acsmt358.oracle.com [141.146.40.158]) by ucsinet23.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id p8SDlNeX025101 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 28 Sep 2011 13:47:24 GMT Received: from abhmt118.oracle.com (abhmt118.oracle.com [141.146.116.70]) by acsmt358.oracle.com (8.12.11.20060308/8.12.11) with ESMTP id p8SDlH29019653; Wed, 28 Sep 2011 08:47:18 -0500 Received: from oracle.com (/207.172.105.198) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Wed, 28 Sep 2011 06:47:17 -0700 Received: by oracle.com (Postfix, from userid 1000) id 13FB51451; Wed, 28 Sep 2011 09:47:12 -0400 (EDT) Date: Wed, 28 Sep 2011 09:47:12 -0400 From: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com> To: David Vrabel <david.vrabel@citrix.com> Subject: Re: [Xen-devel] Re: xen: memory initialization/balloon fixes (#3) Message-ID: <20110928134712.GG10270@phenom.oracle.com> References: <1316089768-22461-1-git-send-email-david.vrabel@citrix.com> <20110924020759.GA27796@phenom.oracle.com> <4E81D909.8020603@citrix.com> <20110927231033.GA4712@phenom.oracle.com> <4E82FAAE.6020206@citrix.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <4E82FAAE.6020206@citrix.com> User-Agent: Mutt/1.5.21 (2010-09-15) X-Source-IP: ucsinet23.oracle.com [156.151.31.71] X-CT-RefId: str=0001.0A090205.4E83256E.0189,ss=1,re=0.000,fgs=0 Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com> X-BeenThere: xen-devel@lists.xensource.com X-Mailman-Version: 2.1.5 Precedence: list List-Id: Xen developer discussion <xen-devel.lists.xensource.com> List-Unsubscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe> List-Post: <mailto:xen-devel@lists.xensource.com> List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help> List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=subscribe> Sender: xen-devel-bounces@lists.xensource.com Errors-To: xen-devel-bounces@lists.xensource.com > Er. We don't really but I think this if needs to be: > > /* > * Page align regions. > * > * Reduce RAM regions and expand other (reserved) regions. > */ > if (type == E820_RAM || type == E820_UNUSABLE) { > start = PAGE_ALIGN(start); > end &= ~((u64)PAGE_SIZE - 1); > } else { > start &= ~((u64)PAGE_SIZE - 1); > end = PAGE_ALIGN(start); > } > > So reserved regions also become page aligned (which is part of the fix > for the dmidecode bug). I am not sure actually that is required for the e820_* calls. As those are used by 'ioremap' and memory buddy system and they only care about the RAM regions. Everybody else assumes that the "gaps" and "anything-but -RAM-regions" are OK - as long as they don't touch the RAM regions. It certainly is required for the set_phys_to_identity(..) call. I am trying here to be sure we don't mess it up - and I don't know what the right answer is for e820_* calls. Well, I do know what the right answer if for RAM regions - they must be page-aligned. But for reserved/non-RAM/ACPI/ACPI-NVS... ? BIOS-e820: 00000000dfe8ac00 - 00000000dfe8cc00 (ACPI NVS) BIOS-e820: 00000000dfe8cc00 - 00000000dfe8ec00 (ACPI data) .. snip.. reserve RAM buffer: 00000000dfe8ac00 - 00000000dfffffff or say: BIOS-e820: 00000000bff66f00 - 00000000bff76300 (ACPI data) .. [ 1.026860] reserve RAM buffer: 00000000bff66f00 - 00000000bfffffff They all seem to work OK without being page-aligned. I think we can drop the page-alignment on non-RAM regions when we give it to e820_*. We want to diverge as little as possible from what baremetal does. _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel From xen-devel-bounces@lists.xensource.com Wed Sep 28 06:49:04 2011 Return-path: <xen-devel-bounces@lists.xensource.com> Envelope-to: www-data@lists.xensource.com Delivery-date: Wed, 28 Sep 2011 06:49:04 -0700 Received: from localhost ([127.0.0.1] helo=lists.colo.xensource.com) by lists.xensource.com with esmtp (Exim 4.43) id 1R8uVU-0005bw-58; Wed, 28 Sep 2011 06:49:04 -0700 Received: from mail27.messagelabs.com ([193.109.254.147]) by lists.xensource.com with esmtp (Exim 4.43) id 1R8uUm-0005F1-9g for xen-devel@lists.xensource.com; Wed, 28 Sep 2011 06:48:21 -0700 X-Env-Sender: konrad@oracle.com X-Msg-Ref: server-15.tower-27.messagelabs.com!1317217686!48660198!1 X-Originating-IP: [148.87.113.117] X-StarScan-Version: 6.4.1; banners=-,-,- X-VirusChecked: Checked Received: (qmail 28156 invoked from network); 28 Sep 2011 13:48:07 -0000 Received: from rcsinet15.oracle.com (HELO rcsinet15.oracle.com) (148.87.113.117) by server-15.tower-27.messagelabs.com with DHE-RSA-AES256-SHA encrypted SMTP; 28 Sep 2011 13:48:07 -0000 Received: from ucsinet23.oracle.com (ucsinet23.oracle.com [156.151.31.71]) by rcsinet15.oracle.com (Switch-3.4.4/Switch-3.4.4) with ESMTP id p8SDm9LR031149 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Wed, 28 Sep 2011 13:48:10 GMT Received: from acsmt356.oracle.com (acsmt356.oracle.com [141.146.40.156]) by ucsinet23.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id p8SDm8wY025928 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 28 Sep 2011 13:48:08 GMT Received: from abhmt110.oracle.com (abhmt110.oracle.com [141.146.116.62]) by acsmt356.oracle.com (8.12.11.20060308/8.12.11) with ESMTP id p8SDm2Ke031716; Wed, 28 Sep 2011 08:48:03 -0500 Received: from oracle.com (/207.172.105.198) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Wed, 28 Sep 2011 06:48:02 -0700 Received: by oracle.com (Postfix, from userid 1000) id 023111451; Wed, 28 Sep 2011 09:48:00 -0400 (EDT) Date: Wed, 28 Sep 2011 09:48:00 -0400 From: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com> To: Ian Jackson <Ian.Jackson@eu.citrix.com> Subject: Re: [Xen-devel] Xen document day (Oct 12 or 26) Message-ID: <20110928134800.GH10270@phenom.oracle.com> References: <20110922130618.GA13238@phenom.oracle.com> <CAFLBxZaAaXTUtW5+VkxPnr_MR0fbW+d1Mzu4y0x=gEOaX9e0OQ@mail.gmail.com> <20110922174002.GA1205@phenom.oracle.com> <20098.1097.824552.541924@mariner.uk.xensource.com> <CAP2B85-=CbMgUGSwO2utvkeLLqk8A1vjhKrPwe2OD+0daAtqsA@mail.gmail.com> <1317195656.13424.73.camel@dagon.hellion.org.uk> <20099.8327.326129.357335@mariner.uk.xensource.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20099.8327.326129.357335@mariner.uk.xensource.com> User-Agent: Mutt/1.5.21 (2010-09-15) X-Source-IP: ucsinet23.oracle.com [156.151.31.71] X-CT-RefId: str=0001.0A090203.4E83259A.01B9,ss=1,re=0.000,fgs=0 Cc: Daniel Castro <evil.dani@gmail.com>, "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>, Ian Campbell <Ian.Campbell@citrix.com> X-BeenThere: xen-devel@lists.xensource.com X-Mailman-Version: 2.1.5 Precedence: list List-Id: Xen developer discussion <xen-devel.lists.xensource.com> List-Unsubscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe> List-Post: <mailto:xen-devel@lists.xensource.com> List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help> List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=subscribe> Sender: xen-devel-bounces@lists.xensource.com Errors-To: xen-devel-bounces@lists.xensource.com On Wed, Sep 28, 2011 at 02:26:31PM +0100, Ian Jackson wrote: > Ian Campbell writes ("Re: [Xen-devel] Xen document day (Oct 12 or 26)"): > > Since the guest APIs are stable there should be relatively little churn > > so perhaps a wiki page (or even series of pages) would be appropriate > > for this sort of thing? > > I want this to be in-tree. If it's in-tree, we can refuse patches > which do not update the documentation. > > > I think this would be good too and in fact even more important than the > > interface documentation. Everyone needs to be able to build Xen to hack > > on it but only a subset need to know any particular API. > > > > Also although we recommend that users consume Xen via their distro where > > possible such a guide would also help any who would rather build from > > scratch (e.g. because we've asked them to "try the latest version" or to > > bisect a bug etc). > > This would be a good candidate for a wiki page, backed up by revisions > of the in-tree README. Any recommendations on what would be a good format to write these "interface" pages in? _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel From xen-devel-bounces@lists.xensource.com Wed Sep 28 07:00:42 2011 Return-path: <xen-devel-bounces@lists.xensource.com> Envelope-to: www-data@lists.xensource.com Delivery-date: Wed, 28 Sep 2011 07:00:42 -0700 Received: from localhost ([127.0.0.1] helo=lists.colo.xensource.com) by lists.xensource.com with esmtp (Exim 4.43) id 1R8ugj-0006Aj-UQ; Wed, 28 Sep 2011 07:00:42 -0700 Received: from mail182.messagelabs.com ([85.158.139.83]) by lists.xensource.com with esmtp (Exim 4.43) id 1R8ueM-0005x4-PT for xen-devel@lists.xensource.com; Wed, 28 Sep 2011 06:58:15 -0700 X-Env-Sender: Ian.Campbell@eu.citrix.com X-Msg-Ref: server-15.tower-182.messagelabs.com!1317218291!19060377!1 X-Originating-IP: [62.200.22.115] X-StarScan-Version: 6.4.1; banners=-,-,- X-VirusChecked: Checked Received: (qmail 1706 invoked from network); 28 Sep 2011 13:58:11 -0000 Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115) by server-15.tower-182.messagelabs.com with RC4-SHA encrypted SMTP; 28 Sep 2011 13:58:11 -0000 X-IronPort-AV: E=Sophos;i="4.68,455,1312156800"; d="scan'208";a="8106474" Received: from lonpmailmx01.citrite.net ([10.30.203.162]) by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5; 28 Sep 2011 13:58:11 +0000 Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net (10.30.203.162) with Microsoft SMTP Server id 8.3.137.0; Wed, 28 Sep 2011 14:58:11 +0100 Subject: Re: [Xen-devel] Xen document day (Oct 12 or 26) From: Ian Campbell <Ian.Campbell@eu.citrix.com> To: Ian Jackson <Ian.Jackson@eu.citrix.com> Date: Wed, 28 Sep 2011 14:58:10 +0100 In-Reply-To: <20099.8327.326129.357335@mariner.uk.xensource.com> References: <20110922130618.GA13238@phenom.oracle.com> <CAFLBxZaAaXTUtW5+VkxPnr_MR0fbW+d1Mzu4y0x=gEOaX9e0OQ@mail.gmail.com> <20110922174002.GA1205@phenom.oracle.com> <20098.1097.824552.541924@mariner.uk.xensource.com> <CAP2B85-=CbMgUGSwO2utvkeLLqk8A1vjhKrPwe2OD+0daAtqsA@mail.gmail.com> <1317195656.13424.73.camel@dagon.hellion.org.uk> <20099.8327.326129.357335@mariner.uk.xensource.com> Organization: Citrix Systems, Inc. Content-Type: text/plain; charset="UTF-8" X-Mailer: Evolution 3.0.3- Content-Transfer-Encoding: 7bit Message-ID: <1317218291.26672.59.camel@zakaz.uk.xensource.com> MIME-Version: 1.0 Cc: Daniel Castro <evil.dani@gmail.com>, "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>, Konrad Rzeszutek Wilk <konrad.wilk@oracle.com> X-BeenThere: xen-devel@lists.xensource.com X-Mailman-Version: 2.1.5 Precedence: list List-Id: Xen developer discussion <xen-devel.lists.xensource.com> List-Unsubscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe> List-Post: <mailto:xen-devel@lists.xensource.com> List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help> List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=subscribe> Sender: xen-devel-bounces@lists.xensource.com Errors-To: xen-devel-bounces@lists.xensource.com On Wed, 2011-09-28 at 14:26 +0100, Ian Jackson wrote: > Ian Campbell writes ("Re: [Xen-devel] Xen document day (Oct 12 or 26)"): > > Since the guest APIs are stable there should be relatively little churn > > so perhaps a wiki page (or even series of pages) would be appropriate > > for this sort of thing? > > I want this to be in-tree. If it's in-tree, we can refuse patches > which do not update the documentation. I was referring to the example API usage which Daniel was intending to supply, not the API documentation (which I agree should be in-tree, if not in-line in the headers), in case that matters. In some sense mini-os was originally supposed to serve as the in-tree example on how to use the Xen APIs. If it's not serving that purpose I'm not sure what would. > > > I think this would be good too and in fact even more important than the > > interface documentation. Everyone needs to be able to build Xen to hack > > on it but only a subset need to know any particular API. > > > > Also although we recommend that users consume Xen via their distro where > > possible such a guide would also help any who would rather build from > > scratch (e.g. because we've asked them to "try the latest version" or to > > bisect a bug etc). > > This would be a good candidate for a wiki page, backed up by revisions > of the in-tree README. > > Ian. _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel From xen-devel-bounces@lists.xensource.com Wed Sep 28 07:03:40 2011 Return-path: <xen-devel-bounces@lists.xensource.com> Envelope-to: www-data@lists.xensource.com Delivery-date: Wed, 28 Sep 2011 07:03:40 -0700 Received: from localhost ([127.0.0.1] helo=lists.colo.xensource.com) by lists.xensource.com with esmtp (Exim 4.43) id 1R8uja-0006aF-Ue; Wed, 28 Sep 2011 07:03:38 -0700 Received: from mail21.messagelabs.com ([85.158.143.35]) by lists.xensource.com with esmtp (Exim 4.43) id 1R8uhX-0006Ly-QO for xen-devel@lists.xensource.com; Wed, 28 Sep 2011 07:01:32 -0700 X-Env-Sender: Ian.Jackson@eu.citrix.com X-Msg-Ref: server-8.tower-21.messagelabs.com!1317218468!60716922!2 X-Originating-IP: [62.200.22.115] X-StarScan-Version: 6.4.1; banners=-,-,- X-VirusChecked: Checked Received: (qmail 15795 invoked from network); 28 Sep 2011 14:01:12 -0000 Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115) by server-8.tower-21.messagelabs.com with RC4-SHA encrypted SMTP; 28 Sep 2011 14:01:12 -0000 X-IronPort-AV: E=Sophos;i="4.68,455,1312156800"; d="scan'208";a="8106544" Received: from lonpmailmx01.citrite.net ([10.30.203.162]) by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5; 28 Sep 2011 14:01:02 +0000 Received: from norwich.cam.xci-test.com (10.80.248.129) by smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id 8.3.137.0; Wed, 28 Sep 2011 15:01:02 +0100 Received: from mariner.cam.xci-test.com ([10.80.2.22] helo=mariner.uk.xensource.com ident=Debian-exim) by norwich.cam.xci-test.com with esmtp (Exim 4.72) (envelope-from <Ian.Jackson@eu.citrix.com>) id 1R8uh4-0002KH-2K for xen-devel@lists.xensource.com; Wed, 28 Sep 2011 14:01:02 +0000 Received: from iwj by mariner.uk.xensource.com with local (Exim 4.69) (envelope-from <Ian.Jackson@eu.citrix.com>) id 1R8uh4-0007Kl-1S for xen-devel@lists.xensource.com; Wed, 28 Sep 2011 15:01:02 +0100 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Message-ID: <20099.10398.36869.624593@mariner.uk.xensource.com> Date: Wed, 28 Sep 2011 15:01:02 +0100 To: xen-devel@lists.xensource.com X-Mailer: VM 8.0.9 under Emacs 21.4.1 (i486-pc-linux-gnu) From: Ian Jackson <Ian.Jackson@eu.citrix.com> Subject: [Xen-devel] Missed tools patches ? X-BeenThere: xen-devel@lists.xensource.com X-Mailman-Version: 2.1.5 Precedence: list List-Id: Xen developer discussion <xen-devel.lists.xensource.com> List-Unsubscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe> List-Post: <mailto:xen-devel@lists.xensource.com> List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help> List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=subscribe> Sender: xen-devel-bounces@lists.xensource.com Errors-To: xen-devel-bounces@lists.xensource.com Currently my queue contains a number of largish patch series which I'm hoping to bundle into the tree soon (now that we have a working tree and a working tester, neither of which were true last week): - libxenvchan - NetBSD support for libxl - QMP - xenpaging But it turns out that I have missed (accidentally dropped) some patches from at least one committer, and I'm worried that whatever happened to those might have happened to other patches. So if you have sent a patch to the xen tools and I haven't replied after a few days, please do let me know. Ian. _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel From xen-devel-bounces@lists.xensource.com Wed Sep 28 07:07:43 2011 Return-path: <xen-devel-bounces@lists.xensource.com> Envelope-to: www-data@lists.xensource.com Delivery-date: Wed, 28 Sep 2011 07:07:43 -0700 Received: from localhost ([127.0.0.1] helo=lists.colo.xensource.com) by lists.xensource.com with esmtp (Exim 4.43) id 1R8unW-0006zn-KH; Wed, 28 Sep 2011 07:07:42 -0700 Received: from mail21.messagelabs.com ([85.158.143.35]) by lists.xensource.com with esmtp (Exim 4.43) id 1R8uhU-0006Li-Mr for xen-devel@lists.xensource.com; Wed, 28 Sep 2011 07:01:32 -0700 X-Env-Sender: Ian.Campbell@eu.citrix.com X-Msg-Ref: server-8.tower-21.messagelabs.com!1317218468!60716922!1 X-Originating-IP: [62.200.22.115] X-StarScan-Version: 6.4.1; banners=-,-,- X-VirusChecked: Checked Received: (qmail 15656 invoked from network); 28 Sep 2011 14:01:09 -0000 Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115) by server-8.tower-21.messagelabs.com with RC4-SHA encrypted SMTP; 28 Sep 2011 14:01:09 -0000 X-IronPort-AV: E=Sophos;i="4.68,455,1312156800"; d="scan'208";a="8106542" Received: from lonpmailmx01.citrite.net ([10.30.203.162]) by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5; 28 Sep 2011 14:01:00 +0000 Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net (10.30.203.162) with Microsoft SMTP Server id 8.3.137.0; Wed, 28 Sep 2011 15:00:59 +0100 Subject: Re: [Xen-devel] Xen document day (Oct 12 or 26) From: Ian Campbell <Ian.Campbell@eu.citrix.com> To: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com> Date: Wed, 28 Sep 2011 15:00:59 +0100 In-Reply-To: <20110928134800.GH10270@phenom.oracle.com> References: <20110922130618.GA13238@phenom.oracle.com> <CAFLBxZaAaXTUtW5+VkxPnr_MR0fbW+d1Mzu4y0x=gEOaX9e0OQ@mail.gmail.com> <20110922174002.GA1205@phenom.oracle.com> <20098.1097.824552.541924@mariner.uk.xensource.com> <CAP2B85-=CbMgUGSwO2utvkeLLqk8A1vjhKrPwe2OD+0daAtqsA@mail.gmail.com> <1317195656.13424.73.camel@dagon.hellion.org.uk> <20099.8327.326129.357335@mariner.uk.xensource.com> <20110928134800.GH10270@phenom.oracle.com> Organization: Citrix Systems, Inc. Content-Type: text/plain; charset="UTF-8" X-Mailer: Evolution 3.0.3- Content-Transfer-Encoding: 7bit Message-ID: <1317218459.26672.62.camel@zakaz.uk.xensource.com> MIME-Version: 1.0 Cc: Daniel Castro <evil.dani@gmail.com>, "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>, Ian Jackson <Ian.Jackson@eu.citrix.com> X-BeenThere: xen-devel@lists.xensource.com X-Mailman-Version: 2.1.5 Precedence: list List-Id: Xen developer discussion <xen-devel.lists.xensource.com> List-Unsubscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe> List-Post: <mailto:xen-devel@lists.xensource.com> List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help> List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=subscribe> Sender: xen-devel-bounces@lists.xensource.com Errors-To: xen-devel-bounces@lists.xensource.com On Wed, 2011-09-28 at 14:48 +0100, Konrad Rzeszutek Wilk wrote: > On Wed, Sep 28, 2011 at 02:26:31PM +0100, Ian Jackson wrote: > > Ian Campbell writes ("Re: [Xen-devel] Xen document day (Oct 12 or 26)"): > > > Since the guest APIs are stable there should be relatively little churn > > > so perhaps a wiki page (or even series of pages) would be appropriate > > > for this sort of thing? > > > > I want this to be in-tree. If it's in-tree, we can refuse patches > > which do not update the documentation. > > > > > I think this would be good too and in fact even more important than the > > > interface documentation. Everyone needs to be able to build Xen to hack > > > on it but only a subset need to know any particular API. > > > > > > Also although we recommend that users consume Xen via their distro where > > > possible such a guide would also help any who would rather build from > > > scratch (e.g. because we've asked them to "try the latest version" or to > > > bisect a bug etc). > > > > This would be a good candidate for a wiki page, backed up by revisions > > of the in-tree README. > > > Any recommendations on what would be a good format to write these "interface" > pages in? For in-line (i.e. in xen/include/public/*.h) docs of APIs I played a little bit with integrating kernel-doc into the Xen build system but it is tied a little too closely to the kernel build infrastructure. Doxygen seems like a plausible alternative with life outside the kernel etc. We actually appear to already have some doxygen stuff for the pytyhon stuff (judging from the Makefile, I've not actually noticed the structured code comments anywhere) For non-inline docs I think we decided that markdown would be a good answer. Ian. _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel From xen-devel-bounces@lists.xensource.com Wed Sep 28 07:09:12 2011 Return-path: <xen-devel-bounces@lists.xensource.com> Envelope-to: www-data@lists.xensource.com Delivery-date: Wed, 28 Sep 2011 07:09:12 -0700 Received: from localhost ([127.0.0.1] helo=lists.colo.xensource.com) by lists.xensource.com with esmtp (Exim 4.43) id 1R8uox-0007NH-RG; Wed, 28 Sep 2011 07:09:11 -0700 Received: from mail182.messagelabs.com ([85.158.139.83]) by lists.xensource.com with esmtp (Exim 4.43) id 1R8uhv-0006MT-3g for xen-devel@lists.xensource.com; Wed, 28 Sep 2011 07:01:56 -0700 X-Env-Sender: Stephan.Diestelhorst@amd.com X-Msg-Ref: server-14.tower-182.messagelabs.com!1317218510!19907782!1 X-Originating-IP: [65.55.88.11] X-StarScan-Version: 6.4.1; banners=-,-,- X-VirusChecked: Checked Received: (qmail 22392 invoked from network); 28 Sep 2011 14:01:51 -0000 Received: from tx2ehsobe001.messaging.microsoft.com (HELO TX2EHSOBE001.bigfish.com) (65.55.88.11) by server-14.tower-182.messagelabs.com with AES128-SHA encrypted SMTP; 28 Sep 2011 14:01:51 -0000 Received: from mail128-tx2-R.bigfish.com (10.9.14.239) by TX2EHSOBE001.bigfish.com (10.9.40.21) with Microsoft SMTP Server id 14.1.225.22; Wed, 28 Sep 2011 14:01:50 +0000 Received: from mail128-tx2 (localhost.localdomain [127.0.0.1]) by mail128-tx2-R.bigfish.com (Postfix) with ESMTP id D67C67D8298; Wed, 28 Sep 2011 14:01:49 +0000 (UTC) X-SpamScore: -19 X-BigFish: VPS-19(zzbb2dK9371Kdf9M1432N98dKzz1202hzz8275bhz32i668h839h93fh) X-Forefront-Antispam-Report: CIP:163.181.249.108; KIP:(null); UIP:(null); IPVD:NLI; H:ausb3twp01.amd.com; RD:none; EFVD:NLI X-FB-SS: 0,13, Received: from mail128-tx2 (localhost.localdomain [127.0.0.1]) by mail128-tx2 (MessageSwitch) id 1317218418678779_18361; Wed, 28 Sep 2011 14:00:18 +0000 (UTC) Received: from TX2EHSMHS004.bigfish.com (unknown [10.9.14.240]) by mail128-tx2.bigfish.com (Postfix) with ESMTP id 41D0F9E030A; Wed, 28 Sep 2011 13:59:50 +0000 (UTC) Received: from ausb3twp01.amd.com (163.181.249.108) by TX2EHSMHS004.bigfish.com (10.9.99.104) with Microsoft SMTP Server id 14.1.225.22; Wed, 28 Sep 2011 13:59:00 +0000 X-WSS-ID: 0LS8K66-01-1DX-02 X-M-MSG: Received: from sausexedgep01.amd.com (sausexedgep01-ext.amd.com [163.181.249.72]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by ausb3twp01.amd.com (Axway MailGate 3.8.1) with ESMTP id 2AAC71028390; Wed, 28 Sep 2011 08:58:53 -0500 (CDT) Received: from SAUSEXDAG03.amd.com (163.181.55.3) by sausexedgep01.amd.com (163.181.36.54) with Microsoft SMTP Server (TLS) id 8.3.106.1; Wed, 28 Sep 2011 08:59:09 -0500 Received: from storexhtp02.amd.com (172.24.4.4) by sausexdag03.amd.com (163.181.55.3) with Microsoft SMTP Server (TLS) id 14.1.289.1; Wed, 28 Sep 2011 08:58:57 -0500 Received: from gwo.osrc.amd.com (165.204.16.204) by storexhtp02.amd.com (172.24.4.4) with Microsoft SMTP Server id 8.3.83.0; Wed, 28 Sep 2011 09:58:56 -0400 Received: from chlor.localnet (chlor.osrc.amd.com [165.204.15.145]) by gwo.osrc.amd.com (Postfix) with ESMTP id 7034949C1FF; Wed, 28 Sep 2011 14:58:55 +0100 (BST) From: Stephan Diestelhorst <stephan.diestelhorst@amd.com> To: Jeremy Fitzhardinge <jeremy@goop.org> Subject: Re: [Xen-devel] [PATCH 00/10] [PATCH RFC V2] Paravirtualized ticketlocks Date: Wed, 28 Sep 2011 15:58:55 +0200 Message-ID: <33782147.oLTY4kzH1r@chlor> Organization: AMD OSRC User-Agent: KMail/4.7.0 (Linux/2.6.38-11-generic; KDE/4.7.0; x86_64; ; ) In-Reply-To: <4E81FD52.50106@goop.org> References: <cover.1315878463.git.jeremy.fitzhardinge@citrix.com> <3300108.XQUp9Wrktc@chlor> <4E81FD52.50106@goop.org> MIME-Version: 1.0 Content-Transfer-Encoding: 7Bit Content-Type: text/plain; charset="utf-8" X-OriginatorOrg: amd.com Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>, Piggin <npiggin@kernel.dk>, KVM <kvm@vger.kernel.org>, Linux, Peter Zijlstra <peterz@infradead.org>, Marcelo Tosatti <mtosatti@redhat.com>, the arch/x86 maintainers <x86@kernel.org>, Kernel Mailing List <linux-kernel@vger.kernel.org>, Nick, Andi Kleen <andi@firstfloor.org>, Avi Kivity <avi@redhat.com>, Jeremy Fitzhardinge <jeremy.fitzhardinge@citrix.com>, "H. Peter Anvin" <hpa@zytor.com>, Ingo Molnar <mingo@elte.hu>, Linus Torvalds <torvalds@linux-foundation.org> X-BeenThere: xen-devel@lists.xensource.com X-Mailman-Version: 2.1.5 Precedence: list List-Id: Xen developer discussion <xen-devel.lists.xensource.com> List-Unsubscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe> List-Post: <mailto:xen-devel@lists.xensource.com> List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help> List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=subscribe> Sender: xen-devel-bounces@lists.xensource.com Errors-To: xen-devel-bounces@lists.xensource.com On Tuesday 27 September 2011, 12:44:02 Jeremy Fitzhardinge wrote: > On 09/27/2011 02:34 AM, Stephan Diestelhorst wrote: > > On Wednesday 14 September 2011, 17:31:32 Jeremy Fitzhardinge wrote: > >> This series replaces the existing paravirtualized spinlock mechanism > >> with a paravirtualized ticketlock mechanism. > > [...] > >> The unlock code is very straightforward: > >> prev = *lock; > >> __ticket_unlock_release(lock); > >> if (unlikely(__ticket_in_slowpath(lock))) > >> __ticket_unlock_slowpath(lock, prev); > >> > >> which generates: > >> push %rbp > >> mov %rsp,%rbp > >> > >> movzwl (%rdi),%esi > >> addb $0x2,(%rdi) > >> movzwl (%rdi),%eax > >> testb $0x1,%ah > >> jne 1f > >> > >> pop %rbp > >> retq > >> > >> ### SLOWPATH START > >> 1: movzwl (%rdi),%edx > >> movzbl %dh,%ecx > >> mov %edx,%eax > >> and $-2,%ecx # clear TICKET_SLOWPATH_FLAG > >> mov %cl,%dh > >> cmp %dl,%cl # test to see if lock is uncontended > >> je 3f > >> > >> 2: movzbl %dl,%esi > >> callq *__ticket_unlock_kick # kick anyone waiting > >> pop %rbp > >> retq > >> > >> 3: lock cmpxchg %dx,(%rdi) # use cmpxchg to safely write back flag > >> jmp 2b > >> ### SLOWPATH END > > [...] > >> Thoughts? Comments? Suggestions? > > You have a nasty data race in your code that can cause a losing > > acquirer to sleep forever, because its setting the TICKET_SLOWPATH flag > > can race with the lock holder releasing the lock. > > > > I used the code for the slow path from the GIT repo. > > > > Let me try to point out an interleaving: > > > > Lock is held by one thread, contains 0x0200. > > > > _Lock holder_ _Acquirer_ > > mov $0x200,%eax > > lock xadd %ax,(%rdi) > > // ax:= 0x0200, lock:= 0x0400 > > ... > > // this guy spins for a while, reading > > // the lock > > ... > > //trying to free the lock > > movzwl (%rdi),%esi (esi:=0x0400) > > addb $0x2,(%rdi) (LOCAL copy of lock is now: 0x0402) > > movzwl (%rdi),%eax (local forwarding from previous store: eax := 0x0402) > > testb $0x1,%ah (no wakeup of anybody) > > jne 1f > > > > callq *__ticket_lock_spinning > > ... > > // __ticket_enter_slowpath(lock) > > lock or (%rdi), $0x100 > > // (global view of lock := 0x0500) > > ... > > ACCESS_ONCE(lock->tickets.head) == want > > // (reads 0x00) > > ... > > xen_poll_irq(irq); // goes to sleep > > ... > > [addb $0x2,(%rdi)] > > // (becomes globally visible only now! global view of lock := 0x0502) > > ... > > > > Your code is reusing the (just about) safe version of unlocking a > > spinlock without understanding the effect that close has on later > > memory ordering. It may work on CPUs that cannot do narrow -> wide > > store to load forwarding and have to make the addb store visible > > globally. This is an implementation artifact of specific uarches, and > > you mustn't rely on it, since our specified memory model allows looser > > behaviour. > > Ah, thanks for this observation. I've seen this bug before when I > didn't pay attention to the unlock W vs flag R ordering at all, and I > was hoping the aliasing would be sufficient - and certainly this seems > to have been OK on my Intel systems. But you're saying that it will > fail on current AMD systems? I have tested this and have not seen it fail on publicly released AMD systems. But as I have tried to point out, this does not mean it is safe to do in software, because future microarchtectures may have more capable forwarding engines. > Have you tested this, or is this just from code analysis (which I > agree with after reviewing the ordering rules in the Intel manual). We have found a similar issue in Novell's PV ticket lock implementation during internal product testing. > > Since you want to get that addb out to global memory before the second > > read, either use a LOCK prefix for it, add an MFENCE between addb and > > movzwl, or use a LOCKed instruction that will have a fencing effect > > (e.g., to top-of-stack)between addb and movzwl. > > Hm. I don't really want to do any of those because it will probably > have a significant effect on the unlock performance; I was really trying > to avoid adding any more locked instructions. A previous version of the > code had an mfence in here, but I hit on the idea of using aliasing to > get the ordering I want - but overlooked the possible effect of store > forwarding. Well, I'd be curious about the actual performance impact. If the store needs to commit to memory due to aliasing anyways, this would slow down execution, too. After all it is better to write working than fast code, no? ;-) > I guess it comes down to throwing myself on the efficiency of some kind > of fence instruction. I guess an lfence would be sufficient; is that > any more efficient than a full mfence? An lfence should not be sufficient, since that essentially is a NOP on WB memory. You really want a full fence here, since the store needs to be published before reading the lock with the next load. > At least I can make it so that its only present when pv ticket locks > are actually in use, so it won't affect the native case. That would be a good thing, indeed. Of course, always relative to an actual performance comparison. > Could you give me a pointer to AMD's description of the ordering rules? They should be in "AMD64 Architecture Programmer's Manual Volume 2: System Programming", Section 7.2 Multiprocessor Memory Access Ordering. http://developer.amd.com/documentation/guides/pages/default.aspx#manuals Let me know if you have some clarifying suggestions. We are currently revising these documents... Cheers, Stephan -- Stephan Diestelhorst, AMD Operating System Research Center stephan.diestelhorst@amd.com Tel. +49 (0)351 448 356 719 Advanced Micro Devices GmbH Einsteinring 24 85609 Aschheim Germany Geschaeftsfuehrer: Alberto Bozzo Sitz: Dornach, Gemeinde Aschheim, Landkreis Muenchen Registergericht Muenchen, HRB Nr. 43632, WEEE-Reg-Nr: DE 12919551 _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel From xen-devel-bounces@lists.xensource.com Wed Sep 28 07:29:42 2011 Return-path: <xen-devel-bounces@lists.xensource.com> Envelope-to: www-data@lists.xensource.com Delivery-date: Wed, 28 Sep 2011 07:29:42 -0700 Received: from localhost ([127.0.0.1] helo=lists.colo.xensource.com) by lists.xensource.com with esmtp (Exim 4.43) id 1R8v8o-0000Mh-I6; Wed, 28 Sep 2011 07:29:42 -0700 Received: from mail174.messagelabs.com ([85.158.138.51]) by lists.xensource.com with smtp (Exim 4.43) id 1R8v7v-0000A2-C2 for xen-devel@lists.xensource.com; Wed, 28 Sep 2011 07:28:50 -0700 X-Env-Sender: caker@theshore.net X-Msg-Ref: server-15.tower-174.messagelabs.com!1317220123!26760004!1 X-Originating-IP: [67.18.92.50] X-StarScan-Version: 6.4.1; banners=-,-,- X-VirusChecked: Checked Received: (qmail 7523 invoked from network); 28 Sep 2011 14:28:44 -0000 Received: from ns.theshore.net (HELO www.theshore.net) (67.18.92.50) by server-15.tower-174.messagelabs.com with SMTP; 28 Sep 2011 14:28:44 -0000 Received: from beefcake.linlan (173-161-199-49-Philadelphia.hfc.comcastbusiness.net [173.161.199.49]) by www.theshore.net (8.13.6/8.9.1) with ESMTP id p8SESgm9023025 for <xen-devel@lists.xensource.com>; Wed, 28 Sep 2011 10:28:42 -0400 Message-ID: <4E832F1A.3030209@theshore.net> Date: Wed, 28 Sep 2011 10:28:42 -0400 From: "Christopher S. Aker" <caker@theshore.net> User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.6; en-US; rv:1.9.2.22) Gecko/20110902 Lightning/1.0b2 Thunderbird/3.1.14 MIME-Version: 1.0 To: xen devel <xen-devel@lists.xensource.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: [Xen-devel] vmalloc_sync_all() patch problems? X-BeenThere: xen-devel@lists.xensource.com X-Mailman-Version: 2.1.5 Precedence: list List-Id: Xen developer discussion <xen-devel.lists.xensource.com> List-Unsubscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe> List-Post: <mailto:xen-devel@lists.xensource.com> List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help> List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=subscribe> Sender: xen-devel-bounces@lists.xensource.com Errors-To: xen-devel-bounces@lists.xensource.com 4.1.2-rc3-pre @ 23159 3.0.4 + vmalloc_sync_all() patch While running my Xen test suite: BUG: unable to handle kernel paging request at bffffd68 IP: [<c102bb51>] vmalloc_sync_all+0x141/0x1e0 *pdpt = 0000000027d71027 *pde = 0000000000000000 Oops: 0000 [#1] SMP Modules linked in: ebt_arp ip6t_rt ebt_mark ebt_limit ip6table_mangle xt_mark ebtable_nat ebtable_filter Pid: 39, comm: xenwatch Not tainted 3.0.4-1 #1 Supermicro X8DTU/X8DTU EIP: 0061:[<c102bb51>] EFLAGS: 00010283 CPU: 3 EIP is at vmalloc_sync_all+0x141/0x1e0 EAX: bffffd68 EBX: efe5a720 ECX: 00000008 EDX: 00000001 ESI: ea082a34 EDI: c1a73d68 EBP: eb1d9e80 ESP: eb1d9e4c DS: 007b ES: 007b FS: 00d8 GS: 0000 SS: 0069 Process xenwatch (pid: 39, ti=eb1d8000 task=eb11b0c0 task.ti=eb1d8000) Stack: 2b048000 00000000 2b048000 00000000 fffff001 00000008 c0000d68 7bf85067 f5a00000 00000018 ea254480 eb1d9f14 eb1d9f54 eb1d9e94 c10e5212 c10e35a0 00000000 e7d3d600 eb1d9ee4 c1446275 eb1d9ea8 c13932c0 e7d3d600 00000011 Call Trace: [<c10e5212>] alloc_vm_area+0x42/0x60 [<c10e35a0>] ? is_vmalloc_or_module_addr+0x50/0x50 [<c1446275>] xen_blkif_map+0x35/0x1e0 [<c13932c0>] ? xen_evtchn_do_upcall+0x20/0x30 [<c1446a61>] frontend_changed+0x261/0x2d0 [<c139852d>] xenbus_otherend_changed+0x7d/0x90 [<c1398732>] frontend_changed+0x12/0x20 [<c1396aa5>] xenwatch_thread+0x85/0x130 [<c10625d0>] ? wake_up_bit+0x60/0x60 [<c1396a20>] ? split+0xd0/0xd0 [<c10621e4>] kthread+0x74/0x80 [<c1062170>] ? kthread_worker_fn+0x160/0x160 [<c16ca2b6>] kernel_thread_helper+0x6/0x10 Code: c1 89 c7 81 e7 00 f0 ff ff 03 7d e4 8b 17 89 55 e8 8b 4f 04 83 e2 01 89 4d e0 0f 84 68 ff ff ff 8b 45 dc 25 00 f0 ff ff 03 45 e4 <8b> 08 8b 50 04 f6 c1 01 89 55 dc 74 7a 8b 55 dc 89 c8 ff 15 14 EIP: [<c102bb51>] vmalloc_sync_all+0x141/0x1e0 SS:ESP 0069:eb1d9e4c CR2: 00000000bffffd68 ---[ end trace 486c192808e46938 ]--- INFO: rcu_sched_state detected stall on CPU 7 (t=60000 jiffies) INFO: rcu_sched_state detected stall on CPU 7 (t=240030 jiffies) ... and so on -Chris _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel From xen-devel-bounces@lists.xensource.com Wed Sep 28 07:45:00 2011 Return-path: <xen-devel-bounces@lists.xensource.com> Envelope-to: www-data@lists.xensource.com Delivery-date: Wed, 28 Sep 2011 07:45:00 -0700 Received: from localhost ([127.0.0.1] helo=lists.colo.xensource.com) by lists.xensource.com with esmtp (Exim 4.43) id 1R8vNc-0001Kp-3r; Wed, 28 Sep 2011 07:45:00 -0700 Received: from mail27.messagelabs.com ([193.109.254.147]) by lists.xensource.com with esmtp (Exim 4.43) id 1R8vMk-00018t-VD for xen-devel@lists.xensource.com; Wed, 28 Sep 2011 07:44:07 -0700 X-Env-Sender: david.vrabel@citrix.com X-Msg-Ref: server-10.tower-27.messagelabs.com!1317221020!37591430!1 X-Originating-IP: [66.165.176.63] X-StarScan-Version: 6.4.1; banners=-,-,- X-VirusChecked: Checked Received: (qmail 11604 invoked from network); 28 Sep 2011 14:43:42 -0000 Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63) by server-10.tower-27.messagelabs.com with RC4-SHA encrypted SMTP; 28 Sep 2011 14:43:42 -0000 X-IronPort-AV: E=Sophos;i="4.68,456,1312171200"; d="scan'208";a="164982937" Received: from ftlpmailmx01.citrite.net ([10.13.107.65]) by FTLPIPO02.CITRIX.COM with ESMTP/TLS/RC4-MD5; 28 Sep 2011 10:44:02 -0400 Received: from [10.80.2.76] (10.80.2.76) by FTLPMAILMX01.citrite.net (10.13.107.65) with Microsoft SMTP Server id 8.3.137.0; Wed, 28 Sep 2011 10:44:01 -0400 Message-ID: <4E83330A.3030509@citrix.com> Date: Wed, 28 Sep 2011 15:45:30 +0100 From: David Vrabel <david.vrabel@citrix.com> User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.1.16) Gecko/20110818 Icedove/3.0.11 MIME-Version: 1.0 To: "Christopher S. Aker" <caker@theshore.net> Subject: Re: [Xen-devel] vmalloc_sync_all() patch problems? References: <4E832F1A.3030209@theshore.net> In-Reply-To: <4E832F1A.3030209@theshore.net> Content-Type: text/plain; charset="ISO-8859-1" Content-Transfer-Encoding: 7bit Cc: xen devel <xen-devel@lists.xensource.com> X-BeenThere: xen-devel@lists.xensource.com X-Mailman-Version: 2.1.5 Precedence: list List-Id: Xen developer discussion <xen-devel.lists.xensource.com> List-Unsubscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe> List-Post: <mailto:xen-devel@lists.xensource.com> List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help> List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=subscribe> Sender: xen-devel-bounces@lists.xensource.com Errors-To: xen-devel-bounces@lists.xensource.com On 28/09/11 15:28, Christopher S. Aker wrote: > 4.1.2-rc3-pre @ 23159 > 3.0.4 + vmalloc_sync_all() patch This is surprising as that vmalloc_sync_all() patch is a revert of a recent change only present in 3.0 and others have reported the patch works for them. You're going to have to provide more information on your system and tests I think. David > While running my Xen test suite: > > BUG: unable to handle kernel paging request at bffffd68 > IP: [<c102bb51>] vmalloc_sync_all+0x141/0x1e0 > *pdpt = 0000000027d71027 *pde = 0000000000000000 > Oops: 0000 [#1] SMP > Modules linked in: ebt_arp ip6t_rt ebt_mark ebt_limit ip6table_mangle > xt_mark ebtable_nat ebtable_filter > Pid: 39, comm: xenwatch Not tainted 3.0.4-1 #1 Supermicro X8DTU/X8DTU > EIP: 0061:[<c102bb51>] EFLAGS: 00010283 CPU: 3 > EIP is at vmalloc_sync_all+0x141/0x1e0 > EAX: bffffd68 EBX: efe5a720 ECX: 00000008 EDX: 00000001 > ESI: ea082a34 EDI: c1a73d68 EBP: eb1d9e80 ESP: eb1d9e4c > DS: 007b ES: 007b FS: 00d8 GS: 0000 SS: 0069 > Process xenwatch (pid: 39, ti=eb1d8000 task=eb11b0c0 task.ti=eb1d8000) > Stack: > 2b048000 00000000 2b048000 00000000 fffff001 00000008 c0000d68 7bf85067 > f5a00000 00000018 ea254480 eb1d9f14 eb1d9f54 eb1d9e94 c10e5212 c10e35a0 > 00000000 e7d3d600 eb1d9ee4 c1446275 eb1d9ea8 c13932c0 e7d3d600 00000011 > Call Trace: > [<c10e5212>] alloc_vm_area+0x42/0x60 > [<c10e35a0>] ? is_vmalloc_or_module_addr+0x50/0x50 > [<c1446275>] xen_blkif_map+0x35/0x1e0 > [<c13932c0>] ? xen_evtchn_do_upcall+0x20/0x30 > [<c1446a61>] frontend_changed+0x261/0x2d0 > [<c139852d>] xenbus_otherend_changed+0x7d/0x90 > [<c1398732>] frontend_changed+0x12/0x20 > [<c1396aa5>] xenwatch_thread+0x85/0x130 > [<c10625d0>] ? wake_up_bit+0x60/0x60 > [<c1396a20>] ? split+0xd0/0xd0 > [<c10621e4>] kthread+0x74/0x80 > [<c1062170>] ? kthread_worker_fn+0x160/0x160 > [<c16ca2b6>] kernel_thread_helper+0x6/0x10 > Code: c1 89 c7 81 e7 00 f0 ff ff 03 7d e4 8b 17 89 55 e8 8b 4f 04 83 e2 > 01 89 4d e0 0f 84 68 ff ff ff 8b 45 dc 25 00 f0 ff ff 03 45 e4 <8b> 08 > 8b 50 04 f6 c1 01 89 55 dc 74 7a 8b 55 dc 89 c8 ff 15 14 > EIP: [<c102bb51>] vmalloc_sync_all+0x141/0x1e0 SS:ESP 0069:eb1d9e4c > CR2: 00000000bffffd68 > ---[ end trace 486c192808e46938 ]--- > INFO: rcu_sched_state detected stall on CPU 7 (t=60000 jiffies) > INFO: rcu_sched_state detected stall on CPU 7 (t=240030 jiffies) > ... and so on > > -Chris > > _______________________________________________ > Xen-devel mailing list > Xen-devel@lists.xensource.com > http://lists.xensource.com/xen-devel _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel From xen-devel-bounces@lists.xensource.com Wed Sep 28 08:19:04 2011 Return-path: <xen-devel-bounces@lists.xensource.com> Envelope-to: www-data@lists.xensource.com Delivery-date: Wed, 28 Sep 2011 08:19:04 -0700 Received: from localhost ([127.0.0.1] helo=lists.colo.xensource.com) by lists.xensource.com with esmtp (Exim 4.43) id 1R8vuZ-0002GK-PZ; Wed, 28 Sep 2011 08:19:03 -0700 Received: from mail182.messagelabs.com ([85.158.139.83]) by lists.xensource.com with esmtp (Exim 4.43) id 1R8vtH-000237-OO for xen-devel@lists.xensource.com; Wed, 28 Sep 2011 08:17:47 -0700 X-Env-Sender: Ian.Campbell@eu.citrix.com X-Msg-Ref: server-13.tower-182.messagelabs.com!1317223060!19949218!1 X-Originating-IP: [62.200.22.115] X-StarScan-Version: 6.4.1; banners=-,-,- X-VirusChecked: Checked Received: (qmail 9606 invoked from network); 28 Sep 2011 15:17:40 -0000 Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115) by server-13.tower-182.messagelabs.com with RC4-SHA encrypted SMTP; 28 Sep 2011 15:17:40 -0000 X-IronPort-AV: E=Sophos;i="4.68,456,1312156800"; d="scan'208";a="8108768" Received: from lonpmailmx01.citrite.net ([10.30.203.162]) by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5; 28 Sep 2011 15:17:40 +0000 Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net (10.30.203.162) with Microsoft SMTP Server id 8.3.137.0; Wed, 28 Sep 2011 16:17:40 +0100 Subject: Re: [Xen-devel] xenbus/xenstore protocol description From: Ian Campbell <Ian.Campbell@citrix.com> To: Vasiliy Tolstov <v.tolstov@selfip.ru> Date: Wed, 28 Sep 2011 16:17:40 +0100 In-Reply-To: <CACaajQv4jgsQZhR62g8-k69OTuzNGHB2N4ZZfcs0TZJGbqa3JQ@mail.gmail.com> References: <CACaajQv4jgsQZhR62g8-k69OTuzNGHB2N4ZZfcs0TZJGbqa3JQ@mail.gmail.com> Organization: Citrix Systems, Inc. Content-Type: text/plain; charset="UTF-8" X-Mailer: Evolution 3.0.3- Content-Transfer-Encoding: 7bit Message-ID: <1317223060.26672.72.camel@zakaz.uk.xensource.com> MIME-Version: 1.0 Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com> X-BeenThere: xen-devel@lists.xensource.com X-Mailman-Version: 2.1.5 Precedence: list List-Id: Xen developer discussion <xen-devel.lists.xensource.com> List-Unsubscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe> List-Post: <mailto:xen-devel@lists.xensource.com> List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help> List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=subscribe> Sender: xen-devel-bounces@lists.xensource.com Errors-To: xen-devel-bounces@lists.xensource.com On Wed, 2011-09-28 at 12:42 +0100, Vasiliy Tolstov wrote: > Hello. Can somebody send me link to xensotre/xenbus protocol > description, docs/misc/xenstore.txt > i can't use xenstore libs Why not? The xenstore libs are available in most distros, even if you are running in domU. In addition libxenstore supports for being used statically for cases where you are deploying into generic/unknown environments (such as for use in a guest agent). As do the xenstore-* tools Ian. > and want to read/write some values to xenstore via os read/write > to /proc/xen/xenbus... _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel From xen-devel-bounces@lists.xensource.com Wed Sep 28 08:26:47 2011 Return-path: <xen-devel-bounces@lists.xensource.com> Envelope-to: www-data@lists.xensource.com Delivery-date: Wed, 28 Sep 2011 08:26:47 -0700 Received: from localhost ([127.0.0.1] helo=lists.colo.xensource.com) by lists.xensource.com with esmtp (Exim 4.43) id 1R8w22-0002iv-J7; Wed, 28 Sep 2011 08:26:47 -0700 Received: from mail216.messagelabs.com ([85.158.143.99]) by lists.xensource.com with esmtp (Exim 4.43) id 1R8w1N-0002X8-CB for xen-devel@lists.xensource.com; Wed, 28 Sep 2011 08:26:08 -0700 X-Env-Sender: vase@selfip.ru X-Msg-Ref: server-15.tower-216.messagelabs.com!1317223561!19378408!1 X-Originating-IP: [74.125.82.171] X-StarScan-Version: 6.4.1; banners=-,-,- X-VirusChecked: Checked Received: (qmail 31738 invoked from network); 28 Sep 2011 15:26:01 -0000 Received: from mail-wy0-f171.google.com (HELO mail-wy0-f171.google.com) (74.125.82.171) by server-15.tower-216.messagelabs.com with RC4-SHA encrypted SMTP; 28 Sep 2011 15:26:01 -0000 Received: by wyh13 with SMTP id 13so164474wyh.30 for <xen-devel@lists.xensource.com>; Wed, 28 Sep 2011 08:26:01 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=selfip.ru; s=google; h=mime-version:sender:x-originating-ip:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type; bh=9dUJEb9t6z6hZHy4LFjqtP8/yZZzQGvTuhE4+eGpSyM=; b=N5ygYJbyOdQpi0MZJ/yViwoqrpc4i0gookC4EIYbCwkLZrX10zB+AfSO+ZQkf1fGzD 1xoCGuCv6kb3OHd083zOXki5NdHEFTP8TgO8s0j34uiMqZqHpUuRlldhG9IuCZfWLvI7 uHjkwy1OMIDCWhaQDblhvYSSoGzVRRJnWxYHo= MIME-Version: 1.0 Received: by 10.216.229.144 with SMTP id h16mr1216881weq.31.1317223561449; Wed, 28 Sep 2011 08:26:01 -0700 (PDT) Received: by 10.216.4.69 with HTTP; Wed, 28 Sep 2011 08:26:01 -0700 (PDT) X-Originating-IP: [85.143.161.18] In-Reply-To: <1317223060.26672.72.camel@zakaz.uk.xensource.com> References: <CACaajQv4jgsQZhR62g8-k69OTuzNGHB2N4ZZfcs0TZJGbqa3JQ@mail.gmail.com> <1317223060.26672.72.camel@zakaz.uk.xensource.com> Date: Wed, 28 Sep 2011 19:26:01 +0400 X-Google-Sender-Auth: 54SUgWL4gyQknisKjuVqXd4F0w4 Message-ID: <CACaajQtS4gOr0Api9X7wJftB+r+1--m8wnL_LE2Xe+6=TKaWEg@mail.gmail.com> Subject: Re: [Xen-devel] xenbus/xenstore protocol description From: Vasiliy Tolstov <v.tolstov@selfip.ru> To: Ian Campbell <Ian.Campbell@citrix.com> Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com> X-BeenThere: xen-devel@lists.xensource.com X-Mailman-Version: 2.1.5 Precedence: list List-Id: Xen developer discussion <xen-devel.lists.xensource.com> List-Unsubscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe> List-Post: <mailto:xen-devel@lists.xensource.com> List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help> List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=subscribe> Content-Type: multipart/mixed; boundary="===============1498978470==" Sender: xen-devel-bounces@lists.xensource.com Errors-To: xen-devel-bounces@lists.xensource.com --===============1498978470== Content-Type: multipart/alternative; boundary=0016e659f74a784fa104ae0202f2 --0016e659f74a784fa104ae0202f2 Content-Type: text/plain; charset=UTF-8 2011/9/28 Ian Campbell <Ian.Campbell@citrix.com> > On Wed, 2011-09-28 at 12:42 +0100, Vasiliy Tolstov wrote: > > Hello. Can somebody send me link to xensotre/xenbus protocol > > description, > > docs/misc/xenstore.txt > > > i can't use xenstore libs > > Why not? The xenstore libs are available in most distros, even if you > are running in domU. > > In addition libxenstore supports for being used statically for cases > where you are deploying into generic/unknown environments (such as for > use in a guest agent). As do the xenstore-* tools > > Ian. > > > > and want to read/write some values to xenstore via os read/write > > to /proc/xen/xenbus... > > > Static binary that used in compile in debian, does not work under centos... And us i see - implement for domU xenstore proto not too hard... it writes to xenbus C struct with 4 fileds and read response... -- Vasiliy Tolstov, Clodo.ru e-mail: v.tolstov@selfip.ru jabber: vase@selfip.ru --0016e659f74a784fa104ae0202f2 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable <br><br><div class=3D"gmail_quote">2011/9/28 Ian Campbell <span dir=3D"ltr"= ><<a href=3D"mailto:Ian.Campbell@citrix.com">Ian.Campbell@citrix.com</a>= ></span><br><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex= ;border-left:1px #ccc solid;padding-left:1ex;"> <div class=3D"im">On Wed, 2011-09-28 at 12:42 +0100, Vasiliy Tolstov wrote:= <br> > Hello. Can somebody send me link to xensotre/xenbus protocol<br> > description,<br> <br> </div>docs/misc/xenstore.txt<br> <div class=3D"im"><br> > =C2=A0i can't use xenstore libs<br> <br> </div>Why not? The xenstore libs are available in most distros, even if you= <br> are running in domU.<br> <br> In addition libxenstore supports for being used statically for cases<br> where you are deploying into generic/unknown environments (such as for<br> use in a guest agent). As do the xenstore-* tools<br> <font color=3D"#888888"><br> Ian.<br> </font><div><div></div><div class=3D"h5"><br> <br> > =C2=A0and want to read/write some values to xenstore via os read/write= <br> > to /proc/xen/xenbus...<br> <br> <br> </div></div></blockquote></div><br>Static binary that used in compile in de= bian, does not work under centos...<div>And us i see - implement for domU x= enstore proto not too hard... it writes to xenbus C struct with 4 fileds an= d read response...<br clear=3D"all"> <div><br></div>-- <br><span style=3D"border-collapse:collapse;color:rgb(136= , 136, 136);font-family:arial, sans-serif;font-size:13px"><div><div>Vasiliy= Tolstov,</div><div>Clodo.ru</div><div>e-mail: <a href=3D"mailto:v.tolstov@= selfip.ru" target=3D"_blank">v.tolstov@selfip.ru</a></div> <div>jabber: <a href=3D"mailto:vase@selfip.ru" target=3D"_blank">vase@selfi= p.ru</a></div></div></span><br> </div> --0016e659f74a784fa104ae0202f2-- --===============1498978470== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel --===============1498978470==-- From xen-devel-bounces@lists.xensource.com Wed Sep 28 08:29:35 2011 Return-path: <xen-devel-bounces@lists.xensource.com> Envelope-to: www-data@lists.xensource.com Delivery-date: Wed, 28 Sep 2011 08:29:35 -0700 Received: from localhost ([127.0.0.1] helo=lists.colo.xensource.com) by lists.xensource.com with esmtp (Exim 4.43) id 1R8w4l-00037v-RV; Wed, 28 Sep 2011 08:29:35 -0700 Received: from mail216.messagelabs.com ([85.158.143.99]) by lists.xensource.com with esmtp (Exim 4.43) id 1R8w3p-0002vX-0h for xen-devel@lists.xensource.com; Wed, 28 Sep 2011 08:28:37 -0700 X-Env-Sender: vase@selfip.ru X-Msg-Ref: server-4.tower-216.messagelabs.com!1317223713!19880455!1 X-Originating-IP: [74.125.82.171] X-StarScan-Version: 6.4.1; banners=-,-,- X-VirusChecked: Checked Received: (qmail 11122 invoked from network); 28 Sep 2011 15:28:33 -0000 Received: from mail-wy0-f171.google.com (HELO mail-wy0-f171.google.com) (74.125.82.171) by server-4.tower-216.messagelabs.com with RC4-SHA encrypted SMTP; 28 Sep 2011 15:28:33 -0000 Received: by wyh13 with SMTP id 13so167364wyh.30 for <xen-devel@lists.xensource.com>; Wed, 28 Sep 2011 08:28:33 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=selfip.ru; s=google; h=mime-version:sender:x-originating-ip:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type; bh=Yjm/MizMlkJBVFVG7JmMOVUZhUn2J36Ki3yxYy6SJA0=; b=SclzVTx3aPwXiH9rTEPXh4vv7juP0UcluTi43b+VS4/sbTAQJ5zL+0UlqOCgplSmDQ AlO0sshH9Q+HtZb8aiylM1RwgNmOI7HY5kp7abGECDgbC7rBvpbcBn5ouc2Oa71oK1VL spqeLi3NhnUB+/W8djxqC4+elN7smQhfNXHLk= MIME-Version: 1.0 Received: by 10.216.163.194 with SMTP id a44mr131982wel.1.1317223713615; Wed, 28 Sep 2011 08:28:33 -0700 (PDT) Received: by 10.216.4.69 with HTTP; Wed, 28 Sep 2011 08:28:33 -0700 (PDT) X-Originating-IP: [85.143.161.18] In-Reply-To: <CACaajQtS4gOr0Api9X7wJftB+r+1--m8wnL_LE2Xe+6=TKaWEg@mail.gmail.com> References: <CACaajQv4jgsQZhR62g8-k69OTuzNGHB2N4ZZfcs0TZJGbqa3JQ@mail.gmail.com> <1317223060.26672.72.camel@zakaz.uk.xensource.com> <CACaajQtS4gOr0Api9X7wJftB+r+1--m8wnL_LE2Xe+6=TKaWEg@mail.gmail.com> Date: Wed, 28 Sep 2011 19:28:33 +0400 X-Google-Sender-Auth: 0GvOw-pVT6Ow66H_eDE5lUoOKDQ Message-ID: <CACaajQvn49Xpb=JvGYoapvXkh8zXp5EchGzuT0fhLEA=i6wSdA@mail.gmail.com> Subject: Re: [Xen-devel] xenbus/xenstore protocol description From: Vasiliy Tolstov <v.tolstov@selfip.ru> To: Ian Campbell <Ian.Campbell@citrix.com> Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com> X-BeenThere: xen-devel@lists.xensource.com X-Mailman-Version: 2.1.5 Precedence: list List-Id: Xen developer discussion <xen-devel.lists.xensource.com> List-Unsubscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe> List-Post: <mailto:xen-devel@lists.xensource.com> List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help> List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=subscribe> Content-Type: multipart/mixed; boundary="===============1288434541==" Sender: xen-devel-bounces@lists.xensource.com Errors-To: xen-devel-bounces@lists.xensource.com --===============1288434541== Content-Type: multipart/alternative; boundary=0016367f9df88a2eb104ae020bcd --0016367f9df88a2eb104ae020bcd Content-Type: text/plain; charset=UTF-8 2011/9/28 Vasiliy Tolstov <v.tolstov@selfip.ru> > >> >> In addition libxenstore supports for being used statically for cases >> where you are deploying into generic/unknown environments (such as for >> use in a guest agent). As do the xenstore-* tools >> >> Ian. >> >> This cool if program written in C, if the program in Lua or something else - for that you not need to use C functions, all operations may be done on native language Lua/Go. P.S. I'm partialy write Golang xenstore bindings, that uses C xenstore libs. Now i'm try to rewrite it to use only /proc/xen/xenbus. -- Vasiliy Tolstov, Clodo.ru e-mail: v.tolstov@selfip.ru jabber: vase@selfip.ru --0016367f9df88a2eb104ae020bcd Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable <br><br><div class=3D"gmail_quote">2011/9/28 Vasiliy Tolstov <span dir=3D"l= tr"><<a href=3D"mailto:v.tolstov@selfip.ru">v.tolstov@selfip.ru</a>><= /span><br><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;bord= er-left:1px #ccc solid;padding-left:1ex;"> <div><div></div><div class=3D"h5"><div class=3D"gmail_quote"><blockquote cl= ass=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;p= adding-left:1ex"><br> <br> In addition libxenstore supports for being used statically for cases<br> where you are deploying into generic/unknown environments (such as for<br> use in a guest agent). As do the xenstore-* tools<br> <font color=3D"#888888"><br> Ian.<br> </font><div><div></div><div><br></div></div></blockquote></div></div></div>= </blockquote><div><br></div><div>This cool if program written in C, if the = program in Lua or something else - for that you not need to use C functions= , all operations may be done on native language Lua/Go.</div> <div>P.S. I'm partialy write Golang xenstore bindings, that uses C xens= tore libs. Now i'm try to rewrite it to use only /proc/xen/xenbus.=C2= =A0</div></div><div><br></div>-- <br><span style=3D"border-collapse:collaps= e;color:rgb(136, 136, 136);font-family:arial, sans-serif;font-size:13px"><d= iv> <div>Vasiliy Tolstov,</div><div>Clodo.ru</div><div>e-mail: <a href=3D"mailt= o:v.tolstov@selfip.ru" target=3D"_blank">v.tolstov@selfip.ru</a></div><div>= jabber: <a href=3D"mailto:vase@selfip.ru" target=3D"_blank">vase@selfip.ru<= /a></div> </div></span><br> --0016367f9df88a2eb104ae020bcd-- --===============1288434541== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel --===============1288434541==-- From xen-devel-bounces@lists.xensource.com Wed Sep 28 08:32:30 2011 Return-path: <xen-devel-bounces@lists.xensource.com> Envelope-to: www-data@lists.xensource.com Delivery-date: Wed, 28 Sep 2011 08:32:30 -0700 Received: from localhost ([127.0.0.1] helo=lists.colo.xensource.com) by lists.xensource.com with esmtp (Exim 4.43) id 1R8w7a-0003ja-6o; Wed, 28 Sep 2011 08:32:30 -0700 Received: from mail27.messagelabs.com ([193.109.254.147]) by lists.xensource.com with esmtp (Exim 4.43) id 1R8w6f-0003Pj-Bu for xen-devel@lists.xensource.com; Wed, 28 Sep 2011 08:31:34 -0700 X-Env-Sender: Ian.Jackson@eu.citrix.com X-Msg-Ref: server-8.tower-27.messagelabs.com!1317223873!48477313!1 X-Originating-IP: [62.200.22.115] X-StarScan-Version: 6.4.1; banners=-,-,- X-VirusChecked: Checked Received: (qmail 28204 invoked from network); 28 Sep 2011 15:31:13 -0000 Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115) by server-8.tower-27.messagelabs.com with RC4-SHA encrypted SMTP; 28 Sep 2011 15:31:13 -0000 X-IronPort-AV: E=Sophos;i="4.68,456,1312156800"; d="scan'208";a="8109160" Received: from lonpmailmx01.citrite.net ([10.30.203.162]) by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5; 28 Sep 2011 15:31:30 +0000 Received: from norwich.cam.xci-test.com (10.80.248.129) by smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id 8.3.137.0; Wed, 28 Sep 2011 16:31:30 +0100 Received: from mariner.cam.xci-test.com ([10.80.2.22] helo=mariner.uk.xensource.com ident=Debian-exim) by norwich.cam.xci-test.com with esmtp (Exim 4.72) (envelope-from <Ian.Jackson@eu.citrix.com>) id 1R8w6c-0002gx-1a; Wed, 28 Sep 2011 15:31:30 +0000 Received: from iwj by mariner.uk.xensource.com with local (Exim 4.69) (envelope-from <Ian.Jackson@eu.citrix.com>) id 1R8w6c-0007PP-0g; Wed, 28 Sep 2011 16:31:30 +0100 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Message-ID: <20099.15826.8587.164892@mariner.uk.xensource.com> Date: Wed, 28 Sep 2011 16:31:30 +0100 To: Ian Campbell <ian.campbell@citrix.com> Subject: Re: [Xen-devel] [PATCH] libxl: fail to parse disk vpath if a disk+part number is required but unavailable Newsgroups: chiark.mail.xen.devel In-Reply-To: <1b2f4f3c9f696270ba7e.1316613363@cosworth.uk.xensource.com> References: <1b2f4f3c9f696270ba7e.1316613363@cosworth.uk.xensource.com> X-Mailer: VM 8.0.9 under Emacs 21.4.1 (i486-pc-linux-gnu) From: Ian Jackson <Ian.Jackson@eu.citrix.com> Cc: xen-devel@lists.xensource.com X-BeenThere: xen-devel@lists.xensource.com X-Mailman-Version: 2.1.5 Precedence: list List-Id: Xen developer discussion <xen-devel.lists.xensource.com> List-Unsubscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe> List-Post: <mailto:xen-devel@lists.xensource.com> List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help> List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=subscribe> Sender: xen-devel-bounces@lists.xensource.com Errors-To: xen-devel-bounces@lists.xensource.com Ian Campbell writes ("[Xen-devel] [PATCH] libxl: fail to parse disk vpath if a disk+part number is required but unavailable"): > libxl: fail to parse disk vpath if a disk+part number is required but unavailable Acked-by: Ian Jackson <ian.jackson@eu.citrix.com> Committed-by: Ian Jackson <ian.jackson@eu.citrix.com> _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel From xen-devel-bounces@lists.xensource.com Wed Sep 28 08:33:32 2011 Return-path: <xen-devel-bounces@lists.xensource.com> Envelope-to: www-data@lists.xensource.com Delivery-date: Wed, 28 Sep 2011 08:33:32 -0700 Received: from localhost ([127.0.0.1] helo=lists.colo.xensource.com) by lists.xensource.com with esmtp (Exim 4.43) id 1R8w8a-00046a-Md; Wed, 28 Sep 2011 08:33:32 -0700 Received: from mail27.messagelabs.com ([193.109.254.147]) by lists.xensource.com with esmtp (Exim 4.43) id 1R8w7o-0003oG-ST for xen-devel@lists.xensource.com; Wed, 28 Sep 2011 08:32:45 -0700 X-Env-Sender: Ian.Jackson@eu.citrix.com X-Msg-Ref: server-2.tower-27.messagelabs.com!1317223935!56838755!1 X-Originating-IP: [62.200.22.115] X-StarScan-Version: 6.4.1; banners=-,-,- X-VirusChecked: Checked Received: (qmail 19044 invoked from network); 28 Sep 2011 15:32:15 -0000 Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115) by server-2.tower-27.messagelabs.com with RC4-SHA encrypted SMTP; 28 Sep 2011 15:32:15 -0000 X-IronPort-AV: E=Sophos;i="4.68,456,1312156800"; d="scan'208";a="8109192" Received: from lonpmailmx01.citrite.net ([10.30.203.162]) by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5; 28 Sep 2011 15:32:41 +0000 Received: from norwich.cam.xci-test.com (10.80.248.129) by smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id 8.3.137.0; Wed, 28 Sep 2011 16:32:41 +0100 Received: from mariner.cam.xci-test.com ([10.80.2.22] helo=mariner.uk.xensource.com ident=Debian-exim) by norwich.cam.xci-test.com with esmtp (Exim 4.72) (envelope-from <Ian.Jackson@eu.citrix.com>) id 1R8w7l-0002hD-De; Wed, 28 Sep 2011 15:32:41 +0000 Received: from iwj by mariner.uk.xensource.com with local (Exim 4.69) (envelope-from <Ian.Jackson@eu.citrix.com>) id 1R8w7l-0007Rb-Cf; Wed, 28 Sep 2011 16:32:41 +0100 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Message-ID: <20099.15897.383176.226301@mariner.uk.xensource.com> Date: Wed, 28 Sep 2011 16:32:41 +0100 To: Ian Campbell <ian.campbell@citrix.com> Subject: Re: [Xen-devel] [PATCH] libxl: correctly propagate errors from libxl_domain_destroy Newsgroups: chiark.mail.xen.devel In-Reply-To: <7c4b34932f2b44fb7050.1316613413@cosworth.uk.xensource.com> References: <7c4b34932f2b44fb7050.1316613413@cosworth.uk.xensource.com> X-Mailer: VM 8.0.9 under Emacs 21.4.1 (i486-pc-linux-gnu) From: Ian Jackson <Ian.Jackson@eu.citrix.com> Cc: xen-devel@lists.xensource.com X-BeenThere: xen-devel@lists.xensource.com X-Mailman-Version: 2.1.5 Precedence: list List-Id: Xen developer discussion <xen-devel.lists.xensource.com> List-Unsubscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe> List-Post: <mailto:xen-devel@lists.xensource.com> List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help> List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=subscribe> Sender: xen-devel-bounces@lists.xensource.com Errors-To: xen-devel-bounces@lists.xensource.com Ian Campbell writes ("[Xen-devel] [PATCH] libxl: correctly propagate errors from libxl_domain_destroy"): > libxl: correctly propagate errors from libxl_domain_destroy Acked-by: Ian Jackson <ian.jackson@eu.citrix.com> Committed-by: Ian Jackson <ian.jackson@eu.citrix.com> _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel From xen-devel-bounces@lists.xensource.com Wed Sep 28 08:35:24 2011 Return-path: <xen-devel-bounces@lists.xensource.com> Envelope-to: www-data@lists.xensource.com Delivery-date: Wed, 28 Sep 2011 08:35:24 -0700 Received: from localhost ([127.0.0.1] helo=lists.colo.xensource.com) by lists.xensource.com with esmtp (Exim 4.43) id 1R8wAO-0004Ub-Ky; Wed, 28 Sep 2011 08:35:24 -0700 Received: from mail174.messagelabs.com ([85.158.138.51]) by lists.xensource.com with esmtp (Exim 4.43) id 1R8w9y-0004IJ-UJ for xen-devel@lists.xensource.com; Wed, 28 Sep 2011 08:34:59 -0700 X-Env-Sender: Ian.Jackson@eu.citrix.com X-Msg-Ref: server-3.tower-174.messagelabs.com!1317224095!27055865!1 X-Originating-IP: [62.200.22.115] X-StarScan-Version: 6.4.1; banners=-,-,- X-VirusChecked: Checked Received: (qmail 32568 invoked from network); 28 Sep 2011 15:34:55 -0000 Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115) by server-3.tower-174.messagelabs.com with RC4-SHA encrypted SMTP; 28 Sep 2011 15:34:55 -0000 X-IronPort-AV: E=Sophos;i="4.68,456,1312156800"; d="scan'208";a="8109255" Received: from lonpmailmx01.citrite.net ([10.30.203.162]) by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5; 28 Sep 2011 15:34:55 +0000 Received: from norwich.cam.xci-test.com (10.80.248.129) by smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id 8.3.137.0; Wed, 28 Sep 2011 16:34:55 +0100 Received: from mariner.cam.xci-test.com ([10.80.2.22] helo=mariner.uk.xensource.com ident=Debian-exim) by norwich.cam.xci-test.com with esmtp (Exim 4.72) (envelope-from <Ian.Jackson@eu.citrix.com>) id 1R8w9v-0002hs-5B; Wed, 28 Sep 2011 15:34:55 +0000 Received: from iwj by mariner.uk.xensource.com with local (Exim 4.69) (envelope-from <Ian.Jackson@eu.citrix.com>) id 1R8w9v-0007TJ-4I; Wed, 28 Sep 2011 16:34:55 +0100 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Message-ID: <20099.16031.124516.403982@mariner.uk.xensource.com> Date: Wed, 28 Sep 2011 16:34:55 +0100 To: Ian Campbell <ian.campbell@citrix.com> Subject: Re: [Xen-devel] [PATCH] libxl: correct allocation size in libxl_list_vm Newsgroups: chiark.mail.xen.devel In-Reply-To: <4a6d34dffcf9d568a783.1316613329@cosworth.uk.xensource.com> References: <4a6d34dffcf9d568a783.1316613329@cosworth.uk.xensource.com> X-Mailer: VM 8.0.9 under Emacs 21.4.1 (i486-pc-linux-gnu) From: Ian Jackson <Ian.Jackson@eu.citrix.com> Cc: xen-devel@lists.xensource.com X-BeenThere: xen-devel@lists.xensource.com X-Mailman-Version: 2.1.5 Precedence: list List-Id: Xen developer discussion <xen-devel.lists.xensource.com> List-Unsubscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe> List-Post: <mailto:xen-devel@lists.xensource.com> List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help> List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=subscribe> Sender: xen-devel-bounces@lists.xensource.com Errors-To: xen-devel-bounces@lists.xensource.com Ian Campbell writes ("[Xen-devel] [PATCH] libxl: correct allocation size in libxl_list_vm"): > libxl: correct allocation size in libxl_list_vm Acked-by: Ian Jackson <ian.jackson@eu.citrix.com> Committed-by: Ian Jackson <ian.jackson@eu.citrix.com> > *ptr has type libxl_vminfo not libxl_domid, so correct calloc call. > > This the second instance of this bug I've noticed recently, I did a > quick audit of other similar uses of sizeof(...) and all I spotted > were a couple of harmlessly reversed calloc arguments. It's a pretty > strong argument for "foo = ..alloc(sizeof(*foo))" rather than > "alloc(sizeof(foos_type))" though... The correct approach to this is to make a macro along these lines: #define OUR_CALLOC(foo) ((foo)=calloc(sizeof(*(foo)))) I think we may have some of these but we should have a complete set. Ian. _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel From xen-devel-bounces@lists.xensource.com Wed Sep 28 08:36:44 2011 Return-path: <xen-devel-bounces@lists.xensource.com> Envelope-to: www-data@lists.xensource.com Delivery-date: Wed, 28 Sep 2011 08:36:44 -0700 Received: from localhost ([127.0.0.1] helo=lists.colo.xensource.com) by lists.xensource.com with esmtp (Exim 4.43) id 1R8wBg-0004sk-FW; Wed, 28 Sep 2011 08:36:44 -0700 Received: from mail216.messagelabs.com ([85.158.143.99]) by lists.xensource.com with esmtp (Exim 4.43) id 1R8wBH-0004gz-DI for xen-devel@lists.xensource.com; Wed, 28 Sep 2011 08:36:19 -0700 X-Env-Sender: Ian.Jackson@eu.citrix.com X-Msg-Ref: server-2.tower-216.messagelabs.com!1317224176!19453728!1 X-Originating-IP: [62.200.22.115] X-StarScan-Version: 6.4.1; banners=-,-,- X-VirusChecked: Checked Received: (qmail 29485 invoked from network); 28 Sep 2011 15:36:16 -0000 Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115) by server-2.tower-216.messagelabs.com with RC4-SHA encrypted SMTP; 28 Sep 2011 15:36:16 -0000 X-IronPort-AV: E=Sophos;i="4.68,456,1312156800"; d="scan'208";a="8109291" Received: from lonpmailmx01.citrite.net ([10.30.203.162]) by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5; 28 Sep 2011 15:35:59 +0000 Received: from norwich.cam.xci-test.com (10.80.248.129) by smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id 8.3.137.0; Wed, 28 Sep 2011 16:35:59 +0100 Received: from mariner.cam.xci-test.com ([10.80.2.22] helo=mariner.uk.xensource.com ident=Debian-exim) by norwich.cam.xci-test.com with esmtp (Exim 4.72) (envelope-from <Ian.Jackson@eu.citrix.com>) id 1R8wAw-0002iE-Vj; Wed, 28 Sep 2011 15:35:59 +0000 Received: from iwj by mariner.uk.xensource.com with local (Exim 4.69) (envelope-from <Ian.Jackson@eu.citrix.com>) id 1R8wAw-0007V3-Ut; Wed, 28 Sep 2011 16:35:58 +0100 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Message-ID: <20099.16094.947249.669043@mariner.uk.xensource.com> Date: Wed, 28 Sep 2011 16:35:58 +0100 To: Ian Campbell <ian.campbell@citrix.com> Subject: Re: [Xen-devel] [PATCH] libxl: correct allocation size in libxl_list_nics Newsgroups: chiark.mail.xen.devel In-Reply-To: <b11af4a5cdc6a94e41a8.1316613284@cosworth.uk.xensource.com> References: <b11af4a5cdc6a94e41a8.1316613284@cosworth.uk.xensource.com> X-Mailer: VM 8.0.9 under Emacs 21.4.1 (i486-pc-linux-gnu) From: Ian Jackson <Ian.Jackson@eu.citrix.com> Cc: xen-devel@lists.xensource.com X-BeenThere: xen-devel@lists.xensource.com X-Mailman-Version: 2.1.5 Precedence: list List-Id: Xen developer discussion <xen-devel.lists.xensource.com> List-Unsubscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe> List-Post: <mailto:xen-devel@lists.xensource.com> List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help> List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=subscribe> Sender: xen-devel-bounces@lists.xensource.com Errors-To: xen-devel-bounces@lists.xensource.com Ian Campbell writes ("[Xen-devel] [PATCH] libxl: correct allocation size in libxl_list_nics"): > libxl: correct allocation size in libxl_list_nics Acked-by: Ian Jackson <ian.jackson@eu.citrix.com> Committed-by: Ian Jackson <ian.jackson@eu.citrix.com> _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel From xen-devel-bounces@lists.xensource.com Wed Sep 28 08:39:07 2011 Return-path: <xen-devel-bounces@lists.xensource.com> Envelope-to: www-data@lists.xensource.com Delivery-date: Wed, 28 Sep 2011 08:39:07 -0700 Received: from localhost ([127.0.0.1] helo=lists.colo.xensource.com) by lists.xensource.com with esmtp (Exim 4.43) id 1R8wDz-0005Io-6p; Wed, 28 Sep 2011 08:39:07 -0700 Received: from mail216.messagelabs.com ([85.158.143.99]) by lists.xensource.com with esmtp (Exim 4.43) id 1R8wDV-00055T-Tq for xen-devel@lists.xensource.com; Wed, 28 Sep 2011 08:38:38 -0700 X-Env-Sender: linus971@gmail.com X-Msg-Ref: server-8.tower-216.messagelabs.com!1317224314!16787261!1 X-Originating-IP: [74.125.82.43] X-StarScan-Version: 6.4.1; banners=-,-,- X-VirusChecked: Checked Received: (qmail 31901 invoked from network); 28 Sep 2011 15:38:34 -0000 Received: from mail-ww0-f43.google.com (HELO mail-ww0-f43.google.com) (74.125.82.43) by server-8.tower-216.messagelabs.com with RC4-SHA encrypted SMTP; 28 Sep 2011 15:38:34 -0000 Received: by wwf27 with SMTP id 27so7336717wwf.24 for <xen-devel@lists.xensource.com>; Wed, 28 Sep 2011 08:38:34 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:sender:in-reply-to:references:from:date :x-google-sender-auth:message-id:subject:to:cc:content-type :content-transfer-encoding; bh=1Pwf5T6ABphmq7zLc1XTW+0iuRd4KWfrHe9ZVKckJ0U=; b=ezL2p/E3qRrc9p5iXX2mN7AGxqc1cVID8cH1VsCkmZqaBTdxZTseKnsHNgGLxmtWFk dn2dx/b4UEMpqbOWk2wpnH3XqZxGDWFqMwAPYo4LL0ysiLFXw3h72DLyQ0YJ+WwhkPV7 cfPGiDmQhYLdVZj4N1LZLde5/7NC0yPg/v7zY= Received: by 10.216.229.136 with SMTP id h8mr10014455weq.93.1317224314607; Wed, 28 Sep 2011 08:38:34 -0700 (PDT) MIME-Version: 1.0 Received: by 10.216.11.12 with HTTP; Wed, 28 Sep 2011 08:38:14 -0700 (PDT) In-Reply-To: <4E81FD52.50106@goop.org> References: <cover.1315878463.git.jeremy.fitzhardinge@citrix.com> <3300108.XQUp9Wrktc@chlor> <4E81FD52.50106@goop.org> From: Linus Torvalds <torvalds@linux-foundation.org> Date: Wed, 28 Sep 2011 08:38:14 -0700 X-Google-Sender-Auth: ZXzhlRZbYYNMcidK3UXDSMiv5MY Message-ID: <CA+55aFx7dv4C4ZB_3CFjdJmX_wpoxecpqo1ARYr1=zTVP=CVVA@mail.gmail.com> Subject: Re: [Xen-devel] [PATCH 00/10] [PATCH RFC V2] Paravirtualized ticketlocks To: Jeremy Fitzhardinge <jeremy@goop.org> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: xen-devel@lists.xensource.com, Nick Piggin <npiggin@kernel.dk>, KVM <kvm@vger.kernel.org>, Peter Zijlstra <peterz@infradead.org>, Marcelo Tosatti <mtosatti@redhat.com>, the arch/x86 maintainers <x86@kernel.org>, Linux Kernel Mailing List <linux-kernel@vger.kernel.org>, Andi Kleen <andi@firstfloor.org>, Avi Kivity <avi@redhat.com>, Jeremy Fitzhardinge <jeremy.fitzhardinge@citrix.com>, "H. Peter Anvin" <hpa@zytor.com>, Ingo Molnar <mingo@elte.hu>, Stephan Diestelhorst <stephan.diestelhorst@amd.com> X-BeenThere: xen-devel@lists.xensource.com X-Mailman-Version: 2.1.5 Precedence: list List-Id: Xen developer discussion <xen-devel.lists.xensource.com> List-Unsubscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe> List-Post: <mailto:xen-devel@lists.xensource.com> List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help> List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=subscribe> Sender: xen-devel-bounces@lists.xensource.com Errors-To: xen-devel-bounces@lists.xensource.com On Tue, Sep 27, 2011 at 9:44 AM, Jeremy Fitzhardinge <jeremy@goop.org> wrot= e: > > I guess it comes down to throwing myself on the efficiency of some kind > of fence instruction. =A0I guess an lfence would be sufficient; is that > any more efficient than a full mfence? =A0At least I can make it so that > its only present when pv ticket locks are actually in use, so it won't > affect the native case. Please don't play with fences, just do the final "addb" as a locked instruc= tion. In fact, don't even use an addb, this whole thing is disgusting: movzwl (%rdi),%esi (esi:=3D0x0400) addb $0x2,(%rdi) (LOCAL copy of lock is now: 0x0402) movzwl (%rdi),%eax (local forwarding from previous store: eax :=3D 0x0402= ) just use "lock xaddw" there too. The fact that the PV unlock is going to be much more expensive than a regular native unlock is just a fact of life. It comes from fundamentally caring about the old/new value, and has nothing to do with aliasing. You care about the other bits, and it doesn't matter where in memory they are. The native unlock can do a simple "addb" (or incb), but that doesn't mean the PV unlock can. There are no ordering issues with the final unlock in the native case, because the native unlock is like the honey badger: it don't care. It only cares that the store make it out *some* day, but it doesn't care about what order the upper/lower bits get updated. You do. So you have to use a locked access. Good catch by Stephan. Linus _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel From xen-devel-bounces@lists.xensource.com Wed Sep 28 08:43:08 2011 Return-path: <xen-devel-bounces@lists.xensource.com> Envelope-to: www-data@lists.xensource.com Delivery-date: Wed, 28 Sep 2011 08:43:08 -0700 Received: from localhost ([127.0.0.1] helo=lists.colo.xensource.com) by lists.xensource.com with esmtp (Exim 4.43) id 1R8wHs-0005sj-6I; Wed, 28 Sep 2011 08:43:08 -0700 Received: from mail27.messagelabs.com ([193.109.254.147]) by lists.xensource.com with esmtp (Exim 4.43) id 1R8wHN-0005b8-Sd for xen-devel@lists.xensource.com; Wed, 28 Sep 2011 08:42:38 -0700 X-Env-Sender: Ian.Jackson@eu.citrix.com X-Msg-Ref: server-7.tower-27.messagelabs.com!1317224530!50527272!1 X-Originating-IP: [62.200.22.115] X-StarScan-Version: 6.4.1; banners=-,-,- X-VirusChecked: Checked Received: (qmail 32567 invoked from network); 28 Sep 2011 15:42:10 -0000 Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115) by server-7.tower-27.messagelabs.com with RC4-SHA encrypted SMTP; 28 Sep 2011 15:42:10 -0000 X-IronPort-AV: E=Sophos;i="4.68,456,1312156800"; d="scan'208";a="8109485" Received: from lonpmailmx01.citrite.net ([10.30.203.162]) by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5; 28 Sep 2011 15:42:34 +0000 Received: from norwich.cam.xci-test.com (10.80.248.129) by smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id 8.3.137.0; Wed, 28 Sep 2011 16:42:34 +0100 Received: from mariner.cam.xci-test.com ([10.80.2.22] helo=mariner.uk.xensource.com ident=Debian-exim) by norwich.cam.xci-test.com with esmtp (Exim 4.72) (envelope-from <Ian.Jackson@eu.citrix.com>) id 1R8wHK-0002jp-7d; Wed, 28 Sep 2011 15:42:34 +0000 Received: from iwj by mariner.uk.xensource.com with local (Exim 4.69) (envelope-from <Ian.Jackson@eu.citrix.com>) id 1R8wHK-0007ru-6p; Wed, 28 Sep 2011 16:42:34 +0100 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Message-ID: <20099.16489.987441.770816@mariner.uk.xensource.com> Date: Wed, 28 Sep 2011 16:42:33 +0100 To: Ian Campbell <ian.campbell@citrix.com> Subject: Re: [Xen-devel] [PATCH] libxl: attempt to cleanup tapdisk processes on disk backend destroy Newsgroups: chiark.mail.xen.devel In-Reply-To: <b43fd821d1aebc8671e6.1316613248@cosworth.uk.xensource.com> References: <b43fd821d1aebc8671e6.1316613248@cosworth.uk.xensource.com> X-Mailer: VM 8.0.9 under Emacs 21.4.1 (i486-pc-linux-gnu) From: Ian Jackson <Ian.Jackson@eu.citrix.com> Cc: xen-devel@lists.xensource.com X-BeenThere: xen-devel@lists.xensource.com X-Mailman-Version: 2.1.5 Precedence: list List-Id: Xen developer discussion <xen-devel.lists.xensource.com> List-Unsubscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe> List-Post: <mailto:xen-devel@lists.xensource.com> List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help> List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=subscribe> Sender: xen-devel-bounces@lists.xensource.com Errors-To: xen-devel-bounces@lists.xensource.com Ian Campbell writes ("[Xen-devel] [PATCH] libxl: attempt to cleanup tapdisk processes on disk backend destroy"): > libxl: attempt to cleanup tapdisk processes on disk backend destroy. This looks plausible to me, although I'm not hugely familiar with the tapdisk machinery. Committed-by: Ian Jackson <ian.jackson@eu.citrix.com> _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel From xen-devel-bounces@lists.xensource.com Wed Sep 28 08:47:24 2011 Return-path: <xen-devel-bounces@lists.xensource.com> Envelope-to: www-data@lists.xensource.com Delivery-date: Wed, 28 Sep 2011 08:47:24 -0700 Received: from localhost ([127.0.0.1] helo=lists.colo.xensource.com) by lists.xensource.com with esmtp (Exim 4.43) id 1R8wM0-0006M0-NZ; Wed, 28 Sep 2011 08:47:24 -0700 Received: from mail182.messagelabs.com ([85.158.139.83]) by lists.xensource.com with esmtp (Exim 4.43) id 1R8wLZ-00069d-1E for xen-devel@lists.xensource.com; Wed, 28 Sep 2011 08:46:57 -0700 X-Env-Sender: Ian.Campbell@eu.citrix.com X-Msg-Ref: server-8.tower-182.messagelabs.com!1317224812!18929497!1 X-Originating-IP: [66.165.176.89] X-StarScan-Version: 6.4.1; banners=-,-,- X-VirusChecked: Checked Received: (qmail 23799 invoked from network); 28 Sep 2011 15:46:53 -0000 Received: from smtp.citrix.com (HELO SMTP.CITRIX.COM) (66.165.176.89) by server-8.tower-182.messagelabs.com with RC4-SHA encrypted SMTP; 28 Sep 2011 15:46:53 -0000 X-IronPort-AV: E=Sophos;i="4.68,456,1312171200"; d="scan'208";a="17777325" Received: from ftlpmailmx02.citrite.net ([10.13.107.66]) by FTLPIPO01.CITRIX.COM with ESMTP/TLS/RC4-MD5; 28 Sep 2011 11:46:52 -0400 Received: from smtp01.ad.xensource.com (10.219.128.104) by smtprelay.citrix.com (10.13.107.66) with Microsoft SMTP Server id 8.3.137.0; Wed, 28 Sep 2011 11:46:52 -0400 Received: from cosworth.uk.xensource.com (cosworth.uk.xensource.com [10.80.16.52]) by smtp01.ad.xensource.com (8.13.1/8.13.1) with ESMTP id p8SFkoXb022851; Wed, 28 Sep 2011 08:46:50 -0700 Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Mercurial-Node: f63f089585652829ec3816590292fde32ee8fbfe Message-ID: <f63f089585652829ec38.1317224809@cosworth.uk.xensource.com> User-Agent: Mercurial-patchbomb/1.6.4 Date: Wed, 28 Sep 2011 16:46:49 +0100 From: Ian Campbell <ian.campbell@citrix.com> To: xen-devel@lists.xensource.com Cc: Ian Campbell <ian.campbell@citrix.com> Subject: [Xen-devel] [PATCH] libxl: correctly propagate errors from libxl_domain_resume X-BeenThere: xen-devel@lists.xensource.com X-Mailman-Version: 2.1.5 Precedence: list List-Id: Xen developer discussion <xen-devel.lists.xensource.com> List-Unsubscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe> List-Post: <mailto:xen-devel@lists.xensource.com> List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help> List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=subscribe> Sender: xen-devel-bounces@lists.xensource.com Errors-To: xen-devel-bounces@lists.xensource.com # HG changeset patch # User Ian Campbell <ian.campbell@citrix.com> # Date 1317224719 -3600 # Node ID f63f089585652829ec3816590292fde32ee8fbfe # Parent 5f25a693b738d2578e8803ba7ee49da1f5495a03 libxl: correctly propagate errors from libxl_domain_resume currently it return success no matter what. Signed-off-by: Ian Campbell <ian.campbell@citrix.com> diff -r 5f25a693b738 -r f63f08958565 tools/libxl/libxl.c --- a/tools/libxl/libxl.c Wed Sep 28 16:42:33 2011 +0100 +++ b/tools/libxl/libxl.c Wed Sep 28 16:45:19 2011 +0100 @@ -261,7 +261,7 @@ int libxl_domain_resume(libxl_ctx *ctx, } out: libxl__free_all(&gc); - return 0; + return rc; } /* _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel From xen-devel-bounces@lists.xensource.com Wed Sep 28 08:53:26 2011 Return-path: <xen-devel-bounces@lists.xensource.com> Envelope-to: www-data@lists.xensource.com Delivery-date: Wed, 28 Sep 2011 08:53:26 -0700 Received: from localhost ([127.0.0.1] helo=lists.colo.xensource.com) by lists.xensource.com with esmtp (Exim 4.43) id 1R8wRq-0006nH-B8; Wed, 28 Sep 2011 08:53:26 -0700 Received: from mail21.messagelabs.com ([85.158.143.35]) by lists.xensource.com with esmtp (Exim 4.43) id 1R8wR9-0006as-0f for xen-devel@lists.xensource.com; Wed, 28 Sep 2011 08:52:43 -0700 X-Env-Sender: Ian.Campbell@eu.citrix.com X-Msg-Ref: server-3.tower-21.messagelabs.com!1317225171!53310033!1 X-Originating-IP: [62.200.22.115] X-StarScan-Version: 6.4.1; banners=-,-,- X-VirusChecked: Checked Received: (qmail 31790 invoked from network); 28 Sep 2011 15:52:51 -0000 Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115) by server-3.tower-21.messagelabs.com with RC4-SHA encrypted SMTP; 28 Sep 2011 15:52:51 -0000 X-IronPort-AV: E=Sophos;i="4.68,456,1312156800"; d="scan'208";a="8109807" Received: from lonpmailmx01.citrite.net ([10.30.203.162]) by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5; 28 Sep 2011 15:52:39 +0000 Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net (10.30.203.162) with Microsoft SMTP Server id 8.3.137.0; Wed, 28 Sep 2011 16:52:39 +0100 Subject: Re: [Xen-devel] pv guests die after failed migration From: Ian Campbell <Ian.Campbell@eu.citrix.com> To: Andreas Olsowski <andreas.olsowski@leuphana.de> Date: Wed, 28 Sep 2011 16:52:39 +0100 In-Reply-To: <4E7C4E44.70508@leuphana.de> References: <4E786015.80603@leuphana.de> <1316546879.5182.26.camel@dagon.hellion.org.uk> <4E7C37BD.2000706@leuphana.de> <1316764045.23371.100.camel@zakaz.uk.xensource.com> <4E7C4E44.70508@leuphana.de> Organization: Citrix Systems, Inc. Content-Type: text/plain; charset="UTF-8" X-Mailer: Evolution 3.0.3- Content-Transfer-Encoding: 7bit Message-ID: <1317225159.26672.87.camel@zakaz.uk.xensource.com> MIME-Version: 1.0 Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com> X-BeenThere: xen-devel@lists.xensource.com X-Mailman-Version: 2.1.5 Precedence: list List-Id: Xen developer discussion <xen-devel.lists.xensource.com> List-Unsubscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe> List-Post: <mailto:xen-devel@lists.xensource.com> List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help> List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=subscribe> Sender: xen-devel-bounces@lists.xensource.com Errors-To: xen-devel-bounces@lists.xensource.com On Fri, 2011-09-23 at 10:15 +0100, Andreas Olsowski wrote: > On 09/23/2011 09:47 AM, Ian Campbell wrote: [...] > I did a clean/make/install after that, compilation worked fine. > > I then tested the migration towards an unsuitable target again and it > did what you thought it could do. The guest resumes correctly at sender [...] > So that works Great, thanks for testing. I need to figure out how to automatically select which guests are capable of a cooperative resume and which are not. > There is no mention of the migration failing in the guest log though, > maybe when a final patch is made it should log that failing migration? Are you saying that you don't see the "failed for domain %u" message immediately after the xc_domain_resume call? + if (xc_domain_resume(ctx->xch, domid, 1)) { LIBXL__LOG_ERRNO(ctx, LIBXL__LOG_ERROR, "xc_domain_resume failed for domain %u", domid); That would be pretty odd... Ian. _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel From xen-devel-bounces@lists.xensource.com Wed Sep 28 08:56:15 2011 Return-path: <xen-devel-bounces@lists.xensource.com> Envelope-to: www-data@lists.xensource.com Delivery-date: Wed, 28 Sep 2011 08:56:15 -0700 Received: from localhost ([127.0.0.1] helo=lists.colo.xensource.com) by lists.xensource.com with esmtp (Exim 4.43) id 1R8wUY-0007Cw-PU; Wed, 28 Sep 2011 08:56:14 -0700 Received: from mail182.messagelabs.com ([85.158.139.83]) by lists.xensource.com with esmtp (Exim 4.43) id 1R8wTr-000706-5W for xen-devel@lists.xensource.com; Wed, 28 Sep 2011 08:55:31 -0700 X-Env-Sender: JBeulich@suse.com X-Msg-Ref: server-12.tower-182.messagelabs.com!1317225327!19950868!1 X-Originating-IP: [130.57.49.28] X-StarScan-Version: 6.4.1; banners=-,-,- X-VirusChecked: Checked Received: (qmail 10464 invoked from network); 28 Sep 2011 15:55:28 -0000 Received: from nat28.tlf.novell.com (HELO nat28.tlf.novell.com) (130.57.49.28) by server-12.tower-182.messagelabs.com with DHE-RSA-AES256-SHA encrypted SMTP; 28 Sep 2011 15:55:28 -0000 Received: from EMEA1-MTA by nat28.tlf.novell.com with Novell_GroupWise; Wed, 28 Sep 2011 16:55:26 +0100 Message-Id: <4E835F8C0200007800058461@nat28.tlf.novell.com> X-Mailer: Novell GroupWise Internet Agent 8.0.1 Date: Wed, 28 Sep 2011 16:55:24 +0100 From: "Jan Beulich" <JBeulich@suse.com> To: "Jeremy Fitzhardinge" <jeremy@goop.org>, "Linus Torvalds" <torvalds@linux-foundation.org> Subject: Re: [Xen-devel] [PATCH 00/10] [PATCH RFC V2] Paravirtualized ticketlocks References: <cover.1315878463.git.jeremy.fitzhardinge@citrix.com> <3300108.XQUp9Wrktc@chlor> <4E81FD52.50106@goop.org> <CA+55aFx7dv4C4ZB_3CFjdJmX_wpoxecpqo1ARYr1=zTVP=CVVA@mail.gmail.com> In-Reply-To: <CA+55aFx7dv4C4ZB_3CFjdJmX_wpoxecpqo1ARYr1=zTVP=CVVA@mail.gmail.com> Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: quoted-printable Content-Disposition: inline Cc: Jeremy Fitzhardinge <jeremy.fitzhardinge@citrix.com>, Nick Piggin <npiggin@kernel.dk>, KVM <kvm@vger.kernel.org>, Peter Zijlstra <peterz@infradead.org>, the arch/x86 maintainers <x86@kernel.org>, Linux Kernel Mailing List <linux-kernel@vger.kernel.org>, Marcelo Tosatti <mtosatti@redhat.com>, Andi Kleen <andi@firstfloor.org>, Avi Kivity <avi@redhat.com>, "H. Peter Anvin" <hpa@zytor.com>, Ingo Molnar <mingo@elte.hu>, xen-devel@lists.xensource.com, Stephan Diestelhorst <stephan.diestelhorst@amd.com> X-BeenThere: xen-devel@lists.xensource.com X-Mailman-Version: 2.1.5 Precedence: list List-Id: Xen developer discussion <xen-devel.lists.xensource.com> List-Unsubscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe> List-Post: <mailto:xen-devel@lists.xensource.com> List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help> List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=subscribe> Sender: xen-devel-bounces@lists.xensource.com Errors-To: xen-devel-bounces@lists.xensource.com >>> On 28.09.11 at 17:38, Linus Torvalds <torvalds@linux-foundation.org> = wrote: > On Tue, Sep 27, 2011 at 9:44 AM, Jeremy Fitzhardinge <jeremy@goop.org> = wrote: >> >> I guess it comes down to throwing myself on the efficiency of some kind >> of fence instruction. I guess an lfence would be sufficient; is that >> any more efficient than a full mfence? At least I can make it so that >> its only present when pv ticket locks are actually in use, so it won't >> affect the native case. >=20 > Please don't play with fences, just do the final "addb" as a locked=20 > instruction. >=20 > In fact, don't even use an addb, this whole thing is disgusting: >=20 > movzwl (%rdi),%esi (esi:=3D0x0400) > addb $0x2,(%rdi) (LOCAL copy of lock is now: 0x0402) > movzwl (%rdi),%eax (local forwarding from previous store: eax :=3D = 0x0402) >=20 > just use "lock xaddw" there too. I'm afraid that's not possible, as that might carry from the low 8 bits into the upper 8 ones, which must be avoided. Jan _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel From xen-devel-bounces@lists.xensource.com Wed Sep 28 08:57:18 2011 Return-path: <xen-devel-bounces@lists.xensource.com> Envelope-to: www-data@lists.xensource.com Delivery-date: Wed, 28 Sep 2011 08:57:18 -0700 Received: from localhost ([127.0.0.1] helo=lists.colo.xensource.com) by lists.xensource.com with esmtp (Exim 4.43) id 1R8wVa-0007bf-Lc; Wed, 28 Sep 2011 08:57:18 -0700 Received: from mail174.messagelabs.com ([85.158.138.51]) by lists.xensource.com with esmtp (Exim 4.43) id 1R8wU0-00071U-2B for xen-devel@lists.xensource.com; Wed, 28 Sep 2011 08:55:40 -0700 X-Env-Sender: Ian.Jackson@eu.citrix.com X-Msg-Ref: server-4.tower-174.messagelabs.com!1317225336!33136166!1 X-Originating-IP: [62.200.22.115] X-StarScan-Version: 6.4.1; banners=-,-,- X-VirusChecked: Checked Received: (qmail 6484 invoked from network); 28 Sep 2011 15:55:37 -0000 Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115) by server-4.tower-174.messagelabs.com with RC4-SHA encrypted SMTP; 28 Sep 2011 15:55:37 -0000 X-IronPort-AV: E=Sophos;i="4.68,456,1312156800"; d="scan'208";a="8109889" Received: from lonpmailmx01.citrite.net ([10.30.203.162]) by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5; 28 Sep 2011 15:55:36 +0000 Received: from norwich.cam.xci-test.com (10.80.248.129) by smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id 8.3.137.0; Wed, 28 Sep 2011 16:55:36 +0100 Received: from mariner.cam.xci-test.com ([10.80.2.22] helo=mariner.uk.xensource.com ident=Debian-exim) by norwich.cam.xci-test.com with esmtp (Exim 4.72) (envelope-from <Ian.Jackson@eu.citrix.com>) id 1R8wTw-0002n1-5o; Wed, 28 Sep 2011 15:55:36 +0000 Received: from iwj by mariner.uk.xensource.com with local (Exim 4.69) (envelope-from <Ian.Jackson@eu.citrix.com>) id 1R8wTw-00010w-4k; Wed, 28 Sep 2011 16:55:36 +0100 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Message-ID: <20099.17272.139799.560052@mariner.uk.xensource.com> Date: Wed, 28 Sep 2011 16:55:36 +0100 To: Anthony PERARD <anthony.perard@citrix.com> Subject: Re: [Xen-devel] [PATCH RESEND V8 0/7] Introduce a QMP client Newsgroups: chiark.mail.xen.devel In-Reply-To: <1316609997-26002-1-git-send-email-anthony.perard@citrix.com> References: <1316609997-26002-1-git-send-email-anthony.perard@citrix.com> X-Mailer: VM 8.0.9 under Emacs 21.4.1 (i486-pc-linux-gnu) From: Ian Jackson <Ian.Jackson@eu.citrix.com> Cc: Ian Campbell <Ian.Campbell@eu.citrix.com>, Xen Devel <xen-devel@lists.xensource.com>, Stefano Stabellini <stefano.stabellini@eu.citrix.com> X-BeenThere: xen-devel@lists.xensource.com X-Mailman-Version: 2.1.5 Precedence: list List-Id: Xen developer discussion <xen-devel.lists.xensource.com> List-Unsubscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe> List-Post: <mailto:xen-devel@lists.xensource.com> List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help> List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=subscribe> Sender: xen-devel-bounces@lists.xensource.com Errors-To: xen-devel-bounces@lists.xensource.com Anthony PERARD writes ("[Xen-devel] [PATCH RESEND V8 0/7] Introduce a QMP client"): > Patch series rebased on last xen-unstable. No other change have been done. Thanks. I tried to apply this and: libxl_qmp.c:293: error: 'SOCK_NONBLOCK' undeclared (first use in this function) libxl_qmp.c:293: error: (Each undeclared identifier is reported only once libxl_qmp.c:293: error: for each function it appears in.) I think SOCK_NONBLOCK is nonstandard, and you will have to change the code to use fcntl. Ian. _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel From xen-devel-bounces@lists.xensource.com Wed Sep 28 09:01:04 2011 Return-path: <xen-devel-bounces@lists.xensource.com> Envelope-to: www-data@lists.xensource.com Delivery-date: Wed, 28 Sep 2011 09:01:04 -0700 Received: from localhost ([127.0.0.1] helo=lists.colo.xensource.com) by lists.xensource.com with esmtp (Exim 4.43) id 1R8wZD-00086W-C8; Wed, 28 Sep 2011 09:01:03 -0700 Received: from mail216.messagelabs.com ([85.158.143.99]) by lists.xensource.com with esmtp (Exim 4.43) id 1R8wWT-0007mO-Ja for xen-devel@lists.xensource.com; Wed, 28 Sep 2011 08:58:14 -0700 X-Env-Sender: Ian.Jackson@eu.citrix.com X-Msg-Ref: server-13.tower-216.messagelabs.com!1317225490!18236765!1 X-Originating-IP: [62.200.22.115] X-StarScan-Version: 6.4.1; banners=-,-,- X-VirusChecked: Checked Received: (qmail 23732 invoked from network); 28 Sep 2011 15:58:10 -0000 Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115) by server-13.tower-216.messagelabs.com with RC4-SHA encrypted SMTP; 28 Sep 2011 15:58:10 -0000 X-IronPort-AV: E=Sophos;i="4.68,456,1312156800"; d="scan'208";a="8109964" Received: from lonpmailmx01.citrite.net ([10.30.203.162]) by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5; 28 Sep 2011 15:58:10 +0000 Received: from norwich.cam.xci-test.com (10.80.248.129) by smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id 8.3.137.0; Wed, 28 Sep 2011 16:58:10 +0100 Received: from mariner.cam.xci-test.com ([10.80.2.22] helo=mariner.uk.xensource.com ident=Debian-exim) by norwich.cam.xci-test.com with esmtp (Exim 4.72) (envelope-from <Ian.Jackson@eu.citrix.com>) id 1R8wWQ-0002nb-7f; Wed, 28 Sep 2011 15:58:10 +0000 Received: from iwj by mariner.uk.xensource.com with local (Exim 4.69) (envelope-from <Ian.Jackson@eu.citrix.com>) id 1R8wWQ-00011H-6n; Wed, 28 Sep 2011 16:58:10 +0100 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Message-ID: <20099.17426.176688.137409@mariner.uk.xensource.com> Date: Wed, 28 Sep 2011 16:58:10 +0100 To: <stefano.stabellini@eu.citrix.com> Subject: Re: [Xen-devel] [PATCH v6 1/5] Introduce git-checkout.sh Newsgroups: chiark.mail.xen.devel In-Reply-To: <1316779878-10950-1-git-send-email-stefano.stabellini@eu.citrix.com> References: <alpine.DEB.2.00.1109231302370.8700@kaball-desktop> <1316779878-10950-1-git-send-email-stefano.stabellini@eu.citrix.com> X-Mailer: VM 8.0.9 under Emacs 21.4.1 (i486-pc-linux-gnu) From: Ian Jackson <Ian.Jackson@eu.citrix.com> Cc: Ian.Campbell@eu.citrix.com, xen-devel@lists.xensource.com, keir@xen.org X-BeenThere: xen-devel@lists.xensource.com X-Mailman-Version: 2.1.5 Precedence: list List-Id: Xen developer discussion <xen-devel.lists.xensource.com> List-Unsubscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe> List-Post: <mailto:xen-devel@lists.xensource.com> List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help> List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=subscribe> Sender: xen-devel-bounces@lists.xensource.com Errors-To: xen-devel-bounces@lists.xensource.com stefano.stabellini@eu.citrix.com writes ("[Xen-devel] [PATCH v6 1/5] Introduce git-checkout.sh"): > Introduce a script to perform git checkout on an external git tree; use > git-checkout.sh in ioemu-dir-find. ... > +#!/bin/sh > + > +TREE=$1 > +TAG=$2 > +DIR=$3 Missing - set -e - argument count check > +if test \! -d $DIR-remote; then > + rm -rf $DIR-remote $DIR-remote.tmp; Spurious semicolons. > distclean: subdirs-distclean > - rm -rf ioemu-dir ioemu-remote > + rm -rf ioemu-dir ioemu-dir-remote Would it be too much to ask you not to rename this directory ? Ian. _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel From xen-devel-bounces@lists.xensource.com Wed Sep 28 09:03:26 2011 Return-path: <xen-devel-bounces@lists.xensource.com> Envelope-to: www-data@lists.xensource.com Delivery-date: Wed, 28 Sep 2011 09:03:26 -0700 Received: from localhost ([127.0.0.1] helo=lists.colo.xensource.com) by lists.xensource.com with esmtp (Exim 4.43) id 1R8wbV-0008Va-TO; Wed, 28 Sep 2011 09:03:26 -0700 Received: from mail216.messagelabs.com ([85.158.143.99]) by lists.xensource.com with esmtp (Exim 4.43) id 1R8wXF-0007te-HF for xen-devel@lists.xensource.com; Wed, 28 Sep 2011 08:59:02 -0700 X-Env-Sender: Ian.Jackson@eu.citrix.com X-Msg-Ref: server-10.tower-216.messagelabs.com!1317225538!10138264!1 X-Originating-IP: [62.200.22.115] X-StarScan-Version: 6.4.1; banners=-,-,- X-VirusChecked: Checked Received: (qmail 27107 invoked from network); 28 Sep 2011 15:58:58 -0000 Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115) by server-10.tower-216.messagelabs.com with RC4-SHA encrypted SMTP; 28 Sep 2011 15:58:58 -0000 X-IronPort-AV: E=Sophos;i="4.68,456,1312156800"; d="scan'208";a="8109980" Received: from lonpmailmx01.citrite.net ([10.30.203.162]) by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5; 28 Sep 2011 15:58:58 +0000 Received: from norwich.cam.xci-test.com (10.80.248.129) by smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id 8.3.137.0; Wed, 28 Sep 2011 16:58:58 +0100 Received: from mariner.cam.xci-test.com ([10.80.2.22] helo=mariner.uk.xensource.com ident=Debian-exim) by norwich.cam.xci-test.com with esmtp (Exim 4.72) (envelope-from <Ian.Jackson@eu.citrix.com>) id 1R8wXC-0002no-5n; Wed, 28 Sep 2011 15:58:58 +0000 Received: from iwj by mariner.uk.xensource.com with local (Exim 4.69) (envelope-from <Ian.Jackson@eu.citrix.com>) id 1R8wXC-00011W-59; Wed, 28 Sep 2011 16:58:58 +0100 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Message-ID: <20099.17474.151701.31680@mariner.uk.xensource.com> Date: Wed, 28 Sep 2011 16:58:58 +0100 To: <stefano.stabellini@eu.citrix.com> Subject: Re: [Xen-devel] [PATCH v6 2/5] Rename ioemu-dir as qemu-xen-traditional-dir Newsgroups: chiark.mail.xen.devel In-Reply-To: <1316779878-10950-2-git-send-email-stefano.stabellini@eu.citrix.com> References: <alpine.DEB.2.00.1109231302370.8700@kaball-desktop> <1316779878-10950-2-git-send-email-stefano.stabellini@eu.citrix.com> X-Mailer: VM 8.0.9 under Emacs 21.4.1 (i486-pc-linux-gnu) From: Ian Jackson <Ian.Jackson@eu.citrix.com> Cc: Ian.Campbell@eu.citrix.com, xen-devel@lists.xensource.com, keir@xen.org X-BeenThere: xen-devel@lists.xensource.com X-Mailman-Version: 2.1.5 Precedence: list List-Id: Xen developer discussion <xen-devel.lists.xensource.com> List-Unsubscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe> List-Post: <mailto:xen-devel@lists.xensource.com> List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help> List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=subscribe> Sender: xen-devel-bounces@lists.xensource.com Errors-To: xen-devel-bounces@lists.xensource.com stefano.stabellini@eu.citrix.com writes ("[Xen-devel] [PATCH v6 2/5] Rename ioemu-dir as qemu-xen-traditional-dir"): > Signed-off-by: Stefano Stabellini <stefano.stabellini@eu.citrix.com> Why ? I'm generally not in favour of renaming things in build trees unless essential. Particularly, this whole machinery is very fragile and this will break existing working trees. Ian. _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel From xen-devel-bounces@lists.xensource.com Wed Sep 28 09:05:16 2011 Return-path: <xen-devel-bounces@lists.xensource.com> Envelope-to: www-data@lists.xensource.com Delivery-date: Wed, 28 Sep 2011 09:05:16 -0700 Received: from localhost ([127.0.0.1] helo=lists.colo.xensource.com) by lists.xensource.com with esmtp (Exim 4.43) id 1R8wdH-0000S1-5F; Wed, 28 Sep 2011 09:05:15 -0700 Received: from mail27.messagelabs.com ([193.109.254.147]) by lists.xensource.com with esmtp (Exim 4.43) id 1R8wYM-00081Z-IQ for xen-devel@lists.xensource.com; Wed, 28 Sep 2011 09:00:15 -0700 X-Env-Sender: Ian.Campbell@eu.citrix.com X-Msg-Ref: server-6.tower-27.messagelabs.com!1317225586!50867662!1 X-Originating-IP: [62.200.22.115] X-StarScan-Version: 6.4.1; banners=-,-,- X-VirusChecked: Checked Received: (qmail 24768 invoked from network); 28 Sep 2011 15:59:47 -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; 28 Sep 2011 15:59:47 -0000 X-IronPort-AV: E=Sophos;i="4.68,456,1312156800"; d="scan'208";a="8110010" Received: from lonpmailmx01.citrite.net ([10.30.203.162]) by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5; 28 Sep 2011 16:00:07 +0000 Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net (10.30.203.162) with Microsoft SMTP Server id 8.3.137.0; Wed, 28 Sep 2011 17:00:07 +0100 Subject: Re: [Xen-devel] [PATCH v6 2/5] Rename ioemu-dir as qemu-xen-traditional-dir From: Ian Campbell <Ian.Campbell@eu.citrix.com> To: Ian Jackson <Ian.Jackson@eu.citrix.com> Date: Wed, 28 Sep 2011 17:00:07 +0100 In-Reply-To: <20099.17474.151701.31680@mariner.uk.xensource.com> References: <alpine.DEB.2.00.1109231302370.8700@kaball-desktop> <1316779878-10950-2-git-send-email-stefano.stabellini@eu.citrix.com> <20099.17474.151701.31680@mariner.uk.xensource.com> Organization: Citrix Systems, Inc. Content-Type: text/plain; charset="UTF-8" X-Mailer: Evolution 3.0.3- Content-Transfer-Encoding: 7bit Message-ID: <1317225607.26672.88.camel@zakaz.uk.xensource.com> MIME-Version: 1.0 Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>, "keir@xen.org" <keir@xen.org>, Stefano Stabellini <Stefano.Stabellini@eu.citrix.com> X-BeenThere: xen-devel@lists.xensource.com X-Mailman-Version: 2.1.5 Precedence: list List-Id: Xen developer discussion <xen-devel.lists.xensource.com> List-Unsubscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe> List-Post: <mailto:xen-devel@lists.xensource.com> List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help> List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=subscribe> Sender: xen-devel-bounces@lists.xensource.com Errors-To: xen-devel-bounces@lists.xensource.com On Wed, 2011-09-28 at 16:58 +0100, Ian Jackson wrote: > stefano.stabellini@eu.citrix.com writes ("[Xen-devel] [PATCH v6 2/5] Rename ioemu-dir as qemu-xen-traditional-dir"): > > Signed-off-by: Stefano Stabellini <stefano.stabellini@eu.citrix.com> > > Why ? I'm generally not in favour of renaming things in build trees > unless essential. Particularly, this whole machinery is very fragile > and this will break existing working trees. I suggested this just to be consistent in our terminology throughout the guest config files, libxl, the build etc. It's not a big deal though. Ian. _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel From xen-devel-bounces@lists.xensource.com Wed Sep 28 09:08:01 2011 Return-path: <xen-devel-bounces@lists.xensource.com> Envelope-to: www-data@lists.xensource.com Delivery-date: Wed, 28 Sep 2011 09:08:01 -0700 Received: from localhost ([127.0.0.1] helo=lists.colo.xensource.com) by lists.xensource.com with esmtp (Exim 4.43) id 1R8wfw-0000ql-EN; Wed, 28 Sep 2011 09:08:00 -0700 Received: from mail174.messagelabs.com ([85.158.138.51]) by lists.xensource.com with esmtp (Exim 4.43) id 1R8wZZ-0008Ak-Ew for xen-devel@lists.xensource.com; Wed, 28 Sep 2011 09:01:27 -0700 X-Env-Sender: Ian.Jackson@eu.citrix.com X-Msg-Ref: server-6.tower-174.messagelabs.com!1317225682!30974657!1 X-Originating-IP: [62.200.22.115] X-StarScan-Version: 6.4.1; banners=-,-,- X-VirusChecked: Checked Received: (qmail 14208 invoked from network); 28 Sep 2011 16:01:22 -0000 Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115) by server-6.tower-174.messagelabs.com with RC4-SHA encrypted SMTP; 28 Sep 2011 16:01:22 -0000 X-IronPort-AV: E=Sophos;i="4.68,456,1312156800"; d="scan'208";a="8110030" Received: from lonpmailmx01.citrite.net ([10.30.203.162]) by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5; 28 Sep 2011 16:00:45 +0000 Received: from norwich.cam.xci-test.com (10.80.248.129) by smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id 8.3.137.0; Wed, 28 Sep 2011 17:00:45 +0100 Received: from mariner.cam.xci-test.com ([10.80.2.22] helo=mariner.uk.xensource.com ident=Debian-exim) by norwich.cam.xci-test.com with esmtp (Exim 4.72) (envelope-from <Ian.Jackson@eu.citrix.com>) id 1R8wYv-0002oE-1Y; Wed, 28 Sep 2011 16:00:45 +0000 Received: from iwj by mariner.uk.xensource.com with local (Exim 4.69) (envelope-from <Ian.Jackson@eu.citrix.com>) id 1R8wYv-00011m-0h; Wed, 28 Sep 2011 17:00:45 +0100 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Message-ID: <20099.17581.13612.775160@mariner.uk.xensource.com> Date: Wed, 28 Sep 2011 17:00:45 +0100 To: <stefano.stabellini@eu.citrix.com> Subject: Re: [Xen-devel] [PATCH v6 3/5] Clone and build upstream Qemu by default Newsgroups: chiark.mail.xen.devel In-Reply-To: <1316779878-10950-3-git-send-email-stefano.stabellini@eu.citrix.com> References: <alpine.DEB.2.00.1109231302370.8700@kaball-desktop> <1316779878-10950-3-git-send-email-stefano.stabellini@eu.citrix.com> X-Mailer: VM 8.0.9 under Emacs 21.4.1 (i486-pc-linux-gnu) From: Ian Jackson <Ian.Jackson@eu.citrix.com> Cc: Ian.Campbell@eu.citrix.com, keir@xen.org, xen-devel@lists.xensource.com, Ian.Jackson@eu.citrix.com X-BeenThere: xen-devel@lists.xensource.com X-Mailman-Version: 2.1.5 Precedence: list List-Id: Xen developer discussion <xen-devel.lists.xensource.com> List-Unsubscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe> List-Post: <mailto:xen-devel@lists.xensource.com> List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help> List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=subscribe> Sender: xen-devel-bounces@lists.xensource.com Errors-To: xen-devel-bounces@lists.xensource.com stefano.stabellini@eu.citrix.com writes ("[Xen-devel] [PATCH v6 3/5] Clone and build upstream Qemu by default"): > +qemu-xen-dir-find: > + if test -d $(QEMU_UPSTREAM_URL) ; then \ > + ln -sf $(QEMU_UPSTREAM_URL) qemu-xen-dir; \ > + else \ > + export GIT=$(GIT); \ > + $(XEN_ROOT)/scripts/git-checkout.sh $(QEMU_UPSTREAM_URL) $(QEMU_UPSTREAM_TAG) qemu-xen-dir ; \ > + fi > + cd qemu-xen-dir; \ > + ./configure --enable-xen --target-list=i386-softmmu \ > + --source-path=$$ROOT \ > + --extra-cflags="-I$(XEN_ROOT)/tools/include \ > + -I$(XEN_ROOT)/tools/libxc \ > + -I$(XEN_ROOT)/tools/xenstore" \ > + --extra-ldflags="-L$(XEN_ROOT)/tools/libxc \ > + -L$(XEN_ROOT)/tools/libxenstore" \ > + --bindir=$(LIBEXEC) \ > + --disable-kvm \ > + $(IOEMU_CONFIGURE_CROSS) This looks OK in principle although of course I would like to test it. Ian. _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel From xen-devel-bounces@lists.xensource.com Wed Sep 28 09:09:51 2011 Return-path: <xen-devel-bounces@lists.xensource.com> Envelope-to: www-data@lists.xensource.com Delivery-date: Wed, 28 Sep 2011 09:09:51 -0700 Received: from localhost ([127.0.0.1] helo=lists.colo.xensource.com) by lists.xensource.com with esmtp (Exim 4.43) id 1R8whi-0001En-VG; Wed, 28 Sep 2011 09:09:50 -0700 Received: from mail174.messagelabs.com ([85.158.138.51]) by lists.xensource.com with esmtp (Exim 4.43) id 1R8wZs-0008Dv-4L for xen-devel@lists.xensource.com; Wed, 28 Sep 2011 09:01:44 -0700 X-Env-Sender: Ian.Jackson@eu.citrix.com X-Msg-Ref: server-7.tower-174.messagelabs.com!1317225700!33096463!1 X-Originating-IP: [62.200.22.115] X-StarScan-Version: 6.4.1; banners=-,-,- X-VirusChecked: Checked Received: (qmail 24490 invoked from network); 28 Sep 2011 16:01:41 -0000 Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115) by server-7.tower-174.messagelabs.com with RC4-SHA encrypted SMTP; 28 Sep 2011 16:01:41 -0000 X-IronPort-AV: E=Sophos;i="4.68,456,1312156800"; d="scan'208";a="8110067" Received: from lonpmailmx01.citrite.net ([10.30.203.162]) by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5; 28 Sep 2011 16:01:33 +0000 Received: from norwich.cam.xci-test.com (10.80.248.129) by smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id 8.3.137.0; Wed, 28 Sep 2011 17:01:33 +0100 Received: from mariner.cam.xci-test.com ([10.80.2.22] helo=mariner.uk.xensource.com ident=Debian-exim) by norwich.cam.xci-test.com with esmtp (Exim 4.72) (envelope-from <Ian.Jackson@eu.citrix.com>) id 1R8wZg-0002oT-RM; Wed, 28 Sep 2011 16:01:32 +0000 Received: from iwj by mariner.uk.xensource.com with local (Exim 4.69) (envelope-from <Ian.Jackson@eu.citrix.com>) id 1R8wZg-000124-Nz; Wed, 28 Sep 2011 17:01:32 +0100 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Message-ID: <20099.17628.708746.746070@mariner.uk.xensource.com> Date: Wed, 28 Sep 2011 17:01:32 +0100 To: <stefano.stabellini@eu.citrix.com> Subject: Re: [Xen-devel] [PATCH v6 4/5] Clone and build Seabios by default Newsgroups: chiark.mail.xen.devel In-Reply-To: <1316779878-10950-4-git-send-email-stefano.stabellini@eu.citrix.com> References: <alpine.DEB.2.00.1109231302370.8700@kaball-desktop> <1316779878-10950-4-git-send-email-stefano.stabellini@eu.citrix.com> X-Mailer: VM 8.0.9 under Emacs 21.4.1 (i486-pc-linux-gnu) From: Ian Jackson <Ian.Jackson@eu.citrix.com> Cc: Ian.Campbell@eu.citrix.com, xen-devel@lists.xensource.com, keir@xen.org X-BeenThere: xen-devel@lists.xensource.com X-Mailman-Version: 2.1.5 Precedence: list List-Id: Xen developer discussion <xen-devel.lists.xensource.com> List-Unsubscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe> List-Post: <mailto:xen-devel@lists.xensource.com> List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help> List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=subscribe> Sender: xen-devel-bounces@lists.xensource.com Errors-To: xen-devel-bounces@lists.xensource.com stefano.stabellini@eu.citrix.com writes ("[Xen-devel] [PATCH v6 4/5] Clone and build Seabios by default"): > Signed-off-by: Stefano Stabellini <stefano.stabellini@eu.citrix.com> Likewise, this one is OK I think provided we fix up my comments on earlier patches, and it tests OK (which I will do). Ian. _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel From xen-devel-bounces@lists.xensource.com Wed Sep 28 09:11:35 2011 Return-path: <xen-devel-bounces@lists.xensource.com> Envelope-to: www-data@lists.xensource.com Delivery-date: Wed, 28 Sep 2011 09:11:36 -0700 Received: from localhost ([127.0.0.1] helo=lists.colo.xensource.com) by lists.xensource.com with esmtp (Exim 4.43) id 1R8wjO-0001cX-Qa; Wed, 28 Sep 2011 09:11:34 -0700 Received: from mail27.messagelabs.com ([193.109.254.147]) by lists.xensource.com with smtp (Exim 4.43) id 1R8wak-0008Mq-Jc for xen-devel@lists.xensource.com; Wed, 28 Sep 2011 09:02:40 -0700 X-Env-Sender: caker@theshore.net X-Msg-Ref: server-4.tower-27.messagelabs.com!1317225736!42152144!1 X-Originating-IP: [67.18.92.50] X-StarScan-Version: 6.4.1; banners=-,-,- X-VirusChecked: Checked Received: (qmail 4562 invoked from network); 28 Sep 2011 16:02:16 -0000 Received: from ns.theshore.net (HELO www.theshore.net) (67.18.92.50) by server-4.tower-27.messagelabs.com with SMTP; 28 Sep 2011 16:02:16 -0000 Received: from beefcake.linlan (173-161-199-49-Philadelphia.hfc.comcastbusiness.net [173.161.199.49]) by www.theshore.net (8.13.6/8.9.1) with ESMTP id p8SG2Xsd008945; Wed, 28 Sep 2011 12:02:34 -0400 Message-ID: <4E834519.3090300@theshore.net> Date: Wed, 28 Sep 2011 12:02:33 -0400 From: "Christopher S. Aker" <caker@theshore.net> User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.6; en-US; rv:1.9.2.22) Gecko/20110902 Lightning/1.0b2 Thunderbird/3.1.14 MIME-Version: 1.0 To: David Vrabel <david.vrabel@citrix.com> Subject: Re: [Xen-devel] vmalloc_sync_all() patch problems? References: <4E832F1A.3030209@theshore.net> <4E83330A.3030509@citrix.com> In-Reply-To: <4E83330A.3030509@citrix.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: xen devel <xen-devel@lists.xensource.com> X-BeenThere: xen-devel@lists.xensource.com X-Mailman-Version: 2.1.5 Precedence: list List-Id: Xen developer discussion <xen-devel.lists.xensource.com> List-Unsubscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe> List-Post: <mailto:xen-devel@lists.xensource.com> List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help> List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=subscribe> Sender: xen-devel-bounces@lists.xensource.com Errors-To: xen-devel-bounces@lists.xensource.com On 9/28/11 10:45 AM, David Vrabel wrote: > You're going to have to provide more information on your system and > tests I think. Nothing crazy. 64 bit Xen, 32 bit dom0, my test suite creates many domUs (in this case about 40) each with a root image and swap image. Some swap thrash, some spin cpu, some are repeatedly shut down or xm destroyed. No networking. This particular box has about 32G in it, and itself and many other boxes identical to it have no problem with our old stack (xen 3.4, 2.6.18 dom0). I've restarted the tests to see if I can reproduce, but I'm certain that if it happened once, it'll happen again. Can I provide anything else? -Chris _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel From xen-devel-bounces@lists.xensource.com Wed Sep 28 09:13:24 2011 Return-path: <xen-devel-bounces@lists.xensource.com> Envelope-to: www-data@lists.xensource.com Delivery-date: Wed, 28 Sep 2011 09:13:24 -0700 Received: from localhost ([127.0.0.1] helo=lists.colo.xensource.com) by lists.xensource.com with esmtp (Exim 4.43) id 1R8wl7-00020e-UH; Wed, 28 Sep 2011 09:13:22 -0700 Received: from mail182.messagelabs.com ([85.158.139.83]) by lists.xensource.com with smtp (Exim 4.43) id 1R8wfN-0000kj-HK for xen-devel@lists.xensource.com; Wed, 28 Sep 2011 09:07:26 -0700 X-Env-Sender: anthony@overnetdata.com X-Msg-Ref: server-13.tower-182.messagelabs.com!1317226042!19956015!1 X-Originating-IP: [81.137.131.225] X-StarScan-Version: 6.4.1; banners=-,-,- X-VirusChecked: Checked Received: (qmail 1419 invoked from network); 28 Sep 2011 16:07:22 -0000 Received: from host81-137-131-225.in-addr.btopenworld.com (HELO zimbra.overnetdata.com) (81.137.131.225) by server-13.tower-182.messagelabs.com with SMTP; 28 Sep 2011 16:07:22 -0000 Received: from localhost (localhost.localdomain [127.0.0.1]) by zimbra.overnetdata.com (Postfix) with ESMTP id 141261619F7; Wed, 28 Sep 2011 17:07:12 +0100 (BST) X-Virus-Scanned: amavisd-new at overnetdata.com Received: from zimbra.overnetdata.com ([127.0.0.1]) by localhost (zimbra.overnetdata.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id uwtcrfAVdDAY; Wed, 28 Sep 2011 17:07:11 +0100 (BST) Received: from [192.168.1.60] (unknown [192.168.1.60]) by zimbra.overnetdata.com (Postfix) with ESMTPSA id 3FDF71616E5; Wed, 28 Sep 2011 17:07:11 +0100 (BST) Message-ID: <4E83462B.9080002@overnetdata.com> Date: Wed, 28 Sep 2011 17:07:07 +0100 From: Anthony Wright <anthony@overnetdata.com> User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:6.0.2) Gecko/20110902 Thunderbird/6.0.2 MIME-Version: 1.0 To: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com> Subject: Re: [Xen-devel] dmidecode doesn't work under xen 4.1.1 on certain hardware References: <4E7C6BDC.8070005@overnetdata.com> <20110923133200.GC19579@phenom.oracle.com> <4E7C9C8B.2010108@overnetdata.com> <20110926141322.GD4102@phenom.oracle.com> <4E8090D4.2090009@overnetdata.com> <20110926193732.GA10007@phenom.oracle.com> <4E82E429.2080600@overnetdata.com> <20110928132815.GE10270@phenom.oracle.com> In-Reply-To: <20110928132815.GE10270@phenom.oracle.com> X-Enigmail-Version: 1.3.2 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com> X-BeenThere: xen-devel@lists.xensource.com X-Mailman-Version: 2.1.5 Precedence: list List-Id: Xen developer discussion <xen-devel.lists.xensource.com> List-Unsubscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe> List-Post: <mailto:xen-devel@lists.xensource.com> List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help> List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=subscribe> Sender: xen-devel-bounces@lists.xensource.com Errors-To: xen-devel-bounces@lists.xensource.com On 28/09/2011 14:28, Konrad Rzeszutek Wilk wrote: >>>> (XEN) WARNING: Only the first 16 GB of the physical memory map can be accessed by Xen in 32-bit mode. >>> That bites ^^^^ >>>> (XEN) Truncating RAM from 17825792kB to 16777216kB >> Does this mean that 32 bit Xen can only use a maximum of 16GB of RAM? >> >> If so, is there a way to use 32 bit Xen tools with a 64 bit Xen hypervisor? > Yes. I've been doing that without any trouble. I tried to get this so work some time ago and failed. Do I need a 64 bit Dom0 kernel with a 64 bit xen hypervisor or can I get away with a 32 bit Dom0 kernel? >> The patch works perfectly. I've attached a copy of the kernel log with >> 'debug loglevel=8' > Yeeey! Great. Thanks for testing it. We are re-doing that whole E820 parsing > for the next version of Linux (3.2) so will integrate the "essence" of that > patch. > > Would you be up for testing a different variant of that patch just to make > sure? Not a problem, ship me the patch when you're ready. I'm running 3.0.4 at the moment and would prefer to stick with 3.0.x for now, so hope that won't be a problem. _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel From xen-devel-bounces@lists.xensource.com Wed Sep 28 09:16:32 2011 Return-path: <xen-devel-bounces@lists.xensource.com> Envelope-to: www-data@lists.xensource.com Delivery-date: Wed, 28 Sep 2011 09:16:32 -0700 Received: from localhost ([127.0.0.1] helo=lists.colo.xensource.com) by lists.xensource.com with esmtp (Exim 4.43) id 1R8woB-0002Q6-Mi; Wed, 28 Sep 2011 09:16:31 -0700 Received: from mail21.messagelabs.com ([85.158.143.35]) by lists.xensource.com with esmtp (Exim 4.43) id 1R8wh6-00017v-Bp; Wed, 28 Sep 2011 09:09:27 -0700 X-Env-Sender: rshriram@cs.ubc.ca X-Msg-Ref: server-12.tower-21.messagelabs.com!1317226130!51703636!1 X-Originating-IP: [142.103.6.52] X-StarScan-Version: 6.4.1; banners=-,-,- X-VirusChecked: Checked Received: (qmail 3328 invoked from network); 28 Sep 2011 16:08:52 -0000 Received: from smtp.cs.ubc.ca (HELO smtp.cs.ubc.ca) (142.103.6.52) by server-12.tower-21.messagelabs.com with DHE-RSA-AES256-SHA encrypted SMTP; 28 Sep 2011 16:08:52 -0000 Received: from mail-bw0-f43.google.com (mail-bw0-f43.google.com [209.85.214.43]) (authenticated bits=0) by smtp.cs.ubc.ca (8.14.3/8.13.6) with ESMTP id p8SG91n0006921 (version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=FAIL); Wed, 28 Sep 2011 09:09:02 -0700 Received: by bkas6 with SMTP id s6so10973569bka.30 for <multiple recipients>; Wed, 28 Sep 2011 09:09:00 -0700 (PDT) Received: by 10.204.132.9 with SMTP id z9mr6167987bks.333.1317226140099; Wed, 28 Sep 2011 09:09:00 -0700 (PDT) MIME-Version: 1.0 Received: by 10.204.227.2 with HTTP; Wed, 28 Sep 2011 09:08:20 -0700 (PDT) In-Reply-To: <CAO14VsMXGyNjbgF0PiJ5MLH_HGwMA6M8yN0Z3Vq5e7tE-tW1bw@mail.gmail.com> References: <CAO14VsP9by7CYgSiVN-hY0rJpDk0MYjuJ+FD5Tp3i8w+BcNYHw@mail.gmail.com> <4E8024E5.9020406@citrix.com> <CAO14VsMXGyNjbgF0PiJ5MLH_HGwMA6M8yN0Z3Vq5e7tE-tW1bw@mail.gmail.com> From: Shriram Rajagopalan <rshriram@cs.ubc.ca> Date: Wed, 28 Sep 2011 09:08:20 -0700 Message-ID: <CAP8mzPOOkZ2iUzKkMCC7T+TExPL6osoANQnw1tUREeE=Jx-_BQ@mail.gmail.com> Subject: Re: [Xen-devel] Re: [Xen-API] FT for XCP To: R J <torushikeshj@gmail.com> Cc: Mike McClurg <mike.mcclurg@citrix.com>, "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>, "xen-users@lists.xensource.com" <xen-users@lists.xensource.com>, "xen-api@lists.xensource.com" <xen-api@lists.xensource.com> X-BeenThere: xen-devel@lists.xensource.com X-Mailman-Version: 2.1.5 Precedence: list Reply-To: rshriram@cs.ubc.ca List-Id: Xen developer discussion <xen-devel.lists.xensource.com> List-Unsubscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe> List-Post: <mailto:xen-devel@lists.xensource.com> List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help> List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=subscribe> Content-Type: multipart/mixed; boundary="===============1513702385==" Sender: xen-devel-bounces@lists.xensource.com Errors-To: xen-devel-bounces@lists.xensource.com --===============1513702385== Content-Type: multipart/alternative; boundary=00151744836a2b65c204ae029cd0 --00151744836a2b65c204ae029cd0 Content-Type: text/plain; charset=ISO-8859-1 On Mon, Sep 26, 2011 at 8:58 AM, R J <torushikeshj@gmail.com> wrote: > Hello Mike, > > Thank you for suggestion. I would love to incorporate remus in xapi if > thats possible. > Great. That would be certainly welcome. [I am not a fan of ocaml ;)] Remus as its inbuilt logic of detecting checkpoint failure and taking > decisions accordingly. > > I think there is remus support for xen 3.4 > > What matters is the toolstack. a. I am not sure if the xe toolstack uses libxenguest (tools/libxc) and if it does, then it should have the basic remus support already. b. I am also not sure if it is recent enough to include all the remus bug fixes that went in over the last 6 months. What do you suggest as my next step ? > > Most of the remus code is python based and completely self contained. It just needs the domU's info (disk paths & vifs) as an s-expression. There is only one api call to Xend- to obtain the domU's s-expression. 1. A quick and dirty way would be to change this single api call to xapi equivalent and obtain the s-expression, then you should have Remus running. 2. Another approach would be to re-write the toolstack code in ocaml - which might be easy. But make sure that ocaml can make netlink api calls. shriram > Regards, > Rushikesh > > > > > On Mon, Sep 26, 2011 at 12:38 PM, Mike McClurg <mike.mcclurg@citrix.com>wrote: > >> On 09/25/2011 09:11 PM, R J wrote: >> >> Hello List, >> >> I have a proposal and wont mind to implement my self but need a helping >> hand to start on. >> I want to implement the aggressive FT feature in XCP. The best way I could >> imagine is the use of feature *Live Migration* >> >> Steps >> 1. Enable the FT of a particular VM using xe commands and adding as a >> param to that VM e.g. xe vm-param-set FT=true uuid=XYZ >> 2. If the FT = true detected by xenstore then xapi will initiate a live >> migrate of that VM to any of available host. >> 3. A parallel "network ping"/"xapi heartbit" from/to that host could be >> initialized for each FT VM. >> 4. Live migrate will run forever until its disabled by FT = false or one >> of the host is down. e.g. the process will loop at 99.99% migration state >> 5. If there is a packet drop of x packets the VM Migrate procedure will >> mark the VM Migration as Complete and will switch the devices forcefully. >> -- this could result in some data loss but I dont have any alternative to >> this. >> -- The specific x packets can be set by XCP but we cant rely for default >> XCP Errors >> 6. If there is a successful migration due to host down then we will again >> start from step2 >> >> Above steps I have assumed to my knowledge, we can discuss the problems in >> it. >> >> Apologies if I'm being too naive. >> >> Regards, >> Rushikesh >> >> This sounds like Remus (http://nss.cs.ubc.ca/remus/). Are you proposing >> to implement Remus support in xapi? >> >> Mike >> > > > _______________________________________________ > Xen-devel mailing list > Xen-devel@lists.xensource.com > http://lists.xensource.com/xen-devel > > --00151744836a2b65c204ae029cd0 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable <br><br><div class=3D"gmail_quote">On Mon, Sep 26, 2011 at 8:58 AM, R J <sp= an dir=3D"ltr"><<a href=3D"mailto:torushikeshj@gmail.com">torushikeshj@g= mail.com</a>></span> wrote:<br><blockquote class=3D"gmail_quote" style= =3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;"> Hello Mike,<br><br>Thank you for suggestion. I would love to incorporate re= mus in xapi if thats possible.<br></blockquote><div><br>Great. That would b= e certainly welcome. [I am not a fan of ocaml ;)]<br><br></div><blockquote = class=3D"gmail_quote" style=3D"margin: 0pt 0pt 0pt 0.8ex; border-left: 1px = solid rgb(204, 204, 204); padding-left: 1ex;"> Remus as its inbuilt logic of detecting checkpoint failure and taking decis= ions accordingly.<br><br>I think there is remus support for xen 3.4<br> <br></blockquote><div><br>What matters is the toolstack. <br>a. I am not su= re if the xe toolstack uses libxenguest (tools/libxc) and <br>=A0if it does= , then it should have the basic remus support already. <br><br>b. I am also= not sure if it is recent enough to include all the remus bug <br> fixes that went in over the last 6 months.<br><br></div><blockquote class= =3D"gmail_quote" style=3D"margin: 0pt 0pt 0pt 0.8ex; border-left: 1px solid= rgb(204, 204, 204); padding-left: 1ex;">What do you suggest as my next ste= p ?<br> <br></blockquote><div><br>Most of the remus code is python based and comple= tely self contained. It just needs <br>the domU's info (disk paths &= ; vifs) as an s-expression. There is only one api call to <br>Xend- to obta= in the domU's s-expression. <br> <br>1. A quick and dirty way would be to change this single api call to xap= i equivalent <br>and obtain the s-expression, then you should have Remus ru= nning.<br><br>2. Another approach would be to re-write the toolstack code i= n ocaml - which might<br> be easy. But make sure that ocaml can make netlink api calls.<br><br>shrira= m<br></div><blockquote class=3D"gmail_quote" style=3D"margin: 0pt 0pt 0pt 0= .8ex; border-left: 1px solid rgb(204, 204, 204); padding-left: 1ex;">Regard= s,<br> Rushikesh<div><div></div><div class=3D"h5"><br><br><br><br><div class=3D"gm= ail_quote">On Mon, Sep 26, 2011 at 12:38 PM, Mike McClurg <span dir=3D"ltr"= ><<a href=3D"mailto:mike.mcclurg@citrix.com" target=3D"_blank">mike.mccl= urg@citrix.com</a>></span> wrote:<br> <blockquote class=3D"gmail_quote" style=3D"margin:0pt 0pt 0pt 0.8ex;border-= left:1px solid rgb(204, 204, 204);padding-left:1ex"> =20 =20 =20 <div bgcolor=3D"#FFFFFF" text=3D"#000000"><div><div></div><div> On 09/25/2011 09:11 PM, R J wrote: <blockquote type=3D"cite">Hello List,<br> <br> I have a proposal and wont mind to implement my self but need a helping hand to start on.<br> I want to implement the aggressive FT feature in XCP. The best way I could imagine is the use of feature *Live Migration*<br> <br> Steps<br> 1. Enable the FT of a particular VM using xe commands and adding as a param to that VM e.g. xe vm-param-set FT=3Dtrue uuid=3DXYZ<br> 2. If the FT =3D true detected by xenstore then xapi will initiate a live migrate of that VM to any of available host.<br> 3. A parallel "network ping"/"xapi heartbit" from= /to that host could be initialized for each FT VM.<br> 4. Live migrate will run forever until its disabled by FT =3D false or one of the host is down. e.g. the process will loop at 99.99% migration state<br> 5. If there is a packet drop of x packets the VM Migrate procedure will mark the VM Migration as Complete and will switch the devices forcefully.<br> -- this could result in some data loss but I dont have any alternative to this.<br> -- The specific x packets can be set by XCP but we cant rely for default XCP Errors<br> 6. If there is a successful migration due to host down then we will again start from step2<br> <br> Above steps I have assumed to my knowledge, we can discuss the problems in it.<br> <br> Apologies if I'm being too naive.<br> <br> Regards,<br> Rushikesh<br> <br> </blockquote> </div></div><font size=3D"-1">This sounds like Remus (<a href=3D"http://nss.cs.ubc.ca/remus/" target=3D"_blank">http://nss= .cs.ubc.ca/remus/</a>). Are you proposing to implement Remus support in xapi?<br><font color=3D"#888888"> <br> Mike<br> </font></font> </div> </blockquote></div><br> </div></div><br>_______________________________________________<br> Xen-devel mailing list<br> <a href=3D"mailto:Xen-devel@lists.xensource.com">Xen-devel@lists.xensource.= com</a><br> <a href=3D"http://lists.xensource.com/xen-devel" target=3D"_blank">http://l= ists.xensource.com/xen-devel</a><br> <br></blockquote></div><br> --00151744836a2b65c204ae029cd0-- --===============1513702385== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel --===============1513702385==-- From xen-devel-bounces@lists.xensource.com Wed Sep 28 09:24:45 2011 Return-path: <xen-devel-bounces@lists.xensource.com> Envelope-to: www-data@lists.xensource.com Delivery-date: Wed, 28 Sep 2011 09:24:45 -0700 Received: from localhost ([127.0.0.1] helo=lists.colo.xensource.com) by lists.xensource.com with esmtp (Exim 4.43) id 1R8ww9-0003qD-0d; Wed, 28 Sep 2011 09:24:45 -0700 Received: from mail21.messagelabs.com ([85.158.143.35]) by lists.xensource.com with esmtp (Exim 4.43) id 1R8wj7-0001YZ-GR for xen-devel@lists.xensource.com; Wed, 28 Sep 2011 09:11:17 -0700 X-Env-Sender: linus971@gmail.com X-Msg-Ref: server-12.tower-21.messagelabs.com!1317226258!51703961!1 X-Originating-IP: [74.125.82.171] X-StarScan-Version: 6.4.1; banners=-,-,- X-VirusChecked: Checked Received: (qmail 8305 invoked from network); 28 Sep 2011 16:10:58 -0000 Received: from mail-wy0-f171.google.com (HELO mail-wy0-f171.google.com) (74.125.82.171) by server-12.tower-21.messagelabs.com with RC4-SHA encrypted SMTP; 28 Sep 2011 16:10:58 -0000 Received: by wyh13 with SMTP id 13so225365wyh.30 for <xen-devel@lists.xensource.com>; Wed, 28 Sep 2011 09:11:14 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:sender:in-reply-to:references:from:date :x-google-sender-auth:message-id:subject:to:cc:content-type; bh=0HMxFKTksWWzOHJz0qa3T0LMUT5cE0Ys7afFnWPptQ4=; b=JB9EdLAu29ixy3gsChVZw5NX4V+T3vn8L3JEytLOtK5bgZAHVyUncZiBx+alm6+aII Ll6XSqnuIiKPD1n/VcBYPsieamyPIydcUvXk4W0fTiqXFk07NoIpuUyX3JEKs6PiAm7G lgPWD7HBWFXaNCZuEVsOsfLKDVIrj34IPW75I= Received: by 10.216.182.197 with SMTP id o47mr10143944wem.78.1317226274140; Wed, 28 Sep 2011 09:11:14 -0700 (PDT) MIME-Version: 1.0 Received: by 10.216.11.12 with HTTP; Wed, 28 Sep 2011 09:10:54 -0700 (PDT) In-Reply-To: <4E835F8C0200007800058461@nat28.tlf.novell.com> References: <cover.1315878463.git.jeremy.fitzhardinge@citrix.com> <3300108.XQUp9Wrktc@chlor> <4E81FD52.50106@goop.org> <CA+55aFx7dv4C4ZB_3CFjdJmX_wpoxecpqo1ARYr1=zTVP=CVVA@mail.gmail.com> <4E835F8C0200007800058461@nat28.tlf.novell.com> From: Linus Torvalds <torvalds@linux-foundation.org> Date: Wed, 28 Sep 2011 09:10:54 -0700 X-Google-Sender-Auth: 15qd6EIGJGbtASGexJiuWoOHilU Message-ID: <CA+55aFyVoZpZZp7ejypTv21Cx_qJWkZQdpJOnxBa_jUxsCjhuw@mail.gmail.com> Subject: Re: [Xen-devel] [PATCH 00/10] [PATCH RFC V2] Paravirtualized ticketlocks To: Jan Beulich <JBeulich@suse.com> Content-Type: text/plain; charset=ISO-8859-1 Cc: Jeremy Fitzhardinge <jeremy@goop.org>, Jeremy Fitzhardinge <jeremy.fitzhardinge@citrix.com>, Nick Piggin <npiggin@kernel.dk>, KVM <kvm@vger.kernel.org>, Peter Zijlstra <peterz@infradead.org>, the arch/x86 maintainers <x86@kernel.org>, Linux Kernel Mailing List <linux-kernel@vger.kernel.org>, Marcelo Tosatti <mtosatti@redhat.com>, Andi Kleen <andi@firstfloor.org>, Avi Kivity <avi@redhat.com>, "H. Peter Anvin" <hpa@zytor.com>, Ingo Molnar <mingo@elte.hu>, xen-devel@lists.xensource.com, Stephan Diestelhorst <stephan.diestelhorst@amd.com> X-BeenThere: xen-devel@lists.xensource.com X-Mailman-Version: 2.1.5 Precedence: list List-Id: Xen developer discussion <xen-devel.lists.xensource.com> List-Unsubscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe> List-Post: <mailto:xen-devel@lists.xensource.com> List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help> List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=subscribe> Sender: xen-devel-bounces@lists.xensource.com Errors-To: xen-devel-bounces@lists.xensource.com On Wed, Sep 28, 2011 at 8:55 AM, Jan Beulich <JBeulich@suse.com> wrote: > >> just use "lock xaddw" there too. > > I'm afraid that's not possible, as that might carry from the low 8 bits > into the upper 8 ones, which must be avoided. Oh damn, you're right. So I guess the "right" way to do things is with cmpxchg, but some nasty mfence setup could do it too. Linus _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel From xen-devel-bounces@lists.xensource.com Wed Sep 28 09:25:48 2011 Return-path: <xen-devel-bounces@lists.xensource.com> Envelope-to: www-data@lists.xensource.com Delivery-date: Wed, 28 Sep 2011 09:25:48 -0700 Received: from localhost ([127.0.0.1] helo=lists.colo.xensource.com) by lists.xensource.com with esmtp (Exim 4.43) id 1R8wx9-0004D5-U6; Wed, 28 Sep 2011 09:25:47 -0700 Received: from mail182.messagelabs.com ([85.158.139.83]) by lists.xensource.com with esmtp (Exim 4.43) id 1R8wm5-0002AA-AB for xen-devel@lists.xensource.com; Wed, 28 Sep 2011 09:14:26 -0700 X-Env-Sender: Ian.Jackson@eu.citrix.com X-Msg-Ref: server-9.tower-182.messagelabs.com!1317226457!18287421!1 X-Originating-IP: [62.200.22.115] X-StarScan-Version: 6.4.1; banners=-,-,- X-VirusChecked: Checked Received: (qmail 2368 invoked from network); 28 Sep 2011 16:14:17 -0000 Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115) by server-9.tower-182.messagelabs.com with RC4-SHA encrypted SMTP; 28 Sep 2011 16:14:17 -0000 X-IronPort-AV: E=Sophos;i="4.68,456,1312156800"; d="scan'208";a="8110466" Received: from lonpmailmx01.citrite.net ([10.30.203.162]) by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5; 28 Sep 2011 16:14:17 +0000 Received: from norwich.cam.xci-test.com (10.80.248.129) by smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id 8.3.137.0; Wed, 28 Sep 2011 17:14:17 +0100 Received: from mariner.cam.xci-test.com ([10.80.2.22] helo=mariner.uk.xensource.com ident=Debian-exim) by norwich.cam.xci-test.com with esmtp (Exim 4.72) (envelope-from <Ian.Jackson@eu.citrix.com>) id 1R8wm1-0002rs-Ci; Wed, 28 Sep 2011 16:14:17 +0000 Received: from iwj by mariner.uk.xensource.com with local (Exim 4.69) (envelope-from <Ian.Jackson@eu.citrix.com>) id 1R8wm1-00013B-Bs; Wed, 28 Sep 2011 17:14:17 +0100 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Message-ID: <20099.18393.357286.395540@mariner.uk.xensource.com> Date: Wed, 28 Sep 2011 17:14:17 +0100 To: Olaf Hering <olaf@aepfle.de> Subject: Re: [Xen-devel] [PATCH 6 of 9] xenpaging: add evict_pages function Newsgroups: chiark.mail.xen.devel In-Reply-To: <20110915091723.GA18591@aepfle.de> References: <patchbomb.1316067388@probook.site> <3a3a5979b799d9488021.1316067394@probook.site> <1316074602.25935.4.camel@cthulhu.hellion.org.uk> <CAFLBxZaPWFSEj_apLtEn=CiZHiep0RMNd6iz_Ypc8Ep2X_Qjhw@mail.gmail.com> <20110915091723.GA18591@aepfle.de> X-Mailer: VM 8.0.9 under Emacs 21.4.1 (i486-pc-linux-gnu) From: Ian Jackson <Ian.Jackson@eu.citrix.com> Cc: George Dunlap <dunlapg@umich.edu>, "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>, Ian Campbell <Ian.Campbell@citrix.com> X-BeenThere: xen-devel@lists.xensource.com X-Mailman-Version: 2.1.5 Precedence: list List-Id: Xen developer discussion <xen-devel.lists.xensource.com> List-Unsubscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe> List-Post: <mailto:xen-devel@lists.xensource.com> List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help> List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=subscribe> Sender: xen-devel-bounces@lists.xensource.com Errors-To: xen-devel-bounces@lists.xensource.com Olaf Hering writes ("Re: [Xen-devel] [PATCH 6 of 9] xenpaging: add evict_pages function"): > On Thu, Sep 15, George Dunlap wrote: > > In any case, a more precise description seems like a better idea -- it > > looks like it takes an argument for the number of pages to evict; and > > it's not adding a new function, it's pulling existing code into a > > function. So, "Pull eviction loop into a function" would probably be > > a better description. > > Thanks to both of you, I will improve the description. Thanks. Just to be clear, I think I'm expecting a repost either of this patch, or perhaps of the whole series ? Ian C made a comment about combining two of your later patches, too. Thanks, Ian. _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel From xen-devel-bounces@lists.xensource.com Wed Sep 28 09:26:39 2011 Return-path: <xen-devel-bounces@lists.xensource.com> Envelope-to: www-data@lists.xensource.com Delivery-date: Wed, 28 Sep 2011 09:26:39 -0700 Received: from localhost ([127.0.0.1] helo=lists.colo.xensource.com) by lists.xensource.com with esmtp (Exim 4.43) id 1R8wxz-0004aF-4G; Wed, 28 Sep 2011 09:26:39 -0700 Received: from mail174.messagelabs.com ([85.158.138.51]) by lists.xensource.com with esmtp (Exim 4.43) id 1R8wql-0002qc-Gg for xen-devel@lists.xensource.com; Wed, 28 Sep 2011 09:19:13 -0700 X-Env-Sender: olaf@aepfle.de X-Msg-Ref: server-5.tower-174.messagelabs.com!1317226747!29421570!1 X-Originating-IP: [81.169.146.161] X-StarScan-Version: 6.4.1; banners=-,-,- X-VirusChecked: Checked Received: (qmail 30263 invoked from network); 28 Sep 2011 16:19:07 -0000 Received: from mo-p00-ob.rzone.de (HELO mo-p00-ob.rzone.de) (81.169.146.161) by server-5.tower-174.messagelabs.com with DHE-RSA-AES256-SHA encrypted SMTP; 28 Sep 2011 16:19:07 -0000 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; t=1317226747; l=827; s=domk; d=aepfle.de; h=In-Reply-To:Content-Type:MIME-Version:References:Subject:Cc:To:From: Date:X-RZG-CLASS-ID:X-RZG-AUTH; bh=80dX24l8HJriSiiaQjeInV1WMW8=; b=PC2Tc4YMwMpAuHJp+totIl3bQXpzWKKbDSDbf5u9CvBQe9mJ1TIMd2X+vYEqKJR6tHv C113WCISH/gMvRZGUPJBu/RtlKQmNIHevE7YQhpwmrQTkqw+l6IMGlvTpR7r9YwFghuQo JksK3u2RfGMNITbZCw16tRxigTsMXtP0shE= X-RZG-AUTH: :P2EQZWCpfu+qG7CngxMFH1J+zrwiavkK6tmQaLfmztM8TOFHjC0IFVc= X-RZG-CLASS-ID: mo00 Received: from probook.site (dslb-088-065-092-066.pools.arcor-ip.net [88.65.92.66]) by smtp.strato.de (jimi mo5) (RZmta 26.7) with (DHE-RSA-AES256-SHA encrypted) ESMTPA id Y01896n8SFw9M5 ; Wed, 28 Sep 2011 18:19:02 +0200 (MEST) Received: by probook.site (Postfix, from userid 1000) id 187FC18B65; Wed, 28 Sep 2011 18:19:01 +0200 (CEST) Date: Wed, 28 Sep 2011 18:19:01 +0200 From: Olaf Hering <olaf@aepfle.de> To: Ian Jackson <Ian.Jackson@eu.citrix.com> Subject: Re: [Xen-devel] [PATCH 6 of 9] xenpaging: add evict_pages function Message-ID: <20110928161901.GA6642@aepfle.de> References: <patchbomb.1316067388@probook.site> <3a3a5979b799d9488021.1316067394@probook.site> <1316074602.25935.4.camel@cthulhu.hellion.org.uk> <CAFLBxZaPWFSEj_apLtEn=CiZHiep0RMNd6iz_Ypc8Ep2X_Qjhw@mail.gmail.com> <20110915091723.GA18591@aepfle.de> <20099.18393.357286.395540@mariner.uk.xensource.com> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline In-Reply-To: <20099.18393.357286.395540@mariner.uk.xensource.com> User-Agent: Mutt/1.5.21.rev5535 (2011-07-01) Cc: George Dunlap <dunlapg@umich.edu>, "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>, Ian Campbell <Ian.Campbell@citrix.com> X-BeenThere: xen-devel@lists.xensource.com X-Mailman-Version: 2.1.5 Precedence: list List-Id: Xen developer discussion <xen-devel.lists.xensource.com> List-Unsubscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe> List-Post: <mailto:xen-devel@lists.xensource.com> List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help> List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=subscribe> Sender: xen-devel-bounces@lists.xensource.com Errors-To: xen-devel-bounces@lists.xensource.com On Wed, Sep 28, Ian Jackson wrote: > Olaf Hering writes ("Re: [Xen-devel] [PATCH 6 of 9] xenpaging: add evict_pages function"): > > On Thu, Sep 15, George Dunlap wrote: > > > In any case, a more precise description seems like a better idea -- it > > > looks like it takes an argument for the number of pages to evict; and > > > it's not adding a new function, it's pulling existing code into a > > > function. So, "Pull eviction loop into a function" would probably be > > > a better description. > > > > Thanks to both of you, I will improve the description. > > Thanks. Just to be clear, I think I'm expecting a repost either of > this patch, or perhaps of the whole series ? Ian C made a comment > about combining two of your later patches, too. Yes, I will post a new series, replacing this one. Olaf _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel From xen-devel-bounces@lists.xensource.com Wed Sep 28 09:33:58 2011 Return-path: <xen-devel-bounces@lists.xensource.com> Envelope-to: www-data@lists.xensource.com Delivery-date: Wed, 28 Sep 2011 09:33:58 -0700 Received: from localhost ([127.0.0.1] helo=lists.colo.xensource.com) by lists.xensource.com with esmtp (Exim 4.43) id 1R8x54-0006D3-I1; Wed, 28 Sep 2011 09:33:58 -0700 Received: from mail216.messagelabs.com ([85.158.143.99]) by lists.xensource.com with esmtp (Exim 4.43) id 1R8x4H-0005oR-OI for xen-devel@lists.xensource.com; Wed, 28 Sep 2011 09:33:10 -0700 X-Env-Sender: konrad@oracle.com X-Msg-Ref: server-3.tower-216.messagelabs.com!1317227585!18878682!1 X-Originating-IP: [141.146.126.227] X-StarScan-Version: 6.4.1; banners=-,-,- X-VirusChecked: Checked Received: (qmail 22634 invoked from network); 28 Sep 2011 16:33:06 -0000 Received: from acsinet15.oracle.com (HELO acsinet15.oracle.com) (141.146.126.227) by server-3.tower-216.messagelabs.com with DHE-RSA-AES256-SHA encrypted SMTP; 28 Sep 2011 16:33:06 -0000 Received: from acsinet21.oracle.com (acsinet21.oracle.com [141.146.126.237]) by acsinet15.oracle.com (Switch-3.4.4/Switch-3.4.4) with ESMTP id p8SGX3lJ005419 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Wed, 28 Sep 2011 16:33:04 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 p8SGX2nB023831 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 28 Sep 2011 16:33:02 GMT Received: from abhmt104.oracle.com (abhmt104.oracle.com [141.146.116.56]) by acsmt358.oracle.com (8.12.11.20060308/8.12.11) with ESMTP id p8SGWuEg000359; Wed, 28 Sep 2011 11:32:56 -0500 Received: from oracle.com (/207.172.105.198) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Wed, 28 Sep 2011 09:32:56 -0700 Received: by oracle.com (Postfix, from userid 1000) id 8965115AA; Wed, 28 Sep 2011 12:32:54 -0400 (EDT) Date: Wed, 28 Sep 2011 12:32:54 -0400 From: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com> To: Anthony Wright <anthony@overnetdata.com> Subject: Re: [Xen-devel] dmidecode doesn't work under xen 4.1.1 on certain hardware Message-ID: <20110928163254.GA16348@phenom.oracle.com> References: <4E7C6BDC.8070005@overnetdata.com> <20110923133200.GC19579@phenom.oracle.com> <4E7C9C8B.2010108@overnetdata.com> <20110926141322.GD4102@phenom.oracle.com> <4E8090D4.2090009@overnetdata.com> <20110926193732.GA10007@phenom.oracle.com> <4E82E429.2080600@overnetdata.com> <20110928132815.GE10270@phenom.oracle.com> <4E83462B.9080002@overnetdata.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <4E83462B.9080002@overnetdata.com> User-Agent: Mutt/1.5.21 (2010-09-15) X-Source-IP: acsinet21.oracle.com [141.146.126.237] X-Auth-Type: Internal IP X-CT-RefId: str=0001.0A090204.4E834C41.0003:SCFMA922111,ss=1,re=-4.000,fgs=0 Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com> X-BeenThere: xen-devel@lists.xensource.com X-Mailman-Version: 2.1.5 Precedence: list List-Id: Xen developer discussion <xen-devel.lists.xensource.com> List-Unsubscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe> List-Post: <mailto:xen-devel@lists.xensource.com> List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help> List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=subscribe> Sender: xen-devel-bounces@lists.xensource.com Errors-To: xen-devel-bounces@lists.xensource.com On Wed, Sep 28, 2011 at 05:07:07PM +0100, Anthony Wright wrote: > On 28/09/2011 14:28, Konrad Rzeszutek Wilk wrote: > >>>> (XEN) WARNING: Only the first 16 GB of the physical memory map can be accessed by Xen in 32-bit mode. > >>> That bites ^^^^ > >>>> (XEN) Truncating RAM from 17825792kB to 16777216kB > >> Does this mean that 32 bit Xen can only use a maximum of 16GB of RAM? > >> > >> If so, is there a way to use 32 bit Xen tools with a 64 bit Xen hypervisor? > > Yes. I've been doing that without any trouble. > I tried to get this so work some time ago and failed. Do I need a 64 bit > Dom0 kernel with a 64 bit xen hypervisor or can I get away with a 32 bit > Dom0 kernel? You can get away with a 32-bit dom0 kernel. > >> The patch works perfectly. I've attached a copy of the kernel log with > >> 'debug loglevel=8' > > Yeeey! Great. Thanks for testing it. We are re-doing that whole E820 parsing > > for the next version of Linux (3.2) so will integrate the "essence" of that > > patch. > > > > Would you be up for testing a different variant of that patch just to make > > sure? > Not a problem, ship me the patch when you're ready. I'm running 3.0.4 at > the moment and would prefer to stick with 3.0.x for now, so hope that > won't be a problem. Ok. Thx! _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel From xen-devel-bounces@lists.xensource.com Wed Sep 28 09:45:53 2011 Return-path: <xen-devel-bounces@lists.xensource.com> Envelope-to: www-data@lists.xensource.com Delivery-date: Wed, 28 Sep 2011 09:45:53 -0700 Received: from localhost ([127.0.0.1] helo=lists.colo.xensource.com) by lists.xensource.com with esmtp (Exim 4.43) id 1R8xGb-0006pl-Oq; Wed, 28 Sep 2011 09:45:53 -0700 Received: from mail21.messagelabs.com ([85.158.143.35]) by lists.xensource.com with esmtp (Exim 4.43) id 1R8xG8-0006dk-Jk for xen-devel@lists.xensource.com; Wed, 28 Sep 2011 09:45:24 -0700 X-Env-Sender: david.vrabel@citrix.com X-Msg-Ref: server-13.tower-21.messagelabs.com!1317228313!50693425!1 X-Originating-IP: [66.165.176.63] X-StarScan-Version: 6.4.1; banners=-,-,- X-VirusChecked: Checked Received: (qmail 10203 invoked from network); 28 Sep 2011 16:45:14 -0000 Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63) by server-13.tower-21.messagelabs.com with RC4-SHA encrypted SMTP; 28 Sep 2011 16:45:14 -0000 X-IronPort-AV: E=Sophos;i="4.68,456,1312171200"; d="scan'208";a="165007087" Received: from ftlpmailmx02.citrite.net ([10.13.107.66]) by FTLPIPO02.CITRIX.COM with ESMTP/TLS/RC4-MD5; 28 Sep 2011 12:45:19 -0400 Received: from smtp01.ad.xensource.com (10.219.128.104) by smtprelay.citrix.com (10.13.107.66) with Microsoft SMTP Server id 8.3.137.0; Wed, 28 Sep 2011 12:45:19 -0400 Received: from qabil.uk.xensource.com (qabil.uk.xensource.com [10.80.2.76]) by smtp01.ad.xensource.com (8.13.1/8.13.1) with ESMTP id p8SGjHv2022965; Wed, 28 Sep 2011 09:45:17 -0700 From: David Vrabel <david.vrabel@citrix.com> To: xen-devel@lists.xensource.com Date: Wed, 28 Sep 2011 17:46:31 +0100 Message-ID: <1317228396-8870-1-git-send-email-david.vrabel@citrix.com> X-Mailer: git-send-email 1.7.2.5 MIME-Version: 1.0 Content-Type: text/plain Cc: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com> Subject: [Xen-devel] [PATCH 0/5] xen: memory initialization/balloon fixes (#4) X-BeenThere: xen-devel@lists.xensource.com X-Mailman-Version: 2.1.5 Precedence: list List-Id: Xen developer discussion <xen-devel.lists.xensource.com> List-Unsubscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe> List-Post: <mailto:xen-devel@lists.xensource.com> List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help> List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=subscribe> Sender: xen-devel-bounces@lists.xensource.com Errors-To: xen-devel-bounces@lists.xensource.com This set of patches fixes some bugs in the memory initialization under Xen and in Xen's memory balloon driver. They can make 100s of MB of additional RAM available (depending on the system/configuration). Patch 1 is a bug fix and sould be queued for 3.1 and possibly queued for the 3.0 stable tree. Patch 2 is a minor cleanup in the balloon driver. Please queue for 3.2. Patches 3 & 4 increase the amount of low memory in 32 bit domains started with < 1 GiB of RAM. Please queue for 3.2 Patch 5 releases all pages in the initial allocation with PFNs that lie within a 1-1 mapping. This seems correct to me as I think that once the 1-1 mapping is set the MFN of the original page is lost so it's no longer accessible by the kernel (and it cannot be used by another domain). Changes since #3: - Dropped the two patches that have already been applied. - Fixed an endless loop on systems with non-page aligned RAM regions. - Updated "xen: release all pages within 1-1 p2m mappings" to handle adjacent non-RAM regions better (particularly ones less than a page) and to round them so partial pages are included in the 1:1 p2m map (this should fix the dmidecode problem on systems with a DMI table on a non-page boundary). David _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel From xen-devel-bounces@lists.xensource.com Wed Sep 28 09:46:46 2011 Return-path: <xen-devel-bounces@lists.xensource.com> Envelope-to: www-data@lists.xensource.com Delivery-date: Wed, 28 Sep 2011 09:46:46 -0700 Received: from localhost ([127.0.0.1] helo=lists.colo.xensource.com) by lists.xensource.com with esmtp (Exim 4.43) id 1R8xHR-0007CX-U3; Wed, 28 Sep 2011 09:46:45 -0700 Received: from mail21.messagelabs.com ([85.158.143.35]) by lists.xensource.com with esmtp (Exim 4.43) id 1R8xG9-0006dl-98 for xen-devel@lists.xensource.com; Wed, 28 Sep 2011 09:45:25 -0700 X-Env-Sender: david.vrabel@citrix.com X-Msg-Ref: server-13.tower-21.messagelabs.com!1317228313!50693425!2 X-Originating-IP: [66.165.176.63] X-StarScan-Version: 6.4.1; banners=-,-,- X-VirusChecked: Checked Received: (qmail 10218 invoked from network); 28 Sep 2011 16:45:15 -0000 Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63) by server-13.tower-21.messagelabs.com with RC4-SHA encrypted SMTP; 28 Sep 2011 16:45:15 -0000 X-IronPort-AV: E=Sophos;i="4.68,456,1312171200"; d="scan'208";a="165007091" Received: from ftlpmailmx02.citrite.net ([10.13.107.66]) by FTLPIPO02.CITRIX.COM with ESMTP/TLS/RC4-MD5; 28 Sep 2011 12:45:20 -0400 Received: from smtp01.ad.xensource.com (10.219.128.104) by smtprelay.citrix.com (10.13.107.66) with Microsoft SMTP Server id 8.3.137.0; Wed, 28 Sep 2011 12:45:20 -0400 Received: from qabil.uk.xensource.com (qabil.uk.xensource.com [10.80.2.76]) by smtp01.ad.xensource.com (8.13.1/8.13.1) with ESMTP id p8SGjHv3022965; Wed, 28 Sep 2011 09:45:19 -0700 From: David Vrabel <david.vrabel@citrix.com> To: xen-devel@lists.xensource.com Date: Wed, 28 Sep 2011 17:46:32 +0100 Message-ID: <1317228396-8870-2-git-send-email-david.vrabel@citrix.com> X-Mailer: git-send-email 1.7.2.5 In-Reply-To: <1317228396-8870-1-git-send-email-david.vrabel@citrix.com> References: <1317228396-8870-1-git-send-email-david.vrabel@citrix.com> MIME-Version: 1.0 Content-Type: text/plain Cc: David Vrabel <david.vrabel@citrix.com>, Konrad Rzeszutek Wilk <konrad.wilk@oracle.com> Subject: [Xen-devel] [PATCH 1/5] xen/balloon: account for pages released during memory setup X-BeenThere: xen-devel@lists.xensource.com X-Mailman-Version: 2.1.5 Precedence: list List-Id: Xen developer discussion <xen-devel.lists.xensource.com> List-Unsubscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe> List-Post: <mailto:xen-devel@lists.xensource.com> List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help> List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=subscribe> Sender: xen-devel-bounces@lists.xensource.com Errors-To: xen-devel-bounces@lists.xensource.com From: David Vrabel <david.vrabel@citrix.com> In xen_memory_setup() pages that occur in gaps in the memory map are released back to Xen. This reduces the domain's current page count in the hypervisor. The Xen balloon driver does not correctly decrease its initial current_pages count to reflect this. If 'delta' pages are released and the target is adjusted the resulting reservation is always 'delta' less than the requested target. This affects dom0 if the initial allocation of pages overlaps the PCI memory region but won't affect most domU guests that have been setup with pseudo-physical memory maps that don't have gaps. Fix this by accouting for the released pages when starting the balloon driver. If the domain's targets are managed by xapi, the domain may eventually run out of memory and die because xapi currently gets its target calculations wrong and whenever it is restarted it always reduces the target by 'delta'. Signed-off-by: David Vrabel <david.vrabel@citrix.com> --- arch/x86/xen/setup.c | 7 ++++++- drivers/xen/balloon.c | 4 +++- include/xen/page.h | 2 ++ 3 files changed, 11 insertions(+), 2 deletions(-) diff --git a/arch/x86/xen/setup.c b/arch/x86/xen/setup.c index 46d6d21..c983717 100644 --- a/arch/x86/xen/setup.c +++ b/arch/x86/xen/setup.c @@ -39,6 +39,9 @@ extern void xen_syscall32_target(void); /* Amount of extra memory space we add to the e820 ranges */ phys_addr_t xen_extra_mem_start, xen_extra_mem_size; +/* Number of pages released from the initial allocation. */ +unsigned long xen_released_pages; + /* * The maximum amount of extra memory compared to the base size. The * main scaling factor is the size of struct page. At extreme ratios @@ -313,7 +316,9 @@ char * __init xen_memory_setup(void) extra_pages = 0; } - extra_pages += xen_return_unused_memory(xen_start_info->nr_pages, &e820); + xen_released_pages = xen_return_unused_memory(xen_start_info->nr_pages, + &e820); + extra_pages += xen_released_pages; /* * Clamp the amount of extra memory to a EXTRA_MEM_RATIO diff --git a/drivers/xen/balloon.c b/drivers/xen/balloon.c index 5dfd8f8..4f59fb3 100644 --- a/drivers/xen/balloon.c +++ b/drivers/xen/balloon.c @@ -565,7 +565,9 @@ static int __init balloon_init(void) pr_info("xen/balloon: Initialising balloon driver.\n"); - balloon_stats.current_pages = xen_pv_domain() ? min(xen_start_info->nr_pages, max_pfn) : max_pfn; + balloon_stats.current_pages = xen_pv_domain() + ? min(xen_start_info->nr_pages - xen_released_pages, max_pfn) + : max_pfn; balloon_stats.target_pages = balloon_stats.current_pages; balloon_stats.balloon_low = 0; balloon_stats.balloon_high = 0; diff --git a/include/xen/page.h b/include/xen/page.h index 0be36b9..92b61f8 100644 --- a/include/xen/page.h +++ b/include/xen/page.h @@ -5,4 +5,6 @@ extern phys_addr_t xen_extra_mem_start, xen_extra_mem_size; +extern unsigned long xen_released_pages; + #endif /* _XEN_PAGE_H */ -- 1.7.2.5 _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel From xen-devel-bounces@lists.xensource.com Wed Sep 28 09:47:37 2011 Return-path: <xen-devel-bounces@lists.xensource.com> Envelope-to: www-data@lists.xensource.com Delivery-date: Wed, 28 Sep 2011 09:47:37 -0700 Received: from localhost ([127.0.0.1] helo=lists.colo.xensource.com) by lists.xensource.com with esmtp (Exim 4.43) id 1R8xIG-0007Z8-Ua; Wed, 28 Sep 2011 09:47:37 -0700 Received: from mail174.messagelabs.com ([85.158.138.51]) by lists.xensource.com with esmtp (Exim 4.43) id 1R8xGA-0006dm-8u for xen-devel@lists.xensource.com; Wed, 28 Sep 2011 09:45:26 -0700 X-Env-Sender: david.vrabel@citrix.com X-Msg-Ref: server-5.tower-174.messagelabs.com!1317228321!29424562!1 X-Originating-IP: [66.165.176.89] X-StarScan-Version: 6.4.1; banners=-,-,- X-VirusChecked: Checked Received: (qmail 25655 invoked from network); 28 Sep 2011 16:45:22 -0000 Received: from smtp.citrix.com (HELO SMTP.CITRIX.COM) (66.165.176.89) by server-5.tower-174.messagelabs.com with RC4-SHA encrypted SMTP; 28 Sep 2011 16:45:22 -0000 X-IronPort-AV: E=Sophos;i="4.68,456,1312171200"; d="scan'208";a="17779549" Received: from ftlpmailmx02.citrite.net ([10.13.107.66]) by FTLPIPO01.CITRIX.COM with ESMTP/TLS/RC4-MD5; 28 Sep 2011 12:45:21 -0400 Received: from smtp01.ad.xensource.com (10.219.128.104) by smtprelay.citrix.com (10.13.107.66) with Microsoft SMTP Server id 8.3.137.0; Wed, 28 Sep 2011 12:45:21 -0400 Received: from qabil.uk.xensource.com (qabil.uk.xensource.com [10.80.2.76]) by smtp01.ad.xensource.com (8.13.1/8.13.1) with ESMTP id p8SGjHv4022965; Wed, 28 Sep 2011 09:45:20 -0700 From: David Vrabel <david.vrabel@citrix.com> To: xen-devel@lists.xensource.com Date: Wed, 28 Sep 2011 17:46:33 +0100 Message-ID: <1317228396-8870-3-git-send-email-david.vrabel@citrix.com> X-Mailer: git-send-email 1.7.2.5 In-Reply-To: <1317228396-8870-1-git-send-email-david.vrabel@citrix.com> References: <1317228396-8870-1-git-send-email-david.vrabel@citrix.com> MIME-Version: 1.0 Content-Type: text/plain Cc: David Vrabel <david.vrabel@citrix.com>, Konrad Rzeszutek Wilk <konrad.wilk@oracle.com> Subject: [Xen-devel] [PATCH 2/5] xen/balloon: simplify test for the end of usable RAM X-BeenThere: xen-devel@lists.xensource.com X-Mailman-Version: 2.1.5 Precedence: list List-Id: Xen developer discussion <xen-devel.lists.xensource.com> List-Unsubscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe> List-Post: <mailto:xen-devel@lists.xensource.com> List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help> List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=subscribe> Sender: xen-devel-bounces@lists.xensource.com Errors-To: xen-devel-bounces@lists.xensource.com From: David Vrabel <david.vrabel@citrix.com> When initializing the balloon only max_pfn needs to be checked (max_pfn will always be <= e820_end_of_ram_pfn()) and improve the confusing comment. Signed-off-by: David Vrabel <david.vrabel@citrix.com> --- drivers/xen/balloon.c | 18 +++++++++--------- 1 files changed, 9 insertions(+), 9 deletions(-) diff --git a/drivers/xen/balloon.c b/drivers/xen/balloon.c index 4f59fb3..9efb993 100644 --- a/drivers/xen/balloon.c +++ b/drivers/xen/balloon.c @@ -586,16 +586,16 @@ static int __init balloon_init(void) #endif /* - * Initialise the balloon with excess memory space. We need - * to make sure we don't add memory which doesn't exist or - * logically exist. The E820 map can be trimmed to be smaller - * than the amount of physical memory due to the mem= command - * line parameter. And if this is a 32-bit non-HIGHMEM kernel - * on a system with memory which requires highmem to access, - * don't try to use it. + * Initialize the balloon with pages from the extra memory + * region (see arch/x86/xen/setup.c). + * + * If the amount of usable memory has been limited (e.g., with + * the 'mem' command line parameter), don't add pages beyond + * this limit. */ - extra_pfn_end = min(min(max_pfn, e820_end_of_ram_pfn()), - (unsigned long)PFN_DOWN(xen_extra_mem_start + xen_extra_mem_size)); + extra_pfn_end = min(max_pfn, + (unsigned long)PFN_DOWN(xen_extra_mem_start + + xen_extra_mem_size)); for (pfn = PFN_UP(xen_extra_mem_start); pfn < extra_pfn_end; pfn++) { -- 1.7.2.5 _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel From xen-devel-bounces@lists.xensource.com Wed Sep 28 09:48:26 2011 Return-path: <xen-devel-bounces@lists.xensource.com> Envelope-to: www-data@lists.xensource.com Delivery-date: Wed, 28 Sep 2011 09:48:26 -0700 Received: from localhost ([127.0.0.1] helo=lists.colo.xensource.com) by lists.xensource.com with esmtp (Exim 4.43) id 1R8xJ4-0007vt-Cj; Wed, 28 Sep 2011 09:48:26 -0700 Received: from mail174.messagelabs.com ([85.158.138.51]) by lists.xensource.com with esmtp (Exim 4.43) id 1R8xGB-0006dn-2Z for xen-devel@lists.xensource.com; Wed, 28 Sep 2011 09:45:27 -0700 X-Env-Sender: david.vrabel@citrix.com X-Msg-Ref: server-5.tower-174.messagelabs.com!1317228321!29424562!2 X-Originating-IP: [66.165.176.89] X-StarScan-Version: 6.4.1; banners=-,-,- X-VirusChecked: Checked Received: (qmail 25699 invoked from network); 28 Sep 2011 16:45:23 -0000 Received: from smtp.citrix.com (HELO SMTP.CITRIX.COM) (66.165.176.89) by server-5.tower-174.messagelabs.com with RC4-SHA encrypted SMTP; 28 Sep 2011 16:45:23 -0000 X-IronPort-AV: E=Sophos;i="4.68,456,1312171200"; d="scan'208";a="17779551" Received: from ftlpmailmx02.citrite.net ([10.13.107.66]) by FTLPIPO01.CITRIX.COM with ESMTP/TLS/RC4-MD5; 28 Sep 2011 12:45:23 -0400 Received: from smtp01.ad.xensource.com (10.219.128.104) by smtprelay.citrix.com (10.13.107.66) with Microsoft SMTP Server id 8.3.137.0; Wed, 28 Sep 2011 12:45:23 -0400 Received: from qabil.uk.xensource.com (qabil.uk.xensource.com [10.80.2.76]) by smtp01.ad.xensource.com (8.13.1/8.13.1) with ESMTP id p8SGjHv6022965; Wed, 28 Sep 2011 09:45:22 -0700 From: David Vrabel <david.vrabel@citrix.com> To: xen-devel@lists.xensource.com Date: Wed, 28 Sep 2011 17:46:35 +0100 Message-ID: <1317228396-8870-5-git-send-email-david.vrabel@citrix.com> X-Mailer: git-send-email 1.7.2.5 In-Reply-To: <1317228396-8870-1-git-send-email-david.vrabel@citrix.com> References: <1317228396-8870-1-git-send-email-david.vrabel@citrix.com> MIME-Version: 1.0 Content-Type: text/plain Cc: David Vrabel <david.vrabel@citrix.com>, Konrad Rzeszutek Wilk <konrad.wilk@oracle.com> Subject: [Xen-devel] [PATCH 4/5] xen: allow extra memory to be in multiple regions X-BeenThere: xen-devel@lists.xensource.com X-Mailman-Version: 2.1.5 Precedence: list List-Id: Xen developer discussion <xen-devel.lists.xensource.com> List-Unsubscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe> List-Post: <mailto:xen-devel@lists.xensource.com> List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help> List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=subscribe> Sender: xen-devel-bounces@lists.xensource.com Errors-To: xen-devel-bounces@lists.xensource.com From: David Vrabel <david.vrabel@citrix.com> Allow the extra memory (used by the balloon driver) to be in multiple regions (typically two regions, one for low memory and one for high memory). This allows the balloon driver to increase the number of available low pages (if the initial number if pages is small). As a side effect, the algorithm for building the e820 memory map is simpler and more obviously correct as the map supplied by the hypervisor is (almost) used as is (in particular, all reserved regions and gaps are preserved). Only RAM regions are altered and RAM regions above max_pfn + extra_pages are marked as unused (the region is split in two if necessary). Signed-off-by: David Vrabel <david.vrabel@citrix.com> --- arch/x86/xen/setup.c | 182 ++++++++++++++++++++++++-------------------------- 1 files changed, 86 insertions(+), 96 deletions(-) diff --git a/arch/x86/xen/setup.c b/arch/x86/xen/setup.c index 0c8e974..03eda3c 100644 --- a/arch/x86/xen/setup.c +++ b/arch/x86/xen/setup.c @@ -54,26 +54,32 @@ unsigned long xen_released_pages; */ #define EXTRA_MEM_RATIO (10) -static void __init xen_add_extra_mem(unsigned long pages) +static void __init xen_add_extra_mem(u64 start, u64 size) { unsigned long pfn; + int i; - u64 size = (u64)pages * PAGE_SIZE; - u64 extra_start = xen_extra_mem[0].start + xen_extra_mem[0].size; - - if (!pages) - return; - - e820_add_region(extra_start, size, E820_RAM); - sanitize_e820_map(e820.map, ARRAY_SIZE(e820.map), &e820.nr_map); - - memblock_x86_reserve_range(extra_start, extra_start + size, "XEN EXTRA"); + for (i = 0; i < XEN_EXTRA_MEM_MAX_REGIONS; i++) { + /* Add new region. */ + if (xen_extra_mem[i].size == 0) { + xen_extra_mem[i].start = start; + xen_extra_mem[i].size = size; + break; + } + /* Append to existing region. */ + if (xen_extra_mem[i].start + xen_extra_mem[i].size == start) { + xen_extra_mem[i].size += size; + break; + } + } + if (i == XEN_EXTRA_MEM_MAX_REGIONS) + printk(KERN_WARNING "Warning: not enough extra memory regions\n"); - xen_extra_mem[0].size += size; + memblock_x86_reserve_range(start, start + size, "XEN EXTRA"); - xen_max_p2m_pfn = PFN_DOWN(extra_start + size); + xen_max_p2m_pfn = PFN_DOWN(start + size); - for (pfn = PFN_DOWN(extra_start); pfn <= xen_max_p2m_pfn; pfn++) + for (pfn = PFN_DOWN(start); pfn <= xen_max_p2m_pfn; pfn++) __set_phys_to_machine(pfn, INVALID_P2M_ENTRY); } @@ -120,8 +126,8 @@ static unsigned long __init xen_release_chunk(phys_addr_t start_addr, return len; } -static unsigned long __init xen_return_unused_memory(unsigned long max_pfn, - const struct e820map *e820) +static unsigned long __init xen_return_unused_memory( + unsigned long max_pfn, const struct e820entry *map, int nr_map) { phys_addr_t max_addr = PFN_PHYS(max_pfn); phys_addr_t last_end = ISA_END_ADDRESS; @@ -129,13 +135,13 @@ static unsigned long __init xen_return_unused_memory(unsigned long max_pfn, int i; /* Free any unused memory above the low 1Mbyte. */ - for (i = 0; i < e820->nr_map && last_end < max_addr; i++) { - phys_addr_t end = e820->map[i].addr; + for (i = 0; i < nr_map && last_end < max_addr; i++) { + phys_addr_t end = map[i].addr; end = min(max_addr, end); if (last_end < end) released += xen_release_chunk(last_end, end); - last_end = max(last_end, e820->map[i].addr + e820->map[i].size); + last_end = max(last_end, map[i].addr + map[i].size); } if (last_end < max_addr) @@ -200,20 +206,32 @@ static unsigned long __init xen_get_max_pages(void) return min(max_pages, MAX_DOMAIN_PAGES); } +static void xen_align_and_add_e820_region(u64 start, u64 size, int type) +{ + u64 end = start + size; + + /* Align RAM regions to page boundaries. */ + if (type == E820_RAM || type == E820_UNUSABLE) { + start = PAGE_ALIGN(start); + end &= ~((u64)PAGE_SIZE - 1); + } + + e820_add_region(start, end - start, type); +} + /** * machine_specific_memory_setup - Hook for machine specific memory setup. **/ char * __init xen_memory_setup(void) { static struct e820entry map[E820MAX] __initdata; - static struct e820entry map_raw[E820MAX] __initdata; unsigned long max_pfn = xen_start_info->nr_pages; unsigned long long mem_end; int rc; struct xen_memory_map memmap; + unsigned long max_pages; unsigned long extra_pages = 0; - unsigned long extra_limit; unsigned long identity_pages = 0; int i; int op; @@ -240,49 +258,55 @@ char * __init xen_memory_setup(void) } BUG_ON(rc); - memcpy(map_raw, map, sizeof(map)); - e820.nr_map = 0; - xen_extra_mem[0].start = mem_end; - for (i = 0; i < memmap.nr_entries; i++) { - unsigned long long end; - - /* Guard against non-page aligned E820 entries. */ - if (map[i].type == E820_RAM) - map[i].size -= (map[i].size + map[i].addr) % PAGE_SIZE; - - end = map[i].addr + map[i].size; - if (map[i].type == E820_RAM && end > mem_end) { - /* RAM off the end - may be partially included */ - u64 delta = min(map[i].size, end - mem_end); - - map[i].size -= delta; - end -= delta; - - extra_pages += PFN_DOWN(delta); - /* - * Set RAM below 4GB that is not for us to be unusable. - * This prevents "System RAM" address space from being - * used as potential resource for I/O address (happens - * when 'allocate_resource' is called). - */ - if (delta && - (xen_initial_domain() && end < 0x100000000ULL)) - e820_add_region(end, delta, E820_UNUSABLE); + /* Make sure the Xen-supplied memory map is well-ordered. */ + sanitize_e820_map(map, memmap.nr_entries, &memmap.nr_entries); + + max_pages = xen_get_max_pages(); + if (max_pages > max_pfn) + extra_pages += max_pages - max_pfn; + + xen_released_pages = xen_return_unused_memory(max_pfn, map, + memmap.nr_entries); + extra_pages += xen_released_pages; + + /* + * Clamp the amount of extra memory to a EXTRA_MEM_RATIO + * factor the base size. On non-highmem systems, the base + * size is the full initial memory allocation; on highmem it + * is limited to the max size of lowmem, so that it doesn't + * get completely filled. + * + * In principle there could be a problem in lowmem systems if + * the initial memory is also very large with respect to + * lowmem, but we won't try to deal with that here. + */ + extra_pages = min(EXTRA_MEM_RATIO * min(max_pfn, PFN_DOWN(MAXMEM)), + extra_pages); + + i = 0; + while (i < memmap.nr_entries) { + u64 addr = map[i].addr; + u64 size = map[i].size; + u32 type = map[i].type; + + if (type == E820_RAM) { + if (addr < mem_end) { + size = min(size, mem_end - addr); + } else if (extra_pages) { + size = min(size, (u64)extra_pages * PAGE_SIZE); + extra_pages -= size / PAGE_SIZE; + xen_add_extra_mem(addr, size); + } else + type = E820_UNUSABLE; } - if (map[i].size > 0 && end > xen_extra_mem[0].start) - xen_extra_mem[0].start = end; + xen_align_and_add_e820_region(addr, size, type); - /* Add region if any remains */ - if (map[i].size > 0) - e820_add_region(map[i].addr, map[i].size, map[i].type); + map[i].addr += size; + map[i].size -= size; + if (map[i].size == 0) + i++; } - /* Align the balloon area so that max_low_pfn does not get set - * to be at the _end_ of the PCI gap at the far end (fee01000). - * Note that the start of balloon area gets set in the loop above - * to be past the last E820 region. */ - if (xen_initial_domain() && (xen_extra_mem[0].start < (1ULL<<32))) - xen_extra_mem[0].start = (1ULL<<32); /* * In domU, the ISA region is normal, usable memory, but we @@ -308,45 +332,11 @@ char * __init xen_memory_setup(void) sanitize_e820_map(e820.map, ARRAY_SIZE(e820.map), &e820.nr_map); - extra_limit = xen_get_max_pages(); - if (max_pfn + extra_pages > extra_limit) { - if (extra_limit > max_pfn) - extra_pages = extra_limit - max_pfn; - else - extra_pages = 0; - } - - xen_released_pages = xen_return_unused_memory(xen_start_info->nr_pages, - &e820); - extra_pages += xen_released_pages; - - /* - * Clamp the amount of extra memory to a EXTRA_MEM_RATIO - * factor the base size. On non-highmem systems, the base - * size is the full initial memory allocation; on highmem it - * is limited to the max size of lowmem, so that it doesn't - * get completely filled. - * - * In principle there could be a problem in lowmem systems if - * the initial memory is also very large with respect to - * lowmem, but we won't try to deal with that here. - */ - extra_limit = min(EXTRA_MEM_RATIO * min(max_pfn, PFN_DOWN(MAXMEM)), - max_pfn + extra_pages); - - if (extra_limit >= max_pfn) - extra_pages = extra_limit - max_pfn; - else - extra_pages = 0; - - xen_add_extra_mem(extra_pages); - /* * Set P2M for all non-RAM pages and E820 gaps to be identity - * type PFNs. We supply it with the non-sanitized version - * of the E820. + * type PFNs. */ - identity_pages = xen_set_identity(map_raw, memmap.nr_entries); + identity_pages = xen_set_identity(e820.map, e820.nr_map); printk(KERN_INFO "Set %ld page(s) to 1-1 mapping.\n", identity_pages); return "Xen"; } -- 1.7.2.5 _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel From xen-devel-bounces@lists.xensource.com Wed Sep 28 09:49:18 2011 Return-path: <xen-devel-bounces@lists.xensource.com> Envelope-to: www-data@lists.xensource.com Delivery-date: Wed, 28 Sep 2011 09:49:18 -0700 Received: from localhost ([127.0.0.1] helo=lists.colo.xensource.com) by lists.xensource.com with esmtp (Exim 4.43) id 1R8xJt-0008Ic-V4; Wed, 28 Sep 2011 09:49:17 -0700 Received: from mail174.messagelabs.com ([85.158.138.51]) by lists.xensource.com with esmtp (Exim 4.43) id 1R8xGB-0006do-DB for xen-devel@lists.xensource.com; Wed, 28 Sep 2011 09:45:27 -0700 X-Env-Sender: david.vrabel@citrix.com X-Msg-Ref: server-13.tower-174.messagelabs.com!1317228322!33139025!1 X-Originating-IP: [66.165.176.63] X-StarScan-Version: 6.4.1; banners=-,-,- X-VirusChecked: Checked Received: (qmail 4600 invoked from network); 28 Sep 2011 16:45:24 -0000 Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63) by server-13.tower-174.messagelabs.com with RC4-SHA encrypted SMTP; 28 Sep 2011 16:45:24 -0000 X-IronPort-AV: E=Sophos;i="4.68,456,1312171200"; d="scan'208";a="165007096" Received: from ftlpmailmx02.citrite.net ([10.13.107.66]) by FTLPIPO02.CITRIX.COM with ESMTP/TLS/RC4-MD5; 28 Sep 2011 12:45:22 -0400 Received: from smtp01.ad.xensource.com (10.219.128.104) by smtprelay.citrix.com (10.13.107.66) with Microsoft SMTP Server id 8.3.137.0; Wed, 28 Sep 2011 12:45:22 -0400 Received: from qabil.uk.xensource.com (qabil.uk.xensource.com [10.80.2.76]) by smtp01.ad.xensource.com (8.13.1/8.13.1) with ESMTP id p8SGjHv5022965; Wed, 28 Sep 2011 09:45:21 -0700 From: David Vrabel <david.vrabel@citrix.com> To: xen-devel@lists.xensource.com Date: Wed, 28 Sep 2011 17:46:34 +0100 Message-ID: <1317228396-8870-4-git-send-email-david.vrabel@citrix.com> X-Mailer: git-send-email 1.7.2.5 In-Reply-To: <1317228396-8870-1-git-send-email-david.vrabel@citrix.com> References: <1317228396-8870-1-git-send-email-david.vrabel@citrix.com> MIME-Version: 1.0 Content-Type: text/plain Cc: David Vrabel <david.vrabel@citrix.com>, Konrad Rzeszutek Wilk <konrad.wilk@oracle.com> Subject: [Xen-devel] [PATCH 3/5] xen: allow balloon driver to use more than one memory region X-BeenThere: xen-devel@lists.xensource.com X-Mailman-Version: 2.1.5 Precedence: list List-Id: Xen developer discussion <xen-devel.lists.xensource.com> List-Unsubscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe> List-Post: <mailto:xen-devel@lists.xensource.com> List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help> List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=subscribe> Sender: xen-devel-bounces@lists.xensource.com Errors-To: xen-devel-bounces@lists.xensource.com From: David Vrabel <david.vrabel@citrix.com> Allow the xen balloon driver to populate its list of extra pages from more than one region of memory. This will allow platforms to provide (for example) a region of low memory and a region of high memory. The maximum possible number of extra regions is 128 (== E820MAX) which is quite large so xen_extra_mem is placed in __initdata. This is safe as both xen_memory_setup() and balloon_init() are in __init. The balloon regions themselves are not altered (i.e., there is still only the one region). Signed-off-by: David Vrabel <david.vrabel@citrix.com> --- arch/x86/xen/setup.c | 20 ++++++++++---------- drivers/xen/balloon.c | 44 +++++++++++++++++++++++++++----------------- include/xen/page.h | 10 +++++++++- 3 files changed, 46 insertions(+), 28 deletions(-) diff --git a/arch/x86/xen/setup.c b/arch/x86/xen/setup.c index c983717..0c8e974 100644 --- a/arch/x86/xen/setup.c +++ b/arch/x86/xen/setup.c @@ -37,7 +37,7 @@ extern void xen_syscall_target(void); extern void xen_syscall32_target(void); /* Amount of extra memory space we add to the e820 ranges */ -phys_addr_t xen_extra_mem_start, xen_extra_mem_size; +struct xen_memory_region xen_extra_mem[XEN_EXTRA_MEM_MAX_REGIONS] __initdata; /* Number of pages released from the initial allocation. */ unsigned long xen_released_pages; @@ -59,7 +59,7 @@ static void __init xen_add_extra_mem(unsigned long pages) unsigned long pfn; u64 size = (u64)pages * PAGE_SIZE; - u64 extra_start = xen_extra_mem_start + xen_extra_mem_size; + u64 extra_start = xen_extra_mem[0].start + xen_extra_mem[0].size; if (!pages) return; @@ -69,7 +69,7 @@ static void __init xen_add_extra_mem(unsigned long pages) memblock_x86_reserve_range(extra_start, extra_start + size, "XEN EXTRA"); - xen_extra_mem_size += size; + xen_extra_mem[0].size += size; xen_max_p2m_pfn = PFN_DOWN(extra_start + size); @@ -242,7 +242,7 @@ char * __init xen_memory_setup(void) memcpy(map_raw, map, sizeof(map)); e820.nr_map = 0; - xen_extra_mem_start = mem_end; + xen_extra_mem[0].start = mem_end; for (i = 0; i < memmap.nr_entries; i++) { unsigned long long end; @@ -270,8 +270,8 @@ char * __init xen_memory_setup(void) e820_add_region(end, delta, E820_UNUSABLE); } - if (map[i].size > 0 && end > xen_extra_mem_start) - xen_extra_mem_start = end; + if (map[i].size > 0 && end > xen_extra_mem[0].start) + xen_extra_mem[0].start = end; /* Add region if any remains */ if (map[i].size > 0) @@ -279,10 +279,10 @@ char * __init xen_memory_setup(void) } /* Align the balloon area so that max_low_pfn does not get set * to be at the _end_ of the PCI gap at the far end (fee01000). - * Note that xen_extra_mem_start gets set in the loop above to be - * past the last E820 region. */ - if (xen_initial_domain() && (xen_extra_mem_start < (1ULL<<32))) - xen_extra_mem_start = (1ULL<<32); + * Note that the start of balloon area gets set in the loop above + * to be past the last E820 region. */ + if (xen_initial_domain() && (xen_extra_mem[0].start < (1ULL<<32))) + xen_extra_mem[0].start = (1ULL<<32); /* * In domU, the ISA region is normal, usable memory, but we diff --git a/drivers/xen/balloon.c b/drivers/xen/balloon.c index 9efb993..fc43b53 100644 --- a/drivers/xen/balloon.c +++ b/drivers/xen/balloon.c @@ -555,11 +555,32 @@ void free_xenballooned_pages(int nr_pages, struct page** pages) } EXPORT_SYMBOL(free_xenballooned_pages); -static int __init balloon_init(void) +static void __init balloon_add_region(unsigned long start_pfn, + unsigned long pages) { unsigned long pfn, extra_pfn_end; struct page *page; + /* + * If the amount of usable memory has been limited (e.g., with + * the 'mem' command line parameter), don't add pages beyond + * this limit. + */ + extra_pfn_end = min(max_pfn, start_pfn + pages); + + for (pfn = start_pfn; pfn < extra_pfn_end; pfn++) { + page = pfn_to_page(pfn); + /* totalram_pages and totalhigh_pages do not + include the boot-time balloon extension, so + don't subtract from it. */ + __balloon_append(page); + } +} + +static int __init balloon_init(void) +{ + int i; + if (!xen_domain()) return -ENODEV; @@ -587,23 +608,12 @@ static int __init balloon_init(void) /* * Initialize the balloon with pages from the extra memory - * region (see arch/x86/xen/setup.c). - * - * If the amount of usable memory has been limited (e.g., with - * the 'mem' command line parameter), don't add pages beyond - * this limit. + * regions (see arch/x86/xen/setup.c). */ - extra_pfn_end = min(max_pfn, - (unsigned long)PFN_DOWN(xen_extra_mem_start - + xen_extra_mem_size)); - for (pfn = PFN_UP(xen_extra_mem_start); - pfn < extra_pfn_end; - pfn++) { - page = pfn_to_page(pfn); - /* totalram_pages and totalhigh_pages do not include the boot-time - balloon extension, so don't subtract from it. */ - __balloon_append(page); - } + for (i = 0; i < XEN_EXTRA_MEM_MAX_REGIONS; i++) + if (xen_extra_mem[i].size) + balloon_add_region(PFN_UP(xen_extra_mem[i].start), + PFN_DOWN(xen_extra_mem[i].size)); return 0; } diff --git a/include/xen/page.h b/include/xen/page.h index 92b61f8..12765b6 100644 --- a/include/xen/page.h +++ b/include/xen/page.h @@ -3,7 +3,15 @@ #include <asm/xen/page.h> -extern phys_addr_t xen_extra_mem_start, xen_extra_mem_size; +struct xen_memory_region { + phys_addr_t start; + phys_addr_t size; +}; + +#define XEN_EXTRA_MEM_MAX_REGIONS 128 /* == E820MAX */ + +extern __initdata +struct xen_memory_region xen_extra_mem[XEN_EXTRA_MEM_MAX_REGIONS]; extern unsigned long xen_released_pages; -- 1.7.2.5 _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel From xen-devel-bounces@lists.xensource.com Wed Sep 28 09:50:20 2011 Return-path: <xen-devel-bounces@lists.xensource.com> Envelope-to: www-data@lists.xensource.com Delivery-date: Wed, 28 Sep 2011 09:50:20 -0700 Received: from localhost ([127.0.0.1] helo=lists.colo.xensource.com) by lists.xensource.com with esmtp (Exim 4.43) id 1R8xKu-0000JD-EC; Wed, 28 Sep 2011 09:50:20 -0700 Received: from mail174.messagelabs.com ([85.158.138.51]) by lists.xensource.com with esmtp (Exim 4.43) id 1R8xGC-0006dy-HB for xen-devel@lists.xensource.com; Wed, 28 Sep 2011 09:45:29 -0700 X-Env-Sender: david.vrabel@citrix.com X-Msg-Ref: server-13.tower-174.messagelabs.com!1317228322!33139025!2 X-Originating-IP: [66.165.176.63] X-StarScan-Version: 6.4.1; banners=-,-,- X-VirusChecked: Checked Received: (qmail 4621 invoked from network); 28 Sep 2011 16:45:25 -0000 Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63) by server-13.tower-174.messagelabs.com with RC4-SHA encrypted SMTP; 28 Sep 2011 16:45:25 -0000 X-IronPort-AV: E=Sophos;i="4.68,456,1312171200"; d="scan'208";a="165007104" Received: from ftlpmailmx02.citrite.net ([10.13.107.66]) by FTLPIPO02.CITRIX.COM with ESMTP/TLS/RC4-MD5; 28 Sep 2011 12:45:24 -0400 Received: from smtp01.ad.xensource.com (10.219.128.104) by smtprelay.citrix.com (10.13.107.66) with Microsoft SMTP Server id 8.3.137.0; Wed, 28 Sep 2011 12:45:24 -0400 Received: from qabil.uk.xensource.com (qabil.uk.xensource.com [10.80.2.76]) by smtp01.ad.xensource.com (8.13.1/8.13.1) with ESMTP id p8SGjHv7022965; Wed, 28 Sep 2011 09:45:23 -0700 From: David Vrabel <david.vrabel@citrix.com> To: xen-devel@lists.xensource.com Date: Wed, 28 Sep 2011 17:46:36 +0100 Message-ID: <1317228396-8870-6-git-send-email-david.vrabel@citrix.com> X-Mailer: git-send-email 1.7.2.5 In-Reply-To: <1317228396-8870-1-git-send-email-david.vrabel@citrix.com> References: <1317228396-8870-1-git-send-email-david.vrabel@citrix.com> MIME-Version: 1.0 Content-Type: text/plain Cc: David Vrabel <david.vrabel@citrix.com>, Konrad Rzeszutek Wilk <konrad.wilk@oracle.com> Subject: [Xen-devel] [PATCH 5/5] xen: release all pages within 1-1 p2m mappings X-BeenThere: xen-devel@lists.xensource.com X-Mailman-Version: 2.1.5 Precedence: list List-Id: Xen developer discussion <xen-devel.lists.xensource.com> List-Unsubscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe> List-Post: <mailto:xen-devel@lists.xensource.com> List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help> List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=subscribe> Sender: xen-devel-bounces@lists.xensource.com Errors-To: xen-devel-bounces@lists.xensource.com From: David Vrabel <david.vrabel@citrix.com> In xen_memory_setup() all reserved regions and gaps are set to an identity (1-1) p2m mapping. If an available page has a PFN within one of these 1-1 mappings it will become inaccessible (as it MFN is lost) so release them before setting up the mapping. This can make an additional 256 MiB or more of RAM available (depending on the size of the reserved regions in the memory map) if the initial pages overlap with reserved regions. The 1:1 p2m mappings are also extended to cover partial pages. This fixes an issue with (for example) systems with a BIOS that puts the DMI tables in a reserved region that begins on a non-page boundary. Signed-off-by: David Vrabel <david.vrabel@citrix.com> --- arch/x86/xen/setup.c | 117 ++++++++++++++++++-------------------------------- 1 files changed, 42 insertions(+), 75 deletions(-) diff --git a/arch/x86/xen/setup.c b/arch/x86/xen/setup.c index 03eda3c..62a1334 100644 --- a/arch/x86/xen/setup.c +++ b/arch/x86/xen/setup.c @@ -83,25 +83,18 @@ static void __init xen_add_extra_mem(u64 start, u64 size) __set_phys_to_machine(pfn, INVALID_P2M_ENTRY); } -static unsigned long __init xen_release_chunk(phys_addr_t start_addr, - phys_addr_t end_addr) +static unsigned long __init xen_release_chunk(unsigned long start, + unsigned long end) { struct xen_memory_reservation reservation = { .address_bits = 0, .extent_order = 0, .domid = DOMID_SELF }; - unsigned long start, end; unsigned long len = 0; unsigned long pfn; int ret; - start = PFN_UP(start_addr); - end = PFN_DOWN(end_addr); - - if (end <= start) - return 0; - for(pfn = start; pfn < end; pfn++) { unsigned long mfn = pfn_to_mfn(pfn); @@ -126,72 +119,52 @@ static unsigned long __init xen_release_chunk(phys_addr_t start_addr, return len; } -static unsigned long __init xen_return_unused_memory( - unsigned long max_pfn, const struct e820entry *map, int nr_map) +static unsigned long __init xen_set_identity_and_release( + const struct e820entry *list, size_t map_size, unsigned long nr_pages) { - phys_addr_t max_addr = PFN_PHYS(max_pfn); - phys_addr_t last_end = ISA_END_ADDRESS; + phys_addr_t start = 0; unsigned long released = 0; - int i; - - /* Free any unused memory above the low 1Mbyte. */ - for (i = 0; i < nr_map && last_end < max_addr; i++) { - phys_addr_t end = map[i].addr; - end = min(max_addr, end); - - if (last_end < end) - released += xen_release_chunk(last_end, end); - last_end = max(last_end, map[i].addr + map[i].size); - } - - if (last_end < max_addr) - released += xen_release_chunk(last_end, max_addr); - - printk(KERN_INFO "released %lu pages of unused memory\n", released); - return released; -} - -static unsigned long __init xen_set_identity(const struct e820entry *list, - ssize_t map_size) -{ - phys_addr_t last = xen_initial_domain() ? 0 : ISA_END_ADDRESS; - phys_addr_t start_pci = last; - const struct e820entry *entry; unsigned long identity = 0; + const struct e820entry *entry; int i; + /* + * Combine non-RAM regions and gaps until a RAM region (or the + * end of the map) is reached, then set the 1:1 map and + * release the pages (if available) in those non-RAM regions. + * + * The combined non-RAM regions are rounded to a whole number + * of pages so any partial pages are accessible via the 1:1 + * mapping. This is needed for some BIOSes that put (for + * example) the DMI tables in a reserved region that begins on + * a non-page boundary. + */ for (i = 0, entry = list; i < map_size; i++, entry++) { - phys_addr_t start = entry->addr; - phys_addr_t end = start + entry->size; + phys_addr_t end = entry->addr + entry->size; - if (start < last) - start = last; + if (entry->type == E820_RAM || i == map_size - 1) { + unsigned long start_pfn = PFN_DOWN(start); + unsigned long end_pfn = PFN_UP(end); - if (end <= start) - continue; + if (entry->type == E820_RAM) + end_pfn = PFN_UP(entry->addr); - /* Skip over the 1MB region. */ - if (last > end) - continue; + if (start_pfn < end_pfn) { + if (start_pfn < nr_pages) + released += xen_release_chunk( + start_pfn, min(end_pfn, nr_pages)); - if ((entry->type == E820_RAM) || (entry->type == E820_UNUSABLE)) { - if (start > start_pci) identity += set_phys_range_identity( - PFN_UP(start_pci), PFN_DOWN(start)); - - /* Without saving 'last' we would gooble RAM too - * at the end of the loop. */ - last = end; - start_pci = end; - continue; + start_pfn, end_pfn); + } + start = end; } - start_pci = min(start, start_pci); - last = end; } - if (last > start_pci) - identity += set_phys_range_identity( - PFN_UP(start_pci), PFN_DOWN(last)); - return identity; + + printk(KERN_INFO "Released %lu pages of unused memory\n", released); + printk(KERN_INFO "Set %ld page(s) to 1-1 mapping\n", identity); + + return released; } static unsigned long __init xen_get_max_pages(void) @@ -232,7 +205,6 @@ char * __init xen_memory_setup(void) struct xen_memory_map memmap; unsigned long max_pages; unsigned long extra_pages = 0; - unsigned long identity_pages = 0; int i; int op; @@ -265,8 +237,13 @@ char * __init xen_memory_setup(void) if (max_pages > max_pfn) extra_pages += max_pages - max_pfn; - xen_released_pages = xen_return_unused_memory(max_pfn, map, - memmap.nr_entries); + /* + * Set P2M for all non-RAM pages and E820 gaps to be identity + * type PFNs. Any RAM pages that would be made inaccesible by + * this are first released. + */ + xen_released_pages = xen_set_identity_and_release( + map, memmap.nr_entries, max_pfn); extra_pages += xen_released_pages; /* @@ -312,10 +289,6 @@ char * __init xen_memory_setup(void) * In domU, the ISA region is normal, usable memory, but we * reserve ISA memory anyway because too many things poke * about in there. - * - * In Dom0, the host E820 information can leave gaps in the - * ISA range, which would cause us to release those pages. To - * avoid this, we unconditionally reserve them here. */ e820_add_region(ISA_START_ADDRESS, ISA_END_ADDRESS - ISA_START_ADDRESS, E820_RESERVED); @@ -332,12 +305,6 @@ char * __init xen_memory_setup(void) sanitize_e820_map(e820.map, ARRAY_SIZE(e820.map), &e820.nr_map); - /* - * Set P2M for all non-RAM pages and E820 gaps to be identity - * type PFNs. - */ - identity_pages = xen_set_identity(e820.map, e820.nr_map); - printk(KERN_INFO "Set %ld page(s) to 1-1 mapping.\n", identity_pages); return "Xen"; } -- 1.7.2.5 _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel From xen-devel-bounces@lists.xensource.com Wed Sep 28 10:04:35 2011 Return-path: <xen-devel-bounces@lists.xensource.com> Envelope-to: www-data@lists.xensource.com Delivery-date: Wed, 28 Sep 2011 10:04:35 -0700 Received: from localhost ([127.0.0.1] helo=lists.colo.xensource.com) by lists.xensource.com with esmtp (Exim 4.43) id 1R8xYg-0000xe-Br; Wed, 28 Sep 2011 10:04:34 -0700 Received: from mail174.messagelabs.com ([85.158.138.51]) by lists.xensource.com with esmtp (Exim 4.43) id 1R8xVJ-0000gt-N3 for xen-devel@lists.xensource.com; Wed, 28 Sep 2011 10:01:47 -0700 X-Env-Sender: david.vrabel@citrix.com X-Msg-Ref: server-8.tower-174.messagelabs.com!1317229261!19437747!1 X-Originating-IP: [66.165.176.63] X-StarScan-Version: 6.4.1; banners=-,-,- X-VirusChecked: Checked Received: (qmail 24175 invoked from network); 28 Sep 2011 17:01:02 -0000 Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63) by server-8.tower-174.messagelabs.com with RC4-SHA encrypted SMTP; 28 Sep 2011 17:01:02 -0000 X-IronPort-AV: E=Sophos;i="4.68,456,1312171200"; d="scan'208";a="165009633" Received: from ftlpmailmx01.citrite.net ([10.13.107.65]) by FTLPIPO02.CITRIX.COM with ESMTP/TLS/RC4-MD5; 28 Sep 2011 13:01:00 -0400 Received: from [10.80.2.76] (10.80.2.76) by FTLPMAILMX01.citrite.net (10.13.107.65) with Microsoft SMTP Server id 8.3.137.0; Wed, 28 Sep 2011 13:01:00 -0400 Message-ID: <4E835324.30902@citrix.com> Date: Wed, 28 Sep 2011 18:02:28 +0100 From: David Vrabel <david.vrabel@citrix.com> User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.1.16) Gecko/20110818 Icedove/3.0.11 MIME-Version: 1.0 To: Anthony Wright <anthony@overnetdata.com> Subject: Re: [Xen-devel] dmidecode doesn't work under xen 4.1.1 on certain hardware References: <4E7C6BDC.8070005@overnetdata.com> <20110923133200.GC19579@phenom.oracle.com> <4E7C9C8B.2010108@overnetdata.com> <20110926141322.GD4102@phenom.oracle.com> <4E8090D4.2090009@overnetdata.com> <20110926193732.GA10007@phenom.oracle.com> <4E82E429.2080600@overnetdata.com> <20110928132815.GE10270@phenom.oracle.com> <4E83462B.9080002@overnetdata.com> In-Reply-To: <4E83462B.9080002@overnetdata.com> Content-Type: text/plain; charset="ISO-8859-1" Content-Transfer-Encoding: 7bit Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>, Konrad Rzeszutek Wilk <konrad.wilk@oracle.com> X-BeenThere: xen-devel@lists.xensource.com X-Mailman-Version: 2.1.5 Precedence: list List-Id: Xen developer discussion <xen-devel.lists.xensource.com> List-Unsubscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe> List-Post: <mailto:xen-devel@lists.xensource.com> List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help> List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=subscribe> Sender: xen-devel-bounces@lists.xensource.com Errors-To: xen-devel-bounces@lists.xensource.com On 28/09/11 17:07, Anthony Wright wrote: > On 28/09/2011 14:28, Konrad Rzeszutek Wilk wrote: >> >> Would you be up for testing a different variant of that patch just to make >> sure? > > Not a problem, ship me the patch when you're ready. I'm running 3.0.4 at > the moment and would prefer to stick with 3.0.x for now, so hope that > won't be a problem. I've just posted an updated patch series that should include a fix for your dmidecode problem. http://lists.xensource.com/archives/html/xen-devel/2011-09/msg01621.html If you running 3.0.4 you will also need the first two patches from http://lists.xensource.com/archives/html/xen-devel/2011-09/msg00817.html Please give these a try and let me know if they work. Thanks. David _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel From xen-devel-bounces@lists.xensource.com Wed Sep 28 10:06:35 2011 Return-path: <xen-devel-bounces@lists.xensource.com> Envelope-to: www-data@lists.xensource.com Delivery-date: Wed, 28 Sep 2011 10:06:35 -0700 Received: from localhost ([127.0.0.1] helo=lists.colo.xensource.com) by lists.xensource.com with esmtp (Exim 4.43) id 1R8xac-0001SO-Co; Wed, 28 Sep 2011 10:06:34 -0700 Received: from mail21.messagelabs.com ([85.158.143.35]) by lists.xensource.com with esmtp (Exim 4.43) id 1R8xXg-0000lP-FB for xen-devel@lists.xensource.com; Wed, 28 Sep 2011 10:03:35 -0700 X-Env-Sender: david.vrabel@citrix.com X-Msg-Ref: server-9.tower-21.messagelabs.com!1317229362!50183073!1 X-Originating-IP: [66.165.176.89] X-StarScan-Version: 6.4.1; banners=-,-,- X-VirusChecked: Checked Received: (qmail 11275 invoked from network); 28 Sep 2011 17:02:43 -0000 Received: from smtp.citrix.com (HELO SMTP.CITRIX.COM) (66.165.176.89) by server-9.tower-21.messagelabs.com with RC4-SHA encrypted SMTP; 28 Sep 2011 17:02:43 -0000 X-IronPort-AV: E=Sophos;i="4.68,456,1312171200"; d="scan'208";a="17780294" Received: from ftlpmailmx01.citrite.net ([10.13.107.65]) by FTLPIPO01.CITRIX.COM with ESMTP/TLS/RC4-MD5; 28 Sep 2011 13:03:22 -0400 Received: from [10.80.2.76] (10.80.2.76) by FTLPMAILMX01.citrite.net (10.13.107.65) with Microsoft SMTP Server id 8.3.137.0; Wed, 28 Sep 2011 13:03:21 -0400 Message-ID: <4E8353B1.9070007@citrix.com> Date: Wed, 28 Sep 2011 18:04:49 +0100 From: David Vrabel <david.vrabel@citrix.com> User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.1.16) Gecko/20110818 Icedove/3.0.11 MIME-Version: 1.0 To: "Christopher S. Aker" <caker@theshore.net> Subject: Re: [Xen-devel] vmalloc_sync_all() patch problems? References: <4E832F1A.3030209@theshore.net> <4E83330A.3030509@citrix.com> <4E834519.3090300@theshore.net> In-Reply-To: <4E834519.3090300@theshore.net> Content-Type: text/plain; charset="ISO-8859-1" Content-Transfer-Encoding: 7bit Cc: xen devel <xen-devel@lists.xensource.com>, David Vrabel <david.vrabel@citrix.com> X-BeenThere: xen-devel@lists.xensource.com X-Mailman-Version: 2.1.5 Precedence: list List-Id: Xen developer discussion <xen-devel.lists.xensource.com> List-Unsubscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe> List-Post: <mailto:xen-devel@lists.xensource.com> List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help> List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=subscribe> Sender: xen-devel-bounces@lists.xensource.com Errors-To: xen-devel-bounces@lists.xensource.com On 28/09/11 17:02, Christopher S. Aker wrote: > On 9/28/11 10:45 AM, David Vrabel wrote: >> You're going to have to provide more information on your system and >> tests I think. > > Nothing crazy. 64 bit Xen, 32 bit dom0, my test suite creates many > domUs (in this case about 40) each with a root image and swap image. > Some swap thrash, some spin cpu, some are repeatedly shut down or xm > destroyed. No networking. This particular box has about 32G in it, and > itself and many other boxes identical to it have no problem with our old > stack (xen 3.4, 2.6.18 dom0). > > I've restarted the tests to see if I can reproduce, but I'm certain that > if it happened once, it'll happen again. Instead of the vmalloc_sync_all() patch you could try this series instead. http://lists.xensource.com/archives/html/xen-devel/2011-09/msg01343.html David _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel From xen-devel-bounces@lists.xensource.com Wed Sep 28 10:18:45 2011 Return-path: <xen-devel-bounces@lists.xensource.com> Envelope-to: www-data@lists.xensource.com Delivery-date: Wed, 28 Sep 2011 10:18:45 -0700 Received: from localhost ([127.0.0.1] helo=lists.colo.xensource.com) by lists.xensource.com with esmtp (Exim 4.43) id 1R8xmO-00021s-6v; Wed, 28 Sep 2011 10:18:44 -0700 Received: from mail182.messagelabs.com ([85.158.139.83]) by lists.xensource.com with esmtp (Exim 4.43) id 1R8xlh-0001oX-IB for xen-devel@lists.xensource.com; Wed, 28 Sep 2011 10:18:01 -0700 X-Env-Sender: jeremy@goop.org X-Msg-Ref: server-12.tower-182.messagelabs.com!1317230276!19960306!1 X-Originating-IP: [74.207.240.146] X-StarScan-Version: 6.4.1; banners=-,-,- X-VirusChecked: Checked Received: (qmail 23765 invoked from network); 28 Sep 2011 17:17:58 -0000 Received: from claw.goop.org (HELO claw.goop.org) (74.207.240.146) by server-12.tower-182.messagelabs.com with DHE-RSA-AES256-SHA encrypted SMTP; 28 Sep 2011 17:17:58 -0000 Received: from saboo.goop.org (unknown [IPv6:2001:470:1f05:899:d0d6:81ff:fe76:ec4e]) (Authenticated sender: smtp-saboo) by claw.goop.org (Postfix) with ESMTPSA id E63F787D8; Wed, 28 Sep 2011 10:17:55 -0700 (PDT) Received: from saboo.goop.org (localhost [IPv6:::1]) by saboo.goop.org (Postfix) with ESMTP id B5B9120F30; Wed, 28 Sep 2011 09:47:54 -0700 (PDT) Message-ID: <4E834FBA.1080709@goop.org> Date: Wed, 28 Sep 2011 09:47:54 -0700 From: Jeremy Fitzhardinge <jeremy@goop.org> User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:6.0.2) Gecko/20110906 Thunderbird/6.0.2 MIME-Version: 1.0 To: Linus Torvalds <torvalds@linux-foundation.org> Subject: Re: [Xen-devel] [PATCH 00/10] [PATCH RFC V2] Paravirtualized ticketlocks References: <cover.1315878463.git.jeremy.fitzhardinge@citrix.com> <3300108.XQUp9Wrktc@chlor> <4E81FD52.50106@goop.org> <CA+55aFx7dv4C4ZB_3CFjdJmX_wpoxecpqo1ARYr1=zTVP=CVVA@mail.gmail.com> <4E835F8C0200007800058461@nat28.tlf.novell.com> <CA+55aFyVoZpZZp7ejypTv21Cx_qJWkZQdpJOnxBa_jUxsCjhuw@mail.gmail.com> In-Reply-To: <CA+55aFyVoZpZZp7ejypTv21Cx_qJWkZQdpJOnxBa_jUxsCjhuw@mail.gmail.com> X-Enigmail-Version: 1.3.2 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: Jeremy Fitzhardinge <jeremy.fitzhardinge@citrix.com>, Nick Piggin <npiggin@kernel.dk>, KVM <kvm@vger.kernel.org>, Peter Zijlstra <peterz@infradead.org>, the arch/x86 maintainers <x86@kernel.org>, Linux Kernel Mailing List <linux-kernel@vger.kernel.org>, Marcelo Tosatti <mtosatti@redhat.com>, Andi Kleen <andi@firstfloor.org>, Avi Kivity <avi@redhat.com>, Jan Beulich <JBeulich@suse.com>, "H. Peter Anvin" <hpa@zytor.com>, Ingo Molnar <mingo@elte.hu>, xen-devel@lists.xensource.com, Stephan Diestelhorst <stephan.diestelhorst@amd.com> X-BeenThere: xen-devel@lists.xensource.com X-Mailman-Version: 2.1.5 Precedence: list List-Id: Xen developer discussion <xen-devel.lists.xensource.com> List-Unsubscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe> List-Post: <mailto:xen-devel@lists.xensource.com> List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help> List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=subscribe> Sender: xen-devel-bounces@lists.xensource.com Errors-To: xen-devel-bounces@lists.xensource.com On 09/28/2011 09:10 AM, Linus Torvalds wrote: > On Wed, Sep 28, 2011 at 8:55 AM, Jan Beulich <JBeulich@suse.com> wrote: >>> just use "lock xaddw" there too. >> I'm afraid that's not possible, as that might carry from the low 8 bits >> into the upper 8 ones, which must be avoided. > Oh damn, you're right. So I guess the "right" way to do things is with > cmpxchg, but some nasty mfence setup could do it too. Could do something like: if (ticket->head >= 254) prev = xadd(&ticket->head_tail, 0xff02); else prev = xadd(&ticket->head_tail, 0x0002); to compensate for the overflow. J _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel From xen-devel-bounces@lists.xensource.com Wed Sep 28 10:20:36 2011 Return-path: <xen-devel-bounces@lists.xensource.com> Envelope-to: www-data@lists.xensource.com Delivery-date: Wed, 28 Sep 2011 10:20:36 -0700 Received: from localhost ([127.0.0.1] helo=lists.colo.xensource.com) by lists.xensource.com with esmtp (Exim 4.43) id 1R8xoC-0002VK-8M; Wed, 28 Sep 2011 10:20:36 -0700 Received: from mail182.messagelabs.com ([85.158.139.83]) by lists.xensource.com with esmtp (Exim 4.43) id 1R8xli-0001oY-BV for xen-devel@lists.xensource.com; Wed, 28 Sep 2011 10:18:02 -0700 X-Env-Sender: jeremy@goop.org X-Msg-Ref: server-13.tower-182.messagelabs.com!1317230277!19963205!1 X-Originating-IP: [74.207.240.146] X-StarScan-Version: 6.4.1; banners=-,-,- X-VirusChecked: Checked Received: (qmail 12047 invoked from network); 28 Sep 2011 17:17:59 -0000 Received: from claw.goop.org (HELO claw.goop.org) (74.207.240.146) by server-13.tower-182.messagelabs.com with DHE-RSA-AES256-SHA encrypted SMTP; 28 Sep 2011 17:17:59 -0000 Received: from saboo.goop.org (unknown [IPv6:2001:470:1f05:899:d0d6:81ff:fe76:ec4e]) (Authenticated sender: smtp-saboo) by claw.goop.org (Postfix) with ESMTPSA id BABF38803; Wed, 28 Sep 2011 10:17:56 -0700 (PDT) Received: from saboo.goop.org (localhost [IPv6:::1]) by saboo.goop.org (Postfix) with ESMTP id B91F72026C; Wed, 28 Sep 2011 09:44:25 -0700 (PDT) Message-ID: <4E834EE9.70102@goop.org> Date: Wed, 28 Sep 2011 09:44:25 -0700 From: Jeremy Fitzhardinge <jeremy@goop.org> User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:6.0.2) Gecko/20110906 Thunderbird/6.0.2 MIME-Version: 1.0 To: Stephan Diestelhorst <stephan.diestelhorst@amd.com> Subject: Re: [Xen-devel] [PATCH 00/10] [PATCH RFC V2] Paravirtualized ticketlocks References: <cover.1315878463.git.jeremy.fitzhardinge@citrix.com> <3300108.XQUp9Wrktc@chlor> <4E81FD52.50106@goop.org> <33782147.oLTY4kzH1r@chlor> In-Reply-To: <33782147.oLTY4kzH1r@chlor> X-Enigmail-Version: 1.3.2 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>, Nick Piggin <npiggin@kernel.dk>, KVM <kvm@vger.kernel.org>, Peter Zijlstra <peterz@infradead.org>, Marcelo Tosatti <mtosatti@redhat.com>, the arch/x86 maintainers <x86@kernel.org>, Linux Kernel Mailing List <linux-kernel@vger.kernel.org>, Jan Beulich <JBeulich@suse.com>, Andi Kleen <andi@firstfloor.org>, Avi Kivity <avi@redhat.com>, Jeremy Fitzhardinge <jeremy.fitzhardinge@citrix.com>, "H. Peter Anvin" <hpa@zytor.com>, Ingo Molnar <mingo@elte.hu>, Linus Torvalds <torvalds@linux-foundation.org> X-BeenThere: xen-devel@lists.xensource.com X-Mailman-Version: 2.1.5 Precedence: list List-Id: Xen developer discussion <xen-devel.lists.xensource.com> List-Unsubscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe> List-Post: <mailto:xen-devel@lists.xensource.com> List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help> List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=subscribe> Sender: xen-devel-bounces@lists.xensource.com Errors-To: xen-devel-bounces@lists.xensource.com On 09/28/2011 06:58 AM, Stephan Diestelhorst wrote: > I have tested this and have not seen it fail on publicly released AMD > systems. But as I have tried to point out, this does not mean it is > safe to do in software, because future microarchtectures may have more > capable forwarding engines. Sure. >> Have you tested this, or is this just from code analysis (which I >> agree with after reviewing the ordering rules in the Intel manual). > We have found a similar issue in Novell's PV ticket lock implementation > during internal product testing. Jan may have picked it up from an earlier set of my patches. >>> Since you want to get that addb out to global memory before the second >>> read, either use a LOCK prefix for it, add an MFENCE between addb and >>> movzwl, or use a LOCKed instruction that will have a fencing effect >>> (e.g., to top-of-stack)between addb and movzwl. >> Hm. I don't really want to do any of those because it will probably >> have a significant effect on the unlock performance; I was really trying >> to avoid adding any more locked instructions. A previous version of the >> code had an mfence in here, but I hit on the idea of using aliasing to >> get the ordering I want - but overlooked the possible effect of store >> forwarding. > Well, I'd be curious about the actual performance impact. If the store > needs to commit to memory due to aliasing anyways, this would slow down > execution, too. After all it is better to write working than fast code, > no? ;-) Rule of thumb is that AMD tends to do things like lock and fence more efficiently than Intel - at least historically. I don't know if that's still true for current Intel microarchitectures. >> I guess it comes down to throwing myself on the efficiency of some kind >> of fence instruction. I guess an lfence would be sufficient; is that >> any more efficient than a full mfence? > An lfence should not be sufficient, since that essentially is a NOP on > WB memory. You really want a full fence here, since the store needs to > be published before reading the lock with the next load. The Intel manual reads: Reads cannot pass earlier LFENCE and MFENCE instructions. Writes cannot pass earlier LFENCE, SFENCE, and MFENCE instructions. LFENCE instructions cannot pass earlier reads. Which I interpreted as meaning that an lfence would prevent forwarding. But I guess it doesn't say "lfence instructions cannot pass earlier writes", which means that the lfence could logically happen before the write, thereby allowing forwarding? Or should I be reading this some other way? >> Could you give me a pointer to AMD's description of the ordering rules? > They should be in "AMD64 Architecture Programmer's Manual Volume 2: > System Programming", Section 7.2 Multiprocessor Memory Access Ordering. > > http://developer.amd.com/documentation/guides/pages/default.aspx#manuals > > Let me know if you have some clarifying suggestions. We are currently > revising these documents... I find the English descriptions of these kinds of things frustrating to read because of ambiguities in the precise meaning of words like "pass", "ahead", "behind" in these contexts. I find the prose useful to get an overview, but when I have a specific question I wonder if something more formal would be useful. I guess it's implied that anything that is not prohibited by the ordering rules is allowed, but it wouldn't hurt to say it explicitly. That said, the AMD description seems clearer and more explicit than the Intel manual (esp since it specifically discusses the problem here). Thanks, J _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel From xen-devel-bounces@lists.xensource.com Wed Sep 28 10:23:27 2011 Return-path: <xen-devel-bounces@lists.xensource.com> Envelope-to: www-data@lists.xensource.com Delivery-date: Wed, 28 Sep 2011 10:23:27 -0700 Received: from localhost ([127.0.0.1] helo=lists.colo.xensource.com) by lists.xensource.com with esmtp (Exim 4.43) id 1R8xqx-000334-JK; Wed, 28 Sep 2011 10:23:27 -0700 Received: from mail216.messagelabs.com ([85.158.143.99]) by lists.xensource.com with esmtp (Exim 4.43) id 1R8xqM-0002pJ-C3 for xen-devel@lists.xensource.com; Wed, 28 Sep 2011 10:22:51 -0700 X-Env-Sender: Ian.Jackson@eu.citrix.com X-Msg-Ref: server-9.tower-216.messagelabs.com!1317230567!19924551!1 X-Originating-IP: [62.200.22.115] X-StarScan-Version: 6.4.1; banners=-,-,- X-VirusChecked: Checked Received: (qmail 12589 invoked from network); 28 Sep 2011 17:22:47 -0000 Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115) by server-9.tower-216.messagelabs.com with RC4-SHA encrypted SMTP; 28 Sep 2011 17:22:47 -0000 X-IronPort-AV: E=Sophos;i="4.68,456,1312156800"; d="scan'208";a="8111703" Received: from lonpmailmx01.citrite.net ([10.30.203.162]) by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5; 28 Sep 2011 17:22:47 +0000 Received: from woking.xci-test.com (10.80.248.135) by smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id 8.3.137.0; Wed, 28 Sep 2011 18:22:47 +0100 Received: from osstest by woking.xci-test.com with local (Exim 4.69) (envelope-from <ian.jackson@eu.citrix.com>) id 1R8xqI-0004ym-M7; Wed, 28 Sep 2011 18:22:46 +0100 To: xen-devel@lists.xensource.com Message-ID: <osstest-9111-mainreport@xen.org> From: xen.org <ian.jackson@eu.citrix.com> Date: Wed, 28 Sep 2011 18:22:46 +0100 MIME-Version: 1.0 Content-Type: text/plain Cc: ian.jackson@eu.citrix.com Subject: [Xen-devel] [xen-unstable test] 9111: regressions - trouble: broken/fail/pass X-BeenThere: xen-devel@lists.xensource.com X-Mailman-Version: 2.1.5 Precedence: list List-Id: Xen developer discussion <xen-devel.lists.xensource.com> List-Unsubscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe> List-Post: <mailto:xen-devel@lists.xensource.com> List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help> List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=subscribe> Sender: xen-devel-bounces@lists.xensource.com Errors-To: xen-devel-bounces@lists.xensource.com flight 9111 xen-unstable real [real] http://www.chiark.greenend.org.uk/~xensrcts/logs/9111/ Regressions :-( Tests which did not succeed and are blocking: test-amd64-amd64-xl-sedf 14 guest-localmigrate/x10 fail REGR. vs. 9110 test-amd64-amd64-xl 3 host-install(3) broken Tests which did not succeed, but are not blocking, including regressions (tests previously passed) regarded as allowable: test-amd64-amd64-xl-pcipt-intel 9 guest-start fail never pass test-amd64-i386-rhel6hvm-intel 9 guest-start.2 fail never pass test-amd64-i386-win-vcpus1 16 leak-check/check fail never pass test-amd64-i386-rhel6hvm-amd 9 guest-start.2 fail never pass test-amd64-i386-xl-win-vcpus1 13 guest-stop fail never pass test-amd64-i386-win 16 leak-check/check fail never pass test-amd64-amd64-win 16 leak-check/check fail never pass test-amd64-amd64-xl-win 13 guest-stop fail never pass test-i386-i386-win 16 leak-check/check fail never pass test-i386-i386-xl-win 13 guest-stop fail never pass version targeted for testing: xen 59c7213b5949 baseline version: xen bfa65eb40b2a ------------------------------------------------------------ People who touched revisions under test: Andreas Olsowski <andreas.olsowski@leuphana.de> Ian Campbell <ian.campbell@citrix.com> Ian Jackson <ian.jackson@eu.citrix.com> Olaf Hering <olaf@aepfle.de> ------------------------------------------------------------ jobs: build-amd64 pass build-i386 pass build-amd64-oldkern pass build-i386-oldkern pass build-amd64-pvops pass build-i386-pvops pass test-amd64-amd64-xl broken test-amd64-i386-xl pass test-i386-i386-xl pass test-amd64-i386-rhel6hvm-amd fail test-amd64-i386-xl-credit2 pass test-amd64-amd64-xl-pcipt-intel fail test-amd64-i386-rhel6hvm-intel fail test-amd64-i386-xl-multivcpu pass test-amd64-amd64-pair pass test-amd64-i386-pair pass test-i386-i386-pair pass test-amd64-amd64-pv pass test-amd64-i386-pv pass test-i386-i386-pv pass test-amd64-amd64-xl-sedf fail test-amd64-i386-win-vcpus1 fail test-amd64-i386-xl-win-vcpus1 fail test-amd64-amd64-win fail test-amd64-i386-win fail test-i386-i386-win fail test-amd64-amd64-xl-win fail test-i386-i386-xl-win fail ------------------------------------------------------------ sg-report-flight on woking.cam.xci-test.com logs: /home/xc_osstest/logs images: /home/xc_osstest/images Logs, config files, etc. are available at http://www.chiark.greenend.org.uk/~xensrcts/logs Test harness code can be found at http://xenbits.xensource.com/gitweb?p=osstest.git;a=summary Not pushing. ------------------------------------------------------------ changeset: 23878:59c7213b5949 tag: tip user: Ian Campbell <ian.campbell@citrix.com> date: Tue Sep 27 18:39:15 2011 +0100 libxl: do not try to redo incoming migration on reboot of migrated domain After a migration, reboot was trying to receive another incoming migration, instead of restarting the domain it already has. Signed-off-by: Ian Jackson <ian.jackson@eu.citrix.com> Tested-by: Andreas Olsowski <andreas.olsowski@leuphana.de> Committed-by: Ian Jackson <ian.jackson@eu.citrix.com> changeset: 23877:bfa65eb40b2a user: Ian Campbell <ian.campbell@citrix.com> date: Tue Sep 27 18:03:11 2011 +0100 libxl: make libxl__wait_for_device_model use libxl__spawn_starrting directly Instead of indirecting via libxl_device_model_starting. This fixes a segmentation fault using stubdomains where starting->for_spawn is (validly) NULL because starting a stubdom doesn't need to spawn a process. Most callers of libxl__wait_for_device_model already pass NULL for this variable (because they are not on the starting path) so on libxl__confirm_device_model_startup needs to change. Reported-by: Jeremy Fitzhardinge <jeremy@goop.org> Signed-off-by: Ian Campbell <ian.campbell@citrix.com> Acked-by: Ian Jackson <ian.jackson@eu.citrix.com> Committed-by: Ian Jackson <ian.jackson@eu.citrix.com> ======================================== commit cd776ee9408ff127f934a707c1a339ee600bc127 Author: Ian Jackson <ian.jackson@eu.citrix.com> Date: Tue Jun 28 13:50:53 2011 +0100 qemu-char.c: fix incorrect CONFIG_STUBDOM handling qemu-char.c:1123:7: warning: "CONFIG_STUBDOM" is not defined [-Wundef] Signed-off-by: Olaf Hering <olaf@aepfle.de> Acked-by: Ian Jackson <ian.jackson@eu.citrix.com> _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel From xen-devel-bounces@lists.xensource.com Wed Sep 28 10:24:19 2011 Return-path: <xen-devel-bounces@lists.xensource.com> Envelope-to: www-data@lists.xensource.com Delivery-date: Wed, 28 Sep 2011 10:24:19 -0700 Received: from localhost ([127.0.0.1] helo=lists.colo.xensource.com) by lists.xensource.com with esmtp (Exim 4.43) id 1R8xrn-0003SG-OA; Wed, 28 Sep 2011 10:24:19 -0700 Received: from mail21.messagelabs.com ([85.158.143.35]) by lists.xensource.com with esmtp (Exim 4.43) id 1R8xqp-0002yf-9o for xen-devel@lists.xensource.com; Wed, 28 Sep 2011 10:23:20 -0700 X-Env-Sender: linus971@gmail.com X-Msg-Ref: server-12.tower-21.messagelabs.com!1317230580!51711600!1 X-Originating-IP: [74.125.82.171] X-StarScan-Version: 6.4.1; banners=-,-,- X-VirusChecked: Checked Received: (qmail 32144 invoked from network); 28 Sep 2011 17:23:00 -0000 Received: from mail-wy0-f171.google.com (HELO mail-wy0-f171.google.com) (74.125.82.171) by server-12.tower-21.messagelabs.com with RC4-SHA encrypted SMTP; 28 Sep 2011 17:23:00 -0000 Received: by wyh13 with SMTP id 13so321459wyh.30 for <xen-devel@lists.xensource.com>; Wed, 28 Sep 2011 10:23:16 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:sender:in-reply-to:references:from:date :x-google-sender-auth:message-id:subject:to:cc:content-type :content-transfer-encoding; bh=neAjlAxHWFbVkdl/7Dh43B9N5O3NbjpZPdytDlqdhHQ=; b=CIxtQgBayqpBtZwRf70rxioF0GwUjlAuw6lhYvGLfzuLt1oGheVGK2dzu8qvV/1vOH AG23qZ66rRxTq3JkglZnbSP2kyV2BnM4gOAZvlXrUkXuxUmH/TA41QaQjEOu4+MJNrOk HSwHyfAsqTvp1HaD0wNY1RsUuP6TNA3Q4x3+8= Received: by 10.216.134.100 with SMTP id r78mr3022542wei.108.1317230596088; Wed, 28 Sep 2011 10:23:16 -0700 (PDT) MIME-Version: 1.0 Received: by 10.216.11.12 with HTTP; Wed, 28 Sep 2011 10:22:56 -0700 (PDT) In-Reply-To: <4E834FBA.1080709@goop.org> References: <cover.1315878463.git.jeremy.fitzhardinge@citrix.com> <3300108.XQUp9Wrktc@chlor> <4E81FD52.50106@goop.org> <CA+55aFx7dv4C4ZB_3CFjdJmX_wpoxecpqo1ARYr1=zTVP=CVVA@mail.gmail.com> <4E835F8C0200007800058461@nat28.tlf.novell.com> <CA+55aFyVoZpZZp7ejypTv21Cx_qJWkZQdpJOnxBa_jUxsCjhuw@mail.gmail.com> <4E834FBA.1080709@goop.org> From: Linus Torvalds <torvalds@linux-foundation.org> Date: Wed, 28 Sep 2011 10:22:56 -0700 X-Google-Sender-Auth: iVnfVLDx5k2y48QFCo9e991pa5g Message-ID: <CA+55aFzGZp8YaQMMUMwV+pd_vnqR14CtiTmTtkXuotQBg0zspg@mail.gmail.com> Subject: Re: [Xen-devel] [PATCH 00/10] [PATCH RFC V2] Paravirtualized ticketlocks To: Jeremy Fitzhardinge <jeremy@goop.org> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: Jeremy Fitzhardinge <jeremy.fitzhardinge@citrix.com>, Nick Piggin <npiggin@kernel.dk>, KVM <kvm@vger.kernel.org>, Peter Zijlstra <peterz@infradead.org>, the arch/x86 maintainers <x86@kernel.org>, Linux Kernel Mailing List <linux-kernel@vger.kernel.org>, Marcelo Tosatti <mtosatti@redhat.com>, Andi Kleen <andi@firstfloor.org>, Avi Kivity <avi@redhat.com>, Jan Beulich <JBeulich@suse.com>, "H. Peter Anvin" <hpa@zytor.com>, Ingo Molnar <mingo@elte.hu>, xen-devel@lists.xensource.com, Stephan Diestelhorst <stephan.diestelhorst@amd.com> X-BeenThere: xen-devel@lists.xensource.com X-Mailman-Version: 2.1.5 Precedence: list List-Id: Xen developer discussion <xen-devel.lists.xensource.com> List-Unsubscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe> List-Post: <mailto:xen-devel@lists.xensource.com> List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help> List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=subscribe> Sender: xen-devel-bounces@lists.xensource.com Errors-To: xen-devel-bounces@lists.xensource.com On Wed, Sep 28, 2011 at 9:47 AM, Jeremy Fitzhardinge <jeremy@goop.org> wrot= e: > > Could do something like: > > =A0 =A0 =A0 =A0if (ticket->head >=3D 254) > =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0prev =3D xadd(&ticket->head_tail, 0xff02); > =A0 =A0 =A0 =A0else > =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0prev =3D xadd(&ticket->head_tail, 0x0002); > > to compensate for the overflow. Oh wow. You havge an even more twisted mind than I do. I guess that will work, exactly because we control "head" and thus can know about the overflow in the low byte. But boy is that ugly ;) But at least you wouldn't need to do the loop with cmpxchg. So it's twisted and ugly, but migth be practical. Linus _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel From xen-devel-bounces@lists.xensource.com Wed Sep 28 10:28:41 2011 Return-path: <xen-devel-bounces@lists.xensource.com> Envelope-to: www-data@lists.xensource.com Delivery-date: Wed, 28 Sep 2011 10:28:41 -0700 Received: from localhost ([127.0.0.1] helo=lists.colo.xensource.com) by lists.xensource.com with esmtp (Exim 4.43) id 1R8xw1-0003sP-5l; Wed, 28 Sep 2011 10:28:41 -0700 Received: from mail174.messagelabs.com ([85.158.138.51]) by lists.xensource.com with esmtp (Exim 4.43) id 1R8xvM-0003fZ-61 for xen-devel@lists.xensource.com; Wed, 28 Sep 2011 10:28:00 -0700 X-Env-Sender: jeremy@goop.org X-Msg-Ref: server-7.tower-174.messagelabs.com!1317230875!33105303!1 X-Originating-IP: [74.207.240.146] X-StarScan-Version: 6.4.1; banners=-,-,- X-VirusChecked: Checked Received: (qmail 5465 invoked from network); 28 Sep 2011 17:27:57 -0000 Received: from claw.goop.org (HELO claw.goop.org) (74.207.240.146) by server-7.tower-174.messagelabs.com with DHE-RSA-AES256-SHA encrypted SMTP; 28 Sep 2011 17:27:57 -0000 Received: from saboo.goop.org (unknown [IPv6:2001:470:1f05:899:d0d6:81ff:fe76:ec4e]) (Authenticated sender: smtp-saboo) by claw.goop.org (Postfix) with ESMTPSA id E86608814; Wed, 28 Sep 2011 10:27:54 -0700 (PDT) Received: from saboo.goop.org (localhost [IPv6:::1]) by saboo.goop.org (Postfix) with ESMTP id C716920983; Wed, 28 Sep 2011 09:50:18 -0700 (PDT) Message-ID: <4E83504A.5070008@goop.org> Date: Wed, 28 Sep 2011 09:50:18 -0700 From: Jeremy Fitzhardinge <jeremy@goop.org> User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:6.0.2) Gecko/20110906 Thunderbird/6.0.2 MIME-Version: 1.0 To: George Dunlap <George.Dunlap@eu.citrix.com> Subject: Re: [Xen-devel] Re: MSI error when reloading iwlagn module References: <4E822AA6.4010605@goop.org> <4E82F7F10200007800058259@nat28.tlf.novell.com> <4E8312C4020000780005829C@nat28.tlf.novell.com> <CAFLBxZZjVxybmt7BEi3BNSLysdruRHonKPmH00MihCLjri6Khg@mail.gmail.com> In-Reply-To: <CAFLBxZZjVxybmt7BEi3BNSLysdruRHonKPmH00MihCLjri6Khg@mail.gmail.com> X-Enigmail-Version: 1.3.2 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: andrew.cooper3@citrix.com, "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>, Jan Beulich <JBeulich@suse.com>, Konrad Rzeszutek Wilk <konrad.wilk@oracle.com> X-BeenThere: xen-devel@lists.xensource.com X-Mailman-Version: 2.1.5 Precedence: list List-Id: Xen developer discussion <xen-devel.lists.xensource.com> List-Unsubscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe> List-Post: <mailto:xen-devel@lists.xensource.com> List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help> List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=subscribe> Sender: xen-devel-bounces@lists.xensource.com Errors-To: xen-devel-bounces@lists.xensource.com On 09/28/2011 04:07 AM, George Dunlap wrote: > Actually, I think the patch I sent shouldn't have any effect on Intel > systems, unless you've expicitly enabled one of the irq vector map > options on your Xen command line. All I have on my xen command line is "cpufreq=xen iommu=pv". J _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel From xen-devel-bounces@lists.xensource.com Wed Sep 28 10:32:42 2011 Return-path: <xen-devel-bounces@lists.xensource.com> Envelope-to: www-data@lists.xensource.com Delivery-date: Wed, 28 Sep 2011 10:32:42 -0700 Received: from localhost ([127.0.0.1] helo=lists.colo.xensource.com) by lists.xensource.com with esmtp (Exim 4.43) id 1R8xzt-0004Ke-VM; Wed, 28 Sep 2011 10:32:42 -0700 Received: from mail182.messagelabs.com ([85.158.139.83]) by lists.xensource.com with esmtp (Exim 4.43) id 1R8xyt-00045X-TA for xen-devel@lists.xensource.com; Wed, 28 Sep 2011 10:31:40 -0700 X-Env-Sender: hpa@zytor.com X-Msg-Ref: server-3.tower-182.messagelabs.com!1317231095!17319986!1 X-Originating-IP: [198.137.202.10] X-StarScan-Version: 6.4.1; banners=-,-,- X-VirusChecked: Checked Received: (qmail 2981 invoked from network); 28 Sep 2011 17:31:36 -0000 Received: from terminus.zytor.com (HELO mail.zytor.com) (198.137.202.10) by server-3.tower-182.messagelabs.com with DHE-RSA-AES256-SHA encrypted SMTP; 28 Sep 2011 17:31:36 -0000 Received: from tazenda.hos.anvin.org ([IPv6:2001:470:861f::feed:face:f00d]) (authenticated bits=0) by mail.zytor.com (8.14.5/8.14.5) with ESMTP id p8SHOc9D020479 (version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NO); Wed, 28 Sep 2011 10:24:39 -0700 Message-ID: <4E835851.7070502@zytor.com> Date: Wed, 28 Sep 2011 10:24:33 -0700 From: "H. Peter Anvin" <hpa@zytor.com> User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:6.0.2) Gecko/20110906 Thunderbird/6.0.2 MIME-Version: 1.0 To: Linus Torvalds <torvalds@linux-foundation.org> Subject: Re: [Xen-devel] [PATCH 00/10] [PATCH RFC V2] Paravirtualized ticketlocks References: <cover.1315878463.git.jeremy.fitzhardinge@citrix.com> <3300108.XQUp9Wrktc@chlor> <4E81FD52.50106@goop.org> <CA+55aFx7dv4C4ZB_3CFjdJmX_wpoxecpqo1ARYr1=zTVP=CVVA@mail.gmail.com> <4E835F8C0200007800058461@nat28.tlf.novell.com> <CA+55aFyVoZpZZp7ejypTv21Cx_qJWkZQdpJOnxBa_jUxsCjhuw@mail.gmail.com> <4E834FBA.1080709@goop.org> <CA+55aFzGZp8YaQMMUMwV+pd_vnqR14CtiTmTtkXuotQBg0zspg@mail.gmail.com> In-Reply-To: <CA+55aFzGZp8YaQMMUMwV+pd_vnqR14CtiTmTtkXuotQBg0zspg@mail.gmail.com> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Cc: Jeremy Fitzhardinge <jeremy@goop.org>, Jeremy Fitzhardinge <jeremy.fitzhardinge@citrix.com>, Nick Piggin <npiggin@kernel.dk>, KVM <kvm@vger.kernel.org>, Peter Zijlstra <peterz@infradead.org>, the arch/x86 maintainers <x86@kernel.org>, Linux Kernel Mailing List <linux-kernel@vger.kernel.org>, Marcelo Tosatti <mtosatti@redhat.com>, Andi Kleen <andi@firstfloor.org>, Avi Kivity <avi@redhat.com>, Jan Beulich <JBeulich@suse.com>, Ingo Molnar <mingo@elte.hu>, xen-devel@lists.xensource.com, Stephan Diestelhorst <stephan.diestelhorst@amd.com> X-BeenThere: xen-devel@lists.xensource.com X-Mailman-Version: 2.1.5 Precedence: list List-Id: Xen developer discussion <xen-devel.lists.xensource.com> List-Unsubscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe> List-Post: <mailto:xen-devel@lists.xensource.com> List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help> List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=subscribe> Sender: xen-devel-bounces@lists.xensource.com Errors-To: xen-devel-bounces@lists.xensource.com On 09/28/2011 10:22 AM, Linus Torvalds wrote: > On Wed, Sep 28, 2011 at 9:47 AM, Jeremy Fitzhardinge <jeremy@goop.org> wrote: >> >> Could do something like: >> >> if (ticket->head >= 254) >> prev = xadd(&ticket->head_tail, 0xff02); >> else >> prev = xadd(&ticket->head_tail, 0x0002); >> >> to compensate for the overflow. > > Oh wow. You havge an even more twisted mind than I do. > > I guess that will work, exactly because we control "head" and thus can > know about the overflow in the low byte. But boy is that ugly ;) > > But at least you wouldn't need to do the loop with cmpxchg. So it's > twisted and ugly, but migth be practical. > I suspect it should be coded as -254 in order to use a short immediate if that is even possible... -hpa -- H. Peter Anvin, Intel Open Source Technology Center I work for Intel. I don't speak on their behalf. _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel From xen-devel-bounces@lists.xensource.com Wed Sep 28 10:51:17 2011 Return-path: <xen-devel-bounces@lists.xensource.com> Envelope-to: www-data@lists.xensource.com Delivery-date: Wed, 28 Sep 2011 10:51:17 -0700 Received: from localhost ([127.0.0.1] helo=lists.colo.xensource.com) by lists.xensource.com with esmtp (Exim 4.43) id 1R8yHt-0005TZ-AW; Wed, 28 Sep 2011 10:51:17 -0700 Received: from mail182.messagelabs.com ([85.158.139.83]) by lists.xensource.com with esmtp (Exim 4.43) id 1R8yGx-0005FZ-26 for xen-devel@lists.xensource.com; Wed, 28 Sep 2011 10:50:19 -0700 X-Env-Sender: jeremy@goop.org X-Msg-Ref: server-5.tower-182.messagelabs.com!1317232214!15142982!1 X-Originating-IP: [74.207.240.146] X-StarScan-Version: 6.4.1; banners=-,-,- X-VirusChecked: Checked Received: (qmail 909 invoked from network); 28 Sep 2011 17:50:16 -0000 Received: from claw.goop.org (HELO claw.goop.org) (74.207.240.146) by server-5.tower-182.messagelabs.com with DHE-RSA-AES256-SHA encrypted SMTP; 28 Sep 2011 17:50:16 -0000 Received: from saboo.goop.org (unknown [IPv6:2001:470:1f05:899:d0d6:81ff:fe76:ec4e]) (Authenticated sender: smtp-saboo) by claw.goop.org (Postfix) with ESMTPSA id C2A338911; Wed, 28 Sep 2011 10:50:12 -0700 (PDT) Received: from saboo.goop.org (localhost [IPv6:::1]) by saboo.goop.org (Postfix) with ESMTP id D4FAB20212; Wed, 28 Sep 2011 10:50:08 -0700 (PDT) Message-ID: <4E835E50.2020307@goop.org> Date: Wed, 28 Sep 2011 10:50:08 -0700 From: Jeremy Fitzhardinge <jeremy@goop.org> User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:6.0.2) Gecko/20110906 Thunderbird/6.0.2 MIME-Version: 1.0 To: "H. Peter Anvin" <hpa@zytor.com> Subject: Re: [Xen-devel] [PATCH 00/10] [PATCH RFC V2] Paravirtualized ticketlocks References: <cover.1315878463.git.jeremy.fitzhardinge@citrix.com> <3300108.XQUp9Wrktc@chlor> <4E81FD52.50106@goop.org> <CA+55aFx7dv4C4ZB_3CFjdJmX_wpoxecpqo1ARYr1=zTVP=CVVA@mail.gmail.com> <4E835F8C0200007800058461@nat28.tlf.novell.com> <CA+55aFyVoZpZZp7ejypTv21Cx_qJWkZQdpJOnxBa_jUxsCjhuw@mail.gmail.com> <4E834FBA.1080709@goop.org> <CA+55aFzGZp8YaQMMUMwV+pd_vnqR14CtiTmTtkXuotQBg0zspg@mail.gmail.com> <4E835851.7070502@zytor.com> In-Reply-To: <4E835851.7070502@zytor.com> X-Enigmail-Version: 1.3.2 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Cc: Jeremy Fitzhardinge <jeremy.fitzhardinge@citrix.com>, Nick Piggin <npiggin@kernel.dk>, KVM <kvm@vger.kernel.org>, Peter Zijlstra <peterz@infradead.org>, the arch/x86 maintainers <x86@kernel.org>, Linux Kernel Mailing List <linux-kernel@vger.kernel.org>, Marcelo Tosatti <mtosatti@redhat.com>, Andi Kleen <andi@firstfloor.org>, Avi Kivity <avi@redhat.com>, Jan Beulich <JBeulich@suse.com>, Ingo Molnar <mingo@elte.hu>, Linus Torvalds <torvalds@linux-foundation.org>, xen-devel@lists.xensource.com, Stephan Diestelhorst <stephan.diestelhorst@amd.com> X-BeenThere: xen-devel@lists.xensource.com X-Mailman-Version: 2.1.5 Precedence: list List-Id: Xen developer discussion <xen-devel.lists.xensource.com> List-Unsubscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe> List-Post: <mailto:xen-devel@lists.xensource.com> List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help> List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=subscribe> Sender: xen-devel-bounces@lists.xensource.com Errors-To: xen-devel-bounces@lists.xensource.com On 09/28/2011 10:24 AM, H. Peter Anvin wrote: > On 09/28/2011 10:22 AM, Linus Torvalds wrote: >> On Wed, Sep 28, 2011 at 9:47 AM, Jeremy Fitzhardinge <jeremy@goop.org> wrote: >>> Could do something like: >>> >>> if (ticket->head >= 254) >>> prev = xadd(&ticket->head_tail, 0xff02); >>> else >>> prev = xadd(&ticket->head_tail, 0x0002); >>> >>> to compensate for the overflow. >> Oh wow. You havge an even more twisted mind than I do. >> >> I guess that will work, exactly because we control "head" and thus can >> know about the overflow in the low byte. But boy is that ugly ;) >> >> But at least you wouldn't need to do the loop with cmpxchg. So it's >> twisted and ugly, but migth be practical. >> > I suspect it should be coded as -254 in order to use a short immediate > if that is even possible... I'm about to test: static __always_inline void arch_spin_unlock(arch_spinlock_t *lock) { if (TICKET_SLOWPATH_FLAG && unlikely(arch_static_branch(¶virt_ticketlocks_enabled))) { arch_spinlock_t prev; __ticketpair_t inc = TICKET_LOCK_INC; if (lock->tickets.head >= (1 << TICKET_SHIFT) - TICKET_LOCK_INC) inc += -1 << TICKET_SHIFT; prev.head_tail = xadd(&lock->head_tail, inc); if (prev.tickets.tail & TICKET_SLOWPATH_FLAG) __ticket_unlock_slowpath(lock, prev); } else __ticket_unlock_release(lock); } Which, frankly, is not something I particularly want to put my name to. It makes gcc go into paroxysms of trickiness: 4a8: 80 3f fe cmpb $0xfe,(%rdi) 4ab: 19 f6 sbb %esi,%esi 4ad: 66 81 e6 00 01 and $0x100,%si 4b2: 66 81 ee fe 00 sub $0xfe,%si 4b7: f0 66 0f c1 37 lock xadd %si,(%rdi) ...which is pretty neat, actually. J _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel From xen-devel-bounces@lists.xensource.com Wed Sep 28 11:11:22 2011 Return-path: <xen-devel-bounces@lists.xensource.com> Envelope-to: www-data@lists.xensource.com Delivery-date: Wed, 28 Sep 2011 11:11:22 -0700 Received: from localhost ([127.0.0.1] helo=lists.colo.xensource.com) by lists.xensource.com with esmtp (Exim 4.43) id 1R8ybK-0006Bz-0H; Wed, 28 Sep 2011 11:11:22 -0700 Received: from mail21.messagelabs.com ([85.158.143.35]) by lists.xensource.com with esmtp (Exim 4.43) id 1R8ya1-0005xd-46 for xen-devel@lists.xensource.com; Wed, 28 Sep 2011 11:10:01 -0700 X-Env-Sender: Stephan.Diestelhorst@amd.com X-Msg-Ref: server-14.tower-21.messagelabs.com!1317233388!61353508!1 X-Originating-IP: [65.55.88.13] X-StarScan-Version: 6.4.1; banners=-,-,- X-VirusChecked: Checked Received: (qmail 17037 invoked from network); 28 Sep 2011 18:09:49 -0000 Received: from tx2ehsobe003.messaging.microsoft.com (HELO TX2EHSOBE006.bigfish.com) (65.55.88.13) by server-14.tower-21.messagelabs.com with AES128-SHA encrypted SMTP; 28 Sep 2011 18:09:49 -0000 Received: from mail164-tx2-R.bigfish.com (10.9.14.239) by TX2EHSOBE006.bigfish.com (10.9.40.26) with Microsoft SMTP Server id 14.1.225.22; Wed, 28 Sep 2011 18:09:56 +0000 Received: from mail164-tx2 (localhost.localdomain [127.0.0.1]) by mail164-tx2-R.bigfish.com (Postfix) with ESMTP id 9902616F02E6; Wed, 28 Sep 2011 18:09:55 +0000 (UTC) X-SpamScore: -14 X-BigFish: VPS-14(zzbb2dK9371K1432N98dKzz1202hzz8275dhz32i668h839h93fh) X-Forefront-Antispam-Report: CIP:163.181.249.108; KIP:(null); UIP:(null); IPVD:NLI; H:ausb3twp01.amd.com; RD:none; EFVD:NLI X-FB-SS: 0,13, Received: from mail164-tx2 (localhost.localdomain [127.0.0.1]) by mail164-tx2 (MessageSwitch) id 1317233395386262_18952; Wed, 28 Sep 2011 18:09:55 +0000 (UTC) Received: from TX2EHSMHS024.bigfish.com (unknown [10.9.14.254]) by mail164-tx2.bigfish.com (Postfix) with ESMTP id 2770F4B804C; Wed, 28 Sep 2011 18:09:55 +0000 (UTC) Received: from ausb3twp01.amd.com (163.181.249.108) by TX2EHSMHS024.bigfish.com (10.9.99.124) with Microsoft SMTP Server id 14.1.225.22; Wed, 28 Sep 2011 18:09:49 +0000 X-WSS-ID: 0LS8VSB-01-QGO-02 X-M-MSG: Received: from sausexedgep02.amd.com (sausexedgep02-ext.amd.com [163.181.249.73]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by ausb3twp01.amd.com (Axway MailGate 3.8.1) with ESMTP id 227431028399; Wed, 28 Sep 2011 13:09:46 -0500 (CDT) Received: from sausexhtp01.amd.com (163.181.3.165) by sausexedgep02.amd.com (163.181.36.59) with Microsoft SMTP Server (TLS) id 8.3.106.1; Wed, 28 Sep 2011 13:10:00 -0500 Received: from storexhtp01.amd.com (172.24.4.3) by sausexhtp01.amd.com (163.181.3.165) with Microsoft SMTP Server (TLS) id 8.3.83.0; Wed, 28 Sep 2011 13:09:47 -0500 Received: from d-allen.localnet (10.224.148.235) by storexhtp01.amd.com (172.24.4.3) with Microsoft SMTP Server id 8.3.83.0; Wed, 28 Sep 2011 14:08:20 -0400 From: Stephan Diestelhorst <stephan.diestelhorst@amd.com> Organization: AMD OSRC To: Jeremy Fitzhardinge <jeremy@goop.org> Subject: Re: [Xen-devel] [PATCH 00/10] [PATCH RFC V2] Paravirtualized ticketlocks Date: Wed, 28 Sep 2011 20:08:16 +0200 User-Agent: KMail/1.13.6 (Linux/3.0.4-030004-generic; KDE/4.7.1; x86_64; ; ) References: <cover.1315878463.git.jeremy.fitzhardinge@citrix.com> <4E835851.7070502@zytor.com> <4E835E50.2020307@goop.org> In-Reply-To: <4E835E50.2020307@goop.org> MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit Message-ID: <201109282008.17722.stephan.diestelhorst@amd.com> X-OriginatorOrg: amd.com Cc: Fitzhardinge <jeremy.fitzhardinge@citrix.com>, Jeremy, Piggin <npiggin@kernel.dk>, KVM <kvm@vger.kernel.org>, Peter Zijlstra <peterz@infradead.org>, the arch/x86 maintainers <x86@kernel.org>, Linux Kernel Mailing List <linux-kernel@vger.kernel.org>, Marcelo Tosatti <mtosatti@redhat.com>, Nick, Andi Kleen <andi@firstfloor.org>, Avi Kivity <avi@redhat.com>, Jan Beulich <JBeulich@suse.com>, "H. Peter Anvin" <hpa@zytor.com>, Ingo Molnar <mingo@elte.hu>, Linus Torvalds <torvalds@linux-foundation.org>, "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com> X-BeenThere: xen-devel@lists.xensource.com X-Mailman-Version: 2.1.5 Precedence: list List-Id: Xen developer discussion <xen-devel.lists.xensource.com> List-Unsubscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe> List-Post: <mailto:xen-devel@lists.xensource.com> List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help> List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=subscribe> Sender: xen-devel-bounces@lists.xensource.com Errors-To: xen-devel-bounces@lists.xensource.com On Wednesday 28 September 2011 19:50:08 Jeremy Fitzhardinge wrote: > On 09/28/2011 10:24 AM, H. Peter Anvin wrote: > > On 09/28/2011 10:22 AM, Linus Torvalds wrote: > >> On Wed, Sep 28, 2011 at 9:47 AM, Jeremy Fitzhardinge <jeremy@goop.org> wrote: > >>> Could do something like: > >>> > >>> if (ticket->head >= 254) > >>> prev = xadd(&ticket->head_tail, 0xff02); > >>> else > >>> prev = xadd(&ticket->head_tail, 0x0002); > >>> > >>> to compensate for the overflow. > >> Oh wow. You havge an even more twisted mind than I do. > >> > >> I guess that will work, exactly because we control "head" and thus can > >> know about the overflow in the low byte. But boy is that ugly ;) > >> > >> But at least you wouldn't need to do the loop with cmpxchg. So it's > >> twisted and ugly, but migth be practical. > >> > > I suspect it should be coded as -254 in order to use a short immediate > > if that is even possible... > > I'm about to test: > > static __always_inline void arch_spin_unlock(arch_spinlock_t *lock) > { > if (TICKET_SLOWPATH_FLAG && unlikely(arch_static_branch(¶virt_ticketlocks_enabled))) { > arch_spinlock_t prev; > __ticketpair_t inc = TICKET_LOCK_INC; > > if (lock->tickets.head >= (1 << TICKET_SHIFT) - TICKET_LOCK_INC) > inc += -1 << TICKET_SHIFT; > > prev.head_tail = xadd(&lock->head_tail, inc); > > if (prev.tickets.tail & TICKET_SLOWPATH_FLAG) > __ticket_unlock_slowpath(lock, prev); > } else > __ticket_unlock_release(lock); > } > > Which, frankly, is not something I particularly want to put my name to. I must have missed the part when this turned into the propose-the- craziest-way-that-this-still-works.contest :) What is wrong with converting the original addb into a lock addb? The crazy wrap around tricks add a conditional and lots of headache. The lock addb/w is clean. We are paying an atomic in both cases, so I just don't see the benefit of the second solution. Stephan -- Stephan Diestelhorst, AMD Operating System Research Center stephan.diestelhorst@amd.com, Tel. +49 (0)351 448 356 719 Advanced Micro Devices GmbH Einsteinring 24 85609 Aschheim Germany Geschaeftsfuehrer: Alberto Bozzo; Sitz: Dornach, Gemeinde Aschheim, Landkreis Muenchen Registergericht Muenchen, HRB Nr. 43632, WEEE-Reg-Nr: DE 12919551 _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel From xen-devel-bounces@lists.xensource.com Wed Sep 28 11:14:25 2011 Return-path: <xen-devel-bounces@lists.xensource.com> Envelope-to: www-data@lists.xensource.com Delivery-date: Wed, 28 Sep 2011 11:14:25 -0700 Received: from localhost ([127.0.0.1] helo=lists.colo.xensource.com) by lists.xensource.com with esmtp (Exim 4.43) id 1R8yeH-0006cD-DR; Wed, 28 Sep 2011 11:14:25 -0700 Received: from mail182.messagelabs.com ([85.158.139.83]) by lists.xensource.com with esmtp (Exim 4.43) id 1R8ydm-0006Px-Pn for xen-devel@lists.xensource.com; Wed, 28 Sep 2011 11:13:55 -0700 X-Env-Sender: Stephan.Diestelhorst@amd.com X-Msg-Ref: server-6.tower-182.messagelabs.com!1317233630!18920850!1 X-Originating-IP: [216.32.181.185] X-StarScan-Version: 6.4.1; banners=-,-,- X-VirusChecked: Checked Received: (qmail 20846 invoked from network); 28 Sep 2011 18:13:51 -0000 Received: from ch1ehsobe005.messaging.microsoft.com (HELO ch1outboundpool.messaging.microsoft.com) (216.32.181.185) by server-6.tower-182.messagelabs.com with AES128-SHA encrypted SMTP; 28 Sep 2011 18:13:51 -0000 Received: from mail59-ch1-R.bigfish.com (216.32.181.169) by CH1EHSOBE008.bigfish.com (10.43.70.58) with Microsoft SMTP Server id 14.1.225.22; Wed, 28 Sep 2011 18:13:50 +0000 Received: from mail59-ch1 (localhost.localdomain [127.0.0.1]) by mail59-ch1-R.bigfish.com (Postfix) with ESMTP id 3DACF1448350; Wed, 28 Sep 2011 18:13:50 +0000 (UTC) X-SpamScore: -22 X-BigFish: VPS-22(zzbb2dK9371K103dK1521M1432N98dKzz1202hzz8275bhz32i668h839h93fh) X-Forefront-Antispam-Report: CIP:163.181.249.108; KIP:(null); UIP:(null); IPVD:NLI; H:ausb3twp01.amd.com; RD:none; EFVD:NLI X-FB-SS: 13, Received: from mail59-ch1 (localhost.localdomain [127.0.0.1]) by mail59-ch1 (MessageSwitch) id 1317233602908249_3847; Wed, 28 Sep 2011 18:13:22 +0000 (UTC) Received: from CH1EHSMHS011.bigfish.com (snatpool1.int.messaging.microsoft.com [10.43.68.246]) by mail59-ch1.bigfish.com (Postfix) with ESMTP id D56D6145804F; Wed, 28 Sep 2011 18:13:22 +0000 (UTC) Received: from ausb3twp01.amd.com (163.181.249.108) by CH1EHSMHS011.bigfish.com (10.43.70.11) with Microsoft SMTP Server id 14.1.225.22; Wed, 28 Sep 2011 18:13:19 +0000 X-WSS-ID: 0LS8VY4-01-QOR-02 X-M-MSG: Received: from sausexedgep01.amd.com (sausexedgep01-ext.amd.com [163.181.249.72]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by ausb3twp01.amd.com (Axway MailGate 3.8.1) with ESMTP id 221E410283A3; Wed, 28 Sep 2011 13:13:16 -0500 (CDT) Received: from sausexhtp02.amd.com (163.181.3.152) by sausexedgep01.amd.com (163.181.36.54) with Microsoft SMTP Server (TLS) id 8.3.106.1; Wed, 28 Sep 2011 13:13:29 -0500 Received: from storexhtp01.amd.com (172.24.4.3) by sausexhtp02.amd.com (163.181.3.152) with Microsoft SMTP Server (TLS) id 8.3.83.0; Wed, 28 Sep 2011 13:13:17 -0500 Received: from d-allen.localnet (10.224.148.235) by storexhtp01.amd.com (172.24.4.3) with Microsoft SMTP Server id 8.3.83.0; Wed, 28 Sep 2011 14:13:16 -0400 From: Stephan Diestelhorst <stephan.diestelhorst@amd.com> Organization: AMD OSRC To: Jeremy Fitzhardinge <jeremy@goop.org> Subject: Re: [Xen-devel] [PATCH 00/10] [PATCH RFC V2] Paravirtualized ticketlocks Date: Wed, 28 Sep 2011 20:13:10 +0200 User-Agent: KMail/1.13.6 (Linux/3.0.4-030004-generic; KDE/4.7.1; x86_64; ; ) References: <cover.1315878463.git.jeremy.fitzhardinge@citrix.com> <33782147.oLTY4kzH1r@chlor> <4E834EE9.70102@goop.org> In-Reply-To: <4E834EE9.70102@goop.org> MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit Message-ID: <201109282013.11513.stephan.diestelhorst@amd.com> X-OriginatorOrg: amd.com Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>, Piggin <npiggin@kernel.dk>, KVM <kvm@vger.kernel.org>, Linux, Peter Zijlstra <peterz@infradead.org>, Marcelo Tosatti <mtosatti@redhat.com>, the arch/x86 maintainers <x86@kernel.org>, Kernel Mailing List <linux-kernel@vger.kernel.org>, Jan Beulich <JBeulich@suse.com>, Nick, Andi Kleen <andi@firstfloor.org>, Avi Kivity <avi@redhat.com>, Jeremy Fitzhardinge <jeremy.fitzhardinge@citrix.com>, "H. Peter Anvin" <hpa@zytor.com>, Ingo Molnar <mingo@elte.hu>, Linus Torvalds <torvalds@linux-foundation.org> X-BeenThere: xen-devel@lists.xensource.com X-Mailman-Version: 2.1.5 Precedence: list List-Id: Xen developer discussion <xen-devel.lists.xensource.com> List-Unsubscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe> List-Post: <mailto:xen-devel@lists.xensource.com> List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help> List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=subscribe> Sender: xen-devel-bounces@lists.xensource.com Errors-To: xen-devel-bounces@lists.xensource.com On Wednesday 28 September 2011 18:44:25 Jeremy Fitzhardinge wrote: > On 09/28/2011 06:58 AM, Stephan Diestelhorst wrote: > >> I guess it comes down to throwing myself on the efficiency of some kind > >> of fence instruction. I guess an lfence would be sufficient; is that > >> any more efficient than a full mfence? > > An lfence should not be sufficient, since that essentially is a NOP on > > WB memory. You really want a full fence here, since the store needs to > > be published before reading the lock with the next load. > > The Intel manual reads: > > Reads cannot pass earlier LFENCE and MFENCE instructions. > Writes cannot pass earlier LFENCE, SFENCE, and MFENCE instructions. > LFENCE instructions cannot pass earlier reads. > > Which I interpreted as meaning that an lfence would prevent forwarding. > But I guess it doesn't say "lfence instructions cannot pass earlier > writes", which means that the lfence could logically happen before the > write, thereby allowing forwarding? Or should I be reading this some > other way? Indeed. You are reading this the right way. > >> Could you give me a pointer to AMD's description of the ordering rules? > > They should be in "AMD64 Architecture Programmer's Manual Volume 2: > > System Programming", Section 7.2 Multiprocessor Memory Access Ordering. > > > > http://developer.amd.com/documentation/guides/pages/default.aspx#manuals > > > > Let me know if you have some clarifying suggestions. We are currently > > revising these documents... > > I find the English descriptions of these kinds of things frustrating to > read because of ambiguities in the precise meaning of words like "pass", > "ahead", "behind" in these contexts. I find the prose useful to get an > overview, but when I have a specific question I wonder if something more > formal would be useful. It would be, and some have started this efort: http://www.cl.cam.ac.uk/~pes20/weakmemory/ But I am not sure whether that particular nasty forwarding case is captured properly in their model It is on my list of things to check. > I guess it's implied that anything that is not prohibited by the > ordering rules is allowed, but it wouldn't hurt to say it explicitly. > That said, the AMD description seems clearer and more explicit than the > Intel manual (esp since it specifically discusses the problem here). Thanks! Glad you like it :) Stephan -- Stephan Diestelhorst, AMD Operating System Research Center stephan.diestelhorst@amd.com, Tel. +49 (0)351 448 356 719 Advanced Micro Devices GmbH Einsteinring 24 85609 Aschheim Germany Geschaeftsfuehrer: Alberto Bozzo; Sitz: Dornach, Gemeinde Aschheim, Landkreis Muenchen Registergericht Muenchen, HRB Nr. 43632, WEEE-Reg-Nr: DE 12919551 _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel From xen-devel-bounces@lists.xensource.com Wed Sep 28 11:28:38 2011 Return-path: <xen-devel-bounces@lists.xensource.com> Envelope-to: www-data@lists.xensource.com Delivery-date: Wed, 28 Sep 2011 11:28:38 -0700 Received: from localhost ([127.0.0.1] helo=lists.colo.xensource.com) by lists.xensource.com with esmtp (Exim 4.43) id 1R8ys2-0007H9-BN; Wed, 28 Sep 2011 11:28:38 -0700 Received: from mail216.messagelabs.com ([85.158.143.99]) by lists.xensource.com with esmtp (Exim 4.43) id 1R8yrH-00074M-Ln for xen-devel@lists.xensource.com; Wed, 28 Sep 2011 11:27:51 -0700 X-Env-Sender: jeremy@goop.org X-Msg-Ref: server-8.tower-216.messagelabs.com!1317234466!16800053!1 X-Originating-IP: [74.207.240.146] X-StarScan-Version: 6.4.1; banners=-,-,- X-VirusChecked: Checked Received: (qmail 24839 invoked from network); 28 Sep 2011 18:27:48 -0000 Received: from claw.goop.org (HELO claw.goop.org) (74.207.240.146) by server-8.tower-216.messagelabs.com with DHE-RSA-AES256-SHA encrypted SMTP; 28 Sep 2011 18:27:48 -0000 Received: from saboo.goop.org (unknown [IPv6:2001:470:1f05:899:d0d6:81ff:fe76:ec4e]) (Authenticated sender: smtp-saboo) by claw.goop.org (Postfix) with ESMTPSA id 8F9F68A72; Wed, 28 Sep 2011 11:27:45 -0700 (PDT) Received: from saboo.goop.org (localhost [IPv6:::1]) by saboo.goop.org (Postfix) with ESMTP id A6A4220429; Wed, 28 Sep 2011 11:27:42 -0700 (PDT) Message-ID: <4E83671E.9070202@goop.org> Date: Wed, 28 Sep 2011 11:27:42 -0700 From: Jeremy Fitzhardinge <jeremy@goop.org> User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:6.0.2) Gecko/20110906 Thunderbird/6.0.2 MIME-Version: 1.0 To: Stephan Diestelhorst <stephan.diestelhorst@amd.com> Subject: Re: [Xen-devel] [PATCH 00/10] [PATCH RFC V2] Paravirtualized ticketlocks References: <cover.1315878463.git.jeremy.fitzhardinge@citrix.com> <4E835851.7070502@zytor.com> <4E835E50.2020307@goop.org> <201109282008.17722.stephan.diestelhorst@amd.com> In-Reply-To: <201109282008.17722.stephan.diestelhorst@amd.com> X-Enigmail-Version: 1.3.2 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Cc: Jeremy Fitzhardinge <jeremy.fitzhardinge@citrix.com>, Nick Piggin <npiggin@kernel.dk>, KVM <kvm@vger.kernel.org>, Peter Zijlstra <peterz@infradead.org>, the arch/x86 maintainers <x86@kernel.org>, Linux Kernel Mailing List <linux-kernel@vger.kernel.org>, Marcelo Tosatti <mtosatti@redhat.com>, Andi Kleen <andi@firstfloor.org>, Avi Kivity <avi@redhat.com>, Jan Beulich <JBeulich@suse.com>, "H. Peter Anvin" <hpa@zytor.com>, Ingo Molnar <mingo@elte.hu>, Linus Torvalds <torvalds@linux-foundation.org>, "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com> X-BeenThere: xen-devel@lists.xensource.com X-Mailman-Version: 2.1.5 Precedence: list List-Id: Xen developer discussion <xen-devel.lists.xensource.com> List-Unsubscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe> List-Post: <mailto:xen-devel@lists.xensource.com> List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help> List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=subscribe> Sender: xen-devel-bounces@lists.xensource.com Errors-To: xen-devel-bounces@lists.xensource.com On 09/28/2011 11:08 AM, Stephan Diestelhorst wrote: > On Wednesday 28 September 2011 19:50:08 Jeremy Fitzhardinge wrote: >> On 09/28/2011 10:24 AM, H. Peter Anvin wrote: >>> On 09/28/2011 10:22 AM, Linus Torvalds wrote: >>>> On Wed, Sep 28, 2011 at 9:47 AM, Jeremy Fitzhardinge <jeremy@goop.org> wrote: >>>>> Could do something like: >>>>> >>>>> if (ticket->head >= 254) >>>>> prev = xadd(&ticket->head_tail, 0xff02); >>>>> else >>>>> prev = xadd(&ticket->head_tail, 0x0002); >>>>> >>>>> to compensate for the overflow. >>>> Oh wow. You havge an even more twisted mind than I do. >>>> >>>> I guess that will work, exactly because we control "head" and thus can >>>> know about the overflow in the low byte. But boy is that ugly ;) >>>> >>>> But at least you wouldn't need to do the loop with cmpxchg. So it's >>>> twisted and ugly, but migth be practical. >>>> >>> I suspect it should be coded as -254 in order to use a short immediate >>> if that is even possible... >> I'm about to test: >> >> static __always_inline void arch_spin_unlock(arch_spinlock_t *lock) >> { >> if (TICKET_SLOWPATH_FLAG && unlikely(arch_static_branch(¶virt_ticketlocks_enabled))) { >> arch_spinlock_t prev; >> __ticketpair_t inc = TICKET_LOCK_INC; >> >> if (lock->tickets.head >= (1 << TICKET_SHIFT) - TICKET_LOCK_INC) >> inc += -1 << TICKET_SHIFT; >> >> prev.head_tail = xadd(&lock->head_tail, inc); >> >> if (prev.tickets.tail & TICKET_SLOWPATH_FLAG) >> __ticket_unlock_slowpath(lock, prev); >> } else >> __ticket_unlock_release(lock); >> } >> >> Which, frankly, is not something I particularly want to put my name to. > I must have missed the part when this turned into the propose-the- > craziest-way-that-this-still-works.contest :) > > What is wrong with converting the original addb into a lock addb? The > crazy wrap around tricks add a conditional and lots of headache. The > lock addb/w is clean. We are paying an atomic in both cases, so I just > don't see the benefit of the second solution. Well, it does end up generating surprisingly nice code. And to be honest, being able to do the unlock and atomically fetch the flag as one operation makes it much easier to reason about. I'll do a locked add variant as well to see how it turns out. Do you think locked add is better than unlocked + mfence? Thanks, J _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel From xen-devel-bounces@lists.xensource.com Wed Sep 28 11:37:10 2011 Return-path: <xen-devel-bounces@lists.xensource.com> Envelope-to: www-data@lists.xensource.com Delivery-date: Wed, 28 Sep 2011 11:37:10 -0700 Received: from localhost ([127.0.0.1] helo=lists.colo.xensource.com) by lists.xensource.com with esmtp (Exim 4.43) id 1R8z0I-0000DL-MF; Wed, 28 Sep 2011 11:37:10 -0700 Received: from mail174.messagelabs.com ([85.158.138.51]) by lists.xensource.com with esmtp (Exim 4.43) id 1R8yy6-0007iT-MV for xen-devel@lists.xensource.com; Wed, 28 Sep 2011 11:34:55 -0700 X-Env-Sender: jeremy@goop.org X-Msg-Ref: server-12.tower-174.messagelabs.com!1317234890!33123792!1 X-Originating-IP: [74.207.240.146] X-StarScan-Version: 6.4.1; banners=-,-,- X-VirusChecked: Checked Received: (qmail 31486 invoked from network); 28 Sep 2011 18:34:51 -0000 Received: from claw.goop.org (HELO claw.goop.org) (74.207.240.146) by server-12.tower-174.messagelabs.com with DHE-RSA-AES256-SHA encrypted SMTP; 28 Sep 2011 18:34:51 -0000 Received: from saboo.goop.org (unknown [IPv6:2001:470:1f05:899:d0d6:81ff:fe76:ec4e]) (Authenticated sender: smtp-saboo) by claw.goop.org (Postfix) with ESMTPSA id 73C568A7F; Wed, 28 Sep 2011 11:34:49 -0700 (PDT) Received: from saboo.goop.org (localhost [IPv6:::1]) by saboo.goop.org (Postfix) with ESMTP id A347720429; Wed, 28 Sep 2011 11:34:47 -0700 (PDT) Message-ID: <4E8368C7.70909@goop.org> Date: Wed, 28 Sep 2011 11:34:47 -0700 From: Jeremy Fitzhardinge <jeremy@goop.org> User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:6.0.2) Gecko/20110906 Thunderbird/6.0.2 MIME-Version: 1.0 To: Ian Campbell <Ian.Campbell@citrix.com> Subject: Re: [Xen-devel] dom0 kernel References: <CACaajQuWMrZhz51p2x9frQ-PyS8P8tbbbQAsJq6hyc4qp=fomg@mail.gmail.com> <1317198065.13424.109.camel@dagon.hellion.org.uk> In-Reply-To: <1317198065.13424.109.camel@dagon.hellion.org.uk> X-Enigmail-Version: 1.3.2 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>, Vasiliy Tolstov <v.tolstov@selfip.ru> X-BeenThere: xen-devel@lists.xensource.com X-Mailman-Version: 2.1.5 Precedence: list List-Id: Xen developer discussion <xen-devel.lists.xensource.com> List-Unsubscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe> List-Post: <mailto:xen-devel@lists.xensource.com> List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help> List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=subscribe> Sender: xen-devel-bounces@lists.xensource.com Errors-To: xen-devel-bounces@lists.xensource.com On 09/28/2011 01:21 AM, Ian Campbell wrote: > On Wed, 2011-09-28 at 09:11 +0100, Vasiliy Tolstov wrote: >> Hello. What kernel version is the best to use for dom0 under debian? >> Now i see, that kernel 2.6.32-5-xen-amd64 panic under heavy network >> load. > Can you give us a pointer to your Debian bug report on this issue > please. > >> What is the best - get kernel from official debian packages (may be in >> sid...) or compile from git and use? > Sid currently has 3.0 packages in it and experimental has 3.1-rc$late. > If you want a more recent 2.6.32.x then git is the only real option. > >> If i need 2.6.x kernel (becouse some packages not ready to run under >> 3.x) where i can find current stable xen git tree? > Jeremy's tree is https://github.com/jsgf/linux-xen Only the "xen/next-2.6.32" branch. The other branches are work-in-progress and are not necessarily stable, usable or anything else. J _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel From xen-devel-bounces@lists.xensource.com Wed Sep 28 11:41:41 2011 Return-path: <xen-devel-bounces@lists.xensource.com> Envelope-to: www-data@lists.xensource.com Delivery-date: Wed, 28 Sep 2011 11:41:41 -0700 Received: from localhost ([127.0.0.1] helo=lists.colo.xensource.com) by lists.xensource.com with esmtp (Exim 4.43) id 1R8z4f-0000mJ-GZ; Wed, 28 Sep 2011 11:41:41 -0700 Received: from mail21.messagelabs.com ([85.158.143.35]) by lists.xensource.com with esmtp (Exim 4.43) id 1R8z4I-0000ag-CW for xen-devel@lists.xensource.com; Wed, 28 Sep 2011 11:41:18 -0700 X-Env-Sender: jeremy@goop.org X-Msg-Ref: server-12.tower-21.messagelabs.com!1317235258!51717716!1 X-Originating-IP: [74.207.240.146] X-StarScan-Version: 6.4.1; banners=-,-,- X-VirusChecked: Checked Received: (qmail 9764 invoked from network); 28 Sep 2011 18:40:59 -0000 Received: from claw.goop.org (HELO claw.goop.org) (74.207.240.146) by server-12.tower-21.messagelabs.com with DHE-RSA-AES256-SHA encrypted SMTP; 28 Sep 2011 18:40:59 -0000 Received: from saboo.goop.org (unknown [IPv6:2001:470:1f05:899:d0d6:81ff:fe76:ec4e]) (Authenticated sender: smtp-saboo) by claw.goop.org (Postfix) with ESMTPSA id 386A98A8C; Wed, 28 Sep 2011 11:41:13 -0700 (PDT) Received: from saboo.goop.org (localhost [IPv6:::1]) by saboo.goop.org (Postfix) with ESMTP id 86B4220ED9; Wed, 28 Sep 2011 11:41:11 -0700 (PDT) Message-ID: <4E836A47.80107@goop.org> Date: Wed, 28 Sep 2011 11:41:11 -0700 From: Jeremy Fitzhardinge <jeremy@goop.org> User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:6.0.2) Gecko/20110906 Thunderbird/6.0.2 MIME-Version: 1.0 To: Ted Ts'o <tytso@mit.edu> Subject: Re: [Xen-devel] Re: [patch 1/1] ext4-fix-dirty-extent-when-origin-leaf-extent-reac.patch References: <BLU157-W499E698F650F554E645F9DDA1C0@phx.gbl> <20110906145347.GA4133@dumpdata.com> <BLU157-W4106FA4CF4EBA78C63FDA0DA1C0@phx.gbl> <4E666C86.5090707@goop.org> <BLU157-W323C330706CB8D7E976BC3DA1F0@phx.gbl> <BLU157-W7DABA5FE01C50C29B1A64DA060@phx.gbl> <BLU157-W25EB1EAC24CC11FA14859ADAF20@phx.gbl> <20110926142808.GG4102@phenom.oracle.com> <20110927193523.GB3309@thunk.org> In-Reply-To: <20110927193523.GB3309@thunk.org> X-Enigmail-Version: 1.3.2 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: MaoXiaoyun <tinnycloud@hotmail.com>, linux-ext4@vger.kernel.org, jack@suse.cz, xen devel <xen-devel@lists.xensource.com>, Konrad Rzeszutek Wilk <konrad.wilk@oracle.com> X-BeenThere: xen-devel@lists.xensource.com X-Mailman-Version: 2.1.5 Precedence: list List-Id: Xen developer discussion <xen-devel.lists.xensource.com> List-Unsubscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe> List-Post: <mailto:xen-devel@lists.xensource.com> List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help> List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=subscribe> Sender: xen-devel-bounces@lists.xensource.com Errors-To: xen-devel-bounces@lists.xensource.com On 09/27/2011 12:35 PM, Ted Ts'o wrote: > On Mon, Sep 26, 2011 at 10:28:08AM -0400, Konrad Rzeszutek Wilk wrote: >>> >>> Attached is the fix, verified in our env. >> So.. you are asking for this upstream git commit to be back-ported >> to 2.6.32, right? > I'm curious --- is there a good reason why Xen users are using an > upstream 2.6.32 kernel? If they are using a distro kernel, fine, but > then the distro kernel should be providing the support. But at this > point, 2.6.32 is so positively *ancient* that, I'm personally not > interesting in providing free, unpaid distro support for users who > aren't willing to either (a) pay $$$ and get a supported distro > kernel, or (b) use a much more modern kernel. At this point, Guest > and Host Xen support is available in 3.0 kernels, so there's really no > excuse, right? The 2.6.32.x-based kernel has been the preferred "stable" kernel for Xen users for a while, and it is still considered to be more stable and functional than what's upstream (obviously we're trying to fix that). Also, because many current distros don't support Xen dom0, it has been an ad-hoc distro kernel. Since kernel.org 2.6.32 is still considered to be a maintained long-term-stable kernel, I keep the xen.git version up-to-date with stable-2.6.32 bugfixes and occasional separate Xen-specific fixes. But I'd really prefer to avoid having any non-Xen private changes in that tree, in favour of getting everything from upstream stable. Do you not consider it worth continuing support of the 2.6.32 stable tree with respect to ext4? J _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel From xen-devel-bounces@lists.xensource.com Wed Sep 28 11:50:47 2011 Return-path: <xen-devel-bounces@lists.xensource.com> Envelope-to: www-data@lists.xensource.com Delivery-date: Wed, 28 Sep 2011 11:50:47 -0700 Received: from localhost ([127.0.0.1] helo=lists.colo.xensource.com) by lists.xensource.com with esmtp (Exim 4.43) id 1R8zDS-0001Gq-Vp; Wed, 28 Sep 2011 11:50:47 -0700 Received: from mail27.messagelabs.com ([193.109.254.147]) by lists.xensource.com with esmtp (Exim 4.43) id 1R8zD2-000158-B4 for xen-devel@lists.xensource.com; Wed, 28 Sep 2011 11:50:20 -0700 X-Env-Sender: linus971@gmail.com X-Msg-Ref: server-2.tower-27.messagelabs.com!1317235791!56859236!1 X-Originating-IP: [74.125.82.171] X-StarScan-Version: 6.4.1; banners=-,-,- X-VirusChecked: Checked Received: (qmail 13081 invoked from network); 28 Sep 2011 18:49:51 -0000 Received: from mail-wy0-f171.google.com (HELO mail-wy0-f171.google.com) (74.125.82.171) by server-2.tower-27.messagelabs.com with RC4-SHA encrypted SMTP; 28 Sep 2011 18:49:51 -0000 Received: by wyh13 with SMTP id 13so422707wyh.30 for <xen-devel@lists.xensource.com>; Wed, 28 Sep 2011 11:50:17 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:sender:in-reply-to:references:from:date :x-google-sender-auth:message-id:subject:to:cc:content-type; bh=UpnQTMMNw+l9Tg8fXOHDAXjur8AiT0A3+E5bRW9i07w=; b=nQKhl8+hX4W7nvKQcJ5tVCPBh84xp+0EX8UyTFXHhgmz0L2wOdORV+GpKF0y0QDA/5 Ty2kQLV0HW6YN/Dw0JkHIADonQzXQdav8K/GPI4R+IfsqNnj3/MOZwN9asv9ba72SfFg mAoQNzrNkB4+7Dj43hdmSMas/mcRv7mkP104Y= Received: by 10.216.208.158 with SMTP id q30mr9794weo.93.1317235817145; Wed, 28 Sep 2011 11:50:17 -0700 (PDT) MIME-Version: 1.0 Received: by 10.216.11.12 with HTTP; Wed, 28 Sep 2011 11:49:56 -0700 (PDT) In-Reply-To: <201109282008.17722.stephan.diestelhorst@amd.com> References: <cover.1315878463.git.jeremy.fitzhardinge@citrix.com> <4E835851.7070502@zytor.com> <4E835E50.2020307@goop.org> <201109282008.17722.stephan.diestelhorst@amd.com> From: Linus Torvalds <torvalds@linux-foundation.org> Date: Wed, 28 Sep 2011 11:49:56 -0700 X-Google-Sender-Auth: bHq8L02SAruJtvz77tWX1LPjbZg Message-ID: <CA+55aFwm7ESNfrHhEHrAKcjcPUq8YxtuEkJd5PzAekYo2dMYNw@mail.gmail.com> Subject: Re: [Xen-devel] [PATCH 00/10] [PATCH RFC V2] Paravirtualized ticketlocks To: Stephan Diestelhorst <stephan.diestelhorst@amd.com> Content-Type: text/plain; charset=ISO-8859-1 Cc: Jeremy Fitzhardinge <jeremy@goop.org>, Jeremy Fitzhardinge <jeremy.fitzhardinge@citrix.com>, Nick Piggin <npiggin@kernel.dk>, KVM <kvm@vger.kernel.org>, Peter Zijlstra <peterz@infradead.org>, the arch/x86 maintainers <x86@kernel.org>, Linux Kernel Mailing List <linux-kernel@vger.kernel.org>, Marcelo Tosatti <mtosatti@redhat.com>, Andi Kleen <andi@firstfloor.org>, Avi Kivity <avi@redhat.com>, Jan Beulich <JBeulich@suse.com>, "H. Peter Anvin" <hpa@zytor.com>, Ingo Molnar <mingo@elte.hu>, "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com> X-BeenThere: xen-devel@lists.xensource.com X-Mailman-Version: 2.1.5 Precedence: list List-Id: Xen developer discussion <xen-devel.lists.xensource.com> List-Unsubscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe> List-Post: <mailto:xen-devel@lists.xensource.com> List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help> List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=subscribe> Sender: xen-devel-bounces@lists.xensource.com Errors-To: xen-devel-bounces@lists.xensource.com On Wed, Sep 28, 2011 at 11:08 AM, Stephan Diestelhorst <stephan.diestelhorst@amd.com> wrote: > > I must have missed the part when this turned into the propose-the- > craziest-way-that-this-still-works.contest :) So doing it just with the "lock addb" probably works fine, but I have to say that I personally shudder at the "surround the locked addb by reads from the word, in order to approximate an atomic read of the upper bits". Because what you get is not really an "atomic read of the upper bits", it's a "ok, we'll get the worst case of somebody modifying the upper bits at the same time". Which certainly should *work*, but from a conceptual standpoint, isn't it just *much* nicer to say "we actually know *exactly* what the upper bits were". But I don't care all *that* deeply. I do agree that the xaddw trick is pretty tricky. I just happen to think that it's actually *less* tricky than "read the upper bits separately and depend on subtle ordering issues with another writer that happens at the same time on another CPU". So I can live with either form - as long as it works. I think it might be easier to argue that the xaddw is guaranteed to work, because all values at all points are unarguably atomic (yeah, we read the lower bits nonatomically, but as the owner of the lock we know that nobody else can write them). Linus _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel From xen-devel-bounces@lists.xensource.com Wed Sep 28 12:07:57 2011 Return-path: <xen-devel-bounces@lists.xensource.com> Envelope-to: www-data@lists.xensource.com Delivery-date: Wed, 28 Sep 2011 12:07:57 -0700 Received: from localhost ([127.0.0.1] helo=lists.colo.xensource.com) by lists.xensource.com with esmtp (Exim 4.43) id 1R8zU5-0002EG-Jx; Wed, 28 Sep 2011 12:07:57 -0700 Received: from mail216.messagelabs.com ([85.158.143.99]) by lists.xensource.com with esmtp (Exim 4.43) id 1R8zSt-00021d-RR for xen-devel@lists.xensource.com; Wed, 28 Sep 2011 12:06:44 -0700 X-Env-Sender: jeremy@goop.org X-Msg-Ref: server-12.tower-216.messagelabs.com!1317236799!14171794!1 X-Originating-IP: [74.207.240.146] X-StarScan-Version: 6.4.1; banners=-,-,- X-VirusChecked: Checked Received: (qmail 11225 invoked from network); 28 Sep 2011 19:06:40 -0000 Received: from claw.goop.org (HELO claw.goop.org) (74.207.240.146) by server-12.tower-216.messagelabs.com with DHE-RSA-AES256-SHA encrypted SMTP; 28 Sep 2011 19:06:40 -0000 Received: from saboo.goop.org (unknown [IPv6:2001:470:1f05:899:d0d6:81ff:fe76:ec4e]) (Authenticated sender: smtp-saboo) by claw.goop.org (Postfix) with ESMTPSA id 51FB13B5; Wed, 28 Sep 2011 12:06:38 -0700 (PDT) Received: from saboo.goop.org (localhost [IPv6:::1]) by saboo.goop.org (Postfix) with ESMTP id A1A3F20429; Wed, 28 Sep 2011 12:06:36 -0700 (PDT) Message-ID: <4E83703C.2010907@goop.org> Date: Wed, 28 Sep 2011 12:06:36 -0700 From: Jeremy Fitzhardinge <jeremy@goop.org> User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:6.0.2) Gecko/20110906 Thunderbird/6.0.2 MIME-Version: 1.0 To: Linus Torvalds <torvalds@linux-foundation.org> Subject: Re: [Xen-devel] [PATCH 00/10] [PATCH RFC V2] Paravirtualized ticketlocks References: <cover.1315878463.git.jeremy.fitzhardinge@citrix.com> <4E835851.7070502@zytor.com> <4E835E50.2020307@goop.org> <201109282008.17722.stephan.diestelhorst@amd.com> <CA+55aFwm7ESNfrHhEHrAKcjcPUq8YxtuEkJd5PzAekYo2dMYNw@mail.gmail.com> In-Reply-To: <CA+55aFwm7ESNfrHhEHrAKcjcPUq8YxtuEkJd5PzAekYo2dMYNw@mail.gmail.com> X-Enigmail-Version: 1.3.2 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: Jeremy Fitzhardinge <jeremy.fitzhardinge@citrix.com>, Nick Piggin <npiggin@kernel.dk>, KVM <kvm@vger.kernel.org>, Peter Zijlstra <peterz@infradead.org>, the arch/x86 maintainers <x86@kernel.org>, Linux Kernel Mailing List <linux-kernel@vger.kernel.org>, Marcelo Tosatti <mtosatti@redhat.com>, Andi Kleen <andi@firstfloor.org>, Avi Kivity <avi@redhat.com>, Jan Beulich <JBeulich@suse.com>, "H. Peter Anvin" <hpa@zytor.com>, Ingo Molnar <mingo@elte.hu>, "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>, Stephan Diestelhorst <stephan.diestelhorst@amd.com> X-BeenThere: xen-devel@lists.xensource.com X-Mailman-Version: 2.1.5 Precedence: list List-Id: Xen developer discussion <xen-devel.lists.xensource.com> List-Unsubscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe> List-Post: <mailto:xen-devel@lists.xensource.com> List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help> List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=subscribe> Sender: xen-devel-bounces@lists.xensource.com Errors-To: xen-devel-bounces@lists.xensource.com On 09/28/2011 11:49 AM, Linus Torvalds wrote: > But I don't care all *that* deeply. I do agree that the xaddw trick is > pretty tricky. I just happen to think that it's actually *less* tricky > than "read the upper bits separately and depend on subtle ordering > issues with another writer that happens at the same time on another > CPU". > > So I can live with either form - as long as it works. I think it might > be easier to argue that the xaddw is guaranteed to work, because all > values at all points are unarguably atomic (yeah, we read the lower > bits nonatomically, but as the owner of the lock we know that nobody > else can write them). Exactly. I just did a locked add variant, and while the code looks a little simpler, it definitely has more actual complexity to analyze. J _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel From xen-devel-bounces@lists.xensource.com Wed Sep 28 12:47:43 2011 Return-path: <xen-devel-bounces@lists.xensource.com> Envelope-to: www-data@lists.xensource.com Delivery-date: Wed, 28 Sep 2011 12:47:43 -0700 Received: from localhost ([127.0.0.1] helo=lists.colo.xensource.com) by lists.xensource.com with esmtp (Exim 4.43) id 1R906Y-0004DZ-Ve; Wed, 28 Sep 2011 12:47:43 -0700 Received: from mail216.messagelabs.com ([85.158.143.99]) by lists.xensource.com with esmtp (Exim 4.43) id 1R905n-00041G-NL for xen-devel@lists.xensource.com; Wed, 28 Sep 2011 12:46:56 -0700 X-Env-Sender: tytso@thunk.org X-Msg-Ref: server-4.tower-216.messagelabs.com!1317239211!19899416!1 X-Originating-IP: [67.18.176.11] X-StarScan-Version: 6.4.1; banners=-,-,- X-VirusChecked: Checked Received: (qmail 16741 invoked from network); 28 Sep 2011 19:46:52 -0000 Received: from li9-11.members.linode.com (HELO test.thunk.org) (67.18.176.11) by server-4.tower-216.messagelabs.com with AES256-SHA encrypted SMTP; 28 Sep 2011 19:46:52 -0000 Received: from root (helo=tytso-glaptop.cam.corp.google.com) by test.thunk.org with local-esmtp (Exim 4.69) (envelope-from <tytso@thunk.org>) id 1R905d-0001jO-DY; Wed, 28 Sep 2011 19:46:45 +0000 Received: from tytso by tytso-glaptop.cam.corp.google.com with local (Exim 4.71) (envelope-from <tytso@thunk.org>) id 1R905c-0000qY-9w; Wed, 28 Sep 2011 15:46:44 -0400 Date: Wed, 28 Sep 2011 15:46:44 -0400 From: Ted Ts'o <tytso@mit.edu> To: Jeremy Fitzhardinge <jeremy@goop.org> Subject: Re: [Xen-devel] Re: [patch 1/1] ext4-fix-dirty-extent-when-origin-leaf-extent-reac.patch Message-ID: <20110928194644.GC19250@thunk.org> References: <BLU157-W499E698F650F554E645F9DDA1C0@phx.gbl> <20110906145347.GA4133@dumpdata.com> <BLU157-W4106FA4CF4EBA78C63FDA0DA1C0@phx.gbl> <4E666C86.5090707@goop.org> <BLU157-W323C330706CB8D7E976BC3DA1F0@phx.gbl> <BLU157-W7DABA5FE01C50C29B1A64DA060@phx.gbl> <BLU157-W25EB1EAC24CC11FA14859ADAF20@phx.gbl> <20110926142808.GG4102@phenom.oracle.com> <20110927193523.GB3309@thunk.org> <4E836A47.80107@goop.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <4E836A47.80107@goop.org> User-Agent: Mutt/1.5.20 (2009-06-14) X-SA-Exim-Connect-IP: <locally generated> X-SA-Exim-Mail-From: tytso@thunk.org X-SA-Exim-Scanned: No (on test.thunk.org); SAEximRunCond expanded to false Cc: MaoXiaoyun <tinnycloud@hotmail.com>, linux-ext4@vger.kernel.org, jack@suse.cz, xen devel <xen-devel@lists.xensource.com>, Konrad Rzeszutek Wilk <konrad.wilk@oracle.com> X-BeenThere: xen-devel@lists.xensource.com X-Mailman-Version: 2.1.5 Precedence: list List-Id: Xen developer discussion <xen-devel.lists.xensource.com> List-Unsubscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe> List-Post: <mailto:xen-devel@lists.xensource.com> List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help> List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=subscribe> Sender: xen-devel-bounces@lists.xensource.com Errors-To: xen-devel-bounces@lists.xensource.com On Wed, Sep 28, 2011 at 11:41:11AM -0700, Jeremy Fitzhardinge wrote: > Since kernel.org 2.6.32 is still considered to be a maintained > long-term-stable kernel, I keep the xen.git version up-to-date with > stable-2.6.32 bugfixes and occasional separate Xen-specific fixes. But > I'd really prefer to avoid having any non-Xen private changes in that > tree, in favour of getting everything from upstream stable. > > Do you not consider it worth continuing support of the 2.6.32 stable > tree with respect to ext4? I just don't have the *time* to maintain backports of ext4 fixes to 2.6.32. There have been so many bug fixes to ext4, and some of them depend on changes in the quota subsystem, so trying to back port them all would be hellish, and not something I'm willing to do on a volunteer basis. I'm busy enough with silly things like trying to help with the kernel.org getting back on-line, that channelling my stay-really-late hours to support users who are too cheap to pay distro support fees is not really a way that I would choose to spend my personal time. If someone would like to volunteer to be unpaid distro support, that's great. It's worth it as long as I get to volunteer somebody else's time. :-) - Ted _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel From xen-devel-bounces@lists.xensource.com Wed Sep 28 14:23:41 2011 Return-path: <xen-devel-bounces@lists.xensource.com> Envelope-to: www-data@lists.xensource.com Delivery-date: Wed, 28 Sep 2011 14:23:41 -0700 Received: from localhost ([127.0.0.1] helo=lists.colo.xensource.com) by lists.xensource.com with esmtp (Exim 4.43) id 1R91bQ-0008KJ-Ps; Wed, 28 Sep 2011 14:23:41 -0700 Received: from mail216.messagelabs.com ([85.158.143.99]) by lists.xensource.com with esmtp (Exim 4.43) id 1R91aj-00087p-C6 for xen-devel@lists.xensource.com; Wed, 28 Sep 2011 14:22:57 -0700 X-Env-Sender: amscanne@gridcentric.ca X-Msg-Ref: server-6.tower-216.messagelabs.com!1317244974!18656408!1 X-Originating-IP: [209.85.161.43] X-StarScan-Version: 6.4.1; banners=-,-,- X-VirusChecked: Checked Received: (qmail 10492 invoked from network); 28 Sep 2011 21:22:54 -0000 Received: from mail-fx0-f43.google.com (HELO mail-fx0-f43.google.com) (209.85.161.43) by server-6.tower-216.messagelabs.com with RC4-SHA encrypted SMTP; 28 Sep 2011 21:22:54 -0000 Received: by fxh19 with SMTP id 19so1379575fxh.30 for <xen-devel@lists.xensource.com>; Wed, 28 Sep 2011 14:22:54 -0700 (PDT) Received: by 10.223.48.69 with SMTP id q5mr15059283faf.80.1317244974078; Wed, 28 Sep 2011 14:22:54 -0700 (PDT) MIME-Version: 1.0 Received: by 10.223.101.194 with HTTP; Wed, 28 Sep 2011 14:22:34 -0700 (PDT) From: Adin Scannell <adin@gridcentric.com> Date: Wed, 28 Sep 2011 17:22:34 -0400 X-Google-Sender-Auth: 1-Uk2H4tHlWG7qIjBPfpTw0D-TI Message-ID: <CAAJKtqp1jEXzfp9Y+1pYKrxdLJU65r2oj3Fc4ScPrzufH8kiig@mail.gmail.com> To: xen-devel@lists.xensource.com Content-Type: text/plain; charset=ISO-8859-1 Subject: [Xen-devel] [PATCH 0/2] enable event channel wake-up for mem_event interfaces X-BeenThere: xen-devel@lists.xensource.com X-Mailman-Version: 2.1.5 Precedence: list List-Id: Xen developer discussion <xen-devel.lists.xensource.com> List-Unsubscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe> List-Post: <mailto:xen-devel@lists.xensource.com> List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help> List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=subscribe> Sender: xen-devel-bounces@lists.xensource.com Errors-To: xen-devel-bounces@lists.xensource.com Currently the mem_event code requires a domctl to kick the hypervisor and unpause vcpus. An event channel is used to notify dom0 of requests placed in the ring, and it can similarly be used to notify Xen, so as not to overuse domctls when running many domains with mem_event interfaces (domctls are not a great interface for this sort of thing, because they will all be serialized). This patch set enables the use of the event channel to signal when a response in placed in a mem_event ring. The two patches are as follows: - The first patch tweaks the memevent code to ensure that no events are lost. Instead of calling get_response once per kick, we may have to pull out multiple events at a time. This doesn't affect normal operation with the domctls. This patch also ensures that each vCPU can generate a request in each mem_event ring (i.e. put_request will always work), by appropriately pausing vCPUs when after requests are placed. - The second patch breaks the Xen-side event channel handling into a new arch-specific file "events.c", and adds cases for the different Xen-handled event channels. This formalizes the tiny exception that was in place for just qemu in event_channel.c. All the domctls are still in place and everything should be backwards compatible. Cheers, -Adin _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel From xen-devel-bounces@lists.xensource.com Wed Sep 28 14:25:53 2011 Return-path: <xen-devel-bounces@lists.xensource.com> Envelope-to: www-data@lists.xensource.com Delivery-date: Wed, 28 Sep 2011 14:25:53 -0700 Received: from localhost ([127.0.0.1] helo=lists.colo.xensource.com) by lists.xensource.com with esmtp (Exim 4.43) id 1R91dZ-0000Gr-Mf; Wed, 28 Sep 2011 14:25:53 -0700 Received: from mail27.messagelabs.com ([193.109.254.147]) by lists.xensource.com with esmtp (Exim 4.43) id 1R91d3-0008WS-JM for xen-devel@lists.xensource.com; Wed, 28 Sep 2011 14:25:22 -0700 X-Env-Sender: amscanne@gridcentric.ca X-Msg-Ref: server-11.tower-27.messagelabs.com!1317245109!39330367!1 X-Originating-IP: [209.85.161.43] X-StarScan-Version: 6.4.1; banners=-,-,- X-VirusChecked: Checked Received: (qmail 29057 invoked from network); 28 Sep 2011 21:25:09 -0000 Received: from mail-fx0-f43.google.com (HELO mail-fx0-f43.google.com) (209.85.161.43) by server-11.tower-27.messagelabs.com with RC4-SHA encrypted SMTP; 28 Sep 2011 21:25:09 -0000 Received: by fxh19 with SMTP id 19so1381898fxh.30 for <xen-devel@lists.xensource.com>; Wed, 28 Sep 2011 14:25:18 -0700 (PDT) Received: by 10.223.76.67 with SMTP id b3mr15212532fak.61.1317245118107; Wed, 28 Sep 2011 14:25:18 -0700 (PDT) MIME-Version: 1.0 Received: by 10.223.101.194 with HTTP; Wed, 28 Sep 2011 14:24:58 -0700 (PDT) From: Adin Scannell <adin@gridcentric.com> Date: Wed, 28 Sep 2011 17:24:58 -0400 X-Google-Sender-Auth: 4tXuNp1sE_Yk9y7JIu9taX7Y1bI Message-ID: <CAAJKtqoPDzEEY7xLQbFyOXrwNhBUJyV274LzRT-=0fPMbYjWkw@mail.gmail.com> To: xen-devel@lists.xensource.com Content-Type: multipart/mixed; boundary=00151743f96458cfa604ae070719 Subject: [Xen-devel] [PATCH 1/2] enable event channel wake-up for mem_event interfaces X-BeenThere: xen-devel@lists.xensource.com X-Mailman-Version: 2.1.5 Precedence: list List-Id: Xen developer discussion <xen-devel.lists.xensource.com> List-Unsubscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe> List-Post: <mailto:xen-devel@lists.xensource.com> List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help> List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=subscribe> Sender: xen-devel-bounces@lists.xensource.com Errors-To: xen-devel-bounces@lists.xensource.com --00151743f96458cfa604ae070719 Content-Type: text/plain; charset=ISO-8859-1 --00151743f96458cfa604ae070719 Content-Type: application/octet-stream; name="memevent-dont-lose-events.patch" Content-Disposition: attachment; filename="memevent-dont-lose-events.patch" Content-Transfer-Encoding: base64 X-Attachment-Id: f_gt4tpaz20 VGhlIG1lbWV2ZW50IGNvZGUgY3VycmVudGx5IGhhcyBhIG1lY2hhbmlzbSBmb3IgcmVzZXJ2aW5n IHNwYWNlIGluIHRoZSByaW5nCmJlZm9yZSBwdXR0aW5nIGFuIGV2ZW50LCBidXQgZWFjaCBjYWxs ZXIgbXVzdCBpbmRpdmlkdWFsbHkgZW5zdXJlIHRoYXQgdGhlCnZDUFVzIGFyZSBjb3JyZWN0bHkg cGF1c2VkIGlmIG5vIHNwYWNlIGlzIGF2YWlsYWJsZS4KClRoaXMgZml4ZXMgdGhhdCBpc3N1ZSBi eSByZXZlcnNpbmcgdGhlIHNlbWFudGljcywgd2UgZW5zdXJlIHRoYXQgZW5zdXJlIHNwYWNlCmlz IGFsd2F5cyBsZWZ0IGluIHRoZSByaW5nIGZvciBvbmUgZXZlbnQgcGVyIHZDUFUgcGVyIHJpbmcu ICBJZiB0aGlzIGNvbnN0cmFpbnQKaXMgYWJvdmUgdG8gdmlvbGF0ZWQgYnkgYSB2Q1BVIHB1dHRp bmcgYSByZXNwb25zZSwgd2UgcGF1c2UgdGhlIHZDUFUgb24gdGhlIHdheQpvdXQuCgpBZGRpdGlv bmFsbHksIHdlIGVuc3VyZSB0aGF0IG5vIGV2ZW50cyBvbiBsb3N0IGJ5IFhlbiBhcyBhIGNvbnN1 bWVyIGlmIG11bHRpcGxlCnJlc3BvbnNlcyBsYW5kIG9uIHRoZSByaW5nIGZvciBhIHNpbmdsZSBk b21jdGwuIChUaGlzIGlzIGN1cnJlbnRseSBpbXBvc3NpYmxlLApidXQgc2FmZSBhbnl3YXlzLi4u IHRoaXMgcGF0Y2ggaXMgcmVxdWlyZWQgYnkgdGhlIG5leHQgaW4gdGhlIHNlcmllcykuCgpTaWdu ZWQtb2ZmLWJ5OiBBZGluIFNjYW5uZWxsIDxhZGluQHNjYW5uZWxsLmNhPgoKZGlmZiAtciBhNDIy ZTJhNDQ1MWUgeGVuL2FyY2gveDg2L2h2bS9odm0uYwotLS0gYS94ZW4vYXJjaC94ODYvaHZtL2h2 bS5jCisrKyBiL3hlbi9hcmNoL3g4Ni9odm0vaHZtLmMKQEAgLTQwMTcsNyArNDAxNyw2IEBAIHN0 YXRpYyBpbnQgaHZtX21lbW9yeV9ldmVudF90cmFwcyhsb25nIHAKICAgICBzdHJ1Y3QgdmNwdSog diA9IGN1cnJlbnQ7CiAgICAgc3RydWN0IGRvbWFpbiAqZCA9IHYtPmRvbWFpbjsKICAgICBtZW1f ZXZlbnRfcmVxdWVzdF90IHJlcTsKLSAgICBpbnQgcmM7CiAKICAgICBpZiAoICEocCAmIEhWTVBN RV9NT0RFX01BU0spICkgCiAgICAgICAgIHJldHVybiAwOwpAQCAtNDAyNSwxMCArNDAyNCw2IEBA IHN0YXRpYyBpbnQgaHZtX21lbW9yeV9ldmVudF90cmFwcyhsb25nIHAKICAgICBpZiAoIChwICYg SFZNUE1FX29uY2hhbmdlb25seSkgJiYgKHZhbHVlID09IG9sZCkgKQogICAgICAgICByZXR1cm4g MTsKICAgICAKLSAgICByYyA9IG1lbV9ldmVudF9jaGVja19yaW5nKGQsICZkLT5tZW1fYWNjZXNz KTsKLSAgICBpZiAoIHJjICkKLSAgICAgICAgcmV0dXJuIHJjOwotICAgIAogICAgIG1lbXNldCgm cmVxLCAwLCBzaXplb2YocmVxKSk7CiAgICAgcmVxLnR5cGUgPSBNRU1fRVZFTlRfVFlQRV9BQ0NF U1M7CiAgICAgcmVxLnJlYXNvbiA9IHJlYXNvbjsKZGlmZiAtciBhNDIyZTJhNDQ1MWUgeGVuL2Fy Y2gveDg2L21tL21lbV9ldmVudC5jCi0tLSBhL3hlbi9hcmNoL3g4Ni9tbS9tZW1fZXZlbnQuYwor KysgYi94ZW4vYXJjaC94ODYvbW0vbWVtX2V2ZW50LmMKQEAgLTc4LDYgKzc4LDkgQEAgc3RhdGlj IGludCBtZW1fZXZlbnRfZW5hYmxlKHN0cnVjdCBkb21haQogICAgIG1lZC0+cmluZ19wYWdlID0g bWFwX2RvbWFpbl9wYWdlKG1mbl94KHJpbmdfbWZuKSk7CiAgICAgbWVkLT5zaGFyZWRfcGFnZSA9 IG1hcF9kb21haW5fcGFnZShtZm5feChzaGFyZWRfbWZuKSk7CiAKKyAgICAvKiBTZXQgdGhlIG51 bWJlciBvZiBjdXJyZW50bHkgYmxvY2tlZCB2Q1BVcyB0byAwLiAqLworICAgIG1lZC0+YmxvY2tl ZCA9IDA7CisKICAgICAvKiBBbGxvY2F0ZSBldmVudCBjaGFubmVsICovCiAgICAgcmMgPSBhbGxv Y191bmJvdW5kX3hlbl9ldmVudF9jaGFubmVsKGQtPnZjcHVbMF0sCiAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgIGN1cnJlbnQtPmRvbWFpbi0+ZG9tYWluX2lkKTsKQEAg LTk1LDcgKzk4LDcgQEAgc3RhdGljIGludCBtZW1fZXZlbnRfZW5hYmxlKHN0cnVjdCBkb21haQog ICAgIG1lbV9ldmVudF9yaW5nX2xvY2tfaW5pdChtZWQpOwogCiAgICAgLyogV2FrZSBhbnkgVkNQ VXMgcGF1c2VkIGZvciBtZW1vcnkgZXZlbnRzICovCi0gICAgbWVtX2V2ZW50X3VucGF1c2VfdmNw dXMoZCk7CisgICAgbWVtX2V2ZW50X3VucGF1c2VfdmNwdXMoZCwgbWVkKTsKIAogICAgIHJldHVy biAwOwogCkBAIC0xMjAsMTMgKzEyMyw0MSBAQCBzdGF0aWMgaW50IG1lbV9ldmVudF9kaXNhYmxl KHN0cnVjdCBtZW1fCiAgICAgcmV0dXJuIDA7CiB9CiAKLXZvaWQgbWVtX2V2ZW50X3B1dF9yZXF1 ZXN0KHN0cnVjdCBkb21haW4gKmQsIHN0cnVjdCBtZW1fZXZlbnRfZG9tYWluICptZWQsIG1lbV9l dmVudF9yZXF1ZXN0X3QgKnJlcSkKK3N0YXRpYyBpbmxpbmUgaW50IG1lbV9ldmVudF9yaW5nX2Zy ZWUoc3RydWN0IGRvbWFpbiAqZCwgc3RydWN0IG1lbV9ldmVudF9kb21haW4gKm1lZCkKK3sKKyAg ICBpbnQgZnJlZV9yZXF1ZXN0czsKKworICAgIGZyZWVfcmVxdWVzdHMgPSBSSU5HX0ZSRUVfUkVR VUVTVFMoJm1lZC0+ZnJvbnRfcmluZyk7CisgICAgaWYgKCB1bmxpa2VseShmcmVlX3JlcXVlc3Rz IDwgZC0+bWF4X3ZjcHVzKSApCisgICAgeworICAgICAgICAvKiBUaGlzIG1heSBoYXBwZW4uICov CisgICAgICAgIGdkcHJpbnRrKFhFTkxPR19JTkZPLCAibWVtX2V2ZW50IHJlcXVlc3Qgc2xvdHMg Zm9yIGRvbWFpbiAlZDogJWRcbiIsCisgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgZC0+ ZG9tYWluX2lkLCBmcmVlX3JlcXVlc3RzKTsKKyAgICAgICAgV0FSTl9PTigxKTsKKyAgICB9CisK KyAgICByZXR1cm4gZnJlZV9yZXF1ZXN0czsKK30KKworaW50IG1lbV9ldmVudF9wdXRfcmVxdWVz dChzdHJ1Y3QgZG9tYWluICpkLCBzdHJ1Y3QgbWVtX2V2ZW50X2RvbWFpbiAqbWVkLCBtZW1fZXZl bnRfcmVxdWVzdF90ICpyZXEpCiB7CiAgICAgbWVtX2V2ZW50X2Zyb250X3JpbmdfdCAqZnJvbnRf cmluZzsKICAgICBSSU5HX0lEWCByZXFfcHJvZDsKIAorICAgIGlmKCBtZW1fZXZlbnRfY2hlY2tf cmluZyhkLCBtZWQpIDwgMCApCisgICAgICAgIHJldHVybiAwOworCiAgICAgbWVtX2V2ZW50X3Jp bmdfbG9jayhtZWQpOwogCisgICAgaWYoIG1lbV9ldmVudF9yaW5nX2ZyZWUoZCwgbWVkKSA9PSAw ICkKKyAgICB7CisgICAgICAgIC8qIFRoaXMgc2hvdWxkbid0IGhhcHBlbi4gKi8KKyAgICAgICAg Z2RwcmludGsoWEVOTE9HX1dBUk5JTkcsICJwb3NzaWJsZSBsb3N0IG1lbV9ldmVudCBmb3IgZG9t YWluICVkXG4iLAorICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgZC0+ZG9tYWluX2lk KTsKKyAgICAgICAgbWVtX2V2ZW50X21hcmtfYW5kX3BhdXNlKGN1cnJlbnQsIG1lZCk7CisgICAg ICAgIHJldHVybiAwOworICAgIH0KKwogICAgIGZyb250X3JpbmcgPSAmbWVkLT5mcm9udF9yaW5n OwogICAgIHJlcV9wcm9kID0gZnJvbnRfcmluZy0+cmVxX3Byb2RfcHZ0OwogCkBAIC0xMzUsMTYg KzE2NiwyOCBAQCB2b2lkIG1lbV9ldmVudF9wdXRfcmVxdWVzdChzdHJ1Y3QgZG9tYWluCiAgICAg cmVxX3Byb2QrKzsKIAogICAgIC8qIFVwZGF0ZSByaW5nICovCi0gICAgbWVkLT5yZXFfcHJvZHVj ZXJzLS07CiAgICAgZnJvbnRfcmluZy0+cmVxX3Byb2RfcHZ0ID0gcmVxX3Byb2Q7CiAgICAgUklO R19QVVNIX1JFUVVFU1RTKGZyb250X3JpbmcpOwogCisgICAgLyoKKyAgICAgKiBXZSBlbnN1cmUg dGhhdCBlYWNoIHZjcHUgY2FuIHB1dCBhdCBsZWFzdCAqb25lKiBldmVudCAtLSBiZWNhdXNlIHNv bWUKKyAgICAgKiBldmVudHMgYXJlIG5vdCByZXBlYXRhYmxlLCBzdWNoIGFzIGRyb3BwaW5nIGEg cGFnZS4gIFRoaXMgd2lsbCBlbnN1cmUgbm8KKyAgICAgKiB2Q1BVIGlzIGxlZnQgd2l0aCBhbiBl dmVudCB0aGF0IHRoZXkgbXVzdCBwbGFjZSBvbiB0aGUgcmluZywgYnV0IGNhbm5vdC4KKyAgICAg KiBUaGV5IHdpbGwgYmUgcGF1c2VkIGFmdGVyIHRoZSBldmVudCBpcyBwbGFjZWQuCisgICAgICog U2VlIGxhcmdlIGNvbW1lbnQgYmVsb3cgaW4gbWVtX2V2ZW50X3VucGF1c2VfdmNwdXMoKS4KKyAg ICAgKi8KKyAgICBpZiggY3VycmVudC0+ZG9tYWluLT5kb21haW5faWQgPT0gZC0+ZG9tYWluX2lk ICYmCisgICAgICAgIG1lbV9ldmVudF9yaW5nX2ZyZWUoZCwgbWVkKSA8IGQtPm1heF92Y3B1cyAp CisgICAgICAgIG1lbV9ldmVudF9tYXJrX2FuZF9wYXVzZShjdXJyZW50LCBtZWQpOworCiAgICAg bWVtX2V2ZW50X3JpbmdfdW5sb2NrKG1lZCk7CiAKICAgICBub3RpZnlfdmlhX3hlbl9ldmVudF9j aGFubmVsKGQsIG1lZC0+eGVuX3BvcnQpOworCisgICAgcmV0dXJuIDE7CiB9CiAKLXZvaWQgbWVt X2V2ZW50X2dldF9yZXNwb25zZShzdHJ1Y3QgbWVtX2V2ZW50X2RvbWFpbiAqbWVkLCBtZW1fZXZl bnRfcmVzcG9uc2VfdCAqcnNwKQoraW50IG1lbV9ldmVudF9nZXRfcmVzcG9uc2Uoc3RydWN0IGRv bWFpbiAqZCwgc3RydWN0IG1lbV9ldmVudF9kb21haW4gKm1lZCwgbWVtX2V2ZW50X3Jlc3BvbnNl X3QgKnJzcCkKIHsKICAgICBtZW1fZXZlbnRfZnJvbnRfcmluZ190ICpmcm9udF9yaW5nOwogICAg IFJJTkdfSURYIHJzcF9jb25zOwpAQCAtMTU0LDYgKzE5NywxMiBAQCB2b2lkIG1lbV9ldmVudF9n ZXRfcmVzcG9uc2Uoc3RydWN0IG1lbV9lCiAgICAgZnJvbnRfcmluZyA9ICZtZWQtPmZyb250X3Jp bmc7CiAgICAgcnNwX2NvbnMgPSBmcm9udF9yaW5nLT5yc3BfY29uczsKIAorICAgIGlmKCAhUklO R19IQVNfVU5DT05TVU1FRF9SRVNQT05TRVMoZnJvbnRfcmluZykgKQorICAgIHsKKyAgICAgICAg bWVtX2V2ZW50X3JpbmdfdW5sb2NrKG1lZCk7CisgICAgICAgIHJldHVybiAwOworICAgIH0KKwog ICAgIC8qIENvcHkgcmVzcG9uc2UgKi8KICAgICBtZW1jcHkocnNwLCBSSU5HX0dFVF9SRVNQT05T RShmcm9udF9yaW5nLCByc3BfY29ucyksIHNpemVvZigqcnNwKSk7CiAgICAgcnNwX2NvbnMrKzsK QEAgLTE2Myw1NCArMjEyLDY1IEBAIHZvaWQgbWVtX2V2ZW50X2dldF9yZXNwb25zZShzdHJ1Y3Qg bWVtX2UKICAgICBmcm9udF9yaW5nLT5zcmluZy0+cnNwX2V2ZW50ID0gcnNwX2NvbnMgKyAxOwog CiAgICAgbWVtX2V2ZW50X3JpbmdfdW5sb2NrKG1lZCk7CisKKyAgICByZXR1cm4gMTsKIH0KIAot dm9pZCBtZW1fZXZlbnRfdW5wYXVzZV92Y3B1cyhzdHJ1Y3QgZG9tYWluICpkKQordm9pZCBtZW1f ZXZlbnRfdW5wYXVzZV92Y3B1cyhzdHJ1Y3QgZG9tYWluICpkLCBzdHJ1Y3QgbWVtX2V2ZW50X2Rv bWFpbiAqbWVkKQogewogICAgIHN0cnVjdCB2Y3B1ICp2OworICAgIGludCBmcmVlOworICAgIGlu dCBvbmxpbmUgPSBkLT5tYXhfdmNwdXM7CiAKKyAgICBpZiggIW1lZC0+YmxvY2tlZCApCisgICAg ICAgIHJldHVybjsKKworICAgIG1lbV9ldmVudF9yaW5nX2xvY2sobWVkKTsKKyAgICBmcmVlID0g bWVtX2V2ZW50X3JpbmdfZnJlZShkLCBtZWQpOworCisgICAgLyoKKyAgICAgKiBXZSBlbnN1cmUg dGhhdCB3ZSBvbmx5IGhhdmUgdkNQVXMgb25saW5lIGlmIHRoZXJlIGFyZSBlbm91Z2ggZnJlZSBz bG90cworICAgICAqIGZvciB0aGVpciBtZW1vcnkgZXZlbnRzIHRvIGJlIHByb2Nlc3NlZC4gIFRo aXMgd2lsbCBlbnN1cmUgdGhhdCBubworICAgICAqIG1lbW9yeSBldmVudHMgYXJlIGxvc3QgKGR1 ZSB0byB0aGUgZmFjdCB0aGF0IGNlcnRhaW4gdHlwZXMgb2YgZXZlbnRzCisgICAgICogY2Fubm90 IGJlIHJlcGxheWVkLCB3ZSBuZWVkIHRvIGVuc3VyZSB0aGF0IHRoZXJlIGlzIHNwYWNlIGluIHRo ZSByaW5nCisgICAgICogZm9yIHdoZW4gdGhleSBhcmUgaGl0KS4gCisgICAgICogU2VlIGxhcmdl IGNvbW1lbnQgYWJvdmUgaW4gbWVtX2V2ZW50X3B1dF9yZXF1ZXN0KCkuCisgICAgICovCiAgICAg Zm9yX2VhY2hfdmNwdSAoIGQsIHYgKQorICAgICAgICBpZiAoIHRlc3RfYml0KF9WUEZfbWVtX2V2 ZW50LCAmdi0+cGF1c2VfZmxhZ3MpICkKKyAgICAgICAgICAgIG9ubGluZS0tOworIAorICAgIGZv cl9lYWNoX3ZjcHUgKCBkLCB2ICkKKyAgICB7CisgICAgICAgIGlmICggIShtZWQtPmJsb2NrZWQp IHx8IG9ubGluZSA+PSBtZW1fZXZlbnRfcmluZ19mcmVlKGQsIG1lZCkgKQorICAgICAgICAgICAg YnJlYWs7CiAgICAgICAgIGlmICggdGVzdF9hbmRfY2xlYXJfYml0KF9WUEZfbWVtX2V2ZW50LCAm di0+cGF1c2VfZmxhZ3MpICkKKyAgICAgICAgewogICAgICAgICAgICAgdmNwdV93YWtlKHYpOwor ICAgICAgICAgICAgb25saW5lKys7CisgICAgICAgICAgICBtZWQtPmJsb2NrZWQtLTsKKyAgICAg ICAgfQorICAgIH0KKworICAgIG1lbV9ldmVudF9yaW5nX3VubG9jayhtZWQpOwogfQogCi12b2lk IG1lbV9ldmVudF9tYXJrX2FuZF9wYXVzZShzdHJ1Y3QgdmNwdSAqdikKK3ZvaWQgbWVtX2V2ZW50 X21hcmtfYW5kX3BhdXNlKHN0cnVjdCB2Y3B1ICp2LCBzdHJ1Y3QgbWVtX2V2ZW50X2RvbWFpbiAq bWVkKQogewotICAgIHNldF9iaXQoX1ZQRl9tZW1fZXZlbnQsICZ2LT5wYXVzZV9mbGFncyk7Ci0g ICAgdmNwdV9zbGVlcF9ub3N5bmModik7Ci19Ci0KLXZvaWQgbWVtX2V2ZW50X3B1dF9yZXFfcHJv ZHVjZXJzKHN0cnVjdCBtZW1fZXZlbnRfZG9tYWluICptZWQpCi17Ci0gICAgbWVtX2V2ZW50X3Jp bmdfbG9jayhtZWQpOwotICAgIG1lZC0+cmVxX3Byb2R1Y2Vycy0tOwotICAgIG1lbV9ldmVudF9y aW5nX3VubG9jayhtZWQpOworICAgIGlmICggIXRlc3RfYml0KF9WUEZfbWVtX2V2ZW50LCAmdi0+ cGF1c2VfZmxhZ3MpICkKKyAgICB7CisgICAgICAgIHNldF9iaXQoX1ZQRl9tZW1fZXZlbnQsICZ2 LT5wYXVzZV9mbGFncyk7CisgICAgICAgIHZjcHVfc2xlZXBfbm9zeW5jKHYpOworICAgICAgICBt ZWQtPmJsb2NrZWQrKzsKKyAgICB9CiB9CiAKIGludCBtZW1fZXZlbnRfY2hlY2tfcmluZyhzdHJ1 Y3QgZG9tYWluICpkLCBzdHJ1Y3QgbWVtX2V2ZW50X2RvbWFpbiAqbWVkKQogewotICAgIHN0cnVj dCB2Y3B1ICpjdXJyID0gY3VycmVudDsKLSAgICBpbnQgZnJlZV9yZXF1ZXN0czsKLSAgICBpbnQg cmluZ19mdWxsID0gMTsKLQogICAgIGlmICggIW1lZC0+cmluZ19wYWdlICkKICAgICAgICAgcmV0 dXJuIC0xOwogCi0gICAgbWVtX2V2ZW50X3JpbmdfbG9jayhtZWQpOwotCi0gICAgZnJlZV9yZXF1 ZXN0cyA9IFJJTkdfRlJFRV9SRVFVRVNUUygmbWVkLT5mcm9udF9yaW5nKTsKLSAgICBpZiAoIG1l ZC0+cmVxX3Byb2R1Y2VycyA8IGZyZWVfcmVxdWVzdHMgKQotICAgIHsKLSAgICAgICAgbWVkLT5y ZXFfcHJvZHVjZXJzKys7Ci0gICAgICAgIHJpbmdfZnVsbCA9IDA7Ci0gICAgfQotCi0gICAgaWYg KCByaW5nX2Z1bGwgJiYgKGN1cnItPmRvbWFpbiA9PSBkKSApCi0gICAgICAgIG1lbV9ldmVudF9t YXJrX2FuZF9wYXVzZShjdXJyKTsKLQotICAgIG1lbV9ldmVudF9yaW5nX3VubG9jayhtZWQpOwot Ci0gICAgcmV0dXJuIHJpbmdfZnVsbDsKKyAgICByZXR1cm4gMDsKIH0KIAogaW50IG1lbV9ldmVu dF9kb21jdGwoc3RydWN0IGRvbWFpbiAqZCwgeGVuX2RvbWN0bF9tZW1fZXZlbnRfb3BfdCAqbWVj LApkaWZmIC1yIGE0MjJlMmE0NDUxZSB4ZW4vYXJjaC94ODYvbW0vbWVtX3NoYXJpbmcuYwotLS0g YS94ZW4vYXJjaC94ODYvbW0vbWVtX3NoYXJpbmcuYworKysgYi94ZW4vYXJjaC94ODYvbW0vbWVt X3NoYXJpbmcuYwpAQCAtMzAwLDEyICszMDAsMTYgQEAgaW50IG1lbV9zaGFyaW5nX3NoYXJpbmdf cmVzdW1lKHN0cnVjdCBkbwogewogICAgIG1lbV9ldmVudF9yZXNwb25zZV90IHJzcDsKIAotICAg IC8qIEdldCByZXF1ZXN0IG9mZiB0aGUgcmluZyAqLwotICAgIG1lbV9ldmVudF9nZXRfcmVzcG9u c2UoJmQtPm1lbV9zaGFyZSwgJnJzcCk7CisgICAgLyogR2V0IGFsbCByZXF1ZXN0cyBvZmYgdGhl IHJpbmcgKi8KKyAgICB3aGlsZSggbWVtX2V2ZW50X2dldF9yZXNwb25zZShkLCAmZC0+bWVtX3No YXJlLCAmcnNwKSApCisgICAgeworICAgICAgICAvKiBVbnBhdXNlIGRvbWFpbi92Y3B1ICovCisg ICAgICAgIGlmKCByc3AuZmxhZ3MgJiBNRU1fRVZFTlRfRkxBR19WQ1BVX1BBVVNFRCApCisgICAg ICAgICAgICB2Y3B1X3VucGF1c2UoZC0+dmNwdVtyc3AudmNwdV9pZF0pOworICAgIH0KIAotICAg IC8qIFVucGF1c2UgZG9tYWluL3ZjcHUgKi8KLSAgICBpZiggcnNwLmZsYWdzICYgTUVNX0VWRU5U X0ZMQUdfVkNQVV9QQVVTRUQgKQotICAgICAgICB2Y3B1X3VucGF1c2UoZC0+dmNwdVtyc3AudmNw dV9pZF0pOworICAgIC8qIFVucGF1c2UgYW55IGRvbWFpbnMgdGhhdCB3ZXJlIHBhdXNlZCBiZWNh dXNlIHRoZSByaW5nIHdhcyBmdWxsICovCisgICAgbWVtX2V2ZW50X3VucGF1c2VfdmNwdXMoZCwg JmQtPm1lbV9wYWdpbmcpOwogCiAgICAgcmV0dXJuIDA7CiB9CmRpZmYgLXIgYTQyMmUyYTQ0NTFl IHhlbi9hcmNoL3g4Ni9tbS9wMm0uYwotLS0gYS94ZW4vYXJjaC94ODYvbW0vcDJtLmMKKysrIGIv eGVuL2FyY2gveDg2L21tL3AybS5jCkBAIC04MDMsNyArODAzLDYgQEAgdm9pZCBwMm1fbWVtX3Bh Z2luZ19wb3B1bGF0ZShzdHJ1Y3QgZG9tYQogICAgIGVsc2UgaWYgKCBwMm10ICE9IHAybV9yYW1f cGFnaW5nX291dCAmJiBwMm10ICE9IHAybV9yYW1fcGFnZWQgKQogICAgIHsKICAgICAgICAgLyog Z2ZuIGlzIGFscmVhZHkgb24gaXRzIHdheSBiYWNrIGFuZCB2Y3B1IGlzIG5vdCBwYXVzZWQgKi8K LSAgICAgICAgbWVtX2V2ZW50X3B1dF9yZXFfcHJvZHVjZXJzKCZkLT5tZW1fcGFnaW5nKTsKICAg ICAgICAgcmV0dXJuOwogICAgIH0KIApAQCAtODQxLDI2ICs4NDAsMjcgQEAgdm9pZCBwMm1fbWVt X3BhZ2luZ19yZXN1bWUoc3RydWN0IGRvbWFpbgogICAgIHAybV90eXBlX3QgcDJtdDsKICAgICBt Zm5fdCBtZm47CiAKLSAgICAvKiBQdWxsIHRoZSByZXNwb25zZSBvZmYgdGhlIHJpbmcgKi8KLSAg ICBtZW1fZXZlbnRfZ2V0X3Jlc3BvbnNlKCZkLT5tZW1fcGFnaW5nLCAmcnNwKTsKKyAgICAvKiBQ dWxsIGFsbCByZXNwb25zZXMgb2ZmIHRoZSByaW5nICovCisgICAgd2hpbGUoIG1lbV9ldmVudF9n ZXRfcmVzcG9uc2UoZCwgJmQtPm1lbV9wYWdpbmcsICZyc3ApICkKKyAgICB7CisgICAgICAgIC8q IEZpeCBwMm0gZW50cnkgaWYgdGhlIHBhZ2Ugd2FzIG5vdCBkcm9wcGVkICovCisgICAgICAgIGlm ICggIShyc3AuZmxhZ3MgJiBNRU1fRVZFTlRfRkxBR19EUk9QX1BBR0UpICkKKyAgICAgICAgewor ICAgICAgICAgICAgbWZuID0gZ2ZuX3RvX21mbihkLCByc3AuZ2ZuLCAmcDJtdCk7CisgICAgICAg ICAgICBwMm1fbG9jayhwMm0pOworICAgICAgICAgICAgc2V0X3AybV9lbnRyeShwMm0sIHJzcC5n Zm4sIG1mbiwgMCwgcDJtX3JhbV9ydywgcDJtLT5kZWZhdWx0X2FjY2Vzcyk7CisgICAgICAgICAg ICBzZXRfZ3Bmbl9mcm9tX21mbihtZm5feChtZm4pLCByc3AuZ2ZuKTsKKyAgICAgICAgICAgIGF1 ZGl0X3AybShwMm0sIDEpOworICAgICAgICAgICAgcDJtX3VubG9jayhwMm0pOworICAgICAgICB9 CiAKLSAgICAvKiBGaXggcDJtIGVudHJ5IGlmIHRoZSBwYWdlIHdhcyBub3QgZHJvcHBlZCAqLwot ICAgIGlmICggIShyc3AuZmxhZ3MgJiBNRU1fRVZFTlRfRkxBR19EUk9QX1BBR0UpICkKLSAgICB7 Ci0gICAgICAgIG1mbiA9IGdmbl90b19tZm4oZCwgcnNwLmdmbiwgJnAybXQpOwotICAgICAgICBw Mm1fbG9jayhwMm0pOwotICAgICAgICBzZXRfcDJtX2VudHJ5KHAybSwgcnNwLmdmbiwgbWZuLCAw LCBwMm1fcmFtX3J3LCBwMm0tPmRlZmF1bHRfYWNjZXNzKTsKLSAgICAgICAgc2V0X2dwZm5fZnJv bV9tZm4obWZuX3gobWZuKSwgcnNwLmdmbik7Ci0gICAgICAgIGF1ZGl0X3AybShwMm0sIDEpOwot ICAgICAgICBwMm1fdW5sb2NrKHAybSk7CisgICAgICAgIC8qIFVucGF1c2UgZG9tYWluICovCisg ICAgICAgIGlmICggcnNwLmZsYWdzICYgTUVNX0VWRU5UX0ZMQUdfVkNQVV9QQVVTRUQgKQorICAg ICAgICAgICAgdmNwdV91bnBhdXNlKGQtPnZjcHVbcnNwLnZjcHVfaWRdKTsKICAgICB9CiAKLSAg ICAvKiBVbnBhdXNlIGRvbWFpbiAqLwotICAgIGlmICggcnNwLmZsYWdzICYgTUVNX0VWRU5UX0ZM QUdfVkNQVV9QQVVTRUQgKQotICAgICAgICB2Y3B1X3VucGF1c2UoZC0+dmNwdVtyc3AudmNwdV9p ZF0pOwotCiAgICAgLyogVW5wYXVzZSBhbnkgZG9tYWlucyB0aGF0IHdlcmUgcGF1c2VkIGJlY2F1 c2UgdGhlIHJpbmcgd2FzIGZ1bGwgKi8KLSAgICBtZW1fZXZlbnRfdW5wYXVzZV92Y3B1cyhkKTsK KyAgICBtZW1fZXZlbnRfdW5wYXVzZV92Y3B1cyhkLCAmZC0+bWVtX3BhZ2luZyk7CiB9CiAKIHZv aWQgcDJtX21lbV9hY2Nlc3NfY2hlY2sodW5zaWduZWQgbG9uZyBncGEsIGJvb2xfdCBnbGFfdmFs aWQsIHVuc2lnbmVkIGxvbmcgZ2xhLCAKQEAgLTg5OSw3ICs4OTksNyBAQCB2b2lkIHAybV9tZW1f YWNjZXNzX2NoZWNrKHVuc2lnbmVkIGxvbmcgCiAgICAgICAgICAgICAgICAgICAgIk1lbW9yeSBh Y2Nlc3MgcGVybWlzc2lvbnMgZmFpbHVyZSwgbm8gbWVtX2V2ZW50IGxpc3RlbmVyOiBwYXVzaW5n IFZDUFUgJWQsIGRvbSAlZFxuIiwKICAgICAgICAgICAgICAgICAgICB2LT52Y3B1X2lkLCBkLT5k b21haW5faWQpOwogCi0gICAgICAgICAgICBtZW1fZXZlbnRfbWFya19hbmRfcGF1c2Uodik7Cisg ICAgICAgICAgICBtZW1fZXZlbnRfbWFya19hbmRfcGF1c2UodiwgJmQtPm1lbV9hY2Nlc3MpOwog ICAgICAgICB9CiAgICAgICAgIGVsc2UKICAgICAgICAgewpAQCAtOTExLDggKzkxMSw2IEBAIHZv aWQgcDJtX21lbV9hY2Nlc3NfY2hlY2sodW5zaWduZWQgbG9uZyAKIAogICAgICAgICByZXR1cm47 CiAgICAgfQotICAgIGVsc2UgaWYgKCByZXMgPiAwICkKLSAgICAgICAgcmV0dXJuOyAgLyogTm8g c3BhY2UgaW4gYnVmZmVyOyBWQ1BVIHBhdXNlZCAqLwogCiAgICAgbWVtc2V0KCZyZXEsIDAsIHNp emVvZihyZXEpKTsKICAgICByZXEudHlwZSA9IE1FTV9FVkVOVF9UWVBFX0FDQ0VTUzsKQEAgLTk0 MywxNSArOTQxLDE3IEBAIHZvaWQgcDJtX21lbV9hY2Nlc3NfcmVzdW1lKHN0cnVjdCBwMm1fZG8K ICAgICBzdHJ1Y3QgZG9tYWluICpkID0gcDJtLT5kb21haW47CiAgICAgbWVtX2V2ZW50X3Jlc3Bv bnNlX3QgcnNwOwogCi0gICAgbWVtX2V2ZW50X2dldF9yZXNwb25zZSgmZC0+bWVtX2FjY2Vzcywg JnJzcCk7Ci0KLSAgICAvKiBVbnBhdXNlIGRvbWFpbiAqLwotICAgIGlmICggcnNwLmZsYWdzICYg TUVNX0VWRU5UX0ZMQUdfVkNQVV9QQVVTRUQgKQotICAgICAgICB2Y3B1X3VucGF1c2UoZC0+dmNw dVtyc3AudmNwdV9pZF0pOworICAgIC8qIFB1bGwgYWxsIHJlc3BvbnNlcyBvZmYgdGhlIHJpbmcg Ki8KKyAgICB3aGlsZSggbWVtX2V2ZW50X2dldF9yZXNwb25zZShkLCAmZC0+bWVtX2FjY2Vzcywg JnJzcCkgKQorICAgIHsKKyAgICAgICAgLyogVW5wYXVzZSBkb21haW4gKi8KKyAgICAgICAgaWYg KCByc3AuZmxhZ3MgJiBNRU1fRVZFTlRfRkxBR19WQ1BVX1BBVVNFRCApCisgICAgICAgICAgICB2 Y3B1X3VucGF1c2UoZC0+dmNwdVtyc3AudmNwdV9pZF0pOworICAgIH0KIAogICAgIC8qIFVucGF1 c2UgYW55IGRvbWFpbnMgdGhhdCB3ZXJlIHBhdXNlZCBiZWNhdXNlIHRoZSByaW5nIHdhcyBmdWxs IG9yIG5vIGxpc3RlbmVyIAogICAgICAqIHdhcyBhdmFpbGFibGUgKi8KLSAgICBtZW1fZXZlbnRf dW5wYXVzZV92Y3B1cyhkKTsKKyAgICBtZW1fZXZlbnRfdW5wYXVzZV92Y3B1cyhkLCAmZC0+bWVt X2FjY2Vzcyk7CiB9CiAKIApkaWZmIC1yIGE0MjJlMmE0NDUxZSB4ZW4vaW5jbHVkZS9hc20teDg2 L21lbV9ldmVudC5oCi0tLSBhL3hlbi9pbmNsdWRlL2FzbS14ODYvbWVtX2V2ZW50LmgKKysrIGIv eGVuL2luY2x1ZGUvYXNtLXg4Ni9tZW1fZXZlbnQuaApAQCAtMjUsMTIgKzI1LDE4IEBACiAjZGVm aW5lIF9fTUVNX0VWRU5UX0hfXwogCiAvKiBQYXVzZXMgVkNQVSB3aGlsZSBtYXJraW5nIHBhdXNl IGZsYWcgZm9yIG1lbSBldmVudCAqLwotdm9pZCBtZW1fZXZlbnRfbWFya19hbmRfcGF1c2Uoc3Ry dWN0IHZjcHUgKnYpOwordm9pZCBtZW1fZXZlbnRfbWFya19hbmRfcGF1c2Uoc3RydWN0IHZjcHUg KnYsIHN0cnVjdCBtZW1fZXZlbnRfZG9tYWluICptZWQpOwogaW50IG1lbV9ldmVudF9jaGVja19y aW5nKHN0cnVjdCBkb21haW4gKmQsIHN0cnVjdCBtZW1fZXZlbnRfZG9tYWluICptZWQpOwotdm9p ZCBtZW1fZXZlbnRfcHV0X3JlcV9wcm9kdWNlcnMoc3RydWN0IG1lbV9ldmVudF9kb21haW4gKm1l ZCk7Ci12b2lkIG1lbV9ldmVudF9wdXRfcmVxdWVzdChzdHJ1Y3QgZG9tYWluICpkLCBzdHJ1Y3Qg bWVtX2V2ZW50X2RvbWFpbiAqbWVkLCBtZW1fZXZlbnRfcmVxdWVzdF90ICpyZXEpOwotdm9pZCBt ZW1fZXZlbnRfZ2V0X3Jlc3BvbnNlKHN0cnVjdCBtZW1fZXZlbnRfZG9tYWluICptZWQsIG1lbV9l dmVudF9yZXNwb25zZV90ICpyc3ApOwotdm9pZCBtZW1fZXZlbnRfdW5wYXVzZV92Y3B1cyhzdHJ1 Y3QgZG9tYWluICpkKTsKK3ZvaWQgbWVtX2V2ZW50X3VucGF1c2VfdmNwdXMoc3RydWN0IGRvbWFp biAqZCwgc3RydWN0IG1lbV9ldmVudF9kb21haW4gKm1lZCk7CisKKy8qIFJldHVybnMgMCBpZiBy aW5nIGlzIGZ1bGwvZW1wdHkgYW5kIDEgdXBvbiBzdWNjZXNzLgorICogSW4gZWl0aGVyIGNhc2Us IHRoZSB2Q1BVIG1heSBiZSBibG9ja2VkIGFmdGVyd2FyZHMgdG8gZW5zdXJlIHRoYXQgdGhlCisg KiByaW5nIGRvZXMgbm90IGxvc2UgZXZlbnRzLiAgSW4gZ2VuZXJhbCwgcHV0X3JlcXVlc3Qgc2hv dWxkIG5vdCBmYWlsLCBhcworICogaXQgYXR0ZW1wdHMgdG8gZW5zdXJlIHRoYXQgZWFjaCB2Q1BV IGNhbiBwdXQgYXQgbGVhc3Qgb25lIHJlcXVlc3QuICovCitpbnQgbWVtX2V2ZW50X3B1dF9yZXF1 ZXN0KHN0cnVjdCBkb21haW4gKmQsIHN0cnVjdCBtZW1fZXZlbnRfZG9tYWluICptZWQsCisgICAg ICAgICAgICAgICAgICAgICAgICAgICAgbWVtX2V2ZW50X3JlcXVlc3RfdCAqcmVxKTsKK2ludCBt ZW1fZXZlbnRfZ2V0X3Jlc3BvbnNlKHN0cnVjdCBkb21haW4gKmQsIHN0cnVjdCBtZW1fZXZlbnRf ZG9tYWluICptZWQsCisgICAgICAgICAgICAgICAgICAgICAgICAgICAgbWVtX2V2ZW50X3Jlc3Bv bnNlX3QgKnJzcCk7CiAKIGludCBtZW1fZXZlbnRfZG9tY3RsKHN0cnVjdCBkb21haW4gKmQsIHhl bl9kb21jdGxfbWVtX2V2ZW50X29wX3QgKm1lYywKICAgICAgICAgICAgICAgICAgICAgIFhFTl9H VUVTVF9IQU5ETEUodm9pZCkgdV9kb21jdGwpOwpkaWZmIC1yIGE0MjJlMmE0NDUxZSB4ZW4vaW5j bHVkZS94ZW4vc2NoZWQuaAotLS0gYS94ZW4vaW5jbHVkZS94ZW4vc2NoZWQuaAorKysgYi94ZW4v aW5jbHVkZS94ZW4vc2NoZWQuaApAQCAtMTgzLDEzICsxODMsMTQgQEAgc3RydWN0IG1lbV9ldmVu dF9kb21haW4KIHsKICAgICAvKiByaW5nIGxvY2sgKi8KICAgICBzcGlubG9ja190IHJpbmdfbG9j azsKLSAgICB1bnNpZ25lZCBpbnQgcmVxX3Byb2R1Y2VyczsKICAgICAvKiBzaGFyZWQgcGFnZSAq LwogICAgIG1lbV9ldmVudF9zaGFyZWRfcGFnZV90ICpzaGFyZWRfcGFnZTsKICAgICAvKiBzaGFy ZWQgcmluZyBwYWdlICovCiAgICAgdm9pZCAqcmluZ19wYWdlOwogICAgIC8qIGZyb250LWVuZCBy aW5nICovCiAgICAgbWVtX2V2ZW50X2Zyb250X3JpbmdfdCBmcm9udF9yaW5nOworICAgIC8qIHRo ZSBudW1iZXIgb2YgdkNQVXMgYmxvY2tlZCAqLworICAgIHVuc2lnbmVkIGludCBibG9ja2VkOwog ICAgIC8qIGV2ZW50IGNoYW5uZWwgcG9ydCAodmNwdTAgb25seSkgKi8KICAgICBpbnQgeGVuX3Bv cnQ7CiB9Owo= --00151743f96458cfa604ae070719 Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel --00151743f96458cfa604ae070719-- From xen-devel-bounces@lists.xensource.com Wed Sep 28 14:27:04 2011 Return-path: <xen-devel-bounces@lists.xensource.com> Envelope-to: www-data@lists.xensource.com Delivery-date: Wed, 28 Sep 2011 14:27:04 -0700 Received: from localhost ([127.0.0.1] helo=lists.colo.xensource.com) by lists.xensource.com with esmtp (Exim 4.43) id 1R91ei-0000k9-A0; Wed, 28 Sep 2011 14:27:04 -0700 Received: from mail27.messagelabs.com ([193.109.254.147]) by lists.xensource.com with esmtp (Exim 4.43) id 1R91dX-0000F8-Eb for xen-devel@lists.xensource.com; Wed, 28 Sep 2011 14:25:52 -0700 X-Env-Sender: amscanne@gridcentric.ca X-Msg-Ref: server-11.tower-27.messagelabs.com!1317245109!39330367!2 X-Originating-IP: [209.85.161.43] X-StarScan-Version: 6.4.1; banners=-,-,- X-VirusChecked: Checked Received: (qmail 29511 invoked from network); 28 Sep 2011 21:25:39 -0000 Received: from mail-fx0-f43.google.com (HELO mail-fx0-f43.google.com) (209.85.161.43) by server-11.tower-27.messagelabs.com with RC4-SHA encrypted SMTP; 28 Sep 2011 21:25:39 -0000 Received: by mail-fx0-f43.google.com with SMTP id 19so1381898fxh.30 for <xen-devel@lists.xensource.com>; Wed, 28 Sep 2011 14:25:48 -0700 (PDT) Received: by 10.223.48.69 with SMTP id q5mr15063258faf.80.1317245148148; Wed, 28 Sep 2011 14:25:48 -0700 (PDT) MIME-Version: 1.0 Received: by 10.223.101.194 with HTTP; Wed, 28 Sep 2011 14:25:28 -0700 (PDT) From: Adin Scannell <adin@gridcentric.com> Date: Wed, 28 Sep 2011 17:25:28 -0400 X-Google-Sender-Auth: HkfR5ndcVZUr2i1z8WZU5v8iIds Message-ID: <CAAJKtqrQZC4JhCAQvmLdjx72wXVHF_29U8F4K4ESUf0MMmbnXA@mail.gmail.com> To: xen-devel@lists.xensource.com Content-Type: multipart/mixed; boundary=00151744133223360804ae0709ad Subject: [Xen-devel] [PATCH 2/2] enable event channel wake-up for mem_event interfaces X-BeenThere: xen-devel@lists.xensource.com X-Mailman-Version: 2.1.5 Precedence: list List-Id: Xen developer discussion <xen-devel.lists.xensource.com> List-Unsubscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe> List-Post: <mailto:xen-devel@lists.xensource.com> List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help> List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=subscribe> Sender: xen-devel-bounces@lists.xensource.com Errors-To: xen-devel-bounces@lists.xensource.com --00151744133223360804ae0709ad Content-Type: text/plain; charset=ISO-8859-1 --00151744133223360804ae0709ad Content-Type: application/octet-stream; name="memevent-event-notify.patch" Content-Disposition: attachment; filename="memevent-event-notify.patch" Content-Transfer-Encoding: base64 X-Attachment-Id: f_gt4tqb0f0 RG9uJ3QgcmVxdWlyZSBhIHNlcGFyYXRlIGRvbWN0bCB0byBub3RpZnkgdGhlIG1lbWV2ZW50IGlu dGVyZmFjZSB0aGF0IGFuIGV2ZW50CmhhcyBvY2N1cmVkLiAgVGhpcyBkb21jdGwgY2FuIGJlIHRh eGluZywgcGFydGljdWxhcmx5IHdoZW4geW91IGFyZSBzY2FsaW5nCmV2ZW50cyBhbmQgcGFnaW5n IHRvIG1hbnkgZG9tYWlucyBhY3Jvc3MgYSBzaW5nbGUgc3lzdGVtLiAgSW5zdGVhZCwgd2UgdXNl IHRoZQpleGlzdGluZyBldmVudCBjaGFubmVsIHRvIHNpZ25hbCB3aGVuIHdlIHBsYWNlIHNvbWV0 aGluZyBpbiB0aGUgcmluZyAoYXMgcGVyCm5vcm1hbCByaW5nIG9wZXJhdGlvbikuCgpTaWduZWQt b2ZmLWJ5OiBBZGluIFNjYW5uZWxsIDxhZGluQHNjYW5uZWxsLmNhPgoKZGlmZiAtciBlNTgxZWQ4 MTYyMjQgeGVuL2FyY2gvaWE2NC94ZW4vTWFrZWZpbGUKLS0tIGEveGVuL2FyY2gvaWE2NC94ZW4v TWFrZWZpbGUKKysrIGIveGVuL2FyY2gvaWE2NC94ZW4vTWFrZWZpbGUKQEAgLTM4LDYgKzM4LDcg QEAgb2JqLXkgKz0gZmx1c2hkLm8KIG9iai15ICs9IHByaXZvcF9zdGF0Lm8KIG9iai15ICs9IHhl bnBhdGNoLm8KIG9iai15ICs9IHBjaS5vCitvYmoteSArPSBldmVudHMubwogCiBvYmotJChjcmFz aF9kZWJ1ZykgKz0gZ2Ric3R1Yi5vCiBvYmotJCh4ZW5faWE2NF90bGJfdHJhY2spICs9IHRsYl90 cmFjay5vCmRpZmYgLXIgZTU4MWVkODE2MjI0IHhlbi9hcmNoL2lhNjQveGVuL2V2ZW50cy5jCi0t LSAvZGV2L251bGwKKysrIGIveGVuL2FyY2gvaWE2NC94ZW4vZXZlbnRzLmMKQEAgLTAsMCArMSwy NyBAQAorLyoqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioq KioqKioqKioqKioqKioqKioqKioqKioqKioqKgorICogZXZlbnRzLmMKKyAqIAorICogQXJjaC1z cGVjaWZpYyBldmVudCBjaGFubmVscy4KKyAqLworCisjaW5jbHVkZSA8eGVuL2NvbmZpZy5oPgor I2luY2x1ZGUgPHhlbi9lcnJuby5oPgorI2luY2x1ZGUgPHhlbi9zY2hlZC5oPgorI2luY2x1ZGUg PHhlbi9ldmVudC5oPgorCitpbnQgYXJjaF9ldmVudF9ub3RpZnkoc3RydWN0IHZjcHUgKnYsIGlu dCBwb3J0KQoreworICAgIGludCByZXQgPSAwOworCisgICAgaWYoIHBvcnQgPT0gdi0+YXJjaC5o dm1fdmNwdS54ZW5fcG9ydCApCisgICAgeworICAgICAgICBpZiggdGVzdF9hbmRfY2xlYXJfYml0 KF9WUEZfYmxvY2tlZF9pbl94ZW4sICZ2LT5wYXVzZV9mbGFncykgKQorICAgICAgICAgICAgdmNw dV93YWtlKHYpOworICAgIH0KKyAgICBlbHNlCisgICAgeworICAgICAgICByZXQgPSAtRUlOVkFM OworICAgIH0KKworICAgIHJldHVybiByZXQ7Cit9CmRpZmYgLXIgZTU4MWVkODE2MjI0IHhlbi9h cmNoL3g4Ni9NYWtlZmlsZQotLS0gYS94ZW4vYXJjaC94ODYvTWFrZWZpbGUKKysrIGIveGVuL2Fy Y2gveDg2L01ha2VmaWxlCkBAIC01Nyw2ICs1Nyw3IEBAIG9iai15ICs9IGNyYXNoLm8KIG9iai15 ICs9IHRib290Lm8KIG9iai15ICs9IGhwZXQubwogb2JqLXkgKz0geHN0YXRlLm8KK29iai15ICs9 IGV2ZW50cy5vCiAKIG9iai0kKGNyYXNoX2RlYnVnKSArPSBnZGJzdHViLm8KIApkaWZmIC1yIGU1 ODFlZDgxNjIyNCB4ZW4vYXJjaC94ODYvZXZlbnRzLmMKLS0tIC9kZXYvbnVsbAorKysgYi94ZW4v YXJjaC94ODYvZXZlbnRzLmMKQEAgLTAsMCArMSw0MSBAQAorLyoqKioqKioqKioqKioqKioqKioq KioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioq KgorICogZXZlbnRzLmMKKyAqIAorICogQXJjaC1zcGVjaWZpYyBldmVudCBjaGFubmVscy4KKyAq LworCisjaW5jbHVkZSA8eGVuL2NvbmZpZy5oPgorI2luY2x1ZGUgPHhlbi9lcnJuby5oPgorI2lu Y2x1ZGUgPHhlbi9zY2hlZC5oPgorI2luY2x1ZGUgPHhlbi9ldmVudC5oPgorI2luY2x1ZGUgPGFz bS9tZW1fZXZlbnQuaD4KKyNpbmNsdWRlIDxhc20vbWVtX3NoYXJpbmcuaD4KKworaW50IGFyY2hf ZXZlbnRfbm90aWZ5KHN0cnVjdCB2Y3B1ICp2LCBpbnQgcG9ydCkKK3sKKyAgICBpbnQgcmV0ID0g MDsKKworICAgIGlmKCBwb3J0ID09IHYtPmFyY2guaHZtX3ZjcHUueGVuX3BvcnQgKQorICAgIHsK KyAgICAgICAgaWYoIHRlc3RfYW5kX2NsZWFyX2JpdChfVlBGX2Jsb2NrZWRfaW5feGVuLCAmdi0+ cGF1c2VfZmxhZ3MpICkKKyAgICAgICAgICAgIHZjcHVfd2FrZSh2KTsKKyAgICB9CisgICAgZWxz ZSBpZiAoIHBvcnQgPT0gdi0+ZG9tYWluLT5tZW1fcGFnaW5nLnhlbl9wb3J0ICkKKyAgICB7Cisg ICAgICAgIHJldCA9IHAybV9tZW1fcGFnaW5nX3Jlc3VtZSh2LT5kb21haW4pOworICAgIH0KKyAg ICBlbHNlIGlmICggcG9ydCA9PSB2LT5kb21haW4tPm1lbV9hY2Nlc3MueGVuX3BvcnQgKQorICAg IHsKKyAgICAgICAgcmV0ID0gcDJtX21lbV9hY2Nlc3NfcmVzdW1lKHYtPmRvbWFpbik7CisgICAg fQorICAgIGVsc2UgaWYgKCBwb3J0ID09IHYtPmRvbWFpbi0+bWVtX3NoYXJlLnhlbl9wb3J0ICkK KyAgICB7CisgICAgICAgIHJldCA9IG1lbV9zaGFyaW5nX3NoYXJpbmdfcmVzdW1lKHYtPmRvbWFp bik7CisgICAgfQorICAgIGVsc2UKKyAgICB7CisgICAgICAgIHJldCA9IC1FSU5WQUw7CisgICAg fQorCisgICAgcmV0dXJuIHJldDsKK30KZGlmZiAtciBlNTgxZWQ4MTYyMjQgeGVuL2FyY2gveDg2 L21tL21lbV9hY2Nlc3MuYwotLS0gYS94ZW4vYXJjaC94ODYvbW0vbWVtX2FjY2Vzcy5jCisrKyBi L3hlbi9hcmNoL3g4Ni9tbS9tZW1fYWNjZXNzLmMKQEAgLTI5LDEzICsyOSwxMiBAQCBpbnQgbWVt X2FjY2Vzc19kb21jdGwoc3RydWN0IGRvbWFpbiAqZCwgCiAgICAgICAgICAgICAgICAgICAgICAg WEVOX0dVRVNUX0hBTkRMRSh2b2lkKSB1X2RvbWN0bCkKIHsKICAgICBpbnQgcmM7Ci0gICAgc3Ry dWN0IHAybV9kb21haW4gKnAybSA9IHAybV9nZXRfaG9zdHAybShkKTsKIAogICAgIHN3aXRjaCgg bWVjLT5vcCApCiAgICAgewogICAgIGNhc2UgWEVOX0RPTUNUTF9NRU1fRVZFTlRfT1BfQUNDRVNT X1JFU1VNRToKICAgICB7Ci0gICAgICAgIHAybV9tZW1fYWNjZXNzX3Jlc3VtZShwMm0pOworICAg ICAgICBwMm1fbWVtX2FjY2Vzc19yZXN1bWUoZCk7CiAgICAgICAgIHJjID0gMDsKICAgICB9CiAg ICAgYnJlYWs7CmRpZmYgLXIgZTU4MWVkODE2MjI0IHhlbi9hcmNoL3g4Ni9tbS9tZW1fcGFnaW5n LmMKLS0tIGEveGVuL2FyY2gveDg2L21tL21lbV9wYWdpbmcuYworKysgYi94ZW4vYXJjaC94ODYv bW0vbWVtX3BhZ2luZy5jCkBAIC02NCw3ICs2NCw2IEBAIGludCBtZW1fcGFnaW5nX2RvbWN0bChz dHJ1Y3QgZG9tYWluICpkLCAKICAgICB9CiB9CiAKLQogLyoKICAqIExvY2FsIHZhcmlhYmxlczoK ICAqIG1vZGU6IEMKZGlmZiAtciBlNTgxZWQ4MTYyMjQgeGVuL2FyY2gveDg2L21tL3AybS5jCi0t LSBhL3hlbi9hcmNoL3g4Ni9tbS9wMm0uYworKysgYi94ZW4vYXJjaC94ODYvbW0vcDJtLmMKQEAg LTgzMyw3ICs4MzMsNyBAQCBpbnQgcDJtX21lbV9wYWdpbmdfcHJlcChzdHJ1Y3QgZG9tYWluICpk CiAgICAgcmV0dXJuIDA7CiB9CiAKLXZvaWQgcDJtX21lbV9wYWdpbmdfcmVzdW1lKHN0cnVjdCBk b21haW4gKmQpCitpbnQgcDJtX21lbV9wYWdpbmdfcmVzdW1lKHN0cnVjdCBkb21haW4gKmQpCiB7 CiAgICAgc3RydWN0IHAybV9kb21haW4gKnAybSA9IHAybV9nZXRfaG9zdHAybShkKTsKICAgICBt ZW1fZXZlbnRfcmVzcG9uc2VfdCByc3A7CkBAIC04NjEsNiArODYxLDggQEAgdm9pZCBwMm1fbWVt X3BhZ2luZ19yZXN1bWUoc3RydWN0IGRvbWFpbgogCiAgICAgLyogVW5wYXVzZSBhbnkgZG9tYWlu cyB0aGF0IHdlcmUgcGF1c2VkIGJlY2F1c2UgdGhlIHJpbmcgd2FzIGZ1bGwgKi8KICAgICBtZW1f ZXZlbnRfdW5wYXVzZV92Y3B1cyhkLCAmZC0+bWVtX3BhZ2luZyk7CisKKyAgICByZXR1cm4gMDsK IH0KIAogdm9pZCBwMm1fbWVtX2FjY2Vzc19jaGVjayh1bnNpZ25lZCBsb25nIGdwYSwgYm9vbF90 IGdsYV92YWxpZCwgdW5zaWduZWQgbG9uZyBnbGEsIApAQCAtOTM2LDkgKzkzOCw4IEBAIHZvaWQg cDJtX21lbV9hY2Nlc3NfY2hlY2sodW5zaWduZWQgbG9uZyAKICAgICAvKiBWQ1BVIHBhdXNlZCwg bWVtIGV2ZW50IHJlcXVlc3Qgc2VudCAqLwogfQogCi12b2lkIHAybV9tZW1fYWNjZXNzX3Jlc3Vt ZShzdHJ1Y3QgcDJtX2RvbWFpbiAqcDJtKQoraW50IHAybV9tZW1fYWNjZXNzX3Jlc3VtZShzdHJ1 Y3QgZG9tYWluICpkKQogewotICAgIHN0cnVjdCBkb21haW4gKmQgPSBwMm0tPmRvbWFpbjsKICAg ICBtZW1fZXZlbnRfcmVzcG9uc2VfdCByc3A7CiAKICAgICAvKiBQdWxsIGFsbCByZXNwb25zZXMg b2ZmIHRoZSByaW5nICovCkBAIC05NTIsNiArOTUzLDggQEAgdm9pZCBwMm1fbWVtX2FjY2Vzc19y ZXN1bWUoc3RydWN0IHAybV9kbwogICAgIC8qIFVucGF1c2UgYW55IGRvbWFpbnMgdGhhdCB3ZXJl IHBhdXNlZCBiZWNhdXNlIHRoZSByaW5nIHdhcyBmdWxsIG9yIG5vIGxpc3RlbmVyIAogICAgICAq IHdhcyBhdmFpbGFibGUgKi8KICAgICBtZW1fZXZlbnRfdW5wYXVzZV92Y3B1cyhkLCAmZC0+bWVt X2FjY2Vzcyk7CisKKyAgICByZXR1cm4gMDsKIH0KIAogCmRpZmYgLXIgZTU4MWVkODE2MjI0IHhl bi9jb21tb24vZXZlbnRfY2hhbm5lbC5jCi0tLSBhL3hlbi9jb21tb24vZXZlbnRfY2hhbm5lbC5j CisrKyBiL3hlbi9jb21tb24vZXZlbnRfY2hhbm5lbC5jCkBAIC01Nyw2ICs1Nyw4IEBACiAgICAg ICAgIGdvdG8gb3V0OyAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgIFwKICAgICB9IHdoaWxlICggMCApCiAKK2V4dGVybiBpbnQgYXJjaF9ldmVudF9ub3Rp Znkoc3RydWN0IHZjcHUgKnYsIGludCBwb3J0KTsKKwogc3RhdGljIGludCBldnRjaG5fc2V0X3Bl bmRpbmcoc3RydWN0IHZjcHUgKnYsIGludCBwb3J0KTsKIAogc3RhdGljIGludCB2aXJxX2lzX2ds b2JhbChpbnQgdmlycSkKQEAgLTU1MywxMCArNTU1LDcgQEAgaW50IGV2dGNobl9zZW5kKHN0cnVj dCBkb21haW4gKmQsIHVuc2lnbgogICAgICAgICBydmNwdSA9IHJkLT52Y3B1W3JjaG4tPm5vdGlm eV92Y3B1X2lkXTsKICAgICAgICAgaWYgKCByY2huLT5jb25zdW1lcl9pc194ZW4gKQogICAgICAg ICB7Ci0gICAgICAgICAgICAvKiBYZW4gY29uc3VtZXJzIG5lZWQgbm90aWZpY2F0aW9uIG9ubHkg aWYgdGhleSBhcmUgYmxvY2tlZC4gKi8KLSAgICAgICAgICAgIGlmICggdGVzdF9hbmRfY2xlYXJf Yml0KF9WUEZfYmxvY2tlZF9pbl94ZW4sCi0gICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAmcnZjcHUtPnBhdXNlX2ZsYWdzKSApCi0gICAgICAgICAgICAgICAgdmNwdV93YWtlKHJ2 Y3B1KTsKKyAgICAgICAgICAgIHJldCA9IGFyY2hfZXZlbnRfbm90aWZ5KHJ2Y3B1LCBycG9ydCk7 CiAgICAgICAgIH0KICAgICAgICAgZWxzZQogICAgICAgICB7CmRpZmYgLXIgZTU4MWVkODE2MjI0 IHhlbi9pbmNsdWRlL2FzbS14ODYvbWVtX2V2ZW50LmgKLS0tIGEveGVuL2luY2x1ZGUvYXNtLXg4 Ni9tZW1fZXZlbnQuaAorKysgYi94ZW4vaW5jbHVkZS9hc20teDg2L21lbV9ldmVudC5oCkBAIC0y NCw2ICsyNCw4IEBACiAjaWZuZGVmIF9fTUVNX0VWRU5UX0hfXwogI2RlZmluZSBfX01FTV9FVkVO VF9IX18KIAorI2luY2x1ZGUgPGFzbS9wMm0uaD4KKwogLyogUGF1c2VzIFZDUFUgd2hpbGUgbWFy a2luZyBwYXVzZSBmbGFnIGZvciBtZW0gZXZlbnQgKi8KIHZvaWQgbWVtX2V2ZW50X21hcmtfYW5k X3BhdXNlKHN0cnVjdCB2Y3B1ICp2LCBzdHJ1Y3QgbWVtX2V2ZW50X2RvbWFpbiAqbWVkKTsKIGlu dCBtZW1fZXZlbnRfY2hlY2tfcmluZyhzdHJ1Y3QgZG9tYWluICpkLCBzdHJ1Y3QgbWVtX2V2ZW50 X2RvbWFpbiAqbWVkKTsKZGlmZiAtciBlNTgxZWQ4MTYyMjQgeGVuL2luY2x1ZGUvYXNtLXg4Ni9t ZW1fc2hhcmluZy5oCi0tLSBhL3hlbi9pbmNsdWRlL2FzbS14ODYvbWVtX3NoYXJpbmcuaAorKysg Yi94ZW4vaW5jbHVkZS9hc20teDg2L21lbV9zaGFyaW5nLmgKQEAgLTQ3LDYgKzQ3LDkgQEAgdm9p ZCBtZW1fc2hhcmluZ19pbml0KHZvaWQpOwogCiAjZGVmaW5lIG1lbV9zaGFyaW5nX2luaXQoKSAg ZG8geyB9IHdoaWxlICgwKQogCitzdGF0aWMgaW5saW5lIGludCBtZW1fc2hhcmluZ19zaGFyaW5n X3Jlc3VtZShzdHJ1Y3QgZG9tYWluICpkKQoreyByZXR1cm4gLUVJTlZBTDsgfQorCiAjZW5kaWYg LyogX194ODZfNjRfXyAqLwogCiAjZW5kaWYgLyogX19NRU1fU0hBUklOR19IX18gKi8KZGlmZiAt ciBlNTgxZWQ4MTYyMjQgeGVuL2luY2x1ZGUvYXNtLXg4Ni9wMm0uaAotLS0gYS94ZW4vaW5jbHVk ZS9hc20teDg2L3AybS5oCisrKyBiL3hlbi9pbmNsdWRlL2FzbS14ODYvcDJtLmgKQEAgLTQ4OSwx MiArNDg5LDE0IEBAIHZvaWQgcDJtX21lbV9wYWdpbmdfcG9wdWxhdGUoc3RydWN0IGRvbWEKIC8q IFByZXBhcmUgdGhlIHAybSBmb3IgcGFnaW5nIGEgZnJhbWUgaW4gKi8KIGludCBwMm1fbWVtX3Bh Z2luZ19wcmVwKHN0cnVjdCBkb21haW4gKmQsIHVuc2lnbmVkIGxvbmcgZ2ZuKTsKIC8qIFJlc3Vt ZSBub3JtYWwgb3BlcmF0aW9uIChpbiBjYXNlIGEgZG9tYWluIHdhcyBwYXVzZWQpICovCi12b2lk IHAybV9tZW1fcGFnaW5nX3Jlc3VtZShzdHJ1Y3QgZG9tYWluICpkKTsKK2ludCBwMm1fbWVtX3Bh Z2luZ19yZXN1bWUoc3RydWN0IGRvbWFpbiAqZCk7CiAjZWxzZQogc3RhdGljIGlubGluZSB2b2lk IHAybV9tZW1fcGFnaW5nX2Ryb3BfcGFnZShzdHJ1Y3QgZG9tYWluICpkLCB1bnNpZ25lZCBsb25n IGdmbikKIHsgfQogc3RhdGljIGlubGluZSB2b2lkIHAybV9tZW1fcGFnaW5nX3BvcHVsYXRlKHN0 cnVjdCBkb21haW4gKmQsIHVuc2lnbmVkIGxvbmcgZ2ZuKQogeyB9CitzdGF0aWMgaW5saW5lIGlu dCBwMm1fbWVtX3BhZ2luZ19yZXN1bWUoc3RydWN0IGRvbWFpbiAqZCkKK3sgcmV0dXJuIC1FSU5W QUw7IH0KICNlbmRpZgogCiAjaWZkZWYgX194ODZfNjRfXwpAQCAtNTAzLDcgKzUwNSw3IEBAIHN0 YXRpYyBpbmxpbmUgdm9pZCBwMm1fbWVtX3BhZ2luZ19wb3B1bGEKIHZvaWQgcDJtX21lbV9hY2Nl c3NfY2hlY2sodW5zaWduZWQgbG9uZyBncGEsIGJvb2xfdCBnbGFfdmFsaWQsIHVuc2lnbmVkIGxv bmcgZ2xhLCAKICAgICAgICAgICAgICAgICAgICAgICAgICAgYm9vbF90IGFjY2Vzc19yLCBib29s X3QgYWNjZXNzX3csIGJvb2xfdCBhY2Nlc3NfeCk7CiAvKiBSZXN1bWVzIHRoZSBydW5uaW5nIG9m IHRoZSBWQ1BVLCByZXN0YXJ0aW5nIHRoZSBsYXN0IGluc3RydWN0aW9uICovCi12b2lkIHAybV9t ZW1fYWNjZXNzX3Jlc3VtZShzdHJ1Y3QgcDJtX2RvbWFpbiAqcDJtKTsKK2ludCBwMm1fbWVtX2Fj Y2Vzc19yZXN1bWUoc3RydWN0IGRvbWFpbiAqZCk7CiAKIC8qIFNldCBhY2Nlc3MgdHlwZSBmb3Ig YSByZWdpb24gb2YgcGZucy4KICAqIElmIHN0YXJ0X3BmbiA9PSAtMXVsLCBzZXRzIHRoZSBkZWZh dWx0IGFjY2VzcyB0eXBlICovCkBAIC01MjcsNiArNTI5LDggQEAgc3RhdGljIGlubGluZSBpbnQg cDJtX3NldF9tZW1fYWNjZXNzKHN0cgogc3RhdGljIGlubGluZSBpbnQgcDJtX2dldF9tZW1fYWNj ZXNzKHN0cnVjdCBkb21haW4gKmQsIHVuc2lnbmVkIGxvbmcgcGZuLCAKICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICBodm1tZW1fYWNjZXNzX3QgKmFjY2VzcykKIHsgcmV0dXJu IC1FSU5WQUw7IH0KK3N0YXRpYyBpbmxpbmUgaW50IHAybV9tZW1fYWNjZXNzX3Jlc3VtZShzdHJ1 Y3QgZG9tYWluICpkKQoreyByZXR1cm4gLUVJTlZBTDsgfQogI2VuZGlmCiAKIC8qIAo= --00151744133223360804ae0709ad Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel --00151744133223360804ae0709ad-- From xen-devel-bounces@lists.xensource.com Wed Sep 28 14:32:00 2011 Return-path: <xen-devel-bounces@lists.xensource.com> Envelope-to: www-data@lists.xensource.com Delivery-date: Wed, 28 Sep 2011 14:32:00 -0700 Received: from localhost ([127.0.0.1] helo=lists.colo.xensource.com) by lists.xensource.com with esmtp (Exim 4.43) id 1R91jU-0001Dg-Ev; Wed, 28 Sep 2011 14:32:00 -0700 Received: from mail174.messagelabs.com ([85.158.138.51]) by lists.xensource.com with esmtp (Exim 4.43) id 1R91iy-0000yk-O9 for xen-devel@lists.xensource.com; Wed, 28 Sep 2011 14:31:29 -0700 X-Env-Sender: amscanne@gridcentric.ca X-Msg-Ref: server-5.tower-174.messagelabs.com!1317245485!29443588!1 X-Originating-IP: [209.85.161.43] X-StarScan-Version: 6.4.1; banners=-,-,- X-VirusChecked: Checked Received: (qmail 28970 invoked from network); 28 Sep 2011 21:31:25 -0000 Received: from mail-fx0-f43.google.com (HELO mail-fx0-f43.google.com) (209.85.161.43) by server-5.tower-174.messagelabs.com with RC4-SHA encrypted SMTP; 28 Sep 2011 21:31:25 -0000 Received: by fxh19 with SMTP id 19so1388586fxh.30 for <xen-devel@lists.xensource.com>; Wed, 28 Sep 2011 14:31:25 -0700 (PDT) Received: by 10.223.45.198 with SMTP id g6mr2706833faf.118.1317245485218; Wed, 28 Sep 2011 14:31:25 -0700 (PDT) MIME-Version: 1.0 Received: by 10.223.101.194 with HTTP; Wed, 28 Sep 2011 14:31:05 -0700 (PDT) From: Adin Scannell <adin@gridcentric.com> Date: Wed, 28 Sep 2011 17:31:05 -0400 X-Google-Sender-Auth: LKqCB5owi5Cp-GpLx4eENHpDI3c Message-ID: <CAAJKtqre0Q3qbngZi01NfmSQSh0YXtSyS4LZc=cOQt98Xqzcyw@mail.gmail.com> To: xen-devel@lists.xensource.com Content-Type: multipart/mixed; boundary=0015173fe8223a7d3804ae071d80 Subject: [Xen-devel] [PATCH] build fixes for cross-compiling X-BeenThere: xen-devel@lists.xensource.com X-Mailman-Version: 2.1.5 Precedence: list List-Id: Xen developer discussion <xen-devel.lists.xensource.com> List-Unsubscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe> List-Post: <mailto:xen-devel@lists.xensource.com> List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help> List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=subscribe> Sender: xen-devel-bounces@lists.xensource.com Errors-To: xen-devel-bounces@lists.xensource.com --0015173fe8223a7d3804ae071d80 Content-Type: text/plain; charset=ISO-8859-1 I always have problems cross-compiling tools (I build everything on a 64-bit machine and generally target a 32-bit host), because all the link steps are missing targets. I've use this tiny patch on the base of my workspaces. To my knowledge, this doesn't break anything -- but who knows with builds, particularly cross-compiling. I just thought I'd throw this there in case others have the same issue and it doesn't affect standard build environments. diff -r a422e2a4451e config/x86_32.mk --- a/config/x86_32.mk +++ b/config/x86_32.mk @@ -8,6 +8,7 @@ CONFIG_XCUTILS := y CONFIG_IOEMU := y CFLAGS += -m32 -march=i686 +LDFLAGS += -m32 -march=i686 # Use only if calling $(LD) directly. LDFLAGS_DIRECT_OpenBSD = _obsd diff -r a422e2a4451e config/x86_64.mk --- a/config/x86_64.mk +++ b/config/x86_64.mk @@ -9,6 +9,7 @@ CONFIG_XCUTILS := y CONFIG_IOEMU := y CFLAGS += -m64 +LDFLAGS += -m64 LIBLEAFDIR = $(LIBLEAFDIR_x86_64) LIBDIR = $(LIBDIR_x86_64) --0015173fe8223a7d3804ae071d80 Content-Type: application/octet-stream; name="build-fixes.patch" Content-Disposition: attachment; filename="build-fixes.patch" Content-Transfer-Encoding: base64 X-Attachment-Id: f_gt4trzik0 Rm9yIGNyb3NzLWNvbXBpbGluZywgdGhlIGxpbmsgc3RlcCBtdXN0IGFsc28gaW5jbHVkZSBuZWNl c3NhcnkgYXJjaGl0ZWN0dXJlCmZsYWdzIChvdGhlcndpc2UgdGhlcmUncyBhIG1pc21hdGNoIGJl dHdlZW4gaW5wdXQgb2JqZWN0cyBhbmQgdGhlIG91dHB1dCB3ZSdyZQp0cnlpbmcgdG8gcHJvZHVj ZSkuCgpTaWduZWQtb2ZmLWJ5OiBBZGluIFNjYW5uZWxsIDxhZGluQHNjYW5uZWxsLmNhPgoKZGlm ZiAtciBhNDIyZTJhNDQ1MWUgY29uZmlnL3g4Nl8zMi5tawotLS0gYS9jb25maWcveDg2XzMyLm1r CisrKyBiL2NvbmZpZy94ODZfMzIubWsKQEAgLTgsNiArOCw3IEBAIENPTkZJR19YQ1VUSUxTIDo9 IHkKIENPTkZJR19JT0VNVSA6PSB5CiAKIENGTEFHUyArPSAtbTMyIC1tYXJjaD1pNjg2CitMREZM QUdTICs9IC1tMzIgLW1hcmNoPWk2ODYKIAogIyBVc2Ugb25seSBpZiBjYWxsaW5nICQoTEQpIGRp cmVjdGx5LgogTERGTEFHU19ESVJFQ1RfT3BlbkJTRCA9IF9vYnNkCmRpZmYgLXIgYTQyMmUyYTQ0 NTFlIGNvbmZpZy94ODZfNjQubWsKLS0tIGEvY29uZmlnL3g4Nl82NC5taworKysgYi9jb25maWcv eDg2XzY0Lm1rCkBAIC05LDYgKzksNyBAQCBDT05GSUdfWENVVElMUyA6PSB5CiBDT05GSUdfSU9F TVUgOj0geQogCiBDRkxBR1MgKz0gLW02NAorTERGTEFHUyArPSAtbTY0CiAKIExJQkxFQUZESVIg PSAkKExJQkxFQUZESVJfeDg2XzY0KQogTElCRElSID0gJChMSUJESVJfeDg2XzY0KQo= --0015173fe8223a7d3804ae071d80 Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel --0015173fe8223a7d3804ae071d80-- From xen-devel-bounces@lists.xensource.com Wed Sep 28 14:41:10 2011 Return-path: <xen-devel-bounces@lists.xensource.com> Envelope-to: www-data@lists.xensource.com Delivery-date: Wed, 28 Sep 2011 14:41:10 -0700 Received: from localhost ([127.0.0.1] helo=lists.colo.xensource.com) by lists.xensource.com with esmtp (Exim 4.43) id 1R91sM-0001tG-IH; Wed, 28 Sep 2011 14:41:10 -0700 Received: from mail216.messagelabs.com ([85.158.143.99]) by lists.xensource.com with esmtp (Exim 4.43) id 1R91rt-0001h7-UP for xen-devel@lists.xensource.com; Wed, 28 Sep 2011 14:40:42 -0700 X-Env-Sender: jeremy@goop.org X-Msg-Ref: server-8.tower-216.messagelabs.com!1317246037!16809400!1 X-Originating-IP: [74.207.240.146] X-StarScan-Version: 6.4.1; banners=-,-,- X-VirusChecked: Checked Received: (qmail 3415 invoked from network); 28 Sep 2011 21:40:38 -0000 Received: from claw.goop.org (HELO claw.goop.org) (74.207.240.146) by server-8.tower-216.messagelabs.com with DHE-RSA-AES256-SHA encrypted SMTP; 28 Sep 2011 21:40:38 -0000 Received: from saboo.goop.org (unknown [IPv6:2001:470:1f05:899:1c35:2ff:fe5f:d133]) (Authenticated sender: smtp-saboo) by claw.goop.org (Postfix) with ESMTPSA id 90BC99102; Wed, 28 Sep 2011 14:40:36 -0700 (PDT) Received: from saboo.goop.org (localhost [IPv6:::1]) by saboo.goop.org (Postfix) with ESMTP id AC2A820F30; Wed, 28 Sep 2011 14:40:33 -0700 (PDT) Message-ID: <4E839451.40901@goop.org> Date: Wed, 28 Sep 2011 14:40:33 -0700 From: Jeremy Fitzhardinge <jeremy@goop.org> User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:6.0.2) Gecko/20110906 Thunderbird/6.0.2 MIME-Version: 1.0 To: Li Dongyang <lidongyang@novell.com> X-Enigmail-Version: 1.3.2 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>, Konrad Rzeszutek Wilk <konrad.wilk@oracle.com> Subject: [Xen-devel] blkback stuck in infinite loop in xen_blkbk_discard() X-BeenThere: xen-devel@lists.xensource.com X-Mailman-Version: 2.1.5 Precedence: list List-Id: Xen developer discussion <xen-devel.lists.xensource.com> List-Unsubscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe> List-Post: <mailto:xen-devel@lists.xensource.com> List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help> List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=subscribe> Sender: xen-devel-bounces@lists.xensource.com Errors-To: xen-devel-bounces@lists.xensource.com I just "xl destroy"d a domain, and now my dom0 kernel is sitting there infinitely spewing: vbd vbd-83-51712: 5 reading type vbd vbd-83-51712: 5 reading type vbd vbd-83-51712: 5 reading type vbd vbd-83-51712: 5 reading type vbd vbd-83-51712: 5 reading type vbd vbd-83-51712: 5 reading type vbd vbd-83-51712: 5 reading type vbd vbd-83-51712: 5 reading type vbd vbd-83-51712: 5 reading type vbd vbd-83-51712: 5 reading type vbd vbd-83-51712: 5 reading type vbd vbd-83-51712: 5 reading type vbd vbd-83-51712: 5 reading type vbd vbd-83-51712: 5 reading type vbd vbd-83-51712: 5 reading type vbd vbd-83-51712: 5 reading type vbd vbd-83-51712: 5 reading type vbd vbd-83-51712: 5 reading type vbd vbd-83-51712: 5 reading type which seems to be coming from the error case in drivers/block/xen-blkback/xenbus.c:xen_blkbk_discard(). I don't know what the backtrace is. The system seems overall fine, despite the console spew, though I have a pile of dying domains sitting in odd states rather than being cleaned up. J _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel From xen-devel-bounces@lists.xensource.com Wed Sep 28 14:57:59 2011 Return-path: <xen-devel-bounces@lists.xensource.com> Envelope-to: www-data@lists.xensource.com Delivery-date: Wed, 28 Sep 2011 14:57:59 -0700 Received: from localhost ([127.0.0.1] helo=lists.colo.xensource.com) by lists.xensource.com with esmtp (Exim 4.43) id 1R928d-0002fe-Dr; Wed, 28 Sep 2011 14:57:59 -0700 Received: from mail216.messagelabs.com ([85.158.143.99]) by lists.xensource.com with esmtp (Exim 4.43) id 1R927U-0002Rq-KM for xen-devel@lists.xensource.com; Wed, 28 Sep 2011 14:56:49 -0700 X-Env-Sender: Ian.Jackson@eu.citrix.com X-Msg-Ref: server-6.tower-216.messagelabs.com!1317247005!18657682!1 X-Originating-IP: [62.200.22.115] X-StarScan-Version: 6.4.1; banners=-,-,- X-VirusChecked: Checked Received: (qmail 9054 invoked from network); 28 Sep 2011 21:56:45 -0000 Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115) by server-6.tower-216.messagelabs.com with RC4-SHA encrypted SMTP; 28 Sep 2011 21:56:45 -0000 X-IronPort-AV: E=Sophos;i="4.68,457,1312156800"; d="scan'208";a="8114898" Received: from lonpmailmx01.citrite.net ([10.30.203.162]) by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5; 28 Sep 2011 21:56:45 +0000 Received: from woking.xci-test.com (10.80.248.135) by smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id 8.3.137.0; Wed, 28 Sep 2011 22:56:45 +0100 Received: from osstest by woking.xci-test.com with local (Exim 4.69) (envelope-from <ian.jackson@eu.citrix.com>) id 1R927Q-0007qD-Oy; Wed, 28 Sep 2011 22:56:44 +0100 To: xen-devel@lists.xensource.com Message-ID: <osstest-9113-mainreport@xen.org> From: xen.org <ian.jackson@eu.citrix.com> Date: Wed, 28 Sep 2011 22:56:44 +0100 MIME-Version: 1.0 Content-Type: text/plain Cc: ian.jackson@eu.citrix.com Subject: [Xen-devel] [xen-unstable test] 9113: regressions - FAIL X-BeenThere: xen-devel@lists.xensource.com X-Mailman-Version: 2.1.5 Precedence: list List-Id: Xen developer discussion <xen-devel.lists.xensource.com> List-Unsubscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe> List-Post: <mailto:xen-devel@lists.xensource.com> List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help> List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=subscribe> Sender: xen-devel-bounces@lists.xensource.com Errors-To: xen-devel-bounces@lists.xensource.com flight 9113 xen-unstable real [real] http://www.chiark.greenend.org.uk/~xensrcts/logs/9113/ Regressions :-( Tests which did not succeed and are blocking: test-amd64-amd64-xl-sedf 11 guest-localmigrate fail REGR. vs. 9110 Tests which did not succeed, but are not blocking, including regressions (tests previously passed) regarded as allowable: test-amd64-amd64-xl-pcipt-intel 9 guest-start fail never pass test-amd64-i386-rhel6hvm-intel 9 guest-start.2 fail never pass test-amd64-i386-win-vcpus1 16 leak-check/check fail never pass test-amd64-i386-rhel6hvm-amd 9 guest-start.2 fail never pass test-amd64-i386-xl-win-vcpus1 13 guest-stop fail never pass test-amd64-i386-win 16 leak-check/check fail never pass test-amd64-amd64-win 16 leak-check/check fail never pass test-amd64-amd64-xl-win 13 guest-stop fail never pass test-i386-i386-win 16 leak-check/check fail never pass test-i386-i386-xl-win 13 guest-stop fail never pass version targeted for testing: xen 7998217630e2 baseline version: xen bfa65eb40b2a ------------------------------------------------------------ People who touched revisions under test: Andreas Olsowski <andreas.olsowski@leuphana.de> Ian Campbell <ian.campbell@citrix.com> Ian Jackson <ian.jackson@eu.citrix.com> Olaf Hering <olaf@aepfle.de> ------------------------------------------------------------ jobs: build-amd64 pass build-i386 pass build-amd64-oldkern pass build-i386-oldkern pass build-amd64-pvops pass build-i386-pvops pass test-amd64-amd64-xl pass test-amd64-i386-xl pass test-i386-i386-xl pass test-amd64-i386-rhel6hvm-amd fail test-amd64-i386-xl-credit2 pass test-amd64-amd64-xl-pcipt-intel fail test-amd64-i386-rhel6hvm-intel fail test-amd64-i386-xl-multivcpu pass test-amd64-amd64-pair pass test-amd64-i386-pair pass test-i386-i386-pair pass test-amd64-amd64-pv pass test-amd64-i386-pv pass test-i386-i386-pv pass test-amd64-amd64-xl-sedf fail test-amd64-i386-win-vcpus1 fail test-amd64-i386-xl-win-vcpus1 fail test-amd64-amd64-win fail test-amd64-i386-win fail test-i386-i386-win fail test-amd64-amd64-xl-win fail test-i386-i386-xl-win fail ------------------------------------------------------------ sg-report-flight on woking.cam.xci-test.com logs: /home/xc_osstest/logs images: /home/xc_osstest/images Logs, config files, etc. are available at http://www.chiark.greenend.org.uk/~xensrcts/logs Test harness code can be found at http://xenbits.xensource.com/gitweb?p=osstest.git;a=summary Not pushing. ------------------------------------------------------------ changeset: 23883:7998217630e2 tag: tip user: Ian Campbell <ian.campbell@citrix.com> date: Wed Sep 28 16:42:11 2011 +0100 libxl: attempt to cleanup tapdisk processes on disk backend destroy. Signed-off-by: Ian Campbell <ian.campbell@citrix.com> Committed-by: Ian Jackson <ian.jackson@eu.citrix.com> changeset: 23882:72e3391299e4 user: Ian Campbell <ian.campbell@citrix.com> date: Wed Sep 28 16:35:44 2011 +0100 libxl: correct allocation size in libxl_list_nics The function returns a list of libxl_nicinfo not libxl_device_nic. Causes memory corruption on free. Signed-off-by: Ian Campbell <ian.campbell@citrix.com> Acked-by: Ian Jackson <ian.jackson@eu.citrix.com> Committed-by: Ian Jackson <ian.jackson@eu.citrix.com> changeset: 23881:8877da7ba3a4 user: Ian Campbell <ian.campbell@citrix.com> date: Wed Sep 28 16:34:00 2011 +0100 libxl: correct allocation size in libxl_list_vm *ptr has type libxl_vminfo not libxl_domid, so correct calloc call. This the second instance of this bug I've noticed recently, I did a quick audit of other similar uses of sizeof(...) and all I spotted were a couple of harmlessly reversed calloc arguments. It's a pretty strong argument for "foo = ..alloc(sizeof(*foo))" rather than "alloc(sizeof(foos_type))" though... Signed-off-by: Ian Campbell <ian.campbell@citrix.com> Acked-by: Ian Jackson <ian.jackson@eu.citrix.com> Committed-by: Ian Jackson <ian.jackson@eu.citrix.com> changeset: 23880:ba1afb9bc159 user: Ian Campbell <ian.campbell@citrix.com> date: Wed Sep 28 16:32:31 2011 +0100 libxl: correctly propagate errors from libxl_domain_destroy currently it return success e.g. even if xc_domain_destroy fails. Signed-off-by: Ian Campbell <ian.campbell@citrix.com> Acked-by: Ian Jackson <ian.jackson@eu.citrix.com> Committed-by: Ian Jackson <ian.jackson@eu.citrix.com> changeset: 23879:8863be49d319 user: Ian Campbell <ian.campbell@citrix.com> date: Wed Sep 28 16:31:11 2011 +0100 libxl: fail to parse disk vpath if a disk+part number needed but unavailable libxl__device_disk_dev_number() can parse a virtpath which is an encoded unsigned long but does not set *pdisk or *ppartition in that case. Ideally we would parse the number but for now simply fail to prevent cascading failures. Signed-off-by: Ian Campbell <ian.campbell@citrix.com> Acked-by: Ian Jackson <ian.jackson@eu.citrix.com> Committed-by: Ian Jackson <ian.jackson@eu.citrix.com> changeset: 23878:59c7213b5949 user: Ian Campbell <ian.campbell@citrix.com> date: Tue Sep 27 18:39:15 2011 +0100 libxl: do not try to redo incoming migration on reboot of migrated domain After a migration, reboot was trying to receive another incoming migration, instead of restarting the domain it already has. Signed-off-by: Ian Jackson <ian.jackson@eu.citrix.com> Tested-by: Andreas Olsowski <andreas.olsowski@leuphana.de> Committed-by: Ian Jackson <ian.jackson@eu.citrix.com> changeset: 23877:bfa65eb40b2a user: Ian Campbell <ian.campbell@citrix.com> date: Tue Sep 27 18:03:11 2011 +0100 libxl: make libxl__wait_for_device_model use libxl__spawn_starrting directly Instead of indirecting via libxl_device_model_starting. This fixes a segmentation fault using stubdomains where starting->for_spawn is (validly) NULL because starting a stubdom doesn't need to spawn a process. Most callers of libxl__wait_for_device_model already pass NULL for this variable (because they are not on the starting path) so on libxl__confirm_device_model_startup needs to change. Reported-by: Jeremy Fitzhardinge <jeremy@goop.org> Signed-off-by: Ian Campbell <ian.campbell@citrix.com> Acked-by: Ian Jackson <ian.jackson@eu.citrix.com> Committed-by: Ian Jackson <ian.jackson@eu.citrix.com> ======================================== commit cd776ee9408ff127f934a707c1a339ee600bc127 Author: Ian Jackson <ian.jackson@eu.citrix.com> Date: Tue Jun 28 13:50:53 2011 +0100 qemu-char.c: fix incorrect CONFIG_STUBDOM handling qemu-char.c:1123:7: warning: "CONFIG_STUBDOM" is not defined [-Wundef] Signed-off-by: Olaf Hering <olaf@aepfle.de> Acked-by: Ian Jackson <ian.jackson@eu.citrix.com> _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel From xen-devel-bounces@lists.xensource.com Wed Sep 28 16:07:41 2011 Return-path: <xen-devel-bounces@lists.xensource.com> Envelope-to: www-data@lists.xensource.com Delivery-date: Wed, 28 Sep 2011 16:07:41 -0700 Received: from localhost ([127.0.0.1] helo=lists.colo.xensource.com) by lists.xensource.com with esmtp (Exim 4.43) id 1R93E4-0004VL-Qn; Wed, 28 Sep 2011 16:07:40 -0700 Received: from mail27.messagelabs.com ([193.109.254.147]) by lists.xensource.com with esmtp (Exim 4.43) id 1R93CP-0004IF-Q1 for xen-devel@lists.xensource.com; Wed, 28 Sep 2011 16:06:10 -0700 X-Env-Sender: konrad@oracle.com X-Msg-Ref: server-10.tower-27.messagelabs.com!1317251130!37635569!1 X-Originating-IP: [148.87.113.117] X-StarScan-Version: 6.4.1; banners=-,-,- X-VirusChecked: Checked Received: (qmail 24957 invoked from network); 28 Sep 2011 23:05:32 -0000 Received: from rcsinet15.oracle.com (HELO rcsinet15.oracle.com) (148.87.113.117) by server-10.tower-27.messagelabs.com with DHE-RSA-AES256-SHA encrypted SMTP; 28 Sep 2011 23:05:32 -0000 Received: from ucsinet23.oracle.com (ucsinet23.oracle.com [156.151.31.71]) by rcsinet15.oracle.com (Switch-3.4.4/Switch-3.4.4) with ESMTP id p8SN5icv003405 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Wed, 28 Sep 2011 23:05:46 GMT Received: from acsmt356.oracle.com (acsmt356.oracle.com [141.146.40.156]) by ucsinet23.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id p8SN5h9X017206 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 28 Sep 2011 23:05:43 GMT Received: from abhmt105.oracle.com (abhmt105.oracle.com [141.146.116.57]) by acsmt356.oracle.com (8.12.11.20060308/8.12.11) with ESMTP id p8SN5bSr001416; Wed, 28 Sep 2011 18:05:37 -0500 Received: from oracle.com (/207.172.105.198) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Wed, 28 Sep 2011 16:05:37 -0700 Received: by oracle.com (Postfix, from userid 1000) id 51D1915AA; Wed, 28 Sep 2011 19:05:35 -0400 (EDT) Date: Wed, 28 Sep 2011 19:05:35 -0400 From: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com> To: Stefano Stabellini <stefano.stabellini@eu.citrix.com> Subject: Re: [Xen-devel] Re: [PATCH v4 2/2] xen: modify kernel mappings corresponding to granted pages Message-ID: <20110928230535.GA23001@phenom.oracle.com> References: <alpine.DEB.2.00.1109081944150.12963@kaball-desktop> <20110921145853.GA541@phenom.oracle.com> <alpine.DEB.2.00.1109231412220.8700@kaball-desktop> <20110923144538.GA10701@phenom.oracle.com> <alpine.DEB.2.00.1109271549030.3519@kaball-desktop> <20110928131229.GA10270@phenom.oracle.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20110928131229.GA10270@phenom.oracle.com> User-Agent: Mutt/1.5.21 (2010-09-15) X-Source-IP: ucsinet23.oracle.com [156.151.31.71] X-CT-RefId: str=0001.0A090207.4E83A84A.007A,ss=1,re=0.000,fgs=0 Cc: Jeremy Fitzhardinge <jeremy@goop.org>, "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>, "linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org> X-BeenThere: xen-devel@lists.xensource.com X-Mailman-Version: 2.1.5 Precedence: list List-Id: Xen developer discussion <xen-devel.lists.xensource.com> List-Unsubscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe> List-Post: <mailto:xen-devel@lists.xensource.com> List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help> List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=subscribe> Sender: xen-devel-bounces@lists.xensource.com Errors-To: xen-devel-bounces@lists.xensource.com On Wed, Sep 28, 2011 at 09:12:29AM -0400, Konrad Rzeszutek Wilk wrote: > > > Anyhow, If you want to modify your patchset to check PagePrivate bit > > > and set the SetPagePrivate/set_page_private - go ahead. > > > > I'll do that. > > Preempted you a bit :-) > http://lists.xensource.com/archives/html/xen-devel/2011-09/msg01364.html > > > > > > > + gnttab_set_map_op(&map->kmap_ops[i], pte_maddr, > > > > > > + map->flags | > > > > > > + GNTMAP_host_map | > > > > > > + GNTMAP_contains_pte, > > > > > > + map->grants[i].ref, > > > > > > + map->grants[i].domid); > > > > > > + } > > > > > > > > > > So, on startup.. (before this function is called) the > > > > > find_grant_ptes is called which pretty much does the exact thing for > > > > > each virtual address. Except its flags are GNTMAP_application_map > > > > > instead of GNTMAP_host_map. > > > > > > > > > > It even uses the same type structure.. It fills out map_ops[i] one. > > > > > > > > > > Can we use that instead of adding a new structure? > > > > > > > > Do you mean moving this code inside find_grant_ptes? > > > > I don't think that can be done because find_grant_ptes is called on a > > > > range of virtual addresses while this is called on an array of struct > > > > pages. It is true that the current implementation of > > > > > > But aren't that 'range of virtual address' of struct pages? You > > > are using 'alloc_xenballooned_pages' to get those pages and that is > > > what the 'range of virtual adresses' is walking through. > > > > it is not the same range of virtual addresses > > OK, but the pte_maddr is the same, isn't it? No it is not. It is the machine address of the PTE entry that points to the 'struct page' (kernel linear address), while the find_grant_pte's gets the machine address of the PTE entry that points to the user pages. Completlely different machine addresses of the PTEs. Can you add a comment to the patch saying something along what I just said? Just in case somebody is as thick as I am when looking at this code/patch. Otherwise the patch looks fine - just fix up the SetPagePrivate, the PAGE_GRANT bit, and add extra comments and I am ready to stick it on my queue. Thanks! > > > > > > > alloc_xenballooned_pages is going to return a consecutive set of pages > > > > but it might not always be the case. > > > > > > I am sensing some grand plans in work here? I thought we are going to > > > try to simply our lives and see about making alloc_xenballooned_pages > > > returned sane pages that are !PageHighMem (or if they are PageHighMem they > > > are already pinned, and set in the &init_mm)? > > > > > > I am just thinking in terms of lookup_address and arbitrary_virt_to_machine > > > calls being done _twice_. And it seems like we have the find_grant_ptes > > > which does the bulk of this already - so why not piggyback on it? > > > > It has to be done twice: once for the user ptes and once for the kernel > > mappings of map->pages. > > > > > > > Besides that, the patch set looks fine. .. How do I reproduce the failures > > > you had encountered with the AIO? > > > > > > > Just setup and use upstream qemu and configure your VM to use a disk on > > a file (file:). > > OK. _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel From xen-devel-bounces@lists.xensource.com Wed Sep 28 17:35:37 2011 Return-path: <xen-devel-bounces@lists.xensource.com> Envelope-to: www-data@lists.xensource.com Delivery-date: Wed, 28 Sep 2011 17:35:37 -0700 Received: from localhost ([127.0.0.1] helo=lists.colo.xensource.com) by lists.xensource.com with esmtp (Exim 4.43) id 1R94bA-0006Tu-W9; Wed, 28 Sep 2011 17:35:37 -0700 Received: from mail21.messagelabs.com ([85.158.143.35]) by lists.xensource.com with esmtp (Exim 4.43) id 1R94Zr-0006FG-7w for xen-devel@lists.xensource.com; Wed, 28 Sep 2011 17:34:15 -0700 X-Env-Sender: james.harper@bendigoit.com.au X-Msg-Ref: server-4.tower-21.messagelabs.com!1317256412!62008400!1 X-Originating-IP: [203.16.224.4] X-StarScan-Version: 6.4.1; banners=-,-,- X-VirusChecked: Checked Received: (qmail 25227 invoked from network); 29 Sep 2011 00:33:35 -0000 Received: from smtp1.bendigoit.com.au (HELO smtp1.bendigoit.com.au) (203.16.224.4) by server-4.tower-21.messagelabs.com with AES256-SHA encrypted SMTP; 29 Sep 2011 00:33:35 -0000 Received: from smtp2.bendigoit.com.au ([203.16.207.99] helo=mail.bendigoit.com.au) by smtp1.bendigoit.com.au with esmtp (Exim 4.69) (envelope-from <james.harper@bendigoit.com.au>) id 1R94Zi-0002bO-GQ for xen-devel@lists.xensource.com; Thu, 29 Sep 2011 10:34:06 +1000 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable X-MimeOLE: Produced By Microsoft Exchange V6.5 Date: Thu, 29 Sep 2011 10:33:44 +1000 Message-ID: <AEC6C66638C05B468B556EA548C1A77D01E5E231@trantor> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: bug in vlan offload in dom0 3.0.0 kernel? Thread-Index: Acx+PsQ9MamN0KnLTtWbPGSAI0uAUw== From: "James Harper" <james.harper@bendigoit.com.au> To: <xen-devel@lists.xensource.com> X-Really-From-Bendigo-IT: magichashvalue Subject: [Xen-devel] bug in vlan offload in dom0 3.0.0 kernel? X-BeenThere: xen-devel@lists.xensource.com X-Mailman-Version: 2.1.5 Precedence: list List-Id: Xen developer discussion <xen-devel.lists.xensource.com> List-Unsubscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe> List-Post: <mailto:xen-devel@lists.xensource.com> List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help> List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=subscribe> Sender: xen-devel-bounces@lists.xensource.com Errors-To: xen-devel-bounces@lists.xensource.com I've just upgraded some dom0's to 3.0.0 (debian kernel) and now my vlan's aren't working properly. Traffic is transmitted and other devices on that vlan see that traffic, and the xen machine sees the tagged response on eth0 but the packet never makes it onto eth0.2 (vlan2). My setup is this: br-wan eth0.2 - physical network interface vif1.0 - virtual backend interface for vm Here's an attempt to describe what I'm seeing for transmit: vm eth0 - untagged packet xen vif1.0 - untagged packet xen br-wan - untagged packet xen eth0.2 - untagged packet xen eth0 - tagged packet | router eth0 - tagged packet router eth0.2 - untagged packet That all looks fine. The packets are tagged inside the vlan interface and then tagged once they appear on the physical trunk. For receive: router eth0.2 - untagged packet router eth0 - tagged packet |=20 xen eth0 - tagged packet xen eth0.2 - nothing The nics are Intel dual port gigabit adapters - 82576. There is at least one bug report describing similar behaviour to the above but that was back in 2.6.x. Has anyone else seen this problem? And more importantly, might vswitch solve some of the above problems? Thanks James _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel From xen-devel-bounces@lists.xensource.com Wed Sep 28 18:04:32 2011 Return-path: <xen-devel-bounces@lists.xensource.com> Envelope-to: www-data@lists.xensource.com Delivery-date: Wed, 28 Sep 2011 18:04:32 -0700 Received: from localhost ([127.0.0.1] helo=lists.colo.xensource.com) by lists.xensource.com with esmtp (Exim 4.43) id 1R953A-0007hy-24; Wed, 28 Sep 2011 18:04:32 -0700 Received: from mail182.messagelabs.com ([85.158.139.83]) by lists.xensource.com with esmtp (Exim 4.43) id 1R94z5-0007D4-UN for xen-devel@lists.xensource.com; Wed, 28 Sep 2011 18:00:29 -0700 X-Env-Sender: Ian.Jackson@eu.citrix.com X-Msg-Ref: server-6.tower-182.messagelabs.com!1317258016!18941488!1 X-Originating-IP: [62.200.22.115] X-StarScan-Version: 6.4.1; banners=-,-,- X-VirusChecked: Checked Received: (qmail 29077 invoked from network); 29 Sep 2011 01:00:16 -0000 Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115) by server-6.tower-182.messagelabs.com with RC4-SHA encrypted SMTP; 29 Sep 2011 01:00:16 -0000 X-IronPort-AV: E=Sophos;i="4.68,458,1312156800"; d="scan'208";a="8115890" Received: from lonpmailmx01.citrite.net ([10.30.203.162]) by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5; 29 Sep 2011 01:00:16 +0000 Received: from woking.xci-test.com (10.80.248.135) by smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id 8.3.137.0; Thu, 29 Sep 2011 02:00:16 +0100 Received: from osstest by woking.xci-test.com with local (Exim 4.69) (envelope-from <ian.jackson@eu.citrix.com>) id 1R94z1-0002Sw-8Y; Thu, 29 Sep 2011 02:00:15 +0100 To: xen-devel@lists.xensource.com Message-ID: <osstest-9115-mainreport@xen.org> From: xen.org <ian.jackson@eu.citrix.com> Date: Thu, 29 Sep 2011 02:00:15 +0100 MIME-Version: 1.0 Content-Type: text/plain Cc: ian.jackson@eu.citrix.com Subject: [Xen-devel] [xen-unstable test] 9115: tolerable FAIL - PUSHED X-BeenThere: xen-devel@lists.xensource.com X-Mailman-Version: 2.1.5 Precedence: list List-Id: Xen developer discussion <xen-devel.lists.xensource.com> List-Unsubscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe> List-Post: <mailto:xen-devel@lists.xensource.com> List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help> List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=subscribe> Sender: xen-devel-bounces@lists.xensource.com Errors-To: xen-devel-bounces@lists.xensource.com flight 9115 xen-unstable real [real] http://www.chiark.greenend.org.uk/~xensrcts/logs/9115/ Failures :-/ but no regressions. Tests which did not succeed, but are not blocking, including regressions (tests previously passed) regarded as allowable: test-amd64-amd64-xl-pcipt-intel 9 guest-start fail never pass test-amd64-i386-rhel6hvm-intel 9 guest-start.2 fail never pass test-amd64-i386-win-vcpus1 16 leak-check/check fail never pass test-amd64-i386-rhel6hvm-amd 9 guest-start.2 fail never pass test-amd64-i386-xl-win-vcpus1 13 guest-stop fail never pass test-amd64-i386-win 16 leak-check/check fail never pass test-amd64-amd64-win 16 leak-check/check fail never pass test-amd64-amd64-xl-win 13 guest-stop fail never pass test-i386-i386-win 16 leak-check/check fail never pass test-i386-i386-xl-win 13 guest-stop fail never pass version targeted for testing: xen 7998217630e2 baseline version: xen bfa65eb40b2a ------------------------------------------------------------ People who touched revisions under test: Andreas Olsowski <andreas.olsowski@leuphana.de> Ian Campbell <ian.campbell@citrix.com> Ian Jackson <ian.jackson@eu.citrix.com> Olaf Hering <olaf@aepfle.de> ------------------------------------------------------------ jobs: build-amd64 pass build-i386 pass build-amd64-oldkern pass build-i386-oldkern pass build-amd64-pvops pass build-i386-pvops pass test-amd64-amd64-xl pass test-amd64-i386-xl pass test-i386-i386-xl pass test-amd64-i386-rhel6hvm-amd fail test-amd64-i386-xl-credit2 pass test-amd64-amd64-xl-pcipt-intel fail test-amd64-i386-rhel6hvm-intel fail test-amd64-i386-xl-multivcpu pass test-amd64-amd64-pair pass test-amd64-i386-pair pass test-i386-i386-pair pass test-amd64-amd64-pv pass test-amd64-i386-pv pass test-i386-i386-pv pass test-amd64-amd64-xl-sedf pass test-amd64-i386-win-vcpus1 fail test-amd64-i386-xl-win-vcpus1 fail test-amd64-amd64-win fail test-amd64-i386-win fail test-i386-i386-win fail test-amd64-amd64-xl-win fail test-i386-i386-xl-win fail ------------------------------------------------------------ sg-report-flight on woking.cam.xci-test.com logs: /home/xc_osstest/logs images: /home/xc_osstest/images Logs, config files, etc. are available at http://www.chiark.greenend.org.uk/~xensrcts/logs Test harness code can be found at http://xenbits.xensource.com/gitweb?p=osstest.git;a=summary Pushing revision : + branch=xen-unstable + revision=7998217630e2 + . cri-lock-repos ++ . cri-common +++ umask 002 +++ getconfig Repos +++ perl -e ' use Osstest; readconfigonly(); print $c{Repos} or die $!; ' ++ repos=/export/home/osstest/repos ++ repos_lock=/export/home/osstest/repos/lock ++ '[' x '!=' x/export/home/osstest/repos/lock ']' ++ OSSTEST_REPOS_LOCK_LOCKED=/export/home/osstest/repos/lock ++ exec with-lock-ex -w /export/home/osstest/repos/lock ./ap-push xen-unstable 7998217630e2 + branch=xen-unstable + revision=7998217630e2 + . cri-lock-repos ++ . cri-common +++ umask 002 +++ getconfig Repos +++ perl -e ' use Osstest; readconfigonly(); print $c{Repos} or die $!; ' ++ repos=/export/home/osstest/repos ++ repos_lock=/export/home/osstest/repos/lock ++ '[' x/export/home/osstest/repos/lock '!=' x/export/home/osstest/repos/lock ']' + : xen@xenbits.xensource.com + : xen@xenbits.xensource.com:git/linux-pvops + : master + : tested/2.6.39.x + case "$branch" in + cd /export/home/osstest/repos/xen-unstable.hg + hg push -r 7998217630e2 ssh://xen@xenbits.xensource.com/HG/xen-unstable.hg pushing to ssh://xen@xenbits.xensource.com/HG/xen-unstable.hg searching for changes remote: adding changesets remote: adding manifests remote: adding file changes remote: added 6 changesets with 12 changes to 9 files _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel From xen-devel-bounces@lists.xensource.com Wed Sep 28 20:07:44 2011 Return-path: <xen-devel-bounces@lists.xensource.com> Envelope-to: www-data@lists.xensource.com Delivery-date: Wed, 28 Sep 2011 20:07:44 -0700 Received: from localhost ([127.0.0.1] helo=lists.colo.xensource.com) by lists.xensource.com with esmtp (Exim 4.43) id 1R96yN-0001wp-P8; Wed, 28 Sep 2011 20:07:43 -0700 Received: from mail174.messagelabs.com ([85.158.138.51]) by lists.xensource.com with esmtp (Exim 4.43) id 1R8t6s-0005q8-UY for xen-devel@lists.xensource.com; Wed, 28 Sep 2011 05:19:36 -0700 X-Env-Sender: bickys1986@gmail.com X-Msg-Ref: server-12.tower-174.messagelabs.com!1317212370!33073179!1 X-Originating-IP: [209.85.160.171] X-StarScan-Version: 6.4.1; banners=-,-,- X-VirusChecked: Checked Received: (qmail 6687 invoked from network); 28 Sep 2011 12:19:31 -0000 Received: from mail-gy0-f171.google.com (HELO mail-gy0-f171.google.com) (209.85.160.171) by server-12.tower-174.messagelabs.com with RC4-SHA encrypted SMTP; 28 Sep 2011 12:19:31 -0000 Received: by gyh3 with SMTP id 3so9981260gyh.30 for <xen-devel@lists.xensource.com>; Wed, 28 Sep 2011 05:19:30 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:date:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=RzsFhxEb/yNzYftr4kCokQ9V9LmBdI5Om5lFHOewwVo=; b=hf3FH1mciyWf6SowqMBEnYJptZLsSWfa9OJALXSDNUzOZLh3myv4oUhfb+5uyzOnLL z2uODpOb0Lh1L6Me5MC6v5/9S5LKUDV+xH/QiTWNjsDUU11MmiiJmbi08PtDbHIVQxK8 +TpRXPM46cB1aVxjaQSJR30wx1dv44hhYn+Uw= MIME-Version: 1.0 Received: by 10.204.6.215 with SMTP id a23mr4540663bka.16.1317212369948; Wed, 28 Sep 2011 05:19:29 -0700 (PDT) Received: by 10.204.60.71 with HTTP; Wed, 28 Sep 2011 05:19:29 -0700 (PDT) Date: Wed, 28 Sep 2011 20:19:29 +0800 Message-ID: <CACavRyCNghRyXwUMeWdoyqLwgmOX2KyuD+oerA8W75JL+07wdw@mail.gmail.com> From: zhen shi <bickys1986@gmail.com> To: olaf@aepfle.de Content-Type: text/plain; charset=GB2312 Content-Transfer-Encoding: quoted-printable X-Mailman-Approved-At: Wed, 28 Sep 2011 20:06:13 -0700 Cc: xen-devel@lists.xensource.com Subject: [Xen-devel] event channel in xenpaging X-BeenThere: xen-devel@lists.xensource.com X-Mailman-Version: 2.1.5 Precedence: list List-Id: Xen developer discussion <xen-devel.lists.xensource.com> List-Unsubscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe> List-Post: <mailto:xen-devel@lists.xensource.com> List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help> List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=subscribe> Sender: xen-devel-bounces@lists.xensource.com Errors-To: xen-devel-bounces@lists.xensource.com Hi,Olaf, I have some questions about event channel in Xenpaging to ask you. 1) In xenpaging it uses Inter-Domainain Commnication (IDC) between dom0 and domU to build bidirectional connection,but I found there is only an event channel notification from xen to dom0 when page faults happens.It seems that xenpaging_resume_page()->xc_evtchn_notify() doesn't make any difference.So why don't use vIRQ between dom0 and xen instead of IDC between dom0 and domU? 2)In your latest patch,[PATCH 9 of 9] xenpaging: watch the domains /xenpaging/num_pages xenstore value.I found some problems. a=A1=A2In main(),you put the page_out process into while(1) and make the following change. if ( interrupted ) victims[i].gfn =3D INVALID_MFN; - else - evict_victim(paging, &victims[i], fd, i); I think the" if ( interrupted )" should remove here.Because once handling page_in requests,the related victims slot should clear, then in evict_pages we can populate new page in this slot because in evict_page() the condition as followings: /* Slot is allocated */ + if ( victims[slot].gfn !=3D INVALID_MFN ) + continue; b=A1=A2In xenpaging_init (),when it goes to err,you add "free(dom_path);free(watch_targetpages)" in PATCH 9,but I think we should firstly judge if dom_path and watch_targetpages variables are NULL.what's more ,if it initializes paging successfully=A3=ACbefore "return paging",we should free (dom_path),and free(watch_targetpages) in xenpaging_teardown() lastly. c=A1=A2when initializing xenpaging fails,and goes to err,it returns NULL to main() then exit main(). If it has already opened event channel,bind event notification,opened connections to xen successfully when goes to err in xenpaging_init()=A3=AChow about dealing with these resources such as xenpaging_teardown. 3)We have tested on Win7-32bit about 40vms to start xenpaging at the same time.The vm is 1G 2VCPUS,and we page out 180M.Then we put 80-90% memory pressure on each vm.About one hour later,there happens many BSOD on vms.and most blue screen code is 0x... 7F or 0x...19. We guess some special pages which systems need use to run may be paged out and cause BSOD.and sometimes print out mmio information in messages.Do you have any ideas about the BSOD on win7-32 bit vms? I am looking forward to hearing from you. Thank you very much! :) _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel From xen-devel-bounces@lists.xensource.com Wed Sep 28 20:37:15 2011 Return-path: <xen-devel-bounces@lists.xensource.com> Envelope-to: www-data@lists.xensource.com Delivery-date: Wed, 28 Sep 2011 20:37:15 -0700 Received: from localhost ([127.0.0.1] helo=lists.colo.xensource.com) by lists.xensource.com with esmtp (Exim 4.43) id 1R97Qx-0002sv-Ld; Wed, 28 Sep 2011 20:37:15 -0700 Received: from mail182.messagelabs.com ([85.158.139.83]) by lists.xensource.com with esmtp (Exim 4.43) id 1R97Q1-0002gg-1E for Xen-devel@lists.xensource.com; Wed, 28 Sep 2011 20:36:17 -0700 X-Env-Sender: sarath.amrita@gmail.com X-Msg-Ref: server-2.tower-182.messagelabs.com!1317267372!17343268!1 X-Originating-IP: [209.85.216.171] X-StarScan-Version: 6.4.1; banners=-,-,- X-VirusChecked: Checked Received: (qmail 13063 invoked from network); 29 Sep 2011 03:36:13 -0000 Received: from mail-qy0-f171.google.com (HELO mail-qy0-f171.google.com) (209.85.216.171) by server-2.tower-182.messagelabs.com with RC4-SHA encrypted SMTP; 29 Sep 2011 03:36:13 -0000 Received: by qyk29 with SMTP id 29so3423443qyk.9 for <Xen-devel@lists.xensource.com>; Wed, 28 Sep 2011 20:36:12 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:date:message-id:subject:from:to:content-type; bh=JKqX65SEhSsGtEArSdZ+LlRq+P3Kmn2Tp3FxaD+znEE=; b=pPrV2bP2kyPqOp11U9Ij2GwhMcOHznllZ7UplNXoeN7GnpAGPL4zo0WYYB93/rG4FT 9b2ORmxRwpbSTrMgxXWiKaUfXXWrEEWkCJD2NjIIqDECZwiFZFHZvJThCOsIvxYoR/yx uklv+n0NXD/djdjjphwAIUdcNJK/5rTnFn3Zk= MIME-Version: 1.0 Received: by 10.229.212.133 with SMTP id gs5mr156166qcb.238.1317267371862; Wed, 28 Sep 2011 20:36:11 -0700 (PDT) Received: by 10.229.216.70 with HTTP; Wed, 28 Sep 2011 20:36:11 -0700 (PDT) Date: Thu, 29 Sep 2011 09:06:11 +0530 Message-ID: <CAEO0G+B7j2hGZQZuK63CR_cCCXMv8k3eBqXcs+MAzJ2u5mabcw@mail.gmail.com> From: Sarath P R <sarath.amrita@gmail.com> To: Xen-devel@lists.xensource.com Cc: Subject: [Xen-devel] Monitoring traffic X-BeenThere: xen-devel@lists.xensource.com X-Mailman-Version: 2.1.5 Precedence: list List-Id: Xen developer discussion <xen-devel.lists.xensource.com> List-Unsubscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe> List-Post: <mailto:xen-devel@lists.xensource.com> List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help> List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=subscribe> Content-Type: multipart/mixed; boundary="===============0835635450==" Sender: xen-devel-bounces@lists.xensource.com Errors-To: xen-devel-bounces@lists.xensource.com --===============0835635450== Content-Type: multipart/alternative; boundary=00163630ecc7c62a5304ae0c35ab --00163630ecc7c62a5304ae0c35ab Content-Type: text/plain; charset=ISO-8859-1 I am new to Xen. as part of my job i need to monitor some traffic. Like a packet originates from which VM and all. Any APIs available for this or where should i start with. Any help. thanks in advance -- Thank You Sarath P Ramachandran +91 99 95 02 4287 --00163630ecc7c62a5304ae0c35ab Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable I am new to Xen. as part of my job i need to monitor some traffic. Like a p= acket originates from which VM and all. Any APIs available for this or wher= e should i start with. Any help. thanks in advance=A0 <br clear=3D"all"><br= > -- <br><font style=3D"color:rgb(0, 0, 0)" color=3D"#666666">Thank You<br></= font><div style=3D"color:rgb(0, 0, 0)">Sarath P Ramachandran</div><div styl= e=3D"color:rgb(0, 0, 0)"></div><div style=3D"color:rgb(0, 0, 0)"><span styl= e=3D"color:rgb(0, 0, 0)">+91 99 95 02 4287</span><br> </div><br> --00163630ecc7c62a5304ae0c35ab-- --===============0835635450== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel --===============0835635450==-- From xen-devel-bounces@lists.xensource.com Wed Sep 28 20:58:59 2011 Return-path: <xen-devel-bounces@lists.xensource.com> Envelope-to: www-data@lists.xensource.com Delivery-date: Wed, 28 Sep 2011 20:59:00 -0700 Received: from localhost ([127.0.0.1] helo=lists.colo.xensource.com) by lists.xensource.com with esmtp (Exim 4.43) id 1R97ly-0003ns-DD; Wed, 28 Sep 2011 20:58:58 -0700 Received: from mail27.messagelabs.com ([193.109.254.147]) by lists.xensource.com with esmtp (Exim 4.43) id 1R97kL-0003b1-79 for xen-devel@lists.xensource.com; Wed, 28 Sep 2011 20:57:18 -0700 X-Env-Sender: Ian.Jackson@eu.citrix.com X-Msg-Ref: server-14.tower-27.messagelabs.com!1317268522!38043182!1 X-Originating-IP: [62.200.22.115] X-StarScan-Version: 6.4.1; banners=-,-,- X-VirusChecked: Checked Received: (qmail 25235 invoked from network); 29 Sep 2011 03:55:22 -0000 Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115) by server-14.tower-27.messagelabs.com with RC4-SHA encrypted SMTP; 29 Sep 2011 03:55:22 -0000 X-IronPort-AV: E=Sophos;i="4.68,458,1312156800"; d="scan'208";a="8116411" Received: from lonpmailmx01.citrite.net ([10.30.203.162]) by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5; 29 Sep 2011 03:57:14 +0000 Received: from woking.xci-test.com (10.80.248.135) by smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id 8.3.137.0; Thu, 29 Sep 2011 04:57:14 +0100 Received: from osstest by woking.xci-test.com with local (Exim 4.69) (envelope-from <ian.jackson@eu.citrix.com>) id 1R97kF-0001T0-Pe; Thu, 29 Sep 2011 04:57:13 +0100 To: xen-devel@lists.xensource.com Message-ID: <osstest-9118-mainreport@xen.org> From: xen.org <ian.jackson@eu.citrix.com> Date: Thu, 29 Sep 2011 04:57:11 +0100 MIME-Version: 1.0 Content-Type: text/plain Cc: ian.jackson@eu.citrix.com Subject: [Xen-devel] [xen-unstable test] 9118: tolerable FAIL X-BeenThere: xen-devel@lists.xensource.com X-Mailman-Version: 2.1.5 Precedence: list List-Id: Xen developer discussion <xen-devel.lists.xensource.com> List-Unsubscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe> List-Post: <mailto:xen-devel@lists.xensource.com> List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help> List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=subscribe> Sender: xen-devel-bounces@lists.xensource.com Errors-To: xen-devel-bounces@lists.xensource.com flight 9118 xen-unstable real [real] http://www.chiark.greenend.org.uk/~xensrcts/logs/9118/ Failures :-/ but no regressions. Tests which did not succeed, but are not blocking, including regressions (tests previously passed) regarded as allowable: test-amd64-amd64-xl-pcipt-intel 9 guest-start fail never pass test-amd64-i386-rhel6hvm-intel 9 guest-start.2 fail never pass test-amd64-i386-win-vcpus1 16 leak-check/check fail never pass test-amd64-i386-rhel6hvm-amd 9 guest-start.2 fail never pass test-amd64-i386-xl-win-vcpus1 13 guest-stop fail never pass test-amd64-i386-win 16 leak-check/check fail never pass test-amd64-amd64-win 16 leak-check/check fail never pass test-amd64-amd64-xl-win 13 guest-stop fail never pass test-i386-i386-win 16 leak-check/check fail never pass test-i386-i386-xl-win 13 guest-stop fail never pass version targeted for testing: xen 7998217630e2 baseline version: xen 7998217630e2 jobs: build-amd64 pass build-i386 pass build-amd64-oldkern pass build-i386-oldkern pass build-amd64-pvops pass build-i386-pvops pass test-amd64-amd64-xl pass test-amd64-i386-xl pass test-i386-i386-xl pass test-amd64-i386-rhel6hvm-amd fail test-amd64-i386-xl-credit2 pass test-amd64-amd64-xl-pcipt-intel fail test-amd64-i386-rhel6hvm-intel fail test-amd64-i386-xl-multivcpu pass test-amd64-amd64-pair pass test-amd64-i386-pair pass test-i386-i386-pair pass test-amd64-amd64-pv pass test-amd64-i386-pv pass test-i386-i386-pv pass test-amd64-amd64-xl-sedf pass test-amd64-i386-win-vcpus1 fail test-amd64-i386-xl-win-vcpus1 fail test-amd64-amd64-win fail test-amd64-i386-win fail test-i386-i386-win fail test-amd64-amd64-xl-win fail test-i386-i386-xl-win fail ------------------------------------------------------------ sg-report-flight on woking.cam.xci-test.com logs: /home/xc_osstest/logs images: /home/xc_osstest/images Logs, config files, etc. are available at http://www.chiark.greenend.org.uk/~xensrcts/logs Test harness code can be found at http://xenbits.xensource.com/gitweb?p=osstest.git;a=summary Published tested tree is already up to date. _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel From xen-devel-bounces@lists.xensource.com Wed Sep 28 23:08:51 2011 Return-path: <xen-devel-bounces@lists.xensource.com> Envelope-to: www-data@lists.xensource.com Delivery-date: Wed, 28 Sep 2011 23:08:51 -0700 Received: from localhost ([127.0.0.1] helo=lists.colo.xensource.com) by lists.xensource.com with esmtp (Exim 4.43) id 1R99nf-0006aA-Ij; Wed, 28 Sep 2011 23:08:51 -0700 Received: from mail174.messagelabs.com ([85.158.138.51]) by lists.xensource.com with esmtp (Exim 4.43) id 1R99mf-0006Nj-Le for Xen-devel@lists.xensource.com; Wed, 28 Sep 2011 23:07:53 -0700 X-Env-Sender: spniphadkar@gmail.com X-Msg-Ref: server-12.tower-174.messagelabs.com!1317276466!33158742!1 X-Originating-IP: [209.85.215.171] X-StarScan-Version: 6.4.1; banners=-,-,- X-VirusChecked: Checked Received: (qmail 28388 invoked from network); 29 Sep 2011 06:07:46 -0000 Received: from mail-ey0-f171.google.com (HELO mail-ey0-f171.google.com) (209.85.215.171) by server-12.tower-174.messagelabs.com with RC4-SHA encrypted SMTP; 29 Sep 2011 06:07:46 -0000 Received: by eye3 with SMTP id 3so239615eye.30 for <Xen-devel@lists.xensource.com>; Wed, 28 Sep 2011 23:07:46 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; bh=l0MVRHXk8N7HoDPyQMhsMCrZTnQRu8BqtJXPdqNFbaQ=; b=H2nHE9Z7MNHt0Kk2bak7bc0U5pm4Xf1b/Ghgp3qSCIm9wSzqIi6mv+7diJhV6O9vkw Sealv+HDxZNffMZHMFIQpL4bD3iAZT5sCkM4TLH/x7ENm5lW43M8RYv3seBcp3E1LiCE 3Bzicf9L8NqszB1Q3yPgW49jObQHlDVKMQ3S4= MIME-Version: 1.0 Received: by 10.213.32.198 with SMTP id e6mr143819ebd.130.1317276466128; Wed, 28 Sep 2011 23:07:46 -0700 (PDT) Received: by 10.213.28.13 with HTTP; Wed, 28 Sep 2011 23:07:46 -0700 (PDT) In-Reply-To: <20110928180909.GA7007@labbmf-linux.qualcomm.com> References: <20110928180909.GA7007@labbmf-linux.qualcomm.com> Date: Thu, 29 Sep 2011 11:37:46 +0530 Message-ID: <CAOFJiu1_HaboUMqtjowA2xKNmGviDE55GUV4OD1vN2hXUf4-kQ@mail.gmail.com> From: Sameer Pramod Niphadkar <spniphadkar@gmail.com> To: Larry Bassel <lbassel@codeaurora.org> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: linux-mm@kvack.org, vgandhi@codeaurora.org, Xen-devel@lists.xensource.com Subject: [Xen-devel] Re: RFC -- new zone type X-BeenThere: xen-devel@lists.xensource.com X-Mailman-Version: 2.1.5 Precedence: list List-Id: Xen developer discussion <xen-devel.lists.xensource.com> List-Unsubscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe> List-Post: <mailto:xen-devel@lists.xensource.com> List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help> List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=subscribe> Sender: xen-devel-bounces@lists.xensource.com Errors-To: xen-devel-bounces@lists.xensource.com On Wed, Sep 28, 2011 at 11:39 PM, Larry Bassel <lbassel@codeaurora.org> wro= te: > We need to create a large (~100M) contiguous physical memory region > which will only be needed occasionally. As this region will > use up 10-20% of all of the available memory, we do not want > to pre-reserve it at boot time. Instead, we want to create > this memory region "on the fly" when asked to by userspace, > and do it as quickly as possible, and return it to > system use when not needed. > > AFAIK, this sort of operation is currently done using memory > compaction (as CMA does for instance). > Alternatively, this memory region (if it is in a fixed place) > could be created using "logical memory hotremove" and returned > to the system using "logical memory hotplug". In either case, > the contiguous physical memory would be created via migrating > pages from the "movable zone". > > The problem with this approach is that the copying of up to 25000 > pages may take considerable time (as well as finding destinations > for all of the pages if free memory is scarce -- this may > even fail, causing the memory region not to be created). > > It was suggested to me that a new zone type which would be similar > to the "movable zone" but is only allowed to contain pages > that can be discarded (such as text) could solve this problem, > so that there is no copying or finding destination pages needed (thus > considerably reducing latency). > Is this approach similar to Copy-on-Write being used in most page sharing entitlements ? If yes, then it almost depends on the # of writes made on the pages. > The downside I see is that there may not be anywhere near > 25000 such discardable pages, so most of this zone would go unused, and > the memory would be "wasted" as in the case where it is pre-reserved. > Also, this is not currently supported, so new code would > have to be designed and implemented. > > I would appreciate people's comments about: > > 1. Does this type of zone make any sense? It > would have to co-exist with the current movable zone type. Ideally can't there be a reserved zone created from which all the remaining on-the fly zones are shared based on CoW ? > 2. How hard would it be to implement this? The new zone type would > need to be supported and "discardable" pages steered into this zone. > Most VMs do support ballooning, CoW and other forms of sharing and can provide as basis for any memory management projects. > 3. Are there better ways of allocating a large memory region > with minimal latency that I haven't mentioned here? > Hmm...there are mechanisms as pointed by yourself but they all depend on the policy of consolidation, priority and security of operations. > Thanks. > > Larry Bassel > > -- > Sent by an employee of the Qualcomm Innovation Center, Inc. > The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum= . > > -- > To unsubscribe, send a message with 'unsubscribe linux-mm' in > the body to majordomo@kvack.org. =A0For more info on Linux MM, > see: http://www.linux-mm.org/ . > Fight unfair telecom internet charges in Canada: sign http://stopthemeter= .ca/ > Don't email: <a href=3Dmailto:"dont@kvack.org"> email@kvack.org </a> > _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel From xen-devel-bounces@lists.xensource.com Wed Sep 28 23:12:42 2011 Return-path: <xen-devel-bounces@lists.xensource.com> Envelope-to: www-data@lists.xensource.com Delivery-date: Wed, 28 Sep 2011 23:12:42 -0700 Received: from localhost ([127.0.0.1] helo=lists.colo.xensource.com) by lists.xensource.com with esmtp (Exim 4.43) id 1R99rO-0006zv-Kk; Wed, 28 Sep 2011 23:12:42 -0700 Received: from mail174.messagelabs.com ([85.158.138.51]) by lists.xensource.com with esmtp (Exim 4.43) id 1R99qt-0006oA-Qj for xen-devel@lists.xensource.com; Wed, 28 Sep 2011 23:12:12 -0700 X-Env-Sender: amscanne@gridcentric.ca X-Msg-Ref: server-9.tower-174.messagelabs.com!1317276728!27132882!1 X-Originating-IP: [74.125.82.43] X-StarScan-Version: 6.4.1; banners=-,-,- X-VirusChecked: Checked Received: (qmail 300 invoked from network); 29 Sep 2011 06:12:08 -0000 Received: from mail-ww0-f43.google.com (HELO mail-ww0-f43.google.com) (74.125.82.43) by server-9.tower-174.messagelabs.com with RC4-SHA encrypted SMTP; 29 Sep 2011 06:12:08 -0000 Received: by wwf27 with SMTP id 27so338828wwf.24 for <xen-devel@lists.xensource.com>; Wed, 28 Sep 2011 23:12:08 -0700 (PDT) Received: by 10.216.172.10 with SMTP id s10mr10886181wel.85.1317276728211; Wed, 28 Sep 2011 23:12:08 -0700 (PDT) MIME-Version: 1.0 Received: by 10.216.10.129 with HTTP; Wed, 28 Sep 2011 23:11:48 -0700 (PDT) In-Reply-To: <20098.689.312648.316912@mariner.uk.xensource.com> References: <CAAJKtqpMqpWckNY=a9HrNZY8hT+cmH8odyLM2HKctSMY63=RRA@mail.gmail.com> <1316597699.3891.130.camel@zakaz.uk.xensource.com> <20098.689.312648.316912@mariner.uk.xensource.com> From: Adin Scannell <adin@gridcentric.com> Date: Thu, 29 Sep 2011 02:11:48 -0400 X-Google-Sender-Auth: uaKn8sFRHs_BgjKI5FxzKSsEsPg Message-ID: <CAAJKtqqXbPw0b49BvUog=95XUf41+EiVZjnWTsh=6iSbovPD9A@mail.gmail.com> Subject: Re: [Xen-devel] [PATCH] expose shared page count through xenlight [and 1 more messages] To: Ian Jackson <Ian.Jackson@eu.citrix.com> Content-Type: multipart/mixed; boundary=0016364180a174b89e04ae0e635b Cc: xen-devel@lists.xensource.com, Ian Campbell <Ian.Campbell@citrix.com> X-BeenThere: xen-devel@lists.xensource.com X-Mailman-Version: 2.1.5 Precedence: list List-Id: Xen developer discussion <xen-devel.lists.xensource.com> List-Unsubscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe> List-Post: <mailto:xen-devel@lists.xensource.com> List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help> List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=subscribe> Sender: xen-devel-bounces@lists.xensource.com Errors-To: xen-devel-bounces@lists.xensource.com --0016364180a174b89e04ae0e635b Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable I can address the output stuff with a future patch. For now, I've cut the patch to just add the shared page info to the libxl info (as its already exposed through libxc) and at least developers can access it programatically. Cheers, -Adin On Tue, Sep 27, 2011 at 1:06 PM, Ian Jackson <Ian.Jackson@eu.citrix.com> wr= ote: > Adin Scannell writes ("[Xen-devel] [PATCH] expose shared page count throu= gh xenlight"): >> Attached is a simple patch to expose the shared page information >> through libxl and xl. > > Thanks, but this will break existing callers who try to parse the > output from "xl list". > > It's a shame that we can't easily extend this. =A0In the future we will > hopefully have a json output mode and can tell people who need to > parse xl's output to use that. > > I'm not sure what the right answer is right now, though. > > Ian. > --0016364180a174b89e04ae0e635b Content-Type: application/octet-stream; name="libxl-shared-pages.patch" Content-Disposition: attachment; filename="libxl-shared-pages.patch" Content-Transfer-Encoding: base64 X-Attachment-Id: f_gt5c9jq10 RXhwb3NlIG51bWJlciBvZiBzaGFyZWQgcGFnZXMgdGhyb3VnaCBsaWJ4bC4KClNpZ25lZC1vZmYt Ynk6IEFkaW4gU2Nhbm5lbGwgPGFkaW5Ac2Nhbm5lbGwuY2E+CgpkaWZmIC1yIDI4ZTFhOGI2Yzkz NCAtciAyYTVlNTdlMmEzZDIgdG9vbHMvbGlieGwvbGlieGwuYwotLS0gYS90b29scy9saWJ4bC9s aWJ4bC5jCisrKyBiL3Rvb2xzL2xpYnhsL2xpYnhsLmMKQEAgLTMzNyw2ICszMzcsNyBAQCBzdGF0 aWMgdm9pZCB4Y2luZm8yeGxpbmZvKGNvbnN0IHhjX2RvbWFpCiAgICAgICAgIHhsaW5mby0+c2h1 dGRvd25fcmVhc29uICA9IH4wOwoKICAgICB4bGluZm8tPmN1cnJlbnRfbWVta2IgPSBQQUdFX1RP X01FTUtCKHhjaW5mby0+dG90X3BhZ2VzKTsKKyAgICB4bGluZm8tPnNoYXJlZF9tZW1rYiA9IFBB R0VfVE9fTUVNS0IoeGNpbmZvLT5zaHJfcGFnZXMpOwogICAgIHhsaW5mby0+bWF4X21lbWtiID0g UEFHRV9UT19NRU1LQih4Y2luZm8tPm1heF9wYWdlcyk7CiAgICAgeGxpbmZvLT5jcHVfdGltZSA9 IHhjaW5mby0+Y3B1X3RpbWU7CiAgICAgeGxpbmZvLT52Y3B1X21heF9pZCA9IHhjaW5mby0+bWF4 X3ZjcHVfaWQ7CmRpZmYgLXIgMjhlMWE4YjZjOTM0IC1yIDJhNWU1N2UyYTNkMiB0b29scy9saWJ4 bC9saWJ4bC5pZGwKLS0tIGEvdG9vbHMvbGlieGwvbGlieGwuaWRsCisrKyBiL3Rvb2xzL2xpYnhs L2xpYnhsLmlkbApAQCAtNDAsNiArNDAsNyBAQCBsaWJ4bF9kb21pbmZvID0gU3RydWN0KCJkb21p bmZvIixbCiBPdGhlcndpc2Ugc2V0IHRvIGEgdmFsdWUgZ3VhcmFudGVlZCBub3QgdG8gY2xhc2gg d2l0aCBhbnkgdmFsaWQKIFNIVVRET1dOXyogY29uc3RhbnQuIiIiKSwKICAgICAoImN1cnJlbnRf bWVta2IiLCAgIHVpbnQ2NCksCisgICAgKCJzaGFyZWRfbWVta2IiLCB1aW50NjQpLAogICAgICgi bWF4X21lbWtiIiwgICB1aW50NjQpLAogICAgICgiY3B1X3RpbWUiLCAgICB1aW50NjQpLAogICAg ICgidmNwdV9tYXhfaWQiLCB1aW50MzIpLAo= --0016364180a174b89e04ae0e635b Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel --0016364180a174b89e04ae0e635b-- From xen-devel-bounces@lists.xensource.com Wed Sep 28 23:16:38 2011 Return-path: <xen-devel-bounces@lists.xensource.com> Envelope-to: www-data@lists.xensource.com Delivery-date: Wed, 28 Sep 2011 23:16:38 -0700 Received: from localhost ([127.0.0.1] helo=lists.colo.xensource.com) by lists.xensource.com with esmtp (Exim 4.43) id 1R99vC-0007P5-3U; Wed, 28 Sep 2011 23:16:38 -0700 Received: from mail174.messagelabs.com ([85.158.138.51]) by lists.xensource.com with esmtp (Exim 4.43) id 1R99uj-0007DM-EK for xen-devel@lists.xensource.com; Wed, 28 Sep 2011 23:16:09 -0700 X-Env-Sender: amscanne@gridcentric.ca X-Msg-Ref: server-3.tower-174.messagelabs.com!1317276966!27109728!1 X-Originating-IP: [74.125.82.171] X-StarScan-Version: 6.4.1; banners=-,-,- X-VirusChecked: Checked Received: (qmail 26062 invoked from network); 29 Sep 2011 06:16:06 -0000 Received: from mail-wy0-f171.google.com (HELO mail-wy0-f171.google.com) (74.125.82.171) by server-3.tower-174.messagelabs.com with RC4-SHA encrypted SMTP; 29 Sep 2011 06:16:06 -0000 Received: by wyh13 with SMTP id 13so65183wyh.30 for <xen-devel@lists.xensource.com>; Wed, 28 Sep 2011 23:16:06 -0700 (PDT) Received: by 10.216.229.103 with SMTP id g81mr6093949weq.0.1317276966072; Wed, 28 Sep 2011 23:16:06 -0700 (PDT) MIME-Version: 1.0 Received: by 10.216.10.129 with HTTP; Wed, 28 Sep 2011 23:15:46 -0700 (PDT) In-Reply-To: <20110928124231.GA19629@aepfle.de> References: <CACavRyCNghRyXwUMeWdoyqLwgmOX2KyuD+oerA8W75JL+07wdw@mail.gmail.com> <20110928124231.GA19629@aepfle.de> From: Adin Scannell <adin@gridcentric.ca> Date: Thu, 29 Sep 2011 02:15:46 -0400 X-Google-Sender-Auth: QpH0KQI6kbS3krqKDrDuD6Fq7iI Message-ID: <CAAJKtqrYvgb_kWaOGArhG+fTMR1VgTMuCBLhyPW_brBF+DO=yw@mail.gmail.com> Subject: Re: [Xen-devel] Re: event channel in xenpaging To: Olaf Hering <olaf@aepfle.de>, zhen shi <bickys1986@gmail.com> Content-Type: text/plain; charset=ISO-8859-1 Cc: xen-devel@lists.xensource.com X-BeenThere: xen-devel@lists.xensource.com X-Mailman-Version: 2.1.5 Precedence: list List-Id: Xen developer discussion <xen-devel.lists.xensource.com> List-Unsubscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe> List-Post: <mailto:xen-devel@lists.xensource.com> List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help> List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=subscribe> Sender: xen-devel-bounces@lists.xensource.com Errors-To: xen-devel-bounces@lists.xensource.com >> I have some questions about event channel in Xenpaging to ask you. >> 1) In xenpaging it uses Inter-Domainain Commnication (IDC) between >> dom0 and domU to build bidirectional connection,but I found there is >> only an event channel notification from xen to dom0 when page faults >> happens.It seems that xenpaging_resume_page()->xc_evtchn_notify() >> doesn't make any difference.So why don't use vIRQ between dom0 and xen >> instead of IDC between dom0 and domU? > > I talked with Adin Scannel about that, he has changes to use an event > channel instead of domctrl for communication. The current event channel > usage in xenpaging is a noop. I just sent these patches to xen-devel today if you'd like to test them. Basically, you need only do the xc_evtchn_notify() -- although the domctl will also work if you'd like to do a synchronous resume. _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel From xen-devel-bounces@lists.xensource.com Thu Sep 29 00:44:30 2011 Return-path: <xen-devel-bounces@lists.xensource.com> Envelope-to: www-data@lists.xensource.com Delivery-date: Thu, 29 Sep 2011 00:44:30 -0700 Received: from localhost ([127.0.0.1] helo=lists.colo.xensource.com) by lists.xensource.com with esmtp (Exim 4.43) id 1R9BID-0000xh-Az; Thu, 29 Sep 2011 00:44:29 -0700 Received: from mail174.messagelabs.com ([85.158.138.51]) by lists.xensource.com with esmtp (Exim 4.43) id 1R9BHG-0000kx-CV for xen-devel@lists.xensource.com; Thu, 29 Sep 2011 00:43:31 -0700 X-Env-Sender: JBeulich@suse.com X-Msg-Ref: server-2.tower-174.messagelabs.com!1317282207!33182534!1 X-Originating-IP: [130.57.49.28] X-StarScan-Version: 6.4.1; banners=-,-,- X-VirusChecked: Checked Received: (qmail 9044 invoked from network); 29 Sep 2011 07:43:27 -0000 Received: from nat28.tlf.novell.com (HELO nat28.tlf.novell.com) (130.57.49.28) by server-2.tower-174.messagelabs.com with DHE-RSA-AES256-SHA encrypted SMTP; 29 Sep 2011 07:43:27 -0000 Received: from EMEA1-MTA by nat28.tlf.novell.com with Novell_GroupWise; Thu, 29 Sep 2011 08:43:26 +0100 Message-Id: <4E843DBD020000780005865C@nat28.tlf.novell.com> X-Mailer: Novell GroupWise Internet Agent 8.0.1 Date: Thu, 29 Sep 2011 08:43:25 +0100 From: "Jan Beulich" <JBeulich@suse.com> To: "Adin Scannell" <adin@gridcentric.com> Subject: Re: [Xen-devel] [PATCH] build fixes for cross-compiling References: <CAAJKtqre0Q3qbngZi01NfmSQSh0YXtSyS4LZc=cOQt98Xqzcyw@mail.gmail.com> In-Reply-To: <CAAJKtqre0Q3qbngZi01NfmSQSh0YXtSyS4LZc=cOQt98Xqzcyw@mail.gmail.com> Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: quoted-printable Content-Disposition: inline Cc: xen-devel@lists.xensource.com X-BeenThere: xen-devel@lists.xensource.com X-Mailman-Version: 2.1.5 Precedence: list List-Id: Xen developer discussion <xen-devel.lists.xensource.com> List-Unsubscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe> List-Post: <mailto:xen-devel@lists.xensource.com> List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help> List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=subscribe> Sender: xen-devel-bounces@lists.xensource.com Errors-To: xen-devel-bounces@lists.xensource.com >>> On 28.09.11 at 23:31, Adin Scannell <adin@gridcentric.com> wrote: > I always have problems cross-compiling tools (I build everything on a > 64-bit machine and generally target a 32-bit host), because all the > link steps are missing targets. I've use this tiny patch on the base > of my workspaces. >=20 > To my knowledge, this doesn't break anything -- but who knows with > builds, particularly cross-compiling. I just thought I'd throw this > there in case others have the same issue and it doesn't affect > standard build environments. Are you saying this actually works for you (building everything, not just the tools)? I do cross builds too, but generally the other way around (64-bit build on 32-bit host), and hence need to only cross-build the hypervisor to put underneath everything. > diff -r a422e2a4451e config/x86_32.mk > --- a/config/x86_32.mk > +++ b/config/x86_32.mk > @@ -8,6 +8,7 @@ CONFIG_XCUTILS :=3D y > CONFIG_IOEMU :=3D y >=20 > CFLAGS +=3D -m32 -march=3Di686 > +LDFLAGS +=3D -m32 -march=3Di686 I can't seem to find an ld (native or cross) that would accept -m32, -march=3Di686, ... > > # Use only if calling $(LD) directly. > LDFLAGS_DIRECT_OpenBSD =3D _obsd > diff -r a422e2a4451e config/x86_64.mk > --- a/config/x86_64.mk > +++ b/config/x86_64.mk > @@ -9,6 +9,7 @@ CONFIG_XCUTILS :=3D y > CONFIG_IOEMU :=3D y >=20 > CFLAGS +=3D -m64 > +LDFLAGS +=3D -m64 ... or -m64. But $(LDFLAGS) gets passed to $(LD) when building Xen (other than for the tools, where generally $(CC) is used to do the linking). Jan >=20 > LIBLEAFDIR =3D $(LIBLEAFDIR_x86_64) > LIBDIR =3D $(LIBDIR_x86_64) _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel From xen-devel-bounces@lists.xensource.com Thu Sep 29 00:55:37 2011 Return-path: <xen-devel-bounces@lists.xensource.com> Envelope-to: www-data@lists.xensource.com Delivery-date: Thu, 29 Sep 2011 00:55:37 -0700 Received: from localhost ([127.0.0.1] helo=lists.colo.xensource.com) by lists.xensource.com with esmtp (Exim 4.43) id 1R9BSz-0001YA-LR; Thu, 29 Sep 2011 00:55:37 -0700 Received: from mail21.messagelabs.com ([85.158.143.35]) by lists.xensource.com with esmtp (Exim 4.43) id 1R9BSS-0001Lb-C5 for xen-devel@lists.xensource.com; Thu, 29 Sep 2011 00:55:04 -0700 X-Env-Sender: Ian.Campbell@eu.citrix.com X-Msg-Ref: server-6.tower-21.messagelabs.com!1317282881!40083082!1 X-Originating-IP: [62.200.22.115] X-StarScan-Version: 6.4.1; banners=-,-,- X-VirusChecked: Checked Received: (qmail 22372 invoked from network); 29 Sep 2011 07:54:41 -0000 Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115) by server-6.tower-21.messagelabs.com with RC4-SHA encrypted SMTP; 29 Sep 2011 07:54:41 -0000 X-IronPort-AV: E=Sophos;i="4.68,459,1312156800"; d="scan'208";a="8118828" Received: from lonpmailmx01.citrite.net ([10.30.203.162]) by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5; 29 Sep 2011 07:55:01 +0000 Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net (10.30.203.162) with Microsoft SMTP Server id 8.3.137.0; Thu, 29 Sep 2011 08:55:01 +0100 Subject: Re: [Xen-devel] [PATCH] build fixes for cross-compiling From: Ian Campbell <Ian.Campbell@citrix.com> To: Adin Scannell <adin@gridcentric.com> Date: Thu, 29 Sep 2011 08:55:00 +0100 In-Reply-To: <CAAJKtqre0Q3qbngZi01NfmSQSh0YXtSyS4LZc=cOQt98Xqzcyw@mail.gmail.com> References: <CAAJKtqre0Q3qbngZi01NfmSQSh0YXtSyS4LZc=cOQt98Xqzcyw@mail.gmail.com> Organization: Citrix Systems, Inc. Content-Type: text/plain; charset="UTF-8" X-Mailer: Evolution 3.0.3- Content-Transfer-Encoding: 7bit Message-ID: <1317282900.26672.99.camel@zakaz.uk.xensource.com> MIME-Version: 1.0 Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com> X-BeenThere: xen-devel@lists.xensource.com X-Mailman-Version: 2.1.5 Precedence: list List-Id: Xen developer discussion <xen-devel.lists.xensource.com> List-Unsubscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe> List-Post: <mailto:xen-devel@lists.xensource.com> List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help> List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=subscribe> Sender: xen-devel-bounces@lists.xensource.com Errors-To: xen-devel-bounces@lists.xensource.com On Wed, 2011-09-28 at 22:31 +0100, Adin Scannell wrote: > I always have problems cross-compiling tools (I build everything on a > 64-bit machine and generally target a 32-bit host), because all the > link steps are missing targets. I've use this tiny patch on the base > of my workspaces. > > To my knowledge, this doesn't break anything -- but who knows with > builds, particularly cross-compiling. I just thought I'd throw this > there in case others have the same issue and it doesn't affect > standard build environments. FWIW Linux does approximately the same thing. It uses it's cc-option construct in the m32 case (presumably once upon a time non-biarch 32 bit compilers were common) but given that we already use -m32 unconditionally in CFLAGS I guess we don't care now. I don't actually do cross compiles myself (only because it doesn't work... so maybe now I will) but this didn't break my native 32 bit tools or native 64 bit Xen build so: Acked-by: Ian Campbell <ian.campbell@citrix.com> (I suppose this change is small enough not to require > > > diff -r a422e2a4451e config/x86_32.mk > --- a/config/x86_32.mk > +++ b/config/x86_32.mk > @@ -8,6 +8,7 @@ CONFIG_XCUTILS := y > CONFIG_IOEMU := y > > CFLAGS += -m32 -march=i686 > +LDFLAGS += -m32 -march=i686 > > # Use only if calling $(LD) directly. > LDFLAGS_DIRECT_OpenBSD = _obsd > diff -r a422e2a4451e config/x86_64.mk > --- a/config/x86_64.mk > +++ b/config/x86_64.mk > @@ -9,6 +9,7 @@ CONFIG_XCUTILS := y > CONFIG_IOEMU := y > > CFLAGS += -m64 > +LDFLAGS += -m64 > > LIBLEAFDIR = $(LIBLEAFDIR_x86_64) > LIBDIR = $(LIBDIR_x86_64) _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel From xen-devel-bounces@lists.xensource.com Thu Sep 29 01:04:59 2011 Return-path: <xen-devel-bounces@lists.xensource.com> Envelope-to: www-data@lists.xensource.com Delivery-date: Thu, 29 Sep 2011 01:04:59 -0700 Received: from localhost ([127.0.0.1] helo=lists.colo.xensource.com) by lists.xensource.com with esmtp (Exim 4.43) id 1R9Bc1-00026B-T3; Thu, 29 Sep 2011 01:04:58 -0700 Received: from mail27.messagelabs.com ([193.109.254.147]) by lists.xensource.com with esmtp (Exim 4.43) id 1R9BY0-0001pd-Bu for xen-devel@lists.xensource.com; Thu, 29 Sep 2011 01:01:30 -0700 X-Env-Sender: Ian.Campbell@eu.citrix.com X-Msg-Ref: server-4.tower-27.messagelabs.com!1317283222!42218778!1 X-Originating-IP: [62.200.22.115] X-StarScan-Version: 6.4.1; banners=-,-,- X-VirusChecked: Checked Received: (qmail 12893 invoked from network); 29 Sep 2011 08:00:22 -0000 Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115) by server-4.tower-27.messagelabs.com with RC4-SHA encrypted SMTP; 29 Sep 2011 08:00:22 -0000 X-IronPort-AV: E=Sophos;i="4.68,459,1312156800"; d="scan'208";a="8118980" Received: from lonpmailmx01.citrite.net ([10.30.203.162]) by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5; 29 Sep 2011 08:00:41 +0000 Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net (10.30.203.162) with Microsoft SMTP Server id 8.3.137.0; Thu, 29 Sep 2011 09:00:41 +0100 Subject: Re: [Xen-devel] [PATCH] build fixes for cross-compiling From: Ian Campbell <Ian.Campbell@citrix.com> To: Jan Beulich <JBeulich@suse.com> Date: Thu, 29 Sep 2011 09:00:41 +0100 In-Reply-To: <4E843DBD020000780005865C@nat28.tlf.novell.com> References: <CAAJKtqre0Q3qbngZi01NfmSQSh0YXtSyS4LZc=cOQt98Xqzcyw@mail.gmail.com> <4E843DBD020000780005865C@nat28.tlf.novell.com> Organization: Citrix Systems, Inc. Content-Type: text/plain; charset="UTF-8" X-Mailer: Evolution 3.0.3- Content-Transfer-Encoding: 7bit Message-ID: <1317283241.26672.104.camel@zakaz.uk.xensource.com> MIME-Version: 1.0 Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>, Adin Scannell <adin@gridcentric.com> X-BeenThere: xen-devel@lists.xensource.com X-Mailman-Version: 2.1.5 Precedence: list List-Id: Xen developer discussion <xen-devel.lists.xensource.com> List-Unsubscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe> List-Post: <mailto:xen-devel@lists.xensource.com> List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help> List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=subscribe> Sender: xen-devel-bounces@lists.xensource.com Errors-To: xen-devel-bounces@lists.xensource.com On Thu, 2011-09-29 at 08:43 +0100, Jan Beulich wrote: > >>> On 28.09.11 at 23:31, Adin Scannell <adin@gridcentric.com> wrote: > > I always have problems cross-compiling tools (I build everything on a > > 64-bit machine and generally target a 32-bit host), because all the > > link steps are missing targets. I've use this tiny patch on the base > > of my workspaces. > > > > To my knowledge, this doesn't break anything -- but who knows with > > builds, particularly cross-compiling. I just thought I'd throw this > > there in case others have the same issue and it doesn't affect > > standard build environments. > > Are you saying this actually works for you (building everything, not just > the tools)? > > I do cross builds too, but generally the other way around (64-bit > build on 32-bit host), and hence need to only cross-build the > hypervisor to put underneath everything. > > > diff -r a422e2a4451e config/x86_32.mk > > --- a/config/x86_32.mk > > +++ b/config/x86_32.mk > > @@ -8,6 +8,7 @@ CONFIG_XCUTILS := y > > CONFIG_IOEMU := y > > > > CFLAGS += -m32 -march=i686 > > +LDFLAGS += -m32 -march=i686 > > I can't seem to find an ld (native or cross) that would accept -m32, > -march=i686, ... > > > > > # Use only if calling $(LD) directly. > > LDFLAGS_DIRECT_OpenBSD = _obsd > > diff -r a422e2a4451e config/x86_64.mk > > --- a/config/x86_64.mk > > +++ b/config/x86_64.mk > > @@ -9,6 +9,7 @@ CONFIG_XCUTILS := y > > CONFIG_IOEMU := y > > > > CFLAGS += -m64 > > +LDFLAGS += -m64 > > ... or -m64. But $(LDFLAGS) gets passed to $(LD) when building Xen > (other than for the tools, where generally $(CC) is used to do the > linking). This worked for me, the link line ends up as ld -m64 -melf_x86_64 -T xen.lds -N prelink.o \ /local/scratch/ianc/devel/xen-unstable.hg/xen/.xen-x86_64-syms.1.o -o /local/scratch/ianc/devel/xen-unstable.hg/xen/xen-x86_64-syms (the inclusion of the arch in the filename is a local patch) This is with ld from Debian Squeeze: $ ld --version GNU ld (GNU Binutils for Debian) 2.20.1-system.20100303 Ah, I think I see what's happening: the -melf... simply silently overrides the -m64, just "ld -m64" gives errors as you suggested, so does "ld -melf... -m64". We have LDFLAGS_DIRECT, adding LDFLAGS_INDIRECT seems a bit gross though... I wonder if perhaps LDFLAGS and LDFLAGS_DIRECT should be mut8lly exclusive, i.e. direct calls to the linker use only the latter and not both? Ian. > > Jan > > > > > LIBLEAFDIR = $(LIBLEAFDIR_x86_64) > > LIBDIR = $(LIBDIR_x86_64) > > > > > _______________________________________________ > Xen-devel mailing list > Xen-devel@lists.xensource.com > http://lists.xensource.com/xen-devel _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel From xen-devel-bounces@lists.xensource.com Thu Sep 29 01:07:39 2011 Return-path: <xen-devel-bounces@lists.xensource.com> Envelope-to: www-data@lists.xensource.com Delivery-date: Thu, 29 Sep 2011 01:07:39 -0700 Received: from localhost ([127.0.0.1] helo=lists.colo.xensource.com) by lists.xensource.com with esmtp (Exim 4.43) id 1R9Bec-0002W2-Dc; Thu, 29 Sep 2011 01:07:38 -0700 Received: from mail174.messagelabs.com ([85.158.138.51]) by lists.xensource.com with smtp (Exim 4.43) id 1R9BcP-00028P-HL for xen-devel@lists.xensource.com; Thu, 29 Sep 2011 01:05:37 -0700 X-Env-Sender: s-v-lnmIP5V_Dp8qWPt3gLh8PSB9xJnIMatQcimaP7HgN1tz0T2dagqz@bo unce.linkedin.com X-Msg-Ref: server-9.tower-174.messagelabs.com!1317283517!27148173!1 X-Originating-IP: [216.52.242.164] X-StarScan-Version: 6.4.1; banners=-,-,- X-VirusChecked: Checked Received: (qmail 8089 invoked from network); 29 Sep 2011 08:05:18 -0000 Received: from maile-ba.linkedin.com (HELO maile-ba.linkedin.com) (216.52.242.164) by server-9.tower-174.messagelabs.com with SMTP; 29 Sep 2011 08:05:18 -0000 DomainKey-Signature: q=dns; a=rsa-sha1; c=nofws; s=prod; d=linkedin.com; h=DKIM-Signature:Sender:Date:From:To:Message-ID:Subject:MIME-Version:Content-Type:X-LinkedIn-Template:X-LinkedIn-Class:X-LinkedIn-fbl; b=NnNnteDvkqCNbVuGs8YunoP/4OsvwUQh9XbBxMk4vDGBGuFwGvrNgfWuhgLt7xeR PeiD61B9yRt/2XJaMwAS3LdI7ILUlyGp8NIpLYmQHnrr6BfS8cu8Bme5j2VkQNyI DKIM-Signature: v=1; a=rsa-sha1; d=linkedin.com; s=proddkim; c=relaxed/relaxed; q=dns/txt; i=@linkedin.com; t=1317283516; h=From:Subject:Date:To:MIME-Version:Content-Type:X-LinkedIn-Class:X-LinkedIn-fbl: X-LinkedIn-Template; bh=fVgPcDeHHQay8YMtwjFY8vXVBfA=; b=ctXi6Noi+3+oRiu6Bjlg3M1xLa2HvZ8E3wPFVU9gAZj9YHeoeiqdxoJGY4LAwoEb Oz4O5vdyD2LPt9FfmSwx4I3jHJ/fzfTFoZQLrdRBU0StZZ61uOH4ZGf0Dhbbhv0L; Date: Thu, 29 Sep 2011 08:05:16 +0000 (UTC) From: Ajeeshrao r <ajishrao@gmail.com> To: <xen-devel@lists.xensource.com> Message-ID: <2019447084.4747880.1317283516724.JavaMail.app@ela4-app0133.prod> MIME-Version: 1.0 X-LinkedIn-Template: invite_guest_59 X-LinkedIn-Class: INVITE-GUEST X-LinkedIn-fbl: s-v-lnmIP5V_Dp8qWPt3gLh8PSB9xJnIMatQcimaP7HgN1tz0T2dagqz Subject: [Xen-devel] Invitation to connect on LinkedIn X-BeenThere: xen-devel@lists.xensource.com X-Mailman-Version: 2.1.5 Precedence: list List-Id: Xen developer discussion <xen-devel.lists.xensource.com> List-Unsubscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe> List-Post: <mailto:xen-devel@lists.xensource.com> List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help> List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=subscribe> Content-Type: multipart/mixed; boundary="===============0517115719==" Sender: xen-devel-bounces@lists.xensource.com Errors-To: xen-devel-bounces@lists.xensource.com --===============0517115719== Content-Type: multipart/alternative; boundary="----=_Part_4747879_1823307949.1317283516722" ------=_Part_4747879_1823307949.1317283516722 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit I'd like to add you to my professional network on LinkedIn. - Ajeeshrao Ajeeshrao r Tech Lead at Yahoo! India Private Limited Bengaluru Area, India Confirm that you know Ajeeshrao r: https://www.linkedin.com/e/g3qy2u-gt5glelt-2q/isd/4394123709/KHMjorxw/?hs=false&tok=2QsfrtmACB04Y1 -- You are receiving Invitation to Connect emails. Click to unsubscribe: http://www.linkedin.com/e/g3qy2u-gt5glelt-2q/93IoRa1TuGiXQo4VcYuX-eBzziJq_RmV_Y76_WtjajRk/goo/xen-devel%40lists%2Exensource%2Ecom/20061/I1522298117_1/?hs=false&tok=268PkVeCyB04Y1 (c) 2011 LinkedIn Corporation. 2029 Stierlin Ct, Mountain View, CA 94043, USA. ------=_Part_4747879_1823307949.1317283516722 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: 7bit <html> <body> <table border="0" cellspacing="0" cellpadding="0" style="font-family:Arial;" width="100%" bgcolor="#F4F4F4"><tr><td align="center"> <table border="0" cellspacing="0" cellpadding="0" style="font-family:Arial;" width="550"> <tr><td> <table width="1" border="0" cellspacing="0" cellpadding="0"><tr><td><div style="height:10px;font-size:10px;line-height:10px;"> </div></td></tr></table> </td></tr> <tr><td align="left"> <img src="http://www.linkedin.com/scds/common/u/img/logos/logo_emails_trans_98x24.png" alt="LinkedIn" border="0" height="24" width="98"> </td></tr> <tr><td> <table width="1" border="0" cellspacing="0" cellpadding="0"><tr><td><div style="height:10px;font-size:10px;line-height:10px;"> </div></td></tr></table> </td></tr> </table> <table border="0" cellspacing="0" cellpadding="0" style="font-family:Arial;border:solid 1px #DDDDDD;-moz-border-radius:5px;-webkit-border-radius:5px;border-radius:5px;" bgcolor="#FFFFFF" width="550"><tr><td colspan="3"><table width="1" border="0" cellspacing="0" cellpadding="0"><tr><td><div style="height:15px;font-size:15px;line-height:15px;"> </div></td></tr></table></td></tr><tr><td width="1%"><table width="15" border="0" cellspacing="0" cellpadding="0"><tr><td><div style="height:0px;font-size:0px;line-height:0px;"> </div></td></tr></table></td><td width="98%" valign="top" align=""> <table border="0" cellspacing="0" cellpadding="0" style="font-family:Arial;" width="100%"> <tr> <td style="font-family:Arial,sans-serif;font-size:12px"> <div> <b style="font-size:16px;margin-right:12px">From Ajeeshrao r</b> </div> <table width="1" border="0" cellspacing="0" cellpadding="0"><tr><td><div style="height:6px;font-size:6px;line-height:6px;"> </div></td></tr></table> <div style="color:#666666">Tech Lead at Yahoo! India Private Limited</div> <div style="color:#666666">Bengaluru Area, India</div> <table width="1" border="0" cellspacing="0" cellpadding="0"><tr><td><div style="height:16px;font-size:16px;line-height:16px;"> </div></td></tr></table> </td> </tr> <tr> <td style="border:1px dotted #DDDDDD;border-width:1px 0"> <table border="0" cellspacing="0" cellpadding="0" style="font-family:Arial;background:#F2FAFF;width:100%" > <tr><td colspan="3"><table width="1" border="0" cellspacing="0" cellpadding="0"><tr><td><div style="height:4px;font-size:4px;line-height:4px;"> </div></td></tr></table></td></tr> <tr> <td><table width="5" border="0" cellspacing="0" cellpadding="0"><tr><td><div style="height:0px;font-size:0px;line-height:0px;"> </div></td></tr></table></td> <td style="font-family:Arial,sans-serif;font-size:12px"> <p> I'd like to add you to my professional network on LinkedIn.<br/> <br/> - Ajeeshrao </p> </td> <td><table width="5" border="0" cellspacing="0" cellpadding="0"><tr><td><div style="height:0px;font-size:0px;line-height:0px;"> </div></td></tr></table></td> </tr> <tr><td colspan="3"><table width="1" border="0" cellspacing="0" cellpadding="0"><tr><td><div style="height:5px;font-size:5px;line-height:5px;"> </div></td></tr></table></td></tr> </table> </td> </tr> <tr> <td> <table width="1" border="0" cellspacing="0" cellpadding="0"><tr><td><div style="height:12px;font-size:12px;line-height:12px;"> </div></td></tr></table> <table border="0" cellpadding="6" cellspacing="1" align=""><tr><td align="center" valign="middle" bgcolor="#FFE86C" background="http://www.linkedin.com/scds/common/u/img/bg/yellow_button_back.png" style="background:url(http://www.linkedin.com/scds/common/u/img/bg/yellow_button_back.png) repeat-x scroll 100% 0 #FFE86C;background-color:#FFE86C;border:1px solid #E8B463;-moz-border-radius:4px;-webkit-border-radius:4px;border-radius:4px;"><div style="padding-right:10px;padding-left:10px;"><a href="https://www.linkedin.com/e/g3qy2u-gt5glelt-2q/isd/4394123709/KHMjorxw/?hs=false&tok=2QsfrtmACB04Y1" style="text-decoration:none;"><span style="font-size:12px;font-family:Arial;font-weight:bold;color:#333333;white-space:nowrap;">Confirm that you know Ajeeshrao</span></a></div></td></tr></table> </td> </tr> </table> </td><td width="1%"><table width="15" border="0" cellspacing="0" cellpadding="0"><tr><td><div style="height:0px;font-size:0px;line-height:0px;"> </div></td></tr></table></td></tr><tr><td colspan="3"><table width="1" border="0" cellspacing="0" cellpadding="0"><tr><td><div style="height:15px;font-size:15px;line-height:15px;"> </div></td></tr></table></td></tr></table> <table width="1" border="0" cellspacing="0" cellpadding="0"><tr><td><div style="height:5px;font-size:5px;line-height:5px;"> </div></td></tr></table> <table border="0" cellspacing="0" cellpadding="0" style="font-family:Arial;width:550px" > <tr> <td style="color:#999;font-family:Arial,sans-serif;font-size:11px;line-height:15px"> <div>You are receiving Invitation to Connect emails. <a href="http://www.linkedin.com/e/g3qy2u-gt5glelt-2q/93IoRa1TuGiXQo4VcYuX-eBzziJq_RmV_Y76_WtjajRk/goo/xen-devel%40lists%2Exensource%2Ecom/20061/I1522298117_1/?hs=false&tok=268PkVeCyB04Y1">Unsubscribe</a></div> <div>© 2011, LinkedIn Corporation. 2029 Stierlin Ct. Mountain View, CA 94043, USA<table width="1" border="0" cellspacing="0" cellpadding="0"><tr><td><div style="height:1px;font-size:1px;line-height:1px;"> </div></td></tr></table></div> </td> </tr> </table> </td></tr></table> <img src="http://www.linkedin.com/emimp/g3qy2u-gt5glelt-2q.gif" style="width:1px; height:1px;"/></body> </html> ------=_Part_4747879_1823307949.1317283516722-- --===============0517115719== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel --===============0517115719==-- From xen-devel-bounces@lists.xensource.com Thu Sep 29 01:23:33 2011 Return-path: <xen-devel-bounces@lists.xensource.com> Envelope-to: www-data@lists.xensource.com Delivery-date: Thu, 29 Sep 2011 01:23:33 -0700 Received: from localhost ([127.0.0.1] helo=lists.colo.xensource.com) by lists.xensource.com with esmtp (Exim 4.43) id 1R9Bu1-0003Gc-IS; Thu, 29 Sep 2011 01:23:33 -0700 Received: from mail182.messagelabs.com ([85.158.139.83]) by lists.xensource.com with esmtp (Exim 4.43) id 1R9BtX-000347-SB for xen-devel@lists.xensource.com; Thu, 29 Sep 2011 01:23:04 -0700 X-Env-Sender: JBeulich@suse.com X-Msg-Ref: server-13.tower-182.messagelabs.com!1317284579!20022696!1 X-Originating-IP: [130.57.49.28] X-StarScan-Version: 6.4.1; banners=-,-,- X-VirusChecked: Checked Received: (qmail 11507 invoked from network); 29 Sep 2011 08:23:00 -0000 Received: from nat28.tlf.novell.com (HELO nat28.tlf.novell.com) (130.57.49.28) by server-13.tower-182.messagelabs.com with DHE-RSA-AES256-SHA encrypted SMTP; 29 Sep 2011 08:23:00 -0000 Received: from EMEA1-MTA by nat28.tlf.novell.com with Novell_GroupWise; Thu, 29 Sep 2011 09:22:59 +0100 Message-Id: <4E844703020000780005868E@nat28.tlf.novell.com> X-Mailer: Novell GroupWise Internet Agent 8.0.1 Date: Thu, 29 Sep 2011 09:22:59 +0100 From: "Jan Beulich" <JBeulich@suse.com> To: "Ian Campbell" <Ian.Campbell@citrix.com> Subject: Re: [Xen-devel] [PATCH] build fixes for cross-compiling References: <CAAJKtqre0Q3qbngZi01NfmSQSh0YXtSyS4LZc=cOQt98Xqzcyw@mail.gmail.com> <4E843DBD020000780005865C@nat28.tlf.novell.com> <1317283241.26672.104.camel@zakaz.uk.xensource.com> In-Reply-To: <1317283241.26672.104.camel@zakaz.uk.xensource.com> Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: quoted-printable Content-Disposition: inline Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>, Adin Scannell <adin@gridcentric.com> X-BeenThere: xen-devel@lists.xensource.com X-Mailman-Version: 2.1.5 Precedence: list List-Id: Xen developer discussion <xen-devel.lists.xensource.com> List-Unsubscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe> List-Post: <mailto:xen-devel@lists.xensource.com> List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help> List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=subscribe> Sender: xen-devel-bounces@lists.xensource.com Errors-To: xen-devel-bounces@lists.xensource.com >>> On 29.09.11 at 10:00, Ian Campbell <Ian.Campbell@citrix.com> wrote: > We have LDFLAGS_DIRECT, adding LDFLAGS_INDIRECT seems a bit gross > though... I wonder if perhaps LDFLAGS and LDFLAGS_DIRECT should be > mut8lly exclusive, i.e. direct calls to the linker use only the latter > and not both? Actually I always found it wrong to read commands like "$(CC) $(LDFLAGS)" - imo xxxFLAGS should be passed exclusively to tool xxx. So rather than having LDFLAGS_DIRECT, I'd suggest cleaning this up and having e.g. CCLDFLAGS or CC_LINK_FLAGS or some such. Jan _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel From xen-devel-bounces@lists.xensource.com Thu Sep 29 01:25:04 2011 Return-path: <xen-devel-bounces@lists.xensource.com> Envelope-to: www-data@lists.xensource.com Delivery-date: Thu, 29 Sep 2011 01:25:04 -0700 Received: from localhost ([127.0.0.1] helo=lists.colo.xensource.com) by lists.xensource.com with esmtp (Exim 4.43) id 1R9BvU-0003eC-Jj; Thu, 29 Sep 2011 01:25:04 -0700 Received: from mail216.messagelabs.com ([85.158.143.99]) by lists.xensource.com with esmtp (Exim 4.43) id 1R9BuK-0003NB-KD for xen-devel@lists.xensource.com; Thu, 29 Sep 2011 01:23:54 -0700 X-Env-Sender: Ian.Campbell@eu.citrix.com X-Msg-Ref: server-2.tower-216.messagelabs.com!1317284628!19511234!1 X-Originating-IP: [66.165.176.89] X-StarScan-Version: 6.4.1; banners=-,-,- X-VirusChecked: Checked Received: (qmail 28703 invoked from network); 29 Sep 2011 08:23:49 -0000 Received: from smtp.citrix.com (HELO SMTP.CITRIX.COM) (66.165.176.89) by server-2.tower-216.messagelabs.com with RC4-SHA encrypted SMTP; 29 Sep 2011 08:23:49 -0000 X-IronPort-AV: E=Sophos;i="4.68,459,1312171200"; d="scan'208";a="17799171" Received: from ftlpmailmx02.citrite.net ([10.13.107.66]) by FTLPIPO01.CITRIX.COM with ESMTP/TLS/RC4-MD5; 29 Sep 2011 04:23:47 -0400 Received: from smtp01.ad.xensource.com (10.219.128.104) by smtprelay.citrix.com (10.13.107.66) with Microsoft SMTP Server id 8.3.137.0; Thu, 29 Sep 2011 04:23:47 -0400 Received: from cosworth.uk.xensource.com (cosworth.uk.xensource.com [10.80.16.52]) by smtp01.ad.xensource.com (8.13.1/8.13.1) with ESMTP id p8T8Nkra024683; Thu, 29 Sep 2011 01:23:46 -0700 Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Mercurial-Node: fcdd79da6c20e5eba4c3099db988a769b23892ca Message-ID: <fcdd79da6c20e5eba4c3.1317284625@cosworth.uk.xensource.com> User-Agent: Mercurial-patchbomb/1.6.4 Date: Thu, 29 Sep 2011 09:23:45 +0100 From: Ian Campbell <ian.campbell@citrix.com> To: xen-devel@lists.xensource.com Cc: Ian Campbell <ian.campbell@citrix.com> Subject: [Xen-devel] [PATCH] libxl: remove hard tabs from libxl_event_get_disk_eject_info X-BeenThere: xen-devel@lists.xensource.com X-Mailman-Version: 2.1.5 Precedence: list List-Id: Xen developer discussion <xen-devel.lists.xensource.com> List-Unsubscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe> List-Post: <mailto:xen-devel@lists.xensource.com> List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help> List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=subscribe> Sender: xen-devel-bounces@lists.xensource.com Errors-To: xen-devel-bounces@lists.xensource.com # HG changeset patch # User Ian Campbell <ian.campbell@citrix.com> # Date 1317284615 -3600 # Node ID fcdd79da6c20e5eba4c3099db988a769b23892ca # Parent 52484af554a275b8187fae34691813c8698563e6 libxl: remove hard tabs from libxl_event_get_disk_eject_info the rest of this function uses spaces Signed-off-by: Ian Campbell <ian.campbell@citrix.com> diff -r 52484af554a2 -r fcdd79da6c20 tools/libxl/libxl.c --- a/tools/libxl/libxl.c Wed Sep 28 16:55:47 2011 +0100 +++ b/tools/libxl/libxl.c Thu Sep 29 09:23:35 2011 +0100 @@ -695,13 +695,13 @@ int libxl_event_get_disk_eject_info(libx sscanf(backend, "/local/domain/%d/backend/%" TOSTRING(BACKEND_STRING_SIZE) "[a-z]/%*d/%*d", &disk->backend_domid, backend_type); - if (!strcmp(backend_type, "tap") || !strcmp(backend_type, "vbd")) { - disk->backend = LIBXL_DISK_BACKEND_TAP; - } else if (!strcmp(backend_type, "qdisk")) { - disk->backend = LIBXL_DISK_BACKEND_QDISK; - } else { - disk->backend = LIBXL_DISK_BACKEND_UNKNOWN; - } + if (!strcmp(backend_type, "tap") || !strcmp(backend_type, "vbd")) { + disk->backend = LIBXL_DISK_BACKEND_TAP; + } else if (!strcmp(backend_type, "qdisk")) { + disk->backend = LIBXL_DISK_BACKEND_QDISK; + } else { + disk->backend = LIBXL_DISK_BACKEND_UNKNOWN; + } disk->pdev_path = strdup(""); disk->format = LIBXL_DISK_FORMAT_EMPTY; _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel From xen-devel-bounces@lists.xensource.com Thu Sep 29 01:26:30 2011 Return-path: <xen-devel-bounces@lists.xensource.com> Envelope-to: www-data@lists.xensource.com Delivery-date: Thu, 29 Sep 2011 01:26:30 -0700 Received: from localhost ([127.0.0.1] helo=lists.colo.xensource.com) by lists.xensource.com with esmtp (Exim 4.43) id 1R9Bws-00040z-Qb; Thu, 29 Sep 2011 01:26:30 -0700 Received: from mail182.messagelabs.com ([85.158.139.83]) by lists.xensource.com with esmtp (Exim 4.43) id 1R9BwM-0003oV-Lz for xen-devel@lists.xensource.com; Thu, 29 Sep 2011 01:25:59 -0700 X-Env-Sender: royger@gmail.com X-Msg-Ref: server-13.tower-182.messagelabs.com!1317284754!20023466!1 X-Originating-IP: [209.85.216.178] X-StarScan-Version: 6.4.1; banners=-,-,- X-VirusChecked: Checked Received: (qmail 23851 invoked from network); 29 Sep 2011 08:25:55 -0000 Received: from mail-qy0-f178.google.com (HELO mail-qy0-f178.google.com) (209.85.216.178) by server-13.tower-182.messagelabs.com with RC4-SHA encrypted SMTP; 29 Sep 2011 08:25:55 -0000 Received: by qyg14 with SMTP id 14so554900qyg.9 for <xen-devel@lists.xensource.com>; Thu, 29 Sep 2011 01:25:54 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=eoUGmW3FFUNCcy711PkavnaH0AobxEW9DA5ORSbMCOM=; b=tS5NKj8BtklSQONuBuLlUe6X+VYbql57Ys1+sexfhhhSdxCAYWvGCSdlTRSM7tD+Xk bd2G5sHM9mVA0eMZoUFsQSpg9XON+yMgHaUmIoB9khnX94KX3iNu8+ZMwjO72s/+3ac1 j8KecQ5x69lPq1ATdOBXYs8FbkpvQSPSRg+RA= MIME-Version: 1.0 Received: by 10.229.66.67 with SMTP id m3mr4605463qci.181.1317284754216; Thu, 29 Sep 2011 01:25:54 -0700 (PDT) Received: by 10.229.43.130 with HTTP; Thu, 29 Sep 2011 01:25:54 -0700 (PDT) In-Reply-To: <20099.8711.134578.942269@mariner.uk.xensource.com> References: <patchbomb.1316187417@loki> <aff3960421768180410c.1316187419@loki> <20098.362.319162.127153@mariner.uk.xensource.com> <1317197638.13424.104.camel@dagon.hellion.org.uk> <20099.8711.134578.942269@mariner.uk.xensource.com> Date: Thu, 29 Sep 2011 10:25:54 +0200 X-Google-Sender-Auth: x9QzCHMJtHAVgSyD1h3aC-wc3dE Message-ID: <CAPLaKK5WGfthNCf5+vg76AsmJbC_3XthF1_nH3+UqtXPZLpHcA@mail.gmail.com> Subject: Re: [Xen-devel] [PATCH 2 of 2] libxl: add support for booting PV domains from NetBSD using raw files as disks From: =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= <roger.pau@entel.upc.edu> To: Ian Jackson <Ian.Jackson@eu.citrix.com> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>, Ian Campbell <Ian.Campbell@citrix.com> X-BeenThere: xen-devel@lists.xensource.com X-Mailman-Version: 2.1.5 Precedence: list List-Id: Xen developer discussion <xen-devel.lists.xensource.com> List-Unsubscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe> List-Post: <mailto:xen-devel@lists.xensource.com> List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help> List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=subscribe> Sender: xen-devel-bounces@lists.xensource.com Errors-To: xen-devel-bounces@lists.xensource.com > Yes. > > The other elements of the block hotplug scripts don't do anything any > more on Linux I think, and currently libxl does not cope with script=3D > being set, so from a Linux pov this is a new feature for libxl. > >> Would we then need special handling to turn "file:<X>" into >> "phy:<X>,script=3Dblock-loop"? > > I think this should be done behind the scenes. =C2=A0The backend-specific > code in libxl should call some kind of "invoke this script" function > which would also be used for explicit "script=3D". > > On NetBSD, how do "more exciting" script=3D things work ? =C2=A0Eg, iscsi= or > nbd. NetBSD only has block and vif scripts currently, nothing fancy. > On Linux the idea is that the hotplug script sets up your nbd > which causes a real block device to appear, and that block device is > used by blkback. NetBSD uses this approach to mount virtual images, the image is mounted on the vnd device, and then this physical device is handled as a regular 'phy' backend. > >> I seem to remember something about setting up a faked out backend area >> for each backend and running the scripts against that instead of the >> real one. > > We would need to do that to support (eg) pygrub over nbd. > >> There was a subtle difference between NetBSD's and Linux's handling of >> these with xend. On Linux xend used to setup and manage the loopback >> device and create a simple phy backend referencing it. On NetBSD xend >> just sets up a file or phy backend as appropriate and the scripts which >> run out of xenbackendd take care of setting up the loopback as necessary >> and filing in the real device in xenstore. On teardown the loopback >> device needs to be cleaned up (and this is what currently fails). > > I'm not a fan of these approaches with a separate daemon. =C2=A0We should > avoid that if we can as it produces a lot of complication. I also think it's stupid to have two different programs watching xenstore, because that's what xenbackendd does. Instead, the code in xenbackendd could be move to libxl without much problem. The proper calls to the block, vif and other scripts can be added to libxl__device_destroy function to unplug vbd and network interfaces, but I don't know if that's the best place to put them, because I still don't have enough knowledge of libxl to decide that. As for the startup script, I have to look at the source to decide where to put them. Some advice about where would be the best place to put this calls is welcome. Regards, Roger. _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel From xen-devel-bounces@lists.xensource.com Thu Sep 29 01:58:26 2011 Return-path: <xen-devel-bounces@lists.xensource.com> Envelope-to: www-data@lists.xensource.com Delivery-date: Thu, 29 Sep 2011 01:58:27 -0700 Received: from localhost ([127.0.0.1] helo=lists.colo.xensource.com) by lists.xensource.com with esmtp (Exim 4.43) id 1R9CRl-00055D-Lz; Thu, 29 Sep 2011 01:58:25 -0700 Received: from mail216.messagelabs.com ([85.158.143.99]) by lists.xensource.com with esmtp (Exim 4.43) id 1R9CQb-0004sc-4s for Xen-devel@lists.xensource.com; Thu, 29 Sep 2011 01:57:15 -0700 X-Env-Sender: dunlapg@gmail.com X-Msg-Ref: server-15.tower-216.messagelabs.com!1317286623!19441978!1 X-Originating-IP: [209.85.210.171] X-StarScan-Version: 6.4.1; banners=-,-,- X-VirusChecked: Checked Received: (qmail 22689 invoked from network); 29 Sep 2011 08:57:04 -0000 Received: from mail-iy0-f171.google.com (HELO mail-iy0-f171.google.com) (209.85.210.171) by server-15.tower-216.messagelabs.com with RC4-SHA encrypted SMTP; 29 Sep 2011 08:57:04 -0000 Received: by iagv1 with SMTP id v1so639608iag.30 for <Xen-devel@lists.xensource.com>; Thu, 29 Sep 2011 01:57:03 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type; bh=gqDpVCM/ixPul29hFIgRTIwjh4xE7eprQgD4OYQYd58=; b=rtbef82kWqtyxlrU6wJSCM/ylvtieoXb6L3A8jzxEYAIIz/tBdNl6UJzIopgWwSGo5 uoch96uJy7+Dgw1I6XXKMR4rNFdX4SlGEunLM5k4+6hK1x3Jd4kzwv8ymvKDIPnDjimD 34ycNvxKk2rdO5VPXcQVQfTts+5UBg11GdduI= MIME-Version: 1.0 Received: by 10.231.29.141 with SMTP id q13mr2021216ibc.58.1317286623457; Thu, 29 Sep 2011 01:57:03 -0700 (PDT) Received: by 10.231.48.9 with HTTP; Thu, 29 Sep 2011 01:57:03 -0700 (PDT) In-Reply-To: <CAEO0G+B7j2hGZQZuK63CR_cCCXMv8k3eBqXcs+MAzJ2u5mabcw@mail.gmail.com> References: <CAEO0G+B7j2hGZQZuK63CR_cCCXMv8k3eBqXcs+MAzJ2u5mabcw@mail.gmail.com> Date: Thu, 29 Sep 2011 09:57:03 +0100 X-Google-Sender-Auth: rIowWXYrL5YIB1WAV3XSJ2WTYjI Message-ID: <CAFLBxZZLv=cJnCbkiv93eYGRLxPFVZDnsMS6-2qC1Ubqj8B6cQ@mail.gmail.com> Subject: Re: [Xen-devel] Monitoring traffic From: George Dunlap <George.Dunlap@eu.citrix.com> To: Sarath P R <sarath.amrita@gmail.com> Content-Type: text/plain; charset=ISO-8859-1 Cc: Xen-devel@lists.xensource.com X-BeenThere: xen-devel@lists.xensource.com X-Mailman-Version: 2.1.5 Precedence: list List-Id: Xen developer discussion <xen-devel.lists.xensource.com> List-Unsubscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe> List-Post: <mailto:xen-devel@lists.xensource.com> List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help> List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=subscribe> Sender: xen-devel-bounces@lists.xensource.com Errors-To: xen-devel-bounces@lists.xensource.com On Thu, Sep 29, 2011 at 4:36 AM, Sarath P R <sarath.amrita@gmail.com> wrote: > I am new to Xen. as part of my job i need to monitor some traffic. Like a > packet originates from which VM and all. Any APIs available for this or > where should i start with. Any help. thanks in advance Have you looked into tcpdump or wireshark? I believe that in dom0 there's a different network device for each virtual network interface (vif). You could try pointing tcpdump or wireshark at that vif, or at the xen bridge, and seeing what you get. -George _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel From xen-devel-bounces@lists.xensource.com Thu Sep 29 02:06:54 2011 Return-path: <xen-devel-bounces@lists.xensource.com> Envelope-to: www-data@lists.xensource.com Delivery-date: Thu, 29 Sep 2011 02:06:54 -0700 Received: from localhost ([127.0.0.1] helo=lists.colo.xensource.com) by lists.xensource.com with esmtp (Exim 4.43) id 1R9CZx-0005a7-Mv; Thu, 29 Sep 2011 02:06:53 -0700 Received: from mail216.messagelabs.com ([85.158.143.99]) by lists.xensource.com with esmtp (Exim 4.43) id 1R9CYa-0005NJ-0N for xen-devel@lists.xensource.com; Thu, 29 Sep 2011 02:05:30 -0700 X-Env-Sender: Ian.Campbell@eu.citrix.com X-Msg-Ref: server-11.tower-216.messagelabs.com!1317287124!12394728!1 X-Originating-IP: [62.200.22.115] X-StarScan-Version: 6.4.1; banners=-,-,- X-VirusChecked: Checked Received: (qmail 491 invoked from network); 29 Sep 2011 09:05:24 -0000 Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115) by server-11.tower-216.messagelabs.com with RC4-SHA encrypted SMTP; 29 Sep 2011 09:05:24 -0000 X-IronPort-AV: E=Sophos;i="4.68,460,1312156800"; d="scan'208";a="8120820" Received: from lonpmailmx01.citrite.net ([10.30.203.162]) by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5; 29 Sep 2011 09:05:24 +0000 Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net (10.30.203.162) with Microsoft SMTP Server id 8.3.137.0; Thu, 29 Sep 2011 10:05:24 +0100 Subject: Re: [Xen-devel] [PATCH 2 of 2] libxl: add support for booting PV domains from NetBSD using raw files as disks From: Ian Campbell <Ian.Campbell@eu.citrix.com> To: Roger Pau =?ISO-8859-1?Q?Monn=E9?= <roger.pau@entel.upc.edu> Date: Thu, 29 Sep 2011 10:05:24 +0100 In-Reply-To: <CAPLaKK5WGfthNCf5+vg76AsmJbC_3XthF1_nH3+UqtXPZLpHcA@mail.gmail.com> References: <patchbomb.1316187417@loki> <aff3960421768180410c.1316187419@loki> <20098.362.319162.127153@mariner.uk.xensource.com> <1317197638.13424.104.camel@dagon.hellion.org.uk> <20099.8711.134578.942269@mariner.uk.xensource.com> <CAPLaKK5WGfthNCf5+vg76AsmJbC_3XthF1_nH3+UqtXPZLpHcA@mail.gmail.com> Organization: Citrix Systems, Inc. Content-Type: text/plain; charset="UTF-8" X-Mailer: Evolution 3.0.3- Content-Transfer-Encoding: 8bit Message-ID: <1317287124.26672.124.camel@zakaz.uk.xensource.com> MIME-Version: 1.0 Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>, Ian Jackson <Ian.Jackson@eu.citrix.com> X-BeenThere: xen-devel@lists.xensource.com X-Mailman-Version: 2.1.5 Precedence: list List-Id: Xen developer discussion <xen-devel.lists.xensource.com> List-Unsubscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe> List-Post: <mailto:xen-devel@lists.xensource.com> List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help> List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=subscribe> Sender: xen-devel-bounces@lists.xensource.com Errors-To: xen-devel-bounces@lists.xensource.com On Thu, 2011-09-29 at 09:25 +0100, Roger Pau Monné wrote: > I also think it's stupid to have two different programs watching > xenstore, because that's what xenbackendd does. Instead, the code in > xenbackendd could be move to libxl without much problem. The proper > calls to the block, vif and other scripts can be added to > libxl__device_destroy function to unplug vbd and network interfaces, > but I don't know if that's the best place to put them, because I still > don't have enough knowledge of libxl to decide that. I think libxl__device_destroy is where they have to go right now, because there are destroy code paths which don't go through code with device-specific knowledge (specifically libxl__devices_destroy). Now, I'd like to change that in the long run (so all destroy paths knows about device specifics) but for now libxl__device_destroy will do. > As for the > startup script, I have to look at the source to decide where to put > them. Some advice about where would be the best place to put this > calls is welcome. I think libxl_device_disk_add() and libxl_device_nic_add() are the right places. The disk case is pretty trivial, I think, since you run the script before setting up the backend and after tearing it down again. The network case is a little trickier since you need to run the script after the backend driver has created the actual device in dom0 so the script can configure it (I presume this is much the same on NetBSD as Linux). The existing hotplug scripts are obviously pretty good for this (at least on Linux) since they are called at precisely the right time. How does NetBSD manage that synchronisation today in xenbackendd? I'm not sure how this can be done in an OS independent way and/or compatibly with the existing backend implementations for each platform . I'd have no problem with just tackling the block half now since it is the more critical bit for NetBSD users. There's a secondary issue of doing the right thing for libxl_device_disk_local_(attach|detach) (to allow e.g. pygrub) but again I think that could be left for the time being, fixing block devices for regular use by domains is more important. With regard to disabling the hotplug scripts/xenbackendd when this last came up we decided that /etc/init.d/xencommons should be opting in on a per-toolstack basis by touching a file (in /var/run or so) which the hotplug script check before actually doing anything. In the NetBSD case instead of touching a file I guess you start xenbackendd or not as appropriate (or pass the right parameters etc). That thread is "add a way to disable xen's udev script." from June, you'll probably want to skip to the end, specifically <19963.36234.366877.468293@mariner.uk.xensource.com> Ian. _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel From xen-devel-bounces@lists.xensource.com Thu Sep 29 02:56:27 2011 Return-path: <xen-devel-bounces@lists.xensource.com> Envelope-to: www-data@lists.xensource.com Delivery-date: Thu, 29 Sep 2011 02:56:27 -0700 Received: from localhost ([127.0.0.1] helo=lists.colo.xensource.com) by lists.xensource.com with esmtp (Exim 4.43) id 1R9DLv-0006vx-GF; Thu, 29 Sep 2011 02:56:27 -0700 Received: from mail21.messagelabs.com ([85.158.143.35]) by lists.xensource.com with esmtp (Exim 4.43) id 1R9DL8-0006jh-HG for xen-devel@lists.xensource.com; Thu, 29 Sep 2011 02:55:38 -0700 X-Env-Sender: JBeulich@suse.com X-Msg-Ref: server-7.tower-21.messagelabs.com!1317290103!56698702!1 X-Originating-IP: [130.57.49.28] X-StarScan-Version: 6.4.1; banners=-,-,- X-VirusChecked: Checked Received: (qmail 30379 invoked from network); 29 Sep 2011 09:55:04 -0000 Received: from nat28.tlf.novell.com (HELO nat28.tlf.novell.com) (130.57.49.28) by server-7.tower-21.messagelabs.com with DHE-RSA-AES256-SHA encrypted SMTP; 29 Sep 2011 09:55:04 -0000 Received: from EMEA1-MTA by nat28.tlf.novell.com with Novell_GroupWise; Thu, 29 Sep 2011 10:55:35 +0100 Message-Id: <4E845CB4020000780005871C@nat28.tlf.novell.com> X-Mailer: Novell GroupWise Internet Agent 8.0.1 Date: Thu, 29 Sep 2011 10:55:32 +0100 From: "Jan Beulich" <JBeulich@suse.com> To: "Jeremy Fitzhardinge" <jeremy@goop.org>, "Dong Yang Li" <lidongyang@suse.com> Subject: Re: [Xen-devel] blkback stuck in infinite loop in xen_blkbk_discard() References: <4E839451.40901@goop.org> In-Reply-To: <4E839451.40901@goop.org> Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: quoted-printable Content-Disposition: inline Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>, Konrad Rzeszutek Wilk <konrad.wilk@oracle.com> X-BeenThere: xen-devel@lists.xensource.com X-Mailman-Version: 2.1.5 Precedence: list List-Id: Xen developer discussion <xen-devel.lists.xensource.com> List-Unsubscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe> List-Post: <mailto:xen-devel@lists.xensource.com> List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help> List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=subscribe> Sender: xen-devel-bounces@lists.xensource.com Errors-To: xen-devel-bounces@lists.xensource.com >>> On 28.09.11 at 23:40, Jeremy Fitzhardinge <jeremy@goop.org> wrote: > I just "xl destroy"d a domain, and now my dom0 kernel is sitting there > infinitely spewing: >=20 > vbd vbd-83-51712: 5 reading type > vbd vbd-83-51712: 5 reading type > vbd vbd-83-51712: 5 reading type > vbd vbd-83-51712: 5 reading type > vbd vbd-83-51712: 5 reading type > vbd vbd-83-51712: 5 reading type > vbd vbd-83-51712: 5 reading type > vbd vbd-83-51712: 5 reading type > vbd vbd-83-51712: 5 reading type > vbd vbd-83-51712: 5 reading type > vbd vbd-83-51712: 5 reading type > vbd vbd-83-51712: 5 reading type > vbd vbd-83-51712: 5 reading type > vbd vbd-83-51712: 5 reading type > vbd vbd-83-51712: 5 reading type > vbd vbd-83-51712: 5 reading type > vbd vbd-83-51712: 5 reading type > vbd vbd-83-51712: 5 reading type > vbd vbd-83-51712: 5 reading type >=20 > which seems to be coming from the error case in > drivers/block/xen-blkback/xenbus.c:xen_blkbk_discard(). >=20 > I don't know what the backtrace is. The system seems overall fine, > despite the console spew, though I have a pile of dying domains sitting > in odd states rather than being cleaned up. I wonder how the function gets called during destroy in the first place, and how that would prevent destroying a domain (unless there's a feedback loop due to the use of xenbus_dev_fatal() here, causing some xenstore entry to get written over and over again, triggering the respective watch that blkback has active). But irrespective of this I would think the function should bail without doing anything if blkif->blk_backend_type was already set (or couldn't get set). But that would then also indicate a more general problem in connect(), as that function shouldn't do anything either when a domain gets destroyed. Jan _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel From xen-devel-bounces@lists.xensource.com Thu Sep 29 03:03:56 2011 Return-path: <xen-devel-bounces@lists.xensource.com> Envelope-to: www-data@lists.xensource.com Delivery-date: Thu, 29 Sep 2011 03:03:56 -0700 Received: from localhost ([127.0.0.1] helo=lists.colo.xensource.com) by lists.xensource.com with esmtp (Exim 4.43) id 1R9DTA-0007P4-It; Thu, 29 Sep 2011 03:03:56 -0700 Received: from mail182.messagelabs.com ([85.158.139.83]) by lists.xensource.com with esmtp (Exim 4.43) id 1R9DQH-0007Ak-5h for xen-devel@lists.xensource.com; Thu, 29 Sep 2011 03:01:15 -0700 X-Env-Sender: Stefano.Stabellini@eu.citrix.com X-Msg-Ref: server-13.tower-182.messagelabs.com!1317290452!20041874!1 X-Originating-IP: [62.200.22.115] X-StarScan-Version: 6.4.1; banners=-,-,- X-VirusChecked: Checked Received: (qmail 10977 invoked from network); 29 Sep 2011 10:00:52 -0000 Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115) by server-13.tower-182.messagelabs.com with RC4-SHA encrypted SMTP; 29 Sep 2011 10:00:52 -0000 X-IronPort-AV: E=Sophos;i="4.68,460,1312156800"; d="scan'208";a="8122791" Received: from lonpmailmx01.citrite.net ([10.30.203.162]) by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5; 29 Sep 2011 10:00:51 +0000 Received: from kaball.uk.xensource.com (10.80.2.59) by LONPMAILMX01.citrite.net (10.30.203.162) with Microsoft SMTP Server id 8.3.137.0; Thu, 29 Sep 2011 11:00:51 +0100 Date: Thu, 29 Sep 2011 11:00:38 +0100 From: Stefano Stabellini <stefano.stabellini@eu.citrix.com> X-X-Sender: sstabellini@kaball-desktop To: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com> Subject: Re: [Xen-devel] Re: [PATCH v4 2/2] xen: modify kernel mappings corresponding to granted pages In-Reply-To: <20110928230535.GA23001@phenom.oracle.com> Message-ID: <alpine.DEB.2.00.1109291059540.3519@kaball-desktop> References: <alpine.DEB.2.00.1109081944150.12963@kaball-desktop> <20110921145853.GA541@phenom.oracle.com> <alpine.DEB.2.00.1109231412220.8700@kaball-desktop> <20110923144538.GA10701@phenom.oracle.com> <alpine.DEB.2.00.1109271549030.3519@kaball-desktop> <20110928131229.GA10270@phenom.oracle.com> <20110928230535.GA23001@phenom.oracle.com> User-Agent: Alpine 2.00 (DEB 1167 2008-08-23) MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Cc: Jeremy Fitzhardinge <jeremy@goop.org>, "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>, "linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>, Stefano Stabellini <Stefano.Stabellini@eu.citrix.com> X-BeenThere: xen-devel@lists.xensource.com X-Mailman-Version: 2.1.5 Precedence: list List-Id: Xen developer discussion <xen-devel.lists.xensource.com> List-Unsubscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe> List-Post: <mailto:xen-devel@lists.xensource.com> List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help> List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=subscribe> Sender: xen-devel-bounces@lists.xensource.com Errors-To: xen-devel-bounces@lists.xensource.com On Thu, 29 Sep 2011, Konrad Rzeszutek Wilk wrote: > > > > But aren't that 'range of virtual address' of struct pages? You > > > > are using 'alloc_xenballooned_pages' to get those pages and that is > > > > what the 'range of virtual adresses' is walking through. > > > > > > it is not the same range of virtual addresses > > > > OK, but the pte_maddr is the same, isn't it? > > No it is not. It is the machine address of the PTE entry that > points to the 'struct page' (kernel linear address), while the > find_grant_pte's gets the machine address of the PTE entry that > points to the user pages. Completlely different machine addresses > of the PTEs. Right > Can you add a comment to the patch saying something along what > I just said? Just in case somebody is as thick as I am when looking > at this code/patch. Sure > Otherwise the patch looks fine - just fix up the SetPagePrivate, > the PAGE_GRANT bit, and add extra comments and I am ready to stick it > on my queue. OK! _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel From xen-devel-bounces@lists.xensource.com Thu Sep 29 03:55:04 2011 Return-path: <xen-devel-bounces@lists.xensource.com> Envelope-to: www-data@lists.xensource.com Delivery-date: Thu, 29 Sep 2011 03:55:04 -0700 Received: from localhost ([127.0.0.1] helo=lists.colo.xensource.com) by lists.xensource.com with esmtp (Exim 4.43) id 1R9EGe-0000Gk-4N; Thu, 29 Sep 2011 03:55:04 -0700 Received: from mail27.messagelabs.com ([193.109.254.147]) by lists.xensource.com with esmtp (Exim 4.43) id 1R9EFU-0008V2-PS for xen-devel@lists.xensource.com; Thu, 29 Sep 2011 03:53:59 -0700 X-Env-Sender: joseph.glanville@orionvm.com.au X-Msg-Ref: server-13.tower-27.messagelabs.com!1317293615!42030151!1 X-Originating-IP: [209.85.210.171] X-StarScan-Version: 6.4.1; banners=-,-,- X-VirusChecked: Checked Received: (qmail 11517 invoked from network); 29 Sep 2011 10:53:36 -0000 Received: from mail-iy0-f171.google.com (HELO mail-iy0-f171.google.com) (209.85.210.171) by server-13.tower-27.messagelabs.com with RC4-SHA encrypted SMTP; 29 Sep 2011 10:53:36 -0000 Received: by iagv1 with SMTP id v1so778217iag.30 for <xen-devel@lists.xensource.com>; Thu, 29 Sep 2011 03:53:48 -0700 (PDT) MIME-Version: 1.0 Received: by 10.231.66.14 with SMTP id l14mr14661192ibi.69.1317293627859; Thu, 29 Sep 2011 03:53:47 -0700 (PDT) Received: by 10.231.170.15 with HTTP; Thu, 29 Sep 2011 03:53:47 -0700 (PDT) X-Originating-IP: [59.167.234.130] In-Reply-To: <1317218459.26672.62.camel@zakaz.uk.xensource.com> References: <20110922130618.GA13238@phenom.oracle.com> <CAFLBxZaAaXTUtW5+VkxPnr_MR0fbW+d1Mzu4y0x=gEOaX9e0OQ@mail.gmail.com> <20110922174002.GA1205@phenom.oracle.com> <20098.1097.824552.541924@mariner.uk.xensource.com> <CAP2B85-=CbMgUGSwO2utvkeLLqk8A1vjhKrPwe2OD+0daAtqsA@mail.gmail.com> <1317195656.13424.73.camel@dagon.hellion.org.uk> <20099.8327.326129.357335@mariner.uk.xensource.com> <20110928134800.GH10270@phenom.oracle.com> <1317218459.26672.62.camel@zakaz.uk.xensource.com> Date: Thu, 29 Sep 2011 20:53:47 +1000 Message-ID: <CAOzFzEhnr7Ri42V1AUMLw-xRn+9NQwu8Pkq8iPc=pS12w=Vnog@mail.gmail.com> Subject: Re: [Xen-devel] Xen document day (Oct 12 or 26) From: Joseph Glanville <joseph.glanville@orionvm.com.au> To: Ian Campbell <Ian.Campbell@eu.citrix.com> Cc: Daniel Castro <evil.dani@gmail.com>, "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>, Ian Jackson <Ian.Jackson@eu.citrix.com>, Konrad Rzeszutek Wilk <konrad.wilk@oracle.com> X-BeenThere: xen-devel@lists.xensource.com X-Mailman-Version: 2.1.5 Precedence: list List-Id: Xen developer discussion <xen-devel.lists.xensource.com> List-Unsubscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe> List-Post: <mailto:xen-devel@lists.xensource.com> List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help> List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=subscribe> Content-Type: multipart/mixed; boundary="===============0765242288==" Sender: xen-devel-bounces@lists.xensource.com Errors-To: xen-devel-bounces@lists.xensource.com --===============0765242288== Content-Type: multipart/alternative; boundary=00151773e028c0e3b204ae12527d --00151773e028c0e3b204ae12527d Content-Type: text/plain; charset=ISO-8859-1 +1 for Markdown. In terms of making Xen more accessible I think it might be a good idea to update/cleanup the distro support page. http://wiki.xen.org/xenwiki/DistributionSupport I can probably do this. Making it simple for people to get started with Xen on a distro they are comfortable with is a good step forward. I know distro specific guides could turn into a nightmare but I am open to writing one for Debian 6 Squeeze, there are also a few that exist already for RHEL/CentOS on the wiki. This should get easier as more distros update to 3.0+ kernels that support PVops out of the box... Next would be networking documentation as network-bridge script has been deprecated. http://wiki.xensource.com/xenwiki/XenNetworking Once again I think alot of the documentation is going to be distro specific to be newbie friendly but atleast a simple ip/brctl guide would help. IMO knowing where to start and setting up networking were the biggest barriers when I was picking up Xen a few years back. I am also open to updating the blktap2 pages and README to reflect the new tap-ctl userspace utilities and tips on driver development. <slightly off-topic but related> With jailtime.org(stacklet) now charging for subscription there is nowhere to download pre-built clean Xen compatible images free of charge etc. I have pvgrub/pygrub capable images of Ubuntu/Debian/CentOS that I am considering hosting for free. Generally new users are confused on how to build new paravirt VMs, I think prebuilt images are suboptimal but a good place to start for beginners. Joseph. On 29 September 2011 00:00, Ian Campbell <Ian.Campbell@eu.citrix.com> wrote: > On Wed, 2011-09-28 at 14:48 +0100, Konrad Rzeszutek Wilk wrote: > > On Wed, Sep 28, 2011 at 02:26:31PM +0100, Ian Jackson wrote: > > > Ian Campbell writes ("Re: [Xen-devel] Xen document day (Oct 12 or > 26)"): > > > > Since the guest APIs are stable there should be relatively little > churn > > > > so perhaps a wiki page (or even series of pages) would be appropriate > > > > for this sort of thing? > > > > > > I want this to be in-tree. If it's in-tree, we can refuse patches > > > which do not update the documentation. > > > > > > > I think this would be good too and in fact even more important than > the > > > > interface documentation. Everyone needs to be able to build Xen to > hack > > > > on it but only a subset need to know any particular API. > > > > > > > > Also although we recommend that users consume Xen via their distro > where > > > > possible such a guide would also help any who would rather build from > > > > scratch (e.g. because we've asked them to "try the latest version" or > to > > > > bisect a bug etc). > > > > > > This would be a good candidate for a wiki page, backed up by revisions > > > of the in-tree README. > > > > > > Any recommendations on what would be a good format to write these > "interface" > > pages in? > > For in-line (i.e. in xen/include/public/*.h) docs of APIs I played a > little bit with integrating kernel-doc into the Xen build system but it > is tied a little too closely to the kernel build infrastructure. > > Doxygen seems like a plausible alternative with life outside the kernel > etc. We actually appear to already have some doxygen stuff for the > pytyhon stuff (judging from the Makefile, I've not actually noticed the > structured code comments anywhere) > > For non-inline docs I think we decided that markdown would be a good > answer. > > Ian. > > > _______________________________________________ > Xen-devel mailing list > Xen-devel@lists.xensource.com > http://lists.xensource.com/xen-devel > -- * Founder | Director | VP Research Orion Virtualisation Solutions* | www.orionvm.com.au | Phone: 1300 56 99 52 | Mobile: 0428 754 846 --00151773e028c0e3b204ae12527d Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable +1 for Markdown.<br><br>In terms of making Xen more accessible I think it m= ight be a good idea to update/cleanup the distro support page.<br><a href= =3D"http://wiki.xen.org/xenwiki/DistributionSupport">http://wiki.xen.org/xe= nwiki/DistributionSupport</a><br> <br>I can probably do this.<br>Making it simple for people to get started w= ith Xen on a distro they are comfortable with is a good step forward.<br>I = know distro specific guides could turn into a nightmare but I am open to wr= iting one for Debian 6 Squeeze, there are also a few that exist already for= RHEL/CentOS on the wiki.<br> This should get easier as more distros update to 3.0+ kernels that support = PVops out of the box...<br><br>Next would be networking documentation as ne= twork-bridge script has been deprecated.<br><a href=3D"http://wiki.xensourc= e.com/xenwiki/XenNetworking">http://wiki.xensource.com/xenwiki/XenNetworkin= g</a><br> Once again I think alot of the documentation is going to be distro specific= to be newbie friendly but atleast a simple ip/brctl guide would help.<br><= br>IMO knowing where to start and setting up networking were the biggest ba= rriers when I was picking up Xen a few years back.<br> <br>I am also open to updating the blktap2 pages and README to reflect the = new tap-ctl userspace utilities and tips on driver development.<br><br><= slightly off-topic but related><br><br>With <a href=3D"http://jailtime.o= rg">jailtime.org</a>(stacklet) now charging for subscription there is nowhe= re to download pre-built clean Xen compatible images free of charge etc.<br= > I have pvgrub/pygrub capable images of Ubuntu/Debian/CentOS that I am consi= dering hosting for free.<br>Generally new users are confused on how to buil= d new paravirt VMs, I think prebuilt images are suboptimal but a good place= to start for beginners.<br> <br>Joseph.<br><br><div class=3D"gmail_quote">On 29 September 2011 00:00, I= an Campbell <span dir=3D"ltr"><<a href=3D"mailto:Ian.Campbell@eu.citrix.= com">Ian.Campbell@eu.citrix.com</a>></span> wrote:<br><blockquote class= =3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padd= ing-left:1ex;"> <div class=3D"im">On Wed, 2011-09-28 at 14:48 +0100, Konrad Rzeszutek Wilk = wrote:<br> > On Wed, Sep 28, 2011 at 02:26:31PM +0100, Ian Jackson wrote:<br> > > Ian Campbell writes ("Re: [Xen-devel] Xen document day (Oct = 12 or 26)"):<br> > > > Since the guest APIs are stable there should be relatively l= ittle churn<br> > > > so perhaps a wiki page (or even series of pages) would be ap= propriate<br> > > > for this sort of thing?<br> > ><br> > > I want this to be in-tree. =A0If it's in-tree, we can refuse = patches<br> > > which do not update the documentation.<br> > ><br> > > > I think this would be good too and in fact even more importa= nt than the<br> > > > interface documentation. Everyone needs to be able to build = Xen to hack<br> > > > on it but only a subset need to know any particular API.<br> > > ><br> > > > Also although we recommend that users consume Xen via their = distro where<br> > > > possible such a guide would also help any who would rather b= uild from<br> > > > scratch (e.g. because we've asked them to "try the = latest version" or to<br> > > > bisect a bug etc).<br> > ><br> > > This would be a good candidate for a wiki page, backed up by revi= sions<br> > > of the in-tree README.<br> ><br> ><br> > Any recommendations on what would be a good format to write these &quo= t;interface"<br> > pages in?<br> <br> </div>For in-line (i.e. in xen/include/public/*.h) docs of APIs I played a<= br> little bit with integrating kernel-doc into the Xen build system but it<br> is tied a little too closely to the kernel build infrastructure.<br> <br> Doxygen seems like a plausible alternative with life outside the kernel<br> etc. We actually appear to already have some doxygen stuff for the<br> pytyhon stuff (judging from the Makefile, I've not actually noticed the= <br> structured code comments anywhere)<br> <br> For non-inline docs I think we decided that markdown would be a good<br> answer.<br> <font color=3D"#888888"><br> Ian.<br> </font><div><div></div><div class=3D"h5"><br> <br> _______________________________________________<br> Xen-devel mailing list<br> <a href=3D"mailto:Xen-devel@lists.xensource.com">Xen-devel@lists.xensource.= com</a><br> <a href=3D"http://lists.xensource.com/xen-devel" target=3D"_blank">http://l= ists.xensource.com/xen-devel</a><br> </div></div></blockquote></div><br><br clear=3D"all"><br>-- <br><span style= =3D"font-family:arial,sans-serif;font-size:13px;border-collapse:collapse"><= b><i><font color=3D"#0000ff"><div><font color=3D"#000000"><span style=3D"fo= nt-style:normal;font-weight:normal">Founder | Director | VP Research<br> </span></font></div>Orion Virtualisation Solutions</font></i></b>=A0|=A0<fo= nt color=3D"#0000ff"><a href=3D"http://www.orionvm.com.au/" style=3D"color:= rgb(42, 93, 176)" target=3D"_blank">www.orionvm.com.au</a></font>=A0| Phone= : 1300 56 99 52 | Mobile: 0428 754 846</span><br> --00151773e028c0e3b204ae12527d-- --===============0765242288== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel --===============0765242288==-- From xen-devel-bounces@lists.xensource.com Thu Sep 29 03:57:52 2011 Return-path: <xen-devel-bounces@lists.xensource.com> Envelope-to: www-data@lists.xensource.com Delivery-date: Thu, 29 Sep 2011 03:57:52 -0700 Received: from localhost ([127.0.0.1] helo=lists.colo.xensource.com) by lists.xensource.com with esmtp (Exim 4.43) id 1R9EJL-0000lW-VE; Thu, 29 Sep 2011 03:57:51 -0700 Received: from mail174.messagelabs.com ([85.158.138.51]) by lists.xensource.com with esmtp (Exim 4.43) id 1R9EIQ-0000Xl-K9 for xen-devel@lists.xensource.com; Thu, 29 Sep 2011 03:56:54 -0700 X-Env-Sender: Stefano.Stabellini@eu.citrix.com X-Msg-Ref: server-8.tower-174.messagelabs.com!1317293810!19527592!1 X-Originating-IP: [62.200.22.115] X-StarScan-Version: 6.4.1; banners=-,-,- X-VirusChecked: Checked Received: (qmail 19537 invoked from network); 29 Sep 2011 10:56:51 -0000 Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115) by server-8.tower-174.messagelabs.com with RC4-SHA encrypted SMTP; 29 Sep 2011 10:56:51 -0000 X-IronPort-AV: E=Sophos;i="4.68,460,1312156800"; d="scan'208";a="8124449" Received: from lonpmailmx01.citrite.net ([10.30.203.162]) by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5; 29 Sep 2011 10:56:41 +0000 Received: from kaball.uk.xensource.com (10.80.2.59) by LONPMAILMX01.citrite.net (10.30.203.162) with Microsoft SMTP Server id 8.3.137.0; Thu, 29 Sep 2011 11:56:41 +0100 Date: Thu, 29 Sep 2011 11:56:27 +0100 From: Stefano Stabellini <Stefano.Stabellini@eu.citrix.com> X-X-Sender: sstabellini@kaball-desktop To: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com> Message-ID: <alpine.DEB.2.00.1109291148340.3519@kaball-desktop> User-Agent: Alpine 2.00 (DEB 1167 2008-08-23) MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Cc: Ian Campbell <Ian.Campbell@eu.citrix.com>, Jeremy Fitzhardinge <jeremy@goop.org>, "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>, "linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>, Stefano Stabellini <Stefano.Stabellini@eu.citrix.com> Subject: [Xen-devel] [PATCH v5 0/2] xen: modify kernel mappings corresponding to granted pages X-BeenThere: xen-devel@lists.xensource.com X-Mailman-Version: 2.1.5 Precedence: list List-Id: Xen developer discussion <xen-devel.lists.xensource.com> List-Unsubscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe> List-Post: <mailto:xen-devel@lists.xensource.com> List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help> List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=subscribe> Sender: xen-devel-bounces@lists.xensource.com Errors-To: xen-devel-bounces@lists.xensource.com Hi all, this is the fifth version of the patch "xen: modify kernel mappings corresponding to granted pages": changes to v4: - add many more comments to the code; - fix some code style issues; - use set_page_private/page_private macros; - compare with GNTST_general_error rather than -1; - BUG in case map->pages are highmem; Changes to v3: - move the xen_mc_entry call in m2p_remove_override after the xen_mc_flush call; - use false rather than 0 as a parameter to alloc_xenballooned_pages; - update the m2p_add_override call in blkback.c, following the new interface; - fix few code style issues. Changes to v2: - drop highmem support; - fold the multicall patch into the main patch; - add another patch to extend the alloc_xenballooned_pages interface with an highmem parameter that allows the caller to explicitly request for highmem or lowmem pages; - modify gntdev to use lowmem pages only thanks to the new alloc_xenballooned_pages interface. Shortlog and diffstat follow: Stefano Stabellini (2): xen: add an "highmem" parameter to alloc_xenballooned_pages xen: modify kernel mappings corresponding to granted pages arch/x86/include/asm/xen/page.h | 5 ++- arch/x86/xen/p2m.c | 79 ++++++++++++++++++++++++++++++----- drivers/block/xen-blkback/blkback.c | 2 +- drivers/xen/balloon.c | 12 ++++-- drivers/xen/gntdev.c | 34 ++++++++++++++- drivers/xen/grant-table.c | 6 +- include/xen/balloon.h | 5 +- include/xen/grant_table.h | 1 + 8 files changed, 120 insertions(+), 24 deletions(-) A git branch with the two patches on top of Konrad's "Xen MMU fixes for 3.2" patch series (1316831299-4144-1-git-send-email-konrad.wilk@oracle.com) on top of Linux 3.1 rc4 is available here: git://xenbits.xen.org/people/sstabellini/linux-pvhvm.git 3.1-rc4-kernel_mappings_5 Cheers, Stefano _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel From xen-devel-bounces@lists.xensource.com Thu Sep 29 04:01:49 2011 Return-path: <xen-devel-bounces@lists.xensource.com> Envelope-to: www-data@lists.xensource.com Delivery-date: Thu, 29 Sep 2011 04:01:49 -0700 Received: from localhost ([127.0.0.1] helo=lists.colo.xensource.com) by lists.xensource.com with esmtp (Exim 4.43) id 1R9ENA-0001B8-Ot; Thu, 29 Sep 2011 04:01:49 -0700 Received: from mail174.messagelabs.com ([85.158.138.51]) by lists.xensource.com with esmtp (Exim 4.43) id 1R9EJl-0000pq-Ra for xen-devel@lists.xensource.com; Thu, 29 Sep 2011 03:58:19 -0700 X-Env-Sender: Stefano.Stabellini@eu.citrix.com X-Msg-Ref: server-9.tower-174.messagelabs.com!1317293892!27181057!1 X-Originating-IP: [66.165.176.63] X-StarScan-Version: 6.4.1; banners=-,-,- X-VirusChecked: Checked Received: (qmail 16635 invoked from network); 29 Sep 2011 10:58:14 -0000 Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63) by server-9.tower-174.messagelabs.com with RC4-SHA encrypted SMTP; 29 Sep 2011 10:58:14 -0000 X-IronPort-AV: E=Sophos;i="4.68,460,1312171200"; d="scan'208";a="165107804" Received: from ftlpmailmx01.citrite.net ([10.13.107.65]) by FTLPIPO02.CITRIX.COM with ESMTP/TLS/RC4-MD5; 29 Sep 2011 06:58:12 -0400 Received: from smtp01.ad.xensource.com (10.219.128.104) by smtprelay.citrix.com (10.13.107.65) with Microsoft SMTP Server id 8.3.137.0; Thu, 29 Sep 2011 06:58:12 -0400 Received: from localhost.localdomain (kaball.uk.xensource.com [10.80.2.59]) by smtp01.ad.xensource.com (8.13.1/8.13.1) with ESMTP id p8TAvuJT024993; Thu, 29 Sep 2011 03:58:00 -0700 From: <stefano.stabellini@eu.citrix.com> To: konrad.wilk@oracle.com Date: Thu, 29 Sep 2011 11:57:56 +0100 Message-ID: <1317293876-23891-2-git-send-email-stefano.stabellini@eu.citrix.com> X-Mailer: git-send-email 1.7.0.4 In-Reply-To: <alpine.DEB.2.00.1109291148340.3519@kaball-desktop> References: <alpine.DEB.2.00.1109291148340.3519@kaball-desktop> MIME-Version: 1.0 Content-Type: text/plain Cc: jeremy@goop.org, xen-devel@lists.xensource.com, linux-kernel@vger.kernel.org, Stefano Stabellini <stefano.stabellini@eu.citrix.com>, Stefano.Stabellini@eu.citrix.com Subject: [Xen-devel] [PATCH v5 2/2] xen: modify kernel mappings corresponding to granted pages X-BeenThere: xen-devel@lists.xensource.com X-Mailman-Version: 2.1.5 Precedence: list List-Id: Xen developer discussion <xen-devel.lists.xensource.com> List-Unsubscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe> List-Post: <mailto:xen-devel@lists.xensource.com> List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help> List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=subscribe> Sender: xen-devel-bounces@lists.xensource.com Errors-To: xen-devel-bounces@lists.xensource.com From: Stefano Stabellini <stefano.stabellini@eu.citrix.com> If we want to use granted pages for AIO, changing the mappings of a user vma and the corresponding p2m is not enough, we also need to update the kernel mappings accordingly. Currently this is only needed for pages that are created for user usages through /dev/xen/gntdev. As in, pages that have been in use by the kernel and use the P2M will not need this special mapping. However there are no guarantees that in the future the kernel won't start accessing pages through the 1:1 even for internal usage. In order to avoid the complexity of dealing with highmem, we allocated the pages lowmem. We issue a HYPERVISOR_grant_table_op right away in m2p_add_override and we remove the mappings using another HYPERVISOR_grant_table_op in m2p_remove_override. Considering that m2p_add_override and m2p_remove_override are called once per page we use multicalls and hypercall batching. Use the kmap_op pointer directly as argument to do the mapping as it is guaranteed to be present up until the unmapping is done. Before issuing any unmapping multicalls, we need to make sure that the mapping has already being done, because we need the kmap->handle to be set correctly. Signed-off-by: Stefano Stabellini <stefano.stabellini@eu.citrix.com> --- arch/x86/include/asm/xen/page.h | 5 ++- arch/x86/xen/p2m.c | 79 ++++++++++++++++++++++++++++++----- drivers/block/xen-blkback/blkback.c | 2 +- drivers/xen/gntdev.c | 32 ++++++++++++++- drivers/xen/grant-table.c | 6 +- include/xen/grant_table.h | 1 + 6 files changed, 108 insertions(+), 17 deletions(-) diff --git a/arch/x86/include/asm/xen/page.h b/arch/x86/include/asm/xen/page.h index e1dc8e6..37d3185 100644 --- a/arch/x86/include/asm/xen/page.h +++ b/arch/x86/include/asm/xen/page.h @@ -12,6 +12,7 @@ #include <asm/pgtable.h> #include <xen/interface/xen.h> +#include <xen/grant_table.h> #include <xen/features.h> /* Xen machine address */ @@ -31,8 +32,10 @@ typedef struct xpaddr { #define INVALID_P2M_ENTRY (~0UL) #define FOREIGN_FRAME_BIT (1UL<<(BITS_PER_LONG-1)) #define IDENTITY_FRAME_BIT (1UL<<(BITS_PER_LONG-2)) +#define GRANT_FRAME_BIT (1UL<<(BITS_PER_LONG-3)) #define FOREIGN_FRAME(m) ((m) | FOREIGN_FRAME_BIT) #define IDENTITY_FRAME(m) ((m) | IDENTITY_FRAME_BIT) +#define GRANT_FRAME(m) ((m) | GRANT_FRAME_BIT) /* Maximum amount of memory we can handle in a domain in pages */ #define MAX_DOMAIN_PAGES \ @@ -48,7 +51,7 @@ extern unsigned long set_phys_range_identity(unsigned long pfn_s, unsigned long pfn_e); extern int m2p_add_override(unsigned long mfn, struct page *page, - bool clear_pte); + struct gnttab_map_grant_ref *kmap_op); extern int m2p_remove_override(struct page *page, bool clear_pte); extern struct page *m2p_find_override(unsigned long mfn); extern unsigned long m2p_find_override_pfn(unsigned long mfn, unsigned long pfn); diff --git a/arch/x86/xen/p2m.c b/arch/x86/xen/p2m.c index 6e56b65..5857ef0 100644 --- a/arch/x86/xen/p2m.c +++ b/arch/x86/xen/p2m.c @@ -161,7 +161,9 @@ #include <asm/xen/page.h> #include <asm/xen/hypercall.h> #include <asm/xen/hypervisor.h> +#include <xen/grant_table.h> +#include "multicalls.h" #include "xen-ops.h" static void __init m2p_override_init(void); @@ -676,7 +678,8 @@ static unsigned long mfn_hash(unsigned long mfn) } /* Add an MFN override for a particular page */ -int m2p_add_override(unsigned long mfn, struct page *page, bool clear_pte) +int m2p_add_override(unsigned long mfn, struct page *page, + struct gnttab_map_grant_ref *kmap_op) { unsigned long flags; unsigned long pfn; @@ -700,9 +703,21 @@ int m2p_add_override(unsigned long mfn, struct page *page, bool clear_pte) if (unlikely(!set_phys_to_machine(pfn, FOREIGN_FRAME(mfn)))) return -ENOMEM; - if (clear_pte && !PageHighMem(page)) - /* Just zap old mapping for now */ - pte_clear(&init_mm, address, ptep); + if (kmap_op != NULL) { + if (!PageHighMem(page)) { + struct multicall_space mcs = + xen_mc_entry(sizeof(*kmap_op)); + + MULTI_grant_table_op(mcs.mc, + GNTTABOP_map_grant_ref, kmap_op, 1); + + xen_mc_issue(PARAVIRT_LAZY_MMU); + } + set_page_private(page, page_private(page) | GRANT_FRAME_BIT); + /* let's use dev_bus_addr to record the old mfn instead */ + kmap_op->dev_bus_addr = page->index; + page->index = (unsigned long) kmap_op; + } spin_lock_irqsave(&m2p_override_lock, flags); list_add(&page->lru, &m2p_overrides[mfn_hash(mfn)]); spin_unlock_irqrestore(&m2p_override_lock, flags); @@ -736,14 +751,56 @@ int m2p_remove_override(struct page *page, bool clear_pte) spin_lock_irqsave(&m2p_override_lock, flags); list_del(&page->lru); spin_unlock_irqrestore(&m2p_override_lock, flags); - set_phys_to_machine(pfn, page->index); WARN_ON(!PagePrivate(page)); ClearPagePrivate(page); - if (clear_pte && !PageHighMem(page)) - set_pte_at(&init_mm, address, ptep, - pfn_pte(pfn, PAGE_KERNEL)); - /* No tlb flush necessary because the caller already - * left the pte unmapped. */ + + if (clear_pte) { + struct gnttab_map_grant_ref *map_op = + (struct gnttab_map_grant_ref *) page->index; + set_phys_to_machine(pfn, map_op->dev_bus_addr); + if (!PageHighMem(page)) { + struct multicall_space mcs; + struct gnttab_unmap_grant_ref *unmap_op; + + /* + * It might be that we queued all the m2p grant table + * hypercalls in a multicall, then m2p_remove_override + * get called before the multicall has actually been + * issued. In this case handle is going to -1 because + * it hasn't been modified yet. + */ + if (map_op->handle == -1) + xen_mc_flush(); + /* + * Now if map_op->handle is negative it means that the + * hypercall actually returned an error. + */ + if (map_op->handle == GNTST_general_error) { + printk(KERN_WARNING "m2p_remove_override: " + "pfn %lx mfn %lx, failed to modify kernel mappings", + pfn, mfn); + return -1; + } + + mcs = xen_mc_entry( + sizeof(struct gnttab_unmap_grant_ref)); + unmap_op = mcs.args; + unmap_op->host_addr = map_op->host_addr; + unmap_op->handle = map_op->handle; + unmap_op->dev_bus_addr = 0; + + MULTI_grant_table_op(mcs.mc, + GNTTABOP_unmap_grant_ref, unmap_op, 1); + + xen_mc_issue(PARAVIRT_LAZY_MMU); + + set_pte_at(&init_mm, address, ptep, + pfn_pte(pfn, PAGE_KERNEL)); + __flush_tlb_single(address); + map_op->host_addr = 0; + } + } else + set_phys_to_machine(pfn, page->index); return 0; } @@ -760,7 +817,7 @@ struct page *m2p_find_override(unsigned long mfn) spin_lock_irqsave(&m2p_override_lock, flags); list_for_each_entry(p, bucket, lru) { - if (page_private(p) == mfn) { + if ((page_private(p) & (~GRANT_FRAME_BIT)) == mfn) { ret = p; break; } diff --git a/drivers/block/xen-blkback/blkback.c b/drivers/block/xen-blkback/blkback.c index 2330a9a..1540792 100644 --- a/drivers/block/xen-blkback/blkback.c +++ b/drivers/block/xen-blkback/blkback.c @@ -396,7 +396,7 @@ static int xen_blkbk_map(struct blkif_request *req, continue; ret = m2p_add_override(PFN_DOWN(map[i].dev_bus_addr), - blkbk->pending_page(pending_req, i), false); + blkbk->pending_page(pending_req, i), NULL); if (ret) { pr_alert(DRV_PFX "Failed to install M2P override for %lx (ret: %d)\n", (unsigned long)map[i].dev_bus_addr, ret); diff --git a/drivers/xen/gntdev.c b/drivers/xen/gntdev.c index 7b9b1d1..3e3603f 100644 --- a/drivers/xen/gntdev.c +++ b/drivers/xen/gntdev.c @@ -83,6 +83,7 @@ struct grant_map { struct ioctl_gntdev_grant_ref *grants; struct gnttab_map_grant_ref *map_ops; struct gnttab_unmap_grant_ref *unmap_ops; + struct gnttab_map_grant_ref *kmap_ops; struct page **pages; }; @@ -116,10 +117,12 @@ static struct grant_map *gntdev_alloc_map(struct gntdev_priv *priv, int count) add->grants = kzalloc(sizeof(add->grants[0]) * count, GFP_KERNEL); add->map_ops = kzalloc(sizeof(add->map_ops[0]) * count, GFP_KERNEL); add->unmap_ops = kzalloc(sizeof(add->unmap_ops[0]) * count, GFP_KERNEL); + add->kmap_ops = kzalloc(sizeof(add->kmap_ops[0]) * count, GFP_KERNEL); add->pages = kzalloc(sizeof(add->pages[0]) * count, GFP_KERNEL); if (NULL == add->grants || NULL == add->map_ops || NULL == add->unmap_ops || + NULL == add->kmap_ops || NULL == add->pages) goto err; @@ -129,6 +132,7 @@ static struct grant_map *gntdev_alloc_map(struct gntdev_priv *priv, int count) for (i = 0; i < count; i++) { add->map_ops[i].handle = -1; add->unmap_ops[i].handle = -1; + add->kmap_ops[i].handle = -1; } add->index = 0; @@ -142,6 +146,7 @@ err: kfree(add->grants); kfree(add->map_ops); kfree(add->unmap_ops); + kfree(add->kmap_ops); kfree(add); return NULL; } @@ -243,10 +248,35 @@ static int map_grant_pages(struct grant_map *map) gnttab_set_unmap_op(&map->unmap_ops[i], addr, map->flags, -1 /* handle */); } + } else { + /* + * Setup the map_ops corresponding to the pte entries pointing + * to the kernel linear addresses of the struct pages. + * These ptes are completely different from the user ptes dealt + * with find_grant_ptes. + */ + for (i = 0; i < map->count; i++) { + unsigned level; + unsigned long address = (unsigned long) + pfn_to_kaddr(page_to_pfn(map->pages[i])); + pte_t *ptep; + u64 pte_maddr = 0; + BUG_ON(PageHighMem(map->pages[i])); + + ptep = lookup_address(address, &level); + pte_maddr = arbitrary_virt_to_machine(ptep).maddr; + gnttab_set_map_op(&map->kmap_ops[i], pte_maddr, + map->flags | + GNTMAP_host_map | + GNTMAP_contains_pte, + map->grants[i].ref, + map->grants[i].domid); + } } pr_debug("map %d+%d\n", map->index, map->count); - err = gnttab_map_refs(map->map_ops, map->pages, map->count); + err = gnttab_map_refs(map->map_ops, use_ptemod ? map->kmap_ops : NULL, + map->pages, map->count); if (err) return err; diff --git a/drivers/xen/grant-table.c b/drivers/xen/grant-table.c index 4f44b34..8c71ab8 100644 --- a/drivers/xen/grant-table.c +++ b/drivers/xen/grant-table.c @@ -448,7 +448,8 @@ unsigned int gnttab_max_grant_frames(void) EXPORT_SYMBOL_GPL(gnttab_max_grant_frames); int gnttab_map_refs(struct gnttab_map_grant_ref *map_ops, - struct page **pages, unsigned int count) + struct gnttab_map_grant_ref *kmap_ops, + struct page **pages, unsigned int count) { int i, ret; pte_t *pte; @@ -488,8 +489,7 @@ int gnttab_map_refs(struct gnttab_map_grant_ref *map_ops, */ return -EOPNOTSUPP; } - ret = m2p_add_override(mfn, pages[i], - map_ops[i].flags & GNTMAP_contains_pte); + ret = m2p_add_override(mfn, pages[i], &kmap_ops[i]); if (ret) return ret; } diff --git a/include/xen/grant_table.h b/include/xen/grant_table.h index b1fab6b..6b99bfb 100644 --- a/include/xen/grant_table.h +++ b/include/xen/grant_table.h @@ -156,6 +156,7 @@ unsigned int gnttab_max_grant_frames(void); #define gnttab_map_vaddr(map) ((void *)(map.host_virt_addr)) int gnttab_map_refs(struct gnttab_map_grant_ref *map_ops, + struct gnttab_map_grant_ref *kmap_ops, struct page **pages, unsigned int count); int gnttab_unmap_refs(struct gnttab_unmap_grant_ref *unmap_ops, struct page **pages, unsigned int count); -- 1.7.2.3 _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel From xen-devel-bounces@lists.xensource.com Thu Sep 29 04:04:53 2011 Return-path: <xen-devel-bounces@lists.xensource.com> Envelope-to: www-data@lists.xensource.com Delivery-date: Thu, 29 Sep 2011 04:04:53 -0700 Received: from localhost ([127.0.0.1] helo=lists.colo.xensource.com) by lists.xensource.com with esmtp (Exim 4.43) id 1R9EQ8-0001bj-Dw; Thu, 29 Sep 2011 04:04:52 -0700 Received: from mail182.messagelabs.com ([85.158.139.83]) by lists.xensource.com with esmtp (Exim 4.43) id 1R9EK1-0000rZ-J0 for xen-devel@lists.xensource.com; Thu, 29 Sep 2011 03:58:34 -0700 X-Env-Sender: Stefano.Stabellini@eu.citrix.com X-Msg-Ref: server-2.tower-182.messagelabs.com!1317293908!17403292!1 X-Originating-IP: [66.165.176.89] X-StarScan-Version: 6.4.1; banners=-,-,- X-VirusChecked: Checked Received: (qmail 18000 invoked from network); 29 Sep 2011 10:58:30 -0000 Received: from smtp.citrix.com (HELO SMTP.CITRIX.COM) (66.165.176.89) by server-2.tower-182.messagelabs.com with RC4-SHA encrypted SMTP; 29 Sep 2011 10:58:30 -0000 X-IronPort-AV: E=Sophos;i="4.68,460,1312171200"; d="scan'208";a="17802069" Received: from ftlpmailmx01.citrite.net ([10.13.107.65]) by FTLPIPO01.CITRIX.COM with ESMTP/TLS/RC4-MD5; 29 Sep 2011 06:58:05 -0400 Received: from smtp01.ad.xensource.com (10.219.128.104) by smtprelay.citrix.com (10.13.107.65) with Microsoft SMTP Server id 8.3.137.0; Thu, 29 Sep 2011 06:58:05 -0400 Received: from localhost.localdomain (kaball.uk.xensource.com [10.80.2.59]) by smtp01.ad.xensource.com (8.13.1/8.13.1) with ESMTP id p8TAvuJS024993; Thu, 29 Sep 2011 03:57:57 -0700 From: <stefano.stabellini@eu.citrix.com> To: konrad.wilk@oracle.com Date: Thu, 29 Sep 2011 11:57:55 +0100 Message-ID: <1317293876-23891-1-git-send-email-stefano.stabellini@eu.citrix.com> X-Mailer: git-send-email 1.7.0.4 In-Reply-To: <alpine.DEB.2.00.1109291148340.3519@kaball-desktop> References: <alpine.DEB.2.00.1109291148340.3519@kaball-desktop> MIME-Version: 1.0 Content-Type: text/plain Cc: jeremy@goop.org, xen-devel@lists.xensource.com, linux-kernel@vger.kernel.org, Stefano Stabellini <stefano.stabellini@eu.citrix.com>, Stefano.Stabellini@eu.citrix.com Subject: [Xen-devel] [PATCH v5 1/2] xen: add an "highmem" parameter to alloc_xenballooned_pages X-BeenThere: xen-devel@lists.xensource.com X-Mailman-Version: 2.1.5 Precedence: list List-Id: Xen developer discussion <xen-devel.lists.xensource.com> List-Unsubscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe> List-Post: <mailto:xen-devel@lists.xensource.com> List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help> List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=subscribe> Sender: xen-devel-bounces@lists.xensource.com Errors-To: xen-devel-bounces@lists.xensource.com From: Stefano Stabellini <stefano.stabellini@eu.citrix.com> Add an highmem parameter to alloc_xenballooned_pages, to allow callers to request lowmem or highmem pages. Fix the code style of free_xenballooned_pages' prototype. Signed-off-by: Stefano Stabellini <stefano.stabellini@eu.citrix.com> --- drivers/xen/balloon.c | 12 ++++++++---- drivers/xen/gntdev.c | 2 +- include/xen/balloon.h | 5 +++-- 3 files changed, 12 insertions(+), 7 deletions(-) diff --git a/drivers/xen/balloon.c b/drivers/xen/balloon.c index 5dfd8f8..cd8b470 100644 --- a/drivers/xen/balloon.c +++ b/drivers/xen/balloon.c @@ -501,20 +501,24 @@ EXPORT_SYMBOL_GPL(balloon_set_new_target); * alloc_xenballooned_pages - get pages that have been ballooned out * @nr_pages: Number of pages to get * @pages: pages returned + * @highmem: highmem or lowmem pages * @return 0 on success, error otherwise */ -int alloc_xenballooned_pages(int nr_pages, struct page** pages) +int alloc_xenballooned_pages(int nr_pages, struct page **pages, bool highmem) { int pgno = 0; struct page* page; mutex_lock(&balloon_mutex); while (pgno < nr_pages) { - page = balloon_retrieve(true); - if (page) { + page = balloon_retrieve(highmem); + if (page && PageHighMem(page) == highmem) { pages[pgno++] = page; } else { enum bp_state st; - st = decrease_reservation(nr_pages - pgno, GFP_HIGHUSER); + if (page) + balloon_append(page); + st = decrease_reservation(nr_pages - pgno, + highmem ? GFP_HIGHUSER : GFP_USER); if (st != BP_DONE) goto out_undo; } diff --git a/drivers/xen/gntdev.c b/drivers/xen/gntdev.c index f914b26..7b9b1d1 100644 --- a/drivers/xen/gntdev.c +++ b/drivers/xen/gntdev.c @@ -123,7 +123,7 @@ static struct grant_map *gntdev_alloc_map(struct gntdev_priv *priv, int count) NULL == add->pages) goto err; - if (alloc_xenballooned_pages(count, add->pages)) + if (alloc_xenballooned_pages(count, add->pages, false /* lowmem */)) goto err; for (i = 0; i < count; i++) { diff --git a/include/xen/balloon.h b/include/xen/balloon.h index 76f7538..d29c153 100644 --- a/include/xen/balloon.h +++ b/include/xen/balloon.h @@ -25,8 +25,9 @@ extern struct balloon_stats balloon_stats; void balloon_set_new_target(unsigned long target); -int alloc_xenballooned_pages(int nr_pages, struct page** pages); -void free_xenballooned_pages(int nr_pages, struct page** pages); +int alloc_xenballooned_pages(int nr_pages, struct page **pages, + bool highmem); +void free_xenballooned_pages(int nr_pages, struct page **pages); struct sys_device; #ifdef CONFIG_XEN_SELFBALLOONING -- 1.7.2.3 _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel From xen-devel-bounces@lists.xensource.com Thu Sep 29 04:08:03 2011 Return-path: <xen-devel-bounces@lists.xensource.com> Envelope-to: www-data@lists.xensource.com Delivery-date: Thu, 29 Sep 2011 04:08:03 -0700 Received: from localhost ([127.0.0.1] helo=lists.colo.xensource.com) by lists.xensource.com with esmtp (Exim 4.43) id 1R9ETB-00024h-Ot; Thu, 29 Sep 2011 04:08:01 -0700 Received: from mail27.messagelabs.com ([193.109.254.147]) by lists.xensource.com with esmtp (Exim 4.43) id 1R9ENA-0001Af-1C for xen-devel@lists.xensource.com; Thu, 29 Sep 2011 04:02:05 -0700 X-Env-Sender: Ian.Campbell@eu.citrix.com X-Msg-Ref: server-12.tower-27.messagelabs.com!1317294088!44422852!1 X-Originating-IP: [62.200.22.115] X-StarScan-Version: 6.4.1; banners=-,-,- X-VirusChecked: Checked Received: (qmail 20699 invoked from network); 29 Sep 2011 11:01:28 -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; 29 Sep 2011 11:01:28 -0000 X-IronPort-AV: E=Sophos;i="4.68,460,1312156800"; d="scan'208";a="8124571" Received: from lonpmailmx01.citrite.net ([10.30.203.162]) by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5; 29 Sep 2011 11:01:44 +0000 Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net (10.30.203.162) with Microsoft SMTP Server id 8.3.137.0; Thu, 29 Sep 2011 12:01:44 +0100 Subject: Re: [Xen-devel] Xen document day (Oct 12 or 26) From: Ian Campbell <Ian.Campbell@eu.citrix.com> To: Joseph Glanville <joseph.glanville@orionvm.com.au> Date: Thu, 29 Sep 2011 12:01:44 +0100 In-Reply-To: <CAOzFzEhnr7Ri42V1AUMLw-xRn+9NQwu8Pkq8iPc=pS12w=Vnog@mail.gmail.com> References: <20110922130618.GA13238@phenom.oracle.com> <CAFLBxZaAaXTUtW5+VkxPnr_MR0fbW+d1Mzu4y0x=gEOaX9e0OQ@mail.gmail.com> <20110922174002.GA1205@phenom.oracle.com> <20098.1097.824552.541924@mariner.uk.xensource.com> <CAP2B85-=CbMgUGSwO2utvkeLLqk8A1vjhKrPwe2OD+0daAtqsA@mail.gmail.com> <1317195656.13424.73.camel@dagon.hellion.org.uk> <20099.8327.326129.357335@mariner.uk.xensource.com> <20110928134800.GH10270@phenom.oracle.com> <1317218459.26672.62.camel@zakaz.uk.xensource.com> <CAOzFzEhnr7Ri42V1AUMLw-xRn+9NQwu8Pkq8iPc=pS12w=Vnog@mail.gmail.com> Organization: Citrix Systems, Inc. Content-Type: text/plain; charset="UTF-8" X-Mailer: Evolution 3.0.3- Content-Transfer-Encoding: 7bit Message-ID: <1317294104.26672.155.camel@zakaz.uk.xensource.com> MIME-Version: 1.0 Cc: Daniel Castro <evil.dani@gmail.com>, "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>, Ian Jackson <Ian.Jackson@eu.citrix.com>, Konrad Rzeszutek Wilk <konrad.wilk@oracle.com> X-BeenThere: xen-devel@lists.xensource.com X-Mailman-Version: 2.1.5 Precedence: list List-Id: Xen developer discussion <xen-devel.lists.xensource.com> List-Unsubscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe> List-Post: <mailto:xen-devel@lists.xensource.com> List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help> List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=subscribe> Sender: xen-devel-bounces@lists.xensource.com Errors-To: xen-devel-bounces@lists.xensource.com On Thu, 2011-09-29 at 11:53 +0100, Joseph Glanville wrote: > +1 for Markdown. > > In terms of making Xen more accessible I think it might be a good idea > to update/cleanup the distro support page. > http://wiki.xen.org/xenwiki/DistributionSupport > > I can probably do this. Excellent, it looks like it needs it... > Making it simple for people to get started with Xen on a distro they > are comfortable with is a good step forward. Agreed. In fact for many users this is probably the end goal, not just a step along the way. > I know distro specific guides could turn into a nightmare but I am > open to writing one for Debian 6 Squeeze, In cases such as this we should also consider updating the distro's wiki page. I'm not sure where the canonical guide should live (wiki.xen.org or wiki.debian.org) but they should certainly cross reference each other. > there are also a few that exist already for RHEL/CentOS on the wiki. > This should get easier as more distros update to 3.0+ kernels that > support PVops out of the box... > > Next would be networking documentation as network-bridge script has > been deprecated. > http://wiki.xensource.com/xenwiki/XenNetworking > Once again I think alot of the documentation is going to be distro > specific to be newbie friendly but atleast a simple ip/brctl guide > would help. > > IMO knowing where to start and setting up networking were the biggest > barriers when I was picking up Xen a few years back. We now have http://wiki.xensource.com/xenwiki/HostConfiguration/Networking which could do with being made more discoverable. There is also http://wiki.xensource.com/xenwiki/HostConfiguration but its looking pretty sad right now... > > I am also open to updating the blktap2 pages and README to reflect the > new tap-ctl userspace utilities and tips on driver development. > > <slightly off-topic but related> > > With jailtime.org(stacklet) now charging for subscription there is > nowhere to download pre-built clean Xen compatible images free of > charge etc. > I have pvgrub/pygrub capable images of Ubuntu/Debian/CentOS that I am > considering hosting for free. > Generally new users are confused on how to build new paravirt VMs, I > think prebuilt images are suboptimal but a good place to start for > beginners. There was discussion of Debian providing such a thing on debian-deval back in late July, I should chase that up really. Cheers, Ian. > > Joseph. > > On 29 September 2011 00:00, Ian Campbell <Ian.Campbell@eu.citrix.com> > wrote: > On Wed, 2011-09-28 at 14:48 +0100, Konrad Rzeszutek Wilk > wrote: > > On Wed, Sep 28, 2011 at 02:26:31PM +0100, Ian Jackson wrote: > > > Ian Campbell writes ("Re: [Xen-devel] Xen document day > (Oct 12 or 26)"): > > > > Since the guest APIs are stable there should be > relatively little churn > > > > so perhaps a wiki page (or even series of pages) would > be appropriate > > > > for this sort of thing? > > > > > > I want this to be in-tree. If it's in-tree, we can refuse > patches > > > which do not update the documentation. > > > > > > > I think this would be good too and in fact even more > important than the > > > > interface documentation. Everyone needs to be able to > build Xen to hack > > > > on it but only a subset need to know any particular API. > > > > > > > > Also although we recommend that users consume Xen via > their distro where > > > > possible such a guide would also help any who would > rather build from > > > > scratch (e.g. because we've asked them to "try the > latest version" or to > > > > bisect a bug etc). > > > > > > This would be a good candidate for a wiki page, backed up > by revisions > > > of the in-tree README. > > > > > > Any recommendations on what would be a good format to write > these "interface" > > pages in? > > > For in-line (i.e. in xen/include/public/*.h) docs of APIs I > played a > little bit with integrating kernel-doc into the Xen build > system but it > is tied a little too closely to the kernel build > infrastructure. > > Doxygen seems like a plausible alternative with life outside > the kernel > etc. We actually appear to already have some doxygen stuff for > the > pytyhon stuff (judging from the Makefile, I've not actually > noticed the > structured code comments anywhere) > > For non-inline docs I think we decided that markdown would be > a good > answer. > > Ian. > > > > _______________________________________________ > Xen-devel mailing list > Xen-devel@lists.xensource.com > http://lists.xensource.com/xen-devel > > > > > -- > Founder | Director | VP Research > > Orion Virtualisation Solutions | www.orionvm.com.au | Phone: 1300 56 > 99 52 | Mobile: 0428 754 846 _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel From xen-devel-bounces@lists.xensource.com Thu Sep 29 04:10:18 2011 Return-path: <xen-devel-bounces@lists.xensource.com> Envelope-to: www-data@lists.xensource.com Delivery-date: Thu, 29 Sep 2011 04:10:18 -0700 Received: from localhost ([127.0.0.1] helo=lists.colo.xensource.com) by lists.xensource.com with esmtp (Exim 4.43) id 1R9EVN-0002Sr-LB; Thu, 29 Sep 2011 04:10:17 -0700 Received: from mail21.messagelabs.com ([85.158.143.35]) by lists.xensource.com with esmtp (Exim 4.43) id 1R9ENH-0001Bf-N9 for xen-devel@lists.xensource.com; Thu, 29 Sep 2011 04:02:00 -0700 X-Env-Sender: Stefano.Stabellini@eu.citrix.com X-Msg-Ref: server-14.tower-21.messagelabs.com!1317294104!61441170!1 X-Originating-IP: [62.200.22.115] X-StarScan-Version: 6.4.1; banners=-,-,- X-VirusChecked: Checked Received: (qmail 16093 invoked from network); 29 Sep 2011 11:01:44 -0000 Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115) by server-14.tower-21.messagelabs.com with RC4-SHA encrypted SMTP; 29 Sep 2011 11:01:44 -0000 X-IronPort-AV: E=Sophos;i="4.68,460,1312156800"; d="scan'208";a="8124575" Received: from lonpmailmx01.citrite.net ([10.30.203.162]) by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5; 29 Sep 2011 11:01:52 +0000 Received: from kaball.uk.xensource.com (10.80.2.59) by LONPMAILMX01.citrite.net (10.30.203.162) with Microsoft SMTP Server id 8.3.137.0; Thu, 29 Sep 2011 12:01:52 +0100 Date: Thu, 29 Sep 2011 12:01:39 +0100 From: Stefano Stabellini <stefano.stabellini@eu.citrix.com> X-X-Sender: sstabellini@kaball-desktop To: Jeremy Fitzhardinge <jeremy@goop.org> In-Reply-To: <4E8206A8.2090606@goop.org> Message-ID: <alpine.DEB.2.00.1109291158420.3519@kaball-desktop> References: <1317143159-7235-1-git-send-email-stefano.stabellini@eu.citrix.com> <1317143159-7235-2-git-send-email-stefano.stabellini@eu.citrix.com> <4E8206A8.2090606@goop.org> User-Agent: Alpine 2.00 (DEB 1167 2008-08-23) MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Cc: Ian Campbell <Ian.Campbell@eu.citrix.com>, "konrad.wilk@oracle.com" <konrad.wilk@oracle.com>, "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>, Stefano Stabellini <Stefano.Stabellini@eu.citrix.com> Subject: [Xen-devel] Re: [PATCH 2/2] xen: remove XEN_PLATFORM_PCI config option X-BeenThere: xen-devel@lists.xensource.com X-Mailman-Version: 2.1.5 Precedence: list List-Id: Xen developer discussion <xen-devel.lists.xensource.com> List-Unsubscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe> List-Post: <mailto:xen-devel@lists.xensource.com> List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help> List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=subscribe> Sender: xen-devel-bounces@lists.xensource.com Errors-To: xen-devel-bounces@lists.xensource.com On Tue, 27 Sep 2011, Jeremy Fitzhardinge wrote: > > diff --git a/drivers/xen/Makefile b/drivers/xen/Makefile > > index 72bbb27..d8dc26a 100644 > > --- a/drivers/xen/Makefile > > +++ b/drivers/xen/Makefile > > @@ -14,7 +14,7 @@ obj-$(CONFIG_XEN_GNTDEV) += xen-gntdev.o > > obj-$(CONFIG_XEN_GRANT_DEV_ALLOC) += xen-gntalloc.o > > obj-$(CONFIG_XENFS) += xenfs/ > > obj-$(CONFIG_XEN_SYS_HYPERVISOR) += sys-hypervisor.o > > -obj-$(CONFIG_XEN_PLATFORM_PCI) += xen-platform-pci.o > > +obj-$(CONFIG_XEN_PVHVM) += xen-platform-pci.o > > May as well just say "platform-pci.o" and remove the > "xen-platform-pci-y := platform-pci.o" further down, since > its no longer externally visible. > good idea, I'll do that _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel From xen-devel-bounces@lists.xensource.com Thu Sep 29 04:12:34 2011 Return-path: <xen-devel-bounces@lists.xensource.com> Envelope-to: www-data@lists.xensource.com Delivery-date: Thu, 29 Sep 2011 04:12:34 -0700 Received: from localhost ([127.0.0.1] helo=lists.colo.xensource.com) by lists.xensource.com with esmtp (Exim 4.43) id 1R9EXa-0002vq-51; Thu, 29 Sep 2011 04:12:34 -0700 Received: from mail27.messagelabs.com ([193.109.254.147]) by lists.xensource.com with esmtp (Exim 4.43) id 1R9EOe-0001NG-FR for xen-devel@lists.xensource.com; Thu, 29 Sep 2011 04:03:24 -0700 X-Env-Sender: anthony.perard@gmail.com X-Msg-Ref: server-6.tower-27.messagelabs.com!1317294175!50972240!1 X-Originating-IP: [209.85.216.171] X-StarScan-Version: 6.4.1; banners=-,-,- X-VirusChecked: Checked Received: (qmail 22940 invoked from network); 29 Sep 2011 11:02:56 -0000 Received: from mail-qy0-f171.google.com (HELO mail-qy0-f171.google.com) (209.85.216.171) by server-6.tower-27.messagelabs.com with RC4-SHA encrypted SMTP; 29 Sep 2011 11:02:56 -0000 Received: by qyk29 with SMTP id 29so3795942qyk.9 for <xen-devel@lists.xensource.com>; Thu, 29 Sep 2011 04:03:16 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:sender:in-reply-to:references:from:date :x-google-sender-auth:message-id:subject:to:cc:content-type :content-transfer-encoding; bh=1cHMdfqQblz7MiPAHH98z4Ma+QwrSw/9vJNEwVIPAWY=; b=oIeuxdcs0sprQQ5DgrgFu7tq9nidvMJBcUmqstCkJYbrHBBAI/oXqbSthiImpbn908 wk8kuK77qnwNeYLAn6lndYH5+fM7zSPzwkepDrrNg+NeQwMY9Oh00DlCuAPwKi0sQKg+ rlzDuxPUQdCsJH8oKGABejxvR+5HZ6iCWXvSc= Received: by 10.224.190.197 with SMTP id dj5mr1445046qab.5.1317294196213; Thu, 29 Sep 2011 04:03:16 -0700 (PDT) MIME-Version: 1.0 Received: by 10.224.47.74 with HTTP; Thu, 29 Sep 2011 04:02:46 -0700 (PDT) In-Reply-To: <20099.17272.139799.560052@mariner.uk.xensource.com> References: <1316609997-26002-1-git-send-email-anthony.perard@citrix.com> <20099.17272.139799.560052@mariner.uk.xensource.com> From: Anthony PERARD <anthony.perard@citrix.com> Date: Thu, 29 Sep 2011 12:02:46 +0100 X-Google-Sender-Auth: Pc-gYQ2AkTsF3x3C1bcBZGvT3YI Message-ID: <CAJJyHjLRxRU9hR+PHhLnxJPVJgeiAK2ACE+QV-ufJ7vLWQqWVg@mail.gmail.com> Subject: Re: [Xen-devel] [PATCH RESEND V8 0/7] Introduce a QMP client To: Ian Jackson <Ian.Jackson@eu.citrix.com> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Cc: Ian Campbell <Ian.Campbell@eu.citrix.com>, Xen Devel <xen-devel@lists.xensource.com>, Stefano Stabellini <stefano.stabellini@eu.citrix.com> X-BeenThere: xen-devel@lists.xensource.com X-Mailman-Version: 2.1.5 Precedence: list List-Id: Xen developer discussion <xen-devel.lists.xensource.com> List-Unsubscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe> List-Post: <mailto:xen-devel@lists.xensource.com> List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help> List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=subscribe> Sender: xen-devel-bounces@lists.xensource.com Errors-To: xen-devel-bounces@lists.xensource.com On Wed, Sep 28, 2011 at 16:55, Ian Jackson <Ian.Jackson@eu.citrix.com> wrot= e: > Anthony PERARD writes ("[Xen-devel] [PATCH RESEND V8 0/7] Introduce a QMP= client"): >> Patch series rebased on last xen-unstable. No other change have been don= e. > > Thanks. =C2=A0I tried to apply this and: > > libxl_qmp.c:293: error: 'SOCK_NONBLOCK' undeclared (first use in this fun= ction) > libxl_qmp.c:293: error: (Each undeclared identifier is reported only once > libxl_qmp.c:293: error: for each function it appears in.) > > I think SOCK_NONBLOCK is nonstandard, and you will have to change the > code to use fcntl. The man page said that we can use this define since Linux 2.6.27, but I will change my patch to use fcntl instead. Regards, --=20 Anthony PERARD _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel From xen-devel-bounces@lists.xensource.com Thu Sep 29 04:16:47 2011 Return-path: <xen-devel-bounces@lists.xensource.com> Envelope-to: www-data@lists.xensource.com Delivery-date: Thu, 29 Sep 2011 04:16:47 -0700 Received: from localhost ([127.0.0.1] helo=lists.colo.xensource.com) by lists.xensource.com with esmtp (Exim 4.43) id 1R9Ebf-0003NC-2D; Thu, 29 Sep 2011 04:16:47 -0700 Received: from mail182.messagelabs.com ([85.158.139.83]) by lists.xensource.com with esmtp (Exim 4.43) id 1R9ERN-0001nK-NL for xen-devel@lists.xensource.com; Thu, 29 Sep 2011 04:06:13 -0700 X-Env-Sender: Stefano.Stabellini@eu.citrix.com X-Msg-Ref: server-5.tower-182.messagelabs.com!1317294364!15232678!1 X-Originating-IP: [66.165.176.63] X-StarScan-Version: 6.4.1; banners=-,-,- X-VirusChecked: Checked Received: (qmail 4030 invoked from network); 29 Sep 2011 11:06:06 -0000 Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63) by server-5.tower-182.messagelabs.com with RC4-SHA encrypted SMTP; 29 Sep 2011 11:06:06 -0000 X-IronPort-AV: E=Sophos;i="4.68,460,1312171200"; d="scan'208";a="165108569" Received: from ftlpmailmx02.citrite.net ([10.13.107.66]) by FTLPIPO02.CITRIX.COM with ESMTP/TLS/RC4-MD5; 29 Sep 2011 07:06:04 -0400 Received: from smtp01.ad.xensource.com (10.219.128.104) by smtprelay.citrix.com (10.13.107.66) with Microsoft SMTP Server id 8.3.137.0; Thu, 29 Sep 2011 07:06:04 -0400 Received: from localhost.localdomain (kaball.uk.xensource.com [10.80.2.59]) by smtp01.ad.xensource.com (8.13.1/8.13.1) with ESMTP id p8TB5uEg025475; Thu, 29 Sep 2011 04:05:57 -0700 From: <stefano.stabellini@eu.citrix.com> To: konrad.wilk@oracle.com Date: Thu, 29 Sep 2011 12:05:57 +0100 Message-ID: <1317294358-24291-1-git-send-email-stefano.stabellini@eu.citrix.com> X-Mailer: git-send-email 1.7.0.4 MIME-Version: 1.0 Content-Type: text/plain Cc: Ian.Campbell@eu.citrix.com, jeremy@goop.org, xen-devel@lists.xensource.com, Stefano Stabellini <stefano.stabellini@eu.citrix.com>, Stefano.Stabellini@eu.citrix.com Subject: [Xen-devel] [PATCH v2 1/2] xen: XEN_PVHVM depends on PCI X-BeenThere: xen-devel@lists.xensource.com X-Mailman-Version: 2.1.5 Precedence: list List-Id: Xen developer discussion <xen-devel.lists.xensource.com> List-Unsubscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe> List-Post: <mailto:xen-devel@lists.xensource.com> List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help> List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=subscribe> Sender: xen-devel-bounces@lists.xensource.com Errors-To: xen-devel-bounces@lists.xensource.com From: Stefano Stabellini <stefano.stabellini@eu.citrix.com> Xen PV on HVM guests require PCI support because they need the xen-platform-pci driver in order to initialize xenbus. Signed-off-by: Stefano Stabellini <stefano.stabellini@eu.citrix.com> --- arch/x86/xen/Kconfig | 3 +-- 1 files changed, 1 insertions(+), 2 deletions(-) diff --git a/arch/x86/xen/Kconfig b/arch/x86/xen/Kconfig index 5cc821c..e061f55 100644 --- a/arch/x86/xen/Kconfig +++ b/arch/x86/xen/Kconfig @@ -25,8 +25,7 @@ config XEN_PRIVILEGED_GUEST config XEN_PVHVM def_bool y - depends on XEN - depends on X86_LOCAL_APIC + depends on XEN && PCI && X86_LOCAL_APIC config XEN_MAX_DOMAIN_MEMORY int -- 1.7.2.3 _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel From xen-devel-bounces@lists.xensource.com Thu Sep 29 04:17:45 2011 Return-path: <xen-devel-bounces@lists.xensource.com> Envelope-to: www-data@lists.xensource.com Delivery-date: Thu, 29 Sep 2011 04:17:45 -0700 Received: from localhost ([127.0.0.1] helo=lists.colo.xensource.com) by lists.xensource.com with esmtp (Exim 4.43) id 1R9Ecb-0003jp-I4; Thu, 29 Sep 2011 04:17:45 -0700 Received: from mail216.messagelabs.com ([85.158.143.99]) by lists.xensource.com with esmtp (Exim 4.43) id 1R9ERT-0001nP-Hy for xen-devel@lists.xensource.com; Thu, 29 Sep 2011 04:06:18 -0700 X-Env-Sender: Stefano.Stabellini@eu.citrix.com X-Msg-Ref: server-9.tower-216.messagelabs.com!1317294371!20000323!1 X-Originating-IP: [66.165.176.89] X-StarScan-Version: 6.4.1; banners=-,-,- X-VirusChecked: Checked Received: (qmail 19132 invoked from network); 29 Sep 2011 11:06:12 -0000 Received: from smtp.citrix.com (HELO SMTP.CITRIX.COM) (66.165.176.89) by server-9.tower-216.messagelabs.com with RC4-SHA encrypted SMTP; 29 Sep 2011 11:06:12 -0000 X-IronPort-AV: E=Sophos;i="4.68,460,1312171200"; d="scan'208";a="17802196" Received: from ftlpmailmx02.citrite.net ([10.13.107.66]) by FTLPIPO01.CITRIX.COM with ESMTP/TLS/RC4-MD5; 29 Sep 2011 07:06:10 -0400 Received: from smtp01.ad.xensource.com (10.219.128.104) by smtprelay.citrix.com (10.13.107.66) with Microsoft SMTP Server id 8.3.137.0; Thu, 29 Sep 2011 07:06:10 -0400 Received: from localhost.localdomain (kaball.uk.xensource.com [10.80.2.59]) by smtp01.ad.xensource.com (8.13.1/8.13.1) with ESMTP id p8TB5uEh025475; Thu, 29 Sep 2011 04:05:58 -0700 From: <stefano.stabellini@eu.citrix.com> To: konrad.wilk@oracle.com Date: Thu, 29 Sep 2011 12:05:58 +0100 Message-ID: <1317294358-24291-2-git-send-email-stefano.stabellini@eu.citrix.com> X-Mailer: git-send-email 1.7.0.4 In-Reply-To: <1317294358-24291-1-git-send-email-stefano.stabellini@eu.citrix.com> References: <1317294358-24291-1-git-send-email-stefano.stabellini@eu.citrix.com> MIME-Version: 1.0 Content-Type: text/plain Cc: Ian.Campbell@eu.citrix.com, jeremy@goop.org, xen-devel@lists.xensource.com, Stefano Stabellini <stefano.stabellini@eu.citrix.com>, Stefano.Stabellini@eu.citrix.com Subject: [Xen-devel] [PATCH v2 2/2] xen: remove XEN_PLATFORM_PCI config option X-BeenThere: xen-devel@lists.xensource.com X-Mailman-Version: 2.1.5 Precedence: list List-Id: Xen developer discussion <xen-devel.lists.xensource.com> List-Unsubscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe> List-Post: <mailto:xen-devel@lists.xensource.com> List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help> List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=subscribe> Sender: xen-devel-bounces@lists.xensource.com Errors-To: xen-devel-bounces@lists.xensource.com From: Stefano Stabellini <stefano.stabellini@eu.citrix.com> Xen PVHVM needs xen-platform-pci, on the other hand xen-platform-pci is useless in any other cases. Therefore remove the XEN_PLATFORM_PCI config option and compile xen-platform-pci built-in if XEN_PVHVM is selected. Changes to v1: - remove xen-platform-pci.o and just use platform-pci.o since it is not externally visible anymore. Signed-off-by: Stefano Stabellini <stefano.stabellini@eu.citrix.com> --- drivers/xen/Kconfig | 10 ---------- drivers/xen/Makefile | 4 +--- 2 files changed, 1 insertions(+), 13 deletions(-) diff --git a/drivers/xen/Kconfig b/drivers/xen/Kconfig index 5f7ff8e..8795480 100644 --- a/drivers/xen/Kconfig +++ b/drivers/xen/Kconfig @@ -137,16 +137,6 @@ config XEN_GRANT_DEV_ALLOC to other domains. This can be used to implement frontend drivers or as part of an inter-domain shared memory channel. -config XEN_PLATFORM_PCI - tristate "xen platform pci device driver" - depends on XEN_PVHVM && PCI - default m - help - Driver for the Xen PCI Platform device: it is responsible for - initializing xenbus and grant_table when running in a Xen HVM - domain. As a consequence this driver is required to run any Xen PV - frontend on Xen HVM. - config SWIOTLB_XEN def_bool y depends on PCI diff --git a/drivers/xen/Makefile b/drivers/xen/Makefile index 72bbb27..974fffd 100644 --- a/drivers/xen/Makefile +++ b/drivers/xen/Makefile @@ -14,7 +14,7 @@ obj-$(CONFIG_XEN_GNTDEV) += xen-gntdev.o obj-$(CONFIG_XEN_GRANT_DEV_ALLOC) += xen-gntalloc.o obj-$(CONFIG_XENFS) += xenfs/ obj-$(CONFIG_XEN_SYS_HYPERVISOR) += sys-hypervisor.o -obj-$(CONFIG_XEN_PLATFORM_PCI) += xen-platform-pci.o +obj-$(CONFIG_XEN_PVHVM) += platform-pci.o obj-$(CONFIG_XEN_TMEM) += tmem.o obj-$(CONFIG_SWIOTLB_XEN) += swiotlb-xen.o obj-$(CONFIG_XEN_DOM0) += pci.o @@ -23,5 +23,3 @@ obj-$(CONFIG_XEN_PCIDEV_BACKEND) += xen-pciback/ xen-evtchn-y := evtchn.o xen-gntdev-y := gntdev.o xen-gntalloc-y := gntalloc.o - -xen-platform-pci-y := platform-pci.o -- 1.7.2.3 _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel From xen-devel-bounces@lists.xensource.com Thu Sep 29 04:18:43 2011 Return-path: <xen-devel-bounces@lists.xensource.com> Envelope-to: www-data@lists.xensource.com Delivery-date: Thu, 29 Sep 2011 04:18:43 -0700 Received: from localhost ([127.0.0.1] helo=lists.colo.xensource.com) by lists.xensource.com with esmtp (Exim 4.43) id 1R9EdW-00046O-LP; Thu, 29 Sep 2011 04:18:42 -0700 Received: from mail182.messagelabs.com ([85.158.139.83]) by lists.xensource.com with esmtp (Exim 4.43) id 1R9ESs-00022L-Jm for xen-devel@lists.xensource.com; Thu, 29 Sep 2011 04:07:45 -0700 X-Env-Sender: david.vrabel@citrix.com X-Msg-Ref: server-8.tower-182.messagelabs.com!1317294457!19028747!1 X-Originating-IP: [66.165.176.89] X-StarScan-Version: 6.4.1; banners=-,-,- X-VirusChecked: Checked Received: (qmail 13567 invoked from network); 29 Sep 2011 11:07:38 -0000 Received: from smtp.citrix.com (HELO SMTP.CITRIX.COM) (66.165.176.89) by server-8.tower-182.messagelabs.com with RC4-SHA encrypted SMTP; 29 Sep 2011 11:07:38 -0000 X-IronPort-AV: E=Sophos;i="4.68,460,1312171200"; d="scan'208";a="17802227" Received: from ftlpmailmx02.citrite.net ([10.13.107.66]) by FTLPIPO01.CITRIX.COM with ESMTP/TLS/RC4-MD5; 29 Sep 2011 07:07:37 -0400 Received: from smtp01.ad.xensource.com (10.219.128.104) by smtprelay.citrix.com (10.13.107.66) with Microsoft SMTP Server id 8.3.137.0; Thu, 29 Sep 2011 07:07:37 -0400 Received: from qabil.uk.xensource.com (qabil.uk.xensource.com [10.80.2.76]) by smtp01.ad.xensource.com (8.13.1/8.13.1) with ESMTP id p8TB7ZTc025480; Thu, 29 Sep 2011 04:07:36 -0700 From: David Vrabel <david.vrabel@citrix.com> To: xen-devel@lists.xensource.com Date: Thu, 29 Sep 2011 12:08:37 +0100 Message-ID: <1317294517-12614-1-git-send-email-david.vrabel@citrix.com> X-Mailer: git-send-email 1.7.2.5 In-Reply-To: <1317228396-8870-5-git-send-email-david.vrabel@citrix.com> References: <1317228396-8870-5-git-send-email-david.vrabel@citrix.com> MIME-Version: 1.0 Content-Type: text/plain Cc: David Vrabel <david.vrabel@citrix.com>, Konrad Rzeszutek Wilk <konrad.wilk@oracle.com> Subject: [Xen-devel] [PATCH] xen: release all pages within 1-1 p2m mappings X-BeenThere: xen-devel@lists.xensource.com X-Mailman-Version: 2.1.5 Precedence: list List-Id: Xen developer discussion <xen-devel.lists.xensource.com> List-Unsubscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe> List-Post: <mailto:xen-devel@lists.xensource.com> List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help> List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=subscribe> Sender: xen-devel-bounces@lists.xensource.com Errors-To: xen-devel-bounces@lists.xensource.com From: David Vrabel <david.vrabel@citrix.com> In xen_memory_setup() all reserved regions and gaps are set to an identity (1-1) p2m mapping. If an available page has a PFN within one of these 1-1 mappings it will become inaccessible (as it MFN is lost) so release them before setting up the mapping. This can make an additional 256 MiB or more of RAM available (depending on the size of the reserved regions in the memory map) if the initial pages overlap with reserved regions. The 1:1 p2m mappings are also extended to cover partial pages. This fixes an issue with (for example) systems with a BIOS that puts the DMI tables in a reserved region that begins on a non-page boundary. Signed-off-by: David Vrabel <david.vrabel@citrix.com> --- arch/x86/xen/setup.c | 117 ++++++++++++++++++-------------------------------- 1 files changed, 42 insertions(+), 75 deletions(-) diff --git a/arch/x86/xen/setup.c b/arch/x86/xen/setup.c index 2ad2fd5..38d0af4 100644 --- a/arch/x86/xen/setup.c +++ b/arch/x86/xen/setup.c @@ -83,25 +83,18 @@ static void __init xen_add_extra_mem(u64 start, u64 size) __set_phys_to_machine(pfn, INVALID_P2M_ENTRY); } -static unsigned long __init xen_release_chunk(phys_addr_t start_addr, - phys_addr_t end_addr) +static unsigned long __init xen_release_chunk(unsigned long start, + unsigned long end) { struct xen_memory_reservation reservation = { .address_bits = 0, .extent_order = 0, .domid = DOMID_SELF }; - unsigned long start, end; unsigned long len = 0; unsigned long pfn; int ret; - start = PFN_UP(start_addr); - end = PFN_DOWN(end_addr); - - if (end <= start) - return 0; - for(pfn = start; pfn < end; pfn++) { unsigned long mfn = pfn_to_mfn(pfn); @@ -126,72 +119,52 @@ static unsigned long __init xen_release_chunk(phys_addr_t start_addr, return len; } -static unsigned long __init xen_return_unused_memory( - unsigned long max_pfn, const struct e820entry *map, int nr_map) +static unsigned long __init xen_set_identity_and_release( + const struct e820entry *list, size_t map_size, unsigned long nr_pages) { - phys_addr_t max_addr = PFN_PHYS(max_pfn); - phys_addr_t last_end = ISA_END_ADDRESS; + phys_addr_t start = 0; unsigned long released = 0; - int i; - - /* Free any unused memory above the low 1Mbyte. */ - for (i = 0; i < nr_map && last_end < max_addr; i++) { - phys_addr_t end = map[i].addr; - end = min(max_addr, end); - - if (last_end < end) - released += xen_release_chunk(last_end, end); - last_end = max(last_end, map[i].addr + map[i].size); - } - - if (last_end < max_addr) - released += xen_release_chunk(last_end, max_addr); - - printk(KERN_INFO "released %lu pages of unused memory\n", released); - return released; -} - -static unsigned long __init xen_set_identity(const struct e820entry *list, - ssize_t map_size) -{ - phys_addr_t last = xen_initial_domain() ? 0 : ISA_END_ADDRESS; - phys_addr_t start_pci = last; - const struct e820entry *entry; unsigned long identity = 0; + const struct e820entry *entry; int i; + /* + * Combine non-RAM regions and gaps until a RAM region (or the + * end of the map) is reached, then set the 1:1 map and + * release the pages (if available) in those non-RAM regions. + * + * The combined non-RAM regions are rounded to a whole number + * of pages so any partial pages are accessible via the 1:1 + * mapping. This is needed for some BIOSes that put (for + * example) the DMI tables in a reserved region that begins on + * a non-page boundary. + */ for (i = 0, entry = list; i < map_size; i++, entry++) { - phys_addr_t start = entry->addr; - phys_addr_t end = start + entry->size; + phys_addr_t end = entry->addr + entry->size; - if (start < last) - start = last; + if (entry->type == E820_RAM || i == map_size - 1) { + unsigned long start_pfn = PFN_DOWN(start); + unsigned long end_pfn = PFN_UP(end); - if (end <= start) - continue; + if (entry->type == E820_RAM) + end_pfn = PFN_UP(entry->addr); - /* Skip over the 1MB region. */ - if (last > end) - continue; + if (start_pfn < end_pfn) { + if (start_pfn < nr_pages) + released += xen_release_chunk( + start_pfn, min(end_pfn, nr_pages)); - if ((entry->type == E820_RAM) || (entry->type == E820_UNUSABLE)) { - if (start > start_pci) identity += set_phys_range_identity( - PFN_UP(start_pci), PFN_DOWN(start)); - - /* Without saving 'last' we would gooble RAM too - * at the end of the loop. */ - last = end; - start_pci = end; - continue; + start_pfn, end_pfn); + } + start = end; } - start_pci = min(start, start_pci); - last = end; } - if (last > start_pci) - identity += set_phys_range_identity( - PFN_UP(start_pci), PFN_DOWN(last)); - return identity; + + printk(KERN_INFO "Released %lu pages of unused memory\n", released); + printk(KERN_INFO "Set %ld page(s) to 1-1 mapping\n", identity); + + return released; } static unsigned long __init xen_get_max_pages(void) @@ -232,7 +205,6 @@ char * __init xen_memory_setup(void) struct xen_memory_map memmap; unsigned long max_pages; unsigned long extra_pages = 0; - unsigned long identity_pages = 0; int i; int op; @@ -265,8 +237,13 @@ char * __init xen_memory_setup(void) if (max_pages > max_pfn) extra_pages += max_pages - max_pfn; - xen_released_pages = xen_return_unused_memory(max_pfn, map, - memmap.nr_entries); + /* + * Set P2M for all non-RAM pages and E820 gaps to be identity + * type PFNs. Any RAM pages that would be made inaccesible by + * this are first released. + */ + xen_released_pages = xen_set_identity_and_release( + map, memmap.nr_entries, max_pfn); extra_pages += xen_released_pages; /* @@ -312,10 +289,6 @@ char * __init xen_memory_setup(void) * In domU, the ISA region is normal, usable memory, but we * reserve ISA memory anyway because too many things poke * about in there. - * - * In Dom0, the host E820 information can leave gaps in the - * ISA range, which would cause us to release those pages. To - * avoid this, we unconditionally reserve them here. */ e820_add_region(ISA_START_ADDRESS, ISA_END_ADDRESS - ISA_START_ADDRESS, E820_RESERVED); @@ -332,12 +305,6 @@ char * __init xen_memory_setup(void) sanitize_e820_map(e820.map, ARRAY_SIZE(e820.map), &e820.nr_map); - /* - * Set P2M for all non-RAM pages and E820 gaps to be identity - * type PFNs. - */ - identity_pages = xen_set_identity(e820.map, e820.nr_map); - printk(KERN_INFO "Set %ld page(s) to 1-1 mapping.\n", identity_pages); return "Xen"; } -- 1.7.2.5 _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel From xen-devel-bounces@lists.xensource.com Thu Sep 29 04:19:33 2011 Return-path: <xen-devel-bounces@lists.xensource.com> Envelope-to: www-data@lists.xensource.com Delivery-date: Thu, 29 Sep 2011 04:19:33 -0700 Received: from localhost ([127.0.0.1] helo=lists.colo.xensource.com) by lists.xensource.com with esmtp (Exim 4.43) id 1R9EeL-0004Sy-4A; Thu, 29 Sep 2011 04:19:33 -0700 Received: from mail182.messagelabs.com ([85.158.139.83]) by lists.xensource.com with esmtp (Exim 4.43) id 1R9EUq-0002LH-P8 for xen-devel@lists.xensource.com; Thu, 29 Sep 2011 04:09:47 -0700 X-Env-Sender: evil.dani@gmail.com X-Msg-Ref: server-5.tower-182.messagelabs.com!1317294579!15233401!1 X-Originating-IP: [209.85.161.43] X-StarScan-Version: 6.4.1; banners=-,-,- X-VirusChecked: Checked Received: (qmail 16961 invoked from network); 29 Sep 2011 11:09:39 -0000 Received: from mail-fx0-f43.google.com (HELO mail-fx0-f43.google.com) (209.85.161.43) by server-5.tower-182.messagelabs.com with RC4-SHA encrypted SMTP; 29 Sep 2011 11:09:39 -0000 Received: by fxh19 with SMTP id 19so2072930fxh.30 for <xen-devel@lists.xensource.com>; Thu, 29 Sep 2011 04:09:39 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; bh=gSE/mAJ5yWGd3JNISMNIWbV3lzWN+BZQ3Oms8xonja0=; b=od1sH6C3UEQVMe6TGXYE97E419QhO1eoWlG51+eeImYBZGyeBxmfEVaTJ5Z/Xex7EP U5nuEBqpA3VqjUEYFFfMtyqM77LCU8kYFjBtQ8Ic14MFfYLU61IVDbx6NP4HMWhPvVLr qpWOkQ8ILhBGnZtNkOt0SXlprNIdQiXN2t2z8= MIME-Version: 1.0 Received: by 10.223.43.218 with SMTP id x26mr15977009fae.75.1317294579324; Thu, 29 Sep 2011 04:09:39 -0700 (PDT) Received: by 10.223.97.9 with HTTP; Thu, 29 Sep 2011 04:09:39 -0700 (PDT) In-Reply-To: <1317125353.26672.25.camel@zakaz.uk.xensource.com> References: <CAP2B85-QBczrKLWSKaRVBkao3=6PB=wnYvuKmoXYqGDbZFnTXA@mail.gmail.com> <4E81B46F.5080208@citrix.com> <CAP2B85_2L2jkRMqbD6OCRXXaPR1nXV3RmRgcLo2zTTuSLDq5_g@mail.gmail.com> <1317125353.26672.25.camel@zakaz.uk.xensource.com> Date: Thu, 29 Sep 2011 20:09:39 +0900 Message-ID: <CAP2B85_1j_-0kxMSYheFYVD9Qn0-eUxeuyyo92u5bahn_6yQMw@mail.gmail.com> Subject: Re: [Xen-devel] Debug event_channel.c From: Daniel Castro <evil.dani@gmail.com> To: Ian Campbell <Ian.Campbell@citrix.com> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com> X-BeenThere: xen-devel@lists.xensource.com X-Mailman-Version: 2.1.5 Precedence: list List-Id: Xen developer discussion <xen-devel.lists.xensource.com> List-Unsubscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe> List-Post: <mailto:xen-devel@lists.xensource.com> List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help> List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=subscribe> Sender: xen-devel-bounces@lists.xensource.com Errors-To: xen-devel-bounces@lists.xensource.com On Tue, Sep 27, 2011 at 9:09 PM, Ian Campbell <Ian.Campbell@citrix.com> wro= te: > On Tue, 2011-09-27 at 12:36 +0100, Daniel Castro wrote: >> On Tue, Sep 27, 2011 at 8:33 PM, Andrew Cooper >> <andrew.cooper3@citrix.com> wrote: >> > On 27/09/11 12:09, Daniel Castro wrote: >> >> Hello All, >> >> >> >> I am trying to debug event_channel.c for this I have filled the >> >> functions with gdprintk(XENLOG_WARNING, "..."); yet the messages are >> >> not displayed on dmesg or /var/log/xen. Where could they be printed? >> >> or should I use a different function? >> >> >> >> In grub I have loglvl=3Dall to print all messages... >> >> >> >> Thanks for the answer, >> >> >> >> Daniel >> >> >> > >> > gdprintk only gets set with guest debugging enabled. ( guest_loglvl on >> > the command line ) >> > >> > My suggestion would be to just use regular printks and look at the >> > serial log. >> >> How can can I look at the serial log from dom0? > > 'xl dmesg' (or using a serial cable of course ;-)) > > You can also add XENCONSOLED_TRACE=3Dhv in /etc/sysconfig/xencommons (or > the equivalent on your distro, the effect should be to add --log=3Dhv to > the xenconsoled command line). Then the xen console will be logged > under /var/log/xen somewhere. Ian, thanks for the info. This is the info I gathered: (XEN) schedule.c:658:d1 DEBUG 1: START DO POLL port -32060 on sched_poll.nr_ports 1 (XEN) schedule.c:719:d1 DEBUG 1: DO POLL test bit on port 2 exit here -> if ( test_bit(port, &shared_info(d, evtchn_pending)) ) (XEN) schedule.c:746:d1 DEBUG 1: DO POLL GOTO out: check previus msg, return rc=3D0 (XEN) event_channel.c:606:d1 DEBUG 1: set_pending (XEN) event_channel.c:628:d1 DEBUG 1 : evtchn_set_pending test_bit AND test_and_set_bit returned 0. (XEN) event_channel.c:637:d1 DEBUG 1: evtchn_set_pending bitmap_empty retur= n 0. In my code test_bit_and_clear in Xenstore ring_wait is in fact returning 0, it was expecting a one, the do_poll is finding the bit in 1 also according to test_bit, right? So the error is on the my test_bit_and_clear. Am I reading it correctly? Thanks all, Daniel > > Ian. > >> >> > >> > -- >> > Andrew Cooper - Dom0 Kernel Engineer, Citrix XenServer >> > T: +44 (0)1223 225 900, http://www.citrix.com >> > >> > >> > _______________________________________________ >> > Xen-devel mailing list >> > Xen-devel@lists.xensource.com >> > http://lists.xensource.com/xen-devel >> > >> >> >> > > > --=20 +-=3D=3D=3D=3D=3D---------------------------+ | +---------------------------------+ | This space intentionally blank for notetaking. | |=A0=A0 | Daniel Castro,=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 | | |=A0=A0 | Consultant/Programmer.| | |=A0=A0 | U Andes=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0=A0 | +-------------------------------------+ _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel From xen-devel-bounces@lists.xensource.com Thu Sep 29 04:20:31 2011 Return-path: <xen-devel-bounces@lists.xensource.com> Envelope-to: www-data@lists.xensource.com Delivery-date: Thu, 29 Sep 2011 04:20:31 -0700 Received: from localhost ([127.0.0.1] helo=lists.colo.xensource.com) by lists.xensource.com with esmtp (Exim 4.43) id 1R9EfH-0004pf-ME; Thu, 29 Sep 2011 04:20:31 -0700 Received: from mail216.messagelabs.com ([85.158.143.99]) by lists.xensource.com with esmtp (Exim 4.43) id 1R9EWC-0002do-CL for xen-devel@lists.xensource.com; Thu, 29 Sep 2011 04:11:09 -0700 X-Env-Sender: Stefano.Stabellini@eu.citrix.com X-Msg-Ref: server-15.tower-216.messagelabs.com!1317294645!19462792!1 X-Originating-IP: [62.200.22.115] X-StarScan-Version: 6.4.1; banners=-,-,- X-VirusChecked: Checked Received: (qmail 2754 invoked from network); 29 Sep 2011 11:10:45 -0000 Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115) by server-15.tower-216.messagelabs.com with RC4-SHA encrypted SMTP; 29 Sep 2011 11:10:45 -0000 X-IronPort-AV: E=Sophos;i="4.68,460,1312156800"; d="scan'208";a="8124890" Received: from lonpmailmx01.citrite.net ([10.30.203.162]) by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5; 29 Sep 2011 11:10:45 +0000 Received: from kaball.uk.xensource.com (10.80.2.59) by LONPMAILMX01.citrite.net (10.30.203.162) with Microsoft SMTP Server id 8.3.137.0; Thu, 29 Sep 2011 12:10:45 +0100 Date: Thu, 29 Sep 2011 12:10:31 +0100 From: Stefano Stabellini <stefano.stabellini@eu.citrix.com> X-X-Sender: sstabellini@kaball-desktop To: Ian Jackson <Ian.Jackson@eu.citrix.com> Subject: Re: [Xen-devel] [PATCH v6 1/5] Introduce git-checkout.sh In-Reply-To: <20099.17426.176688.137409@mariner.uk.xensource.com> Message-ID: <alpine.DEB.2.00.1109291207110.3519@kaball-desktop> References: <alpine.DEB.2.00.1109231302370.8700@kaball-desktop> <1316779878-10950-1-git-send-email-stefano.stabellini@eu.citrix.com> <20099.17426.176688.137409@mariner.uk.xensource.com> User-Agent: Alpine 2.00 (DEB 1167 2008-08-23) MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Cc: Ian Campbell <Ian.Campbell@eu.citrix.com>, "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>, "keir@xen.org" <keir@xen.org>, Stefano Stabellini <Stefano.Stabellini@eu.citrix.com> X-BeenThere: xen-devel@lists.xensource.com X-Mailman-Version: 2.1.5 Precedence: list List-Id: Xen developer discussion <xen-devel.lists.xensource.com> List-Unsubscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe> List-Post: <mailto:xen-devel@lists.xensource.com> List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help> List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=subscribe> Sender: xen-devel-bounces@lists.xensource.com Errors-To: xen-devel-bounces@lists.xensource.com On Wed, 28 Sep 2011, Ian Jackson wrote: > stefano.stabellini@eu.citrix.com writes ("[Xen-devel] [PATCH v6 1/5] Introduce git-checkout.sh"): > > Introduce a script to perform git checkout on an external git tree; use > > git-checkout.sh in ioemu-dir-find. > ... > > +#!/bin/sh > > + > > +TREE=$1 > > +TAG=$2 > > +DIR=$3 > > Missing > - set -e > - argument count check Yes, I'll add those. > > +if test \! -d $DIR-remote; then > > + rm -rf $DIR-remote $DIR-remote.tmp; > > Spurious semicolons. OK. > > distclean: subdirs-distclean > > - rm -rf ioemu-dir ioemu-remote > > + rm -rf ioemu-dir ioemu-dir-remote > > Would it be too much to ask you not to rename this directory ? Honestly I think that keeping the old name is bad: having two qemu trees cloned by xen-unstable is already confusing enough for both to users and developers, the very least we can do is naming the two trees meaningfully. _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel From xen-devel-bounces@lists.xensource.com Thu Sep 29 04:25:32 2011 Return-path: <xen-devel-bounces@lists.xensource.com> Envelope-to: www-data@lists.xensource.com Delivery-date: Thu, 29 Sep 2011 04:25:32 -0700 Received: from localhost ([127.0.0.1] helo=lists.colo.xensource.com) by lists.xensource.com with esmtp (Exim 4.43) id 1R9Ek6-0005M5-Kd; Thu, 29 Sep 2011 04:25:31 -0700 Received: from mail27.messagelabs.com ([193.109.254.147]) by lists.xensource.com with esmtp (Exim 4.43) id 1R9Eil-00058r-Jh for xen-devel@lists.xensource.com; Thu, 29 Sep 2011 04:24:08 -0700 X-Env-Sender: joseph.glanville@orionvm.com.au X-Msg-Ref: server-15.tower-27.messagelabs.com!1317295433!48790302!1 X-Originating-IP: [209.85.210.171] X-StarScan-Version: 6.4.1; banners=-,-,- X-VirusChecked: Checked Received: (qmail 8232 invoked from network); 29 Sep 2011 11:23:54 -0000 Received: from mail-iy0-f171.google.com (HELO mail-iy0-f171.google.com) (209.85.210.171) by server-15.tower-27.messagelabs.com with RC4-SHA encrypted SMTP; 29 Sep 2011 11:23:54 -0000 Received: by iagv1 with SMTP id v1so811524iag.30 for <xen-devel@lists.xensource.com>; Thu, 29 Sep 2011 04:24:02 -0700 (PDT) MIME-Version: 1.0 Received: by 10.231.0.221 with SMTP id 29mr14829031ibc.56.1317295442557; Thu, 29 Sep 2011 04:24:02 -0700 (PDT) Received: by 10.231.170.15 with HTTP; Thu, 29 Sep 2011 04:24:02 -0700 (PDT) X-Originating-IP: [59.167.234.130] In-Reply-To: <1317294104.26672.155.camel@zakaz.uk.xensource.com> References: <20110922130618.GA13238@phenom.oracle.com> <CAFLBxZaAaXTUtW5+VkxPnr_MR0fbW+d1Mzu4y0x=gEOaX9e0OQ@mail.gmail.com> <20110922174002.GA1205@phenom.oracle.com> <20098.1097.824552.541924@mariner.uk.xensource.com> <CAP2B85-=CbMgUGSwO2utvkeLLqk8A1vjhKrPwe2OD+0daAtqsA@mail.gmail.com> <1317195656.13424.73.camel@dagon.hellion.org.uk> <20099.8327.326129.357335@mariner.uk.xensource.com> <20110928134800.GH10270@phenom.oracle.com> <1317218459.26672.62.camel@zakaz.uk.xensource.com> <CAOzFzEhnr7Ri42V1AUMLw-xRn+9NQwu8Pkq8iPc=pS12w=Vnog@mail.gmail.com> <1317294104.26672.155.camel@zakaz.uk.xensource.com> Date: Thu, 29 Sep 2011 21:24:02 +1000 Message-ID: <CAOzFzEhNZbnm0mr1-mSU+4em3Kd930qOjmApbAZQ+3MAhskhfw@mail.gmail.com> Subject: Re: [Xen-devel] Xen document day (Oct 12 or 26) From: Joseph Glanville <joseph.glanville@orionvm.com.au> To: Ian Campbell <Ian.Campbell@eu.citrix.com> Cc: Daniel Castro <evil.dani@gmail.com>, "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>, Ian Jackson <Ian.Jackson@eu.citrix.com>, Konrad Rzeszutek Wilk <konrad.wilk@oracle.com> X-BeenThere: xen-devel@lists.xensource.com X-Mailman-Version: 2.1.5 Precedence: list List-Id: Xen developer discussion <xen-devel.lists.xensource.com> List-Unsubscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe> List-Post: <mailto:xen-devel@lists.xensource.com> List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help> List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=subscribe> Content-Type: multipart/mixed; boundary="===============0101200920==" Sender: xen-devel-bounces@lists.xensource.com Errors-To: xen-devel-bounces@lists.xensource.com --===============0101200920== Content-Type: multipart/alternative; boundary=00151773d3d2eafc8b04ae12be00 --00151773d3d2eafc8b04ae12be00 Content-Type: text/plain; charset=ISO-8859-1 Maybe the wiki frontpage etc needs abit of a restructure to highlight the newer documentation and try steer people away from old stuff? I am going to try do some tagging of the wiki pages tonight to mark what is out of date. Many of the pages I think just need simplification.. the current wiki is somewhat of an information overload (which is fine but we shouldn't bombard new users if we can avoid it) On 29 September 2011 21:01, Ian Campbell <Ian.Campbell@eu.citrix.com> wrote: > On Thu, 2011-09-29 at 11:53 +0100, Joseph Glanville wrote: > > +1 for Markdown. > > > > In terms of making Xen more accessible I think it might be a good idea > > to update/cleanup the distro support page. > > http://wiki.xen.org/xenwiki/DistributionSupport > > > > I can probably do this. > > Excellent, it looks like it needs it... > > > Making it simple for people to get started with Xen on a distro they > > are comfortable with is a good step forward. > > Agreed. In fact for many users this is probably the end goal, not just a > step along the way. > > > I know distro specific guides could turn into a nightmare but I am > > open to writing one for Debian 6 Squeeze, > > In cases such as this we should also consider updating the distro's wiki > page. I'm not sure where the canonical guide should live (wiki.xen.org > or wiki.debian.org) but they should certainly cross reference each > other. > Yeah that's a tricky one, I guess we can start at wiki.xen.org and go from there. Seeing as Debian repackages Xen, wiki.debian.org should probably be the final canonical location. > > > there are also a few that exist already for RHEL/CentOS on the wiki. > > This should get easier as more distros update to 3.0+ kernels that > > support PVops out of the box... > > > > Next would be networking documentation as network-bridge script has > > been deprecated. > > http://wiki.xensource.com/xenwiki/XenNetworking > > Once again I think alot of the documentation is going to be distro > > specific to be newbie friendly but atleast a simple ip/brctl guide > > would help. > > > > IMO knowing where to start and setting up networking were the biggest > > barriers when I was picking up Xen a few years back. > > We now have > http://wiki.xensource.com/xenwiki/HostConfiguration/Networking which > could do with being made more discoverable. > That is -much- better and as you said should be much easier to find.. > > There is also http://wiki.xensource.com/xenwiki/HostConfiguration but > its looking pretty sad right now... > I can think of some stuff to fill that up. eg. Howto enable live migration, local VM storage guide possibly > > > > > I am also open to updating the blktap2 pages and README to reflect the > > new tap-ctl userspace utilities and tips on driver development. > > > > <slightly off-topic but related> > > > > With jailtime.org(stacklet) now charging for subscription there is > > nowhere to download pre-built clean Xen compatible images free of > > charge etc. > > I have pvgrub/pygrub capable images of Ubuntu/Debian/CentOS that I am > > considering hosting for free. > > Generally new users are confused on how to build new paravirt VMs, I > > think prebuilt images are suboptimal but a good place to start for > > beginners. > > There was discussion of Debian providing such a thing on debian-deval > back in late July, I should chase that up really. > > Cheers, > Ian. > > > > > Joseph. > > > > On 29 September 2011 00:00, Ian Campbell <Ian.Campbell@eu.citrix.com> > > wrote: > > On Wed, 2011-09-28 at 14:48 +0100, Konrad Rzeszutek Wilk > > wrote: > > > On Wed, Sep 28, 2011 at 02:26:31PM +0100, Ian Jackson wrote: > > > > Ian Campbell writes ("Re: [Xen-devel] Xen document day > > (Oct 12 or 26)"): > > > > > Since the guest APIs are stable there should be > > relatively little churn > > > > > so perhaps a wiki page (or even series of pages) would > > be appropriate > > > > > for this sort of thing? > > > > > > > > I want this to be in-tree. If it's in-tree, we can refuse > > patches > > > > which do not update the documentation. > > > > > > > > > I think this would be good too and in fact even more > > important than the > > > > > interface documentation. Everyone needs to be able to > > build Xen to hack > > > > > on it but only a subset need to know any particular API. > > > > > > > > > > Also although we recommend that users consume Xen via > > their distro where > > > > > possible such a guide would also help any who would > > rather build from > > > > > scratch (e.g. because we've asked them to "try the > > latest version" or to > > > > > bisect a bug etc). > > > > > > > > This would be a good candidate for a wiki page, backed up > > by revisions > > > > of the in-tree README. > > > > > > > > > Any recommendations on what would be a good format to write > > these "interface" > > > pages in? > > > > > > For in-line (i.e. in xen/include/public/*.h) docs of APIs I > > played a > > little bit with integrating kernel-doc into the Xen build > > system but it > > is tied a little too closely to the kernel build > > infrastructure. > > > > Doxygen seems like a plausible alternative with life outside > > the kernel > > etc. We actually appear to already have some doxygen stuff for > > the > > pytyhon stuff (judging from the Makefile, I've not actually > > noticed the > > structured code comments anywhere) > > > > For non-inline docs I think we decided that markdown would be > > a good > > answer. > > > > Ian. > > > > > > > > _______________________________________________ > > Xen-devel mailing list > > Xen-devel@lists.xensource.com > > http://lists.xensource.com/xen-devel > > > > > > > > > > -- > > Founder | Director | VP Research > > > > Orion Virtualisation Solutions | www.orionvm.com.au | Phone: 1300 56 > > 99 52 | Mobile: 0428 754 846 > > > -- * Founder | Director | VP Research Orion Virtualisation Solutions* | www.orionvm.com.au | Phone: 1300 56 99 52 | Mobile: 0428 754 846 --00151773d3d2eafc8b04ae12be00 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Maybe the wiki frontpage etc needs abit of a restructure to highlight the n= ewer documentation and try steer people away from old stuff?<br>I am going = to try do some tagging of the wiki pages tonight to mark what is out of dat= e.<br> Many of the pages I think just need simplification.. the current wiki is so= mewhat of an information overload (which is fine but we shouldn't bomba= rd new users if we can avoid it)<br><br><div class=3D"gmail_quote">On 29 Se= ptember 2011 21:01, Ian Campbell <span dir=3D"ltr"><<a href=3D"mailto:Ia= n.Campbell@eu.citrix.com">Ian.Campbell@eu.citrix.com</a>></span> wrote:<= br> <blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1p= x #ccc solid;padding-left:1ex;"><div class=3D"im">On Thu, 2011-09-29 at 11:= 53 +0100, Joseph Glanville wrote:<br> > +1 for Markdown.<br> ><br> > In terms of making Xen more accessible I think it might be a good idea= <br> > to update/cleanup the distro support page.<br> > <a href=3D"http://wiki.xen.org/xenwiki/DistributionSupport" target=3D"= _blank">http://wiki.xen.org/xenwiki/DistributionSupport</a><br> ><br> > I can probably do this.<br> <br> </div>Excellent, it looks like it needs it...<br> <div class=3D"im"><br> > Making it simple for people to get started with Xen on a distro they<b= r> > are comfortable with is a good step forward.<br> <br> </div>Agreed. In fact for many users this is probably the end goal, not jus= t a<br> step along the way.<br> <div class=3D"im"><br> > I know distro specific guides could turn into a nightmare but I am<br> > open to writing one for Debian 6 Squeeze,<br> <br> </div>In cases such as this we should also consider updating the distro'= ;s wiki<br> page. I'm not sure where the canonical guide should live (<a href=3D"ht= tp://wiki.xen.org" target=3D"_blank">wiki.xen.org</a><br> or <a href=3D"http://wiki.debian.org" target=3D"_blank">wiki.debian.org</a>= ) but they should certainly cross reference each<br> other.<br></blockquote><div>=A0</div><div>Yeah that's a tricky one, I g= uess we can start at <a href=3D"http://wiki.xen.org">wiki.xen.org</a> and g= o from there.<br>Seeing as Debian repackages Xen, <a href=3D"http://wiki.de= bian.org">wiki.debian.org</a> should probably be the final canonical locati= on.<br> =A0<br></div><blockquote class=3D"gmail_quote" style=3D"margin: 0pt 0pt 0pt= 0.8ex; border-left: 1px solid rgb(204, 204, 204); padding-left: 1ex;"> <div class=3D"im"><br> > =A0there are also a few that exist already for RHEL/CentOS on the wiki= .<br> > This should get easier as more distros update to 3.0+ kernels that<br> > support PVops out of the box...<br> ><br> > Next would be networking documentation as network-bridge script has<br= > > been deprecated.<br> > <a href=3D"http://wiki.xensource.com/xenwiki/XenNetworking" target=3D"= _blank">http://wiki.xensource.com/xenwiki/XenNetworking</a><br> > Once again I think alot of the documentation is going to be distro<br> > specific to be newbie friendly but atleast a simple ip/brctl guide<br> > would help.<br> ><br> > IMO knowing where to start and setting up networking were the biggest<= br> > barriers when I was picking up Xen a few years back.<br> <br> </div>We now have<br> <a href=3D"http://wiki.xensource.com/xenwiki/HostConfiguration/Networking" = target=3D"_blank">http://wiki.xensource.com/xenwiki/HostConfiguration/Netwo= rking</a> which<br> could do with being made more discoverable.<br></blockquote><div>=A0</div><= div>That is -much- better and as you said should be much easier to find.. <= br></div><blockquote class=3D"gmail_quote" style=3D"margin: 0pt 0pt 0pt 0.8= ex; border-left: 1px solid rgb(204, 204, 204); padding-left: 1ex;"> <br> There is also <a href=3D"http://wiki.xensource.com/xenwiki/HostConfiguratio= n" target=3D"_blank">http://wiki.xensource.com/xenwiki/HostConfiguration</a= > but<br> its looking pretty sad right now...<br></blockquote><div>=A0</div><div>I ca= n think of some stuff to fill that up.<br>eg. Howto enable live migration, = local VM storage guide possibly<br>=A0<br></div><blockquote class=3D"gmail_= quote" style=3D"margin: 0pt 0pt 0pt 0.8ex; border-left: 1px solid rgb(204, = 204, 204); padding-left: 1ex;"> <div class=3D"im"><br> ><br> > I am also open to updating the blktap2 pages and README to reflect the= <br> > new tap-ctl userspace utilities and tips on driver development.<br> ><br> > <slightly off-topic but related><br> ><br> > With <a href=3D"http://jailtime.org" target=3D"_blank">jailtime.org</a= >(stacklet) now charging for subscription there is<br> > nowhere to download pre-built clean Xen compatible images free of<br> > charge etc.<br> > I have pvgrub/pygrub capable images of Ubuntu/Debian/CentOS that I am<= br> > considering hosting for free.<br> > Generally new users are confused on how to build new paravirt VMs, I<b= r> > think prebuilt images are suboptimal but a good place to start for<br> > beginners.<br> <br> </div>There was discussion of Debian providing such a thing on debian-deval= <br> back in late July, I should chase that up really.<br> <br> Cheers,<br> <font color=3D"#888888">Ian.<br> </font><div><div></div><div class=3D"h5"><br> ><br> > Joseph.<br> ><br> > On 29 September 2011 00:00, Ian Campbell <<a href=3D"mailto:Ian.Cam= pbell@eu.citrix.com">Ian.Campbell@eu.citrix.com</a>><br> > wrote:<br> > =A0 =A0 =A0 =A0 On Wed, 2011-09-28 at 14:48 +0100, Konrad Rzeszutek Wi= lk<br> > =A0 =A0 =A0 =A0 wrote:<br> > =A0 =A0 =A0 =A0 > On Wed, Sep 28, 2011 at 02:26:31PM +0100, Ian Jac= kson wrote:<br> > =A0 =A0 =A0 =A0 > > Ian Campbell writes ("Re: [Xen-devel] X= en document day<br> > =A0 =A0 =A0 =A0 (Oct 12 or 26)"):<br> > =A0 =A0 =A0 =A0 > > > Since the guest APIs are stable there s= hould be<br> > =A0 =A0 =A0 =A0 relatively little churn<br> > =A0 =A0 =A0 =A0 > > > so perhaps a wiki page (or even series = of pages) would<br> > =A0 =A0 =A0 =A0 be appropriate<br> > =A0 =A0 =A0 =A0 > > > for this sort of thing?<br> > =A0 =A0 =A0 =A0 > ><br> > =A0 =A0 =A0 =A0 > > I want this to be in-tree. =A0If it's in= -tree, we can refuse<br> > =A0 =A0 =A0 =A0 patches<br> > =A0 =A0 =A0 =A0 > > which do not update the documentation.<br> > =A0 =A0 =A0 =A0 > ><br> > =A0 =A0 =A0 =A0 > > > I think this would be good too and in f= act even more<br> > =A0 =A0 =A0 =A0 important than the<br> > =A0 =A0 =A0 =A0 > > > interface documentation. Everyone needs= to be able to<br> > =A0 =A0 =A0 =A0 build Xen to hack<br> > =A0 =A0 =A0 =A0 > > > on it but only a subset need to know an= y particular API.<br> > =A0 =A0 =A0 =A0 > > ><br> > =A0 =A0 =A0 =A0 > > > Also although we recommend that users c= onsume Xen via<br> > =A0 =A0 =A0 =A0 their distro where<br> > =A0 =A0 =A0 =A0 > > > possible such a guide would also help a= ny who would<br> > =A0 =A0 =A0 =A0 rather build from<br> > =A0 =A0 =A0 =A0 > > > scratch (e.g. because we've asked t= hem to "try the<br> > =A0 =A0 =A0 =A0 latest version" or to<br> > =A0 =A0 =A0 =A0 > > > bisect a bug etc).<br> > =A0 =A0 =A0 =A0 > ><br> > =A0 =A0 =A0 =A0 > > This would be a good candidate for a wiki pa= ge, backed up<br> > =A0 =A0 =A0 =A0 by revisions<br> > =A0 =A0 =A0 =A0 > > of the in-tree README.<br> > =A0 =A0 =A0 =A0 ><br> > =A0 =A0 =A0 =A0 ><br> > =A0 =A0 =A0 =A0 > Any recommendations on what would be a good forma= t to write<br> > =A0 =A0 =A0 =A0 these "interface"<br> > =A0 =A0 =A0 =A0 > pages in?<br> ><br> ><br> > =A0 =A0 =A0 =A0 For in-line (i.e. in xen/include/public/*.h) docs of A= PIs I<br> > =A0 =A0 =A0 =A0 played a<br> > =A0 =A0 =A0 =A0 little bit with integrating kernel-doc into the Xen bu= ild<br> > =A0 =A0 =A0 =A0 system but it<br> > =A0 =A0 =A0 =A0 is tied a little too closely to the kernel build<br> > =A0 =A0 =A0 =A0 infrastructure.<br> ><br> > =A0 =A0 =A0 =A0 Doxygen seems like a plausible alternative with life o= utside<br> > =A0 =A0 =A0 =A0 the kernel<br> > =A0 =A0 =A0 =A0 etc. We actually appear to already have some doxygen s= tuff for<br> > =A0 =A0 =A0 =A0 the<br> > =A0 =A0 =A0 =A0 pytyhon stuff (judging from the Makefile, I've not= actually<br> > =A0 =A0 =A0 =A0 noticed the<br> > =A0 =A0 =A0 =A0 structured code comments anywhere)<br> ><br> > =A0 =A0 =A0 =A0 For non-inline docs I think we decided that markdown w= ould be<br> > =A0 =A0 =A0 =A0 a good<br> > =A0 =A0 =A0 =A0 answer.<br> ><br> > =A0 =A0 =A0 =A0 Ian.<br> ><br> ><br> ><br> > =A0 =A0 =A0 =A0 _______________________________________________<br> > =A0 =A0 =A0 =A0 Xen-devel mailing list<br> > =A0 =A0 =A0 =A0 <a href=3D"mailto:Xen-devel@lists.xensource.com">Xen-d= evel@lists.xensource.com</a><br> > =A0 =A0 =A0 =A0 <a href=3D"http://lists.xensource.com/xen-devel" targe= t=3D"_blank">http://lists.xensource.com/xen-devel</a><br> ><br> ><br> ><br> ><br> > --<br> > Founder | Director | VP Research<br> ><br> > Orion Virtualisation Solutions | <a href=3D"http://www.orionvm.com.au"= target=3D"_blank">www.orionvm.com.au</a> | Phone: 1300 56<br> > 99 52 | Mobile: 0428 754 846<br> <br> <br> </div></div></blockquote></div><br><br clear=3D"all"><br>-- <br><span style= =3D"font-family:arial,sans-serif;font-size:13px;border-collapse:collapse"><= b><i><font color=3D"#0000ff"><div><font color=3D"#000000"><span style=3D"fo= nt-style:normal;font-weight:normal">Founder | Director | VP Research<br> </span></font></div>Orion Virtualisation Solutions</font></i></b>=A0|=A0<fo= nt color=3D"#0000ff"><a href=3D"http://www.orionvm.com.au/" style=3D"color:= rgb(42, 93, 176)" target=3D"_blank">www.orionvm.com.au</a></font>=A0| Phone= : 1300 56 99 52 | Mobile: 0428 754 846</span><br> --00151773d3d2eafc8b04ae12be00-- --===============0101200920== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel --===============0101200920==-- From xen-devel-bounces@lists.xensource.com Thu Sep 29 04:26:49 2011 Return-path: <xen-devel-bounces@lists.xensource.com> Envelope-to: www-data@lists.xensource.com Delivery-date: Thu, 29 Sep 2011 04:26:49 -0700 Received: from localhost ([127.0.0.1] helo=lists.colo.xensource.com) by lists.xensource.com with esmtp (Exim 4.43) id 1R9ElN-0005k6-JF; Thu, 29 Sep 2011 04:26:49 -0700 Received: from mail182.messagelabs.com ([85.158.139.83]) by lists.xensource.com with esmtp (Exim 4.43) id 1R9Ek4-0005Ki-T6 for xen-devel@lists.xensource.com; Thu, 29 Sep 2011 04:25:29 -0700 X-Env-Sender: david.vrabel@citrix.com X-Msg-Ref: server-11.tower-182.messagelabs.com!1317295524!18403483!1 X-Originating-IP: [66.165.176.89] X-StarScan-Version: 6.4.1; banners=-,-,- X-VirusChecked: Checked Received: (qmail 1989 invoked from network); 29 Sep 2011 11:25:25 -0000 Received: from smtp.citrix.com (HELO SMTP.CITRIX.COM) (66.165.176.89) by server-11.tower-182.messagelabs.com with RC4-SHA encrypted SMTP; 29 Sep 2011 11:25:25 -0000 X-IronPort-AV: E=Sophos;i="4.68,460,1312171200"; d="scan'208";a="17802457" Received: from ftlpmailmx01.citrite.net ([10.13.107.65]) by FTLPIPO01.CITRIX.COM with ESMTP/TLS/RC4-MD5; 29 Sep 2011 07:25:24 -0400 Received: from smtp01.ad.xensource.com (10.219.128.104) by smtprelay.citrix.com (10.13.107.65) with Microsoft SMTP Server id 8.3.137.0; Thu, 29 Sep 2011 07:25:23 -0400 Received: from qabil.uk.xensource.com (qabil.uk.xensource.com [10.80.2.76]) by smtp01.ad.xensource.com (8.13.1/8.13.1) with ESMTP id p8TBPLut025530; Thu, 29 Sep 2011 04:25:22 -0700 From: David Vrabel <david.vrabel@citrix.com> To: xen-devel@lists.xensource.com Date: Thu, 29 Sep 2011 12:26:19 +0100 Message-ID: <1317295580-12798-1-git-send-email-david.vrabel@citrix.com> X-Mailer: git-send-email 1.7.2.5 In-Reply-To: <1317228396-8870-5-git-send-email-david.vrabel@citrix.com> References: <1317228396-8870-5-git-send-email-david.vrabel@citrix.com> MIME-Version: 1.0 Content-Type: text/plain Cc: David Vrabel <david.vrabel@citrix.com>, Konrad Rzeszutek Wilk <konrad.wilk@oracle.com> Subject: [Xen-devel] [PATCH 1/2] xen: allow extra memory to be in multiple regions X-BeenThere: xen-devel@lists.xensource.com X-Mailman-Version: 2.1.5 Precedence: list List-Id: Xen developer discussion <xen-devel.lists.xensource.com> List-Unsubscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe> List-Post: <mailto:xen-devel@lists.xensource.com> List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help> List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=subscribe> Sender: xen-devel-bounces@lists.xensource.com Errors-To: xen-devel-bounces@lists.xensource.com From: David Vrabel <david.vrabel@citrix.com> Allow the extra memory (used by the balloon driver) to be in multiple regions (typically two regions, one for low memory and one for high memory). This allows the balloon driver to increase the number of available low pages (if the initial number if pages is small). As a side effect, the algorithm for building the e820 memory map is simpler and more obviously correct as the map supplied by the hypervisor is (almost) used as is (in particular, all reserved regions and gaps are preserved). Only RAM regions are altered and RAM regions above max_pfn + extra_pages are marked as unused (the region is split in two if necessary). Signed-off-by: David Vrabel <david.vrabel@citrix.com> --- arch/x86/xen/setup.c | 182 ++++++++++++++++++++++++-------------------------- 1 files changed, 86 insertions(+), 96 deletions(-) diff --git a/arch/x86/xen/setup.c b/arch/x86/xen/setup.c index 0c8e974..2ad2fd5 100644 --- a/arch/x86/xen/setup.c +++ b/arch/x86/xen/setup.c @@ -54,26 +54,32 @@ unsigned long xen_released_pages; */ #define EXTRA_MEM_RATIO (10) -static void __init xen_add_extra_mem(unsigned long pages) +static void __init xen_add_extra_mem(u64 start, u64 size) { unsigned long pfn; + int i; - u64 size = (u64)pages * PAGE_SIZE; - u64 extra_start = xen_extra_mem[0].start + xen_extra_mem[0].size; - - if (!pages) - return; - - e820_add_region(extra_start, size, E820_RAM); - sanitize_e820_map(e820.map, ARRAY_SIZE(e820.map), &e820.nr_map); - - memblock_x86_reserve_range(extra_start, extra_start + size, "XEN EXTRA"); + for (i = 0; i < XEN_EXTRA_MEM_MAX_REGIONS; i++) { + /* Add new region. */ + if (xen_extra_mem[i].size == 0) { + xen_extra_mem[i].start = start; + xen_extra_mem[i].size = size; + break; + } + /* Append to existing region. */ + if (xen_extra_mem[i].start + xen_extra_mem[i].size == start) { + xen_extra_mem[i].size += size; + break; + } + } + if (i == XEN_EXTRA_MEM_MAX_REGIONS) + printk(KERN_WARNING "Warning: not enough extra memory regions\n"); - xen_extra_mem[0].size += size; + memblock_x86_reserve_range(start, start + size, "XEN EXTRA"); - xen_max_p2m_pfn = PFN_DOWN(extra_start + size); + xen_max_p2m_pfn = PFN_DOWN(start + size); - for (pfn = PFN_DOWN(extra_start); pfn <= xen_max_p2m_pfn; pfn++) + for (pfn = PFN_DOWN(start); pfn <= xen_max_p2m_pfn; pfn++) __set_phys_to_machine(pfn, INVALID_P2M_ENTRY); } @@ -120,8 +126,8 @@ static unsigned long __init xen_release_chunk(phys_addr_t start_addr, return len; } -static unsigned long __init xen_return_unused_memory(unsigned long max_pfn, - const struct e820map *e820) +static unsigned long __init xen_return_unused_memory( + unsigned long max_pfn, const struct e820entry *map, int nr_map) { phys_addr_t max_addr = PFN_PHYS(max_pfn); phys_addr_t last_end = ISA_END_ADDRESS; @@ -129,13 +135,13 @@ static unsigned long __init xen_return_unused_memory(unsigned long max_pfn, int i; /* Free any unused memory above the low 1Mbyte. */ - for (i = 0; i < e820->nr_map && last_end < max_addr; i++) { - phys_addr_t end = e820->map[i].addr; + for (i = 0; i < nr_map && last_end < max_addr; i++) { + phys_addr_t end = map[i].addr; end = min(max_addr, end); if (last_end < end) released += xen_release_chunk(last_end, end); - last_end = max(last_end, e820->map[i].addr + e820->map[i].size); + last_end = max(last_end, map[i].addr + map[i].size); } if (last_end < max_addr) @@ -200,20 +206,32 @@ static unsigned long __init xen_get_max_pages(void) return min(max_pages, MAX_DOMAIN_PAGES); } +static void xen_align_and_add_e820_region(u64 start, u64 size, int type) +{ + u64 end = start + size; + + /* Align RAM regions to page boundaries. */ + if (type == E820_RAM) { + start = PAGE_ALIGN(start); + end &= ~((u64)PAGE_SIZE - 1); + } + + e820_add_region(start, end - start, type); +} + /** * machine_specific_memory_setup - Hook for machine specific memory setup. **/ char * __init xen_memory_setup(void) { static struct e820entry map[E820MAX] __initdata; - static struct e820entry map_raw[E820MAX] __initdata; unsigned long max_pfn = xen_start_info->nr_pages; unsigned long long mem_end; int rc; struct xen_memory_map memmap; + unsigned long max_pages; unsigned long extra_pages = 0; - unsigned long extra_limit; unsigned long identity_pages = 0; int i; int op; @@ -240,49 +258,55 @@ char * __init xen_memory_setup(void) } BUG_ON(rc); - memcpy(map_raw, map, sizeof(map)); - e820.nr_map = 0; - xen_extra_mem[0].start = mem_end; - for (i = 0; i < memmap.nr_entries; i++) { - unsigned long long end; - - /* Guard against non-page aligned E820 entries. */ - if (map[i].type == E820_RAM) - map[i].size -= (map[i].size + map[i].addr) % PAGE_SIZE; - - end = map[i].addr + map[i].size; - if (map[i].type == E820_RAM && end > mem_end) { - /* RAM off the end - may be partially included */ - u64 delta = min(map[i].size, end - mem_end); - - map[i].size -= delta; - end -= delta; - - extra_pages += PFN_DOWN(delta); - /* - * Set RAM below 4GB that is not for us to be unusable. - * This prevents "System RAM" address space from being - * used as potential resource for I/O address (happens - * when 'allocate_resource' is called). - */ - if (delta && - (xen_initial_domain() && end < 0x100000000ULL)) - e820_add_region(end, delta, E820_UNUSABLE); + /* Make sure the Xen-supplied memory map is well-ordered. */ + sanitize_e820_map(map, memmap.nr_entries, &memmap.nr_entries); + + max_pages = xen_get_max_pages(); + if (max_pages > max_pfn) + extra_pages += max_pages - max_pfn; + + xen_released_pages = xen_return_unused_memory(max_pfn, map, + memmap.nr_entries); + extra_pages += xen_released_pages; + + /* + * Clamp the amount of extra memory to a EXTRA_MEM_RATIO + * factor the base size. On non-highmem systems, the base + * size is the full initial memory allocation; on highmem it + * is limited to the max size of lowmem, so that it doesn't + * get completely filled. + * + * In principle there could be a problem in lowmem systems if + * the initial memory is also very large with respect to + * lowmem, but we won't try to deal with that here. + */ + extra_pages = min(EXTRA_MEM_RATIO * min(max_pfn, PFN_DOWN(MAXMEM)), + extra_pages); + + i = 0; + while (i < memmap.nr_entries) { + u64 addr = map[i].addr; + u64 size = map[i].size; + u32 type = map[i].type; + + if (type == E820_RAM) { + if (addr < mem_end) { + size = min(size, mem_end - addr); + } else if (extra_pages) { + size = min(size, (u64)extra_pages * PAGE_SIZE); + extra_pages -= size / PAGE_SIZE; + xen_add_extra_mem(addr, size); + } else + type = E820_UNUSABLE; } - if (map[i].size > 0 && end > xen_extra_mem[0].start) - xen_extra_mem[0].start = end; + xen_align_and_add_e820_region(addr, size, type); - /* Add region if any remains */ - if (map[i].size > 0) - e820_add_region(map[i].addr, map[i].size, map[i].type); + map[i].addr += size; + map[i].size -= size; + if (map[i].size == 0) + i++; } - /* Align the balloon area so that max_low_pfn does not get set - * to be at the _end_ of the PCI gap at the far end (fee01000). - * Note that the start of balloon area gets set in the loop above - * to be past the last E820 region. */ - if (xen_initial_domain() && (xen_extra_mem[0].start < (1ULL<<32))) - xen_extra_mem[0].start = (1ULL<<32); /* * In domU, the ISA region is normal, usable memory, but we @@ -308,45 +332,11 @@ char * __init xen_memory_setup(void) sanitize_e820_map(e820.map, ARRAY_SIZE(e820.map), &e820.nr_map); - extra_limit = xen_get_max_pages(); - if (max_pfn + extra_pages > extra_limit) { - if (extra_limit > max_pfn) - extra_pages = extra_limit - max_pfn; - else - extra_pages = 0; - } - - xen_released_pages = xen_return_unused_memory(xen_start_info->nr_pages, - &e820); - extra_pages += xen_released_pages; - - /* - * Clamp the amount of extra memory to a EXTRA_MEM_RATIO - * factor the base size. On non-highmem systems, the base - * size is the full initial memory allocation; on highmem it - * is limited to the max size of lowmem, so that it doesn't - * get completely filled. - * - * In principle there could be a problem in lowmem systems if - * the initial memory is also very large with respect to - * lowmem, but we won't try to deal with that here. - */ - extra_limit = min(EXTRA_MEM_RATIO * min(max_pfn, PFN_DOWN(MAXMEM)), - max_pfn + extra_pages); - - if (extra_limit >= max_pfn) - extra_pages = extra_limit - max_pfn; - else - extra_pages = 0; - - xen_add_extra_mem(extra_pages); - /* * Set P2M for all non-RAM pages and E820 gaps to be identity - * type PFNs. We supply it with the non-sanitized version - * of the E820. + * type PFNs. */ - identity_pages = xen_set_identity(map_raw, memmap.nr_entries); + identity_pages = xen_set_identity(e820.map, e820.nr_map); printk(KERN_INFO "Set %ld page(s) to 1-1 mapping.\n", identity_pages); return "Xen"; } -- 1.7.2.5 _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel From xen-devel-bounces@lists.xensource.com Thu Sep 29 04:27:46 2011 Return-path: <xen-devel-bounces@lists.xensource.com> Envelope-to: www-data@lists.xensource.com Delivery-date: Thu, 29 Sep 2011 04:27:46 -0700 Received: from localhost ([127.0.0.1] helo=lists.colo.xensource.com) by lists.xensource.com with esmtp (Exim 4.43) id 1R9EmI-000670-OQ; Thu, 29 Sep 2011 04:27:46 -0700 Received: from mail21.messagelabs.com ([85.158.143.35]) by lists.xensource.com with esmtp (Exim 4.43) id 1R9Ek5-0005Kw-Pm for xen-devel@lists.xensource.com; Thu, 29 Sep 2011 04:25:30 -0700 X-Env-Sender: david.vrabel@citrix.com X-Msg-Ref: server-15.tower-21.messagelabs.com!1317295527!52432632!1 X-Originating-IP: [66.165.176.63] X-StarScan-Version: 6.4.1; banners=-,-,- X-VirusChecked: Checked Received: (qmail 11093 invoked from network); 29 Sep 2011 11:25:28 -0000 Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63) by server-15.tower-21.messagelabs.com with RC4-SHA encrypted SMTP; 29 Sep 2011 11:25:28 -0000 X-IronPort-AV: E=Sophos;i="4.68,460,1312171200"; d="scan'208";a="165110452" Received: from ftlpmailmx01.citrite.net ([10.13.107.65]) by FTLPIPO02.CITRIX.COM with ESMTP/TLS/RC4-MD5; 29 Sep 2011 07:25:25 -0400 Received: from smtp01.ad.xensource.com (10.219.128.104) by smtprelay.citrix.com (10.13.107.65) with Microsoft SMTP Server id 8.3.137.0; Thu, 29 Sep 2011 07:25:24 -0400 Received: from qabil.uk.xensource.com (qabil.uk.xensource.com [10.80.2.76]) by smtp01.ad.xensource.com (8.13.1/8.13.1) with ESMTP id p8TBPLuu025530; Thu, 29 Sep 2011 04:25:23 -0700 From: David Vrabel <david.vrabel@citrix.com> To: xen-devel@lists.xensource.com Date: Thu, 29 Sep 2011 12:26:20 +0100 Message-ID: <1317295580-12798-2-git-send-email-david.vrabel@citrix.com> X-Mailer: git-send-email 1.7.2.5 In-Reply-To: <1317228396-8870-5-git-send-email-david.vrabel@citrix.com> References: <1317228396-8870-5-git-send-email-david.vrabel@citrix.com> MIME-Version: 1.0 Content-Type: text/plain Cc: David Vrabel <david.vrabel@citrix.com>, Konrad Rzeszutek Wilk <konrad.wilk@oracle.com> Subject: [Xen-devel] [PATCH 2/2] xen: release all pages within 1-1 p2m mappings X-BeenThere: xen-devel@lists.xensource.com X-Mailman-Version: 2.1.5 Precedence: list List-Id: Xen developer discussion <xen-devel.lists.xensource.com> List-Unsubscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe> List-Post: <mailto:xen-devel@lists.xensource.com> List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help> List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=subscribe> Sender: xen-devel-bounces@lists.xensource.com Errors-To: xen-devel-bounces@lists.xensource.com From: David Vrabel <david.vrabel@citrix.com> In xen_memory_setup() all reserved regions and gaps are set to an identity (1-1) p2m mapping. If an available page has a PFN within one of these 1-1 mappings it will become inaccessible (as it MFN is lost) so release them before setting up the mapping. This can make an additional 256 MiB or more of RAM available (depending on the size of the reserved regions in the memory map) if the initial pages overlap with reserved regions. The 1:1 p2m mappings are also extended to cover partial pages. This fixes an issue with (for example) systems with a BIOS that puts the DMI tables in a reserved region that begins on a non-page boundary. Signed-off-by: David Vrabel <david.vrabel@citrix.com> --- arch/x86/xen/setup.c | 117 ++++++++++++++++++-------------------------------- 1 files changed, 42 insertions(+), 75 deletions(-) diff --git a/arch/x86/xen/setup.c b/arch/x86/xen/setup.c index 2ad2fd5..38d0af4 100644 --- a/arch/x86/xen/setup.c +++ b/arch/x86/xen/setup.c @@ -83,25 +83,18 @@ static void __init xen_add_extra_mem(u64 start, u64 size) __set_phys_to_machine(pfn, INVALID_P2M_ENTRY); } -static unsigned long __init xen_release_chunk(phys_addr_t start_addr, - phys_addr_t end_addr) +static unsigned long __init xen_release_chunk(unsigned long start, + unsigned long end) { struct xen_memory_reservation reservation = { .address_bits = 0, .extent_order = 0, .domid = DOMID_SELF }; - unsigned long start, end; unsigned long len = 0; unsigned long pfn; int ret; - start = PFN_UP(start_addr); - end = PFN_DOWN(end_addr); - - if (end <= start) - return 0; - for(pfn = start; pfn < end; pfn++) { unsigned long mfn = pfn_to_mfn(pfn); @@ -126,72 +119,52 @@ static unsigned long __init xen_release_chunk(phys_addr_t start_addr, return len; } -static unsigned long __init xen_return_unused_memory( - unsigned long max_pfn, const struct e820entry *map, int nr_map) +static unsigned long __init xen_set_identity_and_release( + const struct e820entry *list, size_t map_size, unsigned long nr_pages) { - phys_addr_t max_addr = PFN_PHYS(max_pfn); - phys_addr_t last_end = ISA_END_ADDRESS; + phys_addr_t start = 0; unsigned long released = 0; - int i; - - /* Free any unused memory above the low 1Mbyte. */ - for (i = 0; i < nr_map && last_end < max_addr; i++) { - phys_addr_t end = map[i].addr; - end = min(max_addr, end); - - if (last_end < end) - released += xen_release_chunk(last_end, end); - last_end = max(last_end, map[i].addr + map[i].size); - } - - if (last_end < max_addr) - released += xen_release_chunk(last_end, max_addr); - - printk(KERN_INFO "released %lu pages of unused memory\n", released); - return released; -} - -static unsigned long __init xen_set_identity(const struct e820entry *list, - ssize_t map_size) -{ - phys_addr_t last = xen_initial_domain() ? 0 : ISA_END_ADDRESS; - phys_addr_t start_pci = last; - const struct e820entry *entry; unsigned long identity = 0; + const struct e820entry *entry; int i; + /* + * Combine non-RAM regions and gaps until a RAM region (or the + * end of the map) is reached, then set the 1:1 map and + * release the pages (if available) in those non-RAM regions. + * + * The combined non-RAM regions are rounded to a whole number + * of pages so any partial pages are accessible via the 1:1 + * mapping. This is needed for some BIOSes that put (for + * example) the DMI tables in a reserved region that begins on + * a non-page boundary. + */ for (i = 0, entry = list; i < map_size; i++, entry++) { - phys_addr_t start = entry->addr; - phys_addr_t end = start + entry->size; + phys_addr_t end = entry->addr + entry->size; - if (start < last) - start = last; + if (entry->type == E820_RAM || i == map_size - 1) { + unsigned long start_pfn = PFN_DOWN(start); + unsigned long end_pfn = PFN_UP(end); - if (end <= start) - continue; + if (entry->type == E820_RAM) + end_pfn = PFN_UP(entry->addr); - /* Skip over the 1MB region. */ - if (last > end) - continue; + if (start_pfn < end_pfn) { + if (start_pfn < nr_pages) + released += xen_release_chunk( + start_pfn, min(end_pfn, nr_pages)); - if ((entry->type == E820_RAM) || (entry->type == E820_UNUSABLE)) { - if (start > start_pci) identity += set_phys_range_identity( - PFN_UP(start_pci), PFN_DOWN(start)); - - /* Without saving 'last' we would gooble RAM too - * at the end of the loop. */ - last = end; - start_pci = end; - continue; + start_pfn, end_pfn); + } + start = end; } - start_pci = min(start, start_pci); - last = end; } - if (last > start_pci) - identity += set_phys_range_identity( - PFN_UP(start_pci), PFN_DOWN(last)); - return identity; + + printk(KERN_INFO "Released %lu pages of unused memory\n", released); + printk(KERN_INFO "Set %ld page(s) to 1-1 mapping\n", identity); + + return released; } static unsigned long __init xen_get_max_pages(void) @@ -232,7 +205,6 @@ char * __init xen_memory_setup(void) struct xen_memory_map memmap; unsigned long max_pages; unsigned long extra_pages = 0; - unsigned long identity_pages = 0; int i; int op; @@ -265,8 +237,13 @@ char * __init xen_memory_setup(void) if (max_pages > max_pfn) extra_pages += max_pages - max_pfn; - xen_released_pages = xen_return_unused_memory(max_pfn, map, - memmap.nr_entries); + /* + * Set P2M for all non-RAM pages and E820 gaps to be identity + * type PFNs. Any RAM pages that would be made inaccesible by + * this are first released. + */ + xen_released_pages = xen_set_identity_and_release( + map, memmap.nr_entries, max_pfn); extra_pages += xen_released_pages; /* @@ -312,10 +289,6 @@ char * __init xen_memory_setup(void) * In domU, the ISA region is normal, usable memory, but we * reserve ISA memory anyway because too many things poke * about in there. - * - * In Dom0, the host E820 information can leave gaps in the - * ISA range, which would cause us to release those pages. To - * avoid this, we unconditionally reserve them here. */ e820_add_region(ISA_START_ADDRESS, ISA_END_ADDRESS - ISA_START_ADDRESS, E820_RESERVED); @@ -332,12 +305,6 @@ char * __init xen_memory_setup(void) sanitize_e820_map(e820.map, ARRAY_SIZE(e820.map), &e820.nr_map); - /* - * Set P2M for all non-RAM pages and E820 gaps to be identity - * type PFNs. - */ - identity_pages = xen_set_identity(e820.map, e820.nr_map); - printk(KERN_INFO "Set %ld page(s) to 1-1 mapping.\n", identity_pages); return "Xen"; } -- 1.7.2.5 _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel From xen-devel-bounces@lists.xensource.com Thu Sep 29 04:29:05 2011 Return-path: <xen-devel-bounces@lists.xensource.com> Envelope-to: www-data@lists.xensource.com Delivery-date: Thu, 29 Sep 2011 04:29:05 -0700 Received: from localhost ([127.0.0.1] helo=lists.colo.xensource.com) by lists.xensource.com with esmtp (Exim 4.43) id 1R9EnZ-0006ae-EH; Thu, 29 Sep 2011 04:29:05 -0700 Received: from mail216.messagelabs.com ([85.158.143.99]) by lists.xensource.com with esmtp (Exim 4.43) id 1R9EmO-00068N-N0 for xen-devel@lists.xensource.com; Thu, 29 Sep 2011 04:27:53 -0700 X-Env-Sender: david.vrabel@citrix.com X-Msg-Ref: server-9.tower-216.messagelabs.com!1317295668!20003873!1 X-Originating-IP: [66.165.176.89] X-StarScan-Version: 6.4.1; banners=-,-,- X-VirusChecked: Checked Received: (qmail 25536 invoked from network); 29 Sep 2011 11:27:49 -0000 Received: from smtp.citrix.com (HELO SMTP.CITRIX.COM) (66.165.176.89) by server-9.tower-216.messagelabs.com with RC4-SHA encrypted SMTP; 29 Sep 2011 11:27:49 -0000 X-IronPort-AV: E=Sophos;i="4.68,460,1312171200"; d="scan'208";a="17802528" Received: from ftlpmailmx01.citrite.net ([10.13.107.65]) by FTLPIPO01.CITRIX.COM with ESMTP/TLS/RC4-MD5; 29 Sep 2011 07:27:48 -0400 Received: from [10.80.2.76] (10.80.2.76) by FTLPMAILMX01.citrite.net (10.13.107.65) with Microsoft SMTP Server id 8.3.137.0; Thu, 29 Sep 2011 07:27:48 -0400 Message-ID: <4E845685.9080701@citrix.com> Date: Thu, 29 Sep 2011 12:29:09 +0100 From: David Vrabel <david.vrabel@citrix.com> User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.1.16) Gecko/20110818 Icedove/3.0.11 MIME-Version: 1.0 To: David Vrabel <david.vrabel@citrix.com> Subject: Re: [Xen-devel] [PATCH] xen: release all pages within 1-1 p2m mappings References: <1317228396-8870-5-git-send-email-david.vrabel@citrix.com> <1317294517-12614-1-git-send-email-david.vrabel@citrix.com> In-Reply-To: <1317294517-12614-1-git-send-email-david.vrabel@citrix.com> Content-Type: text/plain; charset="ISO-8859-1" Content-Transfer-Encoding: 7bit Cc: xen-devel@lists.xensource.com, Konrad Rzeszutek Wilk <konrad.wilk@oracle.com> X-BeenThere: xen-devel@lists.xensource.com X-Mailman-Version: 2.1.5 Precedence: list List-Id: Xen developer discussion <xen-devel.lists.xensource.com> List-Unsubscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe> List-Post: <mailto:xen-devel@lists.xensource.com> List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help> List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=subscribe> Sender: xen-devel-bounces@lists.xensource.com Errors-To: xen-devel-bounces@lists.xensource.com Er. This was the wrong patch. I meant to repost "xen: allow extra memory to be in multiple regions" to remove unnecessary test of E820_UNUSABLE in xen_align_and_add_e820_region(). Sorry. David On 29/09/11 12:08, David Vrabel wrote: > From: David Vrabel <david.vrabel@citrix.com> > > In xen_memory_setup() all reserved regions and gaps are set to an > identity (1-1) p2m mapping. If an available page has a PFN within one > of these 1-1 mappings it will become inaccessible (as it MFN is lost) > so release them before setting up the mapping. > > [...] _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel From xen-devel-bounces@lists.xensource.com Thu Sep 29 04:30:11 2011 Return-path: <xen-devel-bounces@lists.xensource.com> Envelope-to: www-data@lists.xensource.com Delivery-date: Thu, 29 Sep 2011 04:30:11 -0700 Received: from localhost ([127.0.0.1] helo=lists.colo.xensource.com) by lists.xensource.com with esmtp (Exim 4.43) id 1R9Eod-0006xd-Oy; Thu, 29 Sep 2011 04:30:11 -0700 Received: from mail182.messagelabs.com ([85.158.139.83]) by lists.xensource.com with esmtp (Exim 4.43) id 1R9Enx-0006hb-Lf for xen-devel@lists.xensource.com; Thu, 29 Sep 2011 04:29:30 -0700 X-Env-Sender: Ian.Campbell@eu.citrix.com X-Msg-Ref: server-6.tower-182.messagelabs.com!1317295766!19013085!1 X-Originating-IP: [62.200.22.115] X-StarScan-Version: 6.4.1; banners=-,-,- X-VirusChecked: Checked Received: (qmail 31621 invoked from network); 29 Sep 2011 11:29:26 -0000 Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115) by server-6.tower-182.messagelabs.com with RC4-SHA encrypted SMTP; 29 Sep 2011 11:29:26 -0000 X-IronPort-AV: E=Sophos;i="4.68,460,1312156800"; d="scan'208";a="8125405" Received: from lonpmailmx01.citrite.net ([10.30.203.162]) by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5; 29 Sep 2011 11:29:26 +0000 Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net (10.30.203.162) with Microsoft SMTP Server id 8.3.137.0; Thu, 29 Sep 2011 12:29:26 +0100 Subject: Re: [Xen-devel] Xen document day (Oct 12 or 26) From: Ian Campbell <Ian.Campbell@eu.citrix.com> To: Joseph Glanville <joseph.glanville@orionvm.com.au>, Lars Kurth <lars.kurth@xen.org> Date: Thu, 29 Sep 2011 12:29:25 +0100 In-Reply-To: <CAOzFzEhNZbnm0mr1-mSU+4em3Kd930qOjmApbAZQ+3MAhskhfw@mail.gmail.com> References: <20110922130618.GA13238@phenom.oracle.com> <CAFLBxZaAaXTUtW5+VkxPnr_MR0fbW+d1Mzu4y0x=gEOaX9e0OQ@mail.gmail.com> <20110922174002.GA1205@phenom.oracle.com> <20098.1097.824552.541924@mariner.uk.xensource.com> <CAP2B85-=CbMgUGSwO2utvkeLLqk8A1vjhKrPwe2OD+0daAtqsA@mail.gmail.com> <1317195656.13424.73.camel@dagon.hellion.org.uk> <20099.8327.326129.357335@mariner.uk.xensource.com> <20110928134800.GH10270@phenom.oracle.com> <1317218459.26672.62.camel@zakaz.uk.xensource.com> <CAOzFzEhnr7Ri42V1AUMLw-xRn+9NQwu8Pkq8iPc=pS12w=Vnog@mail.gmail.com> <1317294104.26672.155.camel@zakaz.uk.xensource.com> <CAOzFzEhNZbnm0mr1-mSU+4em3Kd930qOjmApbAZQ+3MAhskhfw@mail.gmail.com> Organization: Citrix Systems, Inc. Content-Type: text/plain; charset="UTF-8" X-Mailer: Evolution 3.0.3- Content-Transfer-Encoding: 7bit Message-ID: <1317295766.26672.169.camel@zakaz.uk.xensource.com> MIME-Version: 1.0 Cc: Daniel Castro <evil.dani@gmail.com>, "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>, Ian Jackson <Ian.Jackson@eu.citrix.com>, Konrad Rzeszutek Wilk <konrad.wilk@oracle.com> X-BeenThere: xen-devel@lists.xensource.com X-Mailman-Version: 2.1.5 Precedence: list List-Id: Xen developer discussion <xen-devel.lists.xensource.com> List-Unsubscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe> List-Post: <mailto:xen-devel@lists.xensource.com> List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help> List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=subscribe> Sender: xen-devel-bounces@lists.xensource.com Errors-To: xen-devel-bounces@lists.xensource.com On Thu, 2011-09-29 at 12:24 +0100, Joseph Glanville wrote: > Maybe the wiki frontpage etc needs abit of a restructure to highlight > the newer documentation and try steer people away from old stuff? > I am going to try do some tagging of the wiki pages tonight to mark > what is out of date. > Many of the pages I think just need simplification.. the current wiki > is somewhat of an information overload (which is fine but we shouldn't > bombard new users if we can avoid it) I think Lars (now CC'd) is planning a switch to a new wiki platform since the current one is very long in the tooth and not especially capable. AIUI part of the transfer will involve discarding out of date stuff and better categorisation of correct/up-to-date pages etc. I'm not sure how the timescales for that transition compare with this documentathon though... Ian. > On 29 September 2011 21:01, Ian Campbell <Ian.Campbell@eu.citrix.com> > wrote: > On Thu, 2011-09-29 at 11:53 +0100, Joseph Glanville wrote: > > +1 for Markdown. > > > > In terms of making Xen more accessible I think it might be a > good idea > > to update/cleanup the distro support page. > > http://wiki.xen.org/xenwiki/DistributionSupport > > > > I can probably do this. > > > Excellent, it looks like it needs it... > > > Making it simple for people to get started with Xen on a > distro they > > are comfortable with is a good step forward. > > > Agreed. In fact for many users this is probably the end goal, > not just a > step along the way. > > > I know distro specific guides could turn into a nightmare > but I am > > open to writing one for Debian 6 Squeeze, > > > In cases such as this we should also consider updating the > distro's wiki > page. I'm not sure where the canonical guide should live > (wiki.xen.org > or wiki.debian.org) but they should certainly cross reference > each > other. > > Yeah that's a tricky one, I guess we can start at wiki.xen.org and go > from there. > Seeing as Debian repackages Xen, wiki.debian.org should probably be > the final canonical location. > > > > > there are also a few that exist already for RHEL/CentOS on > the wiki. > > This should get easier as more distros update to 3.0+ > kernels that > > support PVops out of the box... > > > > Next would be networking documentation as network-bridge > script has > > been deprecated. > > http://wiki.xensource.com/xenwiki/XenNetworking > > Once again I think alot of the documentation is going to be > distro > > specific to be newbie friendly but atleast a simple ip/brctl > guide > > would help. > > > > IMO knowing where to start and setting up networking were > the biggest > > barriers when I was picking up Xen a few years back. > > > We now have > http://wiki.xensource.com/xenwiki/HostConfiguration/Networking > which > could do with being made more discoverable. > > That is -much- better and as you said should be much easier to find.. > > > There is also > http://wiki.xensource.com/xenwiki/HostConfiguration but > its looking pretty sad right now... > > I can think of some stuff to fill that up. > eg. Howto enable live migration, local VM storage guide possibly > > > > > > > I am also open to updating the blktap2 pages and README to > reflect the > > new tap-ctl userspace utilities and tips on driver > development. > > > > <slightly off-topic but related> > > > > With jailtime.org(stacklet) now charging for subscription > there is > > nowhere to download pre-built clean Xen compatible images > free of > > charge etc. > > I have pvgrub/pygrub capable images of Ubuntu/Debian/CentOS > that I am > > considering hosting for free. > > Generally new users are confused on how to build new > paravirt VMs, I > > think prebuilt images are suboptimal but a good place to > start for > > beginners. > > > There was discussion of Debian providing such a thing on > debian-deval > back in late July, I should chase that up really. > > Cheers, > Ian. > > > > > > Joseph. > > > > On 29 September 2011 00:00, Ian Campbell > <Ian.Campbell@eu.citrix.com> > > wrote: > > On Wed, 2011-09-28 at 14:48 +0100, Konrad Rzeszutek > Wilk > > wrote: > > > On Wed, Sep 28, 2011 at 02:26:31PM +0100, Ian > Jackson wrote: > > > > Ian Campbell writes ("Re: [Xen-devel] Xen > document day > > (Oct 12 or 26)"): > > > > > Since the guest APIs are stable there should > be > > relatively little churn > > > > > so perhaps a wiki page (or even series of > pages) would > > be appropriate > > > > > for this sort of thing? > > > > > > > > I want this to be in-tree. If it's in-tree, we > can refuse > > patches > > > > which do not update the documentation. > > > > > > > > > I think this would be good too and in fact > even more > > important than the > > > > > interface documentation. Everyone needs to be > able to > > build Xen to hack > > > > > on it but only a subset need to know any > particular API. > > > > > > > > > > Also although we recommend that users consume > Xen via > > their distro where > > > > > possible such a guide would also help any who > would > > rather build from > > > > > scratch (e.g. because we've asked them to "try > the > > latest version" or to > > > > > bisect a bug etc). > > > > > > > > This would be a good candidate for a wiki page, > backed up > > by revisions > > > > of the in-tree README. > > > > > > > > > Any recommendations on what would be a good format > to write > > these "interface" > > > pages in? > > > > > > For in-line (i.e. in xen/include/public/*.h) docs of > APIs I > > played a > > little bit with integrating kernel-doc into the Xen > build > > system but it > > is tied a little too closely to the kernel build > > infrastructure. > > > > Doxygen seems like a plausible alternative with life > outside > > the kernel > > etc. We actually appear to already have some doxygen > stuff for > > the > > pytyhon stuff (judging from the Makefile, I've not > actually > > noticed the > > structured code comments anywhere) > > > > For non-inline docs I think we decided that markdown > would be > > a good > > answer. > > > > Ian. > > > > > > > > _______________________________________________ > > Xen-devel mailing list > > Xen-devel@lists.xensource.com > > http://lists.xensource.com/xen-devel > > > > > > > > > > -- > > Founder | Director | VP Research > > > > Orion Virtualisation Solutions | www.orionvm.com.au | Phone: > 1300 56 > > 99 52 | Mobile: 0428 754 846 > > > > > > > -- > Founder | Director | VP Research > > Orion Virtualisation Solutions | www.orionvm.com.au | Phone: 1300 56 > 99 52 | Mobile: 0428 754 846 _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel From xen-devel-bounces@lists.xensource.com Thu Sep 29 04:31:23 2011 Return-path: <xen-devel-bounces@lists.xensource.com> Envelope-to: www-data@lists.xensource.com Delivery-date: Thu, 29 Sep 2011 04:31:23 -0700 Received: from localhost ([127.0.0.1] helo=lists.colo.xensource.com) by lists.xensource.com with esmtp (Exim 4.43) id 1R9Epn-0007KW-NO; Thu, 29 Sep 2011 04:31:23 -0700 Received: from mail21.messagelabs.com ([85.158.143.35]) by lists.xensource.com with esmtp (Exim 4.43) id 1R9EpC-00077i-U7 for xen-devel@lists.xensource.com; Thu, 29 Sep 2011 04:30:47 -0700 X-Env-Sender: Ian.Campbell@eu.citrix.com X-Msg-Ref: server-9.tower-21.messagelabs.com!1317295798!50281486!1 X-Originating-IP: [62.200.22.115] X-StarScan-Version: 6.4.1; banners=-,-,- X-VirusChecked: Checked Received: (qmail 10502 invoked from network); 29 Sep 2011 11:29:58 -0000 Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115) by server-9.tower-21.messagelabs.com with RC4-SHA encrypted SMTP; 29 Sep 2011 11:29:58 -0000 X-IronPort-AV: E=Sophos;i="4.68,460,1312156800"; d="scan'208";a="8125447" Received: from lonpmailmx01.citrite.net ([10.30.203.162]) by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5; 29 Sep 2011 11:30:43 +0000 Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net (10.30.203.162) with Microsoft SMTP Server id 8.3.137.0; Thu, 29 Sep 2011 12:30:43 +0100 Subject: Re: [Xen-devel] Debug event_channel.c From: Ian Campbell <Ian.Campbell@eu.citrix.com> To: Daniel Castro <evil.dani@gmail.com> Date: Thu, 29 Sep 2011 12:30:43 +0100 In-Reply-To: <CAP2B85_1j_-0kxMSYheFYVD9Qn0-eUxeuyyo92u5bahn_6yQMw@mail.gmail.com> References: <CAP2B85-QBczrKLWSKaRVBkao3=6PB=wnYvuKmoXYqGDbZFnTXA@mail.gmail.com> <4E81B46F.5080208@citrix.com> <CAP2B85_2L2jkRMqbD6OCRXXaPR1nXV3RmRgcLo2zTTuSLDq5_g@mail.gmail.com> <1317125353.26672.25.camel@zakaz.uk.xensource.com> <CAP2B85_1j_-0kxMSYheFYVD9Qn0-eUxeuyyo92u5bahn_6yQMw@mail.gmail.com> Organization: Citrix Systems, Inc. Content-Type: text/plain; charset="UTF-8" X-Mailer: Evolution 3.0.3- Content-Transfer-Encoding: 7bit Message-ID: <1317295843.26672.170.camel@zakaz.uk.xensource.com> MIME-Version: 1.0 Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com> X-BeenThere: xen-devel@lists.xensource.com X-Mailman-Version: 2.1.5 Precedence: list List-Id: Xen developer discussion <xen-devel.lists.xensource.com> List-Unsubscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe> List-Post: <mailto:xen-devel@lists.xensource.com> List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help> List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=subscribe> Sender: xen-devel-bounces@lists.xensource.com Errors-To: xen-devel-bounces@lists.xensource.com On Thu, 2011-09-29 at 12:09 +0100, Daniel Castro wrote: > On Tue, Sep 27, 2011 at 9:09 PM, Ian Campbell <Ian.Campbell@citrix.com> wrote: > > On Tue, 2011-09-27 at 12:36 +0100, Daniel Castro wrote: > >> On Tue, Sep 27, 2011 at 8:33 PM, Andrew Cooper > >> <andrew.cooper3@citrix.com> wrote: > >> > On 27/09/11 12:09, Daniel Castro wrote: > >> >> Hello All, > >> >> > >> >> I am trying to debug event_channel.c for this I have filled the > >> >> functions with gdprintk(XENLOG_WARNING, "..."); yet the messages are > >> >> not displayed on dmesg or /var/log/xen. Where could they be printed? > >> >> or should I use a different function? > >> >> > >> >> In grub I have loglvl=all to print all messages... > >> >> > >> >> Thanks for the answer, > >> >> > >> >> Daniel > >> >> > >> > > >> > gdprintk only gets set with guest debugging enabled. ( guest_loglvl on > >> > the command line ) > >> > > >> > My suggestion would be to just use regular printks and look at the > >> > serial log. > >> > >> How can can I look at the serial log from dom0? > > > > 'xl dmesg' (or using a serial cable of course ;-)) > > > > You can also add XENCONSOLED_TRACE=hv in /etc/sysconfig/xencommons (or > > the equivalent on your distro, the effect should be to add --log=hv to > > the xenconsoled command line). Then the xen console will be logged > > under /var/log/xen somewhere. > > Ian, thanks for the info. > > This is the info I gathered: > (XEN) schedule.c:658:d1 DEBUG 1: START DO POLL port -32060 on > sched_poll.nr_ports 1 port == -32060 doesn't sound right... > (XEN) schedule.c:719:d1 DEBUG 1: DO POLL test bit on port 2 exit here > -> if ( test_bit(port, &shared_info(d, evtchn_pending)) ) > (XEN) schedule.c:746:d1 DEBUG 1: DO POLL GOTO out: check previus msg, > return rc=0 > (XEN) event_channel.c:606:d1 DEBUG 1: set_pending > (XEN) event_channel.c:628:d1 DEBUG 1 : evtchn_set_pending test_bit AND > test_and_set_bit returned 0. > (XEN) event_channel.c:637:d1 DEBUG 1: evtchn_set_pending bitmap_empty return 0. > > In my code test_bit_and_clear in Xenstore ring_wait is in fact > returning 0, it was expecting a one, the do_poll is finding the bit in > 1 also according to test_bit, right? > So the error is on the my test_bit_and_clear. Am I reading it correctly? I'm not sure I follow what your debug messages are actually saying, but if do_poll is exiting because of the if ( test_bit(port, &shared_info(d, evtchn_pending)) ) goto out; inside the "for ( i = 0; i < sched_poll->nr_ports; i++ )" loop then this indicates that the event channel is pending. If you aren't seeing this on the guest end then there is likely a problem somewhere on that end. In your current ring_wait function you have: int wait = test_and_clear_bit(event, shinfo->evtchn_pending); int ret = 1; while (wait!=0 || ret!=0){ ret = hypercall_sched_op(SCHEDOP_poll, &poll); wait = test_and_clear_bit(event, shinfo->evtchn_pending); struct vcpu_info *vcpu = shinfo->vcpu_info; dprintf(1,"DEBUG bit clear is %d and ret %d\n",wait,ret); time = shinfo->vcpu_info[0].time; dprintf(1,"TIME system %d timestamp %d\n",time.system_time,time.tsc_timestamp); } } Isn't "wait!=0" backwards? Don't you want to succeed (i.e. fall out of the loop) when wait!=0 rather than keep looping? Ian. > > Thanks all, > > Daniel > > > > Ian. > > > >> > >> > > >> > -- > >> > Andrew Cooper - Dom0 Kernel Engineer, Citrix XenServer > >> > T: +44 (0)1223 225 900, http://www.citrix.com > >> > > >> > > >> > _______________________________________________ > >> > Xen-devel mailing list > >> > Xen-devel@lists.xensource.com > >> > http://lists.xensource.com/xen-devel > >> > > >> > >> > >> > > > > > > > > > _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel From xen-devel-bounces@lists.xensource.com Thu Sep 29 04:36:45 2011 Return-path: <xen-devel-bounces@lists.xensource.com> Envelope-to: www-data@lists.xensource.com Delivery-date: Thu, 29 Sep 2011 04:36:45 -0700 Received: from localhost ([127.0.0.1] helo=lists.colo.xensource.com) by lists.xensource.com with esmtp (Exim 4.43) id 1R9Euz-0007sF-0I; Thu, 29 Sep 2011 04:36:45 -0700 Received: from mail21.messagelabs.com ([85.158.143.35]) by lists.xensource.com with esmtp (Exim 4.43) id 1R9Eu3-0007fX-Iw for xen-devel@lists.xensource.com; Thu, 29 Sep 2011 04:35:49 -0700 X-Env-Sender: joseph.glanville@orionvm.com.au X-Msg-Ref: server-2.tower-21.messagelabs.com!1317296141!35961255!1 X-Originating-IP: [209.85.210.171] X-StarScan-Version: 6.4.1; banners=-,-,- X-VirusChecked: Checked Received: (qmail 22471 invoked from network); 29 Sep 2011 11:35:42 -0000 Received: from mail-iy0-f171.google.com (HELO mail-iy0-f171.google.com) (209.85.210.171) by server-2.tower-21.messagelabs.com with RC4-SHA encrypted SMTP; 29 Sep 2011 11:35:42 -0000 Received: by iagv1 with SMTP id v1so824439iag.30 for <xen-devel@lists.xensource.com>; Thu, 29 Sep 2011 04:35:42 -0700 (PDT) MIME-Version: 1.0 Received: by 10.43.53.66 with SMTP id vp2mr684377icb.92.1317296142464; Thu, 29 Sep 2011 04:35:42 -0700 (PDT) Received: by 10.231.170.15 with HTTP; Thu, 29 Sep 2011 04:35:42 -0700 (PDT) X-Originating-IP: [59.167.234.130] In-Reply-To: <1317295766.26672.169.camel@zakaz.uk.xensource.com> References: <20110922130618.GA13238@phenom.oracle.com> <CAFLBxZaAaXTUtW5+VkxPnr_MR0fbW+d1Mzu4y0x=gEOaX9e0OQ@mail.gmail.com> <20110922174002.GA1205@phenom.oracle.com> <20098.1097.824552.541924@mariner.uk.xensource.com> <CAP2B85-=CbMgUGSwO2utvkeLLqk8A1vjhKrPwe2OD+0daAtqsA@mail.gmail.com> <1317195656.13424.73.camel@dagon.hellion.org.uk> <20099.8327.326129.357335@mariner.uk.xensource.com> <20110928134800.GH10270@phenom.oracle.com> <1317218459.26672.62.camel@zakaz.uk.xensource.com> <CAOzFzEhnr7Ri42V1AUMLw-xRn+9NQwu8Pkq8iPc=pS12w=Vnog@mail.gmail.com> <1317294104.26672.155.camel@zakaz.uk.xensource.com> <CAOzFzEhNZbnm0mr1-mSU+4em3Kd930qOjmApbAZQ+3MAhskhfw@mail.gmail.com> <1317295766.26672.169.camel@zakaz.uk.xensource.com> Date: Thu, 29 Sep 2011 21:35:42 +1000 Message-ID: <CAOzFzEg8xJ9F9iohq3SP4n7xwyQkm42BQtTyNYc5v2CT0GvZqg@mail.gmail.com> Subject: Re: [Xen-devel] Xen document day (Oct 12 or 26) From: Joseph Glanville <joseph.glanville@orionvm.com.au> To: Ian Campbell <Ian.Campbell@eu.citrix.com> Cc: Daniel Castro <evil.dani@gmail.com>, Lars Kurth <lars.kurth@xen.org>, Ian Jackson <Ian.Jackson@eu.citrix.com>, "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>, Konrad Rzeszutek Wilk <konrad.wilk@oracle.com> X-BeenThere: xen-devel@lists.xensource.com X-Mailman-Version: 2.1.5 Precedence: list List-Id: Xen developer discussion <xen-devel.lists.xensource.com> List-Unsubscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe> List-Post: <mailto:xen-devel@lists.xensource.com> List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help> List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=subscribe> Content-Type: multipart/mixed; boundary="===============1386169766==" Sender: xen-devel-bounces@lists.xensource.com Errors-To: xen-devel-bounces@lists.xensource.com --===============1386169766== Content-Type: multipart/alternative; boundary=bcaec5299ff5a2b63004ae12e8e2 --bcaec5299ff5a2b63004ae12e8e2 Content-Type: text/plain; charset=ISO-8859-1 Yeah MoinMoin is abit frustrating.. I am currently going through the pages in the TitleIndex: http://wiki.xen.org/xenwiki/TitleIndex Marking pages as out-dated as a find them.. maybe it would be best to create a google spreadsheet and mark their status in there to ease finding what content is good vs bad? How does that sound Lars/Ian? Joseph. On 29 September 2011 21:29, Ian Campbell <Ian.Campbell@eu.citrix.com> wrote: > On Thu, 2011-09-29 at 12:24 +0100, Joseph Glanville wrote: > > Maybe the wiki frontpage etc needs abit of a restructure to highlight > > the newer documentation and try steer people away from old stuff? > > I am going to try do some tagging of the wiki pages tonight to mark > > what is out of date. > > Many of the pages I think just need simplification.. the current wiki > > is somewhat of an information overload (which is fine but we shouldn't > > bombard new users if we can avoid it) > > I think Lars (now CC'd) is planning a switch to a new wiki platform > since the current one is very long in the tooth and not especially > capable. AIUI part of the transfer will involve discarding out of date > stuff and better categorisation of correct/up-to-date pages etc. > > I'm not sure how the timescales for that transition compare with this > documentathon though... > > Ian. > > > On 29 September 2011 21:01, Ian Campbell <Ian.Campbell@eu.citrix.com> > > wrote: > > On Thu, 2011-09-29 at 11:53 +0100, Joseph Glanville wrote: > > > +1 for Markdown. > > > > > > In terms of making Xen more accessible I think it might be a > > good idea > > > to update/cleanup the distro support page. > > > http://wiki.xen.org/xenwiki/DistributionSupport > > > > > > I can probably do this. > > > > > > Excellent, it looks like it needs it... > > > > > Making it simple for people to get started with Xen on a > > distro they > > > are comfortable with is a good step forward. > > > > > > Agreed. In fact for many users this is probably the end goal, > > not just a > > step along the way. > > > > > I know distro specific guides could turn into a nightmare > > but I am > > > open to writing one for Debian 6 Squeeze, > > > > > > In cases such as this we should also consider updating the > > distro's wiki > > page. I'm not sure where the canonical guide should live > > (wiki.xen.org > > or wiki.debian.org) but they should certainly cross reference > > each > > other. > > > > Yeah that's a tricky one, I guess we can start at wiki.xen.org and go > > from there. > > Seeing as Debian repackages Xen, wiki.debian.org should probably be > > the final canonical location. > > > > > > > > > there are also a few that exist already for RHEL/CentOS on > > the wiki. > > > This should get easier as more distros update to 3.0+ > > kernels that > > > support PVops out of the box... > > > > > > Next would be networking documentation as network-bridge > > script has > > > been deprecated. > > > http://wiki.xensource.com/xenwiki/XenNetworking > > > Once again I think alot of the documentation is going to be > > distro > > > specific to be newbie friendly but atleast a simple ip/brctl > > guide > > > would help. > > > > > > IMO knowing where to start and setting up networking were > > the biggest > > > barriers when I was picking up Xen a few years back. > > > > > > We now have > > http://wiki.xensource.com/xenwiki/HostConfiguration/Networking > > which > > could do with being made more discoverable. > > > > That is -much- better and as you said should be much easier to find.. > > > > > > There is also > > http://wiki.xensource.com/xenwiki/HostConfiguration but > > its looking pretty sad right now... > > > > I can think of some stuff to fill that up. > > eg. Howto enable live migration, local VM storage guide possibly > > > > > > > > > > > > I am also open to updating the blktap2 pages and README to > > reflect the > > > new tap-ctl userspace utilities and tips on driver > > development. > > > > > > <slightly off-topic but related> > > > > > > With jailtime.org(stacklet) now charging for subscription > > there is > > > nowhere to download pre-built clean Xen compatible images > > free of > > > charge etc. > > > I have pvgrub/pygrub capable images of Ubuntu/Debian/CentOS > > that I am > > > considering hosting for free. > > > Generally new users are confused on how to build new > > paravirt VMs, I > > > think prebuilt images are suboptimal but a good place to > > start for > > > beginners. > > > > > > There was discussion of Debian providing such a thing on > > debian-deval > > back in late July, I should chase that up really. > > > > Cheers, > > Ian. > > > > > > > > > > Joseph. > > > > > > On 29 September 2011 00:00, Ian Campbell > > <Ian.Campbell@eu.citrix.com> > > > wrote: > > > On Wed, 2011-09-28 at 14:48 +0100, Konrad Rzeszutek > > Wilk > > > wrote: > > > > On Wed, Sep 28, 2011 at 02:26:31PM +0100, Ian > > Jackson wrote: > > > > > Ian Campbell writes ("Re: [Xen-devel] Xen > > document day > > > (Oct 12 or 26)"): > > > > > > Since the guest APIs are stable there should > > be > > > relatively little churn > > > > > > so perhaps a wiki page (or even series of > > pages) would > > > be appropriate > > > > > > for this sort of thing? > > > > > > > > > > I want this to be in-tree. If it's in-tree, we > > can refuse > > > patches > > > > > which do not update the documentation. > > > > > > > > > > > I think this would be good too and in fact > > even more > > > important than the > > > > > > interface documentation. Everyone needs to be > > able to > > > build Xen to hack > > > > > > on it but only a subset need to know any > > particular API. > > > > > > > > > > > > Also although we recommend that users consume > > Xen via > > > their distro where > > > > > > possible such a guide would also help any who > > would > > > rather build from > > > > > > scratch (e.g. because we've asked them to "try > > the > > > latest version" or to > > > > > > bisect a bug etc). > > > > > > > > > > This would be a good candidate for a wiki page, > > backed up > > > by revisions > > > > > of the in-tree README. > > > > > > > > > > > > Any recommendations on what would be a good format > > to write > > > these "interface" > > > > pages in? > > > > > > > > > For in-line (i.e. in xen/include/public/*.h) docs of > > APIs I > > > played a > > > little bit with integrating kernel-doc into the Xen > > build > > > system but it > > > is tied a little too closely to the kernel build > > > infrastructure. > > > > > > Doxygen seems like a plausible alternative with life > > outside > > > the kernel > > > etc. We actually appear to already have some doxygen > > stuff for > > > the > > > pytyhon stuff (judging from the Makefile, I've not > > actually > > > noticed the > > > structured code comments anywhere) > > > > > > For non-inline docs I think we decided that markdown > > would be > > > a good > > > answer. > > > > > > Ian. > > > > > > > > > > > > _______________________________________________ > > > Xen-devel mailing list > > > Xen-devel@lists.xensource.com > > > http://lists.xensource.com/xen-devel > > > > > > > > > > > > > > > -- > > > Founder | Director | VP Research > > > > > > Orion Virtualisation Solutions | www.orionvm.com.au | Phone: > > 1300 56 > > > 99 52 | Mobile: 0428 754 846 > > > > > > > > > > > > > > -- > > Founder | Director | VP Research > > > > Orion Virtualisation Solutions | www.orionvm.com.au | Phone: 1300 56 > > 99 52 | Mobile: 0428 754 846 > > > -- * Founder | Director | VP Research Orion Virtualisation Solutions* | www.orionvm.com.au | Phone: 1300 56 99 52 | Mobile: 0428 754 846 --bcaec5299ff5a2b63004ae12e8e2 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Yeah MoinMoin is abit frustrating.. I am currently going through the pages = in the TitleIndex:<br><a href=3D"http://wiki.xen.org/xenwiki/TitleIndex">ht= tp://wiki.xen.org/xenwiki/TitleIndex</a><br>Marking pages as out-dated as a= find them.. maybe it would be best to create a google spreadsheet and mark= their status in there to ease finding what content is good vs bad?<br> How does that sound Lars/Ian?<br><br>Joseph.<br><br><div class=3D"gmail_quo= te">On 29 September 2011 21:29, Ian Campbell <span dir=3D"ltr"><<a href= =3D"mailto:Ian.Campbell@eu.citrix.com">Ian.Campbell@eu.citrix.com</a>></= span> wrote:<br> <blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1p= x #ccc solid;padding-left:1ex;"><div class=3D"im">On Thu, 2011-09-29 at 12:= 24 +0100, Joseph Glanville wrote:<br> > Maybe the wiki frontpage etc needs abit of a restructure to highlight<= br> > the newer documentation and try steer people away from old stuff?<br> > I am going to try do some tagging of the wiki pages tonight to mark<br= > > what is out of date.<br> > Many of the pages I think just need simplification.. the current wiki<= br> > is somewhat of an information overload (which is fine but we shouldn&#= 39;t<br> > bombard new users if we can avoid it)<br> <br> </div>I think Lars (now CC'd) is planning a switch to a new wiki platfo= rm<br> since the current one is very long in the tooth and not especially<br> capable. AIUI part of the transfer will involve discarding out of date<br> stuff and better categorisation of correct/up-to-date pages etc.<br> <br> I'm not sure how the timescales for that transition compare with this<b= r> documentathon though...<br> <font color=3D"#888888"><br> Ian.<br> </font><div><div></div><div class=3D"h5"><br> > On 29 September 2011 21:01, Ian Campbell <<a href=3D"mailto:Ian.Cam= pbell@eu.citrix.com">Ian.Campbell@eu.citrix.com</a>><br> > wrote:<br> > =A0 =A0 =A0 =A0 On Thu, 2011-09-29 at 11:53 +0100, Joseph Glanville wr= ote:<br> > =A0 =A0 =A0 =A0 > +1 for Markdown.<br> > =A0 =A0 =A0 =A0 ><br> > =A0 =A0 =A0 =A0 > In terms of making Xen more accessible I think it= might be a<br> > =A0 =A0 =A0 =A0 good idea<br> > =A0 =A0 =A0 =A0 > to update/cleanup the distro support page.<br> > =A0 =A0 =A0 =A0 > <a href=3D"http://wiki.xen.org/xenwiki/Distributi= onSupport" target=3D"_blank">http://wiki.xen.org/xenwiki/DistributionSuppor= t</a><br> > =A0 =A0 =A0 =A0 ><br> > =A0 =A0 =A0 =A0 > I can probably do this.<br> ><br> ><br> > =A0 =A0 =A0 =A0 Excellent, it looks like it needs it...<br> ><br> > =A0 =A0 =A0 =A0 > Making it simple for people to get started with X= en on a<br> > =A0 =A0 =A0 =A0 distro they<br> > =A0 =A0 =A0 =A0 > are comfortable with is a good step forward.<br> ><br> ><br> > =A0 =A0 =A0 =A0 Agreed. In fact for many users this is probably the en= d goal,<br> > =A0 =A0 =A0 =A0 not just a<br> > =A0 =A0 =A0 =A0 step along the way.<br> ><br> > =A0 =A0 =A0 =A0 > I know distro specific guides could turn into a n= ightmare<br> > =A0 =A0 =A0 =A0 but I am<br> > =A0 =A0 =A0 =A0 > open to writing one for Debian 6 Squeeze,<br> ><br> ><br> > =A0 =A0 =A0 =A0 In cases such as this we should also consider updating= the<br> > =A0 =A0 =A0 =A0 distro's wiki<br> > =A0 =A0 =A0 =A0 page. I'm not sure where the canonical guide shoul= d live<br> > =A0 =A0 =A0 =A0 (<a href=3D"http://wiki.xen.org" target=3D"_blank">wik= i.xen.org</a><br> > =A0 =A0 =A0 =A0 or <a href=3D"http://wiki.debian.org" target=3D"_blank= ">wiki.debian.org</a>) but they should certainly cross reference<br> > =A0 =A0 =A0 =A0 each<br> > =A0 =A0 =A0 =A0 other.<br> ><br> > Yeah that's a tricky one, I guess we can start at <a href=3D"http:= //wiki.xen.org" target=3D"_blank">wiki.xen.org</a> and go<br> > from there.<br> > Seeing as Debian repackages Xen, <a href=3D"http://wiki.debian.org" ta= rget=3D"_blank">wiki.debian.org</a> should probably be<br> > the final canonical location.<br> ><br> ><br> ><br> > =A0 =A0 =A0 =A0 > =A0there are also a few that exist already for RH= EL/CentOS on<br> > =A0 =A0 =A0 =A0 the wiki.<br> > =A0 =A0 =A0 =A0 > This should get easier as more distros update to = 3.0+<br> > =A0 =A0 =A0 =A0 kernels that<br> > =A0 =A0 =A0 =A0 > support PVops out of the box...<br> > =A0 =A0 =A0 =A0 ><br> > =A0 =A0 =A0 =A0 > Next would be networking documentation as network= -bridge<br> > =A0 =A0 =A0 =A0 script has<br> > =A0 =A0 =A0 =A0 > been deprecated.<br> > =A0 =A0 =A0 =A0 > <a href=3D"http://wiki.xensource.com/xenwiki/XenN= etworking" target=3D"_blank">http://wiki.xensource.com/xenwiki/XenNetworkin= g</a><br> > =A0 =A0 =A0 =A0 > Once again I think alot of the documentation is g= oing to be<br> > =A0 =A0 =A0 =A0 distro<br> > =A0 =A0 =A0 =A0 > specific to be newbie friendly but atleast a simp= le ip/brctl<br> > =A0 =A0 =A0 =A0 guide<br> > =A0 =A0 =A0 =A0 > would help.<br> > =A0 =A0 =A0 =A0 ><br> > =A0 =A0 =A0 =A0 > IMO knowing where to start and setting up network= ing were<br> > =A0 =A0 =A0 =A0 the biggest<br> > =A0 =A0 =A0 =A0 > barriers when I was picking up Xen a few years ba= ck.<br> ><br> ><br> > =A0 =A0 =A0 =A0 We now have<br> > =A0 =A0 =A0 =A0 <a href=3D"http://wiki.xensource.com/xenwiki/HostConfi= guration/Networking" target=3D"_blank">http://wiki.xensource.com/xenwiki/Ho= stConfiguration/Networking</a><br> > =A0 =A0 =A0 =A0 which<br> > =A0 =A0 =A0 =A0 could do with being made more discoverable.<br> ><br> > That is -much- better and as you said should be much easier to find..<= br> ><br> ><br> > =A0 =A0 =A0 =A0 There is also<br> > =A0 =A0 =A0 =A0 <a href=3D"http://wiki.xensource.com/xenwiki/HostConfi= guration" target=3D"_blank">http://wiki.xensource.com/xenwiki/HostConfigura= tion</a> but<br> > =A0 =A0 =A0 =A0 its looking pretty sad right now...<br> ><br> > I can think of some stuff to fill that up.<br> > eg. Howto enable live migration, local VM storage guide possibly<br> ><br> ><br> ><br> > =A0 =A0 =A0 =A0 ><br> > =A0 =A0 =A0 =A0 > I am also open to updating the blktap2 pages and = README to<br> > =A0 =A0 =A0 =A0 reflect the<br> > =A0 =A0 =A0 =A0 > new tap-ctl userspace utilities and tips on drive= r<br> > =A0 =A0 =A0 =A0 development.<br> > =A0 =A0 =A0 =A0 ><br> > =A0 =A0 =A0 =A0 > <slightly off-topic but related><br> > =A0 =A0 =A0 =A0 ><br> > =A0 =A0 =A0 =A0 > With <a href=3D"http://jailtime.org" target=3D"_b= lank">jailtime.org</a>(stacklet) now charging for subscription<br> > =A0 =A0 =A0 =A0 there is<br> > =A0 =A0 =A0 =A0 > nowhere to download pre-built clean Xen compatibl= e images<br> > =A0 =A0 =A0 =A0 free of<br> > =A0 =A0 =A0 =A0 > charge etc.<br> > =A0 =A0 =A0 =A0 > I have pvgrub/pygrub capable images of Ubuntu/Deb= ian/CentOS<br> > =A0 =A0 =A0 =A0 that I am<br> > =A0 =A0 =A0 =A0 > considering hosting for free.<br> > =A0 =A0 =A0 =A0 > Generally new users are confused on how to build = new<br> > =A0 =A0 =A0 =A0 paravirt VMs, I<br> > =A0 =A0 =A0 =A0 > think prebuilt images are suboptimal but a good p= lace to<br> > =A0 =A0 =A0 =A0 start for<br> > =A0 =A0 =A0 =A0 > beginners.<br> ><br> ><br> > =A0 =A0 =A0 =A0 There was discussion of Debian providing such a thing = on<br> > =A0 =A0 =A0 =A0 debian-deval<br> > =A0 =A0 =A0 =A0 back in late July, I should chase that up really.<br> ><br> > =A0 =A0 =A0 =A0 Cheers,<br> > =A0 =A0 =A0 =A0 Ian.<br> ><br> ><br> > =A0 =A0 =A0 =A0 ><br> > =A0 =A0 =A0 =A0 > Joseph.<br> > =A0 =A0 =A0 =A0 ><br> > =A0 =A0 =A0 =A0 > On 29 September 2011 00:00, Ian Campbell<br> > =A0 =A0 =A0 =A0 <<a href=3D"mailto:Ian.Campbell@eu.citrix.com">Ian.= Campbell@eu.citrix.com</a>><br> > =A0 =A0 =A0 =A0 > wrote:<br> > =A0 =A0 =A0 =A0 > =A0 =A0 =A0 =A0 On Wed, 2011-09-28 at 14:48 +0100= , Konrad Rzeszutek<br> > =A0 =A0 =A0 =A0 Wilk<br> > =A0 =A0 =A0 =A0 > =A0 =A0 =A0 =A0 wrote:<br> > =A0 =A0 =A0 =A0 > =A0 =A0 =A0 =A0 > On Wed, Sep 28, 2011 at 02:2= 6:31PM +0100, Ian<br> > =A0 =A0 =A0 =A0 Jackson wrote:<br> > =A0 =A0 =A0 =A0 > =A0 =A0 =A0 =A0 > > Ian Campbell writes (&q= uot;Re: [Xen-devel] Xen<br> > =A0 =A0 =A0 =A0 document day<br> > =A0 =A0 =A0 =A0 > =A0 =A0 =A0 =A0 (Oct 12 or 26)"):<br> > =A0 =A0 =A0 =A0 > =A0 =A0 =A0 =A0 > > > Since the guest AP= Is are stable there should<br> > =A0 =A0 =A0 =A0 be<br> > =A0 =A0 =A0 =A0 > =A0 =A0 =A0 =A0 relatively little churn<br> > =A0 =A0 =A0 =A0 > =A0 =A0 =A0 =A0 > > > so perhaps a wiki = page (or even series of<br> > =A0 =A0 =A0 =A0 pages) would<br> > =A0 =A0 =A0 =A0 > =A0 =A0 =A0 =A0 be appropriate<br> > =A0 =A0 =A0 =A0 > =A0 =A0 =A0 =A0 > > > for this sort of t= hing?<br> > =A0 =A0 =A0 =A0 > =A0 =A0 =A0 =A0 > ><br> > =A0 =A0 =A0 =A0 > =A0 =A0 =A0 =A0 > > I want this to be in-tr= ee. =A0If it's in-tree, we<br> > =A0 =A0 =A0 =A0 can refuse<br> > =A0 =A0 =A0 =A0 > =A0 =A0 =A0 =A0 patches<br> > =A0 =A0 =A0 =A0 > =A0 =A0 =A0 =A0 > > which do not update the= documentation.<br> > =A0 =A0 =A0 =A0 > =A0 =A0 =A0 =A0 > ><br> > =A0 =A0 =A0 =A0 > =A0 =A0 =A0 =A0 > > > I think this would= be good too and in fact<br> > =A0 =A0 =A0 =A0 even more<br> > =A0 =A0 =A0 =A0 > =A0 =A0 =A0 =A0 important than the<br> > =A0 =A0 =A0 =A0 > =A0 =A0 =A0 =A0 > > > interface document= ation. Everyone needs to be<br> > =A0 =A0 =A0 =A0 able to<br> > =A0 =A0 =A0 =A0 > =A0 =A0 =A0 =A0 build Xen to hack<br> > =A0 =A0 =A0 =A0 > =A0 =A0 =A0 =A0 > > > on it but only a s= ubset need to know any<br> > =A0 =A0 =A0 =A0 particular API.<br> > =A0 =A0 =A0 =A0 > =A0 =A0 =A0 =A0 > > ><br> > =A0 =A0 =A0 =A0 > =A0 =A0 =A0 =A0 > > > Also although we r= ecommend that users consume<br> > =A0 =A0 =A0 =A0 Xen via<br> > =A0 =A0 =A0 =A0 > =A0 =A0 =A0 =A0 their distro where<br> > =A0 =A0 =A0 =A0 > =A0 =A0 =A0 =A0 > > > possible such a gu= ide would also help any who<br> > =A0 =A0 =A0 =A0 would<br> > =A0 =A0 =A0 =A0 > =A0 =A0 =A0 =A0 rather build from<br> > =A0 =A0 =A0 =A0 > =A0 =A0 =A0 =A0 > > > scratch (e.g. beca= use we've asked them to "try<br> > =A0 =A0 =A0 =A0 the<br> > =A0 =A0 =A0 =A0 > =A0 =A0 =A0 =A0 latest version" or to<br> > =A0 =A0 =A0 =A0 > =A0 =A0 =A0 =A0 > > > bisect a bug etc).= <br> > =A0 =A0 =A0 =A0 > =A0 =A0 =A0 =A0 > ><br> > =A0 =A0 =A0 =A0 > =A0 =A0 =A0 =A0 > > This would be a good ca= ndidate for a wiki page,<br> > =A0 =A0 =A0 =A0 backed up<br> > =A0 =A0 =A0 =A0 > =A0 =A0 =A0 =A0 by revisions<br> > =A0 =A0 =A0 =A0 > =A0 =A0 =A0 =A0 > > of the in-tree README.<= br> > =A0 =A0 =A0 =A0 > =A0 =A0 =A0 =A0 ><br> > =A0 =A0 =A0 =A0 > =A0 =A0 =A0 =A0 ><br> > =A0 =A0 =A0 =A0 > =A0 =A0 =A0 =A0 > Any recommendations on what = would be a good format<br> > =A0 =A0 =A0 =A0 to write<br> > =A0 =A0 =A0 =A0 > =A0 =A0 =A0 =A0 these "interface"<br> > =A0 =A0 =A0 =A0 > =A0 =A0 =A0 =A0 > pages in?<br> > =A0 =A0 =A0 =A0 ><br> > =A0 =A0 =A0 =A0 ><br> > =A0 =A0 =A0 =A0 > =A0 =A0 =A0 =A0 For in-line (i.e. in xen/include/= public/*.h) docs of<br> > =A0 =A0 =A0 =A0 APIs I<br> > =A0 =A0 =A0 =A0 > =A0 =A0 =A0 =A0 played a<br> > =A0 =A0 =A0 =A0 > =A0 =A0 =A0 =A0 little bit with integrating kerne= l-doc into the Xen<br> > =A0 =A0 =A0 =A0 build<br> > =A0 =A0 =A0 =A0 > =A0 =A0 =A0 =A0 system but it<br> > =A0 =A0 =A0 =A0 > =A0 =A0 =A0 =A0 is tied a little too closely to t= he kernel build<br> > =A0 =A0 =A0 =A0 > =A0 =A0 =A0 =A0 infrastructure.<br> > =A0 =A0 =A0 =A0 ><br> > =A0 =A0 =A0 =A0 > =A0 =A0 =A0 =A0 Doxygen seems like a plausible al= ternative with life<br> > =A0 =A0 =A0 =A0 outside<br> > =A0 =A0 =A0 =A0 > =A0 =A0 =A0 =A0 the kernel<br> > =A0 =A0 =A0 =A0 > =A0 =A0 =A0 =A0 etc. We actually appear to alread= y have some doxygen<br> > =A0 =A0 =A0 =A0 stuff for<br> > =A0 =A0 =A0 =A0 > =A0 =A0 =A0 =A0 the<br> > =A0 =A0 =A0 =A0 > =A0 =A0 =A0 =A0 pytyhon stuff (judging from the M= akefile, I've not<br> > =A0 =A0 =A0 =A0 actually<br> > =A0 =A0 =A0 =A0 > =A0 =A0 =A0 =A0 noticed the<br> > =A0 =A0 =A0 =A0 > =A0 =A0 =A0 =A0 structured code comments anywhere= )<br> > =A0 =A0 =A0 =A0 ><br> > =A0 =A0 =A0 =A0 > =A0 =A0 =A0 =A0 For non-inline docs I think we de= cided that markdown<br> > =A0 =A0 =A0 =A0 would be<br> > =A0 =A0 =A0 =A0 > =A0 =A0 =A0 =A0 a good<br> > =A0 =A0 =A0 =A0 > =A0 =A0 =A0 =A0 answer.<br> > =A0 =A0 =A0 =A0 ><br> > =A0 =A0 =A0 =A0 > =A0 =A0 =A0 =A0 Ian.<br> > =A0 =A0 =A0 =A0 ><br> > =A0 =A0 =A0 =A0 ><br> > =A0 =A0 =A0 =A0 ><br> > =A0 =A0 =A0 =A0 > =A0 =A0 =A0 =A0 _________________________________= ______________<br> > =A0 =A0 =A0 =A0 > =A0 =A0 =A0 =A0 Xen-devel mailing list<br> > =A0 =A0 =A0 =A0 > =A0 =A0 =A0 =A0 <a href=3D"mailto:Xen-devel@lists= .xensource.com">Xen-devel@lists.xensource.com</a><br> > =A0 =A0 =A0 =A0 > =A0 =A0 =A0 =A0 <a href=3D"http://lists.xensource= .com/xen-devel" target=3D"_blank">http://lists.xensource.com/xen-devel</a><= br> > =A0 =A0 =A0 =A0 ><br> > =A0 =A0 =A0 =A0 ><br> > =A0 =A0 =A0 =A0 ><br> > =A0 =A0 =A0 =A0 ><br> > =A0 =A0 =A0 =A0 > --<br> > =A0 =A0 =A0 =A0 > Founder | Director | VP Research<br> > =A0 =A0 =A0 =A0 ><br> > =A0 =A0 =A0 =A0 > Orion Virtualisation Solutions | <a href=3D"http:= //www.orionvm.com.au" target=3D"_blank">www.orionvm.com.au</a> | Phone:<br> > =A0 =A0 =A0 =A0 1300 56<br> > =A0 =A0 =A0 =A0 > 99 52 | Mobile: 0428 754 846<br> ><br> ><br> ><br> ><br> ><br> ><br> > --<br> > Founder | Director | VP Research<br> ><br> > Orion Virtualisation Solutions | <a href=3D"http://www.orionvm.com.au"= target=3D"_blank">www.orionvm.com.au</a> | Phone: 1300 56<br> > 99 52 | Mobile: 0428 754 846<br> <br> <br> </div></div></blockquote></div><br><br clear=3D"all"><br>-- <br><span style= =3D"font-family:arial,sans-serif;font-size:13px;border-collapse:collapse"><= b><i><font color=3D"#0000ff"><div><font color=3D"#000000"><span style=3D"fo= nt-style:normal;font-weight:normal">Founder | Director | VP Research<br> </span></font></div>Orion Virtualisation Solutions</font></i></b>=A0|=A0<fo= nt color=3D"#0000ff"><a href=3D"http://www.orionvm.com.au/" style=3D"color:= rgb(42, 93, 176)" target=3D"_blank">www.orionvm.com.au</a></font>=A0| Phone= : 1300 56 99 52 | Mobile: 0428 754 846</span><br> --bcaec5299ff5a2b63004ae12e8e2-- --===============1386169766== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel --===============1386169766==-- From xen-devel-bounces@lists.xensource.com Thu Sep 29 04:39:23 2011 Return-path: <xen-devel-bounces@lists.xensource.com> Envelope-to: www-data@lists.xensource.com Delivery-date: Thu, 29 Sep 2011 04:39:23 -0700 Received: from localhost ([127.0.0.1] helo=lists.colo.xensource.com) by lists.xensource.com with esmtp (Exim 4.43) id 1R9ExX-0008Sk-Lm; Thu, 29 Sep 2011 04:39:23 -0700 Received: from mail174.messagelabs.com ([85.158.138.51]) by lists.xensource.com with esmtp (Exim 4.43) id 1R9EwZ-000897-8d for xen-devel@lists.xensource.com; Thu, 29 Sep 2011 04:38:23 -0700 X-Env-Sender: anthony.perard@citrix.com X-Msg-Ref: server-2.tower-174.messagelabs.com!1317296298!33226833!1 X-Originating-IP: [66.165.176.63] X-StarScan-Version: 6.4.1; banners=-,-,- X-VirusChecked: Checked Received: (qmail 5080 invoked from network); 29 Sep 2011 11:38:20 -0000 Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63) by server-2.tower-174.messagelabs.com with RC4-SHA encrypted SMTP; 29 Sep 2011 11:38:20 -0000 X-IronPort-AV: E=Sophos;i="4.68,460,1312171200"; d="scan'208";a="165111953" Received: from ftlpmailmx01.citrite.net ([10.13.107.65]) by FTLPIPO02.CITRIX.COM with ESMTP/TLS/RC4-MD5; 29 Sep 2011 07:38:18 -0400 Received: from smtp01.ad.xensource.com (10.219.128.104) by smtprelay.citrix.com (10.13.107.65) with Microsoft SMTP Server id 8.3.137.0; Thu, 29 Sep 2011 07:38:18 -0400 Received: from perard.uk.xensource.com (dhcp-3-28.uk.xensource.com [10.80.3.28] (may be forged)) by smtp01.ad.xensource.com (8.13.1/8.13.1) with ESMTP id p8TBc6sb025574; Thu, 29 Sep 2011 04:38:17 -0700 From: Anthony PERARD <anthony.perard@citrix.com> To: Xen Devel <xen-devel@lists.xensource.com> Date: Thu, 29 Sep 2011 12:37:51 +0100 Message-ID: <1317296277-2838-2-git-send-email-anthony.perard@citrix.com> X-Mailer: git-send-email 1.7.2.5 In-Reply-To: <1317296277-2838-1-git-send-email-anthony.perard@citrix.com> References: <1317296277-2838-1-git-send-email-anthony.perard@citrix.com> MIME-Version: 1.0 Content-Type: text/plain Cc: Ian Campbell <Ian.Campbell@eu.citrix.com>, Anthony PERARD <anthony.perard@citrix.com>, Stefano Stabellini <stefano.stabellini@eu.citrix.com> Subject: [Xen-devel] [PATCH V9 1/7] libxl: Rename libxl.idl to libxl_types.idl. X-BeenThere: xen-devel@lists.xensource.com X-Mailman-Version: 2.1.5 Precedence: list List-Id: Xen developer discussion <xen-devel.lists.xensource.com> List-Unsubscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe> List-Post: <mailto:xen-devel@lists.xensource.com> List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help> List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=subscribe> Sender: xen-devel-bounces@lists.xensource.com Errors-To: xen-devel-bounces@lists.xensource.com Signed-off-by: Anthony PERARD <anthony.perard@citrix.com> Acked-by: Ian Campbell <ian.campbell@citrix.com> --- tools/libxl/Makefile | 12 ++++++------ tools/libxl/{libxl.idl => libxl_types.idl} | 0 tools/ocaml/libs/xl/Makefile | 4 ++-- tools/python/Makefile | 4 ++-- 4 files changed, 10 insertions(+), 10 deletions(-) rename tools/libxl/{libxl.idl => libxl_types.idl} (100%) diff --git a/tools/libxl/Makefile b/tools/libxl/Makefile index 3eeb26f..330ee6e 100644 --- a/tools/libxl/Makefile +++ b/tools/libxl/Makefile @@ -52,8 +52,8 @@ $(XL_OBJS): CFLAGS += $(CFLAGS_libxenctrl) # For xentoollog.h $(XL_OBJS): CFLAGS += $(CFLAGS_libxenlight) testidl.o: CFLAGS += $(CFLAGS_libxenctrl) $(CFLAGS_libxenlight) -testidl.c: libxl.idl gentest.py libxl.h - $(PYTHON) gentest.py libxl.idl testidl.c.new +testidl.c: libxl_types.idl gentest.py libxl.h + $(PYTHON) gentest.py libxl_types.idl testidl.c.new mv testidl.c.new testidl.c .PHONY: all @@ -84,10 +84,10 @@ libxl.h: _libxl_types.h $(LIBXL_OBJS) $(LIBXLU_OBJS) $(XL_OBJS): libxl.h -_libxl_%.h _libxl_%.c: libxl.idl gen%.py libxl%.py - $(PYTHON) gen$*.py libxl.idl __libxl_$*.h __libxl_$*.c - $(call move-if-changed,__libxl_$*.h,_libxl_$*.h) - $(call move-if-changed,__libxl_$*.c,_libxl_$*.c) +_libxl_type%.h _libxl_type%.c: libxl_type%.idl gentypes.py libxltypes.py + $(PYTHON) gentypes.py libxl_type$*.idl __libxl_type$*.h __libxl_type$*.c + $(call move-if-changed,__libxl_type$*.h,_libxl_type$*.h) + $(call move-if-changed,__libxl_type$*.c,_libxl_type$*.c) libxenlight.so: libxenlight.so.$(MAJOR) ln -sf $< $@ diff --git a/tools/libxl/libxl.idl b/tools/libxl/libxl_types.idl similarity index 100% rename from tools/libxl/libxl.idl rename to tools/libxl/libxl_types.idl diff --git a/tools/ocaml/libs/xl/Makefile b/tools/ocaml/libs/xl/Makefile index 342dc35..a1e79a5 100644 --- a/tools/ocaml/libs/xl/Makefile +++ b/tools/ocaml/libs/xl/Makefile @@ -45,10 +45,10 @@ xl.mli: xl.mli.in _libxl_types.mli.in < xl.mli.in > xl.mli.tmp $(Q)mv xl.mli.tmp xl.mli -_libxl_types.ml.in _libxl_types.mli.in _libxl_types.inc: genwrap.py $(XEN_ROOT)/tools/libxl/libxl.idl \ +_libxl_types.ml.in _libxl_types.mli.in _libxl_types.inc: genwrap.py $(XEN_ROOT)/tools/libxl/libxl_types.idl \ $(XEN_ROOT)/tools/libxl/libxltypes.py PYTHONPATH=$(XEN_ROOT)/tools/libxl $(PYTHON) genwrap.py \ - $(XEN_ROOT)/tools/libxl/libxl.idl \ + $(XEN_ROOT)/tools/libxl/libxl_types.idl \ _libxl_types.mli.in _libxl_types.ml.in _libxl_types.inc libs: $(LIBS) diff --git a/tools/python/Makefile b/tools/python/Makefile index de44178..b7bc501 100644 --- a/tools/python/Makefile +++ b/tools/python/Makefile @@ -10,10 +10,10 @@ genpath-target = $(call buildmakevars2file,$(XENPATH)) $(eval $(genpath-target)) .PHONY: build -build: genpath genwrap.py $(XEN_ROOT)/tools/libxl/libxl.idl \ +build: genpath genwrap.py $(XEN_ROOT)/tools/libxl/libxl_types.idl \ $(XEN_ROOT)/tools/libxl/libxltypes.py PYTHONPATH=$(XEN_ROOT)/tools/libxl $(PYTHON) genwrap.py \ - $(XEN_ROOT)/tools/libxl/libxl.idl \ + $(XEN_ROOT)/tools/libxl/libxl_types.idl \ xen/lowlevel/xl/_pyxl_types.h \ xen/lowlevel/xl/_pyxl_types.c CC="$(CC)" CFLAGS="$(CFLAGS)" $(PYTHON) setup.py build -- Anthony PERARD _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel From xen-devel-bounces@lists.xensource.com Thu Sep 29 04:40:53 2011 Return-path: <xen-devel-bounces@lists.xensource.com> Envelope-to: www-data@lists.xensource.com Delivery-date: Thu, 29 Sep 2011 04:40:53 -0700 Received: from localhost ([127.0.0.1] helo=lists.colo.xensource.com) by lists.xensource.com with esmtp (Exim 4.43) id 1R9Eyy-0000QJ-QY; Thu, 29 Sep 2011 04:40:52 -0700 Received: from mail174.messagelabs.com ([85.158.138.51]) by lists.xensource.com with esmtp (Exim 4.43) id 1R9Ewa-00089D-FQ for xen-devel@lists.xensource.com; Thu, 29 Sep 2011 04:38:24 -0700 X-Env-Sender: anthony.perard@citrix.com X-Msg-Ref: server-2.tower-174.messagelabs.com!1317296298!33226833!2 X-Originating-IP: [66.165.176.63] X-StarScan-Version: 6.4.1; banners=-,-,- X-VirusChecked: Checked Received: (qmail 5163 invoked from network); 29 Sep 2011 11:38:21 -0000 Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63) by server-2.tower-174.messagelabs.com with RC4-SHA encrypted SMTP; 29 Sep 2011 11:38:21 -0000 X-IronPort-AV: E=Sophos;i="4.68,460,1312171200"; d="scan'208";a="165111955" Received: from ftlpmailmx01.citrite.net ([10.13.107.65]) by FTLPIPO02.CITRIX.COM with ESMTP/TLS/RC4-MD5; 29 Sep 2011 07:38:20 -0400 Received: from smtp01.ad.xensource.com (10.219.128.104) by smtprelay.citrix.com (10.13.107.65) with Microsoft SMTP Server id 8.3.137.0; Thu, 29 Sep 2011 07:38:20 -0400 Received: from perard.uk.xensource.com (dhcp-3-28.uk.xensource.com [10.80.3.28] (may be forged)) by smtp01.ad.xensource.com (8.13.1/8.13.1) with ESMTP id p8TBc6sd025574; Thu, 29 Sep 2011 04:38:19 -0700 From: Anthony PERARD <anthony.perard@citrix.com> To: Xen Devel <xen-devel@lists.xensource.com> Date: Thu, 29 Sep 2011 12:37:53 +0100 Message-ID: <1317296277-2838-4-git-send-email-anthony.perard@citrix.com> X-Mailer: git-send-email 1.7.2.5 In-Reply-To: <1317296277-2838-1-git-send-email-anthony.perard@citrix.com> References: <1317296277-2838-1-git-send-email-anthony.perard@citrix.com> MIME-Version: 1.0 Content-Type: text/plain Cc: Ian Campbell <Ian.Campbell@eu.citrix.com>, Anthony PERARD <anthony.perard@citrix.com>, Stefano Stabellini <stefano.stabellini@eu.citrix.com> Subject: [Xen-devel] [PATCH V9 3/7] libxl: Introduce libxl_internal_types.idl. X-BeenThere: xen-devel@lists.xensource.com X-Mailman-Version: 2.1.5 Precedence: list List-Id: Xen developer discussion <xen-devel.lists.xensource.com> List-Unsubscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe> List-Post: <mailto:xen-devel@lists.xensource.com> List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help> List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=subscribe> Sender: xen-devel-bounces@lists.xensource.com Errors-To: xen-devel-bounces@lists.xensource.com Signed-off-by: Anthony PERARD <anthony.perard@citrix.com> Acked-by: Ian Campbell <ian.campbell@citrix.com> --- tools/libxl/Makefile | 4 +++- tools/libxl/gentypes.py | 9 +++++---- tools/libxl/libxl_internal.h | 1 + tools/libxl/libxl_types_internal.idl | 9 +++++++++ 4 files changed, 18 insertions(+), 5 deletions(-) create mode 100644 tools/libxl/libxl_types_internal.idl diff --git a/tools/libxl/Makefile b/tools/libxl/Makefile index 330ee6e..1f6b418 100644 --- a/tools/libxl/Makefile +++ b/tools/libxl/Makefile @@ -35,7 +35,7 @@ LIBXL_OBJS-$(CONFIG_IA64) += libxl_nocpuid.o LIBXL_OBJS = flexarray.o libxl.o libxl_create.o libxl_dm.o libxl_pci.o \ libxl_dom.o libxl_exec.o libxl_xshelp.o libxl_device.o \ libxl_internal.o libxl_utils.o libxl_uuid.o $(LIBXL_OBJS-y) -LIBXL_OBJS += _libxl_types.o libxl_flask.o +LIBXL_OBJS += _libxl_types.o libxl_flask.o _libxl_types_internal.o $(LIBXL_OBJS): CFLAGS += $(CFLAGS_libxenctrl) $(CFLAGS_libxenguest) $(CFLAGS_libxenstore) $(CFLAGS_libblktapctl) @@ -81,8 +81,10 @@ _libxl_paths.h: genpath libxl_paths.c: _libxl_paths.h libxl.h: _libxl_types.h +libxl_internal.h: _libxl_types_internal.h $(LIBXL_OBJS) $(LIBXLU_OBJS) $(XL_OBJS): libxl.h +$(LIBXL_OBJS): libxl_internal.h _libxl_type%.h _libxl_type%.c: libxl_type%.idl gentypes.py libxltypes.py $(PYTHON) gentypes.py libxl_type$*.idl __libxl_type$*.h __libxl_type$*.c diff --git a/tools/libxl/gentypes.py b/tools/libxl/gentypes.py index c66a33c..ecf5f15 100644 --- a/tools/libxl/gentypes.py +++ b/tools/libxl/gentypes.py @@ -150,8 +150,9 @@ if __name__ == '__main__': f = open(header, "w") - f.write("""#ifndef __LIBXL_TYPES_H -#define __LIBXL_TYPES_H + header_define = header.upper().replace('.','_') + f.write("""#ifndef %s +#define %s /* * DO NOT EDIT. @@ -160,7 +161,7 @@ if __name__ == '__main__': * "%s" */ -""" % " ".join(sys.argv)) +""" % (header_define, header_define, " ".join(sys.argv))) for ty in types: f.write(libxl_C_type_define(ty) + ";\n") @@ -172,7 +173,7 @@ if __name__ == '__main__': f.write("extern libxl_enum_string_table %s_string_table[];\n" % (ty.typename)) f.write("\n") - f.write("""#endif /* __LIBXL_TYPES_H */\n""") + f.write("""#endif /* %s */\n""" % (header_define)) f.close() print "outputting libxl type implementations to %s" % impl diff --git a/tools/libxl/libxl_internal.h b/tools/libxl/libxl_internal.h index b431632..29cdba4 100644 --- a/tools/libxl/libxl_internal.h +++ b/tools/libxl/libxl_internal.h @@ -35,6 +35,7 @@ #include "flexarray.h" #include "libxl_utils.h" +#include "_libxl_types_internal.h" #define LIBXL_DESTROY_TIMEOUT 10 #define LIBXL_DEVICE_MODEL_START_TIMEOUT 10 diff --git a/tools/libxl/libxl_types_internal.idl b/tools/libxl/libxl_types_internal.idl new file mode 100644 index 0000000..20236a6 --- /dev/null +++ b/tools/libxl/libxl_types_internal.idl @@ -0,0 +1,9 @@ +namespace("libxl__") + +libxl__qmp_message_type = Enumeration("qmp_message_type", [ + (1, "QMP"), + (2, "return"), + (3, "error"), + (4, "event"), + (5, "invalid"), + ]) -- Anthony PERARD _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel From xen-devel-bounces@lists.xensource.com Thu Sep 29 04:41:55 2011 Return-path: <xen-devel-bounces@lists.xensource.com> Envelope-to: www-data@lists.xensource.com Delivery-date: Thu, 29 Sep 2011 04:41:55 -0700 Received: from localhost ([127.0.0.1] helo=lists.colo.xensource.com) by lists.xensource.com with esmtp (Exim 4.43) id 1R9Ezz-0000nT-0l; Thu, 29 Sep 2011 04:41:55 -0700 Received: from mail174.messagelabs.com ([85.158.138.51]) by lists.xensource.com with esmtp (Exim 4.43) id 1R9Ewc-00089J-W0 for xen-devel@lists.xensource.com; Thu, 29 Sep 2011 04:38:27 -0700 X-Env-Sender: anthony.perard@citrix.com X-Msg-Ref: server-2.tower-174.messagelabs.com!1317296298!33226833!3 X-Originating-IP: [66.165.176.63] X-StarScan-Version: 6.4.1; banners=-,-,- X-VirusChecked: Checked Received: (qmail 5281 invoked from network); 29 Sep 2011 11:38:23 -0000 Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63) by server-2.tower-174.messagelabs.com with RC4-SHA encrypted SMTP; 29 Sep 2011 11:38:23 -0000 X-IronPort-AV: E=Sophos;i="4.68,460,1312171200"; d="scan'208";a="165111959" Received: from ftlpmailmx01.citrite.net ([10.13.107.65]) by FTLPIPO02.CITRIX.COM with ESMTP/TLS/RC4-MD5; 29 Sep 2011 07:38:23 -0400 Received: from smtp01.ad.xensource.com (10.219.128.104) by smtprelay.citrix.com (10.13.107.65) with Microsoft SMTP Server id 8.3.137.0; Thu, 29 Sep 2011 07:38:23 -0400 Received: from perard.uk.xensource.com (dhcp-3-28.uk.xensource.com [10.80.3.28] (may be forged)) by smtp01.ad.xensource.com (8.13.1/8.13.1) with ESMTP id p8TBc6sf025574; Thu, 29 Sep 2011 04:38:21 -0700 From: Anthony PERARD <anthony.perard@citrix.com> To: Xen Devel <xen-devel@lists.xensource.com> Date: Thu, 29 Sep 2011 12:37:55 +0100 Message-ID: <1317296277-2838-6-git-send-email-anthony.perard@citrix.com> X-Mailer: git-send-email 1.7.2.5 In-Reply-To: <1317296277-2838-1-git-send-email-anthony.perard@citrix.com> References: <1317296277-2838-1-git-send-email-anthony.perard@citrix.com> MIME-Version: 1.0 Content-Type: text/plain Cc: Ian Campbell <Ian.Campbell@eu.citrix.com>, Anthony PERARD <anthony.perard@citrix.com>, Stefano Stabellini <stefano.stabellini@eu.citrix.com> Subject: [Xen-devel] [PATCH V9 5/7] libxl: Intruduce libxl__strndup. X-BeenThere: xen-devel@lists.xensource.com X-Mailman-Version: 2.1.5 Precedence: list List-Id: Xen developer discussion <xen-devel.lists.xensource.com> List-Unsubscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe> List-Post: <mailto:xen-devel@lists.xensource.com> List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help> List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=subscribe> Sender: xen-devel-bounces@lists.xensource.com Errors-To: xen-devel-bounces@lists.xensource.com Signed-off-by: Anthony PERARD <anthony.perard@citrix.com> Acked-by: Ian Campbell <ian.campbell@citrix.com> --- tools/libxl/libxl_internal.c | 10 ++++++++++ tools/libxl/libxl_internal.h | 1 + 2 files changed, 11 insertions(+), 0 deletions(-) diff --git a/tools/libxl/libxl_internal.c b/tools/libxl/libxl_internal.c index c4d54f9..0fb2315 100644 --- a/tools/libxl/libxl_internal.c +++ b/tools/libxl/libxl_internal.c @@ -159,6 +159,16 @@ char *libxl__strdup(libxl__gc *gc, const char *c) return s; } +char *libxl__strndup(libxl__gc *gc, const char *c, size_t n) +{ + char *s = strndup(c, n); + + if (s) + libxl__ptr_add(gc, s); + + return s; +} + char *libxl__dirname(libxl__gc *gc, const char *s) { char *c; diff --git a/tools/libxl/libxl_internal.h b/tools/libxl/libxl_internal.h index 343c11b..6ec402e 100644 --- a/tools/libxl/libxl_internal.h +++ b/tools/libxl/libxl_internal.h @@ -148,6 +148,7 @@ _hidden void *libxl__calloc(libxl__gc *gc, size_t nmemb, size_t size); _hidden void *libxl__realloc(libxl__gc *gc, void *ptr, size_t new_size); _hidden char *libxl__sprintf(libxl__gc *gc, const char *fmt, ...) PRINTF_ATTRIBUTE(2, 3); _hidden char *libxl__strdup(libxl__gc *gc, const char *c); +_hidden char *libxl__strndup(libxl__gc *gc, const char *c, size_t n); _hidden char *libxl__dirname(libxl__gc *gc, const char *s); _hidden char **libxl__xs_kvs_of_flexarray(libxl__gc *gc, flexarray_t *array, int length); -- Anthony PERARD _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel From xen-devel-bounces@lists.xensource.com Thu Sep 29 04:42:58 2011 Return-path: <xen-devel-bounces@lists.xensource.com> Envelope-to: www-data@lists.xensource.com Delivery-date: Thu, 29 Sep 2011 04:42:58 -0700 Received: from localhost ([127.0.0.1] helo=lists.colo.xensource.com) by lists.xensource.com with esmtp (Exim 4.43) id 1R9F10-0001AW-0Z; Thu, 29 Sep 2011 04:42:58 -0700 Received: from mail21.messagelabs.com ([85.158.143.35]) by lists.xensource.com with esmtp (Exim 4.43) id 1R9Ewf-00089l-BW for xen-devel@lists.xensource.com; Thu, 29 Sep 2011 04:38:29 -0700 X-Env-Sender: anthony.perard@citrix.com X-Msg-Ref: server-5.tower-21.messagelabs.com!1317296269!49996809!2 X-Originating-IP: [66.165.176.89] X-StarScan-Version: 6.4.1; banners=-,-,- X-VirusChecked: Checked Received: (qmail 17030 invoked from network); 29 Sep 2011 11:37:51 -0000 Received: from smtp.citrix.com (HELO SMTP.CITRIX.COM) (66.165.176.89) by server-5.tower-21.messagelabs.com with RC4-SHA encrypted SMTP; 29 Sep 2011 11:37:51 -0000 X-IronPort-AV: E=Sophos;i="4.68,460,1312171200"; d="scan'208";a="17802739" Received: from ftlpmailmx01.citrite.net ([10.13.107.65]) by FTLPIPO01.CITRIX.COM with ESMTP/TLS/RC4-MD5; 29 Sep 2011 07:38:08 -0400 Received: from smtp01.ad.xensource.com (10.219.128.104) by smtprelay.citrix.com (10.13.107.65) with Microsoft SMTP Server id 8.3.137.0; Thu, 29 Sep 2011 07:38:08 -0400 Received: from perard.uk.xensource.com (dhcp-3-28.uk.xensource.com [10.80.3.28] (may be forged)) by smtp01.ad.xensource.com (8.13.1/8.13.1) with ESMTP id p8TBc6sa025574; Thu, 29 Sep 2011 04:38:06 -0700 From: Anthony PERARD <anthony.perard@citrix.com> To: Xen Devel <xen-devel@lists.xensource.com> Date: Thu, 29 Sep 2011 12:37:50 +0100 Message-ID: <1317296277-2838-1-git-send-email-anthony.perard@citrix.com> X-Mailer: git-send-email 1.7.2.5 MIME-Version: 1.0 Content-Type: text/plain Cc: Ian Campbell <Ian.Campbell@eu.citrix.com>, Anthony PERARD <anthony.perard@citrix.com>, Stefano Stabellini <stefano.stabellini@eu.citrix.com> Subject: [Xen-devel] [PATCH V9 0/7] Introduce a QMP client X-BeenThere: xen-devel@lists.xensource.com X-Mailman-Version: 2.1.5 Precedence: list List-Id: Xen developer discussion <xen-devel.lists.xensource.com> List-Unsubscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe> List-Post: <mailto:xen-devel@lists.xensource.com> List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help> List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=subscribe> Sender: xen-devel-bounces@lists.xensource.com Errors-To: xen-devel-bounces@lists.xensource.com Only the last patch have changed on this series since the v8. Replace of SOCK_NONBLOCK by a call to fcntl in qmp_open(). The rest of the patch have been acked-by Ian Campbell. Anthony PERARD (7): libxl: Rename libxl.idl to libxl_types.idl. libxl: Add get/set_default_namespace in libxltypes.py. libxl: Introduce libxl_internal_types.idl. libxl: Introduce libxl__realloc. libxl: Intruduce libxl__strndup. libxl: Introduce JSON parsing stuff. libxl: Introduce a QMP client README | 1 + tools/libxl/Makefile | 21 +- tools/libxl/gentypes.py | 9 +- tools/libxl/libxl.c | 2 + tools/libxl/libxl_create.c | 4 + tools/libxl/libxl_dm.c | 10 + tools/libxl/libxl_internal.c | 34 ++ tools/libxl/libxl_internal.h | 122 ++++++ tools/libxl/libxl_json.c | 560 ++++++++++++++++++++++++++ tools/libxl/libxl_qmp.c | 595 ++++++++++++++++++++++++++++ tools/libxl/{libxl.idl => libxl_types.idl} | 2 + tools/libxl/libxl_types_internal.idl | 9 + tools/libxl/libxltypes.py | 18 +- tools/ocaml/libs/xl/Makefile | 4 +- tools/python/Makefile | 4 +- 15 files changed, 1377 insertions(+), 18 deletions(-) create mode 100644 tools/libxl/libxl_json.c create mode 100644 tools/libxl/libxl_qmp.c rename tools/libxl/{libxl.idl => libxl_types.idl} (99%) create mode 100644 tools/libxl/libxl_types_internal.idl -- Anthony PERARD _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel From xen-devel-bounces@lists.xensource.com Thu Sep 29 04:44:05 2011 Return-path: <xen-devel-bounces@lists.xensource.com> Envelope-to: www-data@lists.xensource.com Delivery-date: Thu, 29 Sep 2011 04:44:05 -0700 Received: from localhost ([127.0.0.1] helo=lists.colo.xensource.com) by lists.xensource.com with esmtp (Exim 4.43) id 1R9F25-0001Xq-2R; Thu, 29 Sep 2011 04:44:05 -0700 Received: from mail21.messagelabs.com ([85.158.143.35]) by lists.xensource.com with esmtp (Exim 4.43) id 1R9Ewe-00089X-PG for xen-devel@lists.xensource.com; Thu, 29 Sep 2011 04:38:29 -0700 X-Env-Sender: anthony.perard@citrix.com X-Msg-Ref: server-5.tower-21.messagelabs.com!1317296269!49996809!1 X-Originating-IP: [66.165.176.89] X-StarScan-Version: 6.4.1; banners=-,-,- X-VirusChecked: Checked Received: (qmail 17011 invoked from network); 29 Sep 2011 11:37:50 -0000 Received: from smtp.citrix.com (HELO SMTP.CITRIX.COM) (66.165.176.89) by server-5.tower-21.messagelabs.com with RC4-SHA encrypted SMTP; 29 Sep 2011 11:37:50 -0000 X-IronPort-AV: E=Sophos;i="4.68,460,1312171200"; d="scan'208";a="17802741" Received: from ftlpmailmx01.citrite.net ([10.13.107.65]) by FTLPIPO01.CITRIX.COM with ESMTP/TLS/RC4-MD5; 29 Sep 2011 07:38:19 -0400 Received: from smtp01.ad.xensource.com (10.219.128.104) by smtprelay.citrix.com (10.13.107.65) with Microsoft SMTP Server id 8.3.137.0; Thu, 29 Sep 2011 07:38:19 -0400 Received: from perard.uk.xensource.com (dhcp-3-28.uk.xensource.com [10.80.3.28] (may be forged)) by smtp01.ad.xensource.com (8.13.1/8.13.1) with ESMTP id p8TBc6sc025574; Thu, 29 Sep 2011 04:38:18 -0700 From: Anthony PERARD <anthony.perard@citrix.com> To: Xen Devel <xen-devel@lists.xensource.com> Date: Thu, 29 Sep 2011 12:37:52 +0100 Message-ID: <1317296277-2838-3-git-send-email-anthony.perard@citrix.com> X-Mailer: git-send-email 1.7.2.5 In-Reply-To: <1317296277-2838-1-git-send-email-anthony.perard@citrix.com> References: <1317296277-2838-1-git-send-email-anthony.perard@citrix.com> MIME-Version: 1.0 Content-Type: text/plain Cc: Ian Campbell <Ian.Campbell@eu.citrix.com>, Anthony PERARD <anthony.perard@citrix.com>, Stefano Stabellini <stefano.stabellini@eu.citrix.com> Subject: [Xen-devel] [PATCH V9 2/7] libxl: Add get/set_default_namespace in libxltypes.py. X-BeenThere: xen-devel@lists.xensource.com X-Mailman-Version: 2.1.5 Precedence: list List-Id: Xen developer discussion <xen-devel.lists.xensource.com> List-Unsubscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe> List-Post: <mailto:xen-devel@lists.xensource.com> List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help> List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=subscribe> Sender: xen-devel-bounces@lists.xensource.com Errors-To: xen-devel-bounces@lists.xensource.com Signed-off-by: Anthony PERARD <anthony.perard@citrix.com> Acked-by: Ian Campbell <ian.campbell@citrix.com> --- tools/libxl/libxl_types.idl | 2 ++ tools/libxl/libxltypes.py | 18 ++++++++++++++++-- 2 files changed, 18 insertions(+), 2 deletions(-) diff --git a/tools/libxl/libxl_types.idl b/tools/libxl/libxl_types.idl index 5b7e731..0d28283 100644 --- a/tools/libxl/libxl_types.idl +++ b/tools/libxl/libxl_types.idl @@ -3,6 +3,8 @@ # Builtin libxl types # +namespace("libxl_") + libxl_domid = Builtin("domid") libxl_uuid = Builtin("uuid", passby=PASS_BY_REFERENCE) libxl_mac = Builtin("mac", passby=PASS_BY_REFERENCE) diff --git a/tools/libxl/libxltypes.py b/tools/libxl/libxltypes.py index f1a4dcf..86ab4b9 100644 --- a/tools/libxl/libxltypes.py +++ b/tools/libxl/libxltypes.py @@ -8,10 +8,23 @@ DIR_IN = 1 DIR_OUT = 2 DIR_BOTH = 3 +_default_namespace = "" +def namespace(s): + if type(s) != str: + raise TypeError, "Require a string for the default namespace." + global _default_namespace + _default_namespace = s + +def _get_default_namespace(): + global _default_namespace + return _default_namespace + + class Type(object): def __init__(self, typename, **kwargs): self.comment = kwargs.setdefault('comment', None) - self.namespace = kwargs.setdefault('namespace', "libxl_") + self.namespace = kwargs.setdefault('namespace', + _get_default_namespace()) self.dir = kwargs.setdefault('dir', DIR_BOTH) if self.dir not in [DIR_NONE, DIR_IN, DIR_OUT, DIR_BOTH]: raise ValueError @@ -256,7 +269,8 @@ def parse(f): elif isinstance(t,type(object)) and issubclass(t, Type): globs[n] = t elif n in ['PASS_BY_REFERENCE', 'PASS_BY_VALUE', - 'DIR_NONE', 'DIR_IN', 'DIR_OUT', 'DIR_BOTH']: + 'DIR_NONE', 'DIR_IN', 'DIR_OUT', 'DIR_BOTH', + 'namespace']: globs[n] = t try: -- Anthony PERARD _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel From xen-devel-bounces@lists.xensource.com Thu Sep 29 04:45:42 2011 Return-path: <xen-devel-bounces@lists.xensource.com> Envelope-to: www-data@lists.xensource.com Delivery-date: Thu, 29 Sep 2011 04:45:42 -0700 Received: from localhost ([127.0.0.1] helo=lists.colo.xensource.com) by lists.xensource.com with esmtp (Exim 4.43) id 1R9F3d-0001up-Ld; Thu, 29 Sep 2011 04:45:42 -0700 Received: from mail21.messagelabs.com ([85.158.143.35]) by lists.xensource.com with esmtp (Exim 4.43) id 1R9Ewf-00089z-UD for xen-devel@lists.xensource.com; Thu, 29 Sep 2011 04:38:30 -0700 X-Env-Sender: anthony.perard@citrix.com X-Msg-Ref: server-5.tower-21.messagelabs.com!1317296269!49996809!3 X-Originating-IP: [66.165.176.89] X-StarScan-Version: 6.4.1; banners=-,-,- X-VirusChecked: Checked Received: (qmail 17048 invoked from network); 29 Sep 2011 11:37:51 -0000 Received: from smtp.citrix.com (HELO SMTP.CITRIX.COM) (66.165.176.89) by server-5.tower-21.messagelabs.com with RC4-SHA encrypted SMTP; 29 Sep 2011 11:37:51 -0000 X-IronPort-AV: E=Sophos;i="4.68,460,1312171200"; d="scan'208";a="17802742" Received: from ftlpmailmx01.citrite.net ([10.13.107.65]) by FTLPIPO01.CITRIX.COM with ESMTP/TLS/RC4-MD5; 29 Sep 2011 07:38:22 -0400 Received: from smtp01.ad.xensource.com (10.219.128.104) by smtprelay.citrix.com (10.13.107.65) with Microsoft SMTP Server id 8.3.137.0; Thu, 29 Sep 2011 07:38:21 -0400 Received: from perard.uk.xensource.com (dhcp-3-28.uk.xensource.com [10.80.3.28] (may be forged)) by smtp01.ad.xensource.com (8.13.1/8.13.1) with ESMTP id p8TBc6se025574; Thu, 29 Sep 2011 04:38:20 -0700 From: Anthony PERARD <anthony.perard@citrix.com> To: Xen Devel <xen-devel@lists.xensource.com> Date: Thu, 29 Sep 2011 12:37:54 +0100 Message-ID: <1317296277-2838-5-git-send-email-anthony.perard@citrix.com> X-Mailer: git-send-email 1.7.2.5 In-Reply-To: <1317296277-2838-1-git-send-email-anthony.perard@citrix.com> References: <1317296277-2838-1-git-send-email-anthony.perard@citrix.com> MIME-Version: 1.0 Content-Type: text/plain Cc: Ian Campbell <Ian.Campbell@eu.citrix.com>, Anthony PERARD <anthony.perard@citrix.com>, Stefano Stabellini <stefano.stabellini@eu.citrix.com> Subject: [Xen-devel] [PATCH V9 4/7] libxl: Introduce libxl__realloc. X-BeenThere: xen-devel@lists.xensource.com X-Mailman-Version: 2.1.5 Precedence: list List-Id: Xen developer discussion <xen-devel.lists.xensource.com> List-Unsubscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe> List-Post: <mailto:xen-devel@lists.xensource.com> List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help> List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=subscribe> Sender: xen-devel-bounces@lists.xensource.com Errors-To: xen-devel-bounces@lists.xensource.com Signed-off-by: Anthony PERARD <anthony.perard@citrix.com> Acked-by: Ian Campbell <ian.campbell@citrix.com> --- tools/libxl/libxl_internal.c | 24 ++++++++++++++++++++++++ tools/libxl/libxl_internal.h | 1 + 2 files changed, 25 insertions(+), 0 deletions(-) diff --git a/tools/libxl/libxl_internal.c b/tools/libxl/libxl_internal.c index e259278..c4d54f9 100644 --- a/tools/libxl/libxl_internal.c +++ b/tools/libxl/libxl_internal.c @@ -102,6 +102,30 @@ void *libxl__calloc(libxl__gc *gc, size_t nmemb, size_t size) return ptr; } +void *libxl__realloc(libxl__gc *gc, void *ptr, size_t new_size) +{ + void *new_ptr = realloc(ptr, new_size); + int i = 0; + + if (new_ptr == NULL && new_size != 0) { + return NULL; + } + + if (ptr == NULL) { + libxl__ptr_add(gc, new_ptr); + } else if (new_ptr != ptr) { + for (i = 0; i < gc->alloc_maxsize; i++) { + if (gc->alloc_ptrs[i] == ptr) { + gc->alloc_ptrs[i] = new_ptr; + break; + } + } + } + + + return new_ptr; +} + char *libxl__sprintf(libxl__gc *gc, const char *fmt, ...) { char *s; diff --git a/tools/libxl/libxl_internal.h b/tools/libxl/libxl_internal.h index 29cdba4..343c11b 100644 --- a/tools/libxl/libxl_internal.h +++ b/tools/libxl/libxl_internal.h @@ -145,6 +145,7 @@ _hidden int libxl__ptr_add(libxl__gc *gc, void *ptr); _hidden void libxl__free_all(libxl__gc *gc); _hidden void *libxl__zalloc(libxl__gc *gc, int bytes); _hidden void *libxl__calloc(libxl__gc *gc, size_t nmemb, size_t size); +_hidden void *libxl__realloc(libxl__gc *gc, void *ptr, size_t new_size); _hidden char *libxl__sprintf(libxl__gc *gc, const char *fmt, ...) PRINTF_ATTRIBUTE(2, 3); _hidden char *libxl__strdup(libxl__gc *gc, const char *c); _hidden char *libxl__dirname(libxl__gc *gc, const char *s); -- Anthony PERARD _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel From xen-devel-bounces@lists.xensource.com Thu Sep 29 04:46:54 2011 Return-path: <xen-devel-bounces@lists.xensource.com> Envelope-to: www-data@lists.xensource.com Delivery-date: Thu, 29 Sep 2011 04:46:54 -0700 Received: from localhost ([127.0.0.1] helo=lists.colo.xensource.com) by lists.xensource.com with esmtp (Exim 4.43) id 1R9F4o-0002HW-It; Thu, 29 Sep 2011 04:46:54 -0700 Received: from mail174.messagelabs.com ([85.158.138.51]) by lists.xensource.com with esmtp (Exim 4.43) id 1R9Ewf-00089v-Uz for xen-devel@lists.xensource.com; Thu, 29 Sep 2011 04:38:31 -0700 X-Env-Sender: anthony.perard@citrix.com X-Msg-Ref: server-2.tower-174.messagelabs.com!1317296298!33226833!4 X-Originating-IP: [66.165.176.63] X-StarScan-Version: 6.4.1; banners=-,-,- X-VirusChecked: Checked Received: (qmail 5348 invoked from network); 29 Sep 2011 11:38:26 -0000 Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63) by server-2.tower-174.messagelabs.com with RC4-SHA encrypted SMTP; 29 Sep 2011 11:38:26 -0000 X-IronPort-AV: E=Sophos;i="4.68,460,1312171200"; d="scan'208";a="165111960" Received: from ftlpmailmx01.citrite.net ([10.13.107.65]) by FTLPIPO02.CITRIX.COM with ESMTP/TLS/RC4-MD5; 29 Sep 2011 07:38:25 -0400 Received: from smtp01.ad.xensource.com (10.219.128.104) by smtprelay.citrix.com (10.13.107.65) with Microsoft SMTP Server id 8.3.137.0; Thu, 29 Sep 2011 07:38:25 -0400 Received: from perard.uk.xensource.com (dhcp-3-28.uk.xensource.com [10.80.3.28] (may be forged)) by smtp01.ad.xensource.com (8.13.1/8.13.1) with ESMTP id p8TBc6sh025574; Thu, 29 Sep 2011 04:38:24 -0700 From: Anthony PERARD <anthony.perard@citrix.com> To: Xen Devel <xen-devel@lists.xensource.com> Date: Thu, 29 Sep 2011 12:37:57 +0100 Message-ID: <1317296277-2838-8-git-send-email-anthony.perard@citrix.com> X-Mailer: git-send-email 1.7.2.5 In-Reply-To: <1317296277-2838-1-git-send-email-anthony.perard@citrix.com> References: <1317296277-2838-1-git-send-email-anthony.perard@citrix.com> MIME-Version: 1.0 Content-Type: text/plain Cc: Ian Campbell <Ian.Campbell@eu.citrix.com>, Anthony PERARD <anthony.perard@citrix.com>, Stefano Stabellini <stefano.stabellini@eu.citrix.com> Subject: [Xen-devel] [PATCH V9 7/7] libxl: Introduce a QMP client X-BeenThere: xen-devel@lists.xensource.com X-Mailman-Version: 2.1.5 Precedence: list List-Id: Xen developer discussion <xen-devel.lists.xensource.com> List-Unsubscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe> List-Post: <mailto:xen-devel@lists.xensource.com> List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help> List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=subscribe> Sender: xen-devel-bounces@lists.xensource.com Errors-To: xen-devel-bounces@lists.xensource.com QMP stands for QEMU Monitor Protocol and it is used to query information from QEMU or to control QEMU. This implementation will ask QEMU the list of chardevice and store the path to serial ports in xenstored. So we will be able to use xl console with QEMU upstream. In order to connect to the QMP server, a socket file is created in /var/run/xen/qmp-libxl-$(domid). Signed-off-by: Anthony PERARD <anthony.perard@citrix.com> --- tools/libxl/Makefile | 2 +- tools/libxl/libxl.c | 2 + tools/libxl/libxl_create.c | 4 + tools/libxl/libxl_dm.c | 10 + tools/libxl/libxl_internal.h | 19 ++ tools/libxl/libxl_qmp.c | 595 ++++++++++++++++++++++++++++++++++++++++++ 6 files changed, 631 insertions(+), 1 deletions(-) create mode 100644 tools/libxl/libxl_qmp.c diff --git a/tools/libxl/Makefile b/tools/libxl/Makefile index e50874e..f10c7e8 100644 --- a/tools/libxl/Makefile +++ b/tools/libxl/Makefile @@ -37,7 +37,7 @@ LIBXL_LIBS += -lyajl LIBXL_OBJS = flexarray.o libxl.o libxl_create.o libxl_dm.o libxl_pci.o \ libxl_dom.o libxl_exec.o libxl_xshelp.o libxl_device.o \ libxl_internal.o libxl_utils.o libxl_uuid.o libxl_json.o \ - $(LIBXL_OBJS-y) + libxl_qmp.o $(LIBXL_OBJS-y) LIBXL_OBJS += _libxl_types.o libxl_flask.o _libxl_types_internal.o $(LIBXL_OBJS): CFLAGS += $(CFLAGS_libxenctrl) $(CFLAGS_libxenguest) $(CFLAGS_libxenstore) $(CFLAGS_libblktapctl) diff --git a/tools/libxl/libxl.c b/tools/libxl/libxl.c index ce76cff..0855f59 100644 --- a/tools/libxl/libxl.c +++ b/tools/libxl/libxl.c @@ -762,6 +762,8 @@ int libxl_domain_destroy(libxl_ctx *ctx, uint32_t domid, int force) if (dm_present) { if (libxl__destroy_device_model(&gc, domid) < 0) LIBXL__LOG(ctx, LIBXL__LOG_ERROR, "libxl__destroy_device_model failed for %d", domid); + + libxl__qmp_cleanup(&gc, domid); } if (libxl__devices_destroy(&gc, domid, force) < 0) LIBXL__LOG(ctx, LIBXL__LOG_ERROR, "libxl_destroy_devices failed for %d", domid); diff --git a/tools/libxl/libxl_create.c b/tools/libxl/libxl_create.c index ce76729..c97819a 100644 --- a/tools/libxl/libxl_create.c +++ b/tools/libxl/libxl_create.c @@ -573,6 +573,10 @@ static int do_domain_create(libxl__gc *gc, libxl_domain_config *d_config, } if (dm_starting) { + if (dm_info->device_model_version + == LIBXL_DEVICE_MODEL_VERSION_QEMU_XEN) { + libxl__qmp_initializations(ctx, domid); + } ret = libxl__confirm_device_model_startup(gc, dm_starting); if (ret < 0) { LIBXL__LOG(ctx, LIBXL__LOG_ERROR, diff --git a/tools/libxl/libxl_dm.c b/tools/libxl/libxl_dm.c index c575460..7e0616a 100644 --- a/tools/libxl/libxl_dm.c +++ b/tools/libxl/libxl_dm.c @@ -248,6 +248,16 @@ static char ** libxl__build_device_model_args_new(libxl__gc *gc, flexarray_vappend(dm_args, dm, "-xen-domid", libxl__sprintf(gc, "%d", info->domid), NULL); + flexarray_append(dm_args, "-chardev"); + flexarray_append(dm_args, + libxl__sprintf(gc, "socket,id=libxl-cmd," + "path=%s/qmp-libxl-%d,server,nowait", + libxl_run_dir_path(), + info->domid)); + + flexarray_append(dm_args, "-mon"); + flexarray_append(dm_args, "chardev=libxl-cmd,mode=control"); + if (info->type == LIBXL_DOMAIN_TYPE_PV) { flexarray_append(dm_args, "-xen-attach"); } diff --git a/tools/libxl/libxl_internal.h b/tools/libxl/libxl_internal.h index 66f56f1..cef2036 100644 --- a/tools/libxl/libxl_internal.h +++ b/tools/libxl/libxl_internal.h @@ -393,6 +393,25 @@ _hidden int libxl__e820_alloc(libxl_ctx *ctx, uint32_t domid, libxl_domain_confi #define STRINGIFY(x) #x #define TOSTRING(x) STRINGIFY(x) +/* from libxl_qmp */ +typedef struct libxl__qmp_handler libxl__qmp_handler; + +/* Initialise and connect to the QMP socket. + * Return an handler or NULL if there is an error + */ +_hidden libxl__qmp_handler *libxl__qmp_initialize(libxl_ctx *ctx, + uint32_t domid); +/* ask to QEMU the serial port information and store it in xenstore. */ +_hidden int libxl__qmp_query_serial(libxl__qmp_handler *qmp); +/* close and free the QMP handler */ +_hidden void libxl__qmp_close(libxl__qmp_handler *qmp); +/* remove the socket file, if the file has already been removed, + * nothing happen */ +_hidden void libxl__qmp_cleanup(libxl__gc *gc, uint32_t domid); + +/* this helper calls qmp_initialize, query_serial and qmp_close */ +_hidden int libxl__qmp_initializations(libxl_ctx *ctx, uint32_t domid); + /* from libxl_json */ #include <yajl/yajl_gen.h> diff --git a/tools/libxl/libxl_qmp.c b/tools/libxl/libxl_qmp.c new file mode 100644 index 0000000..8cda29d --- /dev/null +++ b/tools/libxl/libxl_qmp.c @@ -0,0 +1,595 @@ +/* + * Copyright (C) 2011 Citrix Ltd. + * Author Anthony PERARD <anthony.perard@citrix.com> + * + * This program is free software; you can redistribute it and/or modify + * it under the terms of the GNU Lesser General Public License as published + * by the Free Software Foundation; version 2.1 only. with the special + * exception on linking described in file LICENSE. + * + * This program is distributed in the hope that it will be useful, + * but WITHOUT ANY WARRANTY; without even the implied warranty of + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the + * GNU Lesser General Public License for more details. + */ + +/* + * This file implement a client for QMP (QEMU Monitor Protocol). For the + * Specification, see in the QEMU repository. + */ + +#include <unistd.h> +#include <sys/un.h> +#include <sys/queue.h> +#include <fcntl.h> + +#include <yajl/yajl_gen.h> + +#include "libxl_internal.h" + +/* #define DEBUG_RECEIVED */ + +#ifdef DEBUG_RECEIVED +# define DEBUG_REPORT_RECEIVED(buf, len) \ + LIBXL__LOG(qmp->ctx, LIBXL__LOG_DEBUG, "received: '%.*s'", len, buf) +#else +# define DEBUG_REPORT_RECEIVED(buf, len) ((void)0) +#endif + +/* + * QMP types & constant + */ + +#define QMP_RECEIVE_BUFFER_SIZE 4096 + +typedef int (*qmp_callback_t)(libxl__qmp_handler *qmp, + const libxl__json_object *tree); + +typedef struct callback_id_pair { + int id; + qmp_callback_t callback; + SIMPLEQ_ENTRY(callback_id_pair) next; +} callback_id_pair; + +struct libxl__qmp_handler { + struct sockaddr_un addr; + int qmp_fd; + bool connected; + time_t timeout; + /* wait_for_id will be used by the synchronous send function */ + int wait_for_id; + + char buffer[QMP_RECEIVE_BUFFER_SIZE]; + libxl__yajl_ctx *yajl_ctx; + + libxl_ctx *ctx; + uint32_t domid; + + int last_id_used; + SIMPLEQ_HEAD(callback_list, callback_id_pair) callback_list; +}; + +static int qmp_send(libxl__qmp_handler *qmp, + const char *cmd, qmp_callback_t callback); + +static const int QMP_SOCKET_CONNECT_TIMEOUT = 5; + +/* + * QMP callbacks functions + */ + +static int store_serial_port_info(libxl__qmp_handler *qmp, + const char *chardev, + int port) +{ + libxl__gc gc = LIBXL_INIT_GC(qmp->ctx); + char *path = NULL; + int ret = 0; + + if (!(chardev && strncmp("pty:", chardev, 4) == 0)) { + return -1; + } + + path = libxl__xs_get_dompath(&gc, qmp->domid); + path = libxl__sprintf(&gc, "%s/serial/%d/tty", path, port); + + ret = libxl__xs_write(&gc, XBT_NULL, path, "%s", chardev + 4); + + libxl__free_all(&gc); + return ret; +} + +static int register_serials_chardev_callback(libxl__qmp_handler *qmp, + const libxl__json_object *o) +{ + const libxl__json_object *obj = NULL; + const libxl__json_object *label = NULL; + const char *s = NULL; + int i = 0; + const char *chardev = NULL; + int ret = 0; + + for (i = 0; (obj = libxl__json_array_get(o, i)); i++) { + if (!libxl__json_object_is_map(obj)) + continue; + label = libxl__json_map_get("label", obj, JSON_STRING); + s = libxl__json_object_get_string(label); + + if (s && strncmp("serial", s, strlen("serial")) == 0) { + const libxl__json_object *filename = NULL; + char *endptr = NULL; + int port_number; + + filename = libxl__json_map_get("filename", obj, JSON_STRING); + chardev = libxl__json_object_get_string(filename); + + s += strlen("serial"); + port_number = strtol(s, &endptr, 10); + if (*s == 0 || *endptr != 0) { + LIBXL__LOG(qmp->ctx, LIBXL__LOG_ERROR, + "Invalid serial port number: %s", s); + return -1; + } + ret = store_serial_port_info(qmp, chardev, port_number); + if (ret) { + LIBXL__LOG_ERRNO(qmp->ctx, LIBXL__LOG_ERROR, + "Failed to store serial port information" + " in xenstore"); + return ret; + } + } + }; + + return ret; +} + +static int qmp_capabilities_callback(libxl__qmp_handler *qmp, + const libxl__json_object *o) +{ + qmp->connected = true; + + return 0; +} + +/* + * QMP commands + */ + +static int enable_qmp_capabilities(libxl__qmp_handler *qmp) +{ + return qmp_send(qmp, "qmp_capabilities", qmp_capabilities_callback); +} + +/* + * Helpers + */ + +static libxl__qmp_message_type qmp_response_type(libxl__qmp_handler *qmp, + const libxl__json_object *o) +{ + libxl__qmp_message_type type; + libxl__json_map_node *node = NULL; + int i = 0; + + for (i = 0; (node = libxl__json_map_node_get(o, i)); i++) { + if (libxl__qmp_message_type_from_string(node->map_key, &type) == 0) + return type; + } + + return LIBXL__QMP_MESSAGE_TYPE_INVALID; +} + +static callback_id_pair *qmp_get_callback_from_id(libxl__qmp_handler *qmp, + const libxl__json_object *o) +{ + const libxl__json_object *id_object = libxl__json_map_get("id", o, + JSON_INTEGER); + int id = -1; + callback_id_pair *pp = NULL; + + if (id_object) { + id = libxl__json_object_get_integer(id_object); + + SIMPLEQ_FOREACH(pp, &qmp->callback_list, next) { + if (pp->id == id) { + return pp; + } + } + } + return NULL; +} + +static void qmp_handle_error_response(libxl__qmp_handler *qmp, + const libxl__json_object *resp) +{ + callback_id_pair *pp = qmp_get_callback_from_id(qmp, resp); + + resp = libxl__json_map_get("error", resp, JSON_MAP); + resp = libxl__json_map_get("desc", resp, JSON_STRING); + + if (pp) { + pp->callback(qmp, NULL); + if (pp->id == qmp->wait_for_id) { + /* tell that the id have been processed */ + qmp->wait_for_id = 0; + } + SIMPLEQ_REMOVE(&qmp->callback_list, pp, callback_id_pair, next); + free(pp); + } + + LIBXL__LOG(qmp->ctx, LIBXL__LOG_ERROR, + "received an error message from QMP server: %s", + libxl__json_object_get_string(resp)); +} + +static int qmp_handle_response(libxl__qmp_handler *qmp, + const libxl__json_object *resp) +{ + libxl__qmp_message_type type = LIBXL__QMP_MESSAGE_TYPE_INVALID; + + type = qmp_response_type(qmp, resp); + LIBXL__LOG(qmp->ctx, LIBXL__LOG_DEBUG, + "message type: %s", libxl__qmp_message_type_to_string(type)); + + switch (type) { + case LIBXL__QMP_MESSAGE_TYPE_QMP: + /* On the greeting message from the server, enable QMP capabilities */ + enable_qmp_capabilities(qmp); + break; + case LIBXL__QMP_MESSAGE_TYPE_RETURN: { + callback_id_pair *pp = qmp_get_callback_from_id(qmp, resp); + + if (pp) { + pp->callback(qmp, + libxl__json_map_get("return", resp, JSON_ANY)); + if (pp->id == qmp->wait_for_id) { + /* tell that the id have been processed */ + qmp->wait_for_id = 0; + } + SIMPLEQ_REMOVE(&qmp->callback_list, pp, callback_id_pair, next); + free(pp); + } + break; + } + case LIBXL__QMP_MESSAGE_TYPE_ERROR: + qmp_handle_error_response(qmp, resp); + break; + case LIBXL__QMP_MESSAGE_TYPE_EVENT: + break; + case LIBXL__QMP_MESSAGE_TYPE_INVALID: + return -1; + } + return 0; +} + +/* + * Handler functions + */ + +static libxl__qmp_handler *qmp_init_handler(libxl_ctx *ctx, uint32_t domid) +{ + libxl__qmp_handler *qmp = NULL; + + qmp = calloc(1, sizeof (libxl__qmp_handler)); + if (qmp == NULL) { + LIBXL__LOG_ERRNO(ctx, LIBXL__LOG_ERROR, + "Failed to allocate qmp_handler"); + return NULL; + } + qmp->ctx = ctx; + qmp->domid = domid; + qmp->timeout = 5; + + SIMPLEQ_INIT(&qmp->callback_list); + + return qmp; +} + +static int qmp_open(libxl__qmp_handler *qmp, const char *qmp_socket_path, + int timeout) +{ + int ret; + int flags = 0; + int i = 0; + + qmp->qmp_fd = socket(AF_UNIX, SOCK_STREAM, 0); + if (qmp->qmp_fd < 0) { + return -1; + } + if ((flags = fcntl(qmp->qmp_fd, F_GETFL)) == 1) { + flags = 0; + } + if (fcntl(qmp->qmp_fd, F_SETFL, flags | O_NONBLOCK) == -1) { + return -1; + } + + memset(&qmp->addr, 0, sizeof (&qmp->addr)); + qmp->addr.sun_family = AF_UNIX; + strncpy(qmp->addr.sun_path, qmp_socket_path, + sizeof (qmp->addr.sun_path)); + + do { + ret = connect(qmp->qmp_fd, (struct sockaddr *) &qmp->addr, + sizeof (qmp->addr)); + if (ret == 0) + break; + if (errno == ENOENT || errno == ECONNREFUSED) { + /* ENOENT : Socket may not have shown up yet + * ECONNREFUSED : Leftover socket hasn't been removed yet */ + continue; + } + return -1; + } while ((++i / 5 <= timeout) && (usleep(200 * 1000) <= 0)); + + return ret; +} + +static void qmp_close(libxl__qmp_handler *qmp) +{ + callback_id_pair *pp = NULL; + callback_id_pair *tmp = NULL; + + close(qmp->qmp_fd); + SIMPLEQ_FOREACH(pp, &qmp->callback_list, next) { + if (tmp) + free(tmp); + tmp = pp; + } + if (tmp) + free(tmp); +} + +static int qmp_next(libxl__gc *gc, libxl__qmp_handler *qmp) +{ + ssize_t rd; + char *s = NULL; + char *s_end = NULL; + + char *incomplete = NULL; + size_t incomplete_size = 0; + + do { + fd_set rfds; + int ret = 0; + struct timeval timeout = { + .tv_sec = qmp->timeout, + .tv_usec = 0, + }; + + FD_ZERO(&rfds); + FD_SET(qmp->qmp_fd, &rfds); + + ret = select(qmp->qmp_fd + 1, &rfds, NULL, NULL, &timeout); + if (ret == 0) { + LIBXL__LOG(qmp->ctx, LIBXL__LOG_ERROR, "timeout"); + return -1; + } else if (ret < 0) { + LIBXL__LOG_ERRNO(qmp->ctx, LIBXL__LOG_ERROR, "Select error"); + return -1; + } + + rd = read(qmp->qmp_fd, qmp->buffer, QMP_RECEIVE_BUFFER_SIZE); + if (rd == 0) { + continue; + } else if (rd < 0) { + LIBXL__LOG_ERRNO(qmp->ctx, LIBXL__LOG_ERROR, "Socket read error"); + return rd; + } + + DEBUG_REPORT_RECEIVED(qmp->buffer, rd); + + do { + char *end = NULL; + if (incomplete) { + size_t current_pos = s - incomplete; + incomplete_size += rd; + incomplete = libxl__realloc(gc, incomplete, + incomplete_size + 1); + incomplete = strncat(incomplete, qmp->buffer, rd); + s = incomplete + current_pos; + s_end = incomplete + incomplete_size; + } else { + incomplete = libxl__strndup(gc, qmp->buffer, rd); + incomplete_size = rd; + s = incomplete; + s_end = s + rd; + } + + end = strstr(s, "\r\n"); + if (end) { + libxl__json_object *o = NULL; + + *end = '\0'; + + o = libxl__json_parse(gc, s); + s = end + 2; + + if (o) { + qmp_handle_response(qmp, o); + libxl__json_object_free(gc, o); + } else { + LIBXL__LOG(qmp->ctx, LIBXL__LOG_ERROR, + "Parse error of : %s\n", s); + return -1; + } + } else { + break; + } + } while (s < s_end); + } while (s < s_end); + + return 1; +} + +static int qmp_send(libxl__qmp_handler *qmp, + const char *cmd, qmp_callback_t callback) +{ + yajl_gen_config conf = { 0, NULL }; + const unsigned char *buf; + unsigned int len = 0; + yajl_gen_status s; + yajl_gen hand; + + hand = yajl_gen_alloc(&conf, NULL); + if (!hand) { + return -1; + } + + yajl_gen_map_open(hand); + libxl__yajl_gen_asciiz(hand, "execute"); + libxl__yajl_gen_asciiz(hand, cmd); + libxl__yajl_gen_asciiz(hand, "id"); + yajl_gen_integer(hand, ++qmp->last_id_used); + yajl_gen_map_close(hand); + + s = yajl_gen_get_buf(hand, &buf, &len); + + if (s) { + LIBXL__LOG(qmp->ctx, LIBXL__LOG_ERROR, + "Failed to generate a qmp command"); + return -1; + } + + if (callback) { + callback_id_pair *elm = malloc(sizeof (callback_id_pair)); + if (elm == NULL) { + LIBXL__LOG_ERRNO(qmp->ctx, LIBXL__LOG_ERROR, + "Failed to allocate a QMP callback"); + yajl_gen_free(hand); + return -1; + } + elm->id = qmp->last_id_used; + elm->callback = callback; + SIMPLEQ_INSERT_TAIL(&qmp->callback_list, elm, next); + } + + LIBXL__LOG(qmp->ctx, LIBXL__LOG_DEBUG, "next qmp command: '%s'", buf); + + if (libxl_write_exactly(qmp->ctx, qmp->qmp_fd, buf, len, + "QMP command", "QMP socket")) + goto error; + if (libxl_write_exactly(qmp->ctx, qmp->qmp_fd, "\r\n", 2, + "CRLF", "QMP socket")) + goto error; + + yajl_gen_free(hand); + + return qmp->last_id_used; + +error: + yajl_gen_free(hand); + return -1; +} + +static int qmp_synchronous_send(libxl__qmp_handler *qmp, const char *cmd, + qmp_callback_t callback, int ask_timeout) +{ + int id = 0; + int ret = 0; + libxl__gc gc = LIBXL_INIT_GC(qmp->ctx); + + id = qmp_send(qmp, cmd, callback); + if (id <= 0) { + return -1; + } + qmp->wait_for_id = id; + + while (qmp->wait_for_id == id) { + if ((ret = qmp_next(&gc, qmp)) < 0) { + return ret; + } + } + + libxl__free_all(&gc); + + return 0; +} + +static void qmp_free_handler(libxl__qmp_handler *qmp) +{ + free(qmp); +} + +/* + * API + */ + +libxl__qmp_handler *libxl__qmp_initialize(libxl_ctx *ctx, uint32_t domid) +{ + int ret = 0; + libxl__qmp_handler *qmp = NULL; + char *qmp_socket; + libxl__gc gc = LIBXL_INIT_GC(ctx); + + qmp = qmp_init_handler(ctx, domid); + + qmp_socket = libxl__sprintf(&gc, "%s/qmp-libxl-%d", + libxl_run_dir_path(), domid); + if ((ret = qmp_open(qmp, qmp_socket, QMP_SOCKET_CONNECT_TIMEOUT)) < 0) { + LIBXL__LOG_ERRNO(ctx, LIBXL__LOG_ERROR, "Connection error"); + libxl__free_all(&gc); + qmp_free_handler(qmp); + return NULL; + } + + LIBXL__LOG(qmp->ctx, LIBXL__LOG_DEBUG, "connected to %s", qmp_socket); + + /* Wait for the response to qmp_capabilities */ + while (!qmp->connected) { + if ((ret = qmp_next(&gc, qmp)) < 0) { + break; + } + } + + libxl__free_all(&gc); + if (!qmp->connected) { + LIBXL__LOG(ctx, LIBXL__LOG_ERROR, "Failed to connect to QMP"); + libxl__qmp_close(qmp); + return NULL; + } + return qmp; +} + +void libxl__qmp_close(libxl__qmp_handler *qmp) +{ + if (!qmp) + return; + qmp_close(qmp); + qmp_free_handler(qmp); +} + +void libxl__qmp_cleanup(libxl__gc *gc, uint32_t domid) +{ + libxl_ctx *ctx = libxl__gc_owner(gc); + char *qmp_socket; + + qmp_socket = libxl__sprintf(gc, "%s/qmp-libxl-%d", + libxl_run_dir_path(), domid); + if (unlink(qmp_socket) == -1) { + if (errno != ENOENT) { + LIBXL__LOG_ERRNO(ctx, LIBXL__LOG_ERROR, + "Failed to remove QMP socket file %s", + qmp_socket); + } + } +} + +int libxl__qmp_query_serial(libxl__qmp_handler *qmp) +{ + return qmp_synchronous_send(qmp, "query-chardev", + register_serials_chardev_callback, + qmp->timeout); +} + +int libxl__qmp_initializations(libxl_ctx *ctx, uint32_t domid) +{ + libxl__qmp_handler *qmp = NULL; + int ret = 0; + + qmp = libxl__qmp_initialize(ctx, domid); + if (!qmp) + return -1; + ret = libxl__qmp_query_serial(qmp); + libxl__qmp_close(qmp); + return ret; +} -- Anthony PERARD _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel From xen-devel-bounces@lists.xensource.com Thu Sep 29 04:48:23 2011 Return-path: <xen-devel-bounces@lists.xensource.com> Envelope-to: www-data@lists.xensource.com Delivery-date: Thu, 29 Sep 2011 04:48:23 -0700 Received: from localhost ([127.0.0.1] helo=lists.colo.xensource.com) by lists.xensource.com with esmtp (Exim 4.43) id 1R9F6F-0002f2-CJ; Thu, 29 Sep 2011 04:48:23 -0700 Received: from mail21.messagelabs.com ([85.158.143.35]) by lists.xensource.com with esmtp (Exim 4.43) id 1R9Ewg-0008AF-Op for xen-devel@lists.xensource.com; Thu, 29 Sep 2011 04:38:31 -0700 X-Env-Sender: anthony.perard@citrix.com X-Msg-Ref: server-8.tower-21.messagelabs.com!1317296289!60840839!1 X-Originating-IP: [66.165.176.89] X-StarScan-Version: 6.4.1; banners=-,-,- X-VirusChecked: Checked Received: (qmail 14342 invoked from network); 29 Sep 2011 11:38:10 -0000 Received: from smtp.citrix.com (HELO SMTP.CITRIX.COM) (66.165.176.89) by server-8.tower-21.messagelabs.com with RC4-SHA encrypted SMTP; 29 Sep 2011 11:38:10 -0000 X-IronPort-AV: E=Sophos;i="4.68,460,1312171200"; d="scan'208";a="17802743" Received: from ftlpmailmx01.citrite.net ([10.13.107.65]) by FTLPIPO01.CITRIX.COM with ESMTP/TLS/RC4-MD5; 29 Sep 2011 07:38:24 -0400 Received: from smtp01.ad.xensource.com (10.219.128.104) by smtprelay.citrix.com (10.13.107.65) with Microsoft SMTP Server id 8.3.137.0; Thu, 29 Sep 2011 07:38:24 -0400 Received: from perard.uk.xensource.com (dhcp-3-28.uk.xensource.com [10.80.3.28] (may be forged)) by smtp01.ad.xensource.com (8.13.1/8.13.1) with ESMTP id p8TBc6sg025574; Thu, 29 Sep 2011 04:38:23 -0700 From: Anthony PERARD <anthony.perard@citrix.com> To: Xen Devel <xen-devel@lists.xensource.com> Date: Thu, 29 Sep 2011 12:37:56 +0100 Message-ID: <1317296277-2838-7-git-send-email-anthony.perard@citrix.com> X-Mailer: git-send-email 1.7.2.5 In-Reply-To: <1317296277-2838-1-git-send-email-anthony.perard@citrix.com> References: <1317296277-2838-1-git-send-email-anthony.perard@citrix.com> MIME-Version: 1.0 Content-Type: text/plain Cc: Ian Campbell <Ian.Campbell@eu.citrix.com>, Anthony PERARD <anthony.perard@citrix.com>, Stefano Stabellini <stefano.stabellini@eu.citrix.com> Subject: [Xen-devel] [PATCH V9 6/7] libxl: Introduce JSON parsing stuff. X-BeenThere: xen-devel@lists.xensource.com X-Mailman-Version: 2.1.5 Precedence: list List-Id: Xen developer discussion <xen-devel.lists.xensource.com> List-Unsubscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe> List-Post: <mailto:xen-devel@lists.xensource.com> List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help> List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=subscribe> Sender: xen-devel-bounces@lists.xensource.com Errors-To: xen-devel-bounces@lists.xensource.com We use the yajl parser, but we need to make a tree from the parse result to use it outside the parser. So this patch include json_object struct that is used to hold the JSON data. Signed-off-by: Anthony PERARD <anthony.perard@citrix.com> Acked-by: Ian Campbell <ian.campbell@citrix.com> --- README | 1 + tools/libxl/Makefile | 5 +- tools/libxl/libxl_internal.h | 100 ++++++++ tools/libxl/libxl_json.c | 560 ++++++++++++++++++++++++++++++++++++++++++ 4 files changed, 665 insertions(+), 1 deletions(-) create mode 100644 tools/libxl/libxl_json.c diff --git a/README b/README index ff154b2..c9bf699 100644 --- a/README +++ b/README @@ -47,6 +47,7 @@ provided by your OS distributor: * Development install of openssl (e.g., openssl-dev) * Development install of x11 (e.g. xorg-x11-dev) * Development install of uuid (e.g. uuid-dev) + * Development install of yajl (e.g. libyajl-dev) * bridge-utils package (/sbin/brctl) * iproute package (/sbin/ip) * hotplug or udev diff --git a/tools/libxl/Makefile b/tools/libxl/Makefile index 1f6b418..e50874e 100644 --- a/tools/libxl/Makefile +++ b/tools/libxl/Makefile @@ -32,9 +32,12 @@ endif LIBXL_OBJS-$(CONFIG_X86) += libxl_cpuid.o LIBXL_OBJS-$(CONFIG_IA64) += libxl_nocpuid.o +LIBXL_LIBS += -lyajl + LIBXL_OBJS = flexarray.o libxl.o libxl_create.o libxl_dm.o libxl_pci.o \ libxl_dom.o libxl_exec.o libxl_xshelp.o libxl_device.o \ - libxl_internal.o libxl_utils.o libxl_uuid.o $(LIBXL_OBJS-y) + libxl_internal.o libxl_utils.o libxl_uuid.o libxl_json.o \ + $(LIBXL_OBJS-y) LIBXL_OBJS += _libxl_types.o libxl_flask.o _libxl_types_internal.o $(LIBXL_OBJS): CFLAGS += $(CFLAGS_libxenctrl) $(CFLAGS_libxenguest) $(CFLAGS_libxenstore) $(CFLAGS_libblktapctl) diff --git a/tools/libxl/libxl_internal.h b/tools/libxl/libxl_internal.h index 6ec402e..66f56f1 100644 --- a/tools/libxl/libxl_internal.h +++ b/tools/libxl/libxl_internal.h @@ -393,4 +393,104 @@ _hidden int libxl__e820_alloc(libxl_ctx *ctx, uint32_t domid, libxl_domain_confi #define STRINGIFY(x) #x #define TOSTRING(x) STRINGIFY(x) +/* from libxl_json */ +#include <yajl/yajl_gen.h> + +_hidden yajl_gen_status libxl__yajl_gen_asciiz(yajl_gen hand, const char *str); + +typedef enum { + JSON_ERROR, + JSON_NULL, + JSON_TRUE, + JSON_FALSE, + JSON_INTEGER, + JSON_DOUBLE, + JSON_STRING, + JSON_MAP, + JSON_ARRAY, + JSON_ANY +} libxl__json_node_type; + +typedef struct libxl__json_object { + libxl__json_node_type type; + union { + long i; + double d; + char *string; + /* List of libxl__json_object */ + flexarray_t *array; + /* List of libxl__json_map_node */ + flexarray_t *map; + } u; + struct libxl__json_object *parent; +} libxl__json_object; + +typedef struct { + char *map_key; + libxl__json_object *obj; +} libxl__json_map_node; + +typedef struct libxl__yajl_ctx libxl__yajl_ctx; + +static inline bool libxl__json_object_is_string(const libxl__json_object *o) +{ + return o != NULL && o->type == JSON_STRING; +} +static inline bool libxl__json_object_is_integer(const libxl__json_object *o) +{ + return o != NULL && o->type == JSON_INTEGER; +} +static inline bool libxl__json_object_is_map(const libxl__json_object *o) +{ + return o != NULL && o->type == JSON_MAP; +} +static inline bool libxl__json_object_is_array(const libxl__json_object *o) +{ + return o != NULL && o->type == JSON_ARRAY; +} + +static inline +const char *libxl__json_object_get_string(const libxl__json_object *o) +{ + if (libxl__json_object_is_string(o)) + return o->u.string; + else + return NULL; +} +static inline +flexarray_t *libxl__json_object_get_map(const libxl__json_object *o) +{ + if (libxl__json_object_is_map(o)) + return o->u.map; + else + return NULL; +} +static inline +flexarray_t *libxl__json_object_get_array(const libxl__json_object *o) +{ + if (libxl__json_object_is_array(o)) + return o->u.array; + else + return NULL; +} +static inline long libxl__json_object_get_integer(const libxl__json_object *o) +{ + if (libxl__json_object_is_integer(o)) + return o->u.i; + else + return -1; +} + +_hidden libxl__json_object *libxl__json_array_get(const libxl__json_object *o, + int i); +_hidden +libxl__json_map_node *libxl__json_map_node_get(const libxl__json_object *o, + int i); +_hidden const libxl__json_object *libxl__json_map_get(const char *key, + const libxl__json_object *o, + libxl__json_node_type expected_type); +_hidden void libxl__json_object_free(libxl__gc *gc, libxl__json_object *obj); + +_hidden libxl__json_object *libxl__json_parse(libxl__gc *gc, const char *s); + #endif diff --git a/tools/libxl/libxl_json.c b/tools/libxl/libxl_json.c new file mode 100644 index 0000000..e771925 --- /dev/null +++ b/tools/libxl/libxl_json.c @@ -0,0 +1,560 @@ +/* + * Copyright (C) 2011 Citrix Ltd. + * + * This program is free software; you can redistribute it and/or modify + * it under the terms of the GNU Lesser General Public License as published + * by the Free Software Foundation; version 2.1 only. with the special + * exception on linking described in file LICENSE. + * + * This program is distributed in the hope that it will be useful, + * but WITHOUT ANY WARRANTY; without even the implied warranty of + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the + * GNU Lesser General Public License for more details. + */ + +#include <assert.h> +#include <string.h> + +#include <yajl/yajl_parse.h> +#include <yajl/yajl_gen.h> + +#include "libxl_internal.h" + +/* #define DEBUG_ANSWER */ + +struct libxl__yajl_ctx { + libxl__gc *gc; + yajl_handle hand; + libxl__json_object *head; + libxl__json_object *current; +#ifdef DEBUG_ANSWER + yajl_gen g; +#endif +}; + +#ifdef DEBUG_ANSWER +# define DEBUG_GEN_ALLOC(ctx) \ + if ((ctx)->g == NULL) { \ + yajl_gen_config conf = { 1, " " }; \ + (ctx)->g = yajl_gen_alloc(&conf, NULL); \ + } +# define DEBUG_GEN_FREE(ctx) \ + if ((ctx)->g) yajl_gen_free((ctx)->g) +# define DEBUG_GEN(ctx, type) yajl_gen_##type(ctx->g) +# define DEBUG_GEN_VALUE(ctx, type, value) yajl_gen_##type(ctx->g, value) +# define DEBUG_GEN_STRING(ctx, str, n) yajl_gen_string(ctx->g, str, n) +# define DEBUG_GEN_REPORT(yajl_ctx) \ + do { \ + const unsigned char *buf = NULL; \ + unsigned int len = 0; \ + yajl_gen_get_buf((yajl_ctx)->g, &buf, &len); \ + LIBXL__LOG(libxl__gc_owner((yajl_ctx)->gc), \ + LIBXL__LOG_DEBUG, "response:\n%s", buf); \ + yajl_gen_free((yajl_ctx)->g); \ + (yajl_ctx)->g = NULL; \ + } while (0) +#else +# define DEBUG_GEN_ALLOC(ctx) ((void)0) +# define DEBUG_GEN_FREE(ctx) ((void)0) +# define DEBUG_GEN(ctx, type) ((void)0) +# define DEBUG_GEN_VALUE(ctx, type, value) ((void)0) +# define DEBUG_GEN_STRING(ctx, value, lenght) ((void)0) +# define DEBUG_GEN_REPORT(ctx) ((void)0) +#endif + +/* + * YAJL Helper + */ + +yajl_gen_status libxl__yajl_gen_asciiz(yajl_gen hand, const char *str) +{ + return yajl_gen_string(hand, (const unsigned char *)str, strlen(str)); +} + + +/* + * libxl__json_object helper functions + */ + +static libxl__json_object *json_object_alloc(libxl__gc *gc, + libxl__json_node_type type) +{ + libxl__json_object *obj; + + obj = calloc(1, sizeof (libxl__json_object)); + if (obj == NULL) { + LIBXL__LOG_ERRNO(libxl__gc_owner(gc), LIBXL__LOG_ERROR, + "Failed to allocate a libxl__json_object"); + return NULL; + } + + obj->type = type; + + if (type == JSON_MAP || type == JSON_ARRAY) { + flexarray_t *array = flexarray_make(1, 1); + if (array == NULL) { + LIBXL__LOG_ERRNO(libxl__gc_owner(gc), LIBXL__LOG_ERROR, + "Failed to allocate a flexarray"); + free(obj); + return NULL; + } + if (type == JSON_MAP) + obj->u.map = array; + else + obj->u.array = array; + } + + return obj; +} + +static int json_object_append_to(libxl__gc *gc, + libxl__json_object *obj, + libxl__json_object *dst) +{ + assert(dst != NULL); + + switch (dst->type) { + case JSON_MAP: { + libxl__json_map_node *last; + + if (dst->u.map->count == 0) { + LIBXL__LOG(libxl__gc_owner(gc), LIBXL__LOG_ERROR, + "Try to add a value to an empty map (with no key)"); + return -1; + } + flexarray_get(dst->u.map, dst->u.map->count - 1, (void**)&last); + last->obj = obj; + break; + } + case JSON_ARRAY: + if (flexarray_append(dst->u.array, obj) == 2) { + LIBXL__LOG_ERRNO(libxl__gc_owner(gc), LIBXL__LOG_ERROR, + "Failed to grow a flexarray"); + return -1; + } + break; + default: + LIBXL__LOG(libxl__gc_owner(gc), LIBXL__LOG_ERROR, + "Try append an object is not a map/array (%i)\n", + dst->type); + return -1; + } + + obj->parent = dst; + return 0; +} + +void libxl__json_object_free(libxl__gc *gc, libxl__json_object *obj) +{ + int index = 0; + + if (obj == NULL) + return; + switch (obj->type) { + case JSON_STRING: + free(obj->u.string); + break; + case JSON_MAP: { + libxl__json_map_node *node = NULL; + + for (index = 0; index < obj->u.map->count; index++) { + if (flexarray_get(obj->u.map, index, (void**)&node) != 0) + break; + libxl__json_object_free(gc, node->obj); + free(node->map_key); + free(node); + node = NULL; + } + flexarray_free(obj->u.map); + break; + } + case JSON_ARRAY: { + libxl__json_object *node = NULL; + break; + + for (index = 0; index < obj->u.array->count; index++) { + if (flexarray_get(obj->u.array, index, (void**)&node) != 0) + break; + libxl__json_object_free(gc, node); + node = NULL; + } + flexarray_free(obj->u.array); + break; + } + default: + break; + } + free(obj); +} + +libxl__json_object *libxl__json_array_get(const libxl__json_object *o, int i) +{ + flexarray_t *array = NULL; + libxl__json_object *obj = NULL; + + if ((array = libxl__json_object_get_array(o)) == NULL) { + return NULL; + } + + if (i >= array->count) + return NULL; + + if (flexarray_get(array, i, (void**)&obj) != 0) + return NULL; + + return obj; +} + +libxl__json_map_node *libxl__json_map_node_get(const libxl__json_object *o, + int i) +{ + flexarray_t *array = NULL; + libxl__json_map_node *obj = NULL; + + if ((array = libxl__json_object_get_map(o)) == NULL) { + return NULL; + } + + if (i >= array->count) + return NULL; + + if (flexarray_get(array, i, (void**)&obj) != 0) + return NULL; + + return obj; +} + +const libxl__json_object *libxl__json_map_get(const char *key, + const libxl__json_object *o, + libxl__json_node_type expected_type) +{ + flexarray_t *maps = NULL; + int index = 0; + + if (libxl__json_object_is_map(o)) { + libxl__json_map_node *node = NULL; + + maps = o->u.map; + for (index = 0; index < maps->count; index++) { + if (flexarray_get(maps, index, (void**)&node) != 0) + return NULL; + if (strcmp(key, node->map_key) == 0) { + if (expected_type == JSON_ANY + || (node->obj && node->obj->type == expected_type)) { + return node->obj; + } else { + return NULL; + } + } + } + } + return NULL; +} + + +/* + * JSON callbacks + */ + +static int json_callback_null(void *opaque) +{ + libxl__yajl_ctx *ctx = opaque; + libxl__json_object *obj; + + DEBUG_GEN(ctx, null); + + if ((obj = json_object_alloc(ctx->gc, JSON_NULL)) == NULL) + return 0; + + if (json_object_append_to(ctx->gc, obj, ctx->current) == -1) { + libxl__json_object_free(ctx->gc, obj); + return 0; + } + + return 1; +} + +static int json_callback_boolean(void *opaque, int boolean) +{ + libxl__yajl_ctx *ctx = opaque; + libxl__json_object *obj; + + DEBUG_GEN_VALUE(ctx, bool, boolean); + + if ((obj = json_object_alloc(ctx->gc, + boolean ? JSON_TRUE : JSON_FALSE)) == NULL) + return 0; + + if (json_object_append_to(ctx->gc, obj, ctx->current) == -1) { + libxl__json_object_free(ctx->gc, obj); + return 0; + } + + return 1; +} + +static int json_callback_integer(void *opaque, long value) +{ + libxl__yajl_ctx *ctx = opaque; + libxl__json_object *obj; + + DEBUG_GEN_VALUE(ctx, integer, value); + + if ((obj = json_object_alloc(ctx->gc, JSON_INTEGER)) == NULL) + return 0; + obj->u.i = value; + + if (json_object_append_to(ctx->gc, obj, ctx->current) == -1) { + libxl__json_object_free(ctx->gc, obj); + return 0; + } + + return 1; +} + +static int json_callback_double(void *opaque, double value) +{ + libxl__yajl_ctx *ctx = opaque; + libxl__json_object *obj; + + DEBUG_GEN_VALUE(ctx, double, value); + + if ((obj = json_object_alloc(ctx->gc, JSON_DOUBLE)) == NULL) + return 0; + obj->u.d = value; + + if (json_object_append_to(ctx->gc, obj, ctx->current) == -1) { + libxl__json_object_free(ctx->gc, obj); + return 0; + } + + return 1; +} + +static int json_callback_string(void *opaque, const unsigned char *str, + unsigned int len) +{ + libxl__yajl_ctx *ctx = opaque; + char *t = NULL; + libxl__json_object *obj = NULL; + + t = malloc(len + 1); + if (t == NULL) { + LIBXL__LOG_ERRNO(libxl__gc_owner(ctx->gc), LIBXL__LOG_ERROR, + "Failed to allocate"); + return 0; + } + + DEBUG_GEN_STRING(ctx, str, len); + + strncpy(t, (const char *) str, len); + t[len] = 0; + + if ((obj = json_object_alloc(ctx->gc, JSON_STRING)) == NULL) { + free(t); + return 0; + } + obj->u.string = t; + + if (json_object_append_to(ctx->gc, obj, ctx->current) == -1) { + libxl__json_object_free(ctx->gc, obj); + return 0; + } + + return 1; +} + +static int json_callback_map_key(void *opaque, const unsigned char *str, + unsigned int len) +{ + libxl__yajl_ctx *ctx = opaque; + char *t = NULL; + libxl__json_object *obj = ctx->current; + + t = malloc(len + 1); + if (t == NULL) { + LIBXL__LOG_ERRNO(libxl__gc_owner(ctx->gc), LIBXL__LOG_ERROR, + "Failed to allocate"); + return 0; + } + + DEBUG_GEN_STRING(ctx, str, len); + + strncpy(t, (const char *) str, len); + t[len] = 0; + + if (libxl__json_object_is_map(obj)) { + libxl__json_map_node *node = malloc(sizeof (libxl__json_map_node)); + if (node == NULL) { + LIBXL__LOG_ERRNO(libxl__gc_owner(ctx->gc), LIBXL__LOG_ERROR, + "Failed to allocate"); + return 0; + } + + node->map_key = t; + node->obj = NULL; + + if (flexarray_append(obj->u.map, node) == 2) { + LIBXL__LOG_ERRNO(libxl__gc_owner(ctx->gc), LIBXL__LOG_ERROR, + "Failed to grow a flexarray"); + return 0; + } + } else { + LIBXL__LOG(libxl__gc_owner(ctx->gc), LIBXL__LOG_ERROR, + "Current json object is not a map"); + return 0; + } + + return 1; +} + +static int json_callback_start_map(void *opaque) +{ + libxl__yajl_ctx *ctx = opaque; + libxl__json_object *obj = NULL; + + DEBUG_GEN(ctx, map_open); + + if ((obj = json_object_alloc(ctx->gc, JSON_MAP)) == NULL) + return 0; + + if (ctx->current) { + if (json_object_append_to(ctx->gc, obj, ctx->current) == -1) { + libxl__json_object_free(ctx->gc, obj); + return 0; + } + } + + ctx->current = obj; + if (ctx->head == NULL) { + ctx->head = obj; + } + + return 1; +} + +static int json_callback_end_map(void *opaque) +{ + libxl__yajl_ctx *ctx = opaque; + + DEBUG_GEN(ctx, map_close); + + if (ctx->current) { + ctx->current = ctx->current->parent; + } else { + LIBXL__LOG(libxl__gc_owner(ctx->gc), LIBXL__LOG_ERROR, + "No current libxl__json_object, cannot use his parent."); + return 0; + } + + return 1; +} + +static int json_callback_start_array(void *opaque) +{ + libxl__yajl_ctx *ctx = opaque; + libxl__json_object *obj = NULL; + + DEBUG_GEN(ctx, array_open); + + if ((obj = json_object_alloc(ctx->gc, JSON_ARRAY)) == NULL) + return 0; + + if (ctx->current) { + if (json_object_append_to(ctx->gc, obj, ctx->current) == -1) { + libxl__json_object_free(ctx->gc, obj); + return 0; + } + } + + ctx->current = obj; + if (ctx->head == NULL) { + ctx->head = obj; + } + + return 1; +} + +static int json_callback_end_array(void *opaque) +{ + libxl__yajl_ctx *ctx = opaque; + + DEBUG_GEN(ctx, array_close); + + if (ctx->current) { + ctx->current = ctx->current->parent; + } else { + LIBXL__LOG(libxl__gc_owner(ctx->gc), LIBXL__LOG_ERROR, + "No current libxl__json_object, cannot use his parent."); + return 0; + } + + return 1; +} + +static yajl_callbacks callbacks = { + json_callback_null, + json_callback_boolean, + json_callback_integer, + json_callback_double, + NULL, + json_callback_string, + json_callback_start_map, + json_callback_map_key, + json_callback_end_map, + json_callback_start_array, + json_callback_end_array +}; + +static void yajl_ctx_free(libxl__yajl_ctx *yajl_ctx) +{ + if (yajl_ctx->hand) { + yajl_free(yajl_ctx->hand); + yajl_ctx->hand = NULL; + } + DEBUG_GEN_FREE(yajl_ctx); +} + +libxl__json_object *libxl__json_parse(libxl__gc *gc, const char *s) +{ + yajl_status status; + libxl__yajl_ctx yajl_ctx; + + memset(&yajl_ctx, 0, sizeof (yajl_ctx)); + yajl_ctx.gc = gc; + + DEBUG_GEN_ALLOC(&yajl_ctx); + + if (yajl_ctx.hand == NULL) { + yajl_parser_config cfg = { + .allowComments = 1, + .checkUTF8 = 1, + }; + yajl_ctx.hand = yajl_alloc(&callbacks, &cfg, NULL, &yajl_ctx); + } + status = yajl_parse(yajl_ctx.hand, (const unsigned char *)s, strlen(s)); + status = yajl_parse_complete(yajl_ctx.hand); + + if (status == yajl_status_ok) { + libxl__json_object *o = yajl_ctx.head; + + DEBUG_GEN_REPORT(&yajl_ctx); + + yajl_ctx.head = NULL; + + yajl_ctx_free(&yajl_ctx); + return o; + } else { + unsigned char *str = yajl_get_error(yajl_ctx.hand, 1, + (const unsigned char *)s, + strlen(s)); + + LIBXL__LOG(libxl__gc_owner(gc), LIBXL__LOG_ERROR, + "yajl error: %s", str); + yajl_free_error(yajl_ctx.hand, str); + + libxl__json_object_free(gc, yajl_ctx.head); + yajl_ctx_free(&yajl_ctx); + return NULL; + } +} -- Anthony PERARD _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel From xen-devel-bounces@lists.xensource.com Thu Sep 29 04:54:58 2011 Return-path: <xen-devel-bounces@lists.xensource.com> Envelope-to: www-data@lists.xensource.com Delivery-date: Thu, 29 Sep 2011 04:54:58 -0700 Received: from localhost ([127.0.0.1] helo=lists.colo.xensource.com) by lists.xensource.com with esmtp (Exim 4.43) id 1R9FCb-0003D1-PB; Thu, 29 Sep 2011 04:54:57 -0700 Received: from mail216.messagelabs.com ([85.158.143.99]) by lists.xensource.com with esmtp (Exim 4.43) id 1R9FBs-00030w-LN for xen-devel@lists.xensource.com; Thu, 29 Sep 2011 04:54:12 -0700 X-Env-Sender: Ian.Campbell@eu.citrix.com X-Msg-Ref: server-4.tower-216.messagelabs.com!1317297249!19976999!1 X-Originating-IP: [62.200.22.115] X-StarScan-Version: 6.4.1; banners=-,-,- X-VirusChecked: Checked Received: (qmail 3404 invoked from network); 29 Sep 2011 11:54:09 -0000 Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115) by server-4.tower-216.messagelabs.com with RC4-SHA encrypted SMTP; 29 Sep 2011 11:54:09 -0000 X-IronPort-AV: E=Sophos;i="4.68,460,1312156800"; d="scan'208";a="8126096" Received: from lonpmailmx01.citrite.net ([10.30.203.162]) by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5; 29 Sep 2011 11:54:09 +0000 Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net (10.30.203.162) with Microsoft SMTP Server id 8.3.137.0; Thu, 29 Sep 2011 12:54:09 +0100 From: Ian Campbell <Ian.Campbell@eu.citrix.com> To: Anthony PERARD <anthony.perard@citrix.com> Date: Thu, 29 Sep 2011 12:54:09 +0100 In-Reply-To: <1317296277-2838-8-git-send-email-anthony.perard@citrix.com> References: <1317296277-2838-1-git-send-email-anthony.perard@citrix.com> <1317296277-2838-8-git-send-email-anthony.perard@citrix.com> Organization: Citrix Systems, Inc. Content-Type: text/plain; charset="UTF-8" X-Mailer: Evolution 3.0.3- Content-Transfer-Encoding: 7bit Message-ID: <1317297249.26672.173.camel@zakaz.uk.xensource.com> MIME-Version: 1.0 Cc: Xen Devel <xen-devel@lists.xensource.com>, Stefano Stabellini <Stefano.Stabellini@eu.citrix.com> Subject: [Xen-devel] Re: [PATCH V9 7/7] libxl: Introduce a QMP client X-BeenThere: xen-devel@lists.xensource.com X-Mailman-Version: 2.1.5 Precedence: list List-Id: Xen developer discussion <xen-devel.lists.xensource.com> List-Unsubscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe> List-Post: <mailto:xen-devel@lists.xensource.com> List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help> List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=subscribe> Sender: xen-devel-bounces@lists.xensource.com Errors-To: xen-devel-bounces@lists.xensource.com On Thu, 2011-09-29 at 12:37 +0100, Anthony PERARD wrote: > > + qmp->qmp_fd = socket(AF_UNIX, SOCK_STREAM, 0); > + if (qmp->qmp_fd < 0) { > + return -1; > + } Is SOCK_CLOEXEC standard enough to use? Probably not. We should use FD_CLOEXEC though. Ian. _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel From xen-devel-bounces@lists.xensource.com Thu Sep 29 04:57:54 2011 Return-path: <xen-devel-bounces@lists.xensource.com> Envelope-to: www-data@lists.xensource.com Delivery-date: Thu, 29 Sep 2011 04:57:54 -0700 Received: from localhost ([127.0.0.1] helo=lists.colo.xensource.com) by lists.xensource.com with esmtp (Exim 4.43) id 1R9FFS-0003fz-Gp; Thu, 29 Sep 2011 04:57:54 -0700 Received: from mail27.messagelabs.com ([193.109.254.147]) by lists.xensource.com with esmtp (Exim 4.43) id 1R9FEB-0003PN-9S for xen-devel@lists.xensource.com; Thu, 29 Sep 2011 04:56:36 -0700 X-Env-Sender: joseph.glanville@orionvm.com.au X-Msg-Ref: server-4.tower-27.messagelabs.com!1317297371!42265905!1 X-Originating-IP: [209.85.210.171] X-StarScan-Version: 6.4.1; banners=-,-,- X-VirusChecked: Checked Received: (qmail 15891 invoked from network); 29 Sep 2011 11:56:12 -0000 Received: from mail-iy0-f171.google.com (HELO mail-iy0-f171.google.com) (209.85.210.171) by server-4.tower-27.messagelabs.com with RC4-SHA encrypted SMTP; 29 Sep 2011 11:56:12 -0000 Received: by iagv1 with SMTP id v1so848151iag.30 for <xen-devel@lists.xensource.com>; Thu, 29 Sep 2011 04:56:30 -0700 (PDT) MIME-Version: 1.0 Received: by 10.231.0.221 with SMTP id 29mr14883952ibc.56.1317297390122; Thu, 29 Sep 2011 04:56:30 -0700 (PDT) Received: by 10.231.170.15 with HTTP; Thu, 29 Sep 2011 04:56:30 -0700 (PDT) X-Originating-IP: [59.167.234.130] In-Reply-To: <CAOzFzEg8xJ9F9iohq3SP4n7xwyQkm42BQtTyNYc5v2CT0GvZqg@mail.gmail.com> References: <20110922130618.GA13238@phenom.oracle.com> <CAFLBxZaAaXTUtW5+VkxPnr_MR0fbW+d1Mzu4y0x=gEOaX9e0OQ@mail.gmail.com> <20110922174002.GA1205@phenom.oracle.com> <20098.1097.824552.541924@mariner.uk.xensource.com> <CAP2B85-=CbMgUGSwO2utvkeLLqk8A1vjhKrPwe2OD+0daAtqsA@mail.gmail.com> <1317195656.13424.73.camel@dagon.hellion.org.uk> <20099.8327.326129.357335@mariner.uk.xensource.com> <20110928134800.GH10270@phenom.oracle.com> <1317218459.26672.62.camel@zakaz.uk.xensource.com> <CAOzFzEhnr7Ri42V1AUMLw-xRn+9NQwu8Pkq8iPc=pS12w=Vnog@mail.gmail.com> <1317294104.26672.155.camel@zakaz.uk.xensource.com> <CAOzFzEhNZbnm0mr1-mSU+4em3Kd930qOjmApbAZQ+3MAhskhfw@mail.gmail.com> <1317295766.26672.169.camel@zakaz.uk.xensource.com> <CAOzFzEg8xJ9F9iohq3SP4n7xwyQkm42BQtTyNYc5v2CT0GvZqg@mail.gmail.com> Date: Thu, 29 Sep 2011 21:56:30 +1000 Message-ID: <CAOzFzEiGqn4TgjpHCMa8LcuiXz6mudcKQTKoFy9KEB3MNVZSvg@mail.gmail.com> Subject: Re: [Xen-devel] Xen document day (Oct 12 or 26) From: Joseph Glanville <joseph.glanville@orionvm.com.au> To: Ian Campbell <Ian.Campbell@eu.citrix.com> Cc: Daniel Castro <evil.dani@gmail.com>, Lars Kurth <lars.kurth@xen.org>, Ian Jackson <Ian.Jackson@eu.citrix.com>, "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>, Konrad Rzeszutek Wilk <konrad.wilk@oracle.com> X-BeenThere: xen-devel@lists.xensource.com X-Mailman-Version: 2.1.5 Precedence: list List-Id: Xen developer discussion <xen-devel.lists.xensource.com> List-Unsubscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe> List-Post: <mailto:xen-devel@lists.xensource.com> List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help> List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=subscribe> Content-Type: multipart/mixed; boundary="===============0976090896==" Sender: xen-devel-bounces@lists.xensource.com Errors-To: xen-devel-bounces@lists.xensource.com --===============0976090896== Content-Type: multipart/alternative; boundary=00151773d3d200764004ae1333b5 --00151773d3d200764004ae1333b5 Content-Type: text/plain; charset=ISO-8859-1 I have created a sheet with all of the wiki titles. The sheet is setup to mark pages as fine, outdated or inbuilt (stuff like userprofiles that are a part of moinmoin) You can access it with the link below: https://docs.google.com/spreadsheet/ccc?key=0AiRyVp8djqV3dEJRdVZaQzZmLVNKTERwMDNGaTlKdkE&hl=en_US On 29 September 2011 21:35, Joseph Glanville < joseph.glanville@orionvm.com.au> wrote: > Yeah MoinMoin is abit frustrating.. I am currently going through the pages > in the TitleIndex: > http://wiki.xen.org/xenwiki/TitleIndex > Marking pages as out-dated as a find them.. maybe it would be best to > create a google spreadsheet and mark their status in there to ease finding > what content is good vs bad? > How does that sound Lars/Ian? > > Joseph. > > > On 29 September 2011 21:29, Ian Campbell <Ian.Campbell@eu.citrix.com>wrote: > >> On Thu, 2011-09-29 at 12:24 +0100, Joseph Glanville wrote: >> > Maybe the wiki frontpage etc needs abit of a restructure to highlight >> > the newer documentation and try steer people away from old stuff? >> > I am going to try do some tagging of the wiki pages tonight to mark >> > what is out of date. >> > Many of the pages I think just need simplification.. the current wiki >> > is somewhat of an information overload (which is fine but we shouldn't >> > bombard new users if we can avoid it) >> >> I think Lars (now CC'd) is planning a switch to a new wiki platform >> since the current one is very long in the tooth and not especially >> capable. AIUI part of the transfer will involve discarding out of date >> stuff and better categorisation of correct/up-to-date pages etc. >> >> I'm not sure how the timescales for that transition compare with this >> documentathon though... >> >> Ian. >> >> > On 29 September 2011 21:01, Ian Campbell <Ian.Campbell@eu.citrix.com> >> > wrote: >> > On Thu, 2011-09-29 at 11:53 +0100, Joseph Glanville wrote: >> > > +1 for Markdown. >> > > >> > > In terms of making Xen more accessible I think it might be a >> > good idea >> > > to update/cleanup the distro support page. >> > > http://wiki.xen.org/xenwiki/DistributionSupport >> > > >> > > I can probably do this. >> > >> > >> > Excellent, it looks like it needs it... >> > >> > > Making it simple for people to get started with Xen on a >> > distro they >> > > are comfortable with is a good step forward. >> > >> > >> > Agreed. In fact for many users this is probably the end goal, >> > not just a >> > step along the way. >> > >> > > I know distro specific guides could turn into a nightmare >> > but I am >> > > open to writing one for Debian 6 Squeeze, >> > >> > >> > In cases such as this we should also consider updating the >> > distro's wiki >> > page. I'm not sure where the canonical guide should live >> > (wiki.xen.org >> > or wiki.debian.org) but they should certainly cross reference >> > each >> > other. >> > >> > Yeah that's a tricky one, I guess we can start at wiki.xen.org and go >> > from there. >> > Seeing as Debian repackages Xen, wiki.debian.org should probably be >> > the final canonical location. >> > >> > >> > >> > > there are also a few that exist already for RHEL/CentOS on >> > the wiki. >> > > This should get easier as more distros update to 3.0+ >> > kernels that >> > > support PVops out of the box... >> > > >> > > Next would be networking documentation as network-bridge >> > script has >> > > been deprecated. >> > > http://wiki.xensource.com/xenwiki/XenNetworking >> > > Once again I think alot of the documentation is going to be >> > distro >> > > specific to be newbie friendly but atleast a simple ip/brctl >> > guide >> > > would help. >> > > >> > > IMO knowing where to start and setting up networking were >> > the biggest >> > > barriers when I was picking up Xen a few years back. >> > >> > >> > We now have >> > http://wiki.xensource.com/xenwiki/HostConfiguration/Networking >> > which >> > could do with being made more discoverable. >> > >> > That is -much- better and as you said should be much easier to find.. >> > >> > >> > There is also >> > http://wiki.xensource.com/xenwiki/HostConfiguration but >> > its looking pretty sad right now... >> > >> > I can think of some stuff to fill that up. >> > eg. Howto enable live migration, local VM storage guide possibly >> > >> > >> > >> > > >> > > I am also open to updating the blktap2 pages and README to >> > reflect the >> > > new tap-ctl userspace utilities and tips on driver >> > development. >> > > >> > > <slightly off-topic but related> >> > > >> > > With jailtime.org(stacklet) now charging for subscription >> > there is >> > > nowhere to download pre-built clean Xen compatible images >> > free of >> > > charge etc. >> > > I have pvgrub/pygrub capable images of Ubuntu/Debian/CentOS >> > that I am >> > > considering hosting for free. >> > > Generally new users are confused on how to build new >> > paravirt VMs, I >> > > think prebuilt images are suboptimal but a good place to >> > start for >> > > beginners. >> > >> > >> > There was discussion of Debian providing such a thing on >> > debian-deval >> > back in late July, I should chase that up really. >> > >> > Cheers, >> > Ian. >> > >> > >> > > >> > > Joseph. >> > > >> > > On 29 September 2011 00:00, Ian Campbell >> > <Ian.Campbell@eu.citrix.com> >> > > wrote: >> > > On Wed, 2011-09-28 at 14:48 +0100, Konrad Rzeszutek >> > Wilk >> > > wrote: >> > > > On Wed, Sep 28, 2011 at 02:26:31PM +0100, Ian >> > Jackson wrote: >> > > > > Ian Campbell writes ("Re: [Xen-devel] Xen >> > document day >> > > (Oct 12 or 26)"): >> > > > > > Since the guest APIs are stable there should >> > be >> > > relatively little churn >> > > > > > so perhaps a wiki page (or even series of >> > pages) would >> > > be appropriate >> > > > > > for this sort of thing? >> > > > > >> > > > > I want this to be in-tree. If it's in-tree, we >> > can refuse >> > > patches >> > > > > which do not update the documentation. >> > > > > >> > > > > > I think this would be good too and in fact >> > even more >> > > important than the >> > > > > > interface documentation. Everyone needs to be >> > able to >> > > build Xen to hack >> > > > > > on it but only a subset need to know any >> > particular API. >> > > > > > >> > > > > > Also although we recommend that users consume >> > Xen via >> > > their distro where >> > > > > > possible such a guide would also help any who >> > would >> > > rather build from >> > > > > > scratch (e.g. because we've asked them to "try >> > the >> > > latest version" or to >> > > > > > bisect a bug etc). >> > > > > >> > > > > This would be a good candidate for a wiki page, >> > backed up >> > > by revisions >> > > > > of the in-tree README. >> > > > >> > > > >> > > > Any recommendations on what would be a good format >> > to write >> > > these "interface" >> > > > pages in? >> > > >> > > >> > > For in-line (i.e. in xen/include/public/*.h) docs of >> > APIs I >> > > played a >> > > little bit with integrating kernel-doc into the Xen >> > build >> > > system but it >> > > is tied a little too closely to the kernel build >> > > infrastructure. >> > > >> > > Doxygen seems like a plausible alternative with life >> > outside >> > > the kernel >> > > etc. We actually appear to already have some doxygen >> > stuff for >> > > the >> > > pytyhon stuff (judging from the Makefile, I've not >> > actually >> > > noticed the >> > > structured code comments anywhere) >> > > >> > > For non-inline docs I think we decided that markdown >> > would be >> > > a good >> > > answer. >> > > >> > > Ian. >> > > >> > > >> > > >> > > _______________________________________________ >> > > Xen-devel mailing list >> > > Xen-devel@lists.xensource.com >> > > http://lists.xensource.com/xen-devel >> > > >> > > >> > > >> > > >> > > -- >> > > Founder | Director | VP Research >> > > >> > > Orion Virtualisation Solutions | www.orionvm.com.au | Phone: >> > 1300 56 >> > > 99 52 | Mobile: 0428 754 846 >> > >> > >> > >> > >> > >> > >> > -- >> > Founder | Director | VP Research >> > >> > Orion Virtualisation Solutions | www.orionvm.com.au | Phone: 1300 56 >> > 99 52 | Mobile: 0428 754 846 >> >> >> > > > -- > * > Founder | Director | VP Research > Orion Virtualisation Solutions* | www.orionvm.com.au | Phone: 1300 56 99 > 52 | Mobile: 0428 754 846 > -- * Founder | Director | VP Research Orion Virtualisation Solutions* | www.orionvm.com.au | Phone: 1300 56 99 52 | Mobile: 0428 754 846 --00151773d3d200764004ae1333b5 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable I have created a sheet with all of the wiki titles.<br>The sheet is setup t= o mark pages as fine, outdated or inbuilt (stuff like userprofiles that are= a part of moinmoin)<br>You can access it with the link below:<br><a href= =3D"https://docs.google.com/spreadsheet/ccc?key=3D0AiRyVp8djqV3dEJRdVZaQzZm= LVNKTERwMDNGaTlKdkE&hl=3Den_US">https://docs.google.com/spreadsheet/ccc= ?key=3D0AiRyVp8djqV3dEJRdVZaQzZmLVNKTERwMDNGaTlKdkE&hl=3Den_US</a><br> <br><div class=3D"gmail_quote">On 29 September 2011 21:35, Joseph Glanville= <span dir=3D"ltr"><<a href=3D"mailto:joseph.glanville@orionvm.com.au">j= oseph.glanville@orionvm.com.au</a>></span> wrote:<br><blockquote class= =3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padd= ing-left:1ex;"> Yeah MoinMoin is abit frustrating.. I am currently going through the pages = in the TitleIndex:<br><a href=3D"http://wiki.xen.org/xenwiki/TitleIndex" ta= rget=3D"_blank">http://wiki.xen.org/xenwiki/TitleIndex</a><br>Marking pages= as out-dated as a find them.. maybe it would be best to create a google sp= readsheet and mark their status in there to ease finding what content is go= od vs bad?<br> How does that sound Lars/Ian?<br><font color=3D"#888888"><br>Joseph.</font>= <div><div></div><div class=3D"h5"><br><br><div class=3D"gmail_quote">On 29 = September 2011 21:29, Ian Campbell <span dir=3D"ltr"><<a href=3D"mailto:= Ian.Campbell@eu.citrix.com" target=3D"_blank">Ian.Campbell@eu.citrix.com</a= >></span> wrote:<br> <blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1p= x #ccc solid;padding-left:1ex"><div>On Thu, 2011-09-29 at 12:24 +0100, Jose= ph Glanville wrote:<br> > Maybe the wiki frontpage etc needs abit of a restructure to highlight<= br> > the newer documentation and try steer people away from old stuff?<br> > I am going to try do some tagging of the wiki pages tonight to mark<br= > > what is out of date.<br> > Many of the pages I think just need simplification.. the current wiki<= br> > is somewhat of an information overload (which is fine but we shouldn&#= 39;t<br> > bombard new users if we can avoid it)<br> <br> </div>I think Lars (now CC'd) is planning a switch to a new wiki platfo= rm<br> since the current one is very long in the tooth and not especially<br> capable. AIUI part of the transfer will involve discarding out of date<br> stuff and better categorisation of correct/up-to-date pages etc.<br> <br> I'm not sure how the timescales for that transition compare with this<b= r> documentathon though...<br> <font color=3D"#888888"><br> Ian.<br> </font><div><div></div><div><br> > On 29 September 2011 21:01, Ian Campbell <<a href=3D"mailto:Ian.Cam= pbell@eu.citrix.com" target=3D"_blank">Ian.Campbell@eu.citrix.com</a>><b= r> > wrote:<br> > =A0 =A0 =A0 =A0 On Thu, 2011-09-29 at 11:53 +0100, Joseph Glanville wr= ote:<br> > =A0 =A0 =A0 =A0 > +1 for Markdown.<br> > =A0 =A0 =A0 =A0 ><br> > =A0 =A0 =A0 =A0 > In terms of making Xen more accessible I think it= might be a<br> > =A0 =A0 =A0 =A0 good idea<br> > =A0 =A0 =A0 =A0 > to update/cleanup the distro support page.<br> > =A0 =A0 =A0 =A0 > <a href=3D"http://wiki.xen.org/xenwiki/Distributi= onSupport" target=3D"_blank">http://wiki.xen.org/xenwiki/DistributionSuppor= t</a><br> > =A0 =A0 =A0 =A0 ><br> > =A0 =A0 =A0 =A0 > I can probably do this.<br> ><br> ><br> > =A0 =A0 =A0 =A0 Excellent, it looks like it needs it...<br> ><br> > =A0 =A0 =A0 =A0 > Making it simple for people to get started with X= en on a<br> > =A0 =A0 =A0 =A0 distro they<br> > =A0 =A0 =A0 =A0 > are comfortable with is a good step forward.<br> ><br> ><br> > =A0 =A0 =A0 =A0 Agreed. In fact for many users this is probably the en= d goal,<br> > =A0 =A0 =A0 =A0 not just a<br> > =A0 =A0 =A0 =A0 step along the way.<br> ><br> > =A0 =A0 =A0 =A0 > I know distro specific guides could turn into a n= ightmare<br> > =A0 =A0 =A0 =A0 but I am<br> > =A0 =A0 =A0 =A0 > open to writing one for Debian 6 Squeeze,<br> ><br> ><br> > =A0 =A0 =A0 =A0 In cases such as this we should also consider updating= the<br> > =A0 =A0 =A0 =A0 distro's wiki<br> > =A0 =A0 =A0 =A0 page. I'm not sure where the canonical guide shoul= d live<br> > =A0 =A0 =A0 =A0 (<a href=3D"http://wiki.xen.org" target=3D"_blank">wik= i.xen.org</a><br> > =A0 =A0 =A0 =A0 or <a href=3D"http://wiki.debian.org" target=3D"_blank= ">wiki.debian.org</a>) but they should certainly cross reference<br> > =A0 =A0 =A0 =A0 each<br> > =A0 =A0 =A0 =A0 other.<br> ><br> > Yeah that's a tricky one, I guess we can start at <a href=3D"http:= //wiki.xen.org" target=3D"_blank">wiki.xen.org</a> and go<br> > from there.<br> > Seeing as Debian repackages Xen, <a href=3D"http://wiki.debian.org" ta= rget=3D"_blank">wiki.debian.org</a> should probably be<br> > the final canonical location.<br> ><br> ><br> ><br> > =A0 =A0 =A0 =A0 > =A0there are also a few that exist already for RH= EL/CentOS on<br> > =A0 =A0 =A0 =A0 the wiki.<br> > =A0 =A0 =A0 =A0 > This should get easier as more distros update to = 3.0+<br> > =A0 =A0 =A0 =A0 kernels that<br> > =A0 =A0 =A0 =A0 > support PVops out of the box...<br> > =A0 =A0 =A0 =A0 ><br> > =A0 =A0 =A0 =A0 > Next would be networking documentation as network= -bridge<br> > =A0 =A0 =A0 =A0 script has<br> > =A0 =A0 =A0 =A0 > been deprecated.<br> > =A0 =A0 =A0 =A0 > <a href=3D"http://wiki.xensource.com/xenwiki/XenN= etworking" target=3D"_blank">http://wiki.xensource.com/xenwiki/XenNetworkin= g</a><br> > =A0 =A0 =A0 =A0 > Once again I think alot of the documentation is g= oing to be<br> > =A0 =A0 =A0 =A0 distro<br> > =A0 =A0 =A0 =A0 > specific to be newbie friendly but atleast a simp= le ip/brctl<br> > =A0 =A0 =A0 =A0 guide<br> > =A0 =A0 =A0 =A0 > would help.<br> > =A0 =A0 =A0 =A0 ><br> > =A0 =A0 =A0 =A0 > IMO knowing where to start and setting up network= ing were<br> > =A0 =A0 =A0 =A0 the biggest<br> > =A0 =A0 =A0 =A0 > barriers when I was picking up Xen a few years ba= ck.<br> ><br> ><br> > =A0 =A0 =A0 =A0 We now have<br> > =A0 =A0 =A0 =A0 <a href=3D"http://wiki.xensource.com/xenwiki/HostConfi= guration/Networking" target=3D"_blank">http://wiki.xensource.com/xenwiki/Ho= stConfiguration/Networking</a><br> > =A0 =A0 =A0 =A0 which<br> > =A0 =A0 =A0 =A0 could do with being made more discoverable.<br> ><br> > That is -much- better and as you said should be much easier to find..<= br> ><br> ><br> > =A0 =A0 =A0 =A0 There is also<br> > =A0 =A0 =A0 =A0 <a href=3D"http://wiki.xensource.com/xenwiki/HostConfi= guration" target=3D"_blank">http://wiki.xensource.com/xenwiki/HostConfigura= tion</a> but<br> > =A0 =A0 =A0 =A0 its looking pretty sad right now...<br> ><br> > I can think of some stuff to fill that up.<br> > eg. Howto enable live migration, local VM storage guide possibly<br> ><br> ><br> ><br> > =A0 =A0 =A0 =A0 ><br> > =A0 =A0 =A0 =A0 > I am also open to updating the blktap2 pages and = README to<br> > =A0 =A0 =A0 =A0 reflect the<br> > =A0 =A0 =A0 =A0 > new tap-ctl userspace utilities and tips on drive= r<br> > =A0 =A0 =A0 =A0 development.<br> > =A0 =A0 =A0 =A0 ><br> > =A0 =A0 =A0 =A0 > <slightly off-topic but related><br> > =A0 =A0 =A0 =A0 ><br> > =A0 =A0 =A0 =A0 > With <a href=3D"http://jailtime.org" target=3D"_b= lank">jailtime.org</a>(stacklet) now charging for subscription<br> > =A0 =A0 =A0 =A0 there is<br> > =A0 =A0 =A0 =A0 > nowhere to download pre-built clean Xen compatibl= e images<br> > =A0 =A0 =A0 =A0 free of<br> > =A0 =A0 =A0 =A0 > charge etc.<br> > =A0 =A0 =A0 =A0 > I have pvgrub/pygrub capable images of Ubuntu/Deb= ian/CentOS<br> > =A0 =A0 =A0 =A0 that I am<br> > =A0 =A0 =A0 =A0 > considering hosting for free.<br> > =A0 =A0 =A0 =A0 > Generally new users are confused on how to build = new<br> > =A0 =A0 =A0 =A0 paravirt VMs, I<br> > =A0 =A0 =A0 =A0 > think prebuilt images are suboptimal but a good p= lace to<br> > =A0 =A0 =A0 =A0 start for<br> > =A0 =A0 =A0 =A0 > beginners.<br> ><br> ><br> > =A0 =A0 =A0 =A0 There was discussion of Debian providing such a thing = on<br> > =A0 =A0 =A0 =A0 debian-deval<br> > =A0 =A0 =A0 =A0 back in late July, I should chase that up really.<br> ><br> > =A0 =A0 =A0 =A0 Cheers,<br> > =A0 =A0 =A0 =A0 Ian.<br> ><br> ><br> > =A0 =A0 =A0 =A0 ><br> > =A0 =A0 =A0 =A0 > Joseph.<br> > =A0 =A0 =A0 =A0 ><br> > =A0 =A0 =A0 =A0 > On 29 September 2011 00:00, Ian Campbell<br> > =A0 =A0 =A0 =A0 <<a href=3D"mailto:Ian.Campbell@eu.citrix.com" targ= et=3D"_blank">Ian.Campbell@eu.citrix.com</a>><br> > =A0 =A0 =A0 =A0 > wrote:<br> > =A0 =A0 =A0 =A0 > =A0 =A0 =A0 =A0 On Wed, 2011-09-28 at 14:48 +0100= , Konrad Rzeszutek<br> > =A0 =A0 =A0 =A0 Wilk<br> > =A0 =A0 =A0 =A0 > =A0 =A0 =A0 =A0 wrote:<br> > =A0 =A0 =A0 =A0 > =A0 =A0 =A0 =A0 > On Wed, Sep 28, 2011 at 02:2= 6:31PM +0100, Ian<br> > =A0 =A0 =A0 =A0 Jackson wrote:<br> > =A0 =A0 =A0 =A0 > =A0 =A0 =A0 =A0 > > Ian Campbell writes (&q= uot;Re: [Xen-devel] Xen<br> > =A0 =A0 =A0 =A0 document day<br> > =A0 =A0 =A0 =A0 > =A0 =A0 =A0 =A0 (Oct 12 or 26)"):<br> > =A0 =A0 =A0 =A0 > =A0 =A0 =A0 =A0 > > > Since the guest AP= Is are stable there should<br> > =A0 =A0 =A0 =A0 be<br> > =A0 =A0 =A0 =A0 > =A0 =A0 =A0 =A0 relatively little churn<br> > =A0 =A0 =A0 =A0 > =A0 =A0 =A0 =A0 > > > so perhaps a wiki = page (or even series of<br> > =A0 =A0 =A0 =A0 pages) would<br> > =A0 =A0 =A0 =A0 > =A0 =A0 =A0 =A0 be appropriate<br> > =A0 =A0 =A0 =A0 > =A0 =A0 =A0 =A0 > > > for this sort of t= hing?<br> > =A0 =A0 =A0 =A0 > =A0 =A0 =A0 =A0 > ><br> > =A0 =A0 =A0 =A0 > =A0 =A0 =A0 =A0 > > I want this to be in-tr= ee. =A0If it's in-tree, we<br> > =A0 =A0 =A0 =A0 can refuse<br> > =A0 =A0 =A0 =A0 > =A0 =A0 =A0 =A0 patches<br> > =A0 =A0 =A0 =A0 > =A0 =A0 =A0 =A0 > > which do not update the= documentation.<br> > =A0 =A0 =A0 =A0 > =A0 =A0 =A0 =A0 > ><br> > =A0 =A0 =A0 =A0 > =A0 =A0 =A0 =A0 > > > I think this would= be good too and in fact<br> > =A0 =A0 =A0 =A0 even more<br> > =A0 =A0 =A0 =A0 > =A0 =A0 =A0 =A0 important than the<br> > =A0 =A0 =A0 =A0 > =A0 =A0 =A0 =A0 > > > interface document= ation. Everyone needs to be<br> > =A0 =A0 =A0 =A0 able to<br> > =A0 =A0 =A0 =A0 > =A0 =A0 =A0 =A0 build Xen to hack<br> > =A0 =A0 =A0 =A0 > =A0 =A0 =A0 =A0 > > > on it but only a s= ubset need to know any<br> > =A0 =A0 =A0 =A0 particular API.<br> > =A0 =A0 =A0 =A0 > =A0 =A0 =A0 =A0 > > ><br> > =A0 =A0 =A0 =A0 > =A0 =A0 =A0 =A0 > > > Also although we r= ecommend that users consume<br> > =A0 =A0 =A0 =A0 Xen via<br> > =A0 =A0 =A0 =A0 > =A0 =A0 =A0 =A0 their distro where<br> > =A0 =A0 =A0 =A0 > =A0 =A0 =A0 =A0 > > > possible such a gu= ide would also help any who<br> > =A0 =A0 =A0 =A0 would<br> > =A0 =A0 =A0 =A0 > =A0 =A0 =A0 =A0 rather build from<br> > =A0 =A0 =A0 =A0 > =A0 =A0 =A0 =A0 > > > scratch (e.g. beca= use we've asked them to "try<br> > =A0 =A0 =A0 =A0 the<br> > =A0 =A0 =A0 =A0 > =A0 =A0 =A0 =A0 latest version" or to<br> > =A0 =A0 =A0 =A0 > =A0 =A0 =A0 =A0 > > > bisect a bug etc).= <br> > =A0 =A0 =A0 =A0 > =A0 =A0 =A0 =A0 > ><br> > =A0 =A0 =A0 =A0 > =A0 =A0 =A0 =A0 > > This would be a good ca= ndidate for a wiki page,<br> > =A0 =A0 =A0 =A0 backed up<br> > =A0 =A0 =A0 =A0 > =A0 =A0 =A0 =A0 by revisions<br> > =A0 =A0 =A0 =A0 > =A0 =A0 =A0 =A0 > > of the in-tree README.<= br> > =A0 =A0 =A0 =A0 > =A0 =A0 =A0 =A0 ><br> > =A0 =A0 =A0 =A0 > =A0 =A0 =A0 =A0 ><br> > =A0 =A0 =A0 =A0 > =A0 =A0 =A0 =A0 > Any recommendations on what = would be a good format<br> > =A0 =A0 =A0 =A0 to write<br> > =A0 =A0 =A0 =A0 > =A0 =A0 =A0 =A0 these "interface"<br> > =A0 =A0 =A0 =A0 > =A0 =A0 =A0 =A0 > pages in?<br> > =A0 =A0 =A0 =A0 ><br> > =A0 =A0 =A0 =A0 ><br> > =A0 =A0 =A0 =A0 > =A0 =A0 =A0 =A0 For in-line (i.e. in xen/include/= public/*.h) docs of<br> > =A0 =A0 =A0 =A0 APIs I<br> > =A0 =A0 =A0 =A0 > =A0 =A0 =A0 =A0 played a<br> > =A0 =A0 =A0 =A0 > =A0 =A0 =A0 =A0 little bit with integrating kerne= l-doc into the Xen<br> > =A0 =A0 =A0 =A0 build<br> > =A0 =A0 =A0 =A0 > =A0 =A0 =A0 =A0 system but it<br> > =A0 =A0 =A0 =A0 > =A0 =A0 =A0 =A0 is tied a little too closely to t= he kernel build<br> > =A0 =A0 =A0 =A0 > =A0 =A0 =A0 =A0 infrastructure.<br> > =A0 =A0 =A0 =A0 ><br> > =A0 =A0 =A0 =A0 > =A0 =A0 =A0 =A0 Doxygen seems like a plausible al= ternative with life<br> > =A0 =A0 =A0 =A0 outside<br> > =A0 =A0 =A0 =A0 > =A0 =A0 =A0 =A0 the kernel<br> > =A0 =A0 =A0 =A0 > =A0 =A0 =A0 =A0 etc. We actually appear to alread= y have some doxygen<br> > =A0 =A0 =A0 =A0 stuff for<br> > =A0 =A0 =A0 =A0 > =A0 =A0 =A0 =A0 the<br> > =A0 =A0 =A0 =A0 > =A0 =A0 =A0 =A0 pytyhon stuff (judging from the M= akefile, I've not<br> > =A0 =A0 =A0 =A0 actually<br> > =A0 =A0 =A0 =A0 > =A0 =A0 =A0 =A0 noticed the<br> > =A0 =A0 =A0 =A0 > =A0 =A0 =A0 =A0 structured code comments anywhere= )<br> > =A0 =A0 =A0 =A0 ><br> > =A0 =A0 =A0 =A0 > =A0 =A0 =A0 =A0 For non-inline docs I think we de= cided that markdown<br> > =A0 =A0 =A0 =A0 would be<br> > =A0 =A0 =A0 =A0 > =A0 =A0 =A0 =A0 a good<br> > =A0 =A0 =A0 =A0 > =A0 =A0 =A0 =A0 answer.<br> > =A0 =A0 =A0 =A0 ><br> > =A0 =A0 =A0 =A0 > =A0 =A0 =A0 =A0 Ian.<br> > =A0 =A0 =A0 =A0 ><br> > =A0 =A0 =A0 =A0 ><br> > =A0 =A0 =A0 =A0 ><br> > =A0 =A0 =A0 =A0 > =A0 =A0 =A0 =A0 _________________________________= ______________<br> > =A0 =A0 =A0 =A0 > =A0 =A0 =A0 =A0 Xen-devel mailing list<br> > =A0 =A0 =A0 =A0 > =A0 =A0 =A0 =A0 <a href=3D"mailto:Xen-devel@lists= .xensource.com" target=3D"_blank">Xen-devel@lists.xensource.com</a><br> > =A0 =A0 =A0 =A0 > =A0 =A0 =A0 =A0 <a href=3D"http://lists.xensource= .com/xen-devel" target=3D"_blank">http://lists.xensource.com/xen-devel</a><= br> > =A0 =A0 =A0 =A0 ><br> > =A0 =A0 =A0 =A0 ><br> > =A0 =A0 =A0 =A0 ><br> > =A0 =A0 =A0 =A0 ><br> > =A0 =A0 =A0 =A0 > --<br> > =A0 =A0 =A0 =A0 > Founder | Director | VP Research<br> > =A0 =A0 =A0 =A0 ><br> > =A0 =A0 =A0 =A0 > Orion Virtualisation Solutions | <a href=3D"http:= //www.orionvm.com.au" target=3D"_blank">www.orionvm.com.au</a> | Phone:<br> > =A0 =A0 =A0 =A0 1300 56<br> > =A0 =A0 =A0 =A0 > 99 52 | Mobile: 0428 754 846<br> ><br> ><br> ><br> ><br> ><br> ><br> > --<br> > Founder | Director | VP Research<br> ><br> > Orion Virtualisation Solutions | <a href=3D"http://www.orionvm.com.au"= target=3D"_blank">www.orionvm.com.au</a> | Phone: 1300 56<br> > 99 52 | Mobile: 0428 754 846<br> <br> <br> </div></div></blockquote></div><br><br clear=3D"all"><br>-- <br><span style= =3D"font-family:arial,sans-serif;font-size:13px;border-collapse:collapse"><= b><i><font color=3D"#0000ff"><div><font color=3D"#000000"><span style=3D"fo= nt-style:normal;font-weight:normal">Founder | Director | VP Research<br> </span></font></div>Orion Virtualisation Solutions</font></i></b>=A0|=A0<fo= nt color=3D"#0000ff"><a href=3D"http://www.orionvm.com.au/" style=3D"color:= rgb(42, 93, 176)" target=3D"_blank">www.orionvm.com.au</a></font>=A0| Phone= : 1300 56 99 52 | Mobile: 0428 754 846</span><br> </div></div></blockquote></div><br><br clear=3D"all"><br>-- <br><span style= =3D"font-family:arial,sans-serif;font-size:13px;border-collapse:collapse"><= b><i><font color=3D"#0000ff"><div><font color=3D"#000000"><span style=3D"fo= nt-style:normal;font-weight:normal">Founder | Director | VP Research<br> </span></font></div>Orion Virtualisation Solutions</font></i></b>=A0|=A0<fo= nt color=3D"#0000ff"><a href=3D"http://www.orionvm.com.au/" style=3D"color:= rgb(42, 93, 176)" target=3D"_blank">www.orionvm.com.au</a></font>=A0| Phone= : 1300 56 99 52 | Mobile: 0428 754 846</span><br> --00151773d3d200764004ae1333b5-- --===============0976090896== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel --===============0976090896==-- From xen-devel-bounces@lists.xensource.com Thu Sep 29 05:02:59 2011 Return-path: <xen-devel-bounces@lists.xensource.com> Envelope-to: www-data@lists.xensource.com Delivery-date: Thu, 29 Sep 2011 05:02:59 -0700 Received: from localhost ([127.0.0.1] helo=lists.colo.xensource.com) by lists.xensource.com with esmtp (Exim 4.43) id 1R9FKN-0004DG-F8; Thu, 29 Sep 2011 05:02:59 -0700 Received: from mail216.messagelabs.com ([85.158.143.99]) by lists.xensource.com with esmtp (Exim 4.43) id 1R9FGe-0003re-7M for xen-devel@lists.xensource.com; Thu, 29 Sep 2011 04:59:09 -0700 X-Env-Sender: linux@eikelenboom.it X-Msg-Ref: server-6.tower-216.messagelabs.com!1317297544!18730094!1 X-Originating-IP: [188.40.164.121] X-StarScan-Version: 6.4.1; banners=-,-,- X-VirusChecked: Checked Received: (qmail 23557 invoked from network); 29 Sep 2011 11:59:04 -0000 Received: from static.121.164.40.188.clients.your-server.de (HELO smtp.eikelenboom.it) (188.40.164.121) by server-6.tower-216.messagelabs.com with AES256-SHA encrypted SMTP; 29 Sep 2011 11:59:04 -0000 Received: from 231-79-ftth.onsneteindhoven.nl ([88.159.79.231]:59063 helo=[172.16.1.220]) by smtp.eikelenboom.it with esmtpsa (TLS1.0:RSA_AES_256_CBC_SHA1:32) (Exim 4.72) (envelope-from <linux@eikelenboom.it>) id 1R9FES-0001ct-OV; Thu, 29 Sep 2011 13:56:52 +0200 Date: Thu, 29 Sep 2011 13:59:02 +0200 From: Sander Eikelenboom <linux@eikelenboom.it> Organization: Eikelenboom IT services X-Priority: 3 (Normal) Message-ID: <6410589313.20110929135902@eikelenboom.it> To: Joseph Glanville <joseph.glanville@orionvm.com.au> Subject: Re: [Xen-devel] Xen document day (Oct 12 or 26) In-Reply-To: <CAOzFzEhnr7Ri42V1AUMLw-xRn+9NQwu8Pkq8iPc=pS12w=Vnog@mail.gmail.com> References: <20110922130618.GA13238@phenom.oracle.com> <CAFLBxZaAaXTUtW5+VkxPnr_MR0fbW+d1Mzu4y0x=gEOaX9e0OQ@mail.gmail.com> <20110922174002.GA1205@phenom.oracle.com> <20098.1097.824552.541924@mariner.uk.xensource.com> <CAP2B85-=CbMgUGSwO2utvkeLLqk8A1vjhKrPwe2OD+0daAtqsA@mail.gmail.com> <1317195656.13424.73.camel@dagon.hellion.org.uk> <20099.8327.326129.357335@mariner.uk.xensource.com> <20110928134800.GH10270@phenom.oracle.com> <1317218459.26672.62.camel@zakaz.uk.xensource.com> <CAOzFzEhnr7Ri42V1AUMLw-xRn+9NQwu8Pkq8iPc=pS12w=Vnog@mail.gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable Cc: Ian Campbell <Ian.Campbell@eu.citrix.com>, Daniel Castro <evil.dani@gmail.com>, "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>, Ian Jackson <Ian.Jackson@eu.citrix.com>, Konrad Rzeszutek Wilk <konrad.wilk@oracle.com> X-BeenThere: xen-devel@lists.xensource.com X-Mailman-Version: 2.1.5 Precedence: list List-Id: Xen developer discussion <xen-devel.lists.xensource.com> List-Unsubscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe> List-Post: <mailto:xen-devel@lists.xensource.com> List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help> List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=subscribe> Sender: xen-devel-bounces@lists.xensource.com Errors-To: xen-devel-bounces@lists.xensource.com Hello Joseph, Thursday, September 29, 2011, 12:53:47 PM, you wrote: > +1 for Markdown. > In terms of making Xen more accessible I think it might be a good idea to > update/cleanup the distro support page. > http://wiki.xen.org/xenwiki/DistributionSupport > I can probably do this. > Making it simple for people to get started with Xen on a distro they are > comfortable with is a good step forward. > I know distro specific guides could turn into a nightmare but I am open to > writing one for Debian 6 Squeeze, there are also a few that exist already > for RHEL/CentOS on the wiki. > This should get easier as more distros update to 3.0+ kernels that support > PVops out of the box... > Next would be networking documentation as network-bridge script has been > deprecated. > http://wiki.xensource.com/xenwiki/XenNetworking > Once again I think alot of the documentation is going to be distro specif= ic > to be newbie friendly but atleast a simple ip/brctl guide would help. > IMO knowing where to start and setting up networking were the biggest > barriers when I was picking up Xen a few years back. > I am also open to updating the blktap2 pages and README to reflect the new > tap-ctl userspace utilities and tips on driver development. > <slightly off-topic but related> > With jailtime.org(stacklet) now charging for subscription there is nowhere > to download pre-built clean Xen compatible images free of charge etc. > I have pvgrub/pygrub capable images of Ubuntu/Debian/CentOS that I am > considering hosting for free. > Generally new users are confused on how to build new paravirt VMs, I think > prebuilt images are suboptimal but a good place to start for beginners. I have previously used the debian xen-tools package, which installs Ubuntu= /Debian/CentOS, although i don't remember exactly from what source. > Joseph. > On 29 September 2011 00:00, Ian Campbell <Ian.Campbell@eu.citrix.com> wro= te: >> On Wed, 2011-09-28 at 14:48 +0100, Konrad Rzeszutek Wilk wrote: >> > On Wed, Sep 28, 2011 at 02:26:31PM +0100, Ian Jackson wrote: >> > > Ian Campbell writes ("Re: [Xen-devel] Xen document day (Oct 12 or >> 26)"): >> > > > Since the guest APIs are stable there should be relatively little >> churn >> > > > so perhaps a wiki page (or even series of pages) would be appropri= ate >> > > > for this sort of thing? >> > > >> > > I want this to be in-tree. If it's in-tree, we can refuse patches >> > > which do not update the documentation. >> > > >> > > > I think this would be good too and in fact even more important than >> the >> > > > interface documentation. Everyone needs to be able to build Xen to >> hack >> > > > on it but only a subset need to know any particular API. >> > > > >> > > > Also although we recommend that users consume Xen via their distro >> where >> > > > possible such a guide would also help any who would rather build f= rom >> > > > scratch (e.g. because we've asked them to "try the latest version"= or >> to >> > > > bisect a bug etc). >> > > >> > > This would be a good candidate for a wiki page, backed up by revisio= ns >> > > of the in-tree README. >> > >> > >> > Any recommendations on what would be a good format to write these >> "interface" >> > pages in? >> >> For in-line (i.e. in xen/include/public/*.h) docs of APIs I played a >> little bit with integrating kernel-doc into the Xen build system but it >> is tied a little too closely to the kernel build infrastructure. >> >> Doxygen seems like a plausible alternative with life outside the kernel >> etc. We actually appear to already have some doxygen stuff for the >> pytyhon stuff (judging from the Makefile, I've not actually noticed the >> structured code comments anywhere) >> >> For non-inline docs I think we decided that markdown would be a good >> answer. >> >> Ian. >> >> >> _______________________________________________ >> Xen-devel mailing list >> Xen-devel@lists.xensource.com >> http://lists.xensource.com/xen-devel >> --=20 Best regards, Sander mailto:linux@eikelenboom.it _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel From xen-devel-bounces@lists.xensource.com Thu Sep 29 05:19:02 2011 Return-path: <xen-devel-bounces@lists.xensource.com> Envelope-to: www-data@lists.xensource.com Delivery-date: Thu, 29 Sep 2011 05:19:02 -0700 Received: from localhost ([127.0.0.1] helo=lists.colo.xensource.com) by lists.xensource.com with esmtp (Exim 4.43) id 1R9FZt-0005cN-3M; Thu, 29 Sep 2011 05:19:01 -0700 Received: from mail182.messagelabs.com ([85.158.139.83]) by lists.xensource.com with esmtp (Exim 4.43) id 1R9FZH-0005Pf-3E for xen-devel@lists.xensource.com; Thu, 29 Sep 2011 05:18:25 -0700 X-Env-Sender: joseph.glanville@orionvm.com.au X-Msg-Ref: server-15.tower-182.messagelabs.com!1317298698!19192257!1 X-Originating-IP: [209.85.210.171] X-StarScan-Version: 6.4.1; banners=-,-,- X-VirusChecked: Checked Received: (qmail 24867 invoked from network); 29 Sep 2011 12:18:19 -0000 Received: from mail-iy0-f171.google.com (HELO mail-iy0-f171.google.com) (209.85.210.171) by server-15.tower-182.messagelabs.com with RC4-SHA encrypted SMTP; 29 Sep 2011 12:18:19 -0000 Received: by iagv1 with SMTP id v1so872979iag.30 for <xen-devel@lists.xensource.com>; Thu, 29 Sep 2011 05:18:18 -0700 (PDT) MIME-Version: 1.0 Received: by 10.231.48.149 with SMTP id r21mr3243097ibf.95.1317298697995; Thu, 29 Sep 2011 05:18:17 -0700 (PDT) Received: by 10.231.170.15 with HTTP; Thu, 29 Sep 2011 05:18:17 -0700 (PDT) X-Originating-IP: [59.167.234.130] In-Reply-To: <6410589313.20110929135902@eikelenboom.it> References: <20110922130618.GA13238@phenom.oracle.com> <CAFLBxZaAaXTUtW5+VkxPnr_MR0fbW+d1Mzu4y0x=gEOaX9e0OQ@mail.gmail.com> <20110922174002.GA1205@phenom.oracle.com> <20098.1097.824552.541924@mariner.uk.xensource.com> <CAP2B85-=CbMgUGSwO2utvkeLLqk8A1vjhKrPwe2OD+0daAtqsA@mail.gmail.com> <1317195656.13424.73.camel@dagon.hellion.org.uk> <20099.8327.326129.357335@mariner.uk.xensource.com> <20110928134800.GH10270@phenom.oracle.com> <1317218459.26672.62.camel@zakaz.uk.xensource.com> <CAOzFzEhnr7Ri42V1AUMLw-xRn+9NQwu8Pkq8iPc=pS12w=Vnog@mail.gmail.com> <6410589313.20110929135902@eikelenboom.it> Date: Thu, 29 Sep 2011 22:18:17 +1000 Message-ID: <CAOzFzEiQu=ys1mZcaHTR9=APyQP-iUhGG_8q_yE+hrDJdHEooA@mail.gmail.com> Subject: Re: [Xen-devel] Xen document day (Oct 12 or 26) From: Joseph Glanville <joseph.glanville@orionvm.com.au> To: Sander Eikelenboom <linux@eikelenboom.it> Cc: Ian Campbell <Ian.Campbell@eu.citrix.com>, Daniel Castro <evil.dani@gmail.com>, "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>, Ian Jackson <Ian.Jackson@eu.citrix.com>, Konrad Rzeszutek Wilk <konrad.wilk@oracle.com> X-BeenThere: xen-devel@lists.xensource.com X-Mailman-Version: 2.1.5 Precedence: list List-Id: Xen developer discussion <xen-devel.lists.xensource.com> List-Unsubscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe> List-Post: <mailto:xen-devel@lists.xensource.com> List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help> List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=subscribe> Content-Type: multipart/mixed; boundary="===============0045803450==" Sender: xen-devel-bounces@lists.xensource.com Errors-To: xen-devel-bounces@lists.xensource.com --===============0045803450== Content-Type: multipart/alternative; boundary=000e0cd1af2ef5057904ae13805d --000e0cd1af2ef5057904ae13805d Content-Type: text/plain; charset=ISO-8859-1 Yep, xen-tools is awesome. Uses debootstrap/rinse but at the same time it doesn't work that great outside of Debian. I want to provide PV images that will work on any platform. On 29 September 2011 21:59, Sander Eikelenboom <linux@eikelenboom.it> wrote: > Hello Joseph, > > Thursday, September 29, 2011, 12:53:47 PM, you wrote: > > > +1 for Markdown. > > > In terms of making Xen more accessible I think it might be a good idea to > > update/cleanup the distro support page. > > http://wiki.xen.org/xenwiki/DistributionSupport > > > I can probably do this. > > Making it simple for people to get started with Xen on a distro they are > > comfortable with is a good step forward. > > I know distro specific guides could turn into a nightmare but I am open > to > > writing one for Debian 6 Squeeze, there are also a few that exist already > > for RHEL/CentOS on the wiki. > > This should get easier as more distros update to 3.0+ kernels that > support > > PVops out of the box... > > > Next would be networking documentation as network-bridge script has been > > deprecated. > > http://wiki.xensource.com/xenwiki/XenNetworking > > Once again I think alot of the documentation is going to be distro > specific > > to be newbie friendly but atleast a simple ip/brctl guide would help. > > > IMO knowing where to start and setting up networking were the biggest > > barriers when I was picking up Xen a few years back. > > > I am also open to updating the blktap2 pages and README to reflect the > new > > tap-ctl userspace utilities and tips on driver development. > > > <slightly off-topic but related> > > > With jailtime.org(stacklet) now charging for subscription there is > nowhere > > to download pre-built clean Xen compatible images free of charge etc. > > I have pvgrub/pygrub capable images of Ubuntu/Debian/CentOS that I am > > considering hosting for free. > > Generally new users are confused on how to build new paravirt VMs, I > think > > prebuilt images are suboptimal but a good place to start for beginners. > > I have previously used the debian xen-tools package, which installs > Ubuntu/Debian/CentOS, although i don't remember exactly from what source. > > > Joseph. > > > On 29 September 2011 00:00, Ian Campbell <Ian.Campbell@eu.citrix.com> > wrote: > > >> On Wed, 2011-09-28 at 14:48 +0100, Konrad Rzeszutek Wilk wrote: > >> > On Wed, Sep 28, 2011 at 02:26:31PM +0100, Ian Jackson wrote: > >> > > Ian Campbell writes ("Re: [Xen-devel] Xen document day (Oct 12 or > >> 26)"): > >> > > > Since the guest APIs are stable there should be relatively little > >> churn > >> > > > so perhaps a wiki page (or even series of pages) would be > appropriate > >> > > > for this sort of thing? > >> > > > >> > > I want this to be in-tree. If it's in-tree, we can refuse patches > >> > > which do not update the documentation. > >> > > > >> > > > I think this would be good too and in fact even more important > than > >> the > >> > > > interface documentation. Everyone needs to be able to build Xen to > >> hack > >> > > > on it but only a subset need to know any particular API. > >> > > > > >> > > > Also although we recommend that users consume Xen via their distro > >> where > >> > > > possible such a guide would also help any who would rather build > from > >> > > > scratch (e.g. because we've asked them to "try the latest version" > or > >> to > >> > > > bisect a bug etc). > >> > > > >> > > This would be a good candidate for a wiki page, backed up by > revisions > >> > > of the in-tree README. > >> > > >> > > >> > Any recommendations on what would be a good format to write these > >> "interface" > >> > pages in? > >> > >> For in-line (i.e. in xen/include/public/*.h) docs of APIs I played a > >> little bit with integrating kernel-doc into the Xen build system but it > >> is tied a little too closely to the kernel build infrastructure. > >> > >> Doxygen seems like a plausible alternative with life outside the kernel > >> etc. We actually appear to already have some doxygen stuff for the > >> pytyhon stuff (judging from the Makefile, I've not actually noticed the > >> structured code comments anywhere) > >> > >> For non-inline docs I think we decided that markdown would be a good > >> answer. > >> > >> Ian. > >> > >> > >> _______________________________________________ > >> Xen-devel mailing list > >> Xen-devel@lists.xensource.com > >> http://lists.xensource.com/xen-devel > >> > > > > > > > -- > Best regards, > Sander mailto:linux@eikelenboom.it > > -- * Founder | Director | VP Research Orion Virtualisation Solutions* | www.orionvm.com.au | Phone: 1300 56 99 52 | Mobile: 0428 754 846 --000e0cd1af2ef5057904ae13805d Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Yep, xen-tools is awesome. Uses debootstrap/rinse but at the same time it d= oesn't work that great outside of Debian.<br>I want to provide PV image= s that will work on any platform.<br><br><div class=3D"gmail_quote">On 29 S= eptember 2011 21:59, Sander Eikelenboom <span dir=3D"ltr"><<a href=3D"ma= ilto:linux@eikelenboom.it">linux@eikelenboom.it</a>></span> wrote:<br> <blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1p= x #ccc solid;padding-left:1ex;">Hello Joseph,<br> <div><div></div><div class=3D"h5"><br> Thursday, September 29, 2011, 12:53:47 PM, you wrote:<br> <br> > +1 for Markdown.<br> <br> > In terms of making Xen more accessible I think it might be a good idea= to<br> > update/cleanup the distro support page.<br> > <a href=3D"http://wiki.xen.org/xenwiki/DistributionSupport" target=3D"= _blank">http://wiki.xen.org/xenwiki/DistributionSupport</a><br> <br> > I can probably do this.<br> > Making it simple for people to get started with Xen on a distro they a= re<br> > comfortable with is a good step forward.<br> > I know distro specific guides could turn into a nightmare but I am ope= n to<br> > writing one for Debian 6 Squeeze, there are also a few that exist alre= ady<br> > for RHEL/CentOS on the wiki.<br> > This should get easier as more distros update to 3.0+ kernels that sup= port<br> > PVops out of the box...<br> <br> > Next would be networking documentation as network-bridge script has be= en<br> > deprecated.<br> > <a href=3D"http://wiki.xensource.com/xenwiki/XenNetworking" target=3D"= _blank">http://wiki.xensource.com/xenwiki/XenNetworking</a><br> > Once again I think alot of the documentation is going to be distro spe= cific<br> > to be newbie friendly but atleast a simple ip/brctl guide would help.<= br> <br> > IMO knowing where to start and setting up networking were the biggest<= br> > barriers when I was picking up Xen a few years back.<br> <br> > I am also open to updating the blktap2 pages and README to reflect the= new<br> > tap-ctl userspace utilities and tips on driver development.<br> <br> > <slightly off-topic but related><br> <br> > With <a href=3D"http://jailtime.org" target=3D"_blank">jailtime.org</a= >(stacklet) now charging for subscription there is nowhere<br> > to download pre-built clean Xen compatible images free of charge etc.<= br> > I have pvgrub/pygrub capable images of Ubuntu/Debian/CentOS that I am<= br> > considering hosting for free.<br> > Generally new users are confused on how to build new paravirt VMs, I t= hink<br> > prebuilt images are suboptimal but a good place to start for beginners= .<br> <br> </div></div>I have previously used the debian xen-tools package, which inst= alls =A0Ubuntu/Debian/CentOS, although i don't remember exactly from wh= at source.<br> <div><div></div><div class=3D"h5"><br> > Joseph.<br> <br> > On 29 September 2011 00:00, Ian Campbell <<a href=3D"mailto:Ian.Cam= pbell@eu.citrix.com">Ian.Campbell@eu.citrix.com</a>> wrote:<br> <br> >> On Wed, 2011-09-28 at 14:48 +0100, Konrad Rzeszutek Wilk wrote:<br= > >> > On Wed, Sep 28, 2011 at 02:26:31PM +0100, Ian Jackson wrote:<= br> >> > > Ian Campbell writes ("Re: [Xen-devel] Xen document = day (Oct 12 or<br> >> 26)"):<br> >> > > > Since the guest APIs are stable there should be rel= atively little<br> >> churn<br> >> > > > so perhaps a wiki page (or even series of pages) wo= uld be appropriate<br> >> > > > for this sort of thing?<br> >> > ><br> >> > > I want this to be in-tree. =A0If it's in-tree, we ca= n refuse patches<br> >> > > which do not update the documentation.<br> >> > ><br> >> > > > I think this would be good too and in fact even mor= e important than<br> >> the<br> >> > > > interface documentation. Everyone needs to be able = to build Xen to<br> >> hack<br> >> > > > on it but only a subset need to know any particular= API.<br> >> > > ><br> >> > > > Also although we recommend that users consume Xen v= ia their distro<br> >> where<br> >> > > > possible such a guide would also help any who would= rather build from<br> >> > > > scratch (e.g. because we've asked them to "= ;try the latest version" or<br> >> to<br> >> > > > bisect a bug etc).<br> >> > ><br> >> > > This would be a good candidate for a wiki page, backed u= p by revisions<br> >> > > of the in-tree README.<br> >> ><br> >> ><br> >> > Any recommendations on what would be a good format to write t= hese<br> >> "interface"<br> >> > pages in?<br> >><br> >> For in-line (i.e. in xen/include/public/*.h) docs of APIs I played= a<br> >> little bit with integrating kernel-doc into the Xen build system b= ut it<br> >> is tied a little too closely to the kernel build infrastructure.<b= r> >><br> >> Doxygen seems like a plausible alternative with life outside the k= ernel<br> >> etc. We actually appear to already have some doxygen stuff for the= <br> >> pytyhon stuff (judging from the Makefile, I've not actually no= ticed the<br> >> structured code comments anywhere)<br> >><br> >> For non-inline docs I think we decided that markdown would be a go= od<br> >> answer.<br> >><br> >> Ian.<br> >><br> >><br> >> _______________________________________________<br> >> Xen-devel mailing list<br> >> <a href=3D"mailto:Xen-devel@lists.xensource.com">Xen-devel@lists.x= ensource.com</a><br> >> <a href=3D"http://lists.xensource.com/xen-devel" target=3D"_blank"= >http://lists.xensource.com/xen-devel</a><br> >><br> <br> <br> <br> <br> <br> <br> --<br> </div></div><div><div></div><div class=3D"h5">Best regards,<br> =A0Sander =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0mailto:<a = href=3D"mailto:linux@eikelenboom.it">linux@eikelenboom.it</a><br> <br> </div></div></blockquote></div><br><br clear=3D"all"><br>-- <br><span style= =3D"font-family:arial,sans-serif;font-size:13px;border-collapse:collapse"><= b><i><font color=3D"#0000ff"><div><font color=3D"#000000"><span style=3D"fo= nt-style:normal;font-weight:normal">Founder | Director | VP Research<br> </span></font></div>Orion Virtualisation Solutions</font></i></b>=A0|=A0<fo= nt color=3D"#0000ff"><a href=3D"http://www.orionvm.com.au/" style=3D"color:= rgb(42, 93, 176)" target=3D"_blank">www.orionvm.com.au</a></font>=A0| Phone= : 1300 56 99 52 | Mobile: 0428 754 846</span><br> --000e0cd1af2ef5057904ae13805d-- --===============0045803450== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel --===============0045803450==-- From xen-devel-bounces@lists.xensource.com Thu Sep 29 05:37:19 2011 Return-path: <xen-devel-bounces@lists.xensource.com> Envelope-to: www-data@lists.xensource.com Delivery-date: Thu, 29 Sep 2011 05:37:19 -0700 Received: from localhost ([127.0.0.1] helo=lists.colo.xensource.com) by lists.xensource.com with esmtp (Exim 4.43) id 1R9Frb-0006Nl-Jv; Thu, 29 Sep 2011 05:37:19 -0700 Received: from mail21.messagelabs.com ([85.158.143.35]) by lists.xensource.com with esmtp (Exim 4.43) id 1R9Fqm-00069q-UG for xen-devel@lists.xensource.com; Thu, 29 Sep 2011 05:36:29 -0700 X-Env-Sender: evil.dani@gmail.com X-Msg-Ref: server-4.tower-21.messagelabs.com!1317299748!62090985!1 X-Originating-IP: [209.85.161.43] X-StarScan-Version: 6.4.1; banners=-,-,- X-VirusChecked: Checked Received: (qmail 8566 invoked from network); 29 Sep 2011 12:35:49 -0000 Received: from mail-fx0-f43.google.com (HELO mail-fx0-f43.google.com) (209.85.161.43) by server-4.tower-21.messagelabs.com with RC4-SHA encrypted SMTP; 29 Sep 2011 12:35:49 -0000 Received: by fxh19 with SMTP id 19so2168568fxh.30 for <xen-devel@lists.xensource.com>; Thu, 29 Sep 2011 05:36:25 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; bh=/66VAkELBD0iykFu92d36S+kWSt8MQm6hL4EhnahSiQ=; b=rB2bkF+DCrcpfx5xjdjIUdA5sT7gltTeM1353LLi3inbNzBQeuTfThIUeqg7E0u/fW ZNZ1LWwafV8wbBLCPQ9UNRehexBwUxSvi+w9Hxbynqe4t9w+/XsOrIxSgwtjY60Uqg1C 5DFdMm15CoXGjfUDkH5rwFlwseuVggFAQfv/4= MIME-Version: 1.0 Received: by 10.223.75.24 with SMTP id w24mr16048781faj.132.1317299785540; Thu, 29 Sep 2011 05:36:25 -0700 (PDT) Received: by 10.223.97.9 with HTTP; Thu, 29 Sep 2011 05:36:25 -0700 (PDT) In-Reply-To: <1317295843.26672.170.camel@zakaz.uk.xensource.com> References: <CAP2B85-QBczrKLWSKaRVBkao3=6PB=wnYvuKmoXYqGDbZFnTXA@mail.gmail.com> <4E81B46F.5080208@citrix.com> <CAP2B85_2L2jkRMqbD6OCRXXaPR1nXV3RmRgcLo2zTTuSLDq5_g@mail.gmail.com> <1317125353.26672.25.camel@zakaz.uk.xensource.com> <CAP2B85_1j_-0kxMSYheFYVD9Qn0-eUxeuyyo92u5bahn_6yQMw@mail.gmail.com> <1317295843.26672.170.camel@zakaz.uk.xensource.com> Date: Thu, 29 Sep 2011 21:36:25 +0900 Message-ID: <CAP2B8597Vy-t+3BWgk=+YFzhBzP+M1ZRs1ZSskLySynXR3evgA@mail.gmail.com> Subject: Re: [Xen-devel] Debug event_channel.c From: Daniel Castro <evil.dani@gmail.com> To: Ian Campbell <Ian.Campbell@eu.citrix.com> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com> X-BeenThere: xen-devel@lists.xensource.com X-Mailman-Version: 2.1.5 Precedence: list List-Id: Xen developer discussion <xen-devel.lists.xensource.com> List-Unsubscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe> List-Post: <mailto:xen-devel@lists.xensource.com> List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help> List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=subscribe> Sender: xen-devel-bounces@lists.xensource.com Errors-To: xen-devel-bounces@lists.xensource.com On Thu, Sep 29, 2011 at 8:30 PM, Ian Campbell <Ian.Campbell@eu.citrix.com> wrote: > On Thu, 2011-09-29 at 12:09 +0100, Daniel Castro wrote: >> On Tue, Sep 27, 2011 at 9:09 PM, Ian Campbell <Ian.Campbell@citrix.com> = wrote: >> > On Tue, 2011-09-27 at 12:36 +0100, Daniel Castro wrote: >> >> On Tue, Sep 27, 2011 at 8:33 PM, Andrew Cooper >> >> <andrew.cooper3@citrix.com> wrote: >> >> > On 27/09/11 12:09, Daniel Castro wrote: >> >> >> Hello All, >> >> >> >> >> >> I am trying to debug event_channel.c for this I have filled the >> >> >> functions with gdprintk(XENLOG_WARNING, "..."); yet the messages a= re >> >> >> not displayed on dmesg or /var/log/xen. Where could they be printe= d? >> >> >> or should I use a different function? >> >> >> >> >> >> In grub I have loglvl=3Dall to print all messages... >> >> >> >> >> >> Thanks for the answer, >> >> >> >> >> >> Daniel >> >> >> >> >> > >> >> > gdprintk only gets set with guest debugging enabled. ( guest_loglvl= on >> >> > the command line ) >> >> > >> >> > My suggestion would be to just use regular printks and look at the >> >> > serial log. >> >> >> >> How can can I look at the serial log from dom0? >> > >> > 'xl dmesg' (or using a serial cable of course ;-)) >> > >> > You can also add XENCONSOLED_TRACE=3Dhv in /etc/sysconfig/xencommons (= or >> > the equivalent on your distro, the effect should be to add --log=3Dhv = to >> > the xenconsoled command line). Then the xen console will be logged >> > under /var/log/xen somewhere. >> >> Ian, thanks for the info. >> >> This is the info I gathered: >> (XEN) schedule.c:658:d1 DEBUG 1: START DO POLL port -32060 on >> sched_poll.nr_ports 1 > > port =3D=3D -32060 doesn't sound right... > >> (XEN) schedule.c:719:d1 DEBUG 1: DO POLL test bit on port 2 exit here >> -> if ( test_bit(port, &shared_info(d, evtchn_pending)) ) >> (XEN) schedule.c:746:d1 DEBUG 1: DO POLL GOTO out: check previus msg, >> return rc=3D0 >> (XEN) event_channel.c:606:d1 DEBUG 1: set_pending >> (XEN) event_channel.c:628:d1 DEBUG 1 : evtchn_set_pending test_bit AND >> test_and_set_bit returned 0. >> (XEN) event_channel.c:637:d1 DEBUG 1: evtchn_set_pending bitmap_empty re= turn 0. >> >> In my code test_bit_and_clear in Xenstore ring_wait is in fact >> returning 0, it was expecting a one, the do_poll is finding the bit in >> 1 also according to test_bit, right? >> So the error is on the my test_bit_and_clear. Am I reading it correctly? > > I'm not sure I follow what your debug messages are actually saying, but > if do_poll is exiting because of the > =A0 =A0 =A0 =A0if ( test_bit(port, &shared_info(d, evtchn_pending)) ) > =A0 =A0 =A0 =A0 =A0 =A0goto out; > inside the "for ( i =3D 0; i < sched_poll->nr_ports; i++ )" loop then thi= s > indicates that the event channel is pending. If you aren't seeing this > on the guest end then there is likely a problem somewhere on that end. > > In your current ring_wait function you have: > =A0 =A0 =A0 =A0int wait =3D test_and_clear_bit(event, shinfo->evtchn_pend= ing); > =A0 =A0 =A0 =A0int ret =3D 1; > =A0 =A0 =A0 =A0while (wait!=3D0 || ret!=3D0){ > =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0ret =3D hypercall_sched_op(SCHEDOP_poll, &= poll); > =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0wait =3D test_and_clear_bit(event, shinfo-= >evtchn_pending); > =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0struct vcpu_info *vcpu =3D shinfo->vcpu_in= fo; > =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0dprintf(1,"DEBUG bit clear is %d and ret %= d\n",wait,ret); > =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0time =3D shinfo->vcpu_info[0].time; > =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0dprintf(1,"TIME system %d timestamp %d\n",= time.system_time,time.tsc_timestamp); > =A0 =A0 =A0 =A0} > } > > Isn't "wait!=3D0" backwards? Don't you want to succeed (i.e. fall out of > the loop) when wait!=3D0 rather than keep looping? Yes, at some point I must have screwed that up, and later corrected it... Sorry... Yet the problem remains, in the ring wait I get stuck... What else could I check? > > Ian. > >> >> Thanks all, >> >> Daniel >> > >> > Ian. >> > >> >> >> >> > >> >> > -- >> >> > Andrew Cooper - Dom0 Kernel Engineer, Citrix XenServer >> >> > T: +44 (0)1223 225 900, http://www.citrix.com >> >> > >> >> > >> >> > _______________________________________________ >> >> > Xen-devel mailing list >> >> > Xen-devel@lists.xensource.com >> >> > http://lists.xensource.com/xen-devel >> >> > >> >> >> >> >> >> >> > >> > >> > >> >> >> > > > --=20 +-=3D=3D=3D=3D=3D---------------------------+ | +---------------------------------+ | This space intentionally blank for notetaking. | |=A0=A0 | Daniel Castro,=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 | | |=A0=A0 | Consultant/Programmer.| | |=A0=A0 | U Andes=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0=A0 | +-------------------------------------+ _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel From xen-devel-bounces@lists.xensource.com Thu Sep 29 05:45:04 2011 Return-path: <xen-devel-bounces@lists.xensource.com> Envelope-to: www-data@lists.xensource.com Delivery-date: Thu, 29 Sep 2011 05:45:04 -0700 Received: from localhost ([127.0.0.1] helo=lists.colo.xensource.com) by lists.xensource.com with esmtp (Exim 4.43) id 1R9Fz6-00076N-IX; Thu, 29 Sep 2011 05:45:04 -0700 Received: from mail182.messagelabs.com ([85.158.139.83]) by lists.xensource.com with esmtp (Exim 4.43) id 1R9FyL-0006qw-8I for xen-devel@lists.xensource.com; Thu, 29 Sep 2011 05:44:17 -0700 X-Env-Sender: anthony.perard@gmail.com X-Msg-Ref: server-9.tower-182.messagelabs.com!1317300253!18397634!1 X-Originating-IP: [209.85.216.171] X-StarScan-Version: 6.4.1; banners=-,-,- X-VirusChecked: Checked Received: (qmail 4449 invoked from network); 29 Sep 2011 12:44:14 -0000 Received: from mail-qy0-f171.google.com (HELO mail-qy0-f171.google.com) (209.85.216.171) by server-9.tower-182.messagelabs.com with RC4-SHA encrypted SMTP; 29 Sep 2011 12:44:14 -0000 Received: by qyk29 with SMTP id 29so3905886qyk.9 for <xen-devel@lists.xensource.com>; Thu, 29 Sep 2011 05:44:13 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:sender:in-reply-to:references:from:date :x-google-sender-auth:message-id:subject:to:cc:content-type :content-transfer-encoding; bh=IQb+HstNXdEvHWIeb8jcpEK9DLUm9n+MO5/xGGaOp98=; b=wEzKNjCenxfEacif6ngzdnXK60hf0jP3z77F1TDfiY/sIpEcC1ZU9gFEI/5XyyUbLm LfYhM/wKK9VCWdzMx83QpNd/XyGEn7+0P1BhjiUSUIDv2/vFEo9tqOyNXDrKHFH/6QE9 4bpHPeC4LvTxFK+rAumW2IPwZ2eAKvjqTxPJY= Received: by 10.224.9.138 with SMTP id l10mr1938106qal.255.1317300252796; Thu, 29 Sep 2011 05:44:12 -0700 (PDT) MIME-Version: 1.0 Received: by 10.224.47.74 with HTTP; Thu, 29 Sep 2011 05:43:42 -0700 (PDT) In-Reply-To: <1317297249.26672.173.camel@zakaz.uk.xensource.com> References: <1317296277-2838-1-git-send-email-anthony.perard@citrix.com> <1317296277-2838-8-git-send-email-anthony.perard@citrix.com> <1317297249.26672.173.camel@zakaz.uk.xensource.com> From: Anthony PERARD <anthony.perard@citrix.com> Date: Thu, 29 Sep 2011 13:43:42 +0100 X-Google-Sender-Auth: Tp2x5UmlZ8Qq1WJecEyF3S5Yu0g Message-ID: <CAJJyHj+YzZfHbOXSpkeFZaW173P8SWzkmoTcCPhpWLDHvWDNsg@mail.gmail.com> Subject: Re: [Xen-devel] Re: [PATCH V9 7/7] libxl: Introduce a QMP client To: Ian Campbell <Ian.Campbell@eu.citrix.com> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Cc: Xen Devel <xen-devel@lists.xensource.com>, Stefano Stabellini <Stefano.Stabellini@eu.citrix.com> X-BeenThere: xen-devel@lists.xensource.com X-Mailman-Version: 2.1.5 Precedence: list List-Id: Xen developer discussion <xen-devel.lists.xensource.com> List-Unsubscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe> List-Post: <mailto:xen-devel@lists.xensource.com> List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help> List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=subscribe> Sender: xen-devel-bounces@lists.xensource.com Errors-To: xen-devel-bounces@lists.xensource.com On Thu, Sep 29, 2011 at 12:54, Ian Campbell <Ian.Campbell@eu.citrix.com> wr= ote: > On Thu, 2011-09-29 at 12:37 +0100, Anthony PERARD wrote: >> >> + =C2=A0 =C2=A0qmp->qmp_fd =3D socket(AF_UNIX, SOCK_STREAM, 0); >> + =C2=A0 =C2=A0if (qmp->qmp_fd < 0) { >> + =C2=A0 =C2=A0 =C2=A0 =C2=A0return -1; >> + =C2=A0 =C2=A0} > > Is SOCK_CLOEXEC standard enough to use? Probably not. > > We should use FD_CLOEXEC though. Ok, I will send a separate patch for this. --=20 Anthony PERARD _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel From xen-devel-bounces@lists.xensource.com Thu Sep 29 05:53:18 2011 Return-path: <xen-devel-bounces@lists.xensource.com> Envelope-to: www-data@lists.xensource.com Delivery-date: Thu, 29 Sep 2011 05:53:18 -0700 Received: from localhost ([127.0.0.1] helo=lists.colo.xensource.com) by lists.xensource.com with esmtp (Exim 4.43) id 1R9G74-0007g0-Ch; Thu, 29 Sep 2011 05:53:18 -0700 Received: from mail216.messagelabs.com ([85.158.143.99]) by lists.xensource.com with esmtp (Exim 4.43) id 1R9G6R-0007TK-R3 for xen-devel@lists.xensource.com; Thu, 29 Sep 2011 05:52:40 -0700 X-Env-Sender: Ian.Campbell@eu.citrix.com X-Msg-Ref: server-10.tower-216.messagelabs.com!1317300756!10239149!1 X-Originating-IP: [62.200.22.115] X-StarScan-Version: 6.4.1; banners=-,-,- X-VirusChecked: Checked Received: (qmail 24353 invoked from network); 29 Sep 2011 12:52:36 -0000 Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115) by server-10.tower-216.messagelabs.com with RC4-SHA encrypted SMTP; 29 Sep 2011 12:52:36 -0000 X-IronPort-AV: E=Sophos;i="4.68,461,1312156800"; d="scan'208";a="8128291" Received: from lonpmailmx01.citrite.net ([10.30.203.162]) by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5; 29 Sep 2011 12:52:36 +0000 Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net (10.30.203.162) with Microsoft SMTP Server id 8.3.137.0; Thu, 29 Sep 2011 13:52:36 +0100 Subject: Re: [Xen-devel] Debug event_channel.c From: Ian Campbell <Ian.Campbell@eu.citrix.com> To: Daniel Castro <evil.dani@gmail.com> Date: Thu, 29 Sep 2011 13:52:36 +0100 In-Reply-To: <CAP2B8597Vy-t+3BWgk=+YFzhBzP+M1ZRs1ZSskLySynXR3evgA@mail.gmail.com> References: <CAP2B85-QBczrKLWSKaRVBkao3=6PB=wnYvuKmoXYqGDbZFnTXA@mail.gmail.com> <4E81B46F.5080208@citrix.com> <CAP2B85_2L2jkRMqbD6OCRXXaPR1nXV3RmRgcLo2zTTuSLDq5_g@mail.gmail.com> <1317125353.26672.25.camel@zakaz.uk.xensource.com> <CAP2B85_1j_-0kxMSYheFYVD9Qn0-eUxeuyyo92u5bahn_6yQMw@mail.gmail.com> <1317295843.26672.170.camel@zakaz.uk.xensource.com> <CAP2B8597Vy-t+3BWgk=+YFzhBzP+M1ZRs1ZSskLySynXR3evgA@mail.gmail.com> Organization: Citrix Systems, Inc. Content-Type: text/plain; charset="UTF-8" X-Mailer: Evolution 3.0.3- Content-Transfer-Encoding: 8bit Message-ID: <1317300756.26672.179.camel@zakaz.uk.xensource.com> MIME-Version: 1.0 Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com> X-BeenThere: xen-devel@lists.xensource.com X-Mailman-Version: 2.1.5 Precedence: list List-Id: Xen developer discussion <xen-devel.lists.xensource.com> List-Unsubscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe> List-Post: <mailto:xen-devel@lists.xensource.com> List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help> List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=subscribe> Sender: xen-devel-bounces@lists.xensource.com Errors-To: xen-devel-bounces@lists.xensource.com On Thu, 2011-09-29 at 13:36 +0100, Daniel Castro wrote: > On Thu, Sep 29, 2011 at 8:30 PM, Ian Campbell > <Ian.Campbell@eu.citrix.com> wrote: > > On Thu, 2011-09-29 at 12:09 +0100, Daniel Castro wrote: > >> On Tue, Sep 27, 2011 at 9:09 PM, Ian Campbell <Ian.Campbell@citrix.com> wrote: > >> > On Tue, 2011-09-27 at 12:36 +0100, Daniel Castro wrote: > >> >> On Tue, Sep 27, 2011 at 8:33 PM, Andrew Cooper > >> >> <andrew.cooper3@citrix.com> wrote: > >> >> > On 27/09/11 12:09, Daniel Castro wrote: > >> >> >> Hello All, > >> >> >> > >> >> >> I am trying to debug event_channel.c for this I have filled the > >> >> >> functions with gdprintk(XENLOG_WARNING, "..."); yet the messages are > >> >> >> not displayed on dmesg or /var/log/xen. Where could they be printed? > >> >> >> or should I use a different function? > >> >> >> > >> >> >> In grub I have loglvl=all to print all messages... > >> >> >> > >> >> >> Thanks for the answer, > >> >> >> > >> >> >> Daniel > >> >> >> > >> >> > > >> >> > gdprintk only gets set with guest debugging enabled. ( guest_loglvl on > >> >> > the command line ) > >> >> > > >> >> > My suggestion would be to just use regular printks and look at the > >> >> > serial log. > >> >> > >> >> How can can I look at the serial log from dom0? > >> > > >> > 'xl dmesg' (or using a serial cable of course ;-)) > >> > > >> > You can also add XENCONSOLED_TRACE=hv in /etc/sysconfig/xencommons (or > >> > the equivalent on your distro, the effect should be to add --log=hv to > >> > the xenconsoled command line). Then the xen console will be logged > >> > under /var/log/xen somewhere. > >> > >> Ian, thanks for the info. > >> > >> This is the info I gathered: > >> (XEN) schedule.c:658:d1 DEBUG 1: START DO POLL port -32060 on > >> sched_poll.nr_ports 1 > > > > port == -32060 doesn't sound right... > > > >> (XEN) schedule.c:719:d1 DEBUG 1: DO POLL test bit on port 2 exit here > >> -> if ( test_bit(port, &shared_info(d, evtchn_pending)) ) > >> (XEN) schedule.c:746:d1 DEBUG 1: DO POLL GOTO out: check previus msg, > >> return rc=0 > >> (XEN) event_channel.c:606:d1 DEBUG 1: set_pending > >> (XEN) event_channel.c:628:d1 DEBUG 1 : evtchn_set_pending test_bit AND > >> test_and_set_bit returned 0. > >> (XEN) event_channel.c:637:d1 DEBUG 1: evtchn_set_pending bitmap_empty return 0. > >> > >> In my code test_bit_and_clear in Xenstore ring_wait is in fact > >> returning 0, it was expecting a one, the do_poll is finding the bit in > >> 1 also according to test_bit, right? > >> So the error is on the my test_bit_and_clear. Am I reading it correctly? > > > > I'm not sure I follow what your debug messages are actually saying, but > > if do_poll is exiting because of the > > if ( test_bit(port, &shared_info(d, evtchn_pending)) ) > > goto out; > > inside the "for ( i = 0; i < sched_poll->nr_ports; i++ )" loop then this > > indicates that the event channel is pending. If you aren't seeing this > > on the guest end then there is likely a problem somewhere on that end. > > > > In your current ring_wait function you have: > > int wait = test_and_clear_bit(event, shinfo->evtchn_pending); > > int ret = 1; > > while (wait!=0 || ret!=0){ > > ret = hypercall_sched_op(SCHEDOP_poll, &poll); > > wait = test_and_clear_bit(event, shinfo->evtchn_pending); > > struct vcpu_info *vcpu = shinfo->vcpu_info; > > dprintf(1,"DEBUG bit clear is %d and ret %d\n",wait,ret); > > time = shinfo->vcpu_info[0].time; > > dprintf(1,"TIME system %d timestamp %d\n",time.system_time,time.tsc_timestamp); > > } > > } > > > > Isn't "wait!=0" backwards? Don't you want to succeed (i.e. fall out of > > the loop) when wait!=0 rather than keep looping? > > Yes, at some point I must have screwed that up, and later corrected > it... Sorry... Yet the problem remains, in the ring wait I get > stuck... > > What else could I check? Does shinfo actually point to the right thing? Looking at your *get_shared_info(void) you have: xatp.gpfn = malloc_high(sizeof(shared_info)); shared_info = (struct shared_info *)(xatp.gpfn << PAGE_SHIFT); but malloc_high returns a void * (i.e. a pointer) not an mfn. I suspect you want: shared_info = malloc_high(sizeof(shared_info)); xatp.gpfn = ((unsigned long)shared_info >> PAGE_SHIFT); At least here the compiler produces a clear warning about this issue: src/xen.c: In function ‘get_shared_info’: src/xen.c:157: warning: assignment makes integer from pointer without a cast The code in your seabios tree currently produces nearly a page of warnings. It is very good practice to get into the habit of taking care of all warnings as soon as they appear, more often than not they represent are real problem with the code. For example just from skimming them I can see that a bunch of your debug is not printing what you seem to think it is. Ian. > > > > > Ian. > > > >> > >> Thanks all, > >> > >> Daniel > >> > > >> > Ian. > >> > > >> >> > >> >> > > >> >> > -- > >> >> > Andrew Cooper - Dom0 Kernel Engineer, Citrix XenServer > >> >> > T: +44 (0)1223 225 900, http://www.citrix.com > >> >> > > >> >> > > >> >> > _______________________________________________ > >> >> > Xen-devel mailing list > >> >> > Xen-devel@lists.xensource.com > >> >> > http://lists.xensource.com/xen-devel > >> >> > > >> >> > >> >> > >> >> > >> > > >> > > >> > > >> > >> > >> > > > > > > > > > _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel From xen-devel-bounces@lists.xensource.com Thu Sep 29 06:57:24 2011 Return-path: <xen-devel-bounces@lists.xensource.com> Envelope-to: www-data@lists.xensource.com Delivery-date: Thu, 29 Sep 2011 06:57:24 -0700 Received: from localhost ([127.0.0.1] helo=lists.colo.xensource.com) by lists.xensource.com with esmtp (Exim 4.43) id 1R9H76-0000o8-2i; Thu, 29 Sep 2011 06:57:24 -0700 Received: from mail27.messagelabs.com ([193.109.254.147]) by lists.xensource.com with esmtp (Exim 4.43) id 1R9H6A-0000b3-FW for xen-devel@lists.xensource.com; Thu, 29 Sep 2011 06:56:26 -0700 X-Env-Sender: konrad@oracle.com X-Msg-Ref: server-6.tower-27.messagelabs.com!1317304561!51008545!1 X-Originating-IP: [148.87.113.117] X-StarScan-Version: 6.4.1; banners=-,-,- X-VirusChecked: Checked Received: (qmail 30426 invoked from network); 29 Sep 2011 13:56:02 -0000 Received: from rcsinet15.oracle.com (HELO rcsinet15.oracle.com) (148.87.113.117) by server-6.tower-27.messagelabs.com with DHE-RSA-AES256-SHA encrypted SMTP; 29 Sep 2011 13:56:02 -0000 Received: from rtcsinet21.oracle.com (rtcsinet21.oracle.com [66.248.204.29]) by rcsinet15.oracle.com (Switch-3.4.4/Switch-3.4.4) with ESMTP id p8TDuEc2014099 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Thu, 29 Sep 2011 13:56:16 GMT Received: from acsmt358.oracle.com (acsmt358.oracle.com [141.146.40.158]) by rtcsinet21.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id p8TDuBcn008220 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 29 Sep 2011 13:56:12 GMT Received: from abhmt115.oracle.com (abhmt115.oracle.com [141.146.116.67]) by acsmt358.oracle.com (8.12.11.20060308/8.12.11) with ESMTP id p8TDu3aZ030565; Thu, 29 Sep 2011 08:56:04 -0500 Received: from oracle.com (/207.172.105.198) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Thu, 29 Sep 2011 06:56:03 -0700 Received: by oracle.com (Postfix, from userid 1000) id 22DEE1548; Thu, 29 Sep 2011 09:55:59 -0400 (EDT) Date: Thu, 29 Sep 2011 09:55:59 -0400 From: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com> To: stefano.stabellini@eu.citrix.com Subject: Re: [Xen-devel] [PATCH v5 2/2] xen: modify kernel mappings corresponding to granted pages Message-ID: <20110929135558.GA31321@phenom.oracle.com> References: <alpine.DEB.2.00.1109291148340.3519@kaball-desktop> <1317293876-23891-2-git-send-email-stefano.stabellini@eu.citrix.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <1317293876-23891-2-git-send-email-stefano.stabellini@eu.citrix.com> User-Agent: Mutt/1.5.21 (2010-09-15) X-Source-IP: rtcsinet21.oracle.com [66.248.204.29] X-CT-RefId: str=0001.0A090208.4E847901.0074,ss=1,re=0.000,fgs=0 Cc: jeremy@goop.org, xen-devel@lists.xensource.com, linux-kernel@vger.kernel.org X-BeenThere: xen-devel@lists.xensource.com X-Mailman-Version: 2.1.5 Precedence: list List-Id: Xen developer discussion <xen-devel.lists.xensource.com> List-Unsubscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe> List-Post: <mailto:xen-devel@lists.xensource.com> List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help> List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=subscribe> Sender: xen-devel-bounces@lists.xensource.com Errors-To: xen-devel-bounces@lists.xensource.com > /* Xen machine address */ > @@ -31,8 +32,10 @@ typedef struct xpaddr { > #define INVALID_P2M_ENTRY (~0UL) > #define FOREIGN_FRAME_BIT (1UL<<(BITS_PER_LONG-1)) > #define IDENTITY_FRAME_BIT (1UL<<(BITS_PER_LONG-2)) > +#define GRANT_FRAME_BIT (1UL<<(BITS_PER_LONG-3)) I am going to change that to (BITS_PER_LONG-1) as we aren't using the P2M. (and add that comment in the file). And both patches are now in 3.2 queue. _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel From xen-devel-bounces@lists.xensource.com Thu Sep 29 06:58:55 2011 Return-path: <xen-devel-bounces@lists.xensource.com> Envelope-to: www-data@lists.xensource.com Delivery-date: Thu, 29 Sep 2011 06:58:55 -0700 Received: from localhost ([127.0.0.1] helo=lists.colo.xensource.com) by lists.xensource.com with esmtp (Exim 4.43) id 1R9H8Z-0001BL-Nr; Thu, 29 Sep 2011 06:58:55 -0700 Received: from mail21.messagelabs.com ([85.158.143.35]) by lists.xensource.com with esmtp (Exim 4.43) id 1R9H6e-0000gv-IG for xen-devel@lists.xensource.com; Thu, 29 Sep 2011 06:56:57 -0700 X-Env-Sender: Ian.Jackson@eu.citrix.com X-Msg-Ref: server-4.tower-21.messagelabs.com!1317304576!62105165!1 X-Originating-IP: [62.200.22.115] X-StarScan-Version: 6.4.1; banners=-,-,- X-VirusChecked: Checked Received: (qmail 8114 invoked from network); 29 Sep 2011 13:56:16 -0000 Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115) by server-4.tower-21.messagelabs.com with RC4-SHA encrypted SMTP; 29 Sep 2011 13:56:16 -0000 X-IronPort-AV: E=Sophos;i="4.68,461,1312156800"; d="scan'208";a="8131018" Received: from lonpmailmx01.citrite.net ([10.30.203.162]) by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5; 29 Sep 2011 13:56:53 +0000 Received: from norwich.cam.xci-test.com (10.80.248.129) by smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id 8.3.137.0; Thu, 29 Sep 2011 14:56:53 +0100 Received: from mariner.cam.xci-test.com ([10.80.2.22] helo=mariner.uk.xensource.com ident=Debian-exim) by norwich.cam.xci-test.com with esmtp (Exim 4.72) (envelope-from <Ian.Jackson@eu.citrix.com>) id 1R9H6b-00085f-3f; Thu, 29 Sep 2011 13:56:53 +0000 Received: from iwj by mariner.uk.xensource.com with local (Exim 4.69) (envelope-from <Ian.Jackson@eu.citrix.com>) id 1R9H6b-0001pm-2N; Thu, 29 Sep 2011 14:56:53 +0100 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Message-ID: <20100.31012.856373.349796@mariner.uk.xensource.com> Date: Thu, 29 Sep 2011 14:56:52 +0100 To: Anthony PERARD <anthony.perard@citrix.com> Subject: Re: [Xen-devel] [PATCH RESEND V8 0/7] Introduce a QMP client In-Reply-To: <CAJJyHjLRxRU9hR+PHhLnxJPVJgeiAK2ACE+QV-ufJ7vLWQqWVg@mail.gmail.com> References: <1316609997-26002-1-git-send-email-anthony.perard@citrix.com> <20099.17272.139799.560052@mariner.uk.xensource.com> <CAJJyHjLRxRU9hR+PHhLnxJPVJgeiAK2ACE+QV-ufJ7vLWQqWVg@mail.gmail.com> X-Mailer: VM 8.0.9 under Emacs 21.4.1 (i486-pc-linux-gnu) From: Ian Jackson <Ian.Jackson@eu.citrix.com> Cc: Ian Campbell <Ian.Campbell@eu.citrix.com>, Xen Devel <xen-devel@lists.xensource.com>, Stefano Stabellini <Stefano.Stabellini@eu.citrix.com> X-BeenThere: xen-devel@lists.xensource.com X-Mailman-Version: 2.1.5 Precedence: list List-Id: Xen developer discussion <xen-devel.lists.xensource.com> List-Unsubscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe> List-Post: <mailto:xen-devel@lists.xensource.com> List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help> List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=subscribe> Sender: xen-devel-bounces@lists.xensource.com Errors-To: xen-devel-bounces@lists.xensource.com Anthony PERARD writes ("Re: [Xen-devel] [PATCH RESEND V8 0/7] Introduce a QMP client"): > The man page said that we can use this define since Linux 2.6.27, but > I will change my patch to use fcntl instead. Thanks. My workstation is running lenny, which has not-outrageously-old kernel headers in /usr/include. Ian. _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel From xen-devel-bounces@lists.xensource.com Thu Sep 29 07:00:02 2011 Return-path: <xen-devel-bounces@lists.xensource.com> Envelope-to: www-data@lists.xensource.com Delivery-date: Thu, 29 Sep 2011 07:00:02 -0700 Received: from localhost ([127.0.0.1] helo=lists.colo.xensource.com) by lists.xensource.com with esmtp (Exim 4.43) id 1R9H9d-0001Y9-OX; Thu, 29 Sep 2011 07:00:01 -0700 Received: from mail174.messagelabs.com ([85.158.138.51]) by lists.xensource.com with esmtp (Exim 4.43) id 1R9H7J-0000q7-8y for xen-devel@lists.xensource.com; Thu, 29 Sep 2011 06:57:37 -0700 X-Env-Sender: Ian.Jackson@eu.citrix.com X-Msg-Ref: server-3.tower-174.messagelabs.com!1317304653!27189795!1 X-Originating-IP: [62.200.22.115] X-StarScan-Version: 6.4.1; banners=-,-,- X-VirusChecked: Checked Received: (qmail 26390 invoked from network); 29 Sep 2011 13:57:34 -0000 Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115) by server-3.tower-174.messagelabs.com with RC4-SHA encrypted SMTP; 29 Sep 2011 13:57:34 -0000 X-IronPort-AV: E=Sophos;i="4.68,461,1312156800"; d="scan'208";a="8131041" Received: from lonpmailmx01.citrite.net ([10.30.203.162]) by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5; 29 Sep 2011 13:57:33 +0000 Received: from norwich.cam.xci-test.com (10.80.248.129) by smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id 8.3.137.0; Thu, 29 Sep 2011 14:57:33 +0100 Received: from mariner.cam.xci-test.com ([10.80.2.22] helo=mariner.uk.xensource.com ident=Debian-exim) by norwich.cam.xci-test.com with esmtp (Exim 4.72) (envelope-from <Ian.Jackson@eu.citrix.com>) id 1R9H7F-00085q-9G; Thu, 29 Sep 2011 13:57:33 +0000 Received: from iwj by mariner.uk.xensource.com with local (Exim 4.69) (envelope-from <Ian.Jackson@eu.citrix.com>) id 1R9H7F-0001pw-8F; Thu, 29 Sep 2011 14:57:33 +0100 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Message-ID: <20100.31053.247762.965830@mariner.uk.xensource.com> Date: Thu, 29 Sep 2011 14:57:33 +0100 To: Stefano Stabellini <Stefano.Stabellini@eu.citrix.com> Subject: Re: [Xen-devel] [PATCH v6 1/5] Introduce git-checkout.sh In-Reply-To: <alpine.DEB.2.00.1109291207110.3519@kaball-desktop> References: <alpine.DEB.2.00.1109231302370.8700@kaball-desktop> <1316779878-10950-1-git-send-email-stefano.stabellini@eu.citrix.com> <20099.17426.176688.137409@mariner.uk.xensource.com> <alpine.DEB.2.00.1109291207110.3519@kaball-desktop> X-Mailer: VM 8.0.9 under Emacs 21.4.1 (i486-pc-linux-gnu) From: Ian Jackson <Ian.Jackson@eu.citrix.com> Cc: Ian, Campbell <Ian.Campbell@eu.citrix.com>, "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>, "keir@xen.org" <keir@xen.org> X-BeenThere: xen-devel@lists.xensource.com X-Mailman-Version: 2.1.5 Precedence: list List-Id: Xen developer discussion <xen-devel.lists.xensource.com> List-Unsubscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe> List-Post: <mailto:xen-devel@lists.xensource.com> List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help> List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=subscribe> Sender: xen-devel-bounces@lists.xensource.com Errors-To: xen-devel-bounces@lists.xensource.com Stefano Stabellini writes ("Re: [Xen-devel] [PATCH v6 1/5] Introduce git-checkout.sh"): > On Wed, 28 Sep 2011, Ian Jackson wrote: > > Would it be too much to ask you not to rename this directory ? > > Honestly I think that keeping the old name is bad: having two qemu trees > cloned by xen-unstable is already confusing enough for both to users and > developers, the very least we can do is naming the two trees meaningfully. I guess I'm in a minority on this one. Ian. _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel From xen-devel-bounces@lists.xensource.com Thu Sep 29 07:01:08 2011 Return-path: <xen-devel-bounces@lists.xensource.com> Envelope-to: www-data@lists.xensource.com Delivery-date: Thu, 29 Sep 2011 07:01:08 -0700 Received: from localhost ([127.0.0.1] helo=lists.colo.xensource.com) by lists.xensource.com with esmtp (Exim 4.43) id 1R9HAi-0001w3-Jm; Thu, 29 Sep 2011 07:01:08 -0700 Received: from mail182.messagelabs.com ([85.158.139.83]) by lists.xensource.com with esmtp (Exim 4.43) id 1R9H8F-00014k-Tm for xen-devel@lists.xensource.com; Thu, 29 Sep 2011 06:58:36 -0700 X-Env-Sender: Stefano.Stabellini@eu.citrix.com X-Msg-Ref: server-8.tower-182.messagelabs.com!1317304712!19060299!1 X-Originating-IP: [62.200.22.115] X-StarScan-Version: 6.4.1; banners=-,-,- X-VirusChecked: Checked Received: (qmail 2833 invoked from network); 29 Sep 2011 13:58:32 -0000 Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115) by server-8.tower-182.messagelabs.com with RC4-SHA encrypted SMTP; 29 Sep 2011 13:58:32 -0000 X-IronPort-AV: E=Sophos;i="4.68,461,1312156800"; d="scan'208";a="8131079" Received: from lonpmailmx01.citrite.net ([10.30.203.162]) by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5; 29 Sep 2011 13:58:32 +0000 Received: from kaball.uk.xensource.com (10.80.2.59) by LONPMAILMX01.citrite.net (10.30.203.162) with Microsoft SMTP Server id 8.3.137.0; Thu, 29 Sep 2011 14:58:32 +0100 Date: Thu, 29 Sep 2011 14:58:19 +0100 From: Stefano Stabellini <stefano.stabellini@eu.citrix.com> X-X-Sender: sstabellini@kaball-desktop To: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com> Subject: Re: [Xen-devel] [PATCH v5 2/2] xen: modify kernel mappings corresponding to granted pages In-Reply-To: <20110929135558.GA31321@phenom.oracle.com> Message-ID: <alpine.DEB.2.00.1109291458050.3519@kaball-desktop> References: <alpine.DEB.2.00.1109291148340.3519@kaball-desktop> <1317293876-23891-2-git-send-email-stefano.stabellini@eu.citrix.com> <20110929135558.GA31321@phenom.oracle.com> User-Agent: Alpine 2.00 (DEB 1167 2008-08-23) MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Cc: "jeremy@goop.org" <jeremy@goop.org>, "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>, "linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>, Stefano Stabellini <Stefano.Stabellini@eu.citrix.com> X-BeenThere: xen-devel@lists.xensource.com X-Mailman-Version: 2.1.5 Precedence: list List-Id: Xen developer discussion <xen-devel.lists.xensource.com> List-Unsubscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe> List-Post: <mailto:xen-devel@lists.xensource.com> List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help> List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=subscribe> Sender: xen-devel-bounces@lists.xensource.com Errors-To: xen-devel-bounces@lists.xensource.com On Thu, 29 Sep 2011, Konrad Rzeszutek Wilk wrote: > > /* Xen machine address */ > > @@ -31,8 +32,10 @@ typedef struct xpaddr { > > #define INVALID_P2M_ENTRY (~0UL) > > #define FOREIGN_FRAME_BIT (1UL<<(BITS_PER_LONG-1)) > > #define IDENTITY_FRAME_BIT (1UL<<(BITS_PER_LONG-2)) > > +#define GRANT_FRAME_BIT (1UL<<(BITS_PER_LONG-3)) > > I am going to change that to (BITS_PER_LONG-1) as we aren't > using the P2M. (and add that comment in the file). > > And both patches are now in 3.2 queue. OK, thanks. _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel From xen-devel-bounces@lists.xensource.com Thu Sep 29 07:03:58 2011 Return-path: <xen-devel-bounces@lists.xensource.com> Envelope-to: www-data@lists.xensource.com Delivery-date: Thu, 29 Sep 2011 07:03:58 -0700 Received: from localhost ([127.0.0.1] helo=lists.colo.xensource.com) by lists.xensource.com with esmtp (Exim 4.43) id 1R9HDS-0002LZ-OB; Thu, 29 Sep 2011 07:03:58 -0700 Received: from mail174.messagelabs.com ([85.158.138.51]) by lists.xensource.com with esmtp (Exim 4.43) id 1R9HCh-00028x-35 for xen-devel@lists.xensource.com; Thu, 29 Sep 2011 07:03:11 -0700 X-Env-Sender: Ian.Campbell@eu.citrix.com X-Msg-Ref: server-3.tower-174.messagelabs.com!1317304987!27190814!1 X-Originating-IP: [62.200.22.115] X-StarScan-Version: 6.4.1; banners=-,-,- X-VirusChecked: Checked Received: (qmail 11789 invoked from network); 29 Sep 2011 14:03:08 -0000 Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115) by server-3.tower-174.messagelabs.com with RC4-SHA encrypted SMTP; 29 Sep 2011 14:03:08 -0000 X-IronPort-AV: E=Sophos;i="4.68,461,1312156800"; d="scan'208";a="8131221" Received: from lonpmailmx01.citrite.net ([10.30.203.162]) by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5; 29 Sep 2011 14:03:07 +0000 Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net (10.30.203.162) with Microsoft SMTP Server id 8.3.137.0; Thu, 29 Sep 2011 15:03:08 +0100 Subject: Re: [Xen-devel] [PATCH RESEND V8 0/7] Introduce a QMP client From: Ian Campbell <Ian.Campbell@eu.citrix.com> To: Ian Jackson <Ian.Jackson@eu.citrix.com> Date: Thu, 29 Sep 2011 15:03:07 +0100 In-Reply-To: <20100.31012.856373.349796@mariner.uk.xensource.com> References: <1316609997-26002-1-git-send-email-anthony.perard@citrix.com> <20099.17272.139799.560052@mariner.uk.xensource.com> <CAJJyHjLRxRU9hR+PHhLnxJPVJgeiAK2ACE+QV-ufJ7vLWQqWVg@mail.gmail.com> <20100.31012.856373.349796@mariner.uk.xensource.com> Organization: Citrix Systems, Inc. Content-Type: text/plain; charset="UTF-8" X-Mailer: Evolution 3.0.3- Content-Transfer-Encoding: 7bit Message-ID: <1317304987.26672.184.camel@zakaz.uk.xensource.com> MIME-Version: 1.0 Cc: Anthony Perard <anthony.perard@citrix.com>, Xen Devel <xen-devel@lists.xensource.com>, Stefano Stabellini <Stefano.Stabellini@eu.citrix.com> X-BeenThere: xen-devel@lists.xensource.com X-Mailman-Version: 2.1.5 Precedence: list List-Id: Xen developer discussion <xen-devel.lists.xensource.com> List-Unsubscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe> List-Post: <mailto:xen-devel@lists.xensource.com> List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help> List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=subscribe> Sender: xen-devel-bounces@lists.xensource.com Errors-To: xen-devel-bounces@lists.xensource.com On Thu, 2011-09-29 at 14:56 +0100, Ian Jackson wrote: > Anthony PERARD writes ("Re: [Xen-devel] [PATCH RESEND V8 0/7] Introduce a QMP client"): > > The man page said that we can use this define since Linux 2.6.27, but > > I will change my patch to use fcntl instead. > > Thanks. > > My workstation is running lenny, which has not-outrageously-old kernel > headers in /usr/include. Lenny was 2.6.26 IIRC, hence the issue... Ian. _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel From xen-devel-bounces@lists.xensource.com Thu Sep 29 07:13:58 2011 Return-path: <xen-devel-bounces@lists.xensource.com> Envelope-to: www-data@lists.xensource.com Delivery-date: Thu, 29 Sep 2011 07:13:58 -0700 Received: from localhost ([127.0.0.1] helo=lists.colo.xensource.com) by lists.xensource.com with esmtp (Exim 4.43) id 1R9HN7-0002rd-UY; Thu, 29 Sep 2011 07:13:57 -0700 Received: from mail216.messagelabs.com ([85.158.143.99]) by lists.xensource.com with esmtp (Exim 4.43) id 1R9HMY-0002fn-LY; Thu, 29 Sep 2011 07:13:23 -0700 X-Env-Sender: pasik@iki.fi X-Msg-Ref: server-12.tower-216.messagelabs.com!1317305599!14274427!1 X-Originating-IP: [192.89.123.25] X-StarScan-Version: 6.4.1; banners=-,-,- X-VirusChecked: Checked Received: (qmail 23771 invoked from network); 29 Sep 2011 14:13:19 -0000 Received: from smtp.tele.fi (HELO smtp.tele.fi) (192.89.123.25) by server-12.tower-216.messagelabs.com with DHE-RSA-AES256-SHA encrypted SMTP; 29 Sep 2011 14:13:19 -0000 X-Originating-Ip: [194.89.68.22] Received: from ydin.reaktio.net (reaktio.net [194.89.68.22]) by smtp.tele.fi (Postfix) with ESMTP id 980A71B47; Thu, 29 Sep 2011 17:13:18 +0300 (EEST) Received: by ydin.reaktio.net (Postfix, from userid 1001) id 20ABE200EC; Thu, 29 Sep 2011 17:13:18 +0300 (EEST) Date: Thu, 29 Sep 2011 17:13:18 +0300 From: Pasi =?iso-8859-1?Q?K=E4rkk=E4inen?= <pasik@iki.fi> To: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com> Subject: Re: [Xen-devel] Xen document day (Oct 12 or 26) Message-ID: <20110929141317.GX12984@reaktio.net> References: <20110922130618.GA13238@phenom.oracle.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20110922130618.GA13238@phenom.oracle.com> User-Agent: Mutt/1.5.18 (2008-05-17) Cc: xen-devel@lists.xensource.com, xen-users@lists.xensource.com X-BeenThere: xen-devel@lists.xensource.com X-Mailman-Version: 2.1.5 Precedence: list List-Id: Xen developer discussion <xen-devel.lists.xensource.com> List-Unsubscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe> List-Post: <mailto:xen-devel@lists.xensource.com> List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help> List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=subscribe> Sender: xen-devel-bounces@lists.xensource.com Errors-To: xen-devel-bounces@lists.xensource.com On Thu, Sep 22, 2011 at 09:06:18AM -0400, Konrad Rzeszutek Wilk wrote: > Part of what we brainstormed at Xen Hackathon was what we could do make Xen easier. > > And the one thing that seemed to surface up was making the docs better - either > be the Wiki or the three .pdfs that get created/shipped with Xen. > > One thought was to come up with a Documention Day - where volunteers would try to > fix up some portion of the documentation that they feel they have > a good grasp of knowledge off and are willing to change (and also look > to be incorrect) > > What do you guys think of Oct 12th or Oct 26 as a day for this? > > And then the next question - what page/pdf section interests you? > > http://bits.xensource.com/Xen/docs/user.pdf > http://www.rites.uic.edu/~solworth/xenInterfaceManual.pdf [the one on Xen.org is an older version] > > Or Wiki pages: > http://wiki.xensource.com/xenwiki/ > > http://wiki.xensource.com/xenwiki/XenDom0Kernels > http://wiki.xensource.com/xenwiki/XenSerialConsole > http://wiki.xensource.com/xenwiki/XenParavirtOps > http://wiki.xensource.com/xenwiki/XenCommonProblems > > http://wiki.xensource.com/xenwiki/Consulting > http://wiki.xensource.com/xenwiki/Consultants > http://wiki.xensource.com/xenwiki/VpsHostingWithXen > > http://wiki.xen.org/xenwiki/XenPCIpassthrough > http://wiki.xen.org/xenwiki/VTdHowTo > Some more related pages: http://wiki.xen.org/xenwiki/Xen4.0 http://wiki.xen.org/xenwiki/Xen4.1 http://wiki.xen.org/xenwiki/XenKernelFeatures http://wiki.xen.org/xenwiki/XenBestPractices http://wiki.xen.org/xenwiki/XenHypervisorBootOptions Also there's something completely new that we should document: How to install Xen VMs! which means document all the relevant methods: boot the native distro installer as PV guest, as HVM guest, xen-tools, virt-install, debootstrap, rpmstart, etc.. That's something people ask about very often.. -- Pasi _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel From xen-devel-bounces@lists.xensource.com Thu Sep 29 07:18:40 2011 Return-path: <xen-devel-bounces@lists.xensource.com> Envelope-to: www-data@lists.xensource.com Delivery-date: Thu, 29 Sep 2011 07:18:40 -0700 Received: from localhost ([127.0.0.1] helo=lists.colo.xensource.com) by lists.xensource.com with esmtp (Exim 4.43) id 1R9HRg-0003x1-99; Thu, 29 Sep 2011 07:18:40 -0700 Received: from mail182.messagelabs.com ([85.158.139.83]) by lists.xensource.com with esmtp (Exim 4.43) id 1R9HR9-0003l1-Ts for xen-devel@lists.xensource.com; Thu, 29 Sep 2011 07:18:08 -0700 X-Env-Sender: Ian.Campbell@eu.citrix.com X-Msg-Ref: server-4.tower-182.messagelabs.com!1317305884!20237661!1 X-Originating-IP: [62.200.22.115] X-StarScan-Version: 6.4.1; banners=-,-,- X-VirusChecked: Checked Received: (qmail 2237 invoked from network); 29 Sep 2011 14:18:05 -0000 Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115) by server-4.tower-182.messagelabs.com with RC4-SHA encrypted SMTP; 29 Sep 2011 14:18:05 -0000 X-IronPort-AV: E=Sophos;i="4.68,461,1312156800"; d="scan'208";a="8131637" Received: from lonpmailmx01.citrite.net ([10.30.203.162]) by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5; 29 Sep 2011 14:18:04 +0000 Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net (10.30.203.162) with Microsoft SMTP Server id 8.3.137.0; Thu, 29 Sep 2011 15:18:04 +0100 Subject: Re: [Xen-devel] [PATCH v5 2/2] xen: modify kernel mappings corresponding to granted pages From: Ian Campbell <Ian.Campbell@citrix.com> To: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com> Date: Thu, 29 Sep 2011 15:18:04 +0100 In-Reply-To: <20110929135558.GA31321@phenom.oracle.com> References: <alpine.DEB.2.00.1109291148340.3519@kaball-desktop> <1317293876-23891-2-git-send-email-stefano.stabellini@eu.citrix.com> <20110929135558.GA31321@phenom.oracle.com> Organization: Citrix Systems, Inc. Content-Type: text/plain; charset="UTF-8" X-Mailer: Evolution 3.0.3- Content-Transfer-Encoding: 7bit Message-ID: <1317305884.26672.190.camel@zakaz.uk.xensource.com> MIME-Version: 1.0 Cc: "jeremy@goop.org" <jeremy@goop.org>, "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>, "linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>, Stefano Stabellini <Stefano.Stabellini@eu.citrix.com> X-BeenThere: xen-devel@lists.xensource.com X-Mailman-Version: 2.1.5 Precedence: list List-Id: Xen developer discussion <xen-devel.lists.xensource.com> List-Unsubscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe> List-Post: <mailto:xen-devel@lists.xensource.com> List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help> List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=subscribe> Sender: xen-devel-bounces@lists.xensource.com Errors-To: xen-devel-bounces@lists.xensource.com On Thu, 2011-09-29 at 14:55 +0100, Konrad Rzeszutek Wilk wrote: > > /* Xen machine address */ > > @@ -31,8 +32,10 @@ typedef struct xpaddr { > > #define INVALID_P2M_ENTRY (~0UL) > > #define FOREIGN_FRAME_BIT (1UL<<(BITS_PER_LONG-1)) > > #define IDENTITY_FRAME_BIT (1UL<<(BITS_PER_LONG-2)) > > +#define GRANT_FRAME_BIT (1UL<<(BITS_PER_LONG-3)) > > I am going to change that to (BITS_PER_LONG-1) as we aren't > using the P2M. (and add that comment in the file). You should also move it away from/out of the "/**** MACHINE <-> PHYSICAL CONVERSION MACROS ****/" section, otherwise it's just confusing. The associated GRANT_FRAME macro seems to be unused. But what is that bit in page->private actually used for? This patch adds it in m2p_add_override and masks it off in m2p_find_override, but doesn't otherwise appear to use it. Ian. _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel From xen-devel-bounces@lists.xensource.com Thu Sep 29 07:21:55 2011 Return-path: <xen-devel-bounces@lists.xensource.com> Envelope-to: www-data@lists.xensource.com Delivery-date: Thu, 29 Sep 2011 07:21:55 -0700 Received: from localhost ([127.0.0.1] helo=lists.colo.xensource.com) by lists.xensource.com with esmtp (Exim 4.43) id 1R9HUp-0004RO-Qv; Thu, 29 Sep 2011 07:21:55 -0700 Received: from mail182.messagelabs.com ([85.158.139.83]) by lists.xensource.com with esmtp (Exim 4.43) id 1R9HUL-0004Fd-OE for xen-devel@lists.xensource.com; Thu, 29 Sep 2011 07:21:28 -0700 X-Env-Sender: keir.xen@gmail.com X-Msg-Ref: server-12.tower-182.messagelabs.com!1317306081!20087216!1 X-Originating-IP: [209.85.213.171] X-StarScan-Version: 6.4.1; banners=-,-,- X-VirusChecked: Checked Received: (qmail 27472 invoked from network); 29 Sep 2011 14:21:22 -0000 Received: from mail-yx0-f171.google.com (HELO mail-yx0-f171.google.com) (209.85.213.171) by server-12.tower-182.messagelabs.com with RC4-SHA encrypted SMTP; 29 Sep 2011 14:21:22 -0000 Received: by yxt3 with SMTP id 3so934345yxt.30 for <xen-devel@lists.xensource.com>; Thu, 29 Sep 2011 07:21:21 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=user-agent:date:subject:from:to:cc:message-id:thread-topic :thread-index:in-reply-to:mime-version:content-type :content-transfer-encoding; bh=xGY6VTwoGCzV0OpzSh8LFUN4HL45idjTUU3idw00N7E=; b=xb5U3R9n2TxR9l/NB5AxFfNXTFhTXgCot36lv/l65yYlmStqXrTrepmuA23sWrXBHo f5IbCQAi9UvoHebQB87mKlEVWiQyTTEJ2hReuZzVhYxIgeHYT5Myp82yUW3SeOvUz4iP Voh2JGNYwrJHN4YwVnIaNWhAv2rLixEiR1MPs= Received: by 10.236.154.137 with SMTP id h9mr64339592yhk.26.1317306081241; Thu, 29 Sep 2011 07:21:21 -0700 (PDT) Received: from [10.255.255.36] ([96.49.135.17]) by mx.google.com with ESMTPS id w50sm2314902yhi.2.2011.09.29.07.21.17 (version=SSLv3 cipher=OTHER); Thu, 29 Sep 2011 07:21:19 -0700 (PDT) User-Agent: Microsoft-Entourage/12.30.0.110427 Date: Thu, 29 Sep 2011 07:21:14 -0700 Subject: Re: [Xen-devel] [PATCH 0/2] enable event channel wake-up for mem_event interfaces From: Keir Fraser <keir.xen@gmail.com> To: Adin Scannell <adin@gridcentric.com>, <xen-devel@lists.xensource.com> Message-ID: <CAA9CCEA.21D3C%keir.xen@gmail.com> Thread-Topic: [Xen-devel] [PATCH 0/2] enable event channel wake-up for mem_event interfaces Thread-Index: Acx+swtBFoXOYffjI0md8opwEL2aZw== In-Reply-To: <CAAJKtqp1jEXzfp9Y+1pYKrxdLJU65r2oj3Fc4ScPrzufH8kiig@mail.gmail.com> Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit Cc: Tim Deegan <tim@xen.org> X-BeenThere: xen-devel@lists.xensource.com X-Mailman-Version: 2.1.5 Precedence: list List-Id: Xen developer discussion <xen-devel.lists.xensource.com> List-Unsubscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe> List-Post: <mailto:xen-devel@lists.xensource.com> List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help> List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=subscribe> Sender: xen-devel-bounces@lists.xensource.com Errors-To: xen-devel-bounces@lists.xensource.com On 28/09/2011 14:22, "Adin Scannell" <adin@gridcentric.com> wrote: > Currently the mem_event code requires a domctl to kick the hypervisor > and unpause vcpus. An event channel is used to notify dom0 of > requests placed in the ring, and it can similarly be used to notify > Xen, so as not to overuse domctls when running many domains with > mem_event interfaces (domctls are not a great interface for this sort > of thing, because they will all be serialized). > > This patch set enables the use of the event channel to signal when a > response in placed in a mem_event ring. I don't have an opinion on patch 1/2. I'll leave it to someone else, like Tim, to comment. Patch 2/2 I don't mind the principle, but the implementation is not very scalable. I will post a rewritten version to the list. It might be early next week before I do so. -- Keir > The two patches are as follows: > - The first patch tweaks the memevent code to ensure that no events > are lost. Instead of calling get_response once per kick, we may have > to pull out multiple events at a time. This doesn't affect normal > operation with the domctls. > This patch also ensures that each vCPU can generate a request in each > mem_event ring (i.e. put_request will always work), by appropriately > pausing vCPUs when after requests are placed. > - The second patch breaks the Xen-side event channel handling into a > new arch-specific file "events.c", and adds cases for the different > Xen-handled event channels. This formalizes the tiny exception that > was in place for just qemu in event_channel.c. > > All the domctls are still in place and everything should be backwards > compatible. > > Cheers, > -Adin > > _______________________________________________ > Xen-devel mailing list > Xen-devel@lists.xensource.com > http://lists.xensource.com/xen-devel _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel From xen-devel-bounces@lists.xensource.com Thu Sep 29 07:22:53 2011 Return-path: <xen-devel-bounces@lists.xensource.com> Envelope-to: www-data@lists.xensource.com Delivery-date: Thu, 29 Sep 2011 07:22:53 -0700 Received: from localhost ([127.0.0.1] helo=lists.colo.xensource.com) by lists.xensource.com with esmtp (Exim 4.43) id 1R9HVl-0004ol-JG; Thu, 29 Sep 2011 07:22:53 -0700 Received: from mail174.messagelabs.com ([85.158.138.51]) by lists.xensource.com with esmtp (Exim 4.43) id 1R9HV3-0004X3-OE; Thu, 29 Sep 2011 07:22:11 -0700 X-Env-Sender: joseph.glanville@orionvm.com.au X-Msg-Ref: server-6.tower-174.messagelabs.com!1317306124!31109194!1 X-Originating-IP: [209.85.210.171] X-StarScan-Version: 6.4.1; banners=-,-,- X-VirusChecked: Checked Received: (qmail 23534 invoked from network); 29 Sep 2011 14:22:06 -0000 Received: from mail-iy0-f171.google.com (HELO mail-iy0-f171.google.com) (209.85.210.171) by server-6.tower-174.messagelabs.com with RC4-SHA encrypted SMTP; 29 Sep 2011 14:22:06 -0000 Received: by iagv1 with SMTP id v1so1028920iag.30 for <multiple recipients>; Thu, 29 Sep 2011 07:22:04 -0700 (PDT) MIME-Version: 1.0 Received: by 10.231.48.149 with SMTP id r21mr3435188ibf.95.1317306124134; Thu, 29 Sep 2011 07:22:04 -0700 (PDT) Received: by 10.231.170.15 with HTTP; Thu, 29 Sep 2011 07:22:03 -0700 (PDT) X-Originating-IP: [59.167.234.130] In-Reply-To: <20110929141317.GX12984@reaktio.net> References: <20110922130618.GA13238@phenom.oracle.com> <20110929141317.GX12984@reaktio.net> Date: Fri, 30 Sep 2011 00:22:03 +1000 Message-ID: <CAOzFzEieWhgoBWEXQFjqr8PYoVOAcU20rtA2Q3OhyA+=dD9Atg@mail.gmail.com> Subject: Re: [Xen-devel] Xen document day (Oct 12 or 26) From: Joseph Glanville <joseph.glanville@orionvm.com.au> To: =?ISO-8859-1?Q?Pasi_K=E4rkk=E4inen?= <pasik@iki.fi> Cc: xen-devel@lists.xensource.com, xen-users@lists.xensource.com, Konrad Rzeszutek Wilk <konrad.wilk@oracle.com> X-BeenThere: xen-devel@lists.xensource.com X-Mailman-Version: 2.1.5 Precedence: list List-Id: Xen developer discussion <xen-devel.lists.xensource.com> List-Unsubscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe> List-Post: <mailto:xen-devel@lists.xensource.com> List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help> List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=subscribe> Content-Type: multipart/mixed; boundary="===============0682478648==" Sender: xen-devel-bounces@lists.xensource.com Errors-To: xen-devel-bounces@lists.xensource.com --===============0682478648== Content-Type: multipart/alternative; boundary=000e0cd1af2e96e91004ae153b54 --000e0cd1af2e96e91004ae153b54 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable On 30 September 2011 00:13, Pasi K=E4rkk=E4inen <pasik@iki.fi> wrote: > On Thu, Sep 22, 2011 at 09:06:18AM -0400, Konrad Rzeszutek Wilk wrote: > > Part of what we brainstormed at Xen Hackathon was what we could do make > Xen easier. > > > > And the one thing that seemed to surface up was making the docs better = - > either > > be the Wiki or the three .pdfs that get created/shipped with Xen. > > > > One thought was to come up with a Documention Day - where volunteers > would try to > > fix up some portion of the documentation that they feel they have > > a good grasp of knowledge off and are willing to change (and also look > > to be incorrect) > > > > What do you guys think of Oct 12th or Oct 26 as a day for this? > > > > And then the next question - what page/pdf section interests you? > > > > http://bits.xensource.com/Xen/docs/user.pdf > > http://www.rites.uic.edu/~solworth/xenInterfaceManual.pdf [the one on > Xen.org is an older version] > > > > Or Wiki pages: > > http://wiki.xensource.com/xenwiki/ > > > > http://wiki.xensource.com/xenwiki/XenDom0Kernels > > http://wiki.xensource.com/xenwiki/XenSerialConsole > > http://wiki.xensource.com/xenwiki/XenParavirtOps > > http://wiki.xensource.com/xenwiki/XenCommonProblems > > > > http://wiki.xensource.com/xenwiki/Consulting > > http://wiki.xensource.com/xenwiki/Consultants > > http://wiki.xensource.com/xenwiki/VpsHostingWithXen > > > > http://wiki.xen.org/xenwiki/XenPCIpassthrough > > http://wiki.xen.org/xenwiki/VTdHowTo > > > > Some more related pages: > http://wiki.xen.org/xenwiki/Xen4.0 > http://wiki.xen.org/xenwiki/Xen4.1 > http://wiki.xen.org/xenwiki/XenKernelFeatures > http://wiki.xen.org/xenwiki/XenBestPractices > http://wiki.xen.org/xenwiki/XenHypervisorBootOptions > > Also there's something completely new that we should document: > How to install Xen VMs! which means document all the relevant methods: > boot the native distro installer as PV guest, as HVM guest, xen-tools, > virt-install, > debootstrap, rpmstart, etc.. > > That's something people ask about very often.. > Agreed. After working through a bunch of the pages I think we are going to have to have a realtime collab session to decide on some way of reorganising everything into categories. > -- Pasi > > > _______________________________________________ > Xen-devel mailing list > Xen-devel@lists.xensource.com > http://lists.xensource.com/xen-devel > --=20 * Founder | Director | VP Research Orion Virtualisation Solutions* | www.orionvm.com.au | Phone: 1300 56 99 52 | Mobile: 0428 754 846 --000e0cd1af2e96e91004ae153b54 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable <br><div class=3D"gmail_quote">On 30 September 2011 00:13, Pasi K=E4rkk=E4i= nen <span dir=3D"ltr"><<a href=3D"mailto:pasik@iki.fi">pasik@iki.fi</a>&= gt;</span> wrote:<br><blockquote class=3D"gmail_quote" style=3D"margin:0 0 = 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;"> <div class=3D"im">On Thu, Sep 22, 2011 at 09:06:18AM -0400, Konrad Rzeszute= k Wilk wrote:<br> > Part of what we brainstormed at Xen Hackathon was what we could do mak= e Xen easier.<br> ><br> > And the one thing that seemed to surface up was making the docs better= - either<br> > be the Wiki or the three .pdfs that get created/shipped with Xen.<br> ><br> > One thought was to come up with a Documention Day - where volunteers w= ould try to<br> > fix up some portion of the documentation that they feel they have<br> > a good grasp of knowledge off and are willing to change (and also look= <br> > to be incorrect)<br> ><br> > What do you guys think of Oct 12th or Oct 26 as a day for this?<br> ><br> > And then the next question - what page/pdf section interests you?<br> ><br> > <a href=3D"http://bits.xensource.com/Xen/docs/user.pdf" target=3D"_bla= nk">http://bits.xensource.com/Xen/docs/user.pdf</a><br> > <a href=3D"http://www.rites.uic.edu/%7Esolworth/xenInterfaceManual.pdf= " target=3D"_blank">http://www.rites.uic.edu/~solworth/xenInterfaceManual.p= df</a> [the one on Xen.org is an older version]<br> ><br> > Or Wiki pages:<br> > <a href=3D"http://wiki.xensource.com/xenwiki/" target=3D"_blank">http:= //wiki.xensource.com/xenwiki/</a><br> ><br> > <a href=3D"http://wiki.xensource.com/xenwiki/XenDom0Kernels" target=3D= "_blank">http://wiki.xensource.com/xenwiki/XenDom0Kernels</a><br> > <a href=3D"http://wiki.xensource.com/xenwiki/XenSerialConsole" target= =3D"_blank">http://wiki.xensource.com/xenwiki/XenSerialConsole</a><br> > <a href=3D"http://wiki.xensource.com/xenwiki/XenParavirtOps" target=3D= "_blank">http://wiki.xensource.com/xenwiki/XenParavirtOps</a><br> > <a href=3D"http://wiki.xensource.com/xenwiki/XenCommonProblems" target= =3D"_blank">http://wiki.xensource.com/xenwiki/XenCommonProblems</a><br> ><br> > <a href=3D"http://wiki.xensource.com/xenwiki/Consulting" target=3D"_bl= ank">http://wiki.xensource.com/xenwiki/Consulting</a><br> > <a href=3D"http://wiki.xensource.com/xenwiki/Consultants" target=3D"_b= lank">http://wiki.xensource.com/xenwiki/Consultants</a><br> > <a href=3D"http://wiki.xensource.com/xenwiki/VpsHostingWithXen" target= =3D"_blank">http://wiki.xensource.com/xenwiki/VpsHostingWithXen</a><br> ><br> > <a href=3D"http://wiki.xen.org/xenwiki/XenPCIpassthrough" target=3D"_b= lank">http://wiki.xen.org/xenwiki/XenPCIpassthrough</a><br> > <a href=3D"http://wiki.xen.org/xenwiki/VTdHowTo" target=3D"_blank">htt= p://wiki.xen.org/xenwiki/VTdHowTo</a><br> ><br> <br> </div>Some more related pages:<br> <a href=3D"http://wiki.xen.org/xenwiki/Xen4.0" target=3D"_blank">http://wik= i.xen.org/xenwiki/Xen4.0</a><br> <a href=3D"http://wiki.xen.org/xenwiki/Xen4.1" target=3D"_blank">http://wik= i.xen.org/xenwiki/Xen4.1</a><br> <a href=3D"http://wiki.xen.org/xenwiki/XenKernelFeatures" target=3D"_blank"= >http://wiki.xen.org/xenwiki/XenKernelFeatures</a><br> <a href=3D"http://wiki.xen.org/xenwiki/XenBestPractices" target=3D"_blank">= http://wiki.xen.org/xenwiki/XenBestPractices</a><br> <a href=3D"http://wiki.xen.org/xenwiki/XenHypervisorBootOptions" target=3D"= _blank">http://wiki.xen.org/xenwiki/XenHypervisorBootOptions</a><br> <br> Also there's something completely new that we should document:<br> How to install Xen VMs! which means document all the relevant methods:<br> boot the native distro installer as PV guest, as HVM guest, xen-tools, virt= -install,<br> debootstrap, rpmstart, etc..<br> <br> That's something people ask about very often..<br></blockquote><div>=A0= </div><div>Agreed. <br><br>After working through a bunch of the pages I thi= nk we are going to have to have a realtime collab session to decide on some= way of reorganising everything into categories.<br> <br><br></div><blockquote class=3D"gmail_quote" style=3D"margin: 0pt 0pt 0p= t 0.8ex; border-left: 1px solid rgb(204, 204, 204); padding-left: 1ex;"> <font color=3D"#888888"><br> -- Pasi<br> </font><div><div></div><div class=3D"h5"><br> <br> _______________________________________________<br> Xen-devel mailing list<br> <a href=3D"mailto:Xen-devel@lists.xensource.com">Xen-devel@lists.xensource.= com</a><br> <a href=3D"http://lists.xensource.com/xen-devel" target=3D"_blank">http://l= ists.xensource.com/xen-devel</a><br> </div></div></blockquote></div><br><br clear=3D"all"><br>-- <br><span style= =3D"font-family:arial,sans-serif;font-size:13px;border-collapse:collapse"><= b><i><font color=3D"#0000ff"><div><font color=3D"#000000"><span style=3D"fo= nt-style:normal;font-weight:normal">Founder | Director | VP Research<br> </span></font></div>Orion Virtualisation Solutions</font></i></b>=A0|=A0<fo= nt color=3D"#0000ff"><a href=3D"http://www.orionvm.com.au/" style=3D"color:= rgb(42, 93, 176)" target=3D"_blank">www.orionvm.com.au</a></font>=A0| Phone= : 1300 56 99 52 | Mobile: 0428 754 846</span><br> --000e0cd1af2e96e91004ae153b54-- --===============0682478648== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel --===============0682478648==-- From xen-devel-bounces@lists.xensource.com Thu Sep 29 07:27:13 2011 Return-path: <xen-devel-bounces@lists.xensource.com> Envelope-to: www-data@lists.xensource.com Delivery-date: Thu, 29 Sep 2011 07:27:13 -0700 Received: from localhost ([127.0.0.1] helo=lists.colo.xensource.com) by lists.xensource.com with esmtp (Exim 4.43) id 1R9HZx-0005to-Kl; Thu, 29 Sep 2011 07:27:13 -0700 Received: from mail27.messagelabs.com ([193.109.254.147]) by lists.xensource.com with esmtp (Exim 4.43) id 1R9HZS-0005hH-Fg for xen-devel@lists.xensource.com; Thu, 29 Sep 2011 07:26:42 -0700 X-Env-Sender: Ian.Jackson@eu.citrix.com X-Msg-Ref: server-13.tower-27.messagelabs.com!1317306386!42072350!1 X-Originating-IP: [62.200.22.115] X-StarScan-Version: 6.4.1; banners=-,-,- X-VirusChecked: Checked Received: (qmail 21514 invoked from network); 29 Sep 2011 14:26:26 -0000 Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115) by server-13.tower-27.messagelabs.com with RC4-SHA encrypted SMTP; 29 Sep 2011 14:26:26 -0000 X-IronPort-AV: E=Sophos;i="4.68,461,1312156800"; d="scan'208";a="8131897" Received: from lonpmailmx01.citrite.net ([10.30.203.162]) by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5; 29 Sep 2011 14:26:39 +0000 Received: from norwich.cam.xci-test.com (10.80.248.129) by smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id 8.3.137.0; Thu, 29 Sep 2011 15:26:39 +0100 Received: from mariner.cam.xci-test.com ([10.80.2.22] helo=mariner.uk.xensource.com ident=Debian-exim) by norwich.cam.xci-test.com with esmtp (Exim 4.72) (envelope-from <Ian.Jackson@eu.citrix.com>) id 1R9HZO-0008DI-NE; Thu, 29 Sep 2011 14:26:38 +0000 Received: from iwj by mariner.uk.xensource.com with local (Exim 4.69) (envelope-from <Ian.Jackson@eu.citrix.com>) id 1R9HZO-0001zH-MS; Thu, 29 Sep 2011 15:26:38 +0100 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Message-ID: <20100.32798.687145.386891@mariner.uk.xensource.com> Date: Thu, 29 Sep 2011 15:26:38 +0100 To: Adin Scannell <adin@gridcentric.com> Subject: Re: [Xen-devel] [PATCH] expose shared page count through xenlight [and 1 more messages] In-Reply-To: <CAAJKtqqXbPw0b49BvUog=95XUf41+EiVZjnWTsh=6iSbovPD9A@mail.gmail.com> References: <CAAJKtqpMqpWckNY=a9HrNZY8hT+cmH8odyLM2HKctSMY63=RRA@mail.gmail.com> <1316597699.3891.130.camel@zakaz.uk.xensource.com> <20098.689.312648.316912@mariner.uk.xensource.com> <CAAJKtqqXbPw0b49BvUog=95XUf41+EiVZjnWTsh=6iSbovPD9A@mail.gmail.com> X-Mailer: VM 8.0.9 under Emacs 21.4.1 (i486-pc-linux-gnu) From: Ian Jackson <Ian.Jackson@eu.citrix.com> Cc: Ian Campbell <Ian.Campbell@eu.citrix.com>, "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com> X-BeenThere: xen-devel@lists.xensource.com X-Mailman-Version: 2.1.5 Precedence: list List-Id: Xen developer discussion <xen-devel.lists.xensource.com> List-Unsubscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe> List-Post: <mailto:xen-devel@lists.xensource.com> List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help> List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=subscribe> Sender: xen-devel-bounces@lists.xensource.com Errors-To: xen-devel-bounces@lists.xensource.com Adin Scannell writes ("Re: [Xen-devel] [PATCH] expose shared page count through xenlight [and 1 more messages]"): > I can address the output stuff with a future patch. Ok. > For now, I've cut the patch to just add the shared page info to the > libxl info (as its already exposed through libxc) and at least > developers can access it programatically. Right, thanks. Acked-by: Ian Jackson <ian.jackson@eu.citrix.com> Committed-by: Ian Jackson <ian.jackson@eu.citrix.com> _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel From xen-devel-bounces@lists.xensource.com Thu Sep 29 07:31:49 2011 Return-path: <xen-devel-bounces@lists.xensource.com> Envelope-to: www-data@lists.xensource.com Delivery-date: Thu, 29 Sep 2011 07:31:49 -0700 Received: from localhost ([127.0.0.1] helo=lists.colo.xensource.com) by lists.xensource.com with esmtp (Exim 4.43) id 1R9HeP-0006K5-9l; Thu, 29 Sep 2011 07:31:49 -0700 Received: from mail174.messagelabs.com ([85.158.138.51]) by lists.xensource.com with esmtp (Exim 4.43) id 1R9Hdy-00067o-AS for xen-devel@lists.xensource.com; Thu, 29 Sep 2011 07:31:22 -0700 X-Env-Sender: anthony.perard@citrix.com X-Msg-Ref: server-10.tower-174.messagelabs.com!1317306677!33241838!1 X-Originating-IP: [66.165.176.89] X-StarScan-Version: 6.4.1; banners=-,-,- X-VirusChecked: Checked Received: (qmail 20654 invoked from network); 29 Sep 2011 14:31:19 -0000 Received: from smtp.citrix.com (HELO SMTP.CITRIX.COM) (66.165.176.89) by server-10.tower-174.messagelabs.com with RC4-SHA encrypted SMTP; 29 Sep 2011 14:31:19 -0000 X-IronPort-AV: E=Sophos;i="4.68,461,1312171200"; d="scan'208";a="17808649" Received: from ftlpmailmx01.citrite.net ([10.13.107.65]) by FTLPIPO01.CITRIX.COM with ESMTP/TLS/RC4-MD5; 29 Sep 2011 10:31:17 -0400 Received: from smtp01.ad.xensource.com (10.219.128.104) by smtprelay.citrix.com (10.13.107.65) with Microsoft SMTP Server id 8.3.137.0; Thu, 29 Sep 2011 10:31:17 -0400 Received: from perard.uk.xensource.com (dhcp-3-28.uk.xensource.com [10.80.3.28] (may be forged)) by smtp01.ad.xensource.com (8.13.1/8.13.1) with ESMTP id p8TEVEPM025946; Thu, 29 Sep 2011 07:31:15 -0700 From: Anthony PERARD <anthony.perard@citrix.com> To: Xen Devel <xen-devel@lists.xensource.com> Date: Thu, 29 Sep 2011 15:30:50 +0100 Message-ID: <1317306650-24028-2-git-send-email-anthony.perard@citrix.com> X-Mailer: git-send-email 1.7.2.5 In-Reply-To: <1317306650-24028-1-git-send-email-anthony.perard@citrix.com> References: <1317306650-24028-1-git-send-email-anthony.perard@citrix.com> MIME-Version: 1.0 Content-Type: text/plain Cc: Ian Campbell <Ian.Campbell@eu.citrix.com>, Anthony PERARD <anthony.perard@citrix.com>, Stefano Stabellini <stefano.stabellini@eu.citrix.com> Subject: [Xen-devel] [PATCH 2/2] libxl_qmp: use of libxl__fd_set_cloexec. X-BeenThere: xen-devel@lists.xensource.com X-Mailman-Version: 2.1.5 Precedence: list List-Id: Xen developer discussion <xen-devel.lists.xensource.com> List-Unsubscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe> List-Post: <mailto:xen-devel@lists.xensource.com> List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help> List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=subscribe> Sender: xen-devel-bounces@lists.xensource.com Errors-To: xen-devel-bounces@lists.xensource.com Signed-off-by: Anthony PERARD <anthony.perard@citrix.com> --- tools/libxl/libxl_qmp.c | 1 + 1 files changed, 1 insertions(+), 0 deletions(-) diff --git a/tools/libxl/libxl_qmp.c b/tools/libxl/libxl_qmp.c index 9e2b9e3..34db29f 100644 --- a/tools/libxl/libxl_qmp.c +++ b/tools/libxl/libxl_qmp.c @@ -302,6 +302,7 @@ static int qmp_open(libxl__qmp_handler *qmp, const char *qmp_socket_path, if (fcntl(qmp->qmp_fd, F_SETFL, flags | O_NONBLOCK) == -1) { return -1; } + libxl__fd_set_cloexec(qmp->qmp_fd); memset(&qmp->addr, 0, sizeof (&qmp->addr)); qmp->addr.sun_family = AF_UNIX; -- Anthony PERARD _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel From xen-devel-bounces@lists.xensource.com Thu Sep 29 07:32:45 2011 Return-path: <xen-devel-bounces@lists.xensource.com> Envelope-to: www-data@lists.xensource.com Delivery-date: Thu, 29 Sep 2011 07:32:45 -0700 Received: from localhost ([127.0.0.1] helo=lists.colo.xensource.com) by lists.xensource.com with esmtp (Exim 4.43) id 1R9HfI-0006gj-GT; Thu, 29 Sep 2011 07:32:45 -0700 Received: from mail27.messagelabs.com ([193.109.254.147]) by lists.xensource.com with esmtp (Exim 4.43) id 1R9Hdz-00067p-O6 for xen-devel@lists.xensource.com; Thu, 29 Sep 2011 07:31:24 -0700 X-Env-Sender: anthony.perard@citrix.com X-Msg-Ref: server-14.tower-27.messagelabs.com!1317306567!38146936!1 X-Originating-IP: [66.165.176.63] X-StarScan-Version: 6.4.1; banners=-,-,- X-VirusChecked: Checked Received: (qmail 31117 invoked from network); 29 Sep 2011 14:29:29 -0000 Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63) by server-14.tower-27.messagelabs.com with RC4-SHA encrypted SMTP; 29 Sep 2011 14:29:29 -0000 X-IronPort-AV: E=Sophos;i="4.68,461,1312171200"; d="scan'208";a="165139923" Received: from ftlpmailmx01.citrite.net ([10.13.107.65]) by FTLPIPO02.CITRIX.COM with ESMTP/TLS/RC4-MD5; 29 Sep 2011 10:31:16 -0400 Received: from smtp01.ad.xensource.com (10.219.128.104) by smtprelay.citrix.com (10.13.107.65) with Microsoft SMTP Server id 8.3.137.0; Thu, 29 Sep 2011 10:31:15 -0400 Received: from perard.uk.xensource.com (dhcp-3-28.uk.xensource.com [10.80.3.28] (may be forged)) by smtp01.ad.xensource.com (8.13.1/8.13.1) with ESMTP id p8TEVEPL025946; Thu, 29 Sep 2011 07:31:14 -0700 From: Anthony PERARD <anthony.perard@citrix.com> To: Xen Devel <xen-devel@lists.xensource.com> Date: Thu, 29 Sep 2011 15:30:49 +0100 Message-ID: <1317306650-24028-1-git-send-email-anthony.perard@citrix.com> X-Mailer: git-send-email 1.7.2.5 MIME-Version: 1.0 Content-Type: text/plain Cc: Ian Campbell <Ian.Campbell@eu.citrix.com>, Anthony PERARD <anthony.perard@citrix.com>, Stefano Stabellini <stefano.stabellini@eu.citrix.com> Subject: [Xen-devel] [PATCH 1/2] libxl: Introduce libxl__fd_set_cloexec. X-BeenThere: xen-devel@lists.xensource.com X-Mailman-Version: 2.1.5 Precedence: list List-Id: Xen developer discussion <xen-devel.lists.xensource.com> List-Unsubscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe> List-Post: <mailto:xen-devel@lists.xensource.com> List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help> List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=subscribe> Sender: xen-devel-bounces@lists.xensource.com Errors-To: xen-devel-bounces@lists.xensource.com Signed-off-by: Anthony PERARD <anthony.perard@citrix.com> --- tools/libxl/libxl_internal.c | 13 +++++++++++++ tools/libxl/libxl_internal.h | 1 + 2 files changed, 14 insertions(+), 0 deletions(-) diff --git a/tools/libxl/libxl_internal.c b/tools/libxl/libxl_internal.c index 0fb2315..56e6618 100644 --- a/tools/libxl/libxl_internal.c +++ b/tools/libxl/libxl_internal.c @@ -276,3 +276,16 @@ int libxl__file_reference_unmap(libxl_file_reference *f) return ERROR_FAIL; } + +int libxl__fd_set_cloexec(int fd) +{ + int flags = 0; + + if ((flags = fcntl(fd, F_GETFD)) == -1) { + flags = 0; + } + if ((flags & FD_CLOEXEC)) { + return 0; + } + return fcntl(fd, F_SETFD, flags | FD_CLOEXEC); +} diff --git a/tools/libxl/libxl_internal.h b/tools/libxl/libxl_internal.h index cef2036..18a673e 100644 --- a/tools/libxl/libxl_internal.h +++ b/tools/libxl/libxl_internal.h @@ -387,6 +387,7 @@ _hidden int libxl__error_set(libxl__gc *gc, int code); _hidden int libxl__file_reference_map(libxl_file_reference *f); _hidden int libxl__file_reference_unmap(libxl_file_reference *f); +_hidden int libxl__fd_set_cloexec(int fd); _hidden int libxl__e820_alloc(libxl_ctx *ctx, uint32_t domid, libxl_domain_config *d_config); -- Anthony PERARD _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel From xen-devel-bounces@lists.xensource.com Thu Sep 29 07:33:37 2011 Return-path: <xen-devel-bounces@lists.xensource.com> Envelope-to: www-data@lists.xensource.com Delivery-date: Thu, 29 Sep 2011 07:33:37 -0700 Received: from localhost ([127.0.0.1] helo=lists.colo.xensource.com) by lists.xensource.com with esmtp (Exim 4.43) id 1R9Hg9-00073W-7e; Thu, 29 Sep 2011 07:33:37 -0700 Received: from mail216.messagelabs.com ([85.158.143.99]) by lists.xensource.com with esmtp (Exim 4.43) id 1R9Heg-0006Qq-12 for xen-devel@lists.xensource.com; Thu, 29 Sep 2011 07:32:07 -0700 X-Env-Sender: keir.xen@gmail.com X-Msg-Ref: server-5.tower-216.messagelabs.com!1317306721!17916426!1 X-Originating-IP: [209.85.212.43] X-StarScan-Version: 6.4.1; banners=-,-,- X-VirusChecked: Checked Received: (qmail 10416 invoked from network); 29 Sep 2011 14:32:02 -0000 Received: from mail-vw0-f43.google.com (HELO mail-vw0-f43.google.com) (209.85.212.43) by server-5.tower-216.messagelabs.com with RC4-SHA encrypted SMTP; 29 Sep 2011 14:32:02 -0000 Received: by vws13 with SMTP id 13so682729vws.30 for <xen-devel@lists.xensource.com>; Thu, 29 Sep 2011 07:32:01 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=user-agent:date:subject:from:to:cc:message-id:thread-topic :thread-index:in-reply-to:mime-version:content-type :content-transfer-encoding; bh=IPyx8ZcROz5mS7JaG6W8wLQIUoVAmd+9S7q6bg1I0xw=; b=s4UWWv/s1FJpPsfx3cPmlcBezrWtbB1ECSrkb9xoD7dOqN8sgiki26SELG7RCA3R1j 1LCvhbWboWGKVDIqZIH4rKiJXS4sj6Oj+A1PCsdT76IuhM0onltbsGUNk+jKZwZLIvzx GKN97NNvpYOFdVMTXcqVvj5FTag27hiUwrNew= Received: by 10.229.65.74 with SMTP id h10mr7807804qci.247.1317306721642; Thu, 29 Sep 2011 07:32:01 -0700 (PDT) Received: from [10.255.255.36] ([96.49.135.17]) by mx.google.com with ESMTPS id cl1sm1986841qab.0.2011.09.29.07.31.58 (version=SSLv3 cipher=OTHER); Thu, 29 Sep 2011 07:32:00 -0700 (PDT) User-Agent: Microsoft-Entourage/12.30.0.110427 Date: Thu, 29 Sep 2011 07:31:53 -0700 Subject: Re: [Xen-devel] [PATCH] build fixes for cross-compiling From: Keir Fraser <keir.xen@gmail.com> To: Jan Beulich <JBeulich@suse.com>, Ian Campbell <Ian.Campbell@citrix.com> Message-ID: <CAA9CF69.21DEB%keir.xen@gmail.com> Thread-Topic: [Xen-devel] [PATCH] build fixes for cross-compiling Thread-Index: Acx+tIghWfvnFlZWOkKZURMPUlzlfw== In-Reply-To: <4E844703020000780005868E@nat28.tlf.novell.com> Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>, Adin Scannell <adin@gridcentric.com> X-BeenThere: xen-devel@lists.xensource.com X-Mailman-Version: 2.1.5 Precedence: list List-Id: Xen developer discussion <xen-devel.lists.xensource.com> List-Unsubscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe> List-Post: <mailto:xen-devel@lists.xensource.com> List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help> List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=subscribe> Sender: xen-devel-bounces@lists.xensource.com Errors-To: xen-devel-bounces@lists.xensource.com On 29/09/2011 01:22, "Jan Beulich" <JBeulich@suse.com> wrote: >>>> On 29.09.11 at 10:00, Ian Campbell <Ian.Campbell@citrix.com> wrote: >> We have LDFLAGS_DIRECT, adding LDFLAGS_INDIRECT seems a bit gross >> though... I wonder if perhaps LDFLAGS and LDFLAGS_DIRECT should be >> mut8lly exclusive, i.e. direct calls to the linker use only the latter >> and not both? > > Actually I always found it wrong to read commands like "$(CC) $(LDFLAGS)" > - imo xxxFLAGS should be passed exclusively to tool xxx. So rather than > having LDFLAGS_DIRECT, I'd suggest cleaning this up and having e.g. > CCLDFLAGS or CC_LINK_FLAGS or some such. Or perhaps we could arrange to only link via direct invocation of ld? Apart from the hassle of changing all our Makefiles, is there a good reason to use gcc as a linker wrapper? -- Keir > Jan > > > _______________________________________________ > Xen-devel mailing list > Xen-devel@lists.xensource.com > http://lists.xensource.com/xen-devel _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel From xen-devel-bounces@lists.xensource.com Thu Sep 29 07:41:18 2011 Return-path: <xen-devel-bounces@lists.xensource.com> Envelope-to: www-data@lists.xensource.com Delivery-date: Thu, 29 Sep 2011 07:41:18 -0700 Received: from localhost ([127.0.0.1] helo=lists.colo.xensource.com) by lists.xensource.com with esmtp (Exim 4.43) id 1R9Hna-0007Y2-1x; Thu, 29 Sep 2011 07:41:18 -0700 Received: from mail182.messagelabs.com ([85.158.139.83]) by lists.xensource.com with esmtp (Exim 4.43) id 1R9Hn6-0007LW-Ns for xen-devel@lists.xensource.com; Thu, 29 Sep 2011 07:40:49 -0700 X-Env-Sender: Ian.Jackson@eu.citrix.com X-Msg-Ref: server-15.tower-182.messagelabs.com!1317307245!19223581!1 X-Originating-IP: [62.200.22.115] X-StarScan-Version: 6.4.1; banners=-,-,- X-VirusChecked: Checked Received: (qmail 32503 invoked from network); 29 Sep 2011 14:40:45 -0000 Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115) by server-15.tower-182.messagelabs.com with RC4-SHA encrypted SMTP; 29 Sep 2011 14:40:45 -0000 X-IronPort-AV: E=Sophos;i="4.68,461,1312156800"; d="scan'208";a="8132389" Received: from lonpmailmx01.citrite.net ([10.30.203.162]) by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5; 29 Sep 2011 14:40:45 +0000 Received: from norwich.cam.xci-test.com (10.80.248.129) by smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id 8.3.137.0; Thu, 29 Sep 2011 15:40:45 +0100 Received: from mariner.cam.xci-test.com ([10.80.2.22] helo=mariner.uk.xensource.com ident=Debian-exim) by norwich.cam.xci-test.com with esmtp (Exim 4.72) (envelope-from <Ian.Jackson@eu.citrix.com>) id 1R9Hn2-0008Ge-Ua; Thu, 29 Sep 2011 14:40:44 +0000 Received: from iwj by mariner.uk.xensource.com with local (Exim 4.69) (envelope-from <Ian.Jackson@eu.citrix.com>) id 1R9Hn2-00021p-Th; Thu, 29 Sep 2011 15:40:44 +0100 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Message-ID: <20100.33644.911349.499192@mariner.uk.xensource.com> Date: Thu, 29 Sep 2011 15:40:44 +0100 To: Ian Campbell <ian.campbell@citrix.com> Subject: Re: [Xen-devel] [PATCH] xl: fixup command line handling for several commands Newsgroups: chiark.mail.xen.devel In-Reply-To: <945b1d50724b3d68c562.1317217079@cosworth.uk.xensource.com> References: <945b1d50724b3d68c562.1317217079@cosworth.uk.xensource.com> X-Mailer: VM 8.0.9 under Emacs 21.4.1 (i486-pc-linux-gnu) From: Ian Jackson <Ian.Jackson@eu.citrix.com> Cc: xen-devel@lists.xensource.com X-BeenThere: xen-devel@lists.xensource.com X-Mailman-Version: 2.1.5 Precedence: list List-Id: Xen developer discussion <xen-devel.lists.xensource.com> List-Unsubscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe> List-Post: <mailto:xen-devel@lists.xensource.com> List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help> List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=subscribe> Sender: xen-devel-bounces@lists.xensource.com Errors-To: xen-devel-bounces@lists.xensource.com Ian Campbell writes ("[Xen-devel] [PATCH] xl: fixup command line handling for several commands"): > xl: fixup command line handling for several commands. How entertaining. Acked-by: Ian Jackson <ian.jackson@eu.citrix.com> Committed-by: Ian Jackson <ian.jackson@eu.citrix.com> _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel From xen-devel-bounces@lists.xensource.com Thu Sep 29 07:51:28 2011 Return-path: <xen-devel-bounces@lists.xensource.com> Envelope-to: www-data@lists.xensource.com Delivery-date: Thu, 29 Sep 2011 07:51:28 -0700 Received: from localhost ([127.0.0.1] helo=lists.colo.xensource.com) by lists.xensource.com with esmtp (Exim 4.43) id 1R9HxO-0008C3-UF; Thu, 29 Sep 2011 07:51:27 -0700 Received: from mail21.messagelabs.com ([85.158.143.35]) by lists.xensource.com with esmtp (Exim 4.43) id 1R9Hwi-0007zA-TR for xen-devel@lists.xensource.com; Thu, 29 Sep 2011 07:50:45 -0700 X-Env-Sender: Ian.Jackson@eu.citrix.com X-Msg-Ref: server-3.tower-21.messagelabs.com!1317307852!53451068!1 X-Originating-IP: [62.200.22.115] X-StarScan-Version: 6.4.1; banners=-,-,- X-VirusChecked: Checked Received: (qmail 16435 invoked from network); 29 Sep 2011 14:50:53 -0000 Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115) by server-3.tower-21.messagelabs.com with RC4-SHA encrypted SMTP; 29 Sep 2011 14:50:53 -0000 X-IronPort-AV: E=Sophos;i="4.68,461,1312156800"; d="scan'208";a="8132646" Received: from lonpmailmx01.citrite.net ([10.30.203.162]) by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5; 29 Sep 2011 14:50:41 +0000 Received: from norwich.cam.xci-test.com (10.80.248.129) by smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id 8.3.137.0; Thu, 29 Sep 2011 15:50:41 +0100 Received: from mariner.cam.xci-test.com ([10.80.2.22] helo=mariner.uk.xensource.com ident=Debian-exim) by norwich.cam.xci-test.com with esmtp (Exim 4.72) (envelope-from <Ian.Jackson@eu.citrix.com>) id 1R9Hwf-0008J6-9V; Thu, 29 Sep 2011 14:50:41 +0000 Received: from iwj by mariner.uk.xensource.com with local (Exim 4.69) (envelope-from <Ian.Jackson@eu.citrix.com>) id 1R9Hwf-00022X-8F; Thu, 29 Sep 2011 15:50:41 +0100 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Message-ID: <20100.34241.188165.909233@mariner.uk.xensource.com> Date: Thu, 29 Sep 2011 15:50:41 +0100 To: "Jan Beulich" <JBeulich@suse.com> Subject: Re: [Xen-devel] [PATCH] build fixes for cross-compiling Newsgroups: chiark.mail.xen.devel In-Reply-To: <4E844703020000780005868E@nat28.tlf.novell.com> References: <CAAJKtqre0Q3qbngZi01NfmSQSh0YXtSyS4LZc=cOQt98Xqzcyw@mail.gmail.com> <4E843DBD020000780005865C@nat28.tlf.novell.com> <1317283241.26672.104.camel@zakaz.uk.xensource.com> <4E844703020000780005868E@nat28.tlf.novell.com> X-Mailer: VM 8.0.9 under Emacs 21.4.1 (i486-pc-linux-gnu) From: Ian Jackson <Ian.Jackson@eu.citrix.com> Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>, Ian Campbell <Ian.Campbell@citrix.com>, Adin Scannell <adin@gridcentric.com> X-BeenThere: xen-devel@lists.xensource.com X-Mailman-Version: 2.1.5 Precedence: list List-Id: Xen developer discussion <xen-devel.lists.xensource.com> List-Unsubscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe> List-Post: <mailto:xen-devel@lists.xensource.com> List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help> List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=subscribe> Sender: xen-devel-bounces@lists.xensource.com Errors-To: xen-devel-bounces@lists.xensource.com Jan Beulich writes ("Re: [Xen-devel] [PATCH] build fixes for cross-compiling"): > Ian Campbell <Ian.Campbell@citrix.com> wrote: > > We have LDFLAGS_DIRECT, adding LDFLAGS_INDIRECT seems a bit gross > > though... I wonder if perhaps LDFLAGS and LDFLAGS_DIRECT should be > > mut8lly exclusive, i.e. direct calls to the linker use only the latter > > and not both? > > Actually I always found it wrong to read commands like "$(CC) $(LDFLAGS)" > - imo xxxFLAGS should be passed exclusively to tool xxx. So rather than > having LDFLAGS_DIRECT, I'd suggest cleaning this up and having e.g. > CCLDFLAGS or CC_LINK_FLAGS or some such. Yes, I agree. Ian. _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel From xen-devel-bounces@lists.xensource.com Thu Sep 29 07:52:31 2011 Return-path: <xen-devel-bounces@lists.xensource.com> Envelope-to: www-data@lists.xensource.com Delivery-date: Thu, 29 Sep 2011 07:52:31 -0700 Received: from localhost ([127.0.0.1] helo=lists.colo.xensource.com) by lists.xensource.com with esmtp (Exim 4.43) id 1R9HyR-00007n-6Y; Thu, 29 Sep 2011 07:52:31 -0700 Received: from mail174.messagelabs.com ([85.158.138.51]) by lists.xensource.com with esmtp (Exim 4.43) id 1R9HxD-00087o-Oi for xen-devel@lists.xensource.com; Thu, 29 Sep 2011 07:51:16 -0700 X-Env-Sender: JBeulich@suse.com X-Msg-Ref: server-5.tower-174.messagelabs.com!1317307872!29559387!1 X-Originating-IP: [130.57.49.28] X-StarScan-Version: 6.4.1; banners=-,-,- X-VirusChecked: Checked Received: (qmail 18506 invoked from network); 29 Sep 2011 14:51:12 -0000 Received: from nat28.tlf.novell.com (HELO nat28.tlf.novell.com) (130.57.49.28) by server-5.tower-174.messagelabs.com with DHE-RSA-AES256-SHA encrypted SMTP; 29 Sep 2011 14:51:12 -0000 Received: from EMEA1-MTA by nat28.tlf.novell.com with Novell_GroupWise; Thu, 29 Sep 2011 15:52:03 +0100 Message-Id: <4E84A1FD0200007800058834@nat28.tlf.novell.com> X-Mailer: Novell GroupWise Internet Agent 8.0.1 Date: Thu, 29 Sep 2011 15:51:09 +0100 From: "Jan Beulich" <JBeulich@suse.com> To: "Keir Fraser" <keir.xen@gmail.com> Subject: Re: [Xen-devel] [PATCH] build fixes for cross-compiling References: <4E844703020000780005868E@nat28.tlf.novell.com> <CAA9CF69.21DEB%keir.xen@gmail.com> In-Reply-To: <CAA9CF69.21DEB%keir.xen@gmail.com> Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: quoted-printable Content-Disposition: inline Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>, Ian Campbell <Ian.Campbell@citrix.com>, Adin Scannell <adin@gridcentric.com> X-BeenThere: xen-devel@lists.xensource.com X-Mailman-Version: 2.1.5 Precedence: list List-Id: Xen developer discussion <xen-devel.lists.xensource.com> List-Unsubscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe> List-Post: <mailto:xen-devel@lists.xensource.com> List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help> List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=subscribe> Sender: xen-devel-bounces@lists.xensource.com Errors-To: xen-devel-bounces@lists.xensource.com >>> On 29.09.11 at 16:31, Keir Fraser <keir.xen@gmail.com> wrote: > On 29/09/2011 01:22, "Jan Beulich" <JBeulich@suse.com> wrote: >=20 >>>>> On 29.09.11 at 10:00, Ian Campbell <Ian.Campbell@citrix.com> wrote: >>> We have LDFLAGS_DIRECT, adding LDFLAGS_INDIRECT seems a bit gross >>> though... I wonder if perhaps LDFLAGS and LDFLAGS_DIRECT should be >>> mut8lly exclusive, i.e. direct calls to the linker use only the latter >>> and not both? >>=20 >> Actually I always found it wrong to read commands like "$(CC) $(LDFLAGS)= " >> - imo xxxFLAGS should be passed exclusively to tool xxx. So rather than >> having LDFLAGS_DIRECT, I'd suggest cleaning this up and having e.g. >> CCLDFLAGS or CC_LINK_FLAGS or some such. >=20 > Or perhaps we could arrange to only link via direct invocation of ld? = Apart > from the hassle of changing all our Makefiles, is there a good reason to = use > gcc as a linker wrapper? I'm afraid that would require manually specifying the crt*.o files as well as libgcc (if required) the compiler automatically tells the linker = to include, which would be ugly (namely when it comes to supporting multiple host OSes). Imo, invoking the naked linker should generally be avoided when linking with any kind of system provided runtime library. Jan _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel From xen-devel-bounces@lists.xensource.com Thu Sep 29 07:54:50 2011 Return-path: <xen-devel-bounces@lists.xensource.com> Envelope-to: www-data@lists.xensource.com Delivery-date: Thu, 29 Sep 2011 07:54:50 -0700 Received: from localhost ([127.0.0.1] helo=lists.colo.xensource.com) by lists.xensource.com with esmtp (Exim 4.43) id 1R9I0e-0000Wu-Sq; Thu, 29 Sep 2011 07:54:50 -0700 Received: from mail216.messagelabs.com ([85.158.143.99]) by lists.xensource.com with esmtp (Exim 4.43) id 1R9Hzw-0000Jh-HZ for xen-devel@lists.xensource.com; Thu, 29 Sep 2011 07:54:04 -0700 X-Env-Sender: Stefano.Stabellini@eu.citrix.com X-Msg-Ref: server-4.tower-216.messagelabs.com!1317308041!20009543!1 X-Originating-IP: [62.200.22.115] X-StarScan-Version: 6.4.1; banners=-,-,- X-VirusChecked: Checked Received: (qmail 17963 invoked from network); 29 Sep 2011 14:54:01 -0000 Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115) by server-4.tower-216.messagelabs.com with RC4-SHA encrypted SMTP; 29 Sep 2011 14:54:01 -0000 X-IronPort-AV: E=Sophos;i="4.68,461,1312156800"; d="scan'208";a="8132765" Received: from lonpmailmx01.citrite.net ([10.30.203.162]) by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5; 29 Sep 2011 14:54:00 +0000 Received: from kaball.uk.xensource.com (10.80.2.59) by LONPMAILMX01.citrite.net (10.30.203.162) with Microsoft SMTP Server id 8.3.137.0; Thu, 29 Sep 2011 15:54:01 +0100 Date: Thu, 29 Sep 2011 15:53:47 +0100 From: Stefano Stabellini <stefano.stabellini@eu.citrix.com> X-X-Sender: sstabellini@kaball-desktop To: Ian Campbell <Ian.Campbell@eu.citrix.com> Subject: Re: [Xen-devel] [PATCH v5 2/2] xen: modify kernel mappings corresponding to granted pages In-Reply-To: <1317305884.26672.190.camel@zakaz.uk.xensource.com> Message-ID: <alpine.DEB.2.00.1109291550250.3519@kaball-desktop> References: <alpine.DEB.2.00.1109291148340.3519@kaball-desktop> <1317293876-23891-2-git-send-email-stefano.stabellini@eu.citrix.com> <20110929135558.GA31321@phenom.oracle.com> <1317305884.26672.190.camel@zakaz.uk.xensource.com> User-Agent: Alpine 2.00 (DEB 1167 2008-08-23) MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Cc: "linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>, "jeremy@goop.org" <jeremy@goop.org>, Stefano Stabellini <Stefano.Stabellini@eu.citrix.com>, "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>, Konrad Rzeszutek Wilk <konrad.wilk@oracle.com> X-BeenThere: xen-devel@lists.xensource.com X-Mailman-Version: 2.1.5 Precedence: list List-Id: Xen developer discussion <xen-devel.lists.xensource.com> List-Unsubscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe> List-Post: <mailto:xen-devel@lists.xensource.com> List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help> List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=subscribe> Sender: xen-devel-bounces@lists.xensource.com Errors-To: xen-devel-bounces@lists.xensource.com On Thu, 29 Sep 2011, Ian Campbell wrote: > On Thu, 2011-09-29 at 14:55 +0100, Konrad Rzeszutek Wilk wrote: > > > /* Xen machine address */ > > > @@ -31,8 +32,10 @@ typedef struct xpaddr { > > > #define INVALID_P2M_ENTRY (~0UL) > > > #define FOREIGN_FRAME_BIT (1UL<<(BITS_PER_LONG-1)) > > > #define IDENTITY_FRAME_BIT (1UL<<(BITS_PER_LONG-2)) > > > +#define GRANT_FRAME_BIT (1UL<<(BITS_PER_LONG-3)) > > > > I am going to change that to (BITS_PER_LONG-1) as we aren't > > using the P2M. (and add that comment in the file). > > You should also move it away from/out of the "/**** MACHINE <-> PHYSICAL > CONVERSION MACROS ****/" section, otherwise it's just confusing. > > The associated GRANT_FRAME macro seems to be unused. > > But what is that bit in page->private actually used for? This patch adds > it in m2p_add_override and masks it off in m2p_find_override, but > doesn't otherwise appear to use it. It was needed by the previous version that was capable of handling highmem pages, it is not required anymore. _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel From xen-devel-bounces@lists.xensource.com Thu Sep 29 07:55:52 2011 Return-path: <xen-devel-bounces@lists.xensource.com> Envelope-to: www-data@lists.xensource.com Delivery-date: Thu, 29 Sep 2011 07:55:52 -0700 Received: from localhost ([127.0.0.1] helo=lists.colo.xensource.com) by lists.xensource.com with esmtp (Exim 4.43) id 1R9I1g-0000tZ-2U; Thu, 29 Sep 2011 07:55:52 -0700 Received: from mail21.messagelabs.com ([85.158.143.35]) by lists.xensource.com with esmtp (Exim 4.43) id 1R9I1B-0000hT-Jk for xen-devel@lists.xensource.com; Thu, 29 Sep 2011 07:55:21 -0700 X-Env-Sender: bickys1986@gmail.com X-Msg-Ref: server-14.tower-21.messagelabs.com!1317308109!61485610!1 X-Originating-IP: [209.85.214.43] X-StarScan-Version: 6.4.1; banners=-,-,- X-VirusChecked: Checked Received: (qmail 28616 invoked from network); 29 Sep 2011 14:55:09 -0000 Received: from mail-bw0-f43.google.com (HELO mail-bw0-f43.google.com) (209.85.214.43) by server-14.tower-21.messagelabs.com with RC4-SHA encrypted SMTP; 29 Sep 2011 14:55:09 -0000 Received: by bkas6 with SMTP id s6so982080bka.30 for <xen-devel@lists.xensource.com>; Thu, 29 Sep 2011 07:55:18 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:date:message-id:subject:from:to:cc:content-type; bh=GYe1ehrtNyS1nYCypLmo7u31C2mmf/ZxzZJ6WE9ogds=; b=hPZMwhL21l0+rPuYYxkCV4dGK5PM+A9l6hKWuFBtQkDP7QlgjAHpPYx8zwRbQo4ojH OgU/II2fyP2ZNrsfoPfs8P5C+JMSa1yeCU+1SmEsyN2/RFGRKdhsXc1RbbgdzjfilITb nICb5W1/0VJZHtL0MDQobaDHT3U/u5Iy/SHDQ= MIME-Version: 1.0 Received: by 10.204.6.215 with SMTP id a23mr5681764bka.16.1317308118049; Thu, 29 Sep 2011 07:55:18 -0700 (PDT) Received: by 10.204.60.71 with HTTP; Thu, 29 Sep 2011 07:55:18 -0700 (PDT) Date: Thu, 29 Sep 2011 22:55:18 +0800 Message-ID: <CACavRyB4kvMLZK1-vv9bJnVdnpKJBHTmnhJxt6g3eh88xY6FTg@mail.gmail.com> From: zhen shi <bickys1986@gmail.com> To: Olaf Hering <olaf@aepfle.de> Cc: xen-devel@lists.xensource.com Subject: [Xen-devel] mapping problems in xenpaging X-BeenThere: xen-devel@lists.xensource.com X-Mailman-Version: 2.1.5 Precedence: list List-Id: Xen developer discussion <xen-devel.lists.xensource.com> List-Unsubscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe> List-Post: <mailto:xen-devel@lists.xensource.com> List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help> List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=subscribe> Content-Type: multipart/mixed; boundary="===============1965437405==" Sender: xen-devel-bounces@lists.xensource.com Errors-To: xen-devel-bounces@lists.xensource.com --===============1965437405== Content-Type: multipart/alternative; boundary=0015175884e06fa52b04ae15b2d5 --0015175884e06fa52b04ae15b2d5 Content-Type: text/plain; charset=ISO-8859-1 Hi,Olaf, When we analyze and test xenpaging,we found there are some problems between mapping and xenpaging. 1) When mapping firstly, then do xenpaging,and the code paths have resolved the problems.It's OK. 2) The problems exists if we do address mapping firstly then go to xenpaging,and our confusions are as followings: a) If the domU's memory is directly mapped to dom0,such as the hypercall from pv driver,then it will build a related page-table in dom0,which will not change p2m-type. and then do the xenpaging to page out the domU's memory pages whose gfn address have been already mapped to dom0;So it will cause some problems when dom0 accesses these pages.Because these pages are paged-out,and dom0 cannot tell the p2mt before access the pages. b)The another situation is that if xen has mapped the domU's page, and get the mfn according to pfn_to_mfn.But then the page's p2mt is changed by others, so when xen accesses the page ,it will cause problems such as BSOD or reboot.Because the operations of getting mfn and accessing the page are not atomic.and the situation exists in many code paths . According to the above-mentioned points,do you have any suggestions about what to do to avoid these situations.We have thought these two problems,but currently have no good method to resolve. I am looking forward to hearing from you. Thank you very much! :) --0015175884e06fa52b04ae15b2d5 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable <div>=A0Hi,Olaf,</div> <div>=A0</div> <div>=A0When we analyze and test xenpaging,we found there are some problems= =A0between mapping and xenpaging.</div> <div>=A01) When mapping firstly, then do xenpaging,and the code paths have = resolved the problems.It's OK.</div> <div>=A02) The problems exists if we do address mapping firstly then go to = xenpaging,and our confusions are as followings:</div> <div>=A0=A0 a) If the domU's memory is directly mapped to dom0,such as = the hypercall from pv driver,then it will build a related page-table in dom= 0,which will not change p2m-type.</div> <div>=A0=A0=A0=A0 =A0and then do the xenpaging to page out the domU's m= emory pages whose gfn address have been already mapped to dom0;So it will c= ause some problems when dom0 </div> <div>=A0=A0=A0=A0 =A0accesses these pages.Because these pages are paged-out= ,and dom0 cannot tell the p2mt before access the pages.</div> <div>=A0 b)The another situation is that if xen has mapped the domU's p= age, and get the mfn according to pfn_to_mfn.But then the page's p2mt i= s changed by others, so when xen </div> <div>=A0=A0=A0 accesses the page ,it will cause problems such as BSOD or re= boot.Because the operations of getting mfn and accessing the page are not a= tomic.and=A0the=A0situation exists </div> <div>=A0=A0=A0 in=A0many code paths .</div> <div>=A0=A0 According to the above-mentioned points,do you have any suggest= ions about what to do to avoid these situations.We have thought these two p= roblems,but currently have no</div> <div>=A0 good method to resolve.</div> <div>=A0 </div> <div>=A0 I am looking forward to hearing from you. Thank you very much!=A0 = :)</div> <div>=A0</div> <div>=A0 </div> <div>=A0</div> --0015175884e06fa52b04ae15b2d5-- --===============1965437405== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel --===============1965437405==-- From xen-devel-bounces@lists.xensource.com Thu Sep 29 08:06:20 2011 Return-path: <xen-devel-bounces@lists.xensource.com> Envelope-to: www-data@lists.xensource.com Delivery-date: Thu, 29 Sep 2011 08:06:20 -0700 Received: from localhost ([127.0.0.1] helo=lists.colo.xensource.com) by lists.xensource.com with esmtp (Exim 4.43) id 1R9IBn-0001WY-7t; Thu, 29 Sep 2011 08:06:20 -0700 Received: from mail21.messagelabs.com ([85.158.143.35]) by lists.xensource.com with esmtp (Exim 4.43) id 1R9IAC-0001HQ-Bw for Xen-devel@lists.xensource.com; Thu, 29 Sep 2011 08:04:41 -0700 X-Env-Sender: Ian.Jackson@eu.citrix.com X-Msg-Ref: server-9.tower-21.messagelabs.com!1317308631!50321869!1 X-Originating-IP: [62.200.22.115] X-StarScan-Version: 6.4.1; banners=-,-,- X-VirusChecked: Checked Received: (qmail 9996 invoked from network); 29 Sep 2011 15:03:51 -0000 Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115) by server-9.tower-21.messagelabs.com with RC4-SHA encrypted SMTP; 29 Sep 2011 15:03:51 -0000 X-IronPort-AV: E=Sophos;i="4.68,461,1312156800"; d="scan'208";a="8133107" Received: from lonpmailmx01.citrite.net ([10.30.203.162]) by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5; 29 Sep 2011 15:04:37 +0000 Received: from norwich.cam.xci-test.com (10.80.248.129) by smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id 8.3.137.0; Thu, 29 Sep 2011 16:04:37 +0100 Received: from mariner.cam.xci-test.com ([10.80.2.22] helo=mariner.uk.xensource.com ident=Debian-exim) by norwich.cam.xci-test.com with esmtp (Exim 4.72) (envelope-from <Ian.Jackson@eu.citrix.com>) id 1R9IA8-0008MK-Pw; Thu, 29 Sep 2011 15:04:36 +0000 Received: from iwj by mariner.uk.xensource.com with local (Exim 4.69) (envelope-from <Ian.Jackson@eu.citrix.com>) id 1R9IA8-00023F-OR; Thu, 29 Sep 2011 16:04:36 +0100 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Message-ID: <20100.35076.748503.4391@mariner.uk.xensource.com> Date: Thu, 29 Sep 2011 16:04:36 +0100 To: George Dunlap <George.Dunlap@eu.citrix.com> Subject: Re: [Xen-devel] Monitoring traffic Newsgroups: chiark.mail.xen.devel In-Reply-To: <CAFLBxZZLv=cJnCbkiv93eYGRLxPFVZDnsMS6-2qC1Ubqj8B6cQ@mail.gmail.com> References: <CAEO0G+B7j2hGZQZuK63CR_cCCXMv8k3eBqXcs+MAzJ2u5mabcw@mail.gmail.com> <CAFLBxZZLv=cJnCbkiv93eYGRLxPFVZDnsMS6-2qC1Ubqj8B6cQ@mail.gmail.com> X-Mailer: VM 8.0.9 under Emacs 21.4.1 (i486-pc-linux-gnu) From: Ian Jackson <Ian.Jackson@eu.citrix.com> Cc: Xen-devel@lists.xensource.com, Sarath P R <sarath.amrita@gmail.com> X-BeenThere: xen-devel@lists.xensource.com X-Mailman-Version: 2.1.5 Precedence: list List-Id: Xen developer discussion <xen-devel.lists.xensource.com> List-Unsubscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe> List-Post: <mailto:xen-devel@lists.xensource.com> List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help> List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=subscribe> Sender: xen-devel-bounces@lists.xensource.com Errors-To: xen-devel-bounces@lists.xensource.com George Dunlap writes ("Re: [Xen-devel] Monitoring traffic"): > On Thu, Sep 29, 2011 at 4:36 AM, Sarath P R <sarath.amrita@gmail.com> wrote: > > I am new to Xen. as part of my job i need to monitor some traffic. Like a > > packet originates from which VM and all. Any APIs available for this or > > where should i start with. Any help. thanks in advance > > Have you looked into tcpdump or wireshark? I know you mean well, but I think it's a mistake to answer these kind of badly-misdirected user questions on xen-devel. Other users with user questions will see this in the list archives and ask their question here too. But the purpose of this list is for us to engage in the development of Xen, and user questions (and the threads they cause) are a distraction from that. Thanks, Ian. _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel From xen-devel-bounces@lists.xensource.com Thu Sep 29 08:08:13 2011 Return-path: <xen-devel-bounces@lists.xensource.com> Envelope-to: www-data@lists.xensource.com Delivery-date: Thu, 29 Sep 2011 08:08:13 -0700 Received: from localhost ([127.0.0.1] helo=lists.colo.xensource.com) by lists.xensource.com with esmtp (Exim 4.43) id 1R9IDc-0001uP-F1; Thu, 29 Sep 2011 08:08:12 -0700 Received: from mail216.messagelabs.com ([85.158.143.99]) by lists.xensource.com with esmtp (Exim 4.43) id 1R9IC1-0001Yw-PB for xen-devel@lists.xensource.com; Thu, 29 Sep 2011 08:06:34 -0700 X-Env-Sender: Ian.Jackson@eu.citrix.com X-Msg-Ref: server-6.tower-216.messagelabs.com!1317308790!18764412!1 X-Originating-IP: [62.200.22.115] X-StarScan-Version: 6.4.1; banners=-,-,- X-VirusChecked: Checked Received: (qmail 31162 invoked from network); 29 Sep 2011 15:06:30 -0000 Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115) by server-6.tower-216.messagelabs.com with RC4-SHA encrypted SMTP; 29 Sep 2011 15:06:30 -0000 X-IronPort-AV: E=Sophos;i="4.68,461,1312156800"; d="scan'208";a="8133166" Received: from lonpmailmx01.citrite.net ([10.30.203.162]) by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5; 29 Sep 2011 15:06:13 +0000 Received: from norwich.cam.xci-test.com (10.80.248.129) by smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id 8.3.137.0; Thu, 29 Sep 2011 16:06:14 +0100 Received: from mariner.cam.xci-test.com ([10.80.2.22] helo=mariner.uk.xensource.com ident=Debian-exim) by norwich.cam.xci-test.com with esmtp (Exim 4.72) (envelope-from <Ian.Jackson@eu.citrix.com>) id 1R9IBh-0008Mm-DN; Thu, 29 Sep 2011 15:06:13 +0000 Received: from iwj by mariner.uk.xensource.com with local (Exim 4.69) (envelope-from <Ian.Jackson@eu.citrix.com>) id 1R9IBh-00027p-CY; Thu, 29 Sep 2011 16:06:13 +0100 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Message-ID: <20100.35173.378665.131225@mariner.uk.xensource.com> Date: Thu, 29 Sep 2011 16:06:13 +0100 To: Anthony PERARD <anthony.perard@citrix.com> Subject: Re: [Xen-devel] [PATCH 1/2] libxl: Introduce libxl__fd_set_cloexec. Newsgroups: chiark.mail.xen.devel In-Reply-To: <1317306650-24028-1-git-send-email-anthony.perard@citrix.com> References: <1317306650-24028-1-git-send-email-anthony.perard@citrix.com> X-Mailer: VM 8.0.9 under Emacs 21.4.1 (i486-pc-linux-gnu) From: Ian Jackson <Ian.Jackson@eu.citrix.com> Cc: Ian Campbell <Ian.Campbell@eu.citrix.com>, Xen Devel <xen-devel@lists.xensource.com>, Stefano Stabellini <stefano.stabellini@eu.citrix.com> X-BeenThere: xen-devel@lists.xensource.com X-Mailman-Version: 2.1.5 Precedence: list List-Id: Xen developer discussion <xen-devel.lists.xensource.com> List-Unsubscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe> List-Post: <mailto:xen-devel@lists.xensource.com> List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help> List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=subscribe> Sender: xen-devel-bounces@lists.xensource.com Errors-To: xen-devel-bounces@lists.xensource.com Anthony PERARD writes ("[Xen-devel] [PATCH 1/2] libxl: Introduce libxl__fd_set_cloexec."): > Signed-off-by: Anthony PERARD <anthony.perard@citrix.com> Thanks. Acked-by: Ian Jackson <ian.jackson@eu.citrix.com> Committed-by: Ian Jackson <ian.jackson@eu.citrix.com> _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel From xen-devel-bounces@lists.xensource.com Thu Sep 29 08:09:46 2011 Return-path: <xen-devel-bounces@lists.xensource.com> Envelope-to: www-data@lists.xensource.com Delivery-date: Thu, 29 Sep 2011 08:09:46 -0700 Received: from localhost ([127.0.0.1] helo=lists.colo.xensource.com) by lists.xensource.com with esmtp (Exim 4.43) id 1R9IF7-0002Hk-VY; Thu, 29 Sep 2011 08:09:46 -0700 Received: from mail216.messagelabs.com ([85.158.143.99]) by lists.xensource.com with esmtp (Exim 4.43) id 1R9IDd-0001u5-8p for xen-devel@lists.xensource.com; Thu, 29 Sep 2011 08:08:13 -0700 X-Env-Sender: Ian.Jackson@eu.citrix.com X-Msg-Ref: server-10.tower-216.messagelabs.com!1317308890!10264449!1 X-Originating-IP: [62.200.22.115] X-StarScan-Version: 6.4.1; banners=-,-,- X-VirusChecked: Checked Received: (qmail 27723 invoked from network); 29 Sep 2011 15:08:10 -0000 Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115) by server-10.tower-216.messagelabs.com with RC4-SHA encrypted SMTP; 29 Sep 2011 15:08:10 -0000 X-IronPort-AV: E=Sophos;i="4.68,461,1312156800"; d="scan'208";a="8133237" Received: from lonpmailmx01.citrite.net ([10.30.203.162]) by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5; 29 Sep 2011 15:08:10 +0000 Received: from norwich.cam.xci-test.com (10.80.248.129) by smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id 8.3.137.0; Thu, 29 Sep 2011 16:08:10 +0100 Received: from mariner.cam.xci-test.com ([10.80.2.22] helo=mariner.uk.xensource.com ident=Debian-exim) by norwich.cam.xci-test.com with esmtp (Exim 4.72) (envelope-from <Ian.Jackson@eu.citrix.com>) id 1R9IDZ-0008ND-Nz; Thu, 29 Sep 2011 15:08:09 +0000 Received: from iwj by mariner.uk.xensource.com with local (Exim 4.69) (envelope-from <Ian.Jackson@eu.citrix.com>) id 1R9IDX-00028u-Rf; Thu, 29 Sep 2011 16:08:09 +0100 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Message-ID: <20100.35287.848510.502572@mariner.uk.xensource.com> Date: Thu, 29 Sep 2011 16:08:07 +0100 To: Anthony PERARD <anthony.perard@citrix.com> Subject: Re: [Xen-devel] [PATCH 2/2] libxl_qmp: use of libxl__fd_set_cloexec. Newsgroups: chiark.mail.xen.devel In-Reply-To: <1317306650-24028-2-git-send-email-anthony.perard@citrix.com> References: <1317306650-24028-1-git-send-email-anthony.perard@citrix.com> <1317306650-24028-2-git-send-email-anthony.perard@citrix.com> X-Mailer: VM 8.0.9 under Emacs 21.4.1 (i486-pc-linux-gnu) From: Ian Jackson <Ian.Jackson@eu.citrix.com> Cc: Ian Campbell <Ian.Campbell@eu.citrix.com>, Xen Devel <xen-devel@lists.xensource.com>, Stefano Stabellini <stefano.stabellini@eu.citrix.com> X-BeenThere: xen-devel@lists.xensource.com X-Mailman-Version: 2.1.5 Precedence: list List-Id: Xen developer discussion <xen-devel.lists.xensource.com> List-Unsubscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe> List-Post: <mailto:xen-devel@lists.xensource.com> List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help> List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=subscribe> Sender: xen-devel-bounces@lists.xensource.com Errors-To: xen-devel-bounces@lists.xensource.com Anthony PERARD writes ("[Xen-devel] [PATCH 2/2] libxl_qmp: use of libxl__fd_set_cloexec."): > Signed-off-by: Anthony PERARD <anthony.perard@citrix.com> This patch depends on your qmp series and is indeed a fix to 7/7 "libxl: Introduce a QMP client", so I will try to stack it on the end of those. In general this kind of thing should be mentioned although in this case I've noticed for myself :-). Thanks, Ian. _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel From xen-devel-bounces@lists.xensource.com Thu Sep 29 08:10:39 2011 Return-path: <xen-devel-bounces@lists.xensource.com> Envelope-to: www-data@lists.xensource.com Delivery-date: Thu, 29 Sep 2011 08:10:39 -0700 Received: from localhost ([127.0.0.1] helo=lists.colo.xensource.com) by lists.xensource.com with esmtp (Exim 4.43) id 1R9IFy-0002eR-Uq; Thu, 29 Sep 2011 08:10:39 -0700 Received: from mail182.messagelabs.com ([85.158.139.83]) by lists.xensource.com with esmtp (Exim 4.43) id 1R9IDg-0001up-Km for xen-devel@lists.xensource.com; Thu, 29 Sep 2011 08:08:17 -0700 X-Env-Sender: keir.xen@gmail.com X-Msg-Ref: server-4.tower-182.messagelabs.com!1317308892!20247921!1 X-Originating-IP: [209.85.218.43] X-StarScan-Version: 6.4.1; banners=-,-,- X-VirusChecked: Checked Received: (qmail 14933 invoked from network); 29 Sep 2011 15:08:13 -0000 Received: from mail-yi0-f43.google.com (HELO mail-yi0-f43.google.com) (209.85.218.43) by server-4.tower-182.messagelabs.com with RC4-SHA encrypted SMTP; 29 Sep 2011 15:08:13 -0000 Received: by yib17 with SMTP id 17so945140yib.30 for <xen-devel@lists.xensource.com>; Thu, 29 Sep 2011 08:08:12 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=user-agent:date:subject:from:to:cc:message-id:thread-topic :thread-index:in-reply-to:mime-version:content-type :content-transfer-encoding; bh=KDPrJr2ypj1/a2LKORPAe/Je3vhfqYfx+1dXxmMJH6k=; b=eaHWGaRBqoj8k65wBJV/l6+jyOxJOuiNoGMTWqPHNpNdWPd2y/JmCF4EAS3w3c8XFH uT6tP30CKoXypWQMshQ3kO8x6hYhjkXtwuc4i9OTMs2VGBIsDvzK/P+MF/35xIolbx1m 1TLaHfNyWY81NMiHduo7hovEJuaMbd1aj5+IE= Received: by 10.150.216.16 with SMTP id o16mr9075710ybg.13.1317308892131; Thu, 29 Sep 2011 08:08:12 -0700 (PDT) Received: from [10.255.255.36] ([96.49.135.17]) by mx.google.com with ESMTPS id c2sm444533ybj.16.2011.09.29.08.08.09 (version=SSLv3 cipher=OTHER); Thu, 29 Sep 2011 08:08:11 -0700 (PDT) User-Agent: Microsoft-Entourage/12.30.0.110427 Date: Thu, 29 Sep 2011 08:08:06 -0700 Subject: Re: [Xen-devel] [PATCH] build fixes for cross-compiling From: Keir Fraser <keir.xen@gmail.com> To: Jan Beulich <JBeulich@suse.com> Message-ID: <CAA9D7E6.21DFF%keir.xen@gmail.com> Thread-Topic: [Xen-devel] [PATCH] build fixes for cross-compiling Thread-Index: Acx+uZdWZzZv5sn+MEyHo3Mo866J9A== In-Reply-To: <4E84A1FD0200007800058834@nat28.tlf.novell.com> Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>, Ian Campbell <Ian.Campbell@citrix.com>, Adin Scannell <adin@gridcentric.com> X-BeenThere: xen-devel@lists.xensource.com X-Mailman-Version: 2.1.5 Precedence: list List-Id: Xen developer discussion <xen-devel.lists.xensource.com> List-Unsubscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe> List-Post: <mailto:xen-devel@lists.xensource.com> List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help> List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=subscribe> Sender: xen-devel-bounces@lists.xensource.com Errors-To: xen-devel-bounces@lists.xensource.com On 29/09/2011 07:51, "Jan Beulich" <JBeulich@suse.com> wrote: >> Or perhaps we could arrange to only link via direct invocation of ld? Apart >> from the hassle of changing all our Makefiles, is there a good reason to use >> gcc as a linker wrapper? > > I'm afraid that would require manually specifying the crt*.o files as > well as libgcc (if required) the compiler automatically tells the linker to > include, which would be ugly (namely when it comes to supporting > multiple host OSes). Imo, invoking the naked linker should generally be > avoided when linking with any kind of system provided runtime library. Good point. -- Keir _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel From xen-devel-bounces@lists.xensource.com Thu Sep 29 08:21:49 2011 Return-path: <xen-devel-bounces@lists.xensource.com> Envelope-to: www-data@lists.xensource.com Delivery-date: Thu, 29 Sep 2011 08:21:49 -0700 Received: from localhost ([127.0.0.1] helo=lists.colo.xensource.com) by lists.xensource.com with esmtp (Exim 4.43) id 1R9IQn-0003Gs-LE; Thu, 29 Sep 2011 08:21:49 -0700 Received: from mail216.messagelabs.com ([85.158.143.99]) by lists.xensource.com with smtp (Exim 4.43) id 1R9IQC-00034B-8I for xen-devel@lists.xensource.com; Thu, 29 Sep 2011 08:21:12 -0700 X-Env-Sender: jinsong.liu@intel.com X-Msg-Ref: server-12.tower-216.messagelabs.com!1317309667!14287148!1 X-Originating-IP: [192.55.52.93] X-StarScan-Version: 6.4.1; banners=-,-,- X-VirusChecked: Checked Received: (qmail 29944 invoked from network); 29 Sep 2011 15:21:08 -0000 Received: from mga11.intel.com (HELO mga11.intel.com) (192.55.52.93) by server-12.tower-216.messagelabs.com with SMTP; 29 Sep 2011 15:21:08 -0000 Received: from fmsmga002.fm.intel.com ([10.253.24.26]) by fmsmga102.fm.intel.com with ESMTP; 29 Sep 2011 08:21:07 -0700 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="4.68,461,1312182000"; d="scan'208";a="72131323" Received: from pgsmsx602.gar.corp.intel.com ([10.221.43.81]) by fmsmga002.fm.intel.com with ESMTP; 29 Sep 2011 08:21:03 -0700 Received: from pgsmsx103.gar.corp.intel.com (10.221.44.82) by pgsmsx602.gar.corp.intel.com (10.221.43.81) with Microsoft SMTP Server (TLS) id 8.2.255.0; Thu, 29 Sep 2011 23:21:02 +0800 Received: from shsmsx601.ccr.corp.intel.com (10.239.4.112) by PGSMSX103.gar.corp.intel.com (10.221.44.82) with Microsoft SMTP Server (TLS) id 14.1.323.3; Thu, 29 Sep 2011 23:21:02 +0800 Received: from shsmsx502.ccr.corp.intel.com ([10.239.4.96]) by shsmsx601.ccr.corp.intel.com ([10.239.4.112]) with mapi; Thu, 29 Sep 2011 23:21:00 +0800 From: "Liu, Jinsong" <jinsong.liu@intel.com> To: Keir Fraser <keir.xen@gmail.com>, "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com> Date: Thu, 29 Sep 2011 23:20:59 +0800 Thread-Topic: [PATCH] X86 MCE: Add SRAR handler Thread-Index: Acx+u2Q1yNlzPhj/SO+HbpwXHIBlVQ== Message-ID: <BC00F5384FCFC9499AF06F92E8B78A9E263B557B77@shsmsx502.ccr.corp.intel.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: multipart/mixed; boundary="_002_BC00F5384FCFC9499AF06F92E8B78A9E263B557B77shsmsx502ccrc_" MIME-Version: 1.0 Cc: "Jiang, Yunhong" <yunhong.jiang@intel.com> Subject: [Xen-devel] [PATCH] X86 MCE: Add SRAR handler X-BeenThere: xen-devel@lists.xensource.com X-Mailman-Version: 2.1.5 Precedence: list List-Id: Xen developer discussion <xen-devel.lists.xensource.com> List-Unsubscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe> List-Post: <mailto:xen-devel@lists.xensource.com> List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help> List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=subscribe> Sender: xen-devel-bounces@lists.xensource.com Errors-To: xen-devel-bounces@lists.xensource.com --_002_BC00F5384FCFC9499AF06F92E8B78A9E263B557B77shsmsx502ccrc_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable X86 MCE: Add SRAR handler Currently Intel SDM add 2 kinds of MCE SRAR errors: 1). Data Load error, error code =3D 0x134 2). Instruction Fetch error, error code =3D 0x150 This patch add handler to these new SRAR errors. It based on existed mce infrastructure, add code to handle SRAR specific er= ror. Signed-off-by: Liu, Jinsong <jinsong.liu@intel.com> diff -r 8d6edc3d26d2 xen/arch/x86/cpu/mcheck/mce_intel.c --- a/xen/arch/x86/cpu/mcheck/mce_intel.c Sat Aug 13 10:14:58 2011 +0100 +++ b/xen/arch/x86/cpu/mcheck/mce_intel.c Sat Aug 20 23:53:02 2011 +0800 @@ -37,6 +37,14 @@ static int __read_mostly nr_intel_ext_ms */ #define INTEL_SRAO_MEM_SCRUB 0xC0 ... 0xCF #define INTEL_SRAO_L3_EWB 0x17A + +/*=20 + * Currently Intel SDM define 2 kinds of srar errors: + * 1). Data Load error, error code =3D 0x134 + * 2). Instruction Fetch error, error code =3D 0x150 + */ +#define INTEL_SRAR_DATA_LOAD 0x134 +#define INTEL_SRAR_INSTR_FETCH 0x150 =20 /* Thermal Hanlding */ #ifdef CONFIG_X86_MCE_THERMAL @@ -255,7 +263,7 @@ static enum mce_result mce_action(struct for ( i =3D 0; i < handler_num; i++ ) { if (handlers[i].owned_error(binfo.mib->mc_status)) { - handlers[i].recovery_handler(&binfo, &bank_result); + handlers[i].recovery_handler(&binfo, &bank_result, regs); if (worst_result < bank_result) worst_result =3D bank_result; break; @@ -621,7 +629,8 @@ struct mcinfo_recovery *mci_add_pageoff_ =20 static void intel_memerr_dhandler( struct mca_binfo *binfo, - enum mce_result *result) + enum mce_result *result, + struct cpu_user_regs *regs) { struct mcinfo_bank *bank =3D binfo->mib; struct mcinfo_global *global =3D binfo->mig; @@ -718,6 +727,32 @@ vmce_failed: } } =20 +static int intel_srar_check(uint64_t status) +{ + return ( intel_check_mce_type(status) =3D=3D intel_mce_ucr_srar ); +} + +static void intel_srar_dhandler( + struct mca_binfo *binfo, + enum mce_result *result, + struct cpu_user_regs *regs) +{ + uint64_t status =3D binfo->mib->mc_status; + + /* For unknown srar error code, reset system */ + *result =3D MCER_RESET; + + switch ( status & INTEL_MCCOD_MASK ) + { + case INTEL_SRAR_DATA_LOAD: + case INTEL_SRAR_INSTR_FETCH: + intel_memerr_dhandler(binfo, result, regs); + break; + default: + break; + } +} + static int intel_srao_check(uint64_t status) { return ( intel_check_mce_type(status) =3D=3D intel_mce_ucr_srao ); @@ -725,7 +760,8 @@ static int intel_srao_check(uint64_t sta =20 static void intel_srao_dhandler( struct mca_binfo *binfo, - enum mce_result *result) + enum mce_result *result, + struct cpu_user_regs *regs) { uint64_t status =3D binfo->mib->mc_status; =20 @@ -738,7 +774,7 @@ static void intel_srao_dhandler( { case INTEL_SRAO_MEM_SCRUB: case INTEL_SRAO_L3_EWB: - intel_memerr_dhandler(binfo, result); + intel_memerr_dhandler(binfo, result, regs); break; default: break; @@ -753,14 +789,15 @@ static int intel_default_check(uint64_t=20 =20 static void intel_default_mce_dhandler( struct mca_binfo *binfo, - enum mce_result *result) + enum mce_result *result, + struct cpu_user_regs * regs) { uint64_t status =3D binfo->mib->mc_status; enum intel_mce_type type; =20 type =3D intel_check_mce_type(status); =20 - if (type =3D=3D intel_mce_fatal || type =3D=3D intel_mce_ucr_srar) + if (type =3D=3D intel_mce_fatal) *result =3D MCER_RESET; else *result =3D MCER_CONTINUE; @@ -768,12 +805,14 @@ static void intel_default_mce_dhandler( =20 static const struct mca_error_handler intel_mce_dhandlers[] =3D { {intel_srao_check, intel_srao_dhandler}, + {intel_srar_check, intel_srar_dhandler}, {intel_default_check, intel_default_mce_dhandler} }; =20 static void intel_default_mce_uhandler( struct mca_binfo *binfo, - enum mce_result *result) + enum mce_result *result, + struct cpu_user_regs *regs) { uint64_t status =3D binfo->mib->mc_status; enum intel_mce_type type; @@ -782,8 +821,12 @@ static void intel_default_mce_uhandler( =20 switch (type) { - /* Panic if no handler for SRAR error */ case intel_mce_ucr_srar: + if ( !guest_mode(regs) ) + *result =3D MCER_RESET; + else + *result =3D MCER_CONTINUE; + break; case intel_mce_fatal: *result =3D MCER_RESET; break; @@ -958,10 +1001,8 @@ static int intel_recoverable_scan(u64 st /* SRAR error */ else if ( ser_support && !(status & MCi_STATUS_OVER)=20 && !(status & MCi_STATUS_PCC) && (status & MCi_STATUS_S) - && (status & MCi_STATUS_AR) ) { - mce_printk(MCE_VERBOSE, "MCE: No SRAR error defined currently.\n")= ; - return 0; - } + && (status & MCi_STATUS_AR) && (status & MCi_STATUS_EN) ) + return 1; /* SRAO error */ else if (ser_support && !(status & MCi_STATUS_PCC) && (status & MCi_STATUS_S) && !(status & MCi_STATUS_AR) diff -r 8d6edc3d26d2 xen/arch/x86/cpu/mcheck/x86_mca.h --- a/xen/arch/x86/cpu/mcheck/x86_mca.h Sat Aug 13 10:14:58 2011 +0100 +++ b/xen/arch/x86/cpu/mcheck/x86_mca.h Sat Aug 20 23:53:02 2011 +0800 @@ -151,7 +151,7 @@ struct mca_error_handler */ int (*owned_error)(uint64_t status); void (*recovery_handler)(struct mca_binfo *binfo, - enum mce_result *result); + enum mce_result *result, struct cpu_user_regs *regs); }; =20 /* Global variables */= --_002_BC00F5384FCFC9499AF06F92E8B78A9E263B557B77shsmsx502ccrc_ Content-Type: application/octet-stream; name="srar-1.patch" Content-Description: srar-1.patch Content-Disposition: attachment; filename="srar-1.patch"; size=5819; creation-date="Thu, 29 Sep 2011 23:17:18 GMT"; modification-date="Fri, 30 Sep 2011 07:15:58 GMT" Content-Transfer-Encoding: base64 WDg2IE1DRTogQWRkIFNSQVIgaGFuZGxlcgoKQ3VycmVudGx5IEludGVsIFNETSBhZGQgMiBraW5k cyBvZiBNQ0UgU1JBUiBlcnJvcnM6CjEpLiBEYXRhIExvYWQgZXJyb3IsIGVycm9yIGNvZGUgPSAw eDEzNAoyKS4gSW5zdHJ1Y3Rpb24gRmV0Y2ggZXJyb3IsIGVycm9yIGNvZGUgPSAweDE1MApUaGlz IHBhdGNoIGFkZCBoYW5kbGVyIHRvIHRoZXNlIG5ldyBTUkFSIGVycm9ycy4KSXQgYmFzZWQgb24g ZXhpc3RlZCBtY2UgaW5mcmFzdHJ1Y3R1cmUsIGFkZCBjb2RlIHRvIGhhbmRsZSBTUkFSIHNwZWNp ZmljIGVycm9yLgoKU2lnbmVkLW9mZi1ieTogTGl1LCBKaW5zb25nIDxqaW5zb25nLmxpdUBpbnRl bC5jb20+CgpkaWZmIC1yIDhkNmVkYzNkMjZkMiB4ZW4vYXJjaC94ODYvY3B1L21jaGVjay9tY2Vf aW50ZWwuYwotLS0gYS94ZW4vYXJjaC94ODYvY3B1L21jaGVjay9tY2VfaW50ZWwuYwlTYXQgQXVn IDEzIDEwOjE0OjU4IDIwMTEgKzAxMDAKKysrIGIveGVuL2FyY2gveDg2L2NwdS9tY2hlY2svbWNl X2ludGVsLmMJU2F0IEF1ZyAyMCAyMzo1MzowMiAyMDExICswODAwCkBAIC0zNyw2ICszNywxNCBA QCBzdGF0aWMgaW50IF9fcmVhZF9tb3N0bHkgbnJfaW50ZWxfZXh0X21zCiAgKi8KICNkZWZpbmUg SU5URUxfU1JBT19NRU1fU0NSVUIgMHhDMCAuLi4gMHhDRgogI2RlZmluZSBJTlRFTF9TUkFPX0wz X0VXQiAgICAweDE3QQorCisvKiAKKyAqIEN1cnJlbnRseSBJbnRlbCBTRE0gZGVmaW5lIDIga2lu ZHMgb2Ygc3JhciBlcnJvcnM6CisgKiAxKS4gRGF0YSBMb2FkIGVycm9yLCBlcnJvciBjb2RlID0g MHgxMzQKKyAqIDIpLiBJbnN0cnVjdGlvbiBGZXRjaCBlcnJvciwgZXJyb3IgY29kZSA9IDB4MTUw CisgKi8KKyNkZWZpbmUgSU5URUxfU1JBUl9EQVRBX0xPQUQJMHgxMzQKKyNkZWZpbmUgSU5URUxf U1JBUl9JTlNUUl9GRVRDSAkweDE1MAogCiAvKiBUaGVybWFsIEhhbmxkaW5nICovCiAjaWZkZWYg Q09ORklHX1g4Nl9NQ0VfVEhFUk1BTApAQCAtMjU1LDcgKzI2Myw3IEBAIHN0YXRpYyBlbnVtIG1j ZV9yZXN1bHQgbWNlX2FjdGlvbihzdHJ1Y3QKICAgICAgICAgZm9yICggaSA9IDA7IGkgPCBoYW5k bGVyX251bTsgaSsrICkgewogICAgICAgICAgICAgaWYgKGhhbmRsZXJzW2ldLm93bmVkX2Vycm9y KGJpbmZvLm1pYi0+bWNfc3RhdHVzKSkKICAgICAgICAgICAgIHsKLSAgICAgICAgICAgICAgICBo YW5kbGVyc1tpXS5yZWNvdmVyeV9oYW5kbGVyKCZiaW5mbywgJmJhbmtfcmVzdWx0KTsKKyAgICAg ICAgICAgICAgICBoYW5kbGVyc1tpXS5yZWNvdmVyeV9oYW5kbGVyKCZiaW5mbywgJmJhbmtfcmVz dWx0LCByZWdzKTsKICAgICAgICAgICAgICAgICBpZiAod29yc3RfcmVzdWx0IDwgYmFua19yZXN1 bHQpCiAgICAgICAgICAgICAgICAgICAgIHdvcnN0X3Jlc3VsdCA9IGJhbmtfcmVzdWx0OwogICAg ICAgICAgICAgICAgIGJyZWFrOwpAQCAtNjIxLDcgKzYyOSw4IEBAIHN0cnVjdCBtY2luZm9fcmVj b3ZlcnkgKm1jaV9hZGRfcGFnZW9mZl8KIAogc3RhdGljIHZvaWQgaW50ZWxfbWVtZXJyX2RoYW5k bGVyKAogICAgICAgICAgICAgIHN0cnVjdCBtY2FfYmluZm8gKmJpbmZvLAotICAgICAgICAgICAg IGVudW0gbWNlX3Jlc3VsdCAqcmVzdWx0KQorICAgICAgICAgICAgIGVudW0gbWNlX3Jlc3VsdCAq cmVzdWx0LAorICAgICAgICAgICAgIHN0cnVjdCBjcHVfdXNlcl9yZWdzICpyZWdzKQogewogICAg IHN0cnVjdCBtY2luZm9fYmFuayAqYmFuayA9IGJpbmZvLT5taWI7CiAgICAgc3RydWN0IG1jaW5m b19nbG9iYWwgKmdsb2JhbCA9IGJpbmZvLT5taWc7CkBAIC03MTgsNiArNzI3LDMyIEBAIHZtY2Vf ZmFpbGVkOgogICAgIH0KIH0KIAorc3RhdGljIGludCBpbnRlbF9zcmFyX2NoZWNrKHVpbnQ2NF90 IHN0YXR1cykKK3sKKyAgICByZXR1cm4gKCBpbnRlbF9jaGVja19tY2VfdHlwZShzdGF0dXMpID09 IGludGVsX21jZV91Y3Jfc3JhciApOworfQorCitzdGF0aWMgdm9pZCBpbnRlbF9zcmFyX2RoYW5k bGVyKAorICAgICAgICAgICAgIHN0cnVjdCBtY2FfYmluZm8gKmJpbmZvLAorICAgICAgICAgICAg IGVudW0gbWNlX3Jlc3VsdCAqcmVzdWx0LAorICAgICAgICAgICAgIHN0cnVjdCBjcHVfdXNlcl9y ZWdzICpyZWdzKQoreworICAgIHVpbnQ2NF90IHN0YXR1cyA9IGJpbmZvLT5taWItPm1jX3N0YXR1 czsKKworICAgIC8qIEZvciB1bmtub3duIHNyYXIgZXJyb3IgY29kZSwgcmVzZXQgc3lzdGVtICov CisgICAgKnJlc3VsdCA9IE1DRVJfUkVTRVQ7CisKKyAgICBzd2l0Y2ggKCBzdGF0dXMgJiBJTlRF TF9NQ0NPRF9NQVNLICkKKyAgICB7CisgICAgY2FzZSBJTlRFTF9TUkFSX0RBVEFfTE9BRDoKKyAg ICBjYXNlIElOVEVMX1NSQVJfSU5TVFJfRkVUQ0g6CisgICAgICAgIGludGVsX21lbWVycl9kaGFu ZGxlcihiaW5mbywgcmVzdWx0LCByZWdzKTsKKyAgICAgICAgYnJlYWs7CisgICAgZGVmYXVsdDoK KyAgICAgICAgYnJlYWs7CisgICAgfQorfQorCiBzdGF0aWMgaW50IGludGVsX3NyYW9fY2hlY2so dWludDY0X3Qgc3RhdHVzKQogewogICAgIHJldHVybiAoIGludGVsX2NoZWNrX21jZV90eXBlKHN0 YXR1cykgPT0gaW50ZWxfbWNlX3Vjcl9zcmFvICk7CkBAIC03MjUsNyArNzYwLDggQEAgc3RhdGlj IGludCBpbnRlbF9zcmFvX2NoZWNrKHVpbnQ2NF90IHN0YQogCiBzdGF0aWMgdm9pZCBpbnRlbF9z cmFvX2RoYW5kbGVyKAogICAgICAgICAgICAgIHN0cnVjdCBtY2FfYmluZm8gKmJpbmZvLAotICAg ICAgICAgICAgIGVudW0gbWNlX3Jlc3VsdCAqcmVzdWx0KQorICAgICAgICAgICAgIGVudW0gbWNl X3Jlc3VsdCAqcmVzdWx0LAorICAgICAgICAgICAgIHN0cnVjdCBjcHVfdXNlcl9yZWdzICpyZWdz KQogewogICAgIHVpbnQ2NF90IHN0YXR1cyA9IGJpbmZvLT5taWItPm1jX3N0YXR1czsKIApAQCAt NzM4LDcgKzc3NCw3IEBAIHN0YXRpYyB2b2lkIGludGVsX3NyYW9fZGhhbmRsZXIoCiAgICAgICAg IHsKICAgICAgICAgY2FzZSBJTlRFTF9TUkFPX01FTV9TQ1JVQjoKICAgICAgICAgY2FzZSBJTlRF TF9TUkFPX0wzX0VXQjoKLSAgICAgICAgICAgIGludGVsX21lbWVycl9kaGFuZGxlcihiaW5mbywg cmVzdWx0KTsKKyAgICAgICAgICAgIGludGVsX21lbWVycl9kaGFuZGxlcihiaW5mbywgcmVzdWx0 LCByZWdzKTsKICAgICAgICAgICAgIGJyZWFrOwogICAgICAgICBkZWZhdWx0OgogICAgICAgICAg ICAgYnJlYWs7CkBAIC03NTMsMTQgKzc4OSwxNSBAQCBzdGF0aWMgaW50IGludGVsX2RlZmF1bHRf Y2hlY2sodWludDY0X3QgCiAKIHN0YXRpYyB2b2lkIGludGVsX2RlZmF1bHRfbWNlX2RoYW5kbGVy KAogICAgICAgICAgICAgIHN0cnVjdCBtY2FfYmluZm8gKmJpbmZvLAotICAgICAgICAgICAgIGVu dW0gbWNlX3Jlc3VsdCAqcmVzdWx0KQorICAgICAgICAgICAgIGVudW0gbWNlX3Jlc3VsdCAqcmVz dWx0LAorICAgICAgICAgICAgIHN0cnVjdCBjcHVfdXNlcl9yZWdzICogcmVncykKIHsKICAgICB1 aW50NjRfdCBzdGF0dXMgPSBiaW5mby0+bWliLT5tY19zdGF0dXM7CiAgICAgZW51bSBpbnRlbF9t Y2VfdHlwZSB0eXBlOwogCiAgICAgdHlwZSA9IGludGVsX2NoZWNrX21jZV90eXBlKHN0YXR1cyk7 CiAKLSAgICBpZiAodHlwZSA9PSBpbnRlbF9tY2VfZmF0YWwgfHwgdHlwZSA9PSBpbnRlbF9tY2Vf dWNyX3NyYXIpCisgICAgaWYgKHR5cGUgPT0gaW50ZWxfbWNlX2ZhdGFsKQogICAgICAgICAqcmVz dWx0ID0gTUNFUl9SRVNFVDsKICAgICBlbHNlCiAgICAgICAgICpyZXN1bHQgPSBNQ0VSX0NPTlRJ TlVFOwpAQCAtNzY4LDEyICs4MDUsMTQgQEAgc3RhdGljIHZvaWQgaW50ZWxfZGVmYXVsdF9tY2Vf ZGhhbmRsZXIoCiAKIHN0YXRpYyBjb25zdCBzdHJ1Y3QgbWNhX2Vycm9yX2hhbmRsZXIgaW50ZWxf bWNlX2RoYW5kbGVyc1tdID0gewogICAgIHtpbnRlbF9zcmFvX2NoZWNrLCBpbnRlbF9zcmFvX2Ro YW5kbGVyfSwKKyAgICB7aW50ZWxfc3Jhcl9jaGVjaywgaW50ZWxfc3Jhcl9kaGFuZGxlcn0sCiAg ICAge2ludGVsX2RlZmF1bHRfY2hlY2ssIGludGVsX2RlZmF1bHRfbWNlX2RoYW5kbGVyfQogfTsK IAogc3RhdGljIHZvaWQgaW50ZWxfZGVmYXVsdF9tY2VfdWhhbmRsZXIoCiAgICAgICAgICAgICAg c3RydWN0IG1jYV9iaW5mbyAqYmluZm8sCi0gICAgICAgICAgICAgZW51bSBtY2VfcmVzdWx0ICpy ZXN1bHQpCisgICAgICAgICAgICAgZW51bSBtY2VfcmVzdWx0ICpyZXN1bHQsCisgICAgICAgICAg ICAgc3RydWN0IGNwdV91c2VyX3JlZ3MgKnJlZ3MpCiB7CiAgICAgdWludDY0X3Qgc3RhdHVzID0g YmluZm8tPm1pYi0+bWNfc3RhdHVzOwogICAgIGVudW0gaW50ZWxfbWNlX3R5cGUgdHlwZTsKQEAg LTc4Miw4ICs4MjEsMTIgQEAgc3RhdGljIHZvaWQgaW50ZWxfZGVmYXVsdF9tY2VfdWhhbmRsZXIo CiAKICAgICBzd2l0Y2ggKHR5cGUpCiAgICAgewotICAgIC8qIFBhbmljIGlmIG5vIGhhbmRsZXIg Zm9yIFNSQVIgZXJyb3IgKi8KICAgICBjYXNlIGludGVsX21jZV91Y3Jfc3JhcjoKKyAgICAgICAg aWYgKCAhZ3Vlc3RfbW9kZShyZWdzKSApCisgICAgICAgICAgICAqcmVzdWx0ID0gTUNFUl9SRVNF VDsKKyAgICAgICAgZWxzZQorICAgICAgICAgICAgKnJlc3VsdCA9IE1DRVJfQ09OVElOVUU7Cisg ICAgICAgIGJyZWFrOwogICAgIGNhc2UgaW50ZWxfbWNlX2ZhdGFsOgogICAgICAgICAqcmVzdWx0 ID0gTUNFUl9SRVNFVDsKICAgICAgICAgYnJlYWs7CkBAIC05NTgsMTAgKzEwMDEsOCBAQCBzdGF0 aWMgaW50IGludGVsX3JlY292ZXJhYmxlX3NjYW4odTY0IHN0CiAgICAgLyogU1JBUiBlcnJvciAq LwogICAgIGVsc2UgaWYgKCBzZXJfc3VwcG9ydCAmJiAhKHN0YXR1cyAmIE1DaV9TVEFUVVNfT1ZF UikgCiAgICAgICAgICAgICAgICAgJiYgIShzdGF0dXMgJiBNQ2lfU1RBVFVTX1BDQykgJiYgKHN0 YXR1cyAmIE1DaV9TVEFUVVNfUykKLSAgICAgICAgICAgICAgICAmJiAoc3RhdHVzICYgTUNpX1NU QVRVU19BUikgKSB7Ci0gICAgICAgIG1jZV9wcmludGsoTUNFX1ZFUkJPU0UsICJNQ0U6IE5vIFNS QVIgZXJyb3IgZGVmaW5lZCBjdXJyZW50bHkuXG4iKTsKLSAgICAgICAgcmV0dXJuIDA7Ci0gICAg fQorICAgICAgICAgICAgICAgICYmIChzdGF0dXMgJiBNQ2lfU1RBVFVTX0FSKSAmJiAoc3RhdHVz ICYgTUNpX1NUQVRVU19FTikgKQorICAgICAgICByZXR1cm4gMTsKICAgICAvKiBTUkFPIGVycm9y ICovCiAgICAgZWxzZSBpZiAoc2VyX3N1cHBvcnQgJiYgIShzdGF0dXMgJiBNQ2lfU1RBVFVTX1BD QykKICAgICAgICAgICAgICAgICAmJiAoc3RhdHVzICYgTUNpX1NUQVRVU19TKSAmJiAhKHN0YXR1 cyAmIE1DaV9TVEFUVVNfQVIpCmRpZmYgLXIgOGQ2ZWRjM2QyNmQyIHhlbi9hcmNoL3g4Ni9jcHUv bWNoZWNrL3g4Nl9tY2EuaAotLS0gYS94ZW4vYXJjaC94ODYvY3B1L21jaGVjay94ODZfbWNhLmgJ U2F0IEF1ZyAxMyAxMDoxNDo1OCAyMDExICswMTAwCisrKyBiL3hlbi9hcmNoL3g4Ni9jcHUvbWNo ZWNrL3g4Nl9tY2EuaAlTYXQgQXVnIDIwIDIzOjUzOjAyIDIwMTEgKzA4MDAKQEAgLTE1MSw3ICsx NTEsNyBAQCBzdHJ1Y3QgbWNhX2Vycm9yX2hhbmRsZXIKICAgICAqLwogICAgIGludCAoKm93bmVk X2Vycm9yKSh1aW50NjRfdCBzdGF0dXMpOwogICAgIHZvaWQgKCpyZWNvdmVyeV9oYW5kbGVyKShz dHJ1Y3QgbWNhX2JpbmZvICpiaW5mbywKLSAgICAgICAgICAgICAgICAgICAgZW51bSBtY2VfcmVz dWx0ICpyZXN1bHQpOworICAgICAgICAgICAgICAgICAgICBlbnVtIG1jZV9yZXN1bHQgKnJlc3Vs dCwgc3RydWN0IGNwdV91c2VyX3JlZ3MgKnJlZ3MpOwogfTsKIAogLyogR2xvYmFsIHZhcmlhYmxl cyAqLwo= --_002_BC00F5384FCFC9499AF06F92E8B78A9E263B557B77shsmsx502ccrc_ Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel --_002_BC00F5384FCFC9499AF06F92E8B78A9E263B557B77shsmsx502ccrc_-- From xen-devel-bounces@lists.xensource.com Thu Sep 29 08:25:14 2011 Return-path: <xen-devel-bounces@lists.xensource.com> Envelope-to: www-data@lists.xensource.com Delivery-date: Thu, 29 Sep 2011 08:25:14 -0700 Received: from localhost ([127.0.0.1] helo=lists.colo.xensource.com) by lists.xensource.com with esmtp (Exim 4.43) id 1R9IU6-0003m8-Ox; Thu, 29 Sep 2011 08:25:14 -0700 Received: from mail27.messagelabs.com ([193.109.254.147]) by lists.xensource.com with smtp (Exim 4.43) id 1R9ITR-0003Zl-Ns for xen-devel@lists.xensource.com; Thu, 29 Sep 2011 08:24:34 -0700 X-Env-Sender: jinsong.liu@intel.com X-Msg-Ref: server-2.tower-27.messagelabs.com!1317309843!57000801!1 X-Originating-IP: [192.55.52.88] X-StarScan-Version: 6.4.1; banners=-,-,- X-VirusChecked: Checked Received: (qmail 28322 invoked from network); 29 Sep 2011 15:24:03 -0000 Received: from mga01.intel.com (HELO mga01.intel.com) (192.55.52.88) by server-2.tower-27.messagelabs.com with SMTP; 29 Sep 2011 15:24:03 -0000 Received: from fmsmga002.fm.intel.com ([10.253.24.26]) by fmsmga101.fm.intel.com with ESMTP; 29 Sep 2011 08:24:29 -0700 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="4.68,461,1312182000"; d="scan'208";a="72132509" Received: from pgsmsx602.gar.corp.intel.com ([10.221.43.81]) by fmsmga002.fm.intel.com with ESMTP; 29 Sep 2011 08:24:22 -0700 Received: from pgsmsx151.gar.corp.intel.com (172.30.236.41) by pgsmsx602.gar.corp.intel.com (10.221.43.81) with Microsoft SMTP Server (TLS) id 8.2.255.0; Thu, 29 Sep 2011 23:22:03 +0800 Received: from shsmsx601.ccr.corp.intel.com (10.239.4.112) by PGSMSX151.gar.corp.intel.com (172.30.236.41) with Microsoft SMTP Server (TLS) id 14.1.323.3; Thu, 29 Sep 2011 23:22:02 +0800 Received: from shsmsx502.ccr.corp.intel.com ([10.239.4.96]) by shsmsx601.ccr.corp.intel.com ([10.239.4.112]) with mapi; Thu, 29 Sep 2011 23:22:01 +0800 From: "Liu, Jinsong" <jinsong.liu@intel.com> To: Keir Fraser <keir.xen@gmail.com>, "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com> Date: Thu, 29 Sep 2011 23:22:00 +0800 Thread-Topic: [PATCH] X86 MCE: Prevent malicious guest access broken page again Thread-Index: Acx+u4i3DTnHPNCrTHGpE8IgVH6K2w== Message-ID: <BC00F5384FCFC9499AF06F92E8B78A9E263B557B79@shsmsx502.ccr.corp.intel.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: multipart/mixed; boundary="_002_BC00F5384FCFC9499AF06F92E8B78A9E263B557B79shsmsx502ccrc_" MIME-Version: 1.0 Cc: "Jiang, Yunhong" <yunhong.jiang@intel.com> Subject: [Xen-devel] [PATCH] X86 MCE: Prevent malicious guest access broken page again X-BeenThere: xen-devel@lists.xensource.com X-Mailman-Version: 2.1.5 Precedence: list List-Id: Xen developer discussion <xen-devel.lists.xensource.com> List-Unsubscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe> List-Post: <mailto:xen-devel@lists.xensource.com> List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help> List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=subscribe> Sender: xen-devel-bounces@lists.xensource.com Errors-To: xen-devel-bounces@lists.xensource.com --_002_BC00F5384FCFC9499AF06F92E8B78A9E263B557B79shsmsx502ccrc_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable X86 MCE: Prevent malicious guest access broken page again To avoid recursive mce. Signed-off-by: Liu, Jinsong <jinsong.liu@intel.com> diff -r 753cbb4f4416 xen/arch/x86/cpu/mcheck/mce_intel.c --- a/xen/arch/x86/cpu/mcheck/mce_intel.c Sat Aug 20 23:53:03 2011 +0800 +++ b/xen/arch/x86/cpu/mcheck/mce_intel.c Sun Aug 21 00:45:44 2011 +0800 @@ -665,6 +665,8 @@ static void intel_memerr_dhandler( /* This is free page */ if (status & PG_OFFLINE_OFFLINED) *result =3D MCER_RECOVERED; + else if (status & PG_OFFLINE_AGAIN) + *result =3D MCER_CONTINUE; else if (status & PG_OFFLINE_PENDING) { /* This page has owner */ if (status & PG_OFFLINE_OWNED) { diff -r 753cbb4f4416 xen/common/page_alloc.c --- a/xen/common/page_alloc.c Sat Aug 20 23:53:03 2011 +0800 +++ b/xen/common/page_alloc.c Sun Aug 21 00:45:44 2011 +0800 @@ -38,6 +38,7 @@ #include <xen/tmem.h> #include <xen/tmem_xen.h> #include <public/sysctl.h> +#include <public/sched.h> #include <asm/page.h> #include <asm/numa.h> #include <asm/flushtlb.h> @@ -708,6 +709,19 @@ int offline_page(unsigned long mfn, int=20 return -EINVAL; } =20 + /* + * NB. When broken page belong to guest, usually hypervisor will + * notify the guest to handle the broken page. However, hypervisor + * need to prevent malicious guest access the broken page again. + * Under such case, hypervisor shutdown guest, preventing recursive mc= e. + */ + if ( (pg->count_info & PGC_broken) && (owner =3D page_get_owner(pg)) ) + { + *status =3D PG_OFFLINE_AGAIN; + domain_shutdown(owner, SHUTDOWN_crash); + return 0; + } + spin_lock(&heap_lock); =20 old_info =3D mark_page_offline(pg, broken); diff -r 753cbb4f4416 xen/include/public/sysctl.h --- a/xen/include/public/sysctl.h Sat Aug 20 23:53:03 2011 +0800 +++ b/xen/include/public/sysctl.h Sun Aug 21 00:45:44 2011 +0800 @@ -399,6 +399,7 @@ struct xen_sysctl_page_offline_op { #define PG_OFFLINE_OFFLINED (0x1UL << 1) #define PG_OFFLINE_PENDING (0x1UL << 2) #define PG_OFFLINE_FAILED (0x1UL << 3) +#define PG_OFFLINE_AGAIN (0x1UL << 4) =20 #define PG_ONLINE_FAILED PG_OFFLINE_FAILED #define PG_ONLINE_ONLINED PG_OFFLINE_OFFLINED= --_002_BC00F5384FCFC9499AF06F92E8B78A9E263B557B79shsmsx502ccrc_ Content-Type: application/octet-stream; name="srar-2.patch" Content-Description: srar-2.patch Content-Disposition: attachment; filename="srar-2.patch"; size=2240; creation-date="Thu, 29 Sep 2011 23:17:18 GMT"; modification-date="Fri, 30 Sep 2011 07:18:56 GMT" Content-Transfer-Encoding: base64 WDg2IE1DRTogUHJldmVudCBtYWxpY2lvdXMgZ3Vlc3QgYWNjZXNzIGJyb2tlbiBwYWdlIGFnYWlu CgpUbyBhdm9pZCByZWN1cnNpdmUgbWNlLgoKU2lnbmVkLW9mZi1ieTogTGl1LCBKaW5zb25nIDxq aW5zb25nLmxpdUBpbnRlbC5jb20+CgpkaWZmIC1yIDc1M2NiYjRmNDQxNiB4ZW4vYXJjaC94ODYv Y3B1L21jaGVjay9tY2VfaW50ZWwuYwotLS0gYS94ZW4vYXJjaC94ODYvY3B1L21jaGVjay9tY2Vf aW50ZWwuYwlTYXQgQXVnIDIwIDIzOjUzOjAzIDIwMTEgKzA4MDAKKysrIGIveGVuL2FyY2gveDg2 L2NwdS9tY2hlY2svbWNlX2ludGVsLmMJU3VuIEF1ZyAyMSAwMDo0NTo0NCAyMDExICswODAwCkBA IC02NjUsNiArNjY1LDggQEAgc3RhdGljIHZvaWQgaW50ZWxfbWVtZXJyX2RoYW5kbGVyKAogICAg IC8qIFRoaXMgaXMgZnJlZSBwYWdlICovCiAgICAgaWYgKHN0YXR1cyAmIFBHX09GRkxJTkVfT0ZG TElORUQpCiAgICAgICAgICpyZXN1bHQgPSBNQ0VSX1JFQ09WRVJFRDsKKyAgICBlbHNlIGlmIChz dGF0dXMgJiBQR19PRkZMSU5FX0FHQUlOKQorICAgICAgICAqcmVzdWx0ID0gTUNFUl9DT05USU5V RTsKICAgICBlbHNlIGlmIChzdGF0dXMgJiBQR19PRkZMSU5FX1BFTkRJTkcpIHsKICAgICAgICAg LyogVGhpcyBwYWdlIGhhcyBvd25lciAqLwogICAgICAgICBpZiAoc3RhdHVzICYgUEdfT0ZGTElO RV9PV05FRCkgewpkaWZmIC1yIDc1M2NiYjRmNDQxNiB4ZW4vY29tbW9uL3BhZ2VfYWxsb2MuYwot LS0gYS94ZW4vY29tbW9uL3BhZ2VfYWxsb2MuYwlTYXQgQXVnIDIwIDIzOjUzOjAzIDIwMTEgKzA4 MDAKKysrIGIveGVuL2NvbW1vbi9wYWdlX2FsbG9jLmMJU3VuIEF1ZyAyMSAwMDo0NTo0NCAyMDEx ICswODAwCkBAIC0zOCw2ICszOCw3IEBACiAjaW5jbHVkZSA8eGVuL3RtZW0uaD4KICNpbmNsdWRl IDx4ZW4vdG1lbV94ZW4uaD4KICNpbmNsdWRlIDxwdWJsaWMvc3lzY3RsLmg+CisjaW5jbHVkZSA8 cHVibGljL3NjaGVkLmg+CiAjaW5jbHVkZSA8YXNtL3BhZ2UuaD4KICNpbmNsdWRlIDxhc20vbnVt YS5oPgogI2luY2x1ZGUgPGFzbS9mbHVzaHRsYi5oPgpAQCAtNzA4LDYgKzcwOSwxOSBAQCBpbnQg b2ZmbGluZV9wYWdlKHVuc2lnbmVkIGxvbmcgbWZuLCBpbnQgCiAgICAgICAgIHJldHVybiAtRUlO VkFMOwogICAgIH0KIAorICAgIC8qCisgICAgICogTkIuIFdoZW4gYnJva2VuIHBhZ2UgYmVsb25n IHRvIGd1ZXN0LCB1c3VhbGx5IGh5cGVydmlzb3Igd2lsbAorICAgICAqIG5vdGlmeSB0aGUgZ3Vl c3QgdG8gaGFuZGxlIHRoZSBicm9rZW4gcGFnZS4gSG93ZXZlciwgaHlwZXJ2aXNvcgorICAgICAq IG5lZWQgdG8gcHJldmVudCBtYWxpY2lvdXMgZ3Vlc3QgYWNjZXNzIHRoZSBicm9rZW4gcGFnZSBh Z2Fpbi4KKyAgICAgKiBVbmRlciBzdWNoIGNhc2UsIGh5cGVydmlzb3Igc2h1dGRvd24gZ3Vlc3Qs IHByZXZlbnRpbmcgcmVjdXJzaXZlIG1jZS4KKyAgICAgKi8KKyAgICBpZiAoIChwZy0+Y291bnRf aW5mbyAmIFBHQ19icm9rZW4pICYmIChvd25lciA9IHBhZ2VfZ2V0X293bmVyKHBnKSkgKQorICAg IHsKKyAgICAgICAgKnN0YXR1cyA9IFBHX09GRkxJTkVfQUdBSU47CisgICAgICAgIGRvbWFpbl9z aHV0ZG93bihvd25lciwgU0hVVERPV05fY3Jhc2gpOworICAgICAgICByZXR1cm4gMDsKKyAgICB9 CisKICAgICBzcGluX2xvY2soJmhlYXBfbG9jayk7CiAKICAgICBvbGRfaW5mbyA9IG1hcmtfcGFn ZV9vZmZsaW5lKHBnLCBicm9rZW4pOwpkaWZmIC1yIDc1M2NiYjRmNDQxNiB4ZW4vaW5jbHVkZS9w dWJsaWMvc3lzY3RsLmgKLS0tIGEveGVuL2luY2x1ZGUvcHVibGljL3N5c2N0bC5oCVNhdCBBdWcg MjAgMjM6NTM6MDMgMjAxMSArMDgwMAorKysgYi94ZW4vaW5jbHVkZS9wdWJsaWMvc3lzY3RsLmgJ U3VuIEF1ZyAyMSAwMDo0NTo0NCAyMDExICswODAwCkBAIC0zOTksNiArMzk5LDcgQEAgc3RydWN0 IHhlbl9zeXNjdGxfcGFnZV9vZmZsaW5lX29wIHsKICNkZWZpbmUgUEdfT0ZGTElORV9PRkZMSU5F RCAgKDB4MVVMIDw8IDEpCiAjZGVmaW5lIFBHX09GRkxJTkVfUEVORElORyAgICgweDFVTCA8PCAy KQogI2RlZmluZSBQR19PRkZMSU5FX0ZBSUxFRCAgICAoMHgxVUwgPDwgMykKKyNkZWZpbmUgUEdf T0ZGTElORV9BR0FJTiAgICAgKDB4MVVMIDw8IDQpCiAKICNkZWZpbmUgUEdfT05MSU5FX0ZBSUxF RCAgICAgUEdfT0ZGTElORV9GQUlMRUQKICNkZWZpbmUgUEdfT05MSU5FX09OTElORUQgICAgUEdf T0ZGTElORV9PRkZMSU5FRAo= --_002_BC00F5384FCFC9499AF06F92E8B78A9E263B557B79shsmsx502ccrc_ Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel --_002_BC00F5384FCFC9499AF06F92E8B78A9E263B557B79shsmsx502ccrc_-- From xen-devel-bounces@lists.xensource.com Thu Sep 29 08:39:30 2011 Return-path: <xen-devel-bounces@lists.xensource.com> Envelope-to: www-data@lists.xensource.com Delivery-date: Thu, 29 Sep 2011 08:39:30 -0700 Received: from localhost ([127.0.0.1] helo=lists.colo.xensource.com) by lists.xensource.com with esmtp (Exim 4.43) id 1R9Iht-0004aT-Mc; Thu, 29 Sep 2011 08:39:30 -0700 Received: from mail174.messagelabs.com ([85.158.138.51]) by lists.xensource.com with esmtp (Exim 4.43) id 1R9IhE-0004NB-1t for xen-devel@lists.xensource.com; Thu, 29 Sep 2011 08:38:48 -0700 X-Env-Sender: Ian.Jackson@eu.citrix.com X-Msg-Ref: server-5.tower-174.messagelabs.com!1317310724!29565497!1 X-Originating-IP: [62.200.22.115] X-StarScan-Version: 6.4.1; banners=-,-,- X-VirusChecked: Checked Received: (qmail 18583 invoked from network); 29 Sep 2011 15:38:45 -0000 Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115) by server-5.tower-174.messagelabs.com with RC4-SHA encrypted SMTP; 29 Sep 2011 15:38:45 -0000 X-IronPort-AV: E=Sophos;i="4.68,461,1312156800"; d="scan'208";a="8134033" Received: from lonpmailmx01.citrite.net ([10.30.203.162]) by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5; 29 Sep 2011 15:38:44 +0000 Received: from norwich.cam.xci-test.com (10.80.248.129) by smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id 8.3.137.0; Thu, 29 Sep 2011 16:38:44 +0100 Received: from mariner.cam.xci-test.com ([10.80.2.22] helo=mariner.uk.xensource.com ident=Debian-exim) by norwich.cam.xci-test.com with esmtp (Exim 4.72) (envelope-from <Ian.Jackson@eu.citrix.com>) id 1R9IhA-0008Ul-6d; Thu, 29 Sep 2011 15:38:44 +0000 Received: from iwj by mariner.uk.xensource.com with local (Exim 4.69) (envelope-from <Ian.Jackson@eu.citrix.com>) id 1R9IhA-00028W-5b; Thu, 29 Sep 2011 16:38:44 +0100 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Message-ID: <20100.37124.165585.577243@mariner.uk.xensource.com> Date: Thu, 29 Sep 2011 16:38:44 +0100 To: Anthony PERARD <anthony.perard@citrix.com> Subject: Re: [Xen-devel] [PATCH V9 0/7] Introduce a QMP client Newsgroups: chiark.mail.xen.devel In-Reply-To: <1317296277-2838-1-git-send-email-anthony.perard@citrix.com> References: <1317296277-2838-1-git-send-email-anthony.perard@citrix.com> X-Mailer: VM 8.0.9 under Emacs 21.4.1 (i486-pc-linux-gnu) From: Ian Jackson <Ian.Jackson@eu.citrix.com> Cc: Ian Campbell <Ian.Campbell@eu.citrix.com>, Xen Devel <xen-devel@lists.xensource.com>, Stefano Stabellini <stefano.stabellini@eu.citrix.com> X-BeenThere: xen-devel@lists.xensource.com X-Mailman-Version: 2.1.5 Precedence: list List-Id: Xen developer discussion <xen-devel.lists.xensource.com> List-Unsubscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe> List-Post: <mailto:xen-devel@lists.xensource.com> List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help> List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=subscribe> Sender: xen-devel-bounces@lists.xensource.com Errors-To: xen-devel-bounces@lists.xensource.com Anthony PERARD writes ("[Xen-devel] [PATCH V9 0/7] Introduce a QMP client"): > Only the last patch have changed on this series since the v8. > Replace of SOCK_NONBLOCK by a call to fcntl in qmp_open(). > The rest of the patch have been acked-by Ian Campbell. Thanks, I have applied this whole series. Ian. _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel From xen-devel-bounces@lists.xensource.com Thu Sep 29 08:40:28 2011 Return-path: <xen-devel-bounces@lists.xensource.com> Envelope-to: www-data@lists.xensource.com Delivery-date: Thu, 29 Sep 2011 08:40:28 -0700 Received: from localhost ([127.0.0.1] helo=lists.colo.xensource.com) by lists.xensource.com with esmtp (Exim 4.43) id 1R9Iiq-0004xr-2V; Thu, 29 Sep 2011 08:40:28 -0700 Received: from mail27.messagelabs.com ([193.109.254.147]) by lists.xensource.com with esmtp (Exim 4.43) id 1R9IhM-0004OS-PB for xen-devel@lists.xensource.com; Thu, 29 Sep 2011 08:38:57 -0700 X-Env-Sender: Ian.Jackson@eu.citrix.com X-Msg-Ref: server-12.tower-27.messagelabs.com!1317310717!44479333!1 X-Originating-IP: [62.200.22.115] X-StarScan-Version: 6.4.1; banners=-,-,- X-VirusChecked: Checked Received: (qmail 8140 invoked from network); 29 Sep 2011 15:38:37 -0000 Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115) by server-12.tower-27.messagelabs.com with RC4-SHA encrypted SMTP; 29 Sep 2011 15:38:37 -0000 X-IronPort-AV: E=Sophos;i="4.68,461,1312156800"; d="scan'208";a="8134037" Received: from lonpmailmx01.citrite.net ([10.30.203.162]) by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5; 29 Sep 2011 15:38:53 +0000 Received: from norwich.cam.xci-test.com (10.80.248.129) by smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id 8.3.137.0; Thu, 29 Sep 2011 16:38:53 +0100 Received: from mariner.cam.xci-test.com ([10.80.2.22] helo=mariner.uk.xensource.com ident=Debian-exim) by norwich.cam.xci-test.com with esmtp (Exim 4.72) (envelope-from <Ian.Jackson@eu.citrix.com>) id 1R9IhJ-0008Uq-7A; Thu, 29 Sep 2011 15:38:53 +0000 Received: from iwj by mariner.uk.xensource.com with local (Exim 4.69) (envelope-from <Ian.Jackson@eu.citrix.com>) id 1R9IhJ-00028g-6M; Thu, 29 Sep 2011 16:38:53 +0100 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Message-ID: <20100.37133.189404.935154@mariner.uk.xensource.com> Date: Thu, 29 Sep 2011 16:38:53 +0100 To: Anthony PERARD <anthony.perard@citrix.com> Subject: Re: [Xen-devel] [PATCH 2/2] libxl_qmp: use of libxl__fd_set_cloexec. Newsgroups: chiark.mail.xen.devel In-Reply-To: <1317306650-24028-2-git-send-email-anthony.perard@citrix.com> References: <1317306650-24028-1-git-send-email-anthony.perard@citrix.com> <1317306650-24028-2-git-send-email-anthony.perard@citrix.com> X-Mailer: VM 8.0.9 under Emacs 21.4.1 (i486-pc-linux-gnu) From: Ian Jackson <Ian.Jackson@eu.citrix.com> Cc: Ian Campbell <Ian.Campbell@eu.citrix.com>, Xen Devel <xen-devel@lists.xensource.com>, Stefano Stabellini <stefano.stabellini@eu.citrix.com> X-BeenThere: xen-devel@lists.xensource.com X-Mailman-Version: 2.1.5 Precedence: list List-Id: Xen developer discussion <xen-devel.lists.xensource.com> List-Unsubscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe> List-Post: <mailto:xen-devel@lists.xensource.com> List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help> List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=subscribe> Sender: xen-devel-bounces@lists.xensource.com Errors-To: xen-devel-bounces@lists.xensource.com Anthony PERARD writes ("[Xen-devel] [PATCH 2/2] libxl_qmp: use of libxl__fd_set_cloexec."): > Signed-off-by: Anthony PERARD <anthony.perard@citrix.com> Acked-by: Ian Jackson <ian.jackson@eu.citrix.com> Committed-by: Ian Jackson <ian.jackson@eu.citrix.com> _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel From xen-devel-bounces@lists.xensource.com Thu Sep 29 08:42:48 2011 Return-path: <xen-devel-bounces@lists.xensource.com> Envelope-to: www-data@lists.xensource.com Delivery-date: Thu, 29 Sep 2011 08:42:48 -0700 Received: from localhost ([127.0.0.1] helo=lists.colo.xensource.com) by lists.xensource.com with esmtp (Exim 4.43) id 1R9Il6-0005RX-7V; Thu, 29 Sep 2011 08:42:48 -0700 Received: from mail27.messagelabs.com ([193.109.254.147]) by lists.xensource.com with esmtp (Exim 4.43) id 1R9Ike-0005Fu-5l for xen-devel@lists.xensource.com; Thu, 29 Sep 2011 08:42:20 -0700 X-Env-Sender: JBeulich@suse.com X-Msg-Ref: server-10.tower-27.messagelabs.com!1317310915!37765141!1 X-Originating-IP: [130.57.49.28] X-StarScan-Version: 6.4.1; banners=-,-,- X-VirusChecked: Checked Received: (qmail 12594 invoked from network); 29 Sep 2011 15:41:55 -0000 Received: from nat28.tlf.novell.com (HELO nat28.tlf.novell.com) (130.57.49.28) by server-10.tower-27.messagelabs.com with DHE-RSA-AES256-SHA encrypted SMTP; 29 Sep 2011 15:41:55 -0000 Received: from EMEA1-MTA by nat28.tlf.novell.com with Novell_GroupWise; Thu, 29 Sep 2011 16:42:16 +0100 Message-Id: <4E84ADF70200007800058882@nat28.tlf.novell.com> X-Mailer: Novell GroupWise Internet Agent 8.0.1 Date: Thu, 29 Sep 2011 16:42:15 +0100 From: "Jan Beulich" <JBeulich@suse.com> To: "Jinsong Liu" <jinsong.liu@intel.com> Subject: Re: [Xen-devel] [PATCH] X86 MCE: Add SRAR handler References: <BC00F5384FCFC9499AF06F92E8B78A9E263B557B77@shsmsx502.ccr.corp.intel.com> In-Reply-To: <BC00F5384FCFC9499AF06F92E8B78A9E263B557B77@shsmsx502.ccr.corp.intel.com> Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: quoted-printable Content-Disposition: inline Cc: Keir Fraser <keir.xen@gmail.com>, "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>, Yunhong Jiang <yunhong.jiang@intel.com> X-BeenThere: xen-devel@lists.xensource.com X-Mailman-Version: 2.1.5 Precedence: list List-Id: Xen developer discussion <xen-devel.lists.xensource.com> List-Unsubscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe> List-Post: <mailto:xen-devel@lists.xensource.com> List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help> List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=subscribe> Sender: xen-devel-bounces@lists.xensource.com Errors-To: xen-devel-bounces@lists.xensource.com >>> On 29.09.11 at 17:20, "Liu, Jinsong" <jinsong.liu@intel.com> wrote: > @@ -782,8 +821,12 @@ static void intel_default_mce_uhandler( > =20 > switch (type) > { > - /* Panic if no handler for SRAR error */ > case intel_mce_ucr_srar: > + if ( !guest_mode(regs) ) > + *result =3D MCER_RESET; > + else > + *result =3D MCER_CONTINUE; > + break; > case intel_mce_fatal: > *result =3D MCER_RESET; > break; Using the stack based registers for any decision in an MCE handler seems bogus to me - without knowing that the error occurred synchronously, the result is meaningless. Unfortunately I wasn't able to spot - throughout your patch - what SRAR actually stands for, and the manual is no help in that respect either. It does state, however, that EIPV in three of four cases would be clear for these, so using the registers on stack is likely wrong here. This made me look at the current source, and there I see in mce_urgent_action() if ( !(gstatus & MCG_STATUS_RIPV) && !guest_mode(regs)) return -1; which I think should say ... _EIPV and use || instead. Thoughts? Jan _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel From xen-devel-bounces@lists.xensource.com Thu Sep 29 08:53:52 2011 Return-path: <xen-devel-bounces@lists.xensource.com> Envelope-to: www-data@lists.xensource.com Delivery-date: Thu, 29 Sep 2011 08:53:52 -0700 Received: from localhost ([127.0.0.1] helo=lists.colo.xensource.com) by lists.xensource.com with esmtp (Exim 4.43) id 1R9Ivo-0005xs-DU; Thu, 29 Sep 2011 08:53:52 -0700 Received: from mail174.messagelabs.com ([85.158.138.51]) by lists.xensource.com with esmtp (Exim 4.43) id 1R9IvC-0005lr-VH for xen-devel@lists.xensource.com; Thu, 29 Sep 2011 08:53:15 -0700 X-Env-Sender: david.vrabel@citrix.com X-Msg-Ref: server-13.tower-174.messagelabs.com!1317311590!33281524!1 X-Originating-IP: [66.165.176.63] X-StarScan-Version: 6.4.1; banners=-,-,- X-VirusChecked: Checked Received: (qmail 6947 invoked from network); 29 Sep 2011 15:53:11 -0000 Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63) by server-13.tower-174.messagelabs.com with RC4-SHA encrypted SMTP; 29 Sep 2011 15:53:11 -0000 X-IronPort-AV: E=Sophos;i="4.68,461,1312171200"; d="scan'208";a="165156342" Received: from ftlpmailmx01.citrite.net ([10.13.107.65]) by FTLPIPO02.CITRIX.COM with ESMTP/TLS/RC4-MD5; 29 Sep 2011 11:53:09 -0400 Received: from smtp01.ad.xensource.com (10.219.128.104) by smtprelay.citrix.com (10.13.107.65) with Microsoft SMTP Server id 8.3.137.0; Thu, 29 Sep 2011 11:53:08 -0400 Received: from qabil.uk.xensource.com (qabil.uk.xensource.com [10.80.2.76]) by smtp01.ad.xensource.com (8.13.1/8.13.1) with ESMTP id p8TFr79F026128; Thu, 29 Sep 2011 08:53:07 -0700 From: David Vrabel <david.vrabel@citrix.com> To: xen-devel@lists.xensource.com Date: Thu, 29 Sep 2011 16:53:28 +0100 Message-ID: <1317311612-15220-1-git-send-email-david.vrabel@citrix.com> X-Mailer: git-send-email 1.7.2.5 MIME-Version: 1.0 Content-Type: text/plain Cc: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com> Subject: [Xen-devel] [PATCH 0/4] xen: map foreign pages for shared rings by updating the PTEs directly X-BeenThere: xen-devel@lists.xensource.com X-Mailman-Version: 2.1.5 Precedence: list List-Id: Xen developer discussion <xen-devel.lists.xensource.com> List-Unsubscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe> List-Post: <mailto:xen-devel@lists.xensource.com> List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help> List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=subscribe> Sender: xen-devel-bounces@lists.xensource.com Errors-To: xen-devel-bounces@lists.xensource.com [Resend as requested by Konrad.] This series of patches allows the vmalloc_sync_all() to be removed from alloc_vm_area() by getting the hypervisor to update the PTEs (in init_mm) directly rather than having the hypervisor look in the current page tables to find the PTEs. Once the hypervisor has updated the PTEs, the normal mechanism of syncing the page tables after a fault works as expected. This mechanism doesn't currently work on the ia64 port as that does not support the GNTMAP_contains_pte flag. David _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel From xen-devel-bounces@lists.xensource.com Thu Sep 29 08:54:53 2011 Return-path: <xen-devel-bounces@lists.xensource.com> Envelope-to: www-data@lists.xensource.com Delivery-date: Thu, 29 Sep 2011 08:54:53 -0700 Received: from localhost ([127.0.0.1] helo=lists.colo.xensource.com) by lists.xensource.com with esmtp (Exim 4.43) id 1R9Iwn-0006L6-H6; Thu, 29 Sep 2011 08:54:53 -0700 Received: from mail27.messagelabs.com ([193.109.254.147]) by lists.xensource.com with esmtp (Exim 4.43) id 1R9IvL-0005nh-Ez for xen-devel@lists.xensource.com; Thu, 29 Sep 2011 08:53:24 -0700 X-Env-Sender: david.vrabel@citrix.com X-Msg-Ref: server-14.tower-27.messagelabs.com!1317311487!38162252!1 X-Originating-IP: [66.165.176.63] X-StarScan-Version: 6.4.1; banners=-,-,- X-VirusChecked: Checked Received: (qmail 1440 invoked from network); 29 Sep 2011 15:51:28 -0000 Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63) by server-14.tower-27.messagelabs.com with RC4-SHA encrypted SMTP; 29 Sep 2011 15:51:28 -0000 X-IronPort-AV: E=Sophos;i="4.68,461,1312171200"; d="scan'208";a="165156367" Received: from ftlpmailmx01.citrite.net ([10.13.107.65]) by FTLPIPO02.CITRIX.COM with ESMTP/TLS/RC4-MD5; 29 Sep 2011 11:53:18 -0400 Received: from smtp01.ad.xensource.com (10.219.128.104) by smtprelay.citrix.com (10.13.107.65) with Microsoft SMTP Server id 8.3.137.0; Thu, 29 Sep 2011 11:53:18 -0400 Received: from qabil.uk.xensource.com (qabil.uk.xensource.com [10.80.2.76]) by smtp01.ad.xensource.com (8.13.1/8.13.1) with ESMTP id p8TFr79G026128; Thu, 29 Sep 2011 08:53:17 -0700 From: David Vrabel <david.vrabel@citrix.com> To: xen-devel@lists.xensource.com Date: Thu, 29 Sep 2011 16:53:29 +0100 Message-ID: <1317311612-15220-2-git-send-email-david.vrabel@citrix.com> X-Mailer: git-send-email 1.7.2.5 In-Reply-To: <1317311612-15220-1-git-send-email-david.vrabel@citrix.com> References: <1317311612-15220-1-git-send-email-david.vrabel@citrix.com> MIME-Version: 1.0 Content-Type: text/plain Cc: David Vrabel <david.vrabel@citrix.com>, Konrad Rzeszutek Wilk <konrad.wilk@oracle.com> Subject: [Xen-devel] [PATCH 1/4] xen: use generic functions instead of xen_{alloc, free}_vm_area() X-BeenThere: xen-devel@lists.xensource.com X-Mailman-Version: 2.1.5 Precedence: list List-Id: Xen developer discussion <xen-devel.lists.xensource.com> List-Unsubscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe> List-Post: <mailto:xen-devel@lists.xensource.com> List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help> List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=subscribe> Sender: xen-devel-bounces@lists.xensource.com Errors-To: xen-devel-bounces@lists.xensource.com From: David Vrabel <david.vrabel@citrix.com> Replace calls to the Xen-specific xen_alloc_vm_area() and xen_free_vm_area() functions with the generic equivalent (alloc_vm_area() and free_vm_area()). On x86, these were identical already. Signed-off-by: David Vrabel <david.vrabel@citrix.com> --- arch/ia64/include/asm/xen/grant_table.h | 29 -------------- arch/ia64/xen/grant-table.c | 62 ------------------------------- arch/x86/include/asm/xen/grant_table.h | 7 --- arch/x86/xen/grant-table.c | 2 +- drivers/xen/xenbus/xenbus_client.c | 6 +- include/xen/grant_table.h | 1 - 6 files changed, 4 insertions(+), 103 deletions(-) delete mode 100644 arch/ia64/include/asm/xen/grant_table.h delete mode 100644 arch/x86/include/asm/xen/grant_table.h diff --git a/arch/ia64/include/asm/xen/grant_table.h b/arch/ia64/include/asm/xen/grant_table.h deleted file mode 100644 index 2b1fae0..0000000 --- a/arch/ia64/include/asm/xen/grant_table.h +++ /dev/null @@ -1,29 +0,0 @@ -/****************************************************************************** - * arch/ia64/include/asm/xen/grant_table.h - * - * Copyright (c) 2008 Isaku Yamahata <yamahata at valinux co jp> - * VA Linux Systems Japan K.K. - * - * This program is free software; you can redistribute it and/or modify - * it under the terms of the GNU General Public License as published by - * the Free Software Foundation; either version 2 of the License, or - * (at your option) any later version. - * - * This program is distributed in the hope that it will be useful, - * but WITHOUT ANY WARRANTY; without even the implied warranty of - * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the - * GNU General Public License for more details. - * - * You should have received a copy of the GNU General Public License - * along with this program; if not, write to the Free Software - * Foundation, Inc., 59 Temple Place, Suite 330, Boston, MA 02111-1307 USA - * - */ - -#ifndef _ASM_IA64_XEN_GRANT_TABLE_H -#define _ASM_IA64_XEN_GRANT_TABLE_H - -struct vm_struct *xen_alloc_vm_area(unsigned long size); -void xen_free_vm_area(struct vm_struct *area); - -#endif /* _ASM_IA64_XEN_GRANT_TABLE_H */ diff --git a/arch/ia64/xen/grant-table.c b/arch/ia64/xen/grant-table.c index 48cca37..c182813 100644 --- a/arch/ia64/xen/grant-table.c +++ b/arch/ia64/xen/grant-table.c @@ -31,68 +31,6 @@ #include <asm/xen/hypervisor.h> -struct vm_struct *xen_alloc_vm_area(unsigned long size) -{ - int order; - unsigned long virt; - unsigned long nr_pages; - struct vm_struct *area; - - order = get_order(size); - virt = __get_free_pages(GFP_KERNEL, order); - if (virt == 0) - goto err0; - nr_pages = 1 << order; - scrub_pages(virt, nr_pages); - - area = kmalloc(sizeof(*area), GFP_KERNEL); - if (area == NULL) - goto err1; - - area->flags = VM_IOREMAP; - area->addr = (void *)virt; - area->size = size; - area->pages = NULL; - area->nr_pages = nr_pages; - area->phys_addr = 0; /* xenbus_map_ring_valloc uses this field! */ - - return area; - -err1: - free_pages(virt, order); -err0: - return NULL; -} -EXPORT_SYMBOL_GPL(xen_alloc_vm_area); - -void xen_free_vm_area(struct vm_struct *area) -{ - unsigned int order = get_order(area->size); - unsigned long i; - unsigned long phys_addr = __pa(area->addr); - - /* This area is used for foreign page mappping. - * So underlying machine page may not be assigned. */ - for (i = 0; i < (1 << order); i++) { - unsigned long ret; - unsigned long gpfn = (phys_addr >> PAGE_SHIFT) + i; - struct xen_memory_reservation reservation = { - .nr_extents = 1, - .address_bits = 0, - .extent_order = 0, - .domid = DOMID_SELF - }; - set_xen_guest_handle(reservation.extent_start, &gpfn); - ret = HYPERVISOR_memory_op(XENMEM_populate_physmap, - &reservation); - BUG_ON(ret != 1); - } - free_pages((unsigned long)area->addr, order); - kfree(area); -} -EXPORT_SYMBOL_GPL(xen_free_vm_area); - - /**************************************************************************** * grant table hack * cmd: GNTTABOP_xxx diff --git a/arch/x86/include/asm/xen/grant_table.h b/arch/x86/include/asm/xen/grant_table.h deleted file mode 100644 index fdbbb45..0000000 --- a/arch/x86/include/asm/xen/grant_table.h +++ /dev/null @@ -1,7 +0,0 @@ -#ifndef _ASM_X86_XEN_GRANT_TABLE_H -#define _ASM_X86_XEN_GRANT_TABLE_H - -#define xen_alloc_vm_area(size) alloc_vm_area(size) -#define xen_free_vm_area(area) free_vm_area(area) - -#endif /* _ASM_X86_XEN_GRANT_TABLE_H */ diff --git a/arch/x86/xen/grant-table.c b/arch/x86/xen/grant-table.c index 49ba9b5..6bbfd7a 100644 --- a/arch/x86/xen/grant-table.c +++ b/arch/x86/xen/grant-table.c @@ -71,7 +71,7 @@ int arch_gnttab_map_shared(unsigned long *frames, unsigned long nr_gframes, if (shared == NULL) { struct vm_struct *area = - xen_alloc_vm_area(PAGE_SIZE * max_nr_gframes); + alloc_vm_area(PAGE_SIZE * max_nr_gframes); BUG_ON(area == NULL); shared = area->addr; *__shared = shared; diff --git a/drivers/xen/xenbus/xenbus_client.c b/drivers/xen/xenbus/xenbus_client.c index cdacf92..229d3ad 100644 --- a/drivers/xen/xenbus/xenbus_client.c +++ b/drivers/xen/xenbus/xenbus_client.c @@ -443,7 +443,7 @@ int xenbus_map_ring_valloc(struct xenbus_device *dev, int gnt_ref, void **vaddr) *vaddr = NULL; - area = xen_alloc_vm_area(PAGE_SIZE); + area = alloc_vm_area(PAGE_SIZE); if (!area) return -ENOMEM; @@ -453,7 +453,7 @@ int xenbus_map_ring_valloc(struct xenbus_device *dev, int gnt_ref, void **vaddr) BUG(); if (op.status != GNTST_okay) { - xen_free_vm_area(area); + free_vm_area(area); xenbus_dev_fatal(dev, op.status, "mapping in shared page %d from domain %d", gnt_ref, dev->otherend_id); @@ -552,7 +552,7 @@ int xenbus_unmap_ring_vfree(struct xenbus_device *dev, void *vaddr) BUG(); if (op.status == GNTST_okay) - xen_free_vm_area(area); + free_vm_area(area); else xenbus_dev_error(dev, op.status, "unmapping page at handle %d error %d", diff --git a/include/xen/grant_table.h b/include/xen/grant_table.h index b1fab6b..8a8bb76 100644 --- a/include/xen/grant_table.h +++ b/include/xen/grant_table.h @@ -43,7 +43,6 @@ #include <xen/interface/grant_table.h> #include <asm/xen/hypervisor.h> -#include <asm/xen/grant_table.h> #include <xen/features.h> -- 1.7.2.5 _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel From xen-devel-bounces@lists.xensource.com Thu Sep 29 08:55:54 2011 Return-path: <xen-devel-bounces@lists.xensource.com> Envelope-to: www-data@lists.xensource.com Delivery-date: Thu, 29 Sep 2011 08:55:54 -0700 Received: from localhost ([127.0.0.1] helo=lists.colo.xensource.com) by lists.xensource.com with esmtp (Exim 4.43) id 1R9Ixl-0006hp-T5; Thu, 29 Sep 2011 08:55:53 -0700 Received: from mail27.messagelabs.com ([193.109.254.147]) by lists.xensource.com with esmtp (Exim 4.43) id 1R9IvM-0005nu-Bi for xen-devel@lists.xensource.com; Thu, 29 Sep 2011 08:53:24 -0700 X-Env-Sender: david.vrabel@citrix.com X-Msg-Ref: server-14.tower-27.messagelabs.com!1317311487!38162252!2 X-Originating-IP: [66.165.176.63] X-StarScan-Version: 6.4.1; banners=-,-,- X-VirusChecked: Checked Received: (qmail 1573 invoked from network); 29 Sep 2011 15:51:29 -0000 Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63) by server-14.tower-27.messagelabs.com with RC4-SHA encrypted SMTP; 29 Sep 2011 15:51:29 -0000 X-IronPort-AV: E=Sophos;i="4.68,461,1312171200"; d="scan'208";a="165156374" Received: from ftlpmailmx01.citrite.net ([10.13.107.65]) by FTLPIPO02.CITRIX.COM with ESMTP/TLS/RC4-MD5; 29 Sep 2011 11:53:20 -0400 Received: from smtp01.ad.xensource.com (10.219.128.104) by smtprelay.citrix.com (10.13.107.65) with Microsoft SMTP Server id 8.3.137.0; Thu, 29 Sep 2011 11:53:20 -0400 Received: from qabil.uk.xensource.com (qabil.uk.xensource.com [10.80.2.76]) by smtp01.ad.xensource.com (8.13.1/8.13.1) with ESMTP id p8TFr79I026128; Thu, 29 Sep 2011 08:53:19 -0700 From: David Vrabel <david.vrabel@citrix.com> To: xen-devel@lists.xensource.com Date: Thu, 29 Sep 2011 16:53:31 +0100 Message-ID: <1317311612-15220-4-git-send-email-david.vrabel@citrix.com> X-Mailer: git-send-email 1.7.2.5 In-Reply-To: <1317311612-15220-1-git-send-email-david.vrabel@citrix.com> References: <1317311612-15220-1-git-send-email-david.vrabel@citrix.com> MIME-Version: 1.0 Content-Type: text/plain Cc: David Vrabel <david.vrabel@citrix.com>, Konrad Rzeszutek Wilk <konrad.wilk@oracle.com> Subject: [Xen-devel] [PATCH 3/4] net: xen-netback: use API provided by xenbus module to map rings X-BeenThere: xen-devel@lists.xensource.com X-Mailman-Version: 2.1.5 Precedence: list List-Id: Xen developer discussion <xen-devel.lists.xensource.com> List-Unsubscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe> List-Post: <mailto:xen-devel@lists.xensource.com> List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help> List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=subscribe> Sender: xen-devel-bounces@lists.xensource.com Errors-To: xen-devel-bounces@lists.xensource.com From: David Vrabel <david.vrabel@citrix.com> The xenbus module provides xenbus_map_ring_valloc() and xenbus_map_ring_vfree(). Use these to map the Tx and Rx ring pages granted by the frontend. Signed-off-by: David Vrabel <david.vrabel@citrix.com> Acked-by: Ian Campbell <ian.campbell@citrix.com> --- drivers/net/xen-netback/common.h | 11 ++--- drivers/net/xen-netback/netback.c | 80 ++++++++----------------------------- 2 files changed, 22 insertions(+), 69 deletions(-) diff --git a/drivers/net/xen-netback/common.h b/drivers/net/xen-netback/common.h index 161f207..94b79c3 100644 --- a/drivers/net/xen-netback/common.h +++ b/drivers/net/xen-netback/common.h @@ -58,10 +58,6 @@ struct xenvif { u8 fe_dev_addr[6]; /* Physical parameters of the comms window. */ - grant_handle_t tx_shmem_handle; - grant_ref_t tx_shmem_ref; - grant_handle_t rx_shmem_handle; - grant_ref_t rx_shmem_ref; unsigned int irq; /* List of frontends to notify after a batch of frames sent. */ @@ -70,8 +66,6 @@ struct xenvif { /* The shared rings and indexes. */ struct xen_netif_tx_back_ring tx; struct xen_netif_rx_back_ring rx; - struct vm_struct *tx_comms_area; - struct vm_struct *rx_comms_area; /* Frontend feature information. */ u8 can_sg:1; @@ -106,6 +100,11 @@ struct xenvif { wait_queue_head_t waiting_to_free; }; +static inline struct xenbus_device *xenvif_to_xenbus_device(struct xenvif *vif) +{ + return to_xenbus_device(vif->dev->dev.parent); +} + #define XEN_NETIF_TX_RING_SIZE __CONST_RING_SIZE(xen_netif_tx, PAGE_SIZE) #define XEN_NETIF_RX_RING_SIZE __CONST_RING_SIZE(xen_netif_rx, PAGE_SIZE) diff --git a/drivers/net/xen-netback/netback.c b/drivers/net/xen-netback/netback.c index fd00f25..3af2924 100644 --- a/drivers/net/xen-netback/netback.c +++ b/drivers/net/xen-netback/netback.c @@ -1577,88 +1577,42 @@ static int xen_netbk_kthread(void *data) void xen_netbk_unmap_frontend_rings(struct xenvif *vif) { - struct gnttab_unmap_grant_ref op; - - if (vif->tx.sring) { - gnttab_set_unmap_op(&op, (unsigned long)vif->tx_comms_area->addr, - GNTMAP_host_map, vif->tx_shmem_handle); - - if (HYPERVISOR_grant_table_op(GNTTABOP_unmap_grant_ref, &op, 1)) - BUG(); - } - - if (vif->rx.sring) { - gnttab_set_unmap_op(&op, (unsigned long)vif->rx_comms_area->addr, - GNTMAP_host_map, vif->rx_shmem_handle); - - if (HYPERVISOR_grant_table_op(GNTTABOP_unmap_grant_ref, &op, 1)) - BUG(); - } - if (vif->rx_comms_area) - free_vm_area(vif->rx_comms_area); - if (vif->tx_comms_area) - free_vm_area(vif->tx_comms_area); + if (vif->tx.sring) + xenbus_unmap_ring_vfree(xenvif_to_xenbus_device(vif), + vif->tx.sring); + if (vif->rx.sring) + xenbus_unmap_ring_vfree(xenvif_to_xenbus_device(vif), + vif->rx.sring); } int xen_netbk_map_frontend_rings(struct xenvif *vif, grant_ref_t tx_ring_ref, grant_ref_t rx_ring_ref) { - struct gnttab_map_grant_ref op; + void *addr; struct xen_netif_tx_sring *txs; struct xen_netif_rx_sring *rxs; int err = -ENOMEM; - vif->tx_comms_area = alloc_vm_area(PAGE_SIZE); - if (vif->tx_comms_area == NULL) + err = xenbus_map_ring_valloc(xenvif_to_xenbus_device(vif), + tx_ring_ref, &addr); + if (err) goto err; - vif->rx_comms_area = alloc_vm_area(PAGE_SIZE); - if (vif->rx_comms_area == NULL) - goto err; - - gnttab_set_map_op(&op, (unsigned long)vif->tx_comms_area->addr, - GNTMAP_host_map, tx_ring_ref, vif->domid); - - if (HYPERVISOR_grant_table_op(GNTTABOP_map_grant_ref, &op, 1)) - BUG(); - - if (op.status) { - netdev_warn(vif->dev, - "failed to map tx ring. err=%d status=%d\n", - err, op.status); - err = op.status; - goto err; - } - - vif->tx_shmem_ref = tx_ring_ref; - vif->tx_shmem_handle = op.handle; - - txs = (struct xen_netif_tx_sring *)vif->tx_comms_area->addr; + txs = (struct xen_netif_tx_sring *)addr; BACK_RING_INIT(&vif->tx, txs, PAGE_SIZE); - gnttab_set_map_op(&op, (unsigned long)vif->rx_comms_area->addr, - GNTMAP_host_map, rx_ring_ref, vif->domid); - - if (HYPERVISOR_grant_table_op(GNTTABOP_map_grant_ref, &op, 1)) - BUG(); - - if (op.status) { - netdev_warn(vif->dev, - "failed to map rx ring. err=%d status=%d\n", - err, op.status); - err = op.status; + err = xenbus_map_ring_valloc(xenvif_to_xenbus_device(vif), + rx_ring_ref, &addr); + if (err) goto err; - } - - vif->rx_shmem_ref = rx_ring_ref; - vif->rx_shmem_handle = op.handle; - vif->rx_req_cons_peek = 0; - rxs = (struct xen_netif_rx_sring *)vif->rx_comms_area->addr; + rxs = (struct xen_netif_rx_sring *)addr; BACK_RING_INIT(&vif->rx, rxs, PAGE_SIZE); + vif->rx_req_cons_peek = 0; + return 0; err: -- 1.7.2.5 _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel From xen-devel-bounces@lists.xensource.com Thu Sep 29 08:56:59 2011 Return-path: <xen-devel-bounces@lists.xensource.com> Envelope-to: www-data@lists.xensource.com Delivery-date: Thu, 29 Sep 2011 08:56:59 -0700 Received: from localhost ([127.0.0.1] helo=lists.colo.xensource.com) by lists.xensource.com with esmtp (Exim 4.43) id 1R9Iyp-00079w-9o; Thu, 29 Sep 2011 08:56:59 -0700 Received: from mail216.messagelabs.com ([85.158.143.99]) by lists.xensource.com with esmtp (Exim 4.43) id 1R9IvT-0005py-4T for xen-devel@lists.xensource.com; Thu, 29 Sep 2011 08:53:31 -0700 X-Env-Sender: david.vrabel@citrix.com X-Msg-Ref: server-13.tower-216.messagelabs.com!1317311606!18366514!1 X-Originating-IP: [66.165.176.89] X-StarScan-Version: 6.4.1; banners=-,-,- X-VirusChecked: Checked Received: (qmail 23557 invoked from network); 29 Sep 2011 15:53:27 -0000 Received: from smtp.citrix.com (HELO SMTP.CITRIX.COM) (66.165.176.89) by server-13.tower-216.messagelabs.com with RC4-SHA encrypted SMTP; 29 Sep 2011 15:53:27 -0000 X-IronPort-AV: E=Sophos;i="4.68,462,1312171200"; d="scan'208";a="17811860" Received: from ftlpmailmx01.citrite.net ([10.13.107.65]) by FTLPIPO01.CITRIX.COM with ESMTP/TLS/RC4-MD5; 29 Sep 2011 11:53:19 -0400 Received: from smtp01.ad.xensource.com (10.219.128.104) by smtprelay.citrix.com (10.13.107.65) with Microsoft SMTP Server id 8.3.137.0; Thu, 29 Sep 2011 11:53:19 -0400 Received: from qabil.uk.xensource.com (qabil.uk.xensource.com [10.80.2.76]) by smtp01.ad.xensource.com (8.13.1/8.13.1) with ESMTP id p8TFr79H026128; Thu, 29 Sep 2011 08:53:18 -0700 From: David Vrabel <david.vrabel@citrix.com> To: xen-devel@lists.xensource.com Date: Thu, 29 Sep 2011 16:53:30 +0100 Message-ID: <1317311612-15220-3-git-send-email-david.vrabel@citrix.com> X-Mailer: git-send-email 1.7.2.5 In-Reply-To: <1317311612-15220-1-git-send-email-david.vrabel@citrix.com> References: <1317311612-15220-1-git-send-email-david.vrabel@citrix.com> MIME-Version: 1.0 Content-Type: text/plain Cc: David Vrabel <david.vrabel@citrix.com>, Konrad Rzeszutek Wilk <konrad.wilk@oracle.com> Subject: [Xen-devel] [PATCH 2/4] block: xen-blkback: use API provided by xenbus module to map rings X-BeenThere: xen-devel@lists.xensource.com X-Mailman-Version: 2.1.5 Precedence: list List-Id: Xen developer discussion <xen-devel.lists.xensource.com> List-Unsubscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe> List-Post: <mailto:xen-devel@lists.xensource.com> List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help> List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=subscribe> Sender: xen-devel-bounces@lists.xensource.com Errors-To: xen-devel-bounces@lists.xensource.com From: David Vrabel <david.vrabel@citrix.com> The xenbus module provides xenbus_map_ring_valloc() and xenbus_map_ring_vfree(). Use these to map the ring pages granted by the frontend. Signed-off-by: David Vrabel <david.vrabel@citrix.com> --- drivers/block/xen-blkback/common.h | 5 +-- drivers/block/xen-blkback/xenbus.c | 54 ++++------------------------------- 2 files changed, 8 insertions(+), 51 deletions(-) diff --git a/drivers/block/xen-blkback/common.h b/drivers/block/xen-blkback/common.h index 00c57c9..7ec0e88 100644 --- a/drivers/block/xen-blkback/common.h +++ b/drivers/block/xen-blkback/common.h @@ -139,7 +139,7 @@ struct xen_blkif { /* Comms information. */ enum blkif_protocol blk_protocol; union blkif_back_rings blk_rings; - struct vm_struct *blk_ring_area; + void *blk_ring; /* The VBD attached to this interface. */ struct xen_vbd vbd; /* Back pointer to the backend_info. */ @@ -163,9 +163,6 @@ struct xen_blkif { int st_wr_sect; wait_queue_head_t waiting_to_free; - - grant_handle_t shmem_handle; - grant_ref_t shmem_ref; }; diff --git a/drivers/block/xen-blkback/xenbus.c b/drivers/block/xen-blkback/xenbus.c index 5fd2010..69233dd 100644 --- a/drivers/block/xen-blkback/xenbus.c +++ b/drivers/block/xen-blkback/xenbus.c @@ -120,38 +120,6 @@ static struct xen_blkif *xen_blkif_alloc(domid_t domid) return blkif; } -static int map_frontend_page(struct xen_blkif *blkif, unsigned long shared_page) -{ - struct gnttab_map_grant_ref op; - - gnttab_set_map_op(&op, (unsigned long)blkif->blk_ring_area->addr, - GNTMAP_host_map, shared_page, blkif->domid); - - if (HYPERVISOR_grant_table_op(GNTTABOP_map_grant_ref, &op, 1)) - BUG(); - - if (op.status) { - DPRINTK("Grant table operation failure !\n"); - return op.status; - } - - blkif->shmem_ref = shared_page; - blkif->shmem_handle = op.handle; - - return 0; -} - -static void unmap_frontend_page(struct xen_blkif *blkif) -{ - struct gnttab_unmap_grant_ref op; - - gnttab_set_unmap_op(&op, (unsigned long)blkif->blk_ring_area->addr, - GNTMAP_host_map, blkif->shmem_handle); - - if (HYPERVISOR_grant_table_op(GNTTABOP_unmap_grant_ref, &op, 1)) - BUG(); -} - static int xen_blkif_map(struct xen_blkif *blkif, unsigned long shared_page, unsigned int evtchn) { @@ -161,35 +129,29 @@ static int xen_blkif_map(struct xen_blkif *blkif, unsigned long shared_page, if (blkif->irq) return 0; - blkif->blk_ring_area = alloc_vm_area(PAGE_SIZE); - if (!blkif->blk_ring_area) - return -ENOMEM; - - err = map_frontend_page(blkif, shared_page); - if (err) { - free_vm_area(blkif->blk_ring_area); + err = xenbus_map_ring_valloc(blkif->be->dev, shared_page, &blkif->blk_ring); + if (err < 0) return err; - } switch (blkif->blk_protocol) { case BLKIF_PROTOCOL_NATIVE: { struct blkif_sring *sring; - sring = (struct blkif_sring *)blkif->blk_ring_area->addr; + sring = (struct blkif_sring *)blkif->blk_ring; BACK_RING_INIT(&blkif->blk_rings.native, sring, PAGE_SIZE); break; } case BLKIF_PROTOCOL_X86_32: { struct blkif_x86_32_sring *sring_x86_32; - sring_x86_32 = (struct blkif_x86_32_sring *)blkif->blk_ring_area->addr; + sring_x86_32 = (struct blkif_x86_32_sring *)blkif->blk_ring; BACK_RING_INIT(&blkif->blk_rings.x86_32, sring_x86_32, PAGE_SIZE); break; } case BLKIF_PROTOCOL_X86_64: { struct blkif_x86_64_sring *sring_x86_64; - sring_x86_64 = (struct blkif_x86_64_sring *)blkif->blk_ring_area->addr; + sring_x86_64 = (struct blkif_x86_64_sring *)blkif->blk_ring; BACK_RING_INIT(&blkif->blk_rings.x86_64, sring_x86_64, PAGE_SIZE); break; } @@ -201,8 +163,7 @@ static int xen_blkif_map(struct xen_blkif *blkif, unsigned long shared_page, xen_blkif_be_int, 0, "blkif-backend", blkif); if (err < 0) { - unmap_frontend_page(blkif); - free_vm_area(blkif->blk_ring_area); + xenbus_unmap_ring_vfree(blkif->be->dev, blkif->blk_ring); blkif->blk_rings.common.sring = NULL; return err; } @@ -228,8 +189,7 @@ static void xen_blkif_disconnect(struct xen_blkif *blkif) } if (blkif->blk_rings.common.sring) { - unmap_frontend_page(blkif); - free_vm_area(blkif->blk_ring_area); + xenbus_unmap_ring_vfree(blkif->be->dev, blkif->blk_ring); blkif->blk_rings.common.sring = NULL; } } -- 1.7.2.5 _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel From xen-devel-bounces@lists.xensource.com Thu Sep 29 08:58:36 2011 Return-path: <xen-devel-bounces@lists.xensource.com> Envelope-to: www-data@lists.xensource.com Delivery-date: Thu, 29 Sep 2011 08:58:36 -0700 Received: from localhost ([127.0.0.1] helo=lists.colo.xensource.com) by lists.xensource.com with esmtp (Exim 4.43) id 1R9J0O-0007Zs-M0; Thu, 29 Sep 2011 08:58:36 -0700 Received: from mail216.messagelabs.com ([85.158.143.99]) by lists.xensource.com with esmtp (Exim 4.43) id 1R9IvT-0005q2-Nn for xen-devel@lists.xensource.com; Thu, 29 Sep 2011 08:53:32 -0700 X-Env-Sender: david.vrabel@citrix.com X-Msg-Ref: server-13.tower-216.messagelabs.com!1317311606!18366514!2 X-Originating-IP: [66.165.176.89] X-StarScan-Version: 6.4.1; banners=-,-,- X-VirusChecked: Checked Received: (qmail 23598 invoked from network); 29 Sep 2011 15:53:28 -0000 Received: from smtp.citrix.com (HELO SMTP.CITRIX.COM) (66.165.176.89) by server-13.tower-216.messagelabs.com with RC4-SHA encrypted SMTP; 29 Sep 2011 15:53:28 -0000 X-IronPort-AV: E=Sophos;i="4.68,462,1312171200"; d="scan'208";a="17811862" Received: from ftlpmailmx01.citrite.net ([10.13.107.65]) by FTLPIPO01.CITRIX.COM with ESMTP/TLS/RC4-MD5; 29 Sep 2011 11:53:26 -0400 Received: from smtp01.ad.xensource.com (10.219.128.104) by smtprelay.citrix.com (10.13.107.65) with Microsoft SMTP Server id 8.3.137.0; Thu, 29 Sep 2011 11:53:25 -0400 Received: from qabil.uk.xensource.com (qabil.uk.xensource.com [10.80.2.76]) by smtp01.ad.xensource.com (8.13.1/8.13.1) with ESMTP id p8TFr79J026128; Thu, 29 Sep 2011 08:53:20 -0700 From: David Vrabel <david.vrabel@citrix.com> To: xen-devel@lists.xensource.com Date: Thu, 29 Sep 2011 16:53:32 +0100 Message-ID: <1317311612-15220-5-git-send-email-david.vrabel@citrix.com> X-Mailer: git-send-email 1.7.2.5 In-Reply-To: <1317311612-15220-1-git-send-email-david.vrabel@citrix.com> References: <1317311612-15220-1-git-send-email-david.vrabel@citrix.com> MIME-Version: 1.0 Content-Type: text/plain Cc: Andrew Morton <akpm@linux-foundation.org>, David Vrabel <david.vrabel@citrix.com>, Jeremy Fitzhardinge <jeremy@goop.org>, Konrad Rzeszutek Wilk <konrad.wilk@oracle.com> Subject: [Xen-devel] [PATCH 4/4] xen: map foreign pages for shared rings by updating the PTEs directly X-BeenThere: xen-devel@lists.xensource.com X-Mailman-Version: 2.1.5 Precedence: list List-Id: Xen developer discussion <xen-devel.lists.xensource.com> List-Unsubscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe> List-Post: <mailto:xen-devel@lists.xensource.com> List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help> List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=subscribe> Sender: xen-devel-bounces@lists.xensource.com Errors-To: xen-devel-bounces@lists.xensource.com From: David Vrabel <david.vrabel@citrix.com> When mapping a foreign page with xenbus_map_ring_valloc() with the GNTTABOP_map_grant_ref hypercall, set the GNTMAP_contains_pte flag and pass a pointer to the PTE (in init_mm). After the page is mapped, the usual fault mechanism can be used to update additional MMs. This allows the vmalloc_sync_all() to be removed from alloc_vm_area(). Signed-off-by: David Vrabel <david.vrabel@citrix.com> Cc: Andrew Morton <akpm@linux-foundation.org> Cc: Jeremy Fitzhardinge <jeremy@goop.org> --- arch/x86/xen/grant-table.c | 2 +- drivers/xen/xenbus/xenbus_client.c | 11 ++++++++--- include/linux/vmalloc.h | 2 +- mm/vmalloc.c | 27 +++++++++++++-------------- 4 files changed, 23 insertions(+), 19 deletions(-) diff --git a/arch/x86/xen/grant-table.c b/arch/x86/xen/grant-table.c index 6bbfd7a..5a40d24 100644 --- a/arch/x86/xen/grant-table.c +++ b/arch/x86/xen/grant-table.c @@ -71,7 +71,7 @@ int arch_gnttab_map_shared(unsigned long *frames, unsigned long nr_gframes, if (shared == NULL) { struct vm_struct *area = - alloc_vm_area(PAGE_SIZE * max_nr_gframes); + alloc_vm_area(PAGE_SIZE * max_nr_gframes, NULL); BUG_ON(area == NULL); shared = area->addr; *__shared = shared; diff --git a/drivers/xen/xenbus/xenbus_client.c b/drivers/xen/xenbus/xenbus_client.c index 229d3ad..52bc57f 100644 --- a/drivers/xen/xenbus/xenbus_client.c +++ b/drivers/xen/xenbus/xenbus_client.c @@ -34,6 +34,7 @@ #include <linux/types.h> #include <linux/vmalloc.h> #include <asm/xen/hypervisor.h> +#include <asm/xen/page.h> #include <xen/interface/xen.h> #include <xen/interface/event_channel.h> #include <xen/events.h> @@ -435,19 +436,20 @@ EXPORT_SYMBOL_GPL(xenbus_free_evtchn); int xenbus_map_ring_valloc(struct xenbus_device *dev, int gnt_ref, void **vaddr) { struct gnttab_map_grant_ref op = { - .flags = GNTMAP_host_map, + .flags = GNTMAP_host_map | GNTMAP_contains_pte, .ref = gnt_ref, .dom = dev->otherend_id, }; struct vm_struct *area; + pte_t *pte; *vaddr = NULL; - area = alloc_vm_area(PAGE_SIZE); + area = alloc_vm_area(PAGE_SIZE, &pte); if (!area) return -ENOMEM; - op.host_addr = (unsigned long)area->addr; + op.host_addr = arbitrary_virt_to_machine(pte).maddr; if (HYPERVISOR_grant_table_op(GNTTABOP_map_grant_ref, &op, 1)) BUG(); @@ -526,6 +528,7 @@ int xenbus_unmap_ring_vfree(struct xenbus_device *dev, void *vaddr) struct gnttab_unmap_grant_ref op = { .host_addr = (unsigned long)vaddr, }; + unsigned int level; /* It'd be nice if linux/vmalloc.h provided a find_vm_area(void *addr) * method so that we don't have to muck with vmalloc internals here. @@ -547,6 +550,8 @@ int xenbus_unmap_ring_vfree(struct xenbus_device *dev, void *vaddr) } op.handle = (grant_handle_t)area->phys_addr; + op.host_addr = arbitrary_virt_to_machine( + lookup_address((unsigned long)vaddr, &level)).maddr; if (HYPERVISOR_grant_table_op(GNTTABOP_unmap_grant_ref, &op, 1)) BUG(); diff --git a/include/linux/vmalloc.h b/include/linux/vmalloc.h index 9332e52..1a77252 100644 --- a/include/linux/vmalloc.h +++ b/include/linux/vmalloc.h @@ -118,7 +118,7 @@ unmap_kernel_range(unsigned long addr, unsigned long size) #endif /* Allocate/destroy a 'vmalloc' VM area. */ -extern struct vm_struct *alloc_vm_area(size_t size); +extern struct vm_struct *alloc_vm_area(size_t size, pte_t **ptes); extern void free_vm_area(struct vm_struct *area); /* for /dev/kmem */ diff --git a/mm/vmalloc.c b/mm/vmalloc.c index 5016f19..b5deec6 100644 --- a/mm/vmalloc.c +++ b/mm/vmalloc.c @@ -2105,23 +2105,30 @@ void __attribute__((weak)) vmalloc_sync_all(void) static int f(pte_t *pte, pgtable_t table, unsigned long addr, void *data) { - /* apply_to_page_range() does all the hard work. */ + pte_t ***p = data; + + if (p) { + *(*p) = pte; + (*p)++; + } return 0; } /** * alloc_vm_area - allocate a range of kernel address space * @size: size of the area + * @ptes: returns the PTEs for the address space * * Returns: NULL on failure, vm_struct on success * * This function reserves a range of kernel address space, and * allocates pagetables to map that range. No actual mappings - * are created. If the kernel address space is not shared - * between processes, it syncs the pagetable across all - * processes. + * are created. + * + * If @ptes is non-NULL, pointers to the PTEs (in init_mm) + * allocated for the VM area are returned. */ -struct vm_struct *alloc_vm_area(size_t size) +struct vm_struct *alloc_vm_area(size_t size, pte_t **ptes) { struct vm_struct *area; @@ -2135,19 +2142,11 @@ struct vm_struct *alloc_vm_area(size_t size) * of kernel virtual address space and mapped into init_mm. */ if (apply_to_page_range(&init_mm, (unsigned long)area->addr, - area->size, f, NULL)) { + size, f, ptes ? &ptes : NULL)) { free_vm_area(area); return NULL; } - /* - * If the allocated address space is passed to a hypercall - * before being used then we cannot rely on a page fault to - * trigger an update of the page tables. So sync all the page - * tables here. - */ - vmalloc_sync_all(); - return area; } EXPORT_SYMBOL_GPL(alloc_vm_area); -- 1.7.2.5 _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel From xen-devel-bounces@lists.xensource.com Thu Sep 29 09:09:18 2011 Return-path: <xen-devel-bounces@lists.xensource.com> Envelope-to: www-data@lists.xensource.com Delivery-date: Thu, 29 Sep 2011 09:09:18 -0700 Received: from localhost ([127.0.0.1] helo=lists.colo.xensource.com) by lists.xensource.com with esmtp (Exim 4.43) id 1R9JAj-000865-Bv; Thu, 29 Sep 2011 09:09:17 -0700 Received: from mail174.messagelabs.com ([85.158.138.51]) by lists.xensource.com with esmtp (Exim 4.43) id 1R9J9Y-0007tU-OF for xen-devel@lists.xensource.com; Thu, 29 Sep 2011 09:08:06 -0700 X-Env-Sender: JBeulich@suse.com X-Msg-Ref: server-14.tower-174.messagelabs.com!1317312481!33266420!1 X-Originating-IP: [130.57.49.28] X-StarScan-Version: 6.4.1; banners=-,-,- X-VirusChecked: Checked Received: (qmail 17299 invoked from network); 29 Sep 2011 16:08:01 -0000 Received: from nat28.tlf.novell.com (HELO nat28.tlf.novell.com) (130.57.49.28) by server-14.tower-174.messagelabs.com with DHE-RSA-AES256-SHA encrypted SMTP; 29 Sep 2011 16:08:01 -0000 Received: from EMEA1-MTA by nat28.tlf.novell.com with Novell_GroupWise; Thu, 29 Sep 2011 17:08:00 +0100 Message-Id: <4E84B3FE02000078000588A9@nat28.tlf.novell.com> X-Mailer: Novell GroupWise Internet Agent 8.0.1 Date: Thu, 29 Sep 2011 17:07:58 +0100 From: "Jan Beulich" <JBeulich@suse.com> To: "David Vrabel" <david.vrabel@citrix.com>, <xen-devel@lists.xensource.com> Subject: Re: [Xen-devel] [PATCH 0/4] xen: map foreign pages for shared rings by updating the PTEs directly References: <1317311612-15220-1-git-send-email-david.vrabel@citrix.com> In-Reply-To: <1317311612-15220-1-git-send-email-david.vrabel@citrix.com> Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: quoted-printable Content-Disposition: inline Cc: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com> X-BeenThere: xen-devel@lists.xensource.com X-Mailman-Version: 2.1.5 Precedence: list List-Id: Xen developer discussion <xen-devel.lists.xensource.com> List-Unsubscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe> List-Post: <mailto:xen-devel@lists.xensource.com> List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help> List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=subscribe> Sender: xen-devel-bounces@lists.xensource.com Errors-To: xen-devel-bounces@lists.xensource.com >>> On 29.09.11 at 17:53, David Vrabel <david.vrabel@citrix.com> wrote: > [Resend as requested by Konrad.] >=20 > This series of patches allows the vmalloc_sync_all() to be removed > from alloc_vm_area() by getting the hypervisor to update the PTEs (in > init_mm) directly rather than having the hypervisor look in the > current page tables to find the PTEs. >=20 > Once the hypervisor has updated the PTEs, the normal mechanism of > syncing the page tables after a fault works as expected. Did you actually test that, and namely the case where alloc_vm_area() would result in a new top level page directory entry to get populated? I cannot see how this new entry would propagate into other mm-s, and hence I cannot see how you can do away with calling vmalloc_sync_all() just by changing how leaf page table entries get populated. Jan > This mechanism doesn't currently work on the ia64 port as that does > not support the GNTMAP_contains_pte flag. >=20 > David >=20 >=20 > _______________________________________________ > Xen-devel mailing list > Xen-devel@lists.xensource.com=20 > http://lists.xensource.com/xen-devel=20 _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel From xen-devel-bounces@lists.xensource.com Thu Sep 29 09:14:58 2011 Return-path: <xen-devel-bounces@lists.xensource.com> Envelope-to: www-data@lists.xensource.com Delivery-date: Thu, 29 Sep 2011 09:14:58 -0700 Received: from localhost ([127.0.0.1] helo=lists.colo.xensource.com) by lists.xensource.com with esmtp (Exim 4.43) id 1R9JGE-00005l-2B; Thu, 29 Sep 2011 09:14:58 -0700 Received: from mail216.messagelabs.com ([85.158.143.99]) by lists.xensource.com with esmtp (Exim 4.43) id 1R9JFE-0008KD-U4 for xen-devel@lists.xensource.com; Thu, 29 Sep 2011 09:13:57 -0700 X-Env-Sender: chintamani.sid@gmail.com X-Msg-Ref: server-5.tower-216.messagelabs.com!1317312832!17931662!1 X-Originating-IP: [216.139.236.26] X-StarScan-Version: 6.4.1; banners=-,-,- X-VirusChecked: Checked Received: (qmail 28306 invoked from network); 29 Sep 2011 16:13:53 -0000 Received: from sam.nabble.com (HELO sam.nabble.com) (216.139.236.26) by server-5.tower-216.messagelabs.com with AES256-SHA encrypted SMTP; 29 Sep 2011 16:13:53 -0000 Received: from [192.168.236.26] (helo=sam.nabble.com) by sam.nabble.com with esmtp (Exim 4.72) (envelope-from <chintamani.sid@gmail.com>) id 1R9JFA-0008TW-Bo for xen-devel@lists.xensource.com; Thu, 29 Sep 2011 09:13:52 -0700 Date: Thu, 29 Sep 2011 09:13:52 -0700 (PDT) From: Chintamani Siddeshwar <chintamani.sid@gmail.com> To: xen-devel@lists.xensource.com Message-ID: <1317312832330-4853794.post@n5.nabble.com> In-Reply-To: <1317172992048-4847541.post@n5.nabble.com> References: <1317172992048-4847541.post@n5.nabble.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Subject: [Xen-devel] Re: Getting the page fault count for domU X-BeenThere: xen-devel@lists.xensource.com X-Mailman-Version: 2.1.5 Precedence: list List-Id: Xen developer discussion <xen-devel.lists.xensource.com> List-Unsubscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe> List-Post: <mailto:xen-devel@lists.xensource.com> List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help> List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=subscribe> Sender: xen-devel-bounces@lists.xensource.com Errors-To: xen-devel-bounces@lists.xensource.com I am thinking of doing something like 1) Add a field "unsigned long page_fault_count" to struct domain defined in in xen/sched.h 2) Increment this counter mem_paging_domctl(...) defined in arch/x_86/mm/mem_paging.c for case XEN_DOMCTL_MEM_EVENT_OP_PAGING_EVICT I will then access this information is available from within struct vcpu->domain->page_fault_count. Please correct me if my chain of thought is wrong or if it is too simplistic. Looking forward to your valuable comments thanks Chintamani -- View this message in context: http://xen.1045712.n5.nabble.com/Getting-the-page-fault-count-for-domU-tp4847541p4853794.html Sent from the Xen - Dev mailing list archive at Nabble.com. _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel From xen-devel-bounces@lists.xensource.com Thu Sep 29 09:21:15 2011 Return-path: <xen-devel-bounces@lists.xensource.com> Envelope-to: www-data@lists.xensource.com Delivery-date: Thu, 29 Sep 2011 09:21:15 -0700 Received: from localhost ([127.0.0.1] helo=lists.colo.xensource.com) by lists.xensource.com with esmtp (Exim 4.43) id 1R9JMJ-0000Z1-L9; Thu, 29 Sep 2011 09:21:15 -0700 Received: from mail216.messagelabs.com ([85.158.143.99]) by lists.xensource.com with esmtp (Exim 4.43) id 1R9JLe-0000LT-UO for xen-devel@lists.xensource.com; Thu, 29 Sep 2011 09:20:35 -0700 X-Env-Sender: Ian.Campbell@eu.citrix.com X-Msg-Ref: server-3.tower-216.messagelabs.com!1317313230!19009782!1 X-Originating-IP: [66.165.176.89] X-StarScan-Version: 6.4.1; banners=-,-,- X-VirusChecked: Checked Received: (qmail 9636 invoked from network); 29 Sep 2011 16:20:31 -0000 Received: from smtp.citrix.com (HELO SMTP.CITRIX.COM) (66.165.176.89) by server-3.tower-216.messagelabs.com with RC4-SHA encrypted SMTP; 29 Sep 2011 16:20:31 -0000 X-IronPort-AV: E=Sophos;i="4.68,462,1312171200"; d="scan'208";a="17812853" Received: from ftlpmailmx02.citrite.net ([10.13.107.66]) by FTLPIPO01.CITRIX.COM with ESMTP/TLS/RC4-MD5; 29 Sep 2011 12:20:30 -0400 Received: from smtp01.ad.xensource.com (10.219.128.104) by smtprelay.citrix.com (10.13.107.66) with Microsoft SMTP Server id 8.3.137.0; Thu, 29 Sep 2011 12:20:29 -0400 Received: from localhost.localdomain (cosworth.uk.xensource.com [10.80.16.52]) by smtp01.ad.xensource.com (8.13.1/8.13.1) with ESMTP id p8TGKSAc026204; Thu, 29 Sep 2011 09:20:28 -0700 Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Message-ID: <patchbomb.1317313227@localhost.localdomain> User-Agent: Mercurial-patchbomb/1.6.4 Date: Thu, 29 Sep 2011 17:20:27 +0100 From: Ian Campbell <ian.campbell@citrix.com> To: xen-devel@lists.xensource.com Cc: Ian Campbell <ian.campbell@citrix.com> Subject: [Xen-devel] [PATCH 0 of 6] libxl: support json for pretty printing objects X-BeenThere: xen-devel@lists.xensource.com X-Mailman-Version: 2.1.5 Precedence: list List-Id: Xen developer discussion <xen-devel.lists.xensource.com> List-Unsubscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe> List-Post: <mailto:xen-devel@lists.xensource.com> List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help> List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=subscribe> Sender: xen-devel-bounces@lists.xensource.com Errors-To: xen-devel-bounces@lists.xensource.com Now that Anthony's QMP series is in we can build upon the use of YAJL to add support for pretty printing libxl objects as JSON. Also includes a user in xl (to print disks on dry run) and an associated fix to the check-xl-disk-parse test script. I've appended a couple of unrelated fixes to the xl disk code, only because they also touch check-xl-disk-parse. _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel From xen-devel-bounces@lists.xensource.com Thu Sep 29 09:22:18 2011 Return-path: <xen-devel-bounces@lists.xensource.com> Envelope-to: www-data@lists.xensource.com Delivery-date: Thu, 29 Sep 2011 09:22:18 -0700 Received: from localhost ([127.0.0.1] helo=lists.colo.xensource.com) by lists.xensource.com with esmtp (Exim 4.43) id 1R9JNJ-0000w8-Uv; Thu, 29 Sep 2011 09:22:18 -0700 Received: from mail216.messagelabs.com ([85.158.143.99]) by lists.xensource.com with esmtp (Exim 4.43) id 1R9JLg-0000LV-FU for xen-devel@lists.xensource.com; Thu, 29 Sep 2011 09:20:37 -0700 X-Env-Sender: Ian.Campbell@eu.citrix.com X-Msg-Ref: server-9.tower-216.messagelabs.com!1317313232!20052523!1 X-Originating-IP: [66.165.176.63] X-StarScan-Version: 6.4.1; banners=-,-,- X-VirusChecked: Checked Received: (qmail 10721 invoked from network); 29 Sep 2011 16:20:33 -0000 Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63) by server-9.tower-216.messagelabs.com with RC4-SHA encrypted SMTP; 29 Sep 2011 16:20:33 -0000 X-IronPort-AV: E=Sophos;i="4.68,462,1312171200"; d="scan'208";a="165161520" Received: from ftlpmailmx02.citrite.net ([10.13.107.66]) by FTLPIPO02.CITRIX.COM with ESMTP/TLS/RC4-MD5; 29 Sep 2011 12:20:31 -0400 Received: from smtp01.ad.xensource.com (10.219.128.104) by smtprelay.citrix.com (10.13.107.66) with Microsoft SMTP Server id 8.3.137.0; Thu, 29 Sep 2011 12:20:31 -0400 Received: from localhost.localdomain (cosworth.uk.xensource.com [10.80.16.52]) by smtp01.ad.xensource.com (8.13.1/8.13.1) with ESMTP id p8TGKSAe026204; Thu, 29 Sep 2011 09:20:30 -0700 Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Mercurial-Node: 3fb003a5d5367ccdfb969fd786b57ef2e103f289 Message-ID: <3fb003a5d5367ccdfb96.1317313229@localhost.localdomain> In-Reply-To: <patchbomb.1317313227@localhost.localdomain> References: <patchbomb.1317313227@localhost.localdomain> User-Agent: Mercurial-patchbomb/1.6.4 Date: Thu, 29 Sep 2011 17:20:29 +0100 From: Ian Campbell <ian.campbell@citrix.com> To: xen-devel@lists.xensource.com Cc: Ian Campbell <ian.campbell@citrix.com> Subject: [Xen-devel] [PATCH 2 of 6] xl: allow check-xl-disk-parse to run against installed xl as well as build dir X-BeenThere: xen-devel@lists.xensource.com X-Mailman-Version: 2.1.5 Precedence: list List-Id: Xen developer discussion <xen-devel.lists.xensource.com> List-Unsubscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe> List-Post: <mailto:xen-devel@lists.xensource.com> List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help> List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=subscribe> Sender: xen-devel-bounces@lists.xensource.com Errors-To: xen-devel-bounces@lists.xensource.com # HG changeset patch # User Ian Campbell <ian.campbell@citrix.com> # Date 1317312717 -3600 # Node ID 3fb003a5d5367ccdfb969fd786b57ef2e103f289 # Parent 030e844fccebcc3984c5792559c0cbd5424d277a xl: allow check-xl-disk-parse to run against installed xl as well as build dir I can't run from the current directory since my build box isn't running Xen so if ./xl doesn't exist use the installed version on the assumption that I've copied the script to a test host. I think running from the build dir needs the blktap2 libraries, so update LD_LIBRARY_PATH as appropriate. Signed-off-by: Ian Campbell <ian.campbell@citrix.com> diff -r 030e844fcceb -r 3fb003a5d536 tools/libxl/check-xl-disk-parse --- a/tools/libxl/check-xl-disk-parse Thu Sep 29 17:02:14 2011 +0100 +++ b/tools/libxl/check-xl-disk-parse Thu Sep 29 17:11:57 2011 +0100 @@ -2,6 +2,13 @@ set -e +if [ -x ./xl ] ; then + export LD_LIBRARY_PATH=.:../libxc:../xenstore:../blktap2/control + XL=./xl +else + XL=/usr/sbin/xl +fi + fprefix=tmp.check-xl-disk-parse expected () { @@ -14,8 +21,7 @@ one () { expected_rc=$1; shift printf "test case %s...\n" "$*" set +e - LD_LIBRARY_PATH=.:../libxc:../xenstore \ - ./xl -N block-attach 0 "$@" </dev/null >$fprefix.actual 2>/dev/null + ${XL} -N block-attach 0 "$@" </dev/null >$fprefix.actual 2>/dev/null actual_rc=$? diff -u $fprefix.expected $fprefix.actual diff_rc=$? _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel From xen-devel-bounces@lists.xensource.com Thu Sep 29 09:23:28 2011 Return-path: <xen-devel-bounces@lists.xensource.com> Envelope-to: www-data@lists.xensource.com Delivery-date: Thu, 29 Sep 2011 09:23:28 -0700 Received: from localhost ([127.0.0.1] helo=lists.colo.xensource.com) by lists.xensource.com with esmtp (Exim 4.43) id 1R9JOS-0001Iz-Dc; Thu, 29 Sep 2011 09:23:28 -0700 Received: from mail216.messagelabs.com ([85.158.143.99]) by lists.xensource.com with esmtp (Exim 4.43) id 1R9JLg-0000LW-Iz for xen-devel@lists.xensource.com; Thu, 29 Sep 2011 09:20:37 -0700 X-Env-Sender: Ian.Campbell@eu.citrix.com X-Msg-Ref: server-3.tower-216.messagelabs.com!1317313230!19009782!3 X-Originating-IP: [66.165.176.89] X-StarScan-Version: 6.4.1; banners=-,-,- X-VirusChecked: Checked Received: (qmail 9698 invoked from network); 29 Sep 2011 16:20:33 -0000 Received: from smtp.citrix.com (HELO SMTP.CITRIX.COM) (66.165.176.89) by server-3.tower-216.messagelabs.com with RC4-SHA encrypted SMTP; 29 Sep 2011 16:20:33 -0000 X-IronPort-AV: E=Sophos;i="4.68,462,1312171200"; d="scan'208";a="17812860" Received: from ftlpmailmx02.citrite.net ([10.13.107.66]) by FTLPIPO01.CITRIX.COM with ESMTP/TLS/RC4-MD5; 29 Sep 2011 12:20:32 -0400 Received: from smtp01.ad.xensource.com (10.219.128.104) by smtprelay.citrix.com (10.13.107.66) with Microsoft SMTP Server id 8.3.137.0; Thu, 29 Sep 2011 12:20:32 -0400 Received: from localhost.localdomain (cosworth.uk.xensource.com [10.80.16.52]) by smtp01.ad.xensource.com (8.13.1/8.13.1) with ESMTP id p8TGKSAf026204; Thu, 29 Sep 2011 09:20:31 -0700 Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Mercurial-Node: 6c2b62f0452a73811f708f162490cf7c1c247295 Message-ID: <6c2b62f0452a73811f70.1317313230@localhost.localdomain> In-Reply-To: <patchbomb.1317313227@localhost.localdomain> References: <patchbomb.1317313227@localhost.localdomain> User-Agent: Mercurial-patchbomb/1.6.4 Date: Thu, 29 Sep 2011 17:20:30 +0100 From: Ian Campbell <ian.campbell@citrix.com> To: xen-devel@lists.xensource.com Cc: Ian Campbell <ian.campbell@citrix.com> Subject: [Xen-devel] [PATCH 3 of 6] xl: use libxl_device_disk_to_json to pretty print disk configuration X-BeenThere: xen-devel@lists.xensource.com X-Mailman-Version: 2.1.5 Precedence: list List-Id: Xen developer discussion <xen-devel.lists.xensource.com> List-Unsubscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe> List-Post: <mailto:xen-devel@lists.xensource.com> List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help> List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=subscribe> Sender: xen-devel-bounces@lists.xensource.com Errors-To: xen-devel-bounces@lists.xensource.com # HG changeset patch # User Ian Campbell <ian.campbell@citrix.com> # Date 1317312915 -3600 # Node ID 6c2b62f0452a73811f708f162490cf7c1c247295 # Parent 3fb003a5d5367ccdfb969fd786b57ef2e103f289 xl: use libxl_device_disk_to_json to pretty print disk configuration Signed-off-by: Ian Campbell <ian.campbell@citrix.com> diff -r 3fb003a5d536 -r 6c2b62f0452a tools/libxl/check-xl-disk-parse --- a/tools/libxl/check-xl-disk-parse Thu Sep 29 17:11:57 2011 +0100 +++ b/tools/libxl/check-xl-disk-parse Thu Sep 29 17:15:15 2011 +0100 @@ -51,15 +51,18 @@ expected </dev/null one $e foo expected <<END -disk.backend_domid = 0 -disk.pdev_path = /dev/vg/guest-volume -disk.vdev = hda -disk.backend = 0 -disk.format = 4 -disk.script = (null) -disk.removable = 0 -disk.readwrite = 1 -disk.is_cdrom = 0 +disk: { + "backend_domid": 0, + "pdev_path": "/dev/vg/guest-volume", + "vdev": "hda", + "backend": "unknown", + "format": "raw", + "script": null, + "removable": 0, + "readwrite": 1, + "is_cdrom": 0 +} + END one 0 /dev/vg/guest-volume,,hda one 0 /dev/vg/guest-volume,raw,hda,rw @@ -68,15 +71,18 @@ one 0 format=raw vdev=hda access=rw one 0 raw:/dev/vg/guest-volume,hda,w expected <<END -disk.backend_domid = 0 -disk.pdev_path = /root/image.iso -disk.vdev = hdc -disk.backend = 0 -disk.format = 4 -disk.script = (null) -disk.removable = 1 -disk.readwrite = 0 -disk.is_cdrom = 1 +disk: { + "backend_domid": 0, + "pdev_path": "/root/image.iso", + "vdev": "hdc", + "backend": "unknown", + "format": "raw", + "script": null, + "removable": 1, + "readwrite": 0, + "is_cdrom": 1 +} + END one 0 /root/image.iso,,hdc,cdrom one 0 /root/image.iso,,hdc,,cdrom diff -r 3fb003a5d536 -r 6c2b62f0452a tools/libxl/xl_cmdimpl.c --- a/tools/libxl/xl_cmdimpl.c Thu Sep 29 17:11:57 2011 +0100 +++ b/tools/libxl/xl_cmdimpl.c Thu Sep 29 17:15:15 2011 +0100 @@ -4109,17 +4109,9 @@ int main_blockattach(int argc, char **ar disk.backend_domid = be_domid; if (dryrun_only) { - /* fixme: this should be generated from the idl */ - /* fixme: enums (backend, format) should be converted to strings */ - printf("disk.backend_domid = %"PRIx32"\n", disk.backend_domid); - printf("disk.pdev_path = %s\n", disk.pdev_path); - printf("disk.vdev = %s\n", disk.vdev); - printf("disk.backend = %d\n", disk.backend); - printf("disk.format = %d\n", disk.format); - printf("disk.script = %s\n", disk.script); - printf("disk.removable = %d\n", disk.removable); - printf("disk.readwrite = %d\n", disk.readwrite); - printf("disk.is_cdrom = %d\n", disk.is_cdrom); + char *json = libxl_device_disk_to_json(ctx, &disk); + printf("disk: %s\n", json); + free(json); if (ferror(stdout) || fflush(stdout)) { perror("stdout"); exit(-1); } return 0; } _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel From xen-devel-bounces@lists.xensource.com Thu Sep 29 09:24:23 2011 Return-path: <xen-devel-bounces@lists.xensource.com> Envelope-to: www-data@lists.xensource.com Delivery-date: Thu, 29 Sep 2011 09:24:23 -0700 Received: from localhost ([127.0.0.1] helo=lists.colo.xensource.com) by lists.xensource.com with esmtp (Exim 4.43) id 1R9JPL-0001fm-NQ; Thu, 29 Sep 2011 09:24:23 -0700 Received: from mail216.messagelabs.com ([85.158.143.99]) by lists.xensource.com with esmtp (Exim 4.43) id 1R9JLh-0000LY-4X for xen-devel@lists.xensource.com; Thu, 29 Sep 2011 09:20:38 -0700 X-Env-Sender: Ian.Campbell@eu.citrix.com X-Msg-Ref: server-9.tower-216.messagelabs.com!1317313232!20052523!2 X-Originating-IP: [66.165.176.63] X-StarScan-Version: 6.4.1; banners=-,-,- X-VirusChecked: Checked Received: (qmail 10776 invoked from network); 29 Sep 2011 16:20:33 -0000 Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63) by server-9.tower-216.messagelabs.com with RC4-SHA encrypted SMTP; 29 Sep 2011 16:20:33 -0000 X-IronPort-AV: E=Sophos;i="4.68,462,1312171200"; d="scan'208";a="165161524" Received: from ftlpmailmx02.citrite.net ([10.13.107.66]) by FTLPIPO02.CITRIX.COM with ESMTP/TLS/RC4-MD5; 29 Sep 2011 12:20:33 -0400 Received: from smtp01.ad.xensource.com (10.219.128.104) by smtprelay.citrix.com (10.13.107.66) with Microsoft SMTP Server id 8.3.137.0; Thu, 29 Sep 2011 12:20:33 -0400 Received: from localhost.localdomain (cosworth.uk.xensource.com [10.80.16.52]) by smtp01.ad.xensource.com (8.13.1/8.13.1) with ESMTP id p8TGKSAg026204; Thu, 29 Sep 2011 09:20:32 -0700 Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Mercurial-Node: 6056b382a44fd94ead9523a098855830c400ee54 Message-ID: <6056b382a44fd94ead95.1317313231@localhost.localdomain> In-Reply-To: <patchbomb.1317313227@localhost.localdomain> References: <patchbomb.1317313227@localhost.localdomain> User-Agent: Mercurial-patchbomb/1.6.4 Date: Thu, 29 Sep 2011 17:20:31 +0100 From: Ian Campbell <ian.campbell@citrix.com> To: xen-devel@lists.xensource.com Cc: Ian Campbell <ian.campbell@citrix.com> Subject: [Xen-devel] [PATCH 4 of 6] libxl: undo 23728:548b2826293e whitespace cleanup to autogenerated file X-BeenThere: xen-devel@lists.xensource.com X-Mailman-Version: 2.1.5 Precedence: list List-Id: Xen developer discussion <xen-devel.lists.xensource.com> List-Unsubscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe> List-Post: <mailto:xen-devel@lists.xensource.com> List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help> List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=subscribe> Sender: xen-devel-bounces@lists.xensource.com Errors-To: xen-devel-bounces@lists.xensource.com # HG changeset patch # User Ian Campbell <ian.campbell@citrix.com> # Date 1317312932 -3600 # Node ID 6056b382a44fd94ead9523a098855830c400ee54 # Parent 6c2b62f0452a73811f708f162490cf7c1c247295 libxl: undo 23728:548b2826293e whitespace cleanup to autogenerated file Signed-off-by: Ian Campbell <ian.campbell@citrix.com> diff -r 6c2b62f0452a -r 6056b382a44f tools/libxl/libxlu_disk_l.c --- a/tools/libxl/libxlu_disk_l.c Thu Sep 29 17:15:15 2011 +0100 +++ b/tools/libxl/libxlu_disk_l.c Thu Sep 29 17:15:32 2011 +0100 @@ -34,7 +34,7 @@ #if defined (__STDC_VERSION__) && __STDC_VERSION__ >= 199901L /* C99 says to define __STDC_LIMIT_MACROS before including stdint.h, - * if you want the limit (max/min) macros for int types. + * if you want the limit (max/min) macros for int types. */ #ifndef __STDC_LIMIT_MACROS #define __STDC_LIMIT_MACROS 1 @@ -51,7 +51,7 @@ typedef uint32_t flex_uint32_t; typedef signed char flex_int8_t; typedef short int flex_int16_t; typedef int flex_int32_t; -typedef unsigned char flex_uint8_t; +typedef unsigned char flex_uint8_t; typedef unsigned short int flex_uint16_t; typedef unsigned int flex_uint32_t; @@ -184,7 +184,7 @@ typedef struct yy_buffer_state *YY_BUFFE #define EOB_ACT_LAST_MATCH 2 #define YY_LESS_LINENO(n) - + /* Return all but the first "n" matched characters back to the input stream. */ #define yyless(n) \ do \ @@ -246,7 +246,7 @@ struct yy_buffer_state int yy_bs_lineno; /**< The line count. */ int yy_bs_column; /**< The column count. */ - + /* Whether to try to fill the input buffer when we reach the * end of it. */ @@ -1869,7 +1869,7 @@ static void xlu__disk_yy_load_buffer_sta YY_BUFFER_STATE xlu__disk_yy_create_buffer (FILE * file, int size , yyscan_t yyscanner) { YY_BUFFER_STATE b; - + b = (YY_BUFFER_STATE) xlu__disk_yyalloc(sizeof( struct yy_buffer_state ) ,yyscanner ); if ( ! b ) YY_FATAL_ERROR( "out of dynamic memory in xlu__disk_yy_create_buffer()" ); @@ -1913,7 +1913,7 @@ static void xlu__disk_yy_load_buffer_sta #ifndef __cplusplus extern int isatty (int ); #endif /* __cplusplus */ - + /* Initializes or reinitializes a buffer. * This function is sometimes called more than once on the same buffer, * such as during a xlu__disk_yyrestart() or at EOF. @@ -1939,7 +1939,7 @@ extern int isatty (int ); } b->yy_is_interactive = file ? (isatty( fileno(file) ) > 0) : 0; - + errno = oerrno; } @@ -2045,9 +2045,9 @@ static void xlu__disk_yyensure_buffer_st , yyscanner); if ( ! yyg->yy_buffer_stack ) YY_FATAL_ERROR( "out of dynamic memory in xlu__disk_yyensure_buffer_stack()" ); - + memset(yyg->yy_buffer_stack, 0, num_to_alloc * sizeof(struct yy_buffer_state*)); - + yyg->yy_buffer_stack_max = num_to_alloc; yyg->yy_buffer_stack_top = 0; return; @@ -2076,12 +2076,12 @@ static void xlu__disk_yyensure_buffer_st * @param base the character buffer * @param size the size in bytes of the character buffer * @param yyscanner The scanner object. - * @return the newly allocated buffer state object. + * @return the newly allocated buffer state object. */ YY_BUFFER_STATE xlu__disk_yy_scan_buffer (char * base, yy_size_t size , yyscan_t yyscanner) { YY_BUFFER_STATE b; - + if ( size < 2 || base[size-2] != YY_END_OF_BUFFER_CHAR || base[size-1] != YY_END_OF_BUFFER_CHAR ) @@ -2117,7 +2117,7 @@ YY_BUFFER_STATE xlu__disk_yy_scan_buffer */ YY_BUFFER_STATE xlu__disk_yy_scan_string (yyconst char * yystr , yyscan_t yyscanner) { - + return xlu__disk_yy_scan_bytes(yystr,strlen(yystr) ,yyscanner); } @@ -2134,7 +2134,7 @@ YY_BUFFER_STATE xlu__disk_yy_scan_bytes char *buf; yy_size_t n; int i; - + /* Get memory for full buffer, including space for trailing EOB's. */ n = _yybytes_len + 2; buf = (char *) xlu__disk_yyalloc(n ,yyscanner ); @@ -2202,10 +2202,10 @@ YY_EXTRA_TYPE xlu__disk_yyget_extra (yy int xlu__disk_yyget_lineno (yyscan_t yyscanner) { struct yyguts_t * yyg = (struct yyguts_t*)yyscanner; - + if (! YY_CURRENT_BUFFER) return 0; - + return yylineno; } @@ -2215,10 +2215,10 @@ int xlu__disk_yyget_lineno (yyscan_t yy int xlu__disk_yyget_column (yyscan_t yyscanner) { struct yyguts_t * yyg = (struct yyguts_t*)yyscanner; - + if (! YY_CURRENT_BUFFER) return 0; - + return yycolumn; } @@ -2279,8 +2279,8 @@ void xlu__disk_yyset_lineno (int line_n /* lineno is only valid if an input buffer exists. */ if (! YY_CURRENT_BUFFER ) - yy_fatal_error( "xlu__disk_yyset_lineno called with no buffer" , yyscanner); - + yy_fatal_error( "xlu__disk_yyset_lineno called with no buffer" , yyscanner); + yylineno = line_number; } @@ -2294,8 +2294,8 @@ void xlu__disk_yyset_column (int column /* column is only valid if an input buffer exists. */ if (! YY_CURRENT_BUFFER ) - yy_fatal_error( "xlu__disk_yyset_column called with no buffer" , yyscanner); - + yy_fatal_error( "xlu__disk_yyset_column called with no buffer" , yyscanner); + yycolumn = column_no; } @@ -2378,20 +2378,20 @@ int xlu__disk_yylex_init_extra(YY_EXTRA_ errno = EINVAL; return 1; } - + *ptr_yy_globals = (yyscan_t) xlu__disk_yyalloc ( sizeof( struct yyguts_t ), &dummy_yyguts ); - + if (*ptr_yy_globals == NULL){ errno = ENOMEM; return 1; } - + /* By setting to 0xAA, we expose bugs in yy_init_globals. Leave at 0x00 for releases. */ memset(*ptr_yy_globals,0x00,sizeof(struct yyguts_t)); - + xlu__disk_yyset_extra (yy_user_defined, *ptr_yy_globals); - + return yy_init_globals ( *ptr_yy_globals ); } diff -r 6c2b62f0452a -r 6056b382a44f tools/libxl/libxlu_disk_l.h --- a/tools/libxl/libxlu_disk_l.h Thu Sep 29 17:15:15 2011 +0100 +++ b/tools/libxl/libxlu_disk_l.h Thu Sep 29 17:15:32 2011 +0100 @@ -38,7 +38,7 @@ #if defined (__STDC_VERSION__) && __STDC_VERSION__ >= 199901L /* C99 says to define __STDC_LIMIT_MACROS before including stdint.h, - * if you want the limit (max/min) macros for int types. + * if you want the limit (max/min) macros for int types. */ #ifndef __STDC_LIMIT_MACROS #define __STDC_LIMIT_MACROS 1 @@ -55,7 +55,7 @@ typedef uint32_t flex_uint32_t; typedef signed char flex_int8_t; typedef short int flex_int16_t; typedef int flex_int32_t; -typedef unsigned char flex_uint8_t; +typedef unsigned char flex_uint8_t; typedef unsigned short int flex_uint16_t; typedef unsigned int flex_uint32_t; @@ -193,7 +193,7 @@ struct yy_buffer_state int yy_bs_lineno; /**< The line count. */ int yy_bs_column; /**< The column count. */ - + /* Whether to try to fill the input buffer when we reach the * end of it. */ _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel From xen-devel-bounces@lists.xensource.com Thu Sep 29 09:25:41 2011 Return-path: <xen-devel-bounces@lists.xensource.com> Envelope-to: www-data@lists.xensource.com Delivery-date: Thu, 29 Sep 2011 09:25:41 -0700 Received: from localhost ([127.0.0.1] helo=lists.colo.xensource.com) by lists.xensource.com with esmtp (Exim 4.43) id 1R9JQb-000288-5w; Thu, 29 Sep 2011 09:25:41 -0700 Received: from mail216.messagelabs.com ([85.158.143.99]) by lists.xensource.com with esmtp (Exim 4.43) id 1R9JLi-0000Lf-N0 for xen-devel@lists.xensource.com; Thu, 29 Sep 2011 09:20:39 -0700 X-Env-Sender: Ian.Campbell@eu.citrix.com X-Msg-Ref: server-9.tower-216.messagelabs.com!1317313232!20052523!3 X-Originating-IP: [66.165.176.63] X-StarScan-Version: 6.4.1; banners=-,-,- X-VirusChecked: Checked Received: (qmail 10872 invoked from network); 29 Sep 2011 16:20:35 -0000 Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63) by server-9.tower-216.messagelabs.com with RC4-SHA encrypted SMTP; 29 Sep 2011 16:20:35 -0000 X-IronPort-AV: E=Sophos;i="4.68,462,1312171200"; d="scan'208";a="165161530" Received: from ftlpmailmx02.citrite.net ([10.13.107.66]) by FTLPIPO02.CITRIX.COM with ESMTP/TLS/RC4-MD5; 29 Sep 2011 12:20:35 -0400 Received: from smtp01.ad.xensource.com (10.219.128.104) by smtprelay.citrix.com (10.13.107.66) with Microsoft SMTP Server id 8.3.137.0; Thu, 29 Sep 2011 12:20:35 -0400 Received: from localhost.localdomain (cosworth.uk.xensource.com [10.80.16.52]) by smtp01.ad.xensource.com (8.13.1/8.13.1) with ESMTP id p8TGKSAi026204; Thu, 29 Sep 2011 09:20:34 -0700 Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Mercurial-Node: 966d33c61d0b1dcf8545253b198e185c3757bc65 Message-ID: <966d33c61d0b1dcf8545.1317313233@localhost.localdomain> In-Reply-To: <patchbomb.1317313227@localhost.localdomain> References: <patchbomb.1317313227@localhost.localdomain> User-Agent: Mercurial-patchbomb/1.6.4 Date: Thu, 29 Sep 2011 17:20:33 +0100 From: Ian Campbell <ian.campbell@citrix.com> To: xen-devel@lists.xensource.com Cc: Ian Campbell <ian.campbell@citrix.com> Subject: [Xen-devel] [PATCH 6 of 6] libxl: probe disk backend type in libxl_device_disk_add X-BeenThere: xen-devel@lists.xensource.com X-Mailman-Version: 2.1.5 Precedence: list List-Id: Xen developer discussion <xen-devel.lists.xensource.com> List-Unsubscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe> List-Post: <mailto:xen-devel@lists.xensource.com> List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help> List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=subscribe> Sender: xen-devel-bounces@lists.xensource.com Errors-To: xen-devel-bounces@lists.xensource.com # HG changeset patch # User Ian Campbell <ian.campbell@citrix.com> # Date 1317313222 -3600 # Node ID 966d33c61d0b1dcf8545253b198e185c3757bc65 # Parent 50cd0fd187b39a263680d8a4b4f1a8511c7c04ee libxl: probe disk backend type in libxl_device_disk_add Without this "xl block-attach" does not work. On create do_domain_create already catches this. Signed-off-by: Ian Campbell <ian.campbell@citrix.com> diff -r 50cd0fd187b3 -r 966d33c61d0b tools/libxl/libxl.c --- a/tools/libxl/libxl.c Thu Sep 29 17:17:14 2011 +0100 +++ b/tools/libxl/libxl.c Thu Sep 29 17:20:22 2011 +0100 @@ -926,6 +926,9 @@ int libxl_device_disk_add(libxl_ctx *ctx libxl__device device; int major, minor, rc; + rc = libxl__device_disk_set_backend(&gc, disk); + if (rc) goto out; + front = flexarray_make(16, 1); if (!front) { rc = ERROR_NOMEM; _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel From xen-devel-bounces@lists.xensource.com Thu Sep 29 09:26:29 2011 Return-path: <xen-devel-bounces@lists.xensource.com> Envelope-to: www-data@lists.xensource.com Delivery-date: Thu, 29 Sep 2011 09:26:29 -0700 Received: from localhost ([127.0.0.1] helo=lists.colo.xensource.com) by lists.xensource.com with esmtp (Exim 4.43) id 1R9JRM-0002Wp-QC; Thu, 29 Sep 2011 09:26:28 -0700 Received: from mail216.messagelabs.com ([85.158.143.99]) by lists.xensource.com with esmtp (Exim 4.43) id 1R9JLh-0000LZ-QD for xen-devel@lists.xensource.com; Thu, 29 Sep 2011 09:20:40 -0700 X-Env-Sender: Ian.Campbell@eu.citrix.com X-Msg-Ref: server-3.tower-216.messagelabs.com!1317313230!19009782!4 X-Originating-IP: [66.165.176.89] X-StarScan-Version: 6.4.1; banners=-,-,- X-VirusChecked: Checked Received: (qmail 9757 invoked from network); 29 Sep 2011 16:20:34 -0000 Received: from smtp.citrix.com (HELO SMTP.CITRIX.COM) (66.165.176.89) by server-3.tower-216.messagelabs.com with RC4-SHA encrypted SMTP; 29 Sep 2011 16:20:34 -0000 X-IronPort-AV: E=Sophos;i="4.68,462,1312171200"; d="scan'208";a="17812864" Received: from ftlpmailmx02.citrite.net ([10.13.107.66]) by FTLPIPO01.CITRIX.COM with ESMTP/TLS/RC4-MD5; 29 Sep 2011 12:20:34 -0400 Received: from smtp01.ad.xensource.com (10.219.128.104) by smtprelay.citrix.com (10.13.107.66) with Microsoft SMTP Server id 8.3.137.0; Thu, 29 Sep 2011 12:20:34 -0400 Received: from localhost.localdomain (cosworth.uk.xensource.com [10.80.16.52]) by smtp01.ad.xensource.com (8.13.1/8.13.1) with ESMTP id p8TGKSAh026204; Thu, 29 Sep 2011 09:20:33 -0700 Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Mercurial-Node: 50cd0fd187b39a263680d8a4b4f1a8511c7c04ee Message-ID: <50cd0fd187b39a263680.1317313232@localhost.localdomain> In-Reply-To: <patchbomb.1317313227@localhost.localdomain> References: <patchbomb.1317313227@localhost.localdomain> User-Agent: Mercurial-patchbomb/1.6.4 Date: Thu, 29 Sep 2011 17:20:32 +0100 From: Ian Campbell <ian.campbell@citrix.com> To: xen-devel@lists.xensource.com Cc: Ian Campbell <ian.campbell@citrix.com> Subject: [Xen-devel] [PATCH 5 of 6] libxlu: correctly parse disk "backendtype" field X-BeenThere: xen-devel@lists.xensource.com X-Mailman-Version: 2.1.5 Precedence: list List-Id: Xen developer discussion <xen-devel.lists.xensource.com> List-Unsubscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe> List-Post: <mailto:xen-devel@lists.xensource.com> List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help> List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=subscribe> Sender: xen-devel-bounces@lists.xensource.com Errors-To: xen-devel-bounces@lists.xensource.com # HG changeset patch # User Ian Campbell <ian.campbell@citrix.com> # Date 1317313034 -3600 # Node ID 50cd0fd187b39a263680d8a4b4f1a8511c7c04ee # Parent 6056b382a44fd94ead9523a098855830c400ee54 libxlu: correctly parse disk "backendtype" field Currently it tries to parse the value from the full "backendtype=FOO" string but really it needs to parse from the equals. Before: # xl -N block-attach d32-1 backendtype=phy,vdev=xvdb,access=w,target=/dev/VG/debian-x86_32-1b command line: config parsing error in disk specification: unknown value for backendtype: near `backendtype=phy' in `backendtype=phy,vdev=xvdb,access=w,target=/dev/VG/debian-x86_32-1b' After: # xl -N block-attach d32-1 backendtype=phy,vdev=xvdb,access=w,target=/dev/VG/debian-x86_32-1b disk: { "backend_domid": 0, "pdev_path": "/dev/VG/debian-x86_32-1b", "vdev": "xvdb", "backend": "phy", "format": "raw", "script": null, "removable": 0, "readwrite": 1, "is_cdrom": 0 } Signed-off-by: Ian Campbell <ian.campbell@citrix.com> diff -r 6056b382a44f -r 50cd0fd187b3 tools/libxl/check-xl-disk-parse --- a/tools/libxl/check-xl-disk-parse Thu Sep 29 17:15:32 2011 +0100 +++ b/tools/libxl/check-xl-disk-parse Thu Sep 29 17:17:14 2011 +0100 @@ -91,4 +91,20 @@ one 0 "format=raw, vdev=hdc, access=ro, one 0 format=raw vdev=hdc access=ro devtype=cdrom target=/root/image.iso one 0 raw:/root/image.iso,hdc:cdrom,ro +expected <<EOF +disk: { + "backend_domid": 0, + "pdev_path": "/dev/vg/guest-volume", + "vdev": "xvdb", + "backend": "phy", + "format": "raw", + "script": null, + "removable": 0, + "readwrite": 1, + "is_cdrom": 0 +} + +EOF +one 0 backendtype=phy,vdev=xvdb,access=w,target=/dev/vg/guest-volume + complete diff -r 6056b382a44f -r 50cd0fd187b3 tools/libxl/libxlu_disk_l.c --- a/tools/libxl/libxlu_disk_l.c Thu Sep 29 17:15:32 2011 +0100 +++ b/tools/libxl/libxlu_disk_l.c Thu Sep 29 17:17:14 2011 +0100 @@ -1261,7 +1261,7 @@ case 8: /* rule 8 can match eol */ YY_RULE_SETUP #line 142 "libxlu_disk_l.l" -{ STRIP(','); setbackendtype(DPC,yytext); } +{ STRIP(','); setbackendtype(DPC,FROMEQUALS); } YY_BREAK case 9: /* rule 9 can match eol */ diff -r 6056b382a44f -r 50cd0fd187b3 tools/libxl/libxlu_disk_l.l --- a/tools/libxl/libxlu_disk_l.l Thu Sep 29 17:15:32 2011 +0100 +++ b/tools/libxl/libxlu_disk_l.l Thu Sep 29 17:17:14 2011 +0100 @@ -139,7 +139,7 @@ devtype=disk,? { DPC->disk->is_cdrom = 0 devtype=[^,]*,? { xlu__disk_err(DPC,yytext,"unknown value for type"); } access=[^,]*,? { STRIP(','); setaccess(DPC, FROMEQUALS); } -backendtype=[^,]*? { STRIP(','); setbackendtype(DPC,yytext); } +backendtype=[^,]*? { STRIP(','); setbackendtype(DPC,FROMEQUALS); } vdev=[^,]*,? { STRIP(','); SAVESTRING("vdev", vdev, FROMEQUALS); } script=[^,]*,? { STRIP(','); SAVESTRING("script", script, FROMEQUALS); } _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel From xen-devel-bounces@lists.xensource.com Thu Sep 29 09:27:16 2011 Return-path: <xen-devel-bounces@lists.xensource.com> Envelope-to: www-data@lists.xensource.com Delivery-date: Thu, 29 Sep 2011 09:27:16 -0700 Received: from localhost ([127.0.0.1] helo=lists.colo.xensource.com) by lists.xensource.com with esmtp (Exim 4.43) id 1R9JS8-0002tc-Bx; Thu, 29 Sep 2011 09:27:16 -0700 Received: from mail216.messagelabs.com ([85.158.143.99]) by lists.xensource.com with esmtp (Exim 4.43) id 1R9JLg-0000LU-0K for xen-devel@lists.xensource.com; Thu, 29 Sep 2011 09:20:39 -0700 X-Env-Sender: Ian.Campbell@eu.citrix.com X-Msg-Ref: server-3.tower-216.messagelabs.com!1317313230!19009782!2 X-Originating-IP: [66.165.176.89] X-StarScan-Version: 6.4.1; banners=-,-,- X-VirusChecked: Checked Received: (qmail 9653 invoked from network); 29 Sep 2011 16:20:32 -0000 Received: from smtp.citrix.com (HELO SMTP.CITRIX.COM) (66.165.176.89) by server-3.tower-216.messagelabs.com with RC4-SHA encrypted SMTP; 29 Sep 2011 16:20:32 -0000 X-IronPort-AV: E=Sophos;i="4.68,462,1312171200"; d="scan'208";a="17812855" Received: from ftlpmailmx02.citrite.net ([10.13.107.66]) by FTLPIPO01.CITRIX.COM with ESMTP/TLS/RC4-MD5; 29 Sep 2011 12:20:31 -0400 Received: from smtp01.ad.xensource.com (10.219.128.104) by smtprelay.citrix.com (10.13.107.66) with Microsoft SMTP Server id 8.3.137.0; Thu, 29 Sep 2011 12:20:30 -0400 Received: from localhost.localdomain (cosworth.uk.xensource.com [10.80.16.52]) by smtp01.ad.xensource.com (8.13.1/8.13.1) with ESMTP id p8TGKSAd026204; Thu, 29 Sep 2011 09:20:29 -0700 Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Mercurial-Node: 030e844fccebcc3984c5792559c0cbd5424d277a Message-ID: <030e844fccebcc3984c5.1317313228@localhost.localdomain> In-Reply-To: <patchbomb.1317313227@localhost.localdomain> References: <patchbomb.1317313227@localhost.localdomain> User-Agent: Mercurial-patchbomb/1.6.4 Date: Thu, 29 Sep 2011 17:20:28 +0100 From: Ian Campbell <ian.campbell@citrix.com> To: xen-devel@lists.xensource.com Cc: Ian Campbell <ian.campbell@citrix.com> Subject: [Xen-devel] [PATCH 1 of 6] libxl: IDL: autogenerate functions to produce JSON from libxl data structures X-BeenThere: xen-devel@lists.xensource.com X-Mailman-Version: 2.1.5 Precedence: list List-Id: Xen developer discussion <xen-devel.lists.xensource.com> List-Unsubscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe> List-Post: <mailto:xen-devel@lists.xensource.com> List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help> List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=subscribe> Sender: xen-devel-bounces@lists.xensource.com Errors-To: xen-devel-bounces@lists.xensource.com # HG changeset patch # User Ian Campbell <ian.campbell@citrix.com> # Date 1317312134 -3600 # Node ID 030e844fccebcc3984c5792559c0cbd5424d277a # Parent fb42038b1f5cd4f72c5cfff6e5f8ffa46f2fa0b2 libxl: IDL: autogenerate functions to produce JSON from libxl data structures. Two functions are provided. TYPE_gen_json exposes an interface which is compatible with the YAGL generator infrastructure. TYPE_to_string uses this to produce a pretty printed string. The TYPE_gen_json functions are defined in a new header libxl_json.h which is not exposed via libxl.h due to the use of YAGL datatypes to avoid poluting the namespace us libxl users which don't use the library themselves. If a libxl user is interested in integrating at the YAGL level then it should #include this file itself. Also update testidl to generate a random version of each IDL datastructure and convert it to JSON. Unfortunately this requires a libxl_ctx and therefore the test must be run on a Xen system now. Signed-off-by: Ian Campbell <ian.campbell@citrix.com> diff -r fb42038b1f5c -r 030e844fcceb tools/libxl/Makefile --- a/tools/libxl/Makefile Thu Sep 29 16:57:52 2011 +0100 +++ b/tools/libxl/Makefile Thu Sep 29 17:02:14 2011 +0100 @@ -84,14 +84,17 @@ _libxl_paths.h: genpath libxl_paths.c: _libxl_paths.h libxl.h: _libxl_types.h +libxl_json.h: _libxl_types_json.h libxl_internal.h: _libxl_types_internal.h +libxl_internal_json.h: _libxl_types_internal_json.h $(LIBXL_OBJS) $(LIBXLU_OBJS) $(XL_OBJS): libxl.h $(LIBXL_OBJS): libxl_internal.h -_libxl_type%.h _libxl_type%.c: libxl_type%.idl gentypes.py libxltypes.py - $(PYTHON) gentypes.py libxl_type$*.idl __libxl_type$*.h __libxl_type$*.c +_libxl_type%.h _libxl_type%_json.h _libxl_type%.c: libxl_type%.idl gentypes.py libxltypes.py + $(PYTHON) gentypes.py libxl_type$*.idl __libxl_type$*.h __libxl_type$*_json.h __libxl_type$*.c $(call move-if-changed,__libxl_type$*.h,_libxl_type$*.h) + $(call move-if-changed,__libxl_type$*_json.h,_libxl_type$*_json.h) $(call move-if-changed,__libxl_type$*.c,_libxl_type$*.c) libxenlight.so: libxenlight.so.$(MAJOR) @@ -140,7 +143,7 @@ install: all ln -sf libxlutil.so.$(XLUMAJOR).$(XLUMINOR) $(DESTDIR)$(LIBDIR)/libxlutil.so.$(XLUMAJOR) ln -sf libxlutil.so.$(XLUMAJOR) $(DESTDIR)$(LIBDIR)/libxlutil.so $(INSTALL_DATA) libxlutil.a $(DESTDIR)$(LIBDIR) - $(INSTALL_DATA) libxl.h _libxl_types.h libxl_utils.h libxl_uuid.h $(DESTDIR)$(INCLUDEDIR) + $(INSTALL_DATA) libxl.h libxl_json.h _libxl_types.h _libxl_types_json.h libxl_utils.h libxl_uuid.h $(DESTDIR)$(INCLUDEDIR) $(INSTALL_DATA) bash-completion $(DESTDIR)$(BASH_COMPLETION_DIR)/xl.sh .PHONY: clean diff -r fb42038b1f5c -r 030e844fcceb tools/libxl/gentest.py --- a/tools/libxl/gentest.py Thu Sep 29 16:57:52 2011 +0100 +++ b/tools/libxl/gentest.py Thu Sep 29 17:02:14 2011 +0100 @@ -5,6 +5,7 @@ import re import random import libxltypes + def randomize_char(c): if random.random() < 0.5: return str.lower(c) @@ -15,6 +16,50 @@ def randomize_case(s): r = [randomize_char(c) for c in s] return "".join(r) +def randomize_enum(e): + return random.choice([v.name for v in e.values]) + +handcoded = ["libxl_cpumap", "libxl_key_value_list", + "libxl_cpuid_policy_list", "libxl_file_reference", + "libxl_string_list", "libxl_cpuarray"] + +def gen_rand_init(ty, v, indent = " ", parent = None): + s = "" + if isinstance(ty, libxltypes.Enumeration): + s += "%s = %s;\n" % (ty.pass_arg(v, parent is None), randomize_enum(ty)) + elif isinstance(ty, libxltypes.KeyedUnion): + if parent is None: + raise Exception("KeyedUnion type must have a parent") + s += "switch (%s) {\n" % (parent + ty.keyvar_name) + for f in ty.fields: + (nparent,fexpr) = ty.member(v, f, parent is None) + s += "case %s:\n" % f.enumname + s += gen_rand_init(f.type, fexpr, indent + " ", nparent) + s += " break;\n" + s += "}\n" + elif isinstance(ty, libxltypes.Struct) and (parent is None or ty.json_fn is None): + for f in [f for f in ty.fields if not f.const]: + (nparent,fexpr) = ty.member(v, f, parent is None) + s += gen_rand_init(f.type, fexpr, "", nparent) + elif hasattr(ty, "rand_init") and ty.rand_init is not None: + s += "%s(%s);\n" % (ty.rand_init, ty.pass_arg(v, isref=parent is None, passby=libxltypes.PASS_BY_REFERENCE)) + elif ty.typename in ["libxl_uuid", "libxl_mac", "libxl_hwcap"]: + s += "rand_bytes((uint8_t *)%s, sizeof(*%s));\n" % (v,v) + elif ty.typename in ["libxl_domid"] or isinstance(ty, libxltypes.Number): + s += "%s = rand() %% (sizeof(%s)*8);\n" % (ty.pass_arg(v, parent is None), ty.pass_arg(v, parent is None)) + elif ty.typename in ["bool"]: + s += "%s = rand() %% 2;\n" % v + elif ty.typename in ["char *"]: + s += "%s = rand_str();\n" % v + elif ty.typename in handcoded: + raise Exception("Gen for handcoded %s" % ty.typename) + else: + raise Exception("Cannot randomly init %s" % ty.typename) + + if s != "": + s = indent + s + return s.replace("\n", "\n%s" % indent).rstrip(indent) + if __name__ == '__main__': if len(sys.argv) < 3: print >>sys.stderr, "Usage: gentest.py <idl> <implementation>" @@ -23,23 +68,191 @@ if __name__ == '__main__': random.seed() idl = sys.argv[1] - (_,types) = libxltypes.parse(idl) + (builtins,types) = libxltypes.parse(idl) impl = sys.argv[2] f = open(impl, "w") f.write(""" #include <stdio.h> +#include <stdlib.h> +#include <string.h> + #include \"libxl.h\" +#include \"libxl_utils.h\" +static char *rand_str(void) +{ + int i, sz = rand() % 32; + char *s = malloc(sz+1); + for (i=0; i<sz; i++) + s[i] = 'a' + (rand() % 26); + s[i] = '\\0'; + return s; +} + +static void rand_bytes(uint8_t *p, size_t sz) +{ + int i; + for (i=0; i<sz; i++) + p[i] = rand() % 256; + //p[i] = i; +} + +static void libxl_cpumap_rand_init(libxl_cpumap *cpumap) +{ + int i; + cpumap->size = rand() % 16; + cpumap->map = calloc(cpumap->size, sizeof(*cpumap->map)); + libxl_for_each_cpu(i, *cpumap) { + if (rand() % 2) + libxl_cpumap_set(cpumap, i); + else + libxl_cpumap_reset(cpumap, i); + } +} + +static void libxl_key_value_list_rand_init(libxl_key_value_list *pkvl) +{ + int i, nr_kvp = rand() % 16; + libxl_key_value_list kvl = calloc(nr_kvp+1, 2*sizeof(char *)); + + for (i = 0; i<2*nr_kvp; i += 2) { + kvl[i] = rand_str(); + if (rand() % 8) + kvl[i+1] = rand_str(); + else + kvl[i+1] = NULL; + } + kvl[i] = NULL; + kvl[i+1] = NULL; + *pkvl = kvl; +} + +static void libxl_cpuid_policy_list_rand_init(libxl_cpuid_policy_list *pp) +{ + int i, nr_policies = rand() % 16; + struct { + const char *n; + int w; + } options[] = { + /* A random selection from libxl_cpuid_parse_config */ + {"maxleaf", 32}, + {"family", 8}, + {"model", 8}, + {"stepping", 4}, + {"localapicid", 8}, + {"proccount", 8}, + {"clflush", 8}, + {"brandid", 8}, + {"f16c", 1}, + {"avx", 1}, + {"osxsave", 1}, + {"xsave", 1}, + {"aes", 1}, + {"popcnt", 1}, + {"movbe", 1}, + {"x2apic", 1}, + {"sse4.2", 1}, + {"sse4.1", 1}, + {"dca", 1}, + {"pdcm", 1}, + {"procpkg", 6}, + }; + const int nr_options = sizeof(options)/sizeof(options[0]); + char buf[64]; + libxl_cpuid_policy_list p = NULL; + + for (i = 0; i < nr_policies; i++) { + int opt = rand() % nr_options; + int val = rand() % (1<<options[opt].w); + snprintf(buf, 64, "%s=%#x", options[opt].n, val); + libxl_cpuid_parse_config(&p, buf); + } + *pp = p; +} + +static void libxl_file_reference_rand_init(libxl_file_reference *p) +{ + memset(p, 0, sizeof(*p)); + if (rand() % 8) + p->path = rand_str(); +} + +static void libxl_string_list_rand_init(libxl_string_list *p) +{ + int i, nr = rand() % 16; + libxl_string_list l = calloc(nr+1, sizeof(char *)); + + for (i = 0; i<nr; i++) { + l[i] = rand_str(); + } + l[i] = NULL; + *p = l; +} + +static void libxl_cpuarray_rand_init(libxl_cpuarray *p) +{ + int i; + /* Up to 16 VCPUs on 32 PCPUS */ + p->entries = rand() % 16; + p->array = calloc(p->entries, sizeof(*p->array)); + for (i = 0; i < p->entries; i++) { + int r = rand() % 32*1.5; /* 2:1 valid:invalid */ + if (r >= 32) + p->array[i] = LIBXL_CPUARRAY_INVALID_ENTRY; + else + p->array[i] = r; + } +} +""") + for ty in builtins + types: + if ty.typename not in handcoded: + f.write("static void %s_rand_init(%s);\n" % (ty.typename, ty.make_arg("p", passby=libxltypes.PASS_BY_REFERENCE))) + f.write("static void %s_rand_init(%s)\n" % (ty.typename, ty.make_arg("p", passby=libxltypes.PASS_BY_REFERENCE))) + f.write("{\n") + f.write(gen_rand_init(ty, "p")) + f.write("}\n") + f.write("\n") + ty.rand_init = "%s_rand_init" % ty.typename + + f.write(""" int main(int argc, char **argv) { """) - for ty in [t for t in types if isinstance(t,libxltypes.Enumeration)]: + for ty in types: f.write(" %s %s_val;\n" % (ty.typename, ty.typename)) - f.write(" int rc;\n") - f.write("\n") + f.write(""" + int rc; + char *s; + xentoollog_logger_stdiostream *logger; + libxl_ctx *ctx; + logger = xtl_createlogger_stdiostream(stderr, XTL_DETAIL, 0); + if (!logger) exit(1); + + if (libxl_ctx_alloc(&ctx, LIBXL_VERSION, (xentoollog_logger*)logger)) { + fprintf(stderr, "cannot init xl context\\n"); + exit(1); + } +""") + f.write(" printf(\"Testing TYPE_to_json()\\n\");\n") + f.write(" printf(\"----------------------\\n\");\n") + f.write(" printf(\"\\n\");\n") + for ty in [t for t in types if t.json_fn is not None]: + arg = ty.typename + "_val" + f.write(" %s_rand_init(%s);\n" % (ty.typename, ty.pass_arg(arg, isref=False, passby=libxltypes.PASS_BY_REFERENCE))) + f.write(" s = %s_to_json(ctx, %s);\n" % (ty.typename, ty.pass_arg(arg, isref=False))) + f.write(" printf(\"%%s: %%s\\n\", \"%s\", s);\n" % ty.typename) + f.write(" if (s == NULL) abort();\n") + f.write(" free(s);\n") + if ty.destructor_fn is not None: + f.write(" %s(&%s_val);\n" % (ty.destructor_fn, ty.typename)) + f.write("\n") + + f.write(" printf(\"Testing Enumerations\\n\");\n") + f.write(" printf(\"--------------------\\n\");\n") + f.write(" printf(\"\\n\");\n") for ty in [t for t in types if isinstance(t,libxltypes.Enumeration)]: f.write(" printf(\"%s -- to string:\\n\");\n" % (ty.typename)) for v in ty.values: @@ -47,6 +260,12 @@ int main(int argc, char **argv) (v.valuename, v.name, ty.typename, v.name)) f.write("\n") + f.write(" printf(\"%s -- to JSON:\\n\");\n" % (ty.typename)) + for v in ty.values: + f.write(" printf(\"\\t%s = %%d = %%s\", %s, %s_to_json(ctx, %s));\n" %\ + (v.valuename, v.name, ty.typename, v.name)) + f.write("\n") + f.write(" printf(\"%s -- from string:\\n\");\n" % (ty.typename)) for v in [v.valuename for v in ty.values] + ["AN INVALID VALUE"]: n = randomize_case(v) @@ -58,6 +277,11 @@ int main(int argc, char **argv) (v, n, ty.typename)) f.write("\n") - f.write("""return 0; + f.write(""" + + libxl_ctx_free(ctx); + xtl_logger_destroy((xentoollog_logger*)logger); + + return 0; } """) diff -r fb42038b1f5c -r 030e844fcceb tools/libxl/gentypes.py --- a/tools/libxl/gentypes.py Thu Sep 29 16:57:52 2011 +0100 +++ b/tools/libxl/gentypes.py Thu Sep 29 17:02:14 2011 +0100 @@ -29,7 +29,6 @@ def libxl_C_instance_of(ty, instancename def libxl_C_type_define(ty, indent = ""): s = "" - if isinstance(ty, libxltypes.Enumeration): if ty.comment is not None: s += format_comment(0, ty.comment) @@ -76,7 +75,6 @@ def libxl_C_type_define(ty, indent = "") return s.replace("\n", "\n%s" % indent) def libxl_C_type_destroy(ty, v, indent = " ", parent = None): - s = "" if isinstance(ty, libxltypes.KeyedUnion): if parent is None: @@ -100,6 +98,66 @@ def libxl_C_type_destroy(ty, v, indent = s = indent + s return s.replace("\n", "\n%s" % indent).rstrip(indent) +def libxl_C_type_gen_json(ty, v, indent = " ", parent = None): + s = "" + if parent is None: + s += "yajl_gen_status s;\n" + if isinstance(ty, libxltypes.Enumeration): + s += "{\n" + s += " const char *se = %s_to_string(%s);\n" % (ty.typename, ty.pass_arg(v, parent is None)) + s += " if (se)\n" + s += " s = yajl_gen_string(hand, (const unsigned char *)se, strlen(se));\n" + s += " else\n" + s += " s = yajl_gen_null(hand);\n" + s += " if (s != yajl_gen_status_ok)\n" + s += " goto out;\n" + s += "}\n" + elif isinstance(ty, libxltypes.KeyedUnion): + if parent is None: + raise Exception("KeyedUnion type must have a parent") + s += "switch (%s) {\n" % (parent + ty.keyvar_name) + for f in ty.fields: + (nparent,fexpr) = ty.member(v, f, parent is None) + s += "case %s:\n" % f.enumname + s += libxl_C_type_gen_json(f.type, fexpr, indent + " ", nparent) + s += " break;\n" + s += "}\n" + elif isinstance(ty, libxltypes.Struct) and (parent is None or ty.json_fn is None): + s += "s = yajl_gen_map_open(hand);\n" + s += "if (s != yajl_gen_status_ok)\n" + s += " goto out;\n" + for f in [f for f in ty.fields if not f.const]: + (nparent,fexpr) = ty.member(v, f, parent is None) + s += "s = yajl_gen_string(hand, (const unsigned char *)\"%s\", sizeof(\"%s\")-1);\n" % (f.name, f.name) + s += "if (s != yajl_gen_status_ok)\n" + s += " goto out;\n" + s += libxl_C_type_gen_json(f.type, fexpr, "", nparent) + s += "s = yajl_gen_map_close(hand);\n" + s += "if (s != yajl_gen_status_ok)\n" + s += " goto out;\n" + else: + if ty.json_fn is not None: + s += "s = %s(hand, %s);\n" % (ty.json_fn, ty.pass_arg(v, parent is None)) + s += "if (s != yajl_gen_status_ok)\n" + s += " goto out;\n" + + if parent is None: + s += "out:\n" + s += "return s;\n" + + if s != "": + s = indent + s + return s.replace("\n", "\n%s" % indent).rstrip(indent) + +def libxl_C_type_to_json(ty, v, indent = " "): + s = "" + gen = "(libxl__gen_json_callback)&%s_gen_json" % ty.typename + s += "return libxl__object_to_json(ctx, \"%s\", %s, (void *)%s);\n" % (ty.typename, gen, ty.pass_arg(v, passby=libxltypes.PASS_BY_REFERENCE)) + + if s != "": + s = indent + s + return s.replace("\n", "\n%s" % indent).rstrip(indent) + def libxl_C_enum_to_string(ty, e, indent = " "): s = "" s += "switch(%s) {\n" % e @@ -138,11 +196,11 @@ def libxl_C_enum_from_string(ty, str, e, if __name__ == '__main__': - if len(sys.argv) != 4: - print >>sys.stderr, "Usage: gentypes.py <idl> <header> <implementation>" + if len(sys.argv) != 5: + print >>sys.stderr, "Usage: gentypes.py <idl> <header> <header-json> <implementation>" sys.exit(1) - (_, idl, header, impl) = sys.argv + (_, idl, header, header_json, impl) = sys.argv (_,types) = libxltypes.parse(idl) @@ -167,6 +225,8 @@ if __name__ == '__main__': f.write(libxl_C_type_define(ty) + ";\n") if ty.destructor_fn is not None: f.write("void %s(%s);\n" % (ty.destructor_fn, ty.make_arg("p"))) + if ty.json_fn is not None: + f.write("char *%s_to_json(libxl_ctx *ctx, %s);\n" % (ty.typename, ty.make_arg("p"))) if isinstance(ty, libxltypes.Enumeration): f.write("const char *%s_to_string(%s);\n" % (ty.typename, ty.make_arg("p"))) f.write("int %s_from_string(const char *s, %s);\n" % (ty.typename, ty.make_arg("e", passby=libxltypes.PASS_BY_REFERENCE))) @@ -176,6 +236,30 @@ if __name__ == '__main__': f.write("""#endif /* %s */\n""" % (header_define)) f.close() + print "outputting libxl JSON definitions to %s" % header_json + + f = open(header_json, "w") + + header_json_define = header_json.upper().replace('.','_') + f.write("""#ifndef %s +#define %s + +/* + * DO NOT EDIT. + * + * This file is autogenerated by + * "%s" + */ + +""" % (header_json_define, header_json_define, " ".join(sys.argv))) + + for ty in [ty for ty in types if ty.json_fn is not None]: + f.write("yajl_gen_status %s_gen_json(yajl_gen hand, %s);\n" % (ty.typename, ty.make_arg("p", passby=libxltypes.PASS_BY_REFERENCE))) + + f.write("\n") + f.write("""#endif /* %s */\n""" % header_json_define) + f.close() + print "outputting libxl type implementations to %s" % impl f = open(impl, "w") @@ -222,5 +306,17 @@ if __name__ == '__main__': f.write("}\n") f.write("\n") + for ty in [t for t in types if t.json_fn is not None]: + f.write("yajl_gen_status %s_gen_json(yajl_gen hand, %s)\n" % (ty.typename, ty.make_arg("p", passby=libxltypes.PASS_BY_REFERENCE))) + f.write("{\n") + f.write(libxl_C_type_gen_json(ty, "p")) + f.write("}\n") + f.write("\n") + + f.write("char *%s_to_json(libxl_ctx *ctx, %s)\n" % (ty.typename, ty.make_arg("p"))) + f.write("{\n") + f.write(libxl_C_type_to_json(ty, "p")) + f.write("}\n") + f.write("\n") f.close() diff -r fb42038b1f5c -r 030e844fcceb tools/libxl/idl.txt --- a/tools/libxl/idl.txt Thu Sep 29 16:57:52 2011 +0100 +++ b/tools/libxl/idl.txt Thu Sep 29 17:02:14 2011 +0100 @@ -49,6 +49,15 @@ Type.autogenerate_destructor: (default: Indicates if the above named Type.destructor_fn should be autogenerated. +Type.json_fn: (default: typename + "_gen_json" or None if type == None) + + The name of the C function which will generate a YAJL data structure + representing this type. + +Type.autogenerate_json: (default: True) + + Indicates if the above named Type.json_fn should be autogenerated. + Other simple type-Classes ------------------------- diff -r fb42038b1f5c -r 030e844fcceb tools/libxl/libxl.h --- a/tools/libxl/libxl.h Thu Sep 29 16:57:52 2011 +0100 +++ b/tools/libxl/libxl.h Thu Sep 29 17:02:14 2011 +0100 @@ -199,10 +199,10 @@ typedef struct { int v; } libxl_enum_string_table; +typedef struct libxl__ctx libxl_ctx; + #include "_libxl_types.h" -typedef struct libxl__ctx libxl_ctx; - const libxl_version_info* libxl_get_version_info(libxl_ctx *ctx); typedef struct { diff -r fb42038b1f5c -r 030e844fcceb tools/libxl/libxl_internal.h --- a/tools/libxl/libxl_internal.h Thu Sep 29 16:57:52 2011 +0100 +++ b/tools/libxl/libxl_internal.h Thu Sep 29 17:02:14 2011 +0100 @@ -35,7 +35,9 @@ #include "flexarray.h" #include "libxl_utils.h" + #include "_libxl_types_internal.h" +#include "libxl_json.h" #define LIBXL_DESTROY_TIMEOUT 10 #define LIBXL_DEVICE_MODEL_START_TIMEOUT 10 @@ -337,6 +339,14 @@ _hidden char *libxl__cpupoolid_to_name(l _hidden int libxl__enum_from_string(const libxl_enum_string_table *t, const char *s, int *e); +_hidden yajl_gen_status libxl__yajl_gen_asciiz(yajl_gen hand, const char *str); + +_hidden yajl_gen_status libxl__string_gen_json(yajl_gen hand, const char *p); + +typedef yajl_gen_status (*libxl__gen_json_callback)(yajl_gen hand, void *); +_hidden char *libxl__object_to_json(libxl_ctx *ctx, const char *type, + libxl__gen_json_callback gen, void *p); + /* holds the CPUID response for a single CPUID leaf * input contains the value of the EAX and ECX register, * and each policy string contains a filter to apply to diff -r fb42038b1f5c -r 030e844fcceb tools/libxl/libxl_json.c --- a/tools/libxl/libxl_json.c Thu Sep 29 16:57:52 2011 +0100 +++ b/tools/libxl/libxl_json.c Thu Sep 29 17:02:14 2011 +0100 @@ -18,6 +18,7 @@ #include <yajl/yajl_parse.h> #include <yajl/yajl_gen.h> +#include <libxl.h> #include "libxl_internal.h" /* #define DEBUG_ANSWER */ @@ -71,6 +72,207 @@ yajl_gen_status libxl__yajl_gen_asciiz(y return yajl_gen_string(hand, (const unsigned char *)str, strlen(str)); } +/* + * YAJL generators for builtin libxl types. + */ +yajl_gen_status libxl_uuid_gen_json(yajl_gen hand, + libxl_uuid *uuid) +{ + char buf[LIBXL_UUID_FMTLEN+1]; + snprintf(buf, sizeof(buf), LIBXL_UUID_FMT, LIBXL_UUID_BYTES((*uuid))); + return yajl_gen_string(hand, (const unsigned char *)buf, LIBXL_UUID_FMTLEN); +} + +yajl_gen_status libxl_cpumap_gen_json(yajl_gen hand, + libxl_cpumap *cpumap) +{ + yajl_gen_status s; + int i; + + s = yajl_gen_array_open(hand); + if (s != yajl_gen_status_ok) goto out; + + libxl_for_each_cpu(i, *cpumap) { + if (libxl_cpumap_test(cpumap, i)) { + s = yajl_gen_integer(hand, i); + if (s != yajl_gen_status_ok) goto out; + } + } + s = yajl_gen_array_close(hand); +out: + return s; +} + +yajl_gen_status libxl_key_value_list_gen_json(yajl_gen hand, + libxl_key_value_list *pkvl) +{ + libxl_key_value_list kvl = *pkvl; + yajl_gen_status s; + int i; + + s = yajl_gen_map_open(hand); + if (s != yajl_gen_status_ok) goto out; + + if (!kvl) goto empty; + + for (i = 0; kvl[i] != NULL; i += 2) { + s = libxl__yajl_gen_asciiz(hand, kvl[i]); + if (s != yajl_gen_status_ok) goto out; + if (kvl[i + 1]) + s = libxl__yajl_gen_asciiz(hand, kvl[i+1]); + else + s = yajl_gen_null(hand); + if (s != yajl_gen_status_ok) goto out; + } +empty: + s = yajl_gen_map_close(hand); +out: + return s; +} + +yajl_gen_status libxl_cpuid_policy_list_gen_json(yajl_gen hand, + libxl_cpuid_policy_list *pcpuid) +{ + libxl_cpuid_policy_list cpuid = *pcpuid; + yajl_gen_status s; + const char *input_names[2] = { "leaf", "subleaf" }; + const char *policy_names[4] = { "eax", "ebx", "ecx", "edx" }; + int i, j; + + /* + * Aiming for: + * [ + * { 'leaf': 'val-eax', + * 'subleaf': 'val-edx', + * 'ebx': 'filter', + * 'ecx': 'filter', + * 'edx': 'filter' }, ], + * { 'leaf': 'val-eax', ..., 'eax': 'filter', ... }, + * ... etc ... + * } + */ + + s = yajl_gen_array_open(hand); + if (s != yajl_gen_status_ok) goto out; + + if (cpuid == NULL) goto empty; + + for (i = 0; cpuid[i].input[0] != XEN_CPUID_INPUT_UNUSED; i++) { + s = yajl_gen_map_open(hand); + if (s != yajl_gen_status_ok) goto out; + + for (j = 0; j < 2; j++) { + if (cpuid[i].input[j] != XEN_CPUID_INPUT_UNUSED) { + s = libxl__yajl_gen_asciiz(hand, input_names[j]); + if (s != yajl_gen_status_ok) goto out; + s = yajl_gen_integer(hand, cpuid[i].input[j]); + if (s != yajl_gen_status_ok) goto out; + } + } + + for (j = 0; j < 4; j++) { + if (cpuid[i].policy[j] != NULL) { + s = libxl__yajl_gen_asciiz(hand, policy_names[j]); + if (s != yajl_gen_status_ok) goto out; + s = yajl_gen_string(hand, + (const unsigned char *)cpuid[i].policy[j], 32); + if (s != yajl_gen_status_ok) goto out; + } + } + s = yajl_gen_map_close(hand); + if (s != yajl_gen_status_ok) goto out; + } + +empty: + s = yajl_gen_array_close(hand); +out: + return s; +} + +yajl_gen_status libxl_string_list_gen_json(yajl_gen hand, libxl_string_list *pl) +{ + libxl_string_list l = *pl; + yajl_gen_status s; + int i; + + s = yajl_gen_array_open(hand); + if (s != yajl_gen_status_ok) goto out; + + if (!l) goto empty; + + for (i = 0; l[i] != NULL; i++) { + s = libxl__yajl_gen_asciiz(hand, l[i]); + if (s != yajl_gen_status_ok) goto out; + } +empty: + s = yajl_gen_array_close(hand); +out: + return s; +} + +yajl_gen_status libxl_mac_gen_json(yajl_gen hand, libxl_mac *mac) +{ + char buf[LIBXL_MAC_FMTLEN+1]; + snprintf(buf, sizeof(buf), LIBXL_MAC_FMT, LIBXL_MAC_BYTES((*mac))); + return yajl_gen_string(hand, (const unsigned char *)buf, LIBXL_MAC_FMTLEN); +} + +yajl_gen_status libxl_hwcap_gen_json(yajl_gen hand, + libxl_hwcap p) +{ + yajl_gen_status s; + int i; + + s = yajl_gen_array_open(hand); + if (s != yajl_gen_status_ok) goto out; + + for(i=0; i<4; i++) { + s = yajl_gen_integer(hand, p[i]); + if (s != yajl_gen_status_ok) goto out; + } + s = yajl_gen_array_close(hand); +out: + return s; +} + +yajl_gen_status libxl_cpuarray_gen_json(yajl_gen hand, + libxl_cpuarray *cpuarray) +{ + yajl_gen_status s; + int i; + + s = yajl_gen_array_open(hand); + if (s != yajl_gen_status_ok) goto out; + + for(i=0; i<cpuarray->entries; i++) { + if (cpuarray->array[i] == LIBXL_CPUARRAY_INVALID_ENTRY) + s = yajl_gen_null(hand); + else + s = yajl_gen_integer(hand, cpuarray->array[i]); + if (s != yajl_gen_status_ok) goto out; + } + s = yajl_gen_array_close(hand); +out: + return s; +} + +yajl_gen_status libxl_file_reference_gen_json(yajl_gen hand, + libxl_file_reference *p) +{ + if (p->path) + return libxl__yajl_gen_asciiz(hand, p->path); + else + return yajl_gen_null(hand); +} + +yajl_gen_status libxl__string_gen_json(yajl_gen hand, + const char *p) +{ + if (p) + return libxl__yajl_gen_asciiz(hand, p); + else + return yajl_gen_null(hand); +} /* * libxl__json_object helper functions @@ -558,3 +760,68 @@ libxl__json_object *libxl__json_parse(li return NULL; } } + +static const char *yajl_gen_status_to_string(yajl_gen_status s) +{ + switch (s) { + case yajl_gen_status_ok: abort(); + case yajl_gen_keys_must_be_strings: + return "keys must be strings"; + case yajl_max_depth_exceeded: + return "max depth exceeded"; + case yajl_gen_in_error_state: + return "in error state"; + case yajl_gen_generation_complete: + return "generation complete"; + case yajl_gen_invalid_number: + return "invalid number"; + case yajl_gen_no_buf: + return "no buffer"; +#if 0 /* This is in the docs but not implemented in the version I am running. */ + case yajl_gen_invalid_string: + return "invalid string"; +#endif + default: + return "unknown error"; + } +} + +char *libxl__object_to_json(libxl_ctx *ctx, const char *type, + libxl__gen_json_callback gen, void *p) +{ + yajl_gen_config conf = { 1, " " }; + const unsigned char *buf; + char *ret = NULL; + unsigned int len = 0; + yajl_gen_status s; + yajl_gen hand; + + hand = yajl_gen_alloc(&conf, NULL); + if (!hand) + return NULL; + + s = gen(hand, p); + if (s != yajl_gen_status_ok) + goto out; + + s = yajl_gen_get_buf(hand, &buf, &len); + if (s != yajl_gen_status_ok) + goto out; + ret = strdup((const char *)buf); + +out: + yajl_gen_free(hand); + + if (s != yajl_gen_status_ok) { + LIBXL__LOG(ctx, LIBXL__LOG_ERROR, + "unable to convert %s to JSON representation. " + "YAJL error code %d: %s", type, + s, yajl_gen_status_to_string(s)); + } else if (!ret) { + LIBXL__LOG(ctx, LIBXL__LOG_ERROR, + "unable to allocate space for to JSON representation of %s", + type); + } + + return ret; +} diff -r fb42038b1f5c -r 030e844fcceb tools/libxl/libxl_json.h --- /dev/null Thu Jan 01 00:00:00 1970 +0000 +++ b/tools/libxl/libxl_json.h Thu Sep 29 17:02:14 2011 +0100 @@ -0,0 +1,42 @@ +/* + * Copyright (C) 2011 Citrix Ltd. + * + * This program is free software; you can redistribute it and/or modify + * it under the terms of the GNU Lesser General Public License as published + * by the Free Software Foundation; version 2.1 only. with the special + * exception on linking described in file LICENSE. + * + * This program is distributed in the hope that it will be useful, + * but WITHOUT ANY WARRANTY; without even the implied warranty of + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the + * GNU Lesser General Public License for more details. + */ + +#ifndef LIBXL_JSON_H +#define LIBXL_JSON_H + +#include <yajl/yajl_gen.h> + +#include <_libxl_types_json.h> +#include <_libxl_types_internal_json.h> + +yajl_gen_status libxl_uuid_gen_json(yajl_gen hand, + libxl_uuid *p); +yajl_gen_status libxl_cpumap_gen_json(yajl_gen hand, + libxl_cpumap *p); +yajl_gen_status libxl_key_value_list_gen_json(yajl_gen hand, + libxl_key_value_list *p); +yajl_gen_status libxl_cpuid_policy_list_gen_json(yajl_gen hand, + libxl_cpuid_policy_list *p); +yajl_gen_status libxl_string_list_gen_json(yajl_gen hand, + libxl_string_list *p); +yajl_gen_status libxl_mac_gen_json(yajl_gen hand, + libxl_mac *p); +yajl_gen_status libxl_hwcap_gen_json(yajl_gen hand, + libxl_hwcap p); +yajl_gen_status libxl_cpuarray_gen_json(yajl_gen hand, + libxl_cpuarray *p); +yajl_gen_status libxl_file_reference_gen_json(yajl_gen hand, + libxl_file_reference *p); + +#endif /* LIBXL_JSON_H */ diff -r fb42038b1f5c -r 030e844fcceb tools/libxl/libxl_types.idl --- a/tools/libxl/libxl_types.idl Thu Sep 29 16:57:52 2011 +0100 +++ b/tools/libxl/libxl_types.idl Thu Sep 29 17:02:14 2011 +0100 @@ -5,7 +5,7 @@ namespace("libxl_") -libxl_domid = Builtin("domid") +libxl_domid = Builtin("domid", json_fn = "yajl_gen_integer", autogenerate_json = False) libxl_uuid = Builtin("uuid", passby=PASS_BY_REFERENCE) libxl_mac = Builtin("mac", passby=PASS_BY_REFERENCE) libxl_cpumap = Builtin("cpumap", destructor_fn="libxl_cpumap_destroy", passby=PASS_BY_REFERENCE) diff -r fb42038b1f5c -r 030e844fcceb tools/libxl/libxltypes.py --- a/tools/libxl/libxltypes.py Thu Sep 29 16:57:52 2011 +0100 +++ b/tools/libxl/libxltypes.py Thu Sep 29 17:02:14 2011 +0100 @@ -50,6 +50,13 @@ class Type(object): self.autogenerate_destructor = kwargs.setdefault('autogenerate_destructor', True) + if self.typename is not None: + self.json_fn = kwargs.setdefault('json_fn', self.typename + "_gen_json") + else: + self.json_fn = kwargs.setdefault('json_fn', None) + + self.autogenerate_json = kwargs.setdefault('autogenerate_json', True) + def marshal_in(self): return self.dir in [DIR_IN, DIR_BOTH] def marshal_out(self): @@ -83,6 +90,7 @@ class Builtin(Type): def __init__(self, typename, **kwargs): kwargs.setdefault('destructor_fn', None) kwargs.setdefault('autogenerate_destructor', False) + kwargs.setdefault('autogenerate_json', False) Type.__init__(self, typename, **kwargs) class Number(Builtin): @@ -90,6 +98,7 @@ class Number(Builtin): kwargs.setdefault('namespace', None) kwargs.setdefault('destructor_fn', None) kwargs.setdefault('signed', False) + kwargs.setdefault('json_fn', "yajl_gen_integer") self.signed = kwargs['signed'] Builtin.__init__(self, ctype, **kwargs) @@ -163,6 +172,8 @@ class Aggregate(Type): comment = None else: n,t,const,comment = f + if n is None: + raise ValueError self.fields.append(Field(t,n,const=const,comment=comment)) # Returns a tuple (stem, field-expr) @@ -220,7 +231,10 @@ class KeyedUnion(Aggregate): # void = Builtin("void *", namespace = None) -bool = Builtin("bool", namespace = None) +bool = Builtin("bool", namespace = None, + json_fn = "yajl_gen_bool", + autogenerate_json = False) + size_t = Number("size_t", namespace = None) integer = Number("int", namespace = None, signed = True) @@ -230,7 +244,9 @@ uint16 = UInt(16) uint32 = UInt(32) uint64 = UInt(64) -string = Builtin("char *", namespace = None, destructor_fn = "free") +string = Builtin("char *", namespace = None, destructor_fn = "free", + json_fn = "libxl__string_gen_json", + autogenerate_json = False) class OrderedDict(dict): """A dictionary which remembers insertion order. _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel From xen-devel-bounces@lists.xensource.com Thu Sep 29 09:39:53 2011 Return-path: <xen-devel-bounces@lists.xensource.com> Envelope-to: www-data@lists.xensource.com Delivery-date: Thu, 29 Sep 2011 09:39:53 -0700 Received: from localhost ([127.0.0.1] helo=lists.colo.xensource.com) by lists.xensource.com with esmtp (Exim 4.43) id 1R9JeJ-0003kG-Vt; Thu, 29 Sep 2011 09:39:52 -0700 Received: from mail21.messagelabs.com ([85.158.143.35]) by lists.xensource.com with esmtp (Exim 4.43) id 1R9JdS-0003Xd-Re for Xen-devel@lists.xensource.com; Thu, 29 Sep 2011 09:38:59 -0700 X-Env-Sender: dan.magenheimer@oracle.com X-Msg-Ref: server-3.tower-21.messagelabs.com!1317314345!53466078!1 X-Originating-IP: [148.87.113.117] X-StarScan-Version: 6.4.1; banners=-,-,- X-VirusChecked: Checked Received: (qmail 11543 invoked from network); 29 Sep 2011 16:39:06 -0000 Received: from rcsinet15.oracle.com (HELO rcsinet15.oracle.com) (148.87.113.117) by server-3.tower-21.messagelabs.com with DHE-RSA-AES256-SHA encrypted SMTP; 29 Sep 2011 16:39:06 -0000 Received: from ucsinet24.oracle.com (ucsinet24.oracle.com [156.151.31.67]) by rcsinet15.oracle.com (Switch-3.4.4/Switch-3.4.4) with ESMTP id p8TGcnNo011982 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Thu, 29 Sep 2011 16:38:51 GMT Received: from acsmt358.oracle.com (acsmt358.oracle.com [141.146.40.158]) by ucsinet24.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id p8TGX7d5012951 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 29 Sep 2011 16:33:08 GMT Received: from abhmt109.oracle.com (abhmt109.oracle.com [141.146.116.61]) by acsmt358.oracle.com (8.12.11.20060308/8.12.11) with ESMTP id p8TGchCn015299; Thu, 29 Sep 2011 11:38:43 -0500 MIME-Version: 1.0 Message-ID: <c2d9add1-0095-4319-8936-db1b156559bf@default> Date: Thu, 29 Sep 2011 09:38:41 -0700 (PDT) From: Dan Magenheimer <dan.magenheimer@oracle.com> To: Sameer Pramod Niphadkar <spniphadkar@gmail.com>, Larry Bassel <lbassel@codeaurora.org> Subject: RE: [Xen-devel] Re: RFC -- new zone type References: <20110928180909.GA7007@labbmf-linux.qualcomm.com CAOFJiu1_HaboUMqtjowA2xKNmGviDE55GUV4OD1vN2hXUf4-kQ@mail.gmail.com> In-Reply-To: <CAOFJiu1_HaboUMqtjowA2xKNmGviDE55GUV4OD1vN2hXUf4-kQ@mail.gmail.com> X-Priority: 3 X-Mailer: Oracle Beehive Extensions for Outlook 2.0.1.4.1.0 (410211) [OL 12.0.6562.5003] Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable X-Source-IP: ucsinet24.oracle.com [156.151.31.67] X-CT-RefId: str=0001.0A090201.4E849F1B.0136,ss=1,re=0.000,fgs=0 Cc: linux-mm@kvack.org, vgandhi@codeaurora.org, Xen-devel@lists.xensource.com X-BeenThere: xen-devel@lists.xensource.com X-Mailman-Version: 2.1.5 Precedence: list List-Id: Xen developer discussion <xen-devel.lists.xensource.com> List-Unsubscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe> List-Post: <mailto:xen-devel@lists.xensource.com> List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help> List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=subscribe> Sender: xen-devel-bounces@lists.xensource.com Errors-To: xen-devel-bounces@lists.xensource.com > From: Sameer Pramod Niphadkar [mailto:spniphadkar@gmail.com] > Sent: Thursday, September 29, 2011 12:08 AM > To: Larry Bassel > Cc: linux-mm@kvack.org; vgandhi@codeaurora.org; Xen-devel@lists.xensource= .com > Subject: [Xen-devel] Re: RFC -- new zone type >=20 > On Wed, Sep 28, 2011 at 11:39 PM, Larry Bassel <lbassel@codeaurora.org> w= rote: > > We need to create a large (~100M) contiguous physical memory region > > which will only be needed occasionally. As this region will > > use up 10-20% of all of the available memory, we do not want > > to pre-reserve it at boot time. Instead, we want to create > > this memory region "on the fly" when asked to by userspace, > > and do it as quickly as possible, and return it to > > system use when not needed. > > > > AFAIK, this sort of operation is currently done using memory > > compaction (as CMA does for instance). > > Alternatively, this memory region (if it is in a fixed place) > > could be created using "logical memory hotremove" and returned > > to the system using "logical memory hotplug". In either case, > > the contiguous physical memory would be created via migrating > > pages from the "movable zone". > > > > The problem with this approach is that the copying of up to 25000 > > pages may take considerable time (as well as finding destinations > > for all of the pages if free memory is scarce -- this may > > even fail, causing the memory region not to be created). > > > > It was suggested to me that a new zone type which would be similar > > to the "movable zone" but is only allowed to contain pages > > that can be discarded (such as text) could solve this problem, > > so that there is no copying or finding destination pages needed (thus > > considerably reducing latency). If I read the above correctly, you are talking about indeed pre-reserving your ~100MB contiguous chunk of memory but using it for "discardable" pages only, then discarding all of those pages when you need the memory region, then going back to using the contiguous chunk for discardable pages, and so on. You may be interested in the concept of "ephemeral pages" introduced by transcendent memory ("tmem") and the cleancache patchset which went upstream at 3.0. If you write a driver (called a "backend" in tmem language) that accepts pages from cleancache, you would be able to use your 100MB contiguous chunk of memory for clean pagecache pages when it is not needed for your other purposes, easily discard all the pages when you do need the space, then start using it for clean pagecache pages again when you don't need it for your purposes anymore (and repeat this cycle as many times as necessary). You maybe could call your driver "cleanzone". Zcache (also upstream in drivers/staging) does something like this already, though you might not want/need to use compression in your driver. In zcache, space reclaim is driven by the kernel "shrinker" code that runs when memory is low, but another trigger could easily be used. Also there is likely a lot of code in zcache (e.g. tmem.c) that you could leverage. For more info, see:=20 http://lwn.net/Articles/454795/ http://oss.oracle.com/projects/tmem=20 I'd be happy to answer any questions if you are still interested after you have read the above documentation. Thanks, Dan _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel From xen-devel-bounces@lists.xensource.com Thu Sep 29 09:41:02 2011 Return-path: <xen-devel-bounces@lists.xensource.com> Envelope-to: www-data@lists.xensource.com Delivery-date: Thu, 29 Sep 2011 09:41:02 -0700 Received: from localhost ([127.0.0.1] helo=lists.colo.xensource.com) by lists.xensource.com with esmtp (Exim 4.43) id 1R9JfR-00047j-VH; Thu, 29 Sep 2011 09:41:01 -0700 Received: from mail27.messagelabs.com ([193.109.254.147]) by lists.xensource.com with esmtp (Exim 4.43) id 1R9Jez-0003un-4I for xen-devel@lists.xensource.com; Thu, 29 Sep 2011 09:40:33 -0700 X-Env-Sender: jeremy@goop.org X-Msg-Ref: server-7.tower-27.messagelabs.com!1317314403!50685408!1 X-Originating-IP: [74.207.240.146] X-StarScan-Version: 6.4.1; banners=-,-,- X-VirusChecked: Checked Received: (qmail 17049 invoked from network); 29 Sep 2011 16:40:04 -0000 Received: from claw.goop.org (HELO claw.goop.org) (74.207.240.146) by server-7.tower-27.messagelabs.com with DHE-RSA-AES256-SHA encrypted SMTP; 29 Sep 2011 16:40:04 -0000 Received: from saboo.goop.org (c-50-131-57-2.hsd1.ca.comcast.net [50.131.57.2]) (Authenticated sender: smtp-saboo) by claw.goop.org (Postfix) with ESMTPSA id D131C89D6; Thu, 29 Sep 2011 09:40:26 -0700 (PDT) Received: from saboo.goop.org (localhost [IPv6:::1]) by saboo.goop.org (Postfix) with ESMTP id F021120EE0; Thu, 29 Sep 2011 09:40:19 -0700 (PDT) Message-ID: <4E849F73.3010801@goop.org> Date: Thu, 29 Sep 2011 09:40:19 -0700 From: Jeremy Fitzhardinge <jeremy@goop.org> User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:6.0.2) Gecko/20110906 Thunderbird/6.0.2 MIME-Version: 1.0 To: Jan Beulich <JBeulich@suse.com> Subject: Re: [Xen-devel] blkback stuck in infinite loop in xen_blkbk_discard() References: <4E839451.40901@goop.org> <4E845CB4020000780005871C@nat28.tlf.novell.com> In-Reply-To: <4E845CB4020000780005871C@nat28.tlf.novell.com> X-Enigmail-Version: 1.3.2 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: Dong Yang Li <lidongyang@suse.com>, "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>, Konrad Rzeszutek Wilk <konrad.wilk@oracle.com> X-BeenThere: xen-devel@lists.xensource.com X-Mailman-Version: 2.1.5 Precedence: list List-Id: Xen developer discussion <xen-devel.lists.xensource.com> List-Unsubscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe> List-Post: <mailto:xen-devel@lists.xensource.com> List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help> List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=subscribe> Sender: xen-devel-bounces@lists.xensource.com Errors-To: xen-devel-bounces@lists.xensource.com On 09/29/2011 02:55 AM, Jan Beulich wrote: >>>> On 28.09.11 at 23:40, Jeremy Fitzhardinge <jeremy@goop.org> wrote: >> I just "xl destroy"d a domain, and now my dom0 kernel is sitting there >> infinitely spewing: >> >> vbd vbd-83-51712: 5 reading type >> vbd vbd-83-51712: 5 reading type >> vbd vbd-83-51712: 5 reading type >> vbd vbd-83-51712: 5 reading type >> vbd vbd-83-51712: 5 reading type >> vbd vbd-83-51712: 5 reading type >> vbd vbd-83-51712: 5 reading type >> vbd vbd-83-51712: 5 reading type >> vbd vbd-83-51712: 5 reading type >> vbd vbd-83-51712: 5 reading type >> vbd vbd-83-51712: 5 reading type >> vbd vbd-83-51712: 5 reading type >> vbd vbd-83-51712: 5 reading type >> vbd vbd-83-51712: 5 reading type >> vbd vbd-83-51712: 5 reading type >> vbd vbd-83-51712: 5 reading type >> vbd vbd-83-51712: 5 reading type >> vbd vbd-83-51712: 5 reading type >> vbd vbd-83-51712: 5 reading type >> >> which seems to be coming from the error case in >> drivers/block/xen-blkback/xenbus.c:xen_blkbk_discard(). >> >> I don't know what the backtrace is. The system seems overall fine, >> despite the console spew, though I have a pile of dying domains sitting >> in odd states rather than being cleaned up. > I wonder how the function gets called during destroy in the first place, > and how that would prevent destroying a domain (unless there's a > feedback loop due to the use of xenbus_dev_fatal() here, causing > some xenstore entry to get written over and over again, triggering > the respective watch that blkback has active). > > But irrespective of this I would think the function should bail without > doing anything if blkif->blk_backend_type was already set (or > couldn't get set). But that would then also indicate a more general > problem in connect(), as that function shouldn't do anything either > when a domain gets destroyed. Well, it could have got into that state before I destroyed the domain - it was a test kernel that crashed very early (before setting up its own frontend) after booting from pvgrub, so perhaps there was some race in that handoff. J _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel From xen-devel-bounces@lists.xensource.com Thu Sep 29 09:46:07 2011 Return-path: <xen-devel-bounces@lists.xensource.com> Envelope-to: www-data@lists.xensource.com Delivery-date: Thu, 29 Sep 2011 09:46:07 -0700 Received: from localhost ([127.0.0.1] helo=lists.colo.xensource.com) by lists.xensource.com with esmtp (Exim 4.43) id 1R9JkM-0005DE-UF; Thu, 29 Sep 2011 09:46:06 -0700 Received: from mail174.messagelabs.com ([85.158.138.51]) by lists.xensource.com with esmtp (Exim 4.43) id 1R9Jj5-0004iK-Ri for xen-devel@lists.xensource.com; Thu, 29 Sep 2011 09:44:48 -0700 X-Env-Sender: david.vrabel@citrix.com X-Msg-Ref: server-5.tower-174.messagelabs.com!1317314682!29572846!1 X-Originating-IP: [66.165.176.63] X-StarScan-Version: 6.4.1; banners=-,-,- X-VirusChecked: Checked Received: (qmail 25876 invoked from network); 29 Sep 2011 16:44:44 -0000 Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63) by server-5.tower-174.messagelabs.com with RC4-SHA encrypted SMTP; 29 Sep 2011 16:44:44 -0000 X-IronPort-AV: E=Sophos;i="4.68,462,1312171200"; d="scan'208";a="165165316" Received: from ftlpmailmx01.citrite.net ([10.13.107.65]) by FTLPIPO02.CITRIX.COM with ESMTP/TLS/RC4-MD5; 29 Sep 2011 12:44:32 -0400 Received: from [10.80.2.76] (10.80.2.76) by FTLPMAILMX01.citrite.net (10.13.107.65) with Microsoft SMTP Server id 8.3.137.0; Thu, 29 Sep 2011 12:44:32 -0400 Message-ID: <4E84A0C0.6000804@citrix.com> Date: Thu, 29 Sep 2011 17:45:52 +0100 From: David Vrabel <david.vrabel@citrix.com> User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.1.16) Gecko/20110818 Icedove/3.0.11 MIME-Version: 1.0 To: Jan Beulich <JBeulich@suse.com> Subject: Re: [Xen-devel] [PATCH 0/4] xen: map foreign pages for shared rings by updating the PTEs directly References: <1317311612-15220-1-git-send-email-david.vrabel@citrix.com> <4E84B3FE02000078000588A9@nat28.tlf.novell.com> In-Reply-To: <4E84B3FE02000078000588A9@nat28.tlf.novell.com> Content-Type: text/plain; charset="ISO-8859-1" Content-Transfer-Encoding: 7bit Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>, Rzeszutek Wilk <konrad.wilk@oracle.com>, Konrad X-BeenThere: xen-devel@lists.xensource.com X-Mailman-Version: 2.1.5 Precedence: list List-Id: Xen developer discussion <xen-devel.lists.xensource.com> List-Unsubscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe> List-Post: <mailto:xen-devel@lists.xensource.com> List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help> List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=subscribe> Sender: xen-devel-bounces@lists.xensource.com Errors-To: xen-devel-bounces@lists.xensource.com On 29/09/11 17:07, Jan Beulich wrote: >>>> On 29.09.11 at 17:53, David Vrabel <david.vrabel@citrix.com> wrote: >> [Resend as requested by Konrad.] >> >> This series of patches allows the vmalloc_sync_all() to be removed >> from alloc_vm_area() by getting the hypervisor to update the PTEs (in >> init_mm) directly rather than having the hypervisor look in the >> current page tables to find the PTEs. >> >> Once the hypervisor has updated the PTEs, the normal mechanism of >> syncing the page tables after a fault works as expected. > > Did you actually test that, and namely the case where alloc_vm_area() > would result in a new top level page directory entry to get populated? > > I cannot see how this new entry would propagate into other mm-s, and > hence I cannot see how you can do away with calling vmalloc_sync_all() > just by changing how leaf page table entries get populated. I don't think this new behaviour of alloc_vm_area() is any different from how a regular vmalloc() works. vmalloc_fault() copies the page table entries from init_mm into the current MM (on 32-bit it calls vmalloc_sync_one() which makes it obviously correct I think). David >> This mechanism doesn't currently work on the ia64 port as that does >> not support the GNTMAP_contains_pte flag. >> >> David _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel From xen-devel-bounces@lists.xensource.com Thu Sep 29 10:04:39 2011 Return-path: <xen-devel-bounces@lists.xensource.com> Envelope-to: www-data@lists.xensource.com Delivery-date: Thu, 29 Sep 2011 10:04:39 -0700 Received: from localhost ([127.0.0.1] helo=lists.colo.xensource.com) by lists.xensource.com with esmtp (Exim 4.43) id 1R9K2I-0005s4-MU; Thu, 29 Sep 2011 10:04:38 -0700 Received: from mail27.messagelabs.com ([193.109.254.147]) by lists.xensource.com with esmtp (Exim 4.43) id 1R9K0Z-0005eL-JD for xen-devel@lists.xensource.com; Thu, 29 Sep 2011 10:03:00 -0700 X-Env-Sender: olaf@aepfle.de X-Msg-Ref: server-5.tower-27.messagelabs.com!1317315746!46933791!1 X-Originating-IP: [81.169.146.162] X-StarScan-Version: 6.4.1; banners=-,-,- X-VirusChecked: Checked Received: (qmail 29252 invoked from network); 29 Sep 2011 17:02:26 -0000 Received: from mo-p00-ob.rzone.de (HELO mo-p00-ob.rzone.de) (81.169.146.162) by server-5.tower-27.messagelabs.com with DHE-RSA-AES256-SHA encrypted SMTP; 29 Sep 2011 17:02:26 -0000 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; t=1317315767; l=1607; s=domk; d=aepfle.de; h=In-Reply-To:Content-Transfer-Encoding:Content-Type:MIME-Version: References:Subject:Cc:To:From:Date:X-RZG-CLASS-ID:X-RZG-AUTH; bh=tDLNFfmWA3xjpzsdtiXMEC20p2Q=; b=BtIWNNt3SYti9KcUDatDcmMelhGcOhDtTTA5KFmIoooPXHqIPfKTvN3G8GXhBUFiSXZ K+TSeB8WgWLwt24aSx8O9cPKjFZ9t8LLxfendJWqtyVhf6+XRZW10PE2O20m2XgDfra9x 2Icfdoxkr3FBeVjTXm/UN0/qRcD7eV9E4mY= X-RZG-AUTH: :P2EQZWCpfu+qG7CngxMFH1J+zrwiavkK6tmQaLfmztM8TOFGjy0KF2I= X-RZG-CLASS-ID: mo00 Received: from probook.site (dslb-088-065-081-044.pools.arcor-ip.net [88.65.81.44]) by smtp.strato.de (jimi mo1) (RZmta 26.7) with (DHE-RSA-AES256-SHA encrypted) ESMTPA id e06fadn8TFXCMd ; Thu, 29 Sep 2011 19:02:45 +0200 (MEST) Received: by probook.site (Postfix, from userid 1000) id 0145918B65; Thu, 29 Sep 2011 19:02:44 +0200 (CEST) Date: Thu, 29 Sep 2011 19:02:44 +0200 From: Olaf Hering <olaf@aepfle.de> To: zhen shi <bickys1986@gmail.com> Message-ID: <20110929170244.GA29163@aepfle.de> References: <CACavRyB4kvMLZK1-vv9bJnVdnpKJBHTmnhJxt6g3eh88xY6FTg@mail.gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <CACavRyB4kvMLZK1-vv9bJnVdnpKJBHTmnhJxt6g3eh88xY6FTg@mail.gmail.com> User-Agent: Mutt/1.5.21.rev5535 (2011-07-01) Cc: xen-devel@lists.xensource.com Subject: [Xen-devel] Re: mapping problems in xenpaging X-BeenThere: xen-devel@lists.xensource.com X-Mailman-Version: 2.1.5 Precedence: list List-Id: Xen developer discussion <xen-devel.lists.xensource.com> List-Unsubscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe> List-Post: <mailto:xen-devel@lists.xensource.com> List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help> List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=subscribe> Sender: xen-devel-bounces@lists.xensource.com Errors-To: xen-devel-bounces@lists.xensource.com On Thu, Sep 29, zhen shi wrote: >  Hi,Olaf, >   >  When we analyze and test xenpaging,we found there are some problems between > mapping and xenpaging. >  1) When mapping firstly, then do xenpaging,and the code paths have resolved > the problems.It's OK. >  2) The problems exists if we do address mapping firstly then go to > xenpaging,and our confusions are as followings: >    a) If the domU's memory is directly mapped to dom0,such as the hypercall > from pv driver,then it will build a related page-table in dom0,which will not > change p2m-type. >       and then do the xenpaging to page out the domU's memory pages whose gfn > address have been already mapped to dom0;So it will cause some problems when > dom0 >       accesses these pages.Because these pages are paged-out,and dom0 cannot > tell the p2mt before access the pages. I'm not entirely sure what you do. xenpaging runs in dom0 and is able to map paged-out pages. It uses that to trigger a page-in, see tools/xenpaging/pagein.c in xen-unstable.hg >   b)The another situation is that if xen has mapped the domU's page, and get > the mfn according to pfn_to_mfn.But then the page's p2mt is changed by others, > so when xen >     accesses the page ,it will cause problems such as BSOD or reboot.Because > the operations of getting mfn and accessing the page are not > atomic.and the situation exists >     in many code paths . Can you be more specific what you mean? Xen doesnt seem to have a pfn_to_mfn function, only the tools have some helper macros of that name. Olaf _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel From xen-devel-bounces@lists.xensource.com Thu Sep 29 12:26:06 2011 Return-path: <xen-devel-bounces@lists.xensource.com> Envelope-to: www-data@lists.xensource.com Delivery-date: Thu, 29 Sep 2011 12:26:06 -0700 Received: from localhost ([127.0.0.1] helo=lists.colo.xensource.com) by lists.xensource.com with esmtp (Exim 4.43) id 1R9MFB-0001CC-FY; Thu, 29 Sep 2011 12:26:06 -0700 Received: from mail21.messagelabs.com ([85.158.143.35]) by lists.xensource.com with esmtp (Exim 4.43) id 1R9MEO-0000za-WC for xen-devel@lists.xensource.com; Thu, 29 Sep 2011 12:25:17 -0700 X-Env-Sender: Ian.Jackson@eu.citrix.com X-Msg-Ref: server-12.tower-21.messagelabs.com!1317324298!51873044!1 X-Originating-IP: [62.200.22.115] X-StarScan-Version: 6.4.1; banners=-,-,- X-VirusChecked: Checked Received: (qmail 21439 invoked from network); 29 Sep 2011 19:24:58 -0000 Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115) by server-12.tower-21.messagelabs.com with RC4-SHA encrypted SMTP; 29 Sep 2011 19:24:58 -0000 X-IronPort-AV: E=Sophos;i="4.68,462,1312156800"; d="scan'208";a="8137316" Received: from lonpmailmx01.citrite.net ([10.30.203.162]) by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5; 29 Sep 2011 19:25:06 +0000 Received: from norwich.cam.xci-test.com (10.80.248.129) by smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id 8.3.137.0; Thu, 29 Sep 2011 20:25:06 +0100 Received: from [10.80.248.135] (helo=woking.xci-test.com) by norwich.cam.xci-test.com with esmtp (Exim 4.72) (envelope-from <ian.jackson@eu.citrix.com>) id 1R9MEE-00015r-De; Thu, 29 Sep 2011 19:25:06 +0000 Received: from osstest by woking.xci-test.com with local (Exim 4.69) (envelope-from <ian.jackson@eu.citrix.com>) id 1R9MEE-00034p-D6; Thu, 29 Sep 2011 20:25:06 +0100 To: xen-devel@lists.xensource.com Message-ID: <osstest-9119-mainreport@xen.org> From: xen.org <ian.jackson@eu.citrix.com> Date: Thu, 29 Sep 2011 20:25:06 +0100 MIME-Version: 1.0 Content-Type: text/plain Cc: ian.jackson@eu.citrix.com Subject: [Xen-devel] [xen-unstable test] 9119: regressions - FAIL X-BeenThere: xen-devel@lists.xensource.com X-Mailman-Version: 2.1.5 Precedence: list List-Id: Xen developer discussion <xen-devel.lists.xensource.com> List-Unsubscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe> List-Post: <mailto:xen-devel@lists.xensource.com> List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help> List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=subscribe> Sender: xen-devel-bounces@lists.xensource.com Errors-To: xen-devel-bounces@lists.xensource.com flight 9119 xen-unstable real [real] http://www.chiark.greenend.org.uk/~xensrcts/logs/9119/ Regressions :-( Tests which did not succeed and are blocking: test-amd64-amd64-xl-pcipt-intel 8 debian-fixup fail REGR. vs. 9118 test-amd64-i386-xl-multivcpu 9 guest-start fail REGR. vs. 9118 test-amd64-i386-xl 9 guest-start fail REGR. vs. 9118 test-amd64-i386-xl-credit2 9 guest-start fail REGR. vs. 9118 test-amd64-i386-rhel6hvm-intel 7 redhat-install fail REGR. vs. 9118 test-i386-i386-xl 9 guest-start fail REGR. vs. 9118 test-amd64-amd64-xl-sedf 9 guest-start fail REGR. vs. 9118 test-amd64-amd64-xl 9 guest-start fail REGR. vs. 9118 test-amd64-i386-rhel6hvm-amd 7 redhat-install fail REGR. vs. 9118 test-amd64-i386-xl-win-vcpus1 7 windows-install fail REGR. vs. 9118 test-amd64-amd64-xl-win 7 windows-install fail REGR. vs. 9118 test-i386-i386-xl-win 7 windows-install fail REGR. vs. 9118 Tests which did not succeed, but are not blocking, including regressions (tests previously passed) regarded as allowable: test-amd64-i386-win-vcpus1 16 leak-check/check fail never pass test-amd64-i386-win 16 leak-check/check fail never pass test-amd64-amd64-win 16 leak-check/check fail never pass test-i386-i386-win 16 leak-check/check fail never pass version targeted for testing: xen e78cd03b0308 baseline version: xen 7998217630e2 ------------------------------------------------------------ People who touched revisions under test: Adin Scannell <adin@scannell.ca> Anthony PERARD <anthony.perard@citrix.com> Ian Campbell <ian.campbell@citrix.com> Ian Jackson <ian.jackson.citrix.com> Ian Jackson <ian.jackson@eu.citrix.com> Olaf Hering <olaf@aepfle.de> ------------------------------------------------------------ jobs: build-amd64 pass build-i386 pass build-amd64-oldkern pass build-i386-oldkern pass build-amd64-pvops pass build-i386-pvops pass test-amd64-amd64-xl fail test-amd64-i386-xl fail test-i386-i386-xl fail test-amd64-i386-rhel6hvm-amd fail test-amd64-i386-xl-credit2 fail test-amd64-amd64-xl-pcipt-intel fail test-amd64-i386-rhel6hvm-intel fail test-amd64-i386-xl-multivcpu fail test-amd64-amd64-pair pass test-amd64-i386-pair pass test-i386-i386-pair pass test-amd64-amd64-pv pass test-amd64-i386-pv pass test-i386-i386-pv pass test-amd64-amd64-xl-sedf fail test-amd64-i386-win-vcpus1 fail test-amd64-i386-xl-win-vcpus1 fail test-amd64-amd64-win fail test-amd64-i386-win fail test-i386-i386-win fail test-amd64-amd64-xl-win fail test-i386-i386-xl-win fail ------------------------------------------------------------ sg-report-flight on woking.cam.xci-test.com logs: /home/xc_osstest/logs images: /home/xc_osstest/images Logs, config files, etc. are available at http://www.chiark.greenend.org.uk/~xensrcts/logs Test harness code can be found at http://xenbits.xensource.com/gitweb?p=osstest.git;a=summary Not pushing. ------------------------------------------------------------ changeset: 23894:e78cd03b0308 tag: tip user: Anthony PERARD <anthony.perard@citrix.com> date: Thu Sep 29 16:31:24 2011 +0100 libxl: libxl_qmp: use of libxl__fd_set_cloexec. Signed-off-by: Anthony PERARD <anthony.perard@citrix.com> Acked-by: Ian Jackson <ian.jackson@eu.citrix.com> Committed-by: Ian Jackson <ian.jackson@eu.citrix.com> changeset: 23893:95a40ee93806 user: Anthony PERARD <anthony.perard@citrix.com> date: Thu Sep 29 16:30:54 2011 +0100 libxl: Introduce a QMP client QMP stands for QEMU Monitor Protocol and it is used to query information from QEMU or to control QEMU. This implementation will ask QEMU the list of chardevice and store the path to serial ports in xenstored. So we will be able to use xl console with QEMU upstream. In order to connect to the QMP server, a socket file is created in /var/run/xen/qmp-libxl-$(domid). Signed-off-by: Anthony PERARD <anthony.perard@citrix.com> Committed-by: Ian Jackson <ian.jackson@eu.citrix.com> changeset: 23892:5f397994e6d6 user: Anthony PERARD <anthony.perard@citrix.com> date: Thu Sep 29 16:28:24 2011 +0100 libxl: Introduce JSON parser We use the yajl parser, but we need to make a tree from the parse result to use it outside the parser. So this patch include json_object struct that is used to hold the JSON data. Signed-off-by: Anthony PERARD <anthony.perard@citrix.com> Committed-by: Ian Jackson <ian.jackson.citrix.com> Acked-by: Ian Campbell <ian.campbell@citrix.com> changeset: 23891:066dc3758fa4 user: Anthony PERARD <anthony.perard@citrix.com> date: Thu Sep 29 16:28:23 2011 +0100 libxl: Intruduce libxl__strndup. Signed-off-by: Anthony PERARD <anthony.perard@citrix.com> Committed-by: Ian Jackson <ian.jackson.citrix.com> Acked-by: Ian Campbell <ian.campbell@citrix.com> changeset: 23890:952e0118a7c4 user: Anthony PERARD <anthony.perard@citrix.com> date: Thu Sep 29 16:28:22 2011 +0100 libxl: Introduce libxl__realloc. Signed-off-by: Anthony PERARD <anthony.perard@citrix.com> Committed-by: Ian Jackson <ian.jackson.citrix.com> Acked-by: Ian Campbell <ian.campbell@citrix.com> changeset: 23889:f51dcd8acb7b user: Anthony PERARD <anthony.perard@citrix.com> date: Thu Sep 29 16:28:22 2011 +0100 libxl: Introduce libxl_internal_types.idl. Signed-off-by: Anthony PERARD <anthony.perard@citrix.com> Committed-by: Ian Jackson <ian.jackson.citrix.com> Acked-by: Ian Campbell <ian.campbell@citrix.com> changeset: 23888:f5ee5ad45425 user: Anthony PERARD <anthony.perard@citrix.com> date: Thu Sep 29 16:28:21 2011 +0100 libxl: Add get/set_default_namespace in libxltypes.py. Signed-off-by: Anthony PERARD <anthony.perard@citrix.com> Committed-by: Ian Jackson <ian.jackson.citrix.com> Acked-by: Ian Campbell <ian.campbell@citrix.com> changeset: 23887:a543e10211f7 user: Anthony PERARD <anthony.perard@citrix.com> date: Thu Sep 29 16:28:20 2011 +0100 libxl: Rename libxl.idl to libxl_types.idl. Signed-off-by: Anthony PERARD <anthony.perard@citrix.com> Committed-by: Ian Jackson <ian.jackson.citrix.com> Acked-by: Ian Campbell <ian.campbell@citrix.com> changeset: 23886:cf2ba5720151 user: Anthony PERARD <anthony.perard@citrix.com> date: Thu Sep 29 16:06:02 2011 +0100 libxl: Introduce libxl__fd_set_cloexec Signed-off-by: Anthony PERARD <anthony.perard@citrix.com> Acked-by: Ian Jackson <ian.jackson@eu.citrix.com> Committed-by: Ian Jackson <ian.jackson@eu.citrix.com> changeset: 23885:cd60c87d3496 user: Ian Campbell <ian.campbell@citrix.com> date: Thu Sep 29 15:40:34 2011 +0100 xl: fixup command line handling for several commands. def_getopt already checks for a minimum number of arguments for us. "xl save" simply need to use the correct argument for that value, contrary to the change I made in 23876:b113d626cfaf "xl block-list" does not need to check for at least 2 arguments, since it's already been done by def_getopt. "xl network-list" would previous accept zero arguments and just print the table header. Insist on a domain argument. Signed-off-by: Ian Campbell <ian.campbell@citrix.com> Acked-by: Ian Jackson <ian.jackson@eu.citrix.com> Committed-by: Ian Jackson <ian.jackson@eu.citrix.com> changeset: 23884:145e146876b3 user: Adin Scannell <adin@gridcentric.com> date: Thu Sep 29 15:26:04 2011 +0100 libxl: Expose number of shared pages Signed-off-by: Adin Scannell <adin@scannell.ca> Acked-by: Ian Jackson <ian.jackson@eu.citrix.com> Committed-by: Ian Jackson <ian.jackson@eu.citrix.com> changeset: 23883:7998217630e2 user: Ian Campbell <ian.campbell@citrix.com> date: Wed Sep 28 16:42:11 2011 +0100 libxl: attempt to cleanup tapdisk processes on disk backend destroy. Signed-off-by: Ian Campbell <ian.campbell@citrix.com> Committed-by: Ian Jackson <ian.jackson@eu.citrix.com> ======================================== commit cd776ee9408ff127f934a707c1a339ee600bc127 Author: Ian Jackson <ian.jackson@eu.citrix.com> Date: Tue Jun 28 13:50:53 2011 +0100 qemu-char.c: fix incorrect CONFIG_STUBDOM handling qemu-char.c:1123:7: warning: "CONFIG_STUBDOM" is not defined [-Wundef] Signed-off-by: Olaf Hering <olaf@aepfle.de> Acked-by: Ian Jackson <ian.jackson@eu.citrix.com> _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel From xen-devel-bounces@lists.xensource.com Thu Sep 29 12:53:48 2011 Return-path: <xen-devel-bounces@lists.xensource.com> Envelope-to: www-data@lists.xensource.com Delivery-date: Thu, 29 Sep 2011 12:53:48 -0700 Received: from localhost ([127.0.0.1] helo=lists.colo.xensource.com) by lists.xensource.com with esmtp (Exim 4.43) id 1R9Mg0-0002pp-3S; Thu, 29 Sep 2011 12:53:48 -0700 Received: from mail216.messagelabs.com ([85.158.143.99]) by lists.xensource.com with esmtp (Exim 4.43) id 1R9MfK-0002d2-T5 for xen-devel@lists.xensource.com; Thu, 29 Sep 2011 12:53:07 -0700 X-Env-Sender: konrad@oracle.com X-Msg-Ref: server-9.tower-216.messagelabs.com!1317325982!20067889!1 X-Originating-IP: [148.87.113.117] X-StarScan-Version: 6.4.1; banners=-,-,- X-VirusChecked: Checked Received: (qmail 8507 invoked from network); 29 Sep 2011 19:53:03 -0000 Received: from rcsinet15.oracle.com (HELO rcsinet15.oracle.com) (148.87.113.117) by server-9.tower-216.messagelabs.com with DHE-RSA-AES256-SHA encrypted SMTP; 29 Sep 2011 19:53:03 -0000 Received: from acsinet22.oracle.com (acsinet22.oracle.com [141.146.126.238]) by rcsinet15.oracle.com (Switch-3.4.4/Switch-3.4.4) with ESMTP id p8TJqxQ9015428 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Thu, 29 Sep 2011 19:53:01 GMT Received: from acsmt356.oracle.com (acsmt356.oracle.com [141.146.40.156]) by acsinet22.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id p8TJqwkh020368 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 29 Sep 2011 19:52:59 GMT Received: from abhmt115.oracle.com (abhmt115.oracle.com [141.146.116.67]) by acsmt356.oracle.com (8.12.11.20060308/8.12.11) with ESMTP id p8TJqrje003025; Thu, 29 Sep 2011 14:52:53 -0500 Received: from oracle.com (/207.172.105.198) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Thu, 29 Sep 2011 12:52:53 -0700 Received: by oracle.com (Postfix, from userid 1000) id C6ECE154E; Thu, 29 Sep 2011 15:52:52 -0400 (EDT) From: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com> To: linux-kernel@vger.kernel.org Date: Thu, 29 Sep 2011 15:52:45 -0400 Message-Id: <1317325971-21603-4-git-send-email-konrad.wilk@oracle.com> X-Mailer: git-send-email 1.7.4.1 In-Reply-To: <1317325971-21603-1-git-send-email-konrad.wilk@oracle.com> References: <1317325971-21603-1-git-send-email-konrad.wilk@oracle.com> X-Source-IP: acsinet22.oracle.com [141.146.126.238] X-Auth-Type: Internal IP X-CT-RefId: str=0001.0A090207.4E84CC9D.00AA:SCFMA922111,ss=1,re=-4.000,fgs=0 Cc: xen-devel@lists.xensource.com, Dan Carpenter <error27@gmail.com>, Konrad Rzeszutek Wilk <konrad.wilk@oracle.com> Subject: [Xen-devel] [PATCH 3/9] xen/pciback: Check if the device is found instead of blindly assuming so. X-BeenThere: xen-devel@lists.xensource.com X-Mailman-Version: 2.1.5 Precedence: list List-Id: Xen developer discussion <xen-devel.lists.xensource.com> List-Unsubscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe> List-Post: <mailto:xen-devel@lists.xensource.com> List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help> List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=subscribe> Sender: xen-devel-bounces@lists.xensource.com Errors-To: xen-devel-bounces@lists.xensource.com Just in case it is not found, don't try to dereference it. Signed-off-by: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com> --- drivers/xen/xen-pciback/pci_stub.c | 2 ++ 1 files changed, 2 insertions(+), 0 deletions(-) diff --git a/drivers/xen/xen-pciback/pci_stub.c b/drivers/xen/xen-pciback/pci_stub.c index d985b65..55086e9 100644 --- a/drivers/xen/xen-pciback/pci_stub.c +++ b/drivers/xen/xen-pciback/pci_stub.c @@ -222,6 +222,8 @@ void pcistub_put_pci_dev(struct pci_dev *dev) } spin_unlock_irqrestore(&pcistub_devices_lock, flags); + if (!found_psdev) + return; /*hold this lock for avoiding breaking link between * pcistub and xen_pcibk when AER is in processing -- 1.7.4.1 _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel From xen-devel-bounces@lists.xensource.com Thu Sep 29 12:54:47 2011 Return-path: <xen-devel-bounces@lists.xensource.com> Envelope-to: www-data@lists.xensource.com Delivery-date: Thu, 29 Sep 2011 12:54:47 -0700 Received: from localhost ([127.0.0.1] helo=lists.colo.xensource.com) by lists.xensource.com with esmtp (Exim 4.43) id 1R9Mgx-0003CW-9e; Thu, 29 Sep 2011 12:54:47 -0700 Received: from mail27.messagelabs.com ([193.109.254.147]) by lists.xensource.com with esmtp (Exim 4.43) id 1R9MfL-0002d3-01 for xen-devel@lists.xensource.com; Thu, 29 Sep 2011 12:53:07 -0700 X-Env-Sender: konrad@oracle.com X-Msg-Ref: server-8.tower-27.messagelabs.com!1317325965!48665362!1 X-Originating-IP: [148.87.113.117] X-StarScan-Version: 6.4.1; banners=-,-,- X-VirusChecked: Checked Received: (qmail 18408 invoked from network); 29 Sep 2011 19:52:46 -0000 Received: from rcsinet15.oracle.com (HELO rcsinet15.oracle.com) (148.87.113.117) by server-8.tower-27.messagelabs.com with DHE-RSA-AES256-SHA encrypted SMTP; 29 Sep 2011 19:52:46 -0000 Received: from acsinet21.oracle.com (acsinet21.oracle.com [141.146.126.237]) by rcsinet15.oracle.com (Switch-3.4.4/Switch-3.4.4) with ESMTP id p8TJqx9K015426 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Thu, 29 Sep 2011 19:53:01 GMT Received: from acsmt356.oracle.com (acsmt356.oracle.com [141.146.40.156]) by acsinet21.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id p8TJqwOd012574 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 29 Sep 2011 19:52:59 GMT Received: from abhmt117.oracle.com (abhmt117.oracle.com [141.146.116.69]) by acsmt356.oracle.com (8.12.11.20060308/8.12.11) with ESMTP id p8TJqrvp003021; Thu, 29 Sep 2011 14:52:53 -0500 Received: from oracle.com (/207.172.105.198) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Thu, 29 Sep 2011 12:52:53 -0700 Received: by oracle.com (Postfix, from userid 1000) id A770E154A; Thu, 29 Sep 2011 15:52:52 -0400 (EDT) From: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com> To: linux-kernel@vger.kernel.org Date: Thu, 29 Sep 2011 15:52:42 -0400 Message-Id: <1317325971-21603-1-git-send-email-konrad.wilk@oracle.com> X-Mailer: git-send-email 1.7.4.1 X-Source-IP: acsinet21.oracle.com [141.146.126.237] X-Auth-Type: Internal IP X-CT-RefId: str=0001.0A090209.4E84CC9D.0085:SCFMA922111,ss=1,re=-4.000,fgs=0 Cc: xen-devel@lists.xensource.com, Dan Carpenter <error27@gmail.com> Subject: [Xen-devel] [PATCH] Xen bug-fixes for 3.2 (v1) X-BeenThere: xen-devel@lists.xensource.com X-Mailman-Version: 2.1.5 Precedence: list List-Id: Xen developer discussion <xen-devel.lists.xensource.com> List-Unsubscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe> List-Post: <mailto:xen-devel@lists.xensource.com> List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help> List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=subscribe> Sender: xen-devel-bounces@lists.xensource.com Errors-To: xen-devel-bounces@lists.xensource.com Most of them were discovered by running Dan's static analyzer (git://repo.or.cz/smatch.git). Some of them look/sound familiar which probably means at some point somebody emailed me it and I forgot it - if that is the case, please point me to it so I can use that instead of these. Please review. Konrad Rzeszutek Wilk (9): xen/pciback: Do not dereference psdev during printk when it is NULL. xen/pciback: Return proper error code from sscanf. xen/pciback: Check if the device is found instead of blindly assuming so. xen/events: BUG() when we can't allocate our event->irq array. xen/events: Don't check the info for NULL as it is already done. xen/irq: If we fail during msi_capability_init return proper error code. xen/xenbus: Check before dereferencing it. xen/enlighten: Fix compile warnings. xen/p2m/debugfs: Fix potential pointer exception. arch/x86/pci/xen.c | 10 +++++++--- arch/x86/xen/enlighten.c | 2 +- arch/x86/xen/p2m.c | 4 ++-- drivers/xen/events.c | 11 +++++++---- drivers/xen/xen-pciback/pci_stub.c | 12 ++++++++---- drivers/xen/xenbus/xenbus_probe_backend.c | 3 ++- 6 files changed, 27 insertions(+), 15 deletions(-) _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel From xen-devel-bounces@lists.xensource.com Thu Sep 29 12:55:38 2011 Return-path: <xen-devel-bounces@lists.xensource.com> Envelope-to: www-data@lists.xensource.com Delivery-date: Thu, 29 Sep 2011 12:55:38 -0700 Received: from localhost ([127.0.0.1] helo=lists.colo.xensource.com) by lists.xensource.com with esmtp (Exim 4.43) id 1R9Mhm-0003ZE-IC; Thu, 29 Sep 2011 12:55:38 -0700 Received: from mail21.messagelabs.com ([85.158.143.35]) by lists.xensource.com with esmtp (Exim 4.43) id 1R9MfL-0002d4-2g for xen-devel@lists.xensource.com; Thu, 29 Sep 2011 12:53:07 -0700 X-Env-Sender: konrad@oracle.com X-Msg-Ref: server-3.tower-21.messagelabs.com!1317325993!53481136!1 X-Originating-IP: [148.87.113.117] X-StarScan-Version: 6.4.1; banners=-,-,- X-VirusChecked: Checked Received: (qmail 26444 invoked from network); 29 Sep 2011 19:53:15 -0000 Received: from rcsinet15.oracle.com (HELO rcsinet15.oracle.com) (148.87.113.117) by server-3.tower-21.messagelabs.com with DHE-RSA-AES256-SHA encrypted SMTP; 29 Sep 2011 19:53:15 -0000 Received: from ucsinet23.oracle.com (ucsinet23.oracle.com [156.151.31.71]) by rcsinet15.oracle.com (Switch-3.4.4/Switch-3.4.4) with ESMTP id p8TJqxwB015432 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Thu, 29 Sep 2011 19:53:01 GMT Received: from acsmt356.oracle.com (acsmt356.oracle.com [141.146.40.156]) by ucsinet23.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id p8TJqxeF011480 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 29 Sep 2011 19:52:59 GMT Received: from abhmt109.oracle.com (abhmt109.oracle.com [141.146.116.61]) by acsmt356.oracle.com (8.12.11.20060308/8.12.11) with ESMTP id p8TJqrIr003022; Thu, 29 Sep 2011 14:52:53 -0500 Received: from oracle.com (/207.172.105.198) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Thu, 29 Sep 2011 12:52:53 -0700 Received: by oracle.com (Postfix, from userid 1000) id B0DC6154C; Thu, 29 Sep 2011 15:52:52 -0400 (EDT) From: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com> To: linux-kernel@vger.kernel.org Date: Thu, 29 Sep 2011 15:52:43 -0400 Message-Id: <1317325971-21603-2-git-send-email-konrad.wilk@oracle.com> X-Mailer: git-send-email 1.7.4.1 In-Reply-To: <1317325971-21603-1-git-send-email-konrad.wilk@oracle.com> References: <1317325971-21603-1-git-send-email-konrad.wilk@oracle.com> X-Source-IP: ucsinet23.oracle.com [156.151.31.71] X-CT-RefId: str=0001.0A090206.4E84CC9D.00C4,ss=1,re=0.000,fgs=0 Cc: xen-devel@lists.xensource.com, Dan Carpenter <error27@gmail.com>, Konrad Rzeszutek Wilk <konrad.wilk@oracle.com> Subject: [Xen-devel] [PATCH 1/9] xen/pciback: Do not dereference psdev during printk when it is NULL. X-BeenThere: xen-devel@lists.xensource.com X-Mailman-Version: 2.1.5 Precedence: list List-Id: Xen developer discussion <xen-devel.lists.xensource.com> List-Unsubscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe> List-Post: <mailto:xen-devel@lists.xensource.com> List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help> List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=subscribe> Sender: xen-devel-bounces@lists.xensource.com Errors-To: xen-devel-bounces@lists.xensource.com . instead use printk(.. facility. Signed-off-by: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com> --- drivers/xen/xen-pciback/pci_stub.c | 8 +++++--- 1 files changed, 5 insertions(+), 3 deletions(-) diff --git a/drivers/xen/xen-pciback/pci_stub.c b/drivers/xen/xen-pciback/pci_stub.c index aec214a..32d6891 100644 --- a/drivers/xen/xen-pciback/pci_stub.c +++ b/drivers/xen/xen-pciback/pci_stub.c @@ -514,9 +514,11 @@ static void kill_domain_by_device(struct pcistub_device *psdev) int err; char nodename[PCI_NODENAME_MAX]; - if (!psdev) - dev_err(&psdev->dev->dev, - "device is NULL when do AER recovery/kill_domain\n"); + if (!psdev) { + printk(KERN_ERR DRV_NAME + ":device is NULL when do AER recovery/kill_domain\n"); + return; + } snprintf(nodename, PCI_NODENAME_MAX, "/local/domain/0/backend/pci/%d/0", psdev->pdev->xdev->otherend_id); nodename[strlen(nodename)] = '\0'; -- 1.7.4.1 _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel From xen-devel-bounces@lists.xensource.com Thu Sep 29 12:56:27 2011 Return-path: <xen-devel-bounces@lists.xensource.com> Envelope-to: www-data@lists.xensource.com Delivery-date: Thu, 29 Sep 2011 12:56:27 -0700 Received: from localhost ([127.0.0.1] helo=lists.colo.xensource.com) by lists.xensource.com with esmtp (Exim 4.43) id 1R9MiZ-0003vq-Md; Thu, 29 Sep 2011 12:56:27 -0700 Received: from mail216.messagelabs.com ([85.158.143.99]) by lists.xensource.com with esmtp (Exim 4.43) id 1R9MfL-0002d5-Hq for xen-devel@lists.xensource.com; Thu, 29 Sep 2011 12:53:07 -0700 X-Env-Sender: konrad@oracle.com X-Msg-Ref: server-4.tower-216.messagelabs.com!1317325983!20036713!1 X-Originating-IP: [148.87.113.117] X-StarScan-Version: 6.4.1; banners=-,-,- X-VirusChecked: Checked Received: (qmail 5240 invoked from network); 29 Sep 2011 19:53:04 -0000 Received: from rcsinet15.oracle.com (HELO rcsinet15.oracle.com) (148.87.113.117) by server-4.tower-216.messagelabs.com with DHE-RSA-AES256-SHA encrypted SMTP; 29 Sep 2011 19:53:04 -0000 Received: from acsinet22.oracle.com (acsinet22.oracle.com [141.146.126.238]) by rcsinet15.oracle.com (Switch-3.4.4/Switch-3.4.4) with ESMTP id p8TJqxSG015433 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Thu, 29 Sep 2011 19:53:01 GMT Received: from acsmt358.oracle.com (acsmt358.oracle.com [141.146.40.158]) by acsinet22.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id p8TJqx64020372 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 29 Sep 2011 19:52:59 GMT Received: from abhmt103.oracle.com (abhmt103.oracle.com [141.146.116.55]) by acsmt358.oracle.com (8.12.11.20060308/8.12.11) with ESMTP id p8TJqrAn020657; Thu, 29 Sep 2011 14:52:53 -0500 Received: from oracle.com (/207.172.105.198) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Thu, 29 Sep 2011 12:52:53 -0700 Received: by oracle.com (Postfix, from userid 1000) id D03371550; Thu, 29 Sep 2011 15:52:52 -0400 (EDT) From: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com> To: linux-kernel@vger.kernel.org Date: Thu, 29 Sep 2011 15:52:46 -0400 Message-Id: <1317325971-21603-5-git-send-email-konrad.wilk@oracle.com> X-Mailer: git-send-email 1.7.4.1 In-Reply-To: <1317325971-21603-1-git-send-email-konrad.wilk@oracle.com> References: <1317325971-21603-1-git-send-email-konrad.wilk@oracle.com> X-Source-IP: acsinet22.oracle.com [141.146.126.238] X-Auth-Type: Internal IP X-CT-RefId: str=0001.0A090206.4E84CC9D.0130:SCFMA922111,ss=1,re=-4.000,fgs=0 Cc: xen-devel@lists.xensource.com, Dan Carpenter <error27@gmail.com>, Konrad Rzeszutek Wilk <konrad.wilk@oracle.com> Subject: [Xen-devel] [PATCH 4/9] xen/events: BUG() when we can't allocate our event->irq array. X-BeenThere: xen-devel@lists.xensource.com X-Mailman-Version: 2.1.5 Precedence: list List-Id: Xen developer discussion <xen-devel.lists.xensource.com> List-Unsubscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe> List-Post: <mailto:xen-devel@lists.xensource.com> List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help> List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=subscribe> Sender: xen-devel-bounces@lists.xensource.com Errors-To: xen-devel-bounces@lists.xensource.com In case we can't allocate we are doomed. We should BUG_ON instead of trying to dereference it later on. Signed-off-by: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com> --- drivers/xen/events.c | 2 ++ 1 files changed, 2 insertions(+), 0 deletions(-) diff --git a/drivers/xen/events.c b/drivers/xen/events.c index 7523719..5db04bf 100644 --- a/drivers/xen/events.c +++ b/drivers/xen/events.c @@ -1670,6 +1670,8 @@ void __init xen_init_IRQ(void) evtchn_to_irq = kcalloc(NR_EVENT_CHANNELS, sizeof(*evtchn_to_irq), GFP_KERNEL); + if (!evtchn_to_irq) + BUG(); for (i = 0; i < NR_EVENT_CHANNELS; i++) evtchn_to_irq[i] = -1; -- 1.7.4.1 _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel From xen-devel-bounces@lists.xensource.com Thu Sep 29 12:57:25 2011 Return-path: <xen-devel-bounces@lists.xensource.com> Envelope-to: www-data@lists.xensource.com Delivery-date: Thu, 29 Sep 2011 12:57:25 -0700 Received: from localhost ([127.0.0.1] helo=lists.colo.xensource.com) by lists.xensource.com with esmtp (Exim 4.43) id 1R9MjU-0004K3-Dq; Thu, 29 Sep 2011 12:57:24 -0700 Received: from mail21.messagelabs.com ([85.158.143.35]) by lists.xensource.com with esmtp (Exim 4.43) id 1R9MfL-0002d6-Na for xen-devel@lists.xensource.com; Thu, 29 Sep 2011 12:53:08 -0700 X-Env-Sender: konrad@oracle.com X-Msg-Ref: server-14.tower-21.messagelabs.com!1317325974!61513810!1 X-Originating-IP: [148.87.113.117] X-StarScan-Version: 6.4.1; banners=-,-,- X-VirusChecked: Checked Received: (qmail 30226 invoked from network); 29 Sep 2011 19:52:55 -0000 Received: from rcsinet15.oracle.com (HELO rcsinet15.oracle.com) (148.87.113.117) by server-14.tower-21.messagelabs.com with DHE-RSA-AES256-SHA encrypted SMTP; 29 Sep 2011 19:52:55 -0000 Received: from rtcsinet22.oracle.com (rtcsinet22.oracle.com [66.248.204.30]) by rcsinet15.oracle.com (Switch-3.4.4/Switch-3.4.4) with ESMTP id p8TJr0c5015439 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Thu, 29 Sep 2011 19:53:02 GMT Received: from acsmt357.oracle.com (acsmt357.oracle.com [141.146.40.157]) by rtcsinet22.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id p8TJqxZv003058 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 29 Sep 2011 19:52:59 GMT Received: from abhmt105.oracle.com (abhmt105.oracle.com [141.146.116.57]) by acsmt357.oracle.com (8.12.11.20060308/8.12.11) with ESMTP id p8TJqre9029825; Thu, 29 Sep 2011 14:52:53 -0500 Received: from oracle.com (/207.172.105.198) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Thu, 29 Sep 2011 12:52:53 -0700 Received: by oracle.com (Postfix, from userid 1000) id BC3D5154D; Thu, 29 Sep 2011 15:52:52 -0400 (EDT) From: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com> To: linux-kernel@vger.kernel.org Date: Thu, 29 Sep 2011 15:52:44 -0400 Message-Id: <1317325971-21603-3-git-send-email-konrad.wilk@oracle.com> X-Mailer: git-send-email 1.7.4.1 In-Reply-To: <1317325971-21603-1-git-send-email-konrad.wilk@oracle.com> References: <1317325971-21603-1-git-send-email-konrad.wilk@oracle.com> X-Source-IP: rtcsinet22.oracle.com [66.248.204.30] X-CT-RefId: str=0001.0A090207.4E84CC9E.00A4,ss=1,re=0.000,fgs=0 Cc: xen-devel@lists.xensource.com, Dan Carpenter <error27@gmail.com>, Konrad Rzeszutek Wilk <konrad.wilk@oracle.com> Subject: [Xen-devel] [PATCH 2/9] xen/pciback: Return proper error code from sscanf. X-BeenThere: xen-devel@lists.xensource.com X-Mailman-Version: 2.1.5 Precedence: list List-Id: Xen developer discussion <xen-devel.lists.xensource.com> List-Unsubscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe> List-Post: <mailto:xen-devel@lists.xensource.com> List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help> List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=subscribe> Sender: xen-devel-bounces@lists.xensource.com Errors-To: xen-devel-bounces@lists.xensource.com . instead of just hardcoding it to be -EINVAL. Signed-off-by: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com> --- drivers/xen/xen-pciback/pci_stub.c | 2 +- 1 files changed, 1 insertions(+), 1 deletions(-) diff --git a/drivers/xen/xen-pciback/pci_stub.c b/drivers/xen/xen-pciback/pci_stub.c index 32d6891..d985b65 100644 --- a/drivers/xen/xen-pciback/pci_stub.c +++ b/drivers/xen/xen-pciback/pci_stub.c @@ -868,7 +868,7 @@ static inline int str_to_slot(const char *buf, int *domain, int *bus, if (err == 4) return 0; else if (err < 0) - return -EINVAL; + return err; /* try again without domain */ *domain = 0; -- 1.7.4.1 _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel From xen-devel-bounces@lists.xensource.com Thu Sep 29 13:00:36 2011 Return-path: <xen-devel-bounces@lists.xensource.com> Envelope-to: www-data@lists.xensource.com Delivery-date: Thu, 29 Sep 2011 13:00:36 -0700 Received: from localhost ([127.0.0.1] helo=lists.colo.xensource.com) by lists.xensource.com with esmtp (Exim 4.43) id 1R9MmZ-0004iN-0S; Thu, 29 Sep 2011 13:00:35 -0700 Received: from mail27.messagelabs.com ([193.109.254.147]) by lists.xensource.com with esmtp (Exim 4.43) id 1R9MfM-0002d7-1z for xen-devel@lists.xensource.com; Thu, 29 Sep 2011 12:53:08 -0700 X-Env-Sender: konrad@oracle.com X-Msg-Ref: server-7.tower-27.messagelabs.com!1317325958!50701130!1 X-Originating-IP: [148.87.113.117] X-StarScan-Version: 6.4.1; banners=-,-,- X-VirusChecked: Checked Received: (qmail 14382 invoked from network); 29 Sep 2011 19:52:40 -0000 Received: from rcsinet15.oracle.com (HELO rcsinet15.oracle.com) (148.87.113.117) by server-7.tower-27.messagelabs.com with DHE-RSA-AES256-SHA encrypted SMTP; 29 Sep 2011 19:52:40 -0000 Received: from acsinet22.oracle.com (acsinet22.oracle.com [141.146.126.238]) by rcsinet15.oracle.com (Switch-3.4.4/Switch-3.4.4) with ESMTP id p8TJr06A015495 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Thu, 29 Sep 2011 19:53:02 GMT Received: from acsmt356.oracle.com (acsmt356.oracle.com [141.146.40.156]) by acsinet22.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id p8TJqx5P020383 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 29 Sep 2011 19:53:00 GMT Received: from abhmt109.oracle.com (abhmt109.oracle.com [141.146.116.61]) by acsmt356.oracle.com (8.12.11.20060308/8.12.11) with ESMTP id p8TJqspx003046; Thu, 29 Sep 2011 14:52:54 -0500 Received: from oracle.com (/207.172.105.198) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Thu, 29 Sep 2011 12:52:54 -0700 Received: by oracle.com (Postfix, from userid 1000) id 085621562; Thu, 29 Sep 2011 15:52:53 -0400 (EDT) From: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com> To: linux-kernel@vger.kernel.org Date: Thu, 29 Sep 2011 15:52:51 -0400 Message-Id: <1317325971-21603-10-git-send-email-konrad.wilk@oracle.com> X-Mailer: git-send-email 1.7.4.1 In-Reply-To: <1317325971-21603-1-git-send-email-konrad.wilk@oracle.com> References: <1317325971-21603-1-git-send-email-konrad.wilk@oracle.com> X-Source-IP: acsinet22.oracle.com [141.146.126.238] X-Auth-Type: Internal IP X-CT-RefId: str=0001.0A090209.4E84CC9E.00C4:SCFMA922111,ss=1,re=-4.000,fgs=0 Cc: xen-devel@lists.xensource.com, Dan Carpenter <error27@gmail.com>, Konrad Rzeszutek Wilk <konrad.wilk@oracle.com> Subject: [Xen-devel] [PATCH 9/9] xen/p2m/debugfs: Fix potential pointer exception. X-BeenThere: xen-devel@lists.xensource.com X-Mailman-Version: 2.1.5 Precedence: list List-Id: Xen developer discussion <xen-devel.lists.xensource.com> List-Unsubscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe> List-Post: <mailto:xen-devel@lists.xensource.com> List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help> List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=subscribe> Sender: xen-devel-bounces@lists.xensource.com Errors-To: xen-devel-bounces@lists.xensource.com We could be referencing the last + 1 element of level_name[] array which would cause a pointer exception. Signed-off-by: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com> --- arch/x86/xen/p2m.c | 4 ++-- 1 files changed, 2 insertions(+), 2 deletions(-) diff --git a/arch/x86/xen/p2m.c b/arch/x86/xen/p2m.c index 58efeb9..bc4cf0a 100644 --- a/arch/x86/xen/p2m.c +++ b/arch/x86/xen/p2m.c @@ -786,9 +786,9 @@ EXPORT_SYMBOL_GPL(m2p_find_override_pfn); int p2m_dump_show(struct seq_file *m, void *v) { static const char * const level_name[] = { "top", "middle", - "entry", "abnormal" }; + "entry", "abnormal", NULL}; static const char * const type_name[] = { "identity", "missing", - "pfn", "abnormal"}; + "pfn", "abnormal", NULL}; #define TYPE_IDENTITY 0 #define TYPE_MISSING 1 #define TYPE_PFN 2 -- 1.7.4.1 _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel From xen-devel-bounces@lists.xensource.com Thu Sep 29 13:03:57 2011 Return-path: <xen-devel-bounces@lists.xensource.com> Envelope-to: www-data@lists.xensource.com Delivery-date: Thu, 29 Sep 2011 13:03:57 -0700 Received: from localhost ([127.0.0.1] helo=lists.colo.xensource.com) by lists.xensource.com with esmtp (Exim 4.43) id 1R9Mpn-00056z-VZ; Thu, 29 Sep 2011 13:03:56 -0700 Received: from mail216.messagelabs.com ([85.158.143.99]) by lists.xensource.com with esmtp (Exim 4.43) id 1R9MfM-0002d8-0h for xen-devel@lists.xensource.com; Thu, 29 Sep 2011 12:53:08 -0700 X-Env-Sender: konrad@oracle.com X-Msg-Ref: server-8.tower-216.messagelabs.com!1317325983!16940311!1 X-Originating-IP: [148.87.113.117] X-StarScan-Version: 6.4.1; banners=-,-,- X-VirusChecked: Checked Received: (qmail 13321 invoked from network); 29 Sep 2011 19:53:04 -0000 Received: from rcsinet15.oracle.com (HELO rcsinet15.oracle.com) (148.87.113.117) by server-8.tower-216.messagelabs.com with DHE-RSA-AES256-SHA encrypted SMTP; 29 Sep 2011 19:53:04 -0000 Received: from acsinet21.oracle.com (acsinet21.oracle.com [141.146.126.237]) by rcsinet15.oracle.com (Switch-3.4.4/Switch-3.4.4) with ESMTP id p8TJr0ZY015496 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Thu, 29 Sep 2011 19:53:02 GMT Received: from acsmt357.oracle.com (acsmt357.oracle.com [141.146.40.157]) by acsinet21.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id p8TJqxRb012585 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 29 Sep 2011 19:53:00 GMT Received: from abhmt104.oracle.com (abhmt104.oracle.com [141.146.116.56]) by acsmt357.oracle.com (8.12.11.20060308/8.12.11) with ESMTP id p8TJqsdF029836; Thu, 29 Sep 2011 14:52:54 -0500 Received: from oracle.com (/207.172.105.198) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Thu, 29 Sep 2011 12:52:54 -0700 Received: by oracle.com (Postfix, from userid 1000) id E34C81556; Thu, 29 Sep 2011 15:52:52 -0400 (EDT) From: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com> To: linux-kernel@vger.kernel.org Date: Thu, 29 Sep 2011 15:52:48 -0400 Message-Id: <1317325971-21603-7-git-send-email-konrad.wilk@oracle.com> X-Mailer: git-send-email 1.7.4.1 In-Reply-To: <1317325971-21603-1-git-send-email-konrad.wilk@oracle.com> References: <1317325971-21603-1-git-send-email-konrad.wilk@oracle.com> X-Source-IP: acsinet21.oracle.com [141.146.126.237] X-Auth-Type: Internal IP X-CT-RefId: str=0001.0A090207.4E84CC9E.00F1:SCFMA922111,ss=1,re=-4.000,fgs=0 Cc: xen-devel@lists.xensource.com, Dan Carpenter <error27@gmail.com>, Konrad Rzeszutek Wilk <konrad.wilk@oracle.com> Subject: [Xen-devel] [PATCH 6/9] xen/irq: If we fail during msi_capability_init return proper error code. X-BeenThere: xen-devel@lists.xensource.com X-Mailman-Version: 2.1.5 Precedence: list List-Id: Xen developer discussion <xen-devel.lists.xensource.com> List-Unsubscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe> List-Post: <mailto:xen-devel@lists.xensource.com> List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help> List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=subscribe> Sender: xen-devel-bounces@lists.xensource.com Errors-To: xen-devel-bounces@lists.xensource.com There are three different modes: PV, HVM, and initial domain 0. In all the cases we would return -1 for failure instead of a proper error code. Fix this by propagating the error code from the generic IRQ code. Signed-off-by: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com> --- arch/x86/pci/xen.c | 10 +++++++--- drivers/xen/events.c | 7 ++++--- 2 files changed, 11 insertions(+), 6 deletions(-) diff --git a/arch/x86/pci/xen.c b/arch/x86/pci/xen.c index 1017c7b..11a9301 100644 --- a/arch/x86/pci/xen.c +++ b/arch/x86/pci/xen.c @@ -175,8 +175,10 @@ static int xen_setup_msi_irqs(struct pci_dev *dev, int nvec, int type) "pcifront-msi-x" : "pcifront-msi", DOMID_SELF); - if (irq < 0) + if (irq < 0) { + ret = irq; goto free; + } i++; } kfree(v); @@ -221,8 +223,10 @@ static int xen_hvm_setup_msi_irqs(struct pci_dev *dev, int nvec, int type) if (msg.data != XEN_PIRQ_MSI_DATA || xen_irq_from_pirq(pirq) < 0) { pirq = xen_allocate_pirq_msi(dev, msidesc); - if (pirq < 0) + if (pirq < 0) { + irq = -ENODEV; goto error; + } xen_msi_compose_msg(dev, pirq, &msg); __write_msi_msg(msidesc, &msg); dev_dbg(&dev->dev, "xen: msi bound to pirq=%d\n", pirq); @@ -244,7 +248,7 @@ static int xen_hvm_setup_msi_irqs(struct pci_dev *dev, int nvec, int type) error: dev_err(&dev->dev, "Xen PCI frontend has not registered MSI/MSI-X support!\n"); - return -ENODEV; + return irq; } #ifdef CONFIG_XEN_DOM0 diff --git a/drivers/xen/events.c b/drivers/xen/events.c index 71d2363..93c69ee 100644 --- a/drivers/xen/events.c +++ b/drivers/xen/events.c @@ -432,7 +432,8 @@ static int __must_check xen_allocate_irq_dynamic(void) irq = irq_alloc_desc_from(first, -1); - xen_irq_init(irq); + if (irq >= 0) + xen_irq_init(irq); return irq; } @@ -713,7 +714,7 @@ int xen_bind_pirq_msi_to_irq(struct pci_dev *dev, struct msi_desc *msidesc, mutex_lock(&irq_mapping_update_lock); irq = xen_allocate_irq_dynamic(); - if (irq == -1) + if (irq < 0) goto out; irq_set_chip_and_handler_name(irq, &xen_pirq_chip, handle_edge_irq, @@ -729,7 +730,7 @@ out: error_irq: mutex_unlock(&irq_mapping_update_lock); xen_free_irq(irq); - return -1; + return ret; } #endif -- 1.7.4.1 _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel From xen-devel-bounces@lists.xensource.com Thu Sep 29 13:07:50 2011 Return-path: <xen-devel-bounces@lists.xensource.com> Envelope-to: www-data@lists.xensource.com Delivery-date: Thu, 29 Sep 2011 13:07:50 -0700 Received: from localhost ([127.0.0.1] helo=lists.colo.xensource.com) by lists.xensource.com with esmtp (Exim 4.43) id 1R9MtZ-0005b9-W5; Thu, 29 Sep 2011 13:07:50 -0700 Received: from mail27.messagelabs.com ([193.109.254.147]) by lists.xensource.com with esmtp (Exim 4.43) id 1R9MfN-0002dB-2y for xen-devel@lists.xensource.com; Thu, 29 Sep 2011 12:53:09 -0700 X-Env-Sender: konrad@oracle.com X-Msg-Ref: server-14.tower-27.messagelabs.com!1317325873!38182126!1 X-Originating-IP: [148.87.113.117] X-StarScan-Version: 6.4.1; banners=-,-,- X-VirusChecked: Checked Received: (qmail 22941 invoked from network); 29 Sep 2011 19:51:14 -0000 Received: from rcsinet15.oracle.com (HELO rcsinet15.oracle.com) (148.87.113.117) by server-14.tower-27.messagelabs.com with DHE-RSA-AES256-SHA encrypted SMTP; 29 Sep 2011 19:51:14 -0000 Received: from rtcsinet21.oracle.com (rtcsinet21.oracle.com [66.248.204.29]) by rcsinet15.oracle.com (Switch-3.4.4/Switch-3.4.4) with ESMTP id p8TJr1Hk015734 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Thu, 29 Sep 2011 19:53:03 GMT Received: from acsmt358.oracle.com (acsmt358.oracle.com [141.146.40.158]) by rtcsinet21.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id p8TJr0Ha000050 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 29 Sep 2011 19:53:01 GMT Received: from abhmt106.oracle.com (abhmt106.oracle.com [141.146.116.58]) by acsmt358.oracle.com (8.12.11.20060308/8.12.11) with ESMTP id p8TJqsHe020668; Thu, 29 Sep 2011 14:52:54 -0500 Received: from oracle.com (/207.172.105.198) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Thu, 29 Sep 2011 12:52:54 -0700 Received: by oracle.com (Postfix, from userid 1000) id DAC281555; Thu, 29 Sep 2011 15:52:52 -0400 (EDT) From: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com> To: linux-kernel@vger.kernel.org Date: Thu, 29 Sep 2011 15:52:47 -0400 Message-Id: <1317325971-21603-6-git-send-email-konrad.wilk@oracle.com> X-Mailer: git-send-email 1.7.4.1 In-Reply-To: <1317325971-21603-1-git-send-email-konrad.wilk@oracle.com> References: <1317325971-21603-1-git-send-email-konrad.wilk@oracle.com> X-Source-IP: rtcsinet21.oracle.com [66.248.204.29] X-CT-RefId: str=0001.0A090206.4E84CC9F.0065,ss=1,re=0.000,fgs=0 Cc: xen-devel@lists.xensource.com, Dan Carpenter <error27@gmail.com>, Konrad Rzeszutek Wilk <konrad.wilk@oracle.com> Subject: [Xen-devel] [PATCH 5/9] xen/events: Don't check the info for NULL as it is already done. X-BeenThere: xen-devel@lists.xensource.com X-Mailman-Version: 2.1.5 Precedence: list List-Id: Xen developer discussion <xen-devel.lists.xensource.com> List-Unsubscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe> List-Post: <mailto:xen-devel@lists.xensource.com> List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help> List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=subscribe> Sender: xen-devel-bounces@lists.xensource.com Errors-To: xen-devel-bounces@lists.xensource.com The list operation checks whether the 'info' structure that is retrieved from the list is NULL (otherwise it would not been able to retrieve it). This check is not neccessary. Signed-off-by: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com> --- drivers/xen/events.c | 2 +- 1 files changed, 1 insertions(+), 1 deletions(-) diff --git a/drivers/xen/events.c b/drivers/xen/events.c index 5db04bf..71d2363 100644 --- a/drivers/xen/events.c +++ b/drivers/xen/events.c @@ -779,7 +779,7 @@ int xen_irq_from_pirq(unsigned pirq) mutex_lock(&irq_mapping_update_lock); list_for_each_entry(info, &xen_irq_list_head, list) { - if (info == NULL || info->type != IRQT_PIRQ) + if (info->type != IRQT_PIRQ) continue; irq = info->irq; if (info->u.pirq.pirq == pirq) -- 1.7.4.1 _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel From xen-devel-bounces@lists.xensource.com Thu Sep 29 13:09:26 2011 Return-path: <xen-devel-bounces@lists.xensource.com> Envelope-to: www-data@lists.xensource.com Delivery-date: Thu, 29 Sep 2011 13:09:26 -0700 Received: from localhost ([127.0.0.1] helo=lists.colo.xensource.com) by lists.xensource.com with esmtp (Exim 4.43) id 1R9Mv8-0005yg-AO; Thu, 29 Sep 2011 13:09:26 -0700 Received: from mail182.messagelabs.com ([85.158.139.83]) by lists.xensource.com with esmtp (Exim 4.43) id 1R9MfM-0002d9-Qy for xen-devel@lists.xensource.com; Thu, 29 Sep 2011 12:53:09 -0700 X-Env-Sender: konrad@oracle.com X-Msg-Ref: server-3.tower-182.messagelabs.com!1317325984!17480642!1 X-Originating-IP: [148.87.113.117] X-StarScan-Version: 6.4.1; banners=-,-,- X-VirusChecked: Checked Received: (qmail 32707 invoked from network); 29 Sep 2011 19:53:05 -0000 Received: from rcsinet15.oracle.com (HELO rcsinet15.oracle.com) (148.87.113.117) by server-3.tower-182.messagelabs.com with DHE-RSA-AES256-SHA encrypted SMTP; 29 Sep 2011 19:53:05 -0000 Received: from ucsinet24.oracle.com (ucsinet24.oracle.com [156.151.31.67]) by rcsinet15.oracle.com (Switch-3.4.4/Switch-3.4.4) with ESMTP id p8TJr1u0015629 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Thu, 29 Sep 2011 19:53:02 GMT Received: from acsmt358.oracle.com (acsmt358.oracle.com [141.146.40.158]) by ucsinet24.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id p8TJlJ1g017023 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 29 Sep 2011 19:47:20 GMT Received: from abhmt101.oracle.com (abhmt101.oracle.com [141.146.116.53]) by acsmt358.oracle.com (8.12.11.20060308/8.12.11) with ESMTP id p8TJqs6X020669; Thu, 29 Sep 2011 14:52:55 -0500 Received: from oracle.com (/207.172.105.198) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Thu, 29 Sep 2011 12:52:54 -0700 Received: by oracle.com (Postfix, from userid 1000) id EAAF61559; Thu, 29 Sep 2011 15:52:52 -0400 (EDT) From: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com> To: linux-kernel@vger.kernel.org Date: Thu, 29 Sep 2011 15:52:49 -0400 Message-Id: <1317325971-21603-8-git-send-email-konrad.wilk@oracle.com> X-Mailer: git-send-email 1.7.4.1 In-Reply-To: <1317325971-21603-1-git-send-email-konrad.wilk@oracle.com> References: <1317325971-21603-1-git-send-email-konrad.wilk@oracle.com> X-Source-IP: ucsinet24.oracle.com [156.151.31.67] X-CT-RefId: str=0001.0A090206.4E84CC9E.00F1,ss=1,re=0.000,fgs=0 Cc: xen-devel@lists.xensource.com, Dan Carpenter <error27@gmail.com>, Konrad Rzeszutek Wilk <konrad.wilk@oracle.com> Subject: [Xen-devel] [PATCH 7/9] xen/xenbus: Check before dereferencing it. X-BeenThere: xen-devel@lists.xensource.com X-Mailman-Version: 2.1.5 Precedence: list List-Id: Xen developer discussion <xen-devel.lists.xensource.com> List-Unsubscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe> List-Post: <mailto:xen-devel@lists.xensource.com> List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help> List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=subscribe> Sender: xen-devel-bounces@lists.xensource.com Errors-To: xen-devel-bounces@lists.xensource.com . we do the check whether 'xdev' is NULL - but after we have dereferenced it. Signed-off-by: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com> --- drivers/xen/xenbus/xenbus_probe_backend.c | 3 ++- 1 files changed, 2 insertions(+), 1 deletions(-) diff --git a/drivers/xen/xenbus/xenbus_probe_backend.c b/drivers/xen/xenbus/xenbus_probe_backend.c index 60adf91..331589a 100644 --- a/drivers/xen/xenbus/xenbus_probe_backend.c +++ b/drivers/xen/xenbus/xenbus_probe_backend.c @@ -103,10 +103,11 @@ static int xenbus_uevent_backend(struct device *dev, return -ENODEV; xdev = to_xenbus_device(dev); - bus = container_of(xdev->dev.bus, struct xen_bus_type, bus); if (xdev == NULL) return -ENODEV; + bus = container_of(xdev->dev.bus, struct xen_bus_type, bus); + if (add_uevent_var(env, "MODALIAS=xen-backend:%s", xdev->devicetype)) return -ENOMEM; -- 1.7.4.1 _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel From xen-devel-bounces@lists.xensource.com Thu Sep 29 13:11:26 2011 Return-path: <xen-devel-bounces@lists.xensource.com> Envelope-to: www-data@lists.xensource.com Delivery-date: Thu, 29 Sep 2011 13:11:26 -0700 Received: from localhost ([127.0.0.1] helo=lists.colo.xensource.com) by lists.xensource.com with esmtp (Exim 4.43) id 1R9Mx3-0006N4-Ao; Thu, 29 Sep 2011 13:11:25 -0700 Received: from mail174.messagelabs.com ([85.158.138.51]) by lists.xensource.com with esmtp (Exim 4.43) id 1R9MfN-0002dC-8l for xen-devel@lists.xensource.com; Thu, 29 Sep 2011 12:53:09 -0700 X-Env-Sender: konrad@oracle.com X-Msg-Ref: server-14.tower-174.messagelabs.com!1317325984!33284432!1 X-Originating-IP: [148.87.113.117] X-StarScan-Version: 6.4.1; banners=-,-,- X-VirusChecked: Checked Received: (qmail 30578 invoked from network); 29 Sep 2011 19:53:05 -0000 Received: from rcsinet15.oracle.com (HELO rcsinet15.oracle.com) (148.87.113.117) by server-14.tower-174.messagelabs.com with DHE-RSA-AES256-SHA encrypted SMTP; 29 Sep 2011 19:53:05 -0000 Received: from rtcsinet21.oracle.com (rtcsinet21.oracle.com [66.248.204.29]) by rcsinet15.oracle.com (Switch-3.4.4/Switch-3.4.4) with ESMTP id p8TJr0JO015500 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Thu, 29 Sep 2011 19:53:02 GMT Received: from acsmt356.oracle.com (acsmt356.oracle.com [141.146.40.156]) by rtcsinet21.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id p8TJqxXx000041 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 29 Sep 2011 19:53:00 GMT Received: from abhmt110.oracle.com (abhmt110.oracle.com [141.146.116.62]) by acsmt356.oracle.com (8.12.11.20060308/8.12.11) with ESMTP id p8TJqsKF003045; Thu, 29 Sep 2011 14:52:54 -0500 Received: from oracle.com (/207.172.105.198) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Thu, 29 Sep 2011 12:52:54 -0700 Received: by oracle.com (Postfix, from userid 1000) id F3A66155D; Thu, 29 Sep 2011 15:52:52 -0400 (EDT) From: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com> To: linux-kernel@vger.kernel.org Date: Thu, 29 Sep 2011 15:52:50 -0400 Message-Id: <1317325971-21603-9-git-send-email-konrad.wilk@oracle.com> X-Mailer: git-send-email 1.7.4.1 In-Reply-To: <1317325971-21603-1-git-send-email-konrad.wilk@oracle.com> References: <1317325971-21603-1-git-send-email-konrad.wilk@oracle.com> MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable X-Source-IP: rtcsinet21.oracle.com [66.248.204.29] X-CT-RefId: str=0001.0A090206.4E84CC9F.0025,ss=1,re=0.000,fgs=0 Cc: xen-devel@lists.xensource.com, Dan Carpenter <error27@gmail.com>, Konrad Rzeszutek Wilk <konrad.wilk@oracle.com> Subject: [Xen-devel] [PATCH 8/9] xen/enlighten: Fix compile warnings. X-BeenThere: xen-devel@lists.xensource.com X-Mailman-Version: 2.1.5 Precedence: list List-Id: Xen developer discussion <xen-devel.lists.xensource.com> List-Unsubscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe> List-Post: <mailto:xen-devel@lists.xensource.com> List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help> List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=subscribe> Sender: xen-devel-bounces@lists.xensource.com Errors-To: xen-devel-bounces@lists.xensource.com linux/arch/x86/xen/enlighten.c: In function =E2=80=98xen_start_kernel=E2=80= =99: linux/arch/x86/xen/enlighten.c:226: warning: =E2=80=98cx=E2=80=99 may be = used uninitialized in this function linux/arch/x86/xen/enlighten.c:240: note: =E2=80=98cx=E2=80=99 was declar= ed here Signed-off-by: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com> --- arch/x86/xen/enlighten.c | 2 +- 1 files changed, 1 insertions(+), 1 deletions(-) diff --git a/arch/x86/xen/enlighten.c b/arch/x86/xen/enlighten.c index 2d69617..9473861 100644 --- a/arch/x86/xen/enlighten.c +++ b/arch/x86/xen/enlighten.c @@ -237,7 +237,7 @@ static void xen_cpuid(unsigned int *ax, unsigned int = *bx, =20 static void __init xen_init_cpuid_mask(void) { - unsigned int ax, bx, cx, dx; + unsigned int ax, bx, uninitialized_var(cx), dx; unsigned int xsave_mask; =20 cpuid_leaf1_edx_mask =3D --=20 1.7.4.1 _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel From xen-devel-bounces@lists.xensource.com Thu Sep 29 13:18:22 2011 Return-path: <xen-devel-bounces@lists.xensource.com> Envelope-to: www-data@lists.xensource.com Delivery-date: Thu, 29 Sep 2011 13:18:22 -0700 Received: from localhost ([127.0.0.1] helo=lists.colo.xensource.com) by lists.xensource.com with esmtp (Exim 4.43) id 1R9N3m-0006p8-9c; Thu, 29 Sep 2011 13:18:22 -0700 Received: from mail21.messagelabs.com ([85.158.143.35]) by lists.xensource.com with esmtp (Exim 4.43) id 1R9N2K-0006bi-4R for xen-devel@lists.xensource.com; Thu, 29 Sep 2011 13:16:52 -0700 X-Env-Sender: davidxu06@gmail.com X-Msg-Ref: server-15.tower-21.messagelabs.com!1317327409!52501942!1 X-Originating-IP: [209.85.161.171] X-StarScan-Version: 6.4.1; banners=-,-,- X-VirusChecked: Checked Received: (qmail 14048 invoked from network); 29 Sep 2011 20:16:50 -0000 Received: from mail-gx0-f171.google.com (HELO mail-gx0-f171.google.com) (209.85.161.171) by server-15.tower-21.messagelabs.com with RC4-SHA encrypted SMTP; 29 Sep 2011 20:16:50 -0000 Received: by ggnk4 with SMTP id k4so207483ggn.30 for <xen-devel@lists.xensource.com>; Thu, 29 Sep 2011 13:16:47 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:date:message-id:subject:from:to:content-type; bh=0RTO4avqHPjVyboFIjiNXNlLNJ5NsdZ9co4WOyxw3yE=; b=ulxvDbn6hZmKE0+yA6hKQzYonfZi7cuhWmcI5onK2bNkyhNcJXUPedT/j19C0RUunu I4l8311VIU16gxzXIjJHbFcKr12bgw/aB//7PhYGb+t+9u/xH0GmS6LKQoCBUJPdKuUx uMndCx7MqOLBQzMrqmbre0JGPw8YJDKp6G3Y0= MIME-Version: 1.0 Received: by 10.150.146.19 with SMTP id t19mr6889187ybd.152.1317327407675; Thu, 29 Sep 2011 13:16:47 -0700 (PDT) Received: by 10.150.157.13 with HTTP; Thu, 29 Sep 2011 13:16:47 -0700 (PDT) Date: Thu, 29 Sep 2011 11:16:47 -0900 Message-ID: <CAGjowiSLv2Wa9KgfVBmi9yZ5OBPvbX9NYb+3BaDg=iVbty-kuA@mail.gmail.com> From: David Xu <davidxu06@gmail.com> To: xen-devel <xen-devel@lists.xensource.com> Content-Type: text/plain; charset=ISO-8859-1 Subject: [Xen-devel] use hypercall in Dom0's kernel X-BeenThere: xen-devel@lists.xensource.com X-Mailman-Version: 2.1.5 Precedence: list List-Id: Xen developer discussion <xen-devel.lists.xensource.com> List-Unsubscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe> List-Post: <mailto:xen-devel@lists.xensource.com> List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help> List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=subscribe> Sender: xen-devel-bounces@lists.xensource.com Errors-To: xen-devel-bounces@lists.xensource.com Hi, Do you know how to call hypercall or call some interface function of Xen in the ring1 level. In other words, I want to call hypercall or some interface function of Xen from the Dom0's kernel module. Thanks. Regards, Cong _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel From xen-devel-bounces@lists.xensource.com Thu Sep 29 13:20:03 2011 Return-path: <xen-devel-bounces@lists.xensource.com> Envelope-to: www-data@lists.xensource.com Delivery-date: Thu, 29 Sep 2011 13:20:03 -0700 Received: from localhost ([127.0.0.1] helo=lists.colo.xensource.com) by lists.xensource.com with esmtp (Exim 4.43) id 1R9N5O-0007Du-JM; Thu, 29 Sep 2011 13:20:03 -0700 Received: from mail27.messagelabs.com ([193.109.254.147]) by lists.xensource.com with esmtp (Exim 4.43) id 1R9N3s-0006qs-SX for xen-devel@lists.xensource.com; Thu, 29 Sep 2011 13:18:30 -0700 X-Env-Sender: konrad@oracle.com X-Msg-Ref: server-7.tower-27.messagelabs.com!1317327479!50702814!1 X-Originating-IP: [148.87.113.117] X-StarScan-Version: 6.4.1; banners=-,-,- X-VirusChecked: Checked Received: (qmail 19696 invoked from network); 29 Sep 2011 20:18:01 -0000 Received: from rcsinet15.oracle.com (HELO rcsinet15.oracle.com) (148.87.113.117) by server-7.tower-27.messagelabs.com with DHE-RSA-AES256-SHA encrypted SMTP; 29 Sep 2011 20:18:01 -0000 Received: from rtcsinet21.oracle.com (rtcsinet21.oracle.com [66.248.204.29]) by rcsinet15.oracle.com (Switch-3.4.4/Switch-3.4.4) with ESMTP id p8TKH5Eb012773 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Thu, 29 Sep 2011 20:17:07 GMT Received: from acsmt356.oracle.com (acsmt356.oracle.com [141.146.40.156]) by rtcsinet21.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id p8TKH3bS028405 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 29 Sep 2011 20:17:04 GMT Received: from abhmt101.oracle.com (abhmt101.oracle.com [141.146.116.53]) by acsmt356.oracle.com (8.12.11.20060308/8.12.11) with ESMTP id p8TKGvom021867; Thu, 29 Sep 2011 15:16:58 -0500 Received: from oracle.com (/207.172.105.198) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Thu, 29 Sep 2011 13:16:57 -0700 Received: by oracle.com (Postfix, from userid 1000) id 19099154C; Thu, 29 Sep 2011 16:16:56 -0400 (EDT) From: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com> To: linux-kernel@vger.kernel.org, rjw@sisk.pl, tglx@linutronix.de, hpa@zytor.com, x86@kernel.org, len.brown@intel.com, joseph.cihula@intel.com, shane.wang@intel.com, xen-devel@lists.xensource.com, linux-pm@lists.linux-foundation.org, tboot-devel@lists.sourceforge.net, linux-acpi@vger.kernel.org, liang.tang@oracle.com, ke.yu@intel.com, kevin.tian@intel.com, jeremy@goop.org Date: Thu, 29 Sep 2011 16:16:47 -0400 Message-Id: <1317327414-24072-2-git-send-email-konrad.wilk@oracle.com> X-Mailer: git-send-email 1.7.4.1 In-Reply-To: <1317327414-24072-1-git-send-email-konrad.wilk@oracle.com> References: <1317327414-24072-1-git-send-email-konrad.wilk@oracle.com> X-Source-IP: rtcsinet21.oracle.com [66.248.204.29] X-CT-RefId: str=0001.0A090209.4E84D244.002F,ss=1,re=0.000,fgs=0 Cc: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com> Subject: [Xen-devel] [PATCH 1/8] x86: Expand the x86_msi_ops to have a restore MSIs. X-BeenThere: xen-devel@lists.xensource.com X-Mailman-Version: 2.1.5 Precedence: list List-Id: Xen developer discussion <xen-devel.lists.xensource.com> List-Unsubscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe> List-Post: <mailto:xen-devel@lists.xensource.com> List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help> List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=subscribe> Sender: xen-devel-bounces@lists.xensource.com Errors-To: xen-devel-bounces@lists.xensource.com The MSI restore function will become a function pointer in an x86_msi_ops struct. It defaults to the implementation in the io_apic.c and msi.c. We piggyback on the indirection mechanism introduced by "x86: Introduce x86_msi_ops". c: x86@kernel.org Cc: Thomas Gleixner <tglx@linutronix.de> Cc: "H. Peter Anvin" <hpa@zytor.com> Signed-off-by: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com> --- arch/x86/include/asm/pci.h | 9 +++++++++ arch/x86/include/asm/x86_init.h | 1 + arch/x86/kernel/x86_init.c | 1 + drivers/pci/msi.c | 29 +++++++++++++++++++++++++++-- 4 files changed, 38 insertions(+), 2 deletions(-) diff --git a/arch/x86/include/asm/pci.h b/arch/x86/include/asm/pci.h index d498943..df75d07 100644 --- a/arch/x86/include/asm/pci.h +++ b/arch/x86/include/asm/pci.h @@ -112,19 +112,28 @@ static inline void x86_teardown_msi_irq(unsigned int irq) { x86_msi.teardown_msi_irq(irq); } +static inline void x86_restore_msi_irqs(struct pci_dev *dev, int irq) +{ + x86_msi.restore_msi_irqs(dev, irq); +} #define arch_setup_msi_irqs x86_setup_msi_irqs #define arch_teardown_msi_irqs x86_teardown_msi_irqs #define arch_teardown_msi_irq x86_teardown_msi_irq +#define arch_restore_msi_irqs x86_restore_msi_irqs /* implemented in arch/x86/kernel/apic/io_apic. */ int native_setup_msi_irqs(struct pci_dev *dev, int nvec, int type); void native_teardown_msi_irq(unsigned int irq); +void native_restore_msi_irqs(struct pci_dev *dev, int irq); /* default to the implementation in drivers/lib/msi.c */ #define HAVE_DEFAULT_MSI_TEARDOWN_IRQS +#define HAVE_DEFAULT_MSI_RESTORE_IRQS void default_teardown_msi_irqs(struct pci_dev *dev); +void default_restore_msi_irqs(struct pci_dev *dev, int irq); #else #define native_setup_msi_irqs NULL #define native_teardown_msi_irq NULL #define default_teardown_msi_irqs NULL +#define default_restore_msi_irqs NULL #endif #define PCI_DMA_BUS_IS_PHYS (dma_ops->is_phys) diff --git a/arch/x86/include/asm/x86_init.h b/arch/x86/include/asm/x86_init.h index d3d8590..7af18be 100644 --- a/arch/x86/include/asm/x86_init.h +++ b/arch/x86/include/asm/x86_init.h @@ -174,6 +174,7 @@ struct x86_msi_ops { int (*setup_msi_irqs)(struct pci_dev *dev, int nvec, int type); void (*teardown_msi_irq)(unsigned int irq); void (*teardown_msi_irqs)(struct pci_dev *dev); + void (*restore_msi_irqs)(struct pci_dev *dev, int irq); }; extern struct x86_init_ops x86_init; diff --git a/arch/x86/kernel/x86_init.c b/arch/x86/kernel/x86_init.c index 6f164bd..bd1fe10 100644 --- a/arch/x86/kernel/x86_init.c +++ b/arch/x86/kernel/x86_init.c @@ -110,4 +110,5 @@ struct x86_msi_ops x86_msi = { .setup_msi_irqs = native_setup_msi_irqs, .teardown_msi_irq = native_teardown_msi_irq, .teardown_msi_irqs = default_teardown_msi_irqs, + .restore_msi_irqs = default_restore_msi_irqs, }; diff --git a/drivers/pci/msi.c b/drivers/pci/msi.c index 2f10328..f1fd801 100644 --- a/drivers/pci/msi.c +++ b/drivers/pci/msi.c @@ -85,6 +85,31 @@ void default_teardown_msi_irqs(struct pci_dev *dev) } #endif +#ifndef arch_restore_msi_irqs +# define arch_restore_msi_irqs default_restore_msi_irqs +# define HAVE_DEFAULT_MSI_RESTORE_IRQS +#endif + +#ifdef HAVE_DEFAULT_MSI_RESTORE_IRQS +void default_restore_msi_irqs(struct pci_dev *dev, int irq) +{ + struct msi_desc *entry; + + entry = NULL; + if (dev->msix_enabled) { + list_for_each_entry(entry, &dev->msi_list, list) { + if (irq == entry->irq) + break; + } + } else if (dev->msi_enabled) { + entry = irq_get_msi_desc(irq); + } + + if (entry) + write_msi_msg(irq, &entry->msg); +} +#endif + static void msi_set_enable(struct pci_dev *dev, int pos, int enable) { u16 control; @@ -359,7 +384,7 @@ static void __pci_restore_msi_state(struct pci_dev *dev) pci_intx_for_msi(dev, 0); msi_set_enable(dev, pos, 0); - write_msi_msg(dev->irq, &entry->msg); + arch_restore_msi_irqs(dev, dev->irq); pci_read_config_word(dev, pos + PCI_MSI_FLAGS, &control); msi_mask_irq(entry, msi_capable_mask(control), entry->masked); @@ -387,7 +412,7 @@ static void __pci_restore_msix_state(struct pci_dev *dev) pci_write_config_word(dev, pos + PCI_MSIX_FLAGS, control); list_for_each_entry(entry, &dev->msi_list, list) { - write_msi_msg(entry->irq, &entry->msg); + arch_restore_msi_irqs(dev, entry->irq); msix_mask_irq(entry, entry->masked); } -- 1.7.4.1 _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel From xen-devel-bounces@lists.xensource.com Thu Sep 29 13:20:55 2011 Return-path: <xen-devel-bounces@lists.xensource.com> Envelope-to: www-data@lists.xensource.com Delivery-date: Thu, 29 Sep 2011 13:20:55 -0700 Received: from localhost ([127.0.0.1] helo=lists.colo.xensource.com) by lists.xensource.com with esmtp (Exim 4.43) id 1R9N6E-0007Zs-P2; Thu, 29 Sep 2011 13:20:54 -0700 Received: from mail216.messagelabs.com ([85.158.143.99]) by lists.xensource.com with esmtp (Exim 4.43) id 1R9N3s-0006qt-RM for xen-devel@lists.xensource.com; Thu, 29 Sep 2011 13:18:30 -0700 X-Env-Sender: konrad@oracle.com X-Msg-Ref: server-9.tower-216.messagelabs.com!1317327504!20069276!1 X-Originating-IP: [148.87.113.117] X-StarScan-Version: 6.4.1; banners=-,-,- X-VirusChecked: Checked Received: (qmail 5299 invoked from network); 29 Sep 2011 20:18:25 -0000 Received: from rcsinet15.oracle.com (HELO rcsinet15.oracle.com) (148.87.113.117) by server-9.tower-216.messagelabs.com with DHE-RSA-AES256-SHA encrypted SMTP; 29 Sep 2011 20:18:25 -0000 Received: from ucsinet23.oracle.com (ucsinet23.oracle.com [156.151.31.71]) by rcsinet15.oracle.com (Switch-3.4.4/Switch-3.4.4) with ESMTP id p8TKH5ZB012772 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Thu, 29 Sep 2011 20:17:07 GMT Received: from acsmt358.oracle.com (acsmt358.oracle.com [141.146.40.158]) by ucsinet23.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id p8TKH4mJ006325 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 29 Sep 2011 20:17:05 GMT Received: from abhmt116.oracle.com (abhmt116.oracle.com [141.146.116.68]) by acsmt358.oracle.com (8.12.11.20060308/8.12.11) with ESMTP id p8TKGv5q007003; Thu, 29 Sep 2011 15:16:57 -0500 Received: from oracle.com (/207.172.105.198) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Thu, 29 Sep 2011 13:16:57 -0700 Received: by oracle.com (Postfix, from userid 1000) id 21065154D; Thu, 29 Sep 2011 16:16:56 -0400 (EDT) From: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com> To: linux-kernel@vger.kernel.org, rjw@sisk.pl, tglx@linutronix.de, hpa@zytor.com, x86@kernel.org, len.brown@intel.com, joseph.cihula@intel.com, shane.wang@intel.com, xen-devel@lists.xensource.com, linux-pm@lists.linux-foundation.org, tboot-devel@lists.sourceforge.net, linux-acpi@vger.kernel.org, liang.tang@oracle.com, ke.yu@intel.com, kevin.tian@intel.com, jeremy@goop.org Date: Thu, 29 Sep 2011 16:16:48 -0400 Message-Id: <1317327414-24072-3-git-send-email-konrad.wilk@oracle.com> X-Mailer: git-send-email 1.7.4.1 In-Reply-To: <1317327414-24072-1-git-send-email-konrad.wilk@oracle.com> References: <1317327414-24072-1-git-send-email-konrad.wilk@oracle.com> X-Source-IP: ucsinet23.oracle.com [156.151.31.71] X-CT-RefId: str=0001.0A090201.4E84D244.0008,ss=1,re=0.000,fgs=0 Cc: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com> Subject: [Xen-devel] [PATCH 2/8] x86, acpi, tboot: Have a ACPI sleep override instead of calling tboot_sleep. X-BeenThere: xen-devel@lists.xensource.com X-Mailman-Version: 2.1.5 Precedence: list List-Id: Xen developer discussion <xen-devel.lists.xensource.com> List-Unsubscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe> List-Post: <mailto:xen-devel@lists.xensource.com> List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help> List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=subscribe> Sender: xen-devel-bounces@lists.xensource.com Errors-To: xen-devel-bounces@lists.xensource.com The ACPI suspend path makes a call to tboot_sleep right before it writes the PM1A, PM1B values. We replace the direct call to tboot via an registration callback similar to __acpi_register_gsi. CC: Thomas Gleixner <tglx@linutronix.de> CC: "H. Peter Anvin" <hpa@zytor.com> CC: x86@kernel.org CC: Len Brown <len.brown@intel.com> CC: Joseph Cihula <joseph.cihula@intel.com> CC: Shane Wang <shane.wang@intel.com> CC: xen-devel@lists.xensource.com CC: linux-pm@lists.linux-foundation.org CC: tboot-devel@lists.sourceforge.net CC: linux-acpi@vger.kernel.org [v1: Added __attribute__ ((unused))] Signed-off-by: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com> --- arch/x86/include/asm/acpi.h | 4 ++++ arch/x86/kernel/acpi/boot.c | 4 ++++ arch/x86/kernel/tboot.c | 14 ++++++++++---- drivers/acpi/acpica/hwsleep.c | 12 ++++++++++-- include/linux/tboot.h | 3 ++- 5 files changed, 30 insertions(+), 7 deletions(-) diff --git a/arch/x86/include/asm/acpi.h b/arch/x86/include/asm/acpi.h index 610001d..0a46696 100644 --- a/arch/x86/include/asm/acpi.h +++ b/arch/x86/include/asm/acpi.h @@ -98,6 +98,10 @@ void acpi_pic_sci_set_trigger(unsigned int, u16); extern int (*__acpi_register_gsi)(struct device *dev, u32 gsi, int trigger, int polarity); +extern int (*__acpi_override_sleep)(u8 sleep_state, u32 pm1a_ctrl, + u32 pm1b_ctrl, bool *skip_rest) \ + __attribute__ ((unused)); + static inline void disable_acpi(void) { acpi_disabled = 1; diff --git a/arch/x86/kernel/acpi/boot.c b/arch/x86/kernel/acpi/boot.c index 4558f0d..7f30806 100644 --- a/arch/x86/kernel/acpi/boot.c +++ b/arch/x86/kernel/acpi/boot.c @@ -552,6 +552,10 @@ static int acpi_register_gsi_ioapic(struct device *dev, u32 gsi, int (*__acpi_register_gsi)(struct device *dev, u32 gsi, int trigger, int polarity) = acpi_register_gsi_pic; +int (*__acpi_override_sleep)(u8 sleep_state, u32 pm1a_ctrl, + u32 pm1b_ctrl, bool *skip_rest) \ + __attribute__ ((unused)) = NULL; + /* * success: return IRQ number (>=0) * failure: return < 0 diff --git a/arch/x86/kernel/tboot.c b/arch/x86/kernel/tboot.c index e07a2fc..a6c0a30 100644 --- a/arch/x86/kernel/tboot.c +++ b/arch/x86/kernel/tboot.c @@ -42,7 +42,7 @@ #include <asm/setup.h> #include <asm/e820.h> #include <asm/io.h> - +#include <linux/acpi.h> #include "acpi/realmode/wakeup.h" /* Global pointer to shared data; NULL means no measured launch. */ @@ -271,7 +271,9 @@ static void tboot_copy_fadt(const struct acpi_table_fadt *fadt) offsetof(struct acpi_table_facs, firmware_waking_vector); } -void tboot_sleep(u8 sleep_state, u32 pm1a_control, u32 pm1b_control) + +int tboot_sleep(u8 sleep_state, u32 pm1a_control, u32 pm1b_control, + bool *skip_rest) { static u32 acpi_shutdown_map[ACPI_S_STATE_COUNT] = { /* S0,1,2: */ -1, -1, -1, @@ -280,7 +282,7 @@ void tboot_sleep(u8 sleep_state, u32 pm1a_control, u32 pm1b_control) /* S5: */ TB_SHUTDOWN_S5 }; if (!tboot_enabled()) - return; + return AE_OK; tboot_copy_fadt(&acpi_gbl_FADT); tboot->acpi_sinfo.pm1a_cnt_val = pm1a_control; @@ -291,10 +293,12 @@ void tboot_sleep(u8 sleep_state, u32 pm1a_control, u32 pm1b_control) if (sleep_state >= ACPI_S_STATE_COUNT || acpi_shutdown_map[sleep_state] == -1) { pr_warning("unsupported sleep state 0x%x\n", sleep_state); - return; + return AE_ERROR; } tboot_shutdown(acpi_shutdown_map[sleep_state]); + + return AE_OK; } static atomic_t ap_wfs_count; @@ -344,6 +348,8 @@ static __init int tboot_late_init(void) atomic_set(&ap_wfs_count, 0); register_hotcpu_notifier(&tboot_cpu_notifier); + + __acpi_override_sleep = tboot_sleep; return 0; } diff --git a/drivers/acpi/acpica/hwsleep.c b/drivers/acpi/acpica/hwsleep.c index 2ac28bb..31d1198 100644 --- a/drivers/acpi/acpica/hwsleep.c +++ b/drivers/acpi/acpica/hwsleep.c @@ -45,7 +45,6 @@ #include <acpi/acpi.h> #include "accommon.h" #include "actables.h" -#include <linux/tboot.h> #define _COMPONENT ACPI_HARDWARE ACPI_MODULE_NAME("hwsleep") @@ -343,8 +342,17 @@ acpi_status asmlinkage acpi_enter_sleep_state(u8 sleep_state) ACPI_FLUSH_CPU_CACHE(); - tboot_sleep(sleep_state, pm1a_control, pm1b_control); + if (__acpi_override_sleep) { + bool skip_rest = false; + status = __acpi_override_sleep(sleep_state, pm1a_control, + pm1b_control, &skip_rest); + + if (ACPI_FAILURE(status)) + return_ACPI_STATUS(status); + if (skip_rest) + return_ACPI_STATUS(AE_OK); + } /* Write #2: Write both SLP_TYP + SLP_EN */ status = acpi_hw_write_pm1_control(pm1a_control, pm1b_control); diff --git a/include/linux/tboot.h b/include/linux/tboot.h index 1dba6ee..1216698 100644 --- a/include/linux/tboot.h +++ b/include/linux/tboot.h @@ -143,7 +143,8 @@ static inline int tboot_enabled(void) extern void tboot_probe(void); extern void tboot_shutdown(u32 shutdown_type); -extern void tboot_sleep(u8 sleep_state, u32 pm1a_control, u32 pm1b_control); +extern int tboot_sleep(u8 sleep_state, u32 pm1a_control, u32 pm1b_control, + bool *skip_rest) __attribute__ ((unused)); extern struct acpi_table_header *tboot_get_dmar_table( struct acpi_table_header *dmar_tbl); extern int tboot_force_iommu(void); -- 1.7.4.1 _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel From xen-devel-bounces@lists.xensource.com Thu Sep 29 13:22:05 2011 Return-path: <xen-devel-bounces@lists.xensource.com> Envelope-to: www-data@lists.xensource.com Delivery-date: Thu, 29 Sep 2011 13:22:05 -0700 Received: from localhost ([127.0.0.1] helo=lists.colo.xensource.com) by lists.xensource.com with esmtp (Exim 4.43) id 1R9N7N-0007xB-Az; Thu, 29 Sep 2011 13:22:05 -0700 Received: from mail182.messagelabs.com ([85.158.139.83]) by lists.xensource.com with esmtp (Exim 4.43) id 1R9N3u-0006rl-Fs for xen-devel@lists.xensource.com; Thu, 29 Sep 2011 13:18:31 -0700 X-Env-Sender: konrad@oracle.com X-Msg-Ref: server-3.tower-182.messagelabs.com!1317327505!17482064!1 X-Originating-IP: [148.87.113.117] X-StarScan-Version: 6.4.1; banners=-,-,- X-VirusChecked: Checked Received: (qmail 3199 invoked from network); 29 Sep 2011 20:18:27 -0000 Received: from rcsinet15.oracle.com (HELO rcsinet15.oracle.com) (148.87.113.117) by server-3.tower-182.messagelabs.com with DHE-RSA-AES256-SHA encrypted SMTP; 29 Sep 2011 20:18:27 -0000 Received: from ucsinet24.oracle.com (ucsinet24.oracle.com [156.151.31.67]) by rcsinet15.oracle.com (Switch-3.4.4/Switch-3.4.4) with ESMTP id p8TKH5k4012766 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Thu, 29 Sep 2011 20:17:06 GMT Received: from acsmt356.oracle.com (acsmt356.oracle.com [141.146.40.156]) by ucsinet24.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id p8TKBL20013232 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 29 Sep 2011 20:11:22 GMT Received: from abhmt103.oracle.com (abhmt103.oracle.com [141.146.116.55]) by acsmt356.oracle.com (8.12.11.20060308/8.12.11) with ESMTP id p8TKGv0n021866; Thu, 29 Sep 2011 15:16:57 -0500 Received: from oracle.com (/207.172.105.198) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Thu, 29 Sep 2011 13:16:57 -0700 Received: by oracle.com (Postfix, from userid 1000) id 0FDFC154A; Thu, 29 Sep 2011 16:16:56 -0400 (EDT) From: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com> To: linux-kernel@vger.kernel.org, rjw@sisk.pl, tglx@linutronix.de, hpa@zytor.com, x86@kernel.org, len.brown@intel.com, joseph.cihula@intel.com, shane.wang@intel.com, xen-devel@lists.xensource.com, linux-pm@lists.linux-foundation.org, tboot-devel@lists.sourceforge.net, linux-acpi@vger.kernel.org, liang.tang@oracle.com, ke.yu@intel.com, kevin.tian@intel.com, jeremy@goop.org Date: Thu, 29 Sep 2011 16:16:46 -0400 Message-Id: <1317327414-24072-1-git-send-email-konrad.wilk@oracle.com> X-Mailer: git-send-email 1.7.4.1 X-Source-IP: ucsinet24.oracle.com [156.151.31.67] X-CT-RefId: str=0001.0A090209.4E84D243.0109,ss=1,re=0.000,fgs=0 Cc: Subject: [Xen-devel] [PATCH v2] ACPI S3 to work under Xen. X-BeenThere: xen-devel@lists.xensource.com X-Mailman-Version: 2.1.5 Precedence: list List-Id: Xen developer discussion <xen-devel.lists.xensource.com> List-Unsubscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe> List-Post: <mailto:xen-devel@lists.xensource.com> List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help> List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=subscribe> Sender: xen-devel-bounces@lists.xensource.com Errors-To: xen-devel-bounces@lists.xensource.com Attached is an [v2] set of patches to enable S3 to work with the Xen hypervisor. Changes since the RFC posting [http://comments.gmane.org/gmane.linux.acpi.devel/50701] by Liang Tang: - Per review comments added: __unused__ attribute, support for PM1A/B if more than 16-bit, copyright/license. - Added support for PHYSDEVOP_restore_msi_ext call. The relationship that Xen has with Linux kernel is symbiotic. The Linux kernel does the ACPI "stuff" and tells the hypervisor to do the low-level stuff (such as program the IOAPIC, setup vectors, etc). The realm of ACPI S3 is more complex as we need to save the CPU state (and Intel TXT values - which the hypervisor has to do). The major difficulties we hit was with 'acpi_suspend_lowlevel' - which tweaks a lot of lowlevel values and some of them are not properly handled by Xen. Liang Tang has figured which ones of them we trip over (read below) - and he suggested that perhaps we can provide a registration mechanism to abstract this away. The reason for all of this is that Linux does not talk to the BIOS directly - instead it simply walks through the necessary ACPI methods and then issues hypercall to Xen which then further completes the remaining suspend steps. So the attached patches do exactly that - there are two entry points in the ACPI. 1). For S3: acpi_suspend_lowlevel -> .. lots of code -> acpi_enter_sleep_state 2). For S1/S4/S5: acpi_enter_sleep_state The first naive idea was of abstracting away in the 'acpi_enter_sleep_state' function the tboot_sleep code so that we can use it too. And low-behold - it worked splendidly for powering off (S5 I believe) For S3 that did not work - during suspend the hypervisor tripped over when saving cr8. During resume it tripped over at restoring the cr3, cr8, idt, and gdt values. When I posted the RFC, the feedback I got was to use a higher upper interface to make the call to the hypervisor. Instead of doing it at the lower pv-ops case for cr3, cr8, idt, gdt, etc. The code I've to say - is much nicer than doing it via pv-ops. Anyhow, please take a look! Konrad Rzeszutek Wilk (5): x86: Expand the x86_msi_ops to have a restore MSIs. x86, acpi, tboot: Have a ACPI sleep override instead of calling tboot_sleep. xen: Utilize the restore_msi_irqs hook. xen/acpi/sleep: Enable ACPI sleep via the __acpi_override_sleep xen/acpi/sleep: Register to the acpi_suspend_lowlevel a callback. Liang Tang (2): x86/acpi/sleep: Provide registration for acpi_suspend_lowlevel. xen/pci:use hypercall PHYSDEVOP_restore_msi_ext to restore MSI/MSI-X vectors Yu Ke (1): xen/acpi: Domain0 acpi parser related platform hypercall arch/ia64/include/asm/xen/interface.h | 1 + arch/x86/include/asm/acpi.h | 6 +- arch/x86/include/asm/pci.h | 9 + arch/x86/include/asm/x86_init.h | 1 + arch/x86/include/asm/xen/hypercall.h | 8 + arch/x86/include/asm/xen/interface.h | 1 + arch/x86/kernel/acpi/boot.c | 6 + arch/x86/kernel/acpi/sleep.c | 4 +- arch/x86/kernel/acpi/sleep.h | 2 + arch/x86/kernel/tboot.c | 14 +- arch/x86/kernel/x86_init.c | 1 + arch/x86/pci/xen.c | 29 +++ arch/x86/xen/enlighten.c | 3 + drivers/acpi/acpica/hwsleep.c | 12 +- drivers/acpi/sleep.c | 2 + drivers/pci/msi.c | 29 +++- drivers/xen/Makefile | 2 +- drivers/xen/acpi.c | 65 +++++++ include/linux/tboot.h | 3 +- include/xen/acpi.h | 70 +++++++ include/xen/interface/physdev.h | 15 ++ include/xen/interface/platform.h | 320 +++++++++++++++++++++++++++++++++ include/xen/interface/xen.h | 1 + 23 files changed, 591 insertions(+), 13 deletions(-) _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel From xen-devel-bounces@lists.xensource.com Thu Sep 29 13:22:57 2011 Return-path: <xen-devel-bounces@lists.xensource.com> Envelope-to: www-data@lists.xensource.com Delivery-date: Thu, 29 Sep 2011 13:22:57 -0700 Received: from localhost ([127.0.0.1] helo=lists.colo.xensource.com) by lists.xensource.com with esmtp (Exim 4.43) id 1R9N8D-0008Jd-RL; Thu, 29 Sep 2011 13:22:57 -0700 Received: from mail21.messagelabs.com ([85.158.143.35]) by lists.xensource.com with esmtp (Exim 4.43) id 1R9N3u-0006rZ-G0 for xen-devel@lists.xensource.com; Thu, 29 Sep 2011 13:18:31 -0700 X-Env-Sender: konrad@oracle.com X-Msg-Ref: server-11.tower-21.messagelabs.com!1317327487!44518484!1 X-Originating-IP: [148.87.113.117] X-StarScan-Version: 6.4.1; banners=-,-,- X-VirusChecked: Checked Received: (qmail 8677 invoked from network); 29 Sep 2011 20:18:08 -0000 Received: from rcsinet15.oracle.com (HELO rcsinet15.oracle.com) (148.87.113.117) by server-11.tower-21.messagelabs.com with DHE-RSA-AES256-SHA encrypted SMTP; 29 Sep 2011 20:18:08 -0000 Received: from rtcsinet21.oracle.com (rtcsinet21.oracle.com [66.248.204.29]) by rcsinet15.oracle.com (Switch-3.4.4/Switch-3.4.4) with ESMTP id p8TKH6Qh012780 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Thu, 29 Sep 2011 20:17:08 GMT Received: from acsmt358.oracle.com (acsmt358.oracle.com [141.146.40.158]) by rtcsinet21.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id p8TKH4vV028433 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 29 Sep 2011 20:17:05 GMT Received: from abhmt105.oracle.com (abhmt105.oracle.com [141.146.116.57]) by acsmt358.oracle.com (8.12.11.20060308/8.12.11) with ESMTP id p8TKGvJJ007002; Thu, 29 Sep 2011 15:16:57 -0500 Received: from oracle.com (/207.172.105.198) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Thu, 29 Sep 2011 13:16:57 -0700 Received: by oracle.com (Postfix, from userid 1000) id 334921550; Thu, 29 Sep 2011 16:16:56 -0400 (EDT) From: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com> To: linux-kernel@vger.kernel.org, rjw@sisk.pl, tglx@linutronix.de, hpa@zytor.com, x86@kernel.org, len.brown@intel.com, joseph.cihula@intel.com, shane.wang@intel.com, xen-devel@lists.xensource.com, linux-pm@lists.linux-foundation.org, tboot-devel@lists.sourceforge.net, linux-acpi@vger.kernel.org, liang.tang@oracle.com, ke.yu@intel.com, kevin.tian@intel.com, jeremy@goop.org Date: Thu, 29 Sep 2011 16:16:50 -0400 Message-Id: <1317327414-24072-5-git-send-email-konrad.wilk@oracle.com> X-Mailer: git-send-email 1.7.4.1 In-Reply-To: <1317327414-24072-1-git-send-email-konrad.wilk@oracle.com> References: <1317327414-24072-1-git-send-email-konrad.wilk@oracle.com> X-Source-IP: rtcsinet21.oracle.com [66.248.204.29] X-CT-RefId: str=0001.0A090209.4E84D244.0088,ss=1,re=0.000,fgs=0 Cc: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com> Subject: [Xen-devel] [PATCH 4/8] xen: Utilize the restore_msi_irqs hook. X-BeenThere: xen-devel@lists.xensource.com X-Mailman-Version: 2.1.5 Precedence: list List-Id: Xen developer discussion <xen-devel.lists.xensource.com> List-Unsubscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe> List-Post: <mailto:xen-devel@lists.xensource.com> List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help> List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=subscribe> Sender: xen-devel-bounces@lists.xensource.com Errors-To: xen-devel-bounces@lists.xensource.com to make a hypercall to restore the vectors in the MSI/MSI-X configuration space. Signed-off-by: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com> --- arch/x86/pci/xen.c | 12 ++++++++++++ include/xen/interface/physdev.h | 7 +++++++ 2 files changed, 19 insertions(+), 0 deletions(-) diff --git a/arch/x86/pci/xen.c b/arch/x86/pci/xen.c index 1017c7b..9eea4ed 100644 --- a/arch/x86/pci/xen.c +++ b/arch/x86/pci/xen.c @@ -304,6 +304,17 @@ static int xen_initdom_setup_msi_irqs(struct pci_dev *dev, int nvec, int type) out: return ret; } + +static void xen_initdom_restore_msi_irqs(struct pci_dev *dev, int irq) +{ + int ret = 0; + struct physdev_restore_msi restore; + + restore.bus = dev->bus->number; + restore.devfn = dev->devfn; + ret = HYPERVISOR_physdev_op(PHYSDEVOP_restore_msi, &restore); + WARN(ret && ret != -ENOSYS, "restore_msi -> %d\n", ret); +} #endif static void xen_teardown_msi_irqs(struct pci_dev *dev) @@ -426,6 +437,7 @@ int __init pci_xen_initial_domain(void) #ifdef CONFIG_PCI_MSI x86_msi.setup_msi_irqs = xen_initdom_setup_msi_irqs; x86_msi.teardown_msi_irq = xen_teardown_msi_irq; + x86_msi.restore_msi_irqs = xen_initdom_restore_msi_irqs; #endif xen_setup_acpi_sci(); __acpi_register_gsi = acpi_register_gsi_xen; diff --git a/include/xen/interface/physdev.h b/include/xen/interface/physdev.h index 534cac8..44aefa9 100644 --- a/include/xen/interface/physdev.h +++ b/include/xen/interface/physdev.h @@ -144,6 +144,13 @@ struct physdev_manage_pci { uint8_t devfn; }; +#define PHYSDEVOP_restore_msi 19 +struct physdev_restore_msi { + /* IN */ + uint8_t bus; + uint8_t devfn; +}; + #define PHYSDEVOP_manage_pci_add_ext 20 struct physdev_manage_pci_ext { /* IN */ -- 1.7.4.1 _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel From xen-devel-bounces@lists.xensource.com Thu Sep 29 13:23:43 2011 Return-path: <xen-devel-bounces@lists.xensource.com> Envelope-to: www-data@lists.xensource.com Delivery-date: Thu, 29 Sep 2011 13:23:43 -0700 Received: from localhost ([127.0.0.1] helo=lists.colo.xensource.com) by lists.xensource.com with esmtp (Exim 4.43) id 1R9N8x-0000EQ-MV; Thu, 29 Sep 2011 13:23:43 -0700 Received: from mail174.messagelabs.com ([85.158.138.51]) by lists.xensource.com with esmtp (Exim 4.43) id 1R9N3v-0006s2-6j for xen-devel@lists.xensource.com; Thu, 29 Sep 2011 13:18:32 -0700 X-Env-Sender: konrad@oracle.com X-Msg-Ref: server-7.tower-174.messagelabs.com!1317327506!33265273!1 X-Originating-IP: [148.87.113.117] X-StarScan-Version: 6.4.1; banners=-,-,- X-VirusChecked: Checked Received: (qmail 20612 invoked from network); 29 Sep 2011 20:18:27 -0000 Received: from rcsinet15.oracle.com (HELO rcsinet15.oracle.com) (148.87.113.117) by server-7.tower-174.messagelabs.com with DHE-RSA-AES256-SHA encrypted SMTP; 29 Sep 2011 20:18:27 -0000 Received: from acsinet21.oracle.com (acsinet21.oracle.com [141.146.126.237]) by rcsinet15.oracle.com (Switch-3.4.4/Switch-3.4.4) with ESMTP id p8TKH8iG012800 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Thu, 29 Sep 2011 20:17:10 GMT Received: from acsmt358.oracle.com (acsmt358.oracle.com [141.146.40.158]) by acsinet21.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id p8TKH5Ow009683 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 29 Sep 2011 20:17:06 GMT Received: from abhmt108.oracle.com (abhmt108.oracle.com [141.146.116.60]) by acsmt358.oracle.com (8.12.11.20060308/8.12.11) with ESMTP id p8TKGxHF007025; Thu, 29 Sep 2011 15:17:00 -0500 Received: from oracle.com (/207.172.105.198) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Thu, 29 Sep 2011 13:16:59 -0700 Received: by oracle.com (Postfix, from userid 1000) id 559F3155D; Thu, 29 Sep 2011 16:16:56 -0400 (EDT) From: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com> To: linux-kernel@vger.kernel.org, rjw@sisk.pl, tglx@linutronix.de, hpa@zytor.com, x86@kernel.org, len.brown@intel.com, joseph.cihula@intel.com, shane.wang@intel.com, xen-devel@lists.xensource.com, linux-pm@lists.linux-foundation.org, tboot-devel@lists.sourceforge.net, linux-acpi@vger.kernel.org, liang.tang@oracle.com, ke.yu@intel.com, kevin.tian@intel.com, jeremy@goop.org Date: Thu, 29 Sep 2011 16:16:54 -0400 Message-Id: <1317327414-24072-9-git-send-email-konrad.wilk@oracle.com> X-Mailer: git-send-email 1.7.4.1 In-Reply-To: <1317327414-24072-1-git-send-email-konrad.wilk@oracle.com> References: <1317327414-24072-1-git-send-email-konrad.wilk@oracle.com> X-Source-IP: acsinet21.oracle.com [141.146.126.237] X-Auth-Type: Internal IP X-CT-RefId: str=0001.0A090201.4E84D246.00D1:SCFMA922111,ss=1,re=-4.000,fgs=0 Cc: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com> Subject: [Xen-devel] [PATCH 8/8] xen/pci:use hypercall PHYSDEVOP_restore_msi_ext to restore MSI/MSI-X vectors X-BeenThere: xen-devel@lists.xensource.com X-Mailman-Version: 2.1.5 Precedence: list List-Id: Xen developer discussion <xen-devel.lists.xensource.com> List-Unsubscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe> List-Post: <mailto:xen-devel@lists.xensource.com> List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help> List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=subscribe> Sender: xen-devel-bounces@lists.xensource.com Errors-To: xen-devel-bounces@lists.xensource.com From: Liang Tang <liang.tang@oracle.com> .. to use the new hypercall to restore the vectors for MSI/MSI-X devices. If the new hypercall fail, we will call the old one (PHYSDEVOP_restore_msi). [v1: Attempt only once to make the new hypercall, not everytime] Signed-off-by: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com> Signed-off-by: Liang Tang <liang.tang@oracle.com> --- arch/x86/pci/xen.c | 27 ++++++++++++++++++++++----- include/xen/interface/physdev.h | 8 ++++++++ 2 files changed, 30 insertions(+), 5 deletions(-) diff --git a/arch/x86/pci/xen.c b/arch/x86/pci/xen.c index 9eea4ed..4521b05 100644 --- a/arch/x86/pci/xen.c +++ b/arch/x86/pci/xen.c @@ -248,6 +248,8 @@ error: } #ifdef CONFIG_XEN_DOM0 +static bool __read_mostly pci_seg_supported = true; + static int xen_initdom_setup_msi_irqs(struct pci_dev *dev, int nvec, int type) { int ret = 0; @@ -308,12 +310,27 @@ out: static void xen_initdom_restore_msi_irqs(struct pci_dev *dev, int irq) { int ret = 0; - struct physdev_restore_msi restore; - restore.bus = dev->bus->number; - restore.devfn = dev->devfn; - ret = HYPERVISOR_physdev_op(PHYSDEVOP_restore_msi, &restore); - WARN(ret && ret != -ENOSYS, "restore_msi -> %d\n", ret); + if (pci_seg_supported) { + struct physdev_pci_device restore_ext; + + restore_ext.seg = pci_domain_nr(dev->bus); + restore_ext.bus = dev->bus->number; + restore_ext.devfn = dev->devfn; + ret = HYPERVISOR_physdev_op(PHYSDEVOP_restore_msi_ext, + &restore_ext); + if (ret == -ENOSYS) + pci_seg_supported = false; + WARN(ret && ret != -ENOSYS, "restore_msi_ext -> %d\n", ret); + } + if (!pci_seg_supported) { + struct physdev_restore_msi restore; + + restore.bus = dev->bus->number; + restore.devfn = dev->devfn; + ret = HYPERVISOR_physdev_op(PHYSDEVOP_restore_msi, &restore); + WARN(ret && ret != -ENOSYS, "restore_msi -> %d\n", ret); + } } #endif diff --git a/include/xen/interface/physdev.h b/include/xen/interface/physdev.h index 44aefa9..9818456 100644 --- a/include/xen/interface/physdev.h +++ b/include/xen/interface/physdev.h @@ -205,6 +205,14 @@ struct physdev_get_free_pirq { uint32_t pirq; }; +#define PHYSDEVOP_restore_msi_ext 27 +struct physdev_pci_device { + /* IN */ + uint16_t seg; + uint8_t bus; + uint8_t devfn; +}; + /* * Notify that some PIRQ-bound event channels have been unmasked. * ** This command is obsolete since interface version 0x00030202 and is ** -- 1.7.4.1 _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel From xen-devel-bounces@lists.xensource.com Thu Sep 29 13:24:57 2011 Return-path: <xen-devel-bounces@lists.xensource.com> Envelope-to: www-data@lists.xensource.com Delivery-date: Thu, 29 Sep 2011 13:24:57 -0700 Received: from localhost ([127.0.0.1] helo=lists.colo.xensource.com) by lists.xensource.com with esmtp (Exim 4.43) id 1R9NA9-0000h1-OY; Thu, 29 Sep 2011 13:24:57 -0700 Received: from mail216.messagelabs.com ([85.158.143.99]) by lists.xensource.com with esmtp (Exim 4.43) id 1R9N4C-0006vl-TL for xen-devel@lists.xensource.com; Thu, 29 Sep 2011 13:18:50 -0700 X-Env-Sender: konrad@oracle.com X-Msg-Ref: server-6.tower-216.messagelabs.com!1317327524!18789914!1 X-Originating-IP: [141.146.126.227] X-StarScan-Version: 6.4.1; banners=-,-,- X-VirusChecked: Checked Received: (qmail 6346 invoked from network); 29 Sep 2011 20:18:45 -0000 Received: from acsinet15.oracle.com (HELO acsinet15.oracle.com) (141.146.126.227) by server-6.tower-216.messagelabs.com with DHE-RSA-AES256-SHA encrypted SMTP; 29 Sep 2011 20:18:45 -0000 Received: from acsinet22.oracle.com (acsinet22.oracle.com [141.146.126.238]) by acsinet15.oracle.com (Switch-3.4.4/Switch-3.4.4) with ESMTP id p8TKHPsA014056 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Thu, 29 Sep 2011 20:17:27 GMT Received: from acsmt358.oracle.com (acsmt358.oracle.com [141.146.40.158]) by acsinet22.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id p8TKHO1W017930 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 29 Sep 2011 20:17:25 GMT Received: from abhmt113.oracle.com (abhmt113.oracle.com [141.146.116.65]) by acsmt358.oracle.com (8.12.11.20060308/8.12.11) with ESMTP id p8TKHIeJ007324; Thu, 29 Sep 2011 15:17:18 -0500 Received: from oracle.com (/207.172.105.198) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Thu, 29 Sep 2011 13:17:18 -0700 Received: by oracle.com (Postfix, from userid 1000) id 4E4241559; Thu, 29 Sep 2011 16:16:56 -0400 (EDT) From: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com> To: linux-kernel@vger.kernel.org, rjw@sisk.pl, tglx@linutronix.de, hpa@zytor.com, x86@kernel.org, len.brown@intel.com, joseph.cihula@intel.com, shane.wang@intel.com, xen-devel@lists.xensource.com, linux-pm@lists.linux-foundation.org, tboot-devel@lists.sourceforge.net, linux-acpi@vger.kernel.org, liang.tang@oracle.com, ke.yu@intel.com, kevin.tian@intel.com, jeremy@goop.org Date: Thu, 29 Sep 2011 16:16:53 -0400 Message-Id: <1317327414-24072-8-git-send-email-konrad.wilk@oracle.com> X-Mailer: git-send-email 1.7.4.1 In-Reply-To: <1317327414-24072-1-git-send-email-konrad.wilk@oracle.com> References: <1317327414-24072-1-git-send-email-konrad.wilk@oracle.com> X-Source-IP: acsinet22.oracle.com [141.146.126.238] X-Auth-Type: Internal IP X-CT-RefId: str=0001.0A090201.4E84D258.000B:SCFMA922111,ss=1,re=-4.000,fgs=0 Cc: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com> Subject: [Xen-devel] [PATCH 7/8] xen/acpi/sleep: Register to the acpi_suspend_lowlevel a callback. X-BeenThere: xen-devel@lists.xensource.com X-Mailman-Version: 2.1.5 Precedence: list List-Id: Xen developer discussion <xen-devel.lists.xensource.com> List-Unsubscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe> List-Post: <mailto:xen-devel@lists.xensource.com> List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help> List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=subscribe> Sender: xen-devel-bounces@lists.xensource.com Errors-To: xen-devel-bounces@lists.xensource.com We piggyback on "x86/acpi: Provide registration for acpi_suspend_lowlevel." to register a Xen version of the callback. The callback does not do anything special - except it omits the x86_acpi_suspend_lowlevel. It does that b/c during suspend it tries to save cr8 values (which the hypervisor does not support), and then on resume path the cr3, cr8, idt, and gdt are all resumed which clashes with what the hypervisor has set up for the guest. Signed-off-by: Liang Tang <liang.tang@oracle.com> Signed-off-by: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com> --- include/xen/acpi.h | 14 +++++++++++++- 1 files changed, 13 insertions(+), 1 deletions(-) diff --git a/include/xen/acpi.h b/include/xen/acpi.h index c981887..18025e0 100644 --- a/include/xen/acpi.h +++ b/include/xen/acpi.h @@ -44,10 +44,22 @@ int xen_acpi_notify_hypervisor_state(u8 sleep_state, u32 pm1a_cnt, u32 pm1b_cnd, bool *skip_rest); +static inline int xen_acpi_suspend_lowlevel(void) +{ + /* + * Xen will save and restore CPU context, so + * we can skip that and just go straight to + * the suspend. + */ + acpi_enter_sleep_state(ACPI_STATE_S3); + return 0; +} static inline void xen_acpi_sleep_register(void) { - if (xen_initial_domain()) + if (xen_initial_domain()) { + acpi_suspend_lowlevel = xen_acpi_suspend_lowlevel; __acpi_override_sleep = xen_acpi_notify_hypervisor_state; + } } #else static inline void xen_acpi_sleep_register(void) -- 1.7.4.1 _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel From xen-devel-bounces@lists.xensource.com Thu Sep 29 13:25:45 2011 Return-path: <xen-devel-bounces@lists.xensource.com> Envelope-to: www-data@lists.xensource.com Delivery-date: Thu, 29 Sep 2011 13:25:45 -0700 Received: from localhost ([127.0.0.1] helo=lists.colo.xensource.com) by lists.xensource.com with esmtp (Exim 4.43) id 1R9NAv-00013f-IK; Thu, 29 Sep 2011 13:25:45 -0700 Received: from mail21.messagelabs.com ([85.158.143.35]) by lists.xensource.com with esmtp (Exim 4.43) id 1R9N4G-0006wc-BW for xen-devel@lists.xensource.com; Thu, 29 Sep 2011 13:18:53 -0700 X-Env-Sender: konrad@oracle.com X-Msg-Ref: server-15.tower-21.messagelabs.com!1317327529!52502067!1 X-Originating-IP: [141.146.126.227] X-StarScan-Version: 6.4.1; banners=-,-,- X-VirusChecked: Checked Received: (qmail 16929 invoked from network); 29 Sep 2011 20:18:50 -0000 Received: from acsinet15.oracle.com (HELO acsinet15.oracle.com) (141.146.126.227) by server-15.tower-21.messagelabs.com with DHE-RSA-AES256-SHA encrypted SMTP; 29 Sep 2011 20:18:50 -0000 Received: from rtcsinet22.oracle.com (rtcsinet22.oracle.com [66.248.204.30]) by acsinet15.oracle.com (Switch-3.4.4/Switch-3.4.4) with ESMTP id p8TKHQan014064 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Thu, 29 Sep 2011 20:17:28 GMT Received: from acsmt356.oracle.com (acsmt356.oracle.com [141.146.40.156]) by rtcsinet22.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id p8TKHOLY029922 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 29 Sep 2011 20:17:25 GMT Received: from abhmt119.oracle.com (abhmt119.oracle.com [141.146.116.71]) by acsmt356.oracle.com (8.12.11.20060308/8.12.11) with ESMTP id p8TKHJJS022160; Thu, 29 Sep 2011 15:17:19 -0500 Received: from oracle.com (/207.172.105.198) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Thu, 29 Sep 2011 13:17:19 -0700 Received: by oracle.com (Postfix, from userid 1000) id 29E08154E; Thu, 29 Sep 2011 16:16:56 -0400 (EDT) From: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com> To: linux-kernel@vger.kernel.org, rjw@sisk.pl, tglx@linutronix.de, hpa@zytor.com, x86@kernel.org, len.brown@intel.com, joseph.cihula@intel.com, shane.wang@intel.com, xen-devel@lists.xensource.com, linux-pm@lists.linux-foundation.org, tboot-devel@lists.sourceforge.net, linux-acpi@vger.kernel.org, liang.tang@oracle.com, ke.yu@intel.com, kevin.tian@intel.com, jeremy@goop.org Date: Thu, 29 Sep 2011 16:16:49 -0400 Message-Id: <1317327414-24072-4-git-send-email-konrad.wilk@oracle.com> X-Mailer: git-send-email 1.7.4.1 In-Reply-To: <1317327414-24072-1-git-send-email-konrad.wilk@oracle.com> References: <1317327414-24072-1-git-send-email-konrad.wilk@oracle.com> X-Source-IP: rtcsinet22.oracle.com [66.248.204.30] X-CT-RefId: str=0001.0A090201.4E84D259.0013,ss=1,re=0.000,fgs=0 Cc: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com> Subject: [Xen-devel] [PATCH 3/8] x86/acpi/sleep: Provide registration for acpi_suspend_lowlevel. X-BeenThere: xen-devel@lists.xensource.com X-Mailman-Version: 2.1.5 Precedence: list List-Id: Xen developer discussion <xen-devel.lists.xensource.com> List-Unsubscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe> List-Post: <mailto:xen-devel@lists.xensource.com> List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help> List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=subscribe> Sender: xen-devel-bounces@lists.xensource.com Errors-To: xen-devel-bounces@lists.xensource.com From: Liang Tang <liang.tang@oracle.com> Which by default will be x86_acpi_suspend_lowlevel. This registration allows us to register another callback if there is a need to use another platform specific callback. CC: Thomas Gleixner <tglx@linutronix.de> CC: "H. Peter Anvin" <hpa@zytor.com> CC: x86@kernel.org CC: Len Brown <len.brown@intel.com> CC: Joseph Cihula <joseph.cihula@intel.com> CC: Shane Wang <shane.wang@intel.com> CC: linux-pm@lists.linux-foundation.org CC: linux-acpi@vger.kernel.org CC: Len Brown <len.brown@intel.com> Signed-off-by: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com> Signed-off-by: Liang Tang <liang.tang@oracle.com> --- arch/x86/include/asm/acpi.h | 2 +- arch/x86/kernel/acpi/boot.c | 2 ++ arch/x86/kernel/acpi/sleep.c | 4 ++-- arch/x86/kernel/acpi/sleep.h | 2 ++ drivers/acpi/sleep.c | 2 ++ 5 files changed, 9 insertions(+), 3 deletions(-) diff --git a/arch/x86/include/asm/acpi.h b/arch/x86/include/asm/acpi.h index 0a46696..9b538dc 100644 --- a/arch/x86/include/asm/acpi.h +++ b/arch/x86/include/asm/acpi.h @@ -119,7 +119,7 @@ static inline void acpi_disable_pci(void) } /* Low-level suspend routine. */ -extern int acpi_suspend_lowlevel(void); +extern int (*acpi_suspend_lowlevel)(void); extern const unsigned char acpi_wakeup_code[]; #define acpi_wakeup_address (__pa(TRAMPOLINE_SYM(acpi_wakeup_code))) diff --git a/arch/x86/kernel/acpi/boot.c b/arch/x86/kernel/acpi/boot.c index 7f30806..ddd081b 100644 --- a/arch/x86/kernel/acpi/boot.c +++ b/arch/x86/kernel/acpi/boot.c @@ -44,6 +44,7 @@ #include <asm/mpspec.h> #include <asm/smp.h> +#include "sleep.h" /* To include x86_acpi_suspend_lowlevel */ static int __initdata acpi_force = 0; u32 acpi_rsdt_forced; int acpi_disabled; @@ -556,6 +557,7 @@ int (*__acpi_override_sleep)(u8 sleep_state, u32 pm1a_ctrl, u32 pm1b_ctrl, bool *skip_rest) \ __attribute__ ((unused)) = NULL; +int (*acpi_suspend_lowlevel)(void) = x86_acpi_suspend_lowlevel; /* * success: return IRQ number (>=0) * failure: return < 0 diff --git a/arch/x86/kernel/acpi/sleep.c b/arch/x86/kernel/acpi/sleep.c index 103b6ab..4d2d0b1 100644 --- a/arch/x86/kernel/acpi/sleep.c +++ b/arch/x86/kernel/acpi/sleep.c @@ -25,12 +25,12 @@ static char temp_stack[4096]; #endif /** - * acpi_suspend_lowlevel - save kernel state + * x86_acpi_suspend_lowlevel - save kernel state * * Create an identity mapped page table and copy the wakeup routine to * low memory. */ -int acpi_suspend_lowlevel(void) +int x86_acpi_suspend_lowlevel(void) { struct wakeup_header *header; /* address in low memory of the wakeup routine. */ diff --git a/arch/x86/kernel/acpi/sleep.h b/arch/x86/kernel/acpi/sleep.h index 416d4be..4d3feb5 100644 --- a/arch/x86/kernel/acpi/sleep.h +++ b/arch/x86/kernel/acpi/sleep.h @@ -13,3 +13,5 @@ extern unsigned long acpi_copy_wakeup_routine(unsigned long); extern void wakeup_long64(void); extern void do_suspend_lowlevel(void); + +extern int x86_acpi_suspend_lowlevel(void); diff --git a/drivers/acpi/sleep.c b/drivers/acpi/sleep.c index 3ed80b2..3570c00 100644 --- a/drivers/acpi/sleep.c +++ b/drivers/acpi/sleep.c @@ -254,6 +254,8 @@ static int acpi_suspend_enter(suspend_state_t pm_state) break; case ACPI_STATE_S3: + if (!acpi_suspend_lowlevel) + return -ENODEV; error = acpi_suspend_lowlevel(); if (error) return error; -- 1.7.4.1 _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel From xen-devel-bounces@lists.xensource.com Thu Sep 29 13:26:33 2011 Return-path: <xen-devel-bounces@lists.xensource.com> Envelope-to: www-data@lists.xensource.com Delivery-date: Thu, 29 Sep 2011 13:26:33 -0700 Received: from localhost ([127.0.0.1] helo=lists.colo.xensource.com) by lists.xensource.com with esmtp (Exim 4.43) id 1R9NBh-0001To-Ar; Thu, 29 Sep 2011 13:26:33 -0700 Received: from mail174.messagelabs.com ([85.158.138.51]) by lists.xensource.com with esmtp (Exim 4.43) id 1R9N4H-0006wm-Fx for xen-devel@lists.xensource.com; Thu, 29 Sep 2011 13:18:54 -0700 X-Env-Sender: konrad@oracle.com X-Msg-Ref: server-13.tower-174.messagelabs.com!1317327528!33302777!1 X-Originating-IP: [141.146.126.227] X-StarScan-Version: 6.4.1; banners=-,-,- X-VirusChecked: Checked Received: (qmail 31768 invoked from network); 29 Sep 2011 20:18:50 -0000 Received: from acsinet15.oracle.com (HELO acsinet15.oracle.com) (141.146.126.227) by server-13.tower-174.messagelabs.com with DHE-RSA-AES256-SHA encrypted SMTP; 29 Sep 2011 20:18:50 -0000 Received: from acsinet21.oracle.com (acsinet21.oracle.com [141.146.126.237]) by acsinet15.oracle.com (Switch-3.4.4/Switch-3.4.4) with ESMTP id p8TKHQrj014068 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Thu, 29 Sep 2011 20:17:27 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 p8TKHPae010058 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 29 Sep 2011 20:17:25 GMT Received: from abhmt118.oracle.com (abhmt118.oracle.com [141.146.116.70]) by acsmt358.oracle.com (8.12.11.20060308/8.12.11) with ESMTP id p8TKHJh0007327; Thu, 29 Sep 2011 15:17:19 -0500 Received: from oracle.com (/207.172.105.198) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Thu, 29 Sep 2011 13:17:19 -0700 Received: by oracle.com (Postfix, from userid 1000) id 46FDB1556; Thu, 29 Sep 2011 16:16:56 -0400 (EDT) From: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com> To: linux-kernel@vger.kernel.org, rjw@sisk.pl, tglx@linutronix.de, hpa@zytor.com, x86@kernel.org, len.brown@intel.com, joseph.cihula@intel.com, shane.wang@intel.com, xen-devel@lists.xensource.com, linux-pm@lists.linux-foundation.org, tboot-devel@lists.sourceforge.net, linux-acpi@vger.kernel.org, liang.tang@oracle.com, ke.yu@intel.com, kevin.tian@intel.com, jeremy@goop.org Date: Thu, 29 Sep 2011 16:16:52 -0400 Message-Id: <1317327414-24072-7-git-send-email-konrad.wilk@oracle.com> X-Mailer: git-send-email 1.7.4.1 In-Reply-To: <1317327414-24072-1-git-send-email-konrad.wilk@oracle.com> References: <1317327414-24072-1-git-send-email-konrad.wilk@oracle.com> X-Source-IP: acsinet21.oracle.com [141.146.126.237] X-Auth-Type: Internal IP X-CT-RefId: str=0001.0A090207.4E84D258.00C1:SCFMA922111,ss=1,re=-4.000,fgs=0 Cc: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com> Subject: [Xen-devel] [PATCH 6/8] xen/acpi/sleep: Enable ACPI sleep via the __acpi_override_sleep X-BeenThere: xen-devel@lists.xensource.com X-Mailman-Version: 2.1.5 Precedence: list List-Id: Xen developer discussion <xen-devel.lists.xensource.com> List-Unsubscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe> List-Post: <mailto:xen-devel@lists.xensource.com> List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help> List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=subscribe> Sender: xen-devel-bounces@lists.xensource.com Errors-To: xen-devel-bounces@lists.xensource.com Provide the registration callback to call in the Xen's ACPI sleep functionality. This means that during S3/S5 we make a hypercall XENPF_enter_acpi_sleep with the proper PM1A/PM1B registers. Based of Ke Yu's <ke.yu@intel.com> initial idea. [ From http://xenbits.xensource.com/linux-2.6.18-xen.hg change c68699484a65 ] [v1: Added Copyright and license] [v2: Added check if PM1A/B the 16-bits MSB contain something. The spec only uses 16-bits but might have more in future] Signed-off-by: Liang Tang <liang.tang@oracle.com> Signed-off-by: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com> --- arch/x86/include/asm/xen/hypercall.h | 8 ++++ arch/x86/xen/enlighten.c | 3 ++ drivers/xen/Makefile | 2 +- drivers/xen/acpi.c | 65 ++++++++++++++++++++++++++++++++++ include/xen/acpi.h | 58 ++++++++++++++++++++++++++++++ 5 files changed, 135 insertions(+), 1 deletions(-) create mode 100644 drivers/xen/acpi.c create mode 100644 include/xen/acpi.h diff --git a/arch/x86/include/asm/xen/hypercall.h b/arch/x86/include/asm/xen/hypercall.h index 417777d..5728852 100644 --- a/arch/x86/include/asm/xen/hypercall.h +++ b/arch/x86/include/asm/xen/hypercall.h @@ -47,6 +47,7 @@ #include <xen/interface/xen.h> #include <xen/interface/sched.h> #include <xen/interface/physdev.h> +#include <xen/interface/platform.h> /* * The hypercall asms have to meet several constraints: @@ -301,6 +302,13 @@ HYPERVISOR_set_timer_op(u64 timeout) } static inline int +HYPERVISOR_dom0_op(struct xen_platform_op *platform_op) +{ + platform_op->interface_version = XENPF_INTERFACE_VERSION; + return _hypercall1(int, dom0_op, platform_op); +} + +static inline int HYPERVISOR_set_debugreg(int reg, unsigned long value) { return _hypercall2(int, set_debugreg, reg, value); diff --git a/arch/x86/xen/enlighten.c b/arch/x86/xen/enlighten.c index 2d69617..9306320 100644 --- a/arch/x86/xen/enlighten.c +++ b/arch/x86/xen/enlighten.c @@ -42,6 +42,7 @@ #include <xen/page.h> #include <xen/hvm.h> #include <xen/hvc-console.h> +#include <xen/acpi.h> #include <asm/paravirt.h> #include <asm/apic.h> @@ -1276,6 +1277,8 @@ asmlinkage void __init xen_start_kernel(void) /* Make sure ACS will be enabled */ pci_request_acs(); + + xen_acpi_sleep_register(); } diff --git a/drivers/xen/Makefile b/drivers/xen/Makefile index 72bbb27..6539673 100644 --- a/drivers/xen/Makefile +++ b/drivers/xen/Makefile @@ -17,7 +17,7 @@ obj-$(CONFIG_XEN_SYS_HYPERVISOR) += sys-hypervisor.o obj-$(CONFIG_XEN_PLATFORM_PCI) += xen-platform-pci.o obj-$(CONFIG_XEN_TMEM) += tmem.o obj-$(CONFIG_SWIOTLB_XEN) += swiotlb-xen.o -obj-$(CONFIG_XEN_DOM0) += pci.o +obj-$(CONFIG_XEN_DOM0) += pci.o acpi.o obj-$(CONFIG_XEN_PCIDEV_BACKEND) += xen-pciback/ xen-evtchn-y := evtchn.o diff --git a/drivers/xen/acpi.c b/drivers/xen/acpi.c new file mode 100644 index 0000000..ba9a5d2 --- /dev/null +++ b/drivers/xen/acpi.c @@ -0,0 +1,65 @@ +/****************************************************************************** + * acpi.c + * acpi file for domain 0 kernel + * + * Copyright (c) 2011 Konrad Rzeszutek Wilk <konrad.wilk@oracle.com> + * Copyright (c) 2011 Yu Ke ke.yu@intel.com + * + * This program is free software; you can redistribute it and/or + * modify it under the terms of the GNU General Public License version 2 + * as published by the Free Software Foundation; or, when distributed + * separately from the Linux kernel or incorporated into other + * software packages, subject to the following license: + * + * Permission is hereby granted, free of charge, to any person obtaining a copy + * of this source file (the "Software"), to deal in the Software without + * restriction, including without limitation the rights to use, copy, modify, + * merge, publish, distribute, sublicense, and/or sell copies of the Software, + * and to permit persons to whom the Software is furnished to do so, subject to + * the following conditions: + * + * The above copyright notice and this permission notice shall be included in + * all copies or substantial portions of the Software. + * + * THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR + * IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY, + * FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL THE + * AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER + * LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING + * FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS + * IN THE SOFTWARE. + */ + +#include <xen/acpi.h> +#include <xen/interface/platform.h> +#include <asm/xen/hypercall.h> +#include <asm/xen/hypervisor.h> + +int xen_acpi_notify_hypervisor_state(u8 sleep_state, + u32 pm1a_cnt, u32 pm1b_cnt, + bool *skip_rest) +{ + struct xen_platform_op op = { + .cmd = XENPF_enter_acpi_sleep, + .interface_version = XENPF_INTERFACE_VERSION, + .u = { + .enter_acpi_sleep = { + .pm1a_cnt_val = (u16)pm1a_cnt, + .pm1b_cnt_val = (u16)pm1b_cnt, + .sleep_state = sleep_state, + }, + }, + }; + + if ((pm1a_cnt & 0xffff0000) || (pm1b_cnt & 0xffff0000)) { + WARN(1, "Using more than 16bits of PM1A/B 0x%x/0x%x!" + "Email xen-devel@lists.xensource.com Thank you.\n", \ + pm1a_cnt, pm1b_cnt); + return AE_ERROR; + } + + if (skip_rest) + *skip_rest = true; + + return HYPERVISOR_dom0_op(&op); +} diff --git a/include/xen/acpi.h b/include/xen/acpi.h new file mode 100644 index 0000000..c981887 --- /dev/null +++ b/include/xen/acpi.h @@ -0,0 +1,58 @@ +/****************************************************************************** + * acpi.h + * acpi file for domain 0 kernel + * + * Copyright (c) 2011 Konrad Rzeszutek Wilk <konrad.wilk@oracle.com> + * Copyright (c) 2011 Yu Ke <ke.yu@intel.com> + * + * This program is free software; you can redistribute it and/or + * modify it under the terms of the GNU General Public License version 2 + * as published by the Free Software Foundation; or, when distributed + * separately from the Linux kernel or incorporated into other + * software packages, subject to the following license: + * + * Permission is hereby granted, free of charge, to any person obtaining a copy + * of this source file (the "Software"), to deal in the Software without + * restriction, including without limitation the rights to use, copy, modify, + * merge, publish, distribute, sublicense, and/or sell copies of the Software, + * and to permit persons to whom the Software is furnished to do so, subject to + * the following conditions: + * + * The above copyright notice and this permission notice shall be included in + * all copies or substantial portions of the Software. + * + * THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR + * IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY, + * FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL THE + * AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER + * LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING + * FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS + * IN THE SOFTWARE. + */ + +#ifndef _XEN_ACPI_H +#define _XEN_ACPI_H + +#include <linux/types.h> + +#ifdef CONFIG_XEN_DOM0 +#include <asm/xen/hypervisor.h> +#include <xen/xen.h> +#include <linux/acpi.h> + +int xen_acpi_notify_hypervisor_state(u8 sleep_state, + u32 pm1a_cnt, u32 pm1b_cnd, + bool *skip_rest); + +static inline void xen_acpi_sleep_register(void) +{ + if (xen_initial_domain()) + __acpi_override_sleep = xen_acpi_notify_hypervisor_state; +} +#else +static inline void xen_acpi_sleep_register(void) +{ +} +#endif + +#endif /* _XEN_ACPI_H */ -- 1.7.4.1 _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel From xen-devel-bounces@lists.xensource.com Thu Sep 29 13:27:59 2011 Return-path: <xen-devel-bounces@lists.xensource.com> Envelope-to: www-data@lists.xensource.com Delivery-date: Thu, 29 Sep 2011 13:27:59 -0700 Received: from localhost ([127.0.0.1] helo=lists.colo.xensource.com) by lists.xensource.com with esmtp (Exim 4.43) id 1R9ND5-0001qt-2q; Thu, 29 Sep 2011 13:27:59 -0700 Received: from mail182.messagelabs.com ([85.158.139.83]) by lists.xensource.com with esmtp (Exim 4.43) id 1R9N4H-0006wl-6a for xen-devel@lists.xensource.com; Thu, 29 Sep 2011 13:18:55 -0700 X-Env-Sender: konrad@oracle.com X-Msg-Ref: server-14.tower-182.messagelabs.com!1317327528!20102828!1 X-Originating-IP: [141.146.126.227] X-StarScan-Version: 6.4.1; banners=-,-,- X-VirusChecked: Checked Received: (qmail 11663 invoked from network); 29 Sep 2011 20:18:50 -0000 Received: from acsinet15.oracle.com (HELO acsinet15.oracle.com) (141.146.126.227) by server-14.tower-182.messagelabs.com with DHE-RSA-AES256-SHA encrypted SMTP; 29 Sep 2011 20:18:50 -0000 Received: from rtcsinet22.oracle.com (rtcsinet22.oracle.com [66.248.204.30]) by acsinet15.oracle.com (Switch-3.4.4/Switch-3.4.4) with ESMTP id p8TKHQw7014071 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Thu, 29 Sep 2011 20:17:28 GMT Received: from acsmt357.oracle.com (acsmt357.oracle.com [141.146.40.157]) by rtcsinet22.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id p8TKHO2Q029926 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 29 Sep 2011 20:17:25 GMT Received: from abhmt117.oracle.com (abhmt117.oracle.com [141.146.116.69]) by acsmt357.oracle.com (8.12.11.20060308/8.12.11) with ESMTP id p8TKHJ8m016507; Thu, 29 Sep 2011 15:17:19 -0500 Received: from oracle.com (/207.172.105.198) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Thu, 29 Sep 2011 13:17:19 -0700 Received: by oracle.com (Postfix, from userid 1000) id 3EC0F1555; Thu, 29 Sep 2011 16:16:56 -0400 (EDT) From: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com> To: linux-kernel@vger.kernel.org, rjw@sisk.pl, tglx@linutronix.de, hpa@zytor.com, x86@kernel.org, len.brown@intel.com, joseph.cihula@intel.com, shane.wang@intel.com, xen-devel@lists.xensource.com, linux-pm@lists.linux-foundation.org, tboot-devel@lists.sourceforge.net, linux-acpi@vger.kernel.org, liang.tang@oracle.com, ke.yu@intel.com, kevin.tian@intel.com, jeremy@goop.org Date: Thu, 29 Sep 2011 16:16:51 -0400 Message-Id: <1317327414-24072-6-git-send-email-konrad.wilk@oracle.com> X-Mailer: git-send-email 1.7.4.1 In-Reply-To: <1317327414-24072-1-git-send-email-konrad.wilk@oracle.com> References: <1317327414-24072-1-git-send-email-konrad.wilk@oracle.com> X-Source-IP: rtcsinet22.oracle.com [66.248.204.30] X-CT-RefId: str=0001.0A090201.4E84D259.0073,ss=1,re=-2.300,fgs=0 Cc: Jeremy Fitzhardinge <jeremy.fitzhardinge@citrix.com>, Konrad Rzeszutek Wilk <konrad.wilk@oracle.com> Subject: [Xen-devel] [PATCH 5/8] xen/acpi: Domain0 acpi parser related platform hypercall X-BeenThere: xen-devel@lists.xensource.com X-Mailman-Version: 2.1.5 Precedence: list List-Id: Xen developer discussion <xen-devel.lists.xensource.com> List-Unsubscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe> List-Post: <mailto:xen-devel@lists.xensource.com> List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help> List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=subscribe> Sender: xen-devel-bounces@lists.xensource.com Errors-To: xen-devel-bounces@lists.xensource.com From: Yu Ke <ke.yu@intel.com> This patches implements the xen_platform_op hypercall, to pass the parsed ACPI info to hypervisor. Signed-off-by: Yu Ke <ke.yu@intel.com> Signed-off-by: Tian Kevin <kevin.tian@intel.com> Signed-off-by: Jeremy Fitzhardinge <jeremy.fitzhardinge@citrix.com> [v1: Added DEFINE_GUEST.. in appropiate headers] [v2: Ripped out typedefs] Signed-off-by: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com> --- arch/ia64/include/asm/xen/interface.h | 1 + arch/x86/include/asm/xen/interface.h | 1 + include/xen/interface/platform.h | 320 +++++++++++++++++++++++++++++++++ include/xen/interface/xen.h | 1 + 4 files changed, 323 insertions(+), 0 deletions(-) create mode 100644 include/xen/interface/platform.h diff --git a/arch/ia64/include/asm/xen/interface.h b/arch/ia64/include/asm/xen/interface.h index e951e74..1d2427d 100644 --- a/arch/ia64/include/asm/xen/interface.h +++ b/arch/ia64/include/asm/xen/interface.h @@ -76,6 +76,7 @@ DEFINE_GUEST_HANDLE(char); DEFINE_GUEST_HANDLE(int); DEFINE_GUEST_HANDLE(long); DEFINE_GUEST_HANDLE(void); +DEFINE_GUEST_HANDLE(uint64_t); typedef unsigned long xen_pfn_t; DEFINE_GUEST_HANDLE(xen_pfn_t); diff --git a/arch/x86/include/asm/xen/interface.h b/arch/x86/include/asm/xen/interface.h index 5d4922a..a1f2db5 100644 --- a/arch/x86/include/asm/xen/interface.h +++ b/arch/x86/include/asm/xen/interface.h @@ -55,6 +55,7 @@ DEFINE_GUEST_HANDLE(char); DEFINE_GUEST_HANDLE(int); DEFINE_GUEST_HANDLE(long); DEFINE_GUEST_HANDLE(void); +DEFINE_GUEST_HANDLE(uint64_t); #endif #ifndef HYPERVISOR_VIRT_START diff --git a/include/xen/interface/platform.h b/include/xen/interface/platform.h new file mode 100644 index 0000000..c168468 --- /dev/null +++ b/include/xen/interface/platform.h @@ -0,0 +1,320 @@ +/****************************************************************************** + * platform.h + * + * Hardware platform operations. Intended for use by domain-0 kernel. + * + * Permission is hereby granted, free of charge, to any person obtaining a copy + * of this software and associated documentation files (the "Software"), to + * deal in the Software without restriction, including without limitation the + * rights to use, copy, modify, merge, publish, distribute, sublicense, and/or + * sell copies of the Software, and to permit persons to whom the Software is + * furnished to do so, subject to the following conditions: + * + * The above copyright notice and this permission notice shall be included in + * all copies or substantial portions of the Software. + * + * THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR + * IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY, + * FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL THE + * AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER + * LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING + * FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER + * DEALINGS IN THE SOFTWARE. + * + * Copyright (c) 2002-2006, K Fraser + */ + +#ifndef __XEN_PUBLIC_PLATFORM_H__ +#define __XEN_PUBLIC_PLATFORM_H__ + +#include "xen.h" + +#define XENPF_INTERFACE_VERSION 0x03000001 + +/* + * Set clock such that it would read <secs,nsecs> after 00:00:00 UTC, + * 1 January, 1970 if the current system time was <system_time>. + */ +#define XENPF_settime 17 +struct xenpf_settime { + /* IN variables. */ + uint32_t secs; + uint32_t nsecs; + uint64_t system_time; +}; +DEFINE_GUEST_HANDLE_STRUCT(xenpf_settime_t); + +/* + * Request memory range (@mfn, @mfn+@nr_mfns-1) to have type @type. + * On x86, @type is an architecture-defined MTRR memory type. + * On success, returns the MTRR that was used (@reg) and a handle that can + * be passed to XENPF_DEL_MEMTYPE to accurately tear down the new setting. + * (x86-specific). + */ +#define XENPF_add_memtype 31 +struct xenpf_add_memtype { + /* IN variables. */ + unsigned long mfn; + uint64_t nr_mfns; + uint32_t type; + /* OUT variables. */ + uint32_t handle; + uint32_t reg; +}; +DEFINE_GUEST_HANDLE_STRUCT(xenpf_add_memtype_t); + +/* + * Tear down an existing memory-range type. If @handle is remembered then it + * should be passed in to accurately tear down the correct setting (in case + * of overlapping memory regions with differing types). If it is not known + * then @handle should be set to zero. In all cases @reg must be set. + * (x86-specific). + */ +#define XENPF_del_memtype 32 +struct xenpf_del_memtype { + /* IN variables. */ + uint32_t handle; + uint32_t reg; +}; +DEFINE_GUEST_HANDLE_STRUCT(xenpf_del_memtype_t); + +/* Read current type of an MTRR (x86-specific). */ +#define XENPF_read_memtype 33 +struct xenpf_read_memtype { + /* IN variables. */ + uint32_t reg; + /* OUT variables. */ + unsigned long mfn; + uint64_t nr_mfns; + uint32_t type; +}; +DEFINE_GUEST_HANDLE_STRUCT(xenpf_read_memtype_t); + +#define XENPF_microcode_update 35 +struct xenpf_microcode_update { + /* IN variables. */ + GUEST_HANDLE(void) data; /* Pointer to microcode data */ + uint32_t length; /* Length of microcode data. */ +}; +DEFINE_GUEST_HANDLE_STRUCT(xenpf_microcode_update_t); + +#define XENPF_platform_quirk 39 +#define QUIRK_NOIRQBALANCING 1 /* Do not restrict IO-APIC RTE targets */ +#define QUIRK_IOAPIC_BAD_REGSEL 2 /* IO-APIC REGSEL forgets its value */ +#define QUIRK_IOAPIC_GOOD_REGSEL 3 /* IO-APIC REGSEL behaves properly */ +struct xenpf_platform_quirk { + /* IN variables. */ + uint32_t quirk_id; +}; +DEFINE_GUEST_HANDLE_STRUCT(xenpf_platform_quirk_t); + +#define XENPF_firmware_info 50 +#define XEN_FW_DISK_INFO 1 /* from int 13 AH=08/41/48 */ +#define XEN_FW_DISK_MBR_SIGNATURE 2 /* from MBR offset 0x1b8 */ +#define XEN_FW_VBEDDC_INFO 3 /* from int 10 AX=4f15 */ +struct xenpf_firmware_info { + /* IN variables. */ + uint32_t type; + uint32_t index; + /* OUT variables. */ + union { + struct { + /* Int13, Fn48: Check Extensions Present. */ + uint8_t device; /* %dl: bios device number */ + uint8_t version; /* %ah: major version */ + uint16_t interface_support; /* %cx: support bitmap */ + /* Int13, Fn08: Legacy Get Device Parameters. */ + uint16_t legacy_max_cylinder; /* %cl[7:6]:%ch: max cyl # */ + uint8_t legacy_max_head; /* %dh: max head # */ + uint8_t legacy_sectors_per_track; /* %cl[5:0]: max sector # */ + /* Int13, Fn41: Get Device Parameters (as filled into %ds:%esi). */ + /* NB. First uint16_t of buffer must be set to buffer size. */ + GUEST_HANDLE(void) edd_params; + } disk_info; /* XEN_FW_DISK_INFO */ + struct { + uint8_t device; /* bios device number */ + uint32_t mbr_signature; /* offset 0x1b8 in mbr */ + } disk_mbr_signature; /* XEN_FW_DISK_MBR_SIGNATURE */ + struct { + /* Int10, AX=4F15: Get EDID info. */ + uint8_t capabilities; + uint8_t edid_transfer_time; + /* must refer to 128-byte buffer */ + GUEST_HANDLE(uchar) edid; + } vbeddc_info; /* XEN_FW_VBEDDC_INFO */ + } u; +}; +DEFINE_GUEST_HANDLE_STRUCT(xenpf_firmware_info_t); + +#define XENPF_enter_acpi_sleep 51 +struct xenpf_enter_acpi_sleep { + /* IN variables */ + uint16_t pm1a_cnt_val; /* PM1a control value. */ + uint16_t pm1b_cnt_val; /* PM1b control value. */ + uint32_t sleep_state; /* Which state to enter (Sn). */ + uint32_t flags; /* Must be zero. */ +}; +DEFINE_GUEST_HANDLE_STRUCT(xenpf_enter_acpi_sleep_t); + +#define XENPF_change_freq 52 +struct xenpf_change_freq { + /* IN variables */ + uint32_t flags; /* Must be zero. */ + uint32_t cpu; /* Physical cpu. */ + uint64_t freq; /* New frequency (Hz). */ +}; +DEFINE_GUEST_HANDLE_STRUCT(xenpf_change_freq_t); + +/* + * Get idle times (nanoseconds since boot) for physical CPUs specified in the + * @cpumap_bitmap with range [0..@cpumap_nr_cpus-1]. The @idletime array is + * indexed by CPU number; only entries with the corresponding @cpumap_bitmap + * bit set are written to. On return, @cpumap_bitmap is modified so that any + * non-existent CPUs are cleared. Such CPUs have their @idletime array entry + * cleared. + */ +#define XENPF_getidletime 53 +struct xenpf_getidletime { + /* IN/OUT variables */ + /* IN: CPUs to interrogate; OUT: subset of IN which are present */ + GUEST_HANDLE(uchar) cpumap_bitmap; + /* IN variables */ + /* Size of cpumap bitmap. */ + uint32_t cpumap_nr_cpus; + /* Must be indexable for every cpu in cpumap_bitmap. */ + GUEST_HANDLE(uint64_t) idletime; + /* OUT variables */ + /* System time when the idletime snapshots were taken. */ + uint64_t now; +}; +DEFINE_GUEST_HANDLE_STRUCT(xenpf_getidletime_t); + +#define XENPF_set_processor_pminfo 54 + +/* ability bits */ +#define XEN_PROCESSOR_PM_CX 1 +#define XEN_PROCESSOR_PM_PX 2 +#define XEN_PROCESSOR_PM_TX 4 + +/* cmd type */ +#define XEN_PM_CX 0 +#define XEN_PM_PX 1 +#define XEN_PM_TX 2 + +/* Px sub info type */ +#define XEN_PX_PCT 1 +#define XEN_PX_PSS 2 +#define XEN_PX_PPC 4 +#define XEN_PX_PSD 8 + +struct xen_power_register { + uint32_t space_id; + uint32_t bit_width; + uint32_t bit_offset; + uint32_t access_size; + uint64_t address; +}; + +struct xen_processor_csd { + uint32_t domain; /* domain number of one dependent group */ + uint32_t coord_type; /* coordination type */ + uint32_t num; /* number of processors in same domain */ +}; +DEFINE_GUEST_HANDLE_STRUCT(xen_processor_csd); + +struct xen_processor_cx { + struct xen_power_register reg; /* GAS for Cx trigger register */ + uint8_t type; /* cstate value, c0: 0, c1: 1, ... */ + uint32_t latency; /* worst latency (ms) to enter/exit this cstate */ + uint32_t power; /* average power consumption(mW) */ + uint32_t dpcnt; /* number of dependency entries */ + GUEST_HANDLE(xen_processor_csd) dp; /* NULL if no dependency */ +}; +DEFINE_GUEST_HANDLE_STRUCT(xen_processor_cx); + +struct xen_processor_flags { + uint32_t bm_control:1; + uint32_t bm_check:1; + uint32_t has_cst:1; + uint32_t power_setup_done:1; + uint32_t bm_rld_set:1; +}; + +struct xen_processor_power { + uint32_t count; /* number of C state entries in array below */ + struct xen_processor_flags flags; /* global flags of this processor */ + GUEST_HANDLE(xen_processor_cx) states; /* supported c states */ +}; + +struct xen_pct_register { + uint8_t descriptor; + uint16_t length; + uint8_t space_id; + uint8_t bit_width; + uint8_t bit_offset; + uint8_t reserved; + uint64_t address; +}; + +struct xen_processor_px { + uint64_t core_frequency; /* megahertz */ + uint64_t power; /* milliWatts */ + uint64_t transition_latency; /* microseconds */ + uint64_t bus_master_latency; /* microseconds */ + uint64_t control; /* control value */ + uint64_t status; /* success indicator */ +}; +DEFINE_GUEST_HANDLE_STRUCT(xen_processor_px); + +struct xen_psd_package { + uint64_t num_entries; + uint64_t revision; + uint64_t domain; + uint64_t coord_type; + uint64_t num_processors; +}; + +struct xen_processor_performance { + uint32_t flags; /* flag for Px sub info type */ + uint32_t platform_limit; /* Platform limitation on freq usage */ + struct xen_pct_register control_register; + struct xen_pct_register status_register; + uint32_t state_count; /* total available performance states */ + GUEST_HANDLE(xen_processor_px) states; + struct xen_psd_package domain_info; + uint32_t shared_type; /* coordination type of this processor */ +}; +DEFINE_GUEST_HANDLE_STRUCT(xen_processor_performance); + +struct xenpf_set_processor_pminfo { + /* IN variables */ + uint32_t id; /* ACPI CPU ID */ + uint32_t type; /* {XEN_PM_CX, XEN_PM_PX} */ + union { + struct xen_processor_power power;/* Cx: _CST/_CSD */ + struct xen_processor_performance perf; /* Px: _PPC/_PCT/_PSS/_PSD */ + }; +}; +DEFINE_GUEST_HANDLE_STRUCT(xenpf_set_processor_pminfo); + +struct xen_platform_op { + uint32_t cmd; + uint32_t interface_version; /* XENPF_INTERFACE_VERSION */ + union { + struct xenpf_settime settime; + struct xenpf_add_memtype add_memtype; + struct xenpf_del_memtype del_memtype; + struct xenpf_read_memtype read_memtype; + struct xenpf_microcode_update microcode; + struct xenpf_platform_quirk platform_quirk; + struct xenpf_firmware_info firmware_info; + struct xenpf_enter_acpi_sleep enter_acpi_sleep; + struct xenpf_change_freq change_freq; + struct xenpf_getidletime getidletime; + struct xenpf_set_processor_pminfo set_pminfo; + uint8_t pad[128]; + } u; +}; +DEFINE_GUEST_HANDLE_STRUCT(xen_platform_op_t); + +#endif /* __XEN_PUBLIC_PLATFORM_H__ */ diff --git a/include/xen/interface/xen.h b/include/xen/interface/xen.h index 6acd9ce..6a6e914 100644 --- a/include/xen/interface/xen.h +++ b/include/xen/interface/xen.h @@ -492,6 +492,7 @@ struct dom0_vga_console_info { /* These flags are passed in the 'flags' field of start_info_t. */ #define SIF_PRIVILEGED (1<<0) /* Is the domain privileged? */ #define SIF_INITDOMAIN (1<<1) /* Is this the initial control domain? */ +#define SIF_PM_MASK (0xFF<<8) /* reserve 1 byte for xen-pm options */ typedef uint64_t cpumap_t; -- 1.7.4.1 _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel From xen-devel-bounces@lists.xensource.com Thu Sep 29 13:29:56 2011 Return-path: <xen-devel-bounces@lists.xensource.com> Envelope-to: www-data@lists.xensource.com Delivery-date: Thu, 29 Sep 2011 13:29:56 -0700 Received: from localhost ([127.0.0.1] helo=lists.colo.xensource.com) by lists.xensource.com with esmtp (Exim 4.43) id 1R9NEx-0002KP-TG; Thu, 29 Sep 2011 13:29:55 -0700 Received: from mail21.messagelabs.com ([85.158.143.35]) by lists.xensource.com with smtp (Exim 4.43) id 1R9NDT-0001x1-79 for xen-devel@lists.xensource.com; Thu, 29 Sep 2011 13:28:23 -0700 X-Env-Sender: joseph.cihula@intel.com X-Msg-Ref: server-5.tower-21.messagelabs.com!1317328064!50062473!1 X-Originating-IP: [143.182.124.37] X-StarScan-Version: 6.4.1; banners=-,-,- X-VirusChecked: Checked Received: (qmail 12437 invoked from network); 29 Sep 2011 20:27:44 -0000 Received: from mga14.intel.com (HELO mga14.intel.com) (143.182.124.37) by server-5.tower-21.messagelabs.com with SMTP; 29 Sep 2011 20:27:44 -0000 Received: from azsmga002.ch.intel.com ([10.2.17.35]) by azsmga102.ch.intel.com with ESMTP; 29 Sep 2011 13:28:18 -0700 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="4.68,463,1312182000"; d="scan'208";a="21926884" Received: from orsmsx602.amr.corp.intel.com ([10.22.226.211]) by AZSMGA002.ch.intel.com with ESMTP; 29 Sep 2011 13:28:17 -0700 Received: from orsmsx105.amr.corp.intel.com (10.22.225.132) by orsmsx602.amr.corp.intel.com (10.22.226.211) with Microsoft SMTP Server (TLS) id 8.2.255.0; Thu, 29 Sep 2011 13:28:17 -0700 Received: from orsmsx101.amr.corp.intel.com ([169.254.8.109]) by ORSMSX105.amr.corp.intel.com ([169.254.4.120]) with mapi id 14.01.0323.003; Thu, 29 Sep 2011 13:28:16 -0700 From: "Cihula, Joseph" <joseph.cihula@intel.com> To: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>, "linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>, "rjw@sisk.pl" <rjw@sisk.pl>, "tglx@linutronix.de" <tglx@linutronix.de>, "hpa@zytor.com" <hpa@zytor.com>, "x86@kernel.org" <x86@kernel.org>, "Brown, Len" <len.brown@intel.com>, "Wang, Shane" <shane.wang@intel.com>, "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>, "linux-pm@lists.linux-foundation.org" <linux-pm@lists.linux-foundation.org>, "tboot-devel@lists.sourceforge.net" <tboot-devel@lists.sourceforge.net>, "linux-acpi@vger.kernel.org" <linux-acpi@vger.kernel.org>, "liang.tang@oracle.com" <liang.tang@oracle.com>, "Yu, Ke" <ke.yu@intel.com>, "Tian, Kevin" <kevin.tian@intel.com>, "jeremy@goop.org" <jeremy@goop.org> Thread-Topic: [PATCH 2/8] x86, acpi, tboot: Have a ACPI sleep override instead of calling tboot_sleep. Thread-Index: AQHMfuTGHPVJaHdrN0um3j/aPIi2ZZVkzsqw Date: Thu, 29 Sep 2011 20:28:16 +0000 Message-ID: <9F57BF860713DF4BA3EFA4F8C6DFEDAC16F7CD3A@ORSMSX101.amr.corp.intel.com> References: <1317327414-24072-1-git-send-email-konrad.wilk@oracle.com> <1317327414-24072-3-git-send-email-konrad.wilk@oracle.com> In-Reply-To: <1317327414-24072-3-git-send-email-konrad.wilk@oracle.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.22.254.138] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: Subject: [Xen-devel] RE: [PATCH 2/8] x86, acpi, tboot: Have a ACPI sleep override instead of calling tboot_sleep. X-BeenThere: xen-devel@lists.xensource.com X-Mailman-Version: 2.1.5 Precedence: list List-Id: Xen developer discussion <xen-devel.lists.xensource.com> List-Unsubscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe> List-Post: <mailto:xen-devel@lists.xensource.com> List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help> List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=subscribe> Sender: xen-devel-bounces@lists.xensource.com Errors-To: xen-devel-bounces@lists.xensource.com ACK. > -----Original Message----- > From: Konrad Rzeszutek Wilk [mailto:konrad.wilk@oracle.com] > Sent: Thursday, September 29, 2011 1:17 PM > To: linux-kernel@vger.kernel.org; rjw@sisk.pl; tglx@linutronix.de; hpa@zy= tor.com; x86@kernel.org; > Brown, Len; Cihula, Joseph; Wang, Shane; xen-devel@lists.xensource.com; l= inux-pm@lists.linux- > foundation.org; tboot-devel@lists.sourceforge.net; linux-acpi@vger.kernel= .org; > liang.tang@oracle.com; Yu, Ke; Tian, Kevin; jeremy@goop.org > Cc: Konrad Rzeszutek Wilk > Subject: [PATCH 2/8] x86, acpi, tboot: Have a ACPI sleep override instead= of calling tboot_sleep. >=20 > The ACPI suspend path makes a call to tboot_sleep right before it writes = the PM1A, PM1B values. We > replace the direct call to tboot via an registration callback similar to = __acpi_register_gsi. >=20 > CC: Thomas Gleixner <tglx@linutronix.de> > CC: "H. Peter Anvin" <hpa@zytor.com> > CC: x86@kernel.org > CC: Len Brown <len.brown@intel.com> > CC: Joseph Cihula <joseph.cihula@intel.com> > CC: Shane Wang <shane.wang@intel.com> > CC: xen-devel@lists.xensource.com > CC: linux-pm@lists.linux-foundation.org > CC: tboot-devel@lists.sourceforge.net > CC: linux-acpi@vger.kernel.org > [v1: Added __attribute__ ((unused))] > Signed-off-by: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com> > --- > arch/x86/include/asm/acpi.h | 4 ++++ > arch/x86/kernel/acpi/boot.c | 4 ++++ > arch/x86/kernel/tboot.c | 14 ++++++++++---- > drivers/acpi/acpica/hwsleep.c | 12 ++++++++++-- > include/linux/tboot.h | 3 ++- > 5 files changed, 30 insertions(+), 7 deletions(-) >=20 > diff --git a/arch/x86/include/asm/acpi.h b/arch/x86/include/asm/acpi.h in= dex 610001d..0a46696 > 100644 > --- a/arch/x86/include/asm/acpi.h > +++ b/arch/x86/include/asm/acpi.h > @@ -98,6 +98,10 @@ void acpi_pic_sci_set_trigger(unsigned int, u16); ext= ern int > (*__acpi_register_gsi)(struct device *dev, u32 gsi, > int trigger, int polarity); >=20 > +extern int (*__acpi_override_sleep)(u8 sleep_state, u32 pm1a_ctrl, > + u32 pm1b_ctrl, bool *skip_rest) \ > + __attribute__ ((unused)); > + > static inline void disable_acpi(void) > { > acpi_disabled =3D 1; > diff --git a/arch/x86/kernel/acpi/boot.c b/arch/x86/kernel/acpi/boot.c in= dex 4558f0d..7f30806 > 100644 > --- a/arch/x86/kernel/acpi/boot.c > +++ b/arch/x86/kernel/acpi/boot.c > @@ -552,6 +552,10 @@ static int acpi_register_gsi_ioapic(struct device *d= ev, u32 gsi, int > (*__acpi_register_gsi)(struct device *dev, u32 gsi, > int trigger, int polarity) =3D acpi_register_gsi_pic; >=20 > +int (*__acpi_override_sleep)(u8 sleep_state, u32 pm1a_ctrl, > + u32 pm1b_ctrl, bool *skip_rest) \ > + __attribute__ ((unused)) =3D NULL; > + > /* > * success: return IRQ number (>=3D0) > * failure: return < 0 > diff --git a/arch/x86/kernel/tboot.c b/arch/x86/kernel/tboot.c index e07a= 2fc..a6c0a30 100644 > --- a/arch/x86/kernel/tboot.c > +++ b/arch/x86/kernel/tboot.c > @@ -42,7 +42,7 @@ > #include <asm/setup.h> > #include <asm/e820.h> > #include <asm/io.h> > - > +#include <linux/acpi.h> > #include "acpi/realmode/wakeup.h" >=20 > /* Global pointer to shared data; NULL means no measured launch. */ @@ -= 271,7 +271,9 @@ static > void tboot_copy_fadt(const struct acpi_table_fadt *fadt) > offsetof(struct acpi_table_facs, firmware_waking_vector); } >=20 > -void tboot_sleep(u8 sleep_state, u32 pm1a_control, u32 pm1b_control) > + > +int tboot_sleep(u8 sleep_state, u32 pm1a_control, u32 pm1b_control, > + bool *skip_rest) > { > static u32 acpi_shutdown_map[ACPI_S_STATE_COUNT] =3D { > /* S0,1,2: */ -1, -1, -1, > @@ -280,7 +282,7 @@ void tboot_sleep(u8 sleep_state, u32 pm1a_control, u3= 2 pm1b_control) > /* S5: */ TB_SHUTDOWN_S5 }; >=20 > if (!tboot_enabled()) > - return; > + return AE_OK; >=20 > tboot_copy_fadt(&acpi_gbl_FADT); > tboot->acpi_sinfo.pm1a_cnt_val =3D pm1a_control; @@ -291,10 +293,12 @@ = void tboot_sleep(u8 > sleep_state, u32 pm1a_control, u32 pm1b_control) > if (sleep_state >=3D ACPI_S_STATE_COUNT || > acpi_shutdown_map[sleep_state] =3D=3D -1) { > pr_warning("unsupported sleep state 0x%x\n", sleep_state); > - return; > + return AE_ERROR; > } >=20 > tboot_shutdown(acpi_shutdown_map[sleep_state]); > + > + return AE_OK; > } >=20 > static atomic_t ap_wfs_count; > @@ -344,6 +348,8 @@ static __init int tboot_late_init(void) >=20 > atomic_set(&ap_wfs_count, 0); > register_hotcpu_notifier(&tboot_cpu_notifier); > + > + __acpi_override_sleep =3D tboot_sleep; > return 0; > } >=20 > diff --git a/drivers/acpi/acpica/hwsleep.c b/drivers/acpi/acpica/hwsleep.= c index 2ac28bb..31d1198 > 100644 > --- a/drivers/acpi/acpica/hwsleep.c > +++ b/drivers/acpi/acpica/hwsleep.c > @@ -45,7 +45,6 @@ > #include <acpi/acpi.h> > #include "accommon.h" > #include "actables.h" > -#include <linux/tboot.h> >=20 > #define _COMPONENT ACPI_HARDWARE > ACPI_MODULE_NAME("hwsleep") > @@ -343,8 +342,17 @@ acpi_status asmlinkage acpi_enter_sleep_state(u8 sle= ep_state) >=20 > ACPI_FLUSH_CPU_CACHE(); >=20 > - tboot_sleep(sleep_state, pm1a_control, pm1b_control); > + if (__acpi_override_sleep) { > + bool skip_rest =3D false; >=20 > + status =3D __acpi_override_sleep(sleep_state, pm1a_control, > + pm1b_control, &skip_rest); > + > + if (ACPI_FAILURE(status)) > + return_ACPI_STATUS(status); > + if (skip_rest) > + return_ACPI_STATUS(AE_OK); > + } > /* Write #2: Write both SLP_TYP + SLP_EN */ >=20 > status =3D acpi_hw_write_pm1_control(pm1a_control, pm1b_control); diff = --git > a/include/linux/tboot.h b/include/linux/tboot.h index 1dba6ee..1216698 10= 0644 > --- a/include/linux/tboot.h > +++ b/include/linux/tboot.h > @@ -143,7 +143,8 @@ static inline int tboot_enabled(void) >=20 > extern void tboot_probe(void); > extern void tboot_shutdown(u32 shutdown_type); -extern void tboot_sleep(= u8 sleep_state, u32 > pm1a_control, u32 pm1b_control); > +extern int tboot_sleep(u8 sleep_state, u32 pm1a_control, u32 pm1b_contro= l, > + bool *skip_rest) __attribute__ ((unused)); > extern struct acpi_table_header *tboot_get_dmar_table( > struct acpi_table_header *dmar_tbl); extern int > tboot_force_iommu(void); > -- > 1.7.4.1 _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel From xen-devel-bounces@lists.xensource.com Thu Sep 29 13:31:53 2011 Return-path: <xen-devel-bounces@lists.xensource.com> Envelope-to: www-data@lists.xensource.com Delivery-date: Thu, 29 Sep 2011 13:31:53 -0700 Received: from localhost ([127.0.0.1] helo=lists.colo.xensource.com) by lists.xensource.com with esmtp (Exim 4.43) id 1R9NGr-0002mD-34; Thu, 29 Sep 2011 13:31:53 -0700 Received: from mail216.messagelabs.com ([85.158.143.99]) by lists.xensource.com with smtp (Exim 4.43) id 1R9NG8-0002WT-UG for xen-devel@lists.xensource.com; Thu, 29 Sep 2011 13:31:09 -0700 X-Env-Sender: joseph.cihula@intel.com X-Msg-Ref: server-2.tower-216.messagelabs.com!1317328264!19610424!1 X-Originating-IP: [143.182.124.37] X-StarScan-Version: 6.4.1; banners=-,-,- X-VirusChecked: Checked Received: (qmail 10932 invoked from network); 29 Sep 2011 20:31:05 -0000 Received: from mga14.intel.com (HELO mga14.intel.com) (143.182.124.37) by server-2.tower-216.messagelabs.com with SMTP; 29 Sep 2011 20:31:05 -0000 Received: from azsmga002.ch.intel.com ([10.2.17.35]) by azsmga102.ch.intel.com with ESMTP; 29 Sep 2011 13:31:04 -0700 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="4.68,463,1312182000"; d="scan'208";a="21928491" Received: from orsmsx602.amr.corp.intel.com ([10.22.226.211]) by AZSMGA002.ch.intel.com with ESMTP; 29 Sep 2011 13:31:03 -0700 Received: from orsmsx106.amr.corp.intel.com (10.22.225.133) by orsmsx602.amr.corp.intel.com (10.22.226.211) with Microsoft SMTP Server (TLS) id 8.2.255.0; Thu, 29 Sep 2011 13:30:37 -0700 Received: from orsmsx101.amr.corp.intel.com ([169.254.8.109]) by ORSMSX106.amr.corp.intel.com ([169.254.5.101]) with mapi id 14.01.0323.003; Thu, 29 Sep 2011 13:30:36 -0700 From: "Cihula, Joseph" <joseph.cihula@intel.com> To: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>, "linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>, "rjw@sisk.pl" <rjw@sisk.pl>, "tglx@linutronix.de" <tglx@linutronix.de>, "hpa@zytor.com" <hpa@zytor.com>, "x86@kernel.org" <x86@kernel.org>, "Brown, Len" <len.brown@intel.com>, "Wang, Shane" <shane.wang@intel.com>, "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>, "linux-pm@lists.linux-foundation.org" <linux-pm@lists.linux-foundation.org>, "tboot-devel@lists.sourceforge.net" <tboot-devel@lists.sourceforge.net>, "linux-acpi@vger.kernel.org" <linux-acpi@vger.kernel.org>, "liang.tang@oracle.com" <liang.tang@oracle.com>, "Yu, Ke" <ke.yu@intel.com>, "Tian, Kevin" <kevin.tian@intel.com>, "jeremy@goop.org" <jeremy@goop.org> Thread-Topic: [PATCH 3/8] x86/acpi/sleep: Provide registration for acpi_suspend_lowlevel. Thread-Index: AQHMfuTWyLtvImwM7EyberMoVXrmdJVkz30Q Date: Thu, 29 Sep 2011 20:30:36 +0000 Message-ID: <9F57BF860713DF4BA3EFA4F8C6DFEDAC16F7CD7D@ORSMSX101.amr.corp.intel.com> References: <1317327414-24072-1-git-send-email-konrad.wilk@oracle.com> <1317327414-24072-4-git-send-email-konrad.wilk@oracle.com> In-Reply-To: <1317327414-24072-4-git-send-email-konrad.wilk@oracle.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.22.254.138] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: Subject: [Xen-devel] RE: [PATCH 3/8] x86/acpi/sleep: Provide registration for acpi_suspend_lowlevel. X-BeenThere: xen-devel@lists.xensource.com X-Mailman-Version: 2.1.5 Precedence: list List-Id: Xen developer discussion <xen-devel.lists.xensource.com> List-Unsubscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe> List-Post: <mailto:xen-devel@lists.xensource.com> List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help> List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=subscribe> Sender: xen-devel-bounces@lists.xensource.com Errors-To: xen-devel-bounces@lists.xensource.com ACK > -----Original Message----- > From: Konrad Rzeszutek Wilk [mailto:konrad.wilk@oracle.com] > Sent: Thursday, September 29, 2011 1:17 PM > To: linux-kernel@vger.kernel.org; rjw@sisk.pl; tglx@linutronix.de; hpa@zy= tor.com; x86@kernel.org; > Brown, Len; Cihula, Joseph; Wang, Shane; xen-devel@lists.xensource.com; l= inux-pm@lists.linux- > foundation.org; tboot-devel@lists.sourceforge.net; linux-acpi@vger.kernel= .org; > liang.tang@oracle.com; Yu, Ke; Tian, Kevin; jeremy@goop.org > Cc: Konrad Rzeszutek Wilk > Subject: [PATCH 3/8] x86/acpi/sleep: Provide registration for acpi_suspen= d_lowlevel. >=20 > From: Liang Tang <liang.tang@oracle.com> >=20 > Which by default will be x86_acpi_suspend_lowlevel. > This registration allows us to register another callback if there is a ne= ed to use another > platform specific callback. >=20 > CC: Thomas Gleixner <tglx@linutronix.de> > CC: "H. Peter Anvin" <hpa@zytor.com> > CC: x86@kernel.org > CC: Len Brown <len.brown@intel.com> > CC: Joseph Cihula <joseph.cihula@intel.com> > CC: Shane Wang <shane.wang@intel.com> > CC: linux-pm@lists.linux-foundation.org > CC: linux-acpi@vger.kernel.org > CC: Len Brown <len.brown@intel.com> > Signed-off-by: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com> > Signed-off-by: Liang Tang <liang.tang@oracle.com> > --- > arch/x86/include/asm/acpi.h | 2 +- > arch/x86/kernel/acpi/boot.c | 2 ++ > arch/x86/kernel/acpi/sleep.c | 4 ++-- > arch/x86/kernel/acpi/sleep.h | 2 ++ > drivers/acpi/sleep.c | 2 ++ > 5 files changed, 9 insertions(+), 3 deletions(-) >=20 > diff --git a/arch/x86/include/asm/acpi.h b/arch/x86/include/asm/acpi.h in= dex 0a46696..9b538dc > 100644 > --- a/arch/x86/include/asm/acpi.h > +++ b/arch/x86/include/asm/acpi.h > @@ -119,7 +119,7 @@ static inline void acpi_disable_pci(void) } >=20 > /* Low-level suspend routine. */ > -extern int acpi_suspend_lowlevel(void); > +extern int (*acpi_suspend_lowlevel)(void); >=20 > extern const unsigned char acpi_wakeup_code[]; #define acpi_wakeup_addr= ess > (__pa(TRAMPOLINE_SYM(acpi_wakeup_code))) > diff --git a/arch/x86/kernel/acpi/boot.c b/arch/x86/kernel/acpi/boot.c in= dex 7f30806..ddd081b > 100644 > --- a/arch/x86/kernel/acpi/boot.c > +++ b/arch/x86/kernel/acpi/boot.c > @@ -44,6 +44,7 @@ > #include <asm/mpspec.h> > #include <asm/smp.h> >=20 > +#include "sleep.h" /* To include x86_acpi_suspend_lowlevel */ > static int __initdata acpi_force =3D 0; > u32 acpi_rsdt_forced; > int acpi_disabled; > @@ -556,6 +557,7 @@ int (*__acpi_override_sleep)(u8 sleep_state, u32 pm1a= _ctrl, > u32 pm1b_ctrl, bool *skip_rest) \ > __attribute__ ((unused)) =3D NULL; >=20 > +int (*acpi_suspend_lowlevel)(void) =3D x86_acpi_suspend_lowlevel; > /* > * success: return IRQ number (>=3D0) > * failure: return < 0 > diff --git a/arch/x86/kernel/acpi/sleep.c b/arch/x86/kernel/acpi/sleep.c = index 103b6ab..4d2d0b1 > 100644 > --- a/arch/x86/kernel/acpi/sleep.c > +++ b/arch/x86/kernel/acpi/sleep.c > @@ -25,12 +25,12 @@ static char temp_stack[4096]; #endif >=20 > /** > - * acpi_suspend_lowlevel - save kernel state > + * x86_acpi_suspend_lowlevel - save kernel state > * > * Create an identity mapped page table and copy the wakeup routine to > * low memory. > */ > -int acpi_suspend_lowlevel(void) > +int x86_acpi_suspend_lowlevel(void) > { > struct wakeup_header *header; > /* address in low memory of the wakeup routine. */ diff --git a/arch/x8= 6/kernel/acpi/sleep.h > b/arch/x86/kernel/acpi/sleep.h index 416d4be..4d3feb5 100644 > --- a/arch/x86/kernel/acpi/sleep.h > +++ b/arch/x86/kernel/acpi/sleep.h > @@ -13,3 +13,5 @@ extern unsigned long acpi_copy_wakeup_routine(unsigned = long); extern void > wakeup_long64(void); >=20 > extern void do_suspend_lowlevel(void); > + > +extern int x86_acpi_suspend_lowlevel(void); > diff --git a/drivers/acpi/sleep.c b/drivers/acpi/sleep.c index 3ed80b2..3= 570c00 100644 > --- a/drivers/acpi/sleep.c > +++ b/drivers/acpi/sleep.c > @@ -254,6 +254,8 @@ static int acpi_suspend_enter(suspend_state_t pm_stat= e) > break; >=20 > case ACPI_STATE_S3: > + if (!acpi_suspend_lowlevel) > + return -ENODEV; > error =3D acpi_suspend_lowlevel(); > if (error) > return error; > -- > 1.7.4.1 _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel From xen-devel-bounces@lists.xensource.com Thu Sep 29 13:34:44 2011 Return-path: <xen-devel-bounces@lists.xensource.com> Envelope-to: www-data@lists.xensource.com Delivery-date: Thu, 29 Sep 2011 13:34:44 -0700 Received: from localhost ([127.0.0.1] helo=lists.colo.xensource.com) by lists.xensource.com with esmtp (Exim 4.43) id 1R9NJc-0003JN-Ap; Thu, 29 Sep 2011 13:34:44 -0700 Received: from mail182.messagelabs.com ([85.158.139.83]) by lists.xensource.com with esmtp (Exim 4.43) id 1R9NJ6-00036i-9p for xen-devel@lists.xensource.com; Thu, 29 Sep 2011 13:34:12 -0700 X-Env-Sender: konrad@oracle.com X-Msg-Ref: server-14.tower-182.messagelabs.com!1317328447!20103695!1 X-Originating-IP: [141.146.126.227] X-StarScan-Version: 6.4.1; banners=-,-,- X-VirusChecked: Checked Received: (qmail 32287 invoked from network); 29 Sep 2011 20:34:09 -0000 Received: from acsinet15.oracle.com (HELO acsinet15.oracle.com) (141.146.126.227) by server-14.tower-182.messagelabs.com with DHE-RSA-AES256-SHA encrypted SMTP; 29 Sep 2011 20:34:09 -0000 Received: from acsinet22.oracle.com (acsinet22.oracle.com [141.146.126.238]) by acsinet15.oracle.com (Switch-3.4.4/Switch-3.4.4) with ESMTP id p8TKY28Z000875 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Thu, 29 Sep 2011 20:34:03 GMT Received: from acsmt356.oracle.com (acsmt356.oracle.com [141.146.40.156]) by acsinet22.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id p8TKY1Ew004946 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 29 Sep 2011 20:34:01 GMT Received: from abhmt114.oracle.com (abhmt114.oracle.com [141.146.116.66]) by acsmt356.oracle.com (8.12.11.20060308/8.12.11) with ESMTP id p8TKXtUg001806; Thu, 29 Sep 2011 15:33:55 -0500 Received: from oracle.com (/207.172.105.198) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Thu, 29 Sep 2011 13:33:55 -0700 Received: by oracle.com (Postfix, from userid 1000) id 1FAB8154C; Thu, 29 Sep 2011 16:33:54 -0400 (EDT) From: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com> To: linux-kernel@vger.kernel.org, thellstrom@vmware.com, dri-devel@lists.freedesktop.org, bskeggs@redhat.com, j.glisse@redhat.com, thomas@shipmail.org, airlied@redhat.com, airlied@linux.ie, alexdeucher@gmail.com Date: Thu, 29 Sep 2011 16:33:44 -0400 Message-Id: <1317328432-25620-2-git-send-email-konrad.wilk@oracle.com> X-Mailer: git-send-email 1.7.4.1 In-Reply-To: <1317328432-25620-1-git-send-email-konrad.wilk@oracle.com> References: <1317328432-25620-1-git-send-email-konrad.wilk@oracle.com> X-Source-IP: acsinet22.oracle.com [141.146.126.238] X-Auth-Type: Internal IP X-CT-RefId: str=0001.0A090205.4E84D63C.00A0:SCFMA922111,ss=1,re=-4.000,fgs=0 Cc: xen-devel@lists.xensource.com, Konrad Rzeszutek Wilk <konrad.wilk@oracle.com> Subject: [Xen-devel] [PATCH 1/9] ttm/radeon/nouveau: Check the DMA address from TTM against known value. X-BeenThere: xen-devel@lists.xensource.com X-Mailman-Version: 2.1.5 Precedence: list List-Id: Xen developer discussion <xen-devel.lists.xensource.com> List-Unsubscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe> List-Post: <mailto:xen-devel@lists.xensource.com> List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help> List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=subscribe> Sender: xen-devel-bounces@lists.xensource.com Errors-To: xen-devel-bounces@lists.xensource.com . instead of checking against the DMA_ERROR_CODE value which is per-platform specific. The zero value is a known invalid value that the TTM layer sets on the dma_address array if it is not used (ttm_tt_alloc_page_directory calls drm_calloc_large which creates a page with GFP_ZERO). We can't use pci_dma_mapping_error as that is IOMMU specific (some check for a specific physical address, some for ranges, some just do a check against zero). Also update the comments in the header about the true state of that parameter. Signed-off-by: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com> --- drivers/gpu/drm/nouveau/nouveau_sgdma.c | 3 +-- drivers/gpu/drm/radeon/radeon_gart.c | 4 +--- include/drm/ttm/ttm_page_alloc.h | 4 ++-- 3 files changed, 4 insertions(+), 7 deletions(-) diff --git a/drivers/gpu/drm/nouveau/nouveau_sgdma.c b/drivers/gpu/drm/nouveau/nouveau_sgdma.c index 82fad91..9b570c3 100644 --- a/drivers/gpu/drm/nouveau/nouveau_sgdma.c +++ b/drivers/gpu/drm/nouveau/nouveau_sgdma.c @@ -42,8 +42,7 @@ nouveau_sgdma_populate(struct ttm_backend *be, unsigned long num_pages, nvbe->nr_pages = 0; while (num_pages--) { - /* this code path isn't called and is incorrect anyways */ - if (0) { /*dma_addrs[nvbe->nr_pages] != DMA_ERROR_CODE)*/ + if (dma_addrs[nvbe->nr_pages] != 0) { nvbe->pages[nvbe->nr_pages] = dma_addrs[nvbe->nr_pages]; nvbe->ttm_alloced[nvbe->nr_pages] = true; diff --git a/drivers/gpu/drm/radeon/radeon_gart.c b/drivers/gpu/drm/radeon/radeon_gart.c index a533f52..068ba09 100644 --- a/drivers/gpu/drm/radeon/radeon_gart.c +++ b/drivers/gpu/drm/radeon/radeon_gart.c @@ -181,9 +181,7 @@ int radeon_gart_bind(struct radeon_device *rdev, unsigned offset, p = t / (PAGE_SIZE / RADEON_GPU_PAGE_SIZE); for (i = 0; i < pages; i++, p++) { - /* we reverted the patch using dma_addr in TTM for now but this - * code stops building on alpha so just comment it out for now */ - if (0) { /*dma_addr[i] != DMA_ERROR_CODE) */ + if (dma_addr[i] != 0) { rdev->gart.ttm_alloced[p] = true; rdev->gart.pages_addr[p] = dma_addr[i]; } else { diff --git a/include/drm/ttm/ttm_page_alloc.h b/include/drm/ttm/ttm_page_alloc.h index 8062890..0017b17 100644 --- a/include/drm/ttm/ttm_page_alloc.h +++ b/include/drm/ttm/ttm_page_alloc.h @@ -36,7 +36,7 @@ * @flags: ttm flags for page allocation. * @cstate: ttm caching state for the page. * @count: number of pages to allocate. - * @dma_address: The DMA (bus) address of pages (if TTM_PAGE_FLAG_DMA32 set). + * @dma_address: The DMA (bus) address of pages - (by default zero). */ int ttm_get_pages(struct list_head *pages, int flags, @@ -51,7 +51,7 @@ int ttm_get_pages(struct list_head *pages, * count. * @flags: ttm flags for page allocation. * @cstate: ttm caching state. - * @dma_address: The DMA (bus) address of pages (if TTM_PAGE_FLAG_DMA32 set). + * @dma_address: The DMA (bus) address of pages (by default zero). */ void ttm_put_pages(struct list_head *pages, unsigned page_count, -- 1.7.4.1 _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel From xen-devel-bounces@lists.xensource.com Thu Sep 29 13:35:36 2011 Return-path: <xen-devel-bounces@lists.xensource.com> Envelope-to: www-data@lists.xensource.com Delivery-date: Thu, 29 Sep 2011 13:35:36 -0700 Received: from localhost ([127.0.0.1] helo=lists.colo.xensource.com) by lists.xensource.com with esmtp (Exim 4.43) id 1R9NKS-0003gj-1w; Thu, 29 Sep 2011 13:35:36 -0700 Received: from mail182.messagelabs.com ([85.158.139.83]) by lists.xensource.com with esmtp (Exim 4.43) id 1R9NJ6-00036j-Al for xen-devel@lists.xensource.com; Thu, 29 Sep 2011 13:34:12 -0700 X-Env-Sender: konrad@oracle.com X-Msg-Ref: server-9.tower-182.messagelabs.com!1317328447!18454765!1 X-Originating-IP: [141.146.126.227] X-StarScan-Version: 6.4.1; banners=-,-,- X-VirusChecked: Checked Received: (qmail 10344 invoked from network); 29 Sep 2011 20:34:09 -0000 Received: from acsinet15.oracle.com (HELO acsinet15.oracle.com) (141.146.126.227) by server-9.tower-182.messagelabs.com with DHE-RSA-AES256-SHA encrypted SMTP; 29 Sep 2011 20:34:09 -0000 Received: from acsinet22.oracle.com (acsinet22.oracle.com [141.146.126.238]) by acsinet15.oracle.com (Switch-3.4.4/Switch-3.4.4) with ESMTP id p8TKY2rs000880 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Thu, 29 Sep 2011 20:34:04 GMT Received: from acsmt358.oracle.com (acsmt358.oracle.com [141.146.40.158]) by acsinet22.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id p8TKY1Ws004959 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 29 Sep 2011 20:34:02 GMT Received: from abhmt108.oracle.com (abhmt108.oracle.com [141.146.116.60]) by acsmt358.oracle.com (8.12.11.20060308/8.12.11) with ESMTP id p8TKXtVC019216; Thu, 29 Sep 2011 15:33:55 -0500 Received: from oracle.com (/207.172.105.198) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Thu, 29 Sep 2011 13:33:55 -0700 Received: by oracle.com (Postfix, from userid 1000) id 28A35154D; Thu, 29 Sep 2011 16:33:54 -0400 (EDT) From: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com> To: linux-kernel@vger.kernel.org, thellstrom@vmware.com, dri-devel@lists.freedesktop.org, bskeggs@redhat.com, j.glisse@redhat.com, thomas@shipmail.org, airlied@redhat.com, airlied@linux.ie, alexdeucher@gmail.com Date: Thu, 29 Sep 2011 16:33:45 -0400 Message-Id: <1317328432-25620-3-git-send-email-konrad.wilk@oracle.com> X-Mailer: git-send-email 1.7.4.1 In-Reply-To: <1317328432-25620-1-git-send-email-konrad.wilk@oracle.com> References: <1317328432-25620-1-git-send-email-konrad.wilk@oracle.com> X-Source-IP: acsinet22.oracle.com [141.146.126.238] X-Auth-Type: Internal IP X-CT-RefId: str=0001.0A090206.4E84D63C.0115:SCFMA922111,ss=1,re=-4.000,fgs=0 Cc: xen-devel@lists.xensource.com, Konrad Rzeszutek Wilk <konrad.wilk@oracle.com> Subject: [Xen-devel] [PATCH 2/9] ttm: Introduce ttm_page_alloc_func structure. X-BeenThere: xen-devel@lists.xensource.com X-Mailman-Version: 2.1.5 Precedence: list List-Id: Xen developer discussion <xen-devel.lists.xensource.com> List-Unsubscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe> List-Post: <mailto:xen-devel@lists.xensource.com> List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help> List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=subscribe> Sender: xen-devel-bounces@lists.xensource.com Errors-To: xen-devel-bounces@lists.xensource.com Which has the function members for all of the current page pool operations defined. The old calls (ttm_put_pages, ttm_get_pages, etc) are plumbed through little functions which lookup in the ttm_page_alloc_func the appropiate implementation and call it. There is currently only one page pool code so the default registration goes to 'ttm_page_alloc_default'. The subsequent patch "ttm: Provide a DMA aware TTM page pool code." introduces the one to be used when the SWIOTLB code is turned on (that implementation is a union of the default TTM pool code with the DMA pool code). Signed-off-by: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com> --- drivers/gpu/drm/ttm/ttm_memory.c | 3 ++ drivers/gpu/drm/ttm/ttm_page_alloc.c | 58 ++++++++++++++++++++++++++++---- include/drm/ttm/ttm_page_alloc.h | 60 ++++++++++++++++++++++++++++++++++ 3 files changed, 113 insertions(+), 8 deletions(-) diff --git a/drivers/gpu/drm/ttm/ttm_memory.c b/drivers/gpu/drm/ttm/ttm_memory.c index e70ddd8..c7d97a5 100644 --- a/drivers/gpu/drm/ttm/ttm_memory.c +++ b/drivers/gpu/drm/ttm/ttm_memory.c @@ -356,6 +356,8 @@ static int ttm_mem_init_dma32_zone(struct ttm_mem_global *glob, } #endif +struct ttm_page_alloc_func *ttm_page_alloc; + int ttm_mem_global_init(struct ttm_mem_global *glob) { struct sysinfo si; @@ -394,6 +396,7 @@ int ttm_mem_global_init(struct ttm_mem_global *glob) "Zone %7s: Available graphics memory: %llu kiB.\n", zone->name, (unsigned long long) zone->max_mem >> 10); } + ttm_page_alloc = &ttm_page_alloc_default; ttm_page_alloc_init(glob, glob->zone_kernel->max_mem/(2*PAGE_SIZE)); return 0; out_no_zone: diff --git a/drivers/gpu/drm/ttm/ttm_page_alloc.c b/drivers/gpu/drm/ttm/ttm_page_alloc.c index d948575..6a888f8 100644 --- a/drivers/gpu/drm/ttm/ttm_page_alloc.c +++ b/drivers/gpu/drm/ttm/ttm_page_alloc.c @@ -664,9 +664,9 @@ out: * On success pages list will hold count number of correctly * cached pages. */ -int ttm_get_pages(struct list_head *pages, int flags, - enum ttm_caching_state cstate, unsigned count, - dma_addr_t *dma_address) +int __ttm_get_pages(struct list_head *pages, int flags, + enum ttm_caching_state cstate, unsigned count, + dma_addr_t *dma_address) { struct ttm_page_pool *pool = ttm_get_pool(flags, cstate); struct page *p = NULL; @@ -734,8 +734,8 @@ int ttm_get_pages(struct list_head *pages, int flags, } /* Put all pages in pages list to correct pool to wait for reuse */ -void ttm_put_pages(struct list_head *pages, unsigned page_count, int flags, - enum ttm_caching_state cstate, dma_addr_t *dma_address) +void __ttm_put_pages(struct list_head *pages, unsigned page_count, int flags, + enum ttm_caching_state cstate, dma_addr_t *dma_address) { unsigned long irq_flags; struct ttm_page_pool *pool = ttm_get_pool(flags, cstate); @@ -785,7 +785,7 @@ static void ttm_page_pool_init_locked(struct ttm_page_pool *pool, int flags, pool->name = name; } -int ttm_page_alloc_init(struct ttm_mem_global *glob, unsigned max_pages) +int __ttm_page_alloc_init(struct ttm_mem_global *glob, unsigned max_pages) { int ret; @@ -822,7 +822,7 @@ int ttm_page_alloc_init(struct ttm_mem_global *glob, unsigned max_pages) return 0; } -void ttm_page_alloc_fini(void) +void __ttm_page_alloc_fini(void) { int i; @@ -836,7 +836,7 @@ void ttm_page_alloc_fini(void) _manager = NULL; } -int ttm_page_alloc_debugfs(struct seq_file *m, void *data) +int __ttm_page_alloc_debugfs(struct seq_file *m, void *data) { struct ttm_page_pool *p; unsigned i; @@ -856,4 +856,46 @@ int ttm_page_alloc_debugfs(struct seq_file *m, void *data) } return 0; } + +struct ttm_page_alloc_func ttm_page_alloc_default = { + .get_pages = __ttm_get_pages, + .put_pages = __ttm_put_pages, + .alloc_init = __ttm_page_alloc_init, + .alloc_fini = __ttm_page_alloc_fini, + .debugfs = __ttm_page_alloc_debugfs, +}; + +int ttm_get_pages(struct list_head *pages, int flags, + enum ttm_caching_state cstate, unsigned count, + dma_addr_t *dma_address) +{ + if (ttm_page_alloc && ttm_page_alloc->get_pages) + return ttm_page_alloc->get_pages(pages, flags, cstate, count, + dma_address); + return -1; +} +void ttm_put_pages(struct list_head *pages, unsigned page_count, int flags, + enum ttm_caching_state cstate, dma_addr_t *dma_address) +{ + if (ttm_page_alloc && ttm_page_alloc->put_pages) + ttm_page_alloc->put_pages(pages, page_count, flags, cstate, + dma_address); +} +int ttm_page_alloc_init(struct ttm_mem_global *glob, unsigned max_pages) +{ + if (ttm_page_alloc && ttm_page_alloc->alloc_init) + return ttm_page_alloc->alloc_init(glob, max_pages); + return -1; +} +void ttm_page_alloc_fini(void) +{ + if (ttm_page_alloc && ttm_page_alloc->alloc_fini) + ttm_page_alloc->alloc_fini(); +} +int ttm_page_alloc_debugfs(struct seq_file *m, void *data) +{ + if (ttm_page_alloc && ttm_page_alloc->debugfs) + return ttm_page_alloc->debugfs(m, data); + return -1; +} EXPORT_SYMBOL(ttm_page_alloc_debugfs); diff --git a/include/drm/ttm/ttm_page_alloc.h b/include/drm/ttm/ttm_page_alloc.h index 0017b17..6e8d73a 100644 --- a/include/drm/ttm/ttm_page_alloc.h +++ b/include/drm/ttm/ttm_page_alloc.h @@ -29,6 +29,66 @@ #include "ttm_bo_driver.h" #include "ttm_memory.h" +struct ttm_page_alloc_func { + /** + * struct ttm_page_alloc_func member get_pages + * Get count number of pages from pool to pages list. + * + * @pages: head of empty linked list where pages are filled. + * @flags: ttm flags for page allocation. + * @cstate: ttm caching state for the page. + * @count: number of pages to allocate. + * @dma_address: The DMA (bus) address of pages (by default zero). + */ + int (*get_pages) (struct list_head *pages, + int flags, + enum ttm_caching_state cstate, + unsigned count, + dma_addr_t *dma_address); + /** + * struct ttm_page_alloc_func member put_pages. + * + * Put linked list of pages to pool. + * + * @pages: list of pages to free. + * @page_count: number of pages in the list. Zero can be passed for + * unknown count. + * @flags: ttm flags for page allocation. + * @cstate: ttm caching state. + * @dma_address: The DMA (bus) address of pages (by default zero). + */ + void (*put_pages)(struct list_head *pages, + unsigned page_count, + int flags, + enum ttm_caching_state cstate, + dma_addr_t *dma_address); + /** + * struct ttm_page_alloc_func member alloc_init. + * + * Initialize pool allocator. + */ + int (*alloc_init)(struct ttm_mem_global *glob, unsigned max_pages); + + /** + * struct ttm_page_alloc_func member alloc_fini. + * + * Free pool allocator. + */ + void (*alloc_fini)(void); + + /** + * struct ttm_page_alloc_func member debugfs. + * + * Output the state of pools to debugfs file + */ + int (*debugfs)(struct seq_file *m, void *data); +}; + +extern struct ttm_page_alloc_func *ttm_page_alloc; + +/* Defined in ttm_page_alloc.c */ +extern struct ttm_page_alloc_func ttm_page_alloc_default; + /** * Get count number of pages from pool to pages list. * -- 1.7.4.1 _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel From xen-devel-bounces@lists.xensource.com Thu Sep 29 13:36:22 2011 Return-path: <xen-devel-bounces@lists.xensource.com> Envelope-to: www-data@lists.xensource.com Delivery-date: Thu, 29 Sep 2011 13:36:22 -0700 Received: from localhost ([127.0.0.1] helo=lists.colo.xensource.com) by lists.xensource.com with esmtp (Exim 4.43) id 1R9NLC-00045y-0K; Thu, 29 Sep 2011 13:36:22 -0700 Received: from mail174.messagelabs.com ([85.158.138.51]) by lists.xensource.com with esmtp (Exim 4.43) id 1R9NJ7-00036n-85 for xen-devel@lists.xensource.com; Thu, 29 Sep 2011 13:34:13 -0700 X-Env-Sender: konrad@oracle.com X-Msg-Ref: server-11.tower-174.messagelabs.com!1317328448!33278054!1 X-Originating-IP: [148.87.113.117] X-StarScan-Version: 6.4.1; banners=-,-,- X-VirusChecked: Checked Received: (qmail 19585 invoked from network); 29 Sep 2011 20:34:10 -0000 Received: from rcsinet15.oracle.com (HELO rcsinet15.oracle.com) (148.87.113.117) by server-11.tower-174.messagelabs.com with DHE-RSA-AES256-SHA encrypted SMTP; 29 Sep 2011 20:34:10 -0000 Received: from acsinet21.oracle.com (acsinet21.oracle.com [141.146.126.237]) by rcsinet15.oracle.com (Switch-3.4.4/Switch-3.4.4) with ESMTP id p8TKY22A032603 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Thu, 29 Sep 2011 20:34:04 GMT Received: from acsmt356.oracle.com (acsmt356.oracle.com [141.146.40.156]) by acsinet21.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id p8TKY29S027204 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 29 Sep 2011 20:34:02 GMT Received: from abhmt117.oracle.com (abhmt117.oracle.com [141.146.116.69]) by acsmt356.oracle.com (8.12.11.20060308/8.12.11) with ESMTP id p8TKXv4H001826; Thu, 29 Sep 2011 15:33:57 -0500 Received: from oracle.com (/207.172.105.198) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Thu, 29 Sep 2011 13:33:56 -0700 Received: by oracle.com (Postfix, from userid 1000) id 4F2121559; Thu, 29 Sep 2011 16:33:54 -0400 (EDT) From: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com> To: linux-kernel@vger.kernel.org, thellstrom@vmware.com, dri-devel@lists.freedesktop.org, bskeggs@redhat.com, j.glisse@redhat.com, thomas@shipmail.org, airlied@redhat.com, airlied@linux.ie, alexdeucher@gmail.com Date: Thu, 29 Sep 2011 16:33:50 -0400 Message-Id: <1317328432-25620-8-git-send-email-konrad.wilk@oracle.com> X-Mailer: git-send-email 1.7.4.1 In-Reply-To: <1317328432-25620-1-git-send-email-konrad.wilk@oracle.com> References: <1317328432-25620-1-git-send-email-konrad.wilk@oracle.com> X-Source-IP: acsinet21.oracle.com [141.146.126.237] X-Auth-Type: Internal IP X-CT-RefId: str=0001.0A090204.4E84D63D.0051:SCFMA922111,ss=1,re=-4.000,fgs=0 Cc: xen-devel@lists.xensource.com, Konrad Rzeszutek Wilk <konrad.wilk@oracle.com> Subject: [Xen-devel] [PATCH 7/9] nouveau/radeon: Set coherent DMA mask X-BeenThere: xen-devel@lists.xensource.com X-Mailman-Version: 2.1.5 Precedence: list List-Id: Xen developer discussion <xen-devel.lists.xensource.com> List-Unsubscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe> List-Post: <mailto:xen-devel@lists.xensource.com> List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help> List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=subscribe> Sender: xen-devel-bounces@lists.xensource.com Errors-To: xen-devel-bounces@lists.xensource.com All the storage devices that use the dmapool set the coherent DMA mask so they can properly use the dmapool. Since the TTM DMA pool code is based on that and dma_alloc_coherent checks the 'coherent_dma_mask' and not 'dma_mask' we want to set it. Signed-off-by: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com> --- drivers/gpu/drm/nouveau/nouveau_mem.c | 5 +++++ drivers/gpu/drm/radeon/radeon_device.c | 6 ++++++ 2 files changed, 11 insertions(+), 0 deletions(-) diff --git a/drivers/gpu/drm/nouveau/nouveau_mem.c b/drivers/gpu/drm/nouveau/nouveau_mem.c index a2d7e35..bb6ccbd 100644 --- a/drivers/gpu/drm/nouveau/nouveau_mem.c +++ b/drivers/gpu/drm/nouveau/nouveau_mem.c @@ -408,6 +408,11 @@ nouveau_mem_vram_init(struct drm_device *dev) if (ret) return ret; + ret = pci_set_consistent_dma_mask(dev->pdev, DMA_BIT_MASK(dma_bits)); + if (ret) { + /* Reset to default value. */ + pci_set_consistent_dma_mask(dev->pdev, DMA_BIT_MASK(32)); + } dev_priv->fb_phys = pci_resource_start(dev->pdev, 1); ret = nouveau_ttm_global_init(dev_priv); diff --git a/drivers/gpu/drm/radeon/radeon_device.c b/drivers/gpu/drm/radeon/radeon_device.c index 7cfaa7e..0c0a970 100644 --- a/drivers/gpu/drm/radeon/radeon_device.c +++ b/drivers/gpu/drm/radeon/radeon_device.c @@ -757,8 +757,14 @@ int radeon_device_init(struct radeon_device *rdev, r = pci_set_dma_mask(rdev->pdev, DMA_BIT_MASK(dma_bits)); if (r) { rdev->need_dma32 = true; + dma_bits = 32; printk(KERN_WARNING "radeon: No suitable DMA available.\n"); } + r = pci_set_consistent_dma_mask(rdev->pdev, DMA_BIT_MASK(dma_bits)); + if (r) { + pci_set_consistent_dma_mask(rdev->pdev, DMA_BIT_MASK(32)); + printk(KERN_WARNING "radeon: No coherent DMA available.\n"); + } /* Registers mapping */ /* TODO: block userspace mapping of io register */ -- 1.7.4.1 _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel From xen-devel-bounces@lists.xensource.com Thu Sep 29 13:37:09 2011 Return-path: <xen-devel-bounces@lists.xensource.com> Envelope-to: www-data@lists.xensource.com Delivery-date: Thu, 29 Sep 2011 13:37:09 -0700 Received: from localhost ([127.0.0.1] helo=lists.colo.xensource.com) by lists.xensource.com with esmtp (Exim 4.43) id 1R9NLx-0004Vh-Cx; Thu, 29 Sep 2011 13:37:09 -0700 Received: from mail182.messagelabs.com ([85.158.139.83]) by lists.xensource.com with esmtp (Exim 4.43) id 1R9NJ7-00036m-5G for xen-devel@lists.xensource.com; Thu, 29 Sep 2011 13:34:13 -0700 X-Env-Sender: konrad@oracle.com X-Msg-Ref: server-13.tower-182.messagelabs.com!1317328448!20129342!1 X-Originating-IP: [148.87.113.117] X-StarScan-Version: 6.4.1; banners=-,-,- X-VirusChecked: Checked Received: (qmail 21460 invoked from network); 29 Sep 2011 20:34:09 -0000 Received: from rcsinet15.oracle.com (HELO rcsinet15.oracle.com) (148.87.113.117) by server-13.tower-182.messagelabs.com with DHE-RSA-AES256-SHA encrypted SMTP; 29 Sep 2011 20:34:09 -0000 Received: from ucsinet24.oracle.com (ucsinet24.oracle.com [156.151.31.67]) by rcsinet15.oracle.com (Switch-3.4.4/Switch-3.4.4) with ESMTP id p8TKY2Jn032598 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Thu, 29 Sep 2011 20:34:04 GMT Received: from acsmt356.oracle.com (acsmt356.oracle.com [141.146.40.156]) by ucsinet24.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id p8TKSJt2029392 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 29 Sep 2011 20:28:19 GMT Received: from abhmt116.oracle.com (abhmt116.oracle.com [141.146.116.68]) by acsmt356.oracle.com (8.12.11.20060308/8.12.11) with ESMTP id p8TKXt0U001807; Thu, 29 Sep 2011 15:33:55 -0500 Received: from oracle.com (/207.172.105.198) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Thu, 29 Sep 2011 13:33:55 -0700 Received: by oracle.com (Postfix, from userid 1000) id 2FEB1154E; Thu, 29 Sep 2011 16:33:54 -0400 (EDT) From: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com> To: linux-kernel@vger.kernel.org, thellstrom@vmware.com, dri-devel@lists.freedesktop.org, bskeggs@redhat.com, j.glisse@redhat.com, thomas@shipmail.org, airlied@redhat.com, airlied@linux.ie, alexdeucher@gmail.com Date: Thu, 29 Sep 2011 16:33:46 -0400 Message-Id: <1317328432-25620-4-git-send-email-konrad.wilk@oracle.com> X-Mailer: git-send-email 1.7.4.1 In-Reply-To: <1317328432-25620-1-git-send-email-konrad.wilk@oracle.com> References: <1317328432-25620-1-git-send-email-konrad.wilk@oracle.com> X-Source-IP: ucsinet24.oracle.com [156.151.31.67] X-CT-RefId: str=0001.0A090208.4E84D63D.0012,ss=1,re=-2.300,fgs=0 Cc: xen-devel@lists.xensource.com, Konrad Rzeszutek Wilk <konrad.wilk@oracle.com> Subject: [Xen-devel] [PATCH 3/9] ttm: Pass in 'struct device' to TTM so it can do DMA API on behalf of device. X-BeenThere: xen-devel@lists.xensource.com X-Mailman-Version: 2.1.5 Precedence: list List-Id: Xen developer discussion <xen-devel.lists.xensource.com> List-Unsubscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe> List-Post: <mailto:xen-devel@lists.xensource.com> List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help> List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=subscribe> Sender: xen-devel-bounces@lists.xensource.com Errors-To: xen-devel-bounces@lists.xensource.com We want to pass in the 'struct device' to the TTM layer so that the TTM DMA pool code (if enabled) can use it. The DMA API code needs the 'struct device' to do the DMA API operations. Signed-off-by: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com> --- drivers/gpu/drm/nouveau/nouveau_mem.c | 3 ++- drivers/gpu/drm/radeon/radeon_ttm.c | 3 ++- drivers/gpu/drm/ttm/ttm_bo.c | 4 +++- drivers/gpu/drm/ttm/ttm_page_alloc.c | 17 ++++++++++------- drivers/gpu/drm/ttm/ttm_tt.c | 5 +++-- drivers/gpu/drm/vmwgfx/vmwgfx_drv.c | 4 ++-- include/drm/ttm/ttm_bo_driver.h | 7 ++++++- include/drm/ttm/ttm_page_alloc.h | 16 ++++++++++++---- 8 files changed, 40 insertions(+), 19 deletions(-) diff --git a/drivers/gpu/drm/nouveau/nouveau_mem.c b/drivers/gpu/drm/nouveau/nouveau_mem.c index 5ee14d2..a2d7e35 100644 --- a/drivers/gpu/drm/nouveau/nouveau_mem.c +++ b/drivers/gpu/drm/nouveau/nouveau_mem.c @@ -417,7 +417,8 @@ nouveau_mem_vram_init(struct drm_device *dev) ret = ttm_bo_device_init(&dev_priv->ttm.bdev, dev_priv->ttm.bo_global_ref.ref.object, &nouveau_bo_driver, DRM_FILE_PAGE_OFFSET, - dma_bits <= 32 ? true : false); + dma_bits <= 32 ? true : false, + dev->dev); if (ret) { NV_ERROR(dev, "Error initialising bo driver: %d\n", ret); return ret; diff --git a/drivers/gpu/drm/radeon/radeon_ttm.c b/drivers/gpu/drm/radeon/radeon_ttm.c index 60125dd..dbc6bcb 100644 --- a/drivers/gpu/drm/radeon/radeon_ttm.c +++ b/drivers/gpu/drm/radeon/radeon_ttm.c @@ -517,7 +517,8 @@ int radeon_ttm_init(struct radeon_device *rdev) r = ttm_bo_device_init(&rdev->mman.bdev, rdev->mman.bo_global_ref.ref.object, &radeon_bo_driver, DRM_FILE_PAGE_OFFSET, - rdev->need_dma32); + rdev->need_dma32, + rdev->dev); if (r) { DRM_ERROR("failed initializing buffer object driver(%d).\n", r); return r; diff --git a/drivers/gpu/drm/ttm/ttm_bo.c b/drivers/gpu/drm/ttm/ttm_bo.c index 2e618b5..0358889 100644 --- a/drivers/gpu/drm/ttm/ttm_bo.c +++ b/drivers/gpu/drm/ttm/ttm_bo.c @@ -1527,12 +1527,14 @@ int ttm_bo_device_init(struct ttm_bo_device *bdev, struct ttm_bo_global *glob, struct ttm_bo_driver *driver, uint64_t file_page_offset, - bool need_dma32) + bool need_dma32, + struct device *dev) { int ret = -EINVAL; rwlock_init(&bdev->vm_lock); bdev->driver = driver; + bdev->dev = dev; memset(bdev->man, 0, sizeof(bdev->man)); diff --git a/drivers/gpu/drm/ttm/ttm_page_alloc.c b/drivers/gpu/drm/ttm/ttm_page_alloc.c index 6a888f8..f9a4d83 100644 --- a/drivers/gpu/drm/ttm/ttm_page_alloc.c +++ b/drivers/gpu/drm/ttm/ttm_page_alloc.c @@ -666,7 +666,7 @@ out: */ int __ttm_get_pages(struct list_head *pages, int flags, enum ttm_caching_state cstate, unsigned count, - dma_addr_t *dma_address) + dma_addr_t *dma_address, struct device *dev) { struct ttm_page_pool *pool = ttm_get_pool(flags, cstate); struct page *p = NULL; @@ -724,7 +724,8 @@ int __ttm_get_pages(struct list_head *pages, int flags, printk(KERN_ERR TTM_PFX "Failed to allocate extra pages " "for large request."); - ttm_put_pages(pages, 0, flags, cstate, NULL); + ttm_put_pages(pages, 0, flags, cstate, dma_address, + dev); return r; } } @@ -735,7 +736,8 @@ int __ttm_get_pages(struct list_head *pages, int flags, /* Put all pages in pages list to correct pool to wait for reuse */ void __ttm_put_pages(struct list_head *pages, unsigned page_count, int flags, - enum ttm_caching_state cstate, dma_addr_t *dma_address) + enum ttm_caching_state cstate, dma_addr_t *dma_address, + struct device *dev) { unsigned long irq_flags; struct ttm_page_pool *pool = ttm_get_pool(flags, cstate); @@ -867,19 +869,20 @@ struct ttm_page_alloc_func ttm_page_alloc_default = { int ttm_get_pages(struct list_head *pages, int flags, enum ttm_caching_state cstate, unsigned count, - dma_addr_t *dma_address) + dma_addr_t *dma_address, struct device *dev) { if (ttm_page_alloc && ttm_page_alloc->get_pages) return ttm_page_alloc->get_pages(pages, flags, cstate, count, - dma_address); + dma_address, dev); return -1; } void ttm_put_pages(struct list_head *pages, unsigned page_count, int flags, - enum ttm_caching_state cstate, dma_addr_t *dma_address) + enum ttm_caching_state cstate, dma_addr_t *dma_address, + struct device *dev) { if (ttm_page_alloc && ttm_page_alloc->put_pages) ttm_page_alloc->put_pages(pages, page_count, flags, cstate, - dma_address); + dma_address, dev); } int ttm_page_alloc_init(struct ttm_mem_global *glob, unsigned max_pages) { diff --git a/drivers/gpu/drm/ttm/ttm_tt.c b/drivers/gpu/drm/ttm/ttm_tt.c index 58c271e..1f11a33 100644 --- a/drivers/gpu/drm/ttm/ttm_tt.c +++ b/drivers/gpu/drm/ttm/ttm_tt.c @@ -111,7 +111,7 @@ static struct page *__ttm_tt_get_page(struct ttm_tt *ttm, int index) INIT_LIST_HEAD(&h); ret = ttm_get_pages(&h, ttm->page_flags, ttm->caching_state, 1, - &ttm->dma_address[index]); + &ttm->dma_address[index], ttm->dev); if (ret != 0) return NULL; @@ -305,7 +305,7 @@ static void ttm_tt_free_alloced_pages(struct ttm_tt *ttm) } } ttm_put_pages(&h, count, ttm->page_flags, ttm->caching_state, - ttm->dma_address); + ttm->dma_address, ttm->dev); ttm->state = tt_unpopulated; ttm->first_himem_page = ttm->num_pages; ttm->last_lomem_page = -1; @@ -398,6 +398,7 @@ struct ttm_tt *ttm_tt_create(struct ttm_bo_device *bdev, unsigned long size, ttm->last_lomem_page = -1; ttm->caching_state = tt_cached; ttm->page_flags = page_flags; + ttm->dev = bdev->dev; ttm->dummy_read_page = dummy_read_page; diff --git a/drivers/gpu/drm/vmwgfx/vmwgfx_drv.c b/drivers/gpu/drm/vmwgfx/vmwgfx_drv.c index 96949b9..d266ae7 100644 --- a/drivers/gpu/drm/vmwgfx/vmwgfx_drv.c +++ b/drivers/gpu/drm/vmwgfx/vmwgfx_drv.c @@ -322,11 +322,11 @@ static int vmw_driver_load(struct drm_device *dev, unsigned long chipset) ttm_lock_set_kill(&dev_priv->fbdev_master.lock, false, SIGTERM); dev_priv->active_master = &dev_priv->fbdev_master; - ret = ttm_bo_device_init(&dev_priv->bdev, dev_priv->bo_global_ref.ref.object, &vmw_bo_driver, VMWGFX_FILE_PAGE_OFFSET, - false); + false, + dev->dev); if (unlikely(ret != 0)) { DRM_ERROR("Failed initializing TTM buffer object driver.\n"); goto out_err1; diff --git a/include/drm/ttm/ttm_bo_driver.h b/include/drm/ttm/ttm_bo_driver.h index 09af2d7..9a7ecae 100644 --- a/include/drm/ttm/ttm_bo_driver.h +++ b/include/drm/ttm/ttm_bo_driver.h @@ -177,6 +177,7 @@ struct ttm_tt { tt_unpopulated, } state; dma_addr_t *dma_address; + struct device *dev; }; #define TTM_MEMTYPE_FLAG_FIXED (1 << 0) /* Fixed (on-card) PCI memory */ @@ -551,6 +552,7 @@ struct ttm_bo_device { struct list_head device_list; struct ttm_bo_global *glob; struct ttm_bo_driver *driver; + struct device *dev; rwlock_t vm_lock; struct ttm_mem_type_manager man[TTM_NUM_MEM_TYPES]; spinlock_t fence_lock; @@ -791,6 +793,8 @@ extern int ttm_bo_device_release(struct ttm_bo_device *bdev); * @file_page_offset: Offset into the device address space that is available * for buffer data. This ensures compatibility with other users of the * address space. + * @need_dma32: Allocate pages under 4GB + * @dev: 'struct device' of the PCI device. * * Initializes a struct ttm_bo_device: * Returns: @@ -799,7 +803,8 @@ extern int ttm_bo_device_release(struct ttm_bo_device *bdev); extern int ttm_bo_device_init(struct ttm_bo_device *bdev, struct ttm_bo_global *glob, struct ttm_bo_driver *driver, - uint64_t file_page_offset, bool need_dma32); + uint64_t file_page_offset, bool need_dma32, + struct device *dev); /** * ttm_bo_unmap_virtual diff --git a/include/drm/ttm/ttm_page_alloc.h b/include/drm/ttm/ttm_page_alloc.h index 6e8d73a..8fc92f2 100644 --- a/include/drm/ttm/ttm_page_alloc.h +++ b/include/drm/ttm/ttm_page_alloc.h @@ -39,12 +39,14 @@ struct ttm_page_alloc_func { * @cstate: ttm caching state for the page. * @count: number of pages to allocate. * @dma_address: The DMA (bus) address of pages (by default zero). + * @dev: The device that needs this. */ int (*get_pages) (struct list_head *pages, int flags, enum ttm_caching_state cstate, unsigned count, - dma_addr_t *dma_address); + dma_addr_t *dma_address, + struct device *dev); /** * struct ttm_page_alloc_func member put_pages. * @@ -56,12 +58,14 @@ struct ttm_page_alloc_func { * @flags: ttm flags for page allocation. * @cstate: ttm caching state. * @dma_address: The DMA (bus) address of pages (by default zero). + * @dev: The device that needs this. */ void (*put_pages)(struct list_head *pages, unsigned page_count, int flags, enum ttm_caching_state cstate, - dma_addr_t *dma_address); + dma_addr_t *dma_address, + struct device *dev); /** * struct ttm_page_alloc_func member alloc_init. * @@ -97,12 +101,14 @@ extern struct ttm_page_alloc_func ttm_page_alloc_default; * @cstate: ttm caching state for the page. * @count: number of pages to allocate. * @dma_address: The DMA (bus) address of pages - (by default zero). + * @dev: The device that needs this. */ int ttm_get_pages(struct list_head *pages, int flags, enum ttm_caching_state cstate, unsigned count, - dma_addr_t *dma_address); + dma_addr_t *dma_address, + struct device *dev); /** * Put linked list of pages to pool. * @@ -112,12 +118,14 @@ int ttm_get_pages(struct list_head *pages, * @flags: ttm flags for page allocation. * @cstate: ttm caching state. * @dma_address: The DMA (bus) address of pages (by default zero). + * @dev: The device that needs this. */ void ttm_put_pages(struct list_head *pages, unsigned page_count, int flags, enum ttm_caching_state cstate, - dma_addr_t *dma_address); + dma_addr_t *dma_address, + struct device *dev); /** * Initialize pool allocator. */ -- 1.7.4.1 _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel From xen-devel-bounces@lists.xensource.com Thu Sep 29 13:37:57 2011 Return-path: <xen-devel-bounces@lists.xensource.com> Envelope-to: www-data@lists.xensource.com Delivery-date: Thu, 29 Sep 2011 13:37:57 -0700 Received: from localhost ([127.0.0.1] helo=lists.colo.xensource.com) by lists.xensource.com with esmtp (Exim 4.43) id 1R9NMj-0004uB-0U; Thu, 29 Sep 2011 13:37:57 -0700 Received: from mail27.messagelabs.com ([193.109.254.147]) by lists.xensource.com with esmtp (Exim 4.43) id 1R9NJ7-00036l-0m for xen-devel@lists.xensource.com; Thu, 29 Sep 2011 13:34:13 -0700 X-Env-Sender: konrad@oracle.com X-Msg-Ref: server-15.tower-27.messagelabs.com!1317328438!48870671!1 X-Originating-IP: [148.87.113.117] X-StarScan-Version: 6.4.1; banners=-,-,- X-VirusChecked: Checked Received: (qmail 2614 invoked from network); 29 Sep 2011 20:34:00 -0000 Received: from rcsinet15.oracle.com (HELO rcsinet15.oracle.com) (148.87.113.117) by server-15.tower-27.messagelabs.com with DHE-RSA-AES256-SHA encrypted SMTP; 29 Sep 2011 20:34:00 -0000 Received: from ucsinet24.oracle.com (ucsinet24.oracle.com [156.151.31.67]) by rcsinet15.oracle.com (Switch-3.4.4/Switch-3.4.4) with ESMTP id p8TKY33a032612 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Thu, 29 Sep 2011 20:34:04 GMT Received: from acsmt356.oracle.com (acsmt356.oracle.com [141.146.40.156]) by ucsinet24.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id p8TKSKFv029403 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 29 Sep 2011 20:28:20 GMT Received: from abhmt116.oracle.com (abhmt116.oracle.com [141.146.116.68]) by acsmt356.oracle.com (8.12.11.20060308/8.12.11) with ESMTP id p8TKXvkl001829; Thu, 29 Sep 2011 15:33:57 -0500 Received: from oracle.com (/207.172.105.198) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Thu, 29 Sep 2011 13:33:57 -0700 Received: by oracle.com (Postfix, from userid 1000) id 62C7C1562; Thu, 29 Sep 2011 16:33:54 -0400 (EDT) From: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com> To: linux-kernel@vger.kernel.org, thellstrom@vmware.com, dri-devel@lists.freedesktop.org, bskeggs@redhat.com, j.glisse@redhat.com, thomas@shipmail.org, airlied@redhat.com, airlied@linux.ie, alexdeucher@gmail.com Date: Thu, 29 Sep 2011 16:33:52 -0400 Message-Id: <1317328432-25620-10-git-send-email-konrad.wilk@oracle.com> X-Mailer: git-send-email 1.7.4.1 In-Reply-To: <1317328432-25620-1-git-send-email-konrad.wilk@oracle.com> References: <1317328432-25620-1-git-send-email-konrad.wilk@oracle.com> X-Source-IP: ucsinet24.oracle.com [156.151.31.67] X-CT-RefId: str=0001.0A090208.4E84D63D.007B,ss=1,re=0.000,fgs=0 Cc: xen-devel@lists.xensource.com, Konrad Rzeszutek Wilk <konrad.wilk@oracle.com> Subject: [Xen-devel] [PATCH 9/9] ttm/dma: Implement set_page_caching implementation in the TTM DMA pool code. X-BeenThere: xen-devel@lists.xensource.com X-Mailman-Version: 2.1.5 Precedence: list List-Id: Xen developer discussion <xen-devel.lists.xensource.com> List-Unsubscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe> List-Post: <mailto:xen-devel@lists.xensource.com> List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help> List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=subscribe> Sender: xen-devel-bounces@lists.xensource.com Errors-To: xen-devel-bounces@lists.xensource.com . which is pretty much like the other TTM pool except it also handles moving the page to another pool list. Signed-off-by: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com> --- drivers/gpu/drm/ttm/ttm_page_alloc_dma.c | 96 ++++++++++++++++++++++++++++++ 1 files changed, 96 insertions(+), 0 deletions(-) diff --git a/drivers/gpu/drm/ttm/ttm_page_alloc_dma.c b/drivers/gpu/drm/ttm/ttm_page_alloc_dma.c index 5909d28..cea031e 100644 --- a/drivers/gpu/drm/ttm/ttm_page_alloc_dma.c +++ b/drivers/gpu/drm/ttm/ttm_page_alloc_dma.c @@ -1307,11 +1307,107 @@ static int ttm_dma_page_alloc_debugfs(struct seq_file *m, void *data) mutex_unlock(&_manager->lock); return 0; } +#ifdef CONFIG_X86 +static int ttm_dma_page_set_page_caching(struct page *p, + int flags, + enum ttm_caching_state c_old, + enum ttm_caching_state c_new, + struct device *dev) +{ + struct dma_pool *src, *dst; + enum pool_type type; + struct dma_page *dma_p; + bool found = false; + unsigned long irq_flags; + int ret = 0; + + if (!p) + return 0; + + if (PageHighMem(p)) + return 0; + + type = ttm_to_type(flags, c_old); + src = ttm_dma_find_pool(dev, type); + if (!src) { + WARN_ON(!src); + return -ENOMEM; + } + type = ttm_to_type(flags, c_new); + dst = ttm_dma_find_pool(dev, type); + if (!dst) { + gfp_t gfp_flags; + if (flags & TTM_PAGE_FLAG_DMA32) + gfp_flags = GFP_USER | GFP_DMA32; + else + gfp_flags = GFP_HIGHUSER; + + if (flags & TTM_PAGE_FLAG_ZERO_ALLOC) + gfp_flags |= __GFP_ZERO; + + dst = ttm_dma_pool_init(dev, gfp_flags, type); + if (IS_ERR_OR_NULL(dst)) + return -ENOMEM; + } + + dev_dbg(dev, "(%d) Caching %p (%p) from %x to %x.\n", current->pid, + p, page_address(p), c_old, c_new); + + if (c_old != tt_cached) { + /* p isn't in the default caching state, set it to + * writeback first to free its current memtype. */ + + ret = set_pages_wb(p, 1); + if (ret) + return ret; + } + if (c_new == tt_wc) + ret = set_memory_wc((unsigned long) page_address(p), 1); + else if (c_new == tt_uncached) + ret = set_pages_uc(p, 1); + + if (ret) + return ret; + + dev_dbg(src->dev, "(%s:%d) Moving %p (%p) to %s.\n", src->name, + current->pid, p, page_address(p), dst->name); + + /* To make it faster we only take the spinlock on list + * removal, and later on adding the page to the destination pool. */ + spin_lock_irqsave(&src->lock, irq_flags); + list_for_each_entry(dma_p, &src->page_list, page_list) { + if (virt_to_page(dma_p->vaddr) != p) { + pr_debug("%s: (%s:%d) Skipping %p (%p) (DMA:0x%lx)\n", + src->dev_name, src->name, current->pid, + dma_p->vaddr, + virt_to_page(dma_p->vaddr), + (unsigned long)dma_p->dma); + continue; + } + list_del(&dma_p->page_list); + src->npages_in_use -= 1; + found = true; + break; + } + spin_lock_irqsave(&src->lock, irq_flags); + if (!found) + return -ENODEV; + + spin_lock_irqsave(&dst->lock, irq_flags); + list_add(&dma_p->page_list, &dst->page_list); + dst->npages_in_use++; + spin_unlock_irqrestore(&dst->lock, irq_flags); + return 0; +}; +#endif struct ttm_page_alloc_func ttm_page_alloc_dma = { .get_pages = ttm_dma_get_pages, .put_pages = ttm_dma_put_pages, .alloc_init = ttm_dma_page_alloc_init, .alloc_fini = ttm_dma_page_alloc_fini, .debugfs = ttm_dma_page_alloc_debugfs, +#ifdef CONFIG_X86 + .set_caching = ttm_dma_page_set_page_caching, +#endif }; -- 1.7.4.1 _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel From xen-devel-bounces@lists.xensource.com Thu Sep 29 13:38:49 2011 Return-path: <xen-devel-bounces@lists.xensource.com> Envelope-to: www-data@lists.xensource.com Delivery-date: Thu, 29 Sep 2011 13:38:49 -0700 Received: from localhost ([127.0.0.1] helo=lists.colo.xensource.com) by lists.xensource.com with esmtp (Exim 4.43) id 1R9NNZ-0005HH-MH; Thu, 29 Sep 2011 13:38:49 -0700 Received: from mail27.messagelabs.com ([193.109.254.147]) by lists.xensource.com with esmtp (Exim 4.43) id 1R9NJ7-00036o-BY for xen-devel@lists.xensource.com; Thu, 29 Sep 2011 13:34:13 -0700 X-Env-Sender: konrad@oracle.com X-Msg-Ref: server-3.tower-27.messagelabs.com!1317328424!39746199!1 X-Originating-IP: [141.146.126.227] X-StarScan-Version: 6.4.1; banners=-,-,- X-VirusChecked: Checked Received: (qmail 9889 invoked from network); 29 Sep 2011 20:33:45 -0000 Received: from acsinet15.oracle.com (HELO acsinet15.oracle.com) (141.146.126.227) by server-3.tower-27.messagelabs.com with DHE-RSA-AES256-SHA encrypted SMTP; 29 Sep 2011 20:33:45 -0000 Received: from ucsinet23.oracle.com (ucsinet23.oracle.com [156.151.31.71]) by acsinet15.oracle.com (Switch-3.4.4/Switch-3.4.4) with ESMTP id p8TKY3EX000898 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Thu, 29 Sep 2011 20:34:05 GMT Received: from acsmt358.oracle.com (acsmt358.oracle.com [141.146.40.158]) by ucsinet23.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id p8TKY2r9021672 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 29 Sep 2011 20:34:03 GMT Received: from abhmt105.oracle.com (abhmt105.oracle.com [141.146.116.57]) by acsmt358.oracle.com (8.12.11.20060308/8.12.11) with ESMTP id p8TKXvFa019335; Thu, 29 Sep 2011 15:33:57 -0500 Received: from oracle.com (/207.172.105.198) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Thu, 29 Sep 2011 13:33:56 -0700 Received: by oracle.com (Postfix, from userid 1000) id 58F1D155D; Thu, 29 Sep 2011 16:33:54 -0400 (EDT) From: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com> To: linux-kernel@vger.kernel.org, thellstrom@vmware.com, dri-devel@lists.freedesktop.org, bskeggs@redhat.com, j.glisse@redhat.com, thomas@shipmail.org, airlied@redhat.com, airlied@linux.ie, alexdeucher@gmail.com Date: Thu, 29 Sep 2011 16:33:51 -0400 Message-Id: <1317328432-25620-9-git-send-email-konrad.wilk@oracle.com> X-Mailer: git-send-email 1.7.4.1 In-Reply-To: <1317328432-25620-1-git-send-email-konrad.wilk@oracle.com> References: <1317328432-25620-1-git-send-email-konrad.wilk@oracle.com> X-Source-IP: ucsinet23.oracle.com [156.151.31.71] X-CT-RefId: str=0001.0A090203.4E84D63E.0084,ss=1,re=0.000,fgs=0 Cc: xen-devel@lists.xensource.com, Konrad Rzeszutek Wilk <konrad.wilk@oracle.com> Subject: [Xen-devel] [PATCH 8/9] ttm/tt: Move ttm_tt_set_page_caching implementation in TTM page pool code. X-BeenThere: xen-devel@lists.xensource.com X-Mailman-Version: 2.1.5 Precedence: list List-Id: Xen developer discussion <xen-devel.lists.xensource.com> List-Unsubscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe> List-Post: <mailto:xen-devel@lists.xensource.com> List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help> List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=subscribe> Sender: xen-devel-bounces@lists.xensource.com Errors-To: xen-devel-bounces@lists.xensource.com . and provide in the function callback a method to register with the backend a new (*set_caching). Signed-off-by: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com> --- drivers/gpu/drm/ttm/ttm_page_alloc.c | 46 ++++++++++++++++++++++++++++++++++ drivers/gpu/drm/ttm/ttm_tt.c | 46 +++++---------------------------- include/drm/ttm/ttm_page_alloc.h | 29 +++++++++++++++++++++ 3 files changed, 82 insertions(+), 39 deletions(-) diff --git a/drivers/gpu/drm/ttm/ttm_page_alloc.c b/drivers/gpu/drm/ttm/ttm_page_alloc.c index f9a4d83..002f64f 100644 --- a/drivers/gpu/drm/ttm/ttm_page_alloc.c +++ b/drivers/gpu/drm/ttm/ttm_page_alloc.c @@ -455,6 +455,36 @@ static int ttm_set_pages_caching(struct page **pages, return r; } +#ifdef CONFIG_X86 +static int __ttm_page_set_page_caching(struct page *p, + int flags, + enum ttm_caching_state c_old, + enum ttm_caching_state c_new, + struct device *dev) +{ + int ret = 0; + + if (PageHighMem(p)) + return 0; + + if (c_old != tt_cached) { + /* p isn't in the default caching state, set it to + * writeback first to free its current memtype. */ + + ret = set_pages_wb(p, 1); + if (ret) + return ret; + } + + if (c_new == tt_wc) + ret = set_memory_wc((unsigned long) page_address(p), 1); + else if (c_new == tt_uncached) + ret = set_pages_uc(p, 1); + + return ret; +} +#endif + /** * Free pages the pages that failed to change the caching state. If there is * any pages that have changed their caching state already put them to the @@ -865,6 +895,9 @@ struct ttm_page_alloc_func ttm_page_alloc_default = { .alloc_init = __ttm_page_alloc_init, .alloc_fini = __ttm_page_alloc_fini, .debugfs = __ttm_page_alloc_debugfs, +#ifdef CONFIG_X86 + .set_caching = __ttm_page_set_page_caching, +#endif }; int ttm_get_pages(struct list_head *pages, int flags, @@ -902,3 +935,16 @@ int ttm_page_alloc_debugfs(struct seq_file *m, void *data) return -1; } EXPORT_SYMBOL(ttm_page_alloc_debugfs); + +#ifdef CONFIG_X86 +int ttm_tt_set_page_caching(struct page *p, + int flags, + enum ttm_caching_state c_old, + enum ttm_caching_state c_new, + struct device *dev) +{ + if (ttm_page_alloc && ttm_page_alloc->set_caching) + return ttm_page_alloc->set_caching(p, flags, c_old, c_new, dev); + return -1; +} +#endif diff --git a/drivers/gpu/drm/ttm/ttm_tt.c b/drivers/gpu/drm/ttm/ttm_tt.c index 1f11a33..0f5ce97 100644 --- a/drivers/gpu/drm/ttm/ttm_tt.c +++ b/drivers/gpu/drm/ttm/ttm_tt.c @@ -176,41 +176,6 @@ int ttm_tt_populate(struct ttm_tt *ttm) } EXPORT_SYMBOL(ttm_tt_populate); -#ifdef CONFIG_X86 -static inline int ttm_tt_set_page_caching(struct page *p, - enum ttm_caching_state c_old, - enum ttm_caching_state c_new) -{ - int ret = 0; - - if (PageHighMem(p)) - return 0; - - if (c_old != tt_cached) { - /* p isn't in the default caching state, set it to - * writeback first to free its current memtype. */ - - ret = set_pages_wb(p, 1); - if (ret) - return ret; - } - - if (c_new == tt_wc) - ret = set_memory_wc((unsigned long) page_address(p), 1); - else if (c_new == tt_uncached) - ret = set_pages_uc(p, 1); - - return ret; -} -#else /* CONFIG_X86 */ -static inline int ttm_tt_set_page_caching(struct page *p, - enum ttm_caching_state c_old, - enum ttm_caching_state c_new) -{ - return 0; -} -#endif /* CONFIG_X86 */ - /* * Change caching policy for the linear kernel map * for range of pages in a ttm. @@ -238,9 +203,9 @@ static int ttm_tt_set_caching(struct ttm_tt *ttm, for (i = 0; i < ttm->num_pages; ++i) { cur_page = ttm->pages[i]; if (likely(cur_page != NULL)) { - ret = ttm_tt_set_page_caching(cur_page, + ret = ttm_tt_set_page_caching(cur_page, ttm->page_flags, ttm->caching_state, - c_state); + c_state, ttm->dev); if (unlikely(ret != 0)) goto out_err; } @@ -254,8 +219,11 @@ out_err: for (j = 0; j < i; ++j) { cur_page = ttm->pages[j]; if (likely(cur_page != NULL)) { - (void)ttm_tt_set_page_caching(cur_page, c_state, - ttm->caching_state); + (void)ttm_tt_set_page_caching(cur_page, + ttm->page_flags, + c_state, + ttm->caching_state, + ttm->dev); } } diff --git a/include/drm/ttm/ttm_page_alloc.h b/include/drm/ttm/ttm_page_alloc.h index 1dde3bd..73ad03c 100644 --- a/include/drm/ttm/ttm_page_alloc.h +++ b/include/drm/ttm/ttm_page_alloc.h @@ -93,6 +93,18 @@ struct ttm_page_alloc_func { * Output the state of pools to debugfs file */ int (*debugfs)(struct seq_file *m, void *data); + + /** + * + * struct ttm_page_alloc_func member set_caching + * + * Set the caching on the page retrieved from get_pages. + */ + int (*set_caching)(struct page *p, + int flags, + enum ttm_caching_state c_old, + enum ttm_caching_state c_new, + struct device *dev); }; extern struct ttm_page_alloc_func *ttm_page_alloc; @@ -163,4 +175,21 @@ void ttm_page_alloc_fini(void); * Output the state of pools to debugfs file */ extern int ttm_page_alloc_debugfs(struct seq_file *m, void *data); + +#ifdef CONFIG_X86 +int ttm_tt_set_page_caching(struct page *p, + int flags, + enum ttm_caching_state c_old, + enum ttm_caching_state c_new, + struct device *dev); +#else +static inline int ttm_tt_set_page_caching(struct page *p, + int flags, + enum ttm_caching_state c_old, + enum ttm_caching_state c_new, + struct device *dev) +{ + return 0; +} +#endif #endif -- 1.7.4.1 _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel From xen-devel-bounces@lists.xensource.com Thu Sep 29 13:39:39 2011 Return-path: <xen-devel-bounces@lists.xensource.com> Envelope-to: www-data@lists.xensource.com Delivery-date: Thu, 29 Sep 2011 13:39:39 -0700 Received: from localhost ([127.0.0.1] helo=lists.colo.xensource.com) by lists.xensource.com with esmtp (Exim 4.43) id 1R9NON-0005eC-3S; Thu, 29 Sep 2011 13:39:39 -0700 Received: from mail21.messagelabs.com ([85.158.143.35]) by lists.xensource.com with esmtp (Exim 4.43) id 1R9NJ8-00036p-22 for xen-devel@lists.xensource.com; Thu, 29 Sep 2011 13:34:14 -0700 X-Env-Sender: konrad@oracle.com X-Msg-Ref: server-8.tower-21.messagelabs.com!1317328432!60907238!1 X-Originating-IP: [148.87.113.117] X-StarScan-Version: 6.4.1; banners=-,-,- X-VirusChecked: Checked Received: (qmail 25007 invoked from network); 29 Sep 2011 20:33:54 -0000 Received: from rcsinet15.oracle.com (HELO rcsinet15.oracle.com) (148.87.113.117) by server-8.tower-21.messagelabs.com with DHE-RSA-AES256-SHA encrypted SMTP; 29 Sep 2011 20:33:54 -0000 Received: from rtcsinet22.oracle.com (rtcsinet22.oracle.com [66.248.204.30]) by rcsinet15.oracle.com (Switch-3.4.4/Switch-3.4.4) with ESMTP id p8TKY40S032632 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Thu, 29 Sep 2011 20:34:06 GMT Received: from acsmt358.oracle.com (acsmt358.oracle.com [141.146.40.158]) by rtcsinet22.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id p8TKY1cA017030 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 29 Sep 2011 20:34:02 GMT Received: from abhmt110.oracle.com (abhmt110.oracle.com [141.146.116.62]) by acsmt358.oracle.com (8.12.11.20060308/8.12.11) with ESMTP id p8TKXtKD019214; Thu, 29 Sep 2011 15:33:55 -0500 Received: from oracle.com (/207.172.105.198) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Thu, 29 Sep 2011 13:33:55 -0700 Received: by oracle.com (Postfix, from userid 1000) id 16EAE154A; Thu, 29 Sep 2011 16:33:54 -0400 (EDT) From: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com> To: linux-kernel@vger.kernel.org, thellstrom@vmware.com, dri-devel@lists.freedesktop.org, bskeggs@redhat.com, j.glisse@redhat.com, thomas@shipmail.org, airlied@redhat.com, airlied@linux.ie, alexdeucher@gmail.com Date: Thu, 29 Sep 2011 16:33:43 -0400 Message-Id: <1317328432-25620-1-git-send-email-konrad.wilk@oracle.com> X-Mailer: git-send-email 1.7.4.1 X-Source-IP: rtcsinet22.oracle.com [66.248.204.30] X-CT-RefId: str=0001.0A090204.4E84D63F.003E,ss=1,re=0.000,fgs=0 Cc: xen-devel@lists.xensource.com Subject: [Xen-devel] [PATCH] TTM DMA pool v1.8 X-BeenThere: xen-devel@lists.xensource.com X-Mailman-Version: 2.1.5 Precedence: list List-Id: Xen developer discussion <xen-devel.lists.xensource.com> List-Unsubscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe> List-Post: <mailto:xen-devel@lists.xensource.com> List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help> List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=subscribe> Sender: xen-devel-bounces@lists.xensource.com Errors-To: xen-devel-bounces@lists.xensource.com [.. and this is what I said in v1 post]: Way back in January this patchset: http://lists.freedesktop.org/archives/dri-devel/2011-January/006905.html was merged in, but pieces of it had to be reverted b/c they did not work properly under PowerPC, ARM, and when swapping out pages to disk. After a bit of discussion on the mailing list http://marc.info/?i=4D769726.2030307@shipmail.org I started working on it, but got waylaid by other things .. and finally I am able to post the RFC patches. There was a lot of discussion about it and I am not sure if I captured everybody's thoughts - if I did not - that is _not_ intentional - it has just been quite some time.. Anyhow .. the patches explore what the "lib/dmapool.c" does - which is to have a DMA pool that the device has associated with. I kind of married that code along with drivers/gpu/drm/ttm/ttm_page_alloc.c to create a TTM DMA pool code. The end result is DMA pool with extra features: can do write-combine, uncached, writeback (and tracks them and sets back to WB when freed); tracks "cached" pages that don't really need to be returned to a pool; and hooks up to the shrinker code so that the pools can be shrunk. If you guys think this set of patches make sense - my future plans were 1) Get this in large crowd of testing .. and if it works for a kernel release 2) to move a bulk of this in the lib/dmapool.c (I spoke with Matthew Wilcox about it and he is OK as long as I don't introduce performance regressions). But before I do any of that a second set of eyes taking a look at these patches would be most welcome. In regards to testing, I've been running them non-stop for the last month (and found some issues which I've fixed up) - and been quite happy with how they work. Michel (thanks!) took a spin of the patches on his PowerPC and they did not cause any regressions (wheew). The patches are also located in a git tree: git://oss.oracle.com/git/kwilk/xen.git devel/ttm.dma_pool.v1.8 drivers/gpu/drm/nouveau/nouveau_mem.c | 8 +- drivers/gpu/drm/nouveau/nouveau_sgdma.c | 3 +- drivers/gpu/drm/radeon/radeon_device.c | 6 + drivers/gpu/drm/radeon/radeon_gart.c | 4 +- drivers/gpu/drm/radeon/radeon_ttm.c | 3 +- drivers/gpu/drm/ttm/Makefile | 3 + drivers/gpu/drm/ttm/ttm_bo.c | 4 +- drivers/gpu/drm/ttm/ttm_memory.c | 5 + drivers/gpu/drm/ttm/ttm_page_alloc.c | 63 ++- drivers/gpu/drm/ttm/ttm_page_alloc_dma.c | 1317 ++++++++++++++++++++++++++++++ drivers/gpu/drm/ttm/ttm_tt.c | 5 +- drivers/gpu/drm/vmwgfx/vmwgfx_drv.c | 4 +- drivers/xen/swiotlb-xen.c | 2 +- include/drm/ttm/ttm_bo_driver.h | 7 +- include/drm/ttm/ttm_page_alloc.h | 100 +++- include/linux/swiotlb.h | 7 +- lib/swiotlb.c | 5 +- 17 files changed, 1516 insertions(+), 30 deletions(-) _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel From xen-devel-bounces@lists.xensource.com Thu Sep 29 13:40:38 2011 Return-path: <xen-devel-bounces@lists.xensource.com> Envelope-to: www-data@lists.xensource.com Delivery-date: Thu, 29 Sep 2011 13:40:38 -0700 Received: from localhost ([127.0.0.1] helo=lists.colo.xensource.com) by lists.xensource.com with esmtp (Exim 4.43) id 1R9NPK-00066D-4c; Thu, 29 Sep 2011 13:40:38 -0700 Received: from mail174.messagelabs.com ([85.158.138.51]) by lists.xensource.com with esmtp (Exim 4.43) id 1R9NJ8-00036q-Db for xen-devel@lists.xensource.com; Thu, 29 Sep 2011 13:34:14 -0700 X-Env-Sender: konrad@oracle.com X-Msg-Ref: server-2.tower-174.messagelabs.com!1317328449!33293304!1 X-Originating-IP: [141.146.126.227] X-StarScan-Version: 6.4.1; banners=-,-,- X-VirusChecked: Checked Received: (qmail 20235 invoked from network); 29 Sep 2011 20:34:11 -0000 Received: from acsinet15.oracle.com (HELO acsinet15.oracle.com) (141.146.126.227) by server-2.tower-174.messagelabs.com with DHE-RSA-AES256-SHA encrypted SMTP; 29 Sep 2011 20:34:11 -0000 Received: from rtcsinet22.oracle.com (rtcsinet22.oracle.com [66.248.204.30]) by acsinet15.oracle.com (Switch-3.4.4/Switch-3.4.4) with ESMTP id p8TKY4SE000905 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Thu, 29 Sep 2011 20:34:06 GMT Received: from acsmt358.oracle.com (acsmt358.oracle.com [141.146.40.158]) by rtcsinet22.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id p8TKY25R017066 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 29 Sep 2011 20:34:03 GMT Received: from abhmt112.oracle.com (abhmt112.oracle.com [141.146.116.64]) by acsmt358.oracle.com (8.12.11.20060308/8.12.11) with ESMTP id p8TKXuO0019334; Thu, 29 Sep 2011 15:33:57 -0500 Received: from oracle.com (/207.172.105.198) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Thu, 29 Sep 2011 13:33:56 -0700 Received: by oracle.com (Postfix, from userid 1000) id 4878C1556; Thu, 29 Sep 2011 16:33:54 -0400 (EDT) From: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com> To: linux-kernel@vger.kernel.org, thellstrom@vmware.com, dri-devel@lists.freedesktop.org, bskeggs@redhat.com, j.glisse@redhat.com, thomas@shipmail.org, airlied@redhat.com, airlied@linux.ie, alexdeucher@gmail.com Date: Thu, 29 Sep 2011 16:33:49 -0400 Message-Id: <1317328432-25620-7-git-send-email-konrad.wilk@oracle.com> X-Mailer: git-send-email 1.7.4.1 In-Reply-To: <1317328432-25620-1-git-send-email-konrad.wilk@oracle.com> References: <1317328432-25620-1-git-send-email-konrad.wilk@oracle.com> X-Source-IP: rtcsinet22.oracle.com [66.248.204.30] X-CT-RefId: str=0001.0A090206.4E84D63F.007B,ss=1,re=0.000,fgs=0 Cc: xen-devel@lists.xensource.com, Konrad Rzeszutek Wilk <konrad.wilk@oracle.com> Subject: [Xen-devel] [PATCH 6/9] ttm: Add 'no_dma' parameter to turn the TTM DMA pool off during runtime. X-BeenThere: xen-devel@lists.xensource.com X-Mailman-Version: 2.1.5 Precedence: list List-Id: Xen developer discussion <xen-devel.lists.xensource.com> List-Unsubscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe> List-Post: <mailto:xen-devel@lists.xensource.com> List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help> List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=subscribe> Sender: xen-devel-bounces@lists.xensource.com Errors-To: xen-devel-bounces@lists.xensource.com The TTM DMA only gets turned on when the SWIOTLB is enabled - but we might also want to turn it off when SWIOTLB is on to use the non-DMA TTM pool code. In the future this parameter can be removed. Signed-off-by: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com> --- drivers/gpu/drm/ttm/ttm_page_alloc_dma.c | 4 ++++ include/drm/ttm/ttm_page_alloc.h | 4 ++-- 2 files changed, 6 insertions(+), 2 deletions(-) diff --git a/drivers/gpu/drm/ttm/ttm_page_alloc_dma.c b/drivers/gpu/drm/ttm/ttm_page_alloc_dma.c index 5a5739c..5909d28 100644 --- a/drivers/gpu/drm/ttm/ttm_page_alloc_dma.c +++ b/drivers/gpu/drm/ttm/ttm_page_alloc_dma.c @@ -51,6 +51,10 @@ #include <asm/agp.h> #endif +int __read_mostly dma_ttm_disable; +MODULE_PARM_DESC(no_dma, "Disable TTM DMA pool"); +module_param_named(no_dma, dma_ttm_disable, bool, S_IRUGO); + #define NUM_PAGES_TO_ALLOC (PAGE_SIZE/sizeof(struct page *)) #define SMALL_ALLOCATION 16 #define FREE_ALL_PAGES (~0U) diff --git a/include/drm/ttm/ttm_page_alloc.h b/include/drm/ttm/ttm_page_alloc.h index a58331d..1dde3bd 100644 --- a/include/drm/ttm/ttm_page_alloc.h +++ b/include/drm/ttm/ttm_page_alloc.h @@ -103,10 +103,10 @@ extern struct ttm_page_alloc_func ttm_page_alloc_default; #ifdef CONFIG_SWIOTLB /* Defined in ttm_page_alloc_dma.c */ extern struct ttm_page_alloc_func ttm_page_alloc_dma; - +extern int dma_ttm_disable; static inline bool ttm_page_alloc_need_dma(void) { - if (swiotlb_nr_tbl()) { + if (!dma_ttm_disable && swiotlb_nr_tbl()) { ttm_page_alloc = &ttm_page_alloc_dma; return true; } -- 1.7.4.1 _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel From xen-devel-bounces@lists.xensource.com Thu Sep 29 13:41:31 2011 Return-path: <xen-devel-bounces@lists.xensource.com> Envelope-to: www-data@lists.xensource.com Delivery-date: Thu, 29 Sep 2011 13:41:31 -0700 Received: from localhost ([127.0.0.1] helo=lists.colo.xensource.com) by lists.xensource.com with esmtp (Exim 4.43) id 1R9NQB-0006Ug-FL; Thu, 29 Sep 2011 13:41:31 -0700 Received: from mail182.messagelabs.com ([85.158.139.83]) by lists.xensource.com with esmtp (Exim 4.43) id 1R9NJ8-00036r-Hc for xen-devel@lists.xensource.com; Thu, 29 Sep 2011 13:34:16 -0700 X-Env-Sender: konrad@oracle.com X-Msg-Ref: server-11.tower-182.messagelabs.com!1317328449!18475209!1 X-Originating-IP: [141.146.126.227] X-StarScan-Version: 6.4.1; banners=-,-,- X-VirusChecked: Checked Received: (qmail 32046 invoked from network); 29 Sep 2011 20:34:11 -0000 Received: from acsinet15.oracle.com (HELO acsinet15.oracle.com) (141.146.126.227) by server-11.tower-182.messagelabs.com with DHE-RSA-AES256-SHA encrypted SMTP; 29 Sep 2011 20:34:11 -0000 Received: from acsinet21.oracle.com (acsinet21.oracle.com [141.146.126.237]) by acsinet15.oracle.com (Switch-3.4.4/Switch-3.4.4) with ESMTP id p8TKY4IQ000902 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Thu, 29 Sep 2011 20:34:06 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 p8TKY3l4027225 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 29 Sep 2011 20:34:03 GMT Received: from abhmt115.oracle.com (abhmt115.oracle.com [141.146.116.67]) by acsmt358.oracle.com (8.12.11.20060308/8.12.11) with ESMTP id p8TKXvXT019336; Thu, 29 Sep 2011 15:33:57 -0500 Received: from oracle.com (/207.172.105.198) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Thu, 29 Sep 2011 13:33:56 -0700 Received: by oracle.com (Postfix, from userid 1000) id 402691555; Thu, 29 Sep 2011 16:33:54 -0400 (EDT) From: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com> To: linux-kernel@vger.kernel.org, thellstrom@vmware.com, dri-devel@lists.freedesktop.org, bskeggs@redhat.com, j.glisse@redhat.com, thomas@shipmail.org, airlied@redhat.com, airlied@linux.ie, alexdeucher@gmail.com Date: Thu, 29 Sep 2011 16:33:48 -0400 Message-Id: <1317328432-25620-6-git-send-email-konrad.wilk@oracle.com> X-Mailer: git-send-email 1.7.4.1 In-Reply-To: <1317328432-25620-1-git-send-email-konrad.wilk@oracle.com> References: <1317328432-25620-1-git-send-email-konrad.wilk@oracle.com> MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable X-Source-IP: acsinet21.oracle.com [141.146.126.237] X-Auth-Type: Internal IP X-CT-RefId: str=0001.0A090206.4E84D63E.0192:SCFMA922111,ss=1,re=-6.601,fgs=0 Cc: xen-devel@lists.xensource.com, Konrad Rzeszutek Wilk <konrad.wilk@oracle.com> Subject: [Xen-devel] [PATCH 5/9] ttm: Provide a DMA aware TTM page pool code. X-BeenThere: xen-devel@lists.xensource.com X-Mailman-Version: 2.1.5 Precedence: list List-Id: Xen developer discussion <xen-devel.lists.xensource.com> List-Unsubscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe> List-Post: <mailto:xen-devel@lists.xensource.com> List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help> List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=subscribe> Sender: xen-devel-bounces@lists.xensource.com Errors-To: xen-devel-bounces@lists.xensource.com In TTM world the pages for the graphic drivers are kept in three differen= t pools: write combined, uncached, and cached (write-back). When the pages are used by the graphic driver the graphic adapter via its built in MMU (or AGP) programs these pages in. The programming requires the virtual ad= dress (from the graphic adapter perspective) and the physical address (either S= ystem RAM or the memory on the card) which is obtained using the pci_map_* calls (w= hich does the virtual to physical - or bus address translation). During the graphic app= lication's "life" those pages can be shuffled around, swapped out to disk, moved fro= m the VRAM to System RAM or vice-versa. This all works with the existing TTM po= ol code - except when we want to use the software IOTLB (SWIOTLB) code to "map" t= he physical addresses to the graphic adapter MMU. We end up programming the bounce bu= ffer's physical address instead of the TTM pool memory's and get a non-worky dri= ver. There are two solutions: 1) using the DMA API to allocate pages that are screened by the DMA API, = or 2) using the pci_sync_* calls to copy the pages from the bounce-buffer an= d back. This patch fixes the issue by allocating pages using the DMA API. The sec= ond is a viable option - but it has performance drawbacks and potential corre= ctness issues - think of the write cache page being bounced (SWIOTLB->TTM), the WC is set on the TTM page and the copy from SWIOTLB not making it to the = TTM page until the page has been recycled in the pool (and used by another ap= plication). The bounce buffer does not get activated often - only in cases where we h= ave a 32-bit capable card and we want to use a page that is allocated above t= he 4GB limit. The bounce buffer offers the solution of copying the contents of that 4GB page to an location below 4GB and then back when the operatio= n has been completed (or vice-versa). This is done by using the 'pci_sync_*' calls. Note: If you look carefully enough in the existing TTM page pool code you= will notice the GFP_DMA32 flag is used - which should guarantee that the prov= ided page is under 4GB. It certainly is the case, except this gets ignored in two c= ases: - If user specifies 'swiotlb=3Dforce' which bounces _every_ page. - If user is using a Xen's PV Linux guest (which uses the SWIOTLB and th= e underlaying PFN's aren't necessarily under 4GB). To not have this extra copying done the other option is to allocate the p= ages using the DMA API so that there is not need to map the page and perform t= he expensive 'pci_sync_*' calls. This DMA API capable TTM pool requires for this the 'struct device' to properly call the DMA API. It also has to track the virtual and bus addre= ss of the page being handed out in case it ends up being swapped out or de-allo= cated - to make sure it is de-allocated using the proper's 'struct device'. Implementation wise the code keeps two lists: one that is attached to the 'struct device' (via the dev->dma_pools list) and a global one to be used= when the 'struct device' is unavailable (think shrinker code). The global list= can iterate over all of the 'struct device' and its associated dma_pool. The = list in dev->dma_pools can only iterate the device's dma_pool. /[struct devi= ce_pool]\ /---------------------------------------------------| dev = | / +-------| dma_pool = | /-----+------\ / \------------= --------/ |struct device| /-->[struct dma_pool for WC]</ /[struct devi= ce_pool]\ | dma_pools +----+ /-| dev = | | ... | \--->[struct dma_pool for uncached]<-/--| dma_pool = | \-----+------/ / \------------= --------/ \----------------------------------------------/ [Two pools associated with the device (WC and UC), and the parallel list containing the 'struct dev' and 'struct dma_pool' entries] The maximum amount of dma pools a device can have is six: write-combined, uncached, and cached; then there are the DMA32 variants which are: write-combined dma32, uncached dma32, and cached dma32. Currently this code only gets activated when any variant of the SWIOTLB I= OMMU code is running (Intel without VT-d, AMD without GART, IBM Calgary and Xe= n PV with PCI devices). Tested-by: Michel D=C3=A4nzer <michel@daenzer.net> [v1: Using swiotlb_nr_tbl instead of swiotlb_enabled] Signed-off-by: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com> --- drivers/gpu/drm/ttm/Makefile | 3 + drivers/gpu/drm/ttm/ttm_memory.c | 2 + drivers/gpu/drm/ttm/ttm_page_alloc_dma.c | 1313 ++++++++++++++++++++++++= ++++++ include/drm/ttm/ttm_page_alloc.h | 32 +- 4 files changed, 1346 insertions(+), 4 deletions(-) create mode 100644 drivers/gpu/drm/ttm/ttm_page_alloc_dma.c diff --git a/drivers/gpu/drm/ttm/Makefile b/drivers/gpu/drm/ttm/Makefile index f3cf6f0..8300bc0 100644 --- a/drivers/gpu/drm/ttm/Makefile +++ b/drivers/gpu/drm/ttm/Makefile @@ -7,4 +7,7 @@ ttm-y :=3D ttm_agp_backend.o ttm_memory.o ttm_tt.o ttm_bo= .o \ ttm_object.o ttm_lock.o ttm_execbuf_util.o ttm_page_alloc.o \ ttm_bo_manager.o =20 +ifeq ($(CONFIG_SWIOTLB),y) +ttm-y +=3D ttm_page_alloc_dma.o +endif obj-$(CONFIG_DRM_TTM) +=3D ttm.o diff --git a/drivers/gpu/drm/ttm/ttm_memory.c b/drivers/gpu/drm/ttm/ttm_m= emory.c index c7d97a5..57323fe 100644 --- a/drivers/gpu/drm/ttm/ttm_memory.c +++ b/drivers/gpu/drm/ttm/ttm_memory.c @@ -397,6 +397,8 @@ int ttm_mem_global_init(struct ttm_mem_global *glob) zone->name, (unsigned long long) zone->max_mem >> 10); } ttm_page_alloc =3D &ttm_page_alloc_default; + if (ttm_page_alloc_need_dma()) + printk(KERN_INFO TTM_PFX "Using DMA aware pool.\n"); ttm_page_alloc_init(glob, glob->zone_kernel->max_mem/(2*PAGE_SIZE)); return 0; out_no_zone: diff --git a/drivers/gpu/drm/ttm/ttm_page_alloc_dma.c b/drivers/gpu/drm/t= tm/ttm_page_alloc_dma.c new file mode 100644 index 0000000..5a5739c --- /dev/null +++ b/drivers/gpu/drm/ttm/ttm_page_alloc_dma.c @@ -0,0 +1,1313 @@ +/* + * Copyright 2011 (c) Oracle Corp. + + * Permission is hereby granted, free of charge, to any person obtaining= a + * copy of this software and associated documentation files (the "Softwa= re"), + * to deal in the Software without restriction, including without limita= tion + * the rights to use, copy, modify, merge, publish, distribute, sub lice= nse, + * and/or sell copies of the Software, and to permit persons to whom the + * Software is furnished to do so, subject to the following conditions: + * + * The above copyright notice and this permission notice (including the + * next paragraph) shall be included in all copies or substantial portio= ns + * of the Software. + * + * THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRE= SS OR + * IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILI= TY, + * FITNESS FOR A PARTICULAR PURPOSE AND NON-INFRINGEMENT. IN NO EVENT SH= ALL + * THE AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR = OTHER + * LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISI= NG + * FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER + * DEALINGS IN THE SOFTWARE. + * + * Author: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com> + */ + +/* + * A simple DMA pool losely based on dmapool.c. It has certain advantage= s + * over the DMA pools: + * - Pool collects resently freed pages for reuse (and hooks up to + * the shrinker). + * - Tracks currently in use pages + * - Tracks whether the page is UC, WB or cached (and reverts to WB + * when freed). + */ + +#include <linux/dma-mapping.h> +#include <linux/list.h> +#include <linux/seq_file.h> /* for seq_printf */ +#include <linux/slab.h> +#include <linux/spinlock.h> +#include <linux/highmem.h> +#include <linux/mm_types.h> +#include <linux/module.h> +#include <linux/mm.h> +#include <linux/atomic.h> +#include <linux/device.h> +#include <linux/kthread.h> +#include "ttm/ttm_bo_driver.h" +#include "ttm/ttm_page_alloc.h" +#ifdef TTM_HAS_AGP +#include <asm/agp.h> +#endif + +#define NUM_PAGES_TO_ALLOC (PAGE_SIZE/sizeof(struct page *)) +#define SMALL_ALLOCATION 16 +#define FREE_ALL_PAGES (~0U) +/* times are in msecs */ +#define IS_UNDEFINED (0) +#define IS_WC (1<<1) +#define IS_UC (1<<2) +#define IS_CACHED (1<<3) +#define IS_DMA32 (1<<4) + +enum pool_type { + POOL_IS_UNDEFINED, + POOL_IS_WC =3D IS_WC, + POOL_IS_UC =3D IS_UC, + POOL_IS_CACHED =3D IS_CACHED, + POOL_IS_WC_DMA32 =3D IS_WC | IS_DMA32, + POOL_IS_UC_DMA32 =3D IS_UC | IS_DMA32, + POOL_IS_CACHED_DMA32 =3D IS_CACHED | IS_DMA32, +}; +/* + * The pool structure. There are usually six pools: + * - generic (not restricted to DMA32): + * - write combined, uncached, cached. + * - dma32 (up to 2^32 - so up 4GB): + * - write combined, uncached, cached. + * for each 'struct device'. The 'cached' is for pages that are actively= used. + * The other ones can be shrunk by the shrinker API if neccessary. + * @pools: The 'struct device->dma_pools' link. + * @type: Type of the pool + * @lock: Protects the page_list from concurrnet access. Must be used wi= th + * irqsave/irqrestore variants because pool allocator maybe called from + * delayed work. + * @page_list: Pool of all pages (both in use and free). + * @dev: The device that is associated with these pools. + * @size: Size used during DMA allocation. + * @npages_free: Count of available pages for re-use. + * @npages_in_use: Count of pages that are in use (each of them + * is marked in_use. + * @nfrees: Stats when pool is shrinking. + * @nrefills: Stats when the pool is grown. + * @gfp_flags: Flags to pass for alloc_page. + * @name: Name of the pool. + * @dev_name: Name derieved from dev - similar to how dev_info works. + * Used during shutdown as the dev_info during release is unavailable. + */ +struct dma_pool { + struct list_head pools; /* The 'struct device->dma_pools link */ + enum pool_type type; + spinlock_t lock; + struct list_head page_list; + struct device *dev; + unsigned size; + unsigned npages_free; + unsigned npages_in_use; + unsigned long nfrees; /* Stats when shrunk. */ + unsigned long nrefills; /* Stats when grown. */ + gfp_t gfp_flags; + char name[13]; /* "cached dma32" */ + char dev_name[64]; /* Constructed from dev */ +}; + +/* + * The accounting page keeping track of the allocated page along with + * the DMA address. + * @page_list: The link to the 'page_list' in 'struct dma_pool'. + * @vaddr: The virtual address of the page + * @dma: The bus address of the page. If the page is not allocated + * via the DMA API, it will be -1. + * @in_use: Set to true if in use. Should not be freed. + */ +struct dma_page { + struct list_head page_list; + void *vaddr; + dma_addr_t dma; + unsigned int in_use:1; +}; + +/* + * Limits for the pool. They are handled without locks because only plac= e where + * they may change is in sysfs store. They won't have immediate effect a= nyway + * so forcing serialization to access them is pointless. + */ + +struct ttm_pool_opts { + unsigned alloc_size; + unsigned max_size; + unsigned small; +}; + +/* + * Contains the list of all of the 'struct device' and their correspondi= ng + * DMA pools. Guarded by _mutex->lock. + * @pools: The link to 'struct ttm_pool_manager->pools' + * @dev: The 'struct device' associated with the 'pool' + * @pool: The 'struct dma_pool' associated with the 'dev' + */ +struct device_pools { + struct list_head pools; + struct device *dev; + struct dma_pool *pool; +}; + +/* + * struct ttm_pool_manager - Holds memory pools for fast allocation + * + * @lock: Lock used when adding/removing from pools + * @pools: List of 'struct device' and 'struct dma_pool' tuples. + * @options: Limits for the pool. + * @npools: Total amount of pools in existence. + * @shrinker: The structure used by [un|]register_shrinker + */ +struct ttm_pool_manager { + struct mutex lock; + struct list_head pools; + struct ttm_pool_opts options; + unsigned npools; + struct shrinker mm_shrink; + struct kobject kobj; +}; + +static struct ttm_pool_manager *_manager; + +static struct attribute ttm_page_pool_max =3D { + .name =3D "pool_max_size", + .mode =3D S_IRUGO | S_IWUSR +}; +static struct attribute ttm_page_pool_small =3D { + .name =3D "pool_small_allocation", + .mode =3D S_IRUGO | S_IWUSR +}; +static struct attribute ttm_page_pool_alloc_size =3D { + .name =3D "pool_allocation_size", + .mode =3D S_IRUGO | S_IWUSR +}; + +static struct attribute *ttm_pool_attrs[] =3D { + &ttm_page_pool_max, + &ttm_page_pool_small, + &ttm_page_pool_alloc_size, + NULL +}; + +static void ttm_pool_kobj_release(struct kobject *kobj) +{ + struct ttm_pool_manager *m =3D + container_of(kobj, struct ttm_pool_manager, kobj); + kfree(m); +} + +static ssize_t ttm_pool_store(struct kobject *kobj, struct attribute *at= tr, + const char *buffer, size_t size) +{ + struct ttm_pool_manager *m =3D + container_of(kobj, struct ttm_pool_manager, kobj); + int chars; + unsigned val; + chars =3D sscanf(buffer, "%u", &val); + if (chars =3D=3D 0) + return size; + + /* Convert kb to number of pages */ + val =3D val / (PAGE_SIZE >> 10); + + if (attr =3D=3D &ttm_page_pool_max) + m->options.max_size =3D val; + else if (attr =3D=3D &ttm_page_pool_small) + m->options.small =3D val; + else if (attr =3D=3D &ttm_page_pool_alloc_size) { + if (val > NUM_PAGES_TO_ALLOC*8) { + printk(KERN_ERR TTM_PFX + "Setting allocation size to %lu " + "is not allowed. Recommended size is " + "%lu\n", + NUM_PAGES_TO_ALLOC*(PAGE_SIZE >> 7), + NUM_PAGES_TO_ALLOC*(PAGE_SIZE >> 10)); + return size; + } else if (val > NUM_PAGES_TO_ALLOC) { + printk(KERN_WARNING TTM_PFX + "Setting allocation size to " + "larger than %lu is not recommended.\n", + NUM_PAGES_TO_ALLOC*(PAGE_SIZE >> 10)); + } + m->options.alloc_size =3D val; + } + + return size; +} + +static ssize_t ttm_pool_show(struct kobject *kobj, struct attribute *att= r, + char *buffer) +{ + struct ttm_pool_manager *m =3D + container_of(kobj, struct ttm_pool_manager, kobj); + unsigned val =3D 0; + + if (attr =3D=3D &ttm_page_pool_max) + val =3D m->options.max_size; + else if (attr =3D=3D &ttm_page_pool_small) + val =3D m->options.small; + else if (attr =3D=3D &ttm_page_pool_alloc_size) + val =3D m->options.alloc_size; + + val =3D val * (PAGE_SIZE >> 10); + + return snprintf(buffer, PAGE_SIZE, "%u\n", val); +} + +static const struct sysfs_ops ttm_pool_sysfs_ops =3D { + .show =3D &ttm_pool_show, + .store =3D &ttm_pool_store, +}; + +static struct kobj_type ttm_pool_kobj_type =3D { + .release =3D &ttm_pool_kobj_release, + .sysfs_ops =3D &ttm_pool_sysfs_ops, + .default_attrs =3D ttm_pool_attrs, +}; + +#ifndef CONFIG_X86 +static int set_pages_array_wb(struct page **pages, int addrinarray) +{ +#ifdef TTM_HAS_AGP + int i; + + for (i =3D 0; i < addrinarray; i++) + unmap_page_from_agp(pages[i]); +#endif + return 0; +} + +static int set_pages_array_wc(struct page **pages, int addrinarray) +{ +#ifdef TTM_HAS_AGP + int i; + + for (i =3D 0; i < addrinarray; i++) + map_page_into_agp(pages[i]); +#endif + return 0; +} + +static int set_pages_array_uc(struct page **pages, int addrinarray) +{ +#ifdef TTM_HAS_AGP + int i; + + for (i =3D 0; i < addrinarray; i++) + map_page_into_agp(pages[i]); +#endif + return 0; +} +#endif /* for !CONFIG_X86 */ + +static int ttm_set_pages_caching(struct dma_pool *pool, + struct page **pages, unsigned cpages) +{ + int r =3D 0; + /* Set page caching */ + if (pool->type & IS_UC) { + r =3D set_pages_array_uc(pages, cpages); + if (r) + pr_err(TTM_PFX + "%s: Failed to set %d pages to uc!\n", + pool->dev_name, cpages); + } + if (pool->type & IS_WC) { + r =3D set_pages_array_wc(pages, cpages); + if (r) + pr_err(TTM_PFX + "%s: Failed to set %d pages to wc!\n", + pool->dev_name, cpages); + } + return r; +} + +static void __ttm_dma_free_page(struct dma_pool *pool, struct dma_page *= d_page) +{ + dma_addr_t dma =3D d_page->dma; + + pr_debug("%s: (%s:%d) Freeing %p (%p) (DMA:0x%lx)\n", + pool->dev_name, pool->name, current->pid, d_page->vaddr, + virt_to_page(d_page->vaddr), (unsigned long)dma); + + dma_free_coherent(pool->dev, pool->size, d_page->vaddr, dma); + + kfree(d_page); + d_page =3D NULL; +} +static struct dma_page *__ttm_dma_alloc_page(struct dma_pool *pool) +{ + struct dma_page *d_page; + + d_page =3D kmalloc(sizeof(struct dma_page), GFP_KERNEL); + if (!d_page) + return NULL; + + d_page->vaddr =3D dma_alloc_coherent(pool->dev, pool->size, + &d_page->dma, + pool->gfp_flags); + if (d_page->vaddr) { + pr_debug("%s: (%s:%d) Allocated %p (%p) (DMA:0x%lx)\n", + pool->dev_name, pool->name, current->pid, d_page->vaddr, + virt_to_page(d_page->vaddr), + (unsigned long)d_page->dma); + d_page->in_use =3D 0; + } else { + kfree(d_page); + d_page =3D NULL; + } + + return d_page; +} +static enum pool_type ttm_to_type(int flags, enum ttm_caching_state csta= te) +{ + enum pool_type type =3D IS_UNDEFINED; + + if (flags & TTM_PAGE_FLAG_DMA32) + type |=3D IS_DMA32; + if (cstate =3D=3D tt_cached) + type |=3D IS_CACHED; + else if (cstate =3D=3D tt_uncached) + type |=3D IS_UC; + else + type |=3D IS_WC; + + return type; +} +static void ttm_pool_update_inuse(struct dma_pool *pool, unsigned count) +{ + unsigned long irq_flags; + + spin_lock_irqsave(&pool->lock, irq_flags); + pool->npages_free +=3D count; + pool->npages_in_use -=3D count; + spin_unlock_irqrestore(&pool->lock, irq_flags); +} +static void ttm_pool_update_free_locked(struct dma_pool *pool, + unsigned freed_pages) +{ + pool->npages_free -=3D freed_pages; + pool->nfrees +=3D freed_pages; + +} +/* set memory back to wb and free the pages. */ +static void ttm_dma_pages_put(struct dma_pool *pool, struct list_head *d= _pages, + struct page *pages[], unsigned npages) +{ + struct dma_page *d_page, *tmp; + + if (npages && set_pages_array_wb(pages, npages)) + pr_err(TTM_PFX "%s: Failed to set %d pages to wb!\n", + pool->dev_name, npages); + + pr_debug("%s: (%s:%d) Freeing %d pages at once.\n", + pool->dev_name, pool->name, current->pid, npages); + + list_for_each_entry_safe(d_page, tmp, d_pages, page_list) { + list_del(&d_page->page_list); + __ttm_dma_free_page(pool, d_page); + } +} +/* + * Free pages from pool. + * + * To prevent hogging the ttm_swap process we only free NUM_PAGES_TO_ALL= OC + * number of pages in one go. + * + * @pool: to free the pages from + * @nr_free: If set to true will free all pages in pool + **/ +static unsigned ttm_dma_page_pool_free(struct dma_pool *pool, unsigned n= r_free) +{ + unsigned long irq_flags; + struct dma_page *dma_p, *tmp; + struct page **pages_to_free; + struct list_head d_pages; + unsigned freed_pages =3D 0, + npages_to_free =3D nr_free; + + if (NUM_PAGES_TO_ALLOC < nr_free) + npages_to_free =3D NUM_PAGES_TO_ALLOC; + + pages_to_free =3D kmalloc(npages_to_free * sizeof(struct dma_page *), + GFP_KERNEL); + + if (!pages_to_free) { + pr_err(TTM_PFX + "%s: Failed to allocate memory for pool free operation.\n", + pool->dev_name); + return 0; + } + INIT_LIST_HEAD(&d_pages); +restart: + spin_lock_irqsave(&pool->lock, irq_flags); + list_for_each_entry_safe_reverse(dma_p, tmp, &pool->page_list, + page_list) { + if (freed_pages >=3D npages_to_free) + break; + + if (dma_p->in_use) + continue; + + pr_debug("%s: (%s:%d) %p (%p) (DMA:0x%lx) is expunged.\n", + pool->dev_name, pool->name, current->pid, dma_p->vaddr, + virt_to_page(dma_p->vaddr), + (unsigned long)dma_p->dma); + + /* Move the dma_page from one list to another. */ + list_del(&dma_p->page_list); + list_add(&dma_p->page_list, &d_pages); + + pages_to_free[freed_pages++] =3D virt_to_page(dma_p->vaddr); + /* We can only remove NUM_PAGES_TO_ALLOC at a time. */ + if (freed_pages >=3D NUM_PAGES_TO_ALLOC) { + + ttm_pool_update_free_locked(pool, freed_pages); + /** + * Because changing page caching is costly + * we unlock the pool to prevent stalling. + */ + spin_unlock_irqrestore(&pool->lock, irq_flags); + + ttm_dma_pages_put(pool, &d_pages, pages_to_free, + freed_pages); + + INIT_LIST_HEAD(&d_pages); + + if (likely(nr_free !=3D FREE_ALL_PAGES)) + nr_free -=3D freed_pages; + + if (NUM_PAGES_TO_ALLOC >=3D nr_free) + npages_to_free =3D nr_free; + else + npages_to_free =3D NUM_PAGES_TO_ALLOC; + + freed_pages =3D 0; + + /* free all so restart the processing */ + if (nr_free) + goto restart; + + /* Not allowed to fall tough or break because + * following context is inside spinlock while we are + * outside here. + */ + goto out; + + } + } + + /* remove range of pages from the pool */ + if (freed_pages) { + ttm_pool_update_free_locked(pool, freed_pages); + nr_free -=3D freed_pages; + } + + spin_unlock_irqrestore(&pool->lock, irq_flags); + + if (freed_pages) + ttm_dma_pages_put(pool, &d_pages, pages_to_free, freed_pages); +out: + kfree(pages_to_free); + return nr_free; +} + +static void ttm_dma_free_pool(struct device *dev, enum pool_type type) +{ + struct device_pools *p; + struct dma_pool *pool; + struct dma_page *d_page, *d_tmp; + + if (!dev) + return; + + mutex_lock(&_manager->lock); + list_for_each_entry_reverse(p, &_manager->pools, pools) { + if (p->dev !=3D dev) + continue; + pool =3D p->pool; + if (pool->type !=3D type) + continue; + pr_debug("%s: (%s:%d) of device pool freed "\ + "(has %d free, and %d in use).\n", + pool->dev_name, pool->name, current->pid, + pool->npages_free, pool->npages_in_use); + list_del(&p->pools); + kfree(p); + _manager->npools--; + break; + } + list_for_each_entry_reverse(pool, &dev->dma_pools, pools) { + unsigned long irq_save; + if (pool->type !=3D type) + continue; + /* Takes a spinlock.. */ + ttm_dma_page_pool_free(pool, FREE_ALL_PAGES); + /* .. but afterwards we can take it too */ + spin_lock_irqsave(&pool->lock, irq_save); + list_for_each_entry_safe(d_page, d_tmp, &pool->page_list, + page_list) { + if (d_page->in_use) { + pr_err("%s: (%s:%d) %p (%p DMA:0x%lx) busy!\n", + pool->dev_name, pool->name, + current->pid, d_page->vaddr, + virt_to_page(d_page->vaddr), + (unsigned long)d_page->dma); + list_del(&d_page->page_list); + kfree(d_page); + pool->npages_in_use--; + } + } + spin_unlock_irqrestore(&pool->lock, irq_save); + WARN_ON(((pool->npages_in_use + pool->npages_free) !=3D 0)); + /* This code path is called after _all_ references to the + * struct device has been dropped - so nobody should be + * touching it. In case somebody is trying to _add_ we are + * guarded by the mutex. */ + list_del(&pool->pools); + kfree(pool); + break; + } + mutex_unlock(&_manager->lock); +} +/* + * On free-ing of the 'struct device' this deconstructor is run. + * Albeit the pool might have already been freed earlier. + */ +static void ttm_dma_pool_release(struct device *dev, void *res) +{ + struct dma_pool *pool =3D *(struct dma_pool **)res; + + if (pool) + ttm_dma_free_pool(dev, pool->type); +} + +static int ttm_dma_pool_match(struct device *dev, void *res, void *match= _data) +{ + return *(struct dma_pool **)res =3D=3D match_data; +} + +static struct dma_pool *ttm_dma_pool_init(struct device *dev, gfp_t flag= s, + enum pool_type type) +{ + char *n[] =3D {"wc", "uc", "cached", " dma32", "unknown",}; + enum pool_type t[] =3D {IS_WC, IS_UC, IS_CACHED, IS_DMA32, IS_UNDEFINED= }; + struct device_pools *sec_pool =3D NULL; + struct dma_pool *pool =3D NULL, **ptr; + unsigned i; + int ret =3D -ENODEV; + char *p; + + if (!dev) + return NULL; + + ptr =3D devres_alloc(ttm_dma_pool_release, sizeof(*ptr), GFP_KERNEL); + if (!ptr) + return NULL; + + ret =3D -ENOMEM; + + pool =3D kmalloc_node(sizeof(struct dma_pool), GFP_KERNEL, + dev_to_node(dev)); + if (!pool) + goto err_mem; + + sec_pool =3D kmalloc_node(sizeof(struct device_pools), GFP_KERNEL, + dev_to_node(dev)); + if (!sec_pool) + goto err_mem; + + INIT_LIST_HEAD(&sec_pool->pools); + sec_pool->dev =3D dev; + sec_pool->pool =3D pool; + + INIT_LIST_HEAD(&pool->page_list); + INIT_LIST_HEAD(&pool->pools); + spin_lock_init(&pool->lock); + pool->dev =3D dev; + pool->npages_free =3D pool->npages_in_use =3D 0; + pool->nfrees =3D 0; + pool->gfp_flags =3D flags; + pool->size =3D PAGE_SIZE; + pool->type =3D type; + pool->nrefills =3D 0; + p =3D pool->name; + for (i =3D 0; i < 5; i++) { + if (type & t[i]) { + p +=3D snprintf(p, sizeof(pool->name) - (p - pool->name), + "%s", n[i]); + } + } + *p =3D 0; + /* We copy the name for pr_ calls b/c when dma_pool_destroy is called + * - the kobj->name has already been deallocated.*/ + snprintf(pool->dev_name, sizeof(pool->dev_name), "%s %s", + dev_driver_string(dev), dev_name(dev)); + mutex_lock(&_manager->lock); + /* You can get the dma_pool from either the global: */ + list_add(&sec_pool->pools, &_manager->pools); + _manager->npools++; + /* or from 'struct device': */ + list_add(&pool->pools, &dev->dma_pools); + mutex_unlock(&_manager->lock); + + *ptr =3D pool; + devres_add(dev, ptr); + + return pool; +err_mem: + devres_free(ptr); + kfree(sec_pool); + kfree(pool); + return ERR_PTR(ret); +} +static struct dma_pool *ttm_dma_find_pool(struct device *dev, + enum pool_type type) +{ + struct dma_pool *pool, *tmp, *found =3D NULL; + + if (type =3D=3D IS_UNDEFINED) + return found; + /* NB: We iterate on the 'struct dev' which has no spinlock, but + * it does have a kref which we have taken. */ + list_for_each_entry_safe(pool, tmp, &dev->dma_pools, pools) { + if (pool->type !=3D type) + continue; + found =3D pool; + } + if (found) + pr_debug("%s: (%s:%d) Found. It has %d free pages (%d in use)\n", + found->dev_name, found->name, current->pid, + found->npages_free, found->npages_in_use); + return found; +} + +/* + * Free pages the pages that failed to change the caching state. If ther= e is + * any pages that have changed their caching state already put them to t= he + * pool. + */ +static void ttm_dma_handle_caching_state_failure(struct dma_pool *pool, + struct page **failed_pages, + unsigned cpages) +{ + unsigned long irq_flags; + unsigned i; + struct dma_page *dma_p, *t; + struct list_head d_pages; + + /* Failed pages have to be freed */ + i =3D cpages; + + INIT_LIST_HEAD(&d_pages); + + /* To make it faster we only take the spinlock on list + * removal, and later on do the free-ing at our leisure. */ + spin_lock_irqsave(&pool->lock, irq_flags); + list_for_each_entry_safe(dma_p, t, &pool->page_list, page_list) { + struct page *p =3D failed_pages[i]; + if (virt_to_page(dma_p->vaddr) !=3D p) { + pr_debug("%s: (%s:%d) Skipping %p (%p) (DMA:0x%lx)\n", + pool->dev_name, pool->name, current->pid, + dma_p->vaddr, + virt_to_page(dma_p->vaddr), + (unsigned long)dma_p->dma); + continue; + } + list_del(&dma_p->page_list); + list_add(&dma_p->page_list, &d_pages); + list_del(&failed_pages[i]->lru); + if (--i =3D=3D 0) + break; + } + ttm_pool_update_free_locked(pool, (cpages - i)); + spin_unlock_irqrestore(&pool->lock, irq_flags); + + ttm_dma_pages_put(pool, &d_pages, NULL/* Don't try to set WB on them */= , + cpages - i); +} + +static int ttm_dma_pool_alloc_new_pages(struct dma_pool *pool, + struct list_head *pages, + dma_addr_t *dma_address, + unsigned dma_offset, unsigned count) +{ + struct page **caching_array; + struct dma_page *dma_p; + struct page *p; + int r =3D 0; + unsigned i, cpages; + unsigned long irq_flags; + unsigned max_cpages =3D min(count, + (unsigned)(PAGE_SIZE/sizeof(struct page *))); + + /* allocate array for page caching change */ + caching_array =3D kmalloc(max_cpages*sizeof(struct page *), GFP_KERNEL)= ; + + if (!caching_array) { + pr_err(TTM_PFX + "%s: Unable to allocate table for new pages.", + pool->dev_name); + return -ENOMEM; + } + pr_debug("%s: (%s:%d) Getting %d pages @ %d idx\n", + pool->dev_name, pool->name, current->pid, + count, dma_offset); + for (i =3D 0, cpages =3D 0; i < count; ++i) { + dma_p =3D __ttm_dma_alloc_page(pool); + if (!dma_p) { + pr_err(TTM_PFX "%s: Unable to get page %u.\n", + pool->dev_name, i); + + /* store already allocated pages in the pool after + * setting the caching state */ + if (cpages) { + r =3D ttm_set_pages_caching(pool, caching_array, + cpages); + if (r) + ttm_dma_handle_caching_state_failure( + pool, caching_array, cpages); + } + r =3D -ENOMEM; + goto out; + } + p =3D virt_to_page(dma_p->vaddr); + /* Take ownership of that page. */ + dma_p->in_use =3D true; + /* And now add it in without having to worry about it being + * immediately picked up by another thread. */ + spin_lock_irqsave(&pool->lock, irq_flags); + list_add(&dma_p->page_list, &pool->page_list); + pool->npages_in_use++; + spin_unlock_irqrestore(&pool->lock, irq_flags); +#ifdef CONFIG_HIGHMEM + /* gfp flags of highmem page should never be dma32 so we + * we should be fine in such case + */ + if (!PageHighMem(p)) +#endif + { + caching_array[cpages++] =3D p; + if (cpages =3D=3D max_cpages) { + + r =3D ttm_set_pages_caching(pool, caching_array, + cpages); + if (r) { + ttm_dma_handle_caching_state_failure( + pool, caching_array, cpages); + goto out; + } + cpages =3D 0; + } + } + /* Note: We do _not_ add the pages to the cached pool here. */ + list_add_tail(&p->lru, pages); + dma_address[dma_offset + i] =3D dma_p->dma; + } + + if (cpages) { + r =3D ttm_set_pages_caching(pool, caching_array, cpages); + if (r) + ttm_dma_handle_caching_state_failure(pool, + caching_array, cpages); + } +out: + kfree(caching_array); + return r; +} +/* + * Recycle (or delete) the 'pages' that are on the 'pool'. + * @pool: The pool that the pages are associated with. + * @pages: The list of pages we are done with. + * @page_count: Count of how many pages (or zero if all). + * @erase: Instead of recycling - just free them. + */ +static int ttm_dma_put_pages_in_pool(struct dma_pool *pool, + struct list_head *pages, + unsigned page_count, + bool erase) +{ + unsigned long uninitialized_var(irq_flags); + struct list_head uninitialized_var(d_pages); + struct page **uninitialized_var(pages_to_free); + unsigned uninitialized_var(freed_pages); + struct dma_page *d_page, *d_tmp; + struct page *p, *tmp; + bool found =3D false; + unsigned count =3D 0; + + if (list_empty(pages)) + return 0; + + if (page_count =3D=3D 0) { + list_for_each_entry_safe(p, tmp, pages, lru) + ++page_count; + } + pr_debug("%s: (%s:%d) %s %d pages\n", + pool->dev_name, pool->name, current->pid, + erase ? "Destroying" : "Recycling", page_count); + + if (erase) { + INIT_LIST_HEAD(&d_pages); + pages_to_free =3D kmalloc(page_count * sizeof(struct dma_page *), + GFP_KERNEL); + if (!pages_to_free) { + dev_err(pool->dev, TTM_PFX + "Failed to allocate memory for pool free operation.\n"); + return 0; + } + spin_lock_irqsave(&pool->lock, irq_flags); + freed_pages =3D 0; + } + list_for_each_entry_safe_reverse(p, tmp, pages, lru) { + found =3D false; + /* We only hold the lock when erasing. Otherwise we just + * set the d_page->in_use bit. */ + list_for_each_entry_safe(d_page, d_tmp, &pool->page_list, + page_list) { + if (p !=3D virt_to_page(d_page->vaddr)) + continue; + found =3D true; + break; + } + if (!found) + break; /* We could continue, but why bother..*/ + + WARN_ON(!d_page->in_use); + d_page->in_use =3D false; + count++; + list_del_init(&p->lru); + if (erase) { + list_del(&d_page->page_list); + list_add(&d_page->page_list, &d_pages); + pages_to_free[freed_pages++] =3D + virt_to_page(d_page->vaddr); + } + /* Do not advance past what we were asked to delete. */ + if (count =3D=3D page_count) + break; + } + if (erase) { + spin_unlock_irqrestore(&pool->lock, irq_flags); + ttm_dma_pages_put(pool, &d_pages, pages_to_free /* to set WB */, + freed_pages); + kfree(pages_to_free); + } + pr_debug("%s: (%s:%d) Put %d/%d pages in the pool.\n", + pool->dev_name, pool->name, current->pid, count, page_count); + return count; +} +/* + * @return count of pages still required to fulfill the request. +*/ +static int ttm_dma_page_pool_fill_locked(struct dma_pool *pool, + struct list_head *pages, + dma_addr_t *dma_address, + unsigned count, + unsigned long *irq_flags) +{ + int r =3D count; + + if (count < _manager->options.small && + count > pool->npages_free) { + /* Do NOT try to get more than count. This is b/c + * dma_address[count++] will fail. */ + unsigned alloc_size =3D min(count, _manager->options.alloc_size); + + spin_unlock_irqrestore(&pool->lock, *irq_flags); + /* Returns how many more are neccessary to fulfill the + * request. */ + r =3D ttm_dma_pool_alloc_new_pages(pool, pages, dma_address, + 0 /* no offset */, alloc_size); + spin_lock_irqsave(&pool->lock, *irq_flags); + + if (!r) { + ++pool->nrefills; + } else { + pr_err(TTM_PFX "%s: Failed to fill %s pool (r:%d)!\n", + pool->dev_name, pool->name, r); + spin_unlock_irqrestore(&pool->lock, *irq_flags); + count =3D ttm_dma_put_pages_in_pool(pool, pages, + 0 /* no WB */, + false /* recycle */); + spin_lock_irqsave(&pool->lock, *irq_flags); + pool->npages_free +=3D count; + pool->npages_in_use -=3D count; + } + } + return r; + +} + +/* + * @return count of pages still required to fulfill the request. + */ +static int ttm_dma_pool_get_pages(struct dma_pool *pool, + struct list_head *pages, + dma_addr_t *dma_address, unsigned count) +{ + unsigned long irq_flags; + int r =3D 0; + unsigned i; + struct page *p; + struct dma_page *dma_p; + + spin_lock_irqsave(&pool->lock, irq_flags); + r =3D ttm_dma_page_pool_fill_locked(pool, pages, dma_address, + count, &irq_flags); + pr_debug("%s: (%s:%d) Asked for %d, got %d %s.\n", + pool->dev_name, pool->name, current->pid, count, r, + (r < 0) ? "err:" : "pages"); + + if (r < 0) + goto out; + + if (r > count) { + /* This should never happen. */ + WARN_ON(1); + /* But just in case, limit it to what we requested. */ + r =3D count; + } + /* How many "left" we need to pick off the free list */ + count =3D r; + /* And in case we have gotten all the pages we need - we exit. */ + if (count =3D=3D 0) + goto out; + /* NB: Don't set r=3D0 at the start of the loop, otherwise you will + * overwrite the previously dma_address[x] fields. */ + r =3D count - r; + i =3D 0; + pr_debug("%s: (%s:%d) Scavenging for %d pages - inserting @ %d idx " \ + "(have %d pages free)\n", + pool->dev_name, pool->name, current->pid, count, r, + pool->npages_free); + /* Copy as many as we need from the pool to fulfill the request.*/ + list_for_each_entry(dma_p, &pool->page_list, page_list) { + if (dma_p->in_use) + continue; + p =3D virt_to_page(dma_p->vaddr); + list_add_tail(&p->lru, pages); + dma_address[r++] =3D dma_p->dma; + pr_debug("%s: (%s:%d) Salvaged %p (%p) (DMA:0x%lx)\n", + pool->dev_name, pool->name, current->pid, dma_p->vaddr, + virt_to_page(dma_p->vaddr), + (unsigned long)dma_p->dma); + + /* Take ownership of that page. */ + dma_p->in_use =3D true; + if (++i =3D=3D count) + break; + } + pool->npages_in_use +=3D i; + pool->npages_free -=3D i; + count -=3D i; + pr_debug("%s: (%s:%d) Have taken %d pages, need %d more.\n", + pool->dev_name, pool->name, current->pid, r, count); +out: + spin_unlock_irqrestore(&pool->lock, irq_flags); + return count; +} +/* + * On success pages list will hold count number of correctly + * cached pages. On failure will hold the negative return value (-ENOMEM= , etc). + */ +static int ttm_dma_get_pages(struct list_head *pages, int flags, + enum ttm_caching_state cstate, unsigned count, + dma_addr_t *dma_address, struct device *dev) + +{ + int r =3D -ENOMEM; + struct dma_pool *pool; + gfp_t gfp_flags; + enum pool_type type; + unsigned pages_got =3D count; + + type =3D ttm_to_type(flags, cstate); + + if (flags & TTM_PAGE_FLAG_DMA32) + gfp_flags =3D GFP_USER | GFP_DMA32; + else + gfp_flags =3D GFP_HIGHUSER; + + if (flags & TTM_PAGE_FLAG_ZERO_ALLOC) + gfp_flags |=3D __GFP_ZERO; + + pool =3D ttm_dma_find_pool(dev, type); + if (!pool) { + pool =3D ttm_dma_pool_init(dev, gfp_flags, type); + if (IS_ERR_OR_NULL(pool)) + return -ENOMEM; + } + /* Take pages out of a pool (if applicable) */ + r =3D ttm_dma_pool_get_pages(pool, pages, dma_address, count); + /* clear the pages coming from the pool if requested */ + if (flags & TTM_PAGE_FLAG_ZERO_ALLOC) { + struct page *p; + list_for_each_entry(p, pages, lru) { + clear_page(page_address(p)); + } + } + pages_got =3D count - r; + /* If pool didn't have enough pages allocate new one. */ + if (r > 0) { + unsigned pages_need =3D r; + r =3D ttm_dma_pool_alloc_new_pages(pool, pages, dma_address, + pages_got /* offset in dma_address*/, + pages_need); + if (r >=3D 0) + pages_got +=3D pages_need - r; + + pr_debug("%s: (%s:%d) have %d pages, %s %d.\n", + pool->dev_name, + pool->name, current->pid, pages_got, + pages_got =3D=3D count ? + "got them all" : "need more - (err):", r); + if (r) { + /* If there is any pages in the list put them back to + * the pool. */ + pr_err(TTM_PFX + "%s: Failed to allocate extra pages " + "for large request.", + pool->dev_name); + count =3D ttm_dma_put_pages_in_pool(pool, pages, + 0 /* no WB */, + false /* recycle */); + INIT_LIST_HEAD(pages); + ttm_pool_update_inuse(pool, count); + return count; + } + } + return r; +} + +/* Put all pages in pages list to correct pool to wait for reuse */ +static void ttm_dma_put_pages(struct list_head *pages, unsigned page_cou= nt, + int flags, enum ttm_caching_state cstate, + dma_addr_t *dma_address, struct device *dev) +{ + struct dma_pool *pool; + enum pool_type type; + bool is_cached =3D false; + unsigned count, i; + unsigned long irq_flags; + + if (list_empty(pages)) + return; + + type =3D ttm_to_type(flags, cstate); + pool =3D ttm_dma_find_pool(dev, type); + if (!pool) { + WARN_ON(!pool); + return; + } + is_cached =3D (ttm_dma_find_pool(pool->dev, + ttm_to_type(flags, tt_cached)) =3D=3D pool); + + dev_dbg(pool->dev, "(%s:%d) %s %d pages.\n", pool->name, current->pid, + (is_cached) ? "Destroying" : "Recycling", page_count); + + count =3D ttm_dma_put_pages_in_pool(pool, pages, page_count, is_cached)= ; + + for (i =3D 0; i < count; i++) + dma_address[i] =3D 0; + + spin_lock_irqsave(&pool->lock, irq_flags); + pool->npages_in_use -=3D count; + if (!is_cached) + pool->npages_free +=3D count; + spin_unlock_irqrestore(&pool->lock, irq_flags); + + page_count -=3D count; + WARN(page_count !=3D 0, + "Only freed %d page(s) in %s. Could not free %d rest!\n", + count, pool->name, page_count); + + if (pool->npages_free > _manager->options.max_size) { + page_count =3D pool->npages_free - _manager->options.max_size; + if (page_count < NUM_PAGES_TO_ALLOC) + page_count =3D NUM_PAGES_TO_ALLOC; + } + if (page_count) + ttm_dma_page_pool_free(pool, page_count); +} + +/* Get good estimation how many pages are free in pools */ +static int ttm_pool_get_num_unused_pages(void) +{ + struct device_pools *p; + unsigned total =3D 0; + + mutex_lock(&_manager->lock); + list_for_each_entry(p, &_manager->pools, pools) + total +=3D p->pool->npages_free; + mutex_unlock(&_manager->lock); + return total; +} + +/** + * Callback for mm to request pool to reduce number of page held. + */ +static int ttm_pool_mm_shrink(struct shrinker *shrink, + struct shrink_control *sc) +{ + static atomic_t start_pool =3D ATOMIC_INIT(0); + unsigned idx =3D 0; + unsigned pool_offset =3D atomic_add_return(1, &start_pool); + unsigned shrink_pages =3D sc->nr_to_scan; + struct device_pools *p; + + mutex_lock(&_manager->lock); + pool_offset =3D pool_offset % _manager->npools; + + list_for_each_entry(p, &_manager->pools, pools) { + unsigned nr_free; + + if (!p->dev) + continue; + if (shrink_pages =3D=3D 0) + break; + /* Do it in round-robin fashion. */ + if (++idx < pool_offset) + continue; + nr_free =3D shrink_pages; + shrink_pages =3D ttm_dma_page_pool_free(p->pool, nr_free); + pr_debug("%s: (%s:%d) Asked to shrink %d, have %d more to go\n", + p->pool->dev_name, p->pool->name, current->pid, nr_free, + shrink_pages); + } + mutex_unlock(&_manager->lock); + /* return estimated number of unused pages in pool */ + return ttm_pool_get_num_unused_pages(); +} + +static void ttm_pool_mm_shrink_init(struct ttm_pool_manager *manager) +{ + manager->mm_shrink.shrink =3D &ttm_pool_mm_shrink; + manager->mm_shrink.seeks =3D 1; + register_shrinker(&manager->mm_shrink); +} +static void ttm_pool_mm_shrink_fini(struct ttm_pool_manager *manager) +{ + unregister_shrinker(&manager->mm_shrink); +} + +static int ttm_dma_page_alloc_init(struct ttm_mem_global *glob, + unsigned max_pages) +{ + int ret =3D -ENOMEM; + + WARN_ON(_manager); + + printk(KERN_INFO TTM_PFX "Initializing DMA pool allocator.\n"); + + _manager =3D kzalloc(sizeof(*_manager), GFP_KERNEL); + if (!_manager) + goto err_manager; + + mutex_init(&_manager->lock); + INIT_LIST_HEAD(&_manager->pools); + + _manager->options.max_size =3D max_pages; + _manager->options.small =3D SMALL_ALLOCATION; + _manager->options.alloc_size =3D NUM_PAGES_TO_ALLOC; + + /* This takes care of auto-freeing the _manager */ + ret =3D kobject_init_and_add(&_manager->kobj, &ttm_pool_kobj_type, + &glob->kobj, "pool"); + if (unlikely(ret !=3D 0)) { + kobject_put(&_manager->kobj); + goto err; + } + ttm_pool_mm_shrink_init(_manager); + + return 0; +err_manager: + kfree(_manager); + _manager =3D NULL; +err: + return ret; +} +static void ttm_dma_page_alloc_fini(void) +{ + struct device_pools *p, *t; + + printk(KERN_INFO TTM_PFX "Finalizing DMA pool allocator.\n"); + + ttm_pool_mm_shrink_fini(_manager); + + list_for_each_entry_safe_reverse(p, t, &_manager->pools, pools) { + dev_dbg(p->dev, "(%s:%d) Freeing.\n", p->pool->name, + current->pid); + WARN_ON(devres_destroy(p->dev, ttm_dma_pool_release, + ttm_dma_pool_match, p->pool)); + ttm_dma_free_pool(p->dev, p->pool->type); + } + kobject_put(&_manager->kobj); + _manager =3D NULL; +} + +static int ttm_dma_page_alloc_debugfs(struct seq_file *m, void *data) +{ + struct device_pools *p; + struct dma_pool *pool =3D NULL; + char *h[] =3D {"pool", "refills", "pages freed", "inuse", "available", + "name", "virt", "busaddr"}; + + if (!_manager) { + seq_printf(m, "No pool allocator running.\n"); + return 0; + } + seq_printf(m, "%13s %12s %13s %8s %8s %8s\n", + h[0], h[1], h[2], h[3], h[4], h[5]); + mutex_lock(&_manager->lock); + list_for_each_entry(p, &_manager->pools, pools) { + struct device *dev =3D p->dev; + if (!dev) + continue; + pool =3D p->pool; + seq_printf(m, "%13s %12ld %13ld %8d %8d %8s\n", + pool->name, pool->nrefills, + pool->nfrees, pool->npages_in_use, + pool->npages_free, + pool->dev_name); + } +#ifdef DEBUG + seq_printf(m, "%13s %8s %12s %12s %8s\n", + h[0], h[3], h[6], h[7], h[5]); + list_for_each_entry(p, &_manager->pools, pools) { + struct dma_page *d_page; + struct device *dev =3D p->dev; + if (!dev) + continue; + pool =3D p->pool; + + if ((pool->npages_free + pool->npages_in_use) =3D=3D 0) + continue; + + spin_lock(&pool->lock); + list_for_each_entry(d_page, &pool->page_list, page_list) { + seq_printf(m, + "%13s %8s %12lx %12lx %8s\n", + pool->name, d_page->in_use ? "Busy" : "Free", + (unsigned long)d_page->vaddr, + (unsigned long)d_page->dma, + pool->dev_name); + } + spin_unlock(&pool->lock); + } +#endif + mutex_unlock(&_manager->lock); + return 0; +} + +struct ttm_page_alloc_func ttm_page_alloc_dma =3D { + .get_pages =3D ttm_dma_get_pages, + .put_pages =3D ttm_dma_put_pages, + .alloc_init =3D ttm_dma_page_alloc_init, + .alloc_fini =3D ttm_dma_page_alloc_fini, + .debugfs =3D ttm_dma_page_alloc_debugfs, +}; diff --git a/include/drm/ttm/ttm_page_alloc.h b/include/drm/ttm/ttm_page_= alloc.h index 8fc92f2..a58331d 100644 --- a/include/drm/ttm/ttm_page_alloc.h +++ b/include/drm/ttm/ttm_page_alloc.h @@ -29,6 +29,11 @@ #include "ttm_bo_driver.h" #include "ttm_memory.h" =20 +#ifdef CONFIG_SWIOTLB +#include <linux/dma-mapping.h> +#include <linux/swiotlb.h> +#endif + struct ttm_page_alloc_func { /** * struct ttm_page_alloc_func member get_pages @@ -38,7 +43,8 @@ struct ttm_page_alloc_func { * @flags: ttm flags for page allocation. * @cstate: ttm caching state for the page. * @count: number of pages to allocate. - * @dma_address: The DMA (bus) address of pages (by default zero). + * @dma_address: The DMA (bus) address of pages (if + * TTM DMA pool is used - otherwise it is zero). * @dev: The device that needs this. */ int (*get_pages) (struct list_head *pages, @@ -57,7 +63,8 @@ struct ttm_page_alloc_func { * unknown count. * @flags: ttm flags for page allocation. * @cstate: ttm caching state. - * @dma_address: The DMA (bus) address of pages (by default zero). + * @dma_address: The DMA (bus) address of pages (if + * TTM DMA pool is used - otherwise it is zero). * @dev: The device that needs this. */ void (*put_pages)(struct list_head *pages, @@ -93,6 +100,21 @@ extern struct ttm_page_alloc_func *ttm_page_alloc; /* Defined in ttm_page_alloc.c */ extern struct ttm_page_alloc_func ttm_page_alloc_default; =20 +#ifdef CONFIG_SWIOTLB +/* Defined in ttm_page_alloc_dma.c */ +extern struct ttm_page_alloc_func ttm_page_alloc_dma; + +static inline bool ttm_page_alloc_need_dma(void) +{ + if (swiotlb_nr_tbl()) { + ttm_page_alloc =3D &ttm_page_alloc_dma; + return true; + } + return false; +} +#else +static inline bool ttm_page_alloc_need_dma(void) { return false; } +#endif /** * Get count number of pages from pool to pages list. * @@ -100,7 +122,8 @@ extern struct ttm_page_alloc_func ttm_page_alloc_defa= ult; * @flags: ttm flags for page allocation. * @cstate: ttm caching state for the page. * @count: number of pages to allocate. - * @dma_address: The DMA (bus) address of pages - (by default zero). + * @dma_address: The DMA (bus) address of pages (if TTM DMA pool is used= - + * otherwise the value is zero). * @dev: The device that needs this. */ int ttm_get_pages(struct list_head *pages, @@ -117,7 +140,8 @@ int ttm_get_pages(struct list_head *pages, * count. * @flags: ttm flags for page allocation. * @cstate: ttm caching state. - * @dma_address: The DMA (bus) address of pages (by default zero). + * @dma_address: The DMA (bus) address of pages (if TTM DMA pool is used= - + * otherwise the value is zero). * @dev: The device that needs this. */ void ttm_put_pages(struct list_head *pages, --=20 1.7.4.1 _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel From xen-devel-bounces@lists.xensource.com Thu Sep 29 13:42:34 2011 Return-path: <xen-devel-bounces@lists.xensource.com> Envelope-to: www-data@lists.xensource.com Delivery-date: Thu, 29 Sep 2011 13:42:34 -0700 Received: from localhost ([127.0.0.1] helo=lists.colo.xensource.com) by lists.xensource.com with esmtp (Exim 4.43) id 1R9NRB-0006wz-SP; Thu, 29 Sep 2011 13:42:33 -0700 Received: from mail216.messagelabs.com ([85.158.143.99]) by lists.xensource.com with esmtp (Exim 4.43) id 1R9NJI-0003AK-Lh for xen-devel@lists.xensource.com; Thu, 29 Sep 2011 13:34:24 -0700 X-Env-Sender: konrad@oracle.com X-Msg-Ref: server-14.tower-216.messagelabs.com!1317328460!20060243!1 X-Originating-IP: [141.146.126.227] X-StarScan-Version: 6.4.1; banners=-,-,- X-VirusChecked: Checked Received: (qmail 5150 invoked from network); 29 Sep 2011 20:34:21 -0000 Received: from acsinet15.oracle.com (HELO acsinet15.oracle.com) (141.146.126.227) by server-14.tower-216.messagelabs.com with DHE-RSA-AES256-SHA encrypted SMTP; 29 Sep 2011 20:34:21 -0000 Received: from acsinet21.oracle.com (acsinet21.oracle.com [141.146.126.237]) by acsinet15.oracle.com (Switch-3.4.4/Switch-3.4.4) with ESMTP id p8TKY21G000883 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Thu, 29 Sep 2011 20:34:04 GMT Received: from acsmt357.oracle.com (acsmt357.oracle.com [141.146.40.157]) by acsinet21.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id p8TKY1gL027174 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 29 Sep 2011 20:34:01 GMT Received: from abhmt103.oracle.com (abhmt103.oracle.com [141.146.116.55]) by acsmt357.oracle.com (8.12.11.20060308/8.12.11) with ESMTP id p8TKXtjG028697; Thu, 29 Sep 2011 15:33:55 -0500 Received: from oracle.com (/207.172.105.198) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Thu, 29 Sep 2011 13:33:55 -0700 Received: by oracle.com (Postfix, from userid 1000) id 372ED1550; Thu, 29 Sep 2011 16:33:54 -0400 (EDT) From: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com> To: linux-kernel@vger.kernel.org, thellstrom@vmware.com, dri-devel@lists.freedesktop.org, bskeggs@redhat.com, j.glisse@redhat.com, thomas@shipmail.org, airlied@redhat.com, airlied@linux.ie, alexdeucher@gmail.com Date: Thu, 29 Sep 2011 16:33:47 -0400 Message-Id: <1317328432-25620-5-git-send-email-konrad.wilk@oracle.com> X-Mailer: git-send-email 1.7.4.1 In-Reply-To: <1317328432-25620-1-git-send-email-konrad.wilk@oracle.com> References: <1317328432-25620-1-git-send-email-konrad.wilk@oracle.com> X-Source-IP: acsinet21.oracle.com [141.146.126.237] X-Auth-Type: Internal IP X-CT-RefId: str=0001.0A090206.4E84D63D.0084:SCFMA922111,ss=1,re=-4.000,fgs=0 Cc: FUJITA Tomonori <fujita.tomonori@lab.ntt.co.jp>, xen-devel@lists.xensource.com, Konrad Rzeszutek Wilk <konrad.wilk@oracle.com> Subject: [Xen-devel] [PATCH 4/9] swiotlb: Expose swiotlb_nr_tlb function to modules X-BeenThere: xen-devel@lists.xensource.com X-Mailman-Version: 2.1.5 Precedence: list List-Id: Xen developer discussion <xen-devel.lists.xensource.com> List-Unsubscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe> List-Post: <mailto:xen-devel@lists.xensource.com> List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help> List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=subscribe> Sender: xen-devel-bounces@lists.xensource.com Errors-To: xen-devel-bounces@lists.xensource.com As a mechanism to detect whether SWIOTLB is enabled or not. We also fix the spelling - it was swioltb instead of swiotlb. CC: FUJITA Tomonori <fujita.tomonori@lab.ntt.co.jp> [v1: Ripped out swiotlb_enabled] Signed-off-by: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com> --- drivers/xen/swiotlb-xen.c | 2 +- include/linux/swiotlb.h | 2 +- lib/swiotlb.c | 5 +++-- 3 files changed, 5 insertions(+), 4 deletions(-) diff --git a/drivers/xen/swiotlb-xen.c b/drivers/xen/swiotlb-xen.c index 6e8c15a..cbcd8cc 100644 --- a/drivers/xen/swiotlb-xen.c +++ b/drivers/xen/swiotlb-xen.c @@ -149,7 +149,7 @@ void __init xen_swiotlb_init(int verbose) int rc; unsigned long nr_tbl; - nr_tbl = swioltb_nr_tbl(); + nr_tbl = swiotlb_nr_tbl(); if (nr_tbl) xen_io_tlb_nslabs = nr_tbl; else { diff --git a/include/linux/swiotlb.h b/include/linux/swiotlb.h index 445702c..e872526 100644 --- a/include/linux/swiotlb.h +++ b/include/linux/swiotlb.h @@ -24,7 +24,7 @@ extern int swiotlb_force; extern void swiotlb_init(int verbose); extern void swiotlb_init_with_tbl(char *tlb, unsigned long nslabs, int verbose); -extern unsigned long swioltb_nr_tbl(void); +extern unsigned long swiotlb_nr_tbl(void); /* * Enumeration for sync targets diff --git a/lib/swiotlb.c b/lib/swiotlb.c index 99093b3..058935e 100644 --- a/lib/swiotlb.c +++ b/lib/swiotlb.c @@ -110,11 +110,11 @@ setup_io_tlb_npages(char *str) __setup("swiotlb=", setup_io_tlb_npages); /* make io_tlb_overflow tunable too? */ -unsigned long swioltb_nr_tbl(void) +unsigned long swiotlb_nr_tbl(void) { return io_tlb_nslabs; } - +EXPORT_SYMBOL_GPL(swiotlb_nr_tbl); /* Note that this doesn't work with highmem page */ static dma_addr_t swiotlb_virt_to_bus(struct device *hwdev, volatile void *address) @@ -321,6 +321,7 @@ void __init swiotlb_free(void) free_bootmem_late(__pa(io_tlb_start), PAGE_ALIGN(io_tlb_nslabs << IO_TLB_SHIFT)); } + io_tlb_nslabs = 0; } static int is_swiotlb_buffer(phys_addr_t paddr) -- 1.7.4.1 _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel From xen-devel-bounces@lists.xensource.com Thu Sep 29 14:23:45 2011 Return-path: <xen-devel-bounces@lists.xensource.com> Envelope-to: www-data@lists.xensource.com Delivery-date: Thu, 29 Sep 2011 14:23:45 -0700 Received: from localhost ([127.0.0.1] helo=lists.colo.xensource.com) by lists.xensource.com with esmtp (Exim 4.43) id 1R9O52-0007ye-U1; Thu, 29 Sep 2011 14:23:44 -0700 Received: from mail27.messagelabs.com ([193.109.254.147]) by lists.xensource.com with esmtp (Exim 4.43) id 1R9O46-0007ke-OQ for xen-devel@lists.xensource.com; Thu, 29 Sep 2011 14:22:47 -0700 X-Env-Sender: Jonathan.Ludlam@eu.citrix.com X-Msg-Ref: server-7.tower-27.messagelabs.com!1317331337!50706467!1 X-Originating-IP: [66.165.176.89] X-StarScan-Version: 6.4.1; banners=-,-,- X-VirusChecked: Checked Received: (qmail 22927 invoked from network); 29 Sep 2011 21:22:18 -0000 Received: from smtp.citrix.com (HELO SMTP.CITRIX.COM) (66.165.176.89) by server-7.tower-27.messagelabs.com with RC4-SHA encrypted SMTP; 29 Sep 2011 21:22:18 -0000 X-IronPort-AV: E=Sophos;i="4.68,463,1312171200"; d="scan'208";a="17822816" Received: from ftlpmailmx02.citrite.net ([10.13.107.66]) by FTLPIPO01.CITRIX.COM with ESMTP/TLS/RC4-MD5; 29 Sep 2011 17:22:41 -0400 Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com (10.13.107.66) with Microsoft SMTP Server id 8.3.137.0; Thu, 29 Sep 2011 17:22:41 -0400 Received: from snoosnoo2.uk.xensource.com ([10.80.2.49]) by ukmail1.uk.xensource.com with esmtp (Exim 4.69) (envelope-from <jonathan.ludlam@eu.citrix.com>) id 1R9O41-0006Wb-3c; Thu, 29 Sep 2011 22:22:41 +0100 Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Mercurial-Node: c5df5f625ee2a0339b2a6785f99a5a0f9727f836 Message-ID: <c5df5f625ee2a0339b2a.1317331043@snoosnoo2.uk.xensource.com> In-Reply-To: <patchbomb.1317331042@snoosnoo2.uk.xensource.com> References: <patchbomb.1317331042@snoosnoo2.uk.xensource.com> User-Agent: Mercurial-patchbomb/1.4.3 Date: Thu, 29 Sep 2011 22:17:23 +0100 From: Jon Ludlam <jonathan.ludlam@eu.citrix.com> To: xen-devel@lists.xensource.com Cc: jonathan.ludlam@eu.citrix.com Subject: [Xen-devel] [PATCH 1 of 7] [OCAML] Rename the ocamlfind packages X-BeenThere: xen-devel@lists.xensource.com X-Mailman-Version: 2.1.5 Precedence: list List-Id: Xen developer discussion <xen-devel.lists.xensource.com> List-Unsubscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe> List-Post: <mailto:xen-devel@lists.xensource.com> List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help> List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=subscribe> Sender: xen-devel-bounces@lists.xensource.com Errors-To: xen-devel-bounces@lists.xensource.com ocamlfind does not support namespaces, so to avoid name clashes the ocamlfind package names have been changed. Note that this does not change the names of the actual modules themselves. xb becomes xenbus, xc becomes xenctrl, xl becomes xenlight, xs becomes xenstore, eventchn becomes xeneventchn. Signed-off-by: Jon Ludlam <jonathan.ludlam@eu.citrix.com> diff -r 7998217630e2 -r c5df5f625ee2 tools/ocaml/libs/eventchn/Makefile --- a/tools/ocaml/libs/eventchn/Makefile +++ b/tools/ocaml/libs/eventchn/Makefile @@ -24,12 +24,12 @@ .PHONY: install install: $(LIBS) META mkdir -p $(OCAMLDESTDIR) - ocamlfind remove -destdir $(OCAMLDESTDIR) eventchn - ocamlfind install -destdir $(OCAMLDESTDIR) -ldconf ignore eventchn META $(INTF) $(LIBS) *.a *.so *.cmx + ocamlfind remove -destdir $(OCAMLDESTDIR) xeneventchn + ocamlfind install -destdir $(OCAMLDESTDIR) -ldconf ignore xeneventchn META $(INTF) $(LIBS) *.a *.so *.cmx .PHONY: uninstall uninstall: - ocamlfind remove -destdir $(OCAMLDESTDIR) eventchn + ocamlfind remove -destdir $(OCAMLDESTDIR) xeneventchn include $(TOPLEVEL)/Makefile.rules diff -r 7998217630e2 -r c5df5f625ee2 tools/ocaml/libs/xb/Makefile --- a/tools/ocaml/libs/xb/Makefile +++ b/tools/ocaml/libs/xb/Makefile @@ -36,11 +36,11 @@ .PHONY: install install: $(LIBS) META mkdir -p $(OCAMLDESTDIR) - ocamlfind remove -destdir $(OCAMLDESTDIR) xb - ocamlfind install -destdir $(OCAMLDESTDIR) -ldconf ignore xb META $(INTF) $(LIBS) *.a *.so *.cmx + ocamlfind remove -destdir $(OCAMLDESTDIR) xenbus + ocamlfind install -destdir $(OCAMLDESTDIR) -ldconf ignore xenbus META $(INTF) $(LIBS) *.a *.so *.cmx .PHONY: uninstall uninstall: - ocamlfind remove -destdir $(OCAMLDESTDIR) xb + ocamlfind remove -destdir $(OCAMLDESTDIR) xenbus include $(TOPLEVEL)/Makefile.rules diff -r 7998217630e2 -r c5df5f625ee2 tools/ocaml/libs/xc/Makefile --- a/tools/ocaml/libs/xc/Makefile +++ b/tools/ocaml/libs/xc/Makefile @@ -23,11 +23,11 @@ .PHONY: install install: $(LIBS) META mkdir -p $(OCAMLDESTDIR) - ocamlfind remove -destdir $(OCAMLDESTDIR) xc - ocamlfind install -destdir $(OCAMLDESTDIR) -ldconf ignore xc META $(INTF) $(LIBS) *.a *.so *.cmx + ocamlfind remove -destdir $(OCAMLDESTDIR) xenctrl + ocamlfind install -destdir $(OCAMLDESTDIR) -ldconf ignore xenctrl META $(INTF) $(LIBS) *.a *.so *.cmx .PHONY: uninstall uninstall: - ocamlfind remove -destdir $(OCAMLDESTDIR) xc + ocamlfind remove -destdir $(OCAMLDESTDIR) xenctrl include $(TOPLEVEL)/Makefile.rules diff -r 7998217630e2 -r c5df5f625ee2 tools/ocaml/libs/xl/Makefile --- a/tools/ocaml/libs/xl/Makefile +++ b/tools/ocaml/libs/xl/Makefile @@ -56,11 +56,11 @@ .PHONY: install install: $(LIBS) META mkdir -p $(OCAMLDESTDIR) - ocamlfind remove -destdir $(OCAMLDESTDIR) xl - ocamlfind install -destdir $(OCAMLDESTDIR) -ldconf ignore xl META $(INTF) $(LIBS) *.a *.so *.cmx + ocamlfind remove -destdir $(OCAMLDESTDIR) xenlight + ocamlfind install -destdir $(OCAMLDESTDIR) -ldconf ignore xenlight META $(INTF) $(LIBS) *.a *.so *.cmx .PHONY: uninstall uninstall: - ocamlfind remove -destdir $(OCAMLDESTDIR) xl + ocamlfind remove -destdir $(OCAMLDESTDIR) xenlight include $(TOPLEVEL)/Makefile.rules diff -r 7998217630e2 -r c5df5f625ee2 tools/ocaml/libs/xs/Makefile --- a/tools/ocaml/libs/xs/Makefile +++ b/tools/ocaml/libs/xs/Makefile @@ -26,12 +26,12 @@ .PHONY: install install: $(LIBS) META mkdir -p $(OCAMLDESTDIR) - ocamlfind remove -destdir $(OCAMLDESTDIR) xs - ocamlfind install -destdir $(OCAMLDESTDIR) -ldconf ignore xs META $(INTF) xs.mli xst.mli xsraw.mli $(LIBS) *.a *.cmx + ocamlfind remove -destdir $(OCAMLDESTDIR) xenstore + ocamlfind install -destdir $(OCAMLDESTDIR) -ldconf ignore xenstore META $(INTF) xs.mli xst.mli xsraw.mli $(LIBS) *.a *.cmx .PHONY: uninstall uninstall: - ocamlfind remove -destdir $(OCAMLDESTDIR) xs + ocamlfind remove -destdir $(OCAMLDESTDIR) xenstore include $(TOPLEVEL)/Makefile.rules _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel From xen-devel-bounces@lists.xensource.com Thu Sep 29 14:24:58 2011 Return-path: <xen-devel-bounces@lists.xensource.com> Envelope-to: www-data@lists.xensource.com Delivery-date: Thu, 29 Sep 2011 14:24:58 -0700 Received: from localhost ([127.0.0.1] helo=lists.colo.xensource.com) by lists.xensource.com with esmtp (Exim 4.43) id 1R9O6E-0008Pw-Hl; Thu, 29 Sep 2011 14:24:58 -0700 Received: from mail27.messagelabs.com ([193.109.254.147]) by lists.xensource.com with esmtp (Exim 4.43) id 1R9O47-0007kf-6N for xen-devel@lists.xensource.com; Thu, 29 Sep 2011 14:22:47 -0700 X-Env-Sender: Jonathan.Ludlam@eu.citrix.com X-Msg-Ref: server-7.tower-27.messagelabs.com!1317331337!50706467!2 X-Originating-IP: [66.165.176.89] X-StarScan-Version: 6.4.1; banners=-,-,- X-VirusChecked: Checked Received: (qmail 22949 invoked from network); 29 Sep 2011 21:22:19 -0000 Received: from smtp.citrix.com (HELO SMTP.CITRIX.COM) (66.165.176.89) by server-7.tower-27.messagelabs.com with RC4-SHA encrypted SMTP; 29 Sep 2011 21:22:19 -0000 X-IronPort-AV: E=Sophos;i="4.68,463,1312171200"; d="scan'208";a="17822817" Received: from ftlpmailmx02.citrite.net ([10.13.107.66]) by FTLPIPO01.CITRIX.COM with ESMTP/TLS/RC4-MD5; 29 Sep 2011 17:22:41 -0400 Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com (10.13.107.66) with Microsoft SMTP Server id 8.3.137.0; Thu, 29 Sep 2011 17:22:41 -0400 Received: from snoosnoo2.uk.xensource.com ([10.80.2.49]) by ukmail1.uk.xensource.com with esmtp (Exim 4.69) (envelope-from <jonathan.ludlam@eu.citrix.com>) id 1R9O41-0006Wb-5Y; Thu, 29 Sep 2011 22:22:41 +0100 Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Mercurial-Node: abf14d22106aad906f31eb9ad38d2b981a7cbece Message-ID: <abf14d22106aad906f31.1317331049@snoosnoo2.uk.xensource.com> In-Reply-To: <patchbomb.1317331042@snoosnoo2.uk.xensource.com> References: <patchbomb.1317331042@snoosnoo2.uk.xensource.com> User-Agent: Mercurial-patchbomb/1.4.3 Date: Thu, 29 Sep 2011 22:17:29 +0100 From: Jon Ludlam <jonathan.ludlam@eu.citrix.com> To: xen-devel@lists.xensource.com Cc: jonathan.ludlam@eu.citrix.com Subject: [Xen-devel] [PATCH 7 of 7] [OCAML] Small improvement to the ocaml xenctrl library X-BeenThere: xen-devel@lists.xensource.com X-Mailman-Version: 2.1.5 Precedence: list List-Id: Xen developer discussion <xen-devel.lists.xensource.com> List-Unsubscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe> List-Post: <mailto:xen-devel@lists.xensource.com> List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help> List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=subscribe> Sender: xen-devel-bounces@lists.xensource.com Errors-To: xen-devel-bounces@lists.xensource.com Add a new field 'max_nr_cpus' to the physinfo type in the ocaml xc bindings Signed-off-by: Zheng Li <zheng.li@eu.citrix.com> diff -r 05ac32c3956c -r abf14d22106a tools/ocaml/libs/xc/xc.ml --- a/tools/ocaml/libs/xc/xc.ml +++ b/tools/ocaml/libs/xc/xc.ml @@ -70,6 +70,7 @@ scrub_pages : nativeint; (* XXX hw_cap *) capabilities : physinfo_cap_flag list; + max_nr_cpus : int; } type version = diff -r 05ac32c3956c -r abf14d22106a tools/ocaml/libs/xc/xc.mli --- a/tools/ocaml/libs/xc/xc.mli +++ b/tools/ocaml/libs/xc/xc.mli @@ -52,6 +52,7 @@ free_pages : nativeint; scrub_pages : nativeint; capabilities : physinfo_cap_flag list; + max_nr_cpus : int; (** compile-time max possible number of nr_cpus *) } type version = { major : int; minor : int; extra : string; } type compile_info = { diff -r 05ac32c3956c -r abf14d22106a tools/ocaml/libs/xc/xc_stubs.c --- a/tools/ocaml/libs/xc/xc_stubs.c +++ b/tools/ocaml/libs/xc/xc_stubs.c @@ -534,6 +534,7 @@ if (retval) failwith_xc(_H(xch)); + ring[size] = '\0'; CAMLreturn(caml_copy_string(ring)); } @@ -573,7 +574,7 @@ } } - physinfo = caml_alloc_tuple(9); + physinfo = caml_alloc_tuple(10); Store_field(physinfo, 0, Val_int(c_physinfo.threads_per_core)); Store_field(physinfo, 1, Val_int(c_physinfo.cores_per_socket)); Store_field(physinfo, 2, Val_int(c_physinfo.nr_cpus)); @@ -583,6 +584,7 @@ Store_field(physinfo, 6, caml_copy_nativeint(c_physinfo.free_pages)); Store_field(physinfo, 7, caml_copy_nativeint(c_physinfo.scrub_pages)); Store_field(physinfo, 8, cap_list); + Store_field(physinfo, 9, Val_int(c_physinfo.max_cpu_id + 1)); CAMLreturn(physinfo); } _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel From xen-devel-bounces@lists.xensource.com Thu Sep 29 14:25:53 2011 Return-path: <xen-devel-bounces@lists.xensource.com> Envelope-to: www-data@lists.xensource.com Delivery-date: Thu, 29 Sep 2011 14:25:53 -0700 Received: from localhost ([127.0.0.1] helo=lists.colo.xensource.com) by lists.xensource.com with esmtp (Exim 4.43) id 1R9O77-0000OI-77; Thu, 29 Sep 2011 14:25:53 -0700 Received: from mail27.messagelabs.com ([193.109.254.147]) by lists.xensource.com with esmtp (Exim 4.43) id 1R9O47-0007kg-QA for xen-devel@lists.xensource.com; Thu, 29 Sep 2011 14:22:48 -0700 X-Env-Sender: Jonathan.Ludlam@eu.citrix.com X-Msg-Ref: server-7.tower-27.messagelabs.com!1317331337!50706467!3 X-Originating-IP: [66.165.176.89] X-StarScan-Version: 6.4.1; banners=-,-,- X-VirusChecked: Checked Received: (qmail 22969 invoked from network); 29 Sep 2011 21:22:19 -0000 Received: from smtp.citrix.com (HELO SMTP.CITRIX.COM) (66.165.176.89) by server-7.tower-27.messagelabs.com with RC4-SHA encrypted SMTP; 29 Sep 2011 21:22:19 -0000 X-IronPort-AV: E=Sophos;i="4.68,463,1312171200"; d="scan'208";a="17822818" Received: from ftlpmailmx02.citrite.net ([10.13.107.66]) by FTLPIPO01.CITRIX.COM with ESMTP/TLS/RC4-MD5; 29 Sep 2011 17:22:41 -0400 Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com (10.13.107.66) with Microsoft SMTP Server id 8.3.137.0; Thu, 29 Sep 2011 17:22:41 -0400 Received: from snoosnoo2.uk.xensource.com ([10.80.2.49]) by ukmail1.uk.xensource.com with esmtp (Exim 4.69) (envelope-from <jonathan.ludlam@eu.citrix.com>) id 1R9O41-0006Wb-3P; Thu, 29 Sep 2011 22:22:41 +0100 Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Message-ID: <patchbomb.1317331042@snoosnoo2.uk.xensource.com> User-Agent: Mercurial-patchbomb/1.4.3 Date: Thu, 29 Sep 2011 22:17:22 +0100 From: Jon Ludlam <jonathan.ludlam@eu.citrix.com> To: xen-devel@lists.xensource.com Cc: jonathan.ludlam@eu.citrix.com Subject: [Xen-devel] [PATCH 0 of 7] Ocaml related fixes/cleanups X-BeenThere: xen-devel@lists.xensource.com X-Mailman-Version: 2.1.5 Precedence: list List-Id: Xen developer discussion <xen-devel.lists.xensource.com> List-Unsubscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe> List-Post: <mailto:xen-devel@lists.xensource.com> List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help> List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=subscribe> Sender: xen-devel-bounces@lists.xensource.com Errors-To: xen-devel-bounces@lists.xensource.com This patch series is mostly the same as that sent by Zheng Li some time ago, but split into smaller chunks. It only relates to code in the tools/ocaml subdir. The log and uuid packages are removed, and most of the remaining packages renamed to avoid namespace collisions when using ocamlfind. There are also some minor bugfixes and a small cleanup of a makefile. _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel From xen-devel-bounces@lists.xensource.com Thu Sep 29 14:26:44 2011 Return-path: <xen-devel-bounces@lists.xensource.com> Envelope-to: www-data@lists.xensource.com Delivery-date: Thu, 29 Sep 2011 14:26:44 -0700 Received: from localhost ([127.0.0.1] helo=lists.colo.xensource.com) by lists.xensource.com with esmtp (Exim 4.43) id 1R9O7w-0000m7-Cw; Thu, 29 Sep 2011 14:26:44 -0700 Received: from mail27.messagelabs.com ([193.109.254.147]) by lists.xensource.com with esmtp (Exim 4.43) id 1R9O48-0007ki-9t for xen-devel@lists.xensource.com; Thu, 29 Sep 2011 14:22:48 -0700 X-Env-Sender: Jonathan.Ludlam@eu.citrix.com X-Msg-Ref: server-7.tower-27.messagelabs.com!1317331337!50706467!4 X-Originating-IP: [66.165.176.89] X-StarScan-Version: 6.4.1; banners=-,-,- X-VirusChecked: Checked Received: (qmail 22976 invoked from network); 29 Sep 2011 21:22:20 -0000 Received: from smtp.citrix.com (HELO SMTP.CITRIX.COM) (66.165.176.89) by server-7.tower-27.messagelabs.com with RC4-SHA encrypted SMTP; 29 Sep 2011 21:22:20 -0000 X-IronPort-AV: E=Sophos;i="4.68,463,1312171200"; d="scan'208";a="17822819" Received: from ftlpmailmx02.citrite.net ([10.13.107.66]) by FTLPIPO01.CITRIX.COM with ESMTP/TLS/RC4-MD5; 29 Sep 2011 17:22:41 -0400 Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com (10.13.107.66) with Microsoft SMTP Server id 8.3.137.0; Thu, 29 Sep 2011 17:22:41 -0400 Received: from snoosnoo2.uk.xensource.com ([10.80.2.49]) by ukmail1.uk.xensource.com with esmtp (Exim 4.69) (envelope-from <jonathan.ludlam@eu.citrix.com>) id 1R9O41-0006Wb-4W; Thu, 29 Sep 2011 22:22:41 +0100 Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Mercurial-Node: b6022a18ebb012b8af85ee2d1a61b4f6db6389e4 Message-ID: <b6022a18ebb012b8af85.1317331046@snoosnoo2.uk.xensource.com> In-Reply-To: <patchbomb.1317331042@snoosnoo2.uk.xensource.com> References: <patchbomb.1317331042@snoosnoo2.uk.xensource.com> User-Agent: Mercurial-patchbomb/1.4.3 Date: Thu, 29 Sep 2011 22:17:26 +0100 From: Jon Ludlam <jonathan.ludlam@eu.citrix.com> To: xen-devel@lists.xensource.com Cc: jonathan.ludlam@eu.citrix.com Subject: [Xen-devel] [PATCH 4 of 7] [OCAML] Fix a problem with ocaml xenstored X-BeenThere: xen-devel@lists.xensource.com X-Mailman-Version: 2.1.5 Precedence: list List-Id: Xen developer discussion <xen-devel.lists.xensource.com> List-Unsubscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe> List-Post: <mailto:xen-devel@lists.xensource.com> List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help> List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=subscribe> Sender: xen-devel-bounces@lists.xensource.com Errors-To: xen-devel-bounces@lists.xensource.com Have xenstored trigger an @introduceDomain event even if the introduce call tries to introduce an already existing domain. Signed-off-by: Thomas Gazagnaire <thomas@ocamlpro.com> Acked-by: Jon Ludlam <jonathan.ludlam@eu.citrix.com> diff -r 734cb0807357 -r b6022a18ebb0 tools/ocaml/xenstored/process.ml --- a/tools/ocaml/xenstored/process.ml +++ b/tools/ocaml/xenstored/process.ml @@ -168,9 +168,10 @@ | _ -> raise Invalid_Cmd_Args; in let dom = - if Domains.exist domains domid then + if Domains.exist domains domid then begin + Connections.fire_spec_watches cons "@introduceDomain"; Domains.find domains domid - else try + end else try let ndom = Xc.with_intf (fun xc -> Domains.create xc domains domid mfn port) in Connections.add_domain cons ndom; _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel From xen-devel-bounces@lists.xensource.com Thu Sep 29 14:27:37 2011 Return-path: <xen-devel-bounces@lists.xensource.com> Envelope-to: www-data@lists.xensource.com Delivery-date: Thu, 29 Sep 2011 14:27:37 -0700 Received: from localhost ([127.0.0.1] helo=lists.colo.xensource.com) by lists.xensource.com with esmtp (Exim 4.43) id 1R9O8n-0001AC-5i; Thu, 29 Sep 2011 14:27:37 -0700 Received: from mail174.messagelabs.com ([85.158.138.51]) by lists.xensource.com with esmtp (Exim 4.43) id 1R9O48-0007kj-RP for xen-devel@lists.xensource.com; Thu, 29 Sep 2011 14:22:51 -0700 X-Env-Sender: Jonathan.Ludlam@eu.citrix.com X-Msg-Ref: server-15.tower-174.messagelabs.com!1317331363!26947229!1 X-Originating-IP: [66.165.176.89] X-StarScan-Version: 6.4.1; banners=-,-,- X-VirusChecked: Checked Received: (qmail 23907 invoked from network); 29 Sep 2011 21:22:45 -0000 Received: from smtp.citrix.com (HELO SMTP.CITRIX.COM) (66.165.176.89) by server-15.tower-174.messagelabs.com with RC4-SHA encrypted SMTP; 29 Sep 2011 21:22:45 -0000 X-IronPort-AV: E=Sophos;i="4.68,463,1312171200"; d="scan'208";a="17822820" Received: from ftlpmailmx02.citrite.net ([10.13.107.66]) by FTLPIPO01.CITRIX.COM with ESMTP/TLS/RC4-MD5; 29 Sep 2011 17:22:41 -0400 Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com (10.13.107.66) with Microsoft SMTP Server id 8.3.137.0; Thu, 29 Sep 2011 17:22:41 -0400 Received: from snoosnoo2.uk.xensource.com ([10.80.2.49]) by ukmail1.uk.xensource.com with esmtp (Exim 4.69) (envelope-from <jonathan.ludlam@eu.citrix.com>) id 1R9O41-0006Wb-53; Thu, 29 Sep 2011 22:22:41 +0100 Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Mercurial-Node: 05ac32c3956c0e1584c2e08523744a0308f9c1e5 Message-ID: <05ac32c3956c0e1584c2.1317331048@snoosnoo2.uk.xensource.com> In-Reply-To: <patchbomb.1317331042@snoosnoo2.uk.xensource.com> References: <patchbomb.1317331042@snoosnoo2.uk.xensource.com> User-Agent: Mercurial-patchbomb/1.4.3 Date: Thu, 29 Sep 2011 22:17:28 +0100 From: Jon Ludlam <jonathan.ludlam@eu.citrix.com> To: xen-devel@lists.xensource.com Cc: jonathan.ludlam@eu.citrix.com Subject: [Xen-devel] [PATCH 6 of 7] [OCAML] Fix 2 bit-twiddling bugs and an off-by-one X-BeenThere: xen-devel@lists.xensource.com X-Mailman-Version: 2.1.5 Precedence: list List-Id: Xen developer discussion <xen-devel.lists.xensource.com> List-Unsubscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe> List-Post: <mailto:xen-devel@lists.xensource.com> List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help> List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=subscribe> Sender: xen-devel-bounces@lists.xensource.com Errors-To: xen-devel-bounces@lists.xensource.com The bit bugs are in ocaml vcpu affinity calls, and the off-by-one error is in the ocaml console ring code Signed-off-by: Zheng Li <zheng.li@eu.citrix.com> Acked-by: Jon Ludlam <jonathan.ludlam@eu.citrix.com> diff -r 48d4f312d069 -r 05ac32c3956c tools/ocaml/libs/xc/xc_stubs.c --- a/tools/ocaml/libs/xc/xc_stubs.c +++ b/tools/ocaml/libs/xc/xc_stubs.c @@ -430,7 +430,7 @@ for (i=0; i<len; i++) { if (Bool_val(Field(cpumap, i))) - c_cpumap[i/8] |= i << (i&7); + c_cpumap[i/8] |= 1 << (i&7); } retval = xc_vcpu_setaffinity(_H(xch), _D(domid), Int_val(vcpu), c_cpumap); @@ -466,7 +466,7 @@ ret = caml_alloc(len, 0); for (i=0; i<len; i++) { - if (c_cpumap[i%8] & 1 << (i&7)) + if (c_cpumap[i/8] & 1 << (i&7)) Store_field(ret, i, Val_true); else Store_field(ret, i, Val_false); @@ -523,7 +523,7 @@ CAMLprim value stub_xc_readconsolering(value xch) { - unsigned int size = RING_SIZE; + unsigned int size = RING_SIZE - 1; char *ring_ptr = ring; CAMLparam1(xch); _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel From xen-devel-bounces@lists.xensource.com Thu Sep 29 14:28:23 2011 Return-path: <xen-devel-bounces@lists.xensource.com> Envelope-to: www-data@lists.xensource.com Delivery-date: Thu, 29 Sep 2011 14:28:23 -0700 Received: from localhost ([127.0.0.1] helo=lists.colo.xensource.com) by lists.xensource.com with esmtp (Exim 4.43) id 1R9O9X-0001YH-Ld; Thu, 29 Sep 2011 14:28:23 -0700 Received: from mail27.messagelabs.com ([193.109.254.147]) by lists.xensource.com with esmtp (Exim 4.43) id 1R9O48-0007kk-VG for xen-devel@lists.xensource.com; Thu, 29 Sep 2011 14:22:51 -0700 X-Env-Sender: Jonathan.Ludlam@eu.citrix.com X-Msg-Ref: server-7.tower-27.messagelabs.com!1317331337!50706467!5 X-Originating-IP: [66.165.176.89] X-StarScan-Version: 6.4.1; banners=-,-,- X-VirusChecked: Checked Received: (qmail 22989 invoked from network); 29 Sep 2011 21:22:21 -0000 Received: from smtp.citrix.com (HELO SMTP.CITRIX.COM) (66.165.176.89) by server-7.tower-27.messagelabs.com with RC4-SHA encrypted SMTP; 29 Sep 2011 21:22:21 -0000 X-IronPort-AV: E=Sophos;i="4.68,463,1312171200"; d="scan'208";a="17822821" Received: from ftlpmailmx02.citrite.net ([10.13.107.66]) by FTLPIPO01.CITRIX.COM with ESMTP/TLS/RC4-MD5; 29 Sep 2011 17:22:41 -0400 Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com (10.13.107.66) with Microsoft SMTP Server id 8.3.137.0; Thu, 29 Sep 2011 17:22:41 -0400 Received: from snoosnoo2.uk.xensource.com ([10.80.2.49]) by ukmail1.uk.xensource.com with esmtp (Exim 4.69) (envelope-from <jonathan.ludlam@eu.citrix.com>) id 1R9O41-0006Wb-4n; Thu, 29 Sep 2011 22:22:41 +0100 Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Mercurial-Node: 48d4f312d0693cf8a52e0a077a05f3c4786d8de8 Message-ID: <48d4f312d0693cf8a52e.1317331047@snoosnoo2.uk.xensource.com> In-Reply-To: <patchbomb.1317331042@snoosnoo2.uk.xensource.com> References: <patchbomb.1317331042@snoosnoo2.uk.xensource.com> User-Agent: Mercurial-patchbomb/1.4.3 Date: Thu, 29 Sep 2011 22:17:27 +0100 From: Jon Ludlam <jonathan.ludlam@eu.citrix.com> To: xen-devel@lists.xensource.com Cc: jonathan.ludlam@eu.citrix.com Subject: [Xen-devel] [PATCH 5 of 7] [OCAML] Minor makefile cleanup X-BeenThere: xen-devel@lists.xensource.com X-Mailman-Version: 2.1.5 Precedence: list List-Id: Xen developer discussion <xen-devel.lists.xensource.com> List-Unsubscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe> List-Post: <mailto:xen-devel@lists.xensource.com> List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help> List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=subscribe> Sender: xen-devel-bounces@lists.xensource.com Errors-To: xen-devel-bounces@lists.xensource.com Signed-off-by: Zheng Li <zheng.li@eu.citrix.com> Acked-by: Jon Ludlam <jonathan.ludlam@eu.citrix.com> diff -r b6022a18ebb0 -r 48d4f312d069 tools/ocaml/Makefile.rules --- a/tools/ocaml/Makefile.rules +++ b/tools/ocaml/Makefile.rules @@ -52,20 +52,20 @@ mk-caml-lib-native = $(call quiet-command, $(OCAMLOPT) $(OCAMLOPTFLAGS) -a -o $1 $2 $3,MLA,$1) mk-caml-lib-bytecode = $(call quiet-command, $(OCAMLC) $(OCAMLCFLAGS) -a -o $1 $2 $3,MLA,$1) -mk-caml-stubs = $(call quiet-command, $(OCAMLMKLIB) -o `basename $1 .a` $2,MKLIB,$1) +mk-caml-stubs = $(call quiet-command, $(OCAMLMKLIB) $(LIBS_$(1)) -o $(1)_stubs $2,MKLIB,$1) mk-caml-lib-stubs = \ - $(call quiet-command, $(AR) rcs $1 $2 && $(OCAMLMKLIB) -o `basename $1 .a | sed -e 's/^lib//'` $2,MKLIB,$1) + $(call quiet-command, $(AR) rcs lib$(1)_stubs.a $2 && $(OCAMLMKLIB) $(LIBS_$(1)) -o $(1)_stubs $2,MKLIB,$1) # define a library target <name>.cmxa and <name>.cma define OCAML_LIBRARY_template $(1).cmxa: lib$(1)_stubs.a $(foreach obj,$($(1)_OBJS),$(obj).cmx) $(call mk-caml-lib-native,$$@, -cclib -l$(1)_stubs $(foreach lib,$(LIBS_$(1)),-cclib $(lib)), $(foreach obj,$($(1)_OBJS),$(obj).cmx)) $(1).cma: $(foreach obj,$($(1)_OBJS),$(obj).cmo) - $(call mk-caml-lib-bytecode,$$@, -dllib dll$(1)_stubs.so -cclib -l$(1)_stubs, $$+) + $(call mk-caml-lib-bytecode,$$@, -dllib dll$(1)_stubs.so -cclib -l$(1)_stubs $(foreach lib,$(LIBS_$(1)),-cclib $(lib)), $$+) $(1)_stubs.a: $(foreach obj,$$($(1)_C_OBJS),$(obj).o) - $(call mk-caml-stubs,$$@, $$+) + $(call mk-caml-stubs,$(1), $$+) lib$(1)_stubs.a: $(foreach obj,$($(1)_C_OBJS),$(obj).o) - $(call mk-caml-lib-stubs,$$@, $$+) + $(call mk-caml-lib-stubs,$(1), $$+) endef define OCAML_NOC_LIBRARY_template diff -r b6022a18ebb0 -r 48d4f312d069 tools/ocaml/libs/eventchn/Makefile --- a/tools/ocaml/libs/eventchn/Makefile +++ b/tools/ocaml/libs/eventchn/Makefile @@ -8,7 +8,7 @@ INTF = $(foreach obj, $(OBJS),$(obj).cmi) LIBS = eventchn.cma eventchn.cmxa -LIBS_evtchn = $(LDLIBS_libxenctrl) +LIBS_eventchn = -L$(XEN_ROOT)/tools/libxc -lxenctrl all: $(INTF) $(LIBS) $(PROGRAMS) _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel From xen-devel-bounces@lists.xensource.com Thu Sep 29 14:29:10 2011 Return-path: <xen-devel-bounces@lists.xensource.com> Envelope-to: www-data@lists.xensource.com Delivery-date: Thu, 29 Sep 2011 14:29:10 -0700 Received: from localhost ([127.0.0.1] helo=lists.colo.xensource.com) by lists.xensource.com with esmtp (Exim 4.43) id 1R9OAI-0001vn-8J; Thu, 29 Sep 2011 14:29:10 -0700 Received: from mail174.messagelabs.com ([85.158.138.51]) by lists.xensource.com with esmtp (Exim 4.43) id 1R9O49-0007kl-Af for xen-devel@lists.xensource.com; Thu, 29 Sep 2011 14:22:52 -0700 X-Env-Sender: Jonathan.Ludlam@eu.citrix.com X-Msg-Ref: server-15.tower-174.messagelabs.com!1317331363!26947229!2 X-Originating-IP: [66.165.176.89] X-StarScan-Version: 6.4.1; banners=-,-,- X-VirusChecked: Checked Received: (qmail 23913 invoked from network); 29 Sep 2011 21:22:45 -0000 Received: from smtp.citrix.com (HELO SMTP.CITRIX.COM) (66.165.176.89) by server-15.tower-174.messagelabs.com with RC4-SHA encrypted SMTP; 29 Sep 2011 21:22:45 -0000 X-IronPort-AV: E=Sophos;i="4.68,463,1312171200"; d="scan'208";a="17822822" Received: from ftlpmailmx02.citrite.net ([10.13.107.66]) by FTLPIPO01.CITRIX.COM with ESMTP/TLS/RC4-MD5; 29 Sep 2011 17:22:42 -0400 Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com (10.13.107.66) with Microsoft SMTP Server id 8.3.137.0; Thu, 29 Sep 2011 17:22:41 -0400 Received: from snoosnoo2.uk.xensource.com ([10.80.2.49]) by ukmail1.uk.xensource.com with esmtp (Exim 4.69) (envelope-from <jonathan.ludlam@eu.citrix.com>) id 1R9O41-0006Wb-3n; Thu, 29 Sep 2011 22:22:41 +0100 Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Mercurial-Node: 42cdb34ec175602fa2d8f0f65e44c4eb3a086496 Message-ID: <42cdb34ec175602fa2d8.1317331044@snoosnoo2.uk.xensource.com> In-Reply-To: <patchbomb.1317331042@snoosnoo2.uk.xensource.com> References: <patchbomb.1317331042@snoosnoo2.uk.xensource.com> User-Agent: Mercurial-patchbomb/1.4.3 Date: Thu, 29 Sep 2011 22:17:24 +0100 From: Jon Ludlam <jonathan.ludlam@eu.citrix.com> To: xen-devel@lists.xensource.com Cc: jonathan.ludlam@eu.citrix.com Subject: [Xen-devel] [PATCH 2 of 7] [OCAML] Remove the uuid library X-BeenThere: xen-devel@lists.xensource.com X-Mailman-Version: 2.1.5 Precedence: list List-Id: Xen developer discussion <xen-devel.lists.xensource.com> List-Unsubscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe> List-Post: <mailto:xen-devel@lists.xensource.com> List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help> List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=subscribe> Sender: xen-devel-bounces@lists.xensource.com Errors-To: xen-devel-bounces@lists.xensource.com The library was only minimally used, and was really rather redundant. Signed-off-by: Zheng Li <zheng.li@eu.citrix.com> Acked-by: Jon Ludlam <jonathan.ludlam@eu.citrix.com> diff -r c5df5f625ee2 -r 42cdb34ec175 tools/ocaml/libs/Makefile --- a/tools/ocaml/libs/Makefile +++ b/tools/ocaml/libs/Makefile @@ -2,7 +2,7 @@ include $(XEN_ROOT)/tools/Rules.mk SUBDIRS= \ - uuid mmap \ + mmap \ log xc eventchn \ xb xs xl diff -r c5df5f625ee2 -r 42cdb34ec175 tools/ocaml/libs/uuid/META.in --- a/tools/ocaml/libs/uuid/META.in +++ /dev/null @@ -1,4 +0,0 @@ -version = "@VERSION@" -description = "Uuid - universal identifer" -archive(byte) = "uuid.cma" -archive(native) = "uuid.cmxa" diff -r c5df5f625ee2 -r 42cdb34ec175 tools/ocaml/libs/uuid/Makefile --- a/tools/ocaml/libs/uuid/Makefile +++ /dev/null @@ -1,29 +0,0 @@ -TOPLEVEL=$(CURDIR)/../.. -XEN_ROOT=$(TOPLEVEL)/../.. -include $(TOPLEVEL)/common.make - -OBJS = uuid -INTF = $(foreach obj, $(OBJS),$(obj).cmi) -LIBS = uuid.cma uuid.cmxa - -all: $(INTF) $(LIBS) $(PROGRAMS) - -bins: $(PROGRAMS) - -libs: $(LIBS) - -uuid_OBJS = $(OBJS) -OCAML_NOC_LIBRARY = uuid - -.PHONY: install -install: $(LIBS) META - mkdir -p $(OCAMLDESTDIR) - ocamlfind remove -destdir $(OCAMLDESTDIR) uuid - ocamlfind install -destdir $(OCAMLDESTDIR) -ldconf ignore uuid META $(INTF) $(LIBS) *.a *.cmx - -.PHONY: uninstall -uninstall: - ocamlfind remove -destdir $(OCAMLDESTDIR) uuid - -include $(TOPLEVEL)/Makefile.rules - diff -r c5df5f625ee2 -r 42cdb34ec175 tools/ocaml/libs/uuid/uuid.ml --- a/tools/ocaml/libs/uuid/uuid.ml +++ /dev/null @@ -1,100 +0,0 @@ -(* - * Copyright (C) 2006-2010 Citrix Systems Inc. - * Author Vincent Hanquez <vincent.hanquez@eu.citrix.com> - * - * This program is free software; you can redistribute it and/or modify - * it under the terms of the GNU Lesser General Public License as published - * by the Free Software Foundation; version 2.1 only. with the special - * exception on linking described in file LICENSE. - * - * This program is distributed in the hope that it will be useful, - * but WITHOUT ANY WARRANTY; without even the implied warranty of - * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the - * GNU Lesser General Public License for more details. - *) - -(* Internally, a UUID is simply a string. *) -type 'a t = string - -type cookie = string - -let of_string s = s -let to_string s = s - -let null = "" - -(* deprecated: we don't need to duplicate the uuid prefix/suffix *) -let uuid_of_string = of_string -let string_of_uuid = to_string - -let string_of_cookie s = s - -let cookie_of_string s = s - -let dev_random = "/dev/random" -let dev_urandom = "/dev/urandom" - -let rnd_array n = - let fstbyte i = 0xff land i in - let sndbyte i = fstbyte (i lsr 8) in - let thdbyte i = sndbyte (i lsr 8) in - let rec rnd_list n acc = match n with - | 0 -> acc - | 1 -> - let b = fstbyte (Random.bits ()) in - b :: acc - | 2 -> - let r = Random.bits () in - let b1 = fstbyte r in - let b2 = sndbyte r in - b1 :: b2 :: acc - | n -> - let r = Random.bits () in - let b1 = fstbyte r in - let b2 = sndbyte r in - let b3 = thdbyte r in - rnd_list (n - 3) (b1 :: b2 :: b3 :: acc) - in - Array.of_list (rnd_list n []) - -let read_array dev n = - let ic = open_in_bin dev in - try - let result = Array.init n (fun _ -> input_byte ic) in - close_in ic; - result - with e -> - close_in ic; - raise e - -let uuid_of_int_array uuid = - Printf.sprintf "%02x%02x%02x%02x-%02x%02x-%02x%02x-%02x%02x-%02x%02x%02x%02x%02x%02x" - uuid.(0) uuid.(1) uuid.(2) uuid.(3) uuid.(4) uuid.(5) - uuid.(6) uuid.(7) uuid.(8) uuid.(9) uuid.(10) uuid.(11) - uuid.(12) uuid.(13) uuid.(14) uuid.(15) - -let make_uuid_prng () = uuid_of_int_array (rnd_array 16) -let make_uuid_urnd () = uuid_of_int_array (read_array dev_urandom 16) -let make_uuid_rnd () = uuid_of_int_array (read_array dev_random 16) -let make_uuid = make_uuid_urnd - -let make_cookie() = - let bytes = Array.to_list (read_array dev_urandom 64) in - String.concat "" (List.map (Printf.sprintf "%1x") bytes) - -let int_array_of_uuid s = - try - let l = ref [] in - Scanf.sscanf s "%02x%02x%02x%02x-%02x%02x-%02x%02x-%02x%02x-%02x%02x%02x%02x%02x%02x" - (fun a0 a1 a2 a3 a4 a5 a6 a7 a8 a9 a10 a11 a12 a13 a14 a15 -> - l := [ a0; a1; a2; a3; a4; a5; a6; a7; a8; a9; - a10; a11; a12; a13; a14; a15; ]); - Array.of_list !l - with _ -> invalid_arg "Uuid.int_array_of_uuid" - -let is_uuid str = - try - Scanf.sscanf str - "%02x%02x%02x%02x-%02x%02x-%02x%02x-%02x%02x-%02x%02x%02x%02x%02x%02x" - (fun _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ -> true) - with _ -> false diff -r c5df5f625ee2 -r 42cdb34ec175 tools/ocaml/libs/uuid/uuid.mli --- a/tools/ocaml/libs/uuid/uuid.mli +++ /dev/null @@ -1,67 +0,0 @@ -(* - * Copyright (C) 2006-2010 Citrix Systems Inc. - * Author Vincent Hanquez <vincent.hanquez@eu.citrix.com> - * - * This program is free software; you can redistribute it and/or modify - * it under the terms of the GNU Lesser General Public License as published - * by the Free Software Foundation; version 2.1 only. with the special - * exception on linking described in file LICENSE. - * - * This program is distributed in the hope that it will be useful, - * but WITHOUT ANY WARRANTY; without even the implied warranty of - * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the - * GNU Lesser General Public License for more details. - *) -(** Type-safe UUIDs. - Probably need to refactor this; UUIDs are used in two places: - + to uniquely name things across the cluster - + as secure session IDs - - There is the additional constraint that current Xen tools use - a particular format of UUID (the 16 byte variety generated by fresh ()) - - Also, cookies aren't UUIDs and should be put somewhere else. -*) - -(** A 128-bit UUID. Using phantom types ('a) to achieve the requires type-safety. *) -type 'a t - -(** Create a fresh UUID *) -val make_uuid : unit -> 'a t -val make_uuid_prng : unit -> 'a t -val make_uuid_urnd : unit -> 'a t -val make_uuid_rnd : unit -> 'a t - -(** Create a UUID from a string. *) -val of_string : string -> 'a t - -(** Marshal a UUID to a string. *) -val to_string : 'a t -> string - -(** A null UUID, as if such a thing actually existed. It turns out to be - * useful though. *) -val null : 'a t - -(** Deprecated alias for {! Uuid.of_string} *) -val uuid_of_string : string -> 'a t - -(** Deprecated alias for {! Uuid.to_string} *) -val string_of_uuid : 'a t -> string - -(** Convert an array to a UUID. *) -val uuid_of_int_array : int array -> 'a t - -(** Convert a UUID to an array. *) -val int_array_of_uuid : 'a t -> int array - -(** Check whether a string is a UUID. *) -val is_uuid : string -> bool - -(** A 512-bit cookie. *) -type cookie - -val make_cookie : unit -> cookie - -val cookie_of_string : string -> cookie - -val string_of_cookie : cookie -> string diff -r c5df5f625ee2 -r 42cdb34ec175 tools/ocaml/libs/xb/Makefile --- a/tools/ocaml/libs/xb/Makefile +++ b/tools/ocaml/libs/xb/Makefile @@ -31,7 +31,7 @@ %.mli: %.ml $(E) " MLI $@" - $(Q)$(OCAMLC) -i $< $o + $(Q)$(OCAMLC) $(OCAMLCFLAGS) -i $< $o .PHONY: install install: $(LIBS) META diff -r c5df5f625ee2 -r 42cdb34ec175 tools/ocaml/libs/xc/META.in --- a/tools/ocaml/libs/xc/META.in +++ b/tools/ocaml/libs/xc/META.in @@ -1,5 +1,5 @@ version = "@VERSION@" description = "Xen Control Interface" -requires = "mmap,uuid" +requires = "unix,mmap" archive(byte) = "xc.cma" archive(native) = "xc.cmxa" diff -r c5df5f625ee2 -r 42cdb34ec175 tools/ocaml/libs/xc/Makefile --- a/tools/ocaml/libs/xc/Makefile +++ b/tools/ocaml/libs/xc/Makefile @@ -3,7 +3,7 @@ include $(TOPLEVEL)/common.make CFLAGS += -I../mmap $(CFLAGS_libxenctrl) $(CFLAGS_libxenguest) -OCAMLINCLUDE += -I ../mmap -I ../uuid +OCAMLINCLUDE += -I ../mmap OBJS = xc INTF = xc.cmi diff -r c5df5f625ee2 -r 42cdb34ec175 tools/ocaml/libs/xc/xc.ml --- a/tools/ocaml/libs/xc/xc.ml +++ b/tools/ocaml/libs/xc/xc.ml @@ -118,14 +118,23 @@ external _domain_create: handle -> int32 -> domain_create_flag list -> int array -> domid = "stub_xc_domain_create" +let int_array_of_uuid_string s = + try + Scanf.sscanf s + "%02x%02x%02x%02x-%02x%02x-%02x%02x-%02x%02x-%02x%02x%02x%02x%02x%02x" + (fun a0 a1 a2 a3 a4 a5 a6 a7 a8 a9 a10 a11 a12 a13 a14 a15 -> + [| a0; a1; a2; a3; a4; a5; a6; a7; + a8; a9; a10; a11; a12; a13; a14; a15 |]) + with _ -> invalid_arg ("Xc.int_array_of_uuid_string: " ^ s) + let domain_create handle n flags uuid = - _domain_create handle n flags (Uuid.int_array_of_uuid uuid) + _domain_create handle n flags (int_array_of_uuid_string uuid) external _domain_sethandle: handle -> domid -> int array -> unit = "stub_xc_domain_sethandle" let domain_sethandle handle n uuid = - _domain_sethandle handle n (Uuid.int_array_of_uuid uuid) + _domain_sethandle handle n (int_array_of_uuid_string uuid) external domain_max_vcpus: handle -> domid -> int -> unit = "stub_xc_domain_max_vcpus" diff -r c5df5f625ee2 -r 42cdb34ec175 tools/ocaml/libs/xc/xc.mli --- a/tools/ocaml/libs/xc/xc.mli +++ b/tools/ocaml/libs/xc/xc.mli @@ -74,12 +74,8 @@ external is_fake : unit -> bool = "stub_xc_interface_is_fake" external interface_close : handle -> unit = "stub_xc_interface_close" val with_intf : (handle -> 'a) -> 'a -external _domain_create : handle -> int32 -> domain_create_flag list -> int array -> domid - = "stub_xc_domain_create" -val domain_create : handle -> int32 -> domain_create_flag list -> 'a Uuid.t -> domid -external _domain_sethandle : handle -> domid -> int array -> unit - = "stub_xc_domain_sethandle" -val domain_sethandle : handle -> domid -> 'a Uuid.t -> unit +val domain_create : handle -> int32 -> domain_create_flag list -> string -> domid +val domain_sethandle : handle -> domid -> string -> unit external domain_max_vcpus : handle -> domid -> int -> unit = "stub_xc_domain_max_vcpus" external domain_pause : handle -> domid -> unit = "stub_xc_domain_pause" diff -r c5df5f625ee2 -r 42cdb34ec175 tools/ocaml/xenstored/Makefile --- a/tools/ocaml/xenstored/Makefile +++ b/tools/ocaml/xenstored/Makefile @@ -5,7 +5,6 @@ OCAMLINCLUDE += \ -I $(OCAML_TOPLEVEL)/libs/log \ -I $(OCAML_TOPLEVEL)/libs/xb \ - -I $(OCAML_TOPLEVEL)/libs/uuid \ -I $(OCAML_TOPLEVEL)/libs/mmap \ -I $(OCAML_TOPLEVEL)/libs/xc \ -I $(OCAML_TOPLEVEL)/libs/eventchn @@ -34,7 +33,6 @@ INTF = symbol.cmi trie.cmi XENSTOREDLIBS = \ unix.cmxa \ - $(OCAML_TOPLEVEL)/libs/uuid/uuid.cmxa \ -ccopt -L -ccopt $(OCAML_TOPLEVEL)/libs/mmap $(OCAML_TOPLEVEL)/libs/mmap/mmap.cmxa \ -ccopt -L -ccopt $(OCAML_TOPLEVEL)/libs/log $(OCAML_TOPLEVEL)/libs/log/log.cmxa \ -ccopt -L -ccopt $(OCAML_TOPLEVEL)/libs/eventchn $(OCAML_TOPLEVEL)/libs/eventchn/eventchn.cmxa \ _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel From xen-devel-bounces@lists.xensource.com Thu Sep 29 14:30:16 2011 Return-path: <xen-devel-bounces@lists.xensource.com> Envelope-to: www-data@lists.xensource.com Delivery-date: Thu, 29 Sep 2011 14:30:16 -0700 Received: from localhost ([127.0.0.1] helo=lists.colo.xensource.com) by lists.xensource.com with esmtp (Exim 4.43) id 1R9OBM-0002Jh-BF; Thu, 29 Sep 2011 14:30:16 -0700 Received: from mail21.messagelabs.com ([85.158.143.35]) by lists.xensource.com with esmtp (Exim 4.43) id 1R9O48-0007kh-3Q for xen-devel@lists.xensource.com; Thu, 29 Sep 2011 14:22:52 -0700 X-Env-Sender: Jonathan.Ludlam@eu.citrix.com X-Msg-Ref: server-2.tower-21.messagelabs.com!1317331360!36032107!1 X-Originating-IP: [66.165.176.63] X-StarScan-Version: 6.4.1; banners=-,-,- X-VirusChecked: Checked Received: (qmail 17845 invoked from network); 29 Sep 2011 21:22:42 -0000 Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63) by server-2.tower-21.messagelabs.com with RC4-SHA encrypted SMTP; 29 Sep 2011 21:22:42 -0000 X-IronPort-AV: E=Sophos;i="4.68,463,1312171200"; d="scan'208";a="165208277" Received: from ftlpmailmx02.citrite.net ([10.13.107.66]) by FTLPIPO02.CITRIX.COM with ESMTP/TLS/RC4-MD5; 29 Sep 2011 17:22:42 -0400 Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com (10.13.107.66) with Microsoft SMTP Server id 8.3.137.0; Thu, 29 Sep 2011 17:22:41 -0400 Received: from snoosnoo2.uk.xensource.com ([10.80.2.49]) by ukmail1.uk.xensource.com with esmtp (Exim 4.69) (envelope-from <jonathan.ludlam@eu.citrix.com>) id 1R9O41-0006Wb-40; Thu, 29 Sep 2011 22:22:41 +0100 Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Mercurial-Node: 734cb0807357806d33be6b269e5303c9ae500fec Message-ID: <734cb0807357806d33be.1317331045@snoosnoo2.uk.xensource.com> In-Reply-To: <patchbomb.1317331042@snoosnoo2.uk.xensource.com> References: <patchbomb.1317331042@snoosnoo2.uk.xensource.com> User-Agent: Mercurial-patchbomb/1.4.3 Date: Thu, 29 Sep 2011 22:17:25 +0100 From: Jon Ludlam <jonathan.ludlam@eu.citrix.com> To: xen-devel@lists.xensource.com Cc: jonathan.ludlam@eu.citrix.com Subject: [Xen-devel] [PATCH 3 of 7] [OCAML] Remove log library from tools/ocaml/libs X-BeenThere: xen-devel@lists.xensource.com X-Mailman-Version: 2.1.5 Precedence: list List-Id: Xen developer discussion <xen-devel.lists.xensource.com> List-Unsubscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe> List-Post: <mailto:xen-devel@lists.xensource.com> List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help> List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=subscribe> Sender: xen-devel-bounces@lists.xensource.com Errors-To: xen-devel-bounces@lists.xensource.com The only user was oxenstored, which has had the relevant bits merged in. Signed-off-by: Zheng Li <zheng.li@eu.citrix.com> Acked-by: Jon Ludlam <jonathan.ludlam@eu.citrix.com> diff -r 42cdb34ec175 -r 734cb0807357 tools/ocaml/libs/Makefile --- a/tools/ocaml/libs/Makefile +++ b/tools/ocaml/libs/Makefile @@ -3,7 +3,7 @@ SUBDIRS= \ mmap \ - log xc eventchn \ + xc eventchn \ xb xs xl .PHONY: all diff -r 42cdb34ec175 -r 734cb0807357 tools/ocaml/libs/log/META.in --- a/tools/ocaml/libs/log/META.in +++ /dev/null @@ -1,5 +0,0 @@ -version = "@VERSION@" -description = "Log - logging library" -requires = "unix" -archive(byte) = "log.cma" -archive(native) = "log.cmxa" diff -r 42cdb34ec175 -r 734cb0807357 tools/ocaml/libs/log/Makefile --- a/tools/ocaml/libs/log/Makefile +++ /dev/null @@ -1,44 +0,0 @@ -TOPLEVEL=$(CURDIR)/../.. -XEN_ROOT=$(TOPLEVEL)/../.. -include $(TOPLEVEL)/common.make - -OBJS = syslog log logs -INTF = log.cmi logs.cmi syslog.cmi -LIBS = log.cma log.cmxa - -all: $(INTF) $(LIBS) $(PROGRAMS) - -bins: $(PROGRAMS) - -libs: $(LIBS) - -log.cmxa: libsyslog_stubs.a $(foreach obj,$(OBJS),$(obj).cmx) - $(call mk-caml-lib-native, $@, -cclib -lsyslog_stubs, $(foreach obj,$(OBJS),$(obj).cmx)) - -log.cma: $(foreach obj,$(OBJS),$(obj).cmo) - $(call mk-caml-lib-bytecode, $@, -dllib dllsyslog_stubs.so -cclib -lsyslog_stubs, $(foreach obj,$(OBJS),$(obj).cmo)) - -syslog_stubs.a: syslog_stubs.o - $(call mk-caml-stubs, $@, $+) - -libsyslog_stubs.a: syslog_stubs.o - $(call mk-caml-lib-stubs, $@, $+) - -logs.mli : logs.ml - $(OCAMLC) -i $(OCAMLCFLAGS) $< > $@ - -syslog.mli : syslog.ml - $(OCAMLC) -i $< > $@ - -.PHONY: install -install: $(LIBS) META - mkdir -p $(OCAMLDESTDIR) - ocamlfind remove -destdir $(OCAMLDESTDIR) log - ocamlfind install -destdir $(OCAMLDESTDIR) -ldconf ignore log META $(INTF) $(LIBS) *.a *.so *.cmx - -.PHONY: uninstall -uninstall: - ocamlfind remove -destdir $(OCAMLDESTDIR) log - -include $(TOPLEVEL)/Makefile.rules - diff -r 42cdb34ec175 -r 734cb0807357 tools/ocaml/libs/log/log.ml --- a/tools/ocaml/libs/log/log.ml +++ /dev/null @@ -1,258 +0,0 @@ -(* - * Copyright (C) 2006-2007 XenSource Ltd. - * Copyright (C) 2008 Citrix Ltd. - * Author Vincent Hanquez <vincent.hanquez@eu.citrix.com> - * - * This program is free software; you can redistribute it and/or modify - * it under the terms of the GNU Lesser General Public License as published - * by the Free Software Foundation; version 2.1 only. with the special - * exception on linking described in file LICENSE. - * - * This program is distributed in the hope that it will be useful, - * but WITHOUT ANY WARRANTY; without even the implied warranty of - * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the - * GNU Lesser General Public License for more details. - *) - -open Printf - -exception Unknown_level of string - -type stream_type = Stderr | Stdout | File of string - -type stream_log = { - ty : stream_type; - channel : out_channel option ref; -} - -type level = Debug | Info | Warn | Error - -type output = - | Stream of stream_log - | String of string list ref - | Syslog of string - | Nil - -let int_of_level l = - match l with Debug -> 0 | Info -> 1 | Warn -> 2 | Error -> 3 - -let string_of_level l = - match l with Debug -> "debug" | Info -> "info" - | Warn -> "warn" | Error -> "error" - -let level_of_string s = - match s with - | "debug" -> Debug - | "info" -> Info - | "warn" -> Warn - | "error" -> Error - | _ -> raise (Unknown_level s) - -let mkdir_safe dir perm = - try Unix.mkdir dir perm with _ -> () - -let mkdir_rec dir perm = - let rec p_mkdir dir = - let p_name = Filename.dirname dir in - if p_name = "/" || p_name = "." then - () - else ( - p_mkdir p_name; - mkdir_safe dir perm - ) in - p_mkdir dir - -type t = { output: output; mutable level: level; } - -let make output level = { output = output; level = level; } - -let make_stream ty channel = - Stream {ty=ty; channel=ref channel; } - -(** open a syslog logger *) -let opensyslog k level = - make (Syslog k) level - -(** open a stderr logger *) -let openerr level = - if (Unix.stat "/dev/stderr").Unix.st_kind <> Unix.S_CHR then - failwith "/dev/stderr is not a valid character device"; - make (make_stream Stderr (Some (open_out "/dev/stderr"))) level - -let openout level = - if (Unix.stat "/dev/stdout").Unix.st_kind <> Unix.S_CHR then - failwith "/dev/stdout is not a valid character device"; - make (make_stream Stdout (Some (open_out "/dev/stdout"))) level - - -(** open a stream logger - returning the channel. *) -(* This needs to be separated from 'openfile' so we can reopen later *) -let doopenfile filename = - if Filename.is_relative filename then - None - else ( - try - mkdir_rec (Filename.dirname filename) 0o700; - Some (open_out_gen [ Open_append; Open_creat ] 0o600 filename) - with _ -> None - ) - -(** open a stream logger - returning the output type *) -let openfile filename level = - make (make_stream (File filename) (doopenfile filename)) level - -(** open a nil logger *) -let opennil () = - make Nil Error - -(** open a string logger *) -let openstring level = - make (String (ref [""])) level - -(** try to reopen a logger *) -let reopen t = - match t.output with - | Nil -> t - | Syslog k -> Syslog.close (); opensyslog k t.level - | Stream s -> ( - match (s.ty,!(s.channel)) with - | (File filename, Some c) -> close_out c; s.channel := (try doopenfile filename with _ -> None); t - | _ -> t) - | String _ -> t - -(** close a logger *) -let close t = - match t.output with - | Nil -> () - | Syslog k -> Syslog.close (); - | Stream s -> ( - match !(s.channel) with - | Some c -> close_out c; s.channel := None - | None -> ()) - | String _ -> () - -(** create a string representating the parameters of the logger *) -let string_of_logger t = - match t.output with - | Nil -> "nil" - | Syslog k -> sprintf "syslog:%s" k - | String _ -> "string" - | Stream s -> - begin - match s.ty with - | File f -> sprintf "file:%s" f - | Stderr -> "stderr" - | Stdout -> "stdout" - end - -(** parse a string to a logger *) -let logger_of_string s : t = - match s with - | "nil" -> opennil () - | "stderr" -> openerr Debug - | "stdout" -> openout Debug - | "string" -> openstring Debug - | _ -> - let split_in_2 s = - try - let i = String.index s ':' in - String.sub s 0 (i), - String.sub s (i + 1) (String.length s - i - 1) - with _ -> - failwith "logger format error: expecting string:string" - in - let k, s = split_in_2 s in - match k with - | "syslog" -> opensyslog s Debug - | "file" -> openfile s Debug - | _ -> failwith "unknown logger type" - -let validate s = - match s with - | "nil" -> () - | "stderr" -> () - | "stdout" -> () - | "string" -> () - | _ -> - let split_in_2 s = - try - let i = String.index s ':' in - String.sub s 0 (i), - String.sub s (i + 1) (String.length s - i - 1) - with _ -> - failwith "logger format error: expecting string:string" - in - let k, s = split_in_2 s in - match k with - | "syslog" -> () - | "file" -> ( - try - let st = Unix.stat s in - if st.Unix.st_kind <> Unix.S_REG then - failwith "logger file is a directory"; - () - with Unix.Unix_error (Unix.ENOENT, _, _) -> () - ) - | _ -> failwith "unknown logger" - -(** change a logger level to level *) -let set t level = t.level <- level - -let gettimestring () = - let time = Unix.gettimeofday () in - let tm = Unix.localtime time in - let msec = time -. (floor time) in - sprintf "%d%.2d%.2d %.2d:%.2d:%.2d.%.3d|" (1900 + tm.Unix.tm_year) - (tm.Unix.tm_mon + 1) tm.Unix.tm_mday - tm.Unix.tm_hour tm.Unix.tm_min tm.Unix.tm_sec - (int_of_float (1000.0 *. msec)) - -(*let extra_hook = ref (fun x -> x)*) - -let output t ?(key="") ?(extra="") priority (message: string) = - let construct_string withtime = - (*let key = if key = "" then [] else [ key ] in - let extra = if extra = "" then [] else [ extra ] in - let items = - (if withtime then [ gettimestring () ] else []) - @ [ sprintf "%5s" (string_of_level priority) ] @ extra @ key @ [ message ] in -(* let items = !extra_hook items in*) - String.concat " " items*) - Printf.sprintf "[%s%s|%s] %s" - (if withtime then gettimestring () else "") (string_of_level priority) extra message - in - (* Keep track of how much we write out to streams, so that we can *) - (* log-rotate at appropriate times *) - let write_to_stream stream = - let string = (construct_string true) in - try - fprintf stream "%s\n%!" string - with _ -> () (* Trap exception when we fail to write log *) - in - - if String.length message > 0 then - match t.output with - | Syslog k -> - let sys_prio = match priority with - | Debug -> Syslog.Debug - | Info -> Syslog.Info - | Warn -> Syslog.Warning - | Error -> Syslog.Err in - Syslog.log Syslog.Daemon sys_prio ((construct_string false) ^ "\n") - | Stream s -> ( - match !(s.channel) with - | Some c -> write_to_stream c - | None -> ()) - | Nil -> () - | String s -> (s := (construct_string true)::!s) - -let log t level (fmt: ('a, unit, string, unit) format4): 'a = - let b = (int_of_level t.level) <= (int_of_level level) in - (* ksprintf is the preferred name for kprintf, but the former - * is not available in OCaml 3.08.3 *) - Printf.kprintf (if b then output t level else (fun _ -> ())) fmt - -let debug t (fmt: ('a , unit, string, unit) format4) = log t Debug fmt -let info t (fmt: ('a , unit, string, unit) format4) = log t Info fmt -let warn t (fmt: ('a , unit, string, unit) format4) = log t Warn fmt -let error t (fmt: ('a , unit, string, unit) format4) = log t Error fmt diff -r 42cdb34ec175 -r 734cb0807357 tools/ocaml/libs/log/log.mli --- a/tools/ocaml/libs/log/log.mli +++ /dev/null @@ -1,55 +0,0 @@ -(* - * Copyright (C) 2006-2007 XenSource Ltd. - * Copyright (C) 2008 Citrix Ltd. - * Author Vincent Hanquez <vincent.hanquez@eu.citrix.com> - * - * This program is free software; you can redistribute it and/or modify - * it under the terms of the GNU Lesser General Public License as published - * by the Free Software Foundation; version 2.1 only. with the special - * exception on linking described in file LICENSE. - * - * This program is distributed in the hope that it will be useful, - * but WITHOUT ANY WARRANTY; without even the implied warranty of - * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the - * GNU Lesser General Public License for more details. - *) - -exception Unknown_level of string -type level = Debug | Info | Warn | Error - -type stream_type = Stderr | Stdout | File of string -type stream_log = { - ty : stream_type; - channel : out_channel option ref; -} -type output = - Stream of stream_log - | String of string list ref - | Syslog of string - | Nil -val int_of_level : level -> int -val string_of_level : level -> string -val level_of_string : string -> level -val mkdir_safe : string -> Unix.file_perm -> unit -val mkdir_rec : string -> Unix.file_perm -> unit -type t = { output : output; mutable level : level; } -val make : output -> level -> t -val opensyslog : string -> level -> t -val openerr : level -> t -val openout : level -> t -val openfile : string -> level -> t -val opennil : unit -> t -val openstring : level -> t -val reopen : t -> t -val close : t -> unit -val string_of_logger : t -> string -val logger_of_string : string -> t -val validate : string -> unit -val set : t -> level -> unit -val gettimestring : unit -> string -val output : t -> ?key:string -> ?extra:string -> level -> string -> unit -val log : t -> level -> ('a, unit, string, unit) format4 -> 'a -val debug : t -> ('a, unit, string, unit) format4 -> 'a -val info : t -> ('a, unit, string, unit) format4 -> 'a -val warn : t -> ('a, unit, string, unit) format4 -> 'a -val error : t -> ('a, unit, string, unit) format4 -> 'a diff -r 42cdb34ec175 -r 734cb0807357 tools/ocaml/libs/log/logs.ml --- a/tools/ocaml/libs/log/logs.ml +++ /dev/null @@ -1,197 +0,0 @@ -(* - * Copyright (C) 2006-2007 XenSource Ltd. - * Copyright (C) 2008 Citrix Ltd. - * Author Vincent Hanquez <vincent.hanquez@eu.citrix.com> - * - * This program is free software; you can redistribute it and/or modify - * it under the terms of the GNU Lesser General Public License as published - * by the Free Software Foundation; version 2.1 only. with the special - * exception on linking described in file LICENSE. - * - * This program is distributed in the hope that it will be useful, - * but WITHOUT ANY WARRANTY; without even the implied warranty of - * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the - * GNU Lesser General Public License for more details. - *) - -type keylogger = -{ - mutable debug: string list; - mutable info: string list; - mutable warn: string list; - mutable error: string list; - no_default: bool; -} - -(* map all logger strings into a logger *) -let __all_loggers = Hashtbl.create 10 - -(* default logger that everything that doesn't have a key in __lop_mapping get send *) -let __default_logger = { debug = []; info = []; warn = []; error = []; no_default = false } - -(* - * This describe the mapping between a name to a keylogger. - * a keylogger contains a list of logger string per level of debugging. - * Example: "xenops", debug -> [ "stderr"; "/var/log/xensource.log" ] - * "xapi", error -> [] - * "xapi", debug -> [ "/var/log/xensource.log" ] - * "xenops", info -> [ "syslog" ] - *) -let __log_mapping = Hashtbl.create 32 - -let get_or_open logstring = - if Hashtbl.mem __all_loggers logstring then - Hashtbl.find __all_loggers logstring - else - let t = Log.logger_of_string logstring in - Hashtbl.add __all_loggers logstring t; - t - -(** create a mapping entry for the key "name". - * all log level of key "name" default to "logger" logger. - * a sensible default is put "nil" as a logger and reopen a specific level to - * the logger you want to. - *) -let add key logger = - let kl = { - debug = logger; - info = logger; - warn = logger; - error = logger; - no_default = false; - } in - Hashtbl.add __log_mapping key kl - -let get_by_level keylog level = - match level with - | Log.Debug -> keylog.debug - | Log.Info -> keylog.info - | Log.Warn -> keylog.warn - | Log.Error -> keylog.error - -let set_by_level keylog level logger = - match level with - | Log.Debug -> keylog.debug <- logger - | Log.Info -> keylog.info <- logger - | Log.Warn -> keylog.warn <- logger - | Log.Error -> keylog.error <- logger - -(** set a specific key|level to the logger "logger" *) -let set key level logger = - if not (Hashtbl.mem __log_mapping key) then - add key []; - - let keylog = Hashtbl.find __log_mapping key in - set_by_level keylog level logger - -(** set default logger *) -let set_default level logger = - set_by_level __default_logger level logger - -(** append a logger to the list *) -let append key level logger = - if not (Hashtbl.mem __log_mapping key) then - add key []; - let keylog = Hashtbl.find __log_mapping key in - let loggers = get_by_level keylog level in - set_by_level keylog level (loggers @ [ logger ]) - -(** append a logger to the default list *) -let append_default level logger = - let loggers = get_by_level __default_logger level in - set_by_level __default_logger level (loggers @ [ logger ]) - -(** reopen all logger open *) -let reopen () = - Hashtbl.iter (fun k v -> - Hashtbl.replace __all_loggers k (Log.reopen v)) __all_loggers - -(** reclaim close all logger open that are not use by any other keys *) -let reclaim () = - let list_sort_uniq l = - let oldprev = ref "" and prev = ref "" in - List.fold_left (fun a k -> - oldprev := !prev; - prev := k; - if k = !oldprev then a else k :: a) [] - (List.sort compare l) - in - let flatten_keylogger v = - list_sort_uniq (v.debug @ v.info @ v.warn @ v.error) in - let oldkeys = Hashtbl.fold (fun k v a -> k :: a) __all_loggers [] in - let usedkeys = Hashtbl.fold (fun k v a -> - (flatten_keylogger v) @ a) - __log_mapping (flatten_keylogger __default_logger) in - let usedkeys = list_sort_uniq usedkeys in - - List.iter (fun k -> - if not (List.mem k usedkeys) then ( - begin try - Log.close (Hashtbl.find __all_loggers k) - with - Not_found -> () - end; - Hashtbl.remove __all_loggers k - )) oldkeys - -(** clear a specific key|level *) -let clear key level = - try - let keylog = Hashtbl.find __log_mapping key in - set_by_level keylog level []; - reclaim () - with Not_found -> - () - -(** clear a specific default level *) -let clear_default level = - set_default level []; - reclaim () - -(** reset all the loggers to the specified logger *) -let reset_all logger = - Hashtbl.clear __log_mapping; - set_default Log.Debug logger; - set_default Log.Warn logger; - set_default Log.Error logger; - set_default Log.Info logger; - reclaim () - -(** log a fmt message to the key|level logger specified in the log mapping. - * if the logger doesn't exist, assume nil logger. - *) -let log key level ?(extra="") (fmt: ('a, unit, string, unit) format4): 'a = - let keylog = - if Hashtbl.mem __log_mapping key then - let keylog = Hashtbl.find __log_mapping key in - if keylog.no_default = false && - get_by_level keylog level = [] then - __default_logger - else - keylog - else - __default_logger in - let loggers = get_by_level keylog level in - match loggers with - | [] -> Printf.kprintf ignore fmt - | _ -> - let l = List.fold_left (fun acc logger -> - try get_or_open logger :: acc - with _ -> acc - ) [] loggers in - let l = List.rev l in - - (* ksprintf is the preferred name for kprintf, but the former - * is not available in OCaml 3.08.3 *) - Printf.kprintf (fun s -> - List.iter (fun t -> Log.output t ~key ~extra level s) l) fmt - -(* define some convenience functions *) -let debug t ?extra (fmt: ('a , unit, string, unit) format4) = - log t Log.Debug ?extra fmt -let info t ?extra (fmt: ('a , unit, string, unit) format4) = - log t Log.Info ?extra fmt -let warn t ?extra (fmt: ('a , unit, string, unit) format4) = - log t Log.Warn ?extra fmt -let error t ?extra (fmt: ('a , unit, string, unit) format4) = - log t Log.Error ?extra fmt diff -r 42cdb34ec175 -r 734cb0807357 tools/ocaml/libs/log/logs.mli --- a/tools/ocaml/libs/log/logs.mli +++ /dev/null @@ -1,46 +0,0 @@ -(* - * Copyright (C) 2006-2007 XenSource Ltd. - * Copyright (C) 2008 Citrix Ltd. - * Author Vincent Hanquez <vincent.hanquez@eu.citrix.com> - * - * This program is free software; you can redistribute it and/or modify - * it under the terms of the GNU Lesser General Public License as published - * by the Free Software Foundation; version 2.1 only. with the special - * exception on linking described in file LICENSE. - * - * This program is distributed in the hope that it will be useful, - * but WITHOUT ANY WARRANTY; without even the implied warranty of - * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the - * GNU Lesser General Public License for more details. - *) - -type keylogger = { - mutable debug : string list; - mutable info : string list; - mutable warn : string list; - mutable error : string list; - no_default : bool; -} -val __all_loggers : (string, Log.t) Hashtbl.t -val __default_logger : keylogger -val __log_mapping : (string, keylogger) Hashtbl.t -val get_or_open : string -> Log.t -val add : string -> string list -> unit -val get_by_level : keylogger -> Log.level -> string list -val set_by_level : keylogger -> Log.level -> string list -> unit -val set : string -> Log.level -> string list -> unit -val set_default : Log.level -> string list -> unit -val append : string -> Log.level -> string -> unit -val append_default : Log.level -> string -> unit -val reopen : unit -> unit -val reclaim : unit -> unit -val clear : string -> Log.level -> unit -val clear_default : Log.level -> unit -val reset_all : string list -> unit -val log : - string -> - Log.level -> ?extra:string -> ('a, unit, string, unit) format4 -> 'a -val debug : string -> ?extra:string -> ('a, unit, string, unit) format4 -> 'a -val info : string -> ?extra:string -> ('a, unit, string, unit) format4 -> 'a -val warn : string -> ?extra:string -> ('a, unit, string, unit) format4 -> 'a -val error : string -> ?extra:string -> ('a, unit, string, unit) format4 -> 'a diff -r 42cdb34ec175 -r 734cb0807357 tools/ocaml/libs/log/syslog.ml --- a/tools/ocaml/libs/log/syslog.ml +++ /dev/null @@ -1,26 +0,0 @@ -(* - * Copyright (C) 2006-2007 XenSource Ltd. - * Copyright (C) 2008 Citrix Ltd. - * Author Vincent Hanquez <vincent.hanquez@eu.citrix.com> - * - * This program is free software; you can redistribute it and/or modify - * it under the terms of the GNU Lesser General Public License as published - * by the Free Software Foundation; version 2.1 only. with the special - * exception on linking described in file LICENSE. - * - * This program is distributed in the hope that it will be useful, - * but WITHOUT ANY WARRANTY; without even the implied warranty of - * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the - * GNU Lesser General Public License for more details. - *) - -type level = Emerg | Alert | Crit | Err | Warning | Notice | Info | Debug -type options = Cons | Ndelay | Nowait | Odelay | Perror | Pid -type facility = Auth | Authpriv | Cron | Daemon | Ftp | Kern - | Local0 | Local1 | Local2 | Local3 - | Local4 | Local5 | Local6 | Local7 - | Lpr | Mail | News | Syslog | User | Uucp - -(* external init : string -> options list -> facility -> unit = "stub_openlog" *) -external log : facility -> level -> string -> unit = "stub_syslog" -external close : unit -> unit = "stub_closelog" diff -r 42cdb34ec175 -r 734cb0807357 tools/ocaml/libs/log/syslog.mli --- a/tools/ocaml/libs/log/syslog.mli +++ /dev/null @@ -1,41 +0,0 @@ -(* - * Copyright (C) 2006-2007 XenSource Ltd. - * Copyright (C) 2008 Citrix Ltd. - * Author Vincent Hanquez <vincent.hanquez@eu.citrix.com> - * - * This program is free software; you can redistribute it and/or modify - * it under the terms of the GNU Lesser General Public License as published - * by the Free Software Foundation; version 2.1 only. with the special - * exception on linking described in file LICENSE. - * - * This program is distributed in the hope that it will be useful, - * but WITHOUT ANY WARRANTY; without even the implied warranty of - * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the - * GNU Lesser General Public License for more details. - *) - -type level = Emerg | Alert | Crit | Err | Warning | Notice | Info | Debug -type options = Cons | Ndelay | Nowait | Odelay | Perror | Pid -type facility = - Auth - | Authpriv - | Cron - | Daemon - | Ftp - | Kern - | Local0 - | Local1 - | Local2 - | Local3 - | Local4 - | Local5 - | Local6 - | Local7 - | Lpr - | Mail - | News - | Syslog - | User - | Uucp -external log : facility -> level -> string -> unit = "stub_syslog" -external close : unit -> unit = "stub_closelog" diff -r 42cdb34ec175 -r 734cb0807357 tools/ocaml/libs/log/syslog_stubs.c --- a/tools/ocaml/libs/log/syslog_stubs.c +++ /dev/null @@ -1,75 +0,0 @@ -/* - * Copyright (C) 2006-2007 XenSource Ltd. - * Copyright (C) 2008 Citrix Ltd. - * Author Vincent Hanquez <vincent.hanquez@eu.citrix.com> - * - * This program is free software; you can redistribute it and/or modify - * it under the terms of the GNU Lesser General Public License as published - * by the Free Software Foundation; version 2.1 only. with the special - * exception on linking described in file LICENSE. - * - * This program is distributed in the hope that it will be useful, - * but WITHOUT ANY WARRANTY; without even the implied warranty of - * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the - * GNU Lesser General Public License for more details. - */ - -#include <syslog.h> -#include <caml/mlvalues.h> -#include <caml/memory.h> -#include <caml/alloc.h> -#include <caml/custom.h> - -static int __syslog_level_table[] = { - LOG_EMERG, LOG_ALERT, LOG_CRIT, LOG_ERR, LOG_WARNING, - LOG_NOTICE, LOG_INFO, LOG_DEBUG -}; - -/* -static int __syslog_options_table[] = { - LOG_CONS, LOG_NDELAY, LOG_NOWAIT, LOG_ODELAY, LOG_PERROR, LOG_PID -}; -*/ - -static int __syslog_facility_table[] = { - LOG_AUTH, LOG_AUTHPRIV, LOG_CRON, LOG_DAEMON, LOG_FTP, LOG_KERN, - LOG_LOCAL0, LOG_LOCAL1, LOG_LOCAL2, LOG_LOCAL3, - LOG_LOCAL4, LOG_LOCAL5, LOG_LOCAL6, LOG_LOCAL7, - LOG_LPR | LOG_MAIL | LOG_NEWS | LOG_SYSLOG | LOG_USER | LOG_UUCP -}; - -/* According to the openlog manpage the 'openlog' call may take a reference - to the 'ident' string and keep it long-term. This means we cannot just pass in - an ocaml string which is under the control of the GC. Since we aren't actually - calling this function we can just comment it out for the time-being. */ -/* -value stub_openlog(value ident, value option, value facility) -{ - CAMLparam3(ident, option, facility); - int c_option; - int c_facility; - - c_option = caml_convert_flag_list(option, __syslog_options_table); - c_facility = __syslog_facility_table[Int_val(facility)]; - openlog(String_val(ident), c_option, c_facility); - CAMLreturn(Val_unit); -} -*/ - -value stub_syslog(value facility, value level, value msg) -{ - CAMLparam3(facility, level, msg); - int c_facility; - - c_facility = __syslog_facility_table[Int_val(facility)] - | __syslog_level_table[Int_val(level)]; - syslog(c_facility, "%s", String_val(msg)); - CAMLreturn(Val_unit); -} - -value stub_closelog(value unit) -{ - CAMLparam1(unit); - closelog(); - CAMLreturn(Val_unit); -} diff -r 42cdb34ec175 -r 734cb0807357 tools/ocaml/xenstored/Makefile --- a/tools/ocaml/xenstored/Makefile +++ b/tools/ocaml/xenstored/Makefile @@ -3,7 +3,6 @@ include $(OCAML_TOPLEVEL)/common.make OCAMLINCLUDE += \ - -I $(OCAML_TOPLEVEL)/libs/log \ -I $(OCAML_TOPLEVEL)/libs/xb \ -I $(OCAML_TOPLEVEL)/libs/mmap \ -I $(OCAML_TOPLEVEL)/libs/xc \ @@ -34,7 +33,6 @@ XENSTOREDLIBS = \ unix.cmxa \ -ccopt -L -ccopt $(OCAML_TOPLEVEL)/libs/mmap $(OCAML_TOPLEVEL)/libs/mmap/mmap.cmxa \ - -ccopt -L -ccopt $(OCAML_TOPLEVEL)/libs/log $(OCAML_TOPLEVEL)/libs/log/log.cmxa \ -ccopt -L -ccopt $(OCAML_TOPLEVEL)/libs/eventchn $(OCAML_TOPLEVEL)/libs/eventchn/eventchn.cmxa \ -ccopt -L -ccopt $(OCAML_TOPLEVEL)/libs/xc $(OCAML_TOPLEVEL)/libs/xc/xc.cmxa \ -ccopt -L -ccopt $(OCAML_TOPLEVEL)/libs/xb $(OCAML_TOPLEVEL)/libs/xb/xb.cmxa \ diff -r 42cdb34ec175 -r 734cb0807357 tools/ocaml/xenstored/connection.ml --- a/tools/ocaml/xenstored/connection.ml +++ b/tools/ocaml/xenstored/connection.ml @@ -232,3 +232,8 @@ Printf.fprintf chan "watch,%d,%s,%s\n" domid (Utils.hexify path) (Utils.hexify token) ) (list_watches con); | None -> () + +let debug con = + let domid = get_domstr con in + let watches = List.map (fun (path, token) -> Printf.sprintf "watch %s: %s %s\n" domid path token) (list_watches con) in + String.concat "" watches diff -r 42cdb34ec175 -r 734cb0807357 tools/ocaml/xenstored/connections.ml --- a/tools/ocaml/xenstored/connections.ml +++ b/tools/ocaml/xenstored/connections.ml @@ -15,7 +15,7 @@ * GNU Lesser General Public License for more details. *) -let debug fmt = Logs.debug "general" fmt +let debug fmt = Logging.debug "connections" fmt type t = { mutable anonymous: Connection.t list; @@ -165,3 +165,8 @@ ); (List.length cons.anonymous, !nb_ops_anon, !nb_watchs_anon, Hashtbl.length cons.domains, !nb_ops_dom, !nb_watchs_dom) + +let debug cons = + let anonymous = List.map Connection.debug cons.anonymous in + let domains = Hashtbl.fold (fun _ con accu -> Connection.debug con :: accu) cons.domains [] in + String.concat "" (domains @ anonymous) diff -r 42cdb34ec175 -r 734cb0807357 tools/ocaml/xenstored/disk.ml --- a/tools/ocaml/xenstored/disk.ml +++ b/tools/ocaml/xenstored/disk.ml @@ -17,7 +17,7 @@ let enable = ref false let xs_daemon_database = "/var/run/xenstored/db" -let error = Logs.error "general" +let error fmt = Logging.error "disk" fmt (* unescape utils *) exception Bad_escape diff -r 42cdb34ec175 -r 734cb0807357 tools/ocaml/xenstored/domain.ml --- a/tools/ocaml/xenstored/domain.ml +++ b/tools/ocaml/xenstored/domain.ml @@ -16,7 +16,7 @@ open Printf -let debug fmt = Logs.debug "general" fmt +let debug fmt = Logging.debug "domain" fmt type t = { diff -r 42cdb34ec175 -r 734cb0807357 tools/ocaml/xenstored/domains.ml --- a/tools/ocaml/xenstored/domains.ml +++ b/tools/ocaml/xenstored/domains.ml @@ -14,6 +14,8 @@ * GNU Lesser General Public License for more details. *) +let debug fmt = Logging.debug "domains" fmt + type domains = { eventchn: Event.t; table: (Xc.domid, Domain.t) Hashtbl.t; @@ -35,7 +37,7 @@ try let info = Xc.domain_getinfo xc id in if info.Xc.shutdown || info.Xc.dying then ( - Logs.debug "general" "Domain %u died (dying=%b, shutdown %b -- code %d)" + debug "Domain %u died (dying=%b, shutdown %b -- code %d)" id info.Xc.dying info.Xc.shutdown info.Xc.shutdown_code; if info.Xc.dying then dead_dom := id :: !dead_dom @@ -43,7 +45,7 @@ notify := true; ) with Xc.Error _ -> - Logs.debug "general" "Domain %u died -- no domain info" id; + debug "Domain %u died -- no domain info" id; dead_dom := id :: !dead_dom; ) doms.table; List.iter (fun id -> diff -r 42cdb34ec175 -r 734cb0807357 tools/ocaml/xenstored/logging.ml --- a/tools/ocaml/xenstored/logging.ml +++ b/tools/ocaml/xenstored/logging.ml @@ -17,21 +17,122 @@ open Stdext open Printf -let error fmt = Logs.error "general" fmt -let info fmt = Logs.info "general" fmt -let debug fmt = Logs.debug "general" fmt -let access_log_file = ref "/var/log/xenstored-access.log" -let access_log_nb_files = ref 20 -let access_log_nb_lines = ref 13215 -let activate_access_log = ref true +(* Logger common *) -(* maximal size of the lines in xenstore-acces.log file *) -let line_size = 180 +type logger = + { stop: unit -> unit; + restart: unit -> unit; + rotate: unit -> unit; + write: 'a. ('a, unit, string, unit) format4 -> 'a } -let log_read_ops = ref false -let log_transaction_ops = ref false -let log_special_ops = ref false +let truncate_line nb_chars line = + if String.length line > nb_chars - 1 then + let len = max (nb_chars - 1) 2 in + let dst_line = String.create len in + String.blit line 0 dst_line 0 (len - 2); + dst_line.[len-2] <- '.'; + dst_line.[len-1] <- '.'; + dst_line + else line + +let log_rotate ref_ch log_file log_nb_files = + let file n = sprintf "%s.%i" log_file n in + let log_files = + let rec aux accu n = + if n >= log_nb_files then accu + else + if n = 1 && Sys.file_exists log_file + then aux [log_file,1] 2 + else + let file = file (n-1) in + if Sys.file_exists file then + aux ((file, n) :: accu) (n+1) + else accu in + aux [] 1 in + List.iter (fun (f, n) -> Unix.rename f (file n)) log_files; + close_out !ref_ch; + ref_ch := open_out log_file + +let make_logger log_file log_nb_files log_nb_lines log_nb_chars post_rotate = + let channel = ref (open_out_gen [Open_append; Open_creat] 0o644 log_file) in + let counter = ref 0 in + let stop() = + try flush !channel; close_out !channel + with _ -> () in + let restart() = + stop(); + channel := open_out_gen [Open_append; Open_creat] 0o644 log_file in + let rotate() = + log_rotate channel log_file log_nb_files; + (post_rotate (): unit); + counter := 0 in + let output s = + let s = if log_nb_chars > 0 then truncate_line log_nb_chars s else s in + let s = s ^ "\n" in + output_string !channel s; + flush !channel; + incr counter; + if !counter > log_nb_lines then rotate() in + { stop=stop; restart=restart; rotate=rotate; write = fun fmt -> Printf.ksprintf output fmt } + + +(* Xenstored logger *) + +exception Unknown_level of string + +type level = Debug | Info | Warn | Error | Null + +let int_of_level = function + | Debug -> 0 | Info -> 1 | Warn -> 2 + | Error -> 3 | Null -> max_int + +let string_of_level = function + | Debug -> "debug" | Info -> "info" | Warn -> "warn" + | Error -> "error" | Null -> "null" + +let level_of_string = function + | "debug" -> Debug | "info" -> Info | "warn" -> Warn + | "error" -> Error | "null" -> Null | s -> raise (Unknown_level s) + +let string_of_date () = + let time = Unix.gettimeofday () in + let tm = Unix.gmtime time in + let msec = time -. (floor time) in + sprintf "%d%.2d%.2dT%.2d:%.2d:%.2d.%.3dZ" + (1900 + tm.Unix.tm_year) (tm.Unix.tm_mon + 1) tm.Unix.tm_mday + tm.Unix.tm_hour tm.Unix.tm_min tm.Unix.tm_sec + (int_of_float (1000.0 *. msec)) + +let xenstored_log_file = ref "/var/log/xenstored.log" +let xenstored_log_level = ref Null +let xenstored_log_nb_files = ref 10 +let xenstored_log_nb_lines = ref 13215 +let xenstored_log_nb_chars = ref (-1) +let xenstored_logger = ref (None: logger option) + +let init_xenstored_log () = + if !xenstored_log_level <> Null && !xenstored_log_nb_files > 0 then + let logger = + make_logger + !xenstored_log_file !xenstored_log_nb_files !xenstored_log_nb_lines + !xenstored_log_nb_chars ignore in + xenstored_logger := Some logger + +let xenstored_logging level key (fmt: (_,_,_,_) format4) = + match !xenstored_logger with + | Some logger when int_of_level level >= int_of_level !xenstored_log_level -> + let date = string_of_date() in + let level = string_of_level level in + logger.write ("[%s|%5s|%s] " ^^ fmt) date level key + | _ -> Printf.ksprintf ignore fmt + +let debug key = xenstored_logging Debug key +let info key = xenstored_logging Info key +let warn key = xenstored_logging Warn key +let error key = xenstored_logging Error key + +(* Access logger *) type access_type = | Coalesce @@ -41,38 +142,10 @@ | Endconn | XbOp of Xb.Op.operation -type access = - { - fd: out_channel ref; - counter: int ref; - write: tid:int -> con:string -> ?data:string -> access_type -> unit; - } - -let string_of_date () = - let time = Unix.gettimeofday () in - let tm = Unix.localtime time in - let msec = time -. (floor time) in - sprintf "%d%.2d%.2d %.2d:%.2d:%.2d.%.3d" (1900 + tm.Unix.tm_year) - (tm.Unix.tm_mon + 1) - tm.Unix.tm_mday - tm.Unix.tm_hour - tm.Unix.tm_min - tm.Unix.tm_sec - (int_of_float (1000.0 *. msec)) - -let fill_with_space n s = - if String.length s < n - then - let r = String.make n ' ' in - String.blit s 0 r 0 (String.length s); - r - else - s - let string_of_tid ~con tid = if tid = 0 - then fill_with_space 12 (sprintf "%s" con) - else fill_with_space 12 (sprintf "%s.%i" con tid) + then sprintf "%-12s" con + else sprintf "%-12s" (sprintf "%s.%i" con tid) let string_of_access_type = function | Coalesce -> "coalesce " @@ -109,41 +182,9 @@ | Xb.Op.Error -> "error " | Xb.Op.Watchevent -> "w event " - + (* | x -> Xb.Op.to_string x - -let file_exists file = - try - Unix.close (Unix.openfile file [Unix.O_RDONLY] 0o644); - true - with _ -> - false - -let log_rotate fd = - let file n = sprintf "%s.%i" !access_log_file n in - let log_files = - let rec aux accu n = - if n >= !access_log_nb_files - then accu - else if n = 1 && file_exists !access_log_file - then aux [!access_log_file,1] 2 - else - let file = file (n-1) in - if file_exists file - then aux ((file,n) :: accu) (n+1) - else accu - in - aux [] 1 - in - let rec rename = function - | (f,n) :: t when n < !access_log_nb_files -> - Unix.rename f (file n); - rename t - | _ -> () - in - rename log_files; - close_out !fd; - fd := open_out !access_log_file + *) let sanitize_data data = let data = String.copy data in @@ -154,86 +195,67 @@ done; String.escaped data -let make save_to_disk = - let fd = ref (open_out_gen [Open_append; Open_creat] 0o644 !access_log_file) in - let counter = ref 0 in - { - fd = fd; - counter = counter; - write = - if not !activate_access_log || !access_log_nb_files = 0 - then begin fun ~tid ~con ?data _ -> () end - else fun ~tid ~con ?(data="") access_type -> - let s = Printf.sprintf "[%s] %s %s %s\n" (string_of_date()) (string_of_tid ~con tid) - (string_of_access_type access_type) (sanitize_data data) in - let s = - if String.length s > line_size - then begin - let s = String.sub s 0 line_size in - s.[line_size-3] <- '.'; - s.[line_size-2] <- '.'; - s.[line_size-1] <- '\n'; - s - end else - s - in - incr counter; - output_string !fd s; - flush !fd; - if !counter > !access_log_nb_lines - then begin - log_rotate fd; - save_to_disk (); - counter := 0; - end - } +let activate_access_log = ref true +let access_log_file = ref "/var/log/xenstored-access.log" +let access_log_nb_files = ref 20 +let access_log_nb_lines = ref 13215 +let access_log_nb_chars = ref 180 +let access_log_read_ops = ref false +let access_log_transaction_ops = ref false +let access_log_special_ops = ref false +let access_logger = ref None -let access : (access option) ref = ref None -let init aal save_to_disk = - activate_access_log := aal; - access := Some (make save_to_disk) +let init_access_log post_rotate = + if !access_log_nb_files > 0 then + let logger = + make_logger + !access_log_file !access_log_nb_files !access_log_nb_lines + !access_log_nb_chars post_rotate in + access_logger := Some logger -let write_access_log ~con ~tid ?data access_type = +let access_logging ~con ~tid ?(data="") access_type = try - maybe (fun a -> a.write access_type ~con ~tid ?data) !access + maybe + (fun logger -> + let date = string_of_date() in + let tid = string_of_tid ~con tid in + let access_type = string_of_access_type access_type in + let data = sanitize_data data in + logger.write "[%s] %s %s %s" date tid access_type data) + !access_logger with _ -> () -let new_connection = write_access_log Newconn -let end_connection = write_access_log Endconn +let new_connection = access_logging Newconn +let end_connection = access_logging Endconn let read_coalesce ~tid ~con data = - if !log_read_ops - then write_access_log Coalesce ~tid ~con ~data:("read "^data) -let write_coalesce data = write_access_log Coalesce ~data:("write "^data) -let conflict = write_access_log Conflict -let commit = write_access_log Commit + if !access_log_read_ops + then access_logging Coalesce ~tid ~con ~data:("read "^data) +let write_coalesce data = access_logging Coalesce ~data:("write "^data) +let conflict = access_logging Conflict +let commit = access_logging Commit let xb_op ~tid ~con ~ty data = - let print = - match ty with - | Xb.Op.Read | Xb.Op.Directory | Xb.Op.Getperms -> !log_read_ops + let print = match ty with + | Xb.Op.Read | Xb.Op.Directory | Xb.Op.Getperms -> !access_log_read_ops | Xb.Op.Transaction_start | Xb.Op.Transaction_end -> false (* transactions are managed below *) | Xb.Op.Introduce | Xb.Op.Release | Xb.Op.Getdomainpath | Xb.Op.Isintroduced | Xb.Op.Resume -> - !log_special_ops - | _ -> true - in - if print - then write_access_log ~tid ~con ~data (XbOp ty) + !access_log_special_ops + | _ -> true in + if print then access_logging ~tid ~con ~data (XbOp ty) let start_transaction ~tid ~con = - if !log_transaction_ops && tid <> 0 - then write_access_log ~tid ~con (XbOp Xb.Op.Transaction_start) + if !access_log_transaction_ops && tid <> 0 + then access_logging ~tid ~con (XbOp Xb.Op.Transaction_start) let end_transaction ~tid ~con = - if !log_transaction_ops && tid <> 0 - then write_access_log ~tid ~con (XbOp Xb.Op.Transaction_end) + if !access_log_transaction_ops && tid <> 0 + then access_logging ~tid ~con (XbOp Xb.Op.Transaction_end) let xb_answer ~tid ~con ~ty data = let print = match ty with - | Xb.Op.Error when data="ENOENT " -> !log_read_ops - | Xb.Op.Error -> !log_special_ops + | Xb.Op.Error when String.startswith "ENOENT" data -> !access_log_read_ops + | Xb.Op.Error -> true | Xb.Op.Watchevent -> true - | _ -> false - in - if print - then write_access_log ~tid ~con ~data (XbOp ty) + | _ -> false in + if print then access_logging ~tid ~con ~data (XbOp ty) diff -r 42cdb34ec175 -r 734cb0807357 tools/ocaml/xenstored/perms.ml --- a/tools/ocaml/xenstored/perms.ml +++ b/tools/ocaml/xenstored/perms.ml @@ -15,6 +15,8 @@ * GNU Lesser General Public License for more details. *) +let info fmt = Logging.info "perms" fmt + open Stdext let activate = ref true @@ -145,16 +147,16 @@ in match perm, request with | NONE, _ -> - Logs.info "io" "Permission denied: Domain %d has no permission" domainid; + info "Permission denied: Domain %d has no permission" domainid; false | RDWR, _ -> true | READ, READ -> true | WRITE, WRITE -> true | READ, _ -> - Logs.info "io" "Permission denied: Domain %d has read only access" domainid; + info "Permission denied: Domain %d has read only access" domainid; false | WRITE, _ -> - Logs.info "io" "Permission denied: Domain %d has write only access" domainid; + info "Permission denied: Domain %d has write only access" domainid; false in if !activate diff -r 42cdb34ec175 -r 734cb0807357 tools/ocaml/xenstored/process.ml --- a/tools/ocaml/xenstored/process.ml +++ b/tools/ocaml/xenstored/process.ml @@ -14,6 +14,9 @@ * GNU Lesser General Public License for more details. *) +let error fmt = Logging.error "process" fmt +let info fmt = Logging.info "process" fmt + open Printf open Stdext @@ -79,7 +82,7 @@ (* packets *) let do_debug con t domains cons data = - if not !allow_debug + if not (Connection.is_dom0 con) && not !allow_debug then None else try match split None '\000' data with | "print" :: msg :: _ -> @@ -89,6 +92,9 @@ let domid = int_of_string domid in let quota = (Store.get_quota t.Transaction.store) in Some (Quota.to_string quota domid ^ "\000") + | "watches" :: _ -> + let watches = Connections.debug cons in + Some (watches ^ "\000") | "mfn" :: domid :: _ -> let domid = int_of_string domid in let con = Connections.find_domain cons domid in @@ -357,8 +363,7 @@ in input_handle_error ~cons ~doms ~fct ~ty ~con ~t ~rid ~data; with exn -> - Logs.error "general" "process packet: %s" - (Printexc.to_string exn); + error "process packet: %s" (Printexc.to_string exn); Connection.send_error con tid rid "EIO" let write_access_log ~ty ~tid ~con ~data = @@ -372,7 +377,7 @@ let packet = Connection.pop_in con in let tid, rid, ty, data = Xb.Packet.unpack packet in (* As we don't log IO, do not call an unnecessary sanitize_data - Logs.info "io" "[%s] -> [%d] %s \"%s\"" + info "[%s] -> [%d] %s \"%s\"" (Connection.get_domstr con) tid (Xb.Op.to_string ty) (sanitize_data data); *) process_packet ~store ~cons ~doms ~con ~tid ~rid ~ty ~data; @@ -386,7 +391,7 @@ let packet = Connection.peek_output con in let tid, rid, ty, data = Xb.Packet.unpack packet in (* As we don't log IO, do not call an unnecessary sanitize_data - Logs.info "io" "[%s] <- %s \"%s\"" + info "[%s] <- %s \"%s\"" (Connection.get_domstr con) (Xb.Op.to_string ty) (sanitize_data data);*) write_answer_log ~ty ~tid ~con ~data; diff -r 42cdb34ec175 -r 734cb0807357 tools/ocaml/xenstored/quota.ml --- a/tools/ocaml/xenstored/quota.ml +++ b/tools/ocaml/xenstored/quota.ml @@ -18,7 +18,7 @@ exception Data_too_big exception Transaction_opened -let warn fmt = Logs.warn "general" fmt +let warn fmt = Logging.warn "quota" fmt let activate = ref true let maxent = ref (10000) let maxsize = ref (4096) diff -r 42cdb34ec175 -r 734cb0807357 tools/ocaml/xenstored/store.ml --- a/tools/ocaml/xenstored/store.ml +++ b/tools/ocaml/xenstored/store.ml @@ -83,7 +83,7 @@ let check_owner node connection = if not (Perms.check_owner connection node.perms) then begin - Logs.info "io" "Permission denied: Domain %d not owner" (get_owner node); + Logging.info "store|node" "Permission denied: Domain %d not owner" (get_owner node); raise Define.Permission_denied; end diff -r 42cdb34ec175 -r 734cb0807357 tools/ocaml/xenstored/xenstored.conf --- a/tools/ocaml/xenstored/xenstored.conf +++ b/tools/ocaml/xenstored/xenstored.conf @@ -22,9 +22,14 @@ # Activate filed base backend persistant = false -# Logs -log = error;general;file:/var/log/xenstored.log -log = warn;general;file:/var/log/xenstored.log -log = info;general;file:/var/log/xenstored.log +# Xenstored logs +# xenstored-log-file = /var/log/xenstored.log +# xenstored-log-level = null +# xenstored-log-nb-files = 10 -# log = debug;io;file:/var/log/xenstored-io.log +# Xenstored access logs +# access-log-file = /var/log/xenstored-access.log +# access-log-nb-lines = 13215 +# acesss-log-nb-chars = 180 +# access-log-special-ops = false + diff -r 42cdb34ec175 -r 734cb0807357 tools/ocaml/xenstored/xenstored.ml --- a/tools/ocaml/xenstored/xenstored.ml +++ b/tools/ocaml/xenstored/xenstored.ml @@ -18,7 +18,10 @@ open Printf open Parse_arg open Stdext -open Logging + +let error fmt = Logging.error "xenstored" fmt +let debug fmt = Logging.debug "xenstored" fmt +let info fmt = Logging.info "xenstored" fmt (*------------ event klass processors --------------*) let process_connection_fds store cons domains rset wset = @@ -64,7 +67,8 @@ () let sighup_handler _ = - try Logs.reopen (); info "Log re-opened" with _ -> () + maybe (fun logger -> logger.Logging.restart()) !Logging.xenstored_logger; + maybe (fun logger -> logger.Logging.restart()) !Logging.access_logger let config_filename cf = match cf.config_file with @@ -75,26 +79,6 @@ let parse_config filename = let pidfile = ref default_pidfile in - let set_log s = - let ls = String.split ~limit:3 ';' s in - let level, key, logger = match ls with - | [ level; key; logger ] -> level, key, logger - | _ -> failwith "format mismatch: expecting 3 arguments" in - - let loglevel = match level with - | "debug" -> Log.Debug - | "info" -> Log.Info - | "warn" -> Log.Warn - | "error" -> Log.Error - | s -> failwith (sprintf "Unknown log level: %s" s) in - - (* if key is empty, append to the default logger *) - let append = - if key = "" then - Logs.append_default - else - Logs.append key in - append loglevel logger in let options = [ ("merge-activate", Config.Set_bool Transaction.do_coalesce); ("perms-activate", Config.Set_bool Perms.activate); @@ -104,14 +88,20 @@ ("quota-maxentity", Config.Set_int Quota.maxent); ("quota-maxsize", Config.Set_int Quota.maxsize); ("test-eagain", Config.Set_bool Transaction.test_eagain); - ("log", Config.String set_log); ("persistant", Config.Set_bool Disk.enable); + ("xenstored-log-file", Config.Set_string Logging.xenstored_log_file); + ("xenstored-log-level", Config.String + (fun s -> Logging.xenstored_log_level := Logging.level_of_string s)); + ("xenstored-log-nb-files", Config.Set_int Logging.xenstored_log_nb_files); + ("xenstored-log-nb-lines", Config.Set_int Logging.xenstored_log_nb_lines); + ("xenstored-log-nb-chars", Config.Set_int Logging.xenstored_log_nb_chars); ("access-log-file", Config.Set_string Logging.access_log_file); ("access-log-nb-files", Config.Set_int Logging.access_log_nb_files); ("access-log-nb-lines", Config.Set_int Logging.access_log_nb_lines); - ("access-log-read-ops", Config.Set_bool Logging.log_read_ops); - ("access-log-transactions-ops", Config.Set_bool Logging.log_transaction_ops); - ("access-log-special-ops", Config.Set_bool Logging.log_special_ops); + ("access-log-nb-chars", Config.Set_int Logging.access_log_nb_chars); + ("access-log-read-ops", Config.Set_bool Logging.access_log_read_ops); + ("access-log-transactions-ops", Config.Set_bool Logging.access_log_transaction_ops); + ("access-log-special-ops", Config.Set_bool Logging.access_log_special_ops); ("allow-debug", Config.Set_bool Process.allow_debug); ("pid-file", Config.Set_string pidfile); ] in begin try Config.read filename options (fun _ _ -> raise Not_found) @@ -223,9 +213,6 @@ end let _ = - printf "Xen Storage Daemon, version %d.%d\n%!" - Define.xenstored_major Define.xenstored_minor; - let cf = do_argv in let pidfile = if Sys.file_exists (config_filename cf) then @@ -249,13 +236,13 @@ in if cf.daemonize then - Unixext.daemonize (); + Unixext.daemonize () + else + printf "Xen Storage Daemon, version %d.%d\n%!" + Define.xenstored_major Define.xenstored_minor; (try Unixext.pidfile_write pidfile with _ -> ()); - info "Xen Storage Daemon, version %d.%d" - Define.xenstored_major Define.xenstored_minor; - (* for compatilibity with old xenstored *) begin match cf.pidfile with | Some pidfile -> Unixext.pidfile_write pidfile @@ -293,7 +280,14 @@ Sys.set_signal Sys.sigusr1 (Sys.Signal_handle (fun i -> sigusr1_handler store)); Sys.set_signal Sys.sigpipe Sys.Signal_ignore; - Logging.init cf.activate_access_log (fun () -> DB.to_file store cons "/var/run/xenstored/db"); + Logging.init_xenstored_log(); + if cf.activate_access_log then begin + let post_rotate () = DB.to_file store cons "/var/run/xenstored/db" in + Logging.init_access_log post_rotate + end; + + info "Xen Storage Daemon, version %d.%d" + Define.xenstored_major Define.xenstored_minor; let spec_fds = (match rw_sock with None -> [] | Some x -> [ x ]) @ _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel From xen-devel-bounces@lists.xensource.com Thu Sep 29 14:46:19 2011 Return-path: <xen-devel-bounces@lists.xensource.com> Envelope-to: www-data@lists.xensource.com Delivery-date: Thu, 29 Sep 2011 14:46:19 -0700 Received: from localhost ([127.0.0.1] helo=lists.colo.xensource.com) by lists.xensource.com with esmtp (Exim 4.43) id 1R9OQt-00046y-0O; Thu, 29 Sep 2011 14:46:19 -0700 Received: from mail21.messagelabs.com ([85.158.143.35]) by lists.xensource.com with esmtp (Exim 4.43) id 1R9OQD-0003uX-JR for xen-devel@lists.xensource.com; Thu, 29 Sep 2011 14:45:38 -0700 X-Env-Sender: Ian.Jackson@eu.citrix.com X-Msg-Ref: server-6.tower-21.messagelabs.com!1317332714!40196193!1 X-Originating-IP: [62.200.22.115] X-StarScan-Version: 6.4.1; banners=-,-,- X-VirusChecked: Checked Received: (qmail 11367 invoked from network); 29 Sep 2011 21:45:14 -0000 Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115) by server-6.tower-21.messagelabs.com with RC4-SHA encrypted SMTP; 29 Sep 2011 21:45:14 -0000 X-IronPort-AV: E=Sophos;i="4.68,463,1312156800"; d="scan'208";a="8138604" Received: from lonpmailmx01.citrite.net ([10.30.203.162]) by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5; 29 Sep 2011 21:45:34 +0000 Received: from norwich.cam.xci-test.com (10.80.248.129) by smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id 8.3.137.0; Thu, 29 Sep 2011 22:45:34 +0100 Received: from [10.80.248.135] (helo=woking.xci-test.com) by norwich.cam.xci-test.com with esmtp (Exim 4.72) (envelope-from <ian.jackson@eu.citrix.com>) id 1R9OQ9-0001fg-UC; Thu, 29 Sep 2011 21:45:33 +0000 Received: from osstest by woking.xci-test.com with local (Exim 4.69) (envelope-from <ian.jackson@eu.citrix.com>) id 1R9OQ9-0004UK-Sv; Thu, 29 Sep 2011 22:45:33 +0100 To: xen-devel@lists.xensource.com Message-ID: <osstest-9121-mainreport@xen.org> From: xen.org <ian.jackson@eu.citrix.com> Date: Thu, 29 Sep 2011 22:45:33 +0100 MIME-Version: 1.0 Content-Type: text/plain Cc: ian.jackson@eu.citrix.com Subject: [Xen-devel] [xen-unstable test] 9121: regressions - FAIL X-BeenThere: xen-devel@lists.xensource.com X-Mailman-Version: 2.1.5 Precedence: list List-Id: Xen developer discussion <xen-devel.lists.xensource.com> List-Unsubscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe> List-Post: <mailto:xen-devel@lists.xensource.com> List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help> List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=subscribe> Sender: xen-devel-bounces@lists.xensource.com Errors-To: xen-devel-bounces@lists.xensource.com flight 9121 xen-unstable real [real] http://www.chiark.greenend.org.uk/~xensrcts/logs/9121/ Regressions :-( Tests which did not succeed and are blocking: test-amd64-i386-xl-multivcpu 9 guest-start fail REGR. vs. 9118 test-amd64-i386-xl 9 guest-start fail REGR. vs. 9118 test-amd64-i386-xl-credit2 9 guest-start fail REGR. vs. 9118 test-amd64-i386-rhel6hvm-intel 7 redhat-install fail REGR. vs. 9118 test-i386-i386-xl 9 guest-start fail REGR. vs. 9118 test-amd64-i386-rhel6hvm-amd 7 redhat-install fail REGR. vs. 9118 test-amd64-i386-xl-win-vcpus1 7 windows-install fail REGR. vs. 9118 test-i386-i386-xl-win 7 windows-install fail REGR. vs. 9118 test-amd64-amd64-xl-pcipt-intel 8 debian-fixup fail in 9119 REGR. vs. 9118 test-amd64-amd64-xl-sedf 9 guest-start fail in 9119 REGR. vs. 9118 test-amd64-amd64-xl 9 guest-start fail in 9119 REGR. vs. 9118 test-amd64-amd64-xl-win 7 windows-install fail in 9119 REGR. vs. 9118 Tests which are failing intermittently (not blocking): build-amd64-pvops 4 kernel-build fail pass in 9119 Tests which did not succeed, but are not blocking, including regressions (tests previously passed) regarded as allowable: test-amd64-amd64-xl-pcipt-intel 1 xen-build-check(1) blocked n/a test-amd64-amd64-pv 1 xen-build-check(1) blocked n/a test-amd64-amd64-xl-sedf 1 xen-build-check(1) blocked n/a test-amd64-amd64-pair 1 xen-build-check(1) blocked n/a test-amd64-amd64-xl 1 xen-build-check(1) blocked n/a test-amd64-i386-win-vcpus1 16 leak-check/check fail never pass test-amd64-i386-win 16 leak-check/check fail never pass test-amd64-amd64-win 1 xen-build-check(1) blocked n/a test-amd64-amd64-xl-win 1 xen-build-check(1) blocked n/a test-i386-i386-win 16 leak-check/check fail never pass test-amd64-amd64-win 16 leak-check/check fail in 9119 never pass version targeted for testing: xen e78cd03b0308 baseline version: xen 7998217630e2 ------------------------------------------------------------ People who touched revisions under test: Adin Scannell <adin@scannell.ca> Anthony PERARD <anthony.perard@citrix.com> Ian Campbell <ian.campbell@citrix.com> Ian Jackson <ian.jackson.citrix.com> Ian Jackson <ian.jackson@eu.citrix.com> Olaf Hering <olaf@aepfle.de> ------------------------------------------------------------ jobs: build-amd64 pass build-i386 pass build-amd64-oldkern pass build-i386-oldkern pass build-amd64-pvops fail build-i386-pvops pass test-amd64-amd64-xl blocked test-amd64-i386-xl fail test-i386-i386-xl fail test-amd64-i386-rhel6hvm-amd fail test-amd64-i386-xl-credit2 fail test-amd64-amd64-xl-pcipt-intel blocked test-amd64-i386-rhel6hvm-intel fail test-amd64-i386-xl-multivcpu fail test-amd64-amd64-pair blocked test-amd64-i386-pair pass test-i386-i386-pair pass test-amd64-amd64-pv blocked test-amd64-i386-pv pass test-i386-i386-pv pass test-amd64-amd64-xl-sedf blocked test-amd64-i386-win-vcpus1 fail test-amd64-i386-xl-win-vcpus1 fail test-amd64-amd64-win blocked test-amd64-i386-win fail test-i386-i386-win fail test-amd64-amd64-xl-win blocked test-i386-i386-xl-win fail ------------------------------------------------------------ sg-report-flight on woking.cam.xci-test.com logs: /home/xc_osstest/logs images: /home/xc_osstest/images Logs, config files, etc. are available at http://www.chiark.greenend.org.uk/~xensrcts/logs Test harness code can be found at http://xenbits.xensource.com/gitweb?p=osstest.git;a=summary Not pushing. ------------------------------------------------------------ changeset: 23894:e78cd03b0308 tag: tip user: Anthony PERARD <anthony.perard@citrix.com> date: Thu Sep 29 16:31:24 2011 +0100 libxl: libxl_qmp: use of libxl__fd_set_cloexec. Signed-off-by: Anthony PERARD <anthony.perard@citrix.com> Acked-by: Ian Jackson <ian.jackson@eu.citrix.com> Committed-by: Ian Jackson <ian.jackson@eu.citrix.com> changeset: 23893:95a40ee93806 user: Anthony PERARD <anthony.perard@citrix.com> date: Thu Sep 29 16:30:54 2011 +0100 libxl: Introduce a QMP client QMP stands for QEMU Monitor Protocol and it is used to query information from QEMU or to control QEMU. This implementation will ask QEMU the list of chardevice and store the path to serial ports in xenstored. So we will be able to use xl console with QEMU upstream. In order to connect to the QMP server, a socket file is created in /var/run/xen/qmp-libxl-$(domid). Signed-off-by: Anthony PERARD <anthony.perard@citrix.com> Committed-by: Ian Jackson <ian.jackson@eu.citrix.com> changeset: 23892:5f397994e6d6 user: Anthony PERARD <anthony.perard@citrix.com> date: Thu Sep 29 16:28:24 2011 +0100 libxl: Introduce JSON parser We use the yajl parser, but we need to make a tree from the parse result to use it outside the parser. So this patch include json_object struct that is used to hold the JSON data. Signed-off-by: Anthony PERARD <anthony.perard@citrix.com> Committed-by: Ian Jackson <ian.jackson.citrix.com> Acked-by: Ian Campbell <ian.campbell@citrix.com> changeset: 23891:066dc3758fa4 user: Anthony PERARD <anthony.perard@citrix.com> date: Thu Sep 29 16:28:23 2011 +0100 libxl: Intruduce libxl__strndup. Signed-off-by: Anthony PERARD <anthony.perard@citrix.com> Committed-by: Ian Jackson <ian.jackson.citrix.com> Acked-by: Ian Campbell <ian.campbell@citrix.com> changeset: 23890:952e0118a7c4 user: Anthony PERARD <anthony.perard@citrix.com> date: Thu Sep 29 16:28:22 2011 +0100 libxl: Introduce libxl__realloc. Signed-off-by: Anthony PERARD <anthony.perard@citrix.com> Committed-by: Ian Jackson <ian.jackson.citrix.com> Acked-by: Ian Campbell <ian.campbell@citrix.com> changeset: 23889:f51dcd8acb7b user: Anthony PERARD <anthony.perard@citrix.com> date: Thu Sep 29 16:28:22 2011 +0100 libxl: Introduce libxl_internal_types.idl. Signed-off-by: Anthony PERARD <anthony.perard@citrix.com> Committed-by: Ian Jackson <ian.jackson.citrix.com> Acked-by: Ian Campbell <ian.campbell@citrix.com> changeset: 23888:f5ee5ad45425 user: Anthony PERARD <anthony.perard@citrix.com> date: Thu Sep 29 16:28:21 2011 +0100 libxl: Add get/set_default_namespace in libxltypes.py. Signed-off-by: Anthony PERARD <anthony.perard@citrix.com> Committed-by: Ian Jackson <ian.jackson.citrix.com> Acked-by: Ian Campbell <ian.campbell@citrix.com> changeset: 23887:a543e10211f7 user: Anthony PERARD <anthony.perard@citrix.com> date: Thu Sep 29 16:28:20 2011 +0100 libxl: Rename libxl.idl to libxl_types.idl. Signed-off-by: Anthony PERARD <anthony.perard@citrix.com> Committed-by: Ian Jackson <ian.jackson.citrix.com> Acked-by: Ian Campbell <ian.campbell@citrix.com> changeset: 23886:cf2ba5720151 user: Anthony PERARD <anthony.perard@citrix.com> date: Thu Sep 29 16:06:02 2011 +0100 libxl: Introduce libxl__fd_set_cloexec Signed-off-by: Anthony PERARD <anthony.perard@citrix.com> Acked-by: Ian Jackson <ian.jackson@eu.citrix.com> Committed-by: Ian Jackson <ian.jackson@eu.citrix.com> changeset: 23885:cd60c87d3496 user: Ian Campbell <ian.campbell@citrix.com> date: Thu Sep 29 15:40:34 2011 +0100 xl: fixup command line handling for several commands. def_getopt already checks for a minimum number of arguments for us. "xl save" simply need to use the correct argument for that value, contrary to the change I made in 23876:b113d626cfaf "xl block-list" does not need to check for at least 2 arguments, since it's already been done by def_getopt. "xl network-list" would previous accept zero arguments and just print the table header. Insist on a domain argument. Signed-off-by: Ian Campbell <ian.campbell@citrix.com> Acked-by: Ian Jackson <ian.jackson@eu.citrix.com> Committed-by: Ian Jackson <ian.jackson@eu.citrix.com> changeset: 23884:145e146876b3 user: Adin Scannell <adin@gridcentric.com> date: Thu Sep 29 15:26:04 2011 +0100 libxl: Expose number of shared pages Signed-off-by: Adin Scannell <adin@scannell.ca> Acked-by: Ian Jackson <ian.jackson@eu.citrix.com> Committed-by: Ian Jackson <ian.jackson@eu.citrix.com> changeset: 23883:7998217630e2 user: Ian Campbell <ian.campbell@citrix.com> date: Wed Sep 28 16:42:11 2011 +0100 libxl: attempt to cleanup tapdisk processes on disk backend destroy. Signed-off-by: Ian Campbell <ian.campbell@citrix.com> Committed-by: Ian Jackson <ian.jackson@eu.citrix.com> ======================================== commit cd776ee9408ff127f934a707c1a339ee600bc127 Author: Ian Jackson <ian.jackson@eu.citrix.com> Date: Tue Jun 28 13:50:53 2011 +0100 qemu-char.c: fix incorrect CONFIG_STUBDOM handling qemu-char.c:1123:7: warning: "CONFIG_STUBDOM" is not defined [-Wundef] Signed-off-by: Olaf Hering <olaf@aepfle.de> Acked-by: Ian Jackson <ian.jackson@eu.citrix.com> _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel From xen-devel-bounces@lists.xensource.com Thu Sep 29 16:10:27 2011 Return-path: <xen-devel-bounces@lists.xensource.com> Envelope-to: www-data@lists.xensource.com Delivery-date: Thu, 29 Sep 2011 16:10:27 -0700 Received: from localhost ([127.0.0.1] helo=lists.colo.xensource.com) by lists.xensource.com with esmtp (Exim 4.43) id 1R9PkJ-00087b-By; Thu, 29 Sep 2011 16:10:27 -0700 Received: from mail182.messagelabs.com ([85.158.139.83]) by lists.xensource.com with esmtp (Exim 4.43) id 1R9Pjd-0007uz-E5 for xen-devel@lists.xensource.com; Thu, 29 Sep 2011 16:09:45 -0700 X-Env-Sender: konrad@oracle.com X-Msg-Ref: server-10.tower-182.messagelabs.com!1317337780!20274434!1 X-Originating-IP: [148.87.113.117] X-StarScan-Version: 6.4.1; banners=-,-,- X-VirusChecked: Checked Received: (qmail 30705 invoked from network); 29 Sep 2011 23:09:42 -0000 Received: from rcsinet15.oracle.com (HELO rcsinet15.oracle.com) (148.87.113.117) by server-10.tower-182.messagelabs.com with DHE-RSA-AES256-SHA encrypted SMTP; 29 Sep 2011 23:09:42 -0000 Received: from ucsinet23.oracle.com (ucsinet23.oracle.com [156.151.31.71]) by rcsinet15.oracle.com (Switch-3.4.4/Switch-3.4.4) with ESMTP id p8TN9cQo002325 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL) for <xen-devel@lists.xensource.com>; Thu, 29 Sep 2011 23:09:40 GMT Received: from acsmt356.oracle.com (acsmt356.oracle.com [141.146.40.156]) by ucsinet23.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id p8TN9bUO002220 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for <xen-devel@lists.xensource.com>; Thu, 29 Sep 2011 23:09:38 GMT Received: from abhmt105.oracle.com (abhmt105.oracle.com [141.146.116.57]) by acsmt356.oracle.com (8.12.11.20060308/8.12.11) with ESMTP id p8TN9WYH015519 for <xen-devel@lists.xensource.com>; Thu, 29 Sep 2011 18:09:32 -0500 Received: from oracle.com (/207.172.105.198) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Thu, 29 Sep 2011 16:09:32 -0700 Received: by oracle.com (Postfix, from userid 1000) id 9BEE4154A; Thu, 29 Sep 2011 19:09:31 -0400 (EDT) Date: Thu, 29 Sep 2011 19:09:31 -0400 From: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com> To: xen-devel@lists.xensource.com Message-ID: <20110929230931.GA12858@phenom.oracle.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.5.21 (2010-09-15) X-Source-IP: ucsinet23.oracle.com [156.151.31.71] X-CT-RefId: str=0001.0A090203.4E84FAB4.0048,ss=1,re=0.000,fgs=0 Subject: [Xen-devel] xm list vs xl list (Fedora Core 16, Xen 4.1.1) X-BeenThere: xen-devel@lists.xensource.com X-Mailman-Version: 2.1.5 Precedence: list List-Id: Xen developer discussion <xen-devel.lists.xensource.com> List-Unsubscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe> List-Post: <mailto:xen-devel@lists.xensource.com> List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help> List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=subscribe> Sender: xen-devel-bounces@lists.xensource.com Errors-To: xen-devel-bounces@lists.xensource.com So Fedora 16 is using Xen 4.1.1 and I am seeing some weird things that I *think* we fixed at some point but maybe not? [root@tst004 ~]# xl list Name ID Mem VCPUs State Time(s) Domain-0 0 3917 2 r----- 35.4 [root@tst004 ~]# xm list Name ID Mem VCPUs State Time(s) Domain-0 0 3726 2 r----- 35.6 So a bit off.. And then: [root@tst004 ~]# xl mem-set 0 3000 libxl: error: libxl.c:2114:libxl_set_memory_target cannot get memory info from /local/domain/0/memory/static-max : No such file or directory Anybody remember what this might be? Should we back-port some extra changes in 4.1-testing? What is also weird is if I do xm mem-set 0 3000 after the ballooning is done I get: [root@tst004 ~]# xl list Name ID Mem VCPUs State Time(s) Domain-0 0 2281 2 r----- 38.7 [root@tst004 ~]# xm list Name ID Mem VCPUs State Time(s) Domain-0 0 3000 2 r----- 38.9 The 'xl list' is more accurate, as we have "2034404" memory (so it is still off a bit). _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel From xen-devel-bounces@lists.xensource.com Thu Sep 29 16:27:46 2011 Return-path: <xen-devel-bounces@lists.xensource.com> Envelope-to: www-data@lists.xensource.com Delivery-date: Thu, 29 Sep 2011 16:27:47 -0700 Received: from localhost ([127.0.0.1] helo=lists.colo.xensource.com) by lists.xensource.com with esmtp (Exim 4.43) id 1R9Q14-0000JK-Li; Thu, 29 Sep 2011 16:27:46 -0700 Received: from mail174.messagelabs.com ([85.158.138.51]) by lists.xensource.com with esmtp (Exim 4.43) id 1R9Q0B-00005n-EU for xen-devel@lists.xensource.com; Thu, 29 Sep 2011 16:26:54 -0700 X-Env-Sender: jeremy@goop.org X-Msg-Ref: server-9.tower-174.messagelabs.com!1317338806!27261440!1 X-Originating-IP: [74.207.240.146] X-StarScan-Version: 6.4.1; banners=-,-,- X-VirusChecked: Checked Received: (qmail 11807 invoked from network); 29 Sep 2011 23:26:48 -0000 Received: from claw.goop.org (HELO claw.goop.org) (74.207.240.146) by server-9.tower-174.messagelabs.com with DHE-RSA-AES256-SHA encrypted SMTP; 29 Sep 2011 23:26:48 -0000 Received: from saboo.goop.org (unknown [IPv6:2001:470:1f05:899:2805:8fff:fe05:2e54]) (Authenticated sender: smtp-saboo) by claw.goop.org (Postfix) with ESMTPSA id A3DDC2FC; Thu, 29 Sep 2011 16:26:43 -0700 (PDT) Received: by saboo.goop.org (Postfix, from userid 500) id 2DCA820F94; Thu, 29 Sep 2011 16:26:39 -0700 (PDT) From: Jeremy Fitzhardinge <jeremy@goop.org> To: Steven Rostedt <rostedt@goodmis.org> Date: Thu, 29 Sep 2011 16:26:30 -0700 Message-Id: <cover.1317338254.git.jeremy.fitzhardinge@citrix.com> X-Mailer: git-send-email 1.7.6.2 Cc: Xen Devel <xen-devel@lists.xensource.com>, Jan Glauber <jang@linux.vnet.ibm.com>, Jason Baron <jbaron@redhat.com>, the arch/x86 maintainers <x86@kernel.org>, David Daney <david.daney@cavium.com>, Linux Kernel Mailing List <linux-kernel@vger.kernel.org>, Michael Ellerman <michael@ellerman.id.au>, Jeremy Fitzhardinge <jeremy.fitzhardinge@citrix.com>, "David S. Miller" <davem@davemloft.net> Subject: [Xen-devel] [PATCH RFC 0/8] jump-label: allow early jump_label_enable() X-BeenThere: xen-devel@lists.xensource.com X-Mailman-Version: 2.1.5 Precedence: list List-Id: Xen developer discussion <xen-devel.lists.xensource.com> List-Unsubscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe> List-Post: <mailto:xen-devel@lists.xensource.com> List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help> List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=subscribe> Sender: xen-devel-bounces@lists.xensource.com Errors-To: xen-devel-bounces@lists.xensource.com From: Jeremy Fitzhardinge <jeremy.fitzhardinge@citrix.com> Hi all, While trying to use the jump-label stuff for my PV ticketlock changes, I had some problems using jump labels early in the kernel's lifetime (pre-SMP). The basic problem is that even if I enable a jump_label_key, the jump_label_init() initializer ends up nopping out all the code sites. This series enables early use of jump labels by making jump_label_init() respect already-enabled keys. To do this, I've dropped arch_jump_label_poke_text_early() and replaced it with arch_jump_label_transform_early(), which is the same as the non-_early variant except that it expects to be operating in a pre-SMP environment. I've tested this on x86, but all the other architecture changes are completely untested (not even breathed on by a compiler). One big question which arises is whether the _early() function is necessary at all. All the stop_machine/mutex/etc stuff that arch_jump_label_transform() ends up doing is redundant pre-SMP, but it shouldn't hurt. Maybe we can just drop the _early function? It works on x86, at least, because jump_label_enable() works, which uses the full form. And dropping it would reduce this to a very much smaller series. Thanks, J Jeremy Fitzhardinge (8): jump_label: use proper atomic_t initializer jump_label: if a key has already been initialized, don't nop it out x86/jump_label: add arch_jump_label_transform_early() sparc/jump_label: add arch_jump_label_transform_early() mips/jump_label: add arch_jump_label_transform_early() powerpc/jump_label: add arch_jump_label_transform_early() s390/jump-label: add arch_jump_label_transform_early() jump_label: drop default arch_jump_label_transform_early arch/mips/kernel/jump_label.c | 21 +++++++++++++--- arch/powerpc/kernel/jump_label.c | 6 ++++ arch/s390/kernel/jump_label.c | 49 +++++++++++++++++++++++-------------- arch/sparc/kernel/jump_label.c | 24 +++++++++++------- arch/x86/kernel/jump_label.c | 20 +++++++++++---- include/linux/jump_label.h | 7 +++-- kernel/jump_label.c | 20 ++++++--------- 7 files changed, 94 insertions(+), 53 deletions(-) -- 1.7.6.2 _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel From xen-devel-bounces@lists.xensource.com Thu Sep 29 16:29:10 2011 Return-path: <xen-devel-bounces@lists.xensource.com> Envelope-to: www-data@lists.xensource.com Delivery-date: Thu, 29 Sep 2011 16:29:10 -0700 Received: from localhost ([127.0.0.1] helo=lists.colo.xensource.com) by lists.xensource.com with esmtp (Exim 4.43) id 1R9Q2Q-0000hT-9O; Thu, 29 Sep 2011 16:29:10 -0700 Received: from mail174.messagelabs.com ([85.158.138.51]) by lists.xensource.com with esmtp (Exim 4.43) id 1R9Q0E-00005o-9s for xen-devel@lists.xensource.com; Thu, 29 Sep 2011 16:26:54 -0700 X-Env-Sender: jeremy@goop.org X-Msg-Ref: server-3.tower-174.messagelabs.com!1317338809!27239026!1 X-Originating-IP: [74.207.240.146] X-StarScan-Version: 6.4.1; banners=-,-,- X-VirusChecked: Checked Received: (qmail 5107 invoked from network); 29 Sep 2011 23:26:51 -0000 Received: from claw.goop.org (HELO claw.goop.org) (74.207.240.146) by server-3.tower-174.messagelabs.com with DHE-RSA-AES256-SHA encrypted SMTP; 29 Sep 2011 23:26:51 -0000 Received: from saboo.goop.org (unknown [IPv6:2001:470:1f05:899:2805:8fff:fe05:2e54]) (Authenticated sender: smtp-saboo) by claw.goop.org (Postfix) with ESMTPSA id D3A26326; Thu, 29 Sep 2011 16:26:43 -0700 (PDT) Received: by saboo.goop.org (Postfix, from userid 500) id 30F8820334; Thu, 29 Sep 2011 16:26:39 -0700 (PDT) From: Jeremy Fitzhardinge <jeremy@goop.org> To: Steven Rostedt <rostedt@goodmis.org> Date: Thu, 29 Sep 2011 16:26:31 -0700 Message-Id: <0b202e43573ff2fba673ca375a95d757ed9a3f36.1317338254.git.jeremy.fitzhardinge@citrix.com> X-Mailer: git-send-email 1.7.6.2 In-Reply-To: <cover.1317338254.git.jeremy.fitzhardinge@citrix.com> References: <cover.1317338254.git.jeremy.fitzhardinge@citrix.com> In-Reply-To: <cover.1317338254.git.jeremy.fitzhardinge@citrix.com> References: <cover.1317338254.git.jeremy.fitzhardinge@citrix.com> Cc: Xen Devel <xen-devel@lists.xensource.com>, Jan Glauber <jang@linux.vnet.ibm.com>, Jason Baron <jbaron@redhat.com>, the arch/x86 maintainers <x86@kernel.org>, David Daney <david.daney@cavium.com>, Linux Kernel Mailing List <linux-kernel@vger.kernel.org>, Michael Ellerman <michael@ellerman.id.au>, Jeremy Fitzhardinge <jeremy.fitzhardinge@citrix.com>, "David S. Miller" <davem@davemloft.net> Subject: [Xen-devel] [PATCH RFC 1/8] jump_label: use proper atomic_t initializer X-BeenThere: xen-devel@lists.xensource.com X-Mailman-Version: 2.1.5 Precedence: list List-Id: Xen developer discussion <xen-devel.lists.xensource.com> List-Unsubscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe> List-Post: <mailto:xen-devel@lists.xensource.com> List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help> List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=subscribe> Sender: xen-devel-bounces@lists.xensource.com Errors-To: xen-devel-bounces@lists.xensource.com From: Jeremy Fitzhardinge <jeremy.fitzhardinge@citrix.com> ATOMIC_INIT() is the proper thing to use. Signed-off-by: Jeremy Fitzhardinge <jeremy.fitzhardinge@citrix.com> --- include/linux/jump_label.h | 4 ++-- 1 files changed, 2 insertions(+), 2 deletions(-) diff --git a/include/linux/jump_label.h b/include/linux/jump_label.h index 66f23dc..1213e9d 100644 --- a/include/linux/jump_label.h +++ b/include/linux/jump_label.h @@ -28,9 +28,9 @@ struct module; #ifdef HAVE_JUMP_LABEL #ifdef CONFIG_MODULES -#define JUMP_LABEL_INIT {{ 0 }, NULL, NULL} +#define JUMP_LABEL_INIT {ATOMIC_INIT(0), NULL, NULL} #else -#define JUMP_LABEL_INIT {{ 0 }, NULL} +#define JUMP_LABEL_INIT {ATOMIC_INIT(0), NULL} #endif static __always_inline bool static_branch(struct jump_label_key *key) -- 1.7.6.2 _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel From xen-devel-bounces@lists.xensource.com Thu Sep 29 16:30:11 2011 Return-path: <xen-devel-bounces@lists.xensource.com> Envelope-to: www-data@lists.xensource.com Delivery-date: Thu, 29 Sep 2011 16:30:11 -0700 Received: from localhost ([127.0.0.1] helo=lists.colo.xensource.com) by lists.xensource.com with esmtp (Exim 4.43) id 1R9Q3P-00014E-A8; Thu, 29 Sep 2011 16:30:11 -0700 Received: from mail216.messagelabs.com ([85.158.143.99]) by lists.xensource.com with esmtp (Exim 4.43) id 1R9Q0F-00005r-2O for xen-devel@lists.xensource.com; Thu, 29 Sep 2011 16:26:55 -0700 X-Env-Sender: jeremy@goop.org X-Msg-Ref: server-4.tower-216.messagelabs.com!1317338810!20046970!1 X-Originating-IP: [74.207.240.146] X-StarScan-Version: 6.4.1; banners=-,-,- X-VirusChecked: Checked Received: (qmail 9587 invoked from network); 29 Sep 2011 23:26:52 -0000 Received: from claw.goop.org (HELO claw.goop.org) (74.207.240.146) by server-4.tower-216.messagelabs.com with DHE-RSA-AES256-SHA encrypted SMTP; 29 Sep 2011 23:26:52 -0000 Received: from saboo.goop.org (unknown [IPv6:2001:470:1f05:899:2805:8fff:fe05:2e54]) (Authenticated sender: smtp-saboo) by claw.goop.org (Postfix) with ESMTPSA id 259F7327; Thu, 29 Sep 2011 16:26:44 -0700 (PDT) Received: by saboo.goop.org (Postfix, from userid 500) id 39A5820FAB; Thu, 29 Sep 2011 16:26:39 -0700 (PDT) From: Jeremy Fitzhardinge <jeremy@goop.org> To: Steven Rostedt <rostedt@goodmis.org> Date: Thu, 29 Sep 2011 16:26:33 -0700 Message-Id: <ab9dd31d526e98cd2008b2fc5af9e16972f9aff3.1317338254.git.jeremy.fitzhardinge@citrix.com> X-Mailer: git-send-email 1.7.6.2 In-Reply-To: <cover.1317338254.git.jeremy.fitzhardinge@citrix.com> References: <cover.1317338254.git.jeremy.fitzhardinge@citrix.com> In-Reply-To: <cover.1317338254.git.jeremy.fitzhardinge@citrix.com> References: <cover.1317338254.git.jeremy.fitzhardinge@citrix.com> Cc: Xen Devel <xen-devel@lists.xensource.com>, Jan Glauber <jang@linux.vnet.ibm.com>, Jason Baron <jbaron@redhat.com>, the arch/x86 maintainers <x86@kernel.org>, David Daney <david.daney@cavium.com>, Linux Kernel Mailing List <linux-kernel@vger.kernel.org>, Michael Ellerman <michael@ellerman.id.au>, Jeremy Fitzhardinge <jeremy.fitzhardinge@citrix.com>, "David S. Miller" <davem@davemloft.net> Subject: [Xen-devel] [PATCH RFC 3/8] x86/jump_label: add arch_jump_label_transform_early() X-BeenThere: xen-devel@lists.xensource.com X-Mailman-Version: 2.1.5 Precedence: list List-Id: Xen developer discussion <xen-devel.lists.xensource.com> List-Unsubscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe> List-Post: <mailto:xen-devel@lists.xensource.com> List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help> List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=subscribe> Sender: xen-devel-bounces@lists.xensource.com Errors-To: xen-devel-bounces@lists.xensource.com From: Jeremy Fitzhardinge <jeremy.fitzhardinge@citrix.com> This allows jump-label entries to be modified early, in a pre-SMP environment. Signed-off-by: Jeremy Fitzhardinge <jeremy.fitzhardinge@citrix.com> Cc: Jason Baron <jbaron@redhat.com> --- arch/x86/kernel/jump_label.c | 20 ++++++++++++++------ 1 files changed, 14 insertions(+), 6 deletions(-) diff --git a/arch/x86/kernel/jump_label.c b/arch/x86/kernel/jump_label.c index 3fee346..0887b59 100644 --- a/arch/x86/kernel/jump_label.c +++ b/arch/x86/kernel/jump_label.c @@ -24,8 +24,9 @@ union jump_code_union { } __attribute__((packed)); }; -void arch_jump_label_transform(struct jump_entry *entry, - enum jump_label_type type) +static void __jump_label_transform(struct jump_entry *entry, + enum jump_label_type type, + void *(*poker)(void *, const void *, size_t)) { union jump_code_union code; @@ -35,17 +36,24 @@ void arch_jump_label_transform(struct jump_entry *entry, (entry->code + JUMP_LABEL_NOP_SIZE); } else memcpy(&code, ideal_nops[NOP_ATOMIC5], JUMP_LABEL_NOP_SIZE); + + (*poker)((void *)entry->code, &code, JUMP_LABEL_NOP_SIZE); +} + +void arch_jump_label_transform(struct jump_entry *entry, + enum jump_label_type type) +{ get_online_cpus(); mutex_lock(&text_mutex); - text_poke_smp((void *)entry->code, &code, JUMP_LABEL_NOP_SIZE); + __jump_label_transform(entry, type, text_poke_smp); mutex_unlock(&text_mutex); put_online_cpus(); } -void arch_jump_label_text_poke_early(jump_label_t addr) +void __init arch_jump_label_transform_early(struct jump_entry *entry, + enum jump_label_type type) { - text_poke_early((void *)addr, ideal_nops[NOP_ATOMIC5], - JUMP_LABEL_NOP_SIZE); + __jump_label_transform(entry, type, text_poke_early); } #endif -- 1.7.6.2 _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel From xen-devel-bounces@lists.xensource.com Thu Sep 29 16:31:01 2011 Return-path: <xen-devel-bounces@lists.xensource.com> Envelope-to: www-data@lists.xensource.com Delivery-date: Thu, 29 Sep 2011 16:31:01 -0700 Received: from localhost ([127.0.0.1] helo=lists.colo.xensource.com) by lists.xensource.com with esmtp (Exim 4.43) id 1R9Q4C-0001QB-U0; Thu, 29 Sep 2011 16:31:00 -0700 Received: from mail182.messagelabs.com ([85.158.139.83]) by lists.xensource.com with esmtp (Exim 4.43) id 1R9Q0F-00005s-VA for xen-devel@lists.xensource.com; Thu, 29 Sep 2011 16:26:58 -0700 X-Env-Sender: jeremy@goop.org X-Msg-Ref: server-13.tower-182.messagelabs.com!1317338811!20137437!1 X-Originating-IP: [74.207.240.146] X-StarScan-Version: 6.4.1; banners=-,-,- X-VirusChecked: Checked Received: (qmail 11021 invoked from network); 29 Sep 2011 23:26:52 -0000 Received: from claw.goop.org (HELO claw.goop.org) (74.207.240.146) by server-13.tower-182.messagelabs.com with DHE-RSA-AES256-SHA encrypted SMTP; 29 Sep 2011 23:26:52 -0000 Received: from saboo.goop.org (unknown [IPv6:2001:470:1f05:899:2805:8fff:fe05:2e54]) (Authenticated sender: smtp-saboo) by claw.goop.org (Postfix) with ESMTPSA id 6BDDA8F35; Thu, 29 Sep 2011 16:26:50 -0700 (PDT) Received: by saboo.goop.org (Postfix, from userid 500) id 4338020FAD; Thu, 29 Sep 2011 16:26:39 -0700 (PDT) From: Jeremy Fitzhardinge <jeremy@goop.org> To: Steven Rostedt <rostedt@goodmis.org> Date: Thu, 29 Sep 2011 16:26:35 -0700 Message-Id: <9f95a611c3b317f412f77ae06753752951afd38b.1317338254.git.jeremy.fitzhardinge@citrix.com> X-Mailer: git-send-email 1.7.6.2 In-Reply-To: <cover.1317338254.git.jeremy.fitzhardinge@citrix.com> References: <cover.1317338254.git.jeremy.fitzhardinge@citrix.com> In-Reply-To: <cover.1317338254.git.jeremy.fitzhardinge@citrix.com> References: <cover.1317338254.git.jeremy.fitzhardinge@citrix.com> Cc: Xen Devel <xen-devel@lists.xensource.com>, Jan Glauber <jang@linux.vnet.ibm.com>, Jason Baron <jbaron@redhat.com>, the arch/x86 maintainers <x86@kernel.org>, David Daney <david.daney@cavium.com>, Linux Kernel Mailing List <linux-kernel@vger.kernel.org>, Michael Ellerman <michael@ellerman.id.au>, Jeremy Fitzhardinge <jeremy.fitzhardinge@citrix.com>, "David S. Miller" <davem@davemloft.net> Subject: [Xen-devel] [PATCH RFC 5/8] mips/jump_label: add arch_jump_label_transform_early() X-BeenThere: xen-devel@lists.xensource.com X-Mailman-Version: 2.1.5 Precedence: list List-Id: Xen developer discussion <xen-devel.lists.xensource.com> List-Unsubscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe> List-Post: <mailto:xen-devel@lists.xensource.com> List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help> List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=subscribe> Sender: xen-devel-bounces@lists.xensource.com Errors-To: xen-devel-bounces@lists.xensource.com From: Jeremy Fitzhardinge <jeremy.fitzhardinge@citrix.com> This allows jump-label entries to be modified early, in a pre-SMP environment. XXX TODO: make sure idling CPUs flush their icaches before continuing in case this modifies something that's adjacent to their init-idle loops. Signed-off-by: Jeremy Fitzhardinge <jeremy.fitzhardinge@citrix.com> Cc: David Daney <david.daney@cavium.com> --- arch/mips/kernel/jump_label.c | 21 +++++++++++++++++---- 1 files changed, 17 insertions(+), 4 deletions(-) diff --git a/arch/mips/kernel/jump_label.c b/arch/mips/kernel/jump_label.c index 6001610..ddc9a65 100644 --- a/arch/mips/kernel/jump_label.c +++ b/arch/mips/kernel/jump_label.c @@ -20,8 +20,8 @@ #define J_RANGE_MASK ((1ul << 28) - 1) -void arch_jump_label_transform(struct jump_entry *e, - enum jump_label_type type) +static void __jump_label_transform(struct jump_entry *e, + enum jump_label_type type) { union mips_instruction insn; union mips_instruction *insn_p = @@ -40,15 +40,28 @@ void arch_jump_label_transform(struct jump_entry *e, insn.word = 0; /* nop */ } - get_online_cpus(); - mutex_lock(&text_mutex); *insn_p = insn; flush_icache_range((unsigned long)insn_p, (unsigned long)insn_p + sizeof(*insn_p)); +} + +void arch_jump_label_transform(struct jump_entry *e, + enum jump_label_type type) +{ + get_online_cpus(); + mutex_lock(&text_mutex); + + __jump_label_tranform(e, type); mutex_unlock(&text_mutex); put_online_cpus(); } +void __init arch_jump_label_transform_early(struct jump_entry *e, + enum jump_label_type type) +{ + __jump_label_tranform(e, type); +} + #endif /* HAVE_JUMP_LABEL */ -- 1.7.6.2 _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel From xen-devel-bounces@lists.xensource.com Thu Sep 29 16:31:44 2011 Return-path: <xen-devel-bounces@lists.xensource.com> Envelope-to: www-data@lists.xensource.com Delivery-date: Thu, 29 Sep 2011 16:31:44 -0700 Received: from localhost ([127.0.0.1] helo=lists.colo.xensource.com) by lists.xensource.com with esmtp (Exim 4.43) id 1R9Q4u-0001mh-DR; Thu, 29 Sep 2011 16:31:44 -0700 Received: from mail174.messagelabs.com ([85.158.138.51]) by lists.xensource.com with esmtp (Exim 4.43) id 1R9Q0H-000064-T3 for xen-devel@lists.xensource.com; Thu, 29 Sep 2011 16:26:58 -0700 X-Env-Sender: jeremy@goop.org X-Msg-Ref: server-11.tower-174.messagelabs.com!1317338813!33285881!1 X-Originating-IP: [74.207.240.146] X-StarScan-Version: 6.4.1; banners=-,-,- X-VirusChecked: Checked Received: (qmail 31015 invoked from network); 29 Sep 2011 23:26:54 -0000 Received: from claw.goop.org (HELO claw.goop.org) (74.207.240.146) by server-11.tower-174.messagelabs.com with DHE-RSA-AES256-SHA encrypted SMTP; 29 Sep 2011 23:26:54 -0000 Received: from saboo.goop.org (unknown [IPv6:2001:470:1f05:899:2805:8fff:fe05:2e54]) (Authenticated sender: smtp-saboo) by claw.goop.org (Postfix) with ESMTPSA id B90FA8F3F; Thu, 29 Sep 2011 16:26:51 -0700 (PDT) Received: by saboo.goop.org (Postfix, from userid 500) id 4728220FAE; Thu, 29 Sep 2011 16:26:39 -0700 (PDT) From: Jeremy Fitzhardinge <jeremy@goop.org> To: Steven Rostedt <rostedt@goodmis.org> Date: Thu, 29 Sep 2011 16:26:36 -0700 Message-Id: <2094e79203a950e210b579284330a1b8b774cbdd.1317338254.git.jeremy.fitzhardinge@citrix.com> X-Mailer: git-send-email 1.7.6.2 In-Reply-To: <cover.1317338254.git.jeremy.fitzhardinge@citrix.com> References: <cover.1317338254.git.jeremy.fitzhardinge@citrix.com> In-Reply-To: <cover.1317338254.git.jeremy.fitzhardinge@citrix.com> References: <cover.1317338254.git.jeremy.fitzhardinge@citrix.com> Cc: Xen Devel <xen-devel@lists.xensource.com>, Jan Glauber <jang@linux.vnet.ibm.com>, Jason Baron <jbaron@redhat.com>, the arch/x86 maintainers <x86@kernel.org>, David Daney <david.daney@cavium.com>, Linux Kernel Mailing List <linux-kernel@vger.kernel.org>, Michael Ellerman <michael@ellerman.id.au>, Jeremy Fitzhardinge <jeremy.fitzhardinge@citrix.com>, "David S. Miller" <davem@davemloft.net> Subject: [Xen-devel] [PATCH RFC 6/8] powerpc/jump_label: add arch_jump_label_transform_early() X-BeenThere: xen-devel@lists.xensource.com X-Mailman-Version: 2.1.5 Precedence: list List-Id: Xen developer discussion <xen-devel.lists.xensource.com> List-Unsubscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe> List-Post: <mailto:xen-devel@lists.xensource.com> List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help> List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=subscribe> Sender: xen-devel-bounces@lists.xensource.com Errors-To: xen-devel-bounces@lists.xensource.com From: Jeremy Fitzhardinge <jeremy.fitzhardinge@citrix.com> This allows jump-label entries to be modified early, in a pre-SMP environment. Signed-off-by: Jeremy Fitzhardinge <jeremy.fitzhardinge@citrix.com> Cc: Michael Ellerman <michael@ellerman.id.au> --- arch/powerpc/kernel/jump_label.c | 6 ++++++ 1 files changed, 6 insertions(+), 0 deletions(-) diff --git a/arch/powerpc/kernel/jump_label.c b/arch/powerpc/kernel/jump_label.c index 368d158..20c82fb 100644 --- a/arch/powerpc/kernel/jump_label.c +++ b/arch/powerpc/kernel/jump_label.c @@ -21,3 +21,9 @@ void arch_jump_label_transform(struct jump_entry *entry, else patch_instruction(addr, PPC_INST_NOP); } + +void __init arch_jump_label_transform_early(struct jump_entry *entry, + enum jump_label_type type) +{ + arch_jump_label_transform(entry, type); +} -- 1.7.6.2 _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel From xen-devel-bounces@lists.xensource.com Thu Sep 29 16:32:30 2011 Return-path: <xen-devel-bounces@lists.xensource.com> Envelope-to: www-data@lists.xensource.com Delivery-date: Thu, 29 Sep 2011 16:32:30 -0700 Received: from localhost ([127.0.0.1] helo=lists.colo.xensource.com) by lists.xensource.com with esmtp (Exim 4.43) id 1R9Q5e-0002Bh-Sj; Thu, 29 Sep 2011 16:32:30 -0700 Received: from mail216.messagelabs.com ([85.158.143.99]) by lists.xensource.com with esmtp (Exim 4.43) id 1R9Q0H-000065-Um for xen-devel@lists.xensource.com; Thu, 29 Sep 2011 16:26:58 -0700 X-Env-Sender: jeremy@goop.org X-Msg-Ref: server-15.tower-216.messagelabs.com!1317338812!19534794!1 X-Originating-IP: [74.207.240.146] X-StarScan-Version: 6.4.1; banners=-,-,- X-VirusChecked: Checked Received: (qmail 21252 invoked from network); 29 Sep 2011 23:26:54 -0000 Received: from claw.goop.org (HELO claw.goop.org) (74.207.240.146) by server-15.tower-216.messagelabs.com with DHE-RSA-AES256-SHA encrypted SMTP; 29 Sep 2011 23:26:54 -0000 Received: from saboo.goop.org (unknown [IPv6:2001:470:1f05:899:2805:8fff:fe05:2e54]) (Authenticated sender: smtp-saboo) by claw.goop.org (Postfix) with ESMTPSA id 1279E8F3D; Thu, 29 Sep 2011 16:26:51 -0700 (PDT) Received: by saboo.goop.org (Postfix, from userid 500) id 4C8B820FAF; Thu, 29 Sep 2011 16:26:39 -0700 (PDT) From: Jeremy Fitzhardinge <jeremy@goop.org> To: Steven Rostedt <rostedt@goodmis.org> Date: Thu, 29 Sep 2011 16:26:37 -0700 Message-Id: <b1d87557dc3001031ee8d7f69ee97b90cecba6aa.1317338254.git.jeremy.fitzhardinge@citrix.com> X-Mailer: git-send-email 1.7.6.2 In-Reply-To: <cover.1317338254.git.jeremy.fitzhardinge@citrix.com> References: <cover.1317338254.git.jeremy.fitzhardinge@citrix.com> In-Reply-To: <cover.1317338254.git.jeremy.fitzhardinge@citrix.com> References: <cover.1317338254.git.jeremy.fitzhardinge@citrix.com> Cc: Xen Devel <xen-devel@lists.xensource.com>, Jan Glauber <jang@linux.vnet.ibm.com>, Jason Baron <jbaron@redhat.com>, the arch/x86 maintainers <x86@kernel.org>, David Daney <david.daney@cavium.com>, Linux Kernel Mailing List <linux-kernel@vger.kernel.org>, Michael Ellerman <michael@ellerman.id.au>, Jeremy Fitzhardinge <jeremy.fitzhardinge@citrix.com>, "David S. Miller" <davem@davemloft.net> Subject: [Xen-devel] [PATCH RFC 7/8] s390/jump-label: add arch_jump_label_transform_early() X-BeenThere: xen-devel@lists.xensource.com X-Mailman-Version: 2.1.5 Precedence: list List-Id: Xen developer discussion <xen-devel.lists.xensource.com> List-Unsubscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe> List-Post: <mailto:xen-devel@lists.xensource.com> List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help> List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=subscribe> Sender: xen-devel-bounces@lists.xensource.com Errors-To: xen-devel-bounces@lists.xensource.com From: Jeremy Fitzhardinge <jeremy.fitzhardinge@citrix.com> This allows jump-label entries to be modified early, in a pre-SMP environment. Signed-off-by: Jeremy Fitzhardinge <jeremy.fitzhardinge@citrix.com> Cc: Jan Glauber <jang@linux.vnet.ibm.com> --- arch/s390/kernel/jump_label.c | 49 +++++++++++++++++++++++++---------------- 1 files changed, 30 insertions(+), 19 deletions(-) diff --git a/arch/s390/kernel/jump_label.c b/arch/s390/kernel/jump_label.c index 44cc06b..6001228 100644 --- a/arch/s390/kernel/jump_label.c +++ b/arch/s390/kernel/jump_label.c @@ -18,23 +18,12 @@ struct insn { } __packed; struct insn_args { - unsigned long *target; - struct insn *insn; - ssize_t size; + struct jump_entry *entry; + enum jump_label_type type; }; -static int __arch_jump_label_transform(void *data) -{ - struct insn_args *args = data; - int rc; - - rc = probe_kernel_write(args->target, args->insn, args->size); - WARN_ON_ONCE(rc < 0); - return 0; -} - -void arch_jump_label_transform(struct jump_entry *entry, - enum jump_label_type type) +static void __jump_label_transform(struct jump_entry *entry, + enum jump_label_type type) { struct insn_args args; struct insn insn; @@ -49,11 +38,33 @@ void arch_jump_label_transform(struct jump_entry *entry, insn.offset = 0; } - args.target = (void *) entry->code; - args.insn = &insn; - args.size = JUMP_LABEL_NOP_SIZE; + rc = probe_kernel_write(entry->code, &insn, JUMP_LABEL_NOP_SIZE); + WARN_ON_ONCE(rc < 0); +} + +static int __sm_arch_jump_label_transform(void *data) +{ + struct insn_args *args = data; + + __jump_label_transform(args->entry, args->type); + return 0; +} - stop_machine(__arch_jump_label_transform, &args, NULL); +void arch_jump_label_transform(struct jump_entry *entry, + enum jump_label_type type) +{ + struct insn_args args; + + args.entry = entry; + args.type = type; + + stop_machine(__sm_arch_jump_label_transform, &args, NULL); +} + +void __init arch_jump_label_transform_early(struct jump_entry *entry, + enum jump_label_type type) +{ + __jump_label_transform(entry, type); } #endif -- 1.7.6.2 _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel From xen-devel-bounces@lists.xensource.com Thu Sep 29 16:33:43 2011 Return-path: <xen-devel-bounces@lists.xensource.com> Envelope-to: www-data@lists.xensource.com Delivery-date: Thu, 29 Sep 2011 16:33:43 -0700 Received: from localhost ([127.0.0.1] helo=lists.colo.xensource.com) by lists.xensource.com with esmtp (Exim 4.43) id 1R9Q6o-0002qw-U0; Thu, 29 Sep 2011 16:33:42 -0700 Received: from mail21.messagelabs.com ([85.158.143.35]) by lists.xensource.com with esmtp (Exim 4.43) id 1R9Q0J-00006B-5y for xen-devel@lists.xensource.com; Thu, 29 Sep 2011 16:26:59 -0700 X-Env-Sender: jeremy@goop.org X-Msg-Ref: server-3.tower-21.messagelabs.com!1317338825!53491800!1 X-Originating-IP: [74.207.240.146] X-StarScan-Version: 6.4.1; banners=-,-,- X-VirusChecked: Checked Received: (qmail 26816 invoked from network); 29 Sep 2011 23:27:07 -0000 Received: from claw.goop.org (HELO claw.goop.org) (74.207.240.146) by server-3.tower-21.messagelabs.com with DHE-RSA-AES256-SHA encrypted SMTP; 29 Sep 2011 23:27:07 -0000 Received: from saboo.goop.org (unknown [IPv6:2001:470:1f05:899:2805:8fff:fe05:2e54]) (Authenticated sender: smtp-saboo) by claw.goop.org (Postfix) with ESMTPSA id F36848F4F; Thu, 29 Sep 2011 16:26:52 -0700 (PDT) Received: by saboo.goop.org (Postfix, from userid 500) id 3610920FAA; Thu, 29 Sep 2011 16:26:39 -0700 (PDT) From: Jeremy Fitzhardinge <jeremy@goop.org> To: Steven Rostedt <rostedt@goodmis.org> Date: Thu, 29 Sep 2011 16:26:32 -0700 Message-Id: <9305c40efff18a742f1446fa8013af3ed72b01ce.1317338254.git.jeremy.fitzhardinge@citrix.com> X-Mailer: git-send-email 1.7.6.2 In-Reply-To: <cover.1317338254.git.jeremy.fitzhardinge@citrix.com> References: <cover.1317338254.git.jeremy.fitzhardinge@citrix.com> In-Reply-To: <cover.1317338254.git.jeremy.fitzhardinge@citrix.com> References: <cover.1317338254.git.jeremy.fitzhardinge@citrix.com> Cc: Xen Devel <xen-devel@lists.xensource.com>, Jan Glauber <jang@linux.vnet.ibm.com>, Jason Baron <jbaron@redhat.com>, the arch/x86 maintainers <x86@kernel.org>, David Daney <david.daney@cavium.com>, Linux Kernel Mailing List <linux-kernel@vger.kernel.org>, Michael Ellerman <michael@ellerman.id.au>, Jeremy Fitzhardinge <jeremy.fitzhardinge@citrix.com>, "David S. Miller" <davem@davemloft.net> Subject: [Xen-devel] [PATCH RFC 2/8] jump_label: if a key has already been initialized, don't nop it out X-BeenThere: xen-devel@lists.xensource.com X-Mailman-Version: 2.1.5 Precedence: list List-Id: Xen developer discussion <xen-devel.lists.xensource.com> List-Unsubscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe> List-Post: <mailto:xen-devel@lists.xensource.com> List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help> List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=subscribe> Sender: xen-devel-bounces@lists.xensource.com Errors-To: xen-devel-bounces@lists.xensource.com From: Jeremy Fitzhardinge <jeremy.fitzhardinge@citrix.com> If a key has been enabled before jump_label_init() is called, don't nop it out. This replaces arch_jump_label_text_poke_early() (which can only nop out a site) with arch_jump_label_transform_early(), which is functionally equivalent to arch_jump_label_transform(). Signed-off-by: Jeremy Fitzhardinge <jeremy.fitzhardinge@citrix.com> --- include/linux/jump_label.h | 3 ++- kernel/jump_label.c | 17 +++++++++++------ 2 files changed, 13 insertions(+), 7 deletions(-) diff --git a/include/linux/jump_label.h b/include/linux/jump_label.h index 1213e9d..c8fb1b3 100644 --- a/include/linux/jump_label.h +++ b/include/linux/jump_label.h @@ -45,7 +45,8 @@ extern void jump_label_lock(void); extern void jump_label_unlock(void); extern void arch_jump_label_transform(struct jump_entry *entry, enum jump_label_type type); -extern void arch_jump_label_text_poke_early(jump_label_t addr); +extern void arch_jump_label_transform_early(struct jump_entry *entry, + enum jump_label_type type); extern int jump_label_text_reserved(void *start, void *end); extern void jump_label_inc(struct jump_label_key *key); extern void jump_label_dec(struct jump_label_key *key); diff --git a/kernel/jump_label.c b/kernel/jump_label.c index a8ce450..54e8e2d 100644 --- a/kernel/jump_label.c +++ b/kernel/jump_label.c @@ -124,8 +124,10 @@ static void __jump_label_update(struct jump_label_key *key, /* * Not all archs need this. */ -void __weak arch_jump_label_text_poke_early(jump_label_t addr) +void __weak arch_jump_label_transform_early(struct jump_entry *entry, + enum jump_label_type type) { + arch_jump_label_transform(entry, type); } static __init int jump_label_init(void) @@ -139,12 +141,15 @@ static __init int jump_label_init(void) jump_label_sort_entries(iter_start, iter_stop); for (iter = iter_start; iter < iter_stop; iter++) { - arch_jump_label_text_poke_early(iter->code); - if (iter->key == (jump_label_t)(unsigned long)key) + struct jump_label_key *iterk; + + iterk = (struct jump_label_key *)(unsigned long)iter->key; + arch_jump_label_transform_early(iter, jump_label_enabled(iterk) ? + JUMP_LABEL_ENABLE : JUMP_LABEL_DISABLE); + if (iterk == key) continue; - key = (struct jump_label_key *)(unsigned long)iter->key; - atomic_set(&key->enabled, 0); + key = iterk; key->entries = iter; #ifdef CONFIG_MODULES key->next = NULL; @@ -212,7 +217,7 @@ void jump_label_apply_nops(struct module *mod) return; for (iter = iter_start; iter < iter_stop; iter++) - arch_jump_label_text_poke_early(iter->code); + arch_jump_label_transform(iter, JUMP_LABEL_DISABLE); } static int jump_label_add_module(struct module *mod) -- 1.7.6.2 _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel From xen-devel-bounces@lists.xensource.com Thu Sep 29 16:34:28 2011 Return-path: <xen-devel-bounces@lists.xensource.com> Envelope-to: www-data@lists.xensource.com Delivery-date: Thu, 29 Sep 2011 16:34:28 -0700 Received: from localhost ([127.0.0.1] helo=lists.colo.xensource.com) by lists.xensource.com with esmtp (Exim 4.43) id 1R9Q7Y-0003JJ-CO; Thu, 29 Sep 2011 16:34:28 -0700 Received: from mail27.messagelabs.com ([193.109.254.147]) by lists.xensource.com with esmtp (Exim 4.43) id 1R9Q0I-00006A-W5 for xen-devel@lists.xensource.com; Thu, 29 Sep 2011 16:26:59 -0700 X-Env-Sender: jeremy@goop.org X-Msg-Ref: server-11.tower-27.messagelabs.com!1317338805!39501340!1 X-Originating-IP: [74.207.240.146] X-StarScan-Version: 6.4.1; banners=-,-,- X-VirusChecked: Checked Received: (qmail 7130 invoked from network); 29 Sep 2011 23:26:46 -0000 Received: from claw.goop.org (HELO claw.goop.org) (74.207.240.146) by server-11.tower-27.messagelabs.com with DHE-RSA-AES256-SHA encrypted SMTP; 29 Sep 2011 23:26:46 -0000 Received: from saboo.goop.org (unknown [IPv6:2001:470:1f05:899:2805:8fff:fe05:2e54]) (Authenticated sender: smtp-saboo) by claw.goop.org (Postfix) with ESMTPSA id B91EF8F43; Thu, 29 Sep 2011 16:26:51 -0700 (PDT) Received: by saboo.goop.org (Postfix, from userid 500) id 53F1520FB0; Thu, 29 Sep 2011 16:26:39 -0700 (PDT) From: Jeremy Fitzhardinge <jeremy@goop.org> To: Steven Rostedt <rostedt@goodmis.org> Date: Thu, 29 Sep 2011 16:26:38 -0700 Message-Id: <26bdb3886266f38a3e1664568a0a0193eb882aab.1317338254.git.jeremy.fitzhardinge@citrix.com> X-Mailer: git-send-email 1.7.6.2 In-Reply-To: <cover.1317338254.git.jeremy.fitzhardinge@citrix.com> References: <cover.1317338254.git.jeremy.fitzhardinge@citrix.com> In-Reply-To: <cover.1317338254.git.jeremy.fitzhardinge@citrix.com> References: <cover.1317338254.git.jeremy.fitzhardinge@citrix.com> Cc: Xen Devel <xen-devel@lists.xensource.com>, Jan Glauber <jang@linux.vnet.ibm.com>, Jason Baron <jbaron@redhat.com>, the arch/x86 maintainers <x86@kernel.org>, David Daney <david.daney@cavium.com>, Linux Kernel Mailing List <linux-kernel@vger.kernel.org>, Michael Ellerman <michael@ellerman.id.au>, Jeremy Fitzhardinge <jeremy.fitzhardinge@citrix.com>, "David S. Miller" <davem@davemloft.net> Subject: [Xen-devel] [PATCH RFC 8/8] jump_label: drop default arch_jump_label_transform_early X-BeenThere: xen-devel@lists.xensource.com X-Mailman-Version: 2.1.5 Precedence: list List-Id: Xen developer discussion <xen-devel.lists.xensource.com> List-Unsubscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe> List-Post: <mailto:xen-devel@lists.xensource.com> List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help> List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=subscribe> Sender: xen-devel-bounces@lists.xensource.com Errors-To: xen-devel-bounces@lists.xensource.com From: Jeremy Fitzhardinge <jeremy.fitzhardinge@citrix.com> Signed-off-by: Jeremy Fitzhardinge <jeremy.fitzhardinge@citrix.com> --- kernel/jump_label.c | 9 --------- 1 files changed, 0 insertions(+), 9 deletions(-) diff --git a/kernel/jump_label.c b/kernel/jump_label.c index 54e8e2d..3010bcf 100644 --- a/kernel/jump_label.c +++ b/kernel/jump_label.c @@ -121,15 +121,6 @@ static void __jump_label_update(struct jump_label_key *key, } } -/* - * Not all archs need this. - */ -void __weak arch_jump_label_transform_early(struct jump_entry *entry, - enum jump_label_type type) -{ - arch_jump_label_transform(entry, type); -} - static __init int jump_label_init(void) { struct jump_entry *iter_start = __start___jump_table; -- 1.7.6.2 _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel From xen-devel-bounces@lists.xensource.com Thu Sep 29 16:36:07 2011 Return-path: <xen-devel-bounces@lists.xensource.com> Envelope-to: www-data@lists.xensource.com Delivery-date: Thu, 29 Sep 2011 16:36:07 -0700 Received: from localhost ([127.0.0.1] helo=lists.colo.xensource.com) by lists.xensource.com with esmtp (Exim 4.43) id 1R9Q99-0003j1-0y; Thu, 29 Sep 2011 16:36:07 -0700 Received: from mail21.messagelabs.com ([85.158.143.35]) by lists.xensource.com with esmtp (Exim 4.43) id 1R9Q0J-00006D-LE for xen-devel@lists.xensource.com; Thu, 29 Sep 2011 16:27:00 -0700 X-Env-Sender: jeremy@goop.org X-Msg-Ref: server-12.tower-21.messagelabs.com!1317338799!51885373!1 X-Originating-IP: [74.207.240.146] X-StarScan-Version: 6.4.1; banners=-,-,- X-VirusChecked: Checked Received: (qmail 24648 invoked from network); 29 Sep 2011 23:26:40 -0000 Received: from claw.goop.org (HELO claw.goop.org) (74.207.240.146) by server-12.tower-21.messagelabs.com with DHE-RSA-AES256-SHA encrypted SMTP; 29 Sep 2011 23:26:40 -0000 Received: from saboo.goop.org (unknown [IPv6:2001:470:1f05:899:2805:8fff:fe05:2e54]) (Authenticated sender: smtp-saboo) by claw.goop.org (Postfix) with ESMTPSA id A4A388F57; Thu, 29 Sep 2011 16:26:54 -0700 (PDT) Received: by saboo.goop.org (Postfix, from userid 500) id 3E9E520FAC; Thu, 29 Sep 2011 16:26:39 -0700 (PDT) From: Jeremy Fitzhardinge <jeremy@goop.org> To: Steven Rostedt <rostedt@goodmis.org> Date: Thu, 29 Sep 2011 16:26:34 -0700 Message-Id: <6b0e55538e91fd7663430a291a39c6ed048b2548.1317338254.git.jeremy.fitzhardinge@citrix.com> X-Mailer: git-send-email 1.7.6.2 In-Reply-To: <cover.1317338254.git.jeremy.fitzhardinge@citrix.com> References: <cover.1317338254.git.jeremy.fitzhardinge@citrix.com> In-Reply-To: <cover.1317338254.git.jeremy.fitzhardinge@citrix.com> References: <cover.1317338254.git.jeremy.fitzhardinge@citrix.com> Cc: Xen Devel <xen-devel@lists.xensource.com>, Jan Glauber <jang@linux.vnet.ibm.com>, Jason Baron <jbaron@redhat.com>, the arch/x86 maintainers <x86@kernel.org>, David Daney <david.daney@cavium.com>, Linux Kernel Mailing List <linux-kernel@vger.kernel.org>, Michael Ellerman <michael@ellerman.id.au>, Jeremy Fitzhardinge <jeremy.fitzhardinge@citrix.com>, "David S. Miller" <davem@davemloft.net> Subject: [Xen-devel] [PATCH RFC 4/8] sparc/jump_label: add arch_jump_label_transform_early() X-BeenThere: xen-devel@lists.xensource.com X-Mailman-Version: 2.1.5 Precedence: list List-Id: Xen developer discussion <xen-devel.lists.xensource.com> List-Unsubscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe> List-Post: <mailto:xen-devel@lists.xensource.com> List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help> List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=subscribe> Sender: xen-devel-bounces@lists.xensource.com Errors-To: xen-devel-bounces@lists.xensource.com From: Jeremy Fitzhardinge <jeremy.fitzhardinge@citrix.com> This allows jump-label entries to be modified early, in a pre-SMP environment. Signed-off-by: Jeremy Fitzhardinge <jeremy.fitzhardinge@citrix.com> Cc: David S. Miller <davem@davemloft.net> --- arch/sparc/kernel/jump_label.c | 24 +++++++++++++++--------- 1 files changed, 15 insertions(+), 9 deletions(-) diff --git a/arch/sparc/kernel/jump_label.c b/arch/sparc/kernel/jump_label.c index ea2dafc..d3dad25 100644 --- a/arch/sparc/kernel/jump_label.c +++ b/arch/sparc/kernel/jump_label.c @@ -8,8 +8,8 @@ #ifdef HAVE_JUMP_LABEL -void arch_jump_label_transform(struct jump_entry *entry, - enum jump_label_type type) +static void __jump_label_transform(struct jump_entry *entry, + enum jump_label_type type) { u32 val; u32 *insn = (u32 *) (unsigned long) entry->code; @@ -28,20 +28,26 @@ void arch_jump_label_transform(struct jump_entry *entry, val = 0x01000000; } - get_online_cpus(); - mutex_lock(&text_mutex); *insn = val; flushi(insn); +} + +void arch_jump_label_transform(struct jump_entry *entry, + enum jump_label_type type) +{ + get_online_cpus(); + mutex_lock(&text_mutex); + + __jump_label_transform(entry, type); + mutex_unlock(&text_mutex); put_online_cpus(); } -void arch_jump_label_text_poke_early(jump_label_t addr) +void __init arch_jump_label_transform_early(struct jump_entry *entry, + enum jump_label_type type) { - u32 *insn_p = (u32 *) (unsigned long) addr; - - *insn_p = 0x01000000; - flushi(insn_p); + __jump_label_transform(entry, type); } #endif -- 1.7.6.2 _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel From xen-devel-bounces@lists.xensource.com Thu Sep 29 16:37:05 2011 Return-path: <xen-devel-bounces@lists.xensource.com> Envelope-to: www-data@lists.xensource.com Delivery-date: Thu, 29 Sep 2011 16:37:05 -0700 Received: from localhost ([127.0.0.1] helo=lists.colo.xensource.com) by lists.xensource.com with esmtp (Exim 4.43) id 1R9QA5-00046X-6o; Thu, 29 Sep 2011 16:37:05 -0700 Received: from mail21.messagelabs.com ([85.158.143.35]) by lists.xensource.com with esmtp (Exim 4.43) id 1R9Q9J-0003mE-On for xen-devel@lists.xensource.com; Thu, 29 Sep 2011 16:36:19 -0700 X-Env-Sender: davem@davemloft.net X-Msg-Ref: server-5.tower-21.messagelabs.com!1317339338!50071379!1 X-Originating-IP: [198.137.202.13] X-StarScan-Version: 6.4.1; banners=-,-,- X-VirusChecked: Checked Received: (qmail 7956 invoked from network); 29 Sep 2011 23:35:39 -0000 Received: from shards.monkeyblade.net (HELO shards.monkeyblade.net) (198.137.202.13) by server-5.tower-21.messagelabs.com with DHE-RSA-AES256-SHA encrypted SMTP; 29 Sep 2011 23:35:39 -0000 Received: from localhost (cpe-66-65-62-183.nyc.res.rr.com [66.65.62.183]) (authenticated bits=0) by shards.monkeyblade.net (8.14.4/8.14.4) with ESMTP id p8TNVvdM021179 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 29 Sep 2011 16:31:59 -0700 Date: Thu, 29 Sep 2011 19:31:57 -0400 (EDT) Message-Id: <20110929.193157.1260100265703479487.davem@davemloft.net> To: jeremy@goop.org From: David Miller <davem@davemloft.net> In-Reply-To: <6b0e55538e91fd7663430a291a39c6ed048b2548.1317338254.git.jeremy.fitzhardinge@citrix.com> References: <cover.1317338254.git.jeremy.fitzhardinge@citrix.com> <cover.1317338254.git.jeremy.fitzhardinge@citrix.com> <6b0e55538e91fd7663430a291a39c6ed048b2548.1317338254.git.jeremy.fitzhardinge@citrix.com> X-Mailer: Mew version 6.3 on Emacs 23.2 / Mule 6.0 (HANACHIRUSATO) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.6 (shards.monkeyblade.net [198.137.202.13]); Thu, 29 Sep 2011 16:32:00 -0700 (PDT) Cc: xen-devel@lists.xensource.com, jang@linux.vnet.ibm.com, jbaron@redhat.com, x86@kernel.org, david.daney@cavium.com, linux-kernel@vger.kernel.org, rostedt@goodmis.org, michael@ellerman.id.au, jeremy.fitzhardinge@citrix.com Subject: [Xen-devel] Re: [PATCH RFC 4/8] sparc/jump_label: add arch_jump_label_transform_early() X-BeenThere: xen-devel@lists.xensource.com X-Mailman-Version: 2.1.5 Precedence: list List-Id: Xen developer discussion <xen-devel.lists.xensource.com> List-Unsubscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe> List-Post: <mailto:xen-devel@lists.xensource.com> List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help> List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=subscribe> Sender: xen-devel-bounces@lists.xensource.com Errors-To: xen-devel-bounces@lists.xensource.com From: Jeremy Fitzhardinge <jeremy@goop.org> Date: Thu, 29 Sep 2011 16:26:34 -0700 > From: Jeremy Fitzhardinge <jeremy.fitzhardinge@citrix.com> > > This allows jump-label entries to be modified early, in a pre-SMP > environment. > > Signed-off-by: Jeremy Fitzhardinge <jeremy.fitzhardinge@citrix.com> Acked-by: David S. Miller <davem@davemloft.net> _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel From xen-devel-bounces@lists.xensource.com Thu Sep 29 16:50:51 2011 Return-path: <xen-devel-bounces@lists.xensource.com> Envelope-to: www-data@lists.xensource.com Delivery-date: Thu, 29 Sep 2011 16:50:51 -0700 Received: from localhost ([127.0.0.1] helo=lists.colo.xensource.com) by lists.xensource.com with esmtp (Exim 4.43) id 1R9QNN-0004eZ-Iy; Thu, 29 Sep 2011 16:50:50 -0700 Received: from mail216.messagelabs.com ([85.158.143.99]) by lists.xensource.com with esmtp (Exim 4.43) id 1R9QMX-0004Rp-JL for xen-devel@lists.xensource.com; Thu, 29 Sep 2011 16:49:59 -0700 X-Env-Sender: fujita.tomonori@lab.ntt.co.jp X-Msg-Ref: server-12.tower-216.messagelabs.com!1317340191!14321468!1 X-Originating-IP: [192.16.179.4] X-StarScan-Version: 6.4.1; banners=-,-,- X-VirusChecked: Checked Received: (qmail 6708 invoked from network); 29 Sep 2011 23:49:54 -0000 Received: from sh.osrg.net (HELO sh.osrg.net) (192.16.179.4) by server-12.tower-216.messagelabs.com with DHE-RSA-AES256-SHA encrypted SMTP; 29 Sep 2011 23:49:54 -0000 Received: from localhost (rose.osrg.net [10.76.0.1]) by sh.osrg.net (8.14.3/8.14.3/OSRG-NET) with ESMTP id p8TNnciM006462; Fri, 30 Sep 2011 08:49:38 +0900 Date: Fri, 30 Sep 2011 08:49:38 +0900 To: konrad.wilk@oracle.com From: FUJITA Tomonori <fujita.tomonori@lab.ntt.co.jp> In-Reply-To: <1317328432-25620-5-git-send-email-konrad.wilk@oracle.com> References: <1317328432-25620-1-git-send-email-konrad.wilk@oracle.com> <1317328432-25620-5-git-send-email-konrad.wilk@oracle.com> Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-Id: <20110930083651R.fujita.tomonori@lab.ntt.co.jp> Lines: 17 X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-3.0 (sh.osrg.net [192.16.179.4]); Fri, 30 Sep 2011 08:49:40 +0900 (JST) X-Virus-Scanned: clamav-milter 0.97.2 at sh X-Virus-Status: Clean Cc: thellstrom@vmware.com, xen-devel@lists.xensource.com, thomas@shipmail.org, airlied@linux.ie, linux-kernel@vger.kernel.org, dri-devel@lists.freedesktop.org, fujita.tomonori@lab.ntt.co.jp, j.glisse@redhat.com, alexdeucher@gmail.com, airlied@redhat.com, bskeggs@redhat.com Subject: [Xen-devel] Re: [PATCH 4/9] swiotlb: Expose swiotlb_nr_tlb function to modules X-BeenThere: xen-devel@lists.xensource.com X-Mailman-Version: 2.1.5 Precedence: list List-Id: Xen developer discussion <xen-devel.lists.xensource.com> List-Unsubscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe> List-Post: <mailto:xen-devel@lists.xensource.com> List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help> List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=subscribe> Sender: xen-devel-bounces@lists.xensource.com Errors-To: xen-devel-bounces@lists.xensource.com On Thu, 29 Sep 2011 16:33:47 -0400 Konrad Rzeszutek Wilk <konrad.wilk@oracle.com> wrote: > As a mechanism to detect whether SWIOTLB is enabled or not. > We also fix the spelling - it was swioltb instead of > swiotlb. > > CC: FUJITA Tomonori <fujita.tomonori@lab.ntt.co.jp> > [v1: Ripped out swiotlb_enabled] > Signed-off-by: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com> > --- > drivers/xen/swiotlb-xen.c | 2 +- > include/linux/swiotlb.h | 2 +- > lib/swiotlb.c | 5 +++-- > 3 files changed, 5 insertions(+), 4 deletions(-) Acked-by: FUJITA Tomonori <fujita.tomonori@lab.ntt.co.jp> _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel From xen-devel-bounces@lists.xensource.com Thu Sep 29 17:54:10 2011 Return-path: <xen-devel-bounces@lists.xensource.com> Envelope-to: www-data@lists.xensource.com Delivery-date: Thu, 29 Sep 2011 17:54:10 -0700 Received: from localhost ([127.0.0.1] helo=lists.colo.xensource.com) by lists.xensource.com with esmtp (Exim 4.43) id 1R9RMf-0006Bw-Ha; Thu, 29 Sep 2011 17:54:09 -0700 Received: from mail27.messagelabs.com ([193.109.254.147]) by lists.xensource.com with smtp (Exim 4.43) id 1R9RLX-0005yU-J6 for xen-devel@lists.xensource.com; Thu, 29 Sep 2011 17:53:00 -0700 X-Env-Sender: rostedt@goodmis.org X-Msg-Ref: server-2.tower-27.messagelabs.com!1317343949!57040810!1 X-Originating-IP: [71.74.56.123] X-StarScan-Version: 6.4.1; banners=-,-,- X-VirusChecked: Checked Received: (qmail 28706 invoked from network); 30 Sep 2011 00:52:30 -0000 Received: from hrndva-omtalb.mail.rr.com (HELO hrndva-omtalb.mail.rr.com) (71.74.56.123) by server-2.tower-27.messagelabs.com with SMTP; 30 Sep 2011 00:52:30 -0000 X-Authority-Analysis: v=1.1 cv=cSzO76bR5tCkfUT9bEmBgR3d7VUusRLeq08eKGxa4EU= c=1 sm=0 a=eMQ7hR_6lG4A:10 a=5SG0PmZfjMsA:10 a=Q9fys5e9bTEA:10 a=17wjrS5wAhQaEczCPkpxpQ==:17 a=tHz9FfFoAAAA:8 a=hJUw3UrrG-n1DAumEp0A:9 a=PUjeQqilurYA:10 a=6O0IECtVFhoA:10 a=17wjrS5wAhQaEczCPkpxpQ==:117 X-Cloudmark-Score: 0 X-Originating-IP: 74.67.83.30 Received: from [74.67.83.30] ([74.67.83.30:49825] helo=[192.168.23.10]) by hrndva-oedge04.mail.rr.com (envelope-from <rostedt@goodmis.org>) (ecelerity 2.2.3.46 r()) with ESMTP id AB/C1-05514-5E2158E4; Fri, 30 Sep 2011 00:52:56 +0000 From: Steven Rostedt <rostedt@goodmis.org> To: Jeremy Fitzhardinge <jeremy@goop.org> Date: Thu, 29 Sep 2011 20:52:53 -0400 In-Reply-To: <cover.1317338254.git.jeremy.fitzhardinge@citrix.com> References: <cover.1317338254.git.jeremy.fitzhardinge@citrix.com> Content-Type: text/plain; charset="ISO-8859-15" X-Mailer: Evolution 3.0.3- Content-Transfer-Encoding: 7bit Message-ID: <1317343975.4588.36.camel@gandalf.stny.rr.com> Mime-Version: 1.0 Cc: Jan, arch/x86 maintainers <x86@kernel.org>, Jeremy Fitzhardinge <jeremy.fitzhardinge@citrix.com>, Glauber <jang@linux.vnet.ibm.com>, Jason Baron <jbaron@redhat.com>, David Daney <david.daney@cavium.com>, Linux Kernel Mailing List <linux-kernel@vger.kernel.org>, Michael Ellerman <michael@ellerman.id.au>, Xen Devel <xen-devel@lists.xensource.com>, the, "David S. Miller" <davem@davemloft.net> Subject: [Xen-devel] Re: [PATCH RFC 0/8] jump-label: allow early jump_label_enable() X-BeenThere: xen-devel@lists.xensource.com X-Mailman-Version: 2.1.5 Precedence: list List-Id: Xen developer discussion <xen-devel.lists.xensource.com> List-Unsubscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe> List-Post: <mailto:xen-devel@lists.xensource.com> List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help> List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=subscribe> Sender: xen-devel-bounces@lists.xensource.com Errors-To: xen-devel-bounces@lists.xensource.com On Thu, 2011-09-29 at 16:26 -0700, Jeremy Fitzhardinge wrote: > From: Jeremy Fitzhardinge <jeremy.fitzhardinge@citrix.com> > > One big question which arises is whether the _early() function is > necessary at all. All the stop_machine/mutex/etc stuff that > arch_jump_label_transform() ends up doing is redundant pre-SMP, but it > shouldn't hurt. Maybe we can just drop the _early function? It works > on x86, at least, because jump_label_enable() works, which uses the full > form. And dropping it would reduce this to a very much smaller series. It does slow down the boot process, which is not a good thing when everyone is pushing for the fastest restarts. What we should probably do is have a global read_mostly variable called, smp_activated or something, then things that can be called before and after can read this variable to determine if it can skip certain protections. While we're at it, perhaps we could add a memory_initialized for things like tracers that want to trace early but need to wait till it can allocate buffers. If we had this flag, it could instead do an early memory init to create the buffers. -- Steve _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel From xen-devel-bounces@lists.xensource.com Thu Sep 29 19:20:10 2011 Return-path: <xen-devel-bounces@lists.xensource.com> Envelope-to: www-data@lists.xensource.com Delivery-date: Thu, 29 Sep 2011 19:20:10 -0700 Received: from localhost ([127.0.0.1] helo=lists.colo.xensource.com) by lists.xensource.com with esmtp (Exim 4.43) id 1R9Sht-00089B-B0; Thu, 29 Sep 2011 19:20:09 -0700 Received: from mail174.messagelabs.com ([85.158.138.51]) by lists.xensource.com with esmtp (Exim 4.43) id 1R9SgY-0007vq-Kz for xen-devel@lists.xensource.com; Thu, 29 Sep 2011 19:18:47 -0700 X-Env-Sender: konrad@oracle.com X-Msg-Ref: server-7.tower-174.messagelabs.com!1317349121!33281494!1 X-Originating-IP: [141.146.126.227] X-StarScan-Version: 6.4.1; banners=-,-,- X-VirusChecked: Checked Received: (qmail 9700 invoked from network); 30 Sep 2011 02:18:43 -0000 Received: from acsinet15.oracle.com (HELO acsinet15.oracle.com) (141.146.126.227) by server-7.tower-174.messagelabs.com with DHE-RSA-AES256-SHA encrypted SMTP; 30 Sep 2011 02:18:43 -0000 Received: from rtcsinet21.oracle.com (rtcsinet21.oracle.com [66.248.204.29]) by acsinet15.oracle.com (Switch-3.4.4/Switch-3.4.4) with ESMTP id p8U2IddS006392 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Fri, 30 Sep 2011 02:18:40 GMT Received: from acsmt358.oracle.com (acsmt358.oracle.com [141.146.40.158]) by rtcsinet21.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id p8U2IbhH002164 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 30 Sep 2011 02:18:38 GMT Received: from abhmt116.oracle.com (abhmt116.oracle.com [141.146.116.68]) by acsmt358.oracle.com (8.12.11.20060308/8.12.11) with ESMTP id p8U2IW08010192; Thu, 29 Sep 2011 21:18:32 -0500 Received: from oracle.com (/207.172.105.198) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Thu, 29 Sep 2011 19:18:31 -0700 Received: by oracle.com (Postfix, from userid 1000) id E52211608; Thu, 29 Sep 2011 22:13:01 -0400 (EDT) Date: Thu, 29 Sep 2011 22:13:01 -0400 From: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com> To: Dushmanta Mohapatra <dushmanta.mohapatra@gmail.com> Subject: Re: [Xen-devel] Re: Graphics passthrough related issue Message-ID: <20110930021301.GA3597@phenom.oracle.com> References: <CA+PhxFdtdKqTWA9rD3M6s8VS=WMaBV3oQuicV8JW5wCir=iHnA@mail.gmail.com> <CA+PhxFepcRHQKczKwGeQLWR2QGx+UpqT1Sts3szSnjfQLVieAA@mail.gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <CA+PhxFepcRHQKczKwGeQLWR2QGx+UpqT1Sts3szSnjfQLVieAA@mail.gmail.com> User-Agent: Mutt/1.5.21 (2010-09-15) X-Source-IP: rtcsinet21.oracle.com [66.248.204.29] X-CT-RefId: str=0001.0A090205.4E852701.0081,ss=1,re=0.000,fgs=0 Cc: xen-devel@lists.xensource.com X-BeenThere: xen-devel@lists.xensource.com X-Mailman-Version: 2.1.5 Precedence: list List-Id: Xen developer discussion <xen-devel.lists.xensource.com> List-Unsubscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe> List-Post: <mailto:xen-devel@lists.xensource.com> List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help> List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=subscribe> Sender: xen-devel-bounces@lists.xensource.com Errors-To: xen-devel-bounces@lists.xensource.com On Mon, Sep 19, 2011 at 03:18:13AM -0400, Dushmanta Mohapatra wrote: > I sent the following email a few days back, but did not get any response. > > I am still facing the issue. Could some one please tell me about what might > be going wrong? So you are trying to pass in an USB device to the guest. Does it not work? What does your guest config look like? Are you using 'xl' or 'xm'? > > Any pointers about how could I debug this issue? > > Thanks, > Dushmanta > > On Tue, Sep 13, 2011 at 12:09 AM, Dushmanta Mohapatra < > dushmanta.mohapatra@gmail.com> wrote: > > > Hi, > > > > I am facing an issue with enabling my graphics passthrough properly in Xen. > > > > I am using Xen 4.1.1 and 2.6.32.41 based PVOPS kernel as my Dom0. > > Machine: core i5 vPro based Thinkpad T 520 laptop. > > I use Windows 7 and XP as my HVM DomUs. > > > > I have an Intel Integrated Graphics Controller. > > I can pass through the graphics device (using boot time passthrough) and > > the HVM DomUs boot fine and show me the log in screen. > > > > But somehow I lose my control over input devices (mouse/keyboard). My > > laptop has a PS/2 keypad and I do not know how to pass that through. So > > instead, I plugin an external keyboard and mouse to the USB slots that are > > available and pass them through to DomU. > > > > But those are not accessible when I boot my DomU in the graphics pass > > through mode. (If I boot without graphics pass-through mode, > > then I can pass external keyboard and mouse to the DomUs and they work > > fine.) > > > > I have not applied any patch to the Xen 4.1.1 that I built from source > > obtained from xen.org and I am not doing any manual device/memory region > > mapping. I am not sure if I need any patch for the integrated graphics > > driver that I use. > > > > Could any one provide me some input about what might be going wrong for me > > and how I could solve the issue. I am including the lspci output for > > reference. If some more information is needed from my side, please let me > > know. > > > > Thanks > > > > > > > > For enabling graphics passthrough, I hide and passthrough the devices > > highlighted. > > > > root@dm-ThinkPad-T520:~# lspci > > 00:00.0 Host bridge: Intel Corporation 2nd Generation Core Processor Family > > DRAM Controller (rev 09) > > 00:02.0 VGA compatible controller: Intel Corporation 2nd Generation Core > > Processor Family Integrated Graphics Controller (rev 09) > > 00:16.0 Communication controller: Intel Corporation 6 Series Chipset Family > > MEI Controller #1 (rev 04) > > 00:16.3 Serial controller: Intel Corporation 6 Series Chipset Family KT > > Controller (rev 04) > > 00:19.0 Ethernet controller: Intel Corporation 82579LM Gigabit Network > > Connection (rev 04) > > 00:1a.0 USB Controller: Intel Corporation 6 Series Chipset Family USB > > Enhanced Host Controller #2 (rev 04) > > 00:1b.0 Audio device: Intel Corporation 6 Series Chipset Family High > > Definition Audio Controller (rev 04) > > 00:1c.0 PCI bridge: Intel Corporation 6 Series Chipset Family PCI Express > > Root Port 1 (rev b4) > > 00:1c.1 PCI bridge: Intel Corporation 6 Series Chipset Family PCI Express > > Root Port 2 (rev b4) > > 00:1c.3 PCI bridge: Intel Corporation 6 Series Chipset Family PCI Express > > Root Port 4 (rev b4) > > 00:1c.4 PCI bridge: Intel Corporation 6 Series Chipset Family PCI Express > > Root Port 5 (rev b4) > > 00:1d.0 USB Controller: Intel Corporation 6 Series Chipset Family USB > > Enhanced Host Controller #1 (rev 04) > > 00:1f.0 ISA bridge: Intel Corporation 6 Series Chipset Family LPC > > Controller (rev 04) > > 00:1f.2 SATA controller: Intel Corporation 6 Series Chipset Family 6 port > > SATA AHCI Controller (rev 04) > > 00:1f.3 SMBus: Intel Corporation 6 Series Chipset Family SMBus Controller > > (rev 04) > > 03:00.0 Network controller: Intel Corporation Centrino Advanced-N 6205 (rev > > 34) > > 0d:00.0 System peripheral: Ricoh Co Ltd Device e823 (rev 05) > > 0d:00.3 FireWire (IEEE 1394): Ricoh Co Ltd FireWire Host Controller (rev > > 04) > > > > > > > _______________________________________________ > Xen-devel mailing list > Xen-devel@lists.xensource.com > http://lists.xensource.com/xen-devel _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel From xen-devel-bounces@lists.xensource.com Thu Sep 29 19:54:02 2011 Return-path: <xen-devel-bounces@lists.xensource.com> Envelope-to: www-data@lists.xensource.com Delivery-date: Thu, 29 Sep 2011 19:54:02 -0700 Received: from localhost ([127.0.0.1] helo=lists.colo.xensource.com) by lists.xensource.com with esmtp (Exim 4.43) id 1R9TEf-0000l7-FX; Thu, 29 Sep 2011 19:54:01 -0700 Received: from mail216.messagelabs.com ([85.158.143.99]) by lists.xensource.com with smtp (Exim 4.43) id 1R9TDp-0000ZA-EC for xen-devel@lists.xensource.com; Thu, 29 Sep 2011 19:53:10 -0700 X-Env-Sender: yunhong.jiang@intel.com X-Msg-Ref: server-5.tower-216.messagelabs.com!1317351185!17966398!1 X-Originating-IP: [192.55.52.93] X-StarScan-Version: 6.4.1; banners=-,-,- X-VirusChecked: Checked Received: (qmail 18995 invoked from network); 30 Sep 2011 02:53:05 -0000 Received: from mga11.intel.com (HELO mga11.intel.com) (192.55.52.93) by server-5.tower-216.messagelabs.com with SMTP; 30 Sep 2011 02:53:05 -0000 Received: from fmsmga001.fm.intel.com ([10.253.24.23]) by fmsmga102.fm.intel.com with ESMTP; 29 Sep 2011 19:53:04 -0700 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="4.68,464,1312182000"; d="p7s'?scan'208";a="68881878" Received: from pgsmsx602.gar.corp.intel.com ([10.221.43.81]) by fmsmga001.fm.intel.com with ESMTP; 29 Sep 2011 19:53:03 -0700 Received: from pgsmsx104.gar.corp.intel.com (10.221.44.91) by pgsmsx602.gar.corp.intel.com (10.221.43.81) with Microsoft SMTP Server (TLS) id 8.2.255.0; Fri, 30 Sep 2011 10:51:29 +0800 Received: from shsmsx601.ccr.corp.intel.com (10.239.4.112) by PGSMSX104.gar.corp.intel.com (10.221.44.91) with Microsoft SMTP Server (TLS) id 14.1.323.3; Fri, 30 Sep 2011 10:51:29 +0800 Received: from shsmsx501.ccr.corp.intel.com ([10.239.4.141]) by shsmsx601.ccr.corp.intel.com ([10.239.4.112]) with mapi; Fri, 30 Sep 2011 10:51:28 +0800 From: "Jiang, Yunhong" <yunhong.jiang@intel.com> To: "JBeulich@suse.com" <JBeulich@suse.com>, "Liu, Jinsong" <jinsong.liu@intel.com> Date: Fri, 30 Sep 2011 10:51:25 +0800 Subject: RE: [Xen-devel] [PATCH] X86 MCE: Add SRAR handler Thread-Topic: [Xen-devel] [PATCH] X86 MCE: Add SRAR handler Thread-Index: Acx+vmMhjCc0+Cf0TSm9JKqwC5QF1gARod6A Message-ID: <789F9655DD1B8F43B48D77C5D306597312D2366A9B@shsmsx501.ccr.corp.intel.com> References: <BC00F5384FCFC9499AF06F92E8B78A9E263B557B77@shsmsx502.ccr.corp.intel.com> <4E84ADF70200007800058882@nat28.tlf.novell.com> In-Reply-To: <4E84ADF70200007800058882@nat28.tlf.novell.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: acceptlanguage: en-US MIME-Version: 1.0 Cc: "keir.xen@gmail.com" <keir.xen@gmail.com>, "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com> X-BeenThere: xen-devel@lists.xensource.com X-Mailman-Version: 2.1.5 Precedence: list List-Id: Xen developer discussion <xen-devel.lists.xensource.com> List-Unsubscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe> List-Post: <mailto:xen-devel@lists.xensource.com> List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help> List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=subscribe> Content-Type: multipart/mixed; boundary="===============0875571846==" Sender: xen-devel-bounces@lists.xensource.com Errors-To: xen-devel-bounces@lists.xensource.com --===============0875571846== Content-Language: en-US Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=SHA1; boundary="----=_NextPart_000_002B_01CC7F5E.E673BDA0" ------=_NextPart_000_002B_01CC7F5E.E673BDA0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit > -----Original Message----- > From: Jan Beulich [mailto:JBeulich@suse.com] > Sent: Thursday, September 29, 2011 11:42 PM > To: Liu, Jinsong > Cc: Keir Fraser; Jiang, Yunhong; xen-devel@lists.xensource.com > Subject: Re: [Xen-devel] [PATCH] X86 MCE: Add SRAR handler > > >>> On 29.09.11 at 17:20, "Liu, Jinsong" <jinsong.liu@intel.com> wrote: > > @@ -782,8 +821,12 @@ static void intel_default_mce_uhandler( > > > > switch (type) > > { > > - /* Panic if no handler for SRAR error */ > > case intel_mce_ucr_srar: > > + if ( !guest_mode(regs) ) > > + *result = MCER_RESET; > > + else > > + *result = MCER_CONTINUE; > > + break; > > case intel_mce_fatal: > > *result = MCER_RESET; > > break; > > Using the stack based registers for any decision in an MCE handler > seems bogus to me - without knowing that the error occurred > synchronously, the result is meaningless. Unfortunately I wasn't I think the usage of stack in MCE handler should be case by case. For example, it's ok to use it at data load instruction since the EIPV is valid for it. For the instruction load, not that sure and I will check it internally. But agree that we should not do this depends on the error type (like SRAR), but should depends on the specific error code. > able to spot - throughout your patch - what SRAR actually stands > for, and the manual is no help in that respect either. It does state, > however, that EIPV in three of four cases would be clear for these, > so using the registers on stack is likely wrong here. > > This made me look at the current source, and there I see in > mce_urgent_action() > > if ( !(gstatus & MCG_STATUS_RIPV) && !guest_mode(regs)) > return -1; > > which I think should say ... _EIPV and use || instead. Thoughts? I think this code means, if the error happens in hypervisor mode (i.e. !guest_mode()), and RIPV indicate the RIP in stack can't be restarted, we have to panic. Thanks --jyh > > Jan ------=_NextPart_000_002B_01CC7F5E.E673BDA0 Content-Type: application/x-pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIYYDCCAyAw ggKJoAMCAQICBDXe9M8wDQYJKoZIhvcNAQEFBQAwTjELMAkGA1UEBhMCVVMxEDAOBgNVBAoTB0Vx dWlmYXgxLTArBgNVBAsTJEVxdWlmYXggU2VjdXJlIENlcnRpZmljYXRlIEF1dGhvcml0eTAeFw05 ODA4MjIxNjQxNTFaFw0xODA4MjIxNjQxNTFaME4xCzAJBgNVBAYTAlVTMRAwDgYDVQQKEwdFcXVp ZmF4MS0wKwYDVQQLEyRFcXVpZmF4IFNlY3VyZSBDZXJ0aWZpY2F0ZSBBdXRob3JpdHkwgZ8wDQYJ KoZIhvcNAQEBBQADgY0AMIGJAoGBAMFdsVhnCGLuoJotHwhtkRRomAoe/toEbxOEYiHD0XzOnwXg uAHwTjTs4oqVBGSs8WtTXwWzy2eAv0ICjv7dAQns4QAUT/z78AzdQ7pbK+EfgHCZFVeTFvEPl2q3 wmgjHMxNWTCsUR47ryvW7mNFe8XZX1DS41APOojnvxT94Me5AgMBAAGjggEJMIIBBTBwBgNVHR8E aTBnMGWgY6BhpF8wXTELMAkGA1UEBhMCVVMxEDAOBgNVBAoTB0VxdWlmYXgxLTArBgNVBAsTJEVx dWlmYXggU2VjdXJlIENlcnRpZmljYXRlIEF1dGhvcml0eTENMAsGA1UEAxMEQ1JMMTAaBgNVHRAE EzARgQ8yMDE4MDgyMjE2NDE1MVowCwYDVR0PBAQDAgEGMB8GA1UdIwQYMBaAFEjmaPkr0rKV10fY IyAQTzOYkJ/UMB0GA1UdDgQWBBRI5mj5K9KylddH2CMgEE8zmJCf1DAMBgNVHRMEBTADAQH/MBoG CSqGSIb2fQdBAAQNMAsbBVYzLjBjAwIGwDANBgkqhkiG9w0BAQUFAAOBgQBYzinq/Pfetc4CuRe1 hdG54+CVzCUxDQCmkm5/tpJjnlCV0Zpv5BHeY4VumO6o/1rI01WyZnFX3sAh6z0qpyNJAQSGQnv8 7n+iFlK1Z2fTQNs7JliyKHc9rhR3Ydb6KmYnoA36p3Nc6nDxlCFlRF/6/O8paKmih3nvee9PrAd3 ODCCAz0wggKmoAMCAQICAwWw/zANBgkqhkiG9w0BAQUFADBOMQswCQYDVQQGEwJVUzEQMA4GA1UE ChMHRXF1aWZheDEtMCsGA1UECxMkRXF1aWZheCBTZWN1cmUgQ2VydGlmaWNhdGUgQXV0aG9yaXR5 MB4XDTA2MDIxNjE4MDEzMFoXDTE2MDIxOTE4MDEzMFowUjELMAkGA1UEBhMCVVMxGjAYBgNVBAoT EUludGVsIENvcnBvcmF0aW9uMScwJQYDVQQDEx5JbnRlbCBFeHRlcm5hbCBCYXNpYyBQb2xpY3kg Q0EwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQDBpd/XOb9QVqEZ8mQ1042TdOIq3ATD IsV2xDyt30yLyMR5Wjtus0bn3B+he89BiNO/LP6+rFzEwlD55PlX+HLGIKeNNG97dqyc30FElEUj ZzTZFq2N4e3kVJ/XAEEgANzV8v9qp7qWwxugPgfc3z9BkYot+CifozexHLb/hEZj+yISCU61kRZv uSQ0E11yYL4dRgcglJeaHo3oX57rvIckaLsYV5/1Aj+R8DM1Ppk965XQAKsHfnyT7C4S50T4lVn4 lz36wOdNZn/zegG1zp41lnoTFfT4KuKVJH5x7YD1p6KbgJCKLovnujGuohquBNfdXKpZkvz6pGv+ iC1HawJdAgMBAAGjgaAwgZ0wDgYDVR0PAQH/BAQDAgEGMB0GA1UdDgQWBBQaxgxKxEdvqNutK/D0 Vgaj7TdUDDA6BgNVHR8EMzAxMC+gLaArhilodHRwOi8vY3JsLmdlb3RydXN0LmNvbS9jcmxzL3Nl Y3VyZWNhLmNybDAfBgNVHSMEGDAWgBRI5mj5K9KylddH2CMgEE8zmJCf1DAPBgNVHRMBAf8EBTAD AQH/MA0GCSqGSIb3DQEBBQUAA4GBABMQOK2kVKVIlUWwLTdywJ+e2O+PC/uQltK2F3lRyrPfBn69 tOkIP4SgDJOfsxyobIrPLe75kBLw+Dom13OBDp/EMZJZ1CglQfVV8co9mT3aZMjSGGQiMgkJLR3j Mfr900fXZKj5XeqCJ+JP0mEhJGEdVCY+FFlksJjV86fDrq1QMIIFijCCBHKgAwIBAgIKYSCKYgAA AAAACDANBgkqhkiG9w0BAQUFADBSMQswCQYDVQQGEwJVUzEaMBgGA1UEChMRSW50ZWwgQ29ycG9y YXRpb24xJzAlBgNVBAMTHkludGVsIEV4dGVybmFsIEJhc2ljIFBvbGljeSBDQTAeFw0wOTA1MTUx OTI3MjZaFw0xNTA1MTUxOTM3MjZaMFYxCzAJBgNVBAYTAlVTMRowGAYDVQQKExFJbnRlbCBDb3Jw b3JhdGlvbjErMCkGA1UEAxMiSW50ZWwgRXh0ZXJuYWwgQmFzaWMgSXNzdWluZyBDQSAzQjCCASIw DQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAKQEM1Wn9TU9vc9C+/Tc7KB+eiYElmrcEWE32WUd HvWG+IcQHVQsikTmMyKKojNLw2B5s6Iekc8ivDo/wCfjZzX9JyftMnc+AArc0la87Olybzm8K9jX EfTBvTnUSFSiI9ZYefITdiUgqlAFuljFZEHYKYtLuhrRacpmQfP4mV63NKdc2bT804HRf6YptZFa 4k6YN94zlrGNrBuQQ74WFzz/jLBusbUpEkro6Mu/ZYFOFWQrV9lBhF9Ruk8yN+3N6n9fUo/qBigi F2kEn9xVh1ykl7SCGL2jBUkXx4qgV27a6Si8lRRdgrHGtN/HWnSWlLXTH5l575H4Lq++77OFv38C AwEAAaOCAlwwggJYMA8GA1UdEwEB/wQFMAMBAf8wHQYDVR0OBBYEFA7GKvdZsggQkCVvw939imYx MCvFMAsGA1UdDwQEAwIBhjASBgkrBgEEAYI3FQEEBQIDAQABMCMGCSsGAQQBgjcVAgQWBBQ5oFY2 ekKQ/5Ktim+VdMeSWb4QWTAZBgkrBgEEAYI3FAIEDB4KAFMAdQBiAEMAQTAfBgNVHSMEGDAWgBQa xgxKxEdvqNutK/D0Vgaj7TdUDDCBvQYDVR0fBIG1MIGyMIGvoIGsoIGphk5odHRwOi8vd3d3Lmlu dGVsLmNvbS9yZXBvc2l0b3J5L0NSTC9JbnRlbCUyMEV4dGVybmFsJTIwQmFzaWMlMjBQb2xpY3kl MjBDQS5jcmyGV2h0dHA6Ly9jZXJ0aWZpY2F0ZXMuaW50ZWwuY29tL3JlcG9zaXRvcnkvQ1JML0lu dGVsJTIwRXh0ZXJuYWwlMjBCYXNpYyUyMFBvbGljeSUyMENBLmNybDCB4wYIKwYBBQUHAQEEgdYw gdMwYwYIKwYBBQUHMAKGV2h0dHA6Ly93d3cuaW50ZWwuY29tL3JlcG9zaXRvcnkvY2VydGlmaWNh dGVzL0ludGVsJTIwRXh0ZXJuYWwlMjBCYXNpYyUyMFBvbGljeSUyMENBLmNydDBsBggrBgEFBQcw AoZgaHR0cDovL2NlcnRpZmljYXRlcy5pbnRlbC5jb20vcmVwb3NpdG9yeS9jZXJ0aWZpY2F0ZXMv SW50ZWwlMjBFeHRlcm5hbCUyMEJhc2ljJTIwUG9saWN5JTIwQ0EuY3J0MA0GCSqGSIb3DQEBBQUA A4IBAQCxtQEHchVQhXyjEqtMVUMe6gkmPsIczHxSeqNbo9dsD+6xbT65JT+oYgpIAtfEsYXeUJu1 cChqpb22U5bMAz7eaQcW5bzefufWvA6lg2048B8oczBj/q+5P5NpYrUO8jOmN4jTjfJq3ElZ7yFW py7rB3Vm/aN6ATYqWfMbS/xfh+JCxmH3droUmMJI0/aZJHsLtjbjFnNsHDNrJZX1vxlM78Lb1hjs kTENPmhbVbfTj5i/ZGnhv4tmI8QZPCNtcegXJrfhRl2D9bWpdTOPrWiLDUqzy1Z6KL7TcOS/PCl8 RHCJXkPau/thTQCpIoDa2+c+3XA++gRTfAQ4svTO260NMIIGDzCCBPegAwIBAgIKMrqXMwABAAB4 /jANBgkqhkiG9w0BAQUFADBWMQswCQYDVQQGEwJVUzEaMBgGA1UEChMRSW50ZWwgQ29ycG9yYXRp b24xKzApBgNVBAMTIkludGVsIEV4dGVybmFsIEJhc2ljIElzc3VpbmcgQ0EgM0IwHhcNMTEwOTIw MDQzODAxWhcNMTQwOTA0MDQzODAxWjBBMRcwFQYDVQQDEw5KaWFuZywgWXVuaG9uZzEmMCQGCSqG SIb3DQEJARYXeXVuaG9uZy5qaWFuZ0BpbnRlbC5jb20wggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAw ggEKAoIBAQDGluME2LxwiaZBmdSeObEa8UoyyQ4118LL15UR62zUFyr2kdn7QQ2Co9qLKbtqZPZm xsNmtIC6V8zgOmCd9kq2CZphuFvrJQKBALrKbv3SuVDu2hyYnhfOKMZJtnOH7bw9kYWsrOtdF01z ChRgSz6dUXYCNvtlBIyKvAcsBKRH3ZVDKdvPgdZ6bSQIfkROR1LTplxq3lo4yBeAdYy+3XM40YMc QUAa2lHQNm/fovdPjMpdBL0LYEgiBKCjddpEPDOLKVfpNUV0Q7sjzyO6OL8fS50TLWY14DahsWRb maoNJO9puq2px4nykvb5mZRtNSJqn6Zz80gMRkyKa+yrw1ebAgMBAAGjggLyMIIC7jALBgNVHQ8E BAMCB4AwPAYJKwYBBAGCNxUHBC8wLQYlKwYBBAGCNxUIhsOMdYSZ5VGD/YEohY6fU4KRwAlngd69 OZXwQwIBZAIBCDAdBgNVHQ4EFgQUOTubyHaKHy8V2UbyBz1VEhvF404wHwYDVR0jBBgwFoAUDsYq 91myCBCQJW/D3f2KZjEwK8Uwgc8GA1UdHwSBxzCBxDCBwaCBvqCBu4ZXaHR0cDovL3d3dy5pbnRl bC5jb20vcmVwb3NpdG9yeS9DUkwvSW50ZWwlMjBFeHRlcm5hbCUyMEJhc2ljJTIwSXNzdWluZyUy MENBJTIwM0IoMSkuY3JshmBodHRwOi8vY2VydGlmaWNhdGVzLmludGVsLmNvbS9yZXBvc2l0b3J5 L0NSTC9JbnRlbCUyMEV4dGVybmFsJTIwQmFzaWMlMjBJc3N1aW5nJTIwQ0ElMjAzQigxKS5jcmww gfUGCCsGAQUFBwEBBIHoMIHlMGwGCCsGAQUFBzAChmBodHRwOi8vd3d3LmludGVsLmNvbS9yZXBv c2l0b3J5L2NlcnRpZmljYXRlcy9JbnRlbCUyMEV4dGVybmFsJTIwQmFzaWMlMjBJc3N1aW5nJTIw Q0ElMjAzQigxKS5jcnQwdQYIKwYBBQUHMAKGaWh0dHA6Ly9jZXJ0aWZpY2F0ZXMuaW50ZWwuY29t L3JlcG9zaXRvcnkvY2VydGlmaWNhdGVzL0ludGVsJTIwRXh0ZXJuYWwlMjBCYXNpYyUyMElzc3Vp bmclMjBDQSUyMDNCKDEpLmNydDAfBgNVHSUEGDAWBggrBgEFBQcDBAYKKwYBBAGCNwoDDDApBgkr BgEEAYI3FQoEHDAaMAoGCCsGAQUFBwMEMAwGCisGAQQBgjcKAwwwSwYDVR0RBEQwQqAnBgorBgEE AYI3FAIDoBkMF3l1bmhvbmcuamlhbmdAaW50ZWwuY29tgRd5dW5ob25nLmppYW5nQGludGVsLmNv bTANBgkqhkiG9w0BAQUFAAOCAQEAM2zDUSfyzj7kqPHtToqlASdoH5fWS8yNqtpC//2YFdqV8PZa hZbcsaTsi9st/Jld2nHPbTlR7RoY3JI5x8jVw++yjfz6DnRJn3TbQEKSC+r1jZMFeXJFEz3WWwRR raGRGsH9KlvtA60n5V4DqZMvKau4nvz6VFecAGfZGPe8f6Th7olmb48pMXFaQKnZokuQQXvVlXOi 4wFzm1Qhx//DZBLPTMyzR3nSbewXeJDFobwDDZl1eGoymmpPk8wUX343jx1CV0FgG7u4sEvXzBoe h30e6XHDLP500zYTt5QeX1R8v9Eumny1PPuxsx1X/QM4pWw6aP/JVDA+xQ+Wr7jNDzCCBlYwggU+ oAMCAQICCjK50GgAAQAAeP0wDQYJKoZIhvcNAQEFBQAwVjELMAkGA1UEBhMCVVMxGjAYBgNVBAoT EUludGVsIENvcnBvcmF0aW9uMSswKQYDVQQDEyJJbnRlbCBFeHRlcm5hbCBCYXNpYyBJc3N1aW5n IENBIDNCMB4XDTExMDkyMDA0MzcwNloXDTE0MDkwNDA0MzcwNlowQTEXMBUGA1UEAxMOSmlhbmcs IFl1bmhvbmcxJjAkBgkqhkiG9w0BCQEWF3l1bmhvbmcuamlhbmdAaW50ZWwuY29tMIIBIjANBgkq hkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAuS/sEhB+AG+TGAUigP7DhPRf7dDpO5IBEnsdOZk4MT1L md7SGnLJlPJij5ktbwQCvN1xMmdKG1TUJeMgI6sf6xSQIOzEtLjhJ0H700QnOJMI7L8iy6Yxpx5o q7RMdNHjIVBCCq/iHCQGCRLCDjkQCzzTjwGcvpYxy27dNF4PywSudUIln5cvlVUOJM61i48JObA1 bClVDzmA9b2CHWH0F9Zic5CVp3ZpRwvlvJiV/THcqiC1yZoN5s6DFn6lg1nybB0JNZt9AXvLC3N5 yBrMfQ1/jTQJ1Ubk/8hGkIxVOS5nwRUSQV4cmd4mY+pQpsCZ2x7xthojS4kr7lW6cElZLQIDAQAB o4IDOTCCAzUwCwYDVR0PBAQDAgQwMD0GCSsGAQQBgjcVBwQwMC4GJisGAQQBgjcVCIbDjHWEmeVR g/2BKIWOn1OCkcAJZ4S52UGHhP9OAgFkAgEMMEQGCSqGSIb3DQEJDwQ3MDUwDgYIKoZIhvcNAwIC AgCAMA4GCCqGSIb3DQMEAgIAgDAHBgUrDgMCBzAKBggqhkiG9w0DBzAdBgNVHQ4EFgQUH3wL5R5h cJPF0e3+Fi4mIg58jYcwHwYDVR0jBBgwFoAUDsYq91myCBCQJW/D3f2KZjEwK8Uwgc8GA1UdHwSB xzCBxDCBwaCBvqCBu4ZXaHR0cDovL3d3dy5pbnRlbC5jb20vcmVwb3NpdG9yeS9DUkwvSW50ZWwl MjBFeHRlcm5hbCUyMEJhc2ljJTIwSXNzdWluZyUyMENBJTIwM0IoMSkuY3JshmBodHRwOi8vY2Vy dGlmaWNhdGVzLmludGVsLmNvbS9yZXBvc2l0b3J5L0NSTC9JbnRlbCUyMEV4dGVybmFsJTIwQmFz aWMlMjBJc3N1aW5nJTIwQ0ElMjAzQigxKS5jcmwwgfUGCCsGAQUFBwEBBIHoMIHlMGwGCCsGAQUF BzAChmBodHRwOi8vd3d3LmludGVsLmNvbS9yZXBvc2l0b3J5L2NlcnRpZmljYXRlcy9JbnRlbCUy MEV4dGVybmFsJTIwQmFzaWMlMjBJc3N1aW5nJTIwQ0ElMjAzQigxKS5jcnQwdQYIKwYBBQUHMAKG aWh0dHA6Ly9jZXJ0aWZpY2F0ZXMuaW50ZWwuY29tL3JlcG9zaXRvcnkvY2VydGlmaWNhdGVzL0lu dGVsJTIwRXh0ZXJuYWwlMjBCYXNpYyUyMElzc3VpbmclMjBDQSUyMDNCKDEpLmNydDAfBgNVHSUE GDAWBggrBgEFBQcDBAYKKwYBBAGCNwoDBDApBgkrBgEEAYI3FQoEHDAaMAoGCCsGAQUFBwMEMAwG CisGAQQBgjcKAwQwSwYDVR0RBEQwQqAnBgorBgEEAYI3FAIDoBkMF3l1bmhvbmcuamlhbmdAaW50 ZWwuY29tgRd5dW5ob25nLmppYW5nQGludGVsLmNvbTANBgkqhkiG9w0BAQUFAAOCAQEAZ9Sdy8Lt E3PqdHP75WMmC7Ae5p8zY/5MIWT6sl9i4u0VlfzHHANvcJqhsxIkhoN2IpHQ7M6MFsIkWKubCPTi wr4CfYVq6HIQB/hxf7fk8tBMvKw+HiOt7helIZhFdScVtmq3ZYhD5pj6D+EuOh+zr7RhC2FnQxEW XpNUMFbOPdt492gfzZ1hkJsZ6paeIQchsyi3B3pPrIqg4pJgsb4rHZ6HsOdV+Y7QnwU7vXv6akm4 RsnHYTvlY+pkWRg2ArBoQFe/yRHWoL0OUa+ykfbA+IDdIirnxzr+E+FIhwPhubyspcANi2Nwgpo2 yH6u1VZ0dgnWrshpmZosIsh+s3CFqzGCA5IwggOOAgEBMGQwVjELMAkGA1UEBhMCVVMxGjAYBgNV BAoTEUludGVsIENvcnBvcmF0aW9uMSswKQYDVQQDEyJJbnRlbCBFeHRlcm5hbCBCYXNpYyBJc3N1 aW5nIENBIDNCAgoyupczAAEAAHj+MAkGBSsOAwIaBQCgggIDMBgGCSqGSIb3DQEJAzELBgkqhkiG 9w0BBwEwHAYJKoZIhvcNAQkFMQ8XDTExMDkzMDAyNTEyNVowIwYJKoZIhvcNAQkEMRYEFMJnPXK5 YiS5lgHUB2//Mpqmc04IMHMGCSsGAQQBgjcQBDFmMGQwVjELMAkGA1UEBhMCVVMxGjAYBgNVBAoT EUludGVsIENvcnBvcmF0aW9uMSswKQYDVQQDEyJJbnRlbCBFeHRlcm5hbCBCYXNpYyBJc3N1aW5n IENBIDNCAgoyudBoAAEAAHj9MHUGCyqGSIb3DQEJEAILMWagZDBWMQswCQYDVQQGEwJVUzEaMBgG A1UEChMRSW50ZWwgQ29ycG9yYXRpb24xKzApBgNVBAMTIkludGVsIEV4dGVybmFsIEJhc2ljIElz c3VpbmcgQ0EgM0ICCjK50GgAAQAAeP0wgbcGCSqGSIb3DQEJDzGBqTCBpjALBglghkgBZQMEASow CwYJYIZIAWUDBAEWMAoGCCqGSIb3DQMHMAsGCWCGSAFlAwQBAjAOBggqhkiG9w0DAgICAIAwBwYF Kw4DAgcwDQYIKoZIhvcNAwICAUAwDQYIKoZIhvcNAwICASgwBwYFKw4DAhowCwYJYIZIAWUDBAID MAsGCWCGSAFlAwQCAjALBglghkgBZQMEAgEwCgYIKoZIhvcNAgUwDQYJKoZIhvcNAQEBBQAEggEA ahsbaLnCR8ainJxFMkIniln8YXwZybbyDV55lrc3EMO4CSCUn5BtbqgghfV+/Uy99Fvih6lOhsGf bad+ywwt6nLTgCOYvDGb7skIKysQcE/DWZgEB6P7RIDYVGacmm515eoAlACKWnlyl7P4Cd4TI3bR H7dAmyDGgGlgoCe4rNGInRNVHyRLmtzcaCnOP2hdBKWWGYDuud6dHbY3PRAmYhVlvXlOKGVBg//e NR6AVWw4SXFUDeCJMj6VpHvUIk6BcngQaAVN95w3PnusMZ0pyEQpOk4KrFnQtLCnPNkv+xOCzyvI qUmE7HG7ECcHagHmwlW0/T93SHjbsxpTM2tvLQAAAAAAAA== ------=_NextPart_000_002B_01CC7F5E.E673BDA0-- --===============0875571846== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel --===============0875571846==-- From xen-devel-bounces@lists.xensource.com Thu Sep 29 20:00:16 2011 Return-path: <xen-devel-bounces@lists.xensource.com> Envelope-to: www-data@lists.xensource.com Delivery-date: Thu, 29 Sep 2011 20:00:16 -0700 Received: from localhost ([127.0.0.1] helo=lists.colo.xensource.com) by lists.xensource.com with esmtp (Exim 4.43) id 1R9TKh-0001De-34; Thu, 29 Sep 2011 20:00:15 -0700 Received: from mail216.messagelabs.com ([85.158.143.99]) by lists.xensource.com with esmtp (Exim 4.43) id 1R9TIU-0000zq-R0 for xen-devel@lists.xensource.com; Thu, 29 Sep 2011 19:57:59 -0700 X-Env-Sender: nupurghatnekar@gmail.com X-Msg-Ref: server-10.tower-216.messagelabs.com!1317351474!10308632!1 X-Originating-IP: [209.85.210.171] X-StarScan-Version: 6.4.1; banners=-,-,- X-VirusChecked: Checked Received: (qmail 22762 invoked from network); 30 Sep 2011 02:57:55 -0000 Received: from mail-iy0-f171.google.com (HELO mail-iy0-f171.google.com) (209.85.210.171) by server-10.tower-216.messagelabs.com with RC4-SHA encrypted SMTP; 30 Sep 2011 02:57:55 -0000 Received: by iagv1 with SMTP id v1so1796708iag.30 for <xen-devel@lists.xensource.com>; Thu, 29 Sep 2011 19:57:54 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :content-type; bh=6416bH6SLttGMP5r977dorpdsLX6MBFWwoyJlrJZcWM=; b=vTx+bFkHPR8aX1DJZs5a7nXKdcJxhYEmyeWnoXH8X0PKXq5IKXbQwh+tOzWtubE2/M tBqkr6DDGBSFUisxmW9krF+ak/MJHxVl0j/DzsswVwNBX/gXgTGhCnuZ4da/rWfGi5gk 0vzM99dWyZtfn5IOH3c/xuRJDyQ7jWIwOJ/QY= MIME-Version: 1.0 Received: by 10.68.31.199 with SMTP id c7mr17492573pbi.73.1317351473792; Thu, 29 Sep 2011 19:57:53 -0700 (PDT) Received: by 10.142.210.20 with HTTP; Thu, 29 Sep 2011 19:57:53 -0700 (PDT) In-Reply-To: <1316692074.23371.60.camel@zakaz.uk.xensource.com> References: <CAO8_4Vq7Q145GWwW8jG0oOs6TugQvP764njJ3JLtrAZ766tNUw@mail.gmail.com> <1316692074.23371.60.camel@zakaz.uk.xensource.com> Date: Fri, 30 Sep 2011 08:27:53 +0530 Message-ID: <CAO8_4Vq11UWq6ZBpKPJ4pS60t2OcXan8-eKPEqzdD_aGfc=Pww@mail.gmail.com> Subject: Re: [Xen-devel] Virtual File System in XEN From: Nupur Ghatnekar <nupurghatnekar@gmail.com> To: xen-devel@lists.xensource.com X-BeenThere: xen-devel@lists.xensource.com X-Mailman-Version: 2.1.5 Precedence: list List-Id: Xen developer discussion <xen-devel.lists.xensource.com> List-Unsubscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe> List-Post: <mailto:xen-devel@lists.xensource.com> List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help> List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=subscribe> Content-Type: multipart/mixed; boundary="===============0857319448==" Sender: xen-devel-bounces@lists.xensource.com Errors-To: xen-devel-bounces@lists.xensource.com --===============0857319448== Content-Type: multipart/alternative; boundary=bcaec520ecdba3c6c104ae1fca49 --bcaec520ecdba3c6c104ae1fca49 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable We are planning to port the VirtFS implemented in the KVM land ( http://www.sciweavers.org/publications/virtfs-virtualization-aware-file-sys= tem-pass-through) to XEN land. The advantages are 1) sharing 2) security 3)reduced translations On Thu, Sep 22, 2011 at 5:17 PM, Ian Campbell <Ian.Campbell@citrix.com>wrot= e: > On Thu, 2011-09-22 at 11:01 +0100, Nupur Ghatnekar wrote: > > We are an undergraduate group of students. For our final year project, > > we are planning to implement a Virtual File System in XEN. > > > > > > In a paravirtualised environment, an Userspace Application makes a > > system call for access to a file, the domU=E2=80=99s kernel traps it an= d > > converts it to an appropriate block number. Now this block number is > > on the Virtual Hard Disk. The blktap mechanism is used for block I/O. > > It involves using XenBus and a daemon in user space of Dom0 which with > > help of libaio fires the request on Dom0 File System. > > Just for completeness actual I/O doesn't go via XenBus but is instead > sent as grant references over a shared ring. > > > The current scenario involves multiple translations for getting the > > actual physical address. > > > > > > Our project intends to reduce the number of translations required > > during the fetching or satisfying of the request. > > > > The DomU kernel doesn=E2=80=99t convert the FS request to block and pas= ses on > > this to dom0 using a client-server mechanism. > > > > > > We intend to implement it using the 9P protocol.\ > > > > 1) The domU kernel=E2=80=99s filesystem component will be a client and = the > > dom0 will be the server. > > > > 2) The domU=E2=80=99s kernel will send the file request to dom0 using t= he 9P > > protocol rather than converting it to appropriate block no. > > > > 3) The server in dom0 will authenticate the request, process it and > > send the appropriate replies. > > > > > > By having a virtual file system, the hypervisor will have a better > > understanding of what the guest domains are doing and hence this can > > help in taking intelligent decisions and thereby have better results > > in caching, de-duplication and snapshots. > > > > > > > > Any suggestions for our proposed project would be appreciated. > > There has been some work on a 9p driver for virtio recently (see the > qemu list), combining that with the virtio-on-xen GSoC project would > like a decent approach to implementing this. > > Ian. > > > -- > > > > Nupur Ghatnekar > > > --=20 Nupur Ghatnekar --bcaec520ecdba3c6c104ae1fca49 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable <span class=3D"Apple-style-span" style=3D"color: rgb(32, 32, 32); font-fami= ly: 'Droid Sans', arial, sans-serif; font-size: 13px; background-co= lor: rgb(255, 255, 255); ">We are planning to port the VirtFS implemented i= n the KVM land (</span><span class=3D"Apple-style-span" style=3D"color: rgb= (32, 32, 32); font-family: 'Droid Sans', arial, sans-serif; font-si= ze: 13px; background-color: rgb(255, 255, 255); ">=C2=A0</span><a href=3D"h= ttp://www.sciweavers.org/publications/virtfs-virtualization-aware-file-syst= em-pass-through">http://www.sciweavers.org/publications/virtfs-virtualizati= on-aware-file-system-pass-through</a><span class=3D"Apple-style-span" style= =3D"color: rgb(32, 32, 32); font-family: 'Droid Sans', arial, sans-= serif; font-size: 13px; background-color: rgb(255, 255, 255); ">) to XEN la= nd.=C2=A0</span><div> <span class=3D"Apple-style-span" style=3D"color: rgb(32, 32, 32); font-fami= ly: 'Droid Sans', arial, sans-serif; font-size: 13px; background-co= lor: rgb(255, 255, 255); "><br>The advantages are=C2=A0</span><div><span cl= ass=3D"Apple-style-span" style=3D"color: rgb(32, 32, 32); font-family: '= ;Droid Sans', arial, sans-serif; font-size: 13px; background-color: rgb= (255, 255, 255); ">1) sharing=C2=A0</span></div> <div><span class=3D"Apple-style-span" style=3D"color: rgb(32, 32, 32); font= -family: 'Droid Sans', arial, sans-serif; font-size: 13px; backgrou= nd-color: rgb(255, 255, 255); ">2) security=C2=A0</span></div><div><span cl= ass=3D"Apple-style-span" style=3D"color: rgb(32, 32, 32); font-family: '= ;Droid Sans', arial, sans-serif; font-size: 13px; background-color: rgb= (255, 255, 255); ">3)reduced translations</span><br> <br><div class=3D"gmail_quote">On Thu, Sep 22, 2011 at 5:17 PM, Ian Campbel= l <span dir=3D"ltr"><<a href=3D"mailto:Ian.Campbell@citrix.com" target= =3D"_blank">Ian.Campbell@citrix.com</a>></span> wrote:<br><blockquote cl= ass=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;p= adding-left:1ex"> <div>On Thu, 2011-09-22 at 11:01 +0100, Nupur Ghatnekar wrote:<br> > We are an undergraduate group of students. For our final year project,= <br> > we are planning to implement a Virtual File System in XEN.<br> ><br> ><br> > In a paravirtualised environment, an Userspace Application makes a<br> > system call for access to a file, the domU=E2=80=99s kernel traps it a= nd<br> > converts it to an appropriate block number. Now this block number is<b= r> > on the Virtual Hard Disk. The blktap mechanism is used for block I/O.<= br> > It involves using XenBus and a daemon in user space of Dom0 which with= <br> > help of libaio fires the request on Dom0 File System.<br> <br> </div>Just for completeness actual I/O doesn't go via XenBus but is ins= tead<br> sent as grant references over a shared ring.<br> <div><br> > =C2=A0The current scenario involves multiple translations for getting = the<br> > actual physical address.<br> ><br> ><br> > Our project intends to reduce the number of translations required<br> > during the fetching or satisfying of the request.<br> ><br> > The DomU kernel doesn=E2=80=99t convert the FS request to block and pa= sses on<br> > this to dom0 using a client-server mechanism.<br> ><br> ><br> > We intend to implement it using the 9P protocol.\<br> ><br> > 1) The domU kernel=E2=80=99s filesystem component will be a client and= the<br> > dom0 will be the server.<br> ><br> > 2) The domU=E2=80=99s kernel will send the file request to dom0 using = the 9P<br> > protocol rather than converting it to appropriate block no.<br> ><br> > 3) The server in dom0 will authenticate the request, process it and<br= > > send the appropriate replies.<br> ><br> ><br> > By having a virtual file system, the hypervisor will have a better<br> > understanding of what the guest domains are doing and hence this can<b= r> > help in taking intelligent decisions and thereby have better results<b= r> > in caching, de-duplication and snapshots.<br> ><br> ><br> ><br> > Any suggestions for our proposed project would be appreciated.<br> <br> </div>There has been some work on a 9p driver for virtio recently (see the<= br> qemu list), combining that with the virtio-on-xen GSoC project would<br> like a decent approach to implementing this.<br> <br> Ian.<br> <br> > --<br> ><br> > Nupur Ghatnekar<br> <br> <br> </blockquote></div><br><br clear=3D"all"><div><br></div>-- <br><br>Nupur Gh= atnekar<br> </div></div> --bcaec520ecdba3c6c104ae1fca49-- --===============0857319448== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel --===============0857319448==-- From xen-devel-bounces@lists.xensource.com Thu Sep 29 21:18:59 2011 Return-path: <xen-devel-bounces@lists.xensource.com> Envelope-to: www-data@lists.xensource.com Delivery-date: Thu, 29 Sep 2011 21:18:59 -0700 Received: from localhost ([127.0.0.1] helo=lists.colo.xensource.com) by lists.xensource.com with esmtp (Exim 4.43) id 1R9UYr-00031j-4m; Thu, 29 Sep 2011 21:18:57 -0700 Received: from mail27.messagelabs.com ([193.109.254.147]) by lists.xensource.com with esmtp (Exim 4.43) id 1R9UY2-0002pD-9p for xen-devel@lists.xensource.com; Thu, 29 Sep 2011 21:18:06 -0700 X-Env-Sender: davidxu06@gmail.com X-Msg-Ref: server-2.tower-27.messagelabs.com!1317356255!57050130!1 X-Originating-IP: [209.85.213.43] X-StarScan-Version: 6.4.1; banners=-,-,- X-VirusChecked: Checked Received: (qmail 3799 invoked from network); 30 Sep 2011 04:17:36 -0000 Received: from mail-yw0-f43.google.com (HELO mail-yw0-f43.google.com) (209.85.213.43) by server-2.tower-27.messagelabs.com with RC4-SHA encrypted SMTP; 30 Sep 2011 04:17:36 -0000 Received: by ywm21 with SMTP id 21so1648152ywm.30 for <xen-devel@lists.xensource.com>; Thu, 29 Sep 2011 21:18:01 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:date:message-id:subject:from:to:content-type; bh=/paMKaG04W2W6vjlrFf8SLBMK5YiCeH2fatFad5n/ts=; b=r0Vmf3XNYnPsDMw6AomQbnbyHVWQ7DF6Vmuup3hvMZbnQDM1c7VloDi/FFYf8OtVIa oBDKEW0r6XOF14a0tpuhx/MqE1OJpV0sSIfah+uS0y/EdnClNv62KekxPiBTh6w5O1xn glWzFmJjglXRYuDA5GEbhC+cE7VYMHP4veXIw= MIME-Version: 1.0 Received: by 10.150.22.40 with SMTP id 40mr10957978ybv.395.1317356281667; Thu, 29 Sep 2011 21:18:01 -0700 (PDT) Received: by 10.150.157.13 with HTTP; Thu, 29 Sep 2011 21:18:01 -0700 (PDT) Date: Fri, 30 Sep 2011 00:18:01 -0400 Message-ID: <CAGjowiTc0NAJbWR-RxwLTrz+bhbAFfvcPKPAB_F8r1ef6__PbA@mail.gmail.com> From: David Xu <davidxu06@gmail.com> To: xen-devel <xen-devel@lists.xensource.com> Content-Type: text/plain; charset=ISO-8859-1 Subject: [Xen-devel] ring buffer overflow X-BeenThere: xen-devel@lists.xensource.com X-Mailman-Version: 2.1.5 Precedence: list List-Id: Xen developer discussion <xen-devel.lists.xensource.com> List-Unsubscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe> List-Post: <mailto:xen-devel@lists.xensource.com> List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help> List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=subscribe> Sender: xen-devel-bounces@lists.xensource.com Errors-To: xen-devel-bounces@lists.xensource.com Hi, Does anybody know whether the ring buffer between front end and back end will suffer from overflow? I just wonder if the ring buffer will be full and drop some packets when the Net I/O load is very heavy. BTW, If I want to change the size of i/o ring buffer, how should I do? I tried to reset the NET_TX_RING_SIZE and NET_RX_RING_SIZE in both front end and back end, but it seems doesn't work. Thanks. Regards, Cong _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel From xen-devel-bounces@lists.xensource.com Thu Sep 29 21:37:30 2011 Return-path: <xen-devel-bounces@lists.xensource.com> Envelope-to: www-data@lists.xensource.com Delivery-date: Thu, 29 Sep 2011 21:37:30 -0700 Received: from localhost ([127.0.0.1] helo=lists.colo.xensource.com) by lists.xensource.com with esmtp (Exim 4.43) id 1R9Uqn-0003rM-Iu; Thu, 29 Sep 2011 21:37:29 -0700 Received: from mail21.messagelabs.com ([85.158.143.35]) by lists.xensource.com with esmtp (Exim 4.43) id 1R9Upr-0003ex-3l for xen-devel@lists.xensource.com; Thu, 29 Sep 2011 21:36:31 -0700 X-Env-Sender: Ian.Jackson@eu.citrix.com X-Msg-Ref: server-12.tower-21.messagelabs.com!1317357372!51899485!1 X-Originating-IP: [62.200.22.115] X-StarScan-Version: 6.4.1; banners=-,-,- X-VirusChecked: Checked Received: (qmail 22166 invoked from network); 30 Sep 2011 04:36:12 -0000 Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115) by server-12.tower-21.messagelabs.com with RC4-SHA encrypted SMTP; 30 Sep 2011 04:36:12 -0000 X-IronPort-AV: E=Sophos;i="4.68,464,1312156800"; d="scan'208";a="8140607" Received: from lonpmailmx01.citrite.net ([10.30.203.162]) by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5; 30 Sep 2011 04:36:27 +0000 Received: from norwich.cam.xci-test.com (10.80.248.129) by smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id 8.3.137.0; Fri, 30 Sep 2011 05:36:27 +0100 Received: from [10.80.248.135] (helo=woking.xci-test.com) by norwich.cam.xci-test.com with esmtp (Exim 4.72) (envelope-from <ian.jackson@eu.citrix.com>) id 1R9Upm-0003Ke-W9; Fri, 30 Sep 2011 04:36:27 +0000 Received: from osstest by woking.xci-test.com with local (Exim 4.69) (envelope-from <ian.jackson@eu.citrix.com>) id 1R9Upm-0004SO-V8; Fri, 30 Sep 2011 05:36:26 +0100 To: xen-devel@lists.xensource.com Message-ID: <osstest-9138-mainreport@xen.org> From: xen.org <ian.jackson@eu.citrix.com> Date: Fri, 30 Sep 2011 05:36:26 +0100 MIME-Version: 1.0 Content-Type: text/plain Cc: ian.jackson@eu.citrix.com Subject: [Xen-devel] [xen-unstable test] 9138: regressions - FAIL X-BeenThere: xen-devel@lists.xensource.com X-Mailman-Version: 2.1.5 Precedence: list List-Id: Xen developer discussion <xen-devel.lists.xensource.com> List-Unsubscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe> List-Post: <mailto:xen-devel@lists.xensource.com> List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help> List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=subscribe> Sender: xen-devel-bounces@lists.xensource.com Errors-To: xen-devel-bounces@lists.xensource.com flight 9138 xen-unstable real [real] http://www.chiark.greenend.org.uk/~xensrcts/logs/9138/ Regressions :-( Tests which did not succeed and are blocking: test-amd64-amd64-xl-pcipt-intel 8 debian-fixup fail REGR. vs. 9118 test-amd64-i386-xl-multivcpu 9 guest-start fail REGR. vs. 9118 test-amd64-i386-xl 9 guest-start fail REGR. vs. 9118 test-amd64-i386-xl-credit2 9 guest-start fail REGR. vs. 9118 test-amd64-i386-rhel6hvm-intel 7 redhat-install fail REGR. vs. 9118 test-i386-i386-xl 9 guest-start fail REGR. vs. 9118 test-amd64-amd64-xl-sedf 9 guest-start fail REGR. vs. 9118 test-amd64-amd64-xl 9 guest-start fail REGR. vs. 9118 test-amd64-i386-rhel6hvm-amd 7 redhat-install fail REGR. vs. 9118 test-amd64-i386-xl-win-vcpus1 7 windows-install fail REGR. vs. 9118 test-amd64-amd64-xl-win 7 windows-install fail REGR. vs. 9118 test-i386-i386-xl-win 7 windows-install fail REGR. vs. 9118 Tests which are failing intermittently (not blocking): test-i386-i386-win 14 guest-start.2 fail pass in 9121 build-amd64-pvops 4 kernel-build fail in 9121 pass in 9138 Tests which did not succeed, but are not blocking, including regressions (tests previously passed) regarded as allowable: test-amd64-i386-win-vcpus1 16 leak-check/check fail never pass test-amd64-i386-win 16 leak-check/check fail never pass test-amd64-amd64-win 16 leak-check/check fail never pass test-amd64-amd64-xl-pcipt-intel 1 xen-build-check(1) blocked in 9121 n/a test-amd64-amd64-pv 1 xen-build-check(1) blocked in 9121 n/a test-amd64-amd64-xl-sedf 1 xen-build-check(1) blocked in 9121 n/a test-amd64-amd64-pair 1 xen-build-check(1) blocked in 9121 n/a test-amd64-amd64-xl 1 xen-build-check(1) blocked in 9121 n/a test-amd64-amd64-win 1 xen-build-check(1) blocked in 9121 n/a test-amd64-amd64-xl-win 1 xen-build-check(1) blocked in 9121 n/a test-i386-i386-win 16 leak-check/check fail in 9121 never pass version targeted for testing: xen e78cd03b0308 baseline version: xen 7998217630e2 ------------------------------------------------------------ People who touched revisions under test: Adin Scannell <adin@scannell.ca> Anthony PERARD <anthony.perard@citrix.com> Ian Campbell <ian.campbell@citrix.com> Ian Jackson <ian.jackson.citrix.com> Ian Jackson <ian.jackson@eu.citrix.com> Olaf Hering <olaf@aepfle.de> ------------------------------------------------------------ jobs: build-amd64 pass build-i386 pass build-amd64-oldkern pass build-i386-oldkern pass build-amd64-pvops pass build-i386-pvops pass test-amd64-amd64-xl fail test-amd64-i386-xl fail test-i386-i386-xl fail test-amd64-i386-rhel6hvm-amd fail test-amd64-i386-xl-credit2 fail test-amd64-amd64-xl-pcipt-intel fail test-amd64-i386-rhel6hvm-intel fail test-amd64-i386-xl-multivcpu fail test-amd64-amd64-pair pass test-amd64-i386-pair pass test-i386-i386-pair pass test-amd64-amd64-pv pass test-amd64-i386-pv pass test-i386-i386-pv pass test-amd64-amd64-xl-sedf fail test-amd64-i386-win-vcpus1 fail test-amd64-i386-xl-win-vcpus1 fail test-amd64-amd64-win fail test-amd64-i386-win fail test-i386-i386-win fail test-amd64-amd64-xl-win fail test-i386-i386-xl-win fail ------------------------------------------------------------ sg-report-flight on woking.cam.xci-test.com logs: /home/xc_osstest/logs images: /home/xc_osstest/images Logs, config files, etc. are available at http://www.chiark.greenend.org.uk/~xensrcts/logs Test harness code can be found at http://xenbits.xensource.com/gitweb?p=osstest.git;a=summary Not pushing. ------------------------------------------------------------ changeset: 23894:e78cd03b0308 tag: tip user: Anthony PERARD <anthony.perard@citrix.com> date: Thu Sep 29 16:31:24 2011 +0100 libxl: libxl_qmp: use of libxl__fd_set_cloexec. Signed-off-by: Anthony PERARD <anthony.perard@citrix.com> Acked-by: Ian Jackson <ian.jackson@eu.citrix.com> Committed-by: Ian Jackson <ian.jackson@eu.citrix.com> changeset: 23893:95a40ee93806 user: Anthony PERARD <anthony.perard@citrix.com> date: Thu Sep 29 16:30:54 2011 +0100 libxl: Introduce a QMP client QMP stands for QEMU Monitor Protocol and it is used to query information from QEMU or to control QEMU. This implementation will ask QEMU the list of chardevice and store the path to serial ports in xenstored. So we will be able to use xl console with QEMU upstream. In order to connect to the QMP server, a socket file is created in /var/run/xen/qmp-libxl-$(domid). Signed-off-by: Anthony PERARD <anthony.perard@citrix.com> Committed-by: Ian Jackson <ian.jackson@eu.citrix.com> changeset: 23892:5f397994e6d6 user: Anthony PERARD <anthony.perard@citrix.com> date: Thu Sep 29 16:28:24 2011 +0100 libxl: Introduce JSON parser We use the yajl parser, but we need to make a tree from the parse result to use it outside the parser. So this patch include json_object struct that is used to hold the JSON data. Signed-off-by: Anthony PERARD <anthony.perard@citrix.com> Committed-by: Ian Jackson <ian.jackson.citrix.com> Acked-by: Ian Campbell <ian.campbell@citrix.com> changeset: 23891:066dc3758fa4 user: Anthony PERARD <anthony.perard@citrix.com> date: Thu Sep 29 16:28:23 2011 +0100 libxl: Intruduce libxl__strndup. Signed-off-by: Anthony PERARD <anthony.perard@citrix.com> Committed-by: Ian Jackson <ian.jackson.citrix.com> Acked-by: Ian Campbell <ian.campbell@citrix.com> changeset: 23890:952e0118a7c4 user: Anthony PERARD <anthony.perard@citrix.com> date: Thu Sep 29 16:28:22 2011 +0100 libxl: Introduce libxl__realloc. Signed-off-by: Anthony PERARD <anthony.perard@citrix.com> Committed-by: Ian Jackson <ian.jackson.citrix.com> Acked-by: Ian Campbell <ian.campbell@citrix.com> changeset: 23889:f51dcd8acb7b user: Anthony PERARD <anthony.perard@citrix.com> date: Thu Sep 29 16:28:22 2011 +0100 libxl: Introduce libxl_internal_types.idl. Signed-off-by: Anthony PERARD <anthony.perard@citrix.com> Committed-by: Ian Jackson <ian.jackson.citrix.com> Acked-by: Ian Campbell <ian.campbell@citrix.com> changeset: 23888:f5ee5ad45425 user: Anthony PERARD <anthony.perard@citrix.com> date: Thu Sep 29 16:28:21 2011 +0100 libxl: Add get/set_default_namespace in libxltypes.py. Signed-off-by: Anthony PERARD <anthony.perard@citrix.com> Committed-by: Ian Jackson <ian.jackson.citrix.com> Acked-by: Ian Campbell <ian.campbell@citrix.com> changeset: 23887:a543e10211f7 user: Anthony PERARD <anthony.perard@citrix.com> date: Thu Sep 29 16:28:20 2011 +0100 libxl: Rename libxl.idl to libxl_types.idl. Signed-off-by: Anthony PERARD <anthony.perard@citrix.com> Committed-by: Ian Jackson <ian.jackson.citrix.com> Acked-by: Ian Campbell <ian.campbell@citrix.com> changeset: 23886:cf2ba5720151 user: Anthony PERARD <anthony.perard@citrix.com> date: Thu Sep 29 16:06:02 2011 +0100 libxl: Introduce libxl__fd_set_cloexec Signed-off-by: Anthony PERARD <anthony.perard@citrix.com> Acked-by: Ian Jackson <ian.jackson@eu.citrix.com> Committed-by: Ian Jackson <ian.jackson@eu.citrix.com> changeset: 23885:cd60c87d3496 user: Ian Campbell <ian.campbell@citrix.com> date: Thu Sep 29 15:40:34 2011 +0100 xl: fixup command line handling for several commands. def_getopt already checks for a minimum number of arguments for us. "xl save" simply need to use the correct argument for that value, contrary to the change I made in 23876:b113d626cfaf "xl block-list" does not need to check for at least 2 arguments, since it's already been done by def_getopt. "xl network-list" would previous accept zero arguments and just print the table header. Insist on a domain argument. Signed-off-by: Ian Campbell <ian.campbell@citrix.com> Acked-by: Ian Jackson <ian.jackson@eu.citrix.com> Committed-by: Ian Jackson <ian.jackson@eu.citrix.com> changeset: 23884:145e146876b3 user: Adin Scannell <adin@gridcentric.com> date: Thu Sep 29 15:26:04 2011 +0100 libxl: Expose number of shared pages Signed-off-by: Adin Scannell <adin@scannell.ca> Acked-by: Ian Jackson <ian.jackson@eu.citrix.com> Committed-by: Ian Jackson <ian.jackson@eu.citrix.com> changeset: 23883:7998217630e2 user: Ian Campbell <ian.campbell@citrix.com> date: Wed Sep 28 16:42:11 2011 +0100 libxl: attempt to cleanup tapdisk processes on disk backend destroy. Signed-off-by: Ian Campbell <ian.campbell@citrix.com> Committed-by: Ian Jackson <ian.jackson@eu.citrix.com> ======================================== commit cd776ee9408ff127f934a707c1a339ee600bc127 Author: Ian Jackson <ian.jackson@eu.citrix.com> Date: Tue Jun 28 13:50:53 2011 +0100 qemu-char.c: fix incorrect CONFIG_STUBDOM handling qemu-char.c:1123:7: warning: "CONFIG_STUBDOM" is not defined [-Wundef] Signed-off-by: Olaf Hering <olaf@aepfle.de> Acked-by: Ian Jackson <ian.jackson@eu.citrix.com> _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel From xen-devel-bounces@lists.xensource.com Thu Sep 29 21:41:39 2011 Return-path: <xen-devel-bounces@lists.xensource.com> Envelope-to: www-data@lists.xensource.com Delivery-date: Thu, 29 Sep 2011 21:41:39 -0700 Received: from localhost ([127.0.0.1] helo=lists.colo.xensource.com) by lists.xensource.com with esmtp (Exim 4.43) id 1R9Uuo-0004H9-VU; Thu, 29 Sep 2011 21:41:38 -0700 Received: from mail21.messagelabs.com ([85.158.143.35]) by lists.xensource.com with esmtp (Exim 4.43) id 1R9UuH-00045I-Up for xen-devel@lists.xensource.com; Thu, 29 Sep 2011 21:41:06 -0700 X-Env-Sender: jeremy@goop.org X-Msg-Ref: server-11.tower-21.messagelabs.com!1317357643!44541051!1 X-Originating-IP: [74.207.240.146] X-StarScan-Version: 6.4.1; banners=-,-,- X-VirusChecked: Checked Received: (qmail 28713 invoked from network); 30 Sep 2011 04:40:45 -0000 Received: from claw.goop.org (HELO claw.goop.org) (74.207.240.146) by server-11.tower-21.messagelabs.com with DHE-RSA-AES256-SHA encrypted SMTP; 30 Sep 2011 04:40:44 -0000 Received: from saboo.goop.org (unknown [IPv6:2001:470:1f05:899:224:d7ff:feba:c318]) (Authenticated sender: smtp-saboo) by claw.goop.org (Postfix) with ESMTPSA id 86B1B908C; Thu, 29 Sep 2011 21:41:00 -0700 (PDT) Received: from saboo.goop.org (localhost [IPv6:::1]) by saboo.goop.org (Postfix) with ESMTP id 93F4D2092F; Thu, 29 Sep 2011 21:40:57 -0700 (PDT) Message-ID: <4E854859.4020105@goop.org> Date: Thu, 29 Sep 2011 21:40:57 -0700 From: Jeremy Fitzhardinge <jeremy@goop.org> User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:6.0.2) Gecko/20110906 Thunderbird/6.0.2 MIME-Version: 1.0 To: Steven Rostedt <rostedt@goodmis.org> References: <cover.1317338254.git.jeremy.fitzhardinge@citrix.com> <1317343975.4588.36.camel@gandalf.stny.rr.com> In-Reply-To: <1317343975.4588.36.camel@gandalf.stny.rr.com> X-Enigmail-Version: 1.3.2 Content-Type: text/plain; charset=ISO-8859-15 Content-Transfer-Encoding: 7bit Cc: Xen Devel <xen-devel@lists.xensource.com>, Jan Glauber <jang@linux.vnet.ibm.com>, Jason Baron <jbaron@redhat.com>, the arch/x86 maintainers <x86@kernel.org>, David Daney <david.daney@cavium.com>, Linux Kernel Mailing List <linux-kernel@vger.kernel.org>, Michael Ellerman <michael@ellerman.id.au>, Jeremy Fitzhardinge <jeremy.fitzhardinge@citrix.com>, "David S. Miller" <davem@davemloft.net> Subject: [Xen-devel] Re: [PATCH RFC 0/8] jump-label: allow early jump_label_enable() X-BeenThere: xen-devel@lists.xensource.com X-Mailman-Version: 2.1.5 Precedence: list List-Id: Xen developer discussion <xen-devel.lists.xensource.com> List-Unsubscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe> List-Post: <mailto:xen-devel@lists.xensource.com> List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help> List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=subscribe> Sender: xen-devel-bounces@lists.xensource.com Errors-To: xen-devel-bounces@lists.xensource.com On 09/29/2011 05:52 PM, Steven Rostedt wrote: > On Thu, 2011-09-29 at 16:26 -0700, Jeremy Fitzhardinge wrote: >> From: Jeremy Fitzhardinge <jeremy.fitzhardinge@citrix.com> >> >> One big question which arises is whether the _early() function is >> necessary at all. All the stop_machine/mutex/etc stuff that >> arch_jump_label_transform() ends up doing is redundant pre-SMP, but it >> shouldn't hurt. Maybe we can just drop the _early function? It works >> on x86, at least, because jump_label_enable() works, which uses the full >> form. And dropping it would reduce this to a very much smaller series. > It does slow down the boot process, which is not a good thing when > everyone is pushing for the fastest restarts. Would it really though? stop_machine() doesn't do very much when there are no other cpus. Not that I measured or anything, but there was no obvious big lag at boot. > What we should probably do is have a global read_mostly variable called, > smp_activated or something, then things that can be called before and > after can read this variable to determine if it can skip certain > protections. Could do that if it turns out to be a problem. > While we're at it, perhaps we could add a memory_initialized for things > like tracers that want to trace early but need to wait till it can > allocate buffers. If we had this flag, it could instead do an early > memory init to create the buffers. That seems orthogonal to the jump_label changes. J _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel From xen-devel-bounces@lists.xensource.com Thu Sep 29 22:34:54 2011 Return-path: <xen-devel-bounces@lists.xensource.com> Envelope-to: www-data@lists.xensource.com Delivery-date: Thu, 29 Sep 2011 22:34:54 -0700 Received: from localhost ([127.0.0.1] helo=lists.colo.xensource.com) by lists.xensource.com with esmtp (Exim 4.43) id 1R9VkM-0005dQ-0K; Thu, 29 Sep 2011 22:34:54 -0700 Received: from mail216.messagelabs.com ([85.158.143.99]) by lists.xensource.com with smtp (Exim 4.43) id 1R9Vjd-0005Rb-Ot for xen-devel@lists.xensource.com; Thu, 29 Sep 2011 22:34:10 -0700 X-Env-Sender: chao.zhou@intel.com X-Msg-Ref: server-4.tower-216.messagelabs.com!1317360846!20062714!1 X-Originating-IP: [143.182.124.21] X-StarScan-Version: 6.4.1; banners=-,-,- X-VirusChecked: Checked Received: (qmail 26507 invoked from network); 30 Sep 2011 05:34:06 -0000 Received: from mga03.intel.com (HELO mga03.intel.com) (143.182.124.21) by server-4.tower-216.messagelabs.com with SMTP; 30 Sep 2011 05:34:06 -0000 Received: from azsmga001.ch.intel.com ([10.2.17.19]) by azsmga101.ch.intel.com with ESMTP; 29 Sep 2011 22:34:05 -0700 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="4.68,465,1312182000"; d="scan'208";a="57241968" Received: from pgsmsx602.gar.corp.intel.com ([10.221.43.81]) by azsmga001.ch.intel.com with ESMTP; 29 Sep 2011 22:34:04 -0700 Received: from pgsmsx151.gar.corp.intel.com (172.30.236.41) by pgsmsx602.gar.corp.intel.com (10.221.43.81) with Microsoft SMTP Server (TLS) id 8.2.255.0; Fri, 30 Sep 2011 13:33:31 +0800 Received: from shsmsx601.ccr.corp.intel.com (10.239.4.112) by PGSMSX151.gar.corp.intel.com (172.30.236.41) with Microsoft SMTP Server (TLS) id 14.1.323.3; Fri, 30 Sep 2011 13:33:30 +0800 Received: from shsmsx502.ccr.corp.intel.com ([10.239.4.96]) by shsmsx601.ccr.corp.intel.com ([10.239.4.112]) with mapi; Fri, 30 Sep 2011 13:33:30 +0800 From: "Zhou, Chao" <chao.zhou@intel.com> To: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com> Date: Fri, 30 Sep 2011 13:33:28 +0800 Thread-Topic: VMX status report. Xen:23883 & Dom0:20a27c1e2... Thread-Index: Acx/Mnun8oQN9VdoSfyz6WMCoCCHtA== Message-ID: <A24AE1FFE7AEC5489F83450EE98351BF43AA05E08B@shsmsx502.ccr.corp.intel.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: [Xen-devel] VMX status report. Xen:23883 & Dom0:20a27c1e2... X-BeenThere: xen-devel@lists.xensource.com X-Mailman-Version: 2.1.5 Precedence: list List-Id: Xen developer discussion <xen-devel.lists.xensource.com> List-Unsubscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe> List-Post: <mailto:xen-devel@lists.xensource.com> List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help> List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=subscribe> Sender: xen-devel-bounces@lists.xensource.com Errors-To: xen-devel-bounces@lists.xensource.com Hi all, This is the test report for xen-unstable tree. We found one bug about the g= uest failure to reboot after doing the migration got fixed. The guest will = reboot properly instead of shutdown when sending the reboot command to the = guest after doing the live-migration. Version Info =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D xen-changeset: 23883:7998217630e2 pvops git: commit 20a27c1e25b8550066902c9d6ca91631e656dfa3 =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D Test Environment =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D Platform Romley-EP(x86_64) Westmere-EP(x86_64) CPU 32 24 Memory 28G 12G =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D Fixed issue(1) =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D 1.[Save/Restore] guest failed to reboot after L-Migration it http://bugzilla.xensource.com/bugzilla/show_bug.cgi?id=3D1739 Old issues(6) =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D 1. [ACPI] System cann't resume after do suspend http://bugzilla.xensource.com/bugzilla/show_bug.cgi?id=3D1707 2.[XL]"xl vcpu-set" causes dom0 crash or panic http://bugzilla.xensource.com/bugzilla/show_bug.cgi?id=3D1730 3.[VT-D]fail to detach NIC from guest http://bugzilla.xensource.com/bugzilla/show_bug.cgi?id=3D1736 4.Dom0 crash on power-off http://bugzilla.xensource.com/bugzilla/show_bug.cgi?id=3D1740 5.Sometimes Xen panic on ia32pae Sandybridge when restore guest http://bugzilla.xensource.com/bugzilla/show_bug.cgi?id=3D1747 6.[VT-D] device reset fail when create/destroy guest http://bugzilla.xensource.com/bugzilla/show_bug.cgi?id=3D1752 Thanks, Zhou, Chao _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel From xen-devel-bounces@lists.xensource.com Thu Sep 29 23:34:18 2011 Return-path: <xen-devel-bounces@lists.xensource.com> Envelope-to: www-data@lists.xensource.com Delivery-date: Thu, 29 Sep 2011 23:34:18 -0700 Received: from localhost ([127.0.0.1] helo=lists.colo.xensource.com) by lists.xensource.com with esmtp (Exim 4.43) id 1R9Wfo-00071A-Un; Thu, 29 Sep 2011 23:34:16 -0700 Received: from mail27.messagelabs.com ([193.109.254.147]) by lists.xensource.com with esmtp (Exim 4.43) id 1R9Wem-0006oN-9s for xen-devel@lists.xensource.com; Thu, 29 Sep 2011 23:33:14 -0700 X-Env-Sender: Philippe.Simonet@swisscom.com X-Msg-Ref: server-2.tower-27.messagelabs.com!1317364362!57059176!1 X-Originating-IP: [193.222.81.100] X-StarScan-Version: 6.4.1; banners=-,-,- X-VirusChecked: Checked Received: (qmail 27277 invoked from network); 30 Sep 2011 06:32:42 -0000 Received: from outmail100.swisscom.com (HELO mail.swisscom.com) (193.222.81.100) by server-2.tower-27.messagelabs.com with DHE-RSA-AES256-SHA encrypted SMTP; 30 Sep 2011 06:32:42 -0000 Received: by mail.swisscom.com; Fri, 30 Sep 2011 08:33:01 +0200 From: <Philippe.Simonet@swisscom.com> To: <George.Dunlap@eu.citrix.com>, <dan.magenheimer@oracle.com> Subject: RE: [Xen-devel] Xen 4 TSC problems Thread-Topic: [Xen-devel] Xen 4 TSC problems Thread-Index: AQHMctqprSt5ec8j8ES+2DGqMTKTYJVOH1iAgACGzICABcOIgIARH1AQ Date: Fri, 30 Sep 2011 06:33:00 +0000 Message-ID: <FF93AF260AC2BB499A119CC65B092CF73114B774@sg000713.corproot.net> References: <AANLkTik3Ng6TpQANfPNJ2M=86WYLHVt7_MuBuVfJ1CG_@mail.gmail.com> <CAFLBxZZiGxef5CkH9r+VZeB4h7LPA0nJddumwDRovZaL4zOuvA@mail.gmail.com> <5224b434-5371-404d-8fed-2665e73dacce@default> <CAFLBxZZ3nP5EbtL=Ne-W4DcSWtKGh1XDOs-EhVua7ujmi9Y2Jw@mail.gmail.com> In-Reply-To: <CAFLBxZZ3nP5EbtL=Ne-W4DcSWtKGh1XDOs-EhVua7ujmi9Y2Jw@mail.gmail.com> Accept-Language: en-US, de-CH Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.65.122.32] Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: olivier.hanesse@gmail.com, jeremy@goop.org, xen-devel@lists.xensource.com, keir@xen.org, konrad.wilk@oracle.com X-BeenThere: xen-devel@lists.xensource.com X-Mailman-Version: 2.1.5 Precedence: list List-Id: Xen developer discussion <xen-devel.lists.xensource.com> List-Unsubscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe> List-Post: <mailto:xen-devel@lists.xensource.com> List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help> List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=subscribe> Sender: xen-devel-bounces@lists.xensource.com Errors-To: xen-devel-bounces@lists.xensource.com Hi Xen developpers i need some good tips to go forward with my TSC problem :=20 first fast the problem :=20 - clock jump 50 minutes forward : (xm dmesg) (XEN) TSC is reliable, synchronization unnecessary (XEN) Platform timer is 14.318MHz HPET (XEN) Platform timer appears to have unexpectedly wrapped 10 or more time= s (syslog) Sep 28 17:45:06 dnsit11 kernel: [1970548.356130] Clocksource tsc unstable = (delta =3D -2999660112689 ns) Sep 11 13:56:50 dnsit22 kernel: [571603.359863] Clocksource tsc unstable (= delta =3D -2999662111513 ns) - I can't reproduce or force the problem - on 2 different HP DL 385 G7, with debian squeeze :=20 xen-hypervisor-4.0-amd64 4.0.1-2 dom0 : linux-image-2.6.32-5-xen-amd64 2.6.32-35 domus : 5 -> 15 debian machines 2 * 12-cores AMD Opteron(tm) Processor 6174 - i have this problem since begin of september, before, the machine were ru= nning since 3 month without problem begin of September, I have done an upgrade (dom0 and domus:) linux-image-2.6.32-5-xen-amd64:amd64 (2.6.32-31, automatic) -> linux-imag= e-2.6.32-5-xen-amd64:amd64 (2.6.32-31, 2.6.32-35) - what is strange : (don't know if there is a link with the problem) /proc/cpuinfo in dom0 gives me :=20 cpu MHz : 3249880.888 --or -- cpu MHz : 2300454.255 .... (different after each reboot) =09 in domu thi value is ok(cpu MHz : 2200.112), the bogomips is also = ok (bogomips : 4400.21) if I start the machine with a non-xen environment, the values are also ok =09 I have now exact the same machine where I can make some tests. Could you give me some tips that I could test or implement ? - hardware problem ? hypervisor problem ? dom0 problem ? - try other hypervisor version ?=20 - try linux-image-3.0.0-1-amd64 3.0.0-3 - try reproducing problem ? (how ?, log it ? ....) all your help is welcomed ! many thanks Philippe > -----Original Message----- > From: xen-devel-bounces@lists.xensource.com [mailto:xen-devel- > bounces@lists.xensource.com] On Behalf Of George Dunlap > Sent: Monday, September 19, 2011 12:40 PM > To: Dan Magenheimer > Cc: Keir Fraser; jeremy@goop.org; xen-devel@lists.xensource.com; Philippe > Simonet; Konrad Wilk > Subject: Re: [Xen-devel] Xen 4 TSC problems >=20 > On Thu, Sep 15, 2011 at 7:38 PM, Dan Magenheimer > <dan.magenheimer@oracle.com> wrote: > >> I haven't been following this conversation, so I don't know if this > >> is relevant, but I've just discovered this morning that the TSC warp > >> check in Xen is done at the wrong time (before any secondary cpus are > >> brought up), and thus always returns warp=3D0. =A0I've submitted a pat= ch > >> to do the check after secondary CPUs are brought up; that should > >> cause Xen to do periodic synchronization of TSCs when there is drift. > > > > Wow, nice catch, George! =A0I wonder if this is the underlying bug for > > many of the mysterious time problems that have been reported for a > > year or two now... at least on certain AMD boxes. > > Any idea when this was introduced? =A0Or has it always been wrong? >=20 > Well the comment in 20823:89907dab1aef seems to indicate that's where the > "assume it's reliable on AMD until proven otherwise" started; that would = be > January 2010. >=20 > I looked as far back as 20705:a74aca4b9386, and there the TSC reliability > checks were again in init_xen_time(). Figuring out where things were bef= ore > then is getting into archeology. :-) >=20 > The comment at the top of init_xen_time() is correct now, but from the ti= me > it was first written through 4.1 is was just plain wrong -- it said > init_xen_time() happened after all cpus were up, which has never been tru= e. >=20 > -George >=20 > _______________________________________________ > Xen-devel mailing list > Xen-devel@lists.xensource.com > http://lists.xensource.com/xen-devel _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel From xen-devel-bounces@lists.xensource.com Fri Sep 30 00:26:11 2011 Return-path: <xen-devel-bounces@lists.xensource.com> Envelope-to: www-data@lists.xensource.com Delivery-date: Fri, 30 Sep 2011 00:26:11 -0700 Received: from localhost ([127.0.0.1] helo=lists.colo.xensource.com) by lists.xensource.com with esmtp (Exim 4.43) id 1R9XU2-0008MU-SH; Fri, 30 Sep 2011 00:26:10 -0700 Received: from mail182.messagelabs.com ([85.158.139.83]) by lists.xensource.com with esmtp (Exim 4.43) id 1R9XT5-00089P-3z for xen-devel@lists.xensource.com; Fri, 30 Sep 2011 00:25:11 -0700 X-Env-Sender: JBeulich@suse.com X-Msg-Ref: server-7.tower-182.messagelabs.com!1317367507!15301972!1 X-Originating-IP: [130.57.49.28] X-StarScan-Version: 6.4.1; banners=-,-,- X-VirusChecked: Checked Received: (qmail 4228 invoked from network); 30 Sep 2011 07:25:08 -0000 Received: from nat28.tlf.novell.com (HELO nat28.tlf.novell.com) (130.57.49.28) by server-7.tower-182.messagelabs.com with DHE-RSA-AES256-SHA encrypted SMTP; 30 Sep 2011 07:25:08 -0000 Received: from EMEA1-MTA by nat28.tlf.novell.com with Novell_GroupWise; Fri, 30 Sep 2011 08:25:07 +0100 Message-Id: <4E858AF30200007800058A64@nat28.tlf.novell.com> X-Mailer: Novell GroupWise Internet Agent 8.0.1 Date: Fri, 30 Sep 2011 08:25:07 +0100 From: "Jan Beulich" <JBeulich@suse.com> To: "Jinsong Liu" <jinsong.liu@intel.com>, "Yunhong Jiang" <yunhong.jiang@intel.com> Subject: RE: [Xen-devel] [PATCH] X86 MCE: Add SRAR handler References: <BC00F5384FCFC9499AF06F92E8B78A9E263B557B77@shsmsx502.ccr.corp.intel.com> <4E84ADF70200007800058882@nat28.tlf.novell.com> <789F9655DD1B8F43B48D77C5D306597312D2366A9B@shsmsx501.ccr.corp.intel.com> In-Reply-To: <789F9655DD1B8F43B48D77C5D306597312D2366A9B@shsmsx501.ccr.corp.intel.com> Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: quoted-printable Content-Disposition: inline Cc: "keir.xen@gmail.com" <keir.xen@gmail.com>, "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com> X-BeenThere: xen-devel@lists.xensource.com X-Mailman-Version: 2.1.5 Precedence: list List-Id: Xen developer discussion <xen-devel.lists.xensource.com> List-Unsubscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe> List-Post: <mailto:xen-devel@lists.xensource.com> List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help> List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=subscribe> Sender: xen-devel-bounces@lists.xensource.com Errors-To: xen-devel-bounces@lists.xensource.com >>> On 30.09.11 at 04:51, "Jiang, Yunhong" <yunhong.jiang@intel.com> = wrote: >=20 >> -----Original Message----- >> From: Jan Beulich [mailto:JBeulich@suse.com]=20 >> Sent: Thursday, September 29, 2011 11:42 PM >> To: Liu, Jinsong >> Cc: Keir Fraser; Jiang, Yunhong; xen-devel@lists.xensource.com=20 >> Subject: Re: [Xen-devel] [PATCH] X86 MCE: Add SRAR handler >>=20 >> >>> On 29.09.11 at 17:20, "Liu, Jinsong" <jinsong.liu@intel.com> wrote: >> > @@ -782,8 +821,12 @@ static void intel_default_mce_uhandler( >> > >> > switch (type) >> > { >> > - /* Panic if no handler for SRAR error */ >> > case intel_mce_ucr_srar: >> > + if ( !guest_mode(regs) ) >> > + *result =3D MCER_RESET; >> > + else >> > + *result =3D MCER_CONTINUE; >> > + break; >> > case intel_mce_fatal: >> > *result =3D MCER_RESET; >> > break; >>=20 >> Using the stack based registers for any decision in an MCE handler >> seems bogus to me - without knowing that the error occurred >> synchronously, the result is meaningless. Unfortunately I wasn't >=20 > I think the usage of stack in MCE handler should be case by case.=20 > For example, it's ok to use it at data load instruction since the EIPV = is > valid for it. According to the table in the manual, this is only the case on the local thread. > For the instruction load, not that sure and I will check it internally. >=20 > But agree that we should not do this depends on the error type (like = SRAR), > but should depends on the specific error code. >=20 >> able to spot - throughout your patch - what SRAR actually stands >> for, and the manual is no help in that respect either. It does state, >> however, that EIPV in three of four cases would be clear for these, >> so using the registers on stack is likely wrong here. >>=20 >> This made me look at the current source, and there I see in >> mce_urgent_action() >>=20 >> if ( !(gstatus & MCG_STATUS_RIPV) && !guest_mode(regs)) >> return -1; >>=20 >> which I think should say ... _EIPV and use || instead. Thoughts? >=20 > I think this code means, if the error happens in hypervisor mode (i.e. > !guest_mode()), and RIPV indicate the RIP in stack can't be restarted, = we > have to panic. Then the guest_mode() check still lacks an extra check of EIPV, like if ( !(gstatus & MCG_STATUS_RIPV) && (!(gstatus & MCG_STATUS_EIPV) || !guest_mode(regs))) return -1; Jan _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel From xen-devel-bounces@lists.xensource.com Fri Sep 30 00:32:49 2011 Return-path: <xen-devel-bounces@lists.xensource.com> Envelope-to: www-data@lists.xensource.com Delivery-date: Fri, 30 Sep 2011 00:32:49 -0700 Received: from localhost ([127.0.0.1] helo=lists.colo.xensource.com) by lists.xensource.com with esmtp (Exim 4.43) id 1R9XaT-0000NJ-7A; Fri, 30 Sep 2011 00:32:49 -0700 Received: from mail174.messagelabs.com ([85.158.138.51]) by lists.xensource.com with esmtp (Exim 4.43) id 1R9XYb-00008z-I9 for xen-devel@lists.xensource.com; Fri, 30 Sep 2011 00:30:54 -0700 X-Env-Sender: Ian.Campbell@eu.citrix.com X-Msg-Ref: server-2.tower-174.messagelabs.com!1317367850!33330092!1 X-Originating-IP: [62.200.22.115] X-StarScan-Version: 6.4.1; banners=-,-,- X-VirusChecked: Checked Received: (qmail 6991 invoked from network); 30 Sep 2011 07:30:50 -0000 Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115) by server-2.tower-174.messagelabs.com with RC4-SHA encrypted SMTP; 30 Sep 2011 07:30:50 -0000 X-IronPort-AV: E=Sophos;i="4.68,465,1312156800"; d="scan'208";a="8142147" Received: from lonpmailmx01.citrite.net ([10.30.203.162]) by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5; 30 Sep 2011 07:30:49 +0000 Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net (10.30.203.162) with Microsoft SMTP Server id 8.3.137.0; Fri, 30 Sep 2011 08:30:50 +0100 Subject: Re: [Xen-devel] Virtual File System in XEN From: Ian Campbell <Ian.Campbell@citrix.com> To: Nupur Ghatnekar <nupurghatnekar@gmail.com> Date: Fri, 30 Sep 2011 08:30:49 +0100 In-Reply-To: <CAO8_4Vq11UWq6ZBpKPJ4pS60t2OcXan8-eKPEqzdD_aGfc=Pww@mail.gmail.com> References: <CAO8_4Vq7Q145GWwW8jG0oOs6TugQvP764njJ3JLtrAZ766tNUw@mail.gmail.com> <1316692074.23371.60.camel@zakaz.uk.xensource.com> <CAO8_4Vq11UWq6ZBpKPJ4pS60t2OcXan8-eKPEqzdD_aGfc=Pww@mail.gmail.com> Organization: Citrix Systems, Inc. Content-Type: text/plain; charset="UTF-8" X-Mailer: Evolution 3.0.3- Content-Transfer-Encoding: 7bit Message-ID: <1317367849.26672.195.camel@zakaz.uk.xensource.com> MIME-Version: 1.0 Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com> X-BeenThere: xen-devel@lists.xensource.com X-Mailman-Version: 2.1.5 Precedence: list List-Id: Xen developer discussion <xen-devel.lists.xensource.com> List-Unsubscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe> List-Post: <mailto:xen-devel@lists.xensource.com> List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help> List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=subscribe> Sender: xen-devel-bounces@lists.xensource.com Errors-To: xen-devel-bounces@lists.xensource.com (please try not to top post) On Fri, 2011-09-30 at 03:57 +0100, Nupur Ghatnekar wrote: > We are planning to port the VirtFS implemented in the KVM land > ( http://www.sciweavers.org/publications/virtfs-virtualization-aware-file-system-pass-through) to XEN land. > > The advantages are > 1) sharing > 2) security > 3)reduced translations Is this the same "virtfs" as is documented here http://wiki.qemu.org/Documentation/9psetup ? It certainly appears to be the same thing (the authors of the paper include a qemu maintainer). Ian. _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel From xen-devel-bounces@lists.xensource.com Fri Sep 30 00:33:42 2011 Return-path: <xen-devel-bounces@lists.xensource.com> Envelope-to: www-data@lists.xensource.com Delivery-date: Fri, 30 Sep 2011 00:33:42 -0700 Received: from localhost ([127.0.0.1] helo=lists.colo.xensource.com) by lists.xensource.com with esmtp (Exim 4.43) id 1R9XbK-0000kK-OG; Fri, 30 Sep 2011 00:33:42 -0700 Received: from mail182.messagelabs.com ([85.158.139.83]) by lists.xensource.com with esmtp (Exim 4.43) id 1R9XZb-0000FL-7X for xen-devel@lists.xensource.com; Fri, 30 Sep 2011 00:32:04 -0700 X-Env-Sender: JBeulich@suse.com X-Msg-Ref: server-3.tower-182.messagelabs.com!1317367911!17518952!1 X-Originating-IP: [130.57.49.28] X-StarScan-Version: 6.4.1; banners=-,-,- X-VirusChecked: Checked Received: (qmail 32602 invoked from network); 30 Sep 2011 07:31:52 -0000 Received: from nat28.tlf.novell.com (HELO nat28.tlf.novell.com) (130.57.49.28) by server-3.tower-182.messagelabs.com with DHE-RSA-AES256-SHA encrypted SMTP; 30 Sep 2011 07:31:52 -0000 Received: from EMEA1-MTA by nat28.tlf.novell.com with Novell_GroupWise; Fri, 30 Sep 2011 08:31:51 +0100 Message-Id: <4E858C850200007800058A6E@nat28.tlf.novell.com> X-Mailer: Novell GroupWise Internet Agent 8.0.1 Date: Fri, 30 Sep 2011 08:31:49 +0100 From: "Jan Beulich" <JBeulich@suse.com> To: "Konrad Rzeszutek Wilk" <konrad.wilk@oracle.com> Subject: Re: [Xen-devel] [PATCH 1/9] xen/pciback: Do not dereference psdev during printk when it is NULL. References: <1317325971-21603-1-git-send-email-konrad.wilk@oracle.com> <1317325971-21603-2-git-send-email-konrad.wilk@oracle.com> In-Reply-To: <1317325971-21603-2-git-send-email-konrad.wilk@oracle.com> Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: quoted-printable Content-Disposition: inline Cc: xen-devel@lists.xensource.com, Dan Carpenter <error27@gmail.com>, linux-kernel@vger.kernel.org X-BeenThere: xen-devel@lists.xensource.com X-Mailman-Version: 2.1.5 Precedence: list List-Id: Xen developer discussion <xen-devel.lists.xensource.com> List-Unsubscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe> List-Post: <mailto:xen-devel@lists.xensource.com> List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help> List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=subscribe> Sender: xen-devel-bounces@lists.xensource.com Errors-To: xen-devel-bounces@lists.xensource.com >>> On 29.09.11 at 21:52, Konrad Rzeszutek Wilk <konrad.wilk@oracle.com> = wrote: > . instead use printk(.. facility. >=20 > Signed-off-by: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com> > --- > drivers/xen/xen-pciback/pci_stub.c | 8 +++++--- > 1 files changed, 5 insertions(+), 3 deletions(-) >=20 > diff --git a/drivers/xen/xen-pciback/pci_stub.c=20 > b/drivers/xen/xen-pciback/pci_stub.c > index aec214a..32d6891 100644 > --- a/drivers/xen/xen-pciback/pci_stub.c > +++ b/drivers/xen/xen-pciback/pci_stub.c > @@ -514,9 +514,11 @@ static void kill_domain_by_device(struct pcistub_dev= ice=20 > *psdev) > int err; > char nodename[PCI_NODENAME_MAX]; > =20 > - if (!psdev) > - dev_err(&psdev->dev->dev, > - "device is NULL when do AER recovery/kill_domain\n"= ); > + if (!psdev) { > + printk(KERN_ERR DRV_NAME > + ":device is NULL when do AER recovery/kill_domain\n= "); > + return; > + } This is bogus - all callers of this function already make sure psdev is non-NULL, so imo the check should be removed or replaced with a BUG_ON(). Jan > snprintf(nodename, PCI_NODENAME_MAX, "/local/domain/0/backend/pci/%= d/0", > psdev->pdev->xdev->otherend_id); > nodename[strlen(nodename)] =3D '\0'; _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel From xen-devel-bounces@lists.xensource.com Fri Sep 30 00:35:08 2011 Return-path: <xen-devel-bounces@lists.xensource.com> Envelope-to: www-data@lists.xensource.com Delivery-date: Fri, 30 Sep 2011 00:35:08 -0700 Received: from localhost ([127.0.0.1] helo=lists.colo.xensource.com) by lists.xensource.com with esmtp (Exim 4.43) id 1R9Xch-00017h-VN; Fri, 30 Sep 2011 00:35:07 -0700 Received: from mail216.messagelabs.com ([85.158.143.99]) by lists.xensource.com with esmtp (Exim 4.43) id 1R9Xc3-0000vO-Ok for xen-devel@lists.xensource.com; Fri, 30 Sep 2011 00:34:28 -0700 X-Env-Sender: Ian.Campbell@eu.citrix.com X-Msg-Ref: server-14.tower-216.messagelabs.com!1317368064!20094649!1 X-Originating-IP: [62.200.22.115] X-StarScan-Version: 6.4.1; banners=-,-,- X-VirusChecked: Checked Received: (qmail 1406 invoked from network); 30 Sep 2011 07:34:24 -0000 Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115) by server-14.tower-216.messagelabs.com with RC4-SHA encrypted SMTP; 30 Sep 2011 07:34:24 -0000 X-IronPort-AV: E=Sophos;i="4.68,465,1312156800"; d="scan'208";a="8142228" Received: from lonpmailmx01.citrite.net ([10.30.203.162]) by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5; 30 Sep 2011 07:34:24 +0000 Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net (10.30.203.162) with Microsoft SMTP Server id 8.3.137.0; Fri, 30 Sep 2011 08:34:24 +0100 Subject: Re: [Xen-devel] ring buffer overflow From: Ian Campbell <Ian.Campbell@citrix.com> To: David Xu <davidxu06@gmail.com> Date: Fri, 30 Sep 2011 08:34:24 +0100 In-Reply-To: <CAGjowiTc0NAJbWR-RxwLTrz+bhbAFfvcPKPAB_F8r1ef6__PbA@mail.gmail.com> References: <CAGjowiTc0NAJbWR-RxwLTrz+bhbAFfvcPKPAB_F8r1ef6__PbA@mail.gmail.com> Organization: Citrix Systems, Inc. Content-Type: text/plain; charset="UTF-8" X-Mailer: Evolution 3.0.3- Content-Transfer-Encoding: 7bit Message-ID: <1317368064.26672.198.camel@zakaz.uk.xensource.com> MIME-Version: 1.0 Cc: xen-devel <xen-devel@lists.xensource.com> X-BeenThere: xen-devel@lists.xensource.com X-Mailman-Version: 2.1.5 Precedence: list List-Id: Xen developer discussion <xen-devel.lists.xensource.com> List-Unsubscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe> List-Post: <mailto:xen-devel@lists.xensource.com> List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help> List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=subscribe> Sender: xen-devel-bounces@lists.xensource.com Errors-To: xen-devel-bounces@lists.xensource.com On Fri, 2011-09-30 at 05:18 +0100, David Xu wrote: > Hi, > > Does anybody know whether the ring buffer between front end and back > end will suffer from overflow? I just wonder if the ring buffer will > be full and drop some packets when the Net I/O load is very heavy. In the case of networking whichever end is putting stuff on the ring checks that there is enough room and will stop the queue when it cannot transmit any more and restart when room becomes available. > BTW, If I want to change the size of i/o ring buffer, how should I do? > I tried to reset the NET_TX_RING_SIZE and NET_RX_RING_SIZE in both > front end and back end, but it seems doesn't work. Thanks. Currently the rings are limited to 1 page so if you want to increase the size you would need to add multipage ring support to the network protocol. There have been patches to do this for the blk protocol but I do not recall any for the net protocol. Ian. _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel From xen-devel-bounces@lists.xensource.com Fri Sep 30 00:36:58 2011 Return-path: <xen-devel-bounces@lists.xensource.com> Envelope-to: www-data@lists.xensource.com Delivery-date: Fri, 30 Sep 2011 00:36:58 -0700 Received: from localhost ([127.0.0.1] helo=lists.colo.xensource.com) by lists.xensource.com with esmtp (Exim 4.43) id 1R9XeU-0001iJ-Ev; Fri, 30 Sep 2011 00:36:58 -0700 Received: from mail182.messagelabs.com ([85.158.139.83]) by lists.xensource.com with esmtp (Exim 4.43) id 1R9Xe1-0001LR-FX for xen-devel@lists.xensource.com; Fri, 30 Sep 2011 00:36:29 -0700 X-Env-Sender: Ian.Campbell@eu.citrix.com X-Msg-Ref: server-15.tower-182.messagelabs.com!1317368186!19294386!1 X-Originating-IP: [62.200.22.115] X-StarScan-Version: 6.4.1; banners=-,-,- X-VirusChecked: Checked Received: (qmail 7587 invoked from network); 30 Sep 2011 07:36:26 -0000 Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115) by server-15.tower-182.messagelabs.com with RC4-SHA encrypted SMTP; 30 Sep 2011 07:36:26 -0000 X-IronPort-AV: E=Sophos;i="4.68,465,1312156800"; d="scan'208";a="8142266" Received: from lonpmailmx01.citrite.net ([10.30.203.162]) by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5; 30 Sep 2011 07:36:05 +0000 Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net (10.30.203.162) with Microsoft SMTP Server id 8.3.137.0; Fri, 30 Sep 2011 08:36:05 +0100 Subject: Re: [Xen-devel] use hypercall in Dom0's kernel From: Ian Campbell <Ian.Campbell@citrix.com> To: David Xu <davidxu06@gmail.com> Date: Fri, 30 Sep 2011 08:36:05 +0100 In-Reply-To: <CAGjowiSLv2Wa9KgfVBmi9yZ5OBPvbX9NYb+3BaDg=iVbty-kuA@mail.gmail.com> References: <CAGjowiSLv2Wa9KgfVBmi9yZ5OBPvbX9NYb+3BaDg=iVbty-kuA@mail.gmail.com> Organization: Citrix Systems, Inc. Content-Type: text/plain; charset="UTF-8" X-Mailer: Evolution 3.0.3- Content-Transfer-Encoding: 7bit Message-ID: <1317368165.26672.200.camel@zakaz.uk.xensource.com> MIME-Version: 1.0 Cc: xen-devel <xen-devel@lists.xensource.com> X-BeenThere: xen-devel@lists.xensource.com X-Mailman-Version: 2.1.5 Precedence: list List-Id: Xen developer discussion <xen-devel.lists.xensource.com> List-Unsubscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe> List-Post: <mailto:xen-devel@lists.xensource.com> List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help> List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=subscribe> Sender: xen-devel-bounces@lists.xensource.com Errors-To: xen-devel-bounces@lists.xensource.com On Thu, 2011-09-29 at 21:16 +0100, David Xu wrote: > Hi, > > Do you know how to call hypercall or call some interface function of > Xen in the ring1 level. In other words, I want to call hypercall or > some interface function of Xen from the Dom0's kernel module. Thanks. The kernel (and it's modules) are full of uses of hypercalls (as they must be) so I'm not sure what you mean here, what problem are you seeing? Ian. _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel From xen-devel-bounces@lists.xensource.com Fri Sep 30 00:37:44 2011 Return-path: <xen-devel-bounces@lists.xensource.com> Envelope-to: www-data@lists.xensource.com Delivery-date: Fri, 30 Sep 2011 00:37:44 -0700 Received: from localhost ([127.0.0.1] helo=lists.colo.xensource.com) by lists.xensource.com with esmtp (Exim 4.43) id 1R9XfE-00025C-HX; Fri, 30 Sep 2011 00:37:44 -0700 Received: from mail21.messagelabs.com ([85.158.143.35]) by lists.xensource.com with esmtp (Exim 4.43) id 1R9Xe9-0001TF-4s for xen-devel@lists.xensource.com; Fri, 30 Sep 2011 00:36:37 -0700 X-Env-Sender: Ian.Campbell@eu.citrix.com X-Msg-Ref: server-12.tower-21.messagelabs.com!1317368176!51916723!1 X-Originating-IP: [66.165.176.63] X-StarScan-Version: 6.4.1; banners=-,-,- X-VirusChecked: Checked Received: (qmail 5555 invoked from network); 30 Sep 2011 07:36:17 -0000 Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63) by server-12.tower-21.messagelabs.com with RC4-SHA encrypted SMTP; 30 Sep 2011 07:36:17 -0000 X-IronPort-AV: E=Sophos;i="4.68,465,1312171200"; d="scan'208";a="165251216" Received: from ftlpmailmx02.citrite.net ([10.13.107.66]) by FTLPIPO02.CITRIX.COM with ESMTP/TLS/RC4-MD5; 30 Sep 2011 03:36:32 -0400 Received: from smtp01.ad.xensource.com (10.219.128.104) by smtprelay.citrix.com (10.13.107.66) with Microsoft SMTP Server id 8.3.137.0; Fri, 30 Sep 2011 03:36:32 -0400 Received: from cosworth.uk.xensource.com (cosworth.uk.xensource.com [10.80.16.52]) by smtp01.ad.xensource.com (8.13.1/8.13.1) with ESMTP id p8U7aUCR027997; Fri, 30 Sep 2011 00:36:30 -0700 Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Mercurial-Node: 4b98868690218126b90620d9b43fdd4140145a43 Message-ID: <4b98868690218126b906.1317368189@cosworth.uk.xensource.com> User-Agent: Mercurial-patchbomb/1.6.4 Date: Fri, 30 Sep 2011 08:36:29 +0100 From: Ian Campbell <ian.campbell@citrix.com> To: xen-devel@lists.xensource.com Cc: Anthony.Perard@citrix.com, Olaf Hering <olaf@aepfle.de> Subject: [Xen-devel] [PATCH] tools/check: check for yajl (needed by libxl) X-BeenThere: xen-devel@lists.xensource.com X-Mailman-Version: 2.1.5 Precedence: list List-Id: Xen developer discussion <xen-devel.lists.xensource.com> List-Unsubscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe> List-Post: <mailto:xen-devel@lists.xensource.com> List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help> List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=subscribe> Sender: xen-devel-bounces@lists.xensource.com Errors-To: xen-devel-bounces@lists.xensource.com # HG changeset patch # User Ian Campbell <ian.campbell@citrix.com> # Date 1317367995 -3600 # Node ID 4b98868690218126b90620d9b43fdd4140145a43 # Parent e50da6b98e3d5933b9c98e8f43096fd3ebbae00d tools/check: check for yajl (needed by libxl) Signed-off-by: Ian Campbell <ian.campbell@citrix.com> --- (note to committer, ensure the new file is executable) diff -r e50da6b98e3d -r 4b9886869021 tools/check/check_yajl_lib --- /dev/null Thu Jan 01 00:00:00 1970 +0000 +++ b/tools/check/check_yajl_lib Fri Sep 30 08:33:15 2011 +0100 @@ -0,0 +1,7 @@ +#!/bin/sh +# CHECK-BUILD CHECK-INSTALL + +. ./funcs.sh + + +has_lib libyajl.so || fail "can't find yajl" _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel From xen-devel-bounces@lists.xensource.com Fri Sep 30 00:42:42 2011 Return-path: <xen-devel-bounces@lists.xensource.com> Envelope-to: www-data@lists.xensource.com Delivery-date: Fri, 30 Sep 2011 00:42:42 -0700 Received: from localhost ([127.0.0.1] helo=lists.colo.xensource.com) by lists.xensource.com with esmtp (Exim 4.43) id 1R9Xk2-0002VW-7S; Fri, 30 Sep 2011 00:42:42 -0700 Received: from mail182.messagelabs.com ([85.158.139.83]) by lists.xensource.com with esmtp (Exim 4.43) id 1R9Xja-0002Jp-Ta for xen-devel@lists.xensource.com; Fri, 30 Sep 2011 00:42:15 -0700 X-Env-Sender: Ian.Campbell@eu.citrix.com X-Msg-Ref: server-6.tower-182.messagelabs.com!1317368531!19121629!1 X-Originating-IP: [62.200.22.115] X-StarScan-Version: 6.4.1; banners=-,-,- X-VirusChecked: Checked Received: (qmail 18957 invoked from network); 30 Sep 2011 07:42:11 -0000 Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115) by server-6.tower-182.messagelabs.com with RC4-SHA encrypted SMTP; 30 Sep 2011 07:42:11 -0000 X-IronPort-AV: E=Sophos;i="4.68,465,1312156800"; d="scan'208";a="8142410" Received: from lonpmailmx01.citrite.net ([10.30.203.162]) by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5; 30 Sep 2011 07:42:11 +0000 Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net (10.30.203.162) with Microsoft SMTP Server id 8.3.137.0; Fri, 30 Sep 2011 08:42:11 +0100 Subject: Re: [Xen-devel] [PATCH 1 of 7] [OCAML] Rename the ocamlfind packages From: Ian Campbell <Ian.Campbell@citrix.com> To: Jon Ludlam <jonathan.ludlam@eu.citrix.com> Date: Fri, 30 Sep 2011 08:42:11 +0100 In-Reply-To: <c5df5f625ee2a0339b2a.1317331043@snoosnoo2.uk.xensource.com> References: <patchbomb.1317331042@snoosnoo2.uk.xensource.com> <c5df5f625ee2a0339b2a.1317331043@snoosnoo2.uk.xensource.com> Organization: Citrix Systems, Inc. Content-Type: text/plain; charset="UTF-8" X-Mailer: Evolution 3.0.3- Content-Transfer-Encoding: 7bit Message-ID: <1317368531.26672.203.camel@zakaz.uk.xensource.com> MIME-Version: 1.0 Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com> X-BeenThere: xen-devel@lists.xensource.com X-Mailman-Version: 2.1.5 Precedence: list List-Id: Xen developer discussion <xen-devel.lists.xensource.com> List-Unsubscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe> List-Post: <mailto:xen-devel@lists.xensource.com> List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help> List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=subscribe> Sender: xen-devel-bounces@lists.xensource.com Errors-To: xen-devel-bounces@lists.xensource.com On Thu, 2011-09-29 at 22:17 +0100, Jon Ludlam wrote: > ocamlfind does not support namespaces, so to avoid > name clashes the ocamlfind package names have been > changed. Note that this does not change the names > of the actual modules themselves. So you do "ocamlfind xenbus" in your code but subsequently "import" xl.* (forgive my lack of actual ocaml syntax)? I'm happy with that if its acceptable practice in ocaml, but given it's "just" a sed invocation away should we bite the bullet and change the module name too? > xb becomes xenbus, xc becomes xenctrl, xl becomes xenlight, > xs becomes xenstore, eventchn becomes xeneventchn. The next patch removes uuid which by my count leaves just the mmap library, any plans for that one? > Signed-off-by: Jon Ludlam <jonathan.ludlam@eu.citrix.com> Acked-by: Ian Campbell <ian.campbell@citrix.com> > diff -r 7998217630e2 -r c5df5f625ee2 tools/ocaml/libs/eventchn/Makefile > --- a/tools/ocaml/libs/eventchn/Makefile > +++ b/tools/ocaml/libs/eventchn/Makefile > @@ -24,12 +24,12 @@ > .PHONY: install > install: $(LIBS) META > mkdir -p $(OCAMLDESTDIR) > - ocamlfind remove -destdir $(OCAMLDESTDIR) eventchn > - ocamlfind install -destdir $(OCAMLDESTDIR) -ldconf ignore eventchn META $(INTF) $(LIBS) *.a *.so *.cmx > + ocamlfind remove -destdir $(OCAMLDESTDIR) xeneventchn > + ocamlfind install -destdir $(OCAMLDESTDIR) -ldconf ignore xeneventchn META $(INTF) $(LIBS) *.a *.so *.cmx > > .PHONY: uninstall > uninstall: > - ocamlfind remove -destdir $(OCAMLDESTDIR) eventchn > + ocamlfind remove -destdir $(OCAMLDESTDIR) xeneventchn > > include $(TOPLEVEL)/Makefile.rules > > diff -r 7998217630e2 -r c5df5f625ee2 tools/ocaml/libs/xb/Makefile > --- a/tools/ocaml/libs/xb/Makefile > +++ b/tools/ocaml/libs/xb/Makefile > @@ -36,11 +36,11 @@ > .PHONY: install > install: $(LIBS) META > mkdir -p $(OCAMLDESTDIR) > - ocamlfind remove -destdir $(OCAMLDESTDIR) xb > - ocamlfind install -destdir $(OCAMLDESTDIR) -ldconf ignore xb META $(INTF) $(LIBS) *.a *.so *.cmx > + ocamlfind remove -destdir $(OCAMLDESTDIR) xenbus > + ocamlfind install -destdir $(OCAMLDESTDIR) -ldconf ignore xenbus META $(INTF) $(LIBS) *.a *.so *.cmx > > .PHONY: uninstall > uninstall: > - ocamlfind remove -destdir $(OCAMLDESTDIR) xb > + ocamlfind remove -destdir $(OCAMLDESTDIR) xenbus > > include $(TOPLEVEL)/Makefile.rules > diff -r 7998217630e2 -r c5df5f625ee2 tools/ocaml/libs/xc/Makefile > --- a/tools/ocaml/libs/xc/Makefile > +++ b/tools/ocaml/libs/xc/Makefile > @@ -23,11 +23,11 @@ > .PHONY: install > install: $(LIBS) META > mkdir -p $(OCAMLDESTDIR) > - ocamlfind remove -destdir $(OCAMLDESTDIR) xc > - ocamlfind install -destdir $(OCAMLDESTDIR) -ldconf ignore xc META $(INTF) $(LIBS) *.a *.so *.cmx > + ocamlfind remove -destdir $(OCAMLDESTDIR) xenctrl > + ocamlfind install -destdir $(OCAMLDESTDIR) -ldconf ignore xenctrl META $(INTF) $(LIBS) *.a *.so *.cmx > > .PHONY: uninstall > uninstall: > - ocamlfind remove -destdir $(OCAMLDESTDIR) xc > + ocamlfind remove -destdir $(OCAMLDESTDIR) xenctrl > > include $(TOPLEVEL)/Makefile.rules > diff -r 7998217630e2 -r c5df5f625ee2 tools/ocaml/libs/xl/Makefile > --- a/tools/ocaml/libs/xl/Makefile > +++ b/tools/ocaml/libs/xl/Makefile > @@ -56,11 +56,11 @@ > .PHONY: install > install: $(LIBS) META > mkdir -p $(OCAMLDESTDIR) > - ocamlfind remove -destdir $(OCAMLDESTDIR) xl > - ocamlfind install -destdir $(OCAMLDESTDIR) -ldconf ignore xl META $(INTF) $(LIBS) *.a *.so *.cmx > + ocamlfind remove -destdir $(OCAMLDESTDIR) xenlight > + ocamlfind install -destdir $(OCAMLDESTDIR) -ldconf ignore xenlight META $(INTF) $(LIBS) *.a *.so *.cmx > > .PHONY: uninstall > uninstall: > - ocamlfind remove -destdir $(OCAMLDESTDIR) xl > + ocamlfind remove -destdir $(OCAMLDESTDIR) xenlight > > include $(TOPLEVEL)/Makefile.rules > diff -r 7998217630e2 -r c5df5f625ee2 tools/ocaml/libs/xs/Makefile > --- a/tools/ocaml/libs/xs/Makefile > +++ b/tools/ocaml/libs/xs/Makefile > @@ -26,12 +26,12 @@ > .PHONY: install > install: $(LIBS) META > mkdir -p $(OCAMLDESTDIR) > - ocamlfind remove -destdir $(OCAMLDESTDIR) xs > - ocamlfind install -destdir $(OCAMLDESTDIR) -ldconf ignore xs META $(INTF) xs.mli xst.mli xsraw.mli $(LIBS) *.a *.cmx > + ocamlfind remove -destdir $(OCAMLDESTDIR) xenstore > + ocamlfind install -destdir $(OCAMLDESTDIR) -ldconf ignore xenstore META $(INTF) xs.mli xst.mli xsraw.mli $(LIBS) *.a *.cmx > > .PHONY: uninstall > uninstall: > - ocamlfind remove -destdir $(OCAMLDESTDIR) xs > + ocamlfind remove -destdir $(OCAMLDESTDIR) xenstore > > include $(TOPLEVEL)/Makefile.rules > > > _______________________________________________ > Xen-devel mailing list > Xen-devel@lists.xensource.com > http://lists.xensource.com/xen-devel _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel From xen-devel-bounces@lists.xensource.com Fri Sep 30 00:45:21 2011 Return-path: <xen-devel-bounces@lists.xensource.com> Envelope-to: www-data@lists.xensource.com Delivery-date: Fri, 30 Sep 2011 00:45:21 -0700 Received: from localhost ([127.0.0.1] helo=lists.colo.xensource.com) by lists.xensource.com with esmtp (Exim 4.43) id 1R9Xmb-0002uH-Im; Fri, 30 Sep 2011 00:45:21 -0700 Received: from mail174.messagelabs.com ([85.158.138.51]) by lists.xensource.com with smtp (Exim 4.43) id 1R9Xm6-0002hj-LS for xen-devel@lists.xensource.com; Fri, 30 Sep 2011 00:44:51 -0700 X-Env-Sender: jinsong.liu@intel.com X-Msg-Ref: server-6.tower-174.messagelabs.com!1317368686!31183854!1 X-Originating-IP: [192.55.52.88] X-StarScan-Version: 6.4.1; banners=-,-,- X-VirusChecked: Checked Received: (qmail 19874 invoked from network); 30 Sep 2011 07:44:47 -0000 Received: from mga01.intel.com (HELO mga01.intel.com) (192.55.52.88) by server-6.tower-174.messagelabs.com with SMTP; 30 Sep 2011 07:44:47 -0000 Received: from fmsmga002.fm.intel.com ([10.253.24.26]) by fmsmga101.fm.intel.com with ESMTP; 30 Sep 2011 00:44:46 -0700 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="4.68,465,1312182000"; d="scan'208";a="72578759" Received: from pgsmsx603.gar.corp.intel.com ([10.221.43.87]) by fmsmga002.fm.intel.com with ESMTP; 30 Sep 2011 00:44:45 -0700 Received: from pgsmsx102.gar.corp.intel.com (10.221.44.80) by pgsmsx603.gar.corp.intel.com (10.221.43.87) with Microsoft SMTP Server (TLS) id 8.2.255.0; Fri, 30 Sep 2011 15:44:24 +0800 Received: from shsmsx602.ccr.corp.intel.com (10.239.4.104) by PGSMSX102.gar.corp.intel.com (10.221.44.80) with Microsoft SMTP Server (TLS) id 14.1.323.3; Fri, 30 Sep 2011 15:44:24 +0800 Received: from shsmsx502.ccr.corp.intel.com ([10.239.4.96]) by SHSMSX602.ccr.corp.intel.com ([10.239.4.104]) with mapi; Fri, 30 Sep 2011 15:44:22 +0800 From: "Liu, Jinsong" <jinsong.liu@intel.com> To: Jan Beulich <JBeulich@suse.com>, "Jiang, Yunhong" <yunhong.jiang@intel.com> Date: Fri, 30 Sep 2011 15:44:22 +0800 Subject: RE: [Xen-devel] [PATCH] X86 MCE: Add SRAR handler Thread-Topic: [Xen-devel] [PATCH] X86 MCE: Add SRAR handler Thread-Index: Acx/QhdPC4ZtXKfdTlGx7gQZNw7G3wAALQVQ Message-ID: <BC00F5384FCFC9499AF06F92E8B78A9E263B557F02@shsmsx502.ccr.corp.intel.com> References: <BC00F5384FCFC9499AF06F92E8B78A9E263B557B77@shsmsx502.ccr.corp.intel.com> <4E84ADF70200007800058882@nat28.tlf.novell.com> <789F9655DD1B8F43B48D77C5D306597312D2366A9B@shsmsx501.ccr.corp.intel.com> <4E858AF30200007800058A64@nat28.tlf.novell.com> In-Reply-To: <4E858AF30200007800058A64@nat28.tlf.novell.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "keir.xen@gmail.com" <keir.xen@gmail.com>, "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com> X-BeenThere: xen-devel@lists.xensource.com X-Mailman-Version: 2.1.5 Precedence: list List-Id: Xen developer discussion <xen-devel.lists.xensource.com> List-Unsubscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe> List-Post: <mailto:xen-devel@lists.xensource.com> List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help> List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=subscribe> Sender: xen-devel-bounces@lists.xensource.com Errors-To: xen-devel-bounces@lists.xensource.com Jan Beulich wrote: >>>> On 30.09.11 at 04:51, "Jiang, Yunhong" <yunhong.jiang@intel.com> >>>> wrote:=20 >=20 >>=20 >>> -----Original Message----- >>> From: Jan Beulich [mailto:JBeulich@suse.com] >>> Sent: Thursday, September 29, 2011 11:42 PM >>> To: Liu, Jinsong >>> Cc: Keir Fraser; Jiang, Yunhong; xen-devel@lists.xensource.com >>> Subject: Re: [Xen-devel] [PATCH] X86 MCE: Add SRAR handler >>>=20 >>>>>> On 29.09.11 at 17:20, "Liu, Jinsong" <jinsong.liu@intel.com> >>>>>> wrote:=20 >>>> @@ -782,8 +821,12 @@ static void intel_default_mce_uhandler( >>>>=20 >>>> switch (type) >>>> { >>>> - /* Panic if no handler for SRAR error */ >>>> case intel_mce_ucr_srar: >>>> + if ( !guest_mode(regs) ) >>>> + *result =3D MCER_RESET; >>>> + else >>>> + *result =3D MCER_CONTINUE; >>>> + break; >>>> case intel_mce_fatal: >>>> *result =3D MCER_RESET; >>>> break; >>>=20 >>> Using the stack based registers for any decision in an MCE handler >>> seems bogus to me - without knowing that the error occurred >>> synchronously, the result is meaningless. Unfortunately I wasn't >>=20 >> I think the usage of stack in MCE handler should be case by case. >> For example, it's ok to use it at data load instruction since the >> EIPV is valid for it. >=20 > According to the table in the manual, this is only the case on the > local thread. >=20 OK, we can remove srar check at mce isr 'uhandler'. so at mce isr, the check if ( !(gstatus & MCG_STATUS_RIPV) && !guest_mode(regs))=20 return -1; is a total insurance for the error which triggered at hypervisor while cann= ot restart from RIP. >> For the instruction load, not that sure and I will check it >> internally.=20 >>=20 >> But agree that we should not do this depends on the error type (like >> SRAR), but should depends on the specific error code. >>=20 >>> able to spot - throughout your patch - what SRAR actually stands >>> for, and the manual is no help in that respect either. It does >>> state, however, that EIPV in three of four cases would be clear for >>> these, so using the registers on stack is likely wrong here. >>>=20 >>> This made me look at the current source, and there I see in >>> mce_urgent_action()=20 >>>=20 >>> if ( !(gstatus & MCG_STATUS_RIPV) && !guest_mode(regs)) =20 >>> return -1;=20 >>>=20 >>> which I think should say ... _EIPV and use || instead. Thoughts? >>=20 >> I think this code means, if the error happens in hypervisor mode >> (i.e. !guest_mode()), and RIPV indicate the RIP in stack can't be >> restarted, we have to panic. >=20 > Then the guest_mode() check still lacks an extra check of EIPV, like >=20 > if ( !(gstatus & MCG_STATUS_RIPV) && > (!(gstatus & MCG_STATUS_EIPV) || !guest_mode(regs))) > return -1; >=20 That would be overkilled. Considering instruction fetch error occur at guest context, hypervisor deli= ver to guest to handle the error is perfer, not panic all system. Thanks, Jinsong= _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel From xen-devel-bounces@lists.xensource.com Fri Sep 30 00:46:54 2011 Return-path: <xen-devel-bounces@lists.xensource.com> Envelope-to: www-data@lists.xensource.com Delivery-date: Fri, 30 Sep 2011 00:46:54 -0700 Received: from localhost ([127.0.0.1] helo=lists.colo.xensource.com) by lists.xensource.com with esmtp (Exim 4.43) id 1R9Xo6-0003NG-5l; Fri, 30 Sep 2011 00:46:54 -0700 Received: from mail182.messagelabs.com ([85.158.139.83]) by lists.xensource.com with esmtp (Exim 4.43) id 1R9XmP-0002nk-Aa for xen-devel@lists.xensource.com; Fri, 30 Sep 2011 00:45:09 -0700 X-Env-Sender: Ian.Campbell@eu.citrix.com X-Msg-Ref: server-3.tower-182.messagelabs.com!1317368706!17521262!1 X-Originating-IP: [62.200.22.115] X-StarScan-Version: 6.4.1; banners=-,-,- X-VirusChecked: Checked Received: (qmail 6320 invoked from network); 30 Sep 2011 07:45:06 -0000 Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115) by server-3.tower-182.messagelabs.com with RC4-SHA encrypted SMTP; 30 Sep 2011 07:45:06 -0000 X-IronPort-AV: E=Sophos;i="4.68,465,1312156800"; d="scan'208";a="8142472" Received: from lonpmailmx01.citrite.net ([10.30.203.162]) by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5; 30 Sep 2011 07:45:05 +0000 Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net (10.30.203.162) with Microsoft SMTP Server id 8.3.137.0; Fri, 30 Sep 2011 08:45:05 +0100 Subject: Re: [Xen-devel] [PATCH 2 of 7] [OCAML] Remove the uuid library From: Ian Campbell <Ian.Campbell@citrix.com> To: Jon Ludlam <jonathan.ludlam@eu.citrix.com> Date: Fri, 30 Sep 2011 08:45:05 +0100 In-Reply-To: <42cdb34ec175602fa2d8.1317331044@snoosnoo2.uk.xensource.com> References: <patchbomb.1317331042@snoosnoo2.uk.xensource.com> <42cdb34ec175602fa2d8.1317331044@snoosnoo2.uk.xensource.com> Organization: Citrix Systems, Inc. Content-Type: text/plain; charset="UTF-8" X-Mailer: Evolution 3.0.3- Content-Transfer-Encoding: 7bit Message-ID: <1317368705.26672.206.camel@zakaz.uk.xensource.com> MIME-Version: 1.0 Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com> X-BeenThere: xen-devel@lists.xensource.com X-Mailman-Version: 2.1.5 Precedence: list List-Id: Xen developer discussion <xen-devel.lists.xensource.com> List-Unsubscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe> List-Post: <mailto:xen-devel@lists.xensource.com> List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help> List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=subscribe> Sender: xen-devel-bounces@lists.xensource.com Errors-To: xen-devel-bounces@lists.xensource.com On Thu, 2011-09-29 at 22:17 +0100, Jon Ludlam wrote: > diff -r c5df5f625ee2 -r 42cdb34ec175 tools/ocaml/libs/xc/META.in > --- a/tools/ocaml/libs/xc/META.in > +++ b/tools/ocaml/libs/xc/META.in > @@ -1,5 +1,5 @@ > version = "@VERSION@" > description = "Xen Control Interface" > -requires = "mmap,uuid" > +requires = "unix,mmap" > archive(byte) = "xc.cma" > archive(native) = "xc.cmxa" Is the addition of unix here really part of removing uuid? I don't see any additional use of unix arising from the change. xc does seem to use unix already so the change is probably correct, just not really part of this change. I'd be happier if it went in separately, but: Acked-by: Ian Campbell <ian.campbell@citrix.com> > diff -r c5df5f625ee2 -r 42cdb34ec175 tools/ocaml/libs/xc/Makefile > --- a/tools/ocaml/libs/xc/Makefile > +++ b/tools/ocaml/libs/xc/Makefile > @@ -3,7 +3,7 @@ > include $(TOPLEVEL)/common.make > > CFLAGS += -I../mmap $(CFLAGS_libxenctrl) $(CFLAGS_libxenguest) > -OCAMLINCLUDE += -I ../mmap -I ../uuid > +OCAMLINCLUDE += -I ../mmap > > OBJS = xc > INTF = xc.cmi > diff -r c5df5f625ee2 -r 42cdb34ec175 tools/ocaml/libs/xc/xc.ml > --- a/tools/ocaml/libs/xc/xc.ml > +++ b/tools/ocaml/libs/xc/xc.ml > @@ -118,14 +118,23 @@ > external _domain_create: handle -> int32 -> domain_create_flag list -> int array -> domid > = "stub_xc_domain_create" > > +let int_array_of_uuid_string s = > + try > + Scanf.sscanf s > + "%02x%02x%02x%02x-%02x%02x-%02x%02x-%02x%02x-%02x%02x%02x%02x%02x%02x" > + (fun a0 a1 a2 a3 a4 a5 a6 a7 a8 a9 a10 a11 a12 a13 a14 a15 -> > + [| a0; a1; a2; a3; a4; a5; a6; a7; > + a8; a9; a10; a11; a12; a13; a14; a15 |]) > + with _ -> invalid_arg ("Xc.int_array_of_uuid_string: " ^ s) > + > let domain_create handle n flags uuid = > - _domain_create handle n flags (Uuid.int_array_of_uuid uuid) > + _domain_create handle n flags (int_array_of_uuid_string uuid) > > external _domain_sethandle: handle -> domid -> int array -> unit > = "stub_xc_domain_sethandle" > > let domain_sethandle handle n uuid = > - _domain_sethandle handle n (Uuid.int_array_of_uuid uuid) > + _domain_sethandle handle n (int_array_of_uuid_string uuid) > > external domain_max_vcpus: handle -> domid -> int -> unit > = "stub_xc_domain_max_vcpus" > diff -r c5df5f625ee2 -r 42cdb34ec175 tools/ocaml/libs/xc/xc.mli > --- a/tools/ocaml/libs/xc/xc.mli > +++ b/tools/ocaml/libs/xc/xc.mli > @@ -74,12 +74,8 @@ > external is_fake : unit -> bool = "stub_xc_interface_is_fake" > external interface_close : handle -> unit = "stub_xc_interface_close" > val with_intf : (handle -> 'a) -> 'a > -external _domain_create : handle -> int32 -> domain_create_flag list -> int array -> domid > - = "stub_xc_domain_create" > -val domain_create : handle -> int32 -> domain_create_flag list -> 'a Uuid.t -> domid > -external _domain_sethandle : handle -> domid -> int array -> unit > - = "stub_xc_domain_sethandle" > -val domain_sethandle : handle -> domid -> 'a Uuid.t -> unit > +val domain_create : handle -> int32 -> domain_create_flag list -> string -> domid > +val domain_sethandle : handle -> domid -> string -> unit > external domain_max_vcpus : handle -> domid -> int -> unit > = "stub_xc_domain_max_vcpus" > external domain_pause : handle -> domid -> unit = "stub_xc_domain_pause" > diff -r c5df5f625ee2 -r 42cdb34ec175 tools/ocaml/xenstored/Makefile > --- a/tools/ocaml/xenstored/Makefile > +++ b/tools/ocaml/xenstored/Makefile > @@ -5,7 +5,6 @@ > OCAMLINCLUDE += \ > -I $(OCAML_TOPLEVEL)/libs/log \ > -I $(OCAML_TOPLEVEL)/libs/xb \ > - -I $(OCAML_TOPLEVEL)/libs/uuid \ > -I $(OCAML_TOPLEVEL)/libs/mmap \ > -I $(OCAML_TOPLEVEL)/libs/xc \ > -I $(OCAML_TOPLEVEL)/libs/eventchn > @@ -34,7 +33,6 @@ > INTF = symbol.cmi trie.cmi > XENSTOREDLIBS = \ > unix.cmxa \ > - $(OCAML_TOPLEVEL)/libs/uuid/uuid.cmxa \ > -ccopt -L -ccopt $(OCAML_TOPLEVEL)/libs/mmap $(OCAML_TOPLEVEL)/libs/mmap/mmap.cmxa \ > -ccopt -L -ccopt $(OCAML_TOPLEVEL)/libs/log $(OCAML_TOPLEVEL)/libs/log/log.cmxa \ > -ccopt -L -ccopt $(OCAML_TOPLEVEL)/libs/eventchn $(OCAML_TOPLEVEL)/libs/eventchn/eventchn.cmxa \ > > _______________________________________________ > Xen-devel mailing list > Xen-devel@lists.xensource.com > http://lists.xensource.com/xen-devel _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel From xen-devel-bounces@lists.xensource.com Fri Sep 30 00:47:56 2011 Return-path: <xen-devel-bounces@lists.xensource.com> Envelope-to: www-data@lists.xensource.com Delivery-date: Fri, 30 Sep 2011 00:47:56 -0700 Received: from localhost ([127.0.0.1] helo=lists.colo.xensource.com) by lists.xensource.com with esmtp (Exim 4.43) id 1R9Xp6-0003k5-8Q; Fri, 30 Sep 2011 00:47:56 -0700 Received: from mail27.messagelabs.com ([193.109.254.147]) by lists.xensource.com with esmtp (Exim 4.43) id 1R9Xml-0002y5-4F for xen-devel@lists.xensource.com; Fri, 30 Sep 2011 00:45:31 -0700 X-Env-Sender: JBeulich@suse.com X-Msg-Ref: server-3.tower-27.messagelabs.com!1317368703!39787195!1 X-Originating-IP: [130.57.49.28] X-StarScan-Version: 6.4.1; banners=-,-,- X-VirusChecked: Checked Received: (qmail 703 invoked from network); 30 Sep 2011 07:45:03 -0000 Received: from nat28.tlf.novell.com (HELO nat28.tlf.novell.com) (130.57.49.28) by server-3.tower-27.messagelabs.com with DHE-RSA-AES256-SHA encrypted SMTP; 30 Sep 2011 07:45:03 -0000 Received: from EMEA1-MTA by nat28.tlf.novell.com with Novell_GroupWise; Fri, 30 Sep 2011 08:45:27 +0100 Message-Id: <4E858FB60200007800058A99@nat28.tlf.novell.com> X-Mailer: Novell GroupWise Internet Agent 8.0.1 Date: Fri, 30 Sep 2011 08:45:26 +0100 From: "Jan Beulich" <JBeulich@suse.com> To: "Konrad Rzeszutek Wilk" <konrad.wilk@oracle.com> Subject: Re: [Xen-devel] [PATCH 2/9] xen/pciback: Return proper error code from sscanf. References: <1317325971-21603-1-git-send-email-konrad.wilk@oracle.com> <1317325971-21603-3-git-send-email-konrad.wilk@oracle.com> In-Reply-To: <1317325971-21603-3-git-send-email-konrad.wilk@oracle.com> Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: quoted-printable Content-Disposition: inline Cc: xen-devel@lists.xensource.com, Dan Carpenter <error27@gmail.com>, linux-kernel@vger.kernel.org X-BeenThere: xen-devel@lists.xensource.com X-Mailman-Version: 2.1.5 Precedence: list List-Id: Xen developer discussion <xen-devel.lists.xensource.com> List-Unsubscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe> List-Post: <mailto:xen-devel@lists.xensource.com> List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help> List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=subscribe> Sender: xen-devel-bounces@lists.xensource.com Errors-To: xen-devel-bounces@lists.xensource.com >>> On 29.09.11 at 21:52, Konrad Rzeszutek Wilk <konrad.wilk@oracle.com> = wrote: > . instead of just hardcoding it to be -EINVAL. >=20 > Signed-off-by: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com> > --- > drivers/xen/xen-pciback/pci_stub.c | 2 +- > 1 files changed, 1 insertions(+), 1 deletions(-) >=20 > diff --git a/drivers/xen/xen-pciback/pci_stub.c=20 > b/drivers/xen/xen-pciback/pci_stub.c > index 32d6891..d985b65 100644 > --- a/drivers/xen/xen-pciback/pci_stub.c > +++ b/drivers/xen/xen-pciback/pci_stub.c > @@ -868,7 +868,7 @@ static inline int str_to_slot(const char *buf, = int=20 > *domain, int *bus, > if (err =3D=3D 4) > return 0; > else if (err < 0) > - return -EINVAL; > + return err; > =20 > /* try again without domain */ > *domain =3D 0; This should then also be done for the final return from the function: return err < 0 ? err : -EINVAL; But: Where did you read that {v,}sscanf() would return -E... values in hypothetical error cases? The C standard says it would return EOF when reaching the end of the input string before doing the first conversion; lib/vsprintf.c doesn't do so, and also doesn't say it might return -E... codes. Bottom line is that I think the code is more correct the way it is without this change. Jan _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel From xen-devel-bounces@lists.xensource.com Fri Sep 30 00:48:47 2011 Return-path: <xen-devel-bounces@lists.xensource.com> Envelope-to: www-data@lists.xensource.com Delivery-date: Fri, 30 Sep 2011 00:48:47 -0700 Received: from localhost ([127.0.0.1] helo=lists.colo.xensource.com) by lists.xensource.com with esmtp (Exim 4.43) id 1R9Xpv-000476-9R; Fri, 30 Sep 2011 00:48:47 -0700 Received: from mail182.messagelabs.com ([85.158.139.83]) by lists.xensource.com with esmtp (Exim 4.43) id 1R9Xnf-0003GF-NK for xen-devel@lists.xensource.com; Fri, 30 Sep 2011 00:46:28 -0700 X-Env-Sender: Ian.Campbell@eu.citrix.com X-Msg-Ref: server-9.tower-182.messagelabs.com!1317368784!18493513!1 X-Originating-IP: [62.200.22.115] X-StarScan-Version: 6.4.1; banners=-,-,- X-VirusChecked: Checked Received: (qmail 15887 invoked from network); 30 Sep 2011 07:46:24 -0000 Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115) by server-9.tower-182.messagelabs.com with RC4-SHA encrypted SMTP; 30 Sep 2011 07:46:24 -0000 X-IronPort-AV: E=Sophos;i="4.68,465,1312156800"; d="scan'208";a="8142497" Received: from lonpmailmx01.citrite.net ([10.30.203.162]) by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5; 30 Sep 2011 07:46:04 +0000 Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net (10.30.203.162) with Microsoft SMTP Server id 8.3.137.0; Fri, 30 Sep 2011 08:46:04 +0100 Subject: Re: [Xen-devel] [PATCH 3 of 7] [OCAML] Remove log library from tools/ocaml/libs From: Ian Campbell <Ian.Campbell@citrix.com> To: Jon Ludlam <jonathan.ludlam@eu.citrix.com> Date: Fri, 30 Sep 2011 08:46:03 +0100 In-Reply-To: <734cb0807357806d33be.1317331045@snoosnoo2.uk.xensource.com> References: <patchbomb.1317331042@snoosnoo2.uk.xensource.com> <734cb0807357806d33be.1317331045@snoosnoo2.uk.xensource.com> Organization: Citrix Systems, Inc. Content-Type: text/plain; charset="UTF-8" X-Mailer: Evolution 3.0.3- Content-Transfer-Encoding: 7bit Message-ID: <1317368763.26672.207.camel@zakaz.uk.xensource.com> MIME-Version: 1.0 Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com> X-BeenThere: xen-devel@lists.xensource.com X-Mailman-Version: 2.1.5 Precedence: list List-Id: Xen developer discussion <xen-devel.lists.xensource.com> List-Unsubscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe> List-Post: <mailto:xen-devel@lists.xensource.com> List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help> List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=subscribe> Sender: xen-devel-bounces@lists.xensource.com Errors-To: xen-devel-bounces@lists.xensource.com On Thu, 2011-09-29 at 22:17 +0100, Jon Ludlam wrote: > The only user was oxenstored, which has had the relevant bits > merged in. > > Signed-off-by: Zheng Li <zheng.li@eu.citrix.com> > Acked-by: Jon Ludlam <jonathan.ludlam@eu.citrix.com> Acked-by: Ian Campbell <ian.campbell@citrix.com> _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel From xen-devel-bounces@lists.xensource.com Fri Sep 30 00:49:52 2011 Return-path: <xen-devel-bounces@lists.xensource.com> Envelope-to: www-data@lists.xensource.com Delivery-date: Fri, 30 Sep 2011 00:49:52 -0700 Received: from localhost ([127.0.0.1] helo=lists.colo.xensource.com) by lists.xensource.com with esmtp (Exim 4.43) id 1R9Xqx-0004UH-Rw; Fri, 30 Sep 2011 00:49:51 -0700 Received: from mail182.messagelabs.com ([85.158.139.83]) by lists.xensource.com with esmtp (Exim 4.43) id 1R9XqZ-0004IJ-A9 for xen-devel@lists.xensource.com; Fri, 30 Sep 2011 00:49:27 -0700 X-Env-Sender: Ian.Campbell@eu.citrix.com X-Msg-Ref: server-5.tower-182.messagelabs.com!1317368964!15345558!1 X-Originating-IP: [62.200.22.115] X-StarScan-Version: 6.4.1; banners=-,-,- X-VirusChecked: Checked Received: (qmail 25228 invoked from network); 30 Sep 2011 07:49:24 -0000 Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115) by server-5.tower-182.messagelabs.com with RC4-SHA encrypted SMTP; 30 Sep 2011 07:49:24 -0000 X-IronPort-AV: E=Sophos;i="4.68,465,1312156800"; d="scan'208";a="8142574" Received: from lonpmailmx01.citrite.net ([10.30.203.162]) by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5; 30 Sep 2011 07:49:24 +0000 Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net (10.30.203.162) with Microsoft SMTP Server id 8.3.137.0; Fri, 30 Sep 2011 08:49:24 +0100 Subject: Re: [Xen-devel] [PATCH 4 of 7] [OCAML] Fix a problem with ocaml xenstored From: Ian Campbell <Ian.Campbell@citrix.com> To: Jon Ludlam <jonathan.ludlam@eu.citrix.com> Date: Fri, 30 Sep 2011 08:49:23 +0100 In-Reply-To: <b6022a18ebb012b8af85.1317331046@snoosnoo2.uk.xensource.com> References: <patchbomb.1317331042@snoosnoo2.uk.xensource.com> <b6022a18ebb012b8af85.1317331046@snoosnoo2.uk.xensource.com> Organization: Citrix Systems, Inc. Content-Type: text/plain; charset="UTF-8" X-Mailer: Evolution 3.0.3- Content-Transfer-Encoding: 7bit Message-ID: <1317368963.26672.210.camel@zakaz.uk.xensource.com> MIME-Version: 1.0 Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com> X-BeenThere: xen-devel@lists.xensource.com X-Mailman-Version: 2.1.5 Precedence: list List-Id: Xen developer discussion <xen-devel.lists.xensource.com> List-Unsubscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe> List-Post: <mailto:xen-devel@lists.xensource.com> List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help> List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=subscribe> Sender: xen-devel-bounces@lists.xensource.com Errors-To: xen-devel-bounces@lists.xensource.com On Thu, 2011-09-29 at 22:17 +0100, Jon Ludlam wrote: > Have xenstored trigger an @introduceDomain event even if the > introduce call tries to introduce an already existing domain. The C daemon doesn't appear to behave this way. It would be nice to explain why this change is necessary. > Signed-off-by: Thomas Gazagnaire <thomas@ocamlpro.com> > Acked-by: Jon Ludlam <jonathan.ludlam@eu.citrix.com> > > diff -r 734cb0807357 -r b6022a18ebb0 tools/ocaml/xenstored/process.ml > --- a/tools/ocaml/xenstored/process.ml > +++ b/tools/ocaml/xenstored/process.ml > @@ -168,9 +168,10 @@ > | _ -> raise Invalid_Cmd_Args; > in > let dom = > - if Domains.exist domains domid then > + if Domains.exist domains domid then begin > + Connections.fire_spec_watches cons "@introduceDomain"; > Domains.find domains domid > - else try > + end else try > let ndom = Xc.with_intf (fun xc -> > Domains.create xc domains domid mfn port) in > Connections.add_domain cons ndom; > > _______________________________________________ > Xen-devel mailing list > Xen-devel@lists.xensource.com > http://lists.xensource.com/xen-devel _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel From xen-devel-bounces@lists.xensource.com Fri Sep 30 00:50:39 2011 Return-path: <xen-devel-bounces@lists.xensource.com> Envelope-to: www-data@lists.xensource.com Delivery-date: Fri, 30 Sep 2011 00:50:39 -0700 Received: from localhost ([127.0.0.1] helo=lists.colo.xensource.com) by lists.xensource.com with esmtp (Exim 4.43) id 1R9Xrj-0004uX-Rk; Fri, 30 Sep 2011 00:50:39 -0700 Received: from mail27.messagelabs.com ([193.109.254.147]) by lists.xensource.com with esmtp (Exim 4.43) id 1R9XrF-0004bW-FK for xen-devel@lists.xensource.com; Fri, 30 Sep 2011 00:50:09 -0700 X-Env-Sender: JBeulich@suse.com X-Msg-Ref: server-6.tower-27.messagelabs.com!1317368985!51096867!1 X-Originating-IP: [130.57.49.28] X-StarScan-Version: 6.4.1; banners=-,-,- X-VirusChecked: Checked Received: (qmail 5551 invoked from network); 30 Sep 2011 07:49:45 -0000 Received: from nat28.tlf.novell.com (HELO nat28.tlf.novell.com) (130.57.49.28) by server-6.tower-27.messagelabs.com with DHE-RSA-AES256-SHA encrypted SMTP; 30 Sep 2011 07:49:45 -0000 Received: from EMEA1-MTA by nat28.tlf.novell.com with Novell_GroupWise; Fri, 30 Sep 2011 08:50:06 +0100 Message-Id: <4E8590CD0200007800058ABA@nat28.tlf.novell.com> X-Mailer: Novell GroupWise Internet Agent 8.0.1 Date: Fri, 30 Sep 2011 08:50:05 +0100 From: "Jan Beulich" <JBeulich@suse.com> To: "Konrad Rzeszutek Wilk" <konrad.wilk@oracle.com>, <linux-kernel@vger.kernel.org> Subject: Re: [Xen-devel] [PATCH 3/9] xen/pciback: Check if the device is found instead of blindly assuming so. References: <1317325971-21603-1-git-send-email-konrad.wilk@oracle.com> <1317325971-21603-4-git-send-email-konrad.wilk@oracle.com> In-Reply-To: <1317325971-21603-4-git-send-email-konrad.wilk@oracle.com> Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: quoted-printable Content-Disposition: inline Cc: xen-devel@lists.xensource.com, Dan Carpenter <error27@gmail.com> X-BeenThere: xen-devel@lists.xensource.com X-Mailman-Version: 2.1.5 Precedence: list List-Id: Xen developer discussion <xen-devel.lists.xensource.com> List-Unsubscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe> List-Post: <mailto:xen-devel@lists.xensource.com> List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help> List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=subscribe> Sender: xen-devel-bounces@lists.xensource.com Errors-To: xen-devel-bounces@lists.xensource.com >>> On 29.09.11 at 21:52, Konrad Rzeszutek Wilk <konrad.wilk@oracle.com> = wrote: > Just in case it is not found, don't try to dereference it. >=20 > Signed-off-by: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com> > --- > drivers/xen/xen-pciback/pci_stub.c | 2 ++ > 1 files changed, 2 insertions(+), 0 deletions(-) >=20 > diff --git a/drivers/xen/xen-pciback/pci_stub.c=20 > b/drivers/xen/xen-pciback/pci_stub.c > index d985b65..55086e9 100644 > --- a/drivers/xen/xen-pciback/pci_stub.c > +++ b/drivers/xen/xen-pciback/pci_stub.c > @@ -222,6 +222,8 @@ void pcistub_put_pci_dev(struct pci_dev *dev) > } > =20 > spin_unlock_irqrestore(&pcistub_devices_lock, flags); > + if (!found_psdev) > + return; If this happens, it's a bug (backend controller found the device, but the generic backend code didn't), so I would say minimally a WARN_ON() should be issued here. Jan > =20 > /*hold this lock for avoiding breaking link between > * pcistub and xen_pcibk when AER is in processing _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel From xen-devel-bounces@lists.xensource.com Fri Sep 30 00:51:56 2011 Return-path: <xen-devel-bounces@lists.xensource.com> Envelope-to: www-data@lists.xensource.com Delivery-date: Fri, 30 Sep 2011 00:51:56 -0700 Received: from localhost ([127.0.0.1] helo=lists.colo.xensource.com) by lists.xensource.com with esmtp (Exim 4.43) id 1R9Xsy-0005HK-GZ; Fri, 30 Sep 2011 00:51:56 -0700 Received: from mail21.messagelabs.com ([85.158.143.35]) by lists.xensource.com with esmtp (Exim 4.43) id 1R9XsX-00055L-Ea for xen-devel@lists.xensource.com; Fri, 30 Sep 2011 00:51:29 -0700 X-Env-Sender: Ian.Campbell@eu.citrix.com X-Msg-Ref: server-9.tower-21.messagelabs.com!1317369040!50393743!1 X-Originating-IP: [62.200.22.115] X-StarScan-Version: 6.4.1; banners=-,-,- X-VirusChecked: Checked Received: (qmail 20657 invoked from network); 30 Sep 2011 07:50:40 -0000 Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115) by server-9.tower-21.messagelabs.com with RC4-SHA encrypted SMTP; 30 Sep 2011 07:50:40 -0000 X-IronPort-AV: E=Sophos;i="4.68,465,1312156800"; d="scan'208";a="8142634" Received: from lonpmailmx01.citrite.net ([10.30.203.162]) by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5; 30 Sep 2011 07:51:26 +0000 Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net (10.30.203.162) with Microsoft SMTP Server id 8.3.137.0; Fri, 30 Sep 2011 08:51:26 +0100 Subject: Re: [Xen-devel] [PATCH 5 of 7] [OCAML] Minor makefile cleanup From: Ian Campbell <Ian.Campbell@citrix.com> To: Jon Ludlam <jonathan.ludlam@eu.citrix.com> Date: Fri, 30 Sep 2011 08:51:25 +0100 In-Reply-To: <48d4f312d0693cf8a52e.1317331047@snoosnoo2.uk.xensource.com> References: <patchbomb.1317331042@snoosnoo2.uk.xensource.com> <48d4f312d0693cf8a52e.1317331047@snoosnoo2.uk.xensource.com> Organization: Citrix Systems, Inc. Content-Type: text/plain; charset="UTF-8" X-Mailer: Evolution 3.0.3- Content-Transfer-Encoding: 7bit Message-ID: <1317369085.26672.212.camel@zakaz.uk.xensource.com> MIME-Version: 1.0 Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com> X-BeenThere: xen-devel@lists.xensource.com X-Mailman-Version: 2.1.5 Precedence: list List-Id: Xen developer discussion <xen-devel.lists.xensource.com> List-Unsubscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe> List-Post: <mailto:xen-devel@lists.xensource.com> List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help> List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=subscribe> Sender: xen-devel-bounces@lists.xensource.com Errors-To: xen-devel-bounces@lists.xensource.com What does the cleanup actually do? On Thu, 2011-09-29 at 22:17 +0100, Jon Ludlam wrote: > diff -r b6022a18ebb0 -r 48d4f312d069 tools/ocaml/libs/eventchn/Makefile > --- a/tools/ocaml/libs/eventchn/Makefile > +++ b/tools/ocaml/libs/eventchn/Makefile > @@ -8,7 +8,7 @@ > INTF = $(foreach obj, $(OBJS),$(obj).cmi) > LIBS = eventchn.cma eventchn.cmxa > > -LIBS_evtchn = $(LDLIBS_libxenctrl) > +LIBS_eventchn = -L$(XEN_ROOT)/tools/libxc -lxenctrl This should continue using LDLIBS_libxenctrl unless there is a good reason not too. > > all: $(INTF) $(LIBS) $(PROGRAMS) > > > _______________________________________________ > Xen-devel mailing list > Xen-devel@lists.xensource.com > http://lists.xensource.com/xen-devel _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel From xen-devel-bounces@lists.xensource.com Fri Sep 30 00:52:41 2011 Return-path: <xen-devel-bounces@lists.xensource.com> Envelope-to: www-data@lists.xensource.com Delivery-date: Fri, 30 Sep 2011 00:52:41 -0700 Received: from localhost ([127.0.0.1] helo=lists.colo.xensource.com) by lists.xensource.com with esmtp (Exim 4.43) id 1R9Xth-0005eR-Eh; Fri, 30 Sep 2011 00:52:41 -0700 Received: from mail174.messagelabs.com ([85.158.138.51]) by lists.xensource.com with esmtp (Exim 4.43) id 1R9Xsn-0005AK-28 for xen-devel@lists.xensource.com; Fri, 30 Sep 2011 00:51:45 -0700 X-Env-Sender: vase@selfip.ru X-Msg-Ref: server-4.tower-174.messagelabs.com!1317369101!33345384!1 X-Originating-IP: [74.125.82.43] X-StarScan-Version: 6.4.1; banners=-,-,- X-VirusChecked: Checked Received: (qmail 20199 invoked from network); 30 Sep 2011 07:51:42 -0000 Received: from mail-ww0-f43.google.com (HELO mail-ww0-f43.google.com) (74.125.82.43) by server-4.tower-174.messagelabs.com with RC4-SHA encrypted SMTP; 30 Sep 2011 07:51:42 -0000 Received: by wwf27 with SMTP id 27so1832225wwf.24 for <xen-devel@lists.xensource.com>; Fri, 30 Sep 2011 00:51:41 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=selfip.ru; s=google; h=mime-version:sender:x-originating-ip:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type; bh=mCQlxy8urSEEMKGtHHTtWzWDk8GBkCJzUcBQHkM5chA=; b=Q38l0nbne5mwnEwf1GExo8i3vPN+MO5lqRxGRUxejo4jR2UOa0JQoX1nq0l1J6V5ff xNH/h/qxoXjzqdFpsbzs1BeiZmp0Np9eqDDj1Hm9Y5sd84sw75o756mC7V1RaH0h7ckU tboRZFsSZRRqv/90aOFWHbXCDCUBnShTEpgN8= MIME-Version: 1.0 Received: by 10.216.230.160 with SMTP id j32mr7742925weq.31.1317369101586; Fri, 30 Sep 2011 00:51:41 -0700 (PDT) Received: by 10.216.4.69 with HTTP; Fri, 30 Sep 2011 00:51:41 -0700 (PDT) X-Originating-IP: [85.143.161.18] In-Reply-To: <1316729665-15004-1-git-send-email-dgdegra@tycho.nsa.gov> References: <1313764724-12683-1-git-send-email-dgdegra@tycho.nsa.gov> <1316729665-15004-1-git-send-email-dgdegra@tycho.nsa.gov> Date: Fri, 30 Sep 2011 11:51:41 +0400 X-Google-Sender-Auth: EY78vnn6rK6oxrygFpwd1bMJmOI Message-ID: <CACaajQsMnXb9u1pTtB9jT5b6n2p6gFq_A8aQajAO4kmcpSwKdw@mail.gmail.com> Subject: Re: [Xen-devel] [PATCH v6 0/3] libxenvchan: interdomain communications library From: Vasiliy Tolstov <v.tolstov@selfip.ru> To: Daniel De Graaf <dgdegra@tycho.nsa.gov> Cc: Ian.Campbell@eu.citrix.com, xen-devel@lists.xensource.com, Ian.Jackson@eu.citrix.com, konrad.wilk@oracle.com, Stefano.Stabellini@eu.citrix.com X-BeenThere: xen-devel@lists.xensource.com X-Mailman-Version: 2.1.5 Precedence: list List-Id: Xen developer discussion <xen-devel.lists.xensource.com> List-Unsubscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe> List-Post: <mailto:xen-devel@lists.xensource.com> List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help> List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=subscribe> Content-Type: multipart/mixed; boundary="===============1441608011==" Sender: xen-devel-bounces@lists.xensource.com Errors-To: xen-devel-bounces@lists.xensource.com --===============1441608011== Content-Type: multipart/alternative; boundary=0016e64713e45691a004ae23e5a3 --0016e64713e45691a004ae23e5a3 Content-Type: text/plain; charset=UTF-8 2011/9/23 Daniel De Graaf <dgdegra@tycho.nsa.gov> > Changes since v5: > - Unify gntdev osdep interface > - Eliminate notify_result and revert mapping if notify ioctl fails > - Rename functions and structures to libxenvchan > - Use application-specified xenstore path for ring/event data > - Enforce maximum ring size of 2^20 bytes on client > - Change to LGPL 2.1 > > [PATCH 1/3] libxc: add xc_gnttab_map_grant_ref_notify > [PATCH 2/3] libxc: add xc_gntshr_* functions > [PATCH 3/3] libvchan: interdomain communications library > > > Hello. Sorry for bumping.. What version of xen kernel i need to use this library? Now i have 2.6.32.26 in many domUs. And what i need in dom0 for that, if i want to communicate via libxenvchan from domU to dom0? -- Vasiliy Tolstov, Clodo.ru e-mail: v.tolstov@selfip.ru jabber: vase@selfip.ru --0016e64713e45691a004ae23e5a3 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable <br><br><div class=3D"gmail_quote">2011/9/23 Daniel De Graaf <span dir=3D"l= tr"><<a href=3D"mailto:dgdegra@tycho.nsa.gov">dgdegra@tycho.nsa.gov</a>&= gt;</span><br><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;= border-left:1px #ccc solid;padding-left:1ex;"> Changes since v5:<br> =C2=A0- Unify gntdev osdep interface<br> =C2=A0- Eliminate notify_result and revert mapping if notify ioctl fails<br= > =C2=A0- Rename functions and structures to libxenvchan<br> =C2=A0- Use application-specified xenstore path for ring/event data<br> =C2=A0- Enforce maximum ring size of 2^20 bytes on client<br> =C2=A0- Change to LGPL 2.1<br> <br> [PATCH 1/3] libxc: add xc_gnttab_map_grant_ref_notify<br> [PATCH 2/3] libxc: add xc_gntshr_* functions<br> [PATCH 3/3] libvchan: interdomain communications library<br> <br><br></blockquote><div><br></div><div>Hello. Sorry for bumping..</div><d= iv>What version of xen kernel i need to use this library? Now i have 2.6.32= .26 in many domUs.</div><div>And what i need in dom0 for that, if i want to= communicate via libxenvchan from domU to dom0?</div> </div><br clear=3D"all"><div><br></div>-- <br><span style=3D"border-collaps= e:collapse;color:rgb(136, 136, 136);font-family:arial, sans-serif;font-size= :13px"><div><div>Vasiliy Tolstov,</div><div>Clodo.ru</div><div>e-mail: <a h= ref=3D"mailto:v.tolstov@selfip.ru" target=3D"_blank">v.tolstov@selfip.ru</a= ></div> <div>jabber: <a href=3D"mailto:vase@selfip.ru" target=3D"_blank">vase@selfi= p.ru</a></div></div></span><br> --0016e64713e45691a004ae23e5a3-- --===============1441608011== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel --===============1441608011==-- From xen-devel-bounces@lists.xensource.com Fri Sep 30 00:54:09 2011 Return-path: <xen-devel-bounces@lists.xensource.com> Envelope-to: www-data@lists.xensource.com Delivery-date: Fri, 30 Sep 2011 00:54:09 -0700 Received: from localhost ([127.0.0.1] helo=lists.colo.xensource.com) by lists.xensource.com with esmtp (Exim 4.43) id 1R9Xv7-00061n-Oc; Fri, 30 Sep 2011 00:54:09 -0700 Received: from mail27.messagelabs.com ([193.109.254.147]) by lists.xensource.com with esmtp (Exim 4.43) id 1R9Xuh-0005pK-4z for xen-devel@lists.xensource.com; Fri, 30 Sep 2011 00:53:43 -0700 X-Env-Sender: Ian.Campbell@eu.citrix.com X-Msg-Ref: server-12.tower-27.messagelabs.com!1317369203!44546372!1 X-Originating-IP: [62.200.22.115] X-StarScan-Version: 6.4.1; banners=-,-,- X-VirusChecked: Checked Received: (qmail 28513 invoked from network); 30 Sep 2011 07:53:23 -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; 30 Sep 2011 07:53:23 -0000 X-IronPort-AV: E=Sophos;i="4.68,465,1312156800"; d="scan'208";a="8142697" Received: from lonpmailmx01.citrite.net ([10.30.203.162]) by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5; 30 Sep 2011 07:53:39 +0000 Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net (10.30.203.162) with Microsoft SMTP Server id 8.3.137.0; Fri, 30 Sep 2011 08:53:40 +0100 Subject: Re: [Xen-devel] [PATCH 6 of 7] [OCAML] Fix 2 bit-twiddling bugs and an off-by-one From: Ian Campbell <Ian.Campbell@citrix.com> To: Jon Ludlam <jonathan.ludlam@eu.citrix.com> Date: Fri, 30 Sep 2011 08:53:39 +0100 In-Reply-To: <05ac32c3956c0e1584c2.1317331048@snoosnoo2.uk.xensource.com> References: <patchbomb.1317331042@snoosnoo2.uk.xensource.com> <05ac32c3956c0e1584c2.1317331048@snoosnoo2.uk.xensource.com> Organization: Citrix Systems, Inc. Content-Type: text/plain; charset="UTF-8" X-Mailer: Evolution 3.0.3- Content-Transfer-Encoding: 7bit Message-ID: <1317369219.26672.213.camel@zakaz.uk.xensource.com> MIME-Version: 1.0 Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com> X-BeenThere: xen-devel@lists.xensource.com X-Mailman-Version: 2.1.5 Precedence: list List-Id: Xen developer discussion <xen-devel.lists.xensource.com> List-Unsubscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe> List-Post: <mailto:xen-devel@lists.xensource.com> List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help> List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=subscribe> Sender: xen-devel-bounces@lists.xensource.com Errors-To: xen-devel-bounces@lists.xensource.com On Thu, 2011-09-29 at 22:17 +0100, Jon Ludlam wrote: > The bit bugs are in ocaml vcpu affinity calls, and the off-by-one > error is in the ocaml console ring code > > Signed-off-by: Zheng Li <zheng.li@eu.citrix.com> > Acked-by: Jon Ludlam <jonathan.ludlam@eu.citrix.com> Acked-by: Ian Campbell <ian.campbell@citrix.com> _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel From xen-devel-bounces@lists.xensource.com Fri Sep 30 00:55:00 2011 Return-path: <xen-devel-bounces@lists.xensource.com> Envelope-to: www-data@lists.xensource.com Delivery-date: Fri, 30 Sep 2011 00:55:00 -0700 Received: from localhost ([127.0.0.1] helo=lists.colo.xensource.com) by lists.xensource.com with esmtp (Exim 4.43) id 1R9Xvw-0006Nq-BH; Fri, 30 Sep 2011 00:55:00 -0700 Received: from mail174.messagelabs.com ([85.158.138.51]) by lists.xensource.com with esmtp (Exim 4.43) id 1R9XvX-0006Bv-Mr for xen-devel@lists.xensource.com; Fri, 30 Sep 2011 00:54:36 -0700 X-Env-Sender: Ian.Campbell@eu.citrix.com X-Msg-Ref: server-7.tower-174.messagelabs.com!1317369272!33305362!1 X-Originating-IP: [62.200.22.115] X-StarScan-Version: 6.4.1; banners=-,-,- X-VirusChecked: Checked Received: (qmail 5321 invoked from network); 30 Sep 2011 07:54:32 -0000 Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115) by server-7.tower-174.messagelabs.com with RC4-SHA encrypted SMTP; 30 Sep 2011 07:54:32 -0000 X-IronPort-AV: E=Sophos;i="4.68,465,1312156800"; d="scan'208";a="8142730" Received: from lonpmailmx01.citrite.net ([10.30.203.162]) by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5; 30 Sep 2011 07:54:32 +0000 Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net (10.30.203.162) with Microsoft SMTP Server id 8.3.137.0; Fri, 30 Sep 2011 08:54:32 +0100 Subject: Re: [Xen-devel] [PATCH 7 of 7] [OCAML] Small improvement to the ocaml xenctrl library From: Ian Campbell <Ian.Campbell@citrix.com> To: Jon Ludlam <jonathan.ludlam@eu.citrix.com> Date: Fri, 30 Sep 2011 08:54:32 +0100 In-Reply-To: <abf14d22106aad906f31.1317331049@snoosnoo2.uk.xensource.com> References: <patchbomb.1317331042@snoosnoo2.uk.xensource.com> <abf14d22106aad906f31.1317331049@snoosnoo2.uk.xensource.com> Organization: Citrix Systems, Inc. Content-Type: text/plain; charset="UTF-8" X-Mailer: Evolution 3.0.3- Content-Transfer-Encoding: 7bit Message-ID: <1317369272.26672.214.camel@zakaz.uk.xensource.com> MIME-Version: 1.0 Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com> X-BeenThere: xen-devel@lists.xensource.com X-Mailman-Version: 2.1.5 Precedence: list List-Id: Xen developer discussion <xen-devel.lists.xensource.com> List-Unsubscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe> List-Post: <mailto:xen-devel@lists.xensource.com> List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help> List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=subscribe> Sender: xen-devel-bounces@lists.xensource.com Errors-To: xen-devel-bounces@lists.xensource.com On Thu, 2011-09-29 at 22:17 +0100, Jon Ludlam wrote: > Add a new field 'max_nr_cpus' to the physinfo type in the ocaml xc bindings > > Signed-off-by: Zheng Li <zheng.li@eu.citrix.com> Acked-by: Ian Campbell <ian.campbell@citrix.com> > > diff -r 05ac32c3956c -r abf14d22106a tools/ocaml/libs/xc/xc.ml > --- a/tools/ocaml/libs/xc/xc.ml > +++ b/tools/ocaml/libs/xc/xc.ml > @@ -70,6 +70,7 @@ > scrub_pages : nativeint; > (* XXX hw_cap *) > capabilities : physinfo_cap_flag list; > + max_nr_cpus : int; > } > > type version = > diff -r 05ac32c3956c -r abf14d22106a tools/ocaml/libs/xc/xc.mli > --- a/tools/ocaml/libs/xc/xc.mli > +++ b/tools/ocaml/libs/xc/xc.mli > @@ -52,6 +52,7 @@ > free_pages : nativeint; > scrub_pages : nativeint; > capabilities : physinfo_cap_flag list; > + max_nr_cpus : int; (** compile-time max possible number of nr_cpus *) > } > type version = { major : int; minor : int; extra : string; } > type compile_info = { > diff -r 05ac32c3956c -r abf14d22106a tools/ocaml/libs/xc/xc_stubs.c > --- a/tools/ocaml/libs/xc/xc_stubs.c > +++ b/tools/ocaml/libs/xc/xc_stubs.c > @@ -534,6 +534,7 @@ > > if (retval) > failwith_xc(_H(xch)); > + > ring[size] = '\0'; > CAMLreturn(caml_copy_string(ring)); > } > @@ -573,7 +574,7 @@ > } > } > > - physinfo = caml_alloc_tuple(9); > + physinfo = caml_alloc_tuple(10); > Store_field(physinfo, 0, Val_int(c_physinfo.threads_per_core)); > Store_field(physinfo, 1, Val_int(c_physinfo.cores_per_socket)); > Store_field(physinfo, 2, Val_int(c_physinfo.nr_cpus)); > @@ -583,6 +584,7 @@ > Store_field(physinfo, 6, caml_copy_nativeint(c_physinfo.free_pages)); > Store_field(physinfo, 7, caml_copy_nativeint(c_physinfo.scrub_pages)); > Store_field(physinfo, 8, cap_list); > + Store_field(physinfo, 9, Val_int(c_physinfo.max_cpu_id + 1)); > > CAMLreturn(physinfo); > } > > _______________________________________________ > Xen-devel mailing list > Xen-devel@lists.xensource.com > http://lists.xensource.com/xen-devel _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel From xen-devel-bounces@lists.xensource.com Fri Sep 30 00:56:21 2011 Return-path: <xen-devel-bounces@lists.xensource.com> Envelope-to: www-data@lists.xensource.com Delivery-date: Fri, 30 Sep 2011 00:56:21 -0700 Received: from localhost ([127.0.0.1] helo=lists.colo.xensource.com) by lists.xensource.com with esmtp (Exim 4.43) id 1R9XxE-0006qd-Vw; Fri, 30 Sep 2011 00:56:21 -0700 Received: from mail216.messagelabs.com ([85.158.143.99]) by lists.xensource.com with esmtp (Exim 4.43) id 1R9Xwr-0006e8-10 for xen-devel@lists.xensource.com; Fri, 30 Sep 2011 00:55:57 -0700 X-Env-Sender: Ian.Campbell@eu.citrix.com X-Msg-Ref: server-9.tower-216.messagelabs.com!1317369354!20110955!1 X-Originating-IP: [62.200.22.115] X-StarScan-Version: 6.4.1; banners=-,-,- X-VirusChecked: Checked Received: (qmail 6996 invoked from network); 30 Sep 2011 07:55:54 -0000 Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115) by server-9.tower-216.messagelabs.com with RC4-SHA encrypted SMTP; 30 Sep 2011 07:55:54 -0000 X-IronPort-AV: E=Sophos;i="4.68,465,1312156800"; d="scan'208";a="8142765" Received: from lonpmailmx01.citrite.net ([10.30.203.162]) by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5; 30 Sep 2011 07:55:53 +0000 Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net (10.30.203.162) with Microsoft SMTP Server id 8.3.137.0; Fri, 30 Sep 2011 08:55:54 +0100 Subject: Re: [Xen-devel] [PATCH 4/9] xen/events: BUG() when we can't allocate our event->irq array. From: Ian Campbell <Ian.Campbell@citrix.com> To: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com> Date: Fri, 30 Sep 2011 08:55:53 +0100 In-Reply-To: <1317325971-21603-5-git-send-email-konrad.wilk@oracle.com> References: <1317325971-21603-1-git-send-email-konrad.wilk@oracle.com> <1317325971-21603-5-git-send-email-konrad.wilk@oracle.com> Organization: Citrix Systems, Inc. Content-Type: text/plain; charset="UTF-8" X-Mailer: Evolution 3.0.3- Content-Transfer-Encoding: 7bit Message-ID: <1317369353.26672.215.camel@zakaz.uk.xensource.com> MIME-Version: 1.0 Cc: Dan, "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>, "linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>, Carpenter <error27@gmail.com> X-BeenThere: xen-devel@lists.xensource.com X-Mailman-Version: 2.1.5 Precedence: list List-Id: Xen developer discussion <xen-devel.lists.xensource.com> List-Unsubscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe> List-Post: <mailto:xen-devel@lists.xensource.com> List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help> List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=subscribe> Sender: xen-devel-bounces@lists.xensource.com Errors-To: xen-devel-bounces@lists.xensource.com On Thu, 2011-09-29 at 20:52 +0100, Konrad Rzeszutek Wilk wrote: > In case we can't allocate we are doomed. We should BUG_ON > instead of trying to dereference it later on. > > Signed-off-by: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com> > --- > drivers/xen/events.c | 2 ++ > 1 files changed, 2 insertions(+), 0 deletions(-) > > diff --git a/drivers/xen/events.c b/drivers/xen/events.c > index 7523719..5db04bf 100644 > --- a/drivers/xen/events.c > +++ b/drivers/xen/events.c > @@ -1670,6 +1670,8 @@ void __init xen_init_IRQ(void) > > evtchn_to_irq = kcalloc(NR_EVENT_CHANNELS, sizeof(*evtchn_to_irq), > GFP_KERNEL); > + if (!evtchn_to_irq) > + BUG(); AKA BUG_ON(!evtchn_to_irq); but Acked-by: Ian Campbell <ian.campbell@citrix.com> _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel From xen-devel-bounces@lists.xensource.com Fri Sep 30 01:00:21 2011 Return-path: <xen-devel-bounces@lists.xensource.com> Envelope-to: www-data@lists.xensource.com Delivery-date: Fri, 30 Sep 2011 01:00:21 -0700 Received: from localhost ([127.0.0.1] helo=lists.colo.xensource.com) by lists.xensource.com with esmtp (Exim 4.43) id 1R9Y16-0007Iw-U6; Fri, 30 Sep 2011 01:00:21 -0700 Received: from mail27.messagelabs.com ([193.109.254.147]) by lists.xensource.com with esmtp (Exim 4.43) id 1R9Xyt-00074o-8i for xen-devel@lists.xensource.com; Fri, 30 Sep 2011 00:58:03 -0700 X-Env-Sender: JBeulich@suse.com X-Msg-Ref: server-10.tower-27.messagelabs.com!1317369458!37832933!1 X-Originating-IP: [130.57.49.28] X-StarScan-Version: 6.4.1; banners=-,-,- X-VirusChecked: Checked Received: (qmail 17863 invoked from network); 30 Sep 2011 07:57:38 -0000 Received: from nat28.tlf.novell.com (HELO nat28.tlf.novell.com) (130.57.49.28) by server-10.tower-27.messagelabs.com with DHE-RSA-AES256-SHA encrypted SMTP; 30 Sep 2011 07:57:38 -0000 Received: from EMEA1-MTA by nat28.tlf.novell.com with Novell_GroupWise; Fri, 30 Sep 2011 08:57:59 +0100 Message-Id: <4E8592A60200007800058AD4@nat28.tlf.novell.com> X-Mailer: Novell GroupWise Internet Agent 8.0.1 Date: Fri, 30 Sep 2011 08:57:58 +0100 From: "Jan Beulich" <JBeulich@suse.com> To: "Jinsong Liu" <jinsong.liu@intel.com>, "Yunhong Jiang" <yunhong.jiang@intel.com> Subject: RE: [Xen-devel] [PATCH] X86 MCE: Add SRAR handler References: <BC00F5384FCFC9499AF06F92E8B78A9E263B557B77@shsmsx502.ccr.corp.intel.com> <4E84ADF70200007800058882@nat28.tlf.novell.com> <789F9655DD1B8F43B48D77C5D306597312D2366A9B@shsmsx501.ccr.corp.intel.com> <4E858AF30200007800058A64@nat28.tlf.novell.com> <BC00F5384FCFC9499AF06F92E8B78A9E263B557F02@shsmsx502.ccr.corp.intel.com> In-Reply-To: <BC00F5384FCFC9499AF06F92E8B78A9E263B557F02@shsmsx502.ccr.corp.intel.com> Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: quoted-printable Content-Disposition: inline Cc: "keir.xen@gmail.com" <keir.xen@gmail.com>, "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com> X-BeenThere: xen-devel@lists.xensource.com X-Mailman-Version: 2.1.5 Precedence: list List-Id: Xen developer discussion <xen-devel.lists.xensource.com> List-Unsubscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe> List-Post: <mailto:xen-devel@lists.xensource.com> List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help> List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=subscribe> Sender: xen-devel-bounces@lists.xensource.com Errors-To: xen-devel-bounces@lists.xensource.com >>> On 30.09.11 at 09:44, "Liu, Jinsong" <jinsong.liu@intel.com> wrote: > Jan Beulich wrote: >>>>> On 30.09.11 at 04:51, "Jiang, Yunhong" <yunhong.jiang@intel.com> >>>>> wrote:=20 >>>> This made me look at the current source, and there I see in >>>> mce_urgent_action()=20 >>>>=20 >>>> if ( !(gstatus & MCG_STATUS_RIPV) && !guest_mode(regs)) =20 >>>> return -1;=20 >>>>=20 >>>> which I think should say ... _EIPV and use || instead. Thoughts? >>>=20 >>> I think this code means, if the error happens in hypervisor mode >>> (i.e. !guest_mode()), and RIPV indicate the RIP in stack can't be >>> restarted, we have to panic. >>=20 >> Then the guest_mode() check still lacks an extra check of EIPV, like >>=20 >> if ( !(gstatus & MCG_STATUS_RIPV) && >> (!(gstatus & MCG_STATUS_EIPV) || !guest_mode(regs))) >> return -1; >>=20 >=20 > That would be overkilled. > Considering instruction fetch error occur at guest context, hypervisor=20= > deliver to guest to handle the error is perfer, not panic all system. Even if it was hypervisor code that got prefetched while still executing guest code (which ought to be possible at least across a syscall/sysenter instruction)? Jan _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel From xen-devel-bounces@lists.xensource.com Fri Sep 30 01:04:36 2011 Return-path: <xen-devel-bounces@lists.xensource.com> Envelope-to: www-data@lists.xensource.com Delivery-date: Fri, 30 Sep 2011 01:04:36 -0700 Received: from localhost ([127.0.0.1] helo=lists.colo.xensource.com) by lists.xensource.com with esmtp (Exim 4.43) id 1R9Y5D-0007iu-KJ; Fri, 30 Sep 2011 01:04:35 -0700 Received: from mail21.messagelabs.com ([85.158.143.35]) by lists.xensource.com with esmtp (Exim 4.43) id 1R9Y32-0007VK-SL for xen-devel@lists.xensource.com; Fri, 30 Sep 2011 01:02:25 -0700 X-Env-Sender: Ian.Campbell@eu.citrix.com X-Msg-Ref: server-3.tower-21.messagelabs.com!1317369748!53526447!1 X-Originating-IP: [62.200.22.115] X-StarScan-Version: 6.4.1; banners=-,-,- X-VirusChecked: Checked Received: (qmail 5290 invoked from network); 30 Sep 2011 08:02:29 -0000 Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115) by server-3.tower-21.messagelabs.com with RC4-SHA encrypted SMTP; 30 Sep 2011 08:02:29 -0000 X-IronPort-AV: E=Sophos;i="4.68,465,1312156800"; d="scan'208";a="8142927" Received: from lonpmailmx01.citrite.net ([10.30.203.162]) by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5; 30 Sep 2011 08:01:22 +0000 Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net (10.30.203.162) with Microsoft SMTP Server id 8.3.137.0; Fri, 30 Sep 2011 09:01:22 +0100 Subject: Re: [Xen-devel] [PATCH 7/9] xen/xenbus: Check before dereferencing it. From: Ian Campbell <Ian.Campbell@citrix.com> To: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com> Date: Fri, 30 Sep 2011 09:01:21 +0100 In-Reply-To: <1317325971-21603-8-git-send-email-konrad.wilk@oracle.com> References: <1317325971-21603-1-git-send-email-konrad.wilk@oracle.com> <1317325971-21603-8-git-send-email-konrad.wilk@oracle.com> Organization: Citrix Systems, Inc. Content-Type: text/plain; charset="UTF-8" X-Mailer: Evolution 3.0.3- Content-Transfer-Encoding: 7bit Message-ID: <1317369681.26672.218.camel@zakaz.uk.xensource.com> MIME-Version: 1.0 Cc: Dan, "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>, "linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>, Carpenter <error27@gmail.com> X-BeenThere: xen-devel@lists.xensource.com X-Mailman-Version: 2.1.5 Precedence: list List-Id: Xen developer discussion <xen-devel.lists.xensource.com> List-Unsubscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe> List-Post: <mailto:xen-devel@lists.xensource.com> List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help> List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=subscribe> Sender: xen-devel-bounces@lists.xensource.com Errors-To: xen-devel-bounces@lists.xensource.com On Thu, 2011-09-29 at 20:52 +0100, Konrad Rzeszutek Wilk wrote: > . we do the check whether 'xdev' is NULL - but after we have > dereferenced it. > > Signed-off-by: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com> > --- > drivers/xen/xenbus/xenbus_probe_backend.c | 3 ++- > 1 files changed, 2 insertions(+), 1 deletions(-) > > diff --git a/drivers/xen/xenbus/xenbus_probe_backend.c b/drivers/xen/xenbus/xenbus_probe_backend.c > index 60adf91..331589a 100644 > --- a/drivers/xen/xenbus/xenbus_probe_backend.c > +++ b/drivers/xen/xenbus/xenbus_probe_backend.c > @@ -103,10 +103,11 @@ static int xenbus_uevent_backend(struct device *dev, > return -ENODEV; > > xdev = to_xenbus_device(dev); to_xenbus_device is just container_of. The only way it would return NULL is if dev == offsetof(struct xenbus_device, dev), which isn't terribly likely. A more likely error would be dev == NULL and we just checked above. > - bus = container_of(xdev->dev.bus, struct xen_bus_type, bus); > if (xdev == NULL) > return -ENODEV; > > + bus = container_of(xdev->dev.bus, struct xen_bus_type, bus); > + > if (add_uevent_var(env, "MODALIAS=xen-backend:%s", xdev->devicetype)) > return -ENOMEM; > _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel From xen-devel-bounces@lists.xensource.com Fri Sep 30 01:09:02 2011 Return-path: <xen-devel-bounces@lists.xensource.com> Envelope-to: www-data@lists.xensource.com Delivery-date: Fri, 30 Sep 2011 01:09:02 -0700 Received: from localhost ([127.0.0.1] helo=lists.colo.xensource.com) by lists.xensource.com with esmtp (Exim 4.43) id 1R9Y9W-0008Am-M7; Fri, 30 Sep 2011 01:09:02 -0700 Received: from mail182.messagelabs.com ([85.158.139.83]) by lists.xensource.com with esmtp (Exim 4.43) id 1R9Y92-0007yJ-3O for xen-devel@lists.xensource.com; Fri, 30 Sep 2011 01:08:34 -0700 X-Env-Sender: JBeulich@suse.com X-Msg-Ref: server-7.tower-182.messagelabs.com!1317370108!15309811!1 X-Originating-IP: [130.57.49.28] X-StarScan-Version: 6.4.1; banners=-,-,- X-VirusChecked: Checked Received: (qmail 16567 invoked from network); 30 Sep 2011 08:08:29 -0000 Received: from nat28.tlf.novell.com (HELO nat28.tlf.novell.com) (130.57.49.28) by server-7.tower-182.messagelabs.com with DHE-RSA-AES256-SHA encrypted SMTP; 30 Sep 2011 08:08:29 -0000 Received: from EMEA1-MTA by nat28.tlf.novell.com with Novell_GroupWise; Fri, 30 Sep 2011 09:08:28 +0100 Message-Id: <4E85951B0200007800058AF8@nat28.tlf.novell.com> X-Mailer: Novell GroupWise Internet Agent 8.0.1 Date: Fri, 30 Sep 2011 09:08:27 +0100 From: "Jan Beulich" <JBeulich@suse.com> To: "David Vrabel" <david.vrabel@citrix.com> Subject: Re: [Xen-devel] [PATCH 0/4] xen: map foreign pages for shared rings by updating the PTEs directly References: <1317311612-15220-1-git-send-email-david.vrabel@citrix.com> <4E84B3FE02000078000588A9@nat28.tlf.novell.com> <4E84A0C0.6000804@citrix.com> In-Reply-To: <4E84A0C0.6000804@citrix.com> Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: quoted-printable Content-Disposition: inline Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>, KonradRzeszutek Wilk <konrad.wilk@oracle.com> X-BeenThere: xen-devel@lists.xensource.com X-Mailman-Version: 2.1.5 Precedence: list List-Id: Xen developer discussion <xen-devel.lists.xensource.com> List-Unsubscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe> List-Post: <mailto:xen-devel@lists.xensource.com> List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help> List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=subscribe> Sender: xen-devel-bounces@lists.xensource.com Errors-To: xen-devel-bounces@lists.xensource.com >>> On 29.09.11 at 18:45, David Vrabel <david.vrabel@citrix.com> wrote: > On 29/09/11 17:07, Jan Beulich wrote: >>>>> On 29.09.11 at 17:53, David Vrabel <david.vrabel@citrix.com> wrote: >>> [Resend as requested by Konrad.] >>> >>> This series of patches allows the vmalloc_sync_all() to be removed >>> from alloc_vm_area() by getting the hypervisor to update the PTEs (in >>> init_mm) directly rather than having the hypervisor look in the >>> current page tables to find the PTEs. >>> >>> Once the hypervisor has updated the PTEs, the normal mechanism of >>> syncing the page tables after a fault works as expected. >>=20 >> Did you actually test that, and namely the case where alloc_vm_area() >> would result in a new top level page directory entry to get populated? >> >> I cannot see how this new entry would propagate into other mm-s, and >> hence I cannot see how you can do away with calling vmalloc_sync_all() >> just by changing how leaf page table entries get populated. >=20 > I don't think this new behaviour of alloc_vm_area() is any different > from how a regular vmalloc() works. Of course not. Callers of vmalloc() need to use vmalloc_sync_all() too before it is permitted to access the allocated space from an NMI handler or pass it into a hypercall. > vmalloc_fault() copies the page table entries from init_mm into the > current MM (on 32-bit it calls vmalloc_sync_one() which makes it > obviously correct I think). No, vmalloc_fault() copies pmd-s (32-bit) or pgd-s (64-bit), but never pte-s. Avoiding this to be done in a fault (precisely for the NMI and hypercall cases named above) is what vmalloc_sync_all() was introduced for (really, the hypercall aspect didn't matter back then, and alloc_vm_area() didn't exist outside of Xenolinux then either). So eliminating it from alloc_vm_area() just pushes the need to call it to all callers that may have the obtained space accessed in NMI context (none at present, as only Xen code appears to call this function) or want to pass it to a hypercall without running on init_mm. Just to repeat the essence of my first reply: Fiddling with how pte-s get populated can not possibly eliminate the need to call a function that populates top level page directory entries (pmd-s/pgd-s). Jan >>> This mechanism doesn't currently work on the ia64 port as that does >>> not support the GNTMAP_contains_pte flag. >>> >>> David _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel From xen-devel-bounces@lists.xensource.com Fri Sep 30 01:11:26 2011 Return-path: <xen-devel-bounces@lists.xensource.com> Envelope-to: www-data@lists.xensource.com Delivery-date: Fri, 30 Sep 2011 01:11:26 -0700 Received: from localhost ([127.0.0.1] helo=lists.colo.xensource.com) by lists.xensource.com with esmtp (Exim 4.43) id 1R9YBp-00007f-UA; Fri, 30 Sep 2011 01:11:25 -0700 Received: from mail216.messagelabs.com ([85.158.143.99]) by lists.xensource.com with esmtp (Exim 4.43) id 1R9YBM-0008MN-6W for xen-devel@lists.xensource.com; Fri, 30 Sep 2011 01:10:56 -0700 X-Env-Sender: Ian.Campbell@eu.citrix.com X-Msg-Ref: server-2.tower-216.messagelabs.com!1317370252!19651946!1 X-Originating-IP: [62.200.22.115] X-StarScan-Version: 6.4.1; banners=-,-,- X-VirusChecked: Checked Received: (qmail 12973 invoked from network); 30 Sep 2011 08:10:53 -0000 Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115) by server-2.tower-216.messagelabs.com with RC4-SHA encrypted SMTP; 30 Sep 2011 08:10:53 -0000 X-IronPort-AV: E=Sophos;i="4.68,465,1312156800"; d="scan'208";a="8143203" Received: from lonpmailmx01.citrite.net ([10.30.203.162]) by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5; 30 Sep 2011 08:10:52 +0000 Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net (10.30.203.162) with Microsoft SMTP Server id 8.3.137.0; Fri, 30 Sep 2011 09:10:52 +0100 Subject: Re: [Xen-devel] [PATCH 8/9] xen/enlighten: Fix compile warnings. From: Ian Campbell <Ian.Campbell@citrix.com> To: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com> Date: Fri, 30 Sep 2011 09:10:51 +0100 In-Reply-To: <1317325971-21603-9-git-send-email-konrad.wilk@oracle.com> References: <1317325971-21603-1-git-send-email-konrad.wilk@oracle.com> <1317325971-21603-9-git-send-email-konrad.wilk@oracle.com> Organization: Citrix Systems, Inc. Content-Type: text/plain; charset="UTF-8" X-Mailer: Evolution 3.0.3- Content-Transfer-Encoding: 8bit Message-ID: <1317370252.26672.224.camel@zakaz.uk.xensource.com> MIME-Version: 1.0 Cc: Dan, "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>, "linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>, Carpenter <error27@gmail.com> X-BeenThere: xen-devel@lists.xensource.com X-Mailman-Version: 2.1.5 Precedence: list List-Id: Xen developer discussion <xen-devel.lists.xensource.com> List-Unsubscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe> List-Post: <mailto:xen-devel@lists.xensource.com> List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help> List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=subscribe> Sender: xen-devel-bounces@lists.xensource.com Errors-To: xen-devel-bounces@lists.xensource.com On Thu, 2011-09-29 at 20:52 +0100, Konrad Rzeszutek Wilk wrote: > linux/arch/x86/xen/enlighten.c: In function ‘xen_start_kernel’: > linux/arch/x86/xen/enlighten.c:226: warning: ‘cx’ may be used uninitialized in this function > linux/arch/x86/xen/enlighten.c:240: note: ‘cx’ was declared here Before 61f4237d5b005767a76f4f3694e68e6f78f392d9 we used to initialise cx to zero before calling xen_cpuid. 947ccf9c3c30307b774af3666ee74fcd9f47f646 didn't put it back for some reason. Regardless I'm not sure how cx can be unused while {a,b,d}x apparently are not. All four are passed to xen_cpuid(&ax, &bx, &cx, &dx) and even if gcc were being clever and looking into xen_cpuid all four are in the output constraints of the real cpuid asm call. Oh, I see, ax and cx are also in the input side of the asm and ax is initialised but cx is not and that is the use not the one later in xen_init_cpuid_mask. I think that even if cpuid leaf ax=1 happens not to use the subleaf index in cx we'd be better to initialise cx=0 than use uninitialized_var here. Ian. > > Signed-off-by: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com> > --- > arch/x86/xen/enlighten.c | 2 +- > 1 files changed, 1 insertions(+), 1 deletions(-) > > diff --git a/arch/x86/xen/enlighten.c b/arch/x86/xen/enlighten.c > index 2d69617..9473861 100644 > --- a/arch/x86/xen/enlighten.c > +++ b/arch/x86/xen/enlighten.c > @@ -237,7 +237,7 @@ static void xen_cpuid(unsigned int *ax, unsigned int *bx, > > static void __init xen_init_cpuid_mask(void) > { > - unsigned int ax, bx, cx, dx; > + unsigned int ax, bx, uninitialized_var(cx), dx; > unsigned int xsave_mask; > > cpuid_leaf1_edx_mask = _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel From xen-devel-bounces@lists.xensource.com Fri Sep 30 01:18:47 2011 Return-path: <xen-devel-bounces@lists.xensource.com> Envelope-to: www-data@lists.xensource.com Delivery-date: Fri, 30 Sep 2011 01:18:47 -0700 Received: from localhost ([127.0.0.1] helo=lists.colo.xensource.com) by lists.xensource.com with esmtp (Exim 4.43) id 1R9YIx-0000a2-Db; Fri, 30 Sep 2011 01:18:47 -0700 Received: from mail182.messagelabs.com ([85.158.139.83]) by lists.xensource.com with esmtp (Exim 4.43) id 1R9YIX-0000O4-Ly for xen-devel@lists.xensource.com; Fri, 30 Sep 2011 01:18:22 -0700 X-Env-Sender: Ian.Campbell@eu.citrix.com X-Msg-Ref: server-3.tower-182.messagelabs.com!1317370697!17527356!1 X-Originating-IP: [62.200.22.115] X-StarScan-Version: 6.4.1; banners=-,-,- X-VirusChecked: Checked Received: (qmail 18473 invoked from network); 30 Sep 2011 08:18:17 -0000 Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115) by server-3.tower-182.messagelabs.com with RC4-SHA encrypted SMTP; 30 Sep 2011 08:18:17 -0000 X-IronPort-AV: E=Sophos;i="4.68,465,1312156800"; d="scan'208";a="8143362" Received: from lonpmailmx01.citrite.net ([10.30.203.162]) by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5; 30 Sep 2011 08:18:17 +0000 Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net (10.30.203.162) with Microsoft SMTP Server id 8.3.137.0; Fri, 30 Sep 2011 09:18:17 +0100 Subject: Re: [Xen-devel] [PATCH 9/9] xen/p2m/debugfs: Fix potential pointer exception. From: Ian Campbell <Ian.Campbell@citrix.com> To: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com> Date: Fri, 30 Sep 2011 09:18:17 +0100 In-Reply-To: <1317325971-21603-10-git-send-email-konrad.wilk@oracle.com> References: <1317325971-21603-1-git-send-email-konrad.wilk@oracle.com> <1317325971-21603-10-git-send-email-konrad.wilk@oracle.com> Organization: Citrix Systems, Inc. Content-Type: text/plain; charset="UTF-8" X-Mailer: Evolution 3.0.3- Content-Transfer-Encoding: 7bit Message-ID: <1317370697.26672.230.camel@zakaz.uk.xensource.com> MIME-Version: 1.0 Cc: Dan, "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>, "linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>, Carpenter <error27@gmail.com> X-BeenThere: xen-devel@lists.xensource.com X-Mailman-Version: 2.1.5 Precedence: list List-Id: Xen developer discussion <xen-devel.lists.xensource.com> List-Unsubscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe> List-Post: <mailto:xen-devel@lists.xensource.com> List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help> List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=subscribe> Sender: xen-devel-bounces@lists.xensource.com Errors-To: xen-devel-bounces@lists.xensource.com On Thu, 2011-09-29 at 20:52 +0100, Konrad Rzeszutek Wilk wrote: > We could be referencing the last + 1 element of level_name[] > array which would cause a pointer exception. If we end up accessing it does that not mean something, i.e. should it not be a real string here and not NULL? Otherwise isn't it a bug in the lookup code that we end up looking there? I think this lookup correspond to the initialisation of lvl=4 and falling through the subsequent list of checks without matching one. In which case I think level_name[4] should be "unknown" or even "error". I don't think you can hit type_name[4] in the same way, type and prev_type are always one of the TYPE_* defines, which have values 0..3 inclusive. You could make this more obvious and defend against future changes breaking this with: ... type_name[] = { [TYPE_IDENTITY] = "identity", [TYPE_MISSING] = "missing" ... }; Ian. > > Signed-off-by: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com> > --- > arch/x86/xen/p2m.c | 4 ++-- > 1 files changed, 2 insertions(+), 2 deletions(-) > > diff --git a/arch/x86/xen/p2m.c b/arch/x86/xen/p2m.c > index 58efeb9..bc4cf0a 100644 > --- a/arch/x86/xen/p2m.c > +++ b/arch/x86/xen/p2m.c > @@ -786,9 +786,9 @@ EXPORT_SYMBOL_GPL(m2p_find_override_pfn); > int p2m_dump_show(struct seq_file *m, void *v) > { > static const char * const level_name[] = { "top", "middle", > - "entry", "abnormal" }; > + "entry", "abnormal", NULL}; > static const char * const type_name[] = { "identity", "missing", > - "pfn", "abnormal"}; > + "pfn", "abnormal", NULL}; > #define TYPE_IDENTITY 0 > #define TYPE_MISSING 1 > #define TYPE_PFN 2 _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel From xen-devel-bounces@lists.xensource.com Fri Sep 30 01:23:11 2011 Return-path: <xen-devel-bounces@lists.xensource.com> Envelope-to: www-data@lists.xensource.com Delivery-date: Fri, 30 Sep 2011 01:23:11 -0700 Received: from localhost ([127.0.0.1] helo=lists.colo.xensource.com) by lists.xensource.com with esmtp (Exim 4.43) id 1R9YND-00010q-Ow; Fri, 30 Sep 2011 01:23:11 -0700 Received: from mail27.messagelabs.com ([193.109.254.147]) by lists.xensource.com with smtp (Exim 4.43) id 1R9YMi-0000oG-9k for xen-devel@lists.xensource.com; Fri, 30 Sep 2011 01:22:40 -0700 X-Env-Sender: jinsong.liu@intel.com X-Msg-Ref: server-11.tower-27.messagelabs.com!1317370947!39541891!1 X-Originating-IP: [134.134.136.20] X-StarScan-Version: 6.4.1; banners=-,-,- X-VirusChecked: Checked Received: (qmail 18491 invoked from network); 30 Sep 2011 08:22:27 -0000 Received: from mga02.intel.com (HELO mga02.intel.com) (134.134.136.20) by server-11.tower-27.messagelabs.com with SMTP; 30 Sep 2011 08:22:27 -0000 Received: from orsmga002.jf.intel.com ([10.7.209.21]) by orsmga101.jf.intel.com with ESMTP; 30 Sep 2011 01:22:36 -0700 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="4.67,351,1309762800"; d="scan'208";a="58348231" Received: from pgsmsx603.gar.corp.intel.com ([10.221.43.87]) by orsmga002.jf.intel.com with ESMTP; 30 Sep 2011 01:22:35 -0700 Received: from shsmsx602.ccr.corp.intel.com (10.239.4.104) by pgsmsx603.gar.corp.intel.com (10.221.43.87) with Microsoft SMTP Server (TLS) id 8.2.255.0; Fri, 30 Sep 2011 16:21:04 +0800 Received: from shsmsx502.ccr.corp.intel.com ([10.239.4.96]) by SHSMSX602.ccr.corp.intel.com ([10.239.4.104]) with mapi; Fri, 30 Sep 2011 16:21:02 +0800 From: "Liu, Jinsong" <jinsong.liu@intel.com> To: Jan Beulich <JBeulich@suse.com>, "Jiang, Yunhong" <yunhong.jiang@intel.com> Date: Fri, 30 Sep 2011 16:21:01 +0800 Subject: RE: [Xen-devel] [PATCH] X86 MCE: Add SRAR handler Thread-Topic: [Xen-devel] [PATCH] X86 MCE: Add SRAR handler Thread-Index: Acx/Rq6WnROJ2nrjQNWgUP/OuuW+OgAAYJXA Message-ID: <BC00F5384FCFC9499AF06F92E8B78A9E263B557F40@shsmsx502.ccr.corp.intel.com> References: <BC00F5384FCFC9499AF06F92E8B78A9E263B557B77@shsmsx502.ccr.corp.intel.com> <4E84ADF70200007800058882@nat28.tlf.novell.com> <789F9655DD1B8F43B48D77C5D306597312D2366A9B@shsmsx501.ccr.corp.intel.com> <4E858AF30200007800058A64@nat28.tlf.novell.com> <BC00F5384FCFC9499AF06F92E8B78A9E263B557F02@shsmsx502.ccr.corp.intel.com> <4E8592A60200007800058AD4@nat28.tlf.novell.com> In-Reply-To: <4E8592A60200007800058AD4@nat28.tlf.novell.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "keir.xen@gmail.com" <keir.xen@gmail.com>, "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com> X-BeenThere: xen-devel@lists.xensource.com X-Mailman-Version: 2.1.5 Precedence: list List-Id: Xen developer discussion <xen-devel.lists.xensource.com> List-Unsubscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe> List-Post: <mailto:xen-devel@lists.xensource.com> List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help> List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=subscribe> Sender: xen-devel-bounces@lists.xensource.com Errors-To: xen-devel-bounces@lists.xensource.com Jan Beulich wrote: >>>> On 30.09.11 at 09:44, "Liu, Jinsong" <jinsong.liu@intel.com> wrote: >> Jan Beulich wrote: >>>>>> On 30.09.11 at 04:51, "Jiang, Yunhong" <yunhong.jiang@intel.com> >>>>>> wrote: >>>>> This made me look at the current source, and there I see in >>>>> mce_urgent_action()=20 >>>>>=20 >>>>> if ( !(gstatus & MCG_STATUS_RIPV) && !guest_mode(regs)) >>>>> return -1;=20 >>>>>=20 >>>>> which I think should say ... _EIPV and use || instead. Thoughts? >>>>=20 >>>> I think this code means, if the error happens in hypervisor mode >>>> (i.e. !guest_mode()), and RIPV indicate the RIP in stack can't be >>>> restarted, we have to panic. >>>=20 >>> Then the guest_mode() check still lacks an extra check of EIPV, like >>>=20 >>> if ( !(gstatus & MCG_STATUS_RIPV) && >>> (!(gstatus & MCG_STATUS_EIPV) || !guest_mode(regs))) =20 >>> return -1;=20 >>>=20 >>=20 >> That would be overkilled. >> Considering instruction fetch error occur at guest context, >> hypervisor deliver to guest to handle the error is perfer, not panic >> all system.=20 >=20 > Even if it was hypervisor code that got prefetched while still > executing guest code (which ought to be possible at least > across a syscall/sysenter instruction)? >=20 Executing guest code will not satisfy the check if ( !(gstatus & MCG_STATUS_RIPV) && !guest_mode(regs)) return -1; so it would not panic system. Thanks, Jinsong= _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel From xen-devel-bounces@lists.xensource.com Fri Sep 30 01:29:25 2011 Return-path: <xen-devel-bounces@lists.xensource.com> Envelope-to: www-data@lists.xensource.com Delivery-date: Fri, 30 Sep 2011 01:29:25 -0700 Received: from localhost ([127.0.0.1] helo=lists.colo.xensource.com) by lists.xensource.com with esmtp (Exim 4.43) id 1R9YTF-0001Te-Dt; Fri, 30 Sep 2011 01:29:25 -0700 Received: from mail27.messagelabs.com ([193.109.254.147]) by lists.xensource.com with esmtp (Exim 4.43) id 1R9YSK-0001Gs-Pu for xen-devel@lists.xensource.com; Fri, 30 Sep 2011 01:28:29 -0700 X-Env-Sender: vase@selfip.ru X-Msg-Ref: server-2.tower-27.messagelabs.com!1317371279!57077771!1 X-Originating-IP: [74.125.82.43] X-StarScan-Version: 6.4.1; banners=-,-,- X-VirusChecked: Checked Received: (qmail 16509 invoked from network); 30 Sep 2011 08:27:59 -0000 Received: from mail-ww0-f43.google.com (HELO mail-ww0-f43.google.com) (74.125.82.43) by server-2.tower-27.messagelabs.com with RC4-SHA encrypted SMTP; 30 Sep 2011 08:27:59 -0000 Received: by wwf27 with SMTP id 27so1872981wwf.24 for <xen-devel@lists.xensource.com>; Fri, 30 Sep 2011 01:28:25 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=selfip.ru; s=google; h=mime-version:sender:x-originating-ip:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type; bh=vCxdFPJwaRSC+KVTFl1GRZGUuuNsc6aZde1FhOWrYek=; b=gVALzRJs61biGPd33oK36CtN0n1p1qBE/HaGQ0pM81hiB79yjx59cCJwEPQ9yTrUFZ zYMAHdtFZkcv/7m9gT5R4/+ntXQVzkLdmNx8/wLxhIu5f9SDQz/TxtZedhlDlNivFIn2 vkacNIcLNQDPKUlAq8xt44TxBcTNwJh/ZTQVA= MIME-Version: 1.0 Received: by 10.216.230.160 with SMTP id j32mr7785370weq.31.1317371305422; Fri, 30 Sep 2011 01:28:25 -0700 (PDT) Received: by 10.216.4.69 with HTTP; Fri, 30 Sep 2011 01:28:25 -0700 (PDT) X-Originating-IP: [85.143.161.18] In-Reply-To: <CACaajQsMnXb9u1pTtB9jT5b6n2p6gFq_A8aQajAO4kmcpSwKdw@mail.gmail.com> References: <1313764724-12683-1-git-send-email-dgdegra@tycho.nsa.gov> <1316729665-15004-1-git-send-email-dgdegra@tycho.nsa.gov> <CACaajQsMnXb9u1pTtB9jT5b6n2p6gFq_A8aQajAO4kmcpSwKdw@mail.gmail.com> Date: Fri, 30 Sep 2011 12:28:25 +0400 X-Google-Sender-Auth: _U77O5Zfkpk3Vu3w1kJRrjy1PRY Message-ID: <CACaajQtCMpWuqH8PGhwK-WGC=bXRiE1an+2sWcm2JaozK7BK=w@mail.gmail.com> Subject: Re: [Xen-devel] [PATCH v6 0/3] libxenvchan: interdomain communications library From: Vasiliy Tolstov <v.tolstov@selfip.ru> To: Daniel De Graaf <dgdegra@tycho.nsa.gov> Cc: Ian.Campbell@eu.citrix.com, xen-devel@lists.xensource.com, Ian.Jackson@eu.citrix.com, konrad.wilk@oracle.com, Stefano.Stabellini@eu.citrix.com X-BeenThere: xen-devel@lists.xensource.com X-Mailman-Version: 2.1.5 Precedence: list List-Id: Xen developer discussion <xen-devel.lists.xensource.com> List-Unsubscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe> List-Post: <mailto:xen-devel@lists.xensource.com> List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help> List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=subscribe> Content-Type: multipart/mixed; boundary="===============0903497733==" Sender: xen-devel-bounces@lists.xensource.com Errors-To: xen-devel-bounces@lists.xensource.com --===============0903497733== Content-Type: multipart/alternative; boundary=0016e64713e4b26e3e04ae246805 --0016e64713e4b26e3e04ae246805 Content-Type: text/plain; charset=UTF-8 2011/9/30 Vasiliy Tolstov <v.tolstov@selfip.ru> > > > 2011/9/23 Daniel De Graaf <dgdegra@tycho.nsa.gov> > >> Changes since v5: >> - Unify gntdev osdep interface >> - Eliminate notify_result and revert mapping if notify ioctl fails >> - Rename functions and structures to libxenvchan >> - Use application-specified xenstore path for ring/event data >> - Enforce maximum ring size of 2^20 bytes on client >> - Change to LGPL 2.1 >> >> [PATCH 1/3] libxc: add xc_gnttab_map_grant_ref_notify >> [PATCH 2/3] libxc: add xc_gntshr_* functions >> [PATCH 3/3] libvchan: interdomain communications library >> >> >> > Hello. Sorry for bumping.. > What version of xen kernel i need to use this library? Now i have 2.6.32.26 > in many domUs. > And what i need in dom0 for that, if i want to communicate via libxenvchan > from domU to dom0? > > > And where i can find latest version of the patch? -- Vasiliy Tolstov, Clodo.ru e-mail: v.tolstov@selfip.ru jabber: vase@selfip.ru --0016e64713e4b26e3e04ae246805 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable <br><br><div class=3D"gmail_quote">2011/9/30 Vasiliy Tolstov <span dir=3D"l= tr"><<a href=3D"mailto:v.tolstov@selfip.ru">v.tolstov@selfip.ru</a>><= /span><br><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;bord= er-left:1px #ccc solid;padding-left:1ex;"> <br><br><div class=3D"gmail_quote"><div class=3D"im">2011/9/23 Daniel De Gr= aaf <span dir=3D"ltr"><<a href=3D"mailto:dgdegra@tycho.nsa.gov" target= =3D"_blank">dgdegra@tycho.nsa.gov</a>></span><br><blockquote class=3D"gm= ail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-le= ft:1ex"> Changes since v5:<br> =C2=A0- Unify gntdev osdep interface<br> =C2=A0- Eliminate notify_result and revert mapping if notify ioctl fails<br= > =C2=A0- Rename functions and structures to libxenvchan<br> =C2=A0- Use application-specified xenstore path for ring/event data<br> =C2=A0- Enforce maximum ring size of 2^20 bytes on client<br> =C2=A0- Change to LGPL 2.1<br> <br> [PATCH 1/3] libxc: add xc_gnttab_map_grant_ref_notify<br> [PATCH 2/3] libxc: add xc_gntshr_* functions<br> [PATCH 3/3] libvchan: interdomain communications library<br> <br><br></blockquote><div><br></div></div><div>Hello. Sorry for bumping..</= div><div>What version of xen kernel i need to use this library? Now i have = 2.6.32.26 in many domUs.</div><div>And what i need in dom0 for that, if i w= ant to communicate via libxenvchan from domU to dom0?</div> </div><br clear=3D"all"><font color=3D"#888888"><div><br></div></font></blo= ckquote></div><div><br></div>And where i can find latest version of the pat= ch?<br clear=3D"all"><div><br></div>-- <br><span style=3D"border-collapse:c= ollapse;color:rgb(136, 136, 136);font-family:arial, sans-serif;font-size:13= px"><div> <div>Vasiliy Tolstov,</div><div>Clodo.ru</div><div>e-mail: <a href=3D"mailt= o:v.tolstov@selfip.ru" target=3D"_blank">v.tolstov@selfip.ru</a></div><div>= jabber: <a href=3D"mailto:vase@selfip.ru" target=3D"_blank">vase@selfip.ru<= /a></div> </div></span><br> --0016e64713e4b26e3e04ae246805-- --===============0903497733== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel --===============0903497733==-- From xen-devel-bounces@lists.xensource.com Fri Sep 30 01:34:54 2011 Return-path: <xen-devel-bounces@lists.xensource.com> Envelope-to: www-data@lists.xensource.com Delivery-date: Fri, 30 Sep 2011 01:34:54 -0700 Received: from localhost ([127.0.0.1] helo=lists.colo.xensource.com) by lists.xensource.com with esmtp (Exim 4.43) id 1R9YYY-00020u-Fp; Fri, 30 Sep 2011 01:34:54 -0700 Received: from mail182.messagelabs.com ([85.158.139.83]) by lists.xensource.com with esmtp (Exim 4.43) id 1R9YXw-0001ol-1r for xen-devel@lists.xensource.com; Fri, 30 Sep 2011 01:34:16 -0700 X-Env-Sender: Ian.Campbell@eu.citrix.com X-Msg-Ref: server-5.tower-182.messagelabs.com!1317371652!15352248!1 X-Originating-IP: [62.200.22.115] X-StarScan-Version: 6.4.1; banners=-,-,- X-VirusChecked: Checked Received: (qmail 21887 invoked from network); 30 Sep 2011 08:34:13 -0000 Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115) by server-5.tower-182.messagelabs.com with RC4-SHA encrypted SMTP; 30 Sep 2011 08:34:13 -0000 X-IronPort-AV: E=Sophos;i="4.68,465,1312156800"; d="scan'208";a="8143927" Received: from lonpmailmx01.citrite.net ([10.30.203.162]) by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5; 30 Sep 2011 08:34:12 +0000 Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net (10.30.203.162) with Microsoft SMTP Server id 8.3.137.0; Fri, 30 Sep 2011 09:34:12 +0100 From: Ian Campbell <Ian.Campbell@eu.citrix.com> To: Daniel De Graaf <dgdegra@tycho.nsa.gov> Date: Fri, 30 Sep 2011 09:34:11 +0100 In-Reply-To: <1316729665-15004-1-git-send-email-dgdegra@tycho.nsa.gov> References: <1313764724-12683-1-git-send-email-dgdegra@tycho.nsa.gov> <1316729665-15004-1-git-send-email-dgdegra@tycho.nsa.gov> Organization: Citrix Systems, Inc. Content-Type: text/plain; charset="UTF-8" X-Mailer: Evolution 3.0.3- Content-Transfer-Encoding: 7bit Message-ID: <1317371652.26672.236.camel@zakaz.uk.xensource.com> MIME-Version: 1.0 Cc: Stefano Stabellini <Stefano.Stabellini@eu.citrix.com>, "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>, Ian Jackson <Ian.Jackson@eu.citrix.com>, "konrad.wilk@oracle.com" <konrad.wilk@oracle.com> Subject: [Xen-devel] Re: [PATCH v6 0/3] libxenvchan: interdomain communications library X-BeenThere: xen-devel@lists.xensource.com X-Mailman-Version: 2.1.5 Precedence: list List-Id: Xen developer discussion <xen-devel.lists.xensource.com> List-Unsubscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe> List-Post: <mailto:xen-devel@lists.xensource.com> List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help> List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=subscribe> Sender: xen-devel-bounces@lists.xensource.com Errors-To: xen-devel-bounces@lists.xensource.com On Thu, 2011-09-22 at 23:14 +0100, Daniel De Graaf wrote: > Changes since v5: > - Unify gntdev osdep interface > - Eliminate notify_result and revert mapping if notify ioctl fails > - Rename functions and structures to libxenvchan > - Use application-specified xenstore path for ring/event data > - Enforce maximum ring size of 2^20 bytes on client > - Change to LGPL 2.1 > > [PATCH 1/3] libxc: add xc_gnttab_map_grant_ref_notify > [PATCH 2/3] libxc: add xc_gntshr_* functions > [PATCH 3/3] libvchan: interdomain communications library I meant to say this before but, modulo the spurious changes to tools/libxl/libxlu_cfg_l.[ch] in the first patch, the whole lot are: Acked-by: Ian Campbell <ian.campbell@citrix.com> The error reporting for missing XC_OSDEP_GNTSDHR is missing in xc_netbsd.c but I think that should be pulled out into common code -- I'll send out a patch. Ian. _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel From xen-devel-bounces@lists.xensource.com Fri Sep 30 01:38:10 2011 Return-path: <xen-devel-bounces@lists.xensource.com> Envelope-to: www-data@lists.xensource.com Delivery-date: Fri, 30 Sep 2011 01:38:10 -0700 Received: from localhost ([127.0.0.1] helo=lists.colo.xensource.com) by lists.xensource.com with esmtp (Exim 4.43) id 1R9Ybh-0002Tp-Ta; Fri, 30 Sep 2011 01:38:09 -0700 Received: from mail21.messagelabs.com ([85.158.143.35]) by lists.xensource.com with esmtp (Exim 4.43) id 1R9Yap-0002DD-LM for xen-devel@lists.xensource.com; Fri, 30 Sep 2011 01:37:16 -0700 X-Env-Sender: Ian.Campbell@eu.citrix.com X-Msg-Ref: server-6.tower-21.messagelabs.com!1317371811!40240005!1 X-Originating-IP: [66.165.176.89] X-StarScan-Version: 6.4.1; banners=-,-,- X-VirusChecked: Checked Received: (qmail 6173 invoked from network); 30 Sep 2011 08:36:52 -0000 Received: from smtp.citrix.com (HELO SMTP.CITRIX.COM) (66.165.176.89) by server-6.tower-21.messagelabs.com with RC4-SHA encrypted SMTP; 30 Sep 2011 08:36:52 -0000 X-IronPort-AV: E=Sophos;i="4.68,465,1312171200"; d="scan'208";a="17833302" Received: from ftlpmailmx01.citrite.net ([10.13.107.65]) by FTLPIPO01.CITRIX.COM with ESMTP/TLS/RC4-MD5; 30 Sep 2011 04:37:10 -0400 Received: from smtp01.ad.xensource.com (10.219.128.104) by smtprelay.citrix.com (10.13.107.65) with Microsoft SMTP Server id 8.3.137.0; Fri, 30 Sep 2011 04:37:10 -0400 Received: from localhost.localdomain (cosworth.uk.xensource.com [10.80.16.52]) by smtp01.ad.xensource.com (8.13.1/8.13.1) with ESMTP id p8U8b7TO028098; Fri, 30 Sep 2011 01:37:08 -0700 Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Mercurial-Node: 19d4d6b854a6e54612a4a3a993af0716668e6627 Message-ID: <19d4d6b854a6e54612a4.1317371827@localhost.localdomain> In-Reply-To: <1317371652.26672.236.camel@zakaz.uk.xensource.com> References: <1317371652.26672.236.camel@zakaz.uk.xensource.com> User-Agent: Mercurial-patchbomb/1.6.4 Date: Fri, 30 Sep 2011 09:37:07 +0100 From: Ian Campbell <ian.campbell@citrix.com> To: xen-devel@lists.xensource.com Cc: Daniel De Graaf <dgdegra@tycho.nsa.gov>, Stefano Stabellini <Stefano.Stabellini@eu.citrix.com>, Ian Jackson <Ian.Jackson@eu.citrix.com>, konrad.wilk@oracle.com Subject: [Xen-devel] [PATCH] libxc: osdep: report missing backends in common code X-BeenThere: xen-devel@lists.xensource.com X-Mailman-Version: 2.1.5 Precedence: list List-Id: Xen developer discussion <xen-devel.lists.xensource.com> List-Unsubscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe> List-Post: <mailto:xen-devel@lists.xensource.com> List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help> List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=subscribe> Sender: xen-devel-bounces@lists.xensource.com Errors-To: xen-devel-bounces@lists.xensource.com # HG changeset patch # User Ian Campbell <ian.campbell@citrix.com> # Date 1317371726 -3600 # Node ID 19d4d6b854a6e54612a4a3a993af0716668e6627 # Parent e50da6b98e3d5933b9c98e8f43096fd3ebbae00d libxc: osdep: report missing backends in common code Backends were inconsistent about reporting and it's a pain to edit them all when adding a new class of osdep. Signed-off-by: Ian Campbell <Ian.campbell@citrix.com> --- Requires Daniel De Graaf's "libxc: add xc_gntshr_* functions" diff -r e50da6b98e3d -r 19d4d6b854a6 tools/libxc/xc_netbsd.c --- a/tools/libxc/xc_netbsd.c Thu Sep 29 17:21:32 2011 +0100 +++ b/tools/libxc/xc_netbsd.c Fri Sep 30 09:35:26 2011 +0100 @@ -386,9 +386,6 @@ static struct xc_osdep_ops *netbsd_osdep return &netbsd_privcmd_ops; case XC_OSDEP_EVTCHN: return &netbsd_evtchn_ops; - case XC_OSDEP_GNTTAB: - ERROR("GNTTAB interface not supported on this platform"); - return NULL; default: return NULL; } diff -r e50da6b98e3d -r 19d4d6b854a6 tools/libxc/xc_private.c --- a/tools/libxc/xc_private.c Thu Sep 29 17:21:32 2011 +0100 +++ b/tools/libxc/xc_private.c Fri Sep 30 09:35:26 2011 +0100 @@ -111,6 +111,18 @@ static void xc_osdep_put(xc_osdep_info_t #endif } +static const char *xc_osdep_type_name(enum xc_osdep_type type) +{ + switch ( type ) + { + case XC_OSDEP_PRIVCMD: return "privcmd"; + case XC_OSDEP_EVTCHN: return "evtchn"; + case XC_OSDEP_GNTTAB: return "gnttab"; + case XC_OSDEP_GNTSHR: return "gntshr"; + } + return "unknown"; +} + static struct xc_interface_core *xc_interface_open_common(xentoollog_logger *logger, xentoollog_logger *dombuild_logger, unsigned open_flags, @@ -161,7 +173,11 @@ static struct xc_interface_core *xc_inte xch->ops = xch->osdep.init(xch, type); if ( xch->ops == NULL ) + { + ERROR("OSDEP: interface %d (%s) not supported on this platform", + type, xc_osdep_type_name(type)); goto err_put_iface; + } xch->ops_handle = xch->ops->open(xch); if (xch->ops_handle == XC_OSDEP_OPEN_ERROR) diff -r e50da6b98e3d -r 19d4d6b854a6 tools/libxc/xc_solaris.c --- a/tools/libxc/xc_solaris.c Thu Sep 29 17:21:32 2011 +0100 +++ b/tools/libxc/xc_solaris.c Fri Sep 30 09:35:26 2011 +0100 @@ -322,9 +322,6 @@ static struct xc_osdep_ops *solaris_osde return &solaris_privcmd_ops; case XC_OSDEP_EVTCHN: return &solaris_evtchn_ops; - case XC_OSDEP_GNTTAB: - ERROR("GNTTAB interface not supported on this platform"); - return NULL; default: return NULL; } _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel From xen-devel-bounces@lists.xensource.com Fri Sep 30 01:44:52 2011 Return-path: <xen-devel-bounces@lists.xensource.com> Envelope-to: www-data@lists.xensource.com Delivery-date: Fri, 30 Sep 2011 01:44:52 -0700 Received: from localhost ([127.0.0.1] helo=lists.colo.xensource.com) by lists.xensource.com with esmtp (Exim 4.43) id 1R9YiC-00037b-RX; Fri, 30 Sep 2011 01:44:52 -0700 Received: from mail216.messagelabs.com ([85.158.143.99]) by lists.xensource.com with esmtp (Exim 4.43) id 1R9Yhg-0002vN-5L for xen-devel@lists.xensource.com; Fri, 30 Sep 2011 01:44:20 -0700 X-Env-Sender: JBeulich@suse.com X-Msg-Ref: server-4.tower-216.messagelabs.com!1317372257!20087369!1 X-Originating-IP: [130.57.49.28] X-StarScan-Version: 6.4.1; banners=-,-,- X-VirusChecked: Checked Received: (qmail 16210 invoked from network); 30 Sep 2011 08:44:17 -0000 Received: from nat28.tlf.novell.com (HELO nat28.tlf.novell.com) (130.57.49.28) by server-4.tower-216.messagelabs.com with DHE-RSA-AES256-SHA encrypted SMTP; 30 Sep 2011 08:44:17 -0000 Received: from EMEA1-MTA by nat28.tlf.novell.com with Novell_GroupWise; Fri, 30 Sep 2011 09:44:16 +0100 Message-Id: <4E859D7F0200007800058B39@nat28.tlf.novell.com> X-Mailer: Novell GroupWise Internet Agent 8.0.1 Date: Fri, 30 Sep 2011 09:44:15 +0100 From: "Jan Beulich" <JBeulich@suse.com> To: "Jinsong Liu" <jinsong.liu@intel.com>, "Yunhong Jiang" <yunhong.jiang@intel.com> Subject: RE: [Xen-devel] [PATCH] X86 MCE: Add SRAR handler References: <BC00F5384FCFC9499AF06F92E8B78A9E263B557B77@shsmsx502.ccr.corp.intel.com> <4E84ADF70200007800058882@nat28.tlf.novell.com> <789F9655DD1B8F43B48D77C5D306597312D2366A9B@shsmsx501.ccr.corp.intel.com> <4E858AF30200007800058A64@nat28.tlf.novell.com> <BC00F5384FCFC9499AF06F92E8B78A9E263B557F02@shsmsx502.ccr.corp.intel.com> <4E8592A60200007800058AD4@nat28.tlf.novell.com> <BC00F5384FCFC9499AF06F92E8B78A9E263B557F40@shsmsx502.ccr.corp.intel.com> In-Reply-To: <BC00F5384FCFC9499AF06F92E8B78A9E263B557F40@shsmsx502.ccr.corp.intel.com> Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: quoted-printable Content-Disposition: inline Cc: "keir.xen@gmail.com" <keir.xen@gmail.com>, "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com> X-BeenThere: xen-devel@lists.xensource.com X-Mailman-Version: 2.1.5 Precedence: list List-Id: Xen developer discussion <xen-devel.lists.xensource.com> List-Unsubscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe> List-Post: <mailto:xen-devel@lists.xensource.com> List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help> List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=subscribe> Sender: xen-devel-bounces@lists.xensource.com Errors-To: xen-devel-bounces@lists.xensource.com >>> On 30.09.11 at 10:21, "Liu, Jinsong" <jinsong.liu@intel.com> wrote: > Jan Beulich wrote: >>>>> On 30.09.11 at 09:44, "Liu, Jinsong" <jinsong.liu@intel.com> wrote: >>> Jan Beulich wrote: >>>>>>> On 30.09.11 at 04:51, "Jiang, Yunhong" <yunhong.jiang@intel.com> >>>>>>> wrote: >>>>>> This made me look at the current source, and there I see in >>>>>> mce_urgent_action()=20 >>>>>>=20 >>>>>> if ( !(gstatus & MCG_STATUS_RIPV) && !guest_mode(regs)) >>>>>> return -1;=20 >>>>>>=20 >>>>>> which I think should say ... _EIPV and use || instead. Thoughts? >>>>>=20 >>>>> I think this code means, if the error happens in hypervisor mode >>>>> (i.e. !guest_mode()), and RIPV indicate the RIP in stack can't be >>>>> restarted, we have to panic. >>>>=20 >>>> Then the guest_mode() check still lacks an extra check of EIPV, like >>>>=20 >>>> if ( !(gstatus & MCG_STATUS_RIPV) && >>>> (!(gstatus & MCG_STATUS_EIPV) || !guest_mode(regs))) =20 >>>> return -1;=20 >>>>=20 >>>=20 >>> That would be overkilled. >>> Considering instruction fetch error occur at guest context, >>> hypervisor deliver to guest to handle the error is perfer, not panic >>> all system.=20 >>=20 >> Even if it was hypervisor code that got prefetched while still >> executing guest code (which ought to be possible at least >> across a syscall/sysenter instruction)? >>=20 >=20 > Executing guest code will not satisfy the check > if ( !(gstatus & MCG_STATUS_RIPV) && !guest_mode(regs)) > return -1; > so it would not panic system. Exactly. But it should when the prefetch was to hypervisor code. Jan _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel From xen-devel-bounces@lists.xensource.com Fri Sep 30 01:54:30 2011 Return-path: <xen-devel-bounces@lists.xensource.com> Envelope-to: www-data@lists.xensource.com Delivery-date: Fri, 30 Sep 2011 01:54:30 -0700 Received: from localhost ([127.0.0.1] helo=lists.colo.xensource.com) by lists.xensource.com with esmtp (Exim 4.43) id 1R9YrW-0003lX-1w; Fri, 30 Sep 2011 01:54:30 -0700 Received: from mail174.messagelabs.com ([85.158.138.51]) by lists.xensource.com with esmtp (Exim 4.43) id 1R9Yr3-0003Z9-Gm for xen-devel@lists.xensource.com; Fri, 30 Sep 2011 01:54:02 -0700 X-Env-Sender: Ian.Jackson@eu.citrix.com X-Msg-Ref: server-3.tower-174.messagelabs.com!1317372838!27281773!1 X-Originating-IP: [62.200.22.115] X-StarScan-Version: 6.4.1; banners=-,-,- X-VirusChecked: Checked Received: (qmail 8952 invoked from network); 30 Sep 2011 08:53:58 -0000 Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115) by server-3.tower-174.messagelabs.com with RC4-SHA encrypted SMTP; 30 Sep 2011 08:53:58 -0000 X-IronPort-AV: E=Sophos;i="4.68,466,1312156800"; d="scan'208";a="8144478" Received: from lonpmailmx01.citrite.net ([10.30.203.162]) by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5; 30 Sep 2011 08:53:58 +0000 Received: from norwich.cam.xci-test.com (10.80.248.129) by smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id 8.3.137.0; Fri, 30 Sep 2011 09:53:58 +0100 Received: from [10.80.248.135] (helo=woking.xci-test.com) by norwich.cam.xci-test.com with esmtp (Exim 4.72) (envelope-from <ian.jackson@eu.citrix.com>) id 1R9Yqz-0004Tv-Kz; Fri, 30 Sep 2011 08:53:57 +0000 Received: from osstest by woking.xci-test.com with local (Exim 4.69) (envelope-from <ian.jackson@eu.citrix.com>) id 1R9Yqz-0004YD-KH; Fri, 30 Sep 2011 09:53:57 +0100 To: <xen-devel@lists.xensource.com> Message-ID: <E1R9Yqz-0004YD-KH@woking.xci-test.com> From: xen.org <ian.jackson@eu.citrix.com> Date: Fri, 30 Sep 2011 09:53:57 +0100 MIME-Version: 1.0 Content-Type: text/plain Cc: ian.jackson@eu.citrix.com, keir@xen.org, stefano.stabellini@eu.citrix.com Subject: [Xen-devel] [xen-unstable bisection] complete test-amd64-amd64-xl-pcipt-intel X-BeenThere: xen-devel@lists.xensource.com X-Mailman-Version: 2.1.5 Precedence: list List-Id: Xen developer discussion <xen-devel.lists.xensource.com> List-Unsubscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe> List-Post: <mailto:xen-devel@lists.xensource.com> List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help> List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=subscribe> Sender: xen-devel-bounces@lists.xensource.com Errors-To: xen-devel-bounces@lists.xensource.com branch xen-unstable xen branch xen-unstable job test-amd64-amd64-xl-pcipt-intel test debian-fixup Tree: linux git://github.com/jsgf/linux-xen.git Tree: qemu git://hg.uk.xensource.com/HG/qemu-xen-unstable.git Tree: xen http://xenbits.xen.org/staging/xen-unstable.hg *** Found and reproduced problem changeset *** Bug is in tree: xen http://xenbits.xen.org/staging/xen-unstable.hg Bug introduced: 5f397994e6d6 Bug not present: 066dc3758fa4 changeset: 23892:5f397994e6d6 user: Anthony PERARD <anthony.perard@citrix.com> date: Thu Sep 29 16:28:24 2011 +0100 libxl: Introduce JSON parser We use the yajl parser, but we need to make a tree from the parse result to use it outside the parser. So this patch include json_object struct that is used to hold the JSON data. Signed-off-by: Anthony PERARD <anthony.perard@citrix.com> Committed-by: Ian Jackson <ian.jackson.citrix.com> Acked-by: Ian Campbell <ian.campbell@citrix.com> For bisection revision-tuple graph see: http://www.chiark.greenend.org.uk/~xensrcts/results/bisect.xen-unstable.test-amd64-amd64-xl-pcipt-intel.debian-fixup.html Revision IDs in each graph node refer, respectively, to the Trees above. ---------------------------------------- Searching for failure / basis pass: 9138 fail [host=gall-mite] / 9118 ok. Failure / basis pass flights: 9138 / 9118 Tree: linux git://github.com/jsgf/linux-xen.git Tree: qemu git://hg.uk.xensource.com/HG/qemu-xen-unstable.git Tree: xen http://xenbits.xen.org/staging/xen-unstable.hg Latest 6bec8b4a4c14095d0b7ce424db9d583c3decae6c cd776ee9408ff127f934a707c1a339ee600bc127 e78cd03b0308 Basis pass 6bec8b4a4c14095d0b7ce424db9d583c3decae6c cd776ee9408ff127f934a707c1a339ee600bc127 7998217630e2 Generating revisions with ./adhoc-revtuple-generator git://github.com/jsgf/linux-xen.git#6bec8b4a4c14095d0b7ce424db9d583c3decae6c-6bec8b4a4c14095d0b7ce424db9d583c3decae6c git://hg.uk.xensource.com/HG/qemu-xen-unstable.git#cd776ee9408ff127f934a707c1a339ee600bc127-cd776ee9408ff127f934a707c1a339ee600bc127 http://xenbits.xen.org/staging/xen-unstable.hg#7998217630e2-e78cd03b0308 pulling from ssh://xen@xenbits.xen.org/HG/staging/xen-unstable.hg searching for changes no changes found pulling from ssh://xen@xenbits.xen.org/HG/staging/xen-unstable.hg searching for changes no changes found Loaded 265 nodes in revision graph Searching for test results: 9113 pass 6bec8b4a4c14095d0b7ce424db9d583c3decae6c cd776ee9408ff127f934a707c1a339ee600bc127 7998217630e2 9115 pass 6bec8b4a4c14095d0b7ce424db9d583c3decae6c cd776ee9408ff127f934a707c1a339ee600bc127 7998217630e2 9118 pass 6bec8b4a4c14095d0b7ce424db9d583c3decae6c cd776ee9408ff127f934a707c1a339ee600bc127 7998217630e2 9119 fail 6bec8b4a4c14095d0b7ce424db9d583c3decae6c cd776ee9408ff127f934a707c1a339ee600bc127 e78cd03b0308 9120 pass 6bec8b4a4c14095d0b7ce424db9d583c3decae6c cd776ee9408ff127f934a707c1a339ee600bc127 7998217630e2 9121 [] 9122 fail 6bec8b4a4c14095d0b7ce424db9d583c3decae6c cd776ee9408ff127f934a707c1a339ee600bc127 e78cd03b0308 9138 fail 6bec8b4a4c14095d0b7ce424db9d583c3decae6c cd776ee9408ff127f934a707c1a339ee600bc127 e78cd03b0308 9150 pass 6bec8b4a4c14095d0b7ce424db9d583c3decae6c cd776ee9408ff127f934a707c1a339ee600bc127 f5ee5ad45425 9151 pass 6bec8b4a4c14095d0b7ce424db9d583c3decae6c cd776ee9408ff127f934a707c1a339ee600bc127 066dc3758fa4 9152 fail 6bec8b4a4c14095d0b7ce424db9d583c3decae6c cd776ee9408ff127f934a707c1a339ee600bc127 5f397994e6d6 9153 pass 6bec8b4a4c14095d0b7ce424db9d583c3decae6c cd776ee9408ff127f934a707c1a339ee600bc127 066dc3758fa4 9154 fail 6bec8b4a4c14095d0b7ce424db9d583c3decae6c cd776ee9408ff127f934a707c1a339ee600bc127 5f397994e6d6 9155 pass 6bec8b4a4c14095d0b7ce424db9d583c3decae6c cd776ee9408ff127f934a707c1a339ee600bc127 066dc3758fa4 9156 fail 6bec8b4a4c14095d0b7ce424db9d583c3decae6c cd776ee9408ff127f934a707c1a339ee600bc127 5f397994e6d6 Searching for interesting versions Result found: flight 9113 (pass), for basis pass Result found: flight 9119 (fail), for basis failure Repro found: flight 9120 (pass), for basis pass Repro found: flight 9122 (fail), for basis failure 0 revisions at 6bec8b4a4c14095d0b7ce424db9d583c3decae6c cd776ee9408ff127f934a707c1a339ee600bc127 066dc3758fa4 No revisions left to test, checking graph state. Result found: flight 9151 (pass), for last pass Result found: flight 9152 (fail), for first failure Repro found: flight 9153 (pass), for last pass Repro found: flight 9154 (fail), for first failure Repro found: flight 9155 (pass), for last pass Repro found: flight 9156 (fail), for first failure *** Found and reproduced problem changeset *** Bug is in tree: xen http://xenbits.xen.org/staging/xen-unstable.hg Bug introduced: 5f397994e6d6 Bug not present: 066dc3758fa4 pulling from ssh://xen@xenbits.xen.org/HG/staging/xen-unstable.hg searching for changes no changes found changeset: 23892:5f397994e6d6 user: Anthony PERARD <anthony.perard@citrix.com> date: Thu Sep 29 16:28:24 2011 +0100 libxl: Introduce JSON parser We use the yajl parser, but we need to make a tree from the parse result to use it outside the parser. So this patch include json_object struct that is used to hold the JSON data. Signed-off-by: Anthony PERARD <anthony.perard@citrix.com> Committed-by: Ian Jackson <ian.jackson.citrix.com> Acked-by: Ian Campbell <ian.campbell@citrix.com> Revision graph left in /home/xc_osstest/results/bisect.xen-unstable.test-amd64-amd64-xl-pcipt-intel.debian-fixup.{dot,ps,png,html}. ---------------------------------------- 9156: ALL FAIL flight 9156 xen-unstable real-bisect [real] http://www.chiark.greenend.org.uk/~xensrcts/logs/9156/ jobs: test-amd64-amd64-xl-pcipt-intel fail ------------------------------------------------------------ sg-report-flight on woking.cam.xci-test.com logs: /home/xc_osstest/logs images: /home/xc_osstest/images Logs, config files, etc. are available at http://www.chiark.greenend.org.uk/~xensrcts/logs Test harness code can be found at http://xenbits.xensource.com/gitweb?p=osstest.git;a=summary _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel From xen-devel-bounces@lists.xensource.com Fri Sep 30 02:09:29 2011 Return-path: <xen-devel-bounces@lists.xensource.com> Envelope-to: www-data@lists.xensource.com Delivery-date: Fri, 30 Sep 2011 02:09:29 -0700 Received: from localhost ([127.0.0.1] helo=lists.colo.xensource.com) by lists.xensource.com with esmtp (Exim 4.43) id 1R9Z60-0004Nl-1n; Fri, 30 Sep 2011 02:09:28 -0700 Received: from mail216.messagelabs.com ([85.158.143.99]) by lists.xensource.com with esmtp (Exim 4.43) id 1R9Z4p-0004Ar-TA for xen-devel@lists.xensource.com; Fri, 30 Sep 2011 02:08:24 -0700 X-Env-Sender: Ian.Campbell@eu.citrix.com X-Msg-Ref: server-10.tower-216.messagelabs.com!1317373692!10343761!1 X-Originating-IP: [62.200.22.115] X-StarScan-Version: 6.4.1; banners=-,-,- X-VirusChecked: Checked Received: (qmail 2377 invoked from network); 30 Sep 2011 09:08:13 -0000 Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115) by server-10.tower-216.messagelabs.com with RC4-SHA encrypted SMTP; 30 Sep 2011 09:08:13 -0000 X-IronPort-AV: E=Sophos;i="4.68,466,1312156800"; d="scan'208";a="8144840" Received: from lonpmailmx01.citrite.net ([10.30.203.162]) by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5; 30 Sep 2011 09:08:12 +0000 Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net (10.30.203.162) with Microsoft SMTP Server id 8.3.137.0; Fri, 30 Sep 2011 10:08:13 +0100 Subject: Re: [Xen-devel] [xen-unstable bisection] complete test-amd64-amd64-xl-pcipt-intel From: Ian Campbell <Ian.Campbell@citrix.com> To: xen.org <ian.jackson@eu.citrix.com> Date: Fri, 30 Sep 2011 10:08:12 +0100 In-Reply-To: <E1R9Yqz-0004YD-KH@woking.xci-test.com> References: <E1R9Yqz-0004YD-KH@woking.xci-test.com> Organization: Citrix Systems, Inc. Content-Type: text/plain; charset="UTF-8" X-Mailer: Evolution 3.0.3- Content-Transfer-Encoding: 7bit Message-ID: <1317373692.26672.245.camel@zakaz.uk.xensource.com> MIME-Version: 1.0 Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>, "keir@xen.org" <keir@xen.org>, Stefano Stabellini <Stefano.Stabellini@eu.citrix.com> X-BeenThere: xen-devel@lists.xensource.com X-Mailman-Version: 2.1.5 Precedence: list List-Id: Xen developer discussion <xen-devel.lists.xensource.com> List-Unsubscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe> List-Post: <mailto:xen-devel@lists.xensource.com> List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help> List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=subscribe> Sender: xen-devel-bounces@lists.xensource.com Errors-To: xen-devel-bounces@lists.xensource.com On Fri, 2011-09-30 at 09:53 +0100, xen.org wrote: > branch xen-unstable > xen branch xen-unstable > job test-amd64-amd64-xl-pcipt-intel > test debian-fixup > > Tree: linux git://github.com/jsgf/linux-xen.git > Tree: qemu git://hg.uk.xensource.com/HG/qemu-xen-unstable.git > Tree: xen http://xenbits.xen.org/staging/xen-unstable.hg > > *** Found and reproduced problem changeset *** > > Bug is in tree: xen http://xenbits.xen.org/staging/xen-unstable.hg > Bug introduced: 5f397994e6d6 > Bug not present: 066dc3758fa4 > > > changeset: 23892:5f397994e6d6 > user: Anthony PERARD <anthony.perard@citrix.com> > date: Thu Sep 29 16:28:24 2011 +0100 > > libxl: Introduce JSON parser > > We use the yajl parser, but we need to make a tree from the parse result > to use it outside the parser. > > So this patch include json_object struct that is used to hold the JSON > data. > > Signed-off-by: Anthony PERARD <anthony.perard@citrix.com> > Committed-by: Ian Jackson <ian.jackson.citrix.com> > Acked-by: Ian Campbell <ian.campbell@citrix.com> Due to: xl: error while loading shared libraries: libyajl.so.1: cannot open shared object file: No such file or directory The Debian package "libyajl1" is now required at runtime, I guess the build machine has libyajl-dev on it already or the build would have failed instead. Ian. > > > > > For bisection revision-tuple graph see: > http://www.chiark.greenend.org.uk/~xensrcts/results/bisect.xen-unstable.test-amd64-amd64-xl-pcipt-intel.debian-fixup.html > Revision IDs in each graph node refer, respectively, to the Trees above. > > ---------------------------------------- > Searching for failure / basis pass: > 9138 fail [host=gall-mite] / 9118 ok. > Failure / basis pass flights: 9138 / 9118 > Tree: linux git://github.com/jsgf/linux-xen.git > Tree: qemu git://hg.uk.xensource.com/HG/qemu-xen-unstable.git > Tree: xen http://xenbits.xen.org/staging/xen-unstable.hg > Latest 6bec8b4a4c14095d0b7ce424db9d583c3decae6c cd776ee9408ff127f934a707c1a339ee600bc127 e78cd03b0308 > Basis pass 6bec8b4a4c14095d0b7ce424db9d583c3decae6c cd776ee9408ff127f934a707c1a339ee600bc127 7998217630e2 > Generating revisions with ./adhoc-revtuple-generator git://github.com/jsgf/linux-xen.git#6bec8b4a4c14095d0b7ce424db9d583c3decae6c-6bec8b4a4c14095d0b7ce424db9d583c3decae6c git://hg.uk.xensource.com/HG/qemu-xen-unstable.git#cd776ee9408ff127f934a707c1a339ee600bc127-cd776ee9408ff127f934a707c1a339ee600bc127 http://xenbits.xen.org/staging/xen-unstable.hg#7998217630e2-e78cd03b0308 > pulling from ssh://xen@xenbits.xen.org/HG/staging/xen-unstable.hg > searching for changes > no changes found > pulling from ssh://xen@xenbits.xen.org/HG/staging/xen-unstable.hg > searching for changes > no changes found > Loaded 265 nodes in revision graph > Searching for test results: > 9113 pass 6bec8b4a4c14095d0b7ce424db9d583c3decae6c cd776ee9408ff127f934a707c1a339ee600bc127 7998217630e2 > 9115 pass 6bec8b4a4c14095d0b7ce424db9d583c3decae6c cd776ee9408ff127f934a707c1a339ee600bc127 7998217630e2 > 9118 pass 6bec8b4a4c14095d0b7ce424db9d583c3decae6c cd776ee9408ff127f934a707c1a339ee600bc127 7998217630e2 > 9119 fail 6bec8b4a4c14095d0b7ce424db9d583c3decae6c cd776ee9408ff127f934a707c1a339ee600bc127 e78cd03b0308 > 9120 pass 6bec8b4a4c14095d0b7ce424db9d583c3decae6c cd776ee9408ff127f934a707c1a339ee600bc127 7998217630e2 > 9121 [] > 9122 fail 6bec8b4a4c14095d0b7ce424db9d583c3decae6c cd776ee9408ff127f934a707c1a339ee600bc127 e78cd03b0308 > 9138 fail 6bec8b4a4c14095d0b7ce424db9d583c3decae6c cd776ee9408ff127f934a707c1a339ee600bc127 e78cd03b0308 > 9150 pass 6bec8b4a4c14095d0b7ce424db9d583c3decae6c cd776ee9408ff127f934a707c1a339ee600bc127 f5ee5ad45425 > 9151 pass 6bec8b4a4c14095d0b7ce424db9d583c3decae6c cd776ee9408ff127f934a707c1a339ee600bc127 066dc3758fa4 > 9152 fail 6bec8b4a4c14095d0b7ce424db9d583c3decae6c cd776ee9408ff127f934a707c1a339ee600bc127 5f397994e6d6 > 9153 pass 6bec8b4a4c14095d0b7ce424db9d583c3decae6c cd776ee9408ff127f934a707c1a339ee600bc127 066dc3758fa4 > 9154 fail 6bec8b4a4c14095d0b7ce424db9d583c3decae6c cd776ee9408ff127f934a707c1a339ee600bc127 5f397994e6d6 > 9155 pass 6bec8b4a4c14095d0b7ce424db9d583c3decae6c cd776ee9408ff127f934a707c1a339ee600bc127 066dc3758fa4 > 9156 fail 6bec8b4a4c14095d0b7ce424db9d583c3decae6c cd776ee9408ff127f934a707c1a339ee600bc127 5f397994e6d6 > Searching for interesting versions > Result found: flight 9113 (pass), for basis pass > Result found: flight 9119 (fail), for basis failure > Repro found: flight 9120 (pass), for basis pass > Repro found: flight 9122 (fail), for basis failure > 0 revisions at 6bec8b4a4c14095d0b7ce424db9d583c3decae6c cd776ee9408ff127f934a707c1a339ee600bc127 066dc3758fa4 > No revisions left to test, checking graph state. > Result found: flight 9151 (pass), for last pass > Result found: flight 9152 (fail), for first failure > Repro found: flight 9153 (pass), for last pass > Repro found: flight 9154 (fail), for first failure > Repro found: flight 9155 (pass), for last pass > Repro found: flight 9156 (fail), for first failure > > *** Found and reproduced problem changeset *** > > Bug is in tree: xen http://xenbits.xen.org/staging/xen-unstable.hg > Bug introduced: 5f397994e6d6 > Bug not present: 066dc3758fa4 > > pulling from ssh://xen@xenbits.xen.org/HG/staging/xen-unstable.hg > searching for changes > no changes found > > changeset: 23892:5f397994e6d6 > user: Anthony PERARD <anthony.perard@citrix.com> > date: Thu Sep 29 16:28:24 2011 +0100 > > libxl: Introduce JSON parser > > We use the yajl parser, but we need to make a tree from the parse result > to use it outside the parser. > > So this patch include json_object struct that is used to hold the JSON > data. > > Signed-off-by: Anthony PERARD <anthony.perard@citrix.com> > Committed-by: Ian Jackson <ian.jackson.citrix.com> > Acked-by: Ian Campbell <ian.campbell@citrix.com> > > > > Revision graph left in /home/xc_osstest/results/bisect.xen-unstable.test-amd64-amd64-xl-pcipt-intel.debian-fixup.{dot,ps,png,html}. > ---------------------------------------- > 9156: ALL FAIL > > flight 9156 xen-unstable real-bisect [real] > http://www.chiark.greenend.org.uk/~xensrcts/logs/9156/ > > > jobs: > test-amd64-amd64-xl-pcipt-intel fail > > > ------------------------------------------------------------ > sg-report-flight on woking.cam.xci-test.com > logs: /home/xc_osstest/logs > images: /home/xc_osstest/images > > Logs, config files, etc. are available at > http://www.chiark.greenend.org.uk/~xensrcts/logs > > Test harness code can be found at > http://xenbits.xensource.com/gitweb?p=osstest.git;a=summary > > > _______________________________________________ > Xen-devel mailing list > Xen-devel@lists.xensource.com > http://lists.xensource.com/xen-devel _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel From xen-devel-bounces@lists.xensource.com Fri Sep 30 02:14:13 2011 Return-path: <xen-devel-bounces@lists.xensource.com> Envelope-to: www-data@lists.xensource.com Delivery-date: Fri, 30 Sep 2011 02:14:13 -0700 Received: from localhost ([127.0.0.1] helo=lists.colo.xensource.com) by lists.xensource.com with esmtp (Exim 4.43) id 1R9ZAb-0004tu-Nd; Fri, 30 Sep 2011 02:14:13 -0700 Received: from mail216.messagelabs.com ([85.158.143.99]) by lists.xensource.com with smtp (Exim 4.43) id 1R9ZA1-0004gp-J2 for xen-devel@lists.xensource.com; Fri, 30 Sep 2011 02:13:38 -0700 X-Env-Sender: stefan.bader@canonical.com X-Msg-Ref: server-14.tower-216.messagelabs.com!1317374014!20111517!1 X-Originating-IP: [91.189.89.112] X-StarScan-Version: 6.4.1; banners=-,-,- X-VirusChecked: Checked Received: (qmail 2532 invoked from network); 30 Sep 2011 09:13:34 -0000 Received: from youngberry.canonical.com (HELO youngberry.canonical.com) (91.189.89.112) by server-14.tower-216.messagelabs.com with SMTP; 30 Sep 2011 09:13:34 -0000 Received: from p5b2e4fdc.dip.t-dialin.net ([91.46.79.220] helo=[192.168.2.5]) by youngberry.canonical.com with esmtpsa (TLS1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.71) (envelope-from <stefan.bader@canonical.com>) id 1R9Z9y-0005hk-0n; Fri, 30 Sep 2011 09:13:34 +0000 Message-ID: <4E85883C.7030808@canonical.com> Date: Fri, 30 Sep 2011 11:13:32 +0200 From: Stefan Bader <stefan.bader@canonical.com> User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.2.23) Gecko/20110922 Lightning/1.0b2 Thunderbird/3.1.15 MIME-Version: 1.0 To: Stefano Stabellini <stefano.stabellini@eu.citrix.com> Subject: Re: [Xen-devel] Re: Still struggling with HVM: tx timeouts on emulated nics References: <4E7B4768.8060103@canonical.com> <alpine.DEB.2.00.1109221838370.8700@kaball-desktop> In-Reply-To: <alpine.DEB.2.00.1109221838370.8700@kaball-desktop> X-Enigmail-Version: 1.1.2 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: xen-devel@lists.xensource.com X-BeenThere: xen-devel@lists.xensource.com X-Mailman-Version: 2.1.5 Precedence: list List-Id: Xen developer discussion <xen-devel.lists.xensource.com> List-Unsubscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe> List-Post: <mailto:xen-devel@lists.xensource.com> List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help> List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=subscribe> Sender: xen-devel-bounces@lists.xensource.com Errors-To: xen-devel-bounces@lists.xensource.com On 22.09.2011 19:44, Stefano Stabellini wrote: > On Thu, 22 Sep 2011, Stefan Bader wrote: >> On 22.09.2011 13:58, Stefan Bader wrote: >>> On 22.09.2011 12:30, Stefano Stabellini wrote: >>>> On Wed, 21 Sep 2011, Stefan Bader wrote: >>>>> On 21.09.2011 15:31, Stefano Stabellini wrote: >>>>>> On Wed, 21 Sep 2011, Stefan Bader wrote: >>>>>>> This is on 3.0.4 based dom0 and domU with 4.1.1 hypervisor. I tried using the >>>>>>> default 8139cp and ne2k_pci emulated nic. The 8139cp one at least comes up and >>>>>>> gets configured via dhcp. And initial pings also get routed and done correctly. >>>>>>> But slightly higher traffic (like checking for updates) hangs. And after a while >>>>>>> there are messages about tx timeouts. >>>>>>> The ne2k_pci type nic almost immediately has those issues and never comes up >>>>>>> correctly. >>>>>>> >>>>>>> I am attaching the dmesg of the guest with apic=debug enabled. I am not sure how >>>>>>> this should be but both nics get configured with level,low IRQs. Disk emulation >>>>>>> seems to be ok but that seem to use IO-APIC-edge. And any other IRQs seem to be >>>>>>> at least not level. >>>>>> >>>>> >>>>>> Does the e1000 emulated card work correctly? >>>>> >>>>> Yes, that one seems to work ok. >>>>> >>>>>> What happens if you disable interrupt remapping (see patch below)? >>>>> >>>>> 8139cp seems to work correctly now (much higher irq stats as well) and e1000 >>>>> still works. Both then using IOAPIC-fasteoi. >>>>> >>>> >>>> That means there must be another subtle bug in Xen in interrupt >>>> remapping that only affects 8139p emulation >>>> >>> Right, or to be complete: >>> - e1000: ok >>> - 8139cp: unstable (setup is possible) >>> - ne2k_pci: not working (tx problems from the beginning) >>> >>> The behaviour feels a bit like interrupts may get lost if occurring at a higher >>> rate. Why this affects various drivers differently is a bit weird. >>>> >> >> This is mainly speculating... Quite a while back there was this patch to events: >> >> commit dffe2e1e1a1ddb566a76266136c312801c66dcf7 >> Author: Jeremy Fitzhardinge <jeremy.fitzhardinge@citrix.com> >> Date: Fri Aug 20 19:10:01 2010 -0700 >> >> xen: handle events as edge-triggered >> >> The commit message stated that Xen events are logically edge triggered. So PV >> events were changed to be handled as edge interrupts. Would that not mean that >> for xen-pirq-apic being using events this would apply the same and those should >> be apic-edge instead of level? > > That commit is referring to the internal way Linux handles these event, > that look like normal interrupt to the Linux irq subsystem. It is not > related to the way actual events are delivered from Xen to Linux, so it > shouldn't matter here. > > I would add lots of printk's in: > > xen/arch/x86/hvm/irq.c:__hvm_pci_intx_assert > xen/arch/x86/hvm/irq.c:assert_irq > xen/arch/x86/hvm/irq.c:assert_gsi > > to find out why xen is not injecting those interrupts > > _______________________________________________ > Xen-devel mailing list > Xen-devel@lists.xensource.com > http://lists.xensource.com/xen-devel It took quite a bit of time but at least I got some hopefully useful information now. So in general, whenever an interrupt is asserted, the hypervisor runs through this: __hvm_pci_intx_assert: when assert count was 0 before incrementing call assert_gsi call send_guest_pirq (when hvm uses pirq) In the send_guest_pirq chain is a call to evtchn_set_pending which tests as one of the first actions whether evtchn_pending in the shared_info is set. If that is the case the call immediately returns with 1. Adding printks to call_assert_gsi, I noticed that - When things stop working, the last call to send_guest_pirq returned 1. - But not every time the return code is one, the stall happens. - e1000 also has cases where send_guest_pirq returns 1 but they happen much less often (than using the 8139cp). Usually every intx_assert has a intx_deassert call that follows. when the stall occurs, this does not happen. Right here I got some troubles to understand where this intx_deassert is actually triggered. With an added WARN_ON the stack traces seem odd, like this: (XEN) [<ffff82c4801abd9c>] __hvm_pci_intx_deassert+0x6c/0x130 (XEN) [<ffff82c4801ac43e>] hvm_pci_intx_deassert+0x3e/0x60 (XEN) [<ffff82c4801a8148>] do_hvm_op+0x3b8/0x1e60 (XEN) [<ffff82c480168ea1>] do_update_descriptor+0x171/0x220 (XEN) [<ffff82c48017dba6>] copy_from_user+0x26/0x90 (XEN) [<ffff82c4801f9446>] do_iret+0xb6/0x1a0 (XEN) [<ffff82c4801f4f28>] syscall_enter+0x88/0x8d Not really sure how one gets from do_update_descriptor to do_hvm_op and the only thing in there which does the deassert is some irq level setting. Actually the guest does not really do much do EOI (which I had been assuming). But since domain_pirq_to_irq maps to 0 for emuirqs, the call to PHYSDEVOP_irq_status_query will hit the following and not set the flag for needing EOI. irq_status_query.flags = 0; if ( is_hvm_domain(v->domain) && domain_pirq_to_irq(v->domain, irq) <= 0 ) { ret = copy_to_guest(arg, &irq_status_query, 1) ? -EFAULT : 0; break; } So all the guest is doing is to clear evtchn_pending in the pirq EOI function. I fail to understand what actually is doing the hvm_pci_intx_deassert calls but the way the fasteoi code in the guest looks to be working, there seems to be some gap between calling the handler and the eoi function... So from what I see, I would assume the following: dom0 domU - intx_assert (count 0->1) - send_guest_pirq = 0 (evtchn_pending = 1) - upcall starts fasteoi handler - something does intx_deassert (count 1->0) - intx_assert (count 0->1) - send_guest_pirq = 1 (evtchn_pending still set) - handler->eoi sets evtchn to 0 but otherwise does nothing - there is no intx_deassert, so even when another intx_assert would happen (which does not seem to be the case) no further send_guest_pirq would be called. Unfortunately I do miss some details on the inner working here. Generally I wonder whether not setting the needsEOI flag for those pirqs just is the problem. But it also could be intentional... -Stefan _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel From xen-devel-bounces@lists.xensource.com Fri Sep 30 02:17:16 2011 Return-path: <xen-devel-bounces@lists.xensource.com> Envelope-to: www-data@lists.xensource.com Delivery-date: Fri, 30 Sep 2011 02:17:16 -0700 Received: from localhost ([127.0.0.1] helo=lists.colo.xensource.com) by lists.xensource.com with esmtp (Exim 4.43) id 1R9ZDY-0005Iq-N1; Fri, 30 Sep 2011 02:17:16 -0700 Received: from mail174.messagelabs.com ([85.158.138.51]) by lists.xensource.com with esmtp (Exim 4.43) id 1R9ZD3-00056R-9h for xen-devel@lists.xensource.com; Fri, 30 Sep 2011 02:16:45 -0700 X-Env-Sender: Ian.Campbell@eu.citrix.com X-Msg-Ref: server-3.tower-174.messagelabs.com!1317374202!27285701!1 X-Originating-IP: [62.200.22.115] X-StarScan-Version: 6.4.1; banners=-,-,- X-VirusChecked: Checked Received: (qmail 26595 invoked from network); 30 Sep 2011 09:16:42 -0000 Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115) by server-3.tower-174.messagelabs.com with RC4-SHA encrypted SMTP; 30 Sep 2011 09:16:42 -0000 X-IronPort-AV: E=Sophos;i="4.68,466,1312156800"; d="scan'208";a="8145095" Received: from lonpmailmx01.citrite.net ([10.30.203.162]) by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5; 30 Sep 2011 09:16:14 +0000 Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net (10.30.203.162) with Microsoft SMTP Server id 8.3.137.0; Fri, 30 Sep 2011 10:16:14 +0100 From: Ian Campbell <Ian.Campbell@eu.citrix.com> To: Daniel De Graaf <dgdegra@tycho.nsa.gov> Date: Fri, 30 Sep 2011 10:16:14 +0100 In-Reply-To: <1316729665-15004-2-git-send-email-dgdegra@tycho.nsa.gov> References: <1313764724-12683-1-git-send-email-dgdegra@tycho.nsa.gov> <1316729665-15004-1-git-send-email-dgdegra@tycho.nsa.gov> <1316729665-15004-2-git-send-email-dgdegra@tycho.nsa.gov> Organization: Citrix Systems, Inc. Content-Type: text/plain; charset="UTF-8" X-Mailer: Evolution 3.0.3- Content-Transfer-Encoding: 7bit Message-ID: <1317374174.26672.249.camel@zakaz.uk.xensource.com> MIME-Version: 1.0 Cc: Stefano Stabellini <Stefano.Stabellini@eu.citrix.com>, "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>, Ian Jackson <Ian.Jackson@eu.citrix.com>, "konrad.wilk@oracle.com" <konrad.wilk@oracle.com> Subject: [Xen-devel] Re: [PATCH 1/3] libxc: add xc_gnttab_map_grant_ref_notify X-BeenThere: xen-devel@lists.xensource.com X-Mailman-Version: 2.1.5 Precedence: list List-Id: Xen developer discussion <xen-devel.lists.xensource.com> List-Unsubscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe> List-Post: <mailto:xen-devel@lists.xensource.com> List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help> List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=subscribe> Sender: xen-devel-bounces@lists.xensource.com Errors-To: xen-devel-bounces@lists.xensource.com On Thu, 2011-09-22 at 23:14 +0100, Daniel De Graaf wrote: > diff --git a/tools/libxc/xenctrlosdep.h b/tools/libxc/xenctrlosdep.h > index bfe46e0..1c6317e 100644 > --- a/tools/libxc/xenctrlosdep.h > +++ b/tools/libxc/xenctrlosdep.h > @@ -105,20 +105,12 @@ struct xc_osdep_ops > int (*unmask)(xc_evtchn *xce, xc_osdep_handle h, evtchn_port_t port); > } evtchn; > struct { > - void *(*map_grant_ref)(xc_gnttab *xcg, xc_osdep_handle h, > - uint32_t domid, > - uint32_t ref, > - int prot); > - void *(*map_grant_refs)(xc_gnttab *xcg, xc_osdep_handle h, > - uint32_t count, > - uint32_t *domids, > - uint32_t *refs, > - int prot); > - void *(*map_domain_grant_refs)(xc_gnttab *xcg, xc_osdep_handle h, > - uint32_t count, > - uint32_t domid, > - uint32_t *refs, > - int prot); > +#define XC_GRANT_MAP_SINGLE_DOMAIN 0x1 > + void *(*grant_map)(xc_gnttab *xcg, xc_osdep_handle h, > + uint32_t count, int flags, int prot, > + uint32_t *domids, uint32_t *refs, > + uint32_t notify_offset, > + evtchn_port_t notify_port); > int (*munmap)(xc_gnttab *xcg, xc_osdep_handle h, > void *start_address, > uint32_t count); Not specifically to do with this patch but I wonder if we should try and figure a way to version these shared libraries somehow, otherwise changes like this lead to segfault at best and unexpected non-crashing behaviour at worst (for out of tree backends that is). Something as simple as checksumming the xenctrlosdep.h header and including the value in the .so to be checked at load time would do the trick. Ian. _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel From xen-devel-bounces@lists.xensource.com Fri Sep 30 02:19:08 2011 Return-path: <xen-devel-bounces@lists.xensource.com> Envelope-to: www-data@lists.xensource.com Delivery-date: Fri, 30 Sep 2011 02:19:08 -0700 Received: from localhost ([127.0.0.1] helo=lists.colo.xensource.com) by lists.xensource.com with esmtp (Exim 4.43) id 1R9ZFM-0005gg-G7; Fri, 30 Sep 2011 02:19:08 -0700 Received: from mail174.messagelabs.com ([85.158.138.51]) by lists.xensource.com with smtp (Exim 4.43) id 1R9ZDj-0005Kn-9V for xen-devel@lists.xensource.com; Fri, 30 Sep 2011 02:17:28 -0700 X-Env-Sender: ml-xen-devel@hfp.de X-Msg-Ref: server-15.tower-174.messagelabs.com!1317374244!27000159!1 X-Originating-IP: [88.205.101.6] X-StarScan-Version: 6.4.1; banners=-,-,- X-VirusChecked: Checked Received: (qmail 13535 invoked from network); 30 Sep 2011 09:17:24 -0000 Received: from rootsrv.hfp.de (HELO rootsrv.hfp.de) (88.205.101.6) by server-15.tower-174.messagelabs.com with SMTP; 30 Sep 2011 09:17:24 -0000 Received: from localhost (localhost [127.0.0.1]) by rootsrv.hfp.de (Postfix) with ESMTP id 166811A910C; Fri, 30 Sep 2011 11:17:23 +0200 (CEST) X-Virus-Scanned: amavisd-new/ClamAV at rootsrv.hfp.de Received: from rootsrv.hfp.de ([127.0.0.1]) by localhost (rootsrv.hfp.de [127.0.0.1]) (amavisd-new, port 10026) with ESMTP id LkweQXP0PZM8; Fri, 30 Sep 2011 11:17:23 +0200 (CEST) Received: from [10.0.0.1] (p5DCB6E76.dip.t-dialin.net [93.203.110.118]) by rootsrv.hfp.de (Postfix) with ESMTPA; Fri, 30 Sep 2011 11:17:22 +0200 (CEST) Message-ID: <4E858925.6090903@hfp.de> Date: Fri, 30 Sep 2011 11:17:25 +0200 From: Andreas Kinzler <ml-xen-devel@hfp.de> User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:6.0.2) Gecko/20110902 Thunderbird/6.0.2 MIME-Version: 1.0 To: James Harper <james.harper@bendigoit.com.au> Subject: Re: [Xen-devel] RE: Stability report GPLPV 0.11.0.308 References: <4E64A0DF.2070007@hfp.de> <AEC6C66638C05B468B556EA548C1A77D01E5DB8C@trantor> <4E64D569.5030607@hfp.de> <AEC6C66638C05B468B556EA548C1A77D01E5DBBF@trantor> <4E7728F9.9020208@hfp.de> <AEC6C66638C05B468B556EA548C1A77D01E5E008@trantor> <4E7B04A4.9070601@hfp.de> <AEC6C66638C05B468B556EA548C1A77D01E5E072@trantor> <4E7CF2A8.5040405@hfp.de> <AEC6C66638C05B468B556EA548C1A77D01E5E0D0@trantor> <4E808FE9.5050008@hfp.de> <AEC6C66638C05B468B556EA548C1A77D01E5E190@trantor> In-Reply-To: <AEC6C66638C05B468B556EA548C1A77D01E5E190@trantor> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: xen-devel@lists.xensource.com X-BeenThere: xen-devel@lists.xensource.com X-Mailman-Version: 2.1.5 Precedence: list List-Id: Xen developer discussion <xen-devel.lists.xensource.com> List-Unsubscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe> List-Post: <mailto:xen-devel@lists.xensource.com> List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help> List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=subscribe> Sender: xen-devel-bounces@lists.xensource.com Errors-To: xen-devel-bounces@lists.xensource.com Hello James, > 12961573357740: *** Assertion failed: pi.curr_mdl > 12961573357740: *** Source File: > c:\projects\win-pvdrivers.hg\xennet\xennet6_tx.c, line 308 I took this report about a problem you had with "tx" to modify my tests and to make them mostly tx-based while previously they were mostly rx-based. Tests are running for 2d 18h now - no problems so far. I wanted to tell you about one interesting observation. In my tests I did two runs with modified xenvbd drivers. In run #1 I switched to the scsiport driver of 0.11.0.312 and this made one domU crash after one day while with 0.11.0.312 storport version I always had more than 9 days (as I reported earlier). In run #2 I forward-ported xenvbd from 0.11.0.213 (which is totally stable on our systems) and again one domU crashed after one day. This is really interesting and leads me to two thoughts: 1) xennet has some problem, but still why does scsiport vs. storport make a difference then? 2) perhaps there is some new bug outside xennet and outside xenvbd (some infrastructure thing: event handling, PCI, ...) and this is the real reason. > Can you have a look in your logs for anything like this? I'm curious as > to if we are chasing the same problem or a different one. I am not running kernel debugging so far (have played with it though). So I cannot say. Regards Andreas _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel From xen-devel-bounces@lists.xensource.com Fri Sep 30 02:37:15 2011 Return-path: <xen-devel-bounces@lists.xensource.com> Envelope-to: www-data@lists.xensource.com Delivery-date: Fri, 30 Sep 2011 02:37:15 -0700 Received: from localhost ([127.0.0.1] helo=lists.colo.xensource.com) by lists.xensource.com with esmtp (Exim 4.43) id 1R9ZWs-0006aE-Uy; Fri, 30 Sep 2011 02:37:14 -0700 Received: from mail216.messagelabs.com ([85.158.143.99]) by lists.xensource.com with esmtp (Exim 4.43) id 1R9ZW9-0006O1-Sx for xen-devel@lists.xensource.com; Fri, 30 Sep 2011 02:36:30 -0700 X-Env-Sender: tp@turtle-entertainment.de X-Msg-Ref: server-10.tower-216.messagelabs.com!1317375385!10347906!1 X-Originating-IP: [216.139.236.26] X-StarScan-Version: 6.4.1; banners=-,-,- X-VirusChecked: Checked Received: (qmail 21003 invoked from network); 30 Sep 2011 09:36:26 -0000 Received: from sam.nabble.com (HELO sam.nabble.com) (216.139.236.26) by server-10.tower-216.messagelabs.com with AES256-SHA encrypted SMTP; 30 Sep 2011 09:36:26 -0000 Received: from [192.168.236.26] (helo=sam.nabble.com) by sam.nabble.com with esmtp (Exim 4.72) (envelope-from <tp@turtle-entertainment.de>) id 1R9ZW5-0003hB-6L for xen-devel@lists.xensource.com; Fri, 30 Sep 2011 02:36:25 -0700 Date: Fri, 30 Sep 2011 02:36:25 -0700 (PDT) From: tommics <tp@turtle-entertainment.de> To: xen-devel@lists.xensource.com Message-ID: <1317375385187-4856420.post@n5.nabble.com> In-Reply-To: <FF93AF260AC2BB499A119CC65B092CF73114B774@sg000713.corproot.net> References: <AANLkTik3Ng6TpQANfPNJ2M=86WYLHVt7_MuBuVfJ1CG_@mail.gmail.com> <4E6F034B.5040102@bluewin.ch> <CAFLBxZZiGxef5CkH9r+VZeB4h7LPA0nJddumwDRovZaL4zOuvA@mail.gmail.com> <5224b434-5371-404d-8fed-2665e73dacce@default> <CAFLBxZZ3nP5EbtL=Ne-W4DcSWtKGh1XDOs-EhVua7ujmi9Y2Jw@mail.gmail.com> <FF93AF260AC2BB499A119CC65B092CF73114B774@sg000713.corproot.net> MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Subject: [Xen-devel] RE: Xen 4 TSC problems X-BeenThere: xen-devel@lists.xensource.com X-Mailman-Version: 2.1.5 Precedence: list List-Id: Xen developer discussion <xen-devel.lists.xensource.com> List-Unsubscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe> List-Post: <mailto:xen-devel@lists.xensource.com> List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help> List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=subscribe> Sender: xen-devel-bounces@lists.xensource.com Errors-To: xen-devel-bounces@lists.xensource.com Hey there, just wanted to report that we also experience the same problem since upgrading to xen 4.0.1 on debian squeeze. We are running latest debian stable release. ii libxenstore3.0 4.0.1-2 =20 ii linux-image-2.6.32-5-xen-amd64 2.6.32-35squeeze2 ii linux-image-xen-amd64 2.6.32+29 =20 ii xen-hypervisor-4.0-amd64 4.0.1-2 =20 ii xen-linux-system-2.6-xen-amd64 2.6.32+29 =20 ii xen-linux-system-2.6.32-5-xen-amd64 2.6.32-35squeeze2 ii xen-qemu-dm-4.0 4.0.1-2 =20 ii xen-tools 4.2-1 =20 ii xen-utils-4.0 4.0.1-2 =20 ii xen-utils-common 4.0.0-1 =20 ii xenstore-utils 4.0.1-2 =20 We also have the clock jumping 50 minutes into future.=20 We are running IBM Blades HS21 XM (Type 7995) with Intel(R) Xeon(R) CPU E5345 @ 2.33GHz. We are also running the same configuration on another machine with Intel(R) Xeon(R) CPU X7550 @ 2.00GHz where we dont experience this problems. Also w= e didnt had those bugs running xen 3.1.0 with 2.6.18-5-xen-amd64 kernel. We currently running one blade with disabled HPET, clocksoure=3Dpit and cpuidle=3D0 and another with HPET on and nothing else configured. The main problem debugging this, is to wait for the next error to appear. Until now both machines run fine without time jumping, but we did see that time jump on the machine which is running with hpet enabled and no other settings.=20 We could help debugging here. Regards Thomas P=C3=B6hler -- View this message in context: http://xen.1045712.n5.nabble.com/Xen-4-TSC-pr= oblems-tp3396848p4856420.html Sent from the Xen - Dev mailing list archive at Nabble.com. _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel From xen-devel-bounces@lists.xensource.com Fri Sep 30 02:43:27 2011 Return-path: <xen-devel-bounces@lists.xensource.com> Envelope-to: www-data@lists.xensource.com Delivery-date: Fri, 30 Sep 2011 02:43:27 -0700 Received: from localhost ([127.0.0.1] helo=lists.colo.xensource.com) by lists.xensource.com with esmtp (Exim 4.43) id 1R9Zct-00073f-GL; Fri, 30 Sep 2011 02:43:27 -0700 Received: from mail21.messagelabs.com ([85.158.143.35]) by lists.xensource.com with smtp (Exim 4.43) id 1R9ZcO-0006rD-Ru for xen-devel@lists.xensource.com; Fri, 30 Sep 2011 02:42:57 -0700 X-Env-Sender: jinsong.liu@intel.com X-Msg-Ref: server-4.tower-21.messagelabs.com!1317375735!62208724!1 X-Originating-IP: [192.55.52.88] X-StarScan-Version: 6.4.1; banners=-,-,- X-VirusChecked: Checked Received: (qmail 16748 invoked from network); 30 Sep 2011 09:42:16 -0000 Received: from mga01.intel.com (HELO mga01.intel.com) (192.55.52.88) by server-4.tower-21.messagelabs.com with SMTP; 30 Sep 2011 09:42:16 -0000 Received: from fmsmga002.fm.intel.com ([10.253.24.26]) by fmsmga101.fm.intel.com with ESMTP; 30 Sep 2011 02:42:51 -0700 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="4.68,466,1312182000"; d="scan'208";a="72649118" Received: from pgsmsx601.gar.corp.intel.com ([10.221.43.69]) by fmsmga002.fm.intel.com with ESMTP; 30 Sep 2011 02:42:51 -0700 Received: from pgsmsx103.gar.corp.intel.com (10.221.44.82) by pgsmsx601.gar.corp.intel.com (10.221.43.69) with Microsoft SMTP Server (TLS) id 8.2.255.0; Fri, 30 Sep 2011 17:42:50 +0800 Received: from shsmsx601.ccr.corp.intel.com (10.239.4.112) by PGSMSX103.gar.corp.intel.com (10.221.44.82) with Microsoft SMTP Server (TLS) id 14.1.323.3; Fri, 30 Sep 2011 17:42:50 +0800 Received: from shsmsx502.ccr.corp.intel.com ([10.239.4.96]) by shsmsx601.ccr.corp.intel.com ([10.239.4.112]) with mapi; Fri, 30 Sep 2011 17:42:48 +0800 From: "Liu, Jinsong" <jinsong.liu@intel.com> To: Jan Beulich <JBeulich@suse.com>, "Jiang, Yunhong" <yunhong.jiang@intel.com> Date: Fri, 30 Sep 2011 17:42:47 +0800 Subject: RE: [Xen-devel] [PATCH] X86 MCE: Add SRAR handler Thread-Topic: [Xen-devel] [PATCH] X86 MCE: Add SRAR handler Thread-Index: Acx/TTFOrUqSXoHJQ762h6HAOg22dwABrWvw Message-ID: <BC00F5384FCFC9499AF06F92E8B78A9E263B557F7C@shsmsx502.ccr.corp.intel.com> References: <BC00F5384FCFC9499AF06F92E8B78A9E263B557B77@shsmsx502.ccr.corp.intel.com> <4E84ADF70200007800058882@nat28.tlf.novell.com> <789F9655DD1B8F43B48D77C5D306597312D2366A9B@shsmsx501.ccr.corp.intel.com> <4E858AF30200007800058A64@nat28.tlf.novell.com> <BC00F5384FCFC9499AF06F92E8B78A9E263B557F02@shsmsx502.ccr.corp.intel.com> <4E8592A60200007800058AD4@nat28.tlf.novell.com> <BC00F5384FCFC9499AF06F92E8B78A9E263B557F40@shsmsx502.ccr.corp.intel.com> <4E859D7F0200007800058B39@nat28.tlf.novell.com> In-Reply-To: <4E859D7F0200007800058B39@nat28.tlf.novell.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "keir.xen@gmail.com" <keir.xen@gmail.com>, "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com> X-BeenThere: xen-devel@lists.xensource.com X-Mailman-Version: 2.1.5 Precedence: list List-Id: Xen developer discussion <xen-devel.lists.xensource.com> List-Unsubscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe> List-Post: <mailto:xen-devel@lists.xensource.com> List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help> List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=subscribe> Sender: xen-devel-bounces@lists.xensource.com Errors-To: xen-devel-bounces@lists.xensource.com Jan Beulich wrote: >>>> On 30.09.11 at 10:21, "Liu, Jinsong" <jinsong.liu@intel.com> wrote: >> Jan Beulich wrote: >>>>>> On 30.09.11 at 09:44, "Liu, Jinsong" <jinsong.liu@intel.com> >>>>>> wrote:=20 >>>> Jan Beulich wrote: >>>>>>>> On 30.09.11 at 04:51, "Jiang, Yunhong" >>>>>>>> <yunhong.jiang@intel.com> wrote: >>>>>>> This made me look at the current source, and there I see in >>>>>>> mce_urgent_action()=20 >>>>>>>=20 >>>>>>> if ( !(gstatus & MCG_STATUS_RIPV) && !guest_mode(regs)) >>>>>>> return -1;=20 >>>>>>>=20 >>>>>>> which I think should say ... _EIPV and use || instead. Thoughts? >>>>>>=20 >>>>>> I think this code means, if the error happens in hypervisor mode >>>>>> (i.e. !guest_mode()), and RIPV indicate the RIP in stack can't be >>>>>> restarted, we have to panic. >>>>>=20 >>>>> Then the guest_mode() check still lacks an extra check of EIPV, >>>>> like=20 >>>>>=20 >>>>> if ( !(gstatus & MCG_STATUS_RIPV) && >>>>> (!(gstatus & MCG_STATUS_EIPV) || !guest_mode(regs))) >>>>> return -1;=20 >>>>>=20 >>>>=20 >>>> That would be overkilled. >>>> Considering instruction fetch error occur at guest context, >>>> hypervisor deliver to guest to handle the error is perfer, not >>>> panic all system. >>>=20 >>> Even if it was hypervisor code that got prefetched while still >>> executing guest code (which ought to be possible at least >>> across a syscall/sysenter instruction)? >>>=20 >>=20 >> Executing guest code will not satisfy the check >> if ( !(gstatus & MCG_STATUS_RIPV) && !guest_mode(regs)) return -1; >> so it would not panic system. >=20 > Exactly. But it should when the prefetch was to hypervisor code. >=20 Wouldn't processor refresh instruction prefetch queue under such case? Thanks, Jinsong= _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel From xen-devel-bounces@lists.xensource.com Fri Sep 30 03:05:15 2011 Return-path: <xen-devel-bounces@lists.xensource.com> Envelope-to: www-data@lists.xensource.com Delivery-date: Fri, 30 Sep 2011 03:05:15 -0700 Received: from localhost ([127.0.0.1] helo=lists.colo.xensource.com) by lists.xensource.com with esmtp (Exim 4.43) id 1R9Zxz-0007l7-0J; Fri, 30 Sep 2011 03:05:15 -0700 Received: from mail216.messagelabs.com ([85.158.143.99]) by lists.xensource.com with esmtp (Exim 4.43) id 1R9Zsu-0007U9-3J for xen-devel@lists.xensource.com; Fri, 30 Sep 2011 03:00:32 -0700 X-Env-Sender: Ian.Campbell@eu.citrix.com X-Msg-Ref: server-4.tower-216.messagelabs.com!1317376795!20099261!1 X-Originating-IP: [66.165.176.89] X-StarScan-Version: 6.4.1; banners=-,-,- X-VirusChecked: Checked Received: (qmail 30501 invoked from network); 30 Sep 2011 09:59:57 -0000 Received: from smtp.citrix.com (HELO SMTP.CITRIX.COM) (66.165.176.89) by server-4.tower-216.messagelabs.com with RC4-SHA encrypted SMTP; 30 Sep 2011 09:59:57 -0000 X-IronPort-AV: E=Sophos;i="4.68,466,1312171200"; d="scan'208";a="17835204" Received: from ftlpmailmx01.citrite.net ([10.13.107.65]) by FTLPIPO01.CITRIX.COM with ESMTP/TLS/RC4-MD5; 30 Sep 2011 05:59:55 -0400 Received: from smtp01.ad.xensource.com (10.219.128.104) by smtprelay.citrix.com (10.13.107.65) with Microsoft SMTP Server id 8.3.137.0; Fri, 30 Sep 2011 05:59:54 -0400 Received: from cosworth.uk.xensource.com (cosworth.uk.xensource.com [10.80.16.52]) by smtp01.ad.xensource.com (8.13.1/8.13.1) with ESMTP id p8U9xrId028248; Fri, 30 Sep 2011 02:59:54 -0700 Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Mercurial-Node: d546d9dfb9d6f81c97e66a5ef5c6c93aaedbfb06 Message-ID: <d546d9dfb9d6f81c97e6.1317376793@cosworth.uk.xensource.com> User-Agent: Mercurial-patchbomb/1.6.4 Date: Fri, 30 Sep 2011 10:59:53 +0100 From: Ian Campbell <ian.campbell@citrix.com> To: xen-devel@lists.xensource.com Cc: Ian Campbell <ian.campbell@citrix.com> Subject: [Xen-devel] [PATCH] xl: wrap help output if command name is too long X-BeenThere: xen-devel@lists.xensource.com X-Mailman-Version: 2.1.5 Precedence: list List-Id: Xen developer discussion <xen-devel.lists.xensource.com> List-Unsubscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe> List-Post: <mailto:xen-devel@lists.xensource.com> List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help> List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=subscribe> Sender: xen-devel-bounces@lists.xensource.com Errors-To: xen-devel-bounces@lists.xensource.com # HG changeset patch # User Ian Campbell <ian.campbell@citrix.com> # Date 1317376782 -3600 # Node ID d546d9dfb9d6f81c97e66a5ef5c6c93aaedbfb06 # Parent 0b5c45508431906a947ef578e40ebac1ef59d79f xl: wrap help output if command name is too long Without this in the "xl help" line for pci-list-assignable-devices the command name merges with the first word of the help. Since the bash completion support parses "xl help" this leads to "pci-list-assignable-devicesList" being presented as an option instead of the correct command name. We also need to filter out lines which start with more than one space in the bash completion support to stop "List" appearing as a possible command name after the change to wrap it. Doesn't address the fact thatsome help text overflows 80 columns. Signed-off-by: Ian Campbell <ian.campbell@citrix.com> diff -r 0b5c45508431 -r d546d9dfb9d6 tools/libxl/bash-completion --- a/tools/libxl/bash-completion Fri Sep 30 10:53:05 2011 +0100 +++ b/tools/libxl/bash-completion Fri Sep 30 10:59:42 2011 +0100 @@ -11,7 +11,7 @@ _xl() xl=xl if [[ $COMP_CWORD == 1 ]] ; then - opts=`${xl} help 2>/dev/null | sed '1,4d' | awk '{print $1}' | sed 's/$/ ,/g'` && COMPREPLY=( $(compgen -W "${opts}" -- ${cur}) ) + opts=`${xl} help 2>/dev/null | sed '1,4d' | awk '/^ [^ ]/ {print $1}' | sed 's/$/ ,/g'` && COMPREPLY=( $(compgen -W "${opts}" -- ${cur}) ) return 0 fi diff -r 0b5c45508431 -r d546d9dfb9d6 tools/libxl/xl_cmdimpl.c --- a/tools/libxl/xl_cmdimpl.c Fri Sep 30 10:53:05 2011 +0100 +++ b/tools/libxl/xl_cmdimpl.c Fri Sep 30 10:59:42 2011 +0100 @@ -1791,9 +1791,12 @@ void help(const char *command) if (!command || !strcmp(command, "help")) { printf("Usage xl [-vN] <subcommand> [args]\n\n"); printf("xl full list of subcommands:\n\n"); - for (i = 0; i < cmdtable_len; i++) - printf(" %-20s%s\n", - cmd_table[i].cmd_name, cmd_table[i].cmd_desc); + for (i = 0; i < cmdtable_len; i++) { + printf(" %-19s ", cmd_table[i].cmd_name); + if (strlen(cmd_table[i].cmd_name) > 19) + printf("\n %-19s ", ""); + printf("%s\n", cmd_table[i].cmd_desc); + } } else { cmd = cmdtable_lookup(command); if (cmd) { _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel From xen-devel-bounces@lists.xensource.com Fri Sep 30 03:06:58 2011 Return-path: <xen-devel-bounces@lists.xensource.com> Envelope-to: www-data@lists.xensource.com Delivery-date: Fri, 30 Sep 2011 03:06:58 -0700 Received: from localhost ([127.0.0.1] helo=lists.colo.xensource.com) by lists.xensource.com with esmtp (Exim 4.43) id 1R9Zze-00088Q-Js; Fri, 30 Sep 2011 03:06:58 -0700 Received: from mail27.messagelabs.com ([193.109.254.147]) by lists.xensource.com with smtp (Exim 4.43) id 1R9Zsm-0007U5-7Y for xen-devel@lists.xensource.com; Fri, 30 Sep 2011 03:00:32 -0700 X-Env-Sender: stefan.bader@canonical.com X-Msg-Ref: server-2.tower-27.messagelabs.com!1317376761!57094047!1 X-Originating-IP: [91.189.89.112] X-StarScan-Version: 6.4.1; banners=-,-,- X-VirusChecked: Checked Received: (qmail 13750 invoked from network); 30 Sep 2011 09:59:21 -0000 Received: from youngberry.canonical.com (HELO youngberry.canonical.com) (91.189.89.112) by server-2.tower-27.messagelabs.com with SMTP; 30 Sep 2011 09:59:21 -0000 Received: from p5b2e4fdc.dip.t-dialin.net ([91.46.79.220] helo=[192.168.2.5]) by youngberry.canonical.com with esmtpsa (TLS1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.71) (envelope-from <stefan.bader@canonical.com>) id 1R9Zsh-00007g-Ng; Fri, 30 Sep 2011 09:59:47 +0000 Message-ID: <4E859312.40309@canonical.com> Date: Fri, 30 Sep 2011 11:59:46 +0200 From: Stefan Bader <stefan.bader@canonical.com> User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.2.23) Gecko/20110922 Lightning/1.0b2 Thunderbird/3.1.15 MIME-Version: 1.0 To: xen-devel@lists.xensource.com, Konrad Rzeszutek Wilk <konrad.wilk@oracle.com> Subject: Re: [Xen-devel] Is: [PATCH] x86/paravirt: PTE updates in k(un)map_atomic need to be synchronous, regardless of lazy_mmu mode. Was: Re: [PATCH] x86/paravirt: Partially revert "remove lazy mode in interrupts" References: <1317042797-19975-1-git-send-email-konrad.wilk@oracle.com> <4E80A6BD.3070703@goop.org> <20110926193453.GA9717@phenom.oracle.com> In-Reply-To: <20110926193453.GA9717@phenom.oracle.com> X-Enigmail-Version: 1.1.2 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: X-BeenThere: xen-devel@lists.xensource.com X-Mailman-Version: 2.1.5 Precedence: list List-Id: Xen developer discussion <xen-devel.lists.xensource.com> List-Unsubscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe> List-Post: <mailto:xen-devel@lists.xensource.com> List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help> List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=subscribe> Sender: xen-devel-bounces@lists.xensource.com Errors-To: xen-devel-bounces@lists.xensource.com On 26.09.2011 21:34, Konrad Rzeszutek Wilk wrote: > On Mon, Sep 26, 2011 at 09:22:21AM -0700, Jeremy Fitzhardinge wrote: >> On 09/26/2011 06:13 AM, Konrad Rzeszutek Wilk wrote: >>> which has git commit b8bcfe997e46150fedcc3f5b26b846400122fdd9. >>> >>> The unintended consequence of removing the flushing of MMU >>> updates when doing kmap_atomic (or kunmap_atomic) is that we can >>> hit a dereference bug when processing a "fork()" under a heavy loaded >>> machine. Specifically we can hit: >> >> The patch is all OK, but I wouldn't have headlined it as a "partial >> revert" - the important point is that the pte updates in k(un)map_atomic >> need to be synchronous, regardless of whether we're in lazy_mmu mode. >> >> The fact that b8bcfe997e4 introduced the problem is interesting to note, >> but only somewhat relevant to the analysis of what's being fixed here. > > Good point. How about > Limiting the cc's for just asking about status... >>From 09966678dd645b68a422c9bf0223b13e73387302 Mon Sep 17 00:00:00 2001 > From: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com> > Date: Fri, 23 Sep 2011 17:02:29 -0400 > Subject: [PATCH] x86/paravirt: PTE updates in k(un)map_atomic need to be synchronous, regardless of lazy_mmu mode. > > This patch fixes an outstanding issue that has been reported since 2.6.37. > Under a heavy loaded machine processing "fork()" calls could keepover with: > I wonder whether this may have some effect on older kernels too. According to git the patch that removed the lines that are added back happened in 2.6.31. Probably it is not the same symptom... I would tend to have it applied all the way back but its always better to get some authoritative answer (maybe helps the maintainers of longterm, too). Anyway, since this is a somewhat painful bug to users, do you happen to know how far this is in reaching the upstream kernel? Thanks, Stefan > BUG: unable to handle kernel paging request at f573fc8c > IP: [<c01abc54>] swap_count_continued+0x104/0x180 > *pdpt = 000000002a3b9027 *pde = 0000000001bed067 *pte = 0000000000000000 > Oops: 0000 [#1] SMP > Modules linked in: > Pid: 1638, comm: apache2 Not tainted 3.0.4-linode37 #1 > EIP: 0061:[<c01abc54>] EFLAGS: 00210246 CPU: 3 > EIP is at swap_count_continued+0x104/0x180 > .. snip.. > Call Trace: > [<c01ac222>] ? __swap_duplicate+0xc2/0x160 > [<c01040f7>] ? pte_mfn_to_pfn+0x87/0xe0 > [<c01ac2e4>] ? swap_duplicate+0x14/0x40 > [<c01a0a6b>] ? copy_pte_range+0x45b/0x500 > [<c01a0ca5>] ? copy_page_range+0x195/0x200 > [<c01328c6>] ? dup_mmap+0x1c6/0x2c0 > [<c0132cf8>] ? dup_mm+0xa8/0x130 > [<c013376a>] ? copy_process+0x98a/0xb30 > [<c013395f>] ? do_fork+0x4f/0x280 > [<c01573b3>] ? getnstimeofday+0x43/0x100 > [<c010f770>] ? sys_clone+0x30/0x40 > [<c06c048d>] ? ptregs_clone+0x15/0x48 > [<c06bfb71>] ? syscall_call+0x7/0xb > > The problem is that in copy_page_range we turn lazy mode on, and then > in swap_entry_free we call swap_count_continued which ends up in: > > map = kmap_atomic(page, KM_USER0) + offset; > > and then later we touch *map. > > Since we are running in batched mode (lazy) we don't actually set up the > PTE mappings and the kmap_atomic is not done synchronously and ends up > trying to dereference a page that has not been set. > > Looking at kmap_atomic_prot_pfn, it uses 'arch_flush_lazy_mmu_mode' and > doing the same in kmap_atomic_prot and __kunmap_atomic makes the problem > go away. > > Interestingly, git commit b8bcfe997e46150fedcc3f5b26b846400122fdd9 > removed part of this to fix an interrupt issue - but it went to far > and did not consider this scenario. > > CC: Thomas Gleixner <tglx@linutronix.de> > CC: Ingo Molnar <mingo@redhat.com> > CC: "H. Peter Anvin" <hpa@zytor.com> > CC: x86@kernel.org > CC: Peter Zijlstra <a.p.zijlstra@chello.nl> > CC: Jeremy Fitzhardinge <jeremy.fitzhardinge@citrix.com> > CC: stable@kernel.org > [v1: Redid the commit description per Jeremy's apt suggestion] > Signed-off-by: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com> > --- > arch/x86/mm/highmem_32.c | 2 ++ > 1 files changed, 2 insertions(+), 0 deletions(-) > > diff --git a/arch/x86/mm/highmem_32.c b/arch/x86/mm/highmem_32.c > index b499626..f4f29b1 100644 > --- a/arch/x86/mm/highmem_32.c > +++ b/arch/x86/mm/highmem_32.c > @@ -45,6 +45,7 @@ void *kmap_atomic_prot(struct page *page, pgprot_t prot) > vaddr = __fix_to_virt(FIX_KMAP_BEGIN + idx); > BUG_ON(!pte_none(*(kmap_pte-idx))); > set_pte(kmap_pte-idx, mk_pte(page, prot)); > + arch_flush_lazy_mmu_mode(); > > return (void *)vaddr; > } > @@ -88,6 +89,7 @@ void __kunmap_atomic(void *kvaddr) > */ > kpte_clear_flush(kmap_pte-idx, vaddr); > kmap_atomic_idx_pop(); > + arch_flush_lazy_mmu_mode(); > } > #ifdef CONFIG_DEBUG_HIGHMEM > else { _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel From xen-devel-bounces@lists.xensource.com Fri Sep 30 03:08:39 2011 Return-path: <xen-devel-bounces@lists.xensource.com> Envelope-to: www-data@lists.xensource.com Delivery-date: Fri, 30 Sep 2011 03:08:39 -0700 Received: from localhost ([127.0.0.1] helo=lists.colo.xensource.com) by lists.xensource.com with esmtp (Exim 4.43) id 1R9a1H-00009j-EA; Fri, 30 Sep 2011 03:08:39 -0700 Received: from mail216.messagelabs.com ([85.158.143.99]) by lists.xensource.com with esmtp (Exim 4.43) id 1R9Zyd-0007tU-5K for xen-devel@lists.xensource.com; Fri, 30 Sep 2011 03:05:55 -0700 X-Env-Sender: JBeulich@suse.com X-Msg-Ref: server-10.tower-216.messagelabs.com!1317377152!10353022!1 X-Originating-IP: [130.57.49.28] X-StarScan-Version: 6.4.1; banners=-,-,- X-VirusChecked: Checked Received: (qmail 28506 invoked from network); 30 Sep 2011 10:05:52 -0000 Received: from nat28.tlf.novell.com (HELO nat28.tlf.novell.com) (130.57.49.28) by server-10.tower-216.messagelabs.com with DHE-RSA-AES256-SHA encrypted SMTP; 30 Sep 2011 10:05:52 -0000 Received: from EMEA1-MTA by nat28.tlf.novell.com with Novell_GroupWise; Fri, 30 Sep 2011 11:05:52 +0100 Message-Id: <4E85B09F0200007800058B7B@nat28.tlf.novell.com> X-Mailer: Novell GroupWise Internet Agent 8.0.1 Date: Fri, 30 Sep 2011 11:05:51 +0100 From: "Jan Beulich" <JBeulich@suse.com> To: "Jinsong Liu" <jinsong.liu@intel.com>, "Yunhong Jiang" <yunhong.jiang@intel.com> Subject: RE: [Xen-devel] [PATCH] X86 MCE: Add SRAR handler References: <BC00F5384FCFC9499AF06F92E8B78A9E263B557B77@shsmsx502.ccr.corp.intel.com> <4E84ADF70200007800058882@nat28.tlf.novell.com> <789F9655DD1B8F43B48D77C5D306597312D2366A9B@shsmsx501.ccr.corp.intel.com> <4E858AF30200007800058A64@nat28.tlf.novell.com> <BC00F5384FCFC9499AF06F92E8B78A9E263B557F02@shsmsx502.ccr.corp.intel.com> <4E8592A60200007800058AD4@nat28.tlf.novell.com> <BC00F5384FCFC9499AF06F92E8B78A9E263B557F40@shsmsx502.ccr.corp.intel.com> <4E859D7F0200007800058B39@nat28.tlf.novell.com> <BC00F5384FCFC9499AF06F92E8B78A9E263B557F7C@shsmsx502.ccr.corp.intel.com> In-Reply-To: <BC00F5384FCFC9499AF06F92E8B78A9E263B557F7C@shsmsx502.ccr.corp.intel.com> Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: quoted-printable Content-Disposition: inline Cc: "keir.xen@gmail.com" <keir.xen@gmail.com>, "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com> X-BeenThere: xen-devel@lists.xensource.com X-Mailman-Version: 2.1.5 Precedence: list List-Id: Xen developer discussion <xen-devel.lists.xensource.com> List-Unsubscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe> List-Post: <mailto:xen-devel@lists.xensource.com> List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help> List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=subscribe> Sender: xen-devel-bounces@lists.xensource.com Errors-To: xen-devel-bounces@lists.xensource.com >>> On 30.09.11 at 11:42, "Liu, Jinsong" <jinsong.liu@intel.com> wrote: > Jan Beulich wrote: >>>>> On 30.09.11 at 10:21, "Liu, Jinsong" <jinsong.liu@intel.com> wrote: >>> Executing guest code will not satisfy the check >>> if ( !(gstatus & MCG_STATUS_RIPV) && !guest_mode(regs)) return -1; >>> so it would not panic system. >>=20 >> Exactly. But it should when the prefetch was to hypervisor code. >>=20 >=20 > Wouldn't processor refresh instruction prefetch queue under such case? That's a question that you are better positioned to answer than me. But the SRAR errors being a sub-category of uncorrected errors I would think it can't be that simple. Jan _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel From xen-devel-bounces@lists.xensource.com Fri Sep 30 03:09:53 2011 Return-path: <xen-devel-bounces@lists.xensource.com> Envelope-to: www-data@lists.xensource.com Delivery-date: Fri, 30 Sep 2011 03:09:53 -0700 Received: from localhost ([127.0.0.1] helo=lists.colo.xensource.com) by lists.xensource.com with esmtp (Exim 4.43) id 1R9a2S-0000XA-Rq; Fri, 30 Sep 2011 03:09:52 -0700 Received: from mail216.messagelabs.com ([85.158.143.99]) by lists.xensource.com with esmtp (Exim 4.43) id 1R9ZzI-00081u-Rz for xen-devel@lists.xensource.com; Fri, 30 Sep 2011 03:06:37 -0700 X-Env-Sender: james.harper@bendigoit.com.au X-Msg-Ref: server-12.tower-216.messagelabs.com!1317377190!14373727!1 X-Originating-IP: [203.16.207.99] X-StarScan-Version: 6.4.1; banners=-,-,- X-VirusChecked: Checked Received: (qmail 11242 invoked from network); 30 Sep 2011 10:06:33 -0000 Received: from smtp2.bendigoit.com.au (HELO smtp2.bendigoit.com.au) (203.16.207.99) by server-12.tower-216.messagelabs.com with AES256-SHA encrypted SMTP; 30 Sep 2011 10:06:33 -0000 Received: from trantor.int.sbss.com.au ([192.168.200.206] helo=mail.bendigoit.com.au) by smtp2.bendigoit.com.au with esmtp (Exim 4.72) (envelope-from <james.harper@bendigoit.com.au>) id 1R9Zz3-0001HB-I2; Fri, 30 Sep 2011 20:06:28 +1000 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable X-MimeOLE: Produced By Microsoft Exchange V6.5 Subject: RE: [Xen-devel] RE: Stability report GPLPV 0.11.0.308 Date: Fri, 30 Sep 2011 20:06:20 +1000 Message-ID: <AEC6C66638C05B468B556EA548C1A77D01E5E2DF@trantor> In-Reply-To: <4E858925.6090903@hfp.de> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Xen-devel] RE: Stability report GPLPV 0.11.0.308 Thread-Index: Acx/Uc2dW3uNf8udT6msm1Z35N8rEwABjprw References: <4E64A0DF.2070007@hfp.de> <AEC6C66638C05B468B556EA548C1A77D01E5DB8C@trantor> <4E64D569.5030607@hfp.de> <AEC6C66638C05B468B556EA548C1A77D01E5DBBF@trantor> <4E7728F9.9020208@hfp.de> <AEC6C66638C05B468B556EA548C1A77D01E5E008@trantor> <4E7B04A4.9070601@hfp.de> <AEC6C66638C05B468B556EA548C1A77D01E5E072@trantor> <4E7CF2A8.5040405@hfp.de> <AEC6C66638C05B468B556EA548C1A77D01E5E0D0@trantor> <4E808FE9.5050008@hfp.de> <AEC6C66638C05B468B556EA548C1A77D01E5E190@trantor> <4E858925.6090903@hfp.de> From: "James Harper" <james.harper@bendigoit.com.au> To: "Andreas Kinzler" <ml-xen-devel@hfp.de> X-Really-From-Bendigo-IT: magichashvalue Cc: xen-devel@lists.xensource.com X-BeenThere: xen-devel@lists.xensource.com X-Mailman-Version: 2.1.5 Precedence: list List-Id: Xen developer discussion <xen-devel.lists.xensource.com> List-Unsubscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe> List-Post: <mailto:xen-devel@lists.xensource.com> List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help> List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=subscribe> Sender: xen-devel-bounces@lists.xensource.com Errors-To: xen-devel-bounces@lists.xensource.com >=20 > 1) xennet has some problem, but still why does scsiport vs. storport make a > difference then? If I'm running over the end of a buffer then anything goes... > 2) perhaps there is some new bug outside xennet and outside xenvbd (some > infrastructure thing: event handling, PCI, ...) and this is the real reason. Could be. > > Can you have a look in your logs for anything like this? I'm curious > > as to if we are chasing the same problem or a different one. >=20 > I am not running kernel debugging so far (have played with it though). > So I cannot say. >=20 You only need to be running the debug version of the drivers for this to be logged. Also are you running with the driver verifier enabled? That can help catch bugs and also allows you to notice memory leaks a bit better. One other thing to try is running with the checked build of windows. I've used the checked kernel and hal under 2003 and it picked up one error - it basically just checks parameters etc everywhere it can to make sure you aren't doing anything you shouldn't. I seem to remember the checked NDIS driver threw a fit though because xen was presenting 4 CPU's but a the cpuid registers said it was a single cpu with 4 cores so there are little things like that that can be troublesome with the checked builds... James _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel From xen-devel-bounces@lists.xensource.com Fri Sep 30 03:10:41 2011 Return-path: <xen-devel-bounces@lists.xensource.com> Envelope-to: www-data@lists.xensource.com Delivery-date: Fri, 30 Sep 2011 03:10:41 -0700 Received: from localhost ([127.0.0.1] helo=lists.colo.xensource.com) by lists.xensource.com with esmtp (Exim 4.43) id 1R9a3F-0000tx-KM; Fri, 30 Sep 2011 03:10:41 -0700 Received: from mail27.messagelabs.com ([193.109.254.147]) by lists.xensource.com with esmtp (Exim 4.43) id 1R9a1z-0000OG-3o for xen-devel@lists.xensource.com; Fri, 30 Sep 2011 03:09:24 -0700 X-Env-Sender: james.harper@bendigoit.com.au X-Msg-Ref: server-10.tower-27.messagelabs.com!1317377334!37855436!1 X-Originating-IP: [203.16.207.99] X-StarScan-Version: 6.4.1; banners=-,-,- X-VirusChecked: Checked Received: (qmail 14796 invoked from network); 30 Sep 2011 10:08:57 -0000 Received: from mail.bendigoit.com.au (HELO smtp2.bendigoit.com.au) (203.16.207.99) by server-10.tower-27.messagelabs.com with AES256-SHA encrypted SMTP; 30 Sep 2011 10:08:57 -0000 Received: from trantor.int.sbss.com.au ([192.168.200.206] helo=mail.bendigoit.com.au) by smtp2.bendigoit.com.au with esmtp (Exim 4.72) (envelope-from <james.harper@bendigoit.com.au>) id 1R9a1k-0001I4-55; Fri, 30 Sep 2011 20:09:15 +1000 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable X-MimeOLE: Produced By Microsoft Exchange V6.5 Subject: RE: [Xen-devel] RE: Stability report GPLPV 0.11.0.308 Date: Fri, 30 Sep 2011 20:09:07 +1000 Message-ID: <AEC6C66638C05B468B556EA548C1A77D01E5E2E0@trantor> In-Reply-To: <4E858925.6090903@hfp.de> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Xen-devel] RE: Stability report GPLPV 0.11.0.308 Thread-Index: Acx/Uc2dW3uNf8udT6msm1Z35N8rEwABtsoA References: <4E64A0DF.2070007@hfp.de> <AEC6C66638C05B468B556EA548C1A77D01E5DB8C@trantor> <4E64D569.5030607@hfp.de> <AEC6C66638C05B468B556EA548C1A77D01E5DBBF@trantor> <4E7728F9.9020208@hfp.de> <AEC6C66638C05B468B556EA548C1A77D01E5E008@trantor> <4E7B04A4.9070601@hfp.de> <AEC6C66638C05B468B556EA548C1A77D01E5E072@trantor> <4E7CF2A8.5040405@hfp.de> <AEC6C66638C05B468B556EA548C1A77D01E5E0D0@trantor> <4E808FE9.5050008@hfp.de> <AEC6C66638C05B468B556EA548C1A77D01E5E190@trantor> <4E858925.6090903@hfp.de> From: "James Harper" <james.harper@bendigoit.com.au> To: "Andreas Kinzler" <ml-xen-devel@hfp.de> X-Really-From-Bendigo-IT: magichashvalue Cc: xen-devel@lists.xensource.com X-BeenThere: xen-devel@lists.xensource.com X-Mailman-Version: 2.1.5 Precedence: list List-Id: Xen developer discussion <xen-devel.lists.xensource.com> List-Unsubscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe> List-Post: <mailto:xen-devel@lists.xensource.com> List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help> List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=subscribe> Sender: xen-devel-bounces@lists.xensource.com Errors-To: xen-devel-bounces@lists.xensource.com >=20 > > 12961573357740: *** Assertion failed: pi.curr_mdl > > 12961573357740: *** Source File: > > c:\projects\win-pvdrivers.hg\xennet\xennet6_tx.c, line 308 >=20 > I took this report about a problem you had with "tx" to modify my tests and > to make them mostly tx-based while previously they were mostly rx-based. > Tests are running for 2d 18h now - no problems so far. >=20 > I wanted to tell you about one interesting observation. In my tests I did two > runs with modified xenvbd drivers. In run #1 I switched to the scsiport driver > of 0.11.0.312 and this made one domU crash after one day while with > 0.11.0.312 storport version I always had more than 9 days (as I reported > earlier). In run #2 I forward-ported xenvbd from 0.11.0.213 (which is totally > stable on our systems) and again one domU crashed after one day. This is > really interesting and leads me to two thoughts: >=20 Actually one other thing you could try is simply using the Windows 2003 version of the drivers. That uses ndis5 and scsiport instead of ndis6 and storport. If that worked we could try running with ndis5 + storport and see if that works okay. As long as they are from the same patchlevel it shouldn't matter if you use one compiled for windows 2008 and one for windows 2003 (it's possible that it might matter but I can't think of anything). James _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel From xen-devel-bounces@lists.xensource.com Fri Sep 30 03:12:41 2011 Return-path: <xen-devel-bounces@lists.xensource.com> Envelope-to: www-data@lists.xensource.com Delivery-date: Fri, 30 Sep 2011 03:12:41 -0700 Received: from localhost ([127.0.0.1] helo=lists.colo.xensource.com) by lists.xensource.com with esmtp (Exim 4.43) id 1R9a5B-0001Hx-CA; Fri, 30 Sep 2011 03:12:41 -0700 Received: from mail182.messagelabs.com ([85.158.139.83]) by lists.xensource.com with smtp (Exim 4.43) id 1R9a4o-000169-3A for xen-devel@lists.xensource.com; Fri, 30 Sep 2011 03:12:18 -0700 X-Env-Sender: jinsong.liu@intel.com X-Msg-Ref: server-4.tower-182.messagelabs.com!1317377534!20339734!1 X-Originating-IP: [192.55.52.93] X-StarScan-Version: 6.4.1; banners=-,-,- X-VirusChecked: Checked Received: (qmail 31955 invoked from network); 30 Sep 2011 10:12:14 -0000 Received: from mga11.intel.com (HELO mga11.intel.com) (192.55.52.93) by server-4.tower-182.messagelabs.com with SMTP; 30 Sep 2011 10:12:14 -0000 Received: from fmsmga001.fm.intel.com ([10.253.24.23]) by fmsmga102.fm.intel.com with ESMTP; 30 Sep 2011 03:12:13 -0700 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="4.68,466,1312182000"; d="scan'208";a="68971071" Received: from pgsmsx602.gar.corp.intel.com ([10.221.43.81]) by fmsmga001.fm.intel.com with ESMTP; 30 Sep 2011 03:12:13 -0700 Received: from pgsmsx103.gar.corp.intel.com (10.221.44.82) by pgsmsx602.gar.corp.intel.com (10.221.43.81) with Microsoft SMTP Server (TLS) id 8.2.255.0; Fri, 30 Sep 2011 18:11:31 +0800 Received: from shsmsx601.ccr.corp.intel.com (10.239.4.112) by PGSMSX103.gar.corp.intel.com (10.221.44.82) with Microsoft SMTP Server (TLS) id 14.1.323.3; Fri, 30 Sep 2011 18:11:30 +0800 Received: from shsmsx502.ccr.corp.intel.com ([10.239.4.96]) by shsmsx601.ccr.corp.intel.com ([10.239.4.112]) with mapi; Fri, 30 Sep 2011 18:11:29 +0800 From: "Liu, Jinsong" <jinsong.liu@intel.com> To: Jan Beulich <JBeulich@suse.com>, "Jiang, Yunhong" <yunhong.jiang@intel.com> Date: Fri, 30 Sep 2011 18:11:28 +0800 Subject: RE: [Xen-devel] [PATCH] X86 MCE: Add SRAR handler Thread-Topic: [Xen-devel] [PATCH] X86 MCE: Add SRAR handler Thread-Index: Acx/WI2JGiAAymCbSU+OG6bGavY8HgAAEC9g Message-ID: <BC00F5384FCFC9499AF06F92E8B78A9E263B557F87@shsmsx502.ccr.corp.intel.com> References: <BC00F5384FCFC9499AF06F92E8B78A9E263B557B77@shsmsx502.ccr.corp.intel.com> <4E84ADF70200007800058882@nat28.tlf.novell.com> <789F9655DD1B8F43B48D77C5D306597312D2366A9B@shsmsx501.ccr.corp.intel.com> <4E858AF30200007800058A64@nat28.tlf.novell.com> <BC00F5384FCFC9499AF06F92E8B78A9E263B557F02@shsmsx502.ccr.corp.intel.com> <4E8592A60200007800058AD4@nat28.tlf.novell.com> <BC00F5384FCFC9499AF06F92E8B78A9E263B557F40@shsmsx502.ccr.corp.intel.com> <4E859D7F0200007800058B39@nat28.tlf.novell.com> <BC00F5384FCFC9499AF06F92E8B78A9E263B557F7C@shsmsx502.ccr.corp.intel.com> <4E85B09F0200007800058B7B@nat28.tlf.novell.com> In-Reply-To: <4E85B09F0200007800058B7B@nat28.tlf.novell.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "keir.xen@gmail.com" <keir.xen@gmail.com>, "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com> X-BeenThere: xen-devel@lists.xensource.com X-Mailman-Version: 2.1.5 Precedence: list List-Id: Xen developer discussion <xen-devel.lists.xensource.com> List-Unsubscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe> List-Post: <mailto:xen-devel@lists.xensource.com> List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help> List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=subscribe> Sender: xen-devel-bounces@lists.xensource.com Errors-To: xen-devel-bounces@lists.xensource.com Jan Beulich wrote: >>>> On 30.09.11 at 11:42, "Liu, Jinsong" <jinsong.liu@intel.com> wrote: >> Jan Beulich wrote: >>>>>> On 30.09.11 at 10:21, "Liu, Jinsong" <jinsong.liu@intel.com> >>>>>> wrote:=20 >>>> Executing guest code will not satisfy the check >>>> if ( !(gstatus & MCG_STATUS_RIPV) && !guest_mode(regs)) return -1; >>>> so it would not panic system. >>>=20 >>> Exactly. But it should when the prefetch was to hypervisor code. >>>=20 >>=20 >> Wouldn't processor refresh instruction prefetch queue under such >> case?=20 >=20 > That's a question that you are better positioned to answer than me. > But the SRAR errors being a sub-category of uncorrected errors I > would think it can't be that simple. >=20 Hmm, I will check this question internally first. BTW, we would have 7 days holiday (1/10 ~ 7/10), so email reply maybe some = slow. Thanks, Jinsong= _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel From xen-devel-bounces@lists.xensource.com Fri Sep 30 03:14:10 2011 Return-path: <xen-devel-bounces@lists.xensource.com> Envelope-to: www-data@lists.xensource.com Delivery-date: Fri, 30 Sep 2011 03:14:10 -0700 Received: from localhost ([127.0.0.1] helo=lists.colo.xensource.com) by lists.xensource.com with esmtp (Exim 4.43) id 1R9a6c-0001gK-OH; Fri, 30 Sep 2011 03:14:10 -0700 Received: from mail174.messagelabs.com ([85.158.138.51]) by lists.xensource.com with esmtp (Exim 4.43) id 1R9a6A-0001TW-7Q for xen-devel@lists.xensource.com; Fri, 30 Sep 2011 03:13:43 -0700 X-Env-Sender: david.vrabel@citrix.com X-Msg-Ref: server-15.tower-174.messagelabs.com!1317377617!27009453!1 X-Originating-IP: [66.165.176.89] X-StarScan-Version: 6.4.1; banners=-,-,- X-VirusChecked: Checked Received: (qmail 15960 invoked from network); 30 Sep 2011 10:13:38 -0000 Received: from smtp.citrix.com (HELO SMTP.CITRIX.COM) (66.165.176.89) by server-15.tower-174.messagelabs.com with RC4-SHA encrypted SMTP; 30 Sep 2011 10:13:38 -0000 X-IronPort-AV: E=Sophos;i="4.68,466,1312171200"; d="scan'208";a="17835542" Received: from ftlpmailmx02.citrite.net ([10.13.107.66]) by FTLPIPO01.CITRIX.COM with ESMTP/TLS/RC4-MD5; 30 Sep 2011 06:13:37 -0400 Received: from [10.80.2.76] (10.80.2.76) by FTLPMAILMX02.citrite.net (10.13.107.66) with Microsoft SMTP Server id 8.3.137.0; Fri, 30 Sep 2011 06:13:37 -0400 Message-ID: <4E859697.1050906@citrix.com> Date: Fri, 30 Sep 2011 11:14:47 +0100 From: David Vrabel <david.vrabel@citrix.com> User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.1.16) Gecko/20110818 Icedove/3.0.11 MIME-Version: 1.0 To: Jan Beulich <JBeulich@suse.com> Subject: Re: [Xen-devel] [PATCH 0/4] xen: map foreign pages for shared rings by updating the PTEs directly References: <1317311612-15220-1-git-send-email-david.vrabel@citrix.com> <4E84B3FE02000078000588A9@nat28.tlf.novell.com> <4E84A0C0.6000804@citrix.com> <4E85951B0200007800058AF8@nat28.tlf.novell.com> In-Reply-To: <4E85951B0200007800058AF8@nat28.tlf.novell.com> Content-Type: text/plain; charset="ISO-8859-1" Content-Transfer-Encoding: 7bit Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>, KonradRzeszutek Wilk <konrad.wilk@oracle.com> X-BeenThere: xen-devel@lists.xensource.com X-Mailman-Version: 2.1.5 Precedence: list List-Id: Xen developer discussion <xen-devel.lists.xensource.com> List-Unsubscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe> List-Post: <mailto:xen-devel@lists.xensource.com> List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help> List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=subscribe> Sender: xen-devel-bounces@lists.xensource.com Errors-To: xen-devel-bounces@lists.xensource.com On 30/09/11 09:08, Jan Beulich wrote: >>>> On 29.09.11 at 18:45, David Vrabel <david.vrabel@citrix.com> wrote: >> On 29/09/11 17:07, Jan Beulich wrote: >>>>>> On 29.09.11 at 17:53, David Vrabel <david.vrabel@citrix.com> wrote: >>>> [Resend as requested by Konrad.] >>>> >>>> This series of patches allows the vmalloc_sync_all() to be removed >>>> from alloc_vm_area() by getting the hypervisor to update the PTEs (in >>>> init_mm) directly rather than having the hypervisor look in the >>>> current page tables to find the PTEs. >>>> >>>> Once the hypervisor has updated the PTEs, the normal mechanism of >>>> syncing the page tables after a fault works as expected. >>> >>> Did you actually test that, and namely the case where alloc_vm_area() >>> would result in a new top level page directory entry to get populated? >>> >>> I cannot see how this new entry would propagate into other mm-s, and >>> hence I cannot see how you can do away with calling vmalloc_sync_all() >>> just by changing how leaf page table entries get populated. >> >> I don't think this new behaviour of alloc_vm_area() is any different >> from how a regular vmalloc() works. > > Of course not. Callers of vmalloc() need to use vmalloc_sync_all() too > before it is permitted to access the allocated space from an NMI > handler or pass it into a hypercall. The virtual addresses of the mapped rings are not accessed in an NMI handler or a hypercall (before this patch set they were accessed in the GNTTABOP_map_grant_ref hypercall, but no longer). In the future, if something did want to pass the virtual address to a hypercall it wouldn't need the vmalloc_sync() as it could disable preemption, touch the page (so current->active_mm is updated), do the hypercall, then disable preemption. >> vmalloc_fault() copies the page table entries from init_mm into the >> current MM (on 32-bit it calls vmalloc_sync_one() which makes it >> obviously correct I think). > > No, vmalloc_fault() copies pmd-s (32-bit) or pgd-s (64-bit), but never > pte-s. Avoiding this to be done in a fault (precisely for the NMI and > hypercall cases named above) is what vmalloc_sync_all() was > introduced for (really, the hypercall aspect didn't matter back then, > and alloc_vm_area() didn't exist outside of Xenolinux then either). > > So eliminating it from alloc_vm_area() just pushes the need to call it > to all callers that may have the obtained space accessed in NMI > context (none at present, as only Xen code appears to call this > function) or want to pass it to a hypercall without running on init_mm. > > Just to repeat the essence of my first reply: Fiddling with how pte-s > get populated can not possibly eliminate the need to call a function > that populates top level page directory entries (pmd-s/pgd-s). > > Jan > >>>> This mechanism doesn't currently work on the ia64 port as that does >>>> not support the GNTMAP_contains_pte flag. >>>> >>>> David _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel From xen-devel-bounces@lists.xensource.com Fri Sep 30 03:15:35 2011 Return-path: <xen-devel-bounces@lists.xensource.com> Envelope-to: www-data@lists.xensource.com Delivery-date: Fri, 30 Sep 2011 03:15:35 -0700 Received: from localhost ([127.0.0.1] helo=lists.colo.xensource.com) by lists.xensource.com with esmtp (Exim 4.43) id 1R9a7y-00023D-VM; Fri, 30 Sep 2011 03:15:34 -0700 Received: from mail216.messagelabs.com ([85.158.143.99]) by lists.xensource.com with esmtp (Exim 4.43) id 1R9a7E-0001qW-Nw for xen-devel@lists.xensource.com; Fri, 30 Sep 2011 03:14:49 -0700 X-Env-Sender: marmarek@mimuw.edu.pl X-Msg-Ref: server-6.tower-216.messagelabs.com!1317377685!18851999!1 X-Originating-IP: [193.0.96.6] X-StarScan-Version: 6.4.1; banners=-,-,- X-VirusChecked: Checked Received: (qmail 26147 invoked from network); 30 Sep 2011 10:14:45 -0000 Received: from mail.mimuw.edu.pl (HELO mail.mimuw.edu.pl) (193.0.96.6) by server-6.tower-216.messagelabs.com with DHE-RSA-AES256-SHA encrypted SMTP; 30 Sep 2011 10:14:45 -0000 Received: from localhost (localhost [127.0.0.1] ident=amavis) by duch.mimuw.edu.pl (Postfix) with ESMTP id BD77C31; Fri, 30 Sep 2011 12:14:44 +0200 (CEST) X-Virus-Scanned: amavisd-new at mimuw.edu.pl Received: by duch.mimuw.edu.pl (Postfix, from userid 1575) id DDE0129; Fri, 30 Sep 2011 12:14:43 +0200 (CEST) Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Mercurial-Node: 9b18356077c8dd3276a8dfce538d69057c8462df Message-Id: <9b18356077c8dd3276a8.1317376499@devel14> User-Agent: Mercurial-patchbomb/1.8.4 Date: Fri, 30 Sep 2011 11:54:59 +0200 From: Marek Marczykowski <marmarek@invisiblethingslab.com> To: xen-devel@lists.xensource.com Cc: marmarek@invisiblethingslab.com Subject: [Xen-devel] [PATCH] libxl: fix block attach with non-dom0 backend X-BeenThere: xen-devel@lists.xensource.com X-Mailman-Version: 2.1.5 Precedence: list List-Id: Xen developer discussion <xen-devel.lists.xensource.com> List-Unsubscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe> List-Post: <mailto:xen-devel@lists.xensource.com> List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help> List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=subscribe> Sender: xen-devel-bounces@lists.xensource.com Errors-To: xen-devel-bounces@lists.xensource.com libxl: fix block attach with non-dom0 backend When backend!=dom0 there is no simple way to get major:minor numbers. So just no verify it and leave filling it to hotplug script (as xend does). Signed-off-by: Marek Marczykowski <marmarek@invisiblethingslab.com> diff --git a/tools/libxl/libxl.c b/tools/libxl/libxl.c --- a/tools/libxl/libxl.c +++ b/tools/libxl/libxl.c @@ -959,9 +959,11 @@ int libxl_device_disk_add(libxl_ctx *ctx case LIBXL_DISK_BACKEND_PHY: dev = disk->pdev_path; do_backend_phy: - libxl__device_physdisk_major_minor(dev, &major, &minor); - flexarray_append(back, "physical-device"); - flexarray_append(back, libxl__sprintf(&gc, "%x:%x", major, minor)); + if (disk->backend_domid == 0) { + libxl__device_physdisk_major_minor(dev, &major, &minor); + flexarray_append(back, "physical-device"); + flexarray_append(back, libxl__sprintf(&gc, "%x:%x", major, minor)); + } flexarray_append(back, "params"); flexarray_append(back, dev); _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel From xen-devel-bounces@lists.xensource.com Fri Sep 30 03:18:37 2011 Return-path: <xen-devel-bounces@lists.xensource.com> Envelope-to: www-data@lists.xensource.com Delivery-date: Fri, 30 Sep 2011 03:18:37 -0700 Received: from localhost ([127.0.0.1] helo=lists.colo.xensource.com) by lists.xensource.com with esmtp (Exim 4.43) id 1R9aAv-0002Wn-7L; Fri, 30 Sep 2011 03:18:37 -0700 Received: from mail216.messagelabs.com ([85.158.143.99]) by lists.xensource.com with esmtp (Exim 4.43) id 1R9aAO-0002Kj-T8 for xen-devel@lists.xensource.com; Fri, 30 Sep 2011 03:18:05 -0700 X-Env-Sender: Ian.Campbell@eu.citrix.com X-Msg-Ref: server-3.tower-216.messagelabs.com!1317377881!19089898!1 X-Originating-IP: [62.200.22.115] X-StarScan-Version: 6.4.1; banners=-,-,- X-VirusChecked: Checked Received: (qmail 19271 invoked from network); 30 Sep 2011 10:18:02 -0000 Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115) by server-3.tower-216.messagelabs.com with RC4-SHA encrypted SMTP; 30 Sep 2011 10:18:02 -0000 X-IronPort-AV: E=Sophos;i="4.68,466,1312156800"; d="scan'208";a="8146882" Received: from lonpmailmx01.citrite.net ([10.30.203.162]) by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5; 30 Sep 2011 10:18:01 +0000 Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net (10.30.203.162) with Microsoft SMTP Server id 8.3.137.0; Fri, 30 Sep 2011 11:18:02 +0100 Subject: Re: [Xen-devel] [PATCH 0/4] xen: map foreign pages for shared rings by updating the PTEs directly From: Ian Campbell <Ian.Campbell@citrix.com> To: Jan Beulich <JBeulich@suse.com> Date: Fri, 30 Sep 2011 11:18:01 +0100 In-Reply-To: <4E85951B0200007800058AF8@nat28.tlf.novell.com> References: <1317311612-15220-1-git-send-email-david.vrabel@citrix.com> <4E84B3FE02000078000588A9@nat28.tlf.novell.com> <4E84A0C0.6000804@citrix.com> <4E85951B0200007800058AF8@nat28.tlf.novell.com> Organization: Citrix Systems, Inc. Content-Type: text/plain; charset="UTF-8" X-Mailer: Evolution 3.0.3- Content-Transfer-Encoding: 7bit Message-ID: <1317377881.26672.254.camel@zakaz.uk.xensource.com> MIME-Version: 1.0 Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>, David Vrabel <david.vrabel@citrix.com>, KonradRzeszutek Wilk <konrad.wilk@oracle.com> X-BeenThere: xen-devel@lists.xensource.com X-Mailman-Version: 2.1.5 Precedence: list List-Id: Xen developer discussion <xen-devel.lists.xensource.com> List-Unsubscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe> List-Post: <mailto:xen-devel@lists.xensource.com> List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help> List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=subscribe> Sender: xen-devel-bounces@lists.xensource.com Errors-To: xen-devel-bounces@lists.xensource.com On Fri, 2011-09-30 at 09:08 +0100, Jan Beulich wrote: > >>> On 29.09.11 at 18:45, David Vrabel <david.vrabel@citrix.com> wrote: > > On 29/09/11 17:07, Jan Beulich wrote: > >>>>> On 29.09.11 at 17:53, David Vrabel <david.vrabel@citrix.com> wrote: > >>> [Resend as requested by Konrad.] > >>> > >>> This series of patches allows the vmalloc_sync_all() to be removed > >>> from alloc_vm_area() by getting the hypervisor to update the PTEs (in > >>> init_mm) directly rather than having the hypervisor look in the > >>> current page tables to find the PTEs. > >>> > >>> Once the hypervisor has updated the PTEs, the normal mechanism of > >>> syncing the page tables after a fault works as expected. > >> > >> Did you actually test that, and namely the case where alloc_vm_area() > >> would result in a new top level page directory entry to get populated? > >> > >> I cannot see how this new entry would propagate into other mm-s, and > >> hence I cannot see how you can do away with calling vmalloc_sync_all() > >> just by changing how leaf page table entries get populated. > > > > I don't think this new behaviour of alloc_vm_area() is any different > > from how a regular vmalloc() works. > > Of course not. Callers of vmalloc() need to use vmalloc_sync_all() too > before it is permitted to access the allocated space from an NMI > handler or pass it into a hypercall. > > > vmalloc_fault() copies the page table entries from init_mm into the > > current MM (on 32-bit it calls vmalloc_sync_one() which makes it > > obviously correct I think). > > No, vmalloc_fault() copies pmd-s (32-bit) or pgd-s (64-bit), but never > pte-s. Right, but David has also changed the hypercall so that it now takes the specific pte to update, instead of taking the virtual address and relying on the hypervisor's linear map of the guests page tables to do the update. So the hypercall can now update the pte regardless of whether it is actually hooked into the current set of page tables or not. Then once the hypercall is complete and the kernel comes to actually use the address the normal vmalloc fault stuff will happen and fault in the pmd/pgd which refers to those ptes which have been updated. Ian. > Avoiding this to be done in a fault (precisely for the NMI and > hypercall cases named above) is what vmalloc_sync_all() was > introduced for (really, the hypercall aspect didn't matter back then, > and alloc_vm_area() didn't exist outside of Xenolinux then either). > > So eliminating it from alloc_vm_area() just pushes the need to call it > to all callers that may have the obtained space accessed in NMI > context (none at present, as only Xen code appears to call this > function) or want to pass it to a hypercall without running on init_mm. > > Just to repeat the essence of my first reply: Fiddling with how pte-s > get populated can not possibly eliminate the need to call a function > that populates top level page directory entries (pmd-s/pgd-s). > > Jan > > >>> This mechanism doesn't currently work on the ia64 port as that does > >>> not support the GNTMAP_contains_pte flag. > >>> > >>> David > > > > > _______________________________________________ > Xen-devel mailing list > Xen-devel@lists.xensource.com > http://lists.xensource.com/xen-devel _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel From xen-devel-bounces@lists.xensource.com Fri Sep 30 03:19:33 2011 Return-path: <xen-devel-bounces@lists.xensource.com> Envelope-to: www-data@lists.xensource.com Delivery-date: Fri, 30 Sep 2011 03:19:33 -0700 Received: from localhost ([127.0.0.1] helo=lists.colo.xensource.com) by lists.xensource.com with esmtp (Exim 4.43) id 1R9aBp-0002tQ-La; Fri, 30 Sep 2011 03:19:33 -0700 Received: from mail216.messagelabs.com ([85.158.143.99]) by lists.xensource.com with esmtp (Exim 4.43) id 1R9aAQ-0002Kk-89 for xen-devel@lists.xensource.com; Fri, 30 Sep 2011 03:18:06 -0700 X-Env-Sender: james.harper@bendigoit.com.au X-Msg-Ref: server-14.tower-216.messagelabs.com!1317377880!20122355!1 X-Originating-IP: [203.16.207.99] X-StarScan-Version: 6.4.1; banners=-,-,- X-VirusChecked: Checked Received: (qmail 26781 invoked from network); 30 Sep 2011 10:18:02 -0000 Received: from mail.bendigoit.com.au (HELO smtp2.bendigoit.com.au) (203.16.207.99) by server-14.tower-216.messagelabs.com with AES256-SHA encrypted SMTP; 30 Sep 2011 10:18:02 -0000 Received: from trantor.int.sbss.com.au ([192.168.200.206] helo=mail.bendigoit.com.au) by smtp2.bendigoit.com.au with esmtp (Exim 4.72) (envelope-from <james.harper@bendigoit.com.au>) id 1R9aAB-0001K8-OO; Fri, 30 Sep 2011 20:17:58 +1000 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable X-MimeOLE: Produced By Microsoft Exchange V6.5 Subject: RE: [Xen-devel] RE: Stability report GPLPV 0.11.0.308 Date: Fri, 30 Sep 2011 20:17:50 +1000 Message-ID: <AEC6C66638C05B468B556EA548C1A77D01E5E2E1@trantor> In-Reply-To: <4E858925.6090903@hfp.de> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Xen-devel] RE: Stability report GPLPV 0.11.0.308 Thread-Index: Acx/Uc2dW3uNf8udT6msm1Z35N8rEwACCOSw References: <4E64A0DF.2070007@hfp.de> <AEC6C66638C05B468B556EA548C1A77D01E5DB8C@trantor> <4E64D569.5030607@hfp.de> <AEC6C66638C05B468B556EA548C1A77D01E5DBBF@trantor> <4E7728F9.9020208@hfp.de> <AEC6C66638C05B468B556EA548C1A77D01E5E008@trantor> <4E7B04A4.9070601@hfp.de> <AEC6C66638C05B468B556EA548C1A77D01E5E072@trantor> <4E7CF2A8.5040405@hfp.de> <AEC6C66638C05B468B556EA548C1A77D01E5E0D0@trantor> <4E808FE9.5050008@hfp.de> <AEC6C66638C05B468B556EA548C1A77D01E5E190@trantor> <4E858925.6090903@hfp.de> From: "James Harper" <james.harper@bendigoit.com.au> To: "Andreas Kinzler" <ml-xen-devel@hfp.de> X-Really-From-Bendigo-IT: magichashvalue Cc: xen-devel@lists.xensource.com X-BeenThere: xen-devel@lists.xensource.com X-Mailman-Version: 2.1.5 Precedence: list List-Id: Xen developer discussion <xen-devel.lists.xensource.com> List-Unsubscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe> List-Post: <mailto:xen-devel@lists.xensource.com> List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help> List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=subscribe> Sender: xen-devel-bounces@lists.xensource.com Errors-To: xen-devel-bounces@lists.xensource.com > Hello James, >=20 > > 12961573357740: *** Assertion failed: pi.curr_mdl > > 12961573357740: *** Source File: > > c:\projects\win-pvdrivers.hg\xennet\xennet6_tx.c, line 308 >=20 > I took this report about a problem you had with "tx" to modify my tests and > to make them mostly tx-based while previously they were mostly rx-based. > Tests are running for 2d 18h now - no problems so far. >=20 I'm not quite sure but I think my testing was in the rx direction just prior to the crash. I think the testing finished and then this crash happened a few minutes later. I think it also happened when the machine hadn't been up for very long too... I haven't been able to reproduce it since though which is frustrating. James _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel From xen-devel-bounces@lists.xensource.com Fri Sep 30 03:36:59 2011 Return-path: <xen-devel-bounces@lists.xensource.com> Envelope-to: www-data@lists.xensource.com Delivery-date: Fri, 30 Sep 2011 03:36:59 -0700 Received: from localhost ([127.0.0.1] helo=lists.colo.xensource.com) by lists.xensource.com with esmtp (Exim 4.43) id 1R9aSh-0004Nl-1n; Fri, 30 Sep 2011 03:36:59 -0700 Received: from mail174.messagelabs.com ([85.158.138.51]) by lists.xensource.com with esmtp (Exim 4.43) id 1R9aS5-00046W-IR for xen-devel@lists.xensource.com; Fri, 30 Sep 2011 03:36:22 -0700 X-Env-Sender: anthony.perard@gmail.com X-Msg-Ref: server-2.tower-174.messagelabs.com!1317378977!33359392!1 X-Originating-IP: [209.85.216.43] X-StarScan-Version: 6.4.1; banners=-,-,- X-VirusChecked: Checked Received: (qmail 16574 invoked from network); 30 Sep 2011 10:36:18 -0000 Received: from mail-qw0-f43.google.com (HELO mail-qw0-f43.google.com) (209.85.216.43) by server-2.tower-174.messagelabs.com with RC4-SHA encrypted SMTP; 30 Sep 2011 10:36:18 -0000 Received: by qabg14 with SMTP id g14so378850qab.30 for <xen-devel@lists.xensource.com>; Fri, 30 Sep 2011 03:36:17 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:sender:in-reply-to:references:from:date :x-google-sender-auth:message-id:subject:to:cc:content-type :content-transfer-encoding; bh=xvQZltj+mxVl1eim64Dx/ozGlpoaYxRQAKy5xzncWeg=; b=JGCbzUCz2KdAh5OBsdQ79OU4HKUweiHInKM16JeFLzAezvXuz7P/d5crQ6TDZrWvSj Pqfkwteyo/YbWL/+5vuSp3r21VT5j0p34zbrGhnpPsI8J65Cg5LMUvLUYc3lcuCGIBrv W4hVDOMjzgsHhMwFhso+tsaC8uP1NMPMUMZUQ= Received: by 10.224.9.138 with SMTP id l10mr2816886qal.255.1317378977096; Fri, 30 Sep 2011 03:36:17 -0700 (PDT) MIME-Version: 1.0 Received: by 10.224.47.74 with HTTP; Fri, 30 Sep 2011 03:35:47 -0700 (PDT) In-Reply-To: <4b98868690218126b906.1317368189@cosworth.uk.xensource.com> References: <4b98868690218126b906.1317368189@cosworth.uk.xensource.com> From: Anthony PERARD <anthony.perard@citrix.com> Date: Fri, 30 Sep 2011 11:35:47 +0100 X-Google-Sender-Auth: sXpBnPo_Iyl4j7MyvGnbM3VUW4c Message-ID: <CAJJyHjL55fNgwrmDVdCehaOLC1mPecf8M4fE4RCn_g_vygj=0A@mail.gmail.com> Subject: Re: [Xen-devel] [PATCH] tools/check: check for yajl (needed by libxl) To: Ian Campbell <ian.campbell@citrix.com> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Cc: Olaf Hering <olaf@aepfle.de>, xen-devel@lists.xensource.com X-BeenThere: xen-devel@lists.xensource.com X-Mailman-Version: 2.1.5 Precedence: list List-Id: Xen developer discussion <xen-devel.lists.xensource.com> List-Unsubscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe> List-Post: <mailto:xen-devel@lists.xensource.com> List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help> List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=subscribe> Sender: xen-devel-bounces@lists.xensource.com Errors-To: xen-devel-bounces@lists.xensource.com On Fri, Sep 30, 2011 at 08:36, Ian Campbell <ian.campbell@citrix.com> wrote= : > # HG changeset patch > # User Ian Campbell <ian.campbell@citrix.com> > # Date 1317367995 -3600 > # Node ID 4b98868690218126b90620d9b43fdd4140145a43 > # Parent =C2=A0e50da6b98e3d5933b9c98e8f43096fd3ebbae00d > tools/check: check for yajl (needed by libxl) > > Signed-off-by: Ian Campbell <ian.campbell@citrix.com> > --- > (note to committer, ensure the new file is executable) > > diff -r e50da6b98e3d -r 4b9886869021 tools/check/check_yajl_lib > --- /dev/null =C2=A0 Thu Jan 01 00:00:00 1970 +0000 > +++ b/tools/check/check_yajl_lib =C2=A0 =C2=A0 =C2=A0 =C2=A0Fri Sep 30 08= :33:15 2011 +0100 > @@ -0,0 +1,7 @@ > +#!/bin/sh > +# CHECK-BUILD CHECK-INSTALL > + > +. ./funcs.sh > + > + > +has_lib libyajl.so || fail "can't find yajl" You probably want to check the yajl headers as well, no ? #include <yajl/yajl_parse.h> #include <yajl/yajl_gen.h> Regards, --=20 Anthony PERARD _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel From xen-devel-bounces@lists.xensource.com Fri Sep 30 03:40:23 2011 Return-path: <xen-devel-bounces@lists.xensource.com> Envelope-to: www-data@lists.xensource.com Delivery-date: Fri, 30 Sep 2011 03:40:23 -0700 Received: from localhost ([127.0.0.1] helo=lists.colo.xensource.com) by lists.xensource.com with esmtp (Exim 4.43) id 1R9aVz-0005Vb-JV; Fri, 30 Sep 2011 03:40:23 -0700 Received: from mail21.messagelabs.com ([85.158.143.35]) by lists.xensource.com with esmtp (Exim 4.43) id 1R9aVa-0005JA-Jx for xen-devel@lists.xensource.com; Fri, 30 Sep 2011 03:39:58 -0700 X-Env-Sender: Ian.Campbell@eu.citrix.com X-Msg-Ref: server-7.tower-21.messagelabs.com!1317379163!56852235!1 X-Originating-IP: [62.200.22.115] X-StarScan-Version: 6.4.1; banners=-,-,- X-VirusChecked: Checked Received: (qmail 23170 invoked from network); 30 Sep 2011 10:39:24 -0000 Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115) by server-7.tower-21.messagelabs.com with RC4-SHA encrypted SMTP; 30 Sep 2011 10:39:24 -0000 X-IronPort-AV: E=Sophos;i="4.68,466,1312156800"; d="scan'208";a="8147575" Received: from lonpmailmx01.citrite.net ([10.30.203.162]) by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5; 30 Sep 2011 10:39:55 +0000 Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net (10.30.203.162) with Microsoft SMTP Server id 8.3.137.0; Fri, 30 Sep 2011 11:39:55 +0100 Subject: Re: [Xen-devel] [PATCH] tools/check: check for yajl (needed by libxl) From: Ian Campbell <Ian.Campbell@eu.citrix.com> To: Anthony PERARD <anthony.perard@citrix.com> Date: Fri, 30 Sep 2011 11:39:54 +0100 In-Reply-To: <CAJJyHjL55fNgwrmDVdCehaOLC1mPecf8M4fE4RCn_g_vygj=0A@mail.gmail.com> References: <4b98868690218126b906.1317368189@cosworth.uk.xensource.com> <CAJJyHjL55fNgwrmDVdCehaOLC1mPecf8M4fE4RCn_g_vygj=0A@mail.gmail.com> Organization: Citrix Systems, Inc. Content-Type: text/plain; charset="UTF-8" X-Mailer: Evolution 3.0.3- Content-Transfer-Encoding: 7bit Message-ID: <1317379194.26672.256.camel@zakaz.uk.xensource.com> MIME-Version: 1.0 Cc: Olaf Hering <olaf@aepfle.de>, "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com> X-BeenThere: xen-devel@lists.xensource.com X-Mailman-Version: 2.1.5 Precedence: list List-Id: Xen developer discussion <xen-devel.lists.xensource.com> List-Unsubscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe> List-Post: <mailto:xen-devel@lists.xensource.com> List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help> List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=subscribe> Sender: xen-devel-bounces@lists.xensource.com Errors-To: xen-devel-bounces@lists.xensource.com On Fri, 2011-09-30 at 11:35 +0100, Anthony PERARD wrote: > On Fri, Sep 30, 2011 at 08:36, Ian Campbell <ian.campbell@citrix.com> wrote: > > # HG changeset patch > > # User Ian Campbell <ian.campbell@citrix.com> > > # Date 1317367995 -3600 > > # Node ID 4b98868690218126b90620d9b43fdd4140145a43 > > # Parent e50da6b98e3d5933b9c98e8f43096fd3ebbae00d > > tools/check: check for yajl (needed by libxl) > > > > Signed-off-by: Ian Campbell <ian.campbell@citrix.com> > > --- > > (note to committer, ensure the new file is executable) > > > > diff -r e50da6b98e3d -r 4b9886869021 tools/check/check_yajl_lib > > --- /dev/null Thu Jan 01 00:00:00 1970 +0000 > > +++ b/tools/check/check_yajl_lib Fri Sep 30 08:33:15 2011 +0100 > > @@ -0,0 +1,7 @@ > > +#!/bin/sh > > +# CHECK-BUILD CHECK-INSTALL > > + > > +. ./funcs.sh > > + > > + > > +has_lib libyajl.so || fail "can't find yajl" > > You probably want to check the yajl headers as well, no ? > #include <yajl/yajl_parse.h> > #include <yajl/yajl_gen.h> tools/check seems a bit inconsistent and I'd expect them both to be in the -dev package but I guess it can't hurt. # HG changeset patch # User Ian Campbell <ian.campbell@citrix.com> # Date 1317379175 -3600 # Node ID de602616358b7def9351850f518e453c68141c4f # Parent 302b7556edd91a7506f2215bed5302b4b5eaa52a tools/check: check for yajl (needed by libxl) Signed-off-by: Ian Campbell <ian.campbell@citrix.com> --- (note to committer, ensure the new files are executable) diff -r 302b7556edd9 -r de602616358b tools/check/check_yajl_devel --- /dev/null Thu Jan 01 00:00:00 1970 +0000 +++ b/tools/check/check_yajl_devel Fri Sep 30 11:39:35 2011 +0100 @@ -0,0 +1,7 @@ +#!/bin/sh +# CHECK-BUILD CHECK-INSTALL + +. ./funcs.sh + +has_header yajl/yajl_parse.h || fail "can't find yajl/yajl_parse.h" +has_header yajl/yajl_gen.h || fail "can't find yajl/yajl_gen.h" diff -r 302b7556edd9 -r de602616358b tools/check/check_yajl_lib --- /dev/null Thu Jan 01 00:00:00 1970 +0000 +++ b/tools/check/check_yajl_lib Fri Sep 30 11:39:35 2011 +0100 @@ -0,0 +1,6 @@ +#!/bin/sh +# CHECK-BUILD CHECK-INSTALL + +. ./funcs.sh + +has_lib libyajl.so || fail "can't find libyajl.so" _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel From xen-devel-bounces@lists.xensource.com Fri Sep 30 03:51:01 2011 Return-path: <xen-devel-bounces@lists.xensource.com> Envelope-to: www-data@lists.xensource.com Delivery-date: Fri, 30 Sep 2011 03:51:01 -0700 Received: from localhost ([127.0.0.1] helo=lists.colo.xensource.com) by lists.xensource.com with esmtp (Exim 4.43) id 1R9agH-000619-Mh; Fri, 30 Sep 2011 03:51:01 -0700 Received: from mail182.messagelabs.com ([85.158.139.83]) by lists.xensource.com with esmtp (Exim 4.43) id 1R9afs-0005pZ-UE for xen-devel@lists.xensource.com; Fri, 30 Sep 2011 03:50:37 -0700 X-Env-Sender: JBeulich@suse.com X-Msg-Ref: server-15.tower-182.messagelabs.com!1317379833!19327549!1 X-Originating-IP: [130.57.49.28] X-StarScan-Version: 6.4.1; banners=-,-,- X-VirusChecked: Checked Received: (qmail 9078 invoked from network); 30 Sep 2011 10:50:34 -0000 Received: from nat28.tlf.novell.com (HELO nat28.tlf.novell.com) (130.57.49.28) by server-15.tower-182.messagelabs.com with DHE-RSA-AES256-SHA encrypted SMTP; 30 Sep 2011 10:50:34 -0000 Received: from EMEA1-MTA by nat28.tlf.novell.com with Novell_GroupWise; Fri, 30 Sep 2011 11:51:07 +0100 Message-Id: <4E85BB180200007800058BCF@nat28.tlf.novell.com> X-Mailer: Novell GroupWise Internet Agent 8.0.1 Date: Fri, 30 Sep 2011 11:50:32 +0100 From: "Jan Beulich" <JBeulich@suse.com> To: "David Vrabel" <david.vrabel@citrix.com> Subject: Re: [Xen-devel] [PATCH 0/4] xen: map foreign pages for shared rings by updating the PTEs directly References: <1317311612-15220-1-git-send-email-david.vrabel@citrix.com> <4E84B3FE02000078000588A9@nat28.tlf.novell.com> <4E84A0C0.6000804@citrix.com> <4E85951B0200007800058AF8@nat28.tlf.novell.com> <4E859697.1050906@citrix.com> In-Reply-To: <4E859697.1050906@citrix.com> Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: quoted-printable Content-Disposition: inline Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>, KonradRzeszutek Wilk <konrad.wilk@oracle.com> X-BeenThere: xen-devel@lists.xensource.com X-Mailman-Version: 2.1.5 Precedence: list List-Id: Xen developer discussion <xen-devel.lists.xensource.com> List-Unsubscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe> List-Post: <mailto:xen-devel@lists.xensource.com> List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help> List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=subscribe> Sender: xen-devel-bounces@lists.xensource.com Errors-To: xen-devel-bounces@lists.xensource.com >>> On 30.09.11 at 12:14, David Vrabel <david.vrabel@citrix.com> wrote: > On 30/09/11 09:08, Jan Beulich wrote: >>>>> On 29.09.11 at 18:45, David Vrabel <david.vrabel@citrix.com> wrote: >>> On 29/09/11 17:07, Jan Beulich wrote: >>>>>>> On 29.09.11 at 17:53, David Vrabel <david.vrabel@citrix.com> = wrote: >>>>> [Resend as requested by Konrad.] >>>>> >>>>> This series of patches allows the vmalloc_sync_all() to be removed >>>>> from alloc_vm_area() by getting the hypervisor to update the PTEs = (in >>>>> init_mm) directly rather than having the hypervisor look in the >>>>> current page tables to find the PTEs. >>>>> >>>>> Once the hypervisor has updated the PTEs, the normal mechanism of >>>>> syncing the page tables after a fault works as expected. >>>> >>>> Did you actually test that, and namely the case where alloc_vm_area() >>>> would result in a new top level page directory entry to get populated?= >>>> >>>> I cannot see how this new entry would propagate into other mm-s, and >>>> hence I cannot see how you can do away with calling vmalloc_sync_all()= >>>> just by changing how leaf page table entries get populated. >>> >>> I don't think this new behaviour of alloc_vm_area() is any different >>> from how a regular vmalloc() works. >>=20 >> Of course not. Callers of vmalloc() need to use vmalloc_sync_all() too >> before it is permitted to access the allocated space from an NMI >> handler or pass it into a hypercall. >=20 > The virtual addresses of the mapped rings are not accessed in an NMI > handler or a hypercall (before this patch set they were accessed in the > GNTTABOP_map_grant_ref hypercall, but no longer). >=20 > In the future, if something did want to pass the virtual address to a > hypercall it wouldn't need the vmalloc_sync() as it could disable > preemption, touch the page (so current->active_mm is updated), do the > hypercall, then disable preemption. And you verified that no other hypercall gets, perhaps indirectly, passed alloc_vm_area()ed memory? Jan _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel From xen-devel-bounces@lists.xensource.com Fri Sep 30 04:06:57 2011 Return-path: <xen-devel-bounces@lists.xensource.com> Envelope-to: www-data@lists.xensource.com Delivery-date: Fri, 30 Sep 2011 04:06:57 -0700 Received: from localhost ([127.0.0.1] helo=lists.colo.xensource.com) by lists.xensource.com with esmtp (Exim 4.43) id 1R9avf-0007Ku-Bc; Fri, 30 Sep 2011 04:06:55 -0700 Received: from mail21.messagelabs.com ([85.158.143.35]) by lists.xensource.com with esmtp (Exim 4.43) id 1R9atm-00077G-SR for xen-devel@lists.xensource.com; Fri, 30 Sep 2011 04:05:10 -0700 X-Env-Sender: Ian.Campbell@eu.citrix.com X-Msg-Ref: server-10.tower-21.messagelabs.com!1317380679!56124659!1 X-Originating-IP: [62.200.22.115] X-StarScan-Version: 6.4.1; banners=-,-,- X-VirusChecked: Checked Received: (qmail 14243 invoked from network); 30 Sep 2011 11:04:39 -0000 Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115) by server-10.tower-21.messagelabs.com with RC4-SHA encrypted SMTP; 30 Sep 2011 11:04:39 -0000 X-IronPort-AV: E=Sophos;i="4.68,466,1312156800"; d="scan'208";a="8148239" Received: from lonpmailmx01.citrite.net ([10.30.203.162]) by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5; 30 Sep 2011 11:04:54 +0000 Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net (10.30.203.162) with Microsoft SMTP Server id 8.3.137.0; Fri, 30 Sep 2011 12:04:55 +0100 Subject: Re: [Xen-devel] [PATCH 0/4] xen: map foreign pages for shared rings by updating the PTEs directly From: Ian Campbell <Ian.Campbell@citrix.com> To: Jan Beulich <JBeulich@suse.com> Date: Fri, 30 Sep 2011 12:04:54 +0100 In-Reply-To: <4E85BB180200007800058BCF@nat28.tlf.novell.com> References: <1317311612-15220-1-git-send-email-david.vrabel@citrix.com> <4E84B3FE02000078000588A9@nat28.tlf.novell.com> <4E84A0C0.6000804@citrix.com> <4E85951B0200007800058AF8@nat28.tlf.novell.com> <4E859697.1050906@citrix.com> <4E85BB180200007800058BCF@nat28.tlf.novell.com> Organization: Citrix Systems, Inc. Content-Type: text/plain; charset="UTF-8" X-Mailer: Evolution 3.0.3- Content-Transfer-Encoding: 7bit Message-ID: <1317380694.26672.263.camel@zakaz.uk.xensource.com> MIME-Version: 1.0 Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>, David Vrabel <david.vrabel@citrix.com>, KonradRzeszutek Wilk <konrad.wilk@oracle.com> X-BeenThere: xen-devel@lists.xensource.com X-Mailman-Version: 2.1.5 Precedence: list List-Id: Xen developer discussion <xen-devel.lists.xensource.com> List-Unsubscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe> List-Post: <mailto:xen-devel@lists.xensource.com> List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help> List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=subscribe> Sender: xen-devel-bounces@lists.xensource.com Errors-To: xen-devel-bounces@lists.xensource.com On Fri, 2011-09-30 at 11:50 +0100, Jan Beulich wrote: > >>> On 30.09.11 at 12:14, David Vrabel <david.vrabel@citrix.com> wrote: > > On 30/09/11 09:08, Jan Beulich wrote: > >>>>> On 29.09.11 at 18:45, David Vrabel <david.vrabel@citrix.com> wrote: > >>> On 29/09/11 17:07, Jan Beulich wrote: > >>>>>>> On 29.09.11 at 17:53, David Vrabel <david.vrabel@citrix.com> wrote: > >>>>> [Resend as requested by Konrad.] > >>>>> > >>>>> This series of patches allows the vmalloc_sync_all() to be removed > >>>>> from alloc_vm_area() by getting the hypervisor to update the PTEs (in > >>>>> init_mm) directly rather than having the hypervisor look in the > >>>>> current page tables to find the PTEs. > >>>>> > >>>>> Once the hypervisor has updated the PTEs, the normal mechanism of > >>>>> syncing the page tables after a fault works as expected. > >>>> > >>>> Did you actually test that, and namely the case where alloc_vm_area() > >>>> would result in a new top level page directory entry to get populated? > >>>> > >>>> I cannot see how this new entry would propagate into other mm-s, and > >>>> hence I cannot see how you can do away with calling vmalloc_sync_all() > >>>> just by changing how leaf page table entries get populated. > >>> > >>> I don't think this new behaviour of alloc_vm_area() is any different > >>> from how a regular vmalloc() works. > >> > >> Of course not. Callers of vmalloc() need to use vmalloc_sync_all() too > >> before it is permitted to access the allocated space from an NMI > >> handler or pass it into a hypercall. > > > > The virtual addresses of the mapped rings are not accessed in an NMI > > handler or a hypercall (before this patch set they were accessed in the > > GNTTABOP_map_grant_ref hypercall, but no longer). > > > > In the future, if something did want to pass the virtual address to a > > hypercall it wouldn't need the vmalloc_sync() as it could disable > > preemption, touch the page (so current->active_mm is updated), do the > > hypercall, then disable preemption. > > And you verified that no other hypercall gets, perhaps indirectly, > passed alloc_vm_area()ed memory? In the specific case of these functions, which map the rings, we believe this is the case. If there are other unrelated callsites then the failure to deal with this is an existing bug at that callsite, before or after this series (modulo the short term sticking plaster of putting the vmalloc_sync_all back, which was known not to be acceptable longterm when it went in -- hence this series). The only other use of alloc_vm_area is arch_gnttab_map_shared. IIRC the hypervisor does not use the linear map to get a guests grant table but those pages are owned by Xen and hence it has and uses its own mapping of them. Ian. > > Jan > > > _______________________________________________ > Xen-devel mailing list > Xen-devel@lists.xensource.com > http://lists.xensource.com/xen-devel _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel From xen-api-bounces@lists.xensource.com Fri Sep 30 04:17:01 2011 Return-path: <xen-api-bounces@lists.xensource.com> Envelope-to: www-data@lists.xensource.com Delivery-date: Fri, 30 Sep 2011 04:17:01 -0700 Received: from localhost ([127.0.0.1] helo=lists.colo.xensource.com) by lists.xensource.com with esmtp (Exim 4.43) id 1R9b5R-0007nC-1M; Fri, 30 Sep 2011 04:17:01 -0700 Received: from mail174.messagelabs.com ([85.158.138.51]) by lists.xensource.com with esmtp (Exim 4.43) id 1R9b5B-0007kC-GL; Fri, 30 Sep 2011 04:16:45 -0700 X-Env-Sender: lars.kurth.xen@gmail.com X-Msg-Ref: server-11.tower-174.messagelabs.com!1317381401!33350263!1 X-Originating-IP: [74.125.82.43] X-StarScan-Version: 6.4.1; banners=-,-,- X-VirusChecked: Checked Received: (qmail 19175 invoked from network); 30 Sep 2011 11:16:42 -0000 Received: from mail-ww0-f43.google.com (HELO mail-ww0-f43.google.com) (74.125.82.43) by server-11.tower-174.messagelabs.com with RC4-SHA encrypted SMTP; 30 Sep 2011 11:16:42 -0000 Received: by wwf27 with SMTP id 27so2069029wwf.24 for <multiple recipients>; Fri, 30 Sep 2011 04:16:41 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=sender:message-id:date:from:user-agent:mime-version:to:subject :content-type:content-transfer-encoding; bh=Ze5tiMKpwzhjPLmU1/Ylv5nF1fBNr3ZmtqKY9IbDrPc=; b=fvg0L/Z3hbhLXi/Pmx3hfExt07uHvDeidEUtxkgKtM2D8jvhP3XON1r0MQDGvFnVLR wq0XWToMcKgrFQ5DHcFkDQuy0G+PdGZU4fUjK2suO7nvEVze+CiLn/D9/oyVnYgPy0TT QNQQfdOK4qq6BaDB02HjtQ8YUYYqZgo06ZX+0= Received: by 10.216.188.194 with SMTP id a44mr4613148wen.4.1317381399720; Fri, 30 Sep 2011 04:16:39 -0700 (PDT) Received: from [172.16.25.10] (02d933ea.bb.sky.com. [2.217.51.234]) by mx.google.com with ESMTPS id l9sm2246306wba.5.2011.09.30.04.16.37 (version=SSLv3 cipher=OTHER); Fri, 30 Sep 2011 04:16:38 -0700 (PDT) Message-ID: <4E85A513.6030403@xen.org> Date: Fri, 30 Sep 2011 12:16:35 +0100 From: Lars Kurth <lars.kurth@xen.org> User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:7.0) Gecko/20110922 Thunderbird/7.0 MIME-Version: 1.0 To: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>, "xen-api@lists.xensource.com" <xen-api@lists.xensource.com>, xen-arm@lists.xensource.com Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: Subject: [Xen-API] Please welcome Jan Beulich as Xen committer & revisions to Xen governance X-BeenThere: xen-api@lists.xensource.com X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussion of API issues surrounding Xen <xen-api.lists.xensource.com> List-Unsubscribe: <http://lists.xensource.com/mailman/listinfo/xen-api>, <mailto:xen-api-request@lists.xensource.com?subject=unsubscribe> List-Post: <mailto:xen-api@lists.xensource.com> List-Help: <mailto:xen-api-request@lists.xensource.com?subject=help> List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-api>, <mailto:xen-api-request@lists.xensource.com?subject=subscribe> Sender: xen-api-bounces@lists.xensource.com Errors-To: xen-api-bounces@lists.xensource.com Dear Xen developers, I wanted to announce that Jan Beulich has been nominated for as Xen Hypervisor committer and confirmed by vote by the other Xen committers (which are Keir Fraser, Tim Deegan and Ian Jackson). Jan's Contribution ================== Jan has made a tremendous contribution to the project over the years and was was one of the top 3 contributors to the project for several years. Just to quote a few stats - 2009 : 107 patches changing 11746 lines of code - 2010 : 147 patches changing 7613 lines of code - 2011 : 204 patches changing 2655 lines of code Congratulations! I do have to apologize that we did not entirely follow the new governance process as described at http://www.xen.org/projects/governance.html due to an oversight. The nomination and vote was meant to happen in public, but has happened in private amongst the existing committers. We will do better next time. This exercise has also shown some bugs in the process which need fixing. Bugs in the Process =================== See http://www.xen.org/projects/governance.html) Committer vs. Maintainers: The process talks about maintainers as if they were committers and mixes some aspects of both roles. This is incorrect. PROPOSED FIXES: - Split the role into two - What is a maintainer? - A maintainer owns one or several component in the Xen tree - A maintainer reviews and approves changes that affect their component - Note that some components will be owned by several maintainers (in that case consensus decision making applies) - Election: new maintainers are nominated and voted for by other maintainers - What is a committer? - A maintainer with write access to the code tree - The committer acts on the wishes of the maintainers and applies changes approved by the respective maintainer(s). - Helps resolve disagreements between maintainers of the same component should they arise - Election: new committers are nominated and voted for only by other committers - Allow a committer to be a sponsor for a new Xen.org project - Reflect above changes in Elections - I believe we should keep "Project Lead Elections" as it is (We could restrict elections to committers, but in practice committers will have a much higher chance to be elected. I believe we should leave things as they are.) Please let me know your views, by responding to this thread. If there are no objections by next friday, Oct 7th, we will just update the document. And then give another week for additional discussion and the change will be considered approved. Regards Lars _______________________________________________ xen-api mailing list xen-api@lists.xensource.com http://lists.xensource.com/mailman/listinfo/xen-api From xen-devel-bounces@lists.xensource.com Fri Sep 30 04:39:05 2011 Return-path: <xen-devel-bounces@lists.xensource.com> Envelope-to: www-data@lists.xensource.com Delivery-date: Fri, 30 Sep 2011 04:39:05 -0700 Received: from localhost ([127.0.0.1] helo=lists.colo.xensource.com) by lists.xensource.com with esmtp (Exim 4.43) id 1R9bQn-0002iX-Dj; Fri, 30 Sep 2011 04:39:05 -0700 Received: from mail216.messagelabs.com ([85.158.143.99]) by lists.xensource.com with esmtp (Exim 4.43) id 1R9bOy-00025J-3g; Fri, 30 Sep 2011 04:37:13 -0700 X-Env-Sender: lars.kurth.xen@gmail.com X-Msg-Ref: server-10.tower-216.messagelabs.com!1317382627!10366202!1 X-Originating-IP: [74.125.82.43] X-StarScan-Version: 6.4.1; banners=-,-,- X-VirusChecked: Checked Received: (qmail 5084 invoked from network); 30 Sep 2011 11:37:08 -0000 Received: from mail-ww0-f43.google.com (HELO mail-ww0-f43.google.com) (74.125.82.43) by server-10.tower-216.messagelabs.com with RC4-SHA encrypted SMTP; 30 Sep 2011 11:37:08 -0000 Received: by wwf27 with SMTP id 27so2092282wwf.24 for <multiple recipients>; Fri, 30 Sep 2011 04:37:07 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=sender:message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:content-type; bh=Lb6EODB94uFSujhu2UFKn08MTdKZ7wEJrLRepxLs8WY=; b=igu3ha4rnzwpCtlWajwNhW7OhI7D27V7rc5u6abd7Smx0gMKPzi7daHWV9AZuDnnGV uX2Hu6kzarXybr+YL8sFJ4slRGXyUqXWJ4ZeXNOEKoXfo+ZjtgtClixrwghHZk1NHzkS ZlpheQx74ELCQpdGk8U+0BhrSb7hzTyV9zO6U= Received: by 10.216.80.69 with SMTP id j47mr2676713wee.102.1317382627600; Fri, 30 Sep 2011 04:37:07 -0700 (PDT) Received: from [172.16.25.10] (02d933ea.bb.sky.com. [2.217.51.234]) by mx.google.com with ESMTPS id l40sm8705522wbm.10.2011.09.30.04.36.25 (version=SSLv3 cipher=OTHER); Fri, 30 Sep 2011 04:36:45 -0700 (PDT) Message-ID: <4E85A9B7.7040605@xen.org> Date: Fri, 30 Sep 2011 12:36:23 +0100 From: Lars Kurth <lars.kurth@xen.org> User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:7.0) Gecko/20110922 Thunderbird/7.0 MIME-Version: 1.0 To: Joseph Glanville <joseph.glanville@orionvm.com.au> Subject: Re: [Xen-devel] Xen document day (Oct 12 or 26) References: <20110922130618.GA13238@phenom.oracle.com> <20110929141317.GX12984@reaktio.net> <CAOzFzEieWhgoBWEXQFjqr8PYoVOAcU20rtA2Q3OhyA+=dD9Atg@mail.gmail.com> In-Reply-To: <CAOzFzEieWhgoBWEXQFjqr8PYoVOAcU20rtA2Q3OhyA+=dD9Atg@mail.gmail.com> Cc: xen-devel@lists.xensource.com, xen-users@lists.xensource.com, Konrad Rzeszutek Wilk <konrad.wilk@oracle.com> X-BeenThere: xen-devel@lists.xensource.com X-Mailman-Version: 2.1.5 Precedence: list List-Id: Xen developer discussion <xen-devel.lists.xensource.com> List-Unsubscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe> List-Post: <mailto:xen-devel@lists.xensource.com> List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help> List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=subscribe> Content-Type: multipart/mixed; boundary="===============0275740210==" Sender: xen-devel-bounces@lists.xensource.com Errors-To: xen-devel-bounces@lists.xensource.com This is a multi-part message in MIME format. --===============0275740210== Content-Type: multipart/alternative; boundary="------------000704050206060807020405" This is a multi-part message in MIME format. --------------000704050206060807020405 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Let me know, which date you agreed on. We could do a poll. We should publish on the blog a bit before. Also, how can I help? Regards Lars On 29/09/2011 15:22, Joseph Glanville wrote: > > On 30 September 2011 00:13, Pasi Kärkkäinen <pasik@iki.fi > <mailto:pasik@iki.fi>> wrote: > > On Thu, Sep 22, 2011 at 09:06:18AM -0400, Konrad Rzeszutek Wilk wrote: > > Part of what we brainstormed at Xen Hackathon was what we could > do make Xen easier. > > > > And the one thing that seemed to surface up was making the docs > better - either > > be the Wiki or the three .pdfs that get created/shipped with Xen. > > > > One thought was to come up with a Documention Day - where > volunteers would try to > > fix up some portion of the documentation that they feel they have > > a good grasp of knowledge off and are willing to change (and > also look > > to be incorrect) > > > > What do you guys think of Oct 12th or Oct 26 as a day for this? > > > > And then the next question - what page/pdf section interests you? > > > > http://bits.xensource.com/Xen/docs/user.pdf > > http://www.rites.uic.edu/~solworth/xenInterfaceManual.pdf > <http://www.rites.uic.edu/%7Esolworth/xenInterfaceManual.pdf> [the > one on Xen.org is an older version] > > > > Or Wiki pages: > > http://wiki.xensource.com/xenwiki/ > > > > http://wiki.xensource.com/xenwiki/XenDom0Kernels > > http://wiki.xensource.com/xenwiki/XenSerialConsole > > http://wiki.xensource.com/xenwiki/XenParavirtOps > > http://wiki.xensource.com/xenwiki/XenCommonProblems > > > > http://wiki.xensource.com/xenwiki/Consulting > > http://wiki.xensource.com/xenwiki/Consultants > > http://wiki.xensource.com/xenwiki/VpsHostingWithXen > > > > http://wiki.xen.org/xenwiki/XenPCIpassthrough > > http://wiki.xen.org/xenwiki/VTdHowTo > > > > Some more related pages: > http://wiki.xen.org/xenwiki/Xen4.0 > http://wiki.xen.org/xenwiki/Xen4.1 > http://wiki.xen.org/xenwiki/XenKernelFeatures > http://wiki.xen.org/xenwiki/XenBestPractices > http://wiki.xen.org/xenwiki/XenHypervisorBootOptions > > Also there's something completely new that we should document: > How to install Xen VMs! which means document all the relevant methods: > boot the native distro installer as PV guest, as HVM guest, > xen-tools, virt-install, > debootstrap, rpmstart, etc.. > > That's something people ask about very often.. > > Agreed. > > After working through a bunch of the pages I think we are going to > have to have a realtime collab session to decide on some way of > reorganising everything into categories. > > > > -- Pasi > > > _______________________________________________ > Xen-devel mailing list > Xen-devel@lists.xensource.com <mailto:Xen-devel@lists.xensource.com> > http://lists.xensource.com/xen-devel > > > > > -- > */ > Founder | Director | VP Research > Orion Virtualisation Solutions/* | www.orionvm.com.au > <http://www.orionvm.com.au/> | Phone: 1300 56 99 52 | Mobile: 0428 754 846 > > > _______________________________________________ > Xen-devel mailing list > Xen-devel@lists.xensource.com > http://lists.xensource.com/xen-devel --------------000704050206060807020405 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit <html> <head> <meta content="text/html; charset=ISO-8859-1" http-equiv="Content-Type"> </head> <body bgcolor="#FFFFFF" text="#000000"> Let me know, which date you agreed on. We could do a poll.<br> We should publish on the blog a bit before.<br> Also, how can I help?<br> Regards<br> Lars<br> <br> On 29/09/2011 15:22, Joseph Glanville wrote: <blockquote cite="mid:CAOzFzEieWhgoBWEXQFjqr8PYoVOAcU20rtA2Q3OhyA+=dD9Atg@mail.gmail.com" type="cite"><br> <div class="gmail_quote">On 30 September 2011 00:13, Pasi Kärkkäinen <span dir="ltr"><<a moz-do-not-send="true" href="mailto:pasik@iki.fi">pasik@iki.fi</a>></span> wrote:<br> <blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;"> <div class="im">On Thu, Sep 22, 2011 at 09:06:18AM -0400, Konrad Rzeszutek Wilk wrote:<br> > Part of what we brainstormed at Xen Hackathon was what we could do make Xen easier.<br> ><br> > And the one thing that seemed to surface up was making the docs better - either<br> > be the Wiki or the three .pdfs that get created/shipped with Xen.<br> ><br> > One thought was to come up with a Documention Day - where volunteers would try to<br> > fix up some portion of the documentation that they feel they have<br> > a good grasp of knowledge off and are willing to change (and also look<br> > to be incorrect)<br> ><br> > What do you guys think of Oct 12th or Oct 26 as a day for this?<br> ><br> > And then the next question - what page/pdf section interests you?<br> ><br> > <a moz-do-not-send="true" href="http://bits.xensource.com/Xen/docs/user.pdf" target="_blank">http://bits.xensource.com/Xen/docs/user.pdf</a><br> > <a moz-do-not-send="true" href="http://www.rites.uic.edu/%7Esolworth/xenInterfaceManual.pdf" target="_blank">http://www.rites.uic.edu/~solworth/xenInterfaceManual.pdf</a> [the one on Xen.org is an older version]<br> ><br> > Or Wiki pages:<br> > <a moz-do-not-send="true" href="http://wiki.xensource.com/xenwiki/" target="_blank">http://wiki.xensource.com/xenwiki/</a><br> ><br> > <a moz-do-not-send="true" href="http://wiki.xensource.com/xenwiki/XenDom0Kernels" target="_blank">http://wiki.xensource.com/xenwiki/XenDom0Kernels</a><br> > <a moz-do-not-send="true" href="http://wiki.xensource.com/xenwiki/XenSerialConsole" target="_blank">http://wiki.xensource.com/xenwiki/XenSerialConsole</a><br> > <a moz-do-not-send="true" href="http://wiki.xensource.com/xenwiki/XenParavirtOps" target="_blank">http://wiki.xensource.com/xenwiki/XenParavirtOps</a><br> > <a moz-do-not-send="true" href="http://wiki.xensource.com/xenwiki/XenCommonProblems" target="_blank">http://wiki.xensource.com/xenwiki/XenCommonProblems</a><br> ><br> > <a moz-do-not-send="true" href="http://wiki.xensource.com/xenwiki/Consulting" target="_blank">http://wiki.xensource.com/xenwiki/Consulting</a><br> > <a moz-do-not-send="true" href="http://wiki.xensource.com/xenwiki/Consultants" target="_blank">http://wiki.xensource.com/xenwiki/Consultants</a><br> > <a moz-do-not-send="true" href="http://wiki.xensource.com/xenwiki/VpsHostingWithXen" target="_blank">http://wiki.xensource.com/xenwiki/VpsHostingWithXen</a><br> ><br> > <a moz-do-not-send="true" href="http://wiki.xen.org/xenwiki/XenPCIpassthrough" target="_blank">http://wiki.xen.org/xenwiki/XenPCIpassthrough</a><br> > <a moz-do-not-send="true" href="http://wiki.xen.org/xenwiki/VTdHowTo" target="_blank">http://wiki.xen.org/xenwiki/VTdHowTo</a><br> ><br> <br> </div> Some more related pages:<br> <a moz-do-not-send="true" href="http://wiki.xen.org/xenwiki/Xen4.0" target="_blank">http://wiki.xen.org/xenwiki/Xen4.0</a><br> <a moz-do-not-send="true" href="http://wiki.xen.org/xenwiki/Xen4.1" target="_blank">http://wiki.xen.org/xenwiki/Xen4.1</a><br> <a moz-do-not-send="true" href="http://wiki.xen.org/xenwiki/XenKernelFeatures" target="_blank">http://wiki.xen.org/xenwiki/XenKernelFeatures</a><br> <a moz-do-not-send="true" href="http://wiki.xen.org/xenwiki/XenBestPractices" target="_blank">http://wiki.xen.org/xenwiki/XenBestPractices</a><br> <a moz-do-not-send="true" href="http://wiki.xen.org/xenwiki/XenHypervisorBootOptions" target="_blank">http://wiki.xen.org/xenwiki/XenHypervisorBootOptions</a><br> <br> Also there's something completely new that we should document:<br> How to install Xen VMs! which means document all the relevant methods:<br> boot the native distro installer as PV guest, as HVM guest, xen-tools, virt-install,<br> debootstrap, rpmstart, etc..<br> <br> That's something people ask about very often..<br> </blockquote> <div> </div> <div>Agreed. <br> <br> After working through a bunch of the pages I think we are going to have to have a realtime collab session to decide on some way of reorganising everything into categories.<br> <br> <br> </div> <blockquote class="gmail_quote" style="margin: 0pt 0pt 0pt 0.8ex; border-left: 1px solid rgb(204, 204, 204); padding-left: 1ex;"> <font color="#888888"><br> -- Pasi<br> </font> <div> <div class="h5"><br> <br> _______________________________________________<br> Xen-devel mailing list<br> <a moz-do-not-send="true" href="mailto:Xen-devel@lists.xensource.com">Xen-devel@lists.xensource.com</a><br> <a moz-do-not-send="true" href="http://lists.xensource.com/xen-devel" target="_blank">http://lists.xensource.com/xen-devel</a><br> </div> </div> </blockquote> </div> <br> <br clear="all"> <br> -- <br> <span style="font-family:arial,sans-serif;font-size:13px;border-collapse:collapse"><b><i><font color="#0000ff"> <div><font color="#000000"><span style="font-style:normal;font-weight:normal">Founder | Director | VP Research<br> </span></font></div> Orion Virtualisation Solutions</font></i></b> | <font color="#0000ff"><a moz-do-not-send="true" href="http://www.orionvm.com.au/" style="color:rgb(42, 93, 176)" target="_blank">www.orionvm.com.au</a></font> | Phone: 1300 56 99 52 | Mobile: 0428 754 846</span><br> <br> <fieldset class="mimeAttachmentHeader"></fieldset> <br> <pre wrap="">_______________________________________________ Xen-devel mailing list <a class="moz-txt-link-abbreviated" href="mailto:Xen-devel@lists.xensource.com">Xen-devel@lists.xensource.com</a> <a class="moz-txt-link-freetext" href="http://lists.xensource.com/xen-devel">http://lists.xensource.com/xen-devel</a> </pre> </blockquote> <br> </body> </html> --------------000704050206060807020405-- --===============0275740210== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel --===============0275740210==-- From xen-devel-bounces@lists.xensource.com Fri Sep 30 04:48:14 2011 Return-path: <xen-devel-bounces@lists.xensource.com> Envelope-to: www-data@lists.xensource.com Delivery-date: Fri, 30 Sep 2011 04:48:14 -0700 Received: from localhost ([127.0.0.1] helo=lists.colo.xensource.com) by lists.xensource.com with esmtp (Exim 4.43) id 1R9bZd-0003r6-Oy; Fri, 30 Sep 2011 04:48:13 -0700 Received: from mail27.messagelabs.com ([193.109.254.147]) by lists.xensource.com with smtp (Exim 4.43) id 1R9bYu-0003eg-5k for xen-devel@lists.xensource.com; Fri, 30 Sep 2011 04:47:28 -0700 X-Env-Sender: jinsong.liu@intel.com X-Msg-Ref: server-15.tower-27.messagelabs.com!1317383234!48955358!1 X-Originating-IP: [143.182.124.37] X-StarScan-Version: 6.4.1; banners=-,-,- X-VirusChecked: Checked Received: (qmail 25682 invoked from network); 30 Sep 2011 11:47:15 -0000 Received: from mga14.intel.com (HELO mga14.intel.com) (143.182.124.37) by server-15.tower-27.messagelabs.com with SMTP; 30 Sep 2011 11:47:15 -0000 Received: from azsmga001.ch.intel.com ([10.2.17.19]) by azsmga102.ch.intel.com with ESMTP; 30 Sep 2011 04:47:23 -0700 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="4.68,466,1312182000"; d="scan'208";a="57356683" Received: from pgsmsx601.gar.corp.intel.com ([10.221.43.69]) by azsmga001.ch.intel.com with ESMTP; 30 Sep 2011 04:47:23 -0700 Received: from pgsmsx101.gar.corp.intel.com (10.221.44.78) by pgsmsx601.gar.corp.intel.com (10.221.43.69) with Microsoft SMTP Server (TLS) id 8.2.255.0; Fri, 30 Sep 2011 19:47:22 +0800 Received: from shsmsx601.ccr.corp.intel.com (10.239.4.112) by PGSMSX101.gar.corp.intel.com (10.221.44.78) with Microsoft SMTP Server (TLS) id 14.1.323.3; Fri, 30 Sep 2011 19:47:21 +0800 Received: from shsmsx502.ccr.corp.intel.com ([10.239.4.96]) by shsmsx601.ccr.corp.intel.com ([10.239.4.112]) with mapi; Fri, 30 Sep 2011 19:47:20 +0800 From: "Liu, Jinsong" <jinsong.liu@intel.com> To: "Liu, Jinsong" <jinsong.liu@intel.com>, Jan Beulich <JBeulich@suse.com>, "Jiang, Yunhong" <yunhong.jiang@intel.com> Date: Fri, 30 Sep 2011 19:47:19 +0800 Subject: RE: [Xen-devel] [PATCH] X86 MCE: Add SRAR handler Thread-Topic: [Xen-devel] [PATCH] X86 MCE: Add SRAR handler Thread-Index: Acx/WI2JGiAAymCbSU+OG6bGavY8HgAAEC9gAANiRDA= Message-ID: <BC00F5384FCFC9499AF06F92E8B78A9E263B557F90@shsmsx502.ccr.corp.intel.com> References: <BC00F5384FCFC9499AF06F92E8B78A9E263B557B77@shsmsx502.ccr.corp.intel.com> <4E84ADF70200007800058882@nat28.tlf.novell.com> <789F9655DD1B8F43B48D77C5D306597312D2366A9B@shsmsx501.ccr.corp.intel.com> <4E858AF30200007800058A64@nat28.tlf.novell.com> <BC00F5384FCFC9499AF06F92E8B78A9E263B557F02@shsmsx502.ccr.corp.intel.com> <4E8592A60200007800058AD4@nat28.tlf.novell.com> <BC00F5384FCFC9499AF06F92E8B78A9E263B557F40@shsmsx502.ccr.corp.intel.com> <4E859D7F0200007800058B39@nat28.tlf.novell.com> <BC00F5384FCFC9499AF06F92E8B78A9E263B557F7C@shsmsx502.ccr.corp.intel.com> <4E85B09F0200007800058B7B@nat28.tlf.novell.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "keir.xen@gmail.com" <keir.xen@gmail.com>, "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com> X-BeenThere: xen-devel@lists.xensource.com X-Mailman-Version: 2.1.5 Precedence: list List-Id: Xen developer discussion <xen-devel.lists.xensource.com> List-Unsubscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe> List-Post: <mailto:xen-devel@lists.xensource.com> List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help> List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=subscribe> Sender: xen-devel-bounces@lists.xensource.com Errors-To: xen-devel-bounces@lists.xensource.com Liu, Jinsong wrote: > Jan Beulich wrote: >>>>> On 30.09.11 at 11:42, "Liu, Jinsong" <jinsong.liu@intel.com> >>>>> wrote:=20 >>> Jan Beulich wrote: >>>>>>> On 30.09.11 at 10:21, "Liu, Jinsong" <jinsong.liu@intel.com> >>>>>>> wrote: >>>>> Executing guest code will not satisfy the check >>>>> if ( !(gstatus & MCG_STATUS_RIPV) && !guest_mode(regs)) return >>>>> -1; so it would not panic system. >>>>=20 >>>> Exactly. But it should when the prefetch was to hypervisor code. >>>>=20 >>>=20 >>> Wouldn't processor refresh instruction prefetch queue under such >>> case? >>=20 >> That's a question that you are better positioned to answer than me. >> But the SRAR errors being a sub-category of uncorrected errors I >> would think it can't be that simple. >>=20 >=20 > Hmm, I will check this question internally first. > BTW, we would have 7 days holiday (1/10 ~ 7/10), so email reply maybe > some slow.=20 >=20 > Thanks, > Jinsong Ah, just think our talking context: the prefetched instruction would have b= een flushed since we now at mce exception context. So I think no need to overkill here, just let guest handle it --> who own, = who take. Thanks, Jinsong= _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel From xen-devel-bounces@lists.xensource.com Fri Sep 30 05:05:19 2011 Return-path: <xen-devel-bounces@lists.xensource.com> Envelope-to: www-data@lists.xensource.com Delivery-date: Fri, 30 Sep 2011 05:05:19 -0700 Received: from localhost ([127.0.0.1] helo=lists.colo.xensource.com) by lists.xensource.com with esmtp (Exim 4.43) id 1R9bqA-00058p-UQ; Fri, 30 Sep 2011 05:05:18 -0700 Received: from mail27.messagelabs.com ([193.109.254.147]) by lists.xensource.com with esmtp (Exim 4.43) id 1R9bnP-0004tB-Nj for xen-devel@lists.xensource.com; Fri, 30 Sep 2011 05:02:34 -0700 X-Env-Sender: olaf@aepfle.de X-Msg-Ref: server-12.tower-27.messagelabs.com!1317384127!44590001!1 X-Originating-IP: [81.169.146.162] X-StarScan-Version: 6.4.1; banners=-,-,- X-VirusChecked: Checked Received: (qmail 14352 invoked from network); 30 Sep 2011 12:02:07 -0000 Received: from mo-p00-ob.rzone.de (HELO mo-p00-ob.rzone.de) (81.169.146.162) by server-12.tower-27.messagelabs.com with EDH-RSA-DES-CBC3-SHA encrypted SMTP; 30 Sep 2011 12:02:07 -0000 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; t=1317384143; l=244; s=domk; d=aepfle.de; h=In-Reply-To:Content-Type:MIME-Version:References:Subject:Cc:To:From: Date:X-RZG-CLASS-ID:X-RZG-AUTH; bh=A8ZQV0HM6R1yryapl9Rnc38velo=; b=oYll7uXcCgcOQ0NCGeHQJ/MeHQ5TMRU90P37crZz5lofuxH+xDPkJDxdeqoXs1Tzhij nHh2Kto93BeVz2QleiJbdJt7sJwdhQ/jqHyuOLBcBbq9wfPbBX9F4QMh3xCRBTRR0Zeen 8BEzwbTjP519vsUiJAtfN0z8XwhCppzgNPQ= X-RZG-AUTH: :P2EQZWCpfu+qG7CngxMFH1J+zrwiavkK6tmQaLfmztM8TOFPjzcQElpryw== X-RZG-CLASS-ID: mo00 Received: from probook.site (dslb-088-065-114-112.pools.arcor-ip.net [88.65.114.112]) by smtp.strato.de (fruni mo30) (RZmta 26.9 AUTH) with (EDH-RSA-DES-CBC3-SHA encrypted) ESMTPA id n045f4n8UBdd4D ; Fri, 30 Sep 2011 14:02:12 +0200 (MEST) Received: by probook.site (Postfix, from userid 1000) id 5B89C18B65; Fri, 30 Sep 2011 14:02:11 +0200 (CEST) Date: Fri, 30 Sep 2011 14:02:11 +0200 From: Olaf Hering <olaf@aepfle.de> To: Ian Campbell <ian.campbell@citrix.com> Message-ID: <20110930120210.GA25618@aepfle.de> References: <4b98868690218126b906.1317368189@cosworth.uk.xensource.com> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline In-Reply-To: <4b98868690218126b906.1317368189@cosworth.uk.xensource.com> User-Agent: Mutt/1.5.21.rev5535 (2011-07-01) Cc: Anthony.Perard@citrix.com, xen-devel@lists.xensource.com Subject: [Xen-devel] Re: [PATCH] tools/check: check for yajl (needed by libxl) X-BeenThere: xen-devel@lists.xensource.com X-Mailman-Version: 2.1.5 Precedence: list List-Id: Xen developer discussion <xen-devel.lists.xensource.com> List-Unsubscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe> List-Post: <mailto:xen-devel@lists.xensource.com> List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help> List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=subscribe> Sender: xen-devel-bounces@lists.xensource.com Errors-To: xen-devel-bounces@lists.xensource.com On Fri, Sep 30, Ian Campbell wrote: > (note to committer, ensure the new file is executable) Please dont, thats not patch friendly. Shouldnt all script files be called with like '$interpreter $script' instead of './$script'? Olaf _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel From xen-devel-bounces@lists.xensource.com Fri Sep 30 05:08:36 2011 Return-path: <xen-devel-bounces@lists.xensource.com> Envelope-to: www-data@lists.xensource.com Delivery-date: Fri, 30 Sep 2011 05:08:36 -0700 Received: from localhost ([127.0.0.1] helo=lists.colo.xensource.com) by lists.xensource.com with esmtp (Exim 4.43) id 1R9btL-0005Xp-Gd; Fri, 30 Sep 2011 05:08:36 -0700 Received: from mail182.messagelabs.com ([85.158.139.83]) by lists.xensource.com with esmtp (Exim 4.43) id 1R9bs0-0005L0-QD for xen-devel@lists.xensource.com; Fri, 30 Sep 2011 05:07:14 -0700 X-Env-Sender: Ian.Campbell@eu.citrix.com X-Msg-Ref: server-5.tower-182.messagelabs.com!1317384429!15385873!1 X-Originating-IP: [62.200.22.115] X-StarScan-Version: 6.4.1; banners=-,-,- X-VirusChecked: Checked Received: (qmail 9175 invoked from network); 30 Sep 2011 12:07:09 -0000 Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115) by server-5.tower-182.messagelabs.com with RC4-SHA encrypted SMTP; 30 Sep 2011 12:07:09 -0000 X-IronPort-AV: E=Sophos;i="4.68,467,1312156800"; d="scan'208";a="8149901" Received: from lonpmailmx01.citrite.net ([10.30.203.162]) by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5; 30 Sep 2011 12:07:09 +0000 Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net (10.30.203.162) with Microsoft SMTP Server id 8.3.137.0; Fri, 30 Sep 2011 13:07:08 +0100 From: Ian Campbell <Ian.Campbell@eu.citrix.com> To: Olaf Hering <olaf@aepfle.de> Date: Fri, 30 Sep 2011 13:07:08 +0100 In-Reply-To: <20110930120210.GA25618@aepfle.de> References: <4b98868690218126b906.1317368189@cosworth.uk.xensource.com> <20110930120210.GA25618@aepfle.de> Organization: Citrix Systems, Inc. Content-Type: text/plain; charset="UTF-8" X-Mailer: Evolution 3.0.3- Content-Transfer-Encoding: 7bit Message-ID: <1317384428.26672.269.camel@zakaz.uk.xensource.com> MIME-Version: 1.0 Cc: Anthony, Perard <anthony.perard@citrix.com>, "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com> Subject: [Xen-devel] Re: [PATCH] tools/check: check for yajl (needed by libxl) X-BeenThere: xen-devel@lists.xensource.com X-Mailman-Version: 2.1.5 Precedence: list List-Id: Xen developer discussion <xen-devel.lists.xensource.com> List-Unsubscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe> List-Post: <mailto:xen-devel@lists.xensource.com> List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help> List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=subscribe> Sender: xen-devel-bounces@lists.xensource.com Errors-To: xen-devel-bounces@lists.xensource.com On Fri, 2011-09-30 at 13:02 +0100, Olaf Hering wrote: > On Fri, Sep 30, Ian Campbell wrote: > > > (note to committer, ensure the new file is executable) > > Please dont, thats not patch friendly. > > Shouldnt all script files be called with like > '$interpreter $script' instead of './$script'? In general I agree, but that isn't how it the infrastructure in tools/check/chk works right now. Ian. _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel From xen-devel-bounces@lists.xensource.com Fri Sep 30 05:16:43 2011 Return-path: <xen-devel-bounces@lists.xensource.com> Envelope-to: www-data@lists.xensource.com Delivery-date: Fri, 30 Sep 2011 05:16:43 -0700 Received: from localhost ([127.0.0.1] helo=lists.colo.xensource.com) by lists.xensource.com with esmtp (Exim 4.43) id 1R9c1D-00060m-Bs; Fri, 30 Sep 2011 05:16:43 -0700 Received: from mail216.messagelabs.com ([85.158.143.99]) by lists.xensource.com with esmtp (Exim 4.43) id 1R9c0b-0005ow-Gw for xen-devel@lists.xensource.com; Fri, 30 Sep 2011 05:16:06 -0700 X-Env-Sender: olaf@aepfle.de X-Msg-Ref: server-9.tower-216.messagelabs.com!1317384959!20151177!1 X-Originating-IP: [81.169.146.161] X-StarScan-Version: 6.4.1; banners=-,-,- X-VirusChecked: Checked Received: (qmail 28942 invoked from network); 30 Sep 2011 12:16:02 -0000 Received: from mo-p00-ob.rzone.de (HELO mo-p00-ob.rzone.de) (81.169.146.161) by server-9.tower-216.messagelabs.com with EDH-RSA-DES-CBC3-SHA encrypted SMTP; 30 Sep 2011 12:16:02 -0000 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; t=1317384959; l=730; s=domk; d=aepfle.de; h=In-Reply-To:Content-Type:MIME-Version:References:Subject:Cc:To:From: Date:X-RZG-CLASS-ID:X-RZG-AUTH; bh=2csq1r85+9lDoJ77QuBBjyZx8Qs=; b=wg5rPjzsYeu0TXDdByvq9OXysrskpTcSCq54bILpTfOtYRiC4dcYbKsIliYIO8GoOkV GyVK5kRxlCPE+o7Kd1Um37bJuXQRGMSzCPwq1475krKlZrMQ/J3Z2fwBku3IgrJzm2hqt ifNjJZoQ/z+w5s0Yg5uEq47dwrI4uNSwnno= X-RZG-AUTH: :P2EQZWCpfu+qG7CngxMFH1J+zrwiavkK6tmQaLfmztM8TOFPjzcQElpryw== X-RZG-CLASS-ID: mo00 Received: from probook.site (dslb-088-065-114-112.pools.arcor-ip.net [88.65.114.112]) by post.strato.de (mrclete mo35) (RZmta 26.7) with (EDH-RSA-DES-CBC3-SHA encrypted) ESMTPA id a02c80n8UBBaxg ; Fri, 30 Sep 2011 14:15:43 +0200 (MEST) Received: by probook.site (Postfix, from userid 1000) id 7A1AE18B65; Fri, 30 Sep 2011 14:15:42 +0200 (CEST) Date: Fri, 30 Sep 2011 14:15:42 +0200 From: Olaf Hering <olaf@aepfle.de> To: Ian Campbell <Ian.Campbell@eu.citrix.com> Message-ID: <20110930121542.GA25896@aepfle.de> References: <4b98868690218126b906.1317368189@cosworth.uk.xensource.com> <20110930120210.GA25618@aepfle.de> <1317384428.26672.269.camel@zakaz.uk.xensource.com> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline In-Reply-To: <1317384428.26672.269.camel@zakaz.uk.xensource.com> User-Agent: Mutt/1.5.21.rev5535 (2011-07-01) Cc: Anthony Perard <anthony.perard@citrix.com>, "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com> Subject: [Xen-devel] Re: [PATCH] tools/check: check for yajl (needed by libxl) X-BeenThere: xen-devel@lists.xensource.com X-Mailman-Version: 2.1.5 Precedence: list List-Id: Xen developer discussion <xen-devel.lists.xensource.com> List-Unsubscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe> List-Post: <mailto:xen-devel@lists.xensource.com> List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help> List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=subscribe> Sender: xen-devel-bounces@lists.xensource.com Errors-To: xen-devel-bounces@lists.xensource.com On Fri, Sep 30, Ian Campbell wrote: > On Fri, 2011-09-30 at 13:02 +0100, Olaf Hering wrote: > > On Fri, Sep 30, Ian Campbell wrote: > > > > > (note to committer, ensure the new file is executable) > > > > Please dont, thats not patch friendly. > > > > Shouldnt all script files be called with like > > '$interpreter $script' instead of './$script'? > > In general I agree, but that isn't how it the infrastructure in > tools/check/chk works right now. There is tools/check/check_logging, which says it requires code with is included in Python 2.3 and later. The toplevel README states 2.3 or later is required, so tools/check/check_logging could be removed and line 63 in tools/check/chk be updated. Olaf _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel From xen-devel-bounces@lists.xensource.com Fri Sep 30 05:20:37 2011 Return-path: <xen-devel-bounces@lists.xensource.com> Envelope-to: www-data@lists.xensource.com Delivery-date: Fri, 30 Sep 2011 05:20:37 -0700 Received: from localhost ([127.0.0.1] helo=lists.colo.xensource.com) by lists.xensource.com with esmtp (Exim 4.43) id 1R9c4z-0006QR-Oe; Fri, 30 Sep 2011 05:20:37 -0700 Received: from mail174.messagelabs.com ([85.158.138.51]) by lists.xensource.com with esmtp (Exim 4.43) id 1R9c3u-0006Dr-BF for xen-devel@lists.xensource.com; Fri, 30 Sep 2011 05:19:47 -0700 X-Env-Sender: Jonathan.Ludlam@eu.citrix.com X-Msg-Ref: server-11.tower-174.messagelabs.com!1317385167!33360444!1 X-Originating-IP: [62.200.22.115] X-StarScan-Version: 6.4.1; banners=-,-,- X-VirusChecked: Checked Received: (qmail 323 invoked from network); 30 Sep 2011 12:19:27 -0000 Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115) by server-11.tower-174.messagelabs.com with RC4-SHA encrypted SMTP; 30 Sep 2011 12:19:27 -0000 X-IronPort-AV: E=Sophos;i="4.68,467,1312156800"; d="scan'208";a="8150250" Received: from lonpmailmx01.citrite.net ([10.30.203.162]) by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5; 30 Sep 2011 12:19:27 +0000 Received: from LONPMAILBOX01.citrite.net ([10.30.224.160]) by LONPMAILMX01.citrite.net ([10.30.203.162]) with mapi; Fri, 30 Sep 2011 13:19:26 +0100 From: Jonathan Ludlam <Jonathan.Ludlam@eu.citrix.com> To: Ian Campbell <Ian.Campbell@eu.citrix.com> Date: Fri, 30 Sep 2011 13:19:26 +0100 Subject: Re: [Xen-devel] [PATCH 1 of 7] [OCAML] Rename the ocamlfind packages Thread-Topic: [Xen-devel] [PATCH 1 of 7] [OCAML] Rename the ocamlfind packages Thread-Index: Acx/azJKAAIm66PhSdW/7fu+AvBqCQ== Message-ID: <7CD39FD2-77AD-4662-BE17-E58861955E3A@eu.citrix.com> References: <patchbomb.1317331042@snoosnoo2.uk.xensource.com> <c5df5f625ee2a0339b2a.1317331043@snoosnoo2.uk.xensource.com> <1317368531.26672.203.camel@zakaz.uk.xensource.com> In-Reply-To: <1317368531.26672.203.camel@zakaz.uk.xensource.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com> X-BeenThere: xen-devel@lists.xensource.com X-Mailman-Version: 2.1.5 Precedence: list List-Id: Xen developer discussion <xen-devel.lists.xensource.com> List-Unsubscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe> List-Post: <mailto:xen-devel@lists.xensource.com> List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help> List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=subscribe> Sender: xen-devel-bounces@lists.xensource.com Errors-To: xen-devel-bounces@lists.xensource.com On 30 Sep 2011, at 08:42, Ian Campbell wrote: > On Thu, 2011-09-29 at 22:17 +0100, Jon Ludlam wrote: >> ocamlfind does not support namespaces, so to avoid >> name clashes the ocamlfind package names have been >> changed. Note that this does not change the names >> of the actual modules themselves. >=20 > So you do "ocamlfind xenbus" in your code but subsequently "import" xl.* > (forgive my lack of actual ocaml syntax)? >=20 > I'm happy with that if its acceptable practice in ocaml, but given it's > "just" a sed invocation away should we bite the bullet and change the > module name too? >=20 It's not uncommon, e.g. the 'threads' package allows the use of the Thread,= Mutex, Condition, Event and ThreadUnix modules, but not a 'Threads' one. H= aving said that, for the single module packages it would be slightly odd. T= he only thing that stopped me is that what I did involves a change in the m= akefiles of any ocaml project using the libs, whereas a renaming of the mod= ules would require changing a lot more code. Being a bit ambivalent about t= he two approaches, I picked the one that was less noisy, though I'm willing= to be persuaded otherwise. >> xb becomes xenbus, xc becomes xenctrl, xl becomes xenlight, >> xs becomes xenstore, eventchn becomes xeneventchn. >=20 > The next patch removes uuid which by my count leaves just the mmap > library, any plans for that one? >=20 We haven't quite figured out what to do with that one yet. It depends a lit= tle on whether anything else is using the module. More to follow :-) Jon _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel From xen-devel-bounces@lists.xensource.com Fri Sep 30 05:22:49 2011 Return-path: <xen-devel-bounces@lists.xensource.com> Envelope-to: www-data@lists.xensource.com Delivery-date: Fri, 30 Sep 2011 05:22:49 -0700 Received: from localhost ([127.0.0.1] helo=lists.colo.xensource.com) by lists.xensource.com with esmtp (Exim 4.43) id 1R9c77-0006uG-12; Fri, 30 Sep 2011 05:22:49 -0700 Received: from mail182.messagelabs.com ([85.158.139.83]) by lists.xensource.com with esmtp (Exim 4.43) id 1R9c5x-0006go-40 for xen-devel@lists.xensource.com; Fri, 30 Sep 2011 05:21:37 -0700 X-Env-Sender: Ian.Campbell@eu.citrix.com X-Msg-Ref: server-11.tower-182.messagelabs.com!1317385293!18559010!1 X-Originating-IP: [62.200.22.115] X-StarScan-Version: 6.4.1; banners=-,-,- X-VirusChecked: Checked Received: (qmail 5580 invoked from network); 30 Sep 2011 12:21:34 -0000 Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115) by server-11.tower-182.messagelabs.com with RC4-SHA encrypted SMTP; 30 Sep 2011 12:21:34 -0000 X-IronPort-AV: E=Sophos;i="4.68,467,1312156800"; d="scan'208";a="8150292" Received: from lonpmailmx01.citrite.net ([10.30.203.162]) by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5; 30 Sep 2011 12:20:58 +0000 Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net (10.30.203.162) with Microsoft SMTP Server id 8.3.137.0; Fri, 30 Sep 2011 13:20:58 +0100 From: Ian Campbell <Ian.Campbell@eu.citrix.com> To: Olaf Hering <olaf@aepfle.de> Date: Fri, 30 Sep 2011 13:20:57 +0100 In-Reply-To: <20110930121542.GA25896@aepfle.de> References: <4b98868690218126b906.1317368189@cosworth.uk.xensource.com> <20110930120210.GA25618@aepfle.de> <1317384428.26672.269.camel@zakaz.uk.xensource.com> <20110930121542.GA25896@aepfle.de> Organization: Citrix Systems, Inc. Content-Type: text/plain; charset="UTF-8" X-Mailer: Evolution 3.0.3- Content-Transfer-Encoding: 7bit Message-ID: <1317385258.26672.270.camel@zakaz.uk.xensource.com> MIME-Version: 1.0 Cc: Anthony, Perard <anthony.perard@citrix.com>, "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com> Subject: [Xen-devel] Re: [PATCH] tools/check: check for yajl (needed by libxl) X-BeenThere: xen-devel@lists.xensource.com X-Mailman-Version: 2.1.5 Precedence: list List-Id: Xen developer discussion <xen-devel.lists.xensource.com> List-Unsubscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe> List-Post: <mailto:xen-devel@lists.xensource.com> List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help> List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=subscribe> Sender: xen-devel-bounces@lists.xensource.com Errors-To: xen-devel-bounces@lists.xensource.com On Fri, 2011-09-30 at 13:15 +0100, Olaf Hering wrote: > On Fri, Sep 30, Ian Campbell wrote: > > > On Fri, 2011-09-30 at 13:02 +0100, Olaf Hering wrote: > > > On Fri, Sep 30, Ian Campbell wrote: > > > > > > > (note to committer, ensure the new file is executable) > > > > > > Please dont, thats not patch friendly. > > > > > > Shouldnt all script files be called with like > > > '$interpreter $script' instead of './$script'? > > > > In general I agree, but that isn't how it the infrastructure in > > tools/check/chk works right now. > > There is tools/check/check_logging, which says it requires code with is > included in Python 2.3 and later. > The toplevel README states 2.3 or later is required, so > tools/check/check_logging could be removed and line 63 in > tools/check/chk be updated. Patches accepted, I don't think this should block the patch in this thread though. Ian. _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel From xen-devel-bounces@lists.xensource.com Fri Sep 30 05:24:47 2011 Return-path: <xen-devel-bounces@lists.xensource.com> Envelope-to: www-data@lists.xensource.com Delivery-date: Fri, 30 Sep 2011 05:24:47 -0700 Received: from localhost ([127.0.0.1] helo=lists.colo.xensource.com) by lists.xensource.com with esmtp (Exim 4.43) id 1R9c90-0007IL-NG; Fri, 30 Sep 2011 05:24:46 -0700 Received: from mail182.messagelabs.com ([85.158.139.83]) by lists.xensource.com with esmtp (Exim 4.43) id 1R9c5y-0006gr-J8 for xen-devel@lists.xensource.com; Fri, 30 Sep 2011 05:21:39 -0700 X-Env-Sender: Jonathan.Ludlam@eu.citrix.com X-Msg-Ref: server-11.tower-182.messagelabs.com!1317385293!18559010!2 X-Originating-IP: [62.200.22.115] X-StarScan-Version: 6.4.1; banners=-,-,- X-VirusChecked: Checked Received: (qmail 5653 invoked from network); 30 Sep 2011 12:21:35 -0000 Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115) by server-11.tower-182.messagelabs.com with RC4-SHA encrypted SMTP; 30 Sep 2011 12:21:35 -0000 X-IronPort-AV: E=Sophos;i="4.68,467,1312156800"; d="scan'208";a="8150306" Received: from lonpmailmx02.citrite.net ([10.30.203.163]) by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5; 30 Sep 2011 12:21:28 +0000 Received: from LONPMAILBOX01.citrite.net ([10.30.224.160]) by LONPMAILMX02.citrite.net ([10.30.203.163]) with mapi; Fri, 30 Sep 2011 13:21:28 +0100 From: Jonathan Ludlam <Jonathan.Ludlam@eu.citrix.com> To: Ian Campbell <Ian.Campbell@eu.citrix.com> Date: Fri, 30 Sep 2011 13:21:27 +0100 Subject: Re: [Xen-devel] [PATCH 2 of 7] [OCAML] Remove the uuid library Thread-Topic: [Xen-devel] [PATCH 2 of 7] [OCAML] Remove the uuid library Thread-Index: Acx/a3oXpGEGevimR72TNL+ryp0Olw== Message-ID: <3759F487-EE35-4735-8EF2-7953FDE0FB75@eu.citrix.com> References: <patchbomb.1317331042@snoosnoo2.uk.xensource.com> <42cdb34ec175602fa2d8.1317331044@snoosnoo2.uk.xensource.com> <1317368705.26672.206.camel@zakaz.uk.xensource.com> In-Reply-To: <1317368705.26672.206.camel@zakaz.uk.xensource.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com> X-BeenThere: xen-devel@lists.xensource.com X-Mailman-Version: 2.1.5 Precedence: list List-Id: Xen developer discussion <xen-devel.lists.xensource.com> List-Unsubscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe> List-Post: <mailto:xen-devel@lists.xensource.com> List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help> List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=subscribe> Sender: xen-devel-bounces@lists.xensource.com Errors-To: xen-devel-bounces@lists.xensource.com On 30 Sep 2011, at 08:45, Ian Campbell wrote: > On Thu, 2011-09-29 at 22:17 +0100, Jon Ludlam wrote: >> diff -r c5df5f625ee2 -r 42cdb34ec175 tools/ocaml/libs/xc/META.in >> --- a/tools/ocaml/libs/xc/META.in >> +++ b/tools/ocaml/libs/xc/META.in >> @@ -1,5 +1,5 @@ >> version =3D "@VERSION@" >> description =3D "Xen Control Interface" >> -requires =3D "mmap,uuid" >> +requires =3D "unix,mmap" >> archive(byte) =3D "xc.cma" >> archive(native) =3D "xc.cmxa" >=20 > Is the addition of unix here really part of removing uuid? I don't see > any additional use of unix arising from the change. >=20 No, you're correct - it's a bugfix in the dependencies. I can prepare it as= a separate patch, if you want? > xc does seem to use unix already so the change is probably correct, just > not really part of this change. I'd be happier if it went in separately, > but: >=20 > Acked-by: Ian Campbell <ian.campbell@citrix.com> _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel From xen-devel-bounces@lists.xensource.com Fri Sep 30 05:25:49 2011 Return-path: <xen-devel-bounces@lists.xensource.com> Envelope-to: www-data@lists.xensource.com Delivery-date: Fri, 30 Sep 2011 05:25:49 -0700 Received: from localhost ([127.0.0.1] helo=lists.colo.xensource.com) by lists.xensource.com with esmtp (Exim 4.43) id 1R9cA1-0007fW-JT; Fri, 30 Sep 2011 05:25:49 -0700 Received: from mail27.messagelabs.com ([193.109.254.147]) by lists.xensource.com with esmtp (Exim 4.43) id 1R9c7B-0006uj-82 for xen-devel@lists.xensource.com; Fri, 30 Sep 2011 05:22:53 -0700 X-Env-Sender: Jonathan.Ludlam@eu.citrix.com X-Msg-Ref: server-2.tower-27.messagelabs.com!1317385343!57121069!1 X-Originating-IP: [62.200.22.115] X-StarScan-Version: 6.4.1; banners=-,-,- X-VirusChecked: Checked Received: (qmail 6645 invoked from network); 30 Sep 2011 12:22:23 -0000 Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115) by server-2.tower-27.messagelabs.com with RC4-SHA encrypted SMTP; 30 Sep 2011 12:22:23 -0000 X-IronPort-AV: E=Sophos;i="4.68,467,1312156800"; d="scan'208";a="8150333" Received: from lonpmailmx02.citrite.net ([10.30.203.163]) by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5; 30 Sep 2011 12:22:50 +0000 Received: from LONPMAILBOX01.citrite.net ([10.30.224.160]) by LONPMAILMX02.citrite.net ([10.30.203.163]) with mapi; Fri, 30 Sep 2011 13:22:50 +0100 From: Jonathan Ludlam <Jonathan.Ludlam@eu.citrix.com> To: Ian Campbell <Ian.Campbell@eu.citrix.com> Date: Fri, 30 Sep 2011 13:22:48 +0100 Subject: Re: [Xen-devel] [PATCH 4 of 7] [OCAML] Fix a problem with ocaml xenstored Thread-Topic: [Xen-devel] [PATCH 4 of 7] [OCAML] Fix a problem with ocaml xenstored Thread-Index: Acx/a6rMoR8K2zVmTjieg6z8jDI47g== Message-ID: <310859A4-B038-4784-A51B-F4B217FD575D@eu.citrix.com> References: <patchbomb.1317331042@snoosnoo2.uk.xensource.com> <b6022a18ebb012b8af85.1317331046@snoosnoo2.uk.xensource.com> <1317368963.26672.210.camel@zakaz.uk.xensource.com> In-Reply-To: <1317368963.26672.210.camel@zakaz.uk.xensource.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com> X-BeenThere: xen-devel@lists.xensource.com X-Mailman-Version: 2.1.5 Precedence: list List-Id: Xen developer discussion <xen-devel.lists.xensource.com> List-Unsubscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe> List-Post: <mailto:xen-devel@lists.xensource.com> List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help> List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=subscribe> Sender: xen-devel-bounces@lists.xensource.com Errors-To: xen-devel-bounces@lists.xensource.com Ah, that's a shame. I was hoping this was a bugfix to the ocaml xenstored a= nd that the C version already did this. Unfortunately the patch here went i= n to XenServer a couple of years ago, and Thomas, who made the change, has = since left. I'll dig into this and see why we depend upon it.=20 Jon =20 On 30 Sep 2011, at 08:49, Ian Campbell wrote: > On Thu, 2011-09-29 at 22:17 +0100, Jon Ludlam wrote: >> Have xenstored trigger an @introduceDomain event even if the >> introduce call tries to introduce an already existing domain. >=20 > The C daemon doesn't appear to behave this way. It would be nice to > explain why this change is necessary.=20 >=20 >> Signed-off-by: Thomas Gazagnaire <thomas@ocamlpro.com> >> Acked-by: Jon Ludlam <jonathan.ludlam@eu.citrix.com> >>=20 >> diff -r 734cb0807357 -r b6022a18ebb0 tools/ocaml/xenstored/process.ml >> --- a/tools/ocaml/xenstored/process.ml >> +++ b/tools/ocaml/xenstored/process.ml >> @@ -168,9 +168,10 @@ >> | _ -> raise Invalid_Cmd_Args; >> in >> let dom =3D >> - if Domains.exist domains domid then >> + if Domains.exist domains domid then begin >> + Connections.fire_spec_watches cons "@introduceDomain"; >> Domains.find domains domid >> - else try >> + end else try >> let ndom =3D Xc.with_intf (fun xc -> >> Domains.create xc domains domid mfn port) in >> Connections.add_domain cons ndom; >>=20 >> _______________________________________________ >> Xen-devel mailing list >> Xen-devel@lists.xensource.com >> http://lists.xensource.com/xen-devel >=20 >=20 _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel From xen-devel-bounces@lists.xensource.com Fri Sep 30 05:35:44 2011 Return-path: <xen-devel-bounces@lists.xensource.com> Envelope-to: www-data@lists.xensource.com Delivery-date: Fri, 30 Sep 2011 05:35:44 -0700 Received: from localhost ([127.0.0.1] helo=lists.colo.xensource.com) by lists.xensource.com with esmtp (Exim 4.43) id 1R9cJc-0008MS-32; Fri, 30 Sep 2011 05:35:44 -0700 Received: from mail174.messagelabs.com ([85.158.138.51]) by lists.xensource.com with esmtp (Exim 4.43) id 1R9cJ3-0008A5-JU for xen-devel@lists.xensource.com; Fri, 30 Sep 2011 05:35:09 -0700 X-Env-Sender: Ian.Campbell@eu.citrix.com X-Msg-Ref: server-2.tower-174.messagelabs.com!1317386106!33375904!1 X-Originating-IP: [62.200.22.115] X-StarScan-Version: 6.4.1; banners=-,-,- X-VirusChecked: Checked Received: (qmail 9103 invoked from network); 30 Sep 2011 12:35:06 -0000 Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115) by server-2.tower-174.messagelabs.com with RC4-SHA encrypted SMTP; 30 Sep 2011 12:35:06 -0000 X-IronPort-AV: E=Sophos;i="4.68,467,1312156800"; d="scan'208";a="8150763" Received: from lonpmailmx01.citrite.net ([10.30.203.162]) by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5; 30 Sep 2011 12:35:06 +0000 Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net (10.30.203.162) with Microsoft SMTP Server id 8.3.137.0; Fri, 30 Sep 2011 13:35:06 +0100 Subject: Re: [Xen-devel] [PATCH 1 of 7] [OCAML] Rename the ocamlfind packages From: Ian Campbell <Ian.Campbell@eu.citrix.com> To: Jonathan Ludlam <Jonathan.Ludlam@eu.citrix.com> Date: Fri, 30 Sep 2011 13:35:05 +0100 In-Reply-To: <7CD39FD2-77AD-4662-BE17-E58861955E3A@eu.citrix.com> References: <patchbomb.1317331042@snoosnoo2.uk.xensource.com> <c5df5f625ee2a0339b2a.1317331043@snoosnoo2.uk.xensource.com> <1317368531.26672.203.camel@zakaz.uk.xensource.com> <7CD39FD2-77AD-4662-BE17-E58861955E3A@eu.citrix.com> Organization: Citrix Systems, Inc. Content-Type: text/plain; charset="UTF-8" X-Mailer: Evolution 3.0.3- Content-Transfer-Encoding: 7bit Message-ID: <1317386105.26672.272.camel@zakaz.uk.xensource.com> MIME-Version: 1.0 Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com> X-BeenThere: xen-devel@lists.xensource.com X-Mailman-Version: 2.1.5 Precedence: list List-Id: Xen developer discussion <xen-devel.lists.xensource.com> List-Unsubscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe> List-Post: <mailto:xen-devel@lists.xensource.com> List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help> List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=subscribe> Sender: xen-devel-bounces@lists.xensource.com Errors-To: xen-devel-bounces@lists.xensource.com On Fri, 2011-09-30 at 13:19 +0100, Jonathan Ludlam wrote: > On 30 Sep 2011, at 08:42, Ian Campbell wrote: > > > On Thu, 2011-09-29 at 22:17 +0100, Jon Ludlam wrote: > >> ocamlfind does not support namespaces, so to avoid > >> name clashes the ocamlfind package names have been > >> changed. Note that this does not change the names > >> of the actual modules themselves. > > > > So you do "ocamlfind xenbus" in your code but subsequently "import" xl.* > > (forgive my lack of actual ocaml syntax)? > > > > I'm happy with that if its acceptable practice in ocaml, but given it's > > "just" a sed invocation away should we bite the bullet and change the > > module name too? > > > > It's not uncommon, e.g. the 'threads' package allows the use of the > Thread, Mutex, Condition, Event and ThreadUnix modules, but not a > 'Threads' one. Having said that, for the single module packages it > would be slightly odd. The only thing that stopped me is that what I > did involves a change in the makefiles of any ocaml project using the > libs, whereas a renaming of the modules would require changing a lot > more code. Being a bit ambivalent about the two approaches, I picked > the one that was less noisy, though I'm willing to be persuaded > otherwise. Thanks -- seems reasonable. I'm don't see any reason to try and persuade you any further ;-) > > >> xb becomes xenbus, xc becomes xenctrl, xl becomes xenlight, > >> xs becomes xenstore, eventchn becomes xeneventchn. > > > > The next patch removes uuid which by my count leaves just the mmap > > library, any plans for that one? > > > > We haven't quite figured out what to do with that one yet. It depends > a little on whether anything else is using the module. More to > follow :-) Great! _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel From xen-devel-bounces@lists.xensource.com Fri Sep 30 05:37:23 2011 Return-path: <xen-devel-bounces@lists.xensource.com> Envelope-to: www-data@lists.xensource.com Delivery-date: Fri, 30 Sep 2011 05:37:23 -0700 Received: from localhost ([127.0.0.1] helo=lists.colo.xensource.com) by lists.xensource.com with esmtp (Exim 4.43) id 1R9cLC-0000Qb-S4; Fri, 30 Sep 2011 05:37:22 -0700 Received: from mail174.messagelabs.com ([85.158.138.51]) by lists.xensource.com with esmtp (Exim 4.43) id 1R9cKW-0000C9-Po for xen-devel@lists.xensource.com; Fri, 30 Sep 2011 05:36:41 -0700 X-Env-Sender: Ian.Campbell@eu.citrix.com X-Msg-Ref: server-4.tower-174.messagelabs.com!1317386197!33391364!1 X-Originating-IP: [62.200.22.115] X-StarScan-Version: 6.4.1; banners=-,-,- X-VirusChecked: Checked Received: (qmail 31619 invoked from network); 30 Sep 2011 12:36:37 -0000 Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115) by server-4.tower-174.messagelabs.com with RC4-SHA encrypted SMTP; 30 Sep 2011 12:36:37 -0000 X-IronPort-AV: E=Sophos;i="4.68,467,1312156800"; d="scan'208";a="8150819" Received: from lonpmailmx01.citrite.net ([10.30.203.162]) by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5; 30 Sep 2011 12:36:05 +0000 Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net (10.30.203.162) with Microsoft SMTP Server id 8.3.137.0; Fri, 30 Sep 2011 13:36:05 +0100 Subject: Re: [Xen-devel] [PATCH 2 of 7] [OCAML] Remove the uuid library From: Ian Campbell <Ian.Campbell@eu.citrix.com> To: Jonathan Ludlam <Jonathan.Ludlam@eu.citrix.com> Date: Fri, 30 Sep 2011 13:36:05 +0100 In-Reply-To: <3759F487-EE35-4735-8EF2-7953FDE0FB75@eu.citrix.com> References: <patchbomb.1317331042@snoosnoo2.uk.xensource.com> <42cdb34ec175602fa2d8.1317331044@snoosnoo2.uk.xensource.com> <1317368705.26672.206.camel@zakaz.uk.xensource.com> <3759F487-EE35-4735-8EF2-7953FDE0FB75@eu.citrix.com> Organization: Citrix Systems, Inc. Content-Type: text/plain; charset="UTF-8" X-Mailer: Evolution 3.0.3- Content-Transfer-Encoding: 7bit Message-ID: <1317386165.26672.273.camel@zakaz.uk.xensource.com> MIME-Version: 1.0 Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com> X-BeenThere: xen-devel@lists.xensource.com X-Mailman-Version: 2.1.5 Precedence: list List-Id: Xen developer discussion <xen-devel.lists.xensource.com> List-Unsubscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe> List-Post: <mailto:xen-devel@lists.xensource.com> List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help> List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=subscribe> Sender: xen-devel-bounces@lists.xensource.com Errors-To: xen-devel-bounces@lists.xensource.com On Fri, 2011-09-30 at 13:21 +0100, Jonathan Ludlam wrote: > On 30 Sep 2011, at 08:45, Ian Campbell wrote: > > > On Thu, 2011-09-29 at 22:17 +0100, Jon Ludlam wrote: > >> diff -r c5df5f625ee2 -r 42cdb34ec175 tools/ocaml/libs/xc/META.in > >> --- a/tools/ocaml/libs/xc/META.in > >> +++ b/tools/ocaml/libs/xc/META.in > >> @@ -1,5 +1,5 @@ > >> version = "@VERSION@" > >> description = "Xen Control Interface" > >> -requires = "mmap,uuid" > >> +requires = "unix,mmap" > >> archive(byte) = "xc.cma" > >> archive(native) = "xc.cmxa" > > > > Is the addition of unix here really part of removing uuid? I don't see > > any additional use of unix arising from the change. > > > > No, you're correct - it's a bugfix in the dependencies. I can prepare it as a separate patch, if you want? I you need to resend the series anyway you may as well I suppose, but if not then its not a big deal for me at least. Ian. > > > xc does seem to use unix already so the change is probably correct, just > > not really part of this change. I'd be happier if it went in separately, > > but: > > > > Acked-by: Ian Campbell <ian.campbell@citrix.com> > _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel From xen-devel-bounces@lists.xensource.com Fri Sep 30 05:45:11 2011 Return-path: <xen-devel-bounces@lists.xensource.com> Envelope-to: www-data@lists.xensource.com Delivery-date: Fri, 30 Sep 2011 05:45:11 -0700 Received: from localhost ([127.0.0.1] helo=lists.colo.xensource.com) by lists.xensource.com with esmtp (Exim 4.43) id 1R9cSl-0000v0-90; Fri, 30 Sep 2011 05:45:11 -0700 Received: from mail182.messagelabs.com ([85.158.139.83]) by lists.xensource.com with esmtp (Exim 4.43) id 1R9cRz-0000gz-Mu for xen-devel@lists.xensource.com; Fri, 30 Sep 2011 05:44:24 -0700 X-Env-Sender: royger@gmail.com X-Msg-Ref: server-14.tower-182.messagelabs.com!1317386660!20194712!1 X-Originating-IP: [74.125.82.171] X-StarScan-Version: 6.4.1; banners=-,-,- X-VirusChecked: Checked Received: (qmail 19261 invoked from network); 30 Sep 2011 12:44:20 -0000 Received: from mail-wy0-f171.google.com (HELO mail-wy0-f171.google.com) (74.125.82.171) by server-14.tower-182.messagelabs.com with RC4-SHA encrypted SMTP; 30 Sep 2011 12:44:20 -0000 Received: by wyh13 with SMTP id 13so1328160wyh.30 for <xen-devel@lists.xensource.com>; Fri, 30 Sep 2011 05:44:20 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=sender:content-type:mime-version:content-transfer-encoding:subject :message-id:user-agent:date:from:to; bh=H+enLt8DCYkN8hvJcF/OY8P4dZDpeN8T5ww5NjjAkOU=; b=d6xXLXLP0jRwK91qK9ucbkcM97bwc2DPUQx+2qJgPxoQ8ISSQSc7PCHTA8NPqI0IIA waTSVVmsbCJOrfM6G2v/7zjQH651YVMtGfsnGxD2Pwiuf/eKZxXaIa6VZmtdZG0y/e7+ nA27N1/EehvhIIzPb+ZwEwH03UQbZA5HguEGw= Received: by 10.216.163.194 with SMTP id a44mr3006113wel.1.1317386660255; Fri, 30 Sep 2011 05:44:20 -0700 (PDT) Received: from [127.0.0.1] (queen.upc.es. [147.83.39.247]) by mx.google.com with ESMTPS id l40sm8980963wbm.10.2011.09.30.05.44.18 (version=TLSv1/SSLv3 cipher=OTHER); Fri, 30 Sep 2011 05:44:19 -0700 (PDT) Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Message-Id: <patchbomb.1317386580@loki> User-Agent: Mercurial-patchbomb/1.9.2 Date: Fri, 30 Sep 2011 14:43:00 +0200 From: Roger Pau Monne <roger.pau@entel.upc.edu> To: xen-devel@lists.xensource.com Subject: [Xen-devel] [PATCH 0 of 9] Call hotplug scripts from libxl X-BeenThere: xen-devel@lists.xensource.com X-Mailman-Version: 2.1.5 Precedence: list List-Id: Xen developer discussion <xen-devel.lists.xensource.com> List-Unsubscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe> List-Post: <mailto:xen-devel@lists.xensource.com> List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help> List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=subscribe> Sender: xen-devel-bounces@lists.xensource.com Errors-To: xen-devel-bounces@lists.xensource.com This patch adds support for NetBSD to call hotplugs scripts directly from libxl, instead of relying on xenbackendd. Also some patches contain general bug fixes that apply to both NetBSD and Linux. Currently Linux hotplug script call functions are empty, so Linux continues to use udev rules to call hotplug scripts. If possible, all this changes should be backported to xen-4.1 also. Regards, Roger. _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel From xen-devel-bounces@lists.xensource.com Fri Sep 30 05:46:27 2011 Return-path: <xen-devel-bounces@lists.xensource.com> Envelope-to: www-data@lists.xensource.com Delivery-date: Fri, 30 Sep 2011 05:46:27 -0700 Received: from localhost ([127.0.0.1] helo=lists.colo.xensource.com) by lists.xensource.com with esmtp (Exim 4.43) id 1R9cTz-0001Iw-6e; Fri, 30 Sep 2011 05:46:27 -0700 Received: from mail182.messagelabs.com ([85.158.139.83]) by lists.xensource.com with esmtp (Exim 4.43) id 1R9cS1-0000h0-37 for xen-devel@lists.xensource.com; Fri, 30 Sep 2011 05:44:25 -0700 X-Env-Sender: royger@gmail.com X-Msg-Ref: server-14.tower-182.messagelabs.com!1317386660!20194712!2 X-Originating-IP: [74.125.82.171] X-StarScan-Version: 6.4.1; banners=-,-,- X-VirusChecked: Checked Received: (qmail 19410 invoked from network); 30 Sep 2011 12:44:22 -0000 Received: from mail-wy0-f171.google.com (HELO mail-wy0-f171.google.com) (74.125.82.171) by server-14.tower-182.messagelabs.com with RC4-SHA encrypted SMTP; 30 Sep 2011 12:44:22 -0000 Received: by mail-wy0-f171.google.com with SMTP id 13so1328160wyh.30 for <xen-devel@lists.xensource.com>; Fri, 30 Sep 2011 05:44:22 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=sender:content-type:mime-version:content-transfer-encoding:subject :x-mercurial-node:message-id:in-reply-to:references:user-agent:date :from:to; bh=G9Nd8VddbQ/2ptksIPV0mi+mXM51WVxx3WG/5uABVd8=; b=aHxm+mGe2VZNzDwXQkKjh1V/9La8W1/kJdO1ED2KxohZFpwJxR1M7F8astIqHpUMLJ I9R1biAzKzFl+oH+gbjt+GCRPp9ZwqqwvZ5WexL6xoHKsXLai4sqfHIzBJdiNGgXtdFJ oiKUBnuMhjvSjHY8kQlp2yeF7pPmX0s0EAToQ= Received: by 10.216.166.139 with SMTP id g11mr4417455wel.20.1317386662103; Fri, 30 Sep 2011 05:44:22 -0700 (PDT) Received: from [127.0.0.1] (queen.upc.es. [147.83.39.247]) by mx.google.com with ESMTPS id l40sm8980963wbm.10.2011.09.30.05.44.20 (version=TLSv1/SSLv3 cipher=OTHER); Fri, 30 Sep 2011 05:44:21 -0700 (PDT) Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Mercurial-Node: 47005b3da245e2be052b614c02ed212d3d2cecbd Message-Id: <47005b3da245e2be052b.1317386581@loki> In-Reply-To: <patchbomb.1317386580@loki> References: <patchbomb.1317386580@loki> User-Agent: Mercurial-patchbomb/1.9.2 Date: Fri, 30 Sep 2011 14:43:01 +0200 From: Roger Pau Monne <roger.pau@entel.upc.edu> To: xen-devel@lists.xensource.com Subject: [Xen-devel] [PATCH 1 of 9] xenbackendd: fix incorrect usage of pidfile X-BeenThere: xen-devel@lists.xensource.com X-Mailman-Version: 2.1.5 Precedence: list List-Id: Xen developer discussion <xen-devel.lists.xensource.com> List-Unsubscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe> List-Post: <mailto:xen-devel@lists.xensource.com> List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help> List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=subscribe> Sender: xen-devel-bounces@lists.xensource.com Errors-To: xen-devel-bounces@lists.xensource.com # HG changeset patch # User Roger Pau Monne <roger.pau@entel.upc.edu> # Date 1317300282 -7200 # Node ID 47005b3da245e2be052b614c02ed212d3d2cecbd # Parent a422e2a4451e16dc791b293f41966b842fa4781d xenbackendd: fix incorrect usage of pidfile Fix xenbackendd ignoring the pidfile passed through the command line. Signed-off-by: Roger Pau Monne <roger.pau@entel.upc.edu> diff -r a422e2a4451e -r 47005b3da245 tools/xenbackendd/xenbackendd.c --- a/tools/xenbackendd/xenbackendd.c Sun Sep 18 00:26:52 2011 +0100 +++ b/tools/xenbackendd/xenbackendd.c Thu Sep 29 14:44:42 2011 +0200 @@ -169,7 +169,7 @@ main(int argc, char * const argv[]) log_file = optarg; break; case 'p': - pidfile = pidfile; + pidfile = optarg; case 's': vbd_script = optarg; break; _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel From xen-devel-bounces@lists.xensource.com Fri Sep 30 05:47:31 2011 Return-path: <xen-devel-bounces@lists.xensource.com> Envelope-to: www-data@lists.xensource.com Delivery-date: Fri, 30 Sep 2011 05:47:31 -0700 Received: from localhost ([127.0.0.1] helo=lists.colo.xensource.com) by lists.xensource.com with esmtp (Exim 4.43) id 1R9cV1-0001hJ-JK; Fri, 30 Sep 2011 05:47:31 -0700 Received: from mail182.messagelabs.com ([85.158.139.83]) by lists.xensource.com with esmtp (Exim 4.43) id 1R9cS3-0000h6-28 for xen-devel@lists.xensource.com; Fri, 30 Sep 2011 05:44:29 -0700 X-Env-Sender: royger@gmail.com X-Msg-Ref: server-15.tower-182.messagelabs.com!1317386664!19346553!1 X-Originating-IP: [74.125.82.43] X-StarScan-Version: 6.4.1; banners=-,-,- X-VirusChecked: Checked Received: (qmail 6634 invoked from network); 30 Sep 2011 12:44:24 -0000 Received: from mail-ww0-f43.google.com (HELO mail-ww0-f43.google.com) (74.125.82.43) by server-15.tower-182.messagelabs.com with RC4-SHA encrypted SMTP; 30 Sep 2011 12:44:24 -0000 Received: by wwf27 with SMTP id 27so2169095wwf.24 for <xen-devel@lists.xensource.com>; Fri, 30 Sep 2011 05:44:24 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=sender:content-type:mime-version:content-transfer-encoding:subject :x-mercurial-node:message-id:in-reply-to:references:user-agent:date :from:to; bh=EBT5BcTvW+w5QVPsFWvJ6HTNbMiV6h49jgZTeClUQrU=; b=IbGTBV+WE7cdeTVF26OpjhlNehWPiQxKDX2EdwnzlhA+dwJsWmyfSzt4xy0+MDoeqE 8Bche0wjOr6HB2PI/JZu7x7zb2q8pBxYu5gxcW5EOX/IpBjkASBfsdB4EBru+7qEuAnt ugY/+yXnQtWuqSrBvQa2RZH9+/yvafreLLj+8= Received: by 10.216.8.5 with SMTP id 5mr1889363weq.68.1317386663945; Fri, 30 Sep 2011 05:44:23 -0700 (PDT) Received: from [127.0.0.1] (queen.upc.es. [147.83.39.247]) by mx.google.com with ESMTPS id l40sm8980963wbm.10.2011.09.30.05.44.22 (version=TLSv1/SSLv3 cipher=OTHER); Fri, 30 Sep 2011 05:44:22 -0700 (PDT) Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Mercurial-Node: d10abc15d963b00658405be71981f5726e24c0aa Message-Id: <d10abc15d963b0065840.1317386582@loki> In-Reply-To: <patchbomb.1317386580@loki> References: <patchbomb.1317386580@loki> User-Agent: Mercurial-patchbomb/1.9.2 Date: Fri, 30 Sep 2011 14:43:02 +0200 From: Roger Pau Monne <roger.pau@entel.upc.edu> To: xen-devel@lists.xensource.com Subject: [Xen-devel] [PATCH 2 of 9] xenbackendd: pass type of block device to hotplug script X-BeenThere: xen-devel@lists.xensource.com X-Mailman-Version: 2.1.5 Precedence: list List-Id: Xen developer discussion <xen-devel.lists.xensource.com> List-Unsubscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe> List-Post: <mailto:xen-devel@lists.xensource.com> List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help> List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=subscribe> Sender: xen-devel-bounces@lists.xensource.com Errors-To: xen-devel-bounces@lists.xensource.com # HG changeset patch # User Roger Pau Monne <roger.pau@entel.upc.edu> # Date 1317386335 -7200 # Node ID d10abc15d963b00658405be71981f5726e24c0aa # Parent 47005b3da245e2be052b614c02ed212d3d2cecbd xenbackendd: pass type of block device to hotplug script Pass the type of block device to attach to the block script instead of reading it from xenstore, since new Xen versions don't make a difference between a block device or an image. Signed-off-by: Roger Pau Monne <roger.pau@entel.upc.edu> diff -r 47005b3da245 -r d10abc15d963 tools/hotplug/NetBSD/block --- a/tools/hotplug/NetBSD/block Thu Sep 29 14:44:42 2011 +0200 +++ b/tools/hotplug/NetBSD/block Fri Sep 30 14:38:55 2011 +0200 @@ -19,7 +19,7 @@ error() { xpath=$1 xstatus=$2 -xtype=$(xenstore-read "$xpath/type") +xtype=$3 xparams=$(xenstore-read "$xpath/params") case $xstatus in diff -r 47005b3da245 -r d10abc15d963 tools/xenbackendd/xenbackendd.c --- a/tools/xenbackendd/xenbackendd.c Thu Sep 29 14:44:42 2011 +0200 +++ b/tools/xenbackendd/xenbackendd.c Fri Sep 30 14:38:55 2011 +0200 @@ -89,15 +89,15 @@ dodebug(const char *fmt, ...) } static void -doexec(const char *cmd, const char *arg1, const char *arg2) +doexec(const char *cmd, const char *arg1, const char *arg2, const char *arg3) { - dodebug("exec %s %s %s", cmd, arg1, arg2); + dodebug("exec %s %s %s %s", cmd, arg1, arg2, arg3); switch(vfork()) { case -1: dolog(LOG_ERR, "can't vfork: %s", strerror(errno)); break; case 0: - execl(cmd, cmd, arg1, arg2, NULL); + execl(cmd, cmd, arg1, arg2, arg3, NULL); dolog(LOG_ERR, "can't exec %s: %s", cmd, strerror(errno)); exit(EXIT_FAILURE); /* NOTREACHED */ @@ -145,11 +145,14 @@ xen_setup(void) int main(int argc, char * const argv[]) { + struct stat stab; char **vec; unsigned int num; char *s; int state; char *sstate; + char *stype; + char *params; char *p; char buf[80]; int type; @@ -297,11 +300,38 @@ main(int argc, char * const argv[]) strerror(errno)); goto next2; } - doexec(s, vec[XS_WATCH_PATH], sstate); + doexec(s, vec[XS_WATCH_PATH], sstate, NULL); break; case DEVTYPE_VBD: - doexec(vbd_script, vec[XS_WATCH_PATH], sstate); + /* check if given file is a block device or a raw image */ + snprintf(buf, sizeof(buf), "%s/params", vec[XS_WATCH_PATH]); + params = xs_read(xs, XBT_NULL, buf, 0); + if(params == NULL) { + dolog(LOG_ERR, + "Failed to read %s (%s)", buf, strerror(errno)); + goto next2; + } + if (stat(params, &stab) < 0) { + dolog(LOG_ERR, + "Failed to get info about %s (%s)", params, + strerror(errno)); + goto next3; + } + stype = NULL; + if (S_ISBLK(stab.st_mode)) + stype = "phy"; + if (S_ISREG(stab.st_mode)) + stype = "file"; + if (stype == NULL) { + dolog(LOG_ERR, + "Failed to attach %s (not a block device or raw image)", + params, strerror(errno)); + goto next3; + } + doexec(vbd_script, vec[XS_WATCH_PATH], sstate, stype); +next3: + free(params); break; default: _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel From xen-devel-bounces@lists.xensource.com Fri Sep 30 05:48:25 2011 Return-path: <xen-devel-bounces@lists.xensource.com> Envelope-to: www-data@lists.xensource.com Delivery-date: Fri, 30 Sep 2011 05:48:25 -0700 Received: from localhost ([127.0.0.1] helo=lists.colo.xensource.com) by lists.xensource.com with esmtp (Exim 4.43) id 1R9cVs-00025L-Uu; Fri, 30 Sep 2011 05:48:24 -0700 Received: from mail182.messagelabs.com ([85.158.139.83]) by lists.xensource.com with esmtp (Exim 4.43) id 1R9cS4-0000hJ-P4 for xen-devel@lists.xensource.com; Fri, 30 Sep 2011 05:44:29 -0700 X-Env-Sender: royger@gmail.com X-Msg-Ref: server-14.tower-182.messagelabs.com!1317386660!20194712!3 X-Originating-IP: [74.125.82.171] X-StarScan-Version: 6.4.1; banners=-,-,- X-VirusChecked: Checked Received: (qmail 19655 invoked from network); 30 Sep 2011 12:44:25 -0000 Received: from mail-wy0-f171.google.com (HELO mail-wy0-f171.google.com) (74.125.82.171) by server-14.tower-182.messagelabs.com with RC4-SHA encrypted SMTP; 30 Sep 2011 12:44:25 -0000 Received: by mail-wy0-f171.google.com with SMTP id 13so1328160wyh.30 for <xen-devel@lists.xensource.com>; Fri, 30 Sep 2011 05:44:25 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=sender:content-type:mime-version:content-transfer-encoding:subject :x-mercurial-node:message-id:in-reply-to:references:user-agent:date :from:to; bh=NbqP8D+OMLOPi4qNjmczoaFx8HdhYL3mZc5WFUR3ahs=; b=sipDZfHoJ8unBW/YFPssO2DCwpUDw4RtzJdt5UOlxA87KNFwcfJGaGJfohxAo30ZlQ umAPL1HmSjLOIRoaagU1Yk0jU1g8yscYrXT/oWZmI5H7rFckjD8iZbd4IbiubVXVbFFX 2ofWGRhgL11X0o3rU6+yz2VaBzOfKEcjjPh68= Received: by 10.227.24.70 with SMTP id u6mr13172664wbb.72.1317386665716; Fri, 30 Sep 2011 05:44:25 -0700 (PDT) Received: from [127.0.0.1] (queen.upc.es. [147.83.39.247]) by mx.google.com with ESMTPS id l40sm8980963wbm.10.2011.09.30.05.44.24 (version=TLSv1/SSLv3 cipher=OTHER); Fri, 30 Sep 2011 05:44:24 -0700 (PDT) Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Mercurial-Node: 31b3caad18ac904a242c5bd1ea2bb0e574cd0453 Message-Id: <31b3caad18ac904a242c.1317386583@loki> In-Reply-To: <patchbomb.1317386580@loki> References: <patchbomb.1317386580@loki> User-Agent: Mercurial-patchbomb/1.9.2 Date: Fri, 30 Sep 2011 14:43:03 +0200 From: Roger Pau Monne <roger.pau@entel.upc.edu> To: xen-devel@lists.xensource.com Subject: [Xen-devel] [PATCH 3 of 9] libxl: fix for libxl not waiting for devices to disconnect X-BeenThere: xen-devel@lists.xensource.com X-Mailman-Version: 2.1.5 Precedence: list List-Id: Xen developer discussion <xen-devel.lists.xensource.com> List-Unsubscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe> List-Post: <mailto:xen-devel@lists.xensource.com> List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help> List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=subscribe> Sender: xen-devel-bounces@lists.xensource.com Errors-To: xen-devel-bounces@lists.xensource.com # HG changeset patch # User Roger Pau Monne <roger.pau@entel.upc.edu> # Date 1317386335 -7200 # Node ID 31b3caad18ac904a242c5bd1ea2bb0e574cd0453 # Parent d10abc15d963b00658405be71981f5726e24c0aa libxl: fix for libxl not waiting for devices to disconnect libxl was ignoring the timeout and the number of devices to wait before destroying them. Signed-off-by: Roger Pau Monne <roger.pau@entel.upc.edu> diff -r d10abc15d963 -r 31b3caad18ac tools/libxl/libxl_device.c --- a/tools/libxl/libxl_device.c Fri Sep 30 14:38:55 2011 +0200 +++ b/tools/libxl/libxl_device.c Fri Sep 30 14:38:55 2011 +0200 @@ -422,6 +422,9 @@ static int wait_for_dev_destroy(libxl__g } free(l1); } + } else { + /* timeout reached */ + rc = 0; } return rc; } @@ -482,7 +485,7 @@ int libxl__devices_destroy(libxl__gc *gc tv.tv_usec = 0; while (n_watches > 0) { if (wait_for_dev_destroy(gc, &tv)) { - break; + continue; } else { n_watches--; } _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel From xen-devel-bounces@lists.xensource.com Fri Sep 30 05:49:42 2011 Return-path: <xen-devel-bounces@lists.xensource.com> Envelope-to: www-data@lists.xensource.com Delivery-date: Fri, 30 Sep 2011 05:49:42 -0700 Received: from localhost ([127.0.0.1] helo=lists.colo.xensource.com) by lists.xensource.com with esmtp (Exim 4.43) id 1R9cX8-0002Z3-3Q; Fri, 30 Sep 2011 05:49:42 -0700 Received: from mail182.messagelabs.com ([85.158.139.83]) by lists.xensource.com with esmtp (Exim 4.43) id 1R9cS6-0000hO-L6 for xen-devel@lists.xensource.com; Fri, 30 Sep 2011 05:44:31 -0700 X-Env-Sender: royger@gmail.com X-Msg-Ref: server-15.tower-182.messagelabs.com!1317386664!19346553!2 X-Originating-IP: [74.125.82.43] X-StarScan-Version: 6.4.1; banners=-,-,- X-VirusChecked: Checked Received: (qmail 6816 invoked from network); 30 Sep 2011 12:44:27 -0000 Received: from mail-ww0-f43.google.com (HELO mail-ww0-f43.google.com) (74.125.82.43) by server-15.tower-182.messagelabs.com with RC4-SHA encrypted SMTP; 30 Sep 2011 12:44:27 -0000 Received: by mail-ww0-f43.google.com with SMTP id 27so2169095wwf.24 for <xen-devel@lists.xensource.com>; Fri, 30 Sep 2011 05:44:27 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=sender:content-type:mime-version:content-transfer-encoding:subject :x-mercurial-node:message-id:in-reply-to:references:user-agent:date :from:to; bh=fsI9+eR1ebsTd99Kp1WVDUSTThkRST4St/9zPVP0lYE=; b=FAh2bazKbXej3OOD+Nyu7Q+ALTa8S0RvFkm3ZZyeiYVGfrcPXDdMji/UMQ64pGmWnV ZxL1ZVVLnTTBf/UkWoOk/TEK65pccLSQl93z+hQKIcA2feRe2hD+IhFdCC9yUB1jo+8a rO+87AxBUQwHnCq1ucDu8fWAoFEBj4M5tOggU= Received: by 10.216.186.208 with SMTP id w58mr2792843wem.20.1317386667588; Fri, 30 Sep 2011 05:44:27 -0700 (PDT) Received: from [127.0.0.1] (queen.upc.es. [147.83.39.247]) by mx.google.com with ESMTPS id l40sm8980963wbm.10.2011.09.30.05.44.25 (version=TLSv1/SSLv3 cipher=OTHER); Fri, 30 Sep 2011 05:44:26 -0700 (PDT) Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Mercurial-Node: 156626fef95b36184ad44dfcb049bae2545435f0 Message-Id: <156626fef95b36184ad4.1317386584@loki> In-Reply-To: <patchbomb.1317386580@loki> References: <patchbomb.1317386580@loki> User-Agent: Mercurial-patchbomb/1.9.2 Date: Fri, 30 Sep 2011 14:43:04 +0200 From: Roger Pau Monne <roger.pau@entel.upc.edu> To: xen-devel@lists.xensource.com Subject: [Xen-devel] [PATCH 4 of 9] libxl: create pci backend only when there are pci devices X-BeenThere: xen-devel@lists.xensource.com X-Mailman-Version: 2.1.5 Precedence: list List-Id: Xen developer discussion <xen-devel.lists.xensource.com> List-Unsubscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe> List-Post: <mailto:xen-devel@lists.xensource.com> List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help> List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=subscribe> Sender: xen-devel-bounces@lists.xensource.com Errors-To: xen-devel-bounces@lists.xensource.com # HG changeset patch # User Roger Pau Monne <roger.pau@entel.upc.edu> # Date 1317386335 -7200 # Node ID 156626fef95b36184ad44dfcb049bae2545435f0 # Parent 31b3caad18ac904a242c5bd1ea2bb0e574cd0453 libxl: create pci backend only when there are pci devices. Creating empty pci entries made Linux DomUs under NetBSD Dom0 wait a very long time for devices to initialize during kernel boot. Signed-off-by: Roger Pau Monne <roger.pau@entel.upc.edu> diff -r 31b3caad18ac -r 156626fef95b tools/libxl/libxl_create.c --- a/tools/libxl/libxl_create.c Fri Sep 30 14:38:55 2011 +0200 +++ b/tools/libxl/libxl_create.c Fri Sep 30 14:38:55 2011 +0200 @@ -584,12 +584,14 @@ static int do_domain_create(libxl__gc *g for (i = 0; i < d_config->num_pcidevs; i++) libxl__device_pci_add(gc, domid, &d_config->pcidevs[i], 1); - ret = libxl__create_pci_backend(gc, domid, d_config->pcidevs, - d_config->num_pcidevs); - if (ret < 0) { - LIBXL__LOG(ctx, LIBXL__LOG_ERROR, - "libxl_create_pci_backend failed: %d", ret); - goto error_out; + if (d_config->num_pcidevs > 0) { + ret = libxl__create_pci_backend(gc, domid, d_config->pcidevs, + d_config->num_pcidevs); + if (ret < 0) { + LIBXL__LOG(ctx, LIBXL__LOG_ERROR, + "libxl_create_pci_backend failed: %d", ret); + goto error_out; + } } if (d_config->c_info.type == LIBXL_DOMAIN_TYPE_PV && _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel From xen-devel-bounces@lists.xensource.com Fri Sep 30 05:50:41 2011 Return-path: <xen-devel-bounces@lists.xensource.com> Envelope-to: www-data@lists.xensource.com Delivery-date: Fri, 30 Sep 2011 05:50:41 -0700 Received: from localhost ([127.0.0.1] helo=lists.colo.xensource.com) by lists.xensource.com with esmtp (Exim 4.43) id 1R9cY4-0002vb-RC; Fri, 30 Sep 2011 05:50:40 -0700 Received: from mail182.messagelabs.com ([85.158.139.83]) by lists.xensource.com with esmtp (Exim 4.43) id 1R9cS8-0000hk-Vk for xen-devel@lists.xensource.com; Fri, 30 Sep 2011 05:44:33 -0700 X-Env-Sender: royger@gmail.com X-Msg-Ref: server-14.tower-182.messagelabs.com!1317386660!20194712!4 X-Originating-IP: [74.125.82.171] X-StarScan-Version: 6.4.1; banners=-,-,- X-VirusChecked: Checked Received: (qmail 19818 invoked from network); 30 Sep 2011 12:44:30 -0000 Received: from mail-wy0-f171.google.com (HELO mail-wy0-f171.google.com) (74.125.82.171) by server-14.tower-182.messagelabs.com with RC4-SHA encrypted SMTP; 30 Sep 2011 12:44:30 -0000 Received: by mail-wy0-f171.google.com with SMTP id 13so1328160wyh.30 for <xen-devel@lists.xensource.com>; Fri, 30 Sep 2011 05:44:29 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=sender:content-type:mime-version:content-transfer-encoding:subject :x-mercurial-node:message-id:in-reply-to:references:user-agent:date :from:to; bh=JfmJ0E0ZrBVgpMwAzszcxfhOjKX4s1F1jy0fjeOKDlQ=; b=VUCCD2OJFgSH+35JYq/eholq2TjQEAHWVCxfZ62ZBmSQ9/TksMQDUcmia8UUAladZH R/cOWDXOotl1YLiPr/7khyhgZlF2R3geVGkvbrNJO4fFp0JhjFren3KmAapgugSgyp2q DxsUMmu+JdSttrAJuZOnywfxIdxZwr20BUBH0= Received: by 10.216.131.29 with SMTP id l29mr2838956wei.45.1317386669384; Fri, 30 Sep 2011 05:44:29 -0700 (PDT) Received: from [127.0.0.1] (queen.upc.es. [147.83.39.247]) by mx.google.com with ESMTPS id l40sm8980963wbm.10.2011.09.30.05.44.27 (version=TLSv1/SSLv3 cipher=OTHER); Fri, 30 Sep 2011 05:44:28 -0700 (PDT) Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Mercurial-Node: 84a27a9f39f29194a7344e842b2055f592a42250 Message-Id: <84a27a9f39f29194a734.1317386585@loki> In-Reply-To: <patchbomb.1317386580@loki> References: <patchbomb.1317386580@loki> User-Agent: Mercurial-patchbomb/1.9.2 Date: Fri, 30 Sep 2011 14:43:05 +0200 From: Roger Pau Monne <roger.pau@entel.upc.edu> To: xen-devel@lists.xensource.com Subject: [Xen-devel] [PATCH 5 of 9] libxl: only use interactive PyGrub mode when a console is attached X-BeenThere: xen-devel@lists.xensource.com X-Mailman-Version: 2.1.5 Precedence: list List-Id: Xen developer discussion <xen-devel.lists.xensource.com> List-Unsubscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe> List-Post: <mailto:xen-devel@lists.xensource.com> List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help> List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=subscribe> Sender: xen-devel-bounces@lists.xensource.com Errors-To: xen-devel-bounces@lists.xensource.com # HG changeset patch # User Roger Pau Monne <roger.pau@entel.upc.edu> # Date 1317386335 -7200 # Node ID 84a27a9f39f29194a7344e842b2055f592a42250 # Parent 156626fef95b36184ad44dfcb049bae2545435f0 libxl: only use interactive PyGrub mode when a console is attached Sometimes PyGrub freezed when trying to create a domain without the console attached (without "-c"). This patch adds the "-q" option to PyGrub when "-c" is not specified at creation time. PyGrub freezed trying to set terminal attributes (like reset_prog_mode or nocbreak). Signed-off-by: Roger Pau Monne <roger.pau@entel.upc.edu> diff -r 156626fef95b -r 84a27a9f39f2 tools/libxl/libxl.h --- a/tools/libxl/libxl.h Fri Sep 30 14:38:55 2011 +0200 +++ b/tools/libxl/libxl.h Fri Sep 30 14:38:55 2011 +0200 @@ -287,7 +287,8 @@ int libxl_get_max_cpus(libxl_ctx *ctx); int libxl_run_bootloader(libxl_ctx *ctx, libxl_domain_build_info *info, libxl_device_disk *disk, - uint32_t domid); + uint32_t domid, + libxl_console_ready cb); /* 0 means ERROR_ENOMEM, which we have logged */ diff -r 156626fef95b -r 84a27a9f39f2 tools/libxl/libxl_bootloader.c --- a/tools/libxl/libxl_bootloader.c Fri Sep 30 14:38:55 2011 +0200 +++ b/tools/libxl/libxl_bootloader.c Fri Sep 30 14:38:55 2011 +0200 @@ -33,7 +33,8 @@ static char **make_bootloader_args(libxl__gc *gc, libxl_domain_build_info *info, uint32_t domid, - const char *fifo, char *disk) + const char *fifo, char *disk, + libxl_console_ready cb) { flexarray_t *args; int nr = 0; @@ -55,6 +56,8 @@ static char **make_bootloader_args(libxl flexarray_set(args, nr++, libxl__sprintf(gc, "--output=%s", fifo)); flexarray_set(args, nr++, "--output-format=simple0"); flexarray_set(args, nr++, libxl__sprintf(gc, "--output-directory=%s", "/var/run/libxl/")); + if (!cb) + flexarray_set(args, nr++, "-q"); if (info->u.pv.bootloader_args) { char *saveptr; @@ -300,7 +303,8 @@ static void parse_bootloader_result(libx int libxl_run_bootloader(libxl_ctx *ctx, libxl_domain_build_info *info, libxl_device_disk *disk, - uint32_t domid) + uint32_t domid, + libxl_console_ready cb) { libxl__gc gc = LIBXL_INIT_GC(ctx); int ret, rc = 0; @@ -362,7 +366,7 @@ int libxl_run_bootloader(libxl_ctx *ctx, goto out_close; } - args = make_bootloader_args(&gc, info, domid, fifo, diskpath); + args = make_bootloader_args(&gc, info, domid, fifo, diskpath, cb); if (args == NULL) { rc = ERROR_NOMEM; goto out_close; diff -r 156626fef95b -r 84a27a9f39f2 tools/libxl/libxl_create.c --- a/tools/libxl/libxl_create.c Fri Sep 30 14:38:55 2011 +0200 +++ b/tools/libxl/libxl_create.c Fri Sep 30 14:38:55 2011 +0200 @@ -461,7 +461,7 @@ static int do_domain_create(libxl__gc *g } if ( restore_fd < 0 ) { - ret = libxl_run_bootloader(ctx, &d_config->b_info, d_config->num_disks > 0 ? &d_config->disks[0] : NULL, domid); + ret = libxl_run_bootloader(ctx, &d_config->b_info, d_config->num_disks > 0 ? &d_config->disks[0] : NULL, domid, cb); if (ret) { LIBXL__LOG(ctx, LIBXL__LOG_ERROR, "failed to run bootloader: %d", ret); _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel From xen-devel-bounces@lists.xensource.com Fri Sep 30 05:51:39 2011 Return-path: <xen-devel-bounces@lists.xensource.com> Envelope-to: www-data@lists.xensource.com Delivery-date: Fri, 30 Sep 2011 05:51:39 -0700 Received: from localhost ([127.0.0.1] helo=lists.colo.xensource.com) by lists.xensource.com with esmtp (Exim 4.43) id 1R9cZ0-0003Ib-TP; Fri, 30 Sep 2011 05:51:38 -0700 Received: from mail182.messagelabs.com ([85.158.139.83]) by lists.xensource.com with esmtp (Exim 4.43) id 1R9cSA-0000iZ-Vm for xen-devel@lists.xensource.com; Fri, 30 Sep 2011 05:44:36 -0700 X-Env-Sender: royger@gmail.com X-Msg-Ref: server-14.tower-182.messagelabs.com!1317386660!20194712!5 X-Originating-IP: [74.125.82.171] X-StarScan-Version: 6.4.1; banners=-,-,- X-VirusChecked: Checked Received: (qmail 19882 invoked from network); 30 Sep 2011 12:44:31 -0000 Received: from mail-wy0-f171.google.com (HELO mail-wy0-f171.google.com) (74.125.82.171) by server-14.tower-182.messagelabs.com with RC4-SHA encrypted SMTP; 30 Sep 2011 12:44:31 -0000 Received: by mail-wy0-f171.google.com with SMTP id 13so1328160wyh.30 for <xen-devel@lists.xensource.com>; Fri, 30 Sep 2011 05:44:31 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=sender:content-type:mime-version:content-transfer-encoding:subject :x-mercurial-node:message-id:in-reply-to:references:user-agent:date :from:to; bh=8MEsUSCrBQnck8qCY4YdrD6Frhn/qrnsIW5on9x/MpI=; b=XhM+ZaW4iXuvnciaPFD6gOIu0pu8zm/W8HRksFgxd4T69uuXa6++STGZYon+rGq2IE AyL/IN1xocgIXF4jmGltjcpy8gCW+xSMk3G60eZajtCKbGliuZDy/NlzDvehBwR8JA8f oneT6/g7JAWNiEAqtrTsTgEj3iL7gUbn2ppvs= Received: by 10.227.8.213 with SMTP id i21mr7212591wbi.80.1317386671801; Fri, 30 Sep 2011 05:44:31 -0700 (PDT) Received: from [127.0.0.1] (queen.upc.es. [147.83.39.247]) by mx.google.com with ESMTPS id l40sm8980963wbm.10.2011.09.30.05.44.29 (version=TLSv1/SSLv3 cipher=OTHER); Fri, 30 Sep 2011 05:44:30 -0700 (PDT) Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Mercurial-Node: ce4b969a938afa40edb6858629b6eb2905a29f04 Message-Id: <ce4b969a938afa40edb6.1317386586@loki> In-Reply-To: <patchbomb.1317386580@loki> References: <patchbomb.1317386580@loki> User-Agent: Mercurial-patchbomb/1.9.2 Date: Fri, 30 Sep 2011 14:43:06 +0200 From: Roger Pau Monne <roger.pau@entel.upc.edu> To: xen-devel@lists.xensource.com Subject: [Xen-devel] [PATCH 6 of 9] libxl: add support for image files for NetBSD X-BeenThere: xen-devel@lists.xensource.com X-Mailman-Version: 2.1.5 Precedence: list List-Id: Xen developer discussion <xen-devel.lists.xensource.com> List-Unsubscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe> List-Post: <mailto:xen-devel@lists.xensource.com> List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help> List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=subscribe> Sender: xen-devel-bounces@lists.xensource.com Errors-To: xen-devel-bounces@lists.xensource.com # HG changeset patch # User Roger Pau Monne <roger.pau@entel.upc.edu> # Date 1317386335 -7200 # Node ID ce4b969a938afa40edb6858629b6eb2905a29f04 # Parent 84a27a9f39f29194a7344e842b2055f592a42250 libxl: add support for image files for NetBSD Created a helper function to detect if the OS is capable of using image files as phy backends. Create two OS specific files, and changed the Makefile to choose the correct one at compile time. Signed-off-by: Roger Pau Monne <roger.pau@entel.upc.edu> diff -r 84a27a9f39f2 -r ce4b969a938a tools/libxl/Makefile --- a/tools/libxl/Makefile Fri Sep 30 14:38:55 2011 +0200 +++ b/tools/libxl/Makefile Fri Sep 30 14:38:55 2011 +0200 @@ -31,6 +31,8 @@ LIBXL_OBJS-y += libxl_noblktap2.o endif LIBXL_OBJS-$(CONFIG_X86) += libxl_cpuid.o LIBXL_OBJS-$(CONFIG_IA64) += libxl_nocpuid.o +LIBXL_OBJS-$(CONFIG_NetBSD) += libxl_phybackend.o +LIBXL_OBJS-$(CONFIG_Linux) += libxl_nophybackend.o LIBXL_OBJS = flexarray.o libxl.o libxl_create.o libxl_dm.o libxl_pci.o \ libxl_dom.o libxl_exec.o libxl_xshelp.o libxl_device.o \ diff -r 84a27a9f39f2 -r ce4b969a938a tools/libxl/libxl_device.c --- a/tools/libxl/libxl_device.c Fri Sep 30 14:38:55 2011 +0200 +++ b/tools/libxl/libxl_device.c Fri Sep 30 14:38:55 2011 +0200 @@ -136,15 +136,14 @@ static int disk_try_backend(disk_try_bac a->disk->format == LIBXL_DISK_FORMAT_EMPTY)) { goto bad_format; } - if (a->disk->format != LIBXL_DISK_FORMAT_EMPTY && - !S_ISBLK(a->stab.st_mode)) { - LIBXL__LOG(ctx, LIBXL__LOG_DEBUG, "Disk vdev=%s, backend phy" - " unsuitable as phys path not a block device", - a->disk->vdev); - return 0; - } - return backend; + if (try_phy_backend(a->stab.st_mode)) + return backend; + + LIBXL__LOG(ctx, LIBXL__LOG_DEBUG, "Disk vdev=%s, backend phy" + " unsuitable as phys path not a block device", + a->disk->vdev); + return 0; case LIBXL_DISK_BACKEND_TAP: if (!libxl__blktap_enabled(a->gc)) { diff -r 84a27a9f39f2 -r ce4b969a938a tools/libxl/libxl_internal.h --- a/tools/libxl/libxl_internal.h Fri Sep 30 14:38:55 2011 +0200 +++ b/tools/libxl/libxl_internal.h Fri Sep 30 14:38:55 2011 +0200 @@ -227,6 +227,9 @@ _hidden int libxl__device_destroy(libxl_ _hidden int libxl__devices_destroy(libxl__gc *gc, uint32_t domid, int force); _hidden int libxl__wait_for_backend(libxl__gc *gc, char *be_path, char *state); +/* OS dependant helper function */ +_hidden int try_phy_backend(mode_t st_mode); + /* from libxl_pci */ _hidden int libxl__device_pci_add(libxl__gc *gc, uint32_t domid, libxl_device_pci *pcidev, int starting); diff -r 84a27a9f39f2 -r ce4b969a938a tools/libxl/libxl_nophybackend.c --- /dev/null Thu Jan 01 00:00:00 1970 +0000 +++ b/tools/libxl/libxl_nophybackend.c Fri Sep 30 14:38:55 2011 +0200 @@ -0,0 +1,27 @@ +/* + * Copyright (C) 2011 + * Author Roger Pau Monne <roger.pau@entel.upc.edu> + * + * This program is free software; you can redistribute it and/or modify + * it under the terms of the GNU Lesser General Public License as published + * by the Free Software Foundation; version 2.1 only. with the special + * exception on linking described in file LICENSE. + * + * This program is distributed in the hope that it will be useful, + * but WITHOUT ANY WARRANTY; without even the implied warranty of + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the + * GNU Lesser General Public License for more details. + */ + +#include <sys/stat.h> + +#include "libxl_internal.h" + +int try_phy_backend(mode_t st_mode) +{ + if (!S_ISBLK(st_mode)) { + return 0; + } + + return 1; +} diff -r 84a27a9f39f2 -r ce4b969a938a tools/libxl/libxl_phybackend.c --- /dev/null Thu Jan 01 00:00:00 1970 +0000 +++ b/tools/libxl/libxl_phybackend.c Fri Sep 30 14:38:55 2011 +0200 @@ -0,0 +1,26 @@ +/* + * Copyright (C) 2011 + * Author Roger Pau Monne <roger.pau@entel.upc.edu> + * + * This program is free software; you can redistribute it and/or modify + * it under the terms of the GNU Lesser General Public License as published + * by the Free Software Foundation; version 2.1 only. with the special + * exception on linking described in file LICENSE. + * + * This program is distributed in the hope that it will be useful, + * but WITHOUT ANY WARRANTY; without even the implied warranty of + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the + * GNU Lesser General Public License for more details. + */ + +#include <sys/stat.h> + +#include "libxl_internal.h" + +int try_phy_backend(mode_t st_mode) +{ + if (S_ISREG(st_mode) || S_ISBLK(st_mode)) + return 1; + + return 0; +} _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel From xen-devel-bounces@lists.xensource.com Fri Sep 30 05:52:39 2011 Return-path: <xen-devel-bounces@lists.xensource.com> Envelope-to: www-data@lists.xensource.com Delivery-date: Fri, 30 Sep 2011 05:52:39 -0700 Received: from localhost ([127.0.0.1] helo=lists.colo.xensource.com) by lists.xensource.com with esmtp (Exim 4.43) id 1R9cZz-0003hQ-MJ; Fri, 30 Sep 2011 05:52:39 -0700 Received: from mail182.messagelabs.com ([85.158.139.83]) by lists.xensource.com with esmtp (Exim 4.43) id 1R9cSC-0000j8-Po for xen-devel@lists.xensource.com; Fri, 30 Sep 2011 05:44:38 -0700 X-Env-Sender: royger@gmail.com X-Msg-Ref: server-14.tower-182.messagelabs.com!1317386660!20194712!6 X-Originating-IP: [74.125.82.171] X-StarScan-Version: 6.4.1; banners=-,-,- X-VirusChecked: Checked Received: (qmail 19998 invoked from network); 30 Sep 2011 12:44:33 -0000 Received: from mail-wy0-f171.google.com (HELO mail-wy0-f171.google.com) (74.125.82.171) by server-14.tower-182.messagelabs.com with RC4-SHA encrypted SMTP; 30 Sep 2011 12:44:33 -0000 Received: by mail-wy0-f171.google.com with SMTP id 13so1328160wyh.30 for <xen-devel@lists.xensource.com>; Fri, 30 Sep 2011 05:44:33 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=sender:content-type:mime-version:content-transfer-encoding:subject :x-mercurial-node:message-id:in-reply-to:references:user-agent:date :from:to; bh=1Gv5f+lhc12gMQWIqvdI7XOZUbRZk7DrzuBhcG6x5lU=; b=C4LuIFSghnBKuTO8OMGYybwEhMve/1ylkK+hoEyfcYyuqx5puIhYS0Yfb7VavCTzCr XzLbegoFUvZglRl7o/vuTpF3oiHDbVZtBYI/3lGr1mzEdIgYBI0GfXH0vqXc9JECyzUW 72UtKqo8jIy1SJiosZVS4YBfcnZ1FcO8TGJkk= Received: by 10.216.167.80 with SMTP id h58mr2635521wel.114.1317386673722; Fri, 30 Sep 2011 05:44:33 -0700 (PDT) Received: from [127.0.0.1] (queen.upc.es. [147.83.39.247]) by mx.google.com with ESMTPS id l40sm8980963wbm.10.2011.09.30.05.44.31 (version=TLSv1/SSLv3 cipher=OTHER); Fri, 30 Sep 2011 05:44:32 -0700 (PDT) Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Mercurial-Node: a767b85f9c3410c4cbe5cca7b12bd0900415040e Message-Id: <a767b85f9c3410c4cbe5.1317386587@loki> In-Reply-To: <patchbomb.1317386580@loki> References: <patchbomb.1317386580@loki> User-Agent: Mercurial-patchbomb/1.9.2 Date: Fri, 30 Sep 2011 14:43:07 +0200 From: Roger Pau Monne <roger.pau@entel.upc.edu> To: xen-devel@lists.xensource.com Subject: [Xen-devel] [PATCH 7 of 9] libxl: execute hotplug scripts directly from libxl X-BeenThere: xen-devel@lists.xensource.com X-Mailman-Version: 2.1.5 Precedence: list List-Id: Xen developer discussion <xen-devel.lists.xensource.com> List-Unsubscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe> List-Post: <mailto:xen-devel@lists.xensource.com> List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help> List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=subscribe> Sender: xen-devel-bounces@lists.xensource.com Errors-To: xen-devel-bounces@lists.xensource.com # HG changeset patch # User Roger Pau Monne <roger.pau@entel.upc.edu> # Date 1317386335 -7200 # Node ID a767b85f9c3410c4cbe5cca7b12bd0900415040e # Parent ce4b969a938afa40edb6858629b6eb2905a29f04 libxl: execute hotplug scripts directly from libxl. Added the necessary handlers to execute hotplug scripts when necessary from libxl. Split NetBSD from Linux hotplug calls into two separate files, because parameters for hotplug scripts are different. Linux has empty functions, since the calling of hotplug scripts is still done using udev. Signed-off-by: Roger Pau Monne <roger.pau@entel.upc.edu> diff -r ce4b969a938a -r a767b85f9c34 tools/libxl/Makefile --- a/tools/libxl/Makefile Fri Sep 30 14:38:55 2011 +0200 +++ b/tools/libxl/Makefile Fri Sep 30 14:38:55 2011 +0200 @@ -33,10 +33,13 @@ LIBXL_OBJS-$(CONFIG_X86) += libxl_cpuid. LIBXL_OBJS-$(CONFIG_IA64) += libxl_nocpuid.o LIBXL_OBJS-$(CONFIG_NetBSD) += libxl_phybackend.o LIBXL_OBJS-$(CONFIG_Linux) += libxl_nophybackend.o +LIBXL_OBJS-$(CONFIG_NetBSD) += hotplug_netbsd.o +LIBXL_OBJS-$(CONFIG_Linux) += hotplug_linux.o LIBXL_OBJS = flexarray.o libxl.o libxl_create.o libxl_dm.o libxl_pci.o \ libxl_dom.o libxl_exec.o libxl_xshelp.o libxl_device.o \ - libxl_internal.o libxl_utils.o libxl_uuid.o $(LIBXL_OBJS-y) + libxl_internal.o libxl_utils.o libxl_uuid.o libxl_hotplug.o \ + $(LIBXL_OBJS-y) LIBXL_OBJS += _libxl_types.o libxl_flask.o $(LIBXL_OBJS): CFLAGS += $(CFLAGS_libxenctrl) $(CFLAGS_libxenguest) $(CFLAGS_libxenstore) $(CFLAGS_libblktapctl) diff -r ce4b969a938a -r a767b85f9c34 tools/libxl/hotplug_linux.c --- /dev/null Thu Jan 01 00:00:00 1970 +0000 +++ b/tools/libxl/hotplug_linux.c Fri Sep 30 14:38:55 2011 +0200 @@ -0,0 +1,26 @@ +/* + * Copyright (C) 2011 + * Author Roger Pau Monne <roger.pau@entel.upc.edu> + * + * This program is free software; you can redistribute it and/or modify + * it under the terms of the GNU Lesser General Public License as published + * by the Free Software Foundation; version 2.1 only. with the special + * exception on linking described in file LICENSE. + * + * This program is distributed in the hope that it will be useful, + * but WITHOUT ANY WARRANTY; without even the implied warranty of + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the + * GNU Lesser General Public License for more details. + */ + +#include "libxl_internal.h" + +int libxl_disk_hotplug(libxl__gc *gc, char *be_path) +{ + return 0; +} + +int libxl_nic_hotplug_connect(libxl__gc *gc, char *be_path) +{ + return 0; +} diff -r ce4b969a938a -r a767b85f9c34 tools/libxl/hotplug_netbsd.c --- /dev/null Thu Jan 01 00:00:00 1970 +0000 +++ b/tools/libxl/hotplug_netbsd.c Fri Sep 30 14:38:55 2011 +0200 @@ -0,0 +1,121 @@ +/* + * Copyright (C) 2011 + * Author Roger Pau Monne <roger.pau@entel.upc.edu> + * + * This program is free software; you can redistribute it and/or modify + * it under the terms of the GNU Lesser General Public License as published + * by the Free Software Foundation; version 2.1 only. with the special + * exception on linking described in file LICENSE. + * + * This program is distributed in the hope that it will be useful, + * but WITHOUT ANY WARRANTY; without even the implied warranty of + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the + * GNU Lesser General Public License for more details. + */ + +#include <sys/stat.h> + +#include "libxl_internal.h" + +int libxl_disk_hotplug(libxl__gc *gc, char *be_path) +{ + libxl_ctx *ctx = libxl__gc_owner(gc); + struct stat stab; + char *stype, *sstate, *script, *params; + char **args; + int nr = 0; + flexarray_t *f_args; + + script = libxl__xs_read(gc, XBT_NULL, libxl__sprintf(gc, "%s/%s", be_path, "script")); + if (!script) { + LIBXL__LOG(ctx, LIBXL__LOG_ERROR, "Unable to read script from %s", + be_path); + return -1; + } + + params = libxl__xs_read(gc, XBT_NULL, libxl__sprintf(gc, "%s/%s", be_path, "params")); + if (!params) + return -1; + + sstate = libxl__xs_read(gc, XBT_NULL, libxl__sprintf(gc, "%s/%s", be_path, "state")); + if (!sstate) { + LIBXL__LOG(ctx, LIBXL__LOG_ERROR, "Unable to read state from %s", + be_path); + return -1; + } + + if (stat(params, &stab) < 0) { + LIBXL__LOG_ERRNO(ctx, LIBXL__LOG_ERROR, "Failed to get stat info\n"); + return -1; + } + if (S_ISBLK(stab.st_mode)) + stype = "phy"; + if (S_ISREG(stab.st_mode)) + stype = "file"; + if (stype == NULL) { + LIBXL__LOG(ctx, LIBXL__LOG_ERROR, "Not block or regular file"); + return -1; + } + + f_args = flexarray_make(5, 1); + if (!f_args) + return -1; + + flexarray_set(f_args, nr++, script); + flexarray_set(f_args, nr++, be_path); + flexarray_set(f_args, nr++, sstate); + flexarray_set(f_args, nr++, stype); + flexarray_set(f_args, nr++, NULL); + + args = (char **) flexarray_contents(f_args); + + if (libxl_exec(gc, args) < 0) { + free(args); + return -1; + } + + free(args); + return 0; +} + +int libxl_nic_hotplug(libxl__gc *gc, char *be_path) +{ + libxl_ctx *ctx = libxl__gc_owner(gc); + char *sstate, *script; + char **args; + int nr = 0; + flexarray_t *f_args; + + script = libxl__xs_read(gc, XBT_NULL, libxl__sprintf(gc, "%s/%s", be_path, "script")); + if (!script) { + LIBXL__LOG(ctx, LIBXL__LOG_ERROR, "Unable to read script from %s", + be_path); + return -1; + } + + sstate = libxl__xs_read(gc, XBT_NULL, libxl__sprintf(gc, "%s/%s", be_path, "state")); + if (!sstate) { + LIBXL__LOG(ctx, LIBXL__LOG_ERROR, "Unable to read state from %s", + be_path); + return -1; + } + + f_args = flexarray_make(4, 1); + if (!f_args) + return -1; + + flexarray_set(f_args, nr++, script); + flexarray_set(f_args, nr++, be_path); + flexarray_set(f_args, nr++, sstate); + flexarray_set(f_args, nr++, NULL); + + args = (char **) flexarray_contents(f_args); + + if (libxl_exec(gc, args) < 0) { + free(args); + return -1; + } + + free(args); + return 0; +} diff -r ce4b969a938a -r a767b85f9c34 tools/libxl/libxl.c --- a/tools/libxl/libxl.c Fri Sep 30 14:38:55 2011 +0200 +++ b/tools/libxl/libxl.c Fri Sep 30 14:38:55 2011 +0200 @@ -1009,6 +1009,11 @@ int libxl_device_disk_add(libxl_ctx *ctx flexarray_append(back, libxl__device_disk_string_of_backend(disk->backend)); flexarray_append(back, "mode"); flexarray_append(back, disk->readwrite ? "w" : "r"); + /* TODO: add Linux scripts, NetBSD only has block */ + flexarray_append(back, "script"); + flexarray_append(back, libxl__sprintf(&gc, "%s/%s", + libxl_xen_script_dir_path(), + "block")); flexarray_append(front, "backend-id"); flexarray_append(front, libxl__sprintf(&gc, "%d", disk->backend_domid)); @@ -1023,6 +1028,14 @@ int libxl_device_disk_add(libxl_ctx *ctx libxl__xs_kvs_of_flexarray(&gc, back, back->count), libxl__xs_kvs_of_flexarray(&gc, front, front->count)); + /* Call hotplug scripts to attach device */ + if (libxl_disk_hotplug(&gc, libxl__device_backend_path(&gc, &device)) < 0) { + LIBXL__LOG(ctx, LIBXL__LOG_ERROR, "unable to execute hotplug script for disk: %s\n", + disk->pdev_path); + rc = -1; + goto out_free; + } + rc = 0; out_free: @@ -1252,6 +1265,15 @@ int libxl_device_nic_add(libxl_ctx *ctx, libxl__xs_kvs_of_flexarray(&gc, front, front->count)); /* FIXME: wait for plug */ + + /* Call hotplug scripts to attach device */ + if (libxl_nic_hotplug(&gc, libxl__device_backend_path(&gc, &device)) < 0) { + LIBXL__LOG(ctx, LIBXL__LOG_ERROR, "unable to execute hotplug script for nic: %s\n", + nic->ifname); + rc = -1; + goto out_free; + } + rc = 0; out_free: flexarray_free(back); diff -r ce4b969a938a -r a767b85f9c34 tools/libxl/libxl_device.c --- a/tools/libxl/libxl_device.c Fri Sep 30 14:38:55 2011 +0200 +++ b/tools/libxl/libxl_device.c Fri Sep 30 14:38:55 2011 +0200 @@ -59,6 +59,42 @@ char *libxl__device_backend_path(libxl__ device->domid, device->devid); } +static libxl__device_kinds libxl__device_identify(char *be_path) +{ + char strkind[16]; /* Longest is actually "console" */ + int len = sizeof(string_of_kinds)/sizeof(char *); + + /* /local/domain/<domid>/backend/<kind>/ */ + if (sscanf(be_path, "/local/domain/%*d/backend/%16[^/]s", strkind) != 1) + return DEVICE_UNKNOWN; + + for (int j = 1; j < len; j++) { + if (strncmp(strkind, string_of_kinds[j], 16) == 0) + return j; + } + + return DEVICE_UNKNOWN; +} + +static int libxl__device_hotplug(libxl__gc *gc, libxl__device_kinds device, + char *be_path) +{ + int rc = 0; + + switch(device) { + case DEVICE_VIF: + rc = libxl_nic_hotplug(gc, be_path); + break; + case DEVICE_VBD: + rc = libxl_disk_hotplug(gc, be_path); + break; + default: + break; + } + + return rc; +} + int libxl__device_generic_add(libxl__gc *gc, libxl__device *device, char **bents, char **fents) { @@ -366,11 +402,13 @@ int libxl__device_destroy(libxl__gc *gc, xs_transaction_t t; char *state_path = libxl__sprintf(gc, "%s/state", be_path); char *state = libxl__xs_read(gc, XBT_NULL, state_path); + libxl__device_kinds device = libxl__device_identify(be_path); int rc = 0; if (!state) goto out; if (atoi(state) != 4) { + libxl__device_hotplug(gc, device, be_path); xs_rm(ctx->xsh, XBT_NULL, be_path); goto out; } @@ -391,6 +429,7 @@ retry_transaction: xs_watch(ctx->xsh, state_path, be_path); rc = 1; } else { + libxl__device_hotplug(gc, device, be_path); xs_rm(ctx->xsh, XBT_NULL, be_path); } out: @@ -404,6 +443,7 @@ static int wait_for_dev_destroy(libxl__g unsigned int n; fd_set rfds; char **l1 = NULL; + libxl__device_kinds device; rc = 1; nfds = xs_fileno(ctx->xsh) + 1; @@ -415,6 +455,8 @@ static int wait_for_dev_destroy(libxl__g char *state = libxl__xs_read(gc, XBT_NULL, l1[XS_WATCH_PATH]); if (!state || atoi(state) == 6) { xs_unwatch(ctx->xsh, l1[0], l1[1]); + device = libxl__device_identify(l1[XS_WATCH_PATH]); + libxl__device_hotplug(gc, device, l1[XS_WATCH_PATH]); xs_rm(ctx->xsh, XBT_NULL, l1[XS_WATCH_TOKEN]); LIBXL__LOG(ctx, LIBXL__LOG_DEBUG, "Destroyed device backend at %s", l1[XS_WATCH_TOKEN]); rc = 0; diff -r ce4b969a938a -r a767b85f9c34 tools/libxl/libxl_hotplug.c --- /dev/null Thu Jan 01 00:00:00 1970 +0000 +++ b/tools/libxl/libxl_hotplug.c Fri Sep 30 14:38:55 2011 +0200 @@ -0,0 +1,40 @@ +/* + * Copyright (C) 2011 + * Author Roger Pau Monne <roger.pau@entel.upc.edu> + * + * This program is free software; you can redistribute it and/or modify + * it under the terms of the GNU Lesser General Public License as published + * by the Free Software Foundation; version 2.1 only. with the special + * exception on linking described in file LICENSE. + * + * This program is distributed in the hope that it will be useful, + * but WITHOUT ANY WARRANTY; without even the implied warranty of + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the + * GNU Lesser General Public License for more details. + */ + +#include <unistd.h> + +#include "libxl_internal.h" + +int libxl_exec(libxl__gc *gc, char **cmd) +{ + libxl_ctx *ctx = libxl__gc_owner(gc); + + LIBXL__LOG(ctx, LIBXL__LOG_DEBUG, "Executing: %s", cmd[0]); + switch(vfork()) { + case -1: + LIBXL__LOG_ERRNO(ctx, LIBXL__LOG_ERROR, "Failed to vfork\n"); + return -1; + case 0: + execv(cmd[0], cmd); + LIBXL__LOG_ERRNO(ctx, LIBXL__LOG_ERROR, "Failed to execute %s\n", + cmd[0]); + exit(EXIT_FAILURE); + break; + default: + wait(NULL); + break; + } + return 0; +} diff -r ce4b969a938a -r a767b85f9c34 tools/libxl/libxl_internal.h --- a/tools/libxl/libxl_internal.h Fri Sep 30 14:38:55 2011 +0200 +++ b/tools/libxl/libxl_internal.h Fri Sep 30 14:38:55 2011 +0200 @@ -95,7 +95,8 @@ struct libxl__ctx { }; typedef enum { - DEVICE_VIF = 1, + DEVICE_UNKNOWN = 0, + DEVICE_VIF, DEVICE_VBD, DEVICE_QDISK, DEVICE_PCI, @@ -230,6 +231,11 @@ _hidden int libxl__wait_for_backend(libx /* OS dependant helper function */ _hidden int try_phy_backend(mode_t st_mode); +/* hotplug functions */ +_hidden int libxl_exec(libxl__gc *gc, char **cmd); +_hidden int libxl_disk_hotplug(libxl__gc *gc, char *be_path); +_hidden int libxl_nic_hotplug(libxl__gc *gc, char *be_path); + /* from libxl_pci */ _hidden int libxl__device_pci_add(libxl__gc *gc, uint32_t domid, libxl_device_pci *pcidev, int starting); _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel From xen-devel-bounces@lists.xensource.com Fri Sep 30 05:53:35 2011 Return-path: <xen-devel-bounces@lists.xensource.com> Envelope-to: www-data@lists.xensource.com Delivery-date: Fri, 30 Sep 2011 05:53:35 -0700 Received: from localhost ([127.0.0.1] helo=lists.colo.xensource.com) by lists.xensource.com with esmtp (Exim 4.43) id 1R9cat-00044I-Bb; Fri, 30 Sep 2011 05:53:35 -0700 Received: from mail182.messagelabs.com ([85.158.139.83]) by lists.xensource.com with esmtp (Exim 4.43) id 1R9cSE-0000je-Ie for xen-devel@lists.xensource.com; Fri, 30 Sep 2011 05:44:38 -0700 X-Env-Sender: royger@gmail.com X-Msg-Ref: server-14.tower-182.messagelabs.com!1317386660!20194712!7 X-Originating-IP: [74.125.82.171] X-StarScan-Version: 6.4.1; banners=-,-,- X-VirusChecked: Checked Received: (qmail 20165 invoked from network); 30 Sep 2011 12:44:35 -0000 Received: from mail-wy0-f171.google.com (HELO mail-wy0-f171.google.com) (74.125.82.171) by server-14.tower-182.messagelabs.com with RC4-SHA encrypted SMTP; 30 Sep 2011 12:44:35 -0000 Received: by mail-wy0-f171.google.com with SMTP id 13so1328160wyh.30 for <xen-devel@lists.xensource.com>; Fri, 30 Sep 2011 05:44:35 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=sender:content-type:mime-version:content-transfer-encoding:subject :x-mercurial-node:message-id:in-reply-to:references:user-agent:date :from:to; bh=HEwDYdDHBN+o8Hp55k4Fdo1HchAfRPj6h1gKy9CqIc4=; b=fTLVmD9WaPRs0JJzMzlXM1qmGETC5WiABkSb1wz8nx0onit1mR3QZO5zDMLSds4UCR /B5EkTC8IlL8b11Z2NmTmL3dI64mZ0bOjOajdw7714Y7OGH8xShLfAqnYt9nE15HvQsx 8w1RK/+PP2R2G2LOsokK3fKKyTUwlFaaWPBk0= Received: by 10.216.230.234 with SMTP id j84mr1725072weq.87.1317386675508; Fri, 30 Sep 2011 05:44:35 -0700 (PDT) Received: from [127.0.0.1] (queen.upc.es. [147.83.39.247]) by mx.google.com with ESMTPS id l40sm8980963wbm.10.2011.09.30.05.44.33 (version=TLSv1/SSLv3 cipher=OTHER); Fri, 30 Sep 2011 05:44:34 -0700 (PDT) Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Mercurial-Node: 7e44ba113546e4c2db56ebf9b0b251dcd9a1948a Message-Id: <7e44ba113546e4c2db56.1317386588@loki> In-Reply-To: <patchbomb.1317386580@loki> References: <patchbomb.1317386580@loki> User-Agent: Mercurial-patchbomb/1.9.2 Date: Fri, 30 Sep 2011 14:43:08 +0200 From: Roger Pau Monne <roger.pau@entel.upc.edu> To: xen-devel@lists.xensource.com Subject: [Xen-devel] [PATCH 8 of 9] hotplug NetBSD: detach devices when state is 5 or 6 X-BeenThere: xen-devel@lists.xensource.com X-Mailman-Version: 2.1.5 Precedence: list List-Id: Xen developer discussion <xen-devel.lists.xensource.com> List-Unsubscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe> List-Post: <mailto:xen-devel@lists.xensource.com> List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help> List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=subscribe> Sender: xen-devel-bounces@lists.xensource.com Errors-To: xen-devel-bounces@lists.xensource.com # HG changeset patch # User Roger Pau Monne <roger.pau@entel.upc.edu> # Date 1317386335 -7200 # Node ID 7e44ba113546e4c2db56ebf9b0b251dcd9a1948a # Parent a767b85f9c3410c4cbe5cca7b12bd0900415040e hotplug NetBSD: detach devices when state is 5 or 6 With the move of hotplug calls from xenbackendd to libxl, we can detach devices when the state is 5 or 6. Signed-off-by: Roger Pau Monne <roger.pau@entel.upc.edu> diff -r a767b85f9c34 -r 7e44ba113546 tools/hotplug/NetBSD/block --- a/tools/hotplug/NetBSD/block Fri Sep 30 14:38:55 2011 +0200 +++ b/tools/hotplug/NetBSD/block Fri Sep 30 14:38:55 2011 +0200 @@ -23,7 +23,7 @@ xtype=$3 xparams=$(xenstore-read "$xpath/params") case $xstatus in -6) +5|6) # device removed case $xtype in file) diff -r a767b85f9c34 -r 7e44ba113546 tools/hotplug/NetBSD/vif-bridge --- a/tools/hotplug/NetBSD/vif-bridge Fri Sep 30 14:38:55 2011 +0200 +++ b/tools/hotplug/NetBSD/vif-bridge Fri Sep 30 14:38:55 2011 +0200 @@ -14,7 +14,7 @@ xpath=$1 xstatus=$2 case $xstatus in -6) +5|6) # device removed xenstore-rm $xpath exit 0 diff -r a767b85f9c34 -r 7e44ba113546 tools/hotplug/NetBSD/vif-ip --- a/tools/hotplug/NetBSD/vif-ip Fri Sep 30 14:38:55 2011 +0200 +++ b/tools/hotplug/NetBSD/vif-ip Fri Sep 30 14:38:55 2011 +0200 @@ -14,7 +14,7 @@ xpath=$1 xstatus=$2 case $xstatus in -6) +5|6) # device removed xenstore-rm $xpath exit 0 _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel From xen-devel-bounces@lists.xensource.com Fri Sep 30 05:55:12 2011 Return-path: <xen-devel-bounces@lists.xensource.com> Envelope-to: www-data@lists.xensource.com Delivery-date: Fri, 30 Sep 2011 05:55:12 -0700 Received: from localhost ([127.0.0.1] helo=lists.colo.xensource.com) by lists.xensource.com with esmtp (Exim 4.43) id 1R9ccR-0004XD-JI; Fri, 30 Sep 2011 05:55:12 -0700 Received: from mail182.messagelabs.com ([85.158.139.83]) by lists.xensource.com with esmtp (Exim 4.43) id 1R9cSG-0000js-Ek for xen-devel@lists.xensource.com; Fri, 30 Sep 2011 05:44:41 -0700 X-Env-Sender: royger@gmail.com X-Msg-Ref: server-15.tower-182.messagelabs.com!1317386664!19346553!3 X-Originating-IP: [74.125.82.43] X-StarScan-Version: 6.4.1; banners=-,-,- X-VirusChecked: Checked Received: (qmail 7179 invoked from network); 30 Sep 2011 12:44:37 -0000 Received: from mail-ww0-f43.google.com (HELO mail-ww0-f43.google.com) (74.125.82.43) by server-15.tower-182.messagelabs.com with RC4-SHA encrypted SMTP; 30 Sep 2011 12:44:37 -0000 Received: by mail-ww0-f43.google.com with SMTP id 27so2169095wwf.24 for <xen-devel@lists.xensource.com>; Fri, 30 Sep 2011 05:44:37 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=sender:content-type:mime-version:content-transfer-encoding:subject :x-mercurial-node:message-id:in-reply-to:references:user-agent:date :from:to; bh=5G/v7RkLqYEfYdr8MC22qVGYwgiksF+Q1ICgtYBbRKM=; b=xV7Gkwl/uTOcRe03F7lbeL1OdhFuQ24Z5S4+ehxRrcAGUINLOtliPMebUgPCe40mEL wyZhcNqIPc5NTyZD5ZDkax6VBWflRCuOaWw0k28sysEssf3S6m4pFl9KPn7e9zLAvWyg E3+VxXqzgrG/McBclhXhwUkvkAk4ezo+DF4C4= Received: by 10.216.176.7 with SMTP id a7mr2690740wem.91.1317386677370; Fri, 30 Sep 2011 05:44:37 -0700 (PDT) Received: from [127.0.0.1] (queen.upc.es. [147.83.39.247]) by mx.google.com with ESMTPS id l40sm8980963wbm.10.2011.09.30.05.44.35 (version=TLSv1/SSLv3 cipher=OTHER); Fri, 30 Sep 2011 05:44:36 -0700 (PDT) Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Mercurial-Node: 3009fd6e30ea90b5a55dc97fd953e0b5ab188276 Message-Id: <3009fd6e30ea90b5a55d.1317386589@loki> In-Reply-To: <patchbomb.1317386580@loki> References: <patchbomb.1317386580@loki> User-Agent: Mercurial-patchbomb/1.9.2 Date: Fri, 30 Sep 2011 14:43:09 +0200 From: Roger Pau Monne <roger.pau@entel.upc.edu> To: xen-devel@lists.xensource.com Subject: [Xen-devel] [PATCH 9 of 9] rc.d NetBSD: don't start xenbackendd by default, only when xend needs it X-BeenThere: xen-devel@lists.xensource.com X-Mailman-Version: 2.1.5 Precedence: list List-Id: Xen developer discussion <xen-devel.lists.xensource.com> List-Unsubscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe> List-Post: <mailto:xen-devel@lists.xensource.com> List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help> List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=subscribe> Sender: xen-devel-bounces@lists.xensource.com Errors-To: xen-devel-bounces@lists.xensource.com # HG changeset patch # User Roger Pau Monne <roger.pau@entel.upc.edu> # Date 1317386335 -7200 # Node ID 3009fd6e30ea90b5a55dc97fd953e0b5ab188276 # Parent 7e44ba113546e4c2db56ebf9b0b251dcd9a1948a rc.d NetBSD: don't start xenbackendd by default, only when xend needs it. With the move of hotplug scripts from xenbackendd to libxl xenbackendd is no longer needed by libxl, only start it when xend is started. Signed-off-by: Roger Pau Monne <roger.pau@entel.upc.edu> diff -r 7e44ba113546 -r 3009fd6e30ea tools/hotplug/NetBSD/rc.d/xenbackendd --- /dev/null Thu Jan 01 00:00:00 1970 +0000 +++ b/tools/hotplug/NetBSD/rc.d/xenbackendd Fri Sep 30 14:38:55 2011 +0200 @@ -0,0 +1,27 @@ +#!/bin/sh +# +# PROVIDE: xenbackendd +# REQUIRE: xencommons + +. /etc/rc.subr + +DIR=$(dirname "$0") +. "${DIR}/xen-hotplugpath.sh" + +LD_LIBRARY_PATH="${LIBDIR}" +export LD_LIBRARY_PATH PYTHONPATH +PATH="${PATH}:${SBINDIR}" +export PATH + +name="xenbackendd" +rcvar=$name +command="${SBINDIR}/xenbackendd" +if [ -n "${XENBACKENDD_DEBUG}" ]; then + command_args="${XENBACKENDD_ARGS} -d" +else + command_args="${XENBACKENDD_ARGS}" +fi + +load_rc_config $name +run_rc_command "$1" + diff -r 7e44ba113546 -r 3009fd6e30ea tools/hotplug/NetBSD/rc.d/xencommons --- a/tools/hotplug/NetBSD/rc.d/xencommons Fri Sep 30 14:38:55 2011 +0200 +++ b/tools/hotplug/NetBSD/rc.d/xencommons Fri Sep 30 14:38:55 2011 +0200 @@ -46,7 +46,7 @@ xen_startcmd() XENSTORED_ROOTDIR="/var/lib/xenstored" fi rm -f ${XENSTORED_ROOTDIR}/tdb* >/dev/null 2>&1 - printf "Starting xenservices: xenstored, xenconsoled, xenbackendd." + printf "Starting xenservices: xenstored, xenconsoled." XENSTORED_ARGS=" --pid-file ${XENSTORED_PIDFILE}" if [ -n "${XENSTORED_TRACE}" ]; then XENSTORED_ARGS="${XENSTORED_ARGS} -T /var/log/xen/xenstored-trace.log" @@ -68,13 +68,6 @@ xen_startcmd() ${SBINDIR}/xenconsoled ${XENCONSOLED_ARGS} - XENBACKENDD_ARGS="" - if [ -n "${XENBACKENDD_DEBUG}" ]; then - XENBACKENDD_ARGS="${XENBACKENDD_ARGS} -d" - fi - - ${SBINDIR}/xenbackendd ${XENBACKENDD_ARGS} - printf "\n" printf "Setting domain 0 name.\n" diff -r 7e44ba113546 -r 3009fd6e30ea tools/hotplug/NetBSD/rc.d/xend --- a/tools/hotplug/NetBSD/rc.d/xend Fri Sep 30 14:38:55 2011 +0200 +++ b/tools/hotplug/NetBSD/rc.d/xend Fri Sep 30 14:38:55 2011 +0200 @@ -1,7 +1,7 @@ #!/bin/sh # # PROVIDE: xend -# REQUIRE: xencommons +# REQUIRE: xencommons xenbackendd . /etc/rc.subr _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel From xen-devel-bounces@lists.xensource.com Fri Sep 30 05:56:08 2011 Return-path: <xen-devel-bounces@lists.xensource.com> Envelope-to: www-data@lists.xensource.com Delivery-date: Fri, 30 Sep 2011 05:56:08 -0700 Received: from localhost ([127.0.0.1] helo=lists.colo.xensource.com) by lists.xensource.com with esmtp (Exim 4.43) id 1R9cdM-0004tR-H0; Fri, 30 Sep 2011 05:56:08 -0700 Received: from mail174.messagelabs.com ([85.158.138.51]) by lists.xensource.com with esmtp (Exim 4.43) id 1R9cY5-0002uE-6K for xen-devel@lists.xensource.com; Fri, 30 Sep 2011 05:50:43 -0700 X-Env-Sender: Ian.Campbell@eu.citrix.com X-Msg-Ref: server-14.tower-174.messagelabs.com!1317387037!33376428!1 X-Originating-IP: [62.200.22.115] X-StarScan-Version: 6.4.1; banners=-,-,- X-VirusChecked: Checked Received: (qmail 4140 invoked from network); 30 Sep 2011 12:50:37 -0000 Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115) by server-14.tower-174.messagelabs.com with RC4-SHA encrypted SMTP; 30 Sep 2011 12:50:37 -0000 X-IronPort-AV: E=Sophos;i="4.68,467,1312156800"; d="scan'208";a="8151369" Received: from lonpmailmx01.citrite.net ([10.30.203.162]) by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5; 30 Sep 2011 12:50:37 +0000 Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net (10.30.203.162) with Microsoft SMTP Server id 8.3.137.0; Fri, 30 Sep 2011 13:50:37 +0100 Subject: Re: [Xen-devel] [PATCH 4 of 7] [OCAML] Fix a problem with ocaml xenstored From: Ian Campbell <Ian.Campbell@eu.citrix.com> To: Jonathan Ludlam <Jonathan.Ludlam@eu.citrix.com> Date: Fri, 30 Sep 2011 13:50:36 +0100 In-Reply-To: <310859A4-B038-4784-A51B-F4B217FD575D@eu.citrix.com> References: <patchbomb.1317331042@snoosnoo2.uk.xensource.com> <b6022a18ebb012b8af85.1317331046@snoosnoo2.uk.xensource.com> <1317368963.26672.210.camel@zakaz.uk.xensource.com> <310859A4-B038-4784-A51B-F4B217FD575D@eu.citrix.com> Organization: Citrix Systems, Inc. Content-Type: text/plain; charset="UTF-8" X-Mailer: Evolution 3.0.3- Content-Transfer-Encoding: 7bit Message-ID: <1317387036.26672.279.camel@zakaz.uk.xensource.com> MIME-Version: 1.0 Cc: xen-devel <xen-devel@lists.xensource.com> X-BeenThere: xen-devel@lists.xensource.com X-Mailman-Version: 2.1.5 Precedence: list List-Id: Xen developer discussion <xen-devel.lists.xensource.com> List-Unsubscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe> List-Post: <mailto:xen-devel@lists.xensource.com> List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help> List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=subscribe> Sender: xen-devel-bounces@lists.xensource.com Errors-To: xen-devel-bounces@lists.xensource.com On Fri, 2011-09-30 at 13:22 +0100, Jonathan Ludlam wrote: > Ah, that's a shame. I was hoping this was a bugfix to the ocaml > xenstored and that the C version already did this. Unfortunately the > patch here went in to XenServer a couple of years ago, and Thomas, who > made the change, has since left. I'll dig into this and see why we > depend upon it. Seems to be CA-30927 which was "internal shutdown doesn't work anymore after VM.checkpoint": The bugs comes from the fact that xal always assume that suspended domains are or will be soon dead. However, for VM.checkpoint that assumptions is false, as the VM is suspended, snapshoted, and then resumed, without destroying the domain. Thomas said in that ticket: I fixed this issue by: * teach to xal how to handle dead domains for suspended reasons which become suddenly alive * when resuming a domain, use the xenstore introduce call * modify xenstore to generates a @introduceDomain event even if the introduced domain does not exists I believe nobody care to see too many @introduceDomain event, so that will not change anything. My fix modifies the code path taken by VM.suspend, but that should be safe because xapi destroys properly the domain after suspending it. (I think he meant _does_ exist in the third bullet). In his commit message he said: Teach xal what to do with dead domains which become alive again. Needed to modify xenstored as well in order to trigger a @introduceDomain event even if the introduce call tries to introduce an already existing domain. That will kick-up xal in case when resuming the domain. I think possibly the right fix would have been to have xal kick-up itself. That said spurious @introduceDomain watches are pretty harmless (as he suggests) since they have no context, the recipient has to go and check it's idea of the world vs the real state to know what happened an the answer "nothing" is not a big deal... Ian. > > Jon > > On 30 Sep 2011, at 08:49, Ian Campbell wrote: > > > On Thu, 2011-09-29 at 22:17 +0100, Jon Ludlam wrote: > >> Have xenstored trigger an @introduceDomain event even if the > >> introduce call tries to introduce an already existing domain. > > > > The C daemon doesn't appear to behave this way. It would be nice to > > explain why this change is necessary. > > > >> Signed-off-by: Thomas Gazagnaire <thomas@ocamlpro.com> > >> Acked-by: Jon Ludlam <jonathan.ludlam@eu.citrix.com> > >> > >> diff -r 734cb0807357 -r b6022a18ebb0 tools/ocaml/xenstored/process.ml > >> --- a/tools/ocaml/xenstored/process.ml > >> +++ b/tools/ocaml/xenstored/process.ml > >> @@ -168,9 +168,10 @@ > >> | _ -> raise Invalid_Cmd_Args; > >> in > >> let dom = > >> - if Domains.exist domains domid then > >> + if Domains.exist domains domid then begin > >> + Connections.fire_spec_watches cons "@introduceDomain"; > >> Domains.find domains domid > >> - else try > >> + end else try > >> let ndom = Xc.with_intf (fun xc -> > >> Domains.create xc domains domid mfn port) in > >> Connections.add_domain cons ndom; > >> > >> _______________________________________________ > >> Xen-devel mailing list > >> Xen-devel@lists.xensource.com > >> http://lists.xensource.com/xen-devel > > > > > _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel From xen-devel-bounces@lists.xensource.com Fri Sep 30 05:57:05 2011 Return-path: <xen-devel-bounces@lists.xensource.com> Envelope-to: www-data@lists.xensource.com Delivery-date: Fri, 30 Sep 2011 05:57:05 -0700 Received: from localhost ([127.0.0.1] helo=lists.colo.xensource.com) by lists.xensource.com with esmtp (Exim 4.43) id 1R9ceH-0005Go-5f; Fri, 30 Sep 2011 05:57:05 -0700 Received: from mail174.messagelabs.com ([85.158.138.51]) by lists.xensource.com with esmtp (Exim 4.43) id 1R9cb6-00048W-Rp for xen-devel@lists.xensource.com; Fri, 30 Sep 2011 05:53:49 -0700 X-Env-Sender: Christoph.Egger@amd.com X-Msg-Ref: server-9.tower-174.messagelabs.com!1317387224!27342243!1 X-Originating-IP: [65.55.88.13] X-StarScan-Version: 6.4.1; banners=-,-,- X-VirusChecked: Checked Received: (qmail 4324 invoked from network); 30 Sep 2011 12:53:45 -0000 Received: from tx2ehsobe003.messaging.microsoft.com (HELO TX2EHSOBE006.bigfish.com) (65.55.88.13) by server-9.tower-174.messagelabs.com with AES128-SHA encrypted SMTP; 30 Sep 2011 12:53:45 -0000 Received: from mail154-tx2-R.bigfish.com (10.9.14.245) by TX2EHSOBE006.bigfish.com (10.9.40.26) with Microsoft SMTP Server id 14.1.225.22; Fri, 30 Sep 2011 12:53:44 +0000 Received: from mail154-tx2 (localhost.localdomain [127.0.0.1]) by mail154-tx2-R.bigfish.com (Postfix) with ESMTP id E48DA18F83EA; Fri, 30 Sep 2011 12:53:43 +0000 (UTC) X-SpamScore: -11 X-BigFish: VPS-11(zzbb2dK1432N98dKzz1202hzz8275bhz32i668h839h) X-Forefront-Antispam-Report: CIP:163.181.249.109; KIP:(null); UIP:(null); IPVD:NLI; H:ausb3twp02.amd.com; RD:none; EFVD:NLI X-FB-SS: 0,13, Received: from mail154-tx2 (localhost.localdomain [127.0.0.1]) by mail154-tx2 (MessageSwitch) id 1317387162885596_9576; Fri, 30 Sep 2011 12:52:42 +0000 (UTC) Received: from TX2EHSMHS029.bigfish.com (unknown [10.9.14.242]) by mail154-tx2.bigfish.com (Postfix) with ESMTP id D08BC1808053; Fri, 30 Sep 2011 12:52:42 +0000 (UTC) Received: from ausb3twp02.amd.com (163.181.249.109) by TX2EHSMHS029.bigfish.com (10.9.99.129) with Microsoft SMTP Server id 14.1.225.22; Fri, 30 Sep 2011 12:52:38 +0000 X-WSS-ID: 0LSC6FL-02-0BD-02 X-M-MSG: Received: from sausexedgep02.amd.com (sausexedgep02-ext.amd.com [163.181.249.73]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by ausb3twp02.amd.com (Axway MailGate 3.8.1) with ESMTP id 2A110C83CC; Fri, 30 Sep 2011 07:52:32 -0500 (CDT) Received: from sausexhtp01.amd.com (163.181.3.165) by sausexedgep02.amd.com (163.181.36.59) with Microsoft SMTP Server (TLS) id 8.3.106.1; Fri, 30 Sep 2011 07:52:55 -0500 Received: from storexhtp01.amd.com (172.24.4.3) by sausexhtp01.amd.com (163.181.3.165) with Microsoft SMTP Server (TLS) id 8.3.83.0; Fri, 30 Sep 2011 07:52:37 -0500 Received: from rhodium.osrc.amd.com (165.204.15.173) by storexhtp01.amd.com (172.24.4.3) with Microsoft SMTP Server id 8.3.83.0; Fri, 30 Sep 2011 08:52:35 -0400 Message-ID: <4E85BB92.10605@amd.com> Date: Fri, 30 Sep 2011 14:52:34 +0200 From: Christoph Egger <Christoph.Egger@amd.com> User-Agent: Mozilla/5.0 (X11; U; NetBSD amd64; en-US; rv:1.9.2.17) Gecko/20110523 Lightning/1.0b3pre Thunderbird/3.1.10 MIME-Version: 1.0 To: Roger Pau Monne <roger.pau@entel.upc.edu> Subject: Re: [Xen-devel] [PATCH 1 of 9] xenbackendd: fix incorrect usage of pidfile References: <patchbomb.1317386580@loki> <47005b3da245e2be052b.1317386581@loki> In-Reply-To: <47005b3da245e2be052b.1317386581@loki> Content-Type: text/plain; charset="ISO-8859-1"; format=flowed Content-Transfer-Encoding: 7bit X-OriginatorOrg: amd.com Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com> X-BeenThere: xen-devel@lists.xensource.com X-Mailman-Version: 2.1.5 Precedence: list List-Id: Xen developer discussion <xen-devel.lists.xensource.com> List-Unsubscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe> List-Post: <mailto:xen-devel@lists.xensource.com> List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help> List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=subscribe> Sender: xen-devel-bounces@lists.xensource.com Errors-To: xen-devel-bounces@lists.xensource.com On 09/30/11 14:43, Roger Pau Monne wrote: > # HG changeset patch > # User Roger Pau Monne<roger.pau@entel.upc.edu> > # Date 1317300282 -7200 > # Node ID 47005b3da245e2be052b614c02ed212d3d2cecbd > # Parent a422e2a4451e16dc791b293f41966b842fa4781d > xenbackendd: fix incorrect usage of pidfile > > Fix xenbackendd ignoring the pidfile passed through the command line. > > Signed-off-by: Roger Pau Monne<roger.pau@entel.upc.edu> Acked-by: Christoph Egger <Christoph.Egger@amd.com> > > diff -r a422e2a4451e -r 47005b3da245 tools/xenbackendd/xenbackendd.c > --- a/tools/xenbackendd/xenbackendd.c Sun Sep 18 00:26:52 2011 +0100 > +++ b/tools/xenbackendd/xenbackendd.c Thu Sep 29 14:44:42 2011 +0200 > @@ -169,7 +169,7 @@ main(int argc, char * const argv[]) > log_file = optarg; > break; > case 'p': > - pidfile = pidfile; > + pidfile = optarg; > case 's': > vbd_script = optarg; > break; > -- ---to satisfy European Law for business letters: Advanced Micro Devices GmbH Einsteinring 24, 85689 Dornach b. Muenchen Geschaeftsfuehrer: Alberto Bozzo, Andrew Bowd Sitz: Dornach, Gemeinde Aschheim, Landkreis Muenchen Registergericht Muenchen, HRB Nr. 43632 _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel From xen-devel-bounces@lists.xensource.com Fri Sep 30 06:05:20 2011 Return-path: <xen-devel-bounces@lists.xensource.com> Envelope-to: www-data@lists.xensource.com Delivery-date: Fri, 30 Sep 2011 06:05:20 -0700 Received: from localhost ([127.0.0.1] helo=lists.colo.xensource.com) by lists.xensource.com with esmtp (Exim 4.43) id 1R9cmF-0005n1-Cw; Fri, 30 Sep 2011 06:05:19 -0700 Received: from mail182.messagelabs.com ([85.158.139.83]) by lists.xensource.com with esmtp (Exim 4.43) id 1R9ck5-0005Ze-SS for xen-devel@lists.xensource.com; Fri, 30 Sep 2011 06:03:25 -0700 X-Env-Sender: nupurghatnekar@gmail.com X-Msg-Ref: server-3.tower-182.messagelabs.com!1317387780!17577615!1 X-Originating-IP: [209.85.160.171] X-StarScan-Version: 6.4.1; banners=-,-,- X-VirusChecked: Checked Received: (qmail 21240 invoked from network); 30 Sep 2011 13:03:02 -0000 Received: from mail-gy0-f171.google.com (HELO mail-gy0-f171.google.com) (209.85.160.171) by server-3.tower-182.messagelabs.com with RC4-SHA encrypted SMTP; 30 Sep 2011 13:03:02 -0000 Received: by gyh3 with SMTP id 3so2463161gyh.30 for <xen-devel@lists.xensource.com>; Fri, 30 Sep 2011 06:03:00 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=gUapGdTA9Huw77iCIceXICgWutrxAIFzFlFoUEYUVqE=; b=TlWPaprWj2gC6c3cuJzldkfjuAFBe05rbwee+qD7d4kCIU5xN+gJgA0QBncScjoGL2 YAptBvw2iKXsZqX+P7Ou4wC/Ek/Sxn3twfNvxC9VkxFYK/jUFNggccKKZV+O5i9ndmEe KzFzf6+CdupD4kqCQgQudPaVV9fG+2XEaIEPY= MIME-Version: 1.0 Received: by 10.68.16.38 with SMTP id c6mr59134552pbd.5.1317387780240; Fri, 30 Sep 2011 06:03:00 -0700 (PDT) Received: by 10.142.210.20 with HTTP; Fri, 30 Sep 2011 06:03:00 -0700 (PDT) In-Reply-To: <1317367849.26672.195.camel@zakaz.uk.xensource.com> References: <CAO8_4Vq7Q145GWwW8jG0oOs6TugQvP764njJ3JLtrAZ766tNUw@mail.gmail.com> <1316692074.23371.60.camel@zakaz.uk.xensource.com> <CAO8_4Vq11UWq6ZBpKPJ4pS60t2OcXan8-eKPEqzdD_aGfc=Pww@mail.gmail.com> <1317367849.26672.195.camel@zakaz.uk.xensource.com> Date: Fri, 30 Sep 2011 18:33:00 +0530 Message-ID: <CAO8_4VopoNxrTpgnxqnQskgXM0K6-Q09UHrNJX8mH4ib96oqvg@mail.gmail.com> Subject: Re: [Xen-devel] Virtual File System in XEN From: Nupur Ghatnekar <nupurghatnekar@gmail.com> To: Ian Campbell <Ian.Campbell@citrix.com> Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com> X-BeenThere: xen-devel@lists.xensource.com X-Mailman-Version: 2.1.5 Precedence: list List-Id: Xen developer discussion <xen-devel.lists.xensource.com> List-Unsubscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe> List-Post: <mailto:xen-devel@lists.xensource.com> List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help> List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=subscribe> Content-Type: multipart/mixed; boundary="===============1800158974==" Sender: xen-devel-bounces@lists.xensource.com Errors-To: xen-devel-bounces@lists.xensource.com --===============1800158974== Content-Type: multipart/alternative; boundary=bcaec520e5e5ac345d04ae283e22 --bcaec520e5e5ac345d04ae283e22 Content-Type: text/plain; charset=UTF-8 On Fri, Sep 30, 2011 at 1:00 PM, Ian Campbell <Ian.Campbell@citrix.com>wrote: > (please try not to top post) > > On Fri, 2011-09-30 at 03:57 +0100, Nupur Ghatnekar wrote: > > We are planning to port the VirtFS implemented in the KVM land > > ( > http://www.sciweavers.org/publications/virtfs-virtualization-aware-file-system-pass-through) > to XEN land. > > > > The advantages are > > 1) sharing > > 2) security > > 3)reduced translations > > Is this the same "virtfs" as is documented here > http://wiki.qemu.org/Documentation/9psetup ? It certainly appears to be > the same thing (the authors of the paper include a qemu maintainer). > > Ian. > > > > Yes, it is the same thing. Implemented in KVM. We are trying to do so in XEN. -- Nupur Ghatnekar --bcaec520e5e5ac345d04ae283e22 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable <br><br><div class=3D"gmail_quote">On Fri, Sep 30, 2011 at 1:00 PM, Ian Cam= pbell <span dir=3D"ltr"><<a href=3D"mailto:Ian.Campbell@citrix.com">Ian.= Campbell@citrix.com</a>></span> wrote:<br><blockquote class=3D"gmail_quo= te" style=3D"margin: 0pt 0pt 0pt 0.8ex; border-left: 1px solid rgb(204, 204= , 204); padding-left: 1ex;"> (please try not to top post)<br> <div class=3D"im"><br> On Fri, 2011-09-30 at 03:57 +0100, Nupur Ghatnekar wrote:<br> > We are planning to port the VirtFS implemented in the KVM land<br> > ( <a href=3D"http://www.sciweavers.org/publications/virtfs-virtualizat= ion-aware-file-system-pass-through" target=3D"_blank">http://www.sciweavers= .org/publications/virtfs-virtualization-aware-file-system-pass-through</a>)= to XEN land.<br> ><br> > The advantages are<br> > 1) sharing<br> > 2) security<br> > 3)reduced translations<br> <br> </div>Is this the same "virtfs" as is documented here<br> <a href=3D"http://wiki.qemu.org/Documentation/9psetup" target=3D"_blank">ht= tp://wiki.qemu.org/Documentation/9psetup</a> ? It certainly appears to be<b= r> the same thing (the authors of the paper include a qemu maintainer).<br> <font color=3D"#888888"><br> Ian.<br> <br> <br> <br> </font></blockquote></div><br>Yes, it is the same thing.<br>Implemented in = KVM. We are trying to do so in XEN.<br clear=3D"all"><br>-- <br><br>Nupur G= hatnekar<br> --bcaec520e5e5ac345d04ae283e22-- --===============1800158974== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel --===============1800158974==-- From xen-devel-bounces@lists.xensource.com Fri Sep 30 06:07:46 2011 Return-path: <xen-devel-bounces@lists.xensource.com> Envelope-to: www-data@lists.xensource.com Delivery-date: Fri, 30 Sep 2011 06:07:46 -0700 Received: from localhost ([127.0.0.1] helo=lists.colo.xensource.com) by lists.xensource.com with esmtp (Exim 4.43) id 1R9coc-0006BO-Pl; Fri, 30 Sep 2011 06:07:46 -0700 Received: from mail21.messagelabs.com ([85.158.143.35]) by lists.xensource.com with esmtp (Exim 4.43) id 1R9co2-0005zH-0l for xen-devel@lists.xensource.com; Fri, 30 Sep 2011 06:07:10 -0700 X-Env-Sender: Ian.Campbell@eu.citrix.com X-Msg-Ref: server-14.tower-21.messagelabs.com!1317388018!61609505!1 X-Originating-IP: [62.200.22.115] X-StarScan-Version: 6.4.1; banners=-,-,- X-VirusChecked: Checked Received: (qmail 16077 invoked from network); 30 Sep 2011 13:06:58 -0000 Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115) by server-14.tower-21.messagelabs.com with RC4-SHA encrypted SMTP; 30 Sep 2011 13:06:58 -0000 X-IronPort-AV: E=Sophos;i="4.68,467,1312156800"; d="scan'208";a="8151960" Received: from lonpmailmx01.citrite.net ([10.30.203.162]) by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5; 30 Sep 2011 13:07:06 +0000 Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net (10.30.203.162) with Microsoft SMTP Server id 8.3.137.0; Fri, 30 Sep 2011 14:07:06 +0100 Subject: Re: [Xen-devel] Virtual File System in XEN From: Ian Campbell <Ian.Campbell@eu.citrix.com> To: Nupur Ghatnekar <nupurghatnekar@gmail.com> Date: Fri, 30 Sep 2011 14:07:06 +0100 In-Reply-To: <CAO8_4VopoNxrTpgnxqnQskgXM0K6-Q09UHrNJX8mH4ib96oqvg@mail.gmail.com> References: <CAO8_4Vq7Q145GWwW8jG0oOs6TugQvP764njJ3JLtrAZ766tNUw@mail.gmail.com> <1316692074.23371.60.camel@zakaz.uk.xensource.com> <CAO8_4Vq11UWq6ZBpKPJ4pS60t2OcXan8-eKPEqzdD_aGfc=Pww@mail.gmail.com> <1317367849.26672.195.camel@zakaz.uk.xensource.com> <CAO8_4VopoNxrTpgnxqnQskgXM0K6-Q09UHrNJX8mH4ib96oqvg@mail.gmail.com> Organization: Citrix Systems, Inc. Content-Type: text/plain; charset="UTF-8" X-Mailer: Evolution 3.0.3- Content-Transfer-Encoding: 7bit Message-ID: <1317388026.26672.283.camel@zakaz.uk.xensource.com> MIME-Version: 1.0 Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com> X-BeenThere: xen-devel@lists.xensource.com X-Mailman-Version: 2.1.5 Precedence: list List-Id: Xen developer discussion <xen-devel.lists.xensource.com> List-Unsubscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe> List-Post: <mailto:xen-devel@lists.xensource.com> List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help> List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=subscribe> Sender: xen-devel-bounces@lists.xensource.com Errors-To: xen-devel-bounces@lists.xensource.com On Fri, 2011-09-30 at 14:03 +0100, Nupur Ghatnekar wrote: > > > On Fri, Sep 30, 2011 at 1:00 PM, Ian Campbell > <Ian.Campbell@citrix.com> wrote: > > Is this the same "virtfs" as is documented here > http://wiki.qemu.org/Documentation/9psetup ? It certainly > appears to be the same thing (the authors of the paper include > a qemu maintainer). > Yes, it is the same thing. > Implemented in KVM. We are trying to do so in XEN. I think it is actually implemented using virtio rather than as part of KVM, isn't it? For example I think it works for stand qemu guests, not just KVM. In which case building upon the virtio-on-xen GSoC project, as I initially suggested, seems like a better idea than actually porting it to Xen. Ian. _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel From xen-devel-bounces@lists.xensource.com Fri Sep 30 06:11:52 2011 Return-path: <xen-devel-bounces@lists.xensource.com> Envelope-to: www-data@lists.xensource.com Delivery-date: Fri, 30 Sep 2011 06:11:52 -0700 Received: from localhost ([127.0.0.1] helo=lists.colo.xensource.com) by lists.xensource.com with esmtp (Exim 4.43) id 1R9csa-0006ao-IB; Fri, 30 Sep 2011 06:11:52 -0700 Received: from mail27.messagelabs.com ([193.109.254.147]) by lists.xensource.com with esmtp (Exim 4.43) id 1R9cro-0006Os-J5 for xen-devel@lists.xensource.com; Fri, 30 Sep 2011 06:11:07 -0700 X-Env-Sender: Ian.Campbell@eu.citrix.com X-Msg-Ref: server-14.tower-27.messagelabs.com!1317388148!38282276!1 X-Originating-IP: [66.165.176.63] X-StarScan-Version: 6.4.1; banners=-,-,- X-VirusChecked: Checked Received: (qmail 10646 invoked from network); 30 Sep 2011 13:09:09 -0000 Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63) by server-14.tower-27.messagelabs.com with RC4-SHA encrypted SMTP; 30 Sep 2011 13:09:09 -0000 X-IronPort-AV: E=Sophos;i="4.68,467,1312171200"; d="scan'208";a="165283375" Received: from ftlpmailmx02.citrite.net ([10.13.107.66]) by FTLPIPO02.CITRIX.COM with ESMTP/TLS/RC4-MD5; 30 Sep 2011 09:10:59 -0400 Received: from smtp01.ad.xensource.com (10.219.128.104) by smtprelay.citrix.com (10.13.107.66) with Microsoft SMTP Server id 8.3.137.0; Fri, 30 Sep 2011 09:11:00 -0400 Received: from cosworth.uk.xensource.com (cosworth.uk.xensource.com [10.80.16.52]) by smtp01.ad.xensource.com (8.13.1/8.13.1) with ESMTP id p8UDAwLM029142; Fri, 30 Sep 2011 06:10:58 -0700 Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Mercurial-Node: 222533abc1159bfa9c8cd522649c10079f6a6e9c Message-ID: <222533abc1159bfa9c8c.1317388257@cosworth.uk.xensource.com> User-Agent: Mercurial-patchbomb/1.6.4 Date: Fri, 30 Sep 2011 14:10:57 +0100 From: Ian Campbell <ian.campbell@citrix.com> To: xen-devel@lists.xensource.com Cc: Ian Campbell <ian.campbell@citrix.com> Subject: [Xen-devel] [PATCH] libxl: add missing "break;" to do_pci_remove X-BeenThere: xen-devel@lists.xensource.com X-Mailman-Version: 2.1.5 Precedence: list List-Id: Xen developer discussion <xen-devel.lists.xensource.com> List-Unsubscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe> List-Post: <mailto:xen-devel@lists.xensource.com> List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help> List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=subscribe> Sender: xen-devel-bounces@lists.xensource.com Errors-To: xen-devel-bounces@lists.xensource.com # HG changeset patch # User Ian Campbell <ian.campbell@citrix.com> # Date 1317388225 -3600 # Node ID 222533abc1159bfa9c8cd522649c10079f6a6e9c # Parent e50da6b98e3d5933b9c98e8f43096fd3ebbae00d libxl: add missing "break;" to do_pci_remove Otherwise we erroneously fall through the LIBXL_DOMAIN_TYPE_PV case into the "default: abort()". (I'm sure we fixed this once already...) Signed-off-by: Ian Campbell <ian.campbell@citrix.com> diff -r e50da6b98e3d -r 222533abc115 tools/libxl/libxl_pci.c --- a/tools/libxl/libxl_pci.c Thu Sep 29 17:21:32 2011 +0100 +++ b/tools/libxl/libxl_pci.c Fri Sep 30 14:10:25 2011 +0100 @@ -930,6 +930,7 @@ skip1: } } fclose(f); + break; } default: abort(); _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel From xen-devel-bounces@lists.xensource.com Fri Sep 30 06:15:21 2011 Return-path: <xen-devel-bounces@lists.xensource.com> Envelope-to: www-data@lists.xensource.com Delivery-date: Fri, 30 Sep 2011 06:15:21 -0700 Received: from localhost ([127.0.0.1] helo=lists.colo.xensource.com) by lists.xensource.com with esmtp (Exim 4.43) id 1R9cvx-00077b-Pz; Fri, 30 Sep 2011 06:15:21 -0700 Received: from mail27.messagelabs.com ([193.109.254.147]) by lists.xensource.com with esmtp (Exim 4.43) id 1R9cv3-0006ue-DA for xen-devel@lists.xensource.com; Fri, 30 Sep 2011 06:14:25 -0700 X-Env-Sender: royger@gmail.com X-Msg-Ref: server-5.tower-27.messagelabs.com!1317388441!47050809!1 X-Originating-IP: [74.125.82.43] X-StarScan-Version: 6.4.1; banners=-,-,- X-VirusChecked: Checked Received: (qmail 7389 invoked from network); 30 Sep 2011 13:14:01 -0000 Received: from mail-ww0-f43.google.com (HELO mail-ww0-f43.google.com) (74.125.82.43) by server-5.tower-27.messagelabs.com with RC4-SHA encrypted SMTP; 30 Sep 2011 13:14:01 -0000 Received: by wwf27 with SMTP id 27so2202552wwf.24 for <xen-devel@lists.xensource.com>; Fri, 30 Sep 2011 06:14:22 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=sender:content-type:mime-version:content-transfer-encoding:subject :x-mercurial-node:message-id:user-agent:date:from:to:reply-to; bh=/6xtsBmmuC4WjSMwdnGpby4HQyviIQfjHaMRW7Qbu9M=; b=ephpAoWWKOuJbJm7Q0dHeDQ03ZbIqsg98i3T9Amn6/J6yehasJb9EumXRHMR2CcAYe o+iHrevxxsouXaaOPyZyyQsO79TpdtiXnf6lC/nWiujBUTwu+aVkv5usWj36GPtRKKqW N1E7j6HuBp+I/b4oPJWFWWdMMSzUMus0exNhc= Received: by 10.227.199.209 with SMTP id et17mr2601741wbb.36.1317388462159; Fri, 30 Sep 2011 06:14:22 -0700 (PDT) Received: from [127.0.0.1] (queen.upc.es. [147.83.39.247]) by mx.google.com with ESMTPS id h14sm5429517wbo.7.2011.09.30.06.14.19 (version=TLSv1/SSLv3 cipher=OTHER); Fri, 30 Sep 2011 06:14:20 -0700 (PDT) Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Mercurial-Node: c925c6f28dec6b8df678701b8ec6f981b2e96ba4 Message-Id: <c925c6f28dec6b8df678.1317388441@loki> User-Agent: Mercurial-patchbomb/1.9.2 Date: Fri, 30 Sep 2011 15:14:01 +0200 From: Roger Pau Monne <roger.pau@entel.upc.edu> To: xen-devel@lists.xensource.com Subject: [Xen-devel] [PATCH] rc.d NetBSD: don't start xenbackendd by default, only when xend needs it X-BeenThere: xen-devel@lists.xensource.com X-Mailman-Version: 2.1.5 Precedence: list Reply-To: 3009fd6e30ea90b5a55d.1317386589@loki List-Id: Xen developer discussion <xen-devel.lists.xensource.com> List-Unsubscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe> List-Post: <mailto:xen-devel@lists.xensource.com> List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help> List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=subscribe> Sender: xen-devel-bounces@lists.xensource.com Errors-To: xen-devel-bounces@lists.xensource.com # HG changeset patch # User Roger Pau Monne <roger.pau@entel.upc.edu> # Date 1317388210 -7200 # Node ID c925c6f28dec6b8df678701b8ec6f981b2e96ba4 # Parent 7e44ba113546e4c2db56ebf9b0b251dcd9a1948a rc.d NetBSD: don't start xenbackendd by default, only when xend needs it. With the move of hotplug scripts from xenbackendd to libxl xenbackendd is no longer needed by libxl, only start it when xend is started. Signed-off-by: Roger Pau Monne <roger.pau@entel.upc.edu> diff -r 7e44ba113546 -r c925c6f28dec tools/hotplug/NetBSD/rc.d/xenbackendd --- /dev/null Thu Jan 01 00:00:00 1970 +0000 +++ b/tools/hotplug/NetBSD/rc.d/xenbackendd Fri Sep 30 15:10:10 2011 +0200 @@ -0,0 +1,27 @@ +#!/bin/sh +# +# PROVIDE: xenbackendd +# REQUIRE: xencommons + +. /etc/rc.subr + +DIR=$(dirname "$0") +. "${DIR}/xen-hotplugpath.sh" + +LD_LIBRARY_PATH="${LIBDIR}" +export LD_LIBRARY_PATH PYTHONPATH +PATH="${PATH}:${SBINDIR}" +export PATH + +name="xenbackendd" +rcvar=$name +command="${SBINDIR}/xenbackendd" +if [ -n "${XENBACKENDD_DEBUG}" ]; then + command_args="${XENBACKENDD_ARGS} -d" +else + command_args="${XENBACKENDD_ARGS}" +fi + +load_rc_config $name +run_rc_command "$1" + diff -r 7e44ba113546 -r c925c6f28dec tools/hotplug/NetBSD/rc.d/xencommons --- a/tools/hotplug/NetBSD/rc.d/xencommons Fri Sep 30 14:38:55 2011 +0200 +++ b/tools/hotplug/NetBSD/rc.d/xencommons Fri Sep 30 15:10:10 2011 +0200 @@ -22,10 +22,6 @@ required_files="/kern/xen/privcmd" XENSTORED_PIDFILE="/var/run/xenstored.pid" XENCONSOLED_PIDFILE="/var/run/xenconsoled.pid" -XENBACKENDD_PIDFILE="/var/run/xenbackendd.pid" -#XENBACKENDD_DEBUG=1 -#XENCONSOLED_TRACE="/var/log/xen/xenconsole-trace.log" -#XENSTORED_TRACE="/var/log/xen/xenstore-trace.log" xen_precmd() { @@ -46,7 +42,7 @@ xen_startcmd() XENSTORED_ROOTDIR="/var/lib/xenstored" fi rm -f ${XENSTORED_ROOTDIR}/tdb* >/dev/null 2>&1 - printf "Starting xenservices: xenstored, xenconsoled, xenbackendd." + printf "Starting xenservices: xenstored, xenconsoled." XENSTORED_ARGS=" --pid-file ${XENSTORED_PIDFILE}" if [ -n "${XENSTORED_TRACE}" ]; then XENSTORED_ARGS="${XENSTORED_ARGS} -T /var/log/xen/xenstored-trace.log" @@ -68,13 +64,6 @@ xen_startcmd() ${SBINDIR}/xenconsoled ${XENCONSOLED_ARGS} - XENBACKENDD_ARGS="" - if [ -n "${XENBACKENDD_DEBUG}" ]; then - XENBACKENDD_ARGS="${XENBACKENDD_ARGS} -d" - fi - - ${SBINDIR}/xenbackendd ${XENBACKENDD_ARGS} - printf "\n" printf "Setting domain 0 name.\n" @@ -87,8 +76,6 @@ xen_stop() printf "Stopping xencommons.\n" printf "WARNING: Not stopping xenstored, as it cannot be restarted.\n" - rc_pid=$(check_pidfile ${XENBACKENDD_PIDFILE} ${SBINDIR}/xenbackendd) - pids="$pids $rc_pid" rc_pid=$(check_pidfile ${XENCONSOLED_PIDFILE} ${SBINDIR}/xenconsoled) pids="$pids $rc_pid" @@ -108,17 +95,12 @@ xen_status() pids="$pids $xenconsoled_pid" fi - xenbackend_pid=$(check_pidfile ${XENBACKENDD_PIDFILE} ${SBINDIR}/xenbackendd) - if test -n ${xenbackend_pid}; then - pids="$pids $xenbackend_pid" - fi - - if test -n "$xenbackend_pid" -a -n "$xenconsoled_pid" -a -n "$xenstored_pid"; + if test -n "$xenconsoled_pid" -a -n "$xenstored_pid"; then echo "xencommons are running as pids $pids." return 0 fi - if test -z "$xenbackend_pid" -a -z "$xenconsoled_pid" -a -z "$xenstored_pid"; + if test -z "$xenconsoled_pid" -a -z "$xenstored_pid"; then echo "xencommons are not running." return 0 @@ -134,11 +116,6 @@ xen_status() else echo "xenconsoled is not running." fi - if test -n $xenbackend_pid; then - echo "xenbackendd is running as pid $xenbackend_pid." - else - echo "xenbackendd is not running." - fi } load_rc_config $name diff -r 7e44ba113546 -r c925c6f28dec tools/hotplug/NetBSD/rc.d/xend --- a/tools/hotplug/NetBSD/rc.d/xend Fri Sep 30 14:38:55 2011 +0200 +++ b/tools/hotplug/NetBSD/rc.d/xend Fri Sep 30 15:10:10 2011 +0200 @@ -1,7 +1,7 @@ #!/bin/sh # # PROVIDE: xend -# REQUIRE: xencommons +# REQUIRE: xencommons xenbackendd . /etc/rc.subr _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel From xen-devel-bounces@lists.xensource.com Fri Sep 30 06:20:20 2011 Return-path: <xen-devel-bounces@lists.xensource.com> Envelope-to: www-data@lists.xensource.com Delivery-date: Fri, 30 Sep 2011 06:20:20 -0700 Received: from localhost ([127.0.0.1] helo=lists.colo.xensource.com) by lists.xensource.com with esmtp (Exim 4.43) id 1R9d0m-0007Xn-JZ; Fri, 30 Sep 2011 06:20:20 -0700 Received: from mail21.messagelabs.com ([85.158.143.35]) by lists.xensource.com with esmtp (Exim 4.43) id 1R9d0C-0007LH-4P for xen-devel@lists.xensource.com; Fri, 30 Sep 2011 06:19:46 -0700 X-Env-Sender: Ian.Campbell@eu.citrix.com X-Msg-Ref: server-7.tower-21.messagelabs.com!1317388748!56877729!1 X-Originating-IP: [66.165.176.89] X-StarScan-Version: 6.4.1; banners=-,-,- X-VirusChecked: Checked Received: (qmail 11419 invoked from network); 30 Sep 2011 13:19:09 -0000 Received: from smtp.citrix.com (HELO SMTP.CITRIX.COM) (66.165.176.89) by server-7.tower-21.messagelabs.com with RC4-SHA encrypted SMTP; 30 Sep 2011 13:19:09 -0000 X-IronPort-AV: E=Sophos;i="4.68,467,1312171200"; d="scan'208";a="17840308" Received: from ftlpmailmx02.citrite.net ([10.13.107.66]) by FTLPIPO01.CITRIX.COM with ESMTP/TLS/RC4-MD5; 30 Sep 2011 09:19:39 -0400 Received: from smtp01.ad.xensource.com (10.219.128.104) by smtprelay.citrix.com (10.13.107.66) with Microsoft SMTP Server id 8.3.137.0; Fri, 30 Sep 2011 09:19:39 -0400 Received: from cosworth.uk.xensource.com (cosworth.uk.xensource.com [10.80.16.52]) by smtp01.ad.xensource.com (8.13.1/8.13.1) with ESMTP id p8UDJb8V029186; Fri, 30 Sep 2011 06:19:38 -0700 Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Mercurial-Node: ddd1fcb1dff9f723d4f4c89f97ffef91b3e8a204 Message-ID: <ddd1fcb1dff9f723d4f4.1317388777@cosworth.uk.xensource.com> User-Agent: Mercurial-patchbomb/1.6.4 Date: Fri, 30 Sep 2011 14:19:37 +0100 From: Ian Campbell <ian.campbell@citrix.com> To: xen-devel@lists.xensource.com Cc: Ian Campbell <ian.campbell@citrix.com> Subject: [Xen-devel] [PATCH] build: fix grep invocation in cc-options X-BeenThere: xen-devel@lists.xensource.com X-Mailman-Version: 2.1.5 Precedence: list List-Id: Xen developer discussion <xen-devel.lists.xensource.com> List-Unsubscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe> List-Post: <mailto:xen-devel@lists.xensource.com> List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help> List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=subscribe> Sender: xen-devel-bounces@lists.xensource.com Errors-To: xen-devel-bounces@lists.xensource.com # HG changeset patch # User Ian Campbell <ian.campbell@citrix.com> # Date 1317388735 -3600 # Node ID ddd1fcb1dff9f723d4f4c89f97ffef91b3e8a204 # Parent 222533abc1159bfa9c8cd522649c10079f6a6e9c build: fix grep invocation in cc-options Currently the build produces lots of Usage: grep [OPTION]... PATTERN [FILE]... Try `grep --help' for more information. This is due to the "grep -- $(2)" in cc-options. It seems that the default of reading stdin is disabled when using "--". I don't know if this is a bug in grep or how it is supposed to be but we can work around it by explicitly passing in "-" Signed-off-by: Ian Campbell <ian.campbell@citrix.com> diff -r 222533abc115 -r ddd1fcb1dff9 Config.mk --- a/Config.mk Fri Sep 30 14:10:25 2011 +0100 +++ b/Config.mk Fri Sep 30 14:18:55 2011 +0100 @@ -84,7 +84,7 @@ PYTHON_PREFIX_ARG ?= --install-layout=de # # Usage: cflags-y += $(call cc-option,$(CC),-march=winchip-c6,-march=i586) cc-option = $(shell if test -z "`echo 'void*p=1;' | \ - $(1) $(2) -S -o /dev/null -xc - 2>&1 | grep -- $(2)`"; \ + $(1) $(2) -S -o /dev/null -xc - 2>&1 | grep -- $(2) -`"; \ then echo "$(2)"; else echo "$(3)"; fi ;) # cc-option-add: Add an option to compilation flags, but only if supported. _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel From xen-devel-bounces@lists.xensource.com Fri Sep 30 06:24:55 2011 Return-path: <xen-devel-bounces@lists.xensource.com> Envelope-to: www-data@lists.xensource.com Delivery-date: Fri, 30 Sep 2011 06:24:55 -0700 Received: from localhost ([127.0.0.1] helo=lists.colo.xensource.com) by lists.xensource.com with esmtp (Exim 4.43) id 1R9d5D-0007yU-N1; Fri, 30 Sep 2011 06:24:55 -0700 Received: from mail216.messagelabs.com ([85.158.143.99]) by lists.xensource.com with esmtp (Exim 4.43) id 1R9d4e-0007mD-Ks for xen-devel@lists.xensource.com; Fri, 30 Sep 2011 06:24:21 -0700 X-Env-Sender: Jonathan.Ludlam@eu.citrix.com X-Msg-Ref: server-12.tower-216.messagelabs.com!1317389057!14403490!1 X-Originating-IP: [62.200.22.115] X-StarScan-Version: 6.4.1; banners=-,-,- X-VirusChecked: Checked Received: (qmail 24502 invoked from network); 30 Sep 2011 13:24:17 -0000 Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115) by server-12.tower-216.messagelabs.com with RC4-SHA encrypted SMTP; 30 Sep 2011 13:24:17 -0000 X-IronPort-AV: E=Sophos;i="4.68,467,1312156800"; d="scan'208";a="8152606" Received: from lonpmailmx02.citrite.net ([10.30.203.163]) by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5; 30 Sep 2011 13:24:17 +0000 Received: from LONPMAILBOX01.citrite.net ([10.30.224.160]) by LONPMAILMX02.citrite.net ([10.30.203.163]) with mapi; Fri, 30 Sep 2011 14:24:17 +0100 From: Jonathan Ludlam <Jonathan.Ludlam@eu.citrix.com> To: Ian Campbell <Ian.Campbell@eu.citrix.com> Date: Fri, 30 Sep 2011 14:24:16 +0100 Subject: Re: [Xen-devel] [PATCH 4 of 7] [OCAML] Fix a problem with ocaml xenstored Thread-Topic: [Xen-devel] [PATCH 4 of 7] [OCAML] Fix a problem with ocaml xenstored Thread-Index: Acx/dEC8o/eamDx3RPyJB/wBXQvP3g== Message-ID: <63BFEA71-2066-4CAD-97E1-CF87DD846AC0@eu.citrix.com> References: <patchbomb.1317331042@snoosnoo2.uk.xensource.com> <b6022a18ebb012b8af85.1317331046@snoosnoo2.uk.xensource.com> <1317368963.26672.210.camel@zakaz.uk.xensource.com> <310859A4-B038-4784-A51B-F4B217FD575D@eu.citrix.com> <1317387036.26672.279.camel@zakaz.uk.xensource.com> In-Reply-To: <1317387036.26672.279.camel@zakaz.uk.xensource.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: xen-devel <xen-devel@lists.xensource.com> X-BeenThere: xen-devel@lists.xensource.com X-Mailman-Version: 2.1.5 Precedence: list List-Id: Xen developer discussion <xen-devel.lists.xensource.com> List-Unsubscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe> List-Post: <mailto:xen-devel@lists.xensource.com> List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help> List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=subscribe> Sender: xen-devel-bounces@lists.xensource.com Errors-To: xen-devel-bounces@lists.xensource.com On 30 Sep 2011, at 13:50, Ian Campbell wrote: >=20 > On Fri, 2011-09-30 at 13:22 +0100, Jonathan Ludlam wrote: >> Ah, that's a shame. I was hoping this was a bugfix to the ocaml >> xenstored and that the C version already did this. Unfortunately the >> patch here went in to XenServer a couple of years ago, and Thomas, who >> made the change, has since left. I'll dig into this and see why we >> depend upon it.=20 >=20 > Seems to be CA-30927 which was "internal shutdown doesn't work anymore > after VM.checkpoint": >=20 > The bugs comes from the fact that xal always assume that > suspended domains are or will be soon dead. >=20 > However, for VM.checkpoint that assumptions is false, as the VM > is suspended, snapshoted, and then resumed, without destroying > the domain. >=20 > Thomas said in that ticket: >=20 > I fixed this issue by: > * teach to xal how to handle dead domains for suspended > reasons which become suddenly alive > * when resuming a domain, use the xenstore introduce call > * modify xenstore to generates a @introduceDomain event > even if the introduced domain does not exists >=20 > I believe nobody care to see too many @introduceDomain event, so > that will not change anything. My fix modifies the code path > taken by VM.suspend, but that should be safe because xapi > destroys properly the domain after suspending it. >=20 > (I think he meant _does_ exist in the third bullet). In his commit > message he said: >=20 > Teach xal what to do with dead domains which become alive again. >=20 > Needed to modify xenstored as well in order to trigger a > @introduceDomain event even if the introduce call tries to > introduce an already existing domain. That will kick-up xal in > case when resuming the domain. >=20 > I think possibly the right fix would have been to have xal kick-up > itself. That said spurious @introduceDomain watches are pretty harmless > (as he suggests) since they have no context, the recipient has to go and > check it's idea of the world vs the real state to know what happened an > the answer "nothing" is not a big deal... >=20 I think you're right that the fix should go into xal. Please don't commit t= his particular patch; we'll keep it in our patch queue until we can fix it = properly in xapi. Jon > Ian. >=20 >=20 >>=20 >> Jon >>=20 >> On 30 Sep 2011, at 08:49, Ian Campbell wrote: >>=20 >>> On Thu, 2011-09-29 at 22:17 +0100, Jon Ludlam wrote: >>>> Have xenstored trigger an @introduceDomain event even if the >>>> introduce call tries to introduce an already existing domain. >>>=20 >>> The C daemon doesn't appear to behave this way. It would be nice to >>> explain why this change is necessary.=20 >>>=20 >>>> Signed-off-by: Thomas Gazagnaire <thomas@ocamlpro.com> >>>> Acked-by: Jon Ludlam <jonathan.ludlam@eu.citrix.com> >>>>=20 >>>> diff -r 734cb0807357 -r b6022a18ebb0 tools/ocaml/xenstored/process.ml >>>> --- a/tools/ocaml/xenstored/process.ml >>>> +++ b/tools/ocaml/xenstored/process.ml >>>> @@ -168,9 +168,10 @@ >>>> | _ -> raise Invalid_Cmd_Args; >>>> in >>>> let dom =3D >>>> - if Domains.exist domains domid then >>>> + if Domains.exist domains domid then begin >>>> + Connections.fire_spec_watches cons "@introduceDomain"; >>>> Domains.find domains domid >>>> - else try >>>> + end else try >>>> let ndom =3D Xc.with_intf (fun xc -> >>>> Domains.create xc domains domid mfn port) in >>>> Connections.add_domain cons ndom; >>>>=20 >>>> _______________________________________________ >>>> Xen-devel mailing list >>>> Xen-devel@lists.xensource.com >>>> http://lists.xensource.com/xen-devel >>>=20 >>>=20 >>=20 >=20 >=20 _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel From xen-devel-bounces@lists.xensource.com Fri Sep 30 06:34:13 2011 Return-path: <xen-devel-bounces@lists.xensource.com> Envelope-to: www-data@lists.xensource.com Delivery-date: Fri, 30 Sep 2011 06:34:13 -0700 Received: from localhost ([127.0.0.1] helo=lists.colo.xensource.com) by lists.xensource.com with esmtp (Exim 4.43) id 1R9dEC-0008Vn-Ki; Fri, 30 Sep 2011 06:34:12 -0700 Received: from mail21.messagelabs.com ([85.158.143.35]) by lists.xensource.com with esmtp (Exim 4.43) id 1R9dDO-0008HG-OP for xen-devel@lists.xensource.com; Fri, 30 Sep 2011 06:33:23 -0700 X-Env-Sender: Ian.Campbell@eu.citrix.com X-Msg-Ref: server-4.tower-21.messagelabs.com!1317389561!62247725!1 X-Originating-IP: [66.165.176.63] X-StarScan-Version: 6.4.1; banners=-,-,- X-VirusChecked: Checked Received: (qmail 20193 invoked from network); 30 Sep 2011 13:32:42 -0000 Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63) by server-4.tower-21.messagelabs.com with RC4-SHA encrypted SMTP; 30 Sep 2011 13:32:42 -0000 X-IronPort-AV: E=Sophos;i="4.68,467,1312171200"; d="scan'208";a="165286951" Received: from ftlpmailmx01.citrite.net ([10.13.107.65]) by FTLPIPO02.CITRIX.COM with ESMTP/TLS/RC4-MD5; 30 Sep 2011 09:33:18 -0400 Received: from smtp01.ad.xensource.com (10.219.128.104) by smtprelay.citrix.com (10.13.107.65) with Microsoft SMTP Server id 8.3.137.0; Fri, 30 Sep 2011 09:33:17 -0400 Received: from localhost.localdomain (cosworth.uk.xensource.com [10.80.16.52]) by smtp01.ad.xensource.com (8.13.1/8.13.1) with ESMTP id p8UDXFZF029198; Fri, 30 Sep 2011 06:33:16 -0700 Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Message-ID: <patchbomb.1317389593@localhost.localdomain> User-Agent: Mercurial-patchbomb/1.6.4 Date: Fri, 30 Sep 2011 14:33:13 +0100 From: Ian Campbell <ian.campbell@citrix.com> To: xen-devel@lists.xensource.com Cc: Jim Fehlig <jfehlig@novell.com>, Mike McClurg <mike.mcclurg@citrix.com>, Dave Scott <Dave.Scott@eu.citrix.com>, Jonathan Ludlam <Jonathan.Ludlam@eu.citrix.com> Subject: [Xen-devel] [PATCH 00 of 23] libxl: rationalise libxl_device_* APIs X-BeenThere: xen-devel@lists.xensource.com X-Mailman-Version: 2.1.5 Precedence: list List-Id: Xen developer discussion <xen-devel.lists.xensource.com> List-Unsubscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe> List-Post: <mailto:xen-devel@lists.xensource.com> List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help> List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=subscribe> Sender: xen-devel-bounces@lists.xensource.com Errors-To: xen-devel-bounces@lists.xensource.com The following series overhauls the libxl_device_* APIs in an attempt to make them more consistent across the types of devices and move towards something we can support as a stable API longterm. This is broadly speaking the changes I discussed in [0] One of the early patches adds a big comment describing the API. It would be useful if this got a particularly close eye with a view to supporting it long term -- especially from actual and potential consumers of the API (of who I've CC a few who sprang to mind). Along the way I filed some rough edges of the internal implementation of this stuff but my primary concern is to make the public facing API one that we can commit to keeping stable. One aspect which is missing is the ability to do asynchronous add/remove etc. This requires the overhaul of the libxl event system which Ian Jackson described at [1]. I did bear this in mind so hopefully I have provided the majority of the necessary moving parts internally. [0] http://www.gossamer-threads.com/lists/xen/devel/204668 [1] http://www.gossamer-threads.com/lists/xen/devel/212580 & http://www.gossamer-threads.com/lists/xen/devel/212578 & http://www.gossamer-threads.com/lists/xen/devel/212579 & http://www.gossamer-threads.com/lists/xen/devel/212581 _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel From xen-devel-bounces@lists.xensource.com Fri Sep 30 06:35:52 2011 Return-path: <xen-devel-bounces@lists.xensource.com> Envelope-to: www-data@lists.xensource.com Delivery-date: Fri, 30 Sep 2011 06:35:52 -0700 Received: from localhost ([127.0.0.1] helo=lists.colo.xensource.com) by lists.xensource.com with esmtp (Exim 4.43) id 1R9dFm-0000SZ-RN; Fri, 30 Sep 2011 06:35:52 -0700 Received: from mail21.messagelabs.com ([85.158.143.35]) by lists.xensource.com with esmtp (Exim 4.43) id 1R9dDP-0008HH-Ez for xen-devel@lists.xensource.com; Fri, 30 Sep 2011 06:33:24 -0700 X-Env-Sender: Ian.Campbell@eu.citrix.com X-Msg-Ref: server-4.tower-21.messagelabs.com!1317389561!62247725!2 X-Originating-IP: [66.165.176.63] X-StarScan-Version: 6.4.1; banners=-,-,- X-VirusChecked: Checked Received: (qmail 20245 invoked from network); 30 Sep 2011 13:32:43 -0000 Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63) by server-4.tower-21.messagelabs.com with RC4-SHA encrypted SMTP; 30 Sep 2011 13:32:43 -0000 X-IronPort-AV: E=Sophos;i="4.68,467,1312171200"; d="scan'208";a="165286957" Received: from ftlpmailmx01.citrite.net ([10.13.107.65]) by FTLPIPO02.CITRIX.COM with ESMTP/TLS/RC4-MD5; 30 Sep 2011 09:33:19 -0400 Received: from smtp01.ad.xensource.com (10.219.128.104) by smtprelay.citrix.com (10.13.107.65) with Microsoft SMTP Server id 8.3.137.0; Fri, 30 Sep 2011 09:33:18 -0400 Received: from localhost.localdomain (cosworth.uk.xensource.com [10.80.16.52]) by smtp01.ad.xensource.com (8.13.1/8.13.1) with ESMTP id p8UDXFZG029198; Fri, 30 Sep 2011 06:33:17 -0700 Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Mercurial-Node: 42dee7039d911db8b82e9f857fcad92a689d0318 Message-ID: <42dee7039d911db8b82e.1317389594@localhost.localdomain> In-Reply-To: <patchbomb.1317389593@localhost.localdomain> References: <patchbomb.1317389593@localhost.localdomain> User-Agent: Mercurial-patchbomb/1.6.4 Date: Fri, 30 Sep 2011 14:33:14 +0100 From: Ian Campbell <ian.campbell@citrix.com> To: xen-devel@lists.xensource.com Cc: Jim Fehlig <jfehlig@novell.com>, Mike McClurg <mike.mcclurg@citrix.com>, Dave Scott <Dave.Scott@eu.citrix.com>, Jonathan Ludlam <Jonathan.Ludlam@eu.citrix.com> Subject: [Xen-devel] [PATCH 01 of 23] libxl: remove hard tabs from non-generated *.[ch] X-BeenThere: xen-devel@lists.xensource.com X-Mailman-Version: 2.1.5 Precedence: list List-Id: Xen developer discussion <xen-devel.lists.xensource.com> List-Unsubscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe> List-Post: <mailto:xen-devel@lists.xensource.com> List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help> List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=subscribe> Sender: xen-devel-bounces@lists.xensource.com Errors-To: xen-devel-bounces@lists.xensource.com # HG changeset patch # User Ian Campbell <ian.campbell@citrix.com> # Date 1317389247 -3600 # Node ID 42dee7039d911db8b82e9f857fcad92a689d0318 # Parent de01831eb2a92600dac56c9791dfaa9445777f03 libxl: remove hard tabs from non-generated *.[ch] The vast majority of this code uses four spaces and the tabs make my subsequent patches look funny... Signed-off-by: Ian Campbell <ian.campbell@citrix.com> diff -r de01831eb2a9 -r 42dee7039d91 tools/libxl/libxl.c --- a/tools/libxl/libxl.c Fri Sep 30 14:27:27 2011 +0100 +++ b/tools/libxl/libxl.c Fri Sep 30 14:27:27 2011 +0100 @@ -696,13 +696,13 @@ int libxl_event_get_disk_eject_info(libx sscanf(backend, "/local/domain/%d/backend/%" TOSTRING(BACKEND_STRING_SIZE) "[a-z]/%*d/%*d", &disk->backend_domid, backend_type); - if (!strcmp(backend_type, "tap") || !strcmp(backend_type, "vbd")) { - disk->backend = LIBXL_DISK_BACKEND_TAP; - } else if (!strcmp(backend_type, "qdisk")) { - disk->backend = LIBXL_DISK_BACKEND_QDISK; - } else { - disk->backend = LIBXL_DISK_BACKEND_UNKNOWN; - } + if (!strcmp(backend_type, "tap") || !strcmp(backend_type, "vbd")) { + disk->backend = LIBXL_DISK_BACKEND_TAP; + } else if (!strcmp(backend_type, "qdisk")) { + disk->backend = LIBXL_DISK_BACKEND_QDISK; + } else { + disk->backend = LIBXL_DISK_BACKEND_UNKNOWN; + } disk->pdev_path = strdup(""); disk->format = LIBXL_DISK_FORMAT_EMPTY; diff -r de01831eb2a9 -r 42dee7039d91 tools/libxl/libxl.h --- a/tools/libxl/libxl.h Fri Sep 30 14:27:27 2011 +0100 +++ b/tools/libxl/libxl.h Fri Sep 30 14:27:27 2011 +0100 @@ -420,7 +420,7 @@ int libxl_cpuid_parse_config_xend(libxl_ const char* str); void libxl_cpuid_apply_policy(libxl_ctx *ctx, uint32_t domid); void libxl_cpuid_set(libxl_ctx *ctx, uint32_t domid, - libxl_cpuid_policy_list cpuid); + libxl_cpuid_policy_list cpuid); /* * Functions for allowing users of libxl to store private data diff -r de01831eb2a9 -r 42dee7039d91 tools/libxl/libxl_bootloader.c --- a/tools/libxl/libxl_bootloader.c Fri Sep 30 14:27:27 2011 +0100 +++ b/tools/libxl/libxl_bootloader.c Fri Sep 30 14:27:27 2011 +0100 @@ -81,14 +81,14 @@ static int open_xenconsoled_pty(int *mas ret = openpty(master, slave, NULL, NULL, NULL); if (ret < 0) - return -1; + return -1; ret = ttyname_r(*slave, slave_path, slave_path_len); if (ret == -1) { - close(*master); - close(*slave); - *master = *slave = -1; - return -1; + close(*master); + close(*slave); + *master = *slave = -1; + return -1; } /* diff -r de01831eb2a9 -r 42dee7039d91 tools/libxl/libxl_cpuid.c --- a/tools/libxl/libxl_cpuid.c Fri Sep 30 14:27:27 2011 +0100 +++ b/tools/libxl/libxl_cpuid.c Fri Sep 30 14:27:27 2011 +0100 @@ -317,7 +317,7 @@ void libxl_cpuid_apply_policy(libxl_ctx } void libxl_cpuid_set(libxl_ctx *ctx, uint32_t domid, - libxl_cpuid_policy_list cpuid) + libxl_cpuid_policy_list cpuid) { int i; char *cpuid_res[4]; diff -r de01831eb2a9 -r 42dee7039d91 tools/libxl/libxl_internal.c --- a/tools/libxl/libxl_internal.c Fri Sep 30 14:27:27 2011 +0100 +++ b/tools/libxl/libxl_internal.c Fri Sep 30 14:27:27 2011 +0100 @@ -228,53 +228,53 @@ char *libxl__abs_path(libxl__gc *gc, con int libxl__file_reference_map(libxl_file_reference *f) { - struct stat st_buf; - int ret, fd; - void *data; + struct stat st_buf; + int ret, fd; + void *data; - if (f->mapped) - return 0; + if (f->mapped) + return 0; - fd = open(f->path, O_RDONLY); - if (f < 0) - return ERROR_FAIL; + fd = open(f->path, O_RDONLY); + if (f < 0) + return ERROR_FAIL; - ret = fstat(fd, &st_buf); - if (ret < 0) - goto out; + ret = fstat(fd, &st_buf); + if (ret < 0) + goto out; - ret = -1; - data = mmap(NULL, st_buf.st_size, PROT_READ, MAP_PRIVATE, fd, 0); - if (data == NULL) - goto out; + ret = -1; + data = mmap(NULL, st_buf.st_size, PROT_READ, MAP_PRIVATE, fd, 0); + if (data == NULL) + goto out; - f->mapped = 1; - f->data = data; - f->size = st_buf.st_size; + f->mapped = 1; + f->data = data; + f->size = st_buf.st_size; - ret = 0; + ret = 0; out: - close(fd); + close(fd); - return ret == 0 ? 0 : ERROR_FAIL; + return ret == 0 ? 0 : ERROR_FAIL; } int libxl__file_reference_unmap(libxl_file_reference *f) { - int ret; + int ret; - if (!f->mapped) - return 0; + if (!f->mapped) + return 0; - ret = munmap(f->data, f->size); - if (ret == 0) { - f->mapped = 0; - f->data = NULL; - f->size = 0; - return 0; - } + ret = munmap(f->data, f->size); + if (ret == 0) { + f->mapped = 0; + f->data = NULL; + f->size = 0; + return 0; + } - return ERROR_FAIL; + return ERROR_FAIL; } _hidden int libxl__parse_mac(const char *s, libxl_mac mac) diff -r de01831eb2a9 -r 42dee7039d91 tools/libxl/libxl_nocpuid.c --- a/tools/libxl/libxl_nocpuid.c Fri Sep 30 14:27:27 2011 +0100 +++ b/tools/libxl/libxl_nocpuid.c Fri Sep 30 14:27:27 2011 +0100 @@ -32,6 +32,6 @@ void libxl_cpuid_apply_policy(libxl_ctx } void libxl_cpuid_set(libxl_ctx *ctx, uint32_t domid, - libxl_cpuid_policy_list cpuid) + libxl_cpuid_policy_list cpuid) { } diff -r de01831eb2a9 -r 42dee7039d91 tools/libxl/libxl_pci.c --- a/tools/libxl/libxl_pci.c Fri Sep 30 14:27:27 2011 +0100 +++ b/tools/libxl/libxl_pci.c Fri Sep 30 14:27:27 2011 +0100 @@ -1114,7 +1114,7 @@ static int e820_sanitize(libxl_ctx *ctx, if ((src[i].type == E820_RAM) || (src[i].type == E820_UNUSABLE) || (src[i].type == 0)) - continue; + continue; start = src[i].addr < start ? src[i].addr : start; last = src[i].addr + src[i].size > last ? @@ -1159,14 +1159,14 @@ static int e820_sanitize(libxl_ctx *ctx, * to E820_UNUSED. We also need to move some of the E820_RAM regions if * the overlap with ram_end. */ for (i = 0; i < nr; i++) { - uint64_t end = src[i].addr + src[i].size; + uint64_t end = src[i].addr + src[i].size; - /* We don't care about E820_UNUSABLE, but we need to + /* We don't care about E820_UNUSABLE, but we need to * change the type to zero b/c the loop after this * sticks E820_UNUSABLE on the guest's E820 but ignores * the ones with type zero. */ if ((src[i].type == E820_UNUSABLE) || - /* Any region that is within the "RAM region" can + /* Any region that is within the "RAM region" can * be safely ditched. */ (end < ram_end)) { src[i].type = 0; @@ -1174,15 +1174,15 @@ static int e820_sanitize(libxl_ctx *ctx, } /* Look only at RAM regions. */ - if (src[i].type != E820_RAM) + if (src[i].type != E820_RAM) continue; /* We only care about RAM regions below 4GB. */ if (src[i].addr >= (1ULL<<32)) continue; - /* E820_RAM overlaps with our RAM region. Move it */ - if (src[i].addr < ram_end) { + /* E820_RAM overlaps with our RAM region. Move it */ + if (src[i].addr < ram_end) { uint64_t delta; src[i].type = E820_UNUSABLE; @@ -1236,8 +1236,8 @@ static int e820_sanitize(libxl_ctx *ctx, /* Almost done: copy them over, ignoring the undesireable ones */ for (i = 0; i < nr; i++) { if ((src[i].type == E820_RAM) || - (src[i].type == 0)) - continue; + (src[i].type == 0)) + continue; e820[idx].type = src[i].type; e820[idx].addr = src[i].addr; diff -r de01831eb2a9 -r 42dee7039d91 tools/libxl/libxl_utils.c --- a/tools/libxl/libxl_utils.c Fri Sep 30 14:27:27 2011 +0100 +++ b/tools/libxl/libxl_utils.c Fri Sep 30 14:27:27 2011 +0100 @@ -457,7 +457,7 @@ int libxl_mac_to_device_nic(libxl_ctx *c rc = libxl__parse_mac(mac, mac_n); if (rc) - return rc; + return rc; nics = libxl_list_nics(ctx, domid, &nb); if (!nics) @@ -509,7 +509,7 @@ int libxl_devid_to_device_nic(libxl_ctx val = libxl__xs_read(&gc, XBT_NULL, libxl__sprintf(&gc, "%s/mac", nic_path_fe)); rc = libxl__parse_mac(val, nic->mac); if (rc) - goto out; + goto out; nic->script = xs_read(ctx->xsh, XBT_NULL, libxl__sprintf(&gc, "%s/script", nic_path_be), NULL); rc = 0; diff -r de01831eb2a9 -r 42dee7039d91 tools/libxl/libxlutil.h --- a/tools/libxl/libxlutil.h Fri Sep 30 14:27:27 2011 +0100 +++ b/tools/libxl/libxlutil.h Fri Sep 30 14:27:27 2011 +0100 @@ -64,7 +64,7 @@ const char *xlu_cfg_get_listitem(const X */ int xlu_disk_parse(XLU_Config *cfg, int nspecs, const char *const *specs, - libxl_device_disk *disk); + libxl_device_disk *disk); /* disk must have been initialised. * * On error, returns errno value. Bad strings cause EINVAL and diff -r de01831eb2a9 -r 42dee7039d91 tools/libxl/xl_cmdimpl.c --- a/tools/libxl/xl_cmdimpl.c Fri Sep 30 14:27:27 2011 +0100 +++ b/tools/libxl/xl_cmdimpl.c Fri Sep 30 14:27:27 2011 +0100 @@ -557,15 +557,15 @@ static void parse_disk_config_multistrin memset(disk, 0, sizeof(*disk)); if (!*config) { - *config = xlu_cfg_init(stderr, "command line"); - if (!*config) { perror("xlu_cfg_init"); exit(-1); } + *config = xlu_cfg_init(stderr, "command line"); + if (!*config) { perror("xlu_cfg_init"); exit(-1); } } e = xlu_disk_parse(*config, nspecs, specs, disk); if (e == EINVAL) exit(-1); if (e) { - fprintf(stderr,"xlu_disk_parse failed: %s\n",strerror(errno)); - exit(-1); + fprintf(stderr,"xlu_disk_parse failed: %s\n",strerror(errno)); + exit(-1); } } _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel From xen-devel-bounces@lists.xensource.com Fri Sep 30 06:37:36 2011 Return-path: <xen-devel-bounces@lists.xensource.com> Envelope-to: www-data@lists.xensource.com Delivery-date: Fri, 30 Sep 2011 06:37:36 -0700 Received: from localhost ([127.0.0.1] helo=lists.colo.xensource.com) by lists.xensource.com with esmtp (Exim 4.43) id 1R9dHU-0000yj-0h; Fri, 30 Sep 2011 06:37:36 -0700 Received: from mail21.messagelabs.com ([85.158.143.35]) by lists.xensource.com with esmtp (Exim 4.43) id 1R9dDS-0008HT-P1 for xen-devel@lists.xensource.com; Fri, 30 Sep 2011 06:33:28 -0700 X-Env-Sender: Ian.Campbell@eu.citrix.com X-Msg-Ref: server-4.tower-21.messagelabs.com!1317389561!62247725!3 X-Originating-IP: [66.165.176.63] X-StarScan-Version: 6.4.1; banners=-,-,- X-VirusChecked: Checked Received: (qmail 20412 invoked from network); 30 Sep 2011 13:32:46 -0000 Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63) by server-4.tower-21.messagelabs.com with RC4-SHA encrypted SMTP; 30 Sep 2011 13:32:46 -0000 X-IronPort-AV: E=Sophos;i="4.68,467,1312171200"; d="scan'208";a="165286964" Received: from ftlpmailmx01.citrite.net ([10.13.107.65]) by FTLPIPO02.CITRIX.COM with ESMTP/TLS/RC4-MD5; 30 Sep 2011 09:33:23 -0400 Received: from smtp01.ad.xensource.com (10.219.128.104) by smtprelay.citrix.com (10.13.107.65) with Microsoft SMTP Server id 8.3.137.0; Fri, 30 Sep 2011 09:33:22 -0400 Received: from localhost.localdomain (cosworth.uk.xensource.com [10.80.16.52]) by smtp01.ad.xensource.com (8.13.1/8.13.1) with ESMTP id p8UDXFZJ029198; Fri, 30 Sep 2011 06:33:21 -0700 Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Mercurial-Node: 8645a81f04282ca4e3c51141b1c177ad9a8d5943 Message-ID: <8645a81f04282ca4e3c5.1317389597@localhost.localdomain> In-Reply-To: <patchbomb.1317389593@localhost.localdomain> References: <patchbomb.1317389593@localhost.localdomain> User-Agent: Mercurial-patchbomb/1.6.4 Date: Fri, 30 Sep 2011 14:33:17 +0100 From: Ian Campbell <ian.campbell@citrix.com> To: xen-devel@lists.xensource.com Cc: Jim Fehlig <jfehlig@novell.com>, Mike McClurg <mike.mcclurg@citrix.com>, Dave Scott <Dave.Scott@eu.citrix.com>, Jonathan Ludlam <Jonathan.Ludlam@eu.citrix.com> Subject: [Xen-devel] [PATCH 04 of 23] libxl: refactor code to construct disk from xenstore backend X-BeenThere: xen-devel@lists.xensource.com X-Mailman-Version: 2.1.5 Precedence: list List-Id: Xen developer discussion <xen-devel.lists.xensource.com> List-Unsubscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe> List-Post: <mailto:xen-devel@lists.xensource.com> List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help> List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=subscribe> Sender: xen-devel-bounces@lists.xensource.com Errors-To: xen-devel-bounces@lists.xensource.com # HG changeset patch # User Ian Campbell <ian.campbell@citrix.com> # Date 1317389247 -3600 # Node ID 8645a81f04282ca4e3c51141b1c177ad9a8d5943 # Parent 9fdae058b42c9a8981599d96e1de3131997e7b64 libxl: refactor code to construct disk from xenstore backend Temporarily retain unsafe behaviour of reading f.e. directory. Signed-off-by: Ian Campbell <ian.campbell@citrix.com> diff -r 9fdae058b42c -r 8645a81f0428 tools/libxl/libxl.c --- a/tools/libxl/libxl.c Fri Sep 30 14:27:27 2011 +0100 +++ b/tools/libxl/libxl.c Fri Sep 30 14:27:27 2011 +0100 @@ -1502,24 +1502,69 @@ int libxl_device_vkb_hard_shutdown(libxl return ERROR_NI; } +static void libxl__device_disk_from_xs_be(libxl__gc *gc, + const char *be_path, + libxl_device_disk *disk) +{ + libxl_ctx *ctx = libxl__gc_owner(gc); + unsigned int len; + char *tmp; + const char *fe_path; /* XXX unsafe */ + + memset(disk, 0, sizeof(*disk)); + + tmp = xs_read(ctx->xsh, XBT_NULL, + libxl__sprintf(gc, "%s/params", be_path), &len); + if (tmp && strchr(tmp, ':')) { + disk->pdev_path = strdup(strchr(tmp, ':') + 1); + free(tmp); + } else { + disk->pdev_path = tmp; + } + libxl_string_to_backend(ctx, + libxl__xs_read(gc, XBT_NULL, + libxl__sprintf(gc, "%s/type", be_path)), + &(disk->backend)); + disk->vdev = xs_read(ctx->xsh, XBT_NULL, + libxl__sprintf(gc, "%s/dev", be_path), &len); + tmp = libxl__xs_read(gc, XBT_NULL, libxl__sprintf + (gc, "%s/removable", be_path)); + + if (tmp) + disk->removable = atoi(tmp); + else + disk->removable = 0; + + tmp = libxl__xs_read(gc, XBT_NULL, libxl__sprintf(gc, "%s/mode", be_path)); + if (!strcmp(tmp, "w")) + disk->readwrite = 1; + else + disk->readwrite = 0; + + fe_path = libxl__xs_read(gc, XBT_NULL, + libxl__sprintf(gc, "%s/frontend", be_path)); + tmp = libxl__xs_read(gc, XBT_NULL, + libxl__sprintf(gc, "%s/device-type", fe_path)); + disk->is_cdrom = !strcmp(tmp, "cdrom"); + + disk->format = LIBXL_DISK_FORMAT_UNKNOWN; +} + static int libxl__append_disk_list_of_type(libxl__gc *gc, uint32_t domid, const char *type, libxl_device_disk **disks, int *ndisks) { - libxl_ctx *ctx = libxl__gc_owner(gc); char *be_path = NULL; char **dir = NULL; - unsigned int n = 0, len = 0; + unsigned int n = 0; libxl_device_disk *pdisk = NULL, *pdisk_end = NULL; - char *physpath_tmp = NULL; be_path = libxl__sprintf(gc, "%s/backend/%s/%d", libxl__xs_get_dompath(gc, 0), type, domid); dir = libxl__xs_directory(gc, XBT_NULL, be_path, &n); if (dir) { - char *removable; libxl_device_disk *tmp; tmp = realloc(*disks, sizeof (libxl_device_disk) * (*ndisks + n)); if (tmp == NULL) @@ -1529,32 +1574,10 @@ static int libxl__append_disk_list_of_ty *ndisks += n; pdisk_end = *disks + *ndisks; for (; pdisk < pdisk_end; pdisk++, dir++) { - memset(pdisk, 0, sizeof(*pdisk)); + const char *p; + p = libxl__sprintf(gc, "%s/%s", be_path, *dir); + libxl__device_disk_from_xs_be(gc, p, pdisk); pdisk->backend_domid = 0; - physpath_tmp = xs_read(ctx->xsh, XBT_NULL, libxl__sprintf(gc, "%s/%s/params", be_path, *dir), &len); - if (physpath_tmp && strchr(physpath_tmp, ':')) { - pdisk->pdev_path = strdup(strchr(physpath_tmp, ':') + 1); - free(physpath_tmp); - } else { - pdisk->pdev_path = physpath_tmp; - } - libxl_string_to_backend(ctx, libxl__xs_read(gc, XBT_NULL, - libxl__sprintf(gc, "%s/%s/type", be_path, *dir)), - &(pdisk->backend)); - pdisk->vdev = xs_read(ctx->xsh, XBT_NULL, libxl__sprintf(gc, "%s/%s/dev", be_path, *dir), &len); - removable = libxl__xs_read(gc, XBT_NULL, libxl__sprintf - (gc, "%s/%s/removable", be_path, *dir)); - if (removable) - pdisk->removable = atoi(removable); - else - pdisk->removable = 0; - if (!strcmp(libxl__xs_read(gc, XBT_NULL, libxl__sprintf(gc, "%s/%s/mode", be_path, *dir)), "w")) - pdisk->readwrite = 1; - else - pdisk->readwrite = 0; - type = libxl__xs_read(gc, XBT_NULL, libxl__sprintf(gc, "%s/device-type", libxl__xs_read(gc, XBT_NULL, libxl__sprintf(gc, "%s/%s/frontend", be_path, *dir)))); - pdisk->is_cdrom = !strcmp(type, "cdrom"); - pdisk->format = LIBXL_DISK_FORMAT_UNKNOWN; } } return 0; _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel From xen-devel-bounces@lists.xensource.com Fri Sep 30 06:38:40 2011 Return-path: <xen-devel-bounces@lists.xensource.com> Envelope-to: www-data@lists.xensource.com Delivery-date: Fri, 30 Sep 2011 06:38:40 -0700 Received: from localhost ([127.0.0.1] helo=lists.colo.xensource.com) by lists.xensource.com with esmtp (Exim 4.43) id 1R9dIW-0001Mv-Cb; Fri, 30 Sep 2011 06:38:40 -0700 Received: from mail21.messagelabs.com ([85.158.143.35]) by lists.xensource.com with esmtp (Exim 4.43) id 1R9dDV-0008IA-JX for xen-devel@lists.xensource.com; Fri, 30 Sep 2011 06:33:30 -0700 X-Env-Sender: Ian.Campbell@eu.citrix.com X-Msg-Ref: server-4.tower-21.messagelabs.com!1317389561!62247725!4 X-Originating-IP: [66.165.176.63] X-StarScan-Version: 6.4.1; banners=-,-,- X-VirusChecked: Checked Received: (qmail 20554 invoked from network); 30 Sep 2011 13:32:49 -0000 Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63) by server-4.tower-21.messagelabs.com with RC4-SHA encrypted SMTP; 30 Sep 2011 13:32:49 -0000 X-IronPort-AV: E=Sophos;i="4.68,467,1312171200"; d="scan'208";a="165286968" Received: from ftlpmailmx01.citrite.net ([10.13.107.65]) by FTLPIPO02.CITRIX.COM with ESMTP/TLS/RC4-MD5; 30 Sep 2011 09:33:25 -0400 Received: from smtp01.ad.xensource.com (10.219.128.104) by smtprelay.citrix.com (10.13.107.65) with Microsoft SMTP Server id 8.3.137.0; Fri, 30 Sep 2011 09:33:25 -0400 Received: from localhost.localdomain (cosworth.uk.xensource.com [10.80.16.52]) by smtp01.ad.xensource.com (8.13.1/8.13.1) with ESMTP id p8UDXFZL029198; Fri, 30 Sep 2011 06:33:24 -0700 Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Mercurial-Node: cafd8b3f9e0c8bbf5c30cfcd512c1486661ca4d9 Message-ID: <cafd8b3f9e0c8bbf5c30.1317389599@localhost.localdomain> In-Reply-To: <patchbomb.1317389593@localhost.localdomain> References: <patchbomb.1317389593@localhost.localdomain> User-Agent: Mercurial-patchbomb/1.6.4 Date: Fri, 30 Sep 2011 14:33:19 +0100 From: Ian Campbell <ian.campbell@citrix.com> To: xen-devel@lists.xensource.com Cc: Jim Fehlig <jfehlig@novell.com>, Mike McClurg <mike.mcclurg@citrix.com>, Dave Scott <Dave.Scott@eu.citrix.com>, Jonathan Ludlam <Jonathan.Ludlam@eu.citrix.com> Subject: [Xen-devel] [PATCH 06 of 23] libxl: update nic list API to use common device API style X-BeenThere: xen-devel@lists.xensource.com X-Mailman-Version: 2.1.5 Precedence: list List-Id: Xen developer discussion <xen-devel.lists.xensource.com> List-Unsubscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe> List-Post: <mailto:xen-devel@lists.xensource.com> List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help> List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=subscribe> Sender: xen-devel-bounces@lists.xensource.com Errors-To: xen-devel-bounces@lists.xensource.com # HG changeset patch # User Ian Campbell <ian.campbell@citrix.com> # Date 1317389247 -3600 # Node ID cafd8b3f9e0c8bbf5c30cfcd512c1486661ca4d9 # Parent 4e640cbed20e8ef533f8eb27a82dcdac2be2e8ab libxl: update nic list API to use common device API style libxl_device_nic_list returns an array of libxl_device_nic and libxl_device_nic_getinfo retrieves further information. Signed-off-by: Ian Campbell <ian.campbell@citrix.com> diff -r 4e640cbed20e -r cafd8b3f9e0c tools/libxl/libxl.c --- a/tools/libxl/libxl.c Fri Sep 30 14:27:27 2011 +0100 +++ b/tools/libxl/libxl.c Fri Sep 30 14:27:27 2011 +0100 @@ -1288,60 +1288,138 @@ int libxl_device_nic_del(libxl_ctx *ctx, return rc; } -libxl_nicinfo *libxl_list_nics(libxl_ctx *ctx, uint32_t domid, unsigned int *nb) +static void libxl__device_nic_from_xs_be(libxl__gc *gc, + const char *be_path, + libxl_device_nic *nic) +{ + libxl_ctx *ctx = libxl__gc_owner(gc); + unsigned int len; + char *tmp; + int rc; + + memset(nic, 0, sizeof(*nic)); + + tmp = xs_read(ctx->xsh, XBT_NULL, + libxl__sprintf(gc, "%s/handle", be_path), &len); + if ( tmp ) + nic->devid = atoi(tmp); + else + nic->devid = 0; + + /* nic->mtu = */ + + tmp = xs_read(ctx->xsh, XBT_NULL, + libxl__sprintf(gc, "%s/mac", be_path), &len); + rc = libxl__parse_mac(tmp, nic->mac); + if (rc) + memset(nic->mac, 0, sizeof(nic->mac)); + + nic->ip = xs_read(ctx->xsh, XBT_NULL, + libxl__sprintf(gc, "%s/ip", be_path), &len); + + nic->bridge = xs_read(ctx->xsh, XBT_NULL, + libxl__sprintf(gc, "%s/bridge", be_path), &len); + + nic->script = xs_read(ctx->xsh, XBT_NULL, + libxl__sprintf(gc, "%s/script", be_path), &len); + + /* XXX ioemu nics are not in xenstore at all? */ + nic->nictype = LIBXL_NIC_TYPE_VIF; + nic->model = NULL; /* XXX Only for TYPE_IOEMU */ + nic->ifname = NULL; /* XXX Only for TYPE_IOEMU */ +} + +static int libxl__append_nic_list_of_type(libxl__gc *gc, + uint32_t domid, + const char *type, + libxl_device_nic **nics, + int *nnics) +{ + char *be_path = NULL; + char **dir = NULL; + unsigned int n = 0; + libxl_device_nic *pnic = NULL, *pnic_end = NULL; + + be_path = libxl__sprintf(gc, "%s/backend/%s/%d", + libxl__xs_get_dompath(gc, 0), type, domid); + dir = libxl__xs_directory(gc, XBT_NULL, be_path, &n); + if (dir) { + libxl_device_nic *tmp; + tmp = realloc(*nics, sizeof (libxl_device_nic) * (*nnics + n)); + if (tmp == NULL) + return ERROR_NOMEM; + *nics = tmp; + pnic = *nics + *nnics; + *nnics += n; + pnic_end = *nics + *nnics; + for (; pnic < pnic_end; pnic++, dir++) { + const char *p; + p = libxl__sprintf(gc, "%s/%s", be_path, *dir); + libxl__device_nic_from_xs_be(gc, p, pnic); + pnic->backend_domid = 0; + } + } + return 0; +} + +libxl_device_nic *libxl_device_nic_list(libxl_ctx *ctx, uint32_t domid, int *num) { libxl__gc gc = LIBXL_INIT_GC(ctx); - char *dompath, *nic_path_fe; - char **l, **list; - char *val, *tok; - unsigned int nb_nics, i; - libxl_nicinfo *res, *nics; + libxl_device_nic *nics = NULL; + int rc; + + *num = 0; + + rc = libxl__append_nic_list_of_type(&gc, domid, "vif", &nics, num); + if (rc) goto out_err; + + libxl__free_all(&gc); + return nics; + +out_err: + LIBXL__LOG(ctx, LIBXL__LOG_ERROR, "Unable to list nics"); + while (*num) { + (*num)--; + libxl_device_nic_destroy(&nics[*num]); + } + free(nics); + return NULL; +} + +int libxl_device_nic_getinfo(libxl_ctx *ctx, uint32_t domid, + libxl_device_nic *nic, libxl_nicinfo *nicinfo) +{ + libxl__gc gc = LIBXL_INIT_GC(ctx); + char *dompath, *nicpath; + char *val; dompath = libxl__xs_get_dompath(&gc, domid); - if (!dompath) - goto err; - list = l = libxl__xs_directory(&gc, XBT_NULL, - libxl__sprintf(&gc, "%s/device/vif", dompath), &nb_nics); - if (!l) - goto err; - nics = res = calloc(nb_nics, sizeof (libxl_nicinfo)); - if (!res) - goto err; - for (*nb = nb_nics; nb_nics > 0; --nb_nics, ++l, ++nics) { - nic_path_fe = libxl__sprintf(&gc, "%s/device/vif/%s", dompath, *l); - - nics->backend = xs_read(ctx->xsh, XBT_NULL, - libxl__sprintf(&gc, "%s/backend", nic_path_fe), NULL); - val = libxl__xs_read(&gc, XBT_NULL, libxl__sprintf(&gc, "%s/backend-id", nic_path_fe)); - nics->backend_id = val ? strtoul(val, NULL, 10) : -1; - - nics->devid = strtoul(*l, NULL, 10); - val = libxl__xs_read(&gc, XBT_NULL, libxl__sprintf(&gc, "%s/state", nic_path_fe)); - nics->state = val ? strtoul(val, NULL, 10) : -1; - val = libxl__xs_read(&gc, XBT_NULL, libxl__sprintf(&gc, "%s/mac", nic_path_fe)); - for (i = 0, tok = strtok(val, ":"); tok && (i < 6); - ++i, tok = strtok(NULL, ":")) { - nics->mac[i] = strtoul(tok, NULL, 16); - } - val = libxl__xs_read(&gc, XBT_NULL, libxl__sprintf(&gc, "%s/event-channel", nic_path_fe)); - nics->evtch = val ? strtol(val, NULL, 10) : -1; - val = libxl__xs_read(&gc, XBT_NULL, libxl__sprintf(&gc, "%s/tx-ring-ref", nic_path_fe)); - nics->rref_tx = val ? strtol(val, NULL, 10) : -1; - val = libxl__xs_read(&gc, XBT_NULL, libxl__sprintf(&gc, "%s/rx-ring-ref", nic_path_fe)); - nics->rref_rx = val ? strtol(val, NULL, 10) : -1; - nics->frontend = xs_read(ctx->xsh, XBT_NULL, - libxl__sprintf(&gc, "%s/frontend", nics->backend), NULL); - val = libxl__xs_read(&gc, XBT_NULL, libxl__sprintf(&gc, "%s/frontend-id", nics->backend)); - nics->frontend_id = val ? strtoul(val, NULL, 10) : -1; - nics->script = xs_read(ctx->xsh, XBT_NULL, - libxl__sprintf(&gc, "%s/script", nics->backend), NULL); + nicinfo->devid = nic->devid; + + nicpath = libxl__sprintf(&gc, "%s/device/vif/%d", dompath, nicinfo->devid); + nicinfo->backend = xs_read(ctx->xsh, XBT_NULL, + libxl__sprintf(&gc, "%s/backend", nicpath), NULL); + if (!nicinfo->backend) { + libxl__free_all(&gc); + return ERROR_FAIL; } + val = libxl__xs_read(&gc, XBT_NULL, libxl__sprintf(&gc, "%s/backend-id", nicpath)); + nicinfo->backend_id = val ? strtoul(val, NULL, 10) : -1; + val = libxl__xs_read(&gc, XBT_NULL, libxl__sprintf(&gc, "%s/state", nicpath)); + nicinfo->state = val ? strtoul(val, NULL, 10) : -1; + val = libxl__xs_read(&gc, XBT_NULL, libxl__sprintf(&gc, "%s/event-channel", nicpath)); + nicinfo->evtch = val ? strtoul(val, NULL, 10) : -1; + val = libxl__xs_read(&gc, XBT_NULL, libxl__sprintf(&gc, "%s/tx-ring-ref", nicpath)); + nicinfo->rref_tx = val ? strtoul(val, NULL, 10) : -1; + val = libxl__xs_read(&gc, XBT_NULL, libxl__sprintf(&gc, "%s/rx-ring-ref", nicpath)); + nicinfo->rref_rx = val ? strtoul(val, NULL, 10) : -1; + nicinfo->frontend = xs_read(ctx->xsh, XBT_NULL, + libxl__sprintf(&gc, "%s/frontend", nicinfo->backend), NULL); + val = libxl__xs_read(&gc, XBT_NULL, libxl__sprintf(&gc, "%s/frontend-id", nicinfo->backend)); + nicinfo->frontend_id = val ? strtoul(val, NULL, 10) : -1; libxl__free_all(&gc); - return res; -err: - libxl__free_all(&gc); - return NULL; + return 0; } /******************************************************************************/ diff -r 4e640cbed20e -r cafd8b3f9e0c tools/libxl/libxl.h --- a/tools/libxl/libxl.h Fri Sep 30 14:27:27 2011 +0100 +++ b/tools/libxl/libxl.h Fri Sep 30 14:27:27 2011 +0100 @@ -467,7 +467,9 @@ int libxl_device_disk_local_detach(libxl int libxl_device_nic_init(libxl_device_nic *nic, int dev_num); int libxl_device_nic_add(libxl_ctx *ctx, uint32_t domid, libxl_device_nic *nic); int libxl_device_nic_del(libxl_ctx *ctx, uint32_t domid, libxl_device_nic *nic, int wait); -libxl_nicinfo *libxl_list_nics(libxl_ctx *ctx, uint32_t domid, unsigned int *nb); +libxl_device_nic *libxl_device_nic_list(libxl_ctx *ctx, uint32_t domid, int *num); +int libxl_device_nic_getinfo(libxl_ctx *ctx, uint32_t domid, + libxl_device_nic *nic, libxl_nicinfo *nicinfo); int libxl_device_console_add(libxl_ctx *ctx, uint32_t domid, libxl_device_console *console); diff -r 4e640cbed20e -r cafd8b3f9e0c tools/libxl/libxl_types.idl --- a/tools/libxl/libxl_types.idl Fri Sep 30 14:27:27 2011 +0100 +++ b/tools/libxl/libxl_types.idl Fri Sep 30 14:27:27 2011 +0100 @@ -330,8 +330,6 @@ libxl_nicinfo = Struct("nicinfo", [ ("frontend_id", uint32), ("devid", integer), ("state", integer), - ("script", string), - ("mac", libxl_mac), ("evtch", integer), ("rref_tx", integer), ("rref_rx", integer), diff -r 4e640cbed20e -r cafd8b3f9e0c tools/libxl/libxl_utils.c --- a/tools/libxl/libxl_utils.c Fri Sep 30 14:27:27 2011 +0100 +++ b/tools/libxl/libxl_utils.c Fri Sep 30 14:27:27 2011 +0100 @@ -451,15 +451,15 @@ int libxl_pipe(libxl_ctx *ctx, int pipes int libxl_mac_to_device_nic(libxl_ctx *ctx, uint32_t domid, const char *mac, libxl_device_nic *nic) { - libxl_nicinfo *nics; - unsigned int nb, rc, i; + libxl_device_nic *nics; + int nb, rc, i; libxl_mac mac_n; rc = libxl__parse_mac(mac, mac_n); if (rc) return rc; - nics = libxl_list_nics(ctx, domid, &nb); + nics = libxl_device_nic_list(ctx, domid, &nb); if (!nics) return ERROR_FAIL; @@ -468,17 +468,17 @@ int libxl_mac_to_device_nic(libxl_ctx *c rc = ERROR_INVAL; for (i = 0; i < nb; ++i) { if (!libxl__compare_macs(&mac_n, &nics[i].mac)) { - nic->backend_domid = nics[i].backend_id; - nic->devid = nics[i].devid; - memcpy(nic->mac, nics[i].mac, sizeof (nic->mac)); - nic->script = strdup(nics[i].script); + *nic = nics[i]; rc = 0; + i++; /* Do not destroy this NIC on exit path */ break; } + libxl_device_nic_destroy(&nics[i]); } - for (i=0; i<nb; i++) - libxl_nicinfo_destroy(&nics[i]); + for (; i<nb; i++) + libxl_device_nic_destroy(&nics[i]); + free(nics); return rc; } diff -r 4e640cbed20e -r cafd8b3f9e0c tools/libxl/xl_cmdimpl.c --- a/tools/libxl/xl_cmdimpl.c Fri Sep 30 14:27:27 2011 +0100 +++ b/tools/libxl/xl_cmdimpl.c Fri Sep 30 14:27:27 2011 +0100 @@ -4085,8 +4085,9 @@ int main_networkattach(int argc, char ** int main_networklist(int argc, char **argv) { int opt; - libxl_nicinfo *nics; - unsigned int nb, i; + libxl_device_nic *nics; + libxl_nicinfo nicinfo; + int nb, i; if ((opt = def_getopt(argc, argv, "", "network-list", 1)) != -1) return opt; @@ -4099,19 +4100,23 @@ int main_networklist(int argc, char **ar fprintf(stderr, "%s is an invalid domain identifier\n", *argv); continue; } - if (!(nics = libxl_list_nics(ctx, domid, &nb))) { + nics = libxl_device_nic_list(ctx, domid, &nb); + if (!nics) { continue; } for (i = 0; i < nb; ++i) { - /* Idx BE */ - printf("%-3d %-2d ", nics[i].devid, nics[i].backend_id); - /* MAC */ - printf(LIBXL_MAC_FMT, LIBXL_MAC_BYTES(nics[i].mac)); - /* Hdl Sta evch txr/rxr BE-path */ - printf("%6d %5d %6d %5d/%-11d %-30s\n", - nics[i].devid, nics[i].state, nics[i].evtch, - nics[i].rref_tx, nics[i].rref_rx, nics[i].backend); - libxl_nicinfo_destroy(&nics[i]); + if (!libxl_device_nic_getinfo(ctx, domid, &nics[i], &nicinfo)) { + /* Idx BE */ + printf("%-3d %-2d ", nicinfo.devid, nicinfo.backend_id); + /* MAC */ + printf(LIBXL_MAC_FMT, LIBXL_MAC_BYTES(nics[i].mac)); + /* Hdl Sta evch txr/rxr BE-path */ + printf("%6d %5d %6d %5d/%-11d %-30s\n", + nicinfo.devid, nicinfo.state, nicinfo.evtch, + nicinfo.rref_tx, nicinfo.rref_rx, nicinfo.backend); + libxl_nicinfo_destroy(&nicinfo); + } + libxl_device_nic_destroy(&nics[i]); } free(nics); } _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel From xen-devel-bounces@lists.xensource.com Fri Sep 30 06:40:06 2011 Return-path: <xen-devel-bounces@lists.xensource.com> Envelope-to: www-data@lists.xensource.com Delivery-date: Fri, 30 Sep 2011 06:40:06 -0700 Received: from localhost ([127.0.0.1] helo=lists.colo.xensource.com) by lists.xensource.com with esmtp (Exim 4.43) id 1R9dJu-0001nx-1J; Fri, 30 Sep 2011 06:40:06 -0700 Received: from mail21.messagelabs.com ([85.158.143.35]) by lists.xensource.com with esmtp (Exim 4.43) id 1R9dDX-0008Im-MO for xen-devel@lists.xensource.com; Fri, 30 Sep 2011 06:33:33 -0700 X-Env-Sender: Ian.Campbell@eu.citrix.com X-Msg-Ref: server-4.tower-21.messagelabs.com!1317389561!62247725!5 X-Originating-IP: [66.165.176.63] X-StarScan-Version: 6.4.1; banners=-,-,- X-VirusChecked: Checked Received: (qmail 20708 invoked from network); 30 Sep 2011 13:32:51 -0000 Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63) by server-4.tower-21.messagelabs.com with RC4-SHA encrypted SMTP; 30 Sep 2011 13:32:51 -0000 X-IronPort-AV: E=Sophos;i="4.68,467,1312171200"; d="scan'208";a="165286976" Received: from ftlpmailmx01.citrite.net ([10.13.107.65]) by FTLPIPO02.CITRIX.COM with ESMTP/TLS/RC4-MD5; 30 Sep 2011 09:33:28 -0400 Received: from smtp01.ad.xensource.com (10.219.128.104) by smtprelay.citrix.com (10.13.107.65) with Microsoft SMTP Server id 8.3.137.0; Fri, 30 Sep 2011 09:33:27 -0400 Received: from localhost.localdomain (cosworth.uk.xensource.com [10.80.16.52]) by smtp01.ad.xensource.com (8.13.1/8.13.1) with ESMTP id p8UDXFZN029198; Fri, 30 Sep 2011 06:33:26 -0700 Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Mercurial-Node: d78f45247f1c0a0c879e166010df5cdff2b16988 Message-ID: <d78f45247f1c0a0c879e.1317389601@localhost.localdomain> In-Reply-To: <patchbomb.1317389593@localhost.localdomain> References: <patchbomb.1317389593@localhost.localdomain> User-Agent: Mercurial-patchbomb/1.6.4 Date: Fri, 30 Sep 2011 14:33:21 +0100 From: Ian Campbell <ian.campbell@citrix.com> To: xen-devel@lists.xensource.com Cc: Jim Fehlig <jfehlig@novell.com>, Mike McClurg <mike.mcclurg@citrix.com>, Dave Scott <Dave.Scott@eu.citrix.com>, Jonathan Ludlam <Jonathan.Ludlam@eu.citrix.com> Subject: [Xen-devel] [PATCH 08 of 23] libxl: reimplement devid->disk in terms of from_xs_be function X-BeenThere: xen-devel@lists.xensource.com X-Mailman-Version: 2.1.5 Precedence: list List-Id: Xen developer discussion <xen-devel.lists.xensource.com> List-Unsubscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe> List-Post: <mailto:xen-devel@lists.xensource.com> List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help> List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=subscribe> Sender: xen-devel-bounces@lists.xensource.com Errors-To: xen-devel-bounces@lists.xensource.com # HG changeset patch # User Ian Campbell <ian.campbell@citrix.com> # Date 1317389247 -3600 # Node ID d78f45247f1c0a0c879e166010df5cdff2b16988 # Parent e65e18b230493e7886654d30838ce74407c36168 libxl: reimplement devid->disk in terms of from_xs_be function. Signed-off-by: Ian Campbell <ian.campbell@citrix.com> diff -r e65e18b23049 -r d78f45247f1c tools/libxl/libxl.c --- a/tools/libxl/libxl.c Fri Sep 30 14:27:27 2011 +0100 +++ b/tools/libxl/libxl.c Fri Sep 30 14:27:27 2011 +0100 @@ -1653,6 +1653,33 @@ static void libxl__device_disk_from_xs_b disk->format = LIBXL_DISK_FORMAT_UNKNOWN; } +int libxl_devid_to_device_disk(libxl_ctx *ctx, uint32_t domid, + const char *devid, libxl_device_disk *disk) +{ + libxl__gc gc = LIBXL_INIT_GC(ctx); + char *dompath, *path; + int rc = ERROR_FAIL; + + memset(disk, 0, sizeof (libxl_device_disk)); + dompath = libxl__xs_get_dompath(&gc, domid); + if (!dompath) { + goto out; + } + path = libxl__xs_read(&gc, XBT_NULL, + libxl__sprintf(&gc, "%s/device/vbd/%s/backend", + dompath, devid)); + if (!path) + goto out; + + libxl__device_disk_from_xs_be(&gc, path, disk); + + rc = 0; +out: + libxl__free_all(&gc); + return rc; +} + + static int libxl__append_disk_list_of_type(libxl__gc *gc, uint32_t domid, const char *type, diff -r e65e18b23049 -r d78f45247f1c tools/libxl/libxl_utils.c --- a/tools/libxl/libxl_utils.c Fri Sep 30 14:27:27 2011 +0100 +++ b/tools/libxl/libxl_utils.c Fri Sep 30 14:27:27 2011 +0100 @@ -483,50 +483,6 @@ int libxl_mac_to_device_nic(libxl_ctx *c return rc; } -int libxl_devid_to_device_disk(libxl_ctx *ctx, uint32_t domid, - const char *devid, libxl_device_disk *disk) -{ - libxl__gc gc = LIBXL_INIT_GC(ctx); - char *val; - char *dompath, *diskpath, *be_path; - unsigned int devid_n; - int rc = ERROR_INVAL; - - devid_n = libxl__device_disk_dev_number(devid, NULL, NULL); - if (devid_n < 0) { - goto out; - } - rc = ERROR_FAIL; - dompath = libxl__xs_get_dompath(&gc, domid); - diskpath = libxl__sprintf(&gc, "%s/device/vbd/%d", dompath, devid_n); - if (!diskpath) { - goto out; - } - - val = libxl__xs_read(&gc, XBT_NULL, libxl__sprintf(&gc, "%s/backend-id", diskpath)); - if (!val) - goto out; - disk->backend_domid = strtoul(val, NULL, 10); - be_path = libxl__xs_read(&gc, XBT_NULL, libxl__sprintf(&gc, "%s/backend", diskpath)); - disk->pdev_path = xs_read(ctx->xsh, XBT_NULL, - libxl__sprintf(&gc, "%s/params", be_path), NULL); - val = libxl__xs_read(&gc, XBT_NULL, libxl__sprintf(&gc, "%s/type", be_path)); - libxl_string_to_backend(ctx, val, &(disk->backend)); - disk->vdev = xs_read(ctx->xsh, XBT_NULL, - libxl__sprintf(&gc, "%s/dev", be_path), NULL); - val = libxl__xs_read(&gc, XBT_NULL, libxl__sprintf(&gc, "%s/removable", be_path)); - disk->removable = !strcmp(val, "1"); - val = libxl__xs_read(&gc, XBT_NULL, libxl__sprintf(&gc, "%s/mode", be_path)); - disk->readwrite = !!strcmp(val, "w"); - val = libxl__xs_read(&gc, XBT_NULL, libxl__sprintf(&gc, "%s/device-type", diskpath)); - disk->is_cdrom = !strcmp(val, "cdrom"); - rc = 0; - -out: - libxl__free_all(&gc); - return rc; -} - int libxl_cpumap_alloc(libxl_ctx *ctx, libxl_cpumap *cpumap) { int max_cpus; _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel From xen-devel-bounces@lists.xensource.com Fri Sep 30 06:41:08 2011 Return-path: <xen-devel-bounces@lists.xensource.com> Envelope-to: www-data@lists.xensource.com Delivery-date: Fri, 30 Sep 2011 06:41:08 -0700 Received: from localhost ([127.0.0.1] helo=lists.colo.xensource.com) by lists.xensource.com with esmtp (Exim 4.43) id 1R9dKu-0002Jg-IH; Fri, 30 Sep 2011 06:41:08 -0700 Received: from mail27.messagelabs.com ([193.109.254.147]) by lists.xensource.com with esmtp (Exim 4.43) id 1R9dDb-0008Ji-Il for xen-devel@lists.xensource.com; Fri, 30 Sep 2011 06:33:36 -0700 X-Env-Sender: Ian.Campbell@eu.citrix.com X-Msg-Ref: server-4.tower-27.messagelabs.com!1317389591!42442687!2 X-Originating-IP: [66.165.176.89] X-StarScan-Version: 6.4.1; banners=-,-,- X-VirusChecked: Checked Received: (qmail 30979 invoked from network); 30 Sep 2011 13:33:13 -0000 Received: from smtp.citrix.com (HELO SMTP.CITRIX.COM) (66.165.176.89) by server-4.tower-27.messagelabs.com with RC4-SHA encrypted SMTP; 30 Sep 2011 13:33:13 -0000 X-IronPort-AV: E=Sophos;i="4.68,467,1312171200"; d="scan'208";a="17841092" Received: from ftlpmailmx01.citrite.net ([10.13.107.65]) by FTLPIPO01.CITRIX.COM with ESMTP/TLS/RC4-MD5; 30 Sep 2011 09:33:24 -0400 Received: from smtp01.ad.xensource.com (10.219.128.104) by smtprelay.citrix.com (10.13.107.65) with Microsoft SMTP Server id 8.3.137.0; Fri, 30 Sep 2011 09:33:23 -0400 Received: from localhost.localdomain (cosworth.uk.xensource.com [10.80.16.52]) by smtp01.ad.xensource.com (8.13.1/8.13.1) with ESMTP id p8UDXFZK029198; Fri, 30 Sep 2011 06:33:22 -0700 Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Mercurial-Node: 4e640cbed20e8ef533f8eb27a82dcdac2be2e8ab Message-ID: <4e640cbed20e8ef533f8.1317389598@localhost.localdomain> In-Reply-To: <patchbomb.1317389593@localhost.localdomain> References: <patchbomb.1317389593@localhost.localdomain> User-Agent: Mercurial-patchbomb/1.6.4 Date: Fri, 30 Sep 2011 14:33:18 +0100 From: Ian Campbell <ian.campbell@citrix.com> To: xen-devel@lists.xensource.com Cc: Jim Fehlig <jfehlig@novell.com>, Mike McClurg <mike.mcclurg@citrix.com>, Dave Scott <Dave.Scott@eu.citrix.com>, Jonathan Ludlam <Jonathan.Ludlam@eu.citrix.com> Subject: [Xen-devel] [PATCH 05 of 23] libxl: do not read f.e. xenstore dir in disk list function X-BeenThere: xen-devel@lists.xensource.com X-Mailman-Version: 2.1.5 Precedence: list List-Id: Xen developer discussion <xen-devel.lists.xensource.com> List-Unsubscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe> List-Post: <mailto:xen-devel@lists.xensource.com> List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help> List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=subscribe> Sender: xen-devel-bounces@lists.xensource.com Errors-To: xen-devel-bounces@lists.xensource.com # HG changeset patch # User Ian Campbell <ian.campbell@citrix.com> # Date 1317389247 -3600 # Node ID 4e640cbed20e8ef533f8eb27a82dcdac2be2e8ab # Parent 8645a81f04282ca4e3c51141b1c177ad9a8d5943 libxl: do not read f.e. xenstore dir in disk list function Instead store a duplicate of the "device-type" node in the backend dir and use that instead. This maintains the invariant that the list function is always "safe". XXX I'm not sure this is an actual issue. The entries in the frontend device XXX area are writeable by the guest but maybe the solution is to restrict that? Signed-off-by: Ian Campbell <ian.campbell@citrix.com> diff -r 8645a81f0428 -r 4e640cbed20e tools/libxl/libxl.c --- a/tools/libxl/libxl.c Fri Sep 30 14:27:27 2011 +0100 +++ b/tools/libxl/libxl.c Fri Sep 30 14:27:27 2011 +0100 @@ -1015,6 +1015,8 @@ int libxl_device_disk_add(libxl_ctx *ctx flexarray_append(back, libxl__device_disk_string_of_backend(disk->backend)); flexarray_append(back, "mode"); flexarray_append(back, disk->readwrite ? "w" : "r"); + flexarray_append(back, "device-type"); + flexarray_append(back, disk->is_cdrom ? "cdrom" : "disk"); flexarray_append(front, "backend-id"); flexarray_append(front, libxl__sprintf(&gc, "%d", disk->backend_domid)); @@ -1509,7 +1511,6 @@ static void libxl__device_disk_from_xs_b libxl_ctx *ctx = libxl__gc_owner(gc); unsigned int len; char *tmp; - const char *fe_path; /* XXX unsafe */ memset(disk, 0, sizeof(*disk)); @@ -1541,10 +1542,8 @@ static void libxl__device_disk_from_xs_b else disk->readwrite = 0; - fe_path = libxl__xs_read(gc, XBT_NULL, - libxl__sprintf(gc, "%s/frontend", be_path)); tmp = libxl__xs_read(gc, XBT_NULL, - libxl__sprintf(gc, "%s/device-type", fe_path)); + libxl__sprintf(gc, "%s/device-type", be_path)); disk->is_cdrom = !strcmp(tmp, "cdrom"); disk->format = LIBXL_DISK_FORMAT_UNKNOWN; _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel From xen-devel-bounces@lists.xensource.com Fri Sep 30 06:41:57 2011 Return-path: <xen-devel-bounces@lists.xensource.com> Envelope-to: www-data@lists.xensource.com Delivery-date: Fri, 30 Sep 2011 06:41:57 -0700 Received: from localhost ([127.0.0.1] helo=lists.colo.xensource.com) by lists.xensource.com with esmtp (Exim 4.43) id 1R9dLg-0002iV-Vu; Fri, 30 Sep 2011 06:41:57 -0700 Received: from mail27.messagelabs.com ([193.109.254.147]) by lists.xensource.com with esmtp (Exim 4.43) id 1R9dDb-0008Jh-3e for xen-devel@lists.xensource.com; Fri, 30 Sep 2011 06:33:36 -0700 X-Env-Sender: Ian.Campbell@eu.citrix.com X-Msg-Ref: server-4.tower-27.messagelabs.com!1317389591!42442687!1 X-Originating-IP: [66.165.176.89] X-StarScan-Version: 6.4.1; banners=-,-,- X-VirusChecked: Checked Received: (qmail 30956 invoked from network); 30 Sep 2011 13:33:12 -0000 Received: from smtp.citrix.com (HELO SMTP.CITRIX.COM) (66.165.176.89) by server-4.tower-27.messagelabs.com with RC4-SHA encrypted SMTP; 30 Sep 2011 13:33:12 -0000 X-IronPort-AV: E=Sophos;i="4.68,467,1312171200"; d="scan'208";a="17841090" Received: from ftlpmailmx01.citrite.net ([10.13.107.65]) by FTLPIPO01.CITRIX.COM with ESMTP/TLS/RC4-MD5; 30 Sep 2011 09:33:20 -0400 Received: from smtp01.ad.xensource.com (10.219.128.104) by smtprelay.citrix.com (10.13.107.65) with Microsoft SMTP Server id 8.3.137.0; Fri, 30 Sep 2011 09:33:20 -0400 Received: from localhost.localdomain (cosworth.uk.xensource.com [10.80.16.52]) by smtp01.ad.xensource.com (8.13.1/8.13.1) with ESMTP id p8UDXFZH029198; Fri, 30 Sep 2011 06:33:19 -0700 Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Mercurial-Node: 7c845e974def74de73f67123f39d6fd2769082e9 Message-ID: <7c845e974def74de73f6.1317389595@localhost.localdomain> In-Reply-To: <patchbomb.1317389593@localhost.localdomain> References: <patchbomb.1317389593@localhost.localdomain> User-Agent: Mercurial-patchbomb/1.6.4 Date: Fri, 30 Sep 2011 14:33:15 +0100 From: Ian Campbell <ian.campbell@citrix.com> To: xen-devel@lists.xensource.com Cc: Jim Fehlig <jfehlig@novell.com>, Mike McClurg <mike.mcclurg@citrix.com>, Dave Scott <Dave.Scott@eu.citrix.com>, Jonathan Ludlam <Jonathan.Ludlam@eu.citrix.com> Subject: [Xen-devel] [PATCH 02 of 23] libxl: add a comment describing the device interfaces X-BeenThere: xen-devel@lists.xensource.com X-Mailman-Version: 2.1.5 Precedence: list List-Id: Xen developer discussion <xen-devel.lists.xensource.com> List-Unsubscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe> List-Post: <mailto:xen-devel@lists.xensource.com> List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help> List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=subscribe> Sender: xen-devel-bounces@lists.xensource.com Errors-To: xen-devel-bounces@lists.xensource.com # HG changeset patch # User Ian Campbell <ian.campbell@citrix.com> # Date 1317389247 -3600 # Node ID 7c845e974def74de73f67123f39d6fd2769082e9 # Parent 42dee7039d911db8b82e9f857fcad92a689d0318 libxl: add a comment describing the device interfaces. Subsequent patches will endevour to make reality match this defined interface. Signed-off-by: Ian Campbell <ian.campbell@citrix.com> diff -r 42dee7039d91 -r 7c845e974def tools/libxl/libxl.h --- a/tools/libxl/libxl.h Fri Sep 30 14:27:27 2011 +0100 +++ b/tools/libxl/libxl.h Fri Sep 30 14:27:27 2011 +0100 @@ -379,6 +379,78 @@ libxl_dominfo * libxl_list_domain(libxl_ libxl_cpupoolinfo * libxl_list_cpupool(libxl_ctx*, int *nb_pool); libxl_vminfo * libxl_list_vm(libxl_ctx *ctx, int *nb_vm); +/* + * Devices + * ======= + * + * Each device is represented by a libxl_device_<TYPE> data structure + * which is defined via the IDL. In addition some devices have an + * additional data type libxl_device_<TYPE>_getinfo which contains + * further runtime information about the device. + * + * A common set of methods are available for each device type. These + * are described below. + * + * Querying + * -------- + * + * libxl_device_<type>_list(ctx, domid, nr): + * + * Returns an array of libxl_device_<type> length nr representing + * the devices attached to the specified domain. + * + * libxl_device_<type>_getinfo(ctx, domid, device, info): + * + * Initialises info with details of the given device which must be + * attached to the specified domain. + * + * Creation / Control + * ------------------ + * + * libxl_device_<type>_init(ctx, device): + * + * Initalises device to a default configuration. + * + * libxl_device_<type>_add(ctx, domid, device): + * + * Adds the given device to the specified domain. This can be called + * while the guest is running (hotplug) or before boot (coldplug). + * + * This function only sets up the device but does not wait for the + * domain to connect to the device and therefore cannot block on the + * guest. + * + * XXX do we need a way to wait? e.g. wait_for_connect function? + * XXX perhaps an optional way to generate an event on connect? + * needs event system overhaul. + * + * libxl_device_<type>_remove(ctx, domid, device): + * + * Removes the given device from the specified domain by performing + * an orderly unplug with guest co-operation. This requires that the + * guest is running. + * + * This method is currently synchronous and therefore can block + * while interacting with the guest. + * + * XXX should provide an async version. needs event system overhaul. + * + * libxl_device_<type>_force_remove(ctx, domid, device): + * + * Removes the given device from the specified domain without guest + * co-operation. It is guest specific what affect this will have on + * a running guest. + * + * This function does not interact with the guest and therefore + * cannot block on the guest. + * + * Note + * ---- + * + * The function libxl_device_<type>_destroy is defined by the IDL and + * is used to free the members of the libxl_device_<type> data + * type. It has no impact on the devices attached to any domain. + */ int libxl_device_disk_add(libxl_ctx *ctx, uint32_t domid, libxl_device_disk *disk); int libxl_device_disk_del(libxl_ctx *ctx, uint32_t domid, libxl_device_disk *disk, int wait); libxl_device_disk *libxl_device_disk_list(libxl_ctx *ctx, uint32_t domid, int *num); _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel From xen-devel-bounces@lists.xensource.com Fri Sep 30 06:42:52 2011 Return-path: <xen-devel-bounces@lists.xensource.com> Envelope-to: www-data@lists.xensource.com Delivery-date: Fri, 30 Sep 2011 06:42:52 -0700 Received: from localhost ([127.0.0.1] helo=lists.colo.xensource.com) by lists.xensource.com with esmtp (Exim 4.43) id 1R9dMa-00038e-7E; Fri, 30 Sep 2011 06:42:52 -0700 Received: from mail21.messagelabs.com ([85.158.143.35]) by lists.xensource.com with esmtp (Exim 4.43) id 1R9dDc-0008Jv-7J for xen-devel@lists.xensource.com; Fri, 30 Sep 2011 06:33:36 -0700 X-Env-Sender: Ian.Campbell@eu.citrix.com X-Msg-Ref: server-4.tower-21.messagelabs.com!1317389561!62247725!6 X-Originating-IP: [66.165.176.63] X-StarScan-Version: 6.4.1; banners=-,-,- X-VirusChecked: Checked Received: (qmail 20879 invoked from network); 30 Sep 2011 13:32:55 -0000 Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63) by server-4.tower-21.messagelabs.com with RC4-SHA encrypted SMTP; 30 Sep 2011 13:32:55 -0000 X-IronPort-AV: E=Sophos;i="4.68,467,1312171200"; d="scan'208";a="165286987" Received: from ftlpmailmx01.citrite.net ([10.13.107.65]) by FTLPIPO02.CITRIX.COM with ESMTP/TLS/RC4-MD5; 30 Sep 2011 09:33:32 -0400 Received: from smtp01.ad.xensource.com (10.219.128.104) by smtprelay.citrix.com (10.13.107.65) with Microsoft SMTP Server id 8.3.137.0; Fri, 30 Sep 2011 09:33:31 -0400 Received: from localhost.localdomain (cosworth.uk.xensource.com [10.80.16.52]) by smtp01.ad.xensource.com (8.13.1/8.13.1) with ESMTP id p8UDXFZQ029198; Fri, 30 Sep 2011 06:33:30 -0700 Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Mercurial-Node: ed800095162c2d459ba6bdd651ef6f246858c458 Message-ID: <ed800095162c2d459ba6.1317389604@localhost.localdomain> In-Reply-To: <patchbomb.1317389593@localhost.localdomain> References: <patchbomb.1317389593@localhost.localdomain> User-Agent: Mercurial-patchbomb/1.6.4 Date: Fri, 30 Sep 2011 14:33:24 +0100 From: Ian Campbell <ian.campbell@citrix.com> To: xen-devel@lists.xensource.com Cc: Jim Fehlig <jfehlig@novell.com>, Mike McClurg <mike.mcclurg@citrix.com>, Dave Scott <Dave.Scott@eu.citrix.com>, Jonathan Ludlam <Jonathan.Ludlam@eu.citrix.com> Subject: [Xen-devel] [PATCH 11 of 23] libxl: split forced and non-forced uses of libxl__device_del X-BeenThere: xen-devel@lists.xensource.com X-Mailman-Version: 2.1.5 Precedence: list List-Id: Xen developer discussion <xen-devel.lists.xensource.com> List-Unsubscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe> List-Post: <mailto:xen-devel@lists.xensource.com> List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help> List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=subscribe> Sender: xen-devel-bounces@lists.xensource.com Errors-To: xen-devel-bounces@lists.xensource.com # HG changeset patch # User Ian Campbell <ian.campbell@citrix.com> # Date 1317389247 -3600 # Node ID ed800095162c2d459ba6bdd651ef6f246858c458 # Parent dd195d45be273cf85ef0a614ac69b4498bac6d10 libxl: split forced and non-forced uses of libxl__device_del Most forced users can now simply call libxl__device_force_remove directly. libxl__devices_destroy is something of a special case, it is really just iterating over an opaque set of xenstore directories and removing them. Until this can be refactored just do the force-remove case manually, doing otherwise led to too much entanglement with the other callers of libxl__device_force_remove which do know about specific device types. For the time being do the same in libxl__device_pci_remove_xenstore. Signed-off-by: Ian Campbell <ian.campbell@citrix.com> diff -r dd195d45be27 -r ed800095162c tools/libxl/libxl.c --- a/tools/libxl/libxl.c Fri Sep 30 14:27:27 2011 +0100 +++ b/tools/libxl/libxl.c Fri Sep 30 14:27:27 2011 +0100 @@ -1071,7 +1071,10 @@ int libxl_device_disk_del(libxl_ctx *ctx device.domid = domid; device.devid = devid; device.kind = DEVICE_VBD; - rc = libxl__device_del(&gc, &device, wait); + if (wait) + rc = libxl__device_del(&gc, &device); + else + rc = libxl__device_force_remove(&gc, &device); out_free: libxl__free_all(&gc); return rc; @@ -1283,7 +1286,11 @@ int libxl_device_nic_del(libxl_ctx *ctx, device.domid = domid; device.kind = DEVICE_VIF; - rc = libxl__device_del(&gc, &device, wait); + if (wait) + rc = libxl__device_del(&gc, &device); + else + rc = libxl__device_force_remove(&gc, &device); + libxl__free_all(&gc); return rc; } diff -r dd195d45be27 -r ed800095162c tools/libxl/libxl_device.c --- a/tools/libxl/libxl_device.c Fri Sep 30 14:27:27 2011 +0100 +++ b/tools/libxl/libxl_device.c Fri Sep 30 14:27:27 2011 +0100 @@ -401,11 +401,17 @@ out: return rc; } -int libxl__device_force_remove(libxl__gc *gc, char *be_path) +int libxl__device_force_remove(libxl__gc *gc, libxl__device *dev) { libxl_ctx *ctx = libxl__gc_owner(gc); + char *be_path = libxl__device_backend_path(gc, dev); + char *fe_path = libxl__device_frontend_path(gc, dev); + xs_rm(ctx->xsh, XBT_NULL, be_path); + xs_rm(ctx->xsh, XBT_NULL, fe_path); + libxl__device_destroy_tapdisk(gc, be_path); + return 0; } @@ -466,10 +472,14 @@ int libxl__devices_destroy(libxl__gc *gc fe_path = libxl__sprintf(gc, "/local/domain/%d/device/%s/%s", domid, l1[i], l2[j]); be_path = libxl__xs_read(gc, XBT_NULL, libxl__sprintf(gc, "%s/backend", fe_path)); if (be_path != NULL) { - int rc = force ? libxl__device_force_remove(gc, be_path) - : libxl__device_remove(gc, be_path); - if (rc > 0) - n_watches++; + if (force) { + xs_rm(ctx->xsh, XBT_NULL, be_path); + xs_rm(ctx->xsh, XBT_NULL, fe_path); + libxl__device_destroy_tapdisk(gc, be_path); + } else { + if (libxl__device_remove(gc, be_path) > 0) + n_watches++; + } } else { xs_rm(ctx->xsh, XBT_NULL, path); } @@ -480,10 +490,13 @@ int libxl__devices_destroy(libxl__gc *gc fe_path = libxl__sprintf(gc, "/local/domain/%d/console", domid); be_path = libxl__xs_read(gc, XBT_NULL, libxl__sprintf(gc, "%s/backend", fe_path)); if (be_path && strcmp(be_path, "")) { - int rc = force ? libxl__device_force_remove(gc, be_path) - : libxl__device_remove(gc, be_path); - if (rc > 0) - n_watches++; + if (force) { + xs_rm(ctx->xsh, XBT_NULL, be_path); + xs_rm(ctx->xsh, XBT_NULL, fe_path); + } else { + if (libxl__device_remove(gc, be_path) > 0) + n_watches++; + } } if (!force) { @@ -507,29 +520,24 @@ out: return 0; } -int libxl__device_del(libxl__gc *gc, libxl__device *dev, int wait) +int libxl__device_del(libxl__gc *gc, libxl__device *dev) { libxl_ctx *ctx = libxl__gc_owner(gc); + struct timeval tv; char *backend_path; int rc; backend_path = libxl__device_backend_path(gc, dev); - if (wait) - rc = libxl__device_remove(gc, backend_path); - else - rc = libxl__device_force_remove(gc, backend_path); + rc = libxl__device_remove(gc, backend_path); if (rc == -1) { rc = ERROR_FAIL; goto out; } - if (wait) { - struct timeval tv; - tv.tv_sec = LIBXL_DESTROY_TIMEOUT; - tv.tv_usec = 0; - (void)wait_for_dev_destroy(gc, &tv); - } + tv.tv_sec = LIBXL_DESTROY_TIMEOUT; + tv.tv_usec = 0; + (void)wait_for_dev_destroy(gc, &tv); xs_rm(ctx->xsh, XBT_NULL, libxl__device_frontend_path(gc, dev)); rc = 0; diff -r dd195d45be27 -r ed800095162c tools/libxl/libxl_internal.h --- a/tools/libxl/libxl_internal.h Fri Sep 30 14:27:27 2011 +0100 +++ b/tools/libxl/libxl_internal.h Fri Sep 30 14:27:27 2011 +0100 @@ -252,9 +252,9 @@ _hidden int libxl__device_generic_add(li char **bents, char **fents); _hidden char *libxl__device_backend_path(libxl__gc *gc, libxl__device *device); _hidden char *libxl__device_frontend_path(libxl__gc *gc, libxl__device *device); -_hidden int libxl__device_del(libxl__gc *gc, libxl__device *dev, int wait); +_hidden int libxl__device_del(libxl__gc *gc, libxl__device *dev); _hidden int libxl__device_remove(libxl__gc *gc, char *be_path); -_hidden int libxl__device_force_remove(libxl__gc *gc, char *be_path); +_hidden int libxl__device_force_remove(libxl__gc *gc, libxl__device *dev); _hidden int libxl__devices_destroy(libxl__gc *gc, uint32_t domid, int force); _hidden int libxl__wait_for_backend(libxl__gc *gc, char *be_path, char *state); diff -r dd195d45be27 -r ed800095162c tools/libxl/libxl_pci.c --- a/tools/libxl/libxl_pci.c Fri Sep 30 14:27:27 2011 +0100 +++ b/tools/libxl/libxl_pci.c Fri Sep 30 14:27:27 2011 +0100 @@ -411,7 +411,7 @@ retry_transaction2: if (num == 1) { char *fe_path = libxl__xs_read(gc, XBT_NULL, libxl__sprintf(gc, "%s/frontend", be_path)); - libxl__device_force_remove(gc, be_path); + xs_rm(ctx->xsh, XBT_NULL, be_path); xs_rm(ctx->xsh, XBT_NULL, fe_path); return 0; } _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel From xen-devel-bounces@lists.xensource.com Fri Sep 30 06:43:53 2011 Return-path: <xen-devel-bounces@lists.xensource.com> Envelope-to: www-data@lists.xensource.com Delivery-date: Fri, 30 Sep 2011 06:43:53 -0700 Received: from localhost ([127.0.0.1] helo=lists.colo.xensource.com) by lists.xensource.com with esmtp (Exim 4.43) id 1R9dNZ-0003d8-Or; Fri, 30 Sep 2011 06:43:53 -0700 Received: from mail21.messagelabs.com ([85.158.143.35]) by lists.xensource.com with esmtp (Exim 4.43) id 1R9dDe-0008Ka-6R for xen-devel@lists.xensource.com; Fri, 30 Sep 2011 06:33:38 -0700 X-Env-Sender: Ian.Campbell@eu.citrix.com X-Msg-Ref: server-4.tower-21.messagelabs.com!1317389561!62247725!7 X-Originating-IP: [66.165.176.63] X-StarScan-Version: 6.4.1; banners=-,-,- X-VirusChecked: Checked Received: (qmail 20885 invoked from network); 30 Sep 2011 13:32:58 -0000 Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63) by server-4.tower-21.messagelabs.com with RC4-SHA encrypted SMTP; 30 Sep 2011 13:32:58 -0000 X-IronPort-AV: E=Sophos;i="4.68,467,1312171200"; d="scan'208";a="165286991" Received: from ftlpmailmx01.citrite.net ([10.13.107.65]) by FTLPIPO02.CITRIX.COM with ESMTP/TLS/RC4-MD5; 30 Sep 2011 09:33:34 -0400 Received: from smtp01.ad.xensource.com (10.219.128.104) by smtprelay.citrix.com (10.13.107.65) with Microsoft SMTP Server id 8.3.137.0; Fri, 30 Sep 2011 09:33:34 -0400 Received: from localhost.localdomain (cosworth.uk.xensource.com [10.80.16.52]) by smtp01.ad.xensource.com (8.13.1/8.13.1) with ESMTP id p8UDXFZS029198; Fri, 30 Sep 2011 06:33:33 -0700 Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Mercurial-Node: e5a70a3b61a1acfa7d73db548a591486024d01b7 Message-ID: <e5a70a3b61a1acfa7d73.1317389606@localhost.localdomain> In-Reply-To: <patchbomb.1317389593@localhost.localdomain> References: <patchbomb.1317389593@localhost.localdomain> User-Agent: Mercurial-patchbomb/1.6.4 Date: Fri, 30 Sep 2011 14:33:26 +0100 From: Ian Campbell <ian.campbell@citrix.com> To: xen-devel@lists.xensource.com Cc: Jim Fehlig <jfehlig@novell.com>, Mike McClurg <mike.mcclurg@citrix.com>, Dave Scott <Dave.Scott@eu.citrix.com>, Jonathan Ludlam <Jonathan.Ludlam@eu.citrix.com> Subject: [Xen-devel] [PATCH 13 of 23] libxl: do not remove unidentified frontend paths in libxl__devices_destroy X-BeenThere: xen-devel@lists.xensource.com X-Mailman-Version: 2.1.5 Precedence: list List-Id: Xen developer discussion <xen-devel.lists.xensource.com> List-Unsubscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe> List-Post: <mailto:xen-devel@lists.xensource.com> List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help> List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=subscribe> Sender: xen-devel-bounces@lists.xensource.com Errors-To: xen-devel-bounces@lists.xensource.com # HG changeset patch # User Ian Campbell <ian.campbell@citrix.com> # Date 1317389248 -3600 # Node ID e5a70a3b61a1acfa7d73db548a591486024d01b7 # Parent e8cff01ad4b5519be66e726db124cbdfab4f1e04 libxl: do not remove unidentified frontend paths in libxl__devices_destroy Currently this appears to only include "/local/domain/<domid>/device/suspend". Ultimately the caller will nuke the whole guest directory anyway but not having this function remove things which don't look like devices seems less surprising. Signed-off-by: Ian Campbell <ian.campbell@citrix.com> diff -r e8cff01ad4b5 -r e5a70a3b61a1 tools/libxl/libxl_device.c --- a/tools/libxl/libxl_device.c Fri Sep 30 14:27:28 2011 +0100 +++ b/tools/libxl/libxl_device.c Fri Sep 30 14:27:28 2011 +0100 @@ -463,8 +463,6 @@ int libxl__devices_destroy(libxl__gc *gc if (libxl__device_remove(gc, be_path) > 0) n_watches++; } - } else { - xs_rm(ctx->xsh, XBT_NULL, path); } } } _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel From xen-devel-bounces@lists.xensource.com Fri Sep 30 06:44:42 2011 Return-path: <xen-devel-bounces@lists.xensource.com> Envelope-to: www-data@lists.xensource.com Delivery-date: Fri, 30 Sep 2011 06:44:42 -0700 Received: from localhost ([127.0.0.1] helo=lists.colo.xensource.com) by lists.xensource.com with esmtp (Exim 4.43) id 1R9dOL-00042B-V6; Fri, 30 Sep 2011 06:44:42 -0700 Received: from mail27.messagelabs.com ([193.109.254.147]) by lists.xensource.com with esmtp (Exim 4.43) id 1R9dDc-0008Jr-5R for xen-devel@lists.xensource.com; Fri, 30 Sep 2011 06:33:38 -0700 X-Env-Sender: Ian.Campbell@eu.citrix.com X-Msg-Ref: server-4.tower-27.messagelabs.com!1317389591!42442687!3 X-Originating-IP: [66.165.176.89] X-StarScan-Version: 6.4.1; banners=-,-,- X-VirusChecked: Checked Received: (qmail 31019 invoked from network); 30 Sep 2011 13:33:13 -0000 Received: from smtp.citrix.com (HELO SMTP.CITRIX.COM) (66.165.176.89) by server-4.tower-27.messagelabs.com with RC4-SHA encrypted SMTP; 30 Sep 2011 13:33:13 -0000 X-IronPort-AV: E=Sophos;i="4.68,467,1312171200"; d="scan'208";a="17841094" Received: from ftlpmailmx01.citrite.net ([10.13.107.65]) by FTLPIPO01.CITRIX.COM with ESMTP/TLS/RC4-MD5; 30 Sep 2011 09:33:29 -0400 Received: from smtp01.ad.xensource.com (10.219.128.104) by smtprelay.citrix.com (10.13.107.65) with Microsoft SMTP Server id 8.3.137.0; Fri, 30 Sep 2011 09:33:29 -0400 Received: from localhost.localdomain (cosworth.uk.xensource.com [10.80.16.52]) by smtp01.ad.xensource.com (8.13.1/8.13.1) with ESMTP id p8UDXFZO029198; Fri, 30 Sep 2011 06:33:28 -0700 Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Mercurial-Node: cefb64e94c5e47858ebe2d76d2448da3d9caa7fb Message-ID: <cefb64e94c5e47858ebe.1317389602@localhost.localdomain> In-Reply-To: <patchbomb.1317389593@localhost.localdomain> References: <patchbomb.1317389593@localhost.localdomain> User-Agent: Mercurial-patchbomb/1.6.4 Date: Fri, 30 Sep 2011 14:33:22 +0100 From: Ian Campbell <ian.campbell@citrix.com> To: xen-devel@lists.xensource.com Cc: Jim Fehlig <jfehlig@novell.com>, Mike McClurg <mike.mcclurg@citrix.com>, Dave Scott <Dave.Scott@eu.citrix.com>, Jonathan Ludlam <Jonathan.Ludlam@eu.citrix.com> Subject: [Xen-devel] [PATCH 09 of 23] libxl: libxl_devid_to_* should take an integer device id X-BeenThere: xen-devel@lists.xensource.com X-Mailman-Version: 2.1.5 Precedence: list List-Id: Xen developer discussion <xen-devel.lists.xensource.com> List-Unsubscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe> List-Post: <mailto:xen-devel@lists.xensource.com> List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help> List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=subscribe> Sender: xen-devel-bounces@lists.xensource.com Errors-To: xen-devel-bounces@lists.xensource.com # HG changeset patch # User Ian Campbell <ian.campbell@citrix.com> # Date 1317389247 -3600 # Node ID cefb64e94c5e47858ebe2d76d2448da3d9caa7fb # Parent d78f45247f1c0a0c879e166010df5cdff2b16988 libxl: libxl_devid_to_* should take an integer device id Currently takes a string. Signed-off-by: Ian Campbell <ian.campbell@citrix.com> diff -r d78f45247f1c -r cefb64e94c5e tools/libxl/libxl.c --- a/tools/libxl/libxl.c Fri Sep 30 14:27:27 2011 +0100 +++ b/tools/libxl/libxl.c Fri Sep 30 14:27:27 2011 +0100 @@ -1330,7 +1330,7 @@ static void libxl__device_nic_from_xs_be } int libxl_devid_to_device_nic(libxl_ctx *ctx, uint32_t domid, - const char *devid, libxl_device_nic *nic) + int devid, libxl_device_nic *nic) { libxl__gc gc = LIBXL_INIT_GC(ctx); char *dompath, *path; @@ -1342,7 +1342,7 @@ int libxl_devid_to_device_nic(libxl_ctx goto out; path = libxl__xs_read(&gc, XBT_NULL, - libxl__sprintf(&gc, "%s/device/vif/%s/backend", + libxl__sprintf(&gc, "%s/device/vif/%d/backend", dompath, devid)); if (!path) goto out; @@ -1654,7 +1654,7 @@ static void libxl__device_disk_from_xs_b } int libxl_devid_to_device_disk(libxl_ctx *ctx, uint32_t domid, - const char *devid, libxl_device_disk *disk) + int devid, libxl_device_disk *disk) { libxl__gc gc = LIBXL_INIT_GC(ctx); char *dompath, *path; @@ -1666,7 +1666,7 @@ int libxl_devid_to_device_disk(libxl_ctx goto out; } path = libxl__xs_read(&gc, XBT_NULL, - libxl__sprintf(&gc, "%s/device/vbd/%s/backend", + libxl__sprintf(&gc, "%s/device/vbd/%d/backend", dompath, devid)); if (!path) goto out; diff -r d78f45247f1c -r cefb64e94c5e tools/libxl/libxl_utils.h --- a/tools/libxl/libxl_utils.h Fri Sep 30 14:27:27 2011 +0100 +++ b/tools/libxl/libxl_utils.h Fri Sep 30 14:27:27 2011 +0100 @@ -60,11 +60,11 @@ void libxl_report_child_exitstatus(libxl int libxl_mac_to_device_nic(libxl_ctx *ctx, uint32_t domid, const char *mac, libxl_device_nic *nic); -int libxl_devid_to_device_nic(libxl_ctx *ctx, uint32_t domid, - const char *devid, libxl_device_nic *nic); +int libxl_devid_to_device_nic(libxl_ctx *ctx, uint32_t domid, int devid, + libxl_device_nic *nic); -int libxl_devid_to_device_disk(libxl_ctx *ctx, uint32_t domid, - const char *devid, libxl_device_disk *disk); +int libxl_devid_to_device_disk(libxl_ctx *ctx, uint32_t domid, int devid, + libxl_device_disk *disk); int libxl_cpumap_alloc(libxl_ctx *ctx, libxl_cpumap *cpumap); int libxl_cpumap_test(libxl_cpumap *cpumap, int cpu); diff -r d78f45247f1c -r cefb64e94c5e tools/libxl/xl_cmdimpl.c --- a/tools/libxl/xl_cmdimpl.c Fri Sep 30 14:27:27 2011 +0100 +++ b/tools/libxl/xl_cmdimpl.c Fri Sep 30 14:27:27 2011 +0100 @@ -4137,7 +4137,7 @@ int main_networkdetach(int argc, char ** } if (!strchr(argv[optind+1], ':')) { - if (libxl_devid_to_device_nic(ctx, domid, argv[optind+1], &nic)) { + if (libxl_devid_to_device_nic(ctx, domid, atoi(argv[optind+1]), &nic)) { fprintf(stderr, "Unknown device %s.\n", argv[optind+1]); return 1; } @@ -4238,7 +4238,7 @@ int main_blockdetach(int argc, char **ar fprintf(stderr, "%s is an invalid domain identifier\n", argv[optind]); return 1; } - if (libxl_devid_to_device_disk(ctx, domid, argv[optind+1], &disk)) { + if (libxl_devid_to_device_disk(ctx, domid, atoi(argv[optind+1]), &disk)) { fprintf(stderr, "Error: Device %s not connected.\n", argv[optind+1]); return 1; } _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel From xen-devel-bounces@lists.xensource.com Fri Sep 30 06:45:35 2011 Return-path: <xen-devel-bounces@lists.xensource.com> Envelope-to: www-data@lists.xensource.com Delivery-date: Fri, 30 Sep 2011 06:45:35 -0700 Received: from localhost ([127.0.0.1] helo=lists.colo.xensource.com) by lists.xensource.com with esmtp (Exim 4.43) id 1R9dPD-0004RD-IO; Fri, 30 Sep 2011 06:45:35 -0700 Received: from mail27.messagelabs.com ([193.109.254.147]) by lists.xensource.com with esmtp (Exim 4.43) id 1R9dDd-0008KM-J7 for xen-devel@lists.xensource.com; Fri, 30 Sep 2011 06:33:38 -0700 X-Env-Sender: Ian.Campbell@eu.citrix.com X-Msg-Ref: server-4.tower-27.messagelabs.com!1317389591!42442687!5 X-Originating-IP: [66.165.176.89] X-StarScan-Version: 6.4.1; banners=-,-,- X-VirusChecked: Checked Received: (qmail 31108 invoked from network); 30 Sep 2011 13:33:14 -0000 Received: from smtp.citrix.com (HELO SMTP.CITRIX.COM) (66.165.176.89) by server-4.tower-27.messagelabs.com with RC4-SHA encrypted SMTP; 30 Sep 2011 13:33:14 -0000 X-IronPort-AV: E=Sophos;i="4.68,467,1312171200"; d="scan'208";a="17841096" Received: from ftlpmailmx01.citrite.net ([10.13.107.65]) by FTLPIPO01.CITRIX.COM with ESMTP/TLS/RC4-MD5; 30 Sep 2011 09:33:33 -0400 Received: from smtp01.ad.xensource.com (10.219.128.104) by smtprelay.citrix.com (10.13.107.65) with Microsoft SMTP Server id 8.3.137.0; Fri, 30 Sep 2011 09:33:32 -0400 Received: from localhost.localdomain (cosworth.uk.xensource.com [10.80.16.52]) by smtp01.ad.xensource.com (8.13.1/8.13.1) with ESMTP id p8UDXFZR029198; Fri, 30 Sep 2011 06:33:31 -0700 Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Mercurial-Node: e8cff01ad4b5519be66e726db124cbdfab4f1e04 Message-ID: <e8cff01ad4b5519be66e.1317389605@localhost.localdomain> In-Reply-To: <patchbomb.1317389593@localhost.localdomain> References: <patchbomb.1317389593@localhost.localdomain> User-Agent: Mercurial-patchbomb/1.6.4 Date: Fri, 30 Sep 2011 14:33:25 +0100 From: Ian Campbell <ian.campbell@citrix.com> To: xen-devel@lists.xensource.com Cc: Jim Fehlig <jfehlig@novell.com>, Mike McClurg <mike.mcclurg@citrix.com>, Dave Scott <Dave.Scott@eu.citrix.com>, Jonathan Ludlam <Jonathan.Ludlam@eu.citrix.com> Subject: [Xen-devel] [PATCH 12 of 23] libxl: use IDL to define device front- and back-end kinds X-BeenThere: xen-devel@lists.xensource.com X-Mailman-Version: 2.1.5 Precedence: list List-Id: Xen developer discussion <xen-devel.lists.xensource.com> List-Unsubscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe> List-Post: <mailto:xen-devel@lists.xensource.com> List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help> List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=subscribe> Sender: xen-devel-bounces@lists.xensource.com Errors-To: xen-devel-bounces@lists.xensource.com # HG changeset patch # User Ian Campbell <ian.campbell@citrix.com> # Date 1317389248 -3600 # Node ID e8cff01ad4b5519be66e726db124cbdfab4f1e04 # Parent ed800095162c2d459ba6bdd651ef6f246858c458 libxl: use IDL to define device front- and back-end kinds I'd like to use the from_string functionality... Signed-off-by: Ian Campbell <ian.campbell@citrix.com> diff -r ed800095162c -r e8cff01ad4b5 tools/libxl/libxl.c --- a/tools/libxl/libxl.c Fri Sep 30 14:27:27 2011 +0100 +++ b/tools/libxl/libxl.c Fri Sep 30 14:27:28 2011 +0100 @@ -959,7 +959,7 @@ int libxl_device_disk_add(libxl_ctx *ctx device.backend_domid = disk->backend_domid; device.devid = devid; device.domid = domid; - device.kind = DEVICE_VBD; + device.kind = LIBXL__DEVICE_KIND_VBD; switch (disk->backend) { case LIBXL_DISK_BACKEND_PHY: @@ -972,7 +972,7 @@ int libxl_device_disk_add(libxl_ctx *ctx flexarray_append(back, "params"); flexarray_append(back, dev); - device.backend_kind = DEVICE_VBD; + device.backend_kind = LIBXL__DEVICE_KIND_VBD; break; case LIBXL_DISK_BACKEND_TAP: dev = libxl__blktap_devpath(&gc, disk->pdev_path, disk->format); @@ -991,7 +991,7 @@ int libxl_device_disk_add(libxl_ctx *ctx flexarray_append(back, "params"); flexarray_append(back, libxl__sprintf(&gc, "%s:%s", libxl__device_disk_string_of_format(disk->format), disk->pdev_path)); - device.backend_kind = DEVICE_QDISK; + device.backend_kind = LIBXL__DEVICE_KIND_QDISK; break; default: LIBXL__LOG(ctx, LIBXL__LOG_ERROR, "unrecognized disk backend type: %d\n", disk->backend); @@ -1054,13 +1054,13 @@ int libxl_device_disk_del(libxl_ctx *ctx switch (disk->backend) { case LIBXL_DISK_BACKEND_PHY: - device.backend_kind = DEVICE_VBD; + device.backend_kind = LIBXL__DEVICE_KIND_VBD; break; case LIBXL_DISK_BACKEND_TAP: - device.backend_kind = DEVICE_VBD; + device.backend_kind = LIBXL__DEVICE_KIND_VBD; break; case LIBXL_DISK_BACKEND_QDISK: - device.backend_kind = DEVICE_QDISK; + device.backend_kind = LIBXL__DEVICE_KIND_QDISK; break; default: LIBXL__LOG(ctx, LIBXL__LOG_ERROR, "unrecognized disk backend type: %d\n", @@ -1070,7 +1070,7 @@ int libxl_device_disk_del(libxl_ctx *ctx } device.domid = domid; device.devid = devid; - device.kind = DEVICE_VBD; + device.kind = LIBXL__DEVICE_KIND_VBD; if (wait) rc = libxl__device_del(&gc, &device); else @@ -1218,10 +1218,10 @@ int libxl_device_nic_add(libxl_ctx *ctx, device.backend_devid = nic->devid; device.backend_domid = nic->backend_domid; - device.backend_kind = DEVICE_VIF; + device.backend_kind = LIBXL__DEVICE_KIND_VIF; device.devid = nic->devid; device.domid = domid; - device.kind = DEVICE_VIF; + device.kind = LIBXL__DEVICE_KIND_VIF; flexarray_append(back, "frontend-id"); flexarray_append(back, libxl__sprintf(&gc, "%d", domid)); @@ -1281,10 +1281,10 @@ int libxl_device_nic_del(libxl_ctx *ctx, device.backend_devid = nic->devid; device.backend_domid = nic->backend_domid; - device.backend_kind = DEVICE_VIF; + device.backend_kind = LIBXL__DEVICE_KIND_VIF; device.devid = nic->devid; device.domid = domid; - device.kind = DEVICE_VIF; + device.kind = LIBXL__DEVICE_KIND_VIF; if (wait) rc = libxl__device_del(&gc, &device); @@ -1483,10 +1483,10 @@ int libxl__device_console_add(libxl__gc device.backend_devid = console->devid; device.backend_domid = console->backend_domid; - device.backend_kind = DEVICE_CONSOLE; + device.backend_kind = LIBXL__DEVICE_KIND_CONSOLE; device.devid = console->devid; device.domid = domid; - device.kind = DEVICE_CONSOLE; + device.kind = LIBXL__DEVICE_KIND_CONSOLE; flexarray_append(back, "frontend-id"); flexarray_append(back, libxl__sprintf(gc, "%d", domid)); @@ -1574,10 +1574,10 @@ int libxl_device_vkb_add(libxl_ctx *ctx, device.backend_devid = vkb->devid; device.backend_domid = vkb->backend_domid; - device.backend_kind = DEVICE_VKBD; + device.backend_kind = LIBXL__DEVICE_KIND_VKBD; device.devid = vkb->devid; device.domid = domid; - device.kind = DEVICE_VKBD; + device.kind = LIBXL__DEVICE_KIND_VKBD; flexarray_append(back, "frontend-id"); flexarray_append(back, libxl__sprintf(&gc, "%d", domid)); @@ -1861,10 +1861,10 @@ int libxl_device_vfb_add(libxl_ctx *ctx, device.backend_devid = vfb->devid; device.backend_domid = vfb->backend_domid; - device.backend_kind = DEVICE_VFB; + device.backend_kind = LIBXL__DEVICE_KIND_VFB; device.devid = vfb->devid; device.domid = domid; - device.kind = DEVICE_VFB; + device.kind = LIBXL__DEVICE_KIND_VFB; flexarray_append_pair(back, "frontend-id", libxl__sprintf(&gc, "%d", domid)); flexarray_append_pair(back, "online", "1"); diff -r ed800095162c -r e8cff01ad4b5 tools/libxl/libxl_device.c --- a/tools/libxl/libxl_device.c Fri Sep 30 14:27:27 2011 +0100 +++ b/tools/libxl/libxl_device.c Fri Sep 30 14:27:28 2011 +0100 @@ -24,30 +24,20 @@ #include <unistd.h> #include <fcntl.h> - #include "libxl.h" #include "libxl_internal.h" -static const char *string_of_kinds[] = { - [DEVICE_VIF] = "vif", - [DEVICE_VBD] = "vbd", - [DEVICE_QDISK] = "qdisk", - [DEVICE_PCI] = "pci", - [DEVICE_VFB] = "vfb", - [DEVICE_VKBD] = "vkbd", - [DEVICE_CONSOLE] = "console", -}; - char *libxl__device_frontend_path(libxl__gc *gc, libxl__device *device) { char *dom_path = libxl__xs_get_dompath(gc, device->domid); /* Console 0 is a special case */ - if (device->kind == DEVICE_CONSOLE && device->devid == 0) + if (device->kind == LIBXL__DEVICE_KIND_CONSOLE && device->devid == 0) return libxl__sprintf(gc, "%s/console", dom_path); return libxl__sprintf(gc, "%s/device/%s/%d", dom_path, - string_of_kinds[device->kind], device->devid); + libxl__device_kind_to_string(device->kind), + device->devid); } char *libxl__device_backend_path(libxl__gc *gc, libxl__device *device) @@ -55,7 +45,7 @@ char *libxl__device_backend_path(libxl__ char *dom_path = libxl__xs_get_dompath(gc, device->backend_domid); return libxl__sprintf(gc, "%s/backend/%s/%u/%d", dom_path, - string_of_kinds[device->backend_kind], + libxl__device_kind_to_string(device->backend_kind), device->domid, device->devid); } @@ -67,12 +57,6 @@ int libxl__device_generic_add(libxl__gc xs_transaction_t t; struct xs_permissions frontend_perms[2]; struct xs_permissions backend_perms[2]; - int rc; - - if (!is_valid_device_kind(device->backend_kind) || !is_valid_device_kind(device->kind)) { - rc = ERROR_INVAL; - goto out; - } frontend_path = libxl__device_frontend_path(gc, device); backend_path = libxl__device_backend_path(gc, device); @@ -113,9 +97,8 @@ retry_transaction: else LIBXL__LOG_ERRNO(ctx, LIBXL__LOG_ERROR, "xs transaction failed"); } - rc = 0; -out: - return rc; + + return 0; } typedef struct { diff -r ed800095162c -r e8cff01ad4b5 tools/libxl/libxl_internal.h --- a/tools/libxl/libxl_internal.h Fri Sep 30 14:27:27 2011 +0100 +++ b/tools/libxl/libxl_internal.h Fri Sep 30 14:27:28 2011 +0100 @@ -97,25 +97,13 @@ struct libxl__ctx { libxl_version_info version_info; }; -typedef enum { - DEVICE_VIF = 1, - DEVICE_VBD, - DEVICE_QDISK, - DEVICE_PCI, - DEVICE_VFB, - DEVICE_VKBD, - DEVICE_CONSOLE, -} libxl__device_kinds; - -#define is_valid_device_kind(kind) (((kind) >= DEVICE_VIF) && ((kind) <= DEVICE_CONSOLE)) - typedef struct { uint32_t backend_devid; uint32_t backend_domid; uint32_t devid; uint32_t domid; - libxl__device_kinds backend_kind; - libxl__device_kinds kind; + libxl__device_kind backend_kind; + libxl__device_kind kind; } libxl__device; #define XC_PCI_BDF "0x%x, 0x%x, 0x%x, 0x%x" diff -r ed800095162c -r e8cff01ad4b5 tools/libxl/libxl_pci.c --- a/tools/libxl/libxl_pci.c Fri Sep 30 14:27:27 2011 +0100 +++ b/tools/libxl/libxl_pci.c Fri Sep 30 14:27:28 2011 +0100 @@ -244,10 +244,10 @@ int libxl__create_pci_backend(libxl__gc /* add pci device */ device.backend_devid = 0; device.backend_domid = 0; - device.backend_kind = DEVICE_PCI; + device.backend_kind = LIBXL__DEVICE_KIND_PCI; device.devid = 0; device.domid = domid; - device.kind = DEVICE_PCI; + device.kind = LIBXL__DEVICE_KIND_PCI; flexarray_append_pair(back, "frontend-id", libxl__sprintf(gc, "%d", domid)); flexarray_append_pair(back, "online", "1"); diff -r ed800095162c -r e8cff01ad4b5 tools/libxl/libxl_types_internal.idl --- a/tools/libxl/libxl_types_internal.idl Fri Sep 30 14:27:27 2011 +0100 +++ b/tools/libxl/libxl_types_internal.idl Fri Sep 30 14:27:28 2011 +0100 @@ -1,9 +1,19 @@ namespace("libxl__") -libxl__qmp_message_type = Enumeration("qmp_message_type", [ +libxl__qmp_message_type = Enumeration("qmp_message_type", [ (1, "QMP"), (2, "return"), (3, "error"), (4, "event"), (5, "invalid"), ]) + +libxl__device_kind = Enumeration("device_kind", [ + (1, "VIF"), + (2, "VBD"), + (3, "QDISK"), + (4, "PCI"), + (5, "VFB"), + (6, "VKBD"), + (7, "CONSOLE"), + ]) _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel From xen-devel-bounces@lists.xensource.com Fri Sep 30 06:46:27 2011 Return-path: <xen-devel-bounces@lists.xensource.com> Envelope-to: www-data@lists.xensource.com Delivery-date: Fri, 30 Sep 2011 06:46:27 -0700 Received: from localhost ([127.0.0.1] helo=lists.colo.xensource.com) by lists.xensource.com with esmtp (Exim 4.43) id 1R9dQ3-0004og-Gd; Fri, 30 Sep 2011 06:46:27 -0700 Received: from mail216.messagelabs.com ([85.158.143.99]) by lists.xensource.com with esmtp (Exim 4.43) id 1R9dDc-0008KI-OT for xen-devel@lists.xensource.com; Fri, 30 Sep 2011 06:33:37 -0700 X-Env-Sender: Ian.Campbell@eu.citrix.com X-Msg-Ref: server-12.tower-216.messagelabs.com!1317389612!14404902!1 X-Originating-IP: [66.165.176.89] X-StarScan-Version: 6.4.1; banners=-,-,- X-VirusChecked: Checked Received: (qmail 22860 invoked from network); 30 Sep 2011 13:33:33 -0000 Received: from smtp.citrix.com (HELO SMTP.CITRIX.COM) (66.165.176.89) by server-12.tower-216.messagelabs.com with RC4-SHA encrypted SMTP; 30 Sep 2011 13:33:33 -0000 X-IronPort-AV: E=Sophos;i="4.68,467,1312171200"; d="scan'208";a="17841093" Received: from ftlpmailmx01.citrite.net ([10.13.107.65]) by FTLPIPO01.CITRIX.COM with ESMTP/TLS/RC4-MD5; 30 Sep 2011 09:33:27 -0400 Received: from smtp01.ad.xensource.com (10.219.128.104) by smtprelay.citrix.com (10.13.107.65) with Microsoft SMTP Server id 8.3.137.0; Fri, 30 Sep 2011 09:33:26 -0400 Received: from localhost.localdomain (cosworth.uk.xensource.com [10.80.16.52]) by smtp01.ad.xensource.com (8.13.1/8.13.1) with ESMTP id p8UDXFZM029198; Fri, 30 Sep 2011 06:33:25 -0700 Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Mercurial-Node: e65e18b230493e7886654d30838ce74407c36168 Message-ID: <e65e18b230493e788665.1317389600@localhost.localdomain> In-Reply-To: <patchbomb.1317389593@localhost.localdomain> References: <patchbomb.1317389593@localhost.localdomain> User-Agent: Mercurial-patchbomb/1.6.4 Date: Fri, 30 Sep 2011 14:33:20 +0100 From: Ian Campbell <ian.campbell@citrix.com> To: xen-devel@lists.xensource.com Cc: Jim Fehlig <jfehlig@novell.com>, Mike McClurg <mike.mcclurg@citrix.com>, Dave Scott <Dave.Scott@eu.citrix.com>, Jonathan Ludlam <Jonathan.Ludlam@eu.citrix.com> Subject: [Xen-devel] [PATCH 07 of 23] libxl: reimplement devid->nic in terms of from_xs_be function X-BeenThere: xen-devel@lists.xensource.com X-Mailman-Version: 2.1.5 Precedence: list List-Id: Xen developer discussion <xen-devel.lists.xensource.com> List-Unsubscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe> List-Post: <mailto:xen-devel@lists.xensource.com> List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help> List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=subscribe> Sender: xen-devel-bounces@lists.xensource.com Errors-To: xen-devel-bounces@lists.xensource.com # HG changeset patch # User Ian Campbell <ian.campbell@citrix.com> # Date 1317389247 -3600 # Node ID e65e18b230493e7886654d30838ce74407c36168 # Parent cafd8b3f9e0c8bbf5c30cfcd512c1486661ca4d9 libxl: reimplement devid->nic in terms of from_xs_be function. Signed-off-by: Ian Campbell <ian.campbell@citrix.com> diff -r cafd8b3f9e0c -r e65e18b23049 tools/libxl/libxl.c --- a/tools/libxl/libxl.c Fri Sep 30 14:27:27 2011 +0100 +++ b/tools/libxl/libxl.c Fri Sep 30 14:27:27 2011 +0100 @@ -1312,7 +1312,7 @@ static void libxl__device_nic_from_xs_be libxl__sprintf(gc, "%s/mac", be_path), &len); rc = libxl__parse_mac(tmp, nic->mac); if (rc) - memset(nic->mac, 0, sizeof(nic->mac)); + memset(nic->mac, 0, sizeof(nic->mac)); nic->ip = xs_read(ctx->xsh, XBT_NULL, libxl__sprintf(gc, "%s/ip", be_path), &len); @@ -1329,6 +1329,32 @@ static void libxl__device_nic_from_xs_be nic->ifname = NULL; /* XXX Only for TYPE_IOEMU */ } +int libxl_devid_to_device_nic(libxl_ctx *ctx, uint32_t domid, + const char *devid, libxl_device_nic *nic) +{ + libxl__gc gc = LIBXL_INIT_GC(ctx); + char *dompath, *path; + int rc = ERROR_FAIL; + + memset(nic, 0, sizeof (libxl_device_nic)); + dompath = libxl__xs_get_dompath(&gc, domid); + if (!dompath) + goto out; + + path = libxl__xs_read(&gc, XBT_NULL, + libxl__sprintf(&gc, "%s/device/vif/%s/backend", + dompath, devid)); + if (!path) + goto out; + + libxl__device_nic_from_xs_be(&gc, path, nic); + + rc = 0; +out: + libxl__free_all(&gc); + return rc; +} + static int libxl__append_nic_list_of_type(libxl__gc *gc, uint32_t domid, const char *type, diff -r cafd8b3f9e0c -r e65e18b23049 tools/libxl/libxl_utils.c --- a/tools/libxl/libxl_utils.c Fri Sep 30 14:27:27 2011 +0100 +++ b/tools/libxl/libxl_utils.c Fri Sep 30 14:27:27 2011 +0100 @@ -483,41 +483,6 @@ int libxl_mac_to_device_nic(libxl_ctx *c return rc; } -int libxl_devid_to_device_nic(libxl_ctx *ctx, uint32_t domid, - const char *devid, libxl_device_nic *nic) -{ - libxl__gc gc = LIBXL_INIT_GC(ctx); - char *val; - char *dompath, *nic_path_fe, *nic_path_be; - int rc = ERROR_FAIL; - - memset(nic, 0, sizeof (libxl_device_nic)); - dompath = libxl__xs_get_dompath(&gc, domid); - if (!dompath) { - goto out; - } - nic_path_fe = libxl__sprintf(&gc, "%s/device/vif/%s", dompath, devid); - nic_path_be = libxl__xs_read(&gc, XBT_NULL, - libxl__sprintf(&gc, "%s/backend", nic_path_fe)); - val = libxl__xs_read(&gc, XBT_NULL, libxl__sprintf(&gc, "%s/backend-id", nic_path_fe)); - if ( NULL == val ) { - goto out; - } - nic->backend_domid = strtoul(val, NULL, 10); - nic->devid = strtoul(devid, NULL, 10); - - val = libxl__xs_read(&gc, XBT_NULL, libxl__sprintf(&gc, "%s/mac", nic_path_fe)); - rc = libxl__parse_mac(val, nic->mac); - if (rc) - goto out; - - nic->script = xs_read(ctx->xsh, XBT_NULL, libxl__sprintf(&gc, "%s/script", nic_path_be), NULL); - rc = 0; -out: - libxl__free_all(&gc); - return rc; -} - int libxl_devid_to_device_disk(libxl_ctx *ctx, uint32_t domid, const char *devid, libxl_device_disk *disk) { _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel From xen-devel-bounces@lists.xensource.com Fri Sep 30 06:47:14 2011 Return-path: <xen-devel-bounces@lists.xensource.com> Envelope-to: www-data@lists.xensource.com Delivery-date: Fri, 30 Sep 2011 06:47:14 -0700 Received: from localhost ([127.0.0.1] helo=lists.colo.xensource.com) by lists.xensource.com with esmtp (Exim 4.43) id 1R9dQo-0005BU-GG; Fri, 30 Sep 2011 06:47:14 -0700 Received: from mail216.messagelabs.com ([85.158.143.99]) by lists.xensource.com with esmtp (Exim 4.43) id 1R9dDd-0008KL-7j for xen-devel@lists.xensource.com; Fri, 30 Sep 2011 06:33:37 -0700 X-Env-Sender: Ian.Campbell@eu.citrix.com X-Msg-Ref: server-12.tower-216.messagelabs.com!1317389612!14404902!2 X-Originating-IP: [66.165.176.89] X-StarScan-Version: 6.4.1; banners=-,-,- X-VirusChecked: Checked Received: (qmail 22882 invoked from network); 30 Sep 2011 13:33:34 -0000 Received: from smtp.citrix.com (HELO SMTP.CITRIX.COM) (66.165.176.89) by server-12.tower-216.messagelabs.com with RC4-SHA encrypted SMTP; 30 Sep 2011 13:33:34 -0000 X-IronPort-AV: E=Sophos;i="4.68,467,1312171200"; d="scan'208";a="17841095" Received: from ftlpmailmx01.citrite.net ([10.13.107.65]) by FTLPIPO01.CITRIX.COM with ESMTP/TLS/RC4-MD5; 30 Sep 2011 09:33:30 -0400 Received: from smtp01.ad.xensource.com (10.219.128.104) by smtprelay.citrix.com (10.13.107.65) with Microsoft SMTP Server id 8.3.137.0; Fri, 30 Sep 2011 09:33:30 -0400 Received: from localhost.localdomain (cosworth.uk.xensource.com [10.80.16.52]) by smtp01.ad.xensource.com (8.13.1/8.13.1) with ESMTP id p8UDXFZP029198; Fri, 30 Sep 2011 06:33:29 -0700 Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Mercurial-Node: dd195d45be273cf85ef0a614ac69b4498bac6d10 Message-ID: <dd195d45be273cf85ef0.1317389603@localhost.localdomain> In-Reply-To: <patchbomb.1317389593@localhost.localdomain> References: <patchbomb.1317389593@localhost.localdomain> User-Agent: Mercurial-patchbomb/1.6.4 Date: Fri, 30 Sep 2011 14:33:23 +0100 From: Ian Campbell <ian.campbell@citrix.com> To: xen-devel@lists.xensource.com Cc: Jim Fehlig <jfehlig@novell.com>, Mike McClurg <mike.mcclurg@citrix.com>, Dave Scott <Dave.Scott@eu.citrix.com>, Jonathan Ludlam <Jonathan.Ludlam@eu.citrix.com> Subject: [Xen-devel] [PATCH 10 of 23] libxl: separate forced and non-forced device remove X-BeenThere: xen-devel@lists.xensource.com X-Mailman-Version: 2.1.5 Precedence: list List-Id: Xen developer discussion <xen-devel.lists.xensource.com> List-Unsubscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe> List-Post: <mailto:xen-devel@lists.xensource.com> List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help> List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=subscribe> Sender: xen-devel-bounces@lists.xensource.com Errors-To: xen-devel-bounces@lists.xensource.com # HG changeset patch # User Ian Campbell <ian.campbell@citrix.com> # Date 1317389247 -3600 # Node ID dd195d45be273cf85ef0a614ac69b4498bac6d10 # Parent cefb64e94c5e47858ebe2d76d2448da3d9caa7fb libxl: separate forced and non-forced device remove. The function libxl__device_destroy currently takes a force parameter however: * in the forced case we initiate a graceful shutdown and then immediately nuke the backend directory, quite likely before anyone got a chance to react. * the callers all have a "wait" variable and pass in "!wait" as the force argument which is confusing since not waiting is not really the same thing as forcing the destroy. * the term "destroy" is normally used in libxl for data-type destructors. Therefore split the function into libxl__device_remove and libxl__device_force_remove. The latter simply nukes the backend directory. This makes some of the callers look a bit odd but that should fall out as I continue to pull this piece of string. Signed-off-by: Ian Campbell <ian.campbell@citrix.com> diff -r cefb64e94c5e -r dd195d45be27 tools/libxl/libxl_device.c --- a/tools/libxl/libxl_device.c Fri Sep 30 14:27:27 2011 +0100 +++ b/tools/libxl/libxl_device.c Fri Sep 30 14:27:27 2011 +0100 @@ -365,7 +365,7 @@ int libxl__device_disk_dev_number(const return -1; } -int libxl__device_destroy(libxl__gc *gc, char *be_path, int force) +int libxl__device_remove(libxl__gc *gc, char *be_path) { libxl_ctx *ctx = libxl__gc_owner(gc); xs_transaction_t t; @@ -393,17 +393,22 @@ retry_transaction: goto out; } } - if (!force) { - xs_watch(ctx->xsh, state_path, be_path); - rc = 1; - } else { - xs_rm(ctx->xsh, XBT_NULL, be_path); - } + + xs_watch(ctx->xsh, state_path, be_path); libxl__device_destroy_tapdisk(gc, be_path); + rc = 1; out: return rc; } +int libxl__device_force_remove(libxl__gc *gc, char *be_path) +{ + libxl_ctx *ctx = libxl__gc_owner(gc); + xs_rm(ctx->xsh, XBT_NULL, be_path); + libxl__device_destroy_tapdisk(gc, be_path); + return 0; +} + static int wait_for_dev_destroy(libxl__gc *gc, struct timeval *tv) { libxl_ctx *ctx = libxl__gc_owner(gc); @@ -461,7 +466,9 @@ int libxl__devices_destroy(libxl__gc *gc fe_path = libxl__sprintf(gc, "/local/domain/%d/device/%s/%s", domid, l1[i], l2[j]); be_path = libxl__xs_read(gc, XBT_NULL, libxl__sprintf(gc, "%s/backend", fe_path)); if (be_path != NULL) { - if (libxl__device_destroy(gc, be_path, force) > 0) + int rc = force ? libxl__device_force_remove(gc, be_path) + : libxl__device_remove(gc, be_path); + if (rc > 0) n_watches++; } else { xs_rm(ctx->xsh, XBT_NULL, path); @@ -473,7 +480,9 @@ int libxl__devices_destroy(libxl__gc *gc fe_path = libxl__sprintf(gc, "/local/domain/%d/console", domid); be_path = libxl__xs_read(gc, XBT_NULL, libxl__sprintf(gc, "%s/backend", fe_path)); if (be_path && strcmp(be_path, "")) { - if (libxl__device_destroy(gc, be_path, force) > 0) + int rc = force ? libxl__device_force_remove(gc, be_path) + : libxl__device_remove(gc, be_path); + if (rc > 0) n_watches++; } @@ -506,7 +515,10 @@ int libxl__device_del(libxl__gc *gc, lib backend_path = libxl__device_backend_path(gc, dev); - rc = libxl__device_destroy(gc, backend_path, !wait); + if (wait) + rc = libxl__device_remove(gc, backend_path); + else + rc = libxl__device_force_remove(gc, backend_path); if (rc == -1) { rc = ERROR_FAIL; goto out; diff -r cefb64e94c5e -r dd195d45be27 tools/libxl/libxl_internal.h --- a/tools/libxl/libxl_internal.h Fri Sep 30 14:27:27 2011 +0100 +++ b/tools/libxl/libxl_internal.h Fri Sep 30 14:27:27 2011 +0100 @@ -253,7 +253,8 @@ _hidden int libxl__device_generic_add(li _hidden char *libxl__device_backend_path(libxl__gc *gc, libxl__device *device); _hidden char *libxl__device_frontend_path(libxl__gc *gc, libxl__device *device); _hidden int libxl__device_del(libxl__gc *gc, libxl__device *dev, int wait); -_hidden int libxl__device_destroy(libxl__gc *gc, char *be_path, int force); +_hidden int libxl__device_remove(libxl__gc *gc, char *be_path); +_hidden int libxl__device_force_remove(libxl__gc *gc, char *be_path); _hidden int libxl__devices_destroy(libxl__gc *gc, uint32_t domid, int force); _hidden int libxl__wait_for_backend(libxl__gc *gc, char *be_path, char *state); diff -r cefb64e94c5e -r dd195d45be27 tools/libxl/libxl_pci.c --- a/tools/libxl/libxl_pci.c Fri Sep 30 14:27:27 2011 +0100 +++ b/tools/libxl/libxl_pci.c Fri Sep 30 14:27:27 2011 +0100 @@ -411,8 +411,7 @@ retry_transaction2: if (num == 1) { char *fe_path = libxl__xs_read(gc, XBT_NULL, libxl__sprintf(gc, "%s/frontend", be_path)); - libxl__device_destroy(gc, be_path, 1); - xs_rm(ctx->xsh, XBT_NULL, be_path); + libxl__device_force_remove(gc, be_path); xs_rm(ctx->xsh, XBT_NULL, fe_path); return 0; } _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel From xen-devel-bounces@lists.xensource.com Fri Sep 30 06:48:05 2011 Return-path: <xen-devel-bounces@lists.xensource.com> Envelope-to: www-data@lists.xensource.com Delivery-date: Fri, 30 Sep 2011 06:48:05 -0700 Received: from localhost ([127.0.0.1] helo=lists.colo.xensource.com) by lists.xensource.com with esmtp (Exim 4.43) id 1R9dRd-0005Y5-BV; Fri, 30 Sep 2011 06:48:05 -0700 Received: from mail27.messagelabs.com ([193.109.254.147]) by lists.xensource.com with esmtp (Exim 4.43) id 1R9dDc-0008KF-Md for xen-devel@lists.xensource.com; Fri, 30 Sep 2011 06:33:38 -0700 X-Env-Sender: Ian.Campbell@eu.citrix.com X-Msg-Ref: server-4.tower-27.messagelabs.com!1317389591!42442687!4 X-Originating-IP: [66.165.176.89] X-StarScan-Version: 6.4.1; banners=-,-,- X-VirusChecked: Checked Received: (qmail 31067 invoked from network); 30 Sep 2011 13:33:14 -0000 Received: from smtp.citrix.com (HELO SMTP.CITRIX.COM) (66.165.176.89) by server-4.tower-27.messagelabs.com with RC4-SHA encrypted SMTP; 30 Sep 2011 13:33:14 -0000 X-IronPort-AV: E=Sophos;i="4.68,467,1312171200"; d="scan'208";a="17841091" Received: from ftlpmailmx01.citrite.net ([10.13.107.65]) by FTLPIPO01.CITRIX.COM with ESMTP/TLS/RC4-MD5; 30 Sep 2011 09:33:22 -0400 Received: from smtp01.ad.xensource.com (10.219.128.104) by smtprelay.citrix.com (10.13.107.65) with Microsoft SMTP Server id 8.3.137.0; Fri, 30 Sep 2011 09:33:21 -0400 Received: from localhost.localdomain (cosworth.uk.xensource.com [10.80.16.52]) by smtp01.ad.xensource.com (8.13.1/8.13.1) with ESMTP id p8UDXFZI029198; Fri, 30 Sep 2011 06:33:20 -0700 Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Mercurial-Node: 9fdae058b42c9a8981599d96e1de3131997e7b64 Message-ID: <9fdae058b42c9a898159.1317389596@localhost.localdomain> In-Reply-To: <patchbomb.1317389593@localhost.localdomain> References: <patchbomb.1317389593@localhost.localdomain> User-Agent: Mercurial-patchbomb/1.6.4 Date: Fri, 30 Sep 2011 14:33:16 +0100 From: Ian Campbell <ian.campbell@citrix.com> To: xen-devel@lists.xensource.com Cc: Jim Fehlig <jfehlig@novell.com>, Mike McClurg <mike.mcclurg@citrix.com>, Dave Scott <Dave.Scott@eu.citrix.com>, Jonathan Ludlam <Jonathan.Ludlam@eu.citrix.com> Subject: [Xen-devel] [PATCH 03 of 23] libxl: various fixes to libxl_device_disk_list (and internals) X-BeenThere: xen-devel@lists.xensource.com X-Mailman-Version: 2.1.5 Precedence: list List-Id: Xen developer discussion <xen-devel.lists.xensource.com> List-Unsubscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe> List-Post: <mailto:xen-devel@lists.xensource.com> List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help> List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=subscribe> Sender: xen-devel-bounces@lists.xensource.com Errors-To: xen-devel-bounces@lists.xensource.com # HG changeset patch # User Ian Campbell <ian.campbell@citrix.com> # Date 1317389247 -3600 # Node ID 9fdae058b42c9a8981599d96e1de3131997e7b64 # Parent 7c845e974def74de73f67123f39d6fd2769082e9 libxl: various fixes to libxl_device_disk_list (and internals) - handle realloc errors - remove redundancy of libxl__append_disk_list_of_type return value and ndisks paramter. Signed-off-by: Ian Campbell <ian.campbell@citrix.com> diff -r 7c845e974def -r 9fdae058b42c tools/libxl/libxl.c --- a/tools/libxl/libxl.c Fri Sep 30 14:27:27 2011 +0100 +++ b/tools/libxl/libxl.c Fri Sep 30 14:27:27 2011 +0100 @@ -1502,11 +1502,11 @@ int libxl_device_vkb_hard_shutdown(libxl return ERROR_NI; } -static unsigned int libxl__append_disk_list_of_type(libxl__gc *gc, - uint32_t domid, - const char *type, - libxl_device_disk **disks, - unsigned int *ndisks) +static int libxl__append_disk_list_of_type(libxl__gc *gc, + uint32_t domid, + const char *type, + libxl_device_disk **disks, + int *ndisks) { libxl_ctx *ctx = libxl__gc_owner(gc); char *be_path = NULL; @@ -1520,11 +1520,16 @@ static unsigned int libxl__append_disk_l dir = libxl__xs_directory(gc, XBT_NULL, be_path, &n); if (dir) { char *removable; - *disks = realloc(*disks, sizeof (libxl_device_disk) * (*ndisks + n)); + libxl_device_disk *tmp; + tmp = realloc(*disks, sizeof (libxl_device_disk) * (*ndisks + n)); + if (tmp == NULL) + return ERROR_NOMEM; + *disks = tmp; pdisk = *disks + *ndisks; *ndisks += n; pdisk_end = *disks + *ndisks; for (; pdisk < pdisk_end; pdisk++, dir++) { + memset(pdisk, 0, sizeof(*pdisk)); pdisk->backend_domid = 0; physpath_tmp = xs_read(ctx->xsh, XBT_NULL, libxl__sprintf(gc, "%s/%s/params", be_path, *dir), &len); if (physpath_tmp && strchr(physpath_tmp, ':')) { @@ -1552,22 +1557,37 @@ static unsigned int libxl__append_disk_l pdisk->format = LIBXL_DISK_FORMAT_UNKNOWN; } } - - return n; + return 0; } libxl_device_disk *libxl_device_disk_list(libxl_ctx *ctx, uint32_t domid, int *num) { libxl__gc gc = LIBXL_INIT_GC(ctx); libxl_device_disk *disks = NULL; - unsigned int ndisks = 0; - - *num = libxl__append_disk_list_of_type(&gc, domid, "vbd", &disks, &ndisks); - *num += libxl__append_disk_list_of_type(&gc, domid, "tap", &disks, &ndisks); - *num += libxl__append_disk_list_of_type(&gc, domid, "qdisk", &disks, &ndisks); + int rc; + + *num = 0; + + rc = libxl__append_disk_list_of_type(&gc, domid, "vbd", &disks, num); + if (rc) goto out_err; + + rc = libxl__append_disk_list_of_type(&gc, domid, "tap", &disks, num); + if (rc) goto out_err; + + rc = libxl__append_disk_list_of_type(&gc, domid, "qdisk", &disks, num); + if (rc) goto out_err; libxl__free_all(&gc); return disks; + +out_err: + LIBXL__LOG(ctx, LIBXL__LOG_ERROR, "Unable to list disks"); + while (disks && *num) { + (*num)--; + libxl_device_disk_destroy(&disks[*num]); + } + free(disks); + return NULL; } int libxl_device_disk_getinfo(libxl_ctx *ctx, uint32_t domid, _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel From xen-devel-bounces@lists.xensource.com Fri Sep 30 06:48:55 2011 Return-path: <xen-devel-bounces@lists.xensource.com> Envelope-to: www-data@lists.xensource.com Delivery-date: Fri, 30 Sep 2011 06:48:55 -0700 Received: from localhost ([127.0.0.1] helo=lists.colo.xensource.com) by lists.xensource.com with esmtp (Exim 4.43) id 1R9dSR-0005uL-01; Fri, 30 Sep 2011 06:48:55 -0700 Received: from mail21.messagelabs.com ([85.158.143.35]) by lists.xensource.com with esmtp (Exim 4.43) id 1R9dDf-0008Kp-NS for xen-devel@lists.xensource.com; Fri, 30 Sep 2011 06:33:40 -0700 X-Env-Sender: Ian.Campbell@eu.citrix.com X-Msg-Ref: server-4.tower-21.messagelabs.com!1317389561!62247725!8 X-Originating-IP: [66.165.176.63] X-StarScan-Version: 6.4.1; banners=-,-,- X-VirusChecked: Checked Received: (qmail 20909 invoked from network); 30 Sep 2011 13:32:59 -0000 Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63) by server-4.tower-21.messagelabs.com with RC4-SHA encrypted SMTP; 30 Sep 2011 13:32:59 -0000 X-IronPort-AV: E=Sophos;i="4.68,467,1312171200"; d="scan'208";a="165286997" Received: from ftlpmailmx01.citrite.net ([10.13.107.65]) by FTLPIPO02.CITRIX.COM with ESMTP/TLS/RC4-MD5; 30 Sep 2011 09:33:36 -0400 Received: from smtp01.ad.xensource.com (10.219.128.104) by smtprelay.citrix.com (10.13.107.65) with Microsoft SMTP Server id 8.3.137.0; Fri, 30 Sep 2011 09:33:35 -0400 Received: from localhost.localdomain (cosworth.uk.xensource.com [10.80.16.52]) by smtp01.ad.xensource.com (8.13.1/8.13.1) with ESMTP id p8UDXFZT029198; Fri, 30 Sep 2011 06:33:34 -0700 Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Mercurial-Node: ec28ee6dace513c3d009d498341f9537a19b2d98 Message-ID: <ec28ee6dace513c3d009.1317389607@localhost.localdomain> In-Reply-To: <patchbomb.1317389593@localhost.localdomain> References: <patchbomb.1317389593@localhost.localdomain> User-Agent: Mercurial-patchbomb/1.6.4 Date: Fri, 30 Sep 2011 14:33:27 +0100 From: Ian Campbell <ian.campbell@citrix.com> To: xen-devel@lists.xensource.com Cc: Jim Fehlig <jfehlig@novell.com>, Mike McClurg <mike.mcclurg@citrix.com>, Dave Scott <Dave.Scott@eu.citrix.com>, Jonathan Ludlam <Jonathan.Ludlam@eu.citrix.com> Subject: [Xen-devel] [PATCH 14 of 23] libxl: use libxl__device in libxl_devices_destroy and libxl__device_pci_remove_xenstore X-BeenThere: xen-devel@lists.xensource.com X-Mailman-Version: 2.1.5 Precedence: list List-Id: Xen developer discussion <xen-devel.lists.xensource.com> List-Unsubscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe> List-Post: <mailto:xen-devel@lists.xensource.com> List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help> List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=subscribe> Sender: xen-devel-bounces@lists.xensource.com Errors-To: xen-devel-bounces@lists.xensource.com # HG changeset patch # User Ian Campbell <ian.campbell@citrix.com> # Date 1317389248 -3600 # Node ID ec28ee6dace513c3d009d498341f9537a19b2d98 # Parent e5a70a3b61a1acfa7d73db548a591486024d01b7 libxl: use libxl__device in libxl_devices_destroy and libxl__device_pci_remove_xenstore Doing this allows us to use the common functions for removing devices. Signed-off-by: Ian Campbell <ian.campbell@citrix.com> diff -r e5a70a3b61a1 -r ec28ee6dace5 tools/libxl/libxl_device.c --- a/tools/libxl/libxl_device.c Fri Sep 30 14:27:28 2011 +0100 +++ b/tools/libxl/libxl_device.c Fri Sep 30 14:27:28 2011 +0100 @@ -49,6 +49,25 @@ char *libxl__device_backend_path(libxl__ device->domid, device->devid); } +int libxl__parse_backend_path(libxl__gc *gc, + const char *path, + libxl__device *dev) +{ + /* /local/domain/<domid>/backend/<kind>/<domid>/<devid> */ + char strkind[16]; /* Longest is actually "console" */ + uint32_t domain; + int rc = sscanf(path, "/local/domain/%d/backend/%15[^/]/%d/%d", + &dev->backend_domid, + strkind, + &domain, + &dev->backend_devid); + + if (rc != 4) + return ERROR_FAIL; + + return libxl__device_kind_from_string(strkind, &dev->backend_kind); +} + int libxl__device_generic_add(libxl__gc *gc, libxl__device *device, char **bents, char **fents) { @@ -348,10 +367,11 @@ int libxl__device_disk_dev_number(const return -1; } -int libxl__device_remove(libxl__gc *gc, char *be_path) +int libxl__device_remove(libxl__gc *gc, libxl__device *dev) { libxl_ctx *ctx = libxl__gc_owner(gc); xs_transaction_t t; + char *be_path = libxl__device_backend_path(gc, dev); char *state_path = libxl__sprintf(gc, "%s/state", be_path); char *state = libxl__xs_read(gc, XBT_NULL, state_path); int rc = 0; @@ -429,10 +449,12 @@ static int wait_for_dev_destroy(libxl__g int libxl__devices_destroy(libxl__gc *gc, uint32_t domid, int force) { libxl_ctx *ctx = libxl__gc_owner(gc); - char *path, *be_path, *fe_path; + char *path; unsigned int num1, num2; char **l1 = NULL, **l2 = NULL; int i, j, n_watches = 0; + libxl__device dev; + libxl__device_kind kind; path = libxl__sprintf(gc, "/local/domain/%d/device", domid); l1 = libxl__xs_directory(gc, XBT_NULL, path, &num1); @@ -445,22 +467,27 @@ int libxl__devices_destroy(libxl__gc *gc num1 = 0; } for (i = 0; i < num1; i++) { - if (!strcmp("vfs", l1[i])) + if (libxl__device_kind_from_string(l1[i], &kind)) + continue; + if (kind == LIBXL__DEVICE_KIND_VBD) continue; path = libxl__sprintf(gc, "/local/domain/%d/device/%s", domid, l1[i]); l2 = libxl__xs_directory(gc, XBT_NULL, path, &num2); if (!l2) continue; for (j = 0; j < num2; j++) { - fe_path = libxl__sprintf(gc, "/local/domain/%d/device/%s/%s", domid, l1[i], l2[j]); - be_path = libxl__xs_read(gc, XBT_NULL, libxl__sprintf(gc, "%s/backend", fe_path)); - if (be_path != NULL) { + path = libxl__sprintf(gc, "/local/domain/%d/device/%s/%s/backend", + domid, l1[i], l2[j]); + path = libxl__xs_read(gc, XBT_NULL, libxl__sprintf(gc, path)); + if (path && libxl__parse_backend_path(gc, path, &dev) == 0) { + dev.domid = domid; + dev.kind = kind; + dev.devid = atoi(l2[j]); + if (force) { - xs_rm(ctx->xsh, XBT_NULL, be_path); - xs_rm(ctx->xsh, XBT_NULL, fe_path); - libxl__device_destroy_tapdisk(gc, be_path); + libxl__device_force_remove(gc, &dev); } else { - if (libxl__device_remove(gc, be_path) > 0) + if (libxl__device_remove(gc, &dev) > 0) n_watches++; } } @@ -468,14 +495,18 @@ int libxl__devices_destroy(libxl__gc *gc } /* console 0 frontend directory is not under /local/domain/<domid>/device */ - fe_path = libxl__sprintf(gc, "/local/domain/%d/console", domid); - be_path = libxl__xs_read(gc, XBT_NULL, libxl__sprintf(gc, "%s/backend", fe_path)); - if (be_path && strcmp(be_path, "")) { + path = libxl__sprintf(gc, "/local/domain/%d/console/backend", domid); + path = libxl__xs_read(gc, XBT_NULL, path); + if (path && strcmp(path, "") && + libxl__parse_backend_path(gc, path, &dev) == 0) { + dev.domid = domid; + dev.kind = LIBXL__DEVICE_KIND_CONSOLE; + dev.devid = 0; + if (force) { - xs_rm(ctx->xsh, XBT_NULL, be_path); - xs_rm(ctx->xsh, XBT_NULL, fe_path); + libxl__device_force_remove(gc, &dev); } else { - if (libxl__device_remove(gc, be_path) > 0) + if (libxl__device_remove(gc, &dev) > 0) n_watches++; } } @@ -505,12 +536,9 @@ int libxl__device_del(libxl__gc *gc, lib { libxl_ctx *ctx = libxl__gc_owner(gc); struct timeval tv; - char *backend_path; int rc; - backend_path = libxl__device_backend_path(gc, dev); - - rc = libxl__device_remove(gc, backend_path); + rc = libxl__device_remove(gc, dev); if (rc == -1) { rc = ERROR_FAIL; goto out; diff -r e5a70a3b61a1 -r ec28ee6dace5 tools/libxl/libxl_internal.h --- a/tools/libxl/libxl_internal.h Fri Sep 30 14:27:28 2011 +0100 +++ b/tools/libxl/libxl_internal.h Fri Sep 30 14:27:28 2011 +0100 @@ -240,8 +240,10 @@ _hidden int libxl__device_generic_add(li char **bents, char **fents); _hidden char *libxl__device_backend_path(libxl__gc *gc, libxl__device *device); _hidden char *libxl__device_frontend_path(libxl__gc *gc, libxl__device *device); +_hidden int libxl__parse_backend_path(libxl__gc *gc, const char *path, + libxl__device *dev); _hidden int libxl__device_del(libxl__gc *gc, libxl__device *dev); -_hidden int libxl__device_remove(libxl__gc *gc, char *be_path); +_hidden int libxl__device_remove(libxl__gc *gc, libxl__device *dev); _hidden int libxl__device_force_remove(libxl__gc *gc, libxl__device *dev); _hidden int libxl__devices_destroy(libxl__gc *gc, uint32_t domid, int force); _hidden int libxl__wait_for_backend(libxl__gc *gc, char *be_path, char *state); diff -r e5a70a3b61a1 -r ec28ee6dace5 tools/libxl/libxl_pci.c --- a/tools/libxl/libxl_pci.c Fri Sep 30 14:27:28 2011 +0100 +++ b/tools/libxl/libxl_pci.c Fri Sep 30 14:27:28 2011 +0100 @@ -410,9 +410,15 @@ retry_transaction2: goto retry_transaction2; if (num == 1) { - char *fe_path = libxl__xs_read(gc, XBT_NULL, libxl__sprintf(gc, "%s/frontend", be_path)); - xs_rm(ctx->xsh, XBT_NULL, be_path); - xs_rm(ctx->xsh, XBT_NULL, fe_path); + libxl__device dev; + if (libxl__parse_backend_path(gc, be_path, &dev) != 0) + return ERROR_FAIL; + + dev.domid = domid; + dev.kind = LIBXL__DEVICE_KIND_PCI; + dev.devid = 0; + + libxl__device_force_remove(gc, &dev); return 0; } _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel From xen-devel-bounces@lists.xensource.com Fri Sep 30 06:50:33 2011 Return-path: <xen-devel-bounces@lists.xensource.com> Envelope-to: www-data@lists.xensource.com Delivery-date: Fri, 30 Sep 2011 06:50:33 -0700 Received: from localhost ([127.0.0.1] helo=lists.colo.xensource.com) by lists.xensource.com with esmtp (Exim 4.43) id 1R9dU1-0006NO-3t; Fri, 30 Sep 2011 06:50:33 -0700 Received: from mail21.messagelabs.com ([85.158.143.35]) by lists.xensource.com with esmtp (Exim 4.43) id 1R9dDi-0008Lf-11 for xen-devel@lists.xensource.com; Fri, 30 Sep 2011 06:33:43 -0700 X-Env-Sender: Ian.Campbell@eu.citrix.com X-Msg-Ref: server-4.tower-21.messagelabs.com!1317389561!62247725!9 X-Originating-IP: [66.165.176.63] X-StarScan-Version: 6.4.1; banners=-,-,- X-VirusChecked: Checked Received: (qmail 21053 invoked from network); 30 Sep 2011 13:33:01 -0000 Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63) by server-4.tower-21.messagelabs.com with RC4-SHA encrypted SMTP; 30 Sep 2011 13:33:01 -0000 X-IronPort-AV: E=Sophos;i="4.68,467,1312171200"; d="scan'208";a="165287003" Received: from ftlpmailmx01.citrite.net ([10.13.107.65]) by FTLPIPO02.CITRIX.COM with ESMTP/TLS/RC4-MD5; 30 Sep 2011 09:33:38 -0400 Received: from smtp01.ad.xensource.com (10.219.128.104) by smtprelay.citrix.com (10.13.107.65) with Microsoft SMTP Server id 8.3.137.0; Fri, 30 Sep 2011 09:33:38 -0400 Received: from localhost.localdomain (cosworth.uk.xensource.com [10.80.16.52]) by smtp01.ad.xensource.com (8.13.1/8.13.1) with ESMTP id p8UDXFZV029198; Fri, 30 Sep 2011 06:33:37 -0700 Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Mercurial-Node: b3e80fe9f014f03700ca4846dde58d3473236223 Message-ID: <b3e80fe9f014f03700ca.1317389609@localhost.localdomain> In-Reply-To: <patchbomb.1317389593@localhost.localdomain> References: <patchbomb.1317389593@localhost.localdomain> User-Agent: Mercurial-patchbomb/1.6.4 Date: Fri, 30 Sep 2011 14:33:29 +0100 From: Ian Campbell <ian.campbell@citrix.com> To: xen-devel@lists.xensource.com Cc: Jim Fehlig <jfehlig@novell.com>, Mike McClurg <mike.mcclurg@citrix.com>, Dave Scott <Dave.Scott@eu.citrix.com>, Jonathan Ludlam <Jonathan.Ludlam@eu.citrix.com> Subject: [Xen-devel] [PATCH 16 of 23] libxl: use more descriptive variable names in libxl__devices_destroy X-BeenThere: xen-devel@lists.xensource.com X-Mailman-Version: 2.1.5 Precedence: list List-Id: Xen developer discussion <xen-devel.lists.xensource.com> List-Unsubscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe> List-Post: <mailto:xen-devel@lists.xensource.com> List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help> List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=subscribe> Sender: xen-devel-bounces@lists.xensource.com Errors-To: xen-devel-bounces@lists.xensource.com # HG changeset patch # User Ian Campbell <ian.campbell@citrix.com> # Date 1317389248 -3600 # Node ID b3e80fe9f014f03700ca4846dde58d3473236223 # Parent 7a8cd032b63cf91d3fe04501997405d53cf5d8b3 libxl: use more descriptive variable names in libxl__devices_destroy. It's not immediately clear that "l1" iterates over device types and "l2" iterates over individual devices. Name things in a way which makes this more obvious. Signed-off-by: Ian Campbell <ian.campbell@citrix.com> diff -r 7a8cd032b63c -r b3e80fe9f014 tools/libxl/libxl_device.c --- a/tools/libxl/libxl_device.c Fri Sep 30 14:27:28 2011 +0100 +++ b/tools/libxl/libxl_device.c Fri Sep 30 14:27:28 2011 +0100 @@ -460,39 +460,40 @@ int libxl__devices_destroy(libxl__gc *gc { libxl_ctx *ctx = libxl__gc_owner(gc); char *path; - unsigned int num1, num2; - char **l1 = NULL, **l2 = NULL; + unsigned int num_kinds, num_devs; + char **kinds = NULL, **devs = NULL; int i, j, n_watches = 0; libxl__device dev; libxl__device_kind kind; path = libxl__sprintf(gc, "/local/domain/%d/device", domid); - l1 = libxl__xs_directory(gc, XBT_NULL, path, &num1); - if (!l1) { + kinds = libxl__xs_directory(gc, XBT_NULL, path, &num_kinds); + if (!kinds) { if (errno != ENOENT) { LIBXL__LOG_ERRNO(ctx, LIBXL__LOG_ERROR, "unable to get xenstore" " device listing %s", path); goto out; } - num1 = 0; + num_kinds = 0; } - for (i = 0; i < num1; i++) { - if (libxl__device_kind_from_string(l1[i], &kind)) + for (i = 0; i < num_kinds; i++) { + if (libxl__device_kind_from_string(kinds[i], &kind)) continue; if (kind == LIBXL__DEVICE_KIND_VBD) continue; - path = libxl__sprintf(gc, "/local/domain/%d/device/%s", domid, l1[i]); - l2 = libxl__xs_directory(gc, XBT_NULL, path, &num2); - if (!l2) + + path = libxl__sprintf(gc, "/local/domain/%d/device/%s", domid, kinds[i]); + devs = libxl__xs_directory(gc, XBT_NULL, path, &num_devs); + if (!devs) continue; - for (j = 0; j < num2; j++) { + for (j = 0; j < num_devs; j++) { path = libxl__sprintf(gc, "/local/domain/%d/device/%s/%s/backend", - domid, l1[i], l2[j]); + domid, kinds[i], devs[j]); path = libxl__xs_read(gc, XBT_NULL, libxl__sprintf(gc, path)); if (path && libxl__parse_backend_path(gc, path, &dev) == 0) { dev.domid = domid; dev.kind = kind; - dev.devid = atoi(l2[j]); + dev.devid = atoi(devs[j]); if (force) { libxl__device_force_remove(gc, &dev); _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel From xen-devel-bounces@lists.xensource.com Fri Sep 30 06:51:40 2011 Return-path: <xen-devel-bounces@lists.xensource.com> Envelope-to: www-data@lists.xensource.com Delivery-date: Fri, 30 Sep 2011 06:51:40 -0700 Received: from localhost ([127.0.0.1] helo=lists.colo.xensource.com) by lists.xensource.com with esmtp (Exim 4.43) id 1R9dV5-0006lg-H8; Fri, 30 Sep 2011 06:51:39 -0700 Received: from mail27.messagelabs.com ([193.109.254.147]) by lists.xensource.com with esmtp (Exim 4.43) id 1R9dDj-0008M0-RF for xen-devel@lists.xensource.com; Fri, 30 Sep 2011 06:33:44 -0700 X-Env-Sender: Ian.Campbell@eu.citrix.com X-Msg-Ref: server-12.tower-27.messagelabs.com!1317389601!44609294!2 X-Originating-IP: [66.165.176.89] X-StarScan-Version: 6.4.1; banners=-,-,- X-VirusChecked: Checked Received: (qmail 3605 invoked from network); 30 Sep 2011 13:33:23 -0000 Received: from smtp.citrix.com (HELO SMTP.CITRIX.COM) (66.165.176.89) by server-12.tower-27.messagelabs.com with RC4-SHA encrypted SMTP; 30 Sep 2011 13:33:23 -0000 X-IronPort-AV: E=Sophos;i="4.68,467,1312171200"; d="scan'208";a="17841099" Received: from ftlpmailmx01.citrite.net ([10.13.107.65]) by FTLPIPO01.CITRIX.COM with ESMTP/TLS/RC4-MD5; 30 Sep 2011 09:33:40 -0400 Received: from smtp01.ad.xensource.com (10.219.128.104) by smtprelay.citrix.com (10.13.107.65) with Microsoft SMTP Server id 8.3.137.0; Fri, 30 Sep 2011 09:33:39 -0400 Received: from localhost.localdomain (cosworth.uk.xensource.com [10.80.16.52]) by smtp01.ad.xensource.com (8.13.1/8.13.1) with ESMTP id p8UDXFZW029198; Fri, 30 Sep 2011 06:33:38 -0700 Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Mercurial-Node: 1892dad72518f5253af2282db650cdd70c56a218 Message-ID: <1892dad72518f5253af2.1317389610@localhost.localdomain> In-Reply-To: <patchbomb.1317389593@localhost.localdomain> References: <patchbomb.1317389593@localhost.localdomain> User-Agent: Mercurial-patchbomb/1.6.4 Date: Fri, 30 Sep 2011 14:33:30 +0100 From: Ian Campbell <ian.campbell@citrix.com> To: xen-devel@lists.xensource.com Cc: Jim Fehlig <jfehlig@novell.com>, Mike McClurg <mike.mcclurg@citrix.com>, Dave Scott <Dave.Scott@eu.citrix.com>, Jonathan Ludlam <Jonathan.Ludlam@eu.citrix.com> Subject: [Xen-devel] [PATCH 17 of 23] libxl: convert disk handling to device API X-BeenThere: xen-devel@lists.xensource.com X-Mailman-Version: 2.1.5 Precedence: list List-Id: Xen developer discussion <xen-devel.lists.xensource.com> List-Unsubscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe> List-Post: <mailto:xen-devel@lists.xensource.com> List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help> List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=subscribe> Sender: xen-devel-bounces@lists.xensource.com Errors-To: xen-devel-bounces@lists.xensource.com # HG changeset patch # User Ian Campbell <ian.campbell@citrix.com> # Date 1317389248 -3600 # Node ID 1892dad72518f5253af2282db650cdd70c56a218 # Parent b3e80fe9f014f03700ca4846dde58d3473236223 libxl: convert disk handling to device API Signed-off-by: Ian Campbell <ian.campbell@citrix.com> diff -r b3e80fe9f014 -r 1892dad72518 tools/libxl/libxl.c --- a/tools/libxl/libxl.c Fri Sep 30 14:27:28 2011 +0100 +++ b/tools/libxl/libxl.c Fri Sep 30 14:27:28 2011 +0100 @@ -916,13 +916,58 @@ int libxl_vncviewer_exec(libxl_ctx *ctx, /******************************************************************************/ +int libxl_device_disk_init(libxl_ctx *ctx, libxl_device_disk *disk) +{ + memset(disk, 0x00, sizeof(libxl_device_disk)); + return 0; +} + +static int libxl__device_from_disk(libxl__gc *gc, uint32_t domid, + libxl_device_disk *disk, + libxl__device *device) +{ + libxl_ctx *ctx = libxl__gc_owner(gc); + int devid; + + devid = libxl__device_disk_dev_number(disk->vdev, NULL, NULL); + if (devid==-1) { + LIBXL__LOG(ctx, LIBXL__LOG_ERROR, "Invalid or unsupported" + " virtual disk identifier %s", disk->vdev); + return ERROR_INVAL; + } + + device->backend_domid = disk->backend_domid; + device->backend_devid = devid; + + switch (disk->backend) { + case LIBXL_DISK_BACKEND_PHY: + device->backend_kind = LIBXL__DEVICE_KIND_VBD; + break; + case LIBXL_DISK_BACKEND_TAP: + device->backend_kind = LIBXL__DEVICE_KIND_VBD; + break; + case LIBXL_DISK_BACKEND_QDISK: + device->backend_kind = LIBXL__DEVICE_KIND_QDISK; + break; + default: + LIBXL__LOG(ctx, LIBXL__LOG_ERROR, "unrecognized disk backend type: %d\n", + disk->backend); + return ERROR_INVAL; + } + + device->domid = domid; + device->devid = devid; + device->kind = LIBXL__DEVICE_KIND_VBD; + + return 0; +} + int libxl_device_disk_add(libxl_ctx *ctx, uint32_t domid, libxl_device_disk *disk) { libxl__gc gc = LIBXL_INIT_GC(ctx); flexarray_t *front; flexarray_t *back; char *dev; - int devid; libxl__device device; int major, minor, rc; @@ -947,20 +992,13 @@ int libxl_device_disk_add(libxl_ctx *ctx goto out_free; } - devid = libxl__device_disk_dev_number(disk->vdev, NULL, NULL); - if (devid==-1) { + rc = libxl__device_from_disk(&gc, domid, disk, &device); + if (rc != 0) { LIBXL__LOG(ctx, LIBXL__LOG_ERROR, "Invalid or unsupported" " virtual disk identifier %s", disk->vdev); - rc = ERROR_INVAL; goto out_free; } - device.backend_devid = devid; - device.backend_domid = disk->backend_domid; - device.devid = devid; - device.domid = domid; - device.kind = LIBXL__DEVICE_KIND_VBD; - switch (disk->backend) { case LIBXL_DISK_BACKEND_PHY: dev = disk->pdev_path; @@ -972,7 +1010,7 @@ int libxl_device_disk_add(libxl_ctx *ctx flexarray_append(back, "params"); flexarray_append(back, dev); - device.backend_kind = LIBXL__DEVICE_KIND_VBD; + assert(device.backend_kind == LIBXL__DEVICE_KIND_VBD); break; case LIBXL_DISK_BACKEND_TAP: dev = libxl__blktap_devpath(&gc, disk->pdev_path, disk->format); @@ -991,7 +1029,7 @@ int libxl_device_disk_add(libxl_ctx *ctx flexarray_append(back, "params"); flexarray_append(back, libxl__sprintf(&gc, "%s:%s", libxl__device_disk_string_of_format(disk->format), disk->pdev_path)); - device.backend_kind = LIBXL__DEVICE_KIND_QDISK; + assert(device.backend_kind == LIBXL__DEVICE_KIND_QDISK); break; default: LIBXL__LOG(ctx, LIBXL__LOG_ERROR, "unrecognized disk backend type: %d\n", disk->backend); @@ -1023,7 +1061,7 @@ int libxl_device_disk_add(libxl_ctx *ctx flexarray_append(front, "state"); flexarray_append(front, libxl__sprintf(&gc, "%d", 1)); flexarray_append(front, "virtual-device"); - flexarray_append(front, libxl__sprintf(&gc, "%d", devid)); + flexarray_append(front, libxl__sprintf(&gc, "%d", device.devid)); flexarray_append(front, "device-type"); flexarray_append(front, disk->is_cdrom ? "cdrom" : "disk"); @@ -1041,45 +1079,37 @@ out: return rc; } -int libxl_device_disk_del(libxl_ctx *ctx, uint32_t domid, - libxl_device_disk *disk, int wait) +int libxl_device_disk_remove(libxl_ctx *ctx, uint32_t domid, + libxl_device_disk *disk) { libxl__gc gc = LIBXL_INIT_GC(ctx); libxl__device device; - int devid, rc; - - devid = libxl__device_disk_dev_number(disk->vdev, NULL, NULL); - device.backend_domid = disk->backend_domid; - device.backend_devid = devid; - - switch (disk->backend) { - case LIBXL_DISK_BACKEND_PHY: - device.backend_kind = LIBXL__DEVICE_KIND_VBD; - break; - case LIBXL_DISK_BACKEND_TAP: - device.backend_kind = LIBXL__DEVICE_KIND_VBD; - break; - case LIBXL_DISK_BACKEND_QDISK: - device.backend_kind = LIBXL__DEVICE_KIND_QDISK; - break; - default: - LIBXL__LOG(ctx, LIBXL__LOG_ERROR, "unrecognized disk backend type: %d\n", - disk->backend); - rc = ERROR_INVAL; - goto out_free; - } - device.domid = domid; - device.devid = devid; - device.kind = LIBXL__DEVICE_KIND_VBD; - if (wait) - rc = libxl__device_remove(&gc, &device, wait); - else - rc = libxl__device_force_remove(&gc, &device); -out_free: + int rc; + + rc = libxl__device_from_disk(&gc, domid, disk, &device); + if (rc != 0) goto out; + + rc = libxl__device_remove(&gc, &device, 1); +out: libxl__free_all(&gc); return rc; } +int libxl_device_disk_force_remove(libxl_ctx *ctx, uint32_t domid, + libxl_device_disk *disk) +{ + libxl__gc gc = LIBXL_INIT_GC(ctx); + libxl__device device; + int rc; + + rc = libxl__device_from_disk(&gc, domid, disk, &device); + if (rc != 0) goto out; + + rc = libxl__device_force_remove(&gc, &device); +out: + libxl__free_all(&gc); + return rc; +} char * libxl_device_disk_local_attach(libxl_ctx *ctx, libxl_device_disk *disk) { libxl__gc gc = LIBXL_INIT_GC(ctx); @@ -1623,7 +1653,7 @@ static void libxl__device_disk_from_xs_b unsigned int len; char *tmp; - memset(disk, 0, sizeof(*disk)); + libxl_device_disk_init(ctx, disk); tmp = xs_read(ctx->xsh, XBT_NULL, libxl__sprintf(gc, "%s/params", be_path), &len); @@ -1667,7 +1697,8 @@ int libxl_devid_to_device_disk(libxl_ctx char *dompath, *path; int rc = ERROR_FAIL; - memset(disk, 0, sizeof (libxl_device_disk)); + libxl_device_disk_init(ctx, disk); + dompath = libxl__xs_get_dompath(&gc, domid); if (!dompath) { goto out; @@ -1809,11 +1840,11 @@ int libxl_cdrom_insert(libxl_ctx *ctx, u ret = 0; - libxl_device_disk_del(ctx, domid, disks + i, 1); + libxl_device_disk_remove(ctx, domid, disks + i); libxl_device_disk_add(ctx, domid, disk); stubdomid = libxl_get_stubdom_id(ctx, domid); if (stubdomid) { - libxl_device_disk_del(ctx, stubdomid, disks + i, 1); + libxl_device_disk_remove(ctx, stubdomid, disks + i); libxl_device_disk_add(ctx, stubdomid, disk); } out: diff -r b3e80fe9f014 -r 1892dad72518 tools/libxl/libxl.h --- a/tools/libxl/libxl.h Fri Sep 30 14:27:28 2011 +0100 +++ b/tools/libxl/libxl.h Fri Sep 30 14:27:28 2011 +0100 @@ -451,15 +451,27 @@ libxl_vminfo * libxl_list_vm(libxl_ctx * * is used to free the members of the libxl_device_<type> data * type. It has no impact on the devices attached to any domain. */ + +/* Disks */ +int libxl_device_disk_init(libxl_ctx *ctx, libxl_device_disk *disk); int libxl_device_disk_add(libxl_ctx *ctx, uint32_t domid, libxl_device_disk *disk); -int libxl_device_disk_del(libxl_ctx *ctx, uint32_t domid, libxl_device_disk *disk, int wait); +int libxl_device_disk_remove(libxl_ctx *ctx, uint32_t domid, libxl_device_disk *disk); +int libxl_device_disk_force_remove(libxl_ctx *ctx, uint32_t domid, + libxl_device_disk *disk); + libxl_device_disk *libxl_device_disk_list(libxl_ctx *ctx, uint32_t domid, int *num); int libxl_device_disk_getinfo(libxl_ctx *ctx, uint32_t domid, libxl_device_disk *disk, libxl_diskinfo *diskinfo); + +/* + * Insert a CD-ROM device. A device corresponding to disk must already + * be attached to the guest. + */ int libxl_cdrom_insert(libxl_ctx *ctx, uint32_t domid, libxl_device_disk *disk); /* - * Make a disk available in this domain. Returns path to a device. + * Make a disk available in this (the control) domain. Returns path to + * a device. */ char * libxl_device_disk_local_attach(libxl_ctx *ctx, libxl_device_disk *disk); int libxl_device_disk_local_detach(libxl_ctx *ctx, libxl_device_disk *disk); diff -r b3e80fe9f014 -r 1892dad72518 tools/libxl/xl_cmdimpl.c --- a/tools/libxl/xl_cmdimpl.c Fri Sep 30 14:27:28 2011 +0100 +++ b/tools/libxl/xl_cmdimpl.c Fri Sep 30 14:27:28 2011 +0100 @@ -554,7 +554,7 @@ static void parse_disk_config_multistrin { int e; - memset(disk, 0, sizeof(*disk)); + libxl_device_disk_init(ctx, disk); if (!*config) { *config = xlu_cfg_init(stderr, "command line"); @@ -1953,6 +1953,8 @@ static void cd_insert(const char *dom, c disk.backend_domid = 0; libxl_cdrom_insert(ctx, domid, &disk); + + libxl_device_disk_destroy(&disk); free(buf); } @@ -4242,8 +4244,8 @@ int main_blockdetach(int argc, char **ar fprintf(stderr, "Error: Device %s not connected.\n", argv[optind+1]); return 1; } - if (libxl_device_disk_del(ctx, domid, &disk, 1)) { - fprintf(stderr, "libxl_device_disk_del failed.\n"); + if (libxl_device_disk_remove(ctx, domid, &disk)) { + fprintf(stderr, "libxl_device_disk_remove failed.\n"); } return 0; } _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel From xen-devel-bounces@lists.xensource.com Fri Sep 30 06:52:43 2011 Return-path: <xen-devel-bounces@lists.xensource.com> Envelope-to: www-data@lists.xensource.com Delivery-date: Fri, 30 Sep 2011 06:52:43 -0700 Received: from localhost ([127.0.0.1] helo=lists.colo.xensource.com) by lists.xensource.com with esmtp (Exim 4.43) id 1R9dW7-00078Q-8Y; Fri, 30 Sep 2011 06:52:43 -0700 Received: from mail27.messagelabs.com ([193.109.254.147]) by lists.xensource.com with esmtp (Exim 4.43) id 1R9dDi-0008Lg-1b for xen-devel@lists.xensource.com; Fri, 30 Sep 2011 06:33:43 -0700 X-Env-Sender: Ian.Campbell@eu.citrix.com X-Msg-Ref: server-12.tower-27.messagelabs.com!1317389601!44609294!1 X-Originating-IP: [66.165.176.89] X-StarScan-Version: 6.4.1; banners=-,-,- X-VirusChecked: Checked Received: (qmail 3472 invoked from network); 30 Sep 2011 13:33:22 -0000 Received: from smtp.citrix.com (HELO SMTP.CITRIX.COM) (66.165.176.89) by server-12.tower-27.messagelabs.com with RC4-SHA encrypted SMTP; 30 Sep 2011 13:33:22 -0000 X-IronPort-AV: E=Sophos;i="4.68,467,1312171200"; d="scan'208";a="17841098" Received: from ftlpmailmx01.citrite.net ([10.13.107.65]) by FTLPIPO01.CITRIX.COM with ESMTP/TLS/RC4-MD5; 30 Sep 2011 09:33:37 -0400 Received: from smtp01.ad.xensource.com (10.219.128.104) by smtprelay.citrix.com (10.13.107.65) with Microsoft SMTP Server id 8.3.137.0; Fri, 30 Sep 2011 09:33:36 -0400 Received: from localhost.localdomain (cosworth.uk.xensource.com [10.80.16.52]) by smtp01.ad.xensource.com (8.13.1/8.13.1) with ESMTP id p8UDXFZU029198; Fri, 30 Sep 2011 06:33:35 -0700 Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Mercurial-Node: 7a8cd032b63cf91d3fe04501997405d53cf5d8b3 Message-ID: <7a8cd032b63cf91d3fe0.1317389608@localhost.localdomain> In-Reply-To: <patchbomb.1317389593@localhost.localdomain> References: <patchbomb.1317389593@localhost.localdomain> User-Agent: Mercurial-patchbomb/1.6.4 Date: Fri, 30 Sep 2011 14:33:28 +0100 From: Ian Campbell <ian.campbell@citrix.com> To: xen-devel@lists.xensource.com Cc: Jim Fehlig <jfehlig@novell.com>, Mike McClurg <mike.mcclurg@citrix.com>, Dave Scott <Dave.Scott@eu.citrix.com>, Jonathan Ludlam <Jonathan.Ludlam@eu.citrix.com> Subject: [Xen-devel] [PATCH 15 of 23] libxl: merge libxl__device_del into libxl__device_remove X-BeenThere: xen-devel@lists.xensource.com X-Mailman-Version: 2.1.5 Precedence: list List-Id: Xen developer discussion <xen-devel.lists.xensource.com> List-Unsubscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe> List-Post: <mailto:xen-devel@lists.xensource.com> List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help> List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=subscribe> Sender: xen-devel-bounces@lists.xensource.com Errors-To: xen-devel-bounces@lists.xensource.com # HG changeset patch # User Ian Campbell <ian.campbell@citrix.com> # Date 1317389248 -3600 # Node ID 7a8cd032b63cf91d3fe04501997405d53cf5d8b3 # Parent ec28ee6dace513c3d009d498341f9537a19b2d98 libxl: merge libxl__device_del into libxl__device_remove Note that the "wait" parameter added to libxl_device_remove is different to the wait paramter previously used by similar functions. In the past not-wait meant forced whereas now in means wait for a graceful shutdown, as opposed to setting off a graceful shutdown but not waiting. Signed-off-by: Ian Campbell <ian.campbell@citrix.com> diff -r ec28ee6dace5 -r 7a8cd032b63c tools/libxl/libxl.c --- a/tools/libxl/libxl.c Fri Sep 30 14:27:28 2011 +0100 +++ b/tools/libxl/libxl.c Fri Sep 30 14:27:28 2011 +0100 @@ -1072,7 +1072,7 @@ int libxl_device_disk_del(libxl_ctx *ctx device.devid = devid; device.kind = LIBXL__DEVICE_KIND_VBD; if (wait) - rc = libxl__device_del(&gc, &device); + rc = libxl__device_remove(&gc, &device, wait); else rc = libxl__device_force_remove(&gc, &device); out_free: @@ -1287,7 +1287,7 @@ int libxl_device_nic_del(libxl_ctx *ctx, device.kind = LIBXL__DEVICE_KIND_VIF; if (wait) - rc = libxl__device_del(&gc, &device); + rc = libxl__device_remove(&gc, &device, wait); else rc = libxl__device_force_remove(&gc, &device); diff -r ec28ee6dace5 -r 7a8cd032b63c tools/libxl/libxl_device.c --- a/tools/libxl/libxl_device.c Fri Sep 30 14:27:28 2011 +0100 +++ b/tools/libxl/libxl_device.c Fri Sep 30 14:27:28 2011 +0100 @@ -367,57 +367,6 @@ int libxl__device_disk_dev_number(const return -1; } -int libxl__device_remove(libxl__gc *gc, libxl__device *dev) -{ - libxl_ctx *ctx = libxl__gc_owner(gc); - xs_transaction_t t; - char *be_path = libxl__device_backend_path(gc, dev); - char *state_path = libxl__sprintf(gc, "%s/state", be_path); - char *state = libxl__xs_read(gc, XBT_NULL, state_path); - int rc = 0; - - if (!state) - goto out; - if (atoi(state) != 4) { - libxl__device_destroy_tapdisk(gc, be_path); - xs_rm(ctx->xsh, XBT_NULL, be_path); - goto out; - } - -retry_transaction: - t = xs_transaction_start(ctx->xsh); - xs_write(ctx->xsh, t, libxl__sprintf(gc, "%s/online", be_path), "0", strlen("0")); - xs_write(ctx->xsh, t, state_path, "5", strlen("5")); - if (!xs_transaction_end(ctx->xsh, t, 0)) { - if (errno == EAGAIN) - goto retry_transaction; - else { - rc = -1; - goto out; - } - } - - xs_watch(ctx->xsh, state_path, be_path); - libxl__device_destroy_tapdisk(gc, be_path); - rc = 1; -out: - return rc; -} - -int libxl__device_force_remove(libxl__gc *gc, libxl__device *dev) -{ - libxl_ctx *ctx = libxl__gc_owner(gc); - char *be_path = libxl__device_backend_path(gc, dev); - char *fe_path = libxl__device_frontend_path(gc, dev); - - xs_rm(ctx->xsh, XBT_NULL, be_path); - xs_rm(ctx->xsh, XBT_NULL, fe_path); - - libxl__device_destroy_tapdisk(gc, be_path); - - return 0; -} - static int wait_for_dev_destroy(libxl__gc *gc, struct timeval *tv) { libxl_ctx *ctx = libxl__gc_owner(gc); @@ -446,6 +395,67 @@ static int wait_for_dev_destroy(libxl__g return rc; } +/* Returns 0 on success, ERROR_* on fail */ +int libxl__device_remove(libxl__gc *gc, libxl__device *dev, int wait) +{ + libxl_ctx *ctx = libxl__gc_owner(gc); + xs_transaction_t t; + char *be_path = libxl__device_backend_path(gc, dev); + char *state_path = libxl__sprintf(gc, "%s/state", be_path); + char *state = libxl__xs_read(gc, XBT_NULL, state_path); + int rc = 0; + + if (!state) + goto out; + if (atoi(state) != 4) { + libxl__device_destroy_tapdisk(gc, be_path); + xs_rm(ctx->xsh, XBT_NULL, be_path); + goto out; + } + +retry_transaction: + t = xs_transaction_start(ctx->xsh); + xs_write(ctx->xsh, t, libxl__sprintf(gc, "%s/online", be_path), "0", strlen("0")); + xs_write(ctx->xsh, t, state_path, "5", strlen("5")); + if (!xs_transaction_end(ctx->xsh, t, 0)) { + if (errno == EAGAIN) + goto retry_transaction; + else { + rc = ERROR_FAIL; + goto out; + } + } + + xs_watch(ctx->xsh, state_path, be_path); + libxl__device_destroy_tapdisk(gc, be_path); + + if (wait) { + struct timeval tv; + tv.tv_sec = LIBXL_DESTROY_TIMEOUT; + tv.tv_usec = 0; + (void)wait_for_dev_destroy(gc, &tv); + xs_rm(ctx->xsh, XBT_NULL, libxl__device_frontend_path(gc, dev)); + } + + rc = 0; +out: + return rc; +} + +int libxl__device_force_remove(libxl__gc *gc, libxl__device *dev) +{ + libxl_ctx *ctx = libxl__gc_owner(gc); + char *be_path = libxl__device_backend_path(gc, dev); + char *fe_path = libxl__device_frontend_path(gc, dev); + + xs_rm(ctx->xsh, XBT_NULL, be_path); + xs_rm(ctx->xsh, XBT_NULL, fe_path); + + libxl__device_destroy_tapdisk(gc, be_path); + + return 0; +} + int libxl__devices_destroy(libxl__gc *gc, uint32_t domid, int force) { libxl_ctx *ctx = libxl__gc_owner(gc); @@ -487,7 +497,7 @@ int libxl__devices_destroy(libxl__gc *gc if (force) { libxl__device_force_remove(gc, &dev); } else { - if (libxl__device_remove(gc, &dev) > 0) + if (libxl__device_remove(gc, &dev, 0) == 0) n_watches++; } } @@ -506,7 +516,7 @@ int libxl__devices_destroy(libxl__gc *gc if (force) { libxl__device_force_remove(gc, &dev); } else { - if (libxl__device_remove(gc, &dev) > 0) + if (libxl__device_remove(gc, &dev, 0) == 0) n_watches++; } } @@ -532,29 +542,6 @@ out: return 0; } -int libxl__device_del(libxl__gc *gc, libxl__device *dev) -{ - libxl_ctx *ctx = libxl__gc_owner(gc); - struct timeval tv; - int rc; - - rc = libxl__device_remove(gc, dev); - if (rc == -1) { - rc = ERROR_FAIL; - goto out; - } - - tv.tv_sec = LIBXL_DESTROY_TIMEOUT; - tv.tv_usec = 0; - (void)wait_for_dev_destroy(gc, &tv); - - xs_rm(ctx->xsh, XBT_NULL, libxl__device_frontend_path(gc, dev)); - rc = 0; - -out: - return rc; -} - int libxl__wait_for_device_model(libxl__gc *gc, uint32_t domid, char *state, libxl__spawn_starting *spawning, diff -r ec28ee6dace5 -r 7a8cd032b63c tools/libxl/libxl_internal.h --- a/tools/libxl/libxl_internal.h Fri Sep 30 14:27:28 2011 +0100 +++ b/tools/libxl/libxl_internal.h Fri Sep 30 14:27:28 2011 +0100 @@ -242,8 +242,7 @@ _hidden char *libxl__device_backend_path _hidden char *libxl__device_frontend_path(libxl__gc *gc, libxl__device *device); _hidden int libxl__parse_backend_path(libxl__gc *gc, const char *path, libxl__device *dev); -_hidden int libxl__device_del(libxl__gc *gc, libxl__device *dev); -_hidden int libxl__device_remove(libxl__gc *gc, libxl__device *dev); +_hidden int libxl__device_remove(libxl__gc *gc, libxl__device *dev, int wait); _hidden int libxl__device_force_remove(libxl__gc *gc, libxl__device *dev); _hidden int libxl__devices_destroy(libxl__gc *gc, uint32_t domid, int force); _hidden int libxl__wait_for_backend(libxl__gc *gc, char *be_path, char *state); _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel From xen-devel-bounces@lists.xensource.com Fri Sep 30 06:53:40 2011 Return-path: <xen-devel-bounces@lists.xensource.com> Envelope-to: www-data@lists.xensource.com Delivery-date: Fri, 30 Sep 2011 06:53:40 -0700 Received: from localhost ([127.0.0.1] helo=lists.colo.xensource.com) by lists.xensource.com with esmtp (Exim 4.43) id 1R9dX2-0007VZ-Pp; Fri, 30 Sep 2011 06:53:40 -0700 Received: from mail21.messagelabs.com ([85.158.143.35]) by lists.xensource.com with esmtp (Exim 4.43) id 1R9dDl-0008MC-0F for xen-devel@lists.xensource.com; Fri, 30 Sep 2011 06:33:45 -0700 X-Env-Sender: Ian.Campbell@eu.citrix.com X-Msg-Ref: server-4.tower-21.messagelabs.com!1317389561!62247725!10 X-Originating-IP: [66.165.176.63] X-StarScan-Version: 6.4.1; banners=-,-,- X-VirusChecked: Checked Received: (qmail 21194 invoked from network); 30 Sep 2011 13:33:04 -0000 Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63) by server-4.tower-21.messagelabs.com with RC4-SHA encrypted SMTP; 30 Sep 2011 13:33:04 -0000 X-IronPort-AV: E=Sophos;i="4.68,467,1312171200"; d="scan'208";a="165287009" Received: from ftlpmailmx01.citrite.net ([10.13.107.65]) by FTLPIPO02.CITRIX.COM with ESMTP/TLS/RC4-MD5; 30 Sep 2011 09:33:41 -0400 Received: from smtp01.ad.xensource.com (10.219.128.104) by smtprelay.citrix.com (10.13.107.65) with Microsoft SMTP Server id 8.3.137.0; Fri, 30 Sep 2011 09:33:40 -0400 Received: from localhost.localdomain (cosworth.uk.xensource.com [10.80.16.52]) by smtp01.ad.xensource.com (8.13.1/8.13.1) with ESMTP id p8UDXFZX029198; Fri, 30 Sep 2011 06:33:39 -0700 Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Mercurial-Node: 9b58180714357f9879f7ff88a267e7d1f5dfdbb2 Message-ID: <9b58180714357f9879f7.1317389611@localhost.localdomain> In-Reply-To: <patchbomb.1317389593@localhost.localdomain> References: <patchbomb.1317389593@localhost.localdomain> User-Agent: Mercurial-patchbomb/1.6.4 Date: Fri, 30 Sep 2011 14:33:31 +0100 From: Ian Campbell <ian.campbell@citrix.com> To: xen-devel@lists.xensource.com Cc: Jim Fehlig <jfehlig@novell.com>, Mike McClurg <mike.mcclurg@citrix.com>, Dave Scott <Dave.Scott@eu.citrix.com>, Jonathan Ludlam <Jonathan.Ludlam@eu.citrix.com> Subject: [Xen-devel] [PATCH 18 of 23] libxl: convert NIC handling to device API X-BeenThere: xen-devel@lists.xensource.com X-Mailman-Version: 2.1.5 Precedence: list List-Id: Xen developer discussion <xen-devel.lists.xensource.com> List-Unsubscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe> List-Post: <mailto:xen-devel@lists.xensource.com> List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help> List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=subscribe> Sender: xen-devel-bounces@lists.xensource.com Errors-To: xen-devel-bounces@lists.xensource.com # HG changeset patch # User Ian Campbell <ian.campbell@citrix.com> # Date 1317389248 -3600 # Node ID 9b58180714357f9879f7ff88a267e7d1f5dfdbb2 # Parent 1892dad72518f5253af2282db650cdd70c56a218 libxl: convert NIC handling to device API Signed-off-by: Ian Campbell <ian.campbell@citrix.com> diff -r 1892dad72518 -r 9b5818071435 tools/libxl/libxl.c --- a/tools/libxl/libxl.c Fri Sep 30 14:27:28 2011 +0100 +++ b/tools/libxl/libxl.c Fri Sep 30 14:27:28 2011 +0100 @@ -1184,32 +1184,46 @@ int libxl_device_disk_local_detach(libxl } /******************************************************************************/ -int libxl_device_nic_init(libxl_device_nic *nic_info, int devnum) +int libxl_device_nic_init(libxl_ctx *ctx, libxl_device_nic *nic) { const uint8_t *r; libxl_uuid uuid; libxl_uuid_generate(&uuid); r = libxl_uuid_bytearray(&uuid); - memset(nic_info, '\0', sizeof(*nic_info)); - - nic_info->backend_domid = 0; - nic_info->devid = devnum; - nic_info->mtu = 1492; - nic_info->model = strdup("rtl8139"); - nic_info->mac[0] = 0x00; - nic_info->mac[1] = 0x16; - nic_info->mac[2] = 0x3e; - nic_info->mac[3] = r[0] & 0x7f; - nic_info->mac[4] = r[1]; - nic_info->mac[5] = r[2]; - nic_info->ifname = NULL; - nic_info->bridge = strdup("xenbr0"); - nic_info->ip = NULL; - if ( asprintf(&nic_info->script, "%s/vif-bridge", + memset(nic, '\0', sizeof(*nic)); + + nic->backend_domid = 0; + nic->devid = -1; + nic->mtu = 1492; + nic->model = strdup("rtl8139"); + nic->mac[0] = 0x00; + nic->mac[1] = 0x16; + nic->mac[2] = 0x3e; + nic->mac[3] = r[0] & 0x7f; + nic->mac[4] = r[1]; + nic->mac[5] = r[2]; + nic->ifname = NULL; + nic->bridge = strdup("xenbr0"); + nic->ip = NULL; + if ( asprintf(&nic->script, "%s/vif-bridge", libxl_xen_script_dir_path()) < 0 ) return ERROR_FAIL; - nic_info->nictype = LIBXL_NIC_TYPE_IOEMU; + nic->nictype = LIBXL_NIC_TYPE_IOEMU; + return 0; +} + +static int libxl__device_from_nic(libxl__gc *gc, uint32_t domid, + libxl_device_nic *nic, + libxl__device *device) +{ + device->backend_devid = nic->devid; + device->backend_domid = nic->backend_domid; + device->backend_kind = LIBXL__DEVICE_KIND_VIF; + device->devid = nic->devid; + device->domid = domid; + device->kind = LIBXL__DEVICE_KIND_VIF; + return 0; } @@ -1246,12 +1260,8 @@ int libxl_device_nic_add(libxl_ctx *ctx, } } - device.backend_devid = nic->devid; - device.backend_domid = nic->backend_domid; - device.backend_kind = LIBXL__DEVICE_KIND_VIF; - device.devid = nic->devid; - device.domid = domid; - device.kind = LIBXL__DEVICE_KIND_VIF; + rc = libxl__device_from_nic(&gc, domid, nic, &device); + if ( rc != 0 ) goto out_free; flexarray_append(back, "frontend-id"); flexarray_append(back, libxl__sprintf(&gc, "%d", domid)); @@ -1302,29 +1312,37 @@ out: return rc; } -int libxl_device_nic_del(libxl_ctx *ctx, uint32_t domid, - libxl_device_nic *nic, int wait) +int libxl_device_nic_remove(libxl_ctx *ctx, uint32_t domid, + libxl_device_nic *nic) { libxl__gc gc = LIBXL_INIT_GC(ctx); libxl__device device; int rc; - device.backend_devid = nic->devid; - device.backend_domid = nic->backend_domid; - device.backend_kind = LIBXL__DEVICE_KIND_VIF; - device.devid = nic->devid; - device.domid = domid; - device.kind = LIBXL__DEVICE_KIND_VIF; - - if (wait) - rc = libxl__device_remove(&gc, &device, wait); - else - rc = libxl__device_force_remove(&gc, &device); - + rc = libxl__device_from_nic(&gc, domid, nic, &device); + if (rc != 0) goto out; + + rc = libxl__device_remove(&gc, &device, 1); +out: libxl__free_all(&gc); return rc; } +int libxl_device_nic_force_remove(libxl_ctx *ctx, uint32_t domid, + libxl_device_nic *nic) +{ + libxl__gc gc = LIBXL_INIT_GC(ctx); + libxl__device device; + int rc; + + rc = libxl__device_from_nic(&gc, domid, nic, &device); + if (rc != 0) goto out; + + rc = libxl__device_force_remove(&gc, &device); +out: + libxl__free_all(&gc); + return rc; +} static void libxl__device_nic_from_xs_be(libxl__gc *gc, const char *be_path, libxl_device_nic *nic) diff -r 1892dad72518 -r 9b5818071435 tools/libxl/libxl.h --- a/tools/libxl/libxl.h Fri Sep 30 14:27:28 2011 +0100 +++ b/tools/libxl/libxl.h Fri Sep 30 14:27:28 2011 +0100 @@ -476,9 +476,12 @@ int libxl_cdrom_insert(libxl_ctx *ctx, u char * libxl_device_disk_local_attach(libxl_ctx *ctx, libxl_device_disk *disk); int libxl_device_disk_local_detach(libxl_ctx *ctx, libxl_device_disk *disk); -int libxl_device_nic_init(libxl_device_nic *nic, int dev_num); +/* Network Interfaces */ +int libxl_device_nic_init(libxl_ctx *ctx, libxl_device_nic *nic); int libxl_device_nic_add(libxl_ctx *ctx, uint32_t domid, libxl_device_nic *nic); -int libxl_device_nic_del(libxl_ctx *ctx, uint32_t domid, libxl_device_nic *nic, int wait); +int libxl_device_nic_remove(libxl_ctx *ctx, uint32_t domid, libxl_device_nic *nic); +int libxl_device_nic_force_remove(libxl_ctx *ctx, uint32_t domid, libxl_device_nic *nic); + libxl_device_nic *libxl_device_nic_list(libxl_ctx *ctx, uint32_t domid, int *num); int libxl_device_nic_getinfo(libxl_ctx *ctx, uint32_t domid, libxl_device_nic *nic, libxl_nicinfo *nicinfo); diff -r 1892dad72518 -r 9b5818071435 tools/libxl/xl_cmdimpl.c --- a/tools/libxl/xl_cmdimpl.c Fri Sep 30 14:27:28 2011 +0100 +++ b/tools/libxl/xl_cmdimpl.c Fri Sep 30 14:27:28 2011 +0100 @@ -822,7 +822,8 @@ static void parse_config_data(const char d_config->vifs = (libxl_device_nic *) realloc(d_config->vifs, sizeof (libxl_device_nic) * (d_config->num_vifs+1)); nic = d_config->vifs + d_config->num_vifs; - CHK_ERRNO( libxl_device_nic_init(nic, d_config->num_vifs) ); + CHK_ERRNO( libxl_device_nic_init(ctx, nic) ); + nic->devid = d_config->num_vifs; if (default_vifscript) { free(nic->script); @@ -4032,7 +4033,7 @@ int main_networkattach(int argc, char ** fprintf(stderr, "%s is an invalid domain identifier\n", argv[optind]); return 1; } - libxl_device_nic_init(&nic, -1); + libxl_device_nic_init(ctx, &nic); for (argv += optind+1, argc -= optind+1; argc > 0; ++argv, --argc) { if (MATCH_OPTION("type", *argv, oparg)) { if (!strcmp("vif", oparg)) { @@ -4149,7 +4150,7 @@ int main_networkdetach(int argc, char ** return 1; } } - if (libxl_device_nic_del(ctx, domid, &nic, 1)) { + if (libxl_device_nic_remove(ctx, domid, &nic)) { fprintf(stderr, "libxl_device_nic_del failed.\n"); return 1; } _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel From xen-devel-bounces@lists.xensource.com Fri Sep 30 06:55:03 2011 Return-path: <xen-devel-bounces@lists.xensource.com> Envelope-to: www-data@lists.xensource.com Delivery-date: Fri, 30 Sep 2011 06:55:03 -0700 Received: from localhost ([127.0.0.1] helo=lists.colo.xensource.com) by lists.xensource.com with esmtp (Exim 4.43) id 1R9dYN-0007yn-Or; Fri, 30 Sep 2011 06:55:03 -0700 Received: from mail27.messagelabs.com ([193.109.254.147]) by lists.xensource.com with esmtp (Exim 4.43) id 1R9dDm-0008ML-43 for xen-devel@lists.xensource.com; Fri, 30 Sep 2011 06:33:46 -0700 X-Env-Sender: Ian.Campbell@eu.citrix.com X-Msg-Ref: server-12.tower-27.messagelabs.com!1317389601!44609294!3 X-Originating-IP: [66.165.176.89] X-StarScan-Version: 6.4.1; banners=-,-,- X-VirusChecked: Checked Received: (qmail 3868 invoked from network); 30 Sep 2011 13:33:26 -0000 Received: from smtp.citrix.com (HELO SMTP.CITRIX.COM) (66.165.176.89) by server-12.tower-27.messagelabs.com with RC4-SHA encrypted SMTP; 30 Sep 2011 13:33:26 -0000 X-IronPort-AV: E=Sophos;i="4.68,467,1312171200"; d="scan'208";a="17841105" Received: from ftlpmailmx01.citrite.net ([10.13.107.65]) by FTLPIPO01.CITRIX.COM with ESMTP/TLS/RC4-MD5; 30 Sep 2011 09:33:42 -0400 Received: from smtp01.ad.xensource.com (10.219.128.104) by smtprelay.citrix.com (10.13.107.65) with Microsoft SMTP Server id 8.3.137.0; Fri, 30 Sep 2011 09:33:42 -0400 Received: from localhost.localdomain (cosworth.uk.xensource.com [10.80.16.52]) by smtp01.ad.xensource.com (8.13.1/8.13.1) with ESMTP id p8UDXFZY029198; Fri, 30 Sep 2011 06:33:41 -0700 Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Mercurial-Node: 51dd4ee904718c59b7a05620a4e42e9f531adf81 Message-ID: <51dd4ee904718c59b7a0.1317389612@localhost.localdomain> In-Reply-To: <patchbomb.1317389593@localhost.localdomain> References: <patchbomb.1317389593@localhost.localdomain> User-Agent: Mercurial-patchbomb/1.6.4 Date: Fri, 30 Sep 2011 14:33:32 +0100 From: Ian Campbell <ian.campbell@citrix.com> To: xen-devel@lists.xensource.com Cc: Jim Fehlig <jfehlig@novell.com>, Mike McClurg <mike.mcclurg@citrix.com>, Dave Scott <Dave.Scott@eu.citrix.com>, Jonathan Ludlam <Jonathan.Ludlam@eu.citrix.com> Subject: [Xen-devel] [PATCH 19 of 23] libxl: remove libxl_device_console_add X-BeenThere: xen-devel@lists.xensource.com X-Mailman-Version: 2.1.5 Precedence: list List-Id: Xen developer discussion <xen-devel.lists.xensource.com> List-Unsubscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe> List-Post: <mailto:xen-devel@lists.xensource.com> List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help> List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=subscribe> Sender: xen-devel-bounces@lists.xensource.com Errors-To: xen-devel-bounces@lists.xensource.com # HG changeset patch # User Ian Campbell <ian.campbell@citrix.com> # Date 1317389248 -3600 # Node ID 51dd4ee904718c59b7a05620a4e42e9f531adf81 # Parent 9b58180714357f9879f7ff88a267e7d1f5dfdbb2 libxl: remove libxl_device_console_add. It has no callers, the only code which adds consoles in internal to libxl and uses libxl__device_console_add directly. Rather than worrying about what the public API should look like in this case simply remove it, adding new APIs is much easier than fixing broken ones... Signed-off-by: Ian Campbell <ian.campbell@citrix.com> diff -r 9b5818071435 -r 51dd4ee90471 tools/libxl/libxl.c --- a/tools/libxl/libxl.c Fri Sep 30 14:27:28 2011 +0100 +++ b/tools/libxl/libxl.c Fri Sep 30 14:27:28 2011 +0100 @@ -1582,18 +1582,6 @@ out: return rc; } -int libxl_device_console_add(libxl_ctx *ctx, uint32_t domid, - libxl_device_console *console) -{ - libxl__gc gc = LIBXL_INIT_GC(ctx); - int rc = ERROR_INVAL; - - rc = libxl__device_console_add(&gc, domid, console, NULL); - - libxl__free_all(&gc); - return rc; -} - /******************************************************************************/ void libxl_device_vkb_init(libxl_device_vkb *vkb, int dev_num) { diff -r 9b5818071435 -r 51dd4ee90471 tools/libxl/libxl.h --- a/tools/libxl/libxl.h Fri Sep 30 14:27:28 2011 +0100 +++ b/tools/libxl/libxl.h Fri Sep 30 14:27:28 2011 +0100 @@ -486,8 +486,6 @@ libxl_device_nic *libxl_device_nic_list( int libxl_device_nic_getinfo(libxl_ctx *ctx, uint32_t domid, libxl_device_nic *nic, libxl_nicinfo *nicinfo); -int libxl_device_console_add(libxl_ctx *ctx, uint32_t domid, libxl_device_console *console); - void libxl_device_vkb_init(libxl_device_vkb *vkb, int dev_num); int libxl_device_vkb_add(libxl_ctx *ctx, uint32_t domid, libxl_device_vkb *vkb); int libxl_device_vkb_clean_shutdown(libxl_ctx *ctx, uint32_t domid); _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel From xen-devel-bounces@lists.xensource.com Fri Sep 30 06:56:15 2011 Return-path: <xen-devel-bounces@lists.xensource.com> Envelope-to: www-data@lists.xensource.com Delivery-date: Fri, 30 Sep 2011 06:56:15 -0700 Received: from localhost ([127.0.0.1] helo=lists.colo.xensource.com) by lists.xensource.com with esmtp (Exim 4.43) id 1R9dZX-0008RQ-OD; Fri, 30 Sep 2011 06:56:15 -0700 Received: from mail21.messagelabs.com ([85.158.143.35]) by lists.xensource.com with esmtp (Exim 4.43) id 1R9dDn-0008Mb-HB for xen-devel@lists.xensource.com; Fri, 30 Sep 2011 06:33:48 -0700 X-Env-Sender: Ian.Campbell@eu.citrix.com X-Msg-Ref: server-4.tower-21.messagelabs.com!1317389561!62247725!11 X-Originating-IP: [66.165.176.63] X-StarScan-Version: 6.4.1; banners=-,-,- X-VirusChecked: Checked Received: (qmail 21366 invoked from network); 30 Sep 2011 13:33:07 -0000 Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63) by server-4.tower-21.messagelabs.com with RC4-SHA encrypted SMTP; 30 Sep 2011 13:33:07 -0000 X-IronPort-AV: E=Sophos;i="4.68,467,1312171200"; d="scan'208";a="165287011" Received: from ftlpmailmx01.citrite.net ([10.13.107.65]) by FTLPIPO02.CITRIX.COM with ESMTP/TLS/RC4-MD5; 30 Sep 2011 09:33:44 -0400 Received: from smtp01.ad.xensource.com (10.219.128.104) by smtprelay.citrix.com (10.13.107.65) with Microsoft SMTP Server id 8.3.137.0; Fri, 30 Sep 2011 09:33:43 -0400 Received: from localhost.localdomain (cosworth.uk.xensource.com [10.80.16.52]) by smtp01.ad.xensource.com (8.13.1/8.13.1) with ESMTP id p8UDXFZZ029198; Fri, 30 Sep 2011 06:33:42 -0700 Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Mercurial-Node: afe568282807e64005da85453153c89a64e3b8cd Message-ID: <afe568282807e64005da.1317389613@localhost.localdomain> In-Reply-To: <patchbomb.1317389593@localhost.localdomain> References: <patchbomb.1317389593@localhost.localdomain> User-Agent: Mercurial-patchbomb/1.6.4 Date: Fri, 30 Sep 2011 14:33:33 +0100 From: Ian Campbell <ian.campbell@citrix.com> To: xen-devel@lists.xensource.com Cc: Jim Fehlig <jfehlig@novell.com>, Mike McClurg <mike.mcclurg@citrix.com>, Dave Scott <Dave.Scott@eu.citrix.com>, Jonathan Ludlam <Jonathan.Ludlam@eu.citrix.com> Subject: [Xen-devel] [PATCH 20 of 23] libxl: convert VKB handling to device API X-BeenThere: xen-devel@lists.xensource.com X-Mailman-Version: 2.1.5 Precedence: list List-Id: Xen developer discussion <xen-devel.lists.xensource.com> List-Unsubscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe> List-Post: <mailto:xen-devel@lists.xensource.com> List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help> List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=subscribe> Sender: xen-devel-bounces@lists.xensource.com Errors-To: xen-devel-bounces@lists.xensource.com # HG changeset patch # User Ian Campbell <ian.campbell@citrix.com> # Date 1317389248 -3600 # Node ID afe568282807e64005da85453153c89a64e3b8cd # Parent 51dd4ee904718c59b7a05620a4e42e9f531adf81 libxl: convert VKB handling to device API Signed-off-by: Ian Campbell <ian.campbell@citrix.com> diff -r 51dd4ee90471 -r afe568282807 tools/libxl/libxl.c --- a/tools/libxl/libxl.c Fri Sep 30 14:27:28 2011 +0100 +++ b/tools/libxl/libxl.c Fri Sep 30 14:27:28 2011 +0100 @@ -1583,10 +1583,24 @@ out: } /******************************************************************************/ -void libxl_device_vkb_init(libxl_device_vkb *vkb, int dev_num) +int libxl_device_vkb_init(libxl_ctx *ctx, libxl_device_vkb *vkb) { memset(vkb, 0x00, sizeof(libxl_device_vkb)); - vkb->devid = dev_num; + return 0; +} + +static int libxl__device_from_vkb(libxl__gc *gc, uint32_t domid, + libxl_device_vkb *vkb, + libxl__device *device) +{ + device->backend_devid = vkb->devid; + device->backend_domid = vkb->backend_domid; + device->backend_kind = LIBXL__DEVICE_KIND_VKBD; + device->devid = vkb->devid; + device->domid = domid; + device->kind = LIBXL__DEVICE_KIND_VKBD; + + return 0; } int libxl_device_vkb_add(libxl_ctx *ctx, uint32_t domid, libxl_device_vkb *vkb) @@ -1608,12 +1622,8 @@ int libxl_device_vkb_add(libxl_ctx *ctx, goto out_free; } - device.backend_devid = vkb->devid; - device.backend_domid = vkb->backend_domid; - device.backend_kind = LIBXL__DEVICE_KIND_VKBD; - device.devid = vkb->devid; - device.domid = domid; - device.kind = LIBXL__DEVICE_KIND_VKBD; + rc = libxl__device_from_vkb(&gc, domid, vkb, &device); + if (rc != 0) goto out_free; flexarray_append(back, "frontend-id"); flexarray_append(back, libxl__sprintf(&gc, "%d", domid)); @@ -1641,14 +1651,36 @@ out: return rc; } -int libxl_device_vkb_clean_shutdown(libxl_ctx *ctx, uint32_t domid) +int libxl_device_vkb_remove(libxl_ctx *ctx, uint32_t domid, + libxl_device_vkb *vkb) { - return ERROR_NI; + libxl__gc gc = LIBXL_INIT_GC(ctx); + libxl__device device; + int rc; + + rc = libxl__device_from_vkb(&gc, domid, vkb, &device); + if (rc != 0) goto out; + + rc = libxl__device_remove(&gc, &device, 1); +out: + libxl__free_all(&gc); + return rc; } -int libxl_device_vkb_hard_shutdown(libxl_ctx *ctx, uint32_t domid) +int libxl_device_vkb_force_remove(libxl_ctx *ctx, uint32_t domid, + libxl_device_vkb *vkb) { - return ERROR_NI; + libxl__gc gc = LIBXL_INIT_GC(ctx); + libxl__device device; + int rc; + + rc = libxl__device_from_vkb(&gc, domid, vkb, &device); + if (rc != 0) goto out; + + rc = libxl__device_force_remove(&gc, &device); +out: + libxl__free_all(&gc); + return rc; } static void libxl__device_disk_from_xs_be(libxl__gc *gc, @@ -1936,16 +1968,6 @@ out: return rc; } -int libxl_device_vfb_clean_shutdown(libxl_ctx *ctx, uint32_t domid) -{ - return ERROR_NI; -} - -int libxl_device_vfb_hard_shutdown(libxl_ctx *ctx, uint32_t domid) -{ - return ERROR_NI; -} - /******************************************************************************/ int libxl_domain_setmaxmem(libxl_ctx *ctx, uint32_t domid, uint32_t max_memkb) diff -r 51dd4ee90471 -r afe568282807 tools/libxl/libxl.h --- a/tools/libxl/libxl.h Fri Sep 30 14:27:28 2011 +0100 +++ b/tools/libxl/libxl.h Fri Sep 30 14:27:28 2011 +0100 @@ -486,10 +486,11 @@ libxl_device_nic *libxl_device_nic_list( int libxl_device_nic_getinfo(libxl_ctx *ctx, uint32_t domid, libxl_device_nic *nic, libxl_nicinfo *nicinfo); -void libxl_device_vkb_init(libxl_device_vkb *vkb, int dev_num); +/* Keyboard */ +int libxl_device_vkb_init(libxl_ctx *ctx, libxl_device_vkb *vkb); int libxl_device_vkb_add(libxl_ctx *ctx, uint32_t domid, libxl_device_vkb *vkb); -int libxl_device_vkb_clean_shutdown(libxl_ctx *ctx, uint32_t domid); -int libxl_device_vkb_hard_shutdown(libxl_ctx *ctx, uint32_t domid); +int libxl_device_vkb_remove(libxl_ctx *ctx, uint32_t domid, libxl_device_vkb *vkb); +int libxl_device_vkb_force_remove(libxl_ctx *ctx, uint32_t domid, libxl_device_vkb *vkb); void libxl_device_vfb_init(libxl_device_vfb *vfb, int dev_num); int libxl_device_vfb_add(libxl_ctx *ctx, uint32_t domid, libxl_device_vfb *vfb); diff -r 51dd4ee90471 -r afe568282807 tools/libxl/xl_cmdimpl.c --- a/tools/libxl/xl_cmdimpl.c Fri Sep 30 14:27:28 2011 +0100 +++ b/tools/libxl/xl_cmdimpl.c Fri Sep 30 14:27:28 2011 +0100 @@ -917,7 +917,8 @@ skip: d_config->vkbs = (libxl_device_vkb *) realloc(d_config->vkbs, sizeof(libxl_device_vkb) * (d_config->num_vkbs + 1)); vkb = d_config->vkbs + d_config->num_vkbs; - libxl_device_vkb_init(vkb, d_config->num_vkbs); + libxl_device_vkb_init(ctx, vkb); + vkb->devid = d_config->num_vkbs; p = strtok(buf2, ","); if (!p) _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel From xen-devel-bounces@lists.xensource.com Fri Sep 30 06:57:17 2011 Return-path: <xen-devel-bounces@lists.xensource.com> Envelope-to: www-data@lists.xensource.com Delivery-date: Fri, 30 Sep 2011 06:57:17 -0700 Received: from localhost ([127.0.0.1] helo=lists.colo.xensource.com) by lists.xensource.com with esmtp (Exim 4.43) id 1R9daX-0000Ou-O6; Fri, 30 Sep 2011 06:57:17 -0700 Received: from mail27.messagelabs.com ([193.109.254.147]) by lists.xensource.com with esmtp (Exim 4.43) id 1R9dDo-0008Mu-Ql for xen-devel@lists.xensource.com; Fri, 30 Sep 2011 06:33:49 -0700 X-Env-Sender: Ian.Campbell@eu.citrix.com X-Msg-Ref: server-12.tower-27.messagelabs.com!1317389601!44609294!4 X-Originating-IP: [66.165.176.89] X-StarScan-Version: 6.4.1; banners=-,-,- X-VirusChecked: Checked Received: (qmail 4215 invoked from network); 30 Sep 2011 13:33:28 -0000 Received: from smtp.citrix.com (HELO SMTP.CITRIX.COM) (66.165.176.89) by server-12.tower-27.messagelabs.com with RC4-SHA encrypted SMTP; 30 Sep 2011 13:33:28 -0000 X-IronPort-AV: E=Sophos;i="4.68,467,1312171200"; d="scan'208";a="17841107" Received: from ftlpmailmx01.citrite.net ([10.13.107.65]) by FTLPIPO01.CITRIX.COM with ESMTP/TLS/RC4-MD5; 30 Sep 2011 09:33:45 -0400 Received: from smtp01.ad.xensource.com (10.219.128.104) by smtprelay.citrix.com (10.13.107.65) with Microsoft SMTP Server id 8.3.137.0; Fri, 30 Sep 2011 09:33:44 -0400 Received: from localhost.localdomain (cosworth.uk.xensource.com [10.80.16.52]) by smtp01.ad.xensource.com (8.13.1/8.13.1) with ESMTP id p8UDXFZa029198; Fri, 30 Sep 2011 06:33:43 -0700 Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Mercurial-Node: 73c7b1d5d8cee5fd32ca5c60dc8830dbff23eaef Message-ID: <73c7b1d5d8cee5fd32ca.1317389614@localhost.localdomain> In-Reply-To: <patchbomb.1317389593@localhost.localdomain> References: <patchbomb.1317389593@localhost.localdomain> User-Agent: Mercurial-patchbomb/1.6.4 Date: Fri, 30 Sep 2011 14:33:34 +0100 From: Ian Campbell <ian.campbell@citrix.com> To: xen-devel@lists.xensource.com Cc: Jim Fehlig <jfehlig@novell.com>, Mike McClurg <mike.mcclurg@citrix.com>, Dave Scott <Dave.Scott@eu.citrix.com>, Jonathan Ludlam <Jonathan.Ludlam@eu.citrix.com> Subject: [Xen-devel] [PATCH 21 of 23] libxl: convert VKB handling to device API X-BeenThere: xen-devel@lists.xensource.com X-Mailman-Version: 2.1.5 Precedence: list List-Id: Xen developer discussion <xen-devel.lists.xensource.com> List-Unsubscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe> List-Post: <mailto:xen-devel@lists.xensource.com> List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help> List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=subscribe> Sender: xen-devel-bounces@lists.xensource.com Errors-To: xen-devel-bounces@lists.xensource.com # HG changeset patch # User Ian Campbell <ian.campbell@citrix.com> # Date 1317389248 -3600 # Node ID 73c7b1d5d8cee5fd32ca5c60dc8830dbff23eaef # Parent afe568282807e64005da85453153c89a64e3b8cd libxl: convert VKB handling to device API Signed-off-by: Ian Campbell <ian.campbell@citrix.com> diff -r afe568282807 -r 73c7b1d5d8ce tools/libxl/libxl.c --- a/tools/libxl/libxl.c Fri Sep 30 14:27:28 2011 +0100 +++ b/tools/libxl/libxl.c Fri Sep 30 14:27:28 2011 +0100 @@ -1893,10 +1893,9 @@ out: } /******************************************************************************/ -void libxl_device_vfb_init(libxl_device_vfb *vfb, int dev_num) +int libxl_device_vfb_init(libxl_ctx *ctx, libxl_device_vfb *vfb) { memset(vfb, 0x00, sizeof(libxl_device_vfb)); - vfb->devid = dev_num; vfb->display = NULL; vfb->xauthority = NULL; vfb->vnc = 1; @@ -1907,6 +1906,20 @@ void libxl_device_vfb_init(libxl_device_ vfb->keymap = NULL; vfb->sdl = 0; vfb->opengl = 0; + return 0; +} + +static int libxl__device_from_vfb(libxl__gc *gc, uint32_t domid, + libxl_device_vfb *vfb, + libxl__device *device) +{ + device->backend_devid = vfb->devid; + device->backend_domid = vfb->backend_domid; + device->backend_kind = LIBXL__DEVICE_KIND_VFB; + device->devid = vfb->devid; + device->domid = domid; + device->kind = LIBXL__DEVICE_KIND_VFB; + return 0; } int libxl_device_vfb_add(libxl_ctx *ctx, uint32_t domid, libxl_device_vfb *vfb) @@ -1928,12 +1941,8 @@ int libxl_device_vfb_add(libxl_ctx *ctx, goto out_free; } - device.backend_devid = vfb->devid; - device.backend_domid = vfb->backend_domid; - device.backend_kind = LIBXL__DEVICE_KIND_VFB; - device.devid = vfb->devid; - device.domid = domid; - device.kind = LIBXL__DEVICE_KIND_VFB; + rc = libxl__device_from_vfb(&gc, domid, vfb, &device); + if (rc != 0) goto out_free; flexarray_append_pair(back, "frontend-id", libxl__sprintf(&gc, "%d", domid)); flexarray_append_pair(back, "online", "1"); @@ -1968,6 +1977,38 @@ out: return rc; } +int libxl_device_vfb_remove(libxl_ctx *ctx, uint32_t domid, + libxl_device_vfb *vfb) +{ + libxl__gc gc = LIBXL_INIT_GC(ctx); + libxl__device device; + int rc; + + rc = libxl__device_from_vfb(&gc, domid, vfb, &device); + if (rc != 0) goto out; + + rc = libxl__device_remove(&gc, &device, 1); +out: + libxl__free_all(&gc); + return rc; +} + +int libxl_device_vfb_force_remove(libxl_ctx *ctx, uint32_t domid, + libxl_device_vfb *vfb) +{ + libxl__gc gc = LIBXL_INIT_GC(ctx); + libxl__device device; + int rc; + + rc = libxl__device_from_vfb(&gc, domid, vfb, &device); + if (rc != 0) goto out; + + rc = libxl__device_force_remove(&gc, &device); +out: + libxl__free_all(&gc); + return rc; +} + /******************************************************************************/ int libxl_domain_setmaxmem(libxl_ctx *ctx, uint32_t domid, uint32_t max_memkb) diff -r afe568282807 -r 73c7b1d5d8ce tools/libxl/libxl.h --- a/tools/libxl/libxl.h Fri Sep 30 14:27:28 2011 +0100 +++ b/tools/libxl/libxl.h Fri Sep 30 14:27:28 2011 +0100 @@ -492,10 +492,11 @@ int libxl_device_vkb_add(libxl_ctx *ctx, int libxl_device_vkb_remove(libxl_ctx *ctx, uint32_t domid, libxl_device_vkb *vkb); int libxl_device_vkb_force_remove(libxl_ctx *ctx, uint32_t domid, libxl_device_vkb *vkb); -void libxl_device_vfb_init(libxl_device_vfb *vfb, int dev_num); +/* Framebuffer */ +int libxl_device_vfb_init(libxl_ctx *ctx, libxl_device_vfb *vfb); int libxl_device_vfb_add(libxl_ctx *ctx, uint32_t domid, libxl_device_vfb *vfb); -int libxl_device_vfb_clean_shutdown(libxl_ctx *ctx, uint32_t domid); -int libxl_device_vfb_hard_shutdown(libxl_ctx *ctx, uint32_t domid); +int libxl_device_vfb_remove(libxl_ctx *ctx, uint32_t domid, libxl_device_vfb *vfb); +int libxl_device_vfb_force_remove(libxl_ctx *ctx, uint32_t domid, libxl_device_vfb *vfb); int libxl_device_pci_add(libxl_ctx *ctx, uint32_t domid, libxl_device_pci *pcidev); int libxl_device_pci_remove(libxl_ctx *ctx, uint32_t domid, libxl_device_pci *pcidev, int force); diff -r afe568282807 -r 73c7b1d5d8ce tools/libxl/xl_cmdimpl.c --- a/tools/libxl/xl_cmdimpl.c Fri Sep 30 14:27:28 2011 +0100 +++ b/tools/libxl/xl_cmdimpl.c Fri Sep 30 14:27:28 2011 +0100 @@ -913,7 +913,8 @@ skip: d_config->vfbs = (libxl_device_vfb *) realloc(d_config->vfbs, sizeof(libxl_device_vfb) * (d_config->num_vfbs + 1)); vfb = d_config->vfbs + d_config->num_vfbs; - libxl_device_vfb_init(vfb, d_config->num_vfbs); + libxl_device_vfb_init(ctx, vfb); + vfb->devid = d_config->num_vfbs; d_config->vkbs = (libxl_device_vkb *) realloc(d_config->vkbs, sizeof(libxl_device_vkb) * (d_config->num_vkbs + 1)); vkb = d_config->vkbs + d_config->num_vkbs; _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel From xen-devel-bounces@lists.xensource.com Fri Sep 30 06:59:33 2011 Return-path: <xen-devel-bounces@lists.xensource.com> Envelope-to: www-data@lists.xensource.com Delivery-date: Fri, 30 Sep 2011 06:59:33 -0700 Received: from localhost ([127.0.0.1] helo=lists.colo.xensource.com) by lists.xensource.com with esmtp (Exim 4.43) id 1R9dch-0000pc-Mq; Fri, 30 Sep 2011 06:59:32 -0700 Received: from mail21.messagelabs.com ([85.158.143.35]) by lists.xensource.com with esmtp (Exim 4.43) id 1R9dDq-0008N5-5z for xen-devel@lists.xensource.com; Fri, 30 Sep 2011 06:33:51 -0700 X-Env-Sender: Ian.Campbell@eu.citrix.com X-Msg-Ref: server-4.tower-21.messagelabs.com!1317389561!62247725!12 X-Originating-IP: [66.165.176.63] X-StarScan-Version: 6.4.1; banners=-,-,- X-VirusChecked: Checked Received: (qmail 21522 invoked from network); 30 Sep 2011 13:33:09 -0000 Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63) by server-4.tower-21.messagelabs.com with RC4-SHA encrypted SMTP; 30 Sep 2011 13:33:09 -0000 X-IronPort-AV: E=Sophos;i="4.68,467,1312171200"; d="scan'208";a="165287016" Received: from ftlpmailmx01.citrite.net ([10.13.107.65]) by FTLPIPO02.CITRIX.COM with ESMTP/TLS/RC4-MD5; 30 Sep 2011 09:33:46 -0400 Received: from smtp01.ad.xensource.com (10.219.128.104) by smtprelay.citrix.com (10.13.107.65) with Microsoft SMTP Server id 8.3.137.0; Fri, 30 Sep 2011 09:33:45 -0400 Received: from localhost.localdomain (cosworth.uk.xensource.com [10.80.16.52]) by smtp01.ad.xensource.com (8.13.1/8.13.1) with ESMTP id p8UDXFZb029198; Fri, 30 Sep 2011 06:33:44 -0700 Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Mercurial-Node: dc967a4691d5a7e05eac3522ab78c573a084b63c Message-ID: <dc967a4691d5a7e05eac.1317389615@localhost.localdomain> In-Reply-To: <patchbomb.1317389593@localhost.localdomain> References: <patchbomb.1317389593@localhost.localdomain> User-Agent: Mercurial-patchbomb/1.6.4 Date: Fri, 30 Sep 2011 14:33:35 +0100 From: Ian Campbell <ian.campbell@citrix.com> To: xen-devel@lists.xensource.com Cc: Jim Fehlig <jfehlig@novell.com>, Mike McClurg <mike.mcclurg@citrix.com>, Dave Scott <Dave.Scott@eu.citrix.com>, Jonathan Ludlam <Jonathan.Ludlam@eu.citrix.com> Subject: [Xen-devel] [PATCH 22 of 23] libxl: reorder device functions to put functions for each device together X-BeenThere: xen-devel@lists.xensource.com X-Mailman-Version: 2.1.5 Precedence: list List-Id: Xen developer discussion <xen-devel.lists.xensource.com> List-Unsubscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe> List-Post: <mailto:xen-devel@lists.xensource.com> List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help> List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=subscribe> Sender: xen-devel-bounces@lists.xensource.com Errors-To: xen-devel-bounces@lists.xensource.com # HG changeset patch # User Ian Campbell <ian.campbell@citrix.com> # Date 1317389248 -3600 # Node ID dc967a4691d5a7e05eac3522ab78c573a084b63c # Parent 73c7b1d5d8cee5fd32ca5c60dc8830dbff23eaef libxl: reorder device functions to put functions for each device together. Signed-off-by: Ian Campbell <ian.campbell@citrix.com> diff -r 73c7b1d5d8ce -r dc967a4691d5 tools/libxl/libxl.c --- a/tools/libxl/libxl.c Fri Sep 30 14:27:28 2011 +0100 +++ b/tools/libxl/libxl.c Fri Sep 30 14:27:28 2011 +0100 @@ -1110,6 +1110,216 @@ out: libxl__free_all(&gc); return rc; } + +static void libxl__device_disk_from_xs_be(libxl__gc *gc, + const char *be_path, + libxl_device_disk *disk) +{ + libxl_ctx *ctx = libxl__gc_owner(gc); + unsigned int len; + char *tmp; + + libxl_device_disk_init(ctx, disk); + + tmp = xs_read(ctx->xsh, XBT_NULL, + libxl__sprintf(gc, "%s/params", be_path), &len); + if (tmp && strchr(tmp, ':')) { + disk->pdev_path = strdup(strchr(tmp, ':') + 1); + free(tmp); + } else { + disk->pdev_path = tmp; + } + libxl_string_to_backend(ctx, + libxl__xs_read(gc, XBT_NULL, + libxl__sprintf(gc, "%s/type", be_path)), + &(disk->backend)); + disk->vdev = xs_read(ctx->xsh, XBT_NULL, + libxl__sprintf(gc, "%s/dev", be_path), &len); + tmp = libxl__xs_read(gc, XBT_NULL, libxl__sprintf + (gc, "%s/removable", be_path)); + + if (tmp) + disk->removable = atoi(tmp); + else + disk->removable = 0; + + tmp = libxl__xs_read(gc, XBT_NULL, libxl__sprintf(gc, "%s/mode", be_path)); + if (!strcmp(tmp, "w")) + disk->readwrite = 1; + else + disk->readwrite = 0; + + tmp = libxl__xs_read(gc, XBT_NULL, + libxl__sprintf(gc, "%s/device-type", be_path)); + disk->is_cdrom = !strcmp(tmp, "cdrom"); + + disk->format = LIBXL_DISK_FORMAT_UNKNOWN; +} + +int libxl_devid_to_device_disk(libxl_ctx *ctx, uint32_t domid, + int devid, libxl_device_disk *disk) +{ + libxl__gc gc = LIBXL_INIT_GC(ctx); + char *dompath, *path; + int rc = ERROR_FAIL; + + libxl_device_disk_init(ctx, disk); + + dompath = libxl__xs_get_dompath(&gc, domid); + if (!dompath) { + goto out; + } + path = libxl__xs_read(&gc, XBT_NULL, + libxl__sprintf(&gc, "%s/device/vbd/%d/backend", + dompath, devid)); + if (!path) + goto out; + + libxl__device_disk_from_xs_be(&gc, path, disk); + + rc = 0; +out: + libxl__free_all(&gc); + return rc; +} + + +static int libxl__append_disk_list_of_type(libxl__gc *gc, + uint32_t domid, + const char *type, + libxl_device_disk **disks, + int *ndisks) +{ + char *be_path = NULL; + char **dir = NULL; + unsigned int n = 0; + libxl_device_disk *pdisk = NULL, *pdisk_end = NULL; + + be_path = libxl__sprintf(gc, "%s/backend/%s/%d", + libxl__xs_get_dompath(gc, 0), type, domid); + dir = libxl__xs_directory(gc, XBT_NULL, be_path, &n); + if (dir) { + libxl_device_disk *tmp; + tmp = realloc(*disks, sizeof (libxl_device_disk) * (*ndisks + n)); + if (tmp == NULL) + return ERROR_NOMEM; + *disks = tmp; + pdisk = *disks + *ndisks; + *ndisks += n; + pdisk_end = *disks + *ndisks; + for (; pdisk < pdisk_end; pdisk++, dir++) { + const char *p; + p = libxl__sprintf(gc, "%s/%s", be_path, *dir); + libxl__device_disk_from_xs_be(gc, p, pdisk); + pdisk->backend_domid = 0; + } + } + return 0; +} + +libxl_device_disk *libxl_device_disk_list(libxl_ctx *ctx, uint32_t domid, int *num) +{ + libxl__gc gc = LIBXL_INIT_GC(ctx); + libxl_device_disk *disks = NULL; + int rc; + + *num = 0; + + rc = libxl__append_disk_list_of_type(&gc, domid, "vbd", &disks, num); + if (rc) goto out_err; + + rc = libxl__append_disk_list_of_type(&gc, domid, "tap", &disks, num); + if (rc) goto out_err; + + rc = libxl__append_disk_list_of_type(&gc, domid, "qdisk", &disks, num); + if (rc) goto out_err; + + libxl__free_all(&gc); + return disks; + +out_err: + LIBXL__LOG(ctx, LIBXL__LOG_ERROR, "Unable to list disks"); + while (disks && *num) { + (*num)--; + libxl_device_disk_destroy(&disks[*num]); + } + free(disks); + return NULL; +} + +int libxl_device_disk_getinfo(libxl_ctx *ctx, uint32_t domid, + libxl_device_disk *disk, libxl_diskinfo *diskinfo) +{ + libxl__gc gc = LIBXL_INIT_GC(ctx); + char *dompath, *diskpath; + char *val; + + dompath = libxl__xs_get_dompath(&gc, domid); + diskinfo->devid = libxl__device_disk_dev_number(disk->vdev, NULL, NULL); + + /* tap devices entries in xenstore are written as vbd devices. */ + diskpath = libxl__sprintf(&gc, "%s/device/vbd/%d", dompath, diskinfo->devid); + diskinfo->backend = xs_read(ctx->xsh, XBT_NULL, + libxl__sprintf(&gc, "%s/backend", diskpath), NULL); + if (!diskinfo->backend) { + libxl__free_all(&gc); + return ERROR_FAIL; + } + val = libxl__xs_read(&gc, XBT_NULL, libxl__sprintf(&gc, "%s/backend-id", diskpath)); + diskinfo->backend_id = val ? strtoul(val, NULL, 10) : -1; + val = libxl__xs_read(&gc, XBT_NULL, libxl__sprintf(&gc, "%s/state", diskpath)); + diskinfo->state = val ? strtoul(val, NULL, 10) : -1; + val = libxl__xs_read(&gc, XBT_NULL, libxl__sprintf(&gc, "%s/event-channel", diskpath)); + diskinfo->evtch = val ? strtoul(val, NULL, 10) : -1; + val = libxl__xs_read(&gc, XBT_NULL, libxl__sprintf(&gc, "%s/ring-ref", diskpath)); + diskinfo->rref = val ? strtoul(val, NULL, 10) : -1; + diskinfo->frontend = xs_read(ctx->xsh, XBT_NULL, + libxl__sprintf(&gc, "%s/frontend", diskinfo->backend), NULL); + val = libxl__xs_read(&gc, XBT_NULL, libxl__sprintf(&gc, "%s/frontend-id", diskinfo->backend)); + diskinfo->frontend_id = val ? strtoul(val, NULL, 10) : -1; + + libxl__free_all(&gc); + return 0; +} + +int libxl_cdrom_insert(libxl_ctx *ctx, uint32_t domid, libxl_device_disk *disk) +{ + int num, i; + uint32_t stubdomid; + libxl_device_disk *disks; + int ret = ERROR_FAIL; + + if (!disk->pdev_path) { + disk->pdev_path = strdup(""); + disk->format = LIBXL_DISK_FORMAT_EMPTY; + } + disks = libxl_device_disk_list(ctx, domid, &num); + for (i = 0; i < num; i++) { + if (disks[i].is_cdrom && !strcmp(disk->vdev, disks[i].vdev)) + /* found */ + break; + } + if (i == num) { + LIBXL__LOG(ctx, LIBXL__LOG_ERROR, "Virtual device not found"); + goto out; + } + + ret = 0; + + libxl_device_disk_remove(ctx, domid, disks + i); + libxl_device_disk_add(ctx, domid, disk); + stubdomid = libxl_get_stubdom_id(ctx, domid); + if (stubdomid) { + libxl_device_disk_remove(ctx, stubdomid, disks + i); + libxl_device_disk_add(ctx, stubdomid, disk); + } +out: + for (i = 0; i < num; i++) + libxl_device_disk_destroy(&disks[i]); + free(disks); + return ret; +} + char * libxl_device_disk_local_attach(libxl_ctx *ctx, libxl_device_disk *disk) { libxl__gc gc = LIBXL_INIT_GC(ctx); @@ -1343,6 +1553,7 @@ out: libxl__free_all(&gc); return rc; } + static void libxl__device_nic_from_xs_be(libxl__gc *gc, const char *be_path, libxl_device_nic *nic) @@ -1683,215 +1894,6 @@ out: return rc; } -static void libxl__device_disk_from_xs_be(libxl__gc *gc, - const char *be_path, - libxl_device_disk *disk) -{ - libxl_ctx *ctx = libxl__gc_owner(gc); - unsigned int len; - char *tmp; - - libxl_device_disk_init(ctx, disk); - - tmp = xs_read(ctx->xsh, XBT_NULL, - libxl__sprintf(gc, "%s/params", be_path), &len); - if (tmp && strchr(tmp, ':')) { - disk->pdev_path = strdup(strchr(tmp, ':') + 1); - free(tmp); - } else { - disk->pdev_path = tmp; - } - libxl_string_to_backend(ctx, - libxl__xs_read(gc, XBT_NULL, - libxl__sprintf(gc, "%s/type", be_path)), - &(disk->backend)); - disk->vdev = xs_read(ctx->xsh, XBT_NULL, - libxl__sprintf(gc, "%s/dev", be_path), &len); - tmp = libxl__xs_read(gc, XBT_NULL, libxl__sprintf - (gc, "%s/removable", be_path)); - - if (tmp) - disk->removable = atoi(tmp); - else - disk->removable = 0; - - tmp = libxl__xs_read(gc, XBT_NULL, libxl__sprintf(gc, "%s/mode", be_path)); - if (!strcmp(tmp, "w")) - disk->readwrite = 1; - else - disk->readwrite = 0; - - tmp = libxl__xs_read(gc, XBT_NULL, - libxl__sprintf(gc, "%s/device-type", be_path)); - disk->is_cdrom = !strcmp(tmp, "cdrom"); - - disk->format = LIBXL_DISK_FORMAT_UNKNOWN; -} - -int libxl_devid_to_device_disk(libxl_ctx *ctx, uint32_t domid, - int devid, libxl_device_disk *disk) -{ - libxl__gc gc = LIBXL_INIT_GC(ctx); - char *dompath, *path; - int rc = ERROR_FAIL; - - libxl_device_disk_init(ctx, disk); - - dompath = libxl__xs_get_dompath(&gc, domid); - if (!dompath) { - goto out; - } - path = libxl__xs_read(&gc, XBT_NULL, - libxl__sprintf(&gc, "%s/device/vbd/%d/backend", - dompath, devid)); - if (!path) - goto out; - - libxl__device_disk_from_xs_be(&gc, path, disk); - - rc = 0; -out: - libxl__free_all(&gc); - return rc; -} - - -static int libxl__append_disk_list_of_type(libxl__gc *gc, - uint32_t domid, - const char *type, - libxl_device_disk **disks, - int *ndisks) -{ - char *be_path = NULL; - char **dir = NULL; - unsigned int n = 0; - libxl_device_disk *pdisk = NULL, *pdisk_end = NULL; - - be_path = libxl__sprintf(gc, "%s/backend/%s/%d", - libxl__xs_get_dompath(gc, 0), type, domid); - dir = libxl__xs_directory(gc, XBT_NULL, be_path, &n); - if (dir) { - libxl_device_disk *tmp; - tmp = realloc(*disks, sizeof (libxl_device_disk) * (*ndisks + n)); - if (tmp == NULL) - return ERROR_NOMEM; - *disks = tmp; - pdisk = *disks + *ndisks; - *ndisks += n; - pdisk_end = *disks + *ndisks; - for (; pdisk < pdisk_end; pdisk++, dir++) { - const char *p; - p = libxl__sprintf(gc, "%s/%s", be_path, *dir); - libxl__device_disk_from_xs_be(gc, p, pdisk); - pdisk->backend_domid = 0; - } - } - return 0; -} - -libxl_device_disk *libxl_device_disk_list(libxl_ctx *ctx, uint32_t domid, int *num) -{ - libxl__gc gc = LIBXL_INIT_GC(ctx); - libxl_device_disk *disks = NULL; - int rc; - - *num = 0; - - rc = libxl__append_disk_list_of_type(&gc, domid, "vbd", &disks, num); - if (rc) goto out_err; - - rc = libxl__append_disk_list_of_type(&gc, domid, "tap", &disks, num); - if (rc) goto out_err; - - rc = libxl__append_disk_list_of_type(&gc, domid, "qdisk", &disks, num); - if (rc) goto out_err; - - libxl__free_all(&gc); - return disks; - -out_err: - LIBXL__LOG(ctx, LIBXL__LOG_ERROR, "Unable to list disks"); - while (disks && *num) { - (*num)--; - libxl_device_disk_destroy(&disks[*num]); - } - free(disks); - return NULL; -} - -int libxl_device_disk_getinfo(libxl_ctx *ctx, uint32_t domid, - libxl_device_disk *disk, libxl_diskinfo *diskinfo) -{ - libxl__gc gc = LIBXL_INIT_GC(ctx); - char *dompath, *diskpath; - char *val; - - dompath = libxl__xs_get_dompath(&gc, domid); - diskinfo->devid = libxl__device_disk_dev_number(disk->vdev, NULL, NULL); - - /* tap devices entries in xenstore are written as vbd devices. */ - diskpath = libxl__sprintf(&gc, "%s/device/vbd/%d", dompath, diskinfo->devid); - diskinfo->backend = xs_read(ctx->xsh, XBT_NULL, - libxl__sprintf(&gc, "%s/backend", diskpath), NULL); - if (!diskinfo->backend) { - libxl__free_all(&gc); - return ERROR_FAIL; - } - val = libxl__xs_read(&gc, XBT_NULL, libxl__sprintf(&gc, "%s/backend-id", diskpath)); - diskinfo->backend_id = val ? strtoul(val, NULL, 10) : -1; - val = libxl__xs_read(&gc, XBT_NULL, libxl__sprintf(&gc, "%s/state", diskpath)); - diskinfo->state = val ? strtoul(val, NULL, 10) : -1; - val = libxl__xs_read(&gc, XBT_NULL, libxl__sprintf(&gc, "%s/event-channel", diskpath)); - diskinfo->evtch = val ? strtoul(val, NULL, 10) : -1; - val = libxl__xs_read(&gc, XBT_NULL, libxl__sprintf(&gc, "%s/ring-ref", diskpath)); - diskinfo->rref = val ? strtoul(val, NULL, 10) : -1; - diskinfo->frontend = xs_read(ctx->xsh, XBT_NULL, - libxl__sprintf(&gc, "%s/frontend", diskinfo->backend), NULL); - val = libxl__xs_read(&gc, XBT_NULL, libxl__sprintf(&gc, "%s/frontend-id", diskinfo->backend)); - diskinfo->frontend_id = val ? strtoul(val, NULL, 10) : -1; - - libxl__free_all(&gc); - return 0; -} - -int libxl_cdrom_insert(libxl_ctx *ctx, uint32_t domid, libxl_device_disk *disk) -{ - int num, i; - uint32_t stubdomid; - libxl_device_disk *disks; - int ret = ERROR_FAIL; - - if (!disk->pdev_path) { - disk->pdev_path = strdup(""); - disk->format = LIBXL_DISK_FORMAT_EMPTY; - } - disks = libxl_device_disk_list(ctx, domid, &num); - for (i = 0; i < num; i++) { - if (disks[i].is_cdrom && !strcmp(disk->vdev, disks[i].vdev)) - /* found */ - break; - } - if (i == num) { - LIBXL__LOG(ctx, LIBXL__LOG_ERROR, "Virtual device not found"); - goto out; - } - - ret = 0; - - libxl_device_disk_remove(ctx, domid, disks + i); - libxl_device_disk_add(ctx, domid, disk); - stubdomid = libxl_get_stubdom_id(ctx, domid); - if (stubdomid) { - libxl_device_disk_remove(ctx, stubdomid, disks + i); - libxl_device_disk_add(ctx, stubdomid, disk); - } -out: - for (i = 0; i < num; i++) - libxl_device_disk_destroy(&disks[i]); - free(disks); - return ret; -} - /******************************************************************************/ int libxl_device_vfb_init(libxl_ctx *ctx, libxl_device_vfb *vfb) { _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel From xen-devel-bounces@lists.xensource.com Fri Sep 30 07:03:10 2011 Return-path: <xen-devel-bounces@lists.xensource.com> Envelope-to: www-data@lists.xensource.com Delivery-date: Fri, 30 Sep 2011 07:03:10 -0700 Received: from localhost ([127.0.0.1] helo=lists.colo.xensource.com) by lists.xensource.com with esmtp (Exim 4.43) id 1R9dgD-0001L3-H4; Fri, 30 Sep 2011 07:03:09 -0700 Received: from mail27.messagelabs.com ([193.109.254.147]) by lists.xensource.com with esmtp (Exim 4.43) id 1R9dDr-0008NL-LS for xen-devel@lists.xensource.com; Fri, 30 Sep 2011 06:33:53 -0700 X-Env-Sender: Ian.Campbell@eu.citrix.com X-Msg-Ref: server-12.tower-27.messagelabs.com!1317389601!44609294!5 X-Originating-IP: [66.165.176.89] X-StarScan-Version: 6.4.1; banners=-,-,- X-VirusChecked: Checked Received: (qmail 4493 invoked from network); 30 Sep 2011 13:33:31 -0000 Received: from smtp.citrix.com (HELO SMTP.CITRIX.COM) (66.165.176.89) by server-12.tower-27.messagelabs.com with RC4-SHA encrypted SMTP; 30 Sep 2011 13:33:31 -0000 X-IronPort-AV: E=Sophos;i="4.68,467,1312171200"; d="scan'208";a="17841108" Received: from ftlpmailmx01.citrite.net ([10.13.107.65]) by FTLPIPO01.CITRIX.COM with ESMTP/TLS/RC4-MD5; 30 Sep 2011 09:33:47 -0400 Received: from smtp01.ad.xensource.com (10.219.128.104) by smtprelay.citrix.com (10.13.107.65) with Microsoft SMTP Server id 8.3.137.0; Fri, 30 Sep 2011 09:33:47 -0400 Received: from localhost.localdomain (cosworth.uk.xensource.com [10.80.16.52]) by smtp01.ad.xensource.com (8.13.1/8.13.1) with ESMTP id p8UDXFZc029198; Fri, 30 Sep 2011 06:33:46 -0700 Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Mercurial-Node: f0ab7f2102b37968da2181825ac492b14bc4b449 Message-ID: <f0ab7f2102b37968da21.1317389616@localhost.localdomain> In-Reply-To: <patchbomb.1317389593@localhost.localdomain> References: <patchbomb.1317389593@localhost.localdomain> User-Agent: Mercurial-patchbomb/1.6.4 Date: Fri, 30 Sep 2011 14:33:36 +0100 From: Ian Campbell <ian.campbell@citrix.com> To: xen-devel@lists.xensource.com Cc: Jim Fehlig <jfehlig@novell.com>, Mike McClurg <mike.mcclurg@citrix.com>, Dave Scott <Dave.Scott@eu.citrix.com>, Jonathan Ludlam <Jonathan.Ludlam@eu.citrix.com> Subject: [Xen-devel] [PATCH 23 of 23] libxl: convert PCI device handling to device API X-BeenThere: xen-devel@lists.xensource.com X-Mailman-Version: 2.1.5 Precedence: list List-Id: Xen developer discussion <xen-devel.lists.xensource.com> List-Unsubscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe> List-Post: <mailto:xen-devel@lists.xensource.com> List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help> List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=subscribe> Sender: xen-devel-bounces@lists.xensource.com Errors-To: xen-devel-bounces@lists.xensource.com # HG changeset patch # User Ian Campbell <ian.campbell@citrix.com> # Date 1317389278 -3600 # Node ID f0ab7f2102b37968da2181825ac492b14bc4b449 # Parent dc967a4691d5a7e05eac3522ab78c573a084b63c libxl: convert PCI device handling to device API Signed-off-by: Ian Campbell <ian.campbell@citrix.com> diff -r dc967a4691d5 -r f0ab7f2102b3 tools/libxl/libxl.c --- a/tools/libxl/libxl.c Fri Sep 30 14:27:28 2011 +0100 +++ b/tools/libxl/libxl.c Fri Sep 30 14:27:58 2011 +0100 @@ -754,7 +754,7 @@ int libxl_domain_destroy(libxl_ctx *ctx, goto out; } - if (libxl_device_pci_shutdown(ctx, domid) < 0) + if (libxl__device_pci_force_remove_all(&gc, domid) < 0) LIBXL__LOG(ctx, LIBXL__LOG_ERROR, "pci shutdown failed for domid %d", domid); rc = xc_domain_pause(ctx->xch, domid); if (rc < 0) { diff -r dc967a4691d5 -r f0ab7f2102b3 tools/libxl/libxl.h --- a/tools/libxl/libxl.h Fri Sep 30 14:27:28 2011 +0100 +++ b/tools/libxl/libxl.h Fri Sep 30 14:27:58 2011 +0100 @@ -498,12 +498,28 @@ int libxl_device_vfb_add(libxl_ctx *ctx, int libxl_device_vfb_remove(libxl_ctx *ctx, uint32_t domid, libxl_device_vfb *vfb); int libxl_device_vfb_force_remove(libxl_ctx *ctx, uint32_t domid, libxl_device_vfb *vfb); +/* PCI Passthrough */ +int libxl_device_pci_init(libxl_ctx *ctx, libxl_device_pci *pci); int libxl_device_pci_add(libxl_ctx *ctx, uint32_t domid, libxl_device_pci *pcidev); -int libxl_device_pci_remove(libxl_ctx *ctx, uint32_t domid, libxl_device_pci *pcidev, int force); -int libxl_device_pci_shutdown(libxl_ctx *ctx, uint32_t domid); -int libxl_device_pci_list_assigned(libxl_ctx *ctx, libxl_device_pci **list, uint32_t domid, int *num); -int libxl_device_pci_list_assignable(libxl_ctx *ctx, libxl_device_pci **list, int *num); -int libxl_device_pci_parse_bdf(libxl_ctx *ctx, libxl_device_pci *pcidev, const char *str); +int libxl_device_pci_remove(libxl_ctx *ctx, uint32_t domid, libxl_device_pci *pcidev); +int libxl_device_pci_force_remove(libxl_ctx *ctx, uint32_t domid, libxl_device_pci *pcidev); +libxl_device_pci *libxl_device_pci_list(libxl_ctx *ctx, uint32_t domid, int *num); + +/* + * Parse a PCI BDF into a PCI device structure. + */ +int libxl_device_pci_parse_bdf(libxl_ctx *ctx, + libxl_device_pci *pcidev, + const char *str); + +/* + * Similar to libxl_device_pci_list but returns all devices which + * could be assigned to a domain (i.e. are bound to the backend + * driver) but are not currently. + */ +libxl_device_pci *libxl_device_pci_list_assignable(libxl_ctx *ctx, int *num); + +/* CPUID handling */ int libxl_cpuid_parse_config(libxl_cpuid_policy_list *cpuid, const char* str); int libxl_cpuid_parse_config_xend(libxl_cpuid_policy_list *cpuid, const char* str); diff -r dc967a4691d5 -r f0ab7f2102b3 tools/libxl/libxl_internal.h --- a/tools/libxl/libxl_internal.h Fri Sep 30 14:27:28 2011 +0100 +++ b/tools/libxl/libxl_internal.h Fri Sep 30 14:27:58 2011 +0100 @@ -252,6 +252,7 @@ _hidden int libxl__wait_for_backend(libx _hidden int libxl__device_pci_add(libxl__gc *gc, uint32_t domid, libxl_device_pci *pcidev, int starting); _hidden int libxl__create_pci_backend(libxl__gc *gc, uint32_t domid, libxl_device_pci *pcidev, int num); +_hidden int libxl__device_pci_force_remove_all(libxl__gc *gc, uint32_t domid); /* xl_exec */ diff -r dc967a4691d5 -r f0ab7f2102b3 tools/libxl/libxl_pci.c --- a/tools/libxl/libxl_pci.c Fri Sep 30 14:27:28 2011 +0100 +++ b/tools/libxl/libxl_pci.c Fri Sep 30 14:27:58 2011 +0100 @@ -486,7 +486,7 @@ static int is_assigned(libxl_device_pci return 0; } -int libxl_device_pci_list_assignable(libxl_ctx *ctx, libxl_device_pci **list, int *num) +libxl_device_pci *libxl_device_pci_list_assignable(libxl_ctx *ctx, int *num) { libxl__gc gc = LIBXL_INIT_GC(ctx); libxl_device_pci *pcidevs = NULL, *new, *assigned; @@ -495,13 +495,10 @@ int libxl_device_pci_list_assignable(lib int rc, num_assigned; *num = 0; - *list = NULL; rc = get_all_assigned_devices(&gc, &assigned, &num_assigned); - if ( rc ) { - libxl__free_all(&gc); - return rc; - } + if ( rc ) + goto out; dir = opendir(SYSFS_PCIBACK_DRIVER); if ( NULL == dir ) { @@ -510,8 +507,7 @@ int libxl_device_pci_list_assignable(lib }else{ LIBXL__LOG_ERRNO(ctx, LIBXL__LOG_ERROR, "Couldn't open %s", SYSFS_PCIBACK_DRIVER); } - libxl__free_all(&gc); - return ERROR_FAIL; + goto out_closedir; } while( (de = readdir(dir)) ) { @@ -534,10 +530,11 @@ int libxl_device_pci_list_assignable(lib (*num)++; } +out_closedir: closedir(dir); - *list = pcidevs; +out: libxl__free_all(&gc); - return 0; + return pcidevs; } /* @@ -846,21 +843,25 @@ static int do_pci_remove(libxl__gc *gc, int hvm = 0, rc, num; int stubdomid = 0; - if ( !libxl_device_pci_list_assigned(ctx, &assigned, domid, &num) ) { - if ( !is_assigned(assigned, num, pcidev->domain, - pcidev->bus, pcidev->dev, pcidev->func) ) { - LIBXL__LOG(ctx, LIBXL__LOG_ERROR, "PCI device not attached to this domain"); - return ERROR_INVAL; - } + assigned = libxl_device_pci_list(ctx, domid, &num); + if ( assigned == NULL ) + return ERROR_FAIL; + + rc = ERROR_INVAL; + if ( !is_assigned(assigned, num, pcidev->domain, + pcidev->bus, pcidev->dev, pcidev->func) ) { + LIBXL__LOG(ctx, LIBXL__LOG_ERROR, "PCI device not attached to this domain"); + goto out_fail; } + rc = ERROR_FAIL; switch (libxl__domain_type(gc, domid)) { case LIBXL_DOMAIN_TYPE_HVM: hvm = 1; if (libxl__wait_for_device_model(gc, domid, "running", - NULL, NULL, NULL) < 0) { - return ERROR_FAIL; - } + NULL, NULL, NULL) < 0) + goto out_fail; + path = libxl__sprintf(gc, "/local/domain/0/device-model/%d/state", domid); state = libxl__xs_read(gc, XBT_NULL, path); path = libxl__sprintf(gc, "/local/domain/0/device-model/%d/parameter", domid); @@ -879,7 +880,7 @@ static int do_pci_remove(libxl__gc *gc, * SCI, if it doesn't respond in time then we may wish to * force the removal. */ - return ERROR_FAIL; + goto out_fail; } } path = libxl__sprintf(gc, "/local/domain/0/device-model/%d/state", domid); @@ -955,25 +956,31 @@ out: stubdomid = libxl_get_stubdom_id(ctx, domid); if (stubdomid != 0) { libxl_device_pci pcidev_s = *pcidev; - libxl_device_pci_remove(ctx, stubdomid, &pcidev_s, force); + if (force) + libxl_device_pci_force_remove(ctx, stubdomid, &pcidev_s); + else + libxl_device_pci_remove(ctx, stubdomid, &pcidev_s); } libxl__device_pci_remove_xenstore(gc, domid, pcidev); - return 0; + rc = 0; +out_fail: + free(assigned); + return rc; + } -int libxl_device_pci_remove(libxl_ctx *ctx, uint32_t domid, - libxl_device_pci *pcidev, int force) +static int libxl__device_pci_remove_common(libxl__gc *gc, uint32_t domid, + libxl_device_pci *pcidev, int force) { - libxl__gc gc = LIBXL_INIT_GC(ctx); unsigned int orig_vdev, pfunc_mask; int i, rc; orig_vdev = pcidev->vdevfn & ~7U; if ( pcidev->vfunc_mask == LIBXL_PCI_FUNC_ALL ) { - if ( pci_multifunction_check(&gc, pcidev, &pfunc_mask) ) { + if ( pci_multifunction_check(gc, pcidev, &pfunc_mask) ) { rc = ERROR_FAIL; goto out; } @@ -990,81 +997,118 @@ int libxl_device_pci_remove(libxl_ctx *c }else{ pcidev->vdevfn = orig_vdev; } - if ( do_pci_remove(&gc, domid, pcidev, force) ) + if ( do_pci_remove(gc, domid, pcidev, force) ) rc = ERROR_FAIL; } } out: + return rc; +} + +int libxl_device_pci_remove(libxl_ctx *ctx, uint32_t domid, libxl_device_pci *pcidev) +{ + libxl__gc gc = LIBXL_INIT_GC(ctx); + int rc; + + rc = libxl__device_pci_remove_common(&gc, domid, pcidev, 0); + libxl__free_all(&gc); return rc; } -int libxl_device_pci_list_assigned(libxl_ctx *ctx, libxl_device_pci **list, uint32_t domid, int *num) +int libxl_device_pci_force_remove(libxl_ctx *ctx, uint32_t domid, + libxl_device_pci *pcidev) { libxl__gc gc = LIBXL_INIT_GC(ctx); - char *be_path, *num_devs, *xsdev, *xsvdevfn, *xsopts; + int rc; + + rc = libxl__device_pci_remove_common(&gc, domid, pcidev, 1); + + libxl__free_all(&gc); + return rc; +} + +static void libxl__device_pci_from_xs_be(libxl__gc *gc, + const char *be_path, + libxl_device_pci *pci, + int nr) +{ + char *s; + unsigned int domain = 0, bus = 0, dev = 0, func = 0, vdevfn = 0; + + s = libxl__xs_read(gc, XBT_NULL, libxl__sprintf(gc, "%s/dev-%d", be_path, nr)); + sscanf(s, PCI_BDF, &domain, &bus, &dev, &func); + + s = libxl__xs_read(gc, XBT_NULL, libxl__sprintf(gc, "%s/vdevfn-%d", be_path, nr)); + if (s) + vdevfn = strtol(s, (char **) NULL, 16); + + pcidev_init(pci, domain, bus, dev, func, vdevfn); + + s = libxl__xs_read(gc, XBT_NULL, libxl__sprintf(gc, "%s/opts-%d", be_path, nr)); + if (s) { + char *saveptr; + char *p = strtok_r(s, ",=", &saveptr); + do { + while (*p == ' ') + p++; + if (!strcmp(p, "msitranslate")) { + p = strtok_r(NULL, ",=", &saveptr); + pci->msitranslate = atoi(p); + } else if (!strcmp(p, "power_mgmt")) { + p = strtok_r(NULL, ",=", &saveptr); + pci->power_mgmt = atoi(p); + } + } while ((p = strtok_r(NULL, ",=", &saveptr)) != NULL); + } +} + +libxl_device_pci *libxl_device_pci_list(libxl_ctx *ctx, uint32_t domid, int *num) +{ + libxl__gc gc = LIBXL_INIT_GC(ctx); + char *be_path, *num_devs; int n, i; - unsigned int domain = 0, bus = 0, dev = 0, func = 0, vdevfn = 0; - libxl_device_pci *pcidevs; + libxl_device_pci *pcidevs = NULL; + + *num = 0; be_path = libxl__sprintf(&gc, "%s/backend/pci/%d/0", libxl__xs_get_dompath(&gc, 0), domid); num_devs = libxl__xs_read(&gc, XBT_NULL, libxl__sprintf(&gc, "%s/num_devs", be_path)); - if (!num_devs) { - *num = 0; - *list = NULL; - libxl__free_all(&gc); - return 0; - } + if (!num_devs) + goto out; + n = atoi(num_devs); pcidevs = calloc(n, sizeof(libxl_device_pci)); + + for (i = 0; i < n; i++) + libxl__device_pci_from_xs_be(&gc, be_path, pcidevs + i, i); + *num = n; - - for (i = 0; i < n; i++) { - xsdev = libxl__xs_read(&gc, XBT_NULL, libxl__sprintf(&gc, "%s/dev-%d", be_path, i)); - sscanf(xsdev, PCI_BDF, &domain, &bus, &dev, &func); - xsvdevfn = libxl__xs_read(&gc, XBT_NULL, libxl__sprintf(&gc, "%s/vdevfn-%d", be_path, i)); - if (xsvdevfn) - vdevfn = strtol(xsvdevfn, (char **) NULL, 16); - pcidev_init(pcidevs + i, domain, bus, dev, func, vdevfn); - xsopts = libxl__xs_read(&gc, XBT_NULL, libxl__sprintf(&gc, "%s/opts-%d", be_path, i)); - if (xsopts) { - char *saveptr; - char *p = strtok_r(xsopts, ",=", &saveptr); - do { - while (*p == ' ') - p++; - if (!strcmp(p, "msitranslate")) { - p = strtok_r(NULL, ",=", &saveptr); - pcidevs[i].msitranslate = atoi(p); - } else if (!strcmp(p, "power_mgmt")) { - p = strtok_r(NULL, ",=", &saveptr); - pcidevs[i].power_mgmt = atoi(p); - } - } while ((p = strtok_r(NULL, ",=", &saveptr)) != NULL); - } - } - *list = pcidevs; +out: libxl__free_all(&gc); - return 0; + return pcidevs; } -int libxl_device_pci_shutdown(libxl_ctx *ctx, uint32_t domid) +int libxl__device_pci_force_remove_all(libxl__gc *gc, uint32_t domid) { + libxl_ctx *ctx = libxl__gc_owner(gc); libxl_device_pci *pcidevs; - int num, i, rc; + int num, i, rc = 0; - rc = libxl_device_pci_list_assigned(ctx, &pcidevs, domid, &num); - if ( rc ) - return rc; + pcidevs = libxl_device_pci_list(ctx, domid, &num); + if ( pcidevs == NULL ) + return ERROR_FAIL; + for (i = 0; i < num; i++) { /* Force remove on shutdown since, on HVM, qemu will not always * respond to SCI interrupt because the guest kernel has shut down the * devices by the time we even get here! */ - if (libxl_device_pci_remove(ctx, domid, pcidevs + i, 1) < 0) - return ERROR_FAIL; + if (libxl_device_pci_force_remove(ctx, domid, pcidevs + i) < 0) + rc = ERROR_FAIL; } + free(pcidevs); return 0; } diff -r dc967a4691d5 -r f0ab7f2102b3 tools/libxl/xl_cmdimpl.c --- a/tools/libxl/xl_cmdimpl.c Fri Sep 30 14:27:28 2011 +0100 +++ b/tools/libxl/xl_cmdimpl.c Fri Sep 30 14:27:58 2011 +0100 @@ -2078,11 +2078,14 @@ static void pcilist_assignable(void) libxl_device_pci *pcidevs; int num, i; - if ( libxl_device_pci_list_assignable(ctx, &pcidevs, &num) ) + pcidevs = libxl_device_pci_list_assignable(ctx, &num); + + if ( pcidevs == NULL ) return; for (i = 0; i < num; i++) { printf("%04x:%02x:%02x.%01x\n", - pcidevs[i].domain, pcidevs[i].bus, pcidevs[i].dev, pcidevs[i].func); + pcidevs[i].domain, pcidevs[i].bus, pcidevs[i].dev, pcidevs[i].func); + libxl_device_pci_destroy(&pcidevs[i]); } free(pcidevs); } @@ -2105,7 +2108,8 @@ static void pcilist(const char *dom) find_domain(dom); - if (libxl_device_pci_list_assigned(ctx, &pcidevs, domid, &num)) + pcidevs = libxl_device_pci_list(ctx, domid, &num); + if (pcidevs == NULL) return; printf("Vdev Device\n"); for (i = 0; i < num; i++) { @@ -2142,7 +2146,10 @@ static void pcidetach(const char *dom, c fprintf(stderr, "pci-detach: malformed BDF specification \"%s\"\n", bdf); exit(2); } - libxl_device_pci_remove(ctx, domid, &pcidev, force); + if (force) + libxl_device_pci_force_remove(ctx, domid, &pcidev); + else + libxl_device_pci_remove(ctx, domid, &pcidev); libxl_device_pci_destroy(&pcidev); } diff -r dc967a4691d5 -r f0ab7f2102b3 tools/python/xen/lowlevel/xl/xl.c --- a/tools/python/xen/lowlevel/xl/xl.c Fri Sep 30 14:27:28 2011 +0100 +++ b/tools/python/xen/lowlevel/xl/xl.c Fri Sep 30 14:27:58 2011 +0100 @@ -521,9 +521,16 @@ static PyObject *pyxl_pci_del(XlObject * return NULL; } pci = (Py_device_pci *)obj; - if ( libxl_device_pci_remove(self->ctx, domid, &pci->obj, force) ) { - PyErr_SetString(xl_error_obj, "cannot remove pci device"); - return NULL; + if ( force ) { + if ( libxl_device_pci_force_remove(self->ctx, domid, &pci->obj) ) { + PyErr_SetString(xl_error_obj, "cannot remove pci device"); + return NULL; + } + } else { + if ( libxl_device_pci_remove(self->ctx, domid, &pci->obj) ) { + PyErr_SetString(xl_error_obj, "cannot remove pci device"); + return NULL; + } } Py_INCREF(Py_None); return Py_None; @@ -558,7 +565,8 @@ static PyObject *pyxl_pci_list_assignabl PyObject *list; int nr_dev, i; - if ( libxl_device_pci_list_assignable(self->ctx, &dev, &nr_dev) ) { + dev = libxl_device_pci_list_assignable(self->ctx, &nr_dev); + if ( dev == NULL ) { PyErr_SetString(xl_error_obj, "Cannot list assignable devices"); return NULL; } @@ -594,7 +602,8 @@ static PyObject *pyxl_pci_list(XlObject if ( !PyArg_ParseTuple(args, "i", &domid) ) return NULL; - if ( libxl_device_pci_list_assigned(self->ctx, &dev, domid, &nr_dev) ) { + dev = libxl_device_pci_list(self->ctx, domid, &nr_dev); + if ( dev == NULL ) { PyErr_SetString(xl_error_obj, "Cannot list assignable devices"); return NULL; } _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel From xen-devel-bounces@lists.xensource.com Fri Sep 30 07:05:29 2011 Return-path: <xen-devel-bounces@lists.xensource.com> Envelope-to: www-data@lists.xensource.com Delivery-date: Fri, 30 Sep 2011 07:05:29 -0700 Received: from localhost ([127.0.0.1] helo=lists.colo.xensource.com) by lists.xensource.com with esmtp (Exim 4.43) id 1R9diR-0001kA-TW; Fri, 30 Sep 2011 07:05:28 -0700 Received: from mail27.messagelabs.com ([193.109.254.147]) by lists.xensource.com with esmtp (Exim 4.43) id 1R9dNe-0003eW-Cy for xen-devel@lists.xensource.com; Fri, 30 Sep 2011 06:43:59 -0700 X-Env-Sender: Ian.Jackson@eu.citrix.com X-Msg-Ref: server-13.tower-27.messagelabs.com!1317390222!42218133!1 X-Originating-IP: [62.200.22.115] X-StarScan-Version: 6.4.1; banners=-,-,- X-VirusChecked: Checked Received: (qmail 17866 invoked from network); 30 Sep 2011 13:43:42 -0000 Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115) by server-13.tower-27.messagelabs.com with RC4-SHA encrypted SMTP; 30 Sep 2011 13:43:42 -0000 X-IronPort-AV: E=Sophos;i="4.68,467,1312156800"; d="scan'208";a="8153319" Received: from lonpmailmx01.citrite.net ([10.30.203.162]) by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5; 30 Sep 2011 13:43:54 +0000 Received: from norwich.cam.xci-test.com (10.80.248.129) by smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id 8.3.137.0; Fri, 30 Sep 2011 14:43:54 +0100 Received: from [10.80.248.135] (helo=woking.xci-test.com) by norwich.cam.xci-test.com with esmtp (Exim 4.72) (envelope-from <ian.jackson@eu.citrix.com>) id 1R9dNa-0005oQ-Bm; Fri, 30 Sep 2011 13:43:54 +0000 Received: from osstest by woking.xci-test.com with local (Exim 4.69) (envelope-from <ian.jackson@eu.citrix.com>) id 1R9dNa-0005a4-BI; Fri, 30 Sep 2011 14:43:54 +0100 To: <xen-devel@lists.xensource.com> Message-ID: <osstest-9160-mainreport@xen.org> From: xen.org <ian.jackson@eu.citrix.com> Date: Fri, 30 Sep 2011 14:43:54 +0100 MIME-Version: 1.0 Content-Type: text/plain Cc: ian.jackson@eu.citrix.com Subject: [Xen-devel] [xen-unstable test] 9160: regressions - FAIL X-BeenThere: xen-devel@lists.xensource.com X-Mailman-Version: 2.1.5 Precedence: list List-Id: Xen developer discussion <xen-devel.lists.xensource.com> List-Unsubscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe> List-Post: <mailto:xen-devel@lists.xensource.com> List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help> List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=subscribe> Sender: xen-devel-bounces@lists.xensource.com Errors-To: xen-devel-bounces@lists.xensource.com flight 9160 xen-unstable real [real] http://www.chiark.greenend.org.uk/~xensrcts/logs/9160/ Regressions :-( Tests which did not succeed and are blocking: test-amd64-amd64-xl-pcipt-intel 8 debian-fixup fail REGR. vs. 9118 test-amd64-i386-xl-multivcpu 9 guest-start fail REGR. vs. 9118 test-amd64-i386-xl 9 guest-start fail REGR. vs. 9118 test-amd64-i386-xl-credit2 9 guest-start fail REGR. vs. 9118 test-amd64-i386-rhel6hvm-intel 7 redhat-install fail REGR. vs. 9118 test-i386-i386-xl 9 guest-start fail REGR. vs. 9118 test-amd64-amd64-xl-sedf 9 guest-start fail REGR. vs. 9118 test-amd64-amd64-xl 9 guest-start fail REGR. vs. 9118 test-amd64-i386-rhel6hvm-amd 7 redhat-install fail REGR. vs. 9118 test-amd64-i386-xl-win-vcpus1 7 windows-install fail REGR. vs. 9118 test-amd64-amd64-xl-win 7 windows-install fail REGR. vs. 9118 test-i386-i386-xl-win 7 windows-install fail REGR. vs. 9118 Tests which did not succeed, but are not blocking, including regressions (tests previously passed) regarded as allowable: test-amd64-i386-win-vcpus1 16 leak-check/check fail never pass test-amd64-i386-win 16 leak-check/check fail never pass test-amd64-amd64-win 16 leak-check/check fail never pass test-i386-i386-win 16 leak-check/check fail never pass version targeted for testing: xen e78cd03b0308 baseline version: xen 7998217630e2 ------------------------------------------------------------ People who touched revisions under test: Adin Scannell <adin@scannell.ca> Anthony PERARD <anthony.perard@citrix.com> Ian Campbell <ian.campbell@citrix.com> Ian Jackson <ian.jackson.citrix.com> Ian Jackson <ian.jackson@eu.citrix.com> Olaf Hering <olaf@aepfle.de> ------------------------------------------------------------ jobs: build-amd64 pass build-i386 pass build-amd64-oldkern pass build-i386-oldkern pass build-amd64-pvops pass build-i386-pvops pass test-amd64-amd64-xl fail test-amd64-i386-xl fail test-i386-i386-xl fail test-amd64-i386-rhel6hvm-amd fail test-amd64-i386-xl-credit2 fail test-amd64-amd64-xl-pcipt-intel fail test-amd64-i386-rhel6hvm-intel fail test-amd64-i386-xl-multivcpu fail test-amd64-amd64-pair pass test-amd64-i386-pair pass test-i386-i386-pair pass test-amd64-amd64-pv pass test-amd64-i386-pv pass test-i386-i386-pv pass test-amd64-amd64-xl-sedf fail test-amd64-i386-win-vcpus1 fail test-amd64-i386-xl-win-vcpus1 fail test-amd64-amd64-win fail test-amd64-i386-win fail test-i386-i386-win fail test-amd64-amd64-xl-win fail test-i386-i386-xl-win fail ------------------------------------------------------------ sg-report-flight on woking.cam.xci-test.com logs: /home/xc_osstest/logs images: /home/xc_osstest/images Logs, config files, etc. are available at http://www.chiark.greenend.org.uk/~xensrcts/logs Test harness code can be found at http://xenbits.xensource.com/gitweb?p=osstest.git;a=summary Not pushing. ------------------------------------------------------------ changeset: 23894:e78cd03b0308 tag: tip user: Anthony PERARD <anthony.perard@citrix.com> date: Thu Sep 29 16:31:24 2011 +0100 libxl: libxl_qmp: use of libxl__fd_set_cloexec. Signed-off-by: Anthony PERARD <anthony.perard@citrix.com> Acked-by: Ian Jackson <ian.jackson@eu.citrix.com> Committed-by: Ian Jackson <ian.jackson@eu.citrix.com> changeset: 23893:95a40ee93806 user: Anthony PERARD <anthony.perard@citrix.com> date: Thu Sep 29 16:30:54 2011 +0100 libxl: Introduce a QMP client QMP stands for QEMU Monitor Protocol and it is used to query information from QEMU or to control QEMU. This implementation will ask QEMU the list of chardevice and store the path to serial ports in xenstored. So we will be able to use xl console with QEMU upstream. In order to connect to the QMP server, a socket file is created in /var/run/xen/qmp-libxl-$(domid). Signed-off-by: Anthony PERARD <anthony.perard@citrix.com> Committed-by: Ian Jackson <ian.jackson@eu.citrix.com> changeset: 23892:5f397994e6d6 user: Anthony PERARD <anthony.perard@citrix.com> date: Thu Sep 29 16:28:24 2011 +0100 libxl: Introduce JSON parser We use the yajl parser, but we need to make a tree from the parse result to use it outside the parser. So this patch include json_object struct that is used to hold the JSON data. Signed-off-by: Anthony PERARD <anthony.perard@citrix.com> Committed-by: Ian Jackson <ian.jackson.citrix.com> Acked-by: Ian Campbell <ian.campbell@citrix.com> changeset: 23891:066dc3758fa4 user: Anthony PERARD <anthony.perard@citrix.com> date: Thu Sep 29 16:28:23 2011 +0100 libxl: Intruduce libxl__strndup. Signed-off-by: Anthony PERARD <anthony.perard@citrix.com> Committed-by: Ian Jackson <ian.jackson.citrix.com> Acked-by: Ian Campbell <ian.campbell@citrix.com> changeset: 23890:952e0118a7c4 user: Anthony PERARD <anthony.perard@citrix.com> date: Thu Sep 29 16:28:22 2011 +0100 libxl: Introduce libxl__realloc. Signed-off-by: Anthony PERARD <anthony.perard@citrix.com> Committed-by: Ian Jackson <ian.jackson.citrix.com> Acked-by: Ian Campbell <ian.campbell@citrix.com> changeset: 23889:f51dcd8acb7b user: Anthony PERARD <anthony.perard@citrix.com> date: Thu Sep 29 16:28:22 2011 +0100 libxl: Introduce libxl_internal_types.idl. Signed-off-by: Anthony PERARD <anthony.perard@citrix.com> Committed-by: Ian Jackson <ian.jackson.citrix.com> Acked-by: Ian Campbell <ian.campbell@citrix.com> changeset: 23888:f5ee5ad45425 user: Anthony PERARD <anthony.perard@citrix.com> date: Thu Sep 29 16:28:21 2011 +0100 libxl: Add get/set_default_namespace in libxltypes.py. Signed-off-by: Anthony PERARD <anthony.perard@citrix.com> Committed-by: Ian Jackson <ian.jackson.citrix.com> Acked-by: Ian Campbell <ian.campbell@citrix.com> changeset: 23887:a543e10211f7 user: Anthony PERARD <anthony.perard@citrix.com> date: Thu Sep 29 16:28:20 2011 +0100 libxl: Rename libxl.idl to libxl_types.idl. Signed-off-by: Anthony PERARD <anthony.perard@citrix.com> Committed-by: Ian Jackson <ian.jackson.citrix.com> Acked-by: Ian Campbell <ian.campbell@citrix.com> changeset: 23886:cf2ba5720151 user: Anthony PERARD <anthony.perard@citrix.com> date: Thu Sep 29 16:06:02 2011 +0100 libxl: Introduce libxl__fd_set_cloexec Signed-off-by: Anthony PERARD <anthony.perard@citrix.com> Acked-by: Ian Jackson <ian.jackson@eu.citrix.com> Committed-by: Ian Jackson <ian.jackson@eu.citrix.com> changeset: 23885:cd60c87d3496 user: Ian Campbell <ian.campbell@citrix.com> date: Thu Sep 29 15:40:34 2011 +0100 xl: fixup command line handling for several commands. def_getopt already checks for a minimum number of arguments for us. "xl save" simply need to use the correct argument for that value, contrary to the change I made in 23876:b113d626cfaf "xl block-list" does not need to check for at least 2 arguments, since it's already been done by def_getopt. "xl network-list" would previous accept zero arguments and just print the table header. Insist on a domain argument. Signed-off-by: Ian Campbell <ian.campbell@citrix.com> Acked-by: Ian Jackson <ian.jackson@eu.citrix.com> Committed-by: Ian Jackson <ian.jackson@eu.citrix.com> changeset: 23884:145e146876b3 user: Adin Scannell <adin@gridcentric.com> date: Thu Sep 29 15:26:04 2011 +0100 libxl: Expose number of shared pages Signed-off-by: Adin Scannell <adin@scannell.ca> Acked-by: Ian Jackson <ian.jackson@eu.citrix.com> Committed-by: Ian Jackson <ian.jackson@eu.citrix.com> changeset: 23883:7998217630e2 user: Ian Campbell <ian.campbell@citrix.com> date: Wed Sep 28 16:42:11 2011 +0100 libxl: attempt to cleanup tapdisk processes on disk backend destroy. Signed-off-by: Ian Campbell <ian.campbell@citrix.com> Committed-by: Ian Jackson <ian.jackson@eu.citrix.com> ======================================== commit cd776ee9408ff127f934a707c1a339ee600bc127 Author: Ian Jackson <ian.jackson@eu.citrix.com> Date: Tue Jun 28 13:50:53 2011 +0100 qemu-char.c: fix incorrect CONFIG_STUBDOM handling qemu-char.c:1123:7: warning: "CONFIG_STUBDOM" is not defined [-Wundef] Signed-off-by: Olaf Hering <olaf@aepfle.de> Acked-by: Ian Jackson <ian.jackson@eu.citrix.com> _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel From xen-devel-bounces@lists.xensource.com Fri Sep 30 07:08:25 2011 Return-path: <xen-devel-bounces@lists.xensource.com> Envelope-to: www-data@lists.xensource.com Delivery-date: Fri, 30 Sep 2011 07:08:25 -0700 Received: from localhost ([127.0.0.1] helo=lists.colo.xensource.com) by lists.xensource.com with esmtp (Exim 4.43) id 1R9dlI-0002EQ-Jd; Fri, 30 Sep 2011 07:08:25 -0700 Received: from mail27.messagelabs.com ([193.109.254.147]) by lists.xensource.com with esmtp (Exim 4.43) id 1R9dh6-0001W7-FF for xen-devel@lists.xensource.com; Fri, 30 Sep 2011 07:04:05 -0700 X-Env-Sender: Ian.Jackson@eu.citrix.com X-Msg-Ref: server-5.tower-27.messagelabs.com!1317391420!47059876!1 X-Originating-IP: [62.200.22.115] X-StarScan-Version: 6.4.1; banners=-,-,- X-VirusChecked: Checked Received: (qmail 7781 invoked from network); 30 Sep 2011 14:03:40 -0000 Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115) by server-5.tower-27.messagelabs.com with RC4-SHA encrypted SMTP; 30 Sep 2011 14:03:40 -0000 X-IronPort-AV: E=Sophos;i="4.68,467,1312156800"; d="scan'208";a="8153950" Received: from lonpmailmx01.citrite.net ([10.30.203.162]) by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5; 30 Sep 2011 14:04:01 +0000 Received: from norwich.cam.xci-test.com (10.80.248.129) by smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id 8.3.137.0; Fri, 30 Sep 2011 15:04:01 +0100 Received: from mariner.cam.xci-test.com ([10.80.2.22] helo=mariner.uk.xensource.com ident=Debian-exim) by norwich.cam.xci-test.com with esmtp (Exim 4.72) (envelope-from <Ian.Jackson@eu.citrix.com>) id 1R9dh2-0005tG-VB for xen-devel@lists.xensource.com; Fri, 30 Sep 2011 14:04:00 +0000 Received: from iwj by mariner.uk.xensource.com with local (Exim 4.69) (envelope-from <Ian.Jackson@eu.citrix.com>) id 1R9dh2-0002sa-TV for xen-devel@lists.xensource.com; Fri, 30 Sep 2011 15:04:00 +0100 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Message-ID: <20101.52304.905263.61953@mariner.uk.xensource.com> Date: Fri, 30 Sep 2011 15:04:00 +0100 To: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com> In-Reply-To: <osstest-9121-mainreport@xen.org> References: <osstest-9121-mainreport@xen.org> X-Mailer: VM 8.0.9 under Emacs 21.4.1 (i486-pc-linux-gnu) From: Ian Jackson <Ian.Jackson@eu.citrix.com> Subject: [Xen-devel] Re: [xen-unstable test] 9121: regressions - FAIL X-BeenThere: xen-devel@lists.xensource.com X-Mailman-Version: 2.1.5 Precedence: list List-Id: Xen developer discussion <xen-devel.lists.xensource.com> List-Unsubscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe> List-Post: <mailto:xen-devel@lists.xensource.com> List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help> List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=subscribe> Sender: xen-devel-bounces@lists.xensource.com Errors-To: xen-devel-bounces@lists.xensource.com xen.org writes ("[xen-unstable test] 9121: regressions - FAIL"): > flight 9121 xen-unstable real [real] > http://www.chiark.greenend.org.uk/~xensrcts/logs/9121/ > > Regressions :-( > > Tests which did not succeed and are blocking: > test-amd64-i386-xl-multivcpu 9 guest-start fail REGR. vs. 9118 This is due to my test system not installing the libyajl runtime. I have committed a change to make it do this which will bubble through after it has passed its own tests once or twice. Ian. _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel From xen-devel-bounces@lists.xensource.com Fri Sep 30 07:10:59 2011 Return-path: <xen-devel-bounces@lists.xensource.com> Envelope-to: www-data@lists.xensource.com Delivery-date: Fri, 30 Sep 2011 07:10:59 -0700 Received: from localhost ([127.0.0.1] helo=lists.colo.xensource.com) by lists.xensource.com with esmtp (Exim 4.43) id 1R9dnm-0002cV-T1; Fri, 30 Sep 2011 07:10:58 -0700 Received: from mail216.messagelabs.com ([85.158.143.99]) by lists.xensource.com with esmtp (Exim 4.43) id 1R9dmV-0002Mz-9X for xen-devel@lists.xensource.com; Fri, 30 Sep 2011 07:09:40 -0700 X-Env-Sender: Stefano.Stabellini@eu.citrix.com X-Msg-Ref: server-13.tower-216.messagelabs.com!1317391775!18484365!1 X-Originating-IP: [62.200.22.115] X-StarScan-Version: 6.4.1; banners=-,-,- X-VirusChecked: Checked Received: (qmail 26021 invoked from network); 30 Sep 2011 14:09:35 -0000 Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115) by server-13.tower-216.messagelabs.com with RC4-SHA encrypted SMTP; 30 Sep 2011 14:09:35 -0000 X-IronPort-AV: E=Sophos;i="4.68,467,1312156800"; d="scan'208";a="8154086" Received: from lonpmailmx01.citrite.net ([10.30.203.162]) by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5; 30 Sep 2011 14:09:35 +0000 Received: from kaball.uk.xensource.com (10.80.2.59) by LONPMAILMX01.citrite.net (10.30.203.162) with Microsoft SMTP Server id 8.3.137.0; Fri, 30 Sep 2011 15:09:35 +0100 Date: Fri, 30 Sep 2011 15:09:13 +0100 From: Stefano Stabellini <stefano.stabellini@eu.citrix.com> X-X-Sender: sstabellini@kaball-desktop To: Stefan Bader <stefan.bader@canonical.com> Subject: Re: [Xen-devel] Re: Still struggling with HVM: tx timeouts on emulated nics In-Reply-To: <4E85883C.7030808@canonical.com> Message-ID: <alpine.DEB.2.00.1109301427590.3519@kaball-desktop> References: <4E7B4768.8060103@canonical.com> <alpine.DEB.2.00.1109221838370.8700@kaball-desktop> <4E85883C.7030808@canonical.com> User-Agent: Alpine 2.00 (DEB 1167 2008-08-23) MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>, Stefano Stabellini <Stefano.Stabellini@eu.citrix.com> X-BeenThere: xen-devel@lists.xensource.com X-Mailman-Version: 2.1.5 Precedence: list List-Id: Xen developer discussion <xen-devel.lists.xensource.com> List-Unsubscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe> List-Post: <mailto:xen-devel@lists.xensource.com> List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help> List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=subscribe> Sender: xen-devel-bounces@lists.xensource.com Errors-To: xen-devel-bounces@lists.xensource.com On Fri, 30 Sep 2011, Stefan Bader wrote: > On 22.09.2011 19:44, Stefano Stabellini wrote: > > On Thu, 22 Sep 2011, Stefan Bader wrote: > >> On 22.09.2011 13:58, Stefan Bader wrote: > >>> On 22.09.2011 12:30, Stefano Stabellini wrote: > >>>> On Wed, 21 Sep 2011, Stefan Bader wrote: > >>>>> On 21.09.2011 15:31, Stefano Stabellini wrote: > >>>>>> On Wed, 21 Sep 2011, Stefan Bader wrote: > >>>>>>> This is on 3.0.4 based dom0 and domU with 4.1.1 hypervisor. I tried using the > >>>>>>> default 8139cp and ne2k_pci emulated nic. The 8139cp one at least comes up and > >>>>>>> gets configured via dhcp. And initial pings also get routed and done correctly. > >>>>>>> But slightly higher traffic (like checking for updates) hangs. And after a while > >>>>>>> there are messages about tx timeouts. > >>>>>>> The ne2k_pci type nic almost immediately has those issues and never comes up > >>>>>>> correctly. > >>>>>>> > >>>>>>> I am attaching the dmesg of the guest with apic=debug enabled. I am not sure how > >>>>>>> this should be but both nics get configured with level,low IRQs. Disk emulation > >>>>>>> seems to be ok but that seem to use IO-APIC-edge. And any other IRQs seem to be > >>>>>>> at least not level. > >>>>>> > >>>>> > >>>>>> Does the e1000 emulated card work correctly? > >>>>> > >>>>> Yes, that one seems to work ok. > >>>>> > >>>>>> What happens if you disable interrupt remapping (see patch below)? > >>>>> > >>>>> 8139cp seems to work correctly now (much higher irq stats as well) and e1000 > >>>>> still works. Both then using IOAPIC-fasteoi. > >>>>> > >>>> > >>>> That means there must be another subtle bug in Xen in interrupt > >>>> remapping that only affects 8139p emulation > >>>> > >>> Right, or to be complete: > >>> - e1000: ok > >>> - 8139cp: unstable (setup is possible) > >>> - ne2k_pci: not working (tx problems from the beginning) > >>> > >>> The behaviour feels a bit like interrupts may get lost if occurring at a higher > >>> rate. Why this affects various drivers differently is a bit weird. > >>>> > >> > >> This is mainly speculating... Quite a while back there was this patch to events: > >> > >> commit dffe2e1e1a1ddb566a76266136c312801c66dcf7 > >> Author: Jeremy Fitzhardinge <jeremy.fitzhardinge@citrix.com> > >> Date: Fri Aug 20 19:10:01 2010 -0700 > >> > >> xen: handle events as edge-triggered > >> > >> The commit message stated that Xen events are logically edge triggered. So PV > >> events were changed to be handled as edge interrupts. Would that not mean that > >> for xen-pirq-apic being using events this would apply the same and those should > >> be apic-edge instead of level? > > > > That commit is referring to the internal way Linux handles these event, > > that look like normal interrupt to the Linux irq subsystem. It is not > > related to the way actual events are delivered from Xen to Linux, so it > > shouldn't matter here. > > > > I would add lots of printk's in: > > > > xen/arch/x86/hvm/irq.c:__hvm_pci_intx_assert > > xen/arch/x86/hvm/irq.c:assert_irq > > xen/arch/x86/hvm/irq.c:assert_gsi > > > > to find out why xen is not injecting those interrupts > > > > _______________________________________________ > > Xen-devel mailing list > > Xen-devel@lists.xensource.com > > http://lists.xensource.com/xen-devel > > It took quite a bit of time but at least I got some hopefully useful information > now. So in general, whenever an interrupt is asserted, > the hypervisor runs through this: > > __hvm_pci_intx_assert: > when assert count was 0 before incrementing > call assert_gsi > call send_guest_pirq (when hvm uses pirq) > > In the send_guest_pirq chain is a call to evtchn_set_pending which tests as one > of the first actions whether evtchn_pending in the shared_info is set. If that > is the case the call immediately returns with 1. > > Adding printks to call_assert_gsi, I noticed that > - When things stop working, the last call to send_guest_pirq returned 1. > - But not every time the return code is one, the stall happens. > - e1000 also has cases where send_guest_pirq returns 1 but they happen much > less often (than using the 8139cp). > > Usually every intx_assert has a intx_deassert call that follows. when the stall > occurs, this does not happen. Right here I got some troubles to understand where > this intx_deassert is actually triggered. With an added WARN_ON the stack traces > seem odd, like this: > > (XEN) [<ffff82c4801abd9c>] __hvm_pci_intx_deassert+0x6c/0x130 > (XEN) [<ffff82c4801ac43e>] hvm_pci_intx_deassert+0x3e/0x60 > (XEN) [<ffff82c4801a8148>] do_hvm_op+0x3b8/0x1e60 > (XEN) [<ffff82c480168ea1>] do_update_descriptor+0x171/0x220 > (XEN) [<ffff82c48017dba6>] copy_from_user+0x26/0x90 > (XEN) [<ffff82c4801f9446>] do_iret+0xb6/0x1a0 > (XEN) [<ffff82c4801f4f28>] syscall_enter+0x88/0x8d > > Not really sure how one gets from do_update_descriptor to do_hvm_op and the only > thing in there which does the deassert is some irq level setting. > > Actually the guest does not really do much do EOI (which I had been assuming). > But since domain_pirq_to_irq maps to 0 for emuirqs, the call to > PHYSDEVOP_irq_status_query will hit the following and not set the flag for > needing EOI. > > irq_status_query.flags = 0; > if ( is_hvm_domain(v->domain) && > domain_pirq_to_irq(v->domain, irq) <= 0 ) > { > ret = copy_to_guest(arg, &irq_status_query, 1) ? -EFAULT : 0; > break; > } > > So all the guest is doing is to clear evtchn_pending in the pirq EOI function. I > fail to understand what actually is doing the hvm_pci_intx_deassert calls but > the way the fasteoi code in the guest looks to be working, there seems to be > some gap between calling the handler and the eoi function... So from what I see, > I would assume the following: > > dom0 domU > - intx_assert (count 0->1) > - send_guest_pirq = 0 > (evtchn_pending = 1) > - upcall starts fasteoi handler > - something does intx_deassert > (count 1->0) > - intx_assert (count 0->1) > - send_guest_pirq = 1 > (evtchn_pending still set) > - handler->eoi sets evtchn to 0 but > otherwise does nothing > - there is no intx_deassert, so even > when another intx_assert would happen > (which does not seem to be the case) > no further send_guest_pirq would be > called. > > Unfortunately I do miss some details on the inner working here. Generally I > wonder whether not setting the needsEOI flag for those pirqs just is the > problem. But it also could be intentional... Thanks for the very detailed analysis. It seems to me that the problem is that if the interrupt is a level triggered interrupt when the guest issues an EOI we should be reinjecting the interrupt again if it has been issued a second time in the meantime. However this doesn't happen if the interrupt has been remapped onto an even channel. In that case the guest is not even going to issue an EOI at all. So I wrote a patch to force the guest to issue EOIs even on remapped irqs; in the hypercall handler we check whether we need to reinject the interrupt and if that is the case we set the corresponding event channel pending. Could you please try the patch I appended? I haven't been able to reproduce your problem so I am not really sure if it works. diff -r e042fb60e0ee xen/arch/x86/physdev.c --- a/xen/arch/x86/physdev.c Thu Sep 29 11:23:01 2011 +0000 +++ b/xen/arch/x86/physdev.c Fri Sep 30 14:01:46 2011 +0000 @@ -11,6 +11,7 @@ #include <asm/current.h> #include <asm/io_apic.h> #include <asm/msi.h> +#include <asm/hvm/irq.h> #include <asm/hypercall.h> #include <public/xen.h> #include <public/physdev.h> @@ -270,6 +271,18 @@ ret_t do_physdev_op(int cmd, XEN_GUEST_H if ( !is_hvm_domain(v->domain) || domain_pirq_to_irq(v->domain, eoi.irq) > 0 ) pirq_guest_eoi(pirq); + if ( is_hvm_domain(v->domain) && + domain_pirq_to_emuirq(v->domain, eoi.irq) > 0 ) + { + struct hvm_irq *hvm_irq = &v->domain->arch.hvm_domain.irq; + int gsi = domain_pirq_to_emuirq(v->domain, eoi.irq); + + /* if this is a level irq and count > 0, send another + * notification */ + if ( gsi >= NR_ISAIRQS /* ISA irqs are edge triggered */ + && hvm_irq->gsi_assert_count[gsi] ) + send_guest_pirq(v->domain, pirq); + } spin_unlock(&v->domain->event_lock); ret = 0; break; @@ -327,12 +340,6 @@ ret_t do_physdev_op(int cmd, XEN_GUEST_H if ( (irq < 0) || (irq >= v->domain->nr_pirqs) ) break; irq_status_query.flags = 0; - if ( is_hvm_domain(v->domain) && - domain_pirq_to_irq(v->domain, irq) <= 0 ) - { - ret = copy_to_guest(arg, &irq_status_query, 1) ? -EFAULT : 0; - break; - } /* * Even edge-triggered or message-based IRQs can need masking from _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel From xen-devel-bounces@lists.xensource.com Fri Sep 30 07:12:33 2011 Return-path: <xen-devel-bounces@lists.xensource.com> Envelope-to: www-data@lists.xensource.com Delivery-date: Fri, 30 Sep 2011 07:12:33 -0700 Received: from localhost ([127.0.0.1] helo=lists.colo.xensource.com) by lists.xensource.com with esmtp (Exim 4.43) id 1R9dpJ-00030F-B1; Fri, 30 Sep 2011 07:12:33 -0700 Received: from mail21.messagelabs.com ([85.158.143.35]) by lists.xensource.com with esmtp (Exim 4.43) id 1R9dn3-0002S3-0P for xen-devel@lists.xensource.com; Fri, 30 Sep 2011 07:10:13 -0700 X-Env-Sender: konrad@oracle.com X-Msg-Ref: server-5.tower-21.messagelabs.com!1317391773!50165523!1 X-Originating-IP: [148.87.113.117] X-StarScan-Version: 6.4.1; banners=-,-,- X-VirusChecked: Checked Received: (qmail 8225 invoked from network); 30 Sep 2011 14:09:34 -0000 Received: from rcsinet15.oracle.com (HELO rcsinet15.oracle.com) (148.87.113.117) by server-5.tower-21.messagelabs.com with DHE-RSA-AES256-SHA encrypted SMTP; 30 Sep 2011 14:09:34 -0000 Received: from rtcsinet22.oracle.com (rtcsinet22.oracle.com [66.248.204.30]) by rcsinet15.oracle.com (Switch-3.4.4/Switch-3.4.4) with ESMTP id p8UEA3cG025638 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Fri, 30 Sep 2011 14:10:05 GMT Received: from acsmt358.oracle.com (acsmt358.oracle.com [141.146.40.158]) by rtcsinet22.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id p8UEA0Rx021801 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 30 Sep 2011 14:10:01 GMT Received: from abhmt103.oracle.com (abhmt103.oracle.com [141.146.116.55]) by acsmt358.oracle.com (8.12.11.20060308/8.12.11) with ESMTP id p8UE9rx7010827; Fri, 30 Sep 2011 09:09:53 -0500 Received: from oracle.com (/207.172.105.198) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Fri, 30 Sep 2011 07:09:52 -0700 Received: by oracle.com (Postfix, from userid 1000) id B66CA46E; Fri, 30 Sep 2011 10:09:49 -0400 (EDT) Date: Fri, 30 Sep 2011 10:09:49 -0400 From: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com> To: Thomas Hellstrom <thellstrom@vmware.com> Message-ID: <20110930140949.GA18905@phenom.oracle.com> References: <1317328432-25620-1-git-send-email-konrad.wilk@oracle.com> <4E8568E8.1070800@vmware.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <4E8568E8.1070800@vmware.com> User-Agent: Mutt/1.5.21 (2010-09-15) X-Source-IP: rtcsinet22.oracle.com [66.248.204.30] X-CT-RefId: str=0001.0A090201.4E85CDBD.00E3,ss=1,re=0.000,fgs=0 Cc: xen-devel@lists.xensource.com, thomas@shipmail.org, airlied@linux.ie, linux-kernel@vger.kernel.org, dri-devel@lists.freedesktop.org, j.glisse@redhat.com, alexdeucher@gmail.com, airlied@redhat.com, bskeggs@redhat.com Subject: [Xen-devel] Re: [PATCH] TTM DMA pool v1.8 X-BeenThere: xen-devel@lists.xensource.com X-Mailman-Version: 2.1.5 Precedence: list List-Id: Xen developer discussion <xen-devel.lists.xensource.com> List-Unsubscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe> List-Post: <mailto:xen-devel@lists.xensource.com> List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help> List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=subscribe> Sender: xen-devel-bounces@lists.xensource.com Errors-To: xen-devel-bounces@lists.xensource.com On Fri, Sep 30, 2011 at 08:59:52AM +0200, Thomas Hellstrom wrote: > Konrad, > > I'm really sorry for taking so long to review this. That is OK. We all are busy - and it gave me some time to pretty up the code even more. > > I'd like to go through a couple of high-level things first before > reviewing the coding itself. > > The page_alloc_func structure looks nice, but I'd like to have it > per ttm backend, Meaning the 'struct ttm_backend_func' right? > we would just need to make sure that the backend is alive when we > alloc / free pages. > The reason for this is that there may be backends that want to > allocate dma memory running simultaneously with those who don't. As in for some TTM manager use the non-DMA, and for other DMA (is_dma32 is set?) Or say two cards - one that has the concept of MMU and one that does not and both of them are readeon? > When the backend fires up, it can determine whether to use DMA > memory or not. Or more of backends (and drivers) that do not have any concept of MMU and just use framebuffers and such? I think we would just have to stick in a pointer to the appropiate 'struct ttm_page_alloc_func' (and the 'struct device') in the 'struct ttm_backend_func'. And this would be done by backend that would decided which one to use. And the TTM could find out which page_alloc_func to use straight from the ttm_backend_func and call that (along with the 'struct device' also gathered from that structure). Rough idea (on top of the patches): diff --git a/drivers/gpu/drm/ttm/ttm_page_alloc.c b/drivers/gpu/drm/ttm/ttm_page_alloc.c index dd05db3..e7a0c3c 100644 --- a/drivers/gpu/drm/ttm/ttm_page_alloc.c +++ b/drivers/gpu/drm/ttm/ttm_page_alloc.c @@ -902,12 +902,12 @@ struct ttm_page_alloc_func ttm_page_alloc_default = { int ttm_get_pages(struct list_head *pages, int flags, enum ttm_caching_state cstate, unsigned count, - dma_addr_t *dma_address, struct device *dev) + dma_addr_t *dma_address, struct ttm_backend *be) { - if (ttm_page_alloc && ttm_page_alloc->get_pages) - return ttm_page_alloc->get_pages(pages, flags, cstate, count, - dma_address, dev); - return -1; + if (be->page_backend && be->page_backend->get_pages) + return be->page_backend->get_pages(pages, flags, cstate, count, + dma_address, be->dev); + return __ttm_get_pages(pages, flags, cstate, count, dma_address, NULL); } void ttm_put_pages(struct list_head *pages, unsigned page_count, int flags, enum ttm_caching_state cstate, dma_addr_t *dma_address, diff --git a/drivers/gpu/drm/ttm/ttm_tt.c b/drivers/gpu/drm/ttm/ttm_tt.c index 0f5ce97..0d75213 100644 --- a/drivers/gpu/drm/ttm/ttm_tt.c +++ b/drivers/gpu/drm/ttm/ttm_tt.c @@ -111,7 +111,7 @@ static struct page *__ttm_tt_get_page(struct ttm_tt *ttm, int index) INIT_LIST_HEAD(&h); ret = ttm_get_pages(&h, ttm->page_flags, ttm->caching_state, 1, - &ttm->dma_address[index], ttm->dev); + &ttm->dma_address[index], ttm->be); if (ret != 0) return NULL; diff --git a/include/drm/ttm/ttm_bo_driver.h b/include/drm/ttm/ttm_bo_driver.h index 6509544..9729753 100644 --- a/include/drm/ttm/ttm_bo_driver.h +++ b/include/drm/ttm/ttm_bo_driver.h @@ -100,6 +100,18 @@ struct ttm_backend_func { * Destroy the backend. */ void (*destroy) (struct ttm_backend *backend); + + /* + * Pointer to the struct ttm_page_alloc_func this backend wants + * to use. + */ + struct ttm_page_alloc_func *page_backend; + + /* + * The device that the ttm_page_alloc_func should use for this + * backend. + */ + struct device *dev; }; /** > > This also eliminates the need for patch 3/9. and is in line with patch 8/9. <nods> That would be " ttm: Pass in 'struct device' to TTM so it can do DMA API on behalf of device." as now the driver would be responsible for saving that. And "ttm/tt: Move ttm_tt_set_page_caching implementation in TTM page pool code." would still be there, except it would be done per ttm-backend. Well by choosing which TTM page pool the TTM backend would use. > > 2) Memory accounting: If the number DMA pages are limited in a way > that the ttm memory global routines are not aware of. How do we > handle memory accounting? (How do we avoid exhausting IOMMU space)? Good question. Not entirely sure about that. I know that on SWIOTLB there is no limit (as you do not use the bounce buffer) but not sure about VT-D, AMD-VI, GART, or when there is no IOMMU. Let me get back to you on that. Granted, the code _only_ gets activated when we use SWIOTLB right now so the answer is "no exhausting" currently. Either way let me dig a bit deeper. > > 3) Page swapping. Currently we just copy pages to shmem pages and > then free device pages. In the future we'd probably like to insert > non-dma pages directly into the swap cache. Is it possible to > differentiate dma pages from pages that are directly insertable? Yes. The TTM DMA pool keeps track of which pages belong to which pool and will reject non-dma pages (or pages which belong to a different pool). It is fairly easy to expose that check so that the generic TTM code can make the proper distinction. But also - once you free a device page ('cached') it gets freed. The other pages (writecombine, writeback, uncached) end up sitting in a recycle pool to be used. This is believe how the current TTM page code works right now (and this TTM DMA pool follows). The swapping code back (so from swap to pool) does not seem to distinguish it that much - it just allocates a new page - and then copies from whatever was in the swap cache? This is something you were thinking to do in the future I presume? _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel From xen-api-bounces@lists.xensource.com Fri Sep 30 07:13:12 2011 Return-path: <xen-api-bounces@lists.xensource.com> Envelope-to: www-data@lists.xensource.com Delivery-date: Fri, 30 Sep 2011 07:13:12 -0700 Received: from localhost ([127.0.0.1] helo=lists.colo.xensource.com) by lists.xensource.com with esmtp (Exim 4.43) id 1R9dpv-0003E1-79; Fri, 30 Sep 2011 07:13:11 -0700 Received: from mail182.messagelabs.com ([85.158.139.83]) by lists.xensource.com with esmtp (Exim 4.43) id 1R9doG-0002iK-9E; Fri, 30 Sep 2011 07:11:28 -0700 X-Env-Sender: konrad@oracle.com X-Msg-Ref: server-6.tower-182.messagelabs.com!1317391883!19189771!1 X-Originating-IP: [148.87.113.117] X-StarScan-Version: 6.4.1; banners=-,-,- X-VirusChecked: Checked Received: (qmail 20842 invoked from network); 30 Sep 2011 14:11:24 -0000 Received: from rcsinet15.oracle.com (HELO rcsinet15.oracle.com) (148.87.113.117) by server-6.tower-182.messagelabs.com with DHE-RSA-AES256-SHA encrypted SMTP; 30 Sep 2011 14:11:24 -0000 Received: from acsinet21.oracle.com (acsinet21.oracle.com [141.146.126.237]) by rcsinet15.oracle.com (Switch-3.4.4/Switch-3.4.4) with ESMTP id p8UEBK0o027113 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Fri, 30 Sep 2011 14:11:22 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 p8UEBKJp026186 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 30 Sep 2011 14:11:20 GMT Received: from abhmt120.oracle.com (abhmt120.oracle.com [141.146.116.72]) by acsmt358.oracle.com (8.12.11.20060308/8.12.11) with ESMTP id p8UEBEhD011903; Fri, 30 Sep 2011 09:11:14 -0500 Received: from oracle.com (/207.172.105.198) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Fri, 30 Sep 2011 07:11:14 -0700 Received: by oracle.com (Postfix, from userid 1000) id B037346E; Fri, 30 Sep 2011 10:11:11 -0400 (EDT) Date: Fri, 30 Sep 2011 10:11:11 -0400 From: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com> To: Lars Kurth <lars.kurth@xen.org>, JBeulich@suse.com Message-ID: <20110930141111.GB18905@phenom.oracle.com> References: <4E85A513.6030403@xen.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <4E85A513.6030403@xen.org> User-Agent: Mutt/1.5.21 (2010-09-15) X-Source-IP: acsinet21.oracle.com [141.146.126.237] X-Auth-Type: Internal IP X-CT-RefId: str=0001.0A090201.4E85CE0A.024E:SCFMA922111,ss=1,re=-4.000,fgs=0 Cc: xen-arm@lists.xensource.com, "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>, "xen-api@lists.xensource.com" <xen-api@lists.xensource.com> Subject: [Xen-API] Re: [Xen-devel] Please welcome Jan Beulich as Xen committer & revisions to Xen governance X-BeenThere: xen-api@lists.xensource.com X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussion of API issues surrounding Xen <xen-api.lists.xensource.com> List-Unsubscribe: <http://lists.xensource.com/mailman/listinfo/xen-api>, <mailto:xen-api-request@lists.xensource.com?subject=unsubscribe> List-Post: <mailto:xen-api@lists.xensource.com> List-Help: <mailto:xen-api-request@lists.xensource.com?subject=help> List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-api>, <mailto:xen-api-request@lists.xensource.com?subject=subscribe> Sender: xen-api-bounces@lists.xensource.com Errors-To: xen-api-bounces@lists.xensource.com On Fri, Sep 30, 2011 at 12:16:35PM +0100, Lars Kurth wrote: > Dear Xen developers, > > I wanted to announce that Jan Beulich has been nominated for as Xen > Hypervisor committer and confirmed by vote by the other Xen > committers (which are Keir Fraser, Tim Deegan and Ian Jackson). > > Jan's Contribution > ================== > Jan has made a tremendous contribution to the project over the years > and was was one of the top 3 contributors to the project for several > years. Just to quote a few stats > - 2009 : 107 patches changing 11746 lines of code > - 2010 : 147 patches changing 7613 lines of code > - 2011 : 204 patches changing 2655 lines of code > > Congratulations! Woohoo! Congratulations Jan! _______________________________________________ xen-api mailing list xen-api@lists.xensource.com http://lists.xensource.com/mailman/listinfo/xen-api From xen-devel-bounces@lists.xensource.com Fri Sep 30 07:14:48 2011 Return-path: <xen-devel-bounces@lists.xensource.com> Envelope-to: www-data@lists.xensource.com Delivery-date: Fri, 30 Sep 2011 07:14:48 -0700 Received: from localhost ([127.0.0.1] helo=lists.colo.xensource.com) by lists.xensource.com with esmtp (Exim 4.43) id 1R9drU-0003qb-9l; Fri, 30 Sep 2011 07:14:48 -0700 Received: from mail27.messagelabs.com ([193.109.254.147]) by lists.xensource.com with esmtp (Exim 4.43) id 1R9dp4-0002vq-Ii for xen-devel@lists.xensource.com; Fri, 30 Sep 2011 07:12:19 -0700 X-Env-Sender: Ian.Jackson@eu.citrix.com X-Msg-Ref: server-11.tower-27.messagelabs.com!1317391926!39607322!1 X-Originating-IP: [62.200.22.115] X-StarScan-Version: 6.4.1; banners=-,-,- X-VirusChecked: Checked Received: (qmail 8147 invoked from network); 30 Sep 2011 14:12:06 -0000 Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115) by server-11.tower-27.messagelabs.com with RC4-SHA encrypted SMTP; 30 Sep 2011 14:12:06 -0000 X-IronPort-AV: E=Sophos;i="4.68,467,1312156800"; d="scan'208";a="8154162" Received: from lonpmailmx01.citrite.net ([10.30.203.162]) by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5; 30 Sep 2011 14:12:15 +0000 Received: from norwich.cam.xci-test.com (10.80.248.129) by smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id 8.3.137.0; Fri, 30 Sep 2011 15:12:15 +0100 Received: from mariner.cam.xci-test.com ([10.80.2.22] helo=mariner.uk.xensource.com ident=Debian-exim) by norwich.cam.xci-test.com with esmtp (Exim 4.72) (envelope-from <Ian.Jackson@eu.citrix.com>) id 1R9dp1-0005vu-3w; Fri, 30 Sep 2011 14:12:15 +0000 Received: from iwj by mariner.uk.xensource.com with local (Exim 4.69) (envelope-from <Ian.Jackson@eu.citrix.com>) id 1R9dp1-0002tW-3L; Fri, 30 Sep 2011 15:12:15 +0100 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Message-ID: <20101.52799.95729.431768@mariner.uk.xensource.com> Date: Fri, 30 Sep 2011 15:12:15 +0100 To: Ian Campbell <Ian.Campbell@eu.citrix.com> In-Reply-To: <1317374174.26672.249.camel@zakaz.uk.xensource.com> References: <1313764724-12683-1-git-send-email-dgdegra@tycho.nsa.gov> <1316729665-15004-1-git-send-email-dgdegra@tycho.nsa.gov> <1316729665-15004-2-git-send-email-dgdegra@tycho.nsa.gov> <1317374174.26672.249.camel@zakaz.uk.xensource.com> X-Mailer: VM 8.0.9 under Emacs 21.4.1 (i486-pc-linux-gnu) From: Ian Jackson <Ian.Jackson@eu.citrix.com> Cc: Daniel De Graaf <dgdegra@tycho.nsa.gov>, "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>, Stefano Stabellini <Stefano.Stabellini@eu.citrix.com>, "konrad.wilk@oracle.com" <konrad.wilk@oracle.com> Subject: [Xen-devel] Re: [PATCH 1/3] libxc: add xc_gnttab_map_grant_ref_notify X-BeenThere: xen-devel@lists.xensource.com X-Mailman-Version: 2.1.5 Precedence: list List-Id: Xen developer discussion <xen-devel.lists.xensource.com> List-Unsubscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe> List-Post: <mailto:xen-devel@lists.xensource.com> List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help> List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=subscribe> Sender: xen-devel-bounces@lists.xensource.com Errors-To: xen-devel-bounces@lists.xensource.com Ian Campbell writes ("Re: [PATCH 1/3] libxc: add xc_gnttab_map_grant_ref_notify"): > Not specifically to do with this patch but I wonder if we should try and > figure a way to version these shared libraries somehow, otherwise > changes like this lead to segfault at best and unexpected non-crashing > behaviour at worst (for out of tree backends that is). Our approach is to change the library major number at some point between releases. People using the development tree can expect instability. > Something as simple as checksumming the xenctrlosdep.h header and > including the value in the .so to be checked at load time would do the > trick. Urgh. Ian. _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel From xen-api-bounces@lists.xensource.com Fri Sep 30 07:15:57 2011 Return-path: <xen-api-bounces@lists.xensource.com> Envelope-to: www-data@lists.xensource.com Delivery-date: Fri, 30 Sep 2011 07:15:57 -0700 Received: from localhost ([127.0.0.1] helo=lists.colo.xensource.com) by lists.xensource.com with esmtp (Exim 4.43) id 1R9dsa-0004AN-2Y; Fri, 30 Sep 2011 07:15:56 -0700 Received: from mail216.messagelabs.com ([85.158.143.99]) by lists.xensource.com with esmtp (Exim 4.43) id 1R9dsP-000477-6L; Fri, 30 Sep 2011 07:15:47 -0700 X-Env-Sender: joseph.glanville@orionvm.com.au X-Msg-Ref: server-12.tower-216.messagelabs.com!1317392140!14410856!1 X-Originating-IP: [209.85.212.43] X-StarScan-Version: 6.4.1; banners=-,-,- X-VirusChecked: Checked Received: (qmail 2826 invoked from network); 30 Sep 2011 14:15:41 -0000 Received: from mail-vw0-f43.google.com (HELO mail-vw0-f43.google.com) (209.85.212.43) by server-12.tower-216.messagelabs.com with RC4-SHA encrypted SMTP; 30 Sep 2011 14:15:41 -0000 Received: by vws13 with SMTP id 13so1855931vws.30 for <multiple recipients>; Fri, 30 Sep 2011 07:15:40 -0700 (PDT) MIME-Version: 1.0 Received: by 10.52.97.131 with SMTP id ea3mr11546165vdb.443.1317392140125; Fri, 30 Sep 2011 07:15:40 -0700 (PDT) Received: by 10.220.195.135 with HTTP; Fri, 30 Sep 2011 07:15:40 -0700 (PDT) X-Originating-IP: [59.167.234.130] In-Reply-To: <20110930141111.GB18905@phenom.oracle.com> References: <4E85A513.6030403@xen.org> <20110930141111.GB18905@phenom.oracle.com> Date: Sat, 1 Oct 2011 00:15:40 +1000 Message-ID: <CAOzFzEgOyS7im=2pBG18PgeAWSPh9pMu5TFWZARz37t0yGneeg@mail.gmail.com> Subject: Re: [Xen-API] Re: [Xen-devel] Please welcome Jan Beulich as Xen committer & revisions to Xen governance From: Joseph Glanville <joseph.glanville@orionvm.com.au> To: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com> Cc: xen-arm@lists.xensource.com, "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>, JBeulich@suse.com, "xen-api@lists.xensource.com" <xen-api@lists.xensource.com> X-BeenThere: xen-api@lists.xensource.com X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussion of API issues surrounding Xen <xen-api.lists.xensource.com> List-Unsubscribe: <http://lists.xensource.com/mailman/listinfo/xen-api>, <mailto:xen-api-request@lists.xensource.com?subject=unsubscribe> List-Post: <mailto:xen-api@lists.xensource.com> List-Help: <mailto:xen-api-request@lists.xensource.com?subject=help> List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-api>, <mailto:xen-api-request@lists.xensource.com?subject=subscribe> Content-Type: multipart/mixed; boundary="===============1511090096==" Sender: xen-api-bounces@lists.xensource.com Errors-To: xen-api-bounces@lists.xensource.com --===============1511090096== Content-Type: multipart/alternative; boundary=20cf307cfc7e8ac61c04ae294272 --20cf307cfc7e8ac61c04ae294272 Content-Type: text/plain; charset=ISO-8859-1 Congratulations Jan. :) On 1 October 2011 00:11, Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>wrote: > On Fri, Sep 30, 2011 at 12:16:35PM +0100, Lars Kurth wrote: > > Dear Xen developers, > > > > I wanted to announce that Jan Beulich has been nominated for as Xen > > Hypervisor committer and confirmed by vote by the other Xen > > committers (which are Keir Fraser, Tim Deegan and Ian Jackson). > > > > Jan's Contribution > > ================== > > Jan has made a tremendous contribution to the project over the years > > and was was one of the top 3 contributors to the project for several > > years. Just to quote a few stats > > - 2009 : 107 patches changing 11746 lines of code > > - 2010 : 147 patches changing 7613 lines of code > > - 2011 : 204 patches changing 2655 lines of code > > > > Congratulations! > > Woohoo! Congratulations Jan! > > _______________________________________________ > xen-api mailing list > xen-api@lists.xensource.com > http://lists.xensource.com/mailman/listinfo/xen-api > -- * Founder | Director | VP Research Orion Virtualisation Solutions* | www.orionvm.com.au | Phone: 1300 56 99 52 | Mobile: 0428 754 846 --20cf307cfc7e8ac61c04ae294272 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Congratulations Jan. :)<br><br><div class=3D"gmail_quote">On 1 October 2011= 00:11, Konrad Rzeszutek Wilk <span dir=3D"ltr"><<a href=3D"mailto:konra= d.wilk@oracle.com">konrad.wilk@oracle.com</a>></span> wrote:<br><blockqu= ote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc s= olid;padding-left:1ex;"> <div class=3D"im">On Fri, Sep 30, 2011 at 12:16:35PM +0100, Lars Kurth wrot= e:<br> > Dear Xen developers,<br> ><br> > I wanted to announce that Jan Beulich has been nominated for as Xen<br= > > Hypervisor committer and confirmed by vote by the other Xen<br> > committers (which are Keir Fraser, Tim Deegan and Ian Jackson).<br> ><br> > Jan's Contribution<br> > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D<br> > Jan has made a tremendous contribution to the project over the years<b= r> > and was was one of the top 3 contributors to the project for several<b= r> > years. Just to quote a few stats<br> > - 2009 : 107 patches changing 11746 lines of code<br> > - 2010 : 147 patches changing 7613 lines of code<br> > - 2011 : 204 patches changing 2655 lines of code<br> ><br> > Congratulations!<br> <br> </div>Woohoo! Congratulations Jan!<br> <div><div></div><div class=3D"h5"><br> _______________________________________________<br> xen-api mailing list<br> <a href=3D"mailto:xen-api@lists.xensource.com">xen-api@lists.xensource.com<= /a><br> <a href=3D"http://lists.xensource.com/mailman/listinfo/xen-api" target=3D"_= blank">http://lists.xensource.com/mailman/listinfo/xen-api</a><br> </div></div></blockquote></div><br><br clear=3D"all"><br>-- <br><span style= =3D"font-family:arial,sans-serif;font-size:13px;border-collapse:collapse"><= b><i><font color=3D"#0000ff"><div><font color=3D"#000000"><span style=3D"fo= nt-style:normal;font-weight:normal">Founder | Director | VP Research<br> </span></font></div>Orion Virtualisation Solutions</font></i></b>=A0|=A0<fo= nt color=3D"#0000ff"><a href=3D"http://www.orionvm.com.au/" style=3D"color:= rgb(42, 93, 176)" target=3D"_blank">www.orionvm.com.au</a></font>=A0| Phone= : 1300 56 99 52 | Mobile: 0428 754 846</span><br> --20cf307cfc7e8ac61c04ae294272-- --===============1511090096== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ xen-api mailing list xen-api@lists.xensource.com http://lists.xensource.com/mailman/listinfo/xen-api --===============1511090096==-- From xen-devel-bounces@lists.xensource.com Fri Sep 30 07:18:18 2011 Return-path: <xen-devel-bounces@lists.xensource.com> Envelope-to: www-data@lists.xensource.com Delivery-date: Fri, 30 Sep 2011 07:18:18 -0700 Received: from localhost ([127.0.0.1] helo=lists.colo.xensource.com) by lists.xensource.com with esmtp (Exim 4.43) id 1R9dus-0004o6-KN; Fri, 30 Sep 2011 07:18:18 -0700 Received: from mail182.messagelabs.com ([85.158.139.83]) by lists.xensource.com with esmtp (Exim 4.43) id 1R9duU-0004bu-9u for xen-devel@lists.xensource.com; Fri, 30 Sep 2011 07:17:54 -0700 X-Env-Sender: Ian.Campbell@eu.citrix.com X-Msg-Ref: server-2.tower-182.messagelabs.com!1317392267!17580897!1 X-Originating-IP: [62.200.22.115] X-StarScan-Version: 6.4.1; banners=-,-,- X-VirusChecked: Checked Received: (qmail 31107 invoked from network); 30 Sep 2011 14:17:51 -0000 Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115) by server-2.tower-182.messagelabs.com with RC4-SHA encrypted SMTP; 30 Sep 2011 14:17:51 -0000 X-IronPort-AV: E=Sophos;i="4.68,467,1312156800"; d="scan'208";a="8154344" Received: from lonpmailmx01.citrite.net ([10.30.203.162]) by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5; 30 Sep 2011 14:17:47 +0000 Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net (10.30.203.162) with Microsoft SMTP Server id 8.3.137.0; Fri, 30 Sep 2011 15:17:47 +0100 From: Ian Campbell <Ian.Campbell@eu.citrix.com> To: Ian Jackson <Ian.Jackson@eu.citrix.com> Date: Fri, 30 Sep 2011 15:17:47 +0100 In-Reply-To: <20101.52799.95729.431768@mariner.uk.xensource.com> References: <1313764724-12683-1-git-send-email-dgdegra@tycho.nsa.gov> <1316729665-15004-1-git-send-email-dgdegra@tycho.nsa.gov> <1316729665-15004-2-git-send-email-dgdegra@tycho.nsa.gov> <1317374174.26672.249.camel@zakaz.uk.xensource.com> <20101.52799.95729.431768@mariner.uk.xensource.com> Organization: Citrix Systems, Inc. Content-Type: text/plain; charset="UTF-8" X-Mailer: Evolution 3.0.3- Content-Transfer-Encoding: 7bit Message-ID: <1317392267.26672.285.camel@zakaz.uk.xensource.com> MIME-Version: 1.0 Cc: Daniel De Graaf <dgdegra@tycho.nsa.gov>, "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>, Stefano Stabellini <Stefano.Stabellini@eu.citrix.com>, "konrad.wilk@oracle.com" <konrad.wilk@oracle.com> Subject: [Xen-devel] Re: [PATCH 1/3] libxc: add xc_gnttab_map_grant_ref_notify X-BeenThere: xen-devel@lists.xensource.com X-Mailman-Version: 2.1.5 Precedence: list List-Id: Xen developer discussion <xen-devel.lists.xensource.com> List-Unsubscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe> List-Post: <mailto:xen-devel@lists.xensource.com> List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help> List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=subscribe> Sender: xen-devel-bounces@lists.xensource.com Errors-To: xen-devel-bounces@lists.xensource.com On Fri, 2011-09-30 at 15:12 +0100, Ian Jackson wrote: > Ian Campbell writes ("Re: [PATCH 1/3] libxc: add xc_gnttab_map_grant_ref_notify"): > > Not specifically to do with this patch but I wonder if we should try and > > figure a way to version these shared libraries somehow, otherwise > > changes like this lead to segfault at best and unexpected non-crashing > > behaviour at worst (for out of tree backends that is). > > Our approach is to change the library major number at some point > between releases. People using the development tree can expect > instability. These are "plugins" so they don't have an SONAME. Perhaps they should, but I'm not sure what would check it when opening with dlopen() or how one goes about doing it manually. Ian. _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel From xen-devel-bounces@lists.xensource.com Fri Sep 30 07:19:27 2011 Return-path: <xen-devel-bounces@lists.xensource.com> Envelope-to: www-data@lists.xensource.com Delivery-date: Fri, 30 Sep 2011 07:19:27 -0700 Received: from localhost ([127.0.0.1] helo=lists.colo.xensource.com) by lists.xensource.com with esmtp (Exim 4.43) id 1R9dvz-0005B5-Fk; Fri, 30 Sep 2011 07:19:27 -0700 Received: from mail216.messagelabs.com ([85.158.143.99]) by lists.xensource.com with esmtp (Exim 4.43) id 1R9dvb-0004yv-K8 for xen-devel@lists.xensource.com; Fri, 30 Sep 2011 07:19:03 -0700 X-Env-Sender: Stefano.Stabellini@eu.citrix.com X-Msg-Ref: server-12.tower-216.messagelabs.com!1317392340!14411136!1 X-Originating-IP: [62.200.22.115] X-StarScan-Version: 6.4.1; banners=-,-,- X-VirusChecked: Checked Received: (qmail 7886 invoked from network); 30 Sep 2011 14:19:00 -0000 Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115) by server-12.tower-216.messagelabs.com with RC4-SHA encrypted SMTP; 30 Sep 2011 14:19:00 -0000 X-IronPort-AV: E=Sophos;i="4.68,467,1312156800"; d="scan'208";a="8154385" Received: from lonpmailmx01.citrite.net ([10.30.203.162]) by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5; 30 Sep 2011 14:19:00 +0000 Received: from kaball.uk.xensource.com (10.80.2.59) by LONPMAILMX01.citrite.net (10.30.203.162) with Microsoft SMTP Server id 8.3.137.0; Fri, 30 Sep 2011 15:19:00 +0100 Date: Fri, 30 Sep 2011 15:18:48 +0100 From: Stefano Stabellini <Stefano.Stabellini@eu.citrix.com> X-X-Sender: sstabellini@kaball-desktop To: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com> Message-ID: <alpine.DEB.2.00.1109301514460.3519@kaball-desktop> User-Agent: Alpine 2.00 (DEB 1167 2008-08-23) MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Cc: Ian Campbell <Ian.Campbell@eu.citrix.com>, Keir Fraser <keir@xen.org>, Stefano Stabellini <Stefano.Stabellini@eu.citrix.com> Subject: [Xen-devel] [PATCH v7 0/5] build upstream qemu and seabios by default X-BeenThere: xen-devel@lists.xensource.com X-Mailman-Version: 2.1.5 Precedence: list List-Id: Xen developer discussion <xen-devel.lists.xensource.com> List-Unsubscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe> List-Post: <mailto:xen-devel@lists.xensource.com> List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help> List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=subscribe> Sender: xen-devel-bounces@lists.xensource.com Errors-To: xen-devel-bounces@lists.xensource.com Hi all, this is the sixth version of the patch series to introduce upstream qemu and seabios in the xen-unstable build system. Changes to v6: - add "set -e" to git-checkout.sh; - add argument count check to git-checkout.sh; - remove spurious semicolons in git-checkout.sh. Changes to v5: - use $GIT in git-checkout.sh; - add an http mirror for seabios; - use $(LIBEXEC) to configure upstream qemu; - append a patch for libxenlight to find the upstream qemu binary under $(LIBEXEC). Changes to v4: - remove an obsolete comment; - use /bin/sh to execute git-checkout.sh rathen than /bin/bash. Changes to v3: - reduce the scope of git-checkout.sh, now it only does what the name says; calling "configure" is responsibility of the caller. As a result of this change, the build still works when the user specifies a local directory in the CONFIG_QEMU environmental variable; - use a more official qemu repository hosted on xenbits; - use a changeset as QEMU_UPSTREAM_TAG rather than a branch name. Changes to v2: - move tools/git-checkout.sh to scripts/git-checkout.sh; - use git-checkout.sh for seabios; - improve seabios integration with tools/firmware make system; - add qemu-xen-traditional, qemu-xen and seabios dir entries to .hgignore. Changes to v1: - always build upstream qemu and seabios, rather than introducing them as an option. Cheers, Stefano _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel From xen-devel-bounces@lists.xensource.com Fri Sep 30 07:21:28 2011 Return-path: <xen-devel-bounces@lists.xensource.com> Envelope-to: www-data@lists.xensource.com Delivery-date: Fri, 30 Sep 2011 07:21:28 -0700 Received: from localhost ([127.0.0.1] helo=lists.colo.xensource.com) by lists.xensource.com with esmtp (Exim 4.43) id 1R9dxw-0005Zi-1N; Fri, 30 Sep 2011 07:21:28 -0700 Received: from mail174.messagelabs.com ([85.158.138.51]) by lists.xensource.com with esmtp (Exim 4.43) id 1R9dxK-0005Mj-Qm for xen-devel@lists.xensource.com; Fri, 30 Sep 2011 07:20:51 -0700 X-Env-Sender: Stefano.Stabellini@eu.citrix.com X-Msg-Ref: server-8.tower-174.messagelabs.com!1317392446!19704759!1 X-Originating-IP: [66.165.176.89] X-StarScan-Version: 6.4.1; banners=-,-,- X-VirusChecked: Checked Received: (qmail 3381 invoked from network); 30 Sep 2011 14:20:47 -0000 Received: from smtp.citrix.com (HELO SMTP.CITRIX.COM) (66.165.176.89) by server-8.tower-174.messagelabs.com with RC4-SHA encrypted SMTP; 30 Sep 2011 14:20:47 -0000 X-IronPort-AV: E=Sophos;i="4.68,467,1312171200"; d="scan'208";a="17843000" Received: from ftlpmailmx02.citrite.net ([10.13.107.66]) by FTLPIPO01.CITRIX.COM with ESMTP/TLS/RC4-MD5; 30 Sep 2011 10:20:46 -0400 Received: from smtp01.ad.xensource.com (10.219.128.104) by smtprelay.citrix.com (10.13.107.66) with Microsoft SMTP Server id 8.3.137.0; Fri, 30 Sep 2011 10:20:46 -0400 Received: from localhost.localdomain (kaball.uk.xensource.com [10.80.2.59]) by smtp01.ad.xensource.com (8.13.1/8.13.1) with ESMTP id p8UEKcqp029354; Fri, 30 Sep 2011 07:20:39 -0700 From: <stefano.stabellini@eu.citrix.com> To: xen-devel@lists.xensource.com Date: Fri, 30 Sep 2011 15:20:36 +0100 Message-ID: <1317392440-4137-1-git-send-email-stefano.stabellini@eu.citrix.com> X-Mailer: git-send-email 1.7.0.4 In-Reply-To: <alpine.DEB.2.00.1109301514460.3519@kaball-desktop> References: <alpine.DEB.2.00.1109301514460.3519@kaball-desktop> MIME-Version: 1.0 Content-Type: text/plain Cc: Ian.Campbell@eu.citrix.com, keir@xen.org, Stefano Stabellini <stefano.stabellini@eu.citrix.com>, Ian.Jackson@eu.citrix.com, Stefano.Stabellini@eu.citrix.com Subject: [Xen-devel] [PATCH v7 1/5] Introduce git-checkout.sh X-BeenThere: xen-devel@lists.xensource.com X-Mailman-Version: 2.1.5 Precedence: list List-Id: Xen developer discussion <xen-devel.lists.xensource.com> List-Unsubscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe> List-Post: <mailto:xen-devel@lists.xensource.com> List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help> List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=subscribe> Sender: xen-devel-bounces@lists.xensource.com Errors-To: xen-devel-bounces@lists.xensource.com Introduce a script to perform git checkout on an external git tree; use git-checkout.sh in ioemu-dir-find. Signed-off-by: Stefano Stabellini <stefano.stabellini@eu.citrix.com> diff --git a/.hgignore b/.hgignore --- a/.hgignore +++ b/.hgignore @@ -291,7 +291,7 @@ ^tools/xm-test/lib/XmTestLib/config.py$ ^tools/xm-test/lib/XmTestReport/xmtest.py$ ^tools/xm-test/tests/.*\.test$ -^tools/ioemu-remote +^tools/ioemu-dir-remote ^tools/ioemu-dir$ ^tools/ocaml/.*/.*\.annot$ ^tools/ocaml/.*/.*\.cmx?a$ diff --git a/scripts/git-checkout.sh b/scripts/git-checkout.sh new file mode 100755 --- /dev/null +++ b/scripts/git-checkout.sh @@ -0,0 +1,27 @@ +#!/bin/sh + +if test $# -lt 3; then + echo "Usage: $0 <tree> <tag> <dir>" + exit 1 +fi + +TREE=$1 +TAG=$2 +DIR=$3 + +set -e + +if test \! -d $DIR-remote; then + rm -rf $DIR-remote $DIR-remote.tmp + mkdir $DIR-remote.tmp; rmdir $DIR-remote.tmp + $GIT clone $TREE $DIR-remote.tmp + if test "$TAG" ; then + cd $DIR-remote.tmp + $GIT branch -D dummy >/dev/null 2>&1 ||: + $GIT checkout -b dummy $TAG + cd .. + fi + mv $DIR-remote.tmp $DIR-remote +fi +rm -f $DIR +ln -sf $DIR-remote $DIR diff --git a/tools/Makefile b/tools/Makefile --- a/tools/Makefile +++ b/tools/Makefile @@ -70,7 +70,7 @@ clean: subdirs-clean .PHONY: distclean distclean: subdirs-distclean - rm -rf ioemu-dir ioemu-remote + rm -rf ioemu-dir ioemu-dir-remote ifneq ($(XEN_COMPILE_ARCH),$(XEN_TARGET_ARCH)) IOEMU_CONFIGURE_CROSS ?= --cpu=$(XEN_TARGET_ARCH) \ @@ -88,20 +88,8 @@ ioemu-dir-find: if test -d $(CONFIG_QEMU); then \ mkdir -p ioemu-dir; \ else \ - if [ ! -d ioemu-remote ]; then \ - rm -rf ioemu-remote ioemu-remote.tmp; \ - mkdir ioemu-remote.tmp; rmdir ioemu-remote.tmp; \ - $(GIT) clone $(CONFIG_QEMU) ioemu-remote.tmp; \ - if [ "$(QEMU_TAG)" ]; then \ - cd ioemu-remote.tmp; \ - $(GIT) branch -D dummy >/dev/null 2>&1 ||:; \ - $(GIT) checkout -b dummy $(QEMU_TAG); \ - cd ..; \ - fi; \ - mv ioemu-remote.tmp ioemu-remote; \ - fi; \ - rm -f ioemu-dir; \ - ln -sf ioemu-remote ioemu-dir; \ + export GIT=$(GIT); \ + $(XEN_ROOT)/scripts/git-checkout.sh $(CONFIG_QEMU) $(QEMU_TAG) ioemu-dir; \ fi set -e; \ $(buildmakevars2shellvars); \ @@ -112,7 +100,7 @@ ioemu-dir-find: ioemu-dir-force-update: set -ex; \ if [ "$(QEMU_TAG)" ]; then \ - cd ioemu-remote; \ + cd ioemu-dir-remote; \ $(GIT) fetch origin; \ $(GIT) reset --hard $(QEMU_TAG); \ fi _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel From xen-devel-bounces@lists.xensource.com Fri Sep 30 07:22:22 2011 Return-path: <xen-devel-bounces@lists.xensource.com> Envelope-to: www-data@lists.xensource.com Delivery-date: Fri, 30 Sep 2011 07:22:22 -0700 Received: from localhost ([127.0.0.1] helo=lists.colo.xensource.com) by lists.xensource.com with esmtp (Exim 4.43) id 1R9dyn-0005wq-OW; Fri, 30 Sep 2011 07:22:21 -0700 Received: from mail27.messagelabs.com ([193.109.254.147]) by lists.xensource.com with esmtp (Exim 4.43) id 1R9dxL-0005Mk-HA for xen-devel@lists.xensource.com; Fri, 30 Sep 2011 07:20:51 -0700 X-Env-Sender: Stefano.Stabellini@eu.citrix.com X-Msg-Ref: server-5.tower-27.messagelabs.com!1317392426!47062389!1 X-Originating-IP: [66.165.176.63] X-StarScan-Version: 6.4.1; banners=-,-,- X-VirusChecked: Checked Received: (qmail 21233 invoked from network); 30 Sep 2011 14:20:27 -0000 Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63) by server-5.tower-27.messagelabs.com with RC4-SHA encrypted SMTP; 30 Sep 2011 14:20:27 -0000 X-IronPort-AV: E=Sophos;i="4.68,467,1312171200"; d="scan'208";a="165295421" Received: from ftlpmailmx02.citrite.net ([10.13.107.66]) by FTLPIPO02.CITRIX.COM with ESMTP/TLS/RC4-MD5; 30 Sep 2011 10:20:46 -0400 Received: from smtp01.ad.xensource.com (10.219.128.104) by smtprelay.citrix.com (10.13.107.66) with Microsoft SMTP Server id 8.3.137.0; Fri, 30 Sep 2011 10:20:47 -0400 Received: from localhost.localdomain (kaball.uk.xensource.com [10.80.2.59]) by smtp01.ad.xensource.com (8.13.1/8.13.1) with ESMTP id p8UEKcqt029354; Fri, 30 Sep 2011 07:20:45 -0700 From: <stefano.stabellini@eu.citrix.com> To: xen-devel@lists.xensource.com Date: Fri, 30 Sep 2011 15:20:40 +0100 Message-ID: <1317392440-4137-5-git-send-email-stefano.stabellini@eu.citrix.com> X-Mailer: git-send-email 1.7.0.4 In-Reply-To: <alpine.DEB.2.00.1109301514460.3519@kaball-desktop> References: <alpine.DEB.2.00.1109301514460.3519@kaball-desktop> MIME-Version: 1.0 Content-Type: text/plain Cc: Ian.Campbell@eu.citrix.com, keir@xen.org, Ian.Jackson@eu.citrix.com, Ian Campbell <ian.campbell@citrix.com>, Stefano.Stabellini@eu.citrix.com Subject: [Xen-devel] [PATCH v7 5/5] libxl: use new qemu at the location where xen-unstable installs it X-BeenThere: xen-devel@lists.xensource.com X-Mailman-Version: 2.1.5 Precedence: list List-Id: Xen developer discussion <xen-devel.lists.xensource.com> List-Unsubscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe> List-Post: <mailto:xen-devel@lists.xensource.com> List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help> List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=subscribe> Sender: xen-devel-bounces@lists.xensource.com Errors-To: xen-devel-bounces@lists.xensource.com From: Ian Campbell <ian.campbell@citrix.com> Signed-off-by: Ian Campbell <ian.campbell@citrix.com> diff -r 75f27929ad92 tools/libxl/libxl_dm.c --- a/tools/libxl/libxl_dm.c Fri Sep 23 11:22:23 2011 +0000 +++ b/tools/libxl/libxl_dm.c Fri Sep 23 11:22:39 2011 +0000 @@ -55,7 +55,7 @@ const char *libxl__domain_device_model(l dm = libxl__abs_path(gc, "qemu-dm", libxl_libexec_path()); break; case LIBXL_DEVICE_MODEL_VERSION_QEMU_XEN: - dm = libxl__strdup(gc, "/usr/bin/qemu"); + dm = libxl__abs_path(gc, "qemu", libxl_libexec_path()); break; default: LIBXL__LOG(ctx, LIBXL__LOG_ERROR, _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel From xen-devel-bounces@lists.xensource.com Fri Sep 30 07:23:33 2011 Return-path: <xen-devel-bounces@lists.xensource.com> Envelope-to: www-data@lists.xensource.com Delivery-date: Fri, 30 Sep 2011 07:23:33 -0700 Received: from localhost ([127.0.0.1] helo=lists.colo.xensource.com) by lists.xensource.com with esmtp (Exim 4.43) id 1R9dzx-0006Jf-2z; Fri, 30 Sep 2011 07:23:33 -0700 Received: from mail174.messagelabs.com ([85.158.138.51]) by lists.xensource.com with esmtp (Exim 4.43) id 1R9dxQ-0005NS-Cf for xen-devel@lists.xensource.com; Fri, 30 Sep 2011 07:20:56 -0700 X-Env-Sender: Stefano.Stabellini@eu.citrix.com X-Msg-Ref: server-8.tower-174.messagelabs.com!1317392446!19704759!2 X-Originating-IP: [66.165.176.89] X-StarScan-Version: 6.4.1; banners=-,-,- X-VirusChecked: Checked Received: (qmail 3511 invoked from network); 30 Sep 2011 14:20:52 -0000 Received: from smtp.citrix.com (HELO SMTP.CITRIX.COM) (66.165.176.89) by server-8.tower-174.messagelabs.com with RC4-SHA encrypted SMTP; 30 Sep 2011 14:20:52 -0000 X-IronPort-AV: E=Sophos;i="4.68,467,1312171200"; d="scan'208";a="17843001" Received: from ftlpmailmx02.citrite.net ([10.13.107.66]) by FTLPIPO01.CITRIX.COM with ESMTP/TLS/RC4-MD5; 30 Sep 2011 10:20:52 -0400 Received: from smtp01.ad.xensource.com (10.219.128.104) by smtprelay.citrix.com (10.13.107.66) with Microsoft SMTP Server id 8.3.137.0; Fri, 30 Sep 2011 10:20:52 -0400 Received: from localhost.localdomain (kaball.uk.xensource.com [10.80.2.59]) by smtp01.ad.xensource.com (8.13.1/8.13.1) with ESMTP id p8UEKcqq029354; Fri, 30 Sep 2011 07:20:40 -0700 From: <stefano.stabellini@eu.citrix.com> To: xen-devel@lists.xensource.com Date: Fri, 30 Sep 2011 15:20:37 +0100 Message-ID: <1317392440-4137-2-git-send-email-stefano.stabellini@eu.citrix.com> X-Mailer: git-send-email 1.7.0.4 In-Reply-To: <alpine.DEB.2.00.1109301514460.3519@kaball-desktop> References: <alpine.DEB.2.00.1109301514460.3519@kaball-desktop> MIME-Version: 1.0 Content-Type: text/plain Cc: Ian.Campbell@eu.citrix.com, keir@xen.org, Stefano Stabellini <stefano.stabellini@eu.citrix.com>, Ian.Jackson@eu.citrix.com, Stefano.Stabellini@eu.citrix.com Subject: [Xen-devel] [PATCH v7 2/5] Rename ioemu-dir as qemu-xen-traditional-dir X-BeenThere: xen-devel@lists.xensource.com X-Mailman-Version: 2.1.5 Precedence: list List-Id: Xen developer discussion <xen-devel.lists.xensource.com> List-Unsubscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe> List-Post: <mailto:xen-devel@lists.xensource.com> List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help> List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=subscribe> Sender: xen-devel-bounces@lists.xensource.com Errors-To: xen-devel-bounces@lists.xensource.com Signed-off-by: Stefano Stabellini <stefano.stabellini@eu.citrix.com> diff -r 9d2f56b25845 .hgignore --- a/.hgignore Fri Sep 23 11:35:23 2011 +0000 +++ b/.hgignore Fri Sep 23 11:36:44 2011 +0000 @@ -291,8 +291,8 @@ ^tools/xm-test/lib/XmTestLib/config.py$ ^tools/xm-test/lib/XmTestReport/xmtest.py$ ^tools/xm-test/tests/.*\.test$ -^tools/ioemu-dir-remote -^tools/ioemu-dir$ +^tools/qemu-xen-traditional-dir-remote +^tools/qemu-xen-traditional-dir$ ^tools/ocaml/.*/.*\.annot$ ^tools/ocaml/.*/.*\.cmx?a$ ^tools/ocaml/.*/META$ diff -r 9d2f56b25845 Makefile --- a/Makefile Fri Sep 23 11:35:23 2011 +0000 +++ b/Makefile Fri Sep 23 11:36:44 2011 +0000 @@ -70,7 +70,7 @@ install-tools: $(MAKE) -C tools install ifeq ($(CONFIG_IOEMU),y) -install-tools: tools/ioemu-dir +install-tools: tools/qemu-xen-traditional-dir endif .PHONY: install-kernels @@ -78,18 +78,18 @@ install-kernels: for i in $(XKERNELS) ; do $(MAKE) $$i-install || exit 1; done .PHONY: install-stubdom -install-stubdom: tools/ioemu-dir install-tools +install-stubdom: tools/qemu-xen-traditional-dir install-tools $(MAKE) -C stubdom install ifeq (x86_64,$(XEN_TARGET_ARCH)) XEN_TARGET_ARCH=x86_32 $(MAKE) -C stubdom install-grub endif -tools/ioemu-dir: - $(MAKE) -C tools ioemu-dir-find +tools/qemu-xen-traditional-dir: + $(MAKE) -C tools qemu-xen-traditional-dir-find -.PHONY: tools/ioemu-dir-force-update -tools/ioemu-dir-force-update: - $(MAKE) -C tools ioemu-dir-force-update +.PHONY: tools/qemu-xen-traditional-dir-force-update +tools/qemu-xen-traditional-dir-force-update: + $(MAKE) -C tools qemu-xen-traditional-dir-force-update .PHONY: install-docs install-docs: diff -r 9d2f56b25845 stubdom/Makefile --- a/stubdom/Makefile Fri Sep 23 11:35:23 2011 +0000 +++ b/stubdom/Makefile Fri Sep 23 11:36:44 2011 +0000 @@ -218,15 +218,15 @@ cross-ocaml: $(OCAML_STAMPFILE) QEMU_ROOT := $(shell if [ -d "$(CONFIG_QEMU)" ]; then echo "$(CONFIG_QEMU)"; else echo .; fi) ifeq ($(QEMU_ROOT),.) -$(XEN_ROOT)/tools/ioemu-dir: - $(CROSS_MAKE) -C $(XEN_ROOT)/tools ioemu-dir-find +$(XEN_ROOT)/tools/qemu-xen-traditional-dir: + $(CROSS_MAKE) -C $(XEN_ROOT)/tools qemu-xen-traditional-dir-find -ioemu/linkfarm.stamp: $(XEN_ROOT)/tools/ioemu-dir +ioemu/linkfarm.stamp: $(XEN_ROOT)/tools/qemu-xen-traditional-dir mkdir -p ioemu set -e; \ $(buildmakevars2shellvars); \ cd ioemu; \ - src="$$XEN_ROOT/tools/ioemu-dir"; export src; \ + src="$$XEN_ROOT/tools/qemu-xen-traditional-dir"; export src; \ (cd $$src && find * -type d -print) | xargs mkdir -p; \ (cd $$src && find * ! -type l -type f $(addprefix ! -name , \ '*.[oda1]' 'config-*' config.mak qemu-dm qemu-img-xen \ diff -r 9d2f56b25845 tools/Makefile --- a/tools/Makefile Fri Sep 23 11:35:23 2011 +0000 +++ b/tools/Makefile Fri Sep 23 11:36:44 2011 +0000 @@ -30,7 +30,7 @@ SUBDIRS-$(LIBXENAPI_BINDINGS) += libxen # do not recurse in to a dir we are about to delete ifneq "$(MAKECMDGOALS)" "distclean" -SUBDIRS-$(CONFIG_IOEMU) += ioemu-dir +SUBDIRS-$(CONFIG_IOEMU) += qemu-xen-traditional-dir endif SUBDIRS-y += xenpmd @@ -70,7 +70,7 @@ clean: subdirs-clean .PHONY: distclean distclean: subdirs-distclean - rm -rf ioemu-dir ioemu-dir-remote + rm -rf qemu-xen-traditional-dir qemu-xen-traditional-dir-remote ifneq ($(XEN_COMPILE_ARCH),$(XEN_TARGET_ARCH)) IOEMU_CONFIGURE_CROSS ?= --cpu=$(XEN_TARGET_ARCH) \ @@ -83,34 +83,34 @@ ifneq ($(QEMU_ROOT),.) export QEMU_ROOT endif -ioemu-dir-find: +qemu-xen-traditional-dir-find: set -ex; \ if test -d $(CONFIG_QEMU); then \ - mkdir -p ioemu-dir; \ + mkdir -p qemu-xen-traditional-dir; \ else \ export GIT=$(GIT); \ - $(XEN_ROOT)/scripts/git-checkout.sh $(CONFIG_QEMU) $(QEMU_TAG) ioemu-dir; \ + $(XEN_ROOT)/scripts/git-checkout.sh $(CONFIG_QEMU) $(QEMU_TAG) qemu-xen-traditional-dir; \ fi set -e; \ $(buildmakevars2shellvars); \ - cd ioemu-dir; \ + cd qemu-xen-traditional-dir; \ $(QEMU_ROOT)/xen-setup $(IOEMU_CONFIGURE_CROSS) -.PHONY: ioemu-dir-force-update -ioemu-dir-force-update: +.PHONY: qemu-xen-traditional-dir-force-update +qemu-xen-traditional-dir-force-update: set -ex; \ if [ "$(QEMU_TAG)" ]; then \ - cd ioemu-dir-remote; \ + cd qemu-xen-traditional-dir-remote; \ $(GIT) fetch origin; \ $(GIT) reset --hard $(QEMU_TAG); \ fi -subdir-all-ioemu-dir subdir-install-ioemu-dir: ioemu-dir-find +subdir-all-qemu-xen-traditional-dir subdir-install-qemu-xen-traditional-dir: qemu-xen-traditional-dir-find -subdir-clean-ioemu-dir: - set -e; if test -d ioemu-dir/.; then \ +subdir-clean-qemu-xen-traditional-dir: + set -e; if test -d qemu-xen-traditional-dir/.; then \ $(buildmakevars2shellvars); \ - $(MAKE) -C ioemu-dir clean; \ + $(MAKE) -C qemu-xen-traditional-dir clean; \ fi subdir-clean-debugger/gdbsx subdir-distclean-debugger/gdbsx: .phony _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel From xen-devel-bounces@lists.xensource.com Fri Sep 30 07:25:15 2011 Return-path: <xen-devel-bounces@lists.xensource.com> Envelope-to: www-data@lists.xensource.com Delivery-date: Fri, 30 Sep 2011 07:25:15 -0700 Received: from localhost ([127.0.0.1] helo=lists.colo.xensource.com) by lists.xensource.com with esmtp (Exim 4.43) id 1R9e1a-0006hA-Sz; Fri, 30 Sep 2011 07:25:14 -0700 Received: from mail174.messagelabs.com ([85.158.138.51]) by lists.xensource.com with esmtp (Exim 4.43) id 1R9dxT-0005Ok-8c for xen-devel@lists.xensource.com; Fri, 30 Sep 2011 07:20:59 -0700 X-Env-Sender: Stefano.Stabellini@eu.citrix.com X-Msg-Ref: server-8.tower-174.messagelabs.com!1317392446!19704759!3 X-Originating-IP: [66.165.176.89] X-StarScan-Version: 6.4.1; banners=-,-,- X-VirusChecked: Checked Received: (qmail 3628 invoked from network); 30 Sep 2011 14:20:55 -0000 Received: from smtp.citrix.com (HELO SMTP.CITRIX.COM) (66.165.176.89) by server-8.tower-174.messagelabs.com with RC4-SHA encrypted SMTP; 30 Sep 2011 14:20:55 -0000 X-IronPort-AV: E=Sophos;i="4.68,467,1312171200"; d="scan'208";a="17843004" Received: from ftlpmailmx02.citrite.net ([10.13.107.66]) by FTLPIPO01.CITRIX.COM with ESMTP/TLS/RC4-MD5; 30 Sep 2011 10:20:55 -0400 Received: from smtp01.ad.xensource.com (10.219.128.104) by smtprelay.citrix.com (10.13.107.66) with Microsoft SMTP Server id 8.3.137.0; Fri, 30 Sep 2011 10:20:55 -0400 Received: from localhost.localdomain (kaball.uk.xensource.com [10.80.2.59]) by smtp01.ad.xensource.com (8.13.1/8.13.1) with ESMTP id p8UEKcqs029354; Fri, 30 Sep 2011 07:20:43 -0700 From: <stefano.stabellini@eu.citrix.com> To: xen-devel@lists.xensource.com Date: Fri, 30 Sep 2011 15:20:39 +0100 Message-ID: <1317392440-4137-4-git-send-email-stefano.stabellini@eu.citrix.com> X-Mailer: git-send-email 1.7.0.4 In-Reply-To: <alpine.DEB.2.00.1109301514460.3519@kaball-desktop> References: <alpine.DEB.2.00.1109301514460.3519@kaball-desktop> MIME-Version: 1.0 Content-Type: text/plain Cc: Ian.Campbell@eu.citrix.com, keir@xen.org, Stefano Stabellini <stefano.stabellini@eu.citrix.com>, Ian.Jackson@eu.citrix.com, Stefano.Stabellini@eu.citrix.com Subject: [Xen-devel] [PATCH v7 4/5] Clone and build Seabios by default X-BeenThere: xen-devel@lists.xensource.com X-Mailman-Version: 2.1.5 Precedence: list List-Id: Xen developer discussion <xen-devel.lists.xensource.com> List-Unsubscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe> List-Post: <mailto:xen-devel@lists.xensource.com> List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help> List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=subscribe> Sender: xen-devel-bounces@lists.xensource.com Errors-To: xen-devel-bounces@lists.xensource.com Signed-off-by: Stefano Stabellini <stefano.stabellini@eu.citrix.com> diff -r 294b63f68602 .hgignore --- a/.hgignore Fri Sep 23 11:37:09 2011 +0000 +++ b/.hgignore Fri Sep 23 11:51:06 2011 +0000 @@ -295,6 +295,8 @@ ^tools/qemu-xen-traditional-dir$ ^tools/qemu-xen-dir-remote ^tools/qemu-xen-dir$ +^tools/tools/firmware/seabios-dir-remote +^tools/tools/firmware/seabios-dir$ ^tools/ocaml/.*/.*\.annot$ ^tools/ocaml/.*/.*\.cmx?a$ ^tools/ocaml/.*/META$ diff -r 294b63f68602 Config.mk --- a/Config.mk Fri Sep 23 11:37:09 2011 +0000 +++ b/Config.mk Fri Sep 23 11:51:06 2011 +0000 @@ -194,10 +194,13 @@ endif ifeq ($(GIT_HTTP),y) QEMU_UPSTREAM_URL ?= http://xenbits.xensource.com/git-http/qemu-upstream-unstable.git +SEABIOS_UPSTREAM_URL ?= http://git.qemu.org/git/seabios.git else QEMU_UPSTREAM_URL ?= git://xenbits.xensource.com/qemu-upstream-unstable.git +SEABIOS_UPSTREAM_URL ?= git://git.qemu.org/seabios.git endif QEMU_UPSTREAM_TAG ?= 6dd84c71dff047f9e492d67e7c99928d09202760 +SEABIOS_UPSTREAM_TAG ?= 7fc039e9c262b4199fab497f3e12f4e425c37560 # Specify which qemu-dm to use. This may be `ioemu' to use the old # Mercurial in-tree version, or a local directory, or a git URL. @@ -211,15 +214,6 @@ QEMU_TAG ?= cd776ee9408ff127f934a707c1a3 # Short answer -- do not enable this unless you know what you are # doing and are prepared for some pain. -# SeaBIOS integration is a work in progress. Before enabling this -# option you must clone git://git.qemu.org/seabios.git/, possibly add -# some development patches and then build it yourself before pointing -# this variable to it (using an absolute path). -# -# Note that using SeaBIOS requires the use the upstream qemu as the -# device model. -SEABIOS_DIR ?= - # Optional components XENSTAT_XENTOP ?= y VTPM_TOOLS ?= n diff -r 294b63f68602 tools/firmware/Makefile --- a/tools/firmware/Makefile Fri Sep 23 11:37:09 2011 +0000 +++ b/tools/firmware/Makefile Fri Sep 23 11:51:06 2011 +0000 @@ -6,13 +6,18 @@ TARGET := hvmloader/hvmloader INST_DIR := $(DESTDIR)$(XENFIRMWAREDIR) SUBDIRS := +SUBDIRS += seabios-dir SUBDIRS += rombios SUBDIRS += vgabios SUBDIRS += etherboot SUBDIRS += hvmloader +seabios-dir: + GIT=$(GIT) $(XEN_ROOT)/scripts/git-checkout.sh $(SEABIOS_UPSTREAM_URL) $(SEABIOS_UPSTREAM_TAG) seabios-dir + cp seabios-config seabios-dir/.config; + .PHONY: all -all: +all: seabios-dir @set -e; if [ $$((`( bcc -v 2>&1 | grep version || echo 0.0.0 ) | cut -d' ' -f 3 | awk -F. '{ printf "0x%02x%02x%02x", $$1, $$2, $$3}'`)) -lt $$((0x00100e)) ] ; then \ echo "==========================================================================="; \ echo "Require dev86 rpm or bin86 & bcc debs version >= 0.16.14 to build firmware!"; \ @@ -35,4 +40,7 @@ clean: subdirs-clean distclean: subdirs-distclean subdir-distclean-etherboot: .phony - $(MAKE) -C etherboot distclean \ No newline at end of file + $(MAKE) -C etherboot distclean + +subdir-distclean-seabios-dir: .phony + rm -rf seabios-dir seabios-dir-remote diff -r 294b63f68602 tools/firmware/hvmloader/Makefile --- a/tools/firmware/hvmloader/Makefile Fri Sep 23 11:37:09 2011 +0000 +++ b/tools/firmware/hvmloader/Makefile Fri Sep 23 11:51:06 2011 +0000 @@ -44,6 +44,7 @@ CFLAGS += -DENABLE_ROMBIOS ROMBIOS_ROM := $(ROMBIOS_DIR)/BIOS-bochs-latest endif +SEABIOS_DIR := ../seabios-dir ifneq ($(SEABIOS_DIR),) OBJS += seabios.o CFLAGS += -DENABLE_SEABIOS diff -r 294b63f68602 tools/firmware/seabios-config --- /dev/null Thu Jan 01 00:00:00 1970 +0000 +++ b/tools/firmware/seabios-config Fri Sep 23 11:51:06 2011 +0000 @@ -0,0 +1,73 @@ +# +# Automatically generated make config: don't edit +# SeaBIOS Configuration +# Wed Sep 7 13:03:21 2011 +# + +# +# General Features +# +# CONFIG_COREBOOT is not set +CONFIG_XEN=y +CONFIG_THREADS=y +# CONFIG_THREAD_OPTIONROMS is not set +CONFIG_RELOCATE_INIT=y +CONFIG_BOOTMENU=y +# CONFIG_BOOTSPLASH is not set +CONFIG_BOOTORDER=y + +# +# Hardware support +# +CONFIG_ATA=y +CONFIG_ATA_DMA=y +CONFIG_ATA_PIO32=y +CONFIG_AHCI=y +CONFIG_VIRTIO_BLK=y +CONFIG_FLOPPY=y +CONFIG_PS2PORT=y +CONFIG_USB=y +CONFIG_USB_UHCI=y +CONFIG_USB_OHCI=y +CONFIG_USB_EHCI=y +CONFIG_USB_MSC=y +CONFIG_USB_HUB=y +CONFIG_USB_KEYBOARD=y +CONFIG_USB_MOUSE=y +CONFIG_SERIAL=y +CONFIG_LPT=y +# CONFIG_USE_SMM is not set +CONFIG_MTRR_INIT=y + +# +# BIOS interfaces +# +CONFIG_DRIVES=y +CONFIG_CDROM_BOOT=y +CONFIG_CDROM_EMU=y +CONFIG_PCIBIOS=y +CONFIG_APMBIOS=y +CONFIG_PNPBIOS=y +CONFIG_OPTIONROMS=y +# CONFIG_OPTIONROMS_DEPLOYED is not set +CONFIG_PMM=y +CONFIG_BOOT=y +CONFIG_KEYBOARD=y +CONFIG_KBD_CALL_INT15_4F=y +CONFIG_MOUSE=y +CONFIG_S3_RESUME=y +# CONFIG_DISABLE_A20 is not set + +# +# BIOS Tables +# +CONFIG_PIRTABLE=y +CONFIG_MPTABLE=y +CONFIG_SMBIOS=y +CONFIG_ACPI=y + +# +# Debugging +# +CONFIG_DEBUG_LEVEL=1 +# CONFIG_DEBUG_SERIAL is not set _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel From xen-devel-bounces@lists.xensource.com Fri Sep 30 07:26:20 2011 Return-path: <xen-devel-bounces@lists.xensource.com> Envelope-to: www-data@lists.xensource.com Delivery-date: Fri, 30 Sep 2011 07:26:20 -0700 Received: from localhost ([127.0.0.1] helo=lists.colo.xensource.com) by lists.xensource.com with esmtp (Exim 4.43) id 1R9e2e-00073f-9J; Fri, 30 Sep 2011 07:26:20 -0700 Received: from mail216.messagelabs.com ([85.158.143.99]) by lists.xensource.com with esmtp (Exim 4.43) id 1R9dxT-0005Oj-6B for xen-devel@lists.xensource.com; Fri, 30 Sep 2011 07:20:59 -0700 X-Env-Sender: Stefano.Stabellini@eu.citrix.com X-Msg-Ref: server-11.tower-216.messagelabs.com!1317392454!12583386!1 X-Originating-IP: [66.165.176.63] X-StarScan-Version: 6.4.1; banners=-,-,- X-VirusChecked: Checked Received: (qmail 15208 invoked from network); 30 Sep 2011 14:20:56 -0000 Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63) by server-11.tower-216.messagelabs.com with RC4-SHA encrypted SMTP; 30 Sep 2011 14:20:56 -0000 X-IronPort-AV: E=Sophos;i="4.68,467,1312171200"; d="scan'208";a="165295451" Received: from ftlpmailmx02.citrite.net ([10.13.107.66]) by FTLPIPO02.CITRIX.COM with ESMTP/TLS/RC4-MD5; 30 Sep 2011 10:20:54 -0400 Received: from smtp01.ad.xensource.com (10.219.128.104) by smtprelay.citrix.com (10.13.107.66) with Microsoft SMTP Server id 8.3.137.0; Fri, 30 Sep 2011 10:20:54 -0400 Received: from localhost.localdomain (kaball.uk.xensource.com [10.80.2.59]) by smtp01.ad.xensource.com (8.13.1/8.13.1) with ESMTP id p8UEKcqr029354; Fri, 30 Sep 2011 07:20:42 -0700 From: <stefano.stabellini@eu.citrix.com> To: xen-devel@lists.xensource.com Date: Fri, 30 Sep 2011 15:20:38 +0100 Message-ID: <1317392440-4137-3-git-send-email-stefano.stabellini@eu.citrix.com> X-Mailer: git-send-email 1.7.0.4 In-Reply-To: <alpine.DEB.2.00.1109301514460.3519@kaball-desktop> References: <alpine.DEB.2.00.1109301514460.3519@kaball-desktop> MIME-Version: 1.0 Content-Type: text/plain Cc: Ian.Campbell@eu.citrix.com, keir@xen.org, Stefano Stabellini <stefano.stabellini@eu.citrix.com>, Ian.Jackson@eu.citrix.com, Stefano.Stabellini@eu.citrix.com Subject: [Xen-devel] [PATCH v7 3/5] Clone and build upstream Qemu by default X-BeenThere: xen-devel@lists.xensource.com X-Mailman-Version: 2.1.5 Precedence: list List-Id: Xen developer discussion <xen-devel.lists.xensource.com> List-Unsubscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe> List-Post: <mailto:xen-devel@lists.xensource.com> List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help> List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=subscribe> Sender: xen-devel-bounces@lists.xensource.com Errors-To: xen-devel-bounces@lists.xensource.com Signed-off-by: Stefano Stabellini <stefano.stabellini@eu.citrix.com> diff -r 5553e17faa80 .hgignore --- a/.hgignore Fri Sep 23 11:36:44 2011 +0000 +++ b/.hgignore Fri Sep 23 11:37:08 2011 +0000 @@ -293,6 +293,8 @@ ^tools/xm-test/tests/.*\.test$ ^tools/qemu-xen-traditional-dir-remote ^tools/qemu-xen-traditional-dir$ +^tools/qemu-xen-dir-remote +^tools/qemu-xen-dir$ ^tools/ocaml/.*/.*\.annot$ ^tools/ocaml/.*/.*\.cmx?a$ ^tools/ocaml/.*/META$ diff -r 5553e17faa80 Config.mk --- a/Config.mk Fri Sep 23 11:36:44 2011 +0000 +++ b/Config.mk Fri Sep 23 11:37:08 2011 +0000 @@ -192,6 +192,13 @@ else QEMU_REMOTE=git://xenbits.xensource.com/qemu-xen-unstable.git endif +ifeq ($(GIT_HTTP),y) +QEMU_UPSTREAM_URL ?= http://xenbits.xensource.com/git-http/qemu-upstream-unstable.git +else +QEMU_UPSTREAM_URL ?= git://xenbits.xensource.com/qemu-upstream-unstable.git +endif +QEMU_UPSTREAM_TAG ?= 6dd84c71dff047f9e492d67e7c99928d09202760 + # Specify which qemu-dm to use. This may be `ioemu' to use the old # Mercurial in-tree version, or a local directory, or a git URL. # CONFIG_QEMU ?= `pwd`/$(XEN_ROOT)/../qemu-xen.git diff -r 5553e17faa80 Makefile --- a/Makefile Fri Sep 23 11:36:44 2011 +0000 +++ b/Makefile Fri Sep 23 11:37:08 2011 +0000 @@ -70,7 +70,7 @@ install-tools: $(MAKE) -C tools install ifeq ($(CONFIG_IOEMU),y) -install-tools: tools/qemu-xen-traditional-dir +install-tools: tools/qemu-xen-traditional-dir tools/qemu-xen-dir endif .PHONY: install-kernels @@ -91,6 +91,9 @@ tools/qemu-xen-traditional-dir: tools/qemu-xen-traditional-dir-force-update: $(MAKE) -C tools qemu-xen-traditional-dir-force-update +tools/qemu-xen-dir: + $(MAKE) -C tools qemu-xen-dir-find + .PHONY: install-docs install-docs: sh ./docs/check_pkgs && $(MAKE) -C docs install || true diff -r 5553e17faa80 tools/Makefile --- a/tools/Makefile Fri Sep 23 11:36:44 2011 +0000 +++ b/tools/Makefile Fri Sep 23 11:37:08 2011 +0000 @@ -31,6 +31,7 @@ SUBDIRS-$(LIBXENAPI_BINDINGS) += libxen # do not recurse in to a dir we are about to delete ifneq "$(MAKECMDGOALS)" "distclean" SUBDIRS-$(CONFIG_IOEMU) += qemu-xen-traditional-dir +SUBDIRS-$(CONFIG_IOEMU) += qemu-xen-dir endif SUBDIRS-y += xenpmd @@ -71,6 +72,7 @@ clean: subdirs-clean .PHONY: distclean distclean: subdirs-distclean rm -rf qemu-xen-traditional-dir qemu-xen-traditional-dir-remote + rm -rf qemu-xen-dir qemu-xen-dir-remote ifneq ($(XEN_COMPILE_ARCH),$(XEN_TARGET_ARCH)) IOEMU_CONFIGURE_CROSS ?= --cpu=$(XEN_TARGET_ARCH) \ @@ -96,6 +98,25 @@ qemu-xen-traditional-dir-find: cd qemu-xen-traditional-dir; \ $(QEMU_ROOT)/xen-setup $(IOEMU_CONFIGURE_CROSS) +qemu-xen-dir-find: + if test -d $(QEMU_UPSTREAM_URL) ; then \ + ln -sf $(QEMU_UPSTREAM_URL) qemu-xen-dir; \ + else \ + export GIT=$(GIT); \ + $(XEN_ROOT)/scripts/git-checkout.sh $(QEMU_UPSTREAM_URL) $(QEMU_UPSTREAM_TAG) qemu-xen-dir ; \ + fi + cd qemu-xen-dir; \ + ./configure --enable-xen --target-list=i386-softmmu \ + --source-path=$$ROOT \ + --extra-cflags="-I$(XEN_ROOT)/tools/include \ + -I$(XEN_ROOT)/tools/libxc \ + -I$(XEN_ROOT)/tools/xenstore" \ + --extra-ldflags="-L$(XEN_ROOT)/tools/libxc \ + -L$(XEN_ROOT)/tools/libxenstore" \ + --bindir=$(LIBEXEC) \ + --disable-kvm \ + $(IOEMU_CONFIGURE_CROSS) + .PHONY: qemu-xen-traditional-dir-force-update qemu-xen-traditional-dir-force-update: set -ex; \ @@ -113,6 +134,14 @@ subdir-clean-qemu-xen-traditional-dir: $(MAKE) -C qemu-xen-traditional-dir clean; \ fi +subdir-all-qemu-xen-dir subdir-install-qemu-xen-dir: qemu-xen-dir-find + +subdir-clean-qemu-xen-dir: + set -e; if test -d qemu-xen-dir/.; then \ + $(buildmakevars2shellvars); \ + $(MAKE) -C qemu-xen-dir clean; \ + fi + subdir-clean-debugger/gdbsx subdir-distclean-debugger/gdbsx: .phony $(MAKE) -C debugger/gdbsx clean _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel From xen-devel-bounces@lists.xensource.com Fri Sep 30 07:27:15 2011 Return-path: <xen-devel-bounces@lists.xensource.com> Envelope-to: www-data@lists.xensource.com Delivery-date: Fri, 30 Sep 2011 07:27:15 -0700 Received: from localhost ([127.0.0.1] helo=lists.colo.xensource.com) by lists.xensource.com with esmtp (Exim 4.43) id 1R9e3X-0007QG-HC; Fri, 30 Sep 2011 07:27:15 -0700 Received: from mail216.messagelabs.com ([85.158.143.99]) by lists.xensource.com with esmtp (Exim 4.43) id 1R9dxS-0005OM-34; Fri, 30 Sep 2011 07:20:59 -0700 X-Env-Sender: joseph.glanville@orionvm.com.au X-Msg-Ref: server-13.tower-216.messagelabs.com!1317392453!18485882!1 X-Originating-IP: [209.85.220.171] X-StarScan-Version: 6.4.1; banners=-,-,- X-VirusChecked: Checked Received: (qmail 22357 invoked from network); 30 Sep 2011 14:20:54 -0000 Received: from mail-vx0-f171.google.com (HELO mail-vx0-f171.google.com) (209.85.220.171) by server-13.tower-216.messagelabs.com with RC4-SHA encrypted SMTP; 30 Sep 2011 14:20:54 -0000 Received: by vcbfo13 with SMTP id fo13so1858183vcb.30 for <multiple recipients>; Fri, 30 Sep 2011 07:20:52 -0700 (PDT) MIME-Version: 1.0 Received: by 10.220.141.144 with SMTP id m16mr3365685vcu.107.1317392452667; Fri, 30 Sep 2011 07:20:52 -0700 (PDT) Received: by 10.220.195.135 with HTTP; Fri, 30 Sep 2011 07:20:52 -0700 (PDT) X-Originating-IP: [59.167.234.130] In-Reply-To: <4E85A9B7.7040605@xen.org> References: <20110922130618.GA13238@phenom.oracle.com> <20110929141317.GX12984@reaktio.net> <CAOzFzEieWhgoBWEXQFjqr8PYoVOAcU20rtA2Q3OhyA+=dD9Atg@mail.gmail.com> <4E85A9B7.7040605@xen.org> Date: Sat, 1 Oct 2011 00:20:52 +1000 Message-ID: <CAOzFzEhae7DrxK3eAy4wQetD6Df=x8w38ddLF6XDxC0as96V2A@mail.gmail.com> Subject: Re: [Xen-devel] Xen document day (Oct 12 or 26) From: Joseph Glanville <joseph.glanville@orionvm.com.au> To: Lars Kurth <lars.kurth@xen.org> Cc: xen-devel@lists.xensource.com, xen-users@lists.xensource.com, Konrad Rzeszutek Wilk <konrad.wilk@oracle.com> X-BeenThere: xen-devel@lists.xensource.com X-Mailman-Version: 2.1.5 Precedence: list List-Id: Xen developer discussion <xen-devel.lists.xensource.com> List-Unsubscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe> List-Post: <mailto:xen-devel@lists.xensource.com> List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help> List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=subscribe> Content-Type: multipart/mixed; boundary="===============2040028780==" Sender: xen-devel-bounces@lists.xensource.com Errors-To: xen-devel-bounces@lists.xensource.com --===============2040028780== Content-Type: multipart/alternative; boundary=f46d043be0482bc7ba04ae295545 --f46d043be0482bc7ba04ae295545 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Hi Lars, What timeline do you think there is for migrating to a new wiki/cleaning ou= t the cruft? I am working on a migration strategy (abit more of a full fix rather than a short term kludge) in this doc here: https://docs.google.com/spreadsheet/ccc?key=3D0AiRyVp8djqV3dEJRdVZaQzZmLVNK= TERwMDNGaTlKdkE&hl=3Den_US To achieve this we are probably going to need a way of categorizing and seperating XCP, Xen.org,etc wiki content. Once that structure has been decided on I am happy to go about categorizing all of the current good content and working out what needs to be written/updated. Joseph. On 30 September 2011 21:36, Lars Kurth <lars.kurth@xen.org> wrote: > Let me know, which date you agreed on. We could do a poll. > We should publish on the blog a bit before. > Also, how can I help? > Regards > Lars > > > On 29/09/2011 15:22, Joseph Glanville wrote: > > > On 30 September 2011 00:13, Pasi K=E4rkk=E4inen <pasik@iki.fi> wrote: > >> On Thu, Sep 22, 2011 at 09:06:18AM -0400, Konrad Rzeszutek Wilk wrote: >> > Part of what we brainstormed at Xen Hackathon was what we could do mak= e >> Xen easier. >> > >> > And the one thing that seemed to surface up was making the docs better= - >> either >> > be the Wiki or the three .pdfs that get created/shipped with Xen. >> > >> > One thought was to come up with a Documention Day - where volunteers >> would try to >> > fix up some portion of the documentation that they feel they have >> > a good grasp of knowledge off and are willing to change (and also look >> > to be incorrect) >> > >> > What do you guys think of Oct 12th or Oct 26 as a day for this? >> > >> > And then the next question - what page/pdf section interests you? >> > >> > http://bits.xensource.com/Xen/docs/user.pdf >> > http://www.rites.uic.edu/~solworth/xenInterfaceManual.pdf [the one on >> Xen.org is an older version] >> > >> > Or Wiki pages: >> > http://wiki.xensource.com/xenwiki/ >> > >> > http://wiki.xensource.com/xenwiki/XenDom0Kernels >> > http://wiki.xensource.com/xenwiki/XenSerialConsole >> > http://wiki.xensource.com/xenwiki/XenParavirtOps >> > http://wiki.xensource.com/xenwiki/XenCommonProblems >> > >> > http://wiki.xensource.com/xenwiki/Consulting >> > http://wiki.xensource.com/xenwiki/Consultants >> > http://wiki.xensource.com/xenwiki/VpsHostingWithXen >> > >> > http://wiki.xen.org/xenwiki/XenPCIpassthrough >> > http://wiki.xen.org/xenwiki/VTdHowTo >> > >> >> Some more related pages: >> http://wiki.xen.org/xenwiki/Xen4.0 >> http://wiki.xen.org/xenwiki/Xen4.1 >> http://wiki.xen.org/xenwiki/XenKernelFeatures >> http://wiki.xen.org/xenwiki/XenBestPractices >> http://wiki.xen.org/xenwiki/XenHypervisorBootOptions >> >> Also there's something completely new that we should document: >> How to install Xen VMs! which means document all the relevant methods: >> boot the native distro installer as PV guest, as HVM guest, xen-tools, >> virt-install, >> debootstrap, rpmstart, etc.. >> >> That's something people ask about very often.. >> > > Agreed. > > After working through a bunch of the pages I think we are going to have t= o > have a realtime collab session to decide on some way of reorganising > everything into categories. > > > >> -- Pasi >> >> >> _______________________________________________ >> Xen-devel mailing list >> Xen-devel@lists.xensource.com >> http://lists.xensource.com/xen-devel >> > > > > -- > * > Founder | Director | VP Research > Orion Virtualisation Solutions* | www.orionvm.com.au | Phone: 1300 56 99 > 52 | Mobile: 0428 754 846 > > > _______________________________________________ > Xen-devel mailing listXen-devel@lists.xensource.comhttp://lists.xensource= .com/xen-devel > > > --=20 * Founder | Director | VP Research Orion Virtualisation Solutions* | www.orionvm.com.au | Phone: 1300 56 99 52 | Mobile: 0428 754 846 --f46d043be0482bc7ba04ae295545 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Hi Lars,<br><br>What timeline do you think there is for migrating to a new = wiki/cleaning out the cruft?<br>I am working on a migration strategy (abit = more of a full fix rather than a short term kludge) in this doc here:<br> <a href=3D"https://docs.google.com/spreadsheet/ccc?key=3D0AiRyVp8djqV3dEJRd= VZaQzZmLVNKTERwMDNGaTlKdkE&hl=3Den_US" target=3D"_blank">https://docs.g= oogle.com/spreadsheet/ccc?key=3D0AiRyVp8djqV3dEJRdVZaQzZmLVNKTERwMDNGaTlKdk= E&hl=3Den_US</a><br> <br>To achieve this we are probably going to need a way of categorizing and= seperating XCP, Xen.org,etc wiki content.<br>Once that structure has been = decided on I am happy to go about categorizing all of the current good cont= ent and working out what needs to be written/updated.<br> <br>Joseph.<br><br><div class=3D"gmail_quote">On 30 September 2011 21:36, L= ars Kurth <span dir=3D"ltr"><<a href=3D"mailto:lars.kurth@xen.org">lars.= kurth@xen.org</a>></span> wrote:<br><blockquote class=3D"gmail_quote" st= yle=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;"> =20 =20 =20 <div bgcolor=3D"#FFFFFF" text=3D"#000000"> Let me know, which date you agreed on. We could do a poll.<br> We should publish on the blog a bit before.<br> Also, how can I help?<br> Regards<br><font color=3D"#888888"> Lars</font><div><div></div><div class=3D"h5"><br> <br> On 29/09/2011 15:22, Joseph Glanville wrote: <blockquote type=3D"cite"><br> <div class=3D"gmail_quote">On 30 September 2011 00:13, Pasi K=E4rkk=E4inen <span dir=3D"ltr"><<a href=3D"mailto:pasik@iki.fi= " target=3D"_blank">pasik@iki.fi</a>></span> wrote:<br> <blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border= -left:1px #ccc solid;padding-left:1ex"> <div>On Thu, Sep 22, 2011 at 09:06:18AM -0400, Konrad Rzeszutek Wilk wrote:<br> > Part of what we brainstormed at Xen Hackathon was what we could do make Xen easier.<br> ><br> > And the one thing that seemed to surface up was making the docs better - either<br> > be the Wiki or the three .pdfs that get created/shipped with Xen.<br> ><br> > One thought was to come up with a Documention Day - where volunteers would try to<br> > fix up some portion of the documentation that they feel they have<br> > a good grasp of knowledge off and are willing to change (and also look<br> > to be incorrect)<br> ><br> > What do you guys think of Oct 12th or Oct 26 as a day for this?<br> ><br> > And then the next question - what page/pdf section interests you?<br> ><br> > <a href=3D"http://bits.xensource.com/Xen/docs/user.pdf" ta= rget=3D"_blank">http://bits.xensource.com/Xen/docs/user.pdf</a><br> > <a href=3D"http://www.rites.uic.edu/%7Esolworth/xenInterfa= ceManual.pdf" target=3D"_blank">http://www.rites.uic.edu/~solworth/xenInter= faceManual.pdf</a> [the one on Xen.org is an older version]<br> ><br> > Or Wiki pages:<br> > <a href=3D"http://wiki.xensource.com/xenwiki/" target=3D"_= blank">http://wiki.xensource.com/xenwiki/</a><br> ><br> > <a href=3D"http://wiki.xensource.com/xenwiki/XenDom0Kernel= s" target=3D"_blank">http://wiki.xensource.com/xenwiki/XenDom0Kernels</a><b= r> > <a href=3D"http://wiki.xensource.com/xenwiki/XenSerialCons= ole" target=3D"_blank">http://wiki.xensource.com/xenwiki/XenSerialConsole</= a><br> > <a href=3D"http://wiki.xensource.com/xenwiki/XenParavirtOp= s" target=3D"_blank">http://wiki.xensource.com/xenwiki/XenParavirtOps</a><b= r> > <a href=3D"http://wiki.xensource.com/xenwiki/XenCommonProb= lems" target=3D"_blank">http://wiki.xensource.com/xenwiki/XenCommonProblems= </a><br> ><br> > <a href=3D"http://wiki.xensource.com/xenwiki/Consulting" t= arget=3D"_blank">http://wiki.xensource.com/xenwiki/Consulting</a><br> > <a href=3D"http://wiki.xensource.com/xenwiki/Consultants" = target=3D"_blank">http://wiki.xensource.com/xenwiki/Consultants</a><br> > <a href=3D"http://wiki.xensource.com/xenwiki/VpsHostingWit= hXen" target=3D"_blank">http://wiki.xensource.com/xenwiki/VpsHostingWithXen= </a><br> ><br> > <a href=3D"http://wiki.xen.org/xenwiki/XenPCIpassthrough" = target=3D"_blank">http://wiki.xen.org/xenwiki/XenPCIpassthrough</a><br> > <a href=3D"http://wiki.xen.org/xenwiki/VTdHowTo" target=3D= "_blank">http://wiki.xen.org/xenwiki/VTdHowTo</a><br> ><br> <br> </div> Some more related pages:<br> <a href=3D"http://wiki.xen.org/xenwiki/Xen4.0" target=3D"_blank">= http://wiki.xen.org/xenwiki/Xen4.0</a><br> <a href=3D"http://wiki.xen.org/xenwiki/Xen4.1" target=3D"_blank">= http://wiki.xen.org/xenwiki/Xen4.1</a><br> <a href=3D"http://wiki.xen.org/xenwiki/XenKernelFeatures" target= =3D"_blank">http://wiki.xen.org/xenwiki/XenKernelFeatures</a><br> <a href=3D"http://wiki.xen.org/xenwiki/XenBestPractices" target= =3D"_blank">http://wiki.xen.org/xenwiki/XenBestPractices</a><br> <a href=3D"http://wiki.xen.org/xenwiki/XenHypervisorBootOptions" = target=3D"_blank">http://wiki.xen.org/xenwiki/XenHypervisorBootOptions</a><= br> <br> Also there's something completely new that we should document= :<br> How to install Xen VMs! which means document all the relevant methods:<br> boot the native distro installer as PV guest, as HVM guest, xen-tools, virt-install,<br> debootstrap, rpmstart, etc..<br> <br> That's something people ask about very often..<br> </blockquote> <div>=A0</div> <div>Agreed. <br> <br> After working through a bunch of the pages I think we are going to have to have a realtime collab session to decide on some way of reorganising everything into categories.<br> <br> <br> </div> <blockquote class=3D"gmail_quote" style=3D"margin:0pt 0pt 0pt 0.8ex= ;border-left:1px solid rgb(204, 204, 204);padding-left:1ex"> <font color=3D"#888888"><br> -- Pasi<br> </font> <div> <div><br> <br> _______________________________________________<br> Xen-devel mailing list<br> <a href=3D"mailto:Xen-devel@lists.xensource.com" target=3D"_b= lank">Xen-devel@lists.xensource.com</a><br> <a href=3D"http://lists.xensource.com/xen-devel" target=3D"_b= lank">http://lists.xensource.com/xen-devel</a><br> </div> </div> </blockquote> </div> <br> <br clear=3D"all"> <br> -- <br> <span style=3D"font-family:arial,sans-serif;font-size:13px;border-col= lapse:collapse"><b><i><font color=3D"#0000ff"> <div><font color=3D"#000000"><span style=3D"font-style:normal= ;font-weight:normal">Founder | Director | VP Research<br> </span></font></div> Orion Virtualisation Solutions</font></i></b>=A0|=A0<font col= or=3D"#0000ff"><a href=3D"http://www.orionvm.com.au/" style=3D"color:rgb(42= , 93, 176)" target=3D"_blank">www.orionvm.com.au</a></font>=A0| Phone: 1300 56 99 52 | Mobile: 0428 754 846</span><br> <br> <fieldset></fieldset> <br> <pre>_______________________________________________ Xen-devel mailing list <a href=3D"mailto:Xen-devel@lists.xensource.com" target=3D"_blank">Xen-deve= l@lists.xensource.com</a> <a href=3D"http://lists.xensource.com/xen-devel" target=3D"_blank">http://l= ists.xensource.com/xen-devel</a> </pre> </blockquote> <br> </div></div></div> </blockquote></div><br><br clear=3D"all"><br>-- <br><span style=3D"font-fam= ily:arial,sans-serif;font-size:13px;border-collapse:collapse"><b><i><font c= olor=3D"#0000ff"><div><font color=3D"#000000"><span style=3D"font-style:nor= mal;font-weight:normal">Founder | Director | VP Research<br> </span></font></div>Orion Virtualisation Solutions</font></i></b>=A0|=A0<fo= nt color=3D"#0000ff"><a href=3D"http://www.orionvm.com.au/" style=3D"color:= rgb(42, 93, 176)" target=3D"_blank">www.orionvm.com.au</a></font>=A0| Phone= : 1300 56 99 52 | Mobile: 0428 754 846</span><br> --f46d043be0482bc7ba04ae295545-- --===============2040028780== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel --===============2040028780==-- From xen-devel-bounces@lists.xensource.com Fri Sep 30 07:30:23 2011 Return-path: <xen-devel-bounces@lists.xensource.com> Envelope-to: www-data@lists.xensource.com Delivery-date: Fri, 30 Sep 2011 07:30:23 -0700 Received: from localhost ([127.0.0.1] helo=lists.colo.xensource.com) by lists.xensource.com with esmtp (Exim 4.43) id 1R9e6Z-000080-Ft; Fri, 30 Sep 2011 07:30:23 -0700 Received: from mail21.messagelabs.com ([85.158.143.35]) by lists.xensource.com with esmtp (Exim 4.43) id 1R9dyv-0005xu-IW for xen-devel@lists.xensource.com; Fri, 30 Sep 2011 07:22:29 -0700 X-Env-Sender: Ian.Campbell@eu.citrix.com X-Msg-Ref: server-14.tower-21.messagelabs.com!1317392537!61621475!1 X-Originating-IP: [62.200.22.115] X-StarScan-Version: 6.4.1; banners=-,-,- X-VirusChecked: Checked Received: (qmail 9349 invoked from network); 30 Sep 2011 14:22:18 -0000 Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115) by server-14.tower-21.messagelabs.com with RC4-SHA encrypted SMTP; 30 Sep 2011 14:22:18 -0000 X-IronPort-AV: E=Sophos;i="4.68,467,1312156800"; d="scan'208";a="8154515" Received: from lonpmailmx01.citrite.net ([10.30.203.162]) by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5; 30 Sep 2011 14:22:26 +0000 Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net (10.30.203.162) with Microsoft SMTP Server id 8.3.137.0; Fri, 30 Sep 2011 15:22:26 +0100 Subject: Re: [Xen-devel] use hypercall in Dom0's kernel From: Ian Campbell <Ian.Campbell@eu.citrix.com> To: David Xu <davidxu06@gmail.com>, xen-devel <xen-devel@lists.xensource.com> Date: Fri, 30 Sep 2011 15:22:26 +0100 In-Reply-To: <CAGjowiSbzeBDRAJOM0dKiq4K76jEaKYhVwn2wTysUSa4PHpDDA@mail.gmail.com> References: <CAGjowiSLv2Wa9KgfVBmi9yZ5OBPvbX9NYb+3BaDg=iVbty-kuA@mail.gmail.com> <1317368165.26672.200.camel@zakaz.uk.xensource.com> <CAGjowiSbzeBDRAJOM0dKiq4K76jEaKYhVwn2wTysUSa4PHpDDA@mail.gmail.com> Organization: Citrix Systems, Inc. Content-Type: text/plain; charset="UTF-8" X-Mailer: Evolution 3.0.3- Content-Transfer-Encoding: 7bit Message-ID: <1317392546.26672.287.camel@zakaz.uk.xensource.com> MIME-Version: 1.0 Cc: X-BeenThere: xen-devel@lists.xensource.com X-Mailman-Version: 2.1.5 Precedence: list List-Id: Xen developer discussion <xen-devel.lists.xensource.com> List-Unsubscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe> List-Post: <mailto:xen-devel@lists.xensource.com> List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help> List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=subscribe> Sender: xen-devel-bounces@lists.xensource.com Errors-To: xen-devel-bounces@lists.xensource.com Please don't top post and always CC the list. I've put xen-devel back this time. On Fri, 2011-09-30 at 15:14 +0100, David Xu wrote: > Hi, > > I modify the bridge module of Dom0 and sniff the packets which go > through Dom0. I want to notify the hypervisor if some special packets > come. So I want to call some interface function which are defined in > libxc (libxenctrl). But if I include the xenctrl.h or some related > head file in the br.c or br_input.c which are parts of bridge module > codes, I will encounter the compiling error (can not find the head > file). Of course you cannot link userspace code into the kernel. If you need access to hypercalls then you have them available in the kernel in raw form in the kernel. Ian. _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel From xen-devel-bounces@lists.xensource.com Fri Sep 30 07:31:11 2011 Return-path: <xen-devel-bounces@lists.xensource.com> Envelope-to: www-data@lists.xensource.com Delivery-date: Fri, 30 Sep 2011 07:31:11 -0700 Received: from localhost ([127.0.0.1] helo=lists.colo.xensource.com) by lists.xensource.com with esmtp (Exim 4.43) id 1R9e7K-0000VM-Vn; Fri, 30 Sep 2011 07:31:10 -0700 Received: from mail216.messagelabs.com ([85.158.143.99]) by lists.xensource.com with esmtp (Exim 4.43) id 1R9e0U-0006QL-Cj for xen-devel@lists.xensource.com; Fri, 30 Sep 2011 07:24:07 -0700 X-Env-Sender: konrad@oracle.com X-Msg-Ref: server-9.tower-216.messagelabs.com!1317392642!20170760!1 X-Originating-IP: [148.87.113.117] X-StarScan-Version: 6.4.1; banners=-,-,- X-VirusChecked: Checked Received: (qmail 24153 invoked from network); 30 Sep 2011 14:24:03 -0000 Received: from rcsinet15.oracle.com (HELO rcsinet15.oracle.com) (148.87.113.117) by server-9.tower-216.messagelabs.com with DHE-RSA-AES256-SHA encrypted SMTP; 30 Sep 2011 14:24:03 -0000 Received: from acsinet22.oracle.com (acsinet22.oracle.com [141.146.126.238]) by rcsinet15.oracle.com (Switch-3.4.4/Switch-3.4.4) with ESMTP id p8UENDdY010993 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Fri, 30 Sep 2011 14:23:15 GMT Received: from acsmt356.oracle.com (acsmt356.oracle.com [141.146.40.156]) by acsinet22.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id p8UENAKa004941 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 30 Sep 2011 14:23:10 GMT Received: from abhmt109.oracle.com (abhmt109.oracle.com [141.146.116.61]) by acsmt356.oracle.com (8.12.11.20060308/8.12.11) with ESMTP id p8UEN2Ga006540; Fri, 30 Sep 2011 09:23:02 -0500 Received: from oracle.com (/207.172.105.198) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Fri, 30 Sep 2011 07:23:02 -0700 Received: by oracle.com (Postfix, from userid 1000) id D616C46E; Fri, 30 Sep 2011 10:22:59 -0400 (EDT) Date: Fri, 30 Sep 2011 10:22:59 -0400 From: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com> To: Jeremy Fitzhardinge <jeremy@goop.org>, akpm@linux-foundation.org Message-ID: <20110930142259.GA25454@phenom.oracle.com> References: <1317042797-19975-1-git-send-email-konrad.wilk@oracle.com> <4E80A6BD.3070703@goop.org> <20110926193453.GA9717@phenom.oracle.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20110926193453.GA9717@phenom.oracle.com> User-Agent: Mutt/1.5.21 (2010-09-15) X-Source-IP: acsinet22.oracle.com [141.146.126.238] X-Auth-Type: Internal IP X-CT-RefId: str=0001.0A090204.4E85D0D4.00E6:SCFMA922111,ss=1,re=-4.000,fgs=0 Cc: xen-devel@lists.xensource.com, Peter Zijlstra <a.p.zijlstra@chello.nl>, Jeremy Fitzhardinge <jeremy.fitzhardinge@citrix.com>, x86@kernel.org, linux-kernel@vger.kernel.org, stefan.bader@canonical.com, Ingo Molnar <mingo@redhat.com>, "H. Peter Anvin" <hpa@zytor.com>, Thomas Gleixner <tglx@linutronix.de>, stable@kernel.org Subject: [Xen-devel] Re: Is: [PATCH] x86/paravirt: PTE updates in k(un)map_atomic need to be synchronous, regardless of lazy_mmu mode. Was: Re: [PATCH] x86/paravirt: Partially revert "remove lazy mode in interrupts" X-BeenThere: xen-devel@lists.xensource.com X-Mailman-Version: 2.1.5 Precedence: list List-Id: Xen developer discussion <xen-devel.lists.xensource.com> List-Unsubscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe> List-Post: <mailto:xen-devel@lists.xensource.com> List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help> List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=subscribe> Sender: xen-devel-bounces@lists.xensource.com Errors-To: xen-devel-bounces@lists.xensource.com > >From 09966678dd645b68a422c9bf0223b13e73387302 Mon Sep 17 00:00:00 2001 > From: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com> > Date: Fri, 23 Sep 2011 17:02:29 -0400 > Subject: [PATCH] x86/paravirt: PTE updates in k(un)map_atomic need to be synchronous, regardless of lazy_mmu mode. > > This patch fixes an outstanding issue that has been reported since 2.6.37. > Under a heavy loaded machine processing "fork()" calls could keepover with: Hm, looks like I forgot to include Andrew on this. Andrew, what is your opinion on this tiny little critical patch? > > BUG: unable to handle kernel paging request at f573fc8c > IP: [<c01abc54>] swap_count_continued+0x104/0x180 > *pdpt = 000000002a3b9027 *pde = 0000000001bed067 *pte = 0000000000000000 > Oops: 0000 [#1] SMP > Modules linked in: > Pid: 1638, comm: apache2 Not tainted 3.0.4-linode37 #1 > EIP: 0061:[<c01abc54>] EFLAGS: 00210246 CPU: 3 > EIP is at swap_count_continued+0x104/0x180 > .. snip.. > Call Trace: > [<c01ac222>] ? __swap_duplicate+0xc2/0x160 > [<c01040f7>] ? pte_mfn_to_pfn+0x87/0xe0 > [<c01ac2e4>] ? swap_duplicate+0x14/0x40 > [<c01a0a6b>] ? copy_pte_range+0x45b/0x500 > [<c01a0ca5>] ? copy_page_range+0x195/0x200 > [<c01328c6>] ? dup_mmap+0x1c6/0x2c0 > [<c0132cf8>] ? dup_mm+0xa8/0x130 > [<c013376a>] ? copy_process+0x98a/0xb30 > [<c013395f>] ? do_fork+0x4f/0x280 > [<c01573b3>] ? getnstimeofday+0x43/0x100 > [<c010f770>] ? sys_clone+0x30/0x40 > [<c06c048d>] ? ptregs_clone+0x15/0x48 > [<c06bfb71>] ? syscall_call+0x7/0xb > > The problem is that in copy_page_range we turn lazy mode on, and then > in swap_entry_free we call swap_count_continued which ends up in: > > map = kmap_atomic(page, KM_USER0) + offset; > > and then later we touch *map. > > Since we are running in batched mode (lazy) we don't actually set up the > PTE mappings and the kmap_atomic is not done synchronously and ends up > trying to dereference a page that has not been set. > > Looking at kmap_atomic_prot_pfn, it uses 'arch_flush_lazy_mmu_mode' and > doing the same in kmap_atomic_prot and __kunmap_atomic makes the problem > go away. > > Interestingly, git commit b8bcfe997e46150fedcc3f5b26b846400122fdd9 > removed part of this to fix an interrupt issue - but it went to far > and did not consider this scenario. > > CC: Thomas Gleixner <tglx@linutronix.de> > CC: Ingo Molnar <mingo@redhat.com> > CC: "H. Peter Anvin" <hpa@zytor.com> > CC: x86@kernel.org > CC: Peter Zijlstra <a.p.zijlstra@chello.nl> > CC: Jeremy Fitzhardinge <jeremy.fitzhardinge@citrix.com> > CC: stable@kernel.org > [v1: Redid the commit description per Jeremy's apt suggestion] > Signed-off-by: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com> > --- > arch/x86/mm/highmem_32.c | 2 ++ > 1 files changed, 2 insertions(+), 0 deletions(-) > > diff --git a/arch/x86/mm/highmem_32.c b/arch/x86/mm/highmem_32.c > index b499626..f4f29b1 100644 > --- a/arch/x86/mm/highmem_32.c > +++ b/arch/x86/mm/highmem_32.c > @@ -45,6 +45,7 @@ void *kmap_atomic_prot(struct page *page, pgprot_t prot) > vaddr = __fix_to_virt(FIX_KMAP_BEGIN + idx); > BUG_ON(!pte_none(*(kmap_pte-idx))); > set_pte(kmap_pte-idx, mk_pte(page, prot)); > + arch_flush_lazy_mmu_mode(); > > return (void *)vaddr; > } > @@ -88,6 +89,7 @@ void __kunmap_atomic(void *kvaddr) > */ > kpte_clear_flush(kmap_pte-idx, vaddr); > kmap_atomic_idx_pop(); > + arch_flush_lazy_mmu_mode(); > } > #ifdef CONFIG_DEBUG_HIGHMEM > else { > -- > 1.7.4.1 > > -- > To unsubscribe from this list: send the line "unsubscribe linux-kernel" in > the body of a message to majordomo@vger.kernel.org > More majordomo info at http://vger.kernel.org/majordomo-info.html > Please read the FAQ at http://www.tux.org/lkml/ _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel From xen-devel-bounces@lists.xensource.com Fri Sep 30 07:33:59 2011 Return-path: <xen-devel-bounces@lists.xensource.com> Envelope-to: www-data@lists.xensource.com Delivery-date: Fri, 30 Sep 2011 07:33:59 -0700 Received: from localhost ([127.0.0.1] helo=lists.colo.xensource.com) by lists.xensource.com with esmtp (Exim 4.43) id 1R9eA2-00027Q-WA; Fri, 30 Sep 2011 07:33:59 -0700 Received: from mail216.messagelabs.com ([85.158.143.99]) by lists.xensource.com with esmtp (Exim 4.43) id 1R9e1v-0006lj-Ek for xen-devel@lists.xensource.com; Fri, 30 Sep 2011 07:25:36 -0700 X-Env-Sender: Christoph.Egger@amd.com X-Msg-Ref: server-7.tower-216.messagelabs.com!1317392732!20163150!1 X-Originating-IP: [213.199.154.140] X-StarScan-Version: 6.4.1; banners=-,-,- X-VirusChecked: Checked Received: (qmail 31594 invoked from network); 30 Sep 2011 14:25:32 -0000 Received: from db3ehsobe002.messaging.microsoft.com (HELO DB3EHSOBE002.bigfish.com) (213.199.154.140) by server-7.tower-216.messagelabs.com with AES128-SHA encrypted SMTP; 30 Sep 2011 14:25:32 -0000 Received: from mail63-db3-R.bigfish.com (10.3.81.241) by DB3EHSOBE002.bigfish.com (10.3.84.22) with Microsoft SMTP Server id 14.1.225.22; Fri, 30 Sep 2011 14:25:32 +0000 Received: from mail63-db3 (localhost.localdomain [127.0.0.1]) by mail63-db3-R.bigfish.com (Postfix) with ESMTP id 2721BC30596; Fri, 30 Sep 2011 14:25:32 +0000 (UTC) X-SpamScore: -11 X-BigFish: VPS-11(zzbb2dK1432N98dKzz1202hzz8275bhz32i668h839h61h) X-Spam-TCS-SCL: 0:0 X-Forefront-Antispam-Report: CIP:163.181.249.109; KIP:(null); UIP:(null); IPVD:NLI; H:ausb3twp02.amd.com; RD:none; EFVD:NLI X-FB-SS: 0, Received: from mail63-db3 (localhost.localdomain [127.0.0.1]) by mail63-db3 (MessageSwitch) id 131739273163760_17562; Fri, 30 Sep 2011 14:25:31 +0000 (UTC) Received: from DB3EHSMHS002.bigfish.com (unknown [10.3.81.251]) by mail63-db3.bigfish.com (Postfix) with ESMTP id 00096248051; Fri, 30 Sep 2011 14:25:30 +0000 (UTC) Received: from ausb3twp02.amd.com (163.181.249.109) by DB3EHSMHS002.bigfish.com (10.3.87.102) with Microsoft SMTP Server id 14.1.225.22; Fri, 30 Sep 2011 14:25:28 +0000 X-WSS-ID: 0LSCAQ9-02-1X8-02 X-M-MSG: Received: from sausexedgep02.amd.com (sausexedgep02-ext.amd.com [163.181.249.73]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by ausb3twp02.amd.com (Axway MailGate 3.8.1) with ESMTP id 2AA19C83D4; Fri, 30 Sep 2011 09:25:20 -0500 (CDT) Received: from SAUSEXDAG01.amd.com (163.181.55.1) by sausexedgep02.amd.com (163.181.36.59) with Microsoft SMTP Server (TLS) id 8.3.106.1; Fri, 30 Sep 2011 09:25:43 -0500 Received: from storexhtp02.amd.com (172.24.4.4) by sausexdag01.amd.com (163.181.55.1) with Microsoft SMTP Server (TLS) id 14.1.289.1; Fri, 30 Sep 2011 09:25:25 -0500 Received: from rhodium.osrc.amd.com (165.204.15.173) by storexhtp02.amd.com (172.24.4.4) with Microsoft SMTP Server id 8.3.83.0; Fri, 30 Sep 2011 10:25:12 -0400 Message-ID: <4E85D146.4030601@amd.com> Date: Fri, 30 Sep 2011 16:25:10 +0200 From: Christoph Egger <Christoph.Egger@amd.com> User-Agent: Mozilla/5.0 (X11; U; NetBSD amd64; en-US; rv:1.9.2.17) Gecko/20110523 Lightning/1.0b3pre Thunderbird/3.1.10 MIME-Version: 1.0 To: "stefano.stabellini@eu.citrix.com" <stefano.stabellini@eu.citrix.com> Subject: Re: [Xen-devel] [PATCH v7 5/5] libxl: use new qemu at the location where xen-unstable installs it References: <alpine.DEB.2.00.1109301514460.3519@kaball-desktop> <1317392440-4137-5-git-send-email-stefano.stabellini@eu.citrix.com> In-Reply-To: <1317392440-4137-5-git-send-email-stefano.stabellini@eu.citrix.com> Content-Type: text/plain; charset="ISO-8859-1"; format=flowed Content-Transfer-Encoding: 7bit X-OriginatorOrg: amd.com Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>, "keir@xen.org" <keir@xen.org>, Campbell <ian.campbell@citrix.com>, "Ian.Jackson@eu.citrix.com" <Ian.Jackson@eu.citrix.com>, "Ian.Campbell@eu.citrix.com" <Ian.Campbell@eu.citrix.com>, Ian X-BeenThere: xen-devel@lists.xensource.com X-Mailman-Version: 2.1.5 Precedence: list List-Id: Xen developer discussion <xen-devel.lists.xensource.com> List-Unsubscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe> List-Post: <mailto:xen-devel@lists.xensource.com> List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help> List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=subscribe> Sender: xen-devel-bounces@lists.xensource.com Errors-To: xen-devel-bounces@lists.xensource.com On 09/30/11 16:20, stefano.stabellini@eu.citrix.com wrote: > From: Ian Campbell<ian.campbell@citrix.com> > > Signed-off-by: Ian Campbell<ian.campbell@citrix.com> Acked-by: Christoph Egger <Christoph.Egger@amd.com> > > diff -r 75f27929ad92 tools/libxl/libxl_dm.c > --- a/tools/libxl/libxl_dm.c Fri Sep 23 11:22:23 2011 +0000 > +++ b/tools/libxl/libxl_dm.c Fri Sep 23 11:22:39 2011 +0000 > @@ -55,7 +55,7 @@ const char *libxl__domain_device_model(l > dm = libxl__abs_path(gc, "qemu-dm", libxl_libexec_path()); > break; > case LIBXL_DEVICE_MODEL_VERSION_QEMU_XEN: > - dm = libxl__strdup(gc, "/usr/bin/qemu"); > + dm = libxl__abs_path(gc, "qemu", libxl_libexec_path()); > break; > default: > LIBXL__LOG(ctx, LIBXL__LOG_ERROR, > > _______________________________________________ > Xen-devel mailing list > Xen-devel@lists.xensource.com > http://lists.xensource.com/xen-devel > -- ---to satisfy European Law for business letters: Advanced Micro Devices GmbH Einsteinring 24, 85689 Dornach b. Muenchen Geschaeftsfuehrer: Alberto Bozzo, Andrew Bowd Sitz: Dornach, Gemeinde Aschheim, Landkreis Muenchen Registergericht Muenchen, HRB Nr. 43632 _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel From xen-api-bounces@lists.xensource.com Fri Sep 30 07:35:55 2011 Return-path: <xen-api-bounces@lists.xensource.com> Envelope-to: www-data@lists.xensource.com Delivery-date: Fri, 30 Sep 2011 07:35:55 -0700 Received: from localhost ([127.0.0.1] helo=lists.colo.xensource.com) by lists.xensource.com with esmtp (Exim 4.43) id 1R9eBu-0003Du-Tn; Fri, 30 Sep 2011 07:35:54 -0700 Received: from mail182.messagelabs.com ([85.158.139.83]) by lists.xensource.com with esmtp (Exim 4.43) id 1R9e79-0000Nd-F2; Fri, 30 Sep 2011 07:30:59 -0700 X-Env-Sender: lars.kurth.xen@gmail.com X-Msg-Ref: server-5.tower-182.messagelabs.com!1317393055!15411669!1 X-Originating-IP: [74.125.82.171] X-StarScan-Version: 6.4.1; banners=-,-,- X-VirusChecked: Checked Received: (qmail 18887 invoked from network); 30 Sep 2011 14:30:55 -0000 Received: from mail-wy0-f171.google.com (HELO mail-wy0-f171.google.com) (74.125.82.171) by server-5.tower-182.messagelabs.com with RC4-SHA encrypted SMTP; 30 Sep 2011 14:30:55 -0000 Received: by wyh13 with SMTP id 13so1451051wyh.30 for <multiple recipients>; Fri, 30 Sep 2011 07:30:55 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=sender:message-id:date:from:user-agent:mime-version:cc:subject :references:in-reply-to:content-type; bh=H1UHt2yVIkc62J4GzxTUQbPXfKMCXNynb0GtQ5JNQCo=; b=vRJxR46rxZon+QOD5JMoHmD9+F3cZG70yMymCSJ8sLKVCu6YV/iOTzmKdIFe1US3OA bXJFmfAdYyJyl5aQZJVE7C+Df7/Jta123kzQlSem4Fso0AhjySuxooIXYtc8y6MmZMDK QoifnRAAuPR+llYaVctMAfisncWsQ+CPSHEzc= Received: by 10.216.166.70 with SMTP id f48mr3373747wel.38.1317393055484; Fri, 30 Sep 2011 07:30:55 -0700 (PDT) Received: from [172.16.25.10] (02d933ea.bb.sky.com. [2.217.51.234]) by mx.google.com with ESMTPS id fd4sm9377207wbb.21.2011.09.30.07.30.54 (version=SSLv3 cipher=OTHER); Fri, 30 Sep 2011 07:30:54 -0700 (PDT) Message-ID: <4E85D29C.5000208@xen.org> Date: Fri, 30 Sep 2011 15:30:52 +0100 From: Lars Kurth <lars.kurth@xen.org> User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:7.0) Gecko/20110922 Thunderbird/7.0 MIME-Version: 1.0 Subject: Re: [Xen-API] Re: [Xen-devel] Please welcome Jan Beulich as Xen committer & revisions to Xen governance References: <4E85A513.6030403@xen.org> <20110930141111.GB18905@phenom.oracle.com> <CAOzFzEgOyS7im=2pBG18PgeAWSPh9pMu5TFWZARz37t0yGneeg@mail.gmail.com> In-Reply-To: <CAOzFzEgOyS7im=2pBG18PgeAWSPh9pMu5TFWZARz37t0yGneeg@mail.gmail.com> Cc: xen-arm@lists.xensource.com, "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>, "xen-api@lists.xensource.com" <xen-api@lists.xensource.com> X-BeenThere: xen-api@lists.xensource.com X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussion of API issues surrounding Xen <xen-api.lists.xensource.com> List-Unsubscribe: <http://lists.xensource.com/mailman/listinfo/xen-api>, <mailto:xen-api-request@lists.xensource.com?subject=unsubscribe> List-Post: <mailto:xen-api@lists.xensource.com> List-Help: <mailto:xen-api-request@lists.xensource.com?subject=help> List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-api>, <mailto:xen-api-request@lists.xensource.com?subject=subscribe> Content-Type: multipart/mixed; boundary="===============2011740984==" Sender: xen-api-bounces@lists.xensource.com Errors-To: xen-api-bounces@lists.xensource.com This is a multi-part message in MIME format. --===============2011740984== Content-Type: multipart/alternative; boundary="------------090708060609060203030104" This is a multi-part message in MIME format. --------------090708060609060203030104 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit On 30/09/2011 15:15, Joseph Glanville wrote: > On 1 October 2011 00:11, Konrad Rzeszutek Wilk <konrad.wilk@oracle.com > <mailto:konrad.wilk@oracle.com>> wrote: > > > > Jan's Contribution > > ================== > > Jan has made a tremendous contribution to the project over the years > > and was was one of the top 3 contributors to the project for several > > years. Just to quote a few stats > > - 2009 : 107 patches changing 11746 lines of code > > - 2010 : 147 patches changing 7613 lines of code > > - 2011 : 204 patches changing 2655 lines of code > > > Actually, slight correction due to Jan using two different e-mail addresses in 2011 which I didn't notice and a couple of typo's (sorry my fault). So the 2011 stats should be 2011: 124+6=130 patches changing 26555+822=27377 lines of code Regards Lars --------------090708060609060203030104 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit <html> <head> <meta content="text/html; charset=ISO-8859-1" http-equiv="Content-Type"> </head> <body bgcolor="#FFFFFF" text="#000000"> On 30/09/2011 15:15, Joseph Glanville wrote:<br> <blockquote cite="mid:CAOzFzEgOyS7im=2pBG18PgeAWSPh9pMu5TFWZARz37t0yGneeg@mail.gmail.com" type="cite"> <div class="gmail_quote">On 1 October 2011 00:11, Konrad Rzeszutek Wilk <span dir="ltr"><<a moz-do-not-send="true" href="mailto:konrad.wilk@oracle.com">konrad.wilk@oracle.com</a>></span> wrote:<br> <blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;"> <div class="im"><br> > Jan's Contribution<br> > ==================<br> > Jan has made a tremendous contribution to the project over the years<br> > and was was one of the top 3 contributors to the project for several<br> > years. Just to quote a few stats<br> > - 2009 : 107 patches changing 11746 lines of code<br> > - 2010 : 147 patches changing 7613 lines of code<br> > - 2011 : 204 patches changing 2655 lines of code<br> ><br> </div> </blockquote> </div> </blockquote> Actually, slight correction due to Jan using two different e-mail addresses in 2011 which I didn't notice and a couple of typo's (sorry my fault). So the 2011 stats should be<br> <br> 2011: 124+6=130 patches changing 26555+822=27377 lines of code<br> <br> Regards<br> Lars <br> </body> </html> --------------090708060609060203030104-- --===============2011740984== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ xen-api mailing list xen-api@lists.xensource.com http://lists.xensource.com/mailman/listinfo/xen-api --===============2011740984==-- From xen-devel-bounces@lists.xensource.com Fri Sep 30 07:37:14 2011 Return-path: <xen-devel-bounces@lists.xensource.com> Envelope-to: www-data@lists.xensource.com Delivery-date: Fri, 30 Sep 2011 07:37:14 -0700 Received: from localhost ([127.0.0.1] helo=lists.colo.xensource.com) by lists.xensource.com with esmtp (Exim 4.43) id 1R9eDC-0003tI-H7; Fri, 30 Sep 2011 07:37:14 -0700 Received: from mail27.messagelabs.com ([193.109.254.147]) by lists.xensource.com with esmtp (Exim 4.43) id 1R9eBB-0002lI-Tm for xen-devel@lists.xensource.com; Fri, 30 Sep 2011 07:35:10 -0700 X-Env-Sender: davidxu06@gmail.com X-Msg-Ref: server-7.tower-27.messagelabs.com!1317393281!50817148!1 X-Originating-IP: [209.85.218.43] X-StarScan-Version: 6.4.1; banners=-,-,- X-VirusChecked: Checked Received: (qmail 10012 invoked from network); 30 Sep 2011 14:34:42 -0000 Received: from mail-yi0-f43.google.com (HELO mail-yi0-f43.google.com) (209.85.218.43) by server-7.tower-27.messagelabs.com with RC4-SHA encrypted SMTP; 30 Sep 2011 14:34:42 -0000 Received: by yib17 with SMTP id 17so2785088yib.30 for <xen-devel@lists.xensource.com>; Fri, 30 Sep 2011 07:35:05 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=gJbWUuvnqc3pTy7Uzv2BtoO99Yol2hEEa0KIC8sYCnc=; b=mKIZihxd67owb41KjEWivbeai3yw4shXVtd4TBHUcLADlPg0O51WVUBaWqn0FOy7uE AxuKtP+GOh6okUAmVNACG6ioeBXGRFHdsuwofWP706KyHKD0DBCBoZqQaPWsvsYIlACK eP6f4/RZFoQ6pe2t4VgTlqYWcdpaBpPrvdy/k= MIME-Version: 1.0 Received: by 10.150.22.40 with SMTP id 40mr11503986ybv.395.1317393305647; Fri, 30 Sep 2011 07:35:05 -0700 (PDT) Received: by 10.150.157.13 with HTTP; Fri, 30 Sep 2011 07:35:05 -0700 (PDT) In-Reply-To: <1317392546.26672.287.camel@zakaz.uk.xensource.com> References: <CAGjowiSLv2Wa9KgfVBmi9yZ5OBPvbX9NYb+3BaDg=iVbty-kuA@mail.gmail.com> <1317368165.26672.200.camel@zakaz.uk.xensource.com> <CAGjowiSbzeBDRAJOM0dKiq4K76jEaKYhVwn2wTysUSa4PHpDDA@mail.gmail.com> <1317392546.26672.287.camel@zakaz.uk.xensource.com> Date: Fri, 30 Sep 2011 05:35:05 -0900 Message-ID: <CAGjowiSkgYEd1YAh3065=b-vGY5wsjKFMAtZx5EuoTQkMWATtw@mail.gmail.com> Subject: Re: [Xen-devel] use hypercall in Dom0's kernel From: David Xu <davidxu06@gmail.com> To: Ian Campbell <Ian.Campbell@eu.citrix.com> Content-Type: text/plain; charset=ISO-8859-1 Cc: xen-devel <xen-devel@lists.xensource.com> X-BeenThere: xen-devel@lists.xensource.com X-Mailman-Version: 2.1.5 Precedence: list List-Id: Xen developer discussion <xen-devel.lists.xensource.com> List-Unsubscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe> List-Post: <mailto:xen-devel@lists.xensource.com> List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help> List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=subscribe> Sender: xen-devel-bounces@lists.xensource.com Errors-To: xen-devel-bounces@lists.xensource.com 2011/9/30 Ian Campbell <Ian.Campbell@eu.citrix.com>: > Please don't top post and always CC the list. I've put xen-devel back > this time. Sorry for that. I cc the list this time. :) > On Fri, 2011-09-30 at 15:14 +0100, David Xu wrote: >> Hi, >> >> I modify the bridge module of Dom0 and sniff the packets which go >> through Dom0. I want to notify the hypervisor if some special packets >> come. So I want to call some interface function which are defined in >> libxc (libxenctrl). But if I include the xenctrl.h or some related >> head file in the br.c or br_input.c which are parts of bridge module >> codes, I will encounter the compiling error (can not find the head >> file). > > Of course you cannot link userspace code into the kernel. > > If you need access to hypercalls then you have them available in the > kernel in raw form in the kernel. > So how can I call hypercall in raw form? I am not familiar with that. I changed the xen scheduler and add some other parameters and interface to xen credit scheduler. I want to switch the scheduling policy for some specific scenario. Currently I modified the libxc and xm command, so I can use xm command to change the parameters of scheduler and switch the policy. But I want to make it on demand, so I need communicate with scheduler in the Dom0 kernel module which sniffs and analyzes the packets. Thanks. Regards, Cong _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel From xen-devel-bounces@lists.xensource.com Fri Sep 30 07:40:39 2011 Return-path: <xen-devel-bounces@lists.xensource.com> Envelope-to: www-data@lists.xensource.com Delivery-date: Fri, 30 Sep 2011 07:40:39 -0700 Received: from localhost ([127.0.0.1] helo=lists.colo.xensource.com) by lists.xensource.com with esmtp (Exim 4.43) id 1R9eGV-0004LG-J3; Fri, 30 Sep 2011 07:40:39 -0700 Received: from mail216.messagelabs.com ([85.158.143.99]) by lists.xensource.com with smtp (Exim 4.43) id 1R9eG8-00048J-Em for xen-devel@lists.xensource.com; Fri, 30 Sep 2011 07:40:16 -0700 X-Env-Sender: dgdegra@tycho.nsa.gov X-Msg-Ref: server-12.tower-216.messagelabs.com!1317393612!14413908!1 X-Originating-IP: [63.239.65.40] X-StarScan-Version: 6.4.1; banners=-,-,- X-VirusChecked: Checked Received: (qmail 31290 invoked from network); 30 Sep 2011 14:40:13 -0000 Received: from msux-gh1-uea02.nsa.gov (HELO msux-gh1-uea02.nsa.gov) (63.239.65.40) by server-12.tower-216.messagelabs.com with SMTP; 30 Sep 2011 14:40:13 -0000 Received: from tarius.tycho.ncsc.mil (localhost [127.0.0.1]) by msux-gh1-uea02.nsa.gov (8.12.10/8.12.10) with ESMTP id p8UEe0C4014717; Fri, 30 Sep 2011 14:40:00 GMT Received: from moss-nexus.epoch.ncsc.mil (moss-nexus [144.51.25.48]) by tarius.tycho.ncsc.mil (8.13.1/8.13.1) with ESMTP id p8UEdxs7019479; Fri, 30 Sep 2011 10:40:00 -0400 Message-ID: <4E85D4CB.80009@tycho.nsa.gov> Date: Fri, 30 Sep 2011 10:40:11 -0400 From: Daniel De Graaf <dgdegra@tycho.nsa.gov> Organization: National Security Agency User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:6.0.2) Gecko/20110906 Thunderbird/6.0.2 MIME-Version: 1.0 To: Vasiliy Tolstov <v.tolstov@ghs.l.google.com> Subject: Re: [Xen-devel] [PATCH v6 0/3] libxenvchan: interdomain communications library References: <1313764724-12683-1-git-send-email-dgdegra@tycho.nsa.gov> <1316729665-15004-1-git-send-email-dgdegra@tycho.nsa.gov> <CACaajQsMnXb9u1pTtB9jT5b6n2p6gFq_A8aQajAO4kmcpSwKdw@mail.gmail.com> <CACaajQtCMpWuqH8PGhwK-WGC=bXRiE1an+2sWcm2JaozK7BK=w@mail.gmail.com> In-Reply-To: <CACaajQtCMpWuqH8PGhwK-WGC=bXRiE1an+2sWcm2JaozK7BK=w@mail.gmail.com> X-Enigmail-Version: 1.3 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Cc: Ian.Campbell@eu.citrix.com, xen-devel@lists.xensource.com, Ian.Jackson@eu.citrix.com, konrad.wilk@oracle.com, Stefano.Stabellini@eu.citrix.com X-BeenThere: xen-devel@lists.xensource.com X-Mailman-Version: 2.1.5 Precedence: list List-Id: Xen developer discussion <xen-devel.lists.xensource.com> List-Unsubscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe> List-Post: <mailto:xen-devel@lists.xensource.com> List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help> List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=subscribe> Sender: xen-devel-bounces@lists.xensource.com Errors-To: xen-devel-bounces@lists.xensource.com On 09/30/2011 04:28 AM, Vasiliy Tolstov wrote: > 2011/9/30 Vasiliy Tolstov <v.tolstov@selfip.ru> > >> >> >> 2011/9/23 Daniel De Graaf <dgdegra@tycho.nsa.gov> >> >>> Changes since v5: >>> - Unify gntdev osdep interface >>> - Eliminate notify_result and revert mapping if notify ioctl fails >>> - Rename functions and structures to libxenvchan >>> - Use application-specified xenstore path for ring/event data >>> - Enforce maximum ring size of 2^20 bytes on client >>> - Change to LGPL 2.1 >>> >>> [PATCH 1/3] libxc: add xc_gnttab_map_grant_ref_notify >>> [PATCH 2/3] libxc: add xc_gntshr_* functions >>> [PATCH 3/3] libvchan: interdomain communications library >>> >>> >>> >> Hello. Sorry for bumping.. >> What version of xen kernel i need to use this library? Now i have 2.6.32.26 >> in many domUs. >> And what i need in dom0 for that, if i want to communicate via libxenvchan >> from domU to dom0? >> >> >> > And where i can find latest version of the patch? > This library depends on gntdev for the client and gntalloc for the server; these were merged in 2.6.39. The client can be used with 2.6.32.x kernels however it is not possible to detect when a peer crashes or exits without calling libxenvchan_close() on that kernel. This library does not require that either peer is dom0; it can be used for both domU-domU and domU-dom0 communication. The latest version of the patch can be found in the xen-devel archives. -- Daniel De Graaf National Security Agency _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel From xen-devel-bounces@lists.xensource.com Fri Sep 30 07:45:34 2011 Return-path: <xen-devel-bounces@lists.xensource.com> Envelope-to: www-data@lists.xensource.com Delivery-date: Fri, 30 Sep 2011 07:45:34 -0700 Received: from localhost ([127.0.0.1] helo=lists.colo.xensource.com) by lists.xensource.com with esmtp (Exim 4.43) id 1R9eLG-0004tf-66; Fri, 30 Sep 2011 07:45:34 -0700 Received: from mail174.messagelabs.com ([85.158.138.51]) by lists.xensource.com with esmtp (Exim 4.43) id 1R9eKE-0004eW-OH for xen-devel@lists.xensource.com; Fri, 30 Sep 2011 07:44:31 -0700 X-Env-Sender: Ian.Campbell@eu.citrix.com X-Msg-Ref: server-4.tower-174.messagelabs.com!1317393867!33411225!1 X-Originating-IP: [62.200.22.115] X-StarScan-Version: 6.4.1; banners=-,-,- X-VirusChecked: Checked Received: (qmail 15358 invoked from network); 30 Sep 2011 14:44:27 -0000 Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115) by server-4.tower-174.messagelabs.com with RC4-SHA encrypted SMTP; 30 Sep 2011 14:44:27 -0000 X-IronPort-AV: E=Sophos;i="4.68,467,1312156800"; d="scan'208";a="8155211" Received: from lonpmailmx01.citrite.net ([10.30.203.162]) by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5; 30 Sep 2011 14:44: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.137.0; Fri, 30 Sep 2011 15:44:27 +0100 Subject: Re: [Xen-devel] use hypercall in Dom0's kernel From: Ian Campbell <Ian.Campbell@eu.citrix.com> To: David Xu <davidxu06@gmail.com> Date: Fri, 30 Sep 2011 15:44:26 +0100 In-Reply-To: <CAGjowiSkgYEd1YAh3065=b-vGY5wsjKFMAtZx5EuoTQkMWATtw@mail.gmail.com> References: <CAGjowiSLv2Wa9KgfVBmi9yZ5OBPvbX9NYb+3BaDg=iVbty-kuA@mail.gmail.com> <1317368165.26672.200.camel@zakaz.uk.xensource.com> <CAGjowiSbzeBDRAJOM0dKiq4K76jEaKYhVwn2wTysUSa4PHpDDA@mail.gmail.com> <1317392546.26672.287.camel@zakaz.uk.xensource.com> <CAGjowiSkgYEd1YAh3065=b-vGY5wsjKFMAtZx5EuoTQkMWATtw@mail.gmail.com> Organization: Citrix Systems, Inc. Content-Type: text/plain; charset="UTF-8" X-Mailer: Evolution 3.0.3- Content-Transfer-Encoding: 7bit Message-ID: <1317393867.26672.291.camel@zakaz.uk.xensource.com> MIME-Version: 1.0 Cc: xen-devel <xen-devel@lists.xensource.com> X-BeenThere: xen-devel@lists.xensource.com X-Mailman-Version: 2.1.5 Precedence: list List-Id: Xen developer discussion <xen-devel.lists.xensource.com> List-Unsubscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe> List-Post: <mailto:xen-devel@lists.xensource.com> List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help> List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=subscribe> Sender: xen-devel-bounces@lists.xensource.com Errors-To: xen-devel-bounces@lists.xensource.com On Fri, 2011-09-30 at 15:35 +0100, David Xu wrote: > 2011/9/30 Ian Campbell <Ian.Campbell@eu.citrix.com>: > > Please don't top post and always CC the list. I've put xen-devel back > > this time. > > Sorry for that. I cc the list this time. :) > > > On Fri, 2011-09-30 at 15:14 +0100, David Xu wrote: > >> Hi, > >> > >> I modify the bridge module of Dom0 and sniff the packets which go > >> through Dom0. I want to notify the hypervisor if some special packets > >> come. So I want to call some interface function which are defined in > >> libxc (libxenctrl). But if I include the xenctrl.h or some related > >> head file in the br.c or br_input.c which are parts of bridge module > >> codes, I will encounter the compiling error (can not find the head > >> file). > > > > Of course you cannot link userspace code into the kernel. > > > > If you need access to hypercalls then you have them available in the > > kernel in raw form in the kernel. > > > > So how can I call hypercall in raw form? I am not familiar with that. There are various functions in the kernel to do so. It rather depends which hypercall you want to use, since they are generally subsystem interfaces. e.g. see drivers/xen/events.c for event channel related stuff. > I changed the xen scheduler and add some other parameters and > interface to xen credit scheduler. I want to switch the scheduling > policy for some specific scenario. Currently I modified the libxc and > xm command, so I can use xm command to change the parameters of > scheduler and switch the policy. But I want to make it on demand, so I > need communicate with scheduler in the Dom0 kernel module which sniffs > and analyzes the packets. Having the dom0 kernel be involved with setting hypervisor scheduling parameters doesn't seem right to me. The more normal way to do this would be to expose the necessary statistics to dom0 userspace and have a daemon which did the heavy lifting. Ian. _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel From xen-devel-bounces@lists.xensource.com Fri Sep 30 07:46:41 2011 Return-path: <xen-devel-bounces@lists.xensource.com> Envelope-to: www-data@lists.xensource.com Delivery-date: Fri, 30 Sep 2011 07:46:41 -0700 Received: from localhost ([127.0.0.1] helo=lists.colo.xensource.com) by lists.xensource.com with esmtp (Exim 4.43) id 1R9eML-0005KF-8g; Fri, 30 Sep 2011 07:46:41 -0700 Received: from mail21.messagelabs.com ([85.158.143.35]) by lists.xensource.com with esmtp (Exim 4.43) id 1R9eKf-0004gY-FZ for xen-devel@lists.xensource.com; Fri, 30 Sep 2011 07:44:57 -0700 X-Env-Sender: davidxu06@gmail.com X-Msg-Ref: server-8.tower-21.messagelabs.com!1317393876!61013625!1 X-Originating-IP: [209.85.213.171] X-StarScan-Version: 6.4.1; banners=-,-,- X-VirusChecked: Checked Received: (qmail 26882 invoked from network); 30 Sep 2011 14:44:37 -0000 Received: from mail-yx0-f171.google.com (HELO mail-yx0-f171.google.com) (209.85.213.171) by server-8.tower-21.messagelabs.com with RC4-SHA encrypted SMTP; 30 Sep 2011 14:44:37 -0000 Received: by yxt3 with SMTP id 3so2589865yxt.30 for <xen-devel@lists.xensource.com>; Fri, 30 Sep 2011 07:44:53 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=UzFtqqToQzySJ8xF7xDs9znmaYM4/mhuDO5Q3qB4r6M=; b=IO6tV5mLf6JP89+0nIKclvNBdyXtzO4Eo58DEg0OUjrTF7tyOuB/0GspbGugtw+EHu FZKkuwDG90vUUvfG9exXWc2Y+1Yc/go860w9iMZJBmcJMXUVA8HqpKVHmO3JFe+hwOv2 KwUVxm+cc0rQ77fyobL2aA1N7ZFpOZIcouxjg= MIME-Version: 1.0 Received: by 10.150.22.40 with SMTP id 40mr11516035ybv.395.1317393892987; Fri, 30 Sep 2011 07:44:52 -0700 (PDT) Received: by 10.150.157.13 with HTTP; Fri, 30 Sep 2011 07:44:52 -0700 (PDT) In-Reply-To: <1317393663.26672.288.camel@zakaz.uk.xensource.com> References: <CAGjowiTc0NAJbWR-RxwLTrz+bhbAFfvcPKPAB_F8r1ef6__PbA@mail.gmail.com> <1317368064.26672.198.camel@zakaz.uk.xensource.com> <CAGjowiQE_3gTJxK+Ja850QU9g1+97hZ8hAgdv_a4B18jxmCNGw@mail.gmail.com> <1317393663.26672.288.camel@zakaz.uk.xensource.com> Date: Fri, 30 Sep 2011 05:44:52 -0900 Message-ID: <CAGjowiSrPCY50-iBK67nGfOGdK7z1htc58ohtrqJtmutmRRQzQ@mail.gmail.com> Subject: Re: [Xen-devel] ring buffer overflow From: David Xu <davidxu06@gmail.com> To: Ian Campbell <Ian.Campbell@eu.citrix.com> Content-Type: text/plain; charset=ISO-8859-1 Cc: xen-devel <xen-devel@lists.xensource.com> X-BeenThere: xen-devel@lists.xensource.com X-Mailman-Version: 2.1.5 Precedence: list List-Id: Xen developer discussion <xen-devel.lists.xensource.com> List-Unsubscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe> List-Post: <mailto:xen-devel@lists.xensource.com> List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help> List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=subscribe> Sender: xen-devel-bounces@lists.xensource.com Errors-To: xen-devel-bounces@lists.xensource.com Hi, 2011/9/29 Ian Campbell <Ian.Campbell@citrix.com>: > On Fri, 2011-09-30 at 05:18 +0100, David Xu wrote: >> Hi, >> >> Does anybody know whether the ring buffer between front end and back >> end will suffer from overflow? I just wonder if the ring buffer will >> be full and drop some packets when the Net I/O load is very heavy. > > In the case of networking whichever end is putting stuff on the ring > checks that there is enough room and will stop the queue when it cannot > transmit any more and restart when room becomes available. You mean even there is not enough room in ring buffer, xen will * not drop the packets * and just delay the transmission. I used httperf to measure the performance of web server running in a VM (The workload in this VM is mixed, so it can not benefit from boost mechanism. The net i/o suffers from relatively high latency which depends on the number of VMs in the system). I found that with the increase of request rate in client side, the connection rate will drop and the connection time will increase dramatically. And the retransmission appears when the request rate is over than a quantum. So I doubted that the http/tcp connection suffer from the packets drop when the ring buffer is full because of high request rate. > >> BTW, If I want to change the size of i/o ring buffer, how should I do? >> I tried to reset the NET_TX_RING_SIZE and NET_RX_RING_SIZE in both >> front end and back end, but it seems doesn't work. Thanks. > > Currently the rings are limited to 1 page so if you want to increase the > size you would need to add multipage ring support to the network > protocol. There have been patches to do this for the blk protocol but I > do not recall any for the net protocol. Yes, increasing the size is relatively hard. So I just want reduce the size of ring buffer to make sure my doubt described above. I directly set NET_TX_RING_SIZE and NET_RX_RING_SIZE to 128, but it doesn't seem to work. Regards, Cong _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel From xen-devel-bounces@lists.xensource.com Fri Sep 30 07:56:58 2011 Return-path: <xen-devel-bounces@lists.xensource.com> Envelope-to: www-data@lists.xensource.com Delivery-date: Fri, 30 Sep 2011 07:56:58 -0700 Received: from localhost ([127.0.0.1] helo=lists.colo.xensource.com) by lists.xensource.com with esmtp (Exim 4.43) id 1R9eWH-0005xD-V5; Fri, 30 Sep 2011 07:56:58 -0700 Received: from mail27.messagelabs.com ([193.109.254.147]) by lists.xensource.com with esmtp (Exim 4.43) id 1R9eVP-0005iG-9Q for xen-devel@lists.xensource.com; Fri, 30 Sep 2011 07:56:03 -0700 X-Env-Sender: Ian.Campbell@eu.citrix.com X-Msg-Ref: server-11.tower-27.messagelabs.com!1317394550!39613806!1 X-Originating-IP: [62.200.22.115] X-StarScan-Version: 6.4.1; banners=-,-,- X-VirusChecked: Checked Received: (qmail 1416 invoked from network); 30 Sep 2011 14:55:50 -0000 Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115) by server-11.tower-27.messagelabs.com with RC4-SHA encrypted SMTP; 30 Sep 2011 14:55:50 -0000 X-IronPort-AV: E=Sophos;i="4.68,467,1312156800"; d="scan'208";a="8155519" Received: from lonpmailmx01.citrite.net ([10.30.203.162]) by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5; 30 Sep 2011 14:55:59 +0000 Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net (10.30.203.162) with Microsoft SMTP Server id 8.3.137.0; Fri, 30 Sep 2011 15:55:59 +0100 Subject: Re: [Xen-devel] ring buffer overflow From: Ian Campbell <Ian.Campbell@eu.citrix.com> To: David Xu <davidxu06@gmail.com> Date: Fri, 30 Sep 2011 15:55:59 +0100 In-Reply-To: <CAGjowiSrPCY50-iBK67nGfOGdK7z1htc58ohtrqJtmutmRRQzQ@mail.gmail.com> References: <CAGjowiTc0NAJbWR-RxwLTrz+bhbAFfvcPKPAB_F8r1ef6__PbA@mail.gmail.com> <1317368064.26672.198.camel@zakaz.uk.xensource.com> <CAGjowiQE_3gTJxK+Ja850QU9g1+97hZ8hAgdv_a4B18jxmCNGw@mail.gmail.com> <1317393663.26672.288.camel@zakaz.uk.xensource.com> <CAGjowiSrPCY50-iBK67nGfOGdK7z1htc58ohtrqJtmutmRRQzQ@mail.gmail.com> Organization: Citrix Systems, Inc. Content-Type: text/plain; charset="UTF-8" X-Mailer: Evolution 3.0.3- Content-Transfer-Encoding: 7bit Message-ID: <1317394559.26672.293.camel@zakaz.uk.xensource.com> MIME-Version: 1.0 Cc: xen-devel <xen-devel@lists.xensource.com> X-BeenThere: xen-devel@lists.xensource.com X-Mailman-Version: 2.1.5 Precedence: list List-Id: Xen developer discussion <xen-devel.lists.xensource.com> List-Unsubscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe> List-Post: <mailto:xen-devel@lists.xensource.com> List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help> List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=subscribe> Sender: xen-devel-bounces@lists.xensource.com Errors-To: xen-devel-bounces@lists.xensource.com On Fri, 2011-09-30 at 15:44 +0100, David Xu wrote: > Hi, > > 2011/9/29 Ian Campbell <Ian.Campbell@citrix.com>: > > On Fri, 2011-09-30 at 05:18 +0100, David Xu wrote: > >> Hi, > >> > >> Does anybody know whether the ring buffer between front end and back > >> end will suffer from overflow? I just wonder if the ring buffer will > >> be full and drop some packets when the Net I/O load is very heavy. > > > > In the case of networking whichever end is putting stuff on the ring > > checks that there is enough room and will stop the queue when it cannot > > transmit any more and restart when room becomes available. > > You mean even there is not enough room in ring buffer, xen will * not > drop the packets * and just delay the transmission. It's not Xen but rather the kernel back and front ends which is involved here. You can examine the hard_start_xmit functions in both netback and netfront to determine for yourself whether or not packets can be dropped and when. > I used httperf to > measure the performance of web server running in a VM (The workload in > this VM is mixed, so it can not benefit from boost mechanism. The net > i/o suffers from relatively high latency which depends on the number > of VMs in the system). I found that with the increase of request rate > in client side, the connection rate will drop and the connection time > will increase dramatically. And the retransmission appears when the > request rate is over than a quantum. So I doubted that the http/tcp > connection suffer from the packets drop when the ring buffer is full > because of high request rate. > > > > >> BTW, If I want to change the size of i/o ring buffer, how should I do? > >> I tried to reset the NET_TX_RING_SIZE and NET_RX_RING_SIZE in both > >> front end and back end, but it seems doesn't work. Thanks. > > > > Currently the rings are limited to 1 page so if you want to increase the > > size you would need to add multipage ring support to the network > > protocol. There have been patches to do this for the blk protocol but I > > do not recall any for the net protocol. > > Yes, increasing the size is relatively hard. So I just want reduce the > size of ring buffer to make sure my doubt described above. I directly > set NET_TX_RING_SIZE and NET_RX_RING_SIZE to 128, but it doesn't seem to work. You need to make sure both ends of the connection agree on the ring size. I'm afraid this is not a very common thing to want to do so if you want to persist with this approach I'm afraid you'll have to do some debugging. Ian. _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel From xen-devel-bounces@lists.xensource.com Fri Sep 30 08:09:03 2011 Return-path: <xen-devel-bounces@lists.xensource.com> Envelope-to: www-data@lists.xensource.com Delivery-date: Fri, 30 Sep 2011 08:09:03 -0700 Received: from localhost ([127.0.0.1] helo=lists.colo.xensource.com) by lists.xensource.com with esmtp (Exim 4.43) id 1R9ehx-0006lI-1H; Fri, 30 Sep 2011 08:09:01 -0700 Received: from mail174.messagelabs.com ([85.158.138.51]) by lists.xensource.com with smtp (Exim 4.43) id 1R9egO-0006YF-BU for xen-devel@lists.xensource.com; Fri, 30 Sep 2011 08:07:32 -0700 X-Env-Sender: anthony@overnetdata.com X-Msg-Ref: server-15.tower-174.messagelabs.com!1317395240!27052780!1 X-Originating-IP: [81.137.131.225] X-StarScan-Version: 6.4.1; banners=-,-,- X-VirusChecked: Checked Received: (qmail 19549 invoked from network); 30 Sep 2011 15:07:20 -0000 Received: from host81-137-131-225.in-addr.btopenworld.com (HELO zimbra.overnetdata.com) (81.137.131.225) by server-15.tower-174.messagelabs.com with SMTP; 30 Sep 2011 15:07:20 -0000 Received: from localhost (localhost.localdomain [127.0.0.1]) by zimbra.overnetdata.com (Postfix) with ESMTP id 6D2C91617A8 for <xen-devel@lists.xensource.com>; Fri, 30 Sep 2011 16:07:20 +0100 (BST) X-Virus-Scanned: amavisd-new at overnetdata.com Received: from zimbra.overnetdata.com ([127.0.0.1]) by localhost (zimbra.overnetdata.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ApO+T758Pi6c for <xen-devel@lists.xensource.com>; Fri, 30 Sep 2011 16:07:11 +0100 (BST) Received: from [192.168.1.60] (unknown [192.168.1.60]) by zimbra.overnetdata.com (Postfix) with ESMTPSA id B1D9B1616BE for <xen-devel@lists.xensource.com>; Fri, 30 Sep 2011 16:07:11 +0100 (BST) Message-ID: <4E85DB1A.5060606@overnetdata.com> Date: Fri, 30 Sep 2011 16:07:06 +0100 From: Anthony Wright <anthony@overnetdata.com> User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:6.0.2) Gecko/20110902 Thunderbird/6.0.2 MIME-Version: 1.0 To: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com> X-Enigmail-Version: 1.3.2 Content-Type: multipart/mixed; boundary="------------030503060601060101090300" Subject: [Xen-devel] Memory allocation going seriously wonky on 4.1.1 X-BeenThere: xen-devel@lists.xensource.com X-Mailman-Version: 2.1.5 Precedence: list List-Id: Xen developer discussion <xen-devel.lists.xensource.com> List-Unsubscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe> List-Post: <mailto:xen-devel@lists.xensource.com> List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help> List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=subscribe> Sender: xen-devel-bounces@lists.xensource.com Errors-To: xen-devel-bounces@lists.xensource.com This is a multi-part message in MIME format. --------------030503060601060101090300 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit I have a machine with 16GB of RAM running 32 bit xen 4.1.1 with Dom0 running a 3.0.4 linux kernel and 23 paravirtualized DomUs. As the free ram gets to 2391 MB free the system behaves as if it's got no more ram, and starts grabbing ram from Dom0, before getting even more confused and failing to start DomUs and eventually crashing the whole machine. I have attached a tarball with the output of xl dmesg, xl info & xl list at various points. Stage 1 Everything is fine, Dom0 has 2000MB according to xl list, and 'xl info' says there is 2405MB free. Stage 2 I have increased the memory for the DomU labelled 10-4 from 700MB to 1000MB, Dom0 has 1713MB and 'xl info' says there is 2391MB free. Stage 3 I have tried to increase the memory for the DomU labelled 13-4 from 700MB to 1000MB, but it failed on the 'xl create' displaying the message 'failed to free memory for the domain'. Dom0 has 1413MB and 'xl info' says there is 3391MB free. State 4 I tried to create the 13-4 DomU again, and this time it succeeds. Dom0 has 1413MB and 'xl info' says there is 2391MB free. If I repeatedly stop and start DomUs at this point, particularly if I request more ram, the machine locks up. This may be due to lack of Dom0 ram. --------------030503060601060101090300 Content-Type: application/octet-stream; name="vm-memory-logs.tar.bz2" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="vm-memory-logs.tar.bz2" QlpoOTFBWSZTWZFK8qoAP7//x//8gEJv9//7f+//7v////QIAAAA0AggAAAIYB2/AByAKAAA AAAAEgAAAAAAAAAAAAAAAAAAAAAAAAAAAcAA0GhoNABpkGhkDTQAAGQAZAZAA4ABoNDQaADT INDIGmgAAMgAyAyAA1U/JkyVDEAAAAAAAAAAAAAAADgAGg0NBoANMg0MgaaAAAyADIDIAHAA NBoaDQAaZBoZA00AABkAGQGQACqIQJoBNACZNCYQ0amAh6AmVPamyRtDJpPJpT9UPFHqfjAz j+BHZDtI8ULXQP9ikRKJwhEEd9CIXkeH1HkpXJ5PHS+t91rvcHWWH2HEMiMIUQi0NFdHmX0m 7O6udMFKUmnNWtal5riYEwNJMCYREiFBrhJCsCIiSYEJISISTA1EkURCEogk/+hEhQiISESR IkiYRIkSQ/I/kexs036zzn+AyPQfgfaf+j4z8j2htJEMDSSfcdxcVLi4of0OgqN5Y90wNxiQ i8kH1nIWOssXl5Q9B4S8uOIwLypYsSOw7ShChkWLipERJQvLihsKGRcXCp6D4jpydebNEJtP CxnK0YQNaNTCRN3BnJkCKIiTyEDRhJopJ0Ug4aEhJYs0kSCsxQUIHi0Ec7ACYJwBAdASbjEa s4jIk1EaB+RJ65Y6TlKGwuMzSWJFiSI8UCUQRB9xJDadR2FREf+YEoQEP3l5cPEaA4JmUTEy mYiZTMTKZhzFEQpMzEzpERt3BExQg4RtLhQZkRGJjtERjJ4i4oiI4jIH2EnfPAeEwLGskP6m I7j95ecD/4cxiUMCSpynGcRmZlwkjeSf4MihJoPQbDI5TrRQmSJLyoqO0sRQkkOqIEbjt6cr 6WrSpWO2eDu5RmRcyIiIOkWDxRnd1Vg7ojPB3fO6cZums0lMzD9xxjSSYkWJJEkSSaogR3EG 075/2VLEiG7XpmlEtsa7WrsjARGZSkRGJ0EkKFihFCRsJHkJI1nuFxuGwoOc0FCpJCOgaCRE UiIiHKWPIe8SazYdJzj3ihoNxyGJyn1GRzFChJ9ZY6yw6yo6T3yhY8xvPKeYksLEkbCSRYqJ KkSWPiKnMDA8BQ6BJ3EjtO0yIuPsPQe2cx75kLyhQkSSSSSSSSSSSSSSSO4+kId8d4+o7RiZ jEKkqkfoN5+Z7ZdQwOkxMR4SS+ERH8SHtkbDzAahek4FIZlxoKn9j0mJFYQkiTmhwOs2ngPZ HqixcVKnjPZLi44REbTznOaip4xEPwKjsHQawPtLhcXmRQ0FR5yhmVOg7595959p2HOdhQ9B JUkXEmBIjkOM2HhNBQ1CxsKEnIUOU/iULFxQSXlCJF5IWHMWOA5iS49J4BkXli8zDvEkd4kV JGZJ75eYESXFC4uKkkbCw5DyF4qQzGB8hUsfAdZoMzyDwmk4zE/MvHEMzE1l5J9xQWIFTlOg 7j1T4TMbiTcSDsKmg0ChwKDSWLyShvMypvLHeKl5U1HWbSpcXEnAhJiJFRYofCSR5ySxYeke 0ekqPbLFCT/RQeubjqHA6Cp7Q0j0GwoVOkuMCwaDzlTvFj1zlPWLixGk/saTsFSTAvNJtO+Z G4xFDWeI7xUsZnpPlOM94yO0943knmNxmcpzG44DgO+cZoMzSbz/s9QoJNBcXF5zG8k0mk3D 5Deec9cZlTebhoOk6xvOQ2D2hzkjQZnKfAfcbzsLzIzMRmd47BY6QOUXHYLjA8B0DsO4uP1n jJEkjxlCg6hIiQjMmIgh8xIR5gREWLyoRHESI3nOaiwxJKESSPmEekkj1CTlJKEnmPSe+P1H SYG8zLzmHSfCEHzlChERBxEkOA90RUjaIh8prNY8Y2m8fOcDE92IiIaCIJRERCyEQ8MOByEf qMD2DM981GkqcpQvPSPIMz/JeWXE4mZmZlCptI+YwJJOBJH1HlO47x7p8R0HShENJF5C44iT vknswOSBqIoWPCSJEdJQ8JJrLGocR7g69HLt6um7rp1BTqtddSlMZmt+GgqdRjjgHWDOypE4 g5BBQMwmTFDFEgIABAESINTMyIyRCWQVQpxEHdkY4KCY1VIAYIGOBjATwJ4FDr16t20/Weco PGSWD1D2RYsNGjRorWtZrWtiNpFkwXG+hANUheSKC8oCMjxmJl9JceczMzlNJ7xeGkkLH8zQ dpJIfYLjqJPYJJNBEklCpIoSJKEkmRgSbC4hvIoXy6pVJRpmLy+EIgwERI1plEzEyShGJJEn /BYvKmBmbTvmIhhJAO+YmJ8BrKlxIXw7T1i88BJUoXDE1Ggqe0YHEVPdNpzj8fOXi8kk1CSh pKG4k2IguOQZlRQ+YkkkipcYEklBUIuhIjeJEkkJEkiSOIjeVItYkqUOMqJJKFpIqXElbyov itilxYkkjlGJMLqVKmWBeabhbyChWthIqMDQSUGBIf3OoaSpiNp+BQas4mciSSIjqRGuNZYq XlD2REesPrMSQf1KmBYazuKGRcEYH8iRUuOMqekwNMGgk9Y27P6mB78D1DnGsNRQ8JvPtHYf pJP0i+No17I6iNhsgsO2BuO0C4ui+DJJjR650l8XwsgvLFi0cRMcC4oVUGOgvLkWGMXihtKG RJF5ejq/AkI2wLjnMs2JiuhxGN5edJgYLsBzGkvLy+/jNxoGRxncd41m8k4EcDbvxqVHVEaB riIjrOUIx5CY4yxDpMjkLwLzaNBgXihIuLjkKkVjrObI75eYiI5TdSHfEgpHOUIGJIxMDjhY 6ip0HAsVMHAuKDSUNpXlN2swKFRznOLxgahlpjE0FKYEReU4FShefkXGRqNIRUkhFTMoO4sO dmdKCpnHQOIoSXb5rSYpSZvF5gcZiXnAxjIjUUjElzmo3G0ochUoLsChrLeU7xsLz0EkMCFB uLElsIqSZQOap0cgupEji3TQYGYd8vI8BJSMG7Mil9NJuhwKFCSkQjQaS89coUOBQyOwvOUs ZFY0CSgmOU3ChcSScDYaDk5RcYDgcBkWzLz0kZQuTugTGBkUMSSbEabGekxOIk4G0yOI2Quy z06YVzoZRFczDomZSzGJ0FCOBdDRrzrDQc5t2lSx4STQXkkmF1CpFsoWMaqGngVF4k3XVw3X EjlKHUS/GZTN8XlRoEm4mIbjSXsiWYoTcSJCNxCLhcUIoSQkNvQXl8DpI2tBUxPzOYDSRY15 U3GJvRvLNu8vKm80U51qX7zVERQjOTbauuL6XEZlKl9ihrndCtDAwLzQYmweIYc8zMzOJQyN RQ2mykxMj1z3DUSeAxN5zDQdhtMS4eIjTDiJOMScgyOBHEWFw3lDeiZQqOKNRQwNpf1ljQWP vHvH1HxnxkknnPSf+z5TWYnOfcfrOMYEmoqWPxOQwPxiw+cU8BcZGRvP7HymkkMj4ygewSLE lj7ShrLigP4m8wP0lj0H7hxGZ95yG06DM1mZyHA0H7TAuOYkdxznqnceM9UD2CgsesPEaT4x 3h7wR5TrO0SfUeY90uKCIUJPmPuFC8+g/oewfxEXGkkiDESYH5lCLiR4Cw9JkVNgsUI9JwOg k9woPmNB9hiaSo2EmBqJPXD0kkDiHfNRY5D4S83i81HKbDYSCNpsJLChU/kZCoSNpqKDQaRq LEnxHzGgyIQqUKEPYLz6SpUEg9YzPAcAjEazSVMB3jjHGPbBERYoJIdpIxOU/M5RpLiGkc58 JrIjrEnGQhJeJC8KC8kKHgI6hU6TYLCpBHqiRIkhqJNxHMJKnhLDMqRCFxJH7TWUKm4qekzM RGgkNZIhoJOYhiOs5Chylw+EIkjA1lw5BuKDMjYKknA9c5TQGseuUN5pN5UuHAUOojUPEVOw vIIiJI2jjLFhYRJgfeWPAXEknhOgoMDgNY6DE7SELFjnJLDcRcKFiIhsBG43l5cZGgMCKkR1 hEgcRQ2cRYuMzI0HUXBeLElDYaTA2kjIuJNRFjgXnQO8YDAzMzM75JUhkPwNRiMCTcScZJsJ IWKEm0qRHukkf9EkXGkwIoaTQZFC4iOIUJFxyEOkcRIjQN5QyKmkkyLHAuLGgiRDmIkcZJEN goCIihBcRY0Cp+ZIjpPqP2DuPAXCx1kj9JJ6xYoSfcfgbBYzPfI/mYGBIuJLixU/cd4+A2n5 EiwfAfOXkkn6iS4+4vFDgP2Fx/gsYn6yhkfsFCxqOM4g2nEc0DnMD2DE+k0m0VNRDUJJIjuK ihgZjI75kXmo+gvHvD8TjKniFwSf5GQcp8h0FDSXCgsYjWPISYF5iXCTSLjAhFRpJJJNReKG JGcDUeM7DMkWFDI2GJ5TtLyTymY906BQ6BcYkc5mSLypcfeSdCEQ6yOc4DIk+c/kXkVGIiEn USfwNhmSOc+cZj5z4jEf0JJJJPESUJKEi47DIJIuNJGgcZ2HmH0BuCxkReIOosYm4jrJKkXF iGok0iTQJH3Cp7JkXkbCRzkkZElRrFBQ6ihzEkSSRJIkSIsVJFCEbDlFCKmZqMTYRoC4ofGW KFi8/4ESMCTvDIhkaiwuP9GR2kXmgqZmRFDxmw2ihQwPyOUobDoNJgaDoO0dJ6hqJJLFxkVI aiSwyMzwDAchyFxkSXmBiYEiTUZip4CG0saiSSSx9pIwLFxJcSdJmUPrElxJgbi49UhYWESa RkQkiRpP2lCLENgwEnlLCx5zeLEwH0ERvJJB2AkvNY7iNhGB0DYby8uLC89sjE7xibhEMiG0 aDQOY0lipIipUkoOMhDlMySppMjUfIZmgYGYyO41jvjvHmHtFjpHqHKSahYkJKEjuOck7i8S cRcR7pgWJLzcXDUWOg7DMkSbxvKkeYWOIipENZgWPKeMLiSSTUJMBeWFIGg6iSTrNB6Sp1Gk vEioihcSP/BJGBcGs/QO47xY/udxie0Q75JEYEaS4scgk+U9w6TIkwOUZB75cRidpcayRU9U k85YKmRY7TEscZmbTAdIyHAkaCTIkkuEQkh4CNp5RxCReFjAeQkzO0sKmgoGk2lCRQcZrJKF RccR1FB6T6TxnmKFxtIkyGJ7JCR4STpIqQoeId86CxeNhEkkJLiKlRDgVJFCOkXGI6zjNZeZ FxFxJ85J1nMR9pF0DEbjUaTQOo6SYIqRFRQqbjwlxHcdY1mZGRiFDYRwGAVNcCSo4igsKmgV DGAoGBYoSSVJEFCSKkihUihIkkoSKDrFBD6CREnIbiMCRJFhJeYCSTSRQoBUSKiT3RJePoNJ 5SxqI9AoRxD/kzNIkhEmYjUUNJgWJOIi4k9QbAjynSXkkVEHiPIc4dRQ3i8jETAwKnAxFR4y HQRI9Y8JDUIRiSKFxJGsuNRigftHAqf5NIgxGIjAdpG+A3mSBkRJxHyFDAfvGwvGs5zzHQc5 GRYsSHGHKP5n5GIqLFxG4N53j6yhFjAi8oRQ5CNhFYGsaxBJtKFAyhQ9siIqSIki8ScY0DEo SXknIdJFDMjpJOQuOcUNxoNpGg1kNo2Gw2GAvEVI1j1iERvLyhqPlgf4gdI3HSeQZjSJIiHI ahIqRIcZqPbNBgQvgPEfkVKHA5zzGRYuOo5zkKklCShmdw2GIqKnhLG4vKCRYzOk7RSBYbDI koaSGJHiEnUO+SaSSppJMBHeJLFTSUN5GkRDAvLxkYiwgsQ9gkQaCTkMSgxNBqgaCppNBeXi MUCpcRkXGZCJLGRJUkcReXmBGZU9BJUxOoqR0EjIzMSMjSRYyJgeqSSYElxGAxIuMSwqXmoh caShcaCRxF5UZmgdxUyLjEqRiaCRGJcWDA0FBiYklxmIxMiTkNpzBcNR/AdR+g2j/RvI6zcM i4f3Gosbhxki81kbBeHEf6gVG8VGowIbxyGkhCSSOUj/f+/h+H/da1rX6a1m00vOMk0mRHES WI9J6SR+ojeXGwgsRU+wjcesSdZwEknkJhDoNpHSSf8jwHjNhEkkSf9FAkkoUKChISegoKHx lUQqESg//i7kinChISKV5VQ= --------------030503060601060101090300 Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel --------------030503060601060101090300-- From xen-devel-bounces@lists.xensource.com Fri Sep 30 08:28:44 2011 Return-path: <xen-devel-bounces@lists.xensource.com> Envelope-to: www-data@lists.xensource.com Delivery-date: Fri, 30 Sep 2011 08:28:44 -0700 Received: from localhost ([127.0.0.1] helo=lists.colo.xensource.com) by lists.xensource.com with esmtp (Exim 4.43) id 1R9f11-0007Nb-IP; Fri, 30 Sep 2011 08:28:43 -0700 Received: from mail21.messagelabs.com ([85.158.143.35]) by lists.xensource.com with smtp (Exim 4.43) id 1R9f0S-0007BX-Id for xen-devel@lists.xensource.com; Fri, 30 Sep 2011 08:28:08 -0700 X-Env-Sender: rostedt@goodmis.org X-Msg-Ref: server-13.tower-21.messagelabs.com!1317396478!50980812!1 X-Originating-IP: [71.74.56.122] X-StarScan-Version: 6.4.1; banners=-,-,- X-VirusChecked: Checked Received: (qmail 8672 invoked from network); 30 Sep 2011 15:27:59 -0000 Received: from hrndva-omtalb.mail.rr.com (HELO hrndva-omtalb.mail.rr.com) (71.74.56.122) by server-13.tower-21.messagelabs.com with SMTP; 30 Sep 2011 15:27:59 -0000 X-Authority-Analysis: v=1.1 cv=lfM0d0QHaVz67dfwwr9cyIw6NbaGR/pZhMD6XWNi0kk= c=1 sm=0 a=eMQ7hR_6lG4A:10 a=5SG0PmZfjMsA:10 a=Q9fys5e9bTEA:10 a=17wjrS5wAhQaEczCPkpxpQ==:17 a=tHz9FfFoAAAA:8 a=ZPDoGCN9hik-CNn8tYgA:9 a=PUjeQqilurYA:10 a=6O0IECtVFhoA:10 a=17wjrS5wAhQaEczCPkpxpQ==:117 X-Cloudmark-Score: 0 X-Originating-IP: 74.67.83.30 Received: from [74.67.83.30] ([74.67.83.30:53775] helo=[192.168.23.10]) by hrndva-oedge03.mail.rr.com (envelope-from <rostedt@goodmis.org>) (ecelerity 2.2.3.46 r()) with ESMTP id D8/53-12229-000E58E4; Fri, 30 Sep 2011 15:28:05 +0000 From: Steven Rostedt <rostedt@goodmis.org> To: Jeremy Fitzhardinge <jeremy@goop.org> Date: Fri, 30 Sep 2011 11:28:00 -0400 In-Reply-To: <4E854859.4020105@goop.org> References: <cover.1317338254.git.jeremy.fitzhardinge@citrix.com> <1317343975.4588.36.camel@gandalf.stny.rr.com> <4E854859.4020105@goop.org> Content-Type: text/plain; charset="ISO-8859-15" X-Mailer: Evolution 3.0.3- Content-Transfer-Encoding: 7bit Message-ID: <1317396484.4588.52.camel@gandalf.stny.rr.com> Mime-Version: 1.0 Cc: Jan, arch/x86 maintainers <x86@kernel.org>, Jeremy Fitzhardinge <jeremy.fitzhardinge@citrix.com>, Glauber <jang@linux.vnet.ibm.com>, Jason Baron <jbaron@redhat.com>, David Daney <david.daney@cavium.com>, Linux Kernel Mailing List <linux-kernel@vger.kernel.org>, Michael Ellerman <michael@ellerman.id.au>, Xen Devel <xen-devel@lists.xensource.com>, the, "David S. Miller" <davem@davemloft.net> Subject: [Xen-devel] Re: [PATCH RFC 0/8] jump-label: allow early jump_label_enable() X-BeenThere: xen-devel@lists.xensource.com X-Mailman-Version: 2.1.5 Precedence: list List-Id: Xen developer discussion <xen-devel.lists.xensource.com> List-Unsubscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe> List-Post: <mailto:xen-devel@lists.xensource.com> List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help> List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=subscribe> Sender: xen-devel-bounces@lists.xensource.com Errors-To: xen-devel-bounces@lists.xensource.com On Thu, 2011-09-29 at 21:40 -0700, Jeremy Fitzhardinge wrote: > On 09/29/2011 05:52 PM, Steven Rostedt wrote: > > On Thu, 2011-09-29 at 16:26 -0700, Jeremy Fitzhardinge wrote: > >> From: Jeremy Fitzhardinge <jeremy.fitzhardinge@citrix.com> > >> > >> One big question which arises is whether the _early() function is > >> necessary at all. All the stop_machine/mutex/etc stuff that > >> arch_jump_label_transform() ends up doing is redundant pre-SMP, but it > >> shouldn't hurt. Maybe we can just drop the _early function? It works > >> on x86, at least, because jump_label_enable() works, which uses the full > >> form. And dropping it would reduce this to a very much smaller series. > > It does slow down the boot process, which is not a good thing when > > everyone is pushing for the fastest restarts. > > Would it really though? stop_machine() doesn't do very much when there > are no other cpus. > > Not that I measured or anything, but there was no obvious big lag at boot. Just bringing up the point, but without measurements, its all hand waving. It may not be a big deal, and simpler code is always better if it doesn't harm anything else. > > > What we should probably do is have a global read_mostly variable called, > > smp_activated or something, then things that can be called before and > > after can read this variable to determine if it can skip certain > > protections. > > Could do that if it turns out to be a problem. > > > While we're at it, perhaps we could add a memory_initialized for things > > like tracers that want to trace early but need to wait till it can > > allocate buffers. If we had this flag, it could instead do an early > > memory init to create the buffers. > > That seems orthogonal to the jump_label changes. It is. But it's something that bugs me and this just reminded me of it ;) -- Steve _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel From xen-devel-bounces@lists.xensource.com Fri Sep 30 08:39:07 2011 Return-path: <xen-devel-bounces@lists.xensource.com> Envelope-to: www-data@lists.xensource.com Delivery-date: Fri, 30 Sep 2011 08:39:07 -0700 Received: from localhost ([127.0.0.1] helo=lists.colo.xensource.com) by lists.xensource.com with esmtp (Exim 4.43) id 1R9fB5-0008Ci-A6; Fri, 30 Sep 2011 08:39:07 -0700 Received: from mail216.messagelabs.com ([85.158.143.99]) by lists.xensource.com with smtp (Exim 4.43) id 1R9fAU-00080N-Gx for xen-devel@lists.xensource.com; Fri, 30 Sep 2011 08:38:30 -0700 X-Env-Sender: caker@theshore.net X-Msg-Ref: server-10.tower-216.messagelabs.com!1317397107!10401515!1 X-Originating-IP: [67.18.92.50] X-StarScan-Version: 6.4.1; banners=-,-,- X-VirusChecked: Checked Received: (qmail 646 invoked from network); 30 Sep 2011 15:38:27 -0000 Received: from ns.theshore.net (HELO www.theshore.net) (67.18.92.50) by server-10.tower-216.messagelabs.com with SMTP; 30 Sep 2011 15:38:27 -0000 Received: from beefcake.linlan (173-161-199-49-Philadelphia.hfc.comcastbusiness.net [173.161.199.49]) by www.theshore.net (8.13.6/8.9.1) with ESMTP id p8UFcNDJ000308; Fri, 30 Sep 2011 11:38:23 -0400 Message-ID: <4E85E26F.1030202@theshore.net> Date: Fri, 30 Sep 2011 11:38:23 -0400 From: "Christopher S. Aker" <caker@theshore.net> User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.6; en-US; rv:1.9.2.23) Gecko/20110920 Lightning/1.0b2 Thunderbird/3.1.15 MIME-Version: 1.0 To: David Vrabel <david.vrabel@citrix.com> Subject: Re: [Xen-devel] vmalloc_sync_all() patch problems? References: <4E832F1A.3030209@theshore.net> <4E83330A.3030509@citrix.com> <4E834519.3090300@theshore.net> <4E8353B1.9070007@citrix.com> In-Reply-To: <4E8353B1.9070007@citrix.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: xen devel <xen-devel@lists.xensource.com> X-BeenThere: xen-devel@lists.xensource.com X-Mailman-Version: 2.1.5 Precedence: list List-Id: Xen developer discussion <xen-devel.lists.xensource.com> List-Unsubscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe> List-Post: <mailto:xen-devel@lists.xensource.com> List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help> List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=subscribe> Sender: xen-devel-bounces@lists.xensource.com Errors-To: xen-devel-bounces@lists.xensource.com On 9/28/11 1:04 PM, David Vrabel wrote: > On 28/09/11 17:02, Christopher S. Aker wrote: >> I've restarted the tests to see if I can reproduce, but I'm certain that >> if it happened once, it'll happen again. I was able to reproduce it. > Instead of the vmalloc_sync_all() patch you could try this series instead. > > http://lists.xensource.com/archives/html/xen-devel/2011-09/msg01343.html I'll rebuild using this series and reset the tests. Will let you know! Thanks, -Chris _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel From xen-devel-bounces@lists.xensource.com Fri Sep 30 08:43:10 2011 Return-path: <xen-devel-bounces@lists.xensource.com> Envelope-to: www-data@lists.xensource.com Delivery-date: Fri, 30 Sep 2011 08:43:10 -0700 Received: from localhost ([127.0.0.1] helo=lists.colo.xensource.com) by lists.xensource.com with esmtp (Exim 4.43) id 1R9fF0-0000Ea-Sh; Fri, 30 Sep 2011 08:43:10 -0700 Received: from mail216.messagelabs.com ([85.158.143.99]) by lists.xensource.com with esmtp (Exim 4.43) id 1R9fEX-0008S7-NI for xen-devel@lists.xensource.com; Fri, 30 Sep 2011 08:42:42 -0700 X-Env-Sender: dev@zheng.li X-Msg-Ref: server-9.tower-216.messagelabs.com!1317397358!20182306!1 X-Originating-IP: [95.154.254.124] X-StarScan-Version: 6.4.1; banners=-,-,- X-VirusChecked: Checked Received: (qmail 25866 invoked from network); 30 Sep 2011 15:42:38 -0000 Received: from service.paris5.org (HELO service.paris5.org) (95.154.254.124) by server-9.tower-216.messagelabs.com with AES256-SHA encrypted SMTP; 30 Sep 2011 15:42:38 -0000 Received: by service.paris5.org with esmtpsa (TLS1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.72) id 1R9fEU-0003nv-FJ for xen-devel@lists.xensource.com; Fri, 30 Sep 2011 15:42:38 +0000 Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Message-Id: <patchbomb.1317397198@eta> User-Agent: Mercurial-patchbomb/1.8.3 Date: Fri, 30 Sep 2011 15:39:58 +0000 From: Zheng Li <dev@zheng.li> To: xen-devel@lists.xensource.com Subject: [Xen-devel] [PATCH 0 of 2] Invalid memory access in OCaml mmap library X-BeenThere: xen-devel@lists.xensource.com X-Mailman-Version: 2.1.5 Precedence: list List-Id: Xen developer discussion <xen-devel.lists.xensource.com> List-Unsubscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe> List-Post: <mailto:xen-devel@lists.xensource.com> List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help> List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=subscribe> Sender: xen-devel-bounces@lists.xensource.com Errors-To: xen-devel-bounces@lists.xensource.com Thanks Roberto Di Cosmo for reporting this issue. tools/ocaml/libs/mmap/mmap_stubs.c | 24 +++++++++--------------- tools/ocaml/libs/mmap/mmap_stubs.c | 34 +++++++++++++++++----------------- 2 files changed, 26 insertions(+), 32 deletions(-) _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel From xen-devel-bounces@lists.xensource.com Fri Sep 30 08:44:12 2011 Return-path: <xen-devel-bounces@lists.xensource.com> Envelope-to: www-data@lists.xensource.com Delivery-date: Fri, 30 Sep 2011 08:44:12 -0700 Received: from localhost ([127.0.0.1] helo=lists.colo.xensource.com) by lists.xensource.com with esmtp (Exim 4.43) id 1R9fG0-0000ef-LE; Fri, 30 Sep 2011 08:44:12 -0700 Received: from mail182.messagelabs.com ([85.158.139.83]) by lists.xensource.com with esmtp (Exim 4.43) id 1R9fEY-0008S8-6b for xen-devel@lists.xensource.com; Fri, 30 Sep 2011 08:42:42 -0700 X-Env-Sender: dev@zheng.li X-Msg-Ref: server-4.tower-182.messagelabs.com!1317397358!20395660!1 X-Originating-IP: [95.154.254.124] X-StarScan-Version: 6.4.1; banners=-,-,- X-VirusChecked: Checked Received: (qmail 10522 invoked from network); 30 Sep 2011 15:42:38 -0000 Received: from service.paris5.org (HELO service.paris5.org) (95.154.254.124) by server-4.tower-182.messagelabs.com with AES256-SHA encrypted SMTP; 30 Sep 2011 15:42:38 -0000 Received: by service.paris5.org with esmtpsa (TLS1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.72) id 1R9fEU-0003nv-M0 for xen-devel@lists.xensource.com; Fri, 30 Sep 2011 15:42:38 +0000 Content-Type: multipart/mixed; boundary="===============1784961829==" MIME-Version: 1.0 X-Mercurial-Node: c4bb6370a202e81564dd2f25848662cfa0a5b7ed Message-Id: <c4bb6370a202e81564dd.1317397200@eta> In-Reply-To: <patchbomb.1317397198@eta> References: <patchbomb.1317397198@eta> User-Agent: Mercurial-patchbomb/1.8.3 Date: Fri, 30 Sep 2011 15:40:00 +0000 From: Zheng Li <dev@zheng.li> To: xen-devel@lists.xensource.com Subject: [Xen-devel] [PATCH 2 of 2] Change GET_C_STRUCT to Intf_val to follow the common naming scheme of OCaml macro X-BeenThere: xen-devel@lists.xensource.com X-Mailman-Version: 2.1.5 Precedence: list List-Id: Xen developer discussion <xen-devel.lists.xensource.com> List-Unsubscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe> List-Post: <mailto:xen-devel@lists.xensource.com> List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help> List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=subscribe> Sender: xen-devel-bounces@lists.xensource.com Errors-To: xen-devel-bounces@lists.xensource.com --===============1784961829== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit ... and for better readabilities. Signed-off-by: Zheng Li <dev@zheng.li> tools/ocaml/libs/mmap/mmap_stubs.c | 34 +++++++++++++++++----------------- 1 files changed, 17 insertions(+), 17 deletions(-) ---- diff --git a/tools/ocaml/libs/mmap/mmap_stubs.c b/tools/ocaml/libs/mmap/mmap_stubs.c --- a/tools/ocaml/libs/mmap/mmap_stubs.c +++ b/tools/ocaml/libs/mmap/mmap_stubs.c @@ -28,7 +28,7 @@ #include <caml/fail.h> #include <caml/callback.h> -#define GET_C_STRUCT(a) ((struct mmap_interface *) a) +#define Intf_val(a) ((struct mmap_interface *) a) static int mmap_interface_init(struct mmap_interface *intf, int fd, int pflag, int mflag, @@ -61,27 +61,27 @@ CAMLprim value stub_mmap_init(value fd, result = caml_alloc(sizeof(struct mmap_interface), Abstract_tag); - if (mmap_interface_init(GET_C_STRUCT(result), Int_val(fd), + if (mmap_interface_init(Intf_val(result), Int_val(fd), c_pflag, c_mflag, Int_val(len), Int_val(offset))) caml_failwith("mmap"); CAMLreturn(result); } -CAMLprim value stub_mmap_final(value interface) +CAMLprim value stub_mmap_final(value intf) { - CAMLparam1(interface); + CAMLparam1(intf); - if (GET_C_STRUCT(interface)->addr != MAP_FAILED) - munmap(GET_C_STRUCT(interface)->addr, GET_C_STRUCT(interface)->len); - GET_C_STRUCT(interface)->addr = MAP_FAILED; + if (Intf_val(intf)->addr != MAP_FAILED) + munmap(Intf_val(intf)->addr, Intf_val(intf)->len); + Intf_val(intf)->addr = MAP_FAILED; CAMLreturn(Val_unit); } -CAMLprim value stub_mmap_read(value interface, value start, value len) +CAMLprim value stub_mmap_read(value intf, value start, value len) { - CAMLparam3(interface, start, len); + CAMLparam3(intf, start, len); CAMLlocal1(data); int c_start; int c_len; @@ -89,33 +89,33 @@ CAMLprim value stub_mmap_read(value inte c_start = Int_val(start); c_len = Int_val(len); - if (c_start > GET_C_STRUCT(interface)->len) + if (c_start > Intf_val(intf)->len) caml_invalid_argument("start invalid"); - if (c_start + c_len > GET_C_STRUCT(interface)->len) + if (c_start + c_len > Intf_val(intf)->len) caml_invalid_argument("len invalid"); data = caml_alloc_string(c_len); - memcpy((char *) data, GET_C_STRUCT(interface)->addr + c_start, c_len); + memcpy((char *) data, Intf_val(intf)->addr + c_start, c_len); CAMLreturn(data); } -CAMLprim value stub_mmap_write(value interface, value data, +CAMLprim value stub_mmap_write(value intf, value data, value start, value len) { - CAMLparam4(interface, data, start, len); + CAMLparam4(intf, data, start, len); int c_start; int c_len; c_start = Int_val(start); c_len = Int_val(len); - if (c_start > GET_C_STRUCT(interface)->len) + if (c_start > Intf_val(intf)->len) caml_invalid_argument("start invalid"); - if (c_start + c_len > GET_C_STRUCT(interface)->len) + if (c_start + c_len > Intf_val(intf)->len) caml_invalid_argument("len invalid"); - memcpy(GET_C_STRUCT(interface)->addr + c_start, (char *) data, c_len); + memcpy(Intf_val(intf)->addr + c_start, (char *) data, c_len); CAMLreturn(Val_unit); } --===============1784961829== Content-Type: text/x-patch; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=xen-unstable.hg-2.patch ... and for better readabilities. Signed-off-by: Zheng Li <dev@zheng.li> diff --git a/tools/ocaml/libs/mmap/mmap_stubs.c b/tools/ocaml/libs/mmap/mmap_stubs.c --- a/tools/ocaml/libs/mmap/mmap_stubs.c +++ b/tools/ocaml/libs/mmap/mmap_stubs.c @@ -28,7 +28,7 @@ #include <caml/fail.h> #include <caml/callback.h> -#define GET_C_STRUCT(a) ((struct mmap_interface *) a) +#define Intf_val(a) ((struct mmap_interface *) a) static int mmap_interface_init(struct mmap_interface *intf, int fd, int pflag, int mflag, @@ -61,27 +61,27 @@ CAMLprim value stub_mmap_init(value fd, result = caml_alloc(sizeof(struct mmap_interface), Abstract_tag); - if (mmap_interface_init(GET_C_STRUCT(result), Int_val(fd), + if (mmap_interface_init(Intf_val(result), Int_val(fd), c_pflag, c_mflag, Int_val(len), Int_val(offset))) caml_failwith("mmap"); CAMLreturn(result); } -CAMLprim value stub_mmap_final(value interface) +CAMLprim value stub_mmap_final(value intf) { - CAMLparam1(interface); + CAMLparam1(intf); - if (GET_C_STRUCT(interface)->addr != MAP_FAILED) - munmap(GET_C_STRUCT(interface)->addr, GET_C_STRUCT(interface)->len); - GET_C_STRUCT(interface)->addr = MAP_FAILED; + if (Intf_val(intf)->addr != MAP_FAILED) + munmap(Intf_val(intf)->addr, Intf_val(intf)->len); + Intf_val(intf)->addr = MAP_FAILED; CAMLreturn(Val_unit); } -CAMLprim value stub_mmap_read(value interface, value start, value len) +CAMLprim value stub_mmap_read(value intf, value start, value len) { - CAMLparam3(interface, start, len); + CAMLparam3(intf, start, len); CAMLlocal1(data); int c_start; int c_len; @@ -89,33 +89,33 @@ CAMLprim value stub_mmap_read(value inte c_start = Int_val(start); c_len = Int_val(len); - if (c_start > GET_C_STRUCT(interface)->len) + if (c_start > Intf_val(intf)->len) caml_invalid_argument("start invalid"); - if (c_start + c_len > GET_C_STRUCT(interface)->len) + if (c_start + c_len > Intf_val(intf)->len) caml_invalid_argument("len invalid"); data = caml_alloc_string(c_len); - memcpy((char *) data, GET_C_STRUCT(interface)->addr + c_start, c_len); + memcpy((char *) data, Intf_val(intf)->addr + c_start, c_len); CAMLreturn(data); } -CAMLprim value stub_mmap_write(value interface, value data, +CAMLprim value stub_mmap_write(value intf, value data, value start, value len) { - CAMLparam4(interface, data, start, len); + CAMLparam4(intf, data, start, len); int c_start; int c_len; c_start = Int_val(start); c_len = Int_val(len); - if (c_start > GET_C_STRUCT(interface)->len) + if (c_start > Intf_val(intf)->len) caml_invalid_argument("start invalid"); - if (c_start + c_len > GET_C_STRUCT(interface)->len) + if (c_start + c_len > Intf_val(intf)->len) caml_invalid_argument("len invalid"); - memcpy(GET_C_STRUCT(interface)->addr + c_start, (char *) data, c_len); + memcpy(Intf_val(intf)->addr + c_start, (char *) data, c_len); CAMLreturn(Val_unit); } --===============1784961829== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel --===============1784961829==-- From xen-devel-bounces@lists.xensource.com Fri Sep 30 08:45:32 2011 Return-path: <xen-devel-bounces@lists.xensource.com> Envelope-to: www-data@lists.xensource.com Delivery-date: Fri, 30 Sep 2011 08:45:32 -0700 Received: from localhost ([127.0.0.1] helo=lists.colo.xensource.com) by lists.xensource.com with esmtp (Exim 4.43) id 1R9fHI-00014s-QY; Fri, 30 Sep 2011 08:45:32 -0700 Received: from mail174.messagelabs.com ([85.158.138.51]) by lists.xensource.com with esmtp (Exim 4.43) id 1R9fEY-0008S9-DS for xen-devel@lists.xensource.com; Fri, 30 Sep 2011 08:42:42 -0700 X-Env-Sender: dev@zheng.li X-Msg-Ref: server-12.tower-174.messagelabs.com!1317397358!33395346!1 X-Originating-IP: [95.154.254.124] X-StarScan-Version: 6.4.1; banners=-,-,- X-VirusChecked: Checked Received: (qmail 19000 invoked from network); 30 Sep 2011 15:42:39 -0000 Received: from service.paris5.org (HELO service.paris5.org) (95.154.254.124) by server-12.tower-174.messagelabs.com with AES256-SHA encrypted SMTP; 30 Sep 2011 15:42:39 -0000 Received: by service.paris5.org with esmtpsa (TLS1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.72) id 1R9fEU-0003nv-IY for xen-devel@lists.xensource.com; Fri, 30 Sep 2011 15:42:38 +0000 Content-Type: multipart/mixed; boundary="===============0527095429==" MIME-Version: 1.0 X-Mercurial-Node: a980cfb2e4da7ce1780f2bb3498fd6e9f176ca64 Message-Id: <a980cfb2e4da7ce1780f.1317397199@eta> In-Reply-To: <patchbomb.1317397198@eta> References: <patchbomb.1317397198@eta> User-Agent: Mercurial-patchbomb/1.8.3 Date: Fri, 30 Sep 2011 15:39:59 +0000 From: Zheng Li <dev@zheng.li> To: xen-devel@lists.xensource.com Subject: [Xen-devel] [PATCH 1 of 2] Fix invalid memory access in OCaml mmap library (to play nicely with the GC) X-BeenThere: xen-devel@lists.xensource.com X-Mailman-Version: 2.1.5 Precedence: list List-Id: Xen developer discussion <xen-devel.lists.xensource.com> List-Unsubscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe> List-Post: <mailto:xen-devel@lists.xensource.com> List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help> List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=subscribe> Sender: xen-devel-bounces@lists.xensource.com Errors-To: xen-devel-bounces@lists.xensource.com --===============0527095429== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit This was a bug reported by Roberto Di Cosmo. When he tried to reuse the mmap library for his own project, Mmap.read occasionally got different result when reading from the same map. This turned out to be a bug in the binding, where a C pointer was created pointing to a OCaml value, and the OCaml value was subsequently moved around by the GC after memory allocation and hence invalidated the C pointer. This patch removes the indirection of C pointer and uses OCaml macro to access values directly. Only Mmap.read function had this problem. The other functions, despite having the same code style, didn't have memory allocation involved hence wouldn't intrigue such an error. I've changed all of them to the safer style for future proof. Directly casting OCaml value's *data block* (rather than the value itself) as a C pointer is not a common practice either, but I'll leave it as it is. The bug hadn't occured on XenServer because XenServer didn't make use of the Mmap.read function (except in one place for debugging). In XenServer, most mmap operations were going through another pair of separately implemented functions (Xs_ring.read/write). Signed-off-by: Zheng Li <dev@zheng.li> tools/ocaml/libs/mmap/mmap_stubs.c | 24 +++++++++--------------- 1 files changed, 9 insertions(+), 15 deletions(-) ---- diff --git a/tools/ocaml/libs/mmap/mmap_stubs.c b/tools/ocaml/libs/mmap/mmap_stubs.c --- a/tools/ocaml/libs/mmap/mmap_stubs.c +++ b/tools/ocaml/libs/mmap/mmap_stubs.c @@ -71,12 +71,10 @@ CAMLprim value stub_mmap_init(value fd, CAMLprim value stub_mmap_final(value interface) { CAMLparam1(interface); - struct mmap_interface *intf; - intf = GET_C_STRUCT(interface); - if (intf->addr != MAP_FAILED) - munmap(intf->addr, intf->len); - intf->addr = MAP_FAILED; + if (GET_C_STRUCT(interface)->addr != MAP_FAILED) + munmap(GET_C_STRUCT(interface)->addr, GET_C_STRUCT(interface)->len); + GET_C_STRUCT(interface)->addr = MAP_FAILED; CAMLreturn(Val_unit); } @@ -85,21 +83,19 @@ CAMLprim value stub_mmap_read(value inte { CAMLparam3(interface, start, len); CAMLlocal1(data); - struct mmap_interface *intf; int c_start; int c_len; c_start = Int_val(start); c_len = Int_val(len); - intf = GET_C_STRUCT(interface); - if (c_start > intf->len) + if (c_start > GET_C_STRUCT(interface)->len) caml_invalid_argument("start invalid"); - if (c_start + c_len > intf->len) + if (c_start + c_len > GET_C_STRUCT(interface)->len) caml_invalid_argument("len invalid"); data = caml_alloc_string(c_len); - memcpy((char *) data, intf->addr + c_start, c_len); + memcpy((char *) data, GET_C_STRUCT(interface)->addr + c_start, c_len); CAMLreturn(data); } @@ -108,20 +104,18 @@ CAMLprim value stub_mmap_write(value int value start, value len) { CAMLparam4(interface, data, start, len); - struct mmap_interface *intf; int c_start; int c_len; c_start = Int_val(start); c_len = Int_val(len); - intf = GET_C_STRUCT(interface); - if (c_start > intf->len) + if (c_start > GET_C_STRUCT(interface)->len) caml_invalid_argument("start invalid"); - if (c_start + c_len > intf->len) + if (c_start + c_len > GET_C_STRUCT(interface)->len) caml_invalid_argument("len invalid"); - memcpy(intf->addr + c_start, (char *) data, c_len); + memcpy(GET_C_STRUCT(interface)->addr + c_start, (char *) data, c_len); CAMLreturn(Val_unit); } --===============0527095429== Content-Type: text/x-patch; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=xen-unstable.hg-1.patch This was a bug reported by Roberto Di Cosmo. When he tried to reuse the mmap library for his own project, Mmap.read occasionally got different result when reading from the same map. This turned out to be a bug in the binding, where a C pointer was created pointing to a OCaml value, and the OCaml value was subsequently moved around by the GC after memory allocation and hence invalidated the C pointer. This patch removes the indirection of C pointer and uses OCaml macro to access values directly. Only Mmap.read function had this problem. The other functions, despite having the same code style, didn't have memory allocation involved hence wouldn't intrigue such an error. I've changed all of them to the safer style for future proof. Directly casting OCaml value's *data block* (rather than the value itself) as a C pointer is not a common practice either, but I'll leave it as it is. The bug hadn't occured on XenServer because XenServer didn't make use of the Mmap.read function (except in one place for debugging). In XenServer, most mmap operations were going through another pair of separately implemented functions (Xs_ring.read/write). Signed-off-by: Zheng Li <dev@zheng.li> diff --git a/tools/ocaml/libs/mmap/mmap_stubs.c b/tools/ocaml/libs/mmap/mmap_stubs.c --- a/tools/ocaml/libs/mmap/mmap_stubs.c +++ b/tools/ocaml/libs/mmap/mmap_stubs.c @@ -71,12 +71,10 @@ CAMLprim value stub_mmap_init(value fd, CAMLprim value stub_mmap_final(value interface) { CAMLparam1(interface); - struct mmap_interface *intf; - intf = GET_C_STRUCT(interface); - if (intf->addr != MAP_FAILED) - munmap(intf->addr, intf->len); - intf->addr = MAP_FAILED; + if (GET_C_STRUCT(interface)->addr != MAP_FAILED) + munmap(GET_C_STRUCT(interface)->addr, GET_C_STRUCT(interface)->len); + GET_C_STRUCT(interface)->addr = MAP_FAILED; CAMLreturn(Val_unit); } @@ -85,21 +83,19 @@ CAMLprim value stub_mmap_read(value inte { CAMLparam3(interface, start, len); CAMLlocal1(data); - struct mmap_interface *intf; int c_start; int c_len; c_start = Int_val(start); c_len = Int_val(len); - intf = GET_C_STRUCT(interface); - if (c_start > intf->len) + if (c_start > GET_C_STRUCT(interface)->len) caml_invalid_argument("start invalid"); - if (c_start + c_len > intf->len) + if (c_start + c_len > GET_C_STRUCT(interface)->len) caml_invalid_argument("len invalid"); data = caml_alloc_string(c_len); - memcpy((char *) data, intf->addr + c_start, c_len); + memcpy((char *) data, GET_C_STRUCT(interface)->addr + c_start, c_len); CAMLreturn(data); } @@ -108,20 +104,18 @@ CAMLprim value stub_mmap_write(value int value start, value len) { CAMLparam4(interface, data, start, len); - struct mmap_interface *intf; int c_start; int c_len; c_start = Int_val(start); c_len = Int_val(len); - intf = GET_C_STRUCT(interface); - if (c_start > intf->len) + if (c_start > GET_C_STRUCT(interface)->len) caml_invalid_argument("start invalid"); - if (c_start + c_len > intf->len) + if (c_start + c_len > GET_C_STRUCT(interface)->len) caml_invalid_argument("len invalid"); - memcpy(intf->addr + c_start, (char *) data, c_len); + memcpy(GET_C_STRUCT(interface)->addr + c_start, (char *) data, c_len); CAMLreturn(Val_unit); } --===============0527095429== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel --===============0527095429==-- From xen-devel-bounces@lists.xensource.com Fri Sep 30 09:09:35 2011 Return-path: <xen-devel-bounces@lists.xensource.com> Envelope-to: www-data@lists.xensource.com Delivery-date: Fri, 30 Sep 2011 09:09:35 -0700 Received: from localhost ([127.0.0.1] helo=lists.colo.xensource.com) by lists.xensource.com with esmtp (Exim 4.43) id 1R9feX-0003fC-To; Fri, 30 Sep 2011 09:09:34 -0700 Received: from mail21.messagelabs.com ([85.158.143.35]) by lists.xensource.com with esmtp (Exim 4.43) id 1R9fZA-0002xc-Ak for xen-devel@lists.xensource.com; Fri, 30 Sep 2011 09:04:11 -0700 X-Env-Sender: jeremy@goop.org X-Msg-Ref: server-15.tower-21.messagelabs.com!1317398637!52623703!1 X-Originating-IP: [74.207.240.146] X-StarScan-Version: 6.4.1; banners=-,-,- X-VirusChecked: Checked Received: (qmail 30892 invoked from network); 30 Sep 2011 16:03:58 -0000 Received: from claw.goop.org (HELO claw.goop.org) (74.207.240.146) by server-15.tower-21.messagelabs.com with DHE-RSA-AES256-SHA encrypted SMTP; 30 Sep 2011 16:03:58 -0000 Received: from saboo.goop.org (unknown [IPv6:2001:470:1f05:899:f2de:f1ff:fe5c:34ed]) (Authenticated sender: smtp-saboo) by claw.goop.org (Postfix) with ESMTPSA id 8B05194C1; Fri, 30 Sep 2011 09:03:54 -0700 (PDT) Received: from saboo.goop.org (localhost [IPv6:::1]) by saboo.goop.org (Postfix) with ESMTP id 79E2B20C32; Fri, 30 Sep 2011 09:03:51 -0700 (PDT) Message-ID: <4E85E867.8080809@goop.org> Date: Fri, 30 Sep 2011 09:03:51 -0700 From: Jeremy Fitzhardinge <jeremy@goop.org> User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:6.0.2) Gecko/20110906 Thunderbird/6.0.2 MIME-Version: 1.0 To: Jan Glauber <jang@linux.vnet.ibm.com> References: <cover.1317338254.git.jeremy.fitzhardinge@citrix.com> <b1d87557dc3001031ee8d7f69ee97b90cecba6aa.1317338254.git.jeremy.fitzhardinge@citrix.com> <1317394099.11297.54.camel@localhost.localdomain> In-Reply-To: <1317394099.11297.54.camel@localhost.localdomain> X-Enigmail-Version: 1.3.2 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit Cc: Xen Devel <xen-devel@lists.xensource.com>, David Daney <david.daney@cavium.com>, Jason Baron <jbaron@redhat.com>, the arch/x86 maintainers <x86@kernel.org>, Linux Kernel Mailing List <linux-kernel@vger.kernel.org>, Steven Rostedt <rostedt@goodmis.org>, Michael Ellerman <michael@ellerman.id.au>, Jeremy Fitzhardinge <jeremy.fitzhardinge@citrix.com>, "David S. Miller" <davem@davemloft.net> Subject: [Xen-devel] Re: [PATCH RFC 7/8] s390/jump-label: add arch_jump_label_transform_early() X-BeenThere: xen-devel@lists.xensource.com X-Mailman-Version: 2.1.5 Precedence: list List-Id: Xen developer discussion <xen-devel.lists.xensource.com> List-Unsubscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe> List-Post: <mailto:xen-devel@lists.xensource.com> List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help> List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=subscribe> Sender: xen-devel-bounces@lists.xensource.com Errors-To: xen-devel-bounces@lists.xensource.com On 09/30/2011 07:48 AM, Jan Glauber wrote: > On Thu, 2011-09-29 at 16:26 -0700, Jeremy Fitzhardinge wrote: >> From: Jeremy Fitzhardinge <jeremy.fitzhardinge@citrix.com> >> >> This allows jump-label entries to be modified early, in a pre-SMP >> environment. >> >> Signed-off-by: Jeremy Fitzhardinge <jeremy.fitzhardinge@citrix.com> >> Cc: Jan Glauber <jang@linux.vnet.ibm.com> > Hi Jeremy, > > Your patch looks fine, if you can fix the minor compiler warnings > below. Excluding stop_machine() on pre-SMP also looks safer too me. Do you think there would be an actual problem, or are you just being cautious? It seems to me - in general - stop_machine could just be defined to be a no-op (ie, just directly calls the callback) until enough SMP is initialized for it to make sense, rather than having to make every user work around it (if there's a chance they might call it early). > CC arch/s390/kernel/jump_label.o > arch/s390/kernel/jump_label.c: In function ‘__jump_label_transform’: > arch/s390/kernel/jump_label.c:41:2: error: ‘rc’ undeclared (first use in this function) > arch/s390/kernel/jump_label.c:41:2: note: each undeclared identifier is reported only once for each function it appears in > arch/s390/kernel/jump_label.c:41:2: warning: passing argument 1 of ‘probe_kernel_write’ makes pointer from integer without a cast [enabled by default] > include/linux/uaccess.h:108:21: note: expected ‘void *’ but argument is of type ‘jump_label_t’ > arch/s390/kernel/jump_label.c:28:19: warning: unused variable ‘args’ [-Wunused-variable] > make[2]: *** [arch/s390/kernel/jump_label.o] Error 1 > > Like so? >From 9572689d1e5e6f54a1936a1dca09a6920d1bce27 Mon Sep 17 00:00:00 2001 From: Jeremy Fitzhardinge <jeremy.fitzhardinge@citrix.com> Date: Thu, 29 Sep 2011 10:58:46 -0700 Subject: [PATCH] s390/jump-label: add arch_jump_label_transform_early() This allows jump-label entries to be modified early, in a pre-SMP environment. Signed-off-by: Jeremy Fitzhardinge <jeremy.fitzhardinge@citrix.com> Cc: Jan Glauber <jang@linux.vnet.ibm.com> diff --git a/arch/s390/kernel/jump_label.c b/arch/s390/kernel/jump_label.c index 44cc06b..4fbe63b 100644 --- a/arch/s390/kernel/jump_label.c +++ b/arch/s390/kernel/jump_label.c @@ -18,26 +18,15 @@ struct insn { } __packed; struct insn_args { - unsigned long *target; - struct insn *insn; - ssize_t size; + struct jump_entry *entry; + enum jump_label_type type; }; -static int __arch_jump_label_transform(void *data) +static void __jump_label_transform(struct jump_entry *entry, + enum jump_label_type type) { - struct insn_args *args = data; - int rc; - - rc = probe_kernel_write(args->target, args->insn, args->size); - WARN_ON_ONCE(rc < 0); - return 0; -} - -void arch_jump_label_transform(struct jump_entry *entry, - enum jump_label_type type) -{ - struct insn_args args; struct insn insn; + int rc; if (type == JUMP_LABEL_ENABLE) { /* brcl 15,offset */ @@ -49,11 +38,33 @@ void arch_jump_label_transform(struct jump_entry *entry, insn.offset = 0; } - args.target = (void *) entry->code; - args.insn = &insn; - args.size = JUMP_LABEL_NOP_SIZE; + rc = probe_kernel_write((void *)entry->code, &insn, JUMP_LABEL_NOP_SIZE); + WARN_ON_ONCE(rc < 0); +} - stop_machine(__arch_jump_label_transform, &args, NULL); +static int __sm_arch_jump_label_transform(void *data) +{ + struct insn_args *args = data; + + __jump_label_transform(args->entry, args->type); + return 0; +} + +void arch_jump_label_transform(struct jump_entry *entry, + enum jump_label_type type) +{ + struct insn_args args; + + args.entry = entry; + args.type = type; + + stop_machine(__sm_arch_jump_label_transform, &args, NULL); +} + +void __init arch_jump_label_transform_early(struct jump_entry *entry, + enum jump_label_type type) +{ + __jump_label_transform(entry, type); } #endif J _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel From xen-devel-bounces@lists.xensource.com Fri Sep 30 09:11:29 2011 Return-path: <xen-devel-bounces@lists.xensource.com> Envelope-to: www-data@lists.xensource.com Delivery-date: Fri, 30 Sep 2011 09:11:29 -0700 Received: from localhost ([127.0.0.1] helo=lists.colo.xensource.com) by lists.xensource.com with esmtp (Exim 4.43) id 1R9fgO-00042h-PU; Fri, 30 Sep 2011 09:11:29 -0700 Received: from mail27.messagelabs.com ([193.109.254.147]) by lists.xensource.com with smtp (Exim 4.43) id 1R9fbC-0003MV-Oz for xen-devel@lists.xensource.com; Fri, 30 Sep 2011 09:06:34 -0700 X-Env-Sender: stefan.bader@canonical.com X-Msg-Ref: server-13.tower-27.messagelabs.com!1317398750!42240286!1 X-Originating-IP: [91.189.89.112] X-StarScan-Version: 6.4.1; banners=-,-,- X-VirusChecked: Checked Received: (qmail 7640 invoked from network); 30 Sep 2011 16:05:50 -0000 Received: from youngberry.canonical.com (HELO youngberry.canonical.com) (91.189.89.112) by server-13.tower-27.messagelabs.com with SMTP; 30 Sep 2011 16:05:50 -0000 Received: from p5b2e4fdc.dip.t-dialin.net ([91.46.79.220] helo=[192.168.2.5]) by youngberry.canonical.com with esmtpsa (TLS1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.71) (envelope-from <stefan.bader@canonical.com>) id 1R9fb9-0004h2-07; Fri, 30 Sep 2011 16:06:03 +0000 Message-ID: <4E85E8E8.2020702@canonical.com> Date: Fri, 30 Sep 2011 18:06:00 +0200 From: Stefan Bader <stefan.bader@canonical.com> User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.2.23) Gecko/20110922 Lightning/1.0b2 Thunderbird/3.1.15 MIME-Version: 1.0 To: Stefano Stabellini <stefano.stabellini@eu.citrix.com> Subject: Re: [Xen-devel] Re: Still struggling with HVM: tx timeouts on emulated nics References: <4E7B4768.8060103@canonical.com> <alpine.DEB.2.00.1109221838370.8700@kaball-desktop> <4E85883C.7030808@canonical.com> <alpine.DEB.2.00.1109301427590.3519@kaball-desktop> In-Reply-To: <alpine.DEB.2.00.1109301427590.3519@kaball-desktop> X-Enigmail-Version: 1.1.2 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com> X-BeenThere: xen-devel@lists.xensource.com X-Mailman-Version: 2.1.5 Precedence: list List-Id: Xen developer discussion <xen-devel.lists.xensource.com> List-Unsubscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe> List-Post: <mailto:xen-devel@lists.xensource.com> List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help> List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=subscribe> Sender: xen-devel-bounces@lists.xensource.com Errors-To: xen-devel-bounces@lists.xensource.com On 30.09.2011 16:09, Stefano Stabellini wrote: > @@ -270,6 +271,18 @@ ret_t do_physdev_op(int cmd, XEN_GUEST_H > if ( !is_hvm_domain(v->domain) || > domain_pirq_to_irq(v->domain, eoi.irq) > 0 ) > pirq_guest_eoi(pirq); > + if ( is_hvm_domain(v->domain) && > + domain_pirq_to_emuirq(v->domain, eoi.irq) > 0 ) > + { > + struct hvm_irq *hvm_irq = &v->domain->arch.hvm_domain.irq; > + int gsi = domain_pirq_to_emuirq(v->domain, eoi.irq); > + > + /* if this is a level irq and count > 0, send another > + * notification */ > + if ( gsi >= NR_ISAIRQS /* ISA irqs are edge triggered */ > + && hvm_irq->gsi_assert_count[gsi] ) > + send_guest_pirq(v->domain, pirq); > + } > spin_unlock(&v->domain->event_lock); > ret = 0; > break; This hunk looks substantially different from my 4.1.1 based code. There is no spin_lock acquired. Not sure that could be a reason for the different behaviour, too. I'll add that spinlock too. case PHYSDEVOP_eoi: { struct physdev_eoi eoi; ret = -EFAULT; if ( copy_from_guest(&eoi, arg, 1) != 0 ) break; ret = -EINVAL; if ( eoi.irq >= v->domain->nr_pirqs ) break; if ( v->domain->arch.pirq_eoi_map ) evtchn_unmask(v->domain->pirq_to_evtchn[eoi.irq]); if ( !is_hvm_domain(v->domain) || domain_pirq_to_irq(v->domain, eoi.irq) > 0 ) ret = pirq_guest_eoi(v->domain, eoi.irq); else ret = 0; break; } _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel From xen-devel-bounces@lists.xensource.com Fri Sep 30 09:12:34 2011 Return-path: <xen-devel-bounces@lists.xensource.com> Envelope-to: www-data@lists.xensource.com Delivery-date: Fri, 30 Sep 2011 09:12:34 -0700 Received: from localhost ([127.0.0.1] helo=lists.colo.xensource.com) by lists.xensource.com with esmtp (Exim 4.43) id 1R9fhR-0004PE-Vp; Fri, 30 Sep 2011 09:12:34 -0700 Received: from mail21.messagelabs.com ([85.158.143.35]) by lists.xensource.com with esmtp (Exim 4.43) id 1R9fel-0003h0-L1 for xen-devel@lists.xensource.com; Fri, 30 Sep 2011 09:09:48 -0700 X-Env-Sender: jeremy@goop.org X-Msg-Ref: server-14.tower-21.messagelabs.com!1317398974!61638209!1 X-Originating-IP: [74.207.240.146] X-StarScan-Version: 6.4.1; banners=-,-,- X-VirusChecked: Checked Received: (qmail 27493 invoked from network); 30 Sep 2011 16:09:35 -0000 Received: from claw.goop.org (HELO claw.goop.org) (74.207.240.146) by server-14.tower-21.messagelabs.com with DHE-RSA-AES256-SHA encrypted SMTP; 30 Sep 2011 16:09:35 -0000 Received: from saboo.goop.org (unknown [IPv6:2001:470:1f05:899:f2de:f1ff:fe5c:34ed]) (Authenticated sender: smtp-saboo) by claw.goop.org (Postfix) with ESMTPSA id 59B4F94D6; Fri, 30 Sep 2011 09:09:42 -0700 (PDT) Received: from saboo.goop.org (localhost [IPv6:::1]) by saboo.goop.org (Postfix) with ESMTP id 6334E20256; Fri, 30 Sep 2011 09:09:40 -0700 (PDT) Message-ID: <4E85E9C4.1090606@goop.org> Date: Fri, 30 Sep 2011 09:09:40 -0700 From: Jeremy Fitzhardinge <jeremy@goop.org> User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:6.0.2) Gecko/20110906 Thunderbird/6.0.2 MIME-Version: 1.0 To: Steven Rostedt <rostedt@goodmis.org> References: <cover.1317338254.git.jeremy.fitzhardinge@citrix.com> <1317343975.4588.36.camel@gandalf.stny.rr.com> <4E854859.4020105@goop.org> <1317396484.4588.52.camel@gandalf.stny.rr.com> In-Reply-To: <1317396484.4588.52.camel@gandalf.stny.rr.com> X-Enigmail-Version: 1.3.2 Content-Type: text/plain; charset=ISO-8859-15 Content-Transfer-Encoding: 7bit Cc: Xen Devel <xen-devel@lists.xensource.com>, Jan Glauber <jang@linux.vnet.ibm.com>, Jason Baron <jbaron@redhat.com>, the arch/x86 maintainers <x86@kernel.org>, David Daney <david.daney@cavium.com>, Linux Kernel Mailing List <linux-kernel@vger.kernel.org>, Michael Ellerman <michael@ellerman.id.au>, Jeremy Fitzhardinge <jeremy.fitzhardinge@citrix.com>, "David S. Miller" <davem@davemloft.net> Subject: [Xen-devel] Re: [PATCH RFC 0/8] jump-label: allow early jump_label_enable() X-BeenThere: xen-devel@lists.xensource.com X-Mailman-Version: 2.1.5 Precedence: list List-Id: Xen developer discussion <xen-devel.lists.xensource.com> List-Unsubscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe> List-Post: <mailto:xen-devel@lists.xensource.com> List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help> List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=subscribe> Sender: xen-devel-bounces@lists.xensource.com Errors-To: xen-devel-bounces@lists.xensource.com On 09/30/2011 08:28 AM, Steven Rostedt wrote: > On Thu, 2011-09-29 at 21:40 -0700, Jeremy Fitzhardinge wrote: >> On 09/29/2011 05:52 PM, Steven Rostedt wrote: >>> On Thu, 2011-09-29 at 16:26 -0700, Jeremy Fitzhardinge wrote: >>>> From: Jeremy Fitzhardinge <jeremy.fitzhardinge@citrix.com> >>>> >>>> One big question which arises is whether the _early() function is >>>> necessary at all. All the stop_machine/mutex/etc stuff that >>>> arch_jump_label_transform() ends up doing is redundant pre-SMP, but it >>>> shouldn't hurt. Maybe we can just drop the _early function? It works >>>> on x86, at least, because jump_label_enable() works, which uses the full >>>> form. And dropping it would reduce this to a very much smaller series. >>> It does slow down the boot process, which is not a good thing when >>> everyone is pushing for the fastest restarts. >> Would it really though? stop_machine() doesn't do very much when there >> are no other cpus. >> >> Not that I measured or anything, but there was no obvious big lag at boot. > Just bringing up the point, but without measurements, its all hand > waving. It may not be a big deal, and simpler code is always better if > it doesn't harm anything else. I think the simplest thing is to make stop_machine() well-defined in a pre-smp environment, where it just directly calls the callback: diff --git a/kernel/stop_machine.c b/kernel/stop_machine.c index ba5070c..b6ad9b3 100644 --- a/kernel/stop_machine.c +++ b/kernel/stop_machine.c @@ -485,6 +485,11 @@ int __stop_machine(int (*fn)(void *), void *data, const struct cpumask *cpus) .num_threads = num_online_cpus(), .active_cpus = cpus }; + if (smdata.num_threads == 1) { + (*fn)(data); + return 0; + } + /* Set the initial state and stop all online cpus. */ set_state(&smdata, STOPMACHINE_PREPARE); return stop_cpus(cpu_online_mask, stop_machine_cpu_stop, &smdata); so that its guaranteed safe to use at any point. J _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel From xen-devel-bounces@lists.xensource.com Fri Sep 30 09:34:20 2011 Return-path: <xen-devel-bounces@lists.xensource.com> Envelope-to: www-data@lists.xensource.com Delivery-date: Fri, 30 Sep 2011 09:34:20 -0700 Received: from localhost ([127.0.0.1] helo=lists.colo.xensource.com) by lists.xensource.com with esmtp (Exim 4.43) id 1R9g2W-00056K-Eh; Fri, 30 Sep 2011 09:34:20 -0700 Received: from mail21.messagelabs.com ([85.158.143.35]) by lists.xensource.com with esmtp (Exim 4.43) id 1R9g1x-0004uN-FX; Fri, 30 Sep 2011 09:33:46 -0700 X-Env-Sender: florian.heigl@gmail.com X-Msg-Ref: server-5.tower-21.messagelabs.com!1317400386!50187337!1 X-Originating-IP: [209.85.213.171] X-StarScan-Version: 6.4.1; banners=-,-,- X-VirusChecked: Checked Received: (qmail 20124 invoked from network); 30 Sep 2011 16:33:07 -0000 Received: from mail-yx0-f171.google.com (HELO mail-yx0-f171.google.com) (209.85.213.171) by server-5.tower-21.messagelabs.com with RC4-SHA encrypted SMTP; 30 Sep 2011 16:33:07 -0000 Received: by yxt3 with SMTP id 3so2714216yxt.30 for <multiple recipients>; Fri, 30 Sep 2011 09:33:41 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=rDdOC0hO0Efp3hn1a52IyNVQe/a1TRYJTcsJhzh6kJo=; b=P5as+j1gIZDhg5+OPSx48/qpjxzF/LOHKhBYz+57Bx0KT/bocw1MVL7l4YOwRyfy/q Z7rRl9ynoucBgicHXGuQ1w5ipPmhPn9Z3iL2HmbXWGrfFOzVSZ+LOuQ4WETcXaXZ3PUV GXcSCmJcZzhuF1rwHQ0OJY7uYAYDSvOvcQMaE= MIME-Version: 1.0 Received: by 10.68.22.195 with SMTP id g3mr39944334pbf.108.1317400420665; Fri, 30 Sep 2011 09:33:40 -0700 (PDT) Received: by 10.142.136.13 with HTTP; Fri, 30 Sep 2011 09:33:40 -0700 (PDT) In-Reply-To: <4E85A9B7.7040605@xen.org> References: <20110922130618.GA13238@phenom.oracle.com> <20110929141317.GX12984@reaktio.net> <CAOzFzEieWhgoBWEXQFjqr8PYoVOAcU20rtA2Q3OhyA+=dD9Atg@mail.gmail.com> <4E85A9B7.7040605@xen.org> Date: Fri, 30 Sep 2011 18:33:40 +0200 Message-ID: <CAFivhPnc-Mpv+Yapp3fVkV2awDcfGw0nv_gWERftnLJXA0_M5A@mail.gmail.com> Subject: Re: [Xen-users] Re: [Xen-devel] Xen document day (Oct 12 or 26) From: Florian Heigl <florian.heigl@gmail.com> To: Lars Kurth <lars.kurth@xen.org> Content-Type: text/plain; charset=ISO-8859-1 Cc: Joseph Glanville <joseph.glanville@orionvm.com.au>, xen-devel@lists.xensource.com, xen-users@lists.xensource.com, Konrad Rzeszutek Wilk <konrad.wilk@oracle.com> X-BeenThere: xen-devel@lists.xensource.com X-Mailman-Version: 2.1.5 Precedence: list List-Id: Xen developer discussion <xen-devel.lists.xensource.com> List-Unsubscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe> List-Post: <mailto:xen-devel@lists.xensource.com> List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help> List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=subscribe> Sender: xen-devel-bounces@lists.xensource.com Errors-To: xen-devel-bounces@lists.xensource.com 2011/9/30 Lars Kurth <lars.kurth@xen.org>: > Let me know, which date you agreed on. We could do a poll. > We should publish on the blog a bit before. > Also, how can I help? One thing where you could probably help best is setting clear rules what do document for a release. i.e. the 4.0 relnotes had build instructions and a lot more, whereas this is missing in the next release note. either the build instructions were in the wrong place for 4.0 or 4.1 was released with incomplete info ;) making a checklist sounds *ahem* in place :) Flo -- the purpose of libvirt is to provide an abstraction layer hiding all xen features added since 2006 until they were finally understood and copied by the kvm devs. _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel From xen-devel-bounces@lists.xensource.com Fri Sep 30 09:36:59 2011 Return-path: <xen-devel-bounces@lists.xensource.com> Envelope-to: www-data@lists.xensource.com Delivery-date: Fri, 30 Sep 2011 09:36:59 -0700 Received: from localhost ([127.0.0.1] helo=lists.colo.xensource.com) by lists.xensource.com with esmtp (Exim 4.43) id 1R9g54-00069X-W9; Fri, 30 Sep 2011 09:36:59 -0700 Received: from mail21.messagelabs.com ([85.158.143.35]) by lists.xensource.com with esmtp (Exim 4.43) id 1R9g2K-00051Q-L7 for xen-devel@lists.xensource.com; Fri, 30 Sep 2011 09:34:09 -0700 X-Env-Sender: Ian.Campbell@eu.citrix.com X-Msg-Ref: server-15.tower-21.messagelabs.com!1317400447!52627778!1 X-Originating-IP: [62.200.22.115] X-StarScan-Version: 6.4.1; banners=-,-,- X-VirusChecked: Checked Received: (qmail 26089 invoked from network); 30 Sep 2011 16:34:07 -0000 Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115) by server-15.tower-21.messagelabs.com with RC4-SHA encrypted SMTP; 30 Sep 2011 16:34:07 -0000 X-IronPort-AV: E=Sophos;i="4.68,468,1312156800"; d="scan'208";a="8157833" Received: from lonpmailmx01.citrite.net ([10.30.203.162]) by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5; 30 Sep 2011 16:34:05 +0000 Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net (10.30.203.162) with Microsoft SMTP Server id 8.3.137.0; Fri, 30 Sep 2011 17:34:05 +0100 Subject: Re: [Xen-devel] [PATCH 1 of 2] Fix invalid memory access in OCaml mmap library (to play nicely with the GC) From: Ian Campbell <Ian.Campbell@citrix.com> To: Zheng Li <dev@zheng.li> Date: Fri, 30 Sep 2011 17:34:05 +0100 In-Reply-To: <a980cfb2e4da7ce1780f.1317397199@eta> References: <patchbomb.1317397198@eta> <a980cfb2e4da7ce1780f.1317397199@eta> Organization: Citrix Systems, Inc. Content-Type: text/plain; charset="UTF-8" X-Mailer: Evolution 3.0.3- Content-Transfer-Encoding: 7bit Message-ID: <1317400445.26672.314.camel@zakaz.uk.xensource.com> MIME-Version: 1.0 Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com> X-BeenThere: xen-devel@lists.xensource.com X-Mailman-Version: 2.1.5 Precedence: list List-Id: Xen developer discussion <xen-devel.lists.xensource.com> List-Unsubscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe> List-Post: <mailto:xen-devel@lists.xensource.com> List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help> List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=subscribe> Sender: xen-devel-bounces@lists.xensource.com Errors-To: xen-devel-bounces@lists.xensource.com On Fri, 2011-09-30 at 16:39 +0100, Zheng Li wrote: > This was a bug reported by Roberto Di Cosmo. When he tried to reuse > the mmap library for his own project, Mmap.read occasionally got > different result when reading from the same map. This turned out to be > a bug in the binding, where a C pointer was created pointing to a > OCaml value, and the OCaml value was subsequently moved around by the > GC after memory allocation and hence invalidated the C pointer. This > patch removes the indirection of C pointer and uses OCaml macro to > access values directly. I was initially quite confused about how the value of a parameter to a C function could change while that function was running but I see now that the CAMLparam* stuff apparently enables that behaviour by stashing the address of the parameters so if you ever call back into the runtime (and presumably asynchronously if you are multithreaded) the GC can indeed move stuff around. The proposed patch only appears to fix the issue if there is some higher level locking which prevents another thread from triggering a gc while this function is running. IIRC there is a single global lock which covers all C code called from ocaml, is that right? Ian. > Only Mmap.read function had this problem. The other functions, despite > having the same code style, didn't have memory allocation involved > hence wouldn't intrigue such an error. I've changed all of them to the > safer style for future proof. Directly casting OCaml value's *data > block* (rather than the value itself) as a C pointer is not a common > practice either, but I'll leave it as it is. > > The bug hadn't occured on XenServer because XenServer didn't make use > of the Mmap.read function (except in one place for debugging). In > XenServer, most mmap operations were going through another pair of > separately implemented functions (Xs_ring.read/write). > > > Signed-off-by: Zheng Li <dev@zheng.li> > > > tools/ocaml/libs/mmap/mmap_stubs.c | 24 +++++++++--------------- > 1 files changed, 9 insertions(+), 15 deletions(-) > > > ---- > diff --git a/tools/ocaml/libs/mmap/mmap_stubs.c b/tools/ocaml/libs/mmap/mmap_stubs.c > --- a/tools/ocaml/libs/mmap/mmap_stubs.c > +++ b/tools/ocaml/libs/mmap/mmap_stubs.c > @@ -71,12 +71,10 @@ CAMLprim value stub_mmap_init(value fd, > CAMLprim value stub_mmap_final(value interface) > { > CAMLparam1(interface); > - struct mmap_interface *intf; > > - intf = GET_C_STRUCT(interface); > - if (intf->addr != MAP_FAILED) > - munmap(intf->addr, intf->len); > - intf->addr = MAP_FAILED; > + if (GET_C_STRUCT(interface)->addr != MAP_FAILED) > + munmap(GET_C_STRUCT(interface)->addr, GET_C_STRUCT(interface)->len); > + GET_C_STRUCT(interface)->addr = MAP_FAILED; > > CAMLreturn(Val_unit); > } > @@ -85,21 +83,19 @@ CAMLprim value stub_mmap_read(value inte > { > CAMLparam3(interface, start, len); > CAMLlocal1(data); > - struct mmap_interface *intf; > int c_start; > int c_len; > > c_start = Int_val(start); > c_len = Int_val(len); > - intf = GET_C_STRUCT(interface); > > - if (c_start > intf->len) > + if (c_start > GET_C_STRUCT(interface)->len) > caml_invalid_argument("start invalid"); > - if (c_start + c_len > intf->len) > + if (c_start + c_len > GET_C_STRUCT(interface)->len) > caml_invalid_argument("len invalid"); > > data = caml_alloc_string(c_len); > - memcpy((char *) data, intf->addr + c_start, c_len); > + memcpy((char *) data, GET_C_STRUCT(interface)->addr + c_start, c_len); > > CAMLreturn(data); > } > @@ -108,20 +104,18 @@ CAMLprim value stub_mmap_write(value int > value start, value len) > { > CAMLparam4(interface, data, start, len); > - struct mmap_interface *intf; > int c_start; > int c_len; > > c_start = Int_val(start); > c_len = Int_val(len); > - intf = GET_C_STRUCT(interface); > > - if (c_start > intf->len) > + if (c_start > GET_C_STRUCT(interface)->len) > caml_invalid_argument("start invalid"); > - if (c_start + c_len > intf->len) > + if (c_start + c_len > GET_C_STRUCT(interface)->len) > caml_invalid_argument("len invalid"); > > - memcpy(intf->addr + c_start, (char *) data, c_len); > + memcpy(GET_C_STRUCT(interface)->addr + c_start, (char *) data, c_len); > > CAMLreturn(Val_unit); > } _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel From xen-devel-bounces@lists.xensource.com Fri Sep 30 09:37:50 2011 Return-path: <xen-devel-bounces@lists.xensource.com> Envelope-to: www-data@lists.xensource.com Delivery-date: Fri, 30 Sep 2011 09:37:50 -0700 Received: from localhost ([127.0.0.1] helo=lists.colo.xensource.com) by lists.xensource.com with esmtp (Exim 4.43) id 1R9g5u-0006W1-CM; Fri, 30 Sep 2011 09:37:50 -0700 Received: from mail216.messagelabs.com ([85.158.143.99]) by lists.xensource.com with esmtp (Exim 4.43) id 1R9g5W-0006KF-8d for xen-devel@lists.xensource.com; Fri, 30 Sep 2011 09:37:26 -0700 X-Env-Sender: david.vrabel@citrix.com X-Msg-Ref: server-2.tower-216.messagelabs.com!1317400641!19729107!1 X-Originating-IP: [66.165.176.63] X-StarScan-Version: 6.4.1; banners=-,-,- X-VirusChecked: Checked Received: (qmail 31572 invoked from network); 30 Sep 2011 16:37:23 -0000 Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63) by server-2.tower-216.messagelabs.com with RC4-SHA encrypted SMTP; 30 Sep 2011 16:37:23 -0000 X-IronPort-AV: E=Sophos;i="4.68,468,1312171200"; d="scan'208";a="165319643" Received: from ftlpmailmx02.citrite.net ([10.13.107.66]) by FTLPIPO02.CITRIX.COM with ESMTP/TLS/RC4-MD5; 30 Sep 2011 12:37:21 -0400 Received: from smtp01.ad.xensource.com (10.219.128.104) by smtprelay.citrix.com (10.13.107.66) with Microsoft SMTP Server id 8.3.137.0; Fri, 30 Sep 2011 12:37:21 -0400 Received: from qabil.uk.xensource.com (qabil.uk.xensource.com [10.80.2.76]) by smtp01.ad.xensource.com (8.13.1/8.13.1) with ESMTP id p8UGbJaX029643; Fri, 30 Sep 2011 09:37:19 -0700 From: David Vrabel <david.vrabel@citrix.com> To: "David S. Miller" <davem@davemloft.net> Date: Fri, 30 Sep 2011 17:37:51 +0100 Message-ID: <1317400671-21236-1-git-send-email-david.vrabel@citrix.com> X-Mailer: git-send-email 1.7.2.5 MIME-Version: 1.0 Content-Type: text/plain Cc: netdev@vger.kernel.org, xen-devel@lists.xensource.com, David Vrabel <david.vrabel@citrix.com>, Ian Campbell <ian.campbell@citrix.com> Subject: [Xen-devel] [PATCH] net: xen-netback: correctly restart Tx after a VM restore/migrate X-BeenThere: xen-devel@lists.xensource.com X-Mailman-Version: 2.1.5 Precedence: list List-Id: Xen developer discussion <xen-devel.lists.xensource.com> List-Unsubscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe> List-Post: <mailto:xen-devel@lists.xensource.com> List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help> List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=subscribe> Sender: xen-devel-bounces@lists.xensource.com Errors-To: xen-devel-bounces@lists.xensource.com If a VM is saved and restored (or migrated) the netback driver will no longer process any Tx packets from the frontend. xenvif_up() does not schedule the processing of any pending Tx requests from the front end because the carrier is off. Without this initial kick the frontend just adds Tx requests to the ring without raising an event (until the ring is full). This was caused by 47103041e91794acdbc6165da0ae288d844c820b (net: xen-netback: convert to hw_features) which reordered the calls to xenvif_up() and netif_carrier_on() in xenvif_connect(). Signed-off-by: David Vrabel <david.vrabel@citrix.com> Cc: Ian Campbell <ian.campbell@citrix.com> --- drivers/net/xen-netback/interface.c | 4 ++-- 1 files changed, 2 insertions(+), 2 deletions(-) diff --git a/drivers/net/xen-netback/interface.c b/drivers/net/xen-netback/interface.c index 0ca86f9..1825629 100644 --- a/drivers/net/xen-netback/interface.c +++ b/drivers/net/xen-netback/interface.c @@ -327,12 +327,12 @@ int xenvif_connect(struct xenvif *vif, unsigned long tx_ring_ref, xenvif_get(vif); rtnl_lock(); - if (netif_running(vif->dev)) - xenvif_up(vif); if (!vif->can_sg && vif->dev->mtu > ETH_DATA_LEN) dev_set_mtu(vif->dev, ETH_DATA_LEN); netdev_update_features(vif->dev); netif_carrier_on(vif->dev); + if (netif_running(vif->dev)) + xenvif_up(vif); rtnl_unlock(); return 0; -- 1.7.2.5 _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel From xen-devel-bounces@lists.xensource.com Fri Sep 30 09:44:27 2011 Return-path: <xen-devel-bounces@lists.xensource.com> Envelope-to: www-data@lists.xensource.com Delivery-date: Fri, 30 Sep 2011 09:44:27 -0700 Received: from localhost ([127.0.0.1] helo=lists.colo.xensource.com) by lists.xensource.com with esmtp (Exim 4.43) id 1R9gCJ-00075N-Iz; Fri, 30 Sep 2011 09:44:27 -0700 Received: from mail182.messagelabs.com ([85.158.139.83]) by lists.xensource.com with smtp (Exim 4.43) id 1R9gBg-0006qH-SJ for xen-devel@lists.xensource.com; Fri, 30 Sep 2011 09:43:49 -0700 X-Env-Sender: gcvxd-xen-devel@m.gmane.org X-Msg-Ref: server-14.tower-182.messagelabs.com!1317401025!20233520!1 X-Originating-IP: [80.91.229.12] X-StarScan-Version: 6.4.1; banners=-,-,- X-VirusChecked: Checked Received: (qmail 17611 invoked from network); 30 Sep 2011 16:43:45 -0000 Received: from lo.gmane.org (HELO lo.gmane.org) (80.91.229.12) by server-14.tower-182.messagelabs.com with SMTP; 30 Sep 2011 16:43:45 -0000 Received: from list by lo.gmane.org with local (Exim 4.69) (envelope-from <gcvxd-xen-devel@m.gmane.org>) id 1R9gBa-0003XD-KQ for xen-devel@lists.xensource.com; Fri, 30 Sep 2011 18:43:42 +0200 Received: from firewall.ctxuk.citrix.com ([62.200.22.2]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for <xen-devel@lists.xensource.com>; Fri, 30 Sep 2011 18:43:42 +0200 Received: from zheng.li by firewall.ctxuk.citrix.com with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for <xen-devel@lists.xensource.com>; Fri, 30 Sep 2011 18:43:42 +0200 X-Injected-Via-Gmane: http://gmane.org/ To: xen-devel@lists.xensource.com From: Zheng Li <zheng.li@eu.citrix.com> Date: Fri, 30 Sep 2011 17:43:30 +0100 Lines: 57 Message-ID: <4E85F1B2.2040506@eu.citrix.com> References: <patchbomb.1317331042@snoosnoo2.uk.xensource.com> <48d4f312d0693cf8a52e.1317331047@snoosnoo2.uk.xensource.com> <1317369085.26672.212.camel@zakaz.uk.xensource.com> Mime-Version: 1.0 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Complaints-To: usenet@dough.gmane.org X-Gmane-NNTP-Posting-Host: firewall.ctxuk.citrix.com User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:7.0) Gecko/20110927 Thunderbird/7.0 In-Reply-To: <1317369085.26672.212.camel@zakaz.uk.xensource.com> Cc: Ian Campbell <Ian.Campbell@eu.citrix.com>, Jonathan Ludlam <Jonathan.Ludlam@eu.citrix.com> Subject: [Xen-devel] Re: [PATCH 5 of 7] [OCAML] Minor makefile cleanup X-BeenThere: xen-devel@lists.xensource.com X-Mailman-Version: 2.1.5 Precedence: list List-Id: Xen developer discussion <xen-devel.lists.xensource.com> List-Unsubscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe> List-Post: <mailto:xen-devel@lists.xensource.com> List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help> List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=subscribe> Sender: xen-devel-bounces@lists.xensource.com Errors-To: xen-devel-bounces@lists.xensource.com Hello, On 30/09/2011 08:51, Ian Campbell wrote: > What does the cleanup actually do? IIRC, the patch meant to do 2 things: * A small improvement (in two occasions) E.g., for make rule lib$(1)_stubs.a: $(foreach obj,$($(1)_C_OBJS),$(obj).o) substitute the action part from $(call mk-caml-lib-stubs,$$@, $$+) to $(call mk-caml-lib-stubs,$(1), $$+) i.e. pass part of the target's name as the argument to mk-caml-lib-stubs instead of the whole name, so that we can avoid calling basename and sed later on to recover the sub string. I.e., from $(call quiet-command, $(AR) rcs $1 $2 && $(OCAMLMKLIB) -o `basename $1 .a | sed -e 's/^lib//'` $2,MKLIB,$1) to $(call quiet-command, $(AR) rcs lib$(1)_stubs.a $2 && $(OCAMLMKLIB) $(LIBS_$(1)) -o $(1)_stubs $2,MKLIB,$1) * Some correction on linking parameters for bytecode mode compilation IIRC, it's this line that changed from $(call mk-caml-lib-bytecode,$$@, -dllib dll$(1)_stubs.so -cclib -l$(1)_stubs, $$+) to $(call mk-caml-lib-bytecode,$$@, -dllib dll$(1)_stubs.so -cclib -l$(1)_stubs $(foreach lib,$(LIBS_$(1)),-cclib $(lib)), $$+) The former was able to produce bytecode as well, but there would be problem in dynamic loading the generated bytecode (e.g. in OCaml toplevel). The later version should work fine with the toplevel. >> -LIBS_evtchn = $(LDLIBS_libxenctrl) >> +LIBS_eventchn = -L$(XEN_ROOT)/tools/libxc -lxenctrl > > This should continue using LDLIBS_libxenctrl unless there is a good > reason not too. I think you are right. They are identical, only the name in the first line needs fixing, and using predefined $(LDLIBS_libxenctrl) is certainly better. The change dated back before your Makefile refactoring after Xen-4.1 and was probably a result of mix up during rebase. Cheers -- Zheng _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel From xen-devel-bounces@lists.xensource.com Fri Sep 30 09:46:16 2011 Return-path: <xen-devel-bounces@lists.xensource.com> Envelope-to: www-data@lists.xensource.com Delivery-date: Fri, 30 Sep 2011 09:46:16 -0700 Received: from localhost ([127.0.0.1] helo=lists.colo.xensource.com) by lists.xensource.com with esmtp (Exim 4.43) id 1R9gE4-0007eh-A2; Fri, 30 Sep 2011 09:46:16 -0700 Received: from mail216.messagelabs.com ([85.158.143.99]) by lists.xensource.com with esmtp (Exim 4.43) id 1R9gCz-0007Kv-PB for xen-devel@lists.xensource.com; Fri, 30 Sep 2011 09:45:10 -0700 X-Env-Sender: Ian.Campbell@eu.citrix.com X-Msg-Ref: server-9.tower-216.messagelabs.com!1317401106!20192146!1 X-Originating-IP: [62.200.22.115] X-StarScan-Version: 6.4.1; banners=-,-,- X-VirusChecked: Checked Received: (qmail 26714 invoked from network); 30 Sep 2011 16:45:06 -0000 Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115) by server-9.tower-216.messagelabs.com with RC4-SHA encrypted SMTP; 30 Sep 2011 16:45:06 -0000 X-IronPort-AV: E=Sophos;i="4.68,468,1312156800"; d="scan'208";a="8158062" Received: from lonpmailmx01.citrite.net ([10.30.203.162]) by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5; 30 Sep 2011 16:45:06 +0000 Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net (10.30.203.162) with Microsoft SMTP Server id 8.3.137.0; Fri, 30 Sep 2011 17:45:06 +0100 From: Ian Campbell <Ian.Campbell@eu.citrix.com> To: David Vrabel <david.vrabel@citrix.com> Date: Fri, 30 Sep 2011 17:45:05 +0100 In-Reply-To: <1317400671-21236-1-git-send-email-david.vrabel@citrix.com> References: <1317400671-21236-1-git-send-email-david.vrabel@citrix.com> Organization: Citrix Systems, Inc. Content-Type: text/plain; charset="UTF-8" X-Mailer: Evolution 3.0.3- Content-Transfer-Encoding: 7bit Message-ID: <1317401105.26672.319.camel@zakaz.uk.xensource.com> MIME-Version: 1.0 Cc: "netdev@vger.kernel.org" <netdev@vger.kernel.org>, "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>, "David S. Miller" <davem@davemloft.net> Subject: [Xen-devel] Re: [PATCH] net: xen-netback: correctly restart Tx after a VM restore/migrate X-BeenThere: xen-devel@lists.xensource.com X-Mailman-Version: 2.1.5 Precedence: list List-Id: Xen developer discussion <xen-devel.lists.xensource.com> List-Unsubscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe> List-Post: <mailto:xen-devel@lists.xensource.com> List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help> List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=subscribe> Sender: xen-devel-bounces@lists.xensource.com Errors-To: xen-devel-bounces@lists.xensource.com On Fri, 2011-09-30 at 17:37 +0100, David Vrabel wrote: > If a VM is saved and restored (or migrated) the netback driver will no > longer process any Tx packets from the frontend. xenvif_up() does not > schedule the processing of any pending Tx requests from the front end > because the carrier is off. Without this initial kick the frontend > just adds Tx requests to the ring without raising an event (until the > ring is full). > > This was caused by 47103041e91794acdbc6165da0ae288d844c820b (net: > xen-netback: convert to hw_features) which reordered the calls to > xenvif_up() and netif_carrier_on() in xenvif_connect(). Ah, so the bit of that patch which moved "netif_carrier_on(vif->dev);" should have actually moved the entire block netif_carrier_on(vif->dev); if (netif_running(vif->dev)) xenvif_up(vif); Since it it is logically a single thing. Make sense. Thanks! > Signed-off-by: David Vrabel <david.vrabel@citrix.com> Acked-by: Ian Campbell <ian.campbell@citrix.com> Ian. > --- > drivers/net/xen-netback/interface.c | 4 ++-- > 1 files changed, 2 insertions(+), 2 deletions(-) > > diff --git a/drivers/net/xen-netback/interface.c b/drivers/net/xen-netback/interface.c > index 0ca86f9..1825629 100644 > --- a/drivers/net/xen-netback/interface.c > +++ b/drivers/net/xen-netback/interface.c > @@ -327,12 +327,12 @@ int xenvif_connect(struct xenvif *vif, unsigned long tx_ring_ref, > xenvif_get(vif); > > rtnl_lock(); > - if (netif_running(vif->dev)) > - xenvif_up(vif); > if (!vif->can_sg && vif->dev->mtu > ETH_DATA_LEN) > dev_set_mtu(vif->dev, ETH_DATA_LEN); > netdev_update_features(vif->dev); > netif_carrier_on(vif->dev); > + if (netif_running(vif->dev)) > + xenvif_up(vif); > rtnl_unlock(); > > return 0; _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel From xen-devel-bounces@lists.xensource.com Fri Sep 30 10:17:56 2011 Return-path: <xen-devel-bounces@lists.xensource.com> Envelope-to: www-data@lists.xensource.com Delivery-date: Fri, 30 Sep 2011 10:17:56 -0700 Received: from localhost ([127.0.0.1] helo=lists.colo.xensource.com) by lists.xensource.com with esmtp (Exim 4.43) id 1R9gii-0000hn-FT; Fri, 30 Sep 2011 10:17:56 -0700 Received: from mail27.messagelabs.com ([193.109.254.147]) by lists.xensource.com with esmtp (Exim 4.43) id 1R9ghv-0000Vk-RW for xen-devel@lists.xensource.com; Fri, 30 Sep 2011 10:17:09 -0700 X-Env-Sender: dan.magenheimer@oracle.com X-Msg-Ref: server-11.tower-27.messagelabs.com!1317403013!39634048!1 X-Originating-IP: [141.146.126.227] X-StarScan-Version: 6.4.1; banners=-,-,- X-VirusChecked: Checked Received: (qmail 14345 invoked from network); 30 Sep 2011 17:16:55 -0000 Received: from acsinet15.oracle.com (HELO acsinet15.oracle.com) (141.146.126.227) by server-11.tower-27.messagelabs.com with DHE-RSA-AES256-SHA encrypted SMTP; 30 Sep 2011 17:16:55 -0000 Received: from acsinet21.oracle.com (acsinet21.oracle.com [141.146.126.237]) by acsinet15.oracle.com (Switch-3.4.4/Switch-3.4.4) with ESMTP id p8UHGtKG006827 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Fri, 30 Sep 2011 17:16:57 GMT Received: from acsmt356.oracle.com (acsmt356.oracle.com [141.146.40.156]) by acsinet21.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id p8UHGrIV020377 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 30 Sep 2011 17:16:53 GMT Received: from abhmt103.oracle.com (abhmt103.oracle.com [141.146.116.55]) by acsmt356.oracle.com (8.12.11.20060308/8.12.11) with ESMTP id p8UHGkwV020507; Fri, 30 Sep 2011 12:16:46 -0500 MIME-Version: 1.0 Message-ID: <bcecca3e-55a1-457d-95e2-524068e79f79@default> Date: Fri, 30 Sep 2011 10:16:44 -0700 (PDT) From: Dan Magenheimer <dan.magenheimer@oracle.com> To: Philippe.Simonet@swisscom.com, George.Dunlap@eu.citrix.com Subject: RE: [Xen-devel] Xen 4 TSC problems References: <AANLkTik3Ng6TpQANfPNJ2M=86WYLHVt7_MuBuVfJ1CG_@mail.gmail.com> <CAFLBxZZiGxef5CkH9r+VZeB4h7LPA0nJddumwDRovZaL4zOuvA@mail.gmail.com> <5224b434-5371-404d-8fed-2665e73dacce@default> <CAFLBxZZ3nP5EbtL=Ne-W4DcSWtKGh1XDOs-EhVua7ujmi9Y2Jw@mail.gmail.com FF93AF260AC2BB499A119CC65B092CF73114B774@sg000713.corproot.net> In-Reply-To: <FF93AF260AC2BB499A119CC65B092CF73114B774@sg000713.corproot.net> X-Priority: 3 X-Mailer: Oracle Beehive Extensions for Outlook 2.0.1.4.1.0 (410211) [OL 12.0.6562.5003] Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable X-Source-IP: acsinet21.oracle.com [141.146.126.237] X-Auth-Type: Internal IP X-CT-RefId: str=0001.0A090205.4E85F989.0109:SCFMA922111,ss=1,re=-4.000,fgs=0 Cc: olivier.hanesse@gmail.com, jeremy@goop.org, xen-devel@lists.xensource.com, keir@xen.org, Konrad Wilk <konrad.wilk@oracle.com> X-BeenThere: xen-devel@lists.xensource.com X-Mailman-Version: 2.1.5 Precedence: list List-Id: Xen developer discussion <xen-devel.lists.xensource.com> List-Unsubscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe> List-Post: <mailto:xen-devel@lists.xensource.com> List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help> List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=subscribe> Sender: xen-devel-bounces@lists.xensource.com Errors-To: xen-devel-bounces@lists.xensource.com > From: Philippe.Simonet@swisscom.com [mailto:Philippe.Simonet@swisscom.com= ] > Subject: RE: [Xen-devel] Xen 4 TSC problems >=20 > Hi Xen developpers >=20 > i need some good tips to go forward with my TSC problem : >=20 > Could you give me some tips that I could test or implement ? > =09- try other hypervisor version ? Hi Phillipe -- It would definitely be worthwhile to see if you can reproduce the problem on the latest xen-unstable bits. (Please make sure that the bug George reported below is fixed in your build.) A lot has changed since 4.0.1. Dan P.S. I will be mostly offline for the next week or so... > > -----Original Message----- > > From: xen-devel-bounces@lists.xensource.com [mailto:xen-devel- > > bounces@lists.xensource.com] On Behalf Of George Dunlap > > Sent: Monday, September 19, 2011 12:40 PM > > To: Dan Magenheimer > > Cc: Keir Fraser; jeremy@goop.org; xen-devel@lists.xensource.com; Philip= pe > > Simonet; Konrad Wilk > > Subject: Re: [Xen-devel] Xen 4 TSC problems > > > > On Thu, Sep 15, 2011 at 7:38 PM, Dan Magenheimer > > <dan.magenheimer@oracle.com> wrote: > > >> I haven't been following this conversation, so I don't know if this > > >> is relevant, but I've just discovered this morning that the TSC warp > > >> check in Xen is done at the wrong time (before any secondary cpus ar= e > > >> brought up), and thus always returns warp=3D0. =A0I've submitted a p= atch > > >> to do the check after secondary CPUs are brought up; that should > > >> cause Xen to do periodic synchronization of TSCs when there is drift= . > > > > > > Wow, nice catch, George! =A0I wonder if this is the underlying bug fo= r > > > many of the mysterious time problems that have been reported for a > > > year or two now... at least on certain AMD boxes. > > > Any idea when this was introduced? =A0Or has it always been wrong? > > > > Well the comment in 20823:89907dab1aef seems to indicate that's where t= he > > "assume it's reliable on AMD until proven otherwise" started; that woul= d be > > January 2010. > > > > I looked as far back as 20705:a74aca4b9386, and there the TSC reliabili= ty > > checks were again in init_xen_time(). Figuring out where things were b= efore > > then is getting into archeology. :-) > > > > The comment at the top of init_xen_time() is correct now, but from the = time > > it was first written through 4.1 is was just plain wrong -- it said > > init_xen_time() happened after all cpus were up, which has never been t= rue. > > > > -George > > > > _______________________________________________ > > Xen-devel mailing list > > Xen-devel@lists.xensource.com > > http://lists.xensource.com/xen-devel _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel From xen-devel-bounces@lists.xensource.com Fri Sep 30 10:47:00 2011 Return-path: <xen-devel-bounces@lists.xensource.com> Envelope-to: www-data@lists.xensource.com Delivery-date: Fri, 30 Sep 2011 10:47:00 -0700 Received: from localhost ([127.0.0.1] helo=lists.colo.xensource.com) by lists.xensource.com with esmtp (Exim 4.43) id 1R9hAq-0002DN-Dv; Fri, 30 Sep 2011 10:47:00 -0700 Received: from mail27.messagelabs.com ([193.109.254.147]) by lists.xensource.com with smtp (Exim 4.43) id 1R9hA5-00020B-1e for xen-devel@lists.xensource.com; Fri, 30 Sep 2011 10:46:14 -0700 X-Env-Sender: gcvxd-xen-devel@m.gmane.org X-Msg-Ref: server-8.tower-27.messagelabs.com!1317404752!48810428!1 X-Originating-IP: [80.91.229.12] X-StarScan-Version: 6.4.1; banners=-,-,- X-VirusChecked: Checked Received: (qmail 17914 invoked from network); 30 Sep 2011 17:45:52 -0000 Received: from lo.gmane.org (HELO lo.gmane.org) (80.91.229.12) by server-8.tower-27.messagelabs.com with SMTP; 30 Sep 2011 17:45:52 -0000 Received: from list by lo.gmane.org with local (Exim 4.69) (envelope-from <gcvxd-xen-devel@m.gmane.org>) id 1R9hA1-0007Xs-Eb for xen-devel@lists.xensource.com; Fri, 30 Sep 2011 19:46:09 +0200 Received: from firewall.ctxuk.citrix.com ([62.200.22.2]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for <xen-devel@lists.xensource.com>; Fri, 30 Sep 2011 19:46:09 +0200 Received: from zheng.li by firewall.ctxuk.citrix.com with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for <xen-devel@lists.xensource.com>; Fri, 30 Sep 2011 19:46:09 +0200 X-Injected-Via-Gmane: http://gmane.org/ To: xen-devel@lists.xensource.com From: Zheng Li <zheng.li@eu.citrix.com> Date: Fri, 30 Sep 2011 18:45:54 +0100 Lines: 129 Message-ID: <4E860052.4090800@eu.citrix.com> References: <patchbomb.1317397198@eta> <a980cfb2e4da7ce1780f.1317397199@eta> <1317400445.26672.314.camel@zakaz.uk.xensource.com> Mime-Version: 1.0 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Complaints-To: usenet@dough.gmane.org X-Gmane-NNTP-Posting-Host: firewall.ctxuk.citrix.com User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:7.0) Gecko/20110927 Thunderbird/7.0 In-Reply-To: <1317400445.26672.314.camel@zakaz.uk.xensource.com> Cc: Ian Campbell <Ian.Campbell@eu.citrix.com> Subject: [Xen-devel] Re: [PATCH 1 of 2] Fix invalid memory access in OCaml mmap library (to play nicely with the GC) X-BeenThere: xen-devel@lists.xensource.com X-Mailman-Version: 2.1.5 Precedence: list List-Id: Xen developer discussion <xen-devel.lists.xensource.com> List-Unsubscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe> List-Post: <mailto:xen-devel@lists.xensource.com> List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help> List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=subscribe> Sender: xen-devel-bounces@lists.xensource.com Errors-To: xen-devel-bounces@lists.xensource.com On 30/09/2011 17:34, Ian Campbell wrote: > On Fri, 2011-09-30 at 16:39 +0100, Zheng Li wrote: >> This was a bug reported by Roberto Di Cosmo. When he tried to reuse >> the mmap library for his own project, Mmap.read occasionally got >> different result when reading from the same map. This turned out to be >> a bug in the binding, where a C pointer was created pointing to a >> OCaml value, and the OCaml value was subsequently moved around by the >> GC after memory allocation and hence invalidated the C pointer. This >> patch removes the indirection of C pointer and uses OCaml macro to >> access values directly. > > I was initially quite confused about how the value of a parameter to a C > function could change while that function was running but I see now that > the CAMLparam* stuff apparently enables that behaviour by stashing the > address of the parameters so if you ever call back into the runtime (and > presumably asynchronously if you are multithreaded) the GC can indeed > move stuff around. I think the issue itself is not related to multi-thread though. In the original version of the stub_mmap_read, intf = GET_C_STRUCT(interface); "interface" was passed to the C function as an OCaml value registered in the OCaml runtime, underline it was just a pointer pointing to a block in the OCaml heap. It was copied and casted to the "intf" on the C side, hence "intf" was initially pointing to the same address as "interface". Unfortunately, before we made any use of "intf", we first called data = caml_alloc_string(c_len); which called back to the OCaml runtime and allocated memory in the OCaml heap. Since caml_alloc_string was a function defined by OCaml runtime, it deliberately called quite a few GC routines under the hood which can possibly move any values in the OCaml heap. OCaml runtime would certainly update the "interface" pointer accordingly since it was registered with the runtime. But "intf" was a hard copy on the C side that OCaml had no idea about. So "intf" still pointed to the old address which was no longer valid. Despite the back and forth between C and OCaml territories, all was single threaded here. > The proposed patch only appears to fix the issue if there is some higher > level locking which prevents another thread from triggering a gc while > this function is running. IIRC there is a single global lock which > covers all C code called from ocaml, is that right? OCaml runtime has a global lock that will only allow one thread to execute it at a time and the GC is single threaded as well. This ensures the safety but unfortunately introduces the bottleneck. On the other hand, for threads that don't need to access memory on the OCaml side for a while (e.g. long running pure C routines invoked from OCaml side), they can run in parallel by using caml_{enter|leaving}_blocking_section primitives to give up and then retain the rights to enter OCaml runtime. Cheers -- Zheng >> Only Mmap.read function had this problem. The other functions, despite >> having the same code style, didn't have memory allocation involved >> hence wouldn't intrigue such an error. I've changed all of them to the >> safer style for future proof. Directly casting OCaml value's *data >> block* (rather than the value itself) as a C pointer is not a common >> practice either, but I'll leave it as it is. >> >> The bug hadn't occured on XenServer because XenServer didn't make use >> of the Mmap.read function (except in one place for debugging). In >> XenServer, most mmap operations were going through another pair of >> separately implemented functions (Xs_ring.read/write). >> >> >> Signed-off-by: Zheng Li<dev@zheng.li> >> >> >> tools/ocaml/libs/mmap/mmap_stubs.c | 24 +++++++++--------------- >> 1 files changed, 9 insertions(+), 15 deletions(-) >> >> >> ---- >> diff --git a/tools/ocaml/libs/mmap/mmap_stubs.c b/tools/ocaml/libs/mmap/mmap_stubs.c >> --- a/tools/ocaml/libs/mmap/mmap_stubs.c >> +++ b/tools/ocaml/libs/mmap/mmap_stubs.c >> @@ -71,12 +71,10 @@ CAMLprim value stub_mmap_init(value fd, >> CAMLprim value stub_mmap_final(value interface) >> { >> CAMLparam1(interface); >> - struct mmap_interface *intf; >> >> - intf = GET_C_STRUCT(interface); >> - if (intf->addr != MAP_FAILED) >> - munmap(intf->addr, intf->len); >> - intf->addr = MAP_FAILED; >> + if (GET_C_STRUCT(interface)->addr != MAP_FAILED) >> + munmap(GET_C_STRUCT(interface)->addr, GET_C_STRUCT(interface)->len); >> + GET_C_STRUCT(interface)->addr = MAP_FAILED; >> >> CAMLreturn(Val_unit); >> } >> @@ -85,21 +83,19 @@ CAMLprim value stub_mmap_read(value inte >> { >> CAMLparam3(interface, start, len); >> CAMLlocal1(data); >> - struct mmap_interface *intf; >> int c_start; >> int c_len; >> >> c_start = Int_val(start); >> c_len = Int_val(len); >> - intf = GET_C_STRUCT(interface); >> >> - if (c_start> intf->len) >> + if (c_start> GET_C_STRUCT(interface)->len) >> caml_invalid_argument("start invalid"); >> - if (c_start + c_len> intf->len) >> + if (c_start + c_len> GET_C_STRUCT(interface)->len) >> caml_invalid_argument("len invalid"); >> >> data = caml_alloc_string(c_len); >> - memcpy((char *) data, intf->addr + c_start, c_len); >> + memcpy((char *) data, GET_C_STRUCT(interface)->addr + c_start, c_len); >> >> CAMLreturn(data); >> } >> @@ -108,20 +104,18 @@ CAMLprim value stub_mmap_write(value int >> value start, value len) >> { >> CAMLparam4(interface, data, start, len); >> - struct mmap_interface *intf; >> int c_start; >> int c_len; >> >> c_start = Int_val(start); >> c_len = Int_val(len); >> - intf = GET_C_STRUCT(interface); >> >> - if (c_start> intf->len) >> + if (c_start> GET_C_STRUCT(interface)->len) >> caml_invalid_argument("start invalid"); >> - if (c_start + c_len> intf->len) >> + if (c_start + c_len> GET_C_STRUCT(interface)->len) >> caml_invalid_argument("len invalid"); >> >> - memcpy(intf->addr + c_start, (char *) data, c_len); >> + memcpy(GET_C_STRUCT(interface)->addr + c_start, (char *) data, c_len); >> >> CAMLreturn(Val_unit); >> } _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel From xen-devel-bounces@lists.xensource.com Fri Sep 30 11:03:49 2011 Return-path: <xen-devel-bounces@lists.xensource.com> Envelope-to: www-data@lists.xensource.com Delivery-date: Fri, 30 Sep 2011 11:03:49 -0700 Received: from localhost ([127.0.0.1] helo=lists.colo.xensource.com) by lists.xensource.com with esmtp (Exim 4.43) id 1R9hR6-0002uJ-Jg; Fri, 30 Sep 2011 11:03:48 -0700 Received: from mail21.messagelabs.com ([85.158.143.35]) by lists.xensource.com with smtp (Exim 4.43) id 1R9hN1-0002eY-Kc for xen-devel@lists.xensource.com; Fri, 30 Sep 2011 10:59:49 -0700 X-Env-Sender: stefan.bader@canonical.com X-Msg-Ref: server-11.tower-21.messagelabs.com!1317405554!44653518!1 X-Originating-IP: [91.189.89.112] X-StarScan-Version: 6.4.1; banners=-,-,- X-VirusChecked: Checked Received: (qmail 32563 invoked from network); 30 Sep 2011 17:59:14 -0000 Received: from youngberry.canonical.com (HELO youngberry.canonical.com) (91.189.89.112) by server-11.tower-21.messagelabs.com with SMTP; 30 Sep 2011 17:59:14 -0000 Received: from p5b2e4fdc.dip.t-dialin.net ([91.46.79.220] helo=[192.168.2.5]) by youngberry.canonical.com with esmtpsa (TLS1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.71) (envelope-from <stefan.bader@canonical.com>) id 1R9hMy-00031d-An; Fri, 30 Sep 2011 17:59:32 +0000 Message-ID: <4E860382.7040108@canonical.com> Date: Fri, 30 Sep 2011 19:59:30 +0200 From: Stefan Bader <stefan.bader@canonical.com> User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.2.23) Gecko/20110922 Lightning/1.0b2 Thunderbird/3.1.15 MIME-Version: 1.0 To: Stefano Stabellini <stefano.stabellini@eu.citrix.com> Subject: Re: [Xen-devel] Re: Still struggling with HVM: tx timeouts on emulated nics References: <4E7B4768.8060103@canonical.com> <alpine.DEB.2.00.1109221838370.8700@kaball-desktop> <4E85883C.7030808@canonical.com> <alpine.DEB.2.00.1109301427590.3519@kaball-desktop> <4E85E8E8.2020702@canonical.com> In-Reply-To: <4E85E8E8.2020702@canonical.com> X-Enigmail-Version: 1.1.2 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com> X-BeenThere: xen-devel@lists.xensource.com X-Mailman-Version: 2.1.5 Precedence: list List-Id: Xen developer discussion <xen-devel.lists.xensource.com> List-Unsubscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe> List-Post: <mailto:xen-devel@lists.xensource.com> List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help> List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=subscribe> Sender: xen-devel-bounces@lists.xensource.com Errors-To: xen-devel-bounces@lists.xensource.com On 30.09.2011 18:06, Stefan Bader wrote: > On 30.09.2011 16:09, Stefano Stabellini wrote: >> @@ -270,6 +271,18 @@ ret_t do_physdev_op(int cmd, XEN_GUEST_H >> if ( !is_hvm_domain(v->domain) || >> domain_pirq_to_irq(v->domain, eoi.irq) > 0 ) >> pirq_guest_eoi(pirq); >> + if ( is_hvm_domain(v->domain) && >> + domain_pirq_to_emuirq(v->domain, eoi.irq) > 0 ) >> + { >> + struct hvm_irq *hvm_irq = &v->domain->arch.hvm_domain.irq; >> + int gsi = domain_pirq_to_emuirq(v->domain, eoi.irq); >> + >> + /* if this is a level irq and count > 0, send another >> + * notification */ >> + if ( gsi >= NR_ISAIRQS /* ISA irqs are edge triggered */ >> + && hvm_irq->gsi_assert_count[gsi] ) >> + send_guest_pirq(v->domain, pirq); >> + } >> spin_unlock(&v->domain->event_lock); >> ret = 0; >> break; > > This hunk looks substantially different from my 4.1.1 based code. There is no > spin_lock acquired. Not sure that could be a reason for the different behaviour, > too. I'll add that spinlock too. > > case PHYSDEVOP_eoi: { > struct physdev_eoi eoi; > ret = -EFAULT; > if ( copy_from_guest(&eoi, arg, 1) != 0 ) > break; > ret = -EINVAL; > if ( eoi.irq >= v->domain->nr_pirqs ) > break; > if ( v->domain->arch.pirq_eoi_map ) > evtchn_unmask(v->domain->pirq_to_evtchn[eoi.irq]); > if ( !is_hvm_domain(v->domain) || > domain_pirq_to_irq(v->domain, eoi.irq) > 0 ) > ret = pirq_guest_eoi(v->domain, eoi.irq); > else > ret = 0; > break; > } > > _______________________________________________ > Xen-devel mailing list > Xen-devel@lists.xensource.com > http://lists.xensource.com/xen-devel Ok, so I had been modifying that hunk to spin_lock(&v->domain->event_lock); if ( v->domain->arch.pirq_eoi_map ) evtchn_unmask(v->domain->pirq_to_evtchn[eoi.irq]); if ( !is_hvm_domain(v->domain) || domain_pirq_to_irq(v->domain, eoi.irq) > 0 ) pirq_guest_eoi(v->domain, eoi.irq); if ( is_hvm_domain(v->domain) && domain_pirq_to_emuirq(v->domain, eoi.irq) > 0 ) { struct hvm_irq *hvm_irq = &v->domain->arch.hvm_domain.irq; int gsi = domain_pirq_to_emuirq(v->domain, eoi.irq); /* if this is a level irq and count > 0, send another * notification */ if ( gsi >= NR_ISAIRQS /* ISA irqs are edge triggered */ && hvm_irq->gsi_assert_count[gsi] ) { printk("re-send event for gsi%i\n", gsi); send_guest_pirq(v->domain, eoi.irq); } } spin_unlock(&v->domain->event_lock); ret = 0; Also I did not completely remove the section that would return the status without setting needsEOI. I just changed the if condition to be <0 instead of <=0 (I knew from the tests that the mapping was always 0 and maybe the <0 check could be useful for something. irq_status_query.flags = 0; if ( is_hvm_domain(v->domain) && domain_pirq_to_irq(v->domain, irq) < 0 ) { ret = copy_to_guest(arg, &irq_status_query, 1) ? -EFAULT : 0; break; } With that a quick test shows both the re-sends done sometimes and the domU doing EOIs. And there is no stall apparent. Did the same quick test with the e1000 emulated NIC and that still seems ok. Those were not very thorough tests but at least I would have observed a stall pretty quick otherwise. -Stefan _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel From xen-devel-bounces@lists.xensource.com Fri Sep 30 11:51:11 2011 Return-path: <xen-devel-bounces@lists.xensource.com> Envelope-to: www-data@lists.xensource.com Delivery-date: Fri, 30 Sep 2011 11:51:11 -0700 Received: from localhost ([127.0.0.1] helo=lists.colo.xensource.com) by lists.xensource.com with esmtp (Exim 4.43) id 1R9iAx-0004GN-9O; Fri, 30 Sep 2011 11:51:11 -0700 Received: from mail216.messagelabs.com ([85.158.143.99]) by lists.xensource.com with esmtp (Exim 4.43) id 1R9iAD-000444-88 for xen-devel@lists.xensource.com; Fri, 30 Sep 2011 11:50:25 -0700 X-Env-Sender: Ian.Jackson@eu.citrix.com X-Msg-Ref: server-12.tower-216.messagelabs.com!1317408622!14442518!1 X-Originating-IP: [62.200.22.115] X-StarScan-Version: 6.4.1; banners=-,-,- X-VirusChecked: Checked Received: (qmail 17117 invoked from network); 30 Sep 2011 18:50:22 -0000 Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115) by server-12.tower-216.messagelabs.com with RC4-SHA encrypted SMTP; 30 Sep 2011 18:50:22 -0000 X-IronPort-AV: E=Sophos;i="4.68,468,1312156800"; d="scan'208";a="8159504" Received: from lonpmailmx01.citrite.net ([10.30.203.162]) by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5; 30 Sep 2011 18:50:22 +0000 Received: from norwich.cam.xci-test.com (10.80.248.129) by smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id 8.3.137.0; Fri, 30 Sep 2011 19:50:22 +0100 Received: from [10.80.248.135] (helo=woking.xci-test.com) by norwich.cam.xci-test.com with esmtp (Exim 4.72) (envelope-from <ian.jackson@eu.citrix.com>) id 1R9iA9-00079Q-L0; Fri, 30 Sep 2011 18:50:21 +0000 Received: from osstest by woking.xci-test.com with local (Exim 4.69) (envelope-from <ian.jackson@eu.citrix.com>) id 1R9iA9-0007ai-GY; Fri, 30 Sep 2011 19:50:21 +0100 To: xen-devel@lists.xensource.com Message-ID: <osstest-9163-mainreport@xen.org> From: xen.org <ian.jackson@eu.citrix.com> Date: Fri, 30 Sep 2011 19:50:21 +0100 MIME-Version: 1.0 Content-Type: text/plain Cc: ian.jackson@eu.citrix.com Subject: [Xen-devel] [xen-unstable test] 9163: regressions - FAIL X-BeenThere: xen-devel@lists.xensource.com X-Mailman-Version: 2.1.5 Precedence: list List-Id: Xen developer discussion <xen-devel.lists.xensource.com> List-Unsubscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe> List-Post: <mailto:xen-devel@lists.xensource.com> List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help> List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=subscribe> Sender: xen-devel-bounces@lists.xensource.com Errors-To: xen-devel-bounces@lists.xensource.com flight 9163 xen-unstable real [real] http://www.chiark.greenend.org.uk/~xensrcts/logs/9163/ Regressions :-( Tests which did not succeed and are blocking: test-amd64-amd64-xl-pcipt-intel 8 debian-fixup fail REGR. vs. 9118 test-amd64-i386-xl-multivcpu 9 guest-start fail REGR. vs. 9118 test-amd64-i386-xl 9 guest-start fail REGR. vs. 9118 test-amd64-i386-xl-credit2 9 guest-start fail REGR. vs. 9118 test-amd64-i386-rhel6hvm-intel 7 redhat-install fail REGR. vs. 9118 test-i386-i386-xl 9 guest-start fail REGR. vs. 9118 test-amd64-amd64-xl-sedf 9 guest-start fail REGR. vs. 9118 test-amd64-amd64-xl 9 guest-start fail REGR. vs. 9118 test-amd64-i386-rhel6hvm-amd 7 redhat-install fail REGR. vs. 9118 test-amd64-i386-xl-win-vcpus1 7 windows-install fail REGR. vs. 9118 test-amd64-amd64-xl-win 7 windows-install fail REGR. vs. 9118 test-i386-i386-xl-win 7 windows-install fail REGR. vs. 9118 Tests which did not succeed, but are not blocking, including regressions (tests previously passed) regarded as allowable: test-amd64-i386-win-vcpus1 16 leak-check/check fail never pass test-amd64-i386-win 16 leak-check/check fail never pass test-amd64-amd64-win 16 leak-check/check fail never pass test-i386-i386-win 16 leak-check/check fail never pass version targeted for testing: xen e78cd03b0308 baseline version: xen 7998217630e2 ------------------------------------------------------------ People who touched revisions under test: Adin Scannell <adin@scannell.ca> Anthony PERARD <anthony.perard@citrix.com> Ian Campbell <ian.campbell@citrix.com> Ian Jackson <ian.jackson.citrix.com> Ian Jackson <ian.jackson@eu.citrix.com> Olaf Hering <olaf@aepfle.de> ------------------------------------------------------------ jobs: build-amd64 pass build-i386 pass build-amd64-oldkern pass build-i386-oldkern pass build-amd64-pvops pass build-i386-pvops pass test-amd64-amd64-xl fail test-amd64-i386-xl fail test-i386-i386-xl fail test-amd64-i386-rhel6hvm-amd fail test-amd64-i386-xl-credit2 fail test-amd64-amd64-xl-pcipt-intel fail test-amd64-i386-rhel6hvm-intel fail test-amd64-i386-xl-multivcpu fail test-amd64-amd64-pair pass test-amd64-i386-pair pass test-i386-i386-pair pass test-amd64-amd64-pv pass test-amd64-i386-pv pass test-i386-i386-pv pass test-amd64-amd64-xl-sedf fail test-amd64-i386-win-vcpus1 fail test-amd64-i386-xl-win-vcpus1 fail test-amd64-amd64-win fail test-amd64-i386-win fail test-i386-i386-win fail test-amd64-amd64-xl-win fail test-i386-i386-xl-win fail ------------------------------------------------------------ sg-report-flight on woking.cam.xci-test.com logs: /home/xc_osstest/logs images: /home/xc_osstest/images Logs, config files, etc. are available at http://www.chiark.greenend.org.uk/~xensrcts/logs Test harness code can be found at http://xenbits.xensource.com/gitweb?p=osstest.git;a=summary Not pushing. ------------------------------------------------------------ changeset: 23894:e78cd03b0308 tag: tip user: Anthony PERARD <anthony.perard@citrix.com> date: Thu Sep 29 16:31:24 2011 +0100 libxl: libxl_qmp: use of libxl__fd_set_cloexec. Signed-off-by: Anthony PERARD <anthony.perard@citrix.com> Acked-by: Ian Jackson <ian.jackson@eu.citrix.com> Committed-by: Ian Jackson <ian.jackson@eu.citrix.com> changeset: 23893:95a40ee93806 user: Anthony PERARD <anthony.perard@citrix.com> date: Thu Sep 29 16:30:54 2011 +0100 libxl: Introduce a QMP client QMP stands for QEMU Monitor Protocol and it is used to query information from QEMU or to control QEMU. This implementation will ask QEMU the list of chardevice and store the path to serial ports in xenstored. So we will be able to use xl console with QEMU upstream. In order to connect to the QMP server, a socket file is created in /var/run/xen/qmp-libxl-$(domid). Signed-off-by: Anthony PERARD <anthony.perard@citrix.com> Committed-by: Ian Jackson <ian.jackson@eu.citrix.com> changeset: 23892:5f397994e6d6 user: Anthony PERARD <anthony.perard@citrix.com> date: Thu Sep 29 16:28:24 2011 +0100 libxl: Introduce JSON parser We use the yajl parser, but we need to make a tree from the parse result to use it outside the parser. So this patch include json_object struct that is used to hold the JSON data. Signed-off-by: Anthony PERARD <anthony.perard@citrix.com> Committed-by: Ian Jackson <ian.jackson.citrix.com> Acked-by: Ian Campbell <ian.campbell@citrix.com> changeset: 23891:066dc3758fa4 user: Anthony PERARD <anthony.perard@citrix.com> date: Thu Sep 29 16:28:23 2011 +0100 libxl: Intruduce libxl__strndup. Signed-off-by: Anthony PERARD <anthony.perard@citrix.com> Committed-by: Ian Jackson <ian.jackson.citrix.com> Acked-by: Ian Campbell <ian.campbell@citrix.com> changeset: 23890:952e0118a7c4 user: Anthony PERARD <anthony.perard@citrix.com> date: Thu Sep 29 16:28:22 2011 +0100 libxl: Introduce libxl__realloc. Signed-off-by: Anthony PERARD <anthony.perard@citrix.com> Committed-by: Ian Jackson <ian.jackson.citrix.com> Acked-by: Ian Campbell <ian.campbell@citrix.com> changeset: 23889:f51dcd8acb7b user: Anthony PERARD <anthony.perard@citrix.com> date: Thu Sep 29 16:28:22 2011 +0100 libxl: Introduce libxl_internal_types.idl. Signed-off-by: Anthony PERARD <anthony.perard@citrix.com> Committed-by: Ian Jackson <ian.jackson.citrix.com> Acked-by: Ian Campbell <ian.campbell@citrix.com> changeset: 23888:f5ee5ad45425 user: Anthony PERARD <anthony.perard@citrix.com> date: Thu Sep 29 16:28:21 2011 +0100 libxl: Add get/set_default_namespace in libxltypes.py. Signed-off-by: Anthony PERARD <anthony.perard@citrix.com> Committed-by: Ian Jackson <ian.jackson.citrix.com> Acked-by: Ian Campbell <ian.campbell@citrix.com> changeset: 23887:a543e10211f7 user: Anthony PERARD <anthony.perard@citrix.com> date: Thu Sep 29 16:28:20 2011 +0100 libxl: Rename libxl.idl to libxl_types.idl. Signed-off-by: Anthony PERARD <anthony.perard@citrix.com> Committed-by: Ian Jackson <ian.jackson.citrix.com> Acked-by: Ian Campbell <ian.campbell@citrix.com> changeset: 23886:cf2ba5720151 user: Anthony PERARD <anthony.perard@citrix.com> date: Thu Sep 29 16:06:02 2011 +0100 libxl: Introduce libxl__fd_set_cloexec Signed-off-by: Anthony PERARD <anthony.perard@citrix.com> Acked-by: Ian Jackson <ian.jackson@eu.citrix.com> Committed-by: Ian Jackson <ian.jackson@eu.citrix.com> changeset: 23885:cd60c87d3496 user: Ian Campbell <ian.campbell@citrix.com> date: Thu Sep 29 15:40:34 2011 +0100 xl: fixup command line handling for several commands. def_getopt already checks for a minimum number of arguments for us. "xl save" simply need to use the correct argument for that value, contrary to the change I made in 23876:b113d626cfaf "xl block-list" does not need to check for at least 2 arguments, since it's already been done by def_getopt. "xl network-list" would previous accept zero arguments and just print the table header. Insist on a domain argument. Signed-off-by: Ian Campbell <ian.campbell@citrix.com> Acked-by: Ian Jackson <ian.jackson@eu.citrix.com> Committed-by: Ian Jackson <ian.jackson@eu.citrix.com> changeset: 23884:145e146876b3 user: Adin Scannell <adin@gridcentric.com> date: Thu Sep 29 15:26:04 2011 +0100 libxl: Expose number of shared pages Signed-off-by: Adin Scannell <adin@scannell.ca> Acked-by: Ian Jackson <ian.jackson@eu.citrix.com> Committed-by: Ian Jackson <ian.jackson@eu.citrix.com> changeset: 23883:7998217630e2 user: Ian Campbell <ian.campbell@citrix.com> date: Wed Sep 28 16:42:11 2011 +0100 libxl: attempt to cleanup tapdisk processes on disk backend destroy. Signed-off-by: Ian Campbell <ian.campbell@citrix.com> Committed-by: Ian Jackson <ian.jackson@eu.citrix.com> ======================================== commit cd776ee9408ff127f934a707c1a339ee600bc127 Author: Ian Jackson <ian.jackson@eu.citrix.com> Date: Tue Jun 28 13:50:53 2011 +0100 qemu-char.c: fix incorrect CONFIG_STUBDOM handling qemu-char.c:1123:7: warning: "CONFIG_STUBDOM" is not defined [-Wundef] Signed-off-by: Olaf Hering <olaf@aepfle.de> Acked-by: Ian Jackson <ian.jackson@eu.citrix.com> _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel From xen-devel-bounces@lists.xensource.com Fri Sep 30 12:40:52 2011 Return-path: <xen-devel-bounces@lists.xensource.com> Envelope-to: www-data@lists.xensource.com Delivery-date: Fri, 30 Sep 2011 12:40:52 -0700 Received: from localhost ([127.0.0.1] helo=lists.colo.xensource.com) by lists.xensource.com with esmtp (Exim 4.43) id 1R9ix1-0006qN-V6; Fri, 30 Sep 2011 12:40:51 -0700 Received: from mail182.messagelabs.com ([85.158.139.83]) by lists.xensource.com with esmtp (Exim 4.43) id 1R9iwE-0006aX-92 for xen-devel@lists.xensource.com; Fri, 30 Sep 2011 12:40:03 -0700 X-Env-Sender: keir.xen@gmail.com X-Msg-Ref: server-15.tower-182.messagelabs.com!1317411597!19398224!1 X-Originating-IP: [209.85.218.43] X-StarScan-Version: 6.4.1; banners=-,-,- X-VirusChecked: Checked Received: (qmail 15269 invoked from network); 30 Sep 2011 19:39:58 -0000 Received: from mail-yi0-f43.google.com (HELO mail-yi0-f43.google.com) (209.85.218.43) by server-15.tower-182.messagelabs.com with RC4-SHA encrypted SMTP; 30 Sep 2011 19:39:58 -0000 Received: by yib17 with SMTP id 17so3132143yib.30 for <xen-devel@lists.xensource.com>; Fri, 30 Sep 2011 12:39:57 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=user-agent:date:subject:from:to:cc:message-id:thread-topic :thread-index:in-reply-to:mime-version:content-type; bh=CdBlXizWwcc8c3dAD21w/1+yjXS+2+6MoQS4+hslgx0=; b=PrKFWynUnMNXIkq+2bCWZdVXhLLHLiKb3yegamNrElZF0pMHw8PYSQh2iccG7kA+du gvDK8GAhaEM1aHs69gbTyvPkshT5ITHVN/3MSGZV8FPnzRT/VfpTZFVWKAy1rfBs+R+R HTuvq2j+vSKO1Pd/E4o+f7G0/JTIWvK1/A6XQ= Received: by 10.236.76.136 with SMTP id b8mr59976297yhe.9.1317411596470; Fri, 30 Sep 2011 12:39:56 -0700 (PDT) Received: from [192.168.0.100] ([142.103.56.220]) by mx.google.com with ESMTPS id p68sm7588226yhj.16.2011.09.30.12.39.53 (version=SSLv3 cipher=OTHER); Fri, 30 Sep 2011 12:39:55 -0700 (PDT) User-Agent: Microsoft-Entourage/12.30.0.110427 Date: Fri, 30 Sep 2011 12:39:49 -0700 Subject: Re: [Xen-devel] [PATCH 0/2] enable event channel wake-up for mem_event interfaces From: Keir Fraser <keir.xen@gmail.com> To: Adin Scannell <adin@gridcentric.com>, <xen-devel@lists.xensource.com> Message-ID: <CAAB6917.2210C%keir.xen@gmail.com> Thread-Topic: [Xen-devel] [PATCH 0/2] enable event channel wake-up for mem_event interfaces Thread-Index: Acx+swtBFoXOYffjI0md8opwEL2aZwA9avWm In-Reply-To: <CAA9CCEA.21D3C%keir.xen@gmail.com> Mime-version: 1.0 Content-type: multipart/mixed; boundary="B_3400231193_37149688" Cc: Tim Deegan <tim@xen.org> X-BeenThere: xen-devel@lists.xensource.com X-Mailman-Version: 2.1.5 Precedence: list List-Id: Xen developer discussion <xen-devel.lists.xensource.com> List-Unsubscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe> List-Post: <mailto:xen-devel@lists.xensource.com> List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help> List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=subscribe> Sender: xen-devel-bounces@lists.xensource.com Errors-To: xen-devel-bounces@lists.xensource.com > This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. --B_3400231193_37149688 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit On 29/09/2011 07:21, "Keir Fraser" <keir.xen@gmail.com> wrote: > On 28/09/2011 14:22, "Adin Scannell" <adin@gridcentric.com> wrote: > >> Currently the mem_event code requires a domctl to kick the hypervisor >> and unpause vcpus. An event channel is used to notify dom0 of >> requests placed in the ring, and it can similarly be used to notify >> Xen, so as not to overuse domctls when running many domains with >> mem_event interfaces (domctls are not a great interface for this sort >> of thing, because they will all be serialized). >> >> This patch set enables the use of the event channel to signal when a >> response in placed in a mem_event ring. > > I don't have an opinion on patch 1/2. I'll leave it to someone else, like > Tim, to comment. > > Patch 2/2 I don't mind the principle, but the implementation is not very > scalable. I will post a rewritten version to the list. It might be early > next week before I do so. I've attached it. Let me know how it works for you. -- Keir > > -- Keir > >> The two patches are as follows: >> - The first patch tweaks the memevent code to ensure that no events >> are lost. Instead of calling get_response once per kick, we may have >> to pull out multiple events at a time. This doesn't affect normal >> operation with the domctls. >> This patch also ensures that each vCPU can generate a request in each >> mem_event ring (i.e. put_request will always work), by appropriately >> pausing vCPUs when after requests are placed. >> - The second patch breaks the Xen-side event channel handling into a >> new arch-specific file "events.c", and adds cases for the different >> Xen-handled event channels. This formalizes the tiny exception that >> was in place for just qemu in event_channel.c. >> >> All the domctls are still in place and everything should be backwards >> compatible. >> >> Cheers, >> -Adin >> >> _______________________________________________ >> Xen-devel mailing list >> Xen-devel@lists.xensource.com >> http://lists.xensource.com/xen-devel > > --B_3400231193_37149688 Content-type: application/octet-stream; name="00-evtchn-xen" Content-disposition: attachment; filename="00-evtchn-xen" Content-transfer-encoding: base64 ZGlmZiAtciBhZGU0NGJlNWI5MzYgeGVuL2FyY2gvaWE2NC92bXgvdm14X2luaXQuYwotLS0g YS94ZW4vYXJjaC9pYTY0L3ZteC92bXhfaW5pdC5jCVR1ZSBTZXAgMjcgMTY6MTU6MDkgMjAx MSArMDEwMAorKysgYi94ZW4vYXJjaC9pYTY0L3ZteC92bXhfaW5pdC5jCUZyaSBTZXAgMzAg MjA6Mzc6MDIgMjAxMSArMDEwMApAQCAtMzc3LDcgKzM3Nyw3IEBAIHZteF92Y3B1X2luaXRp YWxpc2Uoc3RydWN0IHZjcHUgKnYpCiB7CiAJc3RydWN0IHZteF9pb3JlcV9wYWdlICppb3Jw ID0gJnYtPmRvbWFpbi0+YXJjaC5odm1fZG9tYWluLmlvcmVxOwogCi0JaW50IHJjID0gYWxs b2NfdW5ib3VuZF94ZW5fZXZlbnRfY2hhbm5lbCh2LCAwKTsKKwlpbnQgcmMgPSBhbGxvY191 bmJvdW5kX3hlbl9ldmVudF9jaGFubmVsKHYsIDAsIE5VTEwpOwogCWlmIChyYyA8IDApCiAJ CXJldHVybiByYzsKIAl2LT5hcmNoLmFyY2hfdm14Lnhlbl9wb3J0ID0gcmM7CmRpZmYgLXIg YWRlNDRiZTViOTM2IHhlbi9hcmNoL3g4Ni9odm0vaHZtLmMKLS0tIGEveGVuL2FyY2gveDg2 L2h2bS9odm0uYwlUdWUgU2VwIDI3IDE2OjE1OjA5IDIwMTEgKzAxMDAKKysrIGIveGVuL2Fy Y2gveDg2L2h2bS9odm0uYwlGcmkgU2VwIDMwIDIwOjM3OjAyIDIwMTEgKzAxMDAKQEAgLTk3 MCw3ICs5NzAsNyBAQCBpbnQgaHZtX3ZjcHVfaW5pdGlhbGlzZShzdHJ1Y3QgdmNwdSAqdikK ICAgICAgICAgZ290byBmYWlsMzsKIAogICAgIC8qIENyZWF0ZSBpb3JlcSBldmVudCBjaGFu bmVsLiAqLwotICAgIHJjID0gYWxsb2NfdW5ib3VuZF94ZW5fZXZlbnRfY2hhbm5lbCh2LCAw KTsKKyAgICByYyA9IGFsbG9jX3VuYm91bmRfeGVuX2V2ZW50X2NoYW5uZWwodiwgMCwgTlVM TCk7CiAgICAgaWYgKCByYyA8IDAgKQogICAgICAgICBnb3RvIGZhaWw0OwogCkBAIC0zNDc3 LDcgKzM0NzcsOCBAQCBsb25nIGRvX2h2bV9vcCh1bnNpZ25lZCBsb25nIG9wLCBYRU5fR1VF CiAgICAgICAgICAgICAgICAgZm9yX2VhY2hfdmNwdSAoIGQsIHYgKQogICAgICAgICAgICAg ICAgIHsKICAgICAgICAgICAgICAgICAgICAgaW50IG9sZF9wb3J0LCBuZXdfcG9ydDsKLSAg ICAgICAgICAgICAgICAgICAgbmV3X3BvcnQgPSBhbGxvY191bmJvdW5kX3hlbl9ldmVudF9j aGFubmVsKHYsIGEudmFsdWUpOworICAgICAgICAgICAgICAgICAgICBuZXdfcG9ydCA9IGFs bG9jX3VuYm91bmRfeGVuX2V2ZW50X2NoYW5uZWwoCisgICAgICAgICAgICAgICAgICAgICAg ICB2LCBhLnZhbHVlLCBOVUxMKTsKICAgICAgICAgICAgICAgICAgICAgaWYgKCBuZXdfcG9y dCA8IDAgKQogICAgICAgICAgICAgICAgICAgICB7CiAgICAgICAgICAgICAgICAgICAgICAg ICByYyA9IG5ld19wb3J0OwpkaWZmIC1yIGFkZTQ0YmU1YjkzNiB4ZW4vYXJjaC94ODYvbW0v bWVtX2FjY2Vzcy5jCi0tLSBhL3hlbi9hcmNoL3g4Ni9tbS9tZW1fYWNjZXNzLmMJVHVlIFNl cCAyNyAxNjoxNTowOSAyMDExICswMTAwCisrKyBiL3hlbi9hcmNoL3g4Ni9tbS9tZW1fYWNj ZXNzLmMJRnJpIFNlcCAzMCAyMDozNzowMiAyMDExICswMTAwCkBAIC0yOSwxMyArMjksMTIg QEAgaW50IG1lbV9hY2Nlc3NfZG9tY3RsKHN0cnVjdCBkb21haW4gKmQsIAogICAgICAgICAg ICAgICAgICAgICAgIFhFTl9HVUVTVF9IQU5ETEUodm9pZCkgdV9kb21jdGwpCiB7CiAgICAg aW50IHJjOwotICAgIHN0cnVjdCBwMm1fZG9tYWluICpwMm0gPSBwMm1fZ2V0X2hvc3RwMm0o ZCk7CiAKICAgICBzd2l0Y2goIG1lYy0+b3AgKQogICAgIHsKICAgICBjYXNlIFhFTl9ET01D VExfTUVNX0VWRU5UX09QX0FDQ0VTU19SRVNVTUU6CiAgICAgewotICAgICAgICBwMm1fbWVt X2FjY2Vzc19yZXN1bWUocDJtKTsKKyAgICAgICAgcDJtX21lbV9hY2Nlc3NfcmVzdW1lKGQp OwogICAgICAgICByYyA9IDA7CiAgICAgfQogICAgIGJyZWFrOwpkaWZmIC1yIGFkZTQ0YmU1 YjkzNiB4ZW4vYXJjaC94ODYvbW0vbWVtX2V2ZW50LmMKLS0tIGEveGVuL2FyY2gveDg2L21t L21lbV9ldmVudC5jCVR1ZSBTZXAgMjcgMTY6MTU6MDkgMjAxMSArMDEwMAorKysgYi94ZW4v YXJjaC94ODYvbW0vbWVtX2V2ZW50LmMJRnJpIFNlcCAzMCAyMDozNzowMiAyMDExICswMTAw CkBAIC0zNyw5ICszNywxMSBAQAogI2RlZmluZSBtZW1fZXZlbnRfcmluZ19sb2NrKF9tZWQp ICAgICAgIHNwaW5fbG9jaygmKF9tZWQpLT5yaW5nX2xvY2spCiAjZGVmaW5lIG1lbV9ldmVu dF9yaW5nX3VubG9jayhfbWVkKSAgICAgc3Bpbl91bmxvY2soJihfbWVkKS0+cmluZ19sb2Nr KQogCi1zdGF0aWMgaW50IG1lbV9ldmVudF9lbmFibGUoc3RydWN0IGRvbWFpbiAqZCwKLSAg ICAgICAgICAgICAgICAgICAgICAgICAgICB4ZW5fZG9tY3RsX21lbV9ldmVudF9vcF90ICpt ZWMsCi0gICAgICAgICAgICAgICAgICAgICAgICAgICAgc3RydWN0IG1lbV9ldmVudF9kb21h aW4gKm1lZCkKK3N0YXRpYyBpbnQgbWVtX2V2ZW50X2VuYWJsZSgKKyAgICBzdHJ1Y3QgZG9t YWluICpkLAorICAgIHhlbl9kb21jdGxfbWVtX2V2ZW50X29wX3QgKm1lYywKKyAgICBzdHJ1 Y3QgbWVtX2V2ZW50X2RvbWFpbiAqbWVkLAorICAgIHhlbl9ldmVudF9jaGFubmVsX25vdGlm aWNhdGlvbl90IG5vdGlmaWNhdGlvbl9mbikKIHsKICAgICBpbnQgcmM7CiAgICAgc3RydWN0 IGRvbWFpbiAqZG9tX21lbV9ldmVudCA9IGN1cnJlbnQtPmRvbWFpbjsKQEAgLTc5LDggKzgx LDggQEAgc3RhdGljIGludCBtZW1fZXZlbnRfZW5hYmxlKHN0cnVjdCBkb21haQogICAgIG1l ZC0+c2hhcmVkX3BhZ2UgPSBtYXBfZG9tYWluX3BhZ2UobWZuX3goc2hhcmVkX21mbikpOwog CiAgICAgLyogQWxsb2NhdGUgZXZlbnQgY2hhbm5lbCAqLwotICAgIHJjID0gYWxsb2NfdW5i b3VuZF94ZW5fZXZlbnRfY2hhbm5lbChkLT52Y3B1WzBdLAotICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICBjdXJyZW50LT5kb21haW4tPmRvbWFpbl9pZCk7Cisg ICAgcmMgPSBhbGxvY191bmJvdW5kX3hlbl9ldmVudF9jaGFubmVsKAorICAgICAgICBkLT52 Y3B1WzBdLCBjdXJyZW50LT5kb21haW4tPmRvbWFpbl9pZCwgbm90aWZpY2F0aW9uX2ZuKTsK ICAgICBpZiAoIHJjIDwgMCApCiAgICAgICAgIGdvdG8gZXJyOwogCkBAIC0yMTMsNiArMjE1 LDE4IEBAIGludCBtZW1fZXZlbnRfY2hlY2tfcmluZyhzdHJ1Y3QgZG9tYWluICoKICAgICBy ZXR1cm4gcmluZ19mdWxsOwogfQogCisvKiBSZWdpc3RlcmVkIHdpdGggWGVuLWJvdW5kIGV2 ZW50IGNoYW5uZWwgZm9yIGluY29taW5nIG5vdGlmaWNhdGlvbnMuICovCitzdGF0aWMgdm9p ZCBtZW1fcGFnaW5nX25vdGlmaWNhdGlvbihzdHJ1Y3QgdmNwdSAqdiwgdW5zaWduZWQgaW50 IHBvcnQpCit7CisgICAgcDJtX21lbV9wYWdpbmdfcmVzdW1lKHYtPmRvbWFpbik7Cit9CisK Ky8qIFJlZ2lzdGVyZWQgd2l0aCBYZW4tYm91bmQgZXZlbnQgY2hhbm5lbCBmb3IgaW5jb21p bmcgbm90aWZpY2F0aW9ucy4gKi8KK3N0YXRpYyB2b2lkIG1lbV9hY2Nlc3Nfbm90aWZpY2F0 aW9uKHN0cnVjdCB2Y3B1ICp2LCB1bnNpZ25lZCBpbnQgcG9ydCkKK3sKKyAgICBwMm1fbWVt X2FjY2Vzc19yZXN1bWUodi0+ZG9tYWluKTsKK30KKwogaW50IG1lbV9ldmVudF9kb21jdGwo c3RydWN0IGRvbWFpbiAqZCwgeGVuX2RvbWN0bF9tZW1fZXZlbnRfb3BfdCAqbWVjLAogICAg ICAgICAgICAgICAgICAgICAgWEVOX0dVRVNUX0hBTkRMRSh2b2lkKSB1X2RvbWN0bCkKIHsK QEAgLTI2Niw3ICsyODAsNyBAQCBpbnQgbWVtX2V2ZW50X2RvbWN0bChzdHJ1Y3QgZG9tYWlu ICpkLCB4CiAgICAgICAgIHsKICAgICAgICAgY2FzZSBYRU5fRE9NQ1RMX01FTV9FVkVOVF9P UF9QQUdJTkdfRU5BQkxFOgogICAgICAgICB7Ci0gICAgICAgICAgICByYyA9IG1lbV9ldmVu dF9lbmFibGUoZCwgbWVjLCBtZWQpOworICAgICAgICAgICAgcmMgPSBtZW1fZXZlbnRfZW5h YmxlKGQsIG1lYywgbWVkLCBtZW1fcGFnaW5nX25vdGlmaWNhdGlvbik7CiAgICAgICAgIH0K ICAgICAgICAgYnJlYWs7CiAKQEAgLTMwMiw3ICszMTYsNyBAQCBpbnQgbWVtX2V2ZW50X2Rv bWN0bChzdHJ1Y3QgZG9tYWluICpkLCB4CiAgICAgICAgIHsKICAgICAgICAgY2FzZSBYRU5f RE9NQ1RMX01FTV9FVkVOVF9PUF9BQ0NFU1NfRU5BQkxFOgogICAgICAgICB7Ci0gICAgICAg ICAgICByYyA9IG1lbV9ldmVudF9lbmFibGUoZCwgbWVjLCBtZWQpOworICAgICAgICAgICAg cmMgPSBtZW1fZXZlbnRfZW5hYmxlKGQsIG1lYywgbWVkLCBtZW1fYWNjZXNzX25vdGlmaWNh dGlvbik7CiAgICAgICAgIH0KICAgICAgICAgYnJlYWs7CiAKZGlmZiAtciBhZGU0NGJlNWI5 MzYgeGVuL2FyY2gveDg2L21tL3AybS5jCi0tLSBhL3hlbi9hcmNoL3g4Ni9tbS9wMm0uYwlU dWUgU2VwIDI3IDE2OjE1OjA5IDIwMTEgKzAxMDAKKysrIGIveGVuL2FyY2gveDg2L21tL3Ay bS5jCUZyaSBTZXAgMzAgMjA6Mzc6MDIgMjAxMSArMDEwMApAQCAtOTQzLDkgKzk0Myw4IEBA IHZvaWQgcDJtX21lbV9hY2Nlc3NfY2hlY2sodW5zaWduZWQgbG9uZyAKICAgICAvKiBWQ1BV IHBhdXNlZCwgbWVtIGV2ZW50IHJlcXVlc3Qgc2VudCAqLwogfQogCi12b2lkIHAybV9tZW1f YWNjZXNzX3Jlc3VtZShzdHJ1Y3QgcDJtX2RvbWFpbiAqcDJtKQordm9pZCBwMm1fbWVtX2Fj Y2Vzc19yZXN1bWUoc3RydWN0IGRvbWFpbiAqZCkKIHsKLSAgICBzdHJ1Y3QgZG9tYWluICpk ID0gcDJtLT5kb21haW47CiAgICAgbWVtX2V2ZW50X3Jlc3BvbnNlX3QgcnNwOwogCiAgICAg bWVtX2V2ZW50X2dldF9yZXNwb25zZSgmZC0+bWVtX2FjY2VzcywgJnJzcCk7CmRpZmYgLXIg YWRlNDRiZTViOTM2IHhlbi9jb21tb24vZXZlbnRfY2hhbm5lbC5jCi0tLSBhL3hlbi9jb21t b24vZXZlbnRfY2hhbm5lbC5jCVR1ZSBTZXAgMjcgMTY6MTU6MDkgMjAxMSArMDEwMAorKysg Yi94ZW4vY29tbW9uL2V2ZW50X2NoYW5uZWwuYwlGcmkgU2VwIDMwIDIwOjM3OjAyIDIwMTEg KzAxMDAKQEAgLTU3LDYgKzU3LDUxIEBACiAgICAgICAgIGdvdG8gb3V0OyAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIFwKICAgICB9IHdoaWxl ICggMCApCiAKKyNkZWZpbmUgY29uc3VtZXJfaXNfeGVuKGUpICghIShlKS0+eGVuX2NvbnN1 bWVyKQorCisvKgorICogVGhlIGZ1bmN0aW9uIGFsbG9jX3VuYm91bmRfeGVuX2V2ZW50X2No YW5uZWwoKSBhbGxvd3MgYW4gYXJiaXRyYXJ5CisgKiBub3RpZmllciBmdW5jdGlvbiB0byBi ZSBzcGVjaWZpZWQuIEhvd2V2ZXIsIHZlcnkgZmV3IHVuaXF1ZSBmdW5jdGlvbnMKKyAqIGFy ZSBzcGVjaWZpZWQgaW4gcHJhY3RpY2UsIHNvIHRvIHByZXZlbnQgYmxvYXRpbmcgdGhlIGV2 dGNobiBzdHJ1Y3R1cmUKKyAqIHdpdGggYSBwb2ludGVyLCB3ZSBzdGFzaCB0aGVtIGR5bmFt aWNhbGx5IGluIGEgc21hbGwgbG9va3VwIGFycmF5IHdoaWNoCisgKiBjYW4gYmUgaW5kZXhl ZCBieSBhIHNtYWxsIGludGVnZXIuCisgKi8KK3N0YXRpYyB4ZW5fZXZlbnRfY2hhbm5lbF9u b3RpZmljYXRpb25fdCB4ZW5fY29uc3VtZXJzWzhdOworCisvKiBEZWZhdWx0IG5vdGlmaWNh dGlvbiBhY3Rpb246IHdha2UgdXAgZnJvbSB3YWl0X29uX3hlbl9ldmVudF9jaGFubmVsKCku ICovCitzdGF0aWMgdm9pZCBkZWZhdWx0X3hlbl9ub3RpZmljYXRpb25fZm4oc3RydWN0IHZj cHUgKnYsIHVuc2lnbmVkIGludCBwb3J0KQoreworICAgIC8qIENvbnN1bWVyIG5lZWRzIG5v dGlmaWNhdGlvbiBvbmx5IGlmIGJsb2NrZWQuICovCisgICAgaWYgKCB0ZXN0X2FuZF9jbGVh cl9iaXQoX1ZQRl9ibG9ja2VkX2luX3hlbiwgJnYtPnBhdXNlX2ZsYWdzKSApCisgICAgICAg IHZjcHVfd2FrZSh2KTsKK30KKworLyoKKyAqIEdpdmVuIGEgbm90aWZpY2F0aW9uIGZ1bmN0 aW9uLCByZXR1cm4gdGhlIHZhbHVlIHRvIHN0YXNoIGluCisgKiB0aGUgZXZ0Y2huLT54ZW5f Y29uc3VtZXIgZmllbGQuCisgKi8KK3N0YXRpYyB1aW50OF90IGdldF94ZW5fY29uc3VtZXIo eGVuX2V2ZW50X2NoYW5uZWxfbm90aWZpY2F0aW9uX3QgZm4pCit7CisgICAgdW5zaWduZWQg aW50IGk7CisKKyAgICBpZiAoIGZuID09IE5VTEwgKQorICAgICAgICBmbiA9IGRlZmF1bHRf eGVuX25vdGlmaWNhdGlvbl9mbjsKKworICAgIGZvciAoIGkgPSAwOyBpIDwgQVJSQVlfU0la RSh4ZW5fY29uc3VtZXJzKTsgaSsrICkKKyAgICB7CisgICAgICAgIGlmICggeGVuX2NvbnN1 bWVyc1tpXSA9PSBOVUxMICkKKyAgICAgICAgICAgIHhlbl9jb25zdW1lcnNbaV0gPSBmbjsK KyAgICAgICAgaWYgKCB4ZW5fY29uc3VtZXJzW2ldID09IGZuICkKKyAgICAgICAgICAgIGJy ZWFrOworICAgIH0KKworICAgIEJVR19PTihpID49IEFSUkFZX1NJWkUoeGVuX2NvbnN1bWVy cykpOworICAgIHJldHVybiBpKzE7Cit9CisKKy8qIEdldCB0aGUgbm90aWZpY2F0aW9uIGZ1 bmN0aW9uIGZvciBhIGdpdmVuIFhlbi1ib3VuZCBldmVudCBjaGFubmVsLiAqLworI2RlZmlu ZSB4ZW5fbm90aWZpY2F0aW9uX2ZuKGUpICh4ZW5fY29uc3VtZXJzWyhlKS0+eGVuX2NvbnN1 bWVyLTFdKQorCiBzdGF0aWMgaW50IGV2dGNobl9zZXRfcGVuZGluZyhzdHJ1Y3QgdmNwdSAq diwgaW50IHBvcnQpOwogCiBzdGF0aWMgaW50IHZpcnFfaXNfZ2xvYmFsKGludCB2aXJxKQpA QCAtMzk2LDcgKzQ0MSw3IEBAIHN0YXRpYyBsb25nIF9fZXZ0Y2huX2Nsb3NlKHN0cnVjdCBk b21haW4KICAgICBjaG4xID0gZXZ0Y2huX2Zyb21fcG9ydChkMSwgcG9ydDEpOwogCiAgICAg LyogR3Vlc3QgY2Fubm90IGNsb3NlIGEgWGVuLWF0dGFjaGVkIGV2ZW50IGNoYW5uZWwuICov Ci0gICAgaWYgKCB1bmxpa2VseShjaG4xLT5jb25zdW1lcl9pc194ZW4pICkKKyAgICBpZiAo IHVubGlrZWx5KGNvbnN1bWVyX2lzX3hlbihjaG4xKSkgKQogICAgIHsKICAgICAgICAgcmMg PSAtRUlOVkFMOwogICAgICAgICBnb3RvIG91dDsKQEAgLTUzNCw3ICs1NzksNyBAQCBpbnQg ZXZ0Y2huX3NlbmQoc3RydWN0IGRvbWFpbiAqZCwgdW5zaWduCiAgICAgbGNobiA9IGV2dGNo bl9mcm9tX3BvcnQobGQsIGxwb3J0KTsKIAogICAgIC8qIEd1ZXN0IGNhbm5vdCBzZW5kIHZp YSBhIFhlbi1hdHRhY2hlZCBldmVudCBjaGFubmVsLiAqLwotICAgIGlmICggdW5saWtlbHko bGNobi0+Y29uc3VtZXJfaXNfeGVuKSApCisgICAgaWYgKCB1bmxpa2VseShjb25zdW1lcl9p c194ZW4obGNobikpICkKICAgICB7CiAgICAgICAgIHNwaW5fdW5sb2NrKCZsZC0+ZXZlbnRf bG9jayk7CiAgICAgICAgIHJldHVybiAtRUlOVkFMOwpAQCAtNTUxLDEzICs1OTYsOCBAQCBp bnQgZXZ0Y2huX3NlbmQoc3RydWN0IGRvbWFpbiAqZCwgdW5zaWduCiAgICAgICAgIHJwb3J0 ID0gbGNobi0+dS5pbnRlcmRvbWFpbi5yZW1vdGVfcG9ydDsKICAgICAgICAgcmNobiAgPSBl dnRjaG5fZnJvbV9wb3J0KHJkLCBycG9ydCk7CiAgICAgICAgIHJ2Y3B1ID0gcmQtPnZjcHVb cmNobi0+bm90aWZ5X3ZjcHVfaWRdOwotICAgICAgICBpZiAoIHJjaG4tPmNvbnN1bWVyX2lz X3hlbiApCi0gICAgICAgIHsKLSAgICAgICAgICAgIC8qIFhlbiBjb25zdW1lcnMgbmVlZCBu b3RpZmljYXRpb24gb25seSBpZiB0aGV5IGFyZSBibG9ja2VkLiAqLwotICAgICAgICAgICAg aWYgKCB0ZXN0X2FuZF9jbGVhcl9iaXQoX1ZQRl9ibG9ja2VkX2luX3hlbiwKLSAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICZydmNwdS0+cGF1c2VfZmxhZ3MpICkKLSAg ICAgICAgICAgICAgICB2Y3B1X3dha2UocnZjcHUpOwotICAgICAgICB9CisgICAgICAgIGlm ICggY29uc3VtZXJfaXNfeGVuKHJjaG4pICkKKyAgICAgICAgICAgICgqeGVuX25vdGlmaWNh dGlvbl9mbihyY2huKSkocnZjcHUsIHJwb3J0KTsKICAgICAgICAgZWxzZQogICAgICAgICB7 CiAgICAgICAgICAgICBldnRjaG5fc2V0X3BlbmRpbmcocnZjcHUsIHJwb3J0KTsKQEAgLTc4 NCw3ICs4MjQsNyBAQCBsb25nIGV2dGNobl9iaW5kX3ZjcHUodW5zaWduZWQgaW50IHBvcnQs CiAgICAgY2huID0gZXZ0Y2huX2Zyb21fcG9ydChkLCBwb3J0KTsKIAogICAgIC8qIEd1ZXN0 IGNhbm5vdCByZS1iaW5kIGEgWGVuLWF0dGFjaGVkIGV2ZW50IGNoYW5uZWwuICovCi0gICAg aWYgKCB1bmxpa2VseShjaG4tPmNvbnN1bWVyX2lzX3hlbikgKQorICAgIGlmICggdW5saWtl bHkoY29uc3VtZXJfaXNfeGVuKGNobikpICkKICAgICB7CiAgICAgICAgIHJjID0gLUVJTlZB TDsKICAgICAgICAgZ290byBvdXQ7CkBAIC05OTUsNyArMTAzNSw4IEBAIGxvbmcgZG9fZXZl bnRfY2hhbm5lbF9vcChpbnQgY21kLCBYRU5fR1UKIAogCiBpbnQgYWxsb2NfdW5ib3VuZF94 ZW5fZXZlbnRfY2hhbm5lbCgKLSAgICBzdHJ1Y3QgdmNwdSAqbG9jYWxfdmNwdSwgZG9taWRf dCByZW1vdGVfZG9taWQpCisgICAgc3RydWN0IHZjcHUgKmxvY2FsX3ZjcHUsIGRvbWlkX3Qg cmVtb3RlX2RvbWlkLAorICAgIHhlbl9ldmVudF9jaGFubmVsX25vdGlmaWNhdGlvbl90IG5v dGlmaWNhdGlvbl9mbikKIHsKICAgICBzdHJ1Y3QgZXZ0Y2huICpjaG47CiAgICAgc3RydWN0 IGRvbWFpbiAqZCA9IGxvY2FsX3ZjcHUtPmRvbWFpbjsKQEAgLTEwMDgsNyArMTA0OSw3IEBA IGludCBhbGxvY191bmJvdW5kX3hlbl9ldmVudF9jaGFubmVsKAogICAgIGNobiA9IGV2dGNo bl9mcm9tX3BvcnQoZCwgcG9ydCk7CiAKICAgICBjaG4tPnN0YXRlID0gRUNTX1VOQk9VTkQ7 Ci0gICAgY2huLT5jb25zdW1lcl9pc194ZW4gPSAxOworICAgIGNobi0+eGVuX2NvbnN1bWVy ID0gZ2V0X3hlbl9jb25zdW1lcihub3RpZmljYXRpb25fZm4pOwogICAgIGNobi0+bm90aWZ5 X3ZjcHVfaWQgPSBsb2NhbF92Y3B1LT52Y3B1X2lkOwogICAgIGNobi0+dS51bmJvdW5kLnJl bW90ZV9kb21pZCA9IHJlbW90ZV9kb21pZDsKIApAQCAtMTAzNSw4ICsxMDc2LDggQEAgdm9p ZCBmcmVlX3hlbl9ldmVudF9jaGFubmVsKAogCiAgICAgQlVHX09OKCFwb3J0X2lzX3ZhbGlk KGQsIHBvcnQpKTsKICAgICBjaG4gPSBldnRjaG5fZnJvbV9wb3J0KGQsIHBvcnQpOwotICAg IEJVR19PTighY2huLT5jb25zdW1lcl9pc194ZW4pOwotICAgIGNobi0+Y29uc3VtZXJfaXNf eGVuID0gMDsKKyAgICBCVUdfT04oIWNvbnN1bWVyX2lzX3hlbihjaG4pKTsKKyAgICBjaG4t Pnhlbl9jb25zdW1lciA9IDA7CiAKICAgICBzcGluX3VubG9jaygmZC0+ZXZlbnRfbG9jayk7 CiAKQEAgLTEwNjAsNyArMTEwMSw3IEBAIHZvaWQgbm90aWZ5X3ZpYV94ZW5fZXZlbnRfY2hh bm5lbChzdHJ1Y3QKIAogICAgIEFTU0VSVChwb3J0X2lzX3ZhbGlkKGxkLCBscG9ydCkpOwog ICAgIGxjaG4gPSBldnRjaG5fZnJvbV9wb3J0KGxkLCBscG9ydCk7Ci0gICAgQVNTRVJUKGxj aG4tPmNvbnN1bWVyX2lzX3hlbik7CisgICAgQVNTRVJUKGNvbnN1bWVyX2lzX3hlbihsY2hu KSk7CiAKICAgICBpZiAoIGxpa2VseShsY2huLT5zdGF0ZSA9PSBFQ1NfSU5URVJET01BSU4p ICkKICAgICB7CkBAIC0xMTAzLDcgKzExNDQsNyBAQCB2b2lkIGV2dGNobl9kZXN0cm95KHN0 cnVjdCBkb21haW4gKmQpCiAgICAgLyogQ2xvc2UgYWxsIGV4aXN0aW5nIGV2ZW50IGNoYW5u ZWxzLiAqLwogICAgIGZvciAoIGkgPSAwOyBwb3J0X2lzX3ZhbGlkKGQsIGkpOyBpKysgKQog ICAgIHsKLSAgICAgICAgZXZ0Y2huX2Zyb21fcG9ydChkLCBpKS0+Y29uc3VtZXJfaXNfeGVu ID0gMDsKKyAgICAgICAgZXZ0Y2huX2Zyb21fcG9ydChkLCBpKS0+eGVuX2NvbnN1bWVyID0g MDsKICAgICAgICAgKHZvaWQpX19ldnRjaG5fY2xvc2UoZCwgaSk7CiAgICAgfQogCkBAIC0x MTg5LDcgKzEyMzAsNyBAQCBzdGF0aWMgdm9pZCBkb21haW5fZHVtcF9ldnRjaG5faW5mbyhz dHJ1CiAgICAgICAgICAgICBwcmludGsoIiB2PSVkIiwgY2huLT51LnZpcnEpOwogICAgICAg ICAgICAgYnJlYWs7CiAgICAgICAgIH0KLSAgICAgICAgcHJpbnRrKCIgeD0lZFxuIiwgY2hu LT5jb25zdW1lcl9pc194ZW4pOworICAgICAgICBwcmludGsoIiB4PSVkXG4iLCBjaG4tPnhl bl9jb25zdW1lcik7CiAgICAgfQogCiAgICAgc3Bpbl91bmxvY2soJmQtPmV2ZW50X2xvY2sp OwpkaWZmIC1yIGFkZTQ0YmU1YjkzNiB4ZW4vaW5jbHVkZS9hc20teDg2L3AybS5oCi0tLSBh L3hlbi9pbmNsdWRlL2FzbS14ODYvcDJtLmgJVHVlIFNlcCAyNyAxNjoxNTowOSAyMDExICsw MTAwCisrKyBiL3hlbi9pbmNsdWRlL2FzbS14ODYvcDJtLmgJRnJpIFNlcCAzMCAyMDozNzow MiAyMDExICswMTAwCkBAIC01MDMsNyArNTAzLDcgQEAgc3RhdGljIGlubGluZSB2b2lkIHAy bV9tZW1fcGFnaW5nX3BvcHVsYQogdm9pZCBwMm1fbWVtX2FjY2Vzc19jaGVjayh1bnNpZ25l ZCBsb25nIGdwYSwgYm9vbF90IGdsYV92YWxpZCwgdW5zaWduZWQgbG9uZyBnbGEsIAogICAg ICAgICAgICAgICAgICAgICAgICAgICBib29sX3QgYWNjZXNzX3IsIGJvb2xfdCBhY2Nlc3Nf dywgYm9vbF90IGFjY2Vzc194KTsKIC8qIFJlc3VtZXMgdGhlIHJ1bm5pbmcgb2YgdGhlIFZD UFUsIHJlc3RhcnRpbmcgdGhlIGxhc3QgaW5zdHJ1Y3Rpb24gKi8KLXZvaWQgcDJtX21lbV9h Y2Nlc3NfcmVzdW1lKHN0cnVjdCBwMm1fZG9tYWluICpwMm0pOwordm9pZCBwMm1fbWVtX2Fj Y2Vzc19yZXN1bWUoc3RydWN0IGRvbWFpbiAqZCk7CiAKIC8qIFNldCBhY2Nlc3MgdHlwZSBm b3IgYSByZWdpb24gb2YgcGZucy4KICAqIElmIHN0YXJ0X3BmbiA9PSAtMXVsLCBzZXRzIHRo ZSBkZWZhdWx0IGFjY2VzcyB0eXBlICovCmRpZmYgLXIgYWRlNDRiZTViOTM2IHhlbi9pbmNs dWRlL3hlbi9ldmVudC5oCi0tLSBhL3hlbi9pbmNsdWRlL3hlbi9ldmVudC5oCVR1ZSBTZXAg MjcgMTY6MTU6MDkgMjAxMSArMDEwMAorKysgYi94ZW4vaW5jbHVkZS94ZW4vZXZlbnQuaAlG cmkgU2VwIDMwIDIwOjM3OjAyIDIwMTEgKzAxMDAKQEAgLTUxLDggKzUxLDExIEBAIGludCBl dnRjaG5fdW5tYXNrKHVuc2lnbmVkIGludCBwb3J0KTsKIHZvaWQgZXZ0Y2huX21vdmVfcGly cXMoc3RydWN0IHZjcHUgKnYpOwogCiAvKiBBbGxvY2F0ZS9mcmVlIGEgWGVuLWF0dGFjaGVk IGV2ZW50IGNoYW5uZWwgcG9ydC4gKi8KK3R5cGVkZWYgdm9pZCAoKnhlbl9ldmVudF9jaGFu bmVsX25vdGlmaWNhdGlvbl90KSgKKyAgICBzdHJ1Y3QgdmNwdSAqdiwgdW5zaWduZWQgaW50 IHBvcnQpOwogaW50IGFsbG9jX3VuYm91bmRfeGVuX2V2ZW50X2NoYW5uZWwoCi0gICAgc3Ry dWN0IHZjcHUgKmxvY2FsX3ZjcHUsIGRvbWlkX3QgcmVtb3RlX2RvbWlkKTsKKyAgICBzdHJ1 Y3QgdmNwdSAqbG9jYWxfdmNwdSwgZG9taWRfdCByZW1vdGVfZG9taWQsCisgICAgeGVuX2V2 ZW50X2NoYW5uZWxfbm90aWZpY2F0aW9uX3Qgbm90aWZpY2F0aW9uX2ZuKTsKIHZvaWQgZnJl ZV94ZW5fZXZlbnRfY2hhbm5lbCgKICAgICBzdHJ1Y3QgdmNwdSAqbG9jYWxfdmNwdSwgaW50 IHBvcnQpOwogCmRpZmYgLXIgYWRlNDRiZTViOTM2IHhlbi9pbmNsdWRlL3hlbi9zY2hlZC5o Ci0tLSBhL3hlbi9pbmNsdWRlL3hlbi9zY2hlZC5oCVR1ZSBTZXAgMjcgMTY6MTU6MDkgMjAx MSArMDEwMAorKysgYi94ZW4vaW5jbHVkZS94ZW4vc2NoZWQuaAlGcmkgU2VwIDMwIDIwOjM3 OjAyIDIwMTEgKzAxMDAKQEAgLTQ3LDcgKzQ3LDcgQEAgc3RydWN0IGV2dGNobgogI2RlZmlu ZSBFQ1NfVklSUSAgICAgICAgIDUgLyogQ2hhbm5lbCBpcyBib3VuZCB0byBhIHZpcnR1YWwg SVJRIGxpbmUuICAgICAgICAqLwogI2RlZmluZSBFQ1NfSVBJICAgICAgICAgIDYgLyogQ2hh bm5lbCBpcyBib3VuZCB0byBhIHZpcnR1YWwgSVBJIGxpbmUuICAgICAgICAq LwogICAgIHU4 ICBzdGF0ZTsgICAgICAgICAgICAgLyogRUNTXyogKi8KLSAgICB1OCAgY29uc3VtZXJfaXNf eGVuOyAgIC8qIENvbnN1bWVkIGJ5IFhlbiBvciBieSBndWVzdD8gKi8KKyAgICB1OCAgeGVu X2NvbnN1bWVyOyAgICAgIC8qIENvbnN1bWVyIGluIFhlbiwgaWYgYW55PyAoMCA9IHNlbmQg dG8gZ3Vlc3QpICovCiAgICAgdTE2IG5vdGlmeV92Y3B1X2lkOyAgICAvKiBWQ1BVIGZvciBs b2NhbCBkZWxpdmVyeSBub3RpZmljYXRpb24gKi8KICAgICB1bmlvbiB7CiAgICAgICAgIHN0 cnVjdCB7Cg== --B_3400231193_37149688 Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel --B_3400231193_37149688-- From xen-devel-bounces@lists.xensource.com Fri Sep 30 13:24:31 2011 Return-path: <xen-devel-bounces@lists.xensource.com> Envelope-to: www-data@lists.xensource.com Delivery-date: Fri, 30 Sep 2011 13:24:31 -0700 Received: from localhost ([127.0.0.1] helo=lists.colo.xensource.com) by lists.xensource.com with esmtp (Exim 4.43) id 1R9jdG-000844-KJ; Fri, 30 Sep 2011 13:24:30 -0700 Received: from mail21.messagelabs.com ([85.158.143.35]) by lists.xensource.com with esmtp (Exim 4.43) id 1R9jcT-0007rV-6Z for xen-devel@lists.xensource.com; Fri, 30 Sep 2011 13:23:42 -0700 X-Env-Sender: keir.xen@gmail.com X-Msg-Ref: server-3.tower-21.messagelabs.com!1317414228!53625538!1 X-Originating-IP: [209.85.213.171] X-StarScan-Version: 6.4.1; banners=-,-,- X-VirusChecked: Checked Received: (qmail 1588 invoked from network); 30 Sep 2011 20:23:49 -0000 Received: from mail-yx0-f171.google.com (HELO mail-yx0-f171.google.com) (209.85.213.171) by server-3.tower-21.messagelabs.com with RC4-SHA encrypted SMTP; 30 Sep 2011 20:23:49 -0000 Received: by yxt3 with SMTP id 3so2947874yxt.30 for <xen-devel@lists.xensource.com>; Fri, 30 Sep 2011 13:23:36 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=user-agent:date:subject:from:to:cc:message-id:thread-topic :thread-index:in-reply-to:mime-version:content-type :content-transfer-encoding; bh=7/U0ATNuJg6kTfBwlvvz6Q9Ef8gOpVNmDxJtYzwfI4U=; b=NN2/T6MZGCcwBj/v0dLCRNI1UU+8PWFxmhcttr2x5MW2lS3IRold4JRHd3mKneGQhm oDLjSpBUZtco2Fig3ff9a0f446acDJWXiVx5XwJsYlhBwH7g5sgy9O4ss1lg+tQpj3q+ Dwxp8z2f0eNsUeFBHtcBCKouZRj4UZ81OghS0= Received: by 10.236.131.42 with SMTP id l30mr70709920yhi.30.1317414216556; Fri, 30 Sep 2011 13:23:36 -0700 (PDT) Received: from [192.168.0.100] ([142.103.56.220]) by mx.google.com with ESMTPS id p8sm7726914yhe.17.2011.09.30.13.23.33 (version=SSLv3 cipher=OTHER); Fri, 30 Sep 2011 13:23:35 -0700 (PDT) User-Agent: Microsoft-Entourage/12.30.0.110427 Date: Fri, 30 Sep 2011 13:23:26 -0700 Subject: Re: [Xen-devel] [PATCH 0/2] enable event channel wake-up for mem_event interfaces From: Keir Fraser <keir.xen@gmail.com> To: Adin Scannell <adin@gridcentric.com>, <xen-devel@lists.xensource.com> Message-ID: <CAAB734E.22150%keir.xen@gmail.com> Thread-Topic: [Xen-devel] [PATCH 0/2] enable event channel wake-up for mem_event interfaces Thread-Index: Acx+swtBFoXOYffjI0md8opwEL2aZwA9avWmAAGF9xo= In-Reply-To: <CAAB6917.2210C%keir.xen@gmail.com> Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit Cc: Tim Deegan <tim@xen.org> X-BeenThere: xen-devel@lists.xensource.com X-Mailman-Version: 2.1.5 Precedence: list List-Id: Xen developer discussion <xen-devel.lists.xensource.com> List-Unsubscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe> List-Post: <mailto:xen-devel@lists.xensource.com> List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help> List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=subscribe> Sender: xen-devel-bounces@lists.xensource.com Errors-To: xen-devel-bounces@lists.xensource.com On 30/09/2011 12:39, "Keir Fraser" <keir.xen@gmail.com> wrote: > On 29/09/2011 07:21, "Keir Fraser" <keir.xen@gmail.com> wrote: > >> On 28/09/2011 14:22, "Adin Scannell" <adin@gridcentric.com> wrote: >> >>> Currently the mem_event code requires a domctl to kick the hypervisor >>> and unpause vcpus. An event channel is used to notify dom0 of >>> requests placed in the ring, and it can similarly be used to notify >>> Xen, so as not to overuse domctls when running many domains with >>> mem_event interfaces (domctls are not a great interface for this sort >>> of thing, because they will all be serialized). >>> >>> This patch set enables the use of the event channel to signal when a >>> response in placed in a mem_event ring. >> >> I don't have an opinion on patch 1/2. I'll leave it to someone else, like >> Tim, to comment. >> >> Patch 2/2 I don't mind the principle, but the implementation is not very >> scalable. I will post a rewritten version to the list. It might be early >> next week before I do so. > > I've attached it. Let me know how it works for you. By the way my patch doesn't hook up event notification for the d->mem_share structure. It doesn't look like d->mem_share.xen_port ever gets set up, and your patches didn't appear to fix that either. > -- Keir > >> >> -- Keir >> >>> The two patches are as follows: >>> - The first patch tweaks the memevent code to ensure that no events >>> are lost. Instead of calling get_response once per kick, we may have >>> to pull out multiple events at a time. This doesn't affect normal >>> operation with the domctls. >>> This patch also ensures that each vCPU can generate a request in each >>> mem_event ring (i.e. put_request will always work), by appropriately >>> pausing vCPUs when after requests are placed. >>> - The second patch breaks the Xen-side event channel handling into a >>> new arch-specific file "events.c", and adds cases for the different >>> Xen-handled event channels. This formalizes the tiny exception that >>> was in place for just qemu in event_channel.c. >>> >>> All the domctls are still in place and everything should be backwards >>> compatible. >>> >>> Cheers, >>> -Adin >>> >>> _______________________________________________ >>> Xen-devel mailing list >>> Xen-devel@lists.xensource.com >>> http://lists.xensource.com/xen-devel >> >> > _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel From xen-devel-bounces@lists.xensource.com Fri Sep 30 13:59:16 2011 Return-path: <xen-devel-bounces@lists.xensource.com> Envelope-to: www-data@lists.xensource.com Delivery-date: Fri, 30 Sep 2011 13:59:16 -0700 Received: from localhost ([127.0.0.1] helo=lists.colo.xensource.com) by lists.xensource.com with esmtp (Exim 4.43) id 1R9kAs-0000wU-Nj; Fri, 30 Sep 2011 13:59:14 -0700 Received: from mail182.messagelabs.com ([85.158.139.83]) by lists.xensource.com with esmtp (Exim 4.43) id 1R9k95-0000fH-GF for xen-devel@lists.xensource.com; Fri, 30 Sep 2011 13:57:24 -0700 X-Env-Sender: amscanne@gridcentric.ca X-Msg-Ref: server-4.tower-182.messagelabs.com!1317416240!20420994!1 X-Originating-IP: [209.85.161.43] X-StarScan-Version: 6.4.1; banners=-,-,- X-VirusChecked: Checked Received: (qmail 14882 invoked from network); 30 Sep 2011 20:57:20 -0000 Received: from mail-fx0-f43.google.com (HELO mail-fx0-f43.google.com) (209.85.161.43) by server-4.tower-182.messagelabs.com with RC4-SHA encrypted SMTP; 30 Sep 2011 20:57:20 -0000 Received: by fxh19 with SMTP id 19so4177453fxh.30 for <xen-devel@lists.xensource.com>; Fri, 30 Sep 2011 13:57:20 -0700 (PDT) Received: by 10.223.45.198 with SMTP id g6mr6618004faf.118.1317416240109; Fri, 30 Sep 2011 13:57:20 -0700 (PDT) MIME-Version: 1.0 Received: by 10.223.101.194 with HTTP; Fri, 30 Sep 2011 13:57:00 -0700 (PDT) In-Reply-To: <CAAB734E.22150%keir.xen@gmail.com> References: <CAAB6917.2210C%keir.xen@gmail.com> <CAAB734E.22150%keir.xen@gmail.com> From: Adin Scannell <adin@gridcentric.com> Date: Fri, 30 Sep 2011 16:57:00 -0400 X-Google-Sender-Auth: z53yZ_EAIIvM-k6axb74FUtM990 Message-ID: <CAAJKtqoPPzeRZqwERhF_cEey-SVjBMxKk=BwS4FdwS=GhkVp8A@mail.gmail.com> Subject: Re: [Xen-devel] [PATCH 0/2] enable event channel wake-up for mem_event interfaces To: Keir Fraser <keir.xen@gmail.com> Content-Type: text/plain; charset=ISO-8859-1 Cc: xen-devel@lists.xensource.com, Tim Deegan <tim@xen.org> X-BeenThere: xen-devel@lists.xensource.com X-Mailman-Version: 2.1.5 Precedence: list List-Id: Xen developer discussion <xen-devel.lists.xensource.com> List-Unsubscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe> List-Post: <mailto:xen-devel@lists.xensource.com> List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help> List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=subscribe> Sender: xen-devel-bounces@lists.xensource.com Errors-To: xen-devel-bounces@lists.xensource.com >>> Patch 2/2 I don't mind the principle, but the implementation is not very >>> scalable. I will post a rewritten version to the list. It might be early >>> next week before I do so. >> >> I've attached it. Let me know how it works for you. Seems to work for me, thanks! > By the way my patch doesn't hook up event notification for the d->mem_share > structure. It doesn't look like d->mem_share.xen_port ever gets set up, and > your patches didn't appear to fix that either. Yeah, it seems that is currently unused (unimplemented). I assume the idea was to put OOM notifications (or maybe unshare notifications) in that ring. Once I hear back on the first patch, I will resend as a series (the event mechanism for paging requires the first patch for correctness). Cheers, -Adin _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel From xen-devel-bounces@lists.xensource.com Fri Sep 30 14:05:20 2011 Return-path: <xen-devel-bounces@lists.xensource.com> Envelope-to: www-data@lists.xensource.com Delivery-date: Fri, 30 Sep 2011 14:05:20 -0700 Received: from localhost ([127.0.0.1] helo=lists.colo.xensource.com) by lists.xensource.com with esmtp (Exim 4.43) id 1R9kGm-0001NS-90; Fri, 30 Sep 2011 14:05:20 -0700 Received: from mail182.messagelabs.com ([85.158.139.83]) by lists.xensource.com with esmtp (Exim 4.43) id 1R9kER-00019V-52 for xen-devel@lists.xensource.com; Fri, 30 Sep 2011 14:03:03 -0700 X-Env-Sender: amscanne@gridcentric.ca X-Msg-Ref: server-9.tower-182.messagelabs.com!1317416571!18599057!1 X-Originating-IP: [209.85.161.43] X-StarScan-Version: 6.4.1; banners=-,-,- X-VirusChecked: Checked Received: (qmail 24289 invoked from network); 30 Sep 2011 21:02:51 -0000 Received: from mail-fx0-f43.google.com (HELO mail-fx0-f43.google.com) (209.85.161.43) by server-9.tower-182.messagelabs.com with RC4-SHA encrypted SMTP; 30 Sep 2011 21:02:51 -0000 Received: by fxh19 with SMTP id 19so4181494fxh.30 for <xen-devel@lists.xensource.com>; Fri, 30 Sep 2011 14:02:51 -0700 (PDT) Received: by 10.223.44.89 with SMTP id z25mr7116560fae.42.1317416571072; Fri, 30 Sep 2011 14:02:51 -0700 (PDT) MIME-Version: 1.0 Received: by 10.223.101.194 with HTTP; Fri, 30 Sep 2011 14:02:31 -0700 (PDT) In-Reply-To: <20110929170244.GA29163@aepfle.de> References: <CACavRyB4kvMLZK1-vv9bJnVdnpKJBHTmnhJxt6g3eh88xY6FTg@mail.gmail.com> <20110929170244.GA29163@aepfle.de> From: Adin Scannell <adin@gridcentric.ca> Date: Fri, 30 Sep 2011 17:02:31 -0400 X-Google-Sender-Auth: XA84RPTCPXvZquibFJhAIPzwQk8 Message-ID: <CAAJKtqrFuJkNAZZhRs8tC0ymgQTD0G2VTgYexQ9EhnCxsJNZuw@mail.gmail.com> Subject: Re: [Xen-devel] Re: mapping problems in xenpaging To: Olaf Hering <olaf@aepfle.de> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: zhen shi <bickys1986@gmail.com>, xen-devel@lists.xensource.com X-BeenThere: xen-devel@lists.xensource.com X-Mailman-Version: 2.1.5 Precedence: list List-Id: Xen developer discussion <xen-devel.lists.xensource.com> List-Unsubscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe> List-Post: <mailto:xen-devel@lists.xensource.com> List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help> List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=subscribe> Sender: xen-devel-bounces@lists.xensource.com Errors-To: xen-devel-bounces@lists.xensource.com >> =A0When we analyze and test xenpaging,we found there are some problems= =A0between >> mapping and xenpaging. >> =A01) When mapping firstly, then do xenpaging,and the code paths have re= solved >> the problems.It's OK. >> =A02) The problems exists if we do address mapping firstly then go to >> xenpaging,and our confusions are as followings: >> =A0=A0 a) If the domU's memory is directly mapped to dom0,such as the hy= percall >> from pv driver,then it will build a related page-table in dom0,which wil= l not >> change p2m-type. >> =A0=A0=A0=A0 =A0and then do the xenpaging to page out the domU's memory = pages whose gfn >> address have been already mapped to dom0;So it will cause some problems = when >> dom0 >> =A0=A0=A0=A0 =A0accesses these pages.Because these pages are paged-out,a= nd dom0 cannot >> tell the p2mt before access the pages. > > I'm not entirely sure what you do. xenpaging runs in dom0 and is able to > map paged-out pages. It uses that to trigger a page-in, see > tools/xenpaging/pagein.c in xen-unstable.hg Here's my take... Xenpaging doesn't allow selection of pages that have been mapped by other domains (as in p2m.c): 669 int p2m_mem_paging_nominate(struct domain *d, unsigned long gfn) .... 693 /* Check page count and type */ 694 page =3D mfn_to_page(mfn); 695 if ( (page->count_info & (PGC_count_mask | PGC_allocated)) !=3D 696 (1 | PGC_allocated) ) 697 goto out; *However*, I think that the problem Zhen is describing still exists: 1) xenpaging nominates a page, it is successful. 2) dom0 maps the same page (a process other than xenpaging, which will also map it). 3) xenpaging evicts the page, successfully. I've experienced a few nasty crashes, and I think this could account for a couple (but certainly not all)... I think that the solution may be to repeat the refcount check in paging_evict, and roll back the nomination gracefully if the race is detected. Thoughts? >> =A0 b)The another situation is that if xen has mapped the domU's page, a= nd get >> the mfn according to pfn_to_mfn.But then the page's p2mt is changed by o= thers, >> so when xen >> =A0=A0=A0 accesses the page ,it will cause problems such as BSOD or rebo= ot.Because >> the operations of getting mfn and accessing the page are not >> atomic.and=A0the=A0situation exists >> =A0=A0=A0 in=A0many code paths . I believe I have recreated this problem a few times, resulting in various crashes... unfortunately, there is somewhat of an implicit assumption throughout the code that when you grab an mfn via gfn_to_mfn, that mfn won't disappear underneath you (for example, see vmx_load_pdptrs). Really, you want something like gfn_to_mfn_getpage, where the underlying page has its refcount bumped so that it won't be nominated/evicted while you map and use the page, then you must put it back when you're done. I hope to look into helping fix some of these paging bugs soon. Cheers, -Adin _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel From xen-devel-bounces@lists.xensource.com Fri Sep 30 14:06:46 2011 Return-path: <xen-devel-bounces@lists.xensource.com> Envelope-to: www-data@lists.xensource.com Delivery-date: Fri, 30 Sep 2011 14:06:46 -0700 Received: from localhost ([127.0.0.1] helo=lists.colo.xensource.com) by lists.xensource.com with esmtp (Exim 4.43) id 1R9kIA-0001pk-GG; Fri, 30 Sep 2011 14:06:46 -0700 Received: from mail27.messagelabs.com ([193.109.254.147]) by lists.xensource.com with esmtp (Exim 4.43) id 1R9kFk-0001Cg-HT for xen-devel@lists.xensource.com; Fri, 30 Sep 2011 14:04:19 -0700 X-Env-Sender: amscanne@gridcentric.ca X-Msg-Ref: server-13.tower-27.messagelabs.com!1317416640!42264882!1 X-Originating-IP: [209.85.161.43] X-StarScan-Version: 6.4.1; banners=-,-,- X-VirusChecked: Checked Received: (qmail 14197 invoked from network); 30 Sep 2011 21:04:00 -0000 Received: from mail-fx0-f43.google.com (HELO mail-fx0-f43.google.com) (209.85.161.43) by server-13.tower-27.messagelabs.com with RC4-SHA encrypted SMTP; 30 Sep 2011 21:04:00 -0000 Received: by fxh19 with SMTP id 19so4182540fxh.30 for <xen-devel@lists.xensource.com>; Fri, 30 Sep 2011 14:04:13 -0700 (PDT) Received: by 10.223.76.67 with SMTP id b3mr19242927fak.61.1317416653066; Fri, 30 Sep 2011 14:04:13 -0700 (PDT) MIME-Version: 1.0 Received: by 10.223.101.194 with HTTP; Fri, 30 Sep 2011 14:03:53 -0700 (PDT) In-Reply-To: <1317312832330-4853794.post@n5.nabble.com> References: <1317172992048-4847541.post@n5.nabble.com> <1317312832330-4853794.post@n5.nabble.com> From: Adin Scannell <adin@gridcentric.ca> Date: Fri, 30 Sep 2011 17:03:53 -0400 X-Google-Sender-Auth: pXYPqhWYfGSIETNFqLW9l1rKcTk Message-ID: <CAAJKtqpQ7RC2=Mz1B9V1t4HPKPx_9kpxd+xL9mPoE0WCqR2fEA@mail.gmail.com> Subject: Re: [Xen-devel] Re: Getting the page fault count for domU To: Chintamani Siddeshwar <chintamani.sid@gmail.com> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: xen-devel@lists.xensource.com X-BeenThere: xen-devel@lists.xensource.com X-Mailman-Version: 2.1.5 Precedence: list List-Id: Xen developer discussion <xen-devel.lists.xensource.com> List-Unsubscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe> List-Post: <mailto:xen-devel@lists.xensource.com> List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help> List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=subscribe> Sender: xen-devel-bounces@lists.xensource.com Errors-To: xen-devel-bounces@lists.xensource.com I'm assuming you're talking about faults through the paging mechanism. The page fault handling is all done in dom0 user-space, so the number of faults for a particular vCPU for a given period in time can be easily tracked by the daemon without modifying hypervisor code. When a vCPU faults (i.e. trys to access a page that is currently paged out), it will be paused -- so it's not possible for the vCPU to accrue additional page faults until the userspace daemon handles the first one. I'm not sure what your use-case is, but there's probably a better way of sharing this information with other user-space tools than through an additional field in struct domain. Cheers, -Adin On Thu, Sep 29, 2011 at 12:13 PM, Chintamani Siddeshwar <chintamani.sid@gmail.com> wrote: > I am thinking of doing something like > > 1) Add a field "unsigned long page_fault_count" to struct domain defined = in > in xen/sched.h > > 2) Increment this counter mem_paging_domctl(...) defined in > arch/x_86/mm/mem_paging.c for > =A0 =A0 =A0 =A0 =A0 =A0 =A0 case XEN_DOMCTL_MEM_EVENT_OP_PAGING_EVICT > > I will then access this information is available from within struct > vcpu->domain->page_fault_count. > > Please correct me if my chain of thought is wrong or if it is too > simplistic. > Looking forward to your valuable comments > > =A0 =A0thanks > Chintamani > > > > -- > View this message in context: http://xen.1045712.n5.nabble.com/Getting-th= e-page-fault-count-for-domU-tp4847541p4853794.html > Sent from the Xen - Dev mailing list archive at Nabble.com. > > _______________________________________________ > Xen-devel mailing list > Xen-devel@lists.xensource.com > http://lists.xensource.com/xen-devel > _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel From xen-devel-bounces@lists.xensource.com Fri Sep 30 14:09:42 2011 Return-path: <xen-devel-bounces@lists.xensource.com> Envelope-to: www-data@lists.xensource.com Delivery-date: Fri, 30 Sep 2011 14:09:42 -0700 Received: from localhost ([127.0.0.1] helo=lists.colo.xensource.com) by lists.xensource.com with esmtp (Exim 4.43) id 1R9kL0-0002EH-Of; Fri, 30 Sep 2011 14:09:42 -0700 Received: from mail174.messagelabs.com ([85.158.138.51]) by lists.xensource.com with esmtp (Exim 4.43) id 1R9kKY-00022V-6U for xen-devel@lists.xensource.com; Fri, 30 Sep 2011 14:09:15 -0700 X-Env-Sender: keir.xen@gmail.com X-Msg-Ref: server-6.tower-174.messagelabs.com!1317416950!31286699!1 X-Originating-IP: [209.85.213.171] X-StarScan-Version: 6.4.1; banners=-,-,- X-VirusChecked: Checked Received: (qmail 9547 invoked from network); 30 Sep 2011 21:09:11 -0000 Received: from mail-yx0-f171.google.com (HELO mail-yx0-f171.google.com) (209.85.213.171) by server-6.tower-174.messagelabs.com with RC4-SHA encrypted SMTP; 30 Sep 2011 21:09:11 -0000 Received: by yxt3 with SMTP id 3so2991998yxt.30 for <xen-devel@lists.xensource.com>; Fri, 30 Sep 2011 14:09:09 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=user-agent:date:subject:from:to:cc:message-id:thread-topic :thread-index:in-reply-to:mime-version:content-type :content-transfer-encoding; bh=ZkCT0BA11ZMzhCo1Ouh39IhPTTCiUpMW/VaP3kPLfxo=; b=JbsX9mBBUGqv+8LYNPXV9ZeReQMIbAKx/fDKYL6KXRQvZOFP+TenYAcrBKWeLl0MiS C2MLBmuzjpZDwaDhIlvpVhU1SSGjVhWaezqYc5qq0nN7cAiHRXXw9N0M6AcTfYnrWu0K Xv2ocBhgBxJJmSXgKlNxRFAl/xq+tKjg1eKvI= Received: by 10.150.55.9 with SMTP id d9mr9979734yba.204.1317416949765; Fri, 30 Sep 2011 14:09:09 -0700 (PDT) Received: from [192.168.0.100] ([142.103.56.220]) by mx.google.com with ESMTPS id a3sm1107065ybn.23.2011.09.30.14.09.05 (version=SSLv3 cipher=OTHER); Fri, 30 Sep 2011 14:09:08 -0700 (PDT) User-Agent: Microsoft-Entourage/12.30.0.110427 Date: Fri, 30 Sep 2011 14:09:00 -0700 Subject: Re: [Xen-devel] [PATCH 0/2] enable event channel wake-up for mem_event interfaces From: Keir Fraser <keir.xen@gmail.com> To: Adin Scannell <adin@gridcentric.com> Message-ID: <CAAB7DFC.22156%keir.xen@gmail.com> Thread-Topic: [Xen-devel] [PATCH 0/2] enable event channel wake-up for mem_event interfaces Thread-Index: Acx/tSyKAkTdQle0e0ykVtiol05Hgw== In-Reply-To: <CAAJKtqoPPzeRZqwERhF_cEey-SVjBMxKk=BwS4FdwS=GhkVp8A@mail.gmail.com> Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit Cc: xen-devel@lists.xensource.com, Tim Deegan <tim@xen.org> X-BeenThere: xen-devel@lists.xensource.com X-Mailman-Version: 2.1.5 Precedence: list List-Id: Xen developer discussion <xen-devel.lists.xensource.com> List-Unsubscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe> List-Post: <mailto:xen-devel@lists.xensource.com> List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help> List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=subscribe> Sender: xen-devel-bounces@lists.xensource.com Errors-To: xen-devel-bounces@lists.xensource.com On 30/09/2011 13:57, "Adin Scannell" <adin@gridcentric.com> wrote: >>>> Patch 2/2 I don't mind the principle, but the implementation is not very >>>> scalable. I will post a rewritten version to the list. It might be early >>>> next week before I do so. >>> >>> I've attached it. Let me know how it works for you. > > Seems to work for me, thanks! > >> By the way my patch doesn't hook up event notification for the d->mem_share >> structure. It doesn't look like d->mem_share.xen_port ever gets set up, and >> your patches didn't appear to fix that either. > > Yeah, it seems that is currently unused (unimplemented). I assume the > idea was to put OOM notifications (or maybe unshare notifications) in > that ring. > > Once I hear back on the first patch, I will resend as a series (the > event mechanism for paging requires the first patch for correctness). You can put my sign off on the redone second patch when you re-send it: Signed-off-by: Keir Fraser <keir@xen.org> Also, most of the reviewers on this list prefer it if you can send patches in-line in plain text rather than as an attachment. Makes it easier to make detailed comments. -- Keir _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel From xen-devel-bounces@lists.xensource.com Fri Sep 30 14:15:48 2011 Return-path: <xen-devel-bounces@lists.xensource.com> Envelope-to: www-data@lists.xensource.com Delivery-date: Fri, 30 Sep 2011 14:15:48 -0700 Received: from localhost ([127.0.0.1] helo=lists.colo.xensource.com) by lists.xensource.com with esmtp (Exim 4.43) id 1R9kQu-0002fO-Bt; Fri, 30 Sep 2011 14:15:48 -0700 Received: from mail174.messagelabs.com ([85.158.138.51]) by lists.xensource.com with esmtp (Exim 4.43) id 1R9kQN-0002TY-5T for xen-devel@lists.xensource.com; Fri, 30 Sep 2011 14:15:17 -0700 X-Env-Sender: amscanne@gridcentric.ca X-Msg-Ref: server-14.tower-174.messagelabs.com!1317417311!33430143!1 X-Originating-IP: [209.85.161.43] X-StarScan-Version: 6.4.1; banners=-,-,- X-VirusChecked: Checked Received: (qmail 31849 invoked from network); 30 Sep 2011 21:15:11 -0000 Received: from mail-fx0-f43.google.com (HELO mail-fx0-f43.google.com) (209.85.161.43) by server-14.tower-174.messagelabs.com with RC4-SHA encrypted SMTP; 30 Sep 2011 21:15:11 -0000 Received: by fxh19 with SMTP id 19so4191705fxh.30 for <xen-devel@lists.xensource.com>; Fri, 30 Sep 2011 14:15:11 -0700 (PDT) Received: by 10.223.48.69 with SMTP id q5mr889899faf.80.1317417311167; Fri, 30 Sep 2011 14:15:11 -0700 (PDT) MIME-Version: 1.0 Received: by 10.223.101.194 with HTTP; Fri, 30 Sep 2011 14:14:51 -0700 (PDT) In-Reply-To: <4E843DBD020000780005865C@nat28.tlf.novell.com> References: <CAAJKtqre0Q3qbngZi01NfmSQSh0YXtSyS4LZc=cOQt98Xqzcyw@mail.gmail.com> <4E843DBD020000780005865C@nat28.tlf.novell.com> From: Adin Scannell <adin@gridcentric.com> Date: Fri, 30 Sep 2011 17:14:51 -0400 X-Google-Sender-Auth: cH-CH6xiP4lMIHGfDuKTyHjLcLc Message-ID: <CAAJKtqpFAtrBMHS7+bUAA_WY5GC28a0Ttd8=zpBWR6=BPp1_=A@mail.gmail.com> Subject: Re: [Xen-devel] [PATCH] build fixes for cross-compiling To: Jan Beulich <JBeulich@suse.com> Content-Type: multipart/mixed; boundary=001517441332da66b904ae2f1ef7 Cc: xen-devel@lists.xensource.com X-BeenThere: xen-devel@lists.xensource.com X-Mailman-Version: 2.1.5 Precedence: list List-Id: Xen developer discussion <xen-devel.lists.xensource.com> List-Unsubscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe> List-Post: <mailto:xen-devel@lists.xensource.com> List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help> List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=subscribe> Sender: xen-devel-bounces@lists.xensource.com Errors-To: xen-devel-bounces@lists.xensource.com --001517441332da66b904ae2f1ef7 Content-Type: text/plain; charset=ISO-8859-1 > Are you saying this actually works for you (building everything, not just > the tools)? To build everything, I need to tweak a couple of extra bits (in the attached patch). I'm somewhat wary about statements regarding anything build-related, because I know everyone has a different approach and it runs in a different environment. With the both first patch and the attached, everything builds for me for both XEN_TARGET_ARCH=x86_32 and x86_64 in my 64-bit environment. > I do cross builds too, but generally the other way around (64-bit > build on 32-bit host), and hence need to only cross-build the > hypervisor to put underneath everything. > > I can't seem to find an ld (native or cross) that would accept -m32, > -march=i686, ... I think I had the same thing happen to me that happened to Ian (-m32 -melf_x86_64 ... so no errors). If the LDFLAGS / LDFLAGS_INDIRECT stuff is messy, my previous approach has been to add $(CFLAGS) to all the link steps in the tools (i.e. lib*, xl, etc.) so that the approach architecture flags would be passed to gcc for linking. I don't mind going through and doing that until everything builds smoothly for 32-bit target on 64-bit, provided that's a friendly solution. It would be great to be able to stop using a set of build patches at the bottom of my queue. :) Cheers, -Adin --001517441332da66b904ae2f1ef7 Content-Type: application/octet-stream; name="cross-compile-fixes.patch" Content-Disposition: attachment; filename="cross-compile-fixes.patch" Content-Transfer-Encoding: base64 X-Attachment-Id: f_gt7lx9ty0 IyBIRyBjaGFuZ2VzZXQgcGF0Y2gKIyBQYXJlbnQgZDliOGU3OTMzMjgyNzI1ODRlZDgyZTVkM2Uy OTc0NzIxYjQyN2E1NQpGaXhlcyBmb3IgY3Jvc3MtY29tcGlsaW5nIDMyLWJpdCB0b29scyBvbiA2 NC1iaXQgaG9zdC4KClNpZ25lZC1vZmYtYnk6IEFkaW4gU2Nhbm5lbGwgPGFkaW5Ac2Nhbm5lbGwu Y2E+CgpkaWZmIC1yIGQ5YjhlNzkzMzI4MiB0b29scy9NYWtlZmlsZQotLS0gYS90b29scy9NYWtl ZmlsZQorKysgYi90b29scy9NYWtlZmlsZQpAQCAtNzMsNyArNzMsMTMgQEAgZGlzdGNsZWFuOiBz dWJkaXJzLWRpc3RjbGVhbgogCXJtIC1yZiBpb2VtdS1kaXIgaW9lbXUtcmVtb3RlCgogaWZuZXEg KCQoWEVOX0NPTVBJTEVfQVJDSCksJChYRU5fVEFSR0VUX0FSQ0gpKQotSU9FTVVfQ09ORklHVVJF X0NST1NTID89IC0tY3B1PSQoWEVOX1RBUkdFVF9BUkNIKSBcCitpZmVxICgkKFhFTl9UQVJHRVRf QVJDSCkseDg2XzMyKQorIyBUaGUgcWVtdSBidWlsZCB1c2VzIGkzODYgaW5zdGVhZCBvZiB4ODZf MzIuCitJT0VNVV9DT05GSUdVUkVfQ1BVID89IC0tY3B1PWkzODYKK2Vsc2UKK0lPRU1VX0NPTkZJ R1VSRV9DUFUgPz0gLS1jcHU9JChYRU5fVEFSR0VUX0FSQ0gpCitlbmRpZgorSU9FTVVfQ09ORklH VVJFX0NST1NTID89ICQoSU9FTVVfQ09ORklHVVJFX0NQVSkgXAogCQkJIC0tY3Jvc3MtcHJlZml4 PSQoQ1JPU1NfQ09NUElMRSkgXAogCQkJIC0taW50ZXJwLXByZWZpeD0kKENST1NTX1NZU19ST09U KQogZW5kaWYKZGlmZiAtciBkOWI4ZTc5MzMyODIgdG9vbHMvYmxrdGFwL2RyaXZlcnMvTWFrZWZp bGUKLS0tIGEvdG9vbHMvYmxrdGFwL2RyaXZlcnMvTWFrZWZpbGUKKysrIGIvdG9vbHMvYmxrdGFw L2RyaXZlcnMvTWFrZWZpbGUKQEAgLTE0LDYgKzE0LDcgQEAgQ0ZMQUdTICAgKz0gJChDRkxBR1Nf bGlieGVuc3RvcmUpCiBDRkxBR1MgICArPSAtSSAkKExJQkFJT19ESVIpCiBDRkxBR1MgICArPSAt SSAkKE1FTVNIUl9ESVIpCiBDRkxBR1MgICArPSAtRF9HTlVfU09VUkNFCitDRkxBR1MgICArPSAt RF9GSUxFX09GRlNFVF9CSVRTPTY0CgogaWZlcSAoJChzaGVsbCAuIC4vY2hlY2tfZ2NyeXB0ICQo Q0MpKSx5ZXMpCiBDRkxBR1MgKz0gLURVU0VfR0NSWVBUCmRpZmYgLXIgZDliOGU3OTMzMjgyIHRv b2xzL2Jsa3RhcDIvdmhkL2xpYi9NYWtlZmlsZQotLS0gYS90b29scy9ibGt0YXAyL3ZoZC9saWIv TWFrZWZpbGUKKysrIGIvdG9vbHMvYmxrdGFwMi92aGQvbGliL01ha2VmaWxlCkBAIC0xOCw2ICsx OCw3IEBAIENGTEFHUyAgICAgICAgICArPSAtSS4uLy4uL2luY2x1ZGUKIENGTEFHUyAgICAgICAg ICArPSAtRF9HTlVfU09VUkNFCiBDRkxBR1MgICAgICAgICAgKz0gLWZQSUMKIENGTEFHUyAgICAg ICAgICArPSAtZworQ0ZMQUdTICAgICAgICAgICs9IC1EX0ZJTEVfT0ZGU0VUX0JJVFM9NjQKCiBp ZmVxICgkKENPTkZJR19MaW51eCkseSkKIExJQlMgICAgICAgICAgICA6PSAtbHV1aWQKZGlmZiAt ciBkOWI4ZTc5MzMyODIgdG9vbHMvbGliZnNpbWFnZS9jb21tb24vTWFrZWZpbGUKLS0tIGEvdG9v bHMvbGliZnNpbWFnZS9jb21tb24vTWFrZWZpbGUKKysrIGIvdG9vbHMvbGliZnNpbWFnZS9jb21t b24vTWFrZWZpbGUKQEAgLTQsOCArNCw4IEBAIGluY2x1ZGUgJChYRU5fUk9PVCkvdG9vbHMvUnVs ZXMubWsKIE1BSk9SID0gMS4wCiBNSU5PUiA9IDAKCi1MREZMQUdTLSQoQ09ORklHX1N1bk9TKSA9 IC1XbCwtTSAtV2wsbWFwZmlsZS1TdW5PUwotTERGTEFHUy0kKENPTkZJR19MaW51eCkgPSAtV2ws bWFwZmlsZS1HTlUKK0xERkxBR1MtJChDT05GSUdfU3VuT1MpIDo9ICQoTERGTEFHUykgLVdsLC1N IC1XbCxtYXBmaWxlLVN1bk9TCitMREZMQUdTLSQoQ09ORklHX0xpbnV4KSA6PSAkKExERkxBR1Mp IC1XbCxtYXBmaWxlLUdOVQogTERGTEFHUyA9ICQoTERGTEFHUy15KQoKIExJQl9TUkNTLXkgPSBm c2ltYWdlLmMgZnNpbWFnZV9wbHVnaW4uYyBmc2ltYWdlX2dydWIuYwo= --001517441332da66b904ae2f1ef7 Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel --001517441332da66b904ae2f1ef7-- From xen-devel-bounces@lists.xensource.com Fri Sep 30 14:47:26 2011 Return-path: <xen-devel-bounces@lists.xensource.com> Envelope-to: www-data@lists.xensource.com Delivery-date: Fri, 30 Sep 2011 14:47:26 -0700 Received: from localhost ([127.0.0.1] helo=lists.colo.xensource.com) by lists.xensource.com with esmtp (Exim 4.43) id 1R9kvW-0003qC-N3; Fri, 30 Sep 2011 14:47:26 -0700 Received: from mail21.messagelabs.com ([85.158.143.35]) by lists.xensource.com with esmtp (Exim 4.43) id 1R9kue-0003dZ-00 for xen-devel@lists.xensource.com; Fri, 30 Sep 2011 14:46:33 -0700 X-Env-Sender: amscanne@gridcentric.ca X-Msg-Ref: server-5.tower-21.messagelabs.com!1317419153!50208629!1 X-Originating-IP: [209.85.161.43] X-StarScan-Version: 6.4.1; banners=-,-,- X-VirusChecked: Checked Received: (qmail 2567 invoked from network); 30 Sep 2011 21:45:53 -0000 Received: from mail-fx0-f43.google.com (HELO mail-fx0-f43.google.com) (209.85.161.43) by server-5.tower-21.messagelabs.com with RC4-SHA encrypted SMTP; 30 Sep 2011 21:45:53 -0000 Received: by fxh19 with SMTP id 19so4216940fxh.30 for <xen-devel@lists.xensource.com>; Fri, 30 Sep 2011 14:46:28 -0700 (PDT) Received: by 10.223.76.67 with SMTP id b3mr19303337fak.61.1317419188234; Fri, 30 Sep 2011 14:46:28 -0700 (PDT) MIME-Version: 1.0 Received: by 10.223.101.194 with HTTP; Fri, 30 Sep 2011 14:46:08 -0700 (PDT) From: Adin Scannell <adin@gridcentric.com> Date: Fri, 30 Sep 2011 17:46:08 -0400 X-Google-Sender-Auth: iWR6Ctu-NooytKE-ZCOQFFRqVfE Message-ID: <CAAJKtqq0Qoxh1KazXXdZaVb1qZ6pcP1LNXk1bD1tgsKEV7g_iQ@mail.gmail.com> To: xen-devel@lists.xensource.com Content-Type: multipart/mixed; boundary=00151743f964bc2a9604ae2f8eb7 Subject: [Xen-devel] [PATCH RFC] memory sharing questions X-BeenThere: xen-devel@lists.xensource.com X-Mailman-Version: 2.1.5 Precedence: list List-Id: Xen developer discussion <xen-devel.lists.xensource.com> List-Unsubscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe> List-Post: <mailto:xen-devel@lists.xensource.com> List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help> List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=subscribe> Sender: xen-devel-bounces@lists.xensource.com Errors-To: xen-devel-bounces@lists.xensource.com --00151743f964bc2a9604ae2f8eb7 Content-Type: text/plain; charset=ISO-8859-1 Hi all, I have a basic question about memory sharing. What is the intended purpose of the hashtable / handle abstraction for page sharing? I understand that it's a nice to associate a handle with a particularly revision of a shared page, but I don't see why it's necessary given that whoever is calling nominate() must be aware of the contents of the page (post-nomination) and how many times it has been nominated. Also, with a lot of shared pages, it seems like you could easily end up with buckets in the hashtable that are thousands of pages deep (i.e. consider 4GB shared on a large machine, each bucket will be 1000 handles on average). When this happens, it seems like it will generate a lot of unnecessary memory accesses to share and unshare pages (esp. since there is a single lock held during scanning!). Anyways, I've got a not-yet-prime-time patch that removes the hashtable and just uses mfns. In true form, I've probably missed something critical with the handle approach, so I'd love some feedback on this before investing effort in testing and scalability comparison. The patch essentially embeds the necessary extra bit of information in the struct page_info for shared pages (without growing the structure). Thanks! (patch inline below and attached) Cheers, -Adin (inline patch follows) diff -r 38135be750ed xen/arch/x86/mm.c --- a/xen/arch/x86/mm.c +++ b/xen/arch/x86/mm.c @@ -4230,12 +4230,19 @@ int page_make_sharable(struct domain *d, struct page_info *page, int expected_refcnt) { + struct list_head *shared_gfns = NULL; + + if((shared_gfns = xmalloc(struct list_head)) == NULL) + return -ENOMEM; + INIT_LIST_HEAD(shared_gfns); + spin_lock(&d->page_alloc_lock); /* Change page type and count atomically */ if ( !get_page_and_type(page, d, PGT_shared_page) ) { spin_unlock(&d->page_alloc_lock); + xfree(shared_gfns); return -EINVAL; } @@ -4244,6 +4251,7 @@ int page_make_sharable(struct domain *d, { put_page_and_type(page); spin_unlock(&d->page_alloc_lock); + xfree(shared_gfns); return -EEXIST; } @@ -4254,12 +4262,14 @@ int page_make_sharable(struct domain *d, /* Return type count back to zero */ put_page_and_type(page); spin_unlock(&d->page_alloc_lock); + xfree(shared_gfns); return -E2BIG; } page_set_owner(page, dom_cow); d->tot_pages--; page_list_del(page, &d->page_list); + page->shared_gfns = shared_gfns; spin_unlock(&d->page_alloc_lock); return 0; } @@ -4280,6 +4290,9 @@ int page_make_private(struct domain *d, return -EEXIST; } + /* Free the shared page info */ + xfree(page->shared_gfns); + /* Drop the final typecount */ put_page_and_type(page); diff -r 38135be750ed xen/arch/x86/mm/mem_sharing.c --- a/xen/arch/x86/mm/mem_sharing.c +++ b/xen/arch/x86/mm/mem_sharing.c @@ -39,8 +39,8 @@ #if MEM_SHARING_AUDIT static void mem_sharing_audit(void); -#define MEM_SHARING_DEBUG(_f, _a...) \ - debugtrace_printk("mem_sharing_debug: %s(): " _f, __func__, ##_a) +#define MEM_SHARING_DEBUG(_f, _a...) \ + debugtrace_printk("mem_sharing_debug: %s(): " _f, __func__, ##_a) #else # define mem_sharing_audit() do {} while(0) #endif /* MEM_SHARING_AUDIT */ @@ -55,19 +55,7 @@ static void mem_sharing_audit(void); #undef page_to_mfn #define page_to_mfn(_pg) _mfn(__page_to_mfn(_pg)) -static shr_handle_t next_handle = 1; -static atomic_t nr_saved_mfns = ATOMIC_INIT(0); - -typedef struct shr_hash_entry -{ - shr_handle_t handle; - mfn_t mfn; - struct shr_hash_entry *next; - struct list_head gfns; -} shr_hash_entry_t; - -#define SHR_HASH_LENGTH 1000 -static shr_hash_entry_t *shr_hash[SHR_HASH_LENGTH]; +static atomic_t nr_saved_mfns = ATOMIC_INIT(0); typedef struct gfn_info { @@ -84,28 +72,9 @@ static inline int list_has_one_entry(str return (head->next != head) && (head->next->next == head); } -static inline struct gfn_info* gfn_get_info(struct list_head *list) +static inline gfn_info_t* gfn_get_info(struct list_head *list) { - return list_entry(list->next, struct gfn_info, list); -} - -static void __init mem_sharing_hash_init(void) -{ - int i; - - mm_lock_init(&shr_lock); - for(i=0; i<SHR_HASH_LENGTH; i++) - shr_hash[i] = NULL; -} - -static shr_hash_entry_t *mem_sharing_hash_alloc(void) -{ - return xmalloc(shr_hash_entry_t); -} - -static void mem_sharing_hash_destroy(shr_hash_entry_t *e) -{ - xfree(e); + return list_entry(list->next, gfn_info_t, list); } static gfn_info_t *mem_sharing_gfn_alloc(void) @@ -130,125 +99,99 @@ static void mem_sharing_gfn_destroy(gfn_ xfree(gfn); } -static shr_hash_entry_t* mem_sharing_hash_lookup(shr_handle_t handle) +static struct page_info* mem_sharing_lookup(shr_handle_t handle) { - shr_hash_entry_t *e; - - e = shr_hash[handle % SHR_HASH_LENGTH]; - while(e != NULL) + if( mfn_valid(_mfn(handle)) ) { - if(e->handle == handle) - return e; - e = e->next; + struct page_info* page = mfn_to_page(_mfn(handle)); + if( page_get_owner(page) == dom_cow ) + return page; } return NULL; } -static shr_hash_entry_t* mem_sharing_hash_insert(shr_handle_t handle, mfn_t mfn) +#if MEM_SHARING_AUDIT +static int mem_sharing_audit(void) { - shr_hash_entry_t *e, **ee; - - e = mem_sharing_hash_alloc(); - if(e == NULL) return NULL; - e->handle = handle; - e->mfn = mfn; - ee = &shr_hash[handle % SHR_HASH_LENGTH]; - e->next = *ee; - *ee = e; - return e; -} - -static void mem_sharing_hash_delete(shr_handle_t handle) -{ - shr_hash_entry_t **pprev, *e; - - pprev = &shr_hash[handle % SHR_HASH_LENGTH]; - e = *pprev; - while(e != NULL) - { - if(e->handle == handle) - { - *pprev = e->next; - mem_sharing_hash_destroy(e); - return; - } - pprev = &e->next; - e = e->next; - } - printk("Could not find shr entry for handle %"PRIx64"\n", handle); - BUG(); -} - -#if MEM_SHARING_AUDIT -static void mem_sharing_audit(void) -{ - shr_hash_entry_t *e; - struct list_head *le; - gfn_info_t *g; - int bucket; - struct page_info *pg; + int errors = 0; + unsigned long count_found = 0; + unsigned long mfn; ASSERT(shr_locked_by_me()); - for(bucket=0; bucket < SHR_HASH_LENGTH; bucket++) + for( mfn = 0; mfn < max_page; mfn++ ) { - e = shr_hash[bucket]; - /* Loop over all shr_hash_entries */ - while(e != NULL) + unsigned long nr_gfns = 0; + struct page_info *pg; + struct list_head *le; + gfn_info_t *g; + + if( !mfn_valid(_mfn(mfn)) ) + continue; + + pg = mfn_to_page(_mfn(mfn)); + + /* Check if the MFN has correct type, owner and handle. */ + if((pg->u.inuse.type_info & PGT_type_mask) != PGT_shared_page) + continue; + + /* Count this page. */ + count_found++; + + /* Check the page owner. */ + if(page_get_owner(pg) != dom_cow) { - int nr_gfns=0; + MEM_SHARING_DEBUG("mfn %lx shared, but wrong owner (%d)!\n", + mfn, page_get_owner(pg)->domain_id); + errors++; + } - /* Check if the MFN has correct type, owner and handle */ - pg = mfn_to_page(e->mfn); - if((pg->u.inuse.type_info & PGT_type_mask) != PGT_shared_page) - MEM_SHARING_DEBUG("mfn %lx not shared, but in the hash!\n", - mfn_x(e->mfn)); - if(page_get_owner(pg) != dom_cow) - MEM_SHARING_DEBUG("mfn %lx shared, but wrong owner (%d)!\n", - mfn_x(e->mfn), - page_get_owner(pg)->domain_id); - if(e->handle != pg->shr_handle) - MEM_SHARING_DEBUG("mfn %lx shared, but wrong handle " - "(%ld != %ld)!\n", - mfn_x(e->mfn), pg->shr_handle, e->handle); - /* Check if all GFNs map to the MFN, and the p2m types */ - list_for_each(le, &e->gfns) + /* Check if all GFNs map to the MFN, and the p2m types */ + list_for_each(le, pg->shared_gfns) + { + struct domain *d; + p2m_type_t t; + mfn_t o_mfn; + + g = list_entry(le, gfn_info_t, list); + d = get_domain_by_id(g->domain); + if(d == NULL) { - struct domain *d; - p2m_type_t t; - mfn_t mfn; + MEM_SHARING_DEBUG("Unknown dom: %d, for PFN=%lx, MFN=%lx\n", + g->domain, g->gfn, mfn); + errors++; + continue; + } + o_mfn = gfn_to_mfn(d, g->gfn, &t); + if(mfn_x(o_mfn) != mfn) + { + MEM_SHARING_DEBUG("Incorrect P2M for d=%d, PFN=%lx." + "Expecting MFN=%ld, got %ld\n", + g->domain, g->gfn, mfn, mfn_x(o_mfn)); + errors++; + } + if(t != p2m_ram_shared) + { + MEM_SHARING_DEBUG("Incorrect P2M type for d=%d, PFN=%lx." + "Expecting t=%d, got %d\n", + g->domain, g->gfn, mfn, p2m_ram_shared, t); + errors++; + } + put_domain(d); + nr_gfns++; + } - g = list_entry(le, struct gfn_info, list); - d = get_domain_by_id(g->domain); - if(d == NULL) - { - MEM_SHARING_DEBUG("Unknow dom: %d, for PFN=%lx, MFN=%lx\n", - g->domain, g->gfn, mfn_x(e->mfn)); - continue; - } - mfn = gfn_to_mfn(d, g->gfn, &t); - if(mfn_x(mfn) != mfn_x(e->mfn)) - MEM_SHARING_DEBUG("Incorrect P2M for d=%d, PFN=%lx." - "Expecting MFN=%ld, got %ld\n", - g->domain, g->gfn, mfn_x(e->mfn), - mfn_x(mfn)); - if(t != p2m_ram_shared) - MEM_SHARING_DEBUG("Incorrect P2M type for d=%d, PFN=%lx." - "Expecting t=%d, got %d\n", - g->domain, g->gfn, mfn_x(e->mfn), - p2m_ram_shared, t); - put_domain(d); - nr_gfns++; - } - if(nr_gfns != (pg->u.inuse.type_info & PGT_count_mask)) - MEM_SHARING_DEBUG("Mismatched counts for MFN=%lx." - "nr_gfns in hash %d, in type_info %d\n", - mfn_x(e->mfn), nr_gfns, - (pg->u.inuse.type_info & PGT_count_mask)); - e = e->next; + if(nr_gfns != (pg->u.inuse.type_info & PGT_count_mask)) + { + MEM_SHARING_DEBUG("Mismatched counts for MFN=%lx." + "nr_gfns in hash %d, in type_info %d\n", + mfn, nr_gfns, (pg->u.inuse.type_info & PGT_count_mask)); + errors++; } } + + return errors; } #endif @@ -392,37 +335,6 @@ static int mem_sharing_gref_to_gfn(struc return -2; } -/* Account for a GFN being shared/unshared. - * When sharing this function needs to be called _before_ gfn lists are merged - * together, but _after_ gfn is removed from the list when unsharing. - */ -static int mem_sharing_gfn_account(struct gfn_info *gfn, int sharing) -{ - struct domain *d; - - /* A) When sharing: - * if the gfn being shared is in > 1 long list, its already been - * accounted for - * B) When unsharing: - * if the list is longer than > 1, we don't have to account yet. - */ - if(list_has_one_entry(&gfn->list)) - { - d = get_domain_by_id(gfn->domain); - BUG_ON(!d); - if(sharing) - atomic_inc(&d->shr_pages); - else - atomic_dec(&d->shr_pages); - put_domain(d); - - return 1; - } - mem_sharing_audit(); - - return 0; -} - int mem_sharing_debug_gref(struct domain *d, grant_ref_t ref) { grant_entry_header_t *shah; @@ -457,8 +369,6 @@ int mem_sharing_nominate_page(struct dom mfn_t mfn; struct page_info *page; int ret; - shr_handle_t handle; - shr_hash_entry_t *hash_entry; struct gfn_info *gfn_info; *phandle = 0UL; @@ -474,7 +384,7 @@ int mem_sharing_nominate_page(struct dom /* Return the handle if the page is already shared */ page = mfn_to_page(mfn); if (p2m_is_shared(p2mt)) { - *phandle = page->shr_handle; + *phandle = mfn_x(mfn); ret = 0; goto out; } @@ -490,16 +400,8 @@ int mem_sharing_nominate_page(struct dom /* Create the handle */ ret = -ENOMEM; - handle = next_handle++; - if((hash_entry = mem_sharing_hash_insert(handle, mfn)) == NULL) - { + if((gfn_info = mem_sharing_gfn_alloc()) == NULL) goto out; - } - if((gfn_info = mem_sharing_gfn_alloc()) == NULL) - { - mem_sharing_hash_destroy(hash_entry); - goto out; - } /* Change the p2m type */ if(p2m_change_type(d, gfn, p2mt, p2m_ram_shared) != p2mt) @@ -509,7 +411,6 @@ int mem_sharing_nominate_page(struct dom * The mfn needs to revert back to rw type. This should never fail, * since no-one knew that the mfn was temporarily sharable */ BUG_ON(page_make_private(d, page) != 0); - mem_sharing_hash_destroy(hash_entry); mem_sharing_gfn_destroy(gfn_info, 0); goto out; } @@ -517,13 +418,12 @@ int mem_sharing_nominate_page(struct dom /* Update m2p entry to SHARED_M2P_ENTRY */ set_gpfn_from_mfn(mfn_x(mfn), SHARED_M2P_ENTRY); - INIT_LIST_HEAD(&hash_entry->gfns); INIT_LIST_HEAD(&gfn_info->list); - list_add(&gfn_info->list, &hash_entry->gfns); + list_add(&gfn_info->list, page->shared_gfns); gfn_info->gfn = gfn; gfn_info->domain = d->domain_id; - page->shr_handle = handle; - *phandle = handle; + *phandle = mfn_x(mfn); + atomic_inc(&d->shr_pages); ret = 0; @@ -534,29 +434,25 @@ out: int mem_sharing_share_pages(shr_handle_t sh, shr_handle_t ch) { - shr_hash_entry_t *se, *ce; struct page_info *spage, *cpage; struct list_head *le, *te; - struct gfn_info *gfn; + gfn_info_t *gfn; struct domain *d; int ret; shr_lock(); ret = XEN_DOMCTL_MEM_SHARING_S_HANDLE_INVALID; - se = mem_sharing_hash_lookup(sh); - if(se == NULL) goto err_out; + spage = mem_sharing_lookup(sh); + if(spage == NULL) goto err_out; ret = XEN_DOMCTL_MEM_SHARING_C_HANDLE_INVALID; - ce = mem_sharing_hash_lookup(ch); - if(ce == NULL) goto err_out; - spage = mfn_to_page(se->mfn); - cpage = mfn_to_page(ce->mfn); - /* gfn lists always have at least one entry => save to call list_entry */ - mem_sharing_gfn_account(gfn_get_info(&ce->gfns), 1); - mem_sharing_gfn_account(gfn_get_info(&se->gfns), 1); - list_for_each_safe(le, te, &ce->gfns) + cpage = mem_sharing_lookup(ch); + if(cpage == NULL) goto err_out; + + /* Merge the lists together */ + list_for_each_safe(le, te, cpage->shared_gfns) { - gfn = list_entry(le, struct gfn_info, list); + gfn = list_entry(le, gfn_info_t, list); /* Get the source page and type, this should never fail * because we are under shr lock, and got non-null se */ BUG_ON(!get_page_and_type(spage, dom_cow, PGT_shared_page)); @@ -564,13 +460,12 @@ int mem_sharing_share_pages(shr_handle_t list_del(&gfn->list); d = get_domain_by_id(gfn->domain); BUG_ON(!d); - BUG_ON(set_shared_p2m_entry(d, gfn->gfn, se->mfn) == 0); + BUG_ON(set_shared_p2m_entry(d, gfn->gfn, _mfn(sh)) == 0); put_domain(d); - list_add(&gfn->list, &se->gfns); + list_add(&gfn->list, spage->shared_gfns); put_page_and_type(cpage); - } - ASSERT(list_empty(&ce->gfns)); - mem_sharing_hash_delete(ch); + } + ASSERT(list_empty(cpage->shared_gfns)); atomic_inc(&nr_saved_mfns); /* Free the client page */ if(test_and_clear_bit(_PGC_allocated, &cpage->count_info)) @@ -592,9 +487,7 @@ int mem_sharing_unshare_page(struct doma struct page_info *page, *old_page; void *s, *t; int ret, last_gfn; - shr_hash_entry_t *hash_entry; - struct gfn_info *gfn_info = NULL; - shr_handle_t handle; + gfn_info_t *gfn_info = NULL; struct list_head *le; shr_lock(); @@ -604,37 +497,40 @@ int mem_sharing_unshare_page(struct doma mfn = gfn_to_mfn(d, gfn, &p2mt); /* Has someone already unshared it? */ - if (!p2m_is_shared(p2mt)) { + if (!p2m_is_shared(p2mt)) + { shr_unlock(); return 0; } - page = mfn_to_page(mfn); - handle = page->shr_handle; - - hash_entry = mem_sharing_hash_lookup(handle); - list_for_each(le, &hash_entry->gfns) + page = mem_sharing_lookup((shr_handle_t)mfn_x(mfn)); + if (page == NULL || page_get_owner(page) != dom_cow) { - gfn_info = list_entry(le, struct gfn_info, list); + printk("Domain p2m is shared, but page is not: %lx\n", gfn); + BUG(); + } + + list_for_each(le, page->shared_gfns) + { + gfn_info = list_entry(le, gfn_info_t, list); if((gfn_info->gfn == gfn) && (gfn_info->domain == d->domain_id)) goto gfn_found; } printk("Could not find gfn_info for shared gfn: %lx\n", gfn); BUG(); + gfn_found: /* Delete gfn_info from the list, but hold on to it, until we've allocated * memory to make a copy */ list_del(&gfn_info->list); - last_gfn = list_empty(&hash_entry->gfns); + last_gfn = list_empty(page->shared_gfns); /* If the GFN is getting destroyed drop the references to MFN * (possibly freeing the page), and exit early */ if(flags & MEM_SHARING_DESTROY_GFN) { mem_sharing_gfn_destroy(gfn_info, !last_gfn); - if(last_gfn) - mem_sharing_hash_delete(handle); - else + if(!last_gfn) /* Even though we don't allocate a private page, we have to account * for the MFN that originally backed this PFN. */ atomic_dec(&nr_saved_mfns); @@ -656,7 +552,7 @@ gfn_found: { /* We've failed to obtain memory for private page. Need to re-add the * gfn_info to relevant list */ - list_add(&gfn_info->list, &hash_entry->gfns); + list_add(&gfn_info->list, page->shared_gfns); shr_unlock(); return -ENOMEM; } @@ -673,9 +569,7 @@ gfn_found: private_page_found: /* We've got a private page, we can commit the gfn destruction */ mem_sharing_gfn_destroy(gfn_info, !last_gfn); - if(last_gfn) - mem_sharing_hash_delete(handle); - else + if(!last_gfn) atomic_dec(&nr_saved_mfns); if(p2m_change_type(d, gfn, p2m_ram_shared, p2m_ram_rw) != @@ -786,6 +680,5 @@ int mem_sharing_domctl(struct domain *d, void __init mem_sharing_init(void) { printk("Initing memory sharing.\n"); - mem_sharing_hash_init(); + mm_lock_init(&shr_lock); } - diff -r 38135be750ed xen/include/asm-x86/mem_sharing.h --- a/xen/include/asm-x86/mem_sharing.h +++ b/xen/include/asm-x86/mem_sharing.h @@ -41,9 +41,10 @@ int mem_sharing_unshare_page(struct doma int mem_sharing_sharing_resume(struct domain *d); int mem_sharing_domctl(struct domain *d, xen_domctl_mem_sharing_op_t *mec); + void mem_sharing_init(void); -#else +#else #define mem_sharing_init() do { } while (0) diff -r 38135be750ed xen/include/asm-x86/mm.h --- a/xen/include/asm-x86/mm.h +++ b/xen/include/asm-x86/mm.h @@ -49,8 +49,15 @@ struct page_info /* For non-pinnable single-page shadows, a higher entry that points * at us. */ paddr_t up; - /* For shared/sharable pages the sharing handle */ - uint64_t shr_handle; + /* For shared/sharable pages, we use a doubly-linked list + * of all the domains that map this page (w/ associated PFNs). + * Previously, this was a handle to a separate hashtable structure, + * however given that this is the only real information we need + * about a shared page, we can associate this directly with the + * page_info frame and use the mfn as the handle for usercode. + * This list is allocated and freed when a page is shared/unshared. + */ + struct list_head *shared_gfns; }; /* Reference count and various PGC_xxx flags and fields. */ --00151743f964bc2a9604ae2f8eb7 Content-Type: application/octet-stream; name="sharing-hashtable-drop.patch" Content-Disposition: attachment; filename="sharing-hashtable-drop.patch" Content-Transfer-Encoding: base64 X-Attachment-Id: f_gt7oux6w0 VGhlIGhhc2h0YWJsZSBtZWNoYW5pc20gdXNlZCBieSB0aGUgc2hhcmluZyBjb2RlIGlzIGEgYm90 dGxlbmVjay4KClRvIHJlbW92ZSBjb21wbGV4aXR5LCB0aGlzIHBhdGNoIHN0cmlwcyBvdXQgdGhl IGhhc2h0YWJsZSBhbmQgYWRkcyB0aGUKbmVjZXNzYXJ5IHNoYXJlZCBnZm4gaW5mb3JtYXRpb24g ZGlyZWN0bHkgaW50byB0aGUgcGFnZV9pbmZvIHN0cnVjdHVyZSAod2l0aG91dApjaGFuZ2luZyB0 aGUgc2l6ZSkuCgpUaGUgYXVkaXQgY29kZSBpcyBtYWRlIHRvIHNjYW4gYWxsIE1GTnMgaW5zdGVh ZCBvZiByZWx5aW5nIG9uIHRoZSBoYXNodGFibGUuCkFsdGhvdWdoIHRoaXMgbWF5IHRha2UgbW9y ZSB0aW1lLCB0aGlzIG1heSBiZSBtb3JlIHJvYnVzdCBzaW5jZSBpdCB3aWxsIGFsbG93CnVzIHRv IGRldGVjdCBwYWdlcyB0aGF0IGFyZSAic2hhcmVkIiBpbiB0eXBlIGJ1dCBmb3Igc29tZSByZWFz b24gd2UgaGF2ZW4ndAphY2NvdW50ZWQgZm9yIGNvcnJlY3RseSAtLSBhIGRpZmZlcmVudCBjbGFz cyBvZiBlcnJvci4gIChBbHRlcm5hdGl2ZWx5LCBhCmdsb2JhbCBsaXN0IG9mIHNoYXJlZCBwYWdl cyBjb3VsZCBhbHNvIGJlIGFkZGVkIHRvIGltcHJvdmUgb3IgZW5oYW5jZSB0aGUgYXVkaXQKY29k ZSBpbnN0ZWFkIG9mIHRoZSBvcmlnaW5hbCBoYXNodGFibGUgLS0gYnV0IHdlJ2Qgc3RpbGwgcmF0 aGVyIG5vdCBoYXZlIHRvCnNlYXJjaCB0aHJvdWdoIGl0IHdoZW4gc2hhcmluZyBvciB1bnNoYXJp bmcgYSBwYWdlLikKCmRpZmYgLXIgMzgxMzViZTc1MGVkIHhlbi9hcmNoL3g4Ni9tbS5jCi0tLSBh L3hlbi9hcmNoL3g4Ni9tbS5jCisrKyBiL3hlbi9hcmNoL3g4Ni9tbS5jCkBAIC00MjMwLDEyICs0 MjMwLDE5IEBAIGludCBwYWdlX21ha2Vfc2hhcmFibGUoc3RydWN0IGRvbWFpbiAqZCwKICAgICAg ICAgICAgICAgICAgICAgICAgc3RydWN0IHBhZ2VfaW5mbyAqcGFnZSwKICAgICAgICAgICAgICAg ICAgICAgICAgaW50IGV4cGVjdGVkX3JlZmNudCkKIHsKKyAgICBzdHJ1Y3QgbGlzdF9oZWFkICpz aGFyZWRfZ2ZucyA9IE5VTEw7CisKKyAgICBpZigoc2hhcmVkX2dmbnMgPSB4bWFsbG9jKHN0cnVj dCBsaXN0X2hlYWQpKSA9PSBOVUxMKQorICAgICAgICByZXR1cm4gLUVOT01FTTsKKyAgICBJTklU X0xJU1RfSEVBRChzaGFyZWRfZ2Zucyk7CisKICAgICBzcGluX2xvY2soJmQtPnBhZ2VfYWxsb2Nf bG9jayk7CgogICAgIC8qIENoYW5nZSBwYWdlIHR5cGUgYW5kIGNvdW50IGF0b21pY2FsbHkgKi8K ICAgICBpZiAoICFnZXRfcGFnZV9hbmRfdHlwZShwYWdlLCBkLCBQR1Rfc2hhcmVkX3BhZ2UpICkK ICAgICB7CiAgICAgICAgIHNwaW5fdW5sb2NrKCZkLT5wYWdlX2FsbG9jX2xvY2spOworICAgICAg ICB4ZnJlZShzaGFyZWRfZ2Zucyk7CiAgICAgICAgIHJldHVybiAtRUlOVkFMOwogICAgIH0KCkBA IC00MjQ0LDYgKzQyNTEsNyBAQCBpbnQgcGFnZV9tYWtlX3NoYXJhYmxlKHN0cnVjdCBkb21haW4g KmQsCiAgICAgewogICAgICAgICBwdXRfcGFnZV9hbmRfdHlwZShwYWdlKTsKICAgICAgICAgc3Bp bl91bmxvY2soJmQtPnBhZ2VfYWxsb2NfbG9jayk7CisgICAgICAgIHhmcmVlKHNoYXJlZF9nZm5z KTsKICAgICAgICAgcmV0dXJuIC1FRVhJU1Q7CiAgICAgfQoKQEAgLTQyNTQsMTIgKzQyNjIsMTQg QEAgaW50IHBhZ2VfbWFrZV9zaGFyYWJsZShzdHJ1Y3QgZG9tYWluICpkLAogICAgICAgICAvKiBS ZXR1cm4gdHlwZSBjb3VudCBiYWNrIHRvIHplcm8gKi8KICAgICAgICAgcHV0X3BhZ2VfYW5kX3R5 cGUocGFnZSk7CiAgICAgICAgIHNwaW5fdW5sb2NrKCZkLT5wYWdlX2FsbG9jX2xvY2spOworICAg ICAgICB4ZnJlZShzaGFyZWRfZ2Zucyk7CiAgICAgICAgIHJldHVybiAtRTJCSUc7CiAgICAgfQoK ICAgICBwYWdlX3NldF9vd25lcihwYWdlLCBkb21fY293KTsKICAgICBkLT50b3RfcGFnZXMtLTsK ICAgICBwYWdlX2xpc3RfZGVsKHBhZ2UsICZkLT5wYWdlX2xpc3QpOworICAgIHBhZ2UtPnNoYXJl ZF9nZm5zID0gc2hhcmVkX2dmbnM7CiAgICAgc3Bpbl91bmxvY2soJmQtPnBhZ2VfYWxsb2NfbG9j ayk7CiAgICAgcmV0dXJuIDA7CiB9CkBAIC00MjgwLDYgKzQyOTAsOSBAQCBpbnQgcGFnZV9tYWtl X3ByaXZhdGUoc3RydWN0IGRvbWFpbiAqZCwKICAgICAgICAgcmV0dXJuIC1FRVhJU1Q7CiAgICAg fQoKKyAgICAvKiBGcmVlIHRoZSBzaGFyZWQgcGFnZSBpbmZvICovCisgICAgeGZyZWUocGFnZS0+ c2hhcmVkX2dmbnMpOworCiAgICAgLyogRHJvcCB0aGUgZmluYWwgdHlwZWNvdW50ICovCiAgICAg cHV0X3BhZ2VfYW5kX3R5cGUocGFnZSk7CgpkaWZmIC1yIDM4MTM1YmU3NTBlZCB4ZW4vYXJjaC94 ODYvbW0vbWVtX3NoYXJpbmcuYwotLS0gYS94ZW4vYXJjaC94ODYvbW0vbWVtX3NoYXJpbmcuYwor KysgYi94ZW4vYXJjaC94ODYvbW0vbWVtX3NoYXJpbmcuYwpAQCAtMzksOCArMzksOCBAQAoKICNp ZiBNRU1fU0hBUklOR19BVURJVAogc3RhdGljIHZvaWQgbWVtX3NoYXJpbmdfYXVkaXQodm9pZCk7 Ci0jZGVmaW5lIE1FTV9TSEFSSU5HX0RFQlVHKF9mLCBfYS4uLikgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgXAotICAgIGRlYnVndHJhY2VfcHJpbnRrKCJtZW1fc2hhcmluZ19kZWJ1 ZzogJXMoKTogIiBfZiwgX19mdW5jX18sICMjX2EpCisjZGVmaW5lIE1FTV9TSEFSSU5HX0RFQlVH KF9mLCBfYS4uLikgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIFwKKyAgICAgZGVidWd0 cmFjZV9wcmludGsoIm1lbV9zaGFyaW5nX2RlYnVnOiAlcygpOiAiIF9mLCBfX2Z1bmNfXywgIyNf YSkKICNlbHNlCiAjIGRlZmluZSBtZW1fc2hhcmluZ19hdWRpdCgpIGRvIHt9IHdoaWxlKDApCiAj ZW5kaWYgLyogTUVNX1NIQVJJTkdfQVVESVQgKi8KQEAgLTU1LDE5ICs1NSw3IEBAIHN0YXRpYyB2 b2lkIG1lbV9zaGFyaW5nX2F1ZGl0KHZvaWQpOwogI3VuZGVmIHBhZ2VfdG9fbWZuCiAjZGVmaW5l IHBhZ2VfdG9fbWZuKF9wZykgX21mbihfX3BhZ2VfdG9fbWZuKF9wZykpCgotc3RhdGljIHNocl9o YW5kbGVfdCBuZXh0X2hhbmRsZSA9IDE7Ci1zdGF0aWMgYXRvbWljX3QgbnJfc2F2ZWRfbWZucyA9 IEFUT01JQ19JTklUKDApOwotCi10eXBlZGVmIHN0cnVjdCBzaHJfaGFzaF9lbnRyeQotewotICAg IHNocl9oYW5kbGVfdCBoYW5kbGU7Ci0gICAgbWZuX3QgbWZuOwotICAgIHN0cnVjdCBzaHJfaGFz aF9lbnRyeSAqbmV4dDsKLSAgICBzdHJ1Y3QgbGlzdF9oZWFkIGdmbnM7Ci19IHNocl9oYXNoX2Vu dHJ5X3Q7Ci0KLSNkZWZpbmUgU0hSX0hBU0hfTEVOR1RIIDEwMDAKLXN0YXRpYyBzaHJfaGFzaF9l bnRyeV90ICpzaHJfaGFzaFtTSFJfSEFTSF9MRU5HVEhdOworc3RhdGljIGF0b21pY190IG5yX3Nh dmVkX21mbnMgID0gQVRPTUlDX0lOSVQoMCk7CgogdHlwZWRlZiBzdHJ1Y3QgZ2ZuX2luZm8KIHsK QEAgLTg0LDI4ICs3Miw5IEBAIHN0YXRpYyBpbmxpbmUgaW50IGxpc3RfaGFzX29uZV9lbnRyeShz dHIKICAgICByZXR1cm4gKGhlYWQtPm5leHQgIT0gaGVhZCkgJiYgKGhlYWQtPm5leHQtPm5leHQg PT0gaGVhZCk7CiB9Cgotc3RhdGljIGlubGluZSBzdHJ1Y3QgZ2ZuX2luZm8qIGdmbl9nZXRfaW5m byhzdHJ1Y3QgbGlzdF9oZWFkICpsaXN0KQorc3RhdGljIGlubGluZSBnZm5faW5mb190KiBnZm5f Z2V0X2luZm8oc3RydWN0IGxpc3RfaGVhZCAqbGlzdCkKIHsKLSAgICByZXR1cm4gbGlzdF9lbnRy eShsaXN0LT5uZXh0LCBzdHJ1Y3QgZ2ZuX2luZm8sIGxpc3QpOwotfQotCi1zdGF0aWMgdm9pZCBf X2luaXQgbWVtX3NoYXJpbmdfaGFzaF9pbml0KHZvaWQpCi17Ci0gICAgaW50IGk7Ci0KLSAgICBt bV9sb2NrX2luaXQoJnNocl9sb2NrKTsKLSAgICBmb3IoaT0wOyBpPFNIUl9IQVNIX0xFTkdUSDsg aSsrKQotICAgICAgICBzaHJfaGFzaFtpXSA9IE5VTEw7Ci19Ci0KLXN0YXRpYyBzaHJfaGFzaF9l bnRyeV90ICptZW1fc2hhcmluZ19oYXNoX2FsbG9jKHZvaWQpCi17Ci0gICAgcmV0dXJuIHhtYWxs b2Moc2hyX2hhc2hfZW50cnlfdCk7Ci19Ci0KLXN0YXRpYyB2b2lkIG1lbV9zaGFyaW5nX2hhc2hf ZGVzdHJveShzaHJfaGFzaF9lbnRyeV90ICplKQotewotICAgIHhmcmVlKGUpOworICAgIHJldHVy biBsaXN0X2VudHJ5KGxpc3QtPm5leHQsIGdmbl9pbmZvX3QsIGxpc3QpOwogfQoKIHN0YXRpYyBn Zm5faW5mb190ICptZW1fc2hhcmluZ19nZm5fYWxsb2Modm9pZCkKQEAgLTEzMCwxMjUgKzk5LDk5 IEBAIHN0YXRpYyB2b2lkIG1lbV9zaGFyaW5nX2dmbl9kZXN0cm95KGdmbl8KICAgICB4ZnJlZShn Zm4pOwogfQoKLXN0YXRpYyBzaHJfaGFzaF9lbnRyeV90KiBtZW1fc2hhcmluZ19oYXNoX2xvb2t1 cChzaHJfaGFuZGxlX3QgaGFuZGxlKQorc3RhdGljIHN0cnVjdCBwYWdlX2luZm8qIG1lbV9zaGFy aW5nX2xvb2t1cChzaHJfaGFuZGxlX3QgaGFuZGxlKQogewotICAgIHNocl9oYXNoX2VudHJ5X3Qg KmU7Ci0KLSAgICBlID0gc2hyX2hhc2hbaGFuZGxlICUgU0hSX0hBU0hfTEVOR1RIXTsKLSAgICB3 aGlsZShlICE9IE5VTEwpCisgICAgaWYoIG1mbl92YWxpZChfbWZuKGhhbmRsZSkpICkKICAgICB7 Ci0gICAgICAgIGlmKGUtPmhhbmRsZSA9PSBoYW5kbGUpCi0gICAgICAgICAgICByZXR1cm4gZTsK LSAgICAgICAgZSA9IGUtPm5leHQ7CisgICAgICAgIHN0cnVjdCBwYWdlX2luZm8qIHBhZ2UgPSBt Zm5fdG9fcGFnZShfbWZuKGhhbmRsZSkpOworICAgICAgICBpZiggcGFnZV9nZXRfb3duZXIocGFn ZSkgPT0gZG9tX2NvdyApCisgICAgICAgICAgICByZXR1cm4gcGFnZTsKICAgICB9CgogICAgIHJl dHVybiBOVUxMOwogfQoKLXN0YXRpYyBzaHJfaGFzaF9lbnRyeV90KiBtZW1fc2hhcmluZ19oYXNo X2luc2VydChzaHJfaGFuZGxlX3QgaGFuZGxlLCBtZm5fdCBtZm4pCisjaWYgTUVNX1NIQVJJTkdf QVVESVQKK3N0YXRpYyBpbnQgbWVtX3NoYXJpbmdfYXVkaXQodm9pZCkKIHsKLSAgICBzaHJfaGFz aF9lbnRyeV90ICplLCAqKmVlOwotCi0gICAgZSA9IG1lbV9zaGFyaW5nX2hhc2hfYWxsb2MoKTsK LSAgICBpZihlID09IE5VTEwpIHJldHVybiBOVUxMOwotICAgIGUtPmhhbmRsZSA9IGhhbmRsZTsK LSAgICBlLT5tZm4gPSBtZm47Ci0gICAgZWUgPSAmc2hyX2hhc2hbaGFuZGxlICUgU0hSX0hBU0hf TEVOR1RIXTsKLSAgICBlLT5uZXh0ID0gKmVlOwotICAgICplZSA9IGU7Ci0gICAgcmV0dXJuIGU7 Ci19Ci0KLXN0YXRpYyB2b2lkIG1lbV9zaGFyaW5nX2hhc2hfZGVsZXRlKHNocl9oYW5kbGVfdCBo YW5kbGUpCi17Ci0gICAgc2hyX2hhc2hfZW50cnlfdCAqKnBwcmV2LCAqZTsKLQotICAgIHBwcmV2 ID0gJnNocl9oYXNoW2hhbmRsZSAlIFNIUl9IQVNIX0xFTkdUSF07Ci0gICAgZSA9ICpwcHJldjsK LSAgICB3aGlsZShlICE9IE5VTEwpCi0gICAgewotICAgICAgICBpZihlLT5oYW5kbGUgPT0gaGFu ZGxlKQotICAgICAgICB7Ci0gICAgICAgICAgICAqcHByZXYgPSBlLT5uZXh0OwotICAgICAgICAg ICAgbWVtX3NoYXJpbmdfaGFzaF9kZXN0cm95KGUpOwotICAgICAgICAgICAgcmV0dXJuOwotICAg ICAgICB9Ci0gICAgICAgIHBwcmV2ID0gJmUtPm5leHQ7Ci0gICAgICAgIGUgPSBlLT5uZXh0Owot ICAgIH0KLSAgICBwcmludGsoIkNvdWxkIG5vdCBmaW5kIHNociBlbnRyeSBmb3IgaGFuZGxlICUi UFJJeDY0IlxuIiwgaGFuZGxlKTsKLSAgICBCVUcoKTsKLX0KLQotI2lmIE1FTV9TSEFSSU5HX0FV RElUCi1zdGF0aWMgdm9pZCBtZW1fc2hhcmluZ19hdWRpdCh2b2lkKQotewotICAgIHNocl9oYXNo X2VudHJ5X3QgKmU7Ci0gICAgc3RydWN0IGxpc3RfaGVhZCAqbGU7Ci0gICAgZ2ZuX2luZm9fdCAq ZzsKLSAgICBpbnQgYnVja2V0OwotICAgIHN0cnVjdCBwYWdlX2luZm8gKnBnOworICAgIGludCBl cnJvcnMgPSAwOworICAgIHVuc2lnbmVkIGxvbmcgY291bnRfZm91bmQgPSAwOworICAgIHVuc2ln bmVkIGxvbmcgbWZuOwoKICAgICBBU1NFUlQoc2hyX2xvY2tlZF9ieV9tZSgpKTsKCi0gICAgZm9y KGJ1Y2tldD0wOyBidWNrZXQgPCBTSFJfSEFTSF9MRU5HVEg7IGJ1Y2tldCsrKQorICAgIGZvcigg bWZuID0gMDsgbWZuIDwgbWF4X3BhZ2U7IG1mbisrICkKICAgICB7Ci0gICAgICAgIGUgPSBzaHJf aGFzaFtidWNrZXRdOwotICAgICAgICAvKiBMb29wIG92ZXIgYWxsIHNocl9oYXNoX2VudHJpZXMg Ki8KLSAgICAgICAgd2hpbGUoZSAhPSBOVUxMKQorICAgICAgICB1bnNpZ25lZCBsb25nIG5yX2dm bnMgPSAwOworICAgICAgICBzdHJ1Y3QgcGFnZV9pbmZvICpwZzsKKyAgICAgICAgc3RydWN0IGxp c3RfaGVhZCAqbGU7CisgICAgICAgIGdmbl9pbmZvX3QgKmc7CisKKyAgICAgICAgaWYoICFtZm5f dmFsaWQoX21mbihtZm4pKSApCisgICAgICAgICAgICBjb250aW51ZTsKKworICAgICAgICBwZyA9 IG1mbl90b19wYWdlKF9tZm4obWZuKSk7CisKKyAgICAgICAgLyogQ2hlY2sgaWYgdGhlIE1GTiBo YXMgY29ycmVjdCB0eXBlLCBvd25lciBhbmQgaGFuZGxlLiAqLworICAgICAgICBpZigocGctPnUu aW51c2UudHlwZV9pbmZvICYgUEdUX3R5cGVfbWFzaykgIT0gUEdUX3NoYXJlZF9wYWdlKQorICAg ICAgICAgICAgY29udGludWU7CisKKyAgICAgICAgLyogQ291bnQgdGhpcyBwYWdlLiAqLworICAg ICAgICBjb3VudF9mb3VuZCsrOworCisgICAgICAgIC8qIENoZWNrIHRoZSBwYWdlIG93bmVyLiAq LworICAgICAgICBpZihwYWdlX2dldF9vd25lcihwZykgIT0gZG9tX2NvdykKICAgICAgICAgewot ICAgICAgICAgICAgaW50IG5yX2dmbnM9MDsKKyAgICAgICAgICAgTUVNX1NIQVJJTkdfREVCVUco Im1mbiAlbHggc2hhcmVkLCBidXQgd3Jvbmcgb3duZXIgKCVkKSFcbiIsCisgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgbWZuLCBwYWdlX2dldF9vd25lcihwZyktPmRvbWFpbl9pZCk7Cisg ICAgICAgICAgIGVycm9ycysrOworICAgICAgICB9CgotICAgICAgICAgICAgLyogQ2hlY2sgaWYg dGhlIE1GTiBoYXMgY29ycmVjdCB0eXBlLCBvd25lciBhbmQgaGFuZGxlICovCi0gICAgICAgICAg ICBwZyA9IG1mbl90b19wYWdlKGUtPm1mbik7Ci0gICAgICAgICAgICBpZigocGctPnUuaW51c2Uu dHlwZV9pbmZvICYgUEdUX3R5cGVfbWFzaykgIT0gUEdUX3NoYXJlZF9wYWdlKQotICAgICAgICAg ICAgICAgIE1FTV9TSEFSSU5HX0RFQlVHKCJtZm4gJWx4IG5vdCBzaGFyZWQsIGJ1dCBpbiB0aGUg aGFzaCFcbiIsCi0gICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIG1mbl94KGUtPm1m bikpOwotICAgICAgICAgICAgaWYocGFnZV9nZXRfb3duZXIocGcpICE9IGRvbV9jb3cpCi0gICAg ICAgICAgICAgICAgTUVNX1NIQVJJTkdfREVCVUcoIm1mbiAlbHggc2hhcmVkLCBidXQgd3Jvbmcg b3duZXIgKCVkKSFcbiIsCi0gICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIG1mbl94 KGUtPm1mbiksCi0gICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIHBhZ2VfZ2V0X293 bmVyKHBnKS0+ZG9tYWluX2lkKTsKLSAgICAgICAgICAgIGlmKGUtPmhhbmRsZSAhPSBwZy0+c2hy X2hhbmRsZSkKLSAgICAgICAgICAgICAgICBNRU1fU0hBUklOR19ERUJVRygibWZuICVseCBzaGFy ZWQsIGJ1dCB3cm9uZyBoYW5kbGUgIgotICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICIoJWxkICE9ICVsZCkhXG4iLAotICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICBt Zm5feChlLT5tZm4pLCBwZy0+c2hyX2hhbmRsZSwgZS0+aGFuZGxlKTsKLSAgICAgICAgICAgIC8q IENoZWNrIGlmIGFsbCBHRk5zIG1hcCB0byB0aGUgTUZOLCBhbmQgdGhlIHAybSB0eXBlcyAqLwot ICAgICAgICAgICAgbGlzdF9mb3JfZWFjaChsZSwgJmUtPmdmbnMpCisgICAgICAgIC8qIENoZWNr IGlmIGFsbCBHRk5zIG1hcCB0byB0aGUgTUZOLCBhbmQgdGhlIHAybSB0eXBlcyAqLworICAgICAg ICBsaXN0X2Zvcl9lYWNoKGxlLCBwZy0+c2hhcmVkX2dmbnMpCisgICAgICAgIHsKKyAgICAgICAg ICAgIHN0cnVjdCBkb21haW4gKmQ7CisgICAgICAgICAgICBwMm1fdHlwZV90IHQ7CisgICAgICAg ICAgICBtZm5fdCBvX21mbjsKKworICAgICAgICAgICAgZyA9IGxpc3RfZW50cnkobGUsIGdmbl9p bmZvX3QsIGxpc3QpOworICAgICAgICAgICAgZCA9IGdldF9kb21haW5fYnlfaWQoZy0+ZG9tYWlu KTsKKyAgICAgICAgICAgIGlmKGQgPT0gTlVMTCkKICAgICAgICAgICAgIHsKLSAgICAgICAgICAg ICAgICBzdHJ1Y3QgZG9tYWluICpkOwotICAgICAgICAgICAgICAgIHAybV90eXBlX3QgdDsKLSAg ICAgICAgICAgICAgICBtZm5fdCBtZm47CisgICAgICAgICAgICAgICAgTUVNX1NIQVJJTkdfREVC VUcoIlVua25vd24gZG9tOiAlZCwgZm9yIFBGTj0lbHgsIE1GTj0lbHhcbiIsCisgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgZy0+ZG9tYWluLCBnLT5nZm4sIG1mbik7CisgICAgICAg ICAgICAgICAgZXJyb3JzKys7CisgICAgICAgICAgICAgICAgY29udGludWU7CisgICAgICAgICAg ICB9CisgICAgICAgICAgICBvX21mbiA9IGdmbl90b19tZm4oZCwgZy0+Z2ZuLCAmdCk7CisgICAg ICAgICAgICBpZihtZm5feChvX21mbikgIT0gbWZuKQorICAgICAgICAgICAgeworICAgICAgICAg ICAgICAgIE1FTV9TSEFSSU5HX0RFQlVHKCJJbmNvcnJlY3QgUDJNIGZvciBkPSVkLCBQRk49JWx4 LiIKKyAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAiRXhwZWN0aW5nIE1GTj0lbGQs IGdvdCAlbGRcbiIsCisgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgZy0+ZG9tYWlu LCBnLT5nZm4sIG1mbiwgbWZuX3gob19tZm4pKTsKKyAgICAgICAgICAgICAgICBlcnJvcnMrKzsK KyAgICAgICAgICAgIH0KKyAgICAgICAgICAgIGlmKHQgIT0gcDJtX3JhbV9zaGFyZWQpCisgICAg ICAgICAgICB7CisgICAgICAgICAgICAgICAgTUVNX1NIQVJJTkdfREVCVUcoIkluY29ycmVjdCBQ Mk0gdHlwZSBmb3IgZD0lZCwgUEZOPSVseC4iCisgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgIkV4cGVjdGluZyB0PSVkLCBnb3QgJWRcbiIsCisgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgZy0+ZG9tYWluLCBnLT5nZm4sIG1mbiwgcDJtX3JhbV9zaGFyZWQsIHQpOwor ICAgICAgICAgICAgICAgIGVycm9ycysrOworICAgICAgICAgICAgfQorICAgICAgICAgICAgcHV0 X2RvbWFpbihkKTsKKyAgICAgICAgICAgIG5yX2dmbnMrKzsKKyAgICAgICAgfQoKLSAgICAgICAg ICAgICAgICBnID0gbGlzdF9lbnRyeShsZSwgc3RydWN0IGdmbl9pbmZvLCBsaXN0KTsKLSAgICAg ICAgICAgICAgICBkID0gZ2V0X2RvbWFpbl9ieV9pZChnLT5kb21haW4pOwotICAgICAgICAgICAg ICAgIGlmKGQgPT0gTlVMTCkKLSAgICAgICAgICAgICAgICB7Ci0gICAgICAgICAgICAgICAgICAg IE1FTV9TSEFSSU5HX0RFQlVHKCJVbmtub3cgZG9tOiAlZCwgZm9yIFBGTj0lbHgsIE1GTj0lbHhc biIsCi0gICAgICAgICAgICAgICAgICAgICAgICAgICAgZy0+ZG9tYWluLCBnLT5nZm4sIG1mbl94 KGUtPm1mbikpOwotICAgICAgICAgICAgICAgICAgICBjb250aW51ZTsKLSAgICAgICAgICAgICAg ICB9Ci0gICAgICAgICAgICAgICAgbWZuID0gZ2ZuX3RvX21mbihkLCBnLT5nZm4sICZ0KTsKLSAg ICAgICAgICAgICAgICBpZihtZm5feChtZm4pICE9IG1mbl94KGUtPm1mbikpCi0gICAgICAgICAg ICAgICAgICAgIE1FTV9TSEFSSU5HX0RFQlVHKCJJbmNvcnJlY3QgUDJNIGZvciBkPSVkLCBQRk49 JWx4LiIKLSAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIkV4cGVjdGluZyBN Rk49JWxkLCBnb3QgJWxkXG4iLAotICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICBnLT5kb21haW4sIGctPmdmbiwgbWZuX3goZS0+bWZuKSwKLSAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgbWZuX3gobWZuKSk7Ci0gICAgICAgICAgICAgICAgaWYodCAhPSBw Mm1fcmFtX3NoYXJlZCkKLSAgICAgICAgICAgICAgICAgICAgTUVNX1NIQVJJTkdfREVCVUcoIklu Y29ycmVjdCBQMk0gdHlwZSBmb3IgZD0lZCwgUEZOPSVseC4iCi0gICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICJFeHBlY3RpbmcgdD0lZCwgZ290ICVkXG4iLAotICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICBnLT5kb21haW4sIGctPmdmbiwgbWZuX3goZS0+ bWZuKSwKLSAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgcDJtX3JhbV9zaGFy ZWQsIHQpOwotICAgICAgICAgICAgICAgIHB1dF9kb21haW4oZCk7Ci0gICAgICAgICAgICAgICAg bnJfZ2ZucysrOwotICAgICAgICAgICAgfQotICAgICAgICAgICAgaWYobnJfZ2ZucyAhPSAocGct PnUuaW51c2UudHlwZV9pbmZvICYgUEdUX2NvdW50X21hc2spKQotICAgICAgICAgICAgICAgIE1F TV9TSEFSSU5HX0RFQlVHKCJNaXNtYXRjaGVkIGNvdW50cyBmb3IgTUZOPSVseC4iCi0gICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgIm5yX2dmbnMgaW4gaGFzaCAlZCwgaW4gdHlwZV9p bmZvICVkXG4iLAotICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIG1mbl94KGUtPm1m biksIG5yX2dmbnMsCi0gICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAocGctPnUuaW51 c2UudHlwZV9pbmZvICYgUEdUX2NvdW50X21hc2spKTsKLSAgICAgICAgICAgIGUgPSBlLT5uZXh0 OworICAgICAgICBpZihucl9nZm5zICE9IChwZy0+dS5pbnVzZS50eXBlX2luZm8gJiBQR1RfY291 bnRfbWFzaykpCisgICAgICAgIHsKKyAgICAgICAgICAgIE1FTV9TSEFSSU5HX0RFQlVHKCJNaXNt YXRjaGVkIGNvdW50cyBmb3IgTUZOPSVseC4iCisgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAibnJfZ2ZucyBpbiBoYXNoICVkLCBpbiB0eXBlX2luZm8gJWRcbiIsCisgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICBtZm4sIG5yX2dmbnMsIChwZy0+dS5pbnVzZS50eXBlX2luZm8gJiBQ R1RfY291bnRfbWFzaykpOworICAgICAgICAgICAgZXJyb3JzKys7CiAgICAgICAgIH0KICAgICB9 CisKKyAgICByZXR1cm4gZXJyb3JzOwogfQogI2VuZGlmCgpAQCAtMzkyLDM3ICszMzUsNiBAQCBz dGF0aWMgaW50IG1lbV9zaGFyaW5nX2dyZWZfdG9fZ2ZuKHN0cnVjCiAgICAgcmV0dXJuIC0yOwog fQoKLS8qIEFjY291bnQgZm9yIGEgR0ZOIGJlaW5nIHNoYXJlZC91bnNoYXJlZC4KLSAqIFdoZW4g c2hhcmluZyB0aGlzIGZ1bmN0aW9uIG5lZWRzIHRvIGJlIGNhbGxlZCBfYmVmb3JlXyBnZm4gbGlz dHMgYXJlIG1lcmdlZAotICogdG9nZXRoZXIsIGJ1dCBfYWZ0ZXJfIGdmbiBpcyByZW1vdmVkIGZy b20gdGhlIGxpc3Qgd2hlbiB1bnNoYXJpbmcuCi0gKi8KLXN0YXRpYyBpbnQgbWVtX3NoYXJpbmdf Z2ZuX2FjY291bnQoc3RydWN0IGdmbl9pbmZvICpnZm4sIGludCBzaGFyaW5nKQotewotICAgIHN0 cnVjdCBkb21haW4gKmQ7Ci0KLSAgICAvKiBBKSBXaGVuIHNoYXJpbmc6Ci0gICAgICogaWYgdGhl IGdmbiBiZWluZyBzaGFyZWQgaXMgaW4gPiAxIGxvbmcgbGlzdCwgaXRzIGFscmVhZHkgYmVlbgot ICAgICAqIGFjY291bnRlZCBmb3IKLSAgICAgKiBCKSBXaGVuIHVuc2hhcmluZzoKLSAgICAgKiBp ZiB0aGUgbGlzdCBpcyBsb25nZXIgdGhhbiA+IDEsIHdlIGRvbid0IGhhdmUgdG8gYWNjb3VudCB5 ZXQuCi0gICAgICovCi0gICAgaWYobGlzdF9oYXNfb25lX2VudHJ5KCZnZm4tPmxpc3QpKQotICAg IHsKLSAgICAgICAgZCA9IGdldF9kb21haW5fYnlfaWQoZ2ZuLT5kb21haW4pOwotICAgICAgICBC VUdfT04oIWQpOwotICAgICAgICBpZihzaGFyaW5nKQotICAgICAgICAgICAgYXRvbWljX2luYygm ZC0+c2hyX3BhZ2VzKTsKLSAgICAgICAgZWxzZQotICAgICAgICAgICAgYXRvbWljX2RlYygmZC0+ c2hyX3BhZ2VzKTsKLSAgICAgICAgcHV0X2RvbWFpbihkKTsKLQotICAgICAgICByZXR1cm4gMTsK LSAgICB9Ci0gICAgbWVtX3NoYXJpbmdfYXVkaXQoKTsKLQotICAgIHJldHVybiAwOwotfQotCiBp bnQgbWVtX3NoYXJpbmdfZGVidWdfZ3JlZihzdHJ1Y3QgZG9tYWluICpkLCBncmFudF9yZWZfdCBy ZWYpCiB7CiAgICAgZ3JhbnRfZW50cnlfaGVhZGVyX3QgKnNoYWg7CkBAIC00NTcsOCArMzY5LDYg QEAgaW50IG1lbV9zaGFyaW5nX25vbWluYXRlX3BhZ2Uoc3RydWN0IGRvbQogICAgIG1mbl90IG1m bjsKICAgICBzdHJ1Y3QgcGFnZV9pbmZvICpwYWdlOwogICAgIGludCByZXQ7Ci0gICAgc2hyX2hh bmRsZV90IGhhbmRsZTsKLSAgICBzaHJfaGFzaF9lbnRyeV90ICpoYXNoX2VudHJ5OwogICAgIHN0 cnVjdCBnZm5faW5mbyAqZ2ZuX2luZm87CgogICAgICpwaGFuZGxlID0gMFVMOwpAQCAtNDc0LDcg KzM4NCw3IEBAIGludCBtZW1fc2hhcmluZ19ub21pbmF0ZV9wYWdlKHN0cnVjdCBkb20KICAgICAv KiBSZXR1cm4gdGhlIGhhbmRsZSBpZiB0aGUgcGFnZSBpcyBhbHJlYWR5IHNoYXJlZCAqLwogICAg IHBhZ2UgPSBtZm5fdG9fcGFnZShtZm4pOwogICAgIGlmIChwMm1faXNfc2hhcmVkKHAybXQpKSB7 Ci0gICAgICAgICpwaGFuZGxlID0gcGFnZS0+c2hyX2hhbmRsZTsKKyAgICAgICAgKnBoYW5kbGUg PSBtZm5feChtZm4pOwogICAgICAgICByZXQgPSAwOwogICAgICAgICBnb3RvIG91dDsKICAgICB9 CkBAIC00OTAsMTYgKzQwMCw4IEBAIGludCBtZW1fc2hhcmluZ19ub21pbmF0ZV9wYWdlKHN0cnVj dCBkb20KCiAgICAgLyogQ3JlYXRlIHRoZSBoYW5kbGUgKi8KICAgICByZXQgPSAtRU5PTUVNOwot ICAgIGhhbmRsZSA9IG5leHRfaGFuZGxlKys7Ci0gICAgaWYoKGhhc2hfZW50cnkgPSBtZW1fc2hh cmluZ19oYXNoX2luc2VydChoYW5kbGUsIG1mbikpID09IE5VTEwpCi0gICAgeworICAgIGlmKChn Zm5faW5mbyA9IG1lbV9zaGFyaW5nX2dmbl9hbGxvYygpKSA9PSBOVUxMKQogICAgICAgICBnb3Rv IG91dDsKLSAgICB9Ci0gICAgaWYoKGdmbl9pbmZvID0gbWVtX3NoYXJpbmdfZ2ZuX2FsbG9jKCkp ID09IE5VTEwpCi0gICAgewotICAgICAgICBtZW1fc2hhcmluZ19oYXNoX2Rlc3Ryb3koaGFzaF9l bnRyeSk7Ci0gICAgICAgIGdvdG8gb3V0OwotICAgIH0KCiAgICAgLyogQ2hhbmdlIHRoZSBwMm0g dHlwZSAqLwogICAgIGlmKHAybV9jaGFuZ2VfdHlwZShkLCBnZm4sIHAybXQsIHAybV9yYW1fc2hh cmVkKSAhPSBwMm10KQpAQCAtNTA5LDcgKzQxMSw2IEBAIGludCBtZW1fc2hhcmluZ19ub21pbmF0 ZV9wYWdlKHN0cnVjdCBkb20KICAgICAgICAgICogVGhlIG1mbiBuZWVkcyB0byByZXZlcnQgYmFj ayB0byBydyB0eXBlLiBUaGlzIHNob3VsZCBuZXZlciBmYWlsLAogICAgICAgICAgKiBzaW5jZSBu by1vbmUga25ldyB0aGF0IHRoZSBtZm4gd2FzIHRlbXBvcmFyaWx5IHNoYXJhYmxlICovCiAgICAg ICAgIEJVR19PTihwYWdlX21ha2VfcHJpdmF0ZShkLCBwYWdlKSAhPSAwKTsKLSAgICAgICAgbWVt X3NoYXJpbmdfaGFzaF9kZXN0cm95KGhhc2hfZW50cnkpOwogICAgICAgICBtZW1fc2hhcmluZ19n Zm5fZGVzdHJveShnZm5faW5mbywgMCk7CiAgICAgICAgIGdvdG8gb3V0OwogICAgIH0KQEAgLTUx NywxMyArNDE4LDEyIEBAIGludCBtZW1fc2hhcmluZ19ub21pbmF0ZV9wYWdlKHN0cnVjdCBkb20K ICAgICAvKiBVcGRhdGUgbTJwIGVudHJ5IHRvIFNIQVJFRF9NMlBfRU5UUlkgKi8KICAgICBzZXRf Z3Bmbl9mcm9tX21mbihtZm5feChtZm4pLCBTSEFSRURfTTJQX0VOVFJZKTsKCi0gICAgSU5JVF9M SVNUX0hFQUQoJmhhc2hfZW50cnktPmdmbnMpOwogICAgIElOSVRfTElTVF9IRUFEKCZnZm5faW5m by0+bGlzdCk7Ci0gICAgbGlzdF9hZGQoJmdmbl9pbmZvLT5saXN0LCAmaGFzaF9lbnRyeS0+Z2Zu cyk7CisgICAgbGlzdF9hZGQoJmdmbl9pbmZvLT5saXN0LCBwYWdlLT5zaGFyZWRfZ2Zucyk7CiAg ICAgZ2ZuX2luZm8tPmdmbiA9IGdmbjsKICAgICBnZm5faW5mby0+ZG9tYWluID0gZC0+ZG9tYWlu X2lkOwotICAgIHBhZ2UtPnNocl9oYW5kbGUgPSBoYW5kbGU7Ci0gICAgKnBoYW5kbGUgPSBoYW5k bGU7CisgICAgKnBoYW5kbGUgPSBtZm5feChtZm4pOworICAgIGF0b21pY19pbmMoJmQtPnNocl9w YWdlcyk7CgogICAgIHJldCA9IDA7CgpAQCAtNTM0LDI5ICs0MzQsMjUgQEAgb3V0OgoKIGludCBt ZW1fc2hhcmluZ19zaGFyZV9wYWdlcyhzaHJfaGFuZGxlX3Qgc2gsIHNocl9oYW5kbGVfdCBjaCkK IHsKLSAgICBzaHJfaGFzaF9lbnRyeV90ICpzZSwgKmNlOwogICAgIHN0cnVjdCBwYWdlX2luZm8g KnNwYWdlLCAqY3BhZ2U7CiAgICAgc3RydWN0IGxpc3RfaGVhZCAqbGUsICp0ZTsKLSAgICBzdHJ1 Y3QgZ2ZuX2luZm8gKmdmbjsKKyAgICBnZm5faW5mb190ICpnZm47CiAgICAgc3RydWN0IGRvbWFp biAqZDsKICAgICBpbnQgcmV0OwoKICAgICBzaHJfbG9jaygpOwoKICAgICByZXQgPSBYRU5fRE9N Q1RMX01FTV9TSEFSSU5HX1NfSEFORExFX0lOVkFMSUQ7Ci0gICAgc2UgPSBtZW1fc2hhcmluZ19o YXNoX2xvb2t1cChzaCk7Ci0gICAgaWYoc2UgPT0gTlVMTCkgZ290byBlcnJfb3V0OworICAgIHNw YWdlID0gbWVtX3NoYXJpbmdfbG9va3VwKHNoKTsKKyAgICBpZihzcGFnZSA9PSBOVUxMKSBnb3Rv IGVycl9vdXQ7CiAgICAgcmV0ID0gWEVOX0RPTUNUTF9NRU1fU0hBUklOR19DX0hBTkRMRV9JTlZB TElEOwotICAgIGNlID0gbWVtX3NoYXJpbmdfaGFzaF9sb29rdXAoY2gpOwotICAgIGlmKGNlID09 IE5VTEwpIGdvdG8gZXJyX291dDsKLSAgICBzcGFnZSA9IG1mbl90b19wYWdlKHNlLT5tZm4pOwot ICAgIGNwYWdlID0gbWZuX3RvX3BhZ2UoY2UtPm1mbik7Ci0gICAgLyogZ2ZuIGxpc3RzIGFsd2F5 cyBoYXZlIGF0IGxlYXN0IG9uZSBlbnRyeSA9PiBzYXZlIHRvIGNhbGwgbGlzdF9lbnRyeSAqLwot ICAgIG1lbV9zaGFyaW5nX2dmbl9hY2NvdW50KGdmbl9nZXRfaW5mbygmY2UtPmdmbnMpLCAxKTsK LSAgICBtZW1fc2hhcmluZ19nZm5fYWNjb3VudChnZm5fZ2V0X2luZm8oJnNlLT5nZm5zKSwgMSk7 Ci0gICAgbGlzdF9mb3JfZWFjaF9zYWZlKGxlLCB0ZSwgJmNlLT5nZm5zKQorICAgIGNwYWdlID0g bWVtX3NoYXJpbmdfbG9va3VwKGNoKTsKKyAgICBpZihjcGFnZSA9PSBOVUxMKSBnb3RvIGVycl9v dXQ7CisKKyAgICAvKiBNZXJnZSB0aGUgbGlzdHMgdG9nZXRoZXIgKi8KKyAgICBsaXN0X2Zvcl9l YWNoX3NhZmUobGUsIHRlLCBjcGFnZS0+c2hhcmVkX2dmbnMpCiAgICAgewotICAgICAgICBnZm4g PSBsaXN0X2VudHJ5KGxlLCBzdHJ1Y3QgZ2ZuX2luZm8sIGxpc3QpOworICAgICAgICBnZm4gPSBs aXN0X2VudHJ5KGxlLCBnZm5faW5mb190LCBsaXN0KTsKICAgICAgICAgLyogR2V0IHRoZSBzb3Vy Y2UgcGFnZSBhbmQgdHlwZSwgdGhpcyBzaG91bGQgbmV2ZXIgZmFpbAogICAgICAgICAgKiBiZWNh dXNlIHdlIGFyZSB1bmRlciBzaHIgbG9jaywgYW5kIGdvdCBub24tbnVsbCBzZSAqLwogICAgICAg ICBCVUdfT04oIWdldF9wYWdlX2FuZF90eXBlKHNwYWdlLCBkb21fY293LCBQR1Rfc2hhcmVkX3Bh Z2UpKTsKQEAgLTU2NCwxMyArNDYwLDEyIEBAIGludCBtZW1fc2hhcmluZ19zaGFyZV9wYWdlcyhz aHJfaGFuZGxlX3QKICAgICAgICAgbGlzdF9kZWwoJmdmbi0+bGlzdCk7CiAgICAgICAgIGQgPSBn ZXRfZG9tYWluX2J5X2lkKGdmbi0+ZG9tYWluKTsKICAgICAgICAgQlVHX09OKCFkKTsKLSAgICAg ICAgQlVHX09OKHNldF9zaGFyZWRfcDJtX2VudHJ5KGQsIGdmbi0+Z2ZuLCBzZS0+bWZuKSA9PSAw KTsKKyAgICAgICAgQlVHX09OKHNldF9zaGFyZWRfcDJtX2VudHJ5KGQsIGdmbi0+Z2ZuLCBfbWZu KHNoKSkgPT0gMCk7CiAgICAgICAgIHB1dF9kb21haW4oZCk7Ci0gICAgICAgIGxpc3RfYWRkKCZn Zm4tPmxpc3QsICZzZS0+Z2Zucyk7CisgICAgICAgIGxpc3RfYWRkKCZnZm4tPmxpc3QsIHNwYWdl LT5zaGFyZWRfZ2Zucyk7CiAgICAgICAgIHB1dF9wYWdlX2FuZF90eXBlKGNwYWdlKTsKLSAgICB9 Ci0gICAgQVNTRVJUKGxpc3RfZW1wdHkoJmNlLT5nZm5zKSk7Ci0gICAgbWVtX3NoYXJpbmdfaGFz aF9kZWxldGUoY2gpOworICAgIH0KKyAgICBBU1NFUlQobGlzdF9lbXB0eShjcGFnZS0+c2hhcmVk X2dmbnMpKTsKICAgICBhdG9taWNfaW5jKCZucl9zYXZlZF9tZm5zKTsKICAgICAvKiBGcmVlIHRo ZSBjbGllbnQgcGFnZSAqLwogICAgIGlmKHRlc3RfYW5kX2NsZWFyX2JpdChfUEdDX2FsbG9jYXRl ZCwgJmNwYWdlLT5jb3VudF9pbmZvKSkKQEAgLTU5Miw5ICs0ODcsNyBAQCBpbnQgbWVtX3NoYXJp bmdfdW5zaGFyZV9wYWdlKHN0cnVjdCBkb21hCiAgICAgc3RydWN0IHBhZ2VfaW5mbyAqcGFnZSwg Km9sZF9wYWdlOwogICAgIHZvaWQgKnMsICp0OwogICAgIGludCByZXQsIGxhc3RfZ2ZuOwotICAg IHNocl9oYXNoX2VudHJ5X3QgKmhhc2hfZW50cnk7Ci0gICAgc3RydWN0IGdmbl9pbmZvICpnZm5f aW5mbyA9IE5VTEw7Ci0gICAgc2hyX2hhbmRsZV90IGhhbmRsZTsKKyAgICBnZm5faW5mb190ICpn Zm5faW5mbyA9IE5VTEw7CiAgICAgc3RydWN0IGxpc3RfaGVhZCAqbGU7CgogICAgIHNocl9sb2Nr KCk7CkBAIC02MDQsMzcgKzQ5Nyw0MCBAQCBpbnQgbWVtX3NoYXJpbmdfdW5zaGFyZV9wYWdlKHN0 cnVjdCBkb21hCiAgICAgbWZuID0gZ2ZuX3RvX21mbihkLCBnZm4sICZwMm10KTsKCiAgICAgLyog SGFzIHNvbWVvbmUgYWxyZWFkeSB1bnNoYXJlZCBpdD8gKi8KLSAgICBpZiAoIXAybV9pc19zaGFy ZWQocDJtdCkpIHsKKyAgICBpZiAoIXAybV9pc19zaGFyZWQocDJtdCkpCisgICAgewogICAgICAg ICBzaHJfdW5sb2NrKCk7CiAgICAgICAgIHJldHVybiAwOwogICAgIH0KCi0gICAgcGFnZSA9IG1m bl90b19wYWdlKG1mbik7Ci0gICAgaGFuZGxlID0gcGFnZS0+c2hyX2hhbmRsZTsKLQotICAgIGhh c2hfZW50cnkgPSBtZW1fc2hhcmluZ19oYXNoX2xvb2t1cChoYW5kbGUpOwotICAgIGxpc3RfZm9y X2VhY2gobGUsICZoYXNoX2VudHJ5LT5nZm5zKQorICAgIHBhZ2UgPSBtZW1fc2hhcmluZ19sb29r dXAoKHNocl9oYW5kbGVfdCltZm5feChtZm4pKTsKKyAgICBpZiAocGFnZSA9PSBOVUxMIHx8IHBh Z2VfZ2V0X293bmVyKHBhZ2UpICE9IGRvbV9jb3cpCiAgICAgewotICAgICAgICBnZm5faW5mbyA9 IGxpc3RfZW50cnkobGUsIHN0cnVjdCBnZm5faW5mbywgbGlzdCk7CisgICAgICAgIHByaW50aygi RG9tYWluIHAybSBpcyBzaGFyZWQsIGJ1dCBwYWdlIGlzIG5vdDogJWx4XG4iLCBnZm4pOworICAg ICAgICBCVUcoKTsKKyAgICB9CisKKyAgICBsaXN0X2Zvcl9lYWNoKGxlLCBwYWdlLT5zaGFyZWRf Z2ZucykKKyAgICB7CisgICAgICAgIGdmbl9pbmZvID0gbGlzdF9lbnRyeShsZSwgZ2ZuX2luZm9f dCwgbGlzdCk7CiAgICAgICAgIGlmKChnZm5faW5mby0+Z2ZuID09IGdmbikgJiYgKGdmbl9pbmZv LT5kb21haW4gPT0gZC0+ZG9tYWluX2lkKSkKICAgICAgICAgICAgIGdvdG8gZ2ZuX2ZvdW5kOwog ICAgIH0KICAgICBwcmludGsoIkNvdWxkIG5vdCBmaW5kIGdmbl9pbmZvIGZvciBzaGFyZWQgZ2Zu OiAlbHhcbiIsIGdmbik7CiAgICAgQlVHKCk7CisKIGdmbl9mb3VuZDoKICAgICAvKiBEZWxldGUg Z2ZuX2luZm8gZnJvbSB0aGUgbGlzdCwgYnV0IGhvbGQgb24gdG8gaXQsIHVudGlsIHdlJ3ZlIGFs bG9jYXRlZAogICAgICAqIG1lbW9yeSB0byBtYWtlIGEgY29weSAqLwogICAgIGxpc3RfZGVsKCZn Zm5faW5mby0+bGlzdCk7Ci0gICAgbGFzdF9nZm4gPSBsaXN0X2VtcHR5KCZoYXNoX2VudHJ5LT5n Zm5zKTsKKyAgICBsYXN0X2dmbiA9IGxpc3RfZW1wdHkocGFnZS0+c2hhcmVkX2dmbnMpOwoKICAg ICAvKiBJZiB0aGUgR0ZOIGlzIGdldHRpbmcgZGVzdHJveWVkIGRyb3AgdGhlIHJlZmVyZW5jZXMg dG8gTUZOCiAgICAgICogKHBvc3NpYmx5IGZyZWVpbmcgdGhlIHBhZ2UpLCBhbmQgZXhpdCBlYXJs eSAqLwogICAgIGlmKGZsYWdzICYgTUVNX1NIQVJJTkdfREVTVFJPWV9HRk4pCiAgICAgewogICAg ICAgICBtZW1fc2hhcmluZ19nZm5fZGVzdHJveShnZm5faW5mbywgIWxhc3RfZ2ZuKTsKLSAgICAg ICAgaWYobGFzdF9nZm4pCi0gICAgICAgICAgICBtZW1fc2hhcmluZ19oYXNoX2RlbGV0ZShoYW5k bGUpOwotICAgICAgICBlbHNlCisgICAgICAgIGlmKCFsYXN0X2dmbikKICAgICAgICAgICAgIC8q IEV2ZW4gdGhvdWdoIHdlIGRvbid0IGFsbG9jYXRlIGEgcHJpdmF0ZSBwYWdlLCB3ZSBoYXZlIHRv IGFjY291bnQKICAgICAgICAgICAgICAqIGZvciB0aGUgTUZOIHRoYXQgb3JpZ2luYWxseSBiYWNr ZWQgdGhpcyBQRk4uICovCiAgICAgICAgICAgICBhdG9taWNfZGVjKCZucl9zYXZlZF9tZm5zKTsK QEAgLTY1Niw3ICs1NTIsNyBAQCBnZm5fZm91bmQ6CiAgICAgewogICAgICAgICAvKiBXZSd2ZSBm YWlsZWQgdG8gb2J0YWluIG1lbW9yeSBmb3IgcHJpdmF0ZSBwYWdlLiBOZWVkIHRvIHJlLWFkZCB0 aGUKICAgICAgICAgICogZ2ZuX2luZm8gdG8gcmVsZXZhbnQgbGlzdCAqLwotICAgICAgICBsaXN0 X2FkZCgmZ2ZuX2luZm8tPmxpc3QsICZoYXNoX2VudHJ5LT5nZm5zKTsKKyAgICAgICAgbGlzdF9h ZGQoJmdmbl9pbmZvLT5saXN0LCBwYWdlLT5zaGFyZWRfZ2Zucyk7CiAgICAgICAgIHNocl91bmxv Y2soKTsKICAgICAgICAgcmV0dXJuIC1FTk9NRU07CiAgICAgfQpAQCAtNjczLDkgKzU2OSw3IEBA IGdmbl9mb3VuZDoKIHByaXZhdGVfcGFnZV9mb3VuZDoKICAgICAvKiBXZSd2ZSBnb3QgYSBwcml2 YXRlIHBhZ2UsIHdlIGNhbiBjb21taXQgdGhlIGdmbiBkZXN0cnVjdGlvbiAqLwogICAgIG1lbV9z aGFyaW5nX2dmbl9kZXN0cm95KGdmbl9pbmZvLCAhbGFzdF9nZm4pOwotICAgIGlmKGxhc3RfZ2Zu KQotICAgICAgICBtZW1fc2hhcmluZ19oYXNoX2RlbGV0ZShoYW5kbGUpOwotICAgIGVsc2UKKyAg ICBpZighbGFzdF9nZm4pCiAgICAgICAgIGF0b21pY19kZWMoJm5yX3NhdmVkX21mbnMpOwoKICAg ICBpZihwMm1fY2hhbmdlX3R5cGUoZCwgZ2ZuLCBwMm1fcmFtX3NoYXJlZCwgcDJtX3JhbV9ydykg IT0KQEAgLTc4Niw2ICs2ODAsNSBAQCBpbnQgbWVtX3NoYXJpbmdfZG9tY3RsKHN0cnVjdCBkb21h aW4gKmQsCiB2b2lkIF9faW5pdCBtZW1fc2hhcmluZ19pbml0KHZvaWQpCiB7CiAgICAgcHJpbnRr KCJJbml0aW5nIG1lbW9yeSBzaGFyaW5nLlxuIik7Ci0gICAgbWVtX3NoYXJpbmdfaGFzaF9pbml0 KCk7CisgICAgbW1fbG9ja19pbml0KCZzaHJfbG9jayk7CiB9Ci0KZGlmZiAtciAzODEzNWJlNzUw ZWQgeGVuL2luY2x1ZGUvYXNtLXg4Ni9tZW1fc2hhcmluZy5oCi0tLSBhL3hlbi9pbmNsdWRlL2Fz bS14ODYvbWVtX3NoYXJpbmcuaAorKysgYi94ZW4vaW5jbHVkZS9hc20teDg2L21lbV9zaGFyaW5n LmgKQEAgLTQxLDkgKzQxLDEwIEBAIGludCBtZW1fc2hhcmluZ191bnNoYXJlX3BhZ2Uoc3RydWN0 IGRvbWEKIGludCBtZW1fc2hhcmluZ19zaGFyaW5nX3Jlc3VtZShzdHJ1Y3QgZG9tYWluICpkKTsK IGludCBtZW1fc2hhcmluZ19kb21jdGwoc3RydWN0IGRvbWFpbiAqZCwKICAgICAgICAgICAgICAg ICAgICAgICAgeGVuX2RvbWN0bF9tZW1fc2hhcmluZ19vcF90ICptZWMpOworCiB2b2lkIG1lbV9z aGFyaW5nX2luaXQodm9pZCk7CgotI2Vsc2UKKyNlbHNlCgogI2RlZmluZSBtZW1fc2hhcmluZ19p bml0KCkgIGRvIHsgfSB3aGlsZSAoMCkKCmRpZmYgLXIgMzgxMzViZTc1MGVkIHhlbi9pbmNsdWRl L2FzbS14ODYvbW0uaAotLS0gYS94ZW4vaW5jbHVkZS9hc20teDg2L21tLmgKKysrIGIveGVuL2lu Y2x1ZGUvYXNtLXg4Ni9tbS5oCkBAIC00OSw4ICs0OSwxNSBAQCBzdHJ1Y3QgcGFnZV9pbmZvCiAg ICAgICAgIC8qIEZvciBub24tcGlubmFibGUgc2luZ2xlLXBhZ2Ugc2hhZG93cywgYSBoaWdoZXIg ZW50cnkgdGhhdCBwb2ludHMKICAgICAgICAgICogYXQgdXMuICovCiAgICAgICAgIHBhZGRyX3Qg dXA7Ci0gICAgICAgIC8qIEZvciBzaGFyZWQvc2hhcmFibGUgcGFnZXMgdGhlIHNoYXJpbmcgaGFu ZGxlICovCi0gICAgICAgIHVpbnQ2NF90IHNocl9oYW5kbGU7CisgICAgICAgIC8qIEZvciBzaGFy ZWQvc2hhcmFibGUgcGFnZXMsIHdlIHVzZSBhIGRvdWJseS1saW5rZWQgbGlzdAorICAgICAgICAg KiBvZiBhbGwgdGhlIGRvbWFpbnMgdGhhdCBtYXAgdGhpcyBwYWdlICh3LyBhc3NvY2lhdGVkIFBG TnMpLgorICAgICAgICAgKiBQcmV2aW91c2x5LCB0aGlzIHdhcyBhIGhhbmRsZSB0byBhIHNlcGFy YXRlIGhhc2h0YWJsZSBzdHJ1Y3R1cmUsCisgICAgICAgICAqIGhvd2V2ZXIgZ2l2ZW4gdGhhdCB0 aGlzIGlzIHRoZSBvbmx5IHJlYWwgaW5mb3JtYXRpb24gd2UgbmVlZAorICAgICAgICAgKiBhYm91 dCBhIHNoYXJlZCBwYWdlLCB3ZSBjYW4gYXNzb2NpYXRlIHRoaXMgZGlyZWN0bHkgd2l0aCB0aGUK KyAgICAgICAgICogcGFnZV9pbmZvIGZyYW1lIGFuZCB1c2UgdGhlIG1mbiBhcyB0aGUgaGFuZGxl IGZvciB1c2VyY29kZS4KKyAgICAgICAgICogVGhpcyBsaXN0IGlzIGFsbG9jYXRlZCBhbmQgZnJl ZWQgd2hlbiBhIHBhZ2UgaXMgc2hhcmVkL3Vuc2hhcmVkLgorICAgICAgICAgKi8KKyAgICAgICAg c3RydWN0IGxpc3RfaGVhZCAqc2hhcmVkX2dmbnM7CiAgICAgfTsKCiAgICAgLyogUmVmZXJlbmNl IGNvdW50IGFuZCB2YXJpb3VzIFBHQ194eHggZmxhZ3MgYW5kIGZpZWxkcy4gKi8K --00151743f964bc2a9604ae2f8eb7 Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel --00151743f964bc2a9604ae2f8eb7-- From xen-devel-bounces@lists.xensource.com Fri Sep 30 15:20:40 2011 Return-path: <xen-devel-bounces@lists.xensource.com> Envelope-to: www-data@lists.xensource.com Delivery-date: Fri, 30 Sep 2011 15:20:40 -0700 Received: from localhost ([127.0.0.1] helo=lists.colo.xensource.com) by lists.xensource.com with esmtp (Exim 4.43) id 1R9lRf-0004lw-SM; Fri, 30 Sep 2011 15:20:39 -0700 Received: from mail21.messagelabs.com ([85.158.143.35]) by lists.xensource.com with esmtp (Exim 4.43) id 1R9lQC-0004Yz-Ip for xen-devel@lists.xensource.com; Fri, 30 Sep 2011 15:19:14 -0700 X-Env-Sender: tim@xen.org X-Msg-Ref: server-5.tower-21.messagelabs.com!1317421110!50210022!1 X-Originating-IP: [81.29.64.94] X-StarScan-Version: 6.4.1; banners=-,-,- X-VirusChecked: Checked Received: (qmail 1928 invoked from network); 30 Sep 2011 22:18:30 -0000 Received: from ocelot.phlegethon.org (HELO mail.phlegethon.org) (81.29.64.94) by server-5.tower-21.messagelabs.com with DHE-RSA-AES256-SHA encrypted SMTP; 30 Sep 2011 22:18:30 -0000 Received: from tjd by mail.phlegethon.org with local (Exim 4.67 (FreeBSD)) (envelope-from <tim@xen.org>) id 1R9lQ7-000GPU-O6; Fri, 30 Sep 2011 22:19:03 +0000 Date: Fri, 30 Sep 2011 23:19:03 +0100 From: Tim Deegan <tim@xen.org> To: Adin Scannell <adin@gridcentric.ca> Subject: Re: [Xen-devel] Re: mapping problems in xenpaging Message-ID: <20110930221903.GB62963@ocelot.phlegethon.org> References: <CACavRyB4kvMLZK1-vv9bJnVdnpKJBHTmnhJxt6g3eh88xY6FTg@mail.gmail.com> <20110929170244.GA29163@aepfle.de> <CAAJKtqrFuJkNAZZhRs8tC0ymgQTD0G2VTgYexQ9EhnCxsJNZuw@mail.gmail.com> Mime-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline In-Reply-To: <CAAJKtqrFuJkNAZZhRs8tC0ymgQTD0G2VTgYexQ9EhnCxsJNZuw@mail.gmail.com> User-Agent: Mutt/1.4.2.1i Cc: Olaf Hering <olaf@aepfle.de>, xen-devel@lists.xensource.com, zhen shi <bickys1986@gmail.com> X-BeenThere: xen-devel@lists.xensource.com X-Mailman-Version: 2.1.5 Precedence: list List-Id: Xen developer discussion <xen-devel.lists.xensource.com> List-Unsubscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe> List-Post: <mailto:xen-devel@lists.xensource.com> List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help> List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=subscribe> Sender: xen-devel-bounces@lists.xensource.com Errors-To: xen-devel-bounces@lists.xensource.com At 17:02 -0400 on 30 Sep (1317402151), Adin Scannell wrote: > I believe I have recreated this problem a few times, resulting in > various crashes... unfortunately, there is somewhat of an implicit > assumption throughout the code that when you grab an mfn via > gfn_to_mfn, that mfn won't disappear underneath you (for example, see > vmx_load_pdptrs). Really, you want something like gfn_to_mfn_getpage, > where the underlying page has its refcount bumped so that it won't be > nominated/evicted while you map and use the page, then you must put it > back when you're done. Quite right - there are a lot of places that assume that a p2m mapping won't change underfoot, and the right answer will involve reference counting of some kind - either better integration with the underlying refcount/typecount system or some reference count in the p2m. The tricky part will be what to do when a p2m update can't be made because of one of those refcounts. Tim. _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel From xen-devel-bounces@lists.xensource.com Fri Sep 30 15:47:23 2011 Return-path: <xen-devel-bounces@lists.xensource.com> Envelope-to: www-data@lists.xensource.com Delivery-date: Fri, 30 Sep 2011 15:47:23 -0700 Received: from localhost ([127.0.0.1] helo=lists.colo.xensource.com) by lists.xensource.com with esmtp (Exim 4.43) id 1R9lrW-0006cq-TF; Fri, 30 Sep 2011 15:47:22 -0700 Received: from mail216.messagelabs.com ([85.158.143.99]) by lists.xensource.com with esmtp (Exim 4.43) id 1R9lqp-0006QW-SO for xen-devel@lists.xensource.com; Fri, 30 Sep 2011 15:46:40 -0700 X-Env-Sender: tim@xen.org X-Msg-Ref: server-3.tower-216.messagelabs.com!1317422796!19168487!1 X-Originating-IP: [81.29.64.94] X-StarScan-Version: 6.4.1; banners=-,-,- X-VirusChecked: Checked Received: (qmail 18407 invoked from network); 30 Sep 2011 22:46:37 -0000 Received: from ocelot.phlegethon.org (HELO mail.phlegethon.org) (81.29.64.94) by server-3.tower-216.messagelabs.com with DHE-RSA-AES256-SHA encrypted SMTP; 30 Sep 2011 22:46:37 -0000 Received: from tjd by mail.phlegethon.org with local (Exim 4.67 (FreeBSD)) (envelope-from <tim@xen.org>) id 1R9lqm-000GUX-4N; Fri, 30 Sep 2011 22:46:36 +0000 Date: Fri, 30 Sep 2011 23:46:36 +0100 From: Tim Deegan <tim@xen.org> To: Adin Scannell <adin@gridcentric.com> Subject: Re: [Xen-devel] [PATCH RFC] memory sharing questions Message-ID: <20110930224636.GC62963@ocelot.phlegethon.org> References: <CAAJKtqq0Qoxh1KazXXdZaVb1qZ6pcP1LNXk1bD1tgsKEV7g_iQ@mail.gmail.com> Mime-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline In-Reply-To: <CAAJKtqq0Qoxh1KazXXdZaVb1qZ6pcP1LNXk1bD1tgsKEV7g_iQ@mail.gmail.com> User-Agent: Mutt/1.4.2.1i Cc: xen-devel@lists.xensource.com X-BeenThere: xen-devel@lists.xensource.com X-Mailman-Version: 2.1.5 Precedence: list List-Id: Xen developer discussion <xen-devel.lists.xensource.com> List-Unsubscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe> List-Post: <mailto:xen-devel@lists.xensource.com> List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help> List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=subscribe> Sender: xen-devel-bounces@lists.xensource.com Errors-To: xen-devel-bounces@lists.xensource.com At 17:46 -0400 on 30 Sep (1317404768), Adin Scannell wrote: > Hi all, > > I have a basic question about memory sharing. > > What is the intended purpose of the hashtable / handle abstraction for > page sharing? > I understand that it's a nice to associate a handle with a > particularly revision of a shared page, but I don't see why it's > necessary given that whoever is calling nominate() must be aware of > the contents of the page (post-nomination) and how many times it has > been nominated. The handle isn't a count of how many times the page has been nominated, it's a global counter, incremented to be sure that the handles are unique. The versioning avoids race conditions where the page gets unshared and re-shared. Since the intended caller was the block backend, short-cutting a read from disk by sharing the last copy read, it's important that the mfn not have been unshared, changed and re-shared in the meantime. In the current system there's only one memory-sharing caller but there could easily be more, and it should be possible to recover from a crashed client too. AIUI the caller shouldn't have to be aware of the _meaning_ of the handle. And there's no reason that the hash table couldn't be improved or replaced, if there's another way around the question of whether the page has changed since you last shared it. Cheers, Tim. _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel From xen-devel-bounces@lists.xensource.com Fri Sep 30 16:03:22 2011 Return-path: <xen-devel-bounces@lists.xensource.com> Envelope-to: www-data@lists.xensource.com Delivery-date: Fri, 30 Sep 2011 16:03:22 -0700 Received: from localhost ([127.0.0.1] helo=lists.colo.xensource.com) by lists.xensource.com with esmtp (Exim 4.43) id 1R9m6z-0007Jw-R2; Fri, 30 Sep 2011 16:03:22 -0700 Received: from mail174.messagelabs.com ([85.158.138.51]) by lists.xensource.com with esmtp (Exim 4.43) id 1R9m3h-00074e-Ql for xen-devel@lists.xensource.com; Fri, 30 Sep 2011 16:00:17 -0700 X-Env-Sender: keith.coleman@n2servers.com X-Msg-Ref: server-5.tower-174.messagelabs.com!1317423593!29735255!1 X-Originating-IP: [209.85.215.171] X-StarScan-Version: 6.4.1; banners=-,-,- X-VirusChecked: Checked Received: (qmail 29003 invoked from network); 30 Sep 2011 22:59:53 -0000 Received: from mail-ey0-f171.google.com (HELO mail-ey0-f171.google.com) (209.85.215.171) by server-5.tower-174.messagelabs.com with RC4-SHA encrypted SMTP; 30 Sep 2011 22:59:53 -0000 Received: by eye3 with SMTP id 3so2552655eye.30 for <xen-devel@lists.xensource.com>; Fri, 30 Sep 2011 15:59:53 -0700 (PDT) MIME-Version: 1.0 Received: by 10.213.22.198 with SMTP id o6mr637050ebb.27.1317423593438; Fri, 30 Sep 2011 15:59:53 -0700 (PDT) Received: by 10.213.36.12 with HTTP; Fri, 30 Sep 2011 15:59:53 -0700 (PDT) X-Originating-IP: [71.56.71.211] Date: Fri, 30 Sep 2011 18:59:53 -0400 Message-ID: <CAH4C7zHnTtb2yXrgPQyNE7qURh64CxpT3WQhexDvqCD09n7VzQ@mail.gmail.com> From: Keith Coleman <keith.coleman@n2servers.com> To: xen-devel <xen-devel@lists.xensource.com> Content-Type: text/plain; charset=ISO-8859-1 Subject: [Xen-devel] Xen 3.4.4 first release candidate X-BeenThere: xen-devel@lists.xensource.com X-Mailman-Version: 2.1.5 Precedence: list List-Id: Xen developer discussion <xen-devel.lists.xensource.com> List-Unsubscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe> List-Post: <mailto:xen-devel@lists.xensource.com> List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help> List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=subscribe> Sender: xen-devel-bounces@lists.xensource.com Errors-To: xen-devel-bounces@lists.xensource.com The first release candidate for Xen 3.4.4 is tagged at: http://xenbits.xensource.com/xen-3.4-testing.hg (tag '3.4.4-rc1') Please test! -- Keith Coleman _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel From xen-devel-bounces@lists.xensource.com Fri Sep 30 16:23:25 2011 Return-path: <xen-devel-bounces@lists.xensource.com> Envelope-to: www-data@lists.xensource.com Delivery-date: Fri, 30 Sep 2011 16:23:25 -0700 Received: from localhost ([127.0.0.1] helo=lists.colo.xensource.com) by lists.xensource.com with esmtp (Exim 4.43) id 1R9mQO-0007xf-VC; Fri, 30 Sep 2011 16:23:24 -0700 Received: from mail27.messagelabs.com ([193.109.254.147]) by lists.xensource.com with esmtp (Exim 4.43) id 1R9mPV-0007lL-PY for xen-devel@lists.xensource.com; Fri, 30 Sep 2011 16:22:33 -0700 X-Env-Sender: Ian.Jackson@eu.citrix.com X-Msg-Ref: server-3.tower-27.messagelabs.com!1317424921!39904675!1 X-Originating-IP: [62.200.22.115] X-StarScan-Version: 6.4.1; banners=-,-,- X-VirusChecked: Checked Received: (qmail 22706 invoked from network); 30 Sep 2011 23:22:01 -0000 Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115) by server-3.tower-27.messagelabs.com with RC4-SHA encrypted SMTP; 30 Sep 2011 23:22:01 -0000 X-IronPort-AV: E=Sophos;i="4.68,470,1312156800"; d="scan'208";a="8161376" Received: from lonpmailmx01.citrite.net ([10.30.203.162]) by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5; 30 Sep 2011 23:22:26 +0000 Received: from norwich.cam.xci-test.com (10.80.248.129) by smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id 8.3.137.0; Sat, 1 Oct 2011 00:22:26 +0100 Received: from [10.80.248.135] (helo=woking.xci-test.com) by norwich.cam.xci-test.com with esmtp (Exim 4.72) (envelope-from <ian.jackson@eu.citrix.com>) id 1R9mPS-0008EW-23; Fri, 30 Sep 2011 23:22:26 +0000 Received: from osstest by woking.xci-test.com with local (Exim 4.69) (envelope-from <ian.jackson@eu.citrix.com>) id 1R9mPS-0002Z9-0f; Sat, 01 Oct 2011 00:22:26 +0100 To: xen-devel@lists.xensource.com Message-ID: <osstest-9169-mainreport@xen.org> From: xen.org <ian.jackson@eu.citrix.com> Date: Sat, 1 Oct 2011 00:22:26 +0100 MIME-Version: 1.0 Content-Type: text/plain Cc: ian.jackson@eu.citrix.com Subject: [Xen-devel] [xen-unstable test] 9169: regressions - FAIL X-BeenThere: xen-devel@lists.xensource.com X-Mailman-Version: 2.1.5 Precedence: list List-Id: Xen developer discussion <xen-devel.lists.xensource.com> List-Unsubscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe> List-Post: <mailto:xen-devel@lists.xensource.com> List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help> List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=subscribe> Sender: xen-devel-bounces@lists.xensource.com Errors-To: xen-devel-bounces@lists.xensource.com flight 9169 xen-unstable real [real] http://www.chiark.greenend.org.uk/~xensrcts/logs/9169/ Regressions :-( Tests which did not succeed and are blocking: test-amd64-amd64-xl-pcipt-intel 8 debian-fixup fail REGR. vs. 9118 test-amd64-i386-xl-multivcpu 9 guest-start fail REGR. vs. 9118 test-amd64-i386-xl 9 guest-start fail REGR. vs. 9118 test-amd64-i386-xl-credit2 9 guest-start fail REGR. vs. 9118 test-amd64-i386-rhel6hvm-intel 7 redhat-install fail REGR. vs. 9118 test-i386-i386-xl 9 guest-start fail REGR. vs. 9118 test-amd64-amd64-xl 9 guest-start fail REGR. vs. 9118 test-amd64-i386-rhel6hvm-amd 7 redhat-install fail REGR. vs. 9118 test-amd64-i386-xl-win-vcpus1 7 windows-install fail REGR. vs. 9118 test-amd64-amd64-xl-win 7 windows-install fail REGR. vs. 9118 test-i386-i386-xl-win 7 windows-install fail REGR. vs. 9118 test-amd64-amd64-xl-sedf 9 guest-start fail in 9163 REGR. vs. 9118 Tests which are failing intermittently (not blocking): test-amd64-amd64-xl-sedf 7 debian-install fail pass in 9163 test-i386-i386-win 14 guest-start.2 fail pass in 9163 Tests which did not succeed, but are not blocking, including regressions (tests previously passed) regarded as allowable: test-amd64-i386-win-vcpus1 16 leak-check/check fail never pass test-amd64-i386-win 16 leak-check/check fail never pass test-amd64-amd64-win 16 leak-check/check fail never pass test-i386-i386-win 16 leak-check/check fail in 9163 never pass version targeted for testing: xen e78cd03b0308 baseline version: xen 7998217630e2 ------------------------------------------------------------ People who touched revisions under test: Adin Scannell <adin@scannell.ca> Anthony PERARD <anthony.perard@citrix.com> Ian Campbell <ian.campbell@citrix.com> Ian Jackson <ian.jackson.citrix.com> Ian Jackson <ian.jackson@eu.citrix.com> Olaf Hering <olaf@aepfle.de> ------------------------------------------------------------ jobs: build-amd64 pass build-i386 pass build-amd64-oldkern pass build-i386-oldkern pass build-amd64-pvops pass build-i386-pvops pass test-amd64-amd64-xl fail test-amd64-i386-xl fail test-i386-i386-xl fail test-amd64-i386-rhel6hvm-amd fail test-amd64-i386-xl-credit2 fail test-amd64-amd64-xl-pcipt-intel fail test-amd64-i386-rhel6hvm-intel fail test-amd64-i386-xl-multivcpu fail test-amd64-amd64-pair pass test-amd64-i386-pair pass test-i386-i386-pair pass test-amd64-amd64-pv pass test-amd64-i386-pv pass test-i386-i386-pv pass test-amd64-amd64-xl-sedf fail test-amd64-i386-win-vcpus1 fail test-amd64-i386-xl-win-vcpus1 fail test-amd64-amd64-win fail test-amd64-i386-win fail test-i386-i386-win fail test-amd64-amd64-xl-win fail test-i386-i386-xl-win fail ------------------------------------------------------------ sg-report-flight on woking.cam.xci-test.com logs: /home/xc_osstest/logs images: /home/xc_osstest/images Logs, config files, etc. are available at http://www.chiark.greenend.org.uk/~xensrcts/logs Test harness code can be found at http://xenbits.xensource.com/gitweb?p=osstest.git;a=summary Not pushing. ------------------------------------------------------------ changeset: 23894:e78cd03b0308 tag: tip user: Anthony PERARD <anthony.perard@citrix.com> date: Thu Sep 29 16:31:24 2011 +0100 libxl: libxl_qmp: use of libxl__fd_set_cloexec. Signed-off-by: Anthony PERARD <anthony.perard@citrix.com> Acked-by: Ian Jackson <ian.jackson@eu.citrix.com> Committed-by: Ian Jackson <ian.jackson@eu.citrix.com> changeset: 23893:95a40ee93806 user: Anthony PERARD <anthony.perard@citrix.com> date: Thu Sep 29 16:30:54 2011 +0100 libxl: Introduce a QMP client QMP stands for QEMU Monitor Protocol and it is used to query information from QEMU or to control QEMU. This implementation will ask QEMU the list of chardevice and store the path to serial ports in xenstored. So we will be able to use xl console with QEMU upstream. In order to connect to the QMP server, a socket file is created in /var/run/xen/qmp-libxl-$(domid). Signed-off-by: Anthony PERARD <anthony.perard@citrix.com> Committed-by: Ian Jackson <ian.jackson@eu.citrix.com> changeset: 23892:5f397994e6d6 user: Anthony PERARD <anthony.perard@citrix.com> date: Thu Sep 29 16:28:24 2011 +0100 libxl: Introduce JSON parser We use the yajl parser, but we need to make a tree from the parse result to use it outside the parser. So this patch include json_object struct that is used to hold the JSON data. Signed-off-by: Anthony PERARD <anthony.perard@citrix.com> Committed-by: Ian Jackson <ian.jackson.citrix.com> Acked-by: Ian Campbell <ian.campbell@citrix.com> changeset: 23891:066dc3758fa4 user: Anthony PERARD <anthony.perard@citrix.com> date: Thu Sep 29 16:28:23 2011 +0100 libxl: Intruduce libxl__strndup. Signed-off-by: Anthony PERARD <anthony.perard@citrix.com> Committed-by: Ian Jackson <ian.jackson.citrix.com> Acked-by: Ian Campbell <ian.campbell@citrix.com> changeset: 23890:952e0118a7c4 user: Anthony PERARD <anthony.perard@citrix.com> date: Thu Sep 29 16:28:22 2011 +0100 libxl: Introduce libxl__realloc. Signed-off-by: Anthony PERARD <anthony.perard@citrix.com> Committed-by: Ian Jackson <ian.jackson.citrix.com> Acked-by: Ian Campbell <ian.campbell@citrix.com> changeset: 23889:f51dcd8acb7b user: Anthony PERARD <anthony.perard@citrix.com> date: Thu Sep 29 16:28:22 2011 +0100 libxl: Introduce libxl_internal_types.idl. Signed-off-by: Anthony PERARD <anthony.perard@citrix.com> Committed-by: Ian Jackson <ian.jackson.citrix.com> Acked-by: Ian Campbell <ian.campbell@citrix.com> changeset: 23888:f5ee5ad45425 user: Anthony PERARD <anthony.perard@citrix.com> date: Thu Sep 29 16:28:21 2011 +0100 libxl: Add get/set_default_namespace in libxltypes.py. Signed-off-by: Anthony PERARD <anthony.perard@citrix.com> Committed-by: Ian Jackson <ian.jackson.citrix.com> Acked-by: Ian Campbell <ian.campbell@citrix.com> changeset: 23887:a543e10211f7 user: Anthony PERARD <anthony.perard@citrix.com> date: Thu Sep 29 16:28:20 2011 +0100 libxl: Rename libxl.idl to libxl_types.idl. Signed-off-by: Anthony PERARD <anthony.perard@citrix.com> Committed-by: Ian Jackson <ian.jackson.citrix.com> Acked-by: Ian Campbell <ian.campbell@citrix.com> changeset: 23886:cf2ba5720151 user: Anthony PERARD <anthony.perard@citrix.com> date: Thu Sep 29 16:06:02 2011 +0100 libxl: Introduce libxl__fd_set_cloexec Signed-off-by: Anthony PERARD <anthony.perard@citrix.com> Acked-by: Ian Jackson <ian.jackson@eu.citrix.com> Committed-by: Ian Jackson <ian.jackson@eu.citrix.com> changeset: 23885:cd60c87d3496 user: Ian Campbell <ian.campbell@citrix.com> date: Thu Sep 29 15:40:34 2011 +0100 xl: fixup command line handling for several commands. def_getopt already checks for a minimum number of arguments for us. "xl save" simply need to use the correct argument for that value, contrary to the change I made in 23876:b113d626cfaf "xl block-list" does not need to check for at least 2 arguments, since it's already been done by def_getopt. "xl network-list" would previous accept zero arguments and just print the table header. Insist on a domain argument. Signed-off-by: Ian Campbell <ian.campbell@citrix.com> Acked-by: Ian Jackson <ian.jackson@eu.citrix.com> Committed-by: Ian Jackson <ian.jackson@eu.citrix.com> changeset: 23884:145e146876b3 user: Adin Scannell <adin@gridcentric.com> date: Thu Sep 29 15:26:04 2011 +0100 libxl: Expose number of shared pages Signed-off-by: Adin Scannell <adin@scannell.ca> Acked-by: Ian Jackson <ian.jackson@eu.citrix.com> Committed-by: Ian Jackson <ian.jackson@eu.citrix.com> changeset: 23883:7998217630e2 user: Ian Campbell <ian.campbell@citrix.com> date: Wed Sep 28 16:42:11 2011 +0100 libxl: attempt to cleanup tapdisk processes on disk backend destroy. Signed-off-by: Ian Campbell <ian.campbell@citrix.com> Committed-by: Ian Jackson <ian.jackson@eu.citrix.com> ======================================== commit cd776ee9408ff127f934a707c1a339ee600bc127 Author: Ian Jackson <ian.jackson@eu.citrix.com> Date: Tue Jun 28 13:50:53 2011 +0100 qemu-char.c: fix incorrect CONFIG_STUBDOM handling qemu-char.c:1123:7: warning: "CONFIG_STUBDOM" is not defined [-Wundef] Signed-off-by: Olaf Hering <olaf@aepfle.de> Acked-by: Ian Jackson <ian.jackson@eu.citrix.com> _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel From xen-devel-bounces@lists.xensource.com Fri Sep 30 16:53:42 2011 Return-path: <xen-devel-bounces@lists.xensource.com> Envelope-to: www-data@lists.xensource.com Delivery-date: Fri, 30 Sep 2011 16:53:42 -0700 Received: from localhost ([127.0.0.1] helo=lists.colo.xensource.com) by lists.xensource.com with esmtp (Exim 4.43) id 1R9mti-0000Sq-Jz; Fri, 30 Sep 2011 16:53:42 -0700 Received: from mail21.messagelabs.com ([85.158.143.35]) by lists.xensource.com with esmtp (Exim 4.43) id 1R9msv-0000G2-3R; Fri, 30 Sep 2011 16:52:53 -0700 X-Env-Sender: pasik@iki.fi X-Msg-Ref: server-14.tower-21.messagelabs.com!1317426760!61668765!1 X-Originating-IP: [192.89.123.25] X-StarScan-Version: 6.4.1; banners=-,-,- X-VirusChecked: Checked Received: (qmail 19000 invoked from network); 30 Sep 2011 23:52:41 -0000 Received: from smtp.tele.fi (HELO smtp.tele.fi) (192.89.123.25) by server-14.tower-21.messagelabs.com with DHE-RSA-AES256-SHA encrypted SMTP; 30 Sep 2011 23:52:41 -0000 X-Originating-Ip: [194.89.68.22] Received: from ydin.reaktio.net (reaktio.net [194.89.68.22]) by smtp.tele.fi (Postfix) with ESMTP id 3C3BA15AC; Sat, 1 Oct 2011 02:52:48 +0300 (EEST) Received: by ydin.reaktio.net (Postfix, from userid 1001) id 1DC5B200EA; Sat, 1 Oct 2011 02:52:48 +0300 (EEST) Date: Sat, 1 Oct 2011 02:52:48 +0300 From: Pasi =?iso-8859-1?Q?K=E4rkk=E4inen?= <pasik@iki.fi> To: Florian Heigl <florian.heigl@gmail.com> Subject: Re: [Xen-users] Re: [Xen-devel] Xen document day (Oct 12 or 26) Message-ID: <20110930235247.GY12984@reaktio.net> References: <20110922130618.GA13238@phenom.oracle.com> <20110929141317.GX12984@reaktio.net> <CAOzFzEieWhgoBWEXQFjqr8PYoVOAcU20rtA2Q3OhyA+=dD9Atg@mail.gmail.com> <4E85A9B7.7040605@xen.org> <CAFivhPnc-Mpv+Yapp3fVkV2awDcfGw0nv_gWERftnLJXA0_M5A@mail.gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <CAFivhPnc-Mpv+Yapp3fVkV2awDcfGw0nv_gWERftnLJXA0_M5A@mail.gmail.com> User-Agent: Mutt/1.5.18 (2008-05-17) Cc: Joseph Glanville <joseph.glanville@orionvm.com.au>, Lars Kurth <lars.kurth@xen.org>, xen-devel@lists.xensource.com, Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>, xen-users@lists.xensource.com X-BeenThere: xen-devel@lists.xensource.com X-Mailman-Version: 2.1.5 Precedence: list List-Id: Xen developer discussion <xen-devel.lists.xensource.com> List-Unsubscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe> List-Post: <mailto:xen-devel@lists.xensource.com> List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help> List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=subscribe> Sender: xen-devel-bounces@lists.xensource.com Errors-To: xen-devel-bounces@lists.xensource.com On Fri, Sep 30, 2011 at 06:33:40PM +0200, Florian Heigl wrote: > 2011/9/30 Lars Kurth <lars.kurth@xen.org>: > > Let me know, which date you agreed on. We could do a poll. > > We should publish on the blog a bit before. > > Also, how can I help? > > One thing where you could probably help best is setting clear rules > what do document for a release. > i.e. the 4.0 relnotes had build instructions and a lot more, whereas > this is missing in the next release note. > > either the build instructions were in the wrong place for 4.0 or 4.1 > was released with incomplete info ;) > making a checklist sounds *ahem* in place :) > Xen 4.1 releasenotes do state that "check Xen 4.0 releasenotes for build instructions and more info" :) -- Pasi _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel From xen-devel-bounces@lists.xensource.com Fri Sep 30 19:32:17 2011 Return-path: <xen-devel-bounces@lists.xensource.com> Envelope-to: www-data@lists.xensource.com Delivery-date: Fri, 30 Sep 2011 19:32:17 -0700 Received: from localhost ([127.0.0.1] helo=lists.colo.xensource.com) by lists.xensource.com with esmtp (Exim 4.43) id 1R9pNA-000553-4f; Fri, 30 Sep 2011 19:32:16 -0700 Received: from mail216.messagelabs.com ([85.158.143.99]) by lists.xensource.com with esmtp (Exim 4.43) id 1R9pMR-0004rt-7g for xen-devel@lists.xensource.com; Fri, 30 Sep 2011 19:31:31 -0700 X-Env-Sender: Ian.Jackson@eu.citrix.com X-Msg-Ref: server-10.tower-216.messagelabs.com!1317436288!10440163!1 X-Originating-IP: [62.200.22.115] X-StarScan-Version: 6.4.1; banners=-,-,- X-VirusChecked: Checked Received: (qmail 23483 invoked from network); 1 Oct 2011 02:31:28 -0000 Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115) by server-10.tower-216.messagelabs.com with RC4-SHA encrypted SMTP; 1 Oct 2011 02:31:28 -0000 X-IronPort-AV: E=Sophos;i="4.68,470,1312156800"; d="scan'208";a="8161665" Received: from lonpmailmx01.citrite.net ([10.30.203.162]) by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5; 01 Oct 2011 02:31:04 +0000 Received: from norwich.cam.xci-test.com (10.80.248.129) by smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id 8.3.137.0; Sat, 1 Oct 2011 03:31:04 +0100 Received: from [10.80.248.135] (helo=woking.xci-test.com) by norwich.cam.xci-test.com with esmtp (Exim 4.72) (envelope-from <ian.jackson@eu.citrix.com>) id 1R9pM0-0000Y6-AJ; Sat, 01 Oct 2011 02:31:04 +0000 Received: from osstest by woking.xci-test.com with local (Exim 4.69) (envelope-from <ian.jackson@eu.citrix.com>) id 1R9pM0-00067P-9r; Sat, 01 Oct 2011 03:31:04 +0100 To: xen-devel@lists.xensource.com Message-ID: <osstest-9176-mainreport@xen.org> From: xen.org <ian.jackson@eu.citrix.com> Date: Sat, 1 Oct 2011 03:31:04 +0100 MIME-Version: 1.0 Content-Type: text/plain Cc: ian.jackson@eu.citrix.com Subject: [Xen-devel] [xen-unstable test] 9176: tolerable FAIL - PUSHED X-BeenThere: xen-devel@lists.xensource.com X-Mailman-Version: 2.1.5 Precedence: list List-Id: Xen developer discussion <xen-devel.lists.xensource.com> List-Unsubscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe> List-Post: <mailto:xen-devel@lists.xensource.com> List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help> List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=subscribe> Sender: xen-devel-bounces@lists.xensource.com Errors-To: xen-devel-bounces@lists.xensource.com flight 9176 xen-unstable real [real] http://www.chiark.greenend.org.uk/~xensrcts/logs/9176/ Failures :-/ but no regressions. Tests which did not succeed, but are not blocking, including regressions (tests previously passed) regarded as allowable: test-amd64-amd64-xl-pcipt-intel 9 guest-start fail never pass test-amd64-i386-rhel6hvm-intel 9 guest-start.2 fail never pass test-amd64-i386-rhel6hvm-amd 9 guest-start.2 fail never pass test-amd64-i386-win-vcpus1 16 leak-check/check fail never pass test-amd64-i386-xl-win-vcpus1 13 guest-stop fail never pass test-amd64-i386-win 16 leak-check/check fail never pass test-amd64-amd64-win 16 leak-check/check fail never pass test-amd64-amd64-xl-win 13 guest-stop fail never pass test-i386-i386-win 16 leak-check/check fail never pass test-i386-i386-xl-win 13 guest-stop fail never pass version targeted for testing: xen 3d1664cc9e45 baseline version: xen 7998217630e2 ------------------------------------------------------------ People who touched revisions under test: Adin Scannell <adin@scannell.ca> Andrew Cooper <andrew.cooper3@citrix.com> Anthony PERARD <anthony.perard@citrix.com> George Dunlap <george.dunlap@eu.citrix.com> Ian Campbell <ian.campbell@citrix.com> Ian Jackson <ian.jackson.citrix.com> Ian Jackson <ian.jackson@eu.citrix.com> Keir Fraser <keir@xen.org> Liu, Jinsong <jinsong.liu@intel.com> Olaf Hering <olaf@aepfle.de> ------------------------------------------------------------ jobs: build-amd64 pass build-i386 pass build-amd64-oldkern pass build-i386-oldkern pass build-amd64-pvops pass build-i386-pvops pass test-amd64-amd64-xl pass test-amd64-i386-xl pass test-i386-i386-xl pass test-amd64-i386-rhel6hvm-amd fail test-amd64-i386-xl-credit2 pass test-amd64-amd64-xl-pcipt-intel fail test-amd64-i386-rhel6hvm-intel fail test-amd64-i386-xl-multivcpu pass test-amd64-amd64-pair pass test-amd64-i386-pair pass test-i386-i386-pair pass test-amd64-amd64-pv pass test-amd64-i386-pv pass test-i386-i386-pv pass test-amd64-amd64-xl-sedf pass test-amd64-i386-win-vcpus1 fail test-amd64-i386-xl-win-vcpus1 fail test-amd64-amd64-win fail test-amd64-i386-win fail test-i386-i386-win fail test-amd64-amd64-xl-win fail test-i386-i386-xl-win fail ------------------------------------------------------------ sg-report-flight on woking.cam.xci-test.com logs: /home/xc_osstest/logs images: /home/xc_osstest/images Logs, config files, etc. are available at http://www.chiark.greenend.org.uk/~xensrcts/logs Test harness code can be found at http://xenbits.xensource.com/gitweb?p=osstest.git;a=summary Pushing revision : + branch=xen-unstable + revision=3d1664cc9e45 + . cri-lock-repos ++ . cri-common +++ umask 002 +++ getconfig Repos +++ perl -e ' use Osstest; readconfigonly(); print $c{Repos} or die $!; ' ++ repos=/export/home/osstest/repos ++ repos_lock=/export/home/osstest/repos/lock ++ '[' x '!=' x/export/home/osstest/repos/lock ']' ++ OSSTEST_REPOS_LOCK_LOCKED=/export/home/osstest/repos/lock ++ exec with-lock-ex -w /export/home/osstest/repos/lock ./ap-push xen-unstable 3d1664cc9e45 + branch=xen-unstable + revision=3d1664cc9e45 + . cri-lock-repos ++ . cri-common +++ umask 002 +++ getconfig Repos +++ perl -e ' use Osstest; readconfigonly(); print $c{Repos} or die $!; ' ++ repos=/export/home/osstest/repos ++ repos_lock=/export/home/osstest/repos/lock ++ '[' x/export/home/osstest/repos/lock '!=' x/export/home/osstest/repos/lock ']' + : xen@xenbits.xensource.com + : xen@xenbits.xensource.com:git/linux-pvops + : master + : tested/2.6.39.x + case "$branch" in + cd /export/home/osstest/repos/xen-unstable.hg + hg push -r 3d1664cc9e45 ssh://xen@xenbits.xensource.com/HG/xen-unstable.hg pushing to ssh://xen@xenbits.xensource.com/HG/xen-unstable.hg searching for changes remote: adding changesets remote: adding manifests remote: adding file changes remote: added 15 changesets with 39 changes to 26 files _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel From xen-devel-bounces@lists.xensource.com Fri Sep 30 19:51:34 2011 Return-path: <xen-devel-bounces@lists.xensource.com> Envelope-to: www-data@lists.xensource.com Delivery-date: Fri, 30 Sep 2011 19:51:34 -0700 Received: from localhost ([127.0.0.1] helo=lists.colo.xensource.com) by lists.xensource.com with esmtp (Exim 4.43) id 1R9pfq-0007UQ-BF; Fri, 30 Sep 2011 19:51:34 -0700 Received: from mail27.messagelabs.com ([193.109.254.147]) by lists.xensource.com with esmtp (Exim 4.43) id 1R9pfJ-0007I1-Lw for xen-devel@lists.xensource.com; Fri, 30 Sep 2011 19:51:01 -0700 X-Env-Sender: jrnieder@gmail.com X-Msg-Ref: server-7.tower-27.messagelabs.com!1317437432!50869888!1 X-Originating-IP: [209.85.210.171] X-StarScan-Version: 6.4.1; banners=-,-,- X-VirusChecked: Checked Received: (qmail 22979 invoked from network); 1 Oct 2011 02:50:33 -0000 Received: from mail-iy0-f171.google.com (HELO mail-iy0-f171.google.com) (209.85.210.171) by server-7.tower-27.messagelabs.com with RC4-SHA encrypted SMTP; 1 Oct 2011 02:50:33 -0000 Received: by iagv1 with SMTP id v1so3280599iag.30 for <xen-devel@lists.xensource.com>; Fri, 30 Sep 2011 19:50:57 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=date:from:to:cc:subject:message-id:references:mime-version :content-type:content-disposition:in-reply-to:user-agent; bh=V058Hb/v0daGi6TxMkp9MRk4TgIOc18t2+JWMFST2J0=; b=J/f2Em9ahtTOeIlbS+hBNivH/1HKNIgv6EIw8iLGHk9BXEg/oUiqqomr0UO6hFrt4n dQbbPNBwpZSP7rgiCqvBhTnK9tS1FL6OO2gFHymC1Gd7UitvoG67fpqmIZhZ/pl8eQUn Vd14YscoOAJG6Q2lW7Ui5D36GDSn1O75qTzn8= Received: by 10.42.154.135 with SMTP id q7mr3819431icw.87.1317437457027; Fri, 30 Sep 2011 19:50:57 -0700 (PDT) Received: from elie.sbx02827.chicail.wayport.net (ip-64-134-196-224.public.wayport.net. [64.134.196.224]) by mx.google.com with ESMTPS id by18sm11289791ibb.1.2011.09.30.19.50.54 (version=SSLv3 cipher=OTHER); Fri, 30 Sep 2011 19:50:55 -0700 (PDT) Date: Fri, 30 Sep 2011 21:50:48 -0500 From: Jonathan Nieder <jrnieder@gmail.com> To: rush <rush1503@gmail.com> Message-ID: <20111001025030.GA5198@elie.sbx02827.chicail.wayport.net> References: <20110919210045.3256.61939.reportbug@xen-dom0.xen.irush.su> <20110919212211.GB6343@elie> <CA+rvmvK8G5hNq4wOkPdcDMufYS9bD559zvexMqG9gy=m7dkU_A@mail.gmail.com> <1316524835.4122.8.camel@deadeye> <1316526058.3891.65.camel@zakaz.uk.xensource.com> <20110922190018.GA16678@phenom.oracle.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20110922190018.GA16678@phenom.oracle.com> User-Agent: Mutt/1.5.21+46 (b01d63af6fea) (2011-07-01) Cc: 642154@bugs.debian.org, Ian Campbell <ijc@hellion.org.uk>, Ben Hutchings <ben@decadent.org.uk>, xen-devel <xen-devel@lists.xensource.com>, Konrad Rzeszutek Wilk <konrad.wilk@oracle.com> Subject: [Xen-devel] Re: BUG: unable to handle kernel paging request at ffff8803bb6ad000 X-BeenThere: xen-devel@lists.xensource.com X-Mailman-Version: 2.1.5 Precedence: list List-Id: Xen developer discussion <xen-devel.lists.xensource.com> List-Unsubscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe> List-Post: <mailto:xen-devel@lists.xensource.com> List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help> List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=subscribe> Sender: xen-devel-bounces@lists.xensource.com Errors-To: xen-devel-bounces@lists.xensource.com Konrad Rzeszutek Wilk wrote: >> There's been some similar looking threads on xen-devel recently but I >> haven't paid attention to the details, list & Konrad CC'd. Full log is >> at http://bugs.debian.org/642154. > > Does xsave=0 make a difference? Cc-ing the reporter. Rush, are you able to reproduce the oops you mentioned? Does adding noxsave to the kernel command line help? Thanks, Jonathan _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel From xen-devel-bounces@lists.xensource.com Fri Sep 30 20:54:19 2011 Return-path: <xen-devel-bounces@lists.xensource.com> Envelope-to: www-data@lists.xensource.com Delivery-date: Fri, 30 Sep 2011 20:54:19 -0700 Received: from localhost ([127.0.0.1] helo=lists.colo.xensource.com) by lists.xensource.com with esmtp (Exim 4.43) id 1R9qeZ-0001FT-7Z; Fri, 30 Sep 2011 20:54:19 -0700 Received: from mail27.messagelabs.com ([193.109.254.147]) by lists.xensource.com with esmtp (Exim 4.43) id 1R9qdc-000132-Du for xen-devel@lists.xensource.com; Fri, 30 Sep 2011 20:53:23 -0700 X-Env-Sender: bickys1986@gmail.com X-Msg-Ref: server-12.tower-27.messagelabs.com!1317441180!44672641!1 X-Originating-IP: [74.125.82.43] X-StarScan-Version: 6.4.1; banners=-,-,- X-VirusChecked: Checked Received: (qmail 14783 invoked from network); 1 Oct 2011 03:53:00 -0000 Received: from mail-ww0-f43.google.com (HELO mail-ww0-f43.google.com) (74.125.82.43) by server-12.tower-27.messagelabs.com with RC4-SHA encrypted SMTP; 1 Oct 2011 03:53:00 -0000 Received: by wwf27 with SMTP id 27so2846023wwf.24 for <xen-devel@lists.xensource.com>; Fri, 30 Sep 2011 20:53:17 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=E33Ex2tofp6D1f3cT5aG/T9KB/lwyhG8jdxgH3a8Y0A=; b=ke/oEVSqvfbKF+p2Clac+XzrHhLpeoyfR8VSXFJcvCQtGaHnlx/VaedMFnZ8HA9hRh mKn5SDXp4sfUt9aBM3vy/2KQwCRWVKHtppg1/J3fQeo+/zm1n1YfurxzoeMmgnZWL5UD sZ9gNLE4hNTP/5U2CCv7LR4eTfpLVHoVCFg/g= MIME-Version: 1.0 Received: by 10.216.47.11 with SMTP id s11mr9215107web.24.1317441141167; Fri, 30 Sep 2011 20:52:21 -0700 (PDT) Received: by 10.216.184.134 with HTTP; Fri, 30 Sep 2011 20:52:21 -0700 (PDT) In-Reply-To: <20110929170244.GA29163@aepfle.de> References: <CACavRyB4kvMLZK1-vv9bJnVdnpKJBHTmnhJxt6g3eh88xY6FTg@mail.gmail.com> <20110929170244.GA29163@aepfle.de> Date: Sat, 1 Oct 2011 11:52:21 +0800 Message-ID: <CACavRyDi7Qjj1PeKWpg1Yf2adpDn0qSzA1azKXLuUswvd2jQEQ@mail.gmail.com> From: zhen shi <bickys1986@gmail.com> To: Olaf Hering <olaf@aepfle.de> Cc: xen-devel@lists.xensource.com Subject: [Xen-devel] Re: mapping problems in xenpaging X-BeenThere: xen-devel@lists.xensource.com X-Mailman-Version: 2.1.5 Precedence: list List-Id: Xen developer discussion <xen-devel.lists.xensource.com> List-Unsubscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe> List-Post: <mailto:xen-devel@lists.xensource.com> List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help> List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=subscribe> Content-Type: multipart/mixed; boundary="===============1867376661==" Sender: xen-devel-bounces@lists.xensource.com Errors-To: xen-devel-bounces@lists.xensource.com --===============1867376661== Content-Type: multipart/alternative; boundary=001485f1bdc43b56a204ae34abcd --001485f1bdc43b56a204ae34abcd Content-Type: text/plain; charset=ISO-8859-1 Olaf,maybe I didn't described the problems clearly.I will give an example. a) In xen_vga_vram_map() of vga.c from tools/ioemu-qemu-xen/hw, it uses xc_map_foreign_pages() to map a page's gfn address to dom0. If then the page is paged out and changed to zero page in xenpaging, and dom0 access the page such as using the mapped address, it will make mistakes.Am I right? In brief,I mean there may be some conflicts in xc_map_foreign_pages from other functions and xenpaging feature when they access the same page. b) In create_grant_pte_mapping() of mm.c from /xen/arch/x86, it uses gmfn_to_mfn() to get mfn, and then executes map_domain_page(mfn). At the same time, the page is paged_out and the mfn is changed to INVALID_MFN. So that in create_grant_pte_mapping () when it goes to mfn_to_page(mfn), it will make a mistake.Because xen didn't judge the mfn and thought the mfn was original. I mean there may be some conflicts of operations after getting the mfn in xen but the page is paged_out in the meantime. 2011/9/30 Olaf Hering <olaf@aepfle.de> > On Thu, Sep 29, zhen shi wrote: > > > Hi,Olaf, > > > > When we analyze and test xenpaging,we found there are some > problems between > > mapping and xenpaging. > > 1) When mapping firstly, then do xenpaging,and the code paths have > resolved > > the problems.It's OK. > > 2) The problems exists if we do address mapping firstly then go to > > xenpaging,and our confusions are as followings: > > a) If the domU's memory is directly mapped to dom0,such as the > hypercall > > from pv driver,then it will build a related page-table in dom0,which will > not > > change p2m-type. > > and then do the xenpaging to page out the domU's memory pages whose > gfn > > address have been already mapped to dom0;So it will cause some problems > when > > dom0 > > accesses these pages.Because these pages are paged-out,and dom0 > cannot > > tell the p2mt before access the pages. > > I'm not entirely sure what you do. xenpaging runs in dom0 and is able to > map paged-out pages. It uses that to trigger a page-in, see > tools/xenpaging/pagein.c in xen-unstable.hg > > > b)The another situation is that if xen has mapped the domU's page, and > get > > the mfn according to pfn_to_mfn.But then the page's p2mt is changed by > others, > > so when xen > > accesses the page ,it will cause problems such as BSOD or > reboot.Because > > the operations of getting mfn and accessing the page are not > > atomic.and the situation exists > > in many code paths . > > Can you be more specific what you mean? Xen doesnt seem to have a > pfn_to_mfn function, only the tools have some helper macros of that name. > > > Olaf > --001485f1bdc43b56a204ae34abcd Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable <div>Olaf,maybe I didn't described the problems clearly.I will give an = example.</div>a) In xen_vga_vram_map() of vga.c from tools/ioemu-qemu-xen/h= w, =A0it uses xc_map_foreign_pages() to map a page's gfn address to dom= 0. If then the page is paged out and changed to zero page in xenpaging, and= dom0 access the page such as using the mapped address, it will make mistak= es.Am I right?<div> In brief,I mean there may be some conflicts in=A0xc_map_foreign_pages from = other functions and xenpaging feature when they access the same page.</div>= <div><br></div><div>b) In create_grant_pte_mapping() of mm.c from /xen/arch= /x86, it uses=A0gmfn_to_mfn() to get mfn, and then executes map_domain_page= (mfn). At the same time, the page is paged_out and the mfn is changed to IN= VALID_MFN. So that in create_grant_pte_mapping () when it goes to=A0mfn_to_= page(mfn), it will make a mistake.Because xen didn't judge the mfn and = thought the mfn was original.</div> <div>I mean there may be some conflicts of operations after getting the mfn= in xen but the page is paged_out in the meantime.</div><div><div><div><br>= </div><div><br><div class=3D"gmail_quote">2011/9/30 Olaf Hering <span dir= =3D"ltr"><<a href=3D"mailto:olaf@aepfle.de">olaf@aepfle.de</a>></span= ><br> <blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1p= x #ccc solid;padding-left:1ex;"><div class=3D"im">On Thu, Sep 29, zhen shi = wrote:<br> <br> > =A0Hi,Olaf,<br> > =A0<br> > =A0When we analyze and test xenpaging,we found there are some problems= =A0between<br> > mapping and xenpaging.<br> > =A01) When mapping firstly, then do xenpaging,and the code paths have = resolved<br> > the problems.It's OK.<br> > =A02) The problems exists if we do address mapping firstly then go to<= br> > xenpaging,and our confusions are as followings:<br> > =A0=A0 a) If the domU's memory is directly mapped to dom0,such as = the hypercall<br> > from pv driver,then it will build a related page-table in dom0,which w= ill not<br> > change p2m-type.<br> > =A0=A0=A0=A0 =A0and then do the xenpaging to page out the domU's m= emory pages whose gfn<br> > address have been already mapped to dom0;So it will cause some problem= s when<br> > dom0<br> > =A0=A0=A0=A0 =A0accesses these pages.Because these pages are paged-out= ,and dom0 cannot<br> > tell the p2mt before access the pages.<br> <br> </div>I'm not entirely sure what you do. xenpaging runs in dom0 and is = able to<br> map paged-out pages. It uses that to trigger a page-in, see<br> tools/xenpaging/pagein.c in xen-unstable.hg<br> <div class=3D"im"><br> > =A0 b)The another situation is that if xen has mapped the domU's p= age, and get<br> > the mfn according to pfn_to_mfn.But then the page's p2mt is change= d by others,<br> > so when xen<br> > =A0=A0=A0 accesses the page ,it will cause problems such as BSOD or re= boot.Because<br> > the operations of getting mfn and accessing the page are not<br> > atomic.and=A0the=A0situation exists<br> > =A0=A0=A0 in=A0many code paths .<br> <br> </div>Can you be more specific what you mean? Xen doesnt seem to have a<br> pfn_to_mfn function, only the tools have some helper macros of that name.<b= r> <font color=3D"#888888"><br> <br> Olaf<br> </font></blockquote></div><br></div></div></div> --001485f1bdc43b56a204ae34abcd-- --===============1867376661== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel --===============1867376661==-- From xen-devel-bounces@lists.xensource.com Fri Sep 30 22:56:06 2011 Return-path: <xen-devel-bounces@lists.xensource.com> Envelope-to: www-data@lists.xensource.com Delivery-date: Fri, 30 Sep 2011 22:56:06 -0700 Received: from localhost ([127.0.0.1] helo=lists.colo.xensource.com) by lists.xensource.com with esmtp (Exim 4.43) id 1R9sYP-0003wF-TF; Fri, 30 Sep 2011 22:56:06 -0700 Received: from mail216.messagelabs.com ([85.158.143.99]) by lists.xensource.com with esmtp (Exim 4.43) id 1R9sXM-0003j6-Tk for xen-devel@lists.xensource.com; Fri, 30 Sep 2011 22:55:02 -0700 X-Env-Sender: Ian.Jackson@eu.citrix.com X-Msg-Ref: server-2.tower-216.messagelabs.com!1317448497!19766444!1 X-Originating-IP: [62.200.22.115] X-StarScan-Version: 6.4.1; banners=-,-,- X-VirusChecked: Checked Received: (qmail 4383 invoked from network); 1 Oct 2011 05:54:57 -0000 Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115) by server-2.tower-216.messagelabs.com with RC4-SHA encrypted SMTP; 1 Oct 2011 05:54:57 -0000 X-IronPort-AV: E=Sophos;i="4.68,471,1312156800"; d="scan'208";a="8162059" Received: from lonpmailmx01.citrite.net ([10.30.203.162]) by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5; 01 Oct 2011 05:54:57 +0000 Received: from norwich.cam.xci-test.com (10.80.248.129) by smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id 8.3.137.0; Sat, 1 Oct 2011 06:54:56 +0100 Received: from [10.80.248.135] (helo=woking.xci-test.com) by norwich.cam.xci-test.com with esmtp (Exim 4.72) (envelope-from <ian.jackson@eu.citrix.com>) id 1R9sXI-0001Lj-P4; Sat, 01 Oct 2011 05:54:56 +0000 Received: from osstest by woking.xci-test.com with local (Exim 4.69) (envelope-from <ian.jackson@eu.citrix.com>) id 1R9sXI-0005SM-Ja; Sat, 01 Oct 2011 06:54:56 +0100 To: xen-devel@lists.xensource.com Message-ID: <osstest-9181-mainreport@xen.org> From: xen.org <ian.jackson@eu.citrix.com> Date: Sat, 1 Oct 2011 06:54:56 +0100 MIME-Version: 1.0 Content-Type: text/plain Cc: ian.jackson@eu.citrix.com Subject: [Xen-devel] [xen-unstable test] 9181: tolerable FAIL X-BeenThere: xen-devel@lists.xensource.com X-Mailman-Version: 2.1.5 Precedence: list List-Id: Xen developer discussion <xen-devel.lists.xensource.com> List-Unsubscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe> List-Post: <mailto:xen-devel@lists.xensource.com> List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help> List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=subscribe> Sender: xen-devel-bounces@lists.xensource.com Errors-To: xen-devel-bounces@lists.xensource.com flight 9181 xen-unstable real [real] http://www.chiark.greenend.org.uk/~xensrcts/logs/9181/ Failures :-/ but no regressions. Tests which are failing intermittently (not blocking): test-amd64-amd64-xl-sedf 9 guest-start fail pass in 9176 test-i386-i386-win 14 guest-start.2 fail pass in 9176 Tests which did not succeed, but are not blocking, including regressions (tests previously passed) regarded as allowable: test-amd64-amd64-xl-pcipt-intel 9 guest-start fail never pass test-amd64-i386-rhel6hvm-intel 9 guest-start.2 fail never pass test-amd64-i386-rhel6hvm-amd 9 guest-start.2 fail never pass test-amd64-i386-win-vcpus1 16 leak-check/check fail never pass test-amd64-i386-xl-win-vcpus1 13 guest-stop fail never pass test-amd64-i386-win 16 leak-check/check fail never pass test-amd64-amd64-win 16 leak-check/check fail never pass test-amd64-amd64-xl-win 13 guest-stop fail never pass test-i386-i386-xl-win 13 guest-stop fail never pass test-i386-i386-win 16 leak-check/check fail in 9176 never pass version targeted for testing: xen 3d1664cc9e45 baseline version: xen 3d1664cc9e45 jobs: build-amd64 pass build-i386 pass build-amd64-oldkern pass build-i386-oldkern pass build-amd64-pvops pass build-i386-pvops pass test-amd64-amd64-xl pass test-amd64-i386-xl pass test-i386-i386-xl pass test-amd64-i386-rhel6hvm-amd fail test-amd64-i386-xl-credit2 pass test-amd64-amd64-xl-pcipt-intel fail test-amd64-i386-rhel6hvm-intel fail test-amd64-i386-xl-multivcpu pass test-amd64-amd64-pair pass test-amd64-i386-pair pass test-i386-i386-pair pass test-amd64-amd64-pv pass test-amd64-i386-pv pass test-i386-i386-pv pass test-amd64-amd64-xl-sedf fail test-amd64-i386-win-vcpus1 fail test-amd64-i386-xl-win-vcpus1 fail test-amd64-amd64-win fail test-amd64-i386-win fail test-i386-i386-win fail test-amd64-amd64-xl-win fail test-i386-i386-xl-win fail ------------------------------------------------------------ sg-report-flight on woking.cam.xci-test.com logs: /home/xc_osstest/logs images: /home/xc_osstest/images Logs, config files, etc. are available at http://www.chiark.greenend.org.uk/~xensrcts/logs Test harness code can be found at http://xenbits.xensource.com/gitweb?p=osstest.git;a=summary Published tested tree is already up to date. _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel